Field Log · Entry

Cerebras 사내 지식 검색 해부: Single Retrieval Layer를 PE Agent에 적용하는 법

Slack 코드 문서 내부 DB가 공통 검색 계층을 거쳐 사람과 PE Agent에 근거를 전달하는 Cerebras Knowledge 구조

이번 글의 결론

사내 지식을 한곳으로 옮기는 대신, 정보가 생기는 기존 시스템 위에 Single Retrieval Layer를 둔다.

Slack·코드·SOP·정비로그는 같은 청킹과 검색법을 쓰지 않고, 출처별로 검색 가능한 표현을 만든다.

Exact·semantic·희귀도·최신성 신호를 병렬 검색한 뒤 RRF·문서 중복 제거·reranking·문맥 확장으로 근거 묶음을 만든다.

Project scope는 관련도를 위한 장치이고 ACL은 보안 장치다. 둘을 같은 필터로 취급하면 안 된다.

반도체 PE Agent에는 여기에 고객사·설비 모델·문서 권위·유효기간·검증 상태를 추가해야 한다.

Cerebras가 공개한 사내 지식 검색 시스템의 핵심은 거대한 위키나 단일 RAG 챗봇이 아니다. Slack, 코드, 문서, 내부 DB는 각자 잘하는 위치에 남겨 두고 질문할 때 필요한 근거를 공통 형식으로 가져오는 검색 계층이다. 나는 이 구조를 Single Source of Truth가 아니라 Single Retrieval Layer라고 이해했다.

Cerebras는 출시 약 3개월 뒤 사람·자동화·AI 에이전트가 이 시스템에 하루 15,000건 이상 질문한다고 밝혔다. 다만 이 숫자는 Cerebras의 자체 공개 사용량이지, 검색 정확도나 업무시간 절감률은 아니다. 이 글에서는 공개된 구조를 해부하고, 현재 만들고 있는 반도체 장비 PE Agent와 시계열 기반 로그 검색에 무엇을 가져올지 구분해 본다.

Single Source of Truth가 아니라 Single Retrieval Layer다

조직 지식 프로젝트는 자주 “모든 내용을 한 플랫폼에 정리하자”로 시작한다. 하지만 실제 정보는 가장 편한 곳에서 생긴다. 설계 논의는 Slack, 변경 이유는 GitHub PR, 공식 절차는 SOP, 설비 이력은 정비 DB에 남는다. 이들을 억지로 한 위키로 옮기면 작성 습관을 바꾸는 비용이 생기고, 이관되지 않은 지식은 더 빨리 늘어난다.

Cerebras의 공식 글은 기존 작성 위치를 유지하는 쪽을 택했다. 출처별 수집기가 데이터를 가져와 공통 검색 레코드로 만들고, 질문 시점에는 하나의 인터페이스로 조회한다.

Slack ─────────┐
Wiki / Docs ───┤
GitHub / Code ─┤
Internal DB ───┤
Custom Source ─┘
        │
        ▼
Source-specific ingestion & transformation
        │
        ▼
Common evidence schema
Postgres + full-text index + embedding index
        │
        ▼
Project scope → tool routing → parallel retrieval
        │
        ▼
RRF → dedupe → rerank → context expansion
        │
        ▼
Evidence bundle → answer with references

여기서 “데이터가 원래 위치에 남는다”는 말을 조심해서 읽어야 한다. 업무 작성 위치를 바꾸지 않는다는 뜻이지, 중앙 검색 서버에 데이터가 복제되지 않는다는 뜻은 아니다. 원문 일부, 요약, 메타데이터, 임베딩과 캐시는 검색을 위해 중앙에 저장된다.

따라서 보안 대상도 원본 시스템만이 아니다.

검색용 원문과 정규화된 요약
임베딩과 full-text index
query·result cache
인용을 포함한 최종 답변
접근·검색 감사 로그

