Cerebras 사내 지식 베이스 구축 전략: 기존 업무 환경을 유지하면서 AI 검색 시스템을 만든 방법

기업이 성장할수록 내부 지식은 빠르게 분산됩니다. Slack에는 기술 토론이, GitHub에는 코드가, 문서 시스템에는 설계 문서가, 내부 데이터베이스에는 운영 정보가 각각 저장됩니다. 문제는 필요한 정보를 찾기 위해 여러 시스템을 오가야 하고, 같은 질문이 반복된다는 점입니다.

Cerebras는 이러한 문제를 해결하기 위해 기존 업무 도구를 그대로 유지하면서 모든 정보를 하나의 검색 경험으로 연결하는 사내 지식 베이스(Cerebras Knowledge)를 구축했습니다. 이 시스템은 출시 3개월 만에 직원과 자동화 시스템, AI 에이전트로부터 하루 15,000건 이상의 질문을 처리할 정도로 빠르게 활용되기 시작했습니다.

이번 글에서는 Cerebras가 어떤 구조로 지식 베이스를 설계했는지, 왜 기존의 '모든 정보를 하나로 옮기는 방식' 대신 새로운 접근을 선택했는지, 그리고 검색 정확도를 높이기 위해 어떤 기술들을 적용했는지 살펴보겠습니다.

반응형

---

기존 정보를 한곳으로 옮기지 않은 이유

많은 기업은 지식 관리 시스템을 구축할 때 모든 정보를 하나의 플랫폼으로 이전하려고 합니다. 하지만 Cerebras는 이러한 접근이 현실적인 업무 환경에서는 잘 동작하지 않는다고 판단했습니다.

그 이유는 정보가 생성되는 위치가 모두 다르기 때문입니다.

• 설계 문서는 문서 시스템
• 개발 코드는 GitHub
• 실시간 논의는 Slack
• 프로젝트 진행 상황은 Jira
• 운영 데이터는 내부 데이터베이스

각 서비스는 해당 목적에 맞게 오랜 기간 발전해 왔으며, 사용자가 익숙한 업무 방식까지 바꾸는 것은 오히려 생산성을 떨어뜨릴 수 있습니다.

따라서 Cerebras는 정보를 이동시키는 대신, 정보가 생성되는 위치에서 직접 수집하는 방식을 선택했습니다.

이 접근은 기존 업무 흐름을 유지하면서도 하나의 검색 인터페이스에서 모든 정보를 찾을 수 있도록 만드는 것이 핵심입니다.

---

공통 임베딩 테이블을 중심으로 한 구조

Cerebras Knowledge는 크게 세 개의 계층으로 구성됩니다.

• 데이터 수집 및 저장
• 검색 및 질의 처리
• 인증, 권한 관리, 감사 및 분석

이 구조의 중심에는 Postgres 기반의 공통 임베딩 테이블이 존재합니다.

이 테이블에는 다음과 같은 정보가 동일한 형식으로 저장됩니다.

• 임베딩 벡터
• 원문 요약
• 메타데이터

Slack, 코드 저장소, 문서 시스템, 내부 데이터베이스 등 모든 데이터 소스는 동일한 인터페이스를 통해 데이터를 저장합니다.

새로운 데이터 소스를 추가할 경우에도 별도의 검색 시스템을 구축할 필요 없이 공통 테이블에 맞춰 연결하기만 하면 동일한 검색 환경에서 즉시 활용할 수 있습니다.

이처럼 공통 스키마 기반 구조를 채택함으로써 확장성과 유지보수성을 크게 높였습니다.

---

Slack 검색은 벡터 검색만으로는 부족했다

Slack은 Cerebras 내부에서 가장 중요한 정보 저장소였습니다.

하지만 일반적인 벡터 검색만으로는 원하는 정보를 정확하게 찾기 어려웠습니다.

대표적인 이유는 다음과 같습니다.

• "좋아요"
• "확인했습니다"
• "응"

과 같은 짧은 메시지가 실제 기술 설명보다 높은 유사도를 가지는 경우가 발생했습니다.

또한 Slack 메시지는 대부분 이전 대화를 전제로 작성되므로 단일 메시지만으로는 의미를 이해하기 어려운 경우가 많았습니다.

이를 해결하기 위해 Cerebras는 네 가지 검색 방식을 동시에 사용했습니다.

