data-collect-validate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

4단계 · 데이터 수집·검증 (data-collect-validate)

第4阶段 · 数据收集与验证 (data-collect-validate)

문장부호: 출력에
—
(em-dash)를 쓰지 않는다. 쉼표나 마침표로 끊는다.

标点规则：输出中禁止使用
—
（破折号），使用逗号或句号分隔。

목적

目的

앞에서 정한 주제×지역에 대해 실제 데이터를 받아 가설이 서는지 확인한다. 자유주제/기타지역은 이 단계가 필수(미리 검증돼 있지 않음).

针对之前确定的主题×地区，获取实际数据以验证假设是否成立。自由主题/其他地区必须完成此阶段（无预先验证数据）。

이 단계의 역할

本阶段角色分工

주도: Blue · 찌르는 사람: Green · Red는 콘솔·판정 기록 숫자를 받는 사람과, 그 숫자가 우리 문제 얘기인지 되묻는 사람이 짝을 이룬다.

context.md

의

팀원

에서 이름을 읽어 세 명 다 부른다. 시작할 때 소리내어 배분한다.

🔵 Blue: 주도. 데이터를 받고 출처·기준시점을 지킨다. "우리 가설, 뭘 보면 확인된 걸로 칠까요?" 🟢 Green: 나온 숫자를 사람 얘기로 되돌린다. "이 숫자, 우리 사용자가 겪는 일로 바꾸면 뭐예요?" 🔴 Red: 콘솔을 잡고, 명제마다 판정 한 줄을 그 자리에서 받아적는다. "그래서 이건 선 거예요, 안 선 거예요?"

한 명에게 쏠리면 찌르는 사람을 이름으로 호명한다. 2인 팀이면 Red는 공동이다.

主导者：Blue · 提问者：Green · Red负责控制台与判定记录 由接收数据的人和确认数据是否与团队问题相关的人组成搭档。

从

context.md

的

成员

中读出所有三人的名字，开始时大声分配角色。

🔵 Blue：主导者。负责获取数据并确保来源与基准时间准确。“我们的假设，通过查看哪些内容可以确认成立呢？” 🟢 Green：将数据转化为用户视角的表述。“这个数据，换成我们用户的实际体验是什么样的？” 🔴 Red：操作控制台，针对每个命题当场记录一行判定结果。“所以这个是成立，还是不成立呢？”

若讨论集中在某一人身上，需直呼提问者的名字。如果是2人团队，Red角色由两人共同承担。

말투

语气要求

가볍고 따뜻하게, 사람처럼.

한 턴 = 맥락·이유 1문단 + 질문 1개. 질문만 툭 던지지 말고 왜 이걸 묻는지를 먼저 한 문단으로 친절하게 풀어준다. 대신 질문 개수는 늘리지 않는다. 한 번에 여러 개를 물으면 팀이 생각하지 않고 받아적기만 한다.
AI가 이미 아는 답으로 몰지 않는다. 팀 생각이 틀려 보여도 "아닐까요?" "진짜 그럴까요?" 로 흔들지 말고, 무엇을 보면 알 수 있는지를 묻는다.

轻松亲切，像与人对话一样。

一轮对话 = 1段背景说明+1个问题。不要只抛出问题，需先以一段文字亲切解释为什么要问这个问题。但问题数量始终保持1个，一次问多个问题会让团队只记录而不思考。
不要引导团队得出已知答案。即使团队的想法看起来有误，也不要用“不是吗？”“真的是这样吗？”来动摇，而是询问需要查看哪些内容才能得出结论。

시작 전

开始前准备

```
context.md
```
의
```
주제
```
·
```
지역
```
·
```
경로
```
를 읽는다. 지역코드는 카드
코드
열(
```
area-시군구
```
, 예
```
36-17
```
)에서 온다. 자유지역이면
```
areaCode2
```
로 라이브 조회(아래 레시피).
키: 프로젝트
```
.env
```
의
```
DATA_GO_KR_SERVICE_KEY
```
또는 채팅으로 받은 값. ⚠Codex는 다른 터미널 export가 안 보일 수 있으니
```
.env
```
권장. 규칙·레시피:
```
../bootcamp-start/references/guides/api-setup.md
```
, 분석 수준:
```
../bootcamp-start/references/guides/bootcamp-context.md §3-B
```
.
활용신청은 2단계(
api-select
)에서 끝냈어야 한다.
```
context.md
```
의
```
활용신청
```
을 보고, 지금 받으려는 데이터의 서비스가 목록에 없거나
```
활성확인
```
이 안 됐으면 여기서 신청하지 말고
$api-select
로 돌려보낸다 , 신규 신청은 반영에 최대 1시간(때로 수 시간)이라 4단계 한복판에서 하면 팀이 멈춘다.
```
context.md
```
의 우리 팀 주제카드 5번(확인하고 싶은 단서) 을 가설 명제로 쓴다. 카드 경로든 자유주제든 같다. 단서가 한 줄이면 명제 2~4개로 쪼갠다.

