MSA

왜 배우는가: MSA는 클라우드 전환과 함께 국내 기업의 시스템 구조 표준으로 자리 잡아 실무 설계·전환 판단에서 자주 마주친다. 정보관리기술사 시험에서도 1교시 용어와 4교시 논술(모놀리스 비교, 서비스 메시)로 반복 출제되므로 정의와 원리를 정확히 익혀야 한다.

출제 이력: 제127회 4교시 1번, 제117회 1교시 6번

1. 한 줄 정의와 핵심 키워드

마이크로서비스 아키텍처(MSA)는 하나의 애플리케이션을 업무 기능 단위의 독립 배포 가능한 작은 서비스들로 나누고, 경량 프로토콜로 협력하게 하는 소프트웨어 구조 방식이다.

• 마이크로서비스 아키텍처(MSA)
• 독립 배포
• 업무 기능 단위 분할
• 경량 통신(REST·gRPC·메시징)
• 서비스별 데이터 소유
• 장애 격리
• 서비스 메시
• 바운디드 컨텍스트

2. 개념 풀이

쉽게 말하면 큰 프로그램 하나를 작은 프로그램 여러 개로 잘라 각각 따로 만들고, 따로 올리고, 따로 늘리는 방식이다. 주문, 결제, 재고처럼 업무 기능마다 서비스를 두고 서로 요청을 주고받는다.

정식 정의는 다음과 같다. 마이크로서비스는 비즈니스 기능을 중심으로 나뉜 소규모 서비스들의 집합이며, 각 서비스는 자체 프로세스에서 실행되고 자율적으로 개발·배포·확장된다. 서비스 간 통신은 HTTP 같은 기술 중립적 프로토콜이나 메시지 전달로 이루어진다. 공식적으로 합의된 단일 정의는 아직 없으며, 특징들을 기준으로 설명하는 것이 일반적이다.

이 구조에서 서비스 자율성은 각 서비스가 다른 서비스의 내부 구현과 무관하게 변경·운영될 수 있음을 뜻한다. 바운디드 컨텍스트(Bounded Context)는 도메인 모델이 일관되게 유효한 경계로, 도메인 주도 설계(DDD)에서 서비스 경계를 정하는 기준으로 쓰인다. 보통 바운디드 컨텍스트 하나가 서비스 하나에 대응하지만, 상황에 따라 일대다 또는 다대일로 매핑할 수 있다.

다언어(Polyglot) 특성도 중요하다. 서비스마다 최적의 프로그래밍 언어, 데이터베이스, 실행 환경을 고를 수 있다. 다만 이는 자유를 주는 동시에 운영 기술 종류를 늘리는 비용이기도 하다.

3. 등장 배경과 필요성

기존 모놀리스 구조는 하나의 단위로 개발되고 하나의 프로세스에서 실행된다. 작은 변경에도 전체를 다시 빌드하고 배포해야 하며, 확장도 기능별이 아니라 애플리케이션 전체를 복제하는 방식으로만 가능하다. 사용량이 늘면 데이터베이스가 하나로 통합되어 있어 탄력적으로 대응하기 어렵고, 결국 스케일업으로 용량을 미리 키워야 했다.

이 한계를 줄이려는 흐름에서 MSA가 나왔다. 서비스를 기능별로 나누면 변경과 배포의 영향 범위가 줄고, 트래픽이 몰리는 기능만 골라 늘릴 수 있다. 또 서비스마다 저장소가 달라 업무 단위의 모듈 경계가 확고해진다. 클라우드와 컨테이너 기술이 보급되면서 서비스를 작게 나누어 운영하는 비용이 낮아진 것도 확산의 배경이다.

여기에 지속적 배포(CI/CD)와 데브옵스(DevOps) 문화가 함께 자리 잡았다. 잦은 소규모 출시를 안전하게 하려면 서비스 경계가 명확해야 하므로, MSA는 조직 구조와 기술 구조를 함께 바꾸는 방식으로 이해해야 한다.

이 배경을 이해하면 MSA가 만능이 아님도 알 수 있다. 서비스가 많아지면 서비스 간 호출 지연, 분산 트랜잭션, 관찰성 문제가 새로 생긴다. 시험에서는 장점과 함께 이 비용을 같이 서술해야 점수를 받는다.