에이전트 기반 개발은 개인 엔지니어의 생산성을 크게 높이지만, 기존 조직 구조를 그대로 두면 회사 전체 생산성은 대체로 50% 향상을 넘기 어렵다. 이를 돌파하려면 제품·엔지니어링의 관계, 팀 구성, 의사결정 권한, 관리 구조, 그리고 비개발 부서의 업무 방식까지 함께 바꿔야 한다. 핵심은 더 빠른 도구를 도입하는 데서 멈추지 않고, 그 속도에 맞는 조직 운영 모델로 전환하는 것이다.
1. 개인의 속도와 조직의 속도 사이의 50% 장벽
앞선 내용에서 다룬 인프라 구축과 인력 전환은 개별 엔지니어를 압도적으로 빠르게 만든다. 그러나 이것만으로 조직 전체가 같은 속도로 움직이지는 않는다. 이 글의 핵심 문제는 바로 개인 단위의 빠른 실행 속도와 조직 전체의 실제 산출 속도 사이의 격차다.
연구에서 가장 앞서 있던 한 기업은 1년 이상 에이전트 중심으로 개발했고, 실제 운영 코드의 85~90%를 에이전트가 생성하고 있었다. 기반 인프라도 강력했다. 하지만 코드 생성이 거의 10배 빨라졌음에도, 아이디어가 실제 배포 가치로 이어지는 전 과정의 생산성은 50%를 넘지 못했다. 보통은 25~30% 수준에 머물렀다.
"코드 생성 속도는 거의 10배 빨라졌습니다. 하지만 의도에서 배포된 가치까지 이어지는 실제 종단 간 생산성 향상은 50%를 넘지 못했습니다. 대부분은 25~30%에 가까웠죠."
— 후기 단계 기업의 엔지니어링 책임자
글은 이를 "신호등마다 멈추는 페라리"에 비유한다. 낡은 세단을 스포츠카로 바꾸면 차 자체의 성능은 분명 좋아진다. 하지만 200m마다 빨간불이 있는 도로를 달리면, 실제 도착 시간은 아주 조금만 단축된다. AI가 개발자를 빠르게 해도 제품 검토, PM 인수인계, 코드 리뷰 대기열, 월 단위 계획, 사람 중심 상태 보고, 오래된 소유권 경계가 그대로라면 조직은 그 속도를 활용하지 못한다.
외부 데이터도 같은 흐름을 보여준다. 400개 이상 기업을 조사한 DX 데이터에서 AI 도입이 65% 늘어나는 동안, 풀 리퀘스트 처리량의 중앙값 증가는 7.76%에 불과했다. 즉, 현장에서 얻은 많은 가속이 조직의 병목에서 소모되고 있었다.
여기서 중요한 것은 모든 안전장치를 없애자는 뜻이 아니다. 품질과 보안을 지키는 통제는 필요하다. 다만 과거의 느린 개발 속도에 맞추어 만들어진 절차 가운데 불필요한 정차 지점은 제거하고, 자동화할 수 있는 통제는 기계 속도로 작동하도록 재설계해야 한다. 🚦
"차들은 더 빨라졌다. 이제 도로를 다시 설계해야 한다."
2. 허가를 기다리도록 훈련된 사람들
조직이 승인 절차를 없앤다고 해서 구성원이 곧바로 빠르게 움직이는 것은 아니다. 글은 AI 방식으로 일하라는 명확한 권한을 받은 한 엔지니어의 사례를 든다. 기존의 승인 관문도 제거됐지만, 그는 아키텍처·범위·제품 우선순위처럼 의미 있는 결정을 마주할 때마다 여전히 누군가의 허락을 받으러 갔다.
"신호등은 꺼졌는데, 그는 여전히 교차로마다 멈췄다."
전통적인 제품·소프트웨어 관리 방식은 보통 정의 → 정렬 → 검토 → 승인 → 구현의 순서로 작동했다. 코드 작성이 비싸고 재작업이 느리던 시대에는 합리적인 방식이었다. 하지만 이 과정은 엔지니어에게 결정을 스스로 내리기보다 허가를 구하고, 이미 작성한 코드를 지키며, 폐기한 작업을 낭비로 여기는 습관을 심어주기도 했다.
반면 에이전트 시대에는 더 많은 결정을 되돌릴 수 있는 형태로 내리고, 소프트웨어로 빠르게 실험하며, 증거가 바뀌면 작업을 미련 없이 버리는 태도가 중요해진다. 따라서 조직 변화는 절차를 없애는 데서 끝나지 않는다. 구성원이 승인 대기 없이 판단하고 움직이는 법을 익혀야 한다.
이 변화가 늦으면 경쟁 위험도 커진다. Part I에서 언급된 46배의 역량 집중을 떠올리면, AI 전환이 늦은 50명 규모의 연구개발 조직이 경쟁사의 AI에 능숙한 엔지니어 2명에게 처리량에서 밀릴 수 있다. 두 사람은 관리 계층, PM 인수인계, 팀 간 대기열 같은 조직적 마찰도 거의 없다. 충분한 도메인 지식과 좋은 기술 구조까지 갖췄다면, 이들은 사실상 창업가처럼 움직인다.
기존 코드베이스는 여전히 방어막이 될 수 있지만, 영구적인 해자는 아니다. 좋은 코드베이스는 경쟁자에게도 훌륭한 명세처럼 작용할 수 있으며, 뛰어난 소수의 엔지니어는 이를 바탕으로 동등한 출발선을 빠르게 재구축한 뒤 더 앞서갈 수 있다. 그래서 조직은 그런 인재들이 경쟁사에 있지 않고 자사 안에 있도록 만들어야 한다.
3. PM과 엔지니어의 관계가 뒤집히다
기존 소프트웨어 조직에서는 보통 PM 1명당 엔지니어 약 6명이라는 비율이 일반적이었다. 엔지니어링이 더 느린 쪽이었기 때문에, PM은 개발팀이 구현할 일을 꾸준히 정의해 공급할 수 있었다.
그러나 기능 하나를 스프린트가 아니라 하루 만에 만들 수 있는 시대에는, 오히려 요구사항 정의와 제품 판단이 병목이 된다. 따라서 PM 대 엔지니어 비율은 한 방향으로 고정되지 않고, 고객과 얼마나 가까운지를 기준으로 두 가지 방향 중 하나로 바뀐다.
엔지니어가 제품 역할을 흡수하는 모델
개발자 도구나 인프라처럼 엔지니어 자신이 고객이거나, 엔지니어가 도메인을 매우 잘 아는 경우에는 PM 비율이 1:10 이상으로 넓어질 수 있다. 제품 업무가 사라지는 것이 아니라 엔지니어링 안으로 들어간다.
이때 각 엔지니어는 특정 제품 영역을 맡은 미니 창업가가 된다. 고객과 가까이 있으면서 무엇을 만들지 결정하고, 직접 출시한 뒤 사용 데이터를 통해 학습한다. 남아 있는 PM은 한 팀에 요구사항을 전달하는 사람이 아니라, 더 넓은 제품 포트폴리오를 담당한다.
PM이 하이브리드 빌더가 되는 모델
반대로 엔지니어가 고객을 충분히 이해하기 어려운 경우도 있다. 고객의 지역, 인구 통계, 전문 영역이 엔지니어와 멀다면 PM을 줄일 수 없다. 이때는 PM이 코드 도구를 직접 활용해 클릭 가능한 프로토타입과 작동하는 기능을 만들고, 엔지니어는 이를 단순히 명세로 번역하는 대신 구조·품질·보안·운영 안정성을 강화한다.
한 후기 단계 소프트웨어 기업은 이 논리로 PM 대 엔지니어 비율을 1:6에서 1:2 쪽으로 옮기고 있으며, 모든 PM이 Claude Code를 사용하게 하고 있다.
"나는 만들 수 있는 능력이 남아돕니다. 당신이 정의하면 내가 만들겠습니다. 나는 당신이 정의하는 속도보다 더 빨리 만들고 싶습니다."
— 후기 단계 소프트웨어 기업 CTO
명세 대신 작동하는 베타와 PR
이전에는 문서가 부서 간 인터페이스였다면, 이제는 작동하는 소프트웨어 자체가 인터페이스가 된다. 디자이너는 실제 동작하는 화면을 제출하고, PM은 기능이 구현된 프로토타입을 제출하며, 불과 1년 전만 해도 Git을 몰랐던 사람들이 풀 리퀘스트를 열기 시작한다.
"베타가 곧 명세이고, PR이 곧 인수인계다."
인수인계 자체가 사라지는 것은 아니다. 다만 "문서를 읽고 해석해 구현하는" 번역 과정이 줄어든다. 모두가 명세의 해석이 아니라 실제 베타를 보고 반응할 수 있기 때문이다. 엔지니어링은 여전히 아키텍처, 품질, 보안, 운영 승인에 책임을 지지만, 이제는 작동하는 변경 사항을 출발점으로 삼는다.
Claude Code의 제품 책임자인 Cat Wu는 이 역할 융합을 다음처럼 설명한다.
"우리 역할은 서로 섞이고 있습니다. 디자이너는 코드를 출시하고, 엔지니어는 제품 결정을 내리며, 제품 관리자는 프로토타입과 평가 도구를 만듭니다."
연구에 참여한 한 엔지니어링 리더는 채용 관점에서 더 직설적으로 말한다.
"개발자에게 PM 역량을 가르치는 편이, PM에게 아키텍트처럼 사고하는 법을 가르치는 것보다 쉽습니다."
계획 주기도 짧아진다
빠른 출시 속도는 PM 비율뿐 아니라 계획 방식도 무너뜨린다. 분기별 OKR, 6개월 로드맵, 2주 스프린트는 기능 하나에 한 달씩 걸리던 시대의 산물이다. 기능을 하루 만에 만들 수 있다면 6개월 앞을 정교하게 계획하는 일은, 출시 시점에는 이미 사라질 제약을 기준으로 계획하는 일이 될 수 있다.
Anthropic 내부 벤치마크에서는 Sonnet 3.5부터 Opus 4.6까지 16개월 동안, 최전선 모델이 사람 개입 없이 처리할 수 있는 작업 길이가 약 41배 늘어난 것으로 나타났다. 모델 역량 변화 간격보다 긴 계획 주기는 이미 존재하지 않을 세상을 전제로 삼을 위험이 있다. 따라서 조직은 장기 약속을 줄이고, 더 많은 실험을 빠르게 실행하고 폐기하는 쪽으로 이동해야 한다.
4. 제품을 출하하는 기본 단위, 자율 스쿼드
에이전트 시대의 핵심 실행 단위는 제품 감각을 가진 개인 기여자들이 구성한 작은 스쿼드다. 이들은 각자 에이전트를 지휘하면서 제품을 독립적으로 출시한다. 연구에 참여한 기업들은 세부 규모는 달랐지만, 대체로 1~5명 사이의 작은 팀으로 수렴했다. 가장 흔한 크기는 2~3명이다.
한 AI 네이티브 기업은 제품 세로 영역마다 약 5명을 배치한다. 구성은 백엔드 엔지니어 2명, AI 엔지니어 2명, 그리고 아키텍트에 가까운 역할 1명이다. 에이전트를 쓰더라도 복잡한 문제는 두 사람이 함께 다루는 편이 한 사람보다 좋은 경우가 많으며, 에이전트를 활용한 페어 코딩도 완전한 고립보다 건강한 협업 역학을 만들 수 있다.
1인 스쿼드라는 극단
1인 스쿼드는 완전히 다른 조직 형태라기보다, 작은 스쿼드 모델의 극단에 가깝다. 이에 대한 평가는 여전히 갈린다. 연구에 참여한 한 AI 네이티브 스타트업은 이를 아직 현실보다 이상화된 모델로 본다.
"낭만적인 이야기죠. 아직 충분히 좋지 않습니다."
— AI 네이티브 스타트업
그러나 다른 후기 단계 기업은 실제 운영 환경에서 5~6개의 1인 스쿼드를 운영한다. 한 명의 엔지니어가 제품을 처음부터 끝까지 소유하고, 거의 24시간 일하는 에이전트 팀을 지휘한다. 이 엔지니어는 PM 역할도 스스로 수행하며 고객과 제품을 이해한 상태에서 무엇을 만들지 결정한다. 이 구조는 엔지니어가 고객을 충분히 대변할 수 있는 영역에서 특히 잘 맞았고, 해당 기업은 재편 전보다 7배의 속도를 보고했다.
주니어 엔지니어는 사라지지 않았다
"AI 때문에 주니어 엔지니어는 끝났다"는 통념과 달리, 여러 기업은 조건부로 정반대 현상을 보고했다. 중요한 채용 기준은 연차가 아니라 AI 활용 능력과 제품 감각이다. 또한 이를 가능하게 하는 전제는 단단한 아키텍처의 중심축이다.
"제품 감각이 있는 주니어가 아키텍트와 짝을 이루면, 어제의 베테랑 프로그래머보다 더 강합니다."
— AI 네이티브 스타트업 CEO
다만 규모가 커지면 양상이 달라진다. 자체 엔지니어링 조직을 측정한 한 중견 SaaS 기업은 최근 졸업생에 가까운 L2 엔지니어가 AI 활용에서 가장 어려움을 겪고, 스태프와 프린시펄 엔지니어가 가장 적극적으로 활용한다는 결과를 얻었다. 그 기업의 CPTO는 이를 경험과 취향, 즉 더 넓은 맥락을 바탕으로 빠르게 결정을 내리는 능력의 차이라고 설명했다.
작은 AI 네이티브 조직에서는 곁에 있는 강한 아키텍트가 판단 부담을 더 많이 떠안을 수 있다. 반면 큰 조직에서 그런 근접성이 낮으면 개인의 판단력이 훨씬 중요해진다. 결국 핵심 기준은 단순한 근속 연수가 아니지만, 대규모 환경에서는 경험이 만들어낸 판단력의 가치가 더 크게 누적된다.
5. 자율성을 묶는 네 명의 최고 책임자
작은 자율 스쿼드는 인수인계를 줄이고 출시 속도를 높인다. 하지만 각 팀이 지역적으로는 타당한 결정을 내리면서도, 회사 전체로는 서로 다른 방향으로 갈 위험이 생긴다. 계층이 얇아질수록 기존의 아키텍트, 고위 관리자, 제품 검토 회의, 디자인 비평, 보안 게이트가 담당하던 정렬 기능도 자동으로 사라진다.
그래서 글은 회사 전체 맥락을 책임질 네 명의 최고 책임자, 즉 'Four Chiefs'를 제안한다.
-
Chief Architect
프로젝트 전반의 아키텍처 일관성을 유지하고, 외부 기술 변화에 맞춰 기술 선택을 갱신한다. -
Chief Product
자율 팀들을 하나의 제품 전략과 중요한 고객 요구에 맞춘다. -
Chief Designer
모든 제품 접점에서 일관되고 차별화된 시각적·제품적 목소리를 만든다. -
Chief Security
모델, 에이전트, 스쿼드, 그리고 AI 도입 과정에서 생기는 위험 영역을 아우르는 단일 보안 경계를 유지한다.
이들은 각 분야에서 가장 경험이 많고 AI를 가장 잘 다루는 사람이어야 한다. 스쿼드는 한 프로젝트 안에서 에이전트를 쓰지만, 최고 책임자는 여러 프로젝트를 가로질러 에이전트를 활용한다. 에이전트가 조사, 검색, 비교, 반복적 커뮤니케이션을 맡으므로, 최고 책임자의 조직은 대형 부서로 커질 필요 없이 개인 또는 아주 작은 팀으로 유지될 수 있다.
모델과 팀의 자유가 만드는 분산 위험
자율 스쿼드는 데이터베이스, 인증, API 패턴, UI 구성 요소, 상태 관리, 테스트, 관찰 가능성, 외부 라이브러리 등을 자체적으로 선택할 수 있다. 여러 모델을 함께 쓰는 것은 좋은 관행이다. 모델마다 강점이 다르고, 독립적인 의견이 중요한 판단을 개선하며, 한 제공업체에 전적으로 의존하지 않아도 되기 때문이다.
그러나 모델에는 각자의 기본 편향도 있다. 2026년 ACL Findings 논문인 대규모 언어 모델의 라이브러리 및 프로그래밍 언어 선호 연구는 8개 모델을 비교해, 모델들이 적합성보다 익숙하고 인기 있는 언어·라이브러리를 선호하는 경향을 확인했다. 즉, 모델이 회사에 가장 맞는 선택이 아니라 가장 흔한 선택으로 팀을 이끌 수 있다.
여러 스쿼드가 각각 합리적인 선택을 해도, 시간이 지나면 호환되지 않는 기술 스택과 중복 인프라가 쌓일 수 있다. 여러 모델의 다양성은 판단에 도움이 되지만, 팀의 자율성과 결합하면 선택의 분산을 더 넓힐 수 있다.
모두가 비슷해 보이는 디자인 문제
디자인에서는 이 문제가 더 눈에 잘 띈다. 많은 모델은 비슷한 제품 데이터로 학습했기 때문에, 익숙한 컴포넌트 라이브러리, 둥근 카드, 예측 가능한 레이아웃 같은 안전한 기본값으로 수렴한다. 회사가 독자적인 시각 언어를 세우지 않으면, 모델은 통계적 평균을 채워 넣는다.
"AI 디자인은 파생적입니다. Tailwind와 Bootstrap으로 학습돼서, 결국 모든 것이 똑같아 보입니다."
— 연구 참여 기업 3곳의 공통 관찰
따라서 Chief Designer는 타이포그래피, 색, 구성, 이미지, 움직임, 그리고 회사가 의도적으로 거부할 관습까지 포함하는 고유한 디자인 언어를 설정해야 한다. 에이전트는 이를 수백 개 화면에 일관되게 적용하고 변형을 만들 수 있지만, 브랜드의 인간적 관점 자체를 대신해서 만들어주지는 못한다.
멈추게 하지 않는 교통 통제
스쿼드의 지역적 맥락은 요구사항, 저장소, 테스트, 당장의 고객 문제에 집중한다. 반면 최고 책임자는 공통 아키텍처, 기술 스택, 제품 전략, 보안 정책, 디자인 시스템, 고객 약속, 재사용 가능한 코드·데이터·프롬프트·디자인 자산, 그리고 과거의 예외 사항까지 기억해야 한다. 이것이 곧 회사 전체의 기억이다.
최고 책임자는 여러 모델을 활용해 이 역사를 검색하고 외부 대안을 비교한다. 중요한 사안에서는 복수의 모델을 사용해 모델 간 이견을 드러내고, 그 이견 속에 숨어 있는 가정과 편향을 확인한다. 모델이 시야를 넓혀 주지만, 최종 판단은 축적된 인간의 경험이 내린다.
기존의 신호등을 없애면서도 무질서에 빠지지 않으려면, 최고 책임자는 각 팀이 문제를 알아서 올려주기만 기다려서는 안 된다. 이들이 운영하는 에이전트는 회사 전체 프로젝트의 계획, 코드, 의존성, 디자인 변화, 보안 예외, 고객 약속을 지속적으로 살핀다. 회사 표준과 과거 결정을 비교해, 작은 팀의 선택이 회사 전체 문제가 되기 시작할 때 책임자에게 알려준다. 일상적 결정은 스쿼드에 맡기되, 중대한 문제는 비동기적으로 조기에 포착하는 방식이다.
"신호등 없이도 교통을 통제한다."
또 다른 사례로, 한 AI 네이티브 기업의 CEO는 Slack, 운영 환경, 회의 기록, 모니터링 도구와 연결된 개인 에이전트를 만들었다. 구성원은 CEO를 바로 찾기 전 이 에이전트와 먼저 대화한다. 다른 선도 조직은 각 제품마다 대화 기록, 코드, 고객 통화를 아는 봇을 두고, 제품 책임자는 이를 출시 승인 전의 첫 검토 단계로 활용한다. 일상적인 질문은 에이전트가 답하고, 실제 판단이 필요한 사안만 사람에게 도달한다.
6. 관리 계층은 짧아지고 관리 범위는 넓어진다
제품 감각을 가진 개인 기여자가 에이전트를 지휘하고, 작은 스쿼드가 독립적으로 출시하며, 네 명의 최고 책임자가 회사 전체 방향을 유지하게 되면 그 주변의 관리 구조는 압축될 수 있다. 에이전트가 상태 수집, 업무 조율, 일상적 인수인계를 흡수하면서, 관리자는 더 많은 엔지니어와 스쿼드를 맡을 수 있다.
이는 관리가 사라진다는 뜻이 아니다. 관리의 밀도와 목적이 바뀐다는 뜻이다. 조직도는 더 짧아지고 넓어진다. 즉, 엔지니어 한 명당 관리자가 줄고, 현장의 빌더에서 임원까지 거치는 단계가 줄며, 관리자 한 명이 맡는 범위는 커진다.
25명 규모 스타트업에서는 팀 단위 관리자가 완전히 사라질 수도 있다. 500명 규모 엔지니어링 조직에서는 한 관리 계층이 줄어들고 관리 범위가 넓어지며, 남은 관리자는 업무 조율보다 인사, 포트폴리오, 팀 간 판단에 집중하게 될 가능성이 높다.
기존 엔지니어링 매니저 역할은 사람 관리와 업무 흐름 조율을 함께 묶어 왔다. 상태 회의, 스프린트 계획, 용량 배분, 장애물 제거, 팀 간 협상 등이 여기에 포함됐다. 에이전트는 이런 조율 업무의 상당 부분을 줄일 수 있지만, 코칭, 성과 관리, 채용, 거버넌스, 제품·플랫폼을 가로지르는 판단까지 없애지는 못한다.
먼저 줄어드는 것은 주로 다른 계층 사이에서 상태를 번역하고 인수인계를 조율하는 역할이다. 반면 남는 관리 역할은 더 넓고, 더 많은 판단을 요구한다.
더 넓은 관리 범위를 가능하게 하는 자동화
회의와 통화의 자동 전사·요약, 팀 활동에서 곧바로 위험을 찾아내고 상태 보고를 초안하는 에이전트, 관리자의 의도를 후속 조치로 바꾸는 보조 도구가 확산되면서, 관리자는 직접 가시성을 만들어내는 데 쓰던 시간을 줄일 수 있다.
이전에는 관리자가 4~6명 정도의 직접 보고자를 맡는 것이 일반적이었다면, 일부 조직은 이제 15~25명까지 맡을 수 있다고 본다. 핵심은 AI가 관리자의 판단을 대체해서가 아니라, 회의 참석, 보고서 작성, 1:1 미팅 준비, 장애물 추적, 여러 업무 흐름의 연결 같은 반복 작업을 줄여 주기 때문이다.
Ramp는 에이전트를 공유되는 다중 사용자 세션에서 실행해, 팀원들이 상태 보고 회의를 기다리지 않고 서로의 작업을 실시간으로 볼 수 있게 한다. 회의 기록은 검색 가능한 회사 기억으로 남는다. 앞서 언급한 CEO 개인 에이전트처럼, 리더의 맥락도 필요할 때 조회할 수 있다. 이런 상시적 가시성과 질의 가능한 리더십 맥락이 관리 범위를 넓힌다.
관리자의 경력 경로는 세 갈래가 된다
더 큰 팀을 관리하는 것이 곧 더 높은 직급이라는 전통적인 등식은 약해진다. 관리 범위가 넓어지고 계층이 압축되면서, 관리자는 다음 세 방향 중 하나로 이동할 수 있다.
-
관리 범위를 넓히는 길
작은 팀 하나가 아니라 여러 스쿼드나 제품 영역을 맡는다. AI가 가시성과 후속 조치를 보조하고, 관리자는 사람·우선순위·성과·팀 간 선택에 책임진다. -
현업 엔지니어링으로 돌아가는 길
이전에 4명을 관리하던 사람이 시니어 개인 기여자로 전환해, 여러 에이전트로 구성된 스쿼드를 지휘한다. 영향력의 범위는 유지되지만 업무 형태가 바뀐다. -
스쿼드 간 리더십을 맡는 길
아키텍처, 플랫폼, 제품 영역, 보안처럼 프로젝트 하나가 보존할 수 없는 맥락과 판단을 책임지는 회사 전체 역할로 이동한다.
세 경로의 공통 조건은 관리자가 반드시 AI에 깊이 익숙해져야 한다는 점이다. AI를 쓰는 사람을 감독하는 것만으로는 부족하다. 리더 자신이 에이전트를 직접 운영하고, 새 업무 방식을 실제로 이해하며, 좋은 에이전트 기반 성과가 무엇인지 구별할 수 있어야 한다.
결국 중요한 것은 팀 규모가 아니라 레버리지다. 대기업에도 중간관리는 남겠지만, 단지 계층 사이에 상태를 전달하기 위해 존재하는 역할은 줄어들 것이다.
7. 구축 능력은 엔지니어링 밖으로 퍼진다
에이전트 기반 업무 전환은 엔지니어링에서 먼저 시작됐지만, 수익 운영, 재무, 인사, 고객 지원, 법무 등 다른 부서도 같은 방향으로 움직인다. 이는 이들을 소프트웨어 엔지니어로 바꾼다는 뜻이 아니다. 각 부서가 자신이 이미 사용하는 시스템 안에서 작동하는 에이전트와 맞춤형 내부 애플리케이션을 갖게 된다는 의미다.
기존에는 사람이 CRM, 청구 시스템, 이메일, 스프레드시트, 고객 지원 큐를 오가며 맥락을 모으고 반복 작업을 수행했다. 에이전트는 이 맥락을 조립하고, 일상 단계를 실행하며, 여전히 인간 판단이 필요한 결정만 사람에게 돌려준다. 이런 시스템이 발전할수록 수작업 절차와 얇은 기능만 제공하는 SaaS 도구는, 회사의 데이터와 운영 방식에 맞춘 에이전트형 내부 도구로 대체되기 시작한다.
이미 연구에서는 다음과 같은 사례가 관찰됐다.
- 한 RevOps 팀은 코딩 에이전트와 자동화 도구로 영업 주기 분석 및 거래 점수화 소프트웨어를 만들고 있다.
- 다른 기업은 영업·마케팅을 위한 통화 브리핑 등 시스템을 만드는 5명 규모 GTM AI 팀을 운영한다.
- 여러 기업이 HR 후보자 심사 도구, 내부 가격 책정 애플리케이션, 헬프데스크·회의 인텔리전스 시스템을 자체 구축했다.
- 매출·엔지니어링·재무·인사 데이터를 한데 모으는 대시보드도 등장했다.
이들은 본업 외 시간에 제품 개발을 하는 직원들이 아니다. 각 기능 부서가 자기 업무가 수행되는 방식을 직접 다시 만들고 있는 것이다.
비즈니스 소프트웨어에서도 IDE 다음 단계가 온다
엔지니어링에서 처음에는 기존 IDE 안에 AI 보조 기능을 넣는 것으로 시작했다. 그러나 더 큰 변화는 에이전트가 결과 목표를 받아 전체 도구 체인을 직접 작동하기 시작하면서 일어났다.
비즈니스 소프트웨어에서도 마찬가지다. CRM 내부의 더 나은 사이드바나 Excel용 AI 확장은 유용하지만, 여전히 사람이 애플리케이션을 조작해야 하는 'IDE 단계'에 가깝다. 진짜 에이전트 전환은 에이전트가 고객 이력을 읽고, CRM 기록을 업데이트하고, 다음 행동을 촉발하며, CRM·이메일·청구·지원 시스템을 가로질러 스스로 작업할 때 시작된다.
전략과 마케팅도 하나의 살아 있는 맥락을 갖는다
네 명의 최고 책임자가 아키텍처·제품·디자인·보안을 일관되게 관리하는 방식은 전략과 마케팅에도 확장된다. 에이전트는 고객 대화, 영업 활동, 지원, 재무, 제품 사용, 경쟁사, 공개 자료 전반에서 능동적으로 신호를 수집한다. 또한 단순히 무슨 일이 일어났는지만이 아니라 왜 그런 결정이 내려졌는지까지 보존한다.
그 결과 리더십과 마케팅은 파편화된 보고서 더미가 아니라, 로드맵·포지셔닝·회사 전략을 위한 하나의 살아 있는 맥락을 갖게 된다.
Anthropic의 Cat Wu도 조직 전체에서 같은 현상을 확인했다.
"데이터 과학, 재무, 마케팅, 법무, 디자인 팀이 이 도구들을 스스로 쓰기 시작했습니다. 이제 조직 전체가 인수인계를 기다리지 않고 같은 속도로 움직입니다."
AI Ops와 구매·구축의 새로운 경계
이 변화 속에서 AI Ops는 엔지니어링만 지원하는 조직이 아니라 전사 기능이 된다. 모든 부서에 도구, 교육, 재사용 가능한 패턴, 공통 보안·데이터 기반을 제공한다. 동시에 각 부서가 무엇을 만들고 어떤 모델과 데이터를 쓰는지, 어디에서 선택이 서로 갈라지는지도 파악하게 한다.
이것이 없으면 회사는 빨라지는 대신 그림자 소프트웨어, 불일치하는 통제, 같은 문제를 푸는 열 개의 데이터베이스를 갖게 될 수 있다.
맞춤형 개발 비용이 내려가면서 구축할 것인가, 구매할 것인가의 경계도 이동한다. 신뢰할 수 있는 시스템 오브 레코드, 규제를 받는 핵심 시스템, 강한 네트워크 효과가 있는 제품은 여전히 구매하는 편이 낫다. 반면 경직된 포인트 솔루션과 얇은 인터페이스는 교체하기 쉬워진다.
가장 가능성 높은 방향은 신뢰할 수 있는 핵심 시스템은 구매하되, 회사를 차별화하는 워크플로와 자사 데이터를 활용하는 에이전트 계층은 직접 만드는 것이다. 그래서 API, MCP 지원, 에이전트 접근성이 새로운 구매 기준이 되고 있다.
8. 지금 조직이 서 있는 위치
글은 에이전트 기반 개발의 전환 순서를 간단히 정리한다. 이는 먼저 인프라 문제, 다음은 사람 문제, 마지막은 조직 문제다. 많은 기업은 마지막 단계에서 멈추지만, 가장 큰 레버리지는 바로 이 조직 변화에 있다.
현재 조직이 어디에 서 있는지는 도구 성숙도와 사람 전환 수준, 두 축으로 판단할 수 있다.
이미 전환점을 지난 AI 적응 조직
AI 네이티브 기업, 또는 2025년 4분기에 AI 보조 IDE를 넘어 자율 에이전트 개발로 과감하게 전환한 기존 기업들이 여기에 속한다. 이들은 도구 도입과 인력 전환을 지나, 실제 측정 지표를 기반으로 조직 구조를 재설계하고 조정하는 어려운 단계에 있다.
직원 다수는 교육, 채용, 교체를 통해 AI 전환을 믿고 활용하는 집단으로 이동했으며, 변화에 저항하던 기존 방식의 수호자들이 만들던 장애물도 상당 부분 제거됐다.
전환점에 가까워지는 신중한 조직
대부분의 조직은 이 구간에 있을 가능성이 높다. 새 제품이나 제품 내 AI 기능에서 일부 에이전트 프로젝트를 진행하지만, 조직 대부분은 여전히 IDE 중심으로 일한다. 또한 에이전트 개발을 확장할 인프라를 구축하는 중이다.
이들은 아직 과감하게 방향을 틀 준비가 되어 있지 않다. 조직 안에 기존 방식에 강하게 묶인 사람들과 저항하는 사람이 남아 있고, 기존 아키텍처에 제약을 느끼며, 통제력을 잃을까 우려한다.
아직 전환하지 못한 보류 조직
이들은 일부 IDE 도구를 추가했을 뿐, 모든 변경 사항이 선택 또는 규제 준수의 이유로 반드시 사람 검토를 거친다. 도구와 사람 양쪽에서 가장 초기 단계이며, 따라잡아야 할 거리는 가장 길고 시간은 가장 부족하다.
9. 먼저 움직인 기업의 우위와 늦은 기업의 선택
AI 지원 IDE가 보편화된 시기는 2023~2024년이었지만, 당시에는 여전히 사람이 코드의 모든 줄을 주도했다. 글은 실제 변곡점이 2025년 4분기라고 본다. Claude Code 2.0이 2025년 9월, Opus 4.5가 2025년 11월 등장하면서, 에이전트가 데모 수준을 넘어 신뢰할 수 있는 업무 도구가 되기 시작했다는 것이다.
초기 2025년의 METR 무작위 실험에서는 숙련된 개발자가 AI를 쓸 때 오히려 19% 느려졌다. 참가자들은 자신들이 20% 빨라졌다고 생각했지만 실제 데이터는 반대였다. 같은 개발자를 2025년 후반에 다시 측정했을 때는 방향이 반전됐지만, 연구진은 많은 참가자가 AI 없이 일하기를 거부할 정도였기에 새 수치는 아직 강한 증거로 보기 어렵다고 경고했다.
이 사례는 불과 몇 달 사이에 도구 성능과 사용 경험이 얼마나 빠르게 바뀌었는지를 보여준다. 먼저 전환한 기업의 우위는 실제로 존재하며 누적된다. 하지만 글은 늦은 기업도 이미 더 좋은 도구, 먼저 시행착오를 겪은 기업들의 학습, 검증된 실행 방식을 물려받는다고 강조한다.
"타이밍이 선두를 만들었다. 하지만 운영 방식의 선택이 앞으로의 기울기를 결정한다."
늦게 움직이는 기업은 두 길 중 하나를 선택할 수 있다.
- 기존 운영 모델을 유지한 채 조심스럽게 AI를 도입하면, 개인 단위의 유의미한 향상은 얻을 수 있지만 격차는 계속 누적된다.
- 인프라, 업무 흐름, 역할, 의사결정 권한을 에이전트 기반 업무에 맞게 다시 그리면, 더 가파른 성장 곡선으로 옮겨가 선두와의 격차를 줄일 수 있다.
"후발 주자에게 선택의 순간은 지금이다."
10. 다음 전환은 더 빠르게 찾아온다
2025년 4분기의 변화는 끝이 아니라 연속적인 전환의 시작이다. 한 시간 동안 사람 개입 없이 일하는 에이전트와 하루 동안 일하는 에이전트는 단지 같은 도구를 더 오래 쓰는 것이 아니다. 필요한 팀 구성, 검토 방식, 조직 구조 자체가 달라진다.
문제는 사람들이 보통 선형적으로 계획한다는 데 있다. 다음 분기는 이번 분기에 조금 더한 모습일 것이라고 생각하지만, AI 역량은 그렇게 천천히 움직이지 않는다. 5배의 세계를 기준으로 만든 구조는, 조직이 그 구조에 맞춰 인력을 채용하는 사이 도착한 20배의 세계에서는 이미 뒤처져 있을 수 있다.
글은 1년 뒤를 상상해 보라고 제안한다. 월요일 아침에 에디터를 여는 대신, 기능·버그 수정·테스트·마이그레이션·리서치·리뷰를 맡은 수백 개 에이전트에게 작업을 브리핑한다. 이들은 밤과 주말에도 계속 일한다. 사람의 핵심 업무는 무엇을 만들지 결정하고, 돌아온 결과가 옳은지 확인하는 일이 된다.
기존 코드베이스라는 해자는 매 분기 조금씩 얕아진다. 동등한 시스템을 처음부터 다시 만드는 시간이 줄어들기 때문이다. 이는 아직 보이지 않는 돌파구를 가정한 예측이 아니라, 이미 보이는 현재의 곡선을 12개월 연장한 시나리오다.
또한 에이전트는 더 많아질 뿐 아니라 더 빨라진다. 현재 몇 분 이상 걸리는 빌드, 테스트, 재작업의 순환은 점차 즉각적인 수준으로 압축된다. 사람의 입력이 필요한 짧은 반복은 몇 분이 아니라 몇 초 안에 끝나면서, 작업은 인수인계의 연속이 아니라 실시간 대화처럼 느껴질 수 있다. 반대로 긴 작업은 에이전트가 사람을 다시 부르지 않고 몇 시간 또는 며칠 동안 계속 수행한다.
하지만 빨라지지 않는 것이 하나 있다. 바로 무엇을 만들지, 결과가 맞는지 판단하는 인간의 판단력이다. 그래서 그것이 결국 사람의 가장 중요한 일이 된다.
이 변화는 엔지니어링을 넘어 수익 운영, 재무, 인사, 지원, 법무로 확산된다. 연구개발 조직이 먼저 움직인 것은 도구 사용 경험이 길고 자동화 유인이 강했기 때문이지만, 다른 부서가 그 과정을 처음부터 다시 발견할 필요는 없다. 도구 도입, 인력 전환, 부서 간 맥락 관리, 조직 변화라는 실행 방식은 그대로 옮겨갈 수 있다.
11. 마무리
에이전트 시대에 필요한 것은 한 번의 완벽한 조직 개편이 아니다. 기술 역량의 변화가 계속해서 팀 구조, 검토 방식, 권한 배분, 관리 역할을 다시 요구할 것이기 때문이다.
따라서 조직이 가져야 할 핵심 역량은 변화의 최전선 가까이에 머물며 다음 전환을 일찍 알아차리고, 그에 맞춰 계속 재구성하는 능력이다. 💡
"에이전트의 각성은 이미 산업 전체를 움직이고 있다. 이를 일찍 보는 사람들이 소프트웨어의 다음 시대를 정의할 것이다. 나머지는 그 안에서 깨어나게 될 것이다."