인공지능(Artificial Intelligence, AI)과 함께하는 제품 개발

AI와 함께 제품을 만드는 창업자의 일하는 법

더 빨리 만드는 것을 넘어,
무엇을 만들지 판단하는 법.

시작 전 준비: 작업할 장소를 구분한다

작업 폴더는 AI가 만든 코드와 문서를 보관할 실제 컴퓨터 폴더입니다. 작업 또는 대화는 AI에게 지시하고 결과를 받는 공간입니다. 대화만 새로 열어도 같은 폴더를 고르면 이전 코드가 남아 있을 수 있습니다.

1. 사용 가능한 Codex (코드를 읽고 수정·실행하는 AI 도구) 환경에서 로그인합니다. 설치 전이라면 공식 시작 안내의 운영체제별 설치·로그인 안내를 따릅니다. 이 교안은 로컬 폴더를 읽고 수정하는 Codex 작업을 기준으로 합니다. 일반 채팅만 되는 화면과 구분하세요.
2. 파일 탐색기 또는 Finder에서 쓰기 가능한 개인 작업 위치에 kakao-ai-practice라는 새 폴더를 만듭니다. 안에 다음 여섯 개의 빈 폴더를 만듭니다. 기존 업무 폴더를 비우거나 지우지 않습니다.

kakao-ai-practice/
  01-first-calculator/
  02-invest-A/
  03-invest-B/
  04-invest-C/
  05-invest-D/
  06-idea-app/

3. 앱에서 프로젝트 또는 폴더를 여는 기능으로 01-first-calculator를 선택하고 새 Codex 작업을 시작합니다. 설치 버전에 따라 명칭은 다를 수 있습니다. 현재 선택한 폴더 이름이 맞는지 확인합니다.
4. 아래 준비 요청을 보냅니다. 답에 나온 경로의 마지막 폴더 이름과, 생성된 LEARNING.md 파일이 실제로 열리는지 확인합니다.

AI에게 입력 — 각 새 실습 작업을 시작할 때 한 번씩

이 폴더는 가상 데이터만 쓰는 AI 제품 개발 실습 공간이야.
현재 작업 폴더의 절대 경로와 기존 파일 목록을 알려줘.
관련 없는 기존 파일이 있으면 바꾸지 말고 알려줘.
이번 실습은 이 폴더 안에서만 하고, 외부 배포·결제·실제 계정 연동·원본 삭제는 하지 마.
허용하지 않은 접근 권한이 필요하면 이유와 대안을 먼저 알려줘.
LEARNING.md가 없으면 만들고, 있으면 내용을 보존해.
내가 직접 적은 관찰과 AI가 확인한 결과를 구분해서 기록할 거야.
아직 제품을 구현하지 마. 생성한 문서를 여는 방법을 알려줘.

1. 강사 소개와 여러분에게 일어날 변화

안녕하세요. 신건호입니다. 현재 ECHO&DELTA를 운영하며 조직 AX 전략, 워크플로 재설계, 기업 교육·강연을 하고 있습니다. 저도 회사를 나와 여러분처럼 창업을 시작한 지 얼마 되지 않았습니다.

커리어 패스 · 현재에서 학부까지

1. 2026.09–현재
   ECHO&DELTA · 대표 NOW

   조직 AX 전략, 워크플로 재설계, 기업 교육·강연을 독립적으로 수행합니다.

2. 2025.01–2026.08
   데이원컴퍼니 · B2B 사업부 본부장

   마케팅·세일즈·CSM·프로덕트·교육 운영·조직/HR·AI/AX 신사업을 포괄하는 B2B 사업을 이끌었습니다.

3. 2024.01–2024.12
   데이원컴퍼니 · B2B 프로덕트 전략팀 팀장 / CFO Staff

   전사 생성형 AI 도입 TF, B2B 제품·교육 전략, IPO 사업 보고서와 IR Deck 작성을 수행했습니다.

4. 2023.07–2023.11
   두잇 · Product Owner

   데이터 분석과 운영 프로세스 개선을 통해 배달 품질과 운영 효율 문제를 다뤘습니다.

5. 2020.10–2023.06
   Kearney Korea · Senior Business Analyst

   성장 전략, 신상품, 디지털 CX, 제조·공정 효율화 프로젝트를 수행했습니다.

6. 2017.01–2020.09
   NICE P&I · Financial Modeling Researcher

   기업·산업 분석과 채권 포트폴리오용 신용평가 모델 개발을 수행했습니다.

7. 2015–2016
   KAIST 경영대학원 · 기술경영·IT 석사

   기술과 경영을 함께 보는 관점을 확장했습니다.

8. 2010–2014
   KAIST · 생명화학공학 학사 / 경영과학 복수전공

   공학적 문제 해결과 경영의 기초를 함께 공부했습니다.

다만 회사에서 여러 일을 하면서 AI를 정말 많이 활용해왔고, 조직에 일을 맡겨 결과를 만드는 경험도 해왔습니다. 그 과정에서 사람에게 일을 잘 맡기는 것과 AI에게 일을 잘 맡기는 것에는 공통된 구조가 있다는 것을 느꼈습니다.

2. 왜 지금 창업자에게 AI 활용이 중요한가

이때 용어를 구분해봅시다.

AI가 구현 시간을 줄여줬다면 남은 시간을 기능 추가로만 채우지 마세요. 고객을 만나고, 고객이 있는 채널에서 제품을 보여주고, 사용하지 않는 이유를 듣고, 다시 사용할지 확인하세요. 제품을 만드는 속도는 현실의 피드백을 받는 속도로 이어질 때 의미가 있습니다.

생각해보기 Q1: 예약 화면을 하루 만에 완성했습니다. “사업 가설을 검증했다”고 말하려면 무엇이 더 필요할까요?

3. 대표의 병목은 ‘일을 정의하는 능력’으로 이동한다

창업 후 투자를 받아 개발팀을 꾸렸다고 생각해봅시다. 대표가 모든 프로그래밍 언어를 개발자보다 잘 알아야 일을 맡길 수 있을까요? 그럴 필요는 없습니다. 대표는 누구를 위해 어떤 제품을 만들지, 어떤 결과를 성공으로 볼지 팀이 이해하도록 설명해야 합니다.

저도 조직에 ‘어떻게 할지(How to)’를 계속 설명하던 때가 있었습니다. 하지만 그보다 중요한 일은 내가 원하는 결과를 상대가 선명하게 그릴 수 있도록 청사진을 제시하는 것이었습니다. 데이원컴퍼니에서 저는 마케터로 일한 적도, 교육 설계 실무를 직접 맡은 적도 없었습니다. 그래도 조직이 만들어야 할 마케팅 성과와 교육 가치는 분명히 말해야 했습니다.

대표가 모든 구현 방법을 알아야 일을 맡길 수 있는 것은 아닙니다. 원하는 결과와 지켜야 할 경계를 설명하고, 합의한 증거로 결과를 판단할 수 있어야 합니다.

AI 개발도 같습니다. 지금은 앱이 약속한 흐름을 수행하는지 확인합니다. 나중에는 고객이 실제로 사용하고 가치를 얻는지 봅니다. AI에게 “매출이 오를 때까지 개발해”라고만 맡기면 당장 확인할 완료 기준도, 개발로 해결할 범위도 모호해집니다.

자기 점검 Q2: 제안서가 예뻐졌지만 고객의 문제와 교육 가치가 연결되지 않습니다. 목표를 달성했나요? 방법 지시 한 가지와 결과 지시 한 가지를 직접 써보세요.

4. 우리는 원래 루프로 일해왔다

사실 일이라는 건 한번의 수행으로 깔끔하게 마무리되지 않습니다. 마케팅팀은 캠페인을 실행하고 지표를 본 뒤 메시지나 채널을 바꿉니다. 개발팀은 구현한 기능을 테스트하고 오류를 고칩니다. 우리는 원래도 루프와 같은 방식으로 일을 해왔습니다.

