전부 통째로 넘긴다

앞 편 아웃풋을 정한다에서 결승선을 적었습니다. 이제 실제로 AI에게 일을 넘깁니다. 이 편의 핵심은 "어떻게 만들지"를 말하지 않는 것입니다. 목적과 완료 조건만 넘기고, 돌아온 결과를 세 가지 중 하나로 판정합니다. 다음 편 알아서 공개되는 구조를 만든다에서는 이 위임이 끝까지 성립하도록 공개 과정까지 자동화합니다.

핵심 요약

• 지시는 절차를 말하고, 위임은 목적과 완료 조건을 말합니다. 바이브 코딩은 위임입니다.
• 넘기는 단위는 GitHub Issue 1건입니다. 한 문장으로 넘길 수 없으면 Issue가 너무 큽니다.
• 작업 중에는 끼어들지 않습니다. 끼어들고 싶은 충동은 Issue를 더 잘 적으라는 신호입니다.
• 돌아오면 사람은 통과, 반려, 폐기 중 하나만 고릅니다. 코드를 읽지 않습니다.

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

"먼저 파일을 열고, 함수를 만들고, 그 다음에 저장해"는 지시입니다. 지시를 하려면 절차를 알아야 하는데, 절차를 아는 사람은 이미 개발자입니다. 위임은 다릅니다. "공고 목록이 매일 아침 메일로 오게 해 줘. 완료 조건은 docs/output.md에 있어"라고 말하면 절차는 AI가 고릅니다.

같은 일을 두 방식으로 적어 보면 차이가 보입니다.

지시: 공고 페이지를 크롤링하는 파이썬 스크립트를 만들고, 결과를 CSV로 저장한 뒤,
      SMTP로 메일을 보내는 함수를 추가해.
위임: 매일 아침 8시에 새 공고 목록이 내 메일함에 와 있게 해 줘.
      완료 조건은 Issue #12에, 안 할 목록은 docs/output.md에 있어.

지시 쪽은 크롤링이 막히면 사람이 다시 방법을 정해 줘야 합니다. 위임 쪽은 AI가 공식 RSS가 있으면 그것을 쓰고, 없으면 다른 방법을 고릅니다. 사람이 몰라도 되는 결정을 사람이 붙들고 있지 않는 것이 위임입니다.

우리 8주 교재 5주차에서 좋은 요청의 4요소를 범위, 목적, 제약, 검증 기준으로 정리합니다. 이 넷에 절차는 없습니다. 황금 문장 "기존 기능은 지우지 말고, 원인을 먼저 분석한 뒤, 최소 수정으로, 수정 후 변경 파일과 테스트 방법을 정리해 줘"도 어떻게 고칠지는 한 마디도 말하지 않습니다. 무엇을 지키고 무엇이 나와야 하는지만 말합니다.

넘기는 단위는 "Issue 1건"

앞 편들에서 GitHub에 적어 둔 기획은 Issue로 쪼개져 있어야 합니다. 넘기는 단위가 Issue 1건인 이유는 두 가지입니다. 완료 조건이 Issue 안에 이미 적혀 있으므로 사람이 다시 설명할 필요가 없고, 1건이 끝나면 통과나 반려를 판정할 수 있을 만큼 작기 때문입니다.

Claude Code에게 넘기는 문장은 이 정도면 됩니다.

Issue #12를 구현해 줘. 완료 조건은 Issue 본문에 있고,
프로젝트 규칙은 CLAUDE.md, 완성 정의는 @docs/output.md를 따라.
끝나면 무엇을 바꿨고 어떻게 확인했는지 보고해 줘.

이 한 문장으로 넘길 수 없다면 Issue가 너무 크거나 완료 조건이 빠진 것입니다. 5주차 교재의 예처럼 "고객 상담 관리 시스템"은 Issue가 아니라 기획이고, "고객 목록 화면"부터 "주간 요약 보고서"까지 여섯 단계로 쪼갠 각각이 Issue입니다.

