Vercel 보안 침해 사건, 우리가 쓰는 배포 플랫폼은 안전한가

무슨 일이 벌어진 걸까

프론트엔드 개발하시는 분들이라면 Vercel이라는 이름이 익숙하실 거예요. Next.js를 만든 회사이자, 한 번의 git push로 사이트가 세상에 배포되게 해주는 그 편리한 플랫폼이죠. 그런데 2026년 4월, Vercel이 보안 침해(breach)를 공식적으로 인정하는 사건이 발생했습니다. 더 충격적인 건 해커가 "우리가 훔친 데이터를 팔겠다"며 다크웹에 매물로 내놓았다는 점이에요.

Vercel은 침해 사실 자체는 인정했지만, 유출된 데이터의 범위와 성격에 대해서는 비교적 신중한 톤으로 발표했어요. 해커 측은 소스 코드, 환경 변수, 토큰, 일부 고객 정보가 포함돼 있다고 주장했고, Vercel은 "일부 정보가 외부에 노출됐을 가능성을 확인했고 영향 범위를 조사 중"이라는 식으로 답했습니다. 정확한 규모는 아직 진행형이지만, 만약 환경변수나 API 토큰이 빠져나갔다면 이 사건의 2차 피해가 훨씬 더 클 수 있어요.

왜 환경변수 유출이 무서운가

이 부분을 좀 풀어서 설명드릴게요. Vercel 같은 PaaS(Platform as a Service)에서는 보통 환경변수(Environment Variables) 라는 곳에 민감한 정보를 저장해둡니다. 데이터베이스 비밀번호, 결제 API 키(Stripe, Toss 등), JWT 시크릿, 외부 서비스 토큰 같은 것들이죠. 코드에 직접 박아두면 GitHub에 올라갔을 때 큰일 나니까, 별도로 안전한 보관함에 넣어두고 빌드·런타임에만 꺼내 쓰는 구조예요.

그런데 그 "안전한 보관함" 자체가 뚫렸다면 어떻게 될까요? 공격자가 내 Stripe 시크릿 키를 손에 넣으면 결제 위조가 가능하고, DB 접속 정보를 알면 사용자 데이터를 통째로 가져갈 수 있어요. 더 무서운 건 공격이 내 인프라에서 일어난 것처럼 보인다는 점입니다. 정상적인 토큰으로 정상적인 API를 호출하니까 로그상으로는 의심스럽지 않거든요. 그래서 이런 종류의 침해는 발견되기까지 몇 주, 몇 달이 걸리는 경우도 많아요.

비슷한 사건들과 업계 흐름

사실 SaaS 플랫폼의 보안 침해는 최근 몇 년간 계속 반복되고 있어요. 2022년 Okta 침해 사건(인증 회사가 뚫린 황당한 사례), 2023년 CircleCI 사건(CI/CD 플랫폼이 뚫리며 수많은 회사의 시크릿이 노출), 2024년 Snowflake 관련 대규모 자격증명 유출까지 — 공격자들이 점점 개별 기업이 아니라 공급망 위쪽의 플랫폼을 노리고 있어요. 한 곳을 뚫으면 수천, 수만 고객의 데이터에 동시에 접근할 수 있으니 ROI가 어마어마하니까요.

이런 흐름을 업계에서는 공급망 공격(supply chain attack) 이라고 부릅니다. 내가 아무리 보안을 잘 짜놨어도, 내가 의존하는 외부 서비스가 뚫리면 같이 무너지는 구조예요. 특히 Vercel처럼 빌드 환경에서 코드와 시크릿을 모두 다루는 플랫폼은 매력적인 표적일 수밖에 없습니다. CircleCI 사건 때도 정확히 같은 구조였고요.

한국 개발자라면 지금 뭘 해야 할까

Vercel을 쓰고 있다면 일단 차분하게 몇 가지를 점검해보시는 걸 권합니다. 첫째, 모든 환경변수에 들어 있는 시크릿을 회전(rotate) 해주세요. 데이터베이스 비밀번호, 외부 API 키, OAuth 클라이언트 시크릿, 결제 API 키까지 전부요. 귀찮지만 이번 사건에 한해서는 "우리는 영향 없을 거야"라고 가정하지 않는 게 안전합니다.

둘째, 액세스 토큰과 배포 후크(Deploy Hook) URL 도 갈아주세요. Vercel 팀 대시보드의 토큰들 말이에요. 셋째, 로그를 거꾸로 훑어보면서 이상한 배포나 알 수 없는 환경변수 변경 이력이 있는지 확인하세요. 넷째, 가능하면 시크릿 관리를 Vercel 환경변수에만 의존하지 말고 Vault나 AWS Secrets Manager 같은 외부 시크릿 매니저와 연동해서, 런타임에만 짧은 수명의 토큰을 발급받는 구조로 옮겨가는 것도 장기적으로 좋습니다.

그리고 더 근본적으로는, 우리가 쓰는 모든 SaaS에 대해 "이 업체가 내일 뚫리면 나는 뭘 잃나?" 라는 질문을 한 번씩 해보는 게 필요해요. GitHub, Vercel, Supabase, Cloudflare, Sentry — 각각 어떤 시크릿과 어떤 데이터를 들고 있는지 알고 있어야 사고가 났을 때 빠르게 움직일 수 있습니다.

마무리

클라우드와 PaaS는 우리에게 엄청난 생산성을 줬지만, 동시에 우리의 보안을 외주화한 측면도 있어요. 이번 Vercel 사건은 그 외주의 위험이 현실로 드러난 사례입니다. 결국 "편한 만큼 의존도가 커지고, 의존도가 큰 만큼 한 번의 사고가 치명적이다"라는 오래된 교훈을 다시 확인하게 되네요.

여러분의 팀은 외부 SaaS 침해 시나리오에 대한 대응 플레이북이 준비돼 있나요? 시크릿 회전을 자동화해두셨나요? 이번 일을 계기로 한 번쯤 점검해보면 좋을 주제 같습니다.