하루 1만 5천 건, 사내 AI 검색은 이렇게 만들었습니다

세레브라스의 사내 지식베이스가 하루 1만 5천 건의 질문을 받습니다. 출시 3개월 만의 기록입니다.

비결은 자료를 한곳에 모으지 않은 것입니다. 슬랙, 코드 저장소, 문서에서 있는 그대로 끌어옵니다.

검색은 네 가지 방식을 동시에 돌리고, 순위는 합의로 정합니다. 하나만 믿지 않는 설계입니다.

어느 회사에나 분기마다 같은 제안이 올라옵니다. 모든 정보를 한 플랫폼에 기록하자는 제안입니다. 단일 진실 원천이라는 이름이 붙습니다. 그리고 대개 실패합니다.

세레브라스는 반대로 갔습니다. 자료를 옮기지 않고, 각 도구에 남아 있는 그대로 끌어왔습니다. 결과는 하루 1만 5천 건의 질문입니다. 이 글은 그 설계도를 원문 도해 그대로 펼쳐 보입니다. 사내 AI 검색을 검토하는 리더가 무엇을 먼저 정해야 하는지도 짚습니다.

사내 AI 도구 도입에서 가장 흔한 실패는 모델 선택이 아닙니다. 자료를 어디서 어떻게 가져올지 정하지 못해 멈춥니다. 세레브라스는 데이터센터 운영, 칩 설계, 하드웨어, 학습, 추론, 클라우드로 팀이 갈라져 있습니다. 매년 수백 명이 새로 들어옵니다. 같은 질문이 채널마다 반복되는 회사라면, 남의 정답보다 남의 설계도가 더 쓸모 있습니다.

리더의 셈법도 바뀝니다. 사내 검색은 모델 계약이 아니라 데이터 연결 프로젝트입니다. 예산의 무게는 모델 사용료가 아니라, 소스를 붙이고 유지하는 사람에게 실립니다.

첫째, 자료를 옮기지 않고 있는 자리에서 끌어옵니다. 정보는 편한 곳에서 생깁니다. 문서의 수정 제안, 슬랙의 스레드, 깃허브의 코드 참조, 지라의 상태값입니다. 각 도구는 그 일에 맞게 수년간 다듬어졌습니다. 풀 리퀘스트를 구글 문서에서 논의하는 건 끔찍한 경험이라고 원문은 적습니다. 그래서 기존 행동을 거의 바꾸지 않는 쪽으로 설계했습니다.

핵심은 포스트그레스 테이블 하나입니다. 임베딩, 요약본, 메타데이터가 여기 모입니다. 슬랙 스레드든 넷리스트든 같은 표에 같은 형식으로 앉습니다. 소스마다 정의하는 건 세 가지뿐입니다. 무슨 데이터인지, 어떻게 접속하는지, 얼마나 자주 가져올지입니다. 인터페이스가 단순하니 다른 팀도 직접 커넥터를 붙일 수 있습니다.

둘째, 슬랙은 대화 단위로 실시간 수집합니다. 슬랙이 가장 중요한 소스였습니다. 최신 엔지니어링 논의가 거기서 벌어지기 때문입니다. 봇을 소켓 모드로 띄워 모든 메시지 이벤트를 웹소켓으로 받습니다. 폴링 없이 실시간이고, API 호출 한도도 아낍니다. 이벤트가 오면 즉시 확인 응답을 보내고, 고유 ID로 중복을 걸러냅니다.

주목할 점은 저장 방식입니다. 새 메시지 하나만 따로 넣지 않습니다. 그 메시지가 속한 스레드 전체를 다시 불러와, 부모와 모든 답글을 한 행으로 씁니다. 그래서 저장된 내용과 참여자 명단, 마지막 활동 시각이 늘 대화 전체를 반영합니다. 채널마다 별도 소스로 두어, 사고 대응 채널처럼 급한 곳은 더 자주 가져올 수 있습니다.

셋째, 원문 대신 요약을 벡터로 넣습니다. 처음엔 원문 임베딩만으로 충분한지 시험했습니다. 곧 부족하다는 걸 알았습니다. 슬랙 메시지는 정보 밀도가 제각각입니다. "네 알겠습니다"와 상세한 커널 설명이 같은 메시지 한 건입니다. 짧은 메시지가 길고 자세한 메시지를 코사인 유사도에서 이기는 일도 잦습니다.

