로브 (Lovv) 데이터 수집 계획서

문서 버전: v0.10

문서 상태: 검토 중 (Review)

기준 문서: 요구사항 명세서 v1.7

상세 문서: 한국 데이터 취득 상세 계획서.pdf, 일본 데이터 취득 상세 계획서.pdf, 기후 데이터 정량 정합성 검토

1. 문서 개요

1.1 목적

본 문서는 지역 여행 추천 서비스인 로브(Lovv)의 추천 품질과 신뢰성을 확보하기 위해 필요한 한국 및 일본의 도시·관광지·축제 데이터를 한 번에 취득하기 위한 범위, 데이터 소스, 검증 방식, 저장 구조를 정의한다.

세부 국가별 취득 기준은 다음 문서에 분리하여 관리한다.

1.2 수집 원칙

• 전체 취득: City, Attraction, Festival의 정의된 필드와 국가별 방문·관광 통계 보조 데이터는 최초 수집 대상에 포함한다.
• 우선 취득 범위: 한국은 강원과 경북의 40개 도시를 우선적으로 취득한 뒤 일본의 관동 지역 지자체를 수집한다.
• 한국 실제 검증 범위: 한국은 data/KR/cities.json, data/KR/attractions.json, data/KR/festivals.json, data/KR/visitor_statistics.json 형태의 로컬 검증 산출물을 기준으로 S3 Raw 적재 전 품질을 확인한다.
• 일본 검증 산출물: 일본은 관동 지역 지자체 우선 수집 결과를 data/JP/*.json 형태의 로컬 검증 산출물로 확인한 뒤 S3 Raw 적재 대상으로 확정한다.
• 공식 출처 우선: 관광지 및 축제 정보는 양국 공식 관광 데이터, 공공데이터, 지자체 공식 사이트, 공식 관광 포털을 우선한다.
• 최신성 관리: 운영시간, 운영기간, 입장료, 축제 기간처럼 변경 가능성이 높은 데이터는 확인일과 출처를 함께 저장한다.
• 일관성 유지: 서로 다른 출처의 데이터를 통합할 때 명칭, 행정구역 코드, 좌표, 날짜 포맷의 매핑 기준을 통일한다.
• 출처 추적: 모든 자동 수집 데이터는 source_name, source_url, collected_at, data_confidence를 기록한다.

2. 데이터 수집 계획 명세

2.1 프로젝트 주제

로브(Lovv)는 대도시 편중 현상(오버투어리즘)을 완화하고 여행자에게 덜 알려진 한국(시/군/구 단위) 및 일본(시/정/촌/구 단위)의 매력적인 지역과 그에 최적화된 여행 일정 및 문화 콘텐츠를 추천하는 서비스이다.

본 계획서는 한국과 일본의 지역 기반 추천을 위해 도시, 관광지, 축제 데이터를 공통 구조로 취득하고 국가별 출처 차이를 매핑하는 방안을 다룬다.

2.2 데이터 모델

추천 DB는 한국·일본 상세 취득 문서의 목표 모델을 합쳐 다음 관계를 기준으로 구축한다.

2.2.1 국가별 데이터 모델 적용

이 공통 관계는 한국과 일본 수집 결과에 동일하게 적용한다. 국가별 차이는 상위 행정 단위의 명칭, City 식별자 체계, 관광지·축제의 1차 출처, 방문·관광 통계의 집계 단위만 다르게 매핑한다.

2.3 City 수집 항목

City는 추천의 기준 지역이다. 한국은 도의 간략 정보와 산하 시·군·구 목록을 먼저 취득하고, 일본은 도도부현의 간략 정보와 산하 시·정·촌·구 목록을 먼저 취득한다. 실제 도시 상세 정보 크롤링은 이 산하 도시 목록에 포함된 City만 대상으로 한다.

한국 실제 수집 기준에서는 강원과 경북의 40개 도시를 KR-{도_코드}-{CITY_EN} 형식의 city_id로 관리한다. 예시는 KR-42-GANGNEUNG, KR-47-ANDONG이며, 광역 단위는 prefecture_id로 연결한다. Wikipedia 기후 표는 climate_table로 보존하고 자동 취득 실패 시 needs_review로 관리한다.

2.4 Attraction 수집 항목

Attraction은 일정 카드와 추천 결과 상세 화면의 핵심 소재로 사용한다. 한국은 TourAPI 4.0(KorService2) 기준 강원·경북 관광지 3,709건을 실제 수집 및 명세 확인 범위로 둔다.

2.5 Festival 수집 항목

Festival은 월별 추천과 계절성 추천의 주요 근거로 사용한다. 한국은 TourAPI 4.0(KorService2) 기준 강원·경북 축제 106건을 실제 수집 및 명세 확인 범위로 둔다.

2.6 데이터 출처

2.6.1 한국 데이터 출처

2.6.2 일본 데이터 출처

VisitorStatistics 그래뉼래리티 주의: 위 JNTO 訪日外客統計은 전국·국적 단위, 旅行・観光消費動向調査는 지방블록(10개 광역권)·일본인 국내분 단위로 집계된 표본 추계치다. 둘 다 최소 단위가 City(시/정/촌)보다 상위라 City 엔티티와 직접 조인할 수 없다. 따라서 City별 방문량·혼잡도의 1차 소스가 아니라, (1) 권역 가중치·월별 시즌 보정 계수, (2) 오버투어리즘·시장규모 거시 근거, (3) 도도부현·시정촌 통계로 채운 City 값의 권역 합계 검증(calibration)에 사용한다. 인바운드(한국인 등)는 JNTO, 일본인 국내 시즌성은 旅行・観光消費動向調査로 구분해 적재한다. 다만 宿泊旅行統計調査의 광역시정촌(130구분)은 위 소스 중 City에 가장 근접한 단위로, 외국인 연박·외국인 비중을 City 매핑·혼잡도 보정에 활용할 수 있다(개별 시정촌이 아닌 130구분 집계라는 점은 유의).

출처: JNTO 訪日外客統計(국적/월별) · 일본관광청 旅行・観光消費動向調査 · 宿泊旅行統計調査 · 인바운드 소비동향조사. 확인일 2026-06-22.

3. 데이터 취득 파이프라인

3.1 처리 흐름

자동 수집
        ↓
        로컬 검증 산출물 생성
        ↓
        JSON 직렬화
        ↓
        S3 Raw Bucket 적재
        ↓
        Raw 보관 기간 경과
        ↓
        Lambda 배치 전처리
        ↓
        취득 상태 분류
        ↓
        공식 사이트 확인 / Web Search Worker
        ↓
        수동 검수
        ↓
        정규화 DB 적재

정의된 모든 필드가 JSON 원본으로 저장되도록 시도한다. 한국은 실제 수집 검증 단계에서 data/KR/*.json 로컬 산출물로 City, Attraction, Festival, 방문객 통계의 구조와 수량을 먼저 확인한다. 일본은 관동 지역 지자체 우선 수집 결과를 data/JP/*.json 로컬 산출물로 확인하고 City, Attraction, Festival, 관광 통계의 구조를 검증한다. 이후 수집 결과는 엔티티 유형과 출처별 JSON 문서로 직렬화한 뒤 S3 Raw Bucket에 적재한다. Raw 데이터는 재사용과 재처리를 위해 일정 기간 누적 보관하고, 보관 기간 또는 배치 기준이 충족되면 Lambda가 해당 Prefix의 JSON 원본을 읽어 전처리한 뒤 DynamoDB에 적재한다. 운영시간, 운영기간, 입장료, 사진, 축제 기간처럼 출처별 표현 차이가 큰 값도 최초 수집 대상에 포함하며, 자동 수집 실패 시 같은 파이프라인 안에서 공식 확인 또는 수동 검수로 채운다.

3.2 취득 상태 관리

3.3 원본 및 정규화 저장

4. 데이터 품질 정합성 관리 방법

수집된 데이터의 품질 및 매핑 신뢰성을 보장하기 위해 다음 검증 기준을 적용한다.

4.1 기후 데이터 정량 정합성·활용 지표

날씨(기후) 데이터는 Wikipedia 기후 표를 기준값으로 취득하고, 한국 기상청·일본 JMA와 정량 지표로 정합성을 맞춘 뒤, 월별 여행 적합도 점수로 추천에 활용한다. 아래 파라미터는 권고 기본값이며 표본 데이터로 보정해 확정한다(신뢰도: 중). 세부 산식과 검수 스키마는 supplemental/weather_consistency_quant_review.md를 따른다.

4.1.1 정규화 기준 (한·일 공통)

m in {1..12}, Wikipedia 취득값 *_wiki, 공식(기상청/JMA) 값 *_off.

4.1.2 정합성 지표 및 판정

• 월별 오차: eT_m = |t_avg_wiki,m − t_avg_off,m|(°C), eP_m = |precip_wiki,m − precip_off,m| / max(precip_off,m, 5mm)
• 연간 집계: MAE_T = (1/12)Σ eT_m, MAPE_P = (1/12)Σ eP_m
• 정합성 점수: ConsistencyScore = 100 × (1 − (0.6·min(MAE_T/3.0, 1) + 0.4·min(MAPE_P/0.40, 1)))

검수 메타데이터에 MAE_T, MAPE_P, ConsistencyScore, status, d_station_km, base_source를 추가한다.

4.1.3 월별 여행 적합도(활용)

• 기온 쾌적도: T_score_m = max(0, 1 − |t_avg_m − 20| / 15)
• 강수 패널티: P_score_m = max(0, 1 − precip_m / 300)
• 월별 적합도: ComfortScore_m = 100 × (0.6·T_score_m + 0.4·P_score_m)
• (선택) 폭염·한파·강설일수 extreme_days_m 패널티: × (1 − 0.3·min(extreme_days_m/10, 1))

recommended_months는 ComfortScore_m ≥ 70인 월(없으면 상위 3개월)로 산출하며, 한·일 동일 단위·동일 산식이므로 국가 무관 비교가 가능하다. 이 점수는 DB 설계의 SEASONAL_FIT/recommended_months 근거와 연결된다.

4.1.4 일본인 국내여행 베이스라인(추천 로직 보정 입력)

旅行・観光消費動向調査(일본인 국내여행)는 추천 결과의 기본값·혼잡 보정에 쓰는 시장 베이스라인을 제공한다. 인바운드(한국인 등)와 별개로, 일본 목적지 자체의 수요·체류 구조를 나타낸다.

• 여행 길이 기본값. 2025년 국내 숙박여행 연인원의 50.9%가 1박, 26.9%가 2박으로 1~2박이 77.8%다(3박 이상 22%). 일정 생성의 기본 길이를 1~2박으로 두는 것이 시장 실태와 부합하며, Lovv의 "소도시 1곳·1~3일" 원칙과 정합한다.
• 권역 수요·혼잡 베이스라인(순유입배율 = 목적지÷거주지 여행자수). 오키나와 3.41, 호쿠리쿠신에쓰 1.40, 홋카이도 1.27, 도호쿠 1.22, 시코쿠 1.16, 규슈 1.12는 '관광 유치권', 간토 0.74는 '송출권'이다. 이 배율은 권역별 방문 수요 가중치·혼잡 보정 계수로 활용하며, 한국 인바운드의 규슈·홋카이도 과대지수(§ 92_B2C 5.1.1)와 같은 방향이다.

한계: 권역(지방블록 10구분)·일본인 국내 기준 추계치다. City 단위 보정에는 숙박여행통계(130구분)·시정촌 통계와 병용한다.

출처: 일본관광청 旅行・観光消費動向調査 2025년 확보 — 체류일 분포(T04), 거주지·목적지 여행자수(T03), 여행 빈도(T17). 확인일 2026-06-22.

5. 법적 요소 검토

공공데이터 및 오픈 백과사전을 활용하는 만큼 기본 라이선스 기준에 근거하여 법적 의무 사항을 준수한다.

• 위키피디아 라이선스 준수: 위키피디아 한국어/일본어 버전의 텍스트 콘텐츠는 CC BY-SA 라이선스 조건에 따라 출처와 원문 링크를 기록한다.
• 한국 공공데이터 활용 조건 준수: 한국관광공사 TourAPI, 대한민국구석구석, 공공데이터포털, 지자체 데이터는 공공누리 유형과 API 이용 조건을 확인한다.
• 일본 공식·상업 플랫폼 제약 준수: JNTO, JTA, 지자체 관광 사이트, Yahoo Japan, じゃらん, 楽天トラベル, 食べログ 등은 이용약관과 크롤링 허용 범위를 확인한다.
• 사진 사용 조건 확인: 사진은 저작권 위험이 크므로 자동 수집 값이 있더라도 사용 가능 조건을 확인하고, 불명확하면 needs_review 또는 blocked로 관리한다.
• 변동 정보 표시: 운영시간, 입장료, 축제 기간은 변경 가능성이 높으므로 서비스 화면에 "확인일 기준" 문구를 표시한다.

6. 수집 정책 및 제외 범위

• 수집 주기: City 기본 정보는 연 1회 이상, 운영시간·입장료·축제 기간은 최신성 상태에 따라 재확인한다.
• Raw 재사용: 수집 JSON은 S3 Raw Bucket에 일정 기간 보관하여 재처리, 검수 기준 변경, DynamoDB 재적재에 재사용한다.
• 전처리 실행: Raw 데이터가 일정 기간 또는 처리 기준만큼 누적되면 Lambda 배치 전처리를 실행하고 DynamoDB에 정규화 결과를 적재한다.
• 실시간 응답 보강: DB 값이 없거나 오래된 경우 Web Search Worker가 공식 사이트 또는 공공 관광 페이지를 확인한다.
• 상업 플랫폼 데이터: 숙박·맛집 플랫폼 데이터는 직접 저장보다 검색 딥링크 제공을 우선한다.
• 본문 원문 저장 제한: 외부 설명문은 원문 전체 복제가 아니라 내부 요약문으로 저장한다.

7. 본 문서 반영 이력

v0.4에서는 City 취득 범위와 원본 저장 방식을 정리했다. 한국은 도의 간략 정보와 산하 도시 목록, 일본은 도도부현의 간략 정보와 산하 도시 목록을 먼저 확보하고, 실제 Wikipedia 크롤링은 해당 산하 도시 목록에 포함된 City만 대상으로 수행한다. 취득 결과는 JSON 문서로 저장한 뒤 S3 Raw Bucket에 일정 기간 누적 보관하고, Lambda 배치 전처리 후 DynamoDB에 정규화 결과를 적재한다. 기후 정보는 양국 모두 Wikipedia 취득값을 기준으로 하되 한국은 기상청, 일본은 일본기상청(JMA) 자료와 비교해 정합성을 확인한다.

v0.5에서는 한국 실제 수집 결과를 반영했다. 강원과 경북의 40개 City는 KR-{도_코드}-{CITY_EN} 형식으로 관리하며, 관광지는 TourAPI 4.0 기준 3,709건, 축제는 106건을 실제 수집 및 명세 확인 범위로 둔다. DataLabService 기반 월별 방문객 통계는 City 보조 지표와 월별 추천 근거로 활용한다. data/KR/*.json은 최종 DB가 아니라 S3 Raw Bucket 적재 전 로컬 검증 산출물로 정의한다.

v0.6에서는 방문·관광 통계를 VisitorStatistics 보조 데이터로 명시하고, 데이터 모델과 전처리 연계 기준에 반영했다. 일본은 관동 지역 지자체를 우선 수집 범위로 두고 data/JP/*.json 로컬 검증 산출물을 S3 Raw Bucket 적재 전 검증 기준으로 사용한다.

v0.8에서는 일본 VisitorStatistics의 공식 통계 소스를 구체화했다. JNTO 訪日外客統計(국적/월별)은 인바운드 시즌성·시장규모를, 일본관광청 旅行・観光消費動向調査는 지방블록별 일본인 국내여행 규모·소비·시즌성을 제공한다. 두 소스 모두 최소 단위가 City보다 상위(전국·국적, 지방블록·일본인 국내분)인 표본 추계치이므로 City별 방문량의 1차 소스가 아니라 권역 가중치·시즌 보정·거시 근거·권역 합계 검증 용도로 한정해 사용한다.