당신의 코딩 에이전트(coding agent)는 집중된 작업 하나를 혼자서 완료할 수 있습니다. 문제는 변경 사항이 소유권 경계를 넘어갈 때 시작됩니다. 한 에이전트가 API를 업데이트하고, 다른 에이전트가 그 소비자를 변경하며, 세 번째 에이전트가 테스트를 수정하는데, 아무도 완료(definition of done)에 대한 공유된 정의를 가지고 있지 않은 상황 말입니다.

그것이 기본적으로 스웜(swarm)을 가동해야 하는 이유는 아닙니다. 그것은 조정 형태(coordination shape)를 의도적으로 선택해야 하는 이유입니다.

인간-에이전트 팀(human-agent teams)에 대한 Anthropic의 최근 가이드는 프로덕션 엔지니어링(production engineering)을 위한 유용한 구분을 제공합니다. 에이전트의 자율성을 높이기 전에 에이전트에게는 가시적인 컨텍스트(context), 명확하게 범위가 지정된 역할(scoped roles), 그리고 검증 경로(verification paths)가 필요합니다. Claude Code 문서 또한 조정된 **에이전트 팀(agent teams)**을 더 좁은 위임 패턴(delegation patterns)과 구분합니다. 에이전트 팀은 아직 연구 프리뷰(research preview) 단계이므로, 이를 즉시 도입 가능한 프로덕션 플랫폼이 아닌 테스트해야 할 운영 패턴으로 취급하십시오.

결정: 하나의 에이전트, 서브에이전트, 아니면 팀?

정확성을 유지할 수 있는 가장 작은 조정 모델을 사용하십시오.

팀이 자동으로 더 빠른 것은 아닙니다. 조정(Coordination)은 토큰(tokens), 대기 시간, 그리고 작업을 중복할 수 있는 더 많은 방법을 추가합니다. 만약 두 작업자가 서로의 중간 결과물을 볼 필요가 없다면, 그들을 격리된 상태로 유지하고 하나의 에이전트가 결과를 합성(synthesize)하도록 하십시오.

이는 에이전트 트레이스를 회귀 테스트로 전환하는 것에서 얻은 더 넓은 프로덕션 교훈과 일치합니다. 오케스트레이션(orchestration) 자체에 관찰 가능하고 반복 가능한 체크가 필요합니다. 더 강력한 증거 없이 더 많은 에이전트를 투입하는 것은 더 비용이 많이 드는 불확실성을 생성할 뿐입니다.

모든 에이전트에게 모호한 역할이 아닌 계약을 부여하십시오

“백엔드를 검토하라”는 직함일 뿐, 실행 가능한 경계(executable boundary)가 아닙니다. 각 작업자에게 무엇을 소유하는지, 무엇을 변경할 수 있는지, 무엇을 보고해야 하는지, 그리고 무엇이 작업을 차단하는지를 명시하는 짧은 계약(contract)을 부여하십시오.

# .claude/agent-team.yml (planning example)
goal: "Add idempotent retry handling to the billing webhook"
shared_done:
...

핵심은 이 파일 형식이 아닙니다. 핵심은 인계(handoff) 과정을 검사 가능하게(inspectable) 만드는 것입니다. 코디네이터(coordinator)는 언제든 다음 네 가지 질문에 답할 수 있어야 합니다: 누가 결정을 소유하고 있는가, 어떤 증거가 완료를 증명하는가, 무엇이 변경되었는가, 그리고 무엇이 인간의 개입을 필요로 하는가.

공유 컨텍스트를 무한하게 만들지 말고 유용하게 만드세요

Anthropic은 에이전트가 찾을 수 있는 정보에 대해서만 추론할 수 있기 때문에, 공개적으로 작업하고 광범위한 컨텍스트를 제공할 것을 권장합니다. 하지만 "모든 것을 다 주라"는 것은 형편없는 실행 계획입니다. 이는 오래된 지침(stale instructions), 충돌하는 요구사항, 그리고 컨텍스트 비용(context cost)을 증가시킵니다.

작은 공유 패킷(shared packet)으로 시작하십시오:

1. 작업 결과물 및 비목표(non-goals).
2. 현재의 아키텍처 결정 또는 인터페이스 계약(interface contract).
3. 그린 베이스라인(green baseline)을 설정하는 명령어들.
4. 접근 금지된 파일 또는 디렉토리 목록.
5. 비밀 정보(secrets), 마이그레이션(migrations), 그리고 외부 부수 효과(external side effects)에 대한 에스컬레이션 경로(escalation path).

그런 다음, 해당 정보가 필요한 에이전트에게만 작업 특화 자료를 노출하십시오. 이는 에이전트가 MCP를 통해 원격 도구에 접근할 수 있을 때 특히 중요합니다. MCP 2026 업데이트가 프로토콜 스토리를 개선하지만, 어떤 컨텍스트나 도구 권한이 귀하의 리포지토리에 적절한지는 결정해주지 않습니다.

