AI가 코드를 거의 다 쓰는 시대, 개발자 역할은 어떻게 바뀌나

출처: The Pragmatic Engineer (Gergely Orosz)
원문: https://newsletter.pragmaticengineer.com/p/when-ai-writes-almost-all-code-what
작성자: 팔복소프트-김팔복

한눈에 보기

• 2025년 11~12월에 나온 Gemini 3, Opus 4.5, GPT-5.2를 기점으로 "코드 대부분을 AI가 쓴다"는 말이 가정이 아니라 현실이 됐다는 분석입니다.
• Claude Code를 만든 Boris Cherny는 한 달 동안 IDE를 한 번도 열지 않고, 약 200개의 PR을 전부 AI로 작성했다고 밝혔습니다.
• 프로토타입 제작, 여러 언어 숙련, 잘 정의된 티켓 구현처럼 '코드를 직접 치는 능력'의 가치는 내려갑니다.
• 요구사항 정리, 테스트·검증 체계, 아키텍처, 기술 부채 관리 같은 '엔지니어링' 역량의 가치는 오히려 올라갑니다.
• 코드가 늘어난 만큼 문제도 늘어, 한 조사에서는 배포 변경 실패율이 30% 올랐습니다.
• 2026년 1월 유료 글이었으나, DHH가 Rails World에서 37signals의 전면 AI 코드 생성을 밝힌 직후 9월 24일 무료 공개됐습니다.

배경

AI 코딩 도구는 지난 1~2년 사이 '다음 줄을 추천하는 자동완성'에서 '작업을 통째로 맡는 에이전트'로 옮겨 왔습니다. Claude Code, Codex, Cursor 같은 에이전트는 코드베이스를 읽고, 여러 파일을 고치고, 테스트를 돌리고, PR까지 올립니다. 원문 저자 Gergely Orosz는 Uber 등을 거친 엔지니어입니다.

주요 내용

회의론자들이 먼저 입장을 바꿨다

2025년 10월 AI 코딩 도구를 과대평가됐다고 평한 Andrej Karpathy는 두 달 뒤 프로그래머로서 이렇게 뒤처진 느낌은 처음이라고 썼습니다. AI에게 코드를 맡기지 않겠다던 DHH도 모델이 좋아지며 입장을 뒤집었습니다.

저자 본인도 TypeScript, Node/Express, React, Postgres 스택에서 자신이 쓰는 코드의 90% 정도는 AI가 생성할 수 있다고 체감합니다. 휴가 중엔 휴대폰으로 PR을 검토하고 머지까지 했는데, 위험이 낮고 로직이 전부 테스트로 덮인 작업이었다는 단서를 붙입니다.

가치가 내려가는 역량, 올라가는 역량

원문의 주장을 역량 단위로 정리했습니다.

저자는 Atlassian의 2025년 개발자 경험 보고서(응답자 3,500명)를 인용해, 평균적인 개발자가 주당 업무 시간 중 코딩에 쓰는 비율이 16%에 그친다고 짚습니다.

불편한 결과들

• 코드가 늘면 문제도 는다. Meta 출신 Michael Novati는 AI 사용 이후 PR 수가 두 배가 됐습니다. Cortex의 2026년 벤치마크 보고서(엔지니어링 리더 50여 명 대상)는 변경 실패율(장애나 롤백을 일으킨 배포 비율)이 30% 올랐다고 봤습니다.
• 약한 개발 문화가 더 빨리 드러난다. 테스트와 관측성(observability)이 약한 팀은 회귀 버그가 더 빨리 운영에 닿습니다.
• 퇴근 후 경계가 흐려진다. 휴대폰으로 수정·배포가 가능해지면 '어디서든 일할 수 있는 상태'가 됩니다.
• 신입에게 시니어 기준이 요구된다. 작업 분해, AI 결과 검증, 테스트가 입문 단계의 기본값이 됩니다.

PM과 개발의 경계가 겹친다

저자는 PM이 개발자를 대체하기보다 두 역할이 겹칠 것으로 봅니다. WorkOS는 PM 1명당 엔지니어가 약 80명이고, Linear는 초기 몇 년간 PM 없이 운영했습니다. Linear 공동창업자 Karri Saarinen은 이렇게 말했습니다.

이 시대에는 에이전트의 작업을 지휘하고 관리하는 일이 곧 기술이 된다.
— Karri Saarinen, Linear 공동창업자

팔복소프트 관점

• 국내 분업 구조에 먼저 영향이 옵니다. 기획서와 화면설계서가 내려오고, 퍼블리셔·프론트엔드·백엔드가 나눠 구현하는 구조에서 '명세대로 구현하는 구간'이 AI로 가장 먼저 넘어갑니다. 반대로 SI 프로젝트에서 익숙한 요구사항 정의서와 설계서 문화는 에이전트에게 줄 컨텍스트로 재활용할 수 있습니다. 단, 비기능 요구사항까지 제대로 적혀 있을 때 얘기입니다.
• 도입 순서는 테스트가 먼저입니다. 저자의 성공 사례도 '로직 전부가 테스트로 덮인 단순한 코드베이스'라는 전제 위에 있었습니다. 테스트 커버리지가 낮은 Java/Spring 레거시에 에이전트부터 붙이면 생산성보다 회귀 버그가 먼저 늘어날 가능성이 큽니다.
• 체감 성능은 환경마다 다릅니다. 원문도 학습 데이터가 풍부한 언어와 프레임워크에서 잘 된다고 말합니다. 사내 전용 프레임워크나 오래된 버전에 묶인 시스템이라면 공개 후기만큼의 효과를 기대하기 어렵습니다. 망분리나 소스코드 외부 반출 금지 정책이 있는 조직은 도구 선택 단계에서 이미 제약이 걸리므로, 보안 정책 확인이 파일럿보다 앞서야 합니다.
• 신입 육성 방식을 다시 짜야 합니다. 코드를 많이 쓰면서 배우던 경로가 줄어들면, 코드 리뷰와 설계 토론을 교육 수단으로 명시적으로 운영해야 합니다.
• 근거의 한계도 봐야 합니다. 원문에 나온 사례 상당수는 AI 도구 회사 관계자이거나 개인·그린필드 프로젝트입니다. 30%라는 실패율 수치도 50여 명 규모 설문입니다. 방향성은 맞다고 보지만, 우리 팀 수치로 검증하기 전까지 그대로 일반화하지 않는 편이 안전합니다.

정리

기억할 것은 하나입니다. 코드 작성 비용이 내려갈수록, 그 코드를 믿을 수 있게 만드는 능력의 값이 올라갑니다. 지금 팀에서 할 일은 AI 도구 비교보다 테스트, CI, 관측성, 요구사항 문서의 수준을 점검하는 것입니다. 그 토대가 있는 팀은 AI로 속도를 얻고, 없는 팀은 AI로 사고를 더 빨리 냅니다.

추천 태그:

• AI코딩에이전트
• ClaudeCode
• 소프트웨어엔지니어링
• 테스트자동화
• 개발자커리어