도구 목록처럼 보이는 마이크로서비스 로드맵을 “왜 이게 필요해졌는지” 관점으로 재정리해보았습니다. 컨테이너·오케스트레이션·API 게이트웨이·메시징을 훑되, 실제 성공/실패를 가르는 서비스 경계(바운디드 컨텍스트)와 데이터 소유권까지 함께 가져가실 수 있게 정리합니다.
로드맵 한 장으로 보는 마이크로서비스의 흐름
원본 로드맵은 대체로 아래 순서의 “플랫폼 구성요소”를 제시합니다.
- 표준 패키징: 컨테이너(Docker 등)로 서비스를 동일한 형태로 배포 가능하게 만든다.
- 클러스터 운영: 오케스트레이션(Kubernetes/Swarm/OpenShift)으로 배포·확장·복구·네트워킹을 자동화한다.
- 동적 환경의 탐색: 서비스 디스커버리(Consul/Eureka/Zookeeper)로 “어디에 떠 있는지”를 찾는다.
- 단일 진입점: API Gateway(Kong/Ocelot/Mulesoft 등)로 라우팅·인증·레이트리밋 같은 공통 관심사를 수렴한다.
- 서비스 간 통신: 비동기 메시징(Kafka/RabbitMQ)으로 결합도를 낮추고 확장성을 얻는다.
이 로드맵의 장점은 “MSA를 운영 가능한 형태로 만들기 위해 필요한 것”을 빠짐없이 보여준다는 점입니다. 다만 댓글 관점에서 지적되듯, 도구를 먼저 도입하면 복잡도/지연/병목이 먼저 늘어날 수 있고, 오히려 경계 안정화·관측성·복원력 같은 운영 역량이 더 중요하다는 논쟁도 함께 따라옵니다.
1) Core Foundation: 서비스 + 컨테이너(표준 패키징)
컨테이너는 “MSA의 목표”가 아니라 배포 단위를 표준화하는 수단입니다. 서비스가 늘어날수록 운영 환경(라이브러리/런타임/설정)이 제각각이면 배포가 곧 리스크가 되기 때문입니다.
- 컨테이너가 주는 실익
- 실행 환경 일관성(“내 PC에선 됐는데…” 제거)
- 이미지 버전 = 배포 버전(릴리스 추적이 쉬움)
- 스케일 아웃을 위한 최소 전제 마련
간단 예시(Dockerfile):
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY build/libs/order-service.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
이 단계에서 중요한 포인트는 “컨테이너를 만들었다”가 아니라, 서비스가 독립 배포 가능한 형태로 패키징되었는가입니다. (여기서부터 이미 ‘경계’ 문제가 시작됩니다.)
2) Orchestration: Kubernetes가 해결하는 것과, 늘리는 것
오케스트레이션은 컨테이너가 많아졌을 때 생기는 운영 문제를 다룹니다.
- 배포(롤링 업데이트), 확장(HPA), 복구(헬스체크 기반 재기동)
- 서비스 네트워킹/로드밸런싱
- 설정/시크릿/스토리지 등 운영 리소스 관리
하지만 동시에 복잡도도 올립니다.
- 장애 지점이 “애플리케이션”에서 “클러스터+네트워크+설정”까지 확대
- 러닝 커브(리소스, 오브젝트, 네트워킹 모델)
- 잘못 설계된 서비스 경계는 Kubernetes로 숨길 수 없음(오히려 더 빨리 드러남)
제 경험상 Kubernetes 도입 여부보다 더 앞에 오는 질문은 이겁니다.
“우리는 배포 단위를 늘릴 준비(관측성/온콜/자동화)가 되어 있나?”
3) Service Discovery: “주소”가 아니라 “관계”가 문제다
동적 환경에서 서비스의 IP/포트는 계속 바뀝니다. 그래서 서비스는 “고정 주소”가 아니라 **이름(논리적 ID)**로 서로를 찾아야 하고, 이를 위해 Consul/Eureka 같은 디스커버리 패턴이 등장합니다.
다만 실무에서는 “찾는다”보다 더 큰 문제가 “얼마나 자주, 얼마나 깊게 서로 호출하나”입니다.
- 서비스가 지나치게 잘게 쪼개지면: 디스커버리는 되지만 연쇄 호출 + 지연 + 장애 전파가 커집니다.
- 즉, 디스커버리는 운영 기능이고, 근본 원인은 경계/의존성 설계인 경우가 많습니다.
4) API Gateway: 공통 기능의 수렴점이자 병목 후보
API Gateway는 외부 클라이언트(웹/앱/파트너) 입장에서 서비스가 많아져도 “하나의 진입점”을 제공해줍니다.
- 라우팅(경로 기반, 헤더 기반)
- 인증/인가(JWT, OAuth2), TLS
- Rate limit, WAF, 로깅/트레이싱 연계
- 버전 관리, API 정책
하지만 댓글의 비판처럼 게이트웨이는 잘못 쓰면 다음을 초래합니다.
- 추가 지연(latency): 요청이 한 홉 더 늘어남
- 중앙 병목/단일 장애 지점: 확장/고가용성 설계 없으면 위험
- “모든 로직이 게이트웨이에 몰림”: 정책과 도메인 로직의 경계가 무너지기 쉬움
따라서 게이트웨이는 “MSA 필수템”이라기보다, 외부 트래픽의 공통 관심사가 임계점을 넘었을 때 도입하는 것이 비용 대비 효과가 좋았습니다.
5) Messaging: 비동기로 얻는 확장성과, 결과적 일관성의 비용
Kafka/RabbitMQ 같은 메시징은 마이크로서비스의 핵심 축으로 자주 언급됩니다. 이유는 단순합니다.
- 동기 HTTP 호출 체인을 줄여 결합도/장애 전파를 낮춤
- 트래픽 스파이크를 버퍼링(소비자 확장)
- 이벤트 기반으로 다른 팀/서비스가 독립적으로 기능을 확장
예시: “주문 생성” 이벤트 발행(의사 코드)
// OrderService
public void createOrder(CreateOrderCommand cmd) {
Order order = orderRepository.save(Order.create(cmd));
eventBus.publish("order.created", new OrderCreatedEvent(order.getId(), order.getTotalPrice()));
}
이벤트 기반으로 가면 자연스럽게 CQRS/이벤트 소싱 같은 방법론과 “결”이 맞닿습니다. 다만 대가는 명확합니다.
- 결과적 일관성(eventual consistency) 수용
- 중복 처리, 재처리(idempotency), 순서 보장, DLQ 설계
- “이벤트 스키마 = 계약”이므로 버전 관리가 필요
메시징은 만능이 아니라, 팀/서비스 간 변경 전파를 어떻게 운영할지에 대한 선택입니다.
도구보다 먼저: 서비스 경계/데이터 소유권을 확정하는 현실적인 기준
대화에서 가장 중요한 질문은 이것이었습니다.
Kubernetes나 API Gateway 같은 도구 도입보다 먼저 “서비스 경계/데이터 소유권”을 확정하려면 어떤 기준과 절차가 효과적인가?
저는 여기서 **Conway’s Law(콘웨이 법칙)**을 실무적 체크리스트로 자주 씁니다.
- 콘웨이 법칙: “시스템을 설계하는 조직은 그 조직의 커뮤니케이션 구조를 닮은 설계를 만들 수밖에 없다.”
- 즉, 도메인/제품별 팀(주문팀, 결제팀…)으로 나뉘어 있다면 서비스도 그 경계를 닮아야 조율 비용이 줄고 독립 배포가 가능해집니다.
경계 확정에 도움이 되는 3가지 질문
- 누가 이 기능의 “변경”을 가장 자주 일으키는가?
- 변경이 잦은 책임을 한 팀이 end-to-end로 소유하면 경계가 안정화됩니다.
- 데이터의 진짜 소유자는 누구인가? (CRUD가 아니라 책임 기준)
- “주문 상태”의 최종 진실(source of truth)은 주문팀이 가져가야 합니다.
- 다른 팀은 조회/파생 데이터는 가질 수 있어도, 원장을 공유 테이블로 섞는 순간 경계가 무너집니다.
- 업무 흐름이 여러 도메인을 횡단할 때, 동기 호출로 엮을 것인가 이벤트로 풀 것인가?
- 주문 → 결제 → 정산처럼 횡단 흐름이 길수록 동기 체인은 취약합니다.
- 이벤트로 풀면 결합은 낮아지지만, 결과적 일관성과 운영 복잡도를 감당해야 합니다.
절차(제가 추천하는 최소 프로세스)
- (1) 도메인 이벤트 후보를 먼저 적습니다:
order.created,payment.authorized같은 형태 - (2) 이벤트를 “발행하는 팀”과 “소비하는 팀”을 매핑합니다
- (3) 이벤트의 source of truth(소유권)를 확정하고, 타 팀은 구독/캐시/읽기 모델로 가져가게 합니다
- (4) 이 경계가 팀 구조와 맞지 않으면(승인 라인/온콜 책임이 다르면) “역 콘웨이 전략”으로 조직/책임을 조정합니다
이 흐름이 잡히면, 컨테이너/오케스트레이션/게이트웨이/메시징 같은 도구는 “필요한 만큼” 자연스럽게 따라오고, 반대로 경계가 없으면 어떤 도구를 얹어도 복잡도만 먼저 상승합니다.
마무리
마이크로서비스 로드맵은 “무엇을 도입할까” 체크리스트처럼 보이지만, 실제로는 서비스 경계와 데이터 소유권을 어떻게 정할 것인가가 성공을 좌우합니다. 저는 도구 선택 전에, 팀 구조(콘웨이 법칙)와 도메인 이벤트를 기준으로 경계를 먼저 그어보는 접근이 가장 비용 대비 효과가 좋았습니다.
