버튼도, 호버 상태도, 드래그 앤 드롭도 필요 없는 사용자가 온다면 어떻게 해야 할까요? 지금 가장 빠르게 성장하는 제품 사용자층은 바로 AI 에이전트입니다. 이들에게 필요한 건 시각적 인터페이스가 아니라 깔끔한 API와 구조화된 데이터입니다.

WordPress 핵심 기여자이자 제품 디자이너 Rich Tabor는 최근 블로그에서 “API is the UI(API가 새로운 UI다)”라는 관점을 제시했습니다. 인간을 위한 시각적 인터페이스보다 에이전트를 위한 API 설계가 더 중요해지고 있다는 겁니다. Google이 발표한 A2UI 프로토콜도 같은 방향을 가리킵니다. 에이전트가 필요에 따라 UI를 직접 생성하고, 인간은 그 결과를 검토하고 수정하는 구조죠.

출처: API is the UI – Rich Tabor

코드 에디터에서 이미 일어난 변화

1년 전만 해도 소프트웨어 개발은 코드 에디터 안에서 살다시피 하며 파일을 직접 만들고 수정하는 일이었습니다. 지금은 Codex, Claude Code, Telex 같은 도구들이 주요 작업 흐름을 채팅 인터페이스로 옮겨버렸습니다.

코드 에디터는 여전히 존재하지만 역할이 바뀌었습니다. 개발자는 이제 AI가 작성한 코드를 검토하고 미세 조정하며 방향을 조율하는 역할을 합니다. 에디터는 보조 도구가 됐죠.

웹사이트 빌더에서도 같은 일이 벌어지고 있습니다. 에이전트는 블록 삽입 버튼이나 드래그 앤 드롭이 필요 없습니다. 페이지가 무엇이 될 수 있는지에 대한 명확한 스키마와 그것을 작성할 수 있는 안정적인 방법만 있으면 됩니다. WordPress의 블록 모델 같은 구조가 바로 그런 역할을 하죠. 시각적 에디터는 에이전트가 만든 결과물을 인간이 검토하고 다듬는 공간으로 변합니다.

두 관객을 위한 설계

이제 제품 설계자는 두 관객을 동시에 고려해야 합니다.

1차 관객은 에이전트입니다. 이들에게 필요한 건 깔끔한 API, 예측 가능한 데이터 구조, 빠른 실행 경로입니다. 버튼의 모양이나 그림자 깊이는 중요하지 않습니다. 블록 스키마, 데이터 모델, 구조화된 콘텐츠가 핵심이죠. 이들이 생산하는 마크다운, HTML, JSON 같은 포맷은 인간과 기계 모두가 읽고 쓸 수 있습니다.

2차 관객은 인간입니다. 인간에게는 편집, 검토, 수정 기능이 필요합니다. 하지만 가장 중요한 건 신뢰입니다. 에이전트가 내 목표에 맞게 작업했는가? 내 기준을 충족했는가? 에이전트가 무엇을 했고 왜 그렇게 했는지 어떻게 전달할 것인가? 인간과 에이전트가 동기화되지 않았을 때 방향을 쉽게 수정할 수 있는가?

Google의 A2UI 프로토콜은 이 문제에 대한 하나의 해법입니다. 에이전트가 실행 가능한 코드 대신 JSON으로 UI 구조를 전달하면, 클라이언트 앱이 자체 네이티브 컴포넌트로 렌더링합니다. 예를 들어 레스토랑 예약을 위해 텍스트 기반 채팅으로 날짜와 시간을 주고받는 대신, 에이전트가 날짜 선택기와 시간 선택 드롭다운이 포함된 폼을 바로 생성하는 겁니다. 보안은 유지되면서도 훨씬 효율적이죠.

API가 중심이 되는 시대

지금까지 인간 인터페이스가 제품 그 자체였습니다. 버튼의 모양, 그림자 깊이, 계정 연결부터 구매까지의 흐름이 제품을 정의했죠. API는 통합이나 기술적 요구사항을 위한 부차적 고려사항이었습니다.

인간 인터페이스가 사라지는 건 아닙니다. 하지만 덜 중심적이 되고 있습니다. Rich Tabor는 “나는 커리어를 인터페이스 구축에 쏟아왔지만, 지금 가장 중요한 작업은 그 아래에서 일어난다”고 말합니다. API가 새로운 UI가 된 시대입니다.

참고자료:

• Introducing A2UI: An open project for agent-driven interfaces – Google Developers Blog