오늘도 버티는 기획자를 위한 마음 다스리기 노하우

프로덕트 말고 스스로는 얼마나 챙기고 있나요?

IT 서비스가 백 가지라면 기획자도 백 가지 모습을 갖고 있다. 우리 기획자들은 서비스 기획자, IT 기획자, PM(Product Manager), PO(Product Owner)등 다양한 이름으로 불린다.

또, 소속이 에이전시인지 인하우스인지*, 맡은 서비스가 B2B인지 B2C인지, 회사의 규모가 초기 스타트업인지, 대기업인지에 따라 우리가 맡은 미션은 달라진다. 도메인(domain)**에 따라 필요한 제반 지식도 다르다.

* 에이전시 기획자는 IT 서비스를 필요로 하는 고객들에게 일정을 받아 일하는 경우를 의미한다. 반대로 인하우스 기획자는 서비스를 제공하는 회사에 직접 속한 경우를 의미한다.

** 소프트웨어로 해결하고자 하는 문제의 영역을 의미한다. 도메인 내 하위 도메인이 존재한다. 예로, 온라인 서점이라는 도메인은 주문, 결제, 배송, 혜택이라는 하위 도메인으로 구성된다. 

하지만 어떤 모습이건 기획자는 비슷한 부침을 겪으리라 생각한다. 유관부서와 개발자, 디자이너 사이에서 무언가를 만들어 나가야 하는 사람들. 제품의 성공적인 론칭하고 운영하기 위해 달리는 사람들. 우리는 많은 일들을 챙기고 있지만 일정과 성과 사이 압박을 받으면서 나도 모르게 스스로에게 가장 가혹해질 수 있을 거라 생각한다.

오늘도 회의하다가 울컥했는지, 퇴근길도 지치진 않았는지. 내일 아침 회의가 두렵고 진짜 다음 주 릴리즈가 가능할지 걱정되지 않았는지.

이 아티클은 그럼에도 버티겠다고 결심한 기획자들에게, 스스로를 다독이면서 일할 수 있도록 도움이 되는 방법들을 전하고자 한다.

우리는 왜 이렇게 쉽게 지칠까?

기획자는 업무에 과몰입하기 쉬운 사람들이다. 

기획자는 프로덕트의 성공을 위해 존재한다. 성공을 다들 다르게 정의하겠지만 누군가는 지표를 성장시키라는, 누군가는 초기 시장을 찾아내라는, 누군가는 납기 일정을 맞춰야 한다는 미션을 부여받는다. 기획자가 움직이지 않으면 일이 시작되지 않고, 일을 마무리하는 사람도 기획자이기 때문에 책임감을 넘어서 압박을 느끼기 쉽다.

나는 의사 결정을 내릴 때 특히 부담을 느꼈다. 그 프로덕트는 사용자는 적은 편이지만 어떤 기조로 정책을 정하느냐에 따라 제품 전체에 미치는 영향이 컸다. 실제로 이런 부담감을 느낀 나머지  정책을 결정할 때 기준을 못 잡고 몇 번 결정을 번복했던 적도 있었다.

QA(Quality Assurance)* 단계에서 이슈 리포트를 보았을 때 '내가 더 챙겼어야 했는데. 진작 한번 내가 미리 테스트했더라면 2주는 단축시킬 수 있었을 이슈였는데'라며 스스로를 비난하기도 했다.

* 제품 출시 전까지 테스트를 반복하며 제품의 품질을 높이는 프로세스

그러다 보면 업무와 나 사이에 적절한 거리 두는 것을 실패하곤 한다. 기획안에 대한 질문이 나를 비난하듯 느껴지기도 하고, 어떤 문제가 생기면 덮어놓고 내 탓으로 자책하기도 했다.

이렇게 업무에 과몰입하다 보면 프로젝트에 문제가 발생했을 때 일희일비하기 쉽다. 조금이라도 문제가 생겨도 덜컥 놀라고, 작은 문제도 지나치게 확대해석하는 바람에 올바른 결정을 내리기 어려워진다. 이러한 과정이 반복되면 일을 끝내기도 전에 지쳐버리는 경우가 많다.

게다가 커뮤니케이션할 대상과 범위가 넓다. 

IT 기획자들을 울리고 웃겼던 영상, 'IT 기획자 되지 말아요(Dont' be a lawyer 패러디)'에 나오는 말이다.

버튼 하나 바꾸려면 몇 명한테 물어봐야 하는지 아나요?

