본문 바로가기
claudecode.to
문서 목록
바이브 코딩 코스중급

접는 기술

바이브 코딩에서 가장 무서운 실패는 틀린 방향으로 고품질 결과물이 쌓이는 것입니다. 다시 만드는 비용이 내려간 세계에서 접을지 고칠지를 가르는 세 가지 기준과, 접을 때 코드 대신 수확해 가는 자산을 정리합니다.

8분2026-08-22 갱신

앞 글 리포팅을 AI에게 맡긴다에서 숫자와 일지가 리포지토리에 쌓이기 시작했습니다. 이 글은 그 기록을 들고 가장 인정하기 싫은 판단 — 이 프로젝트를 접을 것인가 — 을 내리는 법을 다룹니다. 접는 기준 세 가지와 접을 때 남기는 수확 목록을 익히고 나면, 마지막 글 그래도 사람이 하는 일에서 코스 전체를 한 장의 체크리스트로 돌아봅니다.

루프를 돌리다 보면 언젠가 반드시, 인정하기 싫은 아침이 옵니다.

"이거, 뿌리부터 잘못됐던 거 아닐까?" 하는 아침입니다.

이 글은 그 아침을 위한 글입니다.

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

겪어 보니 바이브 코딩에서 가장 무서운 실패는 AI의 폭주도, 품질 저하도 아니었습니다.

틀린 방향으로 고품질의 결과물이 계속 쌓이는 것입니다.

AI는 여러분이 정한 방향으로 빠르고 착실하게 나아갑니다. 방향이 틀렸어도 멈추지 않습니다. Issue는 소화되고, 풀 리퀘스트는 통과되고, 기능은 늘어난다. 한 바퀴마다 "제대로 가고 있다"는 느낌이 있다. — 가고 있는 게 잘못된 길이어도 느낌은 똑같습니다.

저는 이걸 "올바른 쓰레기의 양산"이라고 부릅니다. 하나하나의 결과물은 올바르다. 쌓아 올린 전체가 쓰레기. 손으로 만들던 시대라면 한 달 걸렸을 양의 쓰레기가 지금은 일주일이면 쌓입니다. 생산성 향상은 쓰레기 생산에도 똑같이 작동합니다.

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

여기서 낡은 상식 하나를 버릴 필요가 있습니다.

손으로 쓰던 시대에 "다시 만들기"는 최후의 수단이었습니다. 몇 달의 노력이 사라지니까요. 그래서 다소 뒤틀려 있어도 고쳐 가며 계속 쓰는 게 합리적이었습니다.

지금은 다릅니다. **리포지토리에 생각과 결정이 적혀 있으면(GitHub에 생각을 적는다부터 아웃풋을 정한다까지 다섯 글에서 한 일입니다) 다시 만드는 데 며칠이면 됩니다.** README, CLAUDE.md, docs/의 결정 메모, Issue의 일지 — 쌓아 올린 말은 전부 재사용할 수 있습니다. 잃는 건 코드뿐이고, 코드는 이 세계에서 가장 재생산이 싼 자재입니다.

고치는 것보다 버리고 다시 만드는 게 빠르다 — 이 선택지가 항상 현실적으로 테이블 위에 있다.

이게 새로운 상식입니다.

접는 판단의 기준

그렇다고 매번 제로부터 다시 만들면 아무것도 안 쌓입니다. 접을 것인가 고칠 것인가. 기준을 세 개 두세요.

1. 숫자가 세 바퀴 연속 침묵하고 있다

계측을 먼저 심어 둔다에서 정한 숫자가 세 바퀴를 고쳐도 안 움직인다. 이건 구현의 문제가 아니라 가설(머릿속 그림을 말로 옮긴다의 문제 짚기)이 빗나갔다는 신호입니다. 고치기를 멈추고 머릿속 그림까지 돌아가세요.

2. 고치는 Issue만 늘고 있다

Issue 목록을 봤을 때 "새로 이렇게 하고 싶다"보다 "여기가 이상하니 고친다"가 다수파면 토대가 뒤틀린 겁니다. 뒤틀린 토대 위의 수선은 아무리 해도 안 끝납니다.

3. 내가 안 쓰고 있다

가장 잔혹하고 가장 정확한 기준입니다. 만든 본인이 안 쓰는 건 방향째 틀린 겁니다. 누구보다 먼저 여러분이 이탈해 있으니까요.

뒤집어 말하면, 이 셋에 해당하지 않으면 그건 그냥 "기분이 안 나는 날"입니다. 접지 말고 작은 Issue 하나만 돌리세요.

접을 때 남기는 것

접기로 정했다면 할 일은 "삭제"가 아닙니다. 수확입니다.

## 접기 전 수확 목록
- README와 docs/ 전부 → 다음 리포지토리에 그대로 가져간다
- 네 줄 일지 전부 → "빗나간 가설 목록"이라는 보물. 같은 구덩이에 다시 안 빠진다
- CLAUDE.md → 나와 AI 사이에서 키운 약속. 프로젝트를 넘어 유효
- 접은 이유 → 마지막 일지로 한 장 적는다. "뭐가 빗나갔는가"를 한마디로

코드는 남기지 않습니다. GitHub는 지운 것도 이력에 남겨 주니 정확히는 "버려도 사라지지 않는" 것이지만, 다음 프로젝트로 들고 가지 않는 게 중요합니다.

눈치채셨나요. 수확 목록의 내용물은 이 코스에서 여러분이 직접 적어 온 것뿐입니다. AI가 쓴 건 안 가져간다. 내가 쓴 것만이 자산으로 남는다. 바이브 코딩의 자산이 뭐냐는 질문의 답이 여기 있습니다.

해 보기

지금 돌리고 있는 프로젝트를 세 가지 기준으로 건강검진 해 보세요.

  1. 숫자는 움직이고 있는가 (세 바퀴 연속 침묵하고 있지 않은가)
  2. Issue 목록은 "하고 싶다"가 다수파인가, "고치고 싶다"가 다수파인가
  3. 나는 이번 주에 이걸 썼는가

셋 다 노란불이면 AI에게 수확 목록을 정리하게 하세요 ("이 리포지토리를 접을 거야. README, docs, 일지에서 다음에 가져갈 걸 수확 목록으로 만들어 줘"). 다 적힐 때쯤이면 아마 다음 아이디어가 시작돼 있을 겁니다. 그건 패배가 아니라 더 큰 루프가 한 바퀴 돈 것뿐입니다.

다음 글: 그래도 사람이 하는 일

자주 묻는 질문

바이브 코딩철수 판단재구축수확 목록Issue

팀에 Claude Code를 도입하려면 실제 코드베이스에 맞춘 설계가 필요합니다.

무료 상담 신청