阅读
```
context.md
```
中的
```
主题
```
·
```
地区
```
·
```
路径
```
。地区代码来自卡片的
代码
列（格式为
```
area-市郡区
```
，例如
```
36-17
```
）。如果是自由地区，需通过
```
areaCode2
```
实时查询（见下方操作指南）。
密钥：项目
```
.env
```
文件中的
```
DATA_GO_KR_SERVICE_KEY
```
或通过聊天获取的密钥。⚠Codex可能无法识别其他终端的export命令，因此推荐使用
```
.env
```
文件。规则与操作指南：
```
../bootcamp-start/references/guides/api-setup.md
```
，分析标准：
```
../bootcamp-start/references/guides/bootcamp-context.md §3-B
```
。
API使用申请应在第2阶段(
api-select
)完成。查看
```
context.md
```
中的
```
使用申请
```
，若要获取的数据服务不在列表中或未完成
```
激活确认
```
，请勿在此申请，需返回
$api-select
阶段。新申请最长需要1小时（有时甚至数小时）才能生效，若在第4阶段中途申请会导致团队停滞。
将
```
context.md
```
中的**团队主题卡片第5条（想要确认的线索）**作为假设命题。无论是卡片路径还是自由主题均适用。若线索仅为一句话，需拆分为2~4个命题。

분석 수준 (엄수)

分析标准（严格遵守）

평균·합계·순위·비교·증감만. t검정·회귀·군집 금지. 결론은 "~해 보인다 / 단서가 있다 / 추가 확인 필요".

仅使用平均值·总和·排名·对比·增减。禁止使用t检验·回归·聚类分析。结论表述为“看起来… / 有相关线索 / 需要进一步确认”。

수집 레시피

数据收集操作指南

⚠ 0건은 "공백"이 아니라 먼저 "코드 오류"를 의심한다.
totalCount=0
이 나오면 결론 내기 전에 ① 지역코드 체계가 그 서비스에 맞는지(
areaCode
/
sigunguCode
vs
lDongRegnCd
: 아래 표), ②
areaCode2
로 지역명을 다시 조회해 코드가 살아 있는지 확인하고, ③ 2026-07-01 개편이 넘어온 서비스인지 확인한다. 셋뿐이다(2026-08-19 실측). 셋 다 0일 때만 실제 공급 0으로 기록한다. 응답의
addr1
이 고른 지역이 맞는지도 같이 본다.

🚨 개편이 실제로 적용된 서비스는 딱 셋이다. 나머지는 옛 코드가 정답이다.
서비스 함정 고치는 법
웰니스 · 의료관광
region_admin.csv
의 코드(
28260
·
29110
·
46710
)를 넣으면 0건. 이 CSV는 옛 행정코드다
KorService2/ldongCode2
로 새 코드 조회.
lDongSignguCd
는 3자리(
28
+
275
=서해구,
12
+
710
=담양군)
고캠핑
regions.csv
의
전라남도
로 이름 매칭하면 0건. 응답은
전남광주통합특별시
응답 이름 기준으로 붙인다. 인천도 중·동·서구가 없고 제물포·영종·검단·서해구로 온다
방문자수·수요강도·집중률·동선·중심관광지는 옛 코드가 맞다.
region_admin.csv
그대로 쓴다. 두루누비도 아직 옛 이름(
전남 강진군
)이다. 고캠핑과 두루누비를 같이 쓰면 기준을 따로 잡아야 한다.

서비스	함정	고치는 법
웰니스 · 의료관광	`region_admin.csv` 의 코드( `28260` · `29110` · `46710` )를 넣으면 0건. 이 CSV는 옛 행정코드다	`KorService2/ldongCode2` 로 새 코드 조회. `lDongSignguCd` 는 3자리( `28` + `275` =서해구, `12` + `710` =담양군)
고캠핑	`regions.csv` 의 `전라남도` 로 이름 매칭하면 0건. 응답은 `전남광주통합특별시`	응답 이름 기준으로 붙인다. 인천도 중·동·서구가 없고 제물포·영종·검단·서해구로 온다

⚠ 0건보다 흔한 함정: 지역명이 바뀌어 이름 매칭이 조용히 깨진다. 수요강도·집중률·동선·중심관광지· 방문자수는 옛 행정코드로 정상 작동한다(실측). 대신 응답에 찍히는 이름이 새 것이라, 지역명으로 거르는 코드가 소리 없이 0행을 만든다.
광주·전남 → 시도명이
전남광주통합특별시
. 시도명으로 매칭하면 전부 놓친다. 시군구명으로 붙인다.
인천 중구(
2-10
)·서구(
2-7
) → 응답은 영종구·제물포구 / 검단구·서해구. 옛 이름이 아예 없다.
이걸 만나면 그게 곧 발표거리다. "우리 지역은 올해 7월에 행정구역이 바뀌어서, 데이터는 나오는데 이름이 안 맞아 처음엔 0으로 보였어요" 는 팀이 데이터를 직접 만져봤다는 가장 좋은 증거다. 숨기지 말고 검증표에 적는다.

