비개발자 프로젝트 : AI PM 프로젝트는 무엇을 만들고 어떤 결과를 남겨야 할까요?

비개발자가 AI PM 프로젝트를 할 때는 먼저 반복해서 불편한 문제를 고르고, 만든 뒤 실제로 굴리면서 전후의 변화를 재는 방식으로 결과를 보여 줄 수 있습니다. 저는 개인 OS를 두 달 굴리고, 광고 대행사에서 업무 자동화 도구를 만들고, 사내 AI 도구를 팀에 배포하면서 이 과정을 겪었습니다. AI PM을 준비할 때 프로젝트 경험을 어떻게 연결할지는 AI PM 준비하기에 따로 정리했습니다.

비개발자 프로젝트로 만든 개인 OS를 두 달 굴리면서 어떤 결과를 숫자로 남길 수 있나요?

개인 OS를 실제로 굴리면서 화면 일곱 개, 개념 점 359개와 연결 649개, 부딪힌 문제 165건과 규칙으로 만든 문제 22건처럼 사용 결과를 숫자로 남길 수 있었습니다. 제가 만든 iny-OS 나루터는 폰에서 던진 생각이 쌓여 글이 되고 채널로 나가는 개인 OS입니다. 진행판, 대화, 구조, 사전, 항해일기, 출항, 기록까지 일곱 개 탭으로 만들었고 화면에는 실제 데이터를 연결했습니다.

처음에는 기능을 만드는 데 집중하기도 했습니다. 하지만 두 달 동안 실제로 굴리면서 완료 작업, 정리한 자료, 정의한 개념, 개념 연결을 화면에서 계속 확인했습니다. 기록 탭에는 부딪힌 문제 165건이 쌓였고, 그중 22건은 같은 문제가 반복되지 않도록 규칙이나 시스템으로 바꿨습니다.

그래서 비개발자의 AI Product Manager 프로젝트는 무엇을 만들었는지만 보여 주기보다 문제를 고른 이유, 실제 사용 과정, 전후 시간, 사용 인원, 반복해서 생긴 문제와 바꾼 규칙까지 결과로 보여 줄 수 있다고 봤습니다. 비개발자 프로젝트는 RAG 챗봇을 만드는 경험, 특정한 프로젝트에만 한정할 필요도 없습니다. 개인 OS나 업무 자동화 도구처럼 제가 실제로 쓰면서 결과를 확인할 수 있는 형태도 프로젝트가 될 수 있습니다.

비개발자 프로젝트 주제는 반복해서 불편한 업무에서 어떻게 찾을 수 있나요?

자주 반복되거나 한 사람이 감으로 처리하는 일을 먼저 찾고, 그 일을 역할과 단계로 나누면 프로젝트 범위를 정할 수 있습니다. 나루터를 만들 때는 먼저 여덟 영역의 역할을 나눴습니다. 역할 자체는 정해져 있었지만 어떤 목소리로 말하고 언제 먼저 움직여야 하는지가 비어 있어 PO 한 사람이 감으로 처리하는 상태였습니다. 저는 그 빈칸을 문서에 적고 나루, 여울, 너울처럼 역할에 맞는 페르소나를 붙였습니다.

과거 회사에서 업무 자동화를 만들 때도 출발은 비슷했습니다. 요청서, 기획안, 원고를 각각 처리하던 콘텐츠 제작 과정을 단계별로 나누고 오래 걸리는 부분을 먼저 확인했습니다. 그다음 전 과정을 한 번의 입력으로 이어지게 묶었습니다. 프로젝트 주제를 새로운 기술에서 찾기보다 이미 반복해서 하고 있는 일에서 찾으면 무엇을 바꿔야 하는지도 더 구체적으로 잡을 수 있었습니다.

AI PM이 실제 업무에서 어떤 문제를 다루는지는 AI PM과 일반 PM의 차이에서도 확인할 수 있습니다.

AI PM 프로젝트를 만들기 전에 어떤 지표를 먼저 정할 수 있나요?

작업 시간, 완료 작업, 정리한 자료, 정의한 개념, 해결한 문제처럼 만들기 전후를 직접 비교할 수 있는 숫자를 먼저 정할 수 있습니다. 제가 회사에서 진행한 AI 업무 자동화 사례에서는 콘텐츠 제작 시간을 단계별로 먼저 쟀습니다. 요청서부터 기획안과 원고까지 따로 처리하던 과정을 한 번의 입력으로 이어지는 구조로 묶은 뒤 작업 시간이 300분에서 135분으로 줄었습니다. 약 55% 단축된 결과입니다.

나루터에서는 다른 숫자를 봤습니다. 완료 작업과 정리한 자료, 정의한 개념과 개념 연결을 대시보드에 두고, 부딪힌 문제 중 몇 건을 규칙으로 바꿨는지도 같이 기록했습니다. 두 프로젝트에서 지표는 달랐지만 먼저 재고 나중에 만드는 순서는 같았습니다.

