Party Passport

배경

2026 I/O Extended: Hack the Beat는 개발 시간이 3시간 남짓인 해커톤이었고, 주제는 "파티를 더 잘 즐길 수 있는 서비스 만들기"였습니다. 가장 큰 특징은 심사위원이 사람이 아니었다는 점입니다. 창업가·엔지니어·투자자 역할의 AI 에이전트가 세 번씩 채점하고, Playwright가 배포 링크에 접속해 실제로 작동하는지 확인했습니다.

그래서 팀 4인큐(서새찬·홍의민·백지훈·이예람)는 제품을 만들기 전에 채점 기준부터 분석했습니다. 짧은 시간 안에는 한 사람이 개발하는 편이 빠르다고 보고 구현은 서새찬 님이, 아이디어와 기획은 제가 맡았습니다.

맡은 역할

• 서비스 아이디어 제안 — 파티 패스포트 주제 제안 문서 작성, v2~v4 개정
• 심사관 페르소나로 기획 검증 — 세 페르소나를 구축해 제 기획안을 리뷰하고 v3에 반영
• 수익 모델 기획 — 정원 초과 유료 옵션, 다음 단계의 연락처 교환 옵션 명세
• 프론트엔드·백엔드 PRD 작성 — 구현 담당 팀원이 따를 화면 문구, API, 데이터 구조

과정

주최 측이 공개한 채점표부터 봤습니다. 심사에 그대로 쓸 채점표가 미리 공개됐습니다. 12개 항목을 0~10점으로 매기고, 세 영역을 가중 합산한 뒤 주제 적합성을 배율로 곱합니다.

• 작동 여부 (34%) — 핵심 흐름 완주, 배포 안정성, 기획안과 구현의 일치, 완성도. 브라우저 검증 결과로만 채점합니다.
• GTM 전략 (33%) — 타깃 고객, 첫 유입 채널, 파티형 확산 구조, 재방문 이유
• 비즈니스 가능성 (33%) — 수익 모델, 시장 규모, 차별점, 운영 비용
• 주제 적합성 (배율) — 더하지 않고 곱합니다. 주제와 멀면 총점이 최대 0.35배까지 줄어듭니다.

채점표 본문에는 점수 상한도 숨어 있었습니다. "~할 계획"처럼 의도만 적으면 5점, 기획안에 쓴 기능이 브라우저에서 확인되지 않으면 그 기능에 기댄 항목은 6점을 넘을 수 없었습니다.

채점표를 거꾸로 따라가 심사관 페르소나부터 만들었습니다. 실제 심사 에이전트의 프롬프트는 비공개라, 채점표와 운영진 설명으로 창업가·엔지니어·투자자 3명을 설계했습니다. 세 페르소나 모두 12개 항목을 전부 채점하고, 무엇을 근거로 인정하는지만 다릅니다. 최종 점수는 세 심사관의 평균이라, 한 명에게만 잘 보이면 점수가 3분의 1만 오릅니다.

• 창업가 — 첫 사용자 100명을 어디서 누가 데려오는지, "단톡방·인스타로 이미 되는 거 아니야?"를 묻습니다. 기획안에 쓴 기능이 앱에 실제로 있는지도 확인합니다.
• 엔지니어 — 브라우저 검증 기록만 믿습니다. 제출한 3단계가 모두 성공했는지, 에러는 없는지, 기획안의 기능이 화면에서 확인되는지를 봅니다.
• 투자자 — 숫자 없는 문장은 인정하지 않습니다. 누가·언제·얼마를 내는지, 시장 규모를 직접 계산했는지, 대체재를 이름으로 댈 수 있는지를 봅니다.

파티에 모이는 이유를 새로운 인연으로 봤습니다. 사람들이 파티에 가는 가장 큰 목적은 새로운 사람을 만나는 데 있다고 생각했습니다. 그런데 막상 가면 처음 보는 사람에게 말 걸 계기가 없어, 아는 사람하고만 이야기하다 돌아옵니다. "인스타 좀 주실래요?"처럼 바로 연락처를 묻는 것도 부담스럽습니다. 그래서 말을 거는 일 자체를 게임으로 만든 파티 패스포트를 제안했습니다.

