예약 시스템에 AI 에이전트를 붙인다면, 설계 원칙

 

예약 시스템 기획을 하다 보면 "AI가 대신 예약해주면 되지 않나요?"라는 이야기를 자주 듣게 됩니다.
말로 하면 간단한데, 막상 설계하려고 하면 따져볼 것이 한두 가지가 아니에요.

이번 글은 예약 시스템에 AI 에이전트를 붙인다고 가정했을 때, 제가 기획자로서 지켜야 한다고 생각하는 설계 원칙을 정리한 것입니다.
실제로 만들어서 운영한 경험을 쓰는 글은 아니고, 그동안 예약 도메인과 AI를 함께 공부하며 정리한 가설에 가깝습니다.
그래서 확정된 정답이라기보다 "이런 선을 먼저 그어두면 좋겠다"는 메모로 읽어주시면 좋겠습니다.

 

에이전트를 붙인다고 하면 모든 걸 맡기고 싶은 마음이 먼저 듭니다.
하지만 처음에는 할 일을 아주 좁게 정하는 것이 안전하다고 생각해요.

예를 들어 가상의 반려동물 미용실이 있다고 해보겠습니다.
이 미용실의 손님이 에이전트에게 "이번 주 토요일 오후에 소형견 목욕 가능한 시간 알려줘"라고 말하는 장면입니다.

첫 단계의 에이전트는 이 정도만 할 수 있게 합니다.
영업시간과 서비스 소요시간을 조회하고, 빈 시간 후보를 몇 개 제안하고, 서비스 안내 문구를 설명해주는 일이에요.
반대로 예약을 확정하거나 취소하거나 금액을 바꾸는 일은 처음부터 열어주지 않습니다.

범위를 나눌 때는 "이 일을 잘못하면 누가 어떤 손해를 보는가"를 기준으로 삼습니다.
빈 시간을 잘못 안내하면 손님이 한 번 더 물어보면 되지만, 잘못 확정하면 운영자가 같은 시간을 중복으로 책임져야 할 수 있어요.
손해가 커질수록 에이전트의 자율성을 줄이는 것이 기본 방향입니다.

 

가장 먼저 지키고 싶은 원칙은 읽기와 쓰기를 구분하는 것입니다.

읽기는 정보를 보기만 하는 일입니다.
빈 시간 조회, 서비스 목록 확인, 내 예약 내역 보기 같은 것들이죠.
쓰기는 시스템의 상태를 바꾸는 일입니다.
예약 생성, 변경, 취소, 결제 같은 것들이에요.

처음 설계할 때는 에이전트에게 읽기 권한만 주는 것이 좋다고 봅니다.
쓰기가 필요한 기능은 하나씩 따로 열고, 열 때마다 어떤 조건에서만 가능한지를 적어둡니다.

예를 들어 "예약 변경은 본인의 예약에 한하고, 시작 시각까지 정해진 시간 이상 남은 경우에만 가능"처럼요.
이 조건은 에이전트의 판단에 맡기지 않고 시스템 쪽에서 강제하는 것이 중요합니다.
에이전트가 아무리 정중하게 부탁받아도, 시스템이 허용하지 않는 일은 실행되지 않아야 해요.

 

두 번째 원칙은 되돌리기 어려운 일 앞에 확인 단계를 넣는 것입니다.

예약 확정 직전에 에이전트가 이렇게 정리해서 보여준다고 생각해보세요.
"토요일 오후 2시, 소형견 목욕, 소요 약 60분, 요금 ○○원입니다. 이대로 확정할까요?"
손님이 "네"라고 명시적으로 답해야 비로소 확정이 이루어집니다.

여기서 "사람"은 상황에 따라 두 군데일 수 있습니다.
하나는 요청한 손님 본인이고, 다른 하나는 운영하시는 분입니다.
예를 들어 평소와 다른 요청(영업시간 밖, 매우 긴 시술 등)이 들어오면 운영자의 승인 대기로 넘기는 방식이 가능합니다.

