Vercel이 4월 19일 내부 시스템에 대한 무단 접근 사실을 공개했습니다. 출발점은 Vercel 직원이 연결한 서드파티 AI 도구의 OAuth 권한이었고, 그 경로를 통해 일부 내부 환경과 민감 표시가 되지 않은 환경변수가 노출된 것으로 알려졌습니다.123 지금 중요한 이유는, 이 사건이 단순한 "호스팅 업체 사고"가 아니라 많은 팀이 프런트엔드 배포, 미리보기, Git 연동, 비밀값 관리까지 한 플랫폼에 몰아넣는 방식의 위험을 드러냈기 때문입니다.
특히 Vercel은 "Next.js 호스팅"이 아니라 개발 속도를 극대화하도록 설계된 강한 의견의 플랫폼입니다. 그래서 이번 사건을 볼 때 핵심 질문은 "Vercel이 좋은가?"가 아니라 "우리 팀이 이 정도의 집중된 신뢰를 감수할 만큼 Vercel의 속도와 DX가 필요한가?"입니다.
이번 사고에서 확인된 것과 아직 모르는 것
확인된 사실부터 정리하겠습니다. Vercel은 침해 원인을 Context.ai 관련 OAuth 경로로 설명했고, 공격자가 직원의 Google Workspace 계정을 발판으로 일부 Vercel 환경에 접근했다고 밝혔습니다.23 회사는 Next.js와 Turbopack, 오픈소스 프로젝트의 릴리스 경로는 영향받지 않았다고 했고, 영향을 받은 고객에게는 직접 자격 증명 회전을 권고했습니다.23
또 하나 중요한 포인트는 환경변수의 구분입니다. Vercel 설명에 따르면 고객 환경변수는 저장 시 암호화되지만, "sensitive"로 표시되지 않은 값은 공격자가 열람 가능한 방식으로 노출됐을 가능성이 있습니다.234 즉, "비밀값은 넣어뒀지만 분류를 느슨하게 했다"는 습관이 실제 위험으로 바뀐 셈입니다.
반면 아직 불확실한 부분도 있습니다. 공격자가 실제로 얼마나 많은 고객 데이터, GitHub 토큰, 소스코드, 데이터베이스 정보까지 빼냈는지는 공개 정보만으로 확정하기 어렵습니다. 일부 범죄 포럼 판매 글과 커뮤니티 제보는 있었지만, 이는 확인된 사실과 분리해서 봐야 합니다.25 실무에서는 이럴 때 "사실 여부를 기다리자"보다 "노출 가능성이 있으면 먼저 회전한다"가 맞습니다.
Vercel이 파는 것은 서버가 아니라 '결정 축소'다
많은 스타트업이 "일단 Vercel에 올리자"로 시작합니다. 이유는 분명합니다. Git push 기반 배포, 프리뷰 배포, 글로벌 엣지 전달, 프레임워크 최적화, 대시보드 중심 운영까지 한 번에 제공하기 때문입니다.67 특히 Next.js 기반 마케팅 사이트, 콘텐츠 사이트, 초기 SaaS 프런트엔드에서는 이 조합이 엄청나게 빠릅니다.
이때 팀이 실제로 사는 것은 인프라 자체보다 "덜 고민해도 되는 상태"입니다. CDN 구성, 프리뷰 인프라, 배포 파이프라인, 프런트엔드 중심 운영의 많은 결정을 플랫폼이 대신 가져갑니다. 작은 팀일수록 이 효과는 큽니다. DevOps 인력이 부족한 3~10명 규모 팀이라면, Vercel 덕분에 제품 출시 속도가 체감될 정도로 빨라질 수 있습니다.
하지만 이번 사고는 그 장점의 반대편도 보여줍니다. 배포, Git 연동, 환경변수, 관측, 팀 협업이 하나의 제품 경험으로 엮일수록, 침해 시 영향 반경도 넓어집니다. Hacker News 반응이 다소 과격하긴 했지만, "하나의 OAuth 토큰이 너무 많은 것을 연결한다"는 비판 자체는 곱씹어볼 만합니다.5
숨은 비용은 요금표보다 운영 모델에 있다
Vercel의 진짜 비용은 월 요금만이 아닙니다. 첫째는 락인입니다. Next.js 자체는 오픈소스지만, 실제 운영에서는 프리뷰 배포, 플랫폼별 함수 동작, 이미지 최적화, 엣지 기능, 환경변수 워크플로우에 익숙해질수록 다른 플랫폼으로 옮기는 비용이 커집니다.
둘째는 디버깅과 책임 경계입니다. 자체 호스팅이면 느려도 어디를 봐야 할지 비교적 명확합니다. 반면 Vercel 같은 플랫폼은 많은 것을 추상화해 주는 대신, 문제가 생겼을 때 "우리 앱 문제인지, 플랫폼 설정인지, 연동 문제인지" 경계가 흐려질 수 있습니다. 편한 날엔 큰 장점이지만, 장애나 보안 사고 때는 반대로 작동합니다.
셋째는 보안 습관의 약화입니다. 플랫폼이 너무 편하면 팀이 비밀값 분류, OAuth 권한 최소화, GitHub 앱 권한 범위, 배포 경로 분리 같은 기본기를 덜 엄격하게 다루기 쉽습니다. 이번 사고도 결국 기술 하나의 실패라기보다, AI 도구 연동·OAuth 권한·내부 접근·환경변수 관리가 한 줄로 이어진 문제에 가깝습니다.34
그래서 누가 Vercel을 써야 하고, 누가 거리를 둬야 하나
Vercel이 잘 맞는 경우는 분명합니다. Next.js 중심의 마케팅 사이트, 문서 사이트, 콘텐츠 서비스, 초기 제품 검증 단계의 SaaS 프런트엔드입니다. 팀이 작고, 출시 속도가 가장 중요하고, 규제·감사 요구가 낮다면 Vercel은 여전히 매우 강한 선택지입니다.
반대로 API 비중이 높고, 장시간 실행 작업이 많고, 네트워크 제어·감사 추적·권한 분리가 중요한 서비스라면 전부를 Vercel에 얹는 판단은 더 신중해야 합니다. 특히 핀테크, 헬스케어, 엔터프라이즈 B2B, 크립토처럼 자격 증명 하나의 가치가 큰 분야는 더 그렇습니다.4 이런 경우 현실적인 절충안은 "프런트엔드만 Vercel, 핵심 백엔드와 비밀값 관리는 별도"입니다.
결국 이번 사건이 바꾼 것은 Vercel의 성능이 아니라, 평가 기준입니다. 앞으로는 "배포가 얼마나 쉬운가"만 볼 게 아니라 "이 플랫폼이 우리 팀의 신뢰 구조를 어떻게 재편하는가"를 같이 봐야 합니다. 지금 Vercel을 쓰는 팀이라면 sensitive 환경변수 사용, OAuth 앱 점검, GitHub 연동 권한 축소, 비밀값 회전 절차부터 다시 확인해야 합니다. 아직 도입 전인 팀이라면, Vercel을 기본값이 아니라 전략적 선택으로 보길 권합니다.
참고
1Cloud development platform Vercel was hacked
2App host Vercel says it was hacked and customer data stolen
3Vercel breached via compromised third-party AI tool
4Hack at Vercel sends crypto developers scrambling to lock down API keys
5Vercel April 2026 security incident | Hacker News
6Vercel: Build and deploy the best web experiences with the AI Cloud
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.