PO 1명이 기획팀이 되는 법 — 에이전트 팀으로 기획 프로세스를 자동화한 이야기

바빴는데, 정작 판단에 쓴 시간은 얼마 안 됐어요.

PO가 하루에 하는 일을 세어본 적 있나요?

회의, 문서, 데이터, 커뮤니케이션. 하루가 끝나면 “오늘 뭐 했지?” 싶은 날이 많아요. 바쁘긴 했는데, 정작 내가 판단해야 하는 일에 쓴 시간은 얼마 안 되는 느낌. 나머지는 판단의 재료를 준비하거나, 판단의 결과를 문서화하는 데 썼어요.

이 글은 PO의 일상 업무를 하나하나 뜯어보고, “이건 정말 내가 해야 하는 건가?”를 물어본 기록이에요.

PO는 매일 뭘 하나요?

회사마다 다르겠지만, 제가 하는 일을 솔직하게 나열하면 이래요.

업무	하는 일	체감 시간
정책 결정·조율	기능 방향, 정책 변경, 이해관계자 합의	판단 자체는 짧은데 회의가 길어요
사양서 작성	정책을 UI·API·예외처리로 풀어 적기	정책 30분, 사양서는 반나절
데이터 확인·분석	SQL, 차트, 핵심 지표 모니터링	숫자 보는 건 5분, 준비가 30분
과거 기획 참조	컨플루언스 검색, 이전 정책 근거 확인	찾는 데 30분, 참조해서 판단은 5분
와이어프레임	개발자에게 “이런 화면이에요” 전달용 그림	안 그리면 회의에서 30분 설명
커뮤니케이션	슬랙·지라·회의·QA 피드백	순수 전달인데 줄이기 어려움

공통점이 보이나요? 정책을 정하는 시간보다, 정한 걸 문서로 만들고, 데이터로 확인하고, 전달하는 시간이 훨씬 길어요.

이 중에서 뭘 자동화할 수 있을까?

위 업무들을 다시 보면, 크게 두 종류로 나뉘어요.

판단이 필요한 일:

정책 결정
이해관계자 조율
데이터 해석 (“이 숫자가 의미하는 건 뭔가?”)
트레이드오프 판단 (“A를 하면 B가 손해인데, 그래도 할 건가?”)

실행이 필요한 일:

사양서 초안 작성 (정해진 포맷에 내용 채우기)
데이터 추출과 시각화 (SQL, 차트, 테이블)
대시보드 구축과 유지 (ETL, 시각화 페이지)
과거 문서 검색과 요약
와이어프레임 초안

판단은 쉽게 넘길 수 없어요. 맥락을 아는 사람이 해야 하니까요. 하지만 실행은? 패턴이 있고, 반복이 있고, 참조할 수 있는 것들이에요.

여기서 질문이 바뀌었어요. “뭘 자동화할 수 있을까?”가 아니라, **“판단과 실행의 경계를 어디에 그을 것인가?”**로.

경계를 긋고, 에이전트를 붙이다

에이전트 팀과 실제로 해본 다섯 가지를 정리할게요.

1) 사양서 초안 — 정책을 구조로 바꾸는 작업

PO가 정책을 한 줄로 적어요. “테이스팅 기록은 본인만 수정 가능하다.”

에이전트가 기존 사양서 포맷을 참조해서 초안을 만들어요. UI 사양, API 사양, 예외 케이스, 에러 응답까지. PO는 초안을 검토하고, 판단이 필요한 부분만 수정해요.

핵심은 에이전트가 **“기존 패턴을 알고 있다”**는 거예요. 사양서의 포맷, 항목 구조, 네이밍 컨벤션, 에러 코드 체계 — 이런 것들이 이미 축적된 지식으로 존재하면, 초안의 품질이 올라가요. 빈 문서에서 시작하는 것과, 80% 채워진 문서에서 시작하는 건 완전히 달라요.

2) 데이터 분석·리포트 — 숫자를 의미로 바꾸는 작업

에이전트가 가져가는 부분:

데이터 추출 (SQL 쿼리 작성, CSV 가공)
시각화 (차트 생성, 비교 테이블)
패턴 탐지 (전주 대비, 전년 동기 대비, 그룹 간 차이 하이라이트)

PO가 하는 부분:

“뭘 볼 것인가” 결정
“이게 무슨 의미인가” 해석
“그래서 뭘 할 것인가” 판단

