Kai 1 0
게시물 메뉴

AI 서비스를 만들다 보면 처음에는 이렇게 생각하게 됩니다.

 

“채팅창 하나 만들고 LLM API 연결하면 되는 거 아닌가?”

 

저도 처음에는 UI가 그렇게 어려운 영역이라고 생각하지 않았습니다. 그런데 실제로 에이전트 형태의 서비스를 만들려고 하면 이야기가 꽤 달라집니다.

 

사용자가 메시지를 보내고 AI가 답변하는 기본적인 구조를 넘어서면 생각보다 구현해야 할 것이 많습니다.

 

메시지 스트리밍, 생성 중 상태 표시, 대화 기록 관리, 다시 생성하기, 파일 첨부, 이미지나 코드 출력, 툴 호출 과정 표시, 에러 처리, 대화 중단과 재개 같은 기능들이 하나씩 필요해집니다.

 

특히 최근 AI 서비스는 단순한 “질문 → 답변” 구조에서 점점 벗어나고 있습니다.

 

사용자 요청

→ AI가 작업 판단

→ 필요한 Tool 실행

→ 중간 상태 전달

→ 결과 생성

→ 이미지·파일·코드 등의 Artifact 출력

 

이런 구조가 되면서 백엔드의 Agent 설계만큼 프론트엔드에서 그 과정을 어떻게 보여줄지도 중요해지고 있습니다.

 

이런 부분을 알아보다가 찾은 프로젝트가 assistant-ui입니다.

 

assistant-ui는 React 기반으로 AI 채팅 인터페이스를 만들 수 있도록 도와주는 오픈소스 UI 도구입니다.

 

단순히 “ChatGPT처럼 생긴 화면”을 복사해서 사용하는 템플릿이라기보다는, AI 서비스에 필요한 채팅 경험을 직접 구성할 수 있도록 여러 기능과 컴포넌트를 제공하는 쪽에 가깝습니다.

 

assistant-ui가 필요한 이유

 

일반적인 웹 채팅은 비교적 구조가 단순합니다.

 

사용자가 메시지를 보내면 서버로 전달하고, 상대방의 메시지가 도착하면 화면에 추가하면 됩니다.

 

하지만 LLM 기반 채팅은 조금 다릅니다.

 

AI가 답변을 한 번에 반환하지 않고 스트리밍으로 생성할 수도 있고, 답변 도중 외부 도구를 호출할 수도 있습니다.

 

사용자가 생성을 중단하거나 다시 요청할 수도 있고, 하나의 응답 안에 일반 텍스트뿐만 아니라 코드나 이미지, 파일, 여러 형태의 결과가 포함될 수도 있습니다.

 

결국 AI 채팅 UI를 제대로 만들려면 단순한 메시지 목록보다 훨씬 많은 상태를 관리해야 합니다.

 

이런 기능을 서비스마다 처음부터 다시 만드는 것은 꽤 많은 시간이 들어갑니다.

 

assistant-ui는 이런 반복적인 부분을 줄이고 실제 서비스 기능 개발에 더 집중할 수 있게 해주는 도구라고 볼 수 있습니다.

 

단순한 챗봇보다 에이전트 UI에 더 관심이 갑니다

 

제가 assistant-ui를 보면서 관심이 갔던 부분도 이쪽입니다.

 

앞으로 AI 서비스의 화면은 단순히 사람과 AI가 대화하는 채팅창에 머물지는 않을 것 같습니다.

 

예를 들어 사용자가

 

“이 자료를 분석해서 보고서를 만들어줘.”

 

라고 요청했다고 가정해 보겠습니다.

 

실제로 에이전트 내부에서는 여러 단계가 진행될 수 있습니다.

 

자료 확인

→ 웹 검색

→ 데이터 분석

→ 코드 실행

→ 이미지 생성

→ 보고서 파일 생성

 

사용자 입장에서는 몇십 초 동안 아무것도 보이지 않는 것보다 지금 어떤 작업이 진행되고 있는지를 적절하게 확인할 수 있는 편이 훨씬 좋습니다.

 

반대로 내부에서 일어나는 모든 이벤트를 그대로 보여주면 화면이 너무 복잡해질 수도 있습니다.

 

어떤 정보까지 사용자에게 보여주고, 어떤 정보는 숨길 것인가.

 

