
한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다.
AI 엔지니어 겸 PM이 읽는 'AI 프로덕트 기획과 운영': 두 세계를 연결하는 법
오전에는 모델 아키텍처를 설계하고, 오후에는 PRD(Product Requirements Document)를 작성합니다. 코드를 짜다가 사용자 인터뷰 일정을 확인하고, 모델 성능을 측정하다가 비즈니스 지표를 고민하죠. AI 엔지니어이면서 동시에 PM인 저는, 매일 두 개의 뇌를 번갈아 쓰는 것 같은 피로함을 느끼곤 합니다.
"이 모델의 정확도를 95%까지 올렸는데, 사용자는 왜 여전히 불만족할까?"
"사용자가 원하는 기능을 정확히 알겠는데, 기술적으로 어떻게 구현할지 막막하다."
혹시 이런 고민, 여러분도 해보셨나요?

'AI 프로덕트 기획과 운영'은 바로 이 두 세계 사이의 다리를 놓아주는 책입니다. 엔지니어링과 프로덕트 매니지먼트, 이 두 영역을 동시에 다루면서도 각각을 피상적으로만 훑지 않고 실무에서 바로 쓸 수 있는 구체적인 프레임워크를 제공해주고 있어요.
책의 구조: 이론부터 실전까지
이 책은 총 8개 챕터로 구성되어 있는데요, 앞부분은 AI PM의 역할과 필수 지식을 다루고, 뒷부분은 실전 프레임워크를 제공합니다.
1 AI 프로덕트 매니저의 역할
AI 프로덕트 매니저의 고유한 책임과, 기술적 진보를 사용자 중심의 솔루션으로 전환하는 역할에 대해 설명합니다. 1장에서는 AI 프로덕트 매니저가 일반 PM과 어떻게 다른지, 기술적 진보를 사용자 중심 솔루션으로 전환하는 과정을 설명해요. 저처럼 개발자에서 시작해서 PM 역할까지 하게 된 분들에게는, "아, 내가 하는 일이 이런 거였구나" 싶은 명확한 정의를 제공합니다.
2 AI 프로덕트 개발 라이프사이클
아이디어 발상, 프로토타입 제작, 테스트, 배포에 이르기까지 프로덕트를 이끄는 AI 프로덕트 개발 라이프사이클 프레임워크를 소개합니다.

