Responsibility Partitioning

Context

여러 에이전트가 하나의 시스템 안에서 공동 목표를 수행해야 할 때, 각 에이전트의 역할과 경계가 명확하지 않으면 기능 중복, 책임 공백, 장애 귀인 불가 같은 문제가 발생한다. 시스템이 커질수록 '누가 무엇을 책임지는가'라는 질문에 답할 수 없게 된다.

Problem

역할 분리 없이 기능만 추가하면 에이전트 간 책임이 겹치거나, 아무도 소유하지 않는 회색 영역이 생긴다. 장애가 발생했을 때 원인을 특정 에이전트로 귀인할 수 없고, 개선 방향도 불분명해진다. 결국 시스템 전체가 설명 불가능한 블랙박스가 된다.

Forces

• 에이전트의 독립성을 높이면 협업 비용이 줄어들지만, 지나치게 세분화하면 조정 오버헤드가 증가한다.
• 책임 경계가 명확할수록 테스트와 교체가 쉽지만, 경계를 잘못 나누면 불필요한 핸드오프가 생긴다.
• 초기에 완벽한 분할을 시도하면 분석 마비에 빠지고, 분할 없이 시작하면 나중에 리팩토링 비용이 급증한다.

Solution

시스템의 최종 목표를 하위 책임으로 분해하고, 각 책임을 하나의 에이전트에 배정한다. 분할의 기준은 '이 에이전트가 무엇을 설명할 수 있는가'이다. 각 에이전트는 자신의 책임 범위 안에서 독립적으로 판단하고 실행하되, 범위를 넘는 작업은 명시적 핸드오프로 다른 에이전트에 위임한다. 분할 후에는 각 경계에 Module Contract를 부여해 계약 기반의 협업 구조를 만든다.

적용 시나리오

예시 시나리오 — 본 페이지의 수치와 기업명은 패턴 설명을 위한 가상 사례이며, 실측 데이터가 아닙니다.

고객 상담 시스템 초기 버전에서 하나의 에이전트가 문의 분류, 응답 생성, 에스컬레이션 판단, 품질 검토를 모두 수행했다. 초기에는 동작했지만 문의량이 늘자 문제가 드러났다. 응답 품질이 떨어져도 원인이 분류 오류인지 생성 품질인지 판단할 수 없었고, 에스컬레이션 기준을 바꾸면 응답 생성까지 영향을 받았다. 책임을 분리해 Intake Agent(분류), Response Agent(응답), Escalation Agent(에스컬레이션), QA Agent(검토)로 나누자 각 에이전트를 독립적으로 평가·개선할 수 있게 되었고, 장애 발생 시 원인 귀인이 즉시 가능해졌다.

이렇게 하면 무너진다

모든 기능을 하나의 에이전트에 넣고 프롬프트로만 역할을 구분하면, 역할 간 간섭이 발생한다. 분류 정확도를 높이기 위해 프롬프트를 수정하면 응답 어조가 바뀌고, 에스컬레이션 기준을 강화하면 정상 응답까지 차단된다. 결과적으로 어떤 변경도 부작용을 예측할 수 없는 상태가 된다.

Academic References

• Architecting Agentic Communities using Design Patterns — arXiv 2601.03624
• ATAM: Method for Architecture Evaluation — Carnegie Mellon SEI