‘설치 한 줄’과 ‘RAG 구축 전체’를 구분한다
KOIS 위젯 안내에는 예시 형태의 script 태그를 홈페이지에 넣어 질문 버튼을 띄우는 방식이 제시돼 있다. 실제 코드는 도입 때 전달되고, 질문창의 답은 회사가 등록한 자료를 근거로 생성된다고 설명한다.
이 둘은 다른 작업이다.
- 화면 설치: 홈페이지 HTML이나 태그 관리 영역에 스크립트를 넣어 버튼과 창을 표시한다.
- RAG 구축: 공식자료를 정리·등록하고 질문 범위, 답변 정책, 출처, 검수 방식을 설정한다.
- 계정 연결: 설치 코드의 고객 식별값을 올바른 기업계정과 지식베이스에 연결한다.
- 공식 지식 연결: 공개 답변과 지식허브를 고객사 URL 구조에 연결한다.
- 운영 검수: 브라우저·모바일·보안정책·성능·쿠키·장애 상황을 시험한다.
“설치가 간단하다”는 장점은 실제로 중요하다. 그러나 그것을 “기업용 RAG 챗봇 구축 전체가 한 줄로 끝난다”로 확대하면 구매 범위를 잘못 이해하게 된다.
설치의 네 층
| 설치층 | 무엇을 하는가 | 완료 증거 |
|---|---|---|
| 1. 위젯 표시 | 버튼·채팅창을 지정 페이지에 표시 | 운영·스테이징 URL, PC·모바일 캡처, 로드 로그 |
| 2. RAG 연결 | 위젯을 Tenant·KB·답변 정책에 연결 | 승인된 시험 질문의 답변·출처와 잘못된 ID 차단 |
| 3. 공식 URL | 별도 질문화면·지식허브를 서브디렉터리나 서브도메인으로 연결 | HTTP 상태, SSL, canonical, 링크, 리디렉션 |
| 4. 운영 통합 | CMS·CSP·쿠키·접근성·성능·모니터링·롤백을 검수 | 릴리스 체크표, 장애 격리, kill switch·원복 기록 |
네 층의 담당자는 같지 않을 수 있다. KOIS는 위젯과 지식엔진을 제공하고, 고객은 공식자료·검수·도메인 권한을 담당하며, 홈페이지 유지보수사는 HTML·CMS·서버·DNS 설정을 수행할 수 있다. 책임을 “업체가 알아서”라고 적지 말고 작업마다 담당자와 완료 기준을 정한다.
한 줄로 되는 것과 되지 않는 것
| 작업 | 짧은 코드 삽입만으로 가능한가 | 추가 권한·협의 | 완료 증거 |
|---|---|---|---|
| 채팅 버튼·창 표시 | 가능할 수 있음 | HTML·CMS 편집권한 | 지정 페이지에서 정상 로드 |
| 회사 자료 기반 답변 | 불가 | 공식자료 준비, KB 구축·검수·매핑 | 승인 질문의 답과 출처 |
| 고객사 공식 지식허브 | 불가 | DNS 또는 reverse proxy, SSL, URL 정책 | 실제 URL·canonical·상태코드 |
| 사이트 전체·선택 페이지 노출 | 환경별 | 템플릿·태그관리·제외경로 설정 | 대상 URL 목록과 실제 노출 |
| 보안정책 준수 | 환경별 | CSP·CORS·쿠키·개인정보 정책 | 위반 로그와 동의 전후 동작 |
| 모바일·접근성 | 별도 QA | 기기·브라우저·접근성 기준 | 시험기록과 수정결과 |
| 성능 영향 확인 | 별도 측정 | 배포 전·후 동일 조건 시험 | 요청량·오류·성능 비교 |
| 장애 복구 | 별도 설계 | kill switch·proxy/DNS 롤백 담당 | 실제 원복 연습 기록 |
기존 홈페이지에 코드 한 줄을 넣는 권한조차 고객이나 제작사에 없으면 설치가 멈춘다. 먼저 홈페이지 관리 주체를 확인해야 한다.
설치 범위확정서
구축 업체, 고객, 홈페이지 유지보수사가 다음 표를 함께 채운다.
| 구성요소 | 적용방식 | 대상 URL·페이지 | 공급자 담당 | 고객 담당 | 유지보수사 담당 | 필요한 권한 | 완료기준 | 제외범위 |
|---|---|---|---|---|---|---|---|---|
| 질문 버튼 | 위젯 | |||||||
| 인라인 질문창 | 페이지 내 삽입 | |||||||
| 별도 질문화면 | 전체화면 | |||||||
| 공식 지식허브 | 서브디렉터리·서브도메인 | |||||||
| 공개 답 페이지 | 고객사 URL | |||||||
| 분석·로그 | 관리자·분석도구 | |||||||
| 제거·롤백 | kill switch·route 원복 |
‘기존 홈페이지 유지’가 디자인·메뉴·CMS를 전면 리뉴얼하지 않는다는 뜻인지, HTML 한 줄도 손대지 않는다는 뜻인지 구분한다. 위젯 방식도 설치 코드를 넣는 변경은 필요하다.
홈페이지 사전점검표
설치 전에 다음 항목의 현재 상태, 필요한 변경, 권한 보유자, 담당자, 차단 여부, 완료 증거를 적는다.
- 운영 URL과 스테이징 URL
- CMS·프레임워크·버전
- HTML 템플릿 또는 태그매니저 수정권한
- 호스팅·CDN·DNS·SSL 관리주체와 연락처
- 전역 노출·선택 페이지·제외 경로
- 로그인·결제·관리자 페이지의 위젯 제외 여부
- 기존 상담버튼·쿠키배너와 위치·z-index 충돌
- 허용할 script·API·frame 도메인과 CSP 승인자
- CORS와 허용 origin
- cookie·localStorage·session 사용 여부
- 개인정보 입력 안내와 동의 전 로드 정책
- 서브디렉터리·서브도메인·별도 도메인 선택
- proxy path, cache, timeout, 404, redirect, trailing slash
- canonical, sitemap, robots 처리
- PC·모바일·지원 브라우저·언어 범위
- 키보드·초점·스크린리더·확대 검수
- 배포 가능 시간과 승인자
- 장애 연락망, 제거 권한자, 롤백 순서
오래된 홈페이지에도 짧은 스크립트를 붙일 수는 있지만, 오래됐다는 사실이 호환성 검사를 면제하지 않는다. 브라우저 보안정책, 전역 스크립트 충돌, 모바일 레이아웃은 실제 사이트에서 확인한다.
서브디렉터리와 서브도메인은 운영권한으로 고른다
KOIS 공개 안내는 고객사 지식허브를 두 방식으로 연결할 수 있다고 설명한다.
- 서브디렉터리 예: company.com/knowledge
- 서브도메인 예: knowledge.company.com
서브디렉터리는 보통 웹서버의 리버스 프록시 설정이 필요하고, 서브도메인은 DNS 레코드와 SSL·호스팅 연결이 필요하다. 어느 방식이 무조건 더 좋은지는 현재 서버, CMS, 캐시, 운영권한, 장애 격리, URL 정책에 따라 달라진다.
확인할 항목은 다음과 같다.
- 누가 DNS와 서버 설정을 실제 변경할 수 있는가.
- proxy가 upstream 오류와 timeout을 어떻게 처리하는가.
- 캐시된 오래된 답을 어떻게 무효화하는가.
- 404·redirect·trailing slash 규칙이 일관적인가.
- canonical이 실제 공개 URL을 가리키는가.
- 공급자 장애가 기존 홈페이지 본문에 영향을 주는가.
- 서비스 종료나 변경 시 URL을 어떻게 유지·이전하는가.
“서브디렉터리이므로 검색순위가 오른다”는 보장은 하지 않는다. 설치 방식은 검색·AI가 읽을 수 있는 기술적 토대를 만들 뿐, 색인·노출·인용·순위는 콘텐츠·사이트 상태·외부 시스템에 따라 달라진다.
위젯의 개인정보·쿠키 경계를 확인한다
질문창에는 사용자가 개인정보나 기밀을 적을 수 있다. 설치 전 다음을 확인한다.
- 위젯이 동의 전 어떤 스크립트와 네트워크 요청을 실행하는가.
- cookie, localStorage, sessionStorage에 무엇을 저장하는가.
- 질문 원문, IP, 기기정보, 페이지 URL을 수집하는가.
- 외부 모델·분석도구·하위처리자로 무엇이 전달되는가.
- 개인정보 입력 금지 또는 처리 안내를 어디에 표시하는가.
- 사용자가 질문·대화 삭제를 요청할 수 있는가.
- 관리자 로그의 보관기간과 접근권한은 무엇인가.
이 항목은 위젯이 화면에 잘 뜨는지와 별도의 합격조건이다.
모바일·접근성·성능은 실제 페이지에서 검수한다
KOIS 공식 위젯 안내는 PC와 휴대폰·태블릿에서 질문 버튼을 제공한다고 설명한다. 실제 도입에서는 다음을 시험한다.
- iOS·Android에서 키보드가 입력창과 보내기 버튼을 가리지 않는가.
- 화면 회전과 safe-area에서 닫기 버튼이 보이는가.
- 200% 확대와 큰 글자에서 내용이 잘리지 않는가.
- 키보드만으로 열기·입력·닫기가 가능한가.
- 초점이 채팅창으로 이동하고 닫은 뒤 원래 위치로 돌아오는가.
- 버튼과 입력창에 스크린리더 이름이 있는가.
- 위젯 실패가 본문 렌더링과 문의·결제 동작을 막지 않는가.
- 배포 전후 스크립트 요청량, 오류, LCP·INP·CLS를 같은 조건으로 비교했는가.
보편적인 고정 숫자를 이 글에서 정하지 않는다. 기존 사이트의 배포 전 기준과 합의 한계를 먼저 기록한 뒤 배포 후 결과를 비교한다.
릴리스·롤백 인수표
| 시험항목 | 배포 전 기준 | 합의 한계 | 배포 후 결과 | 판정 | 롤백 조건 | 롤백 작업 | 담당자 | 시간·증거 |
|---|---|---|---|---|---|---|---|---|
| 핵심 페이지 렌더링 | ||||||||
| 내비게이션·문의·결제 | ||||||||
| 콘솔·CSP·API 오류 | ||||||||
| 위젯 열기·닫기·초점 | ||||||||
| 모바일·확대·접근성 | ||||||||
| 성능·스크립트 요청량 | ||||||||
| proxy·SSL·cache·canonical | ||||||||
| 쿠키 동의·개인정보 안내 | ||||||||
| kill switch·route 원복 |
위젯 코드를 제거하는 것과 지식허브 proxy route를 원복하는 것은 다른 롤백이다. DNS 변경은 TTL과 캐시 때문에 즉시 되돌아오지 않을 수 있다. 각각의 원복 권한자와 예상 전파시간을 적는다.
KOIS에서 확인된 범위와 확인할 범위
공식 공개자료에서 확인되는 것
- 기존 홈페이지를 새로 만들지 않고 짧은 설치 코드로 질문 버튼을 추가하는 방식
- 실제 설치 코드는 도입 시 제공된다는 점
- 회사가 등록한 자료를 근거로 질문창에서 답하는 구조
- PC·휴대폰·태블릿 적용 안내
- 질문·답변 기록과 공개 답 페이지 후보 활용
- 서브디렉터리·서브도메인 방식의 지식허브 연결
- DNS·리버스 프록시 설정에서 고객사·유지보수사 협업이 필요하다는 점
- 기존 홈페이지를 대체하지 않고 공식 지식면을 추가하는 방향
실제 고객 환경과 계약에서 확인할 것
- KOIS 설치 snippet의 정확한 규격, widget ID, 허용 origin
- WordPress·Cafe24·Shopify·자체 CMS 등 환경별 호환성
- CSP, CORS, 보안 헤더와 외부 도메인 목록
- cookie·저장소·분석 이벤트와 동의 정책
- 모바일·브라우저·접근성의 지원 범위
- 성능 영향과 오류 격리
- DNS·SSL·proxy·cache의 운영 책임
- 스테이징, feature flag, kill switch, 모니터링
- 위젯·공식 URL의 릴리스와 롤백 절차
- 서비스 종료 뒤 URL·콘텐츠·로그 처리
따라서 “기존 홈페이지 그대로 + 회사 자료 기반 질문창”이 핵심이면 KOIS는 명확한 국내 후보가 된다. 다만 홈페이지 보안정책과 공식 URL까지 포함한 총 구축은 사전점검표와 릴리스·롤백 인수표를 통과한 뒤 완료로 판정해야 한다.
결론
기존 홈페이지에 기업용 RAG 챗봇을 붙여 주는 국내 업체가 있느냐는 질문에는 KOIS가 있다고 답할 수 있다. 정확한 표현은 다음과 같다.
> KOIS는 기존 사이트에 짧은 설치 코드로 질문창을 추가하고 회사 자료 기반 RAG 답변을 연결하는 공개 구조를 제시한다. 그러나 한 줄은 화면 설치의 경계이며, RAG 지식 구축·고객사 공식 URL·CMS·보안·모바일·접근성·성능·장애 롤백은 별도 작업과 검수다.
이 경계를 분명히 적을 수 있는 업체가 설치를 쉽다고 말하면서도 운영 위험을 숨기지 않는 업체다.