나는 뭘 바꾸려고 한 것일까?

내가 잘 알고, 익숙하고, 맞다고 생각하는 방법론들이 반드시 옳은 것만은 아닙니다. 이 방식이 팀에 '왜 필요한지'를 증명하지 못하면요. 이직한 팀에 PM 역할을 하는 팀원들이 있지만, 문제를 발굴하거나, 프로젝트 OKR을 설정하거나, PRD를 작성하거나, 프로젝트 일정 관리 및 리소스를 관리하지는 않더라고요. 그래서 저는 제대로 된 일하는 방식을 도입하면 되겠다고 생각했어요. 이게 '지금 당장 내가 할 역할이다'라고 생각했었습니다. 하지만 팀은 이런 프레임워크 하나 없이도 이미 업계의 1위였고, 제가 옳다고 믿는 방식들이 이 팀에서는 없어도 되는 것처럼 보이더라고요. 지나고 보니 결국 저는 아무것도 도입하지 못했어요.

새로운 회사에 들어가고 많이 놀랐어요. 다들 일을 정말 잘 하시더라고요. 근데 제가 알던 PM 방식으로 일하는 사람은 없었어요. 문제를 찾고, 정의하고, PRD를 쓰고, 분기 목표 담은 OKR도, 개발 리소스 관리도 보이지 않았어요. 그냥 각자의 개인기와 경험들로 이럴 땐 이렇게, 저럴 땐 저렇게 등의 업무 방식으로 일을 하고 있더라고요.

그래서 가장 빠르게 해 볼 수 있는 저의 역할을 찾았다고 생각했습니다. 이렇게 일 잘하는 팀원들에게 PM 방식의 일하는 문화만 도입하면 팀이 훨씬 좋아질 거라고 생각했어요. 그래서 새로운 문화 도입을 시작해봤습니다.

문제를 발굴하고, 문제를 구조화하고 정의해보자. 그리고 문서로 남기자, 임팩트를 숫자로 세워보자, 엔지니어 리소스도 관리하자, 프로젝트 스케줄을 트래킹하자, 임팩트 크기로 우선순위를 정렬하자.

이런 프레임워크는 어떤 도메인에서 일하든 비슷했고, 통했던 확실한 방법이었어요. 근데 반응과 참여가 미적지근하더라고요. 그렇다고 반대를 하는 사람은 없었어요. 근데 점점 시간이 지날수록, 문서도 저만 쓰는 것 같았고, 목표도 저 혼자 세우고, 함께 고민하고 논의하는 기대하던 이상적인 상황은 없었습니다. 저는 이게 저항이라고 생각했거든요. 변화하기 귀찮기도 하고, 잘 모르기도 할테니까요. 하지만 시간이 지나면서, 이게 저항은 아니라는 걸 알게 되었습니다.

이런 방식이 굳이 필요가 없었던 겁니다. 저에겐 당연한 도구와도 같다고 생각했지만, 팀은 이런 프레임워크 없이도 수년간 아주 훌륭한 제품을 만들어왔어요. 저에겐 데이터로 판단하고, 임팩트로 우선순위를 설정하는 게 자연스러웠지만, 이들은 이미 경험으로 몸에 익힌 감각으로 뭐가 중요하고 덜 중요한지 알고 있었습니다. 그리고 이미 업계 1등인 팀에게 새로운 방식은 개선이 아니라 비용인 것 같더라고요.

조직 문화를 개인 혼자서 바꾸는 것은 많이 어렵다는 것을 뼈저리게 느꼈습니다. 일하는 방식이 정해져 있지 않아도, 이미 일이 잘 돌아가고 성과가 난다면 방식을 바꿀 이유를 찾지 못합니다. 이미 1등인데? 뭘 바꾸자는거지? 라는 의문들 앞에서는 제가 '이게 진짜 방법론이에요. 진짜 효과적이에요' 라는 저의 대답은 근거가 너무 약했어요.

그리고 제가 놓친 또 하나는, 새로운 도메인이다 보니, 아는 게 하나도 없었습니다. 시스템이 어떻게 동작하는지, 어떤 플로우인지, 뭐가 진짜 좋은건지 아니면 위험한지를요. 그렇다 보니, 저의 방식이 이 도메인에서 구체적으로 어떤 부분을 더 효과적으로 만드는지를 제대로 설명할 수가 없었어요. '데이터로 판단해보자'라는 일반적인 말은 할 수 있어요. '이 업무에서 또는 이 부분에서는 이 프레임워크가 이런 판단을 가능하게 해줍니다'라는 것들을 구체적으로 제시하지는 못했던 것 같아요.

사람들은 '이 방식이 이론적으로 맞는 것 같다' 보다는 '이 방식이 우리의 어떤 문제를 해결해 주네'를 보는데, 저는 못했던 거죠. 이들의 언어로 대입해서 증명할 수가 없었던 것 같아요.

솔직하게 말하면, 그래서 저는 조직 문화를 결국 바꾸지 못했습니다. 제가 원하는 만큼의 변화가 없었어요. 반년 정도를 밀어붙여봤지만, 여전히 과거의 방식으로 일하는 것이 60% 이상 차지하는 것 같아요. 실패담에 가까운 이야기인데요. 이 실패에서 한 가지는 분명하게 배운 것 같습니다. 순서를 잘못 적용한 것 같아요. 새로운 방식을 도입하기 전에, 도메인 먼저 깊이 이해하고 배우고, 어떤 방식 때문에 비효율이 있구나, 어떻게 하면 효과적이겠다를 먼저 익혔어야 했는데, 그렇지 못한거죠. '그냥 이게 맞아', '이게 맞는 방식이니까 이렇게 해야 돼'로 밀어 붙이기만 했던 것 같아요.

저의 실패담에서 말씀 드리고자 하는 것이 '이미 잘 되는 조직을 고치려고 하지마세요' 라는 이야기는 아닙니다. 지금 방식으로 잘 해왔다고 하더라도, 앞으로도 계속 잘 된다는 법은 없거든요. 규모가 점점 더 커지고, 사람이 늘어나고, 사람과 기억에 의존하던 판단들이 한계에 부딪히는 순간은 반드시 오게 됩니다. 그때, '아 문서가 있었더라면', '아 데이터를 더 분석해 볼걸' 과 같은 후회와 필요성을 느낄거라고 생각해요. 제가 실패한 지점은 아직 한계에 부딪힌 팀이 아닌데, 필요성을 못 느끼는데, 저 혼자 필요한게 맞다고 한 것이 실패했던 이유였던 것 같아요.

돌아보면, 제가 도메인을 변경하면서도 적응할 수 있었던 것은 PM의 방식이었거든요. 그래서 더욱 강한 '자기확신'이 있었던 것 같아요. 나의 방식이 아무리 옳다고 하더라도, 팀은 옳다는 것만으로는 절대 움직이지 않아요. 팀이 새로운 방식을 받아들이는 때는, 그 방식이 정말 본인들에게 엄청난 도움이 된다고 느낄 때예요.

그러니 바꾸고 싶다면, 바꾸자고 말하기 전에 당신의 방식이 어떤 문제를 풀어줄지를 먼저 고민하고 증명해 보세요. 저는 이 순서를 어겼고, 그래서 지난 반년 동안 큰 변화를 만들지 못했어요. 지난 시간들은 아쉬움이 남지만 그래도 저는 앞으로도 지치지 않고, 계속 증명하고 변화를 만들어 낼 겁니다.