게이트가 둘일 때의 절반 통과

중지했는데 계속 주문이 들어온다는 문의를 받고 우리 쪽 상태를 보니 중지가 맞았다. 그런데 그 중지가 외부에는 나가지 않은 상태였다.

Open Table of contents

내부 상태와 외부 전송의 두 플래그

처리 코드를 보니 서로 다른 두 플래그를 각각 확인하고 있었는데 하나는 내부 상태를 바꿔도 되는지이고 다른 하나는 외부로 보내도 되는지였다. 두 조건이 한 흐름 안에 나란히 있지만 서로 독립적으로 판정된다.

첫 번째만 켜져 있으면 내부는 중지로 바뀌고 외부에는 아무것도 나가지 않는다. 화면에서는 중지로 보이므로 관리자 입장에서는 처리가 끝난 것으로 읽힌다.

이 구조에서는 완전히 된 것과 완전히 안 된 것 사이에 절반만 진행된 상태가 존재한다. 그리고 그 상태가 겉으로는 완료와 구분되지 않는다.

한 동작에 통과 지점이 여럿이면 그중 일부만 통과한 상태가 만들어지고 그 상태를 표시할 자리가 없으면 완료로 보인다. 문의가 반복되는 원인이 그 표시의 부재에 있었다.

중지가 외부에 안 나간다는 문의를 받으면 두 플래그를 함께 조회하는 것을 첫 단계로 뒀다. 조인이 길어지지만 한 번 만들어 두니 이후로 계속 쓰였다.

다만 이번 건은 두 값이 모두 정상이었고 게이트가 원인이 아니었다. 이 확인은 원인을 찾는 단계가 아니라 후보를 지우는 단계인데 그것을 헷갈리면 정상이니 문제없다는 결론으로 끝내게 된다.

왜 이렇게 나뉘어 있는지 짐작해 보면 단계적 도입을 위한 구조로 보인다. 어떤 거래처는 우리 시스템에서 관리만 하고 외부 전송은 자기 쪽에서 하므로 앞의 것만 켜 둔다.

그 자체는 합리적인 설계이고 문제는 그 구분이 어디에도 드러나지 않는다는 점이었다. 상태 아래에 외부 전송이 계정 설정으로 꺼져 있다는 한 줄만 있어도 문의가 생기지 않는다.

조사 결과를 정리하면서 원인만이 아니라 확인했지만 원인이 아니었던 것들도 함께 적었다. 두 플래그가 정상이라는 것과 전송 코드가 존재한다는 것과 작업 생성 이력이 없다는 것이 그 목록이었다.

배제 목록이 있으면 다음에 비슷한 문의가 왔을 때 그 부분을 다시 파지 않는다. 그리고 내 결론이 틀렸을 때 어느 단계에서 틀렸는지를 되짚을 수 있는 근거도 된다.