🤖 병목 혹은 양분: AI 기반 코딩이 바꿀 프로덕트 매니지먼트

OpenAI가 Palantir가 대중화한 용어인 '전방 배치 엔지니어(forward deployed engineers)'로 구성된 컨설팅 서비스를 구축한다고 발표했을 때, AI 생태계는 주목했습니다.

FDE 트렌드는 두 가지 근본적인 원인을 가진 증상입니다.

첫째, 현장 개발(onsite dev)은 새로운 카테고리를 판매하는 회사들에게 기대되는 역량입니다. 고객이 제품을 구매한 후 (이상적으로는 계약이 만료되기 전에) 제품 사용법을 가르쳐야 하기 때문입니다.

둘째, 그리고 더 광범위한 소프트웨어 산업에 더 중요한 것은, FDE가 점점 커지는 문제에 대한 해결책을 제시한다는 점입니다. AI 기반 엔지니어는 2~5배 더 빠르게 코딩할 수 있지만, 프로덕트 매니지먼트 작업은 같은 속도로 가속화되지 않았습니다. 조직들은 전통적인 PM 프로세스를 기다리는 대신, 하이브리드 형태의 엔지니어-PM이 고객과 직접 소통하며 제품을 만들도록 힘을 실어주고 있습니다. 관련성을 유지하고 회사가 안정적이고 안전하며 성공적인 제품을 출시하는 데 계속 기여하기 위해, 프로덕트 매니저와 조직 구조는 적응해야 합니다.

이 두 가지 원인을 순서대로 살펴보겠습니다.

1. 새로운 카테고리를 만드는 비즈니스는 교육을 해야 한다

모든 제품은 두 가지 카테고리 중 하나에 속합니다. 기존 예산 항목에 맞춰 판매되는 제품과 새로운 예산 항목을 만들어야 하는 제품입니다.

만약 당신이 전자의 제품을 가진 스타트업이라면, 당신의 전략은 비교적 간단합니다. 당신의 제품은 더 나은 기능, 서비스 및/또는 절감된 비용으로 기존 제품을 능가해야 하며, 시장 진출(go-to-market) 팀은 소음을 뚫고 거래를 성사시키기 위해 마케팅 및 영업 전략을 구사해야 합니다.

만약 당신의 제품이 후자의 카테고리에 속한다면, 당신의 과제는 훨씬 더 까다롭습니다. 당신의 제품에 대한 예산 항목이 존재하지 않으므로, 하나를 만들어야 합니다. 잠재 고객사에서 챔피언, 즉 새로운 예산을 정당화하는 힘든 일을 하거나(상향식 접근 방식) 임원이 명령으로 예산 항목을 추가하도록(하향식 접근 방식) 할 사람을 육성해야 합니다. 제가 PlaceIQ에 있을 때, 우리는 두 가지 접근 방식을 모두 활용했습니다.

챔피언을 찾기 위해서는 새로운 카테고리를 마케팅하고, 그 가치를 정의하고 증명해야 합니다.

그리고 힘든 일은 예산 항목을 만들고 거래를 성사시킨 후에도 끝나지 않습니다. 이제 고객에게 제품 사용법을 가르쳐야 합니다. 간단한 제품의 경우, 이는 교과서적인 고객 성공 서비스처럼 보일 수 있습니다. 하지만 더 복잡한 제품, 특히 고객이 무언가를 만드는 데 사용하는 제품(AI API 등)의 경우, 이는 긴밀한 접촉이 필요한 컨설팅처럼 보입니다.

이것만으로도 충분히 어렵지 않다면, 성공에는 시간제한이 있습니다. 계약이 만료되기 전에 그들이 가치를 창출하도록 도와야 합니다.

OpenAI의 엔터프라이즈 제품은 명백히 이 두 가지 유형 중 후자에 속합니다. 그들과 모든 엔터프라이즈 AI 공급업체는 고객이 AI로 혁신적인 애플리케이션을 만들 것이라고 기대할 수 없습니다. 그들이 도와야만 합니다. 이것이 바로 새로운 '전방 배치 엔지니어(Forward Deployed Engineer)' 채용 공고가 많은 이유입니다.

2. AI는 개발 반복 속도를 높여 프로덕트 매니지먼트를 재편한다

AI가 프로덕트 매니지먼트 역할을 어떻게 재정의하는지 이해하기 위해, 먼저 AI 기반 코딩이 우리의 개발 주기를 어떻게 바꾸고 있는지 살펴보겠습니다.

