Cerebras가 사내 지식 검색을 하루 1만 5천 건까지 키운 설계

Cerebras가 사내 지식 검색을 하루 1만 5천 건까지 키운 설계

AI 뉴스 썸네일

사내 검색은 자료를 한곳에 모으는 일로 끝나지 않아요. 대화와 코드, 문서는 성격이 달라서 같은 검색 방식만 적용하면 필요한 답을 놓치기 쉬워요. Cerebras는 기존 업무 도구를 유지한 채 검색 계층을 연결했고, 출시 3개월 만에 하루 15,000건이 넘는 질문을 처리하고 있어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
데이터 구조	여러 출처를 공통 Postgres 임베딩 스키마에 연결했어요	새 자료원을 붙여도 질의 계층을 다시 만들 필요가 적어요
검색 품질	전문 검색, 임베딩, IDF, 시간 감쇠를 함께 썼어요	오류 코드와 자연어 질문을 한 방식으로 억지로 처리하지 않아요
검색 범위	채널과 저장소를 프로젝트 단위로 묶었어요	조직 전체의 무관한 결과가 상위에 섞이는 문제를 줄여요
도구 설계	MCP에는 작고 안정적인 검색 기능을 따로 공개했어요	코딩 도구가 필요한 검색만 골라 조합할 수 있어요

1. 하나의 검색창보다 검색 계층을 먼저 설계했어요

자료는 원래 있던 곳에 두었어요

Cerebras Knowledge는 문서와 대화를 새 플랫폼으로 옮기라고 요구하지 않아요. Slack 스레드, 코드 저장소, 문서 시스템, 맞춤형 데이터베이스에서 자료를 읽고 공통 형태로 저장해요. 중심에는 임베딩과 요약, 출처 메타데이터를 담는 Postgres 테이블이 있어요. 각 연결기는 같은 행 구조만 맞추면 기존 질의 인터페이스를 그대로 쓸 수 있어요. 2

이 선택은 사내 지식 관리에서 자주 생기는 문제를 피했어요. 코드는 저장소에서, 검토 의견은 문서에서, 장애 대응은 대화방에서 계속 만들어져요. 사람들이 기록 습관을 바꾸길 기다리는 대신 정보가 생기는 위치를 검색 시스템이 따라가요. 다만 원본 시스템의 접근 권한도 함께 따라야 하므로 인증, 권한 부여, 감사, 사용 분석을 별도 계층으로 분리했어요.

728x90

짧은 대화와 긴 기술 설명을 다르게 다뤘어요

대화 검색에서 원문 임베딩만 쓰면 짧은 맞장구가 긴 기술 설명보다 높은 유사도를 얻기도 해요. 정확한 오류 문자열이나 설정 플래그는 의미 검색 과정에서 흐려질 수 있어요. Cerebras는 전문 검색으로 정확한 토큰을 찾고, 임베딩 검색으로 표현이 다른 질문과 답을 연결해요. IDF는 희귀한 용어의 비중을 높이고, 시간 감쇠는 관련성이 비슷할 때 최근 답변을 앞세워요. 2

스레드도 한 덩어리로만 처리하지 않아요. 전체 대화에서 검색용 질문, 짧은 요약, 해결 방법, 관련 시스템과 코드 참조를 뽑아 임베딩해요. 긴 스레드에서 중요한 곁가지 답변이 사라지지 않도록 같은 작성자의 연속 발화를 따로 묶기도 해요. 이 묶음은 200자 이상이거나 희귀 토큰, 반응 이모지 같은 신호가 있을 때만 저장해 낮은 정보량의 메시지가 결과를 채우지 않게 했어요.

여러 검색 결과는 순위 융합 뒤 다시 골랐어요

질문이 들어오면 먼저 어떤 자료원과 검색 기능을 쓸지 정해요. 선택한 검색은 병렬로 실행하고, 서로 다른 결과 목록은 상호 순위 융합인 RRF로 합쳐요. 여러 검색 방식에서 고르게 상위권에 나온 문서가 한 방식에서만 높게 나온 문서보다 유리해요. 이후 작은 재순위화 모델이 질문과 후보 문서의 관련성을 다시 평가하고, 주변 문맥을 붙여 답변 근거를 만들어요. 2

조직 규모가 커지면 좋은 검색 알고리즘만으로 부족해요. 컴파일러 팀의 질문에 데이터센터 운영 문서가 계속 섞이면 검색 결과를 믿기 어려워져요. Cerebras는 채널, 저장소, 문서 공간을 프로젝트라는 기본 검색 범위로 묶었어요. 공유 자료는 복제하지 않고 여러 프로젝트에서 참조할 수 있어요. 사용자는 자신에게 맞는 프로젝트를 기본값으로 골라 관련 자료부터 검색해요.

MCP에는 완성 답변보다 원시 검색 기능을 열었어요

웹 화면은 검색 계획, 병렬 실행, 답변 합성을 한 흐름으로 제공해요. 반면 MCP에는 `search_slack`, `search_code`, `search`, `who_knows`처럼 범위가 좁은 기능을 각각 공개했어요. 각 기능은 가능한 한 빠르고 예측 가능하게 원시 근거를 돌려줘요. Claude Code 같은 MCP 호환 도구가 질문에 맞춰 호출 순서와 결과 조합을 결정할 수 있어요. 2

코드 저장소에는 또 다른 갱신 전략을 썼어요. 40GB가 넘는 저장소를 매번 전부 임베딩하지 않고 CocoIndex로 변경된 코드 청크만 다시 처리해요. 언어별 경계에 맞춰 파일, 클래스, 함수 수준을 나누고 같은 파일에서도 서로 다른 크기의 검색 단위를 만들어요. 대화와 코드가 같은 검색 화면에 보이더라도 자료의 생성 방식과 갱신 주기는 따로 설계한 셈이에요.

왜 중요한가요

기업용 RAG를 만들 때 벡터 데이터베이스를 먼저 고르는 경우가 많아요. Cerebras 사례는 검색 품질이 저장소 하나보다 자료별 처리 방식, 권한, 갱신 주기, 검색 범위에서 갈린다는 점을 구체적으로 보여줘요. 특히 정확한 토큰 검색과 의미 검색을 경쟁시키지 않고 결합한 방식은 장애 기록이나 대규모 코드 검색에 바로 참고할 수 있어요. 2

운영팀이 확인할 지점도 선명해요. 검색 결과가 나쁜 원인을 임베딩 모델 하나로 돌리기 전에 원문 단위, 최신성, 희귀 토큰, 팀별 범위, 재순위화 단계를 나눠 볼 수 있어요. 하루 15,000건이라는 사용량은 이 구조가 실제 사내 업무에서 반복적으로 쓰이고 있다는 수치예요. 다만 검색 정확도나 비용 절감 폭은 공개 글에 비교 지표가 없어 별도로 검증해야 해요. 3

참고 자료

1. Cerebras가 사내 지식 베이스를 구축한 방법 — GeekNews
2. How We Built Our Knowledge Base — Cerebras
3. How we built our knowledge base — Cerebras on X