AgentRadio: 작업 중에 듣는 메시지

두 에이전트가 같은 코드의 동작을 조사한다. 한쪽은 “이 설정은 시작할 때만 읽힌다”는 사실을 찾았지만 다른 쪽은 아직 실행 중 설정을 바꾸며 원인을 찾고 있다. 여러 에이전트로 코드 조사를 나눌 때는 마지막에 답을 모으는 능력만큼 동료의 발견을 다음 행동 전에 전달하는 능력이 중요하다.

Xinxing Ren 외의 AgentRadio: Passive Awareness for Long-Horizon Multi-Agent Collaboration(2026년 7월 30일, arXiv v1)은 그 전달 시점을 바꾼다. 모델이 수신 명령을 실행하며 작업을 멈추는 대신, 별도 프로세스가 메시지를 기다리고 다음 작업 단계에서 내용을 보여 준다. 논문이 부르는 수동적 인지(passive awareness)는 계속 채팅하라는 뜻이 아니다. 동료가 보낸 중요한 발견을 듣기 위해 하던 일을 별도로 중단하지 않는 방식이다.

마지막 보고가 오기 전에 틀린 가정을 고친다

다음은 논문 실험을 옮긴 것이 아니라, 통신 방식의 차이를 설명하기 위해 만든 가상 실행 순서다. 시작 시 설정을 읽는 작은 서버를 조사하며 탐색 담당과 실행 담당이 각각 일을 나눴다고 하자.

마지막 보고 시간에만 결과를 공유하면, 실행 담당은 2번의 가정으로 계속 조사한다. 메시지를 받으려고 수신 명령에 머무르면 다른 조사는 진행되지 않는다. 백그라운드 수신은 3번의 발견을 4번의 선택에 넣는 것으로 이 두 문제를 피한다. 메시지가 이미 실행 중인 요청을 취소하거나 과거 결과를 바꾸지는 않는다.

논문은 이를 세 연산으로 구현한다. create_thread는 참여자가 있는 대화 공간을 만들고 send_message는 메시지와 수신자 언급을 기록한 뒤 즉시 반환한다. wait_for_mention은 자신을 언급한 메시지가 올 때까지 기다리며 반환할 때 전체 대화 공간의 스냅샷도 준다. 받는 쪽이 배경을 복원하려고 따로 읽을 필요를 줄인 설계다. AgentRadio 원문

각 에이전트는 백그라운드 감시 프로세스 하나를 유지한다. 이 프로세스가 기다리는 동안 에이전트는 셸 명령 등 전경 작업을 계속한다. 받은 메시지는 작업 단계 사이에서 드러나므로 긴 명령 자체를 중단하지 않는다. 수신을 기다리는 프로세스는 새 LLM 호출이 아니지만 에이전트가 읽는 메시지는 컨텍스트와 토큰을 소비한다.

통신만 붙이면 분업이 완성되지는 않는다

논문의 팀은 네 에이전트로 구성한다. 각자 먼저 조사하고 조사 내용을 모아 질문을 나눈 다음 맡은 질문을 실행하며 서로 결과를 검토하고 마지막 답을 조립한다. 단계 전환은 조립 담당이 모든 참여자의 명시적 동의를 모은 뒤 진행한다. 실행 중 발견을 나누는 채널이 생겨도 이 검토·승인 경계가 사라지지는 않는다.

이 순서에는 이유가 있다. 처음부터 한 에이전트만 보고 질문을 나누면, 잘못된 경계가 모든 작업에 퍼진다. 가상 서버 사례에서 “설정 담당”과 “캐시 담당”을 먼저 정해 버리면, 실제로 필요 없는 캐시 조사도 정식 작업이 된다. 독립 탐색 뒤 협의하면 문제를 나누는 가정부터 비교할 수 있다. 그래도 실행 중 새 사실이 나오므로 작업 도중의 공유가 추가로 필요하다.

저자들은 이 차이를 단계별로 평가했다. 단일 에이전트에서 출발해 네 에이전트의 단순 분업, 협의와 상호 검토, 백그라운드 수신을 차례로 추가한다. 마지막 두 구성은 같은 다섯 단계 절차를 사용하며 백그라운드 수신 구성에는 실행 중 발견을 바로 공유하도록 안내한다. 따라서 결과는 수신 프로세스 하나의 순수한 성능보다 수신 방식과 그에 맞춘 공유 행동의 효과로 읽는 편이 정확하다.

