| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
- MySQL
- tucker의 go 언어 프로그래밍
- CKA
- Java
- 오블완
- docker
- 기록으로 실력을 쌓자
- 티스토리챌린지
- 정보처리기사 실기 기출문제
- LLM
- Rag
- aws
- Spring
- AI
- AWS EKS
- CKA 기출문제
- go
- Network
- CloudWatch
- 코틀린 코루틴의 정석
- SRE
- 공부
- kotlin
- golang
- PETERICA
- 바이브코딩
- kotlin coroutine
- Kubernetes
- minikube
- Claude
- Today
- Total
피터의 개발이야기
[Search] 검색 미들서버 앞에 Gateway가 필요한 이유 - 검색은 검색만 잘하면 된다 본문

TL;DR
검색 미들서버(SMS)의 역할은 좋은 검색 결과를 만드는 것이다.
하지만 실제 서비스에서는 검색과 관계없는 운영 기능이 훨씬 많다.
그래서 대규모 검색 시스템은 SMS 앞단에 Gateway(Reverse Proxy) 를 두고,
요청 분산, 장애 대응, 캐시, 인증 등을 Gateway가 담당하도록 설계한다.
결국 Gateway의 존재 이유는 검색 미들서버가 검색 로직에만 집중하도록 만드는 것이다.
ㅁ 들어가며
어제 회의에서 들었던 검색미들을 위한 Gateway의 역할에 대해서 알게 되었다.
검색 시스템을 처음 접하면서 자연스럽게 이런 생각을 하게 된다.
검색 미들서버가 요청을 받아 검색하고 결과를 돌려주면 되는 것 아닌가?
나 역시 처음에는 그렇게 생각했다.
하지만 실제 서비스에서는 검색보다 운영을 위한 기능이 훨씬 많이 필요하다.
예를 들어 이런 상황을 생각해 보자.
- 검색 서버가 50대라면 어느 서버로 요청을 보낼까?
- 특정 서버가 장애가 나면 어떻게 할까?
- 동일한 검색어는 다시 검색해야 할까?
- 비정상적인 요청은 어떻게 막을까?
- 모든 요청 로그는 어디에서 관리할까?
이런 기능을 모두 검색 미들서버가 담당한다면 검색 로직과 운영 로직이 하나의 시스템 안에 뒤섞이게 된다.
ㅁ 검색 미들서버는 검색만 잘하면 된다
검색 미들서버(SMS)의 가장 중요한 역할은 검색이다.
즉,
- 검색어 분석
- 검색 정책 적용
- 랭킹 계산
- 검색 결과 생성
처럼 검색 품질과 직접 관련된 기능에 집중해야 한다.
반면 운영을 위한 기능은 성격이 전혀 다르다.
- Load Balancing
- Cache
- Authentication
- Rate Limiting
- Retry
- Failover
- Logging
이 기능들은 검색 알고리즘과는 아무런 관련이 없다.
그래서 대규모 서비스는 자연스럽게 역할을 분리하게 된다.
ㅁ Gateway가 맡는 역할
검색 시스템은 보통 다음과 같이 구성된다.

Gateway는 검색과 관계없는 공통 기능을 담당한다.
| Gateway의 역할 | 설명 |
| 요청 분산 | 여러 SMS에 트래픽을 균등하게 분배 |
| 장애 우회 | 장애가 발생한 SMS를 자동 제외 |
| 캐시 | 동일 요청을 재사용하여 응답 속도 향상 |
| 인증 | 사용자 인증 및 권한 확인 |
| 요청 제한 | 과도한 요청 차단 |
| 로그 수집 | 모든 요청과 응답 기록 |
| Retry / Timeout | 네트워크 오류 자동 처리 |
반면 SMS는 검색에만 집중한다.
| SMS의 역할 |
| 검색어 분석 |
| 검색 정책 적용 |
| 랭킹 계산 |
| 검색 결과 생성 |
ㅁ 대표적인 Gateway 오픈소스
Gateway는 특정 제품이 아니라 역할이다.
대표적으로 다음과 같은 오픈소스가 많이 사용된다.
| 프로젝트 | 특징 | 적합한 환경 |
| Envoy | 고성능 L7 Proxy, 동적 라우팅, Observability | Kubernetes, MSA |
| Apache Traffic Server | HTTP Cache와 Reverse Proxy에 특화 | 포털, CDN, 검색 서비스 |
| NGINX | 범용 Reverse Proxy | 대부분의 웹 서비스 |
| HAProxy | 초고성능 Load Balancer | 금융, 대규모 트래픽 |
Envoy

Envoy는 CNCF 프로젝트이며 현재 클라우드 네이티브 환경에서 가장 많이 사용하는 Gateway 중 하나이다.
특히
- Service Discovery
- Retry
- Circuit Breaker
- Observability
기능이 뛰어나 Kubernetes 환경에서 사실상의 표준으로 자리 잡았다.
Apache Traffic Server

Apache Traffic Server(ATS)는 Yahoo!가 개발한 HTTP Reverse Proxy이다.
특히
- HTTP Cache
- 대규모 트래픽 처리
- Reverse Proxy
성능이 뛰어나 CDN과 검색 서비스에서 오랫동안 활용되어 왔다.
검색 시스템에서는 인기 검색어를 캐시하여 검색 미들서버의 부하를 줄이는 데 큰 장점을 가진다.
ㅁ 왜 이렇게 분리할까?
결국 이유는 하나다.
관심사의 분리(Separation of Concerns)
Gateway는
"요청을 안정적으로 전달하는 책임" 을 가진다.
Search Middleware는
"가장 좋은 검색 결과를 만드는 책임" 을 가진다.
각자의 책임이 명확해질수록 시스템은 단순해지고 유지보수는 쉬워진다.
ㅁ 마무리 — 검색 시스템이 커질수록 Gateway의 가치가 커진다
검색 서비스는 규모가 커질수록 검색 알고리즘보다 운영 복잡도가 더 빠르게 증가한다.
이때 Gateway는 검색과 무관한 공통 기능을 모두 흡수하여 검색 미들서버를 단순하게 만든다.
결국 검색 미들서버는 "어떻게 요청을 받을 것인가" 를 고민하는 것이 아니라,
"어떻게 더 좋은 검색 결과를 만들 것인가" 에만 집중할 수 있게 된다.
아마 이것이 대규모 검색 시스템에서 Gateway를 두는 가장 큰 이유일 것이다.
'DevOps' 카테고리의 다른 글
| ContextBase 컨셉정리 (0) | 2026.07.28 |
|---|---|
| [Container] Harbor와 Kaniko는 왜 함께 사용할까? - 이미지는 만들고, 저장하고, 배포한다 (0) | 2026.07.23 |
| [Fluentd] multiline parser, 로그병합과 필터링 (0) | 2025.09.06 |
| [Kibana] Kibana Saved Objects 관리와 백업 (0) | 2025.09.06 |
| 하이브리드 인증서란? RSA와 ECC를 모두 아우르는 인증서 (4) | 2025.08.05 |