이처럼 결과를 보고 다음 행동을 정하는 반복을 루프라고 부릅니다. 똑같은 실패를 생각 없이 되풀이하는 것과는 다릅니다. 앞선 결과를 근거로 다음 행동을 유지하거나 조정하는 피드백이 있어야 합니다.

우리가 잘 아는 린 스타트업 방식도 사실은 고객 반응으로 가설을 검토하는 루프다

린 스타트업의 만들기→측정하기→배우기(Build–Measure–Learn)는 제품을 많이 만드는 순서가 아닙니다. 먼저 무엇을 배우려는지 정하고, 고객 가설을 작은 실험과 실제 반응으로 확인하는 과정입니다.

여기서 질문을 바꿔봅시다. 우리는 원래 반복하며 일했습니다. 그렇다면... AI가 일을 하는 방식은 어떨까요?

5. AI가 루프로 일하는 방식. 랄프 루프.

AI가 만든 코드를 보며 “이 오류를 고쳐”, 다음 결과를 보며 “이제 다음 기능을 만들어”라고 사람이 계속 지시하는 방식이 있습니다. 결과를 눈앞에서 조정하기는 쉽지만, AI가 한 단계를 마칠 때마다 사람이 다음 지시를 정해야 합니다. 사람이 계속 붙어 있어야 다음 수정이 이어지는 구조였습니다.

랄프 루프의 등장과 핵심 발견

2025년 7월 14일, Geoffrey Huntley가 공개한 최초의 랄프 루프는 사실상 명령어 한 줄이었습니다.

while :; do cat PROMPT.md | claude-code ; done

같은 PROMPT.md를 코딩 에이전트에게 계속 전달하고, 한 번의 실행이 끝나면 새로운 컨텍스트에서 다시 시작시키는 방식입니다. Huntley의 표현을 옮기면, “Ralph는 하나의 기술이며, 가장 순수한 형태에서는 Bash 루프”입니다. Huntley 원문

핵심 발견은 반복문 자체라기보다, 루프 안에서 AI가 만들어 내는 산출물이 개선되는 방식에 있었습니다. Huntley가 강조한 것은 AI에게 일을 잘 시키려면 처음부터 완벽한 프롬프트와 완벽한 지시를 준비해야 한다는 뜻이 아니었습니다. 오히려 완벽한 프롬프트는 존재하지 않는다고 말합니다. 실행에서 드러난 잘못된 행동 패턴을 관찰하고 프롬프트·명세·계획·검증을 고쳐 다음 반복에 남길 때, 산출물이 점차 나아진다는 것이 핵심이었습니다.

따라서 랄프 루프는 같은 문장을 무작정 되풀이하는 방식이 아닙니다. 쉽게 말하면 “합의한 검증을 통과할 때까지 실행하고 고쳐라”라는 반복 작업 방식입니다. 적합한 수행 능력과 도구가 있는 과제에서 AI가 다음 작업을 고르고 실행·확인·수정을 이어가게 하고, 사람은 방향과 결과 판단에 집중합니다.

예전에 AI에게 지시하던 방식으로 계산기를 만든다면

랄프 루프 이전의 전형적인 대화형 작업에서는 사람이 결과를 한 번씩 확인하고 다음 할 일을 다시 지시했습니다. 계산기 하나를 만든다고 해도 대화는 다음처럼 이어질 수 있습니다.

랄프 루프는 이 반복에서 사람이 맡던 다음 작업 선택·실행·확인·수정의 일부를 AI에게 넘기려는 시도입니다. 사람은 매 단계의 버튼을 누르는 대신, 무엇을 만들고 어떤 결과를 통과로 볼지 정합니다.

실습 1. “계산기 만들어”

1. 준비한 01-first-calculator 폴더의 Codex 작업인지 확인합니다.
2. 입력창에서 /goal을 입력해 Goal 시작 기능을 선택합니다. 화면에서 목표 입력 상태가 되었는지 확인하고 아래 문장을 보냅니다. 이미 기능을 선택했다면 /goal을 중복해서 붙이지 않습니다.

AI에게 입력 — 첫 목표

계산기 만들어.

무엇이 바뀌었는가

바뀐 것은 누가 일하느냐가 아니라, 누가 실행 루프를 계속 운영하느냐입니다.

그런데 한 가지 문제가 남습니다. ‘계산기’라는 단어에 내가 원하는 결과가 충분히 들어 있었을까요?

6. 루프를 시작하기 위한 세 가지 계약

AI의 랄프 루프는 주어진 방향으로 계속 돌 뿐, 무엇을 향해 돌아야 하는지는 사람이 정해줘야 합니다.

목표가 잘못되면 잘못된 결과가 반복됩니다. 제약이 없으면 필요하지 않은 범위까지 일이 커집니다. 검증 기준마저 없으면 그럴듯해 보이는 상태를 완료로 오해하기 쉽습니다. 그래서 사람은 AI 루프를 돌리기 위해 다음 세 가지 요소를 AI에게 알려줘야 합니다.

배달을 맡기는 상황에 빗대면 목적지, 지켜야 할 조건, 배송 완료 확인에 해당합니다. 길을 하나하나 알려주기 전에 이 세 가지부터 정해야 합니다.

Clarify: 가장 자주 일어나는 문제 상황은, '나도 내가 뭘 원하는지 모를 때'

AI가 만든 산출물이 내 마음에 안 든다면, 과장 좀 보태 10번 중 9번은 '나도 내가 원하는 걸 잘 모를 때'입니다. Clarify는 실행에 영향을 주는 모호함을 질문으로 해소하는 과정입니다. 쉽게 말해, AI에게 나를 인터뷰시키는 거에요. 정말 상상 이상으로, 우리는 우리가 무엇을 원하는지 모릅니다. 많은 경우 원하는 게 딱히 없기도 합니다. 동시에, AI는 상상 이상으로 우리가 원하는 게 무엇인지 잘 찾아줍니다. 매우 탁월해요.

AI에게 내가 원하는 것을 clarify하도록 시키려면?

내가 원하는 걸 더 구체화하기 위해 필요한 clarify 질문 5가지와 너의 예상 답변 옵션 3가지를 달아서 나에게 제시해. 인터뷰를 3턴 진행하자. 질문은 15개를 하게 되는 거야.

7. 백문이 불여일견: 투자 계산기를 랄프 루프로 만들어보자

예를 들어 창업 후 투자를 받을 상황을 생각해봅시다. 투자 조건을 바꿔가며 값을 비교하는 계산기가 필요합니다. 투자 실무가 아니라 지시의 차이를 관찰하는 연습입니다. 아래는 실제 투자 판단에 사용하지 않는 단순 산술 모형입니다.

투자 후 가치 = 투자 전 가치 + 신규 투자금
신규 투자자 지분율 = 신규 투자금 ÷ 투자 후 가치 × 100
기존 주주 전체 잔여 지분율 = 투자 전 가치 ÷ 투자 후 가치 × 100

금액은 모두 억원 단위입니다. 투자 전 가치 8에 투자금 2가 더해지면 전체는 10, 신규 투자자는 2/10인 20%, 기존 주주 전체는 80%입니다. 창업자가 기존 지분 전부를 보유한 경우에만 이를 창업자 지분 80%라고 부를 수 있습니다. 옵션·전환증권·세금·기존 주주의 추가 투자 등은 이 모형에 포함하지 않습니다.

실습 2-A. 목표만 주고 제약조건, 완료조건을 주지 않는다면?

02-invest-A 폴더의 새 작업에서 실행합니다.

AI에게 입력

맥락: 나는 창업을 준비하고 있고 추후 투자를 받을 상황까지 고려하고 있다.
목표: 투자를 받을 때 해야 하는 여러 계산이 가능한 html 파일 하나로 동작하는 계산기를 만들어줘.

실습 2-B. 목표와 제약조건만 주고 완료조건을 주지 않는다면?

03-invest-B 폴더의 새 작업에서 실행합니다.

AI에게 입력

