Vercel이 Claude Managed Agents를 Vercel Sandbox에서 실행하는 구성을 공개했다. 핵심은 에이전트의 모델·루프·세션 상태는 Anthropic의 관리형 에이전트 기능에 맡기고, 실제 도구 호출은 Vercel 인프라의 격리된 샌드박스에서 처리하는 방식이다. 개발팀은 기능 이름보다 권한 경계, 비밀 값 처리, 네트워크 허용 범위, 비용과 롤백 가능성을 먼저 확인해야 한다.

핵심 요약

  • Vercel 발표에 따르면 Claude Managed Agents는 모델, 하네스, 도구, 세션 상태를 관리하고 Vercel Sandbox는 각 에이전트 세션의 실행 환경을 제공한다.
  • 각 세션은 독립된 Firecracker microVM에서 실행된다. Vercel은 이 구조가 밀리초 단위 시작과 엔터프라이즈급 보안·가용성·성능을 목표로 한다고 설명한다.
  • 에이전트의 도구 호출은 기존 Vercel 인프라 안에서 실행할 수 있어 private API, 내부 서비스, 고객 데이터와 연결되는 작업 흐름을 설계할 수 있다.
  • 비밀 값은 샌드박스 내부로 직접 넣지 않고 방화벽 계층의 credential brokering으로 다루며, 외부 통신은 기본 차단 후 도메인 허용목록으로 여는 모델이다.
  • 공개 발표만으로는 요금, 쿼터, 로그 보존, 조직별 정책까지 확정할 수 없다. 실제 업무 적용 전에는 Vercel Sandbox 문서와 Anthropic Managed Agents 문서를 함께 확인해야 한다.

무엇이 바뀌었나

이번 조합은 “에이전트가 답변을 생성한다”에서 한 단계 더 나아가, 에이전트가 실제 도구를 호출하는 실행 위치를 명확히 나누는 데 의미가 있다. Claude Managed Agents는 Anthropic 쪽에서 에이전트 루프와 세션 상태를 다루고, Vercel Sandbox는 세션별 실행 환경을 만든다. Vercel은 함수 기반 control plane이 세션마다 sandbox를 생성한다고 설명한다.

개발팀 관점에서 중요한 지점은 self-hosting의 의미다. 원문은 self-hosting을 통해 에이전트의 tool call이 기존 Vercel 인프라, private API, 내부 서비스, 고객 데이터와 연결될 수 있다고 설명한다. 즉 단순 챗봇보다 더 강한 권한을 줄 수 있는 구조이므로, 잘 설계하면 반복 운영 작업을 줄일 수 있지만 잘못 설계하면 권한 과다 부여나 데이터 노출 위험도 커진다.

또 하나의 변화는 네트워크 기본값이다. 발표 내용에는 deny-by-default egress와 도메인 allowlist가 포함돼 있다. 에이전트가 외부로 접속할 수 있는 대상을 처음부터 열어두지 않고 필요한 도메인만 허용하는 접근이다. 실제로는 allowlist를 누가 관리하는지, 임시 예외를 어떻게 승인하는지, 실패한 외부 요청을 어떤 로그로 남길지까지 운영 절차가 필요하다.

실사용 전 확인 기준

항목 확인할 질문 권장 판단
권한 범위 에이전트가 어떤 API, 저장소, 내부 서비스에 접근하는가? 읽기 전용과 쓰기 권한을 분리하고, 초기 검증에서는 파괴적 작업을 막는다.
비밀 값 토큰과 키가 샌드박스 내부 파일이나 로그에 남지 않는가? credential brokering 흐름을 문서와 코드로 확인하고, 테스트 토큰으로 먼저 검증한다.
네트워크 도메인 allowlist가 실제 업무 범위만 포함하는가? 기본 차단 상태에서 필요한 도메인만 추가하고, 예외 요청 절차를 남긴다.
격리와 수명 세션별 microVM이 언제 생성되고 언제 폐기되는가? 세션 종료, 실패, 타임아웃 상황에서 임시 파일과 상태가 남지 않는지 확인한다.
관측성 도구 호출, 실패, 네트워크 차단, 비용을 추적할 수 있는가? 성공률뿐 아니라 거부된 요청과 재시도 횟수를 기록한다.
비용 Managed Agents, Vercel Sandbox, 함수 실행, 네트워크 비용이 어떻게 합산되는가? 원문 발표에는 상세 비용 조건이 충분히 나오지 않으므로 실제 플랜과 사용량 기준으로 산정한다.

어떤 팀에 먼저 맞나

