로브 (Lovv)

Local(소도시) + Vibe(분위기·감성), 또는 Voyage(항해·여행)를 뜻한다.

일반적인 Love와 달리 알파벳 v를 겹쳐 써서 트렌디한 스타트업이나 테크 서비스 같은 힙한 인상을 준다.

문서 버전: v3.0 — 관리자 MFA 범위·고위험 승인·admin_web 권한 승인 UX 정합화

문서 상태: 검토 중 (Review)

적용 범위: 로브 서비스 전체

1. 문서 개요

1.1 목적

본 문서는 로브(Lovv) 서비스의 아이디어 기획 단계에서 제품의 핵심 기능, API 연동 요구사항, 비기능 요구사항을 정의한다. 개발 착수 전 이해관계자 간 요구사항에 대한 공통 이해를 확보하는 것을 목적으로 한다.

1.2 범위

본 문서는 다음 범위를 포함한다.

대화형 챗봇 인터페이스 및 기본·확장 테마 기반 소도시 집중 일정 추천 엔진
한국 소도시 추천 — PoC/P1은 한국 강원·경북 데이터 기반 추천으로 고정하고, 한국 전국 확장은 P2로 둔다
일본 소도시 추천(일본 데이터 기반 추천, 일본 현지 데이터/API 연동)은 일본 데이터 수집 실패 리스크를 반영해 P5 재검토 범위로 보류하며, 수집 경로가 복구된 뒤 재승격을 검토한다
여행 시기(달/계절) 입력에 따른 계절 적합 소도시 및 축제·행사 연동
메인 지도 기반 소도시 탐색, 월·테마 필터, 지도 마커 기반 추천 진입점
온보딩 선호 프로필, 추천 피드백, 저장 일정, 북마크, 외부 링크 클릭 기반 개인화
사용자 행동 데이터와 외부 검증 루트를 활용한 cold start 보완 및 세션 기반 개인화
KICK(유사 취향 공개 일정·1탭 복제)은 P2 설계 범위로 관리
지역 문화 체험, 스키 액티비티 등 P3~P4 범위의 확장 테마 추천
여행 시기(월)를 직접 입력해 Wikipedia 기반 월별 날씨 경향이 좋은 소도시를 추천받는 챗봇 진입점
별 관측, 치유·웰니스, 예산 역산 추천은 이번 프로젝트 대상에서 제외하고 향후 단계에서 검토
RAG(검색증강) 기반 grounding 및 멀티스텝 에이전트 추천 파이프라인
Google Maps Platform, Kakao Maps, OpenRouteService 연동 (Yahoo Japan 등 일본 현지 플랫폼 연동은 P5 재검토 범위)
지도 표시, 장소 상세 정보, Wikipedia 기반 월별 날씨 경향, 숙소 검색 링크, 외부 탐색 링크 제공 기능

docs/01_requirements/의 보조 Markdown은 요구사항 후보·근거 자료로 관리한다. 확정된 내용은 이 대표 문서의 기능 요구사항, 데이터 요구사항, 제약사항, 변경 이력에 통합하고, 아직 검토 단계인 내용은 P5 또는 향후 검토 후보로 유지한다.

1.3 용어 정의

용어	정의
오버투어리즘	특정 여행지에 관광객이 과도하게 집중되어 현지 생활환경·자연이 훼손되는 현상
소도시	관광객 집중도가 낮고 로컬 경험이 풍부한 지방 도시 및 읍·면 단위 지역
테마	소도시를 묶는 분류 축 — 초기 6개 테마(온천·휴양 / 바다·해안 / 역사·전통 / 미식·노포 / 자연·트레킹 / 예술·감성)와 공예·웰니스·액티비티 등 확장 테마
추천 진입점	사용자가 테마를 먼저 고르지 않고 여행 시기(월), Wikipedia 기반 월별 날씨 경향, 지도 마커 클릭 등 결정 조건을 통해 추천을 시작하는 흐름
여정 (Route)	사용자가 선택한 소도시 1곳을 대상으로 선택한 일정 유형(당일치기~2박3일)에 맞게 구성한 일별 세부 일정 단위
계절 적합도	각 소도시가 봄·여름·가을·겨울 각 시기에 얼마나 적합한지 나타내는 점수
월별 날씨 경향	Wikipedia에서 추출한 소도시별 1~12월 날씨 패턴 기반 추천용 정적 데이터. 맑음 적합도, 우천·폭설·장마·태풍 경향을 포함
RAG	검색증강생성 — LLM이 답변 시 소도시 관련 지식 데이터를 검색해 근거로 활용, 환각을 방지하는 기법
멀티스텝 에이전트	추천을 단일 호출이 아닌 "분류 → 검색 → 선정 → 일정 구성" 단계로 나눠 처리하는 LLM 파이프라인
추천 엔진	사용자의 취향·시기·혼잡도를 입력받아 소도시 1곳의 집중 일정을 제안하는 RAG·에이전트 기반 시스템
드로어 (Drawer)	하단에서 슬라이드업되는 상세 정보 패널 UI 컴포넌트
API 딥링크	API 직접 호출 없이 외부 플랫폼(Kakao, Yahoo)의 검색·지도 페이지로 연결하는 URL
CORS 제약	브라우저 보안 정책(Same-Origin Policy)으로 인해 외부 API를 클라이언트에서 직접 호출할 수 없는 제약

2. 이해관계자

최종 사용자

자유여행자 (FIT)

취향·시기·동행·이동 범위를 입력하고 소도시 집중 일정을 추천받는다. PoC/P1은 한국 강원·경북 소도시 여행자를 우선 대상으로 하며, 일본 여행자는 일본 데이터 수집 경로 복구 후 P5에서 재검토한다.

운영 사용자

지자체·관광 운영자

소도시 관광 집중도를 모니터링하고 수요 분산 전략을 검토한다.

내부 사용자

서비스 관리자

소도시·축제 데이터, 추천 정책, 공지사항을 관리한다.

연계 기관

공공 데이터 제공 기관

관광지·축제·교통 데이터를 API 형태로 제공하거나, 월별 날씨 경향처럼 공개 문서 기반 데이터를 제공한다 (한국관광공사·JNTO·Wikipedia 등).

2.1 역할 모델

이해관계자는 실제 서비스 권한 체계에서 다음 역할(Role)로 관리한다. 하나의 기관 또는 사용자가 여러 역할을 가질 수 있으며, MVP 단계에서는 조회·제안·승인·관리 권한을 중심으로 단순화한다.

Role ID	역할	주요 사용자	인증	주요 책임
`R-USER`	일반 여행 사용자	자유여행자(FIT)	비로그인 또는 선택 로그인	추천 요청, 추천 결과 조회, 지도·월별 날씨 경향·외부 링크 확인
`R-LOCAL-OPERATOR`	관광 운영자	지자체·관광 운영자	로그인 필수	담당 지역 운영 지표 조회, 지역 데이터 제안, 수요 분산 검토
`R-ADMIN`	서비스 관리자	내부 운영·기획 담당자	로그인 필수	데이터 승인, 추천 정책 관리, 공지 관리
`R-SUPER-ADMIN`	최고 권한 관리자	보안·권한 운영 책임자	로그인 필수, 고위험 결정 시 최근 TOTP	역할·지역 할당과 대량 게시 고위험 변경의 독립 승인·거절
`R-DATA-PROVIDER`	데이터 제공 기관	공공 데이터 제공 기관/API 제공자	기관 인증 또는 API Key	원천 데이터 제공, 갱신 상태 확인, 출처 정보 관리
`R-SYSTEM`	시스템·외부 API	Google Maps, Kakao Maps, OpenRouteService, Yahoo Japan(P5 재검토), Wikipedia 추출 데이터 등	시스템 키 또는 수집 설정	외부 데이터 자동 조회, 동기화, 추천 결과 보강

2.2 권한 매트릭스

기능/데이터	일반 여행 사용자	관광 운영자	서비스 관리자	데이터 제공 기관	시스템/API
추천 요청	가능	가능	가능	불가	불가
추천 결과 조회	가능	가능	가능	제한적	불가
지도·월별 날씨 경향·링크	조회 가능	조회 가능	조회 가능	불가	조회·보강
소도시 데이터	공개 범위 조회	담당 지역 조회·제안	전체 승인·수정	제공 데이터 등록	자동 갱신
축제·행사 데이터	공개 범위 조회	담당 지역 조회·제안	전체 승인·수정	제공 데이터 등록	자동 갱신
추천 정책	불가	불가	수정 가능	불가	적용
운영 지표	불가 또는 요약	담당 지역 조회	전체 조회	불가	산출
대화 로그	저장하지 않음	불가	불가	불가	처리 중 세션 범위
API Key	불가	불가	관리 요청 가능	기관 키 범위	사용
공지사항	조회	제안 가능	등록·수정·삭제	불가	불가

2.3 데이터 접근 범위

데이터 범위	포함 데이터	허용 역할
공개 데이터	목적지 설명, 추천 이유, 지도 링크, 월별 날씨 경향, 외부 탐색 링크	모든 사용자, 운영자, 관리자
담당 지역 데이터	지역별 조회수, 혼잡도 요약, 데이터 제안 상태, 지역 운영 메모	담당 관광 운영자, 관리자
내부 운영 데이터	추천 정책, 데이터 검수 상태, API 연동 상태, 공지 운영 상태	서비스 관리자, 제한된 운영자
민감 데이터	API Key, 처리 중인 세션 데이터, 시스템 설정, 인증 정보	API Key는 개발·운영 담당자와 시스템 역할로 제한하고, 대화 로그 전문은 저장 대상에서 제외한다. 운영 설정은 서비스 관리자와 시스템 역할로 제한

2.4 권한 원칙

각 역할은 수행 목적에 필요한 최소 범위의 데이터와 기능만 사용한다.
여행자에게 노출되는 공개 데이터와 내부 운영 지표, 추천 정책, API Key는 분리한다.
관광 운영자와 데이터 제공 기관은 데이터를 제안·제공할 수 있으나 공개 반영은 서비스 관리자 승인 후 적용한다.
사용자 취향 입력은 추천 목적에 한정해 처리하며, 대화 로그 전문은 저장하지 않는다. 일정·선호·피드백을 저장하는 경우 저장 범위, 보관 기간, 삭제 기준을 명확히 한다.
배포 환경의 외부 API Key는 이 서비스를 개발·운영하는 백엔드/운영 개발자가 서버 환경 변수 또는 백엔드 프록시에서 관리하고 클라이언트 노출을 최소화한다.
서비스 관리자는 API Key 값을 직접 관리하지 않고, 키 발급·교체·만료 대응이 필요할 때 개발·운영 담당자에게 요청한다.

권한 실패 처리:

비로그인 사용자가 관리자 기능에 접근하면 로그인 또는 접근 불가 안내를 표시한다.

담당 지역 외 데이터 접근, 승인 권한 없는 데이터 변경, API Key 미설정·만료 상황은 각각 접근 제한, 제안 상태 저장, 기본 정보 폴백으로 처리한다. API Key 미설정·만료 조치는 개발·운영 담당자가 수행한다.

2.5 후속 문서 반영

후속 문서	반영 항목
사용자 시나리오 / 유저 스토리	일반 여행 사용자, 관광 운영자, 관리자, 데이터 제공 기관의 대표 시나리오를 역할별로 분리한다.
화면 흐름 / 정보 구조	공개 추천 화면과 운영자·관리자 화면의 접근 경로를 분리하고 권한 없는 진입 상태를 정의한다.
Agent 설계	조건 분류, 검색, 후보 선정, 일정 구성, 검증·폴백 단계의 입력·출력과 도구 사용 기준을 정의한다.
데이터 취득 계획서	소도시, 축제, 장소, Wikipedia 월별 날씨 경향 데이터의 수집 대상, 출처, 갱신 주기, 검증 기준을 정의한다.
데이터베이스 설계	역할, 권한, 기관 소속, 담당 지역, 데이터 제안 상태, 승인 이력, 감사 로그 저장 후보를 검토한다.
API 명세서	인증 필요 엔드포인트, 역할별 인가 조건, 401/403/키 만료 응답 형식을 정의한다.
테스트 계획서	역할별 접근 제어, 담당 지역 제한, 제안·승인 분리, API Key 장애 폴백 테스트를 포함한다.

2.6 관리자 RBAC 권한 경계

로브 관리자 콘솔의 인증·인가 경계는 다음 원칙으로 고정한다. 대상 관리 역할은 서비스 관리자(R-ADMIN), 최고 권한 관리자(R-SUPER-ADMIN), 데이터 제공 기관(R-DATA-PROVIDER), 관광 운영자(R-LOCAL-OPERATOR)다.

역할 Source of Truth: 최종 권한은 로브 서비스 DB의 활성 역할 할당을 기준으로 판단한다. Cognito Group 등 외부 인증 그룹 정보는 최초 역할 연결·운영 편의용 보조 신호로만 사용하고 단독 권한 근거로 신뢰하지 않는다.
서버 재검증: API Gateway 인증 이후에도 각 관리자 요청마다 역할과 리소스 범위를 서버 데이터로 다시 검증한다. 요청 본문의 roles, regionIds, organizationId, reviewerId 등 권한·소유권 필드는 신뢰하지 않는다.
공통 admin access gate: require_admin_access는 활성 R-ADMIN 또는 R-SUPER-ADMIN을 허용한다. 일반 admin 읽기·목록 경로는 두 역할 모두 접근할 수 있으며 MFA를 요구하지 않는다.
관리자 Step-up MFA: 로그인 세션은 그대로 유지한다. 일반 admin 읽기·목록 경로와 고위험 요청 생성·조회는 역할 인증만 요구하고, 고위험 변경 승인·거절 시점에만 관리자 도메인 MFA 등록과 최근 5분 이내 TOTP 세션을 요구한다. 복구 코드 인증 세션은 고위험 승인·거절에 사용할 수 없다.
범위 정의: Own은 본인 또는 본인 소속 기관 소유 리소스, Assigned는 활성 지역 할당이 있는 담당 지역, All은 전역 범위를 의미한다.
역할 비상속: 역할은 자동 상속하지 않으며, 권한은 활성 역할별 허용 작업의 합집합으로 계산한다. 범위 제한은 역할마다 따로 적용한다.
기본 역할: 일반 로그인 사용자는 R-USER만 가진다. 관리자 역할은 명시적으로 할당해야 하며, 소셜 로그인이나 이메일 도메인만으로 자동 부여하지 않는다.
실패 원칙: 역할 또는 범위를 확인할 수 없으면 fail-closed로 거부한다.
권한 분리: 데이터 제안 승인과 월간 여행지(이번 달 여행지) 게시는 분리한다. 승인된 데이터도 별도 게시 결정 전에는 노출하지 않는다.
이해충돌 방지: 제안 작성자 본인은 동일 제안을 승인·반려할 수 없다.
고위험 변경 2인 통제: 역할·지역 부여·회수와 10~100건 월간 여행지 대량 게시는 요청자와 결정자를 분리한다. R-ADMIN 또는 R-SUPER-ADMIN이 요청할 수 있지만, 다른 R-SUPER-ADMIN 1명이 승인해야 실행되며 요청자는 자신의 요청을 승인·거절할 수 없다.
승인과 실행의 원자성: 고위험 요청 승인은 대상 변경, 요청 상태 전이, 감사 로그 기록을 하나의 트랜잭션으로 처리한다. 어느 하나라도 실패하면 전체 변경을 롤백한다.

2.7 관리자 권한 매트릭스 (RBAC)

Own은 본인 또는 소속 기관 소유 리소스, Assigned는 할당된 지역, All은 전역 범위를 의미하며, 범위 제한은 역할별로 따로 적용한다.

작업	R-USER	R-DATA-PROVIDER	R-LOCAL-OPERATOR	R-ADMIN	R-SUPER-ADMIN
관리자 콘솔 세션 확인	거부	허용	허용	허용	허용
관리자 MFA 등록·인증	거부	거부	거부	본인 계정	본인 계정
데이터 제안 작성	거부	허용	거부	거부	거부
제안 조회	거부	Own	Assigned 집계만	All	All
제안 수정·재제출	거부	Own	거부	거부	거부
제안 상세 근거 조회	거부	Own	거부	All	All
승인·수정 요청·반려	거부	거부	거부	All	거부
처리 이력 조회	거부	Own 공개 이력	Assigned 집계만	All	All
감사 로그 조회	거부	거부	거부	All	All
운영 지표 조회	거부	거부	Assigned	All	All
월간 여행지 후보·게시 상태 조회	거부	본인 제안 공개 상태	Assigned 요약	All	All
월간 여행지 단건 게시·비노출·만료 처리	거부	거부	거부	All	거부
게시 작업 재시도	거부	거부	거부	All	거부
공지·추천 정책 변경	거부	거부	거부	All	거부
고위험 변경 요청 생성·조회	거부	거부	거부	All	All
고위험 변경 승인·거절·실행	거부	거부	거부	거부	All, 자기 요청 거부
역할·지역 할당 직접 변경	거부	거부	거부	거부	거부, 고위험 변경 절차만 허용
월간 여행지 10~100건 대량 게시	거부	거부	거부	요청만	요청 또는 다른 요청자의 요청 결정·실행

R-SYSTEM(외부 API·시스템 역할)은 관리자 콘솔 인가 대상이 아니며 자동 데이터 조회·동기화에 한정한다.

2.8 관리자 콘솔 권한 승인 UX 원칙

admin_web은 권한 승인 탭에서 pending 고위험 변경 요청을 로그인 직후 eager loading한다. 이 목록과 pending count badge는 MFA 없이 role union 권한만으로 표시하며, pending 건수가 50건 이상이면 50+로 표시한다.

R-ADMIN은 고위험 요청 목록 조회와 요청 생성을 할 수 있지만 승인·거절 버튼은 보지 않는다.
R-SUPER-ADMIN은 pending 요청의 승인·거절 액션을 볼 수 있다. 단, 자기 요청은 backend에서 거부한다.
승인·거절 클릭 시 backend가 ADMIN_MFA_REQUIRED, ADMIN_MFA_TOTP_REQUIRED, ADMIN_MFA_ENROLLMENT_REQUIRED, ADMIN_MFA_LOCKED, SUPER_ADMIN_REQUIRED를 반환하면 UI는 해당 사유에 맞는 MFA 모달 또는 권한 오류를 표시한다.
MFA 모달은 /admin/security/mfa/verify로 TOTP 세션을 먼저 만든 뒤 approve/reject API를 다시 호출한다. approve/reject body에는 TOTP code를 넣지 않는다.
recovery code는 계정 복구용으로만 안내하고, 고위험 승인용 인증 수단으로 표시하지 않는다.
개발 preview에 VITE_LOVV_USE_SAMPLE_DATA=true가 제공되는 경우, 샘플 데이터 모드는 권한 승인 탭의 레이아웃·상태 확인용이며 실제 권한 판단 결과로 해석하지 않는다.

3. 서비스 개요

3.1 서비스 소개

로브(Lovv)는 오버투어리즘 회피를 목적으로 한국의 비주류 소도시 1곳을 사용자의 취향과 여행 시기에 맞는 집중 일정으로 추천하는 대화형 챗봇 서비스다. 사용자가 자연어로 취향과 여행 시기를 입력하거나 지도에서 소도시 마커를 선택하면, 멀티스텝 에이전트가 조건을 테마 또는 추천 진입점으로 해석하고 RAG로 검색한 소도시 데이터에 근거하여 적합한 소도시 1곳과 일별 세부 일정을 추천 이유와 함께 제공한다. PoC/P1은 일본 데이터 수집 실패 리스크를 반영해 한국 강원·경북 소도시 데이터 기반 추천으로 고정하며, 한국 전국 확장은 P2로 둔다. 일본 소도시 추천(일본 데이터 기반 추천, 일본 현지 데이터/API 연동)은 수집 경로가 복구된 뒤 P5에서 재검토하며, 향후 일본 트랙을 운영할 때는 한국은 한국 소도시만, 일본은 일본 소도시만 추천하는 나라별 독립 트랙으로 운영한다.

서비스명 로브(Lovv)는 Local(소도시)과 Vibe(분위기·감성), 또는 Voyage(항해·여행)의 의미를 결합한 이름이다. 일반적인 Love와 달리 알파벳 v를 겹쳐 사용해 감성적인 여행 서비스이면서도 트렌디한 스타트업·테크 서비스의 인상을 전달한다.

추천 시 여행 시기(월)에 빛나는 소도시와 사용자가 포함을 선택한 축제·행사를 일정에 결합하며, 각 결과에는 Google Maps, Kakao Maps, OpenRouteService, Wikipedia 추출 월별 날씨 경향 데이터가 역할 분담하여 지도·장소 상세·이동 동선·월별 날씨 경향·링크 정보를 보완 제공한다. Yahoo Japan 등 일본 현지 플랫폼 API 연동은 P5 재검토 범위로 보류한다. 지역 문화 체험, 스키 액티비티 같은 P3~P4 확장 테마와 Wikipedia 기반 월별 날씨 경향을 기준으로 한 직접 질의형 추천도 같은 추천 엔진 안에서 처리한다. 별 관측, 치유·웰니스, 예산 역산 추천은 이번 프로젝트 대상에서 제외하고 향후 단계에서 검토한다.

3.2 핵심 가치 제안

가치 항목	설명
소도시 집중 일정 추천	기본·확장 테마와 사용자 조건에 맞는 소도시 1곳을 선정하고 당일치기~2박3일 일정을 설계해 제공
계절·축제 연동	여행 시기에 빛나는 소도시와 사용자가 포함을 선택한 축제·행사를 일정에 결합
직접 질의형 추천	사용자가 여행 시기(월)를 바로 말하면 테마 선택 없이 Wikipedia 기반 월별 날씨 경향이 좋은 소도시를 역으로 제안. 예산 역산은 향후 검토
지도 기반 진입	메인 지도에서 국가·월·테마로 소도시를 필터링하고 마커 클릭으로 추천을 시작
개인화 루프	온보딩 선호, 저장 일정, 북마크, 좋아요/싫어요 피드백, 외부 링크 클릭을 다음 추천 조건과 세션 내 후보 조정에 반영
혼잡 회피형 추천	단순 인기순이 아닌 혼잡도 낮은 대체 여행지를 우선 추천
RAG 기반 정확성	직접 구축한 소도시 데이터를 검색·근거로 활용해 환각 없는 사실 기반 추천
멀티스텝 에이전트	분류→검색→선정→일정 구성을 단계별로 추론하여 추천 품질 확보
일본 트랙 (P5 재검토)	한국 소도시 추천을 PoC/P1 핵심으로 제공하고, 일본 소도시 트랙은 데이터 수집 경로 복구 후 P5에서 재검토한다

3.3 타겟 사용자

구분	설명
주 타겟	국내외 여행을 즐기지만 혼잡한 인기 여행지를 피하고 싶은 20~40대 성인
부 타겟	일본 여행 경험이 있어 도쿄·오사카 외 소도시를 탐색하는 여행자
공통 특성	자연어 대화에 익숙하고, 스마트폰 중심의 여행 정보 탐색 습관 보유

3.4 서비스 흐름 요약

단계	입력	처리 / 출력
1	진입 및 조건 파악	온보딩 선호 프로필이 기본값으로 적용됨. 사용자는 지도 마커 클릭 또는 챗봇 대화로 진입하며 국가·여행 시기(월)·테마를 파악
2	진입점 분류	지도 마커 클릭(목적지+일정 유형+축제 포함 여부) 또는 챗봇 발화(테마·시기·월별 날씨 경향 직접 질의)로 분류
3	RAG 검색·후보 선정	테마+계절 적합도+Wikipedia 월별 날씨 경향 데이터를 기준으로 소도시 1곳을 선정
4	일정 구성	선택한 일정 유형(당일치기~2박3일) 기준 일별 세부 일정 생성. 각 날은 메인 관광지 1개와 서브 관광지로 구성하고, 식사는 별도 선택 슬롯으로 제공
5	상세 정보 조회	드로어 패널에서 지도·장소 정보·월별 날씨 경향·외부 링크 확인
6	외부 연동	숙소 검색 링크, Kakao 딥링크로 추가 정보 확인 (Yahoo Japan 등 일본 현지 딥링크는 P5 재검토 범위)

4. 기능 요구사항

본 섹션은 로브 서비스가 제공해야 하는 사용자 기능과 시스템 동작을 정의한다. 각 요구사항은 개발, 설계, 테스트에서 공통 기준으로 사용할 수 있도록 식별자, 적용 영역, 요구사항 내용, 비고로 구분한다.

기능 요구사항 표에서는 우선순위 컬럼을 제외한다. 실제 개발 우선순위는 별도 백로그에서 P1~P5 구간으로 산정한다.

4.1 공통 사용자 인터페이스

ID	서비스/영역	요구사항 내용	비고
FR-COM-001	공통 UI	사용자는 자연어, 조건 입력, 선택형 칩 또는 필터를 통해 여행 조건을 입력할 수 있어야 한다.	여행 조건 입력 통합
FR-COM-002	공통 UI	추천 결과는 카드, 표, 지도, 상세 패널 등 사용자가 비교 가능한 형태로 표시되어야 한다.	결과 비교 가능성
FR-COM-003	공통 UI	서비스는 모바일과 데스크톱에서 핵심 탐색, 추천, 상세 확인 기능을 사용할 수 있는 반응형 화면을 제공해야 한다.	접근성/호환성 연계
FR-COM-004	다국어/국가 선택	국가 또는 언어가 서비스 흐름에 영향을 주는 경우 사용자는 대상 국가와 표시 언어를 선택할 수 있어야 한다.	PoC/P1은 한국 단일 국가 기준. 일본 등 다국가/다국어 확장은 P5 재검토 보류
FR-COM-005	추천 실행 CTA	필수 조건이 충족되면 사용자는 `여행 일정 추천 받기` 버튼을 눌러 추천 파이프라인을 실행할 수 있어야 한다. 필수 조건이 부족하면 버튼은 비활성화되거나 추가 질문을 유도해야 한다.	추천 시작 버튼

