무엇이 달라졌나

Vercel은 Chat SDK에서 Claude Managed Agents를 실행할 수 있게 됐다고 발표했다. 핵심은 에이전트가 대화 중에 반복적으로 판단하고 도구를 호출하고 상태를 이어가는 과정을 애플리케이션 서버가 직접 모두 떠안지 않아도 된다는 점이다. 발표에 따르면 Claude Managed Agents는 모델, 도구, 세션 상태, 샌드박스 기반 웹 리서치를 포함한 에이전트 루프를 서버 측에서 처리한다.

개발자 입장에서는 “채팅 UI를 붙였다”보다 “상태를 가진 에이전트형 대화 흐름을 어디까지 덜 구현해도 되는가”가 더 중요하다. 예를 들어 Slack 안에서 리서치 봇을 만들고, 스레드마다 하나의 지속 세션을 유지하며, 출처가 포함된 요약을 스트리밍으로 보여주는 구성이 발표 예시로 제시됐다. 개인 사용자나 연구자에게는 반복 조사와 출처 정리의 자동화 가능성이 핵심이고, 개발자에게는 세션 관리와 도구 호출 추적을 기존 백엔드 구조에서 얼마나 줄일 수 있는지가 관건이다.

개발자가 먼저 봐야 할 구조적 변화

이번 기능은 단순한 모델 호출 API라기보다, 대화형 에이전트를 제품 안에 넣을 때 필요한 주변 요소를 일부 관리형 서비스로 넘기는 흐름에 가깝다. 기존에는 사용자가 메시지를 보내면 서버가 모델을 호출하고, 도구 호출을 처리하고, 중간 상태를 저장하고, 대화 내역을 데이터베이스에 보관하고, UI에는 토큰 단위 응답이나 실행 로그를 따로 연결해야 했다. Vercel 발표는 이 가운데 세션 상태와 실행 흐름의 상당 부분을 Managed Agents 쪽에서 맡기는 방향을 제시한다.

다만 발표문만으로는 모든 운영 조건이 확인되지 않는다. 요금, 사용량 제한, 데이터 보존 방식, 조직 계정에서의 권한 경계, 지역별 제공 여부, 기업 보안 요구사항 충족 여부는 별도로 확인해야 한다. 특히 업무 문서, 연구 자료, 고객 데이터, 비공개 코드가 들어가는 에이전트라면 “돌아간다”와 “써도 된다”를 분리해서 판단해야 한다.

제공되는 기능을 실제 흐름에 대입하기

발표에서 명시된 기능은 네 가지로 정리할 수 있다. 첫째, 토큰 단위 스트리밍이다. 사용자는 응답이 완성될 때까지 기다리는 대신 모델이 작성하는 과정을 실시간에 가깝게 볼 수 있다. 긴 리서치 요약이나 단계별 분석 결과를 보여주는 봇에서는 체감 속도와 신뢰감에 영향을 준다.

둘째, 실시간 활동 피드다. 도구 호출과 모델 요청이 턴이 진행되는 동안 제공되므로, 채팅 화면 안에 현재 어떤 작업이 진행 중인지 표시할 수 있다. 개발자 도구나 연구 보조 도구에서는 이 부분이 중요하다. 사용자가 단순히 결과만 받는 것이 아니라, 검색했는지, 어떤 도구를 호출했는지, 어떤 단계에서 시간이 걸렸는지 볼 수 있어야 결과를 검토하기 쉽다.

셋째, 별도 데이터베이스 없이 대화 저장 흐름을 구성할 수 있다는 점이다. 발표에 따르면 Managed Agents 세션이 대화를 저장하므로 사이드바, 대화 기록, 재생 기능이 자체 서버 상태 없이 해당 세션에서 읽을 수 있다. 이는 초기 구현 비용을 낮출 수 있지만, 동시에 데이터가 어디에 저장되고 얼마나 유지되며 누가 접근할 수 있는지 확인해야 한다는 뜻이기도 하다.

넷째, 플랫폼 이동성이다. Vercel은 핸들러의 일부 코드를 바꾸는 방식으로 Teams, Google Chat, Discord, WhatsApp 등 30개 이상의 플랫폼으로 에이전트를 옮길 수 있다고 설명한다. 여러 메신저 채널에 같은 에이전트를 붙이려는 팀에는 매력적인 지점이다. 반대로 Slack 하나만 쓰는 개인 프로젝트라면 이 장점이 당장 큰 도입 이유가 되지 않을 수도 있다.

어떤 사용자에게 의미가 큰가

  • 개인 개발자: 사이드 프로젝트에서 Slack 리서치 봇, 문서 요약 봇, 배포 확인 봇처럼 반복되는 작업을 줄이고 싶다면 검토할 만하다. 다만 무료 범위와 월 사용량 제한은 반드시 확인해야 한다.
  • 학생과 연구자: 출처가 포함된 요약을 스트리밍으로 받는 흐름은 자료 조사에 유용할 수 있다. 하지만 인용 정확도, 출처 누락, 접근 가능한 웹 자료 범위는 직접 샘플로 검증해야 한다.
  • 팀 개발자: 채팅 플랫폼 안에서 운영 점검, 코드 리뷰 보조, 문서 검색을 연결하려는 경우 세션 관리와 실행 로그 노출을 줄일 수 있는지 봐야 한다.
  • 자동화 담당자: 여러 채팅 플랫폼으로 같은 에이전트를 확장할 계획이 있다면 Chat SDK의 이식성 설명을 실제 핸들러 코드 수준에서 확인해야 한다.

기능보다 먼저 확인할 제한 조건

항목 확인할 질문 판단 기준
요금 Claude Managed Agents, Vercel, 연결 플랫폼 사용료가 각각 어떻게 계산되는가? 반복 작업 절감 효과가 월 비용과 사용량 제한을 넘어서야 한다.
권한 Slack 스레드, 외부 도구, 웹 리서치 권한이 어디까지 열리는가? 최소 권한으로 필요한 작업만 수행할 수 있어야 한다.
데이터 세션 대화와 도구 호출 기록이 어디에 저장되고 얼마나 유지되는가? 업무 자료나 연구 데이터가 들어간다면 보존, 삭제, 접근 통제를 확인해야 한다.
품질 출처가 포함된 요약이 실제로 검증 가능한 형태로 제공되는가? 중요한 결정에 쓰려면 원문 링크와 요약의 대응 관계를 사람이 확인할 수 있어야 한다.
이식성 Slack에서 만든 흐름을 Teams, Google Chat, Discord, WhatsApp으로 옮길 때 수정 범위가 어느 정도인가? 핸들러 몇 줄 변경 수준인지, 플랫폼별 권한과 메시지 형식 차이가 큰지 확인해야 한다.

Slack 리서치 봇으로 검증할 때의 기준

발표 예시는 Slack 리서치 에이전트다. 따라서 처음 검증한다면 전체 업무 자동화를 옮기기보다 Slack 스레드 하나에서 반복되는 질문 유형을 정하는 편이 낫다. 예를 들어 “특정 기술 발표를 찾아 핵심 변화와 출처를 정리해 달라”처럼 입력과 결과 형식이 분명한 작업이 좋다. 이때 봐야 할 것은 답변이 그럴듯한지가 아니라, 같은 질문을 여러 번 던졌을 때 출처 제시 방식이 안정적인지, 세션이 스레드별로 잘 유지되는지, 중간 활동 피드가 사용자에게 충분한 검토 단서를 주는지다.

토큰 단위 스트리밍은 사용자 경험을 개선할 수 있지만, 긴 답변이 빠르게 보인다고 해서 품질이 보장되는 것은 아니다. 리서치 봇이라면 출처가 있는 문장과 모델이 추론한 문장을 구분해 볼 수 있어야 한다. 또한 웹 리서치가 샌드박스에서 수행된다는 설명만으로 내부 자료 접근 정책이 자동으로 해결되는 것은 아니므로, 사내 문서나 비공개 저장소를 연결하기 전에는 접근 범위를 따로 제한해야 한다.

