AI가 예약한 여행, 책임은 어디서 시작될까: 액션 에이전트 시대의 동의와 면책

“4박 5일 오키나와”가 계약 조건이 되는 순간

“아이와 함께 가기 좋은 오키나와 4박 5일, 오전 출발, 환불 가능한 숙소로 찾아줘.” 사용자는 대화 한 줄로 의도를 표현한다. 그러나 여행 예약 시스템이 처리해야 하는 것은 한 줄의 취향이 아니다. 출발·도착 날짜와 시간대, 성인·아동·유아 인원과 생년월일, 항공편의 수하물 규정, 객실 정원, 조식 포함 여부, 현지 숙박세, 카드 청구 통화, 취소 기한, 공급사의 재고 상태가 서로 얽힌 거래 조건이다.

이 간극이 액션 에이전트의 본질적 위험이다. 기존 검색 서비스의 오류는 대체로 “좋지 않은 결과를 보여줬다”로 끝난다. 반면 에이전트가 장바구니를 만들고 탑승자 정보를 넣고 결제 직전까지 이동하면, 자연어의 모호함이 예약 조건으로 변환된다. ‘아이’가 유아인지 아동인지, ‘오전’이 출발 시각인지 도착 시각인지, ‘환불 가능’이 전액 환불인지 일부 환불인지, 가격 우선인지 환승 최소화 우선인지가 모두 결과를 바꾼다.

따라서 질문은 “AI가 여행 예약을 할 수 있는가”가 아니다. 더 정확한 질문은 이것이다. 사용자의 불완전한 의도를 누가 거래 가능한 조건으로 확정했고, 그 과정에서 중요한 손실 가능성을 누가 발견·고지·승인했는가. 이 질문에 제품 화면, 권한 모델, 데이터 기록으로 답할 수 있어야 서비스를 확장할 수 있다.

여행 산업에서도 대화형 경험은 이미 탐색과 여정 구성의 마찰을 낮추는 방향으로 발전하고 있다. Omio는 실시간 운송 데이터를 활용해 사용자가 목적을 설명하면 예약 가능한 개인화 여정을 제공하는 경험을 실험해 왔다고 소개한다. 검색과 예약 사이의 거리가 줄어드는 만큼, 추천의 설명 가능성과 거래 조건의 확정 절차는 더 중요해진다. 출처: 오미오, 오픈AI 도입해 ‘대화형 여행’ 서비스 혁신 가속

시장은 ‘대답하는 AI’에서 ‘위임받아 움직이는 AI’로 간다

에이전트 시장의 변화는 모델이 문장을 더 잘 만드는 데만 있지 않다. 검색어를 받아 링크를 돌려주던 흐름이 요약·비교를 거쳐, 사용자의 목표를 해석하고 여러 시스템에서 실제 작업을 수행하는 흐름으로 이동하고 있다. 업스테이지 컴퍼니가 키워드 검색, 서치 에이전트, 액션 에이전트라는 발전 단계를 제시하며 예약·구매·결제 자동화를 최종 방향으로 언급한 것도 이 전환을 보여주는 국내 사례다. 출처: 검색엔진·LLM·에이전트 모아 ‘업스테이지 컴퍼니’ 출범

커머스, 금융, 모빌리티, 업무 도구에서 이 변화가 빠르게 보이는 이유는 명확하다. 항공권을 비교한 뒤 예약 화면으로 정보를 옮기는 일, 여러 판매처의 배송 조건을 비교한 뒤 장바구니를 구성하는 일, 반복 청구서를 확인하고 지급안을 만드는 일은 모두 탐색과 실행 사이에 사람의 반복 입력을 둔다. 에이전트는 바로 그 연결 구간을 줄인다.

하지만 자동화 수준이 높아질수록 오류의 성격은 달라진다. 전통적인 서비스 오류는 결제 버튼이 작동하지 않거나 가격 API가 실패하는 식의 명시적 장애가 많았다. 에이전트 오류는 더 자주 ‘그럴듯한 오해’로 나타난다. 사용자가 가족 여행이라고 했는데 항공 좌석과 객실 정원 조건을 따로 최적화해 함께 예약할 수 없는 조합을 만들 수 있다. 가장 저렴한 가격을 찾으라는 요청을 취소 가능성을 희생해 해석할 수도 있다. 시스템은 정상 동작했지만, 문제 정의와 우선순위 판단이 틀린 것이다.