2장의 AI 프로덕트 개발 라이프사이클은 특히 유용했어요. 아이디어 발상부터 프로토타입, 테스트, 배포까지의 전체 흐름을 한눈에 볼 수 있거든요. 엔지니어로서는 "구현" 단계에만 집중하기 쉬운데, PM 관점에서 보면 그 전후 단계가 얼마나 중요한지 알 수 있습니다.
3 AI PM의 필수 지식
일반 PM이 AI 중심의 역할로 전환하기 위해 필요한 개념과 이러한 원리들이 어떻게 사용자에게 영향을 미치는 프로덕트로 구현되는지 다룹니다. 3장은 일반 PM이 AI 중심 역할로 전환하기 위한 필수 개념들을 다루는데, 저처럼 반대로 엔지니어가 PM 역할을 하는 경우에도 "이 기술 개념을 프로덕트 언어로 어떻게 설명할까?"를 배울 수 있어서 도움이 됐습니다.
4 AI PM의 업무
AI 프로덕트 매니저의 독특한 업무 흐름을 설명하며, 협업 중심의 업무, 다양한 이해관계자와의 소통, 지속적인 학습의 중요성을 강조합니다. AI PM의 일상적인 업무 흐름과 전략적 사고를 다루고 있어요.
5 AI에서의 전략적 사고
엔지니어, 디자이너, 이해관계자로 구성된 다양한 팀을 이끄는 전략을 제시합니다. 특히 이번 장은 제가 프로젝트를 운영하면서 실제로 겪었던 소통의 어려움에 대한 해답을 제시해줬습니다.
6 목표 설정과 성공 측정
성공 지표를 정의하고, 정확성과 속도 간의 트레이드오프를 균형 있게 고려하면서, AI 고유의 리스크를 관리하는 방법을 설명합니다.
6장의 목표 설정과 성공 측정은 제가 가장 약했던 부분이에요. 정확성과 속도 사이의 트레이드오프를 어떻게 정량화하고 이해관계자에게 설명할지, AI 고유의 리스크를 어떻게 관리할지에 대한 실용적인 가이드를 제공합니다.
7 PM을 위한 AI 툴
AI 프로덕트 개발 라이프사이클 전반에 걸쳐 중요한 툴과 기술을 소개합니다. 7장은 PM을 위한 AI 툴을 소개하는데, 엔지니어 입장에서도 "PM이 이런 툴을 쓰는구나"를 알게 되면 협업할 때 공통 언어가 생기더라고요.
8 AI 에이전트 구축
자율 AI 에이전트에 대해 다루며, 멀티 에이전트 시스템, 강화 학습, 그리고 실제 프로덕트에서의 활용 사례를 설명합니다. 여기서 앞선 7개 챕터의 이론과 프레임워크가 모두 실전 가이드로 통합됩니다. 이 챕터가 가장 흥미로웠습니다.
책 전체의 시너지
처음에는 8장이 가장 실용적이고 바로 써먹을 수 있어서 가장 좋았어요. 하지만 책을 다 읽고 나니, 앞선 챕터들이 없었다면 8장도 제대로 이해하지 못했을 거라는 걸 깨달았습니다.
3장 "AI PM의 필수 지식"에서 다룬 개념들이 8장의 실전 가이드로 자연스럽게 연결되더라고요. 제가 당연하게 알고 있다고 생각했던 기술 개념들을 프로덕트 관점에서 완전히 다르게 볼 수 있게 해줬어요.
6장 "목표 설정과 성공 측정"에서 배운 "AI 고유의 리스크 관리"는 8장의 성공 지표를 정의할 때 직접적으로 도움이 됐습니다. 정확성과 속도의 트레이드오프를 어떻게 정량화할지, 이해관계자에게 어떻게 설명할지에 대한 구체적인 방법을 알게 됐죠.
7장의 툴 소개도 단순한 툴 리스트가 아니었어요. "PM이 이런 툴을 쓰는구나"를 알게 되니까 협업할 때 공통 언어가 생기더라고요. 엔지니어로서 익숙한 툴도 PM 관점에서 어떻게 활용하는지 배울 수 있었습니다.
이 책의 진짜 가치는 각 챕터가 독립적으로도 훌륭하지만, 함께 읽었을 때 시너지가 난다는 거예요. 1장부터 7장까지가 토대를 만들고, 8장에서 모든 게 실전으로 통합됩니다.
가장 먼저 답해야 할 질문: 내가 해결하고자 하는 문제는 무엇인가?
책에서 제시하는 질문입니다. 내가 만들려는 건 특정 작업에 특화된 에이전트인가, 아니면 여러 작업을 처리할 수 있는 범용 에이전트인가?