상자를 읽기 전에: 응용 프로그램 인터페이스 (Application Programming Interface) · API. 프로그램이 다른 프로그램과 정해진 방식으로 요청과 응답을 주고받는 접점입니다. 이번 제품은 외부 API 연동을 제외합니다.

맥락: 나는 창업을 준비하고 있고 추후 투자를 받을 상황까지 고려하고 있다.
목표: 투자를 받을 때 해야 하는 여러 계산이 가능한 html 파일 하나로 동작하는 계산기를 만들어줘.
제약:
- 브라우저 한 화면에서 사용한다.
- 계산은 투자 후 가치, 신규 투자자 지분율, 기존 주주 전체 잔여 지분율로 한정한다.
- 입력은 투자 전 가치와 신규 투자금이며 단위는 모두 억원이다.
- 투자 후 가치=투자 전 가치+신규 투자금인 단순 모형을 사용한다.
- 전환증권, 옵션, 세금 등 복잡한 조건은 다루지 않는다.
- 회원가입, 제품의 백엔드 서버, 외부 API, 실제 투자 데이터 연동은 하지 않는다.
- 사용자가 값을 바꿔 여러 조건을 비교할 수 있게 한다.
어떤 기능을 선택했고 어떤 가정을 했는지 알려줘.

실습 3-c. 목표와 제약조건, 완료 조건을 모두 준다면

04-invest-C 폴더의 새 작업에서 실행합니다.

AI에게 입력

맥락: 나는 창업을 준비하고 있고 추후 투자를 받을 상황까지 고려하고 있다.
목표: 투자를 받을 때 해야 하는 여러 계산이 가능한 html 파일 하나로 동작하는 계산기를 만들어줘.
제약: 브라우저 한 화면. 투자 전 가치와 신규 투자금을 억원으로 입력한다.
투자 후 가치=두 입력의 합, 신규 지분율=투자금/합계,
기존 주주 전체 잔여 지분율=투자 전 가치/합계로 계산한다.
지분율은 퍼센트로 변환하고 금액과 지분율은 소수 둘째 자리까지 표시한다.
단순 모형이며 회원가입·제품의 백엔드 서버·외부 API·전환증권·옵션·세금은 제외한다.
빈 값, 음수, 합계 0에서는 오류를 보여준다.
정상 계산 뒤 잘못된 입력으로 바꾸면 이전 결과를 유효한 새 결과처럼 보여주지 않는다.
계산기를 완성해줘.

Done when:
- 실제 계산기 화면에서 8과 2를 입력하면
  투자 후 10.00억원, 신규 20.00%, 기존 주주 전체 80.00%가 표시된다.
- 9와 3이면 12.00억원, 25.00%, 75.00%가 표시된다.
- 8과 0이면 8.00억원, 0.00%, 100.00%가 표시된다.
- 빈 값, 음수, 두 입력 모두 0이면 계산 결과 대신 오류를 표시한다.
- 유효한 결과를 본 뒤 잘못된 값으로 바꿔도 이전 결과를 새 결과처럼 보여주지 않는다.
- 위 항목을 각각 검사하고 실제 확인 방법과 결과를 보고한다.
- 실패한 항목은 수정하고 다시 확인한다.
- 화면 확인을 못 했다면 코드 확인과 구분해 미검증으로 남긴다.
위 필수 검증이 통과하면 종료한다.

8. 랄프 루프를 넘어서. 제품이 커질수록 ‘알아서 잘하겠지’를 대신할 구조가 필요하다

계산기에서도 화면·입력·계산·오류가 연결됩니다. 웹앱에는 저장·검색·계정·복구·운영까지 더해질 수 있습니다. 한 문장으로 큰 목표를 줄 수는 있어도, 실제 완성은 여러 작업과 검증을 거쳐야 합니다.

매 단계마다 사람이 결과를 확인하고 다음 작업을 다시 지시해야 한다면, 창업자는 여전히 실행의 병목입니다. 더 큰 일을 맡기려면 AI가 목표를 놓치지 않은 채 확인 가능한 단위로 진행하고, 실패를 고친 뒤 다시 검증하도록 만들어야 합니다.

요즘 모델은 대충 말해도 알아서 잘 만드는 경우가 많습니다. 앞 실습에서도 A나 B가 훌륭했을 수 있습니다. 하지만 사업을 하면서 매번 “이번에도 AI가 알아서 잘하겠지”에만 기댈 수는 없습니다. 아마도 매우 높은 확률로, 정말 긴박할 때 알아서 못하는 순간이 옵니다. 그래서 우리에게는, 기대했던 산출물과 실제 산출물에 괴리가 발생해도 반복해서 그 괴리를 좁혀갈 수 있는 구조가 필요합니다.

이런 실행을 뒷받침하는 맥락·도구·검증·진행 관리 환경을 요즘 말로 하네스라고 부릅니다. AI가 일하는 작업대라고 생각하면 쉽습니다. 좋은 작업자도 설계도와 도구, 검사 기준이 없으면 같은 품질을 꾸준히 내기 어렵습니다. 하네스는 부족한 능력을 마법처럼 키워주는 장치가 아닙니다. 이미 있는 능력을 올바른 방향으로 쓰게 하고 실패를 드러내는 환경입니다.

이제 한 단계 더 메타적인 질문으로 가봅시다. “고객 문제를 해결하고 싶은 내 의도를, 애초에 어떤 제품으로 만들어야 할까요? 더 큰 사이즈의 프로덕트를 랄프 루프 한 번으로 만들 수 있을까요?”

9. 큰 제품은 어떻게 시작하는가: 전체 지도

제품 고도화는 한 번의 거대한 제작이 아니라 다음 판단을 버전마다 반복하는 과정입니다.

제품 의도 → Clarify → 초기 결정 → 얇은 프로토타입
→ 사용하며 문제 검증 → V1 Scope·Spec → 사용자 흐름
→ 수용·검증 기준 → Plan → Goal 실행 → 통합 검수
→ 출시 또는 필요한 단계로 복귀 → 다음 버전

이것이 모든 제품에 적용할 유일한 정석은 아닙니다. 단계는 겹치거나 되돌아갈 수 있습니다. 처음에 순서를 모두 외우려고 하지 마세요. 지금은 한 제품을 두고 질문하고, 결정하고, 만들어 쓰고, 증거를 남기는 경험을 쌓습니다.

이번 공통 제품의 의도는 “아이디어를 관리한다”보다 구체적입니다.

떠오른 생각을 잃기 전에 짧게 기록하고, 나중에 다시 찾는다.

목표 신호는 실제 상황에서 10초 안에 짧은 생각을 저장하고 싶다는 것입니다. 긴 아이디어까지 모두 10초에 입력한다는 약속은 아닙니다. 속도 측정의 시작점과 문장 길이는 뒤에서 정합니다.

같은 제품, 다른 두 번의 제작

첫 제작은 입력→저장→목록만 연결하는 프로토타입입니다. 이를 써보고 무엇을 고칠지 고릅니다. 두 번째 제작은 그 관찰에 따른 작은 개선 하나입니다. 오늘은 전체 사업용 서비스를 출시하는 것이 아니라 이 한 사이클을 경험합니다.

파일 이름을 외울 필요는 없습니다. AI가 작성하고 여러분은 내용과 선택을 확인합니다. 이 파일들은 대화가 길어지거나 중단돼도 합의와 증거를 다시 읽을 수 있게 합니다. 빈 양식을 많이 만드는 것이 목적은 아닙니다.

후반 실습 시작

06-idea-app 폴더를 열어 새 작업을 시작하고 준비 절의 안전 경계를 적용합니다. 이제부터는 이 폴더의 같은 작업을 이어갑니다. 계산기 작업에 웹앱 지시를 보내지 마세요.

AI에게 입력 — 후반 공통 규칙

