6단계 · 프로토타이핑 (prototype-build)
문장부호: 출력에
(em-dash)를 쓰지 않는다. 쉼표나 마침표로 끊는다.
목적
솔루션 MVP를
실제로 클릭되는 기준선 데모(
)로 만들고, 팀의 MVP에 맞는 방식으로
Codex Sites에 공개 배포해 URL까지 만든다(배포가 안 되면
으로 대체, 아래 완료 판정). 공개 URL의 핵심 데모 흐름은 심사위원과 다른 팀이
ChatGPT 로그인 없이 자기 폰으로 열 수 있어야 한다. 발표 덱은 이 스킬이 아니라
담당. 오피스아워 피드백으로
여러 번 반복한다.
이 단계의 역할
주도: Red · 찌르는 사람: Green · Blue는 화면에 뜬 숫자를 지킨다
만드는 손과, 정의서에서 벗어나는지 보는 눈.
의
에서
이름을 읽어 세 명 다 부른다. 시작할 때 소리내어 배분한다.
🔴 Red: 주도. 기준선을 만들고 배포까지 끌고 간다. "이 화면 열면 사용자가 제일 먼저 누르는 게 뭐예요?"
🟢 Green: MVP 정의서에서 벗어나는지 본다. "이거 정의서에 있던 거 맞아요?"
🔵 Blue: 화면에 뜬 수치·장소가 4단계 실측인지, 예시면 예시라고 붙었는지 확인한다. "이 숫자 어디서 왔어요? 기준시점은요?"
한 명에게 쏠리면 찌르는 사람을 이름으로 호명한다. 2인 팀이면 Red는 공동이다.
진행 순서 (한눈에)
기준선 만들기 → 배포 방식 결정(정적 보존/동적 앱) → 선택한 원본에서 구현·반복 → 공개 배포 → 로그아웃·팀 휴대폰 검증 → 안 되면 로컬 폴백 검증 → 시간 남으면 다음 계단(선택).
시작 전
이미 완성된
이 있고 요청이
화면 제작·수정이 아니라 Sites 배포만이라면 아래 제작 선행조건과 화면 질문을 다시 요구하지 않는다. 원본의 핵심 기능·비밀값·개인정보만 확인하고
로 바로 간다.
⚠
를 먼저 거쳤나? 핵심 기능이 1개로 좁혀지고 🔴 위험이 정리돼 있어야 한다. 안 했으면 지금이라도 하고 오는 게 빠르다.
- 의 ···(idea-validate 확정본 + 오피스아워 메모) 를 읽는다. 정의서에 없는 기능을 만들자는 말이 나오면 "그럼 정의서부터 고치자"로 되돌린다. 정의서가 계약이다.
- 4단계에서 받은 실제 수치·장소명을 최대한 넣는다. 없으면 현실적인 예시값 + "예시" 표기.
- 디자인은 이미 정해져 있다. ( 산출물)의 CSS 토큰을 그대로 쓴다. 없으면 먼저, 만들면서 색 고민하지 않는다.
먼저 묻기 (필수: 퍼실리테이션)
바로 코드를 뽑지 말고
화면의 내용을 팀에게서 끌어낸다.
디자인(색·무드)은 묻지 않는다. 이미 에 있다.
- "사용자가 이 화면을 처음 열면 뭐가 보여야 해요?" 첫 화면에 뭘 놓을지.
- "뭘 입력하고, 뭘 누르면, 뭐가 나오나요?" 입력 → 처리 → 출력을 팀 말로.
- 꼭 보여줄 핵심 기능 1개를 팀이 짚게(에서 좁힌 것과 일치 확인).
- "우리가 찾은 데이터 중에 화면 어디에 올려야 문제가 한눈에 보일까요?"
답·합의는 에 남긴다.
산출 규칙 (중요)
- 기준선 은 단일 파일: HTML+CSS+JS 한 파일. 외부는 폰트 CDN만(차트 라이브러리 금지, 네트워크가 끊기면 차트만 사라진다. 비교·순위는 인라인 SVG/CSS 막대로). localStorage 등 브라우저 저장소 금지: 상태는 JS 변수/메모리. 동적 앱의 영속 저장은 Sites가 지원하는 서버 쪽 기능으로 별도 구현한다.
- 은 모든 팀의 기준선·오프라인 폴백이다. Sites에 올리기 위한 기술적 이유만으로 React/Next 계열 화면으로 다시 구현하거나 문구·스타일·동작을 바꾸지 않는다.
- 다만 MVP가 인증·DB·서버 API·업로드·실시간 협업처럼 정적 HTML로는 검증할 수 없는 동적 기능을 실제로 요구하거나, 팀이 범위와 시간을 확인한 뒤 제품형 구현을 명시적으로 선택하면 의 동적 앱을 배포 원본으로 삼을 수 있다. 이때 Sites가 지원하는 구조나 기존의 호환 구조를 쓰며, 은 지우거나 덮어쓰지 않는다.
- 모바일에서도 보이게 반응형. 한국어 UI. (배포하면 심사위원이 폰으로 연다. 반응형이 실전이 된다.)
- 기준선 의 데이터는 파일 안에 JS 객체로 넣어 오프라인에서도 데모되게 한다. 동적 앱은 서버에서 최신 데이터를 받아도 되지만, 외부 API가 멈출 때 기준선이나 검증 스냅샷으로 핵심 시연이 이어져야 한다.
- API 키를 HTML·브라우저 번들에 절대 넣지 않는다. 배포하는 순간 전 세계에 공개된다. 동적 앱은 서버 쪽 비밀 설정과 서버 경로를 쓴다.
prototype.html 만들기
- MVP 흐름(입력→처리→출력)을 실제로 클릭되는 화면으로. 최소 1개 핵심 기능이 동작.
- 예: 관심사 선택 → (내장 데이터로) 코스 생성 → 지도/카드 출력.
- 과욕 금지: 발표에서 보여줄 1~2 기능만 완성도 있게.
- 동적 기능이 이미 MVP로 확정됐다면 기준선에서는 그 기능의 입력→결과를 예시 데이터로 명확히 보여주고 라고 표시한다. 정적 화면을 두 번 완성하려고 시간을 쓰지 말고 아래에서 동적 앱으로 전환해 실제 기능을 검증한다.
배포 방식 결정: 필요할 때 한 번만 묻는다
나 팀 요청에서 방식이 이미 분명하면 다시 묻지 말고 선택 결과와 이유만 기록한다. 불분명할 때만 로컬 기준선이 작동한 뒤 이렇게 묻는다.
"우리 핵심 기능에 로그인·저장·서버 API·업로드·실시간 동작이 꼭 필요한가요, 아니면 지금 화면을 공개 URL로 올리면 충분한가요?"
- 공개 URL이면 충분하다 → 정적 원본 보존: 이 구현 원본이다. 는 바이트 단위로 같은 파일을 싣는 최소 포장이다.
- 동적 기능이 MVP 계약에 있다 → 동적 앱: 가 배포 구현 원본이다. Sites가 지원하는 구조나 기존 호환 구조를 쓸 수 있다. 은 배포 전 기준선·오프라인 폴백으로 보존한다.
- 단지 Sites에 올리기 위해서, 또는 프레임워크가 더 그럴듯해 보여서 동적 앱으로 옮기지는 않는다. 반대로 동적 기능이 합의된 MVP인데 원본 보존 규칙을 이유로 막지도 않는다.
동적 앱으로 전환할 때는 아래
제품 계약을 기본값으로 유지한다. 바꿀 이유가 있다면 팀과 합의하고
에 차이를 기록한다.
- 같은 대상 사용자와 문제
- 같은 핵심 기능 1개와 입력→출력 흐름
- 같은 데이터의 의미·출처·한계
- 의 토큰과 핵심 문구
- 정의서 밖 기능을 슬쩍 늘리지 않기
실제 데이터 넣기 (TourAPI·혼잡도)
실제 수치·장소·혼잡도 예보를 화면에 올리고 싶으면
반드시 를 읽고 그대로 한다. 브라우저에서 TourAPI를 직접 부르면 CORS로 실패한다. 정적 기준선은 터미널에서 한 번 받아 HTML에 인라인하고, 동적 앱은 비밀키를 숨긴 서버 경로에서 호출하며 검증 스냅샷을 폴백으로 둔다.
선택한 원본에서 반복 (충분히 다듬기)
- 정적 방식은 을, 동적 방식은 의 앱 소스를 수정한다. 배포용 복사본이나 빌드 산출물을 직접 고치지 않는다.
- 오피스아워·팀 피드백을 받으면 *"어디를 바꾸고 싶어요?"*로 받아 해당 부분만 수정한다. 동적 앱에서 기준선과 달라지는 변경은 이유를 기록한다.
- 매 반복 후 로그에 "vN: 무엇을 고침" 기록.
- 사용자 테스트: 다른 팀·주변 사람에게 눌러보게 하고 "어디서 헷갈렸어요?" → 반영( 연계).
- 시연 예행: 발표에서 보여줄 클릭 순서를 지금 한 번 밟아본다. 결과가 밋밋하거나 클릭이 너무 많으면 지금 고친다. 피칭 준비 단계에서 발견하면 늦다.
배포: Codex Sites (전 팀의 종착점)
핵심 기능 1개가 로컬에서 확실히 돌면 배포한다. 완벽해질 때까지 미루지 말 것: 배포는 반복 중에 몇 번이고 다시 할 수 있고, 일찍 URL을 만들어두면 피드백 받기도 쉬워진다.
- 절차는 를 읽고 따른다.
- 캠프 배포 목표는 고정이다. 소유자 전용·워크스페이스 전용 URL은 발표용 배포 완료로 인정하지 않는다. 공개 작업 직전 필요한 승인만 참가자에게 한 번 받는다.
- 기존
site/.openai/hosting.json
- 배포되면 로그인 정보가 없는 조회에서 실제 서비스 제목과 핵심 데모 흐름이 보이는지 확인한 뒤, 팀 전원이 자기 폰으로 URL을 열어 핵심 기능까지 눌러본다. 제품 자체에 회원 기능이 있어도 발표용 핵심 흐름은 가입 없이 체험할 수 있는 공개 데모 경로를 둔다.
- 배포 방식·URL·공개범위·기준선 검증·로그아웃 접근·휴대폰 확인 결과를 에 기록하고 발표 덱에 넣는다.
- 배포가 막히면 붙잡고 있지 말 것, 5분 안에 안 풀리면 FT를 부르고 폴백으로 간다.
완료 판정: 둘 중 하나면 통과
의
가 아래 둘 중 하나이고, 같은 행의 증거가 모두 있어야 한다.
둘 다 6단계 완료로 인정한다.| 판정 | 조건 |
|---|
| ·· + + + + + 방식별 + + + + + |
| · 정적 | ·· + + + + + + + + + + |
| · 동적 | ·· + + + + + + + 로컬 동적 결과가 담긴 + 실제 실패 조건과 결과가 담긴 + + |
우리 파일은 오프라인에서도 열리게 만들었으니 폴백은 진짜 폴백이다. "포기"가 아니라 검증된 상태로
적고 다음 단계로 간다. 자기 노트북에서만 열어본 건 해당하지 않는다. 남의 기기에서 한 번은 열어본다.
더 가고 싶은 팀에게 (선택: 다음 계단)
여기까지가 이 스킬의 기본 트랙이다. 배포까지 끝났고 시간이 남으면,
에 다음 계단이 있다. 실데이터를 더 깊게(L2), 대화형 에이전트로(L3).
시작 전에 FT에게 "업그레이드 해보고 싶다"고 말하라: 남은 시간 대비 어디까지가 현실적인지 같이 잡아준다.
context.md 갱신
- 에 기준선 경로를 적고, Sites 프로젝트를 만들었다면 에 경로를 적는다.
- 에 · 중 하나를 적는다. 공개 실패 여부는 에 별도로 적는다.
- 에 또는 을 적는다. ·········은
../bootcamp-start/references/_context-template.md
- , 로그 추가.
끝맺음 (여기까지가 6단계: 프로토타입)
- 요약: 파일 경로 + 배포 판정 + 핵심 기능 한 줄.
- 다음은 : 이 화면을 감싸는 발표 덱을 만든다. 이어서 에서 시연 시나리오·대본·리허설까지 피칭 전체를 준비한다. 만든 것과 보여주는 것은 다른 일이다.
- 아직 안 열렸으면 재촉하지 말고 팀과 나눈다:
- "이 데모, 처음 보는 사람이 눌러도 30초 안에 '오' 할까요? 어디가 약해요?"
- "발표 때 이 화면으로 어떤 이야기를 할지 미리 말로 해볼까요?"
자동으로 채우지 않기
- 화면에 뭘 놓을지는 팀에게서 받는다. 첫 화면·입력·출력·강조할 데이터를 묻기 전에 코드를 뽑지 않는다.
- 에 없는 기능을 슬쩍 넣지 않는다. 좋아 보여도 정의서가 계약이다.
넣고 싶으면 "그럼 정의서부터 고칠까요?" 로 되돌린다.
- 데이터는 4단계에서 실제로 받은 값을 쓴다. 없는 걸 그럴듯하게 만들지 않는다.
불가피하면 화면에 "예시" 라고 박는다.
톤·품질
- 한 턴 = 맥락·이유 1문단 + 질문 1개. 질문만 툭 던지지 말고 왜 이걸 묻는지를 먼저 한 문단으로
친절하게 풀어준다. 대신 질문 개수는 늘리지 않는다. 한 번에 여러 개를 물으면 팀이 생각하지 않고
받아적기만 한다.
- AI가 이미 아는 답으로 몰지 않는다. 팀 생각이 틀려 보여도 "아닐까요?" "진짜 그럴까요?" 로
흔들지 말고, 무엇을 보면 알 수 있는지를 묻는다.
- 완성도 > 기능 수. 하나라도 확실히 되는 데모, 그리고 그 데모의 URL.