금융권의 에이전트 도입 논의에서도 기존 인증 체계가 사람이 거래 세부 사항을 직접 확인한다는 전제를 두며, 사용자를 대신해 선택·협상·구매하는 위임 소프트웨어를 충분히 전제로 하지 않았다는 문제 제기가 나온다. 이를 여행에 옮기면 결제 인증을 통과했다는 사실만으로 사용자가 모든 예약 조건을 이해하고 선택했다는 뜻은 아니다. 출처: 금융권 에이전틱 AI 도입 급증, 보안 리스크 관리는 ‘낙제점’

책임은 한 문장으로 나뉘지 않는다

문제가 발생했을 때 흔히 두 극단이 나온다. “AI 추천은 참고용이므로 사용자가 책임진다”와 “AI가 개입했으므로 서비스가 전부 책임져야 한다”다. 둘 다 제품 설계에는 도움이 되지 않는다. 실제 책임의 판단은 거래 구조, 제공자 역할, 약관과 개별 고지, 판매 주체, 사용자가 확인할 수 있었던 정보, 관련 법령과 구체적 사실관계에 따라 달라질 수 있다. 이 글은 법률 자문이 아니라, 그 판단이 가능한 서비스를 만드는 방법을 다룬다.

실무에서는 사건을 아래 네 층으로 분해해야 한다.

예를 들어 에이전트가 공급사에서 받은 정확한 ‘환불 불가’ 운임을 결제 직전 명확히 표시했고, 사용자가 해당 항목을 확인한 뒤 구매했다면, AI가 앞단에서 후보를 추천했다는 사실만으로 환불 불가의 위험이 서비스 오류가 되는 것은 아니다. 반대로 ‘무료 취소’라고 요약해 놓고 실제 조건이 특정 시각 이전에만 일부 환불인 경우, 또는 요약 근거와 실제 예약 조건이 달랐는데 이를 식별할 화면과 절차가 없었다면 서비스의 고지·표현·검증 설계가 쟁점이 될 수 있다.

핵심은 책임을 사후에 문구로 옮기는 일이 아니라, 사전에 각 단계의 역할을 분리하는 일이다. 에이전트는 의도를 제안과 조건으로 번역한다. 원천 시스템은 가격·재고·규정을 제공한다. 판매 또는 예약 시스템은 계약을 성립시킨다. 사용자는 최종 선택과 승인에 참여한다. 플랫폼은 이 경계를 화면과 기록으로 드러내야 한다.

도구가 초안을 빠르게 만들더라도 ‘이 정보를 믿을 수 있는가’, ‘현행 정책인가’, ‘누가 책임지는가’는 도구 자체가 결정하지 못한다는 지적은 액션 에이전트에도 그대로 적용된다. 자동화가 기준 부재를 가리는 것이 아니라 더 빨리 드러낸다는 뜻이다. 출처: 도구를 넘어, 기준과 책임으로

약관 동의와 거래 동의는 다르다

서비스 약관은 관계의 기본 규칙을 정한다. 그러나 거래 직전의 동의는 특정 선택의 위험을 인지하고 승인하는 행위여야 한다. 사용자가 가입 때 긴 약관에 체크했다는 사실은, 몇 주 뒤 에이전트가 만든 특정 항공권·숙소 조합의 환불 제한, 추가 비용, 변경 불가 조건을 실제로 확인했다는 증거와 같지 않다.

특히 AI 인터페이스는 이 문제를 악화시킬 수 있다. 대화창은 자연스럽고 간결하기 때문에, 복잡한 조건을 ‘알아서 처리했다’는 인상을 준다. 사용자는 표준 예약 화면에서라면 마주쳤을 운임 규정이나 객실 정책을 보지 못한 채, 대화의 연속성 때문에 최종 제안을 신뢰할 수 있다. 그래서 “AI 결과는 참고용”이라는 포괄 문구를 붙이는 것은 안전장치가 아니라 위험 신호일 수 있다. 사용자의 행동이 실제로는 참고가 아니라 계약 체결로 이어지기 때문이다.

