매진 알림을 기다리지 않고 다음 판매를 준비하도록

매진 시각은 예약할 수 없었다

커머스 서비스에는 웨이브라고 부르는 판매 회차가 있었다. 앞 회차의 상품이 팔리면 다음 회차를 열어야 했다. 운영자는 Telegram 매진 알림을 받은 뒤 새 회차를 수동으로 등록했다. 매진 시각을 알 수 없으니, 새벽에도 알림을 듣고 대응해야 하는 일이었다.

단순히 ‘몇 시에 열기’로 예약하면 해결될 문제가 아니었다. 판매가 빨리 끝날 수도, 예상보다 오래 이어질 수도 있었다. 필요한 것은 시각 예약보다 판매 상황에 따른 연결이었다.

다음 회차를 미리 준비하기

후속 회차를 먼저 등록하고, 특정 선행 회차의 잔여 수량이 정한 조건에 도달하면 이어서 열리는 체인을 구현했다. 운영자는 매진을 기다리는 대신 다음 판매를 미리 준비할 수 있게 됐다. 나는 서버와 배치 처리를 맡고 실무자·상급자에게 활용 방법을 권장하고 교육했다.

배치는 정해진 작업을 반복 실행하는 프로그램이다. 여기서는 판매 상태를 확인하고 다음 회차를 여는 일을 처리했다. 달력의 시각만 보는 예약과 달리, 업무 데이터가 실행 조건이 된다는 점이 중요했다.

운영자로부터 새벽 알림에 맞춰 일어나는 부담이 줄고, 미리 등록할 수 있어 편해졌다는 피드백을 들었다. 시간 절감률을 잰 것은 아니다. 그래도 어떤 일이 달라졌는지는 설명할 수 있었다.

실제로 쓰기 시작하니 빠르게 마감될 때 체인이 이어지지 않거나 다른 회차와의 연결이 빠지는 경우가 있었다. 그때 발견한 운영 예외를 수정했다. 사전 등록 기능을 만드는 것과 다양한 판매 속도에서 이어지게 만드는 것은 따로 확인해야 했다.

후속 요청 때문에 앞 거래까지 취소되는 문제

안정화 과정에서 다른 경로도 살폈다. 다음 회차를 여는 활성화 요청이 중복되면 PostgreSQL의 UNIQUE 제약에 부딪혔다. UNIQUE는 같은 요청을 두 번 기록하지 않도록 DB가 막는 조건이다. 그런데 그 오류가 같은 트랜잭션을 중단시키면서, 앞에서 처리한 원 회차 결과까지 rollback될 수 있었다.

트랜잭션은 여러 DB 변경을 함께 확정하거나 함께 취소하는 단위다. 중복을 막으려던 장치가 보존해야 할 거래까지 취소한다면, 중복 방지 자체만 성공했다고 볼 수 없었다. 프로그램에서 오류를 잡아 무시해도 DB의 중단된 트랜잭션이 저절로 정상으로 돌아오지는 않는다.

예상 가능한 충돌은 INSERT ... ON CONFLICT DO NOTHING으로 새 기록을 만들지 않게 처리했다. 그다음 같은 이벤트의 재전송이면 기존 요청을 찾아 사용하고, 다른 요청이 같은 대상을 처리 중이면 이유를 남기고 건너뛰었다. 충돌을 피하는 SQL과 계속 진행해도 되는지를 정하는 업무 판단은 역할이 달랐다. PostgreSQL의 ON CONFLICT 설명을 참고할 수 있다.

알 수 없는 오류까지 성공으로 돌리지는 않았다. 검토할 때도 응답 값만 보지 않고 기존 요청 번호와 처리 뒤 거래 상태를 함께 봤다. 구현에 AI 코딩 도구를 썼고, 수정 범위와 회귀 결과는 직접 확인했다. 순서와 경쟁 상태는 중복 요청 처리 기록에서 더 설명한다.

구현과 도구 활용 교육은 다른 일이었다

반복 점검과 결과 전달에는 Hermes·Codex 예약 실행과 Telegram 보고를 쓰는 방법도 교육했다. 교육한 방법이 실제 업무에 적용돼 사용 중이라는 확인을 받았다. 이 경험은 판매 체인의 서버 구현과 함께 이어졌지만, 새로운 AI 장애 탐지·자동 복구 시스템을 개발한 것은 아니다.

어디까지 적용했나

테스트 수는 당시 수정의 확인 범위다. 현재 서비스 전체에 오류가 없다는 수치는 아니다. 외부 재고 API까지 모든 처리가 한 번만 일어난다고 보장한 것도 아니다.

처음 질문은 다음 회차를 어떻게 자동으로 열까였다. 실제로 쓰는 과정에서는 앞 회차의 결과를 무엇 때문에 잃을 수 있는지까지 봐야 했다. 운영자가 미리 준비한 일이 예외 하나로 사라지지 않게 하는 것도 같은 작업에 들어 있었다.