정확도와 비용을 같은 표에서 읽는다

평가는 SWE-Atlas QnA의 124개 질문과 1,306개 채점 항목을 사용한다. 대상은 11개 저장소의 코드 이해 문제이며 에이전트는 코드를 빌드·실행할 수 있지만 소스를 수정할 수 없다. 질문 하나에 딸린 채점 항목을 모두 만족해야 해결로 인정한다. 같은 Claude Code 하네스, 높은 추론 수준과 온도 0을 사용하고 채점자는 Claude Opus 4.5로 고정한다.

아래는 원문 표 1·2의 전체 정확도와 비용을 합쳐 재구성한 저자 보고값이다. 분야별 행과 채점 항목 통과율은 생략했다. 비용은 요청 하나의 고정 가격이 아니라, 해당 구성으로 질문 하나를 처리한 평균 API 지출이다.

출처: AgentRadio 원문. 직접 재현한 측정값은 아니다.

Opus 4.6에서 마지막 단계의 차이는 62.1 − 51.6 = 10.5%포인트다. 정확도가 10.5% 늘었다는 표현과는 다르다. 같은 124개 질문의 짝 비교에서 새로 해결한 질문은 15개, 반대로 놓친 질문은 2개였고 저자들은 정확 McNemar 검정의 p값 0.0023을 보고한다. DeepSeek에서도 추가 해결 17개와 손실 3개, p값 0.0026이다. 개선과 퇴행을 함께 센 결과다.

비용도 오른다. Opus 4.6의 단일 구성과 전체 구성은 질문당 2.96달러와 19.45달러로, 정확도 비율만 보고 “저렴해졌다”고 말할 수 없다. 단일 실행을 여섯 번 반복한 비교는 비슷한 예산을 더 썼다고 같은 성능이 나오지 않는다는 근거다. 다만 논문의 여섯 실행 기준은 여섯 완전한 실행 중 최선을 보고하는 구성이다. 이를 일반적인 답 후보 여섯 개의 자동 선택 성능으로 바꿔 읽으면 안 된다.

한 가지 계산은 운영 판단을 돕는다. 위 표에서 평균 질문 비용을 해결률로 나눈 값은 Opus 단일 구성에서 약 9.16달러, 전체 구성에서 약 31.32달러다. 이는 표의 저자 보고값으로 계산한 리뷰자의 지표이며 성공 하나당 실제 청구서를 측정한 결과는 아니다. 같은 질문 분포에서 반복 사용한다고 가정하면, 전체 구성은 더 많은 질문을 해결하지만 이 계산상 성공 하나의 비용도 높다. 실패를 사람이 다시 조사하는 비용까지 크다면 선택이 달라질 수 있으나 그 비용은 이 실험에 없다.

MinIO 사례는 전달 시점이 왜 중요한지 보여 준다

평균 점수보다 저자의 설명을 구체적으로 뒷받침하는 것은 원문 그림 6의 MinIO 실행이다. 질문의 16개 채점 항목 중 5개는 서버의 요청별 로그를 확인해야 풀 수 있었다. 두 구성 모두 처음 계획에는 서버 로그를 켜는 작업이 없었다. 협의만 하는 구성에서도 한 에이전트는 감사 로그를 떠올렸고 다른 에이전트는 정확한 설정 이름을 찾았다. 그러나 실행 중 공유하지 않아 이 발견이 팀의 다음 행동으로 이어지지 않았다. 마지막 검토에서는 요청별 로그가 기본적으로 없다는 결론을 함께 승인했다.

백그라운드 수신 구성에서는 감사 웹훅을 켠 뒤 얻은 요청별 기록을 동료에게 보냈고 결과가 11개 통과에서 16개 통과로 바뀌었다. 이 사례가 보여 주는 실패는 지식 부족만이 아니다. 발견한 사실이 아직 수정할 수 있는 계획에 들어가지 못한 것이다. 마지막 답만 비교했다면 “네 에이전트가 더 잘 안다”로 끝났겠지만 실행 기록은 어떤 발견이 어떤 관찰을 가능하게 했는지 보여 준다. MinIO 실행 사례

