에이전트가 코드를 다 쓰면 개발자는 무엇을 하나, 앤드루 응의 답

마지막 5편을 알리며 응은 AI 엔지니어링 역량을 갖추면 무엇을 만들지에 영향을 주고 만드는 과정의 반복을 이끌게 된다고 썼습니다. 8월 14일 1편에서 네 역량의 이름을 내건 뒤 매주 한 편씩, 다섯 번의 편지로 지도를 완성했습니다. 편 이름을 누르면 The Batch 원문으로 이동합니다.

1편과 2편은 역량 지도 첫 편지와 AI 앱 구축을 다룬 2편에서 따로 다뤘습니다. 네 역량의 하위 항목은 모두 20개이고, 이 글은 그 가운데 3~5편이 풀어낸 14개를 다룹니다.

3편, 에이전트가 코드를 다 써도 기본기가 필요한 이유

3편은 에이전트 코딩 시대에 소프트웨어 공학의 기본기가 어떻게 달라졌느냐는 물음으로 시작합니다. 응의 답은 코딩 에이전트가 코드를 전부 써 주더라도, 원하는 트레이드오프(하나를 얻으려면 다른 하나를 내줘야 하는 선택)를 고르도록 에이전트를 이끌려면, 그리고 그런 트레이드오프가 있다는 것을 알려면 기본기가 필요하다는 것입니다. AI 앱을 만들 때도 AI가 맡는 부분은 더 큰 소프트웨어에 담겨 돌아가고, 그 소프트웨어를 빚는 것은 엔지니어라는 설명이 붙습니다.

응은 기본기 없이 바이브 코딩을 하는 초보자도 간단한 앱은 만들 수 있지만, 그 과정에서 에이전트가 지연, 가용성, 일관성, 신뢰성, 유지보수성, 단순성, 비용 일곱 가지 가운데 어딘가에서 나쁜 선택을 하기 쉽다고 적었습니다. 대개 개발자가 그런 트레이드오프가 있다는 것조차 몰라 에이전트를 올바른 방향으로 이끌지 못했다는 겁니다. 예를 들어 응답을 빠르게 하려고 캐시를 넣으면 지연은 줄지만, 사용자가 잠시 옛 데이터를 보게 되는 일관성 문제가 따라옵니다.

다섯 가운데 응이 따로 힘을 준 것은 데이터 관리입니다. 데이터는 소프트웨어가 올라서는 바탕이고, 에이전트가 마이그레이션을 거들어도 비교적 바꾸기 어렵다는 이유입니다. 응은 AI 시스템이 입력 맥락을 그 데이터에서 얻기 때문에 데이터 구조를 잘못 고르면 AI는 자기가 무엇을 모르는지도 모르게 되고, 그래서 맥락을 가진 숙련된 사람, 곧 이 글을 읽는 개발자가 개입해 바로잡아야 한다고 적었습니다.

아키텍처는 움직이는 표적이라고 했습니다. 빠른 시제품에 맞는 단순한 구조가 첫 운영 시스템에는 맞지 않을 수 있고, 그 구조도 사용자가 늘면 다시 달라진다는 겁니다. 보안에서는 소프트웨어를 다 만든 뒤에 보안을 고민하던 순서를 개발 초기로 당기는 시프트 레프트(shift left)를 짚으며, 모든 개발자가 풀스택으로 넓어지듯 많은 개발자가 부분적으로 보안 엔지니어가 됐다고 봤습니다. AI 도구로 코드 취약점과 의존성 공급망 공격, 클라우드 설정의 공격 표면을 훑을 수 있지만 그 일을 잘하려면 여전히 보안 지식이 있어야 한다는 조건도 붙였습니다.

3편의 결론은 코딩 문법을 외우는 것 같은 지식은 쓸모를 잃어 가지만, 소프트웨어가 어떻게 돌아가는지 깊이 아는 개발자는 모르는 채 바이브 코딩하는 개발자를 크게 앞선다는 것입니다. 코딩 에이전트가 AI가 들어가지 않은 소프트웨어를 만드는 방식까지 바꿔 놓았다는 진단도 덧붙였습니다.

코드베이스를 한 달에 세 번 갈아엎던 팀

