20년 경력 개발자가 AI 에이전트에게 이메일만 보내 5일 만에 프로덕트를 완성했다는 이야기가 dev.to에 올라왔다. 160통의 이메일, $15짜리 토큰 비용, 사람이 직접 쓴 코드 0줄. 숫자만 보면 혁명이다. 그런데 그 글의 절반은 칭찬이 아니라 경고로 채워져 있다. "빌드가 됐다는 건 작동한다는 게 아니다." 이 한 문장이 현재 AI 코딩 워크플로우의 핵심 모순을 정확히 찌른다.
왜 AI 코드는 데모에선 완벽하고 프로덕션에선 무너지나
같은 dev.to의 다른 글은 이 현상을 '바이럴 데모의 5가지 거짓말'이라는 프레임으로 해부한다. AI 코딩 에이전트가 최적화하는 대상은 '시각적 정확성'과 '즉각적 속도'다. 보안도, 확장성도, 결정론적 신뢰성도 아니다. 인증 플로우를 요청하면 React 프런트엔드는 완벽하게 렌더링하지만, HMAC 서명 키를 클라이언트 사이드 번들에 그냥 박아버린다. Supabase를 연동하면서 Row-Level Security 정책은 통째로 건너뛴다. 버튼을 누르면 DB에 레코드가 저장된다—이게 '기능적 동등성'이다. 하지만 프로덕션 레디니스의 기준은 완전히 다르다. 동시 트래픽, 적대적 요청, 연쇄 장애 속에서 데이터를 지키고 서버를 살려야 한다.
이 괴리가 가장 위험하게 작동하는 지점은 경험이 없는 사람이 AI를 쓸 때다. "내가 프롬프트를 작성했으니 내가 이 시스템을 만든 것"이라는 착각—글에서는 이를 '숙달의 환상'이라고 부른다—이 팀으로 하여금 생성된 시스템의 견고함을 과대평가하고, 보안과 확장성에 필요한 엔지니어링 노력을 심각하게 과소평가하게 만든다. AI가 코드를 지시할 수 있다는 것과 소프트웨어를 설계할 수 있다는 것은 전혀 다른 능력이다.
20년 경력자가 버텨낸 이유: 경험은 AI가 복제할 수 없다
다시 첫 번째 글로 돌아오면, 그 20년 경력자가 AI 에이전트를 성공적으로 다룰 수 있었던 이유가 나온다. "나는 멀티테넌시 버그가 올 것을 알았다. 내가 그 버그를 직접 심어본 적이 있기 때문이다. 입력값 검증이 없다는 것도 알았다. 그게 신입들이 처음 빠뜨리는 것이기 때문이다." AI가 만드는 실수의 패턴을 알아보는 능력은 수년간 직접 그 실수를 저질러온 사람만이 가진다. 역설적이게도, AI 코딩 워크플로우에서 가장 중요한 자산은 코드를 직접 쓰는 능력이 아니라 AI가 무엇을 틀렸는지 알아채는 경험적 직관이다. 그리고 이 직관은 코드를 직접 쓰지 않으면 사라진다. "AI가 우리 일자리를 빼앗는 게 진짜 리스크가 아니다. 코드 작성을 멈추면, 코드를 쓰는 AI를 조종하는 능력도 잃는다는 게 진짜 리스크다."
구조적 해법: AI가 코드 전에 질문하게 만들기
이 문제를 워크플로우 레벨에서 정면으로 다룬 시도도 있다. Spec-Kit-CoLearn이라는 오픈소스 프레임워크는 AI가 코드 작성 전에 반드시 질문하도록 강제하는 두 단계 모드를 도입했다. 1단계(Senior Architect Mode)에서는 AI가 3~6개의 발견 질문을 던지고, 트레이드오프를 설명하며, 엣지 케이스를 최소 3개 이상 짚는다. 코드는 한 줄도 쓰지 않는다. 사용자가 명시적으로 '승인'하면 비로소 2단계(Coding Worker Mode)로 전환되어 스펙에 맞게 코드를 작성한다. 아이디어는 단순하다. 시니어 개발자는 요구사항을 듣는 즉시 에디터를 열지 않는다. AI도 그렇게 동작해야 한다.
이 프레임워크의 핵심 통찰은 AI 코딩 도구의 문제가 '코드 품질'이 아니라 '질문 순서'에 있다는 점이다. AI는 현재 속도에 최적화되어 있고, 사람은 그 속도에 압도되어 설계 단계를 건너뛴다. 결과물은 빠르게 완성된 것처럼 보이지만, 이해할 수 없고 확장할 수 없으며 디버깅할 수 없는 코드다. 개발자가 3개월 후 자신이 만든 인증 시스템을 전혀 이해하지 못한다는 저자의 고백이 이를 압축한다.
팀 리드가 지금 당장 해야 할 판단
세 가지 글감이 수렴하는 결론은 하나다. AI 코딩 도구의 ROI는 속도가 아니라 '검증 가능성'으로 측정해야 한다. 빌드 시간이 90분에서 10분으로 줄어도, 프로덕션 장애 대응과 보안 패치에 3주가 걸린다면 순이익은 마이너스다. 팀이 AI 생성 코드를 검증할 능력을 유지하고 있는가, AI가 설계 단계를 건너뛰지 않도록 워크플로우가 설계되어 있는가, 주니어 개발자가 AI 코드를 이해하지 못한 채 프로덕션에 밀어 넣고 있지는 않은가—이 세 질문이 팀 내 AI 도입 성숙도를 가르는 기준선이다.
"코드 타이핑은 이제 공짜다." 20년 경력자의 이 말은 축하가 아니라 경고로 읽혀야 한다. 공짜가 된 것은 코드 생성이지, 코드 설계가 아니다. AI가 빠르게 짠 코드가 오래 못 버티는 이유는 AI의 한계가 아니라, 설계 없이 생성을 승인한 워크플로우의 구조적 결함이다. 그 구조를 바꾸는 건 여전히 사람의 몫이다.