v0에서 사내 디자인 시스템을 그대로 재사용하는 법

v0는 이제 팀이 이미 비용을 들여 구축한 비공개 디자인 시스템과 컴포넌트 라이브러리를 직접 사용할 수 있습니다. 따라서 나중에 엔지니어가 다시 교체해야 할 복제품이 아니라 실제 컴포넌트로 프로토타입을 시작할 수 있습니다. Vercel은 2026년 9월 18일 17:00 UTC에 자격 증명 연결 방식을 출시했습니다. 공유 Development 또는 Preview 환경 변수를 통해 v0에 NPM_TOKEN이나 NPM_RC를 제공하면, 자격 증명이 모델에 노출되거나 샌드박스 파일 시스템에 기록되지 않은 채 패키지를 설치할 수 있습니다.

변경은 작지만, 핸드오프 효과는 큽니다

비공개 npm 패키지는 다운로드 권한을 확인하는 레지스트리를 통해 배포되는 JavaScript 또는 TypeScript 코드입니다. 팀은 디자인 시스템 컴포넌트, 토큰, 인증 헬퍼, 애널리틱스 래퍼, 내부 유틸리티 등을 비공개 패키지로 관리합니다.

이번 릴리스 전까지는 레지스트리의 권한 확인 단계에서 v0 워크플로가 막혔습니다. 공개 패키지는 그대로 설치할 수 있었지만, 비공개 컴포넌트 라이브러리는 아카이브를 업로드하는 등의 우회 방법이 필요했습니다. 그렇지 않으면 검토용으로 얼추 비슷한 새 컴포넌트를 만들어야 했습니다. 두 번째 방법은 데모할 때는 빨라 보이지만, 코드가 실제 저장소에 들어가는 순간 교체 작업을 남겼습니다.

v0의 새로운 방식은 인증을 샌드박스 경계로 옮깁니다. v0는 Vercel Sandbox에서 저장소가 기존에 사용하던 패키지 매니저를 실행합니다. 비공개 레지스트리로 설치 요청이 나갈 때 Vercel이 네트워크 경계에서 자격 증명을 적용합니다. 모델과 에이전트는 그 값을 읽을 수 없고, 로컬 .npmrc 파일에도 값이 기록되지 않습니다.

이 차이가 핵심입니다. 패키지는 빌드에 들어오지만, 시크릿은 프롬프트나 파일 시스템에 들어오지 않습니다.

패키지에 접근할 수 있다고 해서 v0가 그 시스템의 올바른 사용법까지 알게 되는 것은 아닙니다. Button 컴포넌트를 가져와도 잘못된 변형을 고르거나, 프로바이더를 빠뜨리거나, 테마 래퍼를 놓칠 수 있습니다. 그래서 패키지와 함께 최신 문서, 예제, 실제 사용 앱을 제공해야 합니다. 코딩 에이전트에 디자인 시스템을 제공하는 방법에서 다룬 더 넓은 운영 원칙도 그대로 적용됩니다. 코드는 반복 가능한 동작을 담고, 가이드는 판단 기준을 전달합니다.

디자인 시스템 재사용의 비용 효과는 컴포넌트 교체에서 나옵니다

비즈니스 관점에서 중요한 변화는 패키지 설치가 빨라진다는 데 있지 않습니다. 프로토타입 승인과 프로덕션 작업 사이에 끼어 있던 별도의 재구축 단계를 없앨 수 있다는 데 있습니다.

v0가 비슷하게 생긴 컴포넌트를 새로 만들면 프로토타입과 제품의 정체성이 달라집니다. 엔지니어링 팀은 임포트를 교체하고, 프롭을 다시 연결하고, 테마 컨텍스트를 복구하고, 각 상태를 재검증해야 합니다. 승인된 화면이 왜 달라졌는지도 설명해야 합니다. 처음부터 실제 패키지를 사용하면 핸드오프가 재구축이 아니라 검토와 개선 과정이 될 수 있습니다.

다음은 Vercel의 벤치마크가 아니라 계산을 위한 가정입니다. 기존에는 프로토타입 하나당 컴포넌트 교체에 4시간이 걸렸다고 해보겠습니다. 엔지니어링 시간의 가치를 시간당 $100로 잡고, 자격 증명 설정과 검증에 1시간이 든다면 절감되는 시간은 3시간, 금액으로는 $300입니다.

이 절감액이 보장되는 것은 아닙니다. 패키지 설정이 잘못됐거나 프로바이더가 빠졌거나 사용 가이드가 부실하면 다른 단계에서 같은 3시간을 소모할 수 있습니다. 실제 컴포넌트로 저장소 변경 내역과 수정 시간을 측정한 뒤, 그 결과를 바탕으로 이 워크플로를 유지할지 판단해야 합니다.

공개 패키지만 사용하는 팀에는 영향이 없습니다. 저장소로 옮길 계획이 없는 일회성 콘셉트 화면을 만드는 팀도 마찬가지입니다. 이 변화는 승인된 v0 프로토타입을 실제로 유지·보수할 소프트웨어로 이어갈 때 가장 큰 의미가 있습니다.

