요즘 스타트업들은 글로벌 진출을 염두에 두고 있습니다. 대부분의 분야에서 우리나라 시장은 가파른 속도로 축소될 전망이므로 해외 진출은 하고 싶은 것이 아닌 할 수 밖에 없는 필수 비즈니스 전략이 되고 있습니다.

해외에 진출하면 보통 현지화, 마케팅, 법률 등의 이유로 현지 팀을 만들고 협업을 하기 시작하는데요.

IT 서비스 회사에서 협업 구조는 어떻게 만들어야 효율이 좋을지 다양한 시행착오를 경험해보신 분께서 작성해주신 글이 있어 공유드립니다.

사업과 프로덕트의 분리

흔히 볼 수 있는 패턴입니다. 프로덕트는 표시 언어만 다국어로 수정한 뒤 현지 법류에 맞춰 필요한 부분만 조금 수정하면 되므로 가장 경제적인 방법입니다.

다만 현지 최적화 프로젝트를 제때 진행하지못하고, 프로덕트 팀에 현지 감각이 낮기 때문에 순수한 현지 사용자의 요구사항을 놓치는 경우가 많습니다.

이러한 문제 때문에 실패로 끝나는 경우가 많았지만 이 패턴이 가장 흔한 이유는 시장을 테스트해 볼 수 있는 가장 경제적인 방법이기 때문입니다.

서비스와 플랫폼의 분리

이 패턴은 사용자의 경험에 따라 조정할 수 있는 폭이 넓고, 현지 사용자에 맞춰 고유하게 표현할 수 있는 여지가 있습니다.

가장 신경써야 하는 부분은 플랫폼의 정의이며, 어디까지 공통 영역에 넣을 것인지 선 긋기를 잘 하는데에 정답은 없습니다. 그래서인지 공통 영역을 엄격하게 정의하면서 동시에 얼마나 유연하게 만들 수 있는지가 소프트웨어 설계의 역사부터 개발자의 역량을 평가하는 기준까지 관통하는 주제 중 하나로 꼽히곤 합니다.

제작과 운영의 분리

민감한 개인정보를 다루는 서비스에서는 이 패턴을 사용하는 경우가 많습니다.

데이터가 저장되는 지역에 민감한 서비스라면 현지의 인프라에 배포하는게 필수입니다.

현지보다 다른 나라의 채용 상황이 좋거나, 경제적인 이득이 있다면 언어의 불편함보다 경제 가치가 크다고 판단해 해외에 프로덕제작을 맡기고 그 산출물을 받아서 서비스를 운영합니다.

이 패턴이 성공하려면 꼼꼼한 모니터링이 가능하도록 만드는 게 필수입니다.

운영은 제작에서 전달받은 산출물이 내부적으로 어떻게 작동하는지 모르기에, 산출물의 입출력뿐 아니라 최대한 상태를 투명하게 파악할 수 있도록 제작 할 필요가 있습니다. 그렇지 않으면 운영에서는 산출물을 믿을 수 없기에 이로 인해 겪을 장애의 책임을 지기 싫다고 생각할 수 있습니다. 이 패턴은 서비스가 어느 정도 성숙한 운영한 서비스에 적합합니다.

공격과 수비의 분리

누구나 빠른 개선으로 프로덕트를 만들고 싶어합니다. 하지만 그만큼 안정성을 잃기도합니다.

이런 문제들을 최소화하는 방법으로 사용자 경험에 직접적인 프로덕트(공격)와 그 외의 프로덕트(수비)로 역할을 나누는 방법이 있습니다.

다른 패턴들은 장애가 발생했을 때에 사용자 경험과 비즈니스에 즉각적인 영향을 주지만, 수비 역할의 프로덕트는 장애가 발생해도 사용자 경험에 직접 영향을 끼치지 않거나 영향을 끼쳐도 큰 영향을 주지 않습니다.

수비를 담당하는 팀은 철저하게 공격을 담당하는 프로덕트를 위한 지원 프로덕트를 만듭니다.

이 패턴의 단점은 공격과 수비 팀의 물고 물리는 관계가 있다는 것입니다.

그래서 우리 팀은 어떤 패턴이 맞는가?

• 사업과 프로덕트의 분리: 경제적으로 시장을 테스트 할 수 있지만, 프로덕트의 현지 감각이 낮을 수 있음

• 서비스와 플랫폼의 분리: 서비스의 자유도와 표현력이 높지만, 서비스의 가능성이 플랫폼 스펙을 넘을 수 없음

• 제작과 운영의 분리: 높은 수준의 패키징이 필수이므로 배포와 확장성이 좋아지지만, 리소스 중복 투자의 가능성이 있음

• 공격과 수비의 분리: 공격팀이 높은 수준으로 프로덕트를 만들 수 있지만, 설계할 때마다 상호 의존이 발생할 수 있음