PRD부터 경쟁사 리서치까지, PM이 AI 에이전트로 일하는 법

PM이 AI를 초안 작성기로만 쓰면 아쉬운 이유

안녕하세요? 오늘 다룰 주제는 서비스 기획자, PM, PO가 AI를 단순한 “초안 작성기”가 아니라 기획 업무 에이전트로 활용하는 방법입니다. 이미 많은 실무자가 ChatGPT나 Gemini로 회의록을 요약하고, PRD 초안을 만들고, 이메일 문장을 다듬고 있습니다. 그런데 여기서 한 단계 더 나아가면 AI는 문서 한 건을 만드는 도구가 아니라, 업무 흐름 전체를 이어주는 보조 운영체제처럼 쓰일 수 있습니다.

기획 업무는 사실 “글쓰기”보다 “맥락 연결”에 가깝습니다. 사용자 인터뷰에서 나온 문제, 경쟁사 릴리즈 노트, 회의에서 합의된 액션아이템, 개발 일정의 지연 신호, 고객 문의에서 반복되는 불만을 연결해야 좋은 제품 판단이 나옵니다. 그래서 AI 활용의 핵심도 “PRD를 예쁘게 써줘”에서 끝나면 안 됩니다. 더 중요한 질문은 “이 AI가 내가 가진 자료를 읽고, 빠진 쟁점을 찾고, 다음 행동까지 추적하게 만들 수 있는가?”입니다.

이 글을 읽으면 AI를 PM 실무에 적용할 때 무엇을 자동화하고, 무엇은 여전히 사람이 판단해야 하는지 구분할 수 있습니다. 또한 ChatGPT, Gemini, Perplexity 사례를 통해 AI 도구들이 어떤 방향으로 “기획 업무 에이전트화”되고 있는지도 이해할 수 있습니다.

AI 기획 에이전트란 무엇인가

AI 초안 작성기는 입력한 프롬프트에 맞춰 문서 한 건을 만들어주는 도구입니다. 예를 들어 “구독 결제 기능 PRD 초안을 써줘”라고 요청하면 목적, 요구사항, 지표, 예외 케이스를 어느 정도 정리해줍니다. 이것만으로도 분명히 유용하지만, 실제 PM 업무에서는 그 문서가 어디서 왔고, 어떤 회의에서 바뀌었고, 어떤 경쟁사 기능과 비교해야 하는지가 더 중요합니다.

반면 AI 기획 에이전트는 한 번의 산출물보다 반복 업무의 흐름에 초점을 둡니다. 예를 들어 고객 인터뷰 파일을 요약하고, 기존 PRD와 충돌하는 요구사항을 찾고, 회의록에서 액션아이템을 뽑고, Jira나 Linear 같은 이슈 관리 도구의 지연 항목을 정리하고, 다음 주 회의 전까지 확인할 리스크를 알려주는 식입니다.

OpenAI 문서에서도 이런 방향은 일부 확인됩니다. ChatGPT의 앱 기능은 외부 도구와 정보를 대화 안에서 활용하도록 설계되어 있고, 검색, 딥 리서치, 동기화, 쓰기 액션 같은 기능을 제공할 수 있습니다. 다만 실제 사용 가능 여부는 앱, 플랜, 지역, 워크스페이스 설정에 따라 달라질 수 있다고 안내되어 있습니다.

이 차이를 PM 관점에서 바꾸어 말하면 이렇습니다. 초안 작성기는 “문서 작성 시간을 줄이는 도구”입니다. 기획 에이전트는 “제품 운영의 반복 루프를 줄이는 도구”입니다.

최근 공식 발표에서 보이는 변화

최근 공식 자료들을 보면 주요 AI 제품들이 단순 챗봇에서 업무 맥락을 다루는 방향으로 이동하고 있다는 점이 보입니다. OpenAI는 2026년 5월 5일 ChatGPT 메모리 개선을 발표하면서, Plus·Pro 사용자에게 과거 대화, 저장된 메모리, 사용 가능한 경우 파일과 연결된 Gmail 앱의 맥락을 더 잘 활용해 더 개인화된 아이디어, 추천, 다음 단계를 제공한다고 설명했습니다.

