Vercel Connect 소개

에이전트(agents)에게 도구, 데이터 및 서비스에 대한 접근 권한을 부여하는 것이 에이전트를 유용하게 만드는 핵심입니다. 에이전트가 여러 시스템에 걸쳐 더 깊은 작업을 수행함에 따라, 해당 접근에 대한 인증(authenticating) 및 인가(authorizing)가 애플리케이션 아키텍처의 중심이 되고 있습니다.

오늘날 에이전트의 접근 권한은 보통 에이전트가 필요로 할 수 있는 모든 것에 대해 준비된, 환경 변수(environment variables)에 저장된 장기 생존 프로바이더 토큰(long-lived provider tokens)을 통해 부여됩니다. 이러한 토큰은 모든 사용자에게 공유되며, 만료되지 않고, 작업의 규모와 상관없이 에이전트에게 모든 작업에 대한 완전한 접근 권한을 부여합니다.

볼트(vault)는 해당 토큰을 훔치기 어렵게 만들 수는 있지만, 위험성을 줄여주지는 않습니다. 문제는 토큰이 유출되었을 때 발생합니다. 토큰이 접근할 수 있는 모든 것이 노출되기 때문입니다.

우리는 이 문제를 해결하기 위해 만들었습니다. 현재 퍼블릭 베타(Public Beta) 단계인 Vercel Connect는 저장된 토큰을 런타임 자격 증명 교환(runtime credential exchange)으로 대체합니다. 커넥터(connector)를 한 번 등록하면 됩니다. 에이전트가 수행할 작업이 있을 때, 앱은 Vercel Connect에 자신의 신원을 증명하고 해당 작업에 국한된(scoped) 단기 자격 증명(short-lived credential)을 받아옵니다. 기존에 토큰으로 수행하던 모든 작업은 그대로 작동합니다. 에이전트는 단지 토큰을 보유하는 대신 매번 접근 권한을 요청할 뿐입니다.Vercel Connect

커넥터는 귀하의 Vercel 팀과 Slack 또는 GitHub와 같은 프로바이더(provider) 사이의 재사용 가능한 연결입니다. 대시보드나 CLI를 통해 한 번 생성한 다음, 프로젝트 수준의 접근 제어(access controls)와 함께 필요한 프로젝트 및 환경에 연결하면 됩니다.

프로바이더와의 관계는 이제 수십 개의 환경 변수 패널에 흩어져 있어 토큰 교체(rotation) 시 모든 복사본을 찾아다녀야 하는 대상이 아니라, 한눈에 보고 관리할 수 있는 단일 엔티티(entity)가 됩니다.

귀하의 코딩 에이전트(coding agent)도 이 설정을 실행할 수 있습니다. npx skills add vercel/vercel-plugin --skill vercel-connect 명령으로 vercel-connect 스킬을 설치하면, 에이전트가 귀하를 대신해 커넥터를 생성하고 연결할 수 있습니다.

커넥터가 설정되면, 에이전트는 작업이 필요한 경우에만 자격 증명 (credential)을 요청합니다. SDK는 제공자 API (provider API)에 즉시 사용할 수 있는 토큰을 반환하며, 귀하의 앱에는 어떠한 제공자 비밀 값 (provider secret)도 저장되지 않습니다.@vercel/connect

토큰은 수명이 짧으며, 그 수명은 제공자에 따라 달라집니다. SDK가 이를 자동으로 갱신하므로, 비밀 값을 수동으로 교체 (rotate)할 필요가 없습니다. 그렇다면 한 가지 질문이 남습니다. 앱이 비밀 값을 보유하고 있지 않다면, 요청 권한이 있음을 무엇으로 증명할까요?

그 증명은 귀하의 앱이 이미 가지고 있는 신원 (identity)입니다. Vercel의 모든 배포 (deployment)는 OIDC 신원을 부여받으며, 앱이나 에이전트가 토큰을 요청할 때 SDK는 해당 신원을 Vercel Connect에 제시합니다. Vercel Connect는 이를 검증하고, 해당 프로젝트와 환경이 커넥터를 사용할 권한이 있는지 확인한 후 제공자 자격 증명 (provider credential)을 반환합니다. 이 왕복 과정이 바로 런타임 자격 증명 교환 (runtime credential exchange)입니다.

동일한 신원은 vercel link 및 vercel env pull을 통해 로컬 개발 중에도 사용할 수 있으며, Vercel 외부에서는 SDK가 Vercel 액세스 토큰 (access token)을 수락합니다. 어떤 방식이든, 앱 내에 유출되거나, 커밋되거나, 환경 간에 복사될 수 있는 제공자 비밀 값 (provider secret)은 존재하지 않습니다.

