Phase 3 · 통합 플랫폼 기획서 엔지니어 착수용

실행 요약(Executive Summary)

핵심 의사결정 (7)

무엇을 먼저 만드나 (MVP 범위)

성공의 정의 (KPI 목표)

일정·인원·비용 한눈 요약

인원 코어: PM 1, FE 2, BE 2, 디자인 1(외주/AI 보강), QA 1. 기획은 본 문서가 대체. 월 인프라(호스팅/CDN/DB/모니터링)는 12장 산정표 참조 - 단일 코드베이스로 운영비 통합 절감.

최상위 리스크 & 대응 (5)

핵심 가정

• 고향사랑e음 API 연동이 유지되고, 아이러브고향의 e음 연동 백엔드를 재사용 가능하다.
• 놀고팜의 실물 공급(체험·숙소·캠핑·스토어)과 '바로결제' 트랜잭션을 답례품 카탈로그에 연결할 수 있다.
• 현행 법령(연 한도 2,000만원, 10만 이하 실질 전액·초과 16.5%·10년 이월, 답례품 30%룰, 공급주체=지자체, 개인·본인 주소지 외 기부)이 사업 기간 중 유효하다.
• 민간플랫폼 시장(2025년 1,515억, 민간 26.4%) 성장세가 지속된다.
• AI 에이전트 병렬 개발로 디자이너·기획자 공백을 보완하고 MVP를 ~14주 내 출시할 수 있다.
• 핵심 지자체 우선 입점으로 론칭 시점 최소 카탈로그를 확보한다.

1. PRD — 제품 요구사항 정의

1.1 문제 정의 (Why now)

현 자산은 3개 도메인으로 찢어진 구조다: 놀고팜(nolgofarm.com, 예약), 아이러브고향(ilovegohyang.nolgofarm.com, 기부), AI추천(ilovegohyangai.org). 사용자는 기부와 체험을 오가며 도메인·세션·장바구니가 모두 끊긴다. Phase2 평가(총 100점)에서 놀고팜 40.2점, 아이러브고향 34.2점으로, 통합 1위 웰로(85.1)·기부깊이 1위 위기브(76.6)에 압도적으로 뒤진다.

낮은 점수의 구체 근거: 캠핑 카탈로그 245페이지가 무가격·리뷰 0, 스토어에 productOld 잔존·0원 가격 노출, Pretendard 폰트 OTS 디코드 실패, 홈 '팝업존' placeholder가 라이브 노출, URL에 jsessionid/productOld 파라미터 노출, alt 다수 누락·h1 다중·canonical/JSON-LD 부재, 모바일 분기형(m. 별도)으로 줌 차단. 기부 측은 답례품 분류·필터·모금 현황·세액공제 계산이 전무하여 기부깊이 95점 위기브와 격차가 60점에 달한다.

1.2 타깃 사용자 페르소나 (3종)

1.3 핵심 가치제안 & 차별점

1.4 성공지표 KPI

1.5 범위 In/Out (MVP)

1.6 핵심 가정 & 제약

• 제도 제약(법령): 개인만·본인 주소지 외 기부, 연 한도 2,000만원(2025.1.1~), 세액공제 10만 이하 전액(100/110+지방세=실질 100%)·초과분 16.5%·미공제 10년 이월, 답례품은 기부액 30% 이내(답례품 가격이 최소 기부금을 결정), 공급주체는 지자체. 기부접수·본인확인·세액공제 영수증은 반드시 고향사랑e음(행안부/한국지역정보개발원) 공공시스템 경유.
• 비즈 가정: 시장 2025년 1,515억(민간 비중 26.4%), 지자체별 개별 입점 계약·수수료 5~10%. 초기 파일럿 5~10개 지자체로 검증 후 확장.
• 기술 제약: e음 API 응답 지연·점검창이 결제 가용성 상한. 레거시 jsessionid·서버세션·productOld·0원 가격을 마이그레이션 시 정리해야 하며, Pretendard OTS 디코드 실패를 Variable 폰트로 교체 전제.
• 조직 제약: 디자이너·기획자 부재 → 본 PRD와 디자인시스템 정의가 곧 착수 근거. 의사결정 단일화 필요.
• 핵심 가설: "기부 답례품을 체험 바우처로 제공하면 크로스 전환(기부↔예약)이 발생하여 객단가·GMV가 동반 상승한다" - 출시+6M 크로스 전환율 15%로 검증.

2. 통합 정보구조(IA)

2.1 단일 도메인 사이트맵 (GNB 7분류)

최상위 GNB는 홈 / 농촌여행 / 고향사랑기부 / 콘텐츠 / 우수체험관 / 단체예약 / 마이페이지 7개. 농촌여행(놀고팜 자산)과 고향사랑기부(아이러브고향 자산)를 형제 메뉴로 나란히 두되, 답례품과 농촌여행 상품은 동일 카드 컴포넌트 · 동일 장바구니를 공유한다.

actibooky.com  (통합 단일 도메인 / lang=ko / 모바일퍼스트 단일 반응형)
│
├─ 홈  /
│   ├─ 히어로 + 전역 통합검색 바
│   ├─ 추천 레일(농촌여행·답례품·지정기부 혼합 / 구 AI추천 흡수)
│   ├─ 마감임박 지정기부 모금률 게이지
│   └─ 동네소식·축제 최신 피드
│
├─ 농촌여행  /trip
│   ├─ 체험        /trip/experience      (6하위: 농사·수확 / 먹거리·요리 / 공예·만들기
│   │                                      / 동물·교감 / 자연·생태 / 전통·문화)
│   ├─ 숙소        /trip/stay            (농가민박·펜션·한옥)
│   ├─ 캠핑        /trip/camping         (오토캠핑·글램핑 / 245p 무가격 디렉터리 정상화)
│   └─ 편의시설    /trip/facility        (주차·매점·체험장 부대시설)
│
├─ 고향사랑기부  /donation
│   ├─ 일반기부     /donation/general    (지자체 243곳 선택 → 기부)
│   ├─ 지정기부     /donation/project    (제8조의2 / 모금액·달성률%·목표·참여N명·사용처)
│   ├─ 답례품       /donation/gift       (계층 분류코드 + 다중필터 / '농촌체험 바우처·숙박' USP)
│   └─ 세액공제 계산기 /donation/tax-calculator (10만 전액→16.5% / 30%룰 인터랙티브)
│
├─ 콘텐츠  /content
│   ├─ 아티클      /content/article      (농촌여행·지역·제도 가이드)
│   ├─ 동네소식    /content/local-news   (지자체·지역 발신 소식)
│   └─ 축제        /content/festival     (축제 애그리게이터 / 일정·지역 필터)
│
├─ 우수체험관  /premium            (인증 체험관 큐레이션 / 놀고팜 우수체험관 자산)
│
├─ 단체예약  /group               (B2B 단체 견적·예약 / 놀고팜 단체예약 자산)
│
└─ 마이페이지  /my
    ├─ 주문·예약내역   /my/orders        (농촌여행 예약 + 답례품 결제 통합)
    ├─ 기부내역·영수증 /my/donations     (e음 연동 세액공제 영수증)
    ├─ 출석체크·포인트 /my/attendance
    ├─ 후기·찜         /my/reviews
    └─ 설정·본인인증   /my/settings

전역 요소: 헤더(GNB + 통합검색 + 장바구니 + 로그인) / 푸터(지자체 입점 안내 · 사업자정보 · 약관). 로그인은 결제·기부 직전에만 요구하고, 그 외 전 화면은 비로그인 전과정 탐색을 허용한다.

2.2 2사이트 메뉴 → 통합 위치 매핑

기존 놀고팜·아이러브고향의 모든 메뉴를 통합 GNB 위치에 1:1로 흡수한다. 중복·플레이스홀더·외부 떠넘김은 폐기 또는 흡수한다.

2.3 URL 체계 — 슬러그--UUID & canonical

도메인별 idx 파편화(놀고팜 상품 idx ↔ 아이고 답례품 idx ↔ 스토어 productOld)와 세션 누출(;jsessionid=)을 제거한다. 모든 상세 URL은 사람이 읽는 슬러그 + 전역 유일 UUID 조합으로 표준화한다.

패턴   /{섹션}/{카테고리}/{slug}--{uuid8}
예시   /trip/experience/yangpyeong-strawberry-farm--a1b2c3d4
       /donation/gift/hongseong-hanwoo-set--9f8e7d6c
       /donation/project/imsil-cheese-festival-fund--2b4c6e8a

규칙
 1. uuid8 = 내부 ULID 앞 8자(전역 유일). slug 바뀌어도 uuid로 동일 리소스 식별.
 2. canonical = 항상 slug--uuid 정규형 1개. slug 불일치/생략 접근은 301로 정규형 흡수.
      /trip/experience/old-name--a1b2c3d4   → 301 → 정규 slug 버전
      /trip/experience/a1b2c3d4 (slug 생략) → 301 → 정규형
 3. 레거시 idx 매핑: /product.do?idx=1234;jsessionid=XX → 301 → /trip/.../slug--uuid
      productOld·0원 상품은 410 Gone(검색 인덱스에서 제거).
 4. 쿼리스트링은 필터/정렬 전용. jsessionid·트래킹 파라미터는 canonical에서 배제.
 5. 페이지네이션·필터 조합 URL은 <link rel="canonical">로 1차 카테고리에 귀속.

2.4 카테고리 정규화 (idx 파편화 해소)

두 도메인이 각자 운영하던 카테고리를 단일 카테고리 마스터 트리로 통합하고, 답례품은 별도 계층 분류코드를 부여해 다중필터를 가능하게 한다.

카테고리 마스터 (category_id = 전역 ULID, parent_id로 트리)
  TRIP
    TRIP.EXP (체험)  ─ AGRI / FOOD / CRAFT / ANIMAL / NATURE / TRADITION
    TRIP.STAY (숙소) ─ MINBAK / PENSION / HANOK
    TRIP.CAMP (캠핑) ─ AUTO / GLAMP / ...
  DONATION
    DON.GIFT (답례품) ─ 분류코드 GcccNN  예) G0101 한우·육류, G0203 쌀·잡곡,
                          G0305 가공·반찬, G0410 농촌체험바우처, G0411 숙박권
    DON.PROJECT / DON.GENERAL

정규화 매핑 테이블 legacy_category_map
  (source_domain, legacy_idx) → category_id  (1:1, 이관 1회 배치)

답례품 분류코드 GcccNN는 지자체·가격·기부유형 필터와 직교(orthogonal)하게 결합되어 다중필터를 지원한다. USP 연결: G0410 농촌체험바우처·G0411 숙박권은 TRIP.EXP/STAY 실물재고와 외래키로 묶여, 답례품 카탈로그에서 놀고팜 실재고를 그대로 노출한다(복제 불가 단일 동선).

2.5 전역 통합검색 설계

헤더 검색 바 1개로 농촌여행·답례품·지정기부·콘텐츠·축제를 동시 검색한다. 구 AI추천 도메인의 추천 로직을 검색 랭킹·연관추천으로 흡수한다.

검색 결과는 외부로 보내지 않고 모두 자사 상세(slug--uuid)로 연결된다. 0건 결과 시 인접 지역·유사 분류코드를 추천해 이탈을 막는다.

2.6 외부 떠넘김 0건 원칙

레거시는 결정적 동선(기부 접수·답례품 구매·상세 안내)을 외부 사이트로 떠넘겨 통합·정보구조 점수를 깎였다. 통합 플랫폼은 법령상 공공 경유가 강제된 지점만 외부 시스템을 호출하고, 그 외 모든 탐색·선택·결제 준비는 자사 도메인에서 완결한다.

3. 핵심 유저 플로우

플로우 지도 (한눈에)

