상품 분류 코드 category_code 를 새 체계로 바꾸게 됐고 코드만 바꾸면 되는 일로 봤다. 열어 보니 옛 체계는 세 단계 숫자이고 새 체계는 네 단계 영문 조합이라 단계 수부터 달랐다.
Table of contents
Open Table of contents
배경 — 1대1이 아니었다
하나가 둘로 나뉜 것이 있었고 반대로 둘이 하나로 합쳐진 것도 있었다. 단순 치환으로는 안 되는 구조였다.
그래서 옛 코드와 새 코드의 대응표를 category_map 테이블로 만들고 relation 컬럼에 관계 종류를 함께 담았다. ONE_TO_ONE 과 SPLIT 과 MERGE 와 NEW 와 RETIRED 다섯 가지다.
나눌 수 없는 것을 사람이 봤다
분할인 항목은 어떤 기준으로 나뉘는지를 적어야 했다. 자동으로 못 나누기 때문이다.
분할 대상 옛 코드가 셋이었고 그중 하나에 products 가 4천 건 넘게 걸려 있었다. 두 가지 방법이 있었다. 4천 건을 전부 사람이 보는 것과 상품명 LIKE 규칙으로 자동 분류하고 애매한 것만 넘기는 것이다. 뒤쪽을 골랐다. 이유는 앞쪽은 담당자 한 사람의 일주일이 통째로 들어서다. 대신 규칙이 잘못 분류한 것을 나중에 발견할 위험을 감수했다. 애매한 수백 건은 목록으로 뽑아 사람이 확인하게 넘겼다.
두 컬럼을 같이 두는 기간
전환 순서는 대응표를 만들고 new_category_code 컬럼을 추가한 뒤 채우는 것부터다. 그다음 읽는 쪽과 쓰는 쪽을 차례로 바꾸며 마지막에 옛 컬럼을 지운다. 그 사이에 두 컬럼이 공존하는 기간이 생긴다.
그 기간에 둘이 갈리지 않도록 새 코드를 세팅할 때 대응표로 옛 코드도 같이 채우게 했다. 공존 기간에 한쪽만 갱신되면 나중에 어느 쪽이 맞는지 알 수 없게 된다.
대응표가 남는 이유
전환이 끝나도 대응표를 지우지 않았다. 주문 이력과 통계 같은 옛 자료에 옛 코드가 남아 있고 외부 시스템이 아직 옛 코드로 보내기 때문이다. 과거 통계와 현재 통계를 비교할 때도 필요하다.
외부가 옛 코드로 보내면 대응표로 변환해 받게 했다. 대응표가 전환 도구가 아니라 계속 쓰는 자산이 됐다. 대응이 없는 값이 오면 UNCLASSIFIED 로 두고 Log::warning 으로 남겼는데 며칠 만에 열두 개가 나왔다.
조치 — 순서를 바꿔 끝낸 이관
과거 통계를 새 기준으로 다시 집계할 때는 분할 항목만 못 나눈다. 그 부분은 합쳐서 보여 주고 하위 구분이 없다고 표시했다.
옮기는 동안 새 상품이 계속 등록되는 문제도 있었는데 옮기기 시작할 때와 끝날 때의 건수가 달랐다. 등록하는 자리를 먼저 새 코드로 바꾸고 그다음에 옛 자료를 옮기니 옮기는 동안 새로 들어오는 것이 없었다. 옮기기 전에 들어오는 쪽을 먼저 바꾸지 않으면 이관이 끝나지 않는다.
정리
- 체계를 바꾸면 1대1로 안 맞고 나뉘고 합쳐지는 것이 있다
- 대응표에 관계 종류를 같이 담는다
- 나뉘는 것은 기준을 적어야 하고 자동으로 못 나눈다
- 자동 분류하고 애매한 것은 사람이 본다
- 두 컬럼을 같이 두는 기간에 갈리지 않게 한다
- 대응표는 전환 뒤에도 자산으로 남는다
- 대응 없는 값이 오면 미분류로 두고 로그에 남긴다
- 옮기기 전에 들어오는 쪽을 먼저 바꾼다