복잡한 세상에서 빠르고 정확한 연결을 만드는 기술
검색은 이제 단순한 기능이 아닙니다. 사용자 경험의 핵심입니다. Uber에서는 수백만 명의 사용자가 음식 배달을 주문하거나 목적지를 검색할 때, 이 검색이 얼마나 빠르고 정확하게 원하는 결과를 제공하느냐가 곧 서비스의 품질을 결정합니다.
그만큼 Uber는 검색 기술에 오랜 시간과 자원을 투자해 왔습니다. 초창기 Elasticsearch 기반의 구조에서 자체 개발한 Sia 엔진을 거쳐, 최근에는 OpenSearch 채택과 오픈소스 커뮤니티와의 협력으로 전략을 전환했습니다.
이 글에서는 Uber가 어떤 문제를 겪었고, 어떤 기술적 선택을 해왔는지를 통해 검색 플랫폼의 설계와 운영에 대한 깊이 있는 인사이트를 나눕니다.
Elasticsearch의 도입과 초기 확장
Uber는 빠르게 성장하는 기업답게, 2010년대 초 Elasticsearch를 도입하여 검색 플랫폼을 구축했습니다.
당시 팀의 주된 관심은 안정성과 운영 효율성이었기 때문에, Elasticsearch를 일종의 '블랙박스'처럼 사용하면서도 안정적인 클러스터 운영을 위해 정기적인 확장과 유지보수에 집중했습니다.
하지만 시간이 지나면서 비즈니스 요구는 단순한 검색 이상의 것을 요구하기 시작했고, Elasticsearch의 한계가 드러나기 시작했습니다. 특히, 실시간성을 요구하는 검색 시나리오에서는 Elasticsearch의 설계 구조가 병목이 되었습니다.
Sia: 실시간성을 위한 Uber 자체 검색 엔진
2019년부터 Uber는 Apache Lucene Core를 확장해 자체 검색 엔진 Sia를 개발하기 시작했습니다.
가장 큰 문제였던 것은 Elasticsearch가 실시간 처리를 지원하지 않는다는 점이었습니다. Lucene은 near-real-time 구조로 설계돼 있어 업데이트 후 바로 검색 가능한 구조가 아니었기 때문입니다.
Sia는 이 문제를 해결하기 위해 Live Index라는 메모리 상의 인덱스 계층을 도입했습니다. 실시간 데이터는 Live Index에 저장되고, 주기적으로 Snapshot Index로 플러시되어 저장됩니다. 이 구조는 메모리 압력을 줄이면서도 최신 데이터를 바로 검색할 수 있게 도와줍니다.
또한, gRPC/Protobuf 통신, Kafka 기반 pull ingestion 모델, 그리고 active-active 아키텍처를 통해 Sia는 확장성과 복원력을 확보했습니다. REST 기반 Elasticsearch보다 효율적인 운영이 가능해졌습니다.
Project Sunrise: 검색 플랫폼 전략의 전환점
하지만 Sia 역시 완벽하지 않았습니다. 실시간성을 위한 BSL(Base/Snapshot/Live) 구조는 새로운 기능을 Lucene에서 도입할 때마다 별도로 재구현해야 하는 부담을 안겨줬습니다.
특히 Lucene의 최신 기능인 벡터 검색, GPU 기반 가속 등 AI 검색 관련 기술들을 적용하기엔 시스템이 너무 복잡해졌고, 관리 비용도 늘었습니다.
Uber는 이 시점에서 전략을 바꿨습니다. 실시간 검색이 꼭 필요한 일부 케이스를 제외하고는 대부분 Lucene의 NRT 구조로도 충분하다는 판단하에, Sia를 유지하기보다는 오픈소스와 함께 가는 방향을 택했습니다.
OpenSearch 도입: 커뮤니티와 함께하는 검색 플랫폼
2024년 Uber는 OpenSearch를 새로운 검색 플랫폼으로 채택했습니다.
선정 과정에서 Uber는 Elasticsearch, Solr 등 다양한 오픈소스 프로젝트를 비교 분석했으며, 최종적으로는 OpenSearch의 확장성, 커뮤니티 지원, 비용 효율성, 오픈 라이선스가 Uber의 니즈와 가장 잘 맞는다고 판단했습니다.
Uber는 OpenSearch Software Foundation의 창립 멤버로 참여하며 기술 커뮤니티의 일원으로서의 역할도 확대하고 있습니다.
LucenePlus와 검색 아키텍처의 최적화
Uber는 Sia에서 얻은 기술적 노하우를 OpenSearch에도 적용하고 있습니다.
예를 들어, Uber Eats의 경우 음식 항목(자식)과 매장(부모)의 관계처럼 계층형 데이터가 많습니다. Lucene은 이런 부모-자식 관계 쿼리에 대해 효율적인 조인 기능을 제공하지 않기 때문에, Uber는 자체적인 데이터 레이아웃과 조인 연산자를 구현했습니다.
이 구조는 메모리 효율성과 쿼리 성능 모두를 고려해 설계되었고, ingest 경로와 검색 경로를 분리해 검색 성능 저하 없이 인덱스를 병합할 수 있도록 했습니다.
또한, OpenSearch API와 호환되는 Search Gateway를 구축하여 내부 구조와 무관하게 클라이언트는 OpenSearch 인터페이스를 그대로 사용할 수 있도록 만들었습니다.
Uber의 사례에서 배울 수 있는 검색 플랫폼 전략
Uber의 검색 플랫폼 진화는 기술적 진보 이상의 의미를 담고 있습니다.
자체 검색 시스템을 개발하고 운영한 경험, 그 과정에서 얻은 성과와 한계, 그리고 다시 오픈소스 커뮤니티와 손을 잡는 전략적 결정은 많은 기업에게 중요한 시사점을 줍니다.
모든 기능을 자체적으로 만드는 것이 능사가 아니며, 중요한 것은 지속 가능하고 확장 가능한 아키텍처를 설계하는 것입니다.
Uber의 접근 방식은 단순한 기술 도입이 아닌, 문제 중심적 사고와 장기적 전략이 결합된 결과입니다. 검색 시스템을 구축하거나 리디자인하려는 기업이라면, Uber의 여정에서 얻을 수 있는 인사이트가 분명히 있을 것입니다.
'잡학다식 > IT 컬럼' 카테고리의 다른 글
| ffmpeg로 비용 33% 절감? OpenAI 음성 트랜스크립션 요금 줄이는 핵심 팁 (0) | 2025.06.27 |
|---|---|
| Zed 디버거, 왜 개발자들이 주목하는가? (0) | 2025.06.20 |
| 영어로 코딩하는 시대? Karpathy가 말하는 'Software 3.0'의 미래 (0) | 2025.06.20 |
| ESLint보다 100배 빠른 린터, Oxlint 1.0 출시! 성능과 실용성 모두 잡았다 (0) | 2025.06.18 |
| IDE는 죽지 않았다. 다만, AI가 그 자리를 넘보고 있다: Agentic AI가 바꾸는 개발의 미래 (0) | 2025.06.18 |
