값을 비워도 남는 것

한 채널에서 옵션 코드와 옵션명이 불일치한다는 오류가 105건 났다. 제안된 조치는 옛 식별자 컬럼을 비우면 새 코드가 생성돼 해결된다는 것이었다.

Open Table of contents

쪼개 세니 무너진 가설

조치하기 전에 105건을 작업 유형과 공급사와 값 보유 여부와 등록 상태 네 축으로 쪼개 셌다. 전부 갱신 작업이었고 102건이 그 값을 이미 가지고 있었다.

즉 값이 비어서 나는 문제가 아니었다. 값이 없어서라는 가설이 세 번째 축에서 그대로 무너졌고 쪼개기 전에는 105건이 한 덩어리였다.

작업 이력을 보니 이관 시점에 완료로 표시되고 로그에 이관이라고 적혀 있었다. 이관 때 등록 작업을 강제로 완료시킨 것이고 실제 마켓 API를 부르지 않았다는 뜻이다.

이관 전에 이미 마켓에 옛 구조 기반 코드로 등록돼 있었는데 이관은 우리 쪽 구조만 바꾸고 마켓 쪽은 안 건드렸다. 강제 완료라서 실제 호출이 없었기 때문이다.

제안된 조치를 따라가 보면 그 컬럼을 비우면 코드 생성이 다른 기준으로 넘어가고 또 다른 새 코드가 만들어진다. 그런데 그것도 마켓에 저장된 옛 코드와는 다르다.

어느 기준으로 만들든 마켓에 저장된 것과 다르면 불일치가 그대로 남는다. 생각한 문제는 우리 쪽 코드 생성 기준이 틀렸다는 것이었고 실제 문제는 마켓과 우리 쪽 코드가 어긋나 있다는 것이었다.

맞추려면 한쪽을 다른 쪽에 맞춰야 한다. 연동을 해제하고 재등록해 새 코드로 등록을 태우거나 마켓의 옵션명 변경 기능으로 상대 쪽을 먼저 동기화하는 두 방법이다.

둘 다 마켓을 건드려야 하고 우리 쪽만 고쳐서는 안 맞는다. 이 결론이 조치의 성격 자체를 바꿨다.

쪼갠 결과 105건이 세 유형으로 갈렸다. 이관 강제 완료가 94건이고 나중에 옵션을 추가하면서 코드가 겹친 것이 8건이며 등록은 정상이었는데 그 뒤 옵션을 바꿔 불일치가 난 것이 3건이었다.

원인이 다르므로 대응도 다를 수 있다. 조치 전에 여러 축으로 쪼개 세는 것이 이 조사의 요지였는데 한 덩어리로 보면 한 가지 조치만 떠올리게 된다.