개선 루프를 돌린다

앞 편 계측을 먼저 심어 둔다까지 오면 만들고, 공개하고, 숫자를 줍는 장치가 다 갖춰졌습니다. 이번 편은 그 장치들을 하나의 바퀴로 묶습니다. 바이브 코딩의 성과는 한 번에 얼마나 잘 만들었는가가 아니라 이 바퀴를 몇 번 돌렸는가로 정해집니다. 다음 편 리포팅을 AI에게 맡긴다에서는 바퀴의 관찰 단계를 자동화합니다.

핵심 요약

• 루프는 가설, 만들기, 공개, 관찰, 학습, 다음 가설의 여섯 단계입니다.
• 한 바퀴는 짧을수록 좋습니다. 공개가 빠진 바퀴는 바퀴가 아닙니다.
• "돌아간다"와 "쓸 만하다"는 다릅니다. 그 거리를 좁히는 것이 루프의 일입니다.
• 가설은 "무엇을 바꾸면 추적할 숫자가 어떻게 될 것이다"의 꼴로 적습니다.
• 루프가 멈추면 의지가 아니라 틀을 고칩니다.

루프의 전체 그림

1. 가설: 무엇을 바꾸면 숫자가 움직일 것이라고 믿는가.
2. 만들기: 가설을 Issue 1건으로 적어 AI에게 넘긴다.
3. 공개: 프리뷰가 아니라 실제 사용자에게 도달시킨다.
4. 관찰: 추적할 숫자가 어떻게 됐는지 본다.
5. 학습: 가설이 맞았는지, 틀렸다면 왜인지 한 줄로 적는다.
6. 다음 가설: 학습에서 다음 가설을 뽑는다.

우리 8주 교재 8주차의 개발 루프와 겹쳐 보면 구조가 같습니다. 계획 모드로 방향을 정하고, 샘플을 확인하고, 실행은 맡기고, 다른 AI에게 교차 검수를 시키고, 반복합니다. 다른 점은 바이브 코딩의 루프에 "공개"와 "관찰"이 명시적으로 들어 있다는 것입니다. 만드는 루프는 코드가 돌아가면 끝나지만, 개선 루프는 사람이 써 보고 숫자가 움직여야 한 바퀴입니다.

한 바퀴를 짧게 하는 게 최대의 기술

한 바퀴가 한 달이면 1년에 열두 번 배웁니다. 한 바퀴가 이틀이면 백 번 넘게 배웁니다. 배움의 횟수가 성과이므로, 바퀴를 짧게 만드는 것이 바이브 코딩에서 가장 큰 기술입니다. 짧게 만드는 방법은 이미 앞 편들에 있습니다. 첫 공개를 작게 잡고(9편), Issue 1건씩 넘기고(10편), 올리면 공개되게 하고(11편), 숫자가 자동으로 잡히게 합니다(13편).

Claude Code 쪽에서는 계획 모드가 바퀴를 짧게 하는 도구입니다. Shift+Tab으로 계획 모드에 들어가거나 프롬프트 앞에 /plan을 붙이면 AI는 파일을 읽고 계획만 제시하고 편집하지 않습니다. 계획이 마음에 들면 승인하면서 실행 모드로 넘어가고, Ctrl+G로 계획을 편집기에서 직접 고칠 수도 있습니다. 계획 단계에서 "이 가설을 검증하는 데 꼭 필요한 최소 변경은 무엇인가"를 묻는 것이 바퀴를 짧게 만드는 질문입니다.

"돌아가는 것"과 "쓸 만한 것"의 거리

코드가 에러 없이 돌아가는 것과 사람이 다시 쓰고 싶은 것 사이에는 거리가 있습니다. 첫 바퀴에서 나오는 것은 대부분 "돌아가는 것"입니다. 우리 5주차 교재에서 QA를 코드 관점과 서비스 관점으로 나누는 이유가 이것입니다. 콘솔 에러가 없는가는 코드 관점이고, 버튼이 실제로 동작하고 문구가 맞는가는 서비스 관점입니다. 개선 루프는 여기에 한 층을 더합니다. 사용자가 다음 주에 또 왔는가.

서비스 관점의 QA는 AI가 자기 결과물을 스스로 점검하는 것만으로는 부족할 때가 있습니다. 우리 5주차 교재와 8주차 개발 루프에서 다른 AI에게 교차 검수를 시키는 이유입니다. Claude Code가 만든 결과를 다른 모델에게 "사용자 입장에서 처음 써 본다고 가정하고 막히는 지점을 찾아 줘"라고 시키면 만든 쪽이 못 보는 맹점이 나옵니다. 검수 결과는 다음 가설의 근거가 됩니다.

이 거리는 한 번에 좁혀지지 않습니다. 첫 바퀴에서 돌아가게 만들고, 둘째 바퀴에서 동료 한 명이 쓰게 만들고, 셋째 바퀴에서 그 동료가 안 시켜도 쓰게 만듭니다. 각 바퀴의 목표를 미리 낮게 잡아야 바퀴가 짧아집니다.

