멀티 에이전트 통신 수단 비교: Kanban, Coral, 직접 프롬프트, 그리고 그 외 접근 · DK 기술 블로그

TL;DR

에이전트가 여러 개일 때 통신 수단을 어떻게 고르느냐가 작업 흐름/속도/안정성을 크게 좌우한다.
대표적으로는 Kanban식 작업판, Coral 같은 실시간 @멘션 채널, 직접 프롬프트로 호출하는 방식이 있고, 그 밖에도 메시지 큐/브로커, 공유 메모리/블랙보드, 워크플로 엔진 같은 접근이 있다.
빠른 신호에는 실시간 채널이 유리하지만, 운영 부담과 Reasoning Drift 같은 문제가 따라온다. 작업 추적과 회고에는 Kanban이 안정적이고, 임시 협업에는 직접 프롬프트가 단순하다.
정답은 하나가 아니다. “얼마나 빠르냐”보다 “그 속도를 얻는 데 어떤 비용을 낼 수 있냐”가 더 중요한 기준이다.
이 글은 내가 실제로 써보면서 느낀 차이와 한계를 정리한 것이고, 범용 정답이 아니라 내 환경에서 나온 비교다.

들어가며

에이전트 여러 개를 쓰다 보면, 각자가 따로 잘하는 것과 별개로 “서로 어떻게 연결되느냐”가 작업 결과를 좌우한다. 한 에이전트가 작업을 끝나고 다음 에이전트가 이어받아야 할 때, 블로커가 생겼을 때, 급하게 상태를 공유해야 할 때, 어떤 통신 수단을 쓰느냐에 따라 흐름이 달라질 수밖에 없다.

나는 최근에 Kanban, Coral(AgentRadio) 실시간 @멘션, 직접 프롬프트 호출 같은 방식을 함께 쓰면서 차이를 체감했다. 여기에 더해 메시지 큐/브로커, 공유 메모리/블랙보드, 워크플로 엔진 같은 접근도 비교 대상으로 볼 만해서 함께 정리했다. 단순히 “실시간 vs 비실시간”으로만 보면 놓치는 부분이 많아서, 기준부터 나누고 각 방식의 장단점을 따로 봤다.

이 글은 특정 도구를 홍보하려는 게 아니라, 통신 수단을 고를 때 어떤 tradeoffs가 있는지 정리한 것이다. 내 환경에서 느낀 점이라 범용 정답은 아니다.

통신 수단을 비교하는 기준

세세하게 들어가면 끝이 없어서, 우선 여섯 가지 기준으로 좁혀 봤다.

속도/지연: 신호가 오갈 때 얼마나 빨리 도착하는가
흐름 제어: 작업 시작/끝/전이/블로커 같은 흐름을 얼마나 자연스럽게 다룰 수 있는가
운영 부담: 연결하고 유지하고 복구하는 데 손이 얼마나 가는가
실패 내성: 연결이나 세션이 흔들릴 때 얼마나 버티는가
추적성/회고: 누가 무엇을 했는지 기록이 남고, 나중에 돌아보기 쉬운가
확장성/복잡도: 에이전트가 늘어나거나 작업 분기가 많아질 때 얼마나 버티는가

이 기준으로 보면, “빠르냐 느리냐”만으로는 거의 설명이 안 된다. 빠른 대신 운영 부담이 큰 방식도 있고, 느린 대신 흔적이 잘 남는 방식도 있다.

Kanban / 작업판 기반 협업

Kanban은 작업 카드를 만들고, 상태를 옮기고, 할당하고, 완료로 넘기는 방식이다. 게시판처럼 일을 정리하고 흘러가게 만드는 데 강점이 있다.

장점부터 보면, 흐름이 안정적이고 기록이 남는다. “이 작업이 끝났다”, “다음 작업은 이거다” 같은 신호를 카드 단위로 처리하기 쉽다. 에이전트 여러 개가 한꺼번에 떠들지 않고, 상태를 보고 반응하는 구조라 혼선이 적은 편이다. 나중에 회고하거나 진행 상황을 정리할 때도 유리하다.

단점은 실시간성이 약하다는 점이다. 급하게 “지금 막혔어” 같은 신호를 보내도, 상대가 바로 보고 반응하려면 카드 상태를 확인해야 한다. 빨라야 하는 장면에서는 느리게 느껴질 수 있다. 작업판 흐름을 벗어나 즉흥적으로 메시지를 던지는 데는 어울리지 않는다.

