설계 중심의 Multi AI Agent Design Methodology(MADM) 제안: RACID 역할 모델 중심으로

현재 상태 분석에서는 MAS가 해결해야 할 문제의 본질과 목표를 명확히 한다. 기존 시스템의 구조와 한계를 파악하고, 자동화나 지능화가 필요한 지점을 확인한다. 사용자 인터뷰, 기존 시스템 분석, 도메인 전문가의 자문 등을 통해 현재 상태를 다각도로 진단하며, MAS 도입을 통해 기대하는 효과를 정량적, 정성적 평가 지표를 설정한다.

MAS의 효과적인 설계는 문제 도메인을 명확히 정의하는 것에서 시작한다. 본 연구에서는 문제 명확성(Problem Clarity)과 방법 명확성(Method Clarity)을 축으로 하는 이차원 분류 매트릭스를 제안한다. 문제 명확성은 목표와 현재 상태 간 격차의 명확성을 의미하고, 방법 명확성은 문제 해결을 위한 절차적 지식의 구체화 정도를 의미한다[14]. 본 연구에서는 두 축을 기준으로 에이전트를 네 가지 유형으로 분류한다. 먼저 실행형 에이전트는 문제와 해결 방법이 모두 명확한 상황에서 반복적이거나 규칙 기반의 작업을 수행하는 데 적합하다. 반면 탐색형 에이전트는 문제는 명확하지만, 해결 방법이 불분명한 경우, 시행착오를 통해 최적의 접근법을 찾아간다. 정의형 에이전트는 문제가 모호하지만, 해결 방법이 분명한 경우에, 문제를 재정의하고 구체화하는 역할을 수행한다. 마지막으로 상호 작용형 에이전트는 문제와 방법 모두 불확실한 상황에서 여러 에이전트가 협력하여 해결 방향을 모색하는 유형이다.

핵심 기능의 중요도와 기술적 실현 가능성을 종합적으로 평가한다. 2 x 2 매트릭스를 통해 기능 영역을 분류하고 우선순위를 결정하며, 높은 우선순위 기능은 초기 단계에서 구현하고 부가 기능은 점진적 개발 전략을 수립한다.

Table 1.

Importance and feasibility matrix

MAS는 다중 에이전트 간의 상호작용과 역할 분담까지 함께 고려해야 한다. 이해관계자를 전문가, 일반 사용자, 관리자로 분류하고 직접 사용자와 간접 영향자로 매핑하여 시스템에 요구되는 기능적‧비기능적 요구사항을 도출한다.

요구사항은 두 가지 관점에서 도출한다. 비효율이나 오류 발생 지점을 식별하는 문제 중심 접근법, 실제 사용자의 관점에서 시스템의 흐름과 요구하는 기대를 파악하는 사용자 중심 접근법이다. 이를 바탕으로 사용자 시나리오를 구성하고, AI 에이전트가 기억해야 할 정보의 종류와 지속성을 가져야 하는 요구를 명시한 메모리 요구사항을 정의하여 설계 단계의 기반을 마련한다.

사용자 시나리오와 요구사항을 기반으로 전체 프로세스를 작업 단위로 세분화한다. 각 작업은 IPO(Input-Process-Output)의 관점에서 정의하고 논리적 순서를 명확히 한다. 세분화된 기능은 단일 책임 원칙에 따라 그룹화되며, 에이전트는 역할과 책임 범위에 따라 계층 구조로 설계된다. 역할 구분을 명확히 하기 위해, 상위 수준의 주요 기능 영역을 최상위 레벨로 두고 점차 하위 기능군과 세부 기능으로 분해한다. 본 연구는 이를 네 단계의 개념적 레벨로 제시한다. 레벨 0(조정형, Orchestrator)은 시스템 전체의 목표를 설정하고 대규모 워크플로를 조정하는 최상위 에이전트이다. 레벨 1(관리형, Coordinator)은 특정 도메인이나 기능 영역을 관리하는 중간 레벨의 에이전트이다. 레벨 2(처리형, Executor)는 도메인별 전문 지식을 바탕으로 구체적인 작업을 실행하는 에이전트이다. 레벨 3(행동형, Operator)은 세부적인 도구 사용이나 단순 반복 작업을 수행하는 최하위 레벨의 에이전트이다. 이 구조는 시스템의 복잡성과 규모에 따라 레벨을 유연하게 확장하거나 축소할 수 있다.

