6년 차 CX 기획자가 다시 1년 차 PM이 된 이유

누군가 길을 헤매고 있을 CX 기획자를 떠올리며

제게 2023년은 가장 큰 변화를 겪은 해입니다. 6년간 쌓아온 CX 기획자 커리어를 뒤로 하고 주문 플랫폼 PM이라는 역할에 도전했기 때문입니다. 저는 새로운 팀과 동료, 그리고 업무 프로세스를 마주하며 다시금 신입으로 돌아가길 자처했습니다.

이러한 변화는 이직이 아닌 팀 이동과 함께 이뤄졌습니다. 물론 이직을 고려할 수도 있었습니다. 하지만 지난 시간 사내에서 복리처럼 쌓아온 평판과 인맥, 회사의 어드민 시스템과 레거시에 대한 지식을 최대한 살리고 싶었습니다. 그래서 팀 이동을 선택했죠.

주변의 반응은 극과 극으로 갈렸습니다. 이변이 없다면 기존 팀에서 2년 뒤에 과장을 달 수 있음에도, 새로운 도전 탓에 자칫 진급이 누락될지 모른다는 우려를 받았습니다. 한편 더 늦기 전에 해보지 않은 방식으로 살아가는 것도 좋을 거라는 격려 메시지 역시 받았습니다.

고민 끝에 이동을 결심한 배경에는 CX 기획자로서의 사명감이 있었습니다. 요즘은 CX에 대한 인식이 나아지며 산업이 커졌고, 이 직무 관련 콘텐츠도 쉽게 볼 수 있습니다. 그러나 제가 CX 기획자로 일을 시작한 2018년만 해도 CX에 대한 개념조차 분명하지 않았습니다. 그렇기에 현업에서 직접 몸으로 부딪치며 배워 나가야 했죠. 이 과정을 브런치와 강의, 기고로 담아냈는데, 저와 비슷한 처지에 있을 ‘외로운 CX기획자’에게 길잡이가 되고 싶은 마음이 컸기 때문입니다.

최근 업계 CX 기획자들이 모인 커뮤니티의 주요 관심사 중 하나는 ‘PM으로의 직무 전환’입니다. CX 직무에서는 VoC 분석과 이에 기반한 CS팀 운영 계획 수립, 고객 문제를 선제적으로 해결하기 위한 서비스 운영 정책 기획, 상담 어드민 기획 등을 수행합니다. 이처럼 다양한 업무를 체험할 수 있지만, 아래 이유로 CX 직무에 대한 한계를 느낀다고도 합니다.

• CX팀 내부 우선순위와 전사 우선순위의 채택 방법이 완전히 다름
• C레벨이 CX를 대하는 태도에서 한계를 느낌
• 고객 입장에서는 서비스에 대한 인식이 변할 수 있는 주요 접점이지만, 내부 이해관계자는 CX를 단순히 사후 처리에 국한되어 바라봄
• CS 부서가 장기적으로 수익에 긍정적인 영향을 미칠 수 있다는 점을 확신하기 어려움
• 간단한 수준의 업무를 반복하며 이로 인해 동기가 떨어짐

물론 이런 의견들에는 다양한 반박이 나올 수 있습니다. 그러나 분명한 것은 CX에 대한 직무 인식은 여전히 걸음마 수준이며 기업별로 업무에도 큰 차이를 보인다는 점입니다.

그렇다면 정말 CX 기획자에게 PM은 기회의 땅일까요? 본인이 쌓아온 역량을 살릴 수 있는 최적의 직무일까요? 사람들의 막연한 생각을 몸소 증명해 보자는 생각에, 그렇게 PM을 향한 첫걸음을 내디뎠습니다.

CX 기획자는 어떻게 PM으로 전향했을까?

여느 대기업과 마찬가지로 저도 직무 전환 신청으로 팀 이동에 지원했습니다. 물론 지원한다고 모두 이동할 수 있는 건 아닙니다. 우선 가려는 팀의 TO가 있어야 합니다. 제가 속한 팀과 사업부 리더의 승인, 이동을 희망하는 팀과 사업부 리더의 승인도 함께 필요합니다. 또한 팀 이동에 성공한다 해도, 제가 원하는 부서가 아닌 완전히 다른 곳으로 배정받을 수도 있었습니다. 즉, 성공적인 이동이 이뤄질 확률은 로또에 가까웠습니다.

이를 해결하고자 우선 스스로 잘할 수 있는 일이 무엇인지 복기하는 시간을 가졌습니다. 제가 주로 해온 업무는 다음과 같았습니다.