데이터가 바꾸기 어렵다는 3편의 문장과 달리, 응은 1년여 전 강연에서 정반대로 들리는 이야기를 했습니다. 2025년 6월 와이 컴비네이터 강연에서 그는 자기 팀이 지난 한 달 동안 코드베이스를 세 번이나 처음부터 다시 만들었고, 코드를 새로 짜는 비용이 급락해 데이터 스키마를 새로 골라도 괜찮아졌다고 말했습니다.

응은 되돌리기 어려운 결정을 일방통행 문, 싸게 되돌릴 수 있는 결정을 양방향 문으로 부르는 제프 베이조스의 표현을 빌렸습니다. 기술 스택과 데이터베이스 스키마를 고르는 일은 예전에는 일방통행 문이었지만, 이제 팀이 일주일 만에 코드를 버리고 새 스택으로 다시 짜는 일도 생겼다는 겁니다. 다만 완전히 양방향 문이 된 것은 아니고 늘 그렇게 하지도 않으며, 다시 만드는 데는 여전히 비용이 든다는 단서를 달았습니다.

같은 강연에서 응은 구분을 하나 더 했습니다. 빨리 만들어 보는 시제품은 AI로 10배 넘게 빨라졌지만, 운영 중인 코드는 엄밀한 수치를 찾기 어렵다는 전제로 30~50% 정도 빨라진 것 같다는 겁니다. 시제품은 기존 시스템이나 기존 데이터와 엮일 일이 적고 신뢰성과 확장성, 보안 요구도 낮기 때문이라며, 자기 노트북에서만 돌릴 시제품이라면 허술한 코드도 괜찮지만 남에게 내보내기 전에는 반드시 안전하게 고치라고 했습니다.

두 말은 부딪히지 않습니다. 코드베이스를 갈아엎던 쪽은 데이터가 쌓이기 전의 시제품이고, 3편이 말한 데이터는 사용자와 기록이 쌓인 운영 시스템의 바탕입니다. 아키텍처가 프로젝트 단계에 따라 움직이는 표적이라는 3편의 문장이 이 간극을 메웁니다.

4편, 계획과 실행과 배포, 그리고 다섯 가지 역량

4편은 코딩 에이전트를 쓰는 능력이 다른 최상위 역량보다 더 빨리 변한다는 말로 시작합니다. Claude Code, Codex, Cursor 같은 상용 에이전트와 OpenCode, Pi 같은 개방형 에이전트가 하네스와 모델 양쪽에서 성큼성큼 발전하고 있어서, 실험하고 만들고 배우는 일을 계속해야 따라갈 수 있다는 겁니다. 여기서 말하는 활용에는 코드 작성과 함께 데이터 분석이나 시스템 운영처럼 코딩 도구로 하는 다른 업무도 들어갑니다.

변화의 속도는 응이 2025년 6월 강연에서 직접 그린 연대기에 나옵니다. 2021년 6월 29일 공개된 깃허브 코파일럿이 코드 자동 완성을 널리 퍼뜨렸고, 이어 커서(Cursor)와 윈드서프(Windsurf) 같은 AI 통합 개발 도구가 나왔으며, 2024년 말 무렵부터 스스로 여러 단계를 실행하는 에이전트형 코딩 도구가 등장했다는 겁니다. 응은 그 강연에서 도구가 반 세대만 뒤처져도 생산성 차이가 크다고 말했습니다.

4편에서 응은 최고 수준의 AI 엔지니어 수십 명을 인터뷰하고 자기 팀의 경험을 돌아봐, 에이전트와 소프트웨어를 만드는 공통된 작업 흐름을 세 단계로 정리했습니다. 계획 단계 끝에는 세운 계획을 다시 검토해 주요 가정을 캐묻고 보안 허점이나 과잉 설계를 찾아내는 일까지 들어 있습니다.

이 작업 흐름은 코딩 에이전트가 나오기 전에 소프트웨어를 만들던 흐름과 비슷합니다. 지금 우리는 코드에 훨씬 덜 집중하고, 무엇을 만들지 정하고 구조를 설계하고 명세를 쓰고 결과를 검증하는 데 집중합니다.— 앤드루 응, DeepLearning.AI 창업자

