Nike The Draw 운영 구조 다시 읽기
Nike The Draw는 단순 이벤트 기능이 아니라 운영, 배치, 제한 조건, 구매 흐름이 모두 얽힌 시스템이었습니다. 운영 구조를 다시 보면 일반적인 상품 판매와는 결이 다른 문제들이 보입니다.
The Draw는 무엇이 달랐는가
일반 상품 판매는 재고와 주문 흐름이 중심이라면, The Draw는 응모와 추첨, 당첨자 확정, 알림 발송, 구매 기간 제어까지 함께 움직였습니다. 즉 이벤트 운영 자체가 제품 기능 안으로 들어와 있었습니다.
실제 흐름을 다시 보면 응모자, 운영자, Breeze, 배치, 구매 흐름이 모두 하나의 운영 구조 안에 묶여 있었습니다. 이건 The Draw가 단순 UI 기능이 아니라 운영 시스템이기도 했다는 의미입니다.
일반 상품 판매는 상품 정보, 재고, 주문 처리라는 익숙한 흐름 위에 올라갑니다. 반면 The Draw는 응모 기간, 추첨 정책, 당첨자 선정, 알림 발송, 제한된 구매 기회처럼 시간과 규칙이 강하게 개입합니다. 그만큼 운영자의 역할도 더 커집니다.
특히 이 구조는 “트래픽이 몰리는 상품 판매”와도 조금 달랐습니다. 일반 판매는 재고와 주문을 얼마나 안정적으로 처리하느냐가 중심이라면, The Draw는 그 앞단에 응모와 추첨, 뒤쪽에 당첨자 확정과 구매 기간 제어가 들어갑니다. 즉 판매 자체보다 이벤트 수명주기를 설계하고 운영하는 일이 더 중요했습니다.
그래서 The Draw는 하나의 기능이 아니라 작은 운영 시스템처럼 봐야 했습니다. 응모를 받고 끝나는 것이 아니라, 응모 데이터를 어떻게 모으고, 어떤 규칙으로 추첨하고, 당첨자를 어떻게 통지하고, 제한된 기간 안에 구매 기회를 어떻게 제어할 것인지까지 모두 이어져 있었기 때문입니다.
이벤트 수명주기로 보면 더 잘 보인다
The Draw를 이해할 때 도움이 됐던 건 화면이 아니라 수명주기였습니다. 대략 흐름은 이렇게 이어졌습니다.
- 상품과 이벤트 정보 등록
- 응모 기간 운영
- 응모 데이터 집계
- 추첨과 당첨자 확정
- 알림 발송
- 제한된 구매 기간 운영
- 미구매자 처리와 재추첨 또는 후속 운영
이 흐름으로 보면 The Draw는 단순한 판매 기능이 아니라, 시간에 따라 상태가 바뀌는 이벤트 엔진에 가까웠습니다. 운영자가 어느 단계에 있는지, 지금 어떤 제약이 유효한지, 다음 단계는 무엇인지 알아야 전체를 통제할 수 있었습니다.
또 각 단계는 독립적이지 않았습니다. 응모 기간 설정이 틀리면 추첨 모집단이 흔들리고, 추첨이 흔들리면 당첨자 알림과 구매 기간 운영이 모두 영향을 받습니다. The Draw가 까다로운 이유는 각 단계가 따로 구현되어 보이면서도 실제로는 하나의 운영 흐름으로 묶여 있기 때문이었습니다.
운영자가 봐야 했던 것
The Draw 구조에서 운영자가 중요하게 봐야 했던 건 다음과 같았습니다.
- 상품과 응모 정보가 어떻게 연결되는가
- 추첨과 재추첨이 어떤 규칙으로 움직이는가
- 구매 제한과 당첨자 rule은 어떻게 설정되는가
- 배치와 캐시 초기화는 어느 시점에 개입하는가
즉 이 시스템은 “자동으로 잘 돌아가는 이벤트”가 아니라, 제약과 운영 판단이 강하게 들어가는 이벤트 운영 구조였습니다.
그래서 The Draw를 읽을 때는 단순히 화면이나 관리자 기능을 보는 것보다, 운영자가 어떤 결정을 내려야 하고 시스템은 어떤 규칙을 강제하는가를 함께 봐야 했습니다. 이 관점을 놓치면 이벤트 구조가 왜 복잡한지 제대로 보이지 않습니다.
운영자가 실제로 신경 써야 했던 건 단순히 “추첨 버튼이 있다” 같은 수준이 아니었습니다. 응모가 정상적으로 모이고 있는지, 제외 대상이 잘 반영됐는지, 추첨 이후 구매 제한이 올바르게 걸리는지, 미구매자 처리와 재추첨 타이밍이 운영 정책과 맞는지까지 함께 봐야 했습니다. 즉 운영 기능은 관리자 화면 안에 있었지만, 실제 판단 기준은 이벤트 정책 전체에 걸쳐 있었습니다.
왜 별도 구조로 이해해야 했는가
The Draw는 Nike 서비스였기 때문에 트래픽 특성도 강했습니다. 관심이 집중되는 상품 하나에 짧은 시간 안에 많은 사용자가 몰리고, 운영 정책 하나가 곧바로 사용자 경험과 공정성 이슈로 이어질 수 있었습니다. 그래서 단순히 “커머스 기능 하나”로 보면 부족했고, 이벤트 운영과 트래픽 대응을 함께 보는 구조로 이해해야 했습니다.
여기에는 애플리케이션 내부만의 문제가 아닌 외부 연동과 인프라 한계도 같이 들어와 있었습니다. 트래픽이 몰리는 시점에는 AWS 콘솔에서 바로 올릴 수 있는 한도 때문에 별도 연락을 통해 증설을 요청했던 기억도 있고, 본인인증이 필요한 흐름에서는 우리 쪽 트래픽이 몰리며 외부 본인인증 서비스 전체가 흔들리거나 장애로 번졌던 적도 있었습니다. 그래서 사전에 연락해 증설을 요청하거나 대비하는 일도 운영의 일부였습니다. 즉 The Draw는 우리 시스템만 잘 만든다고 끝나는 구조가 아니라, 외부 서비스와 인프라의 수용력까지 함께 관리해야 하는 운영 시스템이었습니다.
이 관점에서 보면 The Draw는 앞선 시리즈와도 자연스럽게 연결됩니다. Broadleaf/Breeze 구조를 이해해야 이 이벤트가 어디에 얹혀 있는지 보이고, 주문/재고 시리즈를 이해해야 실제 구매 단계의 병목을 볼 수 있고, 운영 도구화 시리즈를 이해해야 배치·로그·운영자 개입 지점을 읽을 수 있습니다. 즉 The Draw는 앞 시리즈의 흐름이 실제 이벤트 운영으로 모이는 지점이기도 했습니다.
다음 글에서는 이 구조 안에서 추첨, 재추첨, 구매 제한이 어떻게 연결되어 있었는지 더 좁혀서 봅니다: 추첨, 재추첨, 구매 제한은 어떻게 연결되어 있었나