Post

Chat SDK 웹 어댑터 공부 정리 | 브라우저 챗 UI가 이렇게 연결되는구나

Vercel Chat SDK에 웹 어댑터가 추가됐다. createWebAdapter와 useChat으로 연결되는 구조를 공부하면서 정리한 노트.

Chat SDK 웹 어댑터 공부 정리 | 브라우저 챗 UI가 이렇게 연결되는구나

Vercel 블로그에서 Chat SDK에 웹 어댑터가 추가됐다는 공지를 봤다. Chat SDK는 처음 나왔을 때부터 “어댑터”를 중심으로 설계된 거였는데, 이번에 브라우저 기반 UI도 공식적으로 지원하게 된 것 같다. 인앱 어시스턴트나 고객 지원 챗봇처럼 서비스 안에서 돌아가는 챗 경험을 만들 때 어떻게 접근하면 될지 항상 막연했었는데, 딱 공부해보기 좋은 주제였다.

같은 날 Messenger 어댑터 공지도 같이 나왔길래 함께 읽어봤다. 두 공지를 나란히 보다 보니 Chat SDK가 어떤 방향으로 설계된 건지가 조금 더 잡히는 것 같았다.

1️⃣ 이게 뭐냐?

Chat SDK는 Vercel이 만든 챗 인터페이스 SDK인데, “어댑터”라는 단위로 채널을 교체할 수 있는 구조다. Messenger, Slack, 그리고 이번에 추가된 웹 브라우저까지—각 채널을 어댑터로 연결하는 방식이다.

웹 어댑터를 붙이는 방법은 이렇다. 서버에서 createWebAdapter()로 어댑터를 생성하고, onDirectMessage()로 메시지 처리 로직을 정의한다. 사용자 인증이 필요하면 getUser() 콜백을 추가하면 된다. 봇을 정의하고, 들어오는 메시지를 잡아서, 처리 결과를 스트리밍해주는 흐름이다.

클라이언트에서는 @chat-adapter/web/react에서 useChat 훅을 가져다 쓴다. 반환값은 messages, sendMessage, status—이 세 가지로 기본적인 챗 UI를 그릴 수 있는 구조다. @ai-sdk/reactuseChat과 이름이 같아서 처음엔 같은 건 줄 알았는데, 이건 Chat SDK 어댑터 방식에 맞게 미리 구성된 버전이라고 이해했다. 실제로 내부가 어떻게 다른지는 문서를 더 파봐야 할 것 같다.

💡 여기서 든 질문: 두 useChat의 차이가 정확히 뭘까? 상태 관리 방식이 같은 건지, 어댑터와 연결되는 방식 자체가 다른 건지 — 공지 수준에서는 잘 안 보였다.

2️⃣ 내가 든 생각

처음 읽었을 때 “이걸 왜 따로 만드나?” 싶었다. 기존 useChat에 서버 URL만 넘기면 되는 거 아닌가 하고. 그런데 Messenger 공지도 같이 읽다 보니, 핵심이 “봇 로직은 한 번 정의하고, 채널 연결만 어댑터로 교체한다”는 구조인 것 같다는 생각이 들었다.

👉🏻 어댑터 패턴의 의미는 봇을 플랫폼별로 따로 만들지 않아도 된다는 것—이라고 지금 단계에서는 이해하고 있다.

디자이너 입장에서는 이 구조가 흥미로웠다. 챗봇 UI를 서비스 안에 넣을 때, 기존엔 서버 설정부터 클라이언트 상태 관리, 스트리밍 처리까지 다 따로 연결해야 했는데—어댑터 방식은 그 연결 부분을 미리 묶어놓아서 UI 레이어에 집중할 수 있도록 해주는 것 같다. 적어도 공지와 문서를 읽은 기준으로는 그런 방향으로 보였다.

⭐️ 마지막으로, 프론트 공부하면서 느낀 것

공부 끝에 남은 건 “챗 UI는 결국 상태 관리 문제”라는 한 줄이다. 메시지 목록, 전송 상태, 실시간 스트리밍—이 세 가지를 훅 하나로 깔끔하게 들고 있어야 한다는 게, 생각보다 얽혀 있는 문제였다. 그걸 어댑터라는 개념으로 플랫폼마다 교체 가능하게 묶어놓은 구조가, 설계 면에서 꽤 깔끔하다는 생각이 들었다.


참고 원문: Chat SDK adds web adapter support

This post is licensed under CC BY 4.0 by the author.