코드를 타이핑하던 시대는 끝났다, 그런데 진짜 문제는 지금부터다
Andrej Karpathy가 최근 X(트위터)에서 선언한 내용은 꽤 충격적이었습니다. 주말 하루, AI 에이전트에게 SSH 키 설정부터 vLLM 서버 구축, Qwen3-VL 벤치마크, 웹 UI 대시보드, systemd 서비스 설정까지 통째로 맡겼더니 30분 만에 완료 보고서가 나왔다는 겁니다. 3개월 전이라면 주말 내내 붙잡았을 프로젝트가요.
저도 이걸 읽으면서 "이제 진짜 게임이 바뀌었구나" 싶었습니다. Karpathy 본인도 "컴퓨터 발명 이래 에디터에 코드를 직접 타이핑하던 시대는 끝났다"고 단언했고, 이제 개발자의 역할은 에이전트를 실행하고 영어로 지시하며 병렬로 관리하는 에이전틱 엔지니어링으로 이동했다고 봤습니다.
그런데 데이터가 불편한 진실을 말하고 있습니다
팀 리드 입장에서 이 흥분을 식혀주는 데이터가 있습니다. GitHub의 리서치는 Copilot이 개발 속도를 55% 높인다고 말하지만, GitClear가 1억 5천만 줄 이상의 변경 코드를 분석한 결과는 다른 이야기를 합니다.
- 버그 수정 비율 23.7% 증가
- 코드 처닝(2주 내 재작성) 비율 유의미하게 상승
- 복붙 코드 전년 대비 8% 증가
dev.to의 Alex Mayhew가 이름 붙인 개념이 딱 맞습니다. '생성형 부채(Generative Debt)'. 빠르게 만들고, 더 오래 고치는 구조. 속도(velocity)와 생산성(productivity)은 다릅니다. 생산성은 단위 시간당 전달된 가치이고, AI가 만들어낸 코드가 아키텍처를 위반하거나 존재하지 않는 라이브러리를 호출한다면 속도는 오히려 부채를 가속시키는 엔진이 됩니다.
생성형 부채의 두 얼굴: 구조적 오염과 맥락 누락
생성형 부채는 크게 두 가지 형태로 나타납니다.
첫 번째는 구조적 부채입니다. AI는 기술적으로는 동작하지만 아키텍처적으로는 틀린 코드를 생성합니다. 당신의 팀이 서비스 레이어 패턴을 쓰는데, AI는 fetch('/api/users/id')를 바로 호출하는 함수를 뚝딱 만들어줍니다. 기능 테스트는 통과하고, 코드 리뷰에서 놓치면 그냥 병합됩니다. 어느 순간 코드베이스 80%가 아키텍처 패턴을 위반한 상태가 됩니다. AI 코드는 태어난 날부터 레거시입니다.
두 번째는 맥락 누락입니다. dev.to의 Giovanni Rufino가 PowerPoint 사례로 잘 설명한 것처럼, AI는 '명확화 엔진'이 아니라 '완성 엔진'입니다. RLHF 훈련 과정에서 질문하는 것보다 즉각적인 답변을 제공하도록 강화된 탓에, 맥락이 부족하면 채우는 게 아니라 만들어냅니다. 마이크로서비스 환경에서 Angular 앱 컨텍스트만 넣고 Python 백엔드 연동을 물으면, AI는 존재하지 않는 API 엔드포인트와 없는 데이터 구조를 자신 있게 설계해줍니다. 이걸 믿고 진행하면 엔지니어링이 아니라 다음 프로덕션 장애를 정밀하게 오케스트레이션하는 것입니다.
팀에서 실제로 벌어지는 일
저도 비슷한 상황을 팀에서 목격합니다. 시니어 개발자는 AI가 생성한 코드를 즉시 검증하고, 아키텍처 위반을 걸러내며, 없는 라이브러리를 잡아냅니다. 그래서 시니어는 AI 보조 코드를 2.5배 더 많이 출하합니다. 더 많이 써서가 아니라, 결과물을 검증할 수 있어서입니다.
반면 주니어 개발자는 다릅니다. Copilot이 제안한 라이브러리가 실재하지 않는데, 스텁 함수를 작성해서 개발 환경에서는 통과시킵니다. 프로덕션에서 검증 함수가 아무것도 검증하지 않는 상태로 2주 동안 돌아갑니다. 정리에 또 2주. 결국 AI가 만든 속도는 팀 전체의 수리 비용으로 전환됩니다.
96%의 개발자가 AI 아웃풋을 믿지 않는다고 말하면서, 50% 이상이 꼼꼼히 리뷰하지 않는다는 수치가 이 모순을 설명합니다.
그럼 어떻게 해야 하나: 컨텍스트 오케스트레이터가 되어야 합니다
Karpathy도 솔직하게 인정했습니다. 에이전틱 엔지니어링이 특히 잘 작동하는 경우는 "작업 명세가 명확하고, 기능을 검증/테스트할 수 있을 때"라고요. 역으로 말하면, 맥락이 불명확하고 검증 루프가 없으면 에이전트는 자신 있게 틀린 방향으로 질주합니다.
저는 Claude Code를 활용한 워크플로우를 팀에 정착시키면서 몇 가지 원칙을 세웠습니다.
1. 컨텍스트 프론트로딩. 아키텍처 설계를 요청하기 전에 Swagger 문서, DB 스키마, 프론트엔드 컴포넌트 구조, 미들 티어 페이로드 모델을 모두 컨텍스트에 집어넣습니다. AI가 상상으로 채울 여백을 없애는 겁니다.
2. 명시적 명확화 강제. 프롬프트 끝에 항상 붙입니다. "솔루션을 제시하기 전에 시스템 아키텍처, 배포 환경, 누락된 API 계약에 대해 최대 3가지 명확화 질문을 먼저 하세요." AI의 기본 본능(즉시 코드 생성)을 의도적으로 억제하는 겁니다.
3. CLAUDE.md로 아키텍처 메모리 고정. Claude Code 시리즈에서도 강조된 패턴입니다. 팀의 네이밍 컨벤션, 레이어링 규칙, 에러 핸들링 전략, 마이그레이션 방식을 CLAUDE.md에 선언해두면, 매번 프롬프트에 설명하지 않아도 AI가 팀의 아키텍처 안에서 추론합니다. 부족 지식을 1급 아티팩트로 전환하는 것입니다.
4. AI 코드는 주니어 PR처럼 리뷰. 신뢰하되 검증합니다. "내 아키텍처 기준으로" 리뷰하는 것이 핵심입니다. AI의 훈련 데이터 기준이 아니라요.
에이전틱 시대, 개발자의 역할은 어디로 가나
Karpathy가 제시한 그림이 맞습니다. 최상위 레버리지는 올바른 도구·메모리·지시를 갖춘 오케스트레이터가 여러 병렬 코드 인스턴스를 관리하는 구조입니다. 하지만 Giovanni Rufino의 표현이 이를 더 날카롭게 정리합니다. "우리의 역할은 이제 코드를 짜거나 시스템을 설계하는 것만이 아니다. 컨텍스트 관리를 마스터하는 것이다. AI가 무엇을 모르는지 아는 것이 현대 소프트웨어 설계에서 가장 중요한 기술이 되고 있다."
Claude Code 시리즈의 결론도 같은 방향을 가리킵니다. "Claude Code는 주로 당신을 빠르게 만드는 게 아닙니다. 더 정확하게 만듭니다." AI 시대의 개발자는 코드를 더 많이 쓰는 사람이 아니라, 시스템의 맥락을 가장 잘 이해하고 AI의 인식론적 공백을 가장 잘 채우는 사람입니다.
팀에게 전하고 싶은 말
에이전틱 엔지니어링의 레버리지가 지금처럼 높았던 적은 없습니다. 하지만 레버리지는 방향이 맞을 때만 가속입니다. 방향이 틀리면 같은 속도로 낭떠러지에 가까워집니다.
"AI로 빠르게 만들자"가 아니라 "AI로 올바르게 만들자"가 AI-First 팀의 진짜 슬로건이어야 합니다. 생성형 부채를 인식하고, 맥락 오케스트레이션을 팀의 핵심 역량으로 키우고, 검증 루프를 워크플로우에 내재화하는 것. 그것이 에이전틱 시대에 팀이 실제로 빨라지는 방법입니다.
AI가 빠를수록 팀이 느려지는 역설은 피할 수 없는 운명이 아닙니다. 우리가 선택하는 워크플로우의 결과입니다.