넘버링 규칙과 그것이 깨진 이유

MySQL channel 테이블의 channel_code 컬럼을 이어받았다. SMALLINT인데 채널마다 붙은 숫자의 순서가 규칙적이지 않았다.

Open Table of contents

배경 — 새 채널의 코드를 정한다

새 채널 연동을 붙이면서 코드를 정해야 했는데, 기존 규칙을 따라야 하지만 그 규칙이 무엇인지 문서 어디에도 없었다.

10·20·30으로 올라가다가 갑자기 37이 나오고 다시 40으로 가는 식이었다. ORDER BY channel_code로 뽑아 봐도 규칙이 안 잡혔다.

channel_code를 쓰는 자리를 grep -rn으로 전부 찾으니 일부가 외부 API 요청 본문에 그대로 실리고 있었다. ESM 2.0 규격이 그 숫자를 자기 코드로 요구했다.

즉 우리가 정한 값이 아니라 상대가 정한 값이었고, 37은 그쪽 규격의 번호일 뿐 우리 순서와는 무관했다.

나머지는 우리가 정한 것이라 10 단위로 올라가고 있었다. 두 체계가 한 컬럼에 섞여 있었다.

방법이 셋이었다. 컬럼을 나눠 내부 코드와 외부 코드를 따로 두거나, 지금처럼 한 컬럼에 두고 범위로 가르거나, 매핑 테이블을 따로 만드는 것이다.

나누는 쪽은 의미가 분명해지는 대신, PHP·Blade·배치에서 그 값을 읽는 자리가 마흔 곳이 넘어 전부 고쳐야 한다.

범위로 가르는 쪽은 지금 구조를 그대로 유지하는 대신, 규칙이 코드에 드러나지 않아 사람이 알고 있어야 한다.

매핑 테이블은 확장이 쉬운 대신 JOIN이 한 번 늘고 ElastiCache Redis에 캐시를 하나 더 두게 된다.

범위로 가르고 문서에 적는 쪽을 골랐다. 인계를 전제로 보면 마흔 곳을 고치는 위험보다 규칙 하나를 문서로 남기는 편이 나았다.

1~99는 외부 규격 값, 100 이상은 내부 채번으로 갈랐다. 이번 채널은 내부 채번이라 110을 줬다.

대가는 규칙이 코드에 없다는 것이다. 대신 세 곳에 적었다 — Laravel 마이그레이션 파일 주석, MySQL 컬럼 COMMENT, 연동 문서.

이 규칙을 모르면 다음 사람도 같은 조사를 그대로 반복하게 되는데, 내가 반나절을 썼으니 그 반나절을 없애는 것이 문서의 값이다.

「왜 37인가」에 대한 답을 한 줄로 적었다. 답만 있으면 되고 조사 과정은 필요 없었다.

새 채널을 붙이는 절차도 함께 적었다. 어느 범위에서 다음 번호를 고를지가 그 절차의 첫 줄이다.