AI가 코드를 대부분 작성해도 남는 일, 설계와 검증과 책임

TL;DR

• AI가 코드의 90% 이상을 작성한다는 수치는 업계 전체의 실측 결과가 아니라 글의 분석 전제다. 저자의 성공 사례는 자동화 테스트가 갖춰진 저위험·단순 코드베이스에서 나왔다. 기존 시스템의 조직적 복잡성과 운영 위험까지 같은 비율로 사라지는 것은 아니다.
• 프로토타입과 명확한 티켓의 구현이 쉬워지면 코드 입력과 특정 문법의 상대적 가치는 낮아질 수 있다. 대신 무엇을 만들지 정하고 비기능 요구사항과 구조를 설계하는 역량이 중요해진다. 이는 엔지니어링 전문성 전체가 불필요해진다는 전망과 다르다.
• AI가 만든 코드와 테스트에는 검증을 반복할 수 있는 환경이 필요하다. 컴파일과 정적 분석, 자동화 테스트뿐 아니라 테스트 자체의 적절성과 운영 관측도 확인해야 한다. 코드 생산이 빨라질수록 취약한 개발 관행의 피해도 빨리 누적될 수 있다.
• 제품 관리자와 엔지니어는 서로의 일을 더 많이 수행할 가능성이 있다. 주니어에게는 작업 분해와 아키텍처, 제품 판단 등 더 넓은 역량이 일찍 요구될 수 있다. 역할의 융합과 교육 경로의 변화는 전망이며 확정된 채용 결과가 아니다.
• 원격 에이전트와 모바일 개발은 개인의 작업 자유와 업무 침범을 함께 늘릴 수 있다. 손으로 코드를 완성하던 숙련과 만족감이 약해지는 상실도 남는다. 늘어난 소프트웨어의 유지보수와 장애에 대한 책임은 여전히 사람과 조직이 맡는다.

1월의 전망이 9월에 다시 공개된 이유

Gergely Orosz의 원문은 2026년 1월 6일 글이다. RosettaLens의 한국어 번역 생성일과 원문 발행일은 구분해야 한다. 원문 상단의 추가 설명에 따르면 9월 23일 Rails World에서 DHH가 37Signals의 코드 생성 방식을 발표한 뒤 9월 24일 유료 장벽을 없앴다. 따라서 본문에 나오는 연말 모델 출시와 연초의 전망은 9월 시점에 새로 관찰한 현상만을 뜻하지 않는다.

출발점은 저자의 구독 관리 기능과 관리 패널 개발이었다. Opus 4.5와 GPT-5.2로 중간 규모 작업을 처리하고 결과와 테스트를 검토한 뒤 수백 줄을 운영에 배포했다. Claude Code for Web을 GitHub에 연결해서 휴대폰으로 변경을 요청하고 GitHub Actions의 검사를 거쳐 PR을 검토·병합한 경험도 포함된다. 다만 위험도가 낮았고 비즈니스 로직에 자동화 테스트가 있었다. 이 조건을 빼면 휴대폰만으로 어떤 운영 시스템이든 안전하게 개발할 수 있다는 다른 주장으로 바뀐다.

코드 생성의 확산을 가정하되 범위를 남긴다

원문은 여러 숙련 개발자가 모델의 개선을 체감한 사례를 모은다. DHH의 태도 변화와 Karpathy의 새로운 도구 계층에 대한 평가, Boris Cherny가 한 달 동안 약 200개 PR의 모든 코드를 AI로 작성했다는 자기 보고가 이어진다. 이는 도구를 잘 활용한 사람들의 경험이며 무작위 표본의 생산성 실험은 아니다. 저자도 비공개 제품인 Claude Code의 기여 내역을 외부에서 검증하기 어렵다는 한계를 인정한다.

이후의 논의는 많은 개발자와 팀이 코드의 약 90% 이상을 생성하게 될 경우를 가정한다. 제품·시장 적합성을 탐색하며 작업을 버릴 수 있는 스타트업과 새 코드베이스가 가까운 후보로 꼽힌다. 반대로 대규모 조직에서는 이미 코드 작성보다 주변 조정과 복잡한 맥락을 다루는 일이 더 클 수 있다. 생성 코드의 비중과 전체 개발 시간, 유지보수 비용, 고용 수요를 같은 지표로 취급할 수 없는 이유다.

덜 희소해지는 구현과 더 중요한 판단

비개발자도 프로토타입을 만들고 개발자는 익숙하지 않은 언어나 스택에 진입하기 쉬워진다. 명확한 버그 티켓의 구현과 반복적인 리팩터링도 에이전트에 넘길 여지가 커진다. Orosz는 이런 변화가 특정 언어의 문법과 구현 속도만으로 차별화하던 역량의 상대적 가치를 낮출 수 있다고 본다. 그러나 개념 증명에서 중복 코드가 허용된다는 설명을 성숙한 운영 코드의 검토 생략으로 확대하지는 않는다.

