MSA를 공부하게 된 계기
전자도서관 개인 프로젝트를 진행하면서 여러 서비스를 조사하고 참고하면서 "마이크로서비스 아키텍처(MSA)"라는 키워드에 관심이 생겼다. 실제로 배달의민족, 쿠팡과 같은 대규모 서비스들이 MSA 기반으로 유연하게 확장되고 있고 실제 업계에서는 어떻게 설계하고 운영하는지 궁금했다! 그 과정에서 기존 모놀리식 구조와 MSA 구조는 어떤 차이가 있고 MSA의 특징은 무엇인지 학습하게 되었다😉
MSA의 정의
MSA는 Microservices Architecture(마이크로서비스 아키텍처)로, 하나의 애플리케이션을 여러 개의 작은서비스로 나누어 개발하고 운영하는 소프트웨어 아키텍처 스타일이다. 예를 들어 배달의 민족서비스라면 가게, 사용자, 비마트 등등 서비스가 나뉘어 있다.
MSA 특징
- 기능을 작고 독립적인 서비스로 분할 (비즈니스 기능 단위로 의미 있게 나눔)
- 각 서비스는 개별 모듈에서 실행되며, 가벼운 방식으로 유연한 통신(Kafka,RabbitMQ 등)
- 자동화 배포 시스템으로 독립적인 배포 가능
- 각 서비스의 언어와 데이터 저장 기술 개별적 사용 가능
- 서비스를 나누는 기준은 기술별이아니라 도메인기준(DDD) 방식으로 설계
MSA vs Monolithic
| MSA | Monolithic | |
| 장점 | - 개별 서비스의 개발이 빨라지며, 유지보수가 용이 - 서비스별 독립 배포 가능 - 각각의 서비스 마다 scale-out 적용(트래픽 증가 시 해당 서비스만 확장) - 서비스 별로 다른 언어나 DB 선택 가능 |
- 구조가 단순하여 테스트 및 디버깅 용이 - 하나의 DB로 데이터를 일관성있게 관리 가능 - 배포나 테스트가 비교적 간단함 - 빠른 MVP 개발에 유리 |
| 단점 | - 개발이 복잡하고 내부 통신 시스템에 대한 고민 필요 - 분산된 DB로 인해 분산 트랜잭션 문제 발생 가능 - 통합 테스트가 어려움 - 로깅,모니터링 등 자동화가 필요함 |
- 전체 scale-out 적용 - 서비스가 강하게 결합되어 수정 시 시간이 오래걸림 - 서비스의 크기가 커질수록 배포시간이 증가함 - 한 서비스의 장애가 전체 서비스의 장애가 됨 |
MSA의 적용하는 이유?
- 기능이 많고 코드 변경시 영향이 가는 범위가 넓어지고 있을 경우
- 일부 서비스만 빠르게 배포 하고 싶을 경우
- 여러 기술 스택을 병행해야 하는 경우
- 팀별로 독립적인 개발과 배포를 해야 하는 경우
- 특정 기능만 확장 할 경우
-> 한마디로 엄청 큰 서비스에서 적용한다!
MSA의 통신 방법
1. 동기 통신(요청-응답방식)
REST API
- 가장 많이 쓰는 방식이며 단순한 통신
- 디버깅 편리
- 서비스 장애 시 전체 흐름 중단
gRPC
- 통신이 빠름
- 다양한 언어를 지원
- 설정이 복잡함
2. 비동기 통신(이벤트 기반)
Kafka
- 대용량 처리에 최적화
- 발행(Publish) → 구독(Subscribe) 구조
- 메시지를 한 번에 여러 소비자에게 전송 가능
- 강력한 확장성
- 중복이나 메시지 유실 주의 필요
RabbitMQ
- 발행자가 메시지를 큐에 전달, 소비자가 순서대로 사용
- 유연한 라우팅
- 대규모 처리에는 kafka 보다 불편함
🔥마지막으로
이번 전자도서관 프로젝트를 진행하면서 프로젝트 규모나 기능만 놓고 보면 MSA를 꼭 적용해야 할 필연적인 상황은 아니었다.
그럼에도 불구하고 내가 MSA와 Kafka를 학습하고 직접 적용해 본 이유는, 실제 업계에서는 이런 구조를 어떻게 활용하는지 직접 경험해보고 싶었기 때문이다. 처음에는 막연히 "결국 모든 프로젝트가 MSA로 가는 거 아닐까?”라는 생각을 했지만, 공부하고 직접 구조를 설계해 보면서 MSA는 무조건이 아니라, 프로젝트 상황에 따라 전략적으로 선택해야 하는 것이라는 결론을 내리게 되었다.
작은 규모의 프로젝트에서는 모놀리식 구조가 훨씬 빠르고 효율적이다. 개발과 배포가 간단하고, 테스트와 디버깅도 쉬워 빠르게 결과를 낼 수 있다. 반대로, 서비스가 커지고 복잡해지면서는 각 기능을 나누고 독립적으로 배포할 수 있는 MSA 구조의 장점이 분명하게 드러난다.
그리고 MSA구조에서 사용하는 다양한 통신 방법이 있다. REST, gRPC, Kafka, RabbitMQ 등 많은 선택지가 있고, 각각의 장단점과 사용 목적이 다르다. 단순한 요청-응답 구조는 REST로도 충분하지만, 여러 서비스가 동시에 반응해야 하거나 비동기 처리가 필요한 경우에는 Kafka와 같은 메시지 기반 통신이 적합하다. 통신 방식도 "무엇이 좋다"가 아니라 "어떤 상황에 맞는지"를 고려해야 하는 문제였다.
이번 학습을 통해 나는 단순히 기술을 사용하는 법만 배운 것이 아니라, "왜 이런 구조가 필요할까?", "어떤 프로젝트에 방식을 적용할지?"를 고민한느 설계의 중요성을 다시 한번 깨달은 것 같다. 앞으로 어떤 시스템을 만들든 기술을 도입하는 이유와 구조의 목적을 먼저 고민하고 그런 고민이 자연스러워져서 좋은 서비스를 만드는 개발자가 되고 싶다.