가설 세우는 법

가설은 세 칸으로 적습니다.

## 가설 3 (2026-09-08)
- 바꾸는 것: 알림 메일 제목에 마감일까지 남은 일수를 넣는다
- 기대: 원문 링크 클릭 건수가 주 4건에서 8건으로 는다
- 근거: 지난주 클릭된 4건이 전부 마감 3일 이내 공고였다

바꾸는 것 하나, 기대하는 숫자 변화 하나, 근거 하나. 근거는 관찰에서 나옵니다. 근거 없이 "있으면 좋을 것 같아서"로 시작하는 가설은 9편의 안 할 목록으로 보냅니다. 가설은 docs/hypotheses.md처럼 한 파일에 누적합니다. 다음 바퀴를 시작할 때 이 파일을 @docs/hypotheses.md로 AI에게 주면 지난 가설과 결과를 알고 다음 Issue를 잡습니다.

가설이 빗나갔을 때 접는 법

숫자가 안 움직였으면 가설이 틀린 것입니다. 이때 두 가지 유혹이 옵니다. "조금만 더 다듬으면 될 것 같다"와 "숫자가 잘못 잡힌 것 같다". 둘 다 한 바퀴를 더 쓰게 만듭니다. 대신 이렇게 합니다. 만든 것은 브랜치째 남겨 두되 운영에서 되돌리고, 학습 한 줄을 가설 파일에 적고, 다음 가설로 갑니다.

되돌리기가 쉬운 이유는 3주차 교재의 커밋 습관 덕분입니다. 작업 전 커밋, 작업, QA 통과, 커밋. 이 기준점이 있으면 "이전 커밋으로 되돌려 줘" 한 마디로 복구됩니다. 되돌리는 비용이 낮아야 가설을 과감하게 세울 수 있습니다.

안 돌아가게 됐을 때의 처방전

루프가 멈추는 순간은 대개 셋 중 하나입니다. Issue가 커져서 한 바퀴가 길어졌거나, 공개가 사람 손에 걸려 있거나, 숫자를 보러 가는 것이 귀찮아졌거나. 처방은 각각 정해져 있습니다.

1. 바퀴가 길어졌다: Issue를 반으로 쪼갭니다. 5주차 교재의 여섯 단계 쪼개기가 그 방법입니다.
2. 공개가 손에 걸린다: 11편으로 돌아가 자동 배포를 고칩니다.
3. 숫자 보기가 귀찮다: 다음 편에서 리포트가 나에게 오게 만듭니다.

공통 처방은 틀을 문서로 고정하는 것입니다. CLAUDE.md에 규칙을 적어 두면 AI가 바퀴를 길게 만들려 할 때 스스로 경고합니다.

## 개선 루프 규칙
- Issue 1건은 하루 안에 끝나는 크기로 쪼갠다. 넘치면 쪼개는 계획부터 제안한다.
- 공개(운영 배포)가 없는 작업은 완료로 보고하지 않는다.
- 작업이 끝나면 docs/journal.md에 네 줄 일지를 추가한다.
- 가설은 docs/hypotheses.md에 바꾸는 것·기대 숫자·근거 세 칸으로 적는다.

공식 문서도 같은 실수가 두 번 반복될 때 CLAUDE.md에 적으라고 권하며, 특정 시점에 반드시 실행되어야 하는 명령은 CLAUDE.md 대신 훅으로 걸라고 안내합니다. 규칙은 안내이고 훅은 강제입니다. 우리 교육의 표현으로는 "프롬프트는 부탁, 하네스는 강제"입니다. 루프는 의지로 돌지 않습니다. 틀이 돌립니다.

해 보기

1. docs/hypotheses.md를 만들고 지금까지 관찰한 숫자에서 가설 하나를 세 칸으로 적습니다.
2. 그 가설을 Issue 1건으로 옮깁니다. 하루 안에 끝나는 크기인지 확인합니다.
3. 계획 모드로 넘겨 최소 변경 계획을 받고, 승인 뒤 실행을 맡깁니다.
4. 공개하고 일주일 뒤 숫자를 보고, 학습 한 줄을 가설 파일에 적습니다.
5. 이 바퀴에 걸린 날수를 적습니다. 다음 바퀴의 목표는 그보다 하루 짧게입니다.

정리

• 루프는 여섯 단계이고, 공개와 관찰이 빠지면 루프가 아닙니다.
• 바퀴 수가 성과입니다. 짧게 만드는 기술이 앞 편들에 다 들어 있습니다.
• 가설은 바꾸는 것, 기대 숫자, 근거의 세 칸으로 적어 누적합니다.
• 빗나가면 되돌리고 학습만 남깁니다. 멈추면 틀을 문서로 고칩니다.

자주 묻는 질문