우리는 Experience 개발팀입니다 — 2편 (우리가 되고자 하는 것)

류종민
How we build MyRealTrip
10 min readNov 9, 2020
우리 팀을 소개합니다

이전 글 : 우리는 Experience 개발팀입니다 — 1편 (우리가 해야만 하는 것)

안녕하세요. 저는 마이리얼트립에서 2년 반 넘게 개발팀을 리딩하고 있고, 현재는 Experience 개발팀을 맡고 있습니다. 지난 편에서는 우리 팀이 조직에서 어떤 역할을 해야 하는 지에 대한 내용이었습니다. 이번 편에서는 우리가 그리고 있는 팀의 모습은 어떤 것인가에 대해 얘기해보고자 합니다.
아래부터는 전 편과 동일하게 저의 생각을 가감 없이 잘 전달할 수 있도록 평어체로 쓰도록 하겠습니다. 양해 부탁드립니다.

우리가 되고자 하는 것

처음에 우리가 되고자 하는 것을 고민했을 때, 우리를 특징짓고 상징할 수 있는 어떤 이미지가 있으면 좋겠다고 생각했다.

저 팀은 ❍ ❍ 해.
저 팀이랑 일하면 ❍ ❍ 해.

일단은 팀원들이 팀 안에서 일하는 것을 즐거워하기를 바랐다. 하지만 단순히 Fun 하나만을 말하고 싶지는 않았다. 그것만으로는 팀의 성과를 끌어낼 수 없다. 동료와 함께 하는 것이 재밌을 뿐만 아니라 신나고 흥미진진해야 한다. 우리가 스스로 그럴 수 있다면, 협업하는 다른 팀도 우리와 그렇게 일할 수 있지 않을까?
그래서 떠오른 단어가 바로 Exciting이었다. (Experience와 라임도 맞고~😆)

이러자는 얘기는 아닙니다 😅

그런데 “우리는 Exciting 해!” 라고 자신 있게 말하기 위해서는 조금은 더 구체적인 것이 필요했다. 그래서 우리 팀을 Exciting하게 만들기 위한 4가지 실천방안을 만들었다.

1. 해결책에 앞서 문제에 집중

앞에서 언급한 대로 우리의 일은 고객이 겪고 있는 문제를 해결하는 것이다. 그래서 누군가는 문제를 들고 온다. 하지만 꼭 문제만 오는 것은 아니다. “이런 문제가 있으니, 이렇게 해주세요.” 라고 해결책까지 같이 오는 경우가 종종 있다. 그런데 여기에 함정이 도사리고 있다. 문제와 함께 오는 해결책은 어쩌면 문제를 해결하는 것보다 더 많은 사이드 이펙트를 만들어내거나 심지어 실제로는 문제를 해결하지 못할 수도 있다. 그래서 해결책이 함께 오는 경우에는 한 번쯤은 비판적으로 바라볼 필요가 있다.

정말 이렇게 하면 문제를 해결할 수 있을까?

그리고 또 하나의 함정이 있다. 해결책과 문제, 둘 사이의 주객이 전도되어 버리는 것이다. 해결책의 난이도가 높을수록 그에 대한 고민이 깊어지는 나머지, 문제가 정확히 무엇인지 파악하기도 전에 어려운 해결책을 어떻게 달성할 수 있을지에 더 집중하게 된다. 그러다 보면 때때로 해결책을 달성하기 위해 생겨나는 문제들이 원래 해결하려고 했던 문제를 가려버리거나, 오히려 더 커지는 결과를 가져오기도 한다. (아마 다들 많이 경험하지 않았을까 싶다.)

너트를 풀려면 이 정도는 돼야지.. 음? 😳

꽤 많은 고민과 노력으로 해결책을 달성했는데 그게 실제로는 문제를 제대로 해결하지 못한다면, 조직 측면에서의 리소스 낭비는 물론이고 구성원들이 자괴감을 느끼게 될 가능성이 높다.

해결책보다 문제에만 집중하자는 얘기를 하려는 것이 아니다. 해결책에 당장 집중하기 전에 정말 문제를 해결할 수 있는 것인지, 정말 최선의 해결책인지 한번 생각해보자는 것이다. 개발자는 문제를 해결하고 나면 스스로 만족감을 얻기도 하지만, 문제를 겪고 있던 고객에게서 좋은 피드백을 받았을 때 보람과 만족감을 얻는다고 생각한다. 어렵게 개발했는데 고객에게서

이전보다 상황이 나아지지도 않았네요.
이건 생각했던 것보다 불편하네요.
왜 이런 식으로 됐는지 모르겠네요.

이런 반응을 얻게 된다면 개발자는 심한 좌절감과 분노에 휩싸이게 될 거다.그래서 문제를 제대로 해결하기 위해 문제를 잘 정의하고, 해결책의 실효성과 적절성을 의심해보는 습관은 결국 개발자 자신을 즐겁게 만드는 길이라고 생각한다.

