Claude & Codex #1 Single-Agent에서 Multi-Agent로 가는 이유

Claude Code 하나만으로도 코드 분석부터 구현, Test, Diff 확인까지 이어갈 수 있다.

하나의 Agent로도 상당한 개발 과정을 처리할 수 있다. 그런데 작업이 커지면 요구사항 분석, Architecture 판단, 구현, 검증, Review까지 하나의 Agent와 Context에 모이게 된다.

그래서 여러 Agent를 사용하는 구조가 등장한다. 목적은 단순히 AI의 수를 늘리는 것이 아니다. 역할을 분리하고, 독립적인 작업을 병렬화하고, 한 Agent의 결과를 다른 Agent가 다시 검토할 수 있는 구조를 만드는 것이다.

다만 Multi-Agent, Context Engineering, Harness Engineering, Orchestration은 함께 언급되는 경우가 많아 처음 보면 같은 발전 단계처럼 보이기 쉽다. 먼저 각각이 무엇을 구분하는 개념인지 나눠볼 필요가 있다.

Agent 개발 구조는 세 가지 관점으로 나눌 수 있다

1. 개발 환경 설계

구분	의미
Context Engineering	Agent가 어떤 정보와 판단 기준을 보게 할지 설계
Harness Engineering	Agent가 어떤 Tool, 절차, 실행 환경, 검증 루프 안에서 일할지 설계

Context Engineering과 Harness Engineering은 Agent의 수가 아니라 Agent가 일할 환경을 어떻게 설계할 것인가에 관한 개념이다.

2. Agent 구성

구분	의미
Single-Agent	하나의 Agent가 작업
Multiple Agents	여러 Agent를 사용하지만 서로 독립적으로 동작할 수 있음
Multi-Agent System	여러 Agent가 하나의 시스템 안에서 역할과 결과를 주고받으며 협업

이쪽은 Agent를 몇 개 사용하고 서로 어떤 관계로 연결하는가를 구분한다.

3. Multi-Agent 내부 구조

구분	의미
Centralized / Orchestrated	중앙 Orchestrator가 Agent 선택, 작업 분배, 결과 통합을 담당
Decentralized / Handoff	중앙 Manager가 모든 흐름을 유지하지 않고 Agent 사이에서 작업이나 제어권을 넘김

여기서도 한쪽이 더 발전된 형태라고 볼 필요는 없다. Multi-Agent System 안에서 Coordination을 어떻게 구성할지에 따른 선택이다.

OpenAI Agents SDK에서도 중앙 Manager가 Specialist Agent를 호출하는 agents as tools와, 현재 Agent가 다른 Specialist에게 제어권을 넘기는 Handoff를 대표적인 Multi-Agent 패턴으로 제공한다.

OpenAI Agents SDK — Agent orchestration
OpenAI Agents SDK — Handoffs

Agent를 여러 개 쓰면 무엇이 달라질까

Single-Agent가 복잡한 작업을 수행하지 못해서 여러 Agent가 필요한 것은 아니다. 역할을 나눴을 때 얻는 이점이 있는 작업이 있기 때문이다.

Single-Agent에 집중되는 것	여러 Agent로 나눌 수 있는 것
하나의 Context에서 여러 역할 수행	역할에 맞는 Context와 Tool 제공
하나의 흐름에서 작업 처리	독립적인 작업의 병렬 처리
구현과 Self Review가 같은 Agent에서 이어짐	구현과 Independent Review 분리
하나의 Agent가 넓은 책임을 담당	역할별 Specialist Agent 구성

예를 들어 하나의 Agent가 세 방향을 조사한다면 기본적으로 다음과 같이 진행할 수 있다.

A 조사
  ↓
B 조사
  ↓
C 조사
  ↓
결과 정리

서로 독립적인 작업이라면 여러 Agent가 나눠서 수행할 수도 있다.

             Task
         ↙    ↓    ↘
    Agent A Agent B Agent C
         ↘    ↓    ↙
            Result

Anthropic의 Multi-Agent Research System도 Lead Agent가 작업을 나누고 여러 Subagent가 서로 다른 방향을 병렬로 조사한 뒤 결과를 통합하는 구조를 사용한다. Anthropic — How we built our multi-agent research system

하지만 Agent를 많이 붙인다고 항상 좋아지는 것은 아니다. 작업 간 의존성이 높다면 Agent 사이에서 Context와 결과를 전달하는 비용이 커지고, 하나의 Agent가 계속 처리하는 편이 단순할 수도 있다.

Agent 수보다 먼저 역할을 분리할 이유가 있는지를 판단해야 한다.

Agent가 둘이라고 바로 Multi-Agent System은 아니다

Agent 수만 보면 구조의 차이가 잘 보이지 않는다.