특정 작업용 에이전트는 이메일 필터링이나 티켓 예약처럼 명확한 단일 목적을 가지고 있습니다. 조건과 반응 규칙을 바탕으로 작동하고, 별도의 학습 없이도 정해진 방식대로 일을 처리하죠. 반면 범용 에이전트는 변화하는 환경에 맞춰 스스로 응답을 조정하는 내부 세계 모델을 갖추고 있어요. 항공권 예약부터 콘텐츠 생성까지 다양한 작업을 소화할 수 있습니다.
엔지니어로서의 저는 당연히 "더 범용적인" 시스템을 만들고 싶어합니다. 기술적으로 훨씬 도전적이고, 솔직히 말하면 더 멋있어 보이거든요. 하지만 PM으로서의 저는 "빨리 출시해서 사용자 반응을 봐야 한다"고 속삭입니다.
실제로 고객 지원 챗봇을 만들 때가 그랬어요. 엔지니어 모드로 들어간 저는 "모든 질문에 답할 수 있는" LLM 기반 범용 모델을 설계했습니다. 온갖 시나리오를 커버할 수 있는 완벽한 시스템을 그렸죠. 하지만 PM 모드로 전환해서 사용자 데이터를 분석해보니, 전체 문의의 80%가 단 5가지 유형에 집중되어 있더라고요. "배송 조회는 어떻게 하나요?", "환불 정책이 뭔가요?" 같은 반복적인 질문들이었습니다.
책에서는 이렇게 조언합니다. 사용자가 가장 시급하게 필요로 하는 부분을 먼저 정의하라고요. 결국 저는 방향을 완전히 바꿨습니다. 룰 기반 특정 작업용 봇으로 먼저 출시하고, 사용자 피드백을 받아가며 점진적으로 범용화하는 전략을 택한 거죠. 3개월을 허비할 뻔했는데, 2주 만에 출시할 수 있었습니다.
두 역할을 동시에 하다 보니 오히려 이런 게 명확해지더라고요. 기술적 야망과 사용자 니즈 사이의 스위트 스팟을 찾는 게 핵심이라는 걸요. 엔지니어 관점만 있었다면 계속 범용 시스템에 매달렸을 거고, PM 관점만 있었다면 기술적 확장 가능성을 놓쳤을 겁니다.
"언제 말을 걸까?"의 미묘한 차이
에이전트가 언제, 어떻게 사용자와 상호작용할지 결정하는 것. 이게 생각보다 훨씬 어려운 문제더라고요.
반응형 에이전트는 사용자가 먼저 말을 걸 때까지 기다립니다. 텍스트를 입력하거나 음성으로 명령을 내려야만 반응하죠. 우리가 흔히 쓰는 챗봇이나 음성 비서가 대표적이에요. 사용자가 "오늘 날씨 어때?"라고 물어봐야 답을 해주는 거죠.
반면 능동형 에이전트는 사용자 행동을 지켜보다가 먼저 말을 겁니다. 캘린더에서 일정 충돌을 발견하면 사용자에게 알려주고, 더 나아가 자동으로 재조정을 제안하기도 해요. 사용자가 요청하지 않았는데도 말이죠.
엔지니어로서는 능동형이 훨씬 흥미진진합니다. 사용자 컨텍스트를 추론하고, 개입할 타이밍을 판단하고, 여러 신호를 통합해서 처리하는... 기술적으로 정말 도전적인 문제들이거든요. 머릿속으로 아키텍처를 그리는 것만으로도 즐거워요.
하지만 PM으로서는 걱정이 앞섭니다. 사용자가 집중해서 일하고 있는데 갑자기 알림이 뜬다면? 그게 도움이 될까요, 방해가 될까요? 잘못된 타이밍에 제안했다가 오히려 신뢰를 잃는 건 아닐까요?
문서 작성 지원 AI를 만들 때의 경험을 공유해드릴게요. 저는 능동형으로 설계했습니다. 사용자가 3초 이상 타이핑을 멈추면 "지금 막혔나 보다"고 판단하고 자동으로 제안을 띄우는 거죠. 엔지니어 관점에서는 완벽했어요. 추론 latency 200ms, 제안 정확도 87%. 수치상으로는 훌륭했습니다.
그런데 사용자 테스트 결과는... 처참했어요. "생각하는 중에 자꾸 끼어들어서 짜증난다"는 피드백이 쏟아졌습니다. 타이핑을 멈춘 게 막힌 게 아니라 그냥 생각을 정리하고 있었던 거예요. AI는 "도와줘야지!"라고 생각했지만, 사용자는 "제발 좀 가만히 있어줘"라고 느낀 거죠.
책에서는 이렇게 말합니다. 에이전트가 너무 방해되거나 부담스럽지 않으면서도 실질적인 가치를 제공하도록 만들어야 한다고요. 결국 저는 기본값을 반응형으로 전환했습니다. 대신 능동형 제안은 옵트인 기능으로 남겨뒀어요. 원하는 사용자만 켤 수 있게요.
여기서 깨달은 게 있어요. 기술적으로 가능한 것과 사용자가 원하는 것의 교집합을 찾는 게 바로 우리의 역할이라는 거죠. 두 관점을 동시에 가지고 있으니, 이 균형점을 더 빨리 찾을 수 있었습니다. 엔지니어 관점만 있었다면 "왜 이렇게 좋은 기능을 안 쓰지?"라고 의아해했을 거고, PM 관점만 있었다면 "이거 기술적으로 구현 가능해?"라고 물어봤을 거예요.
자율성 스펙트럼
"AI에게 얼마나 많은 권한을 줄 것인가?" 이 질문이 제가 가장 많이 고민하는 부분입니다.
자율성은 크게 세 단계로 나눌 수 있어요.
- 첫 번째는 지원 단계로, AI가 정보를 제공하거나 추천만 하는 거죠. "이 제품 어때요?"라고 제안하는 수준이에요.
- 두 번째는 안내형 업무로, AI가 주요 정보를 대신 입력해줍니다. "항공권 검색해서 옵션 보여드릴게요"처럼요.
- 세 번째는 완전 자동화로, 처음부터 끝까지 AI가 알아서 처리합니다. "항공권 예약 완료했습니다"라고 보고하는 거죠.
엔지니어로서는 당연히 "완전 자동화"를 목표로 시스템을 설계하고 싶습니다. End-to-end 학습, 자율 의사결정, 최소한의 인간 개입. 기술적으로 가장 우아한 솔루션이거든요. 논문에서 봤던 멋진 아키텍처들이 머릿속에 떠오르죠.
하지만 PM으로서는 사용자 신뢰도가 더 중요합니다. 책에서 든 AI 쇼핑 에이전트 예시가 정확히 제 경험과 맞아떨어지더라고요.
책에서 말하는 "점진적으로 자율성을 확대"하는 접근법이 정답이었습니다. 이건 기술 문제가 아니라 신뢰 구축 프로세스더라고요. 아무리 기술이 완벽해도 사용자가 믿지 않으면 쓸모가 없습니다.
엔지니어 겸 PM으로서 저는 이제 모델 설계 단계부터 "자율성 확장 로드맵"을 함께 그립니다. 기술적으로는 처음부터 3단계를 지원할 수 있게 만들어요. 하지만 출시할 때는 1단계로 시작합니다. 나중에 설정 하나만 바꾸면 되도록 설계하는 거죠. 기술은 준비돼 있지만, 사용자의 신뢰가 쌓일 때까지 기다리는 겁니다.
같은 모델, 전혀 다른 제품이 되는 순간
책을 읽으면서 가장 놀라웠던 공감했던 건 인터페이스 설계가 곧 제품 전략이라는 것. 같은 AI 모델이라도 어떤 인터페이스로 제공하느냐에 따라 완전히 다른 제품이 된다는 거죠. 책에서는 여러 디자인 패턴을 소개하는데요, 각각이 다른 사용 시나리오에 최적화되어 있습니다. 또한 이런 설계 능력을 기르려면 다른 좋은 프로덕트를 많이 리뷰해야 한다고 생각합니다. 그동안 리뷰 템플릿을 찾아 헤맸었는데 책에서 또 하나의 답을 주더라고요 ! (만세!)

