AI는 새벽 2시에도 코드를 짜준다. 문제는 그 다음이다
새벽 2시, 한 개발자가 배포 버튼을 눌렀습니다. Copilot이 함수를 짰고, ChatGPT가 버그를 잡았고, Claude가 문서까지 써줬습니다. 코드는 깔끔했고, AI의 설명은 자신감 넘쳤습니다. 2주 뒤, 프로덕션 서버가 털렸습니다.
공격자는 제로데이 익스플로잇 같은 정교한 기술을 쓰지 않았습니다. AI가 만들어 놓은 문을 그냥 열고 들어왔을 뿐입니다. dev.to에 공유된 이 실제 사고 사례는 AI-First 워크플로우가 빠르게 확산되는 지금, 우리 모두가 직면한 불편한 진실을 정면으로 건드립니다.
"완벽해 보이는 코드"의 함정: AI의 구조적 맹점
해당 개발자가 자신의 최근 프로젝트에서 생성된 AI 코드 100개 함수를 직접 감사했을 때, 결과는 충격적이었습니다. 45%에서 실제 보안 취약점이 발견됐습니다. 스타일 문제나 최적화 이슈가 아니라, 실제로 시스템을 뚫을 수 있는 결함들이었습니다.
패턴은 반복됩니다. Claude에게 "PostgreSQL에서 이메일로 유저를 조회하는 함수를 써줘"라고 요청하면, f-string으로 쿼리를 직접 조립하는 SQL 인젝션 취약 코드가 나옵니다. 튜토리얼에서 수백 번 본 패턴 그대로입니다. AI는 그 코드가 인터넷에 노출된 엔드포인트에 붙을지, 내부 스크립트에만 쓰일지 알지 못합니다. 묻지도 않습니다.
Copilot이 제안한 코드 안에는 # TODO: 배포 전에 환경 변수로 이동할 것이라는 주석과 함께 하드코딩된 Stripe 라이브 API 키가 들어있었습니다. 개발자는 잊었고, 그 키는 3주간 레포지토리에 남아있었습니다. AI는 "테스트 코드"와 "프로덕션 코드"를 구분하지 않습니다. 그냥 학습 데이터에서 본 패턴을 완성할 뿐입니다.
AI는 스택 오버플로우 답변처럼 생각합니다. 보안 엔지니어처럼 생각하지 않습니다.
178만 달러짜리 수학 실수: Moonwell 사건이 주는 경고
이 문제는 개인 개발자의 실수로 끝나지 않습니다. 2026년 2월, 탈중앙화 대출 프로토콜 Moonwell에서는 AI가 공동 작성한 코드 한 줄이 178만 달러 손실로 이어진 사건(dev.to, Alessandro Pignati)이 발생했습니다.
Governance 제안 MIP-X43은 Chainlink의 Oracle 래퍼 컨트랙트를 통해 cbETH 가격을 처리하는 코드를 포함했습니다. Anthropic의 Claude Opus 4.6이 생성한 이 코드는 문법적으로 완벽했고, 컴파일도 됐습니다. 문제는 단 하나였습니다. 곱셈이 없었습니다.
cbETH/ETH 교환 비율을 ETH/USD 가격에 곱해야 했는데, AI는 원시 교환 비율을 그대로 달러 가격으로 사용했습니다. 실제 cbETH 가격은 약 2,200달러였지만, 오라클은 1.12달러를 보고했습니다. 99.9% 저평가. 아비트라지 봇들이 즉시 달려들어 헐값에 담보를 쓸어갔습니다.
더 무서운 건 이 버그를 아무도 잡지 못했다는 사실입니다. 인간 리뷰어도, GitHub Copilot도, OpenZeppelin의 자동화 스캐너도 모두 통과시켰습니다. 자동화 편향(automation bias) — 고급 모델과 스캐너를 너무 믿은 나머지, 정작 핵심 로직을 검증하는 사람이 없었던 것입니다.
명암의 반대편: AI로 1주일 만에 프레임워크를 만든다
물론 AI 코드의 이야기가 사고와 실패뿐은 아닙니다. Cloudflare는 한 명의 엔지니어가 일주일 만에 Next.js 호환 프레임워크 vinext를 AI와 함께 만들어냈다는 사례(GeekNews)를 공개했습니다. 전체 코드의 대부분이 AI가 작성했고, 총 비용은 약 1,100달러였습니다.
빌드 속도는 기존 Next.js 대비 4.4배 빠르고, 클라이언트 번들 크기는 57% 작습니다. Next.js API 호환성은 94%. 그리고 1,700개의 Vitest 테스트와 380개의 Playwright 테스트가 품질을 담보했습니다.
"AI as Engineering Force Multiplier" 관점(dev.to)에서 보면, AI는 파이프라인 실행 시간을 50% 줄이고, 낯선 코드베이스 파악 시간을 40% 단축하며, 문서화 정확도를 60%에서 95%로 끌어올립니다. 이 숫자들은 실제로 측정된 수치입니다.
생산성 극대화와 신뢰 과잉은 동전의 양면입니다. vinext가 가능했던 이유는 명확한 명세, 촘촘한 테스트 스위트, 그리고 AI 출력에 대한 지속적인 검증이 있었기 때문입니다.
AI-First 워크플로우에서 '신뢰'를 재설계하는 법
이 모든 사례가 가리키는 결론은 하나입니다. AI를 버릴 필요는 없습니다. 하지만 AI를 어떻게 신뢰할지를 설계해야 합니다.
저는 팀에 다음 세 가지 원칙을 적용하고 있습니다.
첫째, 프롬프트부터 보안을 심어라. "X를 하는 함수를 써줘" 대신 "프로덕션에 들어갈 X 함수를 써줘. 입력 유효성 검사, 에러 핸들링, 보안 고려사항을 포함하고, 네가 가정한 것들을 명시해줘"라고 요청합니다. 출력이 길어지지만, 실제로 쓸 수 있는 코드가 나옵니다.
둘째, AI에게 AI 코드를 리뷰시켜라. 생성된 코드를 새 채팅창에 붙여넣고 "이 코드의 보안 취약점을 찾아줘. 프로덕션에 들어간다고 가정하고 가혹하게 봐줘"라고 물으면, 절반의 경우에 AI가 자신의 실수를 찾아냅니다. 빠르게 배우는 주니어 개발자와 협업하는 것과 같습니다.
셋째, AI 코드에 Zero Trust를 적용하라. Moonwell 사건처럼, 특히 금융 로직이나 핵심 인프라를 다루는 코드는 "AI가 검토했다"는 사실이 아니라 "우리가 직접 수학과 로직을 검증했다"는 기준으로 배포 여부를 결정해야 합니다. 재무 자산이나 핵심 인프라에 영향을 주는 코드에는 멀티 시그 승인 구조를 도입할 것을 권장합니다.
전망: '검증 자동화'가 다음 전선이다
Agentic AI의 시대가 본격화되면서 패러다임이 바뀌고 있습니다. 인간이 버그를 만드는 전통적 워크플로우에서, 이제는 AI 에이전트가 코드를 작성하고 테스트하고 배포까지 합니다. 취약점은 더 이상 인간의 실수가 아니라, 실행 권한을 가진 환각(hallucination with execution power)이 됩니다.
vinext 프로젝트가 보여준 것처럼, AI가 복잡한 시스템을 재구현하는 능력은 이미 현실입니다. 동시에 Moonwell 사건이 보여준 것처럼, AI의 논리적 환각은 문법 검사기나 일반 보안 스캐너로는 잡히지 않습니다.
앞으로 AI-First 팀이 투자해야 할 영역은 명확합니다. 생성 자동화가 아니라 검증 자동화입니다. AI가 코드를 더 빠르게 만들수록, 그 코드의 논리적 일관성을 검증하는 특화된 도구와 프로세스의 중요성은 정비례로 커집니다.
"AI가 썼으니까 괜찮겠지"라는 자신감은, 사실 가장 위험한 취약점입니다. 우리가 AI를 쓰면서도 궁극적으로 코드에 대한 책임을 지는 사람이어야 하는 이유입니다.