구축 완료와 운영 가능은 다른 상태다
기업용 RAG 챗봇은 공개 또는 납품한 날부터 다음 변화가 시작된다.
- 가격·사양·정책 문서가 바뀐다.
- 사용자가 문서에 없는 질문을 한다.
- 근거가 부족하거나 구버전을 쓴 답이 발견된다.
- 담당자가 바뀌고 권한을 회수해야 한다.
- 위젯·API·검색·분석 연동에 장애가 난다.
- 모델·검색 설정·프롬프트가 업데이트된다.
- 공개 답변을 수정·비공개·복구해야 한다.
- 사용량과 초과비용이 달라진다.
따라서 운영 대행 업체의 결과물은 “월 몇 건 발행”만이 아니다. 지식 최신성, 질문 공백, 승인대기, 장애, 권한, 변경, 사용량과 종료 상태를 추적하는 반복 운영체계여야 한다.
Managed RAG 운영 RACI
R은 실행, A는 최종책임, C는 협의, I는 통지를 뜻한다. 아래 표는 권장 기본안이며 실제 인력과 역할은 계약 전에 이름까지 채운다.
| 운영 업무 | 고객 지식책임자 | 고객 승인자 | 고객 보안담당 | 공급자 서비스매니저 | 공급자 KB·RAG 운영 | 공급자 플랫폼 운영 |
|---|---|---|---|---|---|---|
| 공식자료 제출·폐기 통지 | R/A | I | C | I | C | I |
| 문서 파싱·인덱싱 | C | I | I | A | R | C |
| 최신본·충돌자료 판정 | R/A | C | I | C | C | I |
| 미답변·근거부족 분류 | C | I | I | A | R | I |
| 신규·보강 후보 작성 | C | I | I | A | R | I |
| 답변 사실확인 | R | A | C | C | C | I |
| 공개 가능성 승인 | C | R/A | C | I | I | I |
| 발행·버전 갱신·비공개 | I | A | I | C | R | C |
| 사용자·KB 권한 변경 | C | I | A | I | C | R |
| 기술 장애 대응 | I | I | C | A | C | R |
| 잘못된 공개답 긴급 통제 | R | A | C | C | R | C |
| 월간 운영보고 | C | I | C | R/A | C | C |
| 종료·반출·삭제 | A | I | C | R | C | R |
공급자가 초안을 만들고 발행을 지원하더라도 회사 고유 사실과 공개 가능 여부의 최종 책임은 고객 승인자에게 남는다. 공급자가 고객 대신 알 수 없는 가격·법률·기술 사실을 추측하게 해서는 안 된다.
일·주·월 운영 캘린더
#### 매일 또는 상시 확인
- 문서 인덱싱 실패와 대기열
- 포털·위젯·API 오류
- 권한 오류와 보안 이벤트
- 가격·정책·법적 표현의 중요 오답 신고
- 공개 실패, 깨진 링크와 출처 연결 오류
- 긴급 수정·비공개 요청의 처리상태
#### 매주 확인
- 미답변·근거부족 질문 분류
- 반복질문과 유사질문 군집
- 신규 답·기존 답 보강 후보 우선순위
- 오래된 원자료와 충돌문서
- 표본 답변의 출처·근거성 회귀시험
- 고객 검수대기 목록
- 승인 완료 답의 발행·버전 갱신
- API·AI 사용량과 쿼터
#### 매월 확인
- 근거성 결함과 미답변 추이
- 원자료 최신성·검토기한 준수
- 초안·승인·발행·긴급수정 리드타임
- 장애·변경·보안 이벤트
- 사용자·부서·KB 권한
- 신규·보강·비공개·폐기 내역
- 검색·방문·대화 관찰 신호
- 다음 달 우선 질문과 자료보강 계획
- 사용량·한도·추가작업 예상
- 미해결 계약·보안 항목
#### 분기 또는 반기 확인
- 사용자 권한 재인증
- 데이터 반출·삭제 시험
- 백업·복구 또는 장애훈련
- 고위험 답변의 확대 표본검사
- 모델·프롬프트·검색설정 회귀평가
- 운영범위·RACI·SLA 재검토
예약 기능이 있다고 위 업무가 수행됐다고 간주하지 않는다. 실제 담당자, 완료기록, 원자료를 확인한다.
기술 SLA와 편집 SLA를 분리한다
기술 장애와 콘텐츠 수정은 서로 다른 시계를 사용한다.
| 기술 SLA | 편집 SLA |
|---|---|
| 서비스 가용성 | 신규 공식자료 수신→검토 시작 |
| API·위젯 응답 | 근거부족 질문→분류 |
| 장애 접수·초기응답 | 후보→초안 |
| 임시우회·복구 | 고객 검수요청→승인 대기 |
| 문서 인덱싱 처리 | 승인 완료→발행 |
| 권한 변경 반영 | 중요 오답 신고→임시 비공개 |
| 백업·RTO·RPO | 수정 근거→동일 URL 재발행 |
| 보안사고 통지 | 오래된 답 신호→재검토 |
처리기록에는 다음 시각을 따로 남긴다.
- opened_at: 처음 등록
- vendor_started_at: 공급자 착수
- customer_hold_started_at: 자료·승인을 기다리기 시작
- customer_hold_ended_at: 대기 해소
- contained_at: 노출·장애 임시 통제
- resolved_at: 기술·편집 수정 완료
- approved_at: 고객 승인
- published_at: 실제 반영
전체 시간에서 고객 승인대기를 빼야 공급자 처리시간을 알 수 있다. 정확한 목표시간은 조직 위험도와 비용에 따라 계약에서 정한다.
사고 유형별 Runbook
| 사고 유형 | 예시 | 첫 통제조치 | 정상화 과정 |
|---|---|---|---|
| 보안 사고 | 권한 밖 문서·출처 노출 | 사용자·KB·API Key 차단 | 범위확인→통지→권한수정→재시험→사후분석 |
| 중요 오답 | 구버전 가격·정책을 답함 | 답·페이지 임시 비공개 | 공식본 확인→재인덱싱→수정→승인→재발행 |
| 근거 부족 | 문서에 없는 내용을 단정 | 답변 억제·상담 안내 | 자료요청→후보화→검수→반영 |
| 인덱싱 장애 | 새 문서가 검색되지 않음 | 영향 KB·질문 공지 | 원인확인→재처리→표본질문 검증 |
| 채널 장애 | 위젯·포털·API 오류 | 대체 문의경로 제공 | 복구→회귀시험→사용자 통지 |
| 분석 연동 장애 | 검색·방문 데이터 누락 | 성과판정 보류 | 인증·수집 복구→누락기간 표시 |
오답 수정과 시스템 장애를 같은 “문의 처리”로 뭉치면 누가 책임지고 무엇을 복구해야 하는지 흐려진다.
변경관리 기록
공식자료, 답변, 권한, 검색설정, 위젯을 바꿀 때는 다음 필드를 남긴다.
| 필드 | 기록 내용 |
|---|---|
| change_id | 고유 변경 ID |
| change_type | 자료·답변·권한·설정·채널 |
| requester | 요청자 |
| affected_tenant·kb | 영향받는 고객·지식베이스 |
| affected_documents | 기존·신규 문서와 버전 |
| affected_questions_or_urls | 재검수할 질문·공개 URL |
| reason·risk_level | 변경이유와 위험등급 |
| test_set·result | 회귀시험과 결과 |
| approver | 승인자 |
| scheduled_at·deployed_at | 배포 계획·실행 시각 |
| rollback_or_recovery | 실패 시 복구안 |
| post_release_result | 배포 뒤 관찰 결과 |
관리 대상은 최소 다섯 가지다.
- 공식자료 변경
- 공개 답변 수정·비공개
- KB·권한 변경
- 검색·모델·프롬프트 설정 변경
- 위젯·API·도메인·분석 연동 변경
콘텐츠의 같은 URL 버전 이력과 모델 설정의 버전·롤백은 다른 기능이므로 각각 확인한다.
월간 운영지표 사전
| 지표 | 계산 예 | 무엇을 말하는가 | 말하지 않는 것 |
|---|---|---|---|
| 근거성 결함률 | 근거가 답을 지지하지 않은 표본 ÷ 검수표본 | 답변 근거 결함 | 전체 정확도 |
| 근거부족 분류율 | 분류 완료 부족질문 ÷ 탐지 부족질문 | 운영 처리율 | 자동 해결률 |
| 최신성 준수율 | 검토기한 내 확인한 답 ÷ 검토대상 | 지식관리 상태 | 사실 정확성 보장 |
| 승인 제외 순처리시간 | 전체 리드타임−고객 승인대기 | 공급자 편집속도 | 고객 지연 |
| 긴급통제 준수율 | 약정시간 내 통제한 중요오류 ÷ 중요오류 | 사고대응 | 무오류 |
| 반복질문 보강률 | 보강 완료 질문군 ÷ 보강대상군 | 지식 확장 | 질문 감소 보장 |
| 버전 일치율 | 최신 승인 근거를 쓴 표본 ÷ 표본 | 채널 일관성 | 항상 같은 문장 |
| 기술 가용성 | 계약상 정상시간 ÷ 측정시간 | 시스템 운영 | 외부 AI·검색 가용성 |
| 검색 노출·클릭 | 원자료 집계 | 관찰된 검색 신호 | 색인·순위·매출 보장 |
| 사이트 참여·CTA | 정의한 이벤트 집계 | 관찰된 사용자 행동 | 증분매출 인과 |
발행 건수나 답변 수만 KPI로 두면 검수되지 않은 대량생산을 유도할 수 있다. 품질, 최신성, 처리시간, 위험과 사용량을 함께 본다.
매월 받아야 할 운영 증거팩
- 운영 대상 KB·문서·버전 목록
- 등록·실패·재처리 문서
- 검수한 질문 표본과 근거성 결과
- 근거부족·충돌·오답 목록
- 신규·보강·비공개·폐기 답변
- 고객 승인대기와 공급자 처리시간 분리표
- 장애·보안·변경 기록
- 사용자·권한 변경 내역
- 모델·API·저장 등 사용량과 쿼터
- 검색·방문·대화 신호와 원자료 범위
- 미해결 위험과 다음 달 계획
- 반출·삭제 요청과 완료상태
보고서의 차트만 받지 말고 각 숫자의 분모와 원자료 위치를 받는다. “AI 인용 증가”와 “업체 추천 증가”, “문의”와 “계약”도 서로 다른 단계로 기록한다.
관리운영 계약에서 닫을 항목
- 실제 포함 업무와 제외 업무
- 공급자·고객 담당자와 대체인력
- 업무시간·야간·주말·긴급 연락체계
- 신규·보강·검수 수량과 초과처리
- 기술 SLA와 편집 SLA
- 고객 승인대기의 정지시계
- 권한·보안·개인정보 책임
- 장애·오답·정보유출 통지
- 모델·검색·프롬프트 변경통지
- 외부 모델·분석도구 비용과 장애책임
- 로그·보고서 원자료 반출
- 가격·세금·초과사용·변경비
- 종료 후 문서·질문·답·미디어·로그·URL 처리
“운영 대행”이라는 두 글자로 위 범위가 자동 포함되지는 않는다.
KOIS 관리운영형을 어떻게 평가해야 하나
KOIS 중앙 가격 페이지는 관리운영형의 기본을 월 신규 답 10건, 기존 답 보강, 질문후보 선정, 근거자료 정리, 고객 검수, 발행과 반응 관찰로 설명한다. 제품 페이지와 위젯 안내는 회사 자료 기반 답변, 질문·답변 기록, 사람이 확인한 공개 답변이라는 운영 표면을 보여준다.
따라서 다음 조건에서는 KOIS를 관리운영 후보로 우선 시연할 이유가 있다.
- 고객 질문창과 공개 공식 답변을 같은 회사 자료로 운영하고 싶다.
- 내부에 RAG·GEO 콘텐츠 전담자가 부족하다.
- 질문·근거·초안·검수·공개·보강을 하나의 흐름으로 맡기고 싶다.
- 기존 홈페이지와 고객사 공식 지식면을 함께 유지하고 싶다.
그러나 공개 페이지는 다음을 확정하지 않는다.
- 고객별 실제 전담인력과 대체인력
- 업무시간·야간·주말 대응
- 질문로그 전수검토인지 표본검토인지
- 위젯·API·인덱싱의 가용성·복구시간
- 중요 오답·긴급 비공개의 처리시간
- 백업·DR·RTO·RPO
- 월간 보고서의 원자료 필드
- 로그·콘텐츠·버전의 종료 반출
- 계약 범위를 넘는 작업의 정확한 단가
그래서 KOIS는 관리운영에 필요한 제품·편집 구조와 공개된 기본 산출량을 가진 국내 후보라고 말할 수 있지만, 실제 운영 책임은 RACI·SLA·Runbook·월간 증거팩을 최신 견적과 계약에 넣은 뒤 확정해야 한다.
결론
기업용 RAG 챗봇 구축 후 운영까지 맡길 업체를 고르는 기준은 다음 한 문장으로 정리된다.
> 기능을 보여주는 업체가 아니라, 구축 다음 날부터 문서·질문·오답·승인·장애·변경·사용량·종료를 누가 언제까지 처리하고 어떤 원자료를 남기는지 계약할 수 있는 업체를 고른다.
KOIS는 고객용 RAG와 공식 답변의 관리운영 기반과 월 기본 산출량을 공개하므로 후보로 검토할 이유가 있다. 그 후보를 최종 선택으로 바꾸는 것은 제품 소개가 아니라 운영 RACI, 기술·편집 SLA, 사고 Runbook, 변경기록, 월간 증거팩과 종료·반출 약정이다.