• 피크민의 수집 느낌 — 피크민이 걸음 수를 모으듯, 대화한 사람과 서로 QR을 태그해 "만난 사람 수"를 모읍니다. 많이 만날수록 내 캐릭터가 새싹에서 꽃으로 자랍니다.
• 포켓몬 GO의 획득 느낌 — 첫 만남, 3명, 참가자 절반처럼 기준을 넘길 때마다 증표를 얻고, 증표는 다음 파티에도 남습니다. "증표 받으려면 3명은 만나야 해"가 말 걸 핑계가 됩니다.
• 소개팅 앱의 장점 — 참여할 때 관심사를 고르면, 1:1 미션 상대와 겹치는 관심사가 대화 소재로 뜹니다. 파티가 끝나면 다시 만나고 싶은 사람을 몰래 고르고, 서로 고른 사이에만 결과를 보여 줍니다.

아이디어도 채점표로 골랐습니다. 팀원들이 낸 아이디어 7개를 완벽히 구현한다고 가정하고 하나씩 채점했고, 최고점은 파티 패스포트였습니다. 확산 구조 항목은 "초대·동반 참여 없이는 제품이 성립하지 않아야 10점"인데, 파티 패스포트는 만남이 곧 제품이라 혼자서는 쓸 수 없습니다. 모든 동작을 브라우저에서 확인할 수 있다는 점도 맞았습니다.

첫 채점에서 투자자 점수가 가장 낮았습니다. 기획안을 세 페르소나로 채점하니 10점 만점에 창업가 6.4, 엔지니어 7.2, 투자자 3.8이었습니다. 투자자가 엄격히 보는 수익 모델과 차별점이 약했고, 엔지니어는 초대 링크로 들어오기만 해도 "만남"이 기록된다고 지적했습니다. 이 지적을 반영해 기획안을 고쳤습니다(v3).

기술적 결정

"만남"은 사용자가 직접 확인한 기록만 인정

• 상황v2는 초대 링크로 참여하면 초대한 사람과 자동으로 "만남"이 기록됐습니다.
• 문제원격으로 들어와도 만남이 쌓여 핵심 숫자를 믿을 수 없다는 것이 엔지니어 페르소나의 지적이었습니다.
• 결정v3 기획안에서 자동 기록을 없애고, 상대의 4자리 코드를 받아 지금 만났어요를 눌러야 기록되게 했습니다.
• 결과구현이 Spring REST 서버로 바뀌면서 제출본에는 자동 기록이 남았고, v4 문서에 결정 대기로 표시했습니다.

수익 모델: 호감 확인 결제 대신 정원 초과 유료 옵션

• 상황처음 생각한 "파티 후 받은 호감을 확인할 때 결제"는 심사 에이전트가 테스트할 수 없어 점수 상한에 걸렸습니다.
• 결정파티 인원이 20명을 넘으면 결제하는 유료 옵션으로 바꿨고, 결제 화면과 서버 쪽 차단은 구현 담당 팀원이 만들었습니다.
• 결과다시 채점하니 점수가 유의미하게 올랐습니다.
• 이후호스트가 켜는 연락처 교환 유료 옵션(9,900원, 서로 선택한 쌍에게만 공개)을 명세했고, 해커톤 시간 안에 구현하지는 않았습니다.

QR을 못 찍는 사용자를 위한 "코드로 태그"

• 상황1차 사용자는 자동화 브라우저였고, 브라우저는 카메라로 QR을 찍을 수 없습니다.
• 결정4자리 코드 입력을 기본 기능으로 PRD에 넣고, 화면 문구도 제출 시나리오와 글자 단위로 맞췄습니다.

결과

• 2026 I/O Extended: Hack the Beat에서 최종 1위를 했습니다.
• 해커톤 현장에서 참가 팀들이 서로의 서비스를 써 보는 시간에 참가자 29명이 서비스를 실제로 사용했습니다. 처음 보는 사람끼리 QR을 찍으며 증표를 모으는, 만들고 싶었던 장면이 그대로 일어났습니다.

배운 점

• 평가자가 시스템이면 채점 기준을 요구사항처럼 다뤄야 합니다. "테스트할 수 없는 결제"를 "화면에서 지나갈 수 있는 결제"로 바꾸는 것만으로 점수가 움직였습니다.
• 제 아이디어도 검증받기 전까지는 가설로 봐야 합니다. 제 기획안도 첫 리뷰에서 3.8점을 받았고, 지적을 받아들여 고친 버전이 최종안이 됐습니다.