Eureka Labs 창립자 Andrej Karpathy가 최근 이렇게 말했습니다. “몇 주 만에 80% 수동 코딩에서 80% 에이전트 코딩으로 완전히 뒤집혔어요. 이제 정말 영어로 프로그래밍하고 있습니다.” Claude Code 팀도 비슷한 경험을 공유했죠. 하루에 20개 이상의 PR을 올리는데, 모두 100% AI가 작성한 코드라고 합니다.
예전에는 AI가 코드의 70%를 작성하고 나머지 30%는 사람이 완성하는 ‘70% 문제’가 화두였습니다. 이제 그 비율이 80%를 넘어섰지만, 흥미로운 건 숫자보다 문제의 본질이 바뀌었다는 점입니다. Google Chrome 팀의 엔지니어링 매니저 Addy Osmani가 5,000명 개발자 설문과 최신 연구 데이터를 종합해 이 변화의 실체를 분석했습니다.
출처: The 80% Problem in Agentic Coding – Addy Osmani Substack
에러의 본질이 바뀌었다
AI가 만드는 실수가 달라졌습니다. 예전에는 문법 오류나 단순한 버그였다면, 이제는 개념적 실패로 진화했죠. Karpathy는 이렇게 설명합니다. “모델이 당신을 대신해서 잘못된 가정을 하고 확인 없이 그대로 진행합니다. 혼란을 관리하지 못하고, 명확한 설명을 요구하지 않으며, 모순을 드러내지도 않아요.”
구체적으로 어떤 문제가 생길까요? 가정 전파(assumption propagation)가 대표적입니다. 모델이 초반에 뭔가를 잘못 이해하면 그 위에 전체 기능을 쌓아 올립니다. 5개의 PR이 쌓인 후에야 아키텍처가 잘못됐다는 걸 깨닫죠. 추상화 과잉도 문제입니다. 100줄이면 충분한 걸 1,000줄짜리 정교한 클래스 계층으로 만들어버립니다. 유지보수성보다 ‘포괄적으로 보이는 것’을 최적화하는 겁니다.
이런 문제들은 시스템 프롬프트나 계획 모드로도 완전히 해결되지 않습니다. 에이전트가 일관된 출력을 최적화하도록 설계되었지, 당신의 전제를 의심하도록 만들어지지 않았기 때문이죠.
‘이해 부채’라는 새로운 문제
Jeremy Twei가 만든 용어인 comprehension debt(이해 부채)가 핵심을 찌릅니다. LLM이 작동하는 것처럼 보이는 코드를 한 번에 만들어내면 그냥 넘어가고 싶은 유혹이 생깁니다. 에이전트는 지치지 않으니까요. 자신감 넘치게 구현을 이어갑니다. 코드는 그럴듯해 보이고, 테스트도 통과합니다. 출시 압박도 있고요. 그래서 넘어갑니다.
Osmani는 자신의 경험을 털어놓습니다. “지난주에 Claude가 며칠 동안 미뤄뒀던 기능을 구현했어요. 테스트가 통과했고, 대충 훑어보고 머지했죠. 3일 후 그게 어떻게 작동하는지 설명할 수 없었습니다.”
코드를 쓰는 능력(generation)과 읽는 능력(discrimination)은 다릅니다. 직접 처음부터 작성할 능력이 사라진 후에도 코드를 유능하게 리뷰할 수는 있어요. 하지만 어느 시점이 지나면 ‘리뷰’가 ‘도장 찍기’가 되어버립니다. 시간이 지날수록 자신의 코드베이스를 이해하지 못하게 되는 겁니다.
생산성은 올랐지만 시간은 안 줄었다
데이터가 역설을 보여줍니다. Faros AI와 Google DORA 보고서에 따르면, AI를 많이 쓰는 팀은 머지하는 PR이 98% 증가했습니다. 하지만 같은 팀의 리뷰 시간이 91% 늘어났죠. PR 크기는 평균 154% 커졌고, 코드 리뷰가 새로운 병목이 되었습니다.
Atlassian의 2025년 설문은 이 역설을 더 극명하게 드러냅니다. AI를 쓰는 개발자의 99%가 주당 10시간 이상을 절약한다고 답했지만, 대부분은 전체 업무량이 줄지 않았다고 말합니다. 코드 작성에서 아낀 시간이 컨텍스트 전환과 조율 오버헤드, 늘어난 변경사항 관리로 소진된 거죠.
우리는 더 빠른 차를 얻었지만, 도로가 더 막혔습니다. 어떤 자원(여기서는 코드 생성)이 싸지면 소비가 효율성 개선보다 빠르게 증가하고, 총 자원 사용량이 늘어납니다. 우리는 코드를 덜 쓰는 게 아니라 훨씬 더 많이 쓰고 있고, 누군가는 여전히 그 많은 코드를 이해해야 합니다.
“코딩 vs 빌딩” 개발자의 분기점
Karpathy의 관찰이 가장 통찰력 있습니다. “LLM 코딩은 엔지니어를 나눌 겁니다. 주로 코딩을 좋아했던 사람들과 주로 만드는 것을 좋아했던 사람들로요.”
만약 코드를 쓰는 행위 자체, 그 장인정신과 명상 같은 느낌을 좋아했다면 이 전환은 상실처럼 느껴질 겁니다. 만약 무언가를 만드는 게 좋았고 코드는 필요한 수단이었다면, 이건 해방처럼 느껴지죠. 둘 다 틀린 반응이 아닙니다. 하지만 도구는 후자를 위해 최적화되고 있습니다.
Armin Ronacher의 5,000명 개발자 설문은 이분화를 보여줍니다. 44%는 여전히 코드의 90% 이상을 수동으로 작성합니다. 반면 Karpathy나 Claude Code 팀처럼 하루에 수십 개의 PR을 올리며 100% AI 작성 코드로 이전보다 빠르게 반복하는 사람들도 있죠. 종 모양 곡선이 아니라 양극화 분포입니다.
성공하는 개발자들은 단순히 더 나은 도구를 쓰는 게 아닙니다. 자신의 역할을 구현자(implementer)에서 조율자(orchestrator)로 재개념화했습니다. 명령형이 아닌 선언적으로 사고하는 법을 배웠고, 이제 자신의 일이 한 줄씩 코딩하는 게 아니라 아키텍처 감독과 품질 관리라는 걸 받아들였죠.
남은 질문들
80% 임계점은 그린필드 프로젝트에서 가장 현실적입니다. 전체 스택을 통제하고 이해 부채가 작은 팀 규모로 관리 가능한 곳에서요. 개인 프로젝트, MVP, 레거시 제약 없는 스타트업 같은 환경에서는 에이전트의 약점이 덜 문제가 됩니다. 빠르게 스캐폴딩하고, 공격적으로 리팩토링하고, 정치적 마찰 없이 코드를 버릴 수 있으니까요.
하지만 복잡한 불변성을 가진 성숙한 코드베이스에서는 계산이 역전됩니다. 에이전트는 자신이 모르는 걸 모릅니다. 암묵적인 규칙을 직관할 수 없죠. 자신감은 컨텍스트 이해와 반비례합니다.
Karpathy는 이렇게 마무리합니다. “에이전트와 함께하면 채워 넣기식 단조로운 작업이 사라져서 프로그래밍이 더 재미있게 느껴집니다. 창의적인 부분만 남거든요. 또 막히거나 멈추는 느낌이 덜하고, 함께 손잡고 긍정적인 진전을 이룰 방법이 거의 항상 있기 때문에 훨씬 더 용기가 생깁니다.”
AI가 엔지니어를 대체하는 건 아닙니다. 증폭시키는 거죠. 좋은 쪽으로든 나쁜 쪽으로든. 소프트웨어 엔지니어로서 우리의 정체성은 결코 “코드를 쓸 수 있는 사람”이 아니었습니다. “소프트웨어로 문제를 해결할 수 있는 사람”이었죠. 그 본질은 여전히 유효합니다.
참고자료:
답글 남기기