예약 서비스의 AI 기능, 어디까지 맡길지 자동화 수준 정하기

 

 

예약 서비스 기획을 하다 보면 AI 기능 이야기가 나올 때마다 같은 질문에 부딪힙니다.
"그래서 AI가 어디까지 알아서 하게 할 건가요?"라는 질문이에요.

처음에는 이걸 "할 수 있다 / 없다"의 문제로 생각했어요.
그런데 공부하고 정리하다 보니 진짜 질문은 "할 수 있느냐"보다 "알아서 하게 둬도 되느냐"에 가깝더라고요.
모델이 예약을 바꾸는 일 자체는 기술적으로 어렵지 않아졌지만, 바꿔도 되는 일인지는 전혀 다른 문제입니다.

이번 글은 AI 기능의 자동화 수준을 단계로 나눠 보고, 예약 서비스의 기능별로 어느 단계가 어울리는지 정리해본 메모입니다.
실제로 만들어 운영한 결과를 쓰는 글은 아니고, 기획하면서 공부한 내용을 바탕으로 한 가설에 가깝습니다.
예시에 나오는 업장과 숫자는 모두 설명을 위해 가정한 것이에요.

 

"자동화"라는 말이 너무 뭉뚱그려져 있어서, 먼저 단계를 나눠 보았습니다.
정답이 있는 분류는 아니고, 대화할 때 같은 말을 쓰기 위한 눈금 정도로 생각해주세요.

 

1단계는 추천만 하는 수준입니다.
AI가 후보나 의견을 보여주고, 실행은 전부 사람이 합니다.
화면에 "이 시간대가 비어 있어요" 정도를 띄워주는 모습이에요.

2단계는 초안을 만들고 사람이 확인하는 수준입니다.
AI가 답변이나 변경안을 완성된 형태로 만들어 두고, 사람이 읽고 승인해야 실제로 나갑니다.
보내기 직전까지는 AI가 하고, 보내는 버튼은 사람이 누르는 구조입니다.

3단계는 조건부로 자동 실행하는 수준입니다.
미리 정해둔 조건 안에서는 AI가 바로 실행하고, 조건을 벗어나면 사람에게 넘깁니다.
예를 들어 "예약 하루 전까지, 금액 변동이 없는 시간 변경만 자동 처리" 같은 식이에요.

4단계는 완전 자동입니다.
AI가 판단하고 실행하고, 사람은 결과만 나중에 봅니다.
이렇게 나누고 나니 "AI를 붙일까 말까"라는 이분법이 사라지고, 기능마다 "몇 단계로 시작할까"를 묻게 되었어요.
논의가 훨씬 구체적이 되더라고요.

 

기능 네 가지를 놓고 생각해보았습니다.
가상의 작은 요가 스튜디오가 테넌트라고 가정해볼게요.

 

첫째는 문의 답변입니다.
"주차 되나요?", "초보자도 들을 수 있나요?" 같은 문의가 들어오면 AI가 답변 초안을 만들어 둡니다.
저는 여기서 시작하기에 2단계가 가장 무난하다고 생각해요.
답변이 틀려도 운영자가 읽고 고칠 수 있고, 고객에게 나가기 전에 한 번 걸러지기 때문입니다.
자주 나오는 단순 질문만 3단계로 올릴 수는 있지만, 그것도 운영자가 쌓인 초안을 충분히 본 다음의 이야기라고 생각합니다.

둘째는 빈 시간 추천입니다.
이건 1단계, 즉 추천만으로도 충분히 가치가 있어요.
고객이 "수요일 저녁에 가능한 수업 알려줘"라고 하면 빈 슬롯을 계산해서 보여주는 일이고, 계산 자체는 시스템이 맡습니다.
틀리더라도 고객이 선택하는 단계에서 다시 확인되니 위험이 낮습니다.
다만 "추천해준 시간이 실제로는 이미 찼다"는 상황이 생기지 않도록, 확정 시점에 시스템이 다시 검증하는 것은 단계와 상관없이 필요합니다.

셋째는 예약 변경입니다.
같은 날 다른 시간으로 옮기는 것과, 다른 날로 옮기면서 요금이 달라지는 것은 위험도가 전혀 달라요.
그래서 변경은 한 덩어리로 보지 않고 쪼개서 봐야 한다고 생각합니다.
단순한 시간 이동은 3단계 후보가 될 수 있고, 금액이나 정책 예외가 걸리면 2단계로 내려 사람이 확인하게 하는 식입니다.

넷째는 취소와 환불입니다.
돈이 오가고, 정책 해석이 들어가고, 고객 감정이 걸려 있는 영역이에요.
저는 이 기능은 오래도록 2단계에 두는 것이 맞다고 봅니다.
AI가 "취소 규정상 환불 가능 금액은 이렇습니다"라는 초안을 만들어 주는 것까지만 하고, 최종 처리는 사람이 하는 방식이에요.
4단계는 적어도 지금 제 공부 수준에서는 이 기능에 어울리지 않는다고 생각합니다.

 

