Vercel MCP 연결, 로고보다 hostname부터: CIMD 승인 판단표

새 AI 도구를 Vercel 프로젝트에 연결하려는데, 도구가 기존 지원 목록에 없으면 어떻게 해야 할까? 이번 변경은 그 입구를 넓힌다. Vercel의 발표에 따르면 사전 검토와 허용 목록 등록을 거치지 않은 MCP 클라이언트도 이제 연결을 요청할 수 있다. 그렇다고 계정 접근이 자동 허용되는 것은 아니다. 사용자는 여전히 로그인하고 각각의 연결을 승인한다.

핵심은 ‘연결을 요청할 수 있다’와 ‘믿고 접근을 허용해도 된다’를 분리하는 것이다. 미검토 클라이언트에는 Vercel 검증 배지가 붙지 않는다. 익숙한 이름이나 로고만 보지 말고, 동의 화면에 표시되는 메타데이터 제공 hostname과 요청 권한, 선택한 팀을 함께 읽어야 한다. 이 글은 공식 변경 사항을 정리하고, 실제 승인 여부에 활용할 판단표를 제시한다.

1. 바뀐 것은 클라이언트 식별 경로다

기존에는 Vercel이 클라이언트와 redirect URI를 수동으로 검토해 허용 목록에 올렸고, 목록 밖의 요청은 거절했다. 새 경로에서는 클라이언트가 자기 도메인에 Client ID Metadata Document, 줄여서 CIMD라는 JSON 문서를 제공한다. 그리고 그 문서의 HTTPS URL을 OAuth의 client_id로 사용한다. Vercel은 이것이 MCP authorization 명세의 CIMD 권고를 따른다고 설명한다.

여기서 두 URL의 역할을 혼동하면 안 된다. 공식 MCP 서버의 주소는 https://mcp.vercel.com 이다. 반면 CIMD URL은 연결을 요청하는 클라이언트의 메타데이터 주소다. 서버 주소가 공식이라는 사실만으로, 그 서버에 접근하려는 모든 클라이언트가 Vercel의 검토를 받았다는 결론을 낼 수는 없다.

클라이언트의 CIMD 제공, HTTPS client_id, 사용자 승인과 접근 범위를 순서로 분리한 흐름도

새 식별 경로가 사용자 승인을 대체하지 않는다. 접근 범위는 별도 조건의 영향을 받는다. 공식 본문 기반 설명도이며 실제 연결 결과가 아니다. 출처: vercel.com/changelog/vercel-mcp-now-supports-client-id-metadata-documents.

이 변경은 MCP 자체를 새로 만드는 기능도, 모든 권한을 일괄 부여하는 기능도 아니다. 연결 식별 경로의 변화다. 실제 사용 가능한 도구와 접근은 서버 설정, 클라이언트에 부여한 OAuth grant, 팀 권한의 영향을 받는다고 공식 문서는 명시한다. 따라서 연결 성공 여부와 허용 범위는 별도로 확인해야 한다.

2. 동의 화면에서 이름·로고와 hostname을 나눠 읽기

공식 발표는 미검토 클라이언트의 이름, 로고, 메타데이터 문서를 제공하는 hostname을 동의 화면에서 보여 준다고 설명한다. CIMD 클라이언트에는 Vercel verified 배지가 없으므로, 사용자가 승인할 때 신뢰하는 단서는 그 hostname이라는 설명도 덧붙인다. 이름과 로고가 화면에 나온다는 사실 자체는 Vercel이 해당 클라이언트를 검토했다는 증거가 아니다.

이름과 로고를 검토 증거로 오인하지 않고 hostname과 권한 및 팀을 함께 읽도록 비교한 도식

표시된 이름·로고와 공급자 검토는 다르다. 미검토 CIMD에는 Vercel 검증 배지가 없다는 발표를 비교도식으로 정리했다. 출처: vercel.com/changelog/vercel-mcp-now-supports-client-id-metadata-documents.

이를 실무 판단으로 옮기면, 먼저 자신이 설치하거나 사용하려던 도구의 운영 주체와 표시된 hostname이 맞는지 비교하는 편이 합리적이다. 이름과 로고가 익숙해도 메타데이터 hostname이 예상한 운영 주체와 다르면 승인을 보류한다. 다만 hostname이 예상과 일치한다는 이유만으로 모든 보안 문제가 해소되는 것은 아니다. 아래 표는 공식 설명에서 도출한 편집상 판단 기준이며, 공격 차단 효과를 실험한 보안 제품 평가가 아니다.