물론, 표준적인 유의사항이 적용됩니다. AI 기반 코딩은 불균등하게 분포되어 있습니다. 많은 회사가 이러한 새로운 도구를 채택하는 데 느립니다. 많은 엔지니어들이 새로운 AI 개발 패턴을 탐색하고 배울 시간이나 동기가 없었습니다. 모델들은 특정 언어와 작업에는 뛰어나지만 다른 것들에는 서툽니다.

하지만, 제가 만나본 에이전트 시대(agentic era)에 제품을 만든 모든 스타트업은 다음을 보여줍니다.

• AI는 코딩을 더 빠르게 만듭니다. 저의 개인적인 경험과 관찰은 Simon의 의견과 일치합니다. "LLM이 컴퓨터에 코드를 입력하는 제 업무 부분에서 생산성을 2~5배 높여준다고 추정합니다. 이는 소프트웨어 엔지니어로서 제가 하는 일의 작은 부분일 뿐입니다."
• AI는 프로토타이핑을 더 빠르게 만듭니다. 제가 아는 AI를 수용한 프로덕트 매니저와 엔지니어들은 여러 페이지의 사양서 대신 프론트엔드 데모를 신속하게 개발할 것입니다. 우리가 Agile 시대에 배운 것처럼, 협력자, 고객, 사용자에게 반응할 수 있는 무언가를 제공하면 더 좋고 효율적인 피드백을 얻을 수 있습니다.
• 반복이 더 빠릅니다. 이는 앞선 두 항목의 결과입니다. 더 빠른 반복은 더 나은 제품을 만듭니다. 더 많이 출시하는 팀이 승리합니다.

더 많이 출시하면, 더 많이 배울 기회가 생깁니다. 개선 속도가 증가하고 더 빨리 앞서 나갑니다.

하지만 이 속도를 주도하는 것은 코딩입니다. 다른 모든 것은 AI로 인한 가속도가 훨씬 작거나 전혀 없습니다.

최근 Y Combinator Startup School에서 Andrew Ng는 이 역학 관계를 정확히 짚었습니다.

엔지니어들은 훨씬 빨라지고 있지만, 프로덕트 매니지먼트 작업, 즉 무엇을 만들지 설계하는 작업이 엔지니어와 같은 속도로 빨라지고 있다고 보지 않습니다. 저는 [프로덕트 매니지먼트 대 엔지니어링] 비율이 변하고 있는 것을 보고 있습니다.
말 그대로 어제, 저희 팀 중 하나가 인력 계획을 할 때 제게 왔습니다. 이 팀은 PM 1명당 엔지니어 4명이 아니라 PM 1명당 엔지니어 0.5명을 두자고 제안했습니다. 이 제안이 좋은 아이디어인지는 아직 모르겠지만, 세상이 어디로 가고 있는지를 보여주는 신호입니다. 그리고 저는 코딩을 할 수 있는 PM이나 제품 감각이 있는 엔지니어들이 종종 더 나은 성과를 낸다는 것을 발견했습니다.

코딩 속도가 빨라지면서, 제품(product)이 새로운 병목 현상이 되었습니다.

이제 팀들은 하이브리드, 즉 코딩할 수 있는 프로덕트 매니저와 제품 감각이 있는 엔지니어를 찾고 있습니다. '전방 배치 엔지니어(Forward Deployed Engineer)' 역할의 폭발적인 증가는 이를 증명합니다. FDE는 본질적으로 제품 지향적인 엔지니어로, 고객 문제를 이해하고 제품을 만들 수 있는 하이브리드입니다. 그들의 빠른 등장은 단지 새로운 카테고리를 가르치는 것에 관한 것이 아니라, 조직들이 이러한 이중 기술을 가진 역할로 끌리고 있다는 초기 증거입니다.

AI 연구소에서 FDE가 등장하는 것을 보고 있지만, 이러한 변화는 AI 제품을 만들든 AI로 강화된 개발 주기를 가진 전통적인 애플리케이션을 만들든, AI 기반 코딩을 활용하는 모든 소프트웨어 회사에 영향을 미칠 것입니다. 촉매제는 AI 제품 자체가 아니라, 제품 개발의 코딩 부분을 극적으로 가속화하는 AI 도구입니다. 이 매우 가치 있는 하이브리드를 도메인 전문가와 함께 배치함으로써, 빠른 반복 루프의 표면적을 넓힐 수 있습니다.

