마이크로서비스 아키텍처 (Microservices Architecture, MSA)

마이크로서비스란

마이크로서비스 아키텍처(MSA) 는 하나의 애플리케이션을 여러 개의 작고 독립적인 서비스로 나누어 개발, 배포, 운영하는 방식입니다. 널리 알려진 설명에서도, 각 서비스가 독립 프로세스로 실행되고 가벼운 통신 메커니즘으로 상호작용한다는 점이 핵심으로 강조됩니다.¹

핵심은 단순히 서비스를 잘게 쪼개는 것이 아니라, 독립적으로 바꾸고 배포할 수 있는 경계를 만드는 것입니다.

왜 마이크로서비스를 선택하는가

배포 독립성: 전체 애플리케이션이 아니라 특정 서비스만 배포할 수 있습니다.
확장 분리: 검색, 결제, 알림처럼 트래픽이 다른 기능을 따로 확장할 수 있습니다.
팀 자율성: 팀별로 서비스 소유권을 나누기 쉽습니다.
기술 선택 자유: 서비스별로 언어, 저장소, 프레임워크를 다르게 가져갈 수 있습니다.

하지만 이 장점들은 조직과 도메인이 받쳐줄 때 의미가 있습니다. 규모가 작으면 오히려 복잡성만 늘 수 있습니다.

모놀리식과의 차이

항목	모놀리식	마이크로서비스
배포 단위	애플리케이션 전체	서비스별
확장 방식	보통 전체를 함께 확장	필요한 서비스만 확장
장애 범위	잘못 설계하면 전체 영향	일부 서비스로 격리 가능
데이터 관리	보통 하나의 DB 공유	서비스별 DB 분리 지향
운영 복잡도	상대적으로 낮음	분산 시스템 복잡도 큼

중요한 점은 “마이크로서비스가 모놀리식보다 항상 더 좋다”가 아니라,
복잡성을 어디에 둘지 선택하는 문제라는 것입니다.

핵심 설계 원칙

비즈니스 경계 중심 분리: 기술 계층보다 도메인 경계가 더 중요합니다.¹
독립 배포 가능성: 같은 릴리스 타이밍에 묶여 있으면 서비스 분리 효과가 줄어듭니다.
데이터 분리: 각 서비스가 자기 데이터를 소유하는 구조가 기본입니다.²
경량 통신: REST, gRPC, 메시징 같은 단순한 통신 메커니즘을 사용합니다.
관측성 확보: 로그, 메트릭, 트레이스가 없으면 운영이 급격히 어려워집니다.

특히 데이터베이스 공유 여부는 면접에서 자주 묻는 포인트입니다.
DB를 공유하면 경계가 무너지기 쉬워서 서비스 독립성이 약해집니다.²

장점

서비스별 독립 배포
독립 스케일링
장애 격리 가능성
팀 구조와 도메인 경계 정렬
기술 선택 유연성

이 장점은 모두 “경계를 잘 잡았을 때”에만 제대로 나옵니다.

한계와 운영 비용

분산 시스템 복잡도: 네트워크 지연, 타임아웃, 재시도, 부분 실패를 다뤄야 합니다.
데이터 일관성 문제: 글로벌 트랜잭션 대신 eventual consistency와 보상 로직이 필요할 수 있습니다.
테스트 난이도: 통합 테스트와 계약 테스트가 중요해집니다.
운영 부담: 배포 파이프라인, 서비스 디스커버리, 모니터링, 로깅 체계가 필요합니다.
조직 비용: 팀이 작거나 도메인이 단순하면 분리 이점보다 비용이 더 큽니다.

그래서 “MSA를 도입하면 확장성이 생긴다”보다,
운영 복잡성을 감당할 체계가 있어야 한다고 답하는 편이 더 현실적입니다.

도입 시 고려할 점

경계가 진짜 독립적인가
팀이 서비스 소유권을 감당할 수 있는가
DB를 분리할 수 있는가
동기 호출이 너무 많아지지 않는가
관측성과 배포 자동화가 준비되어 있는가

실무에서는 보통 다음 전략이 많이 나옵니다.

모놀리식으로 시작
병목이 크거나 팀 경계가 분명한 도메인부터 분리
API 게이트웨이, 메시징, 관측성 도구를 함께 도입

면접 포인트

마이크로서비스의 핵심은 작은 서비스보다 독립 배포 가능한 경계입니다.
모놀리식보다 무조건 좋다고 말하면 안 되고, 분산 시스템 복잡도가 대가로 따라온다고 설명해야 합니다.
서비스별 DB 분리, eventual consistency, 관측성이 핵심 운영 포인트입니다.
장점은 배포 독립성과 확장 분리, 단점은 운영/데이터/테스트 복잡도입니다.
초기에는 모놀리식이 더 나은 경우가 많다는 점도 같이 말하면 답변이 현실적입니다.