1. 전문 검색(Full-text Search)

정확한 오류 메시지

호스트 이름

설정 플래그

로그 문자열처럼 정확한 토큰 검색을 수행합니다.

---

2. 임베딩 검색(Vector Search)

다른 표현으로 작성된 질문과 답변을 의미적으로 연결합니다.

예를 들어

"manifest 이후 복원이 멈춘다"

와

"NFS 마운트에서 체크포인트가 정지한다"

처럼 표현은 다르지만 같은 문제를 연결할 수 있습니다.

---

3. IDF(역문서 빈도)

희귀한 설정값이나 중요한 키워드의 점수를 높입니다.

반대로

• OK
• Thanks

처럼 자주 등장하는 일반적인 메시지는 점수를 낮춰 검색 품질을 향상시켰습니다.

---

4. 시간 감쇠(Time Decay)

동일한 품질의 결과라면 최신 정보를 우선합니다.

빠르게 변화하는 인프라 환경에서는 오래된 해결 방법보다 최근 논의가 훨씬 유용하기 때문입니다.

---

Slack 스레드를 하나의 지식 단위로 관리

Slack은 개별 메시지가 아니라 스레드 전체가 하나의 문맥(Context) 을 형성합니다.

Cerebras는 이를 고려하여 새 메시지가 등록될 때마다 해당 스레드를 다시 가져와 하나의 레코드로 저장했습니다.

이를 통해

• 부모 메시지
• 답글
• 참여자
• 마지막 수정 시간

등이 항상 최신 상태로 유지됩니다.

또한 Socket Mode 기반 WebSocket 연결을 활용하여 실시간으로 이벤트를 수신함으로써 API 호출을 반복하지 않고도 최신 상태를 유지했습니다.

---

LLM이 Slack 스레드를 구조화한다

원본 Slack 대화를 그대로 임베딩하면 검색 품질이 떨어졌습니다.

대신 LLM을 활용하여 스레드를 다음과 같은 형태로 정리했습니다.

• 실제 검색할 질문
• 한 줄 요약
• 해결 방법
• 관련 시스템
• 코드 참조

이렇게 정규화된 데이터를 임베딩하여 저장하자 검색 정확도가 크게 향상되었습니다.

즉, 대화 자체보다 구조화된 정보가 의미 검색에 더욱 효과적이었습니다.

---

긴 대화에서도 중요한 내용을 놓치지 않는 Bursting

스레드 전체를 하나로 요약하면 긴 토론 속 중요한 내용이 누락될 수 있습니다.

이를 해결하기 위해 Cerebras는 Bursting이라는 방식을 적용했습니다.

동일한 작성자가 연속해서 작성한 메시지를 하나의 묶음으로 합치고 별도로 임베딩했습니다.

단, 모든 대화를 저장하지는 않았습니다.

다음 조건을 만족하는 경우에만 저장했습니다.

• 희귀한 키워드 포함
• 일정 길이 이상의 내용
• 반응 이모지가 존재하는 메시지

이러한 기준을 적용해 실제로 가치 있는 정보만 검색 대상에 포함시켰습니다.

---

대규모 코드 저장소를 효율적으로 임베딩하는 방법

일부 코드 저장소는 40GB를 넘는 규모였습니다.

매번 전체 코드를 다시 임베딩하는 것은 현실적으로 매우 큰 비용이 발생합니다.

이를 해결하기 위해 Cerebras는 CocoIndex를 활용했습니다.

주요 특징은 다음과 같습니다.

• 클래스 단위 분할
• 함수 단위 분할
• 파일 단위 임베딩
• 변경된 코드만 다시 임베딩

특히 커밋마다 변경된 코드 조각만 다시 처리하는 증분 임베딩(Incremental Embedding)을 적용하여 비용을 크게 줄였습니다.

---

맞춤형 데이터베이스도 쉽게 연결

모든 팀이 Slack이나 문서 시스템만 사용하는 것은 아닙니다.

일부 조직은 자체 데이터베이스를 그대로 활용하기를 원했습니다.

이를 위해 Cerebras는 간단한 Python 플러그인 형태의 데이터 연결 방식을 제공했습니다.

팀은

• 기존 시스템에서 데이터 읽기
• 공통 임베딩 스키마 생성
• 공통 테이블 저장

만 구현하면 다른 데이터와 동일한 방식으로 검색할 수 있습니다.

---

검색 전에 AI가 먼저 계획을 세운다

사용자가 질문하면 바로 검색하지 않습니다.

먼저 LLM이 어떤 검색 도구를 사용할지 계획을 수립합니다.

대표적인 검색 도구는 다음과 같습니다.

• Slack 검색
• 코드 검색
• Wiki 검색
• 최근 Pull Request 검색
• 전문가 검색(who_knows)
• 시스템 요약 검색

계획이 완료되면 필요한 검색을 병렬로 실행하여 결과를 수집합니다.

이러한 방식은 검색 속도를 높이는 동시에 필요한 데이터만 조회할 수 있도록 해줍니다.

---

RRF와 재순위화를 이용한 검색 품질 향상

검색 결과는 여러 검색 엔진에서 동시에 생성됩니다.

하지만 각 검색 방식의 결과가 항상 동일하지는 않습니다.

이를 해결하기 위해 Cerebras는 RRF(Reciprocal Rank Fusion)를 적용했습니다.

RRF는 여러 검색기의 순위를 하나로 통합하여 특정 검색기에서만 높은 점수를 받은 결과보다 여러 검색기에서 꾸준히 높은 순위를 받은 결과를 우선합니다.

이후 작은 재순위화(Re-ranking) 모델이 질문과 가장 관련성이 높은 결과만 다시 선별합니다.

마지막으로 주변 문맥까지 함께 제공하여 답변 생성에 필요한 충분한 근거를 확보합니다.

---

MCP와 웹 UI의 역할 분리

Cerebras는 MCP(Model Context Protocol)와 웹 인터페이스의 역할도 명확하게 구분했습니다.

MCP

검색 기능을 작은 단위의 도구로 제공합니다.

예를 들어

• search
• search_slack
• search_code
• who_knows

등을 각각 독립적으로 제공합니다.

이를 통해 Claude Code와 같은 MCP 기반 AI 에이전트가 필요한 도구를 직접 조합할 수 있습니다.

웹 UI

웹에서는 사용자가 하나의 질문만 입력하면

• 계획
• 검색
• 병렬 실행
• 재순위화
• 답변 생성

전체 과정이 자동으로 수행됩니다.

사용자는 단순한 검색 경험을 제공받지만 내부에서는 복잡한 검색 파이프라인이 동작하는 구조입니다.

---

프로젝트 단위 검색으로 관련성을 높이다

조직 규모가 커질수록 모든 데이터를 동시에 검색하면 관련성이 크게 떨어집니다.

이를 해결하기 위해 Cerebras는 프로젝트(Project) 개념을 도입했습니다.

프로젝트는 다음과 같은 리소스를 하나의 작업 공간으로 묶습니다.

• Slack 채널
• Git 저장소
• 문서 공간
• 내부 데이터베이스

사용자는 자신의 프로젝트를 기본 검색 범위로 설정하고 필요한 경우에만 범위를 확장할 수 있습니다.

이를 통해 신규 직원도 자신과 관련된 정보부터 빠르게 탐색할 수 있습니다.

---

728x90

Cerebras Knowledge의 가장 큰 특징은 새로운 지식 관리 시스템을 강요하지 않았다는 점입니다.

모든 정보를 하나의 플랫폼으로 이전하는 대신, 정보가 생성되는 위치에서 직접 수집하고 공통 임베딩 구조를 통해 통합 검색을 제공했습니다.

또한 벡터 검색만 사용하지 않고 전문 검색, IDF, 시간 감쇠, RRF, 재순위화, 스레드 구조화 등 다양한 검색 기법을 조합해 실제 업무 환경에 적합한 검색 품질을 구현했습니다.

이 사례는 사내 AI 지식 베이스 구축이 단순히 LLM을 도입하는 문제를 넘어, 데이터 구조와 검색 전략, 기존 업무 방식의 유지, 그리고 확장 가능한 아키텍처 설계가 함께 고려되어야 한다는 점을 보여줍니다.

앞으로 기업의 AI 기반 지식 관리 시스템은 정보를 한곳에 모으는 방식보다, 분산된 데이터를 효과적으로 연결하고 의미 있게 검색하는 방향으로 발전할 가능성이 더욱 커질 것으로 기대됩니다.

300x250

https://x.com/cerebras/status/2077822555159945507

X의 Cerebras님(@cerebras)