그렇다면 프로덕트 매니저는 사라질까요?

아닙니다. 빠르게 조립된 앱이나 기능을 견고한 서비스로 발전시키기 위해 해야 할 제품 관련 작업은 여전히 많습니다. 연구, 규정 준수, 영업 운영, 제품 마케팅 등이 그것입니다. 더 나아가, 한 고객을 위해 제품을 만드는 데 집중하는 FDE는 질적으로나 양적으로 더 큰 그림을 볼 시간이 없습니다. 그리고 만약 회사들이 속도에 과도하게 최적화하여 전통적인 프로덕트 매니지먼트 단계를 건너뛴다면, 결국엔 화를 입게 될 것입니다.

지난주 GPT-5 출시를 예로 들어보겠습니다. OpenAI는 GPT-4o의 어조에 정서적 애착을 갖게 된 수많은 화난 4o 사용자들을 관리해야 했습니다. ChatGPT를 아무리 분석하고 소비자 문의를 사용 사례별로 분류하더라도, 일부 사용자들이 4o를 친구처럼 여겼다는 사실은 놓쳤을 것입니다.

사라지기보다는, 저는 프로덕트 매니지먼트 기능이 두 가지 영역으로 양분될 것이라고 생각합니다.

• 애플리케이션 프로덕트 매니저 (Application Product Managers): 이 역할은 고객이나 파트너와 긴밀하게 협력하며, 종종 '하이브리드'입니다. 즉, 제품 지향적인 엔지니어나 코딩하는 프로덕트 매니저입니다. 그들은 도메인 전문 지식을 빠르게 흡수하고 이를 사용하여 제품과 기능을 신속하게 반복합니다. 이것은 프로덕트 매니지먼트와 엔지니어링이 고객 성공 및 컨설팅과 혼합된 형태입니다.
• 파운데이션 프로덕트 매니저 (Foundation Product Managers): 이 역할은 애플리케이션 프로덕트 매니저가 구축하는 기반이 되는 핵심 플랫폼을 만듭니다. 그들은 API, 데이터 구조, 핵심 비즈니스 로직을 설계합니다. 나아가, 이 핵심 팀들은 애플리케이션 프로덕트 매니저 팀이 개발한 혁신을 제품화하고, 규정 준수, 보안, QA 등을 처리합니다.

당연히 이 두 영역 간의 정의 정도는 회사의 규모와 제품의 성격에 따라 달라집니다. 하지만 이 구조는 AI 기반 개발의 속도, 전통적인 프로덕트 매니지먼트 기능의 필요성, 그리고 고객에게 제품 사용법을 가르쳐야 할 필요성을 모두 보존하려는 시도입니다.

하지만 대규모 조직에서는 전방 배치 엔지니어와 애플리케이션 프로덕트 매니저로 구성된 많은 소규모 팀(pod)이 있을 것입니다. 그들은 속도와 고객 효용에 최적화하고, 성공적인 혁신을 파운데이션 제품 팀에 넘겨주어 더 넓은 사용을 위해 준비하게 할 것입니다. FDE를 지원하는 핵심 플랫폼은 중앙 집중화되고 더 느린 파운데이션 팀에 의해 유지됩니다. 이 핵심 프로덕트 매니지먼트 팀들은 빠른 앱 팀과 다른 모든 것들 사이의 속도 차이를 효과적으로 조율할 것입니다.

AI 기반 개발에서 얻는 속도 향상과 기업에게 AI 기반 제품 사용법을 가르쳐야 할 필요성은 기술 회사들이 전방 배치 작업을 수용해야 함을 지시합니다. 프로덕트 매니지먼트는 더 빠른 엔지니어들을 지원하기 위해 진화해야 하며, 병목 현상이 되지 않고 조직이 안정적이고 안전한 제품을 출시하도록 도와야 합니다.

이러한 적응은 제가 위에서 설명한 분할처럼 보일 수도 있고, 전통적인 제품 작업에 속도 향상을 부여하는 새로운 AI 기반 도구의 채택처럼 보일 수도 있습니다. 현재로서는 전자에 기대를 걸고 있습니다.

Bottleneck or Bisect: AI-Assisted Coding Will Change Product Management

AI-assisted engineers can code 2-5x faster, but product management work hasn’t accelerated at the same pace. Rather than wait for traditional PM processes, organizations are empowering hybrid engineer-PMs, FDEs, to build directly with customers.

Drew BreunigDrew Breunig