Chat SDK가 AI SDK tools를 품었다: 에이전트 기능은 권한 설계부터 다시 봐야 한다
AI 채팅 제품의 다음 경쟁은 “모델이 답을 잘한다”에서 “모델이 실제 업무를 어디까지 대신해도 되는가”로 이동하고 있습니다. Vercel이 2026년 5월 20일 Chat SDK에 AI SDK toolset을 포함했다고 발표한 것도 이 흐름 안에서 읽어야 합니다. 핵심은 새로운 chat/ai 서브패스와 createChatTools(chat)입니다. 채팅 상태를 읽고, 메시지를 작성하고, 앱 내부 액션과 연결하는 반복 코드를 줄여 줍니다.
하지만 여기서 중요한 결론은 “에이전트를 붙이기 쉬워졌다”가 아닙니다. 오히려 반대입니다. 붙이기 쉬워질수록 제품팀은 권한, 승인, 감사 로그, 복구 경로를 먼저 설계해야 합니다. Reddit, Hacker News, Threads 같은 개발자 커뮤니티에서 반복적으로 보이는 질문도 비슷합니다. 어떤 tool을 모델에게 열어야 하는가, 사용자가 언제 승인해야 하는가, 실패한 액션은 어떻게 설명하고 되돌릴 수 있는가. 커뮤니티 반응은 사실의 근거가 아니라, 실제 빌더들이 어디에서 불안해하는지 보여주는 신호입니다.
무슨 일이 바뀌었나
기존에는 채팅 앱에 에이전트 기능을 붙일 때 앱별로 tool 정의를 만들고, 채팅 상태 접근, 메시지 업데이트, moderation, 사용자 확인 UI를 따로 연결해야 했습니다. AI SDK는 tool calling의 형태를 제공했지만, Chat SDK와 제품 UI 사이의 접점은 여전히 팀마다 다르게 구현되는 경우가 많았습니다. 이번 변화는 그 접점을 더 공식적인 패턴으로 당긴 것입니다.
왜 지금 중요한가
에이전트 기능은 데모에서는 화려하지만 운영에서는 위험합니다. 캘린더 초대, 결제, 배포, 고객 데이터 수정, 이메일 발송처럼 실제 부작용이 있는 액션은 한 번의 tool call로 끝나지 않습니다. 사용자가 의도를 말하고, 모델이 액션을 제안하고, 시스템이 권한을 확인하고, 사용자가 승인하고, 실행 결과가 기록되어야 합니다. 이 중 하나라도 빠지면 제품은 편리함보다 불신을 먼저 얻게 됩니다.
개발팀 입장에서 이번 통합의 가치는 boilerplate를 줄이는 데 있습니다. 그러나 줄어든 코드는 곧 책임이 사라졌다는 뜻이 아닙니다. 오히려 공통 SDK 위에 어떤 정책을 얹을지가 차별점이 됩니다. “모델이 할 수 있는 일”과 “제품이 허용하는 일”을 분리하지 않으면, 작은 편의 기능이 보안·컴플라이언스·고객지원 문제로 번질 수 있습니다.
실무 체크리스트
- 읽기 전용 tool과 쓰기 tool을 분리한다.
- 쓰기 tool에는 사용자 승인 화면을 기본값으로 둔다.
- tool 입력값, 실행자, 승인자, 결과, 실패 사유를 audit log로 남긴다.
- 실패하거나 의심스러운 액션은 human escalation 경로를 둔다.
- 결제, 배포, 개인정보, 외부 발송 액션은 별도 권한 레벨로 묶는다.
- 모델 프롬프트가 아니라 서버 정책으로 금지 규칙을 집행한다.
반론과 리스크
모든 액션에 승인 절차를 넣으면 에이전트의 속도가 느려집니다. 그래서 권한 설계는 “항상 막기”가 아니라 위험도별 계층화가 되어야 합니다. 검색, 초안 작성, 요약처럼 되돌리기 쉬운 작업은 자동화하고, 외부 시스템을 변경하는 작업은 승인과 기록을 요구하는 식입니다. 좋은 에이전트 제품은 모델 성능만으로 만들어지지 않습니다. 사용자가 안심하고 맡길 수 있는 운영 체계가 있어야 합니다.
결론
Chat SDK와 AI SDK tools의 결합은 에이전트 기능을 제품에 붙이는 문턱을 낮춥니다. 그래서 더더욱 제품팀은 “무엇을 자동화할까”보다 “무엇을 승인 없이 자동화하면 안 될까”를 먼저 물어야 합니다. 이번 업데이트의 실질적 의미는 코드 절감보다, 에이전트 제품의 기본 설계가 tool registry와 permission policy 중심으로 재편된다는 데 있습니다.