Vercel이 2026년 4월 내부 일부 시스템에 대한 무단 접근이 있었다고 공개했다. 회사는 조사와 대응을 진행 중이며, 영향받은 고객은 제한된 일부라고 밝혔고 서비스는 계속 운영 중이라고 설명했다.12 문제는 여기서 끝나지 않는다. 클라우드 플랫폼 침해 소식을 들었을 때 정말 중요한 질문은 "사고가 있었나?"보다 "내 구조에서 공격자가 어디까지 닿을 수 있나?"다.
지금 이 이슈가 중요한 이유도 같다. 많은 팀이 Vercel 같은 플랫폼을 단순 호스팅이 아니라 배포, 환경변수, 프리뷰 URL, 팀 권한, Git 연동까지 묶인 운영 허브로 쓰고 있기 때문이다. 같은 침해라도 어떤 팀은 거의 영향이 없고, 어떤 팀은 비밀키 회전과 계정 감사, 배포 동결까지 바로 들어가야 한다.
먼저 따져야 할 것: Vercel이 뚫렸다면 내 앱에서 어디까지 닿나
현재 확인된 사실은 제한적이다. Vercel은 "일부 내부 시스템"에 대한 무단 접근을 인정했고, 전체 고객이 아니라 "제한된 일부 고객"이 영향받았다고 했다.1 다만 공개된 문구만으로는 공격자가 코드, 환경변수, 빌드 로그, 팀 세션, 연동 토큰 중 어디에 접근했는지 일반 고객이 판단하기 어렵다. 그래서 사용자 커뮤니티와 Hacker News에서는 "환경변수를 검토하라"는 조언만으로는 실행이 어렵다는 반응이 나왔다.3
실무에서는 막연한 불안 대신 노출면을 항목별로 쪼개 봐야 한다. 예를 들어 정적 마케팅 사이트라면 위험은 주로 팀 계정과 도메인 설정 쪽에 몰린다. 반면 SaaS 앱이 Vercel 환경변수에 DB 비밀번호, Stripe 키, OAuth 시크릿, 내부 API 토큰을 넣어뒀다면 이야기가 달라진다. 특히 프리뷰 배포가 운영과 같은 비밀값을 공유하거나, 빌드 과정에서 민감값이 로그에 남는 구조면 피해 반경이 커진다.
여기서 핵심은 "호스팅 제공자" 자체보다 "그 플랫폼이 내 운영 체계의 몇 퍼센트를 들고 있느냐"다. 배포만 맡긴 상태와, 배포·비밀관리·권한관리·Git 인증이 한곳에 묶인 상태는 리스크가 전혀 다르다.
breach가 났다고 바로 떠나야 할까: 서비스 유형별 판단 기준
사고가 났다는 사실만으로 즉시 이전을 결정하는 건 대개 좋은 판단이 아니다. 더 현실적인 기준은 세 가지다. 내 앱이 얼마나 민감한 데이터를 다루는지, Vercel에 얼마나 많은 권한을 집중시켰는지, 그리고 내가 보완 통제를 얼마나 빨리 붙일 수 있는지다.
정적 사이트나 개인 프로젝트라면 과잉 반응보다 비밀값 정리, 팀 계정 MFA 점검, Git 연동 토큰 재검토가 우선일 수 있다. 반대로 고객 데이터 경로가 복잡한 SaaS, 엔터프라이즈 계약이 걸린 서비스, 규제 준수가 중요한 앱이라면 판단이 더 엄격해야 한다. 이 경우 "계속 쓸 것인가"보다 "외부 시크릿 매니저 분리, 최소권한 재설계, 프리뷰-운영 분리, 사고 통지 기준 정립이 가능한가"를 먼저 봐야 한다.
반론도 있다. Vercel은 평소에도 공급망 이슈나 프레임워크 취약점에 대해 차단 룰과 WAF 대응을 빠르게 배포해 왔고, Trust Center에서 PCI SAQ-D, TISAX 같은 컴플라이언스 자료도 제공한다.456 즉 "한 번 사고가 났다 = 보안이 약하다"로 단순화하는 것도 위험하다. 다만 컴플라이언스나 빠른 대응이 내 아키텍처의 과도한 비밀 집중까지 해결해 주지는 않는다. 이건 고객 책임 영역이다.
숨은 위험은 호스팅보다 시크릿 확산이다
이번 공지에서 Vercel이 모든 고객에게 환경변수 점검과 민감 환경변수 기능 사용을 권고한 대목은 눈여겨볼 만하다.1 이는 적어도 많은 팀이 아직도 플랫폼 안에 강한 권한의 비밀값을 넓게 펼쳐두고 있다는 뜻으로 읽힌다.
실제로 Vercel은 최근 axios 공급망 공격 때도 빌드 환경에 노출됐을 수 있는 API 키, DB 자격증명, 토큰 회전을 권고했다.7 이건 좋은 비교 사례다. 직접 침해든 공급망 경유든, 실제 피해는 대개 "호스팅이 깨졌다"보다 "빌드와 배포 주변에 비밀이 너무 많았다"에서 커진다.
여기에 계정 리스크도 있다. 커뮤니티에는 GitHub OAuth로 로그인하는 계정에서 비인가 2FA가 설정돼 운영 백엔드 접근을 잃었다는 사례가 올라왔다.8 개별 계정 사건을 이번 침해와 직접 연결할 근거는 없다. 다만 플랫폼 계정 하나가 운영 배포와 비밀값 접근을 함께 쥐고 있으면, 계정 탈취든 플랫폼 사고든 결과는 비슷해진다. 즉 단일 로그인 경로, 공유 팀 계정, 과도한 Owner 권한은 평소엔 편하지만 사고 때는 폭발 반경을 키운다.
사고 후 48시간, 팀이 실제로 해야 할 일
지금 필요한 건 공포가 아니라 순서다.
우선 Vercel에 저장된 운영 비밀값 목록을 뽑아야 한다. DB, 결제, 이메일, OAuth, 내부 API, CI/CD 토큰처럼 외부 시스템으로 이어지는 값부터 회전 우선순위를 정한다. "민감 환경변수" 표시만으로 충분하지 않다. 이미 노출됐을 가능성을 배제할 수 없으면 교체가 원칙이다.17
그다음 팀 접근을 본다. SSO, GitHub 연동, 개인 액세스 토큰, CLI 로그인 세션, Owner 권한 사용자를 확인한다. 최근 빌드 기록과 배포 변경, 알 수 없는 프로젝트 수정도 같이 본다. 고객 데이터가 프리뷰 환경이나 빌드 과정에 닿는 구조라면 일시적으로 위험한 릴리스를 멈추는 편이 낫다.
마지막은 의사결정이다. 남을지 떠날지가 아니라, 남는다면 무엇을 분리할지 정해야 한다. 시크릿은 외부 vault로, 운영 데이터는 프리뷰에서 분리, 배포 권한은 최소화, 장애·침해 시 고객 공지 템플릿은 사전 준비. 이 정도가 안 되면 플랫폼 선택 문제가 아니라 운영 성숙도 문제다.
이번 사건에서 아직 모르는 것은 많다. 그래서 더더욱 과장된 유출설이나 소셜 미디어의 뜨거운 반응보다, 내 서비스의 실제 노출 경로를 도식화하는 일이 먼저다. Vercel을 쓰는 스타트업 창업자, 운영 엔지니어, 보안 담당자가 지금 봐야 할 기준은 단순하다. "이 플랫폼이 침해되면 우리에게서 정확히 무엇이 빠져나갈 수 있는가." 그 질문에 바로 답할 수 없다면, 이번 뉴스는 남의 일이 아니다.
참고
1Vercel April 2026 security incident
2Vercel Says Internal Systems Hit in Breach
3Vercel April 2026 security incident | Hacker News
4Summary of CVE-2026-23869 - Vercel
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.