중앙 위키를 만들지 않았다고 해서 중앙 보안 책임이 사라지는 것은 아니다. 오히려 여러 시스템의 파생 데이터가 한곳에 모이므로, 검색 계층 자체가 중요한 데이터 시스템이 된다.

Slack과 코드는 같은 문서가 아니다

이 사례에서 가장 가져올 가치가 큰 부분은 출처에 따라 전처리와 검색 방법을 바꾼 것이다. Slack 스레드와 소스 코드를 같은 크기로 잘라 같은 embedding model에 넣는 방식은 단순하지만, 각 출처의 중요한 신호를 잃기 쉽다.

Slack은 네 가지 검색 신호를 함께 쓴다

Slack 메시지를 한 건씩 임베딩하면 “네, 좋습니다” 같은 짧은 문장이 높은 유사도를 얻을 수 있다. 오류 코드와 설정 이름은 벡터에서 희석되고, 답변의 의미는 앞뒤 대화에 묶여 있으며, 오래된 해결책과 최신 해결책도 구분하기 어렵다.

Cerebras는 이를 하나의 점수로 해결하지 않았다.

검색 신호	맡는 역할	반도체 장비 예시
Full-text	정확한 문자열	`LEAK 900`, `RF Time Unmatching`, 모델명
Embedding	다른 표현의 같은 의미	“정렬 timeout” ↔ “stage가 home에 못 감”
IDF	희귀 토큰 강조	드문 alarm code, 부품명, recipe parameter
Time decay	비슷한 관련도에서 최신 사례 우선	최근 firmware·SOP 변경 뒤의 해결 기록

SUPRA VPLUS LEAK 900처럼 모델명·숫자·알람명이 붙은 질문은 semantic search만으로는 부족하다. 정확한 token은 lexical search가 찾고, 자연어 표현 차이는 embedding search가 보완해야 한다. 최신성은 둘의 관련도가 비슷할 때 tie-breaker로 작동해야지, 공식 문서를 무조건 밀어내는 절대 점수가 되어서는 안 된다.

원문 대화를 검색 가능한 사건 문서로 바꾼다

Cerebras는 Slack 원문 전체를 그대로 임베딩하지 않는다. LLM이 스레드에서 검색용 질문, 요약, 해결책, 관련 시스템과 코드 참조를 추출하고, 이 정규화된 표현을 임베딩한다. 원문은 exact search와 검증을 위해 별도로 보존한다.

searchable_question:
  SUPRA VPLUS에서 Cooling Stage Align Time Out이 발생한 원인은 무엇인가?

summary:
  Stage home position 확인 중 timeout이 발생했다.

resolution:
  Sensor 상태와 이동 간섭을 점검하고 home calibration을 다시 수행했다.

related_systems:
  - SUPRA VPLUS
  - Cooling Stage

code_or_part_references:
  - Home Sensor
  - Stage Motor

핵심은 임베딩 모델이 긴 대화를 알아서 이해하기를 기대하지 않는 데 있다.

원문을 바로 임베딩하지 말고, 검색하기 좋은 중간 표현을 만든 뒤 원문 검색과 함께 사용한다.

스레드 전체 요약에서 빠질 수 있는 중요한 메시지는 같은 작성자의 연속 발화를 burst로 묶어 별도 embedding으로 만든다. Cerebras가 공개한 희귀 token, 최소 길이, reaction emoji 같은 기준은 그 조직의 Slack 문화에서 얻은 heuristic이다. 다른 조직에 IDF 4.0, 200자를 그대로 복사하기보다 자체 평가셋으로 threshold를 다시 잡아야 한다. 이 Slack 전처리 과정은 공식 글의 한국어 요약에서도 단계별로 확인할 수 있다.

코드는 grep과 embedding의 역할을 분리한다

코드에서도 exact와 semantic은 대체 관계가 아니다.