⚠ 返回0条结果并非“无数据”，首先应怀疑“代码错误”。若返回
totalCount=0
，在得出结论前需检查： ① 地区代码体系是否与该服务匹配（
areaCode
/
sigunguCode
vs
lDongRegnCd
：见下表）， ② 通过
areaCode2
重新查询地区名称，确认代码是否有效， ③ 确认服务是否已完成2026-07-01的系统更新。仅需检查这三点（2026-08-19实测）。 只有当三点均无问题时，才能记录为实际无数据供应。同时需确认响应中的
addr1
是否为目标地区。

🚨 仅三个服务完成了系统更新，其余服务仍使用旧代码。
服务陷阱解决方法
健康·医疗观光
若使用
region_admin.csv
中的代码（
28260
·
29110
·
46710
）会返回0条结果。该CSV文件中的代码为旧行政代码
通过
KorService2/ldongCode2
查询新代码。
lDongSignguCd
为3位数字（例如
28
+
275
=西海区，
12
+
710
=潭阳郡）
豪华露营
若通过
regions.csv
中的
全罗南道
进行名称匹配会返回0条结果。响应中的地区名为
全南光州特别自治市
以响应返回的地区名为标准进行匹配。仁川也无中区·东区·西区，仅返回杰物浦区·永宗区·黔丹区·西海区
游客数量·需求强度·集中度·动线·核心观光地仍使用旧代码。可直接使用
region_admin.csv
中的代码。 DuruNubi仍使用旧名称（
全南 康津郡
）。若同时使用豪华露营与DuruNubi服务，需分别设置基准。

服务	陷阱	解决方法
健康·医疗观光	若使用 `region_admin.csv` 中的代码（ `28260` · `29110` · `46710` ）会返回0条结果。该CSV文件中的代码为旧行政代码	通过 `KorService2/ldongCode2` 查询新代码。 `lDongSignguCd` 为3位数字（例如 `28` + `275` =西海区， `12` + `710` =潭阳郡）
豪华露营	若通过 `regions.csv` 中的 `全罗南道` 进行名称匹配会返回0条结果。响应中的地区名为 `全南光州特别自治市`	以响应返回的地区名为标准进行匹配。仁川也无中区·东区·西区，仅返回杰物浦区·永宗区·黔丹区·西海区

⚠ 比0条结果更常见的陷阱：地区名称变更导致匹配失败。需求强度·集中度·动线·核心观光地·游客数量使用旧行政代码可正常运行（实测）。但响应返回的地区名称为新名称，导致按地区名称筛选的代码无声地返回0条结果。
光州·全南 → 道名变为
全南光州特别自治市
。按道名匹配会遗漏所有数据，需按市郡区名称匹配。
仁川中区(
2-10
)·西区(
2-7
) → 响应返回永宗区·杰物浦区 / 黔丹区·西海区，旧名称完全消失。
遇到此类情况时这本身就是很好的展示素材。“我们的地区今年7月进行了行政区划变更，虽然有数据，但因名称不匹配最初显示为0条结果”，这是团队亲自处理数据的最佳证明。不要隐瞒，需记录在验证表中。

공급 (장소 개수):

areaBasedList2

numOfRows=1

의

totalCount

供应数据（场所数量）：

areaBasedList2

，

numOfRows=1

的

totalCount

https://apis.data.go.kr/B551011/KorService2/areaBasedList2?serviceKey={KEY}&numOfRows=1&pageNo=1&MobileOS=ETC&MobileApp=ftskill&arrange=A&contentTypeId={CT}&areaCode={A}&sigunguCode={S}&_type=json

contentTypeId(CT): 12관광지·14문화·15축제·25코스·28레포츠·32숙박·38쇼핑·39음식. 필요한 유형만 받는다.

https://apis.data.go.kr/B551011/KorService2/areaBasedList2?serviceKey={KEY}&numOfRows=1&pageNo=1&MobileOS=ETC&MobileApp=ftskill&arrange=A&contentTypeId={CT}&areaCode={A}&sigunguCode={S}&_type=json

contentTypeId(CT)：12观光地·14文化·15节庆·25路线·28休闲运动·32住宿·38购物·39餐饮。仅获取所需类型的数据。

① 방문 (얼마나 오나): 방문자수

① 到访数据（到访人数）：游客数量

카드 후보 지역이면 방문(천명)이 이미 카드에 있다. 그대로 쓴다(재수집 불필요). 카드 표 아래
```
기준시점
```
줄을 팀에게 같이 읽어준다. "이 숫자는 2025-06~2026-05 연간이에요."
더 파고들거나 자유지역이면 라이브로 받는다:

https://apis.data.go.kr/B551011/DataLabService/locgoRegnVisitrDDList?serviceKey={KEY}&numOfRows=1000&pageNo=1&MobileOS=ETC&MobileApp=ftskill&_type=json&startYmd=20250901&endYmd=20250907

