AI는 '작동하는 코드'를 쓰지, '안전한 코드'를 쓰지 않는다
2026년 초, 한 보안 연구자가 Lovable로 만들어진 앱 62개를 스캔했다. 결과는 충격적이었다. 63%에서 심각하거나 높은 수준의 취약점이 발견됐고, 앱 하나당 평균 10개의 보안 결함이 있었다. 더 불편한 사실은 따로 있다. 발견된 취약점들이 '희귀한 엣지 케이스'가 아니었다는 것이다. API 키 노출, Row-Level Security(RLS) 비활성화, 인증 없는 라우트, 로그인 엔드포인트의 Rate Limiting 부재—같은 실수가 반복해서 등장했다.
이 패턴에는 구조적 이유가 있다. AI 코딩 에이전트는 '행복한 경로(happy path)'에 최적화되어 있다. 정상적인 사용자가 로그인하는 흐름은 완벽하게 작동하지만, 공격자가 어떻게 우회할지는 고려하지 않는다. 학습 데이터의 대부분이 튜토리얼과 데모 코드—단순하고 읽기 쉽게 쓰인, 프로덕션 보안과는 거리가 먼 코드다. 무엇보다, 에이전트는 당신의 /api/admin 라우트가 공개되어서는 안 된다는 사실을 모른다. Supabase 테이블에 결제 데이터가 있다는 것도 모른다. 요청한 것을 만들 뿐, 진짜 필요한 것을 만들지 않는다.
에이전트의 또 다른 문제: 실패를 기억하지 못한다
보안 취약점과는 별개로, AI 코딩 에이전트에는 또 하나의 구조적 약점이 있다. Claude Code로 개발하다 보면 누구나 한 번쯤 목격하는 장면이 있다. 에이전트가 어떤 수정을 시도한다. 테스트가 실패한다. 다른 것을 시도한다. 또 실패한다. 그리고 몇 프롬프트 뒤, 혹은 컨텍스트 윈도우가 압축된 뒤—에이전트는 이미 실패한 그 첫 번째 수정을 새로운 아이디어인 양 자신 있게 다시 적용한다. 실패는 기억에서 지워졌지만, 자신감은 그대로 남았다.
이 문제를 해결하기 위해 만들어진 오픈소스 도구가 RegressionLedger다. 핵심 아이디어는 단순하다. '어떤 수정을 시도했고 결과가 어땠는지'는 컨텍스트 윈도우 수명보다 오래 살아남아야 한다는 것. 이 도구는 에이전트가 만드는 모든 수정을 핑거프린팅하고, 각 수정을 다음 테스트/빌드 결과와 연결하며, 이를 로컬 JSON 원장에 영속적으로 저장한다. 그리고 이미 실패한 수정을 다시 적용하려 하면 하드 블록을 건다. '단순한 제안'이 아니라 강제다. 에이전트가 가장 자신감 넘칠 때가 정확히 실수를 반복하려는 순간이기 때문이다.
두 문제가 가리키는 하나의 질문
보안 취약점 문제와 반복 실패 문제는 표면적으로 다르지만, 같은 근본 질문을 가리킨다. 에이전트가 만든 코드를 어떻게 신뢰 가능하게 만드는가. 빠른 프로토타이핑→검증→고도화 흐름을 중시하는 관점에서, 이 질문은 특히 핵심 사각지대다. Cursor나 Lovable, Bolt로 하루 만에 프로토타입을 완성하는 속도감은 실제로 경이롭다. 문제는 그 속도감이 '안전하다'는 착각을 함께 생성한다는 데 있다. 앱은 멀쩡하게 작동하고, UI는 아름다우며, 링크를 공유하고 싶어진다. 하지만 그 순간, 이미 문이 열려 있을 수 있다.
배포 전 점검이 필요한 세 가지 사각지대
소스 기사에서 반복적으로 등장하는 취약점 패턴을 실천 가능한 관점으로 정리하면 다음 세 가지로 수렴된다.
첫째, 시크릿 관리. 클라이언트 사이드 코드에 API 키가 노출되는 건 가장 흔하면서도 치명적인 실수다. Next.js에서 NEXT_PUBLIC_ 접두사는 해당 키를 모든 사용자의 브라우저에 번들로 내려보낸다는 의미다. .env 파일이 지금은 gitignore 처리되어 있어도, git log --all --full-history -- .env로 과거 커밋 이력을 반드시 확인해야 한다. 한 번이라도 커밋된 시크릿은 이미 노출된 것이다.
둘째, 인증과 데이터 접근 제어. Supabase를 쓰고 있다면 RLS(Row-Level Security)는 기본값이 OFF다. 이는 2025년 CVE-2025-48757로 공식 등재된 Lovable 보안 사고의 직접적 원인이었다—170개 프로덕션 앱, 수만 건의 사용자 레코드가 노출됐다. 모든 테이블에 RLS를 활성화하고, 사용자가 자신의 데이터만 읽을 수 있도록 정책을 명시적으로 설정해야 한다. 관리자 라우트 보호는 UI 레이어가 아니라 반드시 서버 사이드에서 이루어져야 한다.
셋째, IDOR(Insecure Direct Object Reference). AI 생성 코드에서 가장 많이 발견되는 취약점이다. 문서 ID나 리소스 ID로 데이터를 조회할 때, 현재 사용자의 소유 여부를 함께 필터링하지 않으면 다른 사용자의 데이터에 접근할 수 있다. 직접 테스트해볼 수 있다. 계정 A로 리소스 ID를 확보하고, 계정 B로 그 ID에 접근해보라. 데이터가 보인다면 취약점이다.
에이전트 신뢰 구조를 설계한다는 것
프로덕션에 배포하기 전 이 모든 항목을 직접 점검하는 것이 이상적이지만, 더 근본적인 접근은 에이전트 워크플로우 자체에 신뢰 구조를 설계하는 것이다. Cursor나 Claude Code에 직접 감사 프롬프트를 붙이는 방식—체크리스트를 AI에게 주고 코드를 검토하게 하는 것—은 즉각 실천 가능한 첫 단계다. RegressionLedger처럼 에이전트의 실패 이력을 컨텍스트 바깥에서 관리하는 도구는 '에이전트가 어제 무엇을 시도했는가'를 새 세션에서도 알 수 있게 만든다.
결국 이 두 가지 문제—보안 사각지대와 반복 실패—는 AI 에이전트가 생성한 코드를 인간이 맹목적으로 신뢰할 수 없다는 사실을 다른 각도에서 확인시켜준다. 에이전트는 빠르고 유능하지만, '무엇을 놓쳤는가'를 스스로 알지 못한다. 그 간극을 채우는 것—구조화된 검증, 지속적인 실패 추적, 명시적 보안 체크포인트—이 이제 프론트엔드 개발자의 핵심 역량 중 하나가 되고 있다.
전망: '빠르게 만들기'와 '안전하게 만들기'는 다른 문제다
AI 코딩 도구는 앞으로도 계속 빨라질 것이다. Cursor, Lovable, Bolt의 다음 버전은 지금보다 더 적은 프롬프트로 더 완성도 높은 앱을 만들어낼 것이다. 그러나 이 속도가 보안 판단력을 대체하지는 않는다. 오히려 생성 속도가 빠를수록, 검증 루프의 밀도를 높여야 한다. '프로토타입을 하루 만에 만들었다'는 것과 '배포해도 된다'는 것은 여전히 전혀 다른 명제다. 에이전트가 짠 코드를 신뢰하는 기준을 설계하는 것—그것이 지금 AI-First 개발자에게 요구되는 다음 역량이다.