중요한 정보가 명확하게 제공됐는지, 사용자가 이를 실제로 확인할 합리적 기회를 가졌는지는 분쟁 위험을 평가하는 핵심 축이 될 수 있다. 포괄적 면책 조항이 모든 상황에서 책임을 제거한다고 전제해서는 안 된다. 반대로 명확한 설명·경고·확인 흐름과 적절한 제한을 갖췄다고 해서 언제나 책임이 사라진다고 단정할 수도 없다. 구체적 결론은 거래 유형과 관할 법령, 약관, 화면, 운영 사실에 따라 달라진다.

국내 전자상거래와 여행 계약에서도 책임은 단순한 약관 문구만으로 정리되지 않는다. 통신판매중개자의 고지·정보제공의무, 여행사의 계약조건 이행 여부, 소비자의 최종 확인 가능성은 분쟁에서 함께 검토될 수 있다. 출처: 전자상거래 등에서의 소비자보호에 관한 법률 – 국가법령정보센터, 소비자분쟁해결기준 – 국가법령정보센터

제품팀이 할 일은 법률 문구를 더 길게 만드는 것이 아니다. 사용자가 손해와 직접 연결된 선택을 하기 직전, 이해 가능한 형태로 조건을 다시 보여주고 의도적인 승인을 받는 것이다. 법무 검토는 이 설계를 대체하지 않고, 이 설계와 함께 작동해야 한다.

최종 확인 화면은 ‘마지막 모달’이 아니라 계약 전 안전장치다

좋은 최종 확인 화면은 결제 버튼 앞에 정보를 많이 쌓는 화면이 아니다. AI의 자연어 해석을 사람이 검증 가능한 거래 명세로 바꾸는 화면이다. 추천 화면과 분리해 설계해야 하는 이유도 여기에 있다. 추천은 선택지를 넓혀도 되지만, 결제 확인은 애매함을 줄여야 한다.

화면이 반드시 답해야 할 질문

여행 예약의 확인 화면은 적어도 다음을 한 화면 구조 안에서 드러내야 한다.

• 누가 가는가: 탑승자·투숙객 이름, 성인·아동·유아 구분, 생년월일 또는 연령 조건, 여권·비자 등 사용자가 직접 확인해야 할 요건의 안내.
• 언제 어디로 가는가: 날짜, 현지 기준 출발·도착 시각과 시간대, 출발·도착 공항, 경유 여부와 대기 시간, 숙소 체크인·체크아웃 날짜.
• 무엇을 사는가: 항공 운임 등급, 좌석·수하물 포함 여부, 객실 타입과 정원, 조식·교통편·보험 등 포함 및 제외 항목.
• 얼마를 내는가: 기본 금액, 세금·수수료, 현지에서 별도 납부할 가능성이 있는 비용, 할인 적용 조건, 결제 통화와 총 결제금액.
• 되돌릴 수 있는가: 취소 가능 시한, 구간별 환불액 또는 수수료, 변경 가능 여부와 차액 가능성, 노쇼·부분 사용 조건.
• 무엇이 변할 수 있는가: 가격·재고의 확정 시점, 공급사 확인이 필요한 상태인지, 예약 후 일정 변경과 연락 책임이 어떻게 처리되는지.

이 목록은 모든 항목을 동일한 비중으로 보여주라는 뜻이 아니다. 손실 규모와 되돌리기 어려움에 따라 정보의 위계를 정해야 한다. ‘환불 불가’, ‘아동 투숙 불가’, ‘수하물 미포함’, ‘현지 추가 납부’, ‘별도 확인 후 확정’처럼 사용자의 선택을 바꿀 가능성이 큰 조건은 요약 아래에 숨기지 말고 가격과 결제 버튼 가까이에 보여줘야 한다.

확인의 품질을 높이는 인터랙션

