멀티 에이전트 vs 단일 에이전트, Agent 개념 쉽게 정리
조이
조이의 연습장 (Blog)
카테고리
- 개념정리
Claude에서 말하는 에이전트(Agent)개념을 기준으로
단일 에이전트와 멀티 에이전트의 차이를 정리한 자료입니다.
1. 에이전트란 무엇인가?
•
에이전트(Agent)
◦
환경(파일, 웹, API, DB 등)을 관찰하고
◦
정보를 바탕으로 계획을 세우고
◦
도구(코드 실행, Bash, 웹 검색, 사내 API 등)를 호출해
◦
목표를 달성하기 위해 여러 번 반복해서 행동하는 시스템
•
Claude 관점의 에이전트 루프 (개념적으로)
1.
컨텍스트 수집: 파일/검색/메모리에서 필요한 정보 찾기
2.
계획 수립: 지금 무엇을 먼저/나중에 할지 결정
3.
도구 사용: 코드 실행, Bash, 외부 API, Skill 등을 호출
4.
결과 검증: 출력이 기대와 맞는지 체크, 부족하면 다시 반복
즉, 에이전트는 단순히 "한 번 답변하는 LLM"이 아니라,
도구를 쓰면서 스스로 반복적으로 일하는 실행 주체입니다.
도구를 쓰면서 스스로 반복적으로 일하는 실행 주체입니다.
1-1. 커스텀 GPT, Gem이랑 같은거 아니야?
"그럼 GPTs나 Gem에 지시 프롬프트 넣어 둔 것도 에이전트 아닌가?"라는 질문이 자연스럽게 나오기 때문에, 직관적으로만 구분해 보면 다음과 같습니다.
•
공통점
◦
둘 다 시스템/지시 프롬프트로 역할과 말투, 출력 형식을 세팅한다.
◦
겉으로 보기에는 "역할이 주어진 LLM"이라는 점에서 비슷해 보인다.
GPTs / Gem (지시 프롬프트형)
•
사람:
◦
문제를 나눈다.
◦
각 단계에서 무엇을 물어볼지 정한다.
◦
답을 보고 다음에 뭘 할지 다시 결정한다.
•
모델:
◦
한 번 요청을 받으면, 그에 대한 한 번의 답변을 만들어 낸다.
•
도구/기능:
◦
파일 업로드, 웹 브라우징, 플러그인 등이 있더라도
언제 쓸지는 보통 사람이 버튼/옵션으로 정해 준다.
언제 쓸지는 보통 사람이 버튼/옵션으로 정해 준다.
사람이 오케스트레이터(조정자)이고,
모델은 그때그때 "좋은 답변을 주는 상담자"에 가깝다.
모델은 그때그때 "좋은 답변을 주는 상담자"에 가깝다.
에이전트(Agent)
•
사람:
◦
최종 목표와 제약(예: 품질 기준, 마감 시간 등)을 정해 준다.
•
에이전트:
◦
목표를 달성하기 위해 다음에 무엇을 할지 스스로 결정한다.
◦
필요하면 코드 실행, Bash, 웹 검색, 사내 API 같은 도구를 직접 호출한다.
◦
결과가 부족하거나 잘못됐다고 판단하면, 스스로 다시 시도한다.
오케스트레이터 역할의 상당 부분을 시스템 쪽으로 옮겨 놓은 상태이며,
단순 대답 생성이 아니라 "일을 진행하는 주체"에 더 가깝다.
단순 대답 생성이 아니라 "일을 진행하는 주체"에 더 가깝다.
한 줄로 정리하면,
GPTs/Gem + 지시 프롬프트: "사람이 주도하고, 모델이 돕는 대화형 조언자"
에이전트: "도구와 루프를 가진, 스스로 일하는 작업자"
에이전트: "도구와 루프를 가진, 스스로 일하는 작업자"
조사 예시로 다시 한 번
•
지시 프롬프트 LLM (GPTs, Gem 등)
◦
사람:
▪
"A, B, C 사이트에서 이런 키워드로 찾아봐"처럼
어디서·무엇을·어떻게 조사할지 직접 설계해 준다.
어디서·무엇을·어떻게 조사할지 직접 설계해 준다.
▪
중간 결과를 보고 "그럼 이번에는 이 관점도 추가해서 다시 조사해줘"라고
다음 단계도 사람이 계속 결정한다.
다음 단계도 사람이 계속 결정한다.
◦
모델:
▪
그때그때 들어온 요청에 대해 한 번의 답변을 생성한다.
•
에이전트
◦
사람:
▪
"OO 주제에 대해 우리 의사결정에 쓸 수 있을 정도로 조사해와"처럼
목표와 품질 기준 정도만 정해 준다.
목표와 품질 기준 정도만 정해 준다.
◦
에이전트:
▪
어떤 정보가 필요한지, 어떤 순서(시장 규모 → 경쟁사 → 리스크 등)로 볼지
조사 전략을 스스로 세운다.
조사 전략을 스스로 세운다.
▪
웹 검색, 사내 문서, 내부 API 등 어디서 조사할지와 어떤 도구를 쓸지 결정한다.
▪
중간에 정보가 부족하면 다른 키워드·다른 출처로 다시 조사하자고 스스로 판단하고,
루프를 돌면서 결과를 보강한다.
루프를 돌면서 결과를 보강한다.
2. 단일 에이전트(Single Agent)
2-1. 개념
•
하나의 에이전트가 처음부터 끝까지 전체 작업을 담당하는 구조
•
모든 판단(계획, 도구 선택, 결과 검증)을 한 에이전트의 단일 컨텍스트 안에서 수행
•
Claude Messages API + Tool Use, 또는 단일 Agent SDK 인스턴스를 떠올리면 이해하기 쉽습니다.
2-2. 특징
•
하나의 두뇌 + 하나의 작업 공간
◦
대화/파일/도구 사용 이력이 모두 한 컨텍스트에 쌓임
◦
전체 흐름을 한 번에 바라보기 쉬움
•
구현이 단순
◦
오케스트레이션 레이어(조정자)가 거의 필요 없음
◦
"프롬프트 + 도구 정의"만으로도 어느 정도 복잡한 작업 수행 가능
•
직관적인 디버깅
◦
문제가 생기면 해당 에이전트의 대화/도구 호출 로그만 보면 됨
2-3. 장점
•
아키텍처가 단순해서 처음 도입·PoC에 적합
•
컨텍스트가 하나라서 전체 히스토리를 공유해야 하는 작업에 유리
◦
예: 작은 코드베이스 리팩토링, 한 명 고객의 케이스를 처음부터 끝까지 처리
•
오버헤드(에이전트 간 조율 로직, 서브에이전트 관리)가 적음
2-4. 한계
•
컨텍스트 한계
◦
한 에이전트가 기억할 수 있는 정보(토큰)가 제한적
◦
대규모 문서/코드/로그를 모두 한 번에 다루기 어려움
•
병렬화 어려움
◦
기본적으로 순차적으로 생각하고 도구를 호출
◦
여러 방향을 동시에 탐색해야 하는 작업에 비효율적
•
역할 분리가 약함
◦
계획/구현/검증을 모두 한 에이전트가 담당 → 실수 검출이 어려울 수 있음
3. 멀티 에이전트(Multi Agent)
3-1. 개념
•
여러 개의 에이전트가 서로 협력하여 하나의 큰 목표를 수행하는 구조
•
일반적인 패턴
◦
오케스트레이터(Orchestrator) 에이전트: 전체 계획/분할/통합 담당
◦
워커(Worker) 에이전트 또는 서브에이전트(Subagent): 세부 작업 담당
•
Claude의 멀티에이전트 리서치 시스템 사례에서는
◦
리드 에이전트가 연구 계획을 세우고
◦
여러 서브에이전트가 웹 검색/자료 분석을 병렬 수행 후 결과를 리드 에이전트에게 보고합니다.
3-2. 구조적 특징
•
역할 분리 (Separation of Concerns)
◦
예: "플래너", "리서처", "코더", "테스터", "리뷰어" 등 역할을 나누어 설계
•
컨텍스트 분리 (Context Isolation)
◦
각 에이전트는 자신만의 대화/작업 히스토리를 가짐
◦
필요할 때만 핵심 요약 정보를 서로 주고받음
•
병렬 처리 (Parallelization)
◦
여러 서브에이전트가 동시에 다른 하위 과제를 수행
◦
특히 리서치·대량 데이터 처리에 큰 성능 향상
3-3. 장점
•
대규모·복잡한 문제에 강함
◦
하나의 에이전트 컨텍스트에 다 담기 어려운 정보를
여러 에이전트가 나눠서 탐색 후, 요약본만 합치는 구조
여러 에이전트가 나눠서 탐색 후, 요약본만 합치는 구조
•
전문화 가능
◦
각 에이전트에 다른 시스템 프롬프트/도구/Skill을 부여하여
"보안 리뷰 전문가", "성능 튜너", "데이터 분석가" 등으로 특화 가능
"보안 리뷰 전문가", "성능 튜너", "데이터 분석가" 등으로 특화 가능
•
병렬화에 의한 속도 향상
◦
독립적인 서브 태스크가 많을수록
단일 에이전트 대비 시간 단축 효과가 큼
단일 에이전트 대비 시간 단축 효과가 큼
3-4. 단점·주의점
•
아키텍처 복잡도 증가
◦
어떤 에이전트를 언제 생성/종료할지, 어떻게 결과를 합칠지 설계 필요
•
토큰·비용 증가
◦
여러 에이전트가 각각 컨텍스트와 도구를 사용하기 때문에
단일 에이전트 대비 토큰 사용량이 크게 늘 수 있음
단일 에이전트 대비 토큰 사용량이 크게 늘 수 있음
•
조정 실패 위험
◦
중복 작업, 불필요한 검색, 잘못된 도구 선택 등
오케스트레이션이 좋지 않으면 오히려 효율이 떨어질 수 있음
오케스트레이션이 좋지 않으면 오히려 효율이 떨어질 수 있음
4. 단일 에이전트 vs 멀티 에이전트 비교
4-1. 한눈에 보는 비교 표
구분 | 단일 에이전트 | 멀티 에이전트 |
기본 구조 | 에이전트 1개가 전체 작업 수행 | 여러 에이전트가 역할 분담·협업 |
컨텍스트 | 하나의 큰 컨텍스트 | 에이전트별 분리된 컨텍스트 |
병렬 처리 | 주로 순차 처리 | 서브에이전트로 병렬 처리 가능 |
설계 난이도 | 낮음 (프롬프트+도구 정의 중심) | 높음 (역할·흐름·통합 설계 필요) |
디버깅 | 단일 로그 확인으로 비교적 단순 | 에이전트·메시지 흐름을 함께 봐야 함 |
토큰/비용 | 상대적으로 적음 | 많아질 가능성이 큼 |
적합한 문제 | 규모가 작거나 중간 정도, 흐름이 단순한 작업 | 대규모 리서치, 복잡한 제품 기능, 여러 방향 동시 탐색 |
4-2. 사고 방식의 차이
•
단일 에이전트
◦
"똑똑한 한 명에게 일을 처음부터 끝까지 맡긴다"에 가깝습니다.
•
멀티 에이전트
◦
"PM + 여러 직군(기획, 개발, QA, 데이터 분석)이 협업하는 팀"에 가깝습니다.
5. 언제 단일 에이전트, 언제 멀티 에이전트?
5-1. 단일 에이전트를 우선 고려할 상황
•
PoC, 초기 파일럿 단계
•
기능이 명확하고, 단계가 비교적 단순한 업무
•
입력 규모(문서/코드/데이터)가 컨텍스트 한도 내에 들어오는 경우
•
시스템을 심플하게 유지하고 싶을 때 (운영·모니터링 부담 최소화)
5-2. 멀티 에이전트를 고려해야 하는 상황
•
여러 방향으로 동시에 파고들어야 하는 리서치
◦
예: 시장 조사, 경쟁사 분석, 규제 분석 등
•
대규모 정보 처리
◦
수많은 문서/코드/로그를 동시에 스캔하고 요약해야 하는 경우
•
역할이 확실히 분리된 복잡한 워크플로우
◦
예: 기획 → 설계 → 구현 → 테스트 → 보안 리뷰 → 문서화 등
•
고가치(High-value) 작업
◦
토큰·비용을 더 쓰더라도 품질과 완전성이 중요할 때
5-3. 실무적인 가이드
1.
가능한 한 단일 에이전트로 시작한다.
2.
병목 지점이 보이면 그 부분을 서브에이전트/멀티 에이전트로 분리한다.
•
예: 리서치 단계만 별도의 리서치 에이전트들로 병렬화
3.
토큰/비용, 복잡도, 유지보수성을 함께 고려한다.
6. Claude 관점에서 본 멀티 에이전트 구성 요소
아래는 Claude 공식 문서와 사례에서 반복적으로 등장하는 개념을
멀티 에이전트 설계와 연결해서 정리한 것입니다.
멀티 에이전트 설계와 연결해서 정리한 것입니다.
•
에이전트(Agent)
◦
Messages API + Tool Use 또는 Agent SDK로 구현되는 실행 주체
◦
도구, 코드 실행, 파일 시스템, MCP 서버 등에 접근해 일을 수행
•
서브에이전트(Subagent)
◦
메인 에이전트로부터 특정 하위 과제를 위임받는
"작은 에이전트" 역할
"작은 에이전트" 역할
◦
독립 컨텍스트를 가지며, 병렬 작업과 컨텍스트 분리에 도움
•
Skills
◦
에이전트가 참고하는 전문화된 지식/절차 패키지
◦
"어떻게 할 것인가(How)"를 캡슐화한 문서/코드 번들
◦
여러 에이전트가 동일한 Skill을 공유하면,
역할이 달라도 공통 규칙·스타일·베스트 프랙티스를 유지 가능
역할이 달라도 공통 규칙·스타일·베스트 프랙티스를 유지 가능
멀티 에이전트 시스템을 설계할 때는
•
'에이전트/서브에이전트'로 역할과 흐름을 설계하고,
•
'Skill'로 각 역할이 따라야 할 규칙/전문지식을 재사용하는 구조를
생각하면 Claude의 공식 방향성과 잘 맞습니다.
6-1. 에이전트 vs Skill 한 줄 요약
•
에이전트: 일을 실제로 하는 "직원/팀"에 가깝다.
◦
목표를 받고, 계획을 세우고, 도구를 쓰고, 결과를 보고 다시 행동한다.
•
Skill: 일을 어떻게 할지 적어 둔 "사내 매뉴얼"에 가깝다.
◦
스스로 돌아가진 않고, 에이전트가 필요할 때 꺼내 보는 규칙/노하우 묶음이다.
그래서 구조를 아주 단순화하면,
•
에이전트 = 실행 주체(사람/팀 역할)
•
Skill = 그 실행 주체가 참고하는 매뉴얼/가이드
라고 이해하면 대부분의 차이를 자연스럽게 설명할 수 있습니다.
7. 마무리 요약 (3줄 정리)
1.
단일 에이전트는 한 에이전트가 처음부터 끝까지 모든 일을 담당하는 단순 구조로, 작은·중간 규모 문제에 적합합니다.
2.
멀티 에이전트는 여러 에이전트가 역할을 나누고 병렬로 협업하는 구조로, 대규모·복잡·고가치 작업에 강하지만 설계와 운영이 더 어렵습니다.
3.
실무에서는 단일 에이전트로 시작하고, 병목이 보이는 단계에만 멀티 에이전트/서브에이전트를 도입하는 점진적 접근이 운영 리스크와 비용 모두를 줄여줍니다.
참고 자료
•
Skills 저장소/템플릿: https://github.com/anthropics/skills
•
API에서 Skills 사용: https://platform.claude.com/docs/en/build-with-claude/skills-guide
•
고급 Tool Use/Programmatic/Tool Search: https://www.anthropic.com/engineering/advanced-tool-use
•
Agent SDK Python GitHub: https://github.com/anthropics/claude-agent-sdk-python
•
Skills vs Subagents 설명: https://claude.com/blog/skills-explained , https://code.claude.com/docs/en/skills
'zoeylog' 구독하기
사이트를 구독하면 새 포스트 등 최신 업데이트를 알림과 메일로 가장 먼저 받아보실 수 있습니다.
Slashpage에 가입하고 'zoeylog'을 구독하세요!
Slashpage에 가입하고 'zoeylog'을 구독하세요!
