둘을 빠뜨린 하드코딩 목록

판매중지를 했는데도 계속 주문이 들어온다는 문의가 들어왔다. 한 업체의 특정 상품군에 대한 얘기였다.

Open Table of contents

열이 되고 둘이 안 된 상태

상품 상태와 외부 노출이 분리돼 있으므로 채널별 상태를 하나씩 확인했다. 12개 채널 중 열 개는 중지 성공인데 나머지 둘만 다른 상태로 남아 있었다.

그 두 채널의 작업 이력을 조회하니 중지 작업이 아예 0건이었다. 실패가 아니라 생성 자체가 안 된 것이고 같은 상품에 같은 조작인데 일부만 안 됐다는 것은 채널 목록 어딘가에 그 둘이 빠져 있다는 신호였다.

그 목록이 어디 있는지 찾아보니 몇 달 전에 운영자가 실행한 일회성 배치가 있었다. 중지 상태를 마켓에 재동기화하는 작업이었고 저장소에 없이 운영 서버에서 직접 실행한 것이었다.

그 스크립트에 채널 목록이 하드코딩돼 있었는데 정확히 열 개뿐이었다. 문제의 두 채널은 스크립트를 작성한 뒤에 통합됐으므로 작성 시점의 목록에는 있을 수 없었다.

이 누락이 왜 영구적인지도 따라가 보니 분명했다. 그 배치는 일회성으로 만든 것이라 다시 돌지 않는다.

평소 흐름에서 중지 작업이 안 만들어진 것을 그 배치가 메꿔 준 것인데 두 채널을 빠뜨렸으니 그 둘은 영영 안 메꿔진다. 이 상품만인지를 확인하려고 전사 규모로 세니 5천 건이 넘었다.

한 업체의 한 상품 문의로 시작한 것이 개발팀에 따로 보고할 구조적 버그가 됐다. 이 건만 고치고 끝내면 나머지 수천 건이 그대로 남게 된다.

그 상품들이 중지된 것으로 알려진 상태에서 계속 팔린다는 것이 문제였다. 규모를 세어 보지 않았으면 이 건도 한 건 처리로 끝났을 것이다.

재발 방지로 새 채널을 통합할 때 유사한 수동 배치의 채널 목록 누락 여부를 점검한다는 항목을 넣었다. 수동 배치는 저장소에 없어서 찾기 어렵지만 채널을 늘릴 때 하드코딩된 목록이 어디 있는지를 한 번 훑는 절차가 있으면 줄어든다.

근본적으로는 저장소에 없는 스크립트를 운영에서 실행한 것이 문제였다. 이력도 리뷰도 없고 나중에 무엇을 했는지 알 수 없으며 재실행도 안 되므로 일회성이어도 저장소에 넣어야 채널을 늘릴 때 검색에 걸린다.