이는 PM에게 꽤 중요한 변화입니다. 기획자는 같은 제품, 같은 지표, 같은 이해관계자, 같은 제약 조건을 반복해서 다룹니다. AI가 과거 대화와 프로젝트 파일, 메일 맥락을 참고할 수 있다면 “지난번 논의했던 결제 실패 케이스 기준으로 이번 PRD의 빠진 부분을 찾아줘” 같은 요청이 더 자연스러워집니다. 다만 메모리와 앱 연결은 사용자 통제, 플랜, 지역, 조직 설정의 영향을 받으므로 “모든 조직에서 바로 가능하다”고 단정하면 안 됩니다.

Business·Enterprise 영역에서는 Workspace Agents 흐름도 주목할 만합니다. OpenAI 문서 기준으로 ChatGPT Workspace Agents는 반복 업무와 워크플로를 위한 에이전트를 만들고, 앱과 도구에 연결하고, 워크스페이스에 공유하고, Slack에서 사용하거나 일정에 따라 실행할 수 있도록 설명됩니다. Enterprise 워크스페이스에서는 출시 시점에 기본적으로 꺼져 있으며, 관리자가 적격 워크스페이스에서 활성화해야 한다는 점도 함께 확인됩니다.

Google 쪽에서는 Gemini Deep Research Agent와 Gemini Enterprise 발표가 좋은 비교 사례입니다. Gemini Deep Research Agent는 현재 preview 상태이며, 복잡한 다단계 조사 작업을 자율적으로 계획·실행·종합해 인용이 포함된 보고서를 만드는 에이전트로 설명됩니다. Google 문서는 이 작업이 반복 검색과 읽기를 포함하기 때문에 몇 분이 걸릴 수 있고, background execution으로 실행해야 한다고 안내합니다.

또한 Google Cloud는 2026년 4월 23일 Gemini Enterprise 관련 발표에서 Agent Designer, Projects, Inbox, long-running agents 같은 개념을 제시했습니다. 특히 Agent Designer는 자연어 또는 시각적 인터페이스로 에이전트를 만들 수 있게 하고, Inbox는 장기 실행 에이전트 활동을 모니터링·관리하는 중심 공간으로 설명됩니다. 다만 해당 글은 새 기능이 “향후 몇 달 동안” 고객에게 출시될 예정이라고 안내하므로, 실제 사용 가능 여부는 조직별로 확인해야 합니다.

Perplexity의 경우는 명칭을 특히 조심해야 합니다. Perplexity는 2025년 7월 9일 Comet을 AI 네이티브 브라우저로 소개했고, 2026년 2월 25일 공개 자료 기준으로 Perplexity Computer를 전체 워크플로를 생성·실행하는 범용 디지털 작업자 성격의 시스템으로 설명했습니다. 따라서 프로젝트 브리프 작성, 여러 탭 리서치 요약, 워크플로 자동화 사례를 말할 때는 그것이 Comet의 브라우저/탭 맥락 기능인지, Computer의 멀티스텝 워크플로 실행인지 구분해서 써야 합니다.

왜 PM·PO 업무에 중요한가

PM 업무는 “정답을 만드는 일”보다 “불확실성을 줄이는 일”에 가깝습니다. 새로운 기능을 만들 때 PM은 고객 문제, 사업 목표, 개발 리소스, 디자인 제약, 경쟁사 동향, 출시 일정, 운영 리스크를 한 번에 봐야 합니다. 이때 AI가 단순히 문장을 잘 쓰는 수준에 머문다면 도움은 되지만 영향 범위는 제한됩니다.

