직접 살펴보니 Vercel 보안사고에서 제일 먼저 봐야 할 건 “얼마나 큰 사고인가”보다 “내 환경변수와 배포 기록이 안전한가”였다. 이런 사고는 제목만 보면 무섭지만, 실제 대응은 꽤 구체적이다. 누가 영향을 받았는지, 어떤 값이 노출됐을 수 있는지, 지금 뭘 돌려야 하는지만 차분히 보면 된다.
읽기 전에: 이 글은 Vercel 공식 공지와 외부 보도를 함께 확인해, 공포감보다 실제 대응 순서를 먼저 보게 하려는 목적에서 정리했다. 연락을 받지 않았더라도 환경변수와 배포 기록은 한 번 더 점검해두는 편이 안전하다.
확인 기준: 이 글은 2026년 4월 20일 Vercel 공식 공지와 같은 날 외부 보도를 함께 본 뒤, 실제 운영자가 바로 해야 할 점검 항목만 추려 정리했다. 이후 조사 범위가 넓어지면 판단도 달라질 수 있다는 점을 전제로 읽는 편이 맞다.
핵심만 먼저
- Vercel은 `2026년 4월 20일` 공식 보안 공지를 통해 내부 일부 시스템에 대한 비인가 접근이 있었다고 밝혔다.
- 초기 확인 기준으로는 `일부 고객`의 자격 증명이 영향을 받았고, 그 고객에게는 직접 연락했다고 설명했다.
- 특히 `sensitive`로 표시되지 않은 환경변수는 우선 노출 가능성이 있다고 보고 회전하는 것이 권고됐다.
무슨 일이 있었나
Vercel 공식 공지에 따르면, 이번 사고는 Vercel 내부 일부 시스템에 대한 비인가 접근으로 이어졌다. Vercel은 외부 사고 대응 전문가와 함께 조사 중이며, 수사기관에도 통보했다고 밝혔다.
공식 설명에서 더 중요한 부분은 사고의 출발점이다. Vercel은 이 사건이 `Context.ai`라는 제3자 AI 도구 쪽 침해에서 시작됐고, 그 도구와 연결돼 있던 직원의 Google Workspace 계정이 탈취되면서 일부 Vercel 환경에 접근이 가능해졌다고 적었다. 즉, 단순한 내부 실수라기보다 OAuth 연결을 타고 들어온 공급망형 침해에 가깝다.
누가 영향을 받았다고 봐야 하나
여기서 괜히 더 불안해질 수 있는데, 공식 문구는 비교적 선명하다. Vercel은 초기 파악 기준으로 `제한된 일부 고객`의 자격 증명이 손상됐고, 그 고객에게는 즉시 회전을 권고했다고 밝혔다. 또 `연락을 받지 않았다면 현재 시점에서는 당신의 Vercel 자격 증명이나 개인정보가 손상됐다고 볼 이유는 없다`고 적었다.
다만 이 문장을 “아무것도 안 해도 된다”로 읽으면 안 된다. 아직 조사 중이라는 점도 같이 적혀 있고, 추가 증거가 나오면 더 넓은 범위의 고객에게 연락할 수 있다는 뜻도 담겨 있다. 그래서 연락을 받지 않았더라도 기본 점검은 해두는 편이 맞다.
가장 중요한 건 환경변수다
| 항목 | Vercel 공식 설명 | 실제로 해야 할 일 |
|---|---|---|
| `sensitive` 환경변수 | 읽을 수 없는 방식으로 저장돼 현재 접근 증거가 없음 | 그래도 사용 현황은 점검 |
| 일반 환경변수 | 노출 가능성이 있어 우선 회전 권고 | API 키, 토큰, DB 비밀번호부터 즉시 교체 |
| 배포 보호 토큰 | 설정돼 있다면 회전 권고 | 새 토큰 발급 후 기존 값 폐기 |
이번 사고에서 가장 현실적인 포인트는 여기다. Vercel은 `sensitive`로 표시되지 않은 환경변수는 노출됐을 수 있다고 봐야 한다고 분명히 적었다. 그래서 서비스 운영자 입장에서는 “침해됐는지 나중에 보자”보다 “일반 환경변수에 들어 있던 비밀값부터 모두 교체하자”가 먼저다.
특히 API 키, 서명 키, 데이터베이스 접속 정보, 외부 SaaS 토큰처럼 다른 서비스까지 이어지는 값이 일반 환경변수에 들어 있었다면 우선순위가 높다. 이런 값은 한 군데만의 문제가 아니라 연쇄 접근으로 이어질 수 있다.
지금 바로 확인할 체크리스트
- Vercel activity log에서 낯선 접근이나 이상한 변경 기록이 있는지 본다.
- 최근 배포 내역 중 기억나지 않는 배포가 있는지 확인한다.
- `sensitive`로 표시되지 않은 환경변수에 비밀값이 들어 있었는지 확인하고 회전한다.
- `Deployment Protection`이 최소 `Standard`인지 점검한다.
- 설정된 `Deployment Protection tokens`가 있다면 새로 발급해 교체한다.
이 체크리스트는 Vercel이 공식 공지에서 직접 권고한 내용과 거의 같다. 그래서 이번 대응은 복잡한 포렌식보다, 로그 확인과 자격 증명 교체가 핵심이다. 실무에서는 완벽한 분석보다 빠른 회전이 더 중요할 때가 많다.
이번 사고가 보여주는 더 큰 문제
이 사건이 불편한 이유는 Vercel 하나의 사고로 끝나지 않기 때문이다. 제3자 도구, OAuth 연결, 기업 계정, 내부 환경 접근이 한 줄로 이어졌다는 점이 더 중요하다. 보안사고는 예전처럼 “우리 서버가 뚫렸나”만 보면 안 되고, “누가 어떤 외부 앱을 회사 계정에 연결했나”까지 봐야 한다는 뜻이다.
공식 공지에는 IOC로 특정 Google OAuth 앱 ID까지 공개됐다. 이건 Vercel만의 문제가 아니라, 같은 앱을 쓴 다른 조직도 점검하라는 의미다. 그래서 이번 Vercel 보안사고는 인프라 기업의 침해이면서 동시에 OAuth 공급망 사고로 읽는 편이 맞다.
같이 보면 좋은 글
FAQ
Vercel에서 연락을 못 받았으면 괜찮은 건가요
공식 공지 기준으로는 현재 시점에서 자격 증명이나 개인정보가 손상됐다고 볼 이유는 없다고 적혀 있다. 다만 조사 진행 중이므로 기본 점검과 비밀값 회전은 해두는 편이 좋다.
가장 먼저 바꿔야 하는 건 뭔가요
`sensitive`로 표시되지 않은 환경변수에 들어 있던 비밀값이다. API 키, 토큰, 데이터베이스 자격 증명부터 우선 교체하는 게 현실적이다.
Vercel 환경변수 회전은 어떤 순서로 하면 좋나요
외부 서비스까지 이어지는 값부터 먼저 보는 편이 좋다. API 키, 데이터베이스 비밀번호, 서명 키, OAuth 클라이언트 시크릿처럼 연쇄 접근으로 이어질 수 있는 값이 우선순위다.
이번 사고는 왜 더 크게 보이나요
직접 침해보다 제3자 AI 도구와 OAuth 연결을 통해 기업 계정이 탈취됐다는 점 때문에, 비슷한 연결 구조를 가진 다른 조직에도 경고가 되기 때문이다.
출처 및 참고자료
- Vercel April 2026 security incident
- TechCrunch: App host Vercel says it was hacked and customer data stolen
사고 이후 실제로 볼 순서
Vercel 보안사고처럼 개발 도구와 연결된 이슈는 “뉴스를 봤다”에서 끝나면 위험하다. 프로젝트에 연결된 토큰, 환경변수, 배포 권한을 순서대로 확인해야 한다.
- 팀 멤버 확인: 퇴사자나 외주 계정이 남아 있는지 본다.
- 환경변수 점검: DB 비밀번호, API 키, OAuth secret이 노출된 기록이 있는지 확인한다.
- 토큰 교체: 오래된 배포 토큰과 GitHub 연결 토큰을 교체한다.
- 배포 로그 확인: 낯선 시간대의 배포나 설정 변경 기록을 본다.
개발자는 사고 기사보다 변경 이력을 봐야 한다. 실제 피해 여부를 단정하기 어렵다면, 최소한 키 교체와 권한 정리는 하는 편이 안전하다.