• 외주고객센터(BPO) 관리 및 운영 효율성 개선
• 상담 어드민 기획 및 기타 상담 시 필요한 솔루션 기획(상담 PM)
• 신규 영업 채널 오픈에 따른 서비스 운영 정책 기획 및 고객센터 운영 방안 수립
• VoC 데이터에 기반한 KPI 및 외주고객센터 SLA 관리

업무를 정리하고 나니 제 경험과 역량이 더 잘 보였습니다. 저는 이커머스 클레임 처리를 필두로 내부 운영 리소스 개선 관련 다양한 프로젝트를 해왔습니다. 이는 즉, 프론트 기획보다는 백 오피스 기획 부서로 지원할 때 직무 전환 가능성이 높다는 뜻이었죠.

아울러 요구 정의와 유저 저니 분석은 물론 비즈니스 플로우를 중심으로 한 업무 개선사항을 정리해 내부 공유 목적의 포트폴리오를 만들었습니다. 지원하는 부서의 리더, 인사팀과의 면담도 요청했습니다. 여태 해온 업무를 설명하며 직무 적합성을 스스로 증명할 목적이었습니다.

또, 이를 위해 제 나름대로 백오피스 PM의 역할을 재정립했습니다. 혹자는 대기업 PM을 ‘Feature Factory’, 즉, 컨베이어 벨트에 앉은 공장 직원이라고 표현합니다. 유관 부서로부터 요청을 접수 받아 요구사항을 구체화한 다음 기획 산출물을 개발자와 디자이너에게 넘기는 일이 전부라는 거죠. 스타트업이나 IT 서비스 기업과 달리, 대기업 PM이 맡는 제품과 업무의 영역이 비교적 좁고 한정적인 점이 이런 선입견을 불러왔을 겁니다.

그러나 저는 사내에서 모듈을 구분하는 방식을 파악한 다음 백오피스 PM의 역할을 이렇게 정의했습니다. ‘회사가 가진 인프라 시스템에 대한 이해를 바탕으로 복잡한 문제를 구조화하고 레거시를 고려해 안정적인 백오피스 시스템을 구축하는 사람'이라고요. 포트폴리오와 면담에도 이런 관점을 녹이려고 노력했습니다.

그 과정들 끝에, 저는 결국 원하던 백오피스팀으로 배정받을 수 있었습니다.

새로운 팀에서 적응하기 어려웠던 이유: 디펜던시

오매불망 고대한 끝에 이동한 팀에서, 스스로 마주한 모습은 초라하기 그지 없었습니다. 팀 이동 그 자체가 잘못된 선택은 아닐까 싶기도 했습니다. 이유는 하나, 심각한 무력감 때문이었습니다.

7년 차 기획자였지만, 제 도메인 지식은 새로운 팀의 주니어 PM보다 한참 떨어졌습니다. 기존에 다른 모듈과 업무 연관도가 높은 상담 모듈을 맡아왔지만, 막상 실제 새로운 도메인에서 업무를 하다 보니 처음부터 다시 시작하는 느낌이 강했습니다.

팀 이동을 한 지 6개월이 지난 지금 시점에 돌이켜보면, 이때의 문제점은 ‘디펜던시(dependency)’ 파악에 있었습니다. 의존성을 뜻하는 디펜던시는 PM이 프로젝트를 수행하는 데 꽤 중요한 단어입니다. 이를테면 A 업무를 수행하기 위해 B가 필요하고, 이 과정이 다시 C에 영향을 주는 등 업무들 사이 연결성을 뜻하는 단어죠. 기획자가 기획산출물을 작성하지 않아 개발자가 아직 업무를 못 한다거나, 기획자가 설계 방향을 수립하지 못해 DB 테이블 작성이 지연되는 등 업무 병목을 설명할 때 흔히 쓰입니다.

다만 제가 느낀 디펜던시는 조금 성격이 달랐습니다. 이커머스 플랫폼이 직접 매입해 이윤을 붙여 판매하는 ‘직매입’ 상품을 예로 들어보겠습니다. 직매입 상품 판매는 다음과 같은 프로세스로 이뤄집니다.

PM은 프로젝트에서 업무 흐름의 선후를 파악하는 것과 동시에 유관부서별 업무 모듈을 이해해야 합니다. 각각 모듈이 다른 부서의 모듈과 어떻게 이어지는지, 이를 고려할 ‘시점’ 역시 파악해야 하죠. 즉, 모두 PM이 알아야 하는 디펜던시입니다.

현재 제가 맡은 업무 중 하나가 바로 직매입 플랫폼 기획입니다. 저는 위의 표를 기준으로 상품 매입과 그 상품에 대한 실적을 관리하는 ‘MD’ 영역을 담당합니다. 그렇다면 저는 MD의 업무만 알면 될까요? 아닙니다. MD가 사용하는 계약, 매입, 발주 화면의 기능을 개선한다면, 그 화면뿐만 아니라 이어질 물류, 재경 연계 모듈을 동시에 테스트해야 합니다. 설사 제가 물류와 재경 백오피스의 기획자는 아니라도 말이죠.