반대로 AI가 자료를 찾아 연결하고, 반복적으로 상태를 확인하고, 문서와 회의 사이의 불일치를 찾아준다면 업무 방식 자체가 달라질 수 있습니다. 예를 들어 릴리즈 노트 기반으로 경쟁사 제품 변화를 매주 정리하고, 그중 우리 로드맵과 겹치는 기능만 표시하고, 다음 스프린트 플래닝 전에 확인할 질문을 만들어주는 방식입니다.

Google의 Gemini Deep Research Agent는 표준 Gemini 모델과 비교해 지연 시간은 초 단위가 아니라 분 단위이고, 과정도 단순 생성이 아니라 계획→검색→읽기→반복→출력 흐름이라고 설명됩니다. 대신 결과물은 상세 보고서, 장문 분석, 비교표에 적합하며 시장분석, due diligence, 문헌 리뷰, 경쟁 환경 분석에 적합하다고 정리되어 있습니다. PM에게 이 차이는 중요합니다. 빠른 문장 다듬기는 일반 모델로 충분하지만, “시장 진입 전략을 위해 경쟁사 8곳의 가격 정책과 최근 기능 출시를 비교해줘” 같은 일은 리서치형 에이전트가 더 맞을 수 있기 때문입니다.

결국 PM의 AI 활용 성숙도는 “얼마나 멋진 프롬프트를 쓰는가”보다 “어떤 반복 업무를 하나의 흐름으로 설계했는가”에 달려 있습니다.

PRD부터 이슈 추적까지, 실제로 어떻게 연결할까

가장 먼저 적용하기 쉬운 영역은 PRD 초안 작성입니다. 예를 들어 “결제 실패율을 낮추기 위한 재시도 UX 개선 PRD를 작성해줘”라고 요청할 수 있습니다. 하지만 기획 에이전트 방식이라면 여기에 한 단계 더합니다. 고객 문의 로그, 이전 회의록, 실패 케이스 분석 파일, 경쟁사 결제 UX 리서치 결과를 함께 제공하고 “중복 요구사항, 빠진 엣지 케이스, 개발팀에 확인할 질문을 분리해줘”라고 요청하는 식입니다.

두 번째는 경쟁사 기능 비교표입니다. Gemini Deep Research Agent 문서의 예시처럼 경쟁 환경 분석은 깊은 조사형 에이전트에 적합한 업무입니다. Google 문서는 Deep Research Agent가 기본적으로 Google Search, URL Context, Code Execution 같은 도구를 사용할 수 있다고 설명합니다. PM은 이를 활용해 “A, B, C 경쟁사의 온보딩, 가격 정책, 권한 관리, 리포팅 기능을 비교하고 우리 제품에 영향을 줄 신호를 분류해줘” 같은 형태로 조사 질문을 설계할 수 있습니다.

세 번째는 사용자 인터뷰 요약입니다. 단순 요약에 그치지 말고 “불만, 니즈, 해결 시도, 구매 의사, 기능 요청, PM이 후속 확인해야 할 질문”처럼 분류 기준을 정해두면 더 좋습니다. 이 기준을 프로젝트별 템플릿으로 저장해두면 같은 방식으로 인터뷰 노트를 계속 처리할 수 있습니다.

네 번째는 회의록 액션아이템 추출입니다. 회의록을 넣고 “결정사항, 미결 쟁점, 담당자, 마감일, 다음 회의에서 확인할 질문”을 뽑게 하면 회의 후 정리 시간이 줄어듭니다. OpenAI의 Business release notes에서도 Slack 앱을 통해 긴 스레드를 액션아이템으로 요약하고, 접근 가능한 메시지와 파일을 검색할 수 있는 흐름이 소개되어 있습니다.

