당신의 AI UX는 고장 난 것이 아닙니다. 세션 레이어(Session Layer)가 문제일 뿐입니다.

Fiona Corden은 Ably의 솔루션 엔지니어(Solutions Engineer)로, AI 제품을 구축하는 엔지니어링 및 제품 팀과 직접 협력하고 있습니다. 그녀는 최근 AI UX 실패 모드(failure modes)에 관한 웨비나를 진행했으며, 허용된 시간보다 더 많은 이야기를 나누고 싶어 했습니다. 다음은 그 내용을 글로 정리한 버전입니다. 그녀가 주장한 논거, 데모에 대한 맥락, 그리고 제기된 질문들을 담았습니다. 읽는 것보다 보는 것을 선호하신다면 아래에 녹화 영상이 있습니다.

핵심 논지: AI 제품을 실망시키는 것은 모델이 아니라 사용자 경험(UX)입니다.

지난 9개월 동안 저는 다양한 산업 분야에 걸쳐 40개 이상의 기업에 있는 엔지니어링 및 제품 팀과 대화를 나누었습니다. 이들은 모두 AI 에이전트(agents), 어시스턴트(assistants), 코파일럿(copilots)을 실제 사용자들에게 대규모로 출시하고 있습니다. 이들은 서로 공통점이 거의 없음에도 불구하고 모두 동일한 문제에 직면하고 있으며, 그 근본 원인은 모델의 능력(model capability)이 아닙니다. 모델 능력은 가장 변동성이 큰 요소이기 때문입니다. 이들이 공유하는 공통점은 에이전트(agent)와 클라이언트(client) 사이의 전달 레이어(delivery layer)입니다.

요약(TL;DR): 대부분의 AI UX 실패는 모델의 실패가 아니라 전달(delivery)의 실패입니다. 해결책은 세션(session)을 연결(connection)로부터 분리하는 것입니다. 이는 전체를 다시 쓰는 것이 아니라 전송 레이어(transport-layer)를 교체하는 작업입니다.

핵심 요점

대부분의 AI UX 실패는 모델의 실패가 아니라 전달의 실패입니다. 전송 레이어(transport layer)는 세션이 끊기고, 컨텍스트(context)가 손실되며, 사용자 신뢰가 무너지는 지점입니다.
해결책은 연결(connection)을 세션(session)으로 취급하는 것을 중단하는 것입니다. 내구성이 있는 세션(durable session)은 에이전트와 클라이언트 사이에 위치하는 지속적이고 공유된 리소스여야 하므로, 연결 끊김, 기기 전환, 에이전트 충돌 상황에서도 생존할 수 있어야 합니다.
세션을 연결로부터 분리하는 것은 전체를 다시 쓰는 것이 아니라 전송 레이어(transport-layer)를 교체하는 것입니다. 즉, 에이전트 코드, 모델 통합(model integration), 프롬프트 하네스(prompt harness)는 그대로 유지됩니다.
일단 세션이 올바른 위치에 자리 잡으면, 동일한 아키텍처에서 여러 기능이 파생됩니다: 멀티 탭 및 멀티 디바이스 동기화, 양방향 에이전트 제어, 전체 컨텍스트를 포함한 인간-AI 핸드오프(human-AI handoffs), 그리고 동시적인 서브 에이전트(subagent) 조정 등이 있습니다.

사용자가 경험하고 있는 것

AI 애플리케이션의 사용자로서, 여러분은 아마도 이러한 실패 모드(failure modes) 중 일부 또는 전부를 목격했을 것입니다. AI 경험이 생소했을 때는 참을 만했던 사소한 문제들이, 이제는 매일 사용하는 제품에서 빈번하게 발생하면서 분통 터지는 일이 되고 있습니다.