Tool 실행 결과를 채팅 안에 보여줄 것인가.

 

파일이나 이미지는 메시지 안에 넣을 것인가, 별도의 Artifact 영역으로 분리할 것인가.

 

이런 것들이 앞으로 에이전트 UI를 만들 때 꽤 중요한 설계 포인트가 될 것 같습니다.

 

직접 구현하는 것과 비교하면?

 

물론 assistant-ui가 반드시 필요한 것은 아닙니다.

 

React나 Next.js를 사용하고 있다면 채팅 UI 자체는 직접 구현할 수도 있습니다.

 

서비스가 단순한 질문과 답변만 제공한다면 직접 만드는 것이 오히려 더 빠를 수도 있습니다.

 

하지만 기능이 늘어나기 시작하면 상황이 달라집니다.

 

처음에는 메시지 출력만 필요했던 서비스에 스트리밍이 들어가고, 이후 Tool Calling이 추가되고, 파일 업로드와 Artifact가 추가되는 식입니다.

 

여기에 모바일 대응이나 대화 기록, 재연결까지 고려하기 시작하면 UI 쪽 코드도 상당히 커질 수 있습니다.

 

그래서 저는 이런 라이브러리를 볼 때 “코드를 얼마나 줄여주느냐”보다 “나중에 기능이 커졌을 때 구조를 계속 가져갈 수 있느냐”를 더 중요하게 보는 편입니다.

 

assistant-ui도 실제 프로젝트에 적용한다면 이 부분을 먼저 확인해볼 생각입니다.

 

제가 확인해보려는 부분

 

현재는 단순히 예제 화면만 보고 결정하기보다는 실제 프로젝트에 붙여보면서 몇 가지를 확인해보려고 합니다.

 

첫 번째는 커스터마이징입니다.

 

AI 서비스마다 필요한 화면이 다르기 때문에 기본 UI를 얼마나 자유롭게 변경할 수 있는지가 중요합니다.

 

두 번째는 Tool Calling 표현입니다.

 

에이전트가 여러 도구를 실행했을 때 진행 과정을 사용자가 이해하기 쉽게 표현할 수 있는지 보고 싶습니다.

 

세 번째는 Artifact 처리입니다.

 

이미지, 코드, 문서, 다운로드 파일처럼 일반적인 텍스트 메시지와 다른 결과를 어떤 방식으로 구성할 수 있는지도 중요합니다.

 

마지막은 재연결입니다.

 

웹이나 모바일에서는 네트워크가 잠시 끊기는 일이 흔합니다. 장시간 실행되는 에이전트라면 화면 연결이 끊겼다고 실제 작업까지 사라져서는 안 됩니다.

 

이 부분은 UI 라이브러리 하나로 해결되는 문제는 아니고 서버의 작업 상태 저장, 이벤트 구조, WebSocket이나 SSE 같은 통신 방식과 함께 설계해야 할 영역입니다.

 

AI 서비스를 만든다면 UI도 하나의 기술 영역이 되는 것 같습니다

 

LLM API를 연결하는 것 자체는 예전보다 정말 쉬워졌습니다.

 

오히려 서비스를 만들수록 어려운 것은 그 AI가 무엇을 하고 있는지 사용자가 자연스럽게 이해하도록 만드는 일인 것 같습니다.

 

답변이 생성되고 있는지,

도구를 실행하고 있는지,

작업이 실패한 것인지,

아직 처리 중인 것인지.

 

이걸 잘 보여주는 것만으로도 서비스의 느낌이 상당히 달라집니다.

 

assistant-ui가 모든 AI 서비스의 정답이라고 생각하지는 않습니다.

 

하지만 React나 Next.js로 AI 채팅 또는 에이전트 서비스를 만들고 있다면 처음부터 채팅 인터페이스를 전부 직접 구현하기 전에 한번 살펴볼 만한 프로젝트인 것 같습니다.

 

저도 실제 서비스에 적용할 수 있을지 조금 더 깊게 테스트해보려고 합니다.

 

직접 사용해보신 크루분이 있다면 장점뿐만 아니라 실제 적용하면서 불편했던 점도 공유해주시면 좋겠습니다.

 

assistant-ui

https://www.assistant-ui.com/

 

Screenshot_20260826_184329_Chrome.jpg