다섯 번째는 일정 지연 이슈 정리입니다. 작업 관리 도구의 이슈 목록, 캘린더 일정, 회의록을 함께 보게 하고 “이번 주 출시 리스크가 있는 항목만 정리해줘”라고 요청할 수 있습니다. ChatGPT Workspace Agents처럼 일정 실행이나 Slack 채널 사용이 가능한 에이전트 기능은 이런 반복 점검 업무와 잘 맞습니다. 다만 실제 앱 연결과 스케줄 실행 가능 여부는 플랜·관리자 설정에 따라 달라질 수 있습니다.

여섯 번째는 릴리즈 노트 기반 제품 변화 추적입니다. 경쟁사 릴리즈 노트, 공식 블로그, 가격 페이지 변경 사항을 정기적으로 확인하고 “우리 제품의 로드맵과 충돌하거나 기회가 될 변화”만 요약하게 만들 수 있습니다. Perplexity의 공식 활용 사례에서는 기술 조직 대상으로 기능 출시, 가격 변경, 엔지니어링 블로그를 추적해 주간 브리핑으로 요약하는 경쟁 시장 분석 사례가 제시됩니다.

AI 초안 작성기 vs AI 기획 에이전트

아래 표는 PM 실무에서 두 접근법이 어떻게 다른지 정리한 것입니다.

이 표에서 중요한 부분은 “AI 기획 에이전트가 PM을 대체한다”가 아닙니다. 오히려 반대입니다. PM이 더 명확한 기준을 세워야 AI가 제대로 움직입니다. 어떤 자료를 신뢰할지, 어떤 지표를 우선할지, 어떤 결정은 사람이 승인해야 할지 정하지 않으면 에이전트는 단지 빠르게 움직이는 혼란이 될 수 있습니다.

Perplexity의 Comet Assistant 관련 공식 글도 비슷한 맥락에서 투명성, 사용자 통제, 민감한 행동 전 허가를 핵심 원칙으로 설명합니다. 에이전트가 강력해질수록 “무엇을 할 수 있느냐”보다 “어디까지 맡기고 어디서 멈추게 할 것이냐”가 더 중요해집니다.

도구별 활용 포인트: ChatGPT, Gemini, Perplexity

ChatGPT는 PM의 개인화된 업무 맥락을 쌓아가는 도구로 볼 수 있습니다. 공개 자료 기준으로 ChatGPT는 과거 대화, 저장된 메모리, 사용 가능한 경우 파일과 Gmail 앱 맥락을 활용해 더 맞춤화된 응답과 다음 단계를 제안하는 방향으로 발전하고 있습니다. Business·Enterprise 환경에서는 앱과 커넥터, 회사 지식, Workspace Agents가 결합되며 조직 단위의 반복 업무 자동화 가능성이 커집니다. 다만 Business에서는 앱이 기본 활성화되고 Enterprise/Edu에서는 기본 비활성화될 수 있다는 식의 차이가 있어 관리자 설정 확인이 필요합니다.

Gemini는 깊은 리서치와 조직형 에이전트 관리 흐름에서 참고할 만합니다. Gemini Deep Research Agent는 빠른 답변보다 상세 조사에 초점을 둔 에이전트이고, Google은 비용도 일반 채팅 요청과 달리 계획, 검색, 읽기, 추론 루프에 따라 달라진다고 설명합니다. Preview 요금 기준으로 일반 Deep Research 작업은 약 1~3달러, Deep Research Max는 약 3~7달러의 추정 비용을 예시로 제시하지만, 이 수치는 preview rate 기준이며 변경될 수 있다고 명시되어 있습니다. PM이 이 도구를 쓴다면 “한 문단 요약”보다 “시장 구조를 조사하고 비교표와 근거를 만들어야 하는 업무”에 배치하는 편이 자연스럽습니다.

