해외몰 배송비 구조를 재편하려던 참인데 배송 정보 테이블 TB_PRD_DLV_INFO 에 delivery_payment_setting(배송비설정) 컬럼이 하나 있었다. 두 값의 차이가 실제 동작인지 화면 표시인지부터 확인해야 했다.
Table of contents
Open Table of contents
배경 — 타입 컬럼의 두 값
그 컬럼이 가질 수 있는 값은 코드 표 TB_SYS_CODE_SUB 에 BASIC 과 ADD 두 가지로 등록돼 있었다. 이름만 보면 기본 배송비 위에 추가 배송비가 얹히는 구조인 것처럼 읽힌다.
그렇다면 이 컬럼 기준의 재편이 배송비 동작을 바꾼다는 뜻이 된다. 확인하지 않고 진행하면 그 위험을 그대로 안고 가는 셈이었다.
검증 — 전수로 찾아 분류한 결과
이 컬럼을 읽는 곳을 찾는 데는 두 가지 방법이 있었다. IDE 의 사용처 찾기와 grep -rn delivery_payment_setting 이다. 뒤쪽을 골랐다. 이유는 SQL 문자열 안에 든 컬럼명은 IDE 가 심볼로 못 보고 grep 은 보기 때문이다. 서비스와 컨트롤러와 모델과 cli/ 배치까지 전부 찾아, 나온 자리를 비교와 분기에 쓰는 것과 표시나 매칭에 쓰는 것으로 나눴다.
그 결과 if 나 switch 의 분기에 쓰는 곳이 한 군데도 나오지 않았다. 화면에 표시할 문구를 코드 표에서 고르는 자리와, 배송 정보를 복사할 때 같은 값끼리 짝짓는 자리 둘뿐이었다.
판단 기준 — 안 쓴다는 것은 전수라야 말할 수 있다
이 결론에서는 전수로 확인했다는 점이 중요했다. 일부만 봤으면 여기서는 안 쓰는 것 같다는 말까지만 할 수 있었다.
쓴다는 것은 한 건만 찾아도 성립하지만 안 쓴다는 것은 전부 봐야 성립한다. 어디까지 확인했느냐가 그대로 결론의 강도를 정했다.
원인 — 실제로 정하는 컬럼
그러면 실제로 배송비를 무엇이 정하는지가 다음 물음으로 남는다. 실제 값은 같은 행의 delivery_payment(배송비)와 delivery_payment_type(배송비결제방법)이 갖고 있었고, 어느 행이 적용되는지는 기본 키 prd_prd_mst_no 로 상품이 정했다.
둘 다 delivery_payment_setting 과는 아무 상관이 없는 경로였다. 그래서 이 컬럼 기준 재편은 동작에 영향이 없고 위험 지점은 delivery_payment_type 이 선불인지 착불인지로 옮겨 갔다.
이름이 만든 오해와 기록
이 오해를 만든 것은 이름이었고 그 이름은 앞으로도 그대로 남는다. 다음에 이 코드를 보는 사람도 BASIC·ADD 를 보고 같은 추측을 하게 된다.
기록에 이 컬럼을 동작 분기로 오인하지 말라고 적으면서 실제로 무엇이 정하는지도 함께 적었다. 아니라는 것만 적으면 반쪽이고 무엇이 맞는지까지 적어야 다음 조사가 짧아진다.
정리
- 이름이 동작을 암시해도 분기로 안 쓰일 수 있다
- 그 컬럼을 읽는 곳을
grep -rn으로 전수로 찾아 용도별로 나눈다 - 비교와 분기가 하나도 없으면 라벨이다
- 쓴다는 것은 한 건이면 되고 안 쓴다는 것은 전부 봐야 한다
- 확인 범위가 결론의 강도를 정한다
- 실제 동작은
delivery_payment·delivery_payment_type같은 다른 컬럼이 정할 수 있다 - 그러면 재편의 위험 지점이 다른 자리로 옮겨 간다
- 오인하지 말라는 것과 실제로 정하는 자리를 함께 적는다