초기화 스크립트가 소스와 어긋났다

인계받은 프로젝트에 초기화 스크립트가 있었다. 공통 코드가 하드코딩돼 있어서 원본 소스와 대조해 봤다.

Open Table of contents

상황 — 인계받은 초기화 스크립트

스크립트는 이렇게 생겼다.

INSERT INTO code_sub (group_id, code_id, code_name) VALUES
  ('GRP_010', 'PRODUCT', '상품카테고리'),
  ('GRP_011', 'SOLDOUT', '품절'),
  ...

code_id 와 code_name 이 그대로 박혀 있다.

code_sub 에 무엇이 들어가는지는 이 파일이 정하지만 그 값을 실제로 쓰는 쪽은 따로 있다. 초기화가 만드는 것과 코드가 기대하는 것이 같다는 보장은 어디에도 없었다.

GRP_010 과 PRODUCT 라는 값이 소스 어디에 나오는지부터 찾아야 했다. 인계 문서에는 이 코드 체계에 대한 설명이 한 줄도 없었다.

원본 소스에서 코드가 어떻게 쓰이는지 찾았다.

COM_010_0001
COM_011_0003
COM_024_0001

COM_010_0001 같은 값을 여러 곳에서 대조하니 형식이 보였다.

COM_{그룹번호}_{순번}
      = 그룹의 N번째 서브코드

그리고 이 값이 화면에서 서버로 보내는 값이기도 했다.

프론트 → COM_010_0001 전송
서버   → 그대로 저장

전송값이 곧 저장값이라 화면과 code_sub 가 같은 문자열을 보고 있어야 한다.

COM_{그룹번호}_{순번} 이라는 형식이 화면과 서버 사이의 약속인 셈이다. 그 약속을 초기화 스크립트가 알고 있는지가 다음 물음이 됐다.

초기화 스크립트는 이 형식을 따르지 않았다.

COM_010_0001 이어야 할 자리에  PRODUCT

PRODUCT 라는 값은 COM_ 으로 시작하지도 않고 순번도 없다. 대조해 보니 어긋난 방식이 하나가 아니라 셋이었다.

원본    COM_010_0001
초기화  PRODUCT

첫째는 PRODUCT 처럼 값 자체가 다른 경우다.

원본    COM_011_0003 = 판매예정
초기화  SOLDOUT = 품절

둘째는 SOLDOUT 처럼 값도 다르고 그 값이 가리키는 뜻도 다른 경우다.

원본    COM_024_0001 = 첫 번째 유형
초기화  GENERAL = 일반문의 (다른 순번의 것)

셋째는 순번과 내용의 매핑 자체가 밀려 있는 경우였다.

COM_024_0001 이 가리키는 것과 GENERAL 이 가리키는 것이 서로 다른 항목이었다. 값을 바꿔 넣는 것만으로는 안 되고 어느 순번이 무엇인지를 다시 맞춰야 한다.

셋의 성격이 서로 다르다.

[값만 다름]   안 맞아서 조회가 0건 → 티가 남
[의미가 다름]  값은 찾아지는데 뜻이 다름 → 안 티남

PRODUCT 처럼 값만 다르면 화면에서 이름이 안 나오거나 조회가 비어서 금방 드러난다.

의미가 다르면 조회는 정상으로 되고 화면에도 무언가 나온다. 품절로 저장됐는데 실제로는 판매예정인 상태가 되고 어디에서도 오류가 나지 않는다.

앞의 것은 고장으로 보이고 뒤의 것은 정상으로 보인다. 그래서 뒤쪽이 더 오래 남고 잘못된 값이 다른 표로 더 멀리 퍼진다.

SOLDOUT 으로 쌓인 자료를 나중에 고치려면 어느 시점부터 잘못됐는지를 먼저 가려야 한다. 값이 안 맞아 조회가 비는 쪽은 고칠 것이 코드뿐이지만 이쪽은 쌓인 자료까지 따라온다.

어느 쪽에 맞출지가 판단이었다.

[초기화 기준]  프론트를 전부 고쳐야 함
[원본 기준]    초기화 스크립트만 고치면 됨

프론트가 여럿이고 COM_ 코드를 쓰는 자리가 많아서 한 파일을 고치는 쪽이 쌌다.

원본 소스가 지금 돌고 있는 것이라는 점도 컸다. init 스크립트는 그것을 따라오지 못한 기록일 뿐이었다.

어느 쪽이 정본이냐는 물음에는 실제로 돌고 있는 쪽이 답이 된다. 프론트 여럿을 고쳐 스크립트에 맞추는 것은 사실을 기록에 맞추는 일이 된다.

코드를 쓰는 원본이 한 곳이 아니었다.

서버
사용자 화면
관리 화면

서버와 두 화면이 다 COM_ 코드를 쓰므로 한 곳만 보면 그쪽에서만 쓰는 코드를 놓친다.

셋을 교차해서 전체 목록을 만들었는데 그래도 어디에도 안 나오는 것이 남았다. 어떤 그룹의 서브코드 넷 중 가운데 둘이 세 곳 어디에서도 안 쓰이고 있었다.

[안 넣음]  나중에 쓰이면 없어서 깨짐
[추정해 넣음]  틀린 값이 들어감

code_sub 에 넣지 않고 미확인으로 표시해 두는 것이 지금 할 수 있는 것이었다. 나중에 그 코드를 쓰는 화면이 나오면 거기서 확정된다.

같은 어긋남이 다시 쌓이지 않게 할 방법도 생각해 봤다. 코드 이름은 한글 표시명이라 소스에 없으니 완전 자동 생성은 어렵지만 코드값 목록만 대조하는 검사는 만들 수 있다.

소스의 코드 목록  vs  초기화의 코드 목록

차이가 있으면 실패하는 검사를 두면 이번 같은 불일치가 누적되지 않는다.

code_name 은 사람이 채우더라도 code_id 목록이 어긋나는 것은 기계가 잡을 수 있다. 인계받은 시점에 이런 검사가 있었으면 대조에 쓴 시간이 필요 없었을 것이다.