products.sale_price 를 직접 고쳐야 했는데 연관 테이블이 다섯 개나 걸려 있었다. channel_products 와 commission_rates 와 latest_prices 와 price_histories 를 같이 고쳐야 하는지가 문제였다.
Table of contents
Open Table of contents
검증 — 전송이 읽는 컬럼
밖으로 나갈 때 어느 컬럼을 읽는지를 ProductPayloadBuilder 에서 확인했다. products 의 sale_price 와 list_price 두 컬럼만 읽어 페이로드를 만들고 있었다.
다섯 테이블을 grep -rn 으로 각각 검색했더니 페이로드 구성 코드에서는 하나도 안 읽었다. 용도를 확인하니 마지막 전송 값 기록과 정산 계산과 이력과 감사로 전부 정산과 감사 용도였다.
조치 — 불필요해진 추가 조치
두 가지 방법이 있었는데 다섯 테이블을 같이 갱신하는 것과 sale_price 만 바꾸는 것이다. 뒤쪽을 골랐다. 이유는 전송이 그 컬럼만 읽어서다. 대신 latest_prices 가 다음 수집 때까지 옛 값으로 남는 것을 감수했다.
전송 페이로드가 어느 컬럼을 읽는지를 코드에서 확인하는 것만으로 작업 범위가 다섯 테이블에서 두 컬럼으로 줄었다.
주의 — 게이트로 보인 플래그
channel_products 에 is_price_synced 불리언 컬럼이 있어서 그것이 전송을 막는지가 걸렸다. 이름만 보면 조건문에 쓰일 것처럼 생긴 컬럼이었다.
쓰는 곳을 검색하니 두 곳이었고 하나는 외부에서 가격을 수집할 때 현재가와 비교해 기록하는 자리이고 다른 하나는 가격 불일치 리포트의 필터였다. 기록하고 리포트에서 걸러 보여 줄 뿐 전송을 건너뛰거나 분기하지 않았다.
원인 — 오해했을 때의 결과
이것을 게이트로 봤으면 가격을 바꾸면 그 플래그가 거짓이 되어 전송이 막힐 것으로 판단해 플래그도 같이 갱신했을 것이다. 안 해도 되는 조작이 하나 늘어난다.
그리고 그 갱신이 리포트를 왜곡하는데 실제로는 불일치인데 일치로 표시된다. 이름이 용도를 말해 주지 않으므로 쓰는 곳을 검색해 확인해야 하고 결과 수가 적으면 그 확인이 금방 끝난다.
배경 — 코드와 실측을 함께
코드로 확인한 뒤 실제로 sale_price 만 바꾸고 channel:sync 를 걸어 봤다. 연관 테이블을 안 건드렸는데 네 채널에 정상으로 전송됐다.
이 조합이 필요한 이유는 코드를 읽어도 다른 경로가 있을 수 있고 실측은 실제로 어느 경로를 탔는지를 확인해 주기 때문이다. 둘이 같은 결론을 내면 그때 확정된다.
정리
- 전송 페이로드가 어느 컬럼을 읽는지 코드로 확인한다
- 연관 테이블이 많아도 전송에 안 읽히면 추가 조치가 불필요하다
- 불리언처럼 생긴 컬럼이 게이트가 아닐 수 있다
- 기록만 하고 리포트에서만 쓰이기도 한다
- 오해하면 불필요한 조작을 하고 리포트를 왜곡한다
- 쓰는 곳을 검색하면 결과 수가 적을 때 금방 끝난다
- 코드 확인과 실측을 함께 한다
- 둘이 같은 결론을 내면 확정된다