처음 90일은 기적처럼 느껴진다. 기능이 시간 단위로 나가고, 백로그가 줄고, 이해관계자들은 열광한다. 그런데 4개월쯤 지나면 조용히 뭔가 달라지기 시작한다. PR 리뷰가 무거워지고, 아무도 건드리지 않은 곳에서 버그가 터지고, 온보딩이 길어진다. 팀은 왜 그런지 설명하지 못한다. AI 코딩이 팀에 가져온 가장 위험한 선물은 실패가 아니라, 성공이 너무 오래 지속된다는 착각이다.
속도 지표가 숨기는 것들
Dev.to에 올라온 'Vibe-Coding Works. That's Exactly Why It Will Destroy Your Codebase at Scale.' 포스트는 이 패턴을 정면으로 짚는다. 팀이 AI 코딩을 평가할 때 주로 보는 지표는 배포 빈도, 완료 티켓 수, 코드 줄 수다. 이것들은 선행 지표(leading indicator)다. 진짜 문제는 후행 지표(lagging indicator)에 있다. 새 엔지니어가 기존 모듈을 이해하는 데 걸리는 시간, AI 생성 코드가 포함된 프로덕션 인시던트의 평균 디버깅 시간, 모듈 간 커플링 밀도. 이것들은 Jira 대시보드에 나오지 않는다. 그래서 측정하지 않는다. 그래서 모른다.
글이 정리한 숨은 비용 네 가지는 이론이 아니라 실제 패턴이다. 첫째, 일관성 갭(coherence gap): AI는 프롬프트에 맞는 코드를 생성하지, 시스템에 맞는 코드를 생성하지 않는다. 수백 개의 PR이 쌓이면 각 모듈은 서로 미묘하게 충돌하는 가정 위에 서게 된다. 각 PR은 혼자 보면 문제없다. 그래서 통과된다. 둘째, 오너십 공백(ownership void): 엔지니어가 AI가 쓴 코드의 정신 모델을 갖지 못하면, 버그가 터졌을 때 고고학 발굴을 시작해야 한다. 셋째, 테스트 신뢰 함정(test confidence trap): AI는 코드가 무엇을 하는지를 테스트하지, 무엇을 해야 하는지를 테스트하지 않는다. CI가 초록불이어도 프로덕션이 터지는 이유다. 넷째, 컨텍스트 윈도우 부채(context window debt): AI로 새 변경을 만들수록 더 많은 맥락을 먹여야 한다. 이전 AI 생성 코드의 비일관성을 보상하기 위해. 부채가 부채를 낳는다.
50개 앱 감사가 실제로 발견한 것
이게 추상적 경고로 느껴진다면, 숫자를 보자. Dev.to의 또 다른 포스트 'I Audited 50 Vibe-Coded Apps. Here's What Broke.'는 Lovable, v0, Bolt, Cursor, Claude Code로 만들어진 앱 50개를 직접 감사한 결과를 공개한다. 친구 사이드 프로젝트부터 YC 투자를 받은 스타트업, 24시간 해커톤 결과물이 그대로 프로덕션에 올라간 케이스까지. 그리고 거의 모든 앱에서 동일한 다섯 가지 버그가 반복됐다.
1. Supabase RLS 비활성화 (50개 중 44개): CVE-2025-48757, CVSS 9.3. Lovable 기반 에드테크 앱 하나에서 학생 기록 18,697건이 노출됐다. 그중 UC Berkeley, UC Davis 재학생 4,538명 포함. 인증 로직이 반전되어 익명 사용자는 전체 읽기 권한을 갖고, 로그인한 사용자는 차단됐다. pg_tables에서 rowsecurity = FALSE인 테이블을 조회하는 데 1분도 안 걸린다. 하지만 아무도 확인하지 않았다.
2. NEXT_PUBLIC_*에 시크릿 키 노출 (50개 중 39개): Moltbook 사건(2026년 2월). API 토큰 150만 건, 이메일 3.5만 건, 에이전트 대화 이력 47GB가 노출됐다. 원인은 단순하다. NEXT_PUBLIC_은 네이밍 컨벤션이 아니라 빌드 인스트럭션이다. 이 접두사가 붙은 모든 변수는 브라우저로 배포되는 JavaScript에 그대로 구워진다. 시크릿이 더 이상 시크릿이 아닌 순간이다.
3. 인증 로직 반전 (50개 중 12개): 발생 빈도는 낮지만 터지면 치명적이다. if (session) 분기에서 보호된 데이터를 반환하고, 비세션 상태에서 로그인 요청을 띄워야 할 곳에 역이 실행되는 패턴. AI가 생성한 코드에서 의미론적 검증 없이 통과된 결과다.
4. AI 에이전트의 무제한 파괴적 작업 (50개 중 8개, 전부 심각): PocketOS 사건(2026년 4월). Cursor + Claude 에이전트가 스코프가 없는 Railway API 토큰으로 실행됐다. 에이전트는 9초 만에 프로덕션 데이터베이스와 전체 백업을 삭제했다. 30시간 서비스 중단. 감사된 8개 앱 모두에서 공통 패턴이 있었다. 환경 스코프 없는 프로젝트 전체 쓰기 권한 토큰, 파괴적 작업에 대한 휴먼 인더루프 없음, 툴 호출 레이트 리밋 없음.
5. 프롬프트 인젝션 (LLM을 호출하는 거의 모든 앱): 사용자 입력이 시스템 프롬프트나 툴 디스크립션에 직접 삽입되는 패턴. 감사된 모든 LLM 호출 앱에서 발견됐다. 모델이 항상 지시를 따르는 건 아니지만, 따를 때와 따르지 않을 때의 차이는 정도의 문제이지 종류의 문제가 아니다.
도구 문제가 아니라 프로세스 문제다
여기서 짚고 싶은 것은 하나다. AI가 나쁜 코드를 쓰는 게 실패 모드가 아니다. 팀이 AI의 생성 속도에 맞게 품질 인프라를 확장하지 않는 것이 실패 모드다. Vibe-coding 아티클의 표현을 빌리면: "AI는 당신의 코드베이스를 망가뜨리지 않았다. 당신의 나쁜 습관을 빛의 속도로 움직이게 했을 뿐이다."
주니어 엔지니어도, 외주도, Stack Overflow 복붙도 '로컬은 맞지만 글로벌로는 위험한' 코드를 낸다. 우리는 항상 코드 리뷰, 아키텍처 문서, 팀 컨벤션, 온보딩으로 그 리스크를 관리해왔다. AI 코딩이 달라진 점은 생성 속도가 너무 빨라서 통합 단계가 '관료적 오버헤드'처럼 느껴지기 시작했다는 것이다.
Claude + MCP는 이 문제를 어떻게 접근하나
'From Coder to Architect: How I Rebuilt My Workflow Using Claude and MCP'는 이 긴장을 다른 각도에서 다룬다. 저자는 Claude를 검색 대체제로 쓰다가, MCP(Model Context Protocol)를 통해 파일 시스템, GitHub 레포, Slack을 AI가 직접 볼 수 있는 환경으로 전환했다. 핵심 개념은 '세컨더리 브레인': AI가 실행과 정보 검색을 담당하고, 인간의 프라이머리 브레인은 전략과 엣지 케이스 비판에 집중한다.
실용적인 부분은 Git 워크플로우 자동화(브랜치명 생성, 커밋 메시지 작성, Jira 링크, 푸시)와 TDD 스캐폴딩(요구사항을 넣으면 실패 테스트 케이스 먼저 생성)이다. 팀 단위로는 표준화된 프롬프트와 JSON 스키마를 'Claude Skills'로 공유하는 방식으로 확장했다. 여기서 중요한 건 MCP가 '더 빠른 생성'을 위한 도구가 아니라, 시스템 컨텍스트를 AI에게 공급하는 통로로 기능한다는 점이다. 앞서 말한 '코히어런스 갭'을 줄이는 방향으로 설계된 셈이다.
팀에 내일 당장 적용할 것 세 가지
이 세 기사를 엮어보면 실용적인 처방이 나온다.
첫째, 프롬프트 전에 아키텍처 결정 기록(ADR)을 쓴다. 길 필요 없다. 단락 하나면 된다. 이 모듈이 무엇을 하는지, 무엇을 하지 않는지, 어떤 글로벌 가정을 할 수 있는지. AI가 이것을 기반으로 생성하면 코히어런스 갭이 줄어든다.
둘째, 보안 체크리스트를 배포 전 의무 단계로 넣는다. 50개 앱 감사가 보여준 다섯 가지 버그는 각각 10~30분이면 점검할 수 있다. Supabase RLS 쿼리, NEXT_PUBLIC_* grep, 인증 분기 리뷰, 에이전트 토큰 스코프 확인, 프롬프트 인젝션 경로 점검. 합쳐서 3시간이다. Snyk과 Semgrep은 코드 레벨 CVE는 잡아주지만 RLS 설정 오류나 에이전트 권한 에스컬레이션은 잡지 못한다. 설정 레벨 감사는 눈으로 해야 한다.
셋째, 후행 지표를 하나라도 측정하기 시작한다. 새 엔지니어가 AI 생성 모듈을 이해하는 데 걸린 시간, AI 생성 코드를 포함한 인시던트의 디버깅 시간. 이것만 추적해도 인플렉션 포인트를 사후가 아니라 사전에 볼 수 있다.
결론: 속도의 부채는 복리로 쌓인다
AI 코딩의 생산성 향상은 실제다. 문제는 그 복리 부채도 실제라는 것이다. 그리고 거의 모든 팀이 잘못된 지표를 측정하고 있다. 빠르게 만드는 것과 안전하게 운영하는 것 사이의 긴장은 AI 도구가 만들어낸 게 아니다. AI가 그 긴장을 훨씬 빠르게 당신 앞에 가져다 놓은 것이다. 이 긴장을 설계하지 않으면, 시스템이 알아서 그 답을 내놓는다. 보통 가장 나쁜 타이밍에.