우리가 모듈러 모놀리스(Modular Monolith)로 회귀한 이유
소프트웨어 팀들의 전략이 변하고 있습니다. 많은 팀이 수년간 앱을 마이크로서비스로 분해하는 데 시간을 보냈습니다. 이제 그들은 다시 조각들을 하나로 합치고 있습니다. 그렇다고 예전의 지저분한 모놀리스를 만드는 것은 아닙니다. 그들은 모듈러 모놀리스를 구축하고 있습니다.
마이크로서비스는 숨겨진 비용을 발생시킵니다. 분산 시스템은 엄청난 복잡성을 더합니다. 많은 팀이 확장성이 필요해서가 아니라, 단순히 유행 때문에 마이크로서비스를 채택합니다. 팀 규모가 작다면 마이크로서비스가 오히려 속도를 늦추고 있을지도 모릅니다.
모듈러 모놀리스는 두 방식의 장점을 모두 제공합니다. 하나의 배포 단위로 유지되면서도, 코드는 엄격한 모듈로 구성됩니다. 분산 시스템을 운영하는 높은 비용 없이도 명확한 경계를 가질 수 있습니다.
두 접근 방식을 비교해 보세요:
• 배포: 모놀리스는 하나의 단위를 사용합니다. 마이크로서비스는 여러 개를 사용합니다. • 경계: 모놀리스는 엄격한 코드 규칙을 사용합니다. 마이크로서비스는 네트워크를 사용합니다. • 통신: 모놀리스는 단순한 함수 호출을 사용합니다. 마이크로서비스는 네트워크 호출을 사용합니다. • 오버헤드: 모놀리스는 운영 비용이 낮습니다. 마이크로서비스는 비용이 높습니다.
언제 모듈러 모놀리스를 선택해야 할까요?
- 팀의 엔지니어가 50명 미만일 때.
- 클라우드 인프라 비용을 줄여야 할 때.
- 디버깅과 테스트를 단순화하고 싶을 때.
- 어차피 서비스들을 함께 배포해야 하는 경우가 많을 때.
실제 기업들은 이미 이렇게 하고 있습니다. Shopify는 수백만 명의 판매자를 관리하기 위해 모듈러 방식을 사용합니다. Amazon Prime Video는 특정 워크로드를 마이크로서비스에서 다시 모놀리스로 옮겼습니다. 그 결과 인프라 비용을 90% 절감했습니다.
팀 규모가 작다면 넷플릭스 수준의 확장성을 고려하여 구축하지 마세요. 모듈러 방식으로 시작하세요. 데이터가 정말로 필요하다고 말할 때만 서비스를 분리하세요.
통합이 필요한지 확인하려면 다음 체크리스트를 사용해 보세요:
- 기능 개발보다 서비스 간 연결 문제를 디버깅하는 데 더 많은 시간을 소비하고 있나요?
- 클라우드 비용이 사용자 수보다 더 빠르게 증가하고 있나요?
- 수많은 서비스를 관리하는 DevOps 엔지니어가 5명 미만인가요?
- 버그를 찾기 위해 엔지니어가 하나의 요청을 3개 이상의 서비스를 거쳐 추적하고 있나요?
만약 "예"라고 답했다면, 모듈러 모놀리스가 올바른 선택일 가능성이 높습니다.
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi