엔터프라이즈 AI 에이전트가 서버를 벗어나고 있습니다

엔터프라이즈 AI 에이전트들이 서버의 경계를 벗어나고 있습니다.

이 경계는 에이전트가 브라우저 탭, 데스크톱 애플리케이션, 그리드의 한 행, 로컬에 저장된 초안, 클립보드, 기기 권한, 승인 흐름 및 기타 복잡한 요소들 내에서 사람을 대신하여 행동하기 시작하기 전까지는 기만적일 정도로 작아 보입니다. 그 사람의 작업이 항상 서버 측 기록(server-side record)으로 변환되는 것은 아니기 때문에, 서버 전용 에이전트 도구만으로는 주요 통합 모델로서 불충분합니다.

백엔드 도구는 제품의 순간(product moment)을 볼 수 없습니다

서버 도구는 계정을 업데이트하거나, 지식 베이스(knowledge base)를 검색하거나, 티켓을 생성하거나, ERP 워크플로우를 호출할 수 있습니다. 이것은 제품이 의도를 저장된 사실로 변환한 후의 "사후 기록(record after)"입니다.

제품의 순간(product moment)은 그보다 더 일찍 찾아옵니다.

사용자가 워크플로우에서 제안된 작업 세트 중 세 개의 불렛 포인트를 선택합니다. 영업 엔지니어가 제품 세트의 가격을 편집하며 각 할인율에 대해 저장되지 않은 변경 사항을 만들고 있습니다. 지원 담당자가 특정 고객 세트에 대한 사고 타임라인을 보고 있습니다. 제품 관리자가 분석을 위해 고객 코호트(cohort)를 선택했습니다. 클라이언트(client)는 커서가 어디에 있는지, 사용자가 무엇을 선택했는지, 제품 내 스크롤 위치, 사용자가 현재 있는 경로(route), 워크플로우의 현재 단계에 대한 저장되지 않은 양식 데이터, 현재 뷰포트(viewport)의 크기, 현재 브라우저 권한 상태, 그리고 사용자가 수행한 마지막 UI 동작을 알고 있습니다. 서버는 아무것도 모르거나, 일련의 레코드에 대해 오래된 객체 모델(stale object model)만을 알고 있습니다.