체크박스 하나를 추가하면 마찰은 늘지만 확인 품질은 거의 오르지 않는다. 더 나은 방식은 AI가 해석한 핵심 조건을 사용자가 읽고 고칠 수 있게 만드는 것이다. 예를 들어 ‘무료 취소 선호’라는 사용자의 원 요청을 확인 화면에 고정해 두고, 선택한 상품이 그 조건을 충족하지 않을 경우 “요청한 조건과 다름: 이 상품은 환불 불가”라는 대비를 명시한다. 단순 경고보다 훨씬 강한 이유는, 서비스가 사용자의 원래 의도와 최종 선택의 차이를 보여주기 때문이다.

다음은 권장 흐름이다.

자연어 요청
  → 에이전트가 해석한 조건 카드(사용자 수정 가능)
  → 후보 비교(출처·조회 시점·차이점 표시)
  → 선택 상품의 거래 명세
  → 중요 조건 확인 및 불일치 경고
  → 총액·취소 조건 재확인
  → 사용자 최종 승인
  → 결제 또는 예약 요청

확인 화면에서 ‘AI가 추천한 이유’와 ‘공급사가 확정한 조건’을 섞지 않는 것도 중요하다. “아이와 이동하기 편해 추천”은 서비스의 추론이다. “수하물 0개 포함”, “특정 시각 전 취소 시 환불 가능”은 예약 시스템에서 조회한 거래 데이터다. 전자는 추천 근거로, 후자는 출처·조회 시점과 함께 계약 조건으로 표시해야 한다. 관광 데이터와 AI를 직접 연결해 허위·부정확한 안내를 줄이려는 공공 관광 분야의 시도도, 결국 신뢰할 원천과 생성 결과를 연결해야 한다는 문제의식을 보여준다. 출처: 서울관광재단·나무기술, 공공 관광 분야 첫 MCP 도입 추진

Human-in-the-loop: 사람을 끼워 넣는 것이 아니라 결정권을 배치하는 일

Human-in-the-loop은 단순히 마지막에 ‘확인’을 누르게 하는 패턴이 아니다. 어느 판단을 시스템에 맡기고, 어느 판단을 사용자가 되찾아야 하는지를 위험 기반으로 배치하는 운영 모델이다. 인간 개입이 형식적이면 자동화의 오류를 승인 절차로 세탁할 뿐이다.

여행 서비스에서 사람의 개입이 강해야 하는 지점은 보통 세 가지다. 첫째, 모호한 의도를 계약 조건으로 바꾸는 순간이다. “저렴하면서 편한 편”처럼 상충할 수 있는 요청은 우선순위를 질문하거나, 에이전트의 해석을 명시적으로 수정하게 해야 한다. 둘째, 손해가 크거나 비가역적인 행동 전이다. 환불 불가 상품, 국제선 발권, 고액 결제, 복수 인원 예약, 취소·변경은 별도 승인 대상이다. 셋째, 데이터 신뢰도가 낮거나 조건 충돌이 감지된 순간이다. 공급사 응답이 오래됐거나, 객실 정원과 인원 조건이 맞지 않거나, 가격이 크게 변했으면 자동 진행보다 재조회와 재확인을 우선해야 한다.

여기서 중요한 원칙은 에이전트가 확신한다고 해서 권한이 커지지 않아야 한다는 점이다. 모델이 “적합하다”고 평가한 확률이나 자연스러운 설명은 결제 권한의 근거가 될 수 없다. 권한은 사용자 위임의 범위, 행동의 금전적 영향, 취소 가능성, 데이터의 최신성, 이상 징후에 따라 결정해야 한다.

서비스별로 같은 원칙을 적용하면 다음과 같다.

이 구조는 사용자를 불편하게 만들기 위한 것이 아니다. 사용자가 정말 통제해야 할 순간에만 주의를 집중시키고, 나머지 반복 작업은 자동화하기 위한 것이다. 승인 요청이 너무 자주 뜨면 사용자는 읽지 않는다. 반대로 고위험 순간에 승인 절차가 없으면 서비스는 편리함과 함께 통제권도 빼앗는다. 좋은 설계는 승인 횟수가 아니라 승인당 정보 가치와 행동의 명확성을 최적화한다.

권한은 기능이 아니라 상태 전이로 설계해야 한다