4.2 추천·탐색 기능

ID	서비스/영역	요구사항 내용	비고
FR-REC-001	테마 추천	시스템은 사용자 입력을 테마, 계절, 동행자, 지역, 혼잡 회피 선호 등 추천 조건으로 분류해야 한다.	기존 테마 분류 통합
FR-REC-002	대체 추천	시스템은 혼잡도가 높거나 조건에 맞지 않는 대상 대신 대체 관광지, 축제, 방문 시간 또는 경로를 추천해야 한다.	분산 추천 핵심
FR-REC-003	추천 결과 구성 및 설명 가능성	추천 결과에는 소도시명, 위치, 대표 이미지, 추천 이유, 일정 흐름 이유, 주요 태그, 숙소 검색 링크, 외부 탐색 링크가 포함되어야 한다. 추천 이유는 사용자 조건, 계절 적합도, 혼잡도, Wikipedia 월별 날씨 경향 중 2개 이상을 근거로 서술해야 한다.	Explainability 4요소
FR-REC-004	개인화	시스템은 사용자 취향, 이동 조건, 일정 유형, 동행자 조건, 온보딩 선호 프로필, 북마크, 추천 피드백, 외부 링크 클릭을 반영해 추천 결과를 세션 단위로 조정해야 한다.	서비스별 세부 조건 적용
FR-REC-005	저장/비교	사용자는 추천 소도시 일정 또는 축제 후보를 저장하거나 비교할 수 있어야 한다.	일정 후보 관리
FR-REC-006	추천 다시 받기	사용자는 추천 결과 화면에서 `추천 다시 받기` 버튼을 눌러 현재 조건을 유지한 채 다른 소도시 또는 변형 일정을 다시 추천받을 수 있어야 한다. 시스템은 직전 추천과 동일한 결과를 반복하지 않거나, 동일 결과가 필요한 경우 그 사유를 설명해야 한다.	결과 재생성
FR-STORE-001	저장 데이터 범위	시스템이 저장하는 사용자 데이터는 추천 결과로 생성된 여행 일정, 온보딩 응답, 추천 피드백(좋아요/싫어요), 북마크, 공개 일정 복제 이력, 외부 링크 클릭 이벤트로 한정한다. 대화 전문은 저장 대상에서 제외한다.	저장 범위 제한
FR-STORE-002	PoC 로컬 스토리지	PoC 단계에서 사용자 일정, 선호, 피드백, 북마크 데이터는 브라우저 로컬 스토리지에 저장하며 서버 전송 없이 클라이언트에서 관리한다.	PoC
FR-STORE-003	Production 회원가입 기반 저장	Production 단계에서 사용자는 회원가입 후 자신의 여행 일정, 선호, 피드백, 북마크, 공개 일정 복제 이력을 서버에 저장하고 마이페이지에서 조회할 수 있다.	Production
FR-ONBOARD-001	온보딩 질문	사용자는 서비스 첫 진입 시 선호 여행 스타일을 파악하기 위한 온보딩 질문에 응답해야 한다. 온보딩은 건너뛸 수 없으며 이후 마이페이지에서 재응답할 수 있어야 한다.	필수
FR-ONBOARD-002	대도시-테마 매핑	온보딩 질문은 한국 6개 대도시 스타일 보기를 제공하고, 각 선택지를 온천·휴양, 바다·해안, 역사·전통, 미식·노포, 자연·트레킹, 예술·감성 기본 테마와 매핑해야 한다.	P1은 한국 6개 대도시 기준. 일본 대도시 매핑은 P5 재검토 보류
FR-ONBOARD-003	온보딩 결과 반영	시스템은 온보딩에서 수집한 선호 테마 프로필을 첫 번째 추천부터 기본 조건으로 적용해야 한다. 사용자가 대화 중 다른 조건을 명시하면 대화 조건을 우선 적용한다.	추천 기본값
FR-PERS-001	추천 피드백 UI	사용자는 추천받은 각 소도시에 대해 좋아요 또는 싫어요를 선택할 수 있어야 한다. 선택 결과는 저장 데이터 범위에 따라 보관된다.	개인화 입력
FR-PERS-002	피드백 반영 추천	시스템은 사용자가 싫어요를 선택한 소도시의 추천 우선도를 낮추고, 좋아요를 선택한 소도시의 테마 태그를 다음 추천의 가중치 조건으로 반영해야 한다.	개인화 루프
FR-PERS-003	북마크	사용자는 소도시와 대도시를 북마크할 수 있어야 한다. 소도시 북마크는 선호 추론에, 대도시 북마크는 대도시 기준 주변 소도시 탐색과 비교에 활용한다.	대도시 북마크는 대도시 자체 저장
FR-PERS-004	공개 일정 복제 신호	사용자가 공개 일정을 1탭 복제하거나 참고한 경우, 시스템은 해당 행동을 저장·재추천 전환 분석에 활용할 수 있어야 한다.	KICK P2 설계
FR-PERS-005	Cold Start	시스템은 사용자 행동 데이터가 부족한 초기 상태에서 관광공사, 지자체, 공식 출처, 내부 검증 루트를 기반으로 초기 추천 후보를 구성해야 한다.	신규 사용자 보완
FR-PERS-006	세션 기반 개인화	시스템은 온보딩 선호, 저장, 북마크, 좋아요/싫어요, 외부 링크 클릭, 현재 대화 조건을 다음 추천의 가중치 조건으로 반영해야 한다.	점수 모델 고도화 전 단계
FR-MY-001	마이페이지	서비스는 사용자가 자신의 저장 일정, 선호, 피드백, 북마크, 공개 일정 복제 이력을 조회·관리할 수 있는 마이페이지를 제공해야 한다. PoC에서는 로컬 스토리지 기반, Production에서는 로그인 후 서버 기반으로 운영한다.	저장 관리
FR-MY-002	일정 목록 조회	마이페이지에서 사용자는 이전에 저장한 여행 일정 목록을 조회하고 개별 일정의 상세 내용을 확인할 수 있어야 한다.	Production 중심
FR-MY-003	선호 재설정	마이페이지에서 사용자는 온보딩 결과를 재응답해 선호 테마 프로필을 업데이트할 수 있어야 한다.	Production 중심

4.3 지도·위치·경로 기능

ID	서비스/영역	요구사항 내용	비고
FR-MAP-001	지도 표시	추천 결과와 혼잡도 또는 목적지 위치는 지도 기반으로 표시되어야 한다.	기존 지도 연동 통합
FR-MAP-002	지도 플랫폼	국내 목적지는 Google Maps와 Kakao Maps 링크 또는 탭을 제공해야 한다.	P1은 한국 목적지(Google/Kakao) 기준. 일본 목적지 및 일본 현지 플랫폼 링크 분기는 P5 재검토 보류
FR-MAP-003	경로/패스	철도 기반 서비스는 출발지, 도착지, 패스권, 예상 비용을 비교해 최적 경로 또는 패스를 추천해야 한다.	RailRoute 전용
FR-MAP-004	상세 패널	목적지 또는 추천 카드 선택 시 위치, Wikipedia 기반 월별 날씨 경향, 주변 명소, 외부 링크를 확인할 수 있는 상세 패널을 제공해야 한다. 월별 경향 외 날씨 데이터는 표시하지 않는다.	드로어/상세 카드
FR-MAP-005	메인 소도시 지도	메인 페이지는 추천 대상 소도시의 위치를 마커로 표시한 지도를 제공해야 한다.	P1은 한국 소도시 마커 기준. 일본 소도시 마커 및 한·일 구분 표시는 P5 재검토 보류
FR-MAP-006	지도 필터	메인 지도는 월(1~12월), 테마를 기준으로 소도시 마커를 필터링하는 기능을 제공해야 한다. 복수 조건 동시 적용이 가능해야 한다.	P1은 월·테마 필터 기준. 국가(한국/일본) 필터는 일본 트랙 P5 재검토 시 적용
FR-MAP-007	마커 클릭 여행 시작	사용자가 지도 마커를 클릭하면 해당 소도시를 목적지로 설정하고, 지도 위에서 일정 유형을 선택한 뒤 축제·행사 포함 여부 확인을 거쳐 챗봇 추천 흐름을 시작해야 한다.	지도 기반 추천 진입
FR-MAP-008	일정 이동 동선 표시	시스템은 추천 일정에 포함된 메인·서브 관광지 마커를 일정 순서대로 연결하고, OpenRouteService Directions API 기반 이동 경로를 지도 위에 폴리라인으로 표시할 수 있어야 한다. API 호출 실패 시 직선 연결 또는 장소 목록 중심 UI로 폴백해야 한다.	ORS Directions
FR-MAP-009	이동 시간·거리 비교	시스템은 서브 관광지 후보를 제안하거나 일정 수정 후보를 비교할 때 OpenRouteService Matrix API로 후보 간 이동 시간·거리 정보를 계산할 수 있어야 한다. 이 값은 후보 정렬 보조 정보이며 단독 추천 근거로 사용하지 않는다.	ORS Matrix
FR-MAP-010	위치 반경 추천	위치 반경 기반 추천은 PoC 상세 범위에서 제외하고 향후 확장 후보로 관리한다.	향후 검토

4.4 RAG·챗봇·에이전트 기능

ID	서비스/영역	요구사항 내용	비고
FR-RAG-001	RAG 검색	서비스는 실제 수집 데이터 또는 벡터화된 지식베이스를 근거로 추천과 답변을 생성해야 한다.	환각 방지
FR-RAG-002	멀티스텝 에이전트	추천 파이프라인은 조건 분류, 데이터 검색, 후보 선정, 일정 구성, 검증 단계를 순차적으로 처리해야 한다.	다단계 처리
FR-RAG-003	대화형 Q&A	추천 이후 사용자는 추가 질문을 할 수 있고, 시스템은 메타데이터와 추천 근거를 바탕으로 후속 답변을 제공해야 한다.	후속 질의응답
FR-RAG-004	폴백/검증	각 에이전트 단계가 실패하거나 데이터 근거가 부족한 경우 재시도, 폴백 응답, 안내 메시지를 제공해야 한다.	안정성
FR-RAG-005	직접 질의 진입점	시스템은 사용자가 테마를 고르지 않고 여행 시기(월)를 바로 입력해 해당 월의 Wikipedia 기반 날씨 경향이 좋은 소도시를 추천받을 수 있도록 지원해야 한다. 챗봇 진입 시 추천 생성 직전 축제·행사 포함 여부 확인 단계를 거친다.	월별 날씨 경향 기반

4.5 외부 데이터/API 연동

ID	서비스/영역	요구사항 내용	비고
FR-API-001	공공/관광 데이터	서비스는 관광지, 축제, 교통, 혼잡도 등 외부 데이터 소스를 연동하거나 수집할 수 있어야 한다. 월별 날씨 경향은 Wikipedia에서 추출·전처리한 정적 데이터로 관리한다.	데이터 기반 서비스 공통
FR-API-002	지도/장소 API	지도와 장소 상세 정보는 외부 API 키 또는 공개 API 상태에 따라 연동되고, 미설정 시 안내 UI를 제공해야 한다. 월별 날씨 경향은 API 키 상태와 분리한다.	API 키 설정 포함
FR-API-003	데이터 최신성	축제, 혼잡도, 촬영지, 상품 정보처럼 변경 가능성이 높은 데이터는 갱신 주기와 최신성 상태를 관리해야 한다.	품질 기준
FR-API-004	외부 링크	추천 대상에는 지도, 블로그, 예약, 현지 플랫폼 등 사용자가 후속 행동을 할 수 있는 외부 링크를 제공해야 한다.	예약/탐색 연결
FR-API-005	애니메이션 성지 데이터	시스템은 Anime Tourism 88, JNTO, KTO TourAPI, OSM, Wikidata, 지자체·공식 사이트 등에서 애니메이션 성지 후보와 장소 기본 정보를 수집·검증할 수 있어야 한다.	일본 데이터 의존. 일본 데이터 수집 경로 복구 후 P5 재검토 보류
FR-API-006	일본 현지 플랫폼	일본 목적지에는 Yahoo Travel, じゃらん, 楽天トラベル, 食べログ 등 숙박·맛집·카페 탐색을 위한 외부 딥링크를 제공해야 한다.	일본 현지 데이터/API 연동. P5 재검토 보류
FR-API-007	Wikipedia 월별 날씨 경향 데이터	Wikipedia에서 추출한 월별 날씨 경향 데이터는 추천 후보 스코어링, 계절 정합성 검증, 대체 일정 알림 팝업 분기에 사용한다. 월별 경향 외 날씨 데이터는 호출하거나 화면에 표시하지 않는다.	출처 URL, 추출 기준일, 갱신 실패 안내 필요
FR-API-008	OpenRouteService 경로 API	서비스는 OpenRouteService Directions API를 사용해 일정 마커 간 경로 폴리라인, 이동 거리, 예상 이동 시간을 계산할 수 있어야 한다. API Key는 클라이언트에 노출하지 않고 백엔드 프록시 또는 서버 환경 변수에서 관리한다.	지도 동선 표시
FR-API-009	OpenRouteService Matrix API	서비스는 OpenRouteService Matrix API를 사용해 후보 장소 간 이동 시간·거리 행렬을 계산할 수 있어야 한다. 호출량 제한과 실패 가능성을 고려해 캐시, 후보 수 제한, 폴백 UI를 적용해야 한다.	후보 비교 보조
FR-API-010	비용 추정 데이터	교통, 숙박, 식비, 체험 비용 추정에 사용하는 외부 또는 내부 기준 데이터는 출처와 갱신 시점을 관리해야 한다.	사용자 여행 예산 추천 근거
FR-STAY-001	숙소 검색 링크 정책	시스템은 추천 일정에서 숙소를 직접 추천하지 않는다. 대신 목적지와 일정 기간을 조합한 숙박 플랫폼 검색 링크를 제공해야 한다.	직접 추천 제외
FR-STAY-002	한국 숙소 검색 링크	한국 목적지 추천 결과에는 야놀자, 여기어때, 네이버 호텔로 연결되는 목적지·날짜 기반 검색 딥링크를 포함해야 한다.	한국 목적지