세션 끊김 (Dropped sessions). 사용자(user)와 에이전트(agent) 사이의 연결이 끊어져, 사용자에게 응답이 돌아오지 않거나 심지어 자신이 입력한 프롬프트(prompt)조차 남지 않는 현상입니다. 연결 끊김은 네트워크 변경, 노트북의 절전 모드 진입, 유휴 스트리밍 연결을 종료하는 기업용 프록시(corporate proxies) 등 어디에서나 발생할 수 있습니다. 이러한 현상들은 결코 이례적인 것이 아닙니다. 만약 신뢰할 수 있는 제품을 만들고 싶다면, 이러한 일상적인 사례를 예외적인 케이스(edge case)로 취급해서는 안 됩니다.

에이전트의 침묵하는 실패 (Silent agent failure). 에이전트 측에서 무언가 잘못되었지만 사용자에게 피드백 신호(feedback signal)가 전달되지 않는 상황입니다. 사용자는 기다려야 할까요? 취소를 눌러야 할까요? 아니면 다시 시작해야 할까요? 제품이 작동하고 있는지 알 수 없는 사용자는 제품이 고장 났다고 판단할 것입니다.

핸드오프 시의 컨텍스트 상실 (Context loss at handoff). 챗봇(chatbot)이 처리할 수 있는 한계에 도달하여 대화를 상담원(human support agent)에게 넘기는 경우입니다. 이때 상담원은 아무런 문맥(context)을 가지고 있지 않기 때문에, 사용자는 모든 내용을 다시 반복해야 합니다. 사용자가 상담원에게 연결될 때쯤이면 이미 인내심이 바닥나 있는 경우가 많은 고객 지원(support) 환경에서, 이는 사용자의 신뢰를 가장 빠르게 잃는 방법 중 하나입니다.

기기 종속성 (Device lock-in). 사람들은 휴대폰에서 시작한 작업을 노트북에서 마무리하거나, 열어둔 탭이 다른 곳에서 방금 수행한 작업을 반영하기를 기대합니다. 이는 다른 모든 클라우드(cloud) 제품이 작동하는 방식입니다. AI 제품이 이와 다르게 동작한다면 이는 매우 당혹스러운 격차(jarring gap)를 만들어냅니다.

생성 중 제어 불가 (No control during generation). 일부 팀은 중단(interruption)을 처리하는 것이 너무 어렵다는 이유로 모델 생성(model generation) 중에 사용자 입력을 완전히 비활성화하기도 합니다. 사용자는 에이전트가 경로를 벗어나 잘못된 답변을 내놓기 위해 토큰(tokens)을 낭비하는 것을 지켜볼 수밖에 없으며, 이를 멈출 방법도 없습니다.

실패 뒤에 숨겨진 아키텍처 (The architecture behind the failures)

오늘날 대부분의 AI 제품에서 에이전트(Agent)와 클라이언트(Client)는 HTTP, SSE 스트리밍(SSE streaming), 또는 웹소켓(WebSockets)과 같은 직접적인 파이프(direct pipe)로 연결되어 있습니다. 이 파이프는 단일 요청(single request)에 묶여 있기 때문에, 세션(Session)은 오직 이 두 특정 엔드포인트(endpoints)가 유지되는 동안에만 존재합니다. 만약 어느 한쪽이라도 끊어지면 세션 상태(session state)는 사라집니다. 설령 세션이 유지된다 하더라도, 이러한 직접적인 파이프 아키텍처(direct pipe architecture) 하에서는 다른 클라이언트가 무슨 일이 일어나고 있는지 관찰할 수 없으며, 다른 에이전트가 세션에 참여할 수도 없습니다.

위에서 언급한 실패들은 세션이 연결(connection) 내부에 존재하고, 연결은 지속 가능하도록(durable) 설계되지 않았기 때문에 발생합니다.

지속 가능한 세션으로의 전환 (Moving to durable sessions)

지속 가능한 세션(Durable session)이란 에이전트와 클라이언트 사이에 위치하는, 영구적이고 주소 지정이 가능하며(addressable) 공유 가능한 리소스(resource)를 의미합니다. 연결은 세션 그 자체가 되는 것이 아니라 세션에 접근하는 하나의 방법이 되며, 이를 통해 세션이 유지되는 동안 여러 클라이언트와 에이전트가 자유롭게 오고 갈 수 있습니다.