(A) 일반기부 — 지자체 선택 → 답례품 선택(=기부) → 결제

핵심 발상: 답례품 선택이 곧 기부 행위다(답례품 가격이 최소 기부금을 결정, 기부액의 30% 이내 룰). 탐색 전 과정은 비로그인.

1. 진입·지자체 선택 — GNB '고향기부' → 지자체 지도/리스트(243곳). 비로그인. 슬러그 URL /donate/jeonnam-goheung
2. 답례품 탐색 — 계층 분류코드(축산/수산/농산/가공/생활/체험·숙박) + 다중필터(가격대/지역/배송/재고). 카드에 '기부금 ○○원' 표기
3. 답례품 상세 = 기부 화면 — 좌측 스크롤 콘텐츠 / 우측 sticky 기부 패널. 패널에 답례품 가격·필요 최소 기부액·수량
4. 세액공제 안내(인터랙티브 위젯) — 기부액 입력 시 실시간: 10만원→전액 환급(실질 100%), 초과분 16.5%, 연 한도 2,000만원, 미공제 10년 이월 자동 표시
5. 비로그인 탐색 지속 — 장바구니 담기/금액 조정까지 로그인 요구 없음
6. 결제 직전 간편인증(최초 1회 게이트) — 간편인증(PASS/카카오/네이버)로 본인확인 → 본인 주소지 자동 판별 → 해당 지자체면 차단·다른 지자체 추천
7. e음 기부접수 — 고향사랑e음 API로 기부접수·본인확인 전송, 기부금 결제
8. 완료·영수증 — e음 경유 세액공제 영수증 발급 안내, 답례품 배송 추적, 출석체크/후기 유도

[A 일반기부 시퀀스]
이용자 ──지자체선택──▶ 답례품카탈로그(비로그인)
       └─선택=기부──▶ 상세/기부패널 ──▶ 세액공제 위젯(실시간 계산)
                                   │
                            [결제 직전] 간편인증 ──▶ 주소지 검증
                                   │  (본인 주소지면 차단)
                                   ▼
                          e음 API(기부접수·본인확인) ──▶ 결제 ──▶ 영수증/배송추적

(B) 지정기부 — 캠페인 탐색 → 모금현황 → 응원·기부 → 사용처

제8조의2(2024.2.20 신설) 기반. 위기브식 '기부 깊이'(달성률·참여자·사용처)를 도입해 정서적 몰입을 만든다.

1. 캠페인 탐색 — '지정기부' 탭, 지역/주제(아동/어르신/환경/문화) 필터. 카드에 모금률 게이지
2. 캠페인 상세·모금현황 — 모금액 / 목표액 / 달성률% / 참여 N명 / 마감 D-day 게이지. 좌측 스토리 콘텐츠
3. 응원·기부 — 우측 sticky 패널에서 응원 메시지 + 기부액. 비로그인 상태로 금액 설정까지
4. 결제 직전 간편인증 — 본인확인·주소지 검증(A와 동일 게이트)
5. e음 기부접수 → 완료 — 접수 후 응원 메시지 캠페인 타임라인 노출
6. 사용처 안내 — '이 기금이 어디에 쓰이는지' 사용처 명세(집행 항목·금액·진행률), 집행 후 리포트 알림

[B 지정기부 시퀀스]
캠페인 리스트 ──▶ 상세(모금률 게이지: 6,200만/1억=62%, 참여 318명, D-14)
        │           └─ 좌:스토리 / 우:응원+기부 패널
        ├─응원·기부──▶ [결제 직전] 간편인증·주소지검증
        │                       └──▶ e음 접수 ──▶ 영수증
        └─완료 후 ──▶ 사용처 명세/집행 리포트 ──▶ 리텐션(알림·재방문)

• 이탈 방지: 게이지·참여자 수로 사회적 증거 제공, 마감 D-day로 행동 촉발, 응원 메시지로 참여감
• 현 사이트 대비: 아이러브고향엔 지정기부 깊이(달성률/사용처) 부재 → 단순 기부 폼만 존재. 위기브(기부깊이 95) 수준으로 끌어올림

(C) 답례품 → 농촌체험 바우처 (차별 동선·복제 불가 USP)

일반 답례품(농산물)이 아닌 '농촌체험/숙박'을 답례품으로 선택하면, 받은 바우처가 놀고팜 실물재고·예약 시스템으로 직결된다. 두 자산(e음 + 놀고팜)을 결합한 단일 동선.

1. 답례품 카탈로그에서 '체험·숙박' 분류 진입 — '바로결제'/'예약형' 배지로 구분
2. 체험/숙박 답례품 선택 = 기부 — 예: '고흥 갯벌체험 2인 바우처(기부금 10만원)'
3. 세액공제 위젯 + 결제 직전 간편인증·주소지 검증 → e음 기부접수
4. 바우처 발급 — 마이페이지에 '농촌체험 바우처(코드)' 적립
5. 예약 연결 — 바우처 → 놀고팜 체험/숙박 상세의 예약 캘린더로 연결, 날짜·인원 선택
6. 예약 확정 — 바우처 차감 예약 완료, 일정 알림·오디오가이드 안내

[C 답례품→바우처 시퀀스]
체험·숙박 답례품 ──선택=기부──▶ e음 접수 ──▶ 바우처 적립(마이페이지)
                                          │
                                  ┌───────┘ (별도 결제 0원)
                                  ▼
                       놀고팜 예약 캘린더(날짜·인원) ──▶ 바우처 차감 ──▶ 예약확정

(D) 농촌여행 바로결제 예약

기부와 무관한 순수 여행 예약 동선(놀고팜 자산). 일반 e커머스 예약 UX.

1. 탐색 — '농촌여행' GNB: 체험(6하위)/숙소/캠핑(5하위)/치유관광/단체예약. 비로그인 탐색
2. 상품 상세 — 좌측 사진·후기·코스 / 우측 sticky 예약 패널(날짜·인원·옵션). '바로결제' 배지·별점/리뷰 카드
3. 예약 옵션 선택 → 장바구니 또는 즉시 결제
4. 결제 직전 로그인/간편인증(기부 아니므로 주소지 검증 불필요)
5. PG 직접 결제 → 예약 확정 — 예약번호·취소정책·오디오가이드

[D 바로결제 예약]
여행상품 ──▶ 상세(예약패널·바로결제 배지) ──▶ 날짜/인원
       └──▶ [결제 직전] 로그인 ──▶ PG 결제 ──▶ 예약확정

• 이탈 방지: 0원/0리뷰 잔재 제거(평점·가격 필수화), 스켈레톤으로 CLS 방지, 바로결제 배지로 '즉시 확정' 신뢰
• 현 사이트 대비: 놀고팜 productOld·0원가격·분기형 모바일 폐기 → 모바일퍼스트 단일 반응형

(E) 회원/소셜 + 간편인증 + 본인 주소지 검증

회원가입은 탐색에 불필요(선택). 기부 결제 시에만 간편인증으로 본인확인·주소지 판별이 강제된다(개인만·본인 주소지 외 기부 법령).

1. 회원/소셜 가입(선택) — 카카오/네이버/애플 소셜 또는 이메일. 가입은 리텐션(출석·후기)용
2. 간편인증(결제 직전 강제) — PASS/카카오/네이버 인증서로 실명·생년·주소 확인
3. 본인 주소지 검증 — 인증 주소 vs 기부 대상 지자체 비교
4. 분기 — 동일 지자체면 차단 + 인접/추천 지자체 안내, 상이하면 진행
5. 연 한도 체크 — 2,000만원(2025.1.1~) 누적 검증, 초과 시 차단·잔여 한도 표시

개선점: 현 사이트의 '가입 후 탐색' 게이트 제거 → 인증은 결제 직전 단 1회. 소셜 로그인으로 가입 마찰 최소화.

(F) 통합 장바구니 / 결제

기부(e음)와 여행예약(PG)이 서로 다른 정산 경로를 갖지만, 장바구니·세션·결제 진입은 하나다. 결제 단계에서 항목 성격별로 분기 정산.

1. 단일 장바구니 — 답례품 기부 + 체험 바우처 + 여행예약을 한 카트에 혼합 담기
2. 결제 진입 1회 — 비로그인까지 담기 가능, 결제 버튼에서 인증 게이트
3. 항목 성격 자동 분류 — 기부성(e음 경유·세액공제 대상) / 결제성(PG·여행)
4. 인증·검증 — 기부 항목 존재 시 간편인증·주소지·한도 검증(E)
5. 분기 정산 — 기부=e음 기부접수, 여행=PG 결제. 한 화면에서 통합 영수 처리
6. 완료 — 기부분 세액공제 영수증 + 예약/배송 트래킹을 단일 주문내역에 통합 표시

[F 통합 장바구니/결제]
단일 카트 ─┬─ 기부(답례품/바우처) ──▶ e음 접수 ──▶ 세액공제 영수증
           ├─ 여행 예약 ─────────────▶ PG 결제 ──▶ 예약확정
           └─ [결제 직전] 간편인증·주소지·한도(기부 항목 있을 때만)
                          └──▶ 통합 주문내역(영수증+배송+예약 한 화면)

T1. 농촌여행(놀고팜) 도메인 전략 & 리뉴얼 목표

1. 도메인 포지셔닝 - "국내 농촌관광 OTA + 로컬커머스"

놀고팜의 정체성은 단순 예약사이트가 아니라 농촌 공급의 절대량을 트랜잭션으로 전환하는 수직형 마켓플레이스다. 야놀자·여기어때(도심/일반숙박 OTA)와 정면충돌하지 않고, 그들이 다루지 않는 체험·촌캉스·캠핑·특산품·단체·치유관광의 농촌 버티컬을 독점한다. 경쟁 기부 플랫폼(웰로·위기브)에는 이 실물 공급 자산이 아예 없다.

포지셔닝 한 줄: "농촌의 모든 하루를 예약하고, 그 지역에 기부까지 잇는 곳."

2. 현 상태 진단 - 왜 아직 '디렉터리'인가

실측 IA(체험 6하위·숙소 3유형·캠핑 5하위·편의시설·스토어 5카테고리·단체예약·치유관광·오디오가이드)는 공급 폭이 넓다. 그러나 거래로 닫히지 않는 5가지 누수가 트랜잭션 마켓의 발목을 잡는다.

3. 리뉴얼 목표 - 트랜잭션 마켓플레이스의 4대 전환

4. 타깃 페르소나 3종 & 시나리오

P1/P2는 셀프서비스 트랜잭션(전환율·객단가 중심), P3는 리드→견적→계약(리드전환·계약액 중심)으로 KPI 체계를 분리 운영한다.

5. 농촌여행 전용 KPI 표 (목표 가설)

근거: 일반 여행 OTA 전환율 2-4%대, 리뷰 보유 상품은 무리뷰 대비 전환이 수배 높음(사회적 증거 효과). 현 놀고팜은 전화문의·0평점·0원 SKU로 인해 전환의 분모(방문)는 크지만 분자(결제완료)가 새고 있어, 위 KPI는 '누수 봉쇄'만으로도 단기 달성 여지가 크다.

6. 기부 도메인과의 시너지 (한 줄)

T2. 농촌여행 카탈로그 & 분류 정규화(IA)

1. 상품 타입 8종 — 현행 파편 idx → 통합 모델 매핑

모든 상품은 단일 product 엔티티로 통합하고, 종류는 product_type 한 컬럼으로 구분한다. 기존 도메인별 카테고리 idx는 통합 category_id(전역 유니크)로 1회 마이그레이션한다.

2. 공통 속성 vs 타입별 속성

모든 타입이 공유하는 core 컬럼은 단일 카드 시스템·검색 인덱스의 최소 계약이다. 타입별 속성은 product_attribute(product_id, key, value) EAV 또는 타입별 확장 테이블로 분리한다.

