PM이 사라지고 있다: AI 네이티브 스타트업의 개발팀 구조 변화 (id.news.hada.io)
목차(4)
한줄 요약
AI 네이티브 스타트업에서 PM 역할이 소멸하고, 엔지니어가 고객·제품·실행을 통합 장악하는 구조가 표준이 되고 있다.
AI 도구의 실행 비용이 사실상 0에 수렴하면서, 소프트웨어 개발 조직의 역할 분업 구조 자체가 흔들리고 있다. 샌프란시스코의 AI 네이티브 스타트업들을 직접 방문해 관찰한 결과, 기존 스타트업과는 근본적으로 다른 운영 모델이 이미 현장에서 작동하고 있다는 보고가 나왔다.
무엇이 달라지나?
PM이 없는 팀이 기본값이 되고 있다
방문한 5개 기업 중 PM을 별도로 두고 있는 곳은 단 1곳이었다. 40명 규모 회사도 예외가 아니었다. 엔지니어가 매일 고객과 직접 소통하고, 제품 결정을 처음부터 끝까지 단독으로 책임지는 구조다. PM 역할이 '지원'을 받는 것이 아니라, 그 역할 자체가 엔지니어링과 디자인 안으로 흡수되어 버린 형태다.
이는 단순히 인력 효율화가 아니다. 실행 속도가 극단적으로 빨라지면서, 전통적인 PM의 핵심 기능이었던 '우선순위 판단'과 '고객 인사이트 수집'을 엔지니어가 AI 도구를 통해 직접 수행할 수 있게 된 결과다.
실험 속도가 3~5배 빨라진다
한 연구자는 10가지 UI 디자인을 각각 하루씩 테스트하고 9개를 버리는 방식으로 실험을 진행했다. 코딩 경험이 전혀 없는 Growth PM은 이틀 만에 전체 Meta Ads 파이프라인을 직접 구축했다. 디자이너는 6분 안에 여러 버전의 경쟁 시안을 만들어냈다.
속도 향상은 두 가지 형태로 나타난다. 하나의 실험을 더 빨리 끝내서 같은 기간 안에 더 많은 실험을 돌리는 것, 그리고 여러 실험을 동시에 병렬로 실행하는 것. 이 두 효과가 복합적으로 작용하면서 조직 전체의 학습 속도가 기하급수적으로 올라간다.
Slack이 에이전트 오케스트레이션의 중심이 됐다
방문 기업 대부분이 동일한 코어 스택을 사용하고 있었다. Slack, Claude Code, GitHub, Codex, Linear가 그것이다. 주목할 점은 Slack의 역할 변화다. 이모지 반응으로 자동 티켓이 생성되고, 봇이 고객 이슈를 분류·진단하며, 스레드에서 에이전트를 태그하면 즉시 수정 작업이 시작된다. Slack이 단순한 커뮤니케이션 툴에서 에이전트 실행 레이어로 진화한 것이다.
6개월 전만 해도 모든 대화에서 언급되던 Cursor는 이제 거의 등장하지 않는다. 엔지니어들은 Claude Code 안에서 거의 모든 작업을 처리하고 있으며, 툴에 대한 충성도나 애착이 거의 없다는 점이 코딩 플랫폼 전반에 위협 요소로 지적되고 있다.
실무에서 어떤 의미인가?
'피처 팩토리' 함정이 가장 큰 위협이다
무엇이든 하루 안에 만들 수 있게 되면서, 모든 고객 요청을 바로 구현하려는 충동이 커진다. 방문 기업들 상당수가 이를 현재 자신들이 직면한 가장 큰 전략적 위험으로 꼽았다.
이 문제를 통제하는 방식은 기업마다 다르다. 한 회사는 에이전트가 기존 기능의 JSON 설정값만 수정할 수 있도록 제한하고, 새 코드 생성 자체를 차단했다. 다른 회사는 스쿼드별 North Star 지표를 설정해 출시 전에 아이디어를 걸러낸다. 공통적으로는 창업자가 직접 '우리가 고집할 영역'과 '유연하게 대응할 영역'을 명확하게 구분해두는 것이 필수로 언급됐다.
실행 비용이 0에 가까워지면 취향(taste)이 해자(moat)가 된다. 하지만 그 취향을 조직 차원에서 어떻게 제도화할 것인가는 아직 답이 정해지지 않은 문제다.
엔지니어 외 모든 직군이 변한다
엔지니어에게 AI가 무엇을 해주는가보다, 엔지니어가 아닌 사람들에게 무엇을 해주는가가 더 과소평가된 변화라는 시각이 현장에서 나온다.
엔터프라이즈 어카운트 매니저가 몇 달째 개발팀에 요청해도 우선순위에서 밀리던 자동화 작업을 Slack 에이전트에게 요청해 1시간 만에 해결했다. 회계팀은 직접 데이터베이스 쿼리를 작성해 비즈니스 데이터를 분석한다. Chief of Staff는 30분 이내에 다이렉트 메일과 마케팅 자료를 완성한다. 비개발 직군의 실행 가능 범위가 근본적으로 바뀌고 있다.
도입 전 체크포인트
AI 내재화를 검토하는 팀이라면 다음 질문을 먼저 점검해야 한다.
- 우리 팀에서 PM이 수행하는 역할 중 고객 인사이트 수집과 우선순위 판단 비중은 얼마나 되는가?
- 엔지니어가 고객과 직접 소통할 준비가 되어 있는가, 아니면 구조적 장벽이 있는가?
- 실행 속도가 빨라졌을 때 '무엇을 안 만들지' 결정하는 기준이 조직에 존재하는가?
- 비개발 직군이 AI 도구를 직접 사용할 수 있는 환경이 갖춰져 있는가?
- 에이전트를 통합할 경우 Slack 등 기존 커뮤니케이션 채널의 역할 재정의가 필요한가?
AI 전략을 '논의'하고 있는 조직과 이미 내재화해 운영하는 조직 사이의 격차는 매주 벌어지고 있다. 늦게 시작할수록 따라잡는 데 드는 비용은 비선형적으로 증가한다.
자주 묻는 질문
Q.AI 네이티브 스타트업에서 PM 역할이 사라지면 제품 방향성은 누가 결정하나?
현장 관찰 결과, 엔지니어가 고객과 직접 소통하며 제품 결정을 전담하는 구조로 전환되고 있다. PM의 기능이 사라진 것이 아니라 엔지니어링과 디자인 역할 안으로 통합된 것이다. 다만 이 구조가 작동하려면 창업자 또는 리드 엔지니어가 제품의 방향성과 경계선을 명확하게 설정해두는 것이 전제 조건으로 지목된다. 이 전제 없이 속도만 올리면 피처 팩토리 함정에 빠질 위험이 커진다.
Q.Claude Code가 Cursor를 빠르게 대체하고 있는 이유는 무엇인가?
6개월 전까지만 해도 거의 모든 팀에서 언급됐던 Cursor가 현재는 거의 등장하지 않는다는 현장 관찰이 있었다. 엔지니어들이 Claude Code 안에서 대부분의 작업을 처리하면서 별도의 코딩 창이 필요 없어진 것으로 보인다. 코딩 툴에 대한 엔지니어의 충성도 자체가 매우 낮다는 점도 주목할 부분이다. 모델 학습 데이터를 확보하지 못하는 플랫폼은 장기적인 경쟁력 유지가 어렵다는 분석도 나온다.
Q.실험 비용이 0에 가까워지면 오히려 조직 혼란이 생기지 않나?
실제로 이것이 현장에서 가장 큰 전략적 위험으로 지목됐다. 무엇이든 하루 안에 만들 수 있다는 사실이 오히려 모든 요청을 구현하려는 충동을 키운다. 성공적으로 통제한 팀들은 에이전트의 행동 범위를 사전에 제한하거나, 스쿼드별 핵심 지표로 필터링하는 방식을 사용했다. 실행 비용이 낮아질수록 '무엇을 만들지'보다 '무엇을 만들지 않을지' 결정하는 기준이 더 중요해진다. 📌 원문: [GeekNews](https://id.news.hada.io/topic?id=28879) 🔗 새로운 기술 도입이나 기술 검토가 필요하다면 → [삼태연구소에 문의하기](/contact)