로브 (Lovv) 프로젝트 기획서

문서 버전: v0.18

문서 상태: 검토 중 (Review)

적용 범위: 로브 서비스 PoC 및 Production 기획

기준 문서: 요구사항 명세서 v2.4, 서비스 흐름 명세서 v0.3, 데이터 수집 계획서 v0.10, 데이터베이스 설계 명세서 v0.7, Agent 명세서 v0.15, 기술 명세서 v0.5, API 명세서 v0.4, B2C 수요 검증 v0.4, B2B 제휴 전략 v0.3, KICK 설계 v0.6, Aha Moment 설계 v0.25, 시장조사 v0.2, B2G 공익 협력 v0.9

보조 문서: supplemental/market_positioning.md, supplemental/feature_scope_summary.md, supplemental/business_model.md, supplemental/data_ops_scope.md, supplemental/kick_summary.md, supplemental/aha_moment_summary.md, supplemental/technical_direction_summary.md

하위 문서: sections/*.md

1. 프로젝트 개요

1.1 프로젝트명

로브 (Lovv)

Lovv는 Local(소도시), Vibe(분위기·감성), Voyage(여행)의 의미를 결합한 소도시 여행 추천 서비스다.

1.2 한 줄 정의

로브는 여행 시기와 국내 지역 조건부터 시작해 오버투어리즘을 피할 수 있는 소도시 대체 여행지를 발견하게 해주는 설명 가능한 여행 추천 에이전트다.

서울·오사카 말고, 지금은 이곳

지도에서 흐릿한 곳, 여행에선 가장 빛나는 곳

1.3 기획 배경

국내외 여행 수요는 회복되고 있지만, 인기 관광지로의 집중은 여행 만족도 저하와 지역 수용력 문제를 동시에 만든다. 여행자는 덜 붐비는 목적지를 원하지만, 방문객 수가 낮은 관광지와 그 주변 소도시 정보는 흩어져 있고 이동성, 계절성, 축제, 날씨, 주변 관광지 정보를 한 번에 비교하기 어렵다.

로브의 1차 검증 타깃은 한국 강원·경북 소도시 여행자다. PoC는 일본 데이터 수집 실패 리스크를 반영해 한국 강원·경북의 실제 수집·검증 가능한 데이터를 기준으로 추천 경험을 먼저 검증하고, 한국 전국 확장은 P2로 둔다. 일본 데이터 기반 추천과 일본 현지 데이터 연동은 데이터 수집 경로가 복구된 뒤 P5에서 재검토한다.

로브는 오버투어리즘 회피와 소도시 발견이라는 문제를 여행자 관점의 추천 경험으로 해결한다. 사용자가 여행 시기와 국내 지역 조건을 먼저 입력하면, 서비스는 그 조건을 기준으로 사용자의 자연어 취향과 Wikipedia 기반 월별 날씨 경향을 해석하고 추천 근거가 있는 소도시 여정과 주변 정보를 함께 제공한다.

일반 여행 일정 서비스가 사용자가 이미 선택한 대도시 안에서 동선과 일정을 최적화하는 데 강점이 있다면, 로브는 어디를 갈지부터 정하지 못한 사용자에게 국내 지역과 시기 조건에 맞는 대체 소도시를 발견하게 하는 목적지 탐색 엔진으로 차별화한다.

PoC 단계에서는 많은 지역을 얕게 나열하기보다 한국 강원·경북의 제한된 소도시를 깊게 다룬다. 축제, 기상, 교통, 체험, 외부 링크를 고밀도로 채워 Lovv다운 목적지 추천 경험을 먼저 검증한다.

1.4 시장 포지셔닝과 차별점

트리플이 인기 도시 안에서 여행 일정을 최적화하는 슈퍼앱이라면, Lovv는 여행 시기와 국내 지역 조건부터 시작해 오버투어리즘을 피할 수 있는 소도시 대체 여행지를 발견하게 해주는 설명 가능한 추천 에이전트다.

Lovv는 “어디를 가라”에서 끝나는 서비스가 아니라, 왜 이 소도시인지, 어떤 데이터에 근거했는지, 지금 실제로 갈 수 있는지를 함께 보여주는 목적지 탐색 엔진이다.

PoC 보완 방향은 다음과 같다.

• 소도시를 넓게 나열하기보다 제한된 후보 도시를 깊게 구성한다.
• 출처와 외부 링크를 UI에서 적극적으로 노출해 “LLM이 만든 이야기”가 아니라 데이터 기반 큐레이션임을 드러낸다.
• 첫 질문은 “어디로 갈까요?”보다 “언제, 어느 지역으로 떠나세요?”로 설계한다.
• 소도시 후보 리스트보다 소도시 1곳을 깊게 이해하는 상세 흐름을 우선한다.
• 지자체·공공 파트너가 볼 수 있는 추천 노출, 클릭, 관심도 지표를 장기 확장 방향으로 둔다.

2. 문제 정의

2.1 사용자 문제

2.2 시장·운영 문제

3. 프로젝트 목표

3.1 핵심 목표

• 방문객 수가 많은 혼잡 관광지 대신 대체 가능한 소도시 여행지를 추천한다.
• 추천 1건은 소도시 1곳을 최종 목적지로 삼고, 생성 일정은 그 도시 서비스 범위 안에서 완성한다.
• PoC는 한국 강원·경북 소도시를 기준으로 검증하고, 한국 전국 확장은 P2 범위로 둔다.
• 일본 데이터 기반 추천과 일본 현지 데이터 연동은 수집 경로가 복구된 뒤 P5에서 재검토한다.
• 여행 시기, 축제, Wikipedia 기반 월별 날씨 경향, 이동 경로, 주변 관광 정보를 결합한 여정을 제안한다.
• RAG 기반 검색과 멀티스텝 에이전트로 추천 근거와 안정성을 확보한다.
• 추천 이유, 출처, 검증 상태를 함께 보여주는 설명 가능한 추천 경험을 제공한다.
• KICK(유사 취향 공개 일정·1탭 복제)을 P2 설계 범위에 포함해 선택 불안을 줄이고 저장·외부 링크 전환 가능성을 검증한다.

3.2 성공 기준

4. 서비스 개념

4.1 핵심 서비스

로브는 사용자의 국내 지역, 여행 시기, 일정 길이, 취향을 바탕으로 덜 붐비는 하나의 소도시와 day-by-day 일정을 추천하는 서비스다. 사용자는 온보딩, 지도 마커, AI 챗봇 중 하나로 진입하고, 서비스는 조건에 맞는 목적지와 추천 이유를 함께 제시한다.

첫 질문은 “어디로 갈까요?”보다 “언제, 어느 국내 지역으로 떠나세요?”에 가깝다. 사용자가 도시를 이미 정했다고 가정하지 않고, 지역과 시기부터 고정한 뒤 자연어 취향과 월별 날씨 경향, 축제, 혼잡도 정보를 반영해 후보를 좁힌다.

추천 1건의 최종 목적지는 소도시 한 곳이다. 공항·역·관문 대도시는 교통 안내에만 사용하고 일정 목적지로 섞지 않는다. 적합한 소도시를 확정할 수 없으면 여러 도시를 억지로 조합하지 않고 추가 조건을 요청한다.

추천 결과는 다음 세 가지 경험을 제공해야 한다.

일정은 추천 소도시 안에서 메인 관광지, 서브 관광지, 식사 슬롯, 지도 이동 동선, 외부 탐색 링크를 조합해 구성한다. 숙소는 직접 추천하지 않고 검색 링크로 연결한다. 일정 수정, 장소 타입 균형, 데이터 검증 규칙은 7장 기능 구성과 요구사항 명세서에서 상세화한다.

KICK은 추천 축이 아니라 선택 불안을 낮추는 P2 전환 장치다. 사용자는 유사 취향 공개 일정을 참고하거나 1탭 복제를 검토할 수 있으며, 개인정보·공개 범위·버전 관리 기준은 KICK 상세 설계에서 별도로 확정한다.

4.2 사용자 흐름

5. 주요 사용자 및 이해관계자

초행 여행자는 무료 정보로도 충분할 수 있어 후순위로 본다. 공통 우선 세그먼트는 짧은 휴가의 직장인·커플, 테마형 여행자, 재방문 경험이 있는 FIT 사용자이며, 연령·성별보다 방문 횟수, 여행 기간, 교통 허용도, 테마, 예약 시점으로 구분한다.

장기적으로 로브는 지자체·공공 데이터·현지 운영자와 함께 만드는 소도시 추천 플랫폼을 지향한다. 지역 파트너는 데이터 제안과 검증뿐 아니라 소도시별 추천 노출 수, 클릭 수, 일정 생성·저장 같은 운영 지표를 확인하는 대시보드로 확장할 수 있다.

6. 프로젝트 범위

6.1 우선순위

6.2 PoC 범위

PoC는 P1 구현을 핵심 범위로 한다. P2와 P3는 설계 산출물을 우선 만들고, 일정 여유가 있을 경우 일부 구현한다. KICK은 추천 축 자체가 아니라 선택 전환 장치이므로 P2 설계 범위에 별도 포함한다. 일본 데이터 기반 추천과 일본 현지 데이터 연동은 현재 수집 실패 리스크를 반영해 P5 재검토 범위로 내린다.

PoC 데이터는 한국 강원·경북을 우선 수집 범위로 삼는다. 전국을 선제 구축하지 않고 3~5개 검증 후보 도시부터 깊게 구성한 뒤, 같은 공통 데이터 모델을 한국 전체 도시로 확장한다. 일본 데이터는 수집 경로와 검증 산출물이 확보될 때까지 P5로 보류한다.

6.3 Production 범위

Production 단계는 PoC 검증 결과를 바탕으로 P1을 더 구체화하고, P2 기능의 구현과 고도화를 진행하는 범위로 둔다.

• P1 구체화: 한국 강원·경북 데이터 기반 추천 흐름의 추천 품질, 일정 구성, 설명 가능성, 데이터 검증, 운영 안정성을 보강한다.
• P2 구현: 한국 전국 확장과 KICK(유사 취향 공개 일정·1탭 복제)을 구현 검토 대상에서 실제 구현 대상으로 올린다.
• P2 고도화: 공개 일정 운영, 개인정보·공개 범위, 저장·복제 전환, 재방문 개인화 흐름을 Production 수준으로 정교화한다.

6.4 제외 범위

다음 기능은 PoC 상세 요구기능에서 제외하고, 우선순위 및 단계별 추진 범위에만 기록한다.

• 별 관측 조건 기반 여행지 추천
• 치유·웰니스 여정 추천
• 예산 역산 추천
• 일본 데이터 기반 추천
• 일본 현지 데이터/API 연동
• B2C 과금·가격 모델
• B2G 영리화 시나리오

7. 기능 구성

7.1 사용자 기능

• 선택 로그인 및 온보딩
• 온보딩에서 테마와 기본 국내 지역 선호 입력
• 자연어 기반 여행 조건 입력
• 국내 지역, 여행 시기, 여행 일정 길이를 먼저 고정한 뒤 취향과 Wikipedia 기반 월별 날씨 경향을 반영하는 추천
• 추천 여정 카드와 메인·서브 관광지 확인
• 식사 슬롯에서 식당 선택
• 지도, 마커 간 이동 동선, 월별 날씨 경향, 외부 링크 확인
• 추천 결과 비교 및 후속 질의
• 자연어 또는 관광지 목록 직접 선택 기반 일정 수정
• 공개 일정 참고, 1탭 복제 검토, 챗봇 부분 조정
• 저장, 피드백, 재방문 개인화

7.2 추천 기능

7.3 운영·관리 기능

• 역할 기반 인증 및 인가
• 관광 운영자와 데이터 제공 기관의 데이터 제안
• 서비스 관리자의 데이터 검토, 승인, 반려, 수정 요청
• 데이터 제안·검토 이력 관리
• 공개 일정 운영, 신고, 익명화, 공개 범위 기준 검토
• 추천 정책, 공지사항, 데이터 갱신 상태 관리
• B2G 월간 큐레이션인 “이번 달 여행지” 운영 검토
• 소도시별 추천 노출 수, 클릭 수, 일정 생성·저장 등 파트너 리포트 확장 검토

7.4 비즈니스 모델

B2C·B2B·B2G는 서로 다른 수익화 단계가 아니라 수요 검증, 성과형 제휴, 공익 협력을 분리해 관리하는 사업 트랙이다. 가격 실험, 수익성 시뮬레이션, 파트너별 제안 전문은 상세 문서에 둔다.

B2C 과금·가격 모델과 B2G 영리화 시나리오는 대표 기획서 범위에서 제외한다. 비즈니스 모델 세부 내용은 보조 문서 supplemental/business_model.md에서 관리한다.

7.4.1 B2C: 수요·가치 검증 트랙

1차 타깃은 한국 강원·경북 소도시 여행자다. 서비스 가치는 정보 열람이 아니라 제한된 시간 안에서 실행 가능한 일정, 이동 실패 방지, 예약 가능한 다음 행동에 둔다.

핵심 KPI는 다음과 같다.

• 일정 저장률
• 공유·내보내기율
• 예약 파트너 클릭률
• 재방문율

7.4.2 B2B: 성과형 제휴 트랙

B2B는 취향·일정 맥락을 예약 가능한 상품 탐색으로 연결하고, 성과형 제휴 가능성을 검토하는 추천 중개 트랙이다.

수익 인식 기준은 총 예약액보다 승인 매출 기준으로 검토한다. 성과 구간, CPA, 추천 모듈·API, 화이트라벨, 공동브랜드 같은 장기 확장 후보는 보조 문서에서 관리한다.

7.4.3 B2G: 비과금 공익 협력 트랙

B2G는 지자체·공공기관과 검증된 관광 정보를 “이번 달 여행지” 월간 큐레이션으로 노출하는 비과금 협력 트랙이다. 공식 정보 링크와 제휴 링크는 분리하고, 관문도시 방문은 소도시 성과로 집계하지 않는다.

8. 데이터 및 외부 연동

8.1 필요 데이터

필요 데이터는 PoC 우선 데이터, 확장 후보 데이터, 재검토 데이터로 나눠 관리한다. PoC는 한국 강원·경북 소도시 추천과 일정 구성에 필요한 기본 정보, 축제·행사, 혼잡도·방문 통계, 월별 날씨 경향, 지도·장소, 출처·검증 정보, 일정 구성 후보를 우선한다.

PoC는 한국 강원·경북을 우선 수집 범위로 삼고, 현재 범위는 전국 선제 구축이 아니라 검증 후보 도시를 깊게 구성하기 위한 출발점이다. 한국 전국 확장은 P2로 두며, 일본 데이터는 수집 실패 리스크가 해소될 때까지 P5로 보류한다.

8.2 외부 연동

외부 연동은 서비스 기능별로 지도·장소, 이동 경로, 관광·통계, 예약 탐색, 공공 관광 데이터, P5 일본 재검토 연동으로 나눠 관리한다. 클라이언트에서 직접 호출하기 어려운 API는 딥링크 또는 백엔드 프록시로 대체한다.

연동 운영 원칙은 다음과 같다.

9. 기술 방향

9.1 추천 구조

Lovv의 기술 방향은 Explainable RAG 기반 소도시 추천 엔진이다. 추천 파이프라인은 다음 단계로 구성한다.

• 사용자 입력 수집
• 국내 지역·여행 시기·일정 길이·테마·진입점 조건 분류
• RAG 기반 후보 검색
• 후보 필터링 및 선정
• 메인 관광지·서브 관광지·식사 슬롯 기반 일정 구성
• 추천 이유와 외부 정보 보강
• 출처·갱신 시점·검증 상태 표시
• P2 KICK 흐름 또는 후속 질의응답
• 조건 변경 기반 재추천

9.2 시스템 원칙

• 추천 결과는 근거 데이터와 함께 제공한다.
• 추천은 단순 생성형 답변이 아니라 검색된 데이터와 검증 상태를 기반으로 구성한다.
• API Key는 개발·운영 담당자가 서버 환경 변수 또는 백엔드 프록시에서 관리한다.
• 클라이언트에서 직접 호출하기 어려운 API는 딥링크 또는 백엔드 프록시로 대체한다.
• 데이터 출처, 최신성, 검증 상태를 표시한다.
• 사용자가 후속 질문에서 조건을 바꾸면 동일한 추천 파이프라인을 재실행해 대체 소도시 또는 수정 일정을 제안한다.
• 초기 일정은 소도시 선정 근거 관광지만으로 채우지 않고, 선정 근거 관광지 기반 메인 관광지와 DynamoDB 재인출 기반 서브 관광지를 조합한다.
• 장소 타입이 과도하게 중복되지 않도록 균형을 두고, 식당은 별도 식사 슬롯에서 사용자가 선택하게 한다.
• 일정 수정에서는 메인 관광지는 테마 유지 조건에서 교체하고, 서브 관광지는 테마 고정 없이 사용자가 자유롭게 바꿀 수 있게 한다.
• 첫 화면은 가능한 한 사전계산·캐시를 활용하고, 이유 문구는 템플릿 또는 정형 근거를 우선 사용한다.
• 공개 일정 복제와 부분 수정은 P2 상세 설계에서 권한, 개인정보, 버전 관리 기준을 정리한다.
• PoC에서는 빠른 검증을 위해 핵심 흐름을 우선 구현한다.

9.3 데이터 파이프라인

데이터 파이프라인은 수집, 로컬 검증, 원본 보존, 정규화, 추천·검색 활용 계층으로 나눈다. S3 Raw Bucket, Lambda, DynamoDB 같은 구체 구현 방식은 데이터 수집 계획서, 데이터베이스 설계 명세서, 기술 명세서에서 관리한다.

• 자동 수집
• 로컬 검증 산출물 생성
• 원본 데이터 보존
• 배치 전처리
• 정규화 데이터 적재
• 추천·검색 계층에서 RAG와 운영 조회에 활용

10. 추진 일정

11. 기대 효과

로브를 통해 여행자는 유명 관광지 중심의 반복적인 여행 탐색에서 벗어나, 덜 붐비면서도 자신의 취향과 여행 시기에 맞는 소도시 대체 여행지를 더 쉽게 발견할 수 있다. 단순히 장소 목록을 보여주는 것이 아니라 추천 이유, Wikipedia 기반 월별 날씨 경향, 지도, 외부 링크, 출처·검증 상태를 함께 제공하므로 실제 여행 계획으로 이어지는 의사결정 부담도 줄어든다.

유사 취향 공개 일정과 1탭 복제는 낯선 소도시 선택의 불안을 낮추고, 일정 저장, 외부 링크 클릭, 재방문으로 이어지는 전환 경로를 만든다.

지역 관광 운영자는 상대적으로 노출이 부족했던 소도시 관광 자원과 축제, 지역 문화 체험을 여행자에게 소개할 수 있다. 이를 통해 특정 대도시나 유명 관광지에 집중된 수요를 주변 지역으로 분산시키고, 지역 관광 자원의 활용도를 높이는 기회를 확보할 수 있다.

B2B 파트너는 고의도 맥락형 트래픽과 증분 거래를 확보할 수 있고, 지자체·공공기관은 B2G “이번 달 여행지” 노출을 통해 비재정 성과를 측정할 수 있다.

서비스 운영자는 RAG 기반 추천 근거, 사용자 피드백, 공개 일정 복제 퍼널, 데이터 검증 상태를 바탕으로 추천 정책을 점진적으로 개선할 수 있다.

12. 리스크 및 대응

상세 리스크는 보조 문서 supplemental/business_model.md, supplemental/data_ops_scope.md, supplemental/kick_summary.md에서 관리한다.

운영 리스크 해석 원칙은 다음과 같다.

• 입국자 수는 고유 사용자 수가 아니므로 여행 횟수 흐름 지표로 해석한다.
• 관문도시 방문을 소도시 성과로 보지 않는다.
• 축제·교통 데이터는 갱신 시각과 출처를 함께 표시하고, Wikipedia 월별 날씨 경향 데이터는 추출 기준일과 출처 URL을 함께 표시한다.
• 외부 API 제약이 생기면 딥링크, 캐시, 백엔드 프록시를 조합한다.
• 지방 항공 노선 중단 가능성을 고려해 철도 대체 가능 국내 소도시를 우선한다.
• 일본 데이터는 로컬 검증 산출물과 출처 정합성 기준이 확보되기 전까지 추천 근거로 사용하지 않는다.

13. 후속 문서 및 분리 문서

대표 기획서와 같은 기준으로 관리하는 보조 Markdown은 docs/00_project_plan/supplemental/에서 관리한다.

대표 기획서의 최상위 # 장 단위 하위 Markdown은 docs/00_project_plan/sections/*.md에 둔다. 하위 Markdown은 장 단위 편집 원본이며, 대표 문서인 00_project_plan.md는 이 파일들을 순서대로 합쳐 만든 통합본이다.

앞으로 프로젝트 기획서 본문은 sections/*.md를 먼저 수정한 뒤 00_project_plan.md 통합본에 반영한다.

14. 변경 이력