Hacker News 2026.04.20 25

Vercel 2026년 4월 보안 사고: 무슨 일이 있었고 우리는 뭘 배워야 할까요

Vercel에서 무슨 일이 있었나요?

프론트엔드 개발자라면 Vercel을 모르는 분은 거의 없을 거예요. Next.js 만든 회사이자, GitHub에 푸시하면 알아서 빌드하고 배포해주는 그 편한 호스팅 플랫폼 말이에요. 그런 Vercel이 2026년 4월에 보안 사고가 있었다고 공식적으로 발표했어요. 이게 왜 중요하냐면, Vercel은 수많은 스타트업과 기업의 프로덕션 사이트를 호스팅하고 있고, 환경 변수에 API 키, 데이터베이스 비밀번호, 토큰 같은 민감한 정보가 잔뜩 들어 있거든요. 인프라 제공자에서 사고가 나면 거기 올라간 모든 고객에게 영향이 갈 수 있어요.

오늘 글에서는 보안 사고가 일반적으로 어떻게 일어나고, 이런 상황에서 사용자 입장에서 뭘 점검해야 하는지를 정리해보려고 해요. 공식 발표의 디테일이 계속 업데이트되고 있는 만큼, Vercel을 쓰고 계시다면 공식 보안 게시판을 직접 한 번 더 확인하시는 걸 추천드려요.

SaaS 인프라 보안 사고는 보통 이렇게 일어나요

클라우드/PaaS 보안 사고의 패턴은 몇 가지로 좁혀져요. 첫째는 공급망 침해예요. 회사 내부에서 쓰는 라이브러리나 빌드 파이프라인 도구가 오염되면, 거기서 생성된 모든 결과물에 악성 코드가 섞일 수 있어요. 작년에 있었던 여러 npm 패키지 탈취 사건이 대표적이죠.

둘째는 권한 상승 취약점이에요. 멀티테넌트(multi-tenant, 여러 고객이 같은 인프라를 공유하는 구조) 환경에서는 "A 고객이 B 고객의 데이터를 볼 수 있는" 버그가 가장 무서워요. 빌드 환경이 격리(isolation)가 제대로 안 되어 있거나, API 라우팅에서 테넌트 ID 검증이 빠지면 발생할 수 있어요.

셋째는 내부자 또는 자격증명 탈취예요. 직원의 노트북이 털리거나, 깃허브 액세스 토큰이 유출되면 공격자가 합법적인 사용자처럼 들어와서 데이터를 빼낼 수 있어요. 작년 Okta, Cloudflare 사고도 비슷한 결로 시작됐어요.

Vercel처럼 빌드와 배포를 대신해주는 플랫폼은 "고객의 소스코드와 환경 변수, 빌드 산출물"을 모두 다루기 때문에 위 세 가지 모두에 노출돼 있어요. 그래서 사고 발생 시 영향 범위를 정확히 파악하는 게 정말 중요해요.

사용자가 지금 당장 점검할 것들

Vercel을 쓰고 계신 팀이라면 다음을 한 번 점검해보시는 걸 권해요. 사고와 무관하게 평소 좋은 습관이기도 해요.

첫째, 환경 변수에 들어 있는 시크릿 회전. 사고 기간 동안 노출 가능성이 있다면 데이터베이스 비밀번호, 외부 API 키, JWT 시크릿 같은 걸 새 값으로 바꾸는 게 안전해요. 시크릿 회전(secret rotation)이라는 게 별 거 아니고, 그냥 "기존 키 폐기하고 새로 발급해서 환경 변수 갈아끼우기"예요.

둘째, GitHub/GitLab 통합 권한 재확인. Vercel은 깃 저장소에 접근하기 위해 OAuth 앱이나 GitHub App 권한을 받아 가요. 이 권한 범위가 필요 이상으로 넓진 않은지 확인하고, 의심되면 한 번 끊었다가 다시 연결하는 것도 방법이에요.

셋째, 배포 로그와 빌드 산출물 점검. 평소와 다른 빌드가 발생했는지, 외부로 나가는 네트워크 호출이 새로 추가되진 않았는지 확인하세요. CSP(Content Security Policy) 헤더가 설정돼 있다면 이상한 도메인으로 가는 요청을 잡을 수 있어요.

넷째, 2FA와 SSO 강제. 팀 멤버 모두 2단계 인증을 켜두고, 가능하면 SSO를 통해 로그인하도록 정책을 세우세요. 이건 사고 후가 아니라 기본 위생이에요.

업계 흐름에서 보면

2024년 Snowflake 고객 데이터 유출, 2023년 Okta 지원 시스템 침해, CircleCI 시크릿 탈취 등 최근 몇 년 동안 "개발자 인프라 SaaS"를 노린 공격이 부쩍 늘었어요. 이유는 단순해요. 공격자 입장에서 한 군데 뚫으면 수천, 수만 고객의 정보에 한꺼번에 접근할 수 있는 "한 번에 큰 거" 타깃이거든요.

그래서 요즘은 "제로 트러스트(Zero Trust)" 개념이 강조돼요. 핵심은 "내부 네트워크라고 해서 그냥 믿지 말고, 모든 요청을 매번 검증하자"예요. 시크릿 매니저를 따로 두고(예: HashiCorp Vault, AWS Secrets Manager, Doppler), 단기 수명 토큰을 쓰고, 권한을 최소한으로 부여하는 방식이 표준이 되어 가고 있어요.

한국 개발자에게 주는 시사점

많은 한국 스타트업이 Vercel, Netlify, Supabase, Firebase 같은 BaaS/PaaS를 적극적으로 써요. 빠르게 만들어서 빨리 출시할 수 있다는 장점이 분명하지만, "내가 직접 운영하지 않는 인프라"에 의존한다는 위험을 함께 진다는 점은 잊지 말아야 해요.

실무적으로는 사고 대응 매뉴얼을 한 번 만들어 두시면 좋아요. "우리가 쓰는 SaaS 목록은 뭐가 있고, 각각에 어떤 데이터가 들어가 있고, 사고 발생 시 누가 무엇을 점검할지"를 한 페이지로 정리해두는 거죠. 이런 게 있으면 막상 사고 공지가 떴을 때 허둥대지 않아요.