단일 에이전트 내에서도 모든 작업이 동일한 권한 범위를 가질 필요는 없습니다. 한 단계에서는 리포지토리 (repository)를 읽고, 다음 단계에서는 이슈 (issue)를 생성할 수 있습니다. 각 요청은 정확히 필요한 액세스 (access)만을 요청하며, 요청 자체가 제한 사항을 설정합니다. 요청에는 다음을 포함할 수 있습니다:

GitHub는 토큰을 특정 리포지토리 및 권한으로 제한할 수 있기 때문에 가장 명확한 예시입니다.

배포 에이전트는 해당 리포지토리 하나만 읽고 다른 작업은 수행하지 않을 수 있습니다. 세밀하게 설정된 GitHub App 설치 (install) 또한 범위를 좁힐 수 있지만, 설치는 한 번 설정되면 이후 계속 신뢰되는 상시 부여 (standing grant) 방식입니다. 이 제한은 단 하나의 요청, 하나의 작업에 대해서만 존재합니다. 최소 권한 (Least privilege) 원칙이 요청의 형태가 됩니다.

공유된 봇 토큰 (shared bot token)은 모든 사용자의 요청에 동일한 신원 (identity)과 권한 범위를 부여합니다. Vercel Connect를 사용하면 해당 신원을 직접 설정할 수 있습니다. 앱에서 특정 이름을 가진 사용자 (named user)로 전환하면, 토큰은 해당 사용자의 권한을 대행하며, 그 사용자가 승인한 범위 (scope) 내에서만 작동합니다. subject

사용자가 처음으로 액세스 권한을 부여할 때, 콜백 URL (callback URL), 웹훅 (webhook), 또는 디바이스 코드 (device code)를 통해 동의 흐름 (consent flow)을 실행합니다. 그 이후부터 에이전트 (agent)는 해당 사용자의 자격으로 토큰을 요청합니다. startAuthorization

커넥터 (connector)는 사용자가 선택한 프로젝트와 환경 (environments)에 연결되므로, 세 가지 환경 모두를 하나의 커넥터로 지정하는 대신 개발 (development), 프리뷰 (preview), 프로덕션 (production) 환경을 위해 각각 별도의 커넥터를 실행할 수 있습니다. 각 환경이 권한 부여 (authorization grant) 및 범위 (scopes)를 가진 고유한 커넥터를 가지게 되면, 개발 환경에서 유출된 자격 증명 (credential)이 프로덕션 환경에서 재사용되는 것을 방지할 수 있습니다.

별도의 커넥터를 사용하는 것은 자격 증명이 작동하는 범위를 제한하지만, 이미 발급된 액세스 권한을 회수하지는 못합니다. 보통 이 부분이 까다로운 지점입니다. 저장된 토큰 (stored token)의 경우, 이는 토큰 교체 (rotation)를 의미합니다. 새로운 비밀 값 (secret)을 생성하고, 기존 값이 사용되던 모든 곳을 업데이트한 뒤, 이에 의존하는 모든 것을 재배포해야 합니다. Vercel Connect를 사용하면, 본인의 토큰 또는 모든 토큰을 선택하여 커넥터의 토큰을 취소 (revoke)할 수 있습니다.

취소 (revoking)가 어떻게 작동하는지는 제공자 (provider)에 따라 다릅니다. 제공자가 취소를 지원하는 경우, Vercel Connect는 제공자 측에서 토큰을 취소합니다. 지원하지 않는 경우, Vercel Connect는 해당 권한 부여 (grant)에 대해 새로운 토큰 발급을 중단하며, 이미 발급된 토큰은 제공자 측에서 만료될 때까지 유효하게 유지됩니다. 이는 취소 API (revocation API)가 없는 모든 제공자에게 존재하는 실질적인 한계이며, 제공자가 토큰의 유효 기간을 짧게 유지할수록 이 노출 창 (window)은 줄어듭니다.

지금까지는 에이전트가 직접 요청을 보내는 방식이었습니다. 에이전트는 토큰을 요청하고, 작업이 필요할 때 서비스를 호출합니다. 트리거 (triggers)는 반대 방향으로 작동합니다. 연결된 서비스가 앱으로 이벤트를 보내면, 에이전트가 이에 응답합니다.

Vercel Connect는 제공자(provider)의 웹훅 (webhook)을 수신하고, 이를 검증한 뒤 귀하의 프로젝트로 전달합니다. 트리거 (trigger) 전달 기능은 현재 베타 버전이며, 현재 Slack, GitHub, Linear를 지원합니다. Slack 커넥터 (connector)는 검증된 웹훅을 최대 3개의 프로젝트로 전달할 수 있으므로, Slack의 메시지가 이를 처리하는 에이전트 (agent)를 깨울 수 있습니다.