내가 느낀 Kanban의 핵심은 이랬다. 협업 그 자체보다는 작업 관리와 추적에 강하다. 진행 상황을 남기고, 끝을 명확히 하고, 누가 뭘 맡았는지 정리하는 데는 좋다. 하지만 즉시 반응이나 작업 흐름을 끊지 않고 메시지만 던지는 용도에는 약하다.

Coral / 실시간 @멘션 채널

Coral은 에이전트 사이에 실시간 @멘션 기반 통신 채널을 제공한다. 스레드를 만들고, 메시지를 보내고, 멘션을 기다리는 식의 도구를 쓸 수 있다. Kanban이 게시판이면, Coral은 그 위에 열린 단체 메신저에 가깝다.

장점은 속도다. 작업 착수/완료/블로커 같은 신호를 짧게 던질 수 있고, 다른 에이전트가 바로 받을 수 있다. 작업 분장이 급히 필요할 때, “이 작업 끝났으니 다음 맡아” 같은 메시지를 바로 보내기 좋다. 실시간성이 필요한 장면에서는 확실히 편하다.

대신 문제도 분명하다. 내가 실제로 겪거나 본 지점만 정리하면 이렇다.

Reasoning Drift: 에이전트가 일하는 중간에 다른 메시지를 받으면, 특히 작은/무료 모델일수록 원래 흐름이 흔들릴 수 있다. 보고서 쓰던 직원에게 전화가 계속 오는 상황과 비슷하다.
턴 소비: wait_for_mention 같은 도구는 에이전트가 직접 호출해서 멘션을 기다린다. 직관적이지만 호출할 때마다 턴을 쓰는 구조라, 조용히 기다리는 것과는 다르다.
운영 부담: Coral 세션은 in-memory라 서버 재부팅이나 UUID 만료 시 연결이 끊길 수 있다. 재주입으로 복구 가능하지만, 매번 손을 봐야 하는 부담이 남는다.
스레드 소멸: 세션이 살아 있어도 이전 스레드 ID가 바로 소멸되는 경우가 있어서, 기존 스레드로 보내려다 실패하는 일이 생긴다. 새 스레드를 만들어 써야 한다.

내가 느낀 Coral의 핵심은 이랬다. 속도와 즉각성은 강점인데, “꼭 Coral이어야 하느냐”는 질문은 따로 봐야 한다. Kanban + Discord만으로도 협업은 된다. Coral은 그 위에 실시간 @멘션 옵션을 얹은 것이다. 실시간성이 진짜 필요한지, 아니면 그냥 빨라 보이면 좋겠다는 느낌인지에 따라 가치가 달라진다.

직접 프롬프트 / 그냥 불러내기

세 번째 방식은 통신 수단을 따로 두지 않고, 그냥 프롬프트로 직접 다른 에이전트를 불러내는 접근이다. “이 작업 해줘”, “결과 확인해줘”처럼 직접 지시하거나, 필요하면 다른 에이전트에게 직접 요청을 던지는 식이다.

장점은 단순함이다. 별도 채널이나 세션 관리가 필요 없고, 원하는 순간에 원하는 에이전트에게 바로 말할 수 있다. 임시로 한두 번 협업을 붙이는 데는 편하다.

단점도 분명하다. 협업 구조로서는 약하다. 작업 분담/종료 신호/블로커 공유 같은 흐름이 조직적으로 남기 어렵고, 누가 뭘 했는지 추적도 느슨해진다. 에이전트가 여러 개로 늘어나면, 서로 직접 부르는 방식만으로는 금방 복잡해진다.

내가 느낀 직접 프롬프트의 핵심은 이랬다. 임시 협업/일회성 확인/간단한 지시에는 괜찮다. 하지만 협업이 반복되고, 작업 분장이 생기고, 끝과 상태를 추적해야 하면 통신 수단을 따로 두는 편이 낫다.

그 밖에 볼 만한 접근들

위에서 본 세 방식 말고도, 에이전트 통신을 바라보는 다른 축이 있다. 모두 직접 써본 건 아니지만, 비교하면 의미가 있어서 같이 적는다.

메시지 큐/브로커

