멀티 에이전트 시스템을 설계하다 보면 결국 반복적으로 부딪히는 질문들이 있다.
특히 Context 전달, 제어 흐름, 도구 설계, 상태 관리는 시스템의 안정성과 성능을 직접적으로 좌우하는 요소다.
아래 질문들은 결국 세 가지로 귀결된다:
- Context를 어떻게 전달할 것인가
- 제어 흐름을 어떻게 구성할 것인가
- 책임을 어디에 둘 것인가
1. Context 전달 범위
Q. Handoff를 사용할 때 반드시 전체 Context를 전달해야 할까?
A. 기술적으로는 결과만 전달하는 것도 가능하다. 하지만 결과만으로 다음 작업을 이어가는 것은 맥락 부족으로 인해 오류가 발생할 가능성이 높다. 특히 복잡한 작업에서는 전체 Context를 공유하는 것이 안정적이다. 반면 단순한 작업이라면 결과만 전달하는 방식도 고려할 수 있다. 결국 이는 설계 선택의 문제다.
2. 무한 루프 방지 (Swarm)
Q. Swarm 구조에서 Supervisor가 없으면 무한 loop에 빠질 위험은 어떻게 피할 수 있을까?
A. 충분히 발생할 수 있는 문제다. Swarm 구조는 에이전트 간 자율적인 위임(handoff)이 반복되기 때문에, 종료 조건이 명확하지 않으면 무한 루프에 빠질 가능성이 있다. 이를 방지하기 위해 최대 반복 횟수(Max Turns)를 제한하거나, 일정 횟수 이상의 전환이 발생하면 Escalation 에이전트로 강제 전환하는 방식이 사용된다. 이 에이전트는 사람 개입(HITL)을 요청하거나, 현재 상황을 요약하여 작업을 종료하는 역할을 수행한다. 결국 Swarm 구조에서는 “종료 전략”을 명시적으로 설계하는 것이 필수적이다.
3. Gray Zone 처리 (Swarm)
Q. Swarm 구조에서 특정 도메인에 속하지 않는 Gray Zone 요청은 어떻게 처리할까?
A. 일반적으로 Triage 에이전트를 활용한다. 이는 명확한 작업 수행이 아니라, 요청을 분류하는 역할만 담당하는 에이전트다. 도메인이 불명확하거나 여러 영역에 걸친 요청은 우선 Triage 에이전트로 전달되어 적절한 에이전트로 라우팅된다. 이러한 방식은 Swarm 구조에서 권장되는 패턴이며, 잘못된 에이전트 선택으로 인한 불필요한 Handoff를 줄이는 데 효과적이다.
4. Handoff vs Agents-as-Tools (제어 흐름 차이)
Q. Handoff에서는 그래프 edge가 필요한데, Agents-as-Tools에서는 왜 필요하지 않을까?
A. 두 구조의 차이는 “제어권 이동 방식”에 있다. Handoff는 제어권 자체가 다른 에이전트에게 넘어가는 구조이기 때문에, 작업이 끝난 이후 어디로 이동할지를 명시적으로 정의해야 한다. 즉, 다음 실행 경로를 그래프(edge)로 표현하지 않으면 흐름이 끊긴다. 반면 Agents-as-Tools는 함수 호출(Call & Return) 구조이기 때문에, 도구 실행이 끝나면 결과가 자동으로 Supervisor에게 반환된다. 이후 흐름은 Supervisor가 다시 결정하므로 별도의 edge 정의가 필요 없다.
5. Context 포화 문제
Q. Context 포화 문제는 어떻게 해결할 수 있을까?
A. 컨텍스트 포화는 토큰 비용 증가와 성능 저하를 동시에 유발하는 주요 문제다. 이를 해결하기 위한 대표적인 전략은 두 가지다. 첫째, Context Isolation로 작업 단위별로 Context를 분리하여 사용한다. 멀티 에이전트 구조가 이에 해당한다. 둘째, Context Compression으로 불필요한 메시지를 제거하거나(summarization, trimming) 정보 밀도를 높인다. 이 외에도 retrieval 전략 최적화, tool 메시지 최소화 등 다양한 context engineering 기법을 병행해야 한다.
6. Tool 설계 (이름/인자)
Q. Tool의 이름이나 args 이름도 에이전트 성능에 영향을 미칠까?
A. 매우 큰 영향을 미친다. 에이전트는 도구의 name, description, arguments를 Context로 받아 추론을 수행한다. 특히 name과 arguments는 도구의 사용 의도를 직접적으로 드러내기 때문에 가장 중요하다. 이름이 명확할수록 LLM은 별도의 설명 없이도 올바른 도구를 선택할 수 있다. 반대로 모호하거나 부정확한 이름은 잘못된 tool 호출로 이어질 수 있다.
7. Skills vs System Prompt vs State
Q. Skills, 시스템 프롬프트, State는 각각 어떤 역할을 하는가?
A. 세 요소는 각각 에이전트의 능력, 역할, 기억을 담당한다. Skills는 특정 작업을 수행할 수 있는 도구와 실행 능력을 의미하며, 동적으로 확장 가능하다. 시스템 프롬프트는 에이전트의 역할, 행동 규칙, 페르소나를 정의하는 정적 컨텍스트다. State는 에이전트가 이전 작업을 기억하고 이어서 수행할 수 있도록 하는 동적 맥락이다. 이 세 가지가 함께 작동해야 일관된 에이전트 행동이 가능하다.
8. Orchestration vs Multi-Agent
Q. Context를 변경하는 것이 멀티 에이전트의 개념이라면, Orchestration Workflow와 멀티 에이전트의 차이는 무엇일까?
A. 두 방식의 핵심 차이는 “제어 방식”에 있다. Orchestration은 “A 다음엔 B를 수행한다”는 절차 중심의 구조로, 실행 흐름이 사전에 정의된다. 반면 멀티 에이전트는 목표를 기반으로 각 에이전트가 자율적으로 판단하고 협력하는 구조다. 즉, Orchestration이 정적인 Workflow라면, 멀티 에이전트는 동적인 협업 시스템에 가깝다. 멀티 에이전트는 단순한 순차 실행을 넘어, 상황에 따라 계획을 수정하고 역할을 재분배하는 자율성을 가진다.
9. Supervisor 모델 선택 전략
Q. Supervisor가 낮은 성능의 LLM이면 전체 시스템이 쉽게 깨지지 않을까? Supervisor에는 고성능 모델을 써야 할까?
A. 맞다. Supervisor는 전체 작업을 분배하고 의사결정을 수행하는 역할이기 때문에, 모델 성능이 시스템 전체 품질에 직접적인 영향을 준다. 따라서 가능하다면 Supervisor에는 고성능 모델을 사용하는 것이 바람직하다. 반면 Worker는 작업의 성격에 따라 상대적으로 경량 모델을 사용할 수 있다. 즉, Supervisor는 정확도를, Worker는 비용 효율을 기준으로 모델을 선택하는 것이 일반적인 설계 전략이다.
10. Supervisor 없는 구조의 출력 전략
Q. Supervisor가 없는 구조(Round Robin, Swarm)에서는 Final Result Only 방식이 불가능할까?
A. 완전히 불가능한 것은 아니지만, 일반적으로는 적절하지 않다. Supervisor가 없는 구조에서는 전체 맥락을 통합하고 전달하는 주체가 없기 때문에, 단순히 결과만 전달할 경우 다음 에이전트가 충분한 정보를 갖지 못할 가능성이 높다. 결국 각 에이전트가 이전 작업의 상태를 이해할 수 있도록 최소한의 Context 공유는 필요하다. 따라서 이러한 구조에서는 Final Result Only보다는 부분적인 Context 공유 전략이 더 안정적이다.
'블로그 > 생각거리' 카테고리의 다른 글
| 하네스 엔지니어링(Harness Engineering) (0) | 2026.03.22 |
|---|---|
| 데이터 분석가의 일 (0) | 2023.05.13 |
