Cerebras Knowledge로 보는 PostgreSQL 기반 엔터프라이즈 RAG

지식이 있는 곳을 떠나지 않는 검색 구조

Cerebras는 내부 지식베이스인 Cerebras Knowledge가 직원 질의를 하루 15,000건 이상 처리한다고 공개했다. 이 시스템은 3개월 만에 구축됐으며, Slack 스레드와 소스코드, 위키, 티켓처럼 사내 정보가 이미 자리 잡은 장소를 검색 대상으로 삼는다.

중앙 리포지토리에 모든 데이터를 강제로 모으기보다 “데이터가 사는 곳에서 만난다(meet data where it lives)”는 연합형 접근을 택한 것이다. 이런 환경에서는 검색 방식 하나만으로 충분하지 않다. 벡터 검색은 의역과 개념적 유사성을 잘 찾지만 모델명이나 에러코드 같은 정확 일치를 놓칠 수 있다. 반대로 키워드 검색은 정확한 문자열에는 강하지만 표현이 달라진 질문에는 약하다.

Cerebras Knowledge는 이 간극을 다중 retriever, Reciprocal Rank Fusion(RRF), MCP 도구 연동으로 메운다.

정규화부터 도구 호출까지 이어지는 파이프라인

원문 Slack 전사를 그대로 임베딩하지 않는다. 먼저 LLM이 검색 가능한 질문, 요약, 해결책, 시스템, 코드 참조 같은 구조화 필드를 추출한다. 정규화된 문서는 3,072차원 임베딩으로 변환되며, 이 과정에서 잡음 메시지를 검색 대상에서 배제한다.

검색 단계에서는 Slack Search의 하이브리드 검색, ripgrep 기반 Code Search, RRF를 적용한 Unified Search, 전문가를 찾는 “WHO Knows” 모듈이 병렬로 동작한다. full-text, embedding, IDF, age-decay 신호는 RRF 이전에 결합되고, 각 검색기는 MCP 서버로 노출된다. 어시스턴트는 이 공통 프로토콜을 통해 필요한 도구를 발견하고 호출한다.

⤢✕

PostgreSQL 안에서 결합하는 의미 검색과 정확 일치

pgvector는 PostgreSQL 확장으로 벡터 근사최근접(ANN) 검색을 수행하며, 의미적으로 가까운 문서를 찾는 역할을 맡는다. Cerebras의 구성에서는 단일 search_chunks(query, k) 함수가 벡터 ANN, full-text(BM25 계열), trigram(pg_trgm) 퍼지 매칭을 함께 실행한 뒤 RRF로 결과를 합친다.

벡터 검색은 의역과 개념 유사 검색에 강하고, tsvector와 pg_trgm은 고유명사와 에러코드 같은 정확 일치에 강하다. 서로 다른 특성을 하나의 검색 흐름에 넣으면 질문의 표현 방식에 따라 발생하는 누락을 줄일 수 있다.

pgvector, tsvector, RRF를 PostgreSQL 내부에서 처리한다는 점도 운영 구조에 영향을 준다. 별도 벡터 DB 없이 기존 RDBMS의 트랜잭션, 백업, 접근제어 거버넌스에 검색 계층을 통합할 수 있다.

점수가 아니라 순위를 합치는 RRF

RRF는 여러 결과 목록의 점수가 아니라 각 문서의 순위 위치를 기준으로 결과를 병합한다. 각 문서에는 리스트별로 weight / (k + rank)를 더한다. Cerebras는 기본 weight 1.0, 평활 상수(k) 60을 사용한다.

평활 상수가 클수록 특정 검색기에서만 1위를 차지한 결과보다 여러 retriever에서 상위권에 나타난 합의 문서가 유리해진다. cosine 유사도와 BM25처럼 점수 척도가 다른 검색 시스템도 순위 기준으로 통일할 수 있다.

공개 벤치 기준으로 순수 벡터 검색의 정밀도는 약 62%였고, full-text와 RRF를 결합한 경우 84%+로 상승했다.

⤢✕

MCP가 검색기를 어시스턴트의 도구로 바꾸는 방식

MCP는 2024년 공개된 개방형 표준으로, JSON-RPC 기반 통일 인터페이스를 통해 LLM이 외부 도구와 리소스에 안전하게 접근하도록 한다. 배포 상태, 로그 검색, 지식베이스, 티켓 같은 시스템은 각각 focused 서버를 제공하고, 어시스턴트는 공통 프로토콜을 통해 이를 발견하고 사용한다.

