문의에 답하면서 주문번호를 적어 보냈는데 상대가 그 번호로는 조회가 안 된다고 했다. 확인해 보니 내가 보낸 것은 조사할 때 쓰던 내부 키였고 밖에 안내하는 번호는 다른 값이었다.
Table of contents
셋으로 갈린 식별자
정리해 보니 같은 주문 하나에 식별자가 셋이었는데 내부 키는 DB 조회와 조인에 쓰고 대외 번호는 화면과 고객 안내에 쓰며 API 입력값은 관리자 API 호출에 쓴다.
세 번째는 내부 키를 변환한 값인데 밖으로 순서를 노출하지 않으려고 그렇게 한다. 문제는 화면과 로그와 DB에서 각각 다른 것을 본다는 점이고, 조사할 때는 DB를 보게 되니 내부 키가 손에 익어서 그대로 쓰게 된다.
계속 틀리는 이유
몇 번 더 겪고 나서 패턴이 보였는데 변환 상수가 대상마다 다르다는 것이 첫 번째였다. 주문과 주문항목과 상품이 각각 다른 상수를 쓰므로 한 대상의 상수로 다른 대상의 값을 변환하면 존재하지 않는 값이 나온다. 그러면 없는 데이터라는 응답이 오고 라우팅이나 권한 문제로 오해하게 된다.
되돌린 값이 다른 것의 키가 되기도 했는데, 변환값을 되돌려 나온 숫자를 기본키로 조회했더니 그것이 우연히 다른 대상의 키였고 엉뚱한 데이터가 조회되면서 오류는 안 났다.
컬럼 이름도 도움이 안 됐는데 내부 키처럼 보이는 이름의 컬럼에 외부 번호가 들어 있는 경우가 있었고 그때 조인이 계속 0건으로 나왔다.
지금 하는 확인
숫자를 하나 받으면 그것이 셋 중 무엇인지부터 보는데 자릿수와 형태로 대개 구분된다.
손으로 만든 값은 역방향으로 되돌려 원래 값이 나오는지 대조하고 안 나오면 상수를 잘못 고른 것으로 본다. 대상별 상수는 외우지 않고 매번 설정 파일에서 확인한다.
나가는 문서에는 대외 번호만 쓴다. 조사 노트에는 내부 키를 써도 회신이나 문서에는 조회해서 대외 번호로 바꿔 넣는다.
셋으로 갈린 까닭
처음에는 왜 이렇게 복잡한지 싶었고 하나로 통일하면 안 되는지 생각했는데 셋으로 갈린 데는 이유가 있었다.
순서대로인 번호를 밖에 노출하면 남의 것을 찍을 수 있고 규모도 드러난다. 내부 조인은 정수 키가 빠르고 변환된 값을 저장하면 조회할 때마다 변환해야 한다. 고객 안내용 번호는 사람이 읽고 부를 수 있어야 하고 날짜가 앞에 붙어 있으면 언제 주문인지 바로 안다.
세 값의 목적이 각각 다르니 값도 다른 형태가 된 것이었다. 통일하면 셋 중 하나는 목적을 잃는다.
남은 문제
로그에 숫자만 찍혀 있으면 어느 값인지 모른다는 문제가 그대로 남아 있다. 접두어를 붙이자는 이야기가 나왔는데 아직 못 했다.
변환 코드가 여러 곳에 흩어져 각자 상수를 들고 있는 것도 문제이고 하나가 바뀌면 전부 찾아야 한다. 화면마다 다른 것을 보여 주는 것도 그대로 남아 있다. 어떤 화면은 대외 번호를 보여 주고 어떤 화면은 변환값을 보여 줘서 사용자가 헷갈린다.
정리
- 같은 대상에 내부 키와 대외 번호와 API 입력값이 각각 있을 수 있다
- 변환 상수는 대상마다 다르고 다른 상수를 쓰면 존재하지 않는 값이 된다
- 손으로 만든 값은 되돌려서 원래 값이 나오는지 대조한다
- 컬럼 이름이 무엇을 담는지 말해 주지 않는다
- 나가는 문서에는 대외 번호만 쓴다
- 조사에 쓴 값을 그대로 인용하지 않는다
- 셋으로 갈린 데는 이유가 있다
- 통일하면 셋 중 하나는 목적을 잃는다