검색 방식	잘 찾는 것
`ripgrep`	함수명, class명, 오류 문자열, 설정값
Code embedding	다른 이름으로 작성된 유사 역할의 구현
Git/PR 검색	왜 바뀌었는지, 최근 변경과 회귀 맥락
파일 요약 검색	subsystem이 어느 파일에 구현됐는지

대규모 저장소는 class→method→작은 block 순으로 언어 구조를 고려해 분할하고, 변경된 chunk만 증분 갱신한다. 이 원칙은 코드뿐 아니라 설비 문서에도 적용할 수 있다. SOP는 section·step·warning 구조를 보존하고, 정비 이력은 사건 단위, 시계열은 window 단위로 다뤄야 한다.

검색 품질은 top-k 이전과 이후가 함께 결정한다

검색기마다 점수의 의미와 범위가 다르다. Full-text의 점수와 cosine similarity를 그대로 더하면 한쪽 scale이 결과를 지배하기 쉽다. Cerebras는 각 검색기의 순위를 Reciprocal Rank Fusion(RRF)으로 결합한다.

RRF score(document)
  = Σ weight_i / (60 + rank_i(document))

여러 검색기에서 반복적으로 상위에 나온 문서는, 한 검색기에서만 1위인 문서보다 높은 최종 점수를 받을 수 있다. 이 공식과 구현 주의점은 Hybrid Search와 RRF 글에서 더 자세히 정리했다.

RRF가 끝은 아니다. 공개된 흐름을 단순화하면 다음과 같다.

full-text / embedding / IDF / freshness / code search
  → weighted RRF
  → same-parent chunk merge
  → per-file result cap
  → about 20 diverse candidates
  → query-aware reranking
  → about 10 winners
  → neighboring sections and raw context
  → evidence bundle

이 중 세 단계가 특히 중요하다.

Parent-document deduplication: 같은 원본의 여러 chunk가 top-k를 독점하지 못하게 한다.
Source·file cap: 특정 문서나 출처 하나가 후보 전체를 차지하지 못하게 한다.
Context expansion: 잘린 section의 앞뒤 조건·warning·제목을 다시 붙인다.

후보 약 20개를 다양화한 뒤 reranker로 약 10개를 남기는 수와 주변 section 복원 방식은 Cerebras 공식 구현 설명에 공개된 현재 설정이다. 이 숫자 자체가 보편적인 최적값은 아니다.

나는 도메인 RAG를 개선하면서 alias를 늘리는 것보다 먼저 dense·sparse·fusion·rerank 중 gold 문서가 어디서 사라졌는지 추적해야 한다고 정리했다. 이전 글의 stage trace 위에 Cerebras 구조를 놓으면 다음 단계가 선명해진다. 후보 recall만 올리는 데서 멈추지 말고, 원본 편중과 잘린 문맥이 최종 evidence bundle을 망치는지까지 봐야 한다.

MCP에는 답변 API가 아니라 검색 primitive를 둔다

Cerebras가 MCP에 제공한 것은 answer_question(question) 하나가 아니다. 역할이 좁은 검색 도구들이다.

search
search_slack
search_code
recent_prs
who_knows
subsystem_index

각 도구는 가능하면 LLM 없이 빠르고 구조적인 근거를 반환한다.

{
  "source": "slack",
  "project": "compiler",
  "timestamp": "2026-07-15T00:00:00Z",
  "score": 0.82,
  "text": "retrieved evidence",
  "source_uri": "slack://channel/thread"
}

Claude Code 같은 상위 agent는 어떤 도구를 호출하고 결과를 어떻게 조합할지 결정한다. Web UI에서는 planner→parallel executor→evidence normalizer→synthesizer를 내부에서 실행한다. 두 interface가 서로 다른 지식베이스를 가지는 대신 같은 retrieval primitive를 공유한다.

이 구조의 장점은 검색과 답변 생성을 따로 평가할 수 있다는 것이다.

검색 도구: 관련 근거를 빠짐없이, 권한에 맞게 반환했는가?
planner/router: 질문에 맞는 도구를 선택했는가?
synthesizer: 근거를 왜곡하지 않고 답과 불확실성을 표현했는가?

