brunch

You can make anything
by writing

C.S.Lewis

by Ji Mar 01. 2018

개발자를 위한 UX를 고민하고 있습니다

그것도 개발자가 아닌 UX 디자이너가요-

몇 달 전 브런치에 마지막 포스팅을 올린 후로 많이 바빴습니다. 사실 그 전에도 많이 바쁜 것 같았지만...ㅎ 개인적으로 지금까지 경험해보지 못했던 상황들과, 과제들과, 권한과 책임을 마주하게 되면서 생각의 여유가 없었던 것 같아요. 그러다가 이제야 뭔가 지금까지 내가 경험하고 있는 상황들에 대해 뭔가 생각이 정리되기 시작해서 한번 정리를 해보려 합니다. 



Product Leader가 되었습니다


마켓 컬리에는 소위 말하는 C-level의 직급체계가 존재하지는 않습니다. (마켓 컬리에서 공식적으로 유일한 C-level은 CEO 뿐입니다). 다만 전문영역별로 다수의 Leader분들이 계십니다. Marketing Leader, Operations Leader, Finance Leader, Customer Communication Leader 등... 이렇게 말이죠. 그리고 그중에서 Product(마켓 컬리에서 판매하는 상품이 아닌 시스템) 영역에서의 Leader를 맡게 되었습니다. 그리고 그날부터 저의 책임과 부담이 많이 커졌던것 같습니다. 


개인적으로는 이때까지는 저 자신을 개발자들과 합이 잘 맞고, 잘 이해하는 편인 UX Designer이고 Product Manager였다고 생각했었습니다. 심지어 처음 마켓 컬리에 와서 Product Manager로서 지금까지 미루기만 하던 의미 있는 작업들을 개발자분들과 구현해내기 시작하면서 그 착각이 더 커지기도 한것 같습니다. 그런데 막상 개발팀과 가장 가깝게 일해야하는 리더가 되고나니 제 약점이, 제 능력의 한계가 바로 보이기 시작했습니다. 그래서 더 불안하고 부담스러웠던것 같기도 하고요. 그래서 우선 면담부터 시작했습니다. Product Leader가 된 그날부터 그 주가 지나가기 전에 모든 팀원과 1:1로 면담을 진행하겠다고 무리를 하다가 과로로 결국 몸이 많이 아프기도 했었지만, 그 당시에는 그렇게 한 사람 한 사람과 이야기를 나누는게 제가 혼자 고민하고 걱정하면서 감당해야하는 스트레스보다는 나은것 같다는 생각에 그렇게 제 자신을 몰아붙였었던것도 같네요. 



저는 개발, 개발 문화, 개발 조직에 대해서 모르는 사람입니다


그렇게 팀원들과 면담을 하고 계속 실무를 하는 시간이 늘어나면서 자연스럽게 저에 대한 그리고 우리 팀에 대한 깨달음이 왔습니다. 개인적으로 가장 확실했던 결론은 저는 개발과 관련된 아무것도 모르는 사람이라는 것입니다. 제가 지금까지 알고 있었던 개발에 대한 지식은 개발자와 소통하기 위한 정말 최소 단위의 수준도 안되었고, 그런 제가 개발자들과 기술적인 맥락에 있어서의 판단을 내려준다거나 신기술 도입 등에 대한 리딩을 하는 것은 말도 안 되고 해서도 안 되는 일이었습니다. 


문제는 저의 개발 영역에 있어서의 무지함만이 아니었습니다. 마켓 컬리 시스템 자체가 가지고 있었던 기술 부채의 부담도 있었습니다. 제가 마켓 컬리에 오고 처음에는 우선순위에 대한 파악이 제대로 되지 않아 진행조차 하지 못했었던 기능들이 제가 직접 티켓 관리를 하기 시작하면서 점진적으로 개발 완료가 되기 시작했습니다. 모두의 격려와 응원을 받으면서, 또 기존에는 해보지 못했었던 기능들을 드디어 완료해내기 시작하면서 개발 조직도 저도 점점 난이도 높은 기능들을 개발하는 프로젝트를 시도하기 시작했죠. 개발까지는 큰 문제가 없이 완료되었고, 그렇게 시스템은 (겉으로 보기에는) 매우 고도화가 되어가기 시작했습니다. 다만, 비지니스 초반부터 기술 부채가 많이 누적되어 있었던 마켓 컬리의 시스템에서는 점점 더 큰 기능이 개발이 될 때마다 시스템 전방위적으로 그 잠재 영향범위가 늘어났습니다. 결국 주문량이 폭증하기 시작했던 2017년 연말부터 시스템의 근본적인 한계에서 오는 문제점과 더불어 기존 시스템에 의존해서 고도화를 시킨 기능들이 말썽을 부리기 시작했습니다. 그리고 그런 문제들은 항상 같이 오더군요... 다짜고짜 추가 개발만 할 수도 없는 상황이었습니다. 기존의 시스템을 벗어나야 했고, 기존 시스템을 벗어나기 위해서는 점진적이고 체계적인 시스템 뉴플랫폼화에 대한 계획과 설계가 존재해야만 했으며, 그 모든 단계들이 지금 계속 급격하게 성장하는 비지니스의 발목을 잡지 말았어야 했습니다. 


솔직히 막막한 부분들은 있었지만, 지금까지의 경험상 막막하다고 혼자서 고민만 하고 있다거나 좌절한다고 해서 나아지는 상황은 하나도 없다는 것은 알기에 그냥 무작정 '리서치'를 시작했습니다. 지금까지 이야기했었던 사람들과는 더 구체적인 이야기들을 나누기 시작했고, 지금까지 이야기를 안나눈 사람들과는 억지로 미팅을 만들어서까지 소통을 시작해봤습니다. 모든 시스템을 관통하는 인프라 시스템의 뉴플랫폼화를 위해서는 모든 담당자의 인풋이 필요했기 때문이죠. 매주 물류센터에 가서 지금 발생하고 있는 문제가 시스템의 한계에서 오는 것인지, 아니면 일의 프로세스 때문에 생기는 것인지를 실무자들과 만나고 이야기를 나누면서 가시화하려고 했습니다. 그리고 그중에 계속 우리 개발팀과 개인적으로, 그룹으로 전체와 계속 이야기를 나누면서 마켓 컬리에서의 인재상, 우리 팀원들이 원하는 개발 문화, 개발 프로세스에 대해서 조금이라도 더 알아보려고 했습니다. 


그렇게 '사용자(개발자) 리서치'를 마치고 얻은 몇가지 굵직한 결론은 다음과 같습니다. 

결론 1. 
우리 팀원들은 기술역량의 수준이 다양하게 분포되어 있습니다. 다만, 기술역량의 수준이 상대적으로 낮은 팀원도 비지니스적으로는 매우 중요한 프로젝트를 진행할 수 있다는 것을 알 수 있었습니다. 
결론 2.
우리 팀원들은 성과지향형과 안정지향형의 성향을 가진 담당자들이 골고루 분포되어 있습니다. 그리고 성과지향형인 인재들과 안정지향형 인재들은 동기부여가 본인의 직무와는 기준과는 별개로 다르게 되어야 한다는 것도 알 수 있었습니다. 
결론 3.
많은 팀원들이 '우수한' 개발 조직이라면 어떤 것들을 하고 있다는 표면적인 결과물에 대해서는 예를 들기는 했으나 과연 어떻게 그런 조직이 될 수 있을지에 대해서는 구체적인 아이디어나 방법을 제안하지는 못했습니다.



개발은 모르겠지만 우리 팀원은 조금씩 알 것 같습니다. 그래서 이런저런 도전들을 시작합니다. 


사실 팀원들과 이야기를 나누면서 가장 흥미로웠던 부분은 저 '결론 3'이었습니다. 만약 그 지점에 어떻게 도달해야 하는지 그들도 나도 정확히 모른다면, 그냥 쫄지말고 다 같이 도전을 하면 되겠구나 하는 막연한 무모한 기대가 생기기도 했던 지점이었기 때문이죠. 팀원들과 이야기를 나누면서 어느 정도 상황이 가시화가 된 후에는 혼자 이런저런 공부를 해보고 아이디어들을 정말 마구마구 뱉어내면서 팀원들의 반응을 살펴보고, 또 마켓 컬리 외 개발자들과 이야기 나누면서 피드백을 받아보고, 심지어 개발자들을 추천해주는 헤드헌팅 업체와도 미팅을 진행하면서 제 아이디어들의 수용도를 평가해봤습니다. 그렇게 정리하게 된 저의 Design Direction은 다음과 같습니다. 


Design Direction 1. 어떻게 하면 '같이'할 수 있을까 - Team   

특정 인물의(PM) 적극적인 개입이 없이도 서로 협업을 하는 구조를 어떻게 만들어 낼 수 있는지가 중요합니다. 특정 인물, 혹은 상부의 개입 없이도 자체적으로 시스템적인 부분에 있어서의 문제를 가시화하고 공론화할 수 있는 공통의 관심이 필요하며, 누구든지 최소한의 용기만 내서 문제를 공론화할 수 있도록 하는 신뢰가 필요하고, '누군가'가 고생해야 하는 문제가 아닌 '우리'가 풀어야 한다는 의식의 전환을 목표로 합니다. 


Design Direction 2. 어떻게 하면 '같이 성장'할 수 있을까 - Growth

Legacy시스템을 담당하는 사람은 최선을 다해 현재 발생하는 운영성 이슈와 시스템 고도화를 통한 업무 자동화를 해야 합니다. New Platform을 병렬적으로 개발하는 팀원들에게 업무에 집중할 수 있는 여유와 환경을 제공해줘야 하기 때문입니다. New Platform을 바라보고 개발하는 팀원은 궁극적으로 우리 팀원들이 모두 사용하게 될 시스템이라는 사명감을 가지고 더 체계적으로 개발을 해야 합니다. 또한 신기술을 도입하는 데 있어 시니어 개발자는 주체적으로 지속적으로 학습하고 소화하여 팀원들에게 소개해야 하며, 팀원들은 공격적으로 흡수하고 적용할 수 있는 자체적인 시도들을 해봐야 합니다. 


Design Direction 3. 어떻게 하면 '같이 성공'할 수 있을까 - Alignment  

마켓 컬리의 비지니스 모델이 가지고 있는 가능성까지 수용할 수 있는 New Platform을 개발해야 합니다. 고객의 경험을 완성해야 하기에 인프라의 통합이 이루어져야 하며, 지금까지 가보지 못한 영역을 가 보아야 하기에 확장성 있는 시스템이 필요합니다. 그 모든 단계가 유통의 본질로 돌아가(소비자 관점에서, 중계자의 관점에서, 공급자의 관점에서) 새로운 '상식'의 기준을 제공해야 하는 미션을 가지고 도전하고 노력해야 합니다. 그리고 그 모든 성과들을 매일매일 쌓아 올려가며 점진적으로 도달해야 합니다. 



마켓 컬리는 정말 멋진 회사입니다. 그리고 우리 팀도 그렇게 멋있어지려 합니다


제가 항상 전속력으로 달리고 있으면 소피(대표님)와 길남 님이 저에게 해주는 말이 있습니다. '100M 달리기를 하지 말고 매일매일 최선을 다하는 꾸준한 마라톤을 해라'라고요. 그렇게 멋진 말 하고서는 자기네들은 100미터 달리기 속도로 철인 삼종경기를 뛰면서... 마켓 컬리가 하루아침에 업계를 바꿀 수 없는 것처럼, 우리 팀 또한 역시 매일매일 꾸준히 도전하고, 노력하고, 돌아보며 나아가려고 합니다. 위의 방향성/목표를 도달하기 위해서 지금 당장에도 많은 도전들을 하고 있습니다. 모두 소개할 수는 없겠지만 가장 최근에 도전 중인 아이템들을 공유하자면 다음과 같습니다. 

비지니스와 UX관점을 기준으로 방향성 및 목표가 명확한 단위로 조직을 개편했습니다. 적게는 2명, 많게는 7명까지도 팀의 단위를 구분하여, 각각 팀별 목표를 구체화하는데 오해가 없고 최소단위의 팀워크를 구축할 수 있도록 가시화를 시켰습니다. 각 팀별로 가지고 있는 목표를 달성하게 된다면 자연스럽게 그 타이밍이 조직개편이 되는 타이밍이 되겠으나... 그런 조직개편 조차도 실무자들에게는 큰 의미가 없는 협업의 구조 및 프로세스를 만들어 보는 것이 저의 목표입니다. 
개발 설계 리뷰, 배포전 코드리뷰와 더불어 개발 회고의 시간을 가지려 합니다. 실무자들이 최근에 개발한 프로젝트를 팀원들에게 소개하고 기술적인 맥락에서 더 나아질 수 있는 피드백들을 수렴하는 자리를 가짐으로써, 개발 담당자는 피드백을 수렴하며 한번 더 고민하고 학습하는 기회를 가지고 팀원들은 소통 및 회고를 통한 서로 업무에 대한 가시화가 되는 것을 목표로 합니다. 회고의 시간을 통해 나온 모든 결과물은 물론 기록하여 추후에 어떤 방향으로든 활용할 수 있도록 관리할 예정입니다. 
저희 팀에 속해있는 모든 담당자분들에게 본인의 개인 KPI와 팀빌딩을 위한 KPI를 설정해서 저에게 공유하는 과정 중에 있습니다. 1차적으로 모두 KPI가 취합되면 제가 비지니스 관점 및 인재상 관점의 목표를 기준으로 피드백을 공유하고, 최종적으로는 각자 설정한 KPI를 팀원들에게 공유하는 자리까지 가져보려 합니다. 주체적으로 일하는 팀이 되기 위해 우선 각각 팀원이 주도적으로 주체적으로 마켓 컬리에서 도전할 수 있는 목표를 고민해보고 설정하는 것이 가장 투명하고 공정한 팀의 운영방식이라고 생각했기 때문입니다. 그리고 팀원의 성과 평가를 진행할 때도 물론 이때 설정한 개인 KPI 및 팀빌딩 KPI를 기준으로 평가할 예정입니다. 
모든 팀원들은 팀 단위로 데일리 스크럼을 진행하며, 그중 일부팀은(Product, Product -dev팀) 프로젝트를 스프린트 단위로 관리합니다. 이는 2주 단위의 현실적인 프로젝트 관리를 하려는 목적도 있으나, 2주 단위로 진행되는 회고를 통해 유관부서 및 상부에서 내려오는 어젠다가 아닌 자체적으로 해야 할 일을 고민하고 계획을 수립하며 운영하는 주체적인 조직이 될 수 있도록 유도하기 위함입니다.  


아직은 이 모든 것이 새롭습니다. 다양한 도전들을 하고 있다고 해서 제가 그들과 소통할 수 있는 절대적인 전문성이나 권위가 더 생겼다고 생가하지도 않습니다. 제가 시도하려고 하는 방법들 중 많은 시도들이 벌써 실패하기도 했었고, 그냥 실패했다면 더 고민하고 더 나은 방향으로 이번에는 실패하지 않도록 도전하는 것뿐인 것 같습니다. 개발자는 개발에 집중할 수 있어야 한다고 생각하고, 저는 그 환경을 지원하고 응원하는 사람이라고 생각합니다. 그게 우리 개발팀원들과 저의 관계라고 생각하고, 언제까지나 그 관계여야 한다고 생각합니다. 

짧은 시간이지만 벌써 많은 것들을 이루어가고 있습니다. 신기하게도 말이죠. 제가 대단한 사람이라고 정말 솔직히 잠깐 착각한 적도 있었고, 덕분에 감당할 줄도 모르는 짐을 감당해보려 하다가 과로로 번아웃이 오기도 했었습니다. 그냥 끊임없이 반성하고 겸손해지는 사람이 되려고 합니다. 제가 그럴수록 저와 함께하는 팀원들이 지금보다 더 드러날 것 같고 더 인정받을 수 있을 것 같습니다. 많이 부족한 저와 함께해주고 채워주는 우리 팀원들과 함께하고 있어서 오늘도 매우 감사하고 즐겁게 일하고 있습니다. 




이번 포스팅은 마켓컬리에 관심이 있는 (잠재적) 동료들을 위한 글이기도 합니다. 물류 시스템 개발에 관심있는 자바 개발자, 커머스 서비스 개발에 관심이 있는 프론트엔드 & 백엔드 개발자, Legacy와 신규 플랫폼의 DB설계부터 운영최적화까지 담당해주실 DBA, 물류/사내/파트너사들을 위한 인프라 시스템 기획/설계 담당자등 저희의 비전, 방향성, 그리고 도전에 마음이 맞으시는 분들이 많이 봐주시고 관심가져주시고 연락주셨으면 좋겠습니다. 각 채용중인 포지션에 대한 상세한 소개 및 안내는 공식 채용 채널등을 통해 조만간 오픈하겠으나, 관심있으신 분들은 제 프로필에 있는 이메일주소로 연락 주시면 제가 최대한 안내 드릴 수 있도록 하겠습니다 :) 




Updated 2019. 05. 07


이 글을 쓴지 6개월이 지난 2018년 9월 개발총괄(Head of Engineering) 리더분을 모시게 되었습니다. 어찌보면 제가 마켓컬리 개발자분들의 경험을 고민하며 당시 가장 필요했던 솔루션이 기술 전문성과 관리역량을 두루 겸비하신 개발총괄님을 모셔오는것이라고 생각하여 그렇게 열심히 좋은분을 찾아다녔던것 같기도 합니다. 지금은 이 포스팅을 처음쓰던 지점과는 비교도 안되도록 멋진 조직이 되어있는 개발조직에 혹시나 당시에 제가 썻던 이 포스팅이 누가되지는 않을까 살짝 걱정스러운 마음에 첨언을 붙여봅니다  :) 

매거진의 이전글 마켓컬리 프로덕트(UX) 팀이 일하는 방식

작품 선택

키워드 선택 0 / 3 0

댓글여부

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