Chat SDK AI 도구 내장 공부 정리 | 승인 게이트가 흥미로웠다
Vercel Chat SDK에 createChatTools가 생겼다. 승인 게이트와 프리셋 설계를 중심으로 정리해봤다.
Vercel changelog를 훑다가 Chat SDK에 AI SDK 도구가 내장됐다는 업데이트를 봤다. 처음엔 마이너 업데이트겠거니 생각했는데, createChatTools라는 API 설계 방식이 조금 달라 보여서 문서를 좀 더 읽어봤다.
변화의 흐름을 보면 chat/ai라는 서브경로가 새로 생겼고, 에이전트 연결 방식이 거기에 집중된 구조다. 작은 변경처럼 보이지만, 에이전트와 Chat SDK를 잇는 방식을 정리한 인상이 들었다.
1️⃣ 이게 뭐냐?
createChatTools(chat) 하나로 Chat SDK의 읽기·쓰기 동작을 AI 에이전트에 연결할 수 있다. 이 함수에 chat 인스턴스를 넘기면, 에이전트가 접근할 수 있는 도구 세트가 만들어지는 방식이다. 이전에는 두 SDK를 잇는 코드를 따로 작성해야 했을 텐데, 그 부분이 내장 툴셋으로 추상화된 것처럼 보인다.
toAiMessages와 관련 타입들은 기존 chat에서 새 chat/ai로 이동했고, 이전 경로에는 @deprecated가 붙었다. 마이그레이션 경로를 명시적으로 보여주는 방식이 깔끔하다는 인상이었다.
도구 범위를 미리 좁혀두는 프리셋도 있다. reader, messenger, moderator 세 가지로, 각각 허용하는 동작 범위가 다르다. 에이전트에게 필요한 것 이상의 권한을 주지 않겠다는 설계처럼 읽혔다.
쓰기 작업에는 requireApproval 옵션이 기본으로 붙는다. 에이전트가 데이터를 함부로 건드리지 않도록 승인을 기본으로 요구하는 방식이다. 프리셋이 허용한 도구만 초기화되는 지연 로딩도 포함돼 있다.
2️⃣ 내가 든 생각
가장 눈에 띈 건 쓰기 동작에 승인 게이트가 기본값으로 붙는 방식이었다. 에이전트가 데이터를 건드리는 건 원래 조심스러운 일인데, 그걸 API 수준에서 강제하는 방향이 흥미로웠다. 개발자가 명시적으로 승인 게이트를 “끄는” 결정을 해야 하는 구조라는 점도 그렇다.
👉🏻 프리셋이 reader·messenger·moderator 세 가지로 나뉘는 방식도 비슷한 방향처럼 보인다. 권한 수준을 역할 이름으로 직관적으로 표현했고, 애매한 권한 설정을 피하도록 유도하는 구조처럼 느껴졌다.
💡 여기서 드는 질문? 세 가지 프리셋 사이 어딘가가 필요한 경우엔 커스터마이징이 어떻게 가능할까?
디자이너 관점에서 보면, 이런 설계는 사용자 신뢰를 인터페이스가 아닌 API 수준에서 다루는 방식처럼 느껴졌다. 에이전트가 무엇을 할 수 있는지의 경계를 명확히 하는 일이 결국 UX와도 닿아있다는 생각이 들었다.
3️⃣ 앞으로 어떻게 쓸까?
공부한 내용 기준으로는, createChatTools의 도입이 에이전트 기능을 추가할 때 진입 비용을 낮춰주는 변화인 것 같다. 두 SDK를 잇는 코드를 따로 작성하는 대신 함수 하나로 해결될 수 있으니까.
아직 직접 닿아본 적은 없지만, 프리셋 구조가 에이전트의 권한 범위를 처음부터 설계하도록 유도한다는 점이 인상적이었다. 기능을 추가하기 전에 “이 에이전트가 어디까지 할 수 있어야 하는가”를 먼저 고민하게 만드는 구조랄까.
⭐️ 마지막으로, 프론트엔드를 배우는 입장에서 공부하며 느낀 점
공부 끝에 남은 건, 에이전트 설계도 결국 ‘누가 뭘 할 수 있는가’를 어떻게 나누느냐의 문제라는 한 줄이다. createChatTools의 프리셋과 승인 게이트 모두 그 선을 API로 표현한 방식처럼 보였다.