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

마이크로서비스 아키텍처란

마이크로서비스 아키텍처(Microservices Architecture) 는 하나의 시스템을 여러 독립 서비스로 나누고, 각 서비스가 자체 배포와 확장을 할 수 있도록 경계를 설계하는 방식입니다.¹

이 문서는 시스템 설계 관점에서 왜 서비스를 분리하는지, 언제 마이크로서비스가 필요한지, 어떤 대가가 따르는지를 설명합니다.
서비스 메시, gRPC, 배포 파이프라인 같은 구현·운영 상세는 마이크로서비스 아키텍처, gRPC, 서비스 메시 문서가 더 직접적인 심화 자료입니다.

핵심은 서비스를 작게 자르는 것 자체가 아니라 독립적으로 바꾸고 확장할 수 있는 경계를 찾는 것입니다.

모놀리식과 마이크로서비스 비교

시스템 설계 면접에서는 보통 마이크로서비스를 단독으로 묻기보다, 왜 모놀리식이 아닌가까지 함께 묻습니다.

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

중요한 점은 “마이크로서비스가 더 현대적이라서 좋다”가 아니라, 복잡성을 어디에 둘지 선택하는 문제라는 점입니다.

모놀리식이 잘 맞는 경우:

도메인이 아직 단순함
팀 규모가 작음
배포 속도와 운영 단순성이 더 중요함

마이크로서비스가 잘 맞는 경우:

도메인 경계가 비교적 분명함
서비스별 트래픽 패턴이 다름
팀이 서비스 소유권을 나눠 가져야 함

서비스를 나누는 기준

마이크로서비스 설계에서 가장 중요한 질문은 어디서 자를 것인가입니다.

보통 다음 기준을 같이 봅니다.

도메인 경계: 주문, 결제, 재고, 알림처럼 비즈니스 책임이 다른가
변경 빈도: 자주 바뀌는 기능과 안정된 기능이 분리되는가
확장 패턴: 트래픽이 유독 큰 기능이 따로 있는가
장애 격리: 특정 기능 장애를 다른 기능에서 분리할 필요가 있는가
팀 소유권: 담당 조직이 실제로 분리 운영 가능한가

좋지 않은 분리 예시는 다음과 같습니다.

기술 계층만 기준으로 자르기
같은 데이터에 강하게 묶인 기능을 억지로 분리하기
팀은 하나인데 서비스만 여러 개로 쪼개기

좋은 분리는 보통 도메인 경계와 팀 경계가 어느 정도 맞물릴 때 나옵니다.

즉, 마이크로서비스는 기술 패턴이 아니라 조직과 도메인 모델을 시스템 구조에 반영하는 선택에 가깝습니다.

데이터 분리와 팀 경계

마이크로서비스를 설명할 때 자주 나오는 핵심 질문은 “DB를 같이 써도 되는가”입니다.

원칙적으로는 서비스가 자기 데이터를 소유하는 구조가 더 자연스럽습니다.

이유는 다음과 같습니다.

서비스 독립 배포가 쉬워짐
다른 서비스의 스키마 변경에 덜 묶임
경계가 명확해져 책임 소재가 분명해짐

하지만 데이터 분리는 항상 공짜가 아닙니다.

cross-service join이 어려워짐
트랜잭션을 한 번에 묶기 어려워짐
결국 이벤트나 비동기 동기화가 필요해짐

선택	장점	주의점
공유 DB	초기 구현이 빠르고 단순함	경계가 무너지고 독립성이 약해짐
서비스별 DB	독립 배포와 책임 분리가 쉬움	일관성과 조회 조합이 복잡해짐

그래서 면접에서는 “무조건 DB를 분리한다”보다, 초기에는 공유 DB로 시작할 수 있지만 서비스 경계를 강화하려면 결국 데이터 소유권도 분리해야 한다는 흐름이 더 현실적입니다.

서비스 간 통신과 결합도

서비스를 나누면 통신 방식도 설계해야 합니다.

대표 선택지는 다음과 같습니다.

동기 호출: REST, gRPC
비동기 통신: 메시지 큐, 이벤트 스트림

동기 호출이 잘 맞는 경우:

즉시 응답이 필요한 요청
일관된 사용자 흐름이 중요한 경우

비동기 통신이 잘 맞는 경우:

알림, 분석, 후처리처럼 지연 허용이 가능한 경우
서비스 간 결합도를 낮추고 싶을 때
spike를 버퍼링하고 싶을 때

하지만 서비스 간 통신이 많아질수록 다음 문제가 따라옵니다.

타임아웃과 재시도 폭주
장애 전파
관측성 부족
데이터 최신성 불일치

관련 구현 상세는 마이크로서비스 아키텍처, gRPC, 메시징 시스템, 서비스 메시 문서와 함께 보면 더 좋습니다.

언제 도입할까

마이크로서비스는 보통 처음부터 정답으로 선택하기보다, 모놀리식으로 버티기 어려운 이유가 분명할 때 도입하는 경우가 많습니다.

도입 신호는 보통 다음과 같습니다.

특정 기능만 독립적으로 자주 배포해야 함
트래픽이 일부 기능에만 집중됨
팀이 커져서 코드베이스 소유권 충돌이 심해짐
장애가 전체 시스템으로 번지는 문제가 반복됨

반대로 아직 늦추는 편이 나은 경우도 많습니다.

팀이 작고 도메인이 단순함
테스트와 배포 자동화가 약함
데이터 경계가 아직 명확하지 않음
운영 인력이 분산 복잡도를 감당하기 어려움

또한 전환은 한 번에 전부 옮기기보다, 병목이 큰 도메인부터 점진적으로 분리하는 Strangler Fig 식 접근이 현실적인 경우가 많습니다.

즉, 마이크로서비스는 “규모가 커 보인다”는 이유로 도입하기보다, 배포 경계, 조직 경계, 확장 패턴이 실제로 갈라졌을 때 도입하는 편이 더 안전합니다.

마이크로서비스의 트레이드오프

장점: 독립 배포, 선택적 확장, 장애 격리, 팀 자율성을 얻을 수 있습니다.
단점: 분산 시스템 복잡도, 데이터 일관성 문제, 테스트·관측성 비용이 커집니다.
주의점: 서비스 수를 늘리는 것보다 경계를 잘못 잡는 것이 더 큰 문제입니다.

특히 다음 오해를 피해야 합니다.

마이크로서비스를 도입하면 자동으로 확장성이 생기는 것은 아님
서비스 수가 많을수록 더 좋은 구조라는 뜻은 아님
기술 자유도가 높아지면 운영 표준화 비용도 함께 커짐

좋은 답변은 “MSA가 좋다”가 아니라, 왜 지금 이 조직과 도메인에 독립 경계가 필요한지, 그 대가를 감당할 준비가 되었는지를 말하는 답변입니다.²

면접 포인트

마이크로서비스의 핵심은 작은 서비스가 아니라 독립 배포 가능한 경계입니다.
모놀리식과 마이크로서비스는 우열 관계보다 복잡성을 어디에 둘지에 대한 선택입니다.
서비스 분리는 도메인 경계, 팀 경계, 확장 패턴이 함께 맞을 때 효과가 큽니다.
DB 분리는 독립성에 유리하지만 일관성과 조회 조합이 더 어려워집니다.
좋은 답변은 도입 시점과 운영 대가까지 같이 설명합니다.