나는 AI로 제품 개발 사이클을 배우는 초심자야.
지금부터 빠른 아이디어 기록 웹앱을 단계별로 만들 거야.
내가 요청한 현재 단계까지만 진행해.
질문은 한 번에 최대 2개, 사용자 경험·범위·데이터에 영향을 주는 것부터 해.
내 결정, 임시 가정, 미확인, 이번에 보류한 것을 구분해.
기술 선택은 계약 안에서 제안하고, 내게 필요한 설명은 사용자 영향 중심으로 해.
각 단계 문서는 짧게 쓰고 실제 파일 경로와 내용을 보여줘.
프로토타입 구현을 요청한 때에는 그 작은 범위만 구현해.
그 뒤 Spec·수용 기준·Plan 단계에서는 제품 코드를 바꾸지 마.
내가 Goal 실행을 요청한 때 선택한 개선만 구현·검증해.
실제로 관찰하거나 검사하지 않은 결과는 만들지 마.

혼자 학습한다면 각 절의 통과 조건을 확인한 뒤 넘어갑니다. 수업에서 답변이 늦으면 아래 짧은 선택 카드로 자신의 판단부터 남깁니다. 예시를 그대로 쓸 수 있지만 사실이 아닌 부분은 ‘학습용 가상 상황’이라고 표시하세요.

내 사용 상황: 대화 직후 떠오른 생각을 짧게 저장하고 다음 날 찾는다.
내 선택: 한 기기·텍스트·로그인 없음. 기기 간 공유는 이번에 보류한다.
첫 실험: 입력→저장 확인→목록. 기록을 끝내지 못하거나 저장을 확신하지 못하면 고친다.

63~68분에 문서 작성이 지연되면 세 줄을 직접 수정한 뒤 13절 프롬프트 앞에 붙이고 “내 결정으로 BRIEF.md와 DECISIONS.md를 짧게 저장한 뒤 구현해줘”라고 합니다. 문서 양은 줄여도 내가 무엇을 선택했는지는 건너뛰지 않습니다.

10. 제품 의도: 기능보다 먼저 사용자 변화

“메모·태그·검색 앱을 만들자”는 기능 목록입니다. “대화가 끝난 직후 떠오른 생각을 잃지 않고 다음 날 다시 찾자”는 사용자가 얻을 변화입니다. 후자를 먼저 적으면 새 기능이 나왔을 때 필요한지 판단할 기준이 생깁니다.

AI에게 입력

내가 만들고 싶은 것은 떠오른 창업 아이디어를 빠르게 기록하고 나중에 찾는 웹앱이야.
첫 사용자는 나 자신이야.
내 실제 사용 상황과 기존 기록 방법에서 불편한 점을 먼저 최대 2개 질문해줘.
내 답을 받은 뒤 BRIEF.md에 사용자·문제·핵심 가치·성공 신호·제약·미확인을
한 문단과 짧은 목록으로 써줘. 기능을 늘리지 말고 아직 구현하지 마.

AI가 질문하면 최근의 한 장면을 답합니다. 어떤 앱을 썼는지, 어디서 생각을 놓쳤는지 기억나지 않으면 “실제 경험은 아직 없고 가상 상황으로 연습한다”고 말합니다.

예상 결과 예시 — 가상 학습용 Brief

대화 직후 생각을 남기려는 나를 위한 기록 앱이다. 기존 메모 앱의 폴더 선택에서 흐름이 끊기는지 시험한다. 핵심 가치는 아이디어 분석이 아니라 빠른 저장과 다시 찾기다. 짧은 기록을 쉽게 끝내고 저장을 확신하는 것이 첫 성공 신호다. 수업에서는 가상 메모만 쓰며 수요와 반복 사용은 아직 확인하지 않았다.

직접 확인: 내 상황이 아닌 문장이 들어갔다면 고칩니다. “누구의 어떤 문제를 줄이는 제품인가?”를 기능 이름 없이 말하세요.

통과: 대상·문제·가치·성공 신호를 한 문단으로 설명합니다. 아직 답이 없으면 대상 상황 하나로 좁힙니다.

11. Clarify: 지금 구조를 바꿀 질문에 답한다

여러 기기에서 같은 메모를 보려는지 뒤늦게 알게 되면 저장 구조와 계정 요구가 바뀔 수 있습니다. Clarify는 이런 불확실성을 일찍 드러내는 단계입니다. 모든 질문을 끝낼 때까지 기다리는 절차는 아닙니다.

AI에게 입력

BRIEF.md를 읽고 첫 프로토타입을 크게 바꿀 질문만 최대 2개 해줘.
사용 상황, 저장·공유, 계정, 오프라인 중 지금 결정할 것부터 골라.
각 선택의 사용자 영향과 추천 이유를 설명해줘.
답을 받은 뒤 DECISIONS.md에 확정·가정·미확인·보류로 나눠 적어줘.
아직 구현하지 마.

수업 기본 선택: 한 기기, 텍스트, 로그인 없음, 브라우저 로컬 저장입니다. 로컬 저장은 기록이 그 브라우저에 남는다는 뜻입니다. 다른 기기에 자동으로 공유되지 않고, 브라우저 데이터 삭제 등으로 사라질 수 있습니다. 학습용 가상 메모만 넣고 실제 중요한 아이디어의 유일한 보관 장소로 쓰지 않습니다.

같은 항목도 증거가 생기면 상태가 바뀝니다. AI의 추천만으로 ‘확정’으로 바뀌지 않게 읽어보세요.

통과 질문: “기기 간 공유를 미루는 대신 이번에 무엇을 빠르게 확인하나요?” 답할 수 있으면 다음으로 갑니다. 공유가 실제 제품의 필수 조건이라면 이번 실험에서는 그 가치를 검증하지 못한다고 별도로 남깁니다.

12. 초기 결정: 첫 실험의 임시 계약

프로토타입은 제품의 축소 복제품이 아니라 가설을 확인할 도구입니다. 무엇을 확인할지 정해야 무엇을 만들지 작게 고를 수 있습니다.

AI에게 입력

상자를 읽기 전에: 프로그레시브 웹 앱 (Progressive Web App) · PWA. 웹앱에 설치형 경험 등을 제공하는 방식입니다. 이번 기본 실습에서는 제외합니다.

BRIEF.md와 DECISIONS.md를 읽고 첫 실험 계획을 정리해줘.
공통 가설: 한 입력란과 명확한 저장 피드백이면 생각을 빠르게 남기고 다시 찾을 수 있다.
내 사용 상황과 다르면 차이를 알려줘. 확인받지 않은 가설은 확정하지 마.
범위: 텍스트 입력→저장 성공 표시→최근 목록. 이 기기에 로컬 저장.
제외: 계정·동기화·음성·AI 분석·태그·검색·수정·삭제·PWA.
확인할 행동과 방향을 바꿀 신호를 DECISIONS.md에 기록해줘.
첫 실험 결정이지 최종 출시 범위가 아니라는 점을 표시해. 아직 구현하지 마.

PWA는 설치형 웹앱 경험을 위한 기능 묶음을 가리키며 이번에는 배우거나 만들 필요가 없습니다. 일반 브라우저에서 핵심 기록 흐름부터 확인합니다.

예시 판단: “저장 버튼을 눌렀는데 저장됐는지 몰라 다시 누른다면, 목록 디자인보다 저장 피드백을 먼저 고치겠다.” 이는 관찰 전의 판단 기준이지, 그런 일이 실제 발생했다는 기록이 아닙니다.

직접 할 일: 가설이 내 앞선 답과 맞는지 확인하고 “무엇을 확인하려고 무엇만 만드는가”를 한 문장으로 적습니다.

통과: 실험할 가설·최소 흐름·제외 기능·수정 신호가 있습니다. 구현 방법을 세세하게 정할 필요는 없습니다.

13. 얇은 프로토타입: 작은 흐름을 끝까지 연결한다

입력 화면만 있으면 저장됐는지 확인할 수 없습니다. 목록만 있으면 내 생각을 넣는 경험을 볼 수 없습니다. 얇다는 것은 기능은 적어도 핵심 흐름이 처음부터 끝까지 연결된다는 뜻입니다.