Claude Code GitHub Actions를 설정해 두면 Issue 댓글에 @claude implement this feature based on the issue description처럼 멘션하는 것만으로 같은 위임이 됩니다. 설정은 Claude Code 안에서 /install-github-app을 실행하면 안내를 따라 진행되며, 저장소 시크릿에 ANTHROPIC_API_KEY가 필요합니다.

중간에 손대고 싶어지는 병

AI가 일하는 화면을 보고 있으면 "그쪽이 아닌데"라는 생각이 듭니다. 그때 끼어들면 두 가지를 잃습니다. AI는 방향을 잃고 지금까지의 맥락에 내 즉흥 지시가 섞이며, 나는 결과가 나쁠 때 원인이 Issue였는지 내 끼어들기였는지 알 수 없게 됩니다.

Claude Code의 권한 모드가 이 습관을 돕습니다. Pro·Max·Team에서는 auto 모드가 기본이라 별도 분류기가 위험한 작업만 걸러내고 나머지는 멈추지 않고 진행하며, Manual(default)로 바꾸면 파일 편집마다 승인을 묻습니다. acceptEdits는 작업 폴더 안의 파일 편집을 묻지 않고 진행합니다. Shift+Tab으로 모드를 순환하고, 시작할 때 claude --permission-mode acceptEdits처럼 지정할 수도 있습니다. 방향이 정해졌으면 승인 버튼을 누르는 자리에서 물러나는 것이 위임입니다.

우리 8주 교재 8주차의 개발 루프도 같은 구조입니다. 계획 모드로 방향을 정하고, 실행은 맡기고, 끝난 뒤에 교차 검수합니다. 실행 중간에 개입하는 단계는 없습니다.

넘긴 뒤 사람이 하는 세 가지

돌아온 결과 앞에서 사람이 고를 수 있는 것은 셋뿐입니다.

1. 통과: 완료 조건을 충족했고 증거(실행 화면, 로그)가 있다. 커밋하고 다음 Issue로.
2. 반려: 방향은 맞는데 완료 조건 일부가 빠졌다. 빠진 조건을 Issue에 추가해서 다시 넘긴다.
3. 폐기: Issue 자체가 잘못됐다. 브랜치를 버리고 Issue를 다시 적는다.

판정의 기준은 코드가 아니라 증거입니다. 우리 교육의 정지 규칙이 "증거"인 이유입니다. 테스트가 통과했다는 로그, 실제로 메일이 도착한 화면, 실행 결과 파일. 이 중 하나라도 없으면 통과가 아닙니다.

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

엉뚱한 결과가 반복되면 AI를 바꾸거나 프롬프트를 길게 늘이고 싶어집니다. 그 전에 점검할 곳은 하나, 문서입니다. Issue의 완료 조건이 흐릿하지 않은가, CLAUDE.md의 규칙이 서로 충돌하지 않는가, docs/output.md의 안 할 목록에 빠진 것이 없는가. 공식 문서도 CLAUDE.md는 구체적이고 짧을수록 잘 지켜진다고 안내하며, 파일당 200줄 이하를 권장합니다. 규칙이 모순되면 AI가 임의로 하나를 고릅니다. 결과가 이상하면 AI가 아니라 문서를 고치는 것이 바이브 코딩의 디버깅입니다.

해 보기

1. Issue 1건을 골라 완료 조건이 세 줄 이내로 적혀 있는지 확인합니다.
2. 위의 한 문장 템플릿으로 Claude Code에 넘깁니다. 끝날 때까지 화면을 보지 않습니다.
3. 돌아온 보고에서 증거를 찾습니다. 없으면 "확인한 증거를 보여 줘"라고 한 번만 더 요청합니다.
4. 통과, 반려, 폐기 중 하나를 고르고 Issue에 판정을 적습니다.
5. 반려나 폐기였다면 Issue 문서에서 무엇이 흐릿했는지 한 줄 적어 둡니다.

정리

• 위임은 목적과 완료 조건을 넘기는 것이고, 절차는 AI가 고릅니다.
• 단위는 Issue 1건, 한 문장으로 넘길 수 있어야 합니다.
• 작업 중 개입하지 않고, 돌아오면 통과·반려·폐기만 고릅니다.
• 결과가 나쁘면 AI가 아니라 문서를 점검합니다.

자주 묻는 질문