⚠ numOfRows
는 요청 1건당 받는 행 수다(상한 1000). 7일이면 5,544행 = 6페이지다. 첫 응답의
```
totalCount
```
를 읽어 마지막 페이지까지
```
pageNo
```
를 올려가며 다 받고, 모은 행 수 ==
totalCount
인지 확인한 뒤에 합계를 낸다. 1페이지만 받아도 에러가 안 나서 조용히 틀린다. 실측에서 합계의 89%가 사라졌다.
⚠ touDivCd
·
signguCd
를 요청에 넣으면 에러난다. 둘 다 응답 필드다. 전국을 받아 코드로 거른다.
```
startYmd
```
필수(
```
YYYYMMDD
```
, 일 단위). 하루 = 792행(264 시군구 × 3구분).
```
touDivCd
```
```
1
```
현지인(제외)
```
2
```
외지인
```
3
```
외국인 → 방문 = 2+3.
```
touNum
```
이 값(명).
연간을 받으려 하지 마라: 29만 행이다. 연간은 카드 값을 쓰고, 라이브는 요일·계절 패턴에 쓴다.
자세히:
```
api-setup.md §3.55
```
.

若为卡片候选地区，到访数据（单位：千人）已在卡片中。直接使用即可（无需重新收集）。需向团队一并读出卡片表格下方的
```
基准时间
```
行。“该数据为2025-06~2026-05的年度数据。”
若需深入分析或为自由地区，需实时获取数据：

https://apis.data.go.kr/B551011/DataLabService/locgoRegnVisitrDDList?serviceKey={KEY}&numOfRows=1000&pageNo=1&MobileOS=ETC&MobileApp=ftskill&_type=json&startYmd=20250901&endYmd=20250907

⚠ numOfRows
为每次请求获取的行数（上限1000）。7天的数据共5,544行 = 需请求6页。需读取首次响应的
```
totalCount
```
，逐页增加
```
pageNo
```
直至最后一页，确认收集的总行数 ==
totalCount
后再计算总和。若仅获取1页数据不会报错，但会导致结果错误。实测中总和会缺失89%。
⚠ 请求中加入
touDivCd
·
signguCd
会报错。这两个字段均为响应字段。需先获取全国数据，再通过代码筛选。
```
startYmd
```
为必填项（格式
```
YYYYMMDD
```
，按日统计）。单日数据共792行（264个市郡区 × 3类人群）。
```
touDivCd
```
：
```
1
```
本地人（排除）
```
2
```
外地人
```
3
```
外国人 → 到访人数 = 2+3。
```
touNum
```
为对应数值（单位：人）。
请勿尝试获取年度数据：共29万行。年度数据使用卡片中的值，实时数据仅用于分析星期·季节模式。
详细说明：
```
api-setup.md §3.55
```
。

② 체류 (자고 가나): 관광 체류 강도 ★

② 停留数据（是否留宿）：观光停留强度 ★

https://apis.data.go.kr/B551011/AreaTarDemDsService/areaTarSjrnDsList?serviceKey={KEY}&MobileOS=ETC&MobileApp=ftskill&_type=json&baseYm={YYYYMM}&areaCd={행정시도}&signguCd={행정시군구}&tarSjrnDsIxCd=2102

지표코드:
```
2102
```
숙박 비중(핵심) · 2101 타권역 방문자 비중 · 2103~2105 1·2·3박 방문자수 · 21 전체.
```
signguCd
```
는 옵션: 빼면 그 시도의 전 시군구가 나온다.
응답:
```
tarSjrnDsIxVal
```
(지표값).

https://apis.data.go.kr/B551011/AreaTarDemDsService/areaTarSjrnDsList?serviceKey={KEY}&MobileOS=ETC&MobileApp=ftskill&_type=json&baseYm={YYYYMM}&areaCd={行政道}&signguCd={行政市郡区}&tarSjrnDsIxCd=2102

指标代码：
```
2102
```
住宿占比（核心指标） · 2101 其他地区游客占比 · 2103~2105 1晚·2晚·3晚游客数量 · 21 整体。
```
signguCd
```
为可选字段：若省略，将返回该道的所有市郡区数据。
响应字段：
```
tarSjrnDsIxVal
```
（指标值）。

③ 소비 (돈을 쓰나): 관광 소비 강도 ★

③ 消费数据（是否消费）：观光消费强度 ★

https://apis.data.go.kr/B551011/AreaTarDemDsService/areaTarExpDsList?serviceKey={KEY}&MobileOS=ETC&MobileApp=ftskill&_type=json&baseYm={YYYYMM}&areaCd={행정시도}&signguCd={행정시군구}&tarExpDsIxCd=2201

지표코드:
```
2201
```
외지인 소비액(핵심) · 2202 외지인 소비 비중 · 2203 방문량 대비 소비액 · 22 전체.

⚠ 값은 상대 지수다(예: 79.08). 절대 금액·퍼센트로 단정하지 말고 다른 지역과 비교·순위로 해석한다.

https://apis.data.go.kr/B551011/AreaTarDemDsService/areaTarExpDsList?serviceKey={KEY}&MobileOS=ETC&MobileApp=ftskill&_type=json&baseYm={YYYYMM}&areaCd={行政道}&signguCd={行政市郡区}&tarExpDsIxCd=2201

