# F-13 시장정보·기획 피드백 루프

## 운영 목적

외부 고객·경쟁·시장 신호를 내부 제품·판매·원가·공급 가능성과 연결하고, 검토한 기회를 작은 실험으로 전환한다. 결과가 기대와 달라도 원인과 배운 점을 남겨 다음 기획에 재사용한다. 일회성 보고서를 반복 생산하는 대신 **어떤 근거 때문에 무엇을 바꿨고 그 결과가 어땠는지**를 추적하는 것이 목적이다.

이 문서는 2026-09-10 기준 제안이며 실제 수집 스케줄·AWS 배포·광고 실험이 실행된 것은 아니다. F-13 외부시장 MI를 중심으로 F-07 제품마스터, F-04 판매계획, F-08 프로모션, F-09 광고·실적과 연결한다. 기존 ERP 수정은 범위 밖이며 파일 우선·기존 API 재사용 원칙을 따른다.

## 운영 흐름

```mermaid
flowchart LR
  E[외부 신호<br/>검색·제품·리뷰·시장 통계] --> S[출처·관찰 스냅샷<br/>국가·기간·SKU 버전]
  I[내부 근거<br/>제품·판매계획·판매추이·마감정산] --> M[검토한 제품·채널 매핑]
  S --> M
  M --> H[기회 가설<br/>근거·반대 근거·확신도]
  H --> G{BM·채널 검토<br/>실행 가능·예산 상한}
  G -->|승인| X[작은 실험<br/>제품·채널·메시지·비교조건]
  G -->|보류·기각| L[학습 기록<br/>판정·이유·재검토 조건]
  X --> P[구매 시점 판매추이<br/>반응·주문·취소]
  X --> C[마감 정산내역<br/>비용·반품·공헌 검토]
  P --> R[평가<br/>주문 반응과 확정 경제성 분리]
  C --> R
  R --> L
  L -->|새 질문·타깃·수집 우선순위| E
  L -->|검증된 요구| H
```

## 도구와 역할 분담

초기에는 **ERP Core 화면 + 승인된 파일 업로드 + AWS 업무 RDB + 원천 파일 저장소**로 운영한다. UI는 입력·검토·검색 창이고, 원본·규칙·이력은 서버에서 관리한다. Excel/Google Sheets는 허용된 수집·제출 경로로 유지하되 기회 승인 상태를 개인 시트에만 두지 않는다. API가 이미 운영 중인 채널은 기존 경로를 재사용한다.

| 계층 | 초기 도구·방식 | 반복 가치 확인 후 | 통제 |
|---|---|---|---|
| 외부 수집 | 담당자가 공개 페이지·허용 CSV·계약된 리포트 등록 | 승인된 공식 API 수집 worker | 출처·라이선스·국가·기간·쿼리 조건 기록 |
| 내부 수집 | 기존 가공 제출 파일, ERP 읽기, 기존 Make/BigQuery 결과 | 반복 오류가 적은 데이터부터 정기 적재 | ERP 쓰기와 조회 분리, 기준일·확정 상태 보존 |
| 파일 보존 | S3 후보, 출처·해시·수령시각과 버전 연결 | 버전 관리·보존기간·비용 규칙 | 소스별 이용권한에 맞는 보존, 만료·삭제 이력 |
| 업무 저장 | AWS RDB 후보, 공통 제품·기회·실험·판정 테이블 | 정규화 관측·성과 집계 | 역할별 읽기/수정, 승인·수정 로그 |
| 스케줄 | 초기 담당자 일정·작업 대기열 | EventBridge Scheduler 또는 기존 승인 스케줄러 | 재시도 중복 방지·실패 알림·최종 성공 시각 |
| 요약·태깅 | 사람이 기준표로 태깅, AI는 초안 보조 | 검수 데이터로 태깅 후보 추천 | 원문 근거·모델/프롬프트 버전, 사람이 판정 |
| 의사결정 | F-13 기회 원장·실험 검토 화면 | 누적 학습 검색·유사 실험 추천 | 사람이 승인, 자동 예산 집행·신제품 결정 없음 |

