일단 이번 포스팅에서 API Gateway와 그 외의 기술 스택을 제대로 선정하고 진행할 계획이다.

확정된 기술은 다음과 같으며

MSA 기반이므로 각 서비스의 기술 스택 확정
Spring Boot → User/Auth, Product, Order, Cart 서비스
MySQL → 관계형 데이터 저장
Redis → 로그인 토큰 캐싱

아래의 기술은 조금 더 선별하는 과정이 필요하다.

Kafka or RabbitMQ → 주문 상태 변경 이벤트 처리 고려
Docker & Kubernetes → 서비스 배포 고려
API Gateway 필요 여부 검토 (ex: Spring Cloud Gateway, Kong API Gateway)
CI/CD 파이프라인 구성 고려 (ex: GitHub Actions, Jenkins)

Kafka or RabbitMQ

일단 MSA 구조에서 해당 기술 스택이 필요한 이유는 다음과 같다.

• 주문이 생성되거나 상태가 변경될 때(확인됨, 배송 중, 완료됨 등) 다른 서비스(예: 결제, 알림, 배송)와 비동기적으로 이벤트를 주고받아야 함.
• 비동기 메시징을 통해 서비스 간 결합도를 낮추고 확장성을 높일 수 있음.

표를 통해 살펴보면 각 스택은 이러한 특징을 가지고 있다.

비교 항목	Kafka	RabbitMQ
아키텍처	분산 로그 기반의 스트리밍 플랫폼	메시지 큐 기반의 브로커
메시지 처리	높은 처리량, 로그 리텐션이 가능	낮은 지연 시간, 빠른 메시지 전달
데이터 영속성	메시지를 로그에 저장하여 내구성이 뛰어남	메시지를 소비하면 삭제됨 (옵션 조정 가능)
사용 사례	주문 트래킹, 실시간 분석, 로그 처리	주문 생성, 결제 완료, 재고 감소 등 이벤트 큐

일단 대용량 처리나 로그 분석, 트래킹이나 스트리밍의 기능이 MVP 단계에서 필요하지 않기 때문에 Kafka 자체는 오버엔지니어링이라 보여질 수 있다.

• RabbitMQ → 주문 생성/취소 이벤트, 재고 업데이트 등의 메시징 용도
• Kafka → 실시간 로그 분석 또는 주문 상태 스트리밍이 필요하다면 고려

따라서 MVP에서는 RabbitMQ 먼저 적용 후, 필요 시 Kafka 확장

Docker & Kubernetes

MSA 구조는 각 서비스가 독립적으로 배포되어야 하는 구조이기 때문에
환경 일관성을 유지하고, 운영 효율성을 높이기 위해 컨테이너 기반 배포 필요하다.

비교 항목	Docker Compose	Kubernetes (K8s)
사용 목적	로컬 개발, 작은 규모의 서비스 배포	대규모 서비스 운영 및 오케스트레이션
오토스케일링	X (수동 확장 필요)	O (자동 확장 가능)
장애 복구	X (컨테이너 죽으면 직접 재시작)	O (자동 복구)
로드 밸런싱	X (수동 설정 필요)	O (내장 로드 밸런서 제공)
운영 복잡도	쉬움	어렵지만 강력함

Docker Compose로 MVP 배포 후 Kubernetes 확장은 나중에 고려

API Gateway 필요 여부

MSA에서는 여러 개의 서비스가 각각 API를 노출하기 때문에 API Gateway가 있으면 인증, 로드 밸런싱, CORS, API 버전 관리 등을 중앙에서 처리 가능하다.

또한 API Gateway 없이 클라이언트가 모든 서비스에 직접 요청하면 관리가 복잡해지고, 보안 리스크 증가할 수 있다.

그럼 어떤 API Gateway 옵션이 존재할까

비교 항목	Spring Cloud Gateway	Kong API Gateway
특징	Spring 기반, 마이크로서비스 친화적	Nginx 기반, 성능 최적화
확장성	Spring Boot 프로젝트와 자연스럽게 통합	플러그인으로 기능 확장 가능
OAuth/JWT 지원	O	O
로드 밸런싱	O	O
운영 복잡도	Spring 경험이 있으면 쉬움	설정이 복잡할 수 있음

다행?이도 Spring Cloud Gateway라는게 존재하고 Spring Boot 환경과 자연스럽게 통합이 가능한 API Gateway가 존재한다.

다만 트래픽이 많아질수록 Kong이 고려되는 경우도 있다고 한다.

MVP 단계에서는 Spring Cloud Gateway 사용 후, 트래픽 증가 시 Kong으로 확장 고려

CI/CD

비교 항목	GitHub Actions	Jenkins
설치 필요 여부	X (클라우드 제공)	O (서버 직접 운영 필요)
확장성	적은 설정으로 사용 가능	복잡하지만 강력한 기능 제공
커뮤니티 지원	GitHub과 통합, 빠른 업데이트	기업에서 많이 사용하지만 유지보수 필요
비용	무료 (기본 사용량)	인프라 유지 비용 발생

Jenkins는 기업에서 많이 사용하는 엔터프라이즈급 CI/CD를 구축할 때 필요하다.

MVP 단계에서는 GitHub Actions을 당연히 사용해보겠지만
고도화 단계에서도 Jenkins는 고려해봐야 할 것 같다.

너무 MVP만 생각하는거 아닌가..?

위에서 정리한 내용을 보면 너무 MVP위주로 상대적으로 규모가 작은 스택만을 선별했다고 볼 수 있는데,
개발을 하면서 적절한 기술 스택을 선정하는 것 역시 중요하다고 생각한다.

뿐만 아니라 내가 여기서 사용해본 기술이 몇 개 되지 않는 점 역시 존재하기 때문에
MVP 에서 실제 서비스가 가능한 프로젝트로 바꾼다 하여도 결국에는 다 경험을 해봐야 하는 스택들이다.

이렇게 기술 스택을 고민하면 캠프를 진행할때 이따금씩 튜터님들이 말씀해주셨던 내용이 생각이 난다.기술 스택을 정해서 하나만 확 파보는 것이 취업에 더 도움이 될 수 있다는 내용이다.

물론 최근 공고를 봐도 해당 기술스택을 해본게 아닌 경험이 많은 사람을 찾는 내용도 많지만 다양한 기술을 사용하는 공고도 많이 보인다.

MVP를 만들고 고도화 시키는게 조금 번거롭다고 생각되기도 하고, MVP만 만들고 제풀에 꺾일 수 있겠지만 그래도 나는 가능하면 많은 스택을 경험해보는 것도 중요하다고 생각된다.