Week 14
기간: 2026.02.16 - 2026.02.20
커리큘럼: Server(MSA)
1. Facts — 무엇을 했나?
< Server(MSA) >
- [Spring] MSA 아키텍쳐(Microservice Architecture)
모놀리식과 MSA의 차이를 비교하고, 주문 시스템(회원·상품·주문)을 예로 들어 MSA에서 서비스가 독립적으로 실행·배포되는 구조를 정리했다. - [Spring] SPRING CLOUD MSA 핵심요소
Spring Cloud Gateway의 단일 진입점·라우팅·로드밸런싱 역할과, Eureka를 활용한 서비스 디스커버리 등 MSA 핵심 구성요소를 정리했다. - [Spring] order-service 실습 : MSA 아키텍처 변경
order-system 모놀리식 구조를 api-gateway, eureka, member, product, ordering 서비스로 분리하고, 불필요한 의존성(RabbitMQ, Security 등)과 config 파일을 제거하는 과정을 정리했다.
2. Feelings — 어떻게 느꼈나?
- 모놀리식으로 한 프로젝트에 다 넣었던 코드를 서비스별로 쪼개보니, 각 서비스가 독립적으로 돌아가는 게 신기하면서도 구조적으로 훨씬 깔끔하다고 느꼈다.
- Spring Cloud Gateway가 모든 요청의 단일 진입점 역할을 하는 걸 직접 설정해보니, 프록시·라우팅의 흐름이 머릿속에 확 잡혔다.
- Eureka에 서비스가 등록되고 자동으로 디스커버리되는 과정을 보면서, 수동으로 IP/포트를 관리하던 것보다 훨씬 유연하다는 걸 실감했다.
- 불필요한 의존성(RabbitMQ, Security 등)을 제거하는 과정에서 각 서비스에 정말 필요한 것만 남기는 게 MSA의 핵심이라는 걸 체감했다.
3. Findings — 무엇을 배웠나?
-
모놀리식 vs MSA 아키텍처:
- 모놀리식은 하나의 애플리케이션에 모든 기능이 포함되어 배포·확장이 일괄적이고, MSA는 서비스별로 독립적 배포·확장이 가능함.
- 주문 시스템에서 회원·상품·주문을 각각의 서비스로 분리하면 장애 격리와 팀 단위 운영이 가능함.
-
Spring Cloud 핵심 구성요소:
- Spring Cloud Gateway는 단일 진입점으로 라우팅과 로드밸런싱을 담당하고, Eureka는 서비스 등록·디스커버리를 처리함.
- 각 마이크로서비스는 Eureka에 자신을 등록하고, Gateway가 이를 기반으로 요청을 적절한 서비스로 라우팅함.
-
모놀리식 → MSA 전환 실습:
- 기존 order-system을 api-gateway, eureka, member, product, ordering 5개 서비스로 분리함.
- 서비스별로 불필요한 의존성(RabbitMQ, Spring Security 등)과 config 파일을 제거해 각 서비스의 경량화를 진행함.
4. Future — 다음에 어떻게 활용할까?
- 서비스 간 통신에 FeignClient를 적용해 REST 호출을 선언적으로 처리하고, 장애 시 Circuit Breaker(Resilience4j) 패턴 도입하기.
- Spring Cloud Config Server로 각 서비스의 설정 파일을 중앙 관리해 환경별(dev/prod) 설정 분리 자동화하기.
- Eureka 기반 서비스 디스커버리에 헬스체크 커스터마이징을 추가해 비정상 인스턴스 자동 제거 로직 구현하기.
- Gateway에 Rate Limiting, 인증 필터 등을 추가해 API 보안과 트래픽 제어 경험 쌓기.
- Docker Compose로 각 마이크로서비스를 컨테이너화해 로컬 환경에서 전체 MSA 시스템을 한 번에 띄우는 환경 구축하기.
🧩 마무리 한 줄
모놀리식에서 MSA로의 전환을 직접 경험하면서, Spring Cloud Gateway·Eureka를 중심으로 서비스 분리와 독립 배포의 이점을 체감한 한 주였다.
Eazy하게