오늘 우리는 기능을 확장합니다. 처음에는 알림을 분류하고 Pull Request (PR)를 검토하는 것부터 시작했습니다. 이제 Vercel Agent는 대시보드에 자리를 잡았으며, 프로덕션 (Production) 환경을 조사하고, 프로젝트에 대한 질문에 답하며, 사용자가 승인하면 직접 조치를 취할 수 있습니다. Vercel Agent

Vercel Agent는 앱을 배포하고 실행하는 플랫폼 내에 구축되어 있기 때문에, 프로덕션 환경에 변화가 생기면 가장 먼저 대응하는 First Responder 역할을 합니다. 사용자가 노트북을 열기도 전에 로그, 메트릭 (Metrics), 배포 (Deployments)를 자율적으로 조사하여 근본 원인을 찾아내고 해결책을 제안합니다.

Vercel Agent는 자체적인 ID로 작동하며 기본적으로 읽기 전용 (Read-only) 상태입니다. Vercel Dashboard, GitHub, 그리고 CLI를 통해 접근할 수 있습니다.

우리는 이미 몇 달 동안 실제 프로덕션 배포 환경에서 Vercel Agent를 실행해 왔습니다. 일반적인 조사 과정은 다음과 같습니다.

밤 11시에 잘못된 배포가 이루어져 체크아웃 엔드포인트 (Endpoint)에서 500 에러가 발생하기 시작합니다. 온콜 (On-call) 엔지니어가 로그인할 때쯤이면, Vercel Agent는 이미 에러의 원인이 4분 전에 이루어진 배포임을 추적해냈고, 즉각적인 롤백 (Rollback)을 권장합니다. 엔지니어가 계획을 승인하면, Vercel Agent는 권한에 따라 이전 프로덕션 배포로 롤백을 수행하고 엔드포인트를 수정하기 위한 PR 작업을 시작합니다.

알림 발생부터 완화까지 걸린 시간은 3분 미만이었습니다.

사용자가 직접 Vercel Agent에게 지시를 내릴 수도 있습니다. 작업을 맡기면 Agent가 실무를 수행한 뒤, 질문에 답하거나 승인할 수 있는 수정 사항을 전달합니다. Agent가 스스로 프로덕션 환경을 변경하는 일은 절대 없습니다. 예를 들어:

앱을 고칠 수 있는 Agent는 앱을 망가뜨릴 수도 있습니다. 따라서 프로덕션 환경에 접근을 허용하는 모든 Agent에 대해 가장 먼저 던져야 할 질문은 이것입니다: '이 Agent가 배포를 하거나, 설정을 변경하거나, 데이터에 접근하도록 허용하는 것이 어떻게 안전한가?' 오늘날 대부분의 Agent에 대한 대답은 '안전하지 않다'입니다.

그 이유는 이들이 사용자의 모든 권한을 상속받기 때문입니다. 사용자의 잘못된 프롬프트(Prompt) 하나나 혼란에 빠진 서브 에이전트(Sub-agent)는 사용자와 동일한 영향 범위 (Blast radius)를 가집니다. 지금까지의 선택지는 읽기 전용 또는 상시 접근 권한, 신중하지만 제한적인 권한 또는 유능하지만 위험한 권한 중 하나였습니다.

Vercel Agent는 에이전트가 누구인지, 무엇을 할 수 있는지, 그리고 코드가 어디에서 실행될 수 있는지라는 세 가지 요소를 기반으로 구축된 새로운 권한 모델 (permissions model)을 구현합니다.

대부분의 에이전트는 사용자 자신처럼 동작합니다. 에이전트를 연결하면 전체 세션 동안 사용자의 신원 (identity)과 접근 권한을 가지고 동작합니다. 에이전트가 할 수 있는 일과 사용자가 할 수 있는 일 사이에 경계가 없습니다.

Vercel Agent는 vercel-agent라는 자체 주체 (principal)로서 실행됩니다. 이는 두 가지 이유로 중요합니다:

에이전트를 소프트웨어 개발 생명 주기 (SDLC)에 통합하는 과정은 보통 에이전트에게 필요한 것보다 더 많은 권한을, 더 오랫동안, 초기에 광범위하게 부여하는 동일한 방식으로 시작됩니다. 하지만 에이전트에게 프롬프트 (prompt)를 입력할 수 있는 사람이라면 누구나 해당 권한이 닿는 모든 곳에 접근할 수 있습니다. 여러분이 부여한 권한은 곧 여러분이 감수해야 하는 노출 (exposure)입니다.