세션이 그 자체로 하나의 리소스가 되면, 대화 기록(conversation transcript)보다 훨씬 더 많은 것을 담을 수 있습니다. 도구 호출 이력(Tool call history)은 물론, 프레젠스(presence), 그리고 사용자가 현재 어떤 화면에 있는지 또는 마지막으로 무엇을 클릭했는지와 같은 공유된 구조화된 상태(shared structured state)를 저장할 수 있습니다. 이 모든 정보는 연결된 모든 이에게 동기화된 상태로 유지됩니다.

지속 가능한 세션 모델을 사용하면 이전에는 별도의 개발 항목으로 구축해야 했던 기능들을 구현할 수 있습니다:

모든 연결된 클라이언트가 아직 스트리밍 중인 응답을 포함하여 최신 상태의 뷰(view)를 볼 수 있습니다.
나중에 참여한 사용자(late joiner)도 다른 모든 사람과 동일하게 완전하고 올바른 순서로 정렬된 히스토리를 받게 됩니다. 여기서 나중에 참여한 사용자는 새로운 탭, 다른 기기, 또는 개입하는 상담원(human support agent)일 수 있습니다.
서브에이전트(Subagents)가 중앙 오케스트레이터(central orchestrator)를 거치지 않고 세션으로 직접 게시(publish)할 수 있습니다.
에이전트가 연결 상태로부터 의도를 추론할 필요 없이 명시적인 취소(cancel), 리다이렉트(redirect), 또는 조종(steer) 신호를 받기 때문에 중단(Interruptions) 처리가 깔끔하게 작동합니다.
프레즌스(Presence)를 통해 더 스마트한 에이전트 동작이 가능해집니다: 사용자가 자리를 비우면 작업 우선순위를 낮추고, 작업이 완료되면 알림을 보내며, 작업 도중 오프라인이 되어야 하는 경우 사용자에게 알립니다.

데모에서 보여준 내용

데모는 개발자가 자신만의 커스텀 전송 레이어(transport layer)를 제공할 수 있는 Vercel AI SDK를 기반으로 구축되었습니다. 우리는 기본 HTTP/SSE 구현을 지속 가능한 세션(durable sessions)으로 교체했습니다. 그것이 유일한 변경 사항이었습니다: 추가적인 인프라, Redis, 또는 서버 측 버퍼링(server-side buffering) 코드도 필요하지 않았습니다.

이것이 적용됨에 따라, 두 개의 탭은 네트워크 연결이 끊겨도 스트리밍 응답에 대해 동기화된 상태를 유지했습니다. 한 탭에서 시작된 서브에이전트가 다른 탭에도 나타났으며, 그곳에서 취소할 수 있었습니다. 두 개의 동시 요청은 세션으로 직접 게시하는 별도의 서브에이전트에 의해 처리되었으며, 각 에이전트의 출력은 하나의 뒤섞인 스트림으로 엉키지 않고 대화 내에 깔끔하게 그룹화되었습니다. 중간에 참여한 상담원은 요약 과정 없이 즉시 전체 히스토리를 전달받았습니다.

코드를 직접 확인하고 싶다면 문서와 저장소에서 Vercel AI SDK 통합 및 세션 구현을 확인할 수 있습니다.

세션 질문 사항

내구성이 있는 세션(Durable sessions)은 내구성이 있는 실행(Durable execution)과 어떤 관계가 있나요? 이 둘은 서로 다른 계층(Layer)에 위치하며, 동일한 신뢰성 이야기의 서로 다른 절반을 해결합니다. Temporal 및 유사한 도구들이 차지하고 있는 카테고리인 내구성이 있는 실행(Durable execution)은 백엔드 워크플로(Backend workflows)를 충돌로부터 보호합니다. 내구성이 있는 세션(Durable sessions)은 클라이언트 측 대화(Client-side conversation)를 충돌로부터 보호합니다. 에이전트(Agent)가 백엔드에서 완전히 재개 가능(Resumable)하더라도, 연결 처리(Connection handling)가 제대로 되지 않으면 사용자에게는 여전히 망가진 경험을 제공할 수 있으므로, 이 둘은 상호 보완적입니다.

