완결성이 아닌 효용성을 보는 우물밖 세상(PO의세상)
<우물 안 일잘러를 아시나요> (10)
2020년 12월 31일의 밤은 살면서 가장 괴롭게 느껴지던 날이었다. 정확하게 10월에 입사해서 3개월간 느낀 여러가지 감정들은 스스로에 대한 의문점을 잔뜩 불러온 상태였다. 입사 직후 진행한 프로젝트는 정상적으로 잘 달려나가고 있었지만, 내가 어떤 힘을 가지고 프로젝트를 끌고간다고 느꼈던 지난 날의 과거와 비교하면 나는 우왕좌왕하고 있었다.
일하는 방식을 바꿔보고 싶어서 왔기 때문에 나는 동료들의 이야기에 귀를 기울이고자 했다. 이미 그 방식이 익숙한 조직에서 오랜 시간 보내온 개발자와 디자이너와 함께 일하면서 나에게 기대하는 것이 무엇인지 정리해보기로 마음을 먹었다. 그리고 그 과정이 날 계속 답답하게 만들었고 ‘내가 이런 식으로 일을 하기엔 부족한 사람이 아닐까’하는 쭈굴쭈굴하고 꼴봬기 싫은 ‘가면증후군’의 모습이 나타나기 시작했다.
2021년 1월 1일은 그 지긋지긋한 가면증후군에 대해서 내가 선을 그은 날이었다. 12월 31일 밤에 나는 누워서 몇가지 생각을 정리했고, 펑펑 울면서 자정을 넘겨 2021년을 맞이했다.
우물안 일잘러를 울게 만든 ‘비즈니스 임팩트’
모든 고민의 근간은 ‘비즈니스 임팩트’라는 이 단어 하나에 있었다.
서비스기획자로 오랜시간 일했던 조직에서 나에게 주어줬던 가장 핵심 목표는 단연코 ‘임무완수’였다. 여기서 임무란 아무리 방대한 요청일지라도 그 근간의 이유와 원하는 것을 파악해서 의도한 일정안에 완벽하게 오류없이 프로덕트로 만들어내는 것이었다. 요청자가 스스로도 정확히 모르는 근간의 이유들과 목표를 대화를 통해서 풀어내면서 정말로 일정내 개발 가능한 수준을 찾아내거나 개발하지 않고도 그 목표를 맞출 수 있는 기존 기능들을 컨설팅 해주는 것이 나에게는 훌륭한 목표이자 최선이었다.
물론 그래서 종종 이런 의문이 들고는 했었다.
“그래서 내가 그 프로젝트로 그 기능을 만들어주면, 그 목표가 이뤄지는게 진짜 맞아??”
기가 차다는 듯이 콧웃음을 치거나 어이가 없어했어도, 내 역할이 아니었기에 거기에 대해서 물어볼 수는 있어도 딱 거기까지였다. 나는 이미 리더들이 승인한 거라면 실제 그 프로젝트의 성과가 나올 수 있느냐와 관계없이 프로젝트를 진행했고, 실제 목표한 성과가 나오는지에 대해서는 알고 싶어도 알 수 없었다. 마음은 답답했지만 그저 오픈 후 오류가 나질 않길, 후련하게 휴가라도 갈 수 있는 여유가 생기길 나도 모르게 기다렸다.
그런데 내가 나온 우물밖의 이 곳에서 만난 프로덕트팀의 테크리드(TL, 프로덕트팀내에서 개발을 총괄하는 리드)가 계속해서 이 단어를 이야기했다. 심지어 프로젝트가 이미 규정되서 진행되고 있음에도 매번 회의를 할 때마다 그 질문을 했다.
“어떻게 비즈니스 임팩트를 더 키울 거에요?”
“비즈니스 임팩트를 수치적으로 정리해줄 수 없어요?”
이미 다른 회사에서 내가 하고자 하는 방식에 익숙한 그 TL의 질문에 나는 가슴 한켠이 답답했다. 내가 진행하고 있는 프로젝트는 최종 사용자에게 바로 연결되서 구매로 이어지는 프로덕트가 아니라 어쩌면 인프라 시스템처럼 소위 백엔드가 더 많이 필요한 프로덕트인데 비즈니스 임팩트를 물으니 미칠 것 같았다. 나는 자꾸만 추상적으로 대답했고, 테크리드는 여전히 같은 질문을 했다.
이 충돌은 프로젝트 세팅의 전반적인 부분으로 이어졌다. 상품시스템을 새로 만들어야 한다는 미션에서 나는 내 경험을 통해서 필요한 모든 상품 항목들을 열거했는데, 팀원들과 리뷰하는 과정에서 ‘비즈니스 임팩트’를 위해 꼭 필요한 항목을 정해서 그것만으로 오픈할 수 있어야 첫 오픈 시점을 맞출 수 있다는 점에 대해서 이야기가 모아졌다. 그리고 나는 여기서 첫번째 큰 차이를 정의할 수 있었다.
“기능(feature)의 완결성과 기능의 효용성 중
무조건 후자를 택하는 세상에 온 거구나.”
기능의 완결성을 추구한다는 것은, 그 기능을 사용하는 모든 사용자의 이용 케이스와 발생가능한 데이터적 케이스를 모두 고려하여 그에 맞는 정책을 빠짐없이 기획한다. 그만큼 개발과 디자인을 해야할 케이스가 많다. 여기서 한단계 더 나아가면 내가 처음에 서비스기획을 시작했을 때 들었던 그 단어 “확장가능성”에 대한 부분까지 나아가게 된다. 기능의 확장가능성이란 예를 들어 나중에 이 기능에서 지금은 제외되었지만 추가적인 기능을 만들 수도 있으니까 그걸 개발 설계에 녹여달라고 하는 것에 해당한다. 이렇게 기획을 할 때는 120%를 상상하고 그 중에서 20%가 버려질 수 있다는 것을 감안하고 기획을 한다. 어차피 과도한 기획이기에 다 수용하지 못하는 것이 당연해는 상황이 되기에 가능한 더 많은 양을 내세워서 합의가능한 수준을 높이려고 한다. 그래야 완결성을 조금이나마 높이게 되니까.
나와 같이 일하던 요청하던 사람들도 마찬가지였다. 어차피 짤릴 수 있는 걸 알기에 누구라도 숟가락이라도 하나 더 얹어서 ‘기왕에 하는 김에’ 완결성과 활용도를 높이고자 했다. 프로젝트는 항상 점점 커지고 그 때부터 나는 스탠스를 바꿔서 매번 회의할 때마다 아이디어를 내면서 요구사항을 더하기하려는 수많은 사람들과 칼싸움을 하면서 이겨내거나 방어를 해야했다. 그래서 그 당시에 나의 별명은 ‘암사자.’ 마치 사자의 무리의 암사자가 싸움을 나가듯이 내가 담당하는 모듈의 개발자들에게 약속한 요구사항이 더 불어나가지 않도록 막으려고 했었다.
그렇다면 기능의 효용성을 중요시하며 일하는 세상은 어떤 거였을까. 이커머스에서 만들 수 있는 10가지의 상품 종류가 있다면, 당장 오픈 시키려고 하는 단 한가지의 상품 종류에 최적화해서 확장성을 고려하지 않고 만들어내는 것이다. 그리고 그 최적화의 과정에서 ‘확장 가능성’에 대한 부분도 배제한다. 나중에 9가지 종류가 들어올 때를 대비해서 미리 만들기 보다는 1가지씩 추가할 때 기존의 시스템을 다시 부시고 새로 필요한 만큼 확장해서 만들어낸다는 약속이 존재했다.
“같은 시스템을 두 번 개발하는 게 비효율적인게 아니라,
쓸지 말지 모르는 필요하지 않은 것을 개발하는게 비효율적인 거죠”
개발 효율에 대한 기준 역시 다르게 적용하니까, 전에 있던 논쟁은 일어나지 않았다. 요구사항이 더해지고 더해지다가 등장하는 “리뉴얼” 혹은 “차세대”에 대한 이야기는 필요없는 이야기로 느껴졌다. 어차피 매번 ‘비즈니스 임팩트’가 일어나야 할 때마다 부분적으로 리뉴얼이고 부분적으로 차세대였다. 이게 가능한 이유는 단 하나, 프로덕트팀에 속한 같은 사람들이 계속해서 그 프로덕트 시스템을 관리하고 변경에 대해서 인지하고 기존의 한계도 잘 알기 때문이었다. 그래서 이렇게 일하는 조직들의 개발의 속도와 텐션이 달라질 수 있었다는 것을 체감했다. 기존의 환경에서는 고정된 데이터베이스 구조도(ERD)를 전달받아서 몇 년간 기획하는데 활용했다면, 수시로 일어나는 리팩토링과 개선으로 인해서 기획자 역시 직접 SQL로 현재 현황을 보지 않으면 안되는 상황이었다.
비즈니스 임팩트란 내가 만드는 시스템의 기능(feature)의 존재가치를 증명해줘야 하는 것이었다. 그렇기에 실제 프로젝트가 끝난 뒤에는 증명할 수 있어야 하고, 여기서 수치적인 목표(메트릭)이 나오는 것이었다.
기존의 나의 생각 틀에서는 ‘기본’도 다 하지 않고 프로덕트를 기획해서 오픈시켜야 하는 모습으로 보였다. 하지만 새로운 생각의 틀을 이해하게 되면서 드디어 우물 밖에 적응해서 일하기 위한 새로운 미션이 생겼다.
‘어떻게 하면 비즈니스 임팩트를 정의하고
그에 맞게 적절한 양만큼의 기획을 만들어낼 것인가.’
이 것도 분명 연습이 꽤나 필요해 보였다.
눈물로 시작한 신년, ‘원서’로 시작하다.
2020년 12월 31일 밤, 나는 침대맡에 누워서 나의 부족함에 눈물을 흘리며, 한참을 생각했다. 내가 부족한건가 내가 적응을 못하는 건가하는 못난 마음들이 불쑥불쑥 올라올 때면 30대 중반에 흘리는 눈물이 더 뜨겁게 느껴졌다.
결국은 비슷한 일이지만 뭔가 생각의 근간이 다르다면 그 근간을 다루는 이론이 분명히 있을 거라고 생각했다. 하지만 기존에도 비슷한 접근으로 여러가지 책과 아티클을 봤지만 정말 준비가 되지 않았다는 점이 마음에 걸렸다. 나는 나의 문제를 해결하고 싶었다. 기필고 이렇게 일하는 방식에 대해서도 설명할 수 있는 사람이 되고 싶었다.
그 때 한가지 아이디어를 떠올렸다. 내가 이 우물밖에서 온 여러 사람들과 일할 때 가장 처음으로 다르다고 느꼈던 것이 있었는데, 바로 어휘였다. 충분히 한국어로 설명할 수 있는 단어들도 영단어가 난무했다. 심지어 축약어였다. 사용자에게 어떤 소구점이 있는지는 USP(Unique selling point)라든가 사람들과의 대화를 통해서 합의를 본 것은 ‘컴(커뮤니케이션)했다’라고 하는 둥 처음에는 알아듣기도 힘들었다. 같은 IT 판이 맞나 싶을 정도로 판이하게 다른 용어를 사용하고 있었다. 이른바 ‘판교 사투리’라고 불린다는 것도 처음 알게 됐다.
이 판교 사투리가 왜 쓰이는 지를 생각했다. 답은 간단했다. 판교나 IT회사 중 지금과 같이 일하는 방식의 사람들은 실리콘밸리의 독보적으로 큰 빅테크 기업들을 벤치마크하거나 혹은 그 출신들을 초빙해서 성장했기 때문이었다. 내가 본 번역 책들이 실제 환경과 연결되지 못한 이유는 혹시 어휘 때문이 아니었을까라는 생각에 다다르자 선택은 하나였다.
“실리콘밸리의 사람들이 쓴 원서로 그 근간의 사상을 찾아보자.”
그리고 2021년 1월 당시에 국내에 출간되지 않았던 <인스파이어드>의 저자 마티 케이건의 <임파워드> 원서를 구글에서 ebook으로 구입했다. 영어 원서 읽을 수준이 안되고 기존에도 원서로 읽기엔 턱없이 부족한 영어실력이었지만 직무상 배경지식이 분명히 날 도와주리라 믿었다. 그리고 그 시작은 나에게 정말 큰 도움이 되었다.
원서책을 조금씩 읽어나갈 때마다 번역서에서 찾아내지 못했던 진짜 동료들이 이야기하던 그 단어 그대로 쓰여진 배경들을 읽어나가기 시작했다. 한권을 미처 다 읽어내지 못해도 한 두 페이지에서 얻은 힌트를 그대로 활용해보기도 했다.
임파워드에서 프로덕트오너는 팀내의 HR의 역할을 어느정도 한다는 이야기를 읽으면서 1 on 1(1대1 미팅)을 한다거나, 각 개인이 실제 팀에서 성취하고자 하는 욕망을 인지하고 그에 맞는 프로젝트를 추가하여 개인의 참여를 높여야 한다는 것도 처음 알았다. 나는 바로 행동으로 옮겨서 팀내의 모든 개발자에게 1 On 1을 요청했다. 하지만 갑자기 권한도 없고 이유도 없는 1 On 1이 이상할 것 같았기에 나는 한명 한명을 만나서 개인 인터뷰 형태로 아티클을 써서 사내 노션 페이지로 발행했다. 그 인터뷰를 통해서 개인의 배경과 지향점도 알게 되고, 그들이 이미 겪었던 프로덕트오너로서의 기대역할이나 현재 나의 상태에 대해서도 피드백을 받을 수 있었다.
하지만, 그 시도는 의미가 있었음에도 빠르게 접었는데, 마지막으로 인터뷰 했던 사람의 말 한마디 덕이었다.
“아직 폴리는 프로덕트오너로서의 욕심이 없는 것 같아요”
아직 바뀐 나의 아이덴티티의 차이점을 정확하게 설명하기 버거웠던 나는, 그 문장을 듣는 순간 얼굴이 벌개지고 귀가 달아올랐다. 뭔가 폐부를 찔린 것 같았다. 적당히 하고자 우물을 기어나오는 것이 아니었기에 그 상황이 당황스러웠다. 다시금 내가 모르는 것이 무엇인지 내가 부족한 것이 무엇인지 고민에 빠져들었다. 정말 중요한 것보다 겉모습을 조금 따라가고 있는 것은 아닐까..? 밤새 이불을 뒤척이며 다시 고민했다. 이게 지독한 가면증후군이라고 해도, 나는 그런 말을 다시는 듣지 않을 방법을 찾고 싶었다.
그리고 그건 보여주기식 1 on 1의 요청이 아니라 동료들이 보기에 내가 새로운 일의 방식을 이해하고 진심을 다하는 것이었다. 나는 프로덕트팀에 적응하려고 하는 것이 아니라 처음으로 진짜 의미있고 비즈니스적 효용가치가 있는 프로덕트를 놓고 고민을 시작하기로 결심했다.
