브록먼이 말한 '80%'의 진짜 의미는, 코딩의 자동화가 아니라 판단의 이동이다
TL;DR: 오픈AI 공동창업자 그렉 브록먼의 최근 보고서에 따르면, 개발 프로세스에서 에이전트 코딩의 비중이 이미 80%에 달했다. 그런데 이 숫자가 충격적인 이유는 '자동화' 때문이 아니다. 코드를 작성하는 행위가 아니라, 무엇을 만들지를 결정하는 권한이 개발자 바깥으로 넘어가기 시작했기 때문이다. 2026년, 코딩의 80%가 에이전트 손에 넘어간 시대에, 나머지 20%에 무엇이 남아 있는지가 진짜 질문이다.
요즘 소프트웨어 업계에는 잘 알려지지 않은 규칙이 하나 있다.
"코드를 빨리 짜는 사람이 이기는 게 아니라, 코드를 짜지 않아도 되는 구조를 먼저 만드는 사람이 이긴다."
구글은 내부 개발자 생산성 보고서에서 AI 보조 코딩 도구의 도입 이후 단순 반복 작업의 처리 속도가 극적으로 향상됐다고 밝혔다. 마이크로소프트는 깃허브 코파일럿을 통해 개발자가 하루에 작성하는 코드 줄 수가 눈에 띄게 늘었다고 발표했다. 두 거인 모두 같은 방향을 가리키고 있다. 더 많이, 더 빠르게.
그런데 오픈AI 공동창업자 그렉 브록먼은 조용히 다른 숫자를 꺼냈다. 개발 프로세스에서 에이전트 코딩의 비중이 80%에 달한다는 것. 그리고 이 기술이 이제 비개발자에게까지 확산되고 있다는 것.
이 두 문장을 나란히 놓으면, 갑자기 질문이 바뀐다. 코드를 어떻게 빨리 짜느냐가 아니라, 코드를 짜는 사람이 누구여야 하느냐로.
먼저, '에이전트 코딩'이 뭐길래
에이전트 코딩은, 단순히 AI가 코드를 제안하는 것과 다르다.
자동완성 기능을 생각해보자. 스마트폰 키보드가 다음 단어를 예측해주는 것처럼, 기존의 AI 코딩 보조 도구는 개발자가 타이핑하는 흐름 위에 올라타 다음 줄을 채워준다. 인간이 방향을 정하고, AI가 속도를 높여주는 구조다. 주도권은 여전히 개발자에게 있다.
에이전트 코딩은 다르다. 목표를 입력하면, 에이전트가 스스로 계획을 세우고, 필요한 코드를 생성하고, 테스트를 돌리고, 오류를 수정하고, 결과물을 내놓는다. 사람은 처음에 "이런 기능을 만들어줘"라고 말하고, 나중에 결과물을 받는다. 그 중간 과정의 80%를 에이전트가 채운다는 것이 브록먼이 말한 숫자의 핵심이다.
비유하자면, 기존 AI 코딩 보조는 "조수석에 앉아서 지도를 읽어주는 동반자"고, 에이전트 코딩은 "목적지만 말하면 알아서 운전해주는 기사"다.
이 전환이 중요한 이유는 속도 때문이 아니다. 운전대를 누가 쥐느냐가 바뀌기 때문이다. 그리고 운전대를 쥔 사람이 바뀌면, 도로의 규칙도 바뀐다.
80%라는 숫자가 진짜로 무섭게 느껴지는 순간
숫자를 다시 보자. 80%.
개발 프로세스에서 에이전트가 차지하는 비중이 80%라면, 개발자가 직접 관여하는 영역은 20%다. 그 20%가 어디냐를 생각해보면 이야기가 달라진다.
코드 생성, 테스트, 오류 수정, 반복 작업의 최적화 — 이것들은 이미 에이전트 쪽으로 넘어갔다. 그러면 개발자에게 남은 20%는 무엇인가. 요구사항을 정의하는 것, 아키텍처를 설계하는 것, 비즈니스 문맥을 코드에 연결하는 것, 그리고 에이전트가 만들어낸 결과물이 실제로 옳은지를 판단하는 것.
이것은 기술의 문제가 아니다. 판단의 문제다.
과거에 개발자는 '어떻게 만드는지'를 알고 있었기 때문에 가치가 있었다. 이제 에이전트가 '어떻게 만드는지'를 처리한다면, 개발자의 가치는 '무엇을 만들어야 하는지'와 '그것이 왜 필요한지'를 아는 데서 나온다. 기술적 능숙함의 시대에서 맥락적 판단력의 시대로 이동한다는 뜻이다.
그리고 여기서 브록먼이 던진 두 번째 폭탄이 터진다. 이 기술이 비개발자에게도 확산되고 있다는 말.
비개발자가 에이전트를 쓴다는 것의 진짜 의미
비개발자가 코딩을 한다는 이야기는 새롭지 않다.
노코드, 로우코드 플랫폼들은 수년 전부터 "개발자 없이도 앱을 만들 수 있다"고 외쳤다. 그러나 실제로 그 도구들이 만들어낸 것은, 복잡한 논리나 정교한 기능이 아니라 단순한 폼이나 간단한 자동화 흐름이었다. 진입장벽을 낮췄지만, 만들 수 있는 것의 수준도 함께 낮아졌다.
에이전트 코딩은 이 공식을 깨뜨린다.
비개발자가 에이전트에게 "우리 팀이 매일 수작업으로 하는 데이터 정리 작업을 자동화해줘"라고 말하면, 에이전트는 실제로 작동하는 파이썬 스크립트를 만들어낸다. 단순한 버튼 클릭이 아니라, 실제 코드가 나온다. 그 코드가 돌아간다. 이전에는 개발자를 고용하거나 외주를 줘야 했던 작업이, 이제 도메인 지식을 가진 현업 담당자 손에서 직접 완성된다.
이것이 확산된다는 것은, 소프트웨어를 만드는 행위가 개발자라는 직군에서 지식 노동자 전반으로 분산된다는 뜻이다.
마케터가 자신의 캠페인 성과 분석 도구를 직접 만들고, 재무팀이 자체 리포팅 자동화를 구현하고, 운영팀이 재고 관리 스크립트를 완성한다. 그 각각의 영역에서 도메인 전문가가 에이전트를 통해 코드를 결과물로 출력하는 구조가 자리를 잡으면, 소프트웨어 개발의 병목은 '코드를 쓸 수 있는 사람의 수'가 아니라 '무엇을 만들어야 하는지를 아는 사람의 수'로 이동한다.
그런데, 한 번의 솔직한 의문
이 모든 이야기를 여기까지 읽고 나면, 자연스럽게 하나의 의문이 생긴다.
그렇다면 개발자는 이제 사라지는가.
그건 아니다. 그리고 이 부분은 솔직하게 이야기해야 한다.
에이전트가 80%를 처리한다는 말은, 에이전트가 80%를 옳게 처리한다는 말이 아니다. 에이전트가 만들어낸 코드는 여전히 틀릴 수 있다. 보안 취약점을 만들어낼 수 있고, 엣지 케이스를 처리하지 못할 수 있고, 기존 시스템과 충돌을 일으킬 수 있다. 비개발자가 에이전트를 통해 코드를 만들어냈을 때, 그 코드가 실제로 안전하고 효율적이며 유지보수 가능한지를 검증하는 능력은 여전히 기술적 숙련도를 요구한다.
즉, 에이전트 코딩의 확산은 개발자의 소멸을 의미하지 않는다. 개발자의 역할이 '코드 생산자'에서 '에이전트 감독자이자 시스템 설계자'로 재편된다는 뜻이다.
이것은 특정 직군이 사라지는 이야기가 아니라, 그 직군이 무엇을 해야 하는지가 바뀌는 이야기다.
거인들의 게임, 그리고 다른 질문을 던지는 사람들
구글, 마이크로소프트, 아마존 — 이 거인들이 에이전트 코딩 도구에 쏟아붓는 자원의 규모는 가늠하기 어렵다. 깃허브 코파일럿, 아마존 Q 개발자, 구글의 제미나이 코드 어시스트. 이름도 기능도 조금씩 다르지만 방향은 같다. 더 많은 코드를, 더 빠르게.
그런데 브록먼이 던진 숫자 앞에서 흥미로운 질문이 하나 생긴다. 에이전트가 코드의 80%를 만든다면, 그 에이전트를 어떻게 더 잘 만들 것인가. 에이전트의 에이전트, 즉 AI를 설계하고 검증하고 개선하는 더 상위 레이어의 문제가 남는다.
거인들은 이미 이 레이어에서도 경쟁하고 있다. 더 정밀하게 지시를 이해하는 모델, 더 넓은 문맥을 유지하는 모델, 더 안정적으로 오류를 자기 수정하는 모델. 수조 원짜리 인프라 위에서 벌어지는 게임이다.
그 게임 바깥에서, 다른 질문을 던지는 팀들이 있다. 더 크고 더 빠른 에이전트를 만드는 것이 아니라, 에이전트가 만들어낸 결과물을 어떻게 신뢰할 수 있는지, 에이전트의 판단이 어떤 근거로 내려지는지를 파고드는 팀들. 코드 생성의 속도 경쟁에서 한 발 비껴서, 에이전트의 판단 품질이라는 더 근본적인 문제를 바라보는 시각이다.
판단을 설계하는 일이 남아 있다
에이전트가 코드를 만든다. 그런데 에이전트는 어떤 코드를 만들어야 할지 어떻게 결정하는가.
이 질문은 생각보다 깊다.
에이전트에게 "사용자 데이터를 분석하는 기능을 만들어줘"라고 말하면, 에이전트는 기술적으로 작동하는 코드를 출력할 수 있다. 그러나 그 데이터를 어떤 방식으로 다룰지, 개인정보를 어느 수준까지 보호할지, 결과를 어떤 형식으로 보여줄지, 이 기능이 조직의 어떤 가치와 연결되어야 하는지 — 이것들은 에이전트가 스스로 결정하지 않는다. 아직은.
이것이 브록먼의 80%가 암시하는 가장 불편한 진실이다. 80%가 에이전트로 넘어갔다면, 나머지 20%는 단순히 '적은 비중'이 아니라 '모든 방향을 결정하는 비중'이다. 에이전트가 어디를 향해 달려갈지를, 그 20%가 정한다.
판단을 설계하는 일. 요구사항을 정의하는 일. 에이전트가 만들어낸 결과물이 옳은지를 묻는 일. 이것들은 코딩보다 오래된 능력이다. 글을 쓰고, 논리를 구성하고, 맥락을 이해하고, 결과를 평가하는 능력. 이 능력을 가진 사람이, 에이전트를 쥔다.
그리고 흥미롭게도, 이 능력은 반드시 개발자만 가지고 있지 않다.
비드래프트가 이 숫자를 보는 방식
비드래프트는 AI 모델을 연구하는 팀으로서, 이 숫자를 조금 다르게 읽는다.
에이전트 코딩의 확산에서 가장 중요한 것은 속도가 아니라 정렬(alignment)이다. 에이전트가 더 많은 코드를 만들수록, 그 에이전트가 어떤 가치 판단을 내재하고 있는지가 더 중요해진다. 빠른 코드보다 옳은 코드. 많은 코드보다 설명 가능한 코드.
다윈 모델 패밀리를 통해 추론 품질과 신뢰성을 연구하는 것, GPQA Diamond 벤치마크에서 글로벌 3위권을 유지하는 것 — 이것들은 에이전트 코딩의 시대에 오히려 더 근본적인 질문을 가리킨다. 에이전트가 만들어낸 결과물이 실제로 옳은지를 판별하는 능력, 그 상위 레이어의 신뢰성.
코드를 더 많이 생성하는 경쟁과, 생성된 코드를 더 잘 검증하는 능력은 서로 다른 문제다. 전자는 규모의 싸움이고, 후자는 정밀도의 싸움이다.
80%가 넘어간 뒤, 20%에서 무슨 일이 생기는가
결국 이 이야기는 여기로 돌아온다.
브록먼이 말한 80%는 도착점이 아니다. 시작점이다. 에이전트가 코드의 80%를 처리하게 된 시점부터, 남은 20%를 두고 벌어지는 경쟁이 실질적으로 시작된다. 그 20%가 무엇인지를 먼저 정의한 팀이, 다음 라운드를 설계한다.
구글과 마이크로소프트는 에이전트를 더 크게 만드는 데 수조 원을 쓴다. 그 경쟁의 한편에서, 에이전트가 만들어낸 것을 어떻게 신뢰하고 어떻게 방향을 잡을 것인지를 연구하는 팀들이 조용히 다른 질문을 가다듬고 있다.
에이전트 코딩의 비중이 80%에 달하는 세계에서, 나머지 20%는 단순히 인간이 처리하는 잔여 작업이 아니다. 그것은 에이전트가 아직 처리할 수 없는 것이 아니라, 에이전트에게 맡겨서는 안 되는 것이다.
그 경계를 어디에 그을 것인가. 그것이 지금 진짜 질문이다.
에이전트가 코드의 80%를 만드는 시대에, 나머지 20%를 누가 어떻게 채우는지가 — 꽤 흥미로운 이야기가 될 것이다.
더 많은 AI 인사이트는 비드래프트에서 확인하세요.
Q. 에이전트 코딩이 80%라면, 개발자 직군은 실제로 위협받는 건가요?
A. 위협보다는 재편에 가깝습니다. 코드를 직접 작성하는 역할은 줄어들지만, 에이전트가 만들어낸 결과물을 검증하고, 요구사항을 정의하고, 시스템 전체 구조를 설계하는 역할은 오히려 더 중요해집니다. 코드 생산자에서 시스템 판단자로의 이동이라고 볼 수 있습니다.
Q. 비개발자가 에이전트 코딩으로 만든 코드는 실제로 안전한가요?
A. 아직 불확실합니다. 에이전트가 기능적으로 작동하는 코드를 생성하더라도, 보안 취약점이나 유지보수 문제, 엣지 케이스 처리 등은 여전히 기술적 검증이 필요합니다. 비개발자의 에이전트 활용 확산은 동시에 검증 체계의 필요성도 함께 키웁니다.
Q. 브록먼이 말한 '80%'는 어떤 범위의 수치인가요?
A. 브록먼의 최근 보고서에서 제시된 수치로, 개발 프로세스 전반에서 에이전트 코딩이 차지하는 비중을 의미합니다. 다만 이 수치는 특정 환경이나 조직 기준일 수 있으며, 모든 개발 현장에 일률적으로 적용되는 수치는 아닙니다.
Q. 에이전트 코딩의 확산이 AI 모델 자체의 품질에 어떤 영향을 미치나요?
A. 에이전트가 더 많은 코드를 생성할수록, 그 에이전트의 추론 품질과 신뢰성이 결과물 전체의 품질을 좌우하게 됩니다. 코드 생성 속도보다 판단의 정확성과 설명 가능성이 더 중요한 경쟁 요소로 부상하는 이유입니다.