숙소 후기를 읽지 않아도 되는 세계, AI로 만든 새로운 탐색 방식

마이리얼트립 숙소 서비스가 빠르게 확장하는 동안, 한 가지 문제는 끝까지 제자리였습니다. 숙소를 고를 때 가장 중요한 정보인 ‘후기’가 정작 아무도 제대로 쓰지 않고, 읽지도 않는 데이터가 되어가고 있던 겁니다.

연동사에서 들어오는 후기들은 매일 대량으로 쌓였습니다. 일본어, 영어, 중국어 등 여러 언어로 길게 적힌 리뷰들이었고, 이 텍스트는 화면에 그대로 렌더링될 뿐 내부 DB 어디에도 구조화되어 저장되지 않았습니다.

사용자 입장에서는 언어 장벽 때문에 읽기 어렵고, 한 리뷰가 너무 길어 ‘감’으로만 판단해야 했습니다. 마이리얼트립 입장에서는 데이터는 매일 쌓이는데, 검색·필터·추천 같은 기능으로 확장할 수 있는 여지가 전혀 없는 상태였습니다.

“이대로 두면 안 된다”는 문제의식에서, 숙박사업 Stay실 PM 송지호 님과 Product Engineer 전상민 님이 직접 이 정체를 깨 보기로 했습니다.

두 분은 먼저 “후기를 더 많이 읽게 만들자”가 아니라, “후기를 기능으로 쓸 수 있는 구조로 바꾸자”는 새로운 정의에서 출발했습니다.

읽히지 않는 후기 데이터, 문제는 ‘언어’가 아니라 ‘구조’였다

숙박 연동사에서 제공하는 후기 데이터의 양 자체는 충분했습니다. 문제는 그 데이터가 제품 안에서 어떤 ‘형태’로 존재하느냐였습니다.

• 대부분 현지 언어로 작성된 장문 리뷰
• 단순 텍스트 렌더링으로만 소비
• 내부 DB에 구조화되어 저장되지 않아, 검색·필터·추천 같은 고도화 기능은 사실상 불가능

결국 이 데이터는 “많이 있지만, 쓸 수는 없는 정보”였습니다. 지호 님이 처음 명확히 짚은 포인트는 이것이었습니다.

“후기를 읽히게 만드는 것보다, 쓰일 수 있게 만들어야 했어요.”

문제의 본질은 후기가 외국어인지, 길고 장황한지보다 제품 입장에서 이 정보를 구조화해 기능으로 쓸 수 있는가 여부에 가까웠습니다.

그래서 두 분은 “후기 텍스트를 그대로 보여주는 UI”에서, “후기를 요약·번역·구조화해서 저장하는 시스템”으로 관점을 완전히 전환하기 시작했습니다.

모든 후기를 요약하지 않고, ‘On-Demand 요약’이라는 결정을 내리기까지

숙소 상품은 100만 개가 넘습니다.

LLM 기반 후기 요약은 1건을 생성할 때마다 비용이 발생하기 때문에, 모든 숙소를 한 번에 요약하는 방식은 현실적으로 불가능했습니다.

두 분은 먼저 “그럼 어느 시점에, 무엇을 요약할 것인가?”를 비용 구조 관점에서 다시 설계했습니다. 그 결과 나온 핵심 정책은 다음과 같습니다.

1. 실제 사용자가 조회한 숙소만 요약한다 — 100만 개 전체가 아니라, 실제 상세 페이지에 진입한 숙소에 대해서만 요약을 수행.
2. 요약은 페이지 진입 시 비동기로 요청한다 — 상세 진입 시 Kafka로 요약 요청 메시지를 발행하고, 별도 Consumer가 AI에 요약을 요청하고, 사용자가 느끼는 로딩 시간에 영향을 최소화.
3. 생성된 요약은 저장하고 재사용한다 — 한 번 요약된 숙소 정보를 빠르게 노출.

이 구조 덕분에, 이론적으로는 100만 개 숙소 전체를 다루되, 실제로는 고객이 탐색한 숙소(현재 5.2만 개+)만 요약하면 되는 구조를 만들었습니다.

“데이터는 전 숙소를 대상으로 열어 두되, 비용은 탐색이 실제로 발생한 범위 안에서만 쓰이도록 설계했습니다.”

UI는 심플하게, 사용자에게는 키워드 3개면 충분했다

AI가 아무리 잘 요약해도, 그 결과를 어떻게 보여주느냐에 따라 기능의 가치가 갈립니다.

지호 님은 숙소 상세 페이지의 전체 구조를 다시 훑어본 뒤, 결국 “후기를 읽는 경험이 아니라, 후기를 파악하는 경험”을 목표로 UI를 설계했습니다.

핵심 구조는 다음과 같습니다.

• 긍정 키워드 3개 (Pros Keyword)
• 부정 키워드 3개 (Cons Keyword)
• 각각을 설명하는 한 줄 요약(각 100~200자)
• 최근 1년 이내 후기 + 10개 이상 쌓인 숙소에만 요약 노출