본 연구에서는 MAS를 하나의 조직(Organization)으로, 각 AI 에이전트를 개별 구성원(Team member)으로 간주한다. 이에 따라 전통적인 RACI 매트릭스를 MAS의 특성에 맞게 확장한 RACID 모델을 제안한다. 이 모델은 에이전트의 자율성과 동적 역할 변동성을 반영하여, 시스템 내 모든 에이전트의 책임과 권한을 명확히 규정한다[10].

Table 2.

RACID role definition

역할 수행 여부는 다음과 같이 표기한다: ● (기본 역할), ○(상황별 적응 가능), △(조건부), -(역할 없음).

RACID 매트릭스는 작성 시 다음 사항을 검증해야 한다. 먼저, 각 주요 작업에 대해 반드시 하나의 A 역할만 지정되어야 한다. 또, 모든 작업에 하나 이상의 R 역할이 배정되어야 한다. 세 번째, D 역할은 일반적으로 레벨 0, 레벨 1에 부여한다. 이렇게 완성된 RACID 매트릭스는 다음 단계인 에이전트 상세 명세와 관계 모델 설계의 기반 자료로 활용된다.

Table 3.

RACID Matrix

본 연구는 각 AI 에이전트의 행동 원칙(Persona)과 기술적 능력(Capability)을 중심으로 설계된다. 페르소나는 에이전트의 전문 영역, 의사결정 방식, 대화 스타일 등을 포함한 행동 지침으로, LLM 기반 에이전트의 응답 일관성과 신뢰성에 직접적인 영향을 미친다[15]. 본 연구는 다중 페르소나(Multi-Persona) 접근을 적용해, 각 에이전트가 맡은 역할에 따라 고유한 판단 기준과 성격적 특성을 갖도록 설계했다. 페르소나는 RACID 역할과 긴밀히 연계되며, 사용자 경험의 일관성을 유지하도록 조정된다.

능력 명세(Capability Specification)는 에이전트가 역할을 수행하는 데 필요한 기능을 정의하는 과정이다. 핵심 기능은 RACID 역할과 직접 연결되고, 보조 기능은 이를 지원한다. 각 기능은 IPO 흐름을 따르며, JSON 스키마로 명세 되어 구현 시 참조 기준으로 활용된다.

메모리는 'Lost in Conversation' 문제를 극복하기 위한 핵심 단계이다. 메모리 설계는 구조 정의, 활용 전략, 접근 권한 설정의 세 측면으로 이루어진다. 먼저, 메모리는 정보 지속성에 따라 단기(STM)와 장기(LTM)로 구분되며, 각각 저장할 데이터의 종류를 명확히 지정해야 한다[12]. 다음으로, 메모리 활용 전략은 시스템의 특성에 따라 선제적, 선택적, 또는 도구 기반 방식 중 적합한 접근을 선택한다[13]. 마지막으로, 메모리 접근 권한은 데이터의 민감도와 보안 요구 수준을 고려하여 에이전트별 접근 범위를 설정한다. 메모리 아키텍처 단계의 주요 산출물은 메모리 스키마 명세서, 활용 전략 정의서, 그리고 에이전트별 접근 매트릭스로, 이는 구현 단계에서 저장소 선정과 코드 구현의 기준 자료로 활용된다.

관계 모델은 AI 에이전트 간 상호작용 방식을 정의한다. 즉, 에이전트들이 어떤 방식으로 협력하고 정보를 교환하며, 의사결정과 조율을 수행하는지를 규정한다[9]. 에이전트 관계는 계층 레벨에 따라 크게 두 가지로 구분된다. 수직적 관계는 서로 다른 계층 레벨 사이에 존재하게 되고, 통제와 위임에 기반한 계층형 관계이다. 수평적 관계는 동일한 계층 레벨의 에이전트들 간에 발생한다. 이 관계에서는 협력형, 경쟁형, 혼합형의 관계가 모두 가능하다. 관계 모델링 결과물은 에이전트 간 상호작용 다이어그램 형태로 표현되며, 전체 시스템 내의 통신 흐름을 시각적으로 명확히 보여준다.