AI에게 입력 — 여기서 처음 웹앱 구현을 허용합니다

BRIEF.md와 DECISIONS.md의 첫 실험 범위로 작은 프로토타입을 만들어줘.
텍스트 입력→저장 완료 피드백→최근 목록이 연결되어야 해.
기존 파일과 실행 환경부터 확인하고 가장 단순하게 구현해.
같은 브라우저에 로컬 저장하고 빈 값과 공백만 있는 내용은 저장하지 마.
모바일 폭에서도 읽고 입력할 수 있게 하되 실제 휴대폰 확인 여부는 구분해.
계정·백엔드 서버·외부 API·배포·PWA·추가 기능은 넣지 마.
로컬 화면 실행에 필요한 개발용 서버와 제품의 백엔드는 구분해서 설명해줘.
구현 후 실행 방법, 실제 확인한 범위, 임시 처리·미검증 부분을 알려줘.

개발용 서버는 내 컴퓨터에서 화면을 열기 위한 실행 도구입니다. 계정을 관리하거나 고객 데이터를 받는 제품의 서버를 만들라는 뜻이 아닙니다. AI가 localhost 주소를 안내해도 이것만으로 외부 서비스가 배포된 것은 아닙니다.

기대하는 화면의 최소 형태 — 레이아웃은 달라도 됩니다

지금 떠오른 생각
[ 짧은 생각을 쓰는 입력란       ]
[ 저장 ]
저장되었습니다.               ← 저장 후 확인

최근 기록
- 식당 잔여 식재료 거래 아이디어

직접 확인 순서

1. AI가 알려준 실행 주소를 브라우저에서 엽니다.
2. ‘식당 잔여 식재료 거래 아이디어’라고 입력하고 저장합니다.
3. 저장 성공 표시를 확인하고 목록에서 같은 문장을 찾습니다.
4. ‘대화 후 질문 메모’도 저장하고 두 기록이 보이는지 확인합니다.

통과: 입력→저장 확인→목록의 흐름을 직접 끝냈습니다. 화면 이미지만 생성됐거나 코드만 받았다면 아직 통과가 아닙니다.

막히면 입력

현재 막힌 지점은 {{내가 한 행동과 나온 오류}}야.
새 기능은 추가하지 말고 입력→저장→목록의 이 지점만 복구해줘.
복구 후 내가 같은 행동으로 확인할 방법을 알려줘.

수업에서는 구현을 7분 내 시도하고, 못 열면 상태와 다음 행동을 남깁니다. 짝의 작동 화면이 있으면 관찰을 함께 하되 내 구현 완료와 구분합니다. 혼자라면 복구 후 이 절부터 이어가세요. 다음 절에 실제 관찰을 지어 넣지 않는 것이 중요합니다.

14. 직접 사용하며 문제를 검증한다

화면이 완성되면 “좋아 보인다”는 말을 하기 쉽습니다. 하지만 무엇을 했고 무엇이 달라졌는지는 직접 써봐야 알 수 있습니다. 다음 세 층을 구분해봅시다.

• 문제: 원래 이런 생각을 놓치는 일이 실제로 있는가?
• 행동: 앱을 열고 기록을 끝내며, 나중에 다시 찾는가?
• 경험: 입력·저장·찾기 중 어디서 망설이거나 막히는가?

수업 중 몇 번 써본 것으로 문제의 크기와 장기 사용을 모두 확인할 수는 없습니다. 지금은 입력 경험의 관찰 하나를 얻고, 생활 속에서 확인할 질문을 남깁니다.

실습 4. 3분 사용 관찰

1. 브라우저 화면이 열린 상태에서 ‘대화 후 질문 메모’를 새로 입력합니다. 입력 시작부터 저장됐다고 확인할 때까지 시간을 잽니다.
2. 다른 짧은 문장도 기록합니다. 저장을 확신하지 못해 다시 누른 순간이 있었는지 봅니다.
3. 목록에서 방금 기록한 하나를 다시 찾습니다.
4. 짝이 있으면 옆에서 탭 횟수·멈춘 지점을 기록하게 합니다. 혼자라면 한 번 수행한 직후 메모하고, 기억이 흐린 항목은 미확인으로 둡니다.

직접 채울 관찰표

관찰 대상: 자기 구현 / 짝의 앱 / 실행 못 함
화면 폭·기기:
실제로 입력한 문장:
측정 시작과 끝:
걸린 시간:
어디서 망설였는가:
저장 확인 및 다시 찾기의 실제 결과:
내 예상과 달랐던 것:
아직 확인하지 못한 것:

학습용 가상 관찰 예시 — 실제 기록 대신 제출하지 마세요

열린 화면에서 짧은 문장을 입력했다. 저장 표시를 못 찾아 두 번 눌렀다. 목록에 같은 문장이 두 개 보였다. 입력 속도보다 저장 여부를 알기 어려웠다. 실제 휴대폰에서 앱을 여는 시간과 재사용 여부는 확인하지 않았다.

AI에게 입력 — 관찰한 후에만

내 실제 사용 기록은 다음과 같아.
{{내 관찰표}}
OBSERVATIONS.md에 사실·해석·미확인을 구분해 기록해줘.
가설을 유지할 근거와 부족한 근거를 구분하고,
진행 / 수정 / 재정의 / 중단 중 추천과 이유를 알려줘.
관찰하지 않은 재사용·수요를 사실로 쓰지 마.
다음 결정 하나만 제안해줘. 아직 코드는 고치지 마.

진행은 가설을 유지하는 것, 수정은 흐름 일부를 바꾸는 것, 재정의는 사용자나 문제를 다시 보는 것, 중단은 지금 더 만들 근거가 부족하다고 판단하는 것입니다. AI가 추천하고 여러분이 결정합니다.

통과: 실제 사실 한 가지와 다음에 고칠 문제 또는 확인할 가정 하나를 고릅니다. 문제가 보이지 않았다면 ‘공백 저장’, ‘연속 클릭’ 등 아직 검사하지 않은 조건 하나를 고릅니다. 이를 발견한 문제라고 부르지는 않습니다.

짝의 앱을 관찰했다면: 그 앱에서 본 현상이 자기 앱에도 있다고 가정하지 않습니다. 자신의 06-idea-app에서 같은 행동을 해본 뒤 재현 여부를 기록하세요. 자기 앱을 아직 열지 못하면 참고 관찰로만 남기고 13절 복구로 돌아갑니다. 동작이 다르다면 이미 확인한 고장이 아니라 ‘내 앱에서도 검사할 조건’으로 선택할 수 있습니다.

AI에게 입력 — 짝의 관찰과 자기 앱을 대조할 때

다음은 짝의 앱에서 본 관찰이며 내 앱의 사실은 아니야.
{{짝의 앱에서 한 행동과 본 결과}}
내 현재 코드와 이 관찰을 대조하고, 같은 행동으로 확인할 방법을 알려줘.
내가 직접 확인한 결과는 {{재현됨 / 재현 안 됨 / 아직 확인 못 함}}이야.
OBSERVATIONS.md에서 관찰 대상과 상태를 구분해줘. 아직 코드는 고치지 마.

15. V1: 이번 버전의 범위를 고정한다

V1은 첫 버전입니다. 가능한 기능을 다 적는 목록이 아니라 약속한 가치를 전달할 이번 범위입니다. 지금은 짧은 수업 관찰만 있으므로 출시가 검증된 제품이 아닌 학습용 V1 가안으로 작성합니다.

공통 범위는 기록→저장 확인→최근 목록→새로고침 후 유지입니다. 검색·수정·삭제·동기화는 다음 후보입니다. 방금 관찰한 문제 하나를 이 흐름 안에서 고릅니다.

AI에게 입력

