Field Log · Entry

[책 리뷰] 개발 함정을 탈출하라 — 나는 웨이터형 PM이었다

요즘 『개발 함정을 탈출하라(Escaping the Build Trap)』라는 책을 읽고 있다. 처음 몇 챕터를 읽으면서 가장 먼저 떠오른 건 지금 내가 하고 있는 일이었다. 나는 한 고객사를 위한 AI Agent를 만들고 있고, 실 사용자들의 인터뷰와 요청을 듣고, 그들이 필요하다고 말하는 기능을 정리해 개발에 반영하는 일을 한다. 겉으로 보면 이건 매우 당연한 일처럼 보였다. 그런데 이 책은 첫 챕터부터 “그게 바로 나쁜 PM의 전형”이라고 말한다.

이 글은 책에 대한 정리이자, 그 정리에 비춰 나 자신을 돌아본 감상문이다. 답을 찾으려는 글이 아니라, 책을 읽으면서 생긴 자기 인식과 의문을 기록해두는 데 가깝다.

책이 말하는 나쁜 PM 3유형

저자는 프로덕트 매니지먼트가 제대로 가르쳐지지 않는 분야라고 말한다. 대부분의 PM이 실제로 배우는 일은 요구사항 문서 작성, 사용자 스토리 정리, 개발자와의 회의, 일정 관리, 버그 확인, 기능 검수 같은 것들이다. 이런 일은 전통적인 폭포수형 개발 방식에서 나온 PM의 업무에 가깝다. “무엇을 만들어야 하는가”를 깊게 고민하기보다, 이미 정해진 요구를 문서화하고 개발팀에 전달하는 일에 무게가 실린다.

이 방식 안에서 자라난 PM은 자주 세 가지 나쁜 유형 중 하나로 고착된다. 미니 CEO형, 웨이터형, 전직 프로젝트 매니저형이다.

1. 미니 CEO형 PM

미니 CEO형 PM은 자신을 제품의 최고 결정권자처럼 생각하는 사람이다. 채용공고에서 PM을 “프로덕트의 미니 CEO”라고 표현하는 경우가 많은데, 이 표현을 곧이곧대로 받아들인 결과다. 팀원들에게 명령하고, 자기 아이디어를 검증 없이 밀어붙이고, 개발자와 디자이너를 지시 대상처럼 본다.

문제는 PM이 실제 CEO가 아니라는 점이다. PM에게는 인사권도, 예산 권한도, 조직 구조를 바꿀 힘도 없다. 그런데도 권한이 있는 것처럼 행동하면 팀은 빠르게 신뢰를 잃는다.

나쁜 예시

• “이 기능은 내가 보기엔 꼭 필요해요. 그냥 이렇게 개발해주세요.”
• “디자인은 이렇게 가면 됩니다. 더 논의할 필요 없어요.”
• “개발팀은 제가 정한 방향대로 구현만 해주세요.”

이런 PM 밑에서는 팀원의 전문성이 무시되고, 고객 문제보다 PM의 머릿속 아이디어가 우선되며, 검증 없이 기능이 쏟아진다. 결국 제품은 사용자의 문제가 아니라 PM의 생각을 반영하는 물건이 된다.

좋은 PM이라면 같은 상황에서 이렇게 말해야 한다.

“내가 보기엔 이 방향이 가능성이 있어 보여요. 다만 고객 문제와 데이터로 검증해보고 싶어요. 개발자와 디자이너 관점에서는 어떤 리스크가 있을까요?“

2. 웨이터형 PM

웨이터형 PM은 고객, 영업, 이해관계자, 임원 등에게 가서 “무엇이 필요하세요?”를 묻고, 그렇게 받은 요구사항을 그대로 정리해 개발팀에 전달하는 사람이다. 겉으로 보면 매우 협조적이고 사용자 중심처럼 보인다. 하지만 책은 이것이 좋은 PM의 모습이 아니라 제품을 망치는 방식이라고 단호하게 말한다.

이유는 단순하다. 사람들이 말하는 것은 대개 자신이 겪는 문제 그 자체가 아니라, 자신이 떠올린 해결책이기 때문이다.

예를 들어 어떤 사용자가 “검색 필터를 더 만들어주세요”라고 말했다고 하자. 진짜 문제는 필터가 부족한 게 아닐 수도 있다. 그 뒤에 있을 가능성이 있는 진짜 문제는 이런 것들이다.

