미리보기
"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."
AI 프로덕트 책을 몇 권 읽다 보면 비슷한 지점에서 손이 멈춘다. 프롬프트 모음집이거나, 빅테크 성공담을 다시 쓴 책이거나, 에이전트 시대가 온다는 말만 반복하다 끝나는 책. 읽고 나면 머릿속에 남는 건 그래서 내가 내일 뭘 바꿔야 하지?라는 공허함뿐인 경우가 많다.
《AI 프로덕트는 어떻게 만들어지는가?》 제목을 처음 봤을 때도 비슷한 반응이었다. 부제에 마이크로소프트, VESSL AI, 글로벌 대기업 현직자 이름이 붙어 있으니, 또 한 번 현장 이야기를 포장한 책 아닐까 싶었다. 그런데 목차를 훑어보니 구성이 달랐다. 기획, 디자인, 개발, 리서치를 각각 다른 사람이 쓰되, 하나의 프로덕트 생애주기 안에서 맞물리게 짜여 있다. PM 혼자 읽는 책도, 개발자 혼자 읽는 책도 아니다.
나는 AI 교육 기획과 PoC 검증 쪽 일을 하고 있어서, 이 책을 읽으면서 계속 비교한 대상이 이론이 아니라 지금 겪고있는 현장이었다. 팀에서 AX를 주도하면서, 마주하고 있는 현실과 정답이 없는 길에 대해 이 책에서는 이러한 부분들을 조금 이나마, 다른 시각에서 바라보고 배울 수 있었다. 완벽한 답을 주진 않지만, 왜 그런 일이 생기는지 사례를 엿볼 수 있었다.
출판사 소개에 AX 시대, AI 메이커 같은 말이 많이 나온다. 보통은 그런 문장에서 한 발 물러서게 되는데, 이 책은 다행히 본문이 그 슬로건보다 낮고 실무 쪽에 붙어 있다. 읽다 보면 거대한 비전보다, 다음 스프린트 회의에서 쓸 문장을 더 많이 건져 올리게 된다.
팀이 같은 제품을 두고 회의할 때 필요한 순서
내 책장·읽기 목록을 보면 대개 둘 중 하나다. RAG, 에이전트 같은 개발 입문서이거나, ChatGPT 잘 쓰는 법·프롬프트 모음이다. 가끔 AI 시대 조직 이야기까지 섞이지만, 그때도 PM이 읽을 책과 개발자가 읽을 책은 따로 놓게 된다.
이 책은 그 습관을 깨는 구성이었다. PM 파트에서 스펙과 지표 이야기를 하다가, UX 파트에서 신뢰와 위임 이야기로 넘어가고, 개발 파트에서 RAG와 하네스로 다시 맞닿는다. 한 직무 입장에서만 읽기 좋게 잘라낸 책이 아니라, 팀이 같은 제품을 두고 회의할 때 필요한 순서로 짜여 있다.
PM이 쓰는 스펙, 디자이너가 쓰는 신뢰, 개발자가 쓰는 하네스, 리서처가 쓰는 정신 모델. 같은 프로덕트를 두고 각자 다른 단어를 쓰면 회의는 길어지고 책임은 흐려진다. 파트 2에서 전략 프레임을 공유하고, 파트 3에서 직무별 실행법을 펼친 뒤, 파트 4에서 현직자 이야기로 다시 수렴시킨다.
API 하나 얹은 기능 추가를 넘어, 스스로 판단하고 행동하는 에이전트를 전제로 한다. 할루시네이션, 폴백, 예외 상황도 보통 개발 뒤쪽에서야 등장하는 말들인데, 여기서는 기획 단계부터 끌어올린다. AI를 이상적으로 그리다가 현실에서 부서지는 팀을 많이 봤기 때문에, 이 태도는 꽤 고맙게 느껴졌다.
파트 2 앞부분의 AI 프로덕트 발전 4단계, SaaS와 엔터프라이즈 비즈니스 모델 비교는 읽기 편했다. 거창한 미래학이 아니라, 지금 내가 만드는 게 어느 단계에 해당하는지 감을 잡게 해준다. 속도와 효율의 경제로 넘어간다는 말도, 규모의 경제만 믿고 AI 기능을 얹었던 프로젝트들을 떠올리게 했다. 사용자 수가 늘수록 비용이 같이 늘어나는 구조에서는, 성장이 곧 손해일 수도 있다.
규칙 설계자에서 확률 조율자로
파트 2 기획 전략 챕터에서 규칙 설계자에서 확률 조율자로라는 프레임을 만났을 때, 잠깐 책을 덮었다.
기존 프로덕트 PM은 입력 A면 출력 B가 나오도록 규칙을 설계한다. 버튼 위치, 상태 전이, 예외 처리. 정답이 있다. AI 프로덕트 PM은 같은 질문에 매번 조금씩 다른 답이 나올 수 있는 확률 분포를 다룬다. 틀릴 수 있다가 버그가 아니라 전제다. 그러면 기획서는 어떻게 써야 할까. 성공 기준은 어떻게 잡아야 할까. A/B 테스트는 무엇을 비교해야 할까.
이 책이 제안하는 방향은 스펙 주도 개발과 AI 네이티브 PRD다. 사람만 읽는 기획서가 아니라, 에이전트가 이해하고 실행할 수 있는 명세를 쓰는 법. 처음엔 PM이 그걸 어디까지 알아?라는 반응이 나올 수 있다. 나도 그랬다. 그런데 바이브 코딩으로 MVP를 뽑아내는 PM이 늘어나는 지금, 기획의 산출물 형식 자체가 바뀌지 않으면 병목은 PM에게 돌아온다. 빠르게 만들었는데 왜 검증이 안 되지? 그 답이 여기 있다.
같은 챕터에서 코어 모델 중심 기획, 스코프와 유스케이스의 해상도를 어디까지 올릴지도 인상적이었다. AI 기능을 얹을수록 스코프가 불어나기 쉽다. 요약도 되고, 번역도 되고, 추천도 되고. 결국 아무것도 제대로 안 된다. 모델이 잘하는 좁은 문제부터 선명하게 정의하라고 말한다. 뻔해 보이지만, PoC 현장에서 가장 자주 깨지는 규칙이기도 하다.
AI 네이티브 프로덕트의 시장 출시 전략 파트도 짧지만 생각할 거리가 많다. 기능 출시와 함께 사용자가 무엇을 기대하는지, 에이전트를 고객으로 두면 온보딩과 과금 단위가 어떻게 바뀌는지. B2B SaaS에서 AI를 붙였을 때 영업 자료만 바꾸고 실제 사용 경험은 그대로인 경우를 봤다. 그 간극을 줄이려면 기획 단계부터 시장 출시를 붙잡아야 한다는 메시지로 읽혔다.
6장 PM 파트의 단위 경제학과 AI 프로덕트 지표도 실무형이다. MAU, 전환율만으로는 부족하다. 추론 비용, 재시도율, 사람 개입 비율, 폴백 발생률. 이 숫자들이 붙어야 AI 넣은 기능이 사업이 된다. 교육, 강의 쪽에서 AI PoC 수익화를 고민하는 입장에서, 이 파트는 메모장을 꺼내게 만든다.
같은 6장에서 PM 주도의 바이브 코딩과 초고속 MVP 검증 이야기도 현실적이다. 빠르게 만드는 것 자체가 목표가 아니라, 무엇을 검증하려고 빠르게 만드는지가 분명해야 한다는 뉘앙스. 나는 PoC를 여러 번 돌려봤는데, 데모 직후에 기술 성공과 사용자 성공을 같은 말처럼 쓰던 시기가 있었다. 사용자는 신기해했지만 돌아오지 않았다. 이 책은 그 착각을 기획 언어로 걷어내는 데 도움이 됐다.
예외 상황과 할루시네이션에 대비하는 폴백 기획 파트도 마음에 들었다. AI가 틀렸을 때 어떻게 보일지, 어디서 사람에게 넘길지, 실패를 숨길지 드러낼지. 개발자 몫처럼 보이는 일인데, 사실 사용자가 체감하는 순간은 UX다. PM이 여기까지 생각하지 않으면, 장애가 나왔을 때 팀만 바쁘고 사용자는 그냥 떠난다.
건축에서 정원 가꾸기로
개발 파트는 낭만을 깨는 데 시간을 쓴다. 바이브 코딩의 이상과 현실. 말로 만들면 끝이라는 환상을 조심스럽게 짓밟는다. AI가 코드를 빨리 쓰게 해주는 건 맞다. 그런데 아키텍처, 테스트, 관측 가능성, 장애 대응은 그 속도를 따라가지 않으면 기술 부채가 폭발한다.
9장에서 RAG, 프롬프트 엔지니어링, 추론 모델부터 에이전트까지 다루는데, 이미 LangChain을 돌려본 개발자에게는 얕게 느껴질 수 있다. 그런데 이 책의 개발 파트 목적은 깊은 구현 튜토리얼이 아니다. PM, 디자이너, 리서처가 개발팀이 왜 그렇게 말하는지 이해하게 만드는 공통어를 맞추는 데 있다.
하네스 엔지니어링, 모델 출력을 제품 안에서 안전하게 받아들이기 위한 감싸개와 검증, 제약이라는 개념은 AI 기능을 API 호출 한 줄로 생각하는 기획, 경영진에게 꼭 필요한 언어다. 모델이 똑똑해질수록 하네스 없이는 실서비스에 못 올린다. 데모는 되는데 배포는 안 된다, 이 말을 요즘 많이 듣는다. 그 원인 설명에 이 파트가 도움이 된다.
11장 개발자 인터뷰에서 프로덕트 엔지니어로의 진화 이야기도 설득력 있다. 코딩만 잘하는 사람보다, 문제 정의, 사용자 가치, 시스템 경계를 같이 보는 사람이 AI 시대에 더 오래 산다. 다만 개발자가 PM 일까지 해야 한다는 압박으로 읽힐 수도 있어서, 팀 구조에 따라 이 파트는 해석이 갈릴 것이다.
파트 1의 빅테크와 스타트업 접근법 비교는 가볍게 읽히지만, 완전히 스킵하기엔 아깝다. 같은 AI 기능이라도 조직 규모와 데이터, 배포 주기에 따라 전략이 달라진다는 전제가 깔려 있다. 거대한 참고 사례만 따라 하다가, 우리 팀 리소스와 안 맞는 로드맵을 짠 적이 있다. 그 실수를 줄이는 데 도움이 됐다.
5장의 자사 프로덕트에 AI 서비스 도입 전략, AI 엔지니어링 및 인프라 구축 파트는 신규 스타트업보다 기존 SaaS 팀에 더 와닿을 수 있다. 이미 사용자와 매출이 있는 제품에 AI를 얹을 때, 어디부터 뜯어고칠지, 어디는 API로 붙일지, 데이터 파이프라인은 어떻게 연결할지. 새로 만드는 경우만 다루는 책이 많은데, 여기는 기존 서비스를 고치는 질문도 섞여 있다. 레거시가 있는 팀이라면 이 파트를 메모해 두는 게 좋다.
AI의 불완전함을 경험으로 만드는 법
디자인, 리서치 파트가 이 책에서 가장 오래 남을 부분이라고 느껴졌다. 기술서 독자는 9장만 보고 넘어갈 수 있지만, AI 프로덕트의 체감 품질은 결국 UX에서 갈린다.
7장 UX 연구 파트에서 시간 효용성을 핵심으로 잡는다. AI 기능의 가치는 신기함이 아니라 사용자 시간을 얼마나 돌려주느냐다. 현장에서는 AI 넣었습니다로 끝나고, 정작 사용자는 검증, 수정, 재질문에 더 많은 시간을 쓰는 역설이 벌어진다. AI 온보딩 4가지 전략, 다이어리 스터디, A/B 테스트로 AI 기능 검증 같은 방법론을 구체적으로 제시한다. 학술 논문처럼 느껴지지 않게, 프로덕트 팀이 다음 스프린트에 가져갈 수 있는 언어로 풀어놓았다.
AI 프로덕트 경험을 구성하는 세 가지 요소, AI 윤리가 UX에 미치는 영향 같은 파트도 짧지만 기억에 남는다. 윤리를 거창한 슬로건으로 붙이지 않고, 사용자가 불안해하는 지점과 연결한다. 신뢰는 디자인 한 장면에서 갈린다는 말을, 예전에는 알았지만 이름 붙이기 어려웠다. 이 책은 그걸 리서치와 디자인 언어로 풀어준다.
8장 디자인 파트의 휴먼 인 더 루프와 에이전트 전용 UX는 특히 오래 남을 것 같다. AI 결과가 매번 다를 때, 사용자 신뢰는 어떻게 설계하는가. 로딩 중 한 줄로 끝낼 문제가 아니다. 불확실성을 숨기면 불신이 커지고, 그대로 노출하면 이탈이 커진다. 그 사이를 UX로 풀어야 한다. 에이전트 시대에는 버튼, 폼 중심 UI가 아니라, 목표, 권한, 중간 확인, 되돌리기가 인터페이스가 된다. 디자이너가 예쁜 화면을 넘어 위임의 경계를 그리는 역할. 이 책은 그걸 직무 정의로 말한다.
8장의 디자인 싱킹 프로세스와 PM·개발과의 협업 노하우도 실무 톤이다. 디자이너가 완성된 목업만 넘기는 구조에서는 AI 프로덕트가 잘 안 굴러간다. 모델 출력이 변할수록, 프로토타입과 스펙, 테스트가 더 자주 맞물려야 한다. 회의실에서 PM은 확률 이야기를 하고, 디자이너는 화면 이야기를 하고, 개발자는 토큰 이야기를 하는 장면. 이 책은 그 회의를 같은 방으로 끌어들이려는 시도다.
13장 리서처 파트의 조언자를 넘어 대행자로도 같은 맥락이다. 사용자는 AI에게 추천해줘를 넘어 해줘를 기대하기 시작했다. 그러면 리서치 질문도 바뀐다. 이 기능 쓸 만해?가 아니라, 어디까지 맡기고 싶어, 어디서 불안해져, 실패했을 때 누구 탓이야를 봐야 한다. AI와 인간의 단계적 위임 관계를 정립하는 연구 기법. UX 리서치 현장에서 바로 써먹을 프레임이다.
에이전트 UX 연구 방법 파트는 짧지만, 인터뷰 질문지를 새로 짜야 하는 팀에게는 실용적이다. 사용자에게 모델 성능을 묻기 전에, 기대 수준과 통제감을 먼저 묻는 순서. AI 교육 과정을 설계할 때도 비슷한 전환을 겪었다. 수강생에게 도구 사용법만 가르치면, 정작 수업 후에는 검색만 하고 끝나는 경우가 많았다. 위임과 검증을 어떻게 학습시킬지, 이 책의 리서치 파트는 그 질문을 제품 개발 쪽 언어로 다시 던진다.
8장과 13장을 연달아 읽으면, PM, 개발 파트에서 본 폴백 기획과 하네스가 UX 언어로 다시 돌아온다. 기술, 기획, 디자인, 리서치가 같은 그림을 보게 만드는 순간. 이 책 구성의 의도가 여기서 드러난다.
현직자 이야기와 부록
10~13장 직무별 인터뷰와 부록 넥스트 AI는 분량 대비 밀도가 높다. PM 챕터의 신사업 진출 사례는 거창한 성공담보다, 기존 역량 위에 AI를 어떻게 얹었는지가 분명해서 좋았다. UX 디자이너 파트의 엔지니어링 팀 협업 노하우, 리서처 파트의 멀티모달 이야기는 각각 한 권짜리 주제를 압축한 느낌이다. 깊게 파고들기보다, 내 직무 밖에서 무엇을 몰라왔는지 알게 해주는 역할을 한다.
부록 A, 빅테크는 지금 어떤 AI 인재를 찾는가는 채용 공고를 읽는 눈을 바꿔준다. 우리 팀에 AI 사람 한 명 뽑자가 왜 항상 애매하게 끝나는지. 직무 정의가 아직 흔들리는 시장에서, 프로덕트 팀이 어떤 역할과 협업해야 하는지 힌트를 준다.
부록 B 성공, 실패 케이스 스터디는 전략 파트를 검증한다. 이론만 있으면 공허한데, 그래서 시장에서 뭐가 됐고 뭐가 안 됐는지를 짧게라도 보여준다. 더 길었으면 좋겠다. 그래도 실무서에 실패 사례가 들어 있다는 것만으로도 신뢰는 올라간다.
9장은 얕고, 부록은 짧다
전략, UX, PM 파트는 다음 분기 전략 회의에 가져갈 문장이 많은데, RAG, 프롬프트, LLM 발전사 같은 개발 입문 파트는 이미 실무를 하는 개발자에게는 얕다. 반대로 비개발 PM에게는 9장이 갑자기 부담스러울 수 있다. PM을 위한 RAG 한 페이지, 개발자를 위한 UX 검증 체크리스트 같은 브릿지가 더 있었으면 한 권 완주율이 올라갔을 것이다.
조직, 거버넌스는 상대적으로 얇다. 개인, 스쿼드 단위 실무는 풍부한데, 엔터프라이즈 도입, 컴플라이언스, 감사, 데이터 거버넌스는 더 얇게 지나간다. B2B, SaaS 생존 전략을 말하면서, 구매, 보안, 법무와의 전쟁은 덜 그려진다. 스타트업, 프로덕트 팀 리더에게는 충분하지만, 대기업 AX 추진 조직은 그 다음 장은?을 찾게 될 수 있다.
마이크로소프트, VESSL AI, 글로벌 테크 중심의 시야는 한국 중소 SaaS, 교육, 공공, 로컬 서비스와는 온도 차가 있다. 프레임은 가져가되, 로컬 시장, 규제, 사용자 습관은 독자가 직접 번역해야 하는 부분이 남는다.
이 아쉬움 때문에 책의 가치가 줄어든다기보다, 80%에서 멈춘 지점이 팀 토론의 출발점이 된다. 우리 회사 버전의 폴백 기획은, 우리 사용자에게 시간 효용성을 어떻게 측정하지. 책이 끝까지 답을 주지 않아서, 읽은 팀이 이어서 써야 하는 책이다.
누구에게 맞는 책인가
AI 기능을 하나 추가하는 단계를 넘어, 프로덕트 전체를 AI 네이티브로 다시 설계하려는 PM, PO에게 맞다. 바이브 코딩으로 MVP는 만들지만, 온보딩, 지표, 폴백, 비용에서 막히는 1~5인 프로덕트 팀에도 맞다. AI 결과의 불확실성을 UX로 풀어야 하는 디자이너, UX 리서처, PM, 디자인, 개발, 리서치가 각자 다른 언어로 회의하는 조직의 리드, AI PoC는 했는데 수익, 유지, 확장이 안 된다고 느끼는 의사결정자에게도 맞다.
반대로 LLM 파인튜닝, 분산 학습, 딥러닝 구현을 깊게 배우려는 ML 엔지니어에게는 다른 책이 낫다. 개인 ChatGPT 활용법만 원하는 독자에게도 범위가 다르다. 완성된 체크리스트를 복붙하려는 사람에게도 맞지 않는다. 프레임은 주지만, 우리 팀 답은 직접 써야 한다.
팀에서 함께 읽는다면, 파트 2 전체를 공통 과제로 먼저 읽고 같은 전략 언어를 맞춘 뒤, 직무별로 파트 3 해당 장을 깊게 읽고 나머지는 훑는 방식이 좋다. 파트 4 인터뷰는 북클럽식으로 우리 팀 버전은?을 묻고, 부록 B 케이스로 회고를 하면 된다. 교육, 강의 조직이라면 AI 교육 커리큘럼 설계 시 기술 모듈과 프로덕트 모듈 사이를 잇는 교재 한 권으로도 쓸 만하다. 한 사람이 끝까지 읽기보다, 네 명이 각자 담당 파트를 발표하고 합치는 방식이 이 책 구조와 더 잘 맞는다.
읽는 순서를 하나만 꼽자면, PM이면 6장, 디자이너·리서처면 7~8장, 개발자면 9장부터 시작하고, 모두 파트 2는 공통으로 읽는 편이 낫다. 처음부터 1장부터 순서대로만 읽으면, 전략 파트에 도달하기 전에 9장에서 지루해질 수 있다. 이 책은 순서대로 읽는 교과서보다, 팀 상황에 맞게 끼워 읽는 참고서다.
메이커, AI 메이커
책 속으로에 나오는 AI 메이커라는 말이 마음에 걸렸다. AX 시대를 따라가는 사람이 아니라 주도하는 사람. 멋있게 들리지만, 현실은 더 단순하다. AI 메이커는 모델을 직접 만드는 사람만을 뜻하지 않는다. 확률적으로 움직이는 시스템 안에서, 사용자 신뢰와 단위 경제성을 동시에 설계하는 사람. PM이든, 디자이너든, 개발자든, 리서처든.
이 책을 다 읽고 나서 내게 남은 건 또 하나의 AI 트렌드 정리가 아니었다. 규칙 설계자로서 쓰던 기획서, 건축가로서 그리던 로드맵, 완성된 화면으로만 생각하던 UX. 그 전부를 한 번 의심하게 만드는 질문이었다. 다음 주 회의에서 뭘 바꿀지는 아직 정하지 못했다. 다만, AI 기능 하나를 논의할 때마다 자동으로 나오던 질문 목록은 생겼다. 비용은, 폴백은, 사용자 시간은, 위임 경계는.
AI를 쓰는 것과 AI로 만드는 것 사이의 간격이, 생각보다 훨씬 넓다. 그 간격을 팀으로 메우는 법을 찾는 사람이라면, 이 책은 출발점으로 괜찮다. 다만 출발점일 뿐이다. 정원은 직접 가꿔야 한다.
오늘도 찾아주셔서 감사합니다.
출처: https://patiencelee.tistory.com/1277 [PatienceLee:티스토리]