‘AI 예약 기능’이라는 한 개의 권한은 너무 크다. 조회와 추천, 예약 정보 입력, 예약 확정, 결제, 변경, 취소는 손실 규모도 되돌릴 가능성도 서로 다르다. 초기에는 작업 단위를 분리하고, 상태 전이마다 다른 승인 규칙을 둬야 한다.

권장하는 단계는 다음과 같다.

1. 조회 권한: 상품·규정·가격을 읽는다. 개인 데이터와 제3자 데이터의 접근 범위를 최소화한다.
2. 추천 권한: 후보를 정렬하고 일정안을 만든다. 추천 이유, 충족하지 못한 조건, 데이터 조회 시점을 함께 제공한다.
3. 구성 권한: 장바구니와 예약 초안을 만든다. 이 단계의 결과는 ‘임시안’이며 계약 또는 결제로 보이지 않게 구분한다.
4. 입력 보조 권한: 사용자가 제공한 정보를 예약 양식에 채운다. 민감 정보는 마스킹하고, 입력 출처와 수정 주체를 남긴다.
5. 예약 요청 권한: 외부 공급사에 예약 가능 여부를 요청한다. 확정 전 상태와 확정 후 상태를 UI와 로그에서 명확히 구분한다.
6. 결제·변경·취소 권한: 매번 명시적 사용자 승인, 재인증 또는 설정된 위임 한도 검증을 거친다. 최종 실행 직전 최신 가격과 규정을 재조회한다.

이 분리는 보안과 운영에도 유리하다. 에이전트가 외부 시스템의 자격 증명을 광범위하게 가지면 프롬프트 오염, 계정 탈취, 잘못된 도구 호출이 곧 금전 피해가 된다. 실행에 필요한 최소 권한만 짧은 시간 동안 부여하고, 목적·금액·대상·유효기간을 묶은 위임 토큰 또는 승인 컨텍스트로 검증하는 편이 낫다. 결제 도구는 ‘사용자 A가 여행 관련 모든 결제를 허용했다’가 아니라 ‘사용자 A가 이 예약안의 이 총액 범위에서 이 판매자에게 결제하는 것을 이 시점에 승인했다’에 가까운 권한을 받아야 한다.

비인간 식별자와 에이전트 권한 추적, 실행 행동 검증이 AI 보안의 중요한 축으로 떠오르는 흐름도 이 설계의 배경이다. 에이전트의 정체성과 권한, 실제 호출 행위를 분리해 관찰하지 않으면, 누가 무엇을 실행했는지 나중에 설명하기 어렵다. 출처: AI는 지금: 시스코, AI 에이전트 보안 승부수

감사 로그는 장애 분석용 로그보다 넓어야 한다

결제가 성공했다는 이벤트 하나는 분쟁을 해결하지 못한다. 액션 에이전트의 로그는 시스템이 무엇을 했는지뿐 아니라, 왜 그 행동이 사용자의 의도에 부합한다고 판단됐는지와 사용자가 무엇을 승인했는지를 재구성할 수 있어야 한다.

최소한 다음 네 묶음의 기록을 연결하자.

1. 의도와 해석 기록

원문 요청, 에이전트가 추출한 조건, 모호성 질문과 답, 사용자가 수정한 제약, 우선순위 추론 결과를 남긴다. 원문 전체를 무기한 보관할 필요는 없으며, 개인정보와 민감 정보를 최소화·마스킹하고 보존 기간을 정해야 한다. 중요한 것은 ‘사용자는 최저가만 원했다’ 같은 사후 추정이 아니라, 당시 시스템이 어떤 조건을 우선 처리했는지다.

2. 원천 데이터와 제안 기록

상품 식별자, 공급사 또는 판매자, 가격·재고·규정 조회 시각, 원문 정책의 버전 또는 스냅샷 식별자, AI가 생성한 요약과 출처 연결을 보관한다. 실시간 데이터와 일반 지식 기반 설명은 반드시 구분한다. ‘현지 세금이 있을 수 있다’는 일반 안내는 참고 정보이고, ‘이 예약에 적용되는 세금과 수수료’는 거래 데이터다. 후자를 전자로 대체하면 안 된다.

3. 사용자 상호작용과 동의 기록