• 원하는 정보를 찾기 어렵다
• 검색 결과가 너무 많다
• 데이터 구조가 복잡해서 어떤 기준으로 봐야 할지 모른다
• 기존 화면 흐름이 불편하다
• 권한이나 접근성 문제로 일부 데이터만 보고 있다

웨이터형 PM은 이런 가능성을 파고들지 않는다. 그냥 “검색 필터 추가”를 요구사항 목록에 옮긴다. 그렇게 제품은 점점 기능만 많아지고, 실제 문제는 거의 그대로 남는다.

책은 이런 흐름을 “프로덕트 사망 주기(Product Death Cycle)“라고 부른다.

아무도 우리 제품을 사용하지 않는다 → 고객에게 어떤 기능이 부족한지 묻는다 → 부족하다는 기능을 개발한다 → 그래도 아무도 사용하지 않는다 → 다시 고객에게 부족한 기능을 묻는다

PM이 계속 “무엇을 더 만들까?”만 묻고 있을 때 이 사이클은 끝나지 않는다. 책이 던지는 진짜 질문은 “왜 사용하지 않는가? 고객이 실제로 하려는 일은 무엇인가? 그 일을 지금 제품이 왜 못 도와주고 있는가?”이다.

3. 전직 프로젝트 매니저형 PM

세 번째 유형의 이름이 좀 헷갈리기 쉬운데, 전직 “프로덕트” 매니저가 아니라 전직 “프로젝트” 매니저다. 정확히는 Product Manager 자리를 맡고 있지만 일하는 방식은 여전히 Project Manager인 사람이다.

이 유형은 일정, 마감, 리소스, 진행률을 중심으로 사고한다.

• “이번 기능은 언제까지 끝낼 수 있나요?”
• “마감일 맞출 수 있나요?”
• “일정표대로 진행되고 있나요?”
• “이번 주까지 개발 완료해주세요.”

이 질문 자체가 나쁜 것은 아니다. 일정 관리는 필요하다. 문제는 PM이 이 질문만 하게 되는 경우다. 책은 프로젝트 매니저는 “언제”를 책임지지만, 프로덕트 매니저는 “왜”를 책임져야 한다고 말한다.

• 프로젝트 매니저: 언제 완성할 것인가, 일정이 밀리는가, 마감을 맞출 수 있는가
• 프로덕트 매니저: 왜 이걸 만드는가, 이 기능이 고객에게 어떤 가치를 주는가, 사업 목표와 어떻게 연결되는가, 이 문제가 정말 중요한가

“왜”라는 질문은 “언제”라는 질문보다 훨씬 어렵다. 고객, 시장, 사업, 조직을 모두 이해해야 답할 수 있기 때문이다. 그래서 프로젝트 매니저 출신 PM이 충분한 제품 경험 없이 그 자리로 옮겨오면, 익숙한 일정 관리에 머무르기 쉽다. 결과적으로 일정대로 출시는 했는데 제품은 실패하는, 묘하게 성공한 것 같은 실패가 반복된다.

한눈에 비교

세 유형을 표로 정리하면 이렇게 된다.

유형	핵심 태도	자주 하는 말	문제점
미니 CEO	내가 정한다	”내가 정했으니 이렇게 개발하세요”	독단·팀 전문성 무시·검증 부재
웨이터	들은 대로 한다	”고객이 원하니까 만들어주세요”	진짜 문제 미파악·기능만 비대
전직 프로젝트 매니저	일정대로 끝낸다	”언제까지 완료되나요?”	가치보다 산출물·“왜”의 부재

저자의 메시지를 한 문장으로 줄이면 이렇다.

미니 CEO는 자기 생각을 제품으로 만든다. 웨이터는 고객의 요구사항을 그대로 제품으로 만든다. 전직 프로젝트 매니저는 일정표를 제품으로 착각한다.

좋은 PM은 이 셋 모두와 다르게 움직여야 한다. 고객의 문제를 이해하고, 팀과 함께 해결책을 찾고, 왜 지금 이것을 만들어야 하는지 판단하는 사람.

그 셋 중에 나는 어디에 속해 있을까

여기까지 정리하고 나니, 솔직히 가장 마음에 걸린 건 두 번째 유형이었다.