단계마다 드는 시간은 프로젝트에 따라 크게 다릅니다. 처음부터 새로 만드는 그린필드 시제품은 짧은 프롬프트 하나가 명세를 대신하기도 하지만, 사용자가 많은 기존 서비스(브라운필드)는 명세를 쓰고 검증하는 데 훨씬 큰 노력이 든다고 응은 설명했습니다. 검증에서 실패하면 구현으로, 모니터링에서 문제가 나오면 설계로 되돌아가는 판단도 숙련의 일부로 꼽았습니다.

세부 항목 가운데 몇 가지는 지금 에이전트를 쓰는 개발자라면 바로 알아볼 문제입니다. 응은 작업 도중 바뀐 가정까지 기록해 다음 단계의 에이전트가 쓰게 하라고 했고, 테스트 자체가 목표에 맞는지 평가하고 맞지 않으면 고치라고 했습니다. 새 모델이 옛 우회책을 필요 없게 만들면 스킬도 정리하고, 에이전트가 쌓은 부채를 가끔 치우는 일도 목록에 넣었습니다.

작동 원리를 알아야 하는 이유로는 실패 유형 네 가지를 들었습니다. 단순한 해법을 지나치게 복잡하게 만들기, 명시적인 검증 절차가 없어 엄밀함을 잃기, 목표에 닿기 전에 멈추기, 파일이나 운영 데이터를 망가뜨릴 수 있는 행동입니다. 에이전트가 지금 어떤 상태인지 추론할 수 있어야 알맞은 맥락을 주고, 엉뚱한 방향으로 갈 때 끼어들 수 있다는 설명입니다.

병렬로 도는 에이전트 사이에서 사람의 주의력을 어떻게 나눌지도 응이 적은 항목입니다. 오픈AI의 피터 스타인버거는 7월 공개된 AI 엔지니어 콘퍼런스 발표에서 이 문제를 자기 경험으로 풀었습니다. 1월에는 터미널 창 열 개 이상을 번갈아 보며 에이전트에게 일을 넣었는데, 지금은 오래 도는 관리자 에이전트 하나와 주로 대화하고 그 관리자가 작업자 에이전트들에게 일을 나눠 준다는 겁니다.

YouTube 영상 · 누르면 재생

관리자 에이전트는 이슈가 들어오면 프로젝트의 목표와 메모에 비춰 맡을 만한지 판단하고, 작업자를 만들어 조사와 구현, 테스트를 시키고, 다른 에이전트에게 검토를 맡깁니다. 사람이 필요할 때만 PR과 원래 이슈, 제안된 diff, 영상이나 원격으로 접속할 수 있는 실행 화면을 돌려줍니다. 스타인버거는 토큰과 컴퓨트 문제를 풀고 나니 이제 자신을 묶는 것은 주의력이라며, 에이전트가 안쪽 실행 루프를 돌리고 자신은 바깥 루프에서 방향과 결정을 맡는다고 말했습니다.

저는 4편에서 바뀐 가정을 남기라는 대목과 테스트 자체를 점검하라는 대목을 가장 실용적으로 봤습니다. 요구사항이 달라졌는데 에이전트와 테스트가 예전 목표를 따르면, 구현을 계속 쌓아도 원하는 결과에서 멀어지기 때문입니다.

4편은 GPT-6 Astra 출시 다음 날 나왔다

4편 끝에서 응은 소셜미디어가 코딩 에이전트 쓰는 법을 지나치게 단순하게 그린다고 적었습니다. 에이전트를 몇 시간씩 자율로 돌리며 토큰을 수백만, 수천만 개씩 쓰게 하는 방식이 쓸모 있을 때도 있지만, 아주 긴 작업의 실용성은 특히 비용에 견줘 실제보다 부풀려졌다는 겁니다. 가장 효과적인 사용은 복잡하고 반복적인 과정이고, 숙련된 판단으로 끼어들 수 있을 때 결과가 훨씬 좋다고 봤습니다.

이 편지는 9월 4일(미국 시각) 나왔습니다. 하루 전인 9월 3일 오픈AI가 GPT-6 Astra를 공개했고, 그 주 X에는 Astra로 오래 돌린 작업이 잇달아 올라왔습니다. GTA 6 스크린샷을 참고해 브라우저에서 돌아가는 3D 게임을 만드는 데 약 90시간이 들었다는 게시물도 그중 하나였습니다.

