MSA & MFA

Joowon Jang·2025년 3월 25일

MSA(Micro Service Architecture)

MSA: 하나의 애플리케이션을 작고 독립적인 서비스 단위들로 나누어 구성하는 소프트웨어 아키텍처 스타일 (반대되는 구조는 모놀리식(Monolithic)이라고 함)
각 서비스는 고유한 기능을 가지며, 서로 독립적으로 배포·확장·개발·운영될 수 있도록 설계한다.

예를 들어 전자상거래 플랫폼을 만든다고 가정하면 다음과 같은 마이크로서비스로 분리할 수 있음.

사용자 서비스 (회원 가입, 로그인)
상품 서비스 (상품 등록, 검색)
주문 서비스 (장바구니, 주문)
결제 서비스 (결제 처리)
알림 서비스 (이메일, 문자 알림)

각 서비스는 별도 DB와 API를 가지며 REST, gRPC, Kafka 등으로 통신한다.

마이크로 서비스 아키텍처

이미지 출처: https://www.cuelogic.com/blog/microservices-with-node-js

MSA의 장점

서비스 간 결합이 느슨하여 하나의 서비스를 변경할 때, 다른 서비스에 미치는 영향이 적음
서비스별로 배포했을 때, 하나의 서비스가 죽어도 다른 서비스는 이용 가능
대규모 프로젝트에서 각 서비스를 팀별로 병렬 개발이 쉬움
하나의 서비스(유저인증 등)를 여러 도메인에서 접근 가능
(ex - 네이버에 한 번 로그인하면 네이버 쇼핑, 블로그 등의 서비스로 이동하여도 로그인한 정보로 모든 서비스 이용가능)
서비스마다 다른 기술 스택 사용 가능 (언어, 라이브러리, 프레임워크 등)
단일 서비스 단위로 테스트할 수 있어, 테스트 속도 및 안정성 증가

MSA의 단점

서로 DB가 분리되어 있어, 다른 서비스의 데이터가 필요할 때 통신이 복잡해지고, 통신 비용이 증가
각 서비스가 자기 DB를 가지므로 분산 트랜잭션이 발생하여, 데이터 일관성 관리가 어려움
단일 서비스 테스트는 쉽지만, 서비스 간 연동 테스트가 복잡함
서비스마다 배포 파이프라인을 별도로 운영해야 하므로 DevOps 역량 필수
높은 기술 난이도로 인한 러닝커브가 증가 (설계부터 배포, 장애 대응까지 학습할 내용이 많음)
API Gateway, 인증 서버 등 보안 인프라 설계가 중요

위의 장단점은 밑에서 설명할 모놀리식 구조와 비교했을 때라고 할 수 있음

모놀리식(Monolithic) vs MSA

모놀리식?

MSA 방식을 적용하지 않은 아키텍처라면 대부분 모놀리식이라고 할 수 있을 것 같다.
모놀리식이란, 하나의 큰 애플리케이션을 하나의 코드베이스에서 실행하는 구조라고 볼 수 있다.
회원가입/로그인, 상품 구매, 게시판 등의 기능을 모두 하나의 프로젝트에서 개발하고 데이터베이스도 하나로 구성되는 경우가 많다.

각 방식은 어떤 경우에 적용해야 좋을까?

✔️ 모놀리식이 유리한 경우

스타트업 또는 초기 서비스
팀 규모가 작고 빠르게 MVP(Minimum Viable Product)를 만들어야 할 때
배포 환경이 단순한 경우
트래픽이나 기능 규모가 작은 경우

✔️ MSA가 유리한 경우

서비스가 빠르게 성장하고, 트래픽이 많을 때
독립적인 팀이 여러 개 있을 때
특정 서비스만 자주 변경하거나 확장할 필요가 있을 때
장애 격리와 빠른 복구가 중요한 경우

프로젝트 초기에는 모놀리식으로 구현 후, 서비스가 안정되고 확장하는 단계에서 검토 후 필요에 따라 MSA로 점진적으로 전환하는 방식을 사용하면 좋을 것 같다!

요약(GPT가 정리해준 모놀리식과 MSA 비교)

항목 🧱 모놀리식 (Monolithic Architecture) 🧩 마이크로서비스 (Microservices Architecture)
구조 모든 기능이 하나의 애플리케이션에 통합됨 기능별로 작은 서비스로 분리
개발 속도 초기 개발이 빠름 (한 곳에서 개발) 처음에는 느릴 수 있음 (서비스 분리, 인프라 구축 필요)
배포 전체 시스템을 한 번에 배포 개별 서비스만 선택적으로 배포 가능
확장성 전체 시스템을 같이 확장해야 함 (비효율적) 특정 서비스만 독립적으로 확장 가능 (효율적)
유지보수 규모가 커질수록 코드가 복잡해짐 서비스 단위로 유지보수 용이
팀 규모 적합도 소규모 팀에 적합 대규모 팀 또는 조직에 적합
의존성 관리 모듈 간 의존성이 꼬이기 쉬움 각 서비스는 독립적으로 동작 (loose coupling)
장애 격리 하나의 장애가 전체 시스템에 영향 줄 수 있음 서비스 간 장애가 분리되어 영향도 낮음
기술 선택 자유도 전체 시스템이 동일 스택이어야 함 서비스마다 다른 언어나 프레임워크 사용 가능
테스트 용이성 통합 테스트 쉬움 서비스별 통합 테스트와 환경 설정이 복잡
트랜잭션 처리 단일 DB 사용 시 ACID 보장 쉬움 분산 트랜잭션 어려움 (SAGA 패턴 필요)
운영 및 모니터링 단일 서버, 단순 모니터링 서비스 수가 많아 복잡한 운영 및 모니터링 필요
CI/CD 파이프라인 단일 파이프라인 구축 쉬움 각 서비스별 파이프라인이 필요함

항목	🧱 모놀리식 (Monolithic Architecture)	🧩 마이크로서비스 (Microservices Architecture)
구조	모든 기능이 하나의 애플리케이션에 통합됨	기능별로 작은 서비스로 분리
개발 속도	초기 개발이 빠름 (한 곳에서 개발)	처음에는 느릴 수 있음 (서비스 분리, 인프라 구축 필요)
배포	전체 시스템을 한 번에 배포	개별 서비스만 선택적으로 배포 가능
확장성	전체 시스템을 같이 확장해야 함 (비효율적)	특정 서비스만 독립적으로 확장 가능 (효율적)
유지보수	규모가 커질수록 코드가 복잡해짐	서비스 단위로 유지보수 용이
팀 규모 적합도	소규모 팀에 적합	대규모 팀 또는 조직에 적합
의존성 관리	모듈 간 의존성이 꼬이기 쉬움	각 서비스는 독립적으로 동작 (loose coupling)
장애 격리	하나의 장애가 전체 시스템에 영향 줄 수 있음	서비스 간 장애가 분리되어 영향도 낮음
기술 선택 자유도	전체 시스템이 동일 스택이어야 함	서비스마다 다른 언어나 프레임워크 사용 가능
테스트 용이성	통합 테스트 쉬움	서비스별 통합 테스트와 환경 설정이 복잡
트랜잭션 처리	단일 DB 사용 시 ACID 보장 쉬움	분산 트랜잭션 어려움 (SAGA 패턴 필요)
운영 및 모니터링	단일 서버, 단순 모니터링	서비스 수가 많아 복잡한 운영 및 모니터링 필요
CI/CD 파이프라인	단일 파이프라인 구축 쉬움	각 서비스별 파이프라인이 필요함