파트너의 성장이 곧 성과가 되는 곳, 그리고 그 전환에 AI를 쓴 이유

마이리얼트립의 투어&액티비티(T&A) 비즈니스에서 파트너는 단순한 공급자가 아닙니다.
여행자가 현지에서 경험하는 투어와 액티비티의 품질은 대부분 파트너의 현장에서 완성됩니다. 상품을 기획하고 운영하며, 현장에서 발생하는 문제를 해결하는 주체 역시 파트너입니다.

그래서 T&A실에게 파트너는 여행자와 함께 가장 중요한 또 하나의 고객입니다. 플랫폼의 성과는 파트너의 성과와 분리해서 이야기할 수 없고, 파트너의 운영 방식과 성장 속도는 곧 비즈니스의 방향성과 맞닿아 있습니다.

이 전제에서 한 가지 질문이 자연스럽게 이어졌습니다.

“우리는 파트너의 성장을 제대로 지원하고 있는가?”
그리고,
“이 방식은 앞으로도 계속 유효할 수 있을까?”

AI 챔피언 11번째 이야기는 이 질문에서 출발했습니다. 이 질문을 가지고 두 사람이 등장합니다.

박지수님은 제품을 만드는 사람입니다. 문제가 반복해서 발생할 때, 이를 기능과 구조로 풀 수 있는 방법을 고민합니다.

조은채님은 제품과 파트너를 운영하는 사람입니다. 같은 지표를 보더라도, 현장에서 당장 바꿀 수 있는 행동이 무엇인지에 집중합니다.

두 사람의 역할은 달랐지만, 문제 정의는 같았습니다. 파트너의 전환율은 어디에서 막히고 있는지,이탈은 왜 발생하고 있는지, 그리고 이 문제를 사람의 설명이 아니라 구조로 풀 수 있을지.

같은 문제를 함께 정의하다

초반에는 같은 방식으로 문제를 들여다봤습니다. 수십 명의 파트너를 대상으로 전환율과 이탈 구간을 분석한 리포트를 제공하며, 공통적인 패턴을 확인했습니다.

이 과정에서 분명해진 점이 있었습니다. 파트너들은 자신의 성과를 알고 싶어 했고, 숫자 자체보다 “그래서 무엇을 바꾸면 좋을지”를 더 궁금해했습니다.

전환율이라는 하나의 지표 안에는 상품 상세 문구, 문의 응대, 옵션 구성, 재고 관리 같은 여러 요인이 함께 얽혀 있었습니다.

여기까지는 두 사람의 문제 인식이 완전히 같았습니다. 차이는, 이 문제를 어떤 방식으로 풀 것인가에서 나타나기 시작했습니다.

운영자의 관점: 전환율을 ‘해석’해야 했던 이유

은채님은 운영자의 입장에서 전환율을 바라봤습니다. 전환율은 분명 중요한 지표였지만, 그 자체로는 충분하지 않았습니다.

운영 현장에서 실제로 바꿀 수 있는 것은 숫자가 아니라 상품 상세 문구, 문의 응대 방식, 옵션 구성 같은 운영의 디테일이었기 때문입니다. 전환율이 낮다는 결과만으로는, 파트너에게 무엇을 어떻게 바꿔보자고 말해야 할지 결정하기 어려웠습니다.

실제로 파트너와 대화를 나누다 보면 이런 질문이 더 많이 나왔습니다.

“그래서 제가 다음 주에 뭘 하면 될까요?”

파트너가 원하는 건 성과 요약이 아니라, 지금 당장 시도해볼 수 있는 다음 행동이었습니다. 하지만 이 답을 만들기 위해서는 전환율 하나만 보는 것이 아니라, 그 뒤에 있는 맥락을 함께 봐야 했습니다.

전환율이 떨어진 상품에는 어떤 공통점이 있는지, 문의는 언제 몰리는지, 응답 지연이 실제 전환에 어떤 영향을 주는지.

데이터는 이미 BigQuery에 충분히 쌓여 있었습니다. 문제는 데이터의 양이 아니라, 운영자가 매번 머릿속에서 하던 해석 과정이 구조로 남아 있지 않다는 점이었습니다.