에이전트 설계 단계를 마치면 시스템 아키텍처 다이어그램을 작성한다. 다이어그램은 개발자와 이해관계자 간 의사소통을 원활하게 하고 시스템 구조를 직관적으로 이해할 수 있게 한다. 다이어그램의 포함 요소는 에이전트 목록 및 계층 레벨, 에이전트 간 역할 조정, 정보 흐름의 방향이다. 본 설계 단계에서 생성되는 핵심 산출물은 기능 명세서, RACID 매트릭스, 페르소나 및 능력 명세서, 메모리 스키마 명세서, MAS 설계 다이어그램이다. 이렇게 생성된 산출물은 구현 단계의 기준 문서로 활용되며, MAS의 일관성, 재현 가능성, 품질 확보를 위한 핵심 자료가 된다.

MAS 구현의 첫 단계는 설계 요구사항에 부합하는 에이전트 프레임워크를 선택하는 일이다. 프레임워크는 에이전트의 생성, 실행, 통신을 지원하는 기반 구조로, 전체 시스템의 확장성과 안정성을 좌우한다. 대표적인 에이전트 프레임워크로는 LangChain, AutoGen, CrewAI, LangGraph 등이 있으며, 프레임워크 선정 시에는 다음의 기준을 종합적으로 고려한다.

① 시스템의 목표와 정합성을 평가: 빠른 프로토타이핑과 검증이 목표인지, 엔터프라이즈급의 안정성과 확장성이 중요한지에 따라 적합한 프레임워크가 달라진다[3].

② 기술 생태계 및 인력 확보 용이성을 검토: 기존 인프라(클라우드, 데이터베이스, 인증 시스템)와의 호환성, 개발 인력 확보 용이성, 커뮤니티 활성화 수준을 함께 검토해야 한다.

③ 라이선스 조건 및 비용 검토: 오픈소스 유무, 상업적 이용 제약의 유무, API 제한이 있는지 등을 확인해야 한다.

④ 유지 보수 및 발전 가능성을 평가

이 단계에서는 설계 명세서를 바탕으로 선택된 프레임워크 내에서 LLM, Memory, Tool, Autonomy의 네 가지 핵심 구성요소를 바탕으로 구현한다.

① LLM: 에이전트의 핵심은 언어 모델 선택이다. LLM 모델은 추론력, 속도, 비용, 안정성 등에서 큰 차이를 보이므로, 작업 목적과 성격에 맞는 모델을 선택해야 한다. 고난도 의사결정이나 다단계 추론이 필요한 경우에는 GPT-4나 Claude Opus 등과 같은 고성능 모델이 적합하고, 실시간성과 비용 효율 위주의 환경에서는 Gemini Flash, Claude Haiku, GPT-3.5 등의 경량 모델이 적합하다. 또한, 작업 유형에 따라 CoT(Chain-of-Thought), ToT(Tree-of-Thought), ReAct 등의 추론 프레임워크를 적용해 효율을 높일 수 있다.

② Memory: 메모리 스키마 명세서와 활용 전략 정의서, 접근 매트릭스를 기반으로 구현한다. VectorDB, RAG, MemoryBank 등 적합한 메모리 프레임워크를 선정하고, STM과 LTM 요구사항에 맞춰 데이터 구조를 실제 저장소에 구현한다. 또한 선택된 활용 전략을 코드로 구현하며, 각 에이전트별 접근 권한을 설정한다.

③ Tool: 도구는 LLM이 수행할 수 있는 범위를 "생성"에서 "실행과 상호작용"으로 확장시키는 핵심 구성요소이다.기능적 목적에 따라 Extensions, Functions, Data Stores의 세 가지 유형으로 나뉜다. 각각은 외부 API 호출, 실시간 데이터 접근, 내부 DB 통합 등 다양한 역할을 수행한다. Tool을 선택할 때는 보안 수준, 응답 속도, 외부 시스템 연동성을 종합적으로 고려해야 한다[16].

