AI가 코드를 쓰는 동안, 비밀번호는 새어나갔다

GitGuardian 2026 보고서가 보여주는 시크릿 유출의 실체

GitGuardian 2026 보고서가 보여주는 시크릿 유출의 실체

# AI가 코드를 쓰는 동안, 비밀번호는 새어나갔다

지난해, 누구나 볼 수 있는 GitHub에 새로 노출된 비밀번호와 API 키가 2,865만 개였다.

하루로 치면 약 7만 8,500개. 매 분마다 인터넷 어딘가에 누군가의 데이터베이스 접속 정보가 풀리고 있었다는 뜻이다. API 키, 비밀번호, 인증 토큰, 클라우드 접속 정보가 쉬지 않고 공개 인터넷에 흘러나오고 있었다.

그리고 그 증가분의 상당 부분은, 우리가 열광적으로 도입한 AI 코딩 도구가 만들어냈다.

GitGuardian이 매년 발간하는 시크릿 유출 추적 보고서의 2026년판은 충격적인 수치로 시작한다. 전년 대비 34%라는 역대 최대 증가폭. 같은 기간 공개 GitHub 커밋 수는 19.4억 건으로 43% 늘었고, 개발자 수도 33% 증가했다. 플랫폼이 커진 만큼 유출도 늘었다고 볼 수도 있다. 하지만 핵심은 유출률 자체가 커밋 증가율을 앞질렀다는 점이다. 파이가 커진 게 아니라, 파이에서 새어나오는 비율 자체가 높아진 것이다.

더 불편한 사실이 있다. 이것은 공개 저장소만의 수치다. 사내 Git 서버, 비공개 저장소, 로컬 개발 환경까지 합치면 실제 규모는 이보다 훨씬 크다. GitGuardian은 이전 보고서에서 비공개 저장소의 시크릿 탐지 건수가 공개 저장소를 넘어선다고 밝힌 바 있다. 우리가 보는 2,865만이라는 숫자는 빙산의 수면 위 부분에 불과하다.

수면 아래에는 몇 배나 되는 시크릿이 잠겨 있을지 아무도 모른다. 확실한 건 하나다. 우리가 측정할 수 있는 것만으로도 이미 위기라는 사실이다.

코드를 더 빨리 쓰게 해준 도구가, 비밀도 더 빨리 새어나가게 만들고 있다.

AI가 도와준 커밋의 시크릿 유출률은 3.2%다. 일반 커밋의 1.5%와 비교하면 약 2.1배. Copilot을 사용하는 저장소로 범위를 좁히면 유출률이 6.4%까지 치솟는다. 같은 조건의 베이스라인이 4.6%이니, 40%나 더 높은 셈이다.

왜 이런 일이 벌어질까. 원인은 세 갈래다.

첫 번째는 맥락 오염이다. Claude Code, Cursor, Copilot, Windsurf 같은 AI 코딩 도구들은 작업 효율을 위해 프로젝트의 환경 설정 파일을 자동으로 읽어들인다. 이 과정에서 API 키와 데이터베이스 비밀번호가 AI 모델에 전달되고, AI가 만드는 코드에 그 값이 하드코딩 형태로 스며든다. 비서에게 금고 비밀번호를 알려줬더니, 회의록에 적어서 전사 메일로 보낸 격이다.

두 번째는 훈련 데이터의 잔재다. Copilot이 과거에 학습한 크리덴셜을 전혀 관련 없는 코드에 삽입하는 사례가 보고서에서 확인됐다. AI가 "여기엔 API 키가 들어가야겠군"이라고 판단하면, 기억 속에서 무언가를 꺼내 넣는 것이다. 실제로 존재했던 키가 전혀 다른 프로젝트에 유령처럼 나타나는 셈이다. 누군가의 비밀번호가 AI의 기억에 남아서, 전혀 모르는 사람의 코드에 써지는 소름 끼치는 일이 벌어지고 있다.

