3번의 MSA 아키텍처 경험

 

MSA 아키텍처 기반의 서비스를 직접적/간접적으로 경험하면서 느낀점을 기록해 본다.

 

+ 3번의 MSA 경험

A 서비스
개발자 2명 투입 (나를 포함)

팀 동료의 권유와 새로운 기술에 대한 욕심

Spring Cloud 도입

약 10개의 서버

B2B 서비스라 사용자 많지 않았음.

3~4년 뒤에 서비스 사라짐

B 서비스
MSA 서버군 인수인계 받음
약 10개의 서버로 구성 되어 있음
라이브 서비스가 아닌 PoC 단계의 서비스 (Proof of Concept : 특정 아이디어나 이론이 실현 가능한지를 확인하기 위한 시범적 프로젝트)
혼자서 새로운 요구사항을 구현하고, 라이브 오픈까지 진행해야 하는 상황이였다.
이때 팀을 이동하면서 진행한 첫 프로젝트 이기도 했고, WebRTC 라는 기술을 이용한 서비스 이기에 여러모로 걱정이 많았다.
인수인계 받은 서비스이고, 10개의 서버를 혼자서 감당하며 라이브까지 오픈하기에는 다소 부담스러웠다.
새로운 기능을 구현하기에는 여러 서버를 오가며 수정 업데이트 해야 했고, 이슈 트래킹에 대한 높은 코스트가 예상되었다.
결국 여러가지 리스크를 고려해서 모놀리식 방식으로 새롭게 구현하였다. 10개의 서버를 3개의 서버로 줄였다.
개발 후 서비스를 안전하게 오픈 완료
하지만 사용자 많지 않았다.
결국 2년 정도 유지하고, 서비스를 내렸음.

C 서비스
다수의 인원이 투입되어 프로젝트 수행
약 15개의 서버로 구성
빠르게 오픈하기 위해서 많은 인원을 투입, 여러 팀에서 함께 진행, 한 사람당 1~2개의 서버를 담당
한정적인 시스템 자원으로 인하여 사용자 수 많지 않음을 예측
비용 문제로 프로젝트 중단

 

+ 결과적으로 A, B, C 서비스 모두 사라졌다.

2개의 서비스는 시장에서 살아남지 못했고, 1개의 서비스는 시장에 나오지도 못하고 사라져 버렸다.
지금까지 내가 3번의 MSA를 직접적/간접적으로 경험한 프로젝트들이다.

서비스를 성공시킨다는 것 자체가 여간 쉬운 일이 아니다.
예를 들어 야구에서의 홈런 한 방이 서비스의 성공이라고 가정해 보자.
타자가 첫 타석에 들어서자마자 홈런을 칠 수 있을까? (있다 하더라도 확률적으로 힘들다.)
타석에 서서 삼진 아웃도 당해보고, 파울도 쳐보고, 안타도 쳐봐야 결국에 홈런을 때릴 수 있는 것이다.

이처럼 우리가 만들어내는 서비스 또한 이렇게도 해보고, 저렇게도 해보고, 다양한 시도를 통해서 시장의 평가를 받아야 한다.
다양한 시도를 하기 위해서 처음부터 복잡성이 증가하고, 개발 비용이 상승하며 개발 속도 또한 저하되는 MSA 아키텍처를 무조건 고수할 필요가 있을까?

얼마만큼의 사용자가 유입이 될지를 예측해야 하고, 그에 맞는 적절한 엔지니어링이 요구되어야 한다.
사용자 유입이 예측되지 않으면 모노리틱 아키텍처로 빠르게 개발하고, 시장의 평가를 받으며 서비스를 성장시켜야 한다.
서비스가 성장하고 난 뒤 MSA 아키텍처를 도입해도 늦지 않다.
배달의민족, 카카오, 쿠팡, 토스뱅크, 11번가 등도 처음에는 모노리틱 아키텍처에서 점진적으로 MSA 아키텍처로 전환한 사례들이다.

 

+ 기술보다 서비스 생존이 우선

기술보다 우선시 되어야 할 것은 서비스이다.
서비스가 살아남아야 일하는 사람도 살아남는다.
일하는 사람이 있어야 MSA도 해볼 수 있는 것이다.
기술은 그저 거들뿐이다.