④ Autonomy: 자율성 구현은 RACID 매트릭스에 정의된 자율성 단계(1~5)에 따라 달라진다. 낮은 자율성 단계(1~2)에서는 사용자 명령에 따라 단일 작업을 수행하는 간단한 루프를 구성하며, 중간 단계(3~4)에서는 중간 수준의 계획 수립과 사용자 확인을 포함한 의사결정이 가능하도록 구성한다. 높은 자율성 단계(4~5)에서는 Self-Refine, Reflection 등으로 출력의 품질을 반복적으로 개선하거나 실패 경험에서 학습할 수 있도록 구현한다[8].

MAS의 핵심은 에이전트 간 협력과 정보 교환의 효율성이다. 이를 위해 적절한 통신 프로토콜과 오케스트레이션 구조가 필요하다. 관계 모델 정의서와 시스템 아키텍처 다이어그램은 이 단계의 기본 참조 자료로 활용된다.

① 통신 프로토콜 선정: MAS에서는 에이전트가 외부 시스템 및 다른 에이전트와 상호작용을 하기 위한 표준화된 프로토콜이 필요하다. Context-Oriented Protocols(MCP 등)는 에이전트와 외부 시스템 간 연동에 사용되며, Inter-Agent Protocols(A2A, ACP, ANP 등)은 에이전트 간 통신에 사용된다[17]. 프로토콜 선정 시 에이전트의 자율성 수준, 통신 유연성, 인터페이스 표준화 정도, 보안을 종합적으로 고려해야 한다[3].

② 통신 구조 구현: 설계 단계에서 정의된 관계 유형에 따라 통신 구조를 구현한다. 수직적 관계(계층형)에서는 Lv0→ Lv1 → Lv2 → Lv3 순으로 작업을 분배한다. 수평적 관계의 협력형의 경우 작업 결과를 공유하고 통합하는 파이프라인을, 경쟁형의 경우 독립적 솔루션 제시 및 최적 결과 선택 메커니즘을, 혼합형의 경우 상황에 따른 동적 전환 로직을 구현한다. RACID 매트릭스에 정의된 역할에 따라 실행-검증-자문-모니터링-조율의 흐름을 코드 수준에서 구체화한다.

③ 오케스트레이션 방식 구현: 설계 단계에서 결정된 계획 수립 방식(CPDE 또는 DPDE)에 따라 구현한다[9].

구현이 완료된 에이전트는 단위 테스트(Unit Test)와 통합 테스트를 거쳐 기능 및 상호작용 정확성을 검증한 뒤, 실제 운영 환경에 배포된다.

본 실험은 MADM 방법론의 일반적 성능 우수성을 입증하기보다는, 복합 제약 조건 문제 영역에서 체계적 설계 접근이 결과물에 미치는 영향을 탐색적으로 확인하기 위한 개념증명(PoC)을 목적으로 한다. 이상적으로는 설계 단계 자체의 결함을 직접 측정하고 정량화하는 것이 바람직하나, 현재 MAS 분야에서는 설계 결함에 대한 정량적 정의와 측정 기준이 충분히 합의되지 않은 상황이다. 이에 본 연구는 설계 프로세스 자체를 직접 계량화하는 대신, 최종 출력물의 품질 지표를 통해 설계 방법론의 효과를 간접적으로 평가하는 접근을 채택하였다. 이러한 결과물 중심 평가는 설계 단계의 체계성이 실제 시스템 산출물에 어떻게 반영되는지를 관찰할 수 있는 현 시점에서 타당한 초기 검증 방법으로 판단하였다.

① 비교 그룹 설정: MADM을 통한 체계화된 설계 접근과 구현 중심 설계 접근 간의 차이를 정량적으로 비교하기 위해 두 개의 그룹을 구성하였다. Group A(대조군)은 명확한 설계 방법론 없이 직관과 경험에 기반해 개발하였으며, 현재 산업 현장의 일반적 개발 관행을 대표한다. Group B(실험군)는 MADM 방법론에 기반해 개발되었으며, RACID 모델, 우선순위 계층 모델을 적용하였다.

