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