나는 지금 한 고객사를 위한 AI Agent를 만들고 있다. 일하는 방식은 대체로 이렇다. 고객과 미팅을 한다. 실 사용자가 어떤 점이 불편하다고 말한다. 어떤 기능이 있으면 좋겠다고 말한다. 어떤 화면이 필요하다고 말한다. 나는 그것을 진지하게 받아들이고, 개발 항목으로 정리한다. 사용자가 직접 말한 요구사항이기 때문에 그것을 반영하는 게 맞다고 생각해왔다.

겉으로 보면 이건 매우 당연하고 올바른 일처럼 보인다. 사용자의 목소리를 듣는 것은 중요하다. 특히 내가 만드는 서비스는 실제 현업 사용자가 있고, 그들이 사용해야 의미가 있다. 그래서 그들이 “이 기능이 필요하다”, “이런 화면이 있으면 좋겠다”, “이런 방식으로 조회되면 좋겠다”고 말하면, 나는 그것을 꽤 진지하게 받아들였다.

그런데 책의 표현으로 정리해보면, 이건 거의 그대로 웨이터형 PM의 행동이다. 고객이 원하는 기능을 묻고, 그 기능을 받아 적고, 개발팀(혹은 나 자신)에게 넘긴다. 이 자각이 좀 불편했다.

”분명히 만들었는데 안 쓰는 기능”이라는 경험

더 불편했던 건, 책이 묘사하는 실패 패턴이 내 경험과 어느 정도 맞는다는 점이었다.

분명히 회의에서는 필요하다고 했다. 분명히 있으면 좋겠다고 했다. 어떤 경우엔 사용자가 꽤 강하게 요청하기도 했다. 그래서 만들었다. 그런데 막상 기능이 제공된 뒤에는 사용 빈도가 낮거나, 현업 업무 흐름에 깊게 들어가지 못하는 경우가 종종 있었다.

이 경험 때문에 책 내용이 더 불편하게 다가왔다. 인터뷰까지 했는데 왜 사용하지 않을까? 사용자가 원한다고 해서 만들었는데, 왜 제품의 가치로 이어지지 않을까? 사용자의 요구사항을 반영하는 일이 왜 제품을 성공시키는 길이 아닐 수 있을까? 이 질문이 계속 남았다.

책이 그 이유로 제시하는 설명은 단순하지만 뼈아프다.

사용자가 말하는 것은 종종 “문제”가 아니라 “사용자가 생각한 해결책”이다.

사용자는 자신이 겪는 불편함을 바탕으로 “이런 기능이 있으면 좋겠다”고 말한다. 하지만 그 기능이 실제 문제를 해결하는 최선의 방법인지는 별개의 문제다. 사용자는 자신의 업무 상황 안에서 보이는 것을 말하지만, 제품 전체의 방향성, 사용 흐름, 운영 가능성, 다른 사용자와의 공통 문제, 장기적인 제품 전략까지 모두 고려해서 말하는 것은 아니다.

그런데 나는 그동안 사용자가 말한 기능을 거의 곧바로 “해야 할 일”로 받아들였던 것 같다. 사용자가 필요하다고 말하면, 그것이 곧 사용자의 진짜 문제라고 가정했다. 그리고 그 기능을 잘 구현하면 만족도가 올라갈 것이라고 믿었다. 책을 읽고 나니, 그 사이에 내가 빠뜨린 단계가 있었던 것 같다.

만들기 전에 한 번은 더 물었어야 했던 것

사용자가 말한 요구사항을 바로 개발 항목으로 바꾸기 전에, 나는 이런 질문을 먼저 던졌어야 했다.

• 이 사용자는 왜 이 기능이 필요하다고 느꼈을까?
• 이 기능이 없어서 정말 업무가 막히는 걸까, 아니면 다른 진짜 병목이 있는데 그게 기능 요청의 형태로 표현된 걸까?
• 이 기능을 만들면 실제 사용 빈도가 올라갈까?
• 이 기능이 사용자의 핵심 문제를 해결할까, 아니면 “있으면 좋은” 정도일까?
• 이 요청은 특정 한 사람의 선호일까, 여러 사용자의 공통 문제일까?
• 이 기능을 만들지 않고도 같은 문제를 해결할 다른 방법은 없을까?

지금까지 나는 사용자의 요구사항을 잘 듣는 것이 중요하다고 생각했다. 그건 지금도 맞다고 생각한다. 다만 책을 읽으면서 분명해진 건, 사용자의 말을 듣는 것과 사용자의 말을 그대로 구현하는 것은 다르다는 것이다. 좋은 PM은 사용자의 말을 무시하는 사람이 아니라, 사용자의 말 뒤에 있는 문제를 더 깊게 이해하려는 사람에 가깝다.