에이전트들이 직접 서로를 부르는 대신, 중간 큐나 브로커를 두고 메시지를 주고받는 방식이다. 생산자와 소비자가 분리되기 때문에, 한 에이전트가 막혀도 다른 에이전트가 바로 영향받지 않게 만들기 쉽다. 비동기 처리에 강하고, 작업 순서나 재처리 같은 것도 다루기 좋다.

다만 설정이 늘어나고, 브로커가 병목이 될 수도 있다. “빠른 즉답”보다는 “흐름을 분리하고 안정성을 확보하는 데” 더 어울리는 방식이다. 실시간 @멘션처럼 즉각 반응하는 느낌은 약하다.

공유 메모리/블랙보드

여러 에이전트가 하나의 공유 공간(블랙보드)에 정보를 쓰고 읽는 방식이다. 한 에이전트가 상태를 남겨 두면 다른 에이전트가 그걸 보고 다음 행동을 정할 수 있다. 공통된 상황 인식이 필요할 때 유리하다.

대신 공유 공간이 잘못 설계되면 경합이나 stale 데이터 문제가 생길 수 있다. “누가 언제 뭘 썼는지” 추적이 흐려질 수도 있다. 실시간 통신이라기보다, 공통 상태를 매개로 한 간접 통신에 가깝다.

워크플로 엔진/오케스트레이션

작업 흐름 자체를 엔진이나 오케스트레이터가 관리하는 방식이다. 어떤 에이전트가 어떤 순서로 어떤 작업을 할지 정의하고, 상태 전이를 관리하는 형태다. 큰 워크플로우를 통제할 때는 강점이 있다.

대신 워크플로를 미리 정의해야 하고, 즉흥적인 협업이나 급한 신호에는 딱딱해질 수 있다. 유연성과 통제 사이에는 항상 tradeoff가 있다.

비교 표

아래 표는 지금까지 본 방식들을 한 번에 비교한 것이다. 수치처럼 딱 떨어지는 값은 아니고, 내 경험상의 감각을 정리한 것이다.

방식	속도/지연	흐름 제어	운영 부담	실패 내성	추적성/회고	확장성/복잡도
Kanban	느림~중간	강함	낮음	비교적 높음	좋음	비교적 잘 버틴다
Coral 실시간	빠름	신호 전달에 강함	높음	연결/세션 흔들리면 복구 필요	신호 기록은 남지만 흐름 추적은 별도	에이전트 늘면 스레드/멘션 관리가 복잡해질 수 있음
직접 프롬프트	즉시적일 수 있음	약함	낮음	단순해서 실패 지점 적음	약함	규모 커지면 혼란해지기 쉬움
메시지 큐/브로커	비동기라 즉답은 아님	흐름 분리에 강함	중간~높음	브로커 의존	메시지 기록으로 추적 가능	규모 확장에 유리
공유 메모리/블랙보드	상황에 따라 다름	상태 공유에 강함	중간	공유 공간 의존	상태 이력에 따라 다름	쓰기 규칙이 중요
워크플로 엔진	흐름에 따라 다름	전체 흐름 통제로 강함	중간~높음	엔진 의존	워크플로 기록으로 추적 가능	큰 흐름에 유리하지만 초기 설계 필요

표만 보면 Coral이 속도에서 강해 보이지만, 실제로는 그 속도를 얻는 대가로 운영 부담과 Reasoning Drift 문제를 함께 떠안는다. 반대로 Kanban은 덜 빠르지만 안정적이고 흔적이 남는다. 직접 프롬프트는 가장 단순하지만 협업 구조로서는 약하다. 메시지 큐나 워크플로 엔진은 실시간성보다 흐름 분리/통제/확장에 더 맞는다.

시각화 / 통신 흐름과 지연/리스크 포지션

말로만 보면 차이가 흐려져서, 통신 흐름을 단순한 다이어그램으로 그려 봤다. 아래 SVG는 에이전트들이 어떤 채널에 기대느냐, 그 채널에서 어떤 문제가 생기기 쉬운지를 개념적으로 보여 준다.

위 다이어그램은 실제 아키텍처 도면이라기보다, 각 통신 수단이 어디에 가까운지 감각을 잡기 위한 개념도다. 점선 상자가 통신 채널/중간 구조고, 에이전트마다 어떤 채널을 통해 신호를 주고받느냐가 다르다.

선택 가이드

