접는 기술

앞 편 리포팅을 AI에게 맡긴다에서 숫자와 기록이 자동으로 쌓이게 했습니다. 그 숫자가 몇 바퀴째 움직이지 않을 때 무엇을 해야 할까요. 이번 편은 접는 판단을 다룹니다. 접는 것은 실패가 아니라 루프의 정상 출구이며, 접을 때 무엇을 가져가느냐가 다음 프로젝트의 속도를 정합니다. 마지막 편 그래도 사람이 하는 일에서 코스 전체를 한 장으로 정리합니다.

핵심 요약

• AI는 시킨 것을 잘 만듭니다. 방향이 틀리면 틀린 것을 잘 만든 결과물이 쌓입니다.
• 다시 만드는 비용이 낮아졌으므로, 고치는 비용과 다시 만드는 비용을 매번 비교합니다.
• 접는 기준은 세 가지입니다. 숫자, 시간, 정의.
• 접을 때 가져가는 것은 코드가 아니라 문서, 규칙, 데이터, 검증된 프롬프트입니다.

처음 설계를 틀리면 올바른 쓰레기를 계속 양산한다

바이브 코딩의 무서운 점은 AI가 잘한다는 데 있습니다. Issue를 넘기면 완료 조건을 충족한 결과가 돌아오고, 테스트는 초록이고, 프리뷰도 잘 뜹니다. 그런데 애초에 그 도구를 아무도 원하지 않았다면, 이 모든 통과 판정은 틀린 방향으로 정확하게 걸어간 기록입니다. 우리 8주 교재 8주차에서 조율형 기능을 설명하며 "방향을 잘못 잡으면 잘못된 흐름으로 계속 간다"고 경고하는 것이 같은 이야기입니다.

손으로 코드를 짜던 시절에는 속도가 느려서 방향이 틀려도 쌓이는 양이 적었습니다. 지금은 하루에 Issue 세 건이 통과합니다. 방향 점검을 하지 않으면 한 달 뒤 정교하게 만들어진 쓸모없는 것이 남습니다. 그래서 접는 판단은 예외 절차가 아니라 루프에 내장된 정기 점검이어야 합니다.

다시 만드는 비용이 내려간 세계에서는

예전에는 "지금까지 만든 게 아까워서" 고쳐 쓰는 선택이 합리적이었습니다. 다시 만드는 데 몇 달이 들었기 때문입니다. 지금은 다릅니다. 문서가 제대로 있으면 같은 것을 다시 만드는 데 며칠이면 됩니다. 그러니 판단의 저울이 바뀝니다. 고치는 데 드는 시간과 문서만 들고 처음부터 다시 만드는 시간을 나란히 놓고 비교합니다.

이 비교가 가능하려면 두 가지가 있어야 합니다. 작업 시간 기록과 문서입니다. 5주차부터 작업 시간을 재게 하는 이유, 그리고 코스 내내 docs/에 그림, 완성 정의, 규칙, 가설을 적게 한 이유가 여기서 드러납니다. 시간 기록이 없으면 "고치는 게 빠를 것 같다"는 감으로 결정하고, 문서가 없으면 다시 만들 때 처음부터 다시 생각해야 합니다.

접는 판단의 기준

세 가지 기준 중 둘 이상에 걸리면 접습니다.

1. 숫자: 추적할 숫자가 두 바퀴 이상 움직이지 않았다. 가설을 바꿔도 마찬가지였다.
2. 시간: 최근 바퀴에서 고치는 데 든 시간이, 문서를 들고 다시 만드는 데 들 것으로 보이는 시간을 넘어섰다.
3. 정의: 통과시키려면 docs/output.md의 첫 공개 정의 자체를 바꿔야 한다. 결승선을 옮겨야만 골인할 수 있다면 그 경주는 끝난 것입니다.

예를 들어 봅니다. 정책지도사 수강생이 만든 공고 알림 도구가 있다고 합시다. 세 바퀴를 돌렸는데 동료의 원문 링크 클릭은 주 1건에서 움직이지 않았고(숫자), 마지막 바퀴에서 메일 형식을 고치는 데 이틀이 걸렸는데 문서를 들고 다시 만들면 하루면 될 것 같고(시간), 통과시키려면 첫 공개 정의를 "동료가 받는다"에서 "내가 받는다"로 낮춰야 합니다(정의). 셋 다 걸렸으니 접습니다. 대신 동료가 실제로 반응했던 것은 "상담 뒤 회의록이 바로 나오는 것"이었다는 관찰이 남습니다. 다음 주인공은 거기서 시작합니다.