내가 만들고 있는 AI Agent에서는 이 문제가 특히 크게 작동할 수 있다는 생각도 들었다. 사용자는 “검색이 잘 되게 해달라”, “보고서를 자동으로 만들어달라”, “이런 버튼을 추가해달라”, “이런 조건으로 필터링하게 해달라”고 말한다. 이 말이 곧바로 기능 정의로 번역되면, 제품은 점점 기능 목록처럼 변한다. 기능은 늘어나는데, 사용자가 실제로 어떤 업무를 더 잘하게 되는지는 흐릿해진다.

특히 LLM 기반 시스템에서는 이런 요청이 자주 들어온다.

• “RAG 성능을 올려주세요”
• “Text-to-SQL도 넣어주세요”
• “GraphRAG도 검토해보면 어떨까요”
• “워크플로우 엔진을 붙이는 게 좋지 않을까요”

웨이터형 PM의 대응은 이 요청들을 그대로 기능 목록으로 옮긴다. 좋은 PM의 대응은 먼저 이렇게 묻는 것이다.

• 사용자가 실제로 실패하는 지점은 어디인가? 검색 결과가 틀린 건가, 문서 범위가 섞이는 건가, 답변 생성이 잘못된 건가?
• Text-to-SQL이 정말 필요한 문제인가, 아니면 단순 조회 UI가 필요한 문제인가?
• 그래프 구조의 관계 탐색이 실제로 필요한 질문이 충분히 많은가, 아니면 한두 개 예시만 그렇게 보이는가?
• 워크플로우 엔진이 필요한 진짜 이유가 장기 실행인가, 재시도인가, 상태 추적인가?

요청을 기능으로 바로 번역하지 않고, 한 단계 위인 문제 구조로 다시 쓰는 일이다.

그래도 남는 의문

다 정리해놓고도, 아직 내 안에 의문은 남아 있다.

사용자가 직접 말한 요구사항을 반영하지 않는 것이 정말 맞는가? 사용자가 필요하다고 말하는데, 그것을 PM이 판단해서 보류하거나 거절해도 되는가? 그건 또 다른 형태의 미니 CEO 아닐까? 사용자의 말을 듣지 않는 것과, 사용자의 말을 그대로 구현하지 않는 것 사이의 균형은 어떻게 잡아야 하는가? 책은 그 둘이 다르다고 말하지만, 실제 업무에서 그 경계는 자주 흐릿하다. 이 질문에 대한 답은 아직 내 안에 없다.

다만 이 책을 읽으면서 한 가지는 분명해졌다. 나는 앞으로 사용자의 요구사항을 들을 때, 그것을 곧바로 개발 목록으로 바꾸기 전에 한 번 더 생각해야 한다. 사용자의 말은 중요하지만, 그것은 출발점이지 결론은 아니다. 사용자가 말한 기능이 아니라, 사용자가 겪는 문제를 봐야 한다. 그리고 그 문제를 해결하는 가장 좋은 방법이 정말 그 기능인지 판단해야 한다.

두 번째 자각: 혼자 일하면 셋이 한 사람 안에 들어온다

글을 한 번 다 쓰고 다시 읽어보다가 한 가지를 더 깨달았다. 나는 웨이터형에만 기울어 있는 게 아니었다. 사실은 미니 CEO도 같이 하고 있었다. 사용자가 말한 기능을 받아 적어 개발에 넘기는 것도 사실이지만, 동시에 내가 머릿속에서 “이게 필요할 것 같다”고 판단한 기능을 검증 없이 그대로 만들어 넣는 일도 적지 않았다. 받아 적기와 직접 정하기를, 같은 사람이 번갈아 하고 있었다.

조금 더 솔직하게 정리하면, 만약 내가 실제 팀 안에서 일하는 PM이었다면 아마 세 유형 모두에 해당했을 것이다. 일정에 쫓겼다면 전직 프로젝트 매니저처럼 “언제 끝낼 거냐”가 가장 큰 질문이 됐을 것이고, 내 머릿속 아이디어를 밀어붙일 권한이 더 있었다면 미니 CEO 쪽으로 더 기울었을 것이고, 고객 미팅에서는 지금처럼 웨이터가 됐을 것이다. 세 유형이 서로 배타적인 게 아니라 한 사람 안에 동시에 들어올 수 있다는 걸, 책을 읽고 나서야 알았다.

