AI 시대 클라우드에서 검색 활용

14 min readJul 2, 2024

디지털서비스 이슈리포트 2024–06호

이 글은 제가 NIA [한국지능정보사회진흥원]의 < 디지털서비스 이슈리포트 > 2024년 6월호에 기고한 글입니다. 원본 글 ‘AI 시대 클라우드에서 검색 활용’을 이곳 브런치에서도 공유합니다.

들어가며

지난 2024년 5월 말에는 구글의 검색 알고리듬이 유출되었다는 뉴스로 관련 업계가 들썩였었다. (https://searchengineland.com/how-seo-moves-forward-google-leak-442749 , https://searchengineland.com/google-search-document-leak-ranking-442617 ) 2024년 3월 13일 구글 API 콘텐츠 웨어하우스(Google API Content Warehouse)에서 가져온 것으로 보이는 수천 개의 문서가 자동화 봇에 의해 깃허브 공개 리포지토리에 올라왔다. 이 문서들은 구글의 순위 알고리듬이 어떻게 작동하는지에 대한 요소가 담겨있는 것으로 알려졌는데. 문서에는 2,596개 모듈, 14,014개 속성에 관한 기술이 있고, 검색 결과 순위에서 고려되는 요소에 관한 내용을 기술하고 있었다.

어떤 요소가 어떤 가중치를 지니고 있는지에 대한 구체적인 내용은 기술하고 있지 않았고, 구글이 웹사이트에서 수집하고 있는 세부 정보들을 표시하고 있었다. 사용자의 클릭을 중요하게 본다는 점, 크롬 브라우저의 사용 행태를 보면서 웹 페이지의 유명세를 반영한다는 점, 트위들러(twiddler)라고 불리는 여러 랭킹 로직이 여러 복잡한 방식으로 병렬적으로 작용한다는 점 등이 알려졌고, 이 유출된 내용을 통해서 구글 검색이 실제로 어떻게 작동하는가에 대한 매우 중요한 정보가 다시 공유되었다.

이 내용들이 그동안 구글이 공개적으로 언급한 내용과 모순된다는 의견들도 있지만, 20년 넘게 서비스한 내용 중에 불변하는 규칙이 있을 수 없고, 한편 이 내용 중 몇 가지 원칙에 해당하는 내용에 대해서는 그동안 구글이 중립적인 입장에서 사용자의 만족을 위해 최선을 다해 왔다는 것에 대한 반증이라 할 수 있겠다. 공개적인 인터넷 세상의 정보들을 모아 정리하고 사용자에게 보여주는 행동을 우리는 그동안 검색이라 불러왔고, 이를 유지하기 위해서는 데이터를 모으는 일부터 불필요한 내용을 미리 없애는 일, 사용자가 좋아하는 것을 다시 랭킹의 규칙으로 사용하는 등, 큰 노력이 필요해 왔고, 구글은 지금까지 충실하게 이를 수행하고 있다는 점을 알게 해 주었다.

이 유출 사건 이후 구글의 검색엔진최적화(SEO)를 이용해 왔던 많은 업체는 자신들의 페이지가 잘 발견되는지, 마케팅 전략에 차질은 없는지 여러 노력을 다시 정비하기 시작했고, 이는 AI 시대에 또 어떤 전략으로 안팎을 정리해야 하는지를 화두에 올려 놓았다. 이 글에서는 ‘검색’이라는 기능이 클라우드 환경에서 어떤 의미를 지니고 있고, AI 시대를 맞이해서 어떤 변화를 겪고 있는지, 어떤 미래가 예상되는지에 대해 정리해 본다.

클라우드에서 검색의 활용

검색이라는 용어 자체는 ‘정보를 찾는 과정’’ 이라는 뜻이지만, 클라우드 서비스를 이용하는 업체들의 시각에서는 다양한 의미로 쓰이고 있으며, 필요한 기능을 구현하기 위해 다양한 솔루션을 사용해 왔다. 클라우드를 사용하는 업체 시각에서 검색 기능을 위해 어떤 SaaS 솔루션들을 쓰고 있는지 대략 살펴보도록 하겠다.

내부 자료 저장과 검색

먼저 규모가 작은 서비스를 운영하는 경우 데이터베이스를 사용함에 있어서 검색은 주로 필터링의 용도로 사용했고, 원하는 데이터를 꺼내어 쓰는 것을 기본으로 생각할 수 있겠다. 문자열을 이용한 검색 기능이 없는 게시판 류의 서비스를 생각할 경우 원하는 항목은 고유 식별자로 직접 조회 가능하고, 범위를 제한함으로써 원하는 검색 기능이 동작한다.

이 때 SQL 의 LIKE 문구를 이용해서 위와 같이 기본적인 검색을 구현할 수도 있으나, 이 경우 매번 테이블 전체를 훑어서 비교해야 하는 부담이 커지게 되고, 테이블의 크기에 비례해서 시스템이 느려 지는 등 다른 사용자들에게 영향을 주게 되므로 별도의 검색 시스템을 이용해서 이를 해결해야 한다. 이 때 사용할 수 있는 대표적인 검색 엔진 솔루션들을 아래에 간단히 나열한다.

Elasticsearch

분산형 RESTful 검색 및 분석 엔진, 실시간 전문 검색과 분석 기능
로그, 메트릭, 보안 이벤트 분석에 강점, Kibana, Logstash와 함께 ELK 스택 구성

Apache Solr, Lucene:

오픈 소스 검색 플랫폼
풍부한 쿼리 언어와 다양한 플러그인, 대규모 분산 환경에서 안정적

Amazon CloudSearch:

AWS의 관리형 검색 서비스, AWS 서비스와의 원활한 통합
자동 스케일링과 고가용성

Azure Cognitive Search:

마이크로소프트 AI 기반 검색 서비스, Azure 생태계와의 통합
자연어 처리와 이미지 분석 기능

Algolia

호스팅된 검색 서비스
빠른 설정과 쉬운 관리

오픈소스라도 쿠버네티스를 이용해서 설치형으로 운영할 수도 있고, 클라우드에서 매니지드로 운영하는 서비스를 이용할 경우 더 높은 사용성을 보장받을 수도 있다. 색인으로 넣을 데이터의 양, 색인의 개수, 예상 조회 수 등의 변수를 고려해서 각 회사의 솔루션에 맞는 것을 결정하기를 바라고, 검색 기능이 제품 전체의 어느 부분에 어떤 영향을 미치는지로부터 시작하기를 권한다.

외부 자료 검색

서비스를 운영함에 있어 외부의 웹검색을 이용하는 사례들이 종종 있다. 먼저 실제 서비스를 사용함에 있어 사용자가 보는 내용을 풍부하게 하는 용도로 웹검색을 사용하기도 하는데, 업데이트가 자주 일어나는 경우 검색엔진의 품질 관리 기준을 따르는 게 나은 경우 이를 이용하기도 한다. 다만 이 경우는 사용자가 무엇을 보게 될 것인지 서비스 운영자가 모르기에 저품질의 내용이나 원하지 않는 내용이 보이게 될 경우 서비스 전체의 품질에 영향을 줄 수 있다.

외부의 사이트를 정해 놓고 전체를 크롤해 놓고 사용하는 경우가 아니고서는 서비스에 필요한 내용을 생성할 때 — 예를 들면 게시판이 만들어지거나 리뷰가 생성될 때 — 필요한 내용들을 모으는 용도로 검색 엔진을 이용하기도 한다. 서비스에 필요한 내용을 생성하거나 색인을 만들 때 사용하게 되므로 실제 보게 될 내용들보다 더 많은 호출을 하게 될 수도 있지만, 반대로 실제 서비스에서는 한 번 만들어 놓은 정보들이 유통 될 것이기에 책임 있는 방식으로 캐쉬 등의 효율화도 기대할 수 있다.

아래는 API의 형태로 사용되는 서비스들을 간단히 나열한다.

구글 프로그래머블 검색 엔진 (이전의 맞춤 검색 엔진):

구글의 검색 기술을 활용한 맞춤형 검색 엔진
특정 웹사이트나 웹 페이지 그룹을 대상으로 검색 가능

빙 웹 검색 API:

마이크로소프트 빙 검색 엔진을 기반으로 한 웹 검색 API, 애저 코그니티브 서비스의 일부
웹 페이지, 이미지, 뉴스 등 다양한 유형의 검색 결과 제공

덕덕고(DuckDuckGo) API:

프라이버시 중심의 검색 엔진 덕덕고의 API

SerpApi:

구글, 빙, 바이두 등 여러 검색 엔진 결과를 제공
다양한 프로그래밍 언어를 위한 라이브러리 제공

위키피디아 API

위키피디아를 키워드 검색 가능
사용 예: https://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=Albert%20Einstein&format=json

이 서비스들은 클라우드 외부에 별도의 서비스 형태로 제공되는 경우가 대부분이고, 아래 내용을 고려해야 한다.

검색 범위 (전체 웹 vs 특정 사이트)
제공되는 데이터의 유형 (웹 페이지, 이미지, 뉴스 등)
API 호출 한도 및 비용
응답 속도 및 결과의 정확도
개인정보 보호 및 데이터 사용 정책

그밖의 검색 사용들

지금까지 검색은 서비스에서 검색 기능이 직접적으로 필요한 경우에 해당되지만, 개발 생산성과 데이터 분석의 영역에서 검색은 이미 모두가 자연스럽게 하고 있던 영역의 일이라 하겠다.

대표적으로 관찰 가능성(observability)이라 불리는 영역인데, 시스템 상태를 모니터링하고 정리하는 영역에서 필요한 로그를 저장, 분석, 필요시 조회를 지원하고 문제가 생겼을 경우 로그를 찾는 영역에서 검색이 많이 쓰여 왔다. 일반 사용자들이 필요에 의해 문서의 일부 혹은 전부를 찾아 다니는 서비스와 다르게, 개발과 운영의 경우 평상시에는 사용자들의 행동들 혹은 데이터 처리되는 상태들을 저장하고, 이상이 생기는 경우에 경고 등의 방법과 함께 열람을 가능하게 하는 기능들을 수행하는데 이용된다. 개발자 혹은 운영팀의 편의를 위해 다양한 기능들이 지원되기도 하고, 아래의 SaaS 가 사용 가능하다.

Elasticsearch, Logstash, Kibana (ELK Stack)

3개의 다른 서비스, Elasticsearch는 검색 담당.
실시간 로그 분석, 시각화 도구

프로메테우스(Prometheus), 그라파나(Grafana)

로그 관리 및 분석 솔루션
오픈 소스 시계열 데이터베이스 및 모니터링 도구

데이터독(Datadog)

클라우드 기반 모니터링 및 로그 관리 플랫폼
온프레미스 지원, 다른 디버깅 도구들과의 통합 관리

스플렁크(Splunk)

상용 데이터 수집, 검색, 분석 및 시각화 도구
다양한 데이터 소스와 통합하고 보안 정보 및 이벤트 관리(SIEM) 기능도 지원

AI 시대 검색의 재발견

RAG — 벡터 데이터베이스

LLM 으로 대변되는 AI 시대에 검색증강생성(RAG: Retrieval-Augmented Generation)은 정보를 찾고 구성하는 새로운 방식으로 자리잡고 있으며, 이 경우 사용자의 질문을 받아서 LLM 에게 질문을 던지기 전에 주어진 질문을 다듬는 과정에서 참조해야 하는 내용들을 먼저 추출하는 방법으로 많이 쓰게 되었다.

이 때 자연어로 주어지는 입력문을 지원하는 방법으로 벡터 데이터베이스가 각광을 받고 있다. 이미지로 검색하기 혹은 음악으로 검색하기 등의 방법에서 쓰이던 기법을 LLM 시대에 다시 적용하게 되는 모습인데, 기본적인 아이디어는 참조하려는 문서를 아래의 N 차원 벡터의 영역에 저장하는 것으로, LLM 에서 사용하는 임베딩을 이용해 문서를 저장해 놓고, 입력으로 들어올 벡터와 비교하는 형태이다.

그림 3: 벡터 공간 예제 ( https://weaviate.io/blog/distance-metrics-in-vector-search )

언어 모델에서 사용하는 단어 조각인 토큰을 임베딩을 이용해서 저장해 놓은 것으로 참조할 문서를 여러 개로 잘라 준비한 후 LLM 에 사용하는 임베딩(embedding) 을 이용해서 벡터데이터베이스에 저장을 해 놓고, 질문이 들어왔을 경우 이 질문을 같은 임베딩으로 풀어 조합을 찾는 경우 질문이 나타내는 벡터와 거리가 가장 가까운 벡터를 찾고, 그 벡터를 키로 해서 저장되어 있는 내용을 참조할 문서로 보내면 질문에 가장 가까운 내용을 추가적인 정보로 전해 줄 수 있다. 이 때 거리를 재는 방식으로는 내적(dot product), 코사인 거리(cosine distance), 유클리디안 제곱(squared Euclidean) 등의 방법이 있으며 실제적인 구현은 병렬로 처리한다.

아래는 이런 벡터데이터베이스를 사용할 경우에 이용할 수 있는 클라우드용 솔루션으로, 새로 LLM에 최적화 되어 있는 솔루션과 전통적인 데이터베이스에서 확장하는 방법들이 있으므로, 데이터 규모와 성장 예상, 쿼리 성능 요구사항, 관리 및 운영의 용이성 등을 고려해서 알맞은 기능을 선택하기를 권한다.

Weaviate

사용하기 쉬운 웹 인터페이스
텍스트 및 벡터 검색을 위한 하이브리드 검색 지원

Pinecone

빠른 벡터 검색 속도, 대규모 데이터 세트에 대한 높은 확장성
GenAI 애플리케이션에 적합

아마존 Kendra

문서, 코드 등 다양한 데이터 소스에서의 의미 검색
AWS 서비스와의 긴밀한 통합

애저 코그니티브 서치

애저와 원활한 통합
질문 답변 및 이미지 인식과 같은 사전 구축된 AI 기술

라마인덱스(LlamaIndex)

LLM 애플리케이션에 최적화
효율적인 벡터 표현 저장 및 검색

멀티 에이전트 — 검색 에이전트

ChatGPT가 세상에 나온 이후 LLM 자체의 품질을 높이는 방법과 이를 이용해서 특화된 서비스를 만드는 데 있어 가장 활발하게 쓰이는 것은 LLM 으로 대변되는 여러 개의 일꾼에게 다른 일을 시켜 취합하는 형태의 연결하는 방식이고, 이 경우 가장 중요한 역할을 하는 것은 또 다른 의미로 검색 결과를 사용하는 에이전트이다. 만들고자 하는 서비스가 기존 검색을 대체할 수도 있지만, 현재 공개된 웹 생태계에서 정보를 얻어야 한다면 구글 등의 검색 엔진을 통해 원하는 정보를 찾는 것은 사람이 할 수 있는 가장 정확한 행동에 가깝고, 이 과정을 에이전트를 이용해서 구현하고 있는 모습이라 하겠다.

하나의 모델로 모든 일을 해결하려는 노력과 더불어 일의 순서를 잘게 나누어 차례로 혹은 다각도로 처리하려는 기법들이 에이전트, 혹은 멀티 에이전트라는 이름으로 제안되고 많은 노력들이 이루어지고 있다. 마이크로소프트는 AutoGen 프로젝트(https://www.microsoft.com/en-us/research/project/autogen/overview/)를 오픈소스로 운영하고 있고, 랭체인(https://www.langchain.com/)과 라마인덱스(https://www.llamaindex.ai/) 등은 이 분야를 선도하고 있는 기업들이다.

잘게 잘라진 업무들 중에서 검색 에이전트는 주어진 사이트 혹은 외부 웹 전체에서 필요한 내용을 찾아서 모아 주는 역할로 좁게 정의하는데, 이 경우 다시 내부 자료 검색 혹은 외부 자료 검색 등의 기능이 필요하고 잘 만들어진 검색 엔진을 사용하게 되며, 다시 검색의 품질을 여기서 논의하게 된다.

검색의 위기

ChatGPT 이후 인터넷에는 AI가 생성한 문서들이 불완전한 형태로 생태계 전체를 오염시키고 있다. 창작물 경연 등에서는 판단이 불가능하고, 스팸 등의 영역에서는 그럴듯하게 보이는 확인되지 않는 내용을 대량생산함으로써 생태계 전체, 특히 검색 엔진의 품질에 영향을 주게 되었다. 스팸과 거짓 문서에 가장 오래되고 고도화된 기법을 가지고 있는 유명 검색엔진들이 문제가 된다면 그만큼 처리를 하지 않는 곳에서는 더 큰 위험에 노출되어 있을 것이다.

예를 들자면 오픈 프로젝트인 커먼 크롤(CommonCrawl, https://commoncrawl.org/)이 담고 있는 내용은 앞으로 어떻게 판단할 것이며, 같은 방식으로 인터넷에 있는 내용을 어떻게 믿고 쓸 것인지, 그리고 그것을 이용해서 만들었다고 하는 LLM 의 품질등은 어떻게 판단해야 할 것인지 주의가 필요하다 하겠다.

다른 서비스들과 다르게 검색 엔진의 경우 웹의 생태계를 그대로 놓은 채로 사용자들에게 검색이라는 가치를 주어 왔던 방식이라 몇몇 검색 엔진에서 이상이 발견될 경우 해당 서비스의 문제라기보다는 생태계 전체가 오염되거나 다치고 있다는 증거라 하겠다. 다양한 입력이 필요하겠지만, 업계 전체의 자정 작용이 무엇보다 필요한 영역이라 하겠고, 이는 검색 엔진 뿐 아니라 이를 이용해서 학습을 하는 각종 언어 모델에도 그대로 적용되는 문제이다.

새로운 기회

앞에서 언급한 유출 사건에서도 공개가 되었지만, 구글 검색의 여러 로직 중 중요한 부분이 사이트의 신뢰성 혹은 독창성(originality)이다. 각 사이트 운영자들이 자기 도메인에 맞는 좋은 내용을 인터넷에 공유하고 이들을 연결해 가며 얻은 내용을 구글은 각 사이트 별로 유명 점수(popularity)를 두어 높게 관리해 오고 있다. 특히 미국의 뉴스 사이트, 위키피디아 같은 정보 사이트, 레딧(reddit.com) 같은 커뮤니티 사이트들은 최고의 품질의 내용을 유지하기 위해 오랜 노력을 해 왔고, 이는 인터넷 생태계에서 검색 엔진을 통한 건강한 사용자 유입으로 그동안 이어져 왔다.

그림 4: 전세계 검색 점유율 https://gs.statcounter.com/search-engine-market-share#monthly-202211-202405

ChatGPT 런치 이후 지난달까지 구글의 전세계 검색 점유율은 2022년 11월 92.21%에서 2023년 하반기에는 91% 대, 지난 달에는 90.8%대로 소폭 하락하고 있다. 다른 대체제로서 검색 엔진이 그 효과를 누리는 게 아니므로 이는 전체적인 검색 수요가 줄어든 것일 것이고, 사용자들이 구글의 검색 창에다 하던 행동들의 일부가 다른 곳으로 이동한 것으로 해석하고 있고, 이는 뉴욕타임즈나 레딧이 그 내용 사용권을 OpenAI 와 협상하는 것과 맞닿아 있다 하겠다. 검색의 패러다임이 이동하고 있는 이 시기에 컨텐츠를 가지고 있는 회사들은 더더욱 자신의 가치들을 유지하기 위해 여러 방법들을 동원할 것일테고, 각 서비스는 자신만의 데이터들을 의미 있게 관리하고 공개하며 보호하는 전략들을 이용함으로써 AI 시대에 새로운 기회의 시기로 나아갈 수 있기를 기대한다.