은채님이 정의한 문제는 명확했습니다.

“전환율을 분석하는 게 아니라, 운영자가 판단하던 과정을 구조로 만들 수 없을까?”

수치를 행동으로 바꾸는 구조를 만들다

은채님이 만든 것은 단순한 자동화 리포트가 아니었습니다. 운영자의 판단 과정을 그대로 옮긴 자동 실행 파이프라인에 가까웠습니다.

먼저 BigQuery를 원천 데이터로 두고, 파트너 상품별 전환율을 기준으로 분석 구조를 설계했습니다. 전체 평균이 아니라, 전환율이 상대적으로 낮은 상품을 우선적으로 선별했습니다.

여기에 문의 데이터와 운영 맥락을 결합했습니다. 문의 응답 시간, 문의 유형처럼 실제 운영에서 바로 손댈 수 있는 지표들을 함께 묶었습니다. 전환율이라는 결과를 “어디에서 막히고 있는지”로 다시 해석하기 위한 설계였습니다.

이 데이터는 Looker Studio를 통해 파트너별로 확인할 수 있도록 유지했습니다. 이미 운영 현장에서 사용 중이던 도구를 유지한 이유는 분명했습니다. 새로운 도구를 도입하는 것보다, 익숙한 환경 위에서 바로 실행 가능한 구조를 만드는 게 더 중요했기 때문입니다.

여기에 n8n 노코드 워크플로우를 연결해 정해진 주기마다 분석이 자동으로 실행되도록 했습니다. 전환율 기준으로 개선이 필요한 상품을 추려내고, 그 결과를 AI가 요약해 “이번 주에 우선적으로 점검해볼 수 있는 항목” 형태로 정리했습니다.

이때 AI의 역할은 판단을 대신하는 것이 아니었습니다. 운영자가 매번 반복하던 ‘어디부터 보면 좋을지’를 빠르게 정리해주는 보조 역할이었습니다. AI가 생성한 결과는 항상 실행 가능한지, 운영 맥락에 맞는지 확인할 수 있도록 사람이 검토하는 지점을 구조적으로 남겨두었습니다.

이 구조의 결과물은 숫자 리포트가 아니라 실행 가이드였습니다.

파트너는 “전환율이 낮다”는 결과 대신, “상품 상세 문구에서 무엇을 보완해볼 수 있는지”, “문의 응대에서 어떤 부분을 먼저 점검해볼 수 있는지”를 함께 받게 됐습니다.

운영자의 관점에서 중요한 것은 모든 판단을 자동화하는 것이 아니라, 판단이 필요한 지점을 명확히 좁혀주는 것이었습니다.

은채님의 파이프라인은 파트너가 스스로 운영을 개선할 수 있도록 돕는 방향으로 설계됐고, 전환율을 ‘설명해야 하는 숫자’에서 ‘행동으로 이어지는 신호’로 바꾸는 역할을 했습니다.

제품을 만드는 사람의 관점: 구조적인 병목

같은 전환율 지표를 보면서, 지수님은 다른 지점을 보고 있었습니다.

운영을 잘해도 전환이 되지 않는 경우들이 있었습니다. 재고 관리가 되지 않던 시절, 고객이 예약을 하더라도 실제 재고가 없어 확정되지 않는 문제가 반복됐습니다.

이 문제를 해결하기 위해 T&A에는 재고 관리 기능이 추가됐습니다. 하지만 기능이 생겼다고 해서 자동으로 사용되는 것은 아니었습니다. 재고 관리 기능을 사용하지 않는 파트너의 상품은 여전히 확정률이 낮았고, 전환율 역시 구조적으로 개선되기 어려웠습니다.

지수님에게 중요한 질문은 이것이었습니다.

“어디에서 기능이 쓰이지 않고 있는가?”
그리고
“이 병목을 제품의 구조로 어떻게 드러낼 수 있는가?”

이 관점에서 대시보드는 단순한 성과 리포트가 아니었습니다. 제품의 기능이 실제로 사용되고 있는지를 확인하고, 확정률 개선으로 이어질 수 있는 지점을 찾기 위한 제품적 장치였습니다.

