이 글은 셀메이트 개발자 컨퍼런스 D² 발표 내용을 바탕으로 정리한 포스트입니다.

안녕하세요. MSA에서 우리가 지향해야 할 방향에 대해 발표한 상품개발팀 김범수입니다. 최근 셀메이트에서는 결제 및 WMS 등 다양한 신규 프로젝트가 시작되었고,그 과정에서 기존의 모놀리식 아키텍처에서 벗어나 점진적으로 MSA 구조로 전환되고 있습니다. 아키텍처가 변화할 때 가장 중요한 것은팀 구성원 모두가 그 설계를 명확히 이해하고 공감하는 것입니다. 그리하여 이 시간에는 간단하게라도 MSA에 대해 이해를 해보고자 해당 주제를 선정하게 되었습니다.

좋은 설계란 무엇일까?

지난 컨퍼런스에서 헤드님께서는 “좋은 설계란 결국 팀 구성원 모두가 잘 이해할 수 있는 설계다” 라고 말씀하셨습니다. 이 말의 핵심은, 팀 전체의 명확한 이해가 있을 때 비로소 문제를 빠르게 발견하고, 효율적으로 개선할 수 있다는 데 있습니다. 대웅님은 이를 실현하기 위한 세 가지 요인을 강조하셨습니다.

  1. 설계에 대한 기본 지식을 공유해야 한다.
  2. 설계에 대한 이야기를 자주 나누며 지향점을 찾아가야 한다.
  3. 잘못된 설계에 대해 이야기하고 고쳐나가야 한다. 이번 포스팅에서는 그중에서도 1번과 2번, 즉 MSA에 대한 기본 개념을 정리하고 우리가 지향해야 할 방향을 공유하는 데 중점을 두고자 합니다.

MSA란 무엇인가?

“MSA는 하나의 애플리케이션을 작고 독립적인 여러 개의 서비스로 나눈 아키텍처입니다. 각 서비스는 하나의 도메인을 담당하며, 독립적으로 개발, 배포, 운영할 수 있습니다.” — ChatGPT MSA의 핵심은 각 기능을 독립적인 서비스로 나누어, 각각이 자율적으로 동작할 수 있도록 만드는 구조에 있습니다. 이 구조가 필요한 이유를 이해하기 위해, 먼저 우리가 익숙하게 사용해온 모놀리식 아키텍처에 대해 짚고 넘어가야 합니다.

모놀리식 아키텍처란?

모놀리식(monolithic)은 “하나의 거대한 돌"이라는 의미에서 유래되었습니다. 즉, 모든 기능이 하나의 덩어리로 통합되어 있는 구조입니다.

장점

  • 단일 배포로 관리가 용이
  • 코드 베이스가 하나라 재사용과 이해가 쉬움
  • End-to-End 테스트가 간단함

그러나 시간이 흐르면…

  1. 작은 수정도 전체 재배포가 필요합니다. 예를 들어 배너 문구 하나만 수정해도 전체 웹 서비스가 재배포되어야 하는 문제가 발생합니다.
  2. 도메인 간 결합이 강해 유지보수가 어렵습니다. 코드가 여러 도메인에 걸쳐 얽혀 있어 수정 시마다 참조된 모든 영역을 검토해야 합니다.
  3. 확장이 비효율적입니다. 예컨대 특정 이벤트로 결제 트래픽만 폭증해도 전체 시스템을 함께 확장해야 하며, 이로 인해 불필요한 자원 낭비가 발생합니다.

그래서 MSA는 무엇이 다른가?

MSA는 기능 단위로 명확히 분리되어 있어, 독립적인 개발, 배포, 확장이 가능합니다.

  • 수정과 배포의 독립성: 예를 들어 user 서비스만 수정해도 전체 재배포 없이 해당 서비스만 빠르게 배포할 수 있습니다.
  • 도메인 간 의존성 감소: 유지보수가 쉬워지고 예기치 못한 에러 가능성이 줄어듭니다.
  • 부분 확장 가능: 특정 서비스만 독립적으로 스케일업이 가능합니다.
  • 독립적인 테스트 및 장애 추적: 각 서비스 단위로 테스트와 로깅이 가능해집니다.

그러나 MSA에도 단점은 있다

  1. 인프라 비용 증가: 각 서비스마다 배포 환경과 리소스가 별도로 필요하므로 비용이 상승합니다.
  2. 복잡한 운영: 서비스 간 통신, 데이터 일관성, 트랜잭션 처리 등 고려할 사항이 많습니다.
  3. 모니터링의 어려움: 요청이 여러 서비스를 거치기 때문에 분산 추적 시스템이 필수입니다.

MSA를 도입할 때 우리가 지향해야 할 방향

샘 뉴먼(Sam Newman)의 『Building Microservices』에서는 MSA 도입 시 다음 다섯 가지 방향성을 제시합니다.

1. 명확한 서비스 경계

서비스는 기술적 기준이 아닌 비즈니스 도메인 기준으로 나누어져야 하며, 책임이 명확해야 합니다.

2. 서비스 간 독립성

진정한 MSA는 자율적인 배포, 운영, 개발이 가능해야 하며, 내부 구현에 대한 의존을 줄여야 합니다.

3. 점진적인 전환과 지속적인 개선

MSA는 한 번에 전환하는 빅뱅 방식이 아니라 점진적인 진화가 핵심입니다.

4. 관찰 가능성

문제 발생 시 어디서 문제가 발생했는지를 추적할 수 있어야 하며, 모니터링과 로깅 체계를 초기부터 갖춰야 합니다.

5. 팀 전체의 공감과 협업

MSA는 기술 설계 이전에 조직 설계입니다. 팀 간 소통, 책임 정의, 협업이 정립되어야 진정한 효과를 발휘할 수 있습니다.

마무리하며

샘 뉴먼은 말합니다.

“마이크로서비스는 비용을 절감하기 위한 구조가 아니라, 가치를 창출하기 위한 구조다.” MSA는 단기적 효율을 위한 선택이 아닙니다. 더 많은 고민과 설계를 필요로 하지만, 그만큼 유연성과 확장성, 민첩성을 높이는 전략적 구조입니다. 지금 우리가 MSA를 도입하는 과정은 단순한 기술적 전환이 아니라 조직 전체가 함께 성장해 나가는 여정이라고 믿습니다. 감사합니다.