MCP와 RAG는 경쟁 관계가 아니다. MCP는 검색을 하나의 리소스로 노출하지만 검색에 한정되지 않으며, RAG는 MCP가 제공하는 리소스 중 하나로 편입된다. 컨텍스트도 시작 시점에 전부 preload하지 않는다. 생성 도중 추가 정보가 필요하다고 판단될 때 retrieval 도구를 호출한다.

질의 라우팅은 코드, 인물, 정책처럼 질문 유형에 맞춰 retriever와 도구를 고르게 한다. 불필요한 검색 비용을 줄이는 역할도 여기서 나온다.

운영에서 먼저 관리할 지점

원문을 임베딩하기 전에 LLM으로 구조화 추출을 수행하는 단계가 검색 품질의 상한을 좌우한다. pgvector 운영에서는 HNSW/IVFFlat 인덱스를 조정하고, 임베딩 차원인 3072와 저장·검색 비용의 균형을 살펴야 한다.

RRF는 weight와 평활 상수를 조정해 retriever별 신뢰도를 반영할 수 있으며, age-decay는 최신성 가중에 사용된다. 신규 데이터 소스는 MCP 서버 단위로 추가할 수 있어 전체 파이프라인을 다시 작성하지 않고 확장할 수 있다.

하루 1.5만 건 질의를 PostgreSQL 단일 스택으로 수용하면 별도 벡터 DB의 라이선스와 운영 부담을 피할 수 있다. 인덱스나 모델을 바꿀 때는 골든셋(golden set) 기반 회귀 테스트로 검색 정밀도 하락을 조기에 탐지한다. 또한 Slack 채널과 리포지토리 ACL 같은 소스별 권한을 검색 결과에 반영해 무단 노출을 막아야 한다.

검색 방식과 통합 계층의 선택 기준

구분	순수 벡터 검색	pgvector + RRF 하이브리드	단일 랭킹(리랭커)
정확 일치(에러코드·모델명)	취약	강함(키워드 보완)	중간
의역·개념 유사	강함	강함	강함
검색 정밀도(공개 벤치)	약 62%	84%+	모델 의존
척도 불일치 처리	불필요	순위 기반으로 해결	점수 재계산 필요
인프라 복잡도	벡터 DB 별도	PostgreSQL 단일 스택	리랭커 서빙 추가
비용/지연	낮음	중간(병렬 검색)	높음(추가 추론)

RRF는 추가 추론 없이 순위만 융합하므로 저비용·저지연 특성을 가진다. 단일 리랭커는 정밀도 상한이 높지만 서빙 비용이 증가한다.

MCP 기반 도구 연동은 표준 프로토콜로 소스를 증분 확장하기 쉽다. 커스텀 커넥터는 초기 최적화에는 유리할 수 있지만, 유지보수는 파편화될 수 있다. 2026년에는 PostgreSQL 내장 하이브리드(BM25 + 벡터 + RRF)가 성숙하고, agentic RAG에서 MCP가 사실상 표준 통합 계층으로 정착하는 방향이다.

검색 품질과 접근권한을 함께 다루는 거버넌스

연합형 검색은 중앙 리포지토리를 강제하지 않고 기존 데이터 자산을 지식자산화한다. 이는 EA(Enterprise Architecture)의 데이터 아키텍처 원칙과 맞닿아 있다.

검색 계층은 소스 ACL을 상속해 최소권한(least privilege)을 보장하고, RAG 결과의 기밀성을 확보해야 한다. 검색 정밀도 KPI인 정밀도와 재현율, 회귀 테스트는 SLA로 관리하며, 데이터 최신성(age-decay)도 품질 지표에 포함한다.

MCP 채택은 도구 통합에서 벤더 종속(lock-in)을 완화하고 서비스 지향(SOA/API) 거버넌스와 연결된다. 어떤 retriever와 문서가 응답 근거였는지 로그로 남기면 AI 응답의 설명책임(accountability)과 감사 대응도 가능해진다. 잘못된 검색 근거에서 비롯되는 오답(hallucination) 위험은 융합과 재순위로 완화하고, 데이터 분류체계의 등급에 맞춘 노출 통제 정책으로 다뤄야 한다.

Cerebras Knowledge는 전용 벡터 DB나 대규모 재작성 없이 PostgreSQL, pgvector, RRF, MCP를 조합해 하루 1.5만 건 규모의 엔터프라이즈 RAG를 운영할 수 있음을 보여준다. 원문을 구조화 정규화한 뒤 순위를 융합하는 방식은 검색 품질을 높이는 핵심 축이며, MCP는 데이터가 존재하는 곳을 연합 검색하는 운영 구조를 뒷받침한다.