brunch

매거진 기획자 빌드업

라이킷 26 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 달하 Mar 27. 2024

문제를 무서워 말아요.

오히려 좋아.

프로젝트 매니저로 일하다 보면 매일 아침 풍경이 거의 비슷하다. 일단 캘린더로 오늘의 회의 스케줄을 확인하고 아침에 별다른 미팅이 없다면 노트북을 켜고 커피를 한 잔 타러 간다. 타러 가는 길에 출근하는 동료들과 가벼운 목례를 나누고 자리에 앉아 메일을 확인한다. 그리고 바로 스크럼보드를 켜고 모든 프로젝트의 진행상황을 확인한다.

주로 여기까지 끝내고 나면 다음 타자는 맞물린 티켓의 우선순위를 정하거나 일정을 관리하거나 의사결정이 필요한 사안에 대한 문서를 정리한다. 그런데, 이 평화롭고 온화한 아침을 와장창 깨는 한 단어가 있다.

어???

웅성웅성 금지가 킬포

개발자 또는 PO로부터 어?라는 단어가 나오는 순간 모두가 미어캣처럼 일어나서 어?? 왜? 를 외친다. 일이 안 풀려서 간혹 발생하는 수준의 어? 정도면 괜찮은데 물음표가 한 열댓 개 붙은 것처럼, 큰일 난 것처럼 엄청 크게 어ㅓㅓ!!!???? 하는 수준의 표현을 하는 개발자들이 간혹 있다.

이렇게 되면 이제 3명 이상 뒤에 서서 그 어? 를 외친 개발자 뒤로 가서 해결하기를 기다린다. 3명에게 둘러싸인 개발자는 식은땀을 흘리고 제대로 된 원인을 찾지 못해 허둥지둥 거린다. 이 글로 보기만 해도 같이 식은땀이 흐르는 사람들이 있을 거다.

그런데 여기서 한 가지 갖춰야 할 PM의 태도가 있다. 어? 를 발언한 당사자 뒤에 가는 열정! 은 아니고, 이 문제를 해결하기 위해 집요하게 파고드는 태도다. 사실 개발자가 아니면 근본적으로 찾기 어려운 이슈가 대부분이다. 그러나 특정 시점 배포를 통해 일어난 사이드 이펙트는 기획자들도 기존과 달라진 정책을 통해 발견하기도 한다.

우리가 무슨 대단한, 예를 들어 피라미드는 어떻게 만들어졌는가 같은 고대 미스터리 사건을 파헤치는 것도 아니지 않은가. 어느 시점 이후로 갑자기 안 되는 버그는 대부분 그 ‘어느 시점’에 무언가 이벤트가 일어나서 그런 거다. 배포가 머지되면서 꼬였거나, 기획이 MECE 하지 못했거나 등 분명 그 시점이 문제의 근원일 확률이 매우 높다.

물론 몇 달 전에는 됐는데 다시 해보니 안돼 이런 건 확실히 원인을 잡기가 어렵다. 암만 로그를 열심히 뒤져도 사람들이 천편일률적으로 똑같은 일을 하지는 않기 때문에 패턴을 파악하기가 쉽지 않다. 하지만 갑자기 로그인이 안돼, 상품등록이 안돼하면 그 시점 로그를 뒤져보면 원인을 비교적 분명하게 찾을 수 있다.

문제를 마주했을 때, 그것을 당당히 직면하고 뿌리까지 파고들어 문제를 해결하는 것은 매우 중허다. 문제를 회피하거나 방치하는 순간, 해결할 수 있는 기회는 점점 사라지고 가능성은 줄어들기 시작한다. 조금 귀찮고 번잡해도 PM이라면 팀 내 누구보다 문제에 대해 정확히 마주하고 원인을 분석하는 과정을 거쳐야 한다.

더불어 내가 진행한 배포에는 문제가 없다고 확신하는 것은 위험하다.(반성 중..) 제품을 개발하고 관리하는 과정에서는 항상 경각심을 가지고 모든 가능성에 대해 열린 마음을 가져야 한다. 우리는 온 우주의 하찮은 인간들이라 항상 완벽한 기획과 개발을 할 수 없다. 그러니 에이, 내가 배포한 건 영향도 없어.라는 생각은 애초에 지워야 한다.

그러니 누군가 오늘 어? 를 외쳤다면 슬랙 쓰레드부터 하나 파두자. “오늘의 어? 발언자 김땡땡님의 문제 해결 쓰레드”를 달아두고 예측되는 원인을 모두가 머리 맞대어 고민하자. 반드시 공개 쓰레드여야 한다. 이 김땡땡을 처단하기 위해서? 놉. 히스토리 축적을 위해서다. 다음에 또 비슷한 문제를 직면했을 때 참고자료로 쓰기 위해서다. (가끔 공개채널 멘션 당하면 날 공격하는 건가?? 오해하는 사람들이 있던데, 그건 매우 잘못된 생각이다.)

제품팀은 한 몸이다. 개발자 김땡땡의 잘못이면 그건 내 잘못이기도 한 것이다. 왜? 나는 이 배포에 아무 연관도 없는데! 해도 같은 제품팀이면 그냥 내 잘못이다 생각해야 한다. 왜 내 잘못인지 억지로 엮어보자면 우리 제품의 결함을 개발자보다 늦게 모니터링한 잘못이랄까. 혹시 미션조직에서의 일을 꿈꾸는 PM이나 PO라면 반드시 기억해야 한다. 타 직무에 비해 그 책임감을 더 많이 느껴야 하는 것이 우리의 몫이다.

그렇다고 너무 겁내거나 주눅 들지 않아도 된다. 어차피 문제는 늘 있다. 점심되면 배고프고 3시 되면 당이 땡기고 6시 되면 퇴근하고 싶은 마음이 드는 것처럼 그냥 문제라는 것은 항시 언제나 상시로 생기는 것이다.

(얼마 전 뜬 젠슨황 인터뷰처럼, 요즘 티셔츠에 내 잘못 아니라고 쓰고 다니고 싶을 때가 참 많다..)

그러니 너무 두려워말고 문제를 직면하자. 막상 해결하고 보면 별 것도 아니고, 해결하면 그건 또 내 자산이 된다. 회고하면서 이번의 문제를 되돌아보고 향후 같은 실수를 반복하지 않도록 모두가 인지하는 것으로도 충분히 가치가 있다. 이것은 학원가도 클래스 101 가도 못 배운다. 실무에서만 배울 수 있는 소중한 경험이니 문제를 너무 두려워 말지어다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari