가까운 미래는 단 하나의 에이전트를 선택하는 것이 아닙니다. 갈등을 일으키거나, 컨텍스트 (Context)를 중복시키거나, 추적 가능성 (Traceability)을 잃지 않으면서 여러 에이전트 사이에 작업을 나누는 방법을 아는 것입니다.

많은 팀은 이제 단일 어시스턴트만을 사용하지 않습니다. IDE의 자동 완성 (Autocomplete), 터미널 에이전트, PR을 위한 클라우드 에이전트, MCP 도구 및 자동 리뷰어를 결합합니다. 문제는 '어떤 모델이 더 나은가'에서 '누가 어떤 부분의 작업을 수행하는가'로 변하고 있습니다.

새롭게 떠오르는 패턴
조정이 없다면, 여러 에이전트는 단지 노이즈를 배가시킬 뿐입니다. 동일한 파일을 읽고, 호환되지 않는 변경 사항을 제안하며, 검토하기 어려운 디프 (Diffs)를 생성합니다. 조정이 있다면, 수동적인 대기 상태를 병렬적인 진전으로 바꿀 수 있습니다.

소유권 (Ownership)에 따른 분할
좋은 분할은 경계가 명확합니다. 한 에이전트는 편집 없이 조사합니다. 다른 에이전트는 특정 디렉토리에 테스트를 작성합니다. 또 다른 에이전트는 문서를 업데이트합니다. 다른 에이전트는 별도의 워크트리 (Worktree)에서 대안을 테스트합니다. 나쁜 분할은 두 에이전트에게 '동일한 모듈을 개선하라'고 요청하는 것입니다. 병렬 작업을 시작하기 전에 목표, 허용된 파일, 금지된 파일, 예상 출력 및 검증을 포함한 계약 (Contract)을 정의하십시오. 만약 그 계약을 작성할 수 없다면, 해당 작업은 병렬화할 준비가 되지 않은 것입니다.

Worktrees 및 브랜치 (Branches)

워크트리 (Worktrees)는 각 에이전트가 레포지토리 (Repo)의 별도 복사본에서 작업하기 때문에 충돌을 줄여줍니다. 또한 메인 브랜치를 오염시키지 않고 대안을 비교할 수 있게 해줍니다. 리팩터링 (Refactors), 민감한 버그, 또는 아키텍처 실험의 경우 워크트리는 거의 필수적입니다.

비용은 통합 (Integration)입니다. 누군가는 변경 사항이 서로 모순되지 않는지 검토하고 무엇을 남길지 결정해야 합니다. 인간 조정자는 여전히 필요합니다.

어떤 에이전트를 사용할 것인가
IDE 에이전트는 빠른 로컬 변경 사항과 즉각적인 피드백을 얻기에 대개 더 적합합니다. 터미널 에이전트는 리포지토리(repo) 작업, 테스트 및 스크립트 실행에 효과적입니다. 클라우드 에이전트는 PR(Pull Request), 이슈(issue) 및 비동기 작업에 적합합니다. 특화된 MCP(Model Context Protocol)는 모델이 임의로 추측해서는 안 되는 컨텍스트나 도구를 제공합니다. 결정은 단순히 벤치마크(benchmark)에만 기반해서는 안 됩니다. 지연 시간(latency), 권한, 추적 가능성(traceability), 비용, 환경 및 결과 검토의 용이성을 기반으로 해야 합니다.

안티패턴 (Antipatterns)

• 동일한 프롬프트(prompt)로 여러 에이전트를 실행하는 것.
• 모든 에이전트가 어떤 파일이든 편집할 수 있도록 허용하는 것.
• 종료 기준을 설정하지 않는 것.
• 탐색적 작업과 프로덕션(production) 변경 사항을 혼합하는 것.
• 단순히 컴파일이 된다는 이유만으로 첫 번째 결과를 수용하는 것.
• 어떤 에이전트가 어떤 작업을 어떤 지침(instruction)으로 수행했는지 기록하지 않는 것.

권장 워크플로 (Workflow)

첫째, 분해하십시오: 조사, 테스트, 구현, 문서화, 검증. 둘째, 소유권(ownership)을 할당하십시오. 셋째, 별도의 브랜치(branch)나 워크트리(worktree)에서 실행하십시오. 넷째, 수동으로 통합하십시오. 다섯째, 테스트와 인간의 리뷰(review)를 통한 최종 검증을 거치십시오.

확인해야 할 사항
목표는 많은 에이전트를 활성화하는 것이 아닙니다. 결과에 대한 통제력을 잃지 않으면서 유휴 시간(downtime)을 줄이는 것입니다.

결론
에이전트를 조정하는 것은 마법 같은 도구를 사용하는 것보다 주니어 팀을 이끄는 것에 더 가깝습니다. 범위를 정의하고, 산출물을 검토하며, 아키텍처(architecture)를 유지해야 합니다. 승리하는 팀은 더 많은 에이전트를 보유한 팀이 아니라, 에이전트에게 작고 검증 가능하며 유용한 경계를 가장 잘 설정해 주는 팀이 될 것입니다.

건전한 한계
조사와 제한된 범위의 작업은 병렬화하십시오. 기술적 판단이나 최종 통합은 병렬화하지 마십시오.

출처 및 참고 문헌

• OpenAI: Codex
• OpenAI: Introducing the Codex app
• Claude Code GitHub Actions
• Zed Parallel Agents

매주 화요일마다 개발자를 위한 AI 도구 읽을거리를 보내드립니다: Claude Code, Cursor, Copilot, MCP 그리고 에이전트(agents). 스페인어로, 군더더기 없이 전달합니다. 무료 구독하기.