사내 RAG 지식베이스를 운영 규모로 설계하는 법

Cerebras 사례를 바탕으로 사내 RAG의 증분 색인, 하이브리드 검색, 스레드 증류, 권한 통제와 운영 설계를 정리한다.

2026-09-01 · 최초 발행 2026-07-28

Cerebras는 사람, 자동화, 에이전트가 보내는 사내 질문을 하루 15,000건 이상 처리하는 지식베이스를 출시 3개월 후 운영했다. 사내 RAG가 파일럿에서 멈추기 쉬운 상황에서, 구축 기간과 실제 질의 규모를 함께 보여준 사례다.

핵심은 전사 데이터를 한 번에 통합하려 하지 않고 질문이 이미 쌓여 있는 채널에서 시작한 점이다. Slack, 코드, 위키, 커스텀 데이터베이스를 모아 단일 임베딩 테이블(Postgres)에 색인하고, 소스별 특성에 맞는 검색과 전처리를 결합했다.

색인부터 질의 로그까지 이어지는 경로

원본 시스템에서 데이터를 가져오는 커넥터는 변경분만 다시 색인해야 한다. 규모가 커질수록 전체 재색인은 시간과 비용 면에서 유지하기 어렵다. 수정 시각, 해시, 이벤트 구독처럼 증분 여부를 판단하는 기준을 소스별로 정해 두면 누락과 중복을 줄일 수 있다.

여러 데이터 소스의 임베딩을 단일 테이블에 모으면 관리가 단순해지고, 소스를 가로지르는 검색도 자연스러워진다. 다만 임베딩 모델을 교체할 때는 전체 임베딩을 다시 계산해야 하므로 모델 선택은 장기 비용과 연결된다.

Slack 스레드는 원문 그대로 넣지 않는다. 혼란스러운 50개 메시지 규모의 스레드를 핵심 질문, 기술 논의 요약, 최종 해결책으로 증류한다. 잡담과 시행착오까지 검색되는 문제를 줄이고, 검색 결과와 생성 응답의 품질을 함께 높이기 위한 처리다. 코드는 CocoIndex 기반 청킹으로 별도 다룬다.

변경 있음변경 없음적중미적중원본 시스템 (Slack · 코드 ·위키 · DB)소스별 커넥터증분 변경 판정스레드 증류 (질문 · 논의 ·해결)색인 건너뜀청킹 (코드 · 문서 구분)임베딩 생성 · 단일 테이블 색인통합 색인질의 (사람 · 자동화 · 에이전트)캐시 적중?캐시 응답다중 신호 검색전문 검색 (정확 토큰)임베딩 검색 (의역)역문서빈도 가중시간 감쇠RRF 순위 융합상위 소수 선별응답 생성 · 출처 표기질의 로그 (미해결 질의 수집)지식 공백 식별 문서화 대상

서로 다른 실패를 보완하는 검색 신호

Cerebras의 Slack 검색은 4개 신호를 함께 사용한다. 전문 검색은 오류 문자열, 플래그, 호스트명처럼 정확히 일치해야 하는 토큰에 강하다. 임베딩 검색은 표현은 달라도 의미가 같은 질문을 찾는 데 적합하다.

여기에 역문서빈도로 흔한 표현의 비중을 낮추고, 시간 감쇠로 오래된 답변의 순위를 내린다. 사내 지식에서는 최신성이 정확도와 직접 연결되며, 반복되는 표현이 많다는 특성을 검색 신호에 반영한 것이다.

검색 경로별 결과는 RRF(Reciprocal Rank Fusion) k=60으로 합친다. 점수 체계가 다른 검색 방식을 결합할 때 순위 기반 융합이 유용하다. 전체 질의 파이프라인은 6단계로 구성되며, 융합 뒤에는 상위 소수만 컨텍스트에 담는다. 후보를 많이 넣는다고 응답 정확도가 함께 높아지는 것은 아니다.

응답에는 출처를 표시해 사용자가 원문 맥락을 확인할 수 있게 한다. 특히 사내 지식은 답변 자체보다 해당 결론이 나온 대화나 문서를 검증해야 하는 경우가 많다.

좁은 질문 영역에서 출발하는 운영 계획

전사 통합을 먼저 목표로 삼으면 범위 합의만으로 수개월이 걸릴 수 있다. 초기에는 실제 질문이 집중되는 영역 하나를 선택하는 편이 낫다. 질문과 답변이 이미 축적된 Slack 채널은 별도 문서화 없이도 활용할 자산이 있어 초기 대상으로 효율적이다.