이 사례와 짝 비교 결과를 함께 보면 실행 중 공유가 유용하다는 주장은 설득력이 있다. 다만 메시지가 도착한 시점, 이후의 계획 변경, 추가로 얻은 증거를 모든 질문에서 같은 기준으로 집계한 인과 분석은 아니다. 수신 방식과 공유 지시를 함께 바꿨으므로 같은 지시 아래 주기적으로 메시지를 확인하는 방식과 비교하면 백그라운드 수신 자체의 기여를 더 좁혀 볼 수 있을 것이다. 이는 이 리뷰에서 제안하는 후속 비교다.

점수의 변화도 평가 규칙과 함께 읽어야 한다. 한 질문은 모든 항목을 통과해야 해결로 인정하므로, 마지막으로 빠진 항목 하나를 채우는 발견은 질문 전체의 해결 여부를 바꾼다. 10.5%포인트의 해결률 상승이 코드 이해 능력 전반의 동일한 상승을 뜻하지는 않는다. 원문 그림 5의 난도별 분석도 협의 구성이 실패한 질문을 대상으로 한다. 빠진 항목 수에 따라 질문을 나눴다. 많이 놓친 질문에는 개선할 여지도 많고 일부 구간의 질문 수도 적다. 따라서 “어려울수록 더 효과적이다”는 관찰은 유망하지만 작업 난도가 효과를 일으켰다는 증명으로 읽기는 어렵다.

더 많이 들으면 더 많이 틀릴 수도 있다

수신 시점이 빨라졌다고 모든 메시지가 좋은 것은 아니다. Opus 실험에서 백그라운드 수신 단계는 협의 구성 대비 채점 항목 47개를 새로 통과했지만 23개를 잃었다. 저자들은 메시지가 기존 탐색에서 주의를 돌린 가능성을 제시한다. 이 설명은 손실 원인에 대한 해석이며 모든 손실을 메시지 때문이라고 증명한 결과는 아니다.

그래서 가상 서버 사례의 메시지는 “캐시가 아닐 듯”보다 “시작 함수에서 설정을 1회 읽음. 재시작 전후 비교 필요”가 낫다. 전자는 결론만 전달해 동료가 그대로 믿기 쉽다. 후자는 관찰과 다음 검증을 함께 전달해 받는 쪽이 자기 증거와 대조할 수 있다. 이런 메시지 설계는 이 글의 적용 제안이다. 새로운 효과를 실험으로 측정하지는 않았다.

가정 하나를 바꿔 보자. 서버가 설정을 요청마다 읽고 탐색 담당이 다른 초기화 경로를 잘못 본 경우다. 실행 담당이 메시지를 사실로 확정하면, 필요 없는 재시작으로 탐색을 더 어지럽힐 수 있다. 원본 경로와 실행 결과를 확인한 뒤 계획을 바꿔야 한다. 정보의 빠른 도착과 정보의 정확성은 별개다.

원문의 실패 사례도 이 경계를 보여 준다. Grafana 문제에서는 어느 에이전트도 필요한 부정적 결론을 만들지 못했고 수신 방식을 바꿔도 두 구성 모두 9개 항목 중 5개만 통과했다. 통신은 발견을 전달할 수 있지만 아무도 찾지 못한 사실을 만들어 주지 않는다. 전체 124개 질문은 구성당 한 번 실행했고 반복 변동 검사는 Opus 4.6의 30개 질문 부분집합에서 세 번 수행했다. 이를 모든 모델·작업의 안정성으로 확대할 근거도 없다.

메시지를 붙일지 결정하려면 업무 이름보다 의존 관계를 봐야 한다. 서로 독립적인 파일 변환은 마지막에 모아도 충분할 수 있다. 한쪽의 발견이 다른 쪽의 다음 명령을 바꾸는 코드 조사라면, 어떤 사실을 어떤 단계 전에 전달해야 하는지부터 적어 볼 만하다. 그 관계가 없다면 백그라운드 채널의 토큰 비용과 주의 분산만 늘어날 수 있다.

원문과 참고 자료

• Xinxing Ren 외, AgentRadio: Passive Awareness for Long-Horizon Multi-Agent Collaboration, arXiv:2607.28430v1, 2026년 7월 30일. 논문 · PDF
• 저자 공개 구현: Coral-Protocol/AgentRadio