응답하라 PM100 — 서비스 기획 5년차, YR님의 고민 사연
질문자: 5년차 PM, YR님
질문 작성: 2026년 2월 12일
직무: 서비스 기획
산업군: B2B / 설치형 솔루션 / SI
경력: 5년차
고민의 유형: 이직 / 전직
각색하지 않고 그대로 가져옵니다.
고민은 "B2B PC 앱 설치형 솔루션 개발로 이탈률, 유입률 등의 데이터 기반 의사결정이 어려움"입니다. 특히 고객에서 구축 후 납품이라는 개념도 강해서 저희 솔루션을 한 번 납품하면 고객사에게 연락하지 않으면 성과를 알 수 없고, 대부분 PoC 프로젝트로 정식 프로젝트가 아니기 때문에 고객사에서도 효과성을 측정하거나 느낀 점을 명확히 이야기해 주지 않습니다.
그래서 최근 재취업을 PM 직군으로 준비 중인데 '다수의 이해관계자와의 협업' 외에 '데이터 기반'의 경험을 어필하는 데에 많은 고민이 있습니다. 다니던 회사에서는 당장의 수입이 필요하기 때문에 많은 고객사 프로젝트를 받아 납품하는 것에만 의미를 두고, 제가 데이터 기반을 제안했을 때는 측정도 어렵고 현재 불필요하다는 판단으로 거절됐습니다.
지금 제가 활용하는 방법은 고객사 VoC 기반으로 '몇 명이 어떤 문제점을 많이 언급했지?' 또는 '우리 서비스를 사용하기 전과 후의 작업이 얼마나 단축됐지?'와 같이 맥락적 정성 데이터를 어떻게든 정량 데이터 형태로 변환하여 적용 중입니다. 아직 모바일 앱 기획 경험이 없다 보니 주요 핵심 지표로 사용되는 이탈률, MAU 등의 명칭이 사용되지 않아서 서류 통과 시 불리한 점으로 작용할 것 같아 우려가 됩니다.
응답하라PM100은 고민의 맥락에 맞춰 가장 적합한 멘토를 배정해 답변을 드립니다. 오늘의 사연에는 Operation Manager에서 Product Manager로 전환 후 폭발적인 성장을 하고 계신 PM 5년 차 멘토 파니(Fannie)님이 답변해 주셨습니다.
안녕하세요. 멘토 파니(Fannie)입니다.
YR님 사연을 보면서 정말 많이 고민했어요. 공감도 되고, 이미 잘하고 계신 부분도 있어서 어떻게 정리해서 말씀드리면 좋을까 싶었거든요.
오늘 YR님께 드리고 싶은 말씀은 크게 두 가지입니다.
1) SI 환경에서 서비스 기획을 하다가 PM으로 전환하는 것에 대한 고민
2) 데이터 기반 의사결정 경험이 부족하다는 고민
차근차근 짚어볼게요.
SI에서 PM으로
전환하는 것에 대한 고민
먼저 말씀드리고 싶은 건, 그 허들이 생각보다 크지 않을 수 있다는 점입니다.
왜냐하면 저 역시 처음부터 PM이 아니었기 때문이에요. 쿠팡에서 커리어를 시작했지만 처음 직무는 PM이 아니라 운영이었습니다. 심지어 첫 업무는 기획과 거리가 있었던 이미지 편집 업무였어요.
예를 들어 상품이 등록되면 다음과 같은 업무를 하루 종일 했습니다.
상품 이미지를 흰 배경으로 만드는 작업
어드민에 이미지를 등록하는 작업
프로모션 시 대량 이미지 작업
하지만 이런 실무를 하면서 자연스럽게 이런 생각을 하게 되었어요.
"이 어드민은 왜 이렇게 불편하지?"
"이 과정은 이렇게 바꾸면 훨씬 빨라질 텐데?"
그래서 저는 단순히 불편함을 느끼는 것에서 끝나지 않고 회사에 이렇게 이야기했습니다.
"제가 실제로 이 업무를 100번 해봤는데 이 부분을 이렇게 바꾸면 속도가 xx분에서 x분 만큼 훨씬 빨라집니다."
이런 식으로 실제 업무 경험을 기반으로 개선 아이디어를 제안했고, 여러 TF를 돌아다니며 관련 경험을 더 쌓을 수 있게 되었어요. 그렇게 2년간의 운영팀 경험, 2년간의 TF 업무를 거쳐 PM으로 전환하게 되었습니다. 참고로 직무 전환에 2번 실패하고 3번째에 성공했어요. 그리고 그때 저를 PM으로 이끌어주신 분이 바로 멘토 율(Yul)님이었습니다.
다른 직군에서도
PM 역량을 증명할 수 있다
돌이켜 보면 저는 처음부터 PM이 하는 일을 잘했던 것이 아니라,
실무를 깊게 관찰했고
문제를 발견했고
나름대로 데이터를 만들어서
"이 문제를 해결할 수 있는 사람"이라는 것을 보여주었습니다.
예를 들어 이런 경험이 있었습니다.
당시 쿠팡의 고민 중 하나는 상품 대표 이미지 정책이었습니다. 예를 들어 같은 코카콜라 상품이라도 어떤 판매자는 이미지에 HACCP 마크를 넣고, 어떤 판매자는 넣지 않는 경우가 있었습니다. 이 경우 쿠팡의 시스템 구조상, 여러 판매자가 같은 상품 이미지를 공유하면서 법적 문제나 권리 분쟁이 발생할 수 있는 상황이었습니다.
그래서 저는 '이미지 검수 기준'을 직접 만들었습니다.
1️⃣ Critical - 법적으로 문제가 될 수 있는 요소. 인증 마크 오용, 상표 문제, 권리 침해 가능성 등.
2️⃣ Non-Critical - 그 외의 모든 품질 문제. 저화질, 번들 표기 불일치 등.
그 외의 모든 품질 문제, 예를들면 저화질, 번들 표기 불일치 등이 포함됩니다.
이 기준을 기반으로 하루 약 1,000개의 이미지를 검수했고, 셀러 이미지 품질 기준을 만들었으며, 신규 셀러 입점 시 개선 피드백을 제공하는 프로세스를 구축했습니다. 결국 이것이 셀러 퀄리티 관리 시스템의 시작점이 되었어요. "판매자의 1,000개 이미지 중 Critical은 X%, Non-Critical은 Y%"와 같은 분석을 정리해서 전달하고, 이를 기준으로 입점 가능 여부를 판단했습니다.
YR님 상황과 비슷하죠? 데이터라는 게 존재하지 않았지만, 상황을 관찰하면서 라벨링을 만들었고, 공통 현상을 그룹핑해서 문제를 정의했어요. 숫자를 만들어내고, 그 숫자를 기준점으로 활용한 것. 이 자체가 PM 직군의 데이터 기반 의사결정 능력의 시작이었습니다.
처음부터 완벽한
데이터는 없다
이 이야기를 들으면 이런 생각이 들 수 있어요.
"이건 데이터 기반 의사결정 같지 않은데?"
하지만 쿠팡도 사실 이런 방식으로 일을 시작했습니다. 데이터 기반 의사결정이란 처음부터 완벽한 데이터가 있는 것이 아니라, 현상을 관찰하고 → 라벨링을 만들고 → 데이터로 발전시키는 과정입니다.
실제로 쿠팡에서는 새로운 지표가 생기기 전에 먼저 라벨링 작업이 시작됩니다. 그리고 그 라벨링을 유지하는 운영 조직이 존재해요. 지금 우리가 보는 고도화된 지표들도 처음에는 이런 현상 관찰 → 라벨링 작업에서 시작되었습니다.
그래서 YR님이 지금 VOC를 보면서 하고 계신 작업은 이미 데이터 기반 의사결정의 출발점이라고 볼 수 있어요.
데이터 기반
의사결정의 4단계
PM이 데이터 기반으로 문제를 해결할 때는 대체로 다음 4단계를 거칩니다.
1️⃣ 문제 정의 - 먼저 현상을 관찰합니다.
예를 들어 VOC에서 반복적으로 이런 말이 나온다고 가정해 볼게요.
"서비스가 너무 느립니다."
그러면 문제 정의는 이렇게 됩니다.
"우리 고객은 서비스 속도가 느리다고 느끼고 있다."
2️⃣ 가설 설정 - 그다음은 왜 이런 일이 발생하는지 가설을 세웁니다.
가장 좋은 방법은 지연을 모니터링하는 대시보드가 있는 것이겠지만, 그조차도 없다고 가정해볼게요. 직접 시스템을 테스트해 보니, 버튼을 10번 눌렀을 때 1번 정도 15초 이상 지연이 발생하고 메시지 큐에 메시지가 쌓여있다는 것을 확인했다고 해봅시다.
그러면 가설은 이렇게 됩니다.
"메시지 큐의 성능이 부족해서 특정 상황에서 레이턴시가 발생한다."
3️⃣ 측정 가능한 지표 설정 - 그다음은 무엇을 측정할지 결정합니다.
메시지 큐 수, 처리 속도, 레이턴시 같은 지표를 볼 수 있어요. 하지만 SI 환경에서는 이런 지표가 없을 수도 있습니다. 그럴 경우 가장 간단한 지표를 사용해도 됩니다.
동일 문의 유형 VOC 감소 여부
동일 문의 유형 고객 불만 빈도
4️⃣ 실험 및 검증 - 가설에 따라 조치를 합니다.
예를 들어 '메시지 큐 확장' 또는 '서버 리소스 증설' 같은 실험을 진행하고, 그 후 지표 변화를 확인합니다.
메시지 큐 확장 후 동일 기간 대비 지연이 얼마나 개선되었는지
동일 문의 유형 VOC가 감소되었는지
동일 문의 유형 고객 불만 빈도도 개선되었는지
이력서/포트폴리오에서
어떻게 표현할까
YR님이 가장 우려하시는 부분이 "MAU, 이탈률 같은 지표 경험이 없어서 서류 통과가 불리하지 않을까"인데요. 결론부터 말씀드리면, 지표의 이름보다 문제 해결 과정이 더 중요합니다.
다만 표현 방식이 중요해요. 같은 경험이라도 어떻게 쓰느냐에 따라 PM 역량으로 읽히기도, 단순 운영 업무로 읽히기도 하거든요. 핵심은 문제 발견 → 데이터화 → 가설 → 해결 → 결과의 흐름이 보이도록 쓰는 거예요.
❌ "고객사 VOC를 수집하고 정리했습니다."
⭕️ "고객사 VOC 50건을 분석해 반복 문의 유형 5개를 도출하고, 그중 '작업 속도 불만' 문의가 40%를 차지한다는 것을 발견했습니다. 이를 기반으로 작업 프로세스 개선을 제안했고, 도입 후 동일 유형 문의가 60% 감소했습니다."
몇 가지 표현 전환 예시를 더 드릴게요.
❌ VOC 수집
⭕️ VOC 패턴 분석을 통한 문제 정의
❌ 작업 시간 단축
⭕️ 도입 전/후 작업 시간 비교 분석 (정량화)
그리고 면접에서 자주 나오는 질문이 있어요.
"모든 걸 해볼 수 있다면 어떤 지표를 보시겠어요?"
이 질문에 대한 답을 스스로에게 계속 던져보세요. 지금 환경에서 측정할 수 없었던 것들, 만약 측정할 수 있었다면 어떤 지표를 봤을지, 왜 그 지표가 중요한지를 정리해두면 면접에서 강력한 무기가 됩니다.
마지막으로
SI 환경의 제약이 있는 상태에서 PM으로 이직이 가능할까요? 라는 질문에 대해서는 충분히 가능하다고 말씀드리고 싶습니다. 왜냐하면 문제를 관찰하고 개선 방향을 생각하는 능력 자체는 직무가 달라도 크게 다르지 않기 때문이에요.
다만 현실적으로 데이터 기반 의사결정은 훈련이 필요한 능력입니다. 트레이닝은 분명 필요해요. 하지만 지금 YR님이 하고 계신 VOC를 보고, 패턴을 찾고, 라벨링을 하는 작업 자체가 이미 PM 역량의 출발점이라고 생각합니다.
그리고 요즘 AI 도구들(Claude, ChatGPT 등)이 매우 효율적이에요. 문서화와 정리 작업에 시간이 부담된다면 적극적으로 활용해보세요. 기획서 초안, 와이어프레임, 목업까지도 빠르게 생성할 수 있습니다. 이미 써보셨다면 더 잘 쓸 수 있도록 공부하고, 처음이시라면 하루라도 빨리 사용해보시길 권합니다.
너무 걱정하지 않으셔도 될 것 같아요. 지금 하고 계신 고민 자체가 이미 PM으로서의 성장을 준비하고 있다는 증거니까요. 진심으로 응원하겠습니다!
스타트업부터 대기업까지, 다양한 산업의 시니어 PM들이 모여 내린 결론은 두 가지였습니다.
1. PM의 본질과 고충은 어디서나 크게 다르지 않다
2.성장에 집착하지 않으면 이 일은 버티기 어렵다
그래서 만들었습니다.
성장에 100% 진심인
PM들만 모인 곳, PM100
공감을 위한 위로가 아니라, 조금 불편하더라도 현실을 직면하게 만드는 냉철한 조언을 드립니다.
수신 전용 채널입니다. 매주 실무 인사이트와 Q&A 콘텐츠를 보내드리니, 자유롭게 입장해주세요 :)
https://open.kakao.com/o/pUXzpRdi