Day1. 플랫폼 비즈니스 성공공식과 지원 기술요소

플랫폼 비즈니스 성공 공식

하버드 비즈니스 리뷰에서는 플랫폼 비즈니스에 대한 성공 공식 3가지를 다음과 같이 제시하였습니다.

다양한 참여자, 수익모델, 데이터 기반한 추천 등 너무 익숙한 이야기들이고 당연한 내용입니다.  

그리고 이렇게 성공한 플랫폼 기업의 결과는, 오늘은 Startup이지만 내일은 Star라는 것입니다.

성공 공식 별 기술 아키텍처 요구사항

이러한 비즈니스 요소를 다음과 같은 기술 아키텍처 요구사항으로 정의해 보았습니다.

Agility – 민첩성

요구사항 1. 서비스는 가입하고 바로 사용을 할 수 있어야 한다.

요구사항 2. 폭발적인 비즈니스 성장에서도 서버나 서비스로 인한 성능 저하가 없어야 한다.

요구사항 3. 다양한 참여자의 요구에 .신속하게 대응할 수 있어야 한다.

요구사항 4. 내/외부간 데이터 및 서비스 연계가 손쉬워야 한다.

요구사항 5. 외부 개발자가 손쉽게 서비스 개발에 참여할 수 있어야 한다.

요구사항 6. 각 참여자의 보안이나 권한은 통합된 방식으로 관리되어야 한다.

ð  오늘은 지도 서비스, 내일은 배달 앱, 모레는 금융 서비스로 확장이 가능한 플랫폼 구조인가?

Resiliency – 탄력성

요구사항 7. 사용 비용이 저렴하지만 기능은 최신이어야 한다.

요구사항 8. 공정한 평가모델로 참여자 간 신뢰가 형성되어야 한다.

요구사항 9. 서비스 사용량이나 수익 공유 방식으로 과금이 되어야 한다.

요구사항 10. 서비스 수준이 측정되고 서비스 불안정에 따라 보상이 제시될 수 있어야 한다.

요구사항 11. 장애가 없거나 발생하더라도 전체 서비스 영향은 최소화 되어야 한다.

ð  장애의 영향은 최소화 되게 구조화 되어 있고, 투자 회전율은 높은 플랫폼 구조인가?

Efficiency – 효율성

요구사항 12. 축적된 데이터를 신속하게 처리하여 추천, 검색을 통해 참여자간 연계가 용이해야 한다.

요구사항 13. 다양한 특성의 대용량 데이터 처리와 AI같은 기술 연계가 손쉬워야 한다.

ð  새로운 기술요소를 쉽게 적용해 보고, 쉽게 교체할 수 있는 플랫폼 구조인가?

아키텍처 요구사항 해결방안

이러한 요구사항은 비즈니스 성장과 기술발전에 따라 지속적으로 플랫폼에 적용될 수 있는 구조가 될 수 있어야 합니다.

사실 이러한 요구는 낯설지 않은 것이고 지금까지 다음과 같은 방법으로 해결을 했습니다.

1.     모든 비즈니스 요구사항 및 가능성을 예측한다.

2.     대규모 투자를 통해 분석, 설계, 개발, 그리고 테스트를 통해 단일화된 시스템 구조를 확보한다.

3.     사업을 진행하고 시스템을 운영하다가 기술요소 한계가 발생하면, 차세대 프로젝트를 진행한다.  -> 1번으로 돌아감

사업을 하다가 발생할 수 있는 기술요소의 한계는 다음과 같습니다.

시스템을 운영하는 시간이 길수록 소스의 복잡도와 중복도가 높아진다. 개발과 운영 조직이 달라서 운영 이관 후 개발소스에 대한 이해도가 떨어진다. 새로운 비즈니스나 기술을 적용하려고 하나 단일화된 시스템 구조의 성능과 연계성이 한계가 된다. 단순한 변경을 수행하더라도, 전체 시스템 영향을 고려해서 테스트 및 배포에 시간 소모가 길어진다. 특정 기능의 성능 저하는 전체 시스템 사용에 영향을 주기 시작한다. 모든 데이터의 연계는 데이터베이스 중심으로 진행되고 데이터베이스 구조의 변동이 가끔 재앙이 된다. 한 서비스의 장애는 곧 전체 시스템의 서비스 중단으로 이어진다. 프로그램 간의 결합도가 높아서 개발자 혹은 운영자간 책임소재가 불분명해지고 있다. ð  운영 비용이 점차 증가하기 시작하고, 새로 개발하자는 의견이 많아진다.

