AI 코딩 에이전트가 5분 만에 앱을 만들어주는 시대가 됐다. Lovable, Bolt, Replit, Cursor—이 도구들은 비기술 창업자도 작동하는 프로토타입을 하루 안에 손에 쥘 수 있게 해준다. 그런데 dev.to에 올라온 한 보안 감사 리포트가 불편한 현실을 숫자로 드러냈다. 개발자 Mike I.가 AI로 생성한 태스크 매니저 앱을 스캔했더니, 자신이 코드 한 줄 건드리기 전에 치명적 취약점이 5개 나왔다. 이건 단발 사례가 아니다. Escape.tech가 실제 운영 중인 AI 생성 앱 5,600개를 스캔한 결과 1,400개에서 취약점이 발견됐고, 400개 이상의 시크릿 키가 노출돼 있었다. 200개 이상 앱을 대상으로 한 별도 감사에서는 91.5%에서 AI가 만든 보안 결함이 하나 이상 발견됐다.
가장 치명적인 패턴은 세 가지로 압축된다. 첫째, Row-Level Security(RLS) 미적용이다. Supabase는 새 테이블의 RLS를 기본으로 꺼둔다. 이 상태에서 프론트엔드 번들에 포함된 공개 키만 있으면 브라우저에서 모든 테이블의 전체 행을 읽을 수 있다. 둘째, service_role 키의 프론트엔드 노출이다. AI 도구는 권한 오류를 '빠르게 해결'하려고 모든 보안 규칙을 우회하는 관리자 키를 클라이언트 번들에 박아넣는다. 뷰 소스 한 번이면 누구나 데이터베이스 전체를 장악할 수 있다. 셋째, OpenAI·Stripe·Google API 키의 번들 포함이다. sk-, sk_live_, AIza 같은 접두사를 프론트엔드에서 검색하면 바로 드러난다. 이 키들을 탈취하면 피해자의 계정으로 수천 달러 청구가 가능하다. 그 외에도 서버 검증 없는 클라이언트 측 권한 체크, 레이트 리미팅·보안 헤더·자동화 테스트 부재가 일관되게 반복됐다.
왜 이런 일이 반복되는가. 이건 AI 도구가 나쁜 게 아니다. 이 도구들은 '데모가 작동하도록' 최적화돼 있다. 해피 패스, 즉 모든 게 정상으로 흘러가는 시나리오를 생성하도록 훈련됐다. 보안, 권한 설계, 에러 핸들링은 명시적으로 요청하지 않으면 생략되는 '보이지 않는 20%'다. 문제는 '데모가 작동한다'와 '실제 사용자 데이터를 올려도 안전하다'는 전혀 다른 기준이라는 점이다. 그 간극이 바로 데이터 유출이 살아있는 공간이다.
이 문제는 단순히 배포 전 체크리스트로 해결되지 않는다. 더 근본적으로, 개발자가 AI 워크플로우 자체에 신뢰 구조를 설계해 심어야 한다. 여기서 MCP(Model Context Protocol)가 실질적인 레버가 된다. dev.to에 소개된 MCP 크로스 플랫폼 배포 접근법은 단일 도구 정의를 Claude Code, Cursor, GitHub Copilot, Gemini CLI, Windsurf 등 모든 AI 하네스에서 동일하게 동작시킨다. 핵심은 mcp.json 하나로 보안 민감 정보(API 키, 환경 변수)를 각 하네스의 환경 주입 메커니즘에 위임하고, 도구 로직 자체는 시크릿으로부터 격리된다는 구조다. 이 아키텍처를 내부 보안 감사 도구나 RLS 검증 스크립트에 적용하면, 에이전트가 코드를 생성할 때마다 해당 도구들이 자동으로 호출되는 워크플로우를 한 번의 설계로 전 환경에 배포할 수 있다.
컨텍스트 설계도 빠질 수 없다. GeekNews가 정리한 Claude 5 컨텍스트 엔지니어링 가이드는 흥미로운 역설을 보여준다. Claude Opus 5와 Fable 5에서는 시스템 프롬프트를 80% 이상 줄여도 코딩 성능 저하가 측정되지 않았다. 오히려 과도한 제약과 반복 지침이 모델의 판단을 방해했다. 이 원칙을 보안 컨텍스트에 적용하면 구체적인 설계 방향이 나온다. CLAUDE.md에 "RLS는 반드시 활성화할 것