2020년 마이리얼트립 개발 조직의 변화와 성과 대한 회고-2편 : No.1 Travel Tech Leader를 향한 도전기
이전 글 : 2020년 개발 조직의 변화와 성과 대한 회고-1편 : 코로나 위기 극복기
1편에서는 마이리얼트립이 코로나 상황을 극복하는 이야기를 다루었다면, 2편에서는 코로나 이후 여행을 Reinvent 할 수 있는 최고의 트래블 테크 회사를 위한 마이리얼트립만 도전과 성과에 대해서 이야기 하겠습니다.
다시 채용을 시작하다.
마이리얼트립이 진정한 트래블 테크 회사로 가기에는 개발 조직의 인력이 많이 절대적으로 부족한 편이라 빠르게 좋은 인력들을 확충이 필요했습니다. 많은 회사들이 연봉 협상이 마무리되는 시점인 3월 저는 잠재적인 채용 후보자를 분들을 만나 설득하기 시작했고, 거의 매일 저녁 1~2명의 개발자분들을 만났으니, 정말 엄청난 열정과 노력을 쏟아부였습니다. 공교롭게도 이 시기에는 코로나가 국내 대유행을 시작한 시기였기 때문에 처음에는 냉담한 반응이 대부분이었습니다. 연일 뉴스에서는 코로나 국내 창궐에 대한 이야기밖에 없었고, 많은 여행사들의 어려운 소식들이 전파되는 시기이기도 했으니 후보자 분들의 심정이 충분히 이해가 갔습니다. 그래도 이런 노력 덕분이였는지? 아니면 지난 저의 경력에서 그렇게 나쁜 모습은 아니었는지? 3월부터 조금씩 회사에 관심이 있다는 개발자분들도 생기고, 이력서를 넣겠다는 분들도 많이 생기기 시작하였습니다. 한창 이력서를 많이 받을때는 하루에 9명의 좋은 개발자 이력서를 받기도 하였습니다. 지금에서야 이야기하지만, 이때 받은 이력서는 면접도 진행하지 못하였습니다. 회사의 자금 사정이 빠르게 경색되고 있어 채용보다는 회사의 미래를 걱정해야할 정도였습니다.
우리 경영진은 코로나 국내 창궐 이후 회사의 자금 흐름을 최대한 보수적으로 사용하면서, 국내여행으로의 빠른 전환을 결정하게 됩니다. 당연히 진행하고 있는 모든 채용도 중단되었고, 지금까지 쌓아올린 모든 채용의 노력도 같이 사라지게 되었습니다. 아쉬웠냐고요? 당연히 아쉬웠습니다. 그러나 아쉬워한다고 지금의 상황이 괜찮아지지 않기 때문에 우린 당장 할 수 있는 것에 집중하였습니다. 다행히 우리 조직의 개발자 수는 제가 입사를 결정할 때보다 2배 수준인 40여명까지 늘어나 있었습니다. 정말 네이버, 카카오, 쿠팡 등에서 뛰어난 개발자분들이 많이 합류한 상태였습니다.
우리 제품 조직은 국내 상품의 Selection을 확보하고, 국내여행 플랫폼으로의 전환에 집중했습니다. 그 후 우리는 코로나 한가운데에서 투자를 성공시켰고, 다시 공격적인 채용을 할 수 있는 기회를 8월부터 가지게 됩니다. 그러나 여전히 코로나가 진행 중인 상황에서 한번 무너진 채용 파이프라인은 생각보다 빠르게 복구되지 않았습니다. 채용팀과 저는 2020년 Q1에 했던 것처럼 저녁과 주말을 가리지 않고 좋은 분들을 만나려 다니기 시작했습니다. Q4에 채용 파이프라인은 조금씩 복구되기 시작하였고, 다행히 다양한 회사의 핵심 인재분들을 우리 회사로 모실수 있게 되었습니다.
이 글을 작성하며 다시 한번 우리 회사를 선택해 주신 구성원분들께 감사 인사 드립니다. 지금은 PO, 디자인, 개발, QA 직군을 모두 포함하면 창업 초기보다 4배 이상 성장한 제품 조직이 되었습니다. 2020년의 채용을 되돌아보면 조금 느리게 가더라도 최고의 인재를 뽑으려고 노력한 것 같습니다. 한 번도 조급함 때문에 우리 채용 Bar를 낮추거나 타협하지 않았습니다. 저는 최고의 엔지니어와 함께 좋은 서비스를 만들어가는 경험을 마이리얼트립에서 하고 싶습니다.
코로나 상황 속에서도 기술에 대한 투자를 지속하다.
코로나 여파가 언제 끝날지도 모르는 상황 속에서 다른 해외여행 회사들은 다 웅크리고 있는 가운데, 우리는 대규모 기술 투자를 지속적으로 단행하게 됩니다. 저는 시장이 축소된 지금이 우리 회사의 기술 DNA를 바꿀 수 있는 최적의 시기로 보았습니다. 우리 회사는 오프라인 여행에서 온라인 여행으로, 패키지여행에서 자유여행으로의 전환이라는 거대한 시장의 흐름에 올라탄 상황입니다. 코로나로 인하여 시장의 변화 속도가 느린 지금이 향후에 발생하는 폭발적 성장을 위한 준비 기간이라는 것을 누구도 말하지 않지만 이 업계에 있는 모든 사람들은 알고 있습니다.
1) 느려도 너무 느린 서비스 속도 개선
보통 처음 어떤 서비스를 사용할 때 받는 느낌이 ‘이 서비스 너무 좋은데, 재미있는데, 아니면 이 서비스 별로야’ 와 같이 서비스 본질에 집중해서 생각을 하게 됩니다. 그러나 제가 우리 회사의 서비스를 사용하면서 받은 첫 느낌은 ‘서비스가 좋다 or 나쁘다’ 라는 생각보다 ‘느려도 너무 느리다.’가 저의 첫인상이었습니다.(기술 조직의 장으로써 제가 하기엔 부끄러운 표현이네요..) 클룩, 트립닷컴과 같은 다른 경쟁사의 Time To Interactive (이하 TTI)가 1~2sec를 유지한다면 마이리얼트립의 TTI P50은 3~4sec 정도 되었고, TTI P90은 8~15sec 정도 되었습니다. 경쟁사보다 최소 2배, 최대 6~10배 느린 상황이었습니다. 일반적으로 느린 서비스는 충성 고객을 만들기 어렵게 하고 설령 만들었다 하더라도 심각한 고객 이탈율을 유발합니다. — 관련 기사 비단 이 문제가 아니더라도 하나의 feature를 개발하는데 수십에서 수백 번의 테스트를 거치게 되는데 이 정도의 TTI라면 모든 개발자의 생산성을 심각하게 저해하는 요소 중 하나라고 생각했습니다. 우리는 이를 개선하기 위하여 ‘1초 프로젝트’를 시작하게 됩니다. ‘이 1초가 공격적인 목표가 맞아?’ 라고 생각할 수 있을지 모르겠지만, 그 당시 우리에게는 고객이 불편을 느끼는 않는 최소한의 목표였고, 이 프로젝트가 국내 플랫폼 전환과 병렬로 진행이 되었기 때문에 굉장히 제한된 일정 내에, 제한된 리소스로 완료해야 하는 도전적인 프로젝트였습니다.
이때 우리가 다양한 분석을 통해 얻은 Action Item은 다음과 같았습니다.
- Slow Query 제거
- N+1 Query 문제 제거
- 캐쉬 정책 변경
- 미국, 일본, 한국에 흩어진 서비스들을 AWS Seoul Region으로 통합
우리 회사의 AWS Seoul Region이 생기기 전 2012년부터 서비스를 시작한 회사이기 때문에 대부분의 메인 서비스들은 일본에 기반을 두고 있는 Heroku라는 곳에서 운영되고 있습니다. 또한 Heroku에서 제공하지 않는 MongoDB와 RabbitMQ 같은 서비스들은 미국에 기반을 둔 compose.io에서 사용하고 있습니다. 이렇다 보니, 하나의 페이지를 완성하기 위해서는 미국, 일본, 한국의 서버들이 서로 수십 번 통신을 해야하기 때문에 latency가 느려질 수밖에 없는 구조를 가지고 있었습니다. 이런 문제가 Slow Query와 N+1 Query 문제를 더욱 가중시키고 있었습니다.
우리는 원인과 해결책도 모두 찾은 상태이고, 이미 이러한 문제를 많이 풀어본 좋은 엔지니어도 많아서 처음에는 기술적 난이도가 그헣게 높지 않다고 생각했습니다. 그러나 의외의 곳에서 기술적 난관에 봉착하게 됩니다. Heroku에 있는 DB는 외부에서 데이터를 가지고 올 수는 있어도, 외부로 데이터를 전달하는 것을 차단하고 있었습니다, Heroku DB 데이터를 AWS Seoul Region으로 옮기기 위해, 우리에게 허락된 방법은 Dump & Restore 밖에 없었습니다. 즉 서비스 중단없이(Replication, etc을 통한 데이타 동기화) 데이터를 가지고 올 수 있는 방안이 없었습니다. Heroku에 있는 Main DB의 용량도 엄청 나기 때문에 데이터 이관 작업에만 8시간이 필요하였고, 다른 작업까지 고려한다면 12시간 정도 필요하였습니다. 여러 방안을 고민하다가 네트워크/디스크 대역폭의 한계까지 끌어올려서 Dump & Restore를 시도하게 됩니다. 이를 통해 우리는 8시간 걸리는 것을 1시간30분 만에 완료할 수 있는 방안을 찾아내게 됩니다. 이 정도라면 서비스 중단의 영향을 최소화하고 시도해볼만 하였습니다. 결국 우리는 5월 18일 새벽에 AWS Seoul Region으로 모든 서비스들의 이관하게 됩니다. 이러한 작업으로 인하여 TTI P50이 1~2sec, TTI P90이 4sec 로 기존보다 3~4배의 속도 개선을 만들어 내었습니다. 현재는 모든 페이지에 대한 TTI가 모니터링 되고 있으며, 이를 통해 지속적으로 속도를 개선하고 있습니다.
2. 차세대 플랫폼
우리가 차세대 플랫폼을 개발하려는 이유는 크게 다음과 같은 3가지 Pain Point를 해결하고자 함이었습니다.
첫째, 우리는 2012년 가이드 상품을 시작으로 다른 버티컬로 확장하여 성장해 왔습니다. 그러다 보니, 가이드 상품 DB를 계속 확장하는 형태로 서비스가 만들어졌고, 이 때문에 투어나 숙박을 구매하려는 고객에게 최적의 상품 탐색/구매 경험을 제공하는데 어려움이 있었습니다.
둘째, 한국에서는 숙련된 Java 개발자의 규모가 Ruby 보다 몇 배나 풍부한 시장구조를 가지고 있는데, 우리의 서비스는 Ruby on Rails라는 프레임워크로 개발되어 뛰어난 개발자를 확충하는데 많은 어려움을 겪고 있었습니다. 마이리얼트립이 대규모의 우수한 인력을 채용하기 위해서는 이런 프레임워크의 전환이 필수라고 판단하였습니다.
셋째, 우리의 시스템은 monolithic 아키텍처로 구성되어 있어 서비스의 확장성, 신뢰성 그리고 다수의 개발자와 협업 관점에서도 매우 취약한 구조로 되어 있었습니다. 이를 개선하기 위하여 micro-service architecture로의 전환이 시급하였습니다. 또한 모든 서비스를 한 번에 Java/Kotlin으로 전환시키거나, 모든 상품 DB를 한 번에 변경하는 것은 매우 리스크가 큰 작업이라서 작은 도메인 단위로 분할하여 진행하는 것이 올바른 전략이라고 생각하였습니다.
(Ruby와 Monolithic Architecture가 나쁘다는 것은 아닙니다. 각 서비스의 성장 단계에 최적의 솔루션이 있다고 생각할 뿐이지, 절대적 옮음, 나쁨은 문제는 아니라고 생각합니다. 서비스 초기에 고객과의 빠른 호흡에는 Ruby와 Monolithic Architecture는 최선의 선택 중 하나라고 생각합니다. Monolithic의 문제점은 제가 작성한 이 블로그를 보시면 됩니다.
지금 회사가 겪고 있는 이 3가지 Pain Point는 코로나가 끝나서 보복적 성장을 할 때, 우리의 성장을 방해하는 가장 큰 bottleneck이라고 생각하였습니다. 저는 성장하는 서비스는 멈추지 않는 차와 같고, 서비스의 큰 변경은 달리는 차에서 바퀴를 갈아끼우는 것과 같다고 생각합니다. 코로나로 인하여 차가 조금이라도 느리게 가는 지금이 우리가 바퀴를 갈 최적의 시점이라고 판단하였습니다.
많은 어려움이 있었지만, 우리는 11월 17일 민박 도메인을 차세대 플랫폼으로 전환하게 됩니다. 이를 통해 고객에게 최적의 상품 탐색/구매 경험을 제공하게 되었고, 서비스 변화 속도도 기존보다 수배는 빠르게 변화하게 됩니다. 우리는 이런 성공의 경험을 바탕으로 투어, 티켓, 교통 등 남아 있는 다른 도메인까지 모두 차세대 플랫폼으로 전환을 진행하거나 계획 중에 있습니다.
3. 로그 플랫폼
고객은 어떤 어려움을 가지고 있는지? 어떻게 행동을 하는지? 그리고 우리 서비스가 고객에게 어떤 임팩트(GMV, Conversion Rate, etc)를 미치고 있는지? 판단을 하려면 어떻게 해야 할까요? 가장 쉬운 방법은 고객을 직접 만나보는 것입니다. 그러나 이 방법은 만날 수 있는 고객에 대한 제약이 존재하고, 고객의 전반적인 경향성을 파악하는 것에는 어려움이 있습니다. 이를 해결하기 위한 가장 일반적인 방법은 모니터링입니다. 우리 회사는 2020년 이전부터 데이터의 중요성을 알고, 이런 데이타를 서비스 개발에 잘 사용해 왔습니다. 특히 서버 및 DB 데이터와 같은 정형화된 데이터는 여느 스타트업에 비해서도 매우 높은 수준으로 잘 활용하고 있었습니다. 그러나 고객을 이해하는데 가장 중요한 사용자 행위와 관련된 로그 데이터가 부족하였습니다. 또한 데이터의 수집부터 활용까지 1~2일 정도의 시간이 소요되는 문제가 있었습니다. 우리는 이런 문제점을 해결하기 위해서 로그 플랫폼을 직접 구축하기로 결정하였습니다.
사용자 행위 기반 로그로 인하여 파악할 수 있는 정보
- 한 화면보다 긴 화면이 있다면, 고객은 어디까지 스크롤 하여 내려왔는지? 스크롤로 인하여 고객에게 노출된 상품은 무엇인지?
- 모바일에서 가로로 나열된 상품이 있을 경우, 고객은 어디까지 스와이프를 하였는지? 스와이프로 인하여 고객에게 노출된 상품 무엇인지?
- 노출 상품 된 상품들 중에서 고객은 어떤 상품을 탭/클릭 하였는지?
일반적으로 로그 플랫폼을 구축하고, 유지한다는 것은 기존보다 20~30% 정도의 개발 비용을 더 지불하는 것이기 때문에 우리 회사 규모의 스타트업이 쉽게 할 수 있는 결정은 아닙니다. 그러나 단 한 번의 타석을 서더라도 파울과 볼을 비중을 줄이고, 홈런을 칠 수 있는 확률(고객 이해)을 높이기 위해서는 로그 플랫폼, A/B 테스트와 같은 시스템이 정말 중요하다고 생각합니다. 2020년 말, 마이리얼트립은 표준 로그 사전, 표준 로그 포맷, 서버/클라이언트의 대규모 로그를 비동기 방식으로 받을 수 있는 플랫폼, 웹에서 쉽게 로그를 기록하고, 발송하는 SDK까지 구축을 완료하게 됩니다. 우리는 높은 수준의 고객 이해도를 바탕으로 고객이 겪는 문제를 빠르고, 올바르게 해결할 수 있는 방안을 마련하였습니다. 앞으로는 우리의 로그 플랫폼에 기반한 A/B 테스트 시스템까지 확장하려는 계획을 가지고 있습니다.
4. ISMS-P 인증
ISMS-P : 한국 인터넷진흥원(KISA)이 주관하는 보안 인증심사로, 고객 정보보호 및 개인 정보보호를 위한 일련의 조치와 활동이 국가공인 인증기준에 적합함을 증명하는 제도입니다. 해당 인증을 획득하기 위해서는 정보보호 관리체계 80개 기준과 개인 정보보호 관리체계 22개 기준에 대한 적합성 평가를 모두 통과해야 하는 높은 수준의 인증 심사입니다.
마이리얼트립은 2019년도의 매출이 100억이 넘어가면서 ISMS 인증심사의 의무 대상이 되었습니다. 그러나 코로나19로 국내 여행 플랫폼으로서의 전환이 너무나 시급한 문제였기 때문에 한동안 진행을 하지 못하고 있다가, 인증심사 만료를 단 3개월 남겨둔 시점에 본격적인 ISMS-P 인증심사를 준비하게 됩니다. 하지만 창립 이래 처음 진행하는 보안 인증심사라서 인프라, 데이타베이스, 서비스, 개인 정보 관리 등 다양한 분야에서 ISMS-P의 인증기준을 충족하기 위하여 보안 기준을 수립하고, 이 기준에 맞추어 서비스를 수정하거나 새롭게 만들어야 했습니다. 우리는 3개월간의 전력 질주 끝에 여행 업계 최초로 정부가 공식 인증하는 정보보호 및 개인 정보보호 관리체계 (ISMS-P) 인증을 획득을 하게 됩니다. 고객의 정보가 마이리얼트립 플랫폼 안에서 안정하게 저장되고, 사용되게 함으로써 고객의 신뢰를 유지할 수 있는 기반을 만들었다고 생각합니다.
마이리얼트립이 만들고자 하는 기술 문화
기술 위원회 : 마이리얼트립의 기술 표준은 누가 정하나요?
제가 다닌 많은 회사에서는 전사 공통된 표준 기술이 없거나, 있어도 일부의 팀 또는 실 단위의 표준 기술만 존재하는 경우가 많았습니다. 이런 경우 각 조직에서 필요로 하는 플랫폼을 각자 만들기 때문에 많은 리소스가 중복적으로 낭비됩니다. 이와 반대로 일부 회사의 경우는 전사의 표준 기술을 매우 중요시하기 때문에 이를 책임지는 플랫폼 조직 또는 DevOps 조직을 만들어 운영하는 경우도 있었습니다. 그러나 소수의 집단이 회사 전체의 기술 표준을 리딩하는 경우는 효율의 극대화 측면에서 유리한 점도 있지만, 소수의 집단이 서비스와 기술의 변화를 빠르게 따라잡을 수 없을 때는 전사의 병목 지점이 됩니다. 그리고 기술의 다양성과 변화의 속도를 따라잡을 수 없는 표준 기술들은 구성원분들에게 공감과 신뢰를 잃게 되는 악순환에 빠지게 됩니다.
그럼 이렇게 중요한 전사의 기술 표준들은 누가 정하고, 어떻게 운영하는 것이 가장 좋은 방법일까요? 저는 ‘자비로운 종신독재자’로 불리는 리누스 토발즈가 리눅스 커널을 관리하는 형태에서 이 문제의 실마리를 찾았습니다. (표현이 좀 어렵네요) 누구나 현재의 기술 표준에 문제가 있다면 오픈소스처럼 자유롭게 참여하여 개선할 수 있습니다. 심지어 기존의 기술표준을 거부하고, 새롭게 만들게 만들수도 있습니다. 그러나 전사 표준으로써 동작할 수 있는 특정 분야의 표준 기술은 다수의 지지를 받은 단 하나(또는 소수)의 기술입니다. 이 모든 것을 논의하고, 결정하는 곳이 “기술 위원회”입니다. 우리는 누구나 참여할 수 있는 기술 위원회를 통하여 이슈를 제기하고, 다 함께 고민하여 표준을 만들어 나갑니다. 또한 우리가 만들고자 하는 시스템의 아키텍처에 대하여 같이 논의하고, 더 나은 아키텍처를 같이 논의합니다. 이를 통해 자발적인 참여를 만들어내고, 집단지성으로 조직의 기술이 변화의 속도를 맞추어 지속적으로 나아갈수 있도록 하였습니다.
장애에 대처하는 우리들의 자세 : 우리는 장애를 어떻게 다루는가?
우선 제가 바라보는 장애의 관점에 대해서 먼저 이야기를 하도록 하겠습니다. 모든 회사, 모든 서비스는 크고 작은 장애를 경험하고 있습니다. 특히 빠르게 성장하는 서비스에서는 장애의 빈도가 매우 높게 나타납니다. 반대로 성장의 멈춘 서비스는 장애가 거의 발생하지 않습니다. 또한 열심히 개발하는 사람은 더 많은 장애를 만들어내고, 개발을 거의 하지 않는 사람은 장애를 만들어낼 기회도 얻지 못합니다. 이런 관점에서 장애를 바라본다면 우리가 나쁘게만 생각하는 장애가 그렇게 나쁜 것이 아닙니다. 또한 장애는 개인의 실수라기보다는 조직의 문화 또는 시스템의 부재로 보는 것이 더 올바르다고 생각합니다. 그러나 많은 회사들이 장애를 개인의 꼼꼼하지 못한 실수, 더 나아가 사회악으로 보는 경향이 있습니다. (그렇다고 제가 장애를 좋아하는 것은 아닙니다. ^^”) 실제로 제가 경험한 A사에서는 장애가 발생하면 그 장애를 유발한 사람에게 경위서를 작성하게 하는 경우도 간혹 있었습니다. 이건 정말 탁상행정이고, 소탐대실이라고 생각하였습니다. 이런 회사에서 누가 열심히 일을 하려고 할까요? 저는 장애를 바라보는 우리 사회와 조직의 문화를 바꾸고 싶었습니다.
많은 회사들이 더 좋은 서비스를 만들기 위해서, 고객 인터뷰를 하고, 고객센터로 들어오는 VOC를 청취하고, 앱 리뷰 검토합니다, 장애도 이와 다르지 않습니다. 장애는 시스템이 우리에게 서비스의 개선 포인트를 알려주는 중요한 신호입니다. 이를 무심코 지나치지 않고, “어떤 이유로 발생하였는지?, 똑같은 장애의 재발을 막기 위해서 우리가 어떤 대비책을 준비하고 실행해야 하는지?”를 검토하는 것이 정말 중요하다고 생각합니다. 우리는 장애를 통해서, 장애의 재발을 방지하기 위해서 세계 최고의 기술을 탐닉하고, 추구하고자 합니다.
이 외에도 카카오 싱크를 통한 회원 전환율을 97%까지 끌어올린 프로젝트, 상품 상세에서 구매전환율을 대폭 향상시킨 프로젝트 등 크고 작은 다양한 성공을 통해 우리가 멈추지 않는 성장을 지속하고 있다고 생각합니다.
어려운 환경에서 최선을 다한 우리 제품 조직의 구성원 여러분, 그리고 좋은 제품을 만들기 위해 같이 노력한 사업/운영의 구성원분들이 너무나 자랑스럽습니다. 여러분들이 있기에 우리의 미래가 더욱 기대됩니다.
그리고 마이리얼트립에서 여행의 미래를 만들어 가는 도전에 함께 할 예비 마리터 분들을 기다리고 있습니다. 마이리얼트립 채용에 관심이 있으시다면 마이리얼트립 채용 페이지를 확인해 주세요. 감사합니다!
