내가 잠든 사이 코드를 배포하는 4-에이전트 Claude Code 파이프라인을 구축했다

잠들기 전 명령어를 하나 입력합니다. 아침이 되면: 작성된 명세서(spec), 실제 코드, 이미 실행된 테스트, 그리고 SHIP(배포 가능), NEEDS WORK(수정 필요), 또는 BLOCK(차단) 판정이 당신을 기다리고 있습니다. 이것이 Claude Code 에이전트 파이프라인의 핵심 아이디어이며, 일단 실행되면 AI를 사용하여 소프트웨어를 작성하는 방식에 대한 당신의 생각을 바꿔놓을 것입니다.

대부분의 사람들이 빠지는 루프

Claude에게 계획을 세워달라고 하면 계획을 세웁니다. 코드를 작성해달라고 하면 코드를 작성합니다. 테스트를 요청하면 테스트를 합니다. 그 과정 어딘가에서 당신은 여전히 단계마다 컨텍스트(context)를 전달하고 있으며, 다음에 무엇이 일어날지 결정하는 사람으로 남아 있습니다. 당신이 타이핑을 멈추는 순간, 모든 것이 멈춥니다. 이것은 프롬프팅(prompting)의 문제가 아니라 아키텍처(architecture)의 문제입니다. 해결책은 하나의 명령에 의해 트리거되어 서로에게 자동으로 업무를 인계하는 네 명의 전문 에이전트입니다.

인계(Handoff): 공유된 컨텍스트 창이 아닌 공유된 폴더

이 방식이 실제로 신뢰할 수 있게 만드는 부분은 간단합니다. 각 에이전트는 자신의 출력물을 .pipeline/ 폴더 내의 파일에 작성하며, 다음 에이전트는 그 파일을 읽어 마지막 에이전트가 멈춘 지점에서 정확히 작업을 이어받습니다.

.pipeline/spec.md          <- Planner가 작성
.pipeline/changes.md       <- Coder가 작성
.pipeline/test-results.md  <- Tester가 작성
...

하나의 폴더, 네 개의 파일. 무언가 고장 나면, 그중 아무 파일이나 열어서 해당 에이전트가 어떤 데이터를 가지고 작업했는지 정확히 확인할 수 있습니다.

네 명의 에이전트

각 에이전트는 Claude Code subagent입니다: 좁은 범위의 작업, 고유한 격리된 컨텍스트(isolated context), 하나의 출력물을 가집니다.

Planner는 절대 코드를 작성하지 않습니다. 코드베이스(codebase)를 읽고, 사물들이 실제로 어떻게 구축되어 있는지 이해하며, 명세서(spec)를 작성합니다: 어떤 파일이 변경되는지, 어떤 함수가 필요한지, 예외 케이스(edge cases), 미결 질문 사항 등을 작성합니다.

Coder는 그 명세서를 읽고 코드베이스에 이미 존재하는 패턴을 따라 명세서에 적힌 그대로를 구축합니다. 범위를 이렇게 엄격하게 유지하는 것이, 에이전트가 당신이 건드려달라고 요청하지 않은 것들을 조용히 재작성하는

Tester는 Coder가 구축한 내용을 읽고 일반적인 케이스(normal case), Planner가 지적한 엣지 케이스(edge cases), 그리고 최소 하나 이상의 실패 케이스(failure case)에 대한 테스트를 작성한 뒤 실제로 실행합니다. 만약 무언가 실패하면, 코드를 스스로 패치하려고 시도하는 대신 중단하고 보고합니다.

Reviewer는 최종 관문입니다. 사양(spec), 변경 사항, 테스트 결과를 읽고 diff를 실행하여 SHIP, NEEDS WORK, 또는 BLOCK 중 하나의 판결을 내립니다. 설계상 읽기 전용(read-only)입니다. 문제를 지적할 수는 있지만 수정할 수는 없으며, 이를 통해 한 에이전트가 코드를 작성하고 스스로의 숙제에 점수를 매기는 상황을 방지합니다.

하나의 명령어로 연결하기

이 네 가지를 프로젝트 스킬(.claude/skills/ship/SKILL.md)로 저장된 오케스트레이터(orchestrator)로 감쌉니다. 그런 다음 다음과 같이 입력합니다:

/ship add rate limiting to the login endpoint

오케스트레이터는 당신의 요청을 Planner에게 보내고, 사양(spec)이 나올 때까지 기다린 후, 이를 Coder에게 전달하고, 코드가 나올 때까지 기다린 후, Tester에게 전달하여 결과를 기다리고, 모든 것을 Reviewer에게 전달하여 최종 판결을 보여줍니다. 한 줄의 입력으로 네 명의 에이전트가 순차적으로 실행되어 하나의 완전한 기능이 출력됩니다. 이는 Anthropic이 서브 에이전트를 순차적으로 체이닝(chaining subagents in sequence)하는 방식에 대해 설명한 것과 동일한 패턴입니다. 즉, 각자 고유한 컨텍스트를 가진 전문화된 작업자들이 오케스트레이션 지침 세트에 의해 하나로 묶이는 것입니다.

실제로 무엇이 변하는가

여기서의 변화는 "AI가 코드를 더 빨리 작성한다"가 아닙니다. 계획에서 코드, 테스트, 리뷰로 이어지는 과정을 수동으로 연결하던 사람이 당신이 아니게 된다는 점입니다. 당신은 완성된 결과물을 검토하고 무엇을 배포할지 결정하는 사람이 됩니다. /ship이 테스트가 완료된 기능과 명확한 판결을 저에게 처음 전달해 주었을 때, 제 하루 일과를 계획하는 방식이 바뀌었습니다. 저는 AI를 돌보느라 시간을 할애하는 것을 멈추고, 이미 완료된 작업을 검토하는 데 시간을 할애하기 시작했습니다.

직접 시도해 보세요

저는 ship.md 오케스트레이터(orchestrator)와 .claude/skills/ 및 .claude/agents/ 디렉토리에 바로 사용할 수 있는 4개의 에이전트 설정 파일을 포함하여, 즉시 실행 가능한 5개의 전체 파일을 담은 상세 가이드를 작성했습니다: 내가 잠든 사이 코드를 배포하는 4-에이전트 Claude Code 파이프라인 구축 방법. 그곳에서 무료 키트를 가져와서 본인의 리포지토리(repo)에 맞게 경로와 제약 조건(constraints)을 조정하면, 약 10분 안에 자신만의 /ship 명령어를 실행할 수 있습니다.