빈 파일 앞에서 손이 멈췄다. 문제를 몰라서가 아니라, 손이 자동으로 AI 사이드바를 향했기 때문이다. dev.to에 올라온 한 시니어 개발자의 고백은 이렇게 시작한다. 수년간 레거시 마이그레이션을 이끌고 주니어를 멘토링해온 그가 어느 순간 깨달은 것—'생각하기'가 조용히 '프롬프트하기'로 바뀌어 있었다는 것이다.
이 이야기가 불편하게 느껴진다면, 아마 당신도 그 경험이 있기 때문일 것이다. AI 코딩 도구는 처음엔 지루한 보일러플레이트를 덜어주는 생산성 레버였다. 그다음엔 설계 초안을 제안해주는 브레인스토밍 파트너가 되었다. 그리고 어느 순간부터는, 문제를 직접 정의하기도 전에 채팅창부터 여는 습관이 생겼다. 글쓴이가 '프롬프트 라우터'라고 자조한 것처럼, 도구를 사용하는 것이 아니라 도구에 사고의 출발점을 통째로 위임하게 된 것이다.
이 상태가 시니어 개발자에게 특히 위험한 이유는 명확하다. 주니어는 코드를 타이핑하는 대가를 받는다. 시니어는 판단하는 대가를 받는다. 문제를 올바르게 정의하고, 나쁜 방향에 '노'라고 말하고, 3개 스프린트 중 진짜 중요한 하나를 고르는 능력—이것이 시니어의 핵심 자산이다. 그런데 바로 그 판단력을 AI에 아웃소싱하기 시작하면, 남는 것은 '모델이 온라인 상태일 때만 작동하는 고속 티켓 처리기'뿐이다. 더 심각한 건 주니어들이 그 모습을 보고 배운다는 점이다. 시니어가 설계 결정을 프롬프트로 처리하는 장면만 목격한 주니어는 '시니어란 좋은 프롬프트를 아는 사람'이라고 학습한다.
그런데 이 개인적 역량 퇴화 문제는, 더 넓은 산업 규모의 품질 위기와 정확히 맞닿아 있다. 또 다른 dev.to 글은 지금의 상황을 Unity·Unreal이 무료화된 이후 게임 산업에 비유한다. 당시 툴의 장벽이 무너지자 Steam 출시 게임 수는 2012년 303개에서 2021년 11,236개로 폭증했다. 그러나 2025년 기준, 출시 게임의 47.5%가 100장 미만 판매에 그쳤다. 무료 툴은 소수의 천장을 높이고, 대다수의 바닥을 낮췄다. AI 코딩 도구의 궤적이 동일하게 겹친다.
GitHub Copilot이 4,600만 라인 이상의 코드를 분석한 GitClear 연구에 따르면, 코드 리팩토링 비율은 2021년 25%에서 2024년 10% 미만으로 60% 감소했고, 코드 중복은 약 4배 증가했다. Stanford 연구에서는 AI 보조 개발자가 그렇지 않은 개발자보다 보안 취약점을 더 많이 만들면서도, 자신의 코드가 더 안전하다고 믿는 경향을 보였다. Veracode의 2025년 보고서는 AI 생성 코드의 45%가 보안 취약점을 도입한다고 밝혔다. '4시간 만에 SaaS 완성'을 자랑했던 한 개발자는 런칭 72시간 만에 브라우저 콘솔에서 변수 하나만 바꾸면 결제 페이지가 우회되는 취약점에 당했다. 보안 로직 전체가 클라이언트 사이드에 놓여 있었고, 그는 AI가 생성한 15,000줄의 코드를 스스로 감사할 수 없었다.
그렇다면 '제대로 쓴다'는 것은 무엇인가. 세 번째 글은 그 실마리를 제공한다. Claude Code를 활용해 Rust·Python·Go·React가 혼재하는 프로덕션급 도구를 수 주에 걸쳐 구축한 한 개발자의 방법론이다. 그가 발견한 핵심 문제는 AI의 능력이 아니라 '컨텍스트의 휘발성'이었다. 새 세션이 시작될 때마다 에이전트는 과거의 모든 아키텍처 결정을 기억하지 못한다. 그 결과, 테스트는 통과하지만 설계 의도와는 조금씩 어긋난 코드가 조용히 쌓인다.
그의 해법은 역할의 분리다. Supervisor(장기 Claude 채팅) 가 아키텍처를 책임지고, Executor(Claude Code) 는 정밀한 지시 하에 실행만 한다. Project Owner인 개발자는 Claude Code에 직접 프롬프트를 날리지 않는다. 대신 Supervisor와 대화해 의도를 구체화하고, Supervisor가 Executor를 위한 정밀한 지시문을 생성한다. 여기에 세 개의 외부 메모리 문서—ARCHITECTURE.md(시스템의 현재 상태), DECISIONS.md(왜 이렇게 만들었는가), CLAUDE.md(누적된 코딩 규칙)—가 세션 간 일관성을 보장한다. 에이전트의 기억은 휘발되지만, 문서는 남는다.
이 방법론의 묘미는 Phase Audit에 있다. 각 개발 단계가 끝날 때, Supervisor에게 문서와 실제 코드를 전면 비교하는 감사를 수행하도록 지시한다. 코드를 수정하지 말고, 감사만 하라고. AI Ranger 프로젝트의 Phase 1 감사에서 37개의 불일치가 발견됐다. 이미 제거된 기능이 README에 남아 있었고, 문서와 코드 사이에 Phase 번호가 다른 필드도 있었다. 테스트에서는 아무것도 걸리지 않았지만, 첫 번째 기여자가 마주쳤다면 몇 시간을 낭비했을 함정들이었다.
세 편의 글이 하나로 수렴하는 지점이 보인다. AI 도구는 생각을 대신하지 않는다. 생각의 재료를 더 빠르게 공급할 뿐이다. 재료를 어떻게 조합할지 판단하는 사람이 없으면, 속도는 부채의 축적 속도가 된다. 시니어 개발자의 제안처럼 '처음 20분은 프롬프트 없이' 시작하는 것, Supervisor-Executor 역할을 분리하는 것, 세션이 끝날 때마다 문서를 업데이트하는 것—이 모든 행동의 공통 구조는 하나다. AI가 실행하기 전에, 내가 먼저 생각한다.
앞으로 AI 보조 개발의 생산성 격차는 더 벌어질 것이다. 다만 그 격차가 '누가 더 좋은 도구를 쓰는가'가 아니라 '누가 자신의 판단력을 보존하면서 도구를 운용하는가'로 결정될 가능성이 높다. 게임 업계에서 '어셋 플립'이 Unity를 욕먹게 만들었듯, AI 생성 코드의 품질 위기는 도구의 문제가 아니라 도구를 쥔 손의 문제다. 결국 AI 시대에도 희소한 자원은 같다. 올바른 질문을 정의하는 능력, 그리고 그 답을 스스로 평가하는 판단력.