내가 통신 수단을 고를 때 보는 건 “얼마나 빨리냐”만은 아니다. 그 속도를 얻는 데 어떤 비용을 내는지가 더 중요하다.

작업 추적과 회고가 중요하면 Kanban 쪽으로 간다.
급한 신호, 블로커, 다음 작업 넘기기가 중요하고, 운영 부담을 감수할 수 있으면 Coral 쪽을 본다.
그냥 한두 번 부르고 끝내거나, 협업 구조 자체가 약해도 되는 상황이면 직접 프롬프트가 편하다.
작업 흐름을 분리하고, 생산자와 소비자를 떨어뜨리고 싶으면 메시지 큐/브로커가 맞을 수 있다.
공통 상태 인식이 중요하면 공유 메모리/블랙보드 쪽을 볼 수 있다.
전체 워크플로우를 통제해야 하면 워크플로 엔진/오케스트레이션이 맞는다.

즉 기준을 한 줄로 말하면 이렇다. “실시간 신호가 정말 필요한가, 그 신호를 위해 운영 부담/Reasoning Drift/연결 복구를 감수할 가치가 있는가”를 먼저 본다. 그 질문에 답이 없으면 Coral은 과잉이 되기 쉽다.

내가 겪은 흔한 오해

“실시간이면 무조건 좋다”

그렇지 않다. 실시간은 빠르지만, 빠르기 때문에 생기는 문제도 있다. 에이전트가 일하는 중간에 들어오는 메시지는 작업 흐름을 흔들 수 있고, 연결/유지에 들어가는 운영 부담도 생긴다. 빠르면 다 좋은 게 아니라, 빠름을 얻는 만큼 복잡도와 리스크를 같이 받는 구조다.

“Coral이 있으면 협업이 자동으로 잘 된다”

그렇지 않다. Coral은 채널일 뿐이다. 그 채널을 어떻게 쓰느냐가 더 중요하다. 실제로 협업이 잘 되려면, 언제 메시지를 보내고, 언제 작업 끝을 선언하고, 블로커를 어떻게 공유할지에 대한 흐름이 있어야 한다. 채널이 있어도 흐름이 없으면 그냥 소음이 된다.

“직접 프롬프트면 충분하다”

작은 규모에서는 그럴 수 있다. 하지만 에이전트가 여러 개로 늘고, 작업 분장이 생기고, 상태 추적이 필요해지면 직접 프롬프트만으로는 금방 부족해진다. 그때는 통신 수단을 따로 두는 쪽이 낫다.

“한 가지 통신 수단만 쓰면 된다”

현실에서는 하나의 수단으로 모든 장면을 커버하기 어렵다. 급한 신호에는 실시간 채널이 필요하고, 끝과 흐름은 Kanban이 낫고, 임시 호출은 직접 프롬프트가 편하다. 그래서 실제로는 여러 수단을 섞어 쓰는 경우가 많다. 중요한 건 섞어 쓰는 이유를 알고 쓰는지다.

결론

에이전트 통신 수단은 하나만 고를 수 있는 문제가 아니다. Kanban은 안정적이고 추적에 강하지만 실시간성은 약하다. Coral은 빠르고 즉각적이지만 운영 부담과 Reasoning Drift 같은 문제가 붙는다. 직접 프롬프트는 단순하지만 협업 구조로서는 약하다. 메시지 큐, 공유 메모리, 워크플로 엔진은 또 다른 축을 맡아 준다.

내가 볼 때는 “얼마나 빨리 필요한가”보다 “그 속도를 얻는 데 어떤 비용을 낼 수 있나”가 더 중요한 기준이다. 그 질문에 답이 정리되면, 통신 수단 선택도 훨씬 덜 흔들린다.

이 글도 내 경험에서 나온 비교라 범용 정답은 아니다. 내 환경에서는 이렇게 보였고, 다른 환경이면 결론은 달라질 수 있다.

참고: Coral 관련 세부 동작(스레드 소멸, 세션 in-memory, UUID 만료 후 재주입 필요, wait_for_mention의 턴 소모, Reasoning Drift와 0-turn 주입의 관계)은 Coral(AgentRadio) 로컬 fleet 스킬과 MCP/ACP/Coral 통신 글에서 정리한 내용을 반영했다. 이 글은 그 연장선에서 통신 수단 비교를 더 넓게 다룬 것이다.