BRIEF.md, DECISIONS.md, OBSERVATIONS.md를 읽고 학습용 V1 가안을 작성해줘.
핵심 범위는 기록→저장 확인→최근 목록→새로고침 후 유지야.
이번 개선 또는 검증할 가정은 {{내가 고른 한 가지}}야.
SPEC.md에 대상·문제·가치, 포함·제외 기능, 기대 동작,
필요한 데이터, 빈 상태·오류·저장 실패, 제약과 미확인을 적어줘.
계정·동기화·음성·AI 분석·PWA 등은 추가하지 마.
관찰 근거와 가정을 구분하고 이번 범위를 넘어서는 요청은 후보로 남겨.
아직 코드를 바꾸지 마.

Spec (제품 동작 명세 (Specification))에서 확인할 예시 동작

• 내용이 없는 기록은 만들지 않습니다.
• 실제 저장에 성공한 뒤 성공 표시와 목록을 보여줍니다.
• 저장 실패 시 성공했다고 표시하지 않고 입력을 유지합니다.
• 기록에 구별할 ID (식별자 (Identifier)), 내용, 생성 시각을 둡니다. ID는 각 기록을 구분하는 표식입니다.
• 처음에는 기록이 없다는 안내가 보입니다.

AI가 데이터 항목을 제안하면 이름을 외우기보다 “이 정보가 없으면 어떤 동작을 못 하는가?”를 물으세요. 예를 들어 생성 시각은 최근 순서를 보여주는 데 쓰입니다.

통과: 포함 기능과 제외 기능을 각각 설명합니다. 관찰보다 기능이 많아졌다면 “이번 흐름에 꼭 필요한가?”를 묻고 줄입니다.

16. 사용자 흐름: 기능을 행동으로 바꾼다

‘저장 기능 있음’은 사용자 흐름이 아닙니다. 시작 조건에서 어떤 행동을 하고, 어떤 반응을 보고, 다음에 무엇을 하는지까지 이어져야 합니다. Spec을 먼저 간단히 쓰고 흐름을 보며 보완하는 것이며 한 번 작성한 Spec을 고정해두는 것은 아닙니다.

AI에게 입력

SPEC.md의 필수 기능을 다음 세 사용자 흐름으로 써줘.
1. 처음 기록하고 저장 확인 후 목록에서 다시 보기
2. 새로고침 후 기록 다시 보기
3. 빈 입력 또는 저장 실패 후 복구
각 흐름에 시작 조건→사용자 행동→시스템 반응→확인 결과→다음 행동을 적어줘.
모든 필수 기능이 연결됐는지 확인하고 SPEC.md에 흐름을 포함해줘.
새 제품 결정이 필요하면 먼저 질문하고 아직 코드는 고치지 마.

성공 흐름 예시

앱이 열려 있고 기록할 생각이 있음
→ 입력란에 문장을 쓰고 저장
→ 저장에 성공하면 성공 표시와 새 목록 항목이 나타남
→ 사용자가 같은 내용을 목록에서 확인
→ 새 기록을 시작하거나 앱을 닫음

실패 흐름 예시

저장 공간 문제로 저장 실패
→ 실패 안내를 표시하고 입력 문장은 유지
→ 사용자는 문장을 복사해 다른 곳에 보관하거나 다시 시도
→ 성공하지 않은 기록을 저장 완료로 오해하지 않음

실패를 완전히 없앨 수 없더라도 사용자가 무엇을 해야 하는지 알 수 있게 해야 합니다. 실제 오류 재현 방법은 다음 절에서 AI와 정합니다.

직접 확인 Q6: ‘저장 버튼이 있음’과 위 성공 흐름의 차이는 무엇인가요? 내 앱에서 빠진 연결 하나 또는 이미 확인한 연결 하나를 말하세요.

17. 수용·검증 기준: 완료를 같은 방식으로 판정한다

투자 계산기에서 8/2의 기대값을 정했듯, 웹앱에도 판정할 조건이 필요합니다. 수용 기준은 제품이 보여야 할 동작이고, 검증 방법은 그 동작을 어떻게 확인할지입니다. 증거는 실제 확인에서 얻은 결과입니다.

주어진 조건에서 → 사용자가 행동하면 → 관찰 가능한 결과가 발생한다.

AI에게 입력

상자를 읽기 전에: 수용 기준 (Acceptance Criteria) · AC. 제품이 보여야 하는 동작을 판정 가능한 조건으로 적은 것입니다. 번호는 요구와 검증을 연결합니다.

SPEC.md의 동작과 흐름을 읽고 ACCEPTANCE.md를 작성해줘.
각 항목에 조건, 행동, 기대 결과, 검증 방법, 판정 상태를 붙여.
- AC-01 텍스트 저장 후 성공 표시와 목록에서 같은 내용 확인
- AC-02 두 기록을 저장하고 새로고침해 내용과 개수 유지
- AC-03 공백만 입력하면 저장하지 않고 이유 표시
- AC-04 내가 선택한 개선 또는 검증할 가정의 기대 결과
Spec의 나머지 필수 조건도 누락하지 말고 별도 AC로 연결해줘.
자동 확인과 사람이 직접 볼 부분을 구분해.
저장 실패 재현은 실제 자료를 지우지 않는 안전한 방법을 제안해.
아직 실행하지 않았으므로 판정은 Not verified로 시작해. 코드도 고치지 마.

AC는 Acceptance Criteria, 즉 수용 기준의 짧은 이름입니다. 번호는 요구와 검사를 연결하기 위한 표식입니다.

기존 기록이 있으면 ‘총 두 개’가 아니라 ‘저장한 두 항목과 전체 개수가 새로고침 전후 유지’인지 봅니다. 검증하려고 기존 기록을 지울 필요는 없습니다.

검사 종류도 필요한 만큼만 구분합니다. 단위 테스트는 작은 계산이나 함수, 통합 테스트는 연결된 부분, E2E (처음부터 끝까지 검사 (End-to-End))는 입력부터 결과까지 전체 흐름을 검사합니다. 빌드·타입 검사 등은 코드가 정해진 형식과 실행 준비 조건에 맞는지 확인합니다. 이 검사가 통과해도 실제로 쓸 만한지는 별도입니다.

10초 목표의 위치: 수업 측정은 열린 화면에서 입력 시작→저장 확인입니다. 실제 생활 목표는 앱 열기 시작→저장 확인입니다. 시작점이 다른 시간을 같은 성과로 합치지 않습니다. 후속 실험에서는 같은 짧은 문장과 기기로 5회 재고 각 시간을 기록합니다. 자동 테스트만으로 사람의 10초 기록을 입증할 수는 없습니다.

통과 질문 Q7: AI가 “빌드 통과”라고 했는데 브라우저에서는 저장한 문장이 사라집니다. 데이터 유지 기준을 어떻게 판정해야 할까요?

18. Plan: 다음 작업 하나와 확인 방법

Plan은 합의된 제품을 구현할 작업 순서표입니다. 사용자는 결과와 경계를 결정하고, AI는 실제 코드 상태를 보고 작업 분해와 순서를 제안할 수 있습니다. 화면·데이터·테스트를 따로 끝내는 대신, 사용자가 경험할 작은 흐름 하나를 함께 확인할 단위로 나눕니다.

AI에게 입력

SPEC.md, ACCEPTANCE.md와 현재 코드를 읽고 PLAN.md를 만들어줘.
작동하는 프로토타입을 재사용해.
각 마일스톤에 사용자 결과, 구현·제외 범위, 선행 조건,
연결 AC, 검사 방법, 완료 조건, 막힐 때 행동을 적어줘.
수업에서 약 16분간 시도할 작은 개선 하나를 추천해.
나머지 V1 작업은 별도 미완료 목록으로 남겨줘.
범위 변경·권한 추가는 내 판단으로 돌리고 중단·재개 방법을 남겨.
지금은 계획만 만들고 코드는 바꾸지 마.

마일스톤은 중간 완료 지점입니다. ‘코드 100줄 작성’보다 ‘저장 성공을 사용자가 확인할 수 있고 오류 때는 입력을 잃지 않음’처럼 결과로 적습니다.

