사내 위키를 만들어 본 조직은 다 안다. 만드는 날이 제일 깨끗하고, 그날부터 낡는다. 그래서 Cerebras가 이번 주에 공개한 사내 지식베이스 ’Cerebras Knowledge’의 설계기는 흔한 “우리 RAG 만들었어요” 글이 아니다. 출시 석 달 만에 직원들이 하루 15,000개가 넘는 질문을 던지는, 회사에서 가장 널리 쓰이는 축의 내부 도구가 된 시스템의 유지 방법론이다.
숫자보다 눈여겨볼 건 사용자 구성이다. 이 지식베이스에 묻는 건 사람, 자동화 스크립트, 그리고 에이전트다. Cerebras는 데이터센터 운영부터 칩 설계, 하드웨어, 학습, 추론, 클라우드 플랫폼까지 팀이 흩어져 있고 매년 수백 명이 새로 합류하는 회사라, 채널마다 같은 질문이 반복됐다. “X 어디 있어요?”, “Y는 누가 전문가예요?”, “Z가 뭐예요?” 이런 질문을 받아주는 자리에 검색창을 놓았더니, 사람보다 먼저 시스템들이 단골이 됐다.
출발점: 단일 진실 공급원의 포기
Cerebras가 설계에서 처음 세운 원칙이 재밌다. 지식은 흩어져 있는 게 정상이라는 것. 분기마다 누군가 “모든 걸 한 플랫폼에 기록하자”고 제안하지만, 단일 진실 공급원(single source of truth)의 꿈은 현실에서 거의 작동하지 않는다고 못을 박는다.
이유는 간단하다. 정보는 만들기 편한 곳에서 생긴다. 문서엔 수정 제안이, Slack엔 스레드가, GitHub엔 코드 리뷰가, Jira엔 상태값이 쌓인다. 각 플랫폼은 그 도메인에 맞게 수년간 다듬어진 물건이고, 원문의 표현을 빌리면 “풀 리퀘스트를 구글 문서에서 논의하는 건 끔찍한 경험”이다.
그래서 방향을 뒤집었다. 사람을 플랫폼으로 옮기는 대신, 각 플랫폼에서 데이터를 직접 뽑아 오고 기존 습관은 건드리지 않는다. 구조는 의외로 소박하다. Postgres 테이블 하나에 모든 소스의 임베딩·요약·메타데이터가 들어가고, 커넥터가 소스별로 “무엇을, 어떻게, 얼마나 자주” 가져올지 정의한다. 자기 팀 데이터베이스를 연결하고 싶은 팀은 같은 스키마로 행을 써 넣는 파이썬 스크립트 하나를 PR로 올리면 끝이다. #13에서 다룬 AI-Ready Data의 회사 단위 실사판인 셈이다.
벡터 검색 하나로는 안 된다 — 4중 하이브리드
가장 공들인 소스는 Slack이다. 회사에서 가장 최신의 엔지니어링 논의가 오가는 곳이기 때문인데, 여기서 순수 벡터 검색의 한계가 바로 드러났다. Slack 메시지는 정보 밀도가 극과 극이다. “네 그러죠 마이크” 같은 한 줄과 커널 동작을 설명하는 장문이 똑같이 메시지 한 건이고, 짧은 메시지가 코사인 유사도에서 긴 설명을 이기는 일이 잦다.
그래서 검색 기법 네 개를 겹쳐 서로의 약점을 메운다.
- 전문(full-text) 검색 — 임베딩이 뭉개버리는 정확한 토큰을 잡는다. 에러 문자열, 플래그 이름, 호스트 이름. 엔지니어가 에러 메시지를 그대로 붙여넣었다면 어떤 의미 유사도도 정확한 일치를 이겨선 안 된다.
- 임베딩 검색 — 다른 어휘로 쓰인 같은 얘기를 잇는다. “manifest 로드 후 restore가 멈춰요”라고 묻는 사람과 “체크포인트가 NFS 마운트에서 지연되던데요”라고 답한 사람은 단어를 하나도 공유하지 않는다.
- 역문서빈도(IDF) — 신호와 잡담을 가른다. “좋아요, 감사!“는 임베딩 공간에서 많은 질의와 가깝지만, 토큰 희귀도를 반영하면 0점에 수렴한다.
- 나이 감쇠(age decay) — Slack 답변에는 유통기한이 있다는 사실을 점수에 새긴다. 6개월 전 스레드는 이제 존재하지 않는 인프라를 설명하고 있을 수 있다. 나머지가 같으면 새 답이 이긴다.
어느 하나도 단독으로 신뢰하지 않고, 네 개의 순위표를 질의 시점에 상호 순위 융합(RRF)으로 합친다. 문서마다 weight / (60 + rank)를 리스트별로 더하는 방식이라, 한 검색기에서 1등 한 문서보다 여러 검색기에 걸쳐 상위에 오른 문서가 앞선다. 그 뒤 소형 리랭커가 0~10점을 매겨 상위 10개만 남기고, 마지막으로 잘려나간 이웃 섹션을 다시 붙여 맥락 없는 외톨이 문단이 되는 걸 막는다.
방향 자체는 검증된 길이다. Anthropic의 Contextual Retrieval 실험에서도 컨텍스트를 붙인 임베딩+BM25 하이브리드가 검색 실패율을 49% 줄였고, 리랭킹까지 더하면 67%까지 내려갔다. Cerebras 글의 참고문헌에도 이 글이 올라 있다.
어려운 건 저장이 아니라 유지다
이 글에서 제일 값진 대목은 검색 알고리즘이 아니라 데이터가 낡는 것과 싸우는 방법들이다. 위키는 쓰인 날의 진실을 보관하지만, 브레인은 오늘의 진실을 내놓아야 한다.
원문을 그대로 임베딩하지 않는다. Slack 스레드는 저장 전에 LLM이 정규화한다. 엔지니어가 실제로 검색할 법한 한 줄 질문, 짧은 요약, 해결책, 언급된 시스템과 코드 참조. 이 네 가지를 임베딩하고 원문 트랜스크립트는 임베딩하지 않는다. 실험해 보니 일관된 형식으로 정규화했을 때 정확도가 크게 올랐다고 한다. 긴 스레드 속에 묻힌 곁가지 답변은 ’버스트(burst)’라는 단위로 따로 건진다. 같은 작성자의 연속 메시지 묶음에 스레드 주제를 앞에 붙여 별도로 임베딩하되, 아무거나 넣지 않도록 문턱을 둔다. 희귀 토큰(IDF 4.0 이상) 포함, 200자 이상, 리액션이 달렸으면 가산점.
코드는 커밋 단위로 산다. 40GB가 넘는 저장소도 있는데, 커밋마다 전체를 다시 계산하는 대신 오픈소스 프레임워크 CocoIndex로 바뀐 조각만 다시 임베딩한다. 코드는 언어별 경계 규칙으로 클래스 → 메서드 → 블록 순서로 쪼개고, 동기화 상태와 임베딩이 같은 Postgres에 살아서 관리가 단순해졌다. 저장소 등록도 팀이 직접 설정 파일로 올리는 셀프서비스다.
신선도는 채널 단위로 조절한다. Slack 채널 하나하나가 독립된 데이터 소스라서, 인시던트 채널은 더 자주 수집하는 식의 미세 조정이 가능하다. 수집 자체는 Socket Mode 웹소켓으로 실시간이고, 답글 하나가 달리면 그 스레드 전체를 다시 가져와 한 행으로 갱신한다 — 저장된 대화가 항상 완결된 최신 상태를 유지하도록.
grep이냐 임베딩이냐 — 답은 ‘둘 다’
Cerebras도 코드를 임베딩할지 오래 망설였다고 고백한다. Claude Code 같은 도구가 흔해지면서 “grep이면 충분한 것 아닌가(grep is all you need)” 하는 회의가 컸기 때문이다. 업계 사람들과 이야기하고 Cursor의 대규모 코드베이스 시맨틱 검색 실험을 읽은 뒤 내린 결론은 양자택일이 아니었다. 임베딩 검색 옆에 ripgrep 기반 search_code 도구가 그대로 남았다.
이건 이 시스템만의 결론이 아니다. LlamaIndex의 Jerry Liu는 “스캐폴딩의 시대는 끝났고 이제 컨텍스트가 해자”라고 선언하면서, 시맨틱 검색·키워드·grep·파일 읽기를 에이전트에게 한꺼번에 쥐여주는 리트리벌 하네스를 공개했다. #19에서 봤던 방향과 정확히 같다. 검색의 사용자가 사람에서 에이전트로 바뀌면, 검색은 답을 주는 서비스가 아니라 에이전트가 골라 쓰는 공구함이 된다.
사람용 검색창이 아니라 에이전트용 부품
그 공구함 철학이 인터페이스 설계에 그대로 박혀 있다. Cerebras는 MCP 통합에서 “질문하면 답해줄게” 엔드포인트 하나를 노출하는 대신, 검색 프리미티브를 낱개 도구로 노출한다. search, search_slack, search_code, who_knows(이 주제 전문가가 누구인지), recent_prs까지, 각 도구는 의도적으로 단순하고 가능한 한 LLM 없이 돌아가서 싸고 빠르다. 오케스트레이션은 도구 안에 없다. Claude Code든 어떤 MCP 에이전트든, 부르는 쪽이 조립을 담당한다. #29에서 다룬 “도구 설계가 곧 에이전트 품질”이라는 명제가 사내 인프라 층위에서 반복되는 모습이다.
사람이 쓰는 웹 UI는 같은 부품 위에 플래너 → 실행기 → 합성기 파이프라인을 얹은 것이다. 가벼운 LLM 패스가 질의를 보고 어떤 도구를 부를지 계획하고, 도구 호출을 병렬로 흩뿌린 뒤 결과를 공통 증거 형식으로 정규화하고, 마지막 LLM이 인용과 단서를 붙여 답을 합성한다.
마지막 조각은 범위다. 코퍼스가 커지자 “모든 걸 모든 곳에서 검색”은 빠르게 쓸모를 잃었다. 컴파일러 팀 엔지니어는 인프라 런북이 결과에 섞이는 걸 원하지 않는다. 그래서 Slack 채널·저장소·문서 공간을 팀 단위로 묶은 ’프로젝트’를 만들고, 온보딩 때 자기 업무에 맞는 기본 프로젝트를 고르게 해서 프로필에 저장한다. 신입은 어느 채널이 중요한지 배우기 전에 고신호 답부터 받는다. #30에서 다룬 컨텍스트 엔지니어링의 핵심이 “무엇을 넣을까”가 아니라 “무엇을 뺄까”였는데, 같은 원리가 회사 단위 검색에도 적용되는 것이다.
시장은 이미 값을 매기고 있다
이 물건에 가격표가 붙기 시작했다. 상업용 컴퍼니 브레인의 대표 주자 Glean은 지난해 6월 기업가치 72억 달러를 인정받았고, 올해 5월 연간반복매출 3억 달러를 넘겼다. 15개월 만에 3배, 전년 대비 89% 성장이다. 성장의 명분이 흥미롭다. AI 예산이 깎이는 시기에, 흩어진 도구를 하나의 컨텍스트 층으로 묶어 비용을 줄여준다는 걸 세일즈 포인트로 삼고 있다.
Cerebras 사례와 Glean의 숫자가 가리키는 수요는 같다. 모델은 어느 회사나 API로 빌려 쓸 수 있게 됐고, 에이전트 루프도 상향 평준화됐다. 그러면 남는 차이는 에이전트에게 무엇을 읽혀줄 수 있느냐다. 회사의 기억은 빌려 올 수 없고, 사서 붙일 수도 없다. 축적하고 유지하는 수밖에 없다.
에이전트 시대에 이게 비용 문제가 되는 것도 명확하다. 검색이 한 번 어긋나면 에이전트는 같은 걸 다른 방식으로 다시 찾느라 추론을 한 바퀴 더 돌고, 그만큼 토큰과 시간이 나간다. 더 나쁜 쪽은 #34에서 본 대로 불충분한 컨텍스트를 쥐고도 그럴듯하게 답해버리는 경우다. 검색 품질은 이제 UX 지표가 아니라 에이전트 운영비와 신뢰도의 원가다.
실전: 우리 회사에 브레인을 들일 때 여섯 가지
Cerebras 설계에서 이식할 만한 원칙을 추리면 여섯 개다.
1) 모으지 말고 연결하라. “이번엔 진짜 한곳에 다 기록하자”는 제안이 나오면 이 글을 보여주면 된다. 사람의 습관을 바꾸는 설계는 진다. 데이터가 생기는 곳에 커넥터를 꽂아라.
2) 벡터 검색 하나로 시작하지 마라. 전문 검색 + 임베딩 + 희귀도 + 신선도, 그리고 RRF 융합까지가 한 세트다. Postgres라면 GIN 인덱스와 pgvector로 한 DB 안에서 다 된다. Cerebras가 그렇게 했다.
3) 원문을 임베딩하지 말고 정규화해서 임베딩하라. 질문 한 줄·요약·해결책·관련 시스템. 검색당하는 형태로 저장해야 검색이 된다.
4) 신선도를 1급 신호로 다뤄라. 나이 감쇠를 점수에 넣고, 코드는 커밋 단위 증분 재임베딩으로 살아 있게 하라. 갱신 계획이 없는 지식베이스는 만드는 날부터 부채다.
5) 범위 좁히기를 기능이 아니라 기본값으로 만들어라. 전사 검색은 코퍼스가 커지는 순간 무너진다. 팀·프로젝트 단위 스코프를 온보딩 때 정하게 하라.
6) 사람용 UI보다 에이전트용 프리미티브를 먼저 설계하라. 단순하고 LLM 없는 검색 도구들을 MCP로 노출하면, 사람용 검색창은 그 위에 플래너와 합성기를 얹는 것으로 끝난다. 순서를 거꾸로 하면 에이전트가 못 쓰는 검색창만 남는다.
Cerebras 글이 공개 안 한 것도 있다. 검색 품질을 어떤 eval로 재는지, 오답률이 얼마인지는 안 나온다. 하루 15,000개 질문이라는 채택 지표가 품질의 간접 증거일 뿐이다. 그러니 이 설계를 따라가더라도 #32의 eval 파이프라인은 각자 세워야 한다.
남는 질문은 이거다. 당신 회사의 지식은 흩어진 채로 검색 가능한 상태인가, 아니면 한곳에 모으는 중이라며 낡아가고 있나. 브레인을 만드는 건 어렵지 않다. 살아 있게 유지하는 게 어렵고, Cerebras 글의 진짜 내용은 전부 후자에 관한 것이었다.