발표자는 최근 ThoughtWorks의 ‘모놀리스의 재부상’ 보고서와 Amazon Prime Video, Layers Conf 등 실제 사례를 통해 모놀리스로 회귀하는 경향을 소개하며, Rails 검색량 증가 추이도 이러한 흐름과 무관하지 않음을 보여줍니다. 이어 모놀리스와 마이크로서비스 아키텍처의 특징을 비교하며 각각의 장단점을 명확히 제시합니다.
아키텍처 특징 비교
- 기술 스택: 모놀리스는 단일 언어(monolingo), 마이크로서비스는 다중 언어(multilingo/polyglot)
- 배포: 모놀리스는 느리고 크며, 마이크로서비스는 작고 빠름
- 인프라: 모놀리스는 단순, 마이크로서비스는 복잡 (Kubernetes 필요)
- 지연 시간: 모놀리스는 낮음, 마이크로서비스는 높음 (네트워크 통신)
- 확장성: 모놀리스는 스케일업(제한적, 고비용), 마이크로서비스는 스케일아웃(무제한, 복잡)
- 추적: 모놀리스는 단일 인스턴스, 마이크로서비스는 다수 인스턴스 (추적 시스템 필요)
- 경계: 모놀리스는 모호, 마이크로서비스는 명확
진정한 문제: God Object
발표자는 Conway의 법칙을 인용하여 마이크로서비스가 조직의 확장성과 자율성을 위한 해결책일 수 있지만, 새로운 제품이나 스타트업에는 적합하지 않을 수 있음을 지적합니다. 또한, 마이크로서비스의 API 호출 실패 가능성으로 인한 복잡성(재시도, 서킷 브레이커)을 언급하며, 모놀리스의 진정한 문제는 ‘God Object’와 같은 부적절한 모델링에서 비롯된다고 설명합니다. God Object는 너무 많은 책임을 지고 있어 결합도가 높고 응집도가 낮아 유지보수를 어렵게 만듭니다.
해결책: DRY와 DDD, 점진적 리팩토링
God Object를 해결하기 위해 ‘DRY(Don’t Repeat Yourself)’ 원칙을 ‘코드’의 중복이 아닌 ‘지식’의 중복 방지에 초점을 맞춰 적용해야 함을 강조합니다. Invoice와 Receipt 예시를 통해 우연한 코드의 유사성을 지식의 중복으로 오해하여 잘못된 추상화를 만들면 God Object가 발생할 수 있음을 보여줍니다. Domain-Driven Design(DDD) 또한 더 나은 모델 설계를 돕는 중요한 방법론입니다.
리팩토링은 점진적으로 이루어져야 하며, 명확한 비즈니스 가치를 기반으로 해야 합니다. 사용자 인증 시스템 분리나 복잡한 주문 모델을 배송 모델로 분리하는 사례를 통해 God Object를 점진적으로 개선하는 방법을 제시합니다. Strangler Fig Pattern과 같은 기술을 활용하여 대규모 데이터 마이그레이션 및 리팩토링을 안전하게 수행할 수 있습니다.