4.6 서비스별 세부 기능

우선순위 및 단계별 추진 범위

PoC 단계는 P1 구현을 핵심 범위로 한다. P2는 PoC에서 설계까지 완료하고, 일정 여유가 있을 경우 일부 구현한다. P3는 PoC에서 설계 산출물까지만 정리한다. P4는 Production 단계에서 구현한다. P5는 이번 프로젝트 대상에서 제외하고 향후 검토한다. P5 항목은 우선순위 및 단계별 추진 범위에만 기록하고, 아래 상세 기능 요구사항 표에서는 제외한다. P2 이상 기능은 핵심 AI 추천 경험(P1)이 완성된 이후 진입한다. P1 단계에서 recommendation flow, personalization, ranking, explainability가 충분히 검증되지 않으면 P2 구현을 시작하지 않는다.

우선순위	기능 범위	PoC	Production	상태
P1	한국 강원·경북 데이터 기반 혼잡 회피 대체 여행지 추천, 국내(한국) 축제 기반 여정 추천, Wikipedia 월별 날씨 경향 기반 추천 진입, 세션 기반 개인화	구현	고도화	핵심
P2	한국 전국 확장, KICK(유사 취향 공개 일정·1탭 복제)	설계	구현 검토	선택 구현
P3	K-Drama 촬영지 탐색, 철도 경로 기반 주변 관광지 안내, 지역 문화 체험 추천	설계	구현 검토	설계
P4	스키 액티비티 여행 추천	정의	Production 구현 검토	Production
P5	일본 데이터 기반 추천, 일본 현지 데이터/API 연동(일본어 검색 키워드 FR-JP-005, 애니메이션 성지순례 FR-ANIME-001~003, 일본 현지 탐색 링크 FR-API-006 포함), 별 관측 조건 기반 여행지 추천, 치유·웰니스 여정 추천, 예산 역산 추천	제외	검토	제외

보조 요구사항 문서의 대표 문서 반영 기준은 다음과 같다.

분류	보조 문서	대표 문서 반영 방식
P1 핵심 추천	`supplemental/overturizim.md`, `supplemental/korea_japan.md`, `supplemental/weather_first.md`	혼잡 회피, 국내(한국) 축제, Wikipedia 월별 날씨 경향 기반 추천 요구사항으로 통합. 한일 양방향 축제 설계의 일본 축제 트랙은 P5 재검토로 보류
P2 선택 구현	`supplemental/priority_plan.md`, `supplemental/kick_summary.md`	한국 전국 확장과 KICK(유사 취향 공개 일정·1탭 복제) 설계 범위로 정리. 일본어 검색 키워드·일본 현지 탐색 링크는 P5로 이동
P3 설계	`supplemental/kdrama-pipeline.md`, `supplemental/trip_train.md`, `supplemental/craft_experience.md`, `supplemental/personalization.md`, `supplemental/lovv_agent_multiturn_context_spec.md`	K-Drama 촬영지, 철도, 지역 문화 체험, 멀티턴 컨텍스트 요구사항으로 통합
P4 Production	`supplemental/seasonal_activity.md`	스키 액티비티 요구사항으로 통합
P5 향후 검토	`supplemental/japan_add_function.md`, `supplemental/animation.md`, `supplemental/astro_rag_proposal.md`, `supplemental/healing_wellness.md`, `supplemental/budget_first.md`	이번 프로젝트 상세 기능 요구사항에서는 제외하고 데이터 후보·제약사항에 향후 검토로 기록. 일본 데이터 기반 추천·일본 현지 데이터/API 연동(일본어 검색 키워드, 애니메이션 성지순례)은 일본 데이터 수집 경로 복구 후 재검토
우선순위 정리	`supplemental/priority_plan.md`	P1~P5 단계별 추진 범위의 기준 자료로 반영

우선순위 기능 요구사항

ID	서비스/영역	요구사항 내용	비고
FR-OTR-001	오버투어리즘	시스템은 관광지별 혼잡도를 조회하고 혼잡도가 높은 지역의 대체 관광지와 대체 방문 시간대를 추천해야 한다.	혼잡도 기준과 대체지 선정 근거 필요
FR-OTR-002	오버투어리즘	운영자는 지역별 혼잡도, 추천 분산 결과, 데이터 수집 상태를 모니터링할 수 있어야 한다.	운영 화면에서 지역·기간별 필터 필요
FR-FES-001	국내 축제	사용자는 날짜, 지역, 테마, 동행자 조건을 입력해 한국 축제를 추천받을 수 있어야 한다.	P1은 한국 축제 기준. 국가·언어 선택을 포함한 일본 축제 추천은 P5 재검토 보류
FR-FES-002	국내 축제	축제 추천 결과에는 축제명, 기간, 지역, 추천 이유, 주변 관광 자원, 후속 질의응답 진입점을 포함해야 한다.	축제 기간과 개최 상태 최신성 표시. 일본 축제 트랙은 P5 재검토 보류
FR-ENTRY-WEATHER-001	월별 날씨 경향 기반 추천 진입점	사용자는 테마를 고르지 않고 여행 시기(월)를 입력해 해당 월의 날씨 경향이 좋은 소도시를 추천받을 수 있어야 한다. 추천은 Wikipedia에서 추출한 월별 날씨 경향 데이터에 기반한다.	weather-first, 월별 날씨 경향 기반
FR-ENTRY-WEATHER-002	월별 날씨 경향 표시	추천 결과 또는 목적지 상세에는 월별 날씨 경향, 추천 적기, 우천·폭설·장마·태풍 경향, 데이터 출처 URL과 추출 기준일을 표시해야 한다. 월별 경향 외 날씨 데이터는 표시하지 않는다.	표시용 최신성
FR-ENTRY-WEATHER-003	월별 기상 영향 알림 팝업	추천 목적지가 해당 여행 월에 비·폭설·장마·태풍 등 여행 영향 경향이 있는 경우, 시스템은 기본 일정을 제시한 뒤 대체 일정 추가 여부를 알림 팝업으로 확인해야 한다. 사용자가 동의하면 동일 목적지의 실내·우천 적합 대체 일정을 추가하고, 거절하면 기본 일정을 유지한다.	월별 날씨 경향 기반 팝업
FR-WEATHER-001	Wikipedia 월별 날씨 경향 데이터	시스템은 Wikipedia에서 추출한 소도시별 1~12월 날씨 경향(맑음 적합도, 우천·폭설·장마·태풍 경향)을 추천용 정적 데이터로 관리해야 한다.	추천용
FR-WEATHER-002	날씨 경향 기반 스코어링	후보 선정 단계에서 월별 기상 영향 경향이 높은 목적지는 감점하고, 여행 시기와 날씨 경향이 맞는 목적지는 우선 추천해야 한다.	ranking 연계
FR-WEATHER-003	대체 일정 알림 팝업	월별 날씨 경향상 비·폭설·장마·태풍 등 여행 영향 가능성이 높은 목적지는 대체 일정 추가 여부를 묻는 알림 팝업을 제공해야 한다.	UI 분기
FR-TRIP-001	일정 유형 선택	사용자는 당일치기, 1박2일, 2박3일 중 하나의 일정 유형을 선택할 수 있어야 한다. P1 한국 추천에 적용하며, 일정 유형에 따라 일별 방문지 수와 밀도를 조정해야 한다.	공통 일정 유형
FR-TRIP-002	초기 일정 구성	시스템은 소도시 선정 근거가 된 관광지 후보들만으로 전체 일정을 채우지 않아야 한다. 각 날은 1개의 메인 관광지와 복수의 서브 관광지로 구성한다.	일정 다양성
FR-TRIP-003	메인 관광지 선정	메인 관광지는 소도시 선정 근거가 되었던 관광지 후보에서 우선 채워야 한다. 단, 사용자가 원하면 동일 테마를 유지하는 범위에서 교체할 수 있어야 한다.	근거 관광지 활용
FR-TRIP-004	서브 관광지 인출	서브 관광지는 선정된 소도시의 DynamoDB 관광지 데이터에서 다시 인출해야 하며, 메인 관광지와 장소 타입이 과도하게 중복되지 않도록 균형을 고려해야 한다.	장소 타입 균형
FR-TRIP-005	일정 수정	사용자는 자연어 변경 요청 또는 DB에서 조회된 관광지 목록 직접 선택으로 일정을 수정할 수 있어야 한다. 서브 관광지는 테마 고정 없이 자유롭게 지정할 수 있다.	사용자 주도 수정
FR-TRIP-006	식사 슬롯	일정에는 관광지와 분리된 식사 슬롯을 제공해야 하며, 식당은 프론트엔드에서 제공하는 목록에서 사용자가 선택할 수 있어야 한다.	프론트 구현 반영
FR-FEST-ENTRY-001	축제·행사 포함 여부 확인	시스템은 지도 마커 클릭과 챗봇 대화 두 진입점 모두에서 여행 일정 생성 직전 "현지 축제·행사를 일정에 포함할까요?"를 사용자에게 확인해야 한다. 선택 결과는 해당 세션의 추천 조건으로만 사용하며 장기 저장하지 않는다.	추천 직전 확인
FR-KDRAMA-001	미디어 촬영지·성지순례	시스템은 한국 K-Drama 촬영지 데이터를 수집, 정제, 검증하고 장소별 메타데이터를 구조화해야 한다.	수집 출처와 검증 상태 필수
FR-KDRAMA-002	미디어 촬영지·성지순례	K-Drama 촬영지 결과는 작품명, 위치, 검증 상태, 신뢰도, 태그, 참조 링크와 함께 소도시 여정 중심으로 탐색 가능해야 한다.	작품·장소 매핑 근거 표시
FR-RAIL-001	철도 경로 기반 주변 관광지 안내	시스템은 철도 경로를 기준으로 이동 가능한 소도시와 경로 주변 관광지를 함께 안내해야 한다.	출발지·이동시간·환승 난이도 반영
FR-RAIL-002	철도 경로 기반 주변 관광지 안내	철도 경로 추천 결과에는 주요 역, 환승, 소요 시간, 주변 관광지, 패스 활용 가능 여부를 함께 표시해야 한다.	패스 적용 가능 구간과 주변 관광지 연결 기준 필요
FR-THEME-CRAFT-001	지역 문화 체험 추천	시스템은 공예, 차, 지역 요리, 전통문화, 농어촌 활동 등 지역 문화를 체험할 수 있는 소도시를 추천해야 한다.	실내외 체험 모두 포함
FR-THEME-CRAFT-002	지역 문화 체험 추천	지역 문화 체험 추천 결과에는 체험 소요 시간, 난이도, 예약 필요 여부, 참여 방식, 우천 적합성을 표시해야 한다.	체험 참여 조건 구분
FR-THEME-CRAFT-003	지역 문화 체험 추천	시스템은 지역 문화 체험과 주변 마을, 축제, 로컬 관광 자원을 하나의 여정으로 묶어 제안해야 한다.	체험+주변 관광 결합
FR-THEME-ACTIVITY-001	스키 액티비티 여행 추천	시스템은 스키장 접근성, 적설·날씨 조건, 강습 가능 여부를 기준으로 겨울 액티비티 소도시를 추천해야 한다.	계절축과 직접 연동
FR-THEME-ACTIVITY-002	스키 액티비티 여행 추천	스키 추천 결과에는 적합 시기, 날씨 조건, 난이도, 강습 가능 여부, 장비 대여 정보를 포함해야 한다.	초보자 판단 정보
FR-THEME-ACTIVITY-003	스키 액티비티 여행 추천	시스템은 스키 액티비티와 주변 휴식, 온천, 식당 코스를 하나의 여정으로 결합해야 한다.	활동+회복 결합