② 비교 그룹의 대표성과 통제: 본 실험의 Group A(대조군)는 AutoGen, CrewAI 등 기존 구현 중심 MAS 프레임워크 문서에서 제시하는 기본 패턴을 적용한 설계 수준을 반영한다. 즉, 기능별 에이전트 분리, 단순한 제약 처리 우선순위 규칙, 기본적인 메모리 구조화 및 자율성 설정은 포함하되, RACID 매트릭스와 같은 역할·책임 명세, 계층적 조정 구조, 설계 산출물 문서화는 적용하지 않았다. 반면, Group B는 이러한 기본 설정에 더해, MADM 방법론에 따라 설계 산출물을 사전에 정의하고 이를 구현 단계에서 반영하였다. 이에 따라 두 그룹 간 비교는 산출물 기반의 설계 방법론 적용 여부에 따른 차이를 관찰하도록 구성하였다.

③ 시스템 및 환경 통제: 두 그룹 모두 복합 제약 조건을 가진 '영양, 선호도, 예산을 동시에 만족하는 식사 메뉴 선정 시스템'을 실험 도메인으로 선정했다. 또한, 에이전트 구성(10개), LLM 모델(Gemini 2.0 Flash), 프레임워크(Google ADK), 도구(RAG, Function Calling)를 동일하게 설정하여 관측된 차이가 설계 체계화 수준 이외의 요인에서 발생하지 않도록 통제하였다.

Table 4.

AI agent list

④ 입력 시나리오 구성: 실제 사용자의 다양한 표현 방식을 반영하기 위해 복합 제약 조건을 포함하는 10개의 테스트 시나리오를 설계하였다. LLM 사용 경험이 있는 20대 성인 5명이 각 시나리오에 대해 서로 다른 표현의 프롬프트를 작성하였다. 1인당 10개의 프롬프트를 생성하여 총 50개의 프롬프트를 확보하였고, 이를 두 그룹에 각각 동일하게 입력하여 총 100회의 실험을 수행하였다

Table 5.

Experimental scenarios and constraint settings

⑤ 테스트 시나리오: 각 시나리오는 서로 다른 제약 조건 충돌 패턴과 실패 위험도를 포함한다.

각 그룹당 50회의 응답을 평가하였다. 평가는 실험을 진행한 5명이 진행하였다. 각 응답은 제약 조건 준수, 영양 목표 달성, 예산 준수, 실행 가능성의 4개 차원에서 각 25점씩 배점되며, 총 100점 만점으로 환산된다. 생명이나 건강에 직접적 위험을 초래하는 경우는 Critical Failure(0점), 핵심 제약 조건을 충족하지 못한 경우는 Major Failure(1~41점), 실행 가능성이나 응답의 완결성이 부족한 경우는 Minor Failure(42~70점), 비교적 준수한 응답인 경우에는 Success(71점 이상)으로 정의하였다. 부가적으로는 응답 시간을 비교한다.

본 실험은 결과물의 절대적 성능 우위를 판단하기 위한 것이 아니라, 설계방법론(MADM)에 기반한 설계 체계화(RACID 기반 역할·책임 명세, 우선순위 계층화, 계층적 중재 구조)가 출력 안정성과 실패 유형 분포의 변화를 유도하는 경향을 관찰하는 데 목적이 있다.

Table 6.

Failure classification criteria

"영양, 선호도, 예산을 동시에 만족하는 식사 메뉴 추천" 문제를 탐색형 문제(Exploratory type)로 분류하고, 요구사항을 도출하여 문서화하였다.

