9장
빌드
루프
불완전함을 예상해. 개선을 즐겨.
세 번째 버전에서 마법이 일어나.
AI로 만들 때 가장 흔한 실수는 나쁜 프롬프트가 아니야. 나쁜 기대치야. 긴 설명을 한 번 입력하고, 엔터를 누르고, 완성품을 기대해. 안 돼. 절대 안 돼. 대단한 것을 만드는 사람들은 비밀을 알아: 첫 번째 버전은 항상 잘못돼. 세 번째 버전이 괜찮아. 다섯 번째가 훌륭해. 그리고 1에서 5까지 가는 과정? 그게 진짜 스킬이야.
모든 아티스트가 반복해. 모든 건축가가 수정해. 모든 영화감독이 여러 테이크를 찍어. AI로 만드는 것도 다르지 않아. 루프를 즐기는 사람이 — 원망하지 않는 사람이 — 최고의 것을 만들어.
명세, 생성, 검증
코딩 에이전트와의 모든 생산적인 세션은 같은 리듬을 따라. 원하는 걸 명세해 — 구체적으로, 예시를 주고, "완료"가 어떻게 생겼는지 설명해. 에이전트가 생성하게 해. 그다음 검증: 작동해? 괜찮아 보여? 요청한 대로 해? 아니면 다시 더 정확하게 명세해. 그게 루프야. 실패의 신호가 아니야. 프로세스야.
파워 무브는 만들기 전에 인수 기준을 쓰는 거야. "버튼을 클릭하면 초록색으로 변해야 해." "페이지를 새로고침해도 리스트가 유지돼야 해." "가입 양식이 @ 없는 이메일을 거부해야 해." 이 쉬운 말 설명이 네 평가 프레임워크가 돼. 뭔가 잘못되면 기준을 에이전트한테 다시 붙여넣고 "이거 안 맞아"라고 해. 에이전트가 네 기준에 맞춰 테스트할 수 있어.
막혔을 때 어떻게 할까
에이전트가 망가진 걸 만들었어. 이제 뭐해? 다섯 가지 전략, 먼저 시도할 순서대로:
1. 진단이 아니라 증상을 설명해
"클릭해도 버튼이 반응 안 해"가 "onClick 핸들러가 깨진 것 같아"보다 나아.
2. 에러 메시지를 그대로 공유해
정확한 에러를 복사-붙여넣기. 에이전트한테 줄 수 있는 가장 유용한 것이야.
3. 에이전트한테 뭘 했는지 설명해달라고 해
"방금 뭘 바꿨고 왜 바꿨는지 설명해줘." 이해하면 문제가 드러나는 경우가 많아.
4. 다른 접근법을 요청해
"그 방법은 안 돼. 완전히 다른 방식으로 해결할 수 있어?"
5. 배운 것을 가지고 새로 시작해
가끔은 새 대화가 꼬인 걸 디버깅하는 것보다 빨라. 핵심 결정 사항만 가져가.
가드레일로서의 테스트
에이전트한테 자동화된 테스트를 쓰라고 할 수 있어 — 쉬운 말로. "가입 양식이 @ 없는 이메일을 거부하는지 확인하는 테스트 써줘." 에이전트가 테스트 그리고 그걸 통과하는 코드를 둘 다 써. 테스트를 한 번도 안 써본 사람이 하는 테스트 주도 개발이야. 한번 테스트에 잡힌 버그는 절대 다시 돌아올 수 없어.
스킬을 연습해봐. 이 버그들을 코딩 에이전트한테 어떻게 설명할래?
반복할 수 있어. 디버깅할 수 있어. 근데 만들고 있는 게 실제로 좋은지 어떻게 알아? 그냥 작동하는 게 아니라 — 좋은. 그건 AI가 줄 수 없는 게 필요해: 안목. 그게 다음이야.