AI 코드 생성의 '도파민 트랩'
Claude나 Copilot이 30초 만에 300줄을 뽑아내는 장면은 분명 짜릿하다. Cursor AI가 연간 매출 20억 달러를 돌파하며 생성형 AI 소프트웨어 시장의 25%를 점유할 만큼, 도구의 성장세는 의심할 여지가 없다. UX 디자이너조차 에이전틱 엔지니어링의 '오케스트레이터'로 진화하고 있다는 브런치의 분석처럼, AI 코딩 도구는 이미 특정 직군의 전유물이 아니다.
그런데 바로 그 속도감이 함정이다. dev.to의 Gerus-lab 팀은 14개 이상의 프로덕트를 AI 도구와 함께 출시한 경험을 바탕으로 불편한 진실을 꺼낸다. "대부분의 팀이 AI 생성 코드로 시한폭탄을 만들고 있다." 도구가 나빠서가 아니라, 사용 방식이 근본적으로 잘못됐다는 것이다.
LLM은 '이해'하지 않는다, '예측'할 뿐이다
AI 코드 품질 문제의 핵심은 LLM의 작동 원리 그 자체에 있다. 대형 언어 모델은 코드를 '이해'해서 작성하는 것이 아니라, 학습 데이터에서 통계적으로 그럴듯한 토큰 시퀀스를 예측한다. 인증 미들웨어를 작성하라고 요청하면 AI는 보안을 추론하는 것이 아니라, 수백만 개의 코드 예시에서 패턴 매칭을 수행한다.
결과물은 종종 완벽해 보인다. 깔끔한 포맷, 적절한 변수명, 인라인 주석까지. 그러나 Gerus-lab이 클라이언트 코드베이스를 감사하며 발견한 것들은 SQL 인젝션 벡터, 처리되지 않은 레이스 컨디션, 특정 부하 패턴에서 인증 토큰을 유출하는 WebSocket 구현이었다. AI는 악의가 없었다. 그냥 유창하게, 자신 있게 틀렸을 뿐이다.
카네기멜론대학교의 AI 코드 생성 기술 분석 연구 역시 같은 방향을 가리킨다. AI는 개발 속도를 높이지만 코드 품질을 저하시켜 결국 프로젝트 속도를 늦출 수 있다는 것이다. '환각(hallucination)'은 버그가 아니라, 시스템이 설계된 대로 작동하는 결과다.
주니어 개발자 파이프라인이 무너지고 있다
Gerus-lab이 지목하는 두 번째 문제는 더 장기적이고 구조적이다. AI 도구가 시니어 엔지니어를 만들어내는 학습 파이프라인을 망가뜨리고 있다는 것.
전통적인 성장 경로는 이랬다. 주니어가 나쁜 코드를 작성한다 → 시니어가 리뷰한다 → 주니어가 왜 나쁜지 배운다 → 시간이 지나면 스스로 나쁜 코드를 알아본다. AI는 이 루프를 단락(short-circuit)시킨다. 주니어는 이제 나쁜 코드를 쓰지 않는다. 이해하지 못한 그럴듯한 코드를 생성할 뿐이다. 뭔가 잘못됐을 때 AI에게 픽스를 요청하고, AI는 패치를 생성하고, 그 패치가 새 문제를 낳는다. 반복.
DeFi 프로토콜 사례는 이를 극명하게 보여준다. AI 생성 스마트 컨트랙트는 문법적으로 완벽했지만, 특정 유동성 조건에서 왜 특정 AMM 설계가 실패하는지에 대한 제도적 지식이 빠져 있었다. 2023년 데이터로 학습된 AI가 가질 수 없는 종류의 맥락이었다. 결과는 두 달간의 코어 로직 전면 재작성과 런칭 지연이었다.
검증의 역설: AI가 AI를 심사할 때
AI를 코드 생성기와 코드 리뷰어로 동시에 쓰면 어떻게 될까. Gerus-lab은 이를 '닫힌 피드백 루프(closed feedback loop)'라고 부른다. AI는 AI가 생성한 코드를 훌륭하다고 평가한다. 작은 문제는 찾아내 도움이 되는 척하지만, 근본적인 아키텍처가 잘못됐다고는 절대 말하지 않는다. 왜냐면 그 결과에 아무런 이해관계가 없기 때문이다.
경험 많은 시니어 엔지니어는 다르다. "이 패턴이 세 번 실패하는 걸 봤다"고 말하며 밀어붙인다. 그 마찰(friction)이 나쁜 아이디어를 프로덕션 재앙이 되기 전에 걸러내는 메커니즘이다. AI 어시스턴트는 사용자 만족에 최적화되어 있지, 프로덕트 성공에 최적화되어 있지 않다. 두 목표는 다르다.
'AI로 코드를 검증하는' 새로운 레이어의 등장
역설적이게도, AI 코드의 신뢰성 문제를 해결하려는 시도 역시 AI에서 나오고 있다. AI타임스의 보도에 따르면, 수학 AI 기업 액시엄(Axiom Math)이 수학적 형식 증명 기술을 코드 검증으로 확장한 '액시엄프루버(AxiomProver)'를 공개하며 2억 달러의 투자를 유치했다.
수학 정리 검증을 위해 개발된 프로그래밍 언어 린(Lean)을 활용해, AI가 수학 문제를 증명하는 방식으로 코드의 정확성을 논리적으로 검증하는 접근이다. 이 전이 학습(transfer learning) 방식은 AI가 먼저 수학적 추론 능력을 학습한 뒤, 그 논리 검증 역량을 소프트웨어 코드에 적용한다. 하모닉, 로지컬 인텔리전스 등 유사한 방향의 스타트업들도 실리콘밸리에서 경쟁 중이다.
물론 한계는 명확하다. 수학에서는 정답과 오답이 이분법적이지만, 소프트웨어에서는 '정확한 코드'의 정의 자체가 맥락에 따라 달라진다. 수억 명이 동시 접속하는 서비스에서 '올바른 코드'란 단순히 문법이 맞는 코드가 아니다. 카네기멜론대의 Bogdan Vasilescu 교수가 지적하듯, "AI가 검증할 수 있는 영역은 분명히 있지만, 코드의 모든 문제를 완전히 해결한다는 의미는 아니다."
신뢰 가능한 AI 워크플로우를 설계하는 법
이 모든 맥락을 종합하면, 답은 AI를 덜 쓰는 것이 아니라 어디에 쓸지를 설계하는 것이다. Gerus-lab의 워크플로우는 하나의 참조 모델이 된다.
- 인간 아키텍트 → 시스템 설계 (AI 없음)
- 시니어 개발자 → 핵심 비즈니스 로직 (AI 없음)
- AI 지원 → 보일러플레이트, 테스트, 문서화
- 시니어 개발자 → AI가 손댄 모든 것 리뷰
- 아키텍트 → 최종 아키텍처 승인
Cursor AI의 플랜 모드(Plan Mode)는 이 철학과 정확히 맞닿아 있다. 코드를 한 줄도 쓰기 전에 에이전트가 구현 계획을 수립하도록 강제하는 것, 즉 '추측에 의한 코딩'이 아닌 '설계에 기반한 엔지니어링'으로 격상시키는 것이다. 클라우드 에이전트가 작업 결과를 비디오와 스크린샷으로 기록해 PR과 함께 '증거 자료'를 제공하는 방식도 같은 맥락이다. AI의 자율성을 높이되, 인간이 검증할 수 있는 감사 추적(audit trail)을 설계에 내장하는 것.
앞으로: '검증 레이어'가 경쟁 우위가 된다
AI 코드 생성이 보편화될수록, 역설적으로 진짜 엔지니어링 깊이를 가진 프로덕트는 희소해진다. Gerus-lab의 표현을 빌리면, 모두가 AI 생성 코드를 쏟아낼수록 진짜로 설계된 소프트웨어의 가치는 올라간다.
액시엄프루버 같은 AI 코드 검증 레이어의 등장은 이 흐름을 가속한다. 생성(generation)과 검증(verification)이 분리된 두 레이어로 명확해지는 것, 그리고 그 사이에서 '무엇을 AI에게 맡기고 무엇을 인간이 판단하는가'를 설계하는 역량이 개발자와 팀의 핵심 역량이 될 것이다.
프론트엔드 개발자로서 내가 지금 당장 해야 할 질문은 이것이다. 내 워크플로우에서 AI가 틀렸을 때, 그것을 잡아낼 레이어가 설계되어 있는가. 속도를 얻기 전에, 먼저 그 구조를 설계해야 한다.