이걸 통해, 사용자는 다음과 같은 흐름으로 숙소를 이해할 수 있습니다.

1. 먼저 키워드 3개만 보고 전체 분위기를 빠르게 파악하고,
2. 필요할 때만 한 줄 요약을 펼쳐서 읽고,
3. 더 궁금할 때 원본 리뷰로 내려가 세부 내용을 확인하는 구조.

“장문 리뷰를 ‘끝까지 읽게 만드는 것’이 아니라, 장문을 읽지 않고도 핵심을 보게 하는 것이 목표였던 셈입니다.”

실제 운영에서 드러난 문제: 부정 후기 클릭률이 긍정보다 두 배

후기요약은 기본적으로 약 100자 분량의 미리보기 형태로 보여주고, 사용자가 “더보기”를 눌러 전체 내용을 펼쳐보는 UX로 설계했습니다. “더보기” 클릭 데이터를 균일하게 수집하기 위해 pros/cons 요약문이 항상 100자 이상이 되도록 프롬프트에 prefix 문구를 추가해 길이를 보정하는 방식도 적용했습니다.

기능이 배포되고 며칠 지나지 않아, 데이터에서 뚜렷한 패턴이 나타났습니다. 부정 요약의 ‘더보기’ 클릭률이 긍정보다 2배 이상 높게 나타난 것입니다. 사용자가 숙소의 장점보다 단점을 먼저 확인하려는 경향이 명확하게 드러난 결과였습니다.

하지만 이 데이터가 보여주는 패턴은 곧 새로운 고민을 만들었습니다.

부정 정보만 과도하게 주목받으면, 숙소의 전체 인상이 실제보다 부정적으로 왜곡될 수 있었기 때문입니다. 이를 완화하기 위해 두 분은 초기 정책으로 동일한 부정 의견이 3회 이상 반복될 때만 부정 키워드를 생성한다는 기준을 적용했습니다. 단발성 불만을 그대로 요약에 반영하는 것이 아니라, 여러 리뷰에서 반복적으로 확인된 이슈만 사용자에게 노출하려는 목적이었습니다.

그러나 이 규칙을 적용하자 부정 요약 생성 비율이 긍정 대비 약 54% 수준으로 급감하는 현상이 나타났습니다. 즉, 실제로 존재하는 부정 피드백이 지나치게 걸러지면서, 오히려 숙소의 문제를 정확히 전달하지 못하는 상황이 만들어진 것입니다. 결국 팀 내부에서는 자연스럽게 이런 질문이 다시 제기됐습니다.

“상품이 실제로 안 좋은데, 우리가 그 정보를 숨길 이유가 있을까?” “이 기능이 부정 후기를 ‘관리’하는 도구가 되어서는 안 된다.”

이 논의 끝에 프롬프트 단계에서 ‘3회 이상’ 조건을 제거하고, 명확한 부정 피드백이 하나라도 존재하면 cons를 생성하되, 추론하거나 과장하지 않는다는 원칙으로 정책을 재정립했습니다.

현재는 실명 노출이나 사실과 다른 내용처럼 명백한 문제가 있는 경우에만 운영자가 비노출 처리할 수 있는 최소한의 장치를 둔 상태입니다. 사용자 경험·브랜드 신뢰·전환율 사이에서 조정하며 도달한 결론입니다.

프롬프트 엔지니어링이 프로젝트의 절반을 차지했다

두 분 모두 처음에는 이 작업을 “리뷰를 잘 요약하는 프롬프트 한 번 쓰면 되겠지” 정도로 생각했다고 합니다. 실제로는 프로젝트의 절반 이상이 프롬프트/후처리 설계에 들어갔습니다.

운영 과정에서 반복해서 등장한 문제들은 다음과 같았습니다.

• “한국어로 출력하세요”라고 명시했는데, 일본어/영어 문장이 섞여 나오는 경우
• JSON key/value에서 큰따옴표가 빠져 파싱 실패
• 실명, 전화번호 등 민감 정보가 그대로 요약에 등장
• 키워드 개수가 3개를 넘어가거나, 형식이 들쭉날쭉
• prefix 문구(“여러 리뷰 중 긍정 내용 중심 요약…”)가 문장 중간에 끼어 들어가는 현상

이 문제들을 해결하기 위해, 프롬프트와 후처리 로직을 동시에 다듬어 갔습니다.

대표적인 장치는 다음과 같습니다.

• Strict Korean Rule — pros/cons는 완전한 한국어 문장만 허용, 외국어 문장 등장 시 결과를 버리고 재요약
• 개인정보 제거 규칙 — 이름, 이메일, 전화번호, 예약번호 등은 모두 제거하거나 개인정보를 식별할 수 없도록 치환
• JSON 형식 강제 — 하나의 JSON 객체만 허용, key/value는 모두 더블쿼트, null은 literal로만 허용
• 키워드·길이 제약 — 키워드는 최대 3개, pros/cons는 각 100~200자
• 오류 시 자동 재요약 — 파싱 실패나 규칙 위반 시, 동일 데이터로 재요약을 요청 로직 추가

