언제부턴가 마이크로서비스가 현대적인 아키텍처의 대명사가 됐다. 면접에서 마이크로서비스 경험을 물어보고, 기술 블로그에는 마이크로서비스 전환기가 넘쳐난다. 모놀리스는 마치 부끄러운 과거처럼 취급받는다.

마이크로서비스 아키텍처가 약속하는 것들이 있다. 독립적인 배포, 기술 스택의 자유, 확장성, 장애 격리, 팀의 자율성. 넷플릭스, 아마존, 우버가 마이크로서비스로 성공했다는 이야기가 퍼졌다. 그래서 모두가 마이크로서비스를 해야 한다고 생각하기 시작했다.

하지만 현실에서 마주하는 건 다르다. 함수 호출이 네트워크 호출로 바뀐다. 타임아웃, 재시도, 서킷 브레이커를 고민해야 한다. 트랜잭션이 여러 서비스에 걸치면 골치가 아프다. 서비스가 10개면 모니터링도 10개, 로그도 10개, 배포 파이프라인도 10개다. 요청이 여러 서비스를 거치면서 어디서 문제가 생겼는지 찾기 어렵다.

최근에는 오히려 모놀리스를 재평가하는 목소리가 커지고 있다. Amazon Prime Video 팀이 마이크로서비스에서 모놀리스로 돌아가서 비용을 90% 줄였다는 글이 화제가 됐다. Shopify는 거대한 모놀리스를 성공적으로 운영하고 있다.

마이크로서비스가 진짜 의미 있으려면 조건이 필요하다. 팀이 여러 개이고 서로 다른 속도로 배포해야 할 때. 특정 기능에만 트래픽이 집중되고 그 부분만 스케일 아웃해야 할 때. 쿠버네티스, 서비스 메시, 분산 트레이싱을 운영할 수 있는 팀이 있을 때.

마이크로서비스를 잘못하면 분산 모놀리스가 된다. 서비스는 나눠져 있는데 배포는 같이 해야 한다. A 서비스를 수정하면 B, C, D 서비스도 같이 수정해야 한다. 이건 마이크로서비스의 장점은 하나도 없고 복잡성만 가져간 상태다.

마틴 파울러의 조언이 있다. 모놀리스로 시작하라. 마이크로서비스는 나중에 해도 된다. 처음부터 마이크로서비스로 시작하면 경계를 잘못 나누기 쉽다. 도메인을 충분히 이해하지 못한 상태에서 서비스를 나누면 나중에 고치기 어렵다.

넷플릭스와 아마존이 마이크로서비스를 선택한 건 그들의 규모와 조직 구조 때문이다. 그들을 따라 한다고 우리 회사가 넷플릭스가 되는 건 아니다.