이 구성은 모든 Claude 사용자가 바로 켜야 하는 기능이라기보다, 에이전트가 내부 개발 도구를 호출해야 하는 팀에 더 가깝다. 예를 들어 배포 전 점검, 사내 API를 통한 상태 조회, 문서·이슈·로그를 함께 읽는 운영 보조, 고객별 환경을 분리한 자동화 실험처럼 실행 환경과 권한 관리가 중요한 작업에서 검토 가치가 있다.

반대로 단순 질의응답, 문서 초안 작성, 코드 설명처럼 외부 도구 호출이 거의 없는 작업이라면 복잡한 샌드박스 구성이 과할 수 있다. 이 경우에는 기존 Claude 인터페이스, 사내 챗봇, CI 단계의 정적 검사, GitHub Actions 기반 자동화가 더 단순하고 비용 예측도 쉽다.

개발자 경험 측면에서는 Vercel 함수가 control plane 역할을 하고 세션마다 sandbox를 생성하는 점이 장점이 될 수 있다. 기존 Vercel 배포와 네트워크에 맞춰 연결할 수 있기 때문이다. 다만 이 장점은 팀이 이미 Vercel 기반 운영·배포·관측 흐름을 갖고 있을 때 더 크게 나타난다.

작은 검증 절차

  1. 무해한 작업 하나를 고른다. 예를 들어 내부 API의 상태를 읽고 요약하는 작업처럼 쓰기 권한이 필요 없는 시나리오로 시작한다.
  2. 테스트 전용 토큰을 쓴다. 실제 운영 키가 아니라 제한된 권한의 토큰을 credential brokering 경로로 전달하고, 샌드박스 안에 평문으로 남지 않는지 확인한다.
  3. egress allowlist를 최소화한다. 필요한 도메인만 열고, 허용되지 않은 도메인 요청이 차단되는지 의도적으로 확인한다.
  4. 세션 종료를 관찰한다. Firecracker microVM 기반 격리가 실제 임시 파일, 캐시, 세션 상태 삭제와 어떻게 연결되는지 실패 상황까지 본다.
  5. 비용과 지연 시간을 기록한다. 세션 시작 시간, 도구 호출 횟수, 함수 실행 시간, 재시도 횟수를 함께 남겨 반복 업무에 붙일 가치가 있는지 판단한다.
  6. 자동 수정은 제한한다. 에이전트가 코드를 변경하거나 배포를 실행해야 한다면 사람 검토, 변경 diff, 롤백 명령을 별도 단계로 둔다.

보안·운영 리스크

에이전트 샌드박스의 핵심 리스크는 “격리되어 있다”는 표현만 믿고 권한을 넓게 주는 것이다. microVM 격리는 실행 환경을 분리하는 장치이지만, 에이전트가 접근할 수 있는 API와 데이터 범위까지 자동으로 안전하게 만들어 주지는 않는다. 실제 보안 경계는 토큰 권한, 네트워크 allowlist, 로그 정책, 실패 시 차단 정책을 함께 설계해야 생긴다.

프롬프트 인젝션과 데이터 유출도 별도로 봐야 한다. 에이전트가 외부 문서나 웹페이지를 읽은 뒤 내부 API를 호출한다면, 외부 콘텐츠가 에이전트에게 잘못된 명령을 줄 수 있다. 따라서 외부 입력을 읽는 단계와 내부 권한을 쓰는 단계를 분리하고, 민감한 데이터가 응답·로그·외부 요청에 섞이지 않도록 출력 필터와 승인 단계를 두는 편이 안전하다.

운영 측면에서는 false positive와 실패 처리도 중요하다. deny-by-default egress는 안전하지만 정상 요청도 차단할 수 있다. allowlist가 너무 자주 바뀌면 운영 부담이 커지고, 너무 넓으면 보안 이점이 줄어든다. 처음에는 자동 수행 범위를 좁히고, 차단 로그를 보며 필요한 목적지만 추가하는 방식이 적합하다.

결론

Claude Managed Agents와 Vercel Sandbox의 조합은 에이전트 실행을 제품 데모에서 실제 운영 환경 쪽으로 옮기려는 팀에게 흥미로운 선택지다. 특히 세션별 Firecracker microVM, credential brokering, deny-by-default egress는 개발팀이 에이전트 권한을 더 세밀하게 설계할 수 있게 해 준다.

다만 이 발표만으로 바로 운영 자동화를 맡기는 것은 성급하다. 먼저 읽기 전용 PoC로 시작하고, 비밀 값·네트워크·로그·비용·롤백 기준을 문서화한 뒤 제한된 업무에 붙여 보는 순서가 안전하다. 에이전트가 할 수 있는 일을 늘리는 것보다, 에이전트가 해서는 안 되는 일을 명확히 막는 설계가 이번 통합의 성패를 가른다.

출처와 검증