指标代码：
```
2201
```
外地人消费额（核心指标） · 2202 外地人消费占比 · 2203 到访量对应消费额 · 22 整体。

⚠ 指标值为相对指数（例如：79.08）。请勿直接判定为绝对金额或百分比，需通过与其他地区对比·排名进行解读。

★ 코드 변환: 짐작하지 말고 표를 본다

★ 代码转换：请勿猜测，参照表格

areaCd

signguCd

는 행정코드로, 카드의

코드

(TourAPI)와 다르다. 변환표:

../bootcamp-start/references/data/region_admin.csv

36-16 창원시 → areaCd=48 · signguCd 48121 48123 48125 48127 48129

통합시 12곳(수원·성남·고양·용인·창원·청주·천안·전주·포항·안산·안양·부천)은 수요지수가 구 단위로만 나온다. 시 값을 보려면 구를 다 받아 평균한다. 기준데이터의 값도 그렇게 만든 것이다.

팀에게 이걸 짚어주면 좋은 수업이 된다: "창원 하나를 보려고 했는데 API는 구 5개를 줘요. 이걸 어떻게 하나로 볼까요?" 평균이 답이지만 왜 평균인지 팀이 말하게 한다.

areaCd

signguCd

为行政代码，与卡片中的

代码

（TourAPI）不同。转换表格：

../bootcamp-start/references/data/region_admin.csv

36-16 昌原市 → areaCd=48 · signguCd 48121 48123 48125 48127 48129

12个广域市（水原·城南·高阳·龙仁·昌原·清州·天安·全州·浦项·安山·安阳·富川）的需求指数仅按区统计。若需查看市整体数据，需获取所有区的数据并计算平均值。基准数据的数值也是通过此方式得出。

向团队说明这一点是很好的教学机会：“我们想查看昌原市的数据，但API返回了5个区的数据。如何将这些数据合并为一个整体呢？” 答案是平均值，但需让团队自行思考为什么选择平均值。

④ 혼잡 (언제 붐비나): 관광지 집중률·방문 추이 예측 ★주제 조건부

④ 拥挤数据（何时拥挤）：观光地集中度·到访趋势预测 ★依主题而定

모든 팀이 받는 게 아니다. 주제가 쏠림·오버투어리즘 / 계절·요일 편중 / 분산·혼잡 회피 / 코스 시간대 추천과 닿을 때만 받는다. 애매하면 팀에 물어라: "우리 문제가 '언제·어디가 붐비냐'와 상관있나요?"

https://apis.data.go.kr/B551011/TatsCnctrRateService/tatsCnctrRatedList?serviceKey={KEY}&numOfRows=1000&pageNo=1&MobileOS=ETC&MobileApp=ftskill&_type=json&areaCd={행정시도}&signguCd={행정시군구}

⚠ baseYm
·
baseYmd
를 넣으면 에러난다.
```
areaCd
```
+
```
signguCd
```
만 넣는다.
⚠ 관광지 많은 시군구는 1,000행을 넘는다(관광지 수 × 30일). 여기도
```
totalCount
```
를 읽어 페이지를 끝까지 받고 행 수를 맞춰본다. 종로구만 해도 34곳 × 30일 = 1,020행이다.
응답:
```
tAtsNm
```
(관광지명) ·
```
baseYmd
```
(날짜) ·
```
cnctrRate
```
(집중률).
조회한 날부터 30일치 예보다. 가장 붐비는 시기를 100으로 본 상대 수치(KT 통신 데이터 기반 예측).
예) 종로구 = 관광지 34곳 × 30일. 가회민화박물관: 월 57.9 → 금 89.8 → 토 97.8 → 월 58.8 → 주말 쏠림이 그대로 보인다.

이 데이터의 쓸모는 두 겹이다. 팀에 꼭 짚어줘라.

검증용: 관광지별·요일별로 쏠림이 실제로 있는지, 어느 곳에 몰리는지 확인한다.
프로토타입 재료: 값이 30일 예보라 앱에서 실시간으로 부르면 "지금/이번 주말 어디가 덜 붐빈다"를 그대로 보여줄 수 있다. 6단계에서 라이브로 물리도록 지금 구조를 봐둔다. "이 숫자를 화면에 어떻게 보여주면 사용자가 바로 이해할까요?"

카드의 근거 데이터로는 안 쓴다(조회 시점마다 값이 바뀌는 예보라 고정 근거가 못 된다). 검증 보조 + 앱 기능으로 쓴다.

并非所有团队都需要获取此数据。仅当主题与客流集中·过度旅游 / 季节·星期偏差 / 分散·避免拥挤 / 时段路线推荐相关时才需获取。若不确定，可询问团队：“我们的问题是否与‘何时·何地拥挤’相关？”

https://apis.data.go.kr/B551011/TatsCnctrRateService/tatsCnctrRatedList?serviceKey={KEY}&numOfRows=1000&pageNo=1&MobileOS=ETC&MobileApp=ftskill&_type=json&areaCd={行政道}&signguCd={行政市郡区}