그래서 증류 단계를 넣었습니다. LLM이 스레드 전체에서 네 가지를 뽑습니다. 엔지니어가 실제로 검색할 법한 한 줄 질문, 짧은 요약, 해결 결과, 언급된 시스템과 코드 참조입니다. 이 항목들을 임베딩합니다. 원본 대화록은 임베딩하지 않습니다. 일관된 형식으로 정규화했을 때 정확도가 뚜렷하게 올랐다고 밝힙니다.

스레드 요약만으로는 긴 대화 속 중요한 메시지가 묻혔습니다. 그래서 버스팅을 씁니다. 같은 사람이 연달아 쓴 메시지 묶음을 하나의 버스트로 보고, 스레드 주제를 앞에 붙여 따로 임베딩합니다. 답이 곁가지 메시지 하나에 들어 있는 경우를 잡기 위해서입니다.

다만 아무 버스트나 넣지 않습니다. 세 가지 신호를 가중 합산해 문턱을 넘어야 합니다. 희귀한 단어가 있는지, 합쳐서 200자 이상인지, 이모지 반응이 달렸는지입니다. 마지막 항목은 사람의 손이 남긴 품질 신호를 그대로 쓰는 셈입니다.

넷째, 검색은 네 가지를 동시에 돌리고 순위는 합의로 정합니다. 어느 하나도 단독으로 신뢰하지 않습니다. 전문 검색은 오류 문자열, 플래그 이름, 호스트명처럼 임베딩이 뭉개는 정확한 토큰을 잡습니다. 임베딩 검색은 표현이 달라도 뜻이 같은 경우를 잇습니다. 역문서빈도는 흔한 인사말을 걸러내고 희귀 단어가 든 짧은 메시지를 끌어올립니다. 시간 감쇠는 슬랙의 답이 유통기한을 갖는다는 사실을 반영합니다. 반년 전 스레드가 지금은 없는 인프라를 설명할 수 있기 때문입니다.

서로 다른 검색기가 내놓은 목록은 그대로 비교할 수 없습니다. 그래서 상호 순위 융합을 씁니다. 문서마다 각 목록에서 가중치를 60 더하기 순위로 나눈 값을 더합니다. 가중치 기본값은 1.0, 완충 상수는 60입니다. 이 완충 상수 덕분에 한 검색기에서 1위인 문서보다, 여러 검색기에서 고르게 상위인 문서가 이깁니다.

그다음 중복을 원본 단위로 합칩니다. 한 파일이 차지할 결과 수도 제한해 상위 20개를 다양하게 만듭니다. 이를 작은 재순위 모델에 넘겨 0에서 10점을 매기고 상위 10개만 남깁니다. 마지막으로 살아남은 결과에 문맥을 되돌려줍니다. 위키 한 단락이 걸리면 앞뒤 두 단락을 함께 붙여, 조각내며 잘려나간 제목과 전제와 단서를 되살립니다.

다섯째, 코드는 굵은 단위부터 잘라 넣습니다. 처음엔 코드 임베딩이 필요한지 논쟁했습니다. 클로드 코드 같은 도구가 있으니 그냥 검색하면 된다는 생각이 있었기 때문입니다. 커서가 공개한 대규모 코드베이스 의미 검색 결과를 보고 시도하기로 했습니다. 40GB가 넘는 저장소도 있어, 관건은 최신 상태를 싸게 유지하는 일이었습니다.

선택은 코코인덱스였습니다. 언어별 규칙으로 굵은 경계부터 자릅니다. 클래스 단위를 먼저 시도하고, 조각이 여전히 크면 메서드, 그다음 더 작은 블록으로 내려갑니다. 커밋마다 바뀐 조각만 다시 임베딩합니다. 동기화 상태와 임베딩 저장소가 같은 데이터베이스에 있어 특히 잘 맞았습니다. 저장소가 늘어나자 온보딩을 설정 파일로 옮겨, 팀이 직접 경로 허용 목록과 제외 목록을 제출하게 했습니다.