세 번째는 속도가 만드는 방심이다. AI 코딩 도구의 가장 큰 가치는 속도다. 수십 줄의 코드가 몇 초 만에 만들어진다. 하지만 빠른 생성은 느슨한 검토로 이어진다. 사람은 직접 한 줄씩 쓸 때보다 AI가 만들어준 코드를 읽을 때 경계심이 떨어진다. 코드 리뷰도 AI가 쏟아내는 대량의 변경분을 소화하기 어려워지면서, 그 안에 숨은 시크릿이 통과해버리는 확률이 높아진다.

여기에 아이러니가 하나 더 있다. AI 서비스 관련 키, 그러니까 OpenAI API 키나 Anthropic API 키, HuggingFace 토큰 같은 것들의 유출이 전년 대비 81%나 급증했다. AI를 쓰려고 발급한 키가, AI가 쓴 코드에 박혀서 유출되는 순환 고리가 만들어진 것이다. 도구가 도구 자신의 열쇠를 흘리고 있다.

결국 AI 코딩 도구는 보안 도구가 아니다. 코드를 더 빨리 쓰게 해준다고 해서, 시크릿을 더 잘 관리해주는 것은 아니다. 오히려 그 반대라는 것을 데이터가 말해주고 있다.

AI 에이전트 시대의 연결 표준이 된 MCP(Model Context Protocol)가 새로운 약한 고리로 떠올랐다.

2025년 12월 Anthropic이 MCP를 Linux Foundation 산하 Agentic AI Foundation에 기부하면서, MCP는 사실상의 표준 프로토콜이 됐다. 월간 SDK 다운로드 9,700만 건, 활성 서버 1만 개 이상. ChatGPT부터 Claude, Cursor, Gemini, VS Code까지 주요 플랫폼이 MCP를 네이티브로 지원한다.

문제는 이 폭발적 성장 속에서 보안이 뒤처졌다는 것이다.

공개 GitHub에서 MCP 설정파일 2만 4,008개에서 시크릿이 발견됐고, 그중 2,117개는 실제로 작동하는 살아있는 인증 정보였다. 유효한 API 키, 데이터베이스 비밀번호, OAuth 토큰이 누구나 볼 수 있는 곳에 놓여 있었다는 뜻이다.

원인은 놀랍도록 단순하다. 인기 있는 MCP 셋업 가이드들이 API 키를 설정파일에 직접 넣으라고 안내하고 있기 때문이다. 커맨드라인 인자에 비밀번호를 평문으로 넣고, JSON 설정파일에 접속 정보를 그대로 적는 패턴이 "공식적인" 시작 방법으로 퍼져나갔다. 냉장고 비밀번호를 냉장고 문에 포스트잇으로 붙여놓은 격이다. 그리고 그 설정파일이 gitignore에 포함되지 않은 채 GitHub에 올라갔다.

이 틈을 노린 의도적인 공격도 등장했다. 올 2월 Socket의 위협 연구팀이 발견한 SANDWORM_MODE는 19개의 가짜 npm 패키지를 통해 퍼지는 다단계 공급망 공격이다. 기존 공격과 근본적으로 다른 점이 있다. AI 코딩 도구를 직접 감염시킨다는 것이다.

공격은 두 단계로 진행된다. 처음에는 환경 변수와 암호화폐 키를 훔친다. 그리고 48시간이 지나면 본색을 드러낸다. Claude Code, Claude Desktop, Cursor, VS Code Continue, Windsurf의 MCP 설정을 변조해서 악성 서버를 심는다. 개발자 눈에는 AI가 평소처럼 코드를 쓰는 것처럼 보인다. 하지만 뒤에서는 환경 설정 파일, SSH 키, 클라우드 인증 정보가 빠져나가고 있다. 평소와 똑같이 일하는 비서가, 사실은 매일 밤 서류를 복사해서 밖으로 보내고 있는 것과 같다.