이 실천방안은 마이리얼트립의 핵심가치 중에 고객 중심, 임팩트에 대한 집중과 연관되어 있다.

2. 더 나은 해결방안을 찾는 노력

이제 문제를 잘 정의해서 파악했고 적절한 해결방안을 정했다. 그런데 문제라는 것은 항상 돌고 돈다. 한 번 겪은 문제가 다른 조직, 다른 시간, 다른 상황에서 동일하게 발생하는 건 개발자로서 종종 겪게 되는 일이다. 그러면 한 번 해결했던 문제니까 예전에 선택했던 해결방안을 동일하게 적용하면 되겠다고 생각하고 그렇게 하게 된다. 한 번 해봤으니까 가장 쉽고 빠르다.

하나의 문제를 해결하기 위한 방법은 사실 꽤 다양하다. 그래서 우리는 그중에서 상황에 맞는 최선의 방안을 택하게 된다. 그런데 이 상황이란 게 당연하게도 그때그때 다르다. 기술의 발전은 빠르고 해마다 새로운 언어, 새로운 프레임워크, 새로운 기술들이 대두된다. 예전에는 최선이라고 생각했던 선택이 지금은 아닐 수 있다는 말이다. 개발자의 숙련도나 참여하는 인원 등 업무의 상황도 그때그때 다를 수 있다. 한 명의 개발자만 투입할 수밖에 없는 상황이라 어쩔 수 없이 리소스가 적게 드는 차선을 선택했다면, 다음에 리소스가 충분한 상황에서는 최선을 선택해 볼 수 있는 여지가 생긴다는 것이다.

우리가 문제를 해결하는 방법도 이렇게 발전해야 한다

이렇듯 문제를 해결해야 하는 시점의 상황이 매번 달라질 수 있기 때문에, 한 번 해결해봤던 문제라고 하더라도 그 당시 선택했던 해결방안이 지금도 최선인지를 항상 고민해봐야 한다. 항상 더 나은 것을 생각하고 시도할 때 우리도 개발자로서 한 단계 더 성장할 수 있다. 나의 성장은 자신도 기쁜 일이지만, 팀의 성장이고 기쁨이기도 하다.

이 실천방안은 마이리얼트립의 핵심가치 중에 고객 중심, 최고 수준 요구와 연관되어 있다.

3. 주도적이고 적극적인 협업

이건 당연한 거 아니냐고 얘기할지도 모르겠지만 생각보다 쉽지는 않다. 주도적이고 적극적이 되기위해서는 생각보다 훨씬 더 부지런해야 하고, 매번 찾아오는 귀차니즘을 이겨내야 한다. 사람은 본능적으로 편한 것을 추구하기 마련이다. 그래서 어렵다.

팀 내에서만 진행되는 업무도 많겠지만, 우리 팀의 경우 다른 팀과의 협업을 통해 진행되는 업무들이 많다. 따라서 팀 간에 유기적으로 잘 협업할수록 전반적으로 업무도 속도감 있게 진행된다. 그런데 생각보다 그렇지 못한 경우를 많이 보게 된다. 여러 직군이 함께 진행하는 하나의 프로젝트를 예로 들어보자.

내가 해야 하는 부분은 다하고 넘겼어요. 피드백을 기다리는 중이에요.

위와 같은 상황 자체는 크게 문제가 없다. 그런데 피드백을 기다리는 시간이 길어지고 있는데 아무도 그것에 대해서 챙기지 않는다면 문제가 된다. 길어지는 이유는 여러 가지가 있을 것이다. 요청을 받은 쪽이 다른 업무로 바빠서 Follow-up 하기 어려울 수도 있고, 심지어 요청을 전달받았는지조차 잊어버리고 있는 경우도 생길 수 있다. 그렇게 업무가 진행되지 않고 멈춰있는 상황에서 무작정 업무가 진행되길 기다리거나 PM과 같은 관리자가 알아서 챙겨주기를 기다릴 수는 없는 노릇이다. 그런 상황에서 나에게 그나마 여유가 좀 있다고 한다면, 왜 지연되고 있는지를 확인해 보고 내가 지연상황을 해결하기 위해 도울 일은 없는지 적극적으로 챙겨보는 자세가 필요하다.

답변 올 때까지 잠이나… 잘 순 없으니

협업의 과정에서 지연되는 상황들이 많아질수록 업무의 효율은 떨어지고 그에 따라 일정은 늘어지며 결국 구성원들의 의욕도 떨어져만 간다. 프로젝트 전체가 성공하지 못한다면 내가 맡은 부분만을 아무리 잘 해냈다 하더라도 그 결과를 인정받지 못하기 마련이다. 그렇기 때문에 프로젝트에 참여하는 구성원들은 단지 자신의 역할만을 잘 수행하는 것에 그칠 게 아니라 프로젝트가 성공할 수 있도록 모두가 주도적으로 함께 노력해야 한다.