어떤 화면 버전에서 무엇을 표시했는지, 사용자가 어떤 조건을 펼쳐 보거나 수정했는지, 불일치 경고가 노출됐는지, 최종 버튼을 누른 시각과 인증 결과가 무엇인지 남긴다. 단, 단순 페이지 노출을 ‘읽고 이해했다’로 과장해서는 안 된다. 기록의 목적은 사용자의 책임을 떠넘기는 증거 수집이 아니라, 고지와 승인 흐름이 실제로 작동했는지 검증하는 것이다.

4. 실행과 사후 상태 기록

어떤 서비스 계정 또는 에이전트 신원으로 외부 호출을 했는지, 요청·응답 식별자, 공급사의 확정 결과, 실패·재시도, 가격 변경, 취소·환불 처리 상태를 추적한다. 외부 시스템에서 수정된 예약이라면 그 출처도 구분해야 한다. 그래야 AI 추천 오류, 공급사 데이터 오류, 연동 장애, 사용자 변경, 운영자 개입을 구별할 수 있다.

이 로그는 고객센터의 사후 대응에도 직접적인 효용이 있다. 상담사가 대화 전문을 뒤져 추측하는 대신, ‘추천 시점의 가격’, ‘결제 전 재조회 결과’, ‘환불 불가 경고 노출’, ‘사용자 변경 사항’을 동일한 사건 타임라인에서 확인할 수 있다. 개발팀은 오류 패턴을 분석하고, 운영팀은 민원 대응을 일관되게 하며, 정책팀은 어떤 경고가 무시되는지 개선할 수 있다. AI 실행 내역에 프롬프트·결과·타임스탬프 수준의 감사 추적이 필요하다는 보안 논의는, 거래 서비스에서 더 높은 수준으로 적용할 필요가 있다. 출처: AI 코딩 도구의 한계, ‘코드 생성’ 넘어 ‘안전한 실행’으로

원천 데이터 고정과 출처 표시는 신뢰의 최소 단위다

에이전트가 설명한 모든 문장에 같은 신뢰도를 부여하면 안 된다. 서비스는 적어도 세 종류의 정보를 구분해 보여줘야 한다.

• 거래 원천 데이터: 판매자·공급사 시스템에서 실시간 또는 지정 시점에 조회한 가격, 재고, 운임 규정, 수하물, 객실 정책, 취소·환불 조건.
• 서비스 계산 결과: 여러 가격을 합산한 총액, 시간대 변환, 일정의 이동 시간, 수수료 추정처럼 명시적 입력을 계산한 값.
• AI 해석과 제안: ‘아이와 이동하기 편하다’, ‘비가 와도 일정이 유연하다’, ‘가성비가 좋다’처럼 모델이 조건과 일반 정보를 종합한 판단.

이 구분은 디자인 디테일이 아니라 책임 경계다. 세 번째 항목은 유용하지만 틀릴 수 있으며, 사용자의 취향과 맥락에 따라 평가가 달라진다. 첫 번째 항목은 정확성·최신성·동기화 체계가 핵심이다. 두 번째 항목은 계산식과 입력값 검증이 중요하다. 오류의 원인과 대응 방식이 각각 다르므로 한 개의 ‘AI 답변’으로 뭉치면 안 된다.

가격과 재고는 특히 ‘조회 시점’이 의미를 가진다. 추천 목록에서 본 가격과 결제 직전 가격이 다르면, 변경 사실과 새 총액을 명확하게 보여주고 재승인을 받아야 한다. 예약 조건이 외부 공급사의 확정을 기다리는 구조라면 ‘예약 완료’라는 표현 대신 ‘예약 요청 접수’ 또는 ‘공급사 확인 중’처럼 상태를 정확히 표시해야 한다. 불확실성을 숨겨 전환율을 높이는 방식은 단기적으로는 편해 보여도, 액션 에이전트에서는 신뢰 비용을 크게 만든다.

검색 결과에 출처를 붙이는 AI 오버뷰의 확산은 탐색 단계의 투명성 요구를 보여준다. 하지만 실행 단계에서 필요한 것은 출처 링크보다 더 엄격한 연결이다. 사용자가 결제하는 조건이 어느 판매자의 어떤 규정 버전에서 왔는지, 그 조건이 AI 요약 과정에서 어떻게 보존됐는지까지 추적돼야 한다. 출처: 검색엔진·LLM·에이전트 모아 ‘업스테이지 컴퍼니’ 출범

