돌고 있던 폴백 | isdnetworks

반품 건의 귀책을 바꿔야 했는데 어느 테이블을 고쳐야 하는지가 문제였다. 우리 반품 테이블과 외부에서 수집한 클레임 테이블 둘이 있어서 둘 다 고쳐야 화면에 반영되는지를 확인해야 했다.

Open Table of contents

응답을 만드는 계산부

화면이 받는 API의 응답 객체를 봤다. 귀책 컬럼을 먼저 읽고 그것이 비어 있을 때만 사유 코드로 판정하는 폴백 구조였다.

중요한 것은 그 계산에서 수집 테이블을 전혀 안 읽는다는 점이었다. 우리 반품 테이블의 두 컬럼만 보고 있으므로 우리 쪽만 고치면 화면과 API 출력이 다 바뀐다.

처음 생각은 두 테이블을 다 고치는 것이었고 확인 후에는 하나가 됐다. 작업이 절반이 된 것보다 중요한 것이 따로 있었다.

수집 테이블은 외부에서 가져온 원본이라 고치면 재수집할 때 덮이거나 충돌하고 정산 대사에서 원본과 안 맞으며 우리가 고친 것과 외부가 준 것의 구분이 사라진다. 수정 범위를 좁히는 것이 일이 줄어드는 것이 아니라 안전한 쪽을 고르는 것이었다.

이 계산 구조에서 진단 규칙도 나왔다. 화면 귀책값이 이상하면 첫 컬럼이 비어 폴백이 돌고 있는지를 의심한다.

첫 컬럼이 비면 사유 코드가 판정을 대신하는데 그 코드는 수집 당시의 값이라 나중에 사람이 판단한 귀책과 다를 수 있다. 이상한 값의 원인이 여기인 경우가 있다.

수정할 때 첫 컬럼만 바꿔도 동작한다. 폴백이 안 도니 둘째 컬럼은 안 읽히기 때문이다.

그래도 둘째 컬럼을 같이 맞췄는데 나중에 누가 그 컬럼만 보고 판단할 수 있기 때문이다. 동작에 영향이 없어도 두 값이 같은 것을 가리키게 둔다.

세 번째 필드인 사유 텍스트는 귀책 계산에 안 쓰이는 별개 필드였다. 고객이 쓴 원문이거나 상담원이 적은 것이다.

유지할지 바꿀지를 따로 결정해야 했고 이번에는 유지했다. 계산부를 읽는 데 5분이 걸렸고 그것으로 수정 범위가 절반이 됐으며 어디를 고쳐야 하느냐는 그 값을 읽는 코드가 답한다.