10개의 에이전트를 4단계 계층 구조로 배치하고 단일 책임 원칙에 따라 역할을 분리하였다. A001(System Orchestrator)은 Accountable로서 최종 의사결정 권한, A101(Menu Planner)은 Dynamic Coordinator로써 제약 충돌 시 중재를 담당한다. A201/A202는 각각 건강 분석과 예산 분석에 대한 Responsible 역할을 수행한다. 제약 조건 충돌 시 우선순위는 “생명 안전 → 의학적 제약 → 영양 목표 → 예산 → 선호도”로 계층화하였다. 메모리 활용 전략은 기본적으로 선제적 활용 전략을 선택하였다. 아키텍처는 STM과 LTM으로 구분하였으며, 에이전트 역할에 따라 접근 권한을 차등 설정하였다. A001만 전체 메모리에 대한 관리자 권한을 가지며, 나머지 에이전트는 담당 영역에 대해서만 읽기 또는 쓰기 권한을 부여받는다.

Table 7.

Group B: RACID matrix

Table 8.

Group B: Memory architecture

설계한 최종 MAS의 다이어그램은 다음과 같다.

Fig. 5.

Group A: MAS relationship model

실험 설계에서 정의한 대로 물리적, 기술적 조건을 동일하게 적용하였다. 에이전트 자율성은 계층별 의사결정 루프 구조로 구현하였다. A001(L4)은 하위 에이전트의 결과를 평가하고 필요 시 재작업을 지시하며, 제약 조건 충돌 발생 시 자율적으로 중재안을 도출한다. A101, A201, A202(L3)는 각자의 영역에서 독립적으로 분석과 문제 해결을 수행하되, 처리 범위를 초과하는 경우 상위 레벨 에이전트(A001)에게 판단을 위임하는 에스컬레이션 구조를 통해 의사결정의 일관성을 유지하도록 설계하였다. 반면, A301~A303/A311~A313의 에이전트(L2) 단순 실행 루프 기반으로 구현되어 템플릿 기반 레시피 검색과 제한된 범위 내 조정만 수행하도록 제한하였다. 외부 통신을 위해 MCP를 적용하였으며, 시스템 오케스트레이션 방식으로는 CPDE를 채택하였다[8].

50개의 프롬프트를 각 그룹에 입력한 결과, MADM 방법론을 적용한 Group B는 Group A(Baseline) 대비 평균 점수와 Success 비율에서 상대적으로 높은 값을 보였다.

Table 9.

Overall performance comparison by group

Group B의 평균 점수는 Group A보다 10.24점 높게 나타났으며, 평가 기준을 충족하는 출력(Success)의 발생 빈도 역시 더 자주 관찰되었다. 또한 Major Failure 비율은 6.0%p 감소하여, 일부 시나리오에서 핵심 제약 조건 위반이 상대적으로 적게 발생했음을 확인하였다.

4개 평가 차원(제약 준수, 영양 목표, 예산 준수, 실행 가능성)을 기준으로 분석한 결과, Group B는 제약 준수, 영양 목표, 예산 준수 차원에서 점수 증가가 관찰되었으며, 실행 가능성 차원에서는 소폭 감소가 나타났다.

점수 차이는 특히 예산 준수와 영양 목표 달성 차원에서 크게 나타났는데, 이는 Group B가 제약 조건과 목표를 구조적으로 처리하도록 설계되었기 때문으로 해석할 수 있다. 반면 실행 가능성 점수의 감소는 Group B가 상위 제약 충족에 상대적으로 더 집중하면서, 출력의 구체성이나 단계적 설명이 일부 희석된 결과로 볼 수 있다. 이러한 결과는 MADM이 제약 중심 문제 해결에 강점을 보이지만, 실행 관점에서는 추가적인 보완 여지가 있음을 시사한다.

Table 10.

Detailed scores by evaluation dimension

10개의 테스트 시나리오 중 복합 제약 조건이 명확한 시나리오에서 Group B의 점수 차이가 비교적 크게 나타났으며, 일부 시나리오에서는 Group A가 더 높은 점수를 기록하였다.