3. 통합 카테고리 트리

도메인 분리가 아니라 이용 의도(여행 동사) 기준 1뎁스 + 타입 기준 2뎁스로 통합한다. 괄호는 현행 idx 매핑.

농촌여행 카탈로그 (root)
├─ 체험하기 (EXPERIENCE)
│   ├─ 영농·수확            ← experienceCategoryIdx=1
│   ├─ 자연·생태            ← 2
│   ├─ 문화·예술            ← 3
│   ├─ 힐링·레포츠          ← 4
│   ├─ 공예·요리            ← 5
│   └─ 기타 체험            ← 20
├─ 머무르기 (STAY)
│   ├─ 빌라형               ← accommodationCategoryIdx=2
│   ├─ 독채형               ← 3
│   └─ 촌캉스               ← 6
├─ 캠핑하기 (CAMPING)
│   ├─ 캠핑장 / 글램핑 / 카라반 / 야영장 / 수련원 / 기타  ← facilityCategoryIdx
├─ 둘러보기 (AMENITY · 비거래 POI)
│   ├─ 향토음식맛집 / 전통시장 / 휴양림 / 전기차충전소
├─ 사가기 (GOODS)
│   ├─ 특산품(1) / 기념품(2) / 정육(5) / 체험키트(6)
├─ 묶음여행 (PACKAGE)            ← productCategoryIdx=7 재구조화
│   ├─ 체험+숙소 / 체험+특산품 / 가족형 / 당일형
├─ 단체로 (GROUP · RFQ)
│   ├─ 학교·교육 / 기업·모임 / 지자체 B2G
└─ 특화 (SPECIAL)
    ├─ 오디오가이드 (AUDIO)
    └─ 치유관광·치유농업 (WELLNESS, 전북)

4. 태그·속성 패싯 — 검색/필터와 1:1 일치

카테고리(1개 선택)와 직교하는 다대다 태그. 패싯 UI 필터 = DB 태그 namespace를 그대로 노출해 IA-검색 불일치(현 데스크탑 검색바 vs 모바일 아이콘 그리드)를 제거한다.

5. 패키지·번들 모델 (체험+숙소)

패키지는 별도 상품 타입이 아니라 구성품을 참조하는 컨테이너 product. 구성품 가격 합 대비 절감액을 표기하고, 예약 시 자식 SKU의 재고를 동시 점유한다.

PRODUCT (type=PACKAGE)  "완주 1박2일 딸기수확+촌캉스"
  ├─ bundle_price = 89,000   list_sum = 105,000   savings = 16,000
  └─ PACKAGE_COMPONENT (다대다, 순서/필수여부)
        ├─ #1 EXPERIENCE  딸기수확체험(2인)   required  day=1
        ├─ #2 STAY        촌캉스 독채 1박     required  day=1
        └─ #3 GOODS       딸기잼 키트         optional  add-on

예약 트랜잭션:
PACKAGE 결제 → child별 inventory_hold 발급 →
  EXPERIENCE 회차 슬롯 -2, STAY 객실달력 -1박 →
  하나라도 실패 시 전체 롤백(원자적)

6. 공급자(우수체험관) ↔ 상품 관계

/user/farm/excellentCompanyList의 업체 마스터를 provider로 승격해 모든 product가 단일 공급자 FK를 갖게 한다. 공급자는 PLP/PDP 신뢰 단위이자 정산·기부 답례품 입점 계약의 주체다.

PROVIDER (우수체험관/입점사)
  id, name, region_code, biz_no,
  is_verified(우수체험관 인증), payout_account,
  donation_contract(지자체 답례품 계약 여부)
        │ 1
        │
        │ N
     PRODUCT  (type ∈ 8종)
        │ 0..N                     │ 0..N
   PACKAGE_COMPONENT          DONATION_REWARD_LINK
   (번들 구성, §5)            (체험/숙박권 → 답례품, 30%한도)
        │
   ORDER_ITEM ── ORDER ── REVIEW(rating_avg 집계 역연결)

7. 검색/필터 패싯 일관성 — 단일 인덱스 계약

4개 도메인 검색을 하나의 인덱스(예: products 컬렉션)로 통합. 홈 검색바의 지역·날짜·인원 3축이 그대로 패싯 쿼리 파라미터가 되어 데스크탑/모바일 멘탈모델을 일치시킨다.

T3. 예약 엔진(가용성·재고·결제·취소)

1. 상품 타입별 예약 모델

4개 도메인은 재고 단위(inventory unit)와 시간 단위(time grain)가 다르다. 엔진은 공통 Bookable 추상 위에 타입별 어댑터를 둔다.

편의시설/우수체험관/스토어 productOld(0원)는 예약 대상이 아니거나 마이그레이션 미완이다. 스토어 실물상품은 별도 Orderable(배송형)로 분리하되 동일 결제·정산 인프라를 공유한다.

[Bookable] (추상)
 ├─ ExperienceBookable   slot_grain = 회차(시각)   stock = capacity-기반
 ├─ StayBookable         range_grain = 1박(날짜)   stock = room_count-기반
 ├─ CampingBookable      range_grain = 1박(날짜)   stock = site 0/1 점유
 └─ PackageBookable      composite[*Bookable]      stock = 구성요소 AND
[Orderable] (배송형, 재고 stock_qty)   ← 스토어 특산품/정육/키트

2. ERD (가용성·재고·홀딩 핵심)

supplier(공급자: 우수체험관/숙소주/캠핑장)
   └─< product(상품, type, booking_mode, supplier_id)
         ├─< rate_plan(요금제: 성인/아동/객실타입/사이트등급, base_price)
         │      └─< price_calendar(rate_plan_id, date, weekday_kind,
         │                         season, price, override)
         ├─< inventory_unit(객실/사이트/회차정의)
         │      └─< availability(unit_id, date|slot, total, sold, held, blocked)
         └─< option(옵션: BBQ세트/이불추가/장비대여, price, max_qty)

hold(가심사/홀딩: cart_id, availability_id, qty, status, expires_at)  ← TTL 10분
   └─1:1─ booking(주문: status, mode, total, voucher_id, payment_id)
                └─< booking_item(product_id, unit, qty, unit_price, option_json)
                └─1:1─ payment(pg, method, amount, status, pg_tid, refund_json)
                └─< voucher(code, qr_payload, status, redeemed_at, redeemer)
settlement(정산: supplier_id, period, gross, fee, net, status)
   └─< settlement_line(booking_id, gross, fee_rate, net)

3. 가용성·재고 캘린더

• 재고 표현 통일: availability(total, sold, held, blocked). 잔여 = total - sold - held - blocked. 체험은 회차당 total=정원, 숙소·캠핑은 1박 날짜당 total=객실수/사이트 1.
• 날짜범위(숙소·캠핑)는 체크인~아웃-1까지 매 1박 행을 전부 잔여>0 검증해야 예약 가능. 2박이면 8/1, 8/2 두 날 모두 홀딩.
• blocked: 공급자 수기 마감(정기휴무·내부행사)·공공데이터 동기화 마감. 캠핑 245페이지 고캠핑 집계분은 초기 blocked=total(노출만, 예약불가)로 등록 후 계약 완료 사이트부터 점진 개방.
• 캐시: 월 단위 가용성 그리드를 Redis에 캐시(TTL 60초) + 변경 시 무효화. TTFB<100ms 목표에 부합하게 PLP/캘린더는 캐시 우선.

4. 옵션·인원·가격정책

가격 계산은 서버 권위(server-authoritative). 클라이언트 표시가는 참고용이며, 홀딩·결제 시점에 price_calendar 재조회로 재계산해 가격 변조를 차단한다.

5. 가심사·홀딩·동시성·오버부킹 방지

6. 예약 2모드: '전화문의' 흡수

'전화문의' 배지는 전량 제거하고 위 2모드로 매핑한다. 승인형도 통화 없이 사이트 내에서 가결제(PG 승인 후 capture 보류)로 처리해 통화 누수와 노쇼를 동시에 줄인다.

7. 결제(PG·간편결제)·바이바로 통합

• PG/간편결제: 카드(PG사 결제창)·카카오페이·네이버페이·토스 간편결제. 승인형은 auth(승인) → capture(매입) 2단계 사용, 실시간확정은 즉시 capture.
• 바이바로결제(Bibarro) 통합: 기존 '바로결제' 능력을 표준 PG 어댑터로 추상화(PaymentGateway 인터페이스: authorize/capture/cancel/partialRefund). 바이바로를 1차 어댑터로 두고 신규 간편결제를 동일 인터페이스로 추가해, SKU별 결제수단 차이를 엔진 상위에서 흡수.
• 멱등성: 결제 요청·콜백에 Idempotency-Key. 콜백(webhook) 수신 시 payment.status 전이만 허용(승인→매입→취소/부분환불).
• 고향사랑기부 크로스셀: 결제 직전 패널에서 '이 지역 고향사랑기부 추가' 동선 노출(별도 트랜잭션, 고향사랑e음 연동). 기부 답례품으로 발급된 체험 바우처는 0원 결제(바우처 차감)로 동일 엔진 통과.

8. 취소·노쇼·부분환불 정책 표

부분환불: 인원 일부 취소(체험 4인 중 1인 취소)는 해당 인원 단가만 환불, 옵션은 옵션 정책 따름. 천재지변·공급자 귀책 취소는 정책 무관 100% + 패널티 면제(예외 플래그).

9. 정산(공급자 정산 주기)

10. 바우처/QR 입장

• 확정 시 voucher.code(영숫자 12자) + 서명된 QR payload(booking_id·item·만료·HMAC) 발급. 1예약 다인원은 인원 수만큼 또는 단일 다회 사용 바우처 중 상품설정 따름.
• 현장 검증: 공급자 모바일 웹에서 QR 스캔 → 서버 검증(서명·상태·일자) → redeemed_at 기록(중복사용 차단). 오프라인 대비 코드 수기 입력 폴백.
• 입장 완료가 정산 트리거(이용완료 확정)와 노쇼 판정 근거가 된다.

11. 예약 시퀀스 (실시간확정 + 승인형 분기)

사용자        프론트(SPA)      예약엔진        재고DB         PG(바이바로/간편)   공급자
  │  날짜·인원 선택 │              │              │              │              │
  │──────────────>│ getAvailability──────────>│  잔여 조회     │              │
  │               │<─────────────캐시/DB 그리드─│              │              │
  │  '예약' 클릭   │              │              │              │              │
  │──────────────>│ createHold ─>│ UPDATE held+ WHERE 잔여>=q (원자)         │
  │               │              │<──ok/매진────│              │              │
  │               │<─hold(TTL10m)─│              │              │              │
  │  결제수단 선택 │ confirmPrice >│ price_calendar 재계산(서버권위)           │
  │──────────────>│ pay ────────>│ authorize ─────────────────>│              │
  │               │              │<──auth_ok(승인,Idempotency)─│              │
  │     ┌─────────[ 실시간확정 ]──────────────────────────────────────────┐ │
  │     │         │ capture ───────────────────>│ 매입         │            │ │
  │     │         │ sold+=q, held-=q  바우처·QR 발급                       │ │
  │     │<─확정/바우처/QR──────────────────────────────────────────────────┘ │
  │     └─────────[ 승인형(예약요청) ]───────────────────────────────────┐   │
  │               │ notify ───────────────────────────────────────────>│승인/거절
  │               │           24h 내 승인 ─> capture·확정·바우처발급     │   │
  │               │           거절/타임아웃 ─> auth취소·held회수·안내    │<──┘
  │  현장 도착     │ QR 스캔(공급자) ─> verify(HMAC·상태) ─> redeemed_at      │
  │  (취소 시)     │ cancel ─> 정책표 환불율 계산 ─> partialRefund/cancel ─>PG │