3. 승인 전에 사용할 상황별 판단표

지금 보이는 상황 이 정보로 말할 수 있는 것 다음 판단
처음 보는 클라이언트가 CIMD로 연결을 요청한다 사전 허용 목록에 없어도 요청할 수 있는 새 경로가 있다 요청한 도구의 운영 주체와 hostname을 비교한다
이름·로고는 익숙한데 hostname을 설명할 수 없다 표시된 이름·로고만으로 검토 여부를 증명하지 못한다 운영 주체를 확인할 때까지 승인을 보류한다
hostname은 예상과 맞지만 요청 권한이나 팀이 의도와 다르다 식별 단서와 실제 접근 범위는 서로 다른 질문이다 화면의 권한과 대상 팀을 다시 확인한 뒤 결정한다
원래 Vercel에 등록되어 있던 앱을 쓰고 있다 공식 발표는 기존 등록 앱이 바뀌지 않는다고 명시한다 이 발표만을 이유로 재등록이나 CIMD 전환을 강제하지 않는다
자체 클라이언트가 연결되지 않는다 CIMD만 준비했다고 모든 설정과 권한 조건이 충족되지는 않는다 문서 URL, redirect URI 조건, OAuth grant와 팀 권한을 구분해 점검한다
출처 불일치, 권한과 팀 불일치, 기존 앱 여부에 따른 승인 판단을 연결한 표

출처·접근 범위·기존 앱 여부를 분리하면 자동 승인과 불필요한 이관을 피하는 판단에 도움이 된다. 공격 차단 효과를 시험한 결과는 아니다. 출처: vercel.com/changelog/vercel-mcp-now-supports-client-id-metadata-documents.

예를 들어 같은 팀에서 새 에이전트를 시험하는 상황이라면 ‘연결할 수 있으니 일단 승인’보다 ‘어느 클라이언트가 어느 팀에 무엇을 요청하는가’를 먼저 묻는 것이 낫다. 이는 이번 발표에 없는 보안 기능을 추가로 주장하는 것이 아니다. 공식 동의 화면 설명에 포함된 출처 단서와 권한·팀 선택을 승인 판단의 순서로 재구성한 것이다. 실제 업무의 접근 정책이나 조직 승인을 이 표가 대신하지는 않는다.

4. 자체 클라이언트 작성자가 놓치기 쉬운 조건

개발자가 가장 먼저 볼 항목은 client_id에 넣는 값이다. 공식 문서는 클라이언트 메타데이터를 제공하는 HTTPS URL을 요구한다. 이 조건과 redirect URI의 허용 조건은 같지 않다. redirect URI에는 HTTPS, custom scheme, loopback 주소의 HTTP라는 경로가 문서에 제시된다. 따라서 ‘모든 redirect URI는 무조건 HTTPS’라는 설명도, ‘아무 HTTP 주소나 가능하다’는 설명도 정확하지 않다.

로고 조건도 부등호까지 읽어야 한다. 문서상 logo_uri는 PNG 또는 JPEG이며 100 KB 미만이어야 한다. 100 KB 이하와 미만은 다르다. 여기에 문서에 없는 고정 픽셀 크기나 별도 수치 제한을 덧붙이지 않는다. 이 글의 설명용 본문 그림은 OAuth 클라이언트 로고가 아니므로, 본문 PNG의 크기와 이 logo_uri 조건을 혼동하지 않아야 한다.

client_id는 HTTPS 메타데이터 URL, redirect URI는 세 허용 경로, 로고는 PNG JPEG 100 KB 미만임을 나눈 필드 도식

공식 문서의 필드별 조건을 분리했다. loopback HTTP의 범위를 일반 HTTP로 넓히거나 100 KB 미만을 이하로 바꾸면 안 된다. 이 조건은 본문 그림이 아닌 클라이언트 로고에 관한 것이다. 출처: vercel.com/docs/agent-resources/vercel-mcp.

공식 지원 클라이언트 목록에 포함되고 싶다면 문서의 client review form 경로를 확인할 수 있다. CIMD를 통한 연결 가능성과 지원 목록에 이름을 올리는 검토 절차는 같은 요구가 아니다. 기존 등록 앱은 그대로라는 발표까지 함께 읽으면, 모든 앱을 새 방식으로 급히 이관해야 한다는 오해를 줄일 수 있다.

5. 이번 발표로 단정하지 말아야 할 것