전파 방식도 정교하다. 감염된 머신의 Git 인증 토큰과 npm 토큰을 스캔한 뒤, 유효한 것을 발견하면 다른 프로젝트에 악성 의존성을 추가한다. 피해자의 계정으로 직접 push하거나 감염된 패키지를 배포하기도 한다. 악성 Git 훅을 설치해서 개발자가 코드 작업을 할 때마다 페이로드를 재실행한다. AI 도구의 설정 파일이 새로운 공격 통로가 된 것이다.

내일부터 뉴욕에서 열리는 MCP Dev Summit에서 95개 이상의 세션이 예정되어 있는데, MCP 보안 거버넌스가 핵심 의제 중 하나다. Coalition for Secure AI도 MCP 보안 실무 가이드를 발행하며 이 문제에 대응하고 있다. MCP가 표준이 된 것은 분명하지만, 보안 표준은 아직 만들어지는 중이다.

시크릿은 코드 저장소에서만 새는 게 아니다. 오히려 더 위험한 곳은 우리가 매일 쓰는 협업 도구다.

전체 시크릿 유출 사고의 약 28%가 Slack, Jira, Confluence 같은 플랫폼에서 발생한다. 그리고 이 경로의 유출은 코드 유출보다 13%p 더 높은 확률로 심각한 등급을 받는다.

Jira 티켓의 6.1%가 시크릿을 품고 있다. 로그나 설정 스니펫에 크리덴셜이 포함된 채 티켓에 붙여넣어진 것이다. Slack 채널의 2.4%에서도 키가 발견된다. 장애 대응 중 급히 공유된 것들이다. Confluence 위키 스페이스의 0.5%도 시크릿을 담고 있는데, 비율은 낮지만 위키 특성상 수년간 방치된다.

패턴은 늘 같다. 새벽 3시, 서버가 죽었다. 온콜 엔지니어가 Slack에 "이 키로 접속해봐"라고 급히 던진다. 장애는 해결된다. 하지만 그 메시지는 삭제되지 않는다. 119에 전화하면서 현관 비밀번호를 소리쳐 알려준 뒤, 위기가 끝나도 바꾸지 않는 것과 같다. 그 비밀번호는 누구든 검색하면 찾을 수 있는 상태로 무기한 남는다.

코드 저장소에는 이미 GitHub Push Protection이나 GitGuardian 같은 탐지 도구가 자리 잡았다. 하지만 Slack이나 Jira에 시크릿 스캐닝을 운영하는 조직은 극소수다. 방어가 가장 약한 곳이 공격자에게는 가장 매력적인 문이다. 게다가 AI 에이전트의 확산이 이 문제를 증폭시킨다. AI가 Slack을 읽고, Jira 티켓을 참조하고, Confluence를 크롤링하면서, 거기 남아 있던 시크릿이 AI의 맥락에 자동으로 주입되어 의도치 않은 2차 유출의 씨앗이 된다.

어쩌면 이 보고서에서 가장 불편한 숫자는 따로 있다. 2022년에 유출된 시크릿의 64%가 4년째 폐기되지 않고 살아 있다.

화재 경보가 울린 지 4년이 지났는데, 아직 불을 끄지 않은 셈이다. 그 사이 탐지 기술은 세 세대를 지났다. GitHub은 올 3월에만 28개의 새 시크릿 탐지기를 추가하고, 39개에 대해 Push Protection을 기본 적용했다. 탐지는 점점 좋아지고 있다. 문제는 탐지가 아니라 폐기다.

시크릿 폐기가 실패하는 이유는 구조적이다. 유출된 키를 누가 만들었고, 어디에서 쓰이고 있고, 끄면 뭐가 깨지는지 아는 사람이 없는 경우가 많다. 퇴사자가 만든 키, 임시 프로젝트의 인증 정보, 공유 계정의 토큰이 사각지대에 놓인다. 프로덕션에서 쓰이는 키를 폐기했다가 서비스가 멈추면 어쩌나 하는 공포도 "일단 두자"는 결정으로 이어진다. 유출된 채로 두는 것이 단기적으로는 덜 위험해 보이는 역설이다.

화재 경보기를 달아놓고 스프링클러를 빼놓은 것과 다를 바 없다. 공격자에게 4년 동안 열린 문을 제공하고 있다는 뜻이다.