향후 검토 후보는 다음과 같이 관리한다. 이 항목은 이번 프로젝트의 상세 기능 요구사항 표에는 포함하지 않는다.

후보	근거 보조 문서	검토 조건
일본 데이터 기반 추천	`supplemental/korea_japan.md`, `supplemental/japan_add_function.md`	일본 소도시·축제·방문 통계·월별 날씨 경향의 수집 경로와 로컬 검증 산출물을 확보하고, 출처 정합성 기준을 충족한 뒤 한국 트랙과 동일한 나라별 독립 트랙으로 재승격 검토
일본 현지 데이터/API 연동	`supplemental/japan_add_function.md`	Yahoo Japan, じゃらん, 楽天トラベル, 食べログ 등 일본 현지 플랫폼 딥링크와 일본어 검색 키워드(FR-JP-005, 목적지별 최소 5개: 金沢観光 / 金沢モデルコース / 金沢カフェ / 金沢穴場 / 金沢ひとり旅 기준)를 일본 데이터 수집 경로 복구 후 검토
애니메이션 성지순례	`supplemental/animation.md`	일본 데이터 수집 경로 복구 후, 작품-장소 관계 유형·공식성·신뢰도·근거 URL을 갖춘 일본 소도시 애니메이션 성지(FR-ANIME-001~003) 데이터를 확보한 뒤 검토
별 관측 조건 기반 여행지 추천	`supplemental/astro_rag_proposal.md`	광해, 월령, 구름량, 대기 안정도 데이터를 안정적으로 확보하고, 일반 소도시 추천과 별도 성공률 계산 기준을 정의한 뒤 검토
치유·웰니스 여정 추천	`supplemental/healing_wellness.md`	온천 테마와 중복되지 않는 회복 활동 데이터, 템플스테이·치유의숲 운영 정보, 한적함 지표를 확보한 뒤 검토
예산 역산 추천	`supplemental/budget_first.md`	교통·숙박·식비·액티비티 비용 추정치와 실시간 가격 미연동 제약을 명확히 한 뒤 검토

4.7 운영·관리·검증 기능

ID	서비스/영역	요구사항 내용	비고
FR-AUTH-001	인증	서비스는 관리자, 관광 운영자, 데이터 제공 기관 등 권한이 필요한 역할에 대해 로그인 기반 인증을 제공해야 한다.	Production 운영 기능
FR-AUTH-002	인가	서비스는 역할별 권한에 따라 데이터 조회, 제안, 승인, 정책 관리 기능 접근을 제한해야 한다.	권한 매트릭스 연계
FR-REVIEW-001	데이터 제안	관광 운영자와 데이터 제공 기관은 소도시·축제·행사 데이터를 제안하거나 제공할 수 있어야 한다.	제안 상태 관리
FR-REVIEW-002	데이터 검토	서비스 관리자는 제안·제공된 데이터를 검토하고 승인, 반려, 수정 요청할 수 있어야 한다.	승인 책임 분리
FR-REVIEW-003	이력 관리	시스템은 데이터 제안, 검토, 승인, 반려, 수정 요청 이력을 추적할 수 있어야 한다.	감사 로그 후보
FR-OPS-001	관리자	운영자는 추천 정책, 노출 기준, 공지사항, 데이터 갱신 상태를 관리할 수 있어야 한다.	운영 관리
FR-OPS-002	검증	추천 또는 데이터 파이프라인 결과에는 출처, 검증 상태, 실패 여부 또는 신뢰도 정보를 표시해야 한다.	추적성/신뢰도
FR-OPS-003	확장성	서비스는 신규 지역, 축제, 관광 상품, 촬영지, 데이터 소스를 추가할 수 있는 구조를 가져야 한다.	데이터 확장

4.8 추천 파이프라인 명세

각 단계별 입력·출력·판단 기준을 정의한다.

단계	입력	판단 기준	출력
1. 조건 수집	사용자 자연어, 국내 지역, 시기(월), 온보딩 선호 프로필, 북마크, 추천 피드백, `여행 일정 추천 받기` 실행 이벤트	필수 조건 충족 여부, 부족 조건 존재 여부	구조화된 여행 조건 객체 또는 추가 질문
2. 테마·진입점 분류	구조화된 조건	LLM 분류 + 룰 기반 fallback	테마 태그 + 진입점 유형
3. 후보 검색	테마, 시기(월), 국내 지역	RAG 유사도 점수, 계절 적합도	후보 소도시 목록과 선정 근거 관광지 후보
4. 후보 필터링·순위	후보 목록 + 혼잡도·Wikipedia 월별 날씨 경향·북마크·개인화 피드백 + 직전 추천 결과	가중치 기반 스코어링, 세션 기반 가중치, `추천 다시 받기` 요청 시 직전 후보 제외 또는 감점	상위 1곳 선정
5. 일정 구성	선정 소도시 1곳 + 일정 유형 + 축제 포함 여부 + 선정 근거 관광지 후보 + DynamoDB 관광지 목록	일별 메인 관광지 1개, 서브 관광지, 장소 타입 균형, 식사 슬롯 분리	1곳 일별 세부 일정 카드
6. Explainability 생성	일정 + 사용자 조건 매칭 근거	FR-REC-003 4요소 기준	추천 이유 텍스트
7. 외부 정보 보강	일정 카드	지도·마커 간 이동 동선·Wikipedia 월별 날씨 경향·대체 일정 알림 팝업·숙소 링크	최종 추천 결과

4.9 관리자 권한 및 RBAC 기능

본 절은 관리자 콘솔의 역할 기반 접근 제어(RBAC) 기능 요구사항을 정의한다. 권한 경계와 매트릭스는 2.6·2.7을 기준으로 하며, 인증 엔드포인트와 토큰·오류 응답 형식의 상세는 API 명세서에서 정의한다. 관리자 기능은 Production 운영 범위로 추진한다.

ID	서비스/영역	요구사항 내용	비고
FR-ADMIN-001	관리자 콘솔 인증 경계	시스템은 `R-ADMIN`, `R-SUPER-ADMIN`, `R-DATA-PROVIDER`, `R-LOCAL-OPERATOR` 중 하나 이상의 활성 관리자 역할을 가진 사용자만 역할에 허용된 관리자 콘솔과 `/admin` 영역 API에 접근하도록 제한해야 한다. 관리자 역할이 없으면 거부한다.	fail-closed
FR-ADMIN-002	서버 측 인가 재검증	시스템은 인증 이후에도 각 관리자 요청마다 역할과 리소스 범위를 서버 데이터로 재검증해야 하며, 요청 본문의 `roles`, `regionIds`, `organizationId`, `reviewerId` 등 권한·소유권 필드를 신뢰하지 않아야 한다.	프론트 클레임 미신뢰
FR-ADMIN-003	역할 Source of Truth	시스템은 최종 권한을 서비스 DB의 활성 역할 할당으로 판단하고, 외부 인증 그룹(Cognito Group 등)은 보조 신호로만 사용해야 한다. 그룹이 있어도 활성 DB 할당이 없거나 정지 상태면 관리자 권한을 부여하지 않는다.	권한 단일 출처
FR-ADMIN-004	담당 지역 범위 제한	시스템은 `R-LOCAL-OPERATOR`의 조회 범위를 활성 지역 할당이 있는 담당 지역(Assigned)으로 제한해야 한다. 할당 범위 밖 지역 요청은 빈 결과로 위장하지 않고 거부한다.	region_id 기준
FR-ADMIN-005	기관 소유 범위 제한	시스템은 `R-DATA-PROVIDER`의 조회·수정 범위를 본인 또는 소속 기관이 제출한 제안(Own)으로 제한해야 한다. 다른 기관 제안, 내부 검토 메모, 전체 운영 지표는 제공하지 않는다.	organization 기준
FR-ADMIN-006	제안 검토·승인 권한	시스템은 데이터 제안의 승인, 수정 요청, 반려 결정을 `R-ADMIN`에게만 허용해야 한다. `R-DATA-PROVIDER`와 `R-LOCAL-OPERATOR`는 제안을 직접 승인·반려할 수 없다.	승인 책임 분리
FR-ADMIN-007	데이터 제안–월간 여행지 게시 분리	시스템은 데이터 제안 승인과 월간 여행지(`이번 달 여행지`) 게시를 분리해야 한다. 제안이 승인되어도 자동 게시하지 않으며, `R-ADMIN`만 월간 여행지 후보를 게시·비노출·만료·재검수 처리할 수 있다.	승인≠게시
FR-ADMIN-008	월간 여행지 유효기간·긴급 비노출	시스템은 게시 유효기간이 지난 월간 여행지를 자동 추천과 일정 생성에서 제외하고, 축제 취소·휴장·교통 중단·안전 변경 시 정기 갱신을 기다리지 않고 비노출 또는 재검수 상태로 전환할 수 있어야 한다.	운영 안전성
FR-ADMIN-009	역할 조합·이해충돌	시스템은 복수 역할 사용자의 권한을 역할별 허용 작업의 합집합으로 계산하되 범위 제한은 역할마다 따로 적용해야 하며, 제안 작성자 본인이 동일 제안을 검토(승인·반려)하는 것은 거부해야 한다.	합집합 + 자기검토 금지
FR-ADMIN-010	역할·지역 할당 관리	시스템은 역할·지역 할당 변경을 고위험 변경 요청으로만 처리해야 한다. `R-ADMIN` 또는 `R-SUPER-ADMIN`이 요청하고, 요청자와 다른 `R-SUPER-ADMIN` 1명이 승인한 경우에만 실행하며 일반 역할 관리 API를 직접 노출하지 않는다.	권한 관리 분리
FR-ADMIN-011	공식 링크·제휴 링크 분리	시스템은 공식 정보 이동(`official_link_clicked`)과 제휴·예약·검색 링크 이동(`partner_link_clicked`)을 이벤트·화면·리포트에서 분리해야 하며, B2G 공익 리포트에는 예약액·수수료·승인 GMV 등 재정 지표를 포함하지 않아야 한다. 목적지 선정·추천 순위·월간 노출에 제휴 수수료 지불 여부를 반영하지 않는다.	공익/제휴 분리
FR-ADMIN-012	지역 운영자 익명·집계 지표	시스템은 `R-LOCAL-OPERATOR`와 기관 공유 리포트에 담당 지역 기준 익명·집계 데이터만 제공해야 한다. 개인 사용자 이벤트, 원시 로그, 세션 단위 행동 경로, 사용자 식별 정보는 제공하지 않으며, 최소 집단 크기 미만 통계는 숨김·병합·기간 확장 처리한다.	프라이버시 보호
FR-ADMIN-013	관리자 감사 로그	시스템은 관리자 로그인·세션 갱신, 권한·범위 거부, 제안 상세 조회, 승인·수정 요청·반려, 월간 여행지 상태 변경, 게시 재시도, 공지·정책 변경과 고위험 요청 생성·승인·거절·역할·지역 변경 실행·대량 게시 실행을 성공·거부·실패 결과와 함께 감사 로그로 남겨야 한다. 성공한 고위험 변경의 상태 전이·실행과 감사 로그는 동일 트랜잭션에서 기록하며, 거부·실패 시도도 원장 변경 없이 별도 결과 행으로 남긴다. 토큰·쿠키·MFA 비밀값·민감 원본·전체 개인정보는 기록하지 않는다.	C4 추적성
FR-ADMIN-014	권한 오류 응답	시스템은 관리자 권한 실패를 표준 오류 코드로 응답해야 한다(401 `UNAUTHENTICATED`/`TOKEN_EXPIRED`, 403 `ADMIN_ACCESS_REQUIRED`/`ROLE_FORBIDDEN`/`SUPER_ADMIN_REQUIRED`/`REGION_SCOPE_FORBIDDEN`/`ORGANIZATION_SCOPE_FORBIDDEN`/`SELF_REVIEW_FORBIDDEN`/`ADMIN_MFA_REQUIRED`/`ADMIN_MFA_TOTP_REQUIRED`/`ADMIN_MFA_ENROLLMENT_REQUIRED`, 404 `NOT_FOUND`, 409 `ROLE_ASSIGNMENT_CONFLICT`/`INVALID_PROPOSAL_STATE`/`SELF_APPROVAL_FORBIDDEN`, 429 `ADMIN_MFA_LOCKED`). 오류 메시지에 타 사용자 ID·기관명·지역 할당·리소스 존재 여부를 노출하지 않는다.	API 명세 연계
FR-ADMIN-015	단일 소도시 검수 원칙	관리자 검수는 추천 요청 1건의 최종 목적지가 소도시 1곳인지 확인해야 하며, 공항·역·대도시 관문은 접근 안내에만 사용하고 추천 소도시의 일정 구성·성과 귀속에 포함하지 않아야 한다. 적합 소도시를 확정할 수 없으면 여러 도시를 섞어 승인하지 않고 추가 정보 요청 또는 추천 보류로 처리한다.	단일 소도시 원칙
FR-ADMIN-016	관리자 접근 재검토	시스템 운영자는 활성 역할·지역 할당 전체를 분기마다 재검토하고 인사 이동·계약 종료·보안 사고 시 수시 재검토해야 한다. 최초 부여자와 다른 최종 확인자가 유지·축소·회수 여부를 승인하며, 불필요한 `R-ADMIN`·`R-SUPER-ADMIN`은 1영업일 이내 회수하고 권한 캐시·활성 세션을 무효화해야 한다. 검토 증적에는 토큰·쿠키·민감 원문을 포함하지 않는다.	Access attestation
FR-ADMIN-017	관리자 Step-up MFA	시스템은 기존 로그인 경로를 변경하지 않고 고위험 요청 승인·거절 시점에만 관리자 도메인 MFA 등록과 최근 5분 이내 TOTP 세션을 요구해야 한다. 일반 admin 읽기·목록 경로, MFA 상태 조회, 고위험 요청 목록 조회·생성은 역할 인증만으로 접근 가능해야 한다. MFA 비밀값은 서버 측 암호화 저장소로 보호하고, TOTP 재사용·연속 실패·복구 코드 사용을 제한하며, MFA 등록·확인·인증·복구 시도를 감사 로그로 남겨야 한다. 복구 코드로 만든 세션은 고위험 요청 승인·거절에 사용할 수 없다.	로그인 소유 경계 유지
FR-ADMIN-018	고위험 변경 2인 승인	시스템은 역할 부여·회수, 지역 부여·회수, 월간 여행지 10~100건 대량 게시를 `pending` 고위험 요청으로 등록해야 한다. 요청자와 다른 `R-SUPER-ADMIN` 1명이 승인하면 대상 변경과 감사 로그를 하나의 트랜잭션으로 실행하고 상태를 `executed`로 전환하며, 거절하면 사유와 함께 `rejected`로 전환해야 한다. 마지막 활성 `R-SUPER-ADMIN` 회수와 자기 요청 결정은 거부한다.	C2 2인 통제
FR-ADMIN-019	권한 승인 탭	admin_web은 `권한 승인` 탭에서 pending 고위험 요청을 로그인 직후 eager loading하고, pending count가 50건 이상이면 `50+` badge로 표시해야 한다. `R-ADMIN`은 목록 조회·요청 생성만 가능하고 승인·거절 버튼을 보지 않으며, `R-SUPER-ADMIN`은 승인·거절 클릭 시점에 backend 403 응답을 기준으로 TOTP MFA 모달을 표시해야 한다. approve/reject 요청 본문에는 TOTP code를 포함하지 않는다.	admin_web UX 정합화

