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