30분 만에 8,500줄, 그런데 61%가 쓰레기였다
dev.to에 올라온 한 실험 기록이 AI-First 팀이라면 반드시 읽어야 할 사례를 담고 있습니다. 개발자 shimo4228은 Kimi K2.5 코딩 에이전트에 8개 태스크를 위임했고, 30분 만에 8,500줄의 코드가 생성됐습니다. 파일 트리는 그럴듯했고, 비즈니스 로직도 실제로 작동했습니다. 그런데 다음 날 아침 생성된 캐릭터 사전을 열어보니 1,225개 항목 중 752개의 설명이 "정답은 C입니다."였습니다. 퀴즈 앱 데이터에서 각 에피소드의 첫 문장을 캐릭터 설명으로 추출했는데, 그 첫 문장이 항상 퀴즈 정답 안내 문구였던 겁니다. Kimi는 코드가 실행되는지는 검증했지만, 데이터의 의미가 맞는지는 한 번도 들여다보지 않았습니다.
더 흥미로운 건 그 이후입니다. 수정을 요청하자 Kimi는 이렇게 답했습니다. "Kimi에게 위임한 결과이니, Claude(저)가 책임지고 수정해야 합니다." 자신이 작성한 코드를 두고 위임자가 책임져야 한다는 논리였고, 심지어 스스로를 Claude라고 인식하고 있었습니다. 스펙 파일 헤더에 "Generated by Claude Code"라는 문구가 있었던 탓입니다. AI의 정체성이 이렇게까지 취약할 수 있다는 점, 저도 Claude Code로 작업하다 보면 컨텍스트 오염이 얼마나 미묘하게 작동하는지 실감하는 순간들이 있거든요. 결국 Opus가 투입돼 5개 커밋으로 커버리지를 25%에서 86.4%까지 끌어올렸지만, 근본적인 데이터 소스 문제는 해결되지 않았습니다. 위임 전에 데이터 구조를 검증하지 않은 것, 스펙이 불완전했던 것—실패의 원인은 에이전트가 아니라 위임하는 방식에 있었습니다.
AI 시대의 새로운 함정: 시작은 쉬워졌는데, 끝내기는 더 어려워졌다
또 다른 dev.to 아티클은 AI가 만들어낸 역설적인 생산성 문제를 짚습니다. AI 이전에는 사이드 프로젝트를 시작하는 비용이 높았습니다. 아이디어가 떠올라도 구현 비용을 따져보고 대부분 포기했죠. 그런데 AI 덕분에 시작 비용이 극단적으로 낮아지면서, 우리는 이제 Main Project A(어렵고 중요한 것)보다 Side Project D(쉽고 AI에 맡기기 좋은 것)를 계속 선택하게 됩니다. AI가 새 프로젝트 초반을 빠르게 달려가는 장면을 보는 것 자체가 도파민을 자극하기 때문입니다.
결과는 미완성 프로젝트의 무한 증식입니다. 인지 부하는 쌓이고, 정작 완성해야 할 핵심 프로젝트는 제자리걸음을 합니다. 해당 아티클의 저자는 "AI 시대에 가장 중요한 능력은 시작하지 않는 능력일 수 있다"고 결론 내립니다. AI로 무언가를 시작하는 건 쉬워졌지만, '완성'이라는 희소 자원을 어디에 쓸지 결정하는 판단력은 오히려 더 중요해졌다는 이야기입니다. 팀 리빌딩을 하다 보면 이 패턴을 정말 자주 목격합니다. AI 도입 초기일수록 팀원들이 새 기능을 AI로 빠르게 프로토타입하는 데 에너지를 쏟고, 기존 기술 부채는 더 깊어지는 경우가 많거든요.
위임에 실패하는 세 가지 패턴
dev.to의 또 다른 아티클(러시아어 원문)은 AI를 활용하는 개발자 유형을 세 가지로 분류합니다. 이걸 위임 실패 관점에서 재해석해보면 패턴이 선명해집니다.
첫 번째 유형: "AI는 사기, 나는 직접 짠다" — AI 도구를 원칙적으로 거부합니다. 코드 이해력은 높지만, 2~3년 후 경쟁력이 흔들릴 수 있습니다. 속도 격차가 벌어지기 때문입니다.
두 번째 유형: "AI가 다 써줄 거야" — ChatGPT 결과를 이해 없이 붙여넣습니다. 표준적인 태스크에선 빠르지만, 비표준 문제가 등장하는 순간 무너집니다. Kimi 사례의 핵심도 여기에 있습니다. 에이전트가 생성한 코드를 실행 전에 한 번만 들여다봤어도 데이터 오염을 잡을 수 있었을 겁니다.
세 번째 유형: "AI는 내 멀티플라이어" — AI가 생성한 코드를 이해하고, 오류를 찾아낼 수 있으며, 루틴은 AI에게 맡기고 자신은 아키텍처와 복잡한 판단에 집중합니다. 이 유형이 고용되고, 더 많이 법니다.
"AI를 싫어하는 전문가"의 시사점
흥미롭게도 네 번째 아티클은 완전히 다른 각도를 제시합니다. 7년 경력의 테크 리드가 AI 코딩에 강하게 저항하는 이야기인데, 그가 지적하는 핵심은 예리합니다. AI는 통계적으로 가장 많이 쓰인 솔루션을 제안하는데, 실제로 작성된 코드의 대부분은 형편없다는 것입니다. 평균적인 답이 정답이 아닌 경우, AI는 구조적으로 실패합니다. 그리고 그 슬롭이 다시 학습 데이터로 들어가면서 품질이 스스로 무너지는 루프가 만들어진다고 경고합니다.
그가 틀리지 않았습니다. 하지만 이 비판이 적용되는 건 주로 '두 번째 유형'의 위임 방식입니다. 검증 없이 붙여넣고, 의미를 확인하지 않고, 맥락 없이 위임할 때요. 세 번째 유형처럼 AI 생성물을 인간이 검증하고 다듬는 협업 모델에서는 이 위험이 상당 부분 통제됩니다.
잘 맡기는 팀이 되는 법: 세 가지 실천
이 사례들을 종합하면, AI-First 팀이 위임 실패를 피하기 위해 반드시 갖춰야 할 원칙이 보입니다.
1. 스펙이 완성돼야 위임이 시작된다. Kimi 사례에서 스펙은 데이터 함정을 명시하지 않았습니다. "correctSummary의 첫 문장은 퀴즈 정답 안내 문구이므로 제외할 것"이라는 한 줄이 8,500줄의 재작업을 막을 수 있었습니다. AI에게 태스크를 위임하기 전에, 그 태스크를 충분히 이해하고 있는지 먼저 점검해야 합니다. 이해하지 못한 태스크는 위임할 수 없습니다.
2. 의미 검증은 인간의 몫이다. AI는 코드가 실행되는지 검증하지만, 데이터의 의미가 맞는지는 검증하지 못합니다. CI/CD 파이프라인에서도 마찬가지입니다. 테스트가 통과한다고 프로덕트가 올바른 건 아닙니다. AI가 생성한 결과물에는 반드시 '의미 레이어'의 인간 검증이 필요합니다.
3. 시작 충동을 관리하라. AI가 시작 비용을 낮췄다는 건, 이제 팀의 가장 중요한 의사결정이 "무엇을 시작하지 않을 것인가"로 이동했다는 뜻입니다. 팀 단위로 WIP 한도를 설정하고, AI 덕분에 생긴 여유 시간을 새 프로젝트가 아니라 기존 프로젝트의 완성도 향상에 쓰는 규율이 필요합니다.
결론: AI-First는 'AI에게 다 맡기기'가 아니다
Kimi가 8,500줄을 30분에 생성한 건 인상적입니다. 하지만 그게 팀의 생산성이 된 건 Opus가 맥락을 이해하고 패치한 뒤였고, 근본 해결은 더 나은 데이터 소스를 인간이 판단한 뒤였습니다. AI-First 워크플로우의 진짜 의미는 AI에게 더 많이 맡기는 게 아닙니다. AI가 잘하는 것과 인간이 해야 하는 것을 구분하는 판단력을 팀 전체가 갖추는 것입니다. 그 판단력 없이 위임의 속도만 올리면, 결과물의 61%가 쓰레기인 채로 다음 날 아침을 맞게 됩니다.