AWS에서 AI 에이전트를 위한 서버리스 멀티 백엔드 웹 검색 서비스 구축하기

서론

작은 규모부터 더 복잡한 에이전트 아키텍처(agentic architectures)에 이르기까지, 에이전트(agents)는 어디에나 존재합니다. 더 많은 팀이 AI 기반(AI-powered) 솔루션을 구축함에 따라, 웹 검색은 최신 정보에 접근하고, 사실을 검증하며, 외부 컨텍스트를 수집하는 데 있어 필수적인 역량이 되고 있습니다.

이 글에서는 제가 PostNL에서 어떻게 서버리스(serverless) 멀티 백엔드 웹 검색 서비스를 구축했는지 설명하겠습니다. 이는 단일 검색 백엔드에서 시작하여 AWS 상에서 중앙 집중화된(centralized), 제공자 불가지론적(provider-agnostic) 서비스로 진화할 수 있는 기반을 만드는 과정입니다.

공유 역량으로서의 웹 검색이 필요한 이유

단일 앱을 위해 검색 제공자(search provider)를 통합하는 것은 비교적 간단하지만, LLM(대규모 언어 모델)이 이미 알고 있는 것 이상의 정보에 접근해야 하는 에이전트를 여러 팀이 구축하기 시작하면 문제는 더욱 흥미로워집니다.

만약 각 팀이 웹 검색 서비스를 독립적으로 구현할 자유를 갖게 된다면, 이는 **파편화(fragmentation)**로 이어질 수 있습니다. 서로 다른 제공자, 서로 다른 API, 일부는 공개 웹 검색 API에 의존하고, 서로 다른 비용 모델을 사용하는 등의 문제가 발생합니다.

이 시점에서 웹 검색은 더 이상 단순한 애플리케이션 기능이 아니라, **공유 역량(shared capability)**이 됩니다. 중앙 집중화된 웹 검색 서비스를 제공하면 팀은 **일관된 인터페이스(consistent interface)**를 사용할 수 있는 동시에, 플랫폼 소유자는 비용, 운영 및 향후 제공자 선택을 한 곳에서 관리할 수 있습니다.

중앙 집중화된 웹 검색 서비스 설계

PostNL에서 _AI Center of Excellence (AI CoE)_는 조직 전반의 팀들이 AI 솔루션을 채택하고 확장할 수 있도록 지원합니다. 더 많은 팀이 AI 에이전트를 실험하기 시작하면서, 웹 검색 서비스의 필요성이 명확해졌습니다.

특정 제공자를 권장하는 대신, 우리는 **플랫폼 지향적 솔루션(platform-oriented solution)**에 집중하기로 결정했습니다. 우리의 목표는 팀들이 쉽게 사용할 수 있는 단일 웹 검색 역량을 제공하는 동시에, 기반이 되는 검색 구현을 유연하고 교체 가능하게(replaceable) 유지하는 것이었습니다.

처음부터 우리는 몇 가지 핵심 설계 원칙을 정의했습니다:

모든 소비자(consumers)를 위한 단일 인터페이스;
다중 검색 백엔드(search backends) 지원;
낮은 운영 오버헤드(operational overhead);
비용 효율적인 운영;
소비자에게 영향을 주지 않고 진화할 수 있는 능력;

이러한 원칙들은 AI 애플리케이션과 하위 웹 검색 제공업체 사이에 위치하는 **경량 라우팅 계층(lightweight routing layer)**을 중심으로 하는 아키텍처로 이어졌습니다.

왜 소비자에게 백엔드는 중요하지 않은가

설계에서 아마도 가장 중요한 측면은 소비자가 하위 웹 검색 제공업체와 직접 상호작용하지 않는다는 점입니다.

모든 요청이 라우팅 계층을 통해 흐르기 때문에, 백엔드는 서비스를 사용하는 애플리케이션과 독립적으로 진화할 수 있습니다. 오늘은 라우터가 기본 검색 백엔드로 요청을 전달하지만, 내일은 트래픽을 추가 제공업체로 라우팅하거나, 페일오버(failover) 정책을 적용하거나, 비용, 지리적 위치 또는 최신성 요구 사항을 기반으로 라우팅 결정을 내릴 수도 있습니다.

