우아한 형제들, 베트남 프로덕트 팀 3개월 회고

11 min readApr 12, 2019

이 페이스북 글 이후, 네이버 랩스를 거쳐 현재 우아한 형제들 베트남 프로덕트 팀에 존재하고 있다. 3개월 수습 기간이 지난 기념으로 또다시 회고 글을 쓰려고 보니, 그래 나는 프로 수습러다. 어쨌든, 베트남 호찌민(사이공)이라는 곳에서의 면 수습은 처음이니 즐거운 마음으로 회고 글을 작성해본다.

Why?

지인들은 알겠지만 우아한 형제들에 입사하기 전, 나는 약 5개월 동안 자발적 백수였다. 아무것도 하지 않고 살아보며 마음이 가는 대로 이것저것 해보다가 개발자가 아닌 삶도 고려해 보겠다는 생각으로 시작한 자발적 백수 생활이었다. 그리고 난 여전히 개발자로 살고 있다.

그렇다면 다시 선택한 개발자의 삶을 왜 우아한 형제들과 함께했을까?

1. 함께 일해보고 싶었던 동료

나에게 우아한 형제들 베트남에서의 일을 처음 제안한 사람은 Joy다. Joy는 현재 팀의 리더이자 예전부터 개발자/스타트업 행사에서 함께 스피커로 섰던 사람이다. 함께 일해본 적은 없지만, 그 사람의 생각과 이야기를 전달하는 방식에 있어서 참 닮고 싶다는 생각을 많이 했었다.

Joy는 본인을 개발자가 아닌 ‘프로덕트를 만드는 사람’으로 정의한다. 그리고 프로덕트를 만들기 위한 사람, 프로세스, 의사결정 방법 등을 많이 고민하고 행동하는 사람이라 생각했다. 내가 언젠가 다시 리더라는 역할을 맡게 된다면 이런 사람이었으면 좋겠다는 생각을 했다. 그리고 기회가 된다면 함께 일해보고 내 생각이 맞는지 확인해보고 싶었으며, 우리는 현재 같은 팀에서 프로덕트를 만들고 있다.

2. 해외 근무환경

2019년 1월 2일이 나의 입사일이다. 입사일에 나는 잠실에 있는 본사로 출근하지 않고 호찌민 행 비행기를 타러 인천국제공항에 갔다. 그렇게 낯선 타지에서 입사일을 맞이했다.

아주 예전부터 우리나라가 아닌 다른 나라, 다른 환경에서 일해보고 싶다는 막연한 희망이 있었다. 낯선 환경에서 어떻게든 살아내는 내 모습을 보고싶은 마음이 있었던 것 같다. 그와 동시에 불안한 내 정신이 너무 급격한 변화를 감당하기 버거워하지 않을까 걱정도 했다. 다행히도, 낯선 타지이지만 어느정도 신뢰가 있는 지인이 꾸리는 팀에 속한다는 사실에 좋은 시작이라는 생각이 들었고 함께하게 되었다.

3. 권한과 책임이 주어지는 환경

규모가 있는 회사를 갈 때마다 나의 가장 큰 우려는 결정된 일만 잘 수행하면 되는 환경이다. 우아한 형제들 역시 동일한우려를 했었지만 적어도 베트남 프로덕트팀은 그렇지 않을거라는 기대가 있었다.

빠르게 프로덕트를 빌드하고 시장의 반응을 확인해야 하는 환경이다. 그러기에는 철저하게 리소스가 부족한 상황이었고, 오히려 이 상황이 나에게는 반가웠다. 프로덕트를 만들기 위해 서로가 각자의 역할을 구분 짓지 않고, 일이 되게끔 하는 일을 찾아서 해야 하는 환경이기 때문이다. 스스로 일을 찾고 행동하기 위해서는 권한과 책임이 동시에 주어지는 환경이어야 가능하며, 그 속에서 개인은 성장한다고 믿는 사람이다. 당시, 현재 팀은 그럴 수 있는 곳이라고 판단했다.

물론, 처음 결정 시에는 리더들과의 대화를 통해서만 판단해야 했기에 리스크도 존재했지만 적어도 3개월이 지난 지금 그 판단은 틀리지 않았다고 생각한다.

What?

그럼, 3개월이 지난 이 시간 동안 나는 이곳에서 무엇을 해왔을까? 어떤 결과를 내고 성장을 하고 있을까?

쿠폰 시스템 구축 — 3rd party 서비스 분석

첫 출근을 하고 내가 맡은 주 업무는 쿠폰 시스템 구축이었다. 쿠폰 시스템 구축의 복잡도는 이전 경험을 통해 알고 있었기에 살짝 불안감이 엄습했다. 하지만, 순수하게 인하우스로 개발하는 것이 아닌 3rd party 서비스를 이용하기로 결정했고 integration에 필요한 분석/설계/구축 그리고 마케팅팀과의 협업 등을 진행했다.

