2026년 3월, GitGuardian이 다섯 번째 State of Secrets Sprawl 보고서를 공개했다. 헤드라인 숫자는 충격적이다. 2025년 한 해 동안 공개 GitHub 커밋에서 탐지된 하드코딩 시크릿은 2,865만 건. 전년 대비 34% 증가로, GitGuardian이 기록한 역대 최대 단일 연도 증가폭이다. 그런데 이 숫자보다 더 주목해야 할 수치가 따로 있다.
AI 어시스턴트가 관여한 커밋의 시크릿 유출률은 3.2%, 전체 공개 커밋 베이스라인(1.5%)의 두 배다. AI 코딩 도구를 쓸수록 시크릿이 더 많이 새나간다는 실증 데이터다. 이 글에서 다루려는 핵심은 바로 이 역설이다—우리가 생산성 도구로 도입한 AI가, 동시에 보안 부채를 두 배로 키우고 있다.
구멍 1: 속도가 리뷰를 얕게 만든다
먼저 짚어둘 것이 있다. AI 코딩 도구가 '보안에 무지해서' 시크릿을 흘리는 게 아니다. GitGuardian 보고서는 이 점을 명확히 한다. 코드를 승인하고 커밋하는 건 여전히 사람이다. 문제는 워크플로우 자체가 바뀌었다는 데 있다.
AI 어시스턴트와 함께 일하면 시간당 리뷰하는 코드량이 늘고, 하루 커밋 수도 증가한다. 표면적으로는 생산성 향상이다. 그런데 AI가 생성한 코드 블록에서 API 키 하나를 놓치는 건 놀랍도록 쉽다. 그 키는 여느 config 값처럼 생겼고, 코드가 작동한다는 사실이 리뷰어의 경계심을 낮춘다. '동작하는 코드'와 '안전한 코드'는 다르다는 걸 알면서도, 속도 앞에서 그 구분이 흐려진다.
더 구조적인 문제는 모델의 학습 데이터다. AI 코딩 도구는 공개 레포지토리를 학습한다. 그 레포지토리에는 하드코딩된 API 키가 수백만 건 포함돼 있다. 모델은 나쁜 의도 없이, 학습 데이터에서 본 패턴을 그대로 재현한다. 도구 실패가 아니라 프로세스 갭이다. 속도는 올라갔는데 가드레일은 그대로다.
구멍 2: MCP 설정 파일이 새로운 공격 표면이 됐다
GitGuardian 보고서에서 별도 섹션으로 다룰 만큼 심각한 수치가 있다. MCP(Model Context Protocol) 관련 설정 파일에서 발견된 고유 시크릿이 24,008건이고, 그 중 2,117건은 실제 인증이 가능한 라이브 크리덴셜이었다. 스캔 시점에 공개 레포지토리에 접속 가능한 상태로 노출돼 있었다는 뜻이다.
이 문제의 뿌리는 문서에 있다. 공식 MCP 퀵스타트 가이드를 포함한 설정 튜토리얼 대부분이 API 키를 설정 파일이나 CLI 인자에 직접 넣는 패턴을 보여준다. 개발자들은 공식 문서를 따른다. 그 설정 파일이 커밋되면 시크릿이 함께 올라간다. .env 파일, Docker Compose, Kubernetes 매니페스트가 걸어온 길을 MCP가 빠른 속도로 반복하고 있는 셈이다.
실제 생태계 스캔 데이터도 이를 뒷받침한다. CraftedTrust가 4,275개의 MCP 서버를 12개 보안 카테고리로 스코어링한 결과, npm 패키지 기준 평균 신뢰 점수는 100점 만점에 54점이다. F학점이다. Astrix Security는 MCP 서버의 53%가 정적 시크릿(설정에 임베드된 API 키)을 사용한다고 보고했고, BlueRock Security는 7,000개 이상 서버의 36.7%가 SSRF에 잠재적으로 취약하다고 밝혔다.
MCP 서버가 일반 API와 다른 이유는 위상에 있다. 일반 API는 개발자가 제어하는 애플리케이션에 데이터를 반환한다. MCP 서버는 AI 모델이 다음 행동을 추론하는 데 직접 영향을 주는 데이터와 기능을 제공한다. 서버 하나가 침해되면 단순히 잘못된 데이터를 반환하는 게 아니라, 에이전트 전체의 행동을 조종할 수 있다. CyberArk 연구에 따르면 툴 포이즈닝 공격의 성공률은 자동 승인 모드에서 84.2%에 달했고, Claude 3.7 Sonnet조차 이를 거부한 비율은 3% 미만이었다.
구멍 3: 탐지 이후가 더 무너져 있다
보고서에서 가장 충격적인 숫자는 사실 AI와 직접 관련이 없다. 2022년에 탐지된 유효 시크릿 중 64%가 2026년에도 여전히 유효하다. 4년이 지나도록 폐기되지도, 교체되지도 않은 크리덴셜이 절반을 훌쩍 넘는다는 뜻이다.
이건 탐지 문제가 아니다. GitGuardian은 탐지했다. 문제는 탐지 이후다. 시크릿 소유자를 특정하고, 영향 범위를 평가하고, 폐기하고, 교체하고, 의존하는 모든 시스템을 업데이트하고, 정상 작동을 검증하는 일련의 프로세스—대부분의 조직에서 이 워크플로우는 존재하지 않거나 '소유자 확인' 단계에서 멈춘다.
AI 에이전트는 이 갭을 더 벌린다. 에이전트가 설정 파일에 시크릿을 하드코딩했을 때, 에이전트는 그 시크릿의 소유자가 누구인지, 어떤 서비스에 연결되는지, 교체 절차가 무엇인지 알지 못한다. 티켓을 열지도, 알림을 보내지도 않는다. 그냥 코드를 쓰고 넘어간다. LiteLLM PyPI 공급망 공격 사례가 이를 극명하게 보여준다. 2026년 3월 25일, 손상된 버전이 배포됐을 때 에이전트들이 스타트업 시점에 메모리에 올려둔 환경 변수, SSH 키, 클라우드 크리덴셜이 그대로 수집됐다. 공격이 정교해서가 아니라, 크리덴셜이 정확히 공격자가 찾을 자리에 있었기 때문이다.
AI-First 팀이 지금 당장 바꿔야 할 것
세 가지 구멍의 공통 원인은 하나다. 속도는 올라갔는데 보안 인프라는 그대로다. 처방도 세 가지로 대응한다.
첫째, 커밋 파이프라인에 시크릿 스캐닝을 의무화하라. AI 어시스턴트가 관여하는 모든 프로젝트에 pre-commit 훅을 달아야 한다. GitGuardian, TruffleHog, detect-secrets 중 어느 것이든 좋다. 2배의 유출률이 이미 수학적으로 이걸 강제한다. 선택이 아니다.
둘째, MCP 설정 파일을 .env와 동급으로 취급하라. .cursor/mcp.json, claude_desktop_config.json 같은 파일은 커밋하지 않는다. .gitignore에 추가하고, Slack에 공유하지 않으며, 문서에 붙여 넣지 않는다. 설치된 MCP 서버 목록을 주기적으로 감사하고, 신뢰 점수 40점 미만인 서버는 즉시 검토 대상으로 올린다.
셋째, 에이전트가 크리덴셜을 '보유'하지 않도록 아키텍처를 바꿔라. 스타트업 시점에 모든 크리덴셜을 환경 변수로 올려두는 구조는 공격 표면이 프로세스 전체다. 볼트 기반 아키텍처—필요한 순간에만 특정 시크릿을 fetch하고, 즉시 사용한 뒤 메모리에서 내리는—로 전환하면 침해 시 블래스트 레디우스를 단일 크리덴셜 수준으로 제한할 수 있다. HashiCorp Vault처럼 엔터프라이즈 플랫폼이 아니더라도, 개발자 규모에서 구현 가능한 vault 패턴은 지금 당장 적용할 수 있다.
마치며: 속도의 청구서
AI-First 워크플로우의 속도 이점은 실재한다. 그런데 지금까지 그 청구서의 일부를 보안 부채로 미뤄온 것도 사실이다. 29만 건이 아니다, 2,865만 건이다. 추정치가 아니라 카운트다. 이 숫자는 AI 도구가 나빠서가 아니라, 도구의 속도에 맞는 보안 인프라 설계를 뒤로 밀어뒀기 때문에 나왔다.
MCP 생태계는 지금 .env 파일과 Docker Compose가 수년 전 겪었던 학습 곡선을 압축된 시간 안에 반복하고 있다. 그때는 툴링이 따라잡는 데 몇 년이 걸렸다. 지금은 그 시간이 없다. AI-First 팀이 보안 인프라 설계를 '나중에 할 일'로 남겨두는 것, 그게 지금 가장 비싼 기술 부채다.