S3 Versioning은 덮어쓴 객체의 이전 버전 보존을 지원하며 각 버전에 저장 비용이 발생한다. EventBridge Scheduler는 반복 일정과 재시도를 지원하므로 동일 배치 재실행을 가정한 중복 통제가 필요하다. 현재 CMSLAB에서 해당 구성이 가동 중이라는 뜻은 아니다. [AWS S3 Versioning](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html), [AWS EventBridge Scheduler](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html).

## 소스별 수집·검토 주기 제안

| 대상 | 첫 방식 | 제안 주기 | 책임 역할 후보 | 실패·공백 처리 |
|---|---|---|---|---|
| 네이버 검색어·쇼핑 관심 | 동일 조건 CSV/화면 관찰, 발급 후 공식 데이터랩 API | 주 1회 수집·월 비교 | 기획/국내 MC | 미수집은 0으로 채우지 않음. 검색량과 구매량 구분 |
| Google Trends | 국가·카테고리·기간 고정한 export | 주 1회 또는 월 1회 | 글로벌/동북아 MC | 표본·정규화 조건 보존. 다른 쿼리의 100을 직접 비교하지 않음 |
| 경쟁 SKU 가격·구성·표현 | 공식몰·리테일러 허용 관찰표 | 핵심 8개 주 1회, 후보군 월 1회 | BM+채널 | 국가 처방·번들·용량 변경 시 새 버전. 자동스크래핑 가정하지 않음 |
| 리뷰·고객 불편 | 최근/낮은 별점/긍정/비협찬 구분한 표본 등록 | 월 1회, 리뉴얼·클레임 때 추가 | BM+CS/RM | 삭제·접근 제한은 표시. 개인 식별자는 최소화 |
| 광고·콘텐츠 | Meta/TikTok 공개 라이브러리 관찰 및 자사 승인 리포트 | 주 1회 소재 점검·월 평가 | MC/GMC/동북아 MC | 경쟁 소재 노출은 지출·전환 증거가 아님 |
| 유튜브 공개 댓글 | 우선 수기, 필요 시 공식 API 권한·쿼터 확인 | 선택 영상 월 1회 | 콘텐츠팀 | 댓글 불가/삭제/편향 표시. 원문 전량 축적을 기본으로 두지 않음 |
| 거시·국가 통계 | 공공 통계·NIQ/Euromonitor/Mintel 공개 또는 계약 리포트 | 월간 확인·분기 종합 | 기획/해외영업 | 공개요약과 유료전문 구분, 통계 개정본 연결 |
| 자사 판매추이 | 현재 채널 제출 파일/기존 API | 확보 가능한 일간, 미확보는 주간 | 채널 담당 | 고객구매일·완료율·최종 수집시각 표시 |
| 판매계획 | 기존 양식과 변경 사유 | 월간 기준+수정 발생 시 | 채널/경영관리 | plan_version·작성/승인시각, 과거 계획 덮어쓰기 금지 |
| 마감 정산·비용 | 재경 전달 파일과 마감 승인 상태 | 실제 마감 주기, 잠정은 별도 | 채널+재경 | 주문 반응 평가와 비용 확정 평가를 분리 |
| 품질·반품·사용 경험 | CS/RM 기존 자료의 집계·분류 | 월간, 중요한 이상은 즉시 별도 검토 | CS/RM+BM | 발생률 분모·기간 확인, 개별 건강정보 노출 제한 |

