에이전트 UI는 런타임 인프라입니다 | Focused Labs

에이전트 제품의 스피너(spinner)는 진실을 제대로 전달하지 못합니다.

에이전트 UX에는 흔한 패턴이 하나 있습니다. 사용자가 버튼을 클릭하면 몇 초 후 페이지 중앙에 스피너(spinner)가 나타나고 제품이 잠겨버리는 현상입니다. 사용자는 어떤 도구(tool)가 실행 중인지, 시스템에 어떤 변화가 일어나고 있는지, 어떤 서브 에이전트(subagents)나 에이전트(agents)가 관여하고 있는지 전혀 알 수 없습니다. 나중에 팀원들이 무슨 일이 일어났는지 파악하기 위해 긴 트랜스크립트(transcript)를 다시 읽어볼 수는 있습니다. 아무것도 없는 것보다는 낫지만, 실제 마감 기한을 지키며 업무를 수행하는 인간에게는 궁극적으로 무용지물입니다.

토큰 스트리밍(Token streaming)은 모델 호출(model-call) UX 문제를 해결하며, 모델이 답변을 작성함에 따라 답변이 더 생동감 있게 느껴지도록 만듭니다. 하지만 에이전트 제품에는 더 넓은 범위의 문제가 있습니다. 에이전트가 출력을 생성하기 위한 작업은 도구(tools), 서브 에이전트(subagents), 워크플로우(workflow) 내의 체크포인트(checkpoints), 상태 패치(patches of state), 승인 게이트(approval gates), 백그라운드 작업(background jobs), 재연결 가능한 세션(reconnectable sessions), 그리고 사람이 에이전트 작업의 결과를 확인하기 위해 응시하고 있는 다양한 애플리케이션에 걸쳐 발생합니다.