홀딩 TTL 만료·승인 타임아웃·결제 콜백 중복은 모두 스케줄러+멱등키로 자기치유(self-healing)하며, 어떤 경로에서도 오버부킹과 미회수 재고가 남지 않도록 재고 차감(held/sold)과 결제 상태를 단일 트랜잭션 경계 안에서 정합 유지한다.

T4. 검색·필터·지도·AI 여행 추천

4.1 현 검색 경험의 문제 (실측)

4.2 통합검색 - 단일 검색바 (데스크탑·모바일 동일 멘탈모델)

홈의 모바일 아이콘 그리드를 폐기하고, 데스크탑·모바일 모두 동일한 검색바를 최상단에 둔다. 검색바는 5개 축(지역·날짜·인원·카테고리·테마)을 갖되, 모바일은 탭하면 풀스크린 시트로 펼쳐진다. 카테고리 아이콘은 검색바 아래 "빠른 진입 칩"으로 격하되어 보조 역할만 한다.

[ 어디로?(지역) | 언제?(날짜) | 누구와?(인원) | 무엇을?(카테고리) | [돋보기] ]
                              └ 펼침: 테마 패싯(딸기·할로윈·촌캉스·치유 …)
─ 빠른칩 ─ #딸기따기  #촌캉스  #글램핑  #특산품  #치유관광  #단체

4.3 패싯 필터 체계 (PLP 좌측 / 모바일 하단시트)

현 카테고리 IA를 그대로 패싯으로 매핑하고, 신뢰도 문제(0.0 평점·전화문의 누수)를 필터로 정면 해결한다.

4.4 정렬 (4종 + 기본 부스팅 규칙)

베이지안 평점: score = (m*C + n*avg) / (m + n) (m=가중 표본 5, C=전체평균 3.8). 리뷰 0개 SKU가 "평점 5.0"으로 왜곡 상위 노출되는 사고를 막는다.

4.5 지도 기반 탐색

리스트-지도 50:50 분할(데스크탑) / 리스트 상단 "지도로 보기" 토글(모바일). 지도 이동 시 뷰포트 내 결과만 동기 갱신("이 지역 재검색" 버튼). 캠핑 245p 공공데이터식 디렉터리가 오히려 지도에선 밀도 자산으로 전환된다.

시퀀스: 지도 탐색
사용자 → 지도 pan/zoom
        → viewport bbox(좌표) 전송
검색API → bbox 내 SKU + 클러스터(핀 묶음) 반환
프론트 → 핀 hover시 미니카드(썸네일·가격·평점·바로결제배지)
        → 핀 클릭 → 좌측 리스트 해당 카드로 스크롤+하이라이트
사용자 → "이 지역 재검색" → 패싯 유지한 채 bbox만 갱신

• 핀 색: 회색=가격문의/전화, 파랑=바로결제, 별=리뷰 4.0+
• 클러스터링: 줌 레벨별 그리드 집계(같은 시군구 50개 핀 → "임실 50")
• "내 주변" 버튼: geolocation → 거리순 정렬 자동 전환

4.6 자동완성 · 핫키워드

4.7 SEO 프로그래매틱 랜딩 (지역×테마)

현 jsessionid URL·canonical 부재로 검색유입이 0에 가깝다. "지역 × 테마" 조합을 정적 랜딩으로 자동 생성하여 롱테일 유입을 확보한다.

URL 설계
/travel/{지역}                 → 경북 농촌여행 (허브)
/travel/{지역}/{테마}          → /travel/gyeongbuk/strawberry
/travel/theme/{테마}           → 전국 딸기따기 체험
/stay/{지역}/{숙소유형}        → /stay/jeonbuk/chonkangseu
페이지 = 통합검색의 프리필터된 결과 + 지역/테마 카피 + JSON-LD

4.8 AI 여행 추천 챗봇 (웰로 매칭봇 대비 차별화)

웰로 매칭봇의 약점은 입력 affordance 부재(무엇을 말해야 할지 모름)다. 우리는 자유 텍스트가 아니라 구조화된 입력 칩(예산·일정·동행·관심)을 먼저 제시하고, 그 위에 자유 대화를 얹는다. 결과는 추상 추천이 아니라 예약 가능한 실물 SKU 카드로 끝난다(검색·재고와 직결). 5FPI 치유농업 설문 엔진을 이 챗봇의 "치유 모드"로 흡수한다.

대화→예약 시퀀스

1) 진입: "AI 여행 플래너"  (칩 4종 먼저 노출, 자유입력은 보조)
2) 사용자: [가족·아동] [1박2일] [~20만] [수확]  + "경북에서 딸기"
3) 봇: 의도 파싱 → 통합검색 API 호출(지역=경북, 테마=딸기·수확, 인원=가족, 박=1, 예산필터)
4) 봇: 일정 제안
     · 오전: 경산○○농원 딸기따기(성인 1.5만, ★4.6, 바로결제)
     · 오후: 임실 치즈만들기(2만, ★4.4)
     · 숙박: 촌캉스 독채(12만, ★4.7)
     · 답례품 크로스셀: "이 지역 고향사랑기부 시 딸기잼 답례품" (USP)
5) 사용자: "딸기 말고 포도" → 봇: 해당 항목만 교체(재검색)
6) "전체 장바구니 담기" → 통합 결제(단일 세션/장바구니)

4.9 검색 도메인 모델 (ERD 개요)

SearchableItem(통합 인덱스)
├─ id, type(체험|숙소|캠핑|편의|스토어|치유)
├─ title, thumb, region_sido, region_sigungu, geo(lat,lng)
├─ category_idx(원 IA 키), theme_tags[](신규)
├─ price, price_type(바로결제|전화|가격문의)   ← 누수 SKU 식별
├─ rating_avg, rating_count(0이면 신규 라벨)
├─ amenities[](주차·반려·우천·실내)
├─ available_dates[], capacity
└─ donation_linked(bool)                       ← 답례품 USP 플래그
        │
        ▼ 색인(검색엔진: 자동완성·패싯·지오·정렬)
SearchQuery{region,date,pax,categories[],themes[],facets,sort,bbox}
        │
        ▼
AIPlannerSession{budget,nights,companion,interests[],messages[]}
        └─ 동일 SearchQuery로 변환 → 동일 결과 파이프라인 재사용

핵심: AI 챗봇·지도·PLP·SEO 랜딩이 모두 하나의 SearchQuery → SearchableItem 인덱스를 공유한다. 별도 미니사이트(치유·단체·오디오)도 같은 인덱스에 type만 다르게 적재하여 톤·동선 이질감을 제거한다.

T5. 리뷰·신뢰 & 공급자·우수체험관·단체예약·정산

A. 리뷰·평점·신뢰 시스템

원칙: 실제 예약/구매 완료 건만 리뷰 가능(verified purchase only). 별점은 거래 데이터와 1:1로 묶이며, 미거래 SKU에는 별점 위젯 대신 대체 신뢰 신호를 노출한다. 가짜 '0.0' 표기를 화면에서 영구 추방한다.

B. 공급자(파트너) 생태계

공급 주체는 우수체험관/농가/캠핑장/스토어 셀러. 공급자 어드민에서 상품등록-재고-캘린더-정산-문의를 한 곳에서 처리한다. 단체예약(B2G/B2B)은 별도 견적·계약 워크플로로 분리한다.

B-1. 온보딩 단계

B-2. 공급자 어드민 기능

B-3. 정산(주기·수수료·세금)

정산 시퀀스
이용완료 → [환불대기 7일] → 정산확정 → 수수료·PG·원천 차감
   → 주간배치(수) → 농가계좌 입금 → 세금계산서 발행 → 어드민 내역 반영

B-4. 단체예약(B2G/B2B) 워크플로

학교·기관·기업 단체(견학·워크숍·체험학습)는 즉시결제가 아닌 견적→문의→계약→정산 흐름. '액티부키 X 놀고팜' 톤을 메인 IA에 흡수하되 전용 동선 유지.

B-5. 등급/품질관리

품질 점수(QS) = 평점(40%) + 응답률·속도(20%) + 정시이행/노쇼역(20%)
              + 리뷰량·사진비율(10%) + 인증·수상(10%)

T6. 스토어 — 특산품/로컬 커머스

1. 카테고리 체계: 5종 + 농가직거래 축

현 productCategoryIdx 5종(특산품1/기념품2/정육5/체험키트6/패키지7)을 유지하되, '공급주체' 축(일반셀러 vs 농가직거래)과 '배송유형' 축을 직교(orthogonal) 속성으로 분리한다. 카테고리는 탐색용, 배송/공급은 SKU 속성용.

2. productOld 레거시 정리 & 0원 가격 마이그레이션

레거시를 자동 노출 차단부터 한 뒤, SKU 단위로 분류·정상화·폐기한다. 0원은 미완 데이터이지 무료가 아니므로, 검수 전까지 결제 진입을 막는다.

[마이그레이션 파이프라인]
productOld (레거시 N건)
  ├─ STEP0 분류: price==0 / 전화문의배지 / 이미지없음 / 평점0.0 플래그
  ├─ STEP1 격리: status=DRAFT 강제, PLP/검색 색인 제외 (noindex)
  ├─ STEP2 매핑: old.fields → new SKU 스키마 (단위·중량·옵션 파싱)
  ├─ STEP3 가격검수: 0원 → 공급가 입력 필수 (셀러/MD 2단 승인)
  ├─ STEP4 승인: status=ACTIVE 전환 (이미지 alt·재고·배송정책 충족 시만)
  └─ STEP5 폐기: 90일 미검수 → ARCHIVED + 301 redirect(유사 SKU)

0원 노출 가드: 애플리케이션 레벨에서 price <= 0 && status==ACTIVE는 배포 차단(불변식). 0원은 오직 DRAFT에서만 허용.

3. 도메인 모델 — 상품·옵션·재고(단일 원장)

핵심은 SKU = 재고의 단일 진실원. 스토어 판매도, 답례품 제공도, 패키지 구성도 모두 같은 SKU의 재고를 차감한다. Product(전시) ≠ SKU(재고) 분리가 이중재고 방지의 토대.

[ERD 핵심]
Seller(농가/업체, excellentCompany 연계)
   1─*  Product (전시단위: 제목/설명/이미지/카테고리)
            1─*  Sku (옵션조합: 사과5kg특, price, weight)
                   1─1  Inventory (qty_on_hand, qty_reserved, safety_stock)
                   *─*  Channel  ← SKU가 어느 채널에 노출되나
                          ├ STORE        (스토어 판매)
                          ├ REWARD        (기부 답례품 카탈로그)
                          └ PACKAGE_ITEM  (패키지 구성품)
Reservation(여행예약: 체험/숙소/캠핑) ─┐
Sku ──────────────────────────────────┼→ CartItem (단일 장바구니)
DonationOrder ─────────────────────────┘

4. 배송: 택배·산지직송·신선냉장

장바구니는 배송그룹(shipment group) 단위로 자동 분할: (셀러 × 배송유형 × 온도대)가 그룹 키. 산지직송 정육과 택배 특산품을 한 카트에 담으면 배송비·도착일이 그룹별로 표시된다.

5. 주문 / 교환 / 반품 (신선식품 특례)

반품 정책을 SKU 속성 return_policy로 명시(상온=7일 단순변심 가능 / 신선·정육=품질하자만). PDP·결제·주문완료 3곳에서 동일 문구 노출(분쟁 예방).

6. 지역 × 제철 큐레이션

독점 자산인 전국 농가 공급량을 지역(17개 시도) × 제철(월) 2축으로 큐레이션. 홈 핫키워드(경북/경산/만들기)와 검색 IA에 직결.

