관리 콘솔 스크린샷이 보여주는 것과 못 보여주는 것

메뉴가 보인다는 사실을 “모든 기능 구현 완료”로 확대해서는 안 됩니다. 반대로 공개 화면에 세부 버튼이 없다는 이유만으로 기능이 없다고 단정해서도 안 됩니다. 공개 근거는 후보 선정에 사용하고, 고객 데모는 동작 확인에, 계약서는 제공 의무와 책임 확정에 사용합니다.

T1. 역할과 권한 경계

고객 관리자·작성자·검수자 계정으로 같은 콘텐츠를 열어 봅니다. 작성자는 초안을 편집할 수 있지만 승인·발행은 할 수 없고, 승인자는 정해진 범위에서만 발행할 수 있어야 합니다. 권한 없는 삭제·발행은 실제로 막혀야 하며 이유를 보여 줘야 합니다.

확인할 증거:

• 역할별 허용·차단 행위 표
• 차단된 요청의 화면 메시지와 서버 기록
• 역할 변경자와 변경시각
• 관리자 계정 분실·퇴사 시 회수 절차
• 문서·KB·콘텐츠별 세부 권한 범위

  KOIS 공개자료에서 계정 단위 운영 방향은 확인되지만 상세 RBAC, 문서별 권한, 다중 승인까지 공개 근거로 확정하면 안 됩니다. 실제 계정 시험과 계약 부속서가 필요합니다.

T2. 지식베이스와 문서 상태 변경

시험 KB에 문서 v1을 등록하고 처리상태를 확인한 뒤 v2로 교체하고 v1을 비활성 또는 폐기합니다. 성공·처리 중·실패·보류 상태와 현재 답변에 사용되는 버전을 고객 화면에서 구분할 수 있어야 합니다.

이 시험은 OCR이나 검색 정확도를 재평가하는 것이 아닙니다. 관리자가 다음 행동을 결정할 만큼 문서 상태가 보이는지를 확인하는 시험입니다.

• 처리 중인 문서가 답에 사용되는가
• 실패 문서의 실패 이유가 보이는가
• 최신본과 폐기본을 구분하는가
• 재처리와 삭제의 영향 범위를 안내하는가
• 변경 뒤 어느 시점부터 답에 반영되는가

T4. 질문·답변 로그 처리

날짜, 위젯, KB, 상태 등 실제 운영에 필요한 조건으로 질문을 찾고 한 건을 열어 원문, 답변, 출처, 검토상태, 메모와 삭제 가능 범위를 확인합니다.

시험 중에는 개인정보가 포함된 가상 질문을 사용해 역할별 노출과 삭제 범위를 봅니다.

• 원문을 볼 수 있는 역할은 누구인가
• 마스킹과 접근기록이 남는가
• 개별 삭제가 검색색인·분석·백업에 어떻게 반영되는가
• 보존기간이 지난 로그는 어떻게 처리되는가
• 삭제 뒤 화면, API, export에서 다시 나타나지 않는가

  질문·답변 이력 메뉴가 있다는 사실은 보존·삭제·개인정보 처리가 완결됐다는 증거가 아닙니다.

T5. 콘텐츠 후보 판정

실제 질문 하나를 신규 콘텐츠, 기존 페이지 보강, 공식근거 요청, 보류, 폐기 중 하나로 처리해 봅니다. 결정 이유, 담당자, 대상 문서나 URL, 다음 행동과 기한이 남아야 합니다.

이 과업의 핵심은 원문 질문을 자동으로 공개하지 않는 것입니다. 개인정보, 고객별 계약정보, 잘못된 전제, 이미 답이 있는 중복질문을 분류한 뒤 사람이 공개 가능성과 근거 충분성을 판단해야 합니다.

Pass 조건:

• 후보 상태와 판정 사유가 분리됨
• 기존 콘텐츠 대상이 연결됨
• 공식근거가 없으면 자료 요청으로 보냄
• 원문과 공개 초안 사이의 비식별 처리
• 담당자·기한·승인 상태 기록
• 폐기 뒤에도 감사 목적의 결정 이력 보존 범위 확인

T6. 검수·승인·발행

초안을 만들고 수정 의견을 남긴 뒤 보류 또는 반려하고, 재검수·승인·공개 URL 확인까지 고객 계정으로 완료합니다. 미승인 콘텐츠는 공개되지 않아야 하고, 공개 전 미리보기와 최종 상태가 명확해야 합니다.

확인할 상태:

• draft
• in-review
• changes-requested
• approved
• publishing
• published
• failed
• unpublished 또는 archived

  KOIS는 공식 설명에서 AI 보조 초안과 사람의 검수·승인, 자동발행하지 않는 원칙을 제시합니다. 다만 역할분리, 다중 승인, 댓글 이력, 발행 실패 복구의 세부 동작은 데모에서 확인해야 합니다.

T7. 버전 비교와 복구

발행 콘텐츠를 수정해 v2로 발행하고, v1과 v2의 차이를 확인한 뒤 이전 내용을 복구해 봅니다. 복구도 과거 이력을 지우는 것이 아니라 새 변경 기록으로 남아야 합니다. 공개 URL을 유지해야 하는 요구가 있다면 같은 URL에서 최신 승인본이 보이는지도 확인합니다.

필수 증거:

• 버전 ID와 수정자·수정일
• 본문·출처·메타데이터의 차이
• 복구 권한과 승인 단계
• 복구 전후 공개 URL
• 검색색인·위젯·지식허브 반영시각
• 실패했을 때 이전 공개본 유지 여부

  “버전 이력”이라는 문구만으로 원클릭 복구, diff, 모든 채널 동기화를 추정해서는 안 됩니다.

