Claude Code를 AI 개발팀으로 쓰기: 단독 사용 vs 오케스트레이션의 차이

Claude Code는 강력한 단일 에이전트입니다. 하지만 실제 개발 작업에서 "한 세션에 전부 시키는 것"과 "역할을 나눠 오케스트레이션하는 것"의 결과는 눈에 띄게 다릅니다. 이 글은 그 차이가 어디서 오는지, 그리고 탐색·계획·구현·검증을 분리한 워크플로가 왜 실무에서 더 나은지를 정리합니다.

단일 에이전트가 벽에 부딪히는 순간

작은 작업 — 함수 하나 고치기, 테스트 하나 추가하기 — 은 단일 세션이 최선입니다. 컨텍스트가 짧고, 계획이 필요 없고, 검증이 즉각적이니까요. 오케스트레이션은 오히려 오버헤드입니다.

문제는 작업이 커질 때 시작됩니다. "결제 실패 재시도 로직을 추가해줘" 같은 요청은 여러 파일을 읽고, 기존 패턴을 파악하고, 여러 곳을 수정하고, 회귀를 확인해야 합니다. 단일 세션에서 이걸 한 번에 시키면 세 가지가 무너집니다.

• 컨텍스트 오염: 탐색하며 읽은 20개 파일의 내용이 구현 단계까지 컨텍스트에 남아, 정작 중요한 결정 순간에 노이즈가 됩니다.
• 조기 확정: 충분히 탐색하기 전에 첫 번째 그럴듯한 접근으로 코드를 쓰기 시작합니다. 나중에 더 나은 패턴을 발견해도 되돌리기 비쌉니다.
• 검증 누락: 자기가 짠 코드를 자기가 검토하면 같은 사각지대를 공유합니다. "된다고 생각한 것"과 "실제로 되는 것"의 간극이 남습니다.

오케스트레이션은 문제를 나누는 게 아니라 컨텍스트를 나눈다

흔한 오해는 오케스트레이션을 "작업 쪼개기"로 보는 것입니다. 핵심은 작업이 아니라 컨텍스트를 격리하는 것입니다.

• 탐색(Explore) 은 넓게 읽되, 결론만 남기고 파일 덤프는 버립니다. 상위 에이전트는 "이 로직은 payment.service.ts:220에 있고 재시도는 없다"는 요약만 받습니다.
• 계획(Plan) 은 그 요약 위에서 무엇을·어디를·어떤 순서로 바꿀지를 정합니다. 코드를 쓰지 않으므로 접근을 자유롭게 비교·폐기할 수 있습니다.
• 구현(Implement) 은 확정된 계획을 깨끗한 컨텍스트에서 실행합니다. 탐색의 노이즈 없이 결정에 집중합니다.
• 검증(Verify) 은 구현하지 않은 별도 관점에서 빌드·테스트·회귀를 확인합니다. 저자와 리뷰어가 다르면 사각지대가 겹치지 않습니다.

각 단계가 다음 단계에 넘기는 것은 전체 대화 기록이 아니라 압축된 결론입니다. 이것이 긴 작업에서 품질이 유지되는 이유입니다.

실제 워크플로: "결제 재시도 로직 추가"

단일 세션과 오케스트레이션이 같은 요청을 어떻게 다르게 처리하는지 비교해 보겠습니다.

단일 세션의 전형적 경로

• 파일 몇 개를 열어 보고 → 바로 재시도 코드를 작성 → 타입 에러가 나서 고치고 → 테스트가 깨져서 또 고치고 → 기존 지수 백오프 유틸이 이미 있다는 걸 뒤늦게 발견. 컨텍스트는 이미 절반이 시행착오 로그로 차 있습니다.

오케스트레이션의 경로

• 탐색이 먼저 코드베이스를 훑어 "재시도 관련 유틸이 utils/backoff.ts에 이미 있고, 결제 호출은 3곳에서 일어난다"를 보고합니다.
• 계획은 그 사실 위에서 "새 유틸을 만들지 말고 기존 backoff를 재사용, 3곳을 공통 래퍼로 감싸고, 실패 로그는 기존 logger 규약을 따른다"는 구체적 순서를 세웁니다.
• 구현은 깨끗한 상태에서 이 계획대로만 씁니다. 이미 유틸이 있다는 걸 알고 시작하므로 중복 구현이 없습니다.
• 검증은 빌드·타입체크·기존 결제 테스트를 돌려 회귀가 없는지 확인합니다.