계획의 한 항목 예시 — 실제 선택은 내 관찰에 맞춥니다

이름: 저장 성공 피드백 확인과 보강
목적: 저장 여부를 사용자가 확실히 안다.
범위: 저장 성공 표시와 목록 반영. 기존 입력·저장 방식 유지.
제외: 검색·계정·동기화.
연결: AC-01, AC-04. 데이터 유지와 공백 방지는 회귀 확인.
검증: 문장 저장→성공 표시→목록 동일 내용→새로고침 유지.
완료: 연결 기준과 영향받는 기존 동작을 실제 확인.
중단: 새 외부 서비스가 필요하거나 같은 실패를 근거 없이 반복.

회귀 (전에 되던 기능이 변경 후 깨지는 현상) 확인은 새로 고치면서 전에 되던 기능을 망가뜨리지 않았는지 다시 보는 검사입니다.

직접 할 일: 추천한 개선 하나를 고르고 이름을 기록합니다. 이미 잘 작동하면 없는 문제를 만들지 말고, 미검증 조건 하나의 검사와 필요 시 보강을 선택하세요.

통과: 다음 작업과 연결 AC를 한 문장으로 말합니다. ‘전체 V1 완성’이 16분 안에 가능한지 모른다면 범위를 줄입니다.

수업의 80~94분 구간이 밀리면 긴 문서 대신 이번 범위 / 실제 관찰 / 선택한 개선 / 검증 행동 네 줄을 직접 채워 AI에게 누락된 계약 문서를 짧게 맞추게 하세요. 94분까지 개선과 검증 한 쌍이 없으면 실행을 서두르지 않습니다. 계약을 정리하고 자기 실행은 후속으로 남깁니다.

19. Goal: 검토된 계획을 실행한다

앞의 Goal은 계약의 ‘원하는 결과’를 뜻했습니다. 여기서는 합의한 일을 지속 실행하도록 맡기는 도구의 Goal 기능을 사용합니다. 제품이 성공한다는 뜻을 새로 정하는 단계가 아니라, 앞에서 정한 계약을 실행하는 단계입니다.

먼저 범위 충돌이 없는지 확인합니다.

AI에게 입력 — 실행 전 대조

SPEC.md, ACCEPTANCE.md, PLAN.md를 대조해.
서로 다른 기준, 너무 큰 작업, 검증 방법 누락,
사용자 판단이 필요한 항목만 짧게 알려줘.
문제가 없으면 선택한 마일스톤과 종료 조건을 한 문장으로 정리해.
아직 실행하지 마.

읽어보고 내가 고른 개선과 맞으면 /goal을 시작하고 아래 본문을 보냅니다. 기능이 없을 때는 5절의 일반 작업 대안을 사용합니다.

AI에게 입력 — 선택한 이름을 바꾼 뒤 실행

SPEC.md, ACCEPTANCE.md, PLAN.md를 읽고
내가 선택한 마일스톤 {{선택한 이름}}을 완료해줘.
다른 마일스톤은 이번 실행 범위가 아니야.
현재 상태 확인→구현→검증→실패 수정→재검증을 이어가.
브라우저에서 연결된 사용자 흐름과 영향받는 기존 동작도 확인해.
확인하지 못한 항목을 완료로 표시하지 마.
PROGRESS.md에 실제 검증 방법·결과·중요한 결정·남은 것·재개 위치를 기록해.
선택한 마일스톤의 필수 AC와 연결 흐름이 통과하면 종료해.
제품 범위 변경, 데이터 손실 위험, 계정·동기화·외부 서비스·배포 등
새 권한이 필요하면 멈춰서 내 판단을 요청해.
같은 실패가 새 정보 없이 반복되면 원인과 다른 접근을 보고해.
중지를 요청하면 완료한 것과 미완료, 재개 방법을 남겨줘.

타이머를 16분으로 맞춥니다. 매 단계 방법을 추가하지 말고 계약을 바꿔야 하는 질문에 답합니다. 시간이 끝나면 상태를 확인하고 필요하면 실행을 중지합니다. ‘16분’은 학습자가 중지할 시점이지 AI의 자동 비용 제한이 아닙니다.

완료 보고에서 읽을 것: 어떤 파일이 바뀌었는지만 보지 말고, 어떤 AC를 어떤 방법으로 확인했는지 봅니다. AI가 브라우저 접근이 없다고 하면 화면 검증은 미검증으로 남기고 직접 수행합니다. 접근 불가를 해결하려고 무조건 권한을 넓히지 않습니다.

통과: 선택한 개선과 연결 기준의 증거가 있습니다. 전체 V1의 나머지 AC는 이번 실행에서 자동으로 완료되지 않습니다. 시간이 부족하면 미완료 이유와 재개 위치를 남긴 뒤, 검수에서는 실제 완성된 범위만 봅니다.

20. 검수: 다시 써보고 다음에 돌아갈 곳을 정한다

AI의 완료 보고는 검수의 출발점입니다. 만드는 과정과 별도로 실제 제품을 봐야 합니다. 검수에도 세 층이 있습니다.

1. 기계적 검수: 테스트·빌드 등 코드와 데이터의 조건이 맞는가?
2. 사용자 흐름 검수: 처음부터 끝까지 과업을 수행하고 실패 후 복구할 수 있는가?
3. 제품 검수: 목표 사용자가 이해하고 실제로 쓸 이유가 있는가?

AI에게 입력 — 우선 검사만 요청

현재 제품을 SPEC.md와 ACCEPTANCE.md의 이번 범위에 맞춰 검수해줘.
먼저 검수만 하고 수정하지 마.
검사 결과, 사용자 흐름, 기존 기능 유지, 제외 범위 준수를 구분해.
각 항목의 Pass/Fail/Blocked/Not verified와 실제 증거를 REVIEW.md에 적어줘.
수정 후 재검수 / Plan 복귀 / Spec 복귀 / Clarify 복귀 중
다음 판단과 이유를 추천해줘.
전체 출시 준비와 실제 생활의 재사용 가치는 미확인이면 그대로 남겨줘.

직접 수행할 최종 확인

1. 새 문장 ‘다음 날 다시 찾기’를 저장합니다.
2. 저장 성공 표시와 목록의 같은 내용을 확인합니다.
3. 새로고침 후 내용과 개수를 대조합니다.
4. 공백만 입력해 저장되지 않는지 봅니다.
5. 내가 고른 개선의 AC를 직접 수행합니다.
6. 각 결과를 AI의 보고와 대조합니다. 다르면 실제 증거를 전달합니다.

검수 뒤 판단표

AI가 추천했다고 즉시 새 범위를 구현하지 않습니다. 다음 행동을 고르고, 무엇을 바꾸는지 합의한 뒤 실행합니다.

수업 완료 기록

이번에 실제로 통과한 것:
실패·미검증·차단된 것과 이유:
다음에 돌아갈 단계:
그 단계를 고른 증거:
다음 행동 하나:

수업 뒤: 실제 생활에서 검수한다

지금 테스트가 통과해도 실제로 앱을 열지 않으면 제품 가치는 미확인입니다. 안전하게 멈춰 있는 순간이나 대화 직후에 기록하고, 다음 날 다시 찾아보세요. 걸으면서 화면을 조작하는 실험은 하지 않습니다.

• 앱을 열기 시작한 순간부터 저장 확인까지, 같은 짧은 문장으로 5회 시간을 기록합니다.
• 며칠 동안 생각이 떠올랐을 때 어떤 도구를 실제로 열었는지 적습니다.
• 기존 메모 앱으로 돌아갔다면 그 이유를 적습니다.
• 일주일 동안 기록을 다시 찾은 횟수와, 다시 찾지 않은 이유를 적습니다.

실제 휴대폰 실행은 별도 준비가 필요합니다. localhost를 공유 주소로 오해하지 마세요. 모바일에서 확인하려면 안전한 실행·접속 방식을 AI에게 설명받고 범위와 권한을 별도 승인합니다. 배포는 이 수업의 기본 허용 범위가 아닙니다. 컴퓨터에서 폭만 줄여 본 것을 실제 휴대폰 검수라고 적지 않습니다.