Vercel MCP는 모든 플랜에서 이용 가능하다고 공식 문서에 적혀 있고, 사용에는 Vercel AI Product Terms가 적용된다. 그러나 이것만으로 모든 외부 클라이언트나 회사 워크스페이스에서 연결이 허용된다고 말할 수는 없다. 모든 사용 비용이 0이라고 결론 내릴 근거도 아니다. 이 글은 제품별 과금 비교나 클라이언트 지원 상태의 전수 시험을 하지 않았다.

공식 문서에는 보안 권고도 있지만, 그 권고를 소개하는 것과 독립적으로 공격 저항성을 검증하는 것은 다르다. 이 글은 공식 본문을 분석한 판단 가이드이며, 실제 OAuth 연결이나 공격 재현, 보안 인증을 수행한 결과가 아니다. 실제 계정에 로그인하거나 설치 명령을 실행하지 않았으며, 이 글을 위한 프로젝트 배포나 권한 변경도 하지 않았다.

결론적으로 이번 변화는 ‘승인이 사라짐’이 아니라 ‘사전 검토 없이 요청 가능한 경로가 생김’이다. 클라이언트 작성자는 메타데이터와 redirect URI 조건을 분리해 준비하고, 승인하는 사용자는 이름·로고와 hostname, 요청 권한·팀을 서로 다른 확인 항목으로 읽으면 된다. 기존 등록 앱은 이 발표만으로 바뀌지 않는다.

함께 읽을 판단 경계

참고한 공식 자료

  • Vercel 변경 공지 — https://vercel.com/changelog/vercel-mcp-now-supports-client-id-metadata-documents
  • Vercel MCP 문서 — https://vercel.com/docs/agent-resources/vercel-mcp

근거는 2026년 11월 3일 아침 수집 시점에 본문과 해시를 동결한 공식 자료다. 변경 공지의 구조화 데이터상 최초 게시 시각은 2026년 11월 2일 20:09 UTC, 한국 시각으로 11월 3일 05:09이다. 자료 수집일과 이 글의 예정 공개일인 11월 4일은 구분한다. 이 원고의 로컬 검증은 게시나 예약 완료를 뜻하지 않는다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

이미지
1. --worktree 가 해결하는 충돌은 무엇인가 에이전트 두 개가 같은 저장소에서 동시에 파일을 고치면 가장 먼저 부딪히는 것은 모델이 아니다. 한쪽이 바꾼 작업 트리와 인덱스를 다른 쪽이 읽고, 테스트 산출물이 섞이고, 아직 정리하지 않은 변경을 다음 작업이 자기 입력으로 오해한다. OpenAI는 GitHub 기준 2026년 9월 9일 22:35 UTC, 한국 시각 10일 07:35에 공개한 Codex 0.154.0에 실험적 managed worktree 기능을 넣었다. 새 실행이나 기존 세션의 fork를 --worktree 로 시작할 수 있고, TUI에서는 /worktree 로 새 대화 또는 현재 대화의 fork를 별도 체크아웃에 둘 수 있다. 공식 릴리스 설명은 이를 "isolated checkouts"라고 부른다. 다만 이 표현을 저장소 전체와 외부 환경까지 격리한다는 뜻으로 읽으면 곤란하다. Git worktree가 분리하는 것은 체크아웃의 파일과 작업별 관리 상태다. Git 공식 문서에 따르면 연결된 worktree는 HEAD , index 같은 파일을 따로 갖지만 나머지 저장소 데이터는 공유한다. 따라서 같은 소스 파일을 동시에 편집하는 충돌은 줄일 수 있어도, 같은 원격 브랜치에 push하거나 같은 배포·테스트 데이터베이스를 건드리는 충돌까지 사라지지는 않는다. 그림 1. Codex 0.154 managed worktree는 체크아웃 생성과 thread 소유권을 연결한다. binding 전 실패 시 체크아웃을 보존한다. 출처: github.com/openai/codex/releases/tag/rust-v0.154.0 . 2. Codex는 새 체크아웃을 어떻게 만든다 0.154.0 태그가 가리키는 커밋의 codex-rs/worktree/src/lib.rs 를 보면 생성 순서가 꽤 보수적이다. 먼저 현재 HEAD 를 commit SHA로 확정한다. 그 SHA에서 git worktree add --detach --...
자세한 내용 보기

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

