응답하라 PM100 — 7년차 운영 실무자의 고민 사연
질문자: 7년차 운영 실무자
질문 작성: 2026년 3월 7일
직무: 운영 업무
경력: 7년차
고민의 유형: 전직
일부 표현과 내용을 정리해 사연을 옮겨왔습니다.
저는 7년차 운영 실무자로, PM 직무 전환을 고민하고 있습니다.
운영을 하다 보면 기능 개선이 필요한 지점을 자주 발견합니다. 하지만 운영에서 문제 해결을 위해 개발 요청을 하더라도, 실제로는 운영의 니즈나 문제 상황이 충분히 고려되지 않은 채로 기능이 개선되는 경우가 있습니다. 그 결과 운영 공수가 오히려 늘어나고, 기능 개선이 운영을 더 피로하게 만드는 상황이 발생하기도 합니다.
이러한 경험을 통해 운영의 공수를 줄이면서도 외부 고객에게 가치 있는 기능을 기획하고 운영하고 싶다는 생각이 들어 PM 직무 전환을 고민하게 되었습니다.
PM으로 직무 전환을 하려면 어떤 방향으로 준비하는 것이 좋을지, 그리고 내부 고객(회사 내부에서 기능을 운영하는 사람들)과 외부 고객(실제 서비스를 사용하는 사용자) 모두에게 도움이 되는 기능 개선을 위해 어떤 지점을 고민해야 하는지 궁금합니다.
응답하라 PM100은 고민의 맥락에 맞춰 가장 적합한 멘토를 배정해 답변을 드립니다. 오늘의 사연에는 PM 8년차, 쿠팡에서 운영→PM으로 전환해 현재 무신사에서 활약 중인 멘토 리나(Lina)님이 답변해 주셨습니다.
안녕하세요
멘토 리나입니다
7년이라는 시간 동안 현장의 목소리를 가장 가까이서 들어오셨군요. 보내주신 고민을 읽으며 제가 PM으로 첫발을 내디뎠을 때가 떠올라 깊이 공감했습니다. 저도 운영팀에서 경험을 쌓아 PM으로 전환한 케이스거든요.
그때 저도 "내가 매뉴얼로 처리하는 이 비효율적인 업무들을 시스템화하면 얼마나 좋을까?"라는 고민을 매일 했고, PM이 되면 이 모든 걸 다 고칠 수 있을 거라는 설레는 포부도 있었죠. 하지만 막상 제품 조직으로 들어와 보니, 이상과 현실 사이에는 PM으로서 감당해야 할 '무게'가 있더라고요.
그 길을 먼저 걸어본 선배로서, 사연자님의 고민에 조금 더 구체적이고 현실적인 조언을 전해드리고 싶습니다.
운영자에서
제품 설계자로의 관점 전환
이미 수년간의 운영 경력으로 도메인 전문성이라는 엄청난 무기를 가지고 계십니다. 내 경험과 현재 상황을 토대로 [문제 정의 - 원인 분석 - 개선안 - 기대 효과]의 프레임으로 짧게라도 정리를 시작해 보세요. 이 과정이 반복되면 자연스럽게 운영자의 언어가 아닌 PM의 언어로 사고하게 됩니다. 내가 매일 쓰는 도구를 더 낫게 만들려는 고민이 바로 PM 포트폴리오의 첫 페이지가 될 거예요.
운영 공수가 늘어난다는 것은 결국 회사의 ‘비용’이 증가한다는 뜻입니다. 이 비용을 구체화하기 위해 운영 공수가 늘어나는 원인(예: 매달 발생하던 CS 건이 nn% 증가해 업무량이 늘어나는 상황)을 수치로 정의하고, 그 결과(예: 작업자 1인당 업무 투입 시간 증가, 인건비로 환산했을 때 증가하는 비용 등)도 수치로 환산하는 연습이 필요합니다.
기회는 주어지는 것이 아니라
각인시키는 것
운영팀과 프로덕트팀이 만나는 모든 접점에서 사연자분의 아이디어와 고민의 흔적을 꾸준히 보여주세요. 단순히 “이게 불편해요”가 아니라, 위에서 연습한 문제 정의부터 기대 효과까지 검토한 내용을 제품 설계자의 관점으로 제안해 보세요.
팀에 빈자리가 생길 때 리더들은 외부 채용만큼이나 도메인을 잘 아는 내부 인재를 떠올립니다. 이때 가장 먼저 생각나는 사람이 되려면, 평소에 “저 사람은 단순한 문제를 제기하는 수준을 넘어, 비즈니스 임팩트까지 고려할 수 있는 사람”이라는 인상을 심어주어야 합니다.
내부/외부 고객 모두를
만족시키는 설계
운영과 고객 모두를 만족시키려면, PM은 단순히 기능을 만드는 사람이 아니라 전체 프로세스의 최적화를 고민해 시스템을 설계하는 사람이 되어야 합니다.
서비스 블루프린트: 고객이 경험하는 여정과 그 뒤에서 운영자가 수행하는 업무 흐름을 하나의 그림으로 정리한 설계도
외부 고객이 액션을 취하는 화면/기능만 설계하는 것이 아니라, 그 뒤에서 운영자가 수행해야 하는 액션까지 끝까지 따라가 보세요. 고객의 액션이 마무리될 때까지 운영의 개입이 필요한 구간이 발견된다면, 이를 시스템 정책으로 대체할 방법을 고민해 볼 수 있습니다.
운영 공수가 늘어나는 이유 중 하나는 대개 시스템 기능이 불완전해 사람이 검수나 보정을 해야 하기 때문입니다. 이때 휴먼 에러가 발생하면 더 큰 문제가 생길 수 있습니다. 그렇기 때문에 운영자가 검수하는 구간을 정책화해 시스템화하는 방법을 찾아야 합니다. 유저에게 자유도를 제공하는 것도 좋지만, 정해진 가이드라인 안에서 자동화를 지향하는 설계가 필요합니다.
“사용자가 10배 늘어나도 지금의 운영 프로세스가 유지될 수 있는가?”
라는 질문부터 시작해 보세요. 외부 고객 만족도가 올라가더라도 운영 공수가 이를 감당하지 못한다면, 그 기능은 실패한 설계입니다. 이를 측정하기 위해 기능 개선의 성공 지표에는 매출이나 전환율뿐 아니라 운영 비용과 관련된 지표를 포함시켜야 합니다.
모두를 만족시킬 수 없다
현실 마주하기
PM이 되면 완벽한 설계를 통해 모든 비효율을 해결할 수 있을 것이라고 생각하겠지만 이는 매우 이상적이며, 현실은 늘 한정된 리소스라는 제약과 싸우며 다양한 이해관계자와의 조율을 해나가야 합니다. 그러다 보면 모두의 니즈를 절충하는 과정에서 오히려 운영단에 더 번거로운 프로세스가 생기는 아이러니한 상황이 발생하기도 합니다.
저 역시 PM이 된 이후, 운영팀의 고충을 누구보다 잘 알면서도 때로는 운영팀에 희생을 부탁해야 하는 순간들이 있었고, 마음이 무거웠습니다. 이런 현실에도 우리는 더 많은 이들의 만족을 이끌어 내기 위한 방법을 찾아나가야 합니다. 그래서 필요한 것이 냉철한 우선순위 정렬입니다.
내부와 외부 고객 사이의
우선순위 정렬
내부 고객의 불편을 해소했을 때의 가치와 외부 고객의 불편을 해결했을 때의 가치를 숫자로 구하고 비교해 보세요. 이때, 표면적으로는 외부 고객의 불편을 해소하여 가져오는 비즈니스의 가치가 더 커 보일 수도 있습니다. 그렇지만 운영팀의 리소스를 줄이는 일이 어떻게 고객의 유입 증가나 이탈 방지에 기여하는지를 논리적으로 증명할 수도 있습니다. 모든 요청 사항에 대한 논리적인 임팩트를 산정하고, 냉철하게 우선순위를 매길 수 있어야 합니다.
모든 기능이 Full-spec으로 만들어야만 의미가 있는 것은 아닙니다. 기술적 부채(당장의 속도를 위해 임시로 처리한 것들이 쌓여 나중에 더 큰 개선 비용으로 돌아오는 것)나 리소스 문제로 한 번에 완성하기 어려울 때, 아예 안 하는 것보다 일부라도 배포하여 다음 단계를 준비하는 것이 훨씬 전략적인 선택일 수 있습니다. 상황에 따른 절충은 후퇴가 아닙니다. 모든 이해관계자의 니즈를 담다 보면 어떤 구간에 불편이 생길 수도 있겠지만, 그것이 현재 비즈니스 우선순위 내 최선의 선택이라면 그 불완전함을 받아들이고 다음 기회를 도모하는 유연함도 PM에게 필요한 역량입니다.
신뢰는 투명한 설명과
행동의 증명에서 나온다
PM은 어떤 결정을 내릴 때, 한편의 이해관계자의 기대에 못 미치는 결정을 내려야 하는 상황이 생깁니다. 이때 어떤 행동을 취하느냐에 따라 PM의 진가가 드러납니다.
다른 비즈니스 과제가 왜 우선순위를 받았는지 투명하게 설명해야 합니다. 상대가 그 이유를 충분히 납득할 수 있도록 숨김 없이 설명하고 공감을 구하세요. 충분한 설명이 동반된 거절은 상처가 아니라 납득이 됩니다.
지금은 아니지만, 이후에 어떤 계획으로 이 부분을 다시 개선할 것인지 약속하는 단계가 필요합니다. 그리고 실제로 이를 로드맵에 반영하려는 모습을 보이고, 작은 개선이라도 꾸준히 실행하며 개선하는 모습을 보여준다면, 이해관계자는 이 PM은 언젠가 내 문제를 해결해줄 사람으로 믿고 지지해 줄 것입니다. 그 신뢰가 바로 프로덕트를 움직이는 가장 큰 원동력이 됩니다.
마지막으로
이 모든 과정이 어렵게 느껴질 수 있지만, 사연자분께서는 이미 강력한 출발점이 있습니다. 사내에서의 준비와 함께, PM 커뮤니티나 스터디에 참여해 실무 언어와 사고방식에 미리 익숙해지는 것도 전환의 속도를 높여줍니다.
운영을 하며 어려운 점을 직접적으로 느껴본 경험이 있는 PM은 결코 제품을 대충 만들지 않습니다. 내가 만든 기능 하나가 동료의 퇴근 시간을 바꿀 수 있고, 고객에게 전달되는 가치의 마지막 퍼즐은 결국 사람의 운영으로 완성된다는 것을 누구보다 잘 알고 있기 때문입니다.
지금 당장 모든 것을 바꿀 수 없어 답답할 때도 있겠지만, 가장 비효율적인 상황부터 제품 설계자 관점으로 정리를 시작해 보세요. 그 작은 시도들이 가장 현장감 있고 실력 있는 PM으로 만들어 줄 거예요.
진심으로 새로운 시작과 도전을 응원합니다! 도움이 필요하면 언제든 또 고민 남겨주세요.
기획자만 기획하는 시대는 끝났습니다.
개발자도, 디자이너도, 마케터도 결국 문제를 정의하고 우선순위를 세우는 사람이 일을 움직입니다.
PM적 사고가 필요한 시대
그 시작, PM100
위로보다 현실 직면. 공감보다 성장.
매주 실무 인사이트와 Q&A 콘텐츠를 발행합니다.
수신 전용 채널이니, 부담 없이 입장해 주세요.
https://open.kakao.com/o/pUXzpRdi