facts

SWE-Atlas QnA 벤치마크 결과에서 주목할 점은 모델의 체급보다 에이전트 간의 협업 구조가 더 큰 성능 향상을 가져왔다는 사실이다. 코랄 AI 랩스(Coral AI Labs)와 여러 대학 연구진이 개발한 'AgentRadio'를 적용한 에이전트 팀은 기업용 코드베이스 분석 작업에서 62.1%의 성공률을 보였다. 이는 단일 클로드 코드(Claude Code) 인스턴스가 오퍼스 4.6 모델을 썼을 때의 32.3%보다 두 배 가까이 높은 수치이며, 더 상위 모델인 오퍼스 4.8을 사용한 단일 에이전트의 성공률 57.2%마저 넘어선 결과다.

AgentRadio는 에이전트가 메인 작업을 중단하지 않고도 실행 단계 사이에서 서로 소통할 수 있게 만드는 비동기 메시지 전달 계층이다. 시스템은 세 가지 핵심 기본 요소(primitive)로 작동한다. 참여 에이전트 간 대화를 여는 `create_thread`, 메시지를 보내고 즉시 제어권을 반환하는 `send_message`, 그리고 자신을 언급한 메시지가 올 때까지 프로세스를 대기시키는 `wait_for_mention`이 그것이다. 이를 통해 에이전트는 자신의 작업을 수행하면서 동시에 배경에서 다른 에이전트의 업데이트를 인지하는 '수동적 인식(passive awareness)' 상태를 유지한다.

구현 방식은 가볍다. 독립적인 프로세스로 작동하는 메시지 서버가 모든 스레드와 메시지를 관리하며, 에이전트는 세 개의 간단한 쉘 스크립트를 통해 서버와 상호작용한다. 에이전트 하네스가 쉘 명령어를 백그라운드 작업으로 실행할 수만 있다면 클로드 코드나 코덱스 CLI(Codex CLI) 같은 기존 도구의 내부 코드를 수정하지 않고도 바로 연결할 수 있다.

market-flow

이번 성과는 AI 에이전트의 성능 개선 방향이 '모델 스케일링'에서 '조정 구조(coordination structure)'로 이동하고 있음을 보여준다. 그동안 단일 에이전트 시스템은 코드베이스가 커질수록 초기 계획을 수정하기 어렵고, 뒤늦게 발견한 증거가 전체 계획에 반영되지 않는 '커버리지 문제'에 직면했다. 이를 해결하기 위해 업무를 나누는 멀티 에이전트 방식이 도입됐으나, 기존 시스템들은 치명적인 한계가 있었다.

기존의 멀티 에이전트 구조는 크게 세 가지 패턴에 머물러 있었다. 에이전트들이 완전히 고립되어 병렬 작업만 수행하거나, 정해진 라운드가 끝나야만 소통할 수 있는 '라운드 동기화' 방식, 혹은 상위 에이전트가 하위 에이전트에게 작업을 배분하는 하향식 비동기 방식이다. 특히 라운드 동기화 방식은 한 에이전트가 결정적인 버그를 발견해도 다른 에이전트들이 현재 라운드를 마칠 때까지 기다려야 하므로, 잘못된 경로로 자원을 낭비하는 경우가 많았다.

AgentRadio는 '작업 중인 에이전트는 동시에 들을 수 없다'는 기존의 상호 배제 문제를 해결했다. 에이전트들이 수평적인 자연어 채널을 통해 실시간으로 중간 발견 사항을 공유하고 협상하게 함으로써, 상호 의존성이 높은 기업용 코드 분석 작업에서 효율을 극대화했다. 이는 단순한 모델 업그레이드보다 적절한 통신 아키텍처를 설계하는 것이 복잡한 장기 과제(long-horizon tasks) 해결에 더 유리하다는 선택지를 시장에 제시한다.

reader-impact

한국의 AI 실무자와 개발자가 주목해야 할 지점은 고성능 모델 도입 비용을 들이지 않고도 아키텍처 변경만으로 성능을 끌어올릴 수 있는 구체적인 경로가 확인됐다는 점이다. 특히 AgentRadio가 Apache 2.0 라이선스로 공개되어 있어, 자체 코딩 에이전트를 구축 중인 기업은 모델을 교체하는 대신 메시지 서버와 얇은 어댑터(thin adapter)를 추가하는 방식으로 성능 검증을 시도할 수 있다.

실무적으로는 에이전트에게 '워처(watcher)'를 백그라운드에서 실행하도록 시스템 프롬프트를 설정하고, 제공된 쉘 스크립트를 통해 메시지를 주고받게 하는 워크플로우를 구축하는 것이 핵심이다. 깃허브(GitHub)에 공개된 코드를 통해 기존 스택에 통합해 볼 수 있으며, 이때 모델의 추론 능력 자체보다 에이전트들이 서로의 상태를 얼마나 적시에 공유하도록 프롬프트를 설계하느냐가 실제 성공률을 결정하는 변수가 될 것이다.

결국 개발자는 더 큰 파라미터의 모델을 찾는 경쟁에서 벗어나, 에이전트 간의 '수평적 소통 채널'을 어떻게 설계하고 관리할 것인지에 대한 오케스트레이션 전략을 우선적으로 검토해야 한다.