Single-Agent

Human
    ↓
Agent

Multiple Agents

Human
 ├── Agent A
 └── Agent B

Multi-Agent System

        Task
         ↓
    Coordination
     ↙       ↘
Agent A     Agent B
     ↘       ↙
        Result

Multiple Agents는 여러 Agent를 사용하는 상태를 넓게 표현할 수 있다. 하지만 Agent A와 B가 각각 다른 일을 하고 결과도 서로 전달하지 않는다면 하나의 협업 시스템이라고 보기는 어렵다.

Multi-Agent System에서는 여러 Agent가 하나의 목표 안에서 작업을 나누고 결과를 전달하거나 다른 Agent에게 작업을 위임한다.

즉 차이는 Agent 개수보다 Agent 사이에 Coordination이 존재하는가에 있다.
용어의 범위는 제품이나 연구에 따라 조금씩 다르게 사용된다. 여기서는 이후 구조를 구분하기 위해 여러 Agent를 독립적으로 사용하는 경우와 여러 Agent가 시스템 안에서 협업하는 경우를 나눠서 본다.

여러 Agent를 연결하는 방식도 다르다

여러 Agent가 하나의 작업에 참여하면 누가 다음 작업을 정하고 어떤 Agent에게 넘길 것인가가 필요해진다. 이것이 Orchestration의 영역이다.

Human-Orchestrated

Agent A
   ↓
 Human
   ↓
Agent B

사람이 첫 번째 Agent의 결과를 확인하고 다음 Agent에게 작업을 넘긴다. 별도의 Orchestrator 를 만들지 않아도 여러 Agent를 역할별로 사용할 수 있지만, Agent가 많아질수록 사람이 중간 결과를 연결해야 한다.

Centralized Orchestration

             Orchestrator
          ↙      ↓      ↘
     Agent A   Agent B   Agent C
          ↘      ↓      ↙
             Result

중앙 Orchestrator가 어떤 Agent를 실행할지 결정하고 결과를 다시 통합한다. OpenAI Agents SDK 의 agents as tools가 대표적인 예다. Manager Agent가 제어권을 유지하면서 필요한 Specialist Agent를 호출한다.

Handoff / Decentralized

Agent A
   ↓
 Handoff
   ↓
Agent B
   ↓
 Handoff
   ↓
Agent C

현재 Agent가 적합한 Specialist에게 제어권을 넘길 수도 있다.
OpenAI Agents SDK의 Handoff에서는 선택된 Agent가 활성 Agent가 되어 이후 작업을 이어간다.
더 넓은 분산형 Multi-Agent System에서는 중앙 Manager 없이 여러 Agent가 메시지나 상태를 주고받으며 협력하는 구조도 사용할 수 있다.

사용 형태를 단순화하면

앞의 구조를 실제 사용 형태에 따라 단순화하면 다음과 같다.

단계	구조	추가되는 것	핵심 변화
1. Single-Agent	Agent 1개	Tool, Context	한 Agent가 처음부터 끝까지 수행
2. Multiple Agents	여러 Agent	역할 분리	여러 Agent를 사용하지만 서로 독립적일 수 있음
3. Human-Orchestrated Multiple Agents	여러 Agent + Human	사람이 작업 전달·결과 통합	사람이 Orchestrator 역할 수행
4-A. Orchestrated Multi-Agent System	Orchestrator + 여러 Agent	자동 작업 분할·할당·통합	시스템이 Agent 간 Workflow를 제어
4-B. Decentralized Multi-Agent System	직접 협력하는 여러 Agent	Agent 간 작업·상태 공유	중앙 관리자 없이 Agent들이 협력

4-A와 4-B는 발전 순서가 아니라 Multi-Agent System의 서로 다른 구조다.

이 표의 Human-Orchestrated Multiple Agents는 특정 제품의 공식 명칭이라기보다, 사람이 여러 Agent 사이의 작업을 연결하는 형태를 설명하기 위해 사용하는 표현이다.

Context와 Harness는 Agent 수와 별개다

앞에서 나눈 구조를 다시 연결하면 관계는 단순하다.

Agent Architecture
→ Agent를 몇 개, 어떤 관계로 사용할 것인가

Context Engineering
→ Agent가 무엇을 알고 판단하게 할 것인가

Harness Engineering
→ Agent가 어떤 환경과 검증 루프에서 일하게 할 것인가

예를 들어 Single-Agent에서도 Context Engineering을 적용할 수 있다.

Agent
  +
AGENTS.md / CLAUDE.md
  +
Architecture Docs

Harness 역시 마찬가지다.

Issue
  ↓
Agent
  ↓
Build / Test / Lint
  ↓
실패하면 수정
  ↓