큐레이션은 region_tag + season_month[] SKU 태그로 구동, MD가 슬롯만 편성(수동 상품 나열 금지 → 자동 충원).

7. 답례품 ↔ 스토어: 공유/분리 전략 (이중 재고 방지)

[이중재고 방지 시퀀스 — 동시 주문 경합]
STORE 주문    ┐
              ├→ reserveStock(sku=APPLE5KG, qty=1)  ← 단일 원장 낙관적 락(version)
REWARD 답례   ┘   ├ 성공: reserved+=1, 잔여 검사
                  └ 실패(version 충돌/재고부족): 재시도 or OUT_OF_STOCK
확정: SHIPPED 시 on_hand-=, reserved-=  (양 채널 공통)

분리 케이스: 답례품 전용 SKU(지자체 한정 굿즈, 지역사랑상품권)는 Channel=REWARD 단독으로 두고 STORE 미노출. 공유 케이스: 농산물·정육·체험바우처는 양 채널 동시. 재고 단일 원장이라 한쪽이 팔리면 즉시 반영.

8. 농촌여행 예약 + 스토어 통합 장바구니

예약(체험/숙소/캠핑, 시간·재고 슬롯)과 실물상품(SKU)은 성격이 다르나 하나의 CartItem 추상으로 담는다. 결제는 단일, 이행(fulfillment)은 라인별 분기.

크로스셀: 체험 예약 PDP 우측 sticky 패널에 '해당 농가 특산품' 노출 → 한 카트에 담아 단일 결제. 반대로 특산품 구매 동선에서 고향사랑기부 크로스셀(개인·본인주소지 외·연 2,000만 한도 고지)을 띄워 답례품으로 체험 바우처를 회수하게 한다.

9. 착수 우선순위

1. 0원 가드 + 레거시 격리(STEP0~1): 신뢰 즉시 회복, 결제 누수·'0원' 인상 제거.
2. SKU 단일 원장 + Channel 모델: 답례품 연계 전 이중재고 구조부터 확정(되돌리기 비용 큼).
3. 배송그룹·신선식품 반품 특례: 정육/산지직송 클레임 리스크 선제 차단.
4. 통합 장바구니: 예약×상품×기부 단일 결제로 USP 완성.

T7. 핵심 차별 — 답례품 ↔ 농촌체험 바우처 연결

1. 양방향 USP 두 갈래

2. 법적 제약 — 반드시 지킬 7가지

3. 데이터 모델 (ERD)

donation ──┬─< voucher >──┬── reservation (0원 차감)
  donor_id  │  face_value  │   product_idx (experience/accom/facility)
  lguz_idx ─┤  cap=amt*0.3 │   pay_voucher  + pay_self(초과분)
  amount    │  state       └── usage_log (예약차감/취소복원)
  e음_txn   │   ISSUED→RESERVED→REDEEMED→EXPIRED
           │
lg_contract(지자체 입점계약) ──< reward_product(답례품 등록)
  lguz_idx                      reward_idx ── maps → product_idx(놀고팜 재고)
  fee_rate(5~10%)               face_value, region_lock

region_bundle ──< reward_product   // (이 지역 기부→이 지역 체험)
  region_code      experience set

핵심: reward_product.maps→product_idx 한 줄이 USP의 전부다. 답례품 등록은 지자체 명의지만 실재고 포인터는 놀고팜 product/experience를 가리켜, 별도 재고 이중관리가 없다.

4. 시퀀스 — (A) 기부 → 바우처 → 예약 차감

[기부자]      [놀고팜]        [고향사랑e음]    [지자체]      [예약엔진]
   │ 기부10만+답례품선택 │           │            │
   ├──────────────>│ 기부요청     │            │
   │               ├──────────────>│ 결제승인    │
   │               │<──── e음_txn ─┤            │
   │               ├── 한도검증 face=min(3만,상품가) │
   │               │   voucher.ISSUED(QR발급)  │
   │<── 바우처 ─────┤            │            │
   │  (예약 시점)   │            │            │
   ├─ 체험예약 선택 │            │            │
   │               ├── voucher.RESERVED ──────────────>│ 예약hold
   │               │   pay_voucher=3만 / pay_self=차액 │
   │               │<───────── 예약확정 ───────────────┤
   │               │   voucher.REDEEMED(체험완료 후)   │
   │               ├── 정산: 지자체←수수료 / 업체←체험비 │

5. 시퀀스 — (B) 구매 동선 크로스셀

[PDP/장바구니]   특산품 5만원 담음
   │ "이 지역 5만 기부 시 실부담 8,250원 + 답례품 1.5만 바우처"
   ├─ 기부 후크 클릭 ─> 주소검증(본인지자체 제외)
   │                  기부5만 → 공제 4.175만 / 답례 1.5만
   ├─ 같은 장바구니에서 기부+구매 동시 결제(단일 세션)
   └─ 답례 바우처 즉시 재투입 → 추가 체험 예약(객단가 ↑)

6. 정산 흐름 (2단 분리)

7. 리스크 표

8. 왜 웰로·위기브는 못 따라오나

결론: 기부 플랫폼은 우리의 예약 재고를 답례품화할 수 없지만, 우리는 그들의 정산 레이어를 표준 API로 흡수한다. 해자는 "기부+예약+정산을 단일 세션에 닫는 유일한 사업자"라는 비대칭에 있다.

T8. 농촌여행 도메인 데이터 모델(ERD)

전체 ERD (놀고팜 ↔ 기부 통합)

[USER]──┐ (회원: 여행자=기부자 단일계정)
        │
        ├──< [CART] >── cart_item ── (PRODUCT_OPTION | STORE_PRODUCT | DONATION)
        │        └ 단일 장바구니에 체험·숙소·특산품·기부 혼재
        │
[SUPPLIER]──< [PRODUCT] >──< [PRODUCT_OPTION] >──< [INVENTORY/AVAILABILITY]
  우수체험관      │ type=                    │ (날짜·회차·정원·객실)
  /농가          │ 체험/숙소/캠핑/편의/패키지   │
  /지자체직영     │                          ↓
                 │                      [BOOKING]──< [ORDER] >── [PAYMENT]
                 │                          │  status        └─< [REFUND]
                 │                          │  인원/voucher_id
                 │                          ├── [REVIEW] (예약검증: booking_id 필수)
                 │                          └── [VOUCHER] ←──┐ 기부 답례품 발급
                 │                                          │
                 ├── [STORE_PRODUCT]──< [SHIPMENT]          │
                 │      특산품/정육/키트/기념품               │
                 │                                          │
                 └──< product_tag >── [REGION] / [THEME]    │
                                                            │
[GROUP_RESERVATION] (B2G/B2B 단체) ──── 견적·정산 ───────┐  │
                                                       │  │
══════════ 기부 도메인 연결 ══════════                  │  │
[LOCAL_GOV]──< [GIFT_CATALOG] >── voucher_template ─────┘  │
   지자체        (답례품 등록: 체험권/숙박권)                │
      │                                                   │
      └──< [DONATION] >──< [GIFT] >── 발급 ──> [VOUCHER] ──┘
              고향사랑e음          (기부액 30% 이내)
      │
[SETTLEMENT] ── 정산대상: SUPPLIER(체험/상품 매출) | LOCAL_GOV(기부 답례품 원가/수수료)

카테고리 파편화 해소 (현행 → 통합)

현행은 experienceCategoryIdx, accommodationCategoryIdx, facilityCategoryIdx, productCategoryIdx가 각각 다른 테이블/URL(/user/experience, /user/accommodation, /user/facility, /user/product)에 흩어져 검색·장바구니·정산이 분리됨. 단일 PRODUCT.type + 정규화 카테고리로 통합한다.

마이그레이션: productOld 레거시와 '0원' SKU는 status=DRAFT로 격리, 가격·재고 검증 통과분만 ACTIVE 승격. AMENITY는 bookable=false로 두어 평점 0.0 오염을 PLP에서 분리.

핵심 엔티티별 컬럼

기부(GIFT/DONATION) 도메인 연결점

4. 기능 요구사항(FR) + 우선순위

4.0 MVP(P0) 경계 한눈에 보기

MVP는 "비로그인 전과정 탐색 → 결제 직전 로그인 → 일반/지정 기부 + 답례품/체험 바우처 결제 → e음 영수증"의 단일 동선을 닫는 것이 목표다. 정산 자동화, 커뮤니티 작성, 출석 리워드 교환 등은 P1 이후로 분리한다.

4.1 회원·인증 (MEM)

4.2 기부 - 일반/지정 (DON)

4.3 답례품 커머스 (GFT)

4.4 농촌여행 예약 (RSV)

4.5 세액공제 계산기 (TAX)

4.6 통합검색 (SCH)

4.7 콘텐츠/커뮤니티 (CMS)

4.8 출석·리워드 (ATT)

4.9 장바구니·결제·정산 (PAY)

4.10 알림 (NOTI)

4.11 마이페이지 (MYP)

4.12 우선순위 집계

각 FR은 7장 비기능 요구사항(성능 TTFB<100ms, 접근성 alt 0누락, 보안 ISMS-P)과 함께 충족되어야 완료로 간주한다. P0 41개가 닫히면 평점 목표 86.2의 정보구조·기부깊이 축이 확보된다.

5. 데이터 모델(ERD, 통합)

5.1 전체 ERD (텍스트)

                                   ┌───────────────┐
                                   │  LOCAL_GOV    │  멀티테넌트 루트 (243곳)
                                   │ (지자체/테넌트)│
                                   └──────┬────────┘
            ┌───────────────┬────────────┼───────────────┬──────────────┐
            │1:N            │1:N         │1:N            │1:N           │1:N
       ┌────▼─────┐   ┌─────▼──────┐ ┌───▼──────────┐ ┌──▼─────────┐ ┌──▼──────┐
       │  GIFT    │   │  DONATION_ │ │ EXPERIENCE / │ │  CONTENT   │ │RECEIPT_ │
       │(답례품)   │   │  CAMPAIGN  │ │ ACCOMMODATION│ │(아티클/소식 │ │ POLICY  │
       │categoryCd│   │(지정기부)   │ │ / FACILITY   │ │ /축제)      │ │(정산조건)│
       └────┬─────┘   └─────┬──────┘ └───┬──────────┘ └────────────┘ └─────────┘
            │N:1            │             │N:1
       ┌────▼─────┐         │        ┌────▼────────┐
       │ CATEGORY │◄────────┘        │  PRODUCT    │  (예약/스토어 판매단위)
       │(계층트리) │  (캠페인도 분류)   │ +바로결제배지 │
       └──────────┘                  └────┬────────┘
                                          │N:1 (선택)
   ┌──────────────────────────────────────┼───────────────────────────────┐
   │                                       │                               │
┌──▼──────┐   ┌──────────┐   1:N   ┌──────▼──────┐  1:N   ┌────────────┐   │
│  USER   │──────────────────────► │   ORDER     │ ─────► │ ORDER_LINE │───┘
│(개인회원)│   │  CART    │◄────────│ (통합주문)   │        │ line_type: │
└──┬──────┘   │(통합장바구니)│ 1:1   └──────┬──────┘        │ DONATION / │
   │1:N       └──────────┘               │1:1            │ RESERVATION│
   │      ┌──────────────┬───────────────┤              │ / PRODUCT  │
   │      │1:N           │1:N            │1:1           └─────┬──────┘
┌──▼────┐ │         ┌────▼─────┐   ┌─────▼──────┐             │
│ POINT │ │         │ DONATION │   │  PAYMENT   │             │1:1 (line_type=DONATION)
│(적립금)│ │         │(기부원장) │   │(PG/e음 정산)│        ┌────▼──────┐
└───────┘ │         │ e음연동키 │   └─────┬──────┘        │  DONATION │
          │         │ 세액공제  │         │1:1 (DONATION) │  (기부원장) │