바이브 코딩의 확산이 이 문제를 한층 더 키운다. "로그인 시스템 만들어줘", "Stripe 결제 붙여줘" 한마디면 작동하는 코드가 나오는 시대. Cursor, Claude Code, Lovable, Replit 같은 도구들이 이 흐름을 이끌고 있다.

접근성은 혁명적이지만, 보안 측면에서는 새로운 구멍이 생긴다. "여기에 내 Stripe 키 넣어줘"라고 말하면, AI는 충실하게 그 키를 소스코드에 직접 써넣는다. 금고 비밀번호를 벽에 페인트로 칠해달라고 했더니, 정말로 칠해준 셈이다. 환경 변수를 쓰라는 보안 원칙을 AI가 스스로 적용하지 않는 한, 사용자가 보안을 모르면 보안은 적용되지 않는다. Replit에 따르면 바이브 코딩으로 만든 앱에서 노출된 시크릿의 78%가 하드코딩이 원인이다.

전통적인 개발에서는 코드를 쓰는 사람이 곧 보안을 이해하는 사람이었다. 적어도 그래야 했다. 하지만 바이브 코딩에서는 코드를 "쓰는" 사람이 시크릿 관리, 입력 검증, 권한 최소화 같은 개념 자체를 모를 수 있다.

올 2월 Moltbook 사건이 대표적이다. AI 에이전트용 소셜 네트워킹 사이트 Moltbook은, AI가 개발 중 열어놓은 Supabase 데이터베이스 설정을 그대로 프로덕션에 배포했다가, 보안 기업 Wiz에 의해 누구나 읽고 쓸 수 있다는 사실이 발각됐다. 정교한 해킹이 아니었다. AI가 만든 코드를 인프라 수준까지 검토하지 않은 것이 원인이었다.

Veracode의 GenAI Code Security Report에 따르면 AI 생성 코드의 약 45%에서 보안 취약점이 발견된다. Aikido Security의 2026년 보고서는 전체 보안 침해의 5건 중 1건이 AI 생성 코드 때문이라고 분석했다. 코드를 쓰는 사람과 보안을 책임지는 사람 사이의 간극이 극적으로 벌어지고 있다. 그리고 그 간극 사이로 시크릿이 쏟아져 나오고 있다.

다행히 방어도 빠르게 진화하고 있다.

GitHub의 Push Protection은 시크릿이 포함된 커밋의 업로드 자체를 차단한다. GitGuardian의 시크릿 스캐닝은 빌드 파이프라인에 통합되어 빌드 시점에도 시크릿을 잡아낸다. 로컬 환경에서부터 커밋을 막는 pre-commit 훅도 있다.

MCP 생태계에서는 볼트 기반 아키텍처가 근본적인 해법으로 떠오르고 있다. MCP 게이트웨이가 모든 외부 API 키를 암호화된 금고에 보관하고, AI 에이전트에게는 짧은 수명의 임시 토큰만 발급하는 구조다. 금고 열쇠 대신 한 번 쓰고 버리는 출입증을 주는 방식이다. AI 에이전트가 외부 서비스에 접근을 요청하면, 게이트웨이가 에이전트의 신원을 확인하고, 정책에 따라 필요한 시크릿을 그 자리에서 주입한다. 에이전트는 실제 시크릿을 절대 보지 못한다. 프롬프트에도, 로그에도, 메모리에도 남지 않는다. 1Password가 올 3월 AI 에이전트 보안을 위한 Unified Access 플랫폼을 출시한 것도 이 흐름의 일부다. Strata, BeyondTrust 같은 아이덴티티 보안 기업들도 MCP 서버 거버넌스 솔루션을 내놓고 있다.

