부제: 그렉 브록먼이 조용히 던진 숫자 하나가, '개발자'라는 직업의 경계를 다시 그리고 있다
요즘 소프트웨어 업계에는 잘 알려지지 않은 규칙이 하나 있다.
진짜 개발자는 코드를 직접 쓴다는 것. 그리고 그 코드를 직접 쓸 줄 모르는 사람은 개발자가 아니라는 것. 수십 년 동안 이 규칙은 흔들리지 않았다. 깃허브에 커밋 기록이 없으면 기술직으로 인정받지 못했고, 알고리즘 문제를 손으로 풀지 못하면 FAANG 면접을 통과할 수 없었으며, 스택오버플로우에서 답을 찾지 못하는 사람은 그냥 '비개발자'였다.
그런데 오픈AI의 공동창업자 그렉 브록먼이 최근 조용히 숫자 하나를 꺼냈다.
에이전트 코딩의 비중이 개발 프로세스에서 80%에 달한다는 것.
먼저, 에이전트 코딩이 뭐길래
에이전트 코딩이라는 단어는 얼핏 들으면 그냥 '코드 자동완성' 정도로 들린다. 깃허브 코파일럿이 문장을 예측해서 완성해주는 것, 또는 챗GPT에게 "파이썬으로 엑셀 정렬하는 코드 짜줘"라고 시키는 것. 이미 수백만 명이 하고 있는 그것 말이다.
그런데 에이전트 코딩은 다르다.
자동완성은 개발자가 방향을 잡고, AI가 타이핑을 도와주는 형태다. 운전자가 핸들을 잡고 있고, AI는 가속 페달을 조금씩 밟아주는 보조 시스템이다. 반면 에이전트 코딩에서 AI는 스스로 목표를 이해하고, 계획을 세우고, 코드를 작성하고, 테스트하고, 오류를 수정하고, 다시 실행하는 전 과정을 자율적으로 반복한다. 사람이 시동을 걸어놓으면 AI가 알아서 목적지까지 간다.
비유하자면, 기존 AI 코딩 도구가 '똑똑한 자동완성 타자기'였다면, 에이전트 코딩은 '브리핑만 받고 보고서를 써오는 주니어 개발자'다.
이 차이는 생각보다 크다. 단순히 속도가 빨라지는 게 아니라, 사람이 개입해야 하는 순간 자체가 줄어든다. 요구사항을 말로 설명하면 에이전트가 코드 전체를 만들어내고, 사람은 결과물을 검토하고 방향을 교정하는 역할만 한다. 이 구조에서는 코드를 손으로 쓸 줄 아는 능력보다 무엇을 만들어야 하는지를 명확하게 설명하는 능력이 더 중요해진다.
그리고 브록먼이 말한 80%는, 바로 그 에이전트가 담당하는 비중이다.
80%라는 숫자가 불편한 이유
숫자는 때로 아무것도 설명하지 않고 모든 것을 설명한다.
80%는 단순한 생산성 지표가 아니다. 이 숫자는 지금까지 개발 프로세스에서 '사람의 몫'이라고 여겨졌던 것 중 5분의 4가, 이미 기계에 넘어갔다는 선언이다. 수십 년 동안 프로그래머들이 쌓아온 전문성의 영역 — 변수를 어떻게 명명할지, 함수를 어떻게 분리할지, 예외 처리를 어느 지점에 넣을지 — 그 모든 판단이 이미 에이전트의 영역으로 들어갔다는 뜻이다.
물론 반론은 있다. 아직 복잡한 아키텍처 설계나 도메인 특화된 엣지 케이스는 사람이 처리해야 한다는 것. 에이전트가 만든 코드를 검토하는 '시니어 개발자'의 역할은 오히려 더 중요해진다는 것. 이 반론은 틀리지 않는다.
그런데 흥미로운 점은 브록먼이 이 숫자를 꺼낸 맥락이다. 그는 이것을 개발자를 위한 뉴스로 발표하지 않았다. 비개발자에게까지 이 기술이 확산되고 있다는 방향으로 이야기했다. 즉, 80%라는 숫자는 "개발자가 더 효율적으로 일한다"는 이야기가 아니라 "이제 개발자가 아니어도 된다"는 방향을 향하고 있다는 것이다.
이것이 이 숫자가 불편한 진짜 이유다.
거인들의 전쟁, 그리고 조용한 경계의 붕괴
마이크로소프트는 깃허브 코파일럿에 수십억 달러를 쏟아부었다. 구글은 젬마이니를 개발 도구 전체에 통합하며 코딩 에이전트 생태계를 구축하고 있다. 아마존은 AWS에 코드위스퍼러를 깊숙이 심었다. 거인들이 코딩 자동화 시장에서 싸움을 벌이는 동안, 실리콘밸리의 스타트업들은 또 다른 방향을 바라보기 시작했다.
개발자가 더 빠르게 코딩하도록 돕는 것이 아니라, 코딩을 전혀 모르는 사람이 소프트웨어를 만들 수 있도록 하는 것.
이 방향의 차이는 미묘해 보이지만, 실제로는 완전히 다른 시장을 겨냥한다. 전자는 전 세계 수천만 명의 개발자가 고객이다. 후자의 잠재 고객은 코딩을 배운 적도 없고 배울 생각도 없는 수십억 명이다.
브록먼이 말한 "비개발자까지 확산"이라는 표현은 이 시장을 정면으로 가리킨다. 에이전트 코딩은 지금 두 개의 전선에서 동시에 진격하고 있다. 한쪽은 개발자를 더 강하게 만드는 방향이고, 다른 한쪽은 개발자라는 역할 자체를 재정의하는 방향이다. 그리고 그 두 번째 전선이 조용히, 그러나 빠르게 앞으로 나가고 있다.
역사적으로 이런 일이 처음은 아니다. 데스크톱 출판 소프트웨어가 나왔을 때 전문 식자공이라는 직업이 사라졌다. 포토샵이 나왔을 때 전통 암실 사진 보정 기술자들이 시장에서 밀려났다. 엑셀이 나왔을 때 수작업 계산원이라는 직군이 없어졌다. 그리고 지금 에이전트 코딩이 나왔다.
진짜 흥미로운 이야기는, '개발자'라는 단어 이전에 있었다
'개발자'라는 직업이 특별한 기술을 요구하는 전문직으로 자리 잡기 시작한 것은 생각보다 최근의 일이다.
1990년대 초반까지만 해도 소프트웨어를 만든다는 것은 극소수 공학자들의 영역이었다. 1995년 자바가 나오면서 플랫폼 독립적인 프로그래밍이 가능해졌고, 2000년대 오픈소스 운동이 폭발하면서 개발자 인구가 급격히 늘었다. 그리고 스마트폰이 등장하면서 앱 개발자라는 새로운 직군이 생겨났고, 이제 전 세계 소프트웨어 개발자 수는 수천만 명에 달한다.
이 직군이 성장한 방식은 항상 같았다. 기술이 복잡해질수록 그것을 다룰 수 있는 전문가의 수요가 늘었고, 그 전문성에 대한 프리미엄이 형성됐다. 실리콘밸리의 소프트웨어 엔지니어 연봉이 의사나 변호사를 넘어선 것도 그 구조 덕분이었다. 희소하고 어려운 기술을 보유한 사람들에 대한 시장의 보상이었다.
그런데 에이전트 코딩은 그 구조의 전제를 건드린다. 기술이 복잡하지 않아도 된다면, 다시 말해 그 복잡성을 에이전트가 대신 처리해준다면, 전문성에 대한 프리미엄의 근거가 흔들린다. 물론 완전히 사라지지는 않는다. 하지만 '코드를 쓸 수 있다'는 능력의 희소가치는 분명히 낮아진다. 그리고 그 자리를 무엇이 채울 것인가라는 질문이 지금 업계 전반에 걸려 있다.
그런데 이 방식은, 아직 완성되지 않았다
솔직하게 말해야 할 지점이 있다.
에이전트 코딩이 80%를 담당한다는 것이 곧 비개발자가 당장 복잡한 소프트웨어를 혼자 만들 수 있다는 뜻은 아니다. 브록먼이 말한 80%는 특정 프로젝트, 특정 조건, 특정 에이전트 환경에서의 수치다. 단순하고 반복적인 작업 비중이 높은 프로젝트에서 에이전트가 처리하는 코드의 비율이 그만큼 높아졌다는 것이지, 모든 개발 프로세스에서 동일하게 적용된다는 뜻은 아니다.
에이전트가 아직 잘 못하는 것들이 있다. 사용자가 원하는 게 무엇인지 불명확할 때 올바른 가정을 선택하는 것. 기존 레거시 코드베이스와 새 코드를 충돌 없이 통합하는 것. 보안 취약점을 구조적으로 예방하는 것. 이 영역들은 여전히 숙련된 인간 개발자가 필요하다.
하지만 이 한계를 말한다고 해서 80%라는 숫자의 무게가 줄어드는 것은 아니다. 완성되지 않았다는 것은, 아직 멈춰 있다는 뜻이 아니라 진행 중이라는 뜻이기 때문이다. 에이전트가 80%를 처리한다면 내년에는 85%일 수 있고, 그 다음 해에는 그 비율이 더 높아질 수도 있다. 기술은 직선으로 발전하지 않지만, 이 방향 자체가 바뀔 가능성은 크지 않다.
비개발자의 자리는 어디인가
그렇다면 코드를 모르는 사람들에게 에이전트 코딩의 확산은 어떤 의미인가.
당장 내일부터 누구나 앱을 만들 수 있게 된다는 뜻은 아니다. 에이전트에게 좋은 지시를 내리는 것 자체가 하나의 기술이기 때문이다. '파이썬으로 뭔가 만들어줘'와 '사용자가 CSV 파일을 업로드하면 컬럼별로 평균과 중앙값을 계산하고 그래프로 시각화해주는 웹 앱을 만들어줘'는 같은 요청이 아니다. 에이전트가 후자를 더 잘 처리하는 것은 명확하고, 그 차이를 만드는 것은 코딩 실력이 아니라 사고를 구체화하는 능력, 즉 문제를 정밀하게 정의하는 능력이다.
이것은 전통적으로 기획자, 비즈니스 애널리스트, 콘텐츠 전략가들이 잘한다고 알려진 능력이다. 도메인을 깊이 이해하고, 사용자의 불편함을 정확하게 언어로 옮기고, 그것을 실행 가능한 단위로 쪼개는 것. 에이전트 코딩의 세계에서는 이 능력을 가진 사람이 강력한 소프트웨어 빌더가 된다.
비개발자에게까지 확산된다는 브록먼의 발언이 단순한 마케팅 문구가 아닌 이유가 여기 있다. 에이전트는 코드를 대신 쓰지만, '무엇을 왜 만들어야 하는가'를 설명하는 사람은 여전히 사람이어야 한다. 그리고 그 설명을 잘 할 수 있는 사람은, 반드시 개발자일 필요가 없다.
'개발자'라는 직업의 미래는, 코더에서 큐레이터로
지금 개발자 커뮤니티 안에서는 두 종류의 반응이 공존한다.
하나는 불안이다. 에이전트가 80%를 한다면, 나는 무엇을 해야 하는가. 주니어 개발자 포지션은 사라지는 것인가. 이 불안은 현실적이고, 억지로 안심시킬 필요도 없다. 실제로 일부 기업에서는 에이전트 도입 이후 주니어 개발자 채용을 줄이고 있다는 이야기가 들린다.
다른 하나는 재정의다. 코드를 생산하는 사람에서 코드를 검토하고 방향을 잡는 사람으로, 개발자의 역할이 변하는 것이지 사라지는 것이 아니라는 시각. 에이전트가 코드를 짜주면 개발자는 더 복잡한 문제에 집중할 수 있게 되고, 그것이 오히려 기회라는 것.
역사를 보면 후자가 일반적으로 더 정확했다. 엑셀이 계산원을 없앤 것이 아니라 더 복잡한 분석을 하는 애널리스트로 역할을 변화시켰듯, 에이전트 코딩은 '코더'라는 역할을 없애는 것이 아니라 '큐레이터'로 진화시키는 방향으로 가고 있다. 코드를 쓰는 사람에서, 에이전트가 쓴 코드를 평가하고 조율하고 방향을 잡는 사람으로.
그런데 이 진화가 편안하지만은 않은 이유는, 큐레이터가 되는 데 필요한 능력이 코더가 되는 데 필요한 능력과 상당히 다르기 때문이다. 코더는 정확한 문법과 알고리즘 지식이 필요하다. 큐레이터는 판단력, 비즈니스 맥락 이해, 그리고 에이전트가 놓친 것을 알아채는 메타인지가 필요하다. 이 전환은 자연스럽게 일어나지 않는다. 의도적인 재훈련이 필요하다.
이 숫자가 만들어낼 풍경
80%라는 숫자가 처음 공개됐을 때 업계 반응은 생각보다 조용했다.
숫자가 너무 커서 실감이 안 됐을 수도 있고, 이미 비슷한 이야기가 워낙 많이 나와서 감각이 무뎌졌을 수도 있다. 하지만 이 숫자가 조용히 굴러다니다가 어느 날 갑자기 큰 소리를 낼 것이라는 예감은, 이 업계를 조금이라도 아는 사람이라면 느낄 수 있다.
채용 공고에서 특정 언어 능숙도 요구가 사라지는 날. 신입 면접에서 알고리즘 코딩 테스트 대신 에이전트 지시문을 작성하게 하는 날. 비개발자가 만든 소프트웨어가 스타트업의 초기 제품으로 시장에 나오는 날. 이 날들이 어느 날 갑자기 오는 것처럼 느껴지겠지만, 사실 그날들은 이미 80%라는 숫자가 발표된 순간부터 시작된 변화의 끝에 있다.
코드를 한 줄도 모르는 사람이 코딩의 80%를 에이전트에 넘기고, 나머지 20%를 자신의 판단과 방향으로 채우는 세계. 그것이 브록먼이 조용히 선언한 미래의 모습이다.
코드를 한 줄도 모르는 사람이 코딩의 80%를 차지하게 된 날치고는, 꽤 조용하게 시작된 혁명이다.
📌 이 글은 AI와 함께 작성되었습니다.