Perplexity는 브라우저와 리서치 워크플로 관점에서 볼 수 있습니다. Comet은 브라우징 세션을 대화형 워크플로로 바꾸고, 회의 예약이나 이메일 발송 같은 행동을 요청할 수 있는 흐름으로 소개되었습니다. Comet Help Center에서는 여러 열린 탭을 프로젝트나 논문 단위로 그룹화·태그·요약하는 연구 관리, 폼 입력이나 워크플로 실행 같은 작업 자동화 사례도 제시합니다. 반면 Perplexity Computer는 공개 자료 기준으로 하위 에이전트를 생성해 웹 조사, 문서 생성, 데이터 처리, 연결 서비스 API 호출 등을 병렬적으로 수행할 수 있는 시스템으로 설명됩니다.

흥미로운 것은 Perplexity의 Rho 고객 사례입니다. 해당 사례에서는 제품 개발팀의 정보가 Notion, Jira, Figma, Slack, Google Docs, 녹화 회의 등에 흩어져 있었고, Perplexity Computer를 활용해 Figma, Notion, Jira를 확인하여 결정사항, 요구사항 불일치, 최근 24시간 변경사항을 Slack에 일일 보고하도록 한 예시가 소개됩니다. Perplexity는 이 사례에서 주간 회의 시간이 2.5시간에서 15분으로 줄어 90% 감소했고, 12주 동안 120시간을 절감했다고 설명합니다. 다만 이는 특정 고객 사례이므로 모든 조직에서 같은 효과가 난다고 일반화하면 안 됩니다.

한계와 확인이 필요한 부분

가장 큰 한계는 기능 제공 범위가 계속 바뀐다는 점입니다. 앱 연결, 메모리, Gmail·Calendar·Drive 접근, Workspace Agents, Slack 실행, 스케줄 실행, 조직 계정 지원 여부는 플랜, 지역, 관리자 정책, 베타 여부에 따라 달라질 수 있습니다. OpenAI 문서도 앱 기능이 플랜·지역에 따라 달라질 수 있고, 일부 기능은 특정 플랜에서만 가능하다고 안내합니다.

두 번째 한계는 에이전트가 더 많은 자료에 접근할수록 보안과 정확성 리스크가 커진다는 점입니다. Gemini Deep Research Agent 문서는 웹과 개인 파일 접근을 허용할 때 프롬프트 인젝션, 악성 웹 콘텐츠, 민감 데이터 유출 위험을 고려해야 하며, 응답에 포함된 인용을 검토하라고 권고합니다. PM 입장에서는 “AI가 찾아온 근거를 그대로 믿지 않는 검증 루프”가 필수입니다.

세 번째 한계는 자동화가 곧 좋은 판단을 의미하지 않는다는 점입니다. AI는 회의록에서 액션아이템을 뽑을 수 있지만, 그 액션이 제품 전략상 중요한지 판단하는 것은 PM의 몫입니다. 경쟁사 기능 비교표를 만들 수 있지만, 우리 제품에 적용할지 말지는 고객 세그먼트, 수익 모델, 기술 부채, 브랜드 전략을 보고 결정해야 합니다.

네 번째는 Perplexity처럼 제품명이 빠르게 늘어나는 경우입니다. Comet, Comet Assistant, Comet Enterprise, Perplexity Computer, Computer for Enterprise 같은 명칭이 함께 등장하므로, 블로그나 내부 문서에서 기능 사례를 인용할 때는 반드시 공식 문서 기준으로 어느 제품의 기능인지 확인해야 합니다. Perplexity의 2026년 3월 13일 changelog는 Computer가 Pro 구독자, Enterprise Max 및 Pro 구독자에게 제공되고 Slack 통합과 400개 이상 애플리케이션 연결을 설명하지만, 출시 초기 블로그의 제공 범위와는 다르게 업데이트된 내용이므로 날짜 기준 확인이 필요합니다.

PM이 지금부터 봐야 할 시사점

첫 번째 시사점은 PM의 생산성이 “문서 작성 속도”에서 “업무 루프 설계 능력”으로 이동한다는 점입니다. 앞으로 좋은 PM은 AI에게 PRD를 한 번 쓰게 하는 사람이 아니라, PRD 작성에 필요한 입력 자료를 어떻게 모으고, 어떤 기준으로 비교하고, 어떤 후속 작업을 자동으로 추적할지 설계하는 사람이 될 가능성이 큽니다.