5. API 연동 요구사항

각 플랫폼 API는 역할을 분담하여 지도, 장소, 마커 간 이동 동선, 외부 탐색 링크를 보완 제공한다.

월별 날씨 경향은 API 호출 대상이 아니라 Wikipedia에서 추출·전처리한 추천용 정적 데이터로 관리한다.

클라이언트 측 직접 호출이 불가한 REST API는 딥링크 또는 백엔드 프록시로 대체한다.

Google Maps Platform

장소 상세 · 사진 · 주변 명소 (전 지역)

역할: 플랫폼 공통 지도 + Places API로 실시간 장소 정보

상태: ✓ 클라이언트 직접 연동

Kakao Maps

카카오 지도 · 주변 맛집·숙박 (국내 전용)

역할: 카카오 지도 SDK + Local REST API (맛집 검색)

상태: △ SDK + REST Key 선택

ORS

OpenRouteService

마커 간 이동 경로 · 시간 · 거리 계산

역할: Directions API로 일정 마커 간 경로 폴리라인을 계산하고, Matrix API로 후보 장소 간 이동 시간·거리 비교를 보조

상태: △ 백엔드 프록시 또는 서버 환경 변수 기반 연동

Yahoo Japan

일본 여행 · 숙박 · 맛집 (일본 전용)

역할: Yahoo Travel · じゃらん · 食べログ 딥링크

상태: P5 재검토 보류

5.1 Google Maps Platform

항목	내용
역할	장소 상세 정보, 지도 표시, 주변 명소 검색 (전 지역 공통)
사용 API	Maps JavaScript API, Places API — Text Search / Find Place / Get Details / Nearby Search
연동 방식	JavaScript SDK — 클라이언트 직접 호출 가능
필수 키	Google Cloud API Key (Maps JS API + Places API 활성화 필요)
제공 데이터	리뷰 수, 사진(최대 4장), 운영시간, 현재 영업 여부, 공식 사이트, 주변 명소(반경 3km)
적용 국가	국내 소도시 우선. 일본 소도시는 P5 재검토
CORS 제약	없음 — SDK 방식으로 브라우저에서 직접 사용 가능

5.2 Kakao Maps

항목	내용
역할	국내 소도시 카카오 지도 표시, 주변 맛집·카페·숙박 검색
사용 API	Kakao Maps JavaScript SDK (지도), Kakao Local REST API (주변 검색)
연동 방식	JavaScript SDK (지도): 클라이언트 직접 / Local REST: REST Key 필요
필수 키	Kakao JavaScript App Key (지도 필수), Kakao REST API Key (로컬 검색, 선택)
제공 데이터	카카오 지도, 주변 맛집/카페/숙박 검색 결과, 장소 URL
적용 국가	국내 소도시 전용
CORS 제약	Maps SDK: 없음 / Local REST: 등록 도메인 한정 (로컬 파일 환경 제약) → 오류 시 딥링크 대체

5.3 OpenRouteService

항목	내용
역할	일정 마커 간 이동 경로 표시, 후보 장소 간 이동 시간·거리 비교
사용 API	Directions API, Matrix API
연동 방식	백엔드 프록시 또는 서버 환경 변수 기반 호출. 응답의 geometry/polyline과 duration/distance를 프론트 지도 레이어에 전달
필수 키	OpenRouteService API Key
제공 데이터	경로 geometry, 총 거리, 예상 이동 시간, 후보 지점 간 시간·거리 행렬
적용 국가	PoC/P1은 한국 강원·경북 일정 동선 표시 기준. 일본 트랙은 P5 재검토
제약사항	호출량 제한, 지점 수 제한, 네트워크 실패를 고려해 후보 수 제한, 캐시, 직선 연결 또는 목록 중심 폴백 UI를 적용한다. 지도 렌더링 자체는 Google Maps 또는 Kakao Maps가 담당한다.

5.4 Yahoo Japan (P5 재검토)

⚠ Yahoo Japan Maps JS SDK 지원 중단:

Yahoo Japan Maps JavaScript SDK(Yjans)가 서비스 종료되어 일본 소도시 지도는 Google Maps API로 대체 제공한다. Yahoo Japan REST API는 CORS 제한으로 클라이언트 직접 호출이 불가하며, 일본 데이터 수집 경로 복구 전까지 PoC/P1 기능 요구사항에서 제외한다.

항목	내용
역할	일본 소도시 여행 정보, 숙박·음식점 플랫폼 딥링크 제공
사용 API	Yahoo Japan Local Search REST API (향후), じゃらん/食べログ/楽天トラベル 딥링크 (현재)
연동 방식	P5 재검토: 딥링크 URL 제공 또는 백엔드 프록시를 통한 REST API 연동
필수 키	Yahoo Japan App ID (향후 적용 예정, 현재 입력 항목만 준비)
제공 데이터	Yahoo Japan Maps 링크, Yahoo Travel 링크, じゃらん, 食べログ, 楽天トラベル 링크
추가 딥링크	一休, Booking.com, Agoda, Google Hotels, Retty, Hot Pepper, Instagram 해시태그 검색 링크
적용 국가	일본 소도시 전용(P5 재검토)
지도 대체	Yahoo Japan Maps JS SDK 지원 중단 → Google Maps 대체 제공

5.5 API 연동 현황 요약

플랫폼	역할 특화	지도 SDK	REST API	현재 상태
Google Maps	장소 상세·사진·주변 명소	✓ 지원	✓ 지원	클라이언트 직접 연동
Kakao Maps	맛집·카페·숙박 검색	✓ 지원	△ 조건부	SDK + REST Key 선택
OpenRouteService	마커 간 경로·시간·거리	—	△ Key 필요	백엔드 프록시 권장
Yahoo Japan	일본 여행·숙박·맛집	✗ SDK 중단	✗ CORS	P5 재검토

6. 비기능 요구사항

6.1 성능

ID	요구사항 내용	비고
NFR-001	챗봇 응답은 사용자 입력 후 1.5초 이내에 시작되어야 한다	—
NFR-001B	멀티스텝 에이전트 전체 처리(분류→검색→선정→일정 구성)는 8초 이내를 목표로 한다	단계별 병렬화 고려
NFR-001C	RAG 벡터 검색은 1초 이내에 결과를 반환해야 한다	—
NFR-002	지도 초기 렌더링은 SDK 로드 완료 후 2초 이내에 완료되어야 한다	—
NFR-003	Google Places API 호출은 결과 수신까지 3초 이내를 목표로 한다	—
NFR-004	Wikipedia 월별 날씨 경향 데이터 조회는 2초 이내를 목표로 한다	사전 적재·캐시 활용
NFR-005	API 타임아웃 시 오류 메시지를 표시하고 기본 정보로 폴백한다	폴백 UI 필수

6.2 보안

ID	요구사항 내용	비고
NFR-010	API 키는 클라이언트 로컬 스토리지에 저장하며 외부 서버로 전송하지 않는다	데모 환경 기준
NFR-011	서비스 배포 시 API 키는 이 서비스를 개발·운영하는 백엔드/운영 개발자가 환경 변수 또는 서버 사이드에서 관리한다	배포 환경 적용
NFR-012	Google API 키에 HTTP Referer 제한을 설정하여 무단 사용을 방지한다	—
NFR-013	사용자 대화 로그(채팅 내용 전문)는 저장하지 않으며, 서버나 외부 저장소로 전송하지 않는다. 단, 추천으로 생성된 여행 일정, 사용자가 명시적으로 표현한 선호(온보딩 답변, 좋아요/싫어요, 북마크), 공개 일정 복제 이력은 PoC 단계에서는 브라우저 로컬 스토리지에, Production 단계에서는 로그인 사용자 계정에 저장할 수 있다.	저장 대상 분리
NFR-014	현재 위치는 사용자의 명시적 동의가 있거나 사용자가 기준 위치를 직접 입력한 경우에만 추천 반경 계산에 사용한다. 위치 데이터는 추천 요청 처리 목적에 한정한다.	위치 정보 최소화
NFR-015	사용자는 저장 일정, 북마크, 추천 피드백, 공개 일정 복제 이력 데이터를 조회하고 삭제할 수 있어야 한다.	사용자 통제권
NFR-016	관리자 콘솔과 `/admin` 영역 API는 인증·역할·범위를 확인할 수 없으면 fail-closed로 거부해야 한다.	관리자 인증
NFR-017	서비스 토큰의 역할·기관·지역 클레임은 서버가 DB 활성 할당으로 계산해 발급하며, 클라이언트가 전달한 권한 필드는 신뢰하지 않는다.	토큰 무결성
NFR-018	역할 할당을 정지하면 신규 토큰·세션 갱신에서 관리자 권한이 즉시 제거되어야 하며, 기존 access token은 최대 15분 TTL까지만 유효하다. 즉시 회수가 필요하면 active-session 검증 또는 denylist를 사용한다.	권한 회수
NFR-019	관리자 프론트는 승인된 고정 origin만 credentialed CORS로 허용하고 wildcard origin을 허용하지 않으며, Mock SSO·역할 선택 UI는 개발 모드 전용으로 운영 빌드에서 제거·비활성화한다.	관리자 CORS

6.3 호환성 및 접근성

ID	요구사항 내용	비고
NFR-020	Chrome, Safari, Edge 최신 버전에서 정상 동작해야 한다	—
NFR-021	모바일(iOS/Android) 브라우저에서 사용 가능해야 한다	반응형 레이아웃
NFR-022	화면 너비 375px 이상에서 주요 기능이 모두 사용 가능해야 한다	iPhone SE 기준
NFR-023	다크 모드를 지원해야 한다	—

7. 데이터 요구사항

7.1 필요 데이터 항목

본 절은 저장 구조 설계가 아니라, 로브 서비스가 추천·설명·검증을 수행하기 위해 확보해야 하는 데이터의 종류를 정의한다.