실제로 제품 실험의 A/B 테스트 대시보드를 에이전트 팀과 만들었어요. 실험군/대조군별 전환율, 리텐션, 핵심 지표를 일별로 추적하고, 정책 전후를 비교해요. 에이전트가 데이터를 가공하고 차트를 그리면, PO는 “실험군의 전환율이 왜 올랐는가”를 해석하는 데 집중할 수 있어요.

3) 대시보드 구축 — 반복 관측을 자동화하는 작업

리포트가 “한 번 보는 것”이라면, 대시보드는 “계속 보는 것”이에요.

에이전트 팀과 이런 구조로 만들었어요:

ETL 파이프라인: 원본 데이터를 로드하고, 지표를 계산하고, 대시보드가 읽을 수 있는 형태로 변환
시각화 페이지: Summary, YoY Analysis, Operations, Trend, Raw Data 탭으로 구성
갱신 플로우: 새 데이터가 올라오면 자동 갱신

에이전트의 역할은 “만드는 것”뿐 아니라 **“유지하는 것”**이에요. 지표가 추가되거나 필터 조건이 달라지면 에이전트가 수정해요. PO는 “이 지표 추가해줘”라고 말하면 돼요.

4) 기획 지식 검색 — 조직의 기억에 접근하는 작업

컨플루언스에 문서가 수백 페이지 쌓여 있는데 아무도 안 읽어요.

“그때 이 정책 변경할 때 근거가 뭐였지?” → 컨플루언스 검색 → 비슷한 문서 10개 → 하나하나 열어봄 → “아 이게 아니네” → 결국 옆 사람한테 물어봄 → 그 사람도 기억 안 남. 찾는 데 30분, 물어보는 데 30분, 정작 참조해서 판단하는 건 5분이에요. 이 루프를 끊고 싶었어요.

그래서 두 가지를 했어요.

첫째, 문서를 구조화된 지식으로 변환했어요. 정책서인지 사양서인지 회의록인지 분류하고, 각 문서에서 핵심 결정과 근거를 추출했어요. 이전 글의 개념 체계가 여기서 빛을 발해요. 문서가 “이건 정책이다”, “이건 사양이다”로 분류되어 있으면 검색할 때 노이즈가 확 줄어들어요.

둘째, 검색 에이전트를 붙였어요. “이전 정책 변경 이력”을 물으면, 관련 정책서 3건을 찾아서 결정 사항과 근거를 요약해줘요. 완벽하진 않아요 — 가끔 엉뚱한 문서를 물어오기도 해요. 하지만 최소한 “어디를 봐야 하는지”를 바로 알려주니까, 30분 검색이 5분 확인으로 바뀌었어요. 못 찾으면 그때 사람한테 물어보면 되고요.

5) 와이어프레임 — 대화의 시작점을 만드는 작업

사양서가 “뭘 보여줄 것인가”라면, 와이어프레임은 “어떻게 보여줄 것인가”예요.

실제로 해본 플로우는 이래요:

PO가 화면 구성을 설명해요. “상단에 필터 3개, 중앙에 카드 리스트, 카드에는 이미지·제목·태그”
에이전트가 기존 디자인 시스템의 컴포넌트를 참조해서 와이어프레임을 생성
PO가 “필터 순서 바꿔, 카드에 날짜도 넣어” 피드백
에이전트가 즉시 반영 → 2~3회 반복이면 충분

여기서 중요한 건 완성도가 아니에요. 최종 디자인은 디자이너의 영역이에요. 에이전트가 만드는 건 **“대화의 시작점”**이에요. 개발자가 “이게 무슨 화면이야?”라고 묻는 대신 “여기 이 부분은 이렇게 바꾸자”로 바로 들어갈 수 있으면, 회의에서 그림 설명하는 시간이 사라져요.

예를 들어, Aster.duck의 테이스팅 노트 화면을 만들 때 — 과거에는 피그마를 열어서 컴포넌트 배치하고 정렬하는 데 30분이 걸렸어요. 지금은 “향미 노트 입력 화면, SCA Flavor Wheel 기반, 선택하면 태그로 쌓이는 구조”라고 말하면 초안이 나와요. 거기서 “여기 이렇게 바꿔” 하는 5분이면 끝나요.

이 구조의 이름: PO Copilot

다섯 가지를 묶으면 하나의 패턴이 보여요.

PO가 판단하고, 에이전트가 실행한다.

