AI 코딩 도구를 도입한 팀이 가장 먼저 느끼는 건 속도다. 그리고 6개월 후 가장 먼저 느끼는 것도 속도다—다만 이번엔 뭔가 무너지는 속도다. 문제는 AI가 나쁜 코드를 만들어서가 아니다. AI가 만드는 결과물의 범위가 코드를 훨씬 넘어섰는데, 검증 체계는 아직 코드 리뷰 수준에 머물러 있다는 것이다. 최근 세 가지 사례를 놓고 보면, AI 가속이 만들어내는 검증 공백은 코드 품질, 배포 파이프라인, 에이전트 감사라는 세 개의 레이어에서 각각 다른 방식으로 터진다.
첫 번째 균열: 코드베이스가 팀의 이해를 벗어난다
Dev.to에 올라온 'Your AI Coding Workflow Is Broken'은 이 상황을 정확하게 짚는다. AI 에이전트가 기능을 하나씩 만들어낼 때 개별 기능은 동작한다. 문제는 그 사이 공간이다. 저자가 명명한 세 가지 부채—인지 부채(cognitive debt), 검증 부채(verification debt), 아키텍처 드리프트(architectural drift)—는 독립적으로 발생하지 않는다. 세 개가 쌓이면 '컨트롤 부채'가 된다. 리포지터리는 내가 소유하지만, 운영 관점에서는 그렇지 않은 상태.
CI가 통과한다고 안전한 게 아니다. 진짜 테스트는 새벽 2시에 장애가 났을 때 팀원 중 누군가가 그 코드를 디버깅할 수 있느냐다. AI가 생성 속도를 인간의 리뷰 속도보다 빠르게 만든 순간, 팀은 자신도 모르게 이 테스트를 포기하기 시작한다. 해법은 단순하다: 한 세션에 하나의 태스크, 하나의 diff, 하나의 리뷰. 지루하지만 작동한다. 그리고 검증을 '이후에 하는 것'이 아니라 독립된 단계로 설계해야 한다.
두 번째 균열: PR 프리뷰가 프로덕션 DB에 연결된다
배포 파이프라인 레이어의 문제는 더 즉각적이다. Dev.to의 'Your PR Preview Is Talking to Your Production Database'가 고발하는 상황은 가설이 아니라 Cloudflare Workers의 기본 동작이다. wrangler.jsonc의 최상위 바인딩이 프로덕션 D1을 가리키고 있으면, 피처 브랜치에서 트리거된 PR 프리뷰도 프로덕션 데이터를 읽고 쓴다. 마이그레이션 명령을 배포 커맨드에 추가하는 순간, 그 마이그레이션도 프로덕션에 적용된다.
AI 코딩 에이전트가 자율적으로 PR을 여는 워크플로우를 운영하고 있다면 이 문제는 단순한 설정 실수를 넘어선다. 에이전트가 만든 코드가 격리된 스테이징 DB 없이 프리뷰 배포되면, 에이전트가 실제로 무엇을 만들었는지 안전하게 검증할 방법 자체가 사라진다. 스테이징 환경 분리는 '안전 장치'가 아니라 AI 자동화 PR 워크플로우의 전제 조건이다. Wrangler의 env.staging 구성을 통한 환경 분리—별도 D1 인스턴스, 별도 KV 네임스페이스, 그리고 바인딩의 비상속성에 주의한 명시적 선언—는 다섯 단계로 해결된다. 해결책은 복잡하지 않다. 문제는 기본값을 신뢰한 것이다.
세 번째 균열: 에이전트가 돈을 움직이는데 영수증이 없다
가장 심각한 레이어는 에이전트 감사다. 2026년 3월 공개된 ZombieClaw 보안 사고는 3만 개 이상의 AI 에이전트 인스턴스가 침해됐고, 피해액은 약 1,600만 달러에 달했다. Kaspersky, Bitdefender, Sophos가 각각 분석을 발표했지만, Dev.to의 'AI Agents Can Move Money But Can't Produce Receipts'가 핵심을 짚는다: 사고 이후에 어떤 에이전트가 실제로 무슨 명령을 실행했는지 암호학적으로 증명할 방법이 없었다.
텍스트 로그는 존재한다. 하지만 텍스트 로그는 편집, 삭제, 조작이 가능하다. 침해된 에이전트는 자신의 대화 히스토리를 수정할 수 있고, 툴 콜 로그가 존재하더라도 서명되지 않은 텍스트 파일이라면 공격자가 에이전트를 통제하는 순간 로그도 통제된다. SOC 2, HIPAA, GDPR은 민감 데이터에 대한 감사 추적을 요구한다. 에이전트가 1,600만 달러를 움직인 뒤 남은 증거가 신뢰할 수 없는 텍스트 파일뿐이라면, 이건 컴플라이언스 공백이다.
해법의 방향은 명확하다. 각 에이전트에 Ed25519 아이덴티티를 부여하고, 모든 툴 콜을 실행 시점에 서명하고, 해시 체인으로 엮으면 삭제와 순서 변경이 탐지 가능해진다. 서버가 독립적으로 응답에 서명하는 양방향 서명(bilateral co-signing)은 단일 키 탈취 시나리오를 완화한다. 오프-호스트 앵커링—체인 해시를 외부 시스템에 주기적으로 발행—은 전체 호스트 침해 시나리오에 대한 마지막 방어선이다. 서명은 방어가 아니라 포렌식 레이어다. 방어는 여전히 샌드박싱과 권한 시스템이 담당한다. 하지만 방어는 결국 실패한다. 실패했을 때 증거가 있어야 한다.
세 균열이 하나의 패턴을 만든다
세 가지 사례가 가리키는 패턴은 동일하다: AI가 생성하는 속도와 팀이 검증하는 속도 사이의 간격이 부채를 만든다. 코드 레이어에서는 인지·검증·아키텍처 부채로 나타나고, 배포 레이어에서는 격리되지 않은 환경이 프로덕션 데이터를 오염시키며, 에이전트 레이어에서는 행위의 암호학적 증적이 없는 채로 돈이 움직인다.
테크 리드로서 내가 내리는 결론은 이렇다. AI-First 워크플로우에서 '속도'는 도입 성과 지표가 될 수 없다. 팀이 관리할 수 있는 속도—코드를 이해하고, 배포 환경을 통제하고, 에이전트 행위를 검증할 수 있는 속도—가 지속 가능한 상한선이다. 5분짜리 데모는 항상 인상적이다. 데모는 일이 아니다. 진짜 일은 생성 이후에 시작된다.
당장 내일 팀에 적용할 수 있는 것부터 시작하자. AGENTS.md에 컨벤션을 명문화하고, Wrangler 환경 분리를 설정하고, 에이전트가 금전·데이터에 접근한다면 툴 콜 서명 인프라를 스프린트에 넣어라. 이 세 가지는 모두 하루 안에 시작할 수 있고, 6개월 후의 팀이 당신에게 감사할 것이다.