여섯째, 질문마다 어떤 도구를 쓸지 먼저 계획합니다. 모든 질문에 대해 짧은 계획 단계를 먼저 돌립니다. LLM이 어떤 도구와 소스가 필요할지 고릅니다. 도구는 파일별 요약 색인, 통합 검색, 슬랙 검색, 코드 검색입니다. 최근 풀 리퀘스트와 전문가 찾기도 있습니다. 계획기는 어떤 프로젝트가 있고 각 소스가 무엇에 강한지 적힌 간략한 설명을 보고 판단합니다. 실행기는 선택된 도구를 병렬로 펼쳐 돌리고, 결과를 공통 형식으로 정리해 마지막 종합 단계에 넘깁니다.

일곱째, 사람과 에이전트에게 다른 문을 내줍니다. MCP 쪽에서는 검색 기능을 하나의 답변 엔드포인트로 감싸지 않습니다. 슬랙 검색, 코드 검색, 통합 검색, 전문가 찾기처럼 작은 도구로 그대로 노출합니다. 입출력이 좁고 구조가 안정적이라 어떤 클라이언트든 싸고 빠르게 부를 수 있습니다. 이때 조율은 클로드 코드 같은 에이전트가 맡습니다. 웹 UI에서는 같은 도구를 쓰되, 계획과 실행과 종합을 시스템이 끝까지 책임집니다. 사용자에게는 질문하고 답을 받는 화면 하나로 보입니다.

여덟째, 검색 범위를 프로젝트로 좁힙니다. 말뭉치가 커지자 전부 검색하는 방식은 쓸모를 잃었습니다. 컴파일러 팀은 인프라 운영 문서가 결과에 섞이는 걸 원하지 않았습니다. 그래서 프로젝트라는 단위를 도입했습니다. 특정 슬랙 채널, 코드 저장소, 내부 데이터베이스, 문서 공간을 묶은 이름표입니다. 같은 소스를 여러 프로젝트가 함께 참조할 수 있어 복제가 생기지 않습니다. 온보딩 때 기본 프로젝트를 고르게 했습니다. 새 엔지니어도 어떤 채널이 중요한지 배우기 전에 쓸 만한 답을 받습니다.

세레브라스가 정리한 구성 요소는 결국 세 가지입니다. 내부 데이터를 모으고 저장하는 층, 그 데이터를 질의하는 층입니다. 그리고 인증과 권한과 감사를 맡는 층입니다. 마지막 층은 화려하지 않지만, 사내 도입에서 가장 먼저 막히는 지점이기도 합니다.

자사 사례이며 검증 수치가 아닙니다. 하루 1만 5천 건이라는 숫자는 세레브라스가 직접 밝힌 값입니다. 질문의 질이나 답변 정확도에 대한 외부 검증은 없습니다. 도입 성과를 추정할 때 이 숫자를 근거로 쓰지 마세요.

엔지니어가 많은 조직의 설계입니다. 슬랙과 깃허브에 논의가 축적되는 회사에 맞춰진 구조입니다. 영업이나 제조처럼 정보가 회의와 문서와 현장에 흩어진 조직이라면, 소스 목록부터 다시 짜야 합니다. 그대로 복제하면 빈 데이터베이스만 남습니다.

운영 부담이 계속 남습니다. 채널마다 소스를 두고, 저장소마다 허용 목록을 관리하고, 프로젝트를 유지해야 합니다. 만드는 비용보다 유지하는 비용이 큽니다. 운영 담당을 정하지 않을 거라면 시작하지 않는 편이 낫습니다.

사내 지식베이스가 작동한 이유는 하나입니다. 정보를 한 시스템에 밀어 넣지 않고 있는 자리에서 꺼내 썼기 때문입니다. 통합해야 할 것은 자료가 아니라 자료를 꺼내는 방식입니다.

• Cerebras. (2026, July). How Cerebras Built Its Enterprise Knowledge Base [Blog]. Cerebras Systems. (원문 보기 ↗)
• Cormack, G., Clarke, C., & Büttcher, S. (2009). Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods [Paper]. SIGIR.
• Anthropic. (2024). Introducing Contextual Retrieval [Article]. Anthropic.
• Liu, N., et al. (2023). Lost in the Middle: How Language Models Use Long Contexts [Paper]. arXiv:2307.03172.
• Cursor. (2025). Improving Agent with Semantic Search [Article]. Cursor.