MSA vs 모놀리틱: 무엇이 더 나을까?

소프트웨어 아키텍처 설계에서 MSA(Microservices Architecture)와 모놀리틱 아키텍처는 '한쪽이 정답'일 수 없는 대립 구도를 이루고 있습니다. 그렇다면, 두 방식 중 무엇이 진짜로 더 나을까요? 이 글에서는 두 아키텍처의 장점과 단점, 현실에서의 적용 사례, 그리고 이를 기반으로 브레인스토밍을 통해 현실적인 접근 방향에 대해 고민해봤습니다.

---

1. MSA와 모놀리틱 아키텍처 개요

MSA(Microservices Architecture)

MSA는 애플리케이션을 작은 독립적 서비스들의 집합으로 분리하는 아키텍처입니다. 각 서비스는 독립적으로 배포, 확장, 관리할 수 있으며, 주로 REST API, gRPC 같은 통신 프로토콜을 사용해 상호작용합니다.

모놀리틱 아키텍처

모놀리틱 아키텍처는 애플리케이션의 모든 기능이 하나의 코드베이스와 배포 단위로 구성됩니다. 서비스 간 경계가 없고, 중앙화된 형태로 실행됩니다.

---

2. 두 아키텍처의 장단점

MSA의 장점

1. 확장성: 특정 서비스만 스케일링 가능.
2. 유지보수성: 서비스별로 독립적인 코드베이스 관리.
3. 팀 독립성: 서비스 단위로 개발팀 분리 가능.
4. 탄력성: 특정 서비스 장애 시 전체 시스템이 멈추지 않음.

MSA의 단점

1. 운영 복잡성: 서비스 간 통신, 데이터 동기화, 배포 관리 등.
2. 네트워크 비용: 서비스 간 API 호출에 따른 오버헤드.
3. 개발자 역량 의존: 비즈니스와 시스템에 대한 높은 이해도 필요.
4. 이슈 추적 어려움: 장애 발생 시 원인 추적에 많은 시간 소요.

모놀리틱 아키텍처의 장점

1. 초기 개발 용이: 단일 코드베이스로 빠르게 개발 가능.
2. 운영 단순성: 배포, 모니터링 등 운영 측면에서 간편함.
3. 일관된 데이터 관리: 단일 데이터베이스로 데이터 동기화 문제 감소.
4. 디버깅 용이: 코드베이스가 중앙화되어 있어 문제 추적이 쉬움.

모놀리틱 아키텍처의 단점

1. 확장성 부족: 특정 모듈만 스케일링 불가.
2. 높은 결합도: 코드가 커질수록 유지보수와 변경이 어려움.
3. 배포 리스크: 작은 변경도 전체 재배포를 요구.

---

3. 현실적인 사례와 경험

MSA 사례

이전에 MSA로 구현된 환경에서 6개의 백엔드 서비스를 관리했던 경험이 있습니다. 3명의 개발자가 모든 서비스를 관리해야 했고, 서비스 중 이슈가 발생하면 3~4개의 리포지토리를 열어 코드를 추적해야 했습니다. 이는 관리 비용을 크게 증가시켰습니다. 또한, Proxy를 통한 REST API 통신에서 특정 서버의 장애가 발생하면 트랜잭션이 원활히 진행되지 않았고, 에러 처리가 미흡한 경우 모놀리틱과 큰 차이가 없다고 느꼈습니다.

모놀리틱 전환 사례

결국 NestJS를 도입하여 마이크로서비스를 모듈 단위로 분리하고 이를 모놀리틱 아키텍처로 통합했습니다. 이 접근법은 운영 복잡성을 줄이고 개발 효율성을 높이는 데 효과적이었습니다. 그러나 각 리포지토리의 고유한 장점을 잃지 않도록 신중히 설계해야 했습니다.

---

4. 대안적 접근법: 하이브리드 아키텍처

하이브리드 아키텍처란?

하이브리드 아키텍처는 모놀리틱과 MSA의 장점을 결합한 형태입니다. 강하게 연관된 기능은 "미니 모놀리틱"으로 그룹화하고, 다른 서비스는 독립적으로 유지합니다.

장점

1. 운영 비용 감소: 그룹화된 서비스로 인해 리포지토리 수 감소.
2. 유연성: 필요한 경우 특정 서비스를 독립적으로 분리 가능.
3. 관리 용이성: 서비스 간 통신을 줄여 디버깅과 유지보수 단순화.

단점

1. 설계 복잡성: 그룹화 기준 설정이 까다로움.
2. 경계 관리 필요: 잘못된 그룹화로 결합도가 다시 높아질 위험.

---

5. 도메인 정의와 모듈 구조 설계

그러면 도메인 정의는 쉽나?