제품팀이 지금 만들어야 할 운영 기준

기능 출시 전, PO·개발·디자인·운영·법무가 한 자리에 놓고 답해야 할 질문은 많지 않다. 다만 답을 문서와 화면과 시스템 정책에 같은 뜻으로 반영해야 한다.

1. 행동 분류표부터 만든다

모든 도구 호출을 ‘조회’, ‘임시 변경’, ‘외부 요청’, ‘금전 이동’, ‘되돌리기 어려운 변경’으로 분류한다. 각 분류마다 필요한 사용자 승인, 재인증, 금액 한도, 재조회, 로그 수준, 실패 시 보상 또는 상담 연결 정책을 정한다. ‘예약’이라는 한 단어로는 설계할 수 없다.

2. 위험 시나리오로 승인 UX를 검증한다

정상 플로우만 보지 말고 최소한 다음을 시연해야 한다.

• 사용자가 “다음 주말”이라고 말했는데 대화 시점 또는 시간대 차이로 날짜가 달라지는 경우
• 아동 연령이 항공사·숙소 기준과 다르고, 객실 정원이 초과되는 경우
• 추천 이후 결제 직전에 가격 또는 재고가 바뀌는 경우
• 항공은 환불 가능하지만 숙소는 환불 불가인 묶음 상품인 경우
• 사용자가 취소를 요청했으나 일부 구간이 이미 사용됐거나 공급사 확인이 필요한 경우

각 경우 화면은 무엇을 보여주고, 에이전트는 멈추는지 재질문하는지, 사용자는 무엇을 승인하며, 로그에는 무엇이 남는지를 점검한다. 이 테스트는 모델 정확도 평가와 다르다. ‘정답률’이 높아도 한 번의 고위험 오판이 고객 손실로 이어질 수 있기 때문이다.

3. 운영자가 개입할 수 있는 복구 경로를 둔다

고객센터는 에이전트가 남긴 자연어 요약만 보고 판단해서는 안 된다. 원천 조회, 정책 버전, 승인 이벤트, 외부 호출 상태를 한 사건 화면에서 확인할 수 있어야 한다. 자동 취소나 자동 환불이 불가능한 경우에도, 고객에게 현재 상태·다음 처리 주체·예상 확인 시점을 정확히 안내하는 운영 흐름이 필요하다.

4. 측정 지표를 전환율 밖으로 넓힌다

에이전트가 만든 장바구니의 결제 전환율만 보면, 중요한 경고를 덜 보여주는 설계가 좋아 보일 수 있다. 조건 수정률, 가격 변경 후 이탈률, 예약 후 취소 사유, 고객센터 이관률, 경고 노출 후 선택 변화, AI 해석을 사용자가 정정한 비율, 승인 뒤 분쟁 발생률을 함께 봐야 한다. 이 지표들은 자동화가 사용자의 의도를 제대로 보존하는지 보여준다.

5. 책임 문서를 제품과 동기화한다

약관, 개인정보 안내, 예약 조건, 화면 문구, 고객센터 스크립트, 장애 대응 런북이 서로 다른 말을 하면 분쟁과 운영 비용이 커진다. 디자인 시스템이 화면 구성 요소를 표준화하듯, 책임과 고지에도 재사용 가능한 컴포넌트가 필요하다. 다만 일관성은 같은 문구를 모든 곳에 복사하는 일이 아니라, 위험 수준에 맞는 고지·확인·기록 패턴을 일관되게 적용하는 일이다. AI가 UI 제작의 하한을 빠르게 올리는 환경일수록, 제품 조직의 차이는 화면의 완성도보다 결정 기준과 운영 책임에서 커질 수 있다. 출처: 디자인시스템 팀은 디자인시스템만 잘 만들면 될까

전망: 완전 자동 결제보다 ‘확인 가능한 위임’이 먼저 온다

가까운 시기에 모든 예약과 결제가 사람의 개입 없이 이뤄질 것이라고 보는 것은 성급하다. 여행은 고액 거래일 수 있고, 다수 공급사와 국경·시간대·개인 자격 조건이 얽히며, 취소 비용이 큰 상품도 많다.