패키지가 있는 곳에 맞춰 자격 증명을 선택합니다

간단히 말하면 registry.npmjs.org의 비공개 패키지에는 NPM_TOKEN, 레지스트리 라우팅에는 NPM_RC를 사용합니다. 둘을 예비 수단처럼 동시에 추가하면 안 됩니다. 비공개 의존성 문서에 따르면 두 값이 함께 있을 때 NPM_RC가 우선합니다. 그러면 오래된 커스텀 설정이 정상적인 npm 토큰을 가릴 수 있습니다.

필요한 최소 권한으로 설정하는 방법

1. 1

   실제 패키지 하나를 선택합니다

   프로덕션 저장소에서 이미 사용하는 컴포넌트로 시작합니다. 그러면 검증된 임포트, 예상 가능한 시각적 결과, 확인할 가치가 있는 실제 핸드오프를 확보할 수 있습니다. 데모 전용 패키지로도 인증 작동 여부는 확인할 수 있지만, 재작업이 줄어드는지는 증명할 수 없습니다.

2. 2

   공유 변수를 만듭니다

   Vercel에서 팀을 선택한 뒤 Settings, Environment Variables로 이동합니다. NPM_TOKEN 또는 NPM_RC를 공유 변수로 추가하고 Development, Preview 또는 둘 모두에 스코프를 지정합니다. 민감한 값으로 표시합니다.

   v0 문서에 따르면 이 설정을 관리하려면 Vercel Developer 이상의 역할이 필요합니다. 토큰에는 프로젝트가 설치하는 모든 비공개 패키지의 읽기 권한을 주되, 레지스트리가 요구하는 범위보다 넓게 부여하지 않아야 합니다.

3. 3

   커스텀 레지스트리를 연결합니다

   GitHub Packages의 경우 Vercel은 예시 @acme 스코프에 다음 NPM_RC 값을 안내합니다.

   @acme:registry=https://npm.pkg.github.com/
   //npm.pkg.github.com/:_authToken=${GITHUB_PACKAGES_TOKEN}

   GITHUB_PACKAGES_TOKEN은 별도의 공유 변수로 저장합니다. NPM_RC는 설치 중 ${VAR} 참조를 확장할 수 있으며, 참조된 값에도 동일한 자격 증명 보호가 적용됩니다. JFrog Artifactory에는 그에 맞는 레지스트리 URL과 토큰 변수를 사용합니다.

4. 4

   v0 연동 상태를 확인합니다

   v0에서 Settings, Integrations를 차례로 열고 npm을 찾습니다. v0는 지원되는 공유 변수를 자동으로 연결합니다. 앞서 선택한 컴포넌트를 설치하고 렌더링하도록 요청한 뒤, 프리뷰에 기대한 스타일, 프로바이더, 동작이 적용됐는지 확인합니다.

5. 5

   저장소 핸드오프를 점검합니다

   결과를 실제 저장소로 보냅니다. package.json, 잠금 파일, 임포트 경로, 프로바이더 설정, 전역 스타일, 소스 변경 내역을 검토합니다. 저장소에서 기존에 사용하던 검사도 실행합니다. 정상적으로 작동하는 프리뷰는 유용한 증거지만, 브랜치가 승인된 컴포넌트를 깔끔하게 사용하고 있어야 핸드오프가 끝난 것입니다.

내일부터 적용할 수 있는 네 가지 팀 시나리오

대시보드를 만드는 SaaS 제품 팀

제품 디자이너는 프런트엔드 팀이 실제로 배포하는 비공개 컴포넌트로 새 결제 흐름을 프로토타이핑할 수 있습니다. 생성 결과가 더 보기 좋아진다는 것이 핵심은 아닙니다. 실제 Button, Table, Modal의 동작을 놓고 승인 여부를 논의할 수 있고, 이후 소스 변경 내역도 줄어든다는 점이 중요합니다.

전사 v0 환경을 준비하는 디자인 시스템 리드

리드는 Design Systems 2.0 임포트를 시작하기 전에 비공개 패키지를 추가한 뒤, v0에 소스 저장소, 실제 사용 앱 하나, 최신 사용 문서를 제공할 수 있습니다. v0는 스타터를 만들고 시스템을 저장하기 전에 검토를 위해 멈춥니다. 리드는 이후 모든 대화에 같은 설정이 반영되기 전에 폰트, 프로바이더, 토큰, 폐기 예정인 컴포넌트 패턴을 한 번에 찾아낼 수 있습니다.

여러 레지스트리를 관리하는 에이전시 플랫폼 리드

에이전시는 프로토타입마다 토큰을 복사하는 대신 NPM_RC로 조직별 스코프를 올바른 레지스트리에 연결할 수 있습니다. 자격 증명을 통제된 방식으로 설정하고 고객별로 만든 유사 컴포넌트를 줄일 수 있다는 이점이 있습니다. 다만 고객 패키지마다 접근 경계를 분리하고 별도의 검토 절차를 운영해야 합니다.

GitHub Packages 또는 JFrog를 쓰는 엔터프라이즈 프런트엔드 팀

