여러 AI 에이전트를 동시에 실행하는 방법
Claude Code, Codex 및 다른 AI 코딩 에이전트를 동시에 실행해 개발 속도를 높이는 단계별 가이드입니다.
한 번에 하나의 AI 에이전트를 실행하는 것이 보통입니다. 하지만 두 개, 세 개, 심지어 다섯 개의 에이전트를 병렬로 돌릴 이유가 없는 것은 아닙니다. 각자 프로젝트의 다른 부분을 맡게 하면 됩니다. 어떻게 하는지, 무엇을 조심해야 하는지, 언제 의미가 있는지 살펴보겠습니다.
왜 여러 에이전트를 실행할까?
가장 단순한 이유는 시간입니다. 서로 독립적인 작업 3개가 있고, 각 작업에 에이전트가 5분씩 걸린다면 순차적으로는 15분이 걸립니다. 병렬로 돌리면 5분입니다.
하지만 시간 절약만 장점은 아닙니다.
- 전문화 - 에이전트마다 잘하는 일이 다를 수 있습니다. 복잡한 리팩터링은 Claude Code, 빠른 프로토타입은 Codex, 기계적인 작업은 셸 스크립트처럼 분담할 수 있습니다.
- 리뷰 루프 - 한 에이전트가 코드를 쓰고, 다른 에이전트가 리뷰합니다. 기다림 없이 즉시 피드백을 받을 수 있습니다.
- 문맥 분리 - 각 에이전트는 서로 얽힌 하나의 거대한 문맥이 아니라, 자신에게 필요한 작업에만 집중한 깨끗한 문맥을 받습니다.
방법 1: 여러 터미널 창
가장 단순한 접근입니다. 여러 개의 터미널을 열고 각각에서 에이전트를 시작합니다.
터미널 1:
cd ~/project
claude # 인증 리팩터링용 Claude Code 시작터미널 2:
cd ~/project
claude # API 테스트용 Claude Code 시작터미널 3:
cd ~/project
codex # 문서 작업용 Codex 시작이 방법은 동작하지만 큰 단점이 있습니다. 한 번에 한 터미널만 보거나, 화면을 작은 패널 여러 개로 쪼개야 합니다. 에이전트 1이 끝나도 그 터미널을 다시 확인하지 않으면 알 수 없습니다.
방법 2: tmux 분할 패널
tmux를 쓰면 하나의 창 안에서 여러 터미널 세션을 타일처럼 배치할 수 있습니다.
tmux new-session -s agents
# Ctrl+b % to split vertically
# Ctrl+b " to split horizontally별도 창보다 낫습니다. 여러 에이전트를 동시에 볼 수 있으니까요. 하지만 tmux 패널은 고정된 격자입니다. 에이전트가 3개 이상이면 각 패널이 읽기 어려울 정도로 작아집니다. 또 에이전트 상태(작업 중, 대기 중, 완료)를 시각적으로 알려주지도 않습니다.
방법 3: 캔버스 기반 작업공간
2개 이상의 에이전트에 가장 효과적인 방법은 시각적 캔버스 작업공간입니다. 각 에이전트를 무한 캔버스 위의 별도 타일에 배치하고, 워크플로에서의 역할에 맞춰 공간적으로 정렬하세요.
터미널 창과 tmux보다 좋은 점은 다음과 같습니다.
- 자유로운 크기 조절 - 지금 집중하는 에이전트에 더 많은 공간을 줄 수 있습니다.
- 에이전트 상태 표시 - 어떤 에이전트가 작업 중인지, 대기 중인지, 끝났는지 한눈에 보입니다.
- 라우팅 연결 - 한 에이전트의 출력을 다른 에이전트에게 자동 전달할 수 있습니다.
- 지속성 - 레이아웃이 저장됩니다. 닫았다가 다시 열어도 그대로입니다.
MadoHub은 바로 이런 작업을 위해 만들어졌습니다. 드래그와 리사이즈가 가능한 타일에서 실시간 상태 감지와 함께 터미널 기반 에이전트를 실행할 수 있는 무한 캔버스를 제공합니다.
조심해야 할 것
파일 충돌
두 에이전트가 동시에 같은 파일을 편집하면 충돌이 생깁니다. 병렬 실행 전에 서로 다른 파일이나 모듈을 맡는지 확인하세요.
좋은 병렬 분할:
- Agent A는
src/auth/를 작업하고, Agent B는src/api/를 작업
나쁜 병렬 분할:
- Agent A와 Agent B가 둘 다
src/config/database.ts를 수정
자원 사용량
AI 에이전트 세션 하나마다 RAM(터미널 + 에이전트 프로세스)과 API 크레딧이 소모됩니다. Claude Code를 5개 동시에 실행하면 API 사용량도 5배입니다. 과금형 플랜이라면 크레딧 소모를 모니터링하세요.
문맥 오염
여러 에이전트가 같은 git 저장소에서 작업하면, 한 에이전트의 커밋되지 않은 변경이 다른 에이전트의 파일 읽기를 혼란스럽게 할 수 있습니다. 해결책은 다음과 같습니다.
- Git 브랜치 - 각 에이전트가 별도 브랜치에서 작업
- 독립 디렉터리 - 작업이 정말 독립적이라면 프로젝트 복사본을 분리
- 순차 의존성 - Agent B는 Agent A가 변경을 커밋한 뒤에만 시작
언제 여러 에이전트를 써야 할까
| 상황 | 단일 에이전트 | 여러 에이전트 |
|---|---|---|
| 작은 버그 수정 하나 | 예 | 과함 |
| 대규모 리팩터링 + 테스트 | 경우에 따라 | 예 - 작성 + 테스트 분리 |
| 여러 독립 기능 | 아니오 | 예 - 기능당 에이전트 1개 |
| 구현 후 코드 리뷰 | 순차적 | 예 - 파이프라인 패턴 |
| 익숙하지 않은 코드베이스 탐색 | 예 | 과함 |
규칙은 간단합니다. 작업을 명확한 경계가 있는 독립적인 조각으로 나눌 수 있다면 여러 에이전트가 더 빠릅니다. 작업이 깊게 얽혀 있다면, 전체 문맥을 가진 단일 에이전트가 더 낫습니다.
핸드오프 자동화
여러 에이전트 작업에서 가장 큰 마찰은 정보 전달입니다. Agent A가 끝났을 때 그 결과를 Agent B에게 설명하려면 텍스트를 복사하고, 프롬프트로 다시 포맷하고, 붙여 넣어야 합니다.
자동 라우팅은 이 마찰을 없앱니다. Agent A가 끝나면 시스템이 다음을 수행합니다.
- 완료를 감지합니다(출력 패턴 또는 유휴 감지).
- 필요한 출력을 추출합니다.
- Agent B에 맞는 프롬프트로 변환합니다.
- 전달합니다.
변환 단계가 핵심입니다. 터미널 원시 출력은 ANSI 코드, 진행 바, 장황한 로그 때문에 지저분합니다. 좋은 라우팅 시스템은 의미 있는 내용을 추출해 실행 가능한 지시로 다시 프레이밍합니다.
시작하기
- 현재 프로젝트에서 서로 독립적인 작업 2개를 고르세요.
- 터미널 2개를 나란히 여세요.
- 각각에서 에이전트를 시작하세요.
- 주의가 어떻게 바뀌는지 느껴보세요. 한 작업에 깊게 몰입하는 대신 두 작업을 스캔하게 됩니다.
- 하나가 끝나면 핵심 결과를 수동으로 다른 쪽에 보내보세요.
이 과정을 직접 해보고 효과를 체감하면, 자동 라우팅과 시각적 작업공간이 왜 필요한지 이해하게 됩니다. 수동 버전을 거의 부담 없이 만들기 위해 존재하는 도구들이니까요.