하나만 걸리면 고칩니다. 숫자만 안 움직이는데 시간과 정의는 멀쩡하다면 가설이 부족한 것이지 방향이 틀린 것이 아닙니다. 판단은 리포트와 일지를 열어 놓고 합니다. 감이 아니라 앞 편에서 쌓아 둔 숫자로 결정하는 것이 바이브 코딩의 접기입니다.

@docs/reports/ @docs/journal.md @docs/hypotheses.md 를 읽고,
접기 기준 세 가지(숫자·시간·정의)에 각각 해당하는지 근거와 함께 판정해 줘.
결론은 "접는다" 또는 "고친다" 하나로.

이렇게 AI에게 판정 초안을 시켜도 됩니다. 단 결정은 사람이 합니다. 책임은 넘길 수 없기 때문입니다.

접을 때 남기는 것

접는다는 것은 코드를 버린다는 뜻입니다. 코드 외의 것은 전부 자산이므로 챙겨서 나옵니다.

1. 문서: docs/의 그림, 완성 정의, 안 할 목록, 가설과 결과. 다음 프로젝트의 첫날 재료입니다.
2. 규칙: CLAUDE.md와 .claude/rules/. 이 프로젝트에서 AI가 반복한 실수를 막으려고 적은 규칙은 다음 프로젝트에서도 그대로 통합니다. 사용자 수준 규칙은 ~/.claude/rules/에 두면 모든 프로젝트에 적용됩니다.
3. 데이터: 표준 항목으로 정리한 고객 DB, 수집된 공고, 계측 데이터. 7주차 교재의 한 문장, "DB 손실은 회사 종말"은 접을 때도 유효합니다. 코드는 버려도 데이터는 절대 버리지 않습니다.
4. 검증된 프롬프트: 잘 돌아갔던 Issue 문장, 황금 문장의 변형, 리포트 생성 명령. 8주차 개발 루프의 첫 단계 "미리 써 놓은 프롬프트"가 이것입니다.
5. 학습 한 줄: 왜 접었는지. 일지 마지막에 적습니다.

Claude Code에서 worktree로 작업했다면 세션을 종료할 때 커밋되지 않은 변경이 있는 경우 worktree를 유지할지 제거할지 묻습니다. 접기로 결정한 작업은 커밋해 두고 유지를 고르면 폴더와 브랜치가 남고, 정리하고 싶으면 git worktree remove로 지웁니다. 어느 쪽이든 커밋되어 GitHub에 올라간 것은 사라지지 않습니다.

코드는 지우지 않고 브랜치와 저장소를 보관만 합니다. GitHub에 남겨 두면 저장 비용은 없고, 나중에 일부를 참고할 수 있습니다. 새 프로젝트는 새 저장소에서 시작하되 첫 커밋에 위의 문서와 규칙을 그대로 옮겨 놓습니다.

해 보기

1. 현재 프로젝트의 리포트와 일지를 열고 세 기준을 하나씩 판정해 표로 적습니다.
2. 둘 이상 걸리면 접기로 결정하고, 위 다섯 가지를 새 폴더로 옮깁니다.
3. 하나 이하면 고치기로 결정하고, 어떤 가설을 다음 바퀴에 걸지 한 줄로 적습니다.
4. 어느 쪽이든 결정과 근거를 일지에 남깁니다.
5. 접었다면 새 저장소의 첫 Issue를 "옮겨 온 문서 기준으로 첫 공개 정의를 다시 적기"로 만듭니다.

정리

• AI는 방향을 묻지 않고 잘 만듭니다. 방향 점검은 사람이 정기적으로 합니다.
• 고치는 시간과 다시 만드는 시간을 기록으로 비교합니다.
• 기준은 숫자, 시간, 정의. 둘 이상 걸리면 접습니다.
• 가져가는 것은 문서, 규칙, 데이터, 프롬프트, 학습. 코드는 보관만 합니다.

자주 묻는 질문