# The AI Product Operating Model ### AI 네이티브(AI Native) 기업은 어떻게 사고하는가, 그리고 그 원칙을 활용해 더 빠르게 확장하는 법  마티 케이건(Marty Cagan)은 [제품 운영 모델(product operating model)](https://www.news.aakashg.com/p/the-marty-cagan-episode-product-management)을 널리 알린 인물이다. 하지만 최고 수준의 AI 기업들이 일하는 방식을 보면, 모습이 꽤 다르다. - **[앤트로픽(Anthropic)](https://www.news.aakashg.com/p/taste-at-speed)** 엔지니어들은 수백 가지 해결책을 프로토타이핑하고, 제품 관리자나 디자이너와 상의하지 않은 채 바로 출시한다. - **오픈AI(OpenAI)의 최신 화제작 [코덱스(Codex)](https://www.news.aakashg.com/p/how-to-break-into-openai)** 는 PM 두 명, 디자이너 한 명, 엔지니어 약 40명으로 출발했다. 이들은 10~12개의 서로 다른 제품 표면(product surface)을 함께 책임졌다. 전통적인 회사라면 각 표면마다 15~20명 규모의 전담 스쿼드가 붙었을 것이다. - **[커서(Cursor)](https://www.news.aakashg.com/p/how-cursor-grows)** 는 엔지니어 40명, PM 1명으로 운영되면서 역사상 거의 어떤 회사보다도 빠르게 ARR 40억 달러를 넘어섰다. 이 새로운 일하는 방식은 이전 세대의 제품 운영 모델이 아니다. 이 방식이 바로 “AI 제품 운영 모델(AI product operating model)”이며, 앞으로 10년 동안 대부분의 회사가 이 방향으로 옮겨갈 것이다. 지난 3년 동안 나는 AI 제품 운영 모델을 정의하는 작업을 해왔다. 150회가 넘는 팟캐스트와 [이 주제에 대한 수많은 심층 분석](https://www.news.aakashg.com/p/complete-courses-pm)을 거쳐, 오늘 드디어 그 전체를 내놓을 준비가 됐다. *그리고 이 작업을 나 혼자 한 것은 아니다.* ## 왜 이것이 중요한가 샘 올트먼(Sam Altman)이 2024년에 한 말을 떠올려 보자. > *우리 생애 안에 최초의 **1인 10억 달러 기업(one-person billion-dollar company)** 이 등장할 것이다. 어쩌면 아주 머지않아. 과거에는 수백 명이 필요했던 일을 AI 에이전트가 전부 수행하게 될 것이다.* 이 일은 정말로 벌어지고 있다. 매슈 갤러거(Matthew Gallagher)는 **메드비(Medvi)** 를 만들었고, 2025년에 [혼자서 4억 달러 이상을 벌어들였다](https://www.forbes.com/sites/josipamajic/2026/04/02/ai-and-20000-helped-one-man-build-a-18-billion-telehealth-startup/). 지금은 동생을 고용했고, 2026년에는 **18억 달러** 규모가 예상된다. 여기에 **[오픈클로(OpenClaw)](https://www.news.aakashg.com/p/openclaw-guide)** 의 놀라운 성장도 있다. 피터 슈타인베르거(Peter Steinberger)는 혼자서 가장 유용한 AI 개인 비서 가운데 하나를 만들었고, 그것을 엄청난 규모로 키워 전 세계 가정에서 이름이 알려질 정도로 성장시켰다. 다시 말해, 수많은 에이전트를 거느린 한 사람이 해낸 일이다. 이 수치를 대기업의 엔지니어링 부문 부사장에게 보여주면, 아마 이런 회사들은 오래 못 간다고 말할 것이다. 적절한 인력 배치 없이 이 규모에서 품질과 성장을 유지할 수는 없다고 할 것이다. 그리고 소프트웨어 역사 대부분, 즉 지난 30년 동안은 *그 말이 완전히 맞았다*. **하지만 지난 3년 동안 엄청난 변화가 일어났고**, 대부분의 조직은 아직 그 현실을 제대로 받아들이지 못하고 있다. 코덱스는 최근 한 대기업과 해커톤을 열었다. 개발자가 수천 명이고, 엔지니어링 문화도 성숙한 회사였다. **그들은 현대화 프로젝트 하나를 엔지니어 10명, 기간 12개월로 산정했다**. 그런데 코덱스와 함께한 엔지니어 두 명이 그 일을 단 **3일 만에** 끝냈다. 그러니 이제 우리가 붙들고 생각해야 할 질문은 이것이다. *왜 예전에는 불가능했던 일이 지금은 가능해졌는가?* --- ## 오늘 글에서 다룰 내용 *우리는 AI 네이티브 기업이 어떻게 조직되는지 그 구조적 논리를 정리했다. 사람 모델(people model), 프로세스 모델(process model), 도구 모델(tool model), 경제 모델(economic model), 그리고 지금 여러분이 어디에 있든 그 방향으로 조직을 재구축하기 시작하는 방법까지 모두 담았다.*  1. 회사를 붙잡아 두는 믿음 2. 제품 개발의 전도(inversion) 3. 지금의 EPD는 어떤 모습인가 4. AI 네이티브 워크플로 5. 실제로 맞닥뜨릴 문제들 6. 시작하는 법 - AI 레버리지 플레이북(AI Leverage Playbook) *추가로 4개의 다운로드 자료도 제공한다. AI 네이티브 팀 진단 워크시트(AI Native Team Diagnostic Worksheet), AI 워크플로 분해 역량 자료 등도 포함된다.* --- ## 1\. 회사를 붙잡아 두는 믿음 여러분의 제품 조직이 지금까지 내린 모든 결정은 결국 하나의 믿음으로 이어진다. > *코드를 작성하는 일은 어렵고, 엔지니어는 가장 희소한 자원이다.* 이 믿음의 실타래를 잡아당기면 얼마나 많은 것이 풀려나오는지 보게 된다. 지금 여러분이 운영하는 조직도는 회사가 이 믿음과 부딪힐 때마다 쌓아 올린 화석 기록의 집합이다. 사람, 프로세스, 도구 전반에 걸쳐 그렇다.  ***먼저 사람부터 보자.*** 조직 전체가 엔지니어를 중심으로 짜여 있다. 엔지니어는 비용이 많이 드니, 잘못된 것을 만드는 데 한 스프린트라도 낭비할 수 없다. 그래서 그들을 조율하는 여러 계층을 둔다. EM, TPM, 스크럼 마스터가 여기에 해당한다. 우선순위를 냉정하게 정하는 PM도 둔다. 각 계층마다 전문가도 채용한다. QA, 보안, 플랫폼, 데이터가 그렇다. 일이 너무 복잡해져서 범용 인력만으로는 감당이 안 되기 때문이다. 그러고 나면 그 전문가들을 관리할 사람도 또 채용한다. 지금 전통적인 팀에서 들어가는 전체 노력의 거의 30~50%는 순수한 **조율 오버헤드(coordination overhead)** 다. ***이제 프로세스로 가보자.*** 스프린트 계획은 엔지니어가 일을 시작하기 전에 올바른 것을 만들도록 보장하기 위해 존재한다. 방향을 중간에 바꾸는 비용이 크기 때문이다. 백로그 정리도 같은 이유로 존재한다. 코드 리뷰는 사람이 작성한 모든 코드 한 줄 한 줄을 또 다른 사람이 검증한 뒤에야 프로덕션에 반영하도록 하기 위해 존재한다. QA, 스테이징, 기능 플래그, 단계적 롤아웃, 온콜 사고 대응까지. 이 모든 점검 지점은 비용이 비싼 엔지니어링 시간을 낭비하지 않게 지키기 위해 존재한다. ***마지막으로 도구를 보자.*** IDE는 한 명의 엔지니어가 문자를 한 글자씩 입력해 코드를 작성할 때 쓰는 정밀 도구다. Jira는 일이 몇 주씩 걸리는 느린 파이프라인에서 사람들을 조율하기 위해 존재한다. 데일리 스탠드업은 업무가 느리게 움직이고, 의존성이 사방에 깔려 있을 때, 사람들이 막힘 없이 일하려면 정기적으로 동기화해야 하기 때문에 존재한다. 하지만 이 믿음은 이제 더 이상 사실이 아니다. **코드를 만드는 일은 더 이상 비싸지 않다.** 지금 여러분 머릿속 한구석을 불편하게 해야 할 질문은 이것이다. *오늘 쓸 수 있는 도구를 가지고 지금 제품 조직을 완전히 처음부터 만든다면, 이 모든 것이 지금과 같은 형태로 존재하겠는가?* 2주 스프린트를 운영하겠는가? 코드 한 줄 쓰기 전에 30페이지짜리 PRD를 작성하겠는가? 전담 QA를 둘 것인가? 각 제품 표면마다 15명짜리 스쿼드를 붙이겠는가? 이 시대에 탄생한 AI 네이티브 기업들은 그 답이 어떤 모습인지 보여주는 가장 좋은 길잡이일 수 있다. 그리고 거의 예외 없이 그 답은 **아니오**다. 바로 그 간극이 지금 전 세계 모든 제품 조직 안에 숨어 있는 기회이자 위협이다. --- ***🔨 여러분 팀이 실제로 AI 네이티브인지 어떻게 알 수 있을까?** 우리는 직접 작성해도 되고 클로드(Claude)/코덱스(Codex)와 함께 검토해도 되는 마크다운 진단 워크시트를 만들었다. 이 워크시트는 팀의 가장 큰 병목이 무엇인지 파악하고, AI 네이티브 준비 상태를 평가하며, 오늘 운영 중인 모델과 내일 필요할 가능성이 큰 모델을 비교해 그려보는 데 도움이 된다.*  --- ## 2\. 제품 개발의 전도(inversion) 몇 년 전 코딩 에이전트가 등장하기 시작했을 때, 대부분의 엔지니어링 리더는 그것을 ‘생산성 도구(productivity tools)’로 분류했다. 더 나은 IDE, 더 똑똑한 자동완성, 더 빠른 CI 파이프라인과 같은 정신적 범주에 넣은 것이다. 하지만 도구는 거기에 머무르지 않았다. 불과 2년 만에 세 단계를 거쳐 진화했다. GitHub Copilot과 [커서(Cursor)](https://www.news.aakashg.com/p/how-cursor-grows) Tab 같은 자동완성 보조 도구에서, [클로드 코드(Claude Code)](https://www.news.aakashg.com/p/claude-code-v21-is-insane-ai-update) 같은 작업 단위 CLI 에이전트로, 그리고 복잡한 일을 받아 스스로 반복 개선하고 결과물을 출시하는 [코덱스(Codex)](https://www.news.aakashg.com/p/codex-pm-guide) 같은 완전한 에이전트형 시스템으로 발전했다. 감이 오도록 하나만 짚어보자. **예전에는 엔지니어가 10시간 걸리던 작업이, 이제는 코덱스나 클로드 코드를 쓰면 10분이면 된다.**  전통적인 제품 프로세스에서는 실제 구축(build)을 뒤로 미룬다. 만드는 비용이 크기 때문에 그 전에 다른 것을 앞당겨 처리한다. 리서치, 디스커버리, 명세 작성, 디자인 리뷰, 기술 범위 산정, 이해관계자 정렬이 여기에 해당한다. 하지만 구축 비용이 충분히 낮아져서 먼저 만들고 나중에 평가할 수 있게 되면, 이 논리는 무너진다. **코덱스와 커서에서는 전통적인 SDLC의 여러 단계가 무너지거나 사라졌다.** - **코드 리뷰를 별도 단계로 둘 필요가 있는가?** 에이전트가 생성 시점에 자기 작업을 스스로 검증하고, 사람은 코드 한 줄 한 줄의 diff가 아니라 결과물을 검토한다면, 전통적인 리뷰 절차는 중복이다. - **정교한 스프린트 계획이 필요한가?** 잘못된 것을 만드는 비용이 엔지니어링 2주가 아니라 에이전트 시간 30분이라면, 먼저 만들어 보고 나중에 평가해도 된다. 코덱스가 정확히 그렇게 한다. - **구축 후 의사결정이 아니라, 의사결정 후 구축인가?** 이 순서 자체가 완전히 뒤집혔다. 더 이상 “이 명세를 보고 이걸 만들까?”를 묻지 않는다. 대신 “XYZ를 바탕으로 이런 아이디어가 있었고, 이걸 만들어 봤다. 밤사이 에이전트가 만든 이 작동하는 제품을 출시할까?”를 묻는다. 이 한 가지 전도는 제품 의사결정이 이루어지는 *전체 인식론(epistemology)* 을 바꿔 놓는다. 이제는 어떤 것이 어떨지 추론해서 결정하는 것이 아니라, 그것이 실제로 무엇인지 직접 경험한 뒤에 결정하기 때문이다. --- 🔒 *지금까지가 AI 네이티브 기업이 왜 이기는지에 대한 구조적 논리였다. 아래 내용도 이어진다:* - *PM, 엔지니어, 디자이너 역할이 정확히 어떤 방식으로 처음부터 다시 설계되고 있는가* - *스프린트와 PRD를 대체하는 완전한 AI 네이티브 워크플로* - *오늘 여러분의 위치가 어디든 적용할 수 있는 전체 AI 레버리지 플레이북(AI Leverage Playbook) — 스타트업부터 대기업까지* ***\+ 다운로드 자료 4종**.* ## 7일 무료 체험으로 계속 읽기 Product Growth를 구독하면 이 글을 계속 읽을 수 있고, 전체 아카이브에도 7일 동안 무료로 접근할 수 있다.