10년차 PO가 AI에게 일을 맡기는 방식

AI를 잘 쓰는 사람을 보면 공통점이 있습니다. 긴 프롬프트를 한 번에 잘 쓰는 사람이 아니라, 일을 잘게 쪼개서 AI가 처리할 수 있는 흐름으로 바꿉니다.

10년차 PO의 AI 활용도 이 방향에 가깝습니다. PRD 작성, 데이터 분석, 사내 정보 탐색, 업무 정리처럼 매일 반복되는 일을 AI에게 맡기되, “알아서 잘 써줘”라고 던지지 않습니다. 먼저 어떤 정보를 찾아야 하는지, 어떤 순서로 사고해야 하는지, 어떤 템플릿에 맞춰 정리해야 하는지를 구조화합니다. 핵심은 AI에게 답을 받는 것이 아니라, AI에게 일하는 방식을 주는 것입니다.

PO가 AI를 많이 쓰는 지점은 PRD와 데이터 분석입니다

PO에게 PRD는 단순한 문서가 아닙니다. 팀원에게 왜 이 일을 해야 하는지, 어떤 문제를 풀고 있는지, 어떤 가설을 검증하려는지 전달하는 사고의 흐름입니다. 그래서 PRD 작성에 AI를 붙일 때도 “PRD 하나 써줘”로 끝내면 결과가 흔들립니다. AI는 문장은 만들 수 있지만, 어떤 맥락을 먼저 설명해야 하는지, 어떤 문제를 우선해야 하는지, 어떤 근거가 부족한지 스스로 정확히 알지 못합니다.

실무에서 더 안정적인 방식은 PRD를 단계로 나누는 것입니다. 먼저 컨텍스트를 정리합니다. 그다음 가설이나 문제를 뽑습니다. 루트코즈를 찾고, 마지막으로 솔루션을 정리합니다. 한 번에 완성본을 만들기보다 사고의 순서를 따라가게 하는 방식입니다.

PRD는 한 번에 쓰기보다 페이즈로 나누는 편이 좋습니다

PRD가 어려운 이유는 글쓰기 때문만이 아닙니다. 무엇이 문제인지, 왜 지금 해야 하는지, 어떤 고객과 지표에 영향을 주는지, 어떤 대안이 있는지를 차례로 판단해야 하기 때문입니다.

이 판단을 한 번에 AI에게 맡기면 빠르게 초안은 나오지만, 근거가 약하거나 팀 맥락과 어긋날 수 있습니다. 반대로 페이즈를 나누면 각 단계에서 검토할 수 있습니다.

예를 들어 첫 단계에서는 “이 기능의 배경과 맥락만 정리해줘”라고 시킵니다. 두 번째 단계에서는 “이 맥락에서 가능한 문제와 가설을 뽑아줘”라고 시킵니다. 세 번째 단계에서는 “각 문제의 루트코즈 후보를 정리해줘”라고 시킵니다. 마지막에 솔루션과 인수 조건을 붙입니다.

이렇게 나누면 AI가 잘못 간 방향을 중간에 바로잡을 수 있습니다. PO 입장에서는 완성된 문서를 검수하는 부담보다, 사고 흐름을 단계별로 검토하는 부담이 더 작습니다.

Skill은 개인 프롬프트를 팀 자산으로 바꿉니다

매번 같은 방식으로 PRD를 쓰고 있다면, 그 방식은 프롬프트가 아니라 Skill이 될 수 있습니다. `SKILL.md` 같은 파일에 언제 이 작업을 쓰는지, 어떤 순서로 진행하는지, 어떤 문서와 레포를 참고해야 하는지, 어떤 산출물을 만들어야 하는지 적어두는 방식입니다.

이렇게 만들면 개인의 프롬프트 요령이 팀 자산으로 바뀝니다. 한 사람이 잘 쓰는 프롬프트를 복사해서 채팅창에 붙이는 수준이 아니라, 팀원들이 같은 작업 방식을 재사용할 수 있습니다.

GitHub 레포로 공유하거나 사내 마켓플레이스에 올릴 수도 있습니다. 중요한 것은 “이 사람만 잘 쓰는 AI”에서 “팀이 같은 기준으로 쓸 수 있는 AI 워크플로우”로 넘어가는 것입니다.

좋은 AI 워크플로우의 1단계는 정보 탐색입니다

AI에게 사내 업무를 맡길 때 가장 큰 문제는 정보 위치입니다. 우리 회사 PRD는 어디에 있는지, 과거 분석 문서는 어디에 있는지, 관련 레포는 무엇인지, 비슷한 기능은 어떤 코드에 있는지 모르면 AI도 추측할 수밖에 없습니다.

그래서 워크플로우의 첫 단계는 정보 탐색이어야 합니다. 어떤 레포를 봐야 하는지, 어떤 과거 문서를 참고해야 하는지, 어떤 템플릿을 써야 하는지 먼저 찾게 해야 합니다.