┌─────────▼──┐      └────┬─────┘   ┌─────▼──────┐        └────┬──────┘
│ ATTENDANCE │           │1:1      │  RECEIPT   │             │1:1
│ (출석체크)  │      ┌────▼─────┐   │(기부금영수증│        ┌────▼──────┐
└────────────┘      │GIFT(답례품)│  │ e음 발급)   │        │RESERVATION│
                    └──────────┘   └────────────┘        │(예약-라인별)│
┌────────────┐  ┌──────────┐                             └───────────┘
│  COMMENT   │  │  REVIEW  │   (CONTENT/EXPERIENCE/GIFT에 polymorphic 연결)
│(소식 댓글)  │  │(별점·후기)│   target_type + target_id
└────────────┘  └──────────┘

5.2 핵심 엔티티 컬럼 표

주요 13개 엔티티의 대표 컬럼만 발췌. 모든 PK는 uuid(URL은 슬러그--UUID 패턴), 모든 테이블에 created_at/updated_at 공통. FK는 _id 접미사로 표기.

USER (개인회원)

LOCAL_GOV (지자체 / 멀티테넌트 루트)

DONATION (기부 원장)

DONATION_CAMPAIGN (지정기부 캠페인)

GIFT (답례품)

CATEGORY (통합 계층 트리)

ORDER / ORDER_LINE (통합 주문)

PAYMENT (결제/정산)

RECEIPT (기부금 영수증)

REVIEW / CONTENT / ATTENDANCE / POINT (리텐션 계열)

5.3 설계 결정 3가지

5.4 도메인 무결성 규칙(DB/애플리케이션 제약)

URL 식별자는 전 엔티티 slug--uuid(예: /gift/damyang-bamboo-rice--a1b2…)로 통일, jsessionid·productOld 잔재 제거 및 canonical/JSON-LD 매핑의 기준 키로 사용한다.

6. 고향사랑e음 연동 아키텍처

6.1 연동 범위 - 공공 경유 vs 우리 자체

기능을 책임 주체별로 분리한다. 법적 효력이 발생하는 영역(기부접수/본인확인/영수증/세액공제)은 전량 e음 경유, 사용자 경험·상품·커머스는 우리가 소유한다.

6.2 기부 시퀀스 (사용자 → 우리 플랫폼 → e음 API → 지자체 기금)

[정상 플로우: 기부 + 답례품 선택 + 체험 바우처]

사용자            우리 플랫폼(BFF/주문서비스)        e음 API(KLID)         지자체 기금/PG
  │                      │                            │                    │
  │ 1.기부지자체·금액·답례품 선택(비로그인 탐색 OK)    │                    │
  │─────────────────────▶│                            │                    │
  │                      │ 2.룰 사전검증(주소지 외/한도/30%룰)              │
  │                      │   - 클라 즉시 + 서버 재검증 │                    │
  │ 3.로그인/본인확인(결제 직전 1회)                   │                    │
  │─────────────────────▶│ 4.본인확인 요청(CI/주소)   │                    │
  │                      │───────────────────────────▶│ 5.실명+주소지 판정 │
  │                      │◀───────────────────────────│   (주소지 외 OK?)  │
  │                      │ 6.기부 접수요청(idempotencyKey, 멱등)            │
  │                      │───────────────────────────▶│ 7.기부번호 발번    │
  │                      │                            │   → 지자체 기금 귀속│
  │                      │◀───────────────────────────│ 8.기부확정+영수증ID│
  │                      │ 9.우리 주문 confirm        │                    │
  │                      │   (답례품/체험 = 우리 매출 라인 분리 기록)       │
  │                      │ 10.답례품 결제/체험 바우처 발급(우리 PG)─────────▶│
  │◀─────────────────────│ 11.완료(기부영수증+주문번호 동시 표시)          │
  │                      │                            │                    │

[보상 트랜잭션] 7~10 사이 실패 시:
  - e음 기부 확정 후 우리 confirm 실패 → e음 기부는 유효, 주문만 재시도 큐
  - 답례품 결제 실패 → 기부는 살리고 답례품만 '미수령/재선택' 상태로 분리
  - 기부 접수 실패(8 NACK) → 답례품 결제 미실행, 주문 전체 void

핵심: 기부 확정(8단계)이 트랜잭션 경계의 기준점이다. 답례품·체험은 기부 확정 이후에만 결제를 태워 "돈은 빠졌는데 기부는 안 된" 상황을 원천 차단한다.

6.3 인증·본인확인 (주소지 외 기부 검증)

법령상 개인 본인만, 본인 주소지 외 지자체에만 기부 가능. 검증은 2단계로 한다.

1. 우리 측 사전 검증(UX): 회원 주소(시군구 코드)와 기부 대상 지자체 코드 비교 → 동일 시 결제 버튼 비활성 + "주소지 본인 지자체에는 기부할 수 없습니다" 안내. 연 한도(2,000만원, 2025.1.1~) 누적치 표시.
2. e음 최종 판정(법적 효력): 본인확인 응답의 주소지와 대상 지자체를 e음이 재판정. 우리 캐시 주소가 낡았어도 e음이 최종 거절하면 거절 사유 코드로 차단. 우리 판정은 e음 판정을 절대 덮어쓰지 않는다.

본인인증 방식은 e음 표준 연계 방식을 따른다(간편인증/공동인증서 등). 우리는 인증 결과 토큰만 보관하고 주민번호 평문은 저장하지 않는다.

6.4 정산 흐름 - 기부(지자체 귀속) vs 답례품·체험(우리 매출)

한 번의 주문에서 자금 흐름이 둘로 갈린다. 회계·세무·정산 라인을 물리적으로 분리한다.

주문 1건에 order_id 하나, 그 아래 donation_line(e음 기부번호 연결)과 commerce_line(답례품/체험, 우리 매출)을 별 테이블로 둔다. 세금계산서·정산·환불 정책이 라인별로 완전히 다르므로 절대 한 금액으로 합산 기록하지 않는다.

6.5 영수증·연말정산 연동

6.6 지자체별 입점 계약·수수료 처리

전국 243개 지자체와 개별 입점 계약. 수수료 5~10% 구간을 지자체별로 다르게 설정·정산할 수 있는 데이터 모델이 필요하다.

ERD (입점·수수료 핵심)

municipality (지자체 243)
  ├─ muni_id (PK)  region_code  name
  └─ status: contracted | pending | suspended

partner_contract (입점 계약, muni_id 1:N 가능 - 갱신 이력)
  ├─ contract_id (PK)  muni_id (FK)
  ├─ fee_rate (DECIMAL 5~10%)        # 수수료율
  ├─ fee_base: gift_only | gift+exp  # 수수료 부과 대상(답례품만/체험포함)
  ├─ settle_cycle: monthly|biweekly
  ├─ valid_from / valid_to
  └─ contract_doc_id                 # 전자계약 원본

gift_catalog (답례품, muni_id별)
  ├─ gift_id (PK)  muni_id (FK)  price  category_code
  └─ supply_source: nolgofarm_stock | local_supplier

settlement (정산, 월 마감)
  ├─ settle_id  muni_id  period
  ├─ donation_count / gift_amount / exp_amount
  ├─ fee_amount = base × fee_rate
  └─ payout_to_muni / payout_to_us

수수료는 기부금이 아니라 답례품·체험 공급액 기준으로 산정(기부금은 전액 지자체 귀속이므로 우리가 떼지 않음). fee_base 플래그로 체험 매출을 수수료 대상에 포함할지 계약별 토글.

6.7 장애·재시도·멱등성·정합성

외부 공공 API는 우리 통제 밖이다. "기부는 됐는데 화면엔 실패", "돈은 빠졌는데 기부 안 됨"을 모두 막는다.

• 멱등성: 모든 기부 접수 요청에 idempotencyKey(주문UUID 기반) 부여. 동일 키 재시도 시 e음/우리 모두 중복 발번 금지. 타임아웃 후 무조건 재조회(상태 확인)부터.
• 재시도: 네트워크 타임아웃은 지수 백오프(1s→4s→16s) 최대 3회. 응답 불명(timeout)은 실패로 단정하지 않고 조회 API로 확정(기부번호 존재 여부).
• 아웃박스 패턴: 기부확정 이벤트를 outbox 테이블에 기록 후 비동기 후처리(답례품 결제·바우처 발급). 우리 후처리가 죽어도 기부 정합성은 유지.
• 보상 트랜잭션: 6.2의 실패 분기대로 기부/커머스 라인을 독립적으로 롤백·재시도. 기부 살리고 답례품만 재선택 가능.
• 정합성 배치: 일 1회 e음 기부내역 ↔ 우리 donation_line 대사(reconciliation). 불일치 건 알림 + 수동 처리 큐.
• e음 점검시간 대응: 공공 시스템 정기점검 시 기부 접수 버튼을 "점검 중 - 잠시 후" 상태로 전환, 답례품 탐색·체험 예약(우리 자체)은 정상 운영(외부 떠넘김 0건 원칙 유지).

6.8 개인정보 위탁·보안 (ISMS-P)

• 최소수집·미저장: 주민등록번호 평문 미저장. 본인확인은 e음/인증기관 결과 토큰(CI 등)만 보관. 주소는 시군구 코드 수준으로 룰 검증용 최소 보관.
• 위탁 구조 명시: 우리=기부접수 중개 및 답례품 운영 수탁자, e음/KLID=기부 원장 주체, 지자체=기금·답례품 공급 주체. 위탁계약서·개인정보 처리방침에 흐름 명문화.
• 암호화: 전송 TLS 1.2+, 저장 시 민감정보 AES-256, 키 분리 관리. e음 연계 구간 전용 인증서/IP 화이트리스트.
• 접근통제·로그: 기부/정산 데이터 접근 RBAC, 전 구간 감사로그 보존, 이상접근 탐지.
• ISMS-P 정합: 기술목표 ISMS-P급 보안과 일치. 공공 연계 시스템 보안 요구사항(망분리/연계 보안성 검토) 충족 설계.

6.9 확인 필요 항목 (블로커/계약 전 검증)

기존 자산: 아이러브고향에 e음 연동 백엔드가 이미 존재하므로, 신규 구축이 아니라 규격 재확인 후 신플랫폼 BFF로 재배선하는 것이 합리적. #9가 1순위 확인 항목.

7. 디자인 시스템

7.1 폰트 — Pretendard Variable

레거시의 Pretendard 폰트 OTS 디코드 실패 이슈를 해결하기 위해, woff2 단일 포맷의 Pretendard Variable을 self-host한다. font-display: swap으로 FOIT를 방지하고, 시스템 폰트 폴백 스택을 지정해 폰트 로드 실패 시에도 한글 가독성을 보장한다. 숫자(기부액·달성률·세액공제)는 font-variant-numeric: tabular-nums로 자릿수 정렬한다.

@font-face {
  font-family: 'Pretendard Variable';
  src: url('/fonts/PretendardVariable.woff2') format('woff2-variations');
  font-weight: 45 920; font-display: swap;
}
:root { --font-sans: 'Pretendard Variable', -apple-system, 'Apple SD Gothic Neo',
                     'Noto Sans KR', system-ui, sans-serif; }

타입스케일(모바일퍼스트 기준, px·weight·line-height·용도):

최소 본문 15px 이상 유지(접근성). 텍스트가 박힌 이미지는 사용 금지하고 모두 실제 텍스트로 렌더한다(레거시 '텍스트 박힌 이미지' 폐기).

7.2 컬러 토큰 — 2축 팔레트