다시 검증

OpenAI가 설명하는 Harness Engineering도 Agent가 안정적으로 작업할 수 있도록 환경을 구성하고, 의도를 전달하며, 검증 가능한 Feedback Loop를 만드는 데 초점을 둔다. OpenAI — Harness engineering: leveraging Codex in an agent-first world

Claude Code와 Codex는 역할을 나눠서 사용한다

이제 Claude Code와 Codex를 함께 사용하는 경우로 돌아가보자.

두 도구 모두 코드를 분석하고 수정할 수 있는 Coding Agent다. 여기서는 성능의 우열 때문에 역할을 나누는 것이 아니라 구현과 Review의 판단을 분리하기 위해 서로 다른 단계에 배치한다.

Claude Code      →   Implementation
Codex                 →   Independent Review
GitHub Actions  →   Build / Test / Lint
Human               →   단계 전환과 최종 판단

전체 흐름은 다음과 같다.

GitHub Issue
     ↓
Claude Code
     ↓
Implementation
     ↓
Build / Test / Self Review
     ↓
Pull Request
    ↙       ↘
GitHub     Codex
Actions    Review
    ↘       ↙
 Human Approval
     ↓
   Merge

Claude Code가 Codex를 직접 호출하는 구조는 아니다. 사람이 구현 결과를 다음 Review 단계로 넘기고, Review 결과를 확인해 수정이나 Merge를 결정한다. 따라서 이 단계는 자동화된 Multi-Agent System보다 Human-Orchestrated Multiple-Agent Workflow에 가깝다.

Claude Code의 결과를 시스템이 Codex에 자동으로 전달하고, Review 결과에 따라 다시 수정 작업을 할당하는 등 Agent 간 협업을 시스템이 직접 조정하기 시작하면 그때부터는 Multi-Agent System 에 가까워진다고 할 수 있다.

Self Review와 Independent Review는 역할이 다르다

구현 Agent가 자신의 코드를 다시 보는 Self Review도 필요하다.

Implementation
     ↓
Build / Test
     ↓
Self Review
     ↓
Pull Request
     ↓
Independent Review

구분	Self Review	Independent Review
수행 주체	구현한 Agent	다른 Agent
시점	구현 과정	구현 완료 후
Context	구현 과정의 판단을 유지	완성된 변경을 다시 확인
목적	빠진 변경과 기본 오류 확인	요구사항·Architecture·Regression 재검토

두 번째 Agent를 추가하는 목적은 같은 기능을 다시 구현하는 것이 아니다.
구현한 Agent와 다른 시점에서 변경을 다시 판단할 Review 지점을 만드는 것이다.

Codex는 완성된 변경을 다시 본다

Codex에는 이미 구현된 변경을 다시 구현하게 하지 않는다.
Review 단계에서는 다음 정보가 기준이 된다.

        Issue
            +
Current Codebase
            +
Pull Request Diff
            +
    Test Result
            ↓
         Codex

Review 관점	확인할 내용
요구사항	Issue의 요구사항이 빠지지 않았는가
Architecture	기존 책임과 Dependency 방향을 깨지 않았는가
중복	기존 역할을 다시 구현하지 않았는가
Transaction	범위가 불필요하게 넓어지지 않았는가
외부 I/O	Network와 DB 작업의 경계가 적절한가
Security	Token, Credential, Secret 처리가 안전한가
Regression	기존 기능을 깨뜨릴 가능성이 있는가
Test	중요한 Case가 빠지지 않았는가

Codex가 Finding을 남겼다고 곧바로 수정할 필요도 없다.

Codex Finding
      ↓
실제 코드 확인
      ↓
실제 문제인가?
   ↙       ↘
 Yes       No
 ↓          ↓
수정       제외

AI Review 역시 최종 결정이 아니라 판단의 재료다.

GitHub Actions는 실행해서 확인할 문제를 맡는다

Codex Review가 있다고 GitHub Actions가 필요 없어지는 것은 아니다.

단계	주요 역할
GitHub Actions	Build, Test, Lint, Static Analysis처럼 반복 가능한 검증
Codex Review	Diff와 Project Context를 읽어야 판단할 수 있는 문제 검토
Human	요구사항과 프로젝트 방향을 포함한 최종 Merge 판단

Pull Request
    ↓
GitHub Actions
    ├── Build
    ├── Test
    ├── Lint
    └── Static Analysis

정해진 기준을 실행해서 확인할 문제와, 변경의 맥락을 읽어서 판단할 문제를 분리하는 것이다.

여기까지는 Claude Code는 구현, Codex는 Review​로 역할을 나눴다.
그렇다면 두 Agent를 모두 구현에 사용하면 개발 속도를 더 높일 수 있을까?

