로브 (Lovv) 서비스 흐름 명세서
문서 버전: v0.3
문서 상태: 검토 중 (Review)
기준 문서: 요구사항 명세서
[PRD 반영 v0.1 — 대화형 빌더] 일정 생성 흐름이 자동 결과 화면에서 사용자 주도 HITL 빌더로 바뀐다:
가장 적합한 장소 1곳을 시작으로 반경 내 후보(관광지 DB + 식당·카페 지도 API)를 제시 → 사용자 선택 → 다음 장소 반경 제시를 반복(interrupt/resume).
후보 선택은 메인 대화창과 격리된 서브 윈도우(사이드바) 에서 진행한다. 상세:
../.98_ prd/ interactive_ builder_ prd.md
1. 문서 개요
1.1 목적
본 문서는 로브 서비스의 사용자 진입, 인증, 온보딩, 목적지 탐색, 챗봇 추천, 일정 생성, 저장·피드백·외부 연동 흐름을 화면과 상태 전이 관점에서 정의한다. 요구사항 명세서의 기능 요구사항을 사용자 행동, 시스템 처리, 데이터 상태 단위로 연결해 UX 설계와 프론트엔드·백엔드 구현의 기준으로 사용한다.
1.2 적용 범위
- 앱 로드, 세션 검증, 로그인 및 사용자 상태 로드
- 신규 사용자 온보딩과 재방문 사용자 선호 로드
- 국가·시기·테마 기반 목적지 탐색
- RAG 기반 소도시 후보 비교 및 소도시 확정
- 대화형 AI 일정 생성과 실시간 피드백 반영
- 추천 이유, 출처, 검증 상태가 포함된 결과 확인
- 일정 저장, 좋아요/싫어요 피드백, 마이페이지 조회
- 외부 지도·숙소·맛집 플랫폼 딥링크 이동
- 관리자·지자체 데이터 제안, 검증, 벡터 DB 반영 흐름
2. 사용자 유형과 진입점
| 사용자 | 진입점 | 핵심 목적 |
|---|---|---|
| 신규 자유여행자 | 로그인 또는 비로그인 진입 → 온보딩 → 목적지 탐색 | 선호 테마를 설정하고 첫 추천을 받는다 |
| 재방문 자유여행자 | 세션 검증 → 메인 대시보드 또는 챗봇 | 저장 선호와 피드백을 반영한 추천을 받는다 |
| 관광 운영자 | 운영 화면 | 담당 지역 데이터와 제안 상태를 확인하고 신규 로컬 콘텐츠를 제안한다 |
| 서비스 관리자 | 관리자 화면 | 데이터 제안 승인, 추천 정책, 검증 뱃지, 공지사항을 관리한다 |
3. User Flow
| 단계 | 화면 / 상태 | 사용자 행동 | 시스템 반응 | 사용자에게 보이는 결과 | 완료 조건 |
|---|---|---|---|---|---|
| 1 | 진입 및 인증 | 사용자가 Lovv에 접속 후 소셜/자체 로그인을 진행한다 | 백엔드가 OAuth 또는 자체 로그인 인증 후 Access Token과 Refresh Token을 발급하고 사용자 상태, 기존 취향, 저장 일정을 로드한다 | 로그인 세션이 유지된 맞춤형 메인 대시보드가 노출된다 | 로그인 완료 및 메인 화면 진입 |
| 2 | 목적지 탐색 1단계 | "언제, 어느 나라로 떠나세요?" 질문에 국가와 시기를 입력한다 | 입력된 시기의 공공 관광 데이터, 혼잡도, 계절성 데이터를 기준으로 후보 필터링 조건을 준비한다 | 국가/시기 선택 완료 상태가 UI에 반영된다 | 국가 및 시기 확정 |
| 3 | 테마 설정 2단계 | 자연어 또는 테마 태그 칩으로 취향을 입력한다 | RAG 엔진이 벡터 DB에서 조건에 맞는 소도시 후보를 검색하고 스코어링한다 | 대도시와 유사하지만 덜 붐비는 소도시 후보군 비교 카드가 노출된다 | 추천 소도시 리스트 확인 |
| 4 | 소도시 확정 및 챗봇 | 추천된 소도시 중 1곳을 선택하고 AI 일정 짜기에 진입한다 | 대화형 워크스페이스가 열리고 선택 소도시의 날씨 경향, 축제 정보, 검증 상태를 초기 컨텍스트에 주입한다 | "선택한 도시의 현지 축제 정보를 일정에 포함할까요?" 안내 메시지가 노출된다 | 대화 시작 상태 진입 |
| 5 | 동적 일정 생성 3단계 | 사용자가 기간, 이동 성향, 축제 포함 여부 등 세부 요구사항을 입력한다 | 멀티스텝 Agent가 외부 API와 내부 데이터를 조회하고 동선을 최적화한 뒤 Structured Output 형태로 일정 초안을 생성한다 | 추천 이유와 데이터 출처 뱃지가 포함된 시간대별 타임라인 UI가 생성된다 | 초안 일정 및 근거 확인 |
| 6 | 실시간 피드백 및 조정 | "이 날은 덜 걷게 해줘", "카페 추가해줘" 등 추가 자연어를 입력한다 | Agent 파이프라인이 기존 PlanDraft와 신규 요구사항을 재평가하고 특정 일정 블록과 대체 일정을 갱신한다 | 실시간 갱신된 타임라인과 실내 중심 대체 일정 토글을 확인한다 | 만족하는 일정 확정 |
| 7 | 일정 저장 및 연동 | 일정을 마이페이지에 저장하거나 맛집/숙소 상세 정보를 클릭한다 | 서버가 완성된 일정과 저장 범위 내 선호·피드백 데이터를 저장하고 외부 플랫폼 딥링크를 생성한다 | 내 저장 목록에 일정이 반영되고 현지 신뢰 플랫폼으로 이동할 수 있다 | 외부 예약 이동 또는 마이페이지 저장 완료 |
4. Service Flow
API 경로는 docs/의 Base URL /을 전제로 표기한다.
| 단계 | Trigger | Frontend 처리 | 상태 / 데이터 관리 | AI & Infra 비즈니스 로직 | 결과 |
|---|---|---|---|---|---|
| 1 | 앱 로드 및 세션 검증 | 브라우저 쿠키의 Refresh Token 유무를 확인하고 현재 사용자 조회를 요청한다 | GET /, Cookie: Refresh Token, Memory: Access Token | 백엔드가 토큰 유효성을 검증하고 사용자 ID와 역할을 식별한다. 만료 시 재발급 또는 로그인 전환을 처리한다 | 유효하면 메인 화면으로 진입하고, 토큰이 없거나 만료되면 로그인 화면으로 이동한다 |
| 2 | 소셜/자체 로그인 완료 | OAuth 인가 코드 또는 로그인 폼 데이터를 백엔드로 전송한다 | POST /, User, Preference, SavedItinerary | 자체 로그인은 비밀번호 해시를 검증하고, 소셜 로그인은 제공자 API로 사용자를 식별한 뒤 신규/기존 회원을 매핑한다 | JWT 발급, 보안 쿠키 설정, 개인화 메인 대시보드 출력 준비가 완료된다 |
| 3 | 목적지 및 테마 전송 | 사용자가 입력한 국가, 시기, 자연어 취향, 테마 칩을 추천 요청 상태로 구성한다 | GET /, POST /, State: recommendationSession | 자연어 쿼리를 조건 객체로 구조화하고, 벡터 DB와 목적지 DB에서 소도시 후보를 검색한다. 혼잡도와 계절성 필터를 적용한다 | 메이저 대도시를 대체할 수 있는 소도시 후보군 또는 1차 추천 결과가 반환된다 |
| 4 | 소도시 선택 및 대화 시작 | 특정 소도시를 확정한 뒤 AI 일정 생성 챗봇으로 진입한다 | State: selectedDestination, State: chatSession, PlanDraft | 선택 소도시의 축제 정보, 월별 기상 경향, 온보딩 선호, 피드백 이력을 초기 프롬프트와 Agent 상태에 주입한다 | 초기 어시스턴트 메시지와 소도시 맞춤 상태 칩 UI가 렌더링된다 |
| 5 | 동적 AI 일정 생성 요청 | 사용자가 기간, 이동 성향, 동행, 축제 포함 여부를 메시지로 전송한다 | POST /, PlanDraft, RecommendationResult | Intent Agent, Supervisor Router, Retriever, Festival Verifier, Ranker, Itinerary Writer, Output Validator 순으로 실행한다 | 데이터 출처와 검증 상태 뱃지가 포함된 오전/오후/저녁 타임라인과 챗봇 응답을 출력한다 |
| 6 | 실시간 일정 피드백 | 사용자가 카페 추가, 동선 최적화, 덜 걷기 등 수정 요구사항을 입력한다 | State: PlanDraft, POST / | 기존 PlanDraft와 신규 요구사항을 재투입하고 특정 타임라인 블록만 수정한다. 월별 기상 경향에 따라 실내 중심 대체 일정을 결합한다 | 수정된 타임라인 레이아웃과 대체 일정 토글 UI가 반영된다 |
| 7 | 최종 일정 저장 및 외부 연동 | 사용자가 마이페이지 저장, 지도 열기, 숙소/맛집 상세 링크를 클릭한다 | POST /, POST /, GET /, GET / | 저장 일정은 사용자 ID와 매핑하고 피드백은 향후 랭킹 가중치 업데이트 데이터로 축적한다. 숙소는 직접 추천하지 않고 검색 딥링크만 생성한다 | 마이페이지 내 일정이 보존되고 신뢰 가능한 현지 플랫폼으로 외부 이동한다 |
| 8 | 지자체 데이터 검증 및 업데이트 | 지자체나 로컬 파트너가 축제/체험 정보 업데이트를 제안한다 | POST /, PATCH / | 관리자 승인 후 RDB와 벡터 DB에 콘텐츠를 반영하고 출처·검증 상태를 갱신한다 | 일반 사용자 추천 풀에 최신 로컬 데이터와 검증 완료 뱃지가 반영된다 |
5. 온보딩 흐름
5.1 조건
- 온보딩은 신규 사용자에게 필수로 제공한다.
- PoC에서는 브라우저 로컬 스토리지에 완료 여부와 선호 프로필을 저장한다.
- Production에서는 로그인 사용자 계정에 선호 프로필을 저장하고
GET /,me/ preferences PUT /로 조회·수정한다.me/ preferences - 대화 로그 전문은 장기 저장하지 않으며, 추천에 필요한 구조화 선호와 저장 일정, 피드백만 저장 대상으로 삼는다.
5.2 질문 구조
| 단계 | 질문 | 선택 결과 | 저장 상태 |
|---|---|---|---|
| 1 | 어떤 스타일의 여행지를 선호하나요? | 한국 또는 일본 대도시 스타일 선택 | selectedCityStyle |
| 2 | 어떤 분위기가 더 끌리나요? | 기본 테마 또는 확장 테마 칩 선택 | mappedThemes |
| 3 | 선택 확인 | 대도시 스타일을 기본 테마로 매핑 | onboardingProfile |
| 4 | 완료 | 선호 테마 프로필 저장 | PoC 로컬 스토리지 또는 사용자 프로필 |
5.3 대도시 스타일 매핑
| 기본 테마 | 한국 예시 | 일본 예시 |
|---|---|---|
| 온천·휴양 | 아산/온양 | 벳푸 |
| 바다·해안 | 부산 | 오키나와 |
| 역사·전통 | 경주 | 교토 |
| 미식·노포 | 전주 | 오사카 |
| 자연·트레킹 | 제주 | 닛코 |
| 예술·감성 | 강릉 | 가나자와 |
6. 목적지 탐색 흐름
6.1 메인 탐색 상태
메인 화면은 국가, 여행 시기, 테마, 자연어 취향을 조합해 추천 후보를 좁히는 탐색 워크스페이스다. 지도 마커와 후보 비교 카드는 같은 조건 상태를 공유한다.
| UI 요소 | 동작 | 상태 |
|---|---|---|
| 국가 필터 | 한국, 일본, 전체 중 선택 | country |
| 시기 필터 | 월 또는 계절 선택 | travelMonth 또는 season |
| 테마 필터 | 기본 테마와 확장 테마 선택 | themes |
| 자연어 입력 | "드라마 촬영지 중심의 조용한 곳" 같은 조건 입력 | naturalLanguageQuery |
| 소도시 후보 카드 | 추천 이유, 혼잡도, 계절성, 출처 뱃지 비교 | candidateDestinations |
| 소도시 마커 | 클릭 시 목적지 후보로 고정 | selectedDestination |
6.2 후보 비교 후 흐름
| 단계 | 사용자 행동 | 시스템 처리 | 다음 상태 |
|---|---|---|---|
| 1 | 국가와 시기 입력 | 목적지 DB와 월별 기상 경향 기준으로 1차 필터링 | 테마 설정 |
| 2 | 자연어 또는 테마 칩 입력 | RAG 검색과 스코어링으로 후보군 생성 | 후보 비교 |
| 3 | 후보 카드 또는 지도 마커 클릭 | 소도시명, 대표 태그, 추천 월, 검증 상태 표시 | 소도시 확정 |
| 4 | AI 일정 짜기 클릭 | 챗봇 세션과 PlanDraft 초기 상태 생성 | 대화형 일정 생성 |
7. 챗봇 및 AI 일정 생성 흐름
7.1 자연어 입력 예시
| 입력 예시 | 구조화 조건 |
|---|---|
| "6월에 비 덜 오는 일본 소도시 추천해줘" | 국가=일본, 월=6월, 진입점=월별 기상 경향 |
| "혼자 조용히 쉬는 바다 여행 가고 싶어" | 동행=혼자, 테마=바다·해안/휴양 |
| "가을에 축제 있는 한국 소도시 알려줘" | 국가=한국, 시기=가을, 축제 포함 후보 |
| "드라마 촬영지 중심인데 너무 붐비지 않았으면 좋겠어" | 테마=미디어 성지/조용함, 혼잡 회피 선호 |
7.2 추천 생성 전 필수 확인
챗봇은 추천 생성 직전 아래 항목을 확인한다.
| 확인 항목 | 기본 처리 |
|---|---|
| 국가 | 명시되지 않으면 한국/일본 중 선택 질문 |
| 여행 시기 | 월 또는 계절 입력 요청 |
| 일정 유형 | 명시되지 않으면 당일치기~4박5일 선택 질문 |
| 축제·행사 포함 여부 | 예/아니오 선택 질문 |
| 이동 성향 | 명시되지 않으면 보통 이동량을 기본값으로 사용 |
7.3 Agent 처리 단계
| 단계 | 처리 | 사용자에게 보이는 결과 |
|---|---|---|
| 1 | Intent Agent가 멀티턴 맥락을 정리하고 필요한 조건만 추출한다 | 누락 조건이 있으면 추가 질문 |
| 2 | Intent Agent가 국가, 월, 테마, 일정 유형, 축제 포함 여부를 구조화한다 | 입력 조건 칩 갱신 |
| 3 | Supervisor Router가 검색·후보 선정·일정 생성 순서를 제어한다 | 생성 진행 상태 표시 |
| 4 | Retriever와 Festival Verifier가 목적지, 축제, 월별 기상 경향을 조회·검증한다 | 출처 및 검증 상태 뱃지 |
| 5 | Ranker가 개인화 이력과 혼잡도, 계절성을 반영해 후보를 정렬한다 | 소도시 후보 비교 또는 최종 목적지 |
| 6 | Itinerary Writer가 시간대별 일정과 추천 이유를 함께 생성한다 | 오전/오후/저녁 타임라인, 추천 이유, 동선 설명 |
| 7 | Output Validator가 조건 충족, 환각, 축제 날짜, 단일 목적지 여부를 검증한다 | 검증된 추천 결과 또는 폴백 안내 |
8. 추천 결과 흐름
8.1 결과 카드 구성
| 영역 | 표시 내용 |
|---|---|
| 추천 대상 | 소도시명, 국가, 지역, 대표 이미지 |
| 추천 이유 | 사용자 조건, 계절 적합도, 혼잡도, 월별 기상 경향 중 2개 이상 |
| 검증 상태 | 출처, 최신성, 축제 날짜 검증 상태, 데이터 결측 안내 |
| 일정 | 일정 유형에 맞춘 일별·시간대별 방문 순서 |
| 축제·행사 | 사용자가 포함을 선택한 경우 해당 월 행사 정보. 날짜 미확정 축제는 확정 일정으로 배치하지 않는다 |
| 외부 링크 | 지도, 공식 관광 정보, 숙소 검색 링크, 현지 플랫폼 링크 |
| 피드백 | 좋아요, 싫어요, 저장, 추천 다시 받기 |
8.2 대체 일정 토글
월별 기상 경향상 우천, 폭설, 장마, 태풍 가능성이 높은 목적지는 "기상 악화 시 대체 일정 보기" 토글을 제공한다. 토글을 활성화하면 동일 목적지 안에서 실내 중심 일정으로 전환한다. WeatherAPI 현재 날씨는 상세 화면 표시용으로만 사용하고 추천 스코어링 기준으로 사용하지 않는다.
8.3 실시간 피드백 반영
| 피드백 유형 | 처리 |
|---|---|
| 이동 부담 감소 | 동선 거리와 이동 횟수를 줄이고 일정 블록을 재배치한다 |
| 카페/맛집 추가 | 장소 후보를 추가하되 출처와 외부 탐색 링크를 함께 표시한다 |
| 축제 제외 | 축제 블록을 제거하고 같은 시간대 대체 방문지를 제안한다 |
| 우천 대비 | 실내 중심 대체 일정 토글을 기본 활성화한다 |
| 추천 다시 받기 | 현재 조건을 유지하되 직전 추천 목적지는 제외하거나 감점한다 |
9. 저장·피드백·마이페이지 흐름
| 기능 | PoC | Production |
|---|---|---|
| 일정 저장 | 로컬 스토리지 | POST /로 로그인 계정 서버 저장 |
| 온보딩 선호 | 로컬 스토리지 | PUT /로 사용자 프로필 저장 |
| 좋아요/싫어요 | 로컬 스토리지 | POST /으로 추천 피드백 테이블 저장 |
| 마이페이지 | 기본 조회 | 저장 일정 상세, 선호 재설정, 피드백 이력, 삭제 기능 |
| 대화 로그 | 전문 저장 금지 | 전문 저장 금지. 구조화된 선호와 최종 일정만 저장 |
10. 운영·관리자 데이터 흐름
| 단계 | 사용자 | 행동 | 시스템 처리 | 결과 |
|---|---|---|---|---|
| 1 | 관광 운영자/데이터 제공 기관 | 축제, 체험, 로컬 장소 정보를 제안한다 | POST /로 제안 상태 저장 | 검토 대기 상태 생성 |
| 2 | 서비스 관리자 | 제안 데이터를 검토하고 승인/반려/수정 요청한다 | PATCH /로 검토 이력 저장 | 승인 또는 반려 상태 확정 |
| 3 | 시스템 | 승인된 데이터를 목적지 DB와 벡터 DB에 반영한다 | 임베딩 생성, 출처 URL, 검증 시각, 신뢰도 갱신 | 추천 후보 풀 최신화 |
| 4 | 일반 사용자 | 업데이트된 조건으로 검색한다 | RAG 검색 시 최신 데이터와 검증 뱃지 사용 | "관광공사/지자체 검증 완료" 등 신뢰 표시 |
11. 예외 흐름
| 상황 | 처리 |
|---|---|
| 필수 조건 누락 | 챗봇이 국가, 월, 일정 유형, 축제 포함 여부를 추가 질문한다 |
| 추천 후보 없음 | 조건 완화 제안 및 다른 월/테마 안내를 제공한다 |
| 축제 날짜 미검증 | 확정 일정에 배치하지 않고 후보 정보 또는 참고 안내로만 표시한다 |
| 외부 API 실패 | 기본 데이터 표시 후 현재 날씨 또는 장소 상세 미제공 안내를 제공한다 |
| 스트리밍 응답 실패 | 마지막 안정 상태의 PlanDraft를 유지하고 재시도 CTA를 제공한다 |
| 로컬 저장 실패 | 저장 실패 메시지와 재시도 버튼을 제공한다 |
| 로그인 만료 | Refresh Token 재검증 후 실패하면 로그인 화면으로 이동한다 |
| 권한 없는 운영 화면 접근 | 로그인 또는 접근 불가 안내를 표시한다 |
12. 관련 요구사항 및 API 영향
| 영역 | 관련 요구사항 | 관련 API |
|---|---|---|
| 인증/세션 | 역할 모델, Production 회원가입 기반 저장 | /, /, / |
| 온보딩/선호 | FR-ONBOARD-001, FR-STORE-001 | /, / |
| 목적지 탐색 | FR-COM-001, FR-REC-001, FR-REC-002 | /, / |
| 추천 생성 | FR-COM-005, FR-REC-003, FR-REC-004 | /, / |
| 대체 일정 | 월별 기상 경향, 대체 일정 데이터 | / |
| 저장/피드백 | FR-STORE-001, FR-STORE-002, FR-STORE-003 | /, / |
| 외부 연동 | 지도·숙소·현지 플랫폼 딥링크 | /, /, / |
| 운영 검토 | 역할 기반 운영, 데이터 품질·출처 추적성 | /, / |
13. 변경 이력
| 버전 | 날짜 | 작성자 | 변경 내용 |
|---|---|---|---|
| v0.2 | 2026-06-02 | 로브 기획팀 | User Flow와 Service Flow 추가, 인증/JWT, RAG 후보 비교, AI 일정 생성, 실시간 피드백, 외부 딥링크, 관리자 데이터 검증 흐름 반영 |
| v0.1 | 2026-05-29 | 로브 기획팀 | 서비스 흐름 명세서 초안 작성 |