배포 자동화 플랫폼 베르셀(Vercel)이 자사 AI 에이전트의 프로덕션 환경 접근 권한을 통제하는 새로운 체계를 공개했다. 사용자가 에이전트의 의도한 행동 방식을 먼저 검토한 뒤 승인하는 '계획-승인 모델'을 도입하여, 광범위한 접근 권한 부여의 위험과 반복적 승인 요청의 번거로움을 동시에 해결했다.

문제: AI 에이전트의 신뢰 딜레마

"배포 버그를 고쳐줘"라는 단순한 요청은 에이전트가 어떤 구체적 조치를 취할지, 무엇에 접근할 수 있는지를 사전에 알려주지 않는다. 베르셀이 직면한 것은 개발자 생산성과 보안 사이의 고전적 딜레마였다.

한 가지 해법은 에이전트에 광범위한 권한을 미리 부여하는 것. 하지만 실수로 인한 장애가 무관한 리소스까지 영향을 미칠 수 있다.

다른 해법은 매 단계마다 사용자 승인을 받는 것. 그러나 사용자가 에이전트의 의도된 해결책을 모른 채로 개별 액션 승인을 반복하다 보면, 결국 '승인 습관화'로 전락한다는 위험이 있다.

베르셀의 해법: "계획을 먼저, 권한은 그 다음"

베르셀 에이전트는 다음 두 단계로 작동한다.

1단계: 조사 (읽기 전용) 먼저 최근 배포 기록과 빌드 로그를 자동 검토한다. 실패한 배포와 마지막 성공 배포를 비교 분석한다. 이 단계는 읽기 전용 권한(read:deployment)으로 충분하므로, 사용자 승인 없이 자동 진행된다.

2단계: 계획 제시 및 승인 조사 결과를 바탕으로 에이전트는 "마지막 성공 버전으로 재배포하겠습니다"라는 구체적 계획을 제시한다. 이 계획에는 필요한 추가 권한(read-write:deployment)이 명시된다. 사용자는 계획 전체를 검토한 뒤 한 번에 승인함으로써, 에이전트가 무엇을 할지 미리 알 수 있다.

권한의 세 가지 수준

베르셀이 설명한 권한 메커니즘은 다음과 같이 구조화돼 있다.

읽기 전용 기본선(Baseline)

• 배포, 빌드 로그, 프로젝트 설정 조회 등 정보 수집 작업
• 사용자 승인 불필요
• 민감 정보 노출 가능성 존재 (자동 승인 ≠ 안전)

승인된 추가 권한

• 재배포, 환경변수 수정, 도메인 변경 등 변경 작업
• 사용자가 계획을 승인할 때만 활성화
• 사용자의 기존 권한을 초과할 수 없음 (중요)

외부 제공자 권한

• GitHub PR 생성 같은 외부 서비스 연동
• 각 제공자별 자격증명 필요

핵심: 사용자의 기존 권한이 상한선

베르셀 에이전트가 결코 초과할 수 없는 제약이 하나 있다. 에이전트는 사용자가 이미 보유한 권한의 범위 내에서만 작동한다는 점이다.

구체적 절차는:

1. 사용자가 베르셀 앱을 팀 단위로 인증(OAuth)
2. 베르셀이 단기 토큰 발급, 승인된 권한 범위만 포함
3. 에이전트가 각 API 요청 시마다 토큰 검증

예를 들어 팀 관리자만 팀원 추가 권한이 있는 경우, 일반 개발자가 에이전트 사용 시 팀원 추가를 승인했다 해도 실행되지 않는다.

산업적 의미: "신뢰할 수 있는 자동화"의 기준 제시

이 설계는 개발자 도구 업계에서 중요한 신호를 보낸다. AI 에이전트가 프로덕션 환경에서 행동하려면:

• 투명성: 사전에 "무엇을 할 것인가" 명시
• 유연성: 사용자가 계획 단위로 판단 가능
• 안전성: 사용자의 기존 권한을 넘지 않도록 시스템 수준에서 강제

이는 단순한 기능 추가가 아니라, AI 에이전트가 실무 환경에서 '신뢰할 수 있다'는 인증을 얻기 위한 프레임워크다.

한국 개발팀의 함의

한국 스타트업과 기업 개발팀도 베르셀 플랫폼을 적극 사용하는 추세다. 특히 팀 내 권한 구분이 명확한 대형 기업에서는 이 메커니즘이 빛난다. 과거처럼 배포 자동화를 위해 "마스터 권한 토큰"을 공유하지 않아도 되기 때문이다.

다만 한국 기업들이 갖춘 레거시 시스템과의 통합, 그리고 온프레미스 환경에서의 적용 방식은 아직 과제로 남아 있다.