로버를 만드는 한 개발자는 설계에서 마음에 안 드는 점을 잔뜩 적어 Astra에 맡기고 잠들었습니다. Astra는 밤새 5시간 반 넘게 일했고, 이 한 번에 월 200달러 Pro 요금제(Plus의 20배 사용량) 주간 한도의 52%가 들었습니다.

드론이 사무실에서 특정 사람을 찾아 따라가게 한 Andon Labs의 과제에서 Astra는 다섯 하위 과제 각각에서 적어도 한 번은 사람을 이긴 첫 모델이 됐지만, 처음부터 끝까지 한 번에 성공할 확률은 평균 2.8%였습니다. 오픈AI는 9월 10일 가장 비싼 200달러 Pro 요금제의 신규 가입을 멈췄습니다. 그 주의 사례와 가입 중단 경위는 오픈AI의 Pro 신규 가입 중단을 다룬 글에 정리했습니다.

5편, 남이 쓴 명세를 구현하는 데서 끝나지 않는 일

5편의 첫 문장은 AI 엔지니어링에 능숙한 사람의 가장 좋은 작업이 남이 명세를 써 준 제품을 구현하는 데 그치지 않고, 무엇을 만들지 적극적으로 빚는 일이 된다는 것입니다. 현대 AI 도구가 개발자 한 사람이 할 수 있는 일을 넓히기 전까지 기술 기업은 PM(프로덕트 매니저)과 디자이너가 무엇을 만들지 정하면 개발자가 만드는 분업을 굳혀 왔습니다. 응은 이 역할들이 흐려지고 있다며, AI 엔지니어링 역량을 갖춘 개발자는 다른 역할에도 참여하고 PM과 디자이너도 AI 엔지니어링 역량을 익혀 소프트웨어를 직접 만든다고 적었습니다.

응이 말한 PM은 국내 IT 기업에서 서비스 기획자가 맡아 온 역할과 많이 겹칩니다. 응은 무엇을 만들지 정할 줄 아는 개발자는 PM이 할 일을 정해 주기를 기다리지 않고 더 빨리 움직일 수 있다며, 이 변화가 소프트웨어 개발을 크게 앞당기고 있다고 봤습니다.

개발자가 PM이 될 필요는 없습니다. 다만 제품 명세가 다루지 않는 결정은 내리게 됩니다.— 앤드루 응, DeepLearning.AI 창업자

응은 제품 판단이 사용자에 대한 공감에서 나온다고 적었습니다. 그 공감을 기르는 방법으로는 사용자 두세 명과의 짧은 인터뷰부터 수백 명 설문, 대규모 A/B 테스트, 수천에서 수백만 명의 행동 분석까지를 들었습니다.

높은 주도성을 꼽은 이유도 적었습니다. 일부 경영진을 포함해 많은 사람이 아직 AI가 무엇을 할 수 있는지 몰라 좋은 프로젝트 방향을 알지 못하고, 기술을 아는 사람이 그 간극을 메울 기회가 생겼다는 겁니다. 응은 조직의 우선순위와 제약을 존중하면서도 위에서 정확한 지시가 내려오기를 기다리지 않고 문제를 찾아 해법을 내고 실행하는 사람을 그렸습니다.

PM 1명에 엔지니어 0.5명

5편과 같은 문제를 응은 1년여 전 강연에서 숫자로 말했습니다. 2025년 6월 와이 컴비네이터 강연에서 그는 실리콘밸리에 PM 1명당 엔지니어 4~7명이라는 경험칙이 있었는데, 한 팀이 처음으로 PM 1명에 엔지니어 0.5명, 곧 PM을 엔지니어의 두 배로 두는 인력 계획을 가져왔다고 말했습니다. 엔지니어는 빨라졌는데 사용자 의견을 듣고 무엇을 만들지 정하는 제품 관리 일은 그만큼 빨라지지 않아 병목이 됐다는 설명이었습니다.

YouTube 영상 · 누르면 재생