초기 아키텍처

서비스는 프라이빗 API Gateway를 통해 노출되어, 네트워크 내의 권한이 있는 소비자만이 VPC 엔드포인트(VPC endpoint)를 통해 접근할 수 있도록 보장합니다.
요청은 클라이언트와 하위 검색 백엔드 사이의 추상화 계층 역할을 하는 경량 **Lambda 기반 라우터(Lambda-based router)**로 라우팅됩니다.
초기 백엔드는 내부 Application Load Balancer 뒤에서 ECS Fargate로 실행되는 자체 호스팅된 SearXNG 배포판으로, 아키텍처를 향후 제공업체에 대해 유연하게 유지하면서 확장 가능하고 중앙에서 관리되는 웹 검색 기능을 제공합니다.

라우터 구축하기

라우터는 시스템의 **중심 구성 요소(central component)**입니다. 이는 소비자에게 영향을 주지 않으면서 향후 백엔드 변경을 가능하게 합니다.

전체적인 흐름은 다음과 같이 고정되어 있습니다:

API Gateway로부터 요청 수신
기본 백엔드로 요청 전달
백엔드로부터 응답 반환
필요한 경우 기본적인 요청 유효성 검사 (Validation) 수행

Router는 포트 및 어댑터 (ports and adapters)라고도 알려진 **육각형 아키텍처 (hexagonal architecture)**를 따릅니다. 애플리케이션 코어 (core)는 웹 검색 동작과 인터페이스를 정의하며, API Gateway 이벤트, HTTP 클라이언트, 프로바이더별 통합과 같은 인프라 관련 사항은 어댑터 (adapters)로 구현됩니다.

이를 통해 코어 로직을 특정 백엔드로부터 독립적으로 유지할 수 있습니다. 현재 Router는 SearXNG로 요청을 전달합니다. 향후에는 공개 API를 변경하거나 소비자에게 영향을 주지 않고도 다른 프로바이더를 위한 추가적인 **어댑터 (adapters)**를 도입할 수 있습니다.

런타임 (Runtime) 선택

런타임으로는 Go를 선택했습니다. Router는 대부분 가벼운 HTTP 오케스트레이션 (orchestration) 컴포넌트이기 때문입니다. Router는 무거운 연산을 수행하지 않습니다. 대신 요청을 유효성 검사하고, 라우팅 로직을 적용하며, 백엔드를 호출하고 응답을 반환합니다.

Go는 다음과 같은 특징을 제공하므로 이러한 유형의 워크로드에 적합합니다:

빠른 시작 시간 (Startup times)
낮은 메모리 사용량
표준 라이브러리의 강력한 HTTP 지원
단순한 동시성 프리미티브 (concurrency primitives)
작은 Lambda 바이너리로의 용이한 배포

Lambda를 선택한 이유

운영 부담 (operational footprint)을 최소화하기 위해 AWS Lambda를 선택했습니다. Router는 장시간 실행되는 인프라, 로컬 상태(local state), 또는 복잡한 런타임 관리가 필요하지 않습니다. **상태를 유지하지 않음 (stateless)**으로써 요청 볼륨이 변화함에 따라 Lambda가 수평적으로 확장(scale horizontally)될 수 있도록 합니다.

언뜻 보기에 요청 경로(request path)에 Lambda 기반의 라우터(router)를 도입하는 것은, 특히 여러 애플리케이션에서 소비될 수 있는 서비스의 경우 **확장성 문제 (scalability concerns)**를 일으킬 수 있습니다. 하지만 이 라우터는 요청 검증(validation), 라우팅(routing), 그리고 프로토콜 변환(protocol translation)만을 수행하도록 의도적으로 경량화되어 있습니다. 이 컴포넌트를 상태를 유지하지 않는(stateless) 상태로 유지하고 검색 실행보다는 오케스트레이션(orchestration)에 집중하게 함으로써, Lambda는 낮은 지연 시간(low latency)을 유지하면서도 운영 오버헤드를 최소화하며 자동 확장(automatic scaling)을 제공합니다.