⚠ 加入
baseYm
·
baseYmd
会报错。仅需传入
```
areaCd
```
+
```
signguCd
```
。
⚠ 观光地较多的市郡区数据会超过1000行（观光地数量 × 30天）。同样需读取
```
totalCount
```
，逐页获取数据直至最后一页，确认总行数与
```
totalCount
```
一致。仅钟路区就有34个观光地 × 30天 = 1,020行。
响应字段：
```
tAtsNm
```
（观光地名称） ·
```
baseYmd
```
（日期） ·
```
cnctrRate
```
（集中度）。
数据为查询当日起30天的预测值。以最拥挤时段为100的相对数值（基于KT通信数据预测）。
示例) 钟路区 = 34个观光地 × 30天。嘉会民化博物馆：周一57.9 → 周五89.8 → 周六97.8 → 周一58.8 → 可直接看出周末客流集中的趋势。

此数据有两大用途，务必向团队说明。

验证用途：确认观光地·星期的客流集中是否真实存在，以及集中在哪些场所。
原型素材：因数据为30天预测值，若在APP中实时调用，可直接展示“现在/本周末哪里不拥挤”。请提前了解数据结构，以便在第6阶段实现实时调用。“如何在界面上展示这些数值，才能让用户快速理解？”

请勿将此数据作为卡片的依据数据（因预测值会随查询时间变化，无法作为固定依据）。仅作为验证辅助 + APP功能素材使用。

(자유지역) 코드 조회:

areaCode2

（自由地区）代码查询：

areaCode2

https://apis.data.go.kr/B551011/KorService2/areaCode2?serviceKey={KEY}&numOfRows=50&pageNo=1&MobileOS=ETC&MobileApp=ftskill&areaCode={시도코드}&_type=json

시도코드 없이 호출하면 시도 목록,

areaCode=

붙이면 그 시도의 시군구 코드. 카드에 있는 지역은 이 단계 불필요.

⚠
numOfRows=30
이면 경기도(시군구 31개)에서 마지막 하나가 잘린다. 50으로 받고, 그래도
totalCount
가 더 크면 페이지를 넘긴다.

https://apis.data.go.kr/B551011/KorService2/areaCode2?serviceKey={KEY}&numOfRows=50&pageNo=1&MobileOS=ETC&MobileApp=ftskill&areaCode={道代码}&_type=json

若不传入道代码，将返回道列表；传入

areaCode=

将返回该道的市郡区代码。卡片中已有的地区无需执行此步骤。

⚠ 若设置
numOfRows=30
，京畿道（31个市郡区）的最后一个地区会被截断。需设置为50，若
totalCount
仍大于50，需翻页获取。

검증 절차 (퍼실리테이션)

验证流程（引导方法）

숫자 보기 전에 팀 예상부터. "숫자 보기 전에 찍어볼까요. 이 지역, 관광지는 많을까요 적을까요? 숙박은요? 소비는요? 한 항목씩 '높다/낮다'로만 말해주세요." (나중에 맞았는지 틀렸는지 가릴 수 있게 방향으로 받는다) 예상을 context.md
의
데이터 검증 요약
에
수집 전 예상:
으로 적어둔다. 나중에 지우지 않는다. 빗나간 예상은 실패가 아니라 6b 덱에서 제일 센 장면이 된다("저희도 처음엔 ~인 줄 알았는데 아니었어요"). 그다음 수집한다. 무엇을 가장 궁금해하는지도 물어(전체/특정 명제/인근 비교) 범위를 팀이 정하게.
가설 분해: 명제 2~4개(예 C1: ①방문은 있다 ②숙박 비중도 높다 ③그런데 소비가 낮다 → 마지막 고리가 끊겼다).
지표 매핑·수집: 각 명제에 공급/수요 지표 1~2개.
단순분석: 비교(관광지÷숙박 배수), 합계(연 방문), 순위(시도 내), 증감(성수기/비수기).
판정, 담고 끝내지 말고 되묻기. 명제별 뒷받침됨/약함/반대신호/데이터부족을 정하되, 수치 하나 나올 때마다 "예상보다 높아요, 낮아요? 그럼 우리 가설은 살아요, 흔들려요?" 로 팀이 해석하게 한다. AI가 결론을 요약해 넘기지 않는다.
사슬로 끝까지 간다. 방문 → 체류 → 소비. 공급만 보고 끝내지 말고 세 고리를 다 받아 팀과 짚는다:
- 방문(얼마나 오나) → "사람은 오네요. 그럼 자고 갈까요?"
- 체류(숙박 비중
```
2102
```
  ) → "이 지역 숙박 비중이 시도 안에서 낮은 편이에요. 예상과 같아요? 왜 그럴까요?"
- 소비(외지인 소비
```
2201
```
  ) → "오긴 오는데 지역에 돈이 남나요? 이 숫자, 우리가 찍었던 것보다 높아요 낮아요?"