모든 질문에 LLM planner가 필요한 것도 아니다. 모델명과 alarm code가 명확하면 deterministic rule로 search_exact_alarm과 search_maintenance_log를 먼저 실행할 수 있다. 모호한 질문, 복수 system을 가로지르는 질문에만 planner를 쓰는 편이 비용과 재현성에 유리하다. 이는 Query Router와 Adaptive RAG의 원칙과도 맞는다.

Project scope와 ACL은 다른 문제다

조직 전체를 매번 검색하면 compiler 질문에 data center 운영 문서가 섞인다. Cerebras의 Project는 Slack channel, repository, wiki, internal DB를 가볍게 묶어 기본 검색 범위를 좁힌다. 같은 공용 source는 여러 project가 참조할 수 있다.

하지만 project scope는 관련도 최적화이고 ACL은 접근 통제다.

Project scope: 어디를 먼저 검색해야 관련도가 높은가?
Access control: 이 사용자가 어떤 record를 볼 수 있는가?

프로젝트 필터를 권한 필터로 대신하면 잘못된 routing이나 직접 tool 호출에서 정보가 샐 수 있다. ACL은 후보가 만들어진 뒤 가리는 post-filter가 아니라 retrieval query 내부 또는 후보 생성 이전에 적용해야 한다. 자세한 보안 경계는 RAG ACL·Multi-tenancy 글에서 다뤘다.

하루 15,000건은 품질 benchmark가 아니다

Cerebras 사례는 구체적인 production architecture를 공개했다는 점에서 가치가 크다. 그러나 공개된 자료만으로 “정확도가 입증된 시스템”이라고 결론 내릴 수는 없다. 확인한 공개 자료에는 다음 수치가 없다.

평가 축	필요한 지표 예	공개 여부
Retrieval	Recall@k, nDCG, MRR	미공개
Answer	질문 해결률, 사실 정확도, 인용 정확도	미공개
Freshness	stale evidence 사용률, index lag	미공개
Security	ACL 누출률, unauthorized retrieval	미공개
Operations	p50/p95 latency, 실패율, 비용	미공개
Business impact	업무시간 절감, 재질문 감소	미공개

15,000건에는 사람뿐 아니라 automation과 agent 호출도 포함된다. “직원들이 하루 15,000개 문제를 해결했다”로 바꿔 말하면 안 된다. 사용량은 adoption signal일 수 있지만 quality metric은 아니다.

구조 자체에도 운영 위험이 있다.

LLM distillation 오류: 토론 중 가설을 최종 resolution으로 오인할 수 있다.
최신성 오해: 최신 Slack 대화가 오래된 공식 SOP보다 항상 정확한 것은 아니다.
출처 충돌: SOP, 정비로그, Wiki, Slack이 서로 다른 조치를 말할 수 있다.
파생 데이터 누출: summary와 embedding도 민감 정보를 담을 수 있다.
heuristic 이식 실패: 한 조직의 길이·IDF·reaction 기준이 다른 조직에는 맞지 않을 수 있다.

따라서 도입 전에 “질문 수”와 별도로 작은 평가셋을 만들어야 한다. 설비·alarm·component·조치 유형별 대표 질문을 모으고, source별 gold document와 허용 권한을 표시한 뒤 retrieval, synthesis, citation, ACL을 각각 측정해야 한다.

PE Agent에는 authority-aware retrieval이 더 필요하다

현재 내가 다루는 반도체 장비 검색 문제는 Cerebras 사례와 직접 맞닿아 있다. 특정 dataset이나 gcb/myservice 계열 문서가 후보를 편중시키고, 같은 원본의 여러 chunk가 top-k를 차지하며, 정확한 alarm 문자열을 semantic search가 놓치는 문제다. 모든 지식을 Wiki 하나로 옮기면 해결될 것처럼 보이지만, 실제로는 또 하나의 stale source를 만들 가능성이 크다.

