L01. 진짜 병목은 코드가 아니다
모듈: 기획 · 2시간
오늘의 질문
나는 왜 빠르게 만들었는데 끝까지 못 갔는가?
이 질문에 스스로 답할 수 있으면 오늘 수업은 성공이다.
용어
- meta-layer(메타층) — 코드 바깥에 있어야 하는 것들. 결정·검증·범위. 집으로 치면 설계도와 허가서.
- data-vs-code(데이터 vs 코드) — 실행 중 바뀔 수 있는 값(데이터)과 고정된 지시문(코드)을 구분하는 시각.
- decision-bottleneck(결정 격차) — 만들기는 빠른데 "무엇을 만들지"를 늦게 정해 막히는 현상.
- AI의 6가지 도움 — 바이브 코더가 AI에게서 실제로 받아야 하는 여섯 종류의 지원.
쉬운 이야기
친구가 이케아 책장을 산다. 조립은 빠르게 끝냈다. 그런데 다음 날 보니 벽에 맞지 않는다. 치수를 미리 안 잰 것이다. 나사를 더 잘 조이는 기술이 문제가 아니었다. 재기 전에 조립을 시작한 것이 문제였다.
바이브 코딩도 똑같다. AI는 나사를 빠르게 조여 준다. 하지만 "어디에 놓을 책장인지", "몇 칸이 필요한지", "옮길 때 어떻게 하는지"는 AI가 대신 정해 줄 수 없다. 그것이 메타층이다.
케이스 스터디에서 반복된 패턴이 있다. 결정을 뒤늦게 내리고, 검증을 믿지 못하고, 범위가 조용히 커진다. 이 세 가지는 코드 문제가 아니라 메타층 문제다.
여기서 "데이터 vs 코드" 실을 한 번 건드리자. 어떤 것이 고정돼야 하고(코드처럼), 어떤 것이 바뀔 수 있어야 하는지(데이터처럼) — 이 구분을 설계 단계에서 하지 않으면 나중에 모든 것을 다시 짠다.
실제 파일
아래 파일들을 열어 직접 눈으로 확인한다.
① 병목 분석 원문
파일: docs/vibe-coder-bottleneck-analysis.md
찾을 것: "핵심 인사이트 7" 섹션. 7개 중 1번을 읽는다.
예시로 보이는 것:
1. **병목은 결정.** 결정을 앞으로 당기고(interview), 안 정한 건 보이게(uncertainty ledger).
② AI 6가지 도움 표
파일: docs/ai-vibe-coding-support.md
찾을 것: "Part 1 — 필요한 6가지 도움" 표.
예시로 보이는 것:
| ① 결정 이끌어내기 | 7가지 결정을 모른 채 지나침 | interview — 빌드 전 결정을 질문으로 끌어내 계약으로 고정 |
③ 생애주기 전체 그림
파일: docs/product-lifecycle-for-vibe-coders.md
찾을 것: "0. 전제 — 바이브 코더의 불변 제약" 3가지 항목.
예시로 보이는 것:
1. 코드/시스템 세부를 **못 읽는다** → 평가 불가
따라 하기
강사와 함께 contract-forge를 한 바퀴 구경한다. 실습은 안전한 임시 폴더를 쓴다.
5-1. contract-forge가 무엇을 만드는지 살펴보기
아래 명령은 예제 입력을 읽어 계약 산출물을 만드는 명령이다.
node ./bin/contract-forge.mjs generate \
--input ./examples/hackathon-ai-tutor/input.json \
--out ./tmp-learning-output
실행 후 보이는 것 (예시):
✓ Generated: tmp-learning-output/prd.md
✓ Generated: tmp-learning-output/feature-contracts.yaml
✓ Generated: tmp-learning-output/capability-matrix.yaml
✓ Generated: tmp-learning-output/pm-seed.json
...
흔한 오류: tmp-learning-output 폴더가 없다고 나오면 mkdir tmp-learning-output을 먼저 실행한다.
5-2. 리뷰 게이트 구경하기
아래 명령은 "됐다"를 기계가 판정하는 리뷰 명령이다.
node ./bin/contract-forge.mjs review \
--input ./examples/hackathon-ai-tutor/input.json
실행 후 보이는 것 (예시):
PASS prd.md — required sections found
WARN pm-seed.json — 2 decide-later items without owner
...
흔한 오류: input.json이 없다고 나오면 경로를 ./examples/hackathon-ai-tutor/input.json으로 정확히 입력했는지 확인한다.
5-3. 내 프로젝트를 "코드 문제 / 메타층 문제"로 분류하기
강사가 칠판에 두 칸 표를 그린다. 수강생은 과거 멈춘 프로젝트 하나를 골라 아래 질문에 답한다.
- 멈춘 이유가 "기능을 못 만들었다"인가? → 코드 문제 칸
- 멈춘 이유가 "무엇을 만들지 헷갈렸다", "팀원과 기준이 달랐다", "언제 끝인지 몰랐다"인가? → 메타층 문제 칸
혼자 하기
과제: 내 멈춘 프로젝트 분석표 작성
아래 빈칸을 채운다.
프로젝트 이름: _______________________
멈춘 시점: _______________________
멈춘 이유 (솔직하게 한 문장): _______________________
분류 (하나에 O 표시):
[ ] 코드 문제 — 기능을 기술적으로 못 만들었다
[ ] 메타층 문제 — 결정·검증·범위에서 막혔다
[ ] 둘 다
메타층 문제였다면, 구체적으로 어디서 막혔나:
[ ] 무엇을 만들지 정하지 못했다 (결정 격차)
[ ] 됐는지 아닌지 모르겠다 (검증 불신)
[ ] 만들 것이 계속 늘어났다 (범위 폭주)
실패
실패 1 — "코드는 됐는데 끝이 없다"
아래 상황을 읽고, 왜 위험한지 한 문장으로 말해 보라.
3주 동안 AI와 함께 기능을 40개 만들었다. 그런데 아직도 뭔가 부족한 느낌이다. 언제 끝인지 모르겠다.
왜 위험한가: 성공 기준(done의 정의)을 처음부터 정하지 않으면, 영원히 "조금만 더"가 반복된다.
실패 2 — false certainty(거짓 확신) 체험
아래 문장이 확정인가, 가정인가?
"사용자는 하루에 10번쯤 이 기능을 쓸 것이다."
이것은 가정이다. 누가, 언제, 어떤 데이터로 확인할지가 없으면 "10번"은 숫자처럼 보이는 희망사항이다. 이런 문장을 그냥 넘기면 나중에 메타층 전체가 틀린 전제 위에 서게 된다.
보완
분석표를 작성했는데 "코드 문제"가 하나도 없다면?
- 정직하게 다시 돌아본다. 코드 문제가 0개인 경우는 드물다.
- 반대로 코드 문제만 가득하다면, 메타층이 너무 잘 됐거나 아직 그 단계를 안 만난 것이다.
[실: 데이터 vs 코드] 지금 작성한 분석표는 데이터다. 고정된 코드가 아니라 언제든 다시 쓸 수 있는 값이다. 프로젝트가 바뀌면 이 표도 바뀐다. 그래서 파일로 저장해 두는 것이 의미 있다.
축소 전략
시간이 부족하거나 막혔을 때 핵심 약속을 살리는 방법(downscope).
- 큰 비전 → 수직 슬라이스 하나: "10개 기능 앱" 대신 "사용자 1명이 처음부터 끝까지 쓸 수 있는 기능 1개". 슬라이스 하나가 완주되면 나머지는 반복이다.
- 정교한 분류표 → 멈춘 이유 한 줄: 분석이 어려우면 "왜 멈췄나?" 한 줄만. 그것만 있어도 다음 프로젝트가 달라진다.
- contract-forge 전체 구경 → generate만: 시간이 없으면 generate 명령 하나만 실행해 산출물 목록을 눈으로 보는 것으로 대체한다.
워크시트
대응 워크시트: ../worksheets/W01-why-meta-layer.md
워크시트에서는 멈춘 프로젝트 분류표와 AI 6가지 도움 매핑표를 직접 완성한다. 수업 중 혼자 하기 과제와 연결된다.
동료 리뷰
짝과 서로 아래 질문으로 점검한다. "예/아니오"로 빠르게 확인한다.
- 분류표에서 "메타층 문제"와 "코드 문제"를 구분할 수 있는가? 구분 기준을 한 줄로 설명할 수 있는가?
- false certainty 예시(실패 상황 2)에서 "확정"과 "가정"의 차이를 자기 말로 설명할 수 있는가?
- AI 6가지 도움 중 내 멈춘 프로젝트에 가장 필요했던 것이 무엇인지 하나 이상 말할 수 있는가?
단어장
| 용어 | 내 말로 설명 (직접 채우기) |
|---|---|
| meta-layer(메타층) | |
| data-vs-code(데이터 vs 코드) | |
| decision-bottleneck(결정 격차) | |
| false certainty(거짓 확신) |
증거 점검 질문: "결정 격차 때문에 멈췄다"고 말하려면 어떤 증거가 있어야 하는가? 내 분류표에 그 증거가 있는가?
예고
다음은 L02. 아이디어는 아직 제품이 아니다.
오늘 "메타층이 빠져 있다"는 것을 알았다면, 다음 시간에는 그 메타층의 첫 번째 블록인 문제 정의·사용자·목표·MVP 경계를 직접 만든다. 오늘의 "결정 격차"가 다음엔 "결정을 어떻게 채울 것인가"로 이어진다.
목표
내 멈춘 프로젝트 1개를 "코드 문제 / 메타층 문제"로 분류하고, AI 6가지 도움 중 내게 필요한 것을 특정한다.
작성란
A. 멈춘 프로젝트 분류표
아래 칸을 직접 채운다.
| 항목 | 내용 |
|---|---|
| 프로젝트 이름 | |
| 멈춘 시점 | |
| 멈춘 이유 (한 문장) |
분류 (해당하는 것에 O 표시):
[ ] 코드 문제 — 기능을 기술적으로 못 만들었다
[ ] 메타층 문제 — 결정·검증·범위에서 막혔다
[ ] 둘 다
메타층 문제였다면, 구체적으로 어디서 막혔나 (해당 항목에 O 표시):
[ ] 무엇을 만들지 정하지 못했다 (결정 격차)
[ ] 됐는지 아닌지 모르겠다 (검증 불신)
[ ] 만들 것이 계속 늘어났다 (범위 폭주)
[ ] 기타: ___________________________
B. false certainty 점검
내 멈춘 프로젝트에서 "가정인데 확정처럼 썼던 문장"을 하나 찾아 쓴다.
원래 문장:
(직접 적기)
왜 가정인가 (누가·언제·어떤 데이터로 확인해야 하는가):
(직접 적기)
C. AI 6가지 도움 매핑
아래 표의 "내 프로젝트에 있었나?" 칸에 O(있었다) / X(없었다) / ?(모르겠다)를 표시한다.
| 도움 | 한 줄 설명 | 내 프로젝트에 있었나? |
|---|---|---|
| ① 결정 이끌어내기 | 빌드 전에 7결정을 질문으로 끌어내기 | |
| ② 믿을 수 있는 게이트 | 기계가 pass/fail로 판정 | |
| ③ 가드레일 | AI 표류·비밀유출·범위 확장 방지 | |
| ④ 번역 레이어 | 기술 상태를 평어로 통역 | |
| ⑤ 빠진 것 비평 | "이게 빠졌어요"를 먼저 말해주기 | |
| ⑥ 폴백 + 에스컬레이션 | 막히면 대안 경로 + 사람에게 신호 |
내 프로젝트에서 가장 없었던 도움 (번호로):
(직접 적기)
그 도움이 있었다면 어떻게 달랐을까 (한 문장):
(직접 적기)
D. 데이터 vs 코드 점검 (한 줄)
내 멈춘 프로젝트에서 "고정돼야 했는데 계속 바뀐 것" 하나를 적는다.
(예: 성공 기준 / 대상 사용자 / 핵심 기능 정의 등)
E. 축소 전략 (downscope)
만약 그 프로젝트를 다시 시작한다면, "큰 비전 → 수직 슬라이스 하나"로 줄이면 무엇이 되는가?
수직 슬라이스 한 줄:
사용자 _______가 _______를 할 수 있다.
자가 점검
제출 전 스스로 확인한다.
- [ ] 분류표의 "멈춘 이유"가 한 문장으로 구체적으로 적혀 있다
- [ ] false certainty 문장이 실제 내 프로젝트에서 가져온 것이다 (꾸며낸 예시 금지)
- [ ] AI 6가지 도움 매핑표에 O/X/? 가 모두 채워져 있다
- [ ] 증거 없는 완료 금지: "메타층 문제였다"고 분류했다면, B란(false certainty)이나 C란(도움 매핑)에 그 근거가 하나 이상 있는가?
- [ ] 실패 시 축소: E란의 수직 슬라이스가 "한 명의 사용자가 처음부터 끝까지 쓸 수 있는 기능 하나"로 좁혀져 있는가?
제출 기준
아래가 모두 있으면 통과한다.
- A란: 프로젝트 이름, 멈춘 이유, 분류 O 표시 완료
- B란: 가정 문장 1개 이상 작성
- C란: 6가지 도움 전부 O/X/? 표시 + 가장 없었던 도움 번호 기재
- D란: "고정돼야 했는데 바뀐 것" 1개 이상
- E란: 수직 슬라이스 문장 작성
워크시트를 제출하려면 로그인이 필요해요.