사실 이러한 소프트웨어 아키텍처의 한계는 프로그램 자체에서 발생한 것이 아니라 사람과 관습에서 만들어 낸 것입니다.

이러한 한계를 극복하고자 많은 사람이 조직과 프로세스를 바꾸는 시도를 했고, 이를 마이크로서비스 아키텍처를 구축하는 과정을 통해 달성했다고 합니다.

즉, 작은 규모 서비스(마이크로서비스)의 개발/운영(DevOps)를 지속적으로 반복(Agile)해서 최적의 모델을 만들어 가는 방식으로 변화하는 것이며,

처음에는 속도가 나지 않던 조직/프로세스가 반복을 통해 민첩성과 성과가 개선되는 구조가 되는 것입니다.

마이크로서비스 혹은 단일화된 시스템 구조(Monolithic)

하지만 마이크로서비스는 모든 문제를 해결할 수 없습니다.  다음과 같은 경우는 단일화된 시스템 구조가 더 적합할 수 있습니다.

-       무엇을 개발할지 결정되지 않았다거나 기본적인 서비스 구조도 해보지 않은 상황에서는 단일화된 시스템 구조로 시작하는 편이 낫습니다.

-       비즈니스 성장이 한계가 있고 새로운 요구사항이 많지 않은 경우 단일화된 시스템 구조로 운영하는 것이 더욱 저렴할 수 있습니다.

-       새로운 기술요소나 기능내의 기술 다양성이 높지 않은 경우 단일화된 시스템 구조로 개발하는 것이 효과적입니다.

-       요구사항 분석, 설계, 대규모 외주개발, 테스트가 진행되는 프로젝트는 마이크로서비스 방식으로 진행해서는 안됩니다.

-       외주조직을 연계하거나, 개발과 운영 조직을 다르게 가져가는 경우는 DevOps 형태의 마이크로서비스 방식과 관련이 없습니다.

본 프로젝트 구현에 마이크로서비스 방식을 도입하고자 하는 이유는 위와 같은 상황과 반대이기 때문입니다.

-       구현 대상이 명확하다.  (지금 개발된 기능을 대상으로 전환)

-       비즈니스 성장이 급속할 것으로 기대하고 있으나, 처음에는 작은 규모로 사업을 시작하고 싶다.

-       참여자가 규모, 지역적으로 다양하고 요구사항이 다양하며 신속한 적용이 요구되어 잦은 배포가 필요하다.

-       새로운 기술요소의 도입이 절실히 요구된다.

-       테스트는 단위 기능별로 진행해도 전체 서비스에 영향이 적거나 문제 발생 시 손쉽게 롤백이 필요하다.

-       저렴한 인프라 저렴한 기술요소로 새로운 기술을 구현하고 싶다.

-       작은 규모의 조직으로 지속적인 서비스 확대 및 개선을 수행할 예정이다.  (개발과 운영을 동일한 조직으로 수행)

-       외부 개발자도 쉽게 개발 참여를 할 수 있지만, 외부로 노출된 제한된 API를 통해서 개발을 수행할 수 있어야 한다.

-       여기에 앞에서 언급한 플랫폼 비즈니스 요구사항을 적용할 계획이다.

결론.

플랫폼 비즈니스, 마이크로서비스 방식의 개발은 회사 누구도 경험이 없고 성공에 대한 확신도 없습니다.

이런 방식은 기존처럼 단일 제품이나 아키텍처 선정하여 진행하자는 것도 아닙니다.

지금은 새로운 방식으로 시작하지 않으면 안 되는 상황이라고 판단됩니다.

하지만 작은 규모 마이크로서비스 방식이기 때문에 신속하게 실패하고 다시 시작할 수 있습니다.

실패의 확률을 최소화하고 더 빨리 성공하기 위해서는 조직과 프로세스가 이런 시도를 이해하려는 노력이 필요할 것 같습니다.