이처럼 디펜던시에 대해 높은 이해도를 갖춘 PM을 시장에서는 ‘전사 목표와 로드맵에 따라 우선순위를 설정할 수 있는 사람’, ‘내부 프로세스 개선과 효율성 향상을 위해 현시점의 비효율을 없앨 줄 아는 사람’, ‘문제를 단순화하고 가시화하되, 자기 모듈뿐만 아니라 다른 모듈에 끼칠 영향도 미리 계산할 줄 아는 사람’이라고 평가할 겁니다.

새로운 도메인, 팀에서 빠르게 적응하기 위한 3가지 방법

이렇게 말했지만, 여전히 저는 적응 중입니다. 그래도 몸으로 부딪히며 깨달은 부분도 있습니다. 더 빠르게 새로운 환경에 정착하고 싶은 기획자에게 전하고 싶은 3가지를 정리했습니다.

첫 번째, 맡은 도메인의 제품 매뉴얼을 작성해 보세요. 기업은 각기 다른 도구로 정보를 관리합니다. 어떤 기업은 컨플루언스로, 어떤 기업은 노션과 각종 파일들을 활용하죠. 그러나 프로덕트팀이 아닌 다른 팀 직원들은 이를 보고 제품의 사용 방법이나 레거시의 흐름을 한 번에 파악하기 힘들 겁니다. 기획자와 개발자들이 기획∙개발 과정에서 만든 문서 중심이니까요. 즉, 내부 직원 눈높이에 맞춘 매뉴얼이 필요할 가능성이 높다는 뜻입니다.

저 또한 팀을 이동한 다음, 약 2개월간 총 200페이지가 넘는 직매입 매뉴얼을 만들었습니다. 기준 코드의 위계 관계부터 시작해 MD의 질문들을 FAQ로 묶고 상황별 시스템 사용 방법을 함께 안내했습니다. 어드민 시스템을 하나하나 캡처하며 세밀하게 작성했죠. 이 과정은 모듈에 대한 오너십을 스스로 부여하는 동시에 팀원과 내부 직원들 사이에서 PM으로 입지를 다지는 데 큰 도움을 주었습니다. ‘A 영역= OOO PM’이라는 공식을 세우는 거죠.

두 번째, 질문에는 선후배가 없어야 합니다. 물론 질문을 대수롭지 않게 여기는 분도 있겠지만, 산적한 일감 앞에 허덕이는 동료 기획자와 개발자를 괴롭히는 건 제법 미안한 일이었습니다. 전체 경력으로 보면 저보다 한참 후배인 동료에게 물어보는 것이 모양 빠지는 모습일 수도 있고요. 죄책감과 불편함, ‘내가 초라해 보이진 않을까’라는 생각에 휩싸일 수 있습니다.

하지만 새로운 팀에 적응하고 성장하려면 질문은 필수입니다. 질문에도 유통기한이 있습니다. 신규 배치 후 여러 해가 넘어간 시점에서도 기초적인 질문을 한다면, 그때야말로 동료들이 그 PM의 실력과 자질을 의심하지 않을까요? 그러니 민망해하지 말고 업무를 방해하지 않는 선에서 적극적으로 질문해야 합니다.

마지막으로, 조바심 내지 마세요. 직장인 커뮤니티에서는 이직이나 팀 이동 다음 적응하기까지 걸리는 시간을 대략 6개월 내외로 말하더군요. 그러나 주변의 PM 지인, 회사 선배들과 대화한 끝에 내린 결론은 “경력직 모두에 적용할 만한 적응 기간이란 없다”라는 것입니다. 18년 차 차장 선배는 1년 이상은 걸린다고 했습니다. 에이전시와 IT 대기업을 두루 거친 핀테크 기업의 PM은 최소 3년은 필요하다 했죠. 기업과 도메인이 쌓아온 레거시가 많고 복잡할수록 디펜던시를 파악하기까지 더 오래 걸리기 때문입니다. 조바심을 내면 낼수록 오히려 일을 그르치기 일쑤입니다.

마치며

지금까지 새로운 직무로 새로운 팀에 적응하며 배운 것을 정리해 보았습니다. 어딘가에서 고군분투하고 있을 직무 전환자, 이직과 팀 이동을 거쳐 새로운 환경에서 고생하고 있을 현직 PM 여러분에게 이 글이 부디 조금이라도 도움이 되길 희망합니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.