이 문제는 LangChain이 [

지원 에이전트(support agent)가 계정 정보를 조회하고, SSO 설정을 확인하며, 티켓을 생성하고, 플랜 변경 승인을 요청하고, Salesforce에 노트를 추가한 뒤, 결제 API(billing API)가 정보를 반환하기를 기다린다고 가정해 봅시다. 그동안 에이전트가 생성하는 텍스트 출력은 해당 요청을 처리하기 위해 제품(product)이 수행한 작업의 아주 작은 부분에 불과합니다. 중요한 것은 해당 요청이 제품을 통해 거치는 전체 경로입니다. 즉, 결제 호출, 승인 카드, 변경된 계정 정보, 티켓 ID, 그리고 마지막으로 에이전트의 질문에 대한 응답까지의 과정입니다. 빈 텍스트 입력창과 토큰이 조금씩 흘러나오는 스피너(spinner)는 이러한 경험을 제공하기에 형편없는 UI입니다.

이 문제는 이미 지연 시간(latency)에 취약한 채팅 에이전트에서 명확히 드러나고 있습니다. 이러한 에이전트들은 요청을 한 번에 하나씩 처리하는 싱글 스레드(single-threaded) 봇으로 구현되어 있습니다. 최종 응답이 정확하더라도, 싱글 스레드 지원 봇은 아키텍처 설계상의 결함(architecture smell)이며, 이벤트 스트림(event streams)은 동일한 문제의 UI 버전일 뿐입니다. 즉, 프론트엔드는 에이전트가 이벤트를 병렬로 처리함에 따라 제품의 표면(product surface)이 실시간으로 진화하는 모습을 보아야 하며, 사후에 단일 로그 항목으로 나타나는 것을 보아서는 안 됩니다.

LangChain의 이벤트 스트리밍(event streaming) 문서를 읽어보면 이 점이 더 명확해지는데, 해당 문서에서는 새로운 애플리케이션 및 프론트엔드 작업을 위한 API 경계(boundary)를 개괄하고 있습니다. LangChain은 stream_events(..., version="v3") 사용을 권장하며, 이는 메시지, 도구 호출(tool calls), 상태 값(state values), 서브그래프(subgraphs), 커스텀 프로젝션(custom projections), 그리고 최종 출력에 대한 타입화된 프로젝션(typed projections)을 반환합니다. 그러면 애플리케이션은 실행의 개별 청크(chunks)를 파싱하여 서로 다른 텍스트 블록에 따라 분기하는 대신, 전달받은 프로젝션을 렌더링하여 사용자에게 표시합니다.

stream = agent.stream_events(
    {"messages": [{"role": "user", "content": "Check the renewal risk for Acme"}]},
...

이를 통해 프론트엔드(front end)는 텍스트 스트리밍을 전사(transcript)로 보내는 것과는 다른 무언가를 약속할 수 있습니다. 전사는 실시간으로 텍스트를 통해 업데이트될 수 있습니다. 도구 호출(Tool calls)은 진행 상태 및 실패 상태를 포함하는 카드 형태로 노출될 수 있습니다. 애플리케이션의 최신 상태를 실시간으로 렌더링할 수 있습니다. 에러는 재시도 컨트롤과 함께 노출될 수 있습니다. 최종 출력은 루프를 완성할 수 있습니다.

이벤트 스트림에는 명사가 필요합니다.

유용한 에이전트 스트림(agent stream)은 에이전트의 생명주기(lifecycle), 텍스트 메시지, 도구 호출(tool calls), 상태(state), 활동(activity), 결정 뒤에 숨겨진 추론(reasoning), 커스텀 이벤트(custom events), 그리고 에러에 대한 정보를 포함해야 합니다. AG-UI, 즉 에이전트-사용자 상호작용 프로토콜(Agent-User Interaction Protocol)은 이러한 어휘를 구현한 현재 가장 깔끔한 사례입니다. 해당 문서에서는 이벤트가 에이전트와 프론트엔드 간의 근본적인 통신 단위가 되는 이벤트 기반 아키텍처(event-based architecture)를 설명하며, 여기에는 생명주기 이벤트, 텍스트 메시지 이벤트, 도구 호출 이벤트, 상태 관리 이벤트, 활동 이벤트, 추론 이벤트, 특수 이벤트, 그리고 아직 구축 중인 초안 확장(draft extensions)이 포함됩니다.

다시 강조하지만, 이벤트의 생명주기(lifecycle) 부분은 처음 생각하는 것보다 더 중요합니다. 실행(run)이 시작될 수 있습니다. 단계(steps)가 시작되고 종료됩니다. 텍스트 청크(text chunks)가 메시지 ID에 부착됩니다. 도구 호출(tool calls)이 시작되거나, 완료되거나, 에러가 발생하거나, 사라집니다. 상태(state)는 사용자에게 보여지는 세계 모델(model of the world)에 대한 델타(deltas) 값으로 반영됩니다. 실행은 종료되거나, 중단되거나, 실패할 수 있습니다. 이를 통해 UI는 연기 신호(smoke signals)를 지켜보는 채팅창 대신, 소프트웨어처럼 동작할 수 있습니다.

AG-UI는 우연히 등장한 것이 아닙니다. CopilotKit은 에이전트 실행 중에 생성되는 메시지, 도구 호출 (tool calls), 상태 패치 (state patches), 그리고 라이프사이클 이벤트 (lifecycle events)를 전달하기 위해 표준 HTTP 또는 선택적인 바이너리 채널을 통해 단일 JSON 이벤트 시퀀스를 스트리밍하는 프로토콜로서 이를 도입했습니다. 이 프로토콜은 원격 에이전트 호스팅을 위해 Microsoft의 Agent Framework에서도 지원됩니다. 해당 프레임워크는 SSE를 통한 실시간 스트리밍, 세션 및 상태 관리 (session and state management), 인간 참여형 승인 (human-in-the-loop approvals), 공유 상태 (shared state), 예측적 상태 업데이트 (predictive state updates), 그리고 도구 기반의 생성형 UI (tool-based generative UI)를 지원합니다.

여기에는 기업 도입의 신호도 포함되어 있습니다. 에이전트 프레임워크는 데모 애플리케이션을 구축하는 데 사용하는 React 위젯이 아니라, 제작자가 애플리케이션 개발자에게 노출하는 이벤트 계약 (event contract)에 의해 평가받고 있습니다.

생성형 UI는 런타임 경계의 일부로서 프론트엔드를 만듭니다.

“생성형 UI (generative UI)”라는 용어는 모델이 눈앞에서 컴포넌트를 그려내고 있다고 믿는 사람들 때문에 오용되고 있습니다. 하지만 유용한 부분은 지루한 부분에 있습니다. 프론트엔드와 백엔드에서 작업이 어떻게 일어나는가? 승인은 어떻게 이루어지는가? 상태를 쓰는 작업은 어떻게 작동하는가? 그리고 여기서 무엇을 재시도할 수 있는가? 하는 점들입니다.

AG-UI의 도구 모델은 프론트엔드가 클라이언트 측 도구 (client-side tools)를 정의하고, 에이전트가 구조화된 라이프사이클을 통해 이를 요청할 수 있는 방법을 제공합니다. AG-UI 도구 문서는 도구 스키마 (tool schemas), 도구 호출 (tool calls), 그리고 에이전트가 상호작용에 대해 추론하는 동안 애플리케이션이 민감한 작업을 제품 제어 하에 유지할 수 있도록 해주는 프론트엔드 정의 도구에 대해 설명합니다.

그 경계는 매우 중요합니다. "회의 시간 제안" 기능을 노출하는 캘린더 컴포넌트(Calendar component)가 에이전트에게 캘린더에 대한 쓰기 권한(Write access)을 부여하는 것은 아닙니다. "플랜 변경 준비"를 노출하는 플랜 결제 페이지(Billing page)는 커밋(Commit) 전에 반드시 인간의 승인 이벤트(Human approval event)를 필요로 합니다. 특정 기간 내 계정의 행과 열로 구성된 데이터 테이블(Data table)은 기초 데이터를 변경하는 백엔드 변이(Backend mutation) 대신, "이 세그먼트 필터링"을 UI 작업(UI operation)으로 노출할 수 있습니다. 이를 통해 에이전트가 해당 작업을 요청하면 제품이 이를 허용할지 결정하고, 그 결과로 발생하는 이벤트들을 이벤트 스트림(Stream of events)에 기록할 수 있습니다.

런타임 컨텍스트(Run context)가 파악되면, 화면은 상태(State), 권한(Permissions), 중간 산출물(Intermediate artifacts), 그리고 상호작용 이력(Interaction history)을 반영할 수 있습니다. 이것이 바로 컨텍스트가 정적 디자인을 대체하기 시작하는 지점입니다. UI는 한 번 그려진 뒤 그대로 방치될 수 없습니다. 실행(Run)의 각 단계와 그 단계들로부터 생성되는 이벤트에 반응하여 변화해야 합니다.

UI가 이제 런타임 경계(Runtime boundary)의 일부가 되었기 때문에 프로토콜(Protocols)이 중요해집니다.

서브에이전트(Subagents)는 트랜스크립트 사고(Transcript thinking)를 붕괴시킵니다.

제품 내에 서브에이전트(Subagents)가 존재하면 트랜스크립트 모델(Transcript model)은 더욱 복잡해집니다.

관리자(Supervisor)는 문제를 조사하고, 정책을 찾아보고, 계정을 분석한 다음, 일련의 복구 조치(Remediations)를 계획하는 작업을 정의할 수 있습니다. LangGraph를 이용한 멀티 에이전트 오케스트레이션 (multi-agent orchestration with LangGraph)에 대한 트레이드오프(Tradeoffs)는 최근의 아키텍처 문서에 설명되어 있습니다. 이러한 작업의 UI가 직면한 문제는 채팅 트랜스크립트(Chat transcript)의 문제와 유사합니다. 작업이 서브에이전트(Subagents)에게 위임될 때, 작업은 하나의 단일 트랜스크립트로 평탄화(Flattened)될 수 있지만, 이러한 평탄화는 작업의 계층 구조, 현재 차단된 작업, 완료된 작업, 그리고 어떤 자식 실행(Child run)에 의해 어떤 결과가 생성되었는지에 대한 중요한 정보를 가립니다.

Deep Agents는 각 서브에이전트의 스트림(Stream)을 별도의 일급 프로젝션(First-class projection)으로 취급함으로써 서브에이전트에게 작업이 분할될 때 발생하는 UI 문제를 해결할 수 있습니다. 문서에 따르면 stream.subagents는 위임된 작업당 하나의 스트림 핸들(Stream handle)을 노출하며, 여기에는 범위가 지정된 메시지(Scoped messages), 도구 호출(Tool calls), 값(Values), 중첩된 서브에이전트(Nested subagents), 출력(Output), 경로(Path), 그리고 라이프사이클 상태(Lifecycle status)가 포함됩니다. 이는 UI가 관리자 에이전트(Supervising agent) 작업의 효과를 보여준 다음, 다양한 자식 에이전트들이 수행한 작업을 별도의 카드(Cards)로 보여줄 수 있으며, 다른 모든 서브에이전트의 스트림을 구독하지 않고도 특정 서브에이전트의 스트림으로 드릴 다운(Drill down)할 수 있음을 의미합니다.

재연결(Reconnects)과 트레이스(Traces)는 동일한 설계 논의에 포함되어야 합니다.

에이전트 실행(Agent runs)은 브라우저 탭이 닫힌 후에도 계속되고, 불안정한 API 연결 문제로 인해 중단되기도 하며, 특정 시점에 사람이 수동으로 개입하거나, 제품 업데이트가 배포된 후에도 계속될 수 있습니다. 또한 쓰기(Write) 작업을 완료하는 과정에서 부분적으로 실패할 수도 있습니다. 따라서 특정 에이전트 실행에 대응하는 UI 이벤트 스트림 역시 실행 자체가 재개 가능하다는 사실에 상응하여, 반드시 재개 가능(Resumable)해야 합니다.

이 지점에서 이벤트 계약(event contract)은 프로덕션 인프라(production infrastructure)로 변모합니다. 런타임 작업(runtime work)을 추적하기 위해서는 계약이 실행 ID(run IDs), 스레드 ID(thread IDs), 부모 실행 ID(parent run IDs), 그리고 단계 이름(step names)을 매핑할 수 있어야 합니다. 프론트엔드(frontend)가 부수 효과(side effects)를 중복해서 발생시키지 않도록 순서가 지정된 값의 차이(ordered value deltas), 도구 호출(tool calls), 출력(outputs), 그리고 결과(results)를 추적해야 합니다. UI가 사용자에게 보이는 액션(action)을 생성할 때, 이는 “billing API failed” 오류를 보여주는 도구 카드(tool card)에 나타났던 것과 동일한 식별자를 사용하여 해당 실행(run)으로 역추적될 수 있어야 합니다.

Honeycomb의 에이전트 작업 또한 같은 방향을 가리킵니다. Honeycomb의 Agent Timeline 제품은 에이전트 디버깅을 비행 기록 장치(flight recorder)로 프레임화합니다. UI에서 활성 작업(active work)을 보여주는 데 사용된 것과 동일한 정보를 해당 에이전트가 포함된 인시던트(incident) 검토 시에도 표시할 수 있습니다. 만약 UI가 단계 제목(step title)과 “billing API failed” 도구 카드를 보여주었다면, 에이전트가 수행한 작업을 정확하게 제시하기 위해 이후의 단계들(subsequent steps)에 대한 트레이스(trace)에서도 동일한 실행(run), 단계(step), 그리고 도구 식별자(tool identifiers)가 필요합니다.

통합 에이전트(Integrated agents)는 이 부분의 기준을 높입니다. 통합 에이전트 관련 글에서 강조했듯이, 에이전트는 기존의 엔터프라이즈 시스템 및 워크플로우(workflows) 내에서 작동할 때 가치를 전달합니다. UI를 통해 작업을 처리하는 것만으로는 충분하지 않습니다. 도구의 이벤트 스트림(event stream)은 제품, 플랫폼, 그리고 관측성 시스템(observability system)과 통합되어야 합니다. 이들은 동일한 이벤트 계약(event contract)을 필요로 합니다.

AI 에이전트 프레임워크에 요구해야 할 사항.

구매 체크리스트가 점점 더 날카로워지고 있습니다.

프레임워크가 메시지, 도구 호출(tool calls), 상태 패치(state patches), 하위 에이전트 진행 상황(subagent progress), 승인(approvals), 오류(errors), 커스텀 도메인 이벤트(custom domain events), 그리고 최종 출력(final output)을 타입이 지정된 투영(typed projections)으로서 스트리밍할 수 있는가?

에이전트가 문서화된 스키마(schema)를 통해 요청할 때, 프론트엔드 도구들이 애플리케이션 제어(application control) 하에 유지될 수 있는가?

이벤트 식별자(event identifiers)가 트레이스(traces), 로그(logs), 평가 기록(eval records), 그리고 인시던트 티켓(incident tickets)으로 깔끔하게 매핑되는가?