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

전부 통째로 넘긴다

절차를 지시하지 말고 목적과 완료 조건을 위임합니다. Issue 1건을 한 문장으로 넘기고, 중간에 끼어들지 않고, 돌아오면 통과·반려·폐기 중 하나만 고르면 첫 바퀴가 돕니다.

9분2026-08-22 갱신

준비를 마치고 드디어 넘기는 글입니다. 앞 글 아웃풋을 정한다까지로 리포지토리에 생각·규칙·인터페이스·성공의 정의가 갖춰졌으니, 이제 Issue 1건을 한 문장으로 위임하고 돌아온 결과를 판단하는 법을 익힙니다. 다음 글 알아서 공개되는 구조를 만든다에서는 승인하면 자동으로 공개되는 구조를 만듭니다.

준비가 끝났습니다. README에 생각이 있고, Issue가 줄지어 있고, CLAUDE.md에 규칙이 있고, 인터페이스와 아웃풋이 정해져 있습니다.

여기서부터는 넘기기만 하면 됩니다.

"지시"가 아니라 "위임"

많은 사람이 여기서 걸립니다. 넘어지는 방식은 정해져 있는데, 지시를 내리려고 한다는 겁니다.

"먼저 이 파일을 만들고, 다음에 이 처리를 쓰고, 그다음 여기를 고쳐 줘" — 이렇게 쓰고 싶어집니다. 공들인, 친절한 부탁 같은 기분이 들죠.

하지만 이건 내가 구현 방법을 안다는 전제의 부탁법입니다. 모르면서 절차를 지정하면 대개 틀린 절차를 지정하게 됩니다. 그리고 AI는 그 틀린 절차를 충실히 따릅니다.

넘겨야 할 건 절차가 아니라 목적과 완료 조건입니다.

넘기는 법결과
절차를 지시한다"◯◯라는 파일을 만들고 △△를 써 줘"내 이해 범위를 못 넘는다
목적을 위임한다"Issue #3을 구현해 줘. 완료 조건은 Issue에 적혀 있어"나보다 나은 방법이 돌아올 때가 있다

GitHub에 생각을 적는다에서 Issue를 제대로 적은 건 이 한 줄로 넘기기 위해서였습니다. 준비만 돼 있으면 넘기는 작업 자체는 정말 한 줄이면 끝납니다.

넘기는 단위는 "Issue 1건"

가장 다루기 쉬운 방식은 이겁니다.

"Issue #3을 구현해 주세요. 완료되면 풀 리퀘스트로 올려 주세요."

이게 전부입니다. 풀 리퀘스트를 올리는 Git 조작도 AI가 대신하니, 명령어가 낯설면 Git 조작 자동화를 한 번 훑어 두면 됩니다.

왜 Issue 1건일까요. 돌아온 걸 여러분이 판단할 수 있는 크기이기 때문입니다. 5건을 묶어서 넘기면 돌아온 것의 뭐가 어디에 대응하는지 알 수 없어서 좋고 나쁨을 판단할 수 없습니다. 판단할 수 없으면 승인도 반려도 못 합니다.

중간에 손대고 싶어지는 병

넘긴 뒤, AI가 작업하는 화면이 흘러갑니다. 여기서 많은 사람이 걸리는 병이 있습니다.

"아, 그게 아니라"라고 끼어들고 싶어지는 병입니다.

마음은 압니다. 다만 끼어들기 전에 이것만 확인하세요.

  • 완료 조건에서 벗어났는가? 벗어났다면 멈춰야 합니다.
  • 완료 조건은 채우는데 방식이 내 상상과 다를 뿐인가? 그렇다면 잠자코 끝까지 보세요.

대부분은 후자입니다. 그리고 후자일 때 AI의 방식이 더 나은 경우가 제법 있습니다. 여러분은 구현 전문가가 아니니 당연합니다.

중간에 손대는 건 구현을 아는 사람의 방식입니다. 모르는 사람이 하면 그냥 품질만 떨어뜨립니다.

보는 건 완성품입니다.

넘긴 뒤 사람이 하는 세 가지

통째로 맡기기는 "아무것도 안 하기"가 아닙니다. 할 일이 세 가지로 좁혀지는 겁니다.

기다린다

가장 어려운 일입니다. 몇 분에서 몇십 분, 아무것도 생산하지 않는 시간을 견뎌야 합니다.

못 견디겠으면 그 시간에 다른 Issue를 다른 곳에 넘기세요(동시에 여러 개 굴린다). 아니면 커피를 내리세요. 화면을 뚫어져라 봐도 빨라지지 않습니다.

본다

돌아오면 실제로 돌려 봅니다. 코드는 안 읽어도 됩니다. 못 읽어도 됩니다.

볼 건 하나뿐입니다.

Issue에 적은 "이렇게 되면 완료"를 채우는가.

채우면 합격입니다. "좀 더 이렇게 하고 싶다"는 합격시킨 다음 새 Issue로 만듭니다. 한 번의 주고받기로 완벽을 노리지 마세요.

판단한다

판단은 세 종류뿐입니다.

  • 통과 — 완료 조건을 채웠다. 머지한다.
  • 반려 — 못 채웠다. "◯◯가 안 됩니다"라고만 전한다. 원인 추측은 안 해도 된다.
  • 폐기 — 애초에 이 Issue가 잘못이었다. 닫는다.

세 번째를 고를 수 있게 되면 한 단계 강해집니다. 만들게 한 걸 버리는 판단은 접는 기술에서 다룹니다.

제대로 안 돌아올 때, 점검할 곳은 하나

넘겨도 엉뚱한 것만 돌아오는 시기가 반드시 옵니다.

그때 프롬프트 쓰는 법을 궁리하려 하지 마세요. 점검할 곳은 거의 언제나 여기입니다.

Issue의 "이렇게 되면 완료"가 애매하다.

"쓰기 편하게 한다", "느낌 좋게 한다", "보기 좋게 한다" — 이렇게 적혀 있으면 AI는 매번 다르게 해석합니다. 여러분도 매번 다른 불만을 갖습니다. 영원히 안 끝납니다.

어긋났다 싶으면 AI를 고치지 말고 Issue를 고치세요. 바이브 코딩의 디버깅은 코드가 아니라 한국어 문장에 하는 겁니다.

해 보기

GitHub에 생각을 적는 글에서 세운 Issue 중 가장 작은 1건을 골라 다음 한 문장만 넘겨 보세요.

"Issue #1을 구현해 주세요. 완료되면 풀 리퀘스트로 올려 주세요."

그리고 끝까지 끼어들지 말고 지켜보세요. 돌아오면 Issue의 "이렇게 되면 완료"와 대조해서 통과/반려/폐기 중 하나를 고릅니다.

이게 첫 바퀴입니다.

다음 글: 알아서 공개되는 구조를 만든다

자주 묻는 질문

바이브 코딩Issue풀 리퀘스트위임완료 조건

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

무료 상담 신청