예를 들어 “이 PRD는 A 레포의 결제 흐름과 B 레포의 알림 기능을 참고하면 된다”는 식으로 연결해줍니다. 과거 작성된 PRD 중에서 비슷한 사례도 찾게 합니다. 그다음에 문서 작성을 시작해야 결과가 회사 맥락 안에 들어옵니다. AI가 업무를 잘하려면 똑똑한 모델만 필요한 것이 아닙니다. 회사 안에서 무엇을 봐야 하는지 알려주는 길잡이가 필요합니다.

AI-readable 문서 환경은 복리 효과를 만듭니다

문서가 여러 곳에 흩어져 있으면 AI도 매번 헤맵니다. Google Docs, Jira, Confluence, Notion, 코드 레포가 제각각 있고 이름도 불규칙하면, 사람도 찾기 어렵고 AI도 찾기 어렵습니다.

반대로 AI가 읽기 쉬운 문서 환경을 만들면 시간이 지날수록 효과가 쌓입니다. 문서가 한 곳에 잘 정리되고, 템플릿이 일정하고, 과거 의사결정이 남아 있으면 AI는 더 좋은 컨텍스트를 가져올 수 있습니다.

이것은 단발성 자동화가 아니라 복리 효과에 가깝습니다. 오늘 정리한 문서는 다음 PRD의 입력이 됩니다. 오늘 만든 템플릿은 다음 팀원의 작업 기준이 됩니다. 오늘 만든 Skill은 다음 반복 업무의 시작점이 됩니다.

AI 결과물의 품질은 모델 성능만으로 결정되지 않습니다. 회사의 지식이 얼마나 읽기 쉬운 형태로 남아 있는지가 함께 결정합니다.

질문이 많아도 문제 정의에는 도움이 됩니다

AI가 너무 많이 되묻는 것이 귀찮을 때가 있습니다. 특히 그냥 실행해줬으면 하는 순간에는 더 그렇습니다. 하지만 PO 업무에서는 되묻는 과정이 완전히 나쁜 것만은 아닙니다. PO는 결국 “무엇을 해야 하는가”를 정의하는 사람입니다. 무엇을 만들지, 왜 만들지, 어떤 문제를 먼저 풀지 계속 좁혀가야 합니다.

AI가 질문을 던지는 과정은 문제 정의를 선명하게 만들 수 있습니다. 물론 이미 직관적으로 답이 명확한 상황도 있습니다. 그럴 때는 줄글로 요청하고 빠르게 실행시키는 방식이 더 나을 수 있습니다.

중요한 것은 모든 일을 같은 방식으로 처리하지 않는 것입니다. 탐색이 필요한 일은 질문을 받아가며 좁히고, 명확한 일은 바로 실행하게 합니다.

처음 시작은 매일 업무 정리 Skill이 좋습니다

AI 활용이 막막한 PO나 기획자라면 거창한 PRD 자동화부터 시작하지 않아도 됩니다. 가장 좋은 시작점은 매일 반복하는 업무 정리입니다. 아침에 오늘 할 일을 정리합니다. 새 업무가 들어오면 어디에 기록할지 판단합니다. 회의에서 나온 내용을 액션 아이템으로 바꿉니다. 기억해야 할 정보를 모읍니다. 이런 일은 대부분 반복되고, 형식도 어느 정도 정해져 있습니다.

이 반복 업무를 Skill로 만들어 AI에게 맡겨보면 바로 체감이 생깁니다. “이건 내가 매번 설명하지 않아도 되겠구나”라는 경험이 쌓입니다. 그다음 PRD, 데이터 분석, 사내 문서 검색으로 넓히면 됩니다. 처음부터 완벽한 자동화를 만들 필요는 없습니다. 매일 하는 작은 정리 하나를 AI에게 외주 주는 것이 현실적인 시작입니다.

어제 안 됐다고 오늘도 안 되는 것은 아닙니다

AI 도구는 매우 빠르게 바뀝니다. 어제 시도했을 때 안 됐던 일이 오늘은 될 수 있고, 이번 주에 어색했던 기능이 다음 달에는 꽤 쓸 만해질 수 있습니다. 그래서 한 번 실패했다고 “AI는 우리 업무에 안 맞아”라고 결론 내리기에는 이릅니다. 중요한 것은 작은 반복 업무를 고르고, 다시 시도하고, 잘 된 흐름을 파일과 Skill로 남기는 것입니다.

PO의 AI 활용 능력은 답변을 잘 받는 기술보다 업무를 구조화하는 능력에 가깝습니다. 어떤 정보를 먼저 찾을지, 어떤 순서로 사고할지, 어떤 템플릿에 맞출지, 결과를 어떻게 검증할지 정하는 사람이 AI를 더 잘 씁니다. AI에게 일을 맡긴다는 것은 일을 포기한다는 뜻이 아닙니다. 오히려 내 업무 방식을 더 명확히 정의하는 일에 가깝습니다.