몰라도 알아야 하는 사람
모두의 질문에 답을 줘야 하는 서비스기획자
서당개도 3년이면 풍월을 읊는다고, 서비스기획팀에 오기 전에는 3년 내내 같은 부서에서 비슷한 일을 해왔다 보니 어떤 문제가 발생하든 어떻게 이 문제를 풀어나가면 될지가 눈에 보였다. 그러니까, 문제의 답은 모르더라도 그 답을 어떻게 찾아나가면 될지 방법은 알고 있었다.
처음 서비스기획자가 되고 가장 힘들었던 건, 도무지 그 방법이 보이지 않는다는 것이었다. 어떤 문제가 발생했는데 이걸 어느 부서와 논의해야 할지(백엔드와 논의해야 하는 건가? 프런트엔드랑 확인해야 하는 건가?), 어떻게 처리하면 되는 건지(스펙 변경을 해야 하나? 이 정도면 known issue로 넘어가는 게 낫나?), 어디까지를 내가 결정해야 할지(내가 담당 기획자니까 이 정도는 내가 결정해도 되나? 이런 것도 리드님께 여쭤봐야 하나?). 모두가 나에게 질문하고 나의 답을 기다리는데, 나는 정답을 얘기할 자신이 없었다.
답도 모르고 답을 찾을 방법도 몰라서 머리를 쥐어 싸매며 6개월이 지났을 무렵, 이번에는 부서이동을 앞둔 팀원이 있어 해당 업무를 인수인계받게 되었다. "제가 한번 해보겠습니다!" 하고 자진한 것이었지만, 타 서비스와 엮여있는 프로덕트라서 생각보다 더 복잡하고 어려웠다. 인수인계 미팅이 있기 며칠 전부터 슬랙에 참조되고, 인수인계 미팅이 끝나자마자 협업부서에 내가 새로운 기획 담당자로 소개되더니 어느 순간 덩그러니 실전에서 헤매고 있는 나.
인수인계도 다 받지 못한 나에게 다른 기획자, 디자이너, 개발자들이 질문을 던지고 답을 기다리는 상황에서, 새로운 업무에 대한 설렘은 사라지고 스트레스만 남게 되었다. 아는 만큼만 아는 척 답을 해야 하나, 전임자를 멘션해야 하나, 바빠 보이는 리드님께 여쭤봐야 하나, 고민하면서 슬랙을 썼다 지웠다를 반복하다가 나도 모르게 눈물이 차올랐던 그 순간을 기억한다.
서비스기획자에게는 하루에도 수십 번 다양한 질문이 쏟아진다. 프로덕션 팀 내에서는 기획 스펙에 대한 문의가 주를 이룬다. 내가 기획한 스펙이라면 어떻게든 답변할 수 있지만, 내가 담당하기 전에 정해진 스펙에 대한 질문을 받으면 난감한 경우가 많다. 오랜 시간 문서를 뒤져 답을 찾아냈다면 다행이지만, 기록도 남아있지 않고 당시 담당자들은 모두 퇴사하여 히스토리를 알고 있는 사람이 아무도 없는 경우가 부지기수다. 이럴 땐 초면인 분께 뜬금없이 몇 년 전 스펙을 물어보며 최대한 있는 정보들을 긁어모으고, 그도 안 되면 개발자에게 부탁해 코드를 하나하나 뜯어봐야 할 때도 있다. (인수인계 때 이 모든 히스토리를 인풋 받는 것은 당연히 불가능하다.)
프로덕션 팀 외부에서는 그야말로 모든 질문과 이슈를 다 서비스기획자에게 던진다. 그럴 것도 많은 경우, 서비스기획자가 PM(프로덕트 매니저)을 겸하기 때문이다. 하지만 내가 PM이라고 한들 개발자는 아니므로 개발 관련 문의에 완벽한 답을 주기엔 역부족이다. 어설프게 안다고 섣불리 답했다가는 일이 복잡해질 수 있으니 담당 개발자의 확인을 요청하는 것은 필수인데, 여기서 또 어느 개발팀에 확인해야 하는지가 걸림돌이 된다. 백엔드와 프런트엔드 중 어디에서 확인해줘야 하는지는 지금도 자주 헷갈릴뿐더러, 때때로 API를 제공하거나 데이터를 저장하는 다른 부서의 개발팀의 확인이 필요할 때도 있다. 당장 누구에게 물어봐야 하는지도 불분명하니, 답을 찾는 과정이 한층 더 복잡해지는 것이다.
그래도 어쩌랴, 신뢰받는 PM이 되려면 몇 번이고 물어서 어떻게든 답을 찾아야지. 이 과정을 반복하다 보면 어느새 담당 프로덕트에 대해 빠삭해져 답할 수 있는 영역이 많아지거나, 답을 모르더라도 일단 누구와 먼저 확인해 봐야 할지에 대한 감이 생긴다. 그래서 이제 쫌 할 만하다 싶으면 또 새로운 프로덕트가 나타나 앞의 과정을 또다시 겪어야 할 것이다. 서비스기획이라는 같은 일이더라도, 그 안에서 담당하는 프로덕트가 바뀌는 것. 그게 바로 질리지도 않고 이 일을 계속할 수 있는 이유가 아닐까.
