반품 건의 귀책을 바꿔야 했는데 어느 테이블을 고쳐야 하는지가 문제였다. 우리 returns 와 채널에서 수집한 channel_claims 둘이 있어서 둘 다 고쳐야 화면에 반영되는지를 확인해야 했다.
Table of contents
Open Table of contents
배경 — 응답을 만드는 계산부
화면이 받는 API 의 ReturnResource 를 봤다. fault_type 을 먼저 읽고 그것이 null 일 때만 reason_code 로 판정하는 폴백 구조였다.
중요한 것은 그 계산에서 수집 테이블을 전혀 안 읽는다는 점이었다. returns 의 두 컬럼만 보고 있으므로 우리 쪽만 고치면 화면과 API 출력이 다 바뀐다.
조치 — 범위가 절반으로 좁아졌다
두 가지 방법이 있었는데 두 테이블을 다 고치는 것과 returns 만 고치는 것이다. 뒤쪽을 골랐다. 이유는 계산부가 channel_claims 를 안 읽어서다. 대신 두 테이블의 귀책이 서로 다른 채로 남는 것을 감수했다. 작업이 절반이 된 것보다 중요한 것이 따로 있었다.
수집 테이블은 외부에서 가져온 원본이라 고치면 재수집할 때 덮이거나 충돌하고 정산 대사에서 원본과 안 맞으며 우리가 고친 것과 외부가 준 것의 구분이 사라진다. 수정 범위를 좁히는 것이 일이 줄어드는 것이 아니라 안전한 쪽을 고르는 것이었다.
검증 — 폴백을 의심하는 진단
이 계산 구조에서 진단 규칙도 나왔다. 화면 귀책값이 이상하면 fault_type 이 비어 폴백이 돌고 있는지를 의심한다.
fault_type 이 비면 reason_code 가 판정을 대신하는데 그 코드는 수집 당시의 값이라 나중에 사람이 판단한 귀책과 다를 수 있다. 이상한 값의 원인이 여기인 경우가 있다.
정합성을 위해 맞춘 둘째 컬럼
수정할 때 fault_type 만 바꿔도 동작하는데 폴백이 안 도니 reason_code 는 안 읽히기 때문이다.
그래도 둘째 컬럼을 같이 맞췄는데 나중에 누가 그 컬럼만 보고 판단할 수 있기 때문이다. 동작에 영향이 없어도 두 값이 같은 것을 가리키게 둔다.
주의 — 계산에 안 쓰이는 필드
세 번째 필드인 reason_text 는 귀책 계산에 안 쓰이는 별개 필드였다. 고객이 쓴 원문이거나 상담원이 적은 것이다.
유지할지 바꿀지를 따로 결정해야 했고 이번에는 유지했다. 계산부를 읽는 데 5분이 걸렸고 그것으로 수정 범위가 절반이 됐으며 어디를 고쳐야 하느냐는 그 값을 읽는 코드가 답한다.
정리
- 응답 값이 여러 컬럼의 폴백 체인으로 계산될 수 있다
- 계산부를 읽으면 어느 테이블만 고치면 되는지 나온다
- 수집 원본을 안 건드리는 쪽이 안전하다
- 수정 범위를 좁히는 것은 안전한 쪽을 고르는 것이다
- 값이 이상하면 첫 컬럼이 비어 폴백이 도는지 의심한다
- 동작에 영향 없어도 관련 컬럼을 정합성 있게 맞춘다
- 계산에 안 쓰이는 별개 필드는 따로 결정한다
- 어디를 고칠지는 그 값을 읽는 코드가 답한다