플랫폼 팀은 v0가 임포트된 저장소와 동일한 내부 의존성을 설치하도록 할 수 있습니다. 그러면 프리뷰가 더 솔직해집니다. 패키지 해석, 테마 설정, 임포트 관련 오류가 핸드오프 이후가 아니라 프로토타입 단계에서 드러납니다. 정책상 공유 자격 증명을 사용할 수 없다면 문서화된 .tgz 방식이 더 작은 파일럿이 될 수 있습니다.

접근 권한과 가격은 별개의 비용입니다

비공개 패키지 문서에는 이 기능을 위한 유료 v0 요금제나 별도 추가 옵션이 명시돼 있지 않습니다. 대신 권한 조건이 있습니다. 공유 변수를 관리하는 사람에게 Vercel Developer 이상의 역할이 필요합니다. Vercel의 역할 문서에 따르면 팀 수준 Developer 역할은 Pro와 Enterprise 플랜에서 제공됩니다.

이는 현재 v0 요금제와는 별개입니다. Free는 월 $0이며 월간 크레딧 $5와 일일 7개 메시지 제한이 있습니다. Plus는 사용자당 월 $30이며 사용자당 월간 크레딧 $30와 사용자당 일일 로그인 크레딧 $2를 제공합니다. Business는 사용자당 월 $100이며 표시된 크레딧 금액은 동일하고, 기본적으로 학습 제외가 적용됩니다. Enterprise 가격은 별도 협의입니다. 기존 Premium 플랜은 문서상 월 $20로 남아 있지만 종료 절차가 진행 중이며 신규 사용자는 가입할 수 없습니다.

Vercel Pro는 월 플랫폼 요금 $20에 배포용 좌석 한 개와 월간 사용 크레딧 $20를 포함합니다. 추가 Owner 또는 Member 좌석은 각각 월 $20입니다. 공개된 가격은 모두 세전 미국 달러 기준입니다.

예시로 v0 Plus 좌석 한 개와 Vercel Pro 플랫폼 요금을 합치면 세금과 사용량을 제외하고 월 $50입니다. 하지만 이것이 이 기능의 최저 가격이라는 뜻은 아닙니다. 릴리스 문서에는 두 유료 플랜이 모두 필요하다고 나와 있지 않으므로, 업그레이드하기 전에 현재 계정과 역할부터 확인해야 합니다.

분명히 알아야 할 한계

비공개 패키지 접근은 장벽 하나를 없앱니다. 그렇다고 컴포넌트 라이브러리가 완전한 디자인 시스템으로 바뀌거나, 생성된 코드가 곧바로 프로덕션 수준이 되거나, 패키지가 바뀔 때 기존 프로젝트까지 자동으로 갱신되는 것은 아닙니다.

실무에서는 다음과 같은 경계가 있습니다.

• Shared Environment Variables는 브랜치별 값을 지원하지 않습니다.
• NPM_RC와 NPM_TOKEN이 모두 있으면 전자가 우선합니다.
• 토큰은 선택한 패키지가 끌어오는 비공개 의존성을 포함해 프로젝트가 설치하는 모든 비공개 패키지를 포괄해야 합니다.
• 자격 증명이 보호되더라도 생성된 구현은 여전히 잘못될 수 있습니다.
• 프로바이더, 전역 CSS, 폰트, 토큰, 컴포넌트 상태, 테스트, 접근성, 검토는 여전히 핸드오프 과정에서 팀이 책임져야 합니다.

보안에 대한 약속은 범위가 좁지만 유용합니다. v0는 자격 증명을 모델이나 에이전트에 노출하지 않고, 샌드박스 파일 시스템에도 기록하지 않습니다. 다만 이 워크플로에서 레지스트리 토큰을 사용해도 되는지, 권한 범위를 얼마나 좁힐지, 토큰을 어떻게 교체할지는 각 회사가 결정해야 합니다.

월요일에 바로 할 일

팀에 이미 비공개 컴포넌트 패키지가 있고 v0 프로토타입을 정기적으로 저장소 작업으로 이어간다면 이번 주에 실행할 가치가 있습니다. 보안 책임자가 읽기 전용 레지스트리 자격 증명을 승인하지 않았다면 기다려야 합니다. 자격 증명을 공유할 수 없다면 제한된 파일럿에 .tgz 방식을 사용합니다. 공개 패키지만 쓰거나 v0 결과물을 일회성 콘셉트로 끝낸다면 이번 릴리스는 건너뛰어도 됩니다.

월요일에는 실제 비공개 컴포넌트 하나를 임포트합니다. 최소 범위의 읽기 전용 자격 증명을 Development에 넣고 npm 연동을 확인한 뒤, v0로 컴포넌트를 렌더링해 저장소로 넘깁니다. 의존성, 잠금 파일, 임포트, 프로바이더, 시각적 상태, 소스 변경 내역을 점검합니다. 그 컴포넌트가 유사품으로 교체되지 않고 핸드오프를 통과한다면 워크플로가 달라진 것입니다. 그다음 확장하기 전에 절감된 시간을 측정합니다.

다음 플랫폼 변화와 그에 따른 비즈니스 계산을 실무 관점에서 받아보려면 뉴스레터를 구독하세요.