Vercel 해킹 사태(2026년 4월): 모든 개발자가 지금 당장 실행해야 할 60분 긴급 대응 매뉴얼
2026년 4월 19일, Vercel은 공격자가 서드파티 AI 도구(Context.ai)를 침해하고 Vercel 직원의 Google Workspace 계정을 탈취하여 제한된 일부 고객 프로젝트에서 "중요(Sensitive)"로 표시되지 않은 환경 변수를 읽었음을 확인했습니다. 지난 30일 동안 Vercel에 무언가를 배포했다면, 여러분의 환경 변수 중 하나가 이미 제3자의 손에 들어갔다고 가정하고 신속하게 행동해야 합니다.
불편한 진실은 다음과 같습니다. 대부분의 vibecoders(감각적 코더들)는 템플릿에서 .env 값을 그대로 가져오면서 "중요(Sensitive)" 토글을 전혀 건드리지 않고 배포합니다. 공격자가 읽어간 것이 바로 이런 유형의 변수입니다. 이 매뉴얼은 다음 60분 동안 무엇을 확인하고, 무엇을 교체하며, 다음 플랫폼 침해 시 앱이 중단되지 않도록 스택을 강화하는 방법을 안내합니다.
요약: 다음 60분 동안 해야 할 일
다른 것을 읽지 않더라도 지금 당장 이 여섯 가지를 수행하세요:
- 프로덕션 브랜치에서 자동 배포를 일시 중지하세요.
vercel env pull을 실행하고 출력 결과에서 시크릿 패턴(sk_live_,AKIA,ghp_,eyJ)을 grep으로 검색하세요.- 중요하지 않은 env 변수로 저장된 모든 API 키를 교체하세요. 결제, 데이터베이스, 인증 및 클라우드 제공자 키부터 시작하십시오.
- Vercel의 "중요(Sensitive)" 환경 변수 토글을 사용하여 교체된 시크릿을 다시 추가한 후 재배포하세요.
- Vercel 활동 로그(4월 1일~20일)를 열어 인식하지 못하는 배포, 로그인 또는 토큰 이벤트를 표시하세요.
- 동일한 기간 동안 GitHub 조직 감사 로그를 검토하여 새로운 PAT(Personal Access Token), 배포 키 또는 워크플로우 변경 사항이 있는지 확인하세요.
아래에는 필요한 명령어, 패턴 및 교체 순서가 포함된 전체 분석 내용이 있습니다.
Vercel 2026년 4월 침해 사건에서 실제로 무슨 일이 있었나?
Vercel은 2026년 4월 19일, 공격자가 Vercel 직원이 사용한 서드파티 AI 생산성 도구인 Context.ai를 침해했다고 밝혔습니다. 이후 공격자는 해당 직원의 Vercel Google Workspace 계정을 장악하고 Vercel 내부 환경으로 이동하여 "중요"로 플래그되지 않은 환경 변수에 접근했습니다.
"중요"로 표시된 변수는 별도의 암호화된 읽기 경로를 사용하며, Vercel은 이러한 변수가 노출되었다는 증거는 없다고 밝혔습니다. API 키, 데이터베이스 URL, JWT 시크릿을 저장하는 일반 env 변수 등 나머지 모든 것은 읽을 수 있는 상태였습니다. 사이버 범죄 포럼 게시물에서는 Vercel 데이터를 200만 달러에 판매하고 있다고 주장했지만, Vercel은 데이터 유출을 확인하지 않았습니다. 어쨌든 안전한 조치는 Vercel로부터 직접 이메일을 받지 않았더라도 교체 목적으로 침해가 발생했다고 가정하는 것입니다.
회사는 공격자에 대해 "운영 속도와 Vercel 시스템에 대한 상세한 이해도를 바탕으로 매우 정교하다"고 평가했습니다. 즉, 이는 초보 해커의 짓이 아니므로 시간을 심각하게 받아들이셔야 합니다.
영향을 받았나요? 5분 안에 확인하는 방법
짧은 답변: Vercel을 사용하면서 "중요" 토글을 철저하게 관리하지 않았다면, 영향을 받은 것으로 간주하세요. 다음은 5분 트리아지(응급 분류) 절차입니다:
- Vercel 활동 로그를 열고 2026년 4월 1일부터 현재까지 필터링하세요. 익숙하지 않은 로그인, 토큰 생성 또는 배포 기록이 있는지 확인하세요.
- Google Workspace 관리자 → 보안 → API 제어로 이동하여 공개된 침해 지표(OAuth 클라이언트 ID
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com)를 검색하세요. 승인되어 있다면 즉시 취소하세요. - 팀원 중 누가 Google SSO를 사용하여 Context.ai에 로그인했는지 확인하세요. 만약 있다면 해당 계정을 고위험으로 취급하세요.
- Vercel 프로젝트의 환경 변수 탭을 확인하세요. "중요"로 표시되지 않은 변수의 개수를 세세요. 그중 하나라도 범위에 포함됩니다.
"We identified a security incident affecting your account"(계정에 영향을 미치는 보안 사고를 식별했습니다)로 시작하는 Vercel 이메일을 받았다면, 확인된 영향권 내에 있습니다. 교체 섹션으로 건너뛰어 지금 당장 시작하세요.
60분 긴급 대응 매뉴얼
이 절차는 피해 확산 범위(blast radius) 순서로 정리되었습니다. 단계를 건너뛰지 마십시오. 각 단계는 다음 단계의 전제 조건입니다.
1단계: 환경 동결 (첫 10분)
포렌식 조사 전에 출혈을 멈추세요:
main/production브랜치의 자동 배포를 일시 중지하세요 (Vercel 대시보드 → 프로젝트 → 설정 → Git).- 더 깊은 침해가 의심된다면
github.com/organizations/<your-org>/settings/installations에서 Vercel GitHub 앱을 일시적으로 비활성화하세요. - Vercel 감사 로그를 CSV로 내보내어 로컬에 저장하세요. 나중에 GDPR 통지 대상 사고로 발전할 경우 필요할 수 있습니다.
- 확장된 로그를 보존하기 위해 Observability Plus(무료 체험판 포함)를 활성화하세요.
이는 "증거 보존" 단계입니다. 로그를 스냅샷 찍기 전에 키를 교체하면 타임라인이 파괴됩니다.
2단계: Env 변수 가져오기 및 시크릿 스캔
터미널을 열고 다음을 실행하세요:
vercel link
vercel env pull .env.vercel-audit그런 다음 출력을 스캔하세요. 가장 빠른 방법은 GitGuardian의 CLI를 사용하는 것입니다:
ggshield secret scan path .env.vercel-audit무언가 설치하기 싫다면 다음 패턴을 grep으로 검색하세요. env 파일에서 유출된 시크릿의 80%를 잡아냅니다:
grep -E "AKIA[0-9A-Z]{16}|sk_live_[0-9a-zA-Z]{24}|ghp_[0-9a-zA-Z]{36}|ghs_[0-9a-zA-Z]{36}|npm_[0-9a-zA-Z]{36}|eyJ[a-zA-Z0-9_-]+|-----BEGIN" .env.vercel-audit일치하는 항목은 모두 교체 후보입니다. DB URL, Redis 비밀번호, 웹훅 서명 키와 같이 여전히 자격 증명인 일치하지 않는 시크릿도 교체 후보입니다. grep은 눈에 띄는 것만 잡아낼 뿐입니다.
3단계: 우선순위 순서로 시크릿 교체 (알파벳 순서가 아님)
대부분의 팀이 실수하는 부분입니다. 40개의 시크릿을 무작위 순서로 교체하면 세션 키가 만료되어 모든 활성 로그인이 끊기고 지원 티켓이 폭증합니다. 단계별로 진행하세요:
Tier 0 — 다음 30분 이내에 교체:
- 모든 GitHub 개인 액세스 토큰(세분화 및 클래식)
- 모든 기존 Vercel 중요 env 변수 토큰
- 배포 보호 토큰
Tier 1 — 오늘 교체:
- 결제 처리기 시크릿 키 (Stripe
sk_live_, Adyen, Braintree) AUTH_SECRET,NEXTAUTH_SECRET, JWT 서명 키, 세션 쿠키- 쓰기 권한이 있는 데이터베이스 연결 문자열 (
DATABASE_URL, Mongo, Redis) - 클라우드 제공자 키 (AWS IAM, GCP 서비스 계정, Azure 클라이언트 시크릿)
- 웹훅 서명 시크릿 (발신자와 수신자 모두에서 업데이트)
Tier 2 — 이번 주 교체:
- 서드파티 SaaS 키 (이메일, SMS, 분석, CRM)
- OAuth 클라이언트 시크릿
- SMTP 자격 증명, CDN 키
Tier 3 — 편의에 따라 교체:
- 읽기 전용 분석 토큰, Sentry DSN, 공개/익명 키
중요한 작업 순서:
- 데이터베이스: 사이트를 다운시키지 않으려면 기존 사용자를 폐기하기 전에 새로운 사용자를 먼저 생성하세요.
- 세션 키: 로그아웃 이벤트를 계획하세요. 모든 활성 세션이 종료됩니다.
- 웹훅: 동일한 배포 창에서 양쪽을 모두 업데이트하세요.
- env 변수 변경 후에는 반드시 재배포하세요. Vercel은 런타임이 아닌 빌드 시점에 값을 고정합니다.
4단계: 모든 것을 "중요(Sensitive)"로 다시 추가
새 값을 다시 넣을 때 모든 변수에 "중요" 토글을 켜세요. 중요 값은 별도의 암호화된 경로를 사용하며, Vercel의 공지사항에 따르면 이번 사건에서 노출되지 않았습니다. 이는 대부분의 영향을 받은 고객을 구할 수 있었던 원클릭 변경 사항입니다.
5단계: 리포지토리에서 불필요한 변경 사항 감사
메인 브랜치의 HEAD를 4월 1일 이전의 정상적인 커밋과 비교하세요. 다음에 집중하세요:
package.json스크립트, 특히postinstall,prepare,preinstall- 예상치 못한 새 종속성이 있는지 락파일(
package-lock.json,pnpm-lock.yaml) 확인 - 새 워크플로우 또는 핀되지 않은 액션이 있는지
.github/workflows/*.yml확인 - 빌드 명령어 변경이나 의심스러운 재작성이 있는지
vercel.json확인 - 알 수 없는 도메인을 가리키는 새 헤더나 리디렉션이 있는지
next.config.js확인
npm 패키지를 게시한다면 npm view <pkg> time --json을 실행하여 작성하지 않은 패키지가 배포되지 않았는지 검증하세요.
6단계: 하류 시스템 추적
공격자는 env 변수에서 멈추지 않고 이를 사용합니다. 4월 1일부터 현재까지의 기간 동안 하류 시스템을 쿼리하세요:
- AWS CloudTrail: 예상치 못한
CreateUser,AttachUserPolicy, S3GetObject급증, 새 IP에서의 로그인. - 데이터베이스 감사 로그: 대규모
SELECT *쿼리, export, 비정상적인 지역에서의 연결. - Stripe / Adyen: 새 API 키, 의심스러운 환불, 이상한 위치에서의 고객 생성.
- 인증 제공자: 불가능한 이동(impossible-travel) 로그인, 무단 비밀번호 재설정, 새 OAuth 앱.
여기서.hit(탐지)이 발생하면 이는 단순한 교체 연습이 아닌 실제 사고로 전환되므로 에스컬레이션하고 통지 의무(GDPR: 72시간)를 고려해야 합니다.
"Vibecoders"가 놓치는 점: 숨겨진 공격 표면
Claude Code, Cursor 또는 Copilot과 같은 AI 보조 코딩 도구를 통해 성장했다면, 보안 문서를 읽어보기 전에 첫 번째 Vercel 앱을 배포했을 가능성이 높습니다. 괜찮습니다. 하지만 숙련된 개발자보다 vibecoders에게 더 타격을 주는 네 가지 숨겨진 함정이 있습니다:
NEXT_PUBLIC_함정.NEXT_PUBLIC_접두사가 붙은 모든 항목은 클라이언트 JavaScript에 번들됩니다. "테스트용"으로 API 키를 넣었다면, 침해 이전에도 이미 공개된 상태였습니다. 빌드 출력을 grep하세요:grep -rE "sk_|AKIA|eyJ" .next/static/.- Linear / Slack 유출. 팀이 "잠깐만" Linear 이슈나 Slack 스레드에 시크릿을 붙여넣으면, 해당 시크릿은 서드파티 로그에 남습니다. Linear 감사 로그를 검토하고 위의 regex 패턴으로 검색하세요.
- 개인 리포의
.env.local가정. Vercel GitHub 앱이 침해당했다면 개인 리포지토리는 개인이 아닙니다. 커밋된 모든.env.*파일이 범위에 포함됩니다. - 프로덕션 시크릿이 포함된 미리보기 배포. 대부분의 vibecoders는 미리보기 환경에 프로덕션 env 변수를 재사용합니다. 이는 공격 표면을 두 배로 늘립니다. 분리하세요.
이는 AI 코딩 도구가 건너뛰는 지루한 인프라 작업입니다. 해결책은 AI 사용을 중단하는 것이 아니라, AI 속도에 보안 기준을 결합하는 것입니다. 앱이 어디에 있는지 아직 파악 중이라면, Vercel vs Netlify 비교와 Railway vs Render vs Fly.io 분석이 좋은 출발점입니다.
다음 침해 사태에서 피해를 입지 않도록 스택을 강화하는 방법
플랫폼 침해는 '만약'이 아니라 '언제'의 문제입니다. 월요일까지 모든 프로덕션 앱이 갖추어야 할 기본 사항은 다음과 같습니다:
- Vercel에서 **모든 새 env 변수를 기본적으로 "중요"**로 설정하세요. 이를 팀의 근육 기억으로 만드세요.
- 단명 자격 증명을 사용하세요. 장기간 유효한 AWS/GCP 키를 GitHub OIDC 페더레이션으로 교체하세요. 클라우드 제공자는 CI 신원을 직접 신뢰하므로 유출될 장기간 시크릿이 없습니다.
- pre-commit 시크릿 스캔(gitleaks, Trufflehog)을 설치하세요. 시크릿이 리포지토리에 진입하는 것을 처음부터 막습니다.
- GitHub 앱 권한을 특정 리포지토리로 제한하세요. 조직 전체가 아닌 특정 리포에만 접근하도록 설정하세요.
- Google Workspace, Microsoft 365, GitHub 및 Vercel 전반에 걸쳐 분기별 OAuth 앱 검토를 실시하세요. 인식하지 못하는 앱은 제거하세요.
- Claude Code 훅으로 시크릿 스캔을 실행하세요. AI가 잊어버려도 결정론적인 pre-commit 강제 실행을 보장합니다.
- Next.js 버전을 고정하고 advisories를 모니터링하세요. Vercel은 주요 Next.js 관리자이므로 여기의 사고는 연쇄적으로 발생합니다.
- 백엔드 시크릿을 분할하세요. Supabase 또는 Firebase를 사용한다면 행 수준 보안(row-level security)을 사용하고 서비스 역할 키는 신중하게 사용하세요. 유출된 서비스 키는 전체 DB 침해를 의미합니다.
도움이 필요하신가요? Techsy가 어떻게 도움을 드릴까요
솔직한 제안입니다: 대부분의 소규모 팀에는 보안 엔지니어가 없으며, 새벽 2시에 60단계 사고 대응 매뉴얼을 읽는 것은 누구도 원하는 월요일 보내는 방식이 아닙니다.
Techsy에서는 지난 2년간 40개 이상의 프로덕션 Next.js 및 Node.js 앱에 대한 사고 대응 및 플랫폼 강화를 수행해 왔습니다. Vercel 사건과 관련하여 우리는 다음과 같은 서비스를 제공합니다:
- 72시간 긴급 대응, Tier 0 / Tier 1 교체를 실행하고, 200개 이상의 시크릿 서명에 대해 env 변수를 스캔하며, Vercel + GitHub + 클라우드 로그를 종단 간(end-to-end)으로 감사합니다. 일반적인 소요 시간: 1 영업일.
- 플랫폼 강화 감사, 중요 변수 마이그레이션, OIDC 자격 증명 교체, pre-commit 시크릿 스캔, GitHub 앱 범위 지정, 그리고 다음 침해 사태 시 미래의 당신이 무엇을 해야 할지 알 수 있도록 작성된 러북(runbook) 제공.
- 지속적인 DevSecOps, 분기별 OAuth 검토, 지속적인 시크릿 스캔, 그리고 사고 훈련을 통해 "우리에게는 일어나지 않을 것"이라는 주장을 실제로 뒷받침할 수 있게 합니다.
우리는 체크박스 보안 벤더가 아닌 엔지니어입니다. 지금 당황하고 있다면 무료 30분 트리아지 콜을 위해 연락주세요. 위 매뉴얼로 직접 처리할 수 있는지, 아니면 저희의 도움이 필요한지 솔직하게 알려드리겠습니다.
자주 묻는 질문
Vercel 해킹은 확인된 사실인가요, 아니면 مجرد 소문인가요?
확인되었습니다. Vercel은 2026년 4월 19일 공식 보안 공지사항을 발표하여 침해된 서드파티 AI 도구(Context.ai)와 탈취된 직원 Google Workspace 계정을 통한 무단 접근을 인정했습니다. "중요"로 표시되지 않은 환경 변수가 접근되었습니다. 별도의 BreachForums 게시물이 데이터를 200만 달러에 판매하고 있다고 주장하지만, 이 부분은 확인되지 않았습니다.
Vercel로부터 이메일을 받지 못했습니다. 안전한가요?
아마도 그렇겠지만, "아마도"는 보안 태세가 아닙니다. Vercel은 확인된 영향이 있는 제한된Subset의 고객에게만 연락했다고 밝혔습니다. 이메일이 도착하지 않았다면 위험은 낮지만, Vercel 플랫폼 전체의 중요하지 않은 env 변수는 모두 피해 범위에 있었습니다. 그래도 위의 10분 트리아지를 수행하세요.
Vercel에서 "중요" env 변수와 일반 env 변수의 차이점은 무엇인가요?
"중요" 환경 변수는 별도의 암호화된 읽기 경로를 사용하며 생성 후 대시보드에서 볼 수 없습니다. 일반 env 변수는 프로젝트 접근 권한이 있는 사람(이번 사건의 공격자 포함)이 읽을 수 있습니다. 해결 방법은 무료이며 변수당 한 번의 클릭이면 됩니다.
Vercel에 있는 시크릿만 교체하면 되나요, 아니면 모든 시크릿을 교체해야 하나요?
중요하지 않은 Vercel env 변수에 저장된 모든 시크릿을 교체하세요. 다른 곳에서도 동일한 키를 사용했다면(흔한 안티패턴), 모든 곳에서 교체하세요. 미리보기 배포의 .env.local, GitHub Actions와 같은 CI 시스템, Linear 또는 Slack에 붙여넣은 참조도 잊지 마세요.
env 변수에서 실제 시크릿을 빠르게 스캔하는 방법은 무엇인가요?
vercel env pull .env.audit를 실행한 후 ggshield secret scan path .env.audit를 실행하세요. GitGuardian을 설치할 수 없다면 매뉴얼 2단계의 grep 원라이너를 사용하세요. 이는 AWS 키, Stripe 키, GitHub 토큰, npm 토큰, JWT 및 PEM 블록을 잡아냅니다.
이번 사건 이후 Vercel 사용을 중단해야 하나요?
이 사건 alone으로는 아닙니다. Vercel의 대응, 공개된 IoC(침해 지표), 타임라인, 교체 지침은 상당히 투명했습니다. 모든 플랫폼은 결국 침해를 겪게 됩니다. 중요한 것은 이를 위해 설계했는지 여부입니다: 중요 변수 기본값, 단명 자격 증명, 분리된 환경. 어차피 대안을 고려 중이라면, Vercel vs Netlify와 Railway vs Render vs Fly.io 게시물에서 장단점을 분석했습니다.
영향을 받을 경우 고객에게 통지해야 하는 기한은 얼마나 되나요?
GDPR은 통지 가능한 침해 인지 시점에서 72시간을 부여합니다. 캘리포니아(CCPA)는 데이터 클래스별 트리거가 있습니다. SOC 2 / ISO 27001 계약은 규제 기관보다 더 빠른 통지를 요구하는 경우가 많습니다. 유료 고객이 있고 그들의 데이터 유출이 확인되었다면 72시간 카운트다운이 시작되었다고 가정하고 anything을 보내기 전에 법률 자문을 받으세요.
Vercel을 사용하지 않더라도 Next.js 앱이 이를 통해 공격받을 수 있나요?
이 사건은 Vercel 플랫폼 특이적입니다. 다른 곳에 호스팅된 Next.js 자체는 침해 메커니즘의 영향을 받지 않습니다. 하지만 실수로 시크릿을 노출하는 동일한 NEXT_PUBLIC_ env 변수 패턴을 사용했다면, 이러한 문제는 호스트와 관계없이 코드와 함께 이동합니다.无论如何 빌드 출력을 감사하세요.
대부분의 피해를 예방할 수 있었던 원클릭 해결책은 무엇인가요?
첫날부터 Vercel에서 자격 증명이 포함된 모든 env 변수를 **"중요"**로 표시하는 것입니다. 대시보드의 체크박스입니다. 이번 사건에서 중요 변수는 접근되지 않았으며, 일반 변수만 접근되었습니다. 그것이 해결책이며, 비용은 0달러이고 프로젝트당 약 5분이 소요됩니다.
팀이 다시는 미표시 시크릿을 배포하지 않도록 어떻게 보장할 수 있나요?
세 가지 층위: (1) gitleaks를 사용한 pre-commit 시크릿 스캔, (2) Vercel API를 통해 sensitive: true 플래그 없이 env 변수가 추가되면 실패하는 CI 체크, (3) 모든 편집 시 스캐너를 실행하는 Claude Code 훅. 다층 방어(depth in defense)로, 세 가지 중 하나만 있어도 80%를 잡아내고, 세 가지 모두 사용하면 ~99%를 잡아냅니다.
결론
Vercel 2026년 4월 침해 사태는 심각하지만, 다음 60분 동안 움직인다면 survivable(극복 가능)합니다. 배포를 동결하고, env 변수를 가져오고, grep을 실행하고, 단계별로 교체하고, 중요 변수로 다시 추가한 후 하류 시스템을 추적하세요. 이것이 전체 매뉴얼입니다.
플랫폼 침해는 우리가 기본값에 얼마나 의존하는지를 드러냅니다. 여기서 피해를 입은 대부분의 팀은 잘못된 일을 한 것이 아니라, 누군가 그것이 중요하다고 알려주지 않았기 때문에 "중요" 토글을 체크하지 않았을 뿐입니다. 이것이 vibecoders를 위한 진정한 교훈입니다: AI가 생성한 코드는 빠르게 배포되지만, 보안 기본값은 생성 과정에 포함되지 않습니다.
스택을 다시 한번 점검받고 싶거나, 새벽 2시에 혼자 이 매뉴얼을 실행하기 싫다면 Techsy 팀과 무료 트리아지 콜을 예약하세요. 그렇지 않다면, 행운을 빕니다. 빠르게 행동하고, 변수를 중요로 표시하세요.