운영 혼란은 모델 문제가 아니다
다중 에이전트 시스템을 구축한 팀이 공통으로 겪는 장면이 있다. 에이전트들은 작동하고 있고, 태스크도 처리되고 있다. 그런데 어느 순간부터 인간 운영자가 "지금 무슨 일이 벌어지고 있는지" 파악하는 데 에이전트보다 더 많은 시간을 쓰게 된다.
원인을 모델 성능에서 찾는 경우가 많다. 더 좋은 모델로 교체하거나, 프롬프트를 정교하게 다듬거나, 오케스트레이션 프레임워크를 바꿔 보기도 한다. 그래도 운영 혼란은 줄지 않는다.
이 문제의 실제 원인은 대부분 다른 곳에 있다. 서로 성격이 다른 메시지들이 하나의 채널에 섞여 있어서, 인간 운영자가 맥락을 재구성하는 데 인지 비용을 계속 소비하는 구조다. 에이전트는 전체 컨텍스트를 갖고 있으니 누가 무엇을 요청했는지 추론할 수 있다. 운영자는 그렇지 않다.
이 문제는 시스템이 커진 다음에 수습하기 어렵다. 채널 구조는 요구사항 단계에서 설계해야 한다.
에이전트 하나가 실제로 처리하는 다섯 가지 대화
단일 에이전트 시스템에서는 "사람 한 명이 에이전트 하나에게 지시한다"는 전제가 성립한다. 에이전트가 팀 구조로 연결되는 순간 이 전제는 깨진다. 중간에 위치한 에이전트는 동시에 다섯 가지 유형의 메시지를 주고받는다.
상향(Upstream): 이 에이전트에게 목표를 부여하고 결과를 기다리는 감독자, 또는 감독 에이전트의 메시지다. 작업의 범위, 우선순위, 완료 여부 같은 메타 판단이 오간다. 감독자는 작업 내부에 있지 않다.
하향(Downstream): 이 에이전트가 관리하는 하위 에이전트들과의 메시지다. 지시가 내려가고, 진행 상황이나 완료 보고, 또는 블로커가 올라온다.
측면(Sideways): 같은 작업 공간 안에서 함께 작업하는 인간 협력자의 메시지다. "이 방향으로 바꿔", "왜 이렇게 했어", "멈춰, 그 방식은 틀렸어" 같은 메시지다. 보고 관계가 아니라 페어링에 가깝다. 이 채널의 메시지는 에이전트가 생성하지 않고 사람이 직접 입력한다는 점에서 다른 채널과 구별된다.
피어(Peer): 같은 레벨에 있는 다른 에이전트들과의 조율 메시지다. 누가 누구를 지휘하는 관계가 아니다. "내가 이 파일을 수정 중이니 기다려", "네 API 응답 형태가 어떻게 되는지 알려줘" 같은 내용이다.
알림(Alert): 빌드 실패, 테스트 오류, 웹훅 수신, 예산 소진 임박처럼 시스템이 발생시키는 신호다. 누군가가 질문하거나 지시하는 게 아니라, 상태가 바뀌었다는 사실이다.
이 다섯 가지는 권한 수준, 긴급도, 응답 방식이 각각 다르다. 상향 메시지는 목표를 정하고, 측면 메시지는 작업 방식을 조정하고, 하향 메시지는 참고 입력이지 명령이 아니고, 피어 메시지는 조율이지 지시가 아니고, 알림은 사실이지 요청이 아니다. 이것들이 한 줄의 스크롤에 섞이면 채널마다 달라야 할 처리 규칙이 무력해진다.
채널이 섞일 때 어떤 일이 벌어지는가
실패는 한 번에 드러나지 않는다. 처음에는 그냥 "조금 헷갈리는" 수준이다가, 시스템이 커지면서 비용이 누적된다.
권한이 희석된다. 하위 에이전트의 제안과 인간 운영자의 지시가 같은 형식으로 도착하면, 에이전트는 컨텍스트로 둘을 구분해야 한다. 컨텍스트가 길어질수록 이 구분이 흐려질 수 있고, 운영자는 에이전트가 올바르게 구분했는지 로그를 다시 읽지 않고는 확인할 방법이 없다.
피어 에이전트끼리 충돌한다. 측면 조율 채널이 없으면 형제 에이전트들은 공통 감독자를 통해 간접적으로 조율하거나, 아예 조율하지 않는다. 결과적으로 두 에이전트가 같은 파일을 동시에 수정하거나 같은 버그를 중복으로 처리하고, 감독자는 사후에 이를 발견한다.
알림이 작업을 끊거나 묻힌다. 알림이 대화 스크롤 중간에 섞이면 두 가지 문제가 동시에 생긴다. 중요한 알림이 지나쳐지거나, 반대로 에이전트가 모든 알림을 새 지시로 처리해서 진행 중이던 작업을 중단한다. 어느 쪽이든 운영자가 원하는 동작이 아니다.
인간이 개입하기 어려워진다. 운영자가 작업 중인 특정 에이전트를 수정하고 싶어도, 그 메시지는 다른 모든 메시지와 같은 큐에 쌓인다. 운영자임을 명시하는 구조적 표시가 없으면, 에이전트는 이 지시를 다른 에이전트의 제안과 동일하게 처리할 수 있다.
감사 추적이 불가능해진다. 무언가 잘못됐을 때 "누가 어떤 근거로 이 결정을 내렸는가"를 재구성할 수 없다면, 개선도 책임 소재 확인도 할 수 없다. 채널이 섞인 로그에서 이 추적은 사실상 수작업이 된다.
메시지에 태그를 붙이는 방식은 부분적인 해결책이 될 수 있다. 에이전트는 태그를 참고해서 처리 방식을 조정하는 데 도움이 된다. 그러나 운영자가 수천 줄의 태그된 메시지를 직접 읽어야 하는 구조라면, 태그는 인간의 운영 부담을 줄이지 못한다. 후자가 채널 분리 없이는 해결되지 않는 부분이다.
요구사항 단계에서 채널 분리를 설계하는 순서
채널 분리를 나중에 추가하는 것은 가능하지만, 운영 데이터와 에이전트 행동이 이미 단일 채널을 전제로 쌓인 다음에는 재구조화 비용이 높다. 요구사항 단계에서 아래 순서대로 결정하는 것이 비용이 낮다.
1단계: 에이전트 관계도 작성
팀 내 에이전트들이 어떤 관계를 맺는지를 그린다. 누가 누구를 감독하고, 어떤 에이전트들이 같은 레벨에서 협업하며, 어떤 인간이 어느 에이전트와 측면 협업 관계인지를 명시한다. 이 관계도가 채널 분류의 기준이 된다.
산출물: 에이전트 역할·관계 매핑 문서
2단계: 채널별 메시지 유형과 권한 정의
각 채널에서 어떤 종류의 메시지가 오가는지, 그 메시지가 에이전트 행동에 어느 정도의 권한을 갖는지를 명세한다. 예를 들어 상향 채널은 목표 설정과 범위 변경을 결정하고, 측면 채널은 작업 방식을 조정하며, 하향 채널에서 올라오는 내용은 에이전트가 참고하되 명령으로 처리하지 않는다는 식으로 구체화한다.
피어 채널은 요청과 정보 공유는 허용하되 지시는 허용하지 않는다고 명시한다. 알림 채널은 응답 대상이 아니라 처리 대상임을 구분한다.
산출물: 채널별 메시지 권한 명세서
3단계: 인간 운영자 뷰 설계
채널 분리는 에이전트가 메시지를 올바르게 처리하는 데만 필요한 것이 아니다. 인간 운영자가 각 채널을 독립적으로 열람하고 감사할 수 있어야 실질적인 가치를 갖는다. 하나의 에이전트를 열었을 때, 감독자가 내린 목표, 하위 에이전트의 보고, 피어와의 조율 내용, 시스템 알림, 그리고 자신이 직접 입력한 메시지를 각각 분리된 뷰로 볼 수 있는 인터페이스를 요구사항으로 정의한다.
이 단계에서 운영자가 실제로 필요한 필터와 알림 임계값을 정한다. 예를 들어 빌드 실패 알림은 즉시 운영자에게 노출하고, 린트 경고는 에이전트 큐에 쌓이되 운영자에게는 배치로 전달하는 방식이다.
산출물: 운영자 채널 뷰 와이어프레임과 알림 라우팅 규칙
4단계: 에이전트 응답 주소 지정 방식 명세
에이전트가 메시지를 보낼 때 "어느 채널로 보낼지"를 선택하는 로직을 설계한다. 보고는 상향 채널로, 작업 지시는 하향 채널로, 조율은 피어 채널로, 인간 협력자에 대한 답변은 측면 채널로 보내도록 한다. 알림 채널은 에이전트가 응답을 생성하는 채널이 아니고, 수신하고 처리 방식을 결정하는 채널이다.
이 로직이 프롬프트 규칙으로만 존재하면 지속성이 낮다. 하네스 레벨에서 채널 태깅을 강제하는 구조가 권고된다.
산출물: 에이전트 응답 라우팅 로직 명세
5단계: 파일럿 운영과 채널 위반 감지 기준 설정
실제 파일럿 운영 전에, 채널 혼용이 발생하는 경우를 어떻게 감지할지를 먼저 정한다. 예를 들어 하향 채널에서 에이전트가 목표 변경 메시지를 받은 경우, 피어 채널에서 지시형 메시지가 발생한 경우를 모니터링 지표로 설정한다. 파일럿 기간 동안 수집된 채널 위반 로그를 분석해서 명세를 보완한다.
산출물: 채널 위반 감지 지표와 파일럿 회고 보고서
지금 당장 확인할 수 있는 조기 신호
요구사항 단계이거나 이미 초기 구축 중이라면, 아래 신호 중 하나라도 해당되면 채널 분리 설계가 필요하다.
하나의 에이전트 로그를 열었을 때 누가 어떤 목적으로 메시지를 보냈는지 10초 안에 구분되지 않는다면 채널이 섞여 있다는 뜻이다. 에이전트가 상위 감독자의 목표 변경 요청과 하위 에이전트의 진행 보고를 같은 우선순위로 처리한다면 권한 체계가 없다는 뜻이다. 두 에이전트가 같은 리소스를 동시에 수정한 사례가 한 번이라도 있었다면 피어 조율 채널이 없다는 증거다. 운영자가 에이전트에게 개입하려 할 때 "내 메시지가 다른 메시지와 구분될까"라는 의심이 든다면 측면 채널이 구조적으로 설계되지 않은 것이다.
