CEPO는 멀티에이전트 프롬프트에서 조율과 실행을 분리해 최적화한다

무엇인가

멀티에이전트 시스템(MAS)은 각 에이전트가 맡은 과업을 잘 수행하는 동시에 전체 목표를 향해 협력해야 한다. 논문이 지적하는 문제는 기존 프롬프트 최적화가 이 두 기능, 즉 시스템 수준의 조율과 에이전트 수준의 실행을 에이전트별 프롬프트 하나에 함께 담아 최적화해 왔다는 점이다. 그 결과 협력 규칙 하나를 고치려면 실행 책임이 서로 다른 여러 프롬프트를 일관되게 바꿔야 한다. 에이전트 간 상호작용이나 조율 실패까지 반영하는 MASPO 같은 방법도 업데이트 대상은 여전히 에이전트별 프롬프트에 머문다.

어떻게 동작하나

CEPO의 첫 번째 원칙은 코디네이터-실행자 프롬프트 분해다. 모든 에이전트가 공유하는 코디네이터 프롬프트 p_C가 에이전트 간 협력 방식(발견 공유, 이견 표시, 후속 단계 지원 등)을 정의하고, 각 에이전트는 자기 고유의 실행자 프롬프트 p_E^(i)를 따로 갖는다. 에이전트 A_i가 호출될 때 실제로 쓰이는 프롬프트는 p_C를 p_E^(i) 앞에 붙인 p_C ⊕ p_E^(i)다. 따라서 p_C를 한 번 갱신하면 모든 에이전트에 동일한 조율 변경이 적용되고, p_E^(i) 갱신은 해당 에이전트의 국소 지시만 바꾼다.

무엇과 다른가

두 번째 원칙은 역할 정렬 최적화다. 하위 최적화기에 서로 다른 메타 지시를 넘긴다. 코디네이터 갱신에는 Φ_C를 주어 에이전트 간 통신, 상충 증거 처리, 공유 추론 규범 같은 시스템 수준 협력을 다듬게 하고, 실행자 갱신에는 Φ_E를 주어 과업 범위 설정, 근거 활용, 구체적 절차를 다듬게 한다. 두 프롬프트 계층 모두 시스템 수준 목적 J로 선택되지만, 탐색을 이끄는 지침은 역할에 따라 분리된다.

어떻게 쓰나

절차는 2단계다. 1단계에서는 초기 실행자 프롬프트를 고정한 채 코디네이터를 Φ_C로 T_C회 갱신하고, 전체 MAS를 학습 데이터에 돌려 얻은 실패 피드백으로 후보를 만들며 검증 점수로 최종 코디네이터를 고른다. 2단계에서는 선택된 코디네이터를 고정하고 사용자가 지정한 실행자 부분집합에 대해 Φ_E로 T_E회 갱신한다. 부분집합이 공집합이면 코디네이터만 최적화하는 셈이다. 중요한 점은 CEPO가 프롬프트 구조와 최적화 지침만 규정하고, 후보 생성과 탐색은 기존 최적화기(PE2, OPRO, ProTeGi, MASPO)가 그대로 수행한다는 것이다.

전제와 한계

실험은 문서 이해, 수학 추론, 코드 생성, 비디오 이해 4개 도메인의 11개 벤치마크에서 이뤄졌다. 문서 이해에서는 PE2+CEPO를 MDocAgent(Qwen-3.5 4B)와 DocAgent(GPT-5-mini)에 적용해 각각 평균 4.3점, 2.7점을 올렸고, DocAgent의 MMLongBench-Doc에서 59.5에서 67.4로 7.9점 오르는 최대 개선을 냈다. MASPO 기반 수학·코드 실험에서는 baseline과 MASPO 단독을 모두 앞서며 평균 5.07점 향상을 기록했고, LongVideoAgent의 LongTVQA+에서는 64.9로 vanilla PE2 대비 1.5점, baseline 대비 4.6점 올랐다. PE2, ProTeGi, OPRO를 문서 5개 벤치마크에 적용한 비교에서도 CEPO는 모든 조합에서 0.6~6.5점의 개선을 보였다.

분석 결과도 설계를 뒷받침한다. MMLongBench-Doc에서 최적화 없는 LLM 생성 코디네이터만 붙이면 54.1에서 55.6, 실행자만 최적화하면 57.9, 코디네이터만 최적화하면 58.6이었지만 둘 다 역할 정렬 지침으로 최적화한 PE2+CEPO는 61.0이었다. 지침을 뒤바꾸면 57.7로 가장 나빠졌고, 같은 지침을 양쪽에 쓰면 58.1과 59.1에 그쳤다. 예산 효율 측면에서는 T_C=T_E=1인 CEPO가 60.1로, 실행자를 3회 반복 최적화한 vanilla PE2보다 2.2점 높으면서 최적화기·MAS API 호출은 더 적었다. 에이전트 수를 1~5개로 늘린 실험에서도 vanilla PE2는 3개에서 비단조적으로 떨어졌지만 PE2+CEPO는 단조 증가해 5개에서 61.0에 도달했고, 2개 구성만으로 최적화하지 않은 5개 구성의 최고점을 넘었다.

개발자 입장에서 CEPO는 프롬프트 최적화기를 새로 도입하는 대신, 이미 쓰는 최적화기 위에 프롬프트 구조를 얹는 방식으로 MAS 품질을 올리는 선택지다. 특히 에이전트 수가 늘수록 조율 규칙을 공유 파라미터로 관리하는 이점이 커진다는 결과는, 에이전트를 추가할 때마다 프롬프트를 손으로 맞춰야 했던 팀에 유용하다. 다만 코디네이터 프롬프트가 모든 호출에 앞부분으로 붙는 구조이므로 실제 토큰 비용과 지연을 자기 워크로드에서 확인해야 하고, 2단계 순서나 실행자 부분집합 선택은 논문이 밝힌 대로 구현 선택지일 뿐 최적이라는 보장은 없다.

저자들이 밝힌 전제와 한계도 분명하다. CEPO는 구조와 지침만 제공하고 탐색은 하위 최적화기에 의존하므로, 최적화기 자체의 한계는 그대로 남는다. 또한 프롬프트 최적화가 쉬워지면 충분한 검증 없이 배포하려는 유혹이 생길 수 있고, 최적화된 프롬프트도 고위험 상황이나 분포 밖 입력에서는 의도치 않은 모델 동작을 낳을 수 있다고 경고하며, 배포 전 과업별 검증과 사람의 감독을 권고한다.