오늘부터 Vercel Agent 접근이 확대됩니다. 프로덕션 환경에서 인시던트를 안전하게 자율 조사하고, 빌드 오류를 수정하며, PR을 리뷰하는 AI 에이전트입니다.
오늘부터 Vercel Agent 접근이 확대됩니다. 처음에는 알림 분류와 PR 리뷰에서 시작했지만, 이제는 대시보드에 직접 자리를 잡았습니다. 프로덕션을 조사하고, 프로젝트 관련 질문에 답하며, 사용자가 승인하면 직접 조치까지 취합니다.
Vercel Agent는 앱을 배포하고 실행하는 플랫폼에 내장되어 있어, 프로덕션에 이상이 생기는 순간 가장 먼저 달려듭니다. 노트북을 열기도 전에 로그, 메트릭, 배포 이력을 자율적으로 분석해 근본 원인을 찾아내고 수정안을 제시합니다.
Vercel Agent는 고유한 ID로 동작하며, 기본적으로 읽기 전용입니다. Vercel 대시보드, GitHub, CLI를 통해 사용할 수 있습니다.
수개월째 Vercel Agent를 프로덕션 배포에 직접 운영하고 있습니다. 실제 조사가 어떻게 이루어지는지 살펴보겠습니다.
밤 11시에 잘못된 배포가 나가면서 체크아웃 엔드포인트에서 500 오류가 쏟아지기 시작합니다. 온콜 엔지니어가 로그인할 즈음, Vercel Agent는 이미 4분 전에 배포된 코드에서 오류 원인을 추적해 즉각적인 롤백을 권고한 상태입니다. 엔지니어가 계획을 승인하면, Vercel Agent는 이전 프로덕션 배포로 롤백하고 엔드포인트 수정을 위한 PR 작업에 착수합니다.
알림 발생부터 문제 해결까지 걸리는 시간: 3분 미만.
Vercel Agent에게 직접 작업을 지시할 수도 있습니다. 작업을 맡기면 에이전트가 발품을 팔아 질문에 답하거나 승인을 기다리는 수정안을 가져옵니다. 프로덕션은 절대 단독으로 변경하지 않습니다. 예를 들면:
PR 리뷰. PR을 확인하도록 지시하면, CI를 통과했더라도 CI에서 잡아내지 못한 성능 저하나 위험한 변경 사항을 짚어냅니다.
비용 급증 원인 추적. 청구 금액이 갑자기 오른 이유를 물으면, 캐싱 대신 매 요청마다 페이지를 서버 렌더링하도록 변경된 코드처럼 원인을 찾아냅니다. 승인하면 수정 코드를 작성하고 PR을 엽니다.
빌드 오류 수정. 실패한 배포를 가리키면, 로그를 읽고 문제가 된 설정을 찾아낸 뒤 수정 권한을 요청하고 샌드박스에서 빌드를 테스트합니다.
배포 가능 여부 확인. 특정 기능 플래그에 대해 물으면, 코드와 실시간 메트릭을 분석해 안전하게 배포할 수 있는지 알려줍니다.
앱을 고칠 수 있는 에이전트는 앱을 망가뜨릴 수도 있습니다. 그래서 프로덕션에 에이전트를 들이기 전에 반드시 물어야 할 것이 있습니다. 배포, 설정 변경, 데이터 접근을 어떻게 안전하게 허용할 것인가? 현재 대부분의 에이전트에 대한 답은 '안전하지 않다'입니다.
이유는 간단합니다. 에이전트가 사용자의 권한을 그대로 상속받기 때문입니다. 잘못된 프롬프트 하나, 혼란에 빠진 서브 에이전트 하나가 사용자 본인만큼의 피해를 낼 수 있습니다. 결국 읽기 전용이냐 상시 접근이냐, 안전하지만 제한적이냐 유능하지만 위험하냐 사이에서 선택해야 했습니다.
Vercel Agent는 세 가지를 기반으로 새로운 권한 모델을 구현합니다. 에이전트가 누구인지, 무엇을 할 수 있는지, 코드가 어디서 실행되는지입니다.
대부분의 에이전트는 사용자로서 행동합니다. 연결하는 순간, 세션 내내 사용자의 ID와 권한으로 모든 작업을 수행합니다. 에이전트가 할 수 있는 것과 사용자가 할 수 있는 것 사이에 아무런 경계가 없습니다.
Vercel Agent는 독립적인 주체인 vercel-agent로 실행됩니다. 이것이 중요한 이유는 두 가지입니다.
귀속성: 에이전트의 행동은 항상 사용자의 행동과 구별됩니다. 모든 변경 사항에는 누가 요청했고, 누가 승인했으며, Vercel Agent가 실행했다는 기록이 남습니다. 추적 불가능한 행동은 없습니다.
권한: ID가 분리된다고 해서 권한이 별도로 부여되는 것은 아닙니다. 에이전트는 사용자의 접근 권한을 상속받지 않으며, 계획 승인을 통해 명시적으로 부여된 것만, 그리고 지시하는 사람이 가진 권한 이상은 절대 받지 않습니다.
에이전트를 SDLC(소프트웨어 개발 수명 주기)에 통합할 때 보통 같은 방식으로 시작합니다. 필요 이상의 권한을, 필요 이상으로 오래 부여하는 것입니다. 그런데 에이전트에 프롬프트를 날릴 수 있는 사람이라면 누구든 그 권한이 닿는 모든 것에 접근할 수 있습니다. 부여한 권한이 곧 감수하는 위험입니다.
Vercel Agent는 기본적으로 읽기 전용입니다. 배포 롤백, 설정 변경, 캐시 삭제처럼 더 많은 권한이 필요한 작업을 수행하려면, 계획을 제안하고 해당 계획에만 한정된 접근 권한을 요청합니다. 사용자가 승인하면 에이전트가 작업을 수행하고, 계획이 완료되는 즉시 다시 읽기 전용으로 돌아갑니다.
계획을 승인하면, 에이전트는 명시된 작업에만 국한된 단기 권한을 받습니다. 그 이상은 없습니다. 에이전트가 수행하는 모든 호출은 세 가지 검사를 통과해야 합니다. 해당 권한, 토큰 범위, 팀의 기존 권한이 모두 허용하는 경우에만 실행됩니다. 이 검사는 플랫폼 내에 존재하므로, 모델이 어떻게 행동하든 반드시 적용됩니다.
이를 '플랜-투-퍼미션(plan-to-permission)' 프롬프트 모델이라고 부릅니다. 설계 자체가 최소 권한 원칙을 따릅니다. 무언가 잘못되더라도, Vercel Agent는 사용자가 승인한 계획 안에서만 행동할 수 있습니다. 프로덕션을 고칠 만큼 유능하면서도, 실제로 맡길 수 있을 만큼 통제된 에이전트입니다.
플랜-투-퍼미션 프롬프트 모델은 에이전트가 할 수 있는 행동을 제어합니다. 하지만 코드를 작성하는 에이전트라면 또 다른 문제에 직면합니다. 실행해보기 전까지는 코드가 제대로 동작하는지 알 수 없다는 점입니다.
Vercel Agent가 생성한 코드는 일시적으로 생성되는 Firecracker 마이크로VM인 Vercel Sandbox에서 실행됩니다. 샌드박스 내에서 코드는 라이브 시스템과 호스트 환경으로부터 완전히 격리됩니다.
샌드박스는 실제 프로젝트의 복사본이기 때문에, 에이전트는 실제 빌드, 테스트, 린터를 통해 생성된 코드를 검증하고 통과한 것만 제시합니다. 예를 들어 실패한 설정을 수정해야 한다면, 변경 사항을 작성하고 샌드박스에서 실행해 통과를 확인한 뒤 PR로 제출합니다.
에이전트는 자유롭게 코드를 작성하고 실행할 수 있지만, 사용자나 프로덕션에 문제가 있는 코드를 내놓을 수는 없습니다.
에이전트 시대는 두 가지 한계로 정의될 것입니다. 하나는 모델이 할 수 있는 것이고, 다른 하나는 그중 얼마나 허용할 것인가입니다. 모델이 발전할수록 전자는 점점 덜 중요해지고, 후자가 핵심이 됩니다. 결국 신뢰의 문제입니다.
더 좋은 모델은 실수가 줄어들지만, 여전히 비결정적이며 비결정적 시스템은 예측 불가능한 방식으로 실패합니다. 안전성이 에이전트가 항상 옳다는 가정 위에 세워져서는 안 됩니다. 신뢰는 시스템에 깃들어야 하고, 시스템은 실수가 얼마나 비싼 대가를 치르게 하느냐로 평가됩니다.
그 비용을 낮추는 데 수년을 투자해왔습니다. 불변 배포는 모든 배포가 보존되며, 잘못된 배포도 롤백 한 번이면 되돌릴 수 있다는 의미입니다. 처음에는 에이전트를 위해 만든 것이 아니지만, 자율 시스템에 정확히 필요한 안전장치입니다.
안전이 인프라 자체에 내장되어 있으면, 에이전트의 실수는 제한되고 사람의 실수는 더 적은 비용으로 끝납니다.
이것이 바로 안티프래질 인프라의 의미입니다. 자율 시스템에 실질적인 권한을 부여하면서도 항상 옳을 것이라는 데 베팅할 필요가 없습니다. 틀렸을 때도 기반이 버텨주기 때문입니다. 권한이 더 이상 신뢰를 전제로 하지 않습니다.
에이전트가 일을 하고, 프로덕션에 무엇이 올라갈지는 사용자가 통제합니다. 에이전트가 실수하든 사용자가 실수하든, 언제든 되돌릴 수 있습니다. 에이전트 시대에 필요한 토대가 바로 이것이며, Vercel을 사용한다면 이미 그 위에 서 있는 것입니다.
현재 Vercel Agent는 이상 징후 조사, PR 생성, 프로덕션 앱과 에이전트에 관한 질문 답변이 가능합니다. 곧 코드베이스 전체에 대한 심층 보안 리뷰나 프론트엔드 디자인 및 UX 리뷰처럼, 필요에 따라 전문 에이전트에 위임하는 기능도 추가될 예정입니다.
Vercel Agent는 Pro 및 Enterprise 플랜 팀을 대상으로 순차적으로 배포됩니다. 접근 권한 신청을 하거나, 팀에 제공되는 시점에 대시보드 사이드바의 "Agent" 섹션에서 활성화하세요.