네이버 데이터랩은 별도 애플리케이션 인증이 필요하다. Google Trends는 상대 검색 관심이다. YouTube의 댓글 목록 API는 문서상 조회 경로를 제공하지만 모든 댓글이나 플랫폼을 수집할 권한을 부여하지 않는다. [네이버 문서](https://developers.naver.com/docs/serviceapi/datalab/search/search.md), [Google Trends 설명](https://support.google.com/trends/answer/4365533?hl=en), [YouTube 댓글 목록](https://developers.google.com/youtube/v3/docs/commentThreads/list).

## 운영 리듬과 결정

**주간 30분 제안:** 새 신호 전부를 보고하지 않고 기존 가설을 바꿀 만한 3건 이내를 검토한다. 근거 만료·제품 버전 변경·누락을 확인하고 추가 조사 또는 실험 후보로 분류한다. 시간과 건수는 운영 실험의 초기 상한이며 확정 회의체가 아니다.

**월간 60분 제안:** BM·채널·마케팅이 진행 실험의 반응과 가용한 정산 결과를 검토한다. 진행/중단/보류를 기록하고 다음 주기의 조사 질문을 바꾼다. 정산 미완료면 주문 반응에 대한 잠정 학습과 경제성 판단 보류를 각각 기록한다.

**분기 검토 제안:** 반복된 사용 맥락·불편과 제품군별 강점이 누적됐는지 본다. 새 처방·규격·국가 진입 같은 큰 결정은 이 근거와 공급·표시·경제성 검토가 모인 뒤 다룬다. 기각된 기회를 삭제하지 않고 재검토 조건을 남긴다.

## 최소 데이터 모델

| 객체 | 핵심 필드·키 | 연결·유의점 |
|---|---|---|
| Source | source_id, URL/내부 경로, 발행자, 접근 범위, 수집 방식·주기, owner | 논문·상품 페이지·리뷰·내부 파일을 구분 |
| SourceSnapshot | snapshot_id, source_id, observed_at, published_at, 원본 해시/허용 발췌, 쿼리조건 | 원천이 바뀌어도 판단 당시 증거 유지 |
| MarketObservation | observation_id, snapshot_id, 국가, 기간, 지표, 값, 단위, 범위, 상태 | 회사/브랜드/SKU·실측/추정 구분, 검색지수≠매출 |
| ExternalSKU | external_sku_id, 브랜드, 제품명, 국가, 용량, 처방/표시 버전, 유효기간 | 같은 이름·다른 국가 제품 합치지 않음 |
| ProductMapping | mapping_id, external_sku_id, 내부 PRODUCT/ITEM, 관계유형, valid_from/to, 검토자 | 경쟁/대체/사용상황 유사성은 동일 품목 매핑이 아님 |
| Opportunity | opportunity_id, 타깃·상황·문제, 가설, 반대 근거, evidence_ids, owner, status | 근거 없는 기회는 검토 대기, 상태별 변경 이력 |
| Experiment | experiment_id, opportunity_id, 제품/국가/채널, 비교조건, 예산 상한, 기간, 사전 판정기준 | 비교군 변경·가격·행사·재고 이슈 기록 |
| ExperimentExposure | experiment_id, arm_id, variant_id, campaign/creative/promotion_id, external_offer_id, period, eligible_impressions, valid_visits, orders | 군×기간 집계, 배정 단위·방식과 반복 노출·교차군 처리 규칙 기록 |
| ExperimentProduct | experiment_id, PRODUCT/ITEM, 역할, valid_from/to, 배부 규칙 | 다대다 연결과 번들·사은품, 금액 이중합산 차단 |
| Evaluation | evaluation_id, experiment_id, data_cutoff, 판매추이/정산구분, 결과, 불확실성, 판정자 | 주문과 정산을 직접 원시 조인해 행 증식시키지 않음 |
| Learning | learning_id, evaluation_id, 확인/기각한 가설, 새 질문, 재검토일 | 실패 결과도 검색 가능하게 유지 |

외부 관측은 분석용 AWS RDB에 저장하고 승인된 기회·실험 상태는 플랫폼 업무 원장으로 관리한다. ERP 제품을 참고하되 ERP 품목·수불·정산 원장을 수정하지 않는다. 시장 신호로 내부 판매계획을 자동 덮어쓰지 않는다.

## 내부 데이터와 연결하는 규칙

판매계획, 구매 시점 판매추이, 마감 정산내역은 각각 독립 사실로 유지한다. 비교 차원은 국가·채널·제품·기간이며 서로 다른 날짜 기준을 지운 채 한 숫자로 합치지 않는다. 마감 정산이 늦게 들어오면 같은 실험에 평가 버전을 추가한다.

프로모션은 등록 당시 대상 제품·범위·효력일을 고정한다. 광고 campaign/creative와 주문 연결이 없는 경우 관찰 기간·채널 집계 비교까지만 한다. 직접 귀속이 없는 매출을 광고나 프로모션의 증분 효과라고 부르지 않는다. 캠페인 여러 개에 같은 주문을 전액 중복 귀속하지 않는다.

상품 구성은 채널 offer→유효한 구성품 ITEM으로 풀고 매출·수량 배부 규칙을 따로 둔다. 외부 경쟁 SKU는 내부 SKU와 동일물건 키로 조인하지 않는다. 전체 내부 데이터가 정리되지 않아도 제품군·국가·채널·월 집계로 시작할 수 있다.

실험 시작 전에 비교군 배정 단위·방식, 소재 버전, 적격 노출과 유효 방문의 정의, 중복 주문 제외 기준을 고정한다. 고객 식별자 없이 군×기간별 분모와 분자를 저장하되, 교차군 노출을 배제할 수 없는 경우 그 한계를 명시한다. 무작위 배정이 없는 비교는 인과 효과로 확정하지 않는다.

주문·반품·재구매마다 관찰 기간과 판정 시점을 사전에 정한다. 관찰 기간이 끝나지 않은 코호트는 미결로 두고 평가 버전을 추가한다. 표본 부족, 동시 행사, 다른 국가·처방 SKU 혼입이 있으면 승리 판정을 보류한다.

## 상태·예외·감사

`수집 → 출처검증 → 태깅검토 → 기회검토 → 실험승인 → 실행 → 잠정평가 → 정산평가 → 학습완료`가 기본 상태다. 각 단계에 보류/기각/접근불가 분기가 있고 담당·사유·다음 검토일을 기록한다. 데이터 누락 때문에 실험을 성공으로 확정하지 않는다.

배치키는 소스·수집 조건·대상기간·원본 해시로 구성하고 재시도는 같은 배치를 두 번 적재하지 않도록 한다. 원천 수정본은 덮어쓰지 않고 supersedes 관계로 연결한다. 단위 변경·국가 제품 버전 변경·샘플 편향·미매핑은 검토 대기열로 보낸다.

상태 대시보드에는 최종 성공 수집일, 누락 소스, 매핑 대기, 검토기한 초과, 진행 실험과 예산 상한, 마감 미완료를 표시한다. 접근이 막히면 수기 자료로 대체할지 해당 가설을 보류할지 담당자가 결정한다. 빈 데이터는 관심이나 매출 0이 아니다.

## 성과 지표와 단계별 도입

| 단계 | 먼저 만드는 것 | 통과 기준 제안 |
|---|---|---|
| 첫 2주 | 이 조사 근거를 등록, 핵심 SKU·채널 매핑, 기회 원장 | 선택한 기회마다 근거·반대 근거·내부 확인 항목이 추적됨 |
| 다음 2~4주 | 기존 제품 메시지 실험 1건, 수동 주간 검토 | 노출·주문 반응과 정산 구분, 판정 및 다음 질문 기록 |
| 후속 4~8주 | 반복 가치 있는 1~2소스 수집 자동화 | 누락·재시도·중복·담당 부재 상황에서도 검토 가능 |
| 이후 | 반복 학습과 검증된 제품·지역 확장 | 추가 자동화 비용보다 실제 반복 공수·의사결정 개선 근거가 있음 |

위 기간은 구축 일정 약속이 아닌 단계 설계다. 기존 경영진 대시보드 납기와 충돌하면 첫 단계의 파일·검토 원장만 먼저 넣는다. 학습 루프는 기존 기획회의에 붙여 별도의 보고 체계를 늘리지 않는다.

성과는 수집 건수보다 **근거를 갖춘 의사결정 비율, 검토 대기시간, 실험 종료 후 학습 기록률, 재검토된 가설, 확정 비용을 반영한 성과**로 본다. 시간 절감 목표와 전환 개선 목표는 현재 기준선을 받은 뒤 설정한다. 실패 실험을 숨기게 만드는 성공률 KPI는 피한다.