The Draw 운영에서 배치와 캐시 초기화가 맡고 있던 역할
The Draw를 다시 떠올려 보면 배치와 캐시 초기화가 계속 눈에 띕니다. 이건 우연이 아니라, 이벤트 운영에서 실시간 요청만으로는 처리할 수 없는 흐름이 분명히 있었기 때문입니다.
The Draw를 하나의 이벤트 운영 구조로 보면, 실시간 요청은 전체 수명주기의 일부에 불과합니다. 응모를 받고, 추첨 결과를 반영하고, 구매 가능 상태를 열고 닫고, 미구매자를 다음 단계로 넘기는 과정은 시점이 다르고 제약도 다릅니다. 이런 흐름을 모두 실시간 요청 하나에 몰아넣으면 오히려 구조가 불안정해집니다. 그래서 배치와 캐시는 The Draw에서 보조 수단이 아니라 핵심 운영 메커니즘이었습니다.
배치가 맡은 역할
배치는 단순한 정기 실행이 아니었습니다. 구매 정보 취합, 상태 전환, 후속 처리처럼 이벤트가 끝난 뒤 다음 단계로 넘어가기 위한 연결 고리 역할을 했습니다.
이 말은 곧, Draw 운영은 실시간 화면과 비동기 후처리가 함께 돌아가는 구조였다는 뜻입니다.
대량 이벤트에서는 모든 상태 전환을 실시간 요청 하나에 몰아넣기 어렵습니다. 어떤 일은 응모 시점에, 어떤 일은 추첨 시점에, 어떤 일은 구매 기간 종료 후에 처리해야 합니다. 이런 시차를 메워주는 것이 배치였습니다.
조금 더 풀어보면 배치는 다음 같은 역할을 맡고 있었을 가능성이 큽니다.
- 응모 데이터 집계와 추첨 준비
- 당첨자 상태 반영과 후속 알림 트리거
- 구매 기간 종료 후 미구매자 처리
- 재추첨 대상 정리와 다음 단계 상태 전이
이런 역할은 한 번의 사용자 요청으로 끝나지 않습니다. 이벤트 시간표와 운영 정책에 맞춰 순서대로 실행되어야 하고, 어느 단계가 실패했는지 운영자가 추적할 수 있어야 합니다. 그래서 배치는 The Draw에서 단순 스케줄러가 아니라 상태 전이 엔진에 가까웠습니다.
또 배치를 본다는 건 “언제 실행되느냐”만 보는 일이 아니었습니다. 어떤 배치가 앞선 배치 결과에 의존하는지, 중간에 실패하면 운영자가 수동 개입해야 하는지, 다음 단계가 지연되면 사용자 경험이 어디서부터 흔들리는지까지 함께 봐야 했습니다.
캐시 초기화가 중요한 이유
자료에는 The Draw 정보 캐시 초기화가 일정 주기로 수행된다는 설명이 남아 있습니다. 이벤트 시스템에서는 정보가 늦게 반영되는 것 자체가 사용자 경험과 운영 안정성에 직접 영향을 줍니다.
즉 캐시는 성능을 위해서만 있는 게 아니라, 이벤트 상태를 어느 시점에 어떻게 반영할 것인가라는 운영 문제와도 연결됩니다.
이 점이 일반 서비스와 다른 부분입니다. 캐시 불일치는 단순한 지연이 아니라, 당첨 여부나 구매 가능 상태 같은 민감한 정보에 직접 영향을 줄 수 있습니다. 그래서 캐시는 단순 성능 요소가 아니라 운영 타이밍 제어 장치처럼 다뤄야 했습니다.
예를 들어 응모 종료 직후에도 화면이 이전 상태를 계속 보여주거나, 추첨 결과가 반영됐는데 구매 가능 상태는 아직 늦게 열리거나, 재추첨이 끝났는데 사용자에게는 이전 정보가 보이는 상황이 생기면 운영 이슈가 바로 사용자 경험 이슈로 번집니다. The Draw에서 캐시가 민감했던 이유는, 보여주는 정보가 곧 이벤트 정책의 일부였기 때문입니다.
그래서 캐시 초기화는 단순히 오래된 데이터를 비우는 작업이 아니라, “이 시점부터 어떤 정보를 사용자와 운영자에게 보여줄 것인가”를 맞추는 일에 가까웠습니다. 이벤트 구조에서는 이 타이밍이 어긋나는 것 자체가 공정성이나 신뢰 문제로 이어질 수 있습니다.
배치와 캐시는 같이 봐야 했다
The Draw 운영에서 배치와 캐시는 따로 떨어진 주제가 아니었습니다. 배치가 상태를 바꾸면 캐시도 그 상태를 따라와야 하고, 캐시가 제때 갱신되지 않으면 배치가 성공했더라도 운영자는 시스템이 제대로 움직이는지 확신하기 어렵습니다.
즉 운영자는 다음 같은 질문을 함께 던져야 했습니다.
- 상태 전환 배치는 정상적으로 끝났는가
- 그 결과가 사용자 화면과 관리자 화면에 일관되게 반영됐는가
- 다음 단계 배치가 이 상태를 전제로 안전하게 실행될 수 있는가
이 질문을 통해 보면 The Draw의 배치와 캐시는 각각의 기술 요소가 아니라, 하나의 운영 타이밍 제어 장치로 읽는 편이 더 정확했습니다.
지금 다시 보면 남는 포인트
The Draw 운영에서 배치와 캐시는 각각 다른 역할을 맡았습니다.
- 배치: 상태 전환과 후속 처리
- 캐시: 빠른 조회와 운영 타이밍 제어
이 둘이 합쳐져야 대량 이벤트 트래픽에서도 시스템이 일관된 흐름을 유지할 수 있었습니다.
결국 The Draw 운영은 실시간 요청, 배치 상태 전이, 캐시 반영이 모두 맞물릴 때만 안정적으로 돌아갈 수 있었습니다. 그래서 이 글에서 말하는 배치와 캐시는 성능 최적화 요소라기보다, 이벤트 운영 구조를 성립시키는 핵심 장치에 가까웠습니다.
다음 글에서는 당시 캡처와 모니터링 흔적을 바탕으로, 대량 트래픽 발생 시 운영자가 실제로 무엇을 보고 있었는지 정리합니다: 대량 트래픽 발생 당시 캡처로 다시 보는 운영 포인트