구조를 새로 설계한 이유

초기에는 Looker Studio로 빠르게 시도했습니다. BigQuery와 연동해 확정률, 매출, 예약 흐름을 시각화하고 파트너가 직접 확인할 수 있도록 했습니다.

하지만 파트너 수가 늘어나면서 한계는 분명해졌습니다. 파트너를 추가할 때마다 리포트와 시트를 복제해야 했고, 지표를 수정하면 모든 보고서를 함께 수정해야 했습니다. 무엇보다 파트너별 접근 제어와 확장성을 구조적으로 담기 어려웠습니다.

그래서 지수님은 구조를 다시 설계했습니다.

BigQuery를 단일 원천 데이터로 두고, Supabase를 통해 데이터베이스와 파트너별 인증·접근 제어를 처리했습니다. 파트너는 각자의 계정으로 로그인해 자신의 확정률과 매출, 예약 흐름을 직접 확인할 수 있게 됐습니다.

이 과정에서 AI 코딩 도구를 활용해 기본적인 화면과 흐름을 빠르게 구현했지만, 인증과 권한 분리, 에러 케이스 처리, 데이터 정합성 검증은 사람이 직접 책임졌습니다. 제품의 기능과 데이터가 직접 노출되는 영역이었기 때문입니다.

이 대시보드 구조는 현재 모든 파트너에게 공식적으로 제공되고 있지는 않습니다. 일부 파트너를 대상으로 한 베타 형태의 실험으로 운영되고 있으며, 파트너가 자신의 상태를 어떻게 해석하고 판단하는지를 함께 검증하고 있는 단계입니다.

기능을 빠르게 확장하기보다, 이 구조가 파트너에게 어떤 질문을 가능하게 만드는지부터 확인하는 데 초점을 두고 있습니다.

하나의 목표, 나뉜 역할

이 프로젝트는 두 개의 과제로 진행되었지만, “파트너의 성장을 구조로 지원할 수 있는가”라는 하나의 목표를 향해, 두 사람이 역할을 나눠 접근한 하나의 실험에 가까웠습니다.

지수님의 역할은 분명했습니다. 파트너가 자신의 상태를 직접 볼 수 있게 만드는 것이었습니다. 확정률, 매출, 예약 흐름처럼 지금까지 내부에서만 보던 지표를, 파트너가 로그인해서 스스로 확인할 수 있는 구조로 만드는 일이었습니다.

이 선택의 핵심은 ‘시각화’라기 보다는, 파트너가 “나는 지금 잘하고 있는가?”라는 질문에 누군가의 설명 없이도 답할 수 있는 상태를 만드는 것이었습니다.

은채님의 역할은 그 다음 단계였습니다. 보이는 수치를 어떻게 행동으로 연결할 것인가에 대한 고민이었습니다. 전환율이 낮은 상품을 어떻게 선별할지, 그 결과를 어떤 맥락과 함께 전달해야 파트너가 바로 움직일 수 있을지.

그래서 은채님이 만든 자동화 파이프라인의 결과물은 그냥 리포트가 아니라, “이번 주에 무엇을 해보면 좋을지”에 대한 실행 가이드였습니다.

이 실행 가이드 역시 현재는 일부 파트너를 대상으로 한 테스트 형태로 제공되고 있습니다. 모든 파트너에게 동일한 기준을 일괄 적용하기보다는, 실제 운영 맥락에서 도움이 되는지, 파트너가 스스로 행동을 바꾸는 데 연결되는지를 확인하는 단계에 가깝습니다.

하나는 보게 하는 구조, 다른 하나는 움직이게 하는 구조였습니다.

이제 다음 질문이 남아 있습니다.

전환 퍼널을 더 세분화하면 어떤 신호를 더 볼 수 있을지, 파트너의 자율성을 어디까지 구조로 확장할 수 있을지, 그리고 이 실험을 어디까지 제품의 언어로 옮길 수 있을지.

AI 챔피언 11번째 이야기는 완성된 해답이 아닙니다.

파트너를 비즈니스의 핵심으로 두는 조직이, 제품화 이전에 구조로 먼저 가능성을 증명해본 순간에 대한 기록입니다.