[AI 업계동향] Vercel 보안 사고 후 Next.js 프로젝트 점검 체크리스트
팀 단위로 서비스를 운영한다면 이번 Vercel 보안 사고는 남 일이 아닙니다. 특히 프론트엔드를 Vercel에 배포한 조직이라면 점검이 필요합니다. “Vercel에 보안 사고가 있었고, 우리 프론트도 거기 올라가 있다”는 상황을 가정해 보겠습니다.
Next.js 만든 그 회사요. Vercel 공식 블로그에 사고 공지가 올라왔고, BleepingComputer·The Register·The Hacker News 같은 주류 보안 매체가 일제히 보도했어요. 이게 단순 해킹이 아니라 “AI 툴 하나가 본사를 뚫는” 공급망 공격의 교과서 사례라서, 관련된 모든 분들은 오늘 확인해볼 만합니다.
📌 TL;DR (3줄 요약)
1. 무엇이 영향을 받았나? Vercel 직원 580명 정보 + 고객 환경변수 일부 + API·NPM·GitHub 토큰이 해커 손에 넘어갔다는 주장이 나왔어요.
2. 어떻게 뚫렸나? Context.ai(AI 툴) 직원 PC가 2월에 Lumma Stealer에 감염 → Google OAuth 앱 탈취 → Vercel 직원 계정까지 확장.
3. 지금 뭐 해야 하나? Vercel 쓰신다면 환경변수 전체 회전·Sensitive 플래그 활성화·Deployment Protection 확인을 오늘 안에 끝내세요.
📑 목차
- 1. 사건 한눈에 — 580명, 200만 달러, 72시간
- 2. 공격 체인 4단계 — AI 툴 하나가 본사를 뚫은 방법
- 3. 해커가 판매 중이라고 주장하는 데이터
- 4. ShinyHunters의 $2M 협박 — BreachForums 타임라인
- 5. Vercel 쓰는 분 긴급 대응 5단계
- 6. DeFi·크립토 업계가 유독 긴장한 이유
- 7. 사고 이후 — 기업 신뢰도에 미칠 영향
- 8. 이 사건이 남긴 3가지 교훈
1. 사건 한눈에 — 580명, 200만 달러, 72시간
먼저 숫자부터 깔끔하게 정리해 드릴게요. 기사 읽다 보면 날짜·수치가 여기저기 흩어져 있어서 머리가 어지럽거든요.
| 항목 | 내용 |
|---|---|
| 최초 감염 | 2026년 2월 (Context.ai 직원 PC, Lumma Stealer) |
| Vercel 탐지 | 2026-04-19 (사고 공지: 11:04 AM PST) |
| 공격자 | “ShinyHunters” (BreachForums 판매자) |
| 탈취 주장 규모 | 직원 580명 레코드 + 고객 env vars + 다양한 API/NPM/GitHub 토큰 |
| 요구 금액 | 약 200만 달러 (Telegram) |
| 영향 고객 | “제한된 일부(limited subset)” — 구체 수치 비공개 |
| 대응 파트너 | Mandiant + 법 집행기관 |
| Next.js 영향 | 없음 (Turbopack 포함 오픈소스 모두 안전 확인) |
출처는 Vercel 공식 공지, BleepingComputer, The Register입니다.
2. 공격 체인 4단계 — AI 툴 하나가 본사를 뚫은 방법
이번 사건에서 주목할 점은, Vercel이 직접 뚫린 게 아니라 ‘Vercel 직원이 쓰던 AI 툴’이 뚫린 거거든요. 쉽게 말하면 “우리 회사 문은 튼튼한데 협력 업체 직원 열쇠를 훔쳐서 들어온” 시나리오예요.
단계 1. Context.ai 직원 PC 감염 (2026-02)
AI 요약·기록 서비스 Context.ai의 한 직원이 Roblox 자동 파밍(auto-farm) 스크립트를 인터넷에서 받다가 Lumma Stealer에 감염됐어요. Lumma Stealer는 게임 치트 파일에 몰래 숨어 있는 악성코드로, PC의 쿠키·OAuth 토큰·비밀번호를 전부 털어 가는 걸로 악명 높습니다 (infostealers.com 분석).
단계 2. Google Workspace OAuth 앱 탈취
공격자는 감염된 PC에서 Context.ai의 Google Workspace OAuth 앱 자격증명을 확보했어요. OAuth 앱은 원래 “Context.ai가 내 Google 계정을 읽을 수 있게 허용” 같은 기능을 위해 쓰는 건데, 이게 탈취되면 그 앱이 접근 허가된 모든 Google 계정이 위험해집니다.
단계 3. Vercel 직원 Google 계정 장악
공격자는 같은 OAuth 앱을 승인해 뒀던 Vercel 직원의 Google Workspace 계정까지 타고 들어갔어요. 공식 IOC(침해 지표)로 공개된 OAuth App ID는 110671459871-30f1spbu...apps.googleusercontent.com입니다. 같은 ID가 로그에 찍혔다면 감염 의심입니다.
단계 4. Vercel 내부 환경변수 유출
Vercel 직원 계정으로 들어간 공격자는 Sensitive 플래그가 켜져 있지 않은 환경변수(env vars)를 읽어 갔어요. Vercel CEO Guillermo Rauch는 “민감으로 표시된 변수는 접근 흔적이 없다”고 강조했지만, 많은 팀이 플래그를 귀찮아서 안 켜 둔다는 게 함정이죠 (The Hacker News).
💡 정리하자면 — Roblox 치트 → Lumma Stealer → Context.ai OAuth → Google 계정 → Vercel 환경변수. 고리가 5칸이나 되는데 한 칸도 끊기지 않았다는 점이 위험 신호입니다.
3. 해커가 판매 중이라고 주장하는 데이터
ShinyHunters는 BreachForums에 샘플 파일을 공개했는데, 내용을 정리하면 이래요.
| 데이터 유형 | 상세 | 위험도 |
|---|---|---|
| 직원 레코드 | 580명 이름·이메일·계정 상태·활동 타임스탬프 | 중 (피싱·OSINT) |
| Vercel Enterprise 대시보드 | 스크린샷 증거 (접근 입증) | 상 (내부 구조 노출) |
| API 키 | 고객사 배포 자격증명 일부 | 상 (즉시 회전 필요) |
| NPM 토큰 | 패키지 퍼블리시 권한 포함 가능 | 최상 (공급망 2차 확산) |
| GitHub 토큰 | Private 리포지토리 접근 가능 | 최상 (소스코드 유출 위험) |
| 소스코드·DB 일부 | 내부 배포용 (Next.js 오픈소스 영향 없음) | 중 |
여기서 특히 주의할 부분은 NPM 토큰입니다. 얼마 전에 axios 1.14.1 악성 RAT 사건처럼 한번 NPM에 오염된 패키지가 풀리면 전 세계 개발자들이 npm install 한 번에 감염될 수 있거든요. Vercel 자체 패키지가 영향 범위인지 공식 답변은 아직 없습니다.
4. ShinyHunters의 $2M 협박 — BreachForums 타임라인
ShinyHunters는 이미 SnowFlake(2024), Ticketmaster, AT&T 등 대형 사건을 여러 번 일으킨 전력이 있는 유명 범죄 집단이에요. 이번에도 공식 수법대로 움직였습니다.
- 2026-02: Lumma Stealer 감염 (Context.ai).
- 2026-02 ~ 04: 조용히 Vercel 내부 탐색.
- 2026-04-19 오전: Vercel 공식 사고 공지 (11:04 PST).
- 2026-04-19 오후: ShinyHunters가 BreachForums에 데이터 샘플 공개 + $2M 텔레그램 협상 메시지 공개.
- 2026-04-19 저녁: Vercel 2차 공지 — 공격 경로 확인, 권고사항 추가 (18:01 PST).
- 2026-04-20: 전세계 Vercel 고객사 긴급 키 회전 시작.
텔레그램 메시지 스크린샷에는 해커가 “Vercel 팀과 직접 대화하고 있다”고 주장하는 내용도 있는데, Vercel은 공식적으로 협상 가능성을 언급하지 않았습니다 (Protos 보도).
5. Vercel 쓰는 분 긴급 대응 5단계 ⚡
자, 이 글에서 이 섹션이 제일 중요해요. Vercel 쓰시는 분들은 지금 창 하나 더 띄워서 따라 하시면 됩니다.
- 활동 로그 훑기 — Vercel 대시보드 → Settings → Audit Log에서 2026-02-01 이후 수상한 배포·멤버 추가·토큰 생성 기록이 있는지 확인.
- 환경변수 전부 회전 —
DATABASE_URL,STRIPE_SECRET,OPENAI_API_KEY같은 비밀값은 전부 새로 발급하세요. 특히 Sensitive 플래그가 꺼져 있던 변수가 위험합니다. - Sensitive 플래그 활성화 — Settings → Environment Variables에서 개별 변수 옆 자물쇠 아이콘을 켜면, 이제 대시보드에서도 값이 안 보여요. 앞으로 만드는 모든 비밀값은 여기로.
- Deployment Protection Standard 이상 — Settings → Deployment Protection을 Standard 또는 Secret으로 설정. 공개 URL로 프리뷰 배포가 노출되는 걸 막아 줍니다.
- Deployment Protection 토큰 회전 — 위 설정에 쓰이는 토큰도 과거에 공유된 적 있다면 함께 새로 발급. CI/CD 파이프라인 환경변수도 잊지 마세요.
⚠️ 보너스 체크 — OAuth App ID 110671459871-30f1spbu...가 Google Workspace Admin 콘솔 → Security → API Controls → “App access control”에 승인된 상태라면 즉시 차단하세요. 공식 IOC입니다.
6. DeFi·크립토 업계가 유독 긴장한 이유
Vercel은 전 세계 크립토 프로젝트 프론트엔드의 사실상 표준 호스팅이에요. Uniswap·SushiSwap·PancakeSwap 같은 이름난 DEX부터 중소형 NFT 마켓플레이스까지 상당수가 Vercel에서 돕니다. CoinDesk는 “크립토 개발자들이 API 키 잠그느라 스크램블 중”이라고 표현했어요.
왜 크립토만 특히 위험하냐면, 프론트엔드 환경변수에 WalletConnect Project ID나 RPC 엔드포인트 키가 들어가 있으면 피싱 사이트로 사용자 지갑이 돌려질 수 있거든요. 한번 털리면 수백 명 지갑이 한꺼번에 비워지는 구조입니다.
AMBCrypto 분석에 따르면 이번 Vercel 사건은 4월 한 달간 벌어진 크립토 공격 웨이브의 일부로, 전월 대비 공격 빈도가 유의미하게 증가하고 있다고 해요. AI 툴로 자동화된 타깃 정찰이 늘면서 공격 속도 자체가 빨라진 게 원인이라는 설명입니다.
7. 사고 이후 — 기업 신뢰도에 미칠 영향
Startup Fortune은 이 사건을 “Vercel 공급망 리스크 사고”로 프레이밍했어요. Vercel은 2026년 사업 확장을 준비 중이라고 알려져 있어서, 이번 사고가 기업 신뢰도에 미칠 영향이 함께 주목받고 있습니다.
보안 사건이 공모가에 직접 영향을 줄지는 변수예요. 최근 CrowdStrike·Okta·Snowflake 등 비슷한 사건을 겪은 기업들을 보면, 투명한 대응과 후속 조치의 구체성이 주가 회복 속도를 좌우했어요. Vercel이 Mandiant·법 집행기관과 공조하며 OAuth App ID 같은 IOC를 바로 공개한 건 긍정적 신호입니다.
📊 정리하자면 — 사고 자체는 크지만 대응은 교과서적. 단기 평가엔 흠집이 나겠지만 장기 신뢰는 이제부터 후속 공지와 보상 패키지에서 결정될 겁니다.
8. 이 사건이 남긴 3가지 교훈
- “작은 AI 툴 하나”가 회사 전체 리스크가 된다 — Context.ai는 Vercel 입장에서 서드파티 중에서도 비교적 작은 도구였어요. 하지만 한 직원의 OAuth 승인 하나가 게이트웨이가 됐습니다. Google Workspace Admin에서 ‘승인된 앱’ 목록을 정기적으로 감사하는 루틴이 필수입니다.
- Infostealer(정보 탈취형 악성코드)는 게임 쪽에서 퍼진다 — Lumma Stealer는 Roblox·마인크래프트 치트 파일에 자주 숨어요. 회사 PC로 게임 치트 다운로드 금지는 농담이 아니라 실제 공급망 공격의 시작점이라는 게 확인된 셈입니다.
- Sensitive 플래그, 귀찮아도 켜라 — Vercel이 반복해서 강조하는 건 “플래그만 켜져 있었어도 이 변수들은 털리지 않았다”는 점이에요. 같은 원리로 AWS Secrets Manager·GCP Secret Manager·1Password Service Account도 적극적으로 쓰세요. 편의성 vs 보안, 이제는 보안이 이깁니다.
마무리 — 당신의 Vercel 프로젝트는 안전한가요?
대응 방법은 간단합니다. Vercel 환경변수를 전부 회전하고 Sensitive 플래그를 켜는 것입니다. 번거롭더라도 대규모 보안 사고의 영향 범위에 자신의 토큰이 포함될 가능성을 생각하면 점검은 필수입니다.
이번 사건은 “AI 툴 쓸 때 권한을 어디까지 줄지”를 다시 한번 생각하게 만드는 계기였어요. 편한 만큼 위험해지는 세상이니까요. 여러분 회사에서는 이번 Vercel 사고, 누가 점검 책임지고 있나요? 댓글로 대응 현황 공유해 주시면 다른 분들께도 큰 도움 됩니다. 🙏
끝까지 읽어 주셔서 감사합니다. 도움 되셨다면 구독·공감 부탁드리고, 다음 글에서는 Lumma Stealer 같은 Infostealer 계열을 회사 PC에서 어떻게 사전에 막을지 EDR 툴 비교로 이어서 써 볼게요. 또 봬요! 👋
📚 참고한 출처 (15개)
사례로 보는 대응 점검 흐름
이런 사고가 나면 가장 먼저 “우리 조직이 Vercel을 쓰는가?”부터 확인해야 해요. 게임 서버는 AWS라도 프론트 랜딩 페이지 하나가 Vercel에 올라가 있는 경우가 흔하고, 그 페이지에 연결된 API 키가 노출 범위에 들어갈 수 있거든요.
보안팀이 따로 없는 중소 게임사 기준으로, 아래 순서대로 점검하면 됩니다.
1. Vercel 대시보드 → Environment Variables 전수 확인
어떤 API 키가 deploy에 연결돼 있는지 목록으로 정리합니다. 오래된 키가 남아 있을 수 있으므로, 3개월 이상 된 키는 우선 교체 대상으로 분류하는 편이 안전합니다.
2. GitHub → Settings → Third-party applications 점검
Vercel이 GitHub OAuth로 연결돼 있으면 repo 접근 권한도 같이 노출될 수 있어요. 사용하지 않는 OAuth 앱은 바로 revoke해야 합니다.
3. 알림 설정
Vercel 콘솔에서 팀 멤버 변경·새 deploy 알림을 Slack으로 연결. 이런 거 평소에 안 해두면 사고 나고 나서야 알게 됩니다.
결론적으로 이번 사고는 “우리는 괜찮아”가 아니라 “우리도 점검해야 한다”가 맞습니다. 프론트엔드 배포에 Vercel을 쓰는 조직은 생각보다 많습니다.
지금 점검할 보안 항목
- Vercel 대시보드 → Settings → Environment Variables — 모든 API 키 목록 확인
- GitHub → Settings → Integrations → Authorized OAuth Apps — Vercel 권한 범위 확인
- Vercel 팀 멤버 목록 — 퇴사자/외부 협력사 계정 잔재 없는지 점검
- API 키 rotate 주기 설정 — 최소 분기 1회 (캘린더에 지금 바로 등록)
- 보안 알림 채널 연결 — Vercel Alerts → Slack/이메일 웹훅
이 중 하나라도 지금 안 돼 있으면, Vercel 사고는 “남의 일”이 아닙니다. 5분이면 됩니다.