AI 코드는 컴파일된다. 그렇다고 안전한 건 아니다
100개 AI 생성 앱을 직접 보안 스캔한 결과가 공개됐다. 숫자가 꽤 불편하다. 67개 앱에서 치명적 취약점이 발견됐고, 45%는 소스코드에 API 키와 JWT 시크릿이 그대로 박혀 있었다. 38%는 민감한 API 라우트에 인증이 없었고, Lovable로 만든 앱의 89%는 Supabase Row Level Security 정책이 통째로 빠져 있었다. 이미 실사용자가 있는 프로덕션 앱 이야기다.
이 숫자를 보고 "AI 도구가 나쁘다"는 결론을 내리면 틀린 해석이다. 문제는 도구가 아니라 구조다. AI는 기능 요구사항은 충실히 구현하지만, 위협 모델을 갖고 있지 않다. "투두 앱을 만들어줘"에는 답하지만, "누군가 다른 사용자의 ID를 추측하면 어떻게 되지?"는 스스로 묻지 않는다. 스탠퍼드·UIUC 연구진이 확인한 것처럼, AI 어시스턴트를 쓴 개발자가 더 취약한 코드를 짜면서도 자신의 코드가 안전하다는 확신은 더 강했다. 이 자신감 갭이 진짜 위험이다.
AI가 놓치는 것, 사람이 채워야 하는 것
Claude Code를 실전 워크플로우에 깊게 통합해 쓰는 엔지니어들의 증언은 일관된다. AI는 파일을 보지만, 아키텍처를 보지 못한다. AI는 현재 프롬프트에 답하지만, 팀이 지난 분기에 그 서비스를 왜 deprecated 시켰는지 모른다. AI는 해피 패스를 먼저 구현하지만, 결제 도중 세션이 만료되면 어떻게 되는지는 엔지니어가 시나리오를 정의해줘야 한다.
핵심은 이것이다. AI는 멀티플라이어다. 엔지니어링 기초가 탄탄하면 그걸 증폭시키고, 기초가 약하면 그것도 함께 증폭된다. PR에는 당신 이름이 올라가고, 머지 결정은 당신이 했으며, 프로덕션이 터지면 누가 AI에게 물어보지 않는다.
품질을 지키는 세 겹의 구조
그러면 실제로 어떻게 막는가. 단계별로 정리하면 세 층이다.
첫째, 테스트로 AI를 가이드한다. TDD는 AI 시대에 오히려 더 강력해진다. 엔지니어가 WHAT을 정의하면—어떤 엣지 케이스를 커버할지, 어떤 플로우가 비즈니스 크리티컬인지—AI가 HOW를 구현한다. 테스트 없이 AI에게 맡기면 "겉으로는 맞아 보이는" 코드가 나온다. 실패 테스트를 먼저 작성하면 AI는 그 경계 안에서 작동한다. E2E 테스트도 마찬가지다. 결제 플로우, 인증 시퀀스—어떤 흐름을 검증할지는 비즈니스를 이해하는 사람이 결정해야 한다.
둘째, 배포 전 강제 실행 레이어를 깔아둔다. 린팅 룰, Git pre-push 훅, CI 파이프라인—이 세 가지가 없으면 표준은 그냥 문서 속 텍스트다. Claude Code 같은 도구는 훅을 지원해서 커밋 전 린트, 푸시 전 테스트를 AI 세션 안에서도 자동 실행할 수 있다. AI 생성 코드도 예외 없이 같은 게이트를 통과해야 한다.
셋째, 보안은 별도로 리뷰한다. 소스 스캐닝 도구로 하드코딩된 시크릿을 잡고(grep -rn "api_key\|secret" 한 줄이면 시작된다), 인증·인가 로직은 반드시 사람이 직접 읽는다. Supabase를 쓴다면 RLS 정책은 테이블 생성 시점에 활성화를 기본값으로 잡아두는 것이 팀 컨벤션이 돼야 한다. 뮤테이션 엔드포인트(POST/PUT/DELETE)에 인증 미들웨어가 없는 패턴은 AI 생성 코드에서 반복적으로 나타나는 블라인드 스팟이다.
AI Native Engineer가 갖춰야 할 것
DORA 2025 데이터는 냉정한 사실 하나를 들이민다. AI 도입 후 PR 생성량은 98% 늘었지만 소프트웨어 딜리버리 성과는 flat이었다. 코딩은 원래 병목이 아니었다는 얘기다. "딸깍"으로 만드는 속도는 모두에게 공평하게 생겼다. 차별점은 그 결과물을 판단하는 눈에서 갈린다.
'AI Native Engineer — 원리 위의 감각'이라는 글에서 나온 표현이 정확하다. Anthropic이 "taste"라고 부르는 것—AI를 가장 잘 쓰는 사람들이 AI에게 가장 마지막까지 맡기지 않는 것. Linear CTO가 말한 것처럼 taste는 신비로운 감각이 아니라 근육이다. "AI의 All Pass가 나에게도 All Pass인가?" 이 질문을 매 PR마다 던질 수 있는 사람이 AI 시대의 엔지니어다. 네트워크, OS, 자료구조 같은 원리 지식이 빛나는 이유도 여기 있다. AI가 Swift 문법이나 React 패턴 같은 도구 지식을 대체하면, 그 위에 남는 건 원리 위에서 판단하는 능력이다.
테크 리드가 지금 당장 할 일
이론은 충분하다. 팀 단위로 내일 적용할 수 있는 체크리스트다.
- 보안 스캔을 CI에 넣는다. 시크릿 탐지, 인증 누락 체크는 사람 리뷰 전에 자동화로 걸러야 한다.
- AI 생성 코드 리뷰 기준을 주니어 PR 기준으로 맞춘다. 컴파일되고 테스트 통과한다고 끝이 아니다. 불필요한 추상화, 누락된 null 체크, 팀 컨벤션 이탈, 보안 홀을 라인 단위로 읽는다.
- 인증·인가 코드는 AI에게 단독으로 맡기지 않는다. 이 영역은 리뷰 시간을 두 배로 잡아야 한다.
- 테스트 작성 책임을 명확히 한다. AI가 테스트를 생성해도, 어떤 시나리오를 커버할지 결정하는 건 팀원이다.
AI는 가속기다. 방향을 바꾸지 않는다. 속도가 빨라진 만큼 잘못된 방향으로도 더 빨리 달린다. 품질 구조를 먼저 세우지 않으면, AI는 버그를 더 빠르게 프로덕션에 올리는 도구가 된다. PR에 올라간 코드의 책임은 그걸 머지한 사람에게 있다. AI가 짰어도, 당신 이름이 거기 있다.