## 핵심 요약
AI 시대에 PM의 업무 방식이 근본적으로 변화해야 한다는 문제의식에서 시작하여, Claude Code를 활용해 고객 문제 정의부터 프로토타입 개발까지 전 과정을 담당하는 서브 에이전트 시스템을 구상하고, 구축을 시도했습니다. Context Engineering과 체계적인 워크플로우 설계를 통해 AI와 PM이 협업하는 새로운 방법론을 실험하고 있습니다.
## 문제 정의: AI 시대 PM의 역할 변화
과거부터 B2B 영업, 어카운트 매니저, 사업개발, 프로젝트 매니저, 서비스 기획, 프로덕트 오너, 프로덕트 매니저 등 서비스를 만들고 비즈니스 가치를 창출하는 일을 해오면서 나름의 탁월한 PO/PM 방식을 정립해왔습니다. 다만, 지금까지 내가 배워온 방법론이 여전히 유효한지에 대해서는 강한 의문이 있습니다.
AI 시대에 PM이 일하는 방식이 바뀌어야 한다고 생각하고 있습니다. 커머스 업계에서 일하는 사람들의 업무를 자동화하듯이, PM의 업무 또한 (너무 당연히도) AI의 도움을 받을 영역이 있습니다.
핵심 질문: AI 시대, 그리고 커머스 버티컬 AI 에이전트를 만드는 회사의 PM은 어떻게 일해야 하는가? 기존 방식에서 무엇을 unlearn하고 무엇을 새롭게 learn해야 하는가?
## Claude Code 활용 실험 과정
### 1단계: PM 본질 업무 정의
Claude Code에 프로젝트를 열고 가장 먼저 한 일은 README.md 파일에 PM의 존재 목적과 탁월하게 해내야 하는 것, PM이 본질적으로 집중해야 할 가치와 AI에 위임 가능한 일이 무엇인지에 대한 생각을 정리했습니다.
### 2단계: 현재 PM 결과물 분석
노션에서 PM들이 프로젝트별로 작성하는 핵심 문서들을 다운로드받아 md 파일로 저장하고, Claude Code에게 이를 분석하도록 했습니다.
Claude Code에게 README 파일을 참고해서 PM이 본질적으로 해야 할 일과 그렇지 않은 일을 구분하도록 했고, 결과물 카테고리별로 PM이 본질적으로 해야 하는 일과 AI에게 위임해도 되는 일을 구분하도록 했습니다.
### 3단계: 워크플로우 정의 및 서브 에이전트 설계
현재 PM이 고객에게 제품과 서비스를 딜리버리하는 과정의 워크플로우를 정리했습니다. 이에 더하여 고객 가치를 전달하기 위해 필요한 단계를 추가하고, 큰 단계별로 에이전트들의 역할을 구분하여 각각을 md 파일로 정의해나가기 시작했습니다.
## 서브 에이전트 설계 원칙
### 1. 명확한 존재 목적 정의
각 에이전트가 어떤 목적을 달성하기 위해 존재하는지를 매우 명확하게 했습니다. 범용적인 PM 업무가 아니라 PM의 수많은 일 중 구체적인 한 가지를 탁월하게 해내도록 만드려 했습니다.
### 2. 탁월함의 수준 가이드
해당 서브 에이전트에게 기대하는 탁월함의 수준을 가이드하려고 했습니다. 아직 명확한 방법론은 구상 중입니다.
### 3. 명확한 Input/Output 정의
서브 에이전트가 만들어내야 할 결과물이 무엇인지, 해당 아웃풋을 도출하기 위해 필요한 인풋이 무엇인지를 명확히 정의했습니다. 서브 에이전트가 탁월한 결과물을 만들어내기 위해 Agent가 협업하는 사람 PM에게 어떤 인풋이 필요한지 가이드하고, 인풋이 부족할 경우 추가를 요청하도록 했습니다.
### 4. 팀 멤버로서의 역할
에이전트를 정말 나와 함께 일하는 여섯 번째 멤버처럼 만들고 싶었습니다. 사람에게 무엇을 해달라고 명확히 요청하고 가이드를 제공하듯, 개별 서브 에이전트에게도 기대사항, 고용 목적, 활용 정보, 결과물을 세세하게 조금의 오해도 없이 전달하길 바랐습니다.
## 구축한 서브 에이전트 시스템
### 1. 고객 문제 정의 에이전트
- 고객의 문제를 명확하게 정의하는 역할
### 2. 서비스 기획 에이전트
- PRD(Product Requirement Document)를 기능 단위로 명확한 완료 정의 기반으로 작성하는 역할
### 3. 데이터 요구사항 분석 에이전트
- 고객 요구사항 만족을 위해 필요한 데이터 정의
- 해당 데이터 획득 방법론 제안
- 현재 인핸스가 확보한 데이터로 충분한지 검토
### 4. 기술 설계 에이전트 (구상 중)
- 데이터 스키마 설계
- API 스펙 문서 작성
- 확보한 데이터를 비즈니스 로직에 따라 가공하는 과정 정의
### 5. 프로토타입 개발 에이전트
- 동작하는 프로토타입 제작
- 내부 메이커들에게 명확한 전달
- 고객에게 프로토타입을 보여줘 요구사항 구체화 및 확정
### 6. 프로젝트 관리 에이전트
- 마일스톤 설정 및 범위 확정
- 개발 일정 관리
- 개발 과정 리스크 및 블로커 해결
## Context Engineering 방법론
서브 에이전트가 원하는 결과물을 도출하기 위해서는 단순히 프롬프트를 잘 작성하는 것뿐만 아니라, 내가 알고 있는 수많은 맥락 지식들을 서브 에이전트에게도 제공하는 과정이 필수적입니다.
PM이 탁월한 성과를 내기 위해서는 프로젝트 관련 지식 외에도 회사의 분기 목표(OKR), 대표가 중요하게 생각하는 가치, 프로젝트를 진행하면서 유효했던 방법론과 유효하지 않았던 방법론 등의 맥락 정보가 필요합니다.
### Inbox 방법론 적용
옵시디언의 Inbox 방법론을 활용하여 프로젝트와 관련된 모든 정보를 raw 데이터와 함께 추가적인 맥락을 부여하여 Inbox에 저장하고, 이를 분석해서 개별 서브 에이전트들의 인풋 값으로 넣어주는 subagent 를 만들면 어떨까 생각했습니다.
생각을 Claude Code에게 공유헀더니, Input Processor 에이전트를 만들었습니다.
Input Processor subagent의 역할: "Inbox에 들어온 새로운 정보를 분석하여 여섯 개의 PM 에이전트들에게 필요한 내용을 각각의 에이전트 인풋 폴더에 자동으로 분류하고 업데이트하는 전문 에이전트입니다."
## Git 버전 관리 시스템 도입
Claude Code에게 다양한 요청을 하다 보니 버전 관리가 되지 않으면, 의도하지 않은 방향으로 동작했을 때 되돌릴 수 없을 것이라는 생각이 들었습니다. 모든 프로젝트와 마찬가지로 히스토리를 명확히 관리하고 문제 발생 시 과거 상태로 롤백할 수 있는 시스템이 중요했습니다.
유튜브에서 "코드깎는 노인"의 5분짜리 Git 버전 관리 강의 자료를 다운받아 Claude Code에게 넘기고, 해당 문서를 읽고 Git 버전 관리 시스템을 구축하도록 했습니다. 실제 개발한 것은 없었지만 시스템이 뚝딱 만들어졌습니다.
향후에는 프로젝트 관련 SSOT(Single Source Of Truth)가 Git이 될 것 같고, 서브 에이전트와 협력하면서 인풋과 아웃풋을 체인으로 생성해나가는 과정에서 노션이나 지라 같은 기존 PM 도구들이 무용해질 수도 있다는 생각이 들었습니다.
## 실험 과정에서의 주요 인사이트
### 1. 코드 이해 없이도 가능해진 구현
코드를 이해하지 못했다면 할 수 없었던 일들을 할 수 있게 되었습니다.
내 생각을 Claude Code의 도움을 받아 실현할 수 있다는 생각이 드니, 머리가 뺑뺑 돌아갔습니다. 무엇을 하고싶은지에 대한 명확한 생각이 점점 더 중요해질 것이라는 생각이 들었습니다.
### 2. 에이전트 간 소통 구조의 복잡성
Agent를 만드는 것에 대한 깊은 이해가 없는 상태에서, 나의 생각만으로 Agent의 존재 목적, input/output 정의, 기대수준 부여, Context 제공만으로 원하는 동작 을 할지 의문입니다. 구글의 A2A와 같은 Agent 간 통신 프로토콜 같은 복잡한 개념을 도입해야 기대하는 Agent 간 소통 구조를 만들 수 있을지 궁금합니다.
### 3. 솔루션의 복잡성 문제
Claude Code에게 요청했을 때, 너무 장황하고 복잡하게 솔루션을 제안하는 경향이 있는 것 같습니다. 내가 이해하지 못하는 솔루션은 실행 불가하고, 너무 복잡한 솔루션은 마찰이 커서 지속 가능하지 않습니다.
Claude Code에게 무언가를 요청한 뒤, 핵심 중심으로 간략하게 만들어달라는 요청을 매번 반복했습니다.
### 4. 실제 프로젝트 검증의 필요성
실제 새로운 프로젝트 기반으로 PM과 PM 에이전트들이 협력하는 과정을 통해 어떤 결과물을 만들어낼 수 있을지 궁금합니다. 기존 프로젝트 데이터로 검증하는 것은 효용이 없을 것 같습니다. 이미 결과물을 알고 있으므로 어떻게든 원하는 결과물이 나오도록 추가적인 정보와 맥락을 계속 제공할 것 같기 때문입니다.
시스템이 잘 구축되면 대표에게 제안해서 새로운 프로젝트의 End-to-End를 나와 서브 에이전트들이 진행할 수 있도록 하는 의사결정을 받아내면 좋겠습니다.
### 5. 선택의 어려움
실제 아이디어를 Claude Code에게 요청하고 구현하는 과정보다 더 힘들었던 것은, Claude Code가 만들어낸 결과물들 중에서 어떤 것들을 취하고 어떤 것들을 취하지 말아야 할지를 결정하는 일이었습니다. 처음에는 Claude Code가 제안하는 수많은 복잡한 방법론들을 그대로 모두 개발하도록 했지만, 내가 이해하지 못하는 방식으로 서브 에이전트들이 동작하는 상황에 이르게 되었습니다. 결국 Claude Code에게 내 생각의 본질과 핵심만을 남기고 모든 내용들을 재검토해달라는 요청을 할 수밖에 없었습니다.
### 6. PM 업무의 명확한 구획화
서브 에이전트를 만들어나가는 과정에서 실제 PM이 일하는 과정에 대해 PM인 내가 구획을 명확히 하는 과정이 필수적이었습니다. Claude Code에게 단순히 "PM의 업무를 보조하는 서브 에이전트"를 만들어달라고 했다면 실제 회사의 PM이 일하는 방식과 맞아떨어지지 않았을 수도 있습니다.
에이전트의 성능을 높이는 방법론을 찾아보니, 작은 업무를 명확하게 분리하는 것이 에이전트가 목적한 대로 동작하는 좋은 방법 중 하나였습니다. 의도치 않게 PM이 하는 역할들을 5-6단계로, 누가 들어도 이해할 수 있을 수준으로 명확하게 정의하게 되었습니다.
### 7. 맥락 제공 방식의 고민
옵시디언에서 문서를 작성하는 방식대로 일단 새롭게 만들어진 모든 문서를 Inbox에 때려 넣고 나중에 분류하는 방식으로 에이전트들에게 필요한 맥락과 인풋을 제공하는 방법을 사용하려고 합니다. 나한테는 매우 익숙하고 편한 방식이지만 실제 Input Processor 에이전트가 이를 자동으로 얼마나 잘 수행해줄지 모르겠습니다.
회의록 트랜스크립트, 고객에게서 받은 요구사항 문서, 내부 회의록 등의 로그 파일을 있는 그대로 다 때려박았을 때 과연 에이전트가 필요한 맥락들과 정보들을 제대로 수집할 수 있을까요? 아니면 그러한 raw 정보들에 대한 맥락을 제공해야 할까요? 제공해야 한다면 어디까지 구체적으로 정보를 큐레이션해서 에이전트들에게 제공해야 하는지가 고민입니다.
## 다음 단계
이 스터디를 진행하는 과정에서 한 주에 하나씩 해당 에이전트들을 더 구체화해나가는 과정을 진행해보고자 합니다. 어떻게 하면 해당 에이전트들이 내가 목적하는 기대
수준의 결과를 제공해 줄 수 있을지 모르겠지만, 실제 탁월한 아웃풋을 제공하기 위해 필요한 인풋들을 넣었을 때 정말 어떤 아웃풋이 나오는지에 대해서 지속적으로 실험해나가면서 고도화할 수밖에 없다고 생각합니다.
참고한 자료
