\"그거 어디 있죠?\" \"이거 누가 담당이죠?\" — 회사가 커질수록 정보는 흩어지고, 같은 질문이 반복된다. Cerebras는 Slack·코드·문서를 하나의 임베딩 테이블로 모아 하루 15,000개 질문에 답하는 사내 지식 베이스를 만들었다. 그 안에는 반세기 검색의 역사가 응축돼 있다. 키워드 검색에서 BM25, 임베딩, HNSW, 하이브리드, 그리고 에이전트 검색까지 — 왜 이런 개념들이 하나씩 필요해졌는지, 인터랙티브하게 만져보며 이해한다.
새 회사에 출근한 지 사흘째. 당신은 간단한 걸 하려던 참이다. 학습 잡을 하나 돌리려면 체크포인트를 어디에 저장해야 하는지, 그 규칙이 어디에 적혀 있는지 알고 싶을 뿐이다.
그런데 그 정보는 어디에도 없다. 아니, 모든 곳에 있다. 누군가는 3개월 전 Slack 스레드에서 설명했고, 진짜 규칙은 GitHub 어느 저장소의 설정 파일에 박혀 있으며, 관련 논의는 Jira 티켓 코멘트에 남아 있고, 공식 문서는… 반년째 업데이트가 안 됐다.
결국 당신은 채널에 질문을 올린다. "혹시 체크포인트 저장 경로 규칙 어디서 볼 수 있을까요?" 그리고 깨닫는다. 지난주에 다른 신입이 똑같은 질문을 했다는 걸.
이건 특정 회사의 이야기가 아니다. 조직이 조금만 커지면 반드시 나타나는 현상이다. 그리고 2026년, AI 반도체 회사 Cerebras는 이 문제를 정면으로 풀었다. 그들이 만든 사내 지식 베이스 Cerebras Knowledge는 출시 3개월 만에 사내에서 가장 널리 쓰이는 도구가 됐고, 지금 하루 15,000개 이상의 질문에 답한다. 사람이 묻고, 자동화가 묻고, 에이전트가 묻는다.
이 글은 그들이 공개한 엔지니어링 기록을 깊이 뜯어보는 특집이다. 단순한 사례 소개가 아니다. 그 시스템 안에는 반세기에 걸친 정보 검색의 역사가 통째로 압축돼 있다. 키워드 검색이 왜 부족했는지, 임베딩이 왜 등장했는지, 그런데 임베딩만으로도 왜 안 되는지, 그래서 왜 '하이브리드'와 '에이전트'가 필요해졌는지 — 이 개념들이 하나씩 왜 필요해졌는지를, 직접 만져보는 인터랙티브 도구와 함께 풀어보자.
정보가 흩어져 있다는 문제 앞에서, 조직은 분기마다 똑같은 '천재적 해법'을 떠올린다.
"우리 이제부터 모든 걸 이 플랫폼 한 곳에 기록합시다. 단일 진실의 원천(Single Source of Truth)을 만드는 겁니다."
그리고 이 꿈은, 거의 항상 실패한다.
왜일까? Cerebras 팀의 통찰이 정확하다. 정보는 그것을 만들기 가장 편하고 자연스러운 곳에서 생긴다. 문서에는 제안 편집(suggested edit)이 달리고, 실시간 논의는 Slack 스레드에서 벌어지고, 코드 참조는 GitHub에 있고, 상태 메타데이터는 Jira에 쌓인다. 이 플랫폼들은 각자의 영역에 맞게 수년간 다듬어진 도구다. Pull Request 리뷰를 구글 독스에서 하라고 하면? 그건 끔찍한 경험이다.
그래서 Cerebras는 발상을 뒤집었다. 사람들의 행동을 바꾸려 하지 말자. 대신 정보가 이미 사는 곳으로 우리가 찾아가자(meeting data where it lives). 데이터를 한곳으로 이주시키는 대신, 각 플랫폼에서 직접 데이터를 추출해 오는 것이다.
여기서 핵심 질문이 생긴다. Slack의 잡담과 GitHub의 코드와 Jira의 티켓처럼 성격이 완전히 다른 데이터를, 어떻게 하나의 방식으로 검색할 것인가? 이 질문에 답하려면, 먼저 '검색'이라는 것이 지난 반세기 동안 어떻게 진화해 왔는지를 알아야 한다.
우리가 오늘 당연하게 여기는 '검색'은 사실 여러 세대의 아이디어가 층층이 쌓인 결과물이다. Cerebras의 지식 베이스는 이 역사의 거의 모든 층을 동시에 사용한다. 각 시대를 눌러보며, 어떤 개념이 왜 필요했는지 짚어보자.
이 흐름을 관통하는 이야기는 이렇게 요약된다.
1세대 — 어휘 검색(Lexical). 초기 검색은 단어의 '정확한 일치'였다. 문서에 어떤 단어가 있는지 역색인(inverted index)으로 훑는다. 여기에 1972년 Karen Spärck Jones의 IDF(역문서빈도) 개념이 더해진다. "흔한 단어(‘the’, ‘그리고’)는 덜 중요하고, 희귀한 단어는 더 중요하다." 그리고 1994년, 문서 길이까지 보정하는 BM25가 등장해 오늘날까지 full-text 검색의 표준으로 군림한다. 에러 문자열, 플래그 이름, 호스트 이름처럼 글자 하나 안 틀리게 일치해야 하는 검색에서 BM25는 30년째 최강이다.
2세대 — 의미 검색(Semantic). 문제는, 사람은 같은 것을 다른 말로 표현한다는 것이다. "복원이 매니페스트 로드 후 멈춰요"와 "체크포인트가 NFS 마운트에서 hang" — 단어는 하나도 안 겹치지만 같은 문제다. 어휘 검색은 이걸 절대 연결하지 못한다. 2013년 word2vec은 단어를 벡터(좌표)로 바꿔, 의미의 유사도를 거리로 계산할 수 있게 했다. king − man + woman ≈ queen이라는 그 유명한 시연이 여기서 나왔다. 2020년 DPR(Dense Passage Retrieval)에 이르러 "질문 임베딩 ↔ 문서 임베딩"의 의미 검색이 표준이 된다.
의미 검색을 실용 속도로 만든 숨은 영웅은 따로 있다. 수십억 개의 벡터에서 "가장 가까운 것"을 매번 전부 비교하면 너무 느리다. 2016년 Malkov와 Yashunin이 제안한 HNSW(Hierarchical Navigable Small World)는 계층적 그래프로 근사 최근접 이웃(ANN) 탐색을 실용 속도로 끌어올렸다. 오늘날 모든 벡터 데이터베이스가 그 위에 서 있다. Cerebras의 임베딩 검색도 마찬가지다.
📄 더 깊이: Malkov & Yashunin, Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs (arXiv:1603.09320, IEEE TPAMI 2018). 벡터 검색이 '되는' 이유가 궁금하다면 이 논문이 출발점이다.
3세대 — 하이브리드(Hybrid). 그런데 곧 밝혀진다. 의미 검색만으로도 안 된다는 것이. 이게 이 글의 핵심이니, 다음 장에서 직접 실험해 보자.
Cerebras 팀도 처음엔 순진했다. "그냥 Slack 텍스트를 통째로 임베딩해서 벡터 검색하면 되지 않을까?" 곧 그들은 벡터 검색만으로는 관련 데이터를 제대로 못 찾는다는 걸 깨달았다. Slack 메시지에는 고약한 특성이 있었다.
이 "짧은 메시지의 역설"이 바로 하이브리드 검색이 필요한 이유다. Cerebras는 하나의 스코어러도 혼자서는 신뢰하지 않기로 했다. 대신 네 가지 검색 기법이 각자 같은 코퍼스를 랭킹하고, 서로의 약점을 메우게 했다.
| 스코어러 | 잡아내는 것 | 보완하는 약점 |
|---|---|---|
| Full-text (BM25) | 에러 문자열·플래그·호스트명 등 정확 토큰 | 임베딩이 뭉개버리는 '글자 그대로의 일치' |
| 임베딩 (의미) | 단어가 안 겹치는 패러프레이즈 | 어휘 검색이 놓치는 '다른 말로 한 같은 질문' |
| IDF (희귀도) | 희귀 토큰을 담은 알짜 메시지 | "넵 굿"처럼 의미공간에선 가까워 보이는 필러 |
| Age decay (신선도) | 최신 스레드 우대 | 반년 전, 지금은 없어진 인프라를 설명하는 낡은 답변 |
말로만 들으면 추상적이다. 직접 켜고 꺼보자. 아래는 실제 Slack 코퍼스(M1~M6)를 두고, 네 스코어러가 각각 어떻게 랭킹하고 그것이 RRF로 어떻게 융합되는지 보여주는 실험실이다. ‘다른 말로 바꾼 질문’을 고른 뒤 IDF를 꺼보라. 필러가 올라온다. Age decay를 꺼보라. 폐기된 구버전이 올라온다.
직접 만져봤다면 감이 왔을 것이다. 각 스코어러는 혼자서는 반드시 어딘가에서 틀린다. 네 개를 모두 켰을 때에만 진짜 정답이 안정적으로 1위에 선다. 이것이 하이브리드 검색의 본질이다. 그런데 서로 성격이 다른 네 개의 순위 리스트를, 대체 어떻게 하나로 합치는가? 그 답은 뒤에서(9장) 자세히 다룬다. 먼저 이 모든 게 얹히는 '그릇'부터 보자.
Cerebras Knowledge는 세 가지를 제공한다.
그리고 이 모든 것의 한가운데에는 단 하나의 Postgres 테이블이 있다. 이 테이블에는 임베딩, 원본 요약(raw summary), 그리고 메타데이터가 여러 소스에서 흘러들어와 함께 담긴다. 시스템은 회사 전역에서 데이터를 끊임없이 인제스트하며, 언제든 질의할 수 있는 상태를 유지한다.
디자인 철학은 의도적으로 단순하다. Slack 스레드든, 코드 조각이든, 심지어 칩 설계의 넷리스트(netlist)든 — 모든 소스가 똑같은 임베딩 테이블의 한 행(row)으로 안착한다. 그리고 그 테이블에 들어간 것은 무엇이든 즉시, 같은 인터페이스로 검색된다.
각 데이터 소스는 세 가지만 정의하면 된다. (1) 이 데이터가 무엇인지, (2) 어떻게 연결하는지, (3) 얼마나 자주 가져올지. 그 결과로 생긴 임베딩 행은, 출처가 Slack이든 코드 저장소든 문서든 커스텀 DB든 똑같은 인터페이스를 따른다. 덕분에 사내 개발자 누구나 자기만의 커넥터를 만들어 붙일 수 있다.
이 단순함이 왜 강력한지는 뒤에서 드러난다. 지금은 이 그릇에 가장 어려운 데이터, Slack을 어떻게 담았는지부터 보자.
Slack은 Cerebras가 가장 공들여 설계한 소스다. 회사에서 가장 최신의, 가장 생생한 엔지니어링 논의가 벌어지는 곳이기 때문이다. 하지만 앞서 봤듯 Slack은 가장 다루기 어려운 데이터이기도 하다. 세 단계로 정복했다.
먼저, 데이터를 실시간으로 가져와야 한다. Cerebras는 워크스페이스에 Slack 봇을 설치하고 Socket Mode로 돌렸다. Slack이 모든 메시지 이벤트를 지속 연결된 WebSocket으로 밀어주므로, Web API를 폴링하며 레이트 리밋을 태우지 않고도 실시간 업데이트를 받는다.
이벤트가 도착하면 즉시 확인(ack)하고, 안정적인 이벤트 ID로 중복 제거한 뒤, 인제스트 컨슈머가 처리하도록 표시한다. 여기서 영리한 부분 — 인제스트 컨슈머는 새 메시지 하나만 따로 저장하지 않는다. 그 메시지가 속한 스레드 전체를 다시 가져와서(부모 메시지와 모든 답글 포함), 하나의 행으로 통째로 다시 쓴다.
덕분에 저장된 내용, 참여자 목록, 마지막 활동 타임스탬프가 항상 완전한 대화 상태를 반영한다. 또 하나 — Slack 채널마다 각자 독립된 데이터 소스다. 바쁜 장애 대응 채널은 더 자주, 한산한 채널은 덜 자주. 데이터 신선도를 채널 단위로 세밀하게 조절할 수 있다.
원본 Slack 텍스트는 landing 즉시 키워드 검색이 된다. Postgres full-text(GIN) 인덱스를 원본 위에 유지하기 때문이다. 하지만 쓸 만한 벡터 검색을 위해서는 추가 처리가 필요하다. 여기서 Cerebras는 흥미로운 결정을 내린다 — 원본 대화를 그대로 임베딩하지 않는다.
대신 증류(distillation) 단계에서, LLM이 스레드 전체를 읽고 구조화된 데이터를 뽑아낸다.
이 네 조각을 임베딩해서 공용 테이블에 기록한다. 원본 대화 전문(transcript)은 임베딩하지 않는다.
왜 이렇게 할까? Cerebras의 실험에서, 스레드를 일관된 형식으로 정규화하자 정확도가 크게 올랐다. 어수선한 대화 원본보다, "질문–요약–해결–참조"라는 깔끔한 구조가 의미 매칭에 훨씬 유용한 신호를 준다. 이것은 우연이 아니다. Anthropic이 2024년 발표한 Contextual Retrieval과 Slack 엔지니어링의 대규모 메시지 처리 경험이 모두 가리키는 방향이다 — 청크를 날것으로 두지 말고, 검색에 유리하게 재가공하라.
여기까지 왔는데도 문제가 남았다. 긴 스레드 안의 중요한 메시지가, 스레드 요약에는 안 담기는 경우다. 열 명이 스무 개 메시지를 주고받은 스레드에서, 정답은 중간의 곁가지 메시지 하나에 있을 수 있다. 그 메시지의 어휘는 스레드 요약에 반영되지 않아, 검색으로는 영영 못 찾는다.
해법이 버스팅(bursting)이다. '버스트'란 같은 작성자가 연속으로 남긴 메시지 묶음이다. 각 버스트를 개별적으로 임베딩하되, 스레드 주제를 앞에 붙여(prepend) 맥락을 준다. (이것이 바로 Contextual Retrieval 아이디어의 직계다.) 그러면 그 곁가지 메시지가 독립적으로 검색 가능해진다.
단, 아무 버스트나 임베딩하면 저신호 데이터가 DB를 오염시킨다. 그래서 각 버스트는 가중 신호 조합으로 채점되어 문턱을 넘어야만 임베딩된다.
문턱을 넘은 버스트만 증류를 거쳐 임베딩되어, 스레드 레벨 레코드와 나란히 테이블에 저장된다. 이렇게 Cerebras는 "짧은 메시지의 역설"을 뒤집는다. 이제 알짜배기 한 줄도, 제 무게만큼 검색된다.
다음 소스는 코드다. 그런데 여기서 팀은 잠시 망설였다. Claude Code 같은 커맨드라인 도구가 부상하면서, "코드는 그냥 grep(ripgrep)이면 충분한 거 아냐?"라는 회의가 있었기 때문이다. 코드 임베딩을 만드는 게 반직관적으로 느껴졌다.
하지만 업계 사람들과 대화하고, 대규모 코드베이스에서의 시맨틱 검색에 관한 Cursor의 연구를 읽은 뒤 그들은 시도해 보기로 한다. 결정적 고민은 효율적으로 최신 상태를 유지하는 법이었다. 내부 저장소 중에는 40GB가 넘는 것도 있으니까.
답은 CocoIndex였다. 코드베이스 벡터화에 특화된 오픈소스 문서 임베딩 프레임워크다. 작동 방식이 영리하다.
CocoIndex는 동기화 메타데이터를 Postgres에 추적한다. 그래서 커밋이 있을 때마다 저장소 전체를 다시 계산하는 대신 변경된 코드 청크만 재임베딩·재수출한다. 이게 특히 잘 맞았던 이유 — 동기화 상태와 임베딩 저장소가 같은 데이터베이스에 살기 때문이다. (4장의 "단 하나의 테이블" 철학이 여기서 빛을 발한다.) 저장소가 늘어나자, 팀은 저장소 온보딩 자체를 설정 파일로 옮겨, 각 팀이 파일 경로 단위 allowlist/denylist와 함께 스스로 제출하게 했다.
일부 팀은 이미 자기 데이터베이스를 갖고 있었고, 그걸 Slack이나 문서로 옮기고 싶어 하지 않았다. 그저 자기 테이블 위에서 같은 검색 경험을 원했을 뿐이다.
Cerebras의 답은 우아하다. 커스텀 소스를 플러그인 스크립트로 취급한다. 팀은 작은 파이썬 모듈 하나를 PR로 올린다. 그 모듈은 자기 시스템에서 데이터를 읽어, 임베딩 테이블과 같은 모양의 행으로 뱉어내면 된다. 매칭되는 데이터 소스 항목 하나와 함께.
그 스크립트가 모두와 똑같은 스키마로 공용 DB에 쓰기만 하면, 스택의 나머지는 손댈 필요 없이 그대로 작동한다. 그 데이터는 Slack·코드·문서와 나란히, 아무런 특별 처리 없이 검색된다.
이것이 4장에서 강조한 "의도적 단순함"의 배당금이다. 인터페이스 하나를 단순하고 안정적으로 유지했더니, 확장은 덧셈이 된다. 새 소스를 붙이는 데 코어를 건드릴 필요가 없다. 좋은 소프트웨어 설계의 교과서적 사례다.
이제 데이터는 다 모였다. 질문이 들어오면 무슨 일이 벌어질까? Cerebras는 요즘 에이전트 시스템의 정석인 계획 → 실행 → 종합(Planner → Executor → Synthesis) 패턴을 쓴다.
모든 질의에 대해, 먼저 짧은 계획(planning) 패스가 돈다. LLM이 "이 질문에 어떤 도구와 데이터 소스가 관련 있을까?"를 판단한다. 주요 도구는 이렇다.
| 도구 | 하는 일 |
|---|---|
| subsystem_index | 파일별 LLM 요약 |
| search | Slack·위키·코드를 아우르는 통합 벡터 파이프라인 (내부에서 병합·리랭크) |
| search_slack | Slack 직접 검색 |
| search_code | 소스 저장소에 대한 ripgrep |
| recent_prs | 질문과 관련된 최근 PR |
| who_knows | 해당 주제에 대해 입증된 전문성을 가진 사람 |
플래너는 "무엇이 색인돼 있는지"에 대한 압축된 설명 위에서 동작한다 — 어떤 프로젝트가 있고, 각 프로젝트에 어떤 소스가 있으며, 각 소스가 무엇에 답하기 좋은지. 그 정보를 바탕으로 도구를 선택하면, 실행기(executor)가 그것들을 병렬로 부채살처럼 흩뿌리고(fan-out), 결과를 공통 증거 형식으로 정규화한 뒤, 최종 종합(synthesis) LLM에 넘긴다.
이 패턴은 최근 연구 Search-o1(추론 모델이 스스로 검색을 계획·반복하게 하는)의 정신과 정확히 맞닿아 있다. 아래에서 질문 유형을 바꿔가며, 플래너가 질문에 따라 다른 도구 조합을 고르는 걸 직접 확인해 보자.
📄 더 깊이: Li et al., Search-o1: Agentic Search-Enhanced Large Reasoning Models (arXiv:2501.05366, 2025). 검색을 '한 번 쏘고 끝'이 아니라 추론 루프 안의 반복 행동으로 보는 관점.
3장에서 미뤄둔 질문에 답할 차례다. 성격이 다른 여러 검색기(retriever)의 순위 리스트를, 어떻게 하나로 합치는가?
먼저 문제를 직시하자. 어떤 문서는 단지 질의와 단어가 겹친다는 이유만으로 상위에 올라온다. 정작 다른 질문에 답하는 문서인데도. 이걸 걸러야 한다. Cerebras의 융합 무기는 RRF(Reciprocal Rank Fusion, 상호 순위 융합)다. 2009년 Cormack 등이 제안한, 놀랍도록 단순하고 강력한 공식이다.
모든 문서에 대해, 그 문서가 등장한 각 리스트마다 이만큼의 점수를 더한다.
· weight = 기본 1.0 (리스트별 신뢰 가중치) · 60 = 스무딩 상수 (consensus를 개별 1등보다 중시하게 만듦) · rank = 그 리스트에서의 순위
이 스무딩 상수 60이 핵심 마법이다. 이 값이 클수록 "한 리스트에서 압도적 1등"보다 "여러 리스트에 두루 상위"인 문서가 이긴다. 여러 검색기가 입 모아 추천하는 문서가, 한 검색기만 강하게 미는 문서를 앞서게 되는 것이다. 직접 슬라이더를 돌려보자.
RRF로 융합한 뒤에도 처리는 계속된다.
이 마지막 "맥락 되살리기" 단계는 그냥 나온 게 아니다. 2023년 논문 Lost in the Middle이 보여준 함정 때문이다 — LLM은 긴 컨텍스트의 중간에 있는 근거를 흘려버린다. 그러니 검색 결과를 전부 밀어넣는 건 오히려 독이다. 리랭킹으로 정말 중요한 상위 10개만 추리고, 각각에 이웃 맥락을 붙여 완결된 스니펫으로 만드는 게 낫다. 외로운 한 문단이 아니라, 제목과 전제가 살아 있는 조각을 주는 것이다.
📄 더 깊이: Liu et al., Lost in the Middle: How Language Models Use Long Contexts (arXiv:2307.03172, 2023). "긴 컨텍스트 = 항상 좋다"는 통념을 깨는 필독 논문.
그래서 search의 최종 출력물은 풍부한 증거 패킷이다. 여러 검색기에서 융합되고, 소스 단위로 중복 제거되고, 실제 질문에 맞춰 리랭킹되고, 그런 다음에야 주변 맥락으로 확장된 — 잘 다듬어진 근거 묶음.
Cerebras가 내린 또 하나의 현대적 결정은 MCP(Model Context Protocol) 통합이다. 여기서 그들은 검색을 하나의 "이 질문에 답해줘" 엔드포인트 뒤에 숨기지 않았다. 대신 검색의 구성 요소(building block)들을 각각 직접적인 도구로 노출했다.
| 설계 원칙 | 이유 |
|---|---|
| 도구 = 검색 프리미티브 1개 | search_slack·search_code·search·who_knows 각각이 하나의 검색 기본기에 대응 |
| 입출력을 좁고·구조적·안정적으로 | 어떤 클라이언트나 에이전트에서든 오케스트레이션 로직 없이 호출 가능 |
| 가능한 한 LLM-free | 도구는 빠르고 싸게 — 한 파이프라인(벡터/어휘/ripgrep) 돌리고 가벼운 점수만 매겨 원시 증거 행 반환 |
그 결과, 흥미로운 역할 전환이 일어난다. Claude Code 같은 MCP 호환 에이전트가 오케스트레이션 엔진이 된다. 어떤 도구를 어떤 순서로 부를지, 결과를 어떻게 최종 답변이나 코드 수정으로 엮을지를 에이전트가 결정한다. 검색 레이어 자체는 그 LLM의 판단에 의존하지 않고도 요청을 처리한다. 검색은 '재료'를 대고, 지능은 '요리사'인 에이전트에 있는 것이다.
한편 웹 UI에서는 같은 도구들이 이번엔 완결된 질의 파이프라인에 연결된다. UI 에이전트가 플래너와 실행기를 직접 소유하며 매 질문마다 처음부터 끝까지 돌린다 — 8장에서 본 planner → executor → synthesis 그대로다.
사용자 입장에서 웹 UI는 그저 "질문하면 답이 나오는 것"이다. 하지만 그 아래에서는, MCP 클라이언트가 명시적으로 재현할 수 있는 것과 똑같은 패턴이 돌아간다.
📄 더 깊이: Anthropic, Code Execution with MCP (2025). 도구를 어떻게 잘게, 조합 가능하게 노출할지에 대한 설계 철학.
코퍼스가 커지자 예상 못 한 문제가 터졌다. "모든 곳에서 모든 것을 검색"하는 게 급속도로 쓸모없어진 것이다. 컴파일러 팀 엔지니어는 인프라 런북이 결과에 섞여 나오는 걸 원치 않았고, 그 반대도 마찬가지였다.
Cerebras의 해법은 프로젝트(Project)다. 프로젝트란 데이터 소스들의 이름 붙은 묶음이다 — 특정 Slack 채널들, 코드 저장소들, 내부 DB들, 문서 공간들이 한 팀이나 이니셔티브를 중심으로 묶인다. 프로젝트는 의도적으로 가볍다. 공유 장애 채널이나 중앙 플랫폼 저장소 같은 같은 소스를, 여러 프로젝트가 복제 없이 참조할 수 있다.
그리고 온보딩에서 빛을 발한다. 신규 사용자는 자기 업무에 맞는 기본 프로젝트를 고르거나 만든다(예: ML 학습 인프라, 컴파일러, 데이터센터 운영). 그 기본 프로젝트가 프로필에 저장되어 질의 범위를 자동으로 좁힌다. 신입 엔지니어는 어떤 Slack 채널·저장소·문서가 중요한지 먼저 배울 필요 없이, 처음부터 고신호 답변을 받는다.
프롤로그의 그 신입을 기억하는가? 프로젝트는 정확히 그의 사흘째를 구원하는 장치다.
이 사례가 한 회사의 사내 도구 자랑에 그치지 않는 이유가 있다. 2026년의 기술 지형에서, 이것은 세 가지 큰 흐름의 교차점에 있다.
첫째, 데이터가 유일한 해자(moat)다. 모델은 상향 평준화되고 있다. 오픈 모델이 프론티어를 바짝 뒤쫓는 시대에, 남과 다른 답을 내는 힘은 당신 조직만이 가진 데이터에서 온다. Slack 구석의 장애 대응 노하우, 코드에 박힌 암묵지, 누가 무엇을 아는지 — 이것들은 복제 불가능한 자산이다. 문제는 접근성이었고, Cerebras는 그걸 풀었다.
둘째, 검색은 에이전트의 감각기관이다. 2026년의 AI는 '답을 아는 존재'가 아니라 '찾아서 답하는 존재'다. 에이전트가 아무리 똑똑해도, 회사의 진짜 맥락에 닿지 못하면 그럴듯한 환각을 내놓을 뿐이다. MCP로 노출된 검색 프리미티브는 에이전트에게 눈과 귀를 달아준다. RAG는 죽지 않았다 — 오히려 에이전트 시대의 필수 인프라로 격상됐다.
셋째, 추론 속도가 이걸 실시간으로 만든다. 잊지 말자. 이걸 만든 곳은 Cerebras, 세계에서 가장 빠른 AI 추론을 파는 회사다. planner·distillation·synthesis마다 LLM 호출이 겹겹이 쌓이는 이 파이프라인이 하루 15,000번 돌아가려면, 초고속·저지연 추론이 전제되어야 한다. 빠른 추론이 있어야 "질문하면 즉시 답"이 성립한다. 인프라와 응용이 한 몸으로 맞물린 것이다.
Cerebras의 기록에서 뽑아낼 수 있는 원칙은, 규모와 무관하게 유효하다.
결국 이 지식 베이스가 작동하는 이유는, 정보를 경직된 하나의 시스템에 욱여넣는 대신, 정보가 이미 사는 곳에서 사람을 만나기 때문이다. 여러 검색 기법을 결합해 근거를 빠르게 표면화하고, 실제 회사 데이터의 지저분함을 견딜 만큼 유연하면서도, 조직이 계속 커져도 쓸모를 잃지 않을 만큼 구조적이다.
반세기 전 역색인에서 시작한 검색의 역사는, 2026년 이 지점으로 수렴한다 — 조직의 흩어진 기억을, 사람과 에이전트가 함께 꺼내 쓰는 살아 있는 지식. 당신의 조직에도, 그 15,000개의 질문은 이미 매일 던져지고 있다. 답이 어디 있는지 아무도 모를 뿐이다.
코어닷투데이는 조직의 데이터를 진짜 자산으로 바꾸는 AI 시스템 — 하이브리드 검색, RAG, 사내 지식 에이전트 — 을 설계하고 구축합니다. 흩어진 지식으로 고민 중이라면, 함께 이야기 나눠요.
