AI가 짠 코드, 프로덕션에서 살아남으려면

AI 코드는 데모에서 빛나고 프로덕션에서 무너진다

2025년 5월 보안 감사 결과가 꽤 충격적이다. Lovable로 만들어진 앱 1,645개 중 170개—정확히 10.3%—에서 사용자 데이터 노출 취약점이 발견됐다. 첫 고객이 가입하기도 전에 데이터가 새고 있었다는 얘기다. "AI가 짠 코드니까 검토 한 번 더 해야지"라는 막연한 감각이 있었다면, 이제는 그걸 구체적인 프로세스로 바꿔야 할 때다.

취약점은 랜덤이 아니다, 패턴이 있다

dev.to에 공개된 vibe coding 앱 12개의 프로덕션 구조조정 사례 분석에 따르면, AI 생성 코드의 보안 결함은 예측 가능한 세 가지 패턴으로 수렴한다.

첫째, API 키 노출. 감사한 앱 12개 중 4개에서 Stripe 시크릿 키, Supabase service_role 키가 클라이언트 번들에 하드코딩돼 있었다. service_role 키는 Row Level Security를 완전히 우회한다. 브라우저 DevTools만 열면 DB 전체를 읽고 쓰고 지울 수 있다.

둘째, 서버 사이드 검증 부재. AI 생성 코드는 대부분 클라이언트에서만 입력값을 검증한다. API 엔드포인트는 들어오는 값을 그대로 신뢰한다. 음수 금액, 무한대 값, 문자열이 amount 필드로 들어와도 transferFunds()가 그냥 실행된다.

셋째, 깨진 인증. 만료 시간 없는 JWT, localStorage에 저장된 리프레시 토큰(XSS 취약), 이전 토큰을 무효화하지 않는 비밀번호 재설정 플로우. 세 가지 모두 AI가 "작동하는 코드"를 생성하는 과정에서 시스템 컨텍스트 없이 일반적인 예제를 조합한 결과다.

리뷰 프로세스가 문제다, 코드가 아니라

Kodus Tech의 분석은 더 근본적인 문제를 짚는다. AI 생성 코드는 문법적으로 완벽하고, 스타일도 일관되며, 주니어 개발자 코드보다 오히려 깔끔해 보인다. 이게 함정이다.

기존 코드 리뷰는 "이 코드를 쓴 사람의 의도를 추적"하는 방식으로 설계돼 있다. 우리는 작성자에게 "왜 이렇게 짰어?"라고 물을 수 있었다. AI 생성 코드에는 추적할 의도가 없다. 출력물만 있을 뿐이다.

결과적으로 리뷰어는 친숙한 패턴을 보고 속도를 올리다가 치명적인 결함을 놓친다. 200라인짜리 REST 컨트롤러 중간 어딘가에 서비스 레이어를 우회하는 직접 DB 쿼리가 숨어있어도, 전체적인 구조가 팀 컨벤션을 따르고 있으면 눈에 잘 안 띈다. 또한 AI는 테스트 데이터 100건에서 잘 돌아가는 코드를 생성하지만, 그 코드가 프로덕션 DB의 1,000만 건을 전부 메모리에 올리도록 설계돼 있을 수 있다. 기술적으로 버그는 아니지만, 운영 관점에서는 서버를 죽이는 코드다.

리뷰 관점을 "교정"에서 "검증"으로 전환하라

그렇다면 AI 생성 코드 리뷰는 어떻게 달라져야 하나. 핵심은 "이 코드가 의도한 일을 올바른 이유로, 우리 시스템의 제약 안에서 하는가"를 확인하는 것이다. 코드를 보기 전에 먼저 두 가지를 물어야 한다. "정확히 어떤 프롬프트를 썼나?" 그리고 "원래 해결하려던 비즈니스 문제가 뭐였나?"

구체적인 체크리스트는 다음과 같다.

