Vercel Agent 공부 정리 | 에이전트에 어디까지 맡겨도 될까
Vercel이 대시보드에 AI 에이전트를 붙였다. 권한 설계가 특이해서 정리해봤다.
Vercel 블로그에서 Vercel Agent 확장 발표가 나왔다. 원래 PR 리뷰나 알림 트리아지를 돕는 기능이 있었던 것 같은데, 이번엔 아예 대시보드 안으로 들어와서 프로덕션을 직접 들여다볼 수 있게 됐다고 한다.
“프로덕션 옆에 두어도 되는 에이전트”라는 표현이 눈에 걸렸다. AI 에이전트를 프로덕션에 붙이는 얘기는 요즘 자주 나오는데, Vercel이 그 권한 구조를 어떻게 설계했는지가 궁금해서 문서를 읽어봤다.
1️⃣ 이게 뭐냐?
Vercel Agent는 배포 환경에서 이슈가 생기면 스스로 조사하고 원인을 파악하는 에이전트다. 발표에 나온 시나리오가 인상적이었는데, 밤 11시에 배포가 나가고 체크아웃 엔드포인트에서 500 에러가 터진다. 에이전트가 로그, 메트릭, 배포 기록을 훑어서 원인을 찾고, 담당자가 노트북을 열기 전에 이미 “4분 전 배포가 원인, 롤백 제안”을 내놓는다는 거다. 경보에서 조치까지 3분 미만이라고 한다.
이번 업데이트로 에이전트가 대시보드, GitHub, CLI 세 곳에서 접근 가능해졌다. 읽기만 하는 게 아니라, 승인을 받으면 실제 작업도 한다. PR 리뷰, 비용 증가 원인 추적, 빌드 실패 진단 같은 게 예시로 나온다.
👉🏻 핵심은 “읽기 전용이 기본값”이라는 부분이다. 뭔가를 바꾸려면 계획을 먼저 제시하고 사용자 승인을 받아야 한다.
2️⃣ 내가 든 생각
가장 흥미로웠던 건 권한 모델이었다. 보통 에이전트가 내 계정으로 작업하면 내 권한을 그대로 넘겨받는다. 근데 Vercel Agent는 vercel-agent라는 독자적인 보안 주체(principal)를 갖는다고 한다. 에이전트가 뭘 했는지 추적이 가능하고, 사용자보다 더 많은 권한을 가질 수 없게 설계되어 있다는 거다.
“plan-to-permission” 방식이라는 표현도 나왔는데, 에이전트가 특정 계획을 제안하고 그 계획 범위 내에서만 권한을 받는 개념인 것 같았다. 모든 호출이 세 가지를 통과해야 한다 — 에이전트가 이 작업을 할 능력이 있는지, 토큰 범위 안인지, 팀 권한 범위 안인지.
💡 그럼 에이전트가 코드를 직접 건드릴 수 있는 건가?
코드 수정이 필요하면 실제 프로젝트가 아닌 복사본 샌드박스에서 실행하고, 결과는 PR로만 제시한다고 한다. 프로덕션을 직접 손대지는 않는다는 게 포인트인 것 같았다.
디자이너 관점에서 보면, 이런 구조는 결국 “신뢰의 인터페이스”를 어떻게 만드느냐의 문제에 가까운 것 같았다. 에이전트가 지금 어떤 상태인지, 무엇을 승인받았는지가 사용자에게 명확하게 보여야 한다. 권한 모델이 아무리 잘 설계되어 있어도 UI가 그걸 못 드러내면 사람이 믿고 쓰기 어려울 테니까.
⭐️ 마지막으로, 에이전트 공부를 하면서 드는 생각
이런 류의 에이전트 발표를 볼 때 자꾸 같은 질문을 하게 되는 것 같다 — 신뢰는 기능보다 권한 설계에서 오는 걸까.
Vercel Agent가 기술적으로 뭘 할 수 있는지보다, “읽기 전용 기본값”, “독자 정체성”, “승인 범위 내 권한”이라는 세 단어가 더 인상에 남았다. 에이전트가 프로덕션에 가까워질수록, 어디까지 믿어도 되는지를 설계하는 일이 기능을 만드는 일만큼 중요한 것 같다는 생각이 들었다.