IT 기획자 되지 말아요. (Don't be a lawyer 패러디) ⓒ췌옹CHEONG

실제로 기획자로서 일을 하다 보면 소통해야 할 상대가 많다. 크게 2가지 카테고리로 묶을 수 있다. 첫째, 일명 '유관부서'라 불리는 이해관계자들이 있다. 그분들은 제품 출시를 기다리는 사업팀일 수도 있고, 개인정보 이슈에 문제가 없는지 판단해주는 법무팀일 수도, 문제가 발생했을 때 나 대신 우산이 되어줄 CS(Customer Service)* 담당자일 수도 있다.

* 고객으로부터 문의사항이나 불만이 접수되었을 때 이를 처리하는 부서를 의미

또한 제품 전반의 디테일을 챙겨주는 QA일 수도 있고, 혹시 제품에 취약점이 없나 테스트해주는 보안 부서일 수도 있다. 혹은 우리 제품을 더 잘 전달해줄 마케터일 수도 있다.

둘째로는 함께 제품을 만들어가야 하는 메이커들이 있다. 앱 하나를 돌아가게 하기 위해 클라이언트 개발자, 서버 개발자, 디자이너와 각각 소통해야 한다. 제품 범위가 넓고 복잡할수록 개발자도 한 명이 아니라 여럿이 될 수 있다. 예컨대, 최근 진행했던 프로젝트에는 웹 프론트엔드 개발자 한 명, 윈도우 클라이언트 개발자 세 명, 서버 개발자 세 명, 그리고 디자이너 한 명이 있었다.

담당자들은 각 분야 전문가기 때문에 그들 입장에서 다양한 의견을 쏟아낸다. 그 과정에서 기획자는 최선을 다해 토론하되, 최종 의사결정을 내리고, 이를 다른 이들에게 설득해야 한다.

예를 들어, 일할 때 내가 나누는 대화 예시 4가지를 아래 재구성해 봤다. 보통 새로운 내용을 바로 이해하고 담당자들과 이야기해야 하기 때문에 실제 상황에서는 훨씬 더 횡설수설하기도 한다.

1. 데이터 분석가와 데이터 저장 위치를 확인해야 했을 때

개인정보보호 부서에 확인해보니 이 데이터는 개인정보 3등급에 해당해 개인 정보용 서버에 분리 보관할 필요가 없다고 하더라고요. 다행히 이번에 데이터 저장할 때 이런 건 신경 쓸 필요가 없을 것 같아요.

2. 디자인 작업물을 중간에 리뷰했을 때

아 그러게요, 원래 저희 제품이 관리자 페이지 역할인데 최종적으로 윈도 프로그램으로 개발되었으니, UI도 조정이 필요하겠어요. 에러 모달* 안의 버튼 두 개 위치를 바꿔야겠어요.

* 사용자의 이목을 끌기 위해 사용하는 화면 전환 기법 중 하나

3. 사업 파트에 요금제 검토를 요청했을 때

추가 옵션을 구매하듯 처리하면 좋겠는데 지금 저희 시스템상 그건 구현하기 어려워 보이네요. 우선 타사처럼 요금제 첫 번째 단계에 넣자는 의견에 저도 동의해요.

4. 서비스 배포 전 취약점 테스트 결과를 봤을 때

보안 부서에서 말씀해주신 내용에 십분 공감하지만, 사용자가 동작할 때마다 API에서 추가로 권한 체크를 하고 있습니다. 서버 개발자분들이 이야기하시길, 사용자가 임의로 이 페이지에 접근할 가능성이 낮다고 하는데 배포 후 따로 시기를 정해서 처리하도록 결정하면 어떨까요?

이렇게 커뮤니케이션만 해도 진이 빠지는데, 기획자는 이 의사결정을 잘 정리해서 전달하고 기록에 남겨둬야 한다. 안 그러면 다들 까먹어서 실수가 생기기 때문이다. 이런 식으로 한 가지 결정을 하는데도 많은 사람들과 조율해야 하니 기획자가 지치는 것은 어쩌면 당연하다. 

그런데 정작 스스로의 업무를 가시화하기 쉽지 않다. 

앞서 말했듯 기획자는 많은 사람들 사이에서 많은 일을 한다. 그러나 사람들 사이에서 여러가지 일을 챙기다 보면, 많은 시간을 보냈지만 정작 결과물이 안 남는 경우가 있다. 즉, 힘들게 일했는데 눈에 보이는 결과가 없는 거다.

예를 들어 QA 환경이 마련되어야 일이 시작되는데, 올바른 환경 세팅이 어려워 고군분투하면서 하루 종일 원인을 파악해야 하는 경우가 있다고 하자. 이것이 해결이 안 되면 하루가 그냥 사라져 버린다. 가장 급한 일을 처리하느라 답하지 못한 문제는 산더미처럼 남기고서. 그러다 보면 스스로 업무량을 가늠하지 못하는 경우가 생긴다. 

나도 연초에 이런 실수를 했다. 작년부터 오랫동안 준비했던 프로젝트 두 개가 동시에 진행되고 있었는데, 하나는 QA 단계였고 하나는 초기 개발 단계였다. 두 프로젝트 모두 기획자가 꾸준히 챙겨야 할 일이 있었는데 내 업무 부하를 인지하지 못했다.

기획자가 병목이 되는 현상이 반복되고 나서야 문제 상황을 인지할 수 있었다. 결국 A 프로젝트는 프로젝트 배포 후 인계받기로 한 담당자에게 1차 커뮤니케이션을 부탁했고, B 프로젝트는 동료 기획자가 두 달 정도 투입되어 도움을 주었다.

이 상황을 진작 예상했다면 팀원들과 업무 조정을 하거나 프로젝트를 진작 다른 부서에 인수인계하는 절차를 거쳤을 수도 있었다. 그럼에도 스스로의 업무 비중을 과소평가해 프로젝트 두 개가 모두 어그러질 뻔한 우를 범했다.

기획자의 숨통을 틔워주는 팁 4가지

프로젝트 오픈을 준비하면서 스트레스가 극에 달했을 땐 정말로 이 세상에 사라지고 싶었다. 하지만 도망가고 싶지는 않았다. 지금 도망가면 난 완주를 하지 못한 사람이지만, 이 마라톤을 완주하면 '출시를 해낸' 사람이 되었을 거라 생각했기 때문이다.

이 글을 읽는 또 다른 기획자인 당신도 여러 상황에서 도망가지 않고 버텨야 할 때라고 결정 내렸을지도 모른다. 나처럼 제품 출시를 앞두고 있거나, 일정 기간 이상 경력이 필요한 상황일 수 있다. 버티려면 자신의 현 상황을 받아들이는 일이 무엇보다 중요하다. 여기에 도움이 될 수 있는 몇 가지 방법들을 이야기해보고자 한다.