특히 S3(다중 알레르기), S6(당뇨+고혈압+약물), S10(와파린 복용)과 같이 안전 및 의학적 제약이 중첩되는 시나리오에서는 Group B의 점수가 더 높게 관찰되었다. 이는 MADM의 우선순위 계층화와 역할 분리가 복합 제약 상황에서 일정 수준의 안정성을 제공했을 가능성을 보여준다. 반면 S7(편식 아동), S8(대가족), S9(마라톤 D-3)와 같이 특수 요구사항 또는 선호 중심 문제에서는 Group B의 점수가 낮게 나타났다. 이는 현재 MADM의 우선순위 체계가 안전 및 제약 중심으로 설계되어 있어, 특수 영양 비율이나 선호 조정이 핵심이 되는 시나리오에서는 충분히 대응하지 못했음을 시사한다. 본 결과는 MADM의 적용 범위와 한계를 함께 보여주는 사례적 결과로 해석하는 것이 적절하다.

Table 11.

Performance and improvement rate by scenario

MADM의 구조적 설계는 응답 시간 증가로 이어지는 경향을 보였다. Group B는 Group A 대비 평균 응답 시간이 3.42초(13.9%) 더 길게 나타났다. 다만 두 그룹 모두 제약 조건에 대한 우선순위 규칙을 적용하고 있다는 점에서, 이러한 차이는 우선순위 제약의 존재 자체보다는 제약을 처리하는 방식의 차이에서 기인한 것으로 해석된다.

Group A에서는 우선순위 규칙이 단일 단계의 판단 로직으로 적용된 반면, Group B에서는 RACID 기반 역할 분리와 계층적 중재 구조를 통해 제약 충돌이 단계적으로 처리되었다. 이 과정에서 분석, 중재, 통합 단계가 명시적으로 분리되어 수행되었으며, 특히 복합 제약이 포함된 시나리오(S6, S10)에서는 해당 절차가 반복적으로 수행되었다. 이러한 결과는 MADM이 설계 품질과 안전성을 중시하는 과정에서 추가적인 처리 비용이 발생할 수 있음을 시사한다.

Table 12.

Response time comparison

본 실험에서 MADM을 적용한 Group B는 Group A 대비 평균 점수(+10.24점, +18.2%)와 Success 비율(+38.0%p)이 높은 경향을 보였고, Major Failure 비율은 6.0%p 감소하였다. 특히 안전 및 의학 제약이 중첩되는 시나리오(S3, S6, S10)에서 Group B의 점수 개선폭이 상대적으로 크게 관찰되어, RACID 기반 역할 분리와 우선순위 계층화가 제약 충돌 처리에 구조적 이점을 제공할 가능성을 시사한다. 반면 선호/비율 조정이 핵심인 시나리오(S7, S8, S9)에서는 성능 저하가 관찰되었고, 응답 시간도 13.9% 증가하여 역할 분리와 계층적 중재 구조가 추가적인 처리 비용을 수반할 가능성을 확인하였다.

본 연구는 다음과 같은 한계를 가진다. 첫째, 설계 프로세스 자체를 직접 측정하지 못했다. 본 연구는 설계 결함 감소를 문제의식으로 삼았으나, MAS 설계 결함에 대한 정량적 정의와 측정 기준이 아직 충분히 합의되지 않은 상황에서 설계 오류 발생 빈도, 역할 충돌 횟수, 재설계 횟수, 요구사항 변경 빈도, 설계 소요 시간 등 설계 단계의 정량 지표를 수집이 어렵다. 이에 따라 관찰된 출력 품질 향상이 설계 품질 개선의 직접적 결과인지, 혹은 프롬프트 품질이나 모델 변동과 같은 다른 요인의 영향인지 명확히 분리하여 설명하기 어렵다. 둘째, 우선순위 체계의 도메인 적응 방법을 제시하지 못했다. 안전 중심 우선순위가 특정 시나리오에서 성능 저하로 이어질 수 있음을 관찰했으나, 도메인별로 우선순위를 조정의 원칙이나 기준을 본 연구에서 제시하지 못했다. 셋째, 일반화 가능성이 제한적이다. 단일 도메인(식사 메뉴 추천), 중소규모 에이전트(10개 에이전트), 50개 테스트 케이스에 한정되어 다양한 환경에서의 재현성은 추가 검증이 필요하다.