한 줄 정의
OurNight는 대학 축제 주점과 일일호프의 탐색, 입장, QR 주문, 입금 확인, 조리·서빙, 정산을 하나의 웹 기반 흐름으로 연결하고, 장기적으로 학생 행사팀과 지역 매장을 연결하는 팝업 주점 운영·중개 플랫폼이다.

0x00. Executive Summary

대학 팝업 주점은 짧은 기간에 많은 손님과 초보 스태프가 몰리지만, 주문·입금·조리·서빙 정보는 수기 장부, 구글 폼, 메신저, 구두 전달 등에 흩어져 있다. 이 때문에 주문 누락, 입금 확인 지연, 역할 혼선, 테이블 시간 관리 실패, 재고와 정산 불일치가 발생한다. 손님 역시 행사 정보를 인스타그램·에브리타임 등에서 따로 찾아야 하고, 현장에 가기 전 메뉴나 혼잡도를 파악하기 어렵다.

OurNight의 첫 번째 제품은 별도 설치 없이 스마트폰과 QR로 쓰는 이벤트용 경량 POS다. 손님 주문을 디지털 티켓으로 만들고, 홀·주방·도어 스태프가 각자의 대기열에서 상태를 갱신하면 행사 전체가 같은 정보를 보게 된다. 두 번째 제품 축은 학교·지역별 팝업 탐색 페이지다. 손님은 주점의 위치, 메뉴, 사진, 공지와 혼잡도를 한곳에서 확인하고 대기·입장 흐름까지 이어갈 수 있다.

0x20. 배경과 문제 정의

0x21. 왜 이 문제인가

팝업 주점은 일반 음식점과 운영 조건이 다르다.

일시적이다. 하루 또는 축제 기간만 운영되어 고가 하드웨어와 장기 계약형 POS를 도입하기 어렵다.
운영자가 비전문가다. 학생 스태프는 당일 짧은 교육만 받고 도어·홀·주방 업무를 맡는 경우가 많다.
환경이 혼잡하다. 소음과 높은 주문 밀도로 구두 전달이 잘 끊기며, 누가 어떤 업무를 맡았는지 추적하기 어렵다.
결제가 분리되어 있다. 주문 접수와 계좌이체 확인이 별도 흐름이어서 주문·입금·제공 상태가 어긋날 수 있다.
정보가 파편화되어 있다. 행사와 주점 정보가 개별 SNS·커뮤니티 게시물에 흩어져 비교와 탐색이 어렵다.

탐색 인터뷰에서는 역할 분담 미숙, 주문과 입금 정보 전달 비용, 시간제한 테이블 관리, 주방 지연, 주문 내역과 정산 내역 불일치가 반복적으로 언급되었다. 한 운영자는 19명의 스태프가 역할을 나눴지만 당일 30분 전 설명을 받고 운영해 혼선이 있었고, 소음 속에서 스태프 간 소통 자체가 어려웠다고 답했다. 이는 문제의 존재를 지지하는 정성 신호지만 표본이 작고 편의 표집이므로 시장 전체로 일반화할 수는 없다.

0x22. 핵심 문제 문장

대학 팝업 주점 운영팀은 짧은 준비 기간과 혼잡한 현장에서 주문·입금·조리·서빙·입장 정보를 한 흐름으로 관리할 도구가 없어, 사고를 막기 위해 더 많은 인력과 반복 확인을 사용한다.

손님은 여러 채널을 오가며 행사 정보를 찾아야 하고, 방문 전에 메뉴·위치·혼잡도를 알기 어려워 탐색 비용과 헛걸음 위험을 감수한다.

0x23. 우리가 풀지 않는 문제

초기 제품은 일반 음식점용 범용 POS, 배달 플랫폼, 주류 판매 주체, 회계·세무 시스템이 아니다. 또한 자동 입금 확인과 PG 결제는 법무·정산·연동 리스크를 검토하기 전까지 핵심 전제로 두지 않는다. 초기에는 주문 상태와 입금 확인 상태를 분리해 기록하는 수동 승인 방식을 안정적으로 제공한다.

0x30. 제품 비전과 원칙

0x31. Vision