두 세계를 넘나드는 방법
이 책을 읽고 나서 깨달은 건, AI 엔지니어와 PM은 같은 문제를 해결하되, 출발점이 다르다는 거예요.
- 엔지니어는 "이런 기술이 있는데, 어디에 쓸까?"에서 시작합니다.
- PM은 "이런 문제가 있는데, 어떤 기술로 풀까?"에서 시작하는 것 같습니다.
저는 운 좋게도 두 출발점을 모두 경험했습니다.
그래서 기술 트렌드를 사용자 니즈로 번역할 수 있고, 사용자 요구사항을 기술 스펙으로 구체화할 수 있습니다. 구현 가능성과 사용자 가치를 동시에 평가할 수 있죠. 1장에서 말하는 "기술적 진보를 사용자 중심 솔루션으로 전환"하는 게 바로 이런 것이라고 생각합니다.
책을 통해 얻은 인사이트로 인해 PRD를 쓸 때부터 구현 아키텍처를 고려하고, 모델을 설계할 때부터 사용자 시나리오를 그립니다. 기술 선택에 비즈니스 임팩트를 포함하고, 프로덕트 로드맵에 기술 부채 관리를 넣게 되었습니다.

또한 기술 지표와 비즈니스 지표를 통합적으로 보게 되었습니다.를 봅니다.
- Inference Latency 개선 → Task Completion Rate 상승 → User Satisfaction 증가
- Model Confidence 표시 → 인간 개입 빈도 감소 → Daily Active Users 증가
- 추론 근거 제공 → 신뢰도 향상 → Churn Rate 감소
이 책이 특별한 이유
시중에 AI 책은 정말 많잖아요. 기술서는 알고리즘과 수식을 다루고, 비즈니스서는 전략과 트렌드를 다룹니다. 하지만 둘을 진짜로 연결하는 책은 정말 드물어요. 그 포인트가 이 책을 추천하게 만드는 것 같습니다.
3장에서 AI PM의 필수 지식을 다루지만, 그냥 개념 나열로 끝나지 않습니다. "이 원리가 실제 프로덕트에서 어떻게 구현되는지"까지 보여줍니다. 6장에서 목표 설정과 성공 측정을 다룰 때도, 단순히 "OKR을 세워라"가 아니라 "정확성과 속도의 트레이드오프를 어떻게 정량화할 것인가"까지 구체적으로 설명해요.
7장의 AI 툴 소개도 단순한 툴 리스트가 아니에요. 개발 라이프사이클의 각 단계에서 어떤 툴이 왜 필요한지, PM과 엔지니어가 어떻게 협업할 수 있는지를 보여줍니다.
그리고 8장에서 모든 게 통합됩니다. 앞선 챕터들의 이론과 프레임워크가 실전 가이드로 녹아듭니다.
각 프레임워크가 기술 결정과 프로덕트 결정을 동시에 안내해줍니다.
이런 분들께 추천합니다
먼저, AI 엔지니어이면서 PM 역할도 하시는 분들께 강력히 추천합니다.
아마 "혼자 싸우고 있다"는 느낌이 들텐데, 이를 위로해주면서도 두 역할을 효과적으로 통합하는 구체적인 방법을 제시해줍니다.
스타트업에서 혼자 AI 제품을 만드시는 분들에게도 매우 좋을 것 같습니다. 리소스가 부족할 때 어디에 집중해야 할지, 무엇을 먼저 만들고 무엇을 나중에 추가할지에 대한 명확한 가이드를 얻을 수 있습니다.
AI 조직의 리드나 매니저로 성장하고 싶으신 엔지니어분들께도 추천드려요. 5장의 전략적 사고와 4장의 이해관계자 소통 방법은 리더십에 바로 적용할 수 있는 실용적인 조언들이라 생각합니다.
그리고 무엇보다, 기술과 비즈니스 사이의 간극을 메우고 싶으신 모든 분들께 이 책을 권합니다. 두 세계의 언어를 배우면, 혼자서도 훨씬 더 완성도 높은 제품을 만들 수 있을 것이라 확신합니다!
AI로 제품 만드는 사람의 머릿속을 체계화해주는 책.
엔지니어와 PM, 두 역할 사이에서 길을 잃었다면 이 책이 훌륭한 지도가 되어줄 거예요.
이렇게 읽으면 좋아요
- 순서대로 읽는 것을 추천합니다. 1-7장이 만드는 기초 위에 8장이 빛을 발해요.
- 하지만 당장 에이전트를 구현해야 한다면 8장부터 시작한 뒤, 필요한 챕터로 돌아가도 괜찮습니다.
- 자신이 약한 부분의 챕터는 더 꼼꼼히 읽으세요. 저는 6장(성공 측정)을 두 번 읽었어요.
- 구현 중인 프로젝트와 연결하며 읽으면 효과가 2배입니다.
- 각 프레임워크를 실제 의사결정에 바로 적용해보세요. 이론으로만 두지 마세요.
'ML & DL > 책 & 강의' 카테고리의 다른 글
| [나는 리뷰어다] 바이브 코딩 너머 개발자 생존법 (1) | 2025.11.30 |
|---|---|
| 밑바닥부터 만들면서 배우는 LLM (0) | 2025.11.23 |
| 객체지향 시스템 디자인 원칙 (0) | 2025.09.14 |
| [나는 리뷰어다] 코드 너머, 회사보다 오래 남을 개발자 (5) | 2025.08.31 |
| [나는 리뷰어다] 파인만의 컴퓨터 강의 2판 (8) | 2025.07.27 |
댓글