결정하는 사람 #1

대중에게 미움을 받고 안좋은 평가를 받는 사람들의 예시 중에 '리더'가 등장했다. 왜 리더를 미워하는 예시인지를 설명하다보니 보편적인 가치, 사고 그리고 편견에 대해 설명할 수 밖에 없었다. 누군가는 지지하고 누군가는 지지하지 않는 일을 결정하고 결단을 내리며 일을 추진할 수 밖에 없다는 설명과 함께 의사결정을 하면서 생길 수 있는 것들에 대해 설명해야 했다. 이제 초등학교 3학년인 아이에게 이 설명을 이어가다보니 나도 모르게 아이가 리더를 하지 않았으면 좋겠다는 마음까지 들었다.

나는 매우 높은 수준의 의사결정권을 가진 PO¹를 선호하는 탓에 기능이나 요구사항을 설계하는 데에 그치지 않고 더 많은 의사결정을 해왔다. 그리고 그렇게 일을 하는 것을 선호하고 즐기는 탓에 힘들어도 힘든 내색도 하기 어렵다. 이와 반대되는 것을 요구하는 곳에서의 일하는 경험이 더 힘들었다. 난 동일하게 힘들거라면 내가 컨트롤 할 수 있는 어려움을 선택하는 편이다. 그래서 이런 길을 걸어온 나인데 정작 내 아이는 리더를 안했으면 좋겠다고 생각하다니 아이러니 하다. 언젠가는 좋고 옳다고 믿는 결정을 하는 상황이 올텐데 그런 일 없이 그냥 행복함만 쫓으며 살았으면 좋겠다는 양가적인 감정이 내 안에서 충돌했다.

얼마 전 동일 직무의 동료가 팀을 떠났다. 높은 수준의 의사결정권을 가진 만큼 결정으로 인한 반발도, 결정에 대한 설명도 온전히 본인의 몫이었던 만큼 지쳐가는 것들이 보였다. 물론 이것말고도 많은 이유들이 복합적이었으리라 생각한다. 그냥 나의 시선에 박힌 그가 가장 힘겨워하던 순간은 실행하기 위한 설득의 과정이었다. 왜 이걸 실행하고자 하는지 논리적인 설명을 하려다 보니 논리를 만드는 시간을 썼고 그 논리를 만들며 자신의 논리가 완성되어 버린 모습에 동료들은 반감을 가졌다. 나는 여기서 누구도 잘했다고 생각하지 않으며, 어느 누구도 잘못했다고 생각하지 않는다. 일어날 일이 일어났고, 있어야 했던 충돌이 있었다. 어디선가는 당연한 수순인 기획자가 기획하고 문서를 넘기며 Hand-off 하는 행위가 여기서는 반발이 생기는 것이다. 이유는 하나다. 여기는 그렇게 일하는 방식을 선호하지 않기 때문이다. 다른 곳에서라면 일을 엄청 열심히 하고 잘한다는 평가를 들었을 것이다. 그냥 '여기'와 '그'가 맞지 않았을 뿐이다.

조직 개편이 있을 때면 운영 모드로 돌아가기로 결정된 일들이 우리 팀으로 들어오기도 하고, 갑작스러운 조직 구조의 변화가 있을 때 내가 소방수가 되어 대행을 하게 되는 경우가 있다. 지금까지 반기에 한번씩은 이런 일이 있었으니 이젠 어느정도 익숙해질 법도 한데 새삼스럽게도 매번 새롭고 힘든 역경의 순간이 있다. 내게 가장 힘든 순간은 이미 너무 많은 시간을 써버린 0 to 1을 하는 제품이 넘어왔을 때이다. 여러 이유와 맥락이 있겠지만 두번째 동일한 상황을 마주하니 이건 모든 곳에서 이렇게 일을 한다는 확신으로 이어졌다. 더 작게 더 빠르게 실행하고 빨리 힌트를 찾아야 방향을 잡을 수 있는데 방향에 대한 확신도 없는데 시간은 다 소비한다. 자세한 맥락을 모를 때는 그런 이유가 있겠지라며 나의 일에도 급급해서 그냥 흘려 보냈던 것들이 이제야 내 눈에 보인다. 데이터를 보니 지금 이 구조 안에서는 100% 실패라는 것을 알게 됐다. 다른 걸 할 때가 아니다. 그냥 굉장히 파격적이어야 하고 이미 날려버린 시간을 뛰어넘는 무언가를 만들어야만 한다. 그리고 이렇게 하겠다는 결정을 내리고 10분만에 설득이 끝났다.

"여러분 미안해요. 정말 억울할 거예요. 저도 안타깝지만 어쩔 수 없어요. 런칭하고 한 달 동안 100명이 들어왔고, 유료 전환이 10명이면 10%이긴 해요. 하지만 이번 반기 목표인 800명을 달성하려면 전환율을 개선하는 수준으로 할 수 있는게 아니에요. 우리 2.5개월 남았잖아요. 완전히 바꿔야 해요"

이미 그들이 목표가 말이 안된다며 낮춘 목표였다는 것은 몰랐는데, 아마 목표를 낮추자 했어도 나는 반대했을 것이다. 이 목표는 우리가 검증하고자 하는 가설이 옳다는 것을 증명하는 기준인데 그것을 낮추고 쉬워진다고 해서 시장이 쉬워지는 것은 아니기 때문이다. 나와 일을 해본 적 있는 동료가 입을 열었다.

"그래서 어떻게 하자고요?"

"저도 잘 모르겠어요. 일단 이 기능, 제품의 코어의 프로세스를 따르도록 해주세요."

"그래도 돼요?"

"돼요. 안되면 제가 어떻게든 되게 설득하고 올테니 걱정말고 해주세요."

그리고 30분짜리 미팅이었는데 어느 덧 한 시간을 훌쩍 넘는 시간동안 치열한 토론을 했다. 완벽함과 조금의 개선, 아쉬움들은 다 내 손으로 거절하고 버리도록 했다. 그리고 어느정도 가닥이 잡히기 시작했고 어느정도 틀이 나왔다.

"좋아요. 최대한 단순하게 하고 코어에 구현되어 있는 이미 검증된 전환율과 이탈 방지 기능을 활용하게 해주세요. 3일 안에 해볼 수 있을까요?"

나의 멘트에 회의에 참석한 모두가 얼굴이 붉게 변했다. 내가 말도 안되어 보이는 일정을 입 밖에 꺼내놨기 때문이다. 지금 모여서 방금 결정한 변경사항을 3일 안에 해내는 것은 불가능하다는 말이 나왔다.

"그럼 5일 안에 배포하는 것으로 할게요. 3일은 우리가 완성시키는 목표 일정이라고 생각하고 달려주세요. 저는 그 시간 안에 바텀업 싱크 맞추고 마케팅, 세일즈, Biz Dev, 운영팀 어떻게든 도움 받고 설득하고 올게요."

"네 한번 해보시죠"

나는 이미 이 팀의 리더였다. 하는 일은 잡일이지만 성공을 만들고 문제를 해결하는 것이 나의 일이고 이를 위해 앞장서서 모두의 방향을 맞추고 이끄는게 내가 할 일이다. 임파워먼트(책임과 권한)를 갖는다는 것의 권한은 사실 제안할 수 있는 권한이고 책임은 다시는 반복하지 않을 책임이다. 이제 우리 팀이 권한을 온전히 갖게할 시간이고 이 길이 맞는지 아닌지 증명하고 결과를 가져올 차례이다.

Product Owner ↩

Footnotes