우리는 Experience 개발팀입니다 — 1편 (우리가 해야만 하는 것)
안녕하세요. 저는 마이리얼트립에서 2년 반 넘게 개발팀을 리딩하고 있고, 현재는 Experience 개발팀을 맡고 있습니다. 팀장으로서 팀을 이끌면서 팀원의 성장과 팀의 성과를 온전히 끌어내기 위해 많이 고민하고 있습니다. 그런 고민을 통해 나온 현재 우리 팀이 가지고 있는 철학과 일하는 방식에 대한 얘기를 두 편에 걸쳐서 하려고 합니다.
(개발팀으로서의 고민에 대한 얘기지만, 기술에 대한 얘기는 아닙니다.)
아래부터는 저의 생각을 가감 없이 잘 전달할 수 있도록 평어체로 쓰도록 하겠습니다. 양해 부탁드립니다.
팀장이 되기까지
본론으로 들어가기 전에 간단하게 내 이야기를 하는 게 좋겠다.
나는 (어느덧 추억의 이름이 되어버렸지만) Daum 커뮤니케이션에서 2006년에 공채로 개발자 경력을 시작하여 합병 이후 카카오에 이르기까지 한 회사에서 꽤 오랜 기간 근무를 했었다. 그러다 지난 2018년 초에 처음 이직을 결심했고 마이리얼트립에 팀원으로서 합류하게 되었다. 입사 직후 (지금은 웃으며 이야기할 수 있는) 여러 우여곡절을 거치며 팀을 새롭게 빌딩하고 리딩하는 역할을 처음으로 맡게 되었고, 어느덧 3년 차 개발팀장으로서 재직하고 있다.
처음 팀장 역할을 맡았을 때는 팀의 철학과 방향성에 대해 고민하기보다 비즈니스가 급성장하는 시기에 부족한 인력을 빠르게 채용하는 것에 집중해야 했다. 지금은 좋은 분들이 많이 합류해서 그때 비하면 개발조직이 꽤 커졌다. 그에 따라 개발조직도 몇 번의 조직개편을 통해 역할별로 세분되었고, 그렇게 지금의 Experience 개발팀을 맡게 되었다. 이제는 정말 내가 생각하는 멋진 팀을 그려보고 만들기 위한 노력을 온전히 쏟을 수 있게 된 거다. (야호~!)
그래서 오늘은 멋진 팀이 되고자 노력하는 우리 팀에 대해 얘기를 하려고 한다.
Experience 개발팀
이름에서 느껴지듯 우리 팀은 여행을 통해 경험할 수 있는 다양한 투어와 액티비티 상품을 관리하고 사용자에게 잘 전달하는 역할을 맡고 있다. 하지만 아직은 거기에만 집중할 수 있는 환경은 아니고, 마이리얼트립 서비스의 근간을 이루고 있는 모놀리식 구조의 Ruby On Rails 기반 레거시 시스템 전반과 외부 공급사의 상품들을 마리트 내에서 유통하기 위한 Java/Kotlin 기반의 연동 시스템에 대한 오너십도 가지고 있다.
(물론 레거시가 갖고 있는 다양한 문제들을 근본적으로 개선하기 위해 Java 기반 MSA 구조의 신규 플랫폼 개발이 한창 진행 중이다.)
그래서 비교적 다양한 기술들을 통해 사내의 다양한 팀들과 협업하는 팀이면서, 동시에 업무적인 관점에서는 개발자로서 다소 지치기 쉬운 역할을 떠맡고 있는 팀이기도 하다.
팀의 방향성이 필요하다.
그렇지만 팀장으로서, 어려운 환경에 놓여있는 팀이지만 우리의 팀을 팀의 내부에서든 외부에서든 누구나가 함께 하고픈 팀으로 느껴지게 만들고 싶었다. 팀에 주어지는 업무가 무엇이든 간에 팀이 추구하는 철학과 일하는 방식이 올바르게 설정되어 있고 팀원 서로가 공감하고 있다면, 우리 자신도 즐겁게 일할 수 있고 우리와 협업하는 다른 팀도 우리와 함께하는 것을 즐겁다고 느낄 수 있을 거라 생각했다. 더불어 그러한 것들이 자연스레 팀의 성과를 끌어내는 밑거름이 되리라 생각했다.
우리 팀의 철학과 일하는 방식에 대해 얘기를 하기 전에 먼저 마이리얼트립이 추구하는 핵심가치를 먼저 소개해야 할 것 같다.
우리 회사의 비전은 아래와 같다.
여행을 위한 모든 경험을 연결함으로써 여행을 재발견하고 혁신하는 것이다.
그것을 이뤄내기 위해 회사가 추구하고 있는 핵심가치는 아래의 5가지다.
보통 전사의 비전과 미션, 핵심가치가 정해지면 그것을 기반으로 팀도 동일한 형태로 비전과 미션, 핵심가치를 정하는 게 일반적이지만 사실 이런 용어들이 직관적으로 와 닿지 않기도 하고, 형식에 얽매이다 보면 본질을 놓치게 될 것 같아서, 그냥 쉽게 풀어서 다음의 두 가지로 우리를 표현하고자 한다.
우리가 해야만 하는 것과 우리가 되고자 하는 것.
(그게 미션이고 비전이지 않으냐 한다면..😅)
우리가 해야만 하는 것
우리는 마이리얼트립에 속해 있는 개발팀 중 하나로서, 어떤 업무를 맡게 되든 궁극적으로는 무엇을 위해 노력해야 하는 걸까? 뭐 일단은 개발을 잘해야겠지. 그렇다면 개발을 잘한다는 게 무얼 의미하고 어떻게 하면 개발을 잘한다고 할 수 있을까?
개발자들이 쉽게 빠지기 쉬운 함정은 개발을 잘한다는 것이 좋은 코드를 만들어내는 것이라고만 생각하는 거다. 나도 그랬었다. 그런데 좋은 코드를 만들어내는 것은 우리가 달성하고자 하는 것의 올바른 수단이 될 수 있을지언정 궁극적인 목적은 될 수 없다는 것을 깨달았다. 모든 조직의 목적은 문제를 해결하는 것이다. 그리고 우리는 개발팀이기 때문에 다시 말하면, 문제를 기술로써 해결하는 것이다. 문제를 실제로 해결하지 못하는 코드는 아무리 아름답게 작성되어 있다 하더라도 우리의 목적을 달성하는 데 아무런 도움이 되지 못한다. (개발자로서 자기만족에는 도움이 될지 모르겠지만..) 그래서 우리가 생각하는 개발을 잘한다는 것은 문제를 기술을 통해 잘 해결해 나가는 것이라고 할 수 있겠다.
그럼 여기서 얘기하는 문제라는 건 뭘까? 요구사항 혹은 Needs로 표현되기도 하지만, 누군가가 겪고 있을 고통을 해소하는 것일 수도 있고, 누군가가 필요로 하지만 현재는 없는 무언가를 만들어내는 것일 수도 있다. 그리고 그 누군가는 우리 서비스를 사용하는 사용자일 수도 있고, 심지어 내 옆에 있는 우리 팀원일 수도 있다. 그 누군가에게 이름을 붙여야 얘기하기 편할 테니 앞으로는 고객이라고 하자.
정리해보면 우리 팀은 고객이 겪고 있는 문제를 기술로써 해결해야만 한다.
여기서 두 가지 의문이 생길 수 있다.
- 우리의 고객은 누구인가?
- 기술로써 해결한다는 게 어떤 의미인가?
1. 우리의 고객
사실 고객이라는 말을 들으면 마이리얼트립을 사용하고 있는 여행자나 가이드가 먼저 떠오른다. 그런데 백엔드 개발자의 입장에서 여행자나 가이드는 생각보다 꽤 멀게 느껴진다. 백엔드 개발자가 구현한 결과물은 UI/UX를 통해 제공되거나 다른 시스템과의 연동 등을 통해 간접적으로 여행자나 가이드에게 전달되기 때문이다.
관점을 약간 다르게 보자면, 여행자나 가이드의 문제를 실제로 직접 듣고 느끼면서 그에 대한 해결방안을 고민하는 것은 우리 말고도 이미 회사에서 하고 있는 분들이 있다. 바로 사업, 운영, 디자인, PO 등의 조직에 있는 동료들이다. 이러한 동료들을 통해 사용자의 문제가 구체화되고 우선순위에 맞게 정리되면, 그에 대한 해결방안을 함께 고민하고 개발을 통해 문제를 해결해 나간다. 그렇다면 이런 동료들도 우리 팀의 입장에서 보면 외부의 고객들이 겪고 있는 문제들을 해결하기 위해 발생하는 또 다른 문제를 겪고 있는 고객이라 할 수 있겠다. (적고 나서 보니 왠지 말장난처럼 느껴지는데..😅)
이제 우리 팀의 관점에서 고객을 아래의 두 부류로 나눠보자.
- 외부의 고객 : 마이리얼트립을 실제로 사용하는 여행자와 가이드
- 내부의 고객 : 외부 고객의 문제를 해결하기 위해 노력하는 동료들
이렇게 나눠보니 ‘우리가 주로 관심을 가져야 하는 고객은 바로 우리와 직접적으로 대면하게 되는 내부의 고객이지 않을까?’ 하는 생각에 이르렀다. 외부 고객의 문제를 해결하기 위해 이미 동료(내부의 고객)들이 충분히 노력하고 있으니, 우리는 동료들의 문제에 좀 더 집중하고 노력함으로써 궁극적으로는 외부의 고객이 겪고 있는 문제를 해결하게 되지 않을까?
2. 기술로써 해결한다는 것
이건 사실 쉽게 답이 나온다. 사람이 하는 걸 시스템 혹은 서비스가 하게 만들면 된다. 그런데 우리는 이것을 좀 더 분명하게 이해하고 행동하기 위해 두 가지로 정의했다.
바로 자동화와 기능화다.
자동화는 말 그대로 고객이 겪고 있는 문제를 시스템이 해결해준다. (고객과 개발자 모두가 Happy~😄) 궁극적으로는 이 자동화까지 이뤄내기 위해 노력해야 한다. 하지만 언제나 그렇듯 상황은 우리가 생각하는 대로만 흘러가지 않는다. 때에 따라 자동화를 달성하기 위해 꽤 많은 리소스가 필요하다거나, 정책 혹은 사업적 결정이 뒷받침되어야만 자동화로 나아갈 수 있는 등 여러 난관에 부딪히게 된다. 그럴 때에는 어쩔 수 없이 차선을 고려해야 하는데 그것이 바로 기능화다.
기능화는 고객이 겪고 있는 문제를 고객이 직접 해결할 수 있도록 기능을 제공하는 것이다. 개발자로서 일을 하다 보면 흔하게 겪게 되는 상황이 있다.
이번 달 데이터 좀 뽑아주세요.
DB에 이 값 좀 수정해주세요.
가장 쉽게는 그때그때 개발자가 쿼리를 돌려서 처리하는 것일 텐데, 그게 반복되다 보면 개발자 자신도 귀찮아지니 자주 사용하는 쿼리들을 어딘가에 모아두거나 전용 스크립트를 하나 작성해두고 요청이 들어오면 실행해서 처리하곤 한다. 하지만 여기까지는 결국 문제해결을 위해 개발자가 무언가를 해야 한다. 그래서 동료들이 우리에게 요청하는 절차가 필요하고, 우리가 답을 줄 때까지 동료는 기다려야 한다. (담당 개발자가 휴가를 가버렸다거나, 길어지는 회의에 참석 중이라면⁉️) 이렇게 업무를 처리하기 위한 의존성이 생긴다면 조직 측면에서도 결국 병목이 되어 비효율이 발생하게 되고 기민하게 문제를 해결하지 못하게 된다. 이런 상황을 막으려면 결국 요청자 본인이 개발자의 도움 없이 직접 문제를 해결할 수 있도록 기능을 제공해야 한다. 예를 들면 반복적으로 들어오는 요청을 요청자가 직접 해결할 수 있도록 백오피스 기능을 구현하여 제공한다든지 말이다.
우리가 해야만 하는 것
정리해보면 우리 팀이 해야만 하는 것은 내부의 고객이 겪고 있는 문제를 시스템이 알아서 해결할 수 있게 하거나, 우리의 도움 없이 고객이 직접 해결할 수 있는 기능을 제공하는 것이라 할 수 있겠다.
다음 편에서는
앞에서 얘기한 우리가 해야만 하는 것은 어떻게 보면 정량적인 부분이다. 우리가 얼마나 잘하고 있는지를 비교적 쉽게 측정하고 파악할 수 있다는 뜻이다. 다음 편에서는 다소 정성적인 부분인 우리가 되고자 하는 것에 대해 얘기하고자 한다.
