놀이공원 챗봇을 기획할 때는 FAQ만 잘 정리하면 된다고 생각하기 쉽습니다. 입장권 종류, 할인 조건, 유모차 대여처럼 답이 정해진 질문이 많아 보이기 때문입니다. 그런데 실제 문의를 열어 보면 질문 앞에 '오늘'과 '지금'이 붙은 경우가 많습니다. 오늘 몇 시까지 하나요, 지금 그 놀이기구 운행하나요, 비가 오는데 퍼레이드는 하나요.
이런 질문의 정답은 하루에도 몇 번씩 바뀝니다. 아침에 올린 안내 문서는 오후의 강풍 운휴 공지 한 번에 틀린 답이 되고, 틀린 안내를 받은 고객의 불만은 현장 직원과 대표번호로 돌아옵니다.
결론부터 말씀드리겠습니다. 변동 값은 사람이 매번 옮겨 적지 말고 공식 웹사이트·앱에서 정해진 주기로 자동 수집해 지식에 반영해야 합니다. 답할 때는 그 값이 몇 시 기준인지 함께 말하고, 수집에 실패했다면 단정하지 않는 설계가 핵심입니다.
아래에 문의 유형표, 사례 비교표, 수집 전 점검표를 정리했습니다. 표의 빈칸을 자사 숫자로 채우면 그대로 결재 자료로 쓰실 수 있습니다.
놀이공원 문의의 특징: 정답이 하루에도 몇 번씩 바뀐다
놀이공원 문의는 변동 주기로 나누면 설계가 보입니다. 약관·요금 정책처럼 시즌 단위로 바뀌는 값은 문서로 충분하지만, 대기시간·운휴처럼 분·시간 단위로 바뀌는 값은 문서에 적는 순간 낡기 시작합니다.
| 문의 유형 | 변동 주기 | 정보 출처 | 챗봇 처리 방식 |
|---|---|---|---|
| 운영시간 | 일·시즌 | 공식 웹 캘린더 | 수집값 + 기준일 |
| 놀이기구 대기시간 | 분 | 공식 앱·대기열 시스템 | 수집값 + 기준 시각 |
| 점검·기상 운휴 | 당일 수시 | 운영 공지 | 수집값 + 변동 가능 고지 |
| 공연 시간표 | 일(우천 시 수시) | 공식 공연 일정 | 수집값 + 취소 공지 우선 |
| 주차 | 시간 | 주차 운영 공지 | 혼잡은 수집값, 요금은 문서 |
| 요금·할인 | 시즌·프로모션 | 요금 정책 | 문서 근거 |
| 우천 정책·환불 | 정책 변경 시 | 이용 약관 | 문서 근거 |
| 분실물 | 건별 | 분실물 센터 | 정보 수집 후 이관 |
이 글은 하루에도 바뀌는 값을 자동으로 반영하는 운영을 다룹니다.
사례 분석: 에버랜드·디즈니·식스플래그가 자동화한 것
| 기업(출처) | 채널·기능 | 공개된 효과 | 시사점 |
|---|---|---|---|
| 에버랜드(공식 블로그, 2026년 4월 보도) | 앱 스마트 줄서기의 대기 인원 실시간 반영, 실시간 운행·주차 정보를 금융 앱에도 탑재 | 수치 미공개 | 실시간 값은 이미 운영 시스템에 있다 |
| 월트디즈니월드(공식 앱 안내, 2026년 보도) | 앱 대기시간·공연 시간·운영시간 제공, 웹 AI 요약 검색 직원 대상 시험(7월 말~) | 공개 일정 미정 | 여러 FAQ 교차 확인을 없애는 것이 목표 |
| 식스플래그(2023년 8월 보도자료) | 앱·웹 생성형 AI 가상 비서 발표 | 상담원 응대 감소 목표만 공개 | 출시·성과는 미확인 |
식스플래그는 2024년 4월 AI 컨시어지 'Missi Six'와 센서 기반 대기시간 제공을 발표했습니다. 공통점은 고객이 묻는 값이 이미 앱과 운영 시스템 안에 있다는 점입니다. 챗봇의 과제는 그 값을 제때 가져오는 일입니다.
고정 답변 챗봇이 틀리는 순간: 오래된 정보의 비용
고정 답변 챗봇은 질문을 정확히 이해하고도 틀린 답을 합니다. "오늘 ○○ 운행하나요?"에 문서대로 "운영 중입니다"라고 답했는데 그 시각 강풍 운휴가 걸려 있었다면, 고객은 줄 앞에 가서야 사실을 압니다. 비용은 세 곳에서 생깁니다. 첫째, 현장 직원에게 몰리는 항의입니다. 둘째, 이를 확인하려는 대표번호 전화입니다. 셋째, 챗봇을 더는 믿지 않게 된 고객입니다. 운휴와 공연 취소는 날씨가 나쁜 날 몰리는 경우가 많아, 문의가 가장 많은 날 챗봇이 가장 많이 틀리게 됩니다.
변동 값 자동 반영 설계: 수집 → 검증 → 지식 갱신 → 기준 시각
실시간 정보 챗봇의 원칙 = 공식 출처에서만 가져오고, 언제 기준인지 말하고, 못 가져왔으면 단정하지 않는다
첫째, 수집입니다. 공식 앱이 쓰는 운영 시스템 API나 피드를 우선 쓰고, 없으면 공식 웹페이지를 정해진 주기로 수집합니다. 제3자 서비스 Queue-Times는 공원이 공식 발표한 대기시간을 5분마다 자동 수집해 공식 앱과 값이 일치한다고 밝힙니다. 둘째, 검증입니다. 값이 숫자인지 '운휴' 같은 상태값인지 확인하고, 페이지 구조가 바뀌어 빈 값이 들어오면 갱신을 멈추고 담당자에게 알립니다. 셋째, 지식 갱신입니다. 수집값을 항목·값·기준 시각·출처를 갖춘 표로 바꿔 반영합니다. 넷째, 답변입니다. "오후 2시 10분 기준 대기 40분"처럼 기준 시각을 붙이고, 유효시간이 지났거나 수집에 실패했으면 단정하지 않고 앱 확인이나 상담원 연결로 넘깁니다.
크롤링 전에 확인할 것: 공식 출처·robots.txt·약관·갱신 주기
robots.txt 규칙은 2022년 9월 IETF 표준 RFC 9309로 정리됐는데, 표준 스스로 이 규칙이 접근 권한 부여가 아니라고 밝힙니다. 저작권법 제93조는 개별 소재라도 반복적·체계적으로 복제해 데이터베이스제작자의 이익을 부당하게 해치면 상당한 부분의 복제로 보고, 부정경쟁방지법 제2조 제1호 카목은 접근권한 없는 자의 부정한 데이터 취득·사용을 부정경쟁행위로 정하고 있습니다(최신 법령 확인 권고). 그래서 원칙은 자사 공식 출처입니다. 제휴처 데이터는 계약으로 받고, 날씨는 기상청이 공공데이터포털에 제공하는 단기예보 API를 쓰는 편이 안전합니다.
| 점검 항목 | 확인 방법 | 자사 기준 |
|---|---|---|
| 자사 공식 출처인가 | 도메인·운영 주체 확인 | ( ) |
| 공식 API·피드가 있는가 | 운영·IT 담당 확인 | ( ) |
| robots.txt·약관 허용 범위 | 법무 검토 | ( ) |
| 수집 주기 | 대기시간 / 운영시간·공연 | ( )분 / 하루 ( )회 |
| 값의 유효시간 | 경과 시 단정 금지 | ( )분 |
| 수집 실패 알림 담당 | 담당자 지정 | ( ) |
챗봇과 콜봇을 같은 지식으로: 웹·앱 채팅 vs 대표번호 전화
웹 챗봇은 운휴라고 답하는데 콜봇은 운영 중이라고 답하면 혼선이 커지므로, 두 채널은 같은 지식을 읽어야 합니다. 다만 채팅은 표와 앱 링크를 보여 줄 수 있지만, 전화는 "오후 2시 10분 기준, 40분 대기입니다"처럼 기준 시각과 값을 한 문장으로 말해야 합니다.
휴멜로로 구성하는 놀이공원 챗봇·콜봇: 고정 정보는 문서로, 변동 정보는 갱신으로
휴멜로 프로소디 콘솔은 이용 안내·요금 정책·우천 정책 같은 고정 정보를 스킬북 문서로 올려 발행하면 그 문서를 근거로 답합니다. 스킬북은 파일 업로드 후 발행 방식이라 웹페이지를 등록해 자동으로 따라가게 하는 기능은 없습니다. 셀프서비스에서는 수집 결과를 기준 시각이 담긴 CSV·JSON 문서로 만들어 정기적으로 다시 올려 발행하고, 분 단위 실시간 연동은 기업 도입 범위로 별도 협의합니다.
휴멜로 웹 위젯은 설치 코드에 공개 키만 두고 허용 도메인으로 띄울 사이트를 제한합니다. 같은 에이전트를 콜센터에 배포하면 착신번호(DID)별 라우팅과 바지인을 지원하고, 휴멜로 DIVE TTS가 날짜·시간을 자동 정규화해 실시간 스트리밍으로 읽습니다. 가드레일에는 "기준 시각 없이 대기시간·운행 여부를 단정하지 않는다"를, 상담원 이관 정책에는 분실물·안전 문의를 연결 조건으로 두고, 테스트 케이스로 대기시간 답변에 기준 시각이 들어가는지 배포 전에 점검합니다.
결론적으로, 놀이공원 챗봇의 정확도는 문장력보다 값의 신선도에서 갈립니다. 고정 정보는 문서로, 변동 정보는 공식 출처의 자동 수집과 정기 갱신으로 나누고 위 점검표의 빈칸부터 채워 보시기 바랍니다. 콘솔의 테스트 전화번호로 실제 응대를 들어 보시거나 휴멜로에 도입 범위 검토를 요청해 주시기 바랍니다.