데이터 구분	필요 내용
목적지 기본 정보	소도시명, 국가, 지역, 대표 설명, 주요 이미지, 위치 좌표, 접근 방법
테마 분류 정보	초기 6개 테마와 공예·웰니스·액티비티 등 확장 테마 관련 태그
계절·시기 정보	월별 또는 계절별 추천 적합도, 방문하기 좋은 시기, 비추천 시기와 그 사유
축제·행사 정보	행사명, 개최 지역, 개최 시기, 간단 설명, 공식 또는 참고 링크
혼잡도·대체지 정보	혼잡 가능성이 높은 관광지, 대체 방문지, 대체 시간대, 분산 추천 사유
지도·장소 정보	Google Maps, Kakao Maps, Yahoo Japan 등 외부 플랫폼에서 확인 가능한 지도, 장소 상세, 후속 탐색 링크
Wikipedia 월별 날씨 경향 정보 (추천용)	소도시별 1~12월 날씨 경향(맑음 적합도, 우천·폭설·장마·태풍 경향), 출처 URL, 추출 기준일
추천 근거 정보	추천 이유, 사용자 조건과의 매칭 근거, 참고 출처, 검증 상태, 신뢰도 표시 정보
온보딩 선호 정보	사용자가 선택한 대도시 스타일, 매핑된 기본 테마, 선호 테마 프로필, 재응답 이력
저장 일정·피드백 정보	저장된 추천 일정, 일정 유형, 좋아요/싫어요 피드백, 피드백 대상 소도시와 테마 태그
일정 구성 후보 데이터	소도시 선정 근거 관광지 후보, DynamoDB에서 재인출한 서브 관광지 후보, 장소 타입, 테마 태그, 식사 슬롯 후보
추천 실행 이벤트	추천 요청 시각, 입력 조건, 진입 방식, 필수 조건 충족 여부
재추천 이벤트	직전 추천 결과, 재추천 요청 시각, 유지 조건, 변경 조건, 제외 또는 감점 후보
북마크 데이터	소도시 북마크, 대도시 북마크, 저장 시각, 국가, 지역, 목적지 ID
Cold Start 기준 데이터	관광공사·지자체 추천 루트, 여행 유튜버 루트, 내부 검증 루트, 출처 URL, 신뢰도
세션 개인화 데이터	북마크, 좋아요/싫어요, 목적지 태그, 외부 링크 클릭, 공개 일정 복제 이력
애니메이션 성지 정보 (P5 재검토 보류)	작품명, 장소명, 도시/지역, 국가, 작품과의 관계, 공식 배경지 여부, 작가 고향, 공식 콜라보, 팬 성지 여부, 분위기 유사 태그, 근거 URL, 신뢰도, 방문 가능 여부, 장소 유형 — 일본 데이터 수집 경로 복구 후 확보
일본 목적지 특화 정보 (P5 재검토 보류)	일본어 명칭, 도도부현, 지역권, 여행 스타일 태그, 추천·비추천 계절, 주요 도시 기준 이동시간, 환승 횟수, 가까운 공항, 뚜벅이 가능 여부, JR/지역 교통패스, 일본어 검색 키워드 — 일본 데이터 수집 경로 복구 후 확보
일본 현지 탐색 링크 (P5 재검토 보류)	Yahoo Travel, じゃらん, 楽天トラベル, 一休, Booking.com, Agoda, Google Hotels, 食べログ, Retty, Hot Pepper, Google Maps, Instagram 해시태그 검색 링크 — 일본 데이터 수집 경로 복구 후 확보
지역 문화 체험 정보	체험 유형, 체험 시간, 난이도, 예약 필요 여부, 참여 방식, 우천 적합성, 주변 마을·축제 연계 정보
사계절 액티비티 정보	액티비티 종류, 적합 계절·시기, 눈·파도·수온·월별 날씨 조건, 난이도, 강습 가능 여부, 장비 대여 정보, 주변 휴식 코스
대체 일정 정보	Wikipedia 월별 날씨 경향에 따른 실내·우천 적합 대체 일정, 대체 일정 제공 조건, 알림 팝업 표시 여부
외부 행동 링크	지도 열기, 공식 관광 정보, 예약, 교통, 숙박, 맛집, 현지 플랫폼으로 이어지는 링크
별 관측 후보 데이터	광해 등급, 월령, 구름량, 대기 안정도, 투명도, 관측 시설·예약 링크 등 향후 검토 후보 데이터
치유·웰니스 후보 데이터	회복 활동 유형, 한적함·저자극 정도, 온천·숲 치유·템플스테이·명상 운영 정보 등 향후 검토 후보 데이터
예산 역산 후보 데이터	교통비, 숙박비, 식비, 액티비티 비용 추정치 등 향후 검토 후보 데이터
역할 할당 데이터	사용자 ID, 역할 코드, 소속 기관 ID, 할당 상태(active/suspended/revoked), 효력 기간(valid_from/valid_until), 부여자 ID
지역 할당 데이터	사용자 ID, 표준 지역 ID(region_id), 담당 기관 ID, 할당 상태, 효력 기간, 부여자 ID
월간 여행지 운영 데이터	소도시 ID, 지역 ID, 근거 제안 ID(nullable), 노출 기준 월, 테마 코드, 공식 출처명·링크·최종 확인일, 게시 유효기간, 게시 상태(candidate/scheduled/published/hidden/expired/rejected), 게시 처리자·시각
관리자 감사 로그 데이터	발생 시각, 행위자 ID, 세션 ID, 역할·기관·지역 스냅샷, 작업, 리소스 유형·ID, 처리 결과, 사유 코드, 요청 ID, 변경 전·후 허용 요약(토큰·민감 정보 제외)
공식·제휴 링크 이벤트 데이터	공식 정보 이동(official_link_clicked)과 제휴·예약·검색 링크 이동(partner_link_clicked)을 분리 기록한 이벤트. B2G 리포트에서 재정 지표와 합산하지 않음

7.2 데이터 품질 기준

품질 기준	요구사항
지역 커버리지	PoC/P1은 한국 강원·경북 소도시 데이터를 우선 확보하고, 한국 전국 확장은 P2로 둔다. 일본 소도시 데이터는 수집 경로 복구 후 P5에서 재검토하며, 향후 일본 트랙을 운영할 때는 국가별 추천 흐름을 독립적으로 운영한다.
테마 커버리지	각 테마별로 추천 후보를 구성할 수 있을 만큼 충분한 목적지와 설명 데이터를 확보해야 한다.
최신성	축제, 영업 정보, 혼잡도처럼 변동성이 높은 데이터는 갱신 시점 또는 유효 기간을 함께 관리해야 한다. 월별 날씨 경향은 Wikipedia 추출 기준일과 출처 URL을 함께 관리해야 한다.
출처 추적성	추천 결과에 사용된 주요 데이터는 사용자가 신뢰할 수 있도록 출처 또는 확인 가능한 링크를 제공해야 한다.
설명 가능성	추천 결과는 단순 목록이 아니라 사용자 조건과 어떤 데이터가 매칭되었는지 설명할 수 있어야 한다.
결측 대응	필수 데이터가 부족한 목적지는 추천에서 제외하거나, 부족한 정보와 대체 안내를 명확히 표시해야 한다.
국가별 분리	한국 여행 요청에는 한국 소도시 데이터만 사용한다. 일본 여행 요청에 일본 소도시 데이터만 사용하는 분리 원칙은 일본 트랙 P5 재검토 시 적용한다.

정의 범위:

본 문서는 어떤 데이터가 필요한지를 정의한다.

테이블 구조, 컬렉션 구조, 인덱스, 저장소 선택 등 저장 구조 설계는 별도 설계 문서에서 다룬다.

8. 제약사항 및 가정

8.1 기술적 제약사항

일본 데이터 수집 실패:

일본 소도시·축제·방문 통계·월별 날씨 경향 데이터의 수집 경로 확보와 로컬 검증에 실패하여, 일본 추천 트랙은 후보·축제·방문 통계·날씨 검증 근거가 부족하다. 이에 따라 PoC/P1은 한국 강원·경북 데이터 기반 추천으로 고정하고, 한국 전국 확장은 P2로 둔다. 일본 데이터 기반 추천과 일본 현지 데이터/API 연동(Yahoo Japan·じゃらん 등 현지 플랫폼, 일본어 검색 키워드, 애니메이션 성지순례)은 최하위 우선순위인 P5 재검토 범위로 보류한다. 일본 데이터는 수집 경로와 출처 정합성 기준, 로컬 검증 산출물이 확보되기 전까지 추천 근거로 사용하지 않는다. 수집 경로가 복구되면 한국 트랙과 동일한 나라별 독립 트랙 기준으로 재승격을 검토한다.

Yahoo Japan Maps SDK 지원 중단 (일본 트랙 P5 재검토 시 적용):

Yahoo Japan Maps JavaScript SDK(Yjans)가 지원 중단되어, 향후 일본 트랙을 재개할 경우 일본 소도시 지도는 Google Maps API로 대체 제공한다.

Yahoo Japan REST API CORS:

Local Search 등 REST API는 CORS 제한이 있다. 향후 백엔드 프록시 서버를 통해 연동한다. App ID는 향후 사용을 위해 입력 항목만 준비한다.

Kakao REST API 도메인 제약:

