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

개선 루프를 돌린다

가설→만들어 본다→공개→관찰→학습→다음 가설의 여섯 단계를 의지가 아니라 틀로 돌린다. 성과는 한 바퀴의 질이 아니라 바퀴 수로 정해지므로 항상 짧게, 반드시 공개를 포함해 돈다.

10분2026-08-22 갱신

계측을 먼저 심어 둔다까지로 만들고, 공개하고, 숫자를 주울 수 있는 상태가 됐습니다. 이 글은 그 위에서 가설→공개→관찰→학습을 계속 돌리기 위한 틀, 즉 의지에 기대지 않는 개선 루프를 다룹니다. 다음 글 리포팅을 AI에게 맡긴다에서는 루프가 돌기 시작한 뒤 생기는 숫자 보는 문제를 해결합니다.

여기까지로 만들고, 공개하고, 숫자를 주울 수 있는 상태가 됐습니다.

남은 건 계속 돌리는 것입니다. 솔직히 말하면 여기가 가장 어렵습니다. 만드는 데까지는 기세로 가지만 계속 돌리는 건 의지의 문제가 되기 때문입니다.

이 글에서는 의지에 기대지 않고 돌리기 위한 틀을 만듭니다.

루프의 전체 그림

한 바퀴는 여섯 단계입니다.

가설 → 만들어 본다 → 공개 → 관찰 → 학습 → 다음 가설

중요한 건 각 단계마다 질문을 하나씩 갖는 겁니다. 질문이 없으면 손만 움직이고 아무것도 안 남습니다.

단계하는 일거기서 갖는 질문
가설다음에 확인하고 싶은 걸 하나 정한다지금 가장 모르는 게 뭔가
만들어 본다확인할 수 있는 최소 형태로 만들게 한다이걸로 판가름이 나는가
공개실제로 만질 수 있는 데 내놓는다실서비스에 가까운 상태로 돌아가는가
관찰만져 본다·숫자를 본다가설은 맞았나, 빗나갔나
학습말할 수 있는 걸 한마디로 남긴다다음에 써먹을 배움이 뭔가
다음 가설배움을 바탕으로 다음 수를 정한다다음에 가장 모르는 게 뭔가

전부 통째로 넘긴다에서 넘기고, 알아서 공개되는 구조를 만든다에서 자동 공개되고, 계측을 먼저 심어 둔다에서 숫자가 주워진다. 여기까지 만들어 온 게 그대로 "만들어 본다 → 공개 → 관찰"의 세 단계가 돼 있습니다. 여러분이 할 일은 가설을 세우는 것과 배움을 남기는 것뿐입니다.

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

개선 루프의 성과는 한 바퀴의 질이 아니라 바퀴 수로 정해집니다.

한 바퀴에 한 달 걸리면 1년에 열두 번밖에 못 배웁니다. 한 바퀴가 하루면 365번 배웁니다. 같은 1년이라도 도달하는 데가 전혀 다릅니다.

그러니 애매하면 항상 짧게 가는 쪽을 고르세요.

  • 큰 가설보다 작은 가설
  • 완벽한 구현보다 판정 가능한 최소 구현
  • "전부 되고 나서 공개"보다 "오늘 된 만큼 공개"

그리고 하나 더, 꼭 지켜 줬으면 하는 규칙이 있습니다.

한 바퀴에는 반드시 "공개"를 포함한다.

내 컴퓨터에서 돌아가는 걸로 만족하고 멈추면 관찰이 안 생깁니다. 관찰이 없으면 학습도 없습니다. 그건 루프가 아니라 그냥 작업입니다.

자동 공개 글에서 자동 공개 구조를 만든 건 이 규칙을 의지가 아니라 구조로 지키기 위해서였습니다.

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

첫 바퀴에서 대개 뼈저리게 알게 됩니다.

돌아가는 건 금방 생긴다. 그런데 쓸 만해지지는 않는다.

AI에게 부탁하면 몇 시간 만에 돌아가는 게 손에 들어옵니다. 하지만 실제로 직접 써 보면 묘하게 누르기 불편하다, 생각한 데 정보가 없다, 두 번째 열 때는 귀찮다 — 이런 게 산더미로 나옵니다.

이 거리를 한 번에 점프해서 넘으려 하지 마세요. 숨이 찹니다.

거리는 바퀴 수로 메웁니다. 한 바퀴마다 불만 하나씩 잡는다. 그게 전부입니다. 여기서 "다시 만드는 게 빠르지 않을까" 싶어지지만 그 판단은 접는 기술까지 미뤄 두세요.

가설 세우는 법

"다음에 뭘 할지" 못 정하는 게 루프가 멈추는 가장 큰 이유입니다. 정하는 데는 우선순위가 있습니다.

  1. 내가 쓰면서 가장 짜증 났던 것 (최강. 여기서 시작합니다)
  2. 숫자가 생각보다 나빴던 곳 (계측 글에서 심은 게 효과를 냅니다)
  3. 누군가 말해 준 것 (다만 한 명의 의견은 가설이지 사실이 아닙니다)
  4. 왠지 좋아 보이는 신기능 (최약. 여기서 시작하지 마세요)

4번부터 시작하는 사람이 아주 많습니다. 신기능은 재밌으니까요. 하지만 지금 쓰기 불편한 것에 신기능을 더해 봤자 쓰기 불편한 게 늘어날 뿐입니다.

가설이 빗나갔을 때 접는 법

돌리다 보면 가설은 예사로 빗나갑니다. 빗나가는 것 자체는 실패가 아닙니다. 빗나갔다는 걸 알게 된 게 성과입니다.

문제는 만들게 한 걸 어떻게 접느냐입니다. 판단은 세 가지.

  • 버린다 — 검증용으로만 만든 것. 배움을 기록에 남겼으면 미련 없이 지웁니다
  • 다시 만든다 — 방향은 맞는데 너무 엉성하게 만들었다. 제대로 다시 만듭니다
  • 키운다 — 그대로 다음 바퀴로 가져갑니다

"모처럼 만들게 했으니까"로 남기는 게 가장 위험합니다. 다시 만드는 비용은 여러분이 생각하는 것보다 내려가 있습니다.

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

루프가 멈추는 건 대개 세 가지 패턴입니다.

가설이 너무 컸다 → 반으로 줄이세요. 그래도 크면 또 반으로.

관찰을 안 했다 → 공개한 뒤 스스로 한 번도 안 만져 봤을 겁니다. 만져 보세요. 숫자를 보기 전에 먼저 만집니다.

할 일이 너무 많아 못 고르겠다 → Issue가 너무 쌓였습니다. 이번 주에 안 할 건 솔직하게 닫으세요. 쌓인 Issue는 자산이 아니라 압박입니다.

해 보기

지금 공개돼 있는 걸 여러분 자신이 진심으로 써 보세요. 만든 사람이 아니라 쓰는 사람으로서.

그리고 짜증 났던 곳 세 개를 AI에게 말하세요. "지금 써 봤는데 여기랑, 여기랑, 여기가 싫었어. 가장 작은 걸 Issue로 만들어 줘. 가설이랑 '이렇게 되면 완료'를 넣는 형태로" — 문구는 AI가 다듬습니다. 여러분은 완성된 Issue의 "이렇게 되면 완료"만 채점하면 됩니다 (GitHub에 생각을 적는다의 기준입니다).

이 Issue를 넘기면 그다음은 통째로 넘기는 글과 같습니다. 루프는 이미 돌기 시작했습니다.

다음 글: 리포팅을 AI에게 맡긴다

자주 묻는 질문

바이브 코딩개선 루프가설 검증Issue공개

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

무료 상담 신청