구현을 맡기려면 사용자 요구와 예외 상황뿐 아니라 성능·접근성·신뢰성·보안 같은 비기능 요구사항을 정의해야 한다. 작업을 나누고 의존성과 인터페이스를 정하며 모놀리스나 서비스 경계 같은 구조를 선택하는 일이 남는다. 원문이 더 중요해질 것으로 보는 것은 이런 테크 리드 역량과 제품 판단이다. 안전하고 빠른 코드를 만들어 달라는 요청만으로 요구 수준과 검증 방법이 정해지지는 않으며 필요한 경우 사람이 직접 코드나 설정을 다룰 전문성도 유지된다.

생산량과 품질을 따로 측정한다

에이전트에는 자신의 결과를 반복해서 확인할 수 있는 피드백이 필요하다. 컴파일·정적 분석·단위 테스트·통합 테스트를 실행하는 환경과 CI/CD가 그 기반이다. 생성 모델이 적절한 테스트까지 저절로 설계한다고 가정하지 않고 어떤 동작과 예외를 검증해야 하는지 지정하고 결과를 읽어야 한다. 코드베이스가 커져 검사가 느려지면 중복 테스트와 실행 시간을 정리하는 일도 중요해진다. 검증 속도는 개발 경험의 부수적인 편의에 그치지 않는다.

원문이 인용한 Cortex의 공개 요약은 50명이 넘는 엔지니어링 리더 조사와 여러 조직의 개발 지표를 설명한다. 작성자당 PR은 전년 대비 20%, PR당 사고는 23.5%, 변경 실패율은 약 30% 늘었다는 보고다. 마지막 수치는 실패율이 30%라는 뜻이나 30%포인트 상승했다는 뜻이 아니다. 공개 요약만으로 표본 구성과 인과관계를 확정할 수 없으며 보고서 전문 다운로드는 정보 입력을 요구해 확보하지 않았다. 이 관찰을 모든 조직에서 AI가 동일한 수준의 사고를 유발했다는 결론으로 바꾸면 안 된다.

테스트와 관측 가능성이 약한 조직은 코드를 더 빨리 내보낼수록 회귀와 장애를 더 빨리 쌓을 수 있다. 커진 PR을 예전과 같은 시간에 검토하기 어렵고 기술 부채와 자원 사용량도 늘어난다. 그래서 생산량만 높이는 것과 유지 가능한 개발 속도를 높이는 것은 별도 목표다. 서비스의 담당자와 운영 중 확인할 지표, 장애 대응과 부채 정리까지 함께 설계하는 사람이 필요해진다.

제품과 교육, 일의 경계도 변한다

제품 관리자는 직접 프로토타입을 만들고 엔지니어는 고객의 요구를 듣고 작업을 정하는 비중을 늘릴 수 있다. 원문은 PM이 엔지니어를 단순히 대체하기보다 두 역할이 더 겹치고 정형적인 요구사항 전달이 줄어드는 방향을 예상한다. 의도를 코드로 옮기는 중간 작업이 얇아질수록 무엇을 만들며 어떤 제약과 트레이드오프를 받아들일지가 중요해진다. 작동하는 초안을 만드는 능력과 운영 결과를 책임지는 능력이 완전히 같아지는 것은 아니다.

주니어에게 작업 분해와 테스트·관측 가능성·아키텍처·기술 부채 관리가 일찍 요구될 수 있다. 과거에는 코드를 많이 작성하고 동료의 검토를 받으면서 익히던 판단을 어떤 과정으로 배울지 문제가 남는다. Orosz는 이론과 팀 프로젝트를 제공하는 대학 교육의 가치가 커질 가능성을 제시하지만 학위가 모든 채용의 필수가 됐다는 실측 주장은 아니다. 요구 수준이 높아진다는 전망과 신입이 그것을 실제로 배울 수 있게 만드는 교육은 구분할 필요가 있다.

휴대폰에서 개발할 수 있다는 장점에는 근무 시간 밖에도 일을 처리하라는 압력이 따라올 수 있다. 저자는 도구에 대한 기대와 함께 손으로 코드를 완성하던 숙련과 몰입을 잃는 감각도 남긴다. 이를 단순히 변화에 적응하지 못하는 태도로 지워 버리지는 않는다. 더 많은 소프트웨어가 만들어지더라도 장애와 유지보수의 책임은 사라지지 않으며 엔지니어의 역할은 그 책임을 수행하는 방향으로 다시 구성될 가능성이 있다.

참고 자료

RosettaLens — AI가 거의 모든 코드를 작성하면 소프트웨어 엔지니어링에는 무슨 일이 일어날까?

Gergely Orosz — When AI writes almost all code, what happens to software engineering?

Cortex — Engineering in the Age of AI: 2026 Benchmark Report 공개 요약