이러한 **분리 (separation)**를 통해 현재는 라우터를 단순하게 유지하면서도, 향후 라우팅 정책(routing policies), 폴백 로직(fallback logic), 서킷 브레이커(circuit breakers), 그리고 추가적인 백엔드 어댑터(backend adapters)를 통해 발전할 수 있도록 합니다.

오픈 소스 웹 검색 백엔드 배포하기

라우터(Router) 계층을 구축한 후, 다음 결정 사항은 초기 검색 백엔드를 선택하는 것이었습니다.

상용 (commercial) 웹 검색 제공업체를 즉시 통합하는 대신, 우리는 자체 호스팅(self-hosted)이 가능하고 실험하기 쉬우며 향후 교체 가능한 솔루션을 원했습니다.

MVP(Minimum Viable Product)를 위해, 우리는 오픈 소스 메타 검색 엔진인 SearXNG를 선택했습니다.

왜 SearXNG인가요?

요구 사항	SearXNG
자체 호스팅 (Self-hosted)	✅
...

SearXNG는 ECS Fargate에서 컨테이너화된 서비스(containerized service)로 실행되며, Application Load Balancer를 통해 내부적으로 노출됩니다. 이 워크로드(workload)의 경우, ECS Fargate는 프로덕션 준비가 된 배포(production-ready deployment)를 위한 가장 간단한 경로를 제공했습니다.

서비스 사용하기

서비스가 프라이빗 API Gateway를 통해 노출되므로, PostNL의 팀들은 인증(authentication), 할당량(quotas), 사용량 추적(usage tracking)이 중앙에서 처리되는 **표준 HTTP 인터페이스 (standard HTTP interface)**를 통해 서비스를 사용할 수 있습니다. 이는 도입 및 사용 패턴에 대한 명확한 가시성을 제공하는 동시에, 더 많은 팀이 합류함에 따라 플랫폼을 일관되게 관리(governed)할 수 있도록 보장합니다.

이 플랫폼은 의도적으로 **검색 검색 (search retrieval)**에 집중합니다. 응답은 백엔드에서 반환된 검색 결과로 구성되며, LLM (Large Language Model)에 의해 해석되거나 요약되지 않습니다. 모든 추론이나 답변 생성은 이를 사용하는 애플리케이션의 책임으로 남습니다.

멀티 백엔드 미래를 위한 준비

초기 구현은 단일 백엔드에 의존하지만, 이 서비스는 처음부터 여러 검색 제공업체(search providers)를 지원하도록 설계되었습니다. 라우터(Router)는 헥사고날 아키텍처 (hexagonal architecture)를 따르며, 여기서 애플리케이션 코어는 잘 정의된 포트(ports)와 어댑터(adapters)를 통해 백엔드별 구현으로부터 독립적으로 유지됩니다.

잠재적인 향후 개선 사항은 다음과 같습니다:

추가적인 검색 제공업체
제공업체 장애 조치 (failover) 및 폴백 (fallback) 메커니즘
상태 기반 라우팅 (Health-based routing)
쿼리별 라우팅 정책
구성 가능한 제공업체 선택

초기에 추상화 계층 (abstraction layer)에 투자함으로써, 이 서비스는 유연성을 유지하며 요구 사항이 변경됨에 따라 점진적으로 진화할 수 있는 동시에, 사용자에게 안정적인 인터페이스를 지속적으로 제공할 수 있습니다.

결론

AI 에이전트가 더욱 보편화됨에 따라, 웹 검색과 같은 기능은 개별 애플리케이션에서 공유 기능으로 점점 더 이동하고 있습니다. 일관된 인터페이스 뒤로 웹 검색을 중앙 집중화함으로써, 팀은 검색 제공업체를 통합하고 운영하는 대신 솔루션을 구축하는 데 집중할 수 있습니다.

특정 기술과 제공업체는 시간이 지남에 따라 진화하겠지만, 근본적인 원칙은 동일합니다. **공통 기능 (common capabilities)**은 한 번 제공되어 여러 곳에서 소비될 때 가장 가치 있는 경우가 많습니다.