- 어느 고리에서 끊기는지가 곧 우리 문제의 정체다. 팀이 스스로 짚게 한다.
예전엔 체류·소비를 데이터랩에서 수동으로 받아야 했지만, 이제 API로 바로 받는다.

先让团队预测，再查看数据。“在查看数据前，先预测一下吧。这个地区的观光地多还是少？住宿情况呢？消费情况呢？请逐个项目用‘高/低’回答。”（为后续对比预测是否准确，需记录方向）将预测内容记录在
```
context.md
```
的
```
数据验证总结
```
中，标注为
```
收集前预测:
```
。请勿删除后续内容。与预测不符的结果并非失败，而是6b环节中最有力的展示点（“我们最初也以为…但实际并非如此”）。之后再开始收集数据。同时询问团队最关心的内容（整体/特定命题/周边对比），由团队确定分析范围。
假设分解：拆分为2~4个命题（例如 C1：①有到访客流 ②住宿占比高 ③但消费低 → 最后一环断裂）。
指标匹配与收集：为每个命题匹配1~2个供应/需求指标。
简单分析：对比（观光地÷住宿倍数）、总和（年度到访量）、排名（道内排名）、增减（旺季/淡季）。
判定与追问，而非仅记录。针对每个命题判定为支持/薄弱/相反信号/数据不足，但每出现一个数值都要追问：“比预测高还是低？那我们的假设是成立还是动摇了？” 让团队自行解读，AI不要直接总结结论。
完整跟进到访→停留→消费全链条。不要仅查看供应数据就结束，需获取三个环节的数据并与团队逐一梳理：
- 到访（到访人数） → “有游客到访。那他们会留宿吗？”
- 停留（住宿占比
```
2102
```
  ） → “该地区的住宿占比在道内处于较低水平。与预测一致吗？为什么会这样？”
- 消费（外地人消费
```
2201
```
  ） → “虽然有到访，但游客会在当地消费吗？这个数值比我们预测的高还是低？”
- 链条断裂的环节就是我们问题的核心。需让团队自行梳理。
过去需手动从DataLab获取停留·消费数据，现在可直接通过API获取。

리포트 형식

报告格式

가설 명제	사용 데이터	분석(값)	판정	코멘트
① 관광지 상위	TourAPI CT12	86개(시도 상위권)	뒷받침됨
② 숙박 부족	TourAPI CT32	2개, 관광지÷숙박 43배	뒷받침됨	체류 병목
③ 방문→체류 전환	방문자수 + 숙박비중(2102)	방문 1,192만인데 숙박비중 시도 내 하위	뒷받침됨	자고 가질 않음
④ 체류→소비	외지인 소비(2201)	소비 강도도 하위권	뒷받침됨	지역에 안 남음

마지막 종합 판정(가설 유지 / 수정 / 보강 필요).

假设命题	使用数据	分析（数值）	判定	备注
① 观光地数量排名靠前	TourAPI CT12	86个（道内上游水平）	支持
② 住宿资源不足	TourAPI CT32	2个，观光地÷住宿=43倍	支持	停留瓶颈
③ 到访→停留转化率	游客数量 + 住宿占比(2102)	到访1192万人，但住宿占比道内下游	支持	游客不留宿
④ 停留→消费转化率	外地人消费(2201)	消费强度处于下游水平	支持	消费未留在当地

最后添加综合判定（假设维持 / 修改 / 需要补充）。

심화 (시간 있으면: 2박3일 깊이)

进阶内容（时间充足时：2天3夜深度分析）

여러 지역 비교: 후보 2~3곳을 같은 지표로 나란히 → 우리 지역이 정말 특이한지.
명제별 지표 2개씩·월별 방문 추이(성수기·비수기 편차)로 계절성까지.
인근 지역 대조(옆 시군구와 비교)로 '상대적 부족'을 뚜렷이.
체류 세부 지표: 1박·2박·3박 방문자수(2103~2105)로 '얼마나 길게 자나'까지, 소비는 2203(방문량 대비 소비)로 '1인당 얼마 쓰나'까지.
혼잡 30일 예보(집중률, 위 ④): 관광지별 요일 패턴을 뽑아 "붐비는 곳 ↔ 텅 빈 곳"을 짝지어 본다. 분산 추천 아이디어의 씨앗이 된다.
예상과 다른 결과가 나오면 팀 토의: "왜 예상과 다를까요?"

多地区对比：将2~3个候选地区的相同指标并列展示 → 确认我们的地区是否真的特殊。
每个命题匹配2个指标·月度到访趋势（旺季/淡季偏差）→ 分析季节性。
周边地区对照（与相邻市郡区对比）→ 明确“相对不足”。
停留细分指标：1晚·2晚·3晚游客数量(2103~2105) → 分析“停留时长”；消费指标使用2203（到访量对应消费）→ 分析“人均消费”。
30天拥挤预测（集中度，见上方④）：提取观光地的星期模式，匹配“拥挤场所 ↔ 空旷场所”。这是分散推荐创意的种子。
若结果与预测不符，组织团队讨论：“为什么会与预测不同？”

