단일 지출 항목을 기록하는 데 걸리는 시간: 폼 45초, 대화 10초. 6개 항목 영수증: 폼 4분, 대화 20초. 이 숫자는 어느 UX 연구소의 가설이 아니다. 실제 SaaS 회계 제품에 118개의 MCP 도구를 구축하고, 동일한 작업을 폼과 Claude 대화로 각각 측정한 결과다. 차이는 예상보다 컸다—그리고 그 이유가 흥미롭다.
왜 폼이 느린가—카테고리 트리의 저주
폼이 느린 본질적 이유는 디자인이 나빠서가 아니다. 폼은 태생적으로 사용자에게 시스템의 데이터 구조를 알 것을 요구한다. "Food & Dining > Groceries"를 선택하려면 40개 이상의 카테고리 트리를 직접 탐색해야 한다. 반면 대화에서는 "groceries"라고 입력하면 AI가 list-categories 도구를 호출해 depth 2의 최적 매칭 노드를 자동으로 찾아준다. 사용자는 트리 구조를 몰라도 된다.
이것이 AI 네이티브 UI의 첫 번째 원칙이다: 사용자가 시스템 구조를 내면화하는 부담을 AI가 대신 진다. 폼은 그 부담을 인터페이스 설계로 완화하려 했지만, AI는 구조 자체를 숨겨버린다.
MCP 도구는 API 래퍼가 아니다
여기서 중요한 설계 경고가 등장한다. dev.to의 MCP 서버 설계 원칙 아티클이 정확히 지적하듯, "REST 엔드포인트 하나당 도구 하나"는 최악의 출발점이다. GET /transactions, POST /transactions, GET /categories를 그대로 래핑하면 모델은 단순한 작업에도 3~4번의 도구 호출을 연쇄해야 한다. 이는 레이턴시, 토큰 비용, 그리고 중간 결과를 오해할 확률을 동시에 높인다.
올바른 설계 기준은 엔드포인트가 아니라 인텐트(intent)다. 회계 예시에서 create-transactions는 최대 50개의 트랜잭션을 단일 배치로 처리한다. 6개 영수증 항목을 폼으로 처리하면 6번의 반복 작업이지만, 대화에서는 한 문장이 하나의 도구 호출로 변환된다. 4분 대 20초, 12배 차이의 본질은 UI 레이아웃이 아니라 연산 단위의 설계에 있다.
도구 설명(description)도 단순한 문서가 아니다. z.string().describe("Format: resp_XXXXXXXX")처럼 파라미터 설명 한 줄이 모델의 추론 정확도를 직접 결정한다. MCP에서 description은 프롬프트 엔지니어링이다.
컨텍스트 창이 에이전트 구조를 바꾼다
이 흐름을 더 깊은 맥락에서 이해하려면 컨텍스트 창의 진화를 함께 봐야 한다. DeepSeek-V4의 100만 토큰 컨텍스트와 Google의 에이전틱 시대용 TPU 발표는 단순한 스펙 경쟁이 아니다. dev.to의 밀리언 토큰 컨텍스트 분석이 지적하듯, 컨텍스트는 더 이상 최적화 대상의 제약이 아니라 에이전트가 실제로 살고 일하는 연산 공간으로 바뀌고 있다.
기존 에이전트 아키텍처가 벡터 DB, 청킹 전략, 리트리벌 파이프라인에 복잡성 예산을 쏟아부은 이유는 하나다—컨텍스트가 부족했기 때문이다. 컨텍스트가 사실상 무제한에 가까워지면 이 복잡성 예산은 "어떻게 기억할 것인가"에서 "무엇을 우선할 것인가"로 재배분된다. 회계 에이전트가 이달 지출과 지난달 지출을 동시에 참조해 10초 만에 비교 요약을 내놓을 수 있는 것도 이 흐름의 실용적 구현이다.
어떤 작업이 폼에서 더 나은가
그렇다고 "폼은 죽었다"는 결론은 틀렸다—적어도 지금은. 동일한 회계 제품 실험에서 폼이 우위를 유지하는 영역도 존재했다. 복잡한 날짜 범위 필터, 다중 조건 보고서 설정, 혹은 사용자가 시스템 구조를 정확히 알고 직접 제어하고 싶은 파워 유저 시나리오가 대표적이다.
핵심은 이분법이 아니라 작업의 성격에 따른 인터페이스 선택이다. 트리 탐색이 필요한 분류 작업, 반복 배치 입력, 크로스 컨텍스트 조회("이번 달 vs 저번 달")는 대화형이 압도적으로 유리하다. 반면 정확한 필드 제어가 필요하거나 사용자가 이미 구조를 알고 있는 작업은 여전히 폼이 효율적이다.
프론트엔드 개발자에게 주는 시사점
이 패러다임 전환이 프론트엔드 개발자에게 요구하는 역할 변화는 명확하다. 더 이상 "어떤 컴포넌트로 이 입력을 표현할까"가 첫 번째 질문이 아니다. "이 작업을 사용자가 자연어로 표현할 수 있는가, 그리고 AI가 그 의도를 도구 호출로 정확히 변환할 수 있는가"가 설계의 출발점이다.
MCP 도구 설계는 새로운 UI 컴포넌트 설계다. 도구의 이름, description, 파라미터 타입, 반환 데이터 구조—이 모든 것이 사용자 경험을 결정한다. create-recurring-transaction 도구의 description에 "Does NOT generate a transaction immediately"를 명시한 것은 마이크로카피 설계와 동일한 UX 판단이다. 모델이 사용자에게 정확한 기대치를 전달하게 만드는 것.
전망: AI 네이티브 UI의 설계 기준이 달라진다
앞으로 2~3년, 프론트엔드 설계의 경쟁 우위는 픽셀 퍼펙트 컴포넌트보다 인텐트 정렬된 MCP 도구 아키텍처에서 갈릴 가능성이 높다. 밀리언 토큰 컨텍스트가 에이전트를 상태 유지(stateful) 기본값으로 만들면, UI는 점점 더 얇아지고 에이전트 레이어가 두꺼워진다.
폼이 완전히 사라지지는 않을 것이다—하지만 폼이 기본 UI이고 AI가 보조 기능이던 시대는 끝나가고 있다. 이제는 AI 대화가 기본 경로이고, 폼은 파워 유저를 위한 정밀 제어 도구가 되는 역전이 시작됐다. 그 역전을 설계로 이끄는 것이 다음 세대 프론트엔드 개발자의 핵심 역량이다.