Phase 2는 단순히 "코드를 짜는 3주"가 아닙니다. 매 단계마다 막히는 순간이 오고, 그 순간에 Claude Code에게 물어보고 해결하면서 이해가 생깁니다.
이 페이지는 그 이해가 어떤 순서로, 어떤 경험에서 만들어지는지를 설명합니다. 예시는 실제 참가자들이 경험하는 상황을 기반으로 합니다.
"만들어줘" 한 마디에 Claude Code가 파일 세 개를 동시에 만들어줄 때, 처음엔 당황스럽습니다. 왜 파일이 나뉘어져 있는지 이해하는 순간 구조·스타일·동작이 분리된다는 원리가 몸에 들어옵니다.
→ index.html / style.css / script.js 생성됨
→ "왜 파일이 세 개야?" Claude에게 물어봄
→ "HTML은 뼈대, CSS는 옷, JS는 행동" — 처음으로 개념이 연결됨
처음엔 "검색도 되고, 저장도 되고, 공유도 되면 좋겠는데"라고 말합니다. Claude가 전부 만들어주려 하면 코드가 복잡해지고 아무것도 제대로 작동하지 않습니다. 가장 작은 것 하나만 먼저 완성하는 경험이 MVP 사고의 시작입니다.
→ 200줄짜리 코드 생성 → 실행했더니 화면이 안 뜸
→ "저장 기능만 먼저 만들어줘"로 다시 요청
→ 20줄 코드 → 작동 성공 → "이게 맞구나" 체감
"멋지게 만들어줘"는 잘 동작하지 않습니다. "배경은 흰색, 버튼은 파란색, 글자 크기는 16px"처럼 구체적으로 말할수록 원하는 결과가 나옵니다. AI에게 말하는 법이 곧 스스로 원하는 것을 명확히 아는 훈련이 됩니다.
"배경 흰색, 버튼 파란색, 폰트 16px, 중앙 정렬" → 원하는 결과 출력
→ 요구사항을 언어로 정의하는 능력이 자연스럽게 생김
실제로 써보면 버튼이 안 눌리거나, 저장이 안 되거나, 화면이 깨지는 순간이 옵니다. 그때 브라우저 개발자 도구의 에러 메시지를 복사해 Claude에게 붙여넣는 습관이 생깁니다. 에러 메시지가 낯선 영어라도 괜찮습니다 — 그대로 붙여넣으면 됩니다.
→ F12 → 콘솔 탭 → 빨간 글씨 발견
→ "Cannot read properties of null" 복사
→ Claude에게 붙여넣기 → 원인과 수정 코드 바로 제시
친구에게 써보게 하면 "이 버튼이 뭐하는 거야?"라는 질문이 나옵니다. 만든 사람에게 당연한 것이 쓰는 사람에겐 전혀 당연하지 않습니다. 설명 없이도 직관적으로 이해되는 설계가 왜 중요한지 처음으로 몸으로 배웁니다.
→ "엔터로도 저장되게 해줘" 추가 요청
→ 내가 상상한 사용 방식과 실제 사용 방식이 다르다는 것을 처음 인식
에러를 수정받는 것에서 한 발 나아가, "왜 이 에러가 생긴 거야?"를 함께 물어보는 습관이 생깁니다. 이유를 알면 다음에 같은 실수를 하지 않습니다. 이것이 단순히 코드를 받아쓰는 것과 배우며 만드는 것의 차이입니다.
→ "근데 왜 이 코드가 문제였어?"라고 추가 질문
→ null 참조가 무엇인지 설명 들음 → 다음에 비슷한 상황에서 혼자 해결
"글자 크기만 바꿨는데 레이아웃이 전부 틀어졌어요" — 이 경험이 코드 간 의존성을 이해하는 가장 빠른 방법입니다. 부분을 바꾸면 전체에 영향이 간다는 것을 알게 되면, 무엇을 수정하기 전에 먼저 "어디까지 영향을 줄까?"를 생각하게 됩니다.
→ 버튼이 박스 밖으로 튀어나옴
→ "왜 이렇게 됐어?" → CSS 박스 모델·레이아웃 개념 이해
→ "글자 크기와 패딩을 같이 조정해줘"로 수정 방식 진화
친구 A는 "글자가 너무 작다", 친구 B는 "기능이 너무 단순하다", 친구 C는 "색이 마음에 안 든다"고 합니다. 셋 다 반영하려다 아무것도 못 끝내는 경험을 하게 됩니다. "지금 가장 중요한 것 하나"를 고르는 판단이 설계의 핵심이라는 것을 몸으로 배웁니다.
→ "사용하는 데 가장 불편한 게 뭐야?" 다시 물어봄
→ 글자 크기 하나만 수정 → 실제로 쓰기 편해졌다는 반응
→ "적게 바꾸는 것이 더 나을 수 있다" 체득
처음엔 조금 이상하면 "전부 다시 만들어줘"라고 요청합니다. 그러면 이전에 잘 되던 기능까지 사라집니다. 고쳐야 할 부분을 좁혀서 지시하는 법을 배우면 기존 코드를 지키면서 원하는 부분만 개선할 수 있습니다.
→ "저장 버튼의 클릭 이벤트 부분만 수정해줘"로 방식 변경
→ 기존 기능 유지하면서 원하는 부분만 개선 성공
"이 버튼을 누르면 왜 데이터가 저장돼?"라는 질문에 답하면서 내가 실제로 이해한 것과 그냥 작동했던 것을 구분하게 됩니다. 모르는 부분이 발표 준비 중에 발견되고, 그 자리에서 Claude에게 다시 물어보며 채워집니다.
→ Claude에게 물어봄 → 로컬스토리지·서버 차이 이해
→ 발표에서 "지금은 브라우저에만 저장되고, 다음 단계에서 서버 연동 예정" 설명 가능
"왜 이 기능을 먼저 만들었나요?", "왜 이 피드백은 반영 안 했나요?" 이 질문에 답하는 것이 발표의 핵심입니다. 결과물이 아니라 과정에서 내린 판단을 설명하는 능력이 자소서·면접에서 실제로 쓰입니다.
→ "처음엔 넣으려 했는데, 저장 기능도 완벽하지 않은 상태에서 공유를 먼저 하면 의미가 없다고 판단했습니다"
→ 우선순위 결정 과정이 곧 설계 역량의 증거
"Claude가 다 만들어준 거 아니에요?"라는 질문에 명확하게 답할 수 있어야 합니다. 코드는 Claude가 작성했지만, 무엇을 만들지·무엇을 고칠지·어떤 기능을 포기할지는 내가 결정했습니다. 이 구분이 생기는 것 자체가 AI 협업 역량입니다.
→ "코드 작성은 Claude가 했습니다. 하지만 어떤 문제를 풀지, 어떤 기능을 먼저 만들지, 테스트 결과로 무엇을 바꿀지는 제가 판단했습니다"
→ 이 답변이 나오는 순간이 프로그램의 완성입니다