3rd party가 필요한 이유: 서비스 오픈 일자는 정해져 있었고, 프로모션은 반드시 오픈 시 포함되어야 하는 기능이며, 인적 리소스는 부족한 상황이었다(쿠폰 도메인을 주 업무로 진행하는 사람은 혼자였으니). 일정 수준의 기능, 품질을 보장하며 쿠폰 시스템을 구축하기 위해 3rd party 도입은 적절한 결정이었다고 생각한다.
기능 분석: 3rd party 쿠폰 시스템에 기대하는 기본적인 기능은 몇 가지 유형의 쿠폰 발급, 관리였다. 예를 들어, 특정 상점 대상 정률 할인 혹은 첫 주문 고객 대상 정액 할인과 같은 유형의 쿠폰 발급이 가능한지 직접 기능을 사용하며 분석했다. 또한, 여러가지 유형의 쿠폰을 상상하며 어느 수준까지 쿠폰 조건을 설정할 수 있는지 테스트를 진행했다.
API 분석: 클라이언트 앱 <> 우리 서버 <> 3rd party 서버 구조의 통합을 위해 3rd party 에서 제공하는 API를 분석했다. 필요한 API가 존재하는지, 존재한다면 우리 서버에서는 어느정도의 의존성을 갖고 원하는 기능을 구축할 수 있을지 분석하는 작업을 진행했다.

쿠폰 시스템 구축 — 마케팅 팀 요구사항 수립 지원

백엔드 엔지니어 포지션으로 입사를 했지만 나의 업무 영역을 개발로 한정지을 수는 없었고, 스스로 원하지도 않았다. 내 경험으로 구체화하여 이야기 하자면, 나는 마케팅 팀이 운영하게될 쿠폰 시스템을 구축하고 있었고, 마케팅 팀이 요구사항을 더 빠르고 구체적으로 수립할 수 있도록 내가 할 수 있는 일을 해야했고 그러기를 원했다.

3rd party 기능 분석을 진행하면서 다양한 유형의 쿠폰을 생성 및 발급해봤다. 이 경험과 우리 서비스 특성을 결합하여 발급 가능하다고 생각되는 유형의 쿠폰을 정의하고 마케팅팀에 선제안하는 방식으로 일을 진행시켰다.
그렇게 마케팅팀에서 제안하는 첫 요구사항을 모두 구현할 수 있을 거라고 기대하지는 않았다. 우리는 요구사항과 우리가 할 수 있는 것을 서로 맞춰나가는 과정이었다. 요구사항을 온전히 개발로 풀어가기에 주어진 시간과 자원 내에서 한계가 있다고 생각한다면, 요구사항을 다른 방식으로 만족시키기 위해 솔루션을 찾거나 마케팅팀과 커뮤니케이션 하는 방식으로 일을 진행했다.

쿠폰 시스템 구축 — 3rd party 및 우리 서버 integration

3rd party 서비스를 분석하고, 마케팅팀의 요구사항이 구체화되기 시작할 때 우리 서버와의 integration을 위한 설계와 구축 작업을 진행했다. 개발자 동료들과 설계 방향에 대해 지속적으로 논의하며 모두가 동의하는 방향으로 일을 진행했다.

설계의 기본 방향은 3rd party를 걷어낸다고 할 때, 언제든 쉽게 분리할 수 있는 구조를 유지하자였다. 기존 데이터 모델이 쿠폰 데이터 모델에 의존하지 않도록, 애플리케이션 코드 레벨에서 쿠폰 관련 로직이 다른 비즈니스 로직과 공존하지 않도록 모듈화하여 분리시키는 원칙을 가지고 작업을 진행했다.
그렇게 구축한 쿠폰 시스템의 결과는 다음과 같다. 마케팅 운영자들이 3rd party dashboard를 통해 쿠폰을 생성 및 수정하면 우리 서버와 동기화, 사용자들이 앱을 통해 쿠폰을 확인 및 사용, 첫 구매 고객 대상 정액/정률 할인 지원, 특정 상점 대상 정액/정률 할인 지원 등.

그 외,

내가 쿠폰 시스템 구축을 주 업무라고 표현한 이유는, 프로덕트 팀원이라면 프로덕트를 완성하기 위해 필요한 일은 담당 업무의 구분 없이 할 수 있어야 한다고 생각하기 때문이다. 쿠폰 시스템 구축에 3개월 중 가장 많은 시간을 할애한 것은 맞지만 다음과 같이 필요한 업무도 병행했다.

우리 프로덕트의 핵심 기능인 주문 관련 기능을 조금씩 개선했다. 나보다 먼저 프로덕트 개발을 진행하고 있었던 동료가 대부분의 기능을 구축해 두신 상황이었다. 나 역시 핵심 비즈니스 로직에 대해 당연히 동기화가 필요했기 때문에 작은 이슈이지만 티켓을 할당받아 주문 관련 기능을 개선해나갔다.
백엔드 엔지니어 포지션으로 있는 팀원은 나를 포함해서 2명이다. 프로덕트 오픈 날짜이 다가오면서 자연스럽게 인프라 구축도 진행해야 했다. 기본적으로 AWS, MongoDB Atlas 등을 이용하여 인프라 구축을 진행했다.
개인적으로 공유하고 피드백받는 걸 매우 좋아한다. 그 속에서 가장 많이 성장할 수 있다고 생각한다. 지금 팀에서도 역시 Pull Request 기반으로 서로의 코드를 리뷰 받고 개선하는 과정이 자연스럽게 스며들어있다. 하루의 업무 시간 중, 동료의 코드를 리뷰하는 일을 높은 우선순위로 두고 진행하는 팀이다. Pull Request, 코드 리뷰와 관련된 에피소드는 아래 링크에서 확인할 수 있다.