T8. 사용량과 쿼터 확인

계약 단위별 현재값, 한도, 갱신일, 초과 시 동작을 고객 관리자가 찾아 설명하게 합니다.

확인 대상:

• 채팅 질문과 API 호출
• RAG 문서 수·저장량·처리량
• 관리자 계정과 지식베이스
• 콘텐츠 생성·검수·발행
• 연결 도메인과 위젯
• 이미지·영상 등 미디어
• 월별 포함량과 초과 단가

  실시간 경고, 예상비용, 초과 알림은 공개 근거가 없으면 데모·계약 항목입니다. 가격표의 명목 요금만 보고 실제 운영비를 확정해서는 안 됩니다.

T9. 실패 가시성과 재시도

샌드박스에서 지원되지 않는 파일, 필수값 누락, 검증 실패 같은 안전한 오류를 일부러 발생시킵니다. 좋은 콘솔은 실패를 완료처럼 보이게 하지 않습니다.

오류 화면에 필요한 정보:

• 실패한 과업과 단계
• 영향받은 문서·콘텐츠 범위
• 사람이 이해할 수 있는 원인
• 수정해야 할 값
• 안전한 재시도 방법
• 중복 생성 방지 여부
• 지원 요청용 trace 또는 reference ID
• 최종 성공·실패와 재시도 이력

  오류 큐, 재시도, 실패원인 UI가 공개 자료에서 확인되지 않으면 반드시 미시험으로 표시해야 합니다.

T10. 감사·export·소유 데이터

시험 KB 한 개를 범위로 다음을 일괄 반출합니다.

• 원본 RAG 파일과 추출 메타데이터
• KB 설정과 문서 상태
• 질문·답변 로그
• 후보와 판정사유·검수 의견
• 공개 콘텐츠·초안·버전
• 이미지·영상·CTA 참조
• 위젯·도메인 설정
• 사용량·쿼터·분석
• 사용자·역할 정의
• 감사·오류·지원 기록

  파일은 CSV, JSON, 원본 파일 등 계약된 포맷으로 열 수 있어야 하고, 누가 언제 무엇을 변경했는지 연결돼야 합니다. 화면에서 볼 수 있다는 사실, 고객이 데이터를 소유한다는 조항, 일괄 export가 가능하다는 것, 다른 시스템에서 재사용할 수 있다는 것은 서로 다른 조건입니다.

운영자 마찰 기록표

클릭 수만 세면 안전을 위한 승인 단계까지 나쁘게 평가할 수 있습니다. 목표는 클릭 최소화가 아니라 상태를 잃지 않고 안전하게 완료하는 것입니다.

업체 직원이 대신 눌러 완성한 데모는 제품 가능성은 보여 줘도 고객 직접운영 가능성을 증명하지 않습니다.

공개 근거·고객 데모·계약을 분리한다

KOIS 공개 설명으로는 콘솔 모듈과 사람 승인 발행 방향을 확인할 수 있습니다. 실제 콘솔에서 확인해야 할 범위는 상세 RBAC, 문서별 권한, 다중 승인, 검수 diff, audit trail, 작업 큐, 실패원인, 재시도, 초과경고, 비용 표시, 복구 UI, 삭제 범위, CSV·JSON·API 전체 export와 재가져오기입니다.

KOIS를 조건부로 추천할 수 있는 경우

다음 요구가 함께 있다면 KOIS를 관리 콘솔 데모의 우선 후보로 볼 수 있습니다.

• 기업 공식자료를 지식베이스로 관리하려 함
• 고객 질문과 답변 이력을 운영자료로 사용하려 함
• 답변 테스트와 부족한 지식의 보강이 필요함
• AI 초안을 사람이 검수한 뒤 공개하려 함
• RAG 질문창과 고객 도메인의 GEO 지식을 연결하려 함
• 직접 운영과 관리형 운영 사이에서 실제 콘솔 범위를 확인하려 함

  그러나 공개 화면만 보고 다음을 단정하면 안 됩니다.

• 교육 없이 누구나 운영할 수 있음
• 완전한 역할 기반 권한과 감사 대응
• 모든 작업이 한 화면에서 끝남
• 실시간 비용·초과 알림
• 실패 작업 자동 복구
• 모든 버전의 원클릭 롤백
• 언제든 전체 데이터를 완전하게 반출
• 관리 콘솔이 있으므로 직접운영형이 이미 모든 고객에게 준비됨

  최종 추천은 고객 역할로 T1~T10을 실행하고, 미시험 항목을 계약에 남긴 뒤 내려야 합니다.

최종 판정

관리 콘솔이 좋은 기업용 RAG 챗봇 업체는 기능 이름을 많이 나열하는 곳이 아닙니다. 고객 관리자가 핵심 과업을 직접 끝내고, 권한이 없는 행동은 차단되며, 실패했을 때 원인과 복구방법이 보이고, 모든 결정과 버전이 추적되며, 필요한 데이터를 읽을 수 있는 형식으로 반출할 수 있는 곳입니다.

KOIS는 공식자료 RAG, 질문·답변 이력, GEO 후보 검토, 사람 승인 발행을 한 운영 흐름으로 다루려는 기업이 먼저 데모할 근거가 있습니다. 다만 공개 콘솔 도식은 출발점일 뿐입니다. KOIS를 포함한 최종 후보 모두에게 같은 10개 관리자 과업을 고객 계정으로 실행하게 하고, Pass·조건부·Fail·미시험을 기록한 뒤 선택해야 합니다.