아키텍처 설계에서 도메인 정의는 종종 간단하게 여겨질 수 있지만, 실제로는 많은 함정이 숨어 있습니다. "도메인을 정의한다"는 말이 쉽지만, 실제로는 비즈니스 요구사항과 기술적 구현 사이에서 끊임없는 균형을 찾아야 하는 어려운 과정입니다.

1. 도메인의 경계를 명확히 설정하기 어려움:
   • 기술적 관점에서 도메인을 정의하더라도 비즈니스적 이해가 부족하면 경계가 모호해질 수 있습니다.
   • 예를 들어, "사용자(User)"라는 도메인이 고객 관리, 주문 처리, 권한 관리 등 여러 영역과 연관될 경우, 이를 어디까지 포함해야 할지 명확히 하기 어려울 수 있습니다.
2. 도메인 분리로 인한 데이터 중복 및 의존성 문제:
   • 서로 다른 도메인이 동일한 데이터를 필요로 할 때 데이터 중복 또는 강한 결합이 발생할 위험이 있습니다.
   • 예: 주문(Order)과 결제(Payment) 도메인 간 결합이 강해지면 변경에 따른 영향을 받기 쉬움.

예시로 본 현실적인 어려움

• 이전 프로젝트에서는 사용자(User)와 권한(Role) 도메인을 분리하려다 발생한 문제가 있었습니다. 사용자 정보와 권한 정보가 각기 다른 서비스로 나뉘었으나, 권한 검증 시 사용자 정보를 자주 참조해야 했습니다. 이로 인해 서비스 간 호출 비용이 증가하고 디버깅이 어려워졌습니다.
• 이를 해결하기 위해 사용자와 권한 데이터를 하나의 도메인으로 통합해 "사용자 관리"라는 모듈로 재설계했고, 이후 통신 비용이 크게 감소했습니다.

그러면 어떻게 해야 할까?

1. Event Storming: 팀원들과 비즈니스 프로세스를 시각적으로 정리해 공통 이해 도출. Event Storming 자세히 알아보기
2. Bounded Context (DDD): 도메인 경계를 명확히 정의하고, 각 도메인의 역할을 분리. 더 알아보기
3. Context Map: 도메인 간 관계와 의존성을 시각화하여 명확히 규정. 관련 자료
4. Domain Knowledge Database: 용어와 개념을 문서화해 혼란 방지.

---

협업/문서화는 쉬워요?

문서화와 협업도 아키텍처 설계만큼이나 어려운 과제입니다. "팀원 간 협업과 문서화를 잘하면 된다"는 말이 있지만, 실제로는 실행하기가 쉽지 않습니다.

1. 문서화의 가치를 과소평가:
   • 많은 팀이 아키텍처 설계에만 집중하고 문서화는 뒤로 미루곤 합니다.
   • 하지만 적절히 문서화되지 않은 도메인 정의는 시간이 지나면서 유지보수 비용을 크게 증가시킵니다.
2. 협업의 실질적 어려움:
   • 팀원 간 도메인 이해도 차이로 인해 설계 의도가 제대로 전달되지 않는 경우가 많습니다.
   • 예: 비즈니스 팀과 개발 팀이 "고객(Customer)"의 정의를 다르게 이해하여 불필요한 기능을 추가하거나 잘못 설계된 구조를 생성.
3. 현실적인 해결책:
   • 공유 언어 정의: 비즈니스와 개발 모두가 이해할 수 있는 공통 용어집 작성.
   • 협업 도구 사용: Miro, Lucidchart 등을 통해 시각적으로 의사소통.
   • 정기적인 리뷰 세션: 설계 후 정기적으로 팀 리뷰를 통해 이해도를 맞춤.

---

6. 결론: 상황에 맞는 선택이 핵심이다

MSA와 모놀리틱은 상황에 따라 장단점이 뚜렷합니다. 결론적으로 어떤 아키텍처든 성공적으로 운영하려면 팀의 지식과 역량이 필수적이며, 이를 기반으로 프로젝트의 규모와 요구사항에 맞는 방향성을 선택하는 것이 중요합니다.

모듈 중심적인 모놀리틱 통합은 관리 효율성을 높이는 데 효과적일 때도 있고, 하이브리드 아키텍처는 MSA와 모놀리틱의 균형을 유지할 수 있는 좋은 대안이 될 수 있습니다. 중요한 것은 기술 자체가 아니라, 문제 해결에 적합한 설계와 실행이라는 점입니다. 프로젝트의 요구사항을 깊이 이해하고, 팀과 협력하며 고민하는 과정을 통해 올바른 결정을 내려야 합니다. 결국 아키텍처는 절대적인 답이 없는 어려운 문제이며, 상황과 환경에 따라 유연하게 접근하는 지혜가 필요합니다.

---

참조한 페이지

• Event Storming 자세히 알아보기
• Bounded Context 자세히 알아보기
• Context Map 관련 자료