새로 합류한 직원이 “이 시스템은 왜 이렇게 작동하나요?”라고 묻습니다. 답을 찾으려면 위키에서 설계 문서를 찾고, Slack에서 결정이 오간 대화를 훑은 뒤, 코드 저장소와 Jira의 변경 기록까지 오가야 합니다. 한곳만 봐서는 이유와 현재 상태를 함께 알기 어렵습니다. AI 에이전트도 같은 문제를 겪습니다. 업무를 맡아도 근거가 여러 도구에 흩어져 있으면 답보다 자료의 위치부터 추적하게 됩니다.
Isaac Tai, Daniel Kim, Mike Gao가 2026년 7월 15일 공개한 How We Built Our Knowledge Base에서 Cerebras는 이 문제를 기존 기록 습관을 바꾸지 않는 지식베이스로 풀었다고 소개합니다. 출시 3개월 뒤 하루 15,000건이 넘는 질문을 처리했고 사람, 자동화, AI 에이전트가 같은 검색 계층을 쓴다는 설명도 Cerebras의 자체 보고입니다. 사용량과 공동 사용에 관한 수치와 평가는 외부에서 독립적으로 검증되지 않았습니다.
자료가 있는 곳에서 시작한 구조
Cerebras 팀은 계속 Slack에서 대화하고 코드 저장소에서 코드를 고치며 Jira와 내 부 DB를 사용합니다. 출처별 수집기가 자료를 읽어 공통 형식으로 내보내기 때문에 새 출처가 생겨도 검색 계층 전체를 다시 설계할 필요가 없습니다. 기사는 전체 구조를 수집·저장 계층, 검색 계층, 인증·권한·감사·분석 계층으로 구분합니다.
이 검색 계층은 직원이 화면에서 자료를 찾을 때뿐 아니라 반복 작업을 돌리는 자동화와 작업 중 근거를 호출하는 AI 에이전트에도 쓰입니다. 이용 방식은 달라도 결과는 원본 위치와 인용 근거로 이어져야 합니다.
Slack 대화를 검색 가능한 문서로 만드는 과정
Slack은 중요한 결정이 많이 생기지만 검색하기 까다로운 출처입니다. 짧은 동의와 긴 기술 설명, 뒤늦게 추가된 해결책이 한 스레드에 섞이기 때문입니다. Cerebras의 수집기는 Socket Mode 이벤트를 받고 stable event ID로 중복을 제거합니다. 답글이 달리면 새 메시지만 저장하지 않고 첫 메시지와 모든 답글을 다시 가져와 전체 스레드를 upsert합니다.
검색용 자료를 만들 때도 원문을 버리지 않습니다. 원문 대화 기록은 키워드 검색과 확인을 위해 남겨 둡니다. 정제 단계에서는 질문, 요약, 해결 결과, 관련 시스템, 코드 참조를 뽑아 정규화된 문서를 만듭니다. Cerebras는 이 과정이 내부 정확도를 개선했다고 보고했지만 기준선, 표본 수, 정확한 개선 폭은 공개하지 않았습니다.
스레드 요약에서 빠질 수 있는 설명은 같은 작성자의 연속 메시지를 burst로 묶어 보완합니다. IDF 4.0, 200 chars, 반응은 Cerebras가 공개한 채택 신호입니다. 전체 가중치와 최종 임계값은 공개되지 않았습니다.
정확 일치 검색과 의미 검색을 함께 쓰는 법
정확 일치 검색(exact)은 오류 문자열, 플래그 이름, 호스트 이름처럼 철자가 중요한 토큰을 찾습니다. 의미 검색(semantic)은 표현이 달라도 뜻이 비슷한 자료를 연결합니다. Cerebras는 전체 텍스트 검색(FTS), 임베딩, IDF, 시간 감쇠가 만든 순위 목록을 따로 계산한 뒤 하나로 합칩니다.
결합에는 Reciprocal Rank Fusion의 k=60을 사용합니다. 중복을 줄인 후보 top 20을 작은 LLM 재순위 모델이 0~10으로 평가해 top 10을 남깁니다. 최종 순위를 정한 뒤에는 출처에 맞춰 주변 문맥을 덧붙입니다. 예를 들어 위키 섹션이 일치하면 인접한 두 섹션을 함께 가져옵니다. 재순위 모델의 이름, 학습 데이터, 보정 방법은 공개되지 않았습니다. 3,072차원 임베딩과 HNSW도 Cerebras가 공개한 구현값이며 보편 권장값이 아닙니다. 관련성 순위는 사실 검증을 대신하지 않습니다.
검색 도구와 답변 생성의 경계
에이전트용 MCP 인터페이스는 search_slack, search_code, search, who_knows처럼 범위가 좁은 검색 도구를 제공합니다. 각 도구는 가능한 한 LLM을 쓰지 않고 출처, 시각, 점수가 포함된 근거 행을 반환합니다. 어떤 도구를 어떤 순서로 호출하고 결과를 어떻게 조립할지는 에이전트가 맡습니다.
Web UI에서는 계획 모델이 검색할 곳을 고르고 실행기가 도구를 병렬로 호출해 결과 형식을 맞춥니다. 마지막 합성 단계는 근거 묶음으로 인용과 유의점이 있는 답을 만듭니다. Cerebras의 설명에 따르면 이 과정도 사람, 자동화, AI 에이전트가 함께 쓰는 검색 계층 위에서 동작합니다.
프로젝트 단위 검색과 권한
모든 출처를 한꺼번에 검색하면 잡음이 커집니다. Cerebras의 프로젝트는 Slack 채널, 코드 저장소, 내부 DB, 문서 공간을 묶은 단위입니다. 여러 프로젝트가 공용 출처를 복제하지 않고 참조하며 기본 프로젝트가 검색 범위를 제한합니다.
범위 제한은 관련성 문제이면서 권한 문제입니다. 기사에는 인증·권한·감사 계층이 나오지만 실제 구현의 완전성과 권한 누출 검증은 외부에서 확인되지 않았습니다. who_knows가 전문성을 판정하는 기준과 오탐률도 공개되지 않았습니다.
다른 조직에 적용한다면 이 공백을 별도의 운영 규칙으로 메워야 합니다. 필자의 판단으로는 출처마다 책임자와 갱신 주기를 정하고 권한별 검색 시험을 정기적으로 반복해야 합니다. 이는 Cerebras가 공개한 절차가 아니라 사례를 옮길 때 필요한 보완입니다.
다른 조직을 위한 점검과 파일럿 적용
아래 운영 질문과 파일럿은 Cerebras의 절차를 기반으로 만든것입니다. 에이전트 지식 관리가 처음이신 분은 20~50개 문서와 평가 질문 10개라는 작은 규모로 시작해보시는게 좋습니다.
도입 전 점검 질문
반복 질문이 많고 답의 책임자가 분명한 업무는 무엇입니까?
원본을 관리할 책임자와 검토 주기는 정해져 있습니까?
답변마다 어떤 출처 이름과 인용을 표시해야 합니까?
원문 기록과 검색용 정제본을 어떻게 구분합니까?
프로젝트별 기본 범위와 접근 정책은 어디에서 집행합니까?
오래된 근거, 충돌하는 근거, 확신이 낮은 결과는 누구에게 넘깁니까?
파일럿
반복 질문이 많고 책임자가 분명한 업무 하나를 고른 뒤 공개 또는 비민감 문서 20~50개만 넣습니다. 각 문서에는 목적, 책임자, 검토일, 적용 범위, 출처 링크를 기록합니다.
정답 근거가 있는 평가 질문 10개로 현재 기준선을 재고 정확 일치 검색과 의미 검색을 비교합니다. AI 에이전트의 답에는 인용과 불확실성 표시를 요구하고 충돌, 누락, 낮은 확신은 사람이 검토합니다. 결과는 인용 포함률, 오래된 자료 적중, 권한 누출, 오답, 응답 지연, 유지관리 시간으로 기록합니다.
권한 누출이 한 번이라도 나오면 파일럿을 중단합니다. 인용 없는 답이 반복되면 에이전트의 검색 범위를 줄입니다. 평가 질문의 근거 회수율과 유지관리 시간이 기준을 통과할 때만 문서와 출처를 늘립니다.
참고
Cerebras, How We Built Our Knowledge Base
Isaac Tai, Daniel Kim, Mike Gao
2026-07-15
https://www.cerebras.ai/blog/how-we-built-our-knowledge-base
