회사의 뇌는 중앙 위키가 아니다
Cerebras가 만든 사내 지식베이스를 읽으며 가장 인상적이었던 것은 검색 기술보다 출발점이었다. 회사의 정보는 원래 흩어져 있다. 문제는 흩어져 있다는 사실이 아니라, 필요한 순간에 근거와 함께 다시 찾을 수 없다는 데 있다.
Company Brain은 모든 정보를 한곳으로 옮기는 프로젝트가 아니다. 정보가 생기는 곳은 그대로 두고, 그 위에 검색·권한·최신성·인용을 묶는 공통 계층을 만드는 일이다.
왜 이 글을 읽었나
회사 지식을 AI가 읽게 만들자는 이야기는 이제 흔하다. 보통은 문서를 한곳에 모으고, 벡터 데이터베이스에 넣고, 챗봇을 붙이는 그림으로 끝난다. 하지만 실제 회사의 지식은 그렇게 단정하지 않다.
결정은 Slack에 있고, 현재 사양은 Wiki에 있고, 실제 동작은 코드에 있으며, 예외는 incident 기록에 남는다. 같은 질문에도 프로젝트와 권한에 따라 다른 답이 필요하다. 어제 맞았던 운영 정보가 오늘은 틀릴 수도 있다.
Cerebras의 How We Built Our Knowledge Base는 이 복잡함을 피하지 않는다. 이 글이 흥미로운 이유다.
원문의 한 줄 주장
Cerebras는 Slack, 문서, 코드, incident 같은 원천을 하나의 도구로 강제 이전하지 않았다. 대신 각 원천을 수집하고, 검색 가능한 지식 단위로 정리한 뒤, 여러 검색 신호를 합쳐 답과 출처를 내놓는 시스템을 만들었다.
회사가 공개한 수치에 따르면 이 지식베이스는 출시 후 3개월 만에 사람·자동화·agent가 하루 15,000건 이상의 질문에 사용한다. 다만 이것은 높은 사용량을 보여주는 자사 수치다. 답변 정확도, 운영비, 권한 누출률, 사업 성과는 공개되지 않았다.
Company Brain의 실제 구조
Cerebras의 구현을 뜯어보면
원문에는 따라 해볼 만한 구현 선택이 꽤 구체적으로 공개되어 있다. 핵심은 거대한 AI 모델이 아니라, 서로 다른 실패를 막는 작은 장치들을 한 파이프라인에 배치한 데 있다.
1. 저장소는 단순하게, connector는 원천별로
중심에는 하나의 Postgres embeddings table이 있다. Slack thread, Wiki, 코드 조각, netlist, 사내 DB에서 나온 데이터가 모두 document + embedding + metadata + source + timestamps라는 공통 형태로 들어간다. Vector는 3,072차원이고, pgvector의 HNSW 인덱스를 사용한다.
대신 connector는 원천별로 나눈다. 각 connector가 “무엇을 읽고, 어떻게 연결하며, 얼마나 자주 동기화할지”를 책임진다. 팀이 기존 DB를 연결할 때도 작은 Python plugin이 공통 row를 내보내게 하면 이후 검색 계층은 바꾸지 않아도 된다. 이 분리가 중요한 이유는 새 SaaS나 사내 DB를 붙일 때 전체 RAG pipeline을 다시 만들지 않아도 되기 때문이다.
2. Slack은 메시지가 아니라 thread를 상태 단위로 다룬다
Cerebras는 Slack Socket Mode의 WebSocket event를 받아 즉시 acknowledge하고 stable event ID로 중복을 제거한다. 새 reply 하나만 저장하지 않고, 해당 parent와 모든 reply를 다시 가져와 thread 전체를 한 row로 upsert한다. 참여자와 마지막 활동 시각도 함께 갱신된다. polling보다 실시간성이 좋고 Web API rate limit도 덜 쓴다.
Raw thread에는 Postgres full-text GIN index를 걸어 error string과 flag를 즉시 찾게 한다. Vector 검색용으로는 원문을 그대로 embedding하지 않는다. LLM extractor가 전체 thread에서 다음 구조를 만든다.
{
"question": "엔지니어가 실제로 검색할 한 줄 질문",
"summary": "무슨 일이 있었는가",
"resolution": "어떻게 해결했는가",
"systems": ["관련 시스템"],
"code_refs": ["flag", "class", "path"]
}이 정규화 문서를 embedding하자 raw transcript를 직접 embedding했을 때보다 검색 정확도가 유의미하게 좋아졌다고 Cerebras는 설명한다. 다만 원문 thread와 source ID는 버리지 않는다. 검색은 정규화 문서로 하고, 검증은 원문 citation으로 돌아간다.
3. 긴 thread의 묻힌 답은 burst embedding으로 살린다
Thread summary만으로는 긴 대화 중간의 중요한 한 문장이 사라질 수 있다. 그래서 같은 작성자가 연속으로 쓴 메시지를 burst로 묶고, thread topic을 앞에 붙여 별도로 embedding한다. 모든 잡담을 넣지는 않는다. Cerebras가 공개한 통과 신호는 다음과 같다.
- corpus 기준 희귀 token의 IDF가 4.0 이상
- 합친 burst가 200자 이상
- reaction이 하나 이상 있어 social boost를 받음
이 조건들을 가중 결합한 threshold를 넘은 burst만 저장한다. “좋아요, 해볼게요” 같은 짧은 반응은 줄이고, 희귀한 config flag가 포함된 기술 설명은 thread summary와 별개의 검색 입구를 얻는다.
4. 코드는 언어 경계를 따라 자르고 변경분만 다시 embedding한다
40GB를 넘는 repository도 있어 전체 재색인은 비현실적이었다. Cerebras는 CocoIndex를 사용해 class → method → 작은 block 순서의 language-aware recursive chunking을 적용한다. 큰 파일 하나가 file-level과 function-level 등 여러 해상도의 record를 만들 수 있다.
동기화 상태도 같은 Postgres에 두고, commit마다 바뀐 code chunk만 다시 embedding한다. Repository onboarding은 config와 pull request로 받고 file-path allowlist/denylist를 둔다. 여기서 얻을 아이디어는 “코드를 벡터화할 것인가”보다 grep이 잘하는 exact match와 semantic code search를 함께 두고, 증분 색인을 운영 가능하게 만드는 것이다.
5. 질문마다 필요한 도구부터 계획한다
모든 질의를 모든 원천에 던지지 않는다. 가벼운 planner가 현재 project와 질문을 보고 subsystem_index, search, search_slack, search_code, recent_prs, who_knows 중 필요한 도구를 고른다. Executor는 이를 병렬 실행하고 결과를 공통 evidence schema로 바꾼다. 마지막 synthesis model만 답과 citation을 만든다.
MCP에서는 더 얇다. 각 tool은 가능하면 LLM 없이 한 retrieval primitive와 raw evidence row만 돌려준다. Claude Code 같은 client가 호출 순서와 합성을 맡는다. 이 설계는 검색 계층을 특정 agent에 종속시키지 않고, 비용과 latency를 관찰하기도 쉽게 만든다.
단일 벡터 검색으로는 왜 부족한가
“의미가 비슷한 문서를 찾는다”는 일만 놓고 보면 embedding은 강력하다. 하지만 회사에서 묻는 질문은 의미 검색만으로 해결되지 않는다.
| 검색 신호 | 잘 찾는 것 | 막아주는 실패 |
|---|---|---|
| Full-text / ripgrep | 오류 문자열, flag, hostname, 코드 경로 | 정확한 식별자가 비슷한 문장에 밀리는 문제 |
| Embedding | 표현은 다르지만 뜻이 같은 질문 | 단어가 다르다는 이유로 관련 문서를 놓치는 문제 |
| IDF | 드물고 중요한 기술 용어 | 짧은 잡담이 기술 답변보다 높게 잡히는 문제 |
| Age decay | 최근 운영 정보 | 폐기된 인프라 설명이 계속 답으로 나오는 문제 |
| RRF + reranker | 여러 검색 결과의 합의 | 한 종류의 점수를 지나치게 믿는 문제 |
여기서 중요한 판단은 “어떤 검색 기술이 최고인가”가 아니다. 질문마다 필요한 신호가 다르므로 여러 검색기를 병렬로 돌리고, 마지막에 근거를 보며 합쳐야 한다는 점이다.
여섯 목록을 어떻게 한 순위로 합치는가
Cerebras는 vector, full-text, thread summary, graph, Wiki vector, Slack full-text처럼 서로 점수 체계가 다른 여섯 ranked list를 병렬로 만든다. 이를 억지로 같은 점수로 환산하지 않고 Reciprocal Rank Fusion으로 합친다.
RRF(d) = Σ 1 / (60 + rank_l(d))k=60이라는 완충값 때문에 한 검색기에서만 1등인 문서보다 여러 검색기에서 꾸준히 상위에 나온 문서가 유리해진다. 그다음 같은 원천의 중복 chunk를 하나로 합치고, 한 파일이 결과를 독점하지 않도록 source별 개수를 제한해 상위 20개를 만든다.
작은 reranker model이 원 질문과 후보를 보고 0–10점을 매겨 상위 10개만 남긴다. 마지막으로 Wiki section이 선택됐다면 앞뒤 두 section을 다시 붙인다. 검색용으로 잘게 자르되, 답을 만들 때 heading·전제·주의사항을 복원하는 것이다. 최종 evidence packet은 그래서 fusion → source dedupe → diversity cap → question-aware rerank → neighbor context expansion을 모두 거친다.
원문을 그대로 넣는 것보다 어려운 일
Slack thread를 통째로 embedding하면 대화의 소음까지 검색된다. 반대로 LLM으로 지나치게 요약하면 중요한 단서와 반대 의견이 사라진다.
Cerebras는 대화를 질문, 요약, 해결책, 관련 시스템, 코드 참조 같은 검색 가능한 단위로 정리한다. 나는 이 구조에서 두 가지를 같이 지켜야 한다고 본다.
- 정규화된 지식 단위는 빠르고 정확한 검색을 위해 필요하다.
- 원문과 인용은 요약 과정에서 사라진 맥락을 확인하기 위해 필요하다.
정리된 답만 남기면 시스템은 곧 자신이 만든 요약을 사실처럼 재인용하기 시작한다. 그래서 raw source, 변환 이력, citation은 부가 기능이 아니라 안전장치다.
내가 동의하는 지점
정보의 생성 위치를 존중한다
개발자는 코드를 Git에서 보고, 영업은 고객 정보를 CRM에서 보고, 운영자는 incident 기록을 티켓에서 본다. 모든 사람에게 새 위키로 옮겨 적으라고 요구하면 복사본만 늘고 최신성은 떨어진다. Connector가 원천을 따라가는 편이 현실적이다.
검색 범위를 먼저 좁힌다
회사의 모든 것을 항상 검색하면 더 똑똑해지는 것이 아니라 noise와 권한 위험이 커진다. 프로젝트, 역할, 업무 단계별로 기본 검색 범위를 정하고, 필요할 때만 넓히는 구조가 맞다.
MCP 도구는 좁게 만든다
search_slack, search_code, who_knows처럼 근거를 돌려주는 작은 도구는 안정적이다. 어떤 도구를 언제 조합하고 답을 어떻게 만들지는 client agent가 맡는 편이 확장하기 쉽다.
내가 유보하는 지점
하루 15,000건의 질문은 분명 강한 사용 신호다. 그러나 사용량과 정확성은 같은 말이 아니다. 오래된 답을 얼마나 자주 내놓는지, 출처 없는 답이 얼마나 되는지, 다른 프로젝트의 비공개 정보가 섞이지 않는지는 별도의 지표가 필요하다.
내가 실제 운영에서 보고 싶은 일곱 지표
아래 지표는 Cerebras가 공개한 dashboard 항목이 아니다. 공개된 구조를 실제 회사에 운영한다면 내가 추가로 측정할 지표다. 먼저 정답과 권한이 표시된 질문 세트를 만들고, 자동 집계와 표본 human review를 함께 해야 한다.
| 지표 | 어떻게 재는가 | 왜 필요한가 |
|---|---|---|
| Canonical-source hit rate | 정답 원천이 정해진 평가 질문 중 그 원천이 retrieval top-k에 포함된 비율 | 답변 모델 이전에 검색 계층이 진짜 기준 문서를 찾았는지 분리해서 본다. 낮으면 prompt를 고칠 일이 아니라 connector·scope·ranking을 고쳐야 한다. |
| Citation coverage | 검증 가능한 주요 주장 중 직접 뒷받침하는 citation이 붙은 비율. 링크 개수가 아니라 claim 단위로 센다. | 그럴듯한 문장 뒤에 무관한 링크 하나를 붙이는 citation laundering을 막는다. 사용자가 답을 원문까지 추적할 수 있어야 한다. |
| Stale-hit rate | 최종 evidence 또는 답에 폐기·대체·유효기간 경과 source가 포함된 비율 | 오래된 runbook이 검색 상위에 남으면 답은 자연스럽지만 실행은 위험하다. timestamp뿐 아니라 version, owner, authoritative status, tombstone을 함께 기록해야 측정할 수 있다. |
| Accepted-answer rate | 사용자가 수정 없이 채택했거나 후속 행동에서 유효하다고 확인된 답의 비율 | retrieval 점수가 높아도 업무에 쓸 수 없을 수 있다. 단순 thumbs-up보다 “복사해 사용”, “ticket 해결”, “재질문 없음” 같은 행동 신호를 함께 본다. |
| Permission leakage | 요청자의 ACL 밖 source가 retrieval, citation, answer 어느 단계에서든 노출된 건수와 비율 | 평균 품질보다 우선하는 stop metric이다. 0을 목표로 하고, synthetic canary와 red-team query로 지속 검사해야 한다. |
| Unknown / contradiction 처리율 | 근거 부족 또는 권위 있는 원천 간 충돌이 심어진 평가 질문 중, 단정하지 않고 unknown·충돌·escalation으로 처리한 비율 | 모르는 답을 꾸며내거나 최신 문서와 구 문서를 임의로 섞는 실패를 잰다. 답변률을 높이는 것보다 올바르게 멈추는 능력이 중요하다. |
| Repair latency | 오답·오래된 source·권한 문제를 감지한 시점부터 source 수정, 재색인, 검증 통과까지 걸린 시간의 median과 p95 | 지식베이스는 반드시 틀린다. 핵심은 무오류가 아니라, 틀린 근거가 얼마나 오래 유통되는지다. connector owner와 repair queue가 있어야 줄일 수 있다. |
또 age decay는 최신 문서를 높여주지만, 오래됐어도 여전히 기준인 설계 문서를 낮출 수 있다. 날짜만으로 권위를 판단하지 말고 authoritative status, version, owner, tombstone을 함께 봐야 한다.
한국 기업에서 시작한다면
새로운 RAG 플랫폼부터 도입하지 않겠다. 먼저 실제로 반복되는 질문 20개를 고르겠다. “지난 장애의 원인은 무엇이었나”, “이 고객에게 약속한 기능은 무엇인가”, “현재 배포 절차는 어디에 있는가”처럼 답의 출처가 명확한 질문이 좋다.
- 정답이 있는 canonical source를 지정한다.
- 현재 검색으로 그 문서가 상위에 나오는지 기록한다.
- ID, 경로, 오류 문자열이 정확히 보존되는지 본다.
- 오래된 문서가 최신 문서를 이기는지 확인한다.
- 다른 프로젝트나 권한 밖 정보가 섞이는지 본다.
- 근거가 없을 때 “모른다”고 멈추는지 확인한다.
그다음 lexical search, embedding, freshness, project scope를 한 번에 하나씩 추가한다. 전후 평가가 좋아진 변화만 남긴다. 기술을 많이 붙이는 것보다 틀린 답이 왜 나왔는지 고칠 수 있는 구조가 먼저다.
따라 만드는 최소 설계
Cerebras의 규모를 처음부터 복제할 필요는 없다. 아래 순서면 작은 팀에서도 핵심 가설을 검증할 수 있다.
- 질문 세트: 실제 반복 질문 20개와 canonical source, 허용 ACL, 최신 version을 표로 만든다.
- 공통 row:
id, project_id, source_type, source_id, document, raw_uri, embedding, updated_at, ACL, authoritative_status를 갖는 Postgres table부터 만든다. - 두 connector: Wiki와 Slack 한 channel만 연결한다. Slack reply가 오면 thread 전체를 재수집하고 stable ID로 upsert한다.
- 두 표현: raw source에는 GIN full-text index를 두고, 검색용 normalized artifact에는 vector index를 둔다. 원문을 덮어쓰지 않는다.
- 세 retrieval: full-text, vector, freshness-aware ranking을 각각 top-k로 실행한 뒤 RRF로 합친다.
- 근거 packet: source-level dedupe, project/ACL filter, 주변 context 복원 후에만 synthesis model로 넘긴다.
- 관측: 질문, 선택된 tool, 후보 source, rank, citation, user feedback, repair event를 immutable log로 남긴다.
- 확장: 20개 질문에서 기준선을 넘은 뒤 burst embedding, code indexing, recent PR, who-knows를 하나씩 추가한다.
3,072-dim이나 threshold를 정답처럼 복사하기보다, 자기 질문 세트에서 baseline → 한 가지 변경 → 재평가로 선택해야 한다.마치며
Company Brain이라는 표현은 하나의 거대한 두뇌를 떠올리게 한다. 하지만 실제로 필요한 것은 더 분산된 구조에 가깝다. 각 시스템은 자기 일을 계속하고, 공통 context layer가 필요한 순간에 근거를 모은다.
그래서 질문을 바꿔야 한다.
우리 회사의 문서가 얼마나 많이 쌓였는가가 아니라, 중요한 질문에 최신 근거와 권한을 지키며 답할 수 있는가?
나는 이 질문부터 실제 업무 20개로 검증해보려 한다. Company Brain의 출발점은 대규모 이관이 아니라, 자주 묻는 질문 하나를 틀리지 않게 답하는 일이다.
원문과 참고 자료
- Cerebras — How We Built Our Knowledge Base (Isaac Tai, Daniel Kim, Mike Gao, 2026-07-15)
- Malkov & Yashunin — HNSW
- Cormack, Clarke & Büttcher — Reciprocal Rank Fusion
- Anthropic — Introducing Contextual Retrieval
- CocoIndex — incremental code/document indexing
- @choi.openai의 Threads 해설 — 원문을 발견한 경로
이 글은 원문의 전체 번역이 아니라 구현 구조를 요약하고, 실제 조직 적용 조건과 한계를 덧붙인 리뷰다. Cerebras의 사용량 수치는 회사가 공개한 수치이며 독립 검증 결과는 아니다.