검증자(verifier)를 실행자(implementer)의 성공 사례 밖에 두십시오

Anthropic에 따르면, 장시간 실행되는 에이전트는 인간이 검토하기 전에 작업을 검증할 수 있는 여러 가지 방법이 필요합니다. 실제로 실행자-검증자 분리(doer-verifier separation)는 두 번째 실행자를 추가하는 것보다 더 가치 있습니다.

단순한 루프는 다음과 같습니다:

1. 실행자가 계획을 제안하고 최소한의 변경을 수행합니다.
2. 검증자가 베이스라인 테스트와 함께 하나의 실패 지향적 체크(failure-oriented check)를 실행합니다.
3. 리뷰어가 작업 계약(task contract) 및 신뢰 경계(trust boundaries)를 기준으로 차이점(diff)을 검사합니다.
4. 코디네이터가 증거를 요약하고 인간이 결정해야 할 남은 사항을 명시합니다.

코딩 작업의 경우, 검증자(verifier)는 단순히 해피 패스(happy-path) 단위 테스트 세트를 재실행하는 것에 그쳐서는 안 됩니다. 회귀 조건(regression condition)을 시도하고, 예상치 못한 범위에 대한 차이점(diff)을 검사하며, 정확한 명령어를 보고하도록 요청하십시오. 그렇게 하면 실행 간의 실패 사례를 비교할 수 있게 되며, 위에서 언급한 추적-회귀(trace-to-regression) 워크플로우를 지원할 수 있습니다.

자율성은 증거와 함께 성장해야 합니다

Anthropic은 입증된 신뢰성에 비례하여 자율성을 부여하는 팀에 대해 설명합니다. 이를 운영 규칙으로 사용하십시오:

• 읽기 전용 탐색 및 인간이 승인한 계획으로 시작합니다.
• 반복 가능한 성공적인 실행(green runs) 이후에 좁은 범위의 쓰기 권한을 허용합니다.
• 파괴적 작업, 인증 정보 사용, 배포 및 마이그레이션 작업은 명시적인 승인 절차를 거치도록 유지합니다.
• 모델, 도구 또는 리포지토리 컨벤션(repository conventions)을 변경한 후에는 작업 프롬프트와 가드레일(guardrails)을 재테스트합니다.

출력이 무해해 보일 때조차 이는 중요합니다. 코딩 에이전트가 셸(shell) 및 도구 액세스 권한을 얻게 됨에 따라, 그들의 행동은 엔드포인트 제어(endpoint controls) 관점에서 공격자의 행동처럼 보일 수 있습니다. 코딩 에이전트가 EDR 탐지를 유발하는 현상은 승인, 최소 권한(least privilege), 감사 추적(audit trails)을 사후 정리 작업이 아닌 하네스(harness)의 일부로 만들어야 한다는 점을 상기시켜 줍니다.

지금 해야 할 일

1. 현재 수동 조정이 필요한 반복적인 교차 파일(cross-file) 작업을 하나 선택합니다.
2. 결과물, 비목표(non-goals), 소유자, 증거 및 중단 조건이 포함된 한 페이지 분량의 작업 계약(task contract)을 작성합니다.
3. 대규모 팀이 아닌, 하나의 구현자(implementer)와 하나의 검증자(verifier)로 먼저 실행합니다.
4. 추적(trace)을 캡처하고 첫 번째 실제 실패 사례를 회귀 케이스(regression case)로 전환합니다.
5. 공유된 중간 컨텍스트(intermediate context)가 실제 의존성(dependency) 오류나 병합(merge) 오류를 방지할 수 있는 시점에만 팀원을 추가합니다.

적용되지 않는 경우

아주 작은 리팩토링 (refactor), 단일한 결정론적 명령 (deterministic command), 또는 희소한 환경 (scarce environment)을 중심으로 직렬화되어야 하는 작업에는 조정된 팀 (coordinated team)을 사용하지 마십시오. 또한, 이는 코드 리뷰 (code review), CI, 또는 액세스 제어 (access controls)를 대체할 수 없습니다. 에이전트 팀 (Agent teams)은 여전히 프리뷰 기술이므로, 릴리스 경로 (release path)의 일부로 만들기 전에 일회성 저장소 (disposable repository)에서 그들의 동작, 비용, 그리고 실패 복구 (failure recovery)를 검증하십시오.

Sources

• Anthropic: Building effective human-agent teams
• Claude Code documentation: Agent teams
• Anthropic: Harness design for long-running applications
• OpenAI Agents SDK: orchestration and handoffs

에이전트가 단순히 한 명의 소유자에게 구조화된 결과 (structured results)를 반환하는 대신, 진행 중인 컨텍스트 (in-progress context)를 진정으로 공유해야 한다고 느꼈던 사례는 무엇인가요?