가져올 수 있는 설계는 다음과 같다.

Cerebras 설계	PE Agent의 문제	적용 방향
Project scope	고객사·설비가 다른 결과 혼입	고객사·fab·설비·model별 scope
Full-text + embedding	alarm명과 자연어 표현 차이	exact와 semantic 병렬 검색
IDF	흔한 문구가 상위 노출	희귀 오류 code·part number 가중
Time decay	오래된 정비 사례 노출	문서 종류별 freshness policy
Parent dedupe	같은 원본 chunk가 top-k 독점	canonical document 기준 병합
File/source cap	특정 source 편중	source·document별 후보 상한
Source-specific tool	SOP·log·wiki가 한 검색기에 혼재	출처별 retrieval primitive
Thread distillation	engineer feedback가 비정형	symptom·cause·action·result 구조화
Raw evidence	답변 검증이 어려움	page·log ID·time window 연결

권장 검색 구조는 다음과 같다.

User question
  ↓
Access Gate
- customer / fab / user permission
- project / equipment / model
  ↓
Query Understanding
- exact alarm / component / recipe
- intent / language / time constraint
  ↓
Tool Routing
├─ search_exact_alarm
├─ search_sop
├─ search_troubleshooting_guide
├─ search_maintenance_log
├─ search_feedback_wiki
├─ search_code
└─ search_recent_cases
  ↓
Source-specific Retrieval
  ↓
Weighted RRF
  ↓
Parent-document dedupe + source cap
+ equipment/model consistency gate
  ↓
Reranker → context expansion
  ↓
Evidence bundle
  ↓
Answer + references + uncertainty

반도체 장비 domain에서는 Cerebras보다 출처 권위와 유효기간을 더 강하게 모델링해야 한다.

Official SOP                  authority = highest
Approved troubleshooting     authority = high
Verified maintenance case    authority = medium-high
Engineer feedback wiki       authority = medium
Unverified chat              authority = low

다만 retrieval_score × authority 하나로 최종 순위를 만들면 관련도 높은 현장 사례가 사라질 수 있다. 다음 순서가 더 안전하다.

질문과 관련된 후보를 먼저 검색한다.
equipment·model·revision 일치 여부를 검사한다.
동일 조치에 대한 출처 충돌을 탐지한다.
공식 문서 우선 정책을 적용한다.
공식 문서가 오래됐으면 stale warning을 붙인다.
비공식 사례는 검증 상태와 함께 보조 근거로 제시한다.

예를 들어 Cooling Stage Align Time Out 질문은 exact alarm→maintenance log→troubleshooting guide 순으로 시작한다. “stage가 제 위치로 이동하지 않는다”처럼 alarm명이 없으면 semantic case search를 추가한다. 부품 교체 절차 질문은 SOP와 official manual을 먼저 찾고, engineer feedback는 주의사항을 보완하는 근거로만 사용한다.

시계열도 검색 가능한 사건 표현으로 증류할 수 있다

이 원칙은 최근 구상한 시계열 패턴→정비 로그 검색에도 이어진다. Cerebras는 비정형 Slack을 질문·요약·해결책·관련 system으로 바꿨다. 시계열에서는 raw signal을 event·pattern·context로 바꿀 수 있다.

Raw time series
  → event segmentation
  → anomaly score / change point
  → sensor pattern
  → equipment / recipe / PM context
  → searchable incident representation

equipment: SUPRA_VPLUS

time_window:
  start: 2026-07-31T10:20:00
  end: 2026-07-31T10:35:00

detected_patterns:
  - chamber_pressure_rising
  - pump_current_decreasing
  - he_leak_signal_spike
  - valve_response_delay

derived_symptom:
  probable_vacuum_leak_or_pumping_degradation

context:
  recent_maintenance:
    - slow_valve_replaced
    - pump_replaced

uncertainty:
  leak_probability: 0.81