그래서 먼저 확산될 형태는 ‘결제 직전까지의 고도화된 보조’일 것이다. 에이전트가 조건을 대화로 수집하고, 실시간 데이터를 바탕으로 조합을 만들고, 차이와 위험을 설명하고, 예약 정보를 초안으로 넣는다. 마지막 결제·변경·취소는 사용자가 구조화된 명세를 확인한 뒤 승인한다. 이는 자동화가 덜 된 모델이 아니라, 거래의 위험을 정확히 배분한 모델이다.

장기적으로 사용자가 반복 거래에 대해 더 넓은 위임을 선택할 수는 있다. 그때도 서비스는 포괄 권한을 기본값으로 두기보다 금액 한도, 판매자 범위, 상품 유형, 시간 범위, 취소 가능성, 예외 조건을 사용자가 조절하게 해야 한다. ‘항상 예약해줘’가 아니라 ‘이 선호 조건, 이 예산, 이 판매자, 이 기간 안에서만 후보를 확정 전까지 준비해줘’처럼 위임을 세분화하는 방향이 안전하다.

공급망·물류에서 에이전틱 AI의 성과가 단순 모델 도입보다 미들웨어, 변화 관리, 데이터 거버넌스 재설계와 연결된다는 지적도 참고할 만하다. 여행·커머스 역시 모델을 붙이는 것보다 원천 데이터, 권한, 승인, 분쟁 처리의 연결을 먼저 정비해야 실질적 가치를 만들 수 있다. 출처: 공급망·물류 시장 흔드는 에이전틱 AI, 실질적 승자는 누구인가

결론: 면책이 아니라 책임의 흐름을 제품 안에 남겨라

액션 에이전트가 거래 서비스에 들어오면, 제품은 더 이상 추천 화면만 만드는 일이 아니다. 사용자의 모호한 의도를 계약 조건으로 번역하고, 원천 데이터를 확인하며, 손해 가능성이 큰 선택을 드러내고, 적절한 시점에 사람의 승인과 권한을 받아 실행하는 시스템을 만드는 일이다.

“AI 추천 결과는 참고용”이라는 문구는 이 문제를 해결하지 못한다. 사용자가 실제로 무엇을 보았는지, AI가 어떤 데이터를 근거로 무엇을 제안했는지, 가격·규정이 언제 확정됐는지, 누가 어떤 권한으로 실행했고 사용자가 무엇을 최종 승인했는지에 제품이 답해야 한다. 그 답은 법무 문서 한 장이 아니라 최종 확인 화면, 권한 정책, 감사 로그, 고객지원 도구, 운영 지표에 함께 존재해야 한다.

AI 에이전트 시대의 경쟁은 자동화율만으로 정해지지 않을 것이다. 사용자가 통제권을 잃지 않으면서도 복잡한 거래를 끝낼 수 있게 만들고, 오류가 났을 때 원인과 책임의 경계를 재구성할 수 있게 만드는 기업이 신뢰를 얻는다. 결국 강한 액션 에이전트는 더 많은 일을 몰래 처리하는 에이전트가 아니라, 더 많은 일을 확인 가능하고 책임 가능하게 처리하는 에이전트다.

참고 출처

• 검색엔진·LLM·에이전트 모아 ‘업스테이지 컴퍼니’ 출범
• AI 모델부터 포털까지…업스테이지 컴퍼니, 에이전트 시대 연다 – ZDNet Korea
• How Omio is building the future of conversational travel – OpenAI
• 도구를 넘어, 기준과 책임으로
• 금융 분야 AI Agent 전략: 규제 속에서 신뢰를 구축하는 방법 – 삼성SDS
• 서울관광재단·나무기술, 공공 관광 분야 첫 MCP 도입 추진
• AI 코딩 도구의 한계, ‘코드 생성’ 넘어 ‘안전한 실행’으로
• AI는 지금: 시스코, AI 에이전트 보안 승부수
• 디자인시스템 팀은 디자인시스템만 잘 만들면 될까
• 공급망·물류 시장 흔드는 에이전틱 AI, 실질적 승자는 누구인가