Vercel이나 Cloudflare의 프레임워크가 이미 이 기능을 제공하나요? 부분적으로 그렇습니다. 안정적인 세션 주소(Session address)가 있다는 것은 재방문 사용자나 재시작된 에이전트가 해당 세션으로 다시 찾아갈 수 있음을 의미하며, 이는 유용합니다. 하지만 이들이 아직 갖추지 못한 것은 공유된 구조화된 상태(Shared structured state), 프레젠스(Presence), 멀티 디바이스 동기화(Multi-device sync), 그리고 단일 세션 내에서의 멀티 에이전트 조정(Multi-agent coordination)입니다. 왜냐하면 해당 프레임워크들은 한 번에 하나의 워크플로(Workflow)를 중심으로 구축되었기 때문입니다.

오픈 소스 옵션이 있나요? 아키텍처에 따라 다릅니다. Vercel을 사용 중이라면 Vercel Workflow DevKit이 좋은 시작점이 될 수 있습니다. ElectricSQL은 로컬 퍼스트(Local-first) 앱을 위한 내구성이 있는 세션(Durable sessions) 개념을 가지고 있습니다. Ably는 오픈 소스가 아니지만, 의미 있는 실험을 하기에 충분한 사용량을 제공하는 무료 티어(Free tier)가 있습니다.

당신의 AI 제품에 대해 던져야 할 질문들

이러한 내용이 귀하의 제품에 적용되는지 확인하고 싶다면, 다음 세 가지 질문부터 시작해 보세요.

이미 명확하게 보이지 않는 문제가 존재하나요? 답변 품질(Answer quality)에 관한 불만 사항을 걸러낸 후, 고객 만족도(CSAT) 테마를 살펴보세요. 세션 길이(Session lengths)가 어떻게 분포되어 있는지 조사해 보세요. 짧은 세션이 간격 없이 많이 발생한다면, 이는 사람들이 무언가를 달성하기보다는 문맥(Context)을 잃고 계속 재시작하고 있음을 의미할 수 있습니다. 또한 엔지니어링 팀과 대화해 볼 가치가 있습니다. 그들은 이미 세션 레이어(Session layer)의 일부를 임시방편(Ad hoc)으로 구축하고 있을지도 모르기 때문입니다.

다음에 무엇을 구축하고 싶으신가요? 여러분의 로드맵에 있는 경험 중 멀티 디바이스 연속성 (multi-device continuity), 양방향 제어 (bidirectional control), 또는 인간-AI 핸드오프 (human-AI handoffs)를 가정하는 기능이 무엇인지 주목하십시오. 그러한 기능들은 기저에 세션 아키텍처 (session architecture) 요구사항을 가지고 있습니다.

직접 구축할 것인가, 구매할 것인가? 여러 제품에 걸쳐 일관된 동작을 유지하는 것이 중요하거나, 자체적으로 구축한 맞춤형 세션 레이어 (bespoke session layer)의 유지보수 비용이 증가하고 있다면, 전용 플랫폼을 검토해 볼 가치가 있습니다.

더 자세히 탐색하고 싶다면, docs가 시작하기에 좋은 곳입니다. 실험해보고 싶다면 무료 티어 (free tier)도 있습니다. 그리고 여러분의 구체적인 아키텍처에 대해 직접 논의하고 싶다면, 웹사이트를 통해 상담 예약 (book a call)을 할 수 있습니다.

추가 읽을거리: Why we're betting on Durable Sessions · The model is fine. The session is broken. · The Durable Sessions stack is forming

실제 운영 환경에서 이러한 실패 모드 (failure modes)를 경험한 적이 있으신가요? 현재 여러분의 세션 레이어 (session layer)가 어떤 모습인지 궁금합니다.