두 번째 시사점은 기획 산출물이 더 자주 업데이트되는 형태로 바뀔 수 있다는 점입니다. 예전에는 PRD를 한 번 작성하고 회의 때마다 사람이 업데이트했습니다. 이제는 회의록, 이슈 변경, 릴리즈 노트, 고객 문의를 에이전트가 정기적으로 요약해 “살아있는 PRD”처럼 관리할 수 있습니다. 물론 최종 반영과 승인 책임은 PM에게 남아야 합니다.

세 번째 시사점은 리서치 업무의 단위가 바뀐다는 점입니다. 예전에는 경쟁사 리서치를 분기마다 한 번 크게 했다면, 이제는 릴리즈 노트, 가격 페이지, 채용 공고, 개발자 문서 변경을 주기적으로 추적해 작은 신호를 계속 모을 수 있습니다. Gemini Deep Research Agent나 Perplexity의 경쟁 분석 사례는 이런 반복 리서치 흐름을 PM 업무에 적용할 수 있음을 보여줍니다.

네 번째 시사점은 조직의 권한 관리가 중요해진다는 점입니다. AI 에이전트가 Gmail, Drive, Slack, Jira, Notion, Figma 같은 도구에 접근할수록 편리해지지만, 동시에 접근 권한, 로그, 승인, 데이터 보존 정책이 중요해집니다. Google Cloud의 Gemini Enterprise 발표도 Agent Identity, Agent Registry, Agent Gateway 같은 거버넌스 개념을 강조합니다.

이 글에서 얻을 수 있는 인사이트와 결론

이 이슈를 한 단계 추상화하면, AI 업무 활용의 핵심은 “글쓰기 자동화”가 아니라 “맥락 운영 자동화”입니다. PM에게 중요한 맥락은 고객, 경쟁사, 일정, 회의, 이슈, 릴리즈, 지표입니다. 이 맥락이 흩어져 있으면 AI는 그럴듯한 문장을 만들 뿐입니다. 반대로 맥락이 연결되면 AI는 빠진 질문을 찾고, 반복 리서치를 수행하고, 후속 작업을 추적하는 업무 파트너가 될 수 있습니다.

그래서 PM·PO가 지금부터 실험해볼 만한 방식은 작게 시작하는 것입니다. 예를 들어 “매주 금요일 경쟁사 릴리즈 노트를 요약해 우리 로드맵과 관련 있는 변화만 표로 정리하기”, “회의록에서 담당자와 마감일이 빠진 액션아이템 찾기”, “사용자 인터뷰 5건에서 반복되는 불만과 PRD 반영 여부 비교하기”처럼 하나의 반복 루프를 고르는 것이 좋습니다. 그 다음 해당 루프에 필요한 파일, 메일, 일정, 이슈, 웹 리서치 질문을 연결하면 됩니다.

결론적으로, AI가 PM을 대체한다는 식의 표현은 지금 단계에서 과장입니다. 더 현실적인 변화는 AI가 PM의 반복 리서치, 문서화, 일정 점검, 이슈 정리 업무를 보조하고, PM이 더 많은 시간을 문제 정의와 의사결정에 쓰도록 업무 운영 방식을 바꾸는 것입니다.

이번 주제는 어떠셨나요? 저는 앞으로의 좋은 기획자가 “AI에게 글을 잘 시키는 사람”을 넘어 “AI가 일할 수 있는 맥락과 기준을 설계하는 사람”에 가까워질 것이라고 봅니다. PRD부터 경쟁사 리서치까지, 이제는 문서 하나가 아니라 업무 흐름 전체를 어떻게 에이전트화할지 고민해야 할 시점인 것 같습니다. 긴 글 읽어주셔서 감사합니다.