결과적으로, “프롬프트만 잘 쓰면 된다”는 통념 대신, “운영 환경에서 AI를 쓰려면, 프롬프트·후처리·모니터링까지 하나의 시스템으로 설계해야 한다”는 감각을 두 사람이 몸으로 익히게 된 프로젝트였습니다.

보이는 UI 뒤에 숨은 시스템 설계:

겉에서 보면 이 기능은 숙소 상세 페이지의 작은 요약 박스에 불과합니다. 하지만 트래픽이 큰 서비스에서 이 “작은 박스”를 안정적으로 돌리기 위해서는 제법 본격적인 시스템 구성이 필요했습니다.

최종 아키텍처 흐름은 이렇습니다.

• 사용자가 숙소 상세 페이지에 진입하면 Review Summary Producer가 요약 요청 메시지를 발행합니다.
• AI Review Consumer는 이 메시지를 소비한 뒤 최근 1개월 내 생성된 요약이 있는지 확인하고, 없을 때에만 요약을 요청합니다.
• Internal Review Service는 카테고리별 프롬프트를 통합 관리하고, 마이리얼트립 자사 후기와 숙소 연동사 후기를 함께 요약해 하나의 결과로 반환합니다.

생성된 JSON 결과는 pros/cons 키워드, 한 줄 요약, reviewCount 등의 형태로 파싱되어 통합 숙소 테이블과 캐시에 함께 적재됩니다. 이후 동일 숙소에 다시 접근하면, 프론트는 이 저장된 데이터를 바로 불러와 사용자에게 즉시 키워드와 요약문을 보여주는 거죠.

지금까지의 성과: ‘UI 하나’ 이상의 변화

운영을 시작한 뒤 몇 달이 지나, 데이터는 다음과 같이 쌓였습니다.

• 총 요약 적재량: 5.2만 건 이상
• 일 평균 후기요약 클릭수: 2,200+
• 후기요약 영역 평균 클릭률(CTR): 약 15%

이 숫자들은 단순히 “새로운 UI 하나에 상호작용이 생겼다”를 넘어서, 사용자가 숙소를 탐색하는 방식 자체가 바뀌기 시작했다는 신호로 볼 수 있습니다.

이제 다수의 사용자는 원본 리뷰를 처음부터 끝까지 읽기보다, AI가 정리한 요약을 “탐색의 출발점”으로 사용하고, 이후 필요할 때만 원본 리뷰로 내려가는 패턴을 보이고 있습니다.

구매 전환에 대한 직접적인 영향은 아직 따로 측정하지 않고 있습니다. 지금 단계에서 이 기능은 “숙소 탐색의 피로를 줄여주는 편의 기능”에 가깝고, 전환 임팩트는 이후 고도화를 통해 만들어 가야 한다는 판단입니다.

AI가 만들어낸 것은 요약이 아니라 ‘새로운 탐색 경험’

요약 데이터가 충분히 쌓이자, 두 분은 이 정보를 단순한 UI 요소가 아니라 앞으로의 숙소 탐색 방식을 새로 설계할 수 있는 기반으로 보기 시작했습니다. 후기 텍스트가 키워드와 한 줄 요약으로 구조화되면서, 기존 장문 중심 탐색에서는 상상하기 어려웠던 여러 방향이 열리기 시작했죠.

예를 들어 “청결 좋은 도쿄 호텔”처럼 자연어 기반 검색을 시도해보고, 요약된 키워드와 매핑하는 탐색 방식을 실험해볼 수 있습니다. 특정 키워드를 누르면 그 내용이 담긴 원본 리뷰만 모아 보여주는 형태도 검토해볼 수 있고, 동일 지역 숙소들을 키워드 기준으로 비교해 설명을 자동으로 생성하는 지표 역시 가능성이 열려 있습니다. 사용자가 자주 클릭한 키워드를 기반으로, 후기 특성이 비슷한 숙소를 추천하는 개인화 방향도 상상해볼 수 있죠.

이처럼 후기 요약은 단순히 ‘읽기 편한 박스’를 만드는 수준을 넘어서, 탐색·비교·추천을 재설계할 수 있는 기반 데이터로 확장될 여지가 충분합니다.

숙소 후기를 읽지 않아도 되는 세계.

이 프로젝트는 그 세계를 단숨에 만든 것이 아니라, 읽히지 않던 후기를 “쓰일 수 있는 데이터”로 재정의하고, 그 위에서 새로운 탐색 경험을 설계해 나가는 과정이었습니다.

이제 마이리얼트립의 숙소 후기는 사용자가 더 빠르고 정확하게 숙소를 선택하도록 돕는 새로운 형태의 탐색 경험으로 진화하고 있습니다.

이 여정에 대해 추가로 궁금한 점이 있으시면, 마이리얼트립 Stay실의 송지호 님께 직접 연락 주세요!