두 Agent가 같은 기능을 구현하면 문제가 달라진다

서로 다른 기능이라면 여러 Agent가 각각 작업할 수 있다. 하지만 같은 기능을 동시에 구현하는 것은 단순한 병렬 작업과 다르다.
하나의 기능도 실제로는 여러 파일을 함께 수정한다.

Controller
Service
Repository
DTO
Config
Test
Documentation

같은 파일을 수정하면 Git Conflict가 발생한다. 더 찾기 어려운 문제는 Conflict 없이 같은 책임이 중복되는 경우 다.
Claude Code가 다음 Class를 만들었다고 하자.

GoogleOAuthService

다른 Agent는 별도의 Package에 다음 Class를 만들 수 있다.

OAuthAuthenticationManager

파일은 다르기 때문에 Git Conflict가 발생하지 않고 Build와 Test도 통과할 수 있다.

GoogleOAuthService
        \
         ── OAuth 처리 책임 중복
        /
OAuthAuthenticationManager

파일은 충돌하지 않았지만 Architecture는 갈라진 상태다.
그래서 일반적인 기능 개발에서는 같은 기능을 여러 Agent가 동시에 구현하기보다 한 Agent가 구현하고 다른 Agent가 Review하는 방식이 관리하기 쉽다.

같은 문제를 두 Agent에게 맡길 때도 있다

그렇다고 같은 문제를 두 Agent에게 맡기는 방식이 항상 잘못된 것은 아니다.
Authentication Architecture나 Storage Provider 추상화처럼 한 번의 선택이 이후 구조에 계속 영향을 주는 문제 라면 서로 다른 접근을 독립적으로 비교할 가치가 있다.

이 경우 목적부터 다르다.

            Requirement
         ↙                 ↘
   Claude Code    Codex
            ↓                  ↓
    Design A       Design B
             ↘            ↙
                    비교

같은 작업 공간에서 동시에 수정하지 않도록 Branch와 Worktree도 분리한다.

worktrees/
├── architecture-claude/
└── architecture-codex/

두 결과를 Merge하는 것이 아니라 각각의 설계를 비교한다.

비교 기준	확인할 내용
책임 분리	각 Component의 역할이 명확한가
Dependency	의존 방향이 자연스러운가
확장성	기능 추가 시 변경 범위가 어떤가
Test	책임별 Test가 가능한가
복잡도	현재 요구사항보다 과도하게 추상화하지 않았는가
영향 범위	기존 코드에 미치는 변경이 얼마나 큰가

일반적인 기능 개발에서는 구현과 Review를 분리하고, Architecture처럼 비교 가치가 큰 결정에서는 서로 독립된 대안을 비교하는 식으로 Agent의 역할을 달리할 수 있다.

어떤 방식이든 프로젝트 기준은 공유해야 한다

지금까지는 여러 Agent의 역할을 어떻게 나눌 것인가를 봤다.
하지만 구현 과 Review 를 나누든, 두 Agent에게 Architecture 대안 을 따로 만들게 하든 공통된 전제가 하나 있다.
각 Agent가 같은 프로젝트 기준을 알고 있어야 한다.
Claude Code와 Codex 가 같은 Repository를 읽는다고 같은 Architecture 를 기준으로 판단하는 것은 아니다.

예를 들어 프로젝트에 다음 원칙이 있다고 하자.

Provider 인증은 Client에서 처리한다.
Backend는 Provider Token을 저장하지 않는다.
Backend는 Metadata 관리에 집중한다.

Repository에 과거 Backend 인증 코드가 남아 있다면 한 Agent는 Legacy 코드로 판단하고, 다른 Agent는 현재 유지해야 할 구조로 해석할 수도 있다.

                같은 Repository
                            ↓
 ┌─────────────┐
 ↓                                              ↓
Claude Code                         Codex
 ↓                                              ↓
판단 A                                      판단 B

그러면 Codex가 정상적인 구현을 문제라고 Review할 수도 있고, 두 Agent의 Architecture를 비교하더라도 서로 다른 전제를 기준으로 결과를 만들 수 있다. 같은 코드를 보는 것과 같은 기준으로 코드를 판단하는 것은 다르다. 여기서 Context Engineering이 필요해진다.

다음 글에서는 AGENTS.md, CLAUDE.md, Rules, Skills가 각각 어떤 정보를 담당해야 하는지, 그리고 Agent가 실제 개발에서 사용할 Context를 Markdown으로 어떻게 작성할지 정리한다.

참고 문서

• OpenAI Agents SDK — Agent orchestration
• OpenAI Agents SDK — Handoffs
• Anthropic — How we built our multi-agent research system
• OpenAI — Harness engineering: leveraging Codex in an agent-first world