1. [WHY 시리즈 1]E.007 — Pull Request를 통해 잡은 오류
2. [WHY 시리즈 1]E.006 — 커밋 그래프, mongoose virtual, Pull Request

Who?

그럼 나는 지금 누구와 일하고 있는지에 대해 이야기하고자 한다. 회고 글을 가장한 동료 자랑이 될 수도 있겠다.

팀장이자 PM이자 엔지니어인 Joy. 나를 베트남 프로덕트 팀으로 이끌어 준 분이다. 팀장이자 PM이자 엔지니어로 존재하고 있다. Joy와 일을 해보는 건 처음이지만, 내가 Joy에게 기대했던 모습 그 이상의 모습을 보고있다. 내가 만난 매니저 중 가장 합리적인 의사결정을 잘하는 사람이다. 사업 초기인 만큼 수많은 의사결정이 Joy 앞에 놓여있다. 항상 당황하지 않고 우리에게 필요한 일을 냉정하게 판단하고, 우리가 이 일을 왜 해야 하는지를 모두에게 동기화시킨다. 또한, Joy는 팀장으로서 우리 팀을 위한 일을 한다기보다 우리 팀이 만들게 될 프로덕트를 위한 일을 한다. 프로덕트를 만들어가는 팀원들에게 부담스러울 수 있는 요구사항이 들어와도, 프로덕트를 위해 필요한 요구사항이라면 주어진 리소스 내에서 해결할 수 있는 방법을 끊임없이 고민하고 결정한다. 그러면서 동시에 개발을 손에서 놓지 않는다. 운영자를 위한 도구는 외로이 홀로 개발을 진행하고, 클라이언트 개발도 여력이 닿는 한 돕고 있다. 가끔은 엄청난 책임감의 무게가 비출 때도 있어서 걱정도 된다. 하지만 조이라면 그 무게를 동료들에게 현명하게 나누고 지금처럼 잘 이끌어 나갈 것이라는 믿음이 있다. 앞서 언급한 것 처럼, 내가 매니저가 된다면 조이처럼.

공유하고 피드백 주고받기를 선호하는 개발팀. 손가락이 아플 정도로 글로 쓰고 공유했던 코드리뷰 문화가 있다. 개발자 어느 하나 코드리뷰 합시다 라고 주장하지 않았고, 자연스럽게 스며들어있는 문화였다. 필수 업무로 서로의 코드를 리뷰하고, 개발 프로세스 중 불편한 혹은 비효율적인 부분이 있다면 자발적으로 개선해 나가고 공유한다. 이러한 환경에서 서로의 성장에 동기 부여가 된다는 점은 당연하고, 내가 느끼는 가장 좋은 점은 ‘우리 코드 리뷰 해야해요, 우리 테스트 코드 만들어야 해요’ 설득시키기 위한 노력을 굳이 하지 않아도 된다는 점이다. 또 하나의 자랑거리는, 내가 개발해야 할 일이 아닌 우리가 만들어야 할 프로덕트를 먼저 생각하는 개발팀이라는 점.
배달의 민족 DNA를 보유한 PM 및 디자이너. 베트남 프로덕트 팀은 또 다른 PM 및 디자이너 2분을 제외하면 모두 우아한 형제들로 새롭게 입사한 분들이다. 한국의 배달의 민족 서비스와는 별도로 베트남에서 새로운 서비스를 구축하고 있지만, 자칫 배달의 민족 색깔을 잃어버릴 수 있는 상황에서 PM 및 디자이너 2분의 적절한 방향 제시는 소중하다. 더 다행인 것은 고집하기보다는 유연하게 새로운 시장과 변화를 받아들이시는 분들이라는 점이다.

수습이 해제되고 회고 글을 써야 하는 시기가 하필(?) 매우 바쁠 수밖에 없는 시기와 맞물려서 평소만큼 개요를 고민하지 않고 두서없이 써 내려갔다. 내가 우아한 형제들 베트남 프로덕트 팀을 왜 선택했고, 그래서 무엇을 했으며, 누구와 함께하는지 이야기하고 싶었으니 개인적인 목표는 달성했다. 앞으로 서비스가 런칭되고 확장되면서 분명 새로운 동료들과 함께해야 하는 시기가 다가올 텐데, 지금처럼 힘들지만 즐겁고 서로 동기부여가 될 수 있는 좋은 동료들과 계속하기를 기대한다. 얼마 남지 않은 베트남 프로덕트 팀의 첫 서비스 런칭도 화이팅.

앞으로 나의 우아한 형제들 베트남 프로덕트 팀 생활을 더 응원한다. 자, 이제 면 수습 회고 글은 당분간 그만쓰자 제발.