목표
✅ 아티클카타
🔄 서비스 기획 심화 강의 4,5 완강(4강 수강 중)🌟 목표 달성률 : 60%
⚠️ 모든 아티클은 주관적, 그대로 받아들이기 보단 비판적으로 읽어야 함.
제목 : 경쟁력 있는 'AI PM'이 되기 위한 2026 로드맵
작성자(저자) : 샤일레쉬 샤르마 (Shailesh Sharma) — Medium 원문을 요즘IT가 번역
❓아티클 선정 이유 : AI PM 역량을 갖추기 위해서 선정
전체적으로 읽어보니 강의 홍보 목적의 글이었고, 구체적인 방법론보다 "이게 중요하다"는 말을 반복하는 구조였다.
아티클에서 강조한 역량들 — 데이터 수집을 고려한 서비스 설계, 기술적으로 문제를 지적할 수 있는 언어 능력, 팀이 막혔을 때 방향을 제시하는 능력 — 은 사실 AI 시대가 아니더라도 PM이라면 원래 갖춰야 할 기본기다. 활용할 수 있는 기술(AI)이 확장된 것에 가깝다.
그럼에도 이 글에서 지금 공부하고 있는 건 제외하고 추가로 공부해볼 분야의 힌트를 건질 수 있었다.
- AI 플라이휠 개념
- RAG / 에이전트 구조
- AI Evals (모델 평가 방법론)
- 기본 ML 알고리즘 (선형/로지스틱 회귀, 의사결정 트리)
공부 방법
입문 훓기 정도의 깊이(PM이 알아야 되는 범위)로 학습하고 싶었기 때문에 Claude를 AI PM 강사로 설정해 1:1 대화 방식으로 개념을 학습했다. 모르는 부분은 바로 질문하고, 실제 PM 업무 맥락으로 연결해가며 이해하는 방식으로 진행했다.
머신러닝이란?
데이터를 반복 학습시켜 패턴을 찾고 예측하게 만드는 것. 크게 정답을 알려주며 학습하는 지도 학습과 스스로 패턴을 찾는 비지도 학습으로 나뉨. 오늘 다룬 3가지는 모두 지도 학습.
AI 기술 층 구조
1층 : 선형회귀, 로지스틱회귀, 의사결정트리 (기초 알고리즘)
2층 : 랜덤포레스트, 앙상블 모델
3층 : 신경망, 딥러닝
4층 : GPT 같은 LLM, 생성형 AI4층 얘기를 할 때도 결국 "데이터로 패턴을 찾아 예측한다"는 본질은 같음. 기초를 알면 위층 개념이 빠르게 이해됨.
선형 회귀
숫자를 예측할 때 사용. (예: 사용 시간이 길수록 전환율이 얼마나 높아지나?)
R²로 모델 신뢰도 체크. 0.3 이하면 다른 변수도 함께 봐야 한다는 신호.
로지스틱 회귀
Yes/No를 예측할 때 사용. (예: 이 유저가 이탈할까 안 할까?)
정확도만 보면 함정이 있음 → 전체 유저 중 이탈자가 5%뿐이면 모델이 전부 "안 이탈해"라고 해도 정확도 95%가 나옴. 잡아야 할 대상을 얼마나 놓치지 않고 잡는지 재현율(Recall) 도 함께 봐야 함.
의사결정 트리
조건을 하나씩 따라가며 예측. 결과에 대한 이유를 설명할 수 있는 설명 가능한 AI(Explainable AI).
반대로 회귀나 딥러닝처럼 내부가 복잡해서 이유를 알기 어려운 모델은 블랙박스 AI라고 부름.
설명 가능성이 중요한 이유
대출 심사처럼 "왜 거절됐는지" 설명이 필요한 서비스는 블랙박스 AI를 쓰면 법적으로 문제가 될 수 있음. 반면 넷플릭스 추천처럼 이유를 설명 안 해도 되는 서비스는 더 복잡한 모델을 써도 됨. PM은 "이 서비스에서 설명 가능성이 중요한가?"를 판단하고 모델 선택에 의견을 낼 수 있어야 함.
PM 입장에서 핵심
알고리즘을 직접 지정하는 게 아니라 비즈니스 요구사항을 기술 언어로 번역해서 방향을 잡아주는 것이 PM의 역할.
"R² 값이 0.3밖에 안 나왔다면, 사용 시간 말고 방문 횟수나 알림 수신 여부도 변수로 넣어보면 어떨까요?"
"정확도 말고 재현율은 어떻게 나왔어요? 실제 이탈 예정자를 얼마나 잡아내고 있는지가 더 중요할 것 같아서요."
"이번 기능은 유저한테 왜 이런 결과가 나왔는지 설명할 수 있어야 해요. 설명 가능한 모델로 가는 게 좋을 것 같은데 어떻게 생각해요?"
AI 플라이휠이란?
유저 행동 데이터를 지속적으로 쌓아 모델을 똑똑하게 만들고, 더 좋은 추천으로 유저가 더 오래 머물게 만드는 선순환 구조. 개념 자체는 직관적이지만 업계에서 실제로 쓰는 용어. 원래는 제프 베조스가 아마존 성장 전략을 설명할 때 쓴 용어가 AI 맥락으로 넘어온 것.
플라이휠 구조 예시 (요즘IT)
유입 경로 + 클릭 + 체류 시간 + 스크롤 + 댓글 데이터 쌓임 → 관심 카테고리 파악 → 관련 아티클 추천 → 유저가 더 많이 읽음 → 데이터가 더 쌓임 → 추천이 더 정확해짐 → 유저가 더 오래 머묾 → 반복
플라이휠이 멈추는 순간
콜드 스타트 문제 해결법
신규 유저는 데이터가 없어 추천이 어렵고 이탈로 이어지는 악순환 발생. 해결 방법은 세 가지.
PM 입장에서 핵심
플라이휠은 저절로 돌아가지 않음. 처음 제품 설계 단계부터 "어떻게 하면 유저 행동이 자연스럽게 데이터로 쌓이게 할까"를 의도적으로 설계해야 함.
왜 RAG가 필요한가?
ChatGPT는 특정 시점까지의 인터넷 데이터로만 학습했기 때문에 회사 내부 문서, 최신 정보 등은 모름. 모르면 그럴듯하게 지어내는데 이걸 할루시네이션(Hallucination) 이라고 함. AI를 새로 학습시키는 건 수억~수백억원, 몇 주~몇 달이 걸려서 현실적으로 불가능.
RAG란?
Retrieval-Augmented Generation. AI를 새로 학습시키는 게 아니라 질문이 들어올 때마다 관련 문서를 검색해서 AI한테 같이 던져주는 것. AI가 오픈북 시험을 보는 것과 같음.
유저 질문 → 내부 문서에서 관련 내용 검색 → AI한테 질문 + 관련 문서 같이 전달 → AI가 참고해서 답변 생성
AI가 문서를 학습하거나 저장하지 않고 매번 일회성으로 참고하는 것. 그래서 문서가 업데이트되면 즉시 반영됨.
RAG 장점
PM이 신경써야 할 것
에이전트란?
RAG가 질문에 답변한다면, 에이전트는 직접 행동함. 사람이 일일이 하던 걸 AI가 스스로 판단하고 실행하는 것.
에이전트 핵심 특징
PM이 에이전트 설계할 때 핵심 — Human-in-the-loop
AI가 잘못 판단할 수 있고 과정을 일일이 체크하기 어렵기 때문에 중간에 사람이 확인하는 구조가 필요.
"이 액션이 잘못됐을 때 되돌릴 수 있나요?"
- 되돌릴 수 있으면 → AI가 바로 실행해도 됨
- 되돌릴 수 없으면 → 반드시 사람이 중간에 확인해야 함
이메일 발송, 결제, 파일 삭제처럼 되돌리기 어려운 액션은 반드시 사람이 최종 확인하는 구조로 설계해야 함.
실사용 예시
MAKE, Cowork 같은 노코드 툴로 직접 워크플로우 설계할 수 있으면 에이전트 개념을 이미 실전으로 알고 있는 것. 트리거 설정 → 조건 판단 → 액션 실행 구조가 에이전트와 동일.
AI Evals란?
AI가 한 답변을 또 다른 AI가 자동으로 채점하는 것. 챗봇이 하루 10만 개 질문을 받으면 사람이 다 읽고 평가하는 게 불가능하기 때문에 나온 방법론. 현재 엔터프라이즈 AI 배포에서 가장 큰 병목 중 하나.
챗봇 답변 생성 → 채점 AI가 자동 평가 → 문제 있는 답변 감지
현실적인 운영 방식
AI 채점을 100% 믿을 수 없기 때문에 절충안을 씀.
PM이 봐야 할 핵심 지표
PM 입장에서 핵심
엔지니어가 "할루시네이션 비율이 8%예요" 라고 했을 때
"어떤 유형의 질문에서 주로 발생해요? 특정 문서가 문제인 건 아닐까요?"
이렇게 원인을 짚고 방향을 잡아줄 수 있어야 함.
AI의 불확실성은 본질적 특성: AI가 100% 정답을 내지 못하는 것은 일반 소프트웨어의 '버그'라기보다는 AI 자체의 특성입니다. 기획자는 AI를 특별한 무언가로 분리하기보다, 유저가 원하는 뾰족한 정답을 줄 수 있도록 지속해서 '튜닝'해 나가는 역할에 집중해야 합니다.
'초기부터 완벽한 데이터 설계'는 비현실적: 기획 초기부터 깨끗한 데이터 수집 구조를 짜야 한다는 주장은 이상적이지만 현실에서는 불가능에 가깝습니다. 카카오톡이나 배달의민족처럼 모든 서비스는 시대와 트렌드에 따라 살이 붙고 복잡해지며 성장하는 것이 자연스러운 과정입니다.
개발자/PM 대체론의 과장: 최근 '바이브 코딩' 등 AI가 프로토타입을 뚝딱 만들고 기획자나 개발자를 당장 대체할 것처럼 말하는 기사들은 위화감을 조성하는 과장된 트렌드입니다. AI는 아이디어를 팀원에게 시각적으로 전달하고 소통하기 위한 훌륭한 '도구'일 뿐, 당장 복잡한 조건 분기와 서비스 고도화를 해낼 수 있는 만능 해결사가 아닙니다.
디자이너는 어떻게 단 2주 만에 AI로 가설을 증명해 냈을까?
새로운 개념을 배운 글이라기보다, 알고 있던 개념들이 실제 현업에서 어떻게 구체적으로 작동하는지 그림을 그려준 아티클. 오늘의집 PO/PD/DA 3명이 엔지니어 없이 2주 만에 프로토타입을 만들고 100명에게 검증한 사례.
단순 반복 업무로 고통 받는 동료들을 위해 AI 사내 스터디를 조직한 사례. 직접 방법을 떠먹여 주는 것이 아니라 자신의 진짜 문제를 들고오게 하고(의미 있는 목표), 목표를 쪼개고(일주일 안에 해결), 동료들과 같이 풀게 하여 많은 변화를 이루어 냄.
1. 전문성의 본질에 더 집중
AI가 실행의 장벽을 낮추면서 각 직군이 툴이 아닌 본질에 집중할 수 있게 됐다. PO는 "무엇을 왜 만드는가", PD는 "유저가 실제로 어떻게 반응하는가", DA는 "이 가설이 데이터로 증명되는가"에 각각 집중. 직군 간 경계가 흐려지고 모두가 "검증"이라는 하나의 목표로 수렴됐다.
2. 적은 리소스와 빠른 속도로 아이디어 검증 가능
과거엔 엔지니어 없이는 불가능했던 실제 데이터 기반 프로토타입을 PO/PD/DA 3명이 직접 구축. 아이디어 검증의 진입 장벽이 크게 낮아졌다.
3. 실제 검증이 프로덕트 방향을 바꿨다
처음 가설은 "자연어 검색 유도"였지만, 실제 유저 테스트 결과 유저들은 칩 기반 제안 방식을 훨씬 선호했다. Figma 화면만으로는 얻을 수 없었던 인사이트. 가설을 데이터로 검증하고 방향을 바꾸는 것이 PM의 핵심 역할임을 다시 확인.
4. 자동화 파이프라인
Claude(굵직한 인터랙션 및 구조 변경) → Cursor(세밀한 화면 수정) → GitHub(코드 관리) → Vercel(자동 배포) 조합으로 개발 프로세스 자동화. 코드 수정이 즉시 팀원과 외부 유저에게 공유 가능한 URL로 반영됐다.
5. AI의 한계 — 결정적 순간엔 전문가 필요
첫 번째 칩만 터치가 안 되는 버그를 AI로 반나절 동안 못 잡았는데, 개발자가 30분 만에 해결. AI는 화면 전체의 레이아웃 위계까지 완벽히 파악하지 못한다. 언제 전문가의 도움을 요청해야 하는지 아는 것도 중요한 역량.
오늘 Claude와 대화하며 공부하면서 문득 "AI랑만 공부해도 되나?" 하는 의문이 들었다. AI는 할루시네이션이 있어서 100% 신뢰할 수 없는데 편하다 보니 스스로 찾아보고 고민하는 과정을 건너뛰는 경향이 생기고 있다는 걸 느꼈다.
다만 오늘처럼 입문 훑기 수준에서는 AI가 월등히 유효한 학습 도구라는 결론을 내렸다.
중요한 건 AI로 감을 잡고 → 깊이 파고 싶은 주제는 직접 찾아보는 것.
💭 오늘의 한 줄 평 : 목표를 쪼개서 죄금씩 해 나가자