두 서비스의 정체성을 색으로 구분한다. 기부 축(신뢰 톤, 블루)은 아이러브고향·고향사랑기부 흐름에, 체험 축(생기 톤, 그린)은 놀고팜·농촌여행 흐름에 적용한다. CTA·결제·강조 액션은 축과 무관하게 주황 포인트로 통일한다. 위기브 보라/민트는 모던 톤 참고용 액센트로 제한 사용한다.

중립 그레이스케일(텍스트·보더·배경 공통):

대비 검증(WCAG AA): gray-800(#2B313B) on gray-0 = 12.4:1, gray-600 on gray-0 = 5.0:1(본문 AA 통과). CTA 텍스트는 #F9AA24 위 흰 글씨가 대비 미달(약 1.9:1)이므로 주황 버튼의 라벨은 gray-900(#161A20)으로 지정(대비 약 9:1)한다. 동일 색만으로 정보 전달 금지 — 달성률·상태는 색+텍스트+아이콘 병행.

7.3 간격·라운드·그림자·브레이크포인트 토큰

상세 페이지 레이아웃: lg(1024) 이상에서 좌측 스크롤 콘텐츠 + 우측 sticky 기부/예약 패널(top offset 24px) 2단 구성, 미만에서는 단일 컬럼 + 하단 고정 액션바(sticky bottom CTA).

7.4 핵심 컴포넌트 카탈로그

7.5 접근성 규칙(WCAG 2.1 AA)

• 줌 허용: <meta name="viewport" content="width=device-width, initial-scale=1"> — 레거시 줌차단(user-scalable=no, maximum-scale) 제거. 최대 200% 확대 가능.
• 대체텍스트: 모든 의미있는 이미지에 alt(답례품·체험 썸네일=상품명, 장식 이미지=alt=""). 목표 alt 누락 0건.
• 대비 AA: 본문 텍스트 4.5:1, 큰 텍스트(24px+/19px 700) 3:1 이상. 주황 CTA는 흰 글씨 금지·gray-900 라벨로 충족.
• 실제 텍스트: 가격·달성률·세액공제액·축제 정보 등을 이미지에 박지 않고 DOM 텍스트로 렌더(검색·스크린리더·확대 대응).
• 구조: 페이지당 h1 1개, 논리적 헤딩 위계, lang="ko", 키보드 포커스 가시화(:focus-visible), 폼 라벨 연결, 상태 변화 aria-live.
• 색 비의존: 달성률·재고·출석 상태를 색만으로 전달하지 않고 텍스트·아이콘·패턴 병행.

7.6 운영 방식 및 Claude 디자인 활용 제안

디자이너 부재를 고려해 토큰을 코드 단일 출처로 운영한다. CSS Custom Properties(:root) 또는 Tailwind theme.extend에 위 토큰을 그대로 정의하고, 컴포넌트는 Storybook으로 카탈로그화해 상태·접근성을 회귀 검증한다.

• 초기 시안·컴포넌트 목업·일러스트는 Claude 기반 디자인 워크플로(gstack-design-consultation / design-shotgun)로 변형안을 빠르게 생성·비교해 디자이너 공백을 메운다.
• 토큰표(7.1~7.3)를 그대로 디자인 프롬프트의 제약으로 입력해 일관성을 유지한다(2축 팔레트·주황 CTA 한정 규칙 포함).
• 생성 결과는 본 문서의 접근성 규칙(7.5)으로 검수 후 코드화 — 자동 생성물이 대비·alt·실제텍스트 규칙을 위반하지 않도록 게이트.

8. 운영/관리자(Admin)

8.1 모듈 맵 (12개 모듈)

8.2 RBAC 역할 표

최소권한 원칙. 지자체운영자는 자기 지자체 데이터만(data scope = orgId) 접근. 슈퍼관리자만 RBAC·정산 확정 권한 보유.

8.3 신뢰훼손 방지 정책 - 진열 차단 게이트

레거시 실패(0원 productOld, 캠핑 245p 무가격·0리뷰, 팝업존 플레이스홀더, 평점 0 만연)를 시스템 차원에서 봉쇄. 게시(publish) 시점에 발행 검증기가 차단 사유를 반환하면 상태는 BLOCKED로 떨어지고 절대 노출되지 않는다.

8.4 AI 콘텐츠 품질 게이트 (큐레이션 → 승인 워크플로)

AI가 농촌여행/지역/제도 아티클·큐레이션 초안을 생성하되, 사람 승인 없이는 절대 게시 불가. 자동 품질 점수가 임계 미만이면 승인 큐에 도달조차 못하고 반려된다.

8.5 데이터 모델 (핵심 ERD)

Municipality(orgId PK, 명칭, 계약상태, 수수료율%, 정산주기)
   │1                                    │1
   │N 답례품                              │N 지정기부
RewardItem(id PK, orgId FK, 분류코드,     Campaign(id PK, orgId FK, 목표액,
  판매가, 재고, 최소기부금,                 모금액, 달성률%, 사용처명세,
  상태[DRAFT|PUBLISHED|BLOCKED])           심사상태[등록|심사중|승인|반려])
   │                                       │
   └──────────┐               ┌───────────┘
              │N              │N
        Order(id PK, memberId FK, type[기부|예약],
          금액, orgId FK, 결제상태, 영수증상태)
              │1
              │1  e음 연동
        TaxReceipt(id PK, orderId FK, e음발급ID,
          공제유형[전액|16.5%], 공제액, 정합성[OK|불일치])
              │
        Settlement(id PK, orgId FK, 기간, 총주문액,
          수수료차감, 지급예정액, 상태[대기|확정|지급])

Member(id PK, CI, 주소지코드, 연누적기부액, 상태)
Content(id PK, type[아티클|소식|축제], origin[휴먼|AI],
  품질점수, 승인상태, alt충족, 게시상태)
AuditLog(id PK, actorId, action, target, before/after, ts)

8.6 통계·대시보드 (기부 KPI)

8.7 주문/정산/영수증 처리 흐름

1. 기부 접수: 결제 직전 로그인 → 본인확인(주소지 검증, 본인 지자체 차단) → 고향사랑e음 API로 접수
2. 영수증: e음이 본인확인·세액공제 영수증 발급 → TaxReceipt에 e음발급ID 매핑, 정합성 자동 대사(불일치 시 정산 보류)
3. 답례품 매칭: 30%룰 통과 답례품만 선택지 노출, 공급주체=지자체로 발주
4. 정산: 지자체별 정산주기로 총주문액 집계 → 수수료(5~10%) 차감 → 정산담당 검토 → 슈퍼관리자/운영총괄 확정 → 지급
5. 여행 바로결제: 놀고팜 실물재고 트랜잭션은 즉시 결제·바우처 발급, 기부 동선과 별도 정산

8.8 착수 로드맵

전 모듈 공통: 모바일에서도 검수 큐·CS 티켓 처리 가능한 반응형 백오피스. 표 기반 일괄 작업(다중선택 승인/반려/차단)으로 디자이너·기획자 없는 소수 운영 인력의 처리량 확보.

9. 기술 아키텍처 & 비기능 요구

9.1 스택 추천과 근거

9.2 아키텍처 다이어그램

                          ┌─────────────────────────────┐
        사용자(모바일퍼스트) │   CloudFront (CDN, TLS1.3)   │
        ───────────────────▶│   WAF / OWASP 룰 / 봇 차단    │
                          └───────────────┬─────────────┘
                  정적·ISR 캐시 ┌──────────┴──────────┐ /api/*
                  ┌───────────▶│  Next.js (SSR/ISR)  │───────┐
                  │            │  next/image, JSON-LD │       │ (BFF, 인증 토큰)
                  │            └─────────────────────┘       ▼
            ┌─────┴─────┐                          ┌───────────────────────┐
            │    S3     │◀── 이미지/폰트(woff2) ────│  ALB (Multi-AZ)        │
            │ 원본 자산  │                          └──────────┬────────────┘
            └───────────┘                                     ▼
                                          ┌──────────────────────────────────────┐
                                          │  Spring Boot 3 (모듈러 모놀리스)        │
                                          │  ├ donation  (기부·한도·세액공제 30%룰) │
                                          │  ├ catalog   (답례품·상품·분류코드)      │
                                          │  ├ booking   (체험·숙박·바로결제)        │
                                          │  ├ search    (OpenSearch 색인/질의)     │
                                          │  ├ content   (아티클·후기·출석체크)       │
                                          │  └ identity  (세션·간편인증·권한)        │
                                          └──┬─────────┬─────────┬─────────┬───────┘
                                             ▼         ▼         ▼         ▼
                                      ┌──────────┐ ┌───────┐ ┌────────┐ ┌──────────┐
                                      │PostgreSQL│ │ Redis │ │OpenSrch│ │외부 연동  │
                                      │Multi-AZ  │ │세션/캐시│ │검색색인 │ │e음/PG/PASS│
                                      │+읽기복제 │ └───────┘ └────────┘ └──────────┘
                                      └──────────┘
   외부 연동: 고향사랑e음(본인확인·기부접수·세액공제 영수증) / PG(결제·정산) / 간편인증(PASS·카카오)
   관측: OpenTelemetry → Prometheus + Grafana + Loki / Sentry(FE·BE)

9.3 모놀리식 vs 모듈러 권고

BFF는 Next.js Route Handler가 담당(인증 토큰 핸들링·응답 조합). 별도 Node/NestJS BFF는 도입하지 않아 운영 단순성을 지킨다.

9.4 비기능 요구 (NFR)

9.5 레거시 정리 액션

• 도메인 통합: nolgofarm.com / ilovegohyang.* / ilovegohyangai.org(AI 3번째 도메인) → 단일 도메인 1개로 통합, 구 URL은 301 영구 리다이렉트 맵 작성.
• URL 정책: productOld·jsessionid 파라미터 완전 제거, /{slug}--{uuid} 패턴 + canonical 강제.
• 0원·무가격 데이터: 스토어 productOld 0원 가격, 캠핑 245p 무가격·0리뷰 디렉터리 → 마이그레이션 시 가격·재고 검증 게이트 통과 못 하면 비공개.
• 폰트: OTS 디코드 실패 Pretendard → Pretendard Variable woff2로 교체, font-display: swap + preload.
• 팝업존 플레이스홀더: 아이고 홈 라이브 플레이스홀더 제거, CMS 연동 실데이터로 대체.

9.6 CI/CD · IaC

참고: 검색(OpenSearch)·결제·인증 같은 외부 의존은 장애 격리를 위해 서킷 브레이커(Resilience4j)와 폴백(검색 다운 시 PG full-text 폴백)을 적용한다.

10. 마이그레이션 전략

10.1 현 상태 진단 — 무엇을 이관·정리·차단할 것인가

마이그레이션 대상을 이관(carry-over), 정제(cleanse), 폐기(retire)로 분류한다. 잘못된 데이터를 그대로 신규로 옮기면 신규 플랫폼이 레거시의 신뢰 문제를 상속하므로, 추출 단계에서 게이트를 건다.

10.2 P0 신뢰훼손 버그 — 마이그레이션 착수 전 즉시 차단

아래 4건은 신규 오픈을 기다리지 않고 레거시 프로덕션에서 먼저 수정/차단한다. 잠재 기부자·예약자에게 노출되는 동안 발생하는 신뢰 손실이 비용보다 크기 때문이다.

P0 차단은 신규 빌드와 병행 가능한 독립 작업이다. 레거시 코드 동결(freeze) 전 마지막 핫픽스로 처리하고, 이후 레거시는 읽기 위주 유지보수 모드로 전환한다.

10.3 데이터 마이그레이션 계획 — 도메인별 ETL

추출(Extract)→정제·변환(Transform)→적재(Load) 3단계. 핵심 변환은 정수 PK → 슬러그--UUID 매핑, 레거시 ID → 신규 ID 매핑 테이블 영구 보존(301 리다이렉트·외부 참조 복원에 사용)이다.

레거시 ID 매핑 테이블(영구 보존)
┌──────────────┬───────────────┬──────────────────────────────┬─────────┐
│ legacy_domain│ legacy_id      │ new_uuid                     │ slug    │
├──────────────┼───────────────┼──────────────────────────────┼─────────┤
│ nolgofarm    │ product/1024  │ 7f3a...e21                   │ 곡성-딸기체험 │
│ ilovegohyang │ donation/55012│ a1c9...09b                   │ -       │
│ ilovegohyangai│ rec/88       │ (폐기, AI추천 신규 재생성)    │ -       │
└──────────────┴───────────────┴──────────────────────────────┴─────────┘
용도: ① 301 리다이렉트 소스 ② 외부 백링크/검색엔진 인덱스 복원 ③ 기부영수증 역추적

10.4 도메인 통합 — 3도메인을 단일 도메인으로

예약(nolgofarm)·기부(ilovegohyang)·AI추천(ilovegohyangai.org) 3분할을 폐기하고 단일 도메인·단일 GNB·단일 세션·단일 장바구니·단일 검색으로 흡수한다. AI추천은 별도 도메인을 두지 않고 신규 플랫폼 내 추천 모듈로 내재화한다. 코드 내부의 toNolgofarm()·toGohyang() 같은 도메인 간 점프 라우팅은 내부 경로로 흡수해 외부 떠넘김(redirect to other domain)을 0건으로 만든다.

SEO 보존

• 레거시 URL 전수를 매핑 테이블 기반 301 영구 리다이렉트로 신규 슬러그--UUID에 1:1 연결(404 0건 목표).
• 신규는 <link rel="canonical"> 단일 도메인 지정, jsessionid 등 세션 파라미터를 URL에서 완전 제거.
• JSON-LD(Product/Event/Offer/BreadcrumbList) 구조화 데이터 부여, <html lang="ko">, 페이지당 h1 1개.
• 신규 sitemap.xml 제출 + 구 도메인 sitemap에 리다이렉트 적용, Search Console 주소 변경 신고로 인덱스 이전 가속.

고향사랑e음 연동 승계 (변경 금지 경로)

10.5 단계적 컷오버 — 스트랭글러 패턴

빅뱅 전환을 피하고, 신규 플랫폼이 레거시를 화면 단위로 '조여 가며(strangle)' 트래픽을 흡수한다. 리버스 프록시(엣지 라우터)가 경로별로 신규/레거시를 분기하고, 비율을 점진 상향한다.

      [사용자/검색봇]
            │
      [엣지 리버스 프록시]  ← 경로/비율 기반 라우팅, 즉시 롤백 스위치
        ├── /donation/**   → 신규(병행 검증 후 100%)
        ├── /experiences/* → 신규
        ├── /store/**      → 신규 (P0 정제 완료분만)
        ├── /e음-callback/* → 레거시 백엔드 그대로 프록시(변경금지)
        └── /legacy/**     → 레거시(잔여 트래픽, 점차 0으로)

10.6 병행 운영과 롤백

10.7 리스크와 대응

10.8 완료 정의(Definition of Done)

• 도메인: 외부로 떠넘기는 리다이렉트 0건, canonical 단일 도메인, ilovegohyangai.org 폐기·흡수 완료.
• 데이터: productOld 0건, 0원 가격 0건, 평점 0 노출 0건(리뷰없음 정규화), 기부·결제 금액 합계 100% 정합.
• 기술: jsessionid URL 노출 0, alt 누락 0, h1 1개/페이지, lang=ko, JSON-LD/canonical 적용, TTFB < 100ms.
• e음: 신규 도메인으로 접수·본인확인·영수증 100% 정상, 243 지자체 정산 키 무손실 승계.
• 롤백: 분 단위 복구 스위치 검증 완료, 90일 안정화 후 레거시 인프라 회수(리다이렉트만 잔존).

11. 로드맵 & 마일스톤

11.1 단계 요약 & KPI 게이트

11.2 병행 트랙 정의

11.3 P0 — 긴급 안정화 + 도메인 통합 결정 (W1-3)

P0 KPI 게이트 미통과 시 P1 착수 보류. 도메인 결정은 SEO 자산·브랜드·검색 노출을 고려한 단일 의사결정으로, 이후 모든 트랙의 선행 의존성.

11.4 P1 — 기부 깊이 + 차별 동선 (W4-10)

11.5 P2 — 콘텐츠 · 리텐션 (W11-18)

11.6 P3 — 고도화 (W19-28)

11.7 핵심 의존성 체인 & 임계 경로

임계 경로(Critical Path):
M0.1 도메인결정 ─▶ M1.2 통합셸 ─▶ M1.3 답례품 ─▶ M1.5 지정기부 ─▶ M1.6 USP연결 ─▶ M3.1 입점콘솔 ─▶ M3.3 최종

병행 가능(임계 경로 외):
  콘텐츠 트랙(M2.1~2.3) … M1.1 이후 독립 진행
  성능/접근성 풀튠(M3.2) … 전 트랙 산출물 위에서 마감

게이트:    [P0게이트]   [P1게이트]      [P2게이트]      [P3 최종게이트]
주차:   W3 ──────── W10 ──────────── W18 ──────────── W28

병목 1순위는 e음 API 연동(공공 시스템 경유, 본인확인·영수증)과 지자체 개별 입점 계약(243곳)이며, 둘 다 외부 일정 의존이므로 P1·P3 게이트 통과 시점의 최대 리스크 요인. 입점 계약은 P1과 병행해 영업 트랙으로 선행 착수 권장.

12. 일정·소요인원·비용·인프라(월)

공통 가정

• 범위 가정: 단일 도메인 통합(예약+기부+추천), e음 API 연동, 답례품-농촌체험 바우처 연계, 기부 깊이(계산위젯/지정기부/모금게이지), 콘텐츠·커뮤니티(아티클/출석/후기), 모던 SPA 재구축(레거시 jQuery+jsessionid 폐기).
• 인건비 단가: 블렌디드 월 단가(아래 C 표). 시니어/미들 혼합 평균치이며 ±15% 변동 가정.
• 트래픽 가정: 초기 MAU 3만/피크 동시접속 약 300~500세션(약 150~250 RPS), 성장기 MAU 30만/피크 약 1,500~2,500 RPS. 기부 성수기(연말 12월) 피크는 성장기 기준 2~3배 일시 스파이크 가정.
• 인프라 가정: 클라우드(AWS/NCP 가격대) managed 서비스 우선, 단일 리전(ap-northeast-2). 자체 IDC 미고려. ISMS-P급 보안 요건(로그/암호화) 비용 포함.
• 제외 항목: 243개 지자체 개별 입점 계약/영업 비용, e음(행안부·지역정보개발원) 연동 인증 절차 비용, 디자인 외주 별도 발주 시 추가분, 마케팅·콘텐츠 대량 생산 비용은 본 추정 외.

A. 예상 일정 (단계별 개월수)

가정: 인력 적시 확보·요구사항 동결 전제. e음 API 연동 승인 지연 시 P1이 0.5~1개월 슬립할 수 있음(외부 의존 리스크).

B. 소요 인원 (롤별 FTE, 단계별 투입)

가정: FTE 1.0=풀타임. 액티부키는 현재 디자이너·기획자 부재 → 디자이너/PM은 P0~P1 외부 또는 신규 채용으로 충당 권장. 데이터/AI는 추천·검색·콘텐츠 자동화 겸임. 피크 동시 투입 최대 9~10명(P1).

C. 예상 개발비용 (인건비 기반)

가정: 간접비(사무·관리)는 블렌디드 단가에 포함. 예비비 10~15% 별도 권장. 정부 R&D/지역 매칭 활용 시 실부담 절감 가능(미반영).

D. 예상 인프라 비용 (월 단위, 2시나리오)

PG/결제 수수료(거래액 비례, 별도): 예약·스토어 카드결제 약 2.0~2.8%. 기부는 고향사랑e음 공공시스템 경유 → 일반 PG와 구조 상이, 지자체 입점 수수료 5~10%는 정산 수익구조 항목(인프라 아님). 가정: 월 거래액 1억 시 카드 PG 약 ₩200만~280만 발생.

E. 외주 vs 내재화 & AI 에이전트 절감 가설

종합 가정: 본 추정의 절감 수치는 내부 검증 전 가설이며, P0 종료 시 실제 속도(velocity) 측정으로 재산정 권장. 과도한 정밀치로 해석하지 말 것.

13. AI 에이전트 병렬 작업 분배(PM)

13.1 에이전트 역할 정의

각 에이전트는 독립 git worktree와 전용 컨텍스트(담당 디렉터리·스킬셋)를 갖는다. PM-오케스트레이터만 전체 리포를 보며 통합·중재한다.

13.2 파트별 담당·산출물·의존성 (RACI)

R=실행, A=최종책임, C=협의, I=통보. H=휴먼 PM.

13.3 병렬 가능 vs 직렬 의존

13.4 작업 분해(WBS)

13.5 핸드오프 / 통합 지점

핸드오프는 코드가 아니라 계약(contract)으로 전달한다. 계약 동결 후에만 하위 에이전트가 병렬 착수한다.

[동결순서 1] A2 → 전원   : tokens.css + Storybook (디자인 계약)
[동결순서 2] A3 → A4,A5,A6: openapi.yaml + ERD (데이터/API 계약)
[통합지점 1] A2⊕A4       : 컴포넌트 prop 시그니처 (Storybook 스냅샷 일치)
[통합지점 2] A3⊕A5       : 마이그레이션 후 스키마 = OpenAPI 모델 정합
[통합지점 3] A6⊕A3⊕A4   : e음 영수증 ↔ 주문 ↔ 세액위젯 값 일치 (E2E)
[통합지점 4] A4⊕A7       : alt/JSON-LD 슬롯 채움 (Lighthouse SEO/A11y)
[최종통합]   A1          : 워크트리 머지 → 통합 브랜치 → 회귀 게이트

13.6 휴먼 인더루프(HITL) 체크포인트

AI가 자율 진행하되, 비가역·법적·브랜드 정체성 지점에서만 휴먼 PM(david)이 승인한다. 게이트 통과 전 다운스트림 머지 금지.

13.7 품질 게이트 (자동 차단)

A8/A9가 운영하는 머지 차단 규칙. 하나라도 실패 시 PR 머지 불가.

• 접근성: alt 누락 0건, h1 정확히 1개, 줌차단 메타 부재, 명도대비 AA 충족 → 실패 시 차단
• 성능: TTFB<100ms, LCP<2.5s, CLS<0.1(스켈레톤 필수), Lighthouse 90+
• SEO/구조: canonical·JSON-LD·lang=ko 존재, jsessionid/productOld/0원가격 0건
• 도메인 정합: 세액·30%룰 테스트벡터 100% pass, 비로그인 전과정 탐색 E2E pass
• 통합: 단일 GNB/세션/장바구니, 외부 떠넘김 0건, 별점 0·무가격 잔존 0건

13.8 메타 근거 - 이 기획서 자체가 증명

이는 디자이너·기획자가 없는 액티부키가 동일 패턴으로 실제 개발도 수행 가능함을 입증한다. 기획서 13섹션 = 구현 9에이전트로 1:1 대응되며, 본 문서의 병렬 집필에서 검증된 핸드오프(계약 우선)·HITL(팩트체크)·품질게이트(스키마 검증) 구조를 그대로 코드 생산에 이식하면 된다. 방법론의 자기증명(self-evidence): 읽고 있는 이 산출물이 곧 작동 증거다.