작성자 사이트가 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 정말 웃기면서도 사실 같음. 내 개인 데이터를 마음껏 다루는 에이전트 자동화의 이득을 누리고 싶긴 하지만, 나는 참고 있음. 놓치는 멋진 기능들이 아쉽긴 해도 권한은 현재만의 문제가 아님. 한 번 주면 사실상 계속 가지게 됨
그런 일은 아주 흔하다고 확신함. 권한 피로감과 팝업 피로는 현실임. 요즘 앱과 웹사이트는 사용자가 원래 하려던 일에 도달하기 전에 수십 개 팝업을 던지고, 그중 상당수는 마케팅이고 일부는 멍청한 법무 요구이며 일부만 중요함. 결국 사람은 “그래, 알았으니까 그냥 진행”을 누르게 되고 보안은 창밖으로 날아감. 늘 기억하는 건, 컴퓨터 보안이라는 건 사실상 환상에 가깝고 네트워크에 연결된 컴퓨터의 데이터는 준공개 정보처럼 취급해야 한다는 점임. 인터넷 연결된 컴퓨터 위에 현대 인프라 대부분이 올라가 있다는 사실은 굳이 깊게 생각하지 않는 편이 정신 건강에 좋음
현실은 이렇다고 느낌. 상사는 “오늘 오후 큰 회의 전에 일단 대충 만들어”라고 하고, 엔지니어는 설정 중에 전부 동의한 뒤 나중에 정리하면 된다고 생각함. 그리고 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 메시지만 나왔음. 솔직히 꽤 짜증났음
Hacker News 의견들
글이 AI 생성물처럼 너무 강하게 느껴짐. 일부러 문법을 어색하게 섞어 숨기려 한 것 같지만, 그게 내용의 정확성과는 별개인지까지는 확신이 안 듦
여기서 말하는 “sensitive” 해석은 틀렸다고 봄. 내가 알기로 Vercel의 env var는 전부 저장 시점에는 암호화되어 있고, sensitive 체크박스는 개발자가 UI에서 그 값을 다시 볼 수 없게 만드는 의미임. 즉 write-only에 가까운 개념이고, 앱은 env var를 통해 값을 볼 수 있어야 하니 앱도 못 읽게 암호화하는 건 애초에 무의미함. 체크를 안 하면 프로젝트 UI에서 값을 볼 수 있고,
DEFAULT_TIME_ZONE같은 일반 설정값에는 그 편이 더 실용적임. 그래서 sensitive는 암호화 여부가 아니라 UI 노출 여부를 뜻한다고 이해함. Vercel 직원은 아니지만 좀 써봤고, 이 부분을 비판하는 건 허수아비 논증처럼 보임쉬운 희생양 만들기를 하고 싶진 않지만, 그래도 Context.ai 직원이 업무용 장비에서 게임을 하고, 거기에다가 출처가 의심스러운 치트 프로그램까지 설치한 건 어떻게 봐야 하나 싶음. defense in depth나 보안 계층 얘기는 당연히 맞지만, 여기에는 개인 책임도 분명 있다고 봄. Vercel 쪽 실수는 회사와 경영진 차원의 방어 실패로 볼 수 있어도, 치트 설치는 정말 별개로 심각해 보임
이 기사에는 부정확한 부분이 있다고 봄. Vercel env var는 모두 at rest 암호화되어 있고,
sensitive체크는 설정 후 값을 다시 조회할 수 없게 만드는 의미라서 이번 같은 상황에선 오히려 도움이 됐을 것 같음. 그리고 출처 링크 하나 없이 이런 글을 읽는 것도 꽤 거슬렸음지난 1년 동안 내가 직접 승인한 AI 도구를 대략 12개 점검해봤는데, 그중 9개가 Google Workspace에서 모든 이메일 읽기와 Drive 전체 접근 권한을 요구하고 있었음. 게다가 나는 온보딩 중에 바빠서 권한도 제대로 안 읽고 전부 승인했음. 기술에 익숙한 사람들도 진짜 이렇게 하는지 궁금함. 나는 누군가에게 이메일과 Google Drive 접근을 주는 건 밤잠 설칠 정도로 꺼려지고, 권한도 최대한 세분화해서 주며 안 쓰는 앱은 바로 철회하려고 함. 저 정도면 메일 속 NDA 정보나 기밀은 이미 유출됐다고 가정해야 맞다고 느낌
추측하자면 이건 아무 Google Workspace 앱이 아니라 아마 Gmail 접근권 문제였을 가능성이 큼. 공격자가 피해자의 받은편지함에 넓게 접근했고, 그 뒤 magic link나 일회용 코드로 일부 내부 시스템에 로그인했을 것 같음. 그렇다면 왜 2FA가 없었는지, 그리고 애초에 왜 그렇게 광범위한 접근을 허용했는지가 궁금해짐. 그게 아니라면 다른 가능성은 Google Workspace 안에 API 자격증명을 저장해뒀던 경우 정도인데, 가능은 해도 꽤 이상한 구조라고 느낌
고작 Roblox 치트였다니 어이가 없음. 우리 아들도 Roblox 치트 때문에 계정이 털린 적 있어서 심각하다고 느꼈는데, 그때는 Gamepass 쿠키를 빼가서 Minecraft 라이선스 4개를 샀고 Microsoft가 빨리 환불해준 정도였음
이 기사에서 브라우저 검증 실패 오류가 뜨고 있음
“그 체크박스가 있는 줄 개발자 몇 명이나 알았을까, 그리고 DB 자격증명과 API 키가 기본 암호화라고 몇 명이나 가정했을까”라는 문장을 보고 나는 반대로 생각했음. 비밀값 입력칸에 별표가 안 보이면 저장 버튼부터 안 누름. 혹시 프로그래밍 방식으로 넣었을 수도 있겠지만, 그 경우에도 최소한 secret 플래그 비슷한 건 명시했어야 한다고 봄. Vercel 같은 회사에서 이런 문제가 나왔다는 것 자체가 좀 이상하게 느껴짐
정말 아이러니하게도, 이제는 보안 체크를 더 강화한 것 같음. 구버전 Firefox로 원문을 읽으려 하니 Failed to verify your browser와
Code 11,Vercel Security Checkpoint메시지만 나왔음. 솔직히 꽤 짜증났음