그 간극 때문에 LangChain의 헤드리스 도구를 위한 아키텍처(LangChain's architecture for headless tools)가 매우 중요합니다. 모델에게 도구는 이름, 설명, 매개변수 스키마(schema), 그리고 결과가 있는 또 다른 일반적인 도구일 뿐입니다. 여기서 중요한 점은 이 도구가 클라이언트(client)에서 실행된다는 것입니다.

이는 엔터프라이즈 통합의 초점을 크게 변화시킵니다. 우리가 CRM 통합이 에이전트 런타임으로 이동함에 대해 작성했듯이, 인증 (identity), 승인 (approval), 재시도 (retry), 멱등성 (idempotency), 그리고 트레이싱 (tracing)이 해당 통합이 안전한지를 결정합니다. 그리고 이번 주에 설명했듯이, 동일한 모델이 이제 브라우저로도 넘어가고 있습니다. 백엔드 런타임 (backend runtime)은 여전히 해당 백엔드 서비스를 위한 엔터프라이즈 통합을 배치할 장소입니다. 하지만 Figma에서 선택된 객체, CRM 모달의 저장되지 않은 필드, 또는 훨씬 더 간단하게는 브라우저 권한 프롬프트(permission prompt) 등이 이제 모두 에이전트의 실행 경로 (execution path)에 포함됩니다.

클라이언트 런타임 (client runtime)이 실행 표면 (execution surface)의 일부가 됩니다.

에이전트가 애플리케이션 내에만 존재하는 상태 (state)에 따라 동작해야 할 때, 클라이언트 런타임이 실행 표면의 일부가 됩니다.

프론트엔드 도구는 UI 접착제가 아니라 계약입니다

게으른 접근 방식은 사이드 채널 (side channel)을 사용하는 것입니다. 즉, 애플리케이션 상태를 직렬화 (serialize)하여 거대한 바이너리 블롭 (binary blob) 형태로 서버에 보내고, 모델이 응답을 생성하게 한 다음, 앱이 그 결과로부터 UI를 패치 (patch)하도록 요청하는 방식입니다. 물론, 처음에는 잘 작동합니다. 하지만 직렬화된 데이터의 형태가 코드 작성자조차 알 수 없는 방식으로 변경되고, 모델이 오래된 컨텍스트 (stale context)를 바탕으로 작동하기 시작하며, 현재의 UI가 사용자의 동작 때문인지, 도구 실행 때문인지, 아니면 앱 팀이 모델을 따르는 동안 모델이 맹목적인 추측을 한 것인지 아무도 알 수 없게 됩니다.

프론트엔드 도구(Frontend tools)는 계약을 명시적으로 만듭니다. AG-UI는 도구를 이름, 설명, 그리고 파라미터를 위한 JSON Schema와 함께 런타임(runtime) 시 에이전트에게 전달되는 프론트엔드 정의 함수로 설명합니다. 프론트엔드는 인자 검증(argument validation), 호출 완료 후 도구 실행(invocation), 그리고 도구 결과의 대화 기록(conversation history) 삽입을 구현합니다. 간단합니다.

중요한 부분은 에이전트에게 전달되는 기능(capabilities)에 대해 프론트엔드가 갖는 제어권입니다. 각 도구에 대해, 프론트엔드는 사용자 권한, 애플리케이션 컨텍스트(context), 그리고 상태(state)를 기반으로 해당 도구를 런타임에 추가할지 또는 제거할지를 결정할 수 있습니다 (AG-UI 도구).

예를 들어, 견적 편집기(quote editor)는 견적 대상 레코드가 편집 가능하고, 조항이 승인된 라이브러리에서 선택되었으며, 사용자가 견적을 변경할 권한이 있는 경우에만 insertApprovedClause를 허용하도록 결정할 수 있습니다. 반면, 고객 지원 콘솔(support console)은 draftCustomerReply는 자유롭게 허용하되, sendCustomerReply는 승인을 요구할 수 있습니다. 디자인 도구는 승인 없이 summarizeSelectedFrame을 허용하지만, replaceSelectedFrameCopy는 승인을 요구할 수 있습니다.

클라이언트 측 도구 호출(client-side tool call)은 검증, 승인, 실행, 그리고 증거(evidence)를 하나의 라이프사이클(lifecycle)을 통해 수행합니다.

우리는 앞서 에이전트 UI가 런타임 인프라(runtime infrastructure)라고 주장했습니다. 왜냐하면 이벤트 스트림(event streams)이 제품에 도구, 상태, 승인, 하위 에이전트(subagents), 오류, 그리고 관측성(observability)에 대한 타입이 지정된 핸들(typed handles)을 제공하기 때문입니다. 클라이언트에서 실행되는 도구는 그 주장을 덜 이론적으로 만듭니다. 제품 UI는 더 이상 단순히 에이전트를 감싸는 껍데기에 불과하지 않습니다. UI는 에이전트가 서버에서 안전하게 흉내 낼 수 없는 실행 가능한 기능(executable capabilities)을 소유합니다.

AG-UI는 예정대로 등장하는 프로토콜 계층입니다

MCP는 에이전트(Agents)를 위한 도구(Tools) 및 데이터(Data)에 대한 표준 인터페이스를 제공하며, A2A는 에이전트가 다른 에이전트와 상호작용하기 위한 표준 인터페이스를 제공합니다. AG-UI는 에이전트와 사용자 대면 애플리케이션(user-facing-application) 간의 인터페이스를 목표로 합니다. 이 영역에서는 이벤트(프로그램에 의해 트리거되거나 인간에 의해 트리거됨), UI로의 업데이트 스트리밍(streaming), 멀티모달 입력(multi-modal input, 예: 음성 및 잉크), 공유 상태(shared state), 프론트엔드 도구 호출(frontend tool calls), 그리고 인간 참여형(human-in-the-loop) 중단(interrupts)을 모두 UI에서 처리해야 합니다. 이것이 현재 AG-UI에 의해 정의된 기능의 범위입니다.

사용자 대면 애플리케이션이 런타임(runtime)의 사실 관계를 결정할 수 있는 지점에서 시스템 내에 명확한 경계가 존재합니다. 즉, 현재 누가 존재하는지, 사용자가 무엇을 선택했는지, 도구 결과에 영향을 미칠 사용자의 워크스테이션 내 로컬 변경 사항은 무엇인지, 사용자의 워크스테이션에서 실행 취소(undo)할 수 있는 것은 무엇인지, 그리고 특정 부작용(side effects)이 서버에서 발생하기 전에 사용자의 워크스테이션에서 인간의 클릭이 필요한 사항은 무엇인지 등을 결정하는 지점입니다. 도구가 제품 내의 단순 홍보용 통합(brochureware integration) 단계에서 제품 내의 실제 운영 액션(production action) 단계로 넘어가면, 에이전트 운영 인터페이스(agent-operable interface)가 곧 제품이 됩니다.

Microsoft의 에이전트 프레임워크 AG-UI 통합 또한 동일한 방향을 가리키고 있습니다. 해당 문서에는 실시간 스트리밍(real-time streaming), 세션 및 스레드 관리(session and thread management), 상태 동기화 및 공유(state synchronization and sharing), 인간 참여형(human-in-the-loop) 승인 워크플로우, 커스텀 및 생성형 UI(custom and generative UIs), 도구 실행(tool execution), 그리고 웹 및 모바일 클라이언트를 위한 도구 결과 스트리밍(tool-result streaming)이 나열되어 있습니다.

데모(Demos)의 경우, 예를 들어 패널에 "승인됨(Approved)"과 같은 텍스트를 보내고 해당 승인 텍스트가 올바른 위치에 나타나는지 확인하는 프로그램에 의존할 수 있습니다. 하지만 프로덕션급 엔터프라이즈 AI 에이전트 (Production-grade enterprise AI agents)는 요청된 클라이언트 작업, 사용자의 승인, 실행 중인 데이터, 그리고 해당 작업이 실제로 다른 곳으로 전송되었는지 여부를 모두 고려해야 합니다.

비주얼 빌더(Visual builders)가 이 경계를 소유하지는 않을 것입니다

OpenAI의 AgentKit 페이지에 따르면, Agent Builder와 Evals는 2026년 11월 30일 이후로 종료될 예정입니다 (OpenAI AgentKit 업데이트). 동일한 업데이트는 코드로 계속 유지되어야 하는 워크플로우(workflows)의 경우 Agents SDK로, 자연어 프롬프팅(natural-language prompting)의 경우 Workspace Agents로 팀들을 안내하고 있습니다. 비주얼 빌더(Visual builders)는 여전히 의도(intent)를 스케치할 수는 있습니다. 하지만 지속 가능한 에이전트 통합(Durable agent integration)은 계속해서 애플리케이션이 소유한 코드로 회귀하고 있습니다.

캔버스(Canvas)는 워크플로우를 스케치할 수 있습니다. 하지만 활성화된 브라우저 선택 사항이 여전히 도구 호출 인자(tool call arguments)와 일치하는지는 확인할 수 없습니다. 애플리케이션이 권한을 부여하지 않는 한 로컬 권한 규칙(local permission rule)을 소유할 수도 없습니다. 승인 프롬프트(approval prompt)가 곧 발생할 부수 효과(side effect)를 제대로 반영했는지도 증명할 수 없습니다. 엔터프라이즈 AI 에이전트에게 있어 지속 가능한 경계는 애플리케이션 아키텍처(application architecture)입니다. 즉, 타입이 지정된 도구(typed tools), 범위가 지정된 자격 증명(scoped credentials), 상태 동기화(state synchronization), 검토 가능한 부수 효과(reviewable side effects), 그리고 작업을 추적하는 트레이스(traces)가 그것입니다.

이것이 바로 AI 에이전트 거버넌스가 실행 경로를 따르는(AI agent governance follows the execution path) 이유입니다. LangGraph, AG-UI, 헤드리스 도구(headless tools) 및 SDK와 같은 도구를 사용하는 AI 에이전트의 거버넌스는 AI 에이전트의 제어 하에 실행되는 애플리케이션의 실행 경로(execution path)를 따릅니다. 이는 서버 경로(server path)를 따르는 것이 아니며, 따라서 서버 측 애플리케이션의 거버넌스와는 명확히 다릅니다. 이전과 마찬가지로, AI 에이전트 거버넌스를 성공시키기 위한 핵심은 다른 모든 애플리케이션과 동일합니다. 즉, 애플리케이션과 그 AI는 제품 팀(product team)에 의해 소유되어야 하며, 이 팀은 AI의 역량을 정의하고 애플리케이션에 의해 운영되는 AI의 런타임 사실(runtime facts)을 검토할 수 있어야 합니다.

클라이언트 작업은 관찰 가능해야 합니다

브라우저가 에이전트 계획의 일부를 실행하고 있을 때는 백엔드 전용 트레이스(Backend-only traces)만으로는 작동하지 않습니다. 이는 에이전트가 클라이언트 도구(client tool)에 명령을 보낼 수 있음을 의미합니다. 그러면 클라이언트 도구는 로컬 상태(local state)를 검증할 수 있습니다. 사용자는 해당 작업을 승인할 수 있습니다. 그런 다음 브라우저는 외부 API를 호출할 수 있으며, 백엔드는 해당 작업의 결과를 저장할 수 있습니다. 만약 이러한 스팬(spans)들이 연결된 트레이스(connected trace)를 형성하지 못한다면, 장애 검토(incident review)는 스크린샷과 역연대순으로 하나씩 읽어야 하는 Slack 메시지 확인 작업으로 변질됩니다.

Honeycomb 블로그는 최근 브라우저에서 OpenTelemetry를 사용하는 방법에 관한 글(Honeycomb on OpenTelemetry in the browser)을 게시했습니다. 저자가 지적했듯이, 프론트엔드 코드에 계측(instrumenting)을 수행하는 것은 매우 어렵고 복잡한 문제입니다. 코드가 예측 불가능한 환경(즉, 동시적이고 예측할 수 없는 사용자 입력 하)에서 실행되기 때문입니다. 해당 포스트는 브라우저 계측이 어떻게 후속 백엔드 요청으로 트레이스 컨텍스트(trace context)를 전파할 수 있는지 설명하며, 동일한 세션 내에서 서로 다른 사용자의 프론트엔드 코드에 의해 생성된 트레이스들을 서로 연관시키기 위한 방법으로 세션 ID(session IDs)를 사용하는 것에 대해 논의합니다.

Honeycomb의 frontend observability GA 포스트는 엔드 투 엔드(end-to-end) 사용자 흐름, 고카디널리티(high-cardinality) 데이터, 사용자 상호작용 컨텍스트(user interaction context), 커스텀 속성(custom attributes), 그리고 특정 사용자에게 영향을 미치는 동작의 디버깅을 강조합니다. 프론트엔드에 에이전트(agent)를 추가하면, 트레이스(trace)는 클라이언트에서 실행되는 모든 동작에 대해 에이전트 식별자(agent identifiers), 도구 호출 ID(tool-call IDs), 승인 결정(approval decisions), 권한 결과(permission outcomes), 상태 버전(state versions), 그리고 영수증 ID(receipt IDs)를 포함해야 합니다.

클라이언트에서 실행되는 도구의 좋은 결과값은 단순히 "ok: true" 이상이어야 합니다. 실행된 명령(command), 도구가 읽은 상태(state), 열린 권한(permission), 해당 동작을 승인한 사람, 변경된 내용, 취소 가능한 동작(actions that can be undone), 그리고 트레이스 ID(trace id)에 대한 정보가 포함되어야 합니다.

에이전트보다 먼저 클라이언트 런타임(client runtime)을 소유하라

프로덕션 체크리스트는 명확합니다.

클라이언트 도구를 코드로 정의하십시오. 이는 컴포넌트 내부에 파묻힌 콜백 스타일(callback-style) 함수가 아닌, 타입이 지정된 계약(typed contracts)을 의미합니다. 시스템 프롬프트(system prompts)의 휴리스틱(heuristics) 대신 도구의 권한 규칙(permission rules)을 사용하십시오. 클라이언트가 오래된(stale) 요청을 거부할 수 있도록 각 도구 호출에 최신 상태 버전(state version)을 포함하십시오. 정확한 부수 효과(side-effect) 설명을 포함하여 제품 워크플로우(product workflow)를 통해 승인을 라우팅하십시오. 클라이언트에서 실행되는 모든 동작에 대해 영수증(receipt)을 기록하십시오. 브라우저, 에이전트 런타임(agent runtime), 백엔드 서비스(backend service), 그리고 외부 API에 걸친 실행 경로를 추적하십시오. 로컬 또는 원격 상태를 수정하는 동작에 대해서는 실행 취소(undo) 경로를 구축하십시오. 누군가는 인터페이스를 소유해야 합니다.