응답하는 AI와 행동하는 AI는 다른 물건이다
Cursor 3, v0, Claude Managed Agents, GitHub Copilot Agent Mode. 지난 12개월 사이 에이전트 제품들이 일제히 GA를 선언했다. 문제는 이 제품 대부분이 여전히 채팅 스레드 UI 위에서 작동한다는 점이다. Q&A에 최적화된 인터페이스를 그대로 가져와, 이제는 실제 행동을 수행하는 AI에 덮어씌운 것이다.
dev.to에 게재된 Fuselab의 디자이너 Victor의 분석은 이 문제를 정확히 짚는다: "Chatbots respond. Agents act." 챗봇의 출력은 텍스트다. 에이전트의 출력은 세계의 상태 변화다—전송된 이메일, 실행된 CI 파이프라인, 프로덕션에 반영된 파일 변경. 사용자가 스트리밍 응답을 읽다가 마음에 들지 않으면 스크롤을 내리면 그만이지만, 에이전트가 이미 실행한 배포는 스크롤로 되돌릴 수 없다.
채팅 UX가 에이전트에서 실패하는 세 지점
이 비대칭성 하나가 에이전트 UX 설계 문제의 거의 전부를 파생시킨다. 구체적으로 세 가지 설계 문제가 드러난다.
첫째, Pre-action preview(사전 행동 미리보기). 되돌릴 수 없는 작업 앞에서는 에이전트가 실행 전에 계획을 보여주고, 사용자가 확인 또는 수정한 뒤 실행해야 한다. Cursor의 diff 적용 흐름이 현재 시장에서 가장 깔끔한 구현 사례다. 변경 내역이 표시되고, 사용자가 수락 혹은 거부하면 파일이 바뀐다. Vercel의 'claim deployments'도 같은 패턴을 플랫폼 레벨에서 공식화한 것이다. 핵심은 마찰을 없애는 것이 아니라, 마찰을 수백 밀리초 수준으로 압축하는 것이다. 승인 게이트를 제거한 팀은 마법 같은 경험이 아니라 첫 번째 예상치 못한 동작이 발생하는 순간 플러그가 뽑히는 제품을 출시하게 된다.
둘째, Multi-step plan editing(다단계 계획 편집). 에이전트는 하나의 작업을 완료하기 위해 보통 세 번 이상의 행동이 필요하다. 이 계획이 채팅 메시지 스트림 안에 묻혀 있으면 사용자는 스크롤을 올려가며 에이전트의 의도를 재구성해야 한다. 대부분은 그냥 승인 버튼을 누른다—읽지도 않고. Devin과 Manus가, 그리고 Cursor의 Plan Mode가 보여주는 해법은 계획을 채팅과 분리된 독립적이고 편집 가능한 구조화 객체로 렌더링하는 것이다. 계획이 눈에 보이는 체크리스트가 되는 순간 '고무도장 승인'이 '실제 검토'로 바뀐다.
셋째, 장시간 실행 작업의 상태 관리. 챗봇은 몇 초 안에 응답을 마친다. 에이전트는 몇 시간씩 돌아갈 수 있다. 사용자는 탭을 닫는다. 돌아왔을 때 결과는 어디 있는가? 대부분의 팀이 출시하는 잘못된 패턴은 결과를 채팅 스레드 안에 넣어두는 것이다. 3일 후 사용자는 어느 스레드에 있었는지조차 기억하지 못한다. Cursor 3의 Agents Window(2026년 4월)와 Claude Code의 Agent View(2026년 5월)는 이 문제에 진지하게 대응한 첫 사례다. 둘 다 '채팅 스레드 안의 결과'를 '전용 태스크 대시보드'로 옮겼다. 채팅 스레드는 대화를 위한 것이고, 태스크 서피스는 상태를 위한 것이다.
Figma 파일 포맷이 우리에게 건네는 시사점
에이전트 UX 설계 문제를 다른 각도에서 바라보게 해주는 사례가 있다. dev.to에 공개된 Figma 내부 파일 포맷 역공학 분석이다. .fig 파일은 ZIP 아카이브이고, 내부 canvas.fig는 fig-kiwi 바이너리 포맷으로 인코딩되어 있으며, 35,660개의 노드가 트리가 아닌 플랫 배열로 저장된다는 사실이 드러났다.
왜 플랫 배열인가? Figma의 와이어 포맷은 스트리밍 편집을 위해 설계되었기 때문이다. 디자이너가 만드는 모든 변경은 NodeChange 레코드로 추가된다. 저장 파일은 그 스트림의 최종 상태를 구체화한 것이다. 정렬 키는 문자열 기반 fractional indexing으로, 두 클라이언트가 충돌 없이 동시에 노드를 삽입할 수 있도록 한 CRDT 트릭이다.
이것이 에이전트 UX와 무슨 관련인가? 근본적으로 같은 설계 철학이다. Figma는 '협업 우선'으로 데이터 모델을 설계했고, 그 결과 UI가 트리처럼 보이더라도 내부는 상태 변화의 스트림으로 작동한다. 에이전트 UX도 마찬가지다—사용자 눈에 보이는 인터페이스가 채팅처럼 보이더라도, 내부에서 에이전트가 다루는 것은 텍스트 스트림이 아니라 상태 변화의 연속이다. 인터페이스의 모양이 내부 작동 방식을 반영해야 한다는 원칙을 Figma는 데이터 레이어에서, 에이전트 UX는 사용자 레이어에서 각각 구현해야 하는 문제다.
디자인-개발 협업의 새 앵글
이 두 흐름이 교차하는 지점에서 실무적으로 중요한 함의가 나온다. Figma 파일 구조를 직접 파싱할 수 있게 되면—오픈소스 파서 figma-reverse가 그 길을 열었다—디자인 결정의 히스토리를 코드와 동일한 방식으로 추적할 수 있다. 에이전트가 UI 컴포넌트를 생성하거나 수정할 때, 그 변경이 디자인 토큰과 충돌하는지를 실시간으로 검증하는 파이프라인을 만들 수 있다. 에이전트의 행동 결과를 사람이 검토하는 Pre-action preview 패턴을 디자인-개발 협업 레이어까지 확장하는 것이다.
더 실용적으로는, Figma 파일을 RAG 인덱스로 변환해 "이 버튼의 primary color는 어디서 오는가"를 에이전트가 직접 조회하게 할 수도 있다. 에이전트가 코드를 수정하기 전에 디자인 시스템 컨텍스트를 스스로 파악하게 하는 것—이것이 Pre-action preview 이전 단계에서 에이전트가 해야 할 작업이다.
우리가 지금 설계해야 할 것
2026년 최고의 에이전트 제품들이 공통적으로 선택한 방향은 인상적이다. 승인 게이트를 없애는 것이 아니라, 승인 게이트를 거의 느껴지지 않을 만큼 빠르게 만드는 것이다. 필요한 마찰을 제거하는 것보다 필요한 마찰을 수백 밀리초로 압축하는 것이 훨씬 어려운 설계 작업이다.
프론트엔드 개발자이자 UX 설계자로서 지금 우리가 직접 물어야 할 질문은 이것이다: 우리 제품에서 에이전트가 취하는 행동 중 되돌릴 수 없는 것은 무엇인가? 그 앞에 Pre-action preview가 있는가? 장시간 실행 작업의 결과가 사용자가 돌아왔을 때 찾을 수 있는 곳에 있는가? 계획이 채팅 스트림 안에 묻혀 있지 않고 편집 가능한 구조화 객체로 표시되는가?
채팅 박스는 질문하기에 적합하다. 행동하기에는 적합하지 않다. 에이전트 시대의 UX는 이 단순한 비대칭에서 시작한다.