AI에게 입력 — 생활 사용 후

이 앱의 실제 생활 사용 기록이야.
{{실제 기록}}
재사용한 이유, 기존 방법으로 돌아간 이유, 불편을 최대 2개씩 질문해줘.
관찰과 추정을 구분하고 다음 버전에서 유지·수정·제외할 것,
돌아갈 단계와 아직 부족한 증거를 정리해줘.
아직 구현하거나 배포하지 마.

출시는 테스트 외에 데이터 보존·보안·접근성·운영 등 실제 사용 환경의 조건까지 확인한 뒤 사람이 결정합니다. 로컬 저장은 백업이나 기기 간 동기화의 보장이 아닙니다. 다음 버전에서 필요한 조건을 새 계약으로 정하세요.

21. 창업자의 역할은 루프를 설계하고 판단하는 것이다

처음에는 “계산기 만들어”라고만 했습니다. 그다음 제약과 완료 기준이 어떤 선택과 증거를 바꾸는지 봤습니다. 웹앱에서는 제품 의도를 정하고, 실제 사용에서 얻은 관찰을 계획과 다음 구현으로 연결했습니다.

마지막으로 두 루프를 분명히 구분해봅시다.

제품 학습: 고객 문제 → 가설 → 사용 실험 → 관찰 → 다음 제품 결정
                              ↓ 정한 계약
AI 실행:   작업 선택 → 구현 → 검증 → 수정 → 증거와 결과 보고
                              ↓ 사람의 검수
                       다음 고객 학습으로

AI 실행 루프는 정한 일을 완수하도록 돕습니다. 제품 학습 루프는 그 일이 고객에게 필요한지 판단하게 합니다. 실행이 빨라졌다고 잘못된 제품 의도가 자동으로 고쳐지는 것은 아닙니다.

마지막 수행: 제품 완료와 학습 완료를 따로 확인한다

실행 증거

• 계산기의 실제 입력과 결과를 대조했다.
• 제약과 완료 기준이 있는 요청을 실행하고 차이를 기록했다.
• 웹앱의 입력→저장→목록 흐름을 직접 수행했다.
• 관찰에서 고른 개선 또는 미검증 조건을 계약·Plan에 연결했다.
• 선택한 범위를 구현·검수하고 미완료를 구분했다.

자기 설명 — 예시를 보지 않고 채우기

내가 결정한 계약은 ______이다.
AI에게 맡긴 방법은 ______이다.
내가 실제로 확인한 증거는 ______이다.
아직 알 수 없는 것은 ______이다.
다음에는 ______ 상황의 사용자를 만나 ______을 확인하겠다.

실행이 미완료라면 체크하지 말고 재개할 절을 적습니다. 실행은 했는데 위 문장을 채우지 못하면 해당 결과를 다시 보고 이유를 설명합니다. 프롬프트 복사 횟수와 AI가 일한 시간은 졸업 기준이 아닙니다.

전이 문제 Q8: 새 제품에도 적용할 수 있는가

이번에는 소규모 행사 예약 앱을 맡기려 합니다. 코드를 만들지는 말고 스스로 아래를 작성하세요.

1. 사용 상황 한 문장.
2. AI가 방법을 정하기 전에 물어야 할 제품 질문 두 개.
3. 원하는 결과·제약·완료 기준 각각 한 가지.
4. 기능이 맞아도 고객에게 쓸모없는 상황 한 가지.

답을 쓴 뒤 부록 해설과 대조합니다. 프레임워크의 이름을 외우지 못해도 계약은 스스로 정할 수 있어야 합니다.

마지막으로: 구현을 맡겨 확보한 시간을 고객과 현실의 피드백에 쓰세요. 그 피드백으로 다음 버전의 계약을 다시 정하는 것, 그리고 AI가 그 계약을 일관되게 수행할 환경을 만드는 것이 창업자의 일입니다.

부록 A. 자기 점검 해설

정답 문장을 외우지 마세요. 아래 핵심 구분이 내 답에도 있는지 확인합니다.

Q8 참고 답안 — 유일한 정답이 아닌 가상 예시

상황: 참가자가 정원 10명의 행사에서 자리를 신청한다. 질문: 신청 즉시 확정인가, 운영자 승인 후 확정인가? 정원이 차면 대기 신청을 받는가? 결과: 참가자가 자신의 예약 확정 여부를 알 수 있다. 제약: 이번 프로토타입에는 실제 결제와 실제 개인정보를 넣지 않는다. 완료 기준: 테스트 데이터로 정원 10명을 채운 뒤 11번째 신청을 하면 확정 예약이 아닌 마감 또는 합의한 대기 상태가 표시되고, 이미 확정한 인원이 10명을 넘지 않는다. 가치 미확인: 동작은 맞지만 고객이 기존 예약 도구에서 옮길 이유가 없다.

내 답이 다른 예약 정책을 선택해도 괜찮습니다. 질문→선택→관찰 가능한 완료가 서로 맞으면 됩니다. ‘예쁘게’, ‘잘’, ‘완벽하게’만 있고 확인할 행동이 없다면 다시 구체화하세요.

부록 B. 한 장으로 다시 쓰는 위임 양식

다음 제품에서는 먼저 아래만 채워 시작하세요. 모든 문서를 한꺼번에 만들 필요는 없습니다.

Context: 사용자는 ______ 상황에서 ______ 문제를 겪는다.
Goal: 이번에는 ______을 할 수 있게 만든다.
Boundary: ______은 지키고 ______은 만들거나 바꾸지 않는다.
Done when: ______ 조건에서 ______ 행동을 하면 ______ 결과를 확인한다.
확인 방법: ______. 사람이 확인할 것은 ______.
Clarify: 사용자 결정이 필요한 불확실성은 ______.
Approach: 계약 안의 구현 방법과 순서는 AI가 제안한다.
중단: ______이면 실행을 멈추고 나에게 판단을 요청한다.
기록: 실제 결과·미검증·다음 행동을 남긴다.

작업이 크다면 이를 Spec·Acceptance·Plan으로 구체화합니다. 작은 작업은 이 짧은 계약만으로도 시작할 수 있습니다. 문서의 양보다 의도와 증거가 맞물리는지가 더 중요합니다.

부록 C. 출처와 이 교안의 검증 범위

강사 소개와 회사 경험은 강사 제공 진술입니다. 체결률 수치·투자 수치·관찰 사례는 학습용이며 실제 성과나 투자 권유가 아닙니다.

• Geoffrey Huntley, Ralph Wiggum as a software engineer: 반복문 출처. 실행해야 할 명령이 아니라 구조를 읽는 자료입니다.
• The Lean Startup, Principles: 만들기·측정·학습의 피드백 사이클.
• OpenAI 공식 시작 안내: 설치·로그인·작업 시작 안내. 실제 참가자 환경은 별도 확인합니다.
• OpenAI 공식 장기작업 안내: 목표·제약·검증과 Goal 기능. 확인일 2026-09-07, UI (사용자 인터페이스 (User Interface))와 계정별 이용 가능성은 달라질 수 있습니다.

문서의 설명·단계 연결·기대값은 검토 대상입니다. 여기 수록된 프롬프트를 모든 참가자 환경에서 실행했거나, 실제 학습자가 120분에 완주했다는 뜻은 아닙니다. 별도 완성 앱은 이 자료에 포함되지 않으며, 학습자가 AI와 직접 만드는 것이 실습입니다. 외부 링크는 출처·도구 설치용이고 핵심 개념과 실습 계약은 본문 안에 있습니다.

내 말로 설명할 수 있나요?

아래 점검은 이해한 부분을 돌아보는 자기평가입니다. 제품 성능이나 학습 성취를 자동으로 인증하는 점수가 아닙니다.

읽다가 궁금해지는 것들