Vercel 해킹 사태에 관한 고찰 — OAuth 공급망 공격, 그리고 우리가 놓치고 있던 것

2026년 4월 19일, Vercel이 내부 시스템 무단 접근을 공식 공시했다.
공격의 시작점은 Vercel의 인프라가 아니었다. 한 직원이 쓰던 서드파티 AI 도구였다.
1. 사건 개요
Vercel은 Next.js를 만들고 전 세계 수백만 애플리케이션의 배포 인프라를 책임지는 회사다. 그런 Vercel이 4월 19일, 내부 시스템에 대한 무단 접근이 있었다고 보안 게시판에 공지했다. CEO Guillermo Rauch는 X에 공격 체인을 상세히 공개했고, Mandiant와 법 집행 기관이 조사에 투입됐다.
팩트만 추리면 이렇다.
침해 시점: 2024년 6월경(Context.ai 침해 시점 기준 추정)
공시 시점: 2026년 4월 19일 — 약 22개월의 잠복 기간
초기 벡터: 서드파티 AI 도구 Context.ai의 Google Workspace OAuth 애플리케이션 탈취
측면 이동 경로: Context.ai OAuth → Vercel 직원 Google Workspace 계정 → Vercel 내부 환경
노출 자산: sensitive 플래그가 지정되지 않은 고객 환경 변수(environment variables)
자칭 공격자: ShinyHunters를 주장하는 행위자, BreachForums에 $2M(BTC) 요구
주장된 유출물: NPM 토큰, GitHub 토큰, 580명 직원 기록, 소스코드 일부(Vercel은 미확인)
Vercel 측은 sensitive로 플래그된 환경 변수는 저장 방식 자체가 읽기 불가능하며 접근 증거가 없다고 밝혔다. Next.js, Turbopack, 그 외 오픈소스 프로젝트는 공급망 분석 결과 안전하다고 확인됐다.
2. 이 사건이 특이한 이유
2.1. 공격 체인이 "OAuth 경로"로 짜여 있다
우리가 "공급망 공격"이라는 단어를 들을 때 떠올리는 그림은 보통 이렇다.
누가 npm 패키지에 악성 코드를 심는다
누가 GitHub Actions를 오염시킨다
누가 Docker 이미지에 백도어를 넣는다
이번 사건은 그 범주에 들지 않는다. 코드가 아니라 신원(identity)이 공급망이었다. Context.ai는 직원 한 명이 업무 생산성을 위해 Google Workspace와 OAuth 연결을 걸어둔, 그런 종류의 도구다. 공격자가 Context.ai의 OAuth 토큰을 탈취하자, 비밀번호도 MFA도 건드리지 않고 그 직원의 Workspace API에 접근할 수 있었다. Google 입장에서는 "정당하게 인가된 앱의 정상 API 호출"일 뿐이다. 탐지 컨트롤이 울릴 이유가 없다.
이게 현대적 공급망 공격의 새로운 얼굴이다. 코드 경로가 아니라 IdP(Identity Provider)를 거쳐가는 경로. 주변부 도구 하나만 장악하면 본진 계정을 우회할 수 있는 구조.
2.2. 22개월 dwell time
Context.ai는 별도 공지를 통해 2026년 3월 사건을 공개했고, 보안 연구자들이 역추적한 결과 실제 초기 OAuth 침해는 2024년 6월경으로 거슬러 올라간다고 본다. 약 22개월 동안 공격자는 Vercel 생태계 어딘가에 접근 가능한 상태였다는 뜻이다.
더 인상적인 건 탐지-공시 지연(detection-to-disclosure latency) 문제다. 공개된 고객 제보에 따르면 한 Vercel 고객은 4월 10일에 OpenAI로부터 "당신의 API 키가 외부에서 유출된 것으로 보인다"는 알림을 받았다. 해당 키는 오직 Vercel에만 존재하던 키였다. Vercel이 공식 공시한 4월 19일보다 9일 전의 일이다.
2.3. "AI에 가속된 공격자"라는 CEO의 공식 언급
Rauch는 공격자의 속도와 Vercel 내부 시스템에 대한 이해도를 근거로 AI augmentation을 의심한다고 밝혔다. 공격자가 LLM을 도구로 써서 측면 이동과 정찰을 가속했다는 판단이다. 이게 2026년 보안 담론의 핵심 주제 중 하나로 부상한 이유이기도 하다. "AI로 빨라진 공격자"라는 표현이 이제 벤더의 공식 성명에 들어가기 시작했다.
3. 기술적 쟁점 — sensitive 플래그 모델의 한계
이번 사건에서 개발자가 가장 따져볼 부분은 Vercel의 환경 변수 모델이다.
Vercel에는 환경 변수에 sensitive라는 플래그를 켤 수 있는 기능이 있다. 켜두면 UI에서도 값이 보이지 않고, 내부 시스템에서도 평문 접근이 차단되는 구조다. 문제는 이 플래그가 기본값이 아니었다는 점. 고객이 자기 의지로 켜야 하는 옵트인 옵션이었고, 안 켰으면 Vercel 내부 접근 권한을 가진 누군가(이번에는 공격자)가 평문으로 읽을 수 있었다.
여기서 세 가지 교훈이 나온다.
첫째, 민감 정보의 "기본값"이 중요하다. 플랫폼이 제공하는 안전 장치가 옵트인이면, 그 장치는 많은 경우 켜지지 않는다. 개발자가 의식적으로 보안을 챙기는 순간에만 작동한다. 프로덕션 규모에서는 "의식적으로 챙겨야 한다"가 "많이 빠뜨린다"와 동의어다.
둘째, 플랫폼에 올린 비밀값은 플랫폼을 신뢰 경계(trust boundary)로 삼아선 안 된다. Vercel을 믿는 건 괜찮다. 그러나 Vercel의 직원 계정과 OAuth 연결된 서드파티 AI 도구까지 신뢰 경계 안에 들어와야 한다면, 그 경계는 이미 경계가 아니다.
셋째, long-lived secret 자체를 걷어내는 방향이 정답이다. API 키, DB 패스워드, JWT 서명 키 같은 장기 수명 비밀값은 플랫폼 어딘가에 정적으로 존재하는 한, "어디선가 한 번 뚫리면 전파되는" 자산이다. 대안은 workload identity, 단기 수명 토큰, AWS IAM Roles Anywhere, GCP Workload Identity Federation 같은 구조. OAuth 토큰과 플랫폼 env var에 의존하는 모델을 가능한 한 제거해야 한다.
4. 한국 개발 현장에서 짚어야 할 것
한국 백엔드 개발자 입장에서 이 사건을 남의 일로 읽기 어렵다. 이유는 세 가지다.
첫째, 우리는 SaaS OAuth 연동을 광범위하게 쓴다. Google Workspace, Microsoft 365, Slack, Notion, Atlassian, Figma, Canva, 그리고 최근엔 MCP 커넥터까지. 각 연동은 토큰 탈취 한 번으로 계정을 대체 인증할 수 있는 통로다. 조직에 어떤 OAuth 앱이 어떤 스코프로 걸려 있는지 자산 인벤토리가 최신 상태로 관리되는 회사는 많지 않다.
둘째, AI 도구의 도입 속도가 보안 검토 속도를 앞질렀다. 국내에서도 2025년부터 생산성 목적의 AI SaaS 도입이 폭발적으로 늘었다. "업무 효율이 두 배"라는 서술 뒤에 "Workspace 전체 읽기 권한을 넘겼다"는 사실이 감춰져 있는 경우가 흔하다. 조직의 TPRM(Third-Party Risk Management) 프로세스가 AI 툴에 대해서는 사실상 작동하지 않고 있다. 이번 공격이 "Context.ai 한 개"로 촉발됐다는 점이 바로 그 얘기다.
셋째, 2025년 한국의 보안 사고 지형 자체가 이미 임계점을 넘었다. SK텔레콤 유심 해킹(2025년 4월), KT·LGU+ 의혹, YES24 랜섬웨어, 쿠팡 3,370만 건 유출, 롯데카드 960만 건. 국내 대기업 여러 곳이 1년 안에 줄줄이 뚫렸다. 그런데 유형을 보면 SKT는 BPFDoor 리눅스 백도어, 롯데카드는 웹쉘, KT는 가짜 기지국 물리 공격 등 다 다르다. "한 가지 취약점만 막으면 된다"는 사고방식이 이미 무효화됐다는 뜻이다. Vercel 건은 이 구도에 "OAuth 공급망"이라는 축을 하나 더 추가한 셈이다.
5. 실무 체크리스트
개발자/DevOps 관점에서 지금 당장 확인해볼 것들.
[ ] 조직의 Google Workspace, Microsoft 365에 인가된 OAuth 앱 목록을 뽑고, 현재 사용하지 않는 앱의 grant 해제
[ ] 각 OAuth 앱의 스코프를 점검 — 읽기 전용이어도 되는 앱이 쓰기 권한을 쥐고 있진 않은지
[ ] 배포 플랫폼(Vercel, Netlify, Render, AWS Amplify 등)의 환경 변수 중 실제 비밀값에 해당하는 항목을 분리해, 전용 시크릿 매니저로 이관
[ ] Vercel 사용 중이면 sensitive 플래그 감사 — 켜져 있지 않은 비밀값은 이미 노출 가능성 구간이라고 간주하고 로테이션
[ ] 프로덕션 API 키에 사용 범위 제한(IP 제한, 스코프 축소, 만료 기간) 적용 여부 재점검
[ ] GitHub Actions, GitLab CI 등 파이프라인 시크릿도 동일 원칙으로 재검토 — 이번 사건의 Vercel 자리에 어떤 CI 벤더가 들어가도 이야기 구조는 같다
[ ] 시크릿 스캔 도구(ggshield, trufflehog, gitleaks) 상시 운용
[ ] "우리 조직에 침투됐다고 가정"하는 assume-breach 관점의 로그 감사 루틴 도입
6. 마무리
이번 사건을 "Vercel이 뚫린 얘기"로만 읽으면 교훈의 절반은 놓친다. 정확히 말하면 Vercel을 둘러싼 SaaS 신뢰망의 한 꼭지가 뚫렸고, 그 신뢰망 전체가 같이 흔들렸다는 얘기다. 이런 구조에서는 한 회사가 아무리 잘 방어해도, 그 회사 직원이 쓰는 다른 회사 하나가 무너지면 같이 무너진다.
2020년대 중반의 소프트웨어 공급망은 더 이상 "라이브러리"의 집합이 아니라 "SaaS 간 OAuth 연결"의 그래프다. 공격자는 그래프에서 가장 약한 노드를 찾는다. 우리가 해야 할 일은 그래프를 작게 유지하고, 각 엣지에 최소 권한을 부여하고, 자산을 장기 비밀값에 의존하지 않도록 설계하는 것이다. 보안이 기능보다 앞서는 게 아니라, 기능을 선택하는 순간 보안이 동시에 정해지도록.
결국 이 사건이 말하는 건 이거다.
"신뢰는 전이되지 않지만, 공격은 전이된다."
참고한 주요 소스: Vercel Knowledge Base 공식 공지, Vercel CEO Guillermo Rauch의 X 스레드, Trend Micro 분석, GitGuardian 블로그, CoinDesk, Cyber Kendra, Safe Security. 사건은 아직 진행 중이므로 세부 사실은 업데이트될 수 있다.