Route vs Microservice

2026. 1. 7. 17:34Spring Microservice/API Gateway

🚦 Spring Cloud Gateway에서 Route와 Microservice의 관계

― “Route는 서비스가 아니라, 서비스로 가는 출입 명부다”

Spring Cloud Gateway(SCG)를 학습하다 보면 거의 반드시 마주치는 질문이 있습니다.

“Route 하나가 곧 마이크로서비스 하나 아닌가요?”

이 질문은 아주 정확하고, 동시에 아키텍처의 본질을 찌르는 질문입니다.
결론부터 말씀드리면 다음과 같이 정리하는 것이 가장 정확합니다.

Route는 마이크로서비스 그 자체는 아니다.
✅ 하지만 마이크로서비스로 들어가는 ‘논리적인 이정표’이자 ‘출입 명부’다.

이 쳅터에서는 Route와 Microservice의 관계를 구조적으로 정리해 보겠습니다. 🧠✨

1️⃣ Route vs Microservice — 개념적 차이부터 명확히

🧩 Microservice란?

  • 실제로 비즈니스 로직을 수행하는 주체
  • 독립적으로 배포되고 실행되는 실체(Entity)
  • 보통 여러 개의 인스턴스로 확장 가능

📌 예시
Order Service
→ 주문 생성, 조회, 결제 검증 등의 로직 수행
→ 실제 서버 프로세스 (컨테이너, JVM, Pod 등)

🧭 Route란?

  • Gateway 내부에 존재하는 설정 단위(Configuration Unit)
  • “이 요청이 오면 → 검사하고 → 어디로 보낼지”를 정의한 규칙 집합

Route는 다음 3가지를 정의합니다.

Predicate → Filter → Destination(uri)

즉,

🧠 Route는 ‘행동 주체’가 아니라 ‘판단 규칙’입니다.

2️⃣ 왜 “Route = Microservice”라고 단정하면 안 될까?

가장 중요한 이유는 이것입니다.

하나의 마이크로서비스에 여러 개의 Route가 매핑될 수 있기 때문입니다.

🧪 예시: Order Service는 하나, Route는 여러 개

🔹 Route A — 일반 사용자용 API

Predicate: /api/orders/**
Filter: 없음
Destination: lb://ORDER-SERVICE

🔹 Route B — 관리자 전용 API (보안 강화)

Predicate: /admin/orders/**
Filter:
  - IP 화이트리스트
  - 관리자 권한 검증
Destination: lb://ORDER-SERVICE

🔹 Route C — 구버전 API 호환

Predicate: /v1/orders/**
Filter:
  - Path Rewrite (/v1/orders → /api/orders)
Destination: lb://ORDER-SERVICE

📌 핵심 포인트

  • 💼 서비스는 하나
  • 🚪 진입로(Route)는 목적·보안·버전별로 여러 개

즉,
물리적 서비스 구조와 API 외부 설계는 분리되어 있습니다.

3️⃣ “Route가 서비스를 가리키는 것처럼 보이는 이유”

Route 설정을 보면 항상 uri가 등장합니다.

uri: lb://ORDER-SERVICE

이 때문에 자연스럽게 이런 착각이 생깁니다.

🤔 “Route가 곧 서비스 아닌가요?”

하지만 uri서비스 그 자체가 아니라 ‘목적지 정보’일 뿐입니다.

🔗 Route의 uri가 가리키는 대상

🧱 정적 라우팅

uri: http://192.168.0.10:8080

→ 특정 서버 주소 직접 지정

🔄 동적 라우팅 (Service Discovery)

uri: lb://ORDER-SERVICE

→ Eureka / Consul 등에 등록된 서비스 그룹

📌 즉,

Route는
“이 요청을 어디로 보낼지 결정하는 마지막 네비게이션 정보”를 담고 있을 뿐입니다.

4️⃣ 한 문장으로 정리해 보면

비유로 정리하면 아주 명확해집니다. 🎯

개념 비유
🧑‍💼 Microservice 실제로 일하는 직원
📘 Route 안내 데스크에 있는 매뉴얼

“이 손님은 이 Route 매뉴얼에 해당하니까,
👉 검사(Filter) 좀 하고
👉 저기 Order Service 직원한테 보내!”

이것이 Spring Cloud Gateway의 핵심 사고방식입니다. 🧠🚦

✨ 마무리 요약

Route ≠ Microservice
✅ Route는 논리적 진입로, Microservice는 실제 실행 주체
✅ 하나의 서비스에 여러 Route를 매핑할 수 있음
✅ 이를 통해 보안, 버전 관리, API 구조를 유연하게 설계 가능

'Spring Microservice > API Gateway' 카테고리의 다른 글

Spring Cloud Gateway Reactive 라이프사이클  (0) 2026.01.07
Filter  (0) 2026.01.07
Predicate  (0) 2026.01.07
Load Balancer 스키마  (0) 2026.01.07
Route  (0) 2026.01.07