챗봇 UI를 만드는 건 어렵지 않다. 입력창 하나, 응답 버블 하나면 된다. 문제는 그다음이다. 에이전트가 웹을 검색하고, 데이터베이스를 조회하고, 외부 API를 호출하기 시작하는 순간—사용자는 갑자기 낯선 질문 앞에 선다. 이 답변은 어디서 왔는가? 지금 에이전트가 무엇을 하고 있는가? 이걸 믿어도 되는가?
최근 velog에 올라온 CS 전공지식 RAG 챗봇 프론트엔드 구현기는 이 질문에 조용하지만 날카롭게 답한다. 저자는 React 없이 순수 HTML/CSS/JS로 단일 파일 챗 UI를 만들었다. 기능이 "질문 입력 → 답변 표시"뿐인 프로젝트에 프레임워크를 끌어들이는 건 오버스펙이라는 판단이었다. 그 자체로도 충분히 실용적인 결정이지만, 진짜 주목할 부분은 따로 있다. 답변 아래에 <details> 블록으로 "참고한 근거 N개"를 접었다 펼 수 있게 만든 것—저자는 이를 RAG의 핵심이라고 불렀다. "왜 이 답변이 나왔는지" 추적 가능하다는 점.
이 소스 추적 UI는 단순한 부가 기능이 아니다. 에이전트 시스템에서 신뢰를 코드로 설계하는 첫 번째 접점이다. 사용자가 LLM의 출력을 맹목적으로 수용하지 않고, 근거를 확인하고 판단할 수 있는 경로를 열어두는 것—이게 에이전트 UI 설계의 핵심 철학이어야 한다. 챕터별 파일로 분리되면 "3장_프로세스와스레드.md 근거로 답변함"처럼 구체적 출처가 드러난다고 저자가 언급한 대목이 특히 인상적이다. 출처의 粒度(granularity)가 높아질수록 사용자의 신뢰 판단도 정교해진다.
그렇다면 에이전트가 단일 문서 검색을 넘어 외부 시스템—GitHub, Slack, 데이터베이스, 결제 API—과 연결되기 시작하면 UI는 어떻게 달라져야 할까. 여기서 MCP(Model Context Protocol) 아키텍처가 UI/UX 설계 논의로 끌려들어온다. dev.to에 올라온 두 편의 글은 이를 엔지니어링 관점에서 다루지만, 프론트엔드 설계자에게는 다른 의미로 읽힌다.
MCP는 AI 애플리케이션이 외부 도구와 연결되는 방식을 표준화한 프로토콜이다. 흔히 쓰이는 비유는 "AI 도구의 USB-C"—어떤 장치를 꽂든 같은 포트로 연결된다. 에이전트는 MCP 서버를 통해 GitHub 이슈를 읽고, Postgres 쿼리를 실행하고, Slack 메시지를 보낸다. 연결 방식이 표준화되면 코드 중복이 줄고 재사용성이 높아진다는 게 핵심 주장이다.
그런데 UI 설계자 입장에서 MCP 아키텍처를 보면 전혀 다른 질문이 생긴다. 에이전트가 어떤 도구를 호출했는지, 그 결과가 어디서 왔는지를 사용자에게 얼마나 드러낼 것인가. MCP는 세 가지 프리미티브를 노출한다: Resources(읽기 전용 데이터), Tools(실제 실행 함수), Prompts(재사용 템플릿). 이 세 가지는 단순히 백엔드 설계 개념이 아니라, 사용자에게 보여줄 인터랙션 레이어의 설계도이기도 하다.
예를 들어 에이전트가 Stripe API를 호출해 환불을 처리한다고 하자. 사용자는 그 과정을 봐야 하는가, 결과만 봐야 하는가? 중간에 에이전트가 GitHub에서 관련 이슈를 읽어왔다면, RAG 챗봇의 <details> 블록처럼 그 출처를 접었다 펼 수 있게 해야 하는가? MCP 서버가 노출하는 Tool 목록이 UI에 동적으로 반영돼야 하는가? 이런 질문들이 에이전트 UI 설계의 실제 난도다.
또 하나의 구분이 중요하다. MCP와 함께 언급되는 'Agent Skills' 개념—에이전트에게 반복 절차를 가르치는 플레이북 레이어—은 UI에서 전혀 다른 방식으로 드러난다. MCP가 "지금 실시간으로 어디에 연결됐는가"의 문제라면, Skills는 "이 에이전트가 어떤 방식으로 일하는가"의 문제다. 전자는 연결 상태와 데이터 출처를 시각화하는 UI로 이어지고, 후자는 에이전트의 행동 패턴을 사용자에게 예측 가능하게 만드는 UX 설계로 이어진다. 같은 채팅창 안에서 두 레이어를 구분해서 설계하지 않으면, 사용자는 에이전트가 "왜 이렇게 행동하는지" 전혀 감을 잡지 못한다.
세 소스를 관통하는 시사점은 하나로 모인다. 에이전트 UI의 핵심 설계 질문은 '기능을 어떻게 보여줄까'가 아니라 '신뢰를 어떻게 설계할까'다. RAG 챗봇의 소스 추적 UI는 그 가장 단순한 형태였다. MCP로 연결된 멀티툴 에이전트에서는 이 요구가 훨씬 복잡해진다. 어떤 도구가 호출됐는지, 실시간 데이터인지 캐시된 데이터인지, 에이전트가 지금 어느 단계를 수행 중인지—이 정보들을 언제, 얼마나, 어떤 형태로 노출할지가 곧 에이전트 UX의 품질을 결정한다.
프로토타이핑 단계에서는 RAG 구현기처럼 <details> 하나로 시작해도 충분하다. 중요한 건 그 선택이 의도적이어야 한다는 것—지금은 단순하게 가지만, 에이전트가 연결하는 도구가 늘어날수록 신뢰 인터페이스의 설계 복잡도도 함께 올라간다는 사실을 미리 인지하고 있어야 한다. MCP 서버가 확장될수록 UI도 함께 확장 가능한 구조여야 한다. 에이전트 시대의 프론트엔드 개발자에게 필요한 건 더 나은 컴포넌트가 아니라, 더 명확한 신뢰 설계 원칙이다.