그래서 AI PM 프로젝트에서는 도구를 만들었다는 설명만 남기기보다 무엇을 바꾸려고 했고 그 전후를 무엇으로 확인했는지를 같이 남기는 편이 좋았습니다. 제가 쓴 업무 자동화 사례에서도 핵심은 자동화 자체보다 300분이 135분으로 바뀐 결과를 직접 잰 데 있었습니다.

AI Product Manager 프로젝트에서 만든 기능이 실제로 쓰이는지 어떻게 확인할 수 있나요?

기능을 완성했는지만 보는 것이 아니라 사용 인원과 실제 사용 과정, 설명서와 온보딩, 사용 뒤 남은 문제까지 함께 확인할 수 있습니다. 사내 AI 활용 사례에서는 2025년 9월부터 2026년 1월까지 도구 일곱 개를 만들어 배포했습니다. 하지만 만드는 것만으로 팀에 정착하지는 않았습니다.

도구를 만드는 데서 끝내지 않고 가이드를 여러 번 고치고 대상에 따라 설명회를 나눠 열어 실제 업무에서 쓰게 했습니다. 같은 앱의 가이드를 2025년 12월 세 번 만들었고 설명회도 두 번 열었습니다. 2025년 12월에는 대표님과 리더님에게 성과와 기대 효과를 중심으로 설명했고, 2026년 1월에는 실무진에게 사용법을 중심으로 설명했습니다. 개발이나 별도 배포 없이 MVP로 콘텐츠크리에이티브팀 5명이 실제로 도구를 사용했습니다.

다만 실제 팀이 잘 썼다고 해서 어디에서나 쓸 수 있는 것은 아니었습니다. 처음부터 하나의 타겟에 맞춰 설계한 도구는 다른 타겟에는 바로 적용하지 못할 수 있습니다. D사 한 곳에 맞춰 만든 프로덕트도 다른 광고주에는 바로 붙일 수 없었습니다. 그래서 사내 AI 활용 사례에서는 사용 여부와 함께 사용 범위와 한계를 함께 기록해야 했습니다. 제가 만든 사내 도구들의 흐름은 사내 AI 활용 사례에서 이어서 볼 수 있습니다.

업무 자동화 프로젝트를 만든 사람만 쓰는 도구로 끝내지 않으려면 어떻게 해야 하나요?

다른 사람이 처음부터 따라 할 수 있도록 설치 과정과 오류를 기록하고 사용 가이드와 온보딩까지 함께 준비해야 합니다. 나루터를 다른 사람에게 내놓을 때는 제가 이미 설치한 환경을 그대로 넘기지 않았습니다. 맥과 윈도우에서 설치 과정을 처음부터 다시 밟았고, 그 과정에서 생긴 오류를 문서로 남겼습니다. 대화창에서 보낸 글이 들어가지 않는 오류처럼 실제로 막힌 자리는 스타터 저장소의 버그 목록으로 이어졌습니다.

회사에서도 비슷했습니다. 업무 자동화 도구에 브랜드별 톤앤매너와 상품정보를 미리 넣고, 사용 가이드와 온보딩까지 함께 만들었습니다. 도구를 만든 사람이 옆에 있어야만 쓸 수 있다면 다른 사람에게 넘긴 뒤에는 사용하기 어렵습니다. 그래서 기능을 만드는 일과 다른 사람이 처음부터 사용할 수 있게 만드는 일은 따로 확인해야 했습니다.

비개발자가 AI PM 프로젝트를 할 때 어떤 문제와 결과를 남기면 되나요?

비개발자 프로젝트는 새로운 기술을 많이 넣는 것보다 실제로 반복되는 문제를 골라 만들기 전과 후를 재고, 다른 사람이 쓸 수 있을 때까지 굴린 기록을 남기는 방식으로 정리할 수 있습니다. 저는 개인 OS에서는 부딪힌 문제와 규칙으로 바꾼 수를 기록했고, 회사의 AI 업무 자동화에서는 작업 시간을 300분에서 135분으로 쟀습니다. 사내 AI 도구에서는 일곱 개를 만든 뒤 가이드와 설명회를 거쳐 5명이 실제로 쓰는 과정까지 확인했습니다.

단순히 포트폴리오 경험을 위해 RAG 챗봇을 만들었는지보다 어떤 문제를 왜 골랐고, 만든 뒤 무엇이 달라졌으며, 어디까지 실제로 쓰였는지를 설명할 수 있어야 프로젝트의 과정이 보였습니다. 이런 경험을 AI PM 지원 경험으로 어떻게 정리할지는 AI PM 채용공고 기반 : 포트폴리오는 어떻게 준비해야 할까?에서 확인할 수 있습니다.