Kotlin으로 직접 구현하며 배우는 MSA - 0. 이 시리즈를 시작하며

✨ 공부하며 성장하는 기록 공간입니다.

아직 부족한 점이 많고 배워야 할 것도 많지만, 그만큼 하나씩 알아가는 과정에서 큰 재미를 느끼고 있습니다.
이 블로그는 제가 공부한 내용을 정리하고, 직접 구현하며 겪은 고민과 시행착오를 기록하기 위한 공간입니다.

틀리거나 부족한 내용이 있을 수 있습니다. 잘못된 내용이나 더 나은 방향이 있다면 언제든지 편하게 지적해 주세요 😁

해당 포스팅 시리즈에서는 Kotlin/Spring 기반으로 MSA를 이해해보는 과정을 다룰 예정입니다.
단순히 기술을 사용하는 방법만 정리하기보다는, 초기 프로젝트 구축부터 시작해 특정 문제가 왜 발생했는지, 그 문제를 해결하기 위해 어떤 기술과 구조가 등장했는지, 그리고 실제 개발 과정에서는 어떻게 적용할 수 있는지를 함께 공부해보려고 합니다. 가능한 한 복잡한 개념도 쉽게 풀어내고, 제가 직접 이해한 방식으로 정리해보겠습니다.

 

회사에 취업을 하기 위해 면접을 준비할 때에 MSA에 대한 개념 정리와 필요한 이유 들을 장황하게 정리하고,
공부를 매 면접마다 진행하였다. 그 내용에는

• Monolithic Architecture와 Microservices Architecture의 차이
• API Gateway란?
• Service Discovery란?
• Kafka를 왜 쓰는가?
• Saga Pattern이란?
• CQRS와 Event Sourcing이란?

등에 대한 내용들을 처음부터 공부하고 암기하는 것은 쉽지 않았다. 실제로 회사에서 프로젝트 할 때에는 대부분 하나의 시스템을 담당하기에 전체적인 MSA 아키텍처에 대해서 이해하기가 어려웠다. 하지만 실제로 내가 궁금한 것은

“그래서 실제 프로젝트에서는 어디서부터 시작해야 하지?”
“처음부터 서비스를 다 나눠야 하나?”
“API Gateway는 그냥 가져다 쓰면 되는 건가?”
“Kafka는 왜 필요한 순간이 오는 거지?”
“MSA가 좋다고 하는데, 실제로는 뭐가 어려운 거지?”

등에 대한 내용이 오히려 실무적이지 않은가? 프로젝트를 위한 MSA Architecture를 만드는 것이 아닌, 실제 Mini project를 구성해가면서 어떠한 문제 때문에 MSA가 등장하게 되었고, 분리 되어있는 서비스를 위해서 어떠한 기술이 나왔으며 어떻게 해결해가는지를 분석 및 공부해 볼 예정이다.

 

목표

이번 시리즈에서는 Kotlin과 Spring Boot를 사용해서 작은 커머스 시스템을 만들고, 이를 단계적으로 MSA 구조로 발전시켜보려고 한다.

프로젝트 이름은 가볍게 다음처럼 정했다.

Kotlin MSA Commerce

도메인은 Mini Commerce다.

아주 복잡한 쇼핑몰을 만들 생각은 아니다.
대신 MSA에서 자주 만나는 문제를 경험할 수 있을 정도의 기능만 만든다.

초기 도메인은 다음 정도로 잡는다.

회원
상품
주문
결제
알림

처음부터 거대한 시스템을 만들지는 않는다.

먼저 하나의 애플리케이션으로 시작한다.

그리고 기능이 늘어나면서 불편한 점을 직접 겪어본 뒤, 필요한 순간에 하나씩 구조를 바꿔볼 예정이다.

처음부터 MSA로 만들지 않는 이유

MSA를 공부한다고 하면 처음부터 이런 구조를 만들고 싶어진다.

member-service
product-service
order-service
payment-service
notification-service
api-gateway
discovery-server
kafka
redis

하지만 처음부터 이렇게 시작하면 문제가 있다.

• 왜 서비스가 나뉘어야 하는지,
• 왜 API Gateway가 필요한지,
• 왜 Kafka가 필요한지,
• 왜 Service Discovery가 필요한지 제대로 느끼기 어렵다.

그냥 “MSA 예제에서 다들 쓰니까 나도 쓴다”가 되어버릴 수 있다.

나는 이 시리즈를 그렇게 진행하고 싶지 않다.

이 시리즈의 흐름은 다음과 같다.

문제를 먼저 만든다.
불편함을 직접 확인한다.
그 문제를 해결하기 위해 기술을 도입한다.
그리고 그 기술의 한계도 다시 확인한다.

즉, 완성된 정답 구조를 처음부터 만드는 것이 아니라,
문제를 만나면서 구조를 바꿔가는 방식으로 진행한다.

 

최종 목표

 

기술 스택

기술 스택은 다음과 같다.

• Kotlin
• Spring Boot
• Gradle
• Kotlin DSL
• Modular Monolith
• Microservices
• API Gateway
• Load Balancer
• Service Discovery
• Netflix Eureka
• JWT
• Redis, Sentinel
• Kafka
• Saga Pattern
• Outbox Pattern
• Circuit Breaker
• Observability
• CQRS
• Event Sourcing
• gRPC
• Docker Compose

사실 다 다룰 수 있을 지는 잘 모르겠다. 목표는 이렇다.

 

마무리

이 시리즈는 MSA를 완벽하게 설명하는 글이 아니다.

오히려 직접 만들어보면서 시행착오를 기록하는 글에 가깝다.

MSA는 단순히 서비스를 여러 개로 나누는 것이 아니다.

서비스가 나뉘면 배포도 나뉘고, 데이터도 나뉘고, 장애도 나뉜다.
동시에 복잡도도 늘어난다.

그래서 이 시리즈에서는 MSA를 “좋은 아키텍처”로만 보지 않고,
어떤 문제를 해결하기 위해 어떤 복잡도를 감수하는지 하나씩 확인해보려고 한다.

다음 글에서는 본격적으로 프로젝트를 시작한다.

먼저 Kotlin + Spring Boot + Gradle Kotlin DSL 기반의 초기 프로젝트를 만들고,
common 모듈과 commerce-monolith 모듈을 구성해볼 예정이다.

 

다음 글:
Kotlin MSA Commerce - 1. Gradle Kotlin DSL로 프로젝트 시작하기

Kotlin으로 직접 구현하며 배우는 MSA - 1. Gradle Kotlin DSL로 모듈러 모놀리스 시작하기

 

코드 참조

• https://github.com/Kyoungwoong/mini-commerce