기능별로 단계를 고르는 기준은 결국 두 가지로 모였습니다.
틀렸을 때 얼마나 아픈가, 그리고 틀렸을 때 되돌릴 수 있는가입니다.

예를 들어 가정으로 이런 두 장면을 비교해볼게요.

하나는 AI가 고객에게 틀린 영업시간을 안내한 경우입니다.
고객이 헛걸음할 수 있지만, 정정 안내를 보내면 대부분 수습됩니다.
피해 범위가 한 사람이고 되돌릴 방법도 있어요.

다른 하나는 AI가 환불을 잘못 실행한 경우입니다.
이미 나간 돈을 돌려받으려면 고객에게 다시 연락해야 하고, 신뢰까지 영향을 받을 수 있어요.
되돌리기가 어렵고 운영자가 직접 책임을 집니다.

그래서 저는 간단한 질문 세 개를 기능마다 던져보려고 합니다.
돈이나 정책 해석이 걸려 있는가.
고객이나 운영자에게 한 번 나가면 거둘 수 없는 것인가.
틀렸을 때 영향을 받는 사람이 한 명인가, 여러 명인가.

세 질문 중 하나라도 "그렇다"에 가까우면 단계를 한 칸 낮추는 것이 기본값입니다.
반대로 셋 다 "아니다"에 가까우면 한 칸 올려볼 수 있겠다고 생각해요.
이 질문들은 이전에 정리한 에이전트 설계 원칙과 같은 뿌리입니다.

 

여기까지 정리하고 나서 가장 크게 들었던 생각은, 이 단계를 제가 일괄로 정하면 안 된다는 것이었어요.
테넌트마다 사정이 다르기 때문입니다.

예를 들어 직원이 혼자인 작은 업장은 문의에 바로 답하기 어려우니 자동 답변이 반가울 수 있습니다.
반대로 단골 위주로 운영하는 업장은 말투 하나까지 직접 챙기고 싶어서 모든 답변을 직접 확인하고 싶을 수 있어요.

그래서 어드민에 이런 설정을 두는 모습을 그려보았습니다.
기능별로 "추천만", "초안 후 확인", "조건부 자동", 이렇게 선택하는 항목이에요.
완전 자동은 처음에는 열어두지 않고, 충분히 써본 뒤에 필요하면 검토하자는 생각입니다.

설정을 만들 때 신경 쓸 점이 몇 가지 있습니다.

기본값은 보수적으로 둡니다.
처음 켰을 때는 가장 낮은 단계에서 시작하고, 운영자가 올리는 방향으로만 움직이게 해요.

조건부 자동의 조건은 운영자가 직접 읽을 수 있는 말로 보여줍니다.
"하루 전까지 시간만 바뀌는 변경은 자동 처리"처럼 문장으로 보여야 무엇을 맡겼는지 알 수 있어요.

요금제와도 연결해볼 수 있습니다.
다만 안전과 관련된 기능을 요금제로 갈라두는 것은 조심스러워서, 이 부분은 아직 고민 중입니다.

 

단계를 높여 맡길수록 "무슨 일이 있었는지 볼 수 있는 것"이 중요해집니다.
자동화 수준과 관찰 가능성은 같이 올라가야 한다고 생각해요.

기록에는 최소한 이런 내용이 남아야 할 것 같습니다.
어떤 요청이 들어왔는지, AI가 무엇을 제안했는지, 사람이 승인했는지 자동 실행됐는지, 실행 결과가 어땠는지입니다.
그리고 사람이 AI의 초안을 고쳐서 보냈다면 그 수정 내용도 남기고 싶어요.
이 기록이 쌓이면 "이 정도면 단계를 올려도 되겠다"를 감이 아니라 근거로 판단할 수 있기 때문입니다.

알림도 같이 설계해야 합니다.
조건부 자동으로 처리된 일은 운영자에게 요약해서 알려주고, 조건을 벗어나 사람에게 넘어온 일은 눈에 띄게 알려줍니다.
너무 자주 울리면 결국 꺼버리게 되니, 어떤 건 즉시 알리고 어떤 건 하루치를 모아 보여줄지도 정해야 해요.
되돌리기 버튼이 있다면 알림에서 바로 닿을 수 있어야 하고요.

아직 남은 질문도 많습니다.

단계를 올려도 되는 시점을 어떤 지표로 판단할지, 아직 확신이 없어요.
고객에게 "AI가 답했다"는 사실을 어떻게 알릴지도 정해두지 못했습니다.
그리고 테넌트가 단계를 잘못 골랐을 때 서비스 쪽에서 어디까지 막아줄지도 고민입니다.

지금의 생각을 한 줄로 줄이면, AI 기능을 기획한다는 것은 무엇을 시킬지보다 "어디까지 맡기고 어디서 사람이 받아줄지"를 정하는 일이라는 것입니다.
이 감각을 계속 다듬어 보려고 해요.