AI 코딩 도구가 빠르게 확산되면서 '생성된 코드를 얼마나 믿을 수 있는가'라는 질문이 점점 날카로워지고 있다. 프로토타입을 하루 만에 뽑아내는 건 이미 일상이 됐지만, 그 코드가 실제 프로덕션 환경에서 어떤 구멍을 품고 있는지는 좀처럼 가시화되지 않는다. 세 가지 독립적인 흐름—바이브코딩 보안 감사 결과, AI 자기 검토의 구조적 한계, 그리고 에이전트 행동 제어 실험—을 나란히 놓으면, 하나의 공통된 진단이 떠오른다. AI는 작동하는 코드를 만들도록 최적화되어 있지, 안전하거나 검증된 코드를 만들도록 설계되어 있지 않다.
첫 번째 이유: AI는 보안을 기본값으로 챙기지 않는다
프로덕트 스튜디오 Inithouse가 수십 개의 AI 생성 코드베이스를 감사한 결과는 꽤 충격적이다. 바이브코딩으로 만들어진 앱의 70% 이상이 브라우저의 required 속성 외에 서버 사이드 유효성 검증을 전혀 갖추지 않았다. XSS 방어도, SQL 인젝션 차단도 없다. "연락처 폼을 만들어줘"라는 프롬프트에 AI는 '동작하는 폼'을 돌려주지만, 그게 곧 '안전한 폼'은 아니다.
인증 흐름도 마찬가지다. 토큰이 생성되고 세션이 작동하니 겉으로는 멀쩡해 보이지만, 실제로는 토큰이 localStorage에 평문으로 저장되거나 JWT 시크릿이 클라이언트에 노출된 채로 남겨진 경우가 반복적으로 발견됐다. CORS 설정도 전형적인 패턴을 따른다. 로컬에선 잘 되다가 배포하면 오류가 나고, 빠른 해결책으로 Access-Control-Allow-Origin: *를 적용하면서 보안 모델이 통째로 무너진다. 환경 변수는 더 직접적이다. AI 어시스턴트가 프로젝트 구조를 잡아주는 과정에서 API 키가 버전 관리에 커밋되는 사례가 감사 결과에서 가장 빈번한 '심각' 등급 발견으로 꼽혔다.
핵심은 단순하다. AI는 프롬프트에 명시된 것만 구현한다. 보안은 명시적으로 요구하지 않으면 생략된다. "XSS 방어와 SQL 인젝션 차단, 길이 제한을 포함한 입력 유효성 검증을 추가해줘"라고 써야 비로소 그게 나온다. '폼을 추가해줘'와의 차이는 프롬프트 한 줄이지만, 결과의 차이는 보안 감사 통과 여부다.
두 번째 이유: AI가 AI 코드를 검토하면 같은 실수를 반복한다
Cursor의 BugBot처럼 코딩 도구가 자체 코드 리뷰 기능을 내장하는 흐름이 빠르게 자리를 잡고 있다. 편리함은 분명하다. 그런데 한 가지 구조적 문제가 있다. BugBot은 코드 생성에 쓰이는 것과 동일한 모델 계열로 리뷰를 수행한다. 이게 왜 문제인지는 연구 데이터가 명확하게 보여준다.
대규모 언어 모델이 자신이 생성한 오류를 스스로 수정하도록 요청받았을 때의 실패율은 평균 64.5%에 달한다. 같은 계열 모델로 테스트된 코드는 독립적으로 테스트된 코드보다 9~17%포인트 높은 통과율을 보였다. 제대로 걸러내지 못했다는 뜻이다. 같은 학습 데이터를 공유하는 모델은 사각지대도 공유한다. 코드 작성과 리뷰에 동일한 가정이 작동하면, 오류를 잡는 게 아니라 같은 실수를 승인하는 구조가 만들어진다. 이른바 '동질화 함정'이다.
이 문제는 규모가 커질수록 심각해진다. CodeRabbit 커뮤니티가 인용한 전망에 따르면 2026년 AI 코딩으로 인한 GitHub 커밋은 14배 증가하고, PR에서 발견되는 심각한 문제는 40% 늘어날 것으로 예측된다. 코드 유출 비밀 정보는 이미 81% 증가했다. 코드 생성 속도는 검증 속도를 앞질러 가고 있고, 동일 모델이 생성과 승인을 모두 담당하는 구조에서 그 간격은 더 벌어진다. 해법은 금융 업계가 수십 년 전에 확립한 원칙과 같다. 작성자와 검토자를 분리하라. 코딩 에이전트와 리뷰 에이전트를 독립적으로 운용하고, 단일 모델이 아닌 앙상블 방식으로 검토를 구성하는 것이 현실적인 대안으로 제시되고 있다.
세 번째 이유: 지시 파일의 규칙은 '규칙'이 아니라 '희망'일 수 있다
AGENTS.md나 CLAUDE.md 같은 에이전트 지시 파일을 정교하게 작성하는 개발자들이 늘고 있다. 그런데 실제로 이 파일로 에이전트를 운용해본 경험자들이 공통적으로 발견하는 사실이 있다. 마크다운 파일에 적힌 규칙은 강한 제안이지 계약이 아니다. 모델은 드리프트한다. 충분한 횟수를 반복하면 어떤 지시도 결국 무시된다.
dev.to에서 자신의 AGENTS.md 운용 경험을 공유한 한 개발자는 이 깨달음이 파일 전체 구조를 바꿨다고 설명한다. 지시 내용을 두 계층으로 분리하는 것이다. 스타일 선호, 철학적 가이드처럼 대부분의 경우에 지켜지면 충분한 것들은 산문으로 남긴다. 반면 반드시 매번 지켜져야 하는 것들—예를 들어 '커밋 전 린트 통과', '테스트 재실행 후 확인'—은 산문으로 쓰는 게 아니라 훅, 스크립트, CI 체크로 구현한다. 지시 파일의 그 문장은 의례적 안내일 뿐이고, 진짜 보장은 위반이 머지 자체를 불가능하게 만드는 자동화 게이트다.
이 원칙의 실용적 테스트는 간단하다. 지시 파일에 'always' 또는 'never'를 쓸 때마다 그것을 강제하는 메커니즘이 있는지 확인하라. 없다면 그것은 규칙이 아니라 희망이다. 에이전트가 "테스트가 통과됐습니다"라고 말하는 것과 테스트를 실제로 재실행해서 통과를 확인하는 것은 전혀 다른 일이다. 에이전트의 확신은 검증의 증거가 아니다.
세 이유가 가리키는 하나의 실행 원칙
세 가지 흐름은 결국 같은 곳을 향한다. AI 코딩 도구는 '작동하는 것'을 만들도록 설계됐지, '안전하고 검증된 것'을 만들도록 설계되지 않았다. 보안은 프롬프트에 명시하지 않으면 생략된다. 리뷰는 독립적이지 않으면 동질화된다. 지시는 강제되지 않으면 드리프트한다.
이것은 AI 도구를 쓰지 말자는 이야기가 아니다. 오히려 반대다. 이 패턴을 알면 대응이 명확해진다. 보안 요구사항은 프롬프트에 명시적으로 포함시킨다. 코드 생성과 코드 리뷰에 동일한 모델 계열을 사용하지 않는다. '반드시 지켜야 할 것'은 산문이 아니라 자동화 게이트로 구현한다. AI의 속도를 유지하면서도 신뢰할 수 있는 코드를 만드는 것, 그 간격을 채우는 것이 지금 AI-First 개발 워크플로우에서 진짜 설계 과제다.