Vercel Agent는 기본적으로 읽기 전용 (read-only)입니다. 배포 롤백 (rolling back a deploy), 설정 변경 (changing a config), 또는 캐시 삭제 (clearing a cache)와 같이 더 많은 작업을 수행하려면, 에이전트는 계획 (plan)을 제안하고 해당 계획에 구체적으로 범위가 지정된 (scoped) 접근 권한을 요청합니다. 사용자가 이를 승인하면 에이전트가 작업을 수행하며, 계획이 완료되는 즉시 다시 읽기 전용 상태로 돌아갑니다.

사용자가 계획을 승인하면, 에이전트는 자신이 명시한 정확한 작업들에 대해서만 짧은 수명의 권한 (short-lived capability)을 얻으며, 그 외의 것에는 권한을 얻지 못합니다. 에이전트가 수행하는 모든 호출은 세 가지 확인 절차를 통과해야 합니다: 해당 권한 (capability), 토큰의 범위 (token's scope), 그리고 팀의 기존 권한 (existing permissions)입니다. 에이전트는 이 세 가지가 모두 허용하는 곳에서만 실행되며, 이러한 확인 절차는 플랫폼 내에 존재하므로 모델이 무엇을 하든 상관없이 유지됩니다.

우리는 이를 계획-권한 프롬프트 모델 (plan-to-permission prompt model)이라고 부릅니다. 이는 설계 단계부터 최소 권한 원칙 (least privilege)을 따릅니다. 무언가 잘못되더라도 Vercel Agent는 사용자가 승인한 계획 범위 내에서만 동작할 수 있습니다. 이는 프로덕션을 수정할 수 있을 만큼 유능하면서도, 실제로 수정을 허용할 수 있을 만큼 통제된 에이전트입니다.

계획-권한 프롬프트 모델은 에이전트가 무엇을 할 수 있는지 제어합니다. 하지만 코드를 작성하는 모든 에이전트는 두 번째 문제에 직면합니다: 코드를 실행해 보기 전까지는 그 코드가 제대로 작동하는지 알 방법이 없다는 점입니다.

Vercel Agent가 생성하는 코드는 일시적인 Firecracker 마이크로VM(microVM)인 Vercel Sandbox 내에서 실행됩니다. 이 샌드박스(sandbox) 내부에서 해당 코드는 사용자의 라이브 시스템 및 호스트 환경으로부터 격리됩니다.

샌드박스는 프로젝트의 실제 복사본이므로, 에이전트는 생성된 코드를 실제 빌드(build), 테스트(tests), 린터(linters)에 적용하여 실행하며, 통과한 결과만을 제시합니다. 예를 들어, 에이전트가 실패하는 설정을 수정해야 한다고 가정해 봅시다. 에이전트는 변경 사항을 작성하고, 샌드박스에서 이를 실행하여 통과 여부를 확인한 뒤, 이를 PR(Pull Request)로 제시합니다.

에이전트는 자유롭게 코드를 작성하고 실행할 수 있지만, 여전히 고장 난 코드를 사용자에게 제시하거나 프로덕션(production) 환경에 반영할 수는 없습니다.

에이전트 시대는 두 가지 한계(ceilings)에 의해 정의될 것입니다. 하나는 모델이 무엇을 할 수 있는가이며, 다른 하나는 당신이 그중 얼마만큼을 허용할 것인가입니다. 모델이 개선됨에 따라 첫 번째는 덜 중요해지고, 두 번째가 핵심이 됩니다. 이 모든 것은 신뢰(trust)의 문제로 귀결됩니다.

더 나은 모델은 오류를 덜 빈번하게 범하지만, 여전히 비결정론적(non-deterministic)이며, 비결정론적인 시스템은 비결정론적으로 실패합니다. 안전에 대한 이야기는 에이전트가 매번 올바르게 수행한다는 사실에만 의존할 수 없습니다. 신뢰는 시스템 내에 존재해야 하며, 시스템은 실수가 초래하는 비용에 의해 평가됩니다.

우리는 수년간 그 비용을 낮추기 위해 노력해 왔습니다. 이는 모든 배포(deploy)가 보존되며, 잘못된 배포는 롤백(rollback) 한 번으로 되돌릴 수 있음을 의미합니다. 우리는 처음부터 에이전트를 위해 이것을 구축한 것은 아니지만, 이것은 자율 시스템(autonomous system)에 정확히 필요한 가드레일(guardrail)입니다. Immutable deployments

안전성이 인프라 자체에 내장되면, 에이전트의 실수는 격리되고 인간의 실수는 비용이 적게 듭니다.

이것이 바로 우리가 말하는 안티프래질(anti-fragile) 인프라입니다. 자율 시스템이 올바를 것이라는 도박을 하지 않고도 시스템에 실제 권한을 부여할 수 있습니다. 시스템이 틀렸을 때도 기반이 버텨주기 때문입니다. 권한은 더 이상 신뢰를 요구하지 않게 됩니다.

에이전트는 작업을 수행하고, 당신은 프로덕션에 도달하는 것을 제어하며, 에이전트에 의해서든 당신에 의해서든 무언가 잘못되었을 때 이를 되돌릴 수 있습니다. 이것이 에이전트 시대에 필요한 토대이며, Vercel과 함께라면 당신은 이미 그 위에 서 있습니다.

오늘, Vercel Agent는 이상 징후를 조사하고, PR(Pull Request)을 생성하며, 프로덕션(Production) 환경의 앱과 에이전트에 관한 질문에 답변할 수 있습니다. 곧, 코드베이스 전반에 걸친 심층 보안 검토(Security review)나 프론트엔드(Frontend)의 디자인 및 UX 검토와 같이 필요에 따라 전문가에게 작업을 위임하게 될 것입니다.

Vercel Agent는 Pro 및 Enterprise 팀을 대상으로 점진적으로 출시됩니다. 팀에서 사용할 수 있게 되면 대시보드 사이드바의 "Agent" 섹션에서 활성화하거나 액세스 요청을 할 수 있습니다.

더 읽어보기

Vercel Agent가 당신을 위해 하는 일

프로덕션 환경 내 에이전트를 위한 새로운 보안 모델

안티프래질(Anti-fragile) 인프라

다음 단계

시작하기

Vercel Agent로 할 수 있는 일

• PR을 살펴보라고 명령하면, 통과된 CI(Continuous Integration) 실행에서는 나타나지 않는 성능 퇴보(Performance regressions) 및 위험한 변경 사항을 식기(Flag)합니다. 풀 리퀘스트(Pull request) 검토.

• 비용이 왜 급증했는지 물어보면, 캐싱 대신 모든 요청에 대해 페이지를 서버 사이드 렌더링(Server-renders)하는 코드 변경과 같은 원인을 찾아냅니다. 승인 시, 수정 사항을 작성하고 PR을 생성합니다. 비용 증가 추적.

• 실패한 배포(Deployment)를 Vercel Agent로 지정하면, 로그를 읽고 실패한 설정을 찾아내어 업데이트 권한을 요청한 뒤 샌드박스(Sandbox)에서 빌드를 테스트합니다. 깨진 빌드 수정.

• 피처 플래그(Feature flag)에 대해 물어보면, 코드와 라이브 메트릭(Live metrics)을 읽고 배포가 안전한지 알려줍니다. 배포 가능 여부 확인.

Vercel Agent는 고유한 ID를 가집니다

계획이 곧 권한입니다

생성된 코드는 샌드박스에서 실행됩니다

1. 에이전트의 작업은 항상 사용자의 작업과 구별됩니다. 모든 변경 사항에는 누가 요청했는지, 누가 승인했는지, 그리고 Vercel Agent가 이를 수행했는지가 기록됩니다. 에이전트가 수행하는 그 어떤 것도 추적 불가능하지 않습니다. 귀속(Attribution):

2. 별도의 ID가 별도의 권한을 의미하지는 않습니다. 에이전트는 사용자의 액세스 권한을 상속받지 않습니다. 에이전트는 계획 승인(Plan approval)을 통해 명시적으로 부여된 권한만 가지며, 이를 지시하는 사람이 이미 가진 권한보다 더 많은 권한을 절대 가질 수 없습니다. 권한(Authority):