“대학생 누구나, 언제 어디서든 쉽고 투명하게 행사를 주최하고 즐길 수 있는 대학 이벤트 운영·중개 플랫폼.”

0x32. Product Principles

현장 우선: 예쁜 화면보다 주문 누락과 상태 불일치를 줄이는 것이 먼저다.
설치 장벽 최소화: 손님은 QR로 즉시 진입하고, 스태프는 모바일·태블릿 웹에서 역할별 화면을 쓴다.
하나의 상태, 하나의 책임자: 주문·입금·조리·서빙 상태와 담당자를 명확히 표시한다.
실패해도 운영은 계속: 네트워크 지연, 잘못된 승인, 품절, 환불 등 현장 예외를 정상 흐름만큼 중요하게 다룬다.
검증 뒤 확장: 자동화·매칭·추천보다 반복 가능한 현장 성공 사례를 먼저 만든다.

0x40. 사용자와 가치 제안

사용자	해야 하는 일	현재의 고통	OurNight의 가치
학생 주최자·운영총괄	행사를 만들고 인력·메뉴·테이블·매출을 관리	초보 스태프 교육, 주문·재고·정산 불일치, 운영 상황 파악 실패	행사 설정, 역할별 화면, 실시간 상태, 주문·환불·매출 기록
도어 스태프	대기와 입장, 재입장을 관리	만석·대기 순서·입장권 확인이 수기	대기 티켓, QR 검증, 입장 상태 전환
홀 스태프	주문 승인, 입금 확인, 서빙, 요청 처리	소음 속 전달, 중복 처리, 담당 불명확	입금·서빙·요청 대기열과 담당자 표시
주방 스태프	조리 순서와 품절을 관리	주문 순서 혼선, 홀과의 반복 확인	조리 티켓 보드, 상태 전환, 실시간 품절
손님	주점을 찾고 입장·주문·진행 상황을 확인	정보 파편화, 대기 불확실성, 주문 진행 확인 불가	통합 탐색, 메뉴·혼잡도, QR 주문, 상태 확인
지역 매장	유휴 시간에 단체 수요를 받고 안전하게 운영	행사팀 접근과 홍보 채널 부족, 초보 운영팀 리스크	검증된 행사팀 연결, 표준 운영 도구, 운영 기록

0x50. 제품 구조

0x51. 핵심 제품 루프

Host setup: 주최자가 행사·장소·테이블·메뉴·계좌·스태프 권한을 설정하고 QR을 발급한다.
Discover & enter: 손님이 학교·지역·행사 페이지에서 주점을 찾고, 혼잡도를 확인해 대기 또는 입장한다.
Order & confirm: 테이블 QR로 주문하고 계좌이체한다. 홀 스태프가 입금을 확인해 주문을 확정한다.
Cook & serve: 주방이 조리 상태를 바꾸고, 홀 스태프가 완성 주문을 서빙 처리한다.
Operate & learn: 운영총괄이 매출·주문·환불·품절·처리시간을 확인하고 다음 행사에 반영한다.

0x52. 역할별 핵심 여정

1. 손님

축제/지역 진입 → 주점 탐색 → 상세·메뉴·혼잡도 확인 → 대기 신청 → 입장 → 테이블 QR → 장바구니 → 주문서 생성 → 계좌이체 → 주문 확정 확인 → 조리/서빙 상태 확인

2. 주최자·운영총괄

행사 생성 → 장소·운영시간 입력 → 테이블 정의 → 메뉴·재고 등록 → 입금 계좌 설정 → 스태프 초대·권한 배정 → QR 패키지 배포 → 운영 모니터링 → 마감·정산

3. 도어·홀·주방 스태프

Door: 대기 발생 여부 설정, 입장권/QR 확인, 입장·재입장 처리
Hall: 입금 확인, 주문 승인·취소·추가, 서빙 완료, 손님 요청 처리
Kitchen: 신규 주문 접수, 대기→조리→완료 상태 전환, 품절 처리

0x53. 주문 상태

작성 중 → 입금 확인 대기 → 주문 확정 → 조리 대기 → 조리 중 → 조리 완료 → 서빙 완료

종료 상태는 고객 취소, 운영 취소, 환불 대기, 환불 완료로 분리한다. 주문 취소와 환불은 같은 사건이 아니므로 각각 처리자·시각·사유를 남긴다.