응은 그 제안이 좋은 생각인지는 아직 모르겠다면서도, 코딩할 줄 아는 PM이나 제품 감각이 있는 엔지니어가 대체로 더 잘한다고 덧붙였습니다. 같은 강연에서 제품 피드백을 얻는 방법을 빠른 순서로 늘어놓았는데, 그 분야를 잘 아는 사람이라면 직접 써 보고 감으로 판단하는 것이 가장 빠르고, 동료 세 명, 낯선 사람 3~10명, 테스터 100명 순으로 느려지며, A/B 테스트는 이제 가장 느린 방법 가운데 하나라고 했습니다.

2026년 1월 다보스 대담에서는 비율 이야기가 한 걸음 더 나갔습니다. 보통 PM 1명에 엔지니어 4~8명이던 팀을 1대 2로, 다시 1대 1로 줄였고, 그보다 빠른 방법은 두 사람을 한 사람으로 합치는 것이었다는 겁니다. 응은 요즘 가장 빨리 움직이는 팀 가운데에는 사용자 의견을 모을 공감 능력까지 갖춘 강한 엔지니어 한 명으로 된 팀도 있다고 했고, 세상에는 PM보다 엔지니어가 훨씬 많아 제품을 배우는 엔지니어가 코딩을 배우는 PM보다 많다고 봤습니다.

에이전트가 대신 겪은 시행착오

저는 3편을 읽으며 배움의 경로가 가장 마음에 걸렸습니다. 예전에는 나쁜 데이터 모델이나 잘못된 아키텍처를 고르면 구현하는 동안 그 대가를 직접 치렀고, 쿼리가 느려져 인덱스를 다시 짜고 사용자가 늘어 구조를 뜯어고치는 고생이 기본기를 가르쳤습니다. 지금은 에이전트가 그 과정을 대신 지나가고, 개발자는 그럴듯하게 도는 소프트웨어를 받지만 그 안에 묻힌 결정은 한 번도 보지 못합니다.

응 자신도 비슷한 경험을 털어놓은 적이 있습니다. 유튜브 채널 실리콘밸리 걸과의 인터뷰에서 그는 AI로 프런트엔드와 백엔드 컴포넌트를 빠르게 구현해도 6개월 뒤에는 그 내용을 전혀 기억하지 못해 다시 AI에 기대게 된다고 말했습니다. 그 인터뷰는 응의 인터뷰를 정리한 글에서 다뤘습니다.

다보스에서 응이 가장 생산성이 낮은 부류로 꼽은 것은 AI를 모르는 신입이었고, AI 도구를 아는 신입은 두 번째 부류였습니다. 신입이 AI 도구를 쓰는 속도로 앞서 나가면서도 기본기를 쌓으려면, 에이전트가 대신 지나간 결정을 따로 들여다보는 연습이 붙어야 한다는 것이 제 생각입니다. 제가 스레드에서 제안한 방법은 3편의 다섯 축을 에이전트에게 되묻는 질문으로 바꾸는 것이었습니다.

판단을 기르는 방법은 지도에 없다

다섯 편을 이어 보면 항목의 성격이 뒤로 갈수록 달라집니다. 2편과 3편의 항목은 트레이스와 캐싱, 샤딩처럼 가르칠 수 있는 기술의 이름이고, 5편의 항목은 제품 감각과 주도성, 책임처럼 사람마다 상황마다 새로 내리는 판단의 이름입니다. 응은 무엇이 중요한지는 자세히 적었지만, 판단 쪽 역량을 무엇으로 재고 어떻게 기르는지는 끝까지 적지 않았습니다.

표본의 문제도 풀리지 않았습니다. 1편에서 밝힌 채용 공고 1만 건 이상의 국가와 기간, 회사 구성, 인터뷰 대상자 수는 다섯 편이 끝날 때까지 공개되지 않았습니다. 채용 공고는 회사가 원한다고 적은 문서라서, 이 목록이 지금의 업무를 반영하는지 앞으로의 요구를 예고하는지도 이 자료만으로는 가리기 어렵습니다.

응은 1편 추신에서 AI가 바뀌는 대로 지도를 계속 고쳐 나가겠다고 했습니다. 5편의 마지막 단락에는 이런 문장이 있습니다.

여러분은 더 큰 힘을 갖고, 더 넓은 범위를 맡고, 더 많은 결정을 내립니다. 다만 이 모든 일을 잘하려면 더 많은 기술이 필요합니다.— 앤드루 응, DeepLearning.AI 창업자

읽어 주셔서 고맙습니다.

초이 드림