The Draw의 응모·추첨·구매와 배치 처리

Breeze에서 운영하던 The Draw는 응모를 받고 당첨자를 뽑는 기능에 그치지 않았습니다. 당첨자에게 구매 기회를 열고, 기간이 지난 뒤 미구매자를 처리하거나 재추첨하는 운영까지 연결되어 있었습니다.

이 글은 2020년 무렵 Breeze의 운영 경험을 정리한 내용입니다. 이후 글로벌 플랫폼의 저장결제 연동과 구분해서 봐야 하는 당시의 구매 기간 제어 흐름입니다.

응모부터 구매까지

운영자는 상품과 이벤트 정보를 등록하고 응모 기간을 설정했습니다. 응모가 끝나면 대상자를 기준으로 추첨하고, 결과와 알림을 반영한 뒤 정해진 기간에 당첨자가 구매할 수 있도록 운영했습니다.

각 단계가 이어지기 때문에 추첨 결과만 확인해서는 끝나지 않았습니다. 알림을 받은 사용자가 실제 구매 가능한 대상인지, 기간이 열려 있는지, 이미 구매를 마친 상태인지도 맞아야 했습니다.

구매 제한과 재추첨

제외 대상과 구매 제한 등은 이벤트의 운영 정책에 맞춰 시스템에서 처리해야 했습니다. 개발자가 정책 자체를 정했다기보다, 정해진 조건을 데이터와 검증 로직에 반영하는 일이었습니다.

재추첨에서도 현재 당첨자와 구매 완료자, 구매하지 않은 대상을 구분해야 했습니다. 같은 사람에게 구매 기회가 중복으로 생기거나 이미 완료된 구매가 다음 처리에 다시 들어가지 않는지 살펴볼 필요가 있었습니다.

규칙을 확인할 때는 어떤 대상에게 적용하는지와 언제 검증하는지를 함께 봐야 했습니다. 응모할 때 확인한 조건이라도 이후 구매 단계의 상태가 달라질 수 있기 때문입니다.

배치와 단계별 처리

구매 정보 취합이나 후속 상태 변경은 사용자 요청과 다른 시점에 진행됐습니다. 운영자는 배치가 실행됐는지와 어떤 대상을 처리했는지 확인해야 했습니다.

배치를 다시 실행할 때도 이미 반영한 결과와 아직 남은 대상을 구분할 필요가 있습니다. 추첨 결과가 반영된 상태에서 알림만 실패했는지, 구매 정보 취합부터 끝나지 않은 것인지에 따라 이어서 처리할 범위가 달라집니다. 모든 단계를 처음부터 다시 돌리면 되는 문제는 아니었습니다.

캐시 반영과 구매 가능 상태

이벤트 정보에는 캐시도 사용했습니다. 원본의 기간이나 상태를 바꾼 뒤 캐시가 이전 정보를 보여주면, 관리자와 사용자 화면이 다르게 보일 수 있었습니다.

캐시 초기화와 갱신 시점을 확인하되 캐시만을 구매 권한의 기준으로 삼을 수는 없습니다. 실제 구매 요청에서도 당첨 여부와 기간, 구매 완료 상태를 검증해야 합니다. 화면이 열린 상태라고 서버가 기간이 지난 구매까지 받아들여서는 안 됩니다.

또한 캐시를 한꺼번에 비우면 원본 조회가 몰릴 수 있습니다. 상태 반영과 조회 부하를 함께 고려해야 하는 부분이었습니다.

이벤트 운영과 트래픽 대응

이벤트가 시작되면 응모와 조회, 구매 요청이 짧은 시간에 몰렸습니다. 운영 흐름을 준비하는 것과 별개로 애플리케이션과 외부 연동이 그 요청을 처리할 수 있는지도 확인해야 했습니다.

당시 지표와 트래픽 차단·복구 경험은 대량 이벤트 트래픽 대응에 따로 정리했습니다.