결제는 더 보수적으로 다뤄야 한다고 생각해요.
금액과 대상, 환불 규정을 사용자가 직접 눈으로 확인한 다음, 결제 자체는 기존에 검증된 결제 화면에서 이뤄지도록 하는 편이 안전합니다.
에이전트가 대화창 안에서 결제까지 다 처리하는 구조는 편리해 보이지만, 문제가 생겼을 때 책임 소재를 가르기가 어려워요.

 

멀티테넌트 예약 시스템이라면 이 원칙이 특히 중요합니다.

업장마다 테넌트가 나뉘어 있는데, 에이전트가 다른 업장의 정보를 우연히 섞어서 답한다면 큰 문제입니다.
예를 들어 A 미용실 손님에게 B 미용실의 예약 현황이나 가격이 안내되는 일은 있어서는 안 돼요.

이를 막으려면 두 가지가 필요하다고 생각합니다.

하나는 에이전트가 호출하는 기능마다 현재 대화가 속한 테넌트 정보가 시스템에서 자동으로 붙게 하는 것입니다.
모델이 "어느 업장인지"를 말로 정하게 두지 않고, 서버가 세션 정보에서 결정해주는 방식이에요.

다른 하나는 사용자 개인의 데이터도 같은 방식으로 지키는 것입니다.
로그인한 손님은 본인 예약만, 운영자는 자기 업장의 예약만 볼 수 있어야 합니다.
에이전트는 요청한 사람의 권한을 대신 쓰는 것이지, 그보다 더 큰 권한을 갖는 것이 아니라는 점을 설계 문서에 분명히 적어둡니다.

 

네 번째 원칙은 실패를 정상 상황으로 설계하는 것입니다.

에이전트는 잘못 알아들을 수 있고, 시스템은 일시적으로 응답하지 않을 수 있고, 같은 시간대에 다른 손님이 먼저 예약할 수도 있습니다.
이럴 때 어떻게 행동할지 미리 정해두지 않으면, 손님은 "예약된 건지 아닌지"를 모르는 상태에 빠집니다.

제가 생각하는 기본 규칙은 세 가지입니다.
확정 결과는 항상 시스템의 응답을 기준으로 안내하고, 에이전트가 "아마 됐을 거예요" 같은 추측을 말하지 않게 합니다.
요청이 중간에 실패하면 어디까지 처리되었는지를 사용자에게 사실대로 알려줍니다.
되돌릴 수 있는 일은 되돌리는 경로를 같이 안내합니다.
예를 들어 방금 만든 예약을 취소하는 방법을 바로 보여주는 식이에요.

그리고 모든 쓰기 동작은 기록으로 남깁니다.
누가 어떤 요청을 했고, 에이전트가 어떤 기능을 호출했고, 시스템이 무엇을 응답했는지를 나중에 확인할 수 있어야 문제를 추적하고 개선할 수 있습니다.

그래도 풀리지 않을 때는 사람에게 넘기는 출구가 필요합니다.
"이 부분은 직접 확인해드릴게요" 하고 운영자에게 문의가 전달되는 경로가 있으면, 에이전트의 한계가 서비스의 한계가 되지 않아요.

 

정리해보면 원칙은 단순합니다.
좁게 시작하고, 읽기와 쓰기를 나누고, 되돌리기 어려운 일은 확인받고, 테넌트와 사용자 경계를 지키고, 실패를 설계하는 것입니다.

이 원칙들은 AI가 대단히 똑똑해지더라도 쉽게 바뀌지 않을 거라고 생각해요.
오히려 모델이 더 유능해질수록 "어디까지 맡길 것인가"를 정하는 기획의 몫이 커질 것 같습니다.

 

아직 풀지 못한 질문도 있습니다.
어느 수준의 확인 단계까지가 안전을 높이고, 어디부터가 사용자에게 번거로움이 되는지입니다.
이건 문서만으로는 알 수 없고, 가정한 시나리오를 만들어 놓고 사용성을 지켜보면서 조금씩 맞춰가야 할 부분이라고 생각합니다.