요즘 우리나라는 어느 회사든 글로벌 진출을 염두에 두고 있습니다. 대부분의 분야에서 우리나라 시장은 가파른 속도로 축소될 전망이므로 해외 진출은 하고 싶은 것이 아닌 할 수밖에 없는 필수 비즈니스 전략이 되고 있습니다.
해외에 진출하면 현지화, 마케팅, 법률 등의 이유로 현지 팀을 만들고 협업을 하기 시작하는데요. IT 서비스 회사에서의 협업 구조는 어떻게 만들어야 효율이 좋을까요?
저는 5년간 한국과 일본의 협업 구조로 십여 개의 프로덕트를 만들었고, 현재는 일본 최대 규모 배달 서비스인 데마에칸(Demaecan, 出前館)의 프 로덕트 제작 및 운영 전반을 담당하고 있습니다. 지금까지의 경험을 모아서 프로덕트 팀을 중심으로 언어와 문화가 다른 해외 팀과 협업 구조를 만들 때 겪은 다양한 시행착오와 진행 중인 방법을 공유하고자 합니다.
프로덕트를 중심으로 협업 구조 만들기
조직 구성에 정답은 없습니다. 모든 선택은 나름의 장단점이 있고 트레이드오프가 따릅니다. 현실적인 이유로 어쩔 수 없이 선택해야 하는 경우도 많습니다.
저는 어느 서비스든 프로덕트 영역을 담당해 왔기 때문에 이 글은 프로덕트 팀을 중심으로 이야기하겠습니다. 편의상 해외에 전개한 서비스 또는 해외의 팀을 '현지'라고 칭하겠습니다.
첫 번째 패턴 - 사업과 프로덕트의 분리
가장 흔히 볼 수 있는 구성은 현지에는 사업 팀만 있고, 프로덕트는 중앙에서 만드는 것입니다. 프로덕트는 표시 언어만 다국어로 수정한 뒤 현지 법률에 맞춰 필요한 부분만 조금 수정하면 되므로 가장 경제적인 방법이기도 합니다.
아래 그림은 이 패턴의 구조와 각 팀의 속마음을 나타내고 있습니다.
위와 같은 구조는 제 경험과 관찰에 따르면 실패로 끝나는 경우가 많았습니다. 이유는 크게 두 가지입니다.
- 현지 최적화 프로젝트를 제때 진행하지 못함 - 현지에서 전개하는 사업에는 현지에 가장 부합하는 비즈니스와 마케팅 전략이 있기 마련이고, 이는 필연적으로 프로덕트의 수정을 필요로 합니다. 이때 프로덕트가 최적의 시기에 쇄신되지 못하면 현지 팀은 무기 없이 싸우는 꼴이 됩니다. 그 결과 성과가 애매해지고, 여러 관련 수치가 필요한 만큼 나오지 않아 추가 투자를 하기 어려워지는 악순환에 빠지곤 합니다.
- 프로덕트 팀의 낮은 현지 감각 - 사용자의 목소리를 프로덕트에 반영하고 새로 릴리스하는 결과에 사용자가 만족하는 선순환을 이루려면 사용자의 작은 목소리도 민감하게 들을 수 있는 시스템이 필수입니다. 하지만 위 구조의 경우 현지 사업 팀의 필터를 한 번 거쳐서 사용자의 요구 사항이 들어오기 때문에 순수한 현지 사용자의 요구 사항을 놓치는 경우가 많습니다.
이런 문제점과 높은 실패 확률에도 불구하고 이 패턴이 가장 흔한 이유는 앞서 말했듯 시장을 테스트해 볼 수 있는 가장 경제적인 방법이기 때문입니다. 이 패턴을 사용하면서 현지 사용자의 목소리를 잘 수집해 그나마 실패 확률을 낮추려면 LY의 오픈소스 ABC User Feedback을 서비스에 도입하는 것을 추천합니다. 이를 통해 프로덕트 팀의 현지 감각을 많이 끌어올린다면 적어도 두 번째로 지적한 문제는 많이 개선할 수 있습니다.
ABC User Feedback 프로덕트의 일반적인 소개는 팀에서 블로그에 공개한 사용자의 피드백을 잘 관리하고 활용하기 위한 서비스, ABC User Feedback 글을 참고하시기 바랍니다.
데마에칸의 모든 앱에도 사용자가 직접 의견을 남기고 버그를 신고하는 기능을 넣었고, 사용자 의견이 접수될 때마다 한국어 로 기계 번역한 결과를 함께 저장하고 있습니다. 그 덕에 실수로 버그를 릴리스했을 때 급격히 증가하는 사용자의 버그 신고를 보고 빠르게 대응해 해결한 경우가 종종 있습니다.
두 번째 패턴 - 서비스와 플랫폼의 분리
규모가 수백만 MAU를 넘어가거나 이커머스 플랫폼처럼 엔드유저가 둘 이상인 서비스는 아키텍처의 중요성이 높아지며 여러 도메인과 계층이 만들어집니다.
프로덕트 내부에도 플랫폼 또는 공통 모듈이라는 계층이 만들어지기 시작하며, 현지 사용자가 사용하는 다양한 기능에는 현지에 맞춰 최적화된 부분이 생기고, 각 서비스가 플랫폼 안의 여러 컴포넌트를 호출하며 작동합니다. 플랫폼 대신 코어, 서비스 대신 애플리케이션이라고 부르는 곳도 있는데요. 어떤 용어를 사용하든 비즈니스의 공통 정책과 안정성을 지키기 위한 부분과 현지 사용자에게 민첩하고 유연하게 대응하기 위한 부분을 나눈다는 의미는 같습니다.
이렇게 나누는 패턴은 첫 번째 패턴인 사업과 프로덕트를 나누는 경우보다는 성공 가능성이 높습니다. 사용자의 경험에 따라 조정할 수 있는 폭이 넓고, 그만큼 현지 사용자에 맞춰 고유하게 표현할 수 있는 여지가 있기 때문입니다.
이 패턴에서 가장 신경 써야 하는 부분은 플랫폼의 정의입니다. 어디까지 공통 영역에 넣을 것인지 선 긋기를 잘 하는 데에 정답은 없습니다. 그래서인지 공통 영역을 엄격하게 정의하면서 동시에 얼마나 유연하게 만들 수 있는지가 소프트웨어 설계의 역사부터 개발자의 역량을 평가하는 기준까지 관통하는 주제 중 하나로 꼽히곤 합니다.
아래 그림처럼 공통 플랫폼의 어떤 컴포넌트(예: 데이터 수집/분석 시스템)는 비즈니스 독립적으로 만들 수 있을 뿐 아니라 지구 반대편 회사에서도 사용할 수 있도록 만들 수 있습니다. 이와 같은 기준으로 컴포넌트를 하나씩 분리하고 분리 가능한 컴포넌트를 모아 집합을 만들면 이 집합이 곧 플랫폼이라고 말할 수 있습니다.
하지만 공통 플랫폼을 구성하다가 실패하기도 합니다. 만일 현지에 서비스를 새롭게 전개할 때마다 플랫폼을 수정해야 한다면 플랫폼 정의에 문제가 있다고 말할 수 있습니다. 이런 문제를 막기 위한 좋은 훈련 방법은 특정 도메인에 대해 오픈소스답게 설계해 보는 것인데요. 이와 관련해서는 저의 이전 글 오픈소스답게 소프트웨어 설계하기에 자세한 내용이 있으니 참고하시길 바랍니다.
세 번째 패턴 - 제작과 운영의 분리
프로덕트를 만드는 팀과 이를 받아 운영하는 팀을 분리한다면 어떨까요?
민감한 개인정보를 다루는 서비스에서는 어쩔 수 없이 이 패턴을 사용하는 경우가 많습니다. 데이터가 저장되는 지역에 민감한 서비스라면 현지의 인프라에 배포하는 게 필수입니다. 또한, 해외 외주 개발에 의존하는 부분이 많아서 이 패턴을 사용하는 경우도 있습니다. 현지보다 다른 나라의 채용 상황이 좋거나, 경제적인 이득이 있다면 언어의 불편함보다 경제 가치가 크다고 판단해 해외에 프로덕트 제작을 맡기고 그 산출물을 받아서 서 비스를 운영합니다.
아래 그림은 제작과 운영이 나뉠 때 담당하는 시스템과 역할을 나타냅니다.
제작과 운영을 분리한 패턴이 성공하려면 우선 꼼꼼한 모니터링이 가능하도록 만드는 게 필수입니다. 운영은 제작에서 전달받은 산출물이 내부적으로 어떻게 작동하는지 모르므로, 산출물의 입출력뿐 아니라 최대한 상태를 투명하게 파악할 수 있도록 제작할 필요가 있습니다. 그렇지 않으면 운영에서는 산출물을 믿을 수 없으니 이로 인해 겪을 장애의 책임을 지기 싫다고 생각할 수 있습니다.
그다음 중요한 것은 제작과 운영 사이의 디버깅을 위한 데이터 전달 프로세스입니다. 예를 들어, 운영 팀에서 발견한 특정 사용자의 입출력 오류를 고치려면 사용자의 개인정보를 명확한 기준으로 분류해 마스킹 처리한 후 제작에 전달할 필요가 있습니다. 현지에 배포한 AI 모델을 튜닝할 때도 운영 쪽에서 입출력 정보는 얻을 수 있지만, 이 정보를 근거로 모델을 조정하는 작업은 제작 쪽의 일입니다.
이처럼 운영의 관점에서는 프로젝트 산출물을 블랙박스라고 가정하므로, 둘 사이에 데이터를 전달하는 흐름과 데이터를 보며 대화하는 효율이 전체 업무 효율에 미치는 영향이 큽니다.
이 패턴은 서비스가 어느 정도 성숙한 운영형 서비스에 적합합니다. 아니, 성숙해야만 가능한 패턴인지도 모릅니다. 왜냐하면 이 패턴의 단점은 중복 투자 또는 운영 리소스의 낭비가 될 가능성이 높기 때문입니다.
제작 팀이 운영의 요구를 늦게 소 화하면 운영은 그야말로 '몸으로 때우는' 시간을 보낼 수밖에 없습니다. 급기야 기다리다 지친 운영 팀이 조금씩 제작 인력을 채용하다 보면 비슷한 역량의 직원이 양쪽에 있기도 합니다. 이는 직원의 역량을 역할이라는 장벽 때문에 온전히 활용하지 못한다는 의미이기도 합니다.
그럼에도 불구하고 나눌 수밖에 없는 이유는 앞서 말했듯 민감한 정보를 취급할 필요가 있다거나 AI 모델처럼 복잡도가 너무 커서 서로가 각자의 영역에 집중하는 게 더 가치 있다고 말할 수 있을 때입니다.
네 번째 패턴 - 공격과 수비의 분리
누구나 빠른 개선으로 프로덕트를 만들고 싶어 합니다. 하지만 그만큼 안정성을 잃기도 합니다.
"This is test!!!"라는 푸시 메시지를 사용자들에게 보낸다거나, 내부 통제가 미흡해서 개인정보를 엑셀로 다루다가 다른 회원에게 잘못 첨부해서 보낸다거나, 환불 처리가 잘못되어 정산에 오차가 발생한다거나, 보안이 미흡한 코드로 해킹을 당하는 등의 사건은 전 세계에서 매주 나옵니다.
이런 문제들을 최소화하는 방법으로 사용자 경험에 직접적인 프로덕트(공격)와 그 외의 프로덕트(수비)로 역할을 나누는 방법이 있습니다. 가벼운 예로 공지 사항을 관리하는 시스템이 있습니다. 인프라에 장애가 발생해서 앱에 긴급 공지를 보여줘야 하는데, 공지 사항 시스템 또한 서비스 인프라에 함께 있다 보니 장애 공지를 제때 낼 수 없는 회사도 많습니다.
이를 방지하려면 공지 사항 시스템은 별도의 인프라에 구성할 필요가 있습니다. 공지 사항 외에도 실시간 처리가 필요 없는 데이터 분석 시스템이나 경리 시스템과 같은 일명 백오피스 프로덕트들이 있습니다. 그뿐만 아니라, 서비스를 만드는 데 집중하는 프로덕트 팀은 그 프로덕트를 제어할 수 있는 적절한 운영 도구를 함께 만드는 데 어려움을 겪곤 합니다. 이럴 때 프로덕트를 지원하는 프로덕트를 만드는 팀이 별도로 있다면 든든합니다.
아래 그림처럼 각 프로덕트가 바라보는 사용자(Actor라고도 합니다)를 나눠서 만드는 팀을 생각해 볼 수 있습니다.
이 패턴은 앞서 언급한 서비스와 플랫폼의 분리와 비슷하다고 생각할 수 있습니다. 차이가 있다면, 플랫폼에 장애가 발생했을 때는 사용자 경험과 비즈니스에 즉각적인 영향을 주지만, 수비 역할의 프로덕트는 장애가 발생해도 사용자 경험에 직접 영향을 끼치지 않거나 영향을 끼쳐도 큰 영향을 주지는 않습니다.
또한 세 번째 패턴으로 언급한 제작과 운영의 분리와 비슷하다고 생각할 수 있습니다. 차이가 있다면, 제작과 운영의 분리에서 운영 팀은 자체 개발을 하지 않는 운영 인력이 대부분이지만, 공격과 수비의 분리는 수비 팀에서도 적극적으로 프로덕트를 만듭니다.
즉, 수비를 담당하는 프로덕트 팀은 철저하게 공격(시장 공략)을 담당하는 프로덕트를 위한 지원 프로덕트를 만듭니다.
이 패턴은 주로 게임 회사에서 찾아볼 수 있습니다. 게임은 각 게임마다 자신만의 고유한 시나리오를 가지고 있을뿐더러, 국가 단위로 사업부터 제작, 운영, 각종 규제 대응까지 최적화하는 경우가 많기 때문에 다양한 게임을 운영 중인 회사라도 공통 모듈이 거의 없곤 합니다. 그래서 최소한의 기능만 중앙에서 만들고 각 게임 스튜디오가 여러 게임을 시장에 던져보며 실험하는 데 집중할 수 있도록 운영합니다.
이 패턴의 단점은 공격 팀과 수비 팀의 물고 물리는 관계가 있다는 것입니다. 수비 팀은 공격 팀이 만든 프로덕트의 기능에 강하게 의존하므로, 공격 팀과 아키텍처 및 도메인을 설계할 때 예민해지는 경우가 있습니다. 공격 팀 또한 운영의 편의를 고려해 설계하도록 수비 팀의 강요를 받을 때가 있습니다.
대체로 관리 경험의 편의성을 높이려면 프로덕트의 깔끔함이 훼손될 때가 많습니다. 간단한 예로 관리 도구에서 100개 필드의 일괄 수정 기능을 구현하려면, 공격 팀에서 한 개만 수정 가능하게 만든 API를 100번 호출하는 번거로움을 부담하거나, 반대로 공격 팀이 100개의 수정을 안정적으로 할 수 있는 기능과 테스트를 만드는 부담을 져야 할 것입니다.
그 외의 단점으로 수비를 담당하는 팀의 동기 부여를 관리하는 게 어려울 수 있다는 다소 인간적인(?) 특징이 있습니다. 그래서 글로벌 협업 시 공격 팀이 더 좋은 서비스를 만들 수 있도록 도와주는 것이 회사로서는 비즈니스에 매우 중요한 공헌이라고 수비 팀에 주지시켜줄 필요가 있습니다.
우리는 어떤 패턴이 맞을까
지금까지 제가 경험하거나 관찰했던 네 가지 패턴을 살펴봤습니다. 이를 표로 정리하면 아래와 같습니다.
| 패턴 | 장점 | 단점 |
|---|---|---|
| 사업과 프로덕트의 분리 | 경제적으로 시장을 테스트할 수 있음 | 프로덕트의 현지 감각이 낮을 수 있음 |
| 서비스와 플랫폼의 분리 | 서비스의 자유도와 표현력이 높음 | 서비스의 가능성이 플랫폼 스펙을 넘을 수 없음(플랫폼이 병목이 될 수 있음) |
| 제작과 운영의 분리 | 높은 수준의 패키징이 필수이므로 배포와 확장성이 좋아짐 | 리소스 중복 투자의 가능성이 있음 |
| 공격과 수비의 분리 | 공격 팀이 높은 수준으로 프로덕트를 만들 수 있음 | 설계할 때마다 상호 의존이 발생할 수 있음 |
이 중에서 어떤 패턴이 맞는지는 현지의 상황에 따라 다르다고 말할 수 있습니다. 현지에 개발 팀을 만들고 싶어도 채용이 안 돼 만들 수 없는 경우도 많기 때문입니다.
제가 담당하는 데마에칸의 프로덕트는 위의 네 패턴이 모두 조금씩 섞여 있습니다. 배달 서비스의 특성상 엔드유저가 주문자, 가맹점, 배달원으로 셋이며, 회사 직원을 위한 사내 관리 시스템까지 포함하면 프로덕트가 상대하는 엔드유저는 네 그룹이라고 말 할 수 있습니다. 그래서 각 엔드유저의 상황과 각 팀의 전문성에 따라 계속 구성을 조정하고 있습니다.
아래 표는 데마에칸의 상황을 위 패턴으로 설명한 것입니다.
| 영역 | 패턴 | 설명 |
|---|---|---|
| Delivery Engine | 사업과 프로덕트의 분리 | 현지의 사업 팀에서 주요 KPI를 설정하고, 이를 달성하기 위한 기능을 한국의 프로덕트 팀에게 요구합니다. 사업이 요구하는 기능은 변동비(주문 1건당 비용)와 강한 상관관계가 있습니다. 한국의 프로덕트 팀은 시스템 운영을 포함하며, KPI 달성이 가능하도록 제때 좋은 프로덕트를 만드는 데 집중하고 장애 대응도 합니다. |
| Merchant Service | 서비스와 플랫폼의 분리 | 가맹점주가 매장을 관리하는 앱은 현지의 가맹점 플랫폼을 활용하여 한국에서 서비스를 만듭니다. 가맹점 플랫폼은 점포 정보, 메뉴, 리뷰, 판촉 등의 API가 있으며 서비스는 이들을 호출해 가맹점주에게 서비스 경험을 제공하고 있습니다. |
| Account Service | 제작과 운영의 분리 | Account Service는 계정과 그 역할을 관리하는 시스템입니다. 개인 정보와 밀접한 시스템이면서 개발 난도가 높습니다. 그래서 제작과 배포는 한국에서 이루어지지만 베타 환경에서 QA까지만 진행합니다. 프로덕션 환경에 배포한 후에 인프라와 데이터의 접근은 불가능합니다. |
| Retail System | 공격과 수비의 분리 | 한국의 개발 팀이 점포, 상품, 재고, 주문 시스템을 만들고, 이것의 관리 도구(통칭 Admin)와 POS 연계 개발은 현지에서 담당합니다. 코어는 주문, 재고 관리, 점포와 상품 시스템이 있습니다. 어떻게 API 스펙을 디자인하는가가 협업할 때 가장 많이 하는 대화 주제입니다. |
이처럼 각 분야마다 협업의 형태는 다릅니다. 사용자는 프로덕트 내부의 협업 구조에는 아무 관심이 없기 때문에 여기에 정답은 없습니다. 현재의 내외부 상황에 맞는 최적의 구성을 갖추도록 끊임없이 조정할 뿐입니다.
글로벌 협업을 맞이하는 자세
지금까지 살펴본 모든 패턴에는 공통점이 있습니다. 팀이 나뉘어 있고 그 사이에는 필연적으로 접점이 있다는 것입니다.
이상적인 모습은 물리적으로 떨어져 있든 법률적으로 법인이 나뉘어 있든 상관없이 하나의 팀으로 일하는 모습입니다. 구조적으로 최선의 패턴일지라도 협업하는 상대방의 성격에 따라 프로젝트가 성공하기도, 실패하기도 합니다.
아니, 어쩌면 패턴보다 중요한 것은 서비스 감각도 높고 협업 능력도 높은 사람들끼리 좋은 서비스를 만들겠다는 목표만으로 일하는 팀워크일 것입니다.
나의 당연함은 어디까지 당연한 것인가
영국의 철학자 존 스튜어트 밀(John Stuart Mill)은 개인의 자유에 대해 '나의 자유와 상대방의 자유가 맞닿은 지점이 자유의 범위'라고 말했습니다.
일하다 보면 동료로부터 '상대방이 (한국인이 아니라서) 당연한 걸 이해 못해서 답답하다'라며 푸념하곤 합니다. 수년간 들었던 푸념 속에 공통적으로 나오는 표현으로 '당연함'이 있었습니다.
하지만 어디까지가 상식이고 당연함인지는 같은 성장 배경을 가진 사람들 안에서도 무척 다릅니다. 우리나라만 대상으로 서비스를 만들어도 생각대로 되지 않습니다. 이 사실을 깨닫지 못하면 자신의 설득력을 높일 수 있는 기회를 스스로 놓치게 됩니다.
설득력은 3단 논법 같은 기술일 수도 있지만, 업무를 대하는 진정성과 내 감정보다 팀 성장을 우선하는 리더십, 그리고 당신을 이해하고 설득하고 싶다는 의지까지 합쳐진 눈에 안 보이는 힘입니다. 그러니 나만의 당연함을 주장하기에 앞서 먼저 객관화해 보는 게 더 건설적입니다.
글로벌 서비스는 가장 완벽한 데이터 드리븐 훈련의 장
현지의 동료가 현지의 모든 사용자를 대변한다고 말할 수는 없습니다. 즉, 나의 주장을 객관화하는 노력과는 별개로 양측 모두의 주관을 넘어서 사안을 객관적으로 보고 논할 수 있는 자세가 필요합니다.
해외 팀과 일하면 아무래도 서로 완곡하게 표현하거나 감정을 절제하므로 사안에 대해 객관화가 강제되는 특징이 있습니다. 통역을 사이에 두고 말하면 더더욱 그렇습니다. 자연히 객관적인 논거를 위해 데이터를 더 많이 수집하고 볼 수밖에 없습니다. 결과적으로 당연함과 답답함의 계곡을 건너 객관과 납득의 언덕에 이르면 그동안 얼마나 나 자신을 속이며 일했는지 깨닫기도 합니다.
프로덕트를 더욱 설득력 있고 견고하게 만들고 싶은 분들이라면 글 로벌 협업 경험을 꼭 해보시길 권하며, 이 글이 협업 구조를 고민할 때 도움이 되기를 바랍니다.