Vercel 침해 사고는 겉으로 보면 "또 하나의 벤더 해킹"처럼 보입니다. 하지만 이번 사건의 핵심은 Vercel 인프라 자체보다, 직원이 연결해 둔 AI 도구의 OAuth 권한이 기업 내부 신뢰 경로로 바뀌었다는 데 있습니다. Vercel은 최근 조사 확대 과정에서, 이번 사고와 별개이면서 더 이전에 발생한 고객 계정 침해 정황도 확인했다고 밝혔습니다.1
왜 지금 이 사건이 중요할까요. 앞으로의 침해는 비밀번호를 훔치는 방식보다, Google Workspace·GitHub·AI SaaS에 이미 부여된 "합법적 권한"을 타고 들어오는 경우가 더 많아질 가능성이 크기 때문입니다. 이번 사고는 그 변화를 꽤 선명하게 보여줍니다.23
이번 사고의 본질은 "Vercel 해킹"보다 권한 위임 구조의 붕괴다
현재까지 공개된 사실을 좁혀 보면 이렇습니다. Vercel은 Context.ai라는 외부 AI 도구의 Google Workspace OAuth 앱이 침해됐고, 그 권한을 통해 한 직원의 Google Workspace 계정이 장악됐다고 설명했습니다. 이후 공격자는 해당 직원의 Vercel 계정과 내부 환경으로 이동했고, "민감하지 않음"으로 분류된 환경변수를 열람·나열해 추가 접근에 활용했습니다.2
이 지점이 중요합니다. 공격자는 처음부터 Vercel의 핵심 인증 체계를 정면 돌파한 것이 아니라, 이미 신뢰받던 앱 권한을 상속받아 내부로 들어왔습니다. 즉 방어 포인트가 로그인 보안만이 아니었다는 뜻입니다.
여기서 흔한 반론이 있습니다. "우리도 OAuth 앱 몇 개 붙여 쓰지만, 업무 효율 때문에 어쩔 수 없다"는 말입니다. 맞습니다. 문제는 OAuth 자체가 아니라, 누가 어떤 범위의 권한을 언제까지 갖는지 거의 관리되지 않는 상태입니다. 특히 AI 요약, 회의 기록, 문서 자동화처럼 생산성 도구로 보이는 앱이 Drive, Gmail, Calendar, GitHub 저장소, 심지어 배포 워크플로까지 읽을 수 있다면, 그 순간부터 그 앱은 단순 부가 기능이 아니라 사실상 아이덴티티 공급망의 일부입니다.
Google Workspace, GitHub, AI 툴을 함께 쓰는 팀이라면 어디가 특히 위험한가
보안팀이 크지 않은 조직도 이번 분기 안에 최소한의 자체 점검은 할 수 있습니다. 가장 먼저 볼 것은 계정이 아니라 연결된 앱 목록입니다. Google Workspace 관리자 콘솔의 서드파티 앱 접근, 개인 계정의 연결된 앱, 브라우저 확장, GitHub OAuth 앱과 GitHub Apps를 함께 봐야 합니다. Vercel도 이번 사고와 관련된 특정 Google OAuth 앱 ID를 공개하며 관리자의 즉각적인 점검을 권고했습니다.2
그다음은 권한 범위입니다. 특히 위험한 스코프는 메일함 전체 읽기, Drive 전체 접근, 오프라인 액세스, 조직 전체 동의, 코드 저장소 읽기/쓰기, 배포 비밀값 접근 같은 것들입니다. 이름이 낯설지 않아도 안심할 수 없습니다. "회의 요약", "문서 도우미", "AI 업무 비서"처럼 보여도 실제 권한은 내부 검색 엔진에 가까울 수 있습니다.
역할도 중요합니다. 모든 직원이 같은 위험을 만들지 않습니다. 배포 권한을 가진 플랫폼 엔지니어, 재무·고객 문서에 접근하는 운영 담당자, Google Workspace 관리자, GitHub 조직 관리자 계정은 작은 앱 하나로도 훨씬 큰 폭발 반경을 만듭니다. 이번 사건도 단일 직원 계정에서 시작됐지만, 그 계정이 가진 연결과 내부 접근이 연쇄 효과를 만들었습니다.24
점검 기준은 간단합니다. 그 앱이 탈취됐을 때 공격자가 "문서를 읽는 수준"에 머무는지, 아니면 "토큰을 찾아 다른 시스템으로 이동"할 수 있는지 보라는 것입니다. 후자라면 생산성 도구가 아니라 침해 경로입니다.
"제한된 자격증명만 노출"돼도 왜 대응 비용은 크게 불어나는가
이런 사건에서 기업 공지는 종종 범위를 보수적으로 표현합니다. 실제로 Vercel은 일부 고객의 비민감 환경변수와 제한된 계정 범위를 언급했고, npm 패키지 변조 증거는 없다고 밝혔습니다.2 이건 중요한 사실입니다. 과장해선 안 됩니다.
다만 실무적으로는 "비민감"이라는 표현이 운영 비용을 거의 줄여주지 못할 수 있습니다. 환경변수 안에는 원래 민감정보를 넣지 말아야 하지만, 현실의 팀들은 API 키, 서명 키, 데이터베이스 접속정보, 서드파티 토큰을 섞어 두는 경우가 많습니다. 그래서 한 번 노출 가능성이 생기면 실제 해야 하는 일은 광범위합니다. 키 교체, 배포 재검증, 로그 검토, 고객 커뮤니케이션, 감사 대응, 그리고 "정말 더 안 퍼졌는지"를 입증하는 작업까지 따라옵니다.
이번에 더 불편한 신호는, Vercel이 조사 확대 후 이번 사고보다 앞선 시점의 별도 고객 계정 침해 정황도 확인했다는 점입니다.1 아직 공개 정보만으로 동일 공격자나 동일 기법이라고 단정할 수는 없습니다. 하지만 조직 입장에서는 하나의 사건을 닫아도, 이미 SaaS 스택 안에 비슷한 경로가 더 있을 수 있다는 뜻입니다. 이게 바로 OAuth 기반 공급망 리스크가 운영적으로 비싼 이유입니다.
이번 분기에 먼저 해야 할 최소 방어선 5가지
보안 정책 PDF를 한 권 더 만드는 것보다, 아래 다섯 가지가 훨씬 실용적입니다.
첫째, OAuth 앱 승인 권한을 줄이세요. 누구나 회사 계정으로 임의의 AI 앱을 연결할 수 있게 두면 안 됩니다. 고위험 스코프는 관리자 승인제로 바꾸는 것이 맞습니다.
둘째, 장수 토큰과 광범위한 환경변수를 줄이세요. "민감하지 않음" 기본값에 기대지 말고, 비밀값은 짧게 살고 자주 교체되게 설계해야 합니다.2
셋째, 권한 큰 계정을 분리하세요. 관리자 계정, 배포 계정, 일반 생산성 도구 사용 계정을 섞지 않는 것만으로도 횡이동 범위를 줄일 수 있습니다.
넷째, 토큰 악용 징후를 봐야 합니다. Vercel CEO가 언급한 것처럼 빠른 API 열람과 환경변수 나열은 중요한 패턴입니다.1 로그인 실패보다 "정상 토큰으로 너무 많이 읽는 행위"가 더 중요한 시대입니다.
다섯째, SaaS 침해 대응을 연습하세요. 서버 침해 runbook만 있어서는 부족합니다. Google Workspace, GitHub, 배포 플랫폼, 브라우저 확장까지 포함한 회수·차단·감사 절차가 있어야 합니다.
이번 사건에서 정말 배워야 할 것은 "어느 벤더가 당했다"가 아닙니다. 우리 조직이 이미 승인해 둔 앱들이 어느 정도의 내부 신뢰를 상속받고 있는지, 그리고 그 신뢰가 깨졌을 때 얼마나 빨리 격리할 수 있는지입니다. Google Workspace와 GitHub, 그리고 각종 AI 도구를 함께 쓰는 개발 조직이라면 지금 봐야 할 것은 비밀번호 정책보다 연결된 권한 지도입니다.
참고
1Vercel says some of its customers' data was stolen prior to its recent hack
2Vercel April 2026 security incident
3App host Vercel says it was hacked and customer data stolen
4Vercel's security breach started with malware disguised as Roblox cheats
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.