예약 사이트를 몇 년째 운영하고 있습니다. 회원도 쌓였고 결제도 문제없이 돌아갑니다. 여기에 '대화로 예약하는 기능'을 넣고 싶은데, 홈페이지를 새로 만들어야 한다는 말을 들으면 일이 커집니다. 고객 데이터를 옮기고 결제를 다시 검증하는 부담도 큽니다.
AI 기능을 추가한다고 전체를 다시 개발해야 하는 것은 아닙니다. 기존 서비스가 필요한 정보를 내주고 업무를 실행할 수 있다면, 그 위에 새로운 입력 방식을 연결하면 됩니다. 봐야 할 것은 사이트가 얼마나 오래됐는지가 아니라 어떤 기능을 연결할 수 있는지입니다.
고객이 말하는 방식은 바뀌어도 업무 규칙은 그대로입니다
지금은 고객이 날짜와 인원을 직접 고릅니다. 대화형 예약에서는 '다음 주 토요일에 아이 둘과 갈 수 있는 체험'이라고 말합니다. 입력 방식만 바뀝니다. 판매 가능한 상품, 잔여 수량, 가격을 확인하는 규칙은 똑같이 필요합니다.
AI는 요청을 날짜·인원·상품 조건으로 정리합니다. 후보 조회는 기존 예약 시스템이 하고, 최종 신청은 고객이 조건을 확인한 뒤에 처리합니다. 가격은 대화 모델이 계산하지 않고 현재 시스템의 값을 그대로 씁니다. 그래야 운영 기준이 한곳에서 관리됩니다. AI가 데이터베이스에 직접 접근하는 구조가 아닙니다.
연결 가능성을 가르는 세 가지
첫째는 데이터 접근입니다. 주문과 예약 정보를 조회하는 API가 있는지, 없다면 안전한 서버 기능을 추가할 수 있는지 봅니다.
둘째는 권한입니다. 고객이 보는 자기 예약과 운영자가 보는 전체 예약은 접근 범위가 다릅니다. 이 구분은 AI에게 주는 지시문이 아니라 서버가 지켜야 합니다.
셋째는 업무 상태입니다. 결제 대기, 확정, 취소가 화면에만 표시되고 데이터에는 구분돼 있지 않다면 상태부터 정리해야 합니다. 그대로 AI를 연결하면 고객이 '취소됐나요?'라고 물었을 때 일관된 답을 못 합니다.
API가 없다고 전체를 다시 만들 필요는 없습니다. 조회 기능 몇 개만 추가하면 되는 경우도 있습니다. 반대로 외부 서비스가 연결을 막고 있거나 지금 구조로는 권한 검사를 할 수 없다면 변경 범위가 커집니다. 실제 범위는 진단을 해봐야 나옵니다.
처음에는 기존 화면으로 돌아갈 길을 남깁니다
대화 입력을 처음부터 유일한 예약 경로로 만들지 않습니다. 선택형 화면은 그대로 두고, 대화가 막히면 입력한 조건을 유지한 채 그 화면으로 넘어가게 설계합니다.
시범 운영은 예약을 확정하지 않고 후보만 안내하는 수준으로 시작해도 충분합니다. 잘못 해석한 날짜, 조회 실패, 사용자가 고친 조건을 모으면 개선할 지점이 드러납니다. 검증된 범위에만 확정 기능을 추가하면 변경의 영향이 좁게 유지됩니다.
개편 견적을 받기 전에 준비할 자료
사용 중인 관리자 화면, 고객의 실제 요청 예시, 주문·예약 상태 목록을 준비하세요. 기능 이름보다 실제 사용 장면이 필요합니다. 기술 자료가 없으면 화면 녹화만 있어도 업무를 파악할 수 있습니다. 코드를 볼 수 있으면 필요한 연결 기능과 변경 범위를 더 정확하게 판단합니다.
저희는 현재 서비스를 먼저 진단한 뒤에 AI 기능 연결과 출시 마무리 범위를 정합니다. 전체 재개발 여부를 미리 정하지 않습니다. 남길 기능과 보완할 기능부터 나눕니다. 사이트 주소와 붙이고 싶은 기능을 견적 내보기로 보내주시면 필요한 연결과 기존 코드의 활용 범위를 검토해 드립니다.