이 문제가 그동안 잘 안 보였던 이유는 단순했다. 나는 혼자 일하고 있기 때문이다.

나는 한 명의 엔지니어로서 PM부터 개발까지 전부 혼자 진행하고 있다. 원래는 LLM 엔지니어와 데이터 사이언티스트 일을 해왔는데, LLM 기반의 이른바 “바이브 코딩”이 빠르게 활성화되면서 자연스럽게 풀스택 엔지니어를 흉내내게 됐다. 백엔드도, 프론트엔드도, 인프라도, 거기에 제품 결정까지 다 한 사람이 누른다. 한쪽에선 사용자의 말을 듣고 받아 적고, 다른 한쪽에선 내가 옳다고 느낀 방향을 그대로 코드로 옮긴다. 견제할 사람도, 다른 시선도 없다.

문제는 이 모든 역할을 동시에 하면서 어떤 역할도 책으로 배운 적이 없다는 점이다. 풀스택 개발도 부딪쳐서 배웠고, 프로덕트 매니지먼트는 더더욱 책으로 배운 적이 없다. 부딪치고, 부서지고, 다시 만드는 식으로만 배웠다. 그래서 내가 어떤 패턴으로 일하고 있는지를 객관화할 기회가 거의 없었다. 다른 사람과 비교할 일도 없고, 누가 옆에서 “그건 좀 위험하다”고 말해주지도 않는다. 결국 내 방식이 보편적인 거라고 자연스럽게 가정하게 된다.

책이 던지는 진짜 무서운 표현은 따로 있었다. 가장 나쁜 상태는 무엇이 잘못됐는지조차 모르는 상태라는 것. 기능이 안 쓰여도 “기능이 더 필요한가 보다”라고 해석하고, 사용자가 안 들어와도 “다른 게 부족한가 보다”라고 해석한다. 진짜 문제는 그 해석을 점검할 기준 자체가 없다는 데 있다. 돌이켜보면 나는 꽤 자주 그 상태였다. 더 정확히 말하면, 그 상태에 있다는 사실조차 인지하지 못했다.

그래서 이번에 이 책을 펴기 전과 후에, 한 가지가 분명하게 달라진 것 같다. 지금까지 나는 부딪치면서 배우는 엔지니어였다. 앞으로는 책을 통해 한 발 먼저 배우는 엔지니어로 옮겨가야겠다는 생각이 들었다. 모든 시행착오를 직접 겪을 필요는 없다. 누군가 이미 겪고 정리해둔 것을 먼저 읽어두는 것만으로도, 적어도 “내가 어디에 서 있는지”를 알아차릴 기준점은 생긴다.

이 책을 어쩌면 더 일찍 읽었어야 했다.

마무리: 경계선 위에서

지금까지 나는 사용자의 요구를 잘 반영하는 것이 곧 좋은 일이라고 생각했다. 지금도 그것이 틀렸다고 생각하지는 않는다. 다만 이제는 그 역할만으로는 부족하다는 자각이 생겼다. 사용자의 요구를 듣는 사람에서 사용자의 문제를 정의하는 사람으로 가야 한다. 기능을 전달하는 사람이 아니라, 왜 이 기능이 필요한지, 정말 필요한지, 제품의 목표와 연결되는지를 판단하는 사람이 되어야 한다.

이 책의 이 부분이 나에게 던진 메시지를 한 문장으로 줄이면 이렇다.

좋은 PM은 사용자의 말을 무시하는 사람이 아니다. 하지만 사용자의 말을 그대로 받아 적는 사람도 아니다. 좋은 PM은 사용자의 말 뒤에 있는 문제를 발견하고, 그 문제를 제품의 방향과 연결하는 사람이다.

그리고 지금 나는, 그 경계선 위에 어정쩡하게 서 있는 것 같다. 한쪽으로만 기울어 있는 줄 알았는데, 다시 보면 세 방향 모두에 조금씩 발을 걸친 채 서 있다. 이 자각이 곧바로 다른 행동으로 이어진다는 보장은 없다. 다만 이 자각이 있는 상태로 다음 주 미팅에 나가는 것과, 없는 상태로 나가는 것은 분명히 다를 거라고 생각한다.

다음 챕터를 더 읽고, 또 정리해볼 생각이다.