멀티 에이전트 도구는 대화 채널을 나눠야 한다

여러 에이전트가 한 팀으로 움직이면 한 에이전트에는 상사·작업자·동료·사람·알림에서 오는 다섯 흐름이 한꺼번에 들어온다. 지금의 도구는 이를 하나의 대화창에 섞어 놓는다.

하르샬 가자르는 매일 쓰는 도구로 에이전트들을 연결해 보며, 사람의 감독과 조율이 어려워진다고 주장한다. 그가 제안하는 해법은 메시지를 관계별 채널로 나누는 것이다. 여러 에이전트를 감독하는 사람이라면 어떤 메시지가 누구에게서 왔는지 한눈에 파악하는 데 도움이 될 수 있다.

어떤 대화가 한데 섞이나?

가자르가 구분한 흐름은 다섯 가지다. 상위 흐름은 작업을 맡긴 감독자나 사람과 목표·우선순위·진행 상황을 주고받는다. 하위 흐름은 에이전트가 관리하는 작업자들과 지시·진행 상황·결과·장애물을 주고받는 관계다.

옆 흐름은 에이전트와 같은 작업 안에서 파일이나 문서를 함께 보는 사람과의 협업이다. 여기서는 사람이 직접 메시지를 보내며, 작업 방식이나 특정 코드·문단을 바로잡는다. 동료 흐름은 같은 수준의 다른 에이전트와 조율하는 채널이다. 서로 명령을 내리는 관계가 아니라, 같은 파일을 수정 중인지 묻거나 API 반환 형태를 확인하는 식으로 정보를 주고받는다. 알림 흐름에는 빌드 실패, 테스트 실패, 타이머, 웹훅, 예산 소진 임박처럼 대화 상대가 아닌 사건이 들어온다.

상위 흐름과 옆 흐름은 모두 사람이 지시할 수 있어 혼동하기 쉽다. 하지만 상위 역할은 목표·기한·승인처럼 작업 바깥에서 일의 방향을 다룬다. 옆 역할은 작업 안에서 특정 코드 줄이나 문단을 짚는다. 같은 사람이 두 역할을 맡을 수 있지만, 각 메시지는 어느 한쪽에 속한다.

한 대화창에 섞이면 무엇이 꼬이나?

메시지 출처가 뒤섞이면 권한의 차이가 흐려진다. 하위 에이전트나 동료의 제안이 사람의 지시와 똑같이 보일 수 있다. 모델은 맥락으로 구별할 수 있지만, 이를 보장하는 구조는 없고 사람은 메시지를 다시 읽어야 한다.

응답이 엉뚱한 곳에 전달되기도 한다. 에이전트가 하위 작업자의 질문에 사람만 보는 곳에서 답하거나, 작업자에게 할 말을 감독자에게 보고할 수 있다. 동료 간 직접 채널이 없으면 에이전트들이 감독자를 거쳐 조율하거나 아예 조율하지 않는다. 그러면 둘이 같은 파일을 고치거나 같은 버그를 각각 해결한 뒤에야 감독자가 알게 된다.

알림은 대화에 묻혀 놓칠 수도 있고, 반대로 새 지시처럼 취급돼 진행 중인 작업을 끊을 수도 있다. 사람이 작업 도중 에이전트를 바로잡으려 해도 메시지가 다른 것들과 같은 대기열에 들어간다. 나중에 결정을 되짚을 때 누가 무엇을 결정했고 무엇이 계기였는지 재구성하기도 어려워진다.

발신자 표시나 [ALERT] 같은 표식을 붙이면 일부 문제는 줄일 수 있다. 하지만 사람의 개입과 기록 확인 문제는 메시지를 하나의 긴 흐름에 계속 쌓는 방식으로 해결되지 않는다. 표시가 있어도 중요한 한 줄을 찾으려면 수많은 메시지를 읽어야 하기 때문이다.

도구는 채널을 어떻게 나눠야 하나?

가자르의 제안은 모델을 더 똑똑하게 만드는 대신 도구에 구조를 두는 것이다. 에이전트의 작업 맥락은 하나로 유지하되, 모든 메시지를 상위·하위·옆·동료·알림 가운데 하나로 표시하고 도구가 그 구분을 강제해야 한다. 단순히 프롬프트에 규칙을 적어 두는 방식이 아니다.

사람에게는 채널마다 별도의 화면이나 필터를 제공해야 한다. 감독자의 요청, 작업자들의 말, 동료 간 조율, 알림, 사람이 보낸 메시지를 한꺼번에 스크롤하지 않고 각각 확인할 수 있어야 한다. 채널별 기록을 따로 보면 관계별로 대화를 감사할 수 있다.

응답도 채널을 지정해 보내야 한다. 상위에 보고하기, 하위에 지시하기, 사람에게 답하기, 동료에게 알리기는 하나의 일반적인 전송 동작이 아니다. 알림에는 답장 대신 확인·처리·상향 보고를 해야 한다.

채널별 권한도 달라야 한다. 상위는 목표를 정하고 달성 여부를 판단한다. 소유자인 사람의 옆 채널 메시지는 작업 방법을 구체적으로 바꿀 수 있다. 하위 에이전트의 메시지는 명령이 아니라 입력으로 취급한다. 동료는 질문하고 정보를 전할 수 있지만 지시할 수 없다. 알림은 지시가 아니라 사실을 전달한다.

알림의 심각도 분류, 중복 제거, 전달 경로도 도구가 맡아야 한다. 실패한 배포는 작업을 중단시킬 만큼 중요할 수 있지만, 간헐적으로 발생하는 린트 경고는 대기열에 둘 수 있다. 에이전트가 알림에 대응할 수는 있어도, 알림이 사람의 메시지인지 스스로 판별하게 해서는 안 된다는 주장이다.

왜 지금 채널 분리가 필요하나?

가자르는 조직도와 이메일의 받는 사람·참조·상사 표시, 슬랙의 DM과 채널, PagerDuty의 호출이 이미 서로 다른 관계와 알림을 구분한다고 짚는다. 반면 다중 에이전트 시스템은 한 사람과 한 에이전트의 대화를 전제로 한 채팅 화면에 머물러 있다는 것이다.

그는 단일 에이전트 도구가 충분히 발전하면서 사람들이 에이전트를 연결하기 시작했고, 이제 작업 단위가 개별 에이전트가 아니라 연결된 에이전트 팀으로 바뀌고 있다고 본다. 다음에 쓸 도구는 사람과 에이전트 모두에게 누가 말하는지, 아니면 대화가 아닌 알림인지 분명히 보여줘야 한다는 것이 그의 주장이다.

원문은 채널 분리를 구현한 도구나 적용 사례, 이 방식의 효과를 측정한 결과는 밝히지 않는다.