기존 구현과 비교하는 법

이미 자체 채팅 서버, 데이터베이스, 작업 큐, 도구 호출 로그를 갖춘 팀이라면 이번 기능이 곧바로 전환 이유가 되지는 않는다. 비교 기준은 구현 난이도보다 운영 비용과 장애 처리다. Managed Agents 세션을 쓰면 자체 서버 상태를 줄일 수 있지만, 그만큼 외부 관리형 세션에 의존하게 된다. 반대로 자체 구현은 초기 비용이 크지만 저장 정책, 감사 로그, 권한 모델을 더 세밀하게 통제할 수 있다.

개인 프로젝트나 초기 제품이라면 관리형 세션의 장점이 더 크게 보일 수 있다. 데이터베이스를 직접 구성하지 않고도 대화 기록, 사이드바, 재생 흐름을 만들 수 있다면 출시 속도가 빨라진다. 그러나 장기적으로는 내보내기, 삭제, 백업, 장애 시 대체 경로가 필요할 수 있다. 초기에는 편의성을 우선하되, 중요한 데이터가 쌓이기 전에 이전 가능성을 점검하는 것이 좋다.

적용 전 샘플 프로젝트에서 볼 것

  1. Vercel이 제공하는 Slack 리서치 에이전트 배포 흐름이 현재 계정에서 가능한지 확인한다.
  2. 단계별 가이드와 템플릿 소스를 보고 핸들러에서 실제로 바뀌는 코드 범위를 확인한다.
  3. 스레드별 지속 세션이 기대대로 유지되는지, 다른 스레드와 내용이 섞이지 않는지 테스트한다.
  4. 스트리밍 응답 중 활동 피드가 도구 호출과 모델 요청을 충분히 보여주는지 확인한다.
  5. 대화 기록, 사이드바, 재생 기능이 자체 데이터베이스 없이 어느 범위까지 동작하는지 확인한다.
  6. 실제 업무 자료를 넣기 전 요금, 보존, 삭제, 권한 조건을 공식 문서에서 다시 확인한다.

도입을 미뤄야 하는 경우

비공개 고객 데이터, 민감한 연구 자료, 규제 대상 문서를 다루는데 데이터 보존과 접근 통제 조건을 아직 확인하지 못했다면 도입을 미루는 편이 맞다. 또한 기존 자동화가 이미 안정적으로 동작하고 있고, 새 기능이 줄여주는 반복 작업이 분명하지 않다면 전환보다 관찰이 낫다. 관리형 에이전트는 구현 부담을 낮출 수 있지만, 운영 책임이 사라지는 것은 아니다.

반대로 반복 리서치, 출처 요약, 채팅 기반 작업 요청이 많은 환경이라면 작은 범위에서 확인할 가치가 있다. 핵심은 “새 SDK를 써봤다”가 아니라 “매주 반복되는 작업 하나가 줄었고, 실패했을 때 사람이 검토하고 되돌릴 수 있다”는 상태를 만드는 것이다.

출처와 검증

이 글은 Vercel Changelog의 발표 내용을 바탕으로 작성했다. 발표문에서 확인되는 내용은 Chat SDK에서 Claude Managed Agents를 실행할 수 있다는 점, 서버 측 에이전트 루프 처리, 토큰 단위 스트리밍, 실시간 활동 피드, Managed Agents 세션 기반 대화 저장, Slack 리서치 에이전트 예시, 여러 채팅 플랫폼으로의 이식성 설명이다.

요금, 세부 권한, 데이터 보존 기간, 지역 제한, 조직 계정 정책은 제공된 발표문만으로 확정할 수 없다. 실제 적용 전에는 공식 문서, 가격표, 템플릿 소스, 계정별 설정 화면에서 같은 조건이 적용되는지 확인해야 한다.

원문: https://vercel.com/changelog/claude-managed-agents-with-chat-sdk