팝업온 빌드 로그 — 3주 만에 한 번 갈아엎은 팀 프로젝트

왜 시작했나요

굿즈 팝업에 가면 계산대 앞 줄이 길고, 줄을 서는 사이에 사려던 굿즈가 품절되는 일이 흔해요. 이런 불편을 직접 겪어서, 팝업 운영을 돕는 서비스를 만들어 보기로 했어요.

2026년 10월, 국민대 창업동아리 3인 팀 '사전예약'으로 팝업온을 시작했어요. 저는 기획 문서(PRD)를 처음 쓰는 것부터 맡았어요.

첫 번째 팝업온: 사전조사로 미리 알기

처음 방향은 "행사 전에 미리 알기"였어요. 손님이 사전조사 링크로 방문 시간대와 사고 싶은 수량을 남기면, 판매자는 시간대별 예상 인원과 품목별 준비 수량을 봐요. 당일에는 부스에 붙인 종이 QR로 대기번호를 받고, 매일 마감 때 남은 재고를 넣으면 예측과 실제를 비교하는 리포트가 나와요.

처음 예산안에는 QR 스테이션 장비가 있었어요. 하지만 판매자가 종이 QR을 붙여 두기만 해도 된다는 걸 알고 장비를 뺐고, 그 돈은 AI 구독료로 돌렸어요.

이 방향에서 제가 만든 것은 주로 데이터 쪽이에요.

• Python 예측 파이프라인: 응답을 시간대별로 모아 기준선 예측을 내고, 첫날 실제 방문 수로 다음 날 예측을 다시 계산해요.
• 리포트 AI 해설: 리포트 집계만 Gemini에 보내 요약을 받아요. 해설 문장에 보낸 집계에 없는 숫자가 들어 있으면 저장하지 않게 했어요. AI가 차이나 배수를 스스로 계산해 지어내는 걸 막으려고요.

팀은 손님의 이름이나 전화번호를 받지 않기로 했어요. 그래서 사전조사 응답과 당일 방문을 사람 단위로 잇지 않고, 응답 수 대비 대기 등록 수라는 비율 하나로 예측을 보정했어요.

고객을 다시 정했어요

실증은 서울코믹월드 같은 행사에서 개인 부스와 하기로 했었어요. 그런데 사업 정리 문서를 쓰다가 "실증만 코믹월드이고, 돈을 내는 진짜 고객은 기업 아닌가?"라는 질문이 나왔어요. 정리해 보니 첫 유료 고객은 작은 기업 팝업이었어요.

고객이 기업이 되자 필요한 기능도 달라졌어요. 같은 시기에 열린 스텔라이브 팝업은 손님이 매대의 NFC에 폰을 대고 굿즈를 골라 결제하면 픽업 번호를 받고, 번호가 불리면 카운터에서 받아 가는 방식이었어요. 기업 팝업에서는 사전조사보다 계산대 줄을 없애는 게 더 직접적인 해결이라고 판단했어요.

10월 31일에 방향을 바꿨어요.

• 사전조사, 혼잡도, QR 대기번호를 뺐어요.
• 손님 앱으로 NFC 주문, 결제, 현장 픽업을 해요.
• 웹은 운영사 대시보드와 현장 직원 화면으로만 써요.
• 판매 예측은 핵심 기능으로 남기되, 데이터와 방식은 다시 정해요.

PRD를 새로 쓰고, 팀이 3주 동안 만든 방문객 화면과 파이프라인, 리포트 AI 해설을 지웠어요. 옛 문서와 코드는 git 기록에만 남겼어요. 그리고 README의 결정 기록에 무엇이 끝났고 무엇이 이어지는지를 한 줄씩 적었어요. 그래야 세 명이 같은 그림을 볼 수 있었어요.

두 번째 팝업온: 매대에서 고르고, 카운터에선 받기만

새 방향에서는 손님 앱을 처음부터 만들었어요. React Native(Expo)로 안드로이드부터 시작했고, 앱 디자인은 시안을 세 개씩 그려 비교해서 골랐어요.

제가 맡은 것은 이래요.

