멀티 에이전트 시스템이 복잡할수록 사용자에게는 오히려 더 단순하게 보여야 합니다.
이세돌 9단의 시연 현장에서는 멀티 에이전트가 동시에 작동했습니다. PM Agent가 기획하는 동안 Design Agent가 설계하고, Coding Agent가 구현했습니다. 그러나 사용자가 마주한 것은 하나의 대화창이었습니다.
시스템 내부에서 무슨 일이 일어나는지 사용자는 알 필요가 없었습니다. 요청하고, 결과를 받으면 됐습니다.
지난 1회차에서 에이전트들이 어떻게 소통하고 협업하는지를 다뤘다면, 이번 편에서는 그 복잡한 시스템이 어떻게 하나의 화면으로 보이는지를 다룹니다.
에이전트마다 다른 정보를 봐야 하는 이유
멀티 에이전트는 분명 강력하지만, 그만큼 trade-off도 존재합니다. 에이전트끼리 서로 다른 판단을 내려 충돌이 생기기도 하고, 한 에이전트가 내린 결정이 다른 에이전트에 제대로 전달되지 않기도 합니다. 모든 에이전트가 전체 컨텍스트를 공유하면 토큰 비용이 폭발적으로 늘어납니다.
Enhans는 에이전트마다 다른 역할을 부여하고, 해당 역할에 필요한 정보만 전달하며 나머지는 구조적으로 차단하는 방식을 택했습니다.
PM Agent는 사용자의 원본 요청과 전체 기획 맥락, 프로젝트 히스토리를 받지만 코드 상세나 디자인 파일은 보지 않습니다. Design Agent는 PM이 정리한 기획 요약과 디자인 지시사항, 브랜드 가이드만 받고 사용자와의 원본 대화나 상세한 코드 구축 내용은 보지 않습니다.
이러한 컨텍스트 분리를 통해 각 에이전트는 자기 역할에만 집중할 수 있고, 불필요한 정보로 인한 혼선과 비용 낭비를 구조적으로 막을 수 있습니다.
Bridge Layer: 사용자 입력부터 에이전트 실행까지
컨텍스트 분리를 통해 역할이 나눠진 에이전트들에게 메시지를 전달하는 역할은 Bridge Layer에서 처리합니다. 사용자 입력이 에이전트에게 전달되는 흐름은 세 단계로 나뉩니다.
첫째, Interface Bridge가 텍스트, 음성 등 사용자에게 다양한 형태의 입력을 받아 방식에 상관없이 일반 텍스트로 변환합니다. 입력 형태가 달라도 이후 처리는 동일한 경로로 진행됩니다.
둘째, User Bridge가 그 텍스트를 구조화된 포맷으로 변환하고 OS Agent에 필요한 컨텍스트를 함께 주입합니다. 과거 대화 목록은 최근 내용을 비교적 자세하게, 이전 작업 이력은 "코딩 에이전트가 로그인 모듈을 생성했음"처럼 메타 정보만 압축된 형태로 함께 제공합니다. OS Agent는 이 구조화된 데이터를 받아 사용자의 의도를 해석하고 어떤 행동을 할지 판단하는 것에만 집중할 수 있게 됩니다.
셋째, Agent Bridge가 OS Agent의 판단을 각 서브 에이전트에게 전달합니다. 이때 반환 주소(Return Address)를 함께 등록합니다. 작업이 완료됐을 때 결과를 어디로 돌려줘야 하는지를 미리 명시해두는 구조입니다. OS Agent가 PM Agent에게 위임할 때 반환 주소에 "OS"가 등록됩니다. PM Agent가 Design Agent에게 다시 위임하면 반환 주소에 "PM"이 등록됩니다. 작업이 완료되면 각 에이전트는 등록된 반환 주소로 결과를 돌려줍니다. 에이전트가 "이 결과를 누구에게 전달해야 하지?"를 판단하는 과정이 없습니다. Bridge 레이어가 명시된 주소로 돌려주면 됩니다.
여러 작업이 동시에 진행되더라도 반환 주소 덕분에 작업 순서가 꼬이지 않습니다. 에이전트는 추론과 실행에만 집중하고, 메시지 전달, 컨텍스트 보강, 안전장치는 Bridge 레이어가 담당합니다. 에이전트의 성능과 Bridge의 안정성을 독립적으로 분리해 각각 발전시킬 수 있는 구조입니다.
HITL Gate: 모든 결정을 AI에게 맡기지 않는 이유
에이전트가 모든 작업을 스스로 처리할 수 있으면 좋겠지만, 모호한 요청이나 중요한 방향 결정은 사용자의 의도를 확인하는 절차가 필요합니다. 이때 HITL Gate(Human-In-The-Loop Gate)는 사용자의 의도를 확인하는 시점을 시스템이 판단하도록 하는 장치입니다.
서브 에이전트가 사용자의 선택이 필요하다고 판단하면 Bridge Layer가 Interface Bridge에 해당 내용을 전달하고, UI에 선택 버튼이 표시됩니다. 에이전트는 대기 상태로 전환됩니다. "어떻게 할까요?"가 아니라 추천 선택지를 함께 제시합니다.
사용자가 선택하면 입력이 User Bridge를 통해 OS Agent에 전달됩니다. OS Agent는 LLM을 호출하기 전에 현재 대기 중인 에이전트가 있는지 확인합니다. 대기 에이전트가 존재하면 LLM 호출 없이 해당 에이전트에게 직접 라우팅합니다. 지연 감소, 비용 절감, 의미 왜곡 방지가 동시에 달성됩니다.
일정 시간이 지나도 응답이 없으면 재질문하고, 그래도 없으면 추천된 선택지로 진행합니다. 대부분의 작업은 빠르게 자동으로 처리하되, 선택이 필요한 순간에서만 사람이 개입해 완성도를 높이는 구조입니다.
Interface Bridge: 에이전트의 결과가 사용자에게 보이는 방식
지금까지는 사용자의 입력이 에이전트에게 전달되는 흐름을 다뤘습니다. 이번에는 반대로, 에이전트가 작업을 완료했을 때 그 결과가 사용자에게 어떻게 전달되는지를 다뤄보겠습니다.
에이전트 시스템 내부에서는 기획서, 이미지, 코드, 진행 상태 등 다양한 형태의 결과가 생성됩니다. 이것들이 웹, 모바일, 음성 등 서로 다른 환경에서 각각 다른 방식으로 표현되어야 합니다. Interface Bridge는 이 문제를 해결하기 위한 계층입니다.
에이전트는 특정 UI 구현 방식에 의존하지 않고, 5가지 표준 이벤트만 발행합니다. conversation은 사용자와 시스템 간의 대화 흐름을 담습니다. agent_bubble은 에이전트의 현재 작업 상태를 짧은 문장으로 전달합니다. content_viewer는 기획서, 표, 이미지 갤러리처럼 정보 밀도가 높은 결과를 표시합니다. agent_panel은 보조 정보와 제어 요소를 패널 형태로 구성합니다. action_buttons는 사용자가 다음 행동을 선택해야 할 때 선택지를 제공합니다.
같은 이벤트라도 웹에서는 카드로, 모바일에서는 전체 화면으로, 전화 기반 시스템에서는 음성 안내로 전달됩니다. 에이전트는 무엇을 전달할지만 결정하고, 어떻게 보여줄지는 Interface Bridge가 처리합니다. 웹에서 작동하던 시스템을 모바일로, 음성 인터페이스로 확장할 때 에이전트 코드를 수정할 필요가 없습니다. Interface Bridge 구현체만 교체하면 됩니다.
Dual-Path: 빠른 응답과 대화 연속성을 동시에
에이전트의 결과는 두 경로로 동시에 처리됩니다.
UI 직접 투사 경로는 content_viewer, agent_panel 등의 표준 이벤트를 Interface Bridge가 받아 사용자에게 즉시 전달합니다. 오케스트레이터를 거치지 않고 직접 투사하기 때문에 응답이 빠릅니다.
OS 컨텍스트 기록 경로는 동일한 결과의 텍스트 요약을 OS Agent의 대화 페로몬 파일에 기록합니다. 이 기록이 있어야 이후 음성 안내나 후속 추론이 자연스럽게 이어질 수 있습니다.
UI에 즉시 보여주는 것만으로는 시스템의 대화 연속성이 유지되지 않습니다. 두 경로가 동시에 작동함으로써, 사용자는 빠른 응답을 경험하면서도 시스템은 맥락을 잃지 않습니다.
마치며: 복잡한 에이전트 시스템, 일관된 사용자 인터페이스
이처럼 사용자와 에이전트를 잇는 각 계층의 Bridge가 메시지 전달, 컨텍스트 보강, 결과 표현을 각자의 역할에 맞게 정확하게 처리하도록 설계되어 있습니다.
Interface Bridge가 어떤 입력이든 동일한 경로로 받아들이고, User Bridge와 Agent Bridge가 메시지를 올바른 에이전트에게 정확하게 전달합니다. HITL Gate가 사람의 판단이 필요한 순간을 시스템이 스스로 판단하고, Dual-Path가 에이전트의 결과를 사용자에게 즉시 전달하면서 맥락은 유지합니다.
에이전트는 추론과 실행에만 집중합니다. 연결, 전달, 표현은 Bridge Layer가 담당합니다. 각 계층이 자신의 역할에만 집중하기 때문에, 내부가 아무리 복잡해도 사용자는 하나의 대화창만 경험합니다.
이것이 여러 AI가 동시에 일해도 하나처럼 보이는 이유입니다.
in solving your problems with Enhans!
We'll contact you shortly!