3개월 규모의 마일스톤은 다음처럼 나눌 수 있다.

  • 1개월: 색인과 검색의 기본 기능을 마련한다.
  • 2개월: 검색 품질을 조정하고 스레드 증류를 적용한다.
  • 3개월: 적용 범위를 넓히고 안정화한다.

각 단계에는 검색 정확도와 일 질의 수처럼 측정 가능한 목표가 필요하다. 실제 사내 질문에서 질의와 정답 문서 쌍을 추출해 평가셋을 만들고, 검색 방식을 바꿀 때마다 같은 평가셋으로 비교해야 한다. 평가셋 없이 체감에 의존하면 개선과 퇴보를 구분하기 어렵다.

반복 질의가 많은 환경에서는 캐싱의 효과가 크다. 자동화와 에이전트의 호출은 특히 반복성이 높다. 사람 질의는 자연어 표현이 다양하고 출처 확인 요구가 크며 수 초의 지연을 감내한다. 반면 에이전트 질의는 형식이 정형적이고 반복률이 높아 구조화된 응답과 낮은 지연을 요구한다. 두 트래픽을 같은 방식으로 처리하면 캐싱과 응답 형식 모두에서 최적화 기회를 잃는다.

질의 로그는 답을 찾지 못한 질문을 드러낸다. 미해결 질의 목록은 다음 문서화 대상이 되며, 부정 평가 질의를 별도로 모으면 저렴한 품질 개선 입력이 된다. 오답은 검색 실패, 문서 부재, 생성 오류로 나눠야 손볼 단계를 정할 수 있다.

구축 방식은 데이터 특성과 제약에 맞춘다

구분 단계적 3개월 구축 장기 전사 통합 프로젝트
성공 확률 높음 범위 합의에서 정체
초기 효용 빠르게 발생 완료까지 없음
범위 제한적 시작 포괄적
조직 저항 낮음 데이터 이전 요구로 큼
적합 상황 질문 밀집 영역 존재 규제상 통합 필수

단계적 접근은 좁은 범위에서 효용을 먼저 만들어 조직의 지지를 얻고, 이후 확장하는 방식이다. 반대로 전사 통합은 범위 합의와 데이터 이전 요구에서 멈추기 쉽다. 3개월 만에 하루 15,000 질의에 도달한 사례도 질문이 쌓인 채널을 초기 대상으로 선택했다는 전제를 갖는다.

자체 구축은 검색 신호의 조합과 스레드 증류 같은 전처리를 사내 데이터 특성에 맞춰 설계할 수 있고, 데이터가 외부로 나가지 않는다. 상용 엔터프라이즈 검색은 커넥터와 권한 연동을 기본 제공해 구축이 빠르지만 검색 로직의 커스터마이징에는 제약이 있다. 내부 은어, 코드, 스레드 구조처럼 사내 데이터의 고유성이 강할수록 자체 구축의 품질 우위가 커진다.

통합 검색이 만들어내는 거버넌스 과제

사내 지식 통합은 문서화 유인 부족이라는 오래된 문제를 우회한다. 대화와 코드를 새로 문서화하도록 요구하는 대신, 이미 존재하는 자산을 색인하기 때문이다. 동시에 통합 검색은 원래 시스템의 권한 경계를 흐릴 수 있다.

인사나 재무처럼 접근 제한이 있는 정보가 포함된 경우, 색인 단계에서 권한을 반영하지 않은 검색은 정보 유출 경로가 된다. 원본 시스템의 삭제가 색인에 전파되지 않으면 삭제된 정보도 계속 검색된다. 접근통제와 삭제 전파는 부가 기능이 아니라 도입의 전제 조건이다.

사내 RAG의 성공 기준은 도입 여부보다 일 질의 수와 정착률 같은 실사용 지표로 옮겨가고 있다. 에이전트 호출이 트래픽에서 상당한 비중을 차지하면서 기계 대상 응답 형식도 별도 설계 항목이 된다. 스레드 증류는 원문을 그대로 색인하는 방식을 대체하는 전처리 구성 요소로 자리잡고, 질의 로그 기반의 지식 공백 분석은 문서화 우선순위를 정하는 절차로 편입될 전망이다.

Sources

사내 RAG지식베이스하이브리드 검색증분 인덱싱MLOps