로컬 파일 환경( file:// )에서는 CORS 정책으로 Kakao Local REST API 호출이 제한될 수 있다. 등록된 도메인 환경에서 정상 동작한다.

Google Places API 과금:

Places API는 무료 한도 초과 시 과금이 발생한다. 서비스 규모에 따른 비용 산정이 필요하다.

8.2 가정사항

서비스 초기에는 단일 HTML 파일 기반 데모로 운영하며, API 키는 사용자가 직접 입력한다.
초기 데이터는 정적 파일 또는 외부 API 기반으로 관리하며, 저장 구조는 별도 데이터 설계 단계에서 결정한다. 월별 날씨 경향은 Wikipedia에서 추출·전처리한 정적 데이터로 관리한다.
추천 엔진은 RAG(검색증강) + 멀티스텝 에이전트 구조로 구현하며, LLM API를 활용한다.
자체 모델 학습(sLLM)은 본 범위에서 제외하며, 기성 LLM API + RAG + 에이전트 설계로 품질을 확보한다.
축제·계절 정보는 월·계절 단위로만 관리하여 연도별 갱신 부담과 환각 위험을 최소화한다.
이동 동선은 방문 순서 제안 수준으로 한정하며, 실시간 교통·항공편 최적화는 제외한다.
추천 후보 스코어링과 대체 일정 알림 팝업 분기에는 Wikipedia 기반 월별 날씨 경향 데이터를 사용한다. 월별 경향 외 날씨 데이터는 호출하거나 화면에 표시하지 않는다.
PoC 단계의 개인화 데이터는 브라우저 로컬 스토리지 중심으로 관리하며, Production 단계에서는 로그인 사용자 계정 기반으로 누적·조회·삭제할 수 있도록 확장한다.
위치 반경 추천과 여행 중 즉흥 일정 조정은 PoC 상세 범위에서 제외하고 향후 확장 후보로 관리한다.
관리자 권한의 최종 판단 기준은 로브 서비스 DB의 활성 역할·지역 할당이며, Cognito Group 등 외부 인증 그룹은 보조 신호로만 사용한다. 관리자 프론트의 Mock SSO·역할 선택은 개발 모드 전용이며 운영 빌드에서는 사용하지 않는다.
데이터 제안 승인과 월간 여행지 게시는 분리해 운영하며, 공익(B2G) 성과 리포트와 제휴(B2B) 성과 지표는 같은 사용자 여정 안에서도 분리해 기록·표시한다.
일본 데이터 기반 추천, 일본 현지 데이터/API 연동, 별 관측, 치유·웰니스, 예산 역산 추천은 P5 향후 검토 후보이며, 대표 문서에는 데이터 후보와 검토 조건만 유지한다. 상세 기능 요구사항으로 승격하려면 별도 우선순위 재검토와 데이터 확보 기준을 먼저 확정한다. 특히 일본 항목은 일본 데이터 수집 경로 복구와 로컬 검증 산출물 확보를 재승격 전제로 한다.

9. 예산안·인력 분배·개발 기한

본 섹션은 로브 서비스의 MVP 개발을 위한 예산, 수행 인력, 개발 기간을 정의한다. 금액과 일정은 요구사항 정의 단계의 기준값이며, 외부 API 사용량, 데이터 확보 범위, Production 전환 승인 여부에 따라 조정될 수 있다.

9.1 예산 산정 기준

구분	산정 기준	비용 유형
초기 구축비	기획, UI/UX, 프론트엔드, 백엔드, 데이터 구축, QA 등 개발 착수부터 최종 정리까지 필요한 일회성 작업 비용	고정비 또는 인건비
사용량 기반 비용	AWS, Runpod, OpenAPI, 외부 지도 API처럼 호출량, 저장량, 실행 시간에 따라 달라지는 비용	변동비
운영비	배포 이후 모니터링, 장애 대응, 데이터 갱신, API Key 관리에 필요한 반복 비용	월 운영비
미정 항목	인건비, 외부 API 호출량, 데이터 확보 범위가 확정되지 않은 항목은 `TBD` 로 표시하고 상세 설계 후 확정한다.	추후 산정

9.2 예산안

예산 구분	예산	포함 항목	반영 방향	비고
기획·PM	TBD	요구사항 정리, 일정 관리, 이해관계자 조율	문서화 및 일정 관리 비용으로 분리	인건비 산정 필요
UI/UX	TBD	화면 설계, 사용자 흐름, 디자인 시스템	데모와 MVP 범위를 구분	인건비 산정 필요
프론트엔드	TBD	챗봇 UI, 지도, 결과 화면, 반응형 구현	사용자-facing 개발 비용으로 분리	인건비 산정 필요
백엔드/API	TBD	RAG 파이프라인, 외부 API 프록시, 인증·인가	서버 구현 및 API 연동 비용으로 분리	인건비 산정 필요
데이터 구축	TBD	소도시, 축제, 장소, 출처 데이터 정리	초기 구축과 정기 갱신 비용 구분	데이터 범위 확정 후 산정
AI 실행 (Runpod)	$300	GPU 실행, 모델 서빙, 배치 작업	AI 실행 사용량 기반 변동비로 정의	Runpod 사용량 기준 관리
LLM/API 사용 (OpenAPI)	$300	LLM API, 임베딩, 벡터 검색	LLM·임베딩 사용량 기반 변동비로 정의	OpenAPI 사용량 기준 관리
외부 API	TBD	Google Maps, Kakao Maps, OpenRouteService 등	무료 한도와 과금 전환 조건 명시	호출량 확정 후 산정
인프라	300,000원	AWS 호스팅, DB, 스토리지, 모니터링	MVP와 운영 전환 비용 분리	AWS 예산
QA/검증	TBD	기능 테스트, 접근 제어, 데이터 품질 검증	릴리스 전 필수 검증 비용으로 정의	인건비 산정 필요
운영·유지보수	TBD	장애 대응, 데이터 갱신, API Key 관리	월별 운영 비용으로 정의	운영 범위 확정 후 산정
확정 예산 합계	300,000원 + $600	AWS 300,000원, Runpod $300, OpenAPI $300	통화별 확정 예산 합계	원화와 달러 예산을 분리 관리

9.3 인력 역할 정의

역할	주요 책임	MVP 기준 투입
PM/기획	범위 관리, 요구사항 정리, 일정·리스크 관리	1명
UI/UX 디자이너	사용자 흐름, 화면 설계, 디자인 가이드	1명
프론트엔드 개발자	챗봇 UI, 추천 결과, 지도·월별 날씨 경향 화면 구현	1~2명
백엔드 개발자	API, 인증·인가, 외부 API 프록시, API Key 환경 변수 관리, 운영 기능	1~2명
AI/RAG 엔지니어	추천 파이프라인, RAG, 프롬프트, 평가 기준	1명
데이터 담당자	목적지·축제 데이터 수집, 정제, 출처 관리	1명
QA 담당자	테스트 계획, 기능 검증, 권한·데이터 품질 검증	0.5~1명
운영 담당자	배포, 모니터링, API Key 교체·만료 대응, 장애 대응	0.5~1명

역할 구분:

본 절의 PM, 개발자, QA 등은 프로젝트 수행 인력 역할이며, 2. 이해관계자의 R-USER, R-LOCAL-OPERATOR, R-ADMIN 등 서비스 권한 Role ID와 구분한다.

9.4 단계별 인력 분배

구분	기간	핵심 투입	보조 투입	목표
M1 PoC 완료	2026-05-22 ~ 2026-06-12	PM/기획, 데이터, DB, AI/RAG, 백엔드, 프론트엔드, UI/UX	QA	요구사항·WBS·기획서·데이터 수집·DB 설계·데이터 조회·AI 전처리·모델·시스템 아키텍처·화면/UX 기초 설계 완료
M2 중간 발표	2026-06-13 ~ 2026-06-16	PM/기획, UI/UX, 프론트엔드, AI/RAG	백엔드, QA	화면설계서 확정·시스템 구성도·중간 발표 PT·발표 QA 완료
M3 Production	2026-06-17 ~ 2026-07-16	프론트엔드, 백엔드, AI/RAG, 인프라, QA	PM/기획, 데이터, 운영 담당자	LLM 서비스·RAG 파이프라인·AWS 배포·실서비스화·통합 테스트·최종 산출물 제출 완료

9.5 개발 기한 및 마일스톤

9.5.1 마일스톤 요약

마일스톤	마감일	범위	주요 산출물
M1 PoC 완료	2026-06-12	Sprint 1~3	요구사항 정의서, WBS, 프로젝트 기획서, 수집 데이터, DB 설계문서, 데이터 조회 프로그램, AI 전처리·학습 결과, 시스템 아키텍처, 화면/UX 기초 설계
M2 중간 발표	2026-06-16	Sprint 4	화면설계서 확정본, 시스템 구성도, 중간 발표 PT, 중간 발표 QA
M3 Production	2026-07-16	Sprint 5~9	LLM 활용 소프트웨어, AWS 배포 환경, LLM 연동 웹앱, 테스트 계획·결과 보고서, 웹 테스트 보고서, 최종 발표 PT, 시연 영상, 소스코드, 최종 제출물

9.5.2 스프린트별 개발 기한

Sprint	기간	마일스톤	주요 목표
Sprint 1	2026-05-22 ~ 2026-05-31	M1	요구사항 정의서, WBS, 협업 환경, 프로젝트 기획·명세 초안
Sprint 2	2026-06-01 ~ 2026-06-07	M1	기획서, 데이터 수집, DB 설계, 데이터 조회 프로그램, Agent·Backend 기반 작업
Sprint 3	2026-06-08 ~ 2026-06-12	M1	AI 전처리·학습·모델, RAG 검증, 시스템 아키텍처, 화면/UX 기초 설계, PoC 완료
Sprint 4	2026-06-13 ~ 2026-06-16	M2	화면설계서 확정본, 시스템 구성도, 중간 발표 PT, 발표 QA
Sprint 5	2026-06-17 ~ 2026-06-21	M3	LLM 선정, RAG 파이프라인, 프롬프트 최적화, 핵심 웹앱 기능 구현
Sprint 6	2026-06-22 ~ 2026-06-28	M3	AWS 배포 환경, LLM 연동 웹앱 실서비스화, 운영·관리 기능 구현, 단위 테스트
Sprint 7	2026-06-29 ~ 2026-07-05	M3	테스트 계획서, 통합 테스트, 모델링 테스트 보고서
Sprint 8	2026-07-06 ~ 2026-07-12	M3	웹 테스트 보고서, 최종 발표 PT, 시연 영상, 소스코드 정리, 운영 가이드
Sprint 9	2026-07-13 ~ 2026-07-16	M3	최종 발표·시연, 데모 QA, 피드백 반영, 산출물 최종 제출

9.6 예산·인력·일정 관리 원칙

AWS 인프라 예산은 300,000원으로 관리하고, Runpod과 OpenAPI는 각각 $300 한도로 분리 관리한다.
M1 PoC는 기획·데이터·DB·AI 모델·시스템 아키텍처와 화면/UX 기초 설계 산출물 완료를 목표로 한다.
M2 중간 발표는 PoC의 마지막 항목이 아니라 별도 마일스톤으로 관리한다.
2026-06-16 중간 발표에서 Sprint 5~9 Production 범위와 리스크를 확정한다.
M3 Production은 2026-07-16 최종 발표·피드백 반영·산출물 최종 제출까지 완료하는 일정으로 관리한다.
외부 API Key 승인, 데이터 확보, RAG 품질 검증, 배포 리스크가 지연되면 해당 Sprint 안에서 우선순위 기능을 조정한다.
예산 사용량은 AWS 인프라, Runpod AI 실행, OpenAPI LLM/API, 외부 API 호출량을 중심으로 주기적으로 확인한다.

10. 변경 이력

버전	날짜	작성자	변경 내용
v3.0	2026-07-02	Codex	관리자 MFA 필수 범위를 고위험 승인·거절 시점으로 정정하고 admin_web `권한 승인` 탭, pending badge, decision-time TOTP 모달 요구사항 추가
v2.9	2026-06-30	Codex	`R-SUPER-ADMIN` 역할 모델, 역할·지역·대량 게시 고위험 변경 2인 승인, 최근 TOTP 재인증, C4 감사 로그 커버리지 요구사항 추가
v2.8	2026-06-30	Codex	기존 로그인 경로를 변경하지 않는 관리자 Step-up MFA 요구사항과 권한 매트릭스 행 추가
v2.7	2026-06-30	Codex	분기별 관리자 역할·지역 접근 재검토, 독립 확인, 회수 기한, 캐시·세션 무효화 요구사항 추가
v2.6	2026-06-30	Codex	관리자 권한 매트릭스에 감사 로그 조회 행을 추가해 관리자 콘솔 audit 탭 권한과 정합화
v2.5	2026-06-30	Codex	관리자 권한 오류 응답의 401 코드명을 API 명세와 동일하게 `UNAUTHENTICATED`로 통일
v2.4	2026-06-25	Codex	날씨 정책 확정: Wikipedia 추출 월별 날씨 경향 데이터와 월별 기상 영향 발생 시 대체 일정 추가 알림 팝업 요구사항 반영
v2.3	2026-06-25	Codex	지도 마커 간 이동 동선 표시 요구사항 추가: OpenRouteService Directions API 기반 경로 폴리라인, Matrix API 기반 후보 장소 간 이동 시간·거리 비교, API Key 백엔드 관리와 폴백 UI 기준 반영
v2.2	2026-06-25	Codex	최종 기획서 기준으로 요구사항 범위를 재정렬: PoC/P1을 한국 강원·경북, 일정 길이를 당일치기~2박3일로 고정하고 위치 반경·즉흥 일정 조정·개인화 랭킹을 핵심 범위에서 제외. 메인 관광지·서브 관광지·식사 슬롯·사용자 일정 수정 원칙을 추가
v2.1	2026-06-25	로브 기획팀	관리자 RBAC 명세 반영: §2.6 RBAC 권한 경계와 §2.7 관리자 권한 매트릭스, §4.9 관리자 권한 및 RBAC 기능(FR-ADMIN-001~015), 관리자 인증·토큰·회수·CORS 비기능 요구사항(NFR-016~019), 역할·지역·월간 여행지·감사 로그·공식/제휴 링크 분리 데이터 항목 추가
v2.0	2026-06-25	로브 기획팀	일본 데이터 수집 실패 리스크를 반영해 프로젝트 기획서(00_project_plan v0.11)와 동기화. 일본 데이터 기반 추천·일본 현지 데이터/API 연동(일본어 검색 키워드 FR-JP-005, 애니메이션 성지순례 FR-ANIME-001~003, 일본 현지 탐색 링크 FR-API-006)을 최하위 우선순위 P5 재검토 범위로 강등하고, PoC/P1을 한국 강원·경북 데이터 기반 추천으로 고정, 한국 전국 확장을 P2로 정리. 양국 공통 FR의 일본 부분을 P5 보류로 표기하고 §8에 일본 데이터 수집 실패 제약 추가
v1.9	2026-06-23	로브 기획팀	01 요구사항 보조 문서 백업·인덱스화, P1~P5 보조 문서 반영 기준, P5 향후 검토 후보, 별 관측 후보 데이터, 대표 문서 동기화 기준 반영
v1.8	2026-06-01	로브 기획팀	여행 일정 추천 받기 CTA와 추천 다시 받기 요구사항, 재추천 이벤트 데이터 정의 추가
v1.7	2026-06-01	로브 기획팀	GitHub Projects Lovv WBS 기준으로 개발 기한, M1/M2/M3 마일스톤, Sprint 1~9 일정, Production 종료일을 정합화
v1.6	2026-06-01	로브 기획팀	개인화 확장 요구사항 반영: 북마크, 방문 기록, cold start, 소도시 랭킹, PoC ML 랭킹, Production 개인화 데이터 누적, 개인화 랭킹 1차 운영, 위치 반경 추천, 여행 중 즉흥 일정 조정 추가
v1.5	2026-05-29	로브 기획팀	개인화 온보딩, 지도 마커 진입, 소도시 1곳 집중 일정, 월별 날씨 경향 기반 추천, 숙소 검색 링크 정책, 추천 파이프라인 명세 반영
v1.4.2	2026-05-27	로브 기획팀	인프라 300,000원 예산을 복원하고 Runpod AI 실행 $300, OpenAPI LLM/API $300으로 달러 예산 분리
v1.4	2026-05-27	로브 기획팀	Runpod $300과 OpenAPI $300을 AI 실행·LLM 통합 예산으로 관리하도록 예산안과 관리 원칙 수정
v1.3	2026-05-27	로브 기획팀	지역 문화 체험, 치유·웰니스, 사계절 액티비티 확장 테마와 예산 역산·날씨 기반 직접 질의 진입점 반영
v1.2	2026-05-27	로브 기획팀	예산안, 인력 분배, 개발 기한 섹션 추가. PoC/Production 일정 기준 반영
v1.1	2026-05-26	로브 기획팀	6개 테마 여정 추천 도입, 계절·축제 연동 추가, RAG·멀티스텝 에이전트 기반으로 추천 엔진 정의 (규칙기반→RAG 전환), 소도시 필요 데이터 항목에 테마·계절·축제·추천 근거 정보 추가
v1.0	2026-05-26	로브 기획팀	최초 작성 — 기능 요구사항, API 연동 명세, 비기능 요구사항 초안