결과물의 라인 수는 비슷할 수 있습니다. 하지만 오케스트레이션 버전은 기존 패턴을 재사용하고, 시행착오가 최종 코드에 스며들지 않으며, 검증이 실제로 수행됩니다.

루틴 작업은 애초에 LLM이 할 일이 아니다

오케스트레이션의 절반은 "무엇을 LLM에게 시키지 않을지"를 정하는 것이기도 합니다. 빌드 실행, 로그 파싱, 코드 검색, 파일 조회 같은 결정론적 루틴 작업은 매번 토큰을 태워 가며 LLM에게 시킬 이유가 없습니다.

RoutineCode의 설계 원칙이 여기서 나옵니다 — "루틴 작업 = MCP 도구(토큰 0), 비루틴 = LLM". 빌드가 통과했는지, 테스트가 몇 개 깨졌는지, 특정 심볼이 어디 정의됐는지는 도구가 정확히·즉시·무료로 답합니다. LLM의 추론 예산은 오직 판단이 필요한 곳 — 어떤 접근을 택할지, 이 에러의 진짜 원인이 무엇인지 — 에만 씁니다.

그 결과 같은 작업을 하더라도 유료 토큰 소모가 크게 줄고, 무엇보다 컨텍스트가 루틴 작업의 출력으로 오염되지 않습니다.

실패했을 때 같은 길을 네 번 가지 않기

단일 에이전트의 흔한 실패 양상은 "안 되는 방법을 반복하는 것"입니다. 수정이 안 먹히면 거의 같은 코드를 다시 시도하고, 또 실패하고, 컨텍스트만 소모합니다.

오케스트레이션 관점에서는 실패가 곧 전략 전환 신호입니다. 같은 접근을 정해진 횟수 이상 반복하면 접근 자체를 버리고 다른 경로 — 다른 가설, 다른 파일, 다른 도구 — 로 갈아탑니다. 저자와 검증자가 분리돼 있으면 "이 방법은 이미 두 번 실패했다"는 사실이 객관적으로 남아 무한 루프를 끊습니다.

세션이 끝나도 배운 것은 남는다

단일 세션의 근본 한계는 세션이 끝나면 맥락이 증발한다는 것입니다. 지난주에 고생해서 고친 라이브러리 특이 동작을, 다음 세션의 에이전트는 처음 보는 것처럼 다시 만납니다.

오케스트레이션 구조에서는 검증까지 통과한 결론 — 에러 수정, 도메인 특이사항, 폐기된 접근 — 을 영구 저장소에 남깁니다. 실제 결과로 검증된 지식만 축적되므로, 세션을 거듭할수록 탐색 단계가 짧아지고 같은 실수를 반복하지 않습니다. 단일 세션에는 이 복리 효과가 없습니다.

언제 오케스트레이션을 쓰고, 언제 안 쓰는가

오케스트레이션은 만능이 아닙니다. 판단 기준은 단순합니다.

• 단일 세션이 맞는 경우: 한두 파일 안에서 끝나는 명확한 작업, 계획이 필요 없는 수정, 즉각 검증 가능한 변경.
• 오케스트레이션이 이기는 경우: 여러 파일에 걸친 기능, 기존 패턴 파악이 선행돼야 하는 작업, 회귀 위험이 있는 변경, 반복되는 유형의 작업(축적된 지식이 효과를 내는 지점).

핵심은 "항상 나눠라"가 아니라 "작업 규모에 맞게 컨텍스트를 격리하라"입니다.

---

한 줄 요약: 오케스트레이션의 본질은 작업 쪼개기가 아니라 컨텍스트 격리다. 탐색은 노이즈를 버리고 결론만 넘기고, 계획은 코드 없이 접근을 확정하고, 구현은 깨끗한 상태에서 실행하고, 검증은 다른 관점에서 확인한다. 루틴 작업은 도구에 맡겨 토큰과 컨텍스트를 아끼고, 검증된 지식은 세션을 넘어 축적한다. 그래서 작업이 커질수록 단일 에이전트보다 오케스트레이션이 이긴다.