이 흐름은 앱 내에 제공자 비밀키 (provider secret) 없이도 엔드 투 엔드 (end-to-end)로 실행됩니다:

Slack 서명 비밀키 (signing secret)는 사라지지 않습니다. 이는 서버 측의 Vercel Connect로 이동하여, 상위 웹훅 (upstream webhook)을 검증하고 귀하의 앱이 확인할 수 있는 신원(identity)으로 전달된 요청을 다시 서명합니다. 귀하의 앱은 실행을 위한 봇 토큰 (bot token)도, 검증을 위한 서명 비밀키 (signing secret)도 보유하지 않습니다.

모든 것의 밑바탕에는 단 하나의 호출이 있습니다. 귀하의 에이전트가 AI SDK를 기반으로 구축되었든, 백그라운드 작업 (background job)으로 실행되든, 혹은 직접 작성한 루프 (loop)이든 관계없이, .getToken을 통해 동일한 방식으로 토큰을 요청합니다. 해당 호출 주변에는 이미 사용 중인 스택을 위한 어댑터 (adapters)들이 있습니다. [Better Auth](https://www.better-auth.com/)와 [Auth.js](https://authjs.dev/)는 제공자 설정 (provider configs)을 기대하는 형태로 가져오며, @vercel/connect/ai-sdk와 @vercel/connect/mcp는 AI SDK 도구 (tools) 및 MCP 클라이언트 (clients)에 대해 동일한 역할을 수행합니다. [Nuxt starter](https://github.com/vercel-labs/nuxt-connect-starter)를 사용하면 GitHub와 Linear가 연결되어 있고, 제공자 비밀키 (provider secret)나 데이터베이스에 저장된 OAuth 리프레시 토큰 (refresh token) 없이도 바로 구축 가능한 앱을 가질 수 있습니다.

프레임워크는 이를 더 발전시켜 연결 자체를 선언적 (declarative)으로 만들 수 있습니다. Vercel의 오픈 소스 에이전트 프레임워크인 [eve](https://eve.dev/)에서는 연결이 하나의 파일이며, 어댑터 (@vercel/connect/eve)가 해당 연결의 자격 증명 (credential)을 제공합니다.

에이전트 코드 내에는 토큰 처리 로직이 없습니다. 왜냐하면 connect가 동의 흐름 (consent flow), 리프레시 (refresh), 그리고 에러 케이스 (error cases)를 eve에 매핑하기 때문입니다. OAuth를 지원하는 모든 MCP 서버는 URL을 통해 커넥터 (connector)가 될 수 있으며, 이를 통해 mcp.linear.app은 Slack이나 GitHub와 동일한 스코프 토큰 (scoped-token) 모델을 갖게 됩니다.

동일한 어댑터가 Slack 채널을 연결합니다. 단 한 번의 호출로 양방향을 모두 처리합니다: 전송을 위한 봇 자격 증명 (bot credentials)과 수신을 위한 웹후크 검증 (webhook verification)을 모두 포함합니다. connectSlackCredentials

Slack 연동 시 일반적으로 환경 변수에 보관하던 두 가지 비밀 값(secrets)인 SLACK_BOT_TOKEN과 SLACK_SIGNING_SECRET이 앱에서 사라집니다. 더 이상 프로비저닝(provision), 저장 또는 순환(rotate)할 것이 남아있지 않습니다.

에이전트는 더 많은 곳에 도달할 수 있을수록 더 유용해지며, 이것이 바로 접근 권한 (access)을 올바르게 설정해야 하는 이유입니다. 에이전트가 접촉할 수 있는 모든 시스템은 누군가가 유출된 토큰을 통해 접근할 수 있는 시스템이기도 합니다. 런타임 자격 증명 교환 (runtime credential exchange)을 사용하면, 모든 것을 위해 무언가를 프로비저닝할 필요가 없습니다. 모든 사용자가 무언가를 공유하지도 않습니다. 영원히 지속되는 것도 없습니다. 눈앞의 작업 범위를 벗어나 도달하는 것도 없습니다.

자격 증명 관리 (Credential management)는 과거에는 하나의 아키텍처였습니다. 그것은 순환 스크립트(rotation scripts), 환경 간에 복사되는 비밀 값, 그리고 아무도 유출하지 않기를 바라야 할 만큼 범위가 넓은 봇 토큰 (bot tokens)을 의미했습니다. 이제 당신은 그 어떤 것도 저장하지 않습니다. 에이전트가 필요한 순간, 해당 작업에 한정된 스코프 (scoped)로 접근을 요청합니다.

Vercel Connect로 빌드 시작하기

커넥터 (connector)를 등록하고, 첫 번째 런타임 토큰 (runtime token)을 요청하여, 제공자 비밀 값 (provider secret)을 저장하지 않고도 에이전트를 Slack 또는 GitHub에 연결하세요.

코딩 에이전트에게는 프롬프트 (prompt)만 있으면 됩니다:

Vercel Connect란 무엇인가요?

Vercel Connect를 사용하면 에이전트와 서비스가 사용자 및 팀을 대신하여 외부 시스템에 접근할 수 있습니다. 제공자 자격 증명 (provider credentials)을 수명이 긴 환경 변수 (environment variables)에 저장하는 대신, 프로젝트 수준의 접근 제어 (access controls)를 통해 런타임에 사용자 승인 토큰을 요청합니다.

Vercel Connect는 어떤 문제를 해결하나요?

에이전트가 외부 API에서 동작할 수 있도록 허용하면서도, 런타임에서 수명이 긴 제3자 비밀 값 (third-party secrets)을 제거합니다. 제공자를 위한 커넥터를 등록하고, 이를 프로젝트 및 환경에 연결한 다음, 런타임에 제공자 토큰을 요청하면 됩니다.

언제 Integrations 대신 Vercel Connect를 사용해야 하나요?

Vercel Marketplace에서 마켓플레이스 관리형 설치(marketplace-managed installs) 및 제공자 관리형 제품(provider-managed products)을 사용하는 경우에 사용하세요. Slack 워크스페이스에 대한 프로젝트 범위 내 액세스(project-scoped access)가 필요한 에이전트와 같이, 에이전트 워크플로(agent workflows)를 위한 위임된 런타임 자격 증명(delegated runtime credentials) 및 사용자 권한 부여(user authorization)가 필요한 경우 Vercel Connect를 사용하세요. Vercel Integrations

어떤 커넥터(connectors)를 사용할 수 있나요?

Vercel Connect는 일반적인 OAuth 및 API 키 커넥터를 지원하며, Slack, GitHub, Linear, Discord, Notion, Salesforce, Figma, Snowflake를 위한 전용 커넥터도 지원합니다. Resend, Workday, Microsoft Teams 등이 곧 추가될 예정입니다.

가격 책정 방식은 어떻게 되나요?

가격은 토큰 요청(token requests)을 기준으로 합니다. Hobby 플랜에는 추가 비용 없이 월 5,000회의 토큰 요청이 포함되어 있습니다. Pro 및 Enterprise 플랜에서는 토큰 요청 10,000회당 $3의 비용이 청구됩니다.

현재 베타 버전의 제한 사항은 무엇인가요?

트리거 전달(Trigger forwarding)은 Slack, GitHub, Linear로 제한되며, 커넥터 브랜딩 필드는 설정 후 완전히 삭제할 수 없습니다. 또한 토큰 취소(token revocation), 토큰 수명(token lifetime), 범위 세분성(scope granularity)은 제공자의 지원 여부에 따라 달라집니다.

더 읽어보기

커넥터를 한 번만 등록하면 프로젝트와 환경 전반에서 재사용할 수 있습니다

런타임에 범위가 지정된 토큰을 요청하세요

앱이 OIDC를 통해 자신의 신원을 증명합니다

각 토큰의 범위를 작업에 정확히 필요한 만큼만 제한하세요

사용자별 토큰 범위 지정(per-user token scoping)을 통해 특정 사용자를 대신하여 동작하세요

환경별로 액세스를 제한하고, 필요할 때 취소하세요

검증된 Slack 트리거를 통해 이벤트 기반 에이전트(event-driven agents)를 구동하세요

Vercel Connect는 코드가 이미 존재하는 곳에서 만납니다

액세스는 작업에 맞춰 범위가 지정되어 요청하는 것이 됩니다

자주 묻는 질문 (Frequently asked questions)

• 제공자 범위 (Provider scopes)

• 설치 ID (An installation ID)

• 리소스 제한 (Resource restrictions)

• 제공자별 권한 부여 세부 정보 (Provider-specific authorization details)

• 사용자가 Slack에 메시지를 게시합니다.

• Slack이 해당 이벤트를 Vercel Connect로 전송합니다.

• Vercel Connect는 보유하고 있는 Slack 서명 비밀값 (signing secret)을 통해 이벤트를 검증한 후, 자체 OIDC ID (identity)로 재인증 (re-attested)하여 귀하의 Vercel 앱으로 전달합니다.

• 귀하의 앱은 해당 인증 (attestation)을 검증한 다음, 범위가 지정된 런타임 토큰 (scoped runtime token)을 요청합니다.

• 에이전트 (agent)가 동작하고 응답합니다.