AI Native PM으로 체질 개선해보기
들어가면서
링크드인을 스크롤하다 보면 요즘 AI 활용 사례가 넘쳐난다. 누군가는 Claude로 PRD를 뚝딱 만들고, 누군가는 Cursor로 코드를 짜고, 누군가는 에이전트 파이프라인을 설계해서 업무 시간을 반으로 줄였다고 한다.
2월에는 Figma Make를 써보면서 기획 중인 기능의 목업을 직접 만들었다. 텍스트로 프롬프트를 입력하면 인터랙티브 프로토타입이 나오는 경험이 꽤 실용적이었다. 기획자가 디자이너에게 "이런 느낌이요"라고 말로 설명하는 대신, 직접 돌아가는 목업을 먼저 만들어 공유했다. 피드백 싸이클이 달라졌다.
나름대로 효용을 체감하면서, 에이전트에도 도전해보고 싶어야지 생각했다. 매번 "나도 해봐야지" 했다. 그런데 평일은 스프린트가 돌아가고, 이해관계자 조율하고, 지표 들여다보다 보면 저녁이 됐다. 주말엔 쉬고 싶었다. 그렇게 조금씩 조금씩, 찜만 해두다가 실제로는 아무것도 만들지 못했다.
약간 FOMO가 오려던 찰나, 이번 연휴에 본격적으로 각을 잡았다. 회사에서 Claude API 계정을 열어주면서, 이를 활용한 자동화, 최적화를 지원해줬기에 가능했다.
그래서 3월에는 이전보다 한 발 더 나아가기 위해, PM 업무와 데이터 분석 업무 전반을 자동화할 수 있는 AI Agent 시스템을 직접 설계하고 구축했다. Claude Code를 기반으로 pm-studio와 da-studio라는 두 개의 에이전트 시스템이다. 오늘은 그 과정에서 느낀 점과 배운 점들을 정리했다.
ChatGPT만 사용하는 것은 AI Native PM이 아니다
테슬라 FSD 후기 영상을 보면, 많은 사람이 FSD를 켜놓고도 핸들에서 손을 못 뗀다. 여전히 기존 운전방식에 길들여진 탓에 카메라 8개, 뉴럴 넷, 수십억 마일의 학습 데이터가 차선을 읽고, 신호를 판단해도 애매하게 핸들을 잡는다. 아마 FSD가 보편화 된 시대에 태어난 친구들은, 자율주행 차 안에서 잠도 자고, 게임도 하고 이전보다 이 기술을 적극적으로 활용할 것 같다는 생각을 해봤다.
이런 관점에서 문득 나의 일하는 방식을 되돌아보게 되었다. 나 역시 도구로서의 AI는 활성화했지만, 일하는 방식만큼은 여전히 핸들에서 손을 못떼고 일하는게 아닐까 생각이 들었다. AI를 활용해 업무를 조금 더 빨리 끝내는 수준을 넘어, AI-Native 기업인 Anthropic이나 Cursor의 PM들처럼 일한다는 것을 고민해봤다.
그들이 일반적인 PM과 다른 결정적인 차이는 크게 두 가지다. 첫째, AI를 통해 기존 업무의 효율을 높이는 것을 넘어 전혀 새로운 가치(증분)를 창출해낸다는 것. 둘째, 이를 위해 업무 설계 단계부터 AI를 핵심 동료로 상정하고, '위임할 영역'과 '내가 집중할 판단의 영역'을 날카롭게 분리한다는 점이다.
우선, AI를 통해 기존 업무의 효율을 높이는 것을 넘어 전혀 새로운 가치(증분)를 창출해낸다는 것이다. 예를 들어 CRM 채널 성과 리포트를 만드는 데 기존엔 2~3시간이 걸렸다면, AI 활용 PM은 이걸 1시간으로 줄인다. AI Native PM은 다르다. 아예 파이프라인을 설계해서 CSV 파일을 넣으면 전처리·집계·시각화·리포트 초안이 자동으로 나오게 만들고, 절약된 2시간을 "어떤 질문을 할 것인가"에 쓴다. 같은 시간에 더 많은 채널을 커버하거나, 기존엔 엄두도 못 냈던 레드팀 분석을 추가한다. 효율의 문제가 아니라 할 수 있는 일의 종류가 달라지는 것이다.
또한, 이를 위해 업무 설계 단계부터 AI를 핵심 동료로 상정하고, '위임할 영역'과 '내가 집중할 판단의 영역'을 날카롭게 분리한다는 점이다. 데이터 수집, 집계, 초안 작성은 에이전트에게 완전히 넘긴다. 대신 "이 지표 하락이 구조적 문제인가, 일시적 노이즈인가"처럼 도메인 맥락이 없으면 틀리기 쉬운 판단에 집중한다. 또는 기회 우선순위 결정 등 전략적인 판단이 필요한 영역이나, AI의 산출물 제작과 의사결정 및 작업에 필요한 유의미한 컨텍스트를 식별하는 영역 등을 명확히 구분해야한다는 것이다.
실제 작업하면서 느낀 것들
1. 처음부터 잘 되진 않았다
여기서 '실패'의 정의는 에이전트가 아예 안 돌아가는 게 아니다. 쓸만한 산출물이 나오기까지 걸리는 시간이 너무 길어지는 것이다. 처음엔 일단 뭔가 돌아가는 걸 빠르게 만들려고 했다. 그런데 반복 활용을 고려하지 않고 만들면, 에이전트 간 역할이 겹치거나 출력 형식이 맞지 않아 결국 처음부터 다시 설계하게 됐다. 구조 없이 시작하면 구조 잡는 데만 시간이 더 걸리는 역설이다.
지금은 순서를 바꿨다. 실제로 내가 하는 작업, 반복적으로 쓸 작업을 먼저 특정하고 — Gemini Gem으로 에이전트 설계서를 먼저 작성한 다음 구조를 잡고 들어간다. 만들기 전에 설계서가 나오니, 에이전트 간 역할과 인터페이스가 훨씬 명확해졌다.
2. 하나의 산출물에 여러개의 서브 에이전트
PRD 하나를 만드는 데도, 단일 에이전트보다 역할을 나눈 서브 에이전트 조합이 결과물이 훨씬 낫다.
내가 만든 PRD 에이전트는 이렇게 구성된다. 2-Pager와 대화를 거쳐 PRD 초안을 만드는 오케스트레이터 아래, 세 개의 서브 에이전트가 붙는다.
requirement-writer: 기능 요구사항을 P0/P1 단위로 분류
ux-logic-analyst: 사용자 플로우를 분석하고 Mermaid 플로우 차트로 시각화
red-team: 요구사항의 허점과 미결 사항을 공격적으로 검토
시각화(Mermaid)를 별도 에이전트로 분리한 게 특히 효과적이었다. 플로우 차트를 텍스트 서술과 같은 에이전트에 묶어두면 둘 다 어중간해지는데, 분리하니 각각의 품질이 올라갔다. 또 하나 배운 것은, 에이전트 단위가 적당히 작아야 개선이 쉽다는 점이다. 결과물이 아쉬울 때 어느 에이전트의 문제인지 바로 짚을 수 있고, 그 에이전트만 수정하면 된다. 덩어리가 크면 어디가 문제인지 추적하는 것부터 다시 해야 한다.
3. 증분에 대한 고민 — 레드팀 문서와 GTM 생성기
에이전트를 단순히 기존 작업을 빠르게 하는 용도로 쓰는 것에서 한 발 더 나가고 싶었다. 원래라면 시간이 없어서 안 만들었을 것들을 만들어내는 것, 그게 진짜 증분이라고 생각했다.
레드팀 문서가 그 첫 번째다. PRD를 리뷰에 올리기 전, 늘 마음 한편에 "내가 놓친 게 있진 않을까"라는 불안이 있었다. 리뷰 중간에 예상 못한 질문이 튀어나오면 답변 준비로 에너지가 분산된다. 레드팀 에이전트는 이 불안을 사전에 해소해준다. PRD를 읽고 허점, 엣지 케이스, 이해관계자가 던질 법한 질문을 먼저 뽑아낸다. 특히 "이걸 왜 만들어야 하는가", "지표 설정이 목적과 정합하는가"처럼 PM이 스스로에게 가장 물어봐야 하지만 바쁠 때 흘려버리기 쉬운 질문들을 강제로 던지게 설계했다. 리뷰 자리에서 처음 듣는 날카로운 질문이 확연히 줄었다.
GTM 문서 생성기는 두 번째다. PRD와 2-Pager를 쓸 때 늘 겪는 어려움이 있다. 독자가 개발팀이냐 사업부냐에 따라 톤앤매너가 완전히 달라야 하는데, 두 버전을 각각 쓰는 건 현실적으로 잘 안 된다. 결국 어중간한 문서 하나가 나온다. GTM 생성기는 PRD 리뷰가 완료되면 그 내용을 읽어서, 사업부 전용 언어로 재구성한 GTM 브리프와 예상 FAQ를 자동으로 만들어준다. 기술 용어 없이, 사용자 가치와 비즈니스 임팩트 중심으로. 이건 기존 작업을 빠르게 한 게 아니다. 원래 만들지 못했던 문서가 생긴 것이다.
끝으로
아직 부족한게 많지만, 조금씩 필요한 영역에 적용해보고 고민해가다보면 조금 더 요즘 시대에 맞는 PM으로 진화하지 않을까 생각해본다. 그럼 이만