탐지와 예방을 넘어, 시크릿의 수명 자체를 관리하는 것도 중요하다. HashiCorp Vault나 AWS Secrets Manager 같은 시크릿 매니저로 즉시 발급 방식을 구현하면, 각 작업에 맞는 단기 토큰이 발급되고 자동으로 만료된다. 장기 API 키 대신 작업별 단기 토큰을 발급하고, 각 토큰이 필요한 최소 권한만 갖게 하고, 주기적 교체를 사람이 아닌 시스템이 수행하는 것이다. 이 세 원칙이 함께 작동할 때, 탐지는 빠르지만 폐기는 느린 현재의 구조적 문제가 비로소 풀린다.

하지만 도구만으로는 부족하다. 결국 시크릿 관리가 개발자 개인의 습관이 아니라 인프라의 기본값이 되어야 한다.

그리고 이 모든 이야기가 허공의 경고가 아니라는 것을 증명하듯, 사건이 하나 터졌다. 그것도, 가장 터지면 안 되는 곳에서.

2026년 3월 31일, Anthropic이 npm에 배포한 Claude Code v2.1.88에 59.8MB짜리 소스맵 파일이 실수로 포함됐다. 약 51만 2천 줄, 1,900개 파일에 달하는 TypeScript 소스코드가 고스란히 담긴 파일이었다. npm은 공개 레지스트리다. 누구나 다운로드할 수 있다. 그리고 누군가는 실제로 그 파일을 GitHub에 미러링했다.

릴리즈 패키징 과정의 휴먼 에러였다고 Anthropic은 밝혔다. 고객 데이터 노출은 없다고도 덧붙였다. 기술적으로는 맞는 말이다. 하지만 이 사건의 본질은 데이터 유출이 아니다.

AI 코딩 도구를 만드는 회사가, npm 패키징 과정에서 자사의 소스코드를 통째로 유출한 것이다.

잠깐 멈춰서 생각해보자. 이 글에서 지금까지 이야기한 모든 것이 여기에 압축되어 있다. 빌드 파이프라인의 한 단계가 빠졌을 뿐인데, 수만 줄의 코드가 공개 인터넷에 풀렸다. 탐지도, 차단도, 리뷰도 없이. 누군가가 발견해서 알려줄 때까지.

시크릿 유출과 구조가 똑같다. 자동화된 파이프라인 어딘가에서 인간의 실수가 끼어들고, 그 실수를 잡아줄 안전장치가 없었고, 결과물은 되돌릴 수 없는 형태로 세상에 나왔다. 소스맵이 시크릿은 아니지만, 배포 과정의 취약함이 드러나는 방식은 정확히 같다.

그리고 아이러니의 무게가 있다. 개발자들의 코드 품질을 높여주겠다는 AI 코딩 도구가, 자기 자신의 코드를 지키지 못했다. 남의 시크릿을 스캔하고 보안을 강화하라고 말하는 도구의 제작사가, 가장 기본적인 패키징 검증에서 실수했다. 대장간에 칼이 없다는 속담이, 이렇게까지 정확하게 들어맞는 순간이 또 있을까.

이 사건은 경고다. 아무리 뛰어난 엔지니어링 조직이라도, 릴리즈 파이프라인에 한 겹의 확인 절차가 빠지면 모든 것이 새어나갈 수 있다. Anthropic이었기에 소스코드로 끝났지만, 다른 조직이었다면 그 59.8MB 안에 API 키와 내부 인증 정보가 들어 있었을 수도 있다.

속도는 무기다. 하지만 검증 없는 속도는 총구가 자기를 향한 무기다.

GitGuardian의 2026 보고서가 그리는 그림은 결국 하나의 질문으로 수렴한다. 속도의 대가를 보안으로 치를 것인가, 아니면 처음부터 보안을 속도의 일부로 만들 것인가.

AI가 코드를 대신 써주는 시대에, 시크릿의 수명은 곧 시크릿의 위험이다. 탐지에서 알림, 폐기, 교체까지 전체 생명주기를 자동화하지 않으면, 아무리 좋은 탐지 도구를 도입해도 투자 대비 효과는 제로에 수렴한다.

"코드 한 줄 안 썼다"는 자랑이 "보안 한 줄 안 챙겼다"가 되는 건 순식간이다.