0x54. 입장 상태

탐색 → 대기 신청 → 호출/입장 가능 → 입장 완료 → 퇴장을 기본으로 하고, 대기 취소, 노쇼, 재입장 가능/완료를 예외 상태로 둔다.

0x55. 권한

운영총괄: 모든 설정·조회·정정
Door: 대기·입장 상태
Hall: 입금 확인·주문 확정·서빙·요청
Kitchen: 조리 상태·품절
Viewer: 대시보드 읽기 전용

한 사람이 여러 역할을 가질 수 있지만, 각 변경은 실제 처리 역할과 사용자 ID를 함께 기록한다.

0x60. 비즈니스 모델

OurNight는 운영 솔루션으로 현장에 진입하고, 장기적으로 공간 중개에서 더 큰 수익을 만드는 2-Track 모델을 가정한다.

0x61. 행사 단위 솔루션 이용료

과금 대상: OurNight 운영 도구를 사용하는 일일호프·축제 주점
과금 방식 가설: 행사 1회당 고정 요금, 기능/주문량별 요금, 학교 단위 계약
원문 예시: 행사당 9,900원 수준이 언급되지만 검증된 지불의사 가격은 아니다.
검증 질문: 무료가 아니어도 다시 쓰는가, 누가 결재권자인가, 축제 주점과 일일호프의 지불의사가 다른가

0x62. 장소 매칭 수수료

학생 행사팀에 유휴 시간대의 지역 매장을 연결
매장으로부터 고정 중개료 또는 행사 매출의 일정 비율 수취
초기에는 거래 구조, 책임 범위, 취소·보증금·파손·주류 판매 관련 법무 검토가 선행되어야 한다.

0x63. 확장 수익 가설

학교·축제 단위 운영 라이선스
고급 분석, 반복 행사 템플릿, CRM 등 Host Pro 기능
공동 개최 팀 매칭 프리미엄

수익모델은 아직 가설 단계다. PMF 판단 전에는 복잡한 요금제를 만들기보다 행사당 지불의사와 공간 매칭의 실거래 구조를 검증하는 것이 우선이다. 팝업 주점 플랫폼, OurNight

0x70. Go-to-Market

0x71. Beachhead

첫 시장은 서울 대학가의 소규모 일일호프와 축제 주점이다. 기존에 개최가 확정된 행사를 찾아 운영 도구를 제안하고, 가까운 지역에서 현장 지원이 가능한 팀부터 시작한다.

0x72. 도입 순서

이미 예정된 행사 확보: 개최 의지가 있는 학생회·동아리·학과 주점에 무료 또는 지원형 파일럿 제안
성공 사례 제작: 처리시간, 오류, 운영자 후기와 현장 영상을 남김
학교 단위 확장: 총학생회·축제준비위원회에 통합 안내 페이지와 운영 표준 패키지 제안
Venue 공급 확보: 비축제 기간의 단체 수요를 원하는 지역 매장 등록
반복 행사와 매칭: 축제 밖 일일호프를 상시 공급해 계절성을 낮춤

주최자에게는 “회비 마련과 우리 이름의 행사”라는 욕망을, 매장에는 “비어 있는 평일의 단체 매출”을 제시하되, 영업 메시지는 기능 나열보다 운영 리스크 감소와 준비 시간 절감을 증명해야 한다. Team Wiki

0x80. 단계별 로드맵

Phase 1 — 운영 코어 검증

주문–입금확인–조리–서빙 닫힌 루프 완성
주최자 셀프 세팅과 역할별 권한
소규모 일일호프 파일럿과 운영 기준선 수집
종료 조건: 개발자 개입 없는 행사 마감, 치명적 주문 유실 0건, 재사용 의향 확인

Phase 2 — 축제 규모 안정화

대기·입장, 탐색 지도/리스트, 테이블·현장 예외 고도화
동시접속·상태 동기화·복구 테스트
여러 주점의 통합 안내와 학교 단위 영업
종료 조건: 다중 부스 운영, 장애 대응 절차, 학교/행사 운영자의 반복 도입 합의

OurNight; Product Planning