Notes
5분 읽기Tech

Cerebras 사내 지식베이스의 검색 인프라 설계

사내 지식을 한곳으로 옮기지 않고, 여러 업무 도구 위에 공통 수집·검색·권한 계층을 만든 Cerebras의 설계 원칙을 정리한 노트.

Cerebras 사내 지식베이스의 검색 인프라 설계

한 줄 요약

사내 지식베이스의 성패는 LLM보다 지식의 수집, 정규화, 검색, 신선도, 권한을 얼마나 안정적으로 다루느냐에 달려 있다.

먼저 읽을 결론

Cerebras는 새 위키를 만들고 직원들에게 기록 방식을 바꾸라고 요구하지 않았다. Slack, GitHub, 문서, Jira, 내부 데이터베이스처럼 지식이 생기는 장소는 그대로 두고, 그 위에 공통 검색 계층을 올렸다.

복제할 만한 부분은 특정 벡터 데이터베이스나 임베딩 설정이 아니다. 핵심은 아래 흐름이다.

커넥터
  → 증분 동기화
  → 검색 가능한 지식 단위로 구조화
  → 키워드·벡터·희소 단어·시간 신호 결합
  → 순위 융합과 재순위
  → 주변 문맥 복원
  → 권한을 적용한 답변과 출처 제공

한마디로 Cerebras는 LLM을 문서 저장소에 붙인 챗봇이 아니라, 회사 전체가 함께 쓰는 신뢰 가능한 retrieval layer를 만들었다.

왜 저장했나

사내 RAG를 설계할 때 모델 선택이나 임베딩 차원부터 논의하기 쉽다. 이 사례는 더 오래 남는 문제가 데이터 연결, 검색 품질, 최신성, 접근 제어, 출처 관리라는 점을 보여준다.

특히 사용자 채택을 교육이나 규칙이 아닌 아키텍처로 해결한 판단이 인상적이다. 사람은 기존 도구에서 계속 일하고, 시스템이 흩어진 정보를 찾아 쓸 수 있게 만든다.

정리한 질문

Cerebras는 Slack, 코드, 문서, 이슈 추적기, 내부 데이터베이스에 흩어진 사내 지식을 어떻게 하나의 검색·답변 인프라로 연결했으며, 여기서 재사용할 만한 설계 원칙은 무엇인가?

핵심 답변

저장 위치보다 검색 인터페이스를 통일한다

모든 정보를 하나의 저장소로 옮기면 팀의 기존 업무 방식과 충돌한다. Cerebras는 소스별 커넥터가 각기 다른 데이터를 공통 스키마로 바꾸도록 했다. 수집 방식과 원본 형식은 달라도, 수집 이후에는 같은 질의 인터페이스를 쓴다.

공통 계층에는 검색할 텍스트와 임베딩뿐 아니라 원문 위치, 소스, 메타데이터, 타임스탬프가 함께 들어간다. 새 팀은 작은 Python 커넥터를 추가해 자체 데이터베이스를 같은 검색 계층에 연결할 수 있다. 중앙 팀이 모든 업무 시스템의 내부 구조를 알아야 할 필요도 없다.

원시 대화를 검색 가능한 지식으로 바꾼다

Slack 메시지를 그대로 잘라 임베딩하면 잡음이 많다. 짧은 동의나 감사 메시지가 높은 유사도를 얻기도 하고, 중요한 해결책이 긴 스레드 중간에 묻히기도 한다.

Cerebras는 LLM으로 스레드에서 다음 정보를 추출한다.

  • 사용자가 검색할 법한 질문
  • 핵심 요약
  • 최종 해결 방법
  • 관련 시스템과 코드 참조

이 구조화된 결과를 임베딩하고, 원문은 에러 문자열이나 설정 플래그를 정확히 찾을 수 있도록 따로 유지한다. 긴 스레드에서 요약에 빠질 수 있는 내용은 같은 작성자가 연속으로 쓴 메시지 묶음인 burst 단위로 보완한다.

핵심은 문서를 일정 길이로 나누는 데 있지 않다. 원시 대화를 나중에 다시 찾을 수 있는 지식 단위로 바꾸는 일이다.

검색기 하나의 점수를 믿지 않는다

사내 데이터에는 서로 다른 검색 문제가 섞여 있다.

검색 신호잘 다루는 문제
전문 검색에러 문자열, 설정 플래그, 코드 식별자처럼 철자가 중요한 질의
임베딩 검색표현이 달라도 의미가 가까운 질문과 답변 연결
IDF 기반 희소 단어 가중치흔한 짧은 메시지의 잡음을 줄이고 드문 기술 용어를 우대
시간 감쇠오래되어 폐기됐을 가능성이 있는 답변보다 최신 정보를 우대

각 검색기는 별도의 순위를 만든다. 이후 RRF(Reciprocal Rank Fusion)로 순위를 합쳐 여러 검색기에서 고르게 높은 문서를 우대한다. 점수 체계가 서로 다른 검색 결과를 억지로 같은 척도로 맞추지 않는 방식이다.

답변 생성 전 증거를 단계적으로 다듬는다

질문 하나를 벡터 검색 한 번으로 처리하지 않는다. 가벼운 planner가 통합 검색, Slack 검색, 코드 ripgrep, 최근 PR, 파일별 요약, who_knows 같은 도구 중 필요한 것을 고르고 병렬로 실행한다.

질문
  → 도구 선택과 병렬 검색
  → RRF 순위 융합
  → 중복 제거와 소스 다양화
  → 소형 reranker
  → 인접 섹션 등 주변 문맥 복원
  → 최종 LLM 답변과 출처

