월간 보고를 다음 달 첫날에: Microsoft PM이 에이전트로 바꾼 계획·데이터·프로토타입 업무
제품 관리자(PM)의 업무에는 고객 요구를 이해하고 엔지니어링 투자 우선순위를 정하는 일뿐 아니라, 여러 시스템에서 진행 상황을 모으고 경영진에게 설명하는 일도 포함됩니다. AI가 문서를 빨리 요약해 주더라도, 원천 데이터가 부정확하면 판단의 질은 좋아지기 어렵습니다.
Microsoft Digital의 Infrastructure Engineering Services(IES) 팀은 이 문제를 Continuous Planning 관점에서 풀었습니다. 계획 대시보드, 엔지니어링 용량, Azure DevOps(ADO) 데이터 품질, 정기 검토, 월간 보고와 AI 요약을 하나의 운영 흐름으로 연결한 것입니다.
이번 Inside Track 사례의 핵심은 PM을 자동화로 대체하는 것이 아닙니다. 반복적인 정보 정리 시간을 줄이고, 고객·엔지니어와 함께 우선순위와 제품 방향을 판단하는 시간을 늘리는 데 있습니다.
보고서 자동화보다 먼저: 계획과 실행의 피드백 루프
IES의 PM 리더 Martin O’Flaherty와 팀은 지난달 완료한 시나리오를 모아 전략적 우선순위별로 정리하고, 엔지니어링 투자와 결과를 경영진용 보고·시각화로 만드는 AI 지원 기능을 구축했습니다.
처음에는 보고가 정확하지 않거나 누락된 정보가 있었습니다. 팀은 이를 모델만의 문제로 보지 않고, 보고 로직을 개선하고 계획 데이터를 보강하며 실제 납품을 뒷받침하는 문서화된 근거의 평가 방식을 정리했습니다.
위 이미지는 원문에 제시된 익명화된 예시입니다. 계획 상태, 전달 진척, 자원 배분과 실행을 논의하기 위한 화면이지 특정 수치를 모든 팀에 적용하는 벤치마크는 아닙니다.
원문에서 O’Flaherty는 이전에는 몇 주가 걸려 7월 보고를 8월 말에야 제공했지만, 이제 8월 1일에 보낼 수 있다고 설명합니다. 최근 보고에 대한 피드백도 거의 없었다고 말하지만, 사람의 검토는 여전히 과정의 일부입니다.
두 번째 에이전트: 보고서를 고치기보다 데이터 습관을 고치기
ADO 데이터의 누락과 불일치는 불완전한 인사이트로 이어졌습니다. 이를 해결하기 위해 팀은 범위에 포함된 시나리오를 정의된 규칙으로 지속 점검하는 데이터 hygiene 기능도 만들었습니다.
이 기능은 데이터 공백을 발견하고, 팀원에게 Azure DevOps에서 무엇을 보완해야 하는지 구체적으로 안내합니다. 더 좋은 데이터가 더 좋은 AI 보고를 만들고, AI가 다시 보고의 신뢰성을 해치는 데이터 품질 문제를 찾는 구조입니다.
중요한 점은 원문이 이 기능의 실제 필드 목록, 규칙 코드, 쓰기 권한 구성을 제공하지 않는다는 것입니다. “데이터를 자동 수정하는 완제품 에이전트”로 단정하지 말고, 규칙 기반 점검과 담당자 안내라는 구현 방향으로 이해해야 합니다.
PM 교육은 설치와 첫 연결부터 시작했습니다
모든 PM이 AI 전문가인 것은 아닙니다. O’Flaherty와 동료들은 Visual Studio Code 설치, GitHub Copilot 로그인, MCP server 접근 같은 기본 과정을 짧은 설명 영상으로 나눴습니다.
목표는 먼저 모든 기술을 배우게 하는 것이 아니라, 자신의 실제 업무에서 작은 문제를 풀어보게 하는 것이었습니다. 기술 수준이 다양한 직원에게 접근 가능한 시작점을 제공한 셈입니다.
그러나 확산되자 비슷한 문제를 해결하는 에이전트가 중복 생성됐습니다. 팀은 재사용 가능한 skills와 공유 저장소를 도입해 이미 있는 작업을 가져오고 조직에 맞게 조정하도록 유도했습니다. 개인의 실험을 막지 않으면서 성공한 패턴을 공동 자산으로 만드는 접근입니다.
개인 PM의 업무는 어떻게 바뀌었나요?
여러 파트너를 위한 정기 보고
Senior PM Astha Sinha는 문서, 회의 노트, 여러 기술 환경의 정보를 정리하는 데 매일 몇 시간을 쓰곤 했습니다. Copilot 요약을 사용한 뒤에는 agentic skills로 파트너별 보고 주기에 맞춰 보고서를 생성하도록 업무를 발전시켰습니다.
원문은 이 작업이 백그라운드에서 수행된다고 설명하지만, 구체적인 스케줄러·구성 파일·실행 코드는 제공하지 않습니다. Skills 파일 자체만 만들면 자동 예약 실행이 설정된다고 해석해서는 안 됩니다.
코드·로그·장애 정보를 연결한 사용 분석
Senior PM Owais Khan은 에이전트가 코드베이스와 장애 보고를 이해하도록 하고, 로그와 데이터 모델을 연결해 사용자 클릭, API 사용, 호출 패턴을 더 빠르게 분석합니다.
이전에는 몇 시간 걸릴 수 있는 조사를 엔지니어 시간을 요청하지 않고 더 빠르게 수행해 고객과 논의할 수 있었다고 설명합니다. 실제 도입에서는 에이전트가 읽어야 하는 코드·운영 로그의 권한과 민감 정보 범위를 먼저 정하는 것이 필요합니다. 이 권한 점검은 사례를 적용하는 실무 권고입니다.
클릭 가능한 프로토타입으로 요구사항 설명
Principal PM Nevedita Mallick은 한 페이지 기획서와 Figma 기반 수작업 대신 AI로 인터랙티브 mockup을 만드는 경험을 소개합니다. 원문에서 그녀는 Copilot Studio에 거친 스케치를 제공해 HTML·CSS·JavaScript를 얻고, 화면을 클릭하며 엔지니어에게 원하는 동작을 설명했다고 말합니다.
이는 해당 PM이 공유한 활용 경험입니다. 모든 Copilot Studio 환경에 동일한 범용 UI 코드 생성 기능이 기본 제공된다는 출시 공지는 아닙니다. 원문은 재현용 설정이나 템플릿도 제시하지 않습니다.
핵심 가치는 고객에게도 상호작용 가능한 예시를 일찍 보여주어 요구사항을 더 빨리 맞추고, 뒤늦은 수정 부담을 줄이는 데 있습니다.
원문에 나온 시간 단축 사례
| 작업 | 원문이 공유한 개인·팀 경험 |
|---|---|
| 월간 보고 | 몇 주가 걸리던 보고를 다음 달 첫날에 제공할 수 있게 됨 |
| 프로토타입 | 하루나 이틀 걸리던 작업이 1시간 미만, 경우에 따라 몇 분으로 단축 |
| 특정 업무용 custom skill | 숙련 후 5분 미만에 만든 사례 |
| 문서·회의 정보 정리 및 사용 분석 | 기존에는 매일 몇 시간 또는 조사별 몇 시간이 걸릴 수 있었다고 설명 |
이 수치는 해당 직원들의 경험담입니다. 작업 난이도와 학습 수준에 따라 달라지며, 조직 전체 평균 생산성이나 특정 비율의 ROI 측정으로 일반화해서는 안 됩니다.
프롬프트에는 판단에 필요한 맥락을 넣으세요
원문은 네트워크 문제를 분석할 때 “네트워크 엔지니어처럼 생각해 달라”고 요청하고 토폴로지·의존성·운영 맥락을 제공한 예를 소개합니다. 일반적인 답보다 문제에 맞춘 분석으로 이동한 사례입니다.
PM 업무에서는 대상 독자, 보고 형식, 우선순위 기준, 신뢰할 원천 자료를 구체적으로 정의해야 합니다. 다음은 원문의 원칙을 적용한 예시이며 원문 그대로의 프롬프트는 아닙니다.
지난달 완료한 ADO 시나리오를 승인된 전략 우선순위별로 정리해 주세요. 완료를 뒷받침하는 근거와 원천 링크를 표시하고, 누락된 필드나 근거가 불충분한 항목은 별도로 구분해 주세요. 경영진이 투자와 결과를 판단할 수 있게 요약하되 확인되지 않은 성과는 추정하지 마세요.
사람은 에이전트의 검토·승인 계층으로 남습니다
에이전트가 시나리오별 시간을 추정할 수 있어도 누가 수행했는지, 경험과 실제 속도가 어떠한지 등 생산성 평가에는 추가 맥락이 필요합니다. 사실 확인도 빠질 수 없습니다.
O’Flaherty는 에이전트가 작업하고 사람이 검토·승인하는 역할을 “agent bosses”라고 표현합니다. PM은 반복 정리에서 벗어나더라도 판단, 협업, 책임을 계속 가져갑니다.
장애를 미리 발견하고 예방하는 방향은 원문이 제시하는 향후 기회와 기대입니다. 모든 문제를 이미 선제적으로 방지하고 있다는 구현 결과로 읽어서는 안 됩니다.
우리 팀에서 시작할 순서
- 반복 보고·상태 정리·맥락 수집처럼 범위가 명확한 업무를 선택합니다.
- 기존 문서와 ADO 등 원천 시스템을 활용하고 데이터 누락을 함께 점검합니다.
- 대상 독자, 출력 형식, 근거 자료와 검토 책임을 명시합니다.
- 공유된 skills·에이전트가 있는지 확인해 중복 개발을 줄입니다.
- 공유·컴플라이언스·재사용 규칙을 초기에 마련합니다.
- 사람의 검토를 유지하면서 실제 시간과 품질의 변화를 확인합니다.
이는 사내 활용 사례이며 특정 기능의 GA·프리뷰 일정, 라이선스 비용이나 배포 절차를 확정하는 글은 아닙니다. 사용 도구의 지원 범위와 실제 환경 설정은 별도로 확인해야 합니다.
마무리: PM을 자동화하지 말고 좋은 판단의 시간을 늘리세요
Microsoft의 사례에서 가장 재현할 만한 요소는 화려한 자동 보고서 자체가 아닙니다. 계획 데이터의 품질, 재사용 가능한 skills, 실제 업무에 맞춘 교육, 사람의 검토가 연결된 운영 방식입니다.
AI가 정보를 모으고 초안을 만들면 PM은 고객의 문제와 엔지니어링 투자의 우선순위에 더 집중할 수 있습니다. 그 역할 분담이 제품 관리에서 에이전트를 활용하는 목적입니다.
출처: Microsoft Inside Track Blog, Boosting product manager productivity at Microsoft with AI.
자세한 내용은 원문 참조.