이미지
1. 잠금은 작업을 소비했다는 기록이 아니다 에이전트 작업자를 여러 개 띄웠다. 각 작업자는 PostgreSQL에서 FOR UPDATE SKIP LOCKED 로 작업 하나를 가져온다. 다른 작업자가 잡은 행을 기다리지 않으니 병렬 처리도 잘되는 것처럼 보인다. 그런데 커밋한 뒤 같은 작업이 다시 나온다면 무엇이 빠진 걸까? 핵심은 행을 잠갔다는 사실과 작업을 맡았다는 상태가 서로 다르다 는 점이다. PostgreSQL 공식 문서는 행 잠금이 트랜잭션 종료 때 풀린다고 설명한다. SKIP LOCKED 는 지금 즉시 잠글 수 없는 행을 건너뛰는 옵션이지, 그 작업을 영구히 큐에서 제거하는 명령이 아니다. 공식 PostgreSQL 18.0 소스의 회귀 테스트에도 이 차이가 드러난다. 상태를 바꾸지 않고 조회만 하는 순서에서 세션 A가 작업 1을 잠그면 B는 작업 2를 받는다. A가 커밋한 뒤 B가 다시 조회하면 작업 1이 나온다. 프로젝트가 저장한 기대 출력과 별도로, 이번 글에서는 PostgreSQL 16.2의 격리된 로컬 DB 에서도 이 순서를 실제 확인했다. 문서와 고정 소스는 18 계열, 직접 실행한 엔진은 16.2다. 두 버전을 같은 실험으로 섞거나 최신 버전의 성능 측정이라고 부르지 않는다. 그림 1. 잠금이 해제돼도 작업 상태가 그대로면 같은 작업이 다시 선택된다. 공식 18.0 기대 출력과 별도 16.2 로컬 확인에 근거한 자체 도식. 출처: www.postgresql.org/docs/18/sql-select.html . 조회 결과가 0행일 때도 해석에 주의해야 한다. 모든 후보가 다른 작업자에게 잠겨 있으면 SKIP LOCKED 는 아무것도 반환하지 않을 수 있다. 로컬 확인에서는 일반 조회로 보이는 행이 2개인데 잠금 건너뛰기 조회는 0행이었다. 따라서 “지금 가져올 작업이 없다”와 “큐 자체가 비었다”는 같은 말이 아니다. 공식 문서 역시 이 옵션이 일반적인 일관된 조회에는 적합하지 않고, 큐와 비슷한 테이블의 여러 소비자 사이 경합을...
자세한 내용 보기

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다

이미지
코딩 에이전트를 위한 문서를 만든다고 하면 보통 API 레퍼런스나 상세한 개발 가이드부터 떠올린다. 그런데 실제 에이전트의 작업 기록을 분석한 연구에서는 다른 문서가 훨씬 자주 등장했다. AGENTS.md , CLAUDE.md 같은 지시 파일과 계획·작업 노트였다. 2026년 8월 공개된 논문 From Agent Behaviour to Agent-Friendly Documentation 은 공개된 코딩 에이전트 세션과 풀 리퀘스트를 이용해 에이전트가 어떤 문서를 읽고 쓰는지 조사했다. 연구진이 분석한 데이터는 다음과 같다. SWE-chat의 파싱 가능한 세션 557개 개발 이벤트 94,813개 문서 관련 이벤트 3,033개 AIDev의 에이전트 풀 리퀘스트 33,097개 파일·커밋 단위 변경 기록 690,260개 에이전트가 가장 자주 만진 문서 문서 상호작용에서 가장 큰 비중을 차지한 것은 에이전트 지시 파일이었다. 문서 유형 이벤트 수 비중 에이전트 지시 파일 1,074 35.4% 계획·작업 노트 760 25.1% 작업 및 요구사항 문서 301 9.9% 설정 문서 205 6.8% README 197 6.5% API 레퍼런스 40 1.3% 지시 파일과 작업 노트를 합하면 전체 문서 상호작용의 60.5%다. API 레퍼런스는 1.3%에 그쳤다. 지시 파일이 API 레퍼런스보다 약 27배 많이 관찰된 셈이다. 코딩 에이전트의 문서 관련 이벤트 분포. 지시 파일과 계획·작업 노트가 전체의 60.5%를 차지했다. 출처: Gao & Chen, arXiv:2608.20195v1 . 이 수치를 "API 문서는 필요 없다"고 해석하면 곤란하다. 연구가 추적한 것은 저장소 안에서 명시적으로 열린 파일이다. 웹 문서, 모델이 이미 학습한 지식, 코드 주석, 런타임이 자동으로 주입한 문맥은 잡히지 않는다. 정확한 결론은 코딩 에이전트가 저장소 안에서 작업할 ...
자세한 내용 보기