회사 규모가 커질수록 이상한 일이 생깁니다.
사람은 늘어나는데회사가 이미 알고 있는 것을 다시 묻는 시간도 같이 늘어납니다.
“이거 어디에 있어요?”“이 시스템은 누가 제일 잘 알아요?”“예전에 비슷한 장애가 있었나요?”“이 코드가 왜 이렇게 만들어졌죠?”
문제는 답이 없는 게 아닙니다.
답이 어디엔가 있다는 게 문제입니다.
Slack에 있을 수도 있고,GitHub PR에 있을 수도 있고,Jira 티켓이나 문서 한구석에 있을 수도 있습니다.
Cerebras가 최근 공개한 사내 지식베이스 Cerebras Knowledge 이야기가 흥미로운 이유입니다.
출시 약 3개월 만에 직원들이 하루 15,000개 이상의 질문을 던지는 내부 도구가 됐고, 이제는 사람뿐 아니라 자동화와 AI 에이전트까지 이 지식베이스를 사용합니다.
그런데 Cerebras가 선택한 방식은 의외로 단순합니다.
모든 지식을 하나의 시스템으로 옮기려고 하지 않았습니다.
‘Single Source of Truth’를 만들지 않았다
회사가 커지면 거의 반드시 이런 이야기가 나옵니다.
“문서를 한곳에 모읍시다.”
Notion으로 옮기고,Confluence를 정리하고,Wiki를 만들고,
이번에는 정말 모든 정보가 한곳에 모일 것처럼 시작합니다.
하지만 오래가지 않습니다.
사람들은 다시 Slack에서 이야기하고,개발자는 GitHub에서 논의하고,프로젝트 상태는 Jira에 남습니다.
왜냐하면 정보는 결국
사람이 일하는 곳에서 만들어지기 때문입니다.
Cerebras도 이 현실을 받아들였습니다.
문서의 수정 제안은 문서에 있고,엔지니어링 논의는 Slack에 있고,코드의 맥락은 GitHub에 있고,프로젝트 상태는 Jira에 있습니다.
그래서 기존 업무 방식을 바꾸는 대신AI가 데이터가 있는 곳으로 찾아가도록 만들었습니다.
저는 이 부분이 가장 중요하다고 봅니다.
AI 시대의 사내 지식 관리에서 중요한 것은
Single Source of Truth가 아니라Single Interface to Knowledge입니다.
데이터를 한곳에 모으는 것이 아니라흩어진 지식에 접근하는 하나의 인터페이스를 만드는 겁니다.
벡터DB 하나 붙인다고 회사의 지식이 되지는 않는다
구조를 보면 더 재미있습니다.
Cerebras는 여러 데이터 소스에서 가져온 임베딩, 요약, 메타데이터를 Postgres 중심의 공통 구조로 저장했습니다.
하지만 단순히
문서 → Chunk → Embedding → Vector Search
이렇게 만들지 않았습니다.
특히 Slack을 처리하는 방법이 흥미롭습니다.
Slack에는 이런 것들이 섞여 있습니다.
“좋습니다.”
“해결됐어요.”
“이 에러는 XYZ_CONFIG_FLAG 때문입니다.”
“6개월 전에도 같은 문제가 있었는데 당시에는 NFS 설정이 원인이었습니다.”
이걸 전부 임베딩해서 Semantic Search만 하면 결과가 좋을 수 없습니다.
그래서 Cerebras는 여러 검색 신호를 같이 사용합니다.
정확한 에러 문자열이나 호스트명은 Full-text Search,표현이 달라도 의미가 비슷한 질문은 Vector Search,희귀한 기술 용어는 IDF,오래돼서 더 이상 맞지 않을 수 있는 답변은 Time Decay를 적용합니다.
그리고 하나의 검색 방식만 믿지 않고 여러 검색 결과를 결합하고 다시 랭킹합니다.
여기서 중요한 사실이 하나 있습니다.
좋은 RAG는 더 많이 찾는 시스템이 아닙니다.
오히려
무엇을 보여주지 않을 것인가를 잘 결정하는 시스템입니다.
관련 없는 문서,오래된 정보,의미 없는 대화,
이런 것들을 얼마나 잘 제거하느냐가 답변 품질을 결정합니다.
원문을 그대로 임베딩하지 않았다
또 하나 인상적인 부분이 있습니다.
Cerebras는 Slack Thread 전체를 그대로 임베딩하는 것보다LLM이 대화를 먼저 이해하고 구조화하도록 만들었습니다.
질문이 무엇이었는지,어떤 맥락인지,어떻게 해결됐는지 등을 정리한 뒤 그 정보를 임베딩합니다.
실험에서는 이렇게 일관된 구조로 정규화했을 때 검색 정확도가 크게 좋아졌다고 설명합니다. 긴 Thread에서 중요한 메시지가 요약에 묻히는 문제를 보완하기 위해 개별 메시지 묶음도 별도로 평가해 일정 신호 이상의 내용만 임베딩합니다.
이건 꽤 중요한 힌트입니다.
많은 회사가 RAG를 만들면서
“우리 데이터를 어떻게 Embedding할까?”
부터 고민합니다.
그런데 더 중요한 질문은
“AI가 이해하기 좋은 지식의 형태로 어떻게 바꿀 것인가?”
일지도 모릅니다.
Raw Data와 Knowledge는 다릅니다.
회사의 모든 대화를 저장한다고회사 지식이 만들어지는 것은 아닙니다.
AI가 다시 사용할 수 있도록
맥락을 만들고,의미를 압축하고,중요도를 판단하고,출처를 연결해야
비로소 Reusable Knowledge가 됩니다.
그리고 이 지식베이스를 사람만 사용하지 않는다
제가 Cerebras 사례에서 가장 주목한 부분은 여기입니다.
이 시스템의 사용자는 직원만이 아닙니다.
AI Agent도 같은 지식을 사용합니다.
Cerebras는 search_slack, search_code, who_knows 같은 검색 기능을 MCP 도구 형태로 작게 노출했습니다.
검색 시스템 안에 거대한 Agent를 넣은 것이 아니라,
검색은 검색답게 만들고어떤 도구를 언제 사용할지는 Claude Code 같은 Agent가 결정하게 만든 겁니다.
이 구조는 앞으로 꽤 중요해질 것 같습니다.
지금 대부분의 회사는 AI Agent를 만들면서 Agent에게 새로운 지식을 넣으려고 합니다.
하지만 방향을 조금 바꿔볼 수 있습니다.
사람과 AI가 같은 회사 지식을 조회하게 만드는 겁니다.
사람이 물어봐도 같은 답을 찾고,
Coding Agent가 코드를 수정할 때도과거 PR과 장애 기록을 찾아보고,
Incident Agent가 장애를 분석할 때도이전 Slack Thread와 Runbook을 찾아보고,
새로운 직원이 들어와도“누구한테 물어봐야 하지?”부터 배우지 않아도 됩니다.
그때부터 Knowledge Base는
검색 서비스가 아니라
조직의 Context Infrastructure가 됩니다.
AI를 도입할수록 ‘회사 기억’이 중요해진다
AI Agent의 성능을 이야기하면 보통 모델부터 이야기합니다.
GPT가 좋은가.Claude가 좋은가.어떤 Coding Agent가 더 좋은가.
그런데 회사에서 실제로 일을 시켜보면 곧 다른 문제를 만납니다.
AI가 우리 회사를 모릅니다.
왜 이 결정을 했는지 모르고,
누가 전문가인지 모르고,
지난번 장애에서 무엇을 배웠는지 모르고,
어떤 코드가 어떤 운영상의 이유 때문에 존재하는지도 모릅니다.
결국 사람이 다시 설명합니다.
Agent가 바뀔 때마다 또 설명합니다.
그 순간부터 모델의 성능보다 중요한 것이 생깁니다.
조직의 Context를 얼마나 잘 축적하고 전달할 수 있는가.
Cerebras가 만든 것은 단순한 RAG 시스템이라기보다이 문제를 해결하기 위한 하나의 기반에 가깝습니다.
앞으로 회사의 경쟁력은 ‘얼마나 많이 알고 있느냐’가 아닐지도 모릅니다
대부분의 회사에는 이미 엄청난 지식이 있습니다.
Slack에도 있고,메일에도 있고,GitHub에도 있고,회의록에도 있고,사람들의 머릿속에도 있습니다.
문제는 그 지식을
필요한 순간에 꺼낼 수 없다는 것입니다.
AI 시대에는 이 차이가 더 커집니다.
지식을 잘 연결해 놓은 회사에서는
사람 한 명의 경험이다음 사람에게 전달되고,
한 번 해결한 문제가다음 Agent의 Context가 되고,
하나의 의사결정이다음 의사결정의 출발점이 됩니다.
반대로 연결되지 않은 회사에서는
AI Agent가 아무리 많아져도매번 처음부터 다시 회사에 대해 배워야 합니다.
그래서 저는 앞으로 중요한 질문이
“우리 회사에 AI Agent가 몇 개 있는가?”보다
“우리 회사의 지식을 사람과 Agent가 얼마나 잘 공유하고 있는가?”
가 될 거라고 봅니다.
회사의 두뇌는 모든 정보를 한곳에 저장한다고 만들어지지 않습니다.
회사 곳곳에 흩어진 기억을필요한 순간에 꺼내 쓸 수 있을 때 만들어집니다.
[원문]
의견을 남겨주세요