# Vercel 보안 점검소

> Clean Markdown view of GeekNews topic #28789. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28789](https://news.hada.io/topic?id=28789)
- GeekNews Markdown: [https://news.hada.io/topic/28789.md](https://news.hada.io/topic/28789.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-23T07:35:37+09:00
- Updated: 2026-04-23T07:35:37+09:00
- Original source: [webmatrices.com](https://webmatrices.com/post/how-a-roblox-cheat-and-one-ai-tool-brought-down-vercel-s-entire-platform)
- Points: 1
- Comments: 1

## Topic Body

- **의미 있는 본문 정보**가 없어 사건의 정체나 경과를 확인할 수 없음
- Hacker News 제목에는 **Roblox 치트**와 AI 도구가 Vercel 플랫폼에 영향을 준 것으로 표기됨
- 원문 제목은 **Vercel Security Checkpoint**로 제시됨
- 구체적인 원인, 영향 범위, 대응 방식은 **본문 근거가 없어 확인되지 않음**
- 제공된 정보만으로는 사건의 중요성이나 기술적 세부 사항을 **요약할 수 없음**

---

내용 없음

## Comments



### Comment 56092

- Author: neo
- Created: 2026-04-23T07:35:38+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47844431) 
- 글이 **AI 생성물**처럼 너무 강하게 느껴짐. 일부러 문법을 어색하게 섞어 숨기려 한 것 같지만, 그게 내용의 정확성과는 별개인지까지는 확신이 안 듦
  - 나는 읽다가 중간에 멈췄음. 이제 **LLM 말투**에 너무 민감해져서, 이건 사실상 “ChatGPT야 이 기사 읽고 캐주얼하게 다시 써줘” 수준으로 보였고 실제 저자성이 거의 안 느껴졌음. 이런 종류의 글은 HN에서 가능하면 1차 출처를 가져오는 쪽이 맞다고 봄
  - 왜 비추천을 받는지 모르겠음. 이 글은 **AI 블로그 스팸**에 가깝고, [https://www.darkreading.com/application-security/vercel-employees-ai-tool-access-data-breach](https://www.darkreading.com/application-security/vercel-employees-ai-tool-access-data-breach) 같은 기사보다 사실 정보가 더 많은 것도 아니며, 텅 빈 LLM식 표현으로 가득해 보였음. 이런 글을 사람들이 기꺼이 읽는 분위기가 좀 우울하게 느껴짐
  - 작성자 사이트가 **Vercel** 위에 올라가 있는 걸 봤음. 그래서 이 이슈에 실제 노출돼 있었고 이해관계도 있는 사람이라고 생각함. 그 점만으로도 AI 단독 생성물보다는 한 단계 낫다고 봄
  - 문체는 분명 **LLM 산문** 같지만, 전부가 그렇지는 않아 보였음. 아마 일부만 다시 쓴 것 같음. 더 걱정되는 건 HN처럼 LLM에 익숙한 사람이 많은 곳에서도 이런 글이 그냥 통과된다는 점임. 이게 표준이 되는 건 싫지만, AI 생성 글이 진지한 반응을 많이 받는 HN 사례가 이번이 처음도 아니라는 점이 더 신경 쓰임. 코드에 AI를 쓰는 건 사람이 충분히 검증하면 괜찮다고 보지만, LLM 산문이 프런트 페이지를 점점 더 점령하는 건 정말 별로라고 느낌
  - 나도 똑같이 느꼈음. 보통 사람은 **저런 식으로** 쓰지 않음

- 여기서 말하는 “sensitive” 해석은 틀렸다고 봄. 내가 알기로 Vercel의 env var는 전부 저장 시점에는 암호화되어 있고, **sensitive 체크박스**는 개발자가 UI에서 그 값을 다시 볼 수 없게 만드는 의미임. 즉 write-only에 가까운 개념이고, 앱은 env var를 통해 값을 볼 수 있어야 하니 앱도 못 읽게 암호화하는 건 애초에 무의미함. 체크를 안 하면 프로젝트 UI에서 값을 볼 수 있고, `DEFAULT_TIME_ZONE` 같은 일반 설정값에는 그 편이 더 실용적임. 그래서 sensitive는 암호화 여부가 아니라 UI 노출 여부를 뜻한다고 이해함. Vercel 직원은 아니지만 좀 써봤고, 이 부분을 비판하는 건 **허수아비 논증**처럼 보임
  - 맞음, 나도 그 부분이 헷갈렸음. 프로그램이 실제로 써야 하는 env var는 **평문 주입**될 수밖에 없음. 저장 시 암호화는 가능해도 실행 전에 결국 복호화돼야 하고, 이건 Vercel 문제가 아니라 시스템 구조 자체의 한계임. 언젠가 완전 동형암호로 개선될 수도 있겠지만 전체 프로그램에 오버헤드가 너무 커서 아직은 현실적이지 않음
  - 유출 사고만 나면 “암호화했어야지”라고 외치는 경우가 많은데, 정작 **암호화의 한계**를 원리와 실무 양쪽에서 이해하지 못하는 경우가 많다고 느낌. 암호화는 secure나 safe의 동의어가 아님
  - Vercel에서 정확히 어떻게 동작하는지는 모르지만, 다른 플랫폼에서는 보통 이 표시가 있으면 **로그에서도 마스킹**되는 의미인 경우가 많았음
  - 내가 일하는 곳은 Vault를 쓰기 시작했고, vault key 조회용 키는 일반적인 비숨김 env var에 넣음. 이 방식이 아마 더 **탄탄한 구조**라고 생각함
  - 이건 다른 클라우드도 비슷하게 함. 예를 들면 **DigitalOcean**도 같은 식임

- 쉬운 희생양 만들기를 하고 싶진 않지만, 그래도 Context.ai 직원이 업무용 장비에서 게임을 하고, 거기에다가 출처가 의심스러운 **치트 프로그램**까지 설치한 건 어떻게 봐야 하나 싶음. defense in depth나 보안 계층 얘기는 당연히 맞지만, 여기에는 개인 책임도 분명 있다고 봄. Vercel 쪽 실수는 회사와 경영진 차원의 방어 실패로 볼 수 있어도, 치트 설치는 정말 별개로 심각해 보임
  - AI를 도입하는 회사들 전반에서 **OpSec 수준**이 낮다고 봄. 지금은 보안이 의사결정의 핵심 기능이 아니기 때문임. 2년 전 McDonalds 침해 사례만 봐도 비슷한 흐름이 보임
  - 그 직원이 정말 업무용 장비에 그걸 설치했는지는 아직 모른다고 봄. 적어도 이 기사에는 없고 다른 출처에서도 못 찾았음. 많은 회사가 사내망 VPN 접속이나 일부 내부 시스템의 인터넷 직접 로그인을 허용하기도 하는데, 바람직하진 않아도 생각보다 흔한 일임. Disney 해킹도 개인 PC에 설치한 손상된 소프트웨어에서 시작됐던 걸 떠올리게 됨. 내가 직접 봐온 바로는 많은 회사의 IT는 **생각보다 훨씬 허술**함
  - 나는 오히려 사용자가 임의 소프트웨어를 설치할 수 있게 둔 **IT 부서**를 더 탓하겠음
  - 나도 전적으로 동의함. 업무와 사적 용도를 한 대의 노트북에서 같이 처리한다는 발상 자체가 이미 꽤 무리라고 느낌. 시가총액 세계 상위 10위권 기업 중 하나에서는 엔지니어 책상에 인터넷이 안 되는 업무용 컴퓨터와, 다른 네트워크에 연결된 인터넷용 컴퓨터를 따로 두는 구조를 썼음. 내 주 작업 장비는 소리도 안 남. **사운드조차 없음**. 대부분 사람은 소리 안 나는 메인 업무 컴퓨터로도 충분히 일할 수 있다고 봄. 나는 기술 혐오자도 아니고 NUC, Raspberry Pi, 노트북도 많이 쓰지만, 메인 업무 장비로 YouTube를 보거나 게임을 할 필요는 전혀 없음. 회의용은 다른 노트북, 영상 시청도 다른 노트북이면 됨. 커피숍에도 들고 가고 회사에도 들고 가는 그 노트북으로 게임까지 하는 문화가 Vercel을 무너뜨렸고, 앞으로도 많은 회사를 무너뜨릴 거라고 봄
  - 그건 여러 원인 중 하나일 뿐이라고 봄. 물론 나쁜 선택이지만, 다른 시스템의 보안이 “업무용 노트북이 절대 해킹당하지 않을 것”에만 의존해서는 안 됨. 그게 유일한 방어선이면 결국 문제를 맞게 됨

- 이 기사에는 부정확한 부분이 있다고 봄. Vercel env var는 모두 **at rest 암호화**되어 있고, `sensitive` 체크는 설정 후 값을 다시 조회할 수 없게 만드는 의미라서 이번 같은 상황에선 오히려 도움이 됐을 것 같음. 그리고 출처 링크 하나 없이 이런 글을 읽는 것도 꽤 거슬렸음
  - 여기 UI 결정은 좀 흥미로움. 환경 변수 목록이 마치 비밀번호처럼 가려져 있고 보기 버튼도 있어서, advisory를 읽기 전에는 **sensitive 플래그**가 얼마나 중요한지 바로 눈에 잘 안 들어왔음. 우리도 민감 표시가 안 된 비밀값들이 있어서 지금 회전 작업을 바쁘게 하고 있음
  - 그런데 일부 고객 env var가 실제로 노출된 건 맞으니, 그럼 **암호화 안 된 것** 아닌가 하는 생각도 들었음

- 지난 1년 동안 내가 직접 승인한 AI 도구를 대략 12개 점검해봤는데, 그중 9개가 Google Workspace에서 **모든 이메일 읽기**와 Drive 전체 접근 권한을 요구하고 있었음. 게다가 나는 온보딩 중에 바빠서 권한도 제대로 안 읽고 전부 승인했음. 기술에 익숙한 사람들도 진짜 이렇게 하는지 궁금함. 나는 누군가에게 이메일과 Google Drive 접근을 주는 건 밤잠 설칠 정도로 꺼려지고, 권한도 최대한 세분화해서 주며 안 쓰는 앱은 바로 철회하려고 함. 저 정도면 메일 속 NDA 정보나 기밀은 이미 유출됐다고 가정해야 맞다고 느낌
  - 내 직장에서 다른 팀이 산 AI 회의록 도구와 Google Workspace를 연동하는 일을 도와달라는 요청을 받았음. 벤더는 이메일과 Drive 파일 읽기·쓰기를 위해 **Domain-wide Delegation**을 설정하라고 했고, 그렇게 하면 조직 전체 사용자가 자동으로 opt-in되며 거부도 불가능했음. 그래서 나는 벤더에 연락해 사용자가 직접 로그인하고 OAuth 권한창을 수락하는 “덜 권장되는” 방식을 따로 열어달라고 요청했음. 그런데 그 과정 내내 벤더와 우리 조직 모두 이걸 시간 낭비처럼 취급했음. 누가 넓은 권한을 자발적으로 주고 싶다면 그건 각자 선택이지만, 핵심 도구도 아닌데 전 직원에게 거부권 없이 켜버리는 건 **비윤리적**이라고 느낌. 보안 우려는 말할 것도 없음. 더 무서운 건 AI와 조금이라도 관련되면 사람들이 생각을 멈춘다는 점임. 5년 전만 해도 이런 요청을 안 했을 똑똑한 사람들이 이제는 남들도 다 하니까 괜찮다고 여김
  - 나는 개인적으로 그렇게 안 함. 며칠 전 본 “안전하려는 사람은 결국 Stallman식 수도원 컴퓨팅으로 수렴한다”는 말이 머릿속에 남아 있음. [https://news.ycombinator.com/item?id=47796469#47797330](https://news.ycombinator.com/item?id=47796469#47797330) 정말 웃기면서도 사실 같음. 내 개인 데이터를 마음껏 다루는 **에이전트 자동화**의 이득을 누리고 싶긴 하지만, 나는 참고 있음. 놓치는 멋진 기능들이 아쉽긴 해도 권한은 현재만의 문제가 아님. 한 번 주면 사실상 계속 가지게 됨
  - 그런 일은 아주 흔하다고 확신함. **권한 피로감**과 팝업 피로는 현실임. 요즘 앱과 웹사이트는 사용자가 원래 하려던 일에 도달하기 전에 수십 개 팝업을 던지고, 그중 상당수는 마케팅이고 일부는 멍청한 법무 요구이며 일부만 중요함. 결국 사람은 “그래, 알았으니까 그냥 진행”을 누르게 되고 보안은 창밖으로 날아감. 늘 기억하는 건, 컴퓨터 보안이라는 건 사실상 환상에 가깝고 네트워크에 연결된 컴퓨터의 데이터는 **준공개 정보**처럼 취급해야 한다는 점임. 인터넷 연결된 컴퓨터 위에 현대 인프라 대부분이 올라가 있다는 사실은 굳이 깊게 생각하지 않는 편이 정신 건강에 좋음
  - 현실은 이렇다고 느낌. 상사는 “오늘 오후 큰 회의 전에 일단 대충 만들어”라고 하고, 엔지니어는 설정 중에 **전부 동의**한 뒤 나중에 정리하면 된다고 생각함. 그리고 6개월 뒤 그 급조 데모가 그대로 프로덕션이 됨
  - 나는 그걸 “바빠서 읽지 않고 승인했다”로 보지 않음. 실제로는 온보딩이 권한을 요구했고, **거절할 기회 자체가 없었기 때문**이라고 봄. 거절하면 앱을 못 쓰게 되니까 사실상 강요임. 이 개념 자체가 잘못됐다고 느낌. 사용자는 “거부”를 눌러도 앱에 거부 사실이 전달되지 않고, 그저 요청 데이터가 비어 있는 것처럼 보여야 맞음. 그러면 앱은 원하는 권한을 물어볼 수 있고, 사용자는 권한을 주지 않은 채 앱도 계속 쓸 수 있음. 그게 진짜 해결책이라고 봄

- 추측하자면 이건 아무 Google Workspace 앱이 아니라 아마 **Gmail 접근권** 문제였을 가능성이 큼. 공격자가 피해자의 받은편지함에 넓게 접근했고, 그 뒤 magic link나 일회용 코드로 일부 내부 시스템에 로그인했을 것 같음. 그렇다면 왜 2FA가 없었는지, 그리고 애초에 왜 그렇게 광범위한 접근을 허용했는지가 궁금해짐. 그게 아니라면 다른 가능성은 Google Workspace 안에 API 자격증명을 저장해뒀던 경우 정도인데, 가능은 해도 꽤 이상한 구조라고 느낌

- 고작 **Roblox 치트**였다니 어이가 없음. 우리 아들도 Roblox 치트 때문에 계정이 털린 적 있어서 심각하다고 느꼈는데, 그때는 Gamepass 쿠키를 빼가서 Minecraft 라이선스 4개를 샀고 Microsoft가 빨리 환불해준 정도였음
  - 이 말은 사실상 Vercel이 **10대 스크립트 키디**들에게 뚫렸다는 뜻처럼 들림. 다만 긍정적으로 보자면 체포 소식도 곧 나올 수 있다고 기대함
  - 나는 애초에 왜 게임 치트가 실행 가능했는지가 궁금함. 이런 회사들은 **디바이스 통제**가 없거나, 있어도 신경을 안 쓰는 건가 싶음. 직원이 LastPass Plex 사건 같은 실수를 반복한 느낌임

- 이 기사에서 **브라우저 검증 실패** 오류가 뜨고 있음
  - 아이러니하게도 그 사이트가 **Vercel 호스팅**이라는 점이 웃김

- “그 체크박스가 있는 줄 개발자 몇 명이나 알았을까, 그리고 DB 자격증명과 API 키가 기본 암호화라고 몇 명이나 가정했을까”라는 문장을 보고 나는 반대로 생각했음. 비밀값 입력칸에 별표가 안 보이면 저장 버튼부터 안 누름. 혹시 프로그래밍 방식으로 넣었을 수도 있겠지만, 그 경우에도 최소한 **secret 플래그** 비슷한 건 명시했어야 한다고 봄. Vercel 같은 회사에서 이런 문제가 나왔다는 것 자체가 좀 이상하게 느껴짐
  - 이런 입력칸에는 누군가가 민감 정보를 넣을 거라고 **기본 가정**해야 함. 그래서 기본 암호화가 유일하게 합리적인 선택이라고 봄
  - 다리 엔지니어에게 “혹시 교각 보강 빼먹으셨어요?”라고 묻지는 않듯이, 보안 지식이 부족했을 때조차 이런 건 **기본 중 기본**이라고 생각했음. 평문으로 민감 정보를 저장했다가 되돌아온 결과를 맞은 사람들이 화내는 건 이해하지만, 결국 자기 관행의 대가를 치른 면도 있음. 그렇다고 피해자 비난만 하자는 건 아니고, Vercel도 이 황당한 상황에 대한 책임을 분명 져야 한다고 봄. 그래도 결국 FAFO라는 느낌이 남음

- 정말 아이러니하게도, 이제는 보안 체크를 더 강화한 것 같음. 구버전 Firefox로 원문을 읽으려 하니 **Failed to verify your browser**와 `Code 11`, `Vercel Security Checkpoint` 메시지만 나왔음. 솔직히 꽤 짜증났음