이 중간 표현에서 다음과 같은 query를 만들 수 있다.

SUPRA VPLUS에서 pump 또는 slow valve 교체 후
chamber pressure가 상승하고 pump current가 감소하면서
HE leak signal이 증가한 정비 사례

그리고 여러 검색기를 함께 실행한다.

search_exact_events
search_semantic_maintenance_logs
search_similar_sensor_patterns
search_sop
search_recent_replacement_cases

여기서 raw time series를 버리면 안 된다. derived_symptom은 검색을 위한 hypothesis이지 확정 진단이 아니다. 최종 evidence에는 원시 window, sensor ID, sampling 조건, maintenance log ID, 파생 feature와 model version이 함께 남아야 한다.

Cerebras 사례가 시계열→로그 검색의 성능을 실험적으로 입증한 것은 아니다. 가져올 수 있는 것은 설계 원칙이다.

원시 데이터를 바로 임베딩하려 하지 말고, 검색 가능한 중간 표현으로 증류한 뒤 raw evidence 검색과 함께 사용한다.

먼저 구현할 순서

처음부터 planner와 모든 source를 붙이지 않는다. 다음 순서라면 각 단계의 효과를 따로 검증할 수 있다.

EvidenceRecord 공통 schema와 canonical document ID를 정한다.
exact alarm·SOP·maintenance log 세 도구만 만든다.
lexical·semantic 결과를 RRF로 합치고 parent dedupe와 source cap을 넣는다.
고객사·설비·model ACL을 retrieval 내부에 적용한다.
citation 가능한 evidence bundle과 source conflict report를 만든다.
대표 질문 평가셋에서 recall·citation·stale·ACL을 측정한다.
그 뒤에 feedback distillation, time-series incident, planner를 추가한다.

자주 묻는 질문

Q. Vector DB 하나로 통합하면 더 단순하지 않나?

저장소를 하나로 만드는 것과 검색 방법을 하나로 만드는 것은 다르다. 같은 Postgres를 쓰더라도 exact alarm은 full-text, 유사 사례는 embedding, code symbol은 ripgrep이 더 적합할 수 있다.

Q. 최신 문서에 높은 점수를 주면 stale 문제를 해결할 수 있나?

최신성은 하나의 신호일 뿐이다. 공식 SOP의 revision과 현장 chat의 timestamp는 같은 의미가 아니다. source별 유효기간과 authority를 따로 관리해야 한다.

Q. 작은 MCP 도구가 많으면 agent가 더 복잡해지지 않나?

도구 선택은 복잡해지지만 각 도구를 독립적으로 테스트할 수 있다. 명확한 질문은 deterministic routing으로 처리하고, 모호한 질문만 planner에 보내면 복잡도와 비용을 제한할 수 있다.

마무리

Cerebras 사례에서 중요한 것은 Postgres, RRF, embedding 가운데 하나를 골랐다는 사실이 아니다. 데이터의 특성에 맞는 검색 가능한 표현을 만들고, 좁은 retrieval primitive로 분리한 뒤, 질문에 맞춰 근거를 조합한 것이 핵심이다.

PE Agent에 그대로 복사할 필요는 없다. 고객사·설비·model scope, 문서 authority, revision·유효기간, 정비 결과의 검증 상태, 한·영 domain alias를 추가해야 한다. 그리고 15,000이라는 사용량보다 먼저, 내가 답해야 하는 질문에서 gold evidence가 검색되고 권한이 지켜지며 서로 충돌하는 근거가 드러나는지를 측정해야 한다.

참고자료

Cerebras, How We Built Our Knowledge Base — 2026-07-15 공식 기술 글
Cerebras LinkedIn, Cerebras Knowledge 사용량 공개 — 출시 약 3개월, 하루 15,000건 이상이라는 자체 발표
GeekNews, Cerebras가 사내 지식 베이스를 구축한 방법 — 공식 글의 한국어 요약과 구현 세부 정리