AI가 짠 코드, '돌아간다'는 건 아무 말도 아니다
지난주에 vibe coding PR 세 개를 리뷰했는데 전부 API 키가 소스코드에 하드코딩돼 있었다. 이 문장 하나가 지금 AI-First 팀 운영의 핵심 리스크를 정확히 찌른다. dev.to에 올라온 이 사례를 처음 봤을 때, '설마 그 정도야'가 아니라 '역시나'였다. AI 코딩 에이전트는 보안 컨텍스트를 모른다. 지금 이 코드가 퍼블릭 레포에 올라갈지, 인터널 시스템에만 쓰일지, 배포 후 로그에 찍힐지—그런 판단을 프롬프트에 명시하지 않으면 AI는 그냥 동작하는 코드를 뱉는다.
그보다 더 무서운 사례가 있다. 같은 dev.to에서 공유된 크립토 봇 이야기다. AI가 짜준 가격 추적 로직이 석 달 동안 아무 에러 없이 돌았다. 문제는 if-elif 구조였다. 30분 조건이 먼저 매칭되면 1시간, 4시간 브랜치는 영원히 실행되지 않는다. 스프레드시트엔 데이터가 쌓였고, 봇은 멀쩡해 보였고, 에러 로그는 깨끗했다. 그 상태로 분석을 돌렸다면 '무조건 30분 안에 팔아라'는 전략을 도출했을 것이다. 틀린 데이터 → 틀린 결론 → 틀린 의사결정, 단 한 줄의 논리 오류가 아무 소리 없이 만들어낸 결과다.
왜 이런 일이 반복되는가
vibe coding의 기본 루프는 이렇다. 프롬프트 → 코드 생성 → 실행 → 에러 없음 → 다음 기능. 이 루프에서 '에러 없음'이 '의도대로 동작'과 동치가 되는 순간 문제가 시작된다. AI는 구문 오류나 런타임 예외는 잘 잡는다. 하지만 비즈니스 로직의 구조적 결함—조건 분기가 빠진 케이스, 상태 플래그 없이 중복 실행되는 로직, 시간 의존적 사이드이펙트—이런 건 테스트를 짜기 전엔 안 보인다. 7일 만에 SaaS를 만든 사례(FeedMission, GoCodeLab)도 솔직하게 인정한다. 52분에 MVP 10,742줄이 나왔지만, 이후 7개 보안 취약점 패치와 4개 성능 이슈 수정에 6일이 더 걸렸다고. '동작하는 코드'와 '출시 가능한 제품' 사이의 갭은 AI가 좁혀주지 않는다.
팀이 지금 당장 쓸 수 있는 검증 레이어
첫 번째 PR 사례를 계기로 만들어진 도구가 vibescore다. pip install vibescore 하나면 된다. 별도 서버 없이, 외부로 코드를 전송하지 않고, 로컬에서 네 가지 차원을 검사한다.
- Security: 하드코딩 시크릿, SQL 인젝션,
eval()/exec(), 인시큐어 디폴트 - Code Quality: 함수 길이, 복잡도, 중첩 깊이, 타입 힌트 커버리지
- Dependencies: 버전 고정, 락파일, 지원 종료 패키지, CVE
- Testing: 테스트 대비 코드 라인 비율, 커버리지 설정, CI 구성
결과는 A+부터 F까지 단일 등급으로 나온다. SonarQube처럼 Java 서버를 띄울 필요 없고, Codacy처럼 코드를 외부로 보내지 않아도 된다. --init-ci 플래그로 GitHub Actions 워크플로우까지 자동 생성된다. PR 머지 전 게이트로 붙이기에 딱 맞는 구조다.
도구보다 먼저 바꿔야 할 질문
vibescore 같은 정적 분석 도구는 필요조건이지 충분조건이 아니다. 크립토 봇 버그는 정적 분석으로 잡기 어렵다. 문법적으로 완벽하고, 런타임 에러도 없고, 단지 조건 분기 설계가 잘못됐을 뿐이다. 이걸 잡으려면 코드 리뷰의 질문 자체가 바뀌어야 한다.
"이 코드가 돌아가나?" → "이 코드가 틀릴 수 있는 경우가 뭔가?"
AI 생성 코드를 리뷰할 때 내가 팀에 요구하는 체크포인트는 세 가지다. ① 조건 분기 완전성: 모든 케이스가 커버되는가, elif 뒤에 있어야 할 독립 if가 누락되진 않았는가. ② 상태 사이드이펙트: 함수 실행 순서가 바뀌면 결과가 달라지는가, 상태가 외부에 암묵적으로 의존하진 않는가. ③ 침묵 실패 가능성: 에러를 던지지 않고 조용히 잘못된 값을 기록하거나 건너뛰는 경로가 있는가. AI는 이 세 가지를 프롬프트에 명시하지 않으면 고려하지 않는다.
AI-First 팀의 검증 파이프라인 설계
세 사례를 합쳐보면 검증 레이어가 최소 세 단계여야 한다는 그림이 나온다.
1단계 — 자동화 게이트 (PR 전): vibescore 또는 유사 정적 분석을 CI에 붙인다. 보안 등급 B 미만이면 머지 블록. 이건 선택이 아니라 기본값이어야 한다.
2단계 — 로직 리뷰 (사람이 개입): AI 생성 코드일수록 리뷰어는 '실행 경로'보다 '누락된 경로'를 먼저 찾아야 한다. 조건 분기마다 "이 조건이 아닐 때 뭐가 일어나나"를 명시적으로 묻는 리뷰 템플릿을 팀 PR 가이드에 박아두는 게 실용적이다.
3단계 — 데이터 무결성 검증 (배포 후): FeedMission 사례처럼 AI 생성 코드는 '동작'은 하지만 '기대한 데이터를 만드는지'는 별개다. 핵심 데이터 파이프라인엔 주기적 샘플링 검증 또는 이상 탐지 알림을 붙여야 한다. 크립토 봇 버그가 석 달간 발각되지 않은 이유는 데이터를 실제로 들여다볼 루틴이 없었기 때문이다.
전망: 검증 역량이 곧 AI 활용 역량이다
vibe coding 속도는 실제다. 52분에 MVP, 72.5% 커밋을 AI가 공동 작성—이 숫자는 과장이 아니다. 문제는 그 속도가 검증 비용을 없애주지 않는다는 것이다. 오히려 코드 생성이 빨라질수록 검증 부채가 더 빠르게 쌓인다. AI-First 팀에서 시니어 개발자의 가치는 더 빠르게 코드를 짜는 게 아니라 AI가 놓친 것을 체계적으로 찾아내는 프레임을 팀에 심는 것으로 이동하고 있다. vibescore 같은 도구는 그 프레임의 일부일 뿐이다. 나머지는 여전히 사람의 질문 방식에 달려 있다.