업무	PO의 역할	에이전트의 역할
사양서	정책 결정, 검토	초안 생성, 포맷 적용
데이터 분석	질문 설계, 해석, 판단	추출, 가공, 시각화
대시보드	지표 선정, 해석	ETL, 시각화, 유지보수
지식 검색	질문, 맥락 판단	문서 지식화, 검색, 요약
와이어프레임	구조 설계, 검토	시각화, 컴포넌트 적용

이걸 PO Copilot이라고 부르기로 했어요. Copilot이라는 단어를 쓴 이유는, 에이전트가 PO를 ‘대체’하는 게 아니라 ‘옆에서 함께 일하는’ 구조이기 때문이에요.

**판단(Judgment)**은 맥락을 아는 사람이, **실행(Execution)**은 에이전트가. 이 경계를 명확히 유지하는 게 핵심이에요 — 에이전트가 정책을 판단하기 시작하면 위험하고, PO가 SQL을 직접 쓰고 있으면 비효율이에요.

BaaS와의 관계

이전 글에서 BaaS(Builder-as-a-Service)를 다뤘어요. 개인화 소프트웨어의 제작-운영 공급망을 제공하는 서비스 계층이라고 했죠.

PO Copilot은 BaaS의 하위 레이어예요.

BaaS: 소프트웨어 공급망 전체를 제공하는 서비스
PO Copilot: 그 공급망 안에서 기획 프로세스를 보조하는 에이전트 팀

BaaS가 “공장 전체”라면, PO Copilot은 “공장 안의 기획 라인”이에요.

왜 기획 라인부터인가? 대부분의 조직에서 기획이 병목이에요. 개발자가 “사양서 언제 나와요?”라고 물어보는 상황, 한 번쯤 겪어보셨을 거예요. 기획이 느리면 개발이 기다리고, 개발이 기다리면 출시가 밀려요. 기획 라인의 처리량이 올라가면 — 사양서가 빨리 나오고, 데이터가 미리 정리되어 있고, 와이어프레임이 회의 전에 준비되어 있으면 — 그 뒤의 개발·QA·출시 라인도 같이 빨라지는 구조예요.

실제로 달라진 것

에이전트 팀과 함께 일하기 시작하고 나서 달라진 점이 있어요.

사양서 반나절 → 2시간. 빈 문서에서 시작하면 반나절, 에이전트 초안 위에서 검토하면 2시간이에요. 포맷 맞추고 항목 채우는 시간이 사라진 거예요.

회의가 짧아졌어요. 데이터가 이미 정리되어 있고, 와이어프레임 초안이 있으니까 “이건 뭐야?”에서 시작하는 대신 “이 부분은 이렇게 바꾸자”에서 시작할 수 있어요.

병렬 처리가 가능해졌어요. PO가 A 기능의 정책을 결정하는 동안, 에이전트가 B 기능의 사양서 초안을 작성하고, C 기능의 데이터를 분석해요. 동시에 2~3개 트랙이 돌아가요.

기억이 사라지지 않아요. 3개월 전 정책 결정의 배경이 뭐였는지, 검색 에이전트한테 물으면 관련 문서 3건이 요약돼서 나와요. “그때 그거 뭐였지?” 루프가 사라졌어요.

정리

PO의 하루를 해부하면, 판단과 실행으로 나뉘어요.

판단 — 정책 결정, 데이터 해석, 트레이드오프 — 은 맥락을 아는 사람이 해야 해요. 실행 — 사양서 초안, 데이터 추출, 대시보드 구축, 문서 검색, 와이어프레임 — 은 패턴이 있고 반복이 있어요.

그 경계를 긋고, 실행 쪽에 에이전트를 붙였어요. 그 결과가 PO Copilot이에요.

사양서: 정책을 구조로 바꾸는 작업
데이터 분석: 숫자를 의미로 바꾸는 작업
대시보드: 반복 관측을 자동화하는 작업
지식 검색: 조직의 기억에 접근하는 작업
와이어프레임: 인터페이스를 시각화하는 작업

PO 1명이 기획팀 하나의 산출물을 만들 수 있는 구조. PO는 판단에 집중하고, 나머지는 에이전트가 실행하니까요.

다음 글 예고: PO Copilot을 다른 팀에 분양하려면 어떤 구조가 필요할까요? 온프레미스와 하이브리드 모델, 그리고 에이전트 팀의 서비스화에 대해 이어갈게요.