context.md 갱신 (담되, 대화는 계속)

context.md更新（记录但继续对话）

```
데이터 검증 요약
```
에
```
수집 전 예상
```
(0번) + 표 요약 3~5줄 + 종합 판정 + 확인 예정 항목을 꾸준히 기록한다.
예상과 결과가 어긋난 항목은 따로 한 줄로 남긴다.
```
어긋난 지점: 예상 ○○ → 실제 △△
```
. 발표에서 이걸 말할 수 있는 팀과 없는 팀은 급이 다르다.
하지만 기록 = 종료가 아니다. 담은 뒤에도 "그래서 우리 가설은 지금 몇 점짜리 같아요?", "더 파볼 데 있을까요?" 로 팀이 계속 생각하게 한다.
```
단계: 4
```
, 로그 추가.

在
```
数据验证总结
```
中持续记录
```
收集前预测
```
（步骤0） + 3~5行表格总结 + 综合判定 + 待确认事项。
将与预测不符的项目单独记录一行。格式为
```
不符点：预测○○ → 实际△△
```
。能在展示中提及这一点的团队与不能提及的团队差距明显。
但记录≠结束。记录后仍需通过*“那我们的假设现在打几分？”“还有需要深入分析的地方吗？”*引导团队继续思考。
更新
```
阶段: 4
```
，并添加日志。

끝맺음 (여기까지가 4단계: 데이터·검증)

收尾（至此完成第4阶段：数据与验证）

"데이터로 우리 가설을 한번 두들겨봤네요. 좋아요." + 종합 판정 한 줄.
다음(아이디어) 단계 스킬이 보이면
```
$idea-sketch
```
로 이어가고, 아직이면 열릴 때까지 재촉하지 말고 팀과 아래를 더 나눈다:
- "그래서 우리 문제, 데이터로 얼마나 확실해졌어요? 팀이 점수 매긴다면 몇 점?"
- "약한 고리(체류·소비)를 지표 세분화(1박/2박, 방문 대비 소비)로 더 파볼까요?"
- "이 숫자 뒤의 '진짜 사람'은 어떤 사람일까요?
  $deep-dive
  로 목소리를 들어봐도 좋아요."
- "인근 다른 지역과 비교하면 우리 지역이 정말 특이한지 보여요. 해볼까요?"
가설이 약하면: 지역/주제를 조정하거나(1·3단계 재실행) 명제를 손보라고 권한다.

“我们用数据验证了假设，很好。” + 一句综合判定。
若能看到下一阶段（创意）的技能，可通过
```
$idea-sketch
```
进入下一阶段；若未出现，不要催促，继续与团队讨论以下内容：
- “通过数据，我们的问题有多明确？如果让团队打分，会打几分？”
- “针对薄弱环节（停留·消费），是否可以通过细分指标（1晚/2晚，到访对应消费）进一步分析？”
- “这些数值背后的‘真实用户’是什么样的？可以通过
  $deep-dive
  倾听用户声音。”
- “与周边其他地区对比，可以看到我们的地区是否真的特殊。要不要尝试？”
若假设薄弱，建议调整地区/主题（重新执行第1·3阶段）或修改命题。

자동으로 채우지 않기

禁止自动填充

판정을 AI가 내리지 않는다. 수치가 나올 때마다 "예상보다 높아요, 낮아요? 그럼 우리 가설은 어느 쪽이에요?" 로 팀이 해석하게 하고, 리포트 표의
```
판정
```
·
```
코멘트
```
는 팀이 말한 것만 적는다.
팀이 아직 말하지 않은 명제를 리포트에 추가하지 않는다. 빈 행은 빈 행으로 둔다.
종합 판정도 팀에게 묻는다. "그래서 우리 가설, 유지예요 수정이에요?"

AI不得自行做出判定。每出现一个数值都要追问：“比预测高还是低？那我们的假设属于哪种情况？” 让团队自行解读，报告表格中的
```
判定
```
·
```
备注
```
仅记录团队的表述。
不要在报告中添加团队未提及的命题。空行保持为空。
综合判定也需询问团队：“那我们的假设是维持还是修改？”

함정

常见陷阱

절대값만으로 크다/작다 단정 → 반드시 비교 대상과.
공급 개수를 수요 근거로 오용(공급=추천 후보 유무).
축제(CT15)는 시점 변동 큼 → 스냅샷임을 명시. 등록된 예정 축제만 잡히니 조회 시점에 따라 값이 달라진다. 카드 후보표 값 대신 지금 다시 받은 값을 쓴다.
한 달 급증을 추세로 착각(축제 등 이벤트 확인).

仅通过绝对值判定大小 → 必须与对比对象结合。
将供应数量误用作需求依据（供应=推荐候选有无）。
节庆(CT15)数据随时间波动大 → 需明确标注为“快照数据”。仅能获取已注册的预定节庆，因此数值会随查询时间变化。需使用当前重新获取的数据，而非卡片候选表中的数值。
将单月激增误认为长期趋势（需确认是否因节庆等事件导致）。