이 흐름에서 검색은 단순 조회가 아니다. 답변에 쓸 증거를 모으고, 겹치는 결과를 정리하고, 잘린 문맥을 복원하는 검증 파이프라인이다.

같은 지식 계층을 사람과 에이전트가 공유한다

웹 UI는 planner, executor, synthesis를 묶어 완성된 답변을 제공한다. MCP에서는 search, search_slack, search_code, who_knows처럼 작고 안정적인 검색 도구를 노출한다. MCP 클라이언트가 필요한 도구를 조합하고 검색 결과를 답변이나 코드 변경으로 바꾼다.

덕분에 같은 검색 기반을 직원, 사내 애플리케이션, 자동화, AI 에이전트가 함께 쓸 수 있다. 검색 범위와 인증, 권한, 감사 로그도 별도 부가기능이 아니라 지식 계층의 일부로 다뤄야 한다.

재사용할 설계 원칙

  1. 기록 습관을 바꾸기 전에 기존 업무 도구에서 데이터를 가져올 방법을 만든다.
  2. 원본 데이터의 소유권은 분산해도 검색 인터페이스는 통일한다.
  3. 대화 기록은 단순 chunk가 아니라 질문, 요약, 해결책, 참조가 있는 지식 단위로 바꾼다.
  4. 키워드, 의미, 희소성, 최신성을 독립된 검색 신호로 유지한 뒤 순위를 합친다.
  5. 재순위 뒤에는 잘린 주변 문맥을 복원한다.
  6. 출처, 권한, 프로젝트 범위, 감사 기록을 retrieval layer에 포함한다.
  7. 완성형 답변 API와 에이전트용 원시 검색 도구를 같은 기반 위에 제공한다.

적용할 때의 최소 구성

처음부터 전사 지식 그래프를 만들 필요는 없다. 다음 순서면 충분하다.

1. 가치가 큰 소스 2~3개를 고른다.
2. 공통 문서 스키마와 출처 메타데이터를 정한다.
3. 증분 동기화와 삭제·갱신 처리를 먼저 안정화한다.
4. 전문 검색과 벡터 검색을 각각 평가한다.
5. 순위 융합, 중복 제거, 재순위를 붙인다.
6. 권한이 검색과 답변 양쪽에서 유지되는지 테스트한다.
7. 웹 답변과 에이전트용 검색 도구를 분리해 제공한다.

모델을 바꿔도 이 계층은 남는다. 반대로 이 계층이 약하면 더 좋은 모델을 써도 오래된 답변, 권한 밖 정보, 근거 없는 요약을 막기 어렵다.

주의점과 불확실성

  • 공식 글은 Cerebras가 자사 시스템을 설명한 사례 연구다. 같은 구성이 다른 조직에서도 같은 검색 품질과 채택률을 보장하지는 않는다.
  • 시간 감쇠는 최신성을 높이지만, 오래되었어도 여전히 유효한 설계 문서나 장애 기록을 과도하게 낮출 수 있다.
  • LLM이 만든 질문·요약·해결책은 원문을 누락하거나 잘못 압축할 수 있다. 원문 링크와 정확 문자열 검색을 유지해야 한다.
  • who_knows 같은 전문가 검색은 편리하지만 개인 평가나 감시로 오해되지 않도록 목적, 노출 범위, 이의 제기 절차가 필요하다.
  • 권한 필터는 최종 답변 단계가 아니라 검색 후보를 만드는 단계부터 적용해야 한다. 그렇지 않으면 메타데이터나 요약을 통해 정보가 새어 나갈 수 있다.

검증이 필요한 주장

  • PostgreSQL 공통 테이블, pgvector, HNSW의 구체적인 스키마와 운영 설정은 공식 원문의 구현 설명을 다시 대조해야 한다.
  • Slack burst 선정 조건, IDF 가중치, 시간 감쇠 방식은 운영 환경에 맞춘 경험적 선택일 수 있으므로 그대로 일반화하면 안 된다.
  • planner가 쓰는 도구 목록과 RRF, 후보 수, reranker, 문맥 복원 범위 같은 세부값은 시스템 개편에 따라 달라질 수 있다.
  • 인증, 프로젝트 범위, 감사 로그가 실제로 어느 계층에서 어떻게 강제되는지는 공개 설명만으로 완전히 검증하기 어렵다.

Source Fidelity Notes

  • Preserved key numbers: 제공된 분석에는 운영 성능이나 채택률에 관한 정량 수치가 없어서 새 수치를 추가하지 않았다.
  • Preserved frameworks / models: 공통 검색 인터페이스, Slack 구조화, burst, 전문 검색, 임베딩 검색, IDF, 시간 감쇠, RRF, reranker, 문맥 복원, planner-executor-synthesis, MCP 검색 도구, 권한·출처 관리를 보존했다.
  • Preserved templates / checklists: 전체 retrieval pipeline과 재사용할 설계 원칙, 최소 도입 순서를 체크리스트 형태로 남겼다.
  • Omitted or compressed: 원문의 반복 설명과 강조 문구를 줄이고, 같은 주장을 아키텍처 단계별로 합쳤다. 사용자에게 제시된 해석과 Cerebras가 공개한 구현 설명은 구분해 표현했다.
  • Omission risk: 세부 구현값을 일반 원칙으로 압축했기 때문에 Cerebras 시스템을 그대로 재현하기에는 부족하다. 원문 분석은 비공개 sources/ 계층에 보존했다.

출처 / 참고자료