• 도메인 컨텍스트 확인: AI는 우리 시스템을 모른다. 우리 시스템에서 유저가 이메일을 여러 개 가질 수 있는데, AI가 하나만 있다고 가정하고 코드를 짜지는 않았나?
• 테스트 품질 재검토: AI가 생성한 테스트는 해피 패스만 커버하는 경우가 많다. AI 생성 코드의 테스트 커버리지 기준은 낮추는 게 아니라 높여야 한다.
• 보안 — 비신뢰 입력으로 취급: 새로운 의존성이 추가됐나? 사용자 입력을 안전하게 처리하나? 승인된 암호화 라이브러리를 쓰나? 2021년 스탠퍼드 연구에 따르면 AI 어시스턴트를 쓴 개발자가 안 쓴 개발자보다 불안전한 코드를 작성할 가능성이 더 높았다.
• 성능 — 알고리즘 복잡도 직접 추적: 함수의 빅-오 복잡도를 눈으로 확인하라. 루프 안에서 데이터를 조회하고 있지는 않나? 10개 아이템에서 통과한 유닛 테스트가 10,000개에서도 통과한다는 보장은 없다.

시니어 개발자의 역할이 바뀐다

3년간 생성형 AI를 집중적으로 사용한 시니어 개발자 Patricio Renner는 이것을 "spec-driven development"라고 부른다. AI에게 코드 작성을 맡기되, 방향은 개발자가 잡는 방식이다. 측정 가능한 인수 조건을 담은 기능 명세, 아키텍처 패턴, 코드 품질 기준, 테스트·보안·관찰 가능성 요구사항—이것들을 먼저 문서로 정의하고, AI는 그 범위 안에서 코드를 생성한다.

"vibe coding"이 아니라 "spec-driven development"다. 차이는 크다. AI가 채워야 할 빈칸을 사람이 미리 설계한다는 것이다. AI를 빈 캔버스 앞에 세워두면 알아서 그럴듯한 그림을 그려내지만, 그게 우리가 원하는 그림이라는 보장은 없다.

이 관점에서 보면 개발자의 역할이 사라지는 게 아니라 진화한다. 코드를 직접 쓰는 시간보다, AI가 올바른 코드를 생성할 수 있도록 컨텍스트와 제약을 설계하는 시간이 늘어난다.

프로덕션 하드닝 스프린트: 현실적인 공수

12개 앱의 프로덕션 구조조정 경험을 바탕으로 정리된 작업 공수는 현실적인 기준점을 제공한다.

합계 7~12일. 전면 재작성이 아니라 하드닝 스프린트다. 이 공수를 무시하고 프로토타입을 그대로 프로덕션에 올리는 게 10.3% 데이터 노출 통계를 만드는 경로다.

결론: AI 코드의 속도를 유지하면서 프로덕션을 지키는 구조

AI 생성 코드의 생산성 이득은 실재한다. 문제는 그 코드를 검증하는 프로세스가 여전히 AI 이전 시대의 가정 위에 서 있다는 것이다. 리뷰어가 "작성자의 의도"를 추적하는 방식, 문법과 스타일 중심의 검토 습관, 테스트가 통과하면 됐다는 암묵적 기준—이 모든 것이 AI 생성 코드 앞에서 작동하지 않는다.

당장 팀에서 시작할 수 있는 변화는 세 가지다. PR에 프롬프트를 첨부하게 한다—리뷰어가 의도를 추적할 수 있는 유일한 단서다. 보안 체크리스트를 AI 생성 PR 전용으로 분리한다—API 키 노출, 서버 사이드 검증, 의존성 추가 여부를 별도 항목으로 강제한다. 성능은 코드 리뷰가 아니라 부하 테스트로 검증한다—리뷰어의 눈으로 O(n²)를 잡는 건 점점 어려워지고 있다.

AI는 코드를 더 빠르게 만든다. 하지만 그 코드가 프로덕션에서 살아남을지는 여전히 구조를 설계하는 사람에게 달려있다.