• 안드로이드 앱 1단계: 화면 6개를 만들고 웹에서 만든 행사를 읽어 오게 했어요.
• 앱 주문을 서버로 옮기기: 주문이 DB에 저장되고, 직원이 웹에서 '포장 완료'를 누르면 손님 앱에 바로 뜨게 했어요(Supabase Realtime).
• 주문 처리 DB 함수: 재고, 품절, 1인 구매 제한을 확인하고 재고를 줄인 뒤 픽업 번호를 매겨요. 품목 재고 행을 잠가서 두 사람이 같은 마지막 재고를 동시에 사지 못하게 했어요. 재고가 0이 되면 자동으로 품절이 돼요.
• 운영사 대시보드: 실제 주문으로 매출, 품목별 판매와 남은 재고, 시간대별 주문, 결제부터 수령까지 걸린 시간을 보여 줘요.

손님 정보는 처음 방향 때처럼 최소로 받아요. 손님은 소셜 로그인으로만 구분하고 전화번호와 위치는 받지 않아요. 카카오 로그인은 닉네임만 받아요. 판매자 화면에는 픽업 번호, 품목, 수량, 상태까지만 보이고 손님 계정 정보는 넘기지 않아요.

막혔던 곳: 결제

가장 오래 붙잡은 건 결제였어요. 먼저 정한 원칙은 "돈은 팝업온을 거치지 않고 운영사에게 바로 간다"였어요. 팝업온은 대금을 받거나 정산하지 않고, 운영사가 자기 PG 계정으로 결제를 받아요.

PG는 KG이니시스, 토스페이먼츠, NHN KCP, 나이스페이먼츠를 비교했어요. 앱 개발만 보면 React Native 공식 SDK가 있는 토스페이먼츠가 더 맞는다는 의견도 있었지만, 카드와 카카오페이·토스페이를 한 결제창에서 받을 수 있는 KG이니시스로 정했어요. 대신 서버 결제 코드는 나중에 PG를 바꿔 끼울 수 있게 나눠 두기로 했어요.

조사하면서 예상하지 못한 벽이 계속 나왔어요.

• KG이니시스의 입점 제한 업종에 피규어, 랜덤박스, 예약상품이 있어요. 굿즈 팝업에서 많이 파는 것들이라, 운영사가 가맹을 받을 수 있는지부터 확인해야 해요.
• 결제 요청에 구매자 이름이 꼭 들어가야 해요. 그런데 팝업온은 손님에게 이름을 따로 묻지 않아요. 무엇을 넣을지 아직 정하지 못했어요.
• 가상계좌는 입금 전까지 결제가 확인되지 않아서, 결제가 끝나면 바로 픽업 번호를 주는 흐름과 맞지 않았어요. 그래서 뺐어요.
• 실물 굿즈는 앱스토어 인앱 결제가 아니라 PG로 받아야 해요.

그래서 지금 앱의 결제는 누르면 통과하는 가짜예요. 결제를 뺀 나머지 흐름(태그 → 고르기 → 주문 → 포장 완료 → 수령)을 먼저 끝까지 이어 두고, 결제는 확인할 것들을 정리해 실증 전에 붙이기로 했어요.

결과

• 국민대 2026-2학기 창업동아리에 선정되어 지원금 300만 원을 받았어요.
• 10월 12일 PRD 첫 줄부터 11월 초까지 3주 남짓 동안 팀이 PR을 55개 머지했어요.
• 방향 전환 뒤 손님 앱에서 주문하면 웹 현장 화면에 뜨고, 직원이 포장 완료를 누르면 앱에 바로 뜨는 흐름까지 이어졌어요(결제는 가짜).
• 안드로이드 앱을 Play Console 비공개 테스트에 올릴 준비를 하고 있어요. 실증 장소와 일정은 아직 정하지 않았어요.

배운 것

• 누가 돈을 내는지를 먼저 정해야 했어요. 고객이 바뀌자 3주 동안 만든 기능 대부분이 필요 없어졌어요.
• 결정 기록이 팀을 붙잡아 줬어요. 세 명이 동시에 PR을 올리며 충돌이 자주 났지만, 결정 기록에 무엇을 왜 바꿨는지 한 줄씩 남겨서 방향을 틀어도 같은 그림을 볼 수 있었어요.
• 결제는 코드보다 계약과 규칙이 먼저였어요. 업종 제한, 필수 정보, 스토어 정책처럼 코드를 쓰기 전에 확인할 것이 훨씬 많았어요.