빠르게 달리는 팀일수록 구멍이 먼저 난다
속도는 AI-First 팀의 가장 큰 자산이다. 동시에 가장 큰 리스크이기도 하다. GitGuardian의 State of Secrets Sprawl 2026 리포트에 따르면 2025년 한 해 동안 공개 GitHub 커밋에 새로 추가된 하드코딩 시크릿은 2,865만 건으로, 전년 대비 34% 증가했다. 단일 연도 기준 역대 최대 증가폭이다. 같은 기간 GitHub 커밋 수는 43%, 활성 개발자 수는 33% 늘었다. AI 코딩 어시스턴트가 소프트웨어 생산의 문턱을 낮추면서, 만드는 속도와 관리하는 속도 사이의 간격이 벌어지고 있다.
이 간격은 세 곳에서 동시에 터진다. 보안(시크릿 유출), 생산성(설계 없는 코딩), 비용(MCP 토큰 낭비). 각각을 독립된 문제로 보면 각개격파할 수 있을 것 같지만, 실제로는 같은 원인에서 나온다. "일단 만들고 보자"는 관성이다.
구멍 1: AI가 코드를 빠르게 쓸수록 시크릿도 빠르게 새어 나간다
리포트에서 눈에 띄는 수치가 있다. AI 서비스 관련 시크릿 유출이 전년 대비 81% 증가해 127만 건을 넘겼다. 가장 빠르게 성장한 탐지 유형 10개 중 8개가 AI 서비스와 연결돼 있었다. DeepSeek API 키 11만 3,000건 유출은 그 단면이다.
Claude Code 기반 커밋의 시크릿 유출률은 3.2%로, 전체 공개 GitHub 기준 1.5%의 두 배가 넘는다. 이걸 두고 "도구 문제"라고 읽으면 오독이다. 코딩 어시스턴트가 경고를 띄워도 개발자가 무시하거나 우회를 요청할 수 있다. 유출은 여전히 인간 워크플로우를 통해 일어난다. 시간 압박 아래 복잡한 시스템에서 로컬 결정을 내리는 사람의 문제다.
MCP 설정 파일도 새로운 노출면이 됐다. 공개 GitHub에서 MCP 관련 설정 파일에 노출된 고유 시크릿이 24,008건, 그중 유효한 자격증명만 2,117건이다. 원인의 일부는 공식 문서 자체에 있다. 많은 MCP 설정 가이드가 API 키를 설정 파일이나 커맨드라인 인수에 직접 넣는 패턴을 예시로 보여준다. 공식 퀵스타트가 불안전한 패턴을 정상화하면, 그 패턴은 생태계 속도로 퍼진다.
더 불편한 사실은 내부 레포가 더 위험하다는 점이다. 내부 저장소는 공개 저장소보다 하드코딩 시크릿을 포함할 확률이 약 6배 높다. "어차피 내부니까"라는 안도감이 만드는 보안 부채다. 게다가 전체 시크릿 인시던트의 28%는 코드 저장소 밖, 즉 Slack·Jira·Confluence 같은 협업 도구에서 발생하며, 코드에서만 발견된 시크릿보다 치명도가 13%p 높다. 개발자 워크스테이션까지 공격 범위에 포함된다는 점도 주목할 필요가 있다. Shai-Hulud 공급망 공격 분석에서 확인된 6,943대의 침해 머신에서 추출된 고유 시크릿은 33,185건이었고, 이 중 59%는 개인 노트북이 아닌 CI/CD 러너였다.
리포트가 던지는 가장 냉혹한 숫자는 따로 있다. 2022년에 유출된 자격증명 중 2026년 1월 기준으로도 64%가 여전히 유효하다. 만들어진 것은 고쳐지지 않는다. AI가 생산 속도를 올릴수록, 고치지 않은 과거의 유출은 조용히 쌓인다.
구멍 2: 코드보다 먼저 터지는 건 "잘못된 것을 만드는" 실수다
보안만큼 치명적이지만 훨씬 조용히 터지는 구멍이 있다. 설계 없이 코딩을 시작하는 것이다. dev.to에 공개된 실무 사례가 이걸 단적으로 보여준다. 3일을 들여 실시간 WebSocket 알림 시스템을 만들었다. 뱃지 카운트, 읽음 상태, 세션 유지까지. 완성도 높은 코드였다. 그런데 제품팀이 원한 건 "누군가가 태스크를 할당했을 때 이메일 하나"였다. 3일이 증발했다. 코드가 나빠서가 아니라 잘못된 것을 만들었기 때문에.
AI 코딩 어시스턴트는 이 문제를 더 빠르게, 더 크게 만들 수 있다. 구현 속도가 빨라질수록 방향이 잘못됐을 때의 낭비도 커진다. @spec-writer와 @planner 같은 AI 기반 사전 설계 도구가 주목받는 이유가 여기 있다. 코드 한 줄 쓰기 전에 아이디어를 다듬고, 가정을 명시하고, 수직 슬라이스 단위로 태스크를 분해하는 과정을 AI와 함께 거치는 것이다.
핵심은 속도가 아니라 방향 검증의 비용이다. 요구사항 단계에서 수정하는 비용은 5분, 작동 중인 코드에서 수정하는 비용은 수 시간, 프로덕션 배포 후에는 수 일이다. AI가 빠르게 만드는 것을 돕는다면, 설계 단계에서 방향을 확정하는 것도 AI가 도와야 한다. 구현 전 15분의 스펙 작성이 3~8시간의 재작업을 없앤다는 실측이 이를 뒷받침한다. 수직 슬라이스 방식의 태스크 분해는 추가로 "잘못된 순서로 만들다가 의존성 문제를 마지막에 발견하는" 패턴도 제거한다.
구멍 3: MCP 서버를 연결할수록 보이지 않는 토큰 세금이 쌓인다
MCP 서버를 팀 워크플로우에 통합하면서 놓치기 쉬운 것이 있다. 도구 정의 자체가 컨텍스트 윈도우를 차지한다는 사실이다. 실측 결과를 보자. @modelcontextprotocol/server-filesystem의 실제 tools/list를 tiktoken으로 측정한 결과: 14개 도구, 2,638 토큰, 200K 윈도우의 약 1.3%다. 서버 하나는 작다. 문제는 합산에 있다.
Anthropic 내부 데이터에 따르면 5개 서버 구성 시 약 55K 토큰, 최적화 전 내부 환경에서는 134K 토큰이 도구 정의만으로 소비됐다. 이 토큰은 매 턴마다 반복해서 청구된다. 한 번 내는 입장료가 아니라 라운드마다 내는 임대료다. 재정적 비용만의 문제가 아니다. 컨텍스트를 채운 도구 정의는 실제 대화, 검색된 문서, 붙여넣은 파일이 들어올 자리를 빼앗는다. Anthropic의 자체 테스트에서 모델이 동시에 보유하는 도구 수를 줄이자 도구 선택 정확도가 49%에서 74%로 올랐다. 토큰 세금은 비용 문제이면서 동시에 품질 문제다.
Claude Code의 Tool Search가 레이지 로딩으로 이 문제를 숨기긴 하지만, 도구가 실제로 호출될 때는 정의가 컨텍스트에 들어온다. 세금이 사라진 게 아니라 미뤄진 것이다. 팀이 MCP 서버를 확장하기 전에 먼저 해야 할 일은 각 서버가 얼마나 먹는지 측정하는 것이다. 자를 수 없는 것은 측정하지 않은 것뿐이다.
AI-First 팀에 필요한 것: 속도를 지키는 구조
세 구멍의 공통 원인은 하나다. 거버넌스가 생산 속도를 따라가지 못하는 것. AI는 만드는 속도를 올렸지만, 검증·설계·측정의 속도는 함께 올리지 않으면 부채가 쌓인다.
내일 당장 팀에서 시작할 수 있는 것은 단순하다. 첫째, 시크릿 스캐닝을 커밋 전 훅과 CI 파이프라인 양쪽에 건다. MCP 설정 파일을 별도 검사 대상에 추가한다. 둘째, 코딩 에이전트를 열기 전에 스펙 작성 단계를 강제한다. AI가 스펙 초안을 만들어도 좋다. 중요한 것은 가정이 명시되고 인간이 승인하는 게이트가 존재하는 것이다. 셋째, MCP 서버를 추가하기 전에 토큰 비용을 측정한다. 60초 스크립트 하나면 충분하다.
AI-First 워크플로우의 진짜 레버리지는 빠른 생성이 아니다. 빠른 생성을 안전하게 지속할 수 있는 구조를 가진 팀이다. 구멍을 막는 데 드는 시간은 구멍이 터진 후 수습하는 시간보다 항상 짧다.