에이전트를 언제 쪼개고 언제 합칠지 고민될 때 쓰는 3가지 기준
Multi-Agent(다중 에이전트) 시스템 설계할 때 “이걸 하나로 묶을까, 둘로 나눌까?” 판단 기준 정리. ALL_FOR_ONE 프로젝트에서 7개 에이전트를 나눈 근거이기도 함.
1. “하나의 도구 세트”를 기준으로 자른다
에이전트가 호출하는 tool/API가 겹치지 않으면 별도 에이전트로 분리함. ALL_FOR_ONE에서 정책 / 입지 / 인구 에이전트를 나눈 것도 결국 각자 다른 데이터소스(API)를 쓰기 때문. 도구가 겹치기 시작하면 합치는 게 낫다.
- 정책 에이전트: 국토부 API, LH 공고 API
- 입지 에이전트: Kakao Map API, 지하철 API
- 인구 에이전트: KOSIS 인구이동 API
데이터소스가 완전히 다르면 프롬프트 내 tool 설명이 분리되어 LLM이 tool selection(도구 선택) 실수할 확률도 줄어듦.
2. “독립 실행 가능 여부”로 자른다
- A 에이전트 결과 없이 B가 시작조차 못 하면 → 같은 에이전트(또는 순차 스텝)로 묶음
- 병렬로 돌릴 수 있으면 → 별도 에이전트로 분리
이게 latency(지연시간) 최적화의 핵심임. ALL_FOR_ONE에서 7개 에이전트를 병렬로 돌린 이유이기도 함. 순차로 돌리면 7배 걸리는 걸, 병렬로 묶으면 가장 느린 하나의 시간으로 끝난다.
판단 트릭: “B가 A의 출력을 입력으로 받는가?” 받는다 → 순차. 각자 따로 돌 수 있다 → 병렬 분리.
3. “프롬프트 역할 충돌”로 자른다
하나의 System Prompt(시스템 프롬프트, 에이전트의 역할/행동 지침) 안에 상충하는 지시가 들어가면 성능이 떨어진다. 예를 들어:
- “비판적으로 분석하라” vs “친절하게 보고서를 작성하라”
- “간결하게 답변” vs “모든 근거를 상세히 나열”
한 에이전트에 넣으면 둘 다 어중간해짐. 역할이 충돌하면 분리, 보완적이면 합치는 게 맞다.
실무 체크리스트
순서대로 체크:
- 도구 / 데이터소스가 다른가? → 분리
- 병렬 실행 가능한가? → 분리
- 프롬프트 페르소나가 충돌하는가? → 분리
- 위 3개 다 “아니오”면 → 하나로 합침
한마디 요약
“도구가 다르고, 병렬로 돌 수 있고, 역할이 충돌하면 분리. 아니면 합침.”
관련: ReAct vs CoT의 핵심 차이, LLM Integration(통합)과 Inference Pipeline(추론 파이프라인)