이 실천방안은 마이리얼트립의 핵심가치 중에 프로페셔널, 빠른 실행력과 연관되어 있다.

4. 빠르고 즉각적인 피드백

개발자로서 다른 동료로부터 업무요청을 받거나 업무 관련 문의를 받게 되는 일은 빈번하다. 그리고 보통 그때는 이미 다른 업무를 진행하고 있는 경우가 많다. 그래서 요청이나 문의가 들어오면 바쁘다는 핑계로 못 본 척하거나 받아놓고 함흥차사인 경우가 있다. 이렇게 되면 업무를 요청한 동료의 입장에서는 업무의 흐름이 끊기기도 하고, 언제 답이 올지 알 수 없으니 다른 업무를 맘 편히 진행할 수도 없다. 물론 요청이 왔을 때 빠르게 답을 줄 수 있다면 가장 좋겠지만, 모든 업무 요청을 바로 대응하는 것도 현실적으로 어려울 수 있다. 그렇다면 적어도 요청하는 동료가 무작정 기다리지 않도록 언제쯤 답변이 가능할지라도 빠르게 알려줘야 하지 않을까? 그러면 요청을 한 동료 입장에서는 일단 약속한 시각까지는 마음 편히 다른 일에 신경을 더 쓸 수 있다.

피드백이 빠를수록 조직의 속도는 올라간다

요청에 대한 반응이 빠르고 즉각적일수록 조직 전체적인 타임로스를 줄이면서 자원을 효율적으로 활용할 수 있고, 조직의 전반적인 업무 퍼포먼스도 올라간다. 우리가 이렇게 서로의 처지를 생각하고 이해하면서 요청에 대한 반응을 신경 쓴다면, 의미 없이 기다리는 시간들이 줄어들고 각자 업무에 좀 더 집중할 수 있으니, 일하는 게 좀 더 신바람 나지 않을까?

이 실천방안 역시 마이리얼트립의 핵심가치 중에 프로페셔널, 빠른 실행력과 연관되어 있다.

정리해보자

이제 앞에서 했던 모든 얘기를 종합해보자. 새로이 팀에 합류하려는 분이, 아니면 팀 외부의 누군가가 나에게 Experience 개발팀은 어떤 팀이냐고 물어본다면, 나는 아래와 같이 답할 수 있을거다.

Experience 개발팀은 내부의 고객이 겪고 있는 문제를 자동화와 기능화를 통해 기술로써 해결하는 것을 목표로 삼고 있습니다. 그 과정에서

해결책에 앞서 문제에 집중하고,
더 나은 해결방안을 찾기 위해 노력하며,
협업은 주도적이고 적극적으로 하고,
피드백은 빠르고 즉각적으로 함으로써

누구나 Exciting 하다고 느낄 수 있는 조직을 추구하고 있습니다.

그래서 현재의 Experience 개발팀은?

Experience 개발팀 위키 대문
Experience 개발팀 위키 대문

사실 팀의 철학이나 일하는 방식을 정하는 것 자체는 생각보다 어려운 일은 아니다. 하지만 꾸준한 실천이 뒷받침되지 않으면 아무리 멋있고 좋은 문구라도 그 의미를 잃어버린다. 그렇기 때문에 우리가 그리고 있는 팀의 모습에 맞게 업무를 대하는지를 자꾸 들여다보고 돌아본다.

이제 어느덧 2020년의 마지막 분기를 내달리고 있다. 과연 그동안..

우리는 자동화와 기능화를 통해 고객의 문제를 해결하기 위해 얼마나 노력했는가?
우리는 우리의 바람대로 자신을 Exciting 하다고 느끼는가?
외부에서는 우리를 Exciting 하다고 느끼고 있는가?

사실… 아직은 꽤 부족하다고 느낀다. 그리고 또 한편으로는 궁금하다. 우리는 우리가 생각하는 모습에 과연 얼마큼 가까워지고 있는가?
한 가지 확실한 건, 적어도 나에게는 우리 팀이 그렇게 나아가고 있다는 확신이 있고 그래서 우리 팀에 자부심을 느낀다는 것이다.

함께할 동료를 찾습니다

어찌 보면 이 글을 쓰게 된 이유

다시 경어체로 돌아와서.. 이렇게 두 편에 걸쳐 장황하게 팀에 대한 얘기를 한 이유는 여러 가지가 있겠지만 역시나, 팀에 함께할 좋은 분을 모시기 위함입니다. 😅
우리 팀은 개발팀으로서 기술에 대한 관심뿐만 아니라, 문제를 해결하기 위해 동료와 잘 협업하는 방법에 대해서도 관심이 많습니다. Exciting한 개발조직을 만들어가고 있는 우리 팀과 함께하고 싶으시다면 채용 중인 포지션을 통해 지원해주세요! (https://career.myrealtrip.com/)

--

--