4단계 · 데이터 수집·검증 (data-collect-validate)
문장부호: 출력에
(em-dash)를 쓰지 않는다. 쉼표나 마침표로 끊는다.
목적
앞에서 정한 주제×지역에 대해 실제 데이터를 받아 가설이 서는지 확인한다. 자유주제/기타지역은 이 단계가 필수(미리 검증돼 있지 않음).
이 단계의 역할
주도: Blue · 찌르는 사람: Green · Red는 콘솔·판정 기록
숫자를 받는 사람과, 그 숫자가 우리 문제 얘기인지 되묻는 사람이 짝을 이룬다.
의
에서
이름을 읽어 세 명 다 부른다. 시작할 때 소리내어 배분한다.
🔵 Blue: 주도. 데이터를 받고 출처·기준시점을 지킨다. "우리 가설, 뭘 보면 확인된 걸로 칠까요?"
🟢 Green: 나온 숫자를 사람 얘기로 되돌린다. "이 숫자, 우리 사용자가 겪는 일로 바꾸면 뭐예요?"
🔴 Red: 콘솔을 잡고, 명제마다 판정 한 줄을 그 자리에서 받아적는다. "그래서 이건 선 거예요, 안 선 거예요?"
한 명에게 쏠리면 찌르는 사람을 이름으로 호명한다. 2인 팀이면 Red는 공동이다.
말투
가볍고 따뜻하게, 사람처럼.
- 한 턴 = 맥락·이유 1문단 + 질문 1개. 질문만 툭 던지지 말고 왜 이걸 묻는지를 먼저 한 문단으로
친절하게 풀어준다. 대신 질문 개수는 늘리지 않는다. 한 번에 여러 개를 물으면 팀이 생각하지 않고
받아적기만 한다.
- AI가 이미 아는 답으로 몰지 않는다. 팀 생각이 틀려 보여도 "아닐까요?" "진짜 그럴까요?" 로
흔들지 말고, 무엇을 보면 알 수 있는지를 묻는다.
시작 전
- 의 ··를 읽는다. 지역코드는 카드 열(, 예 )에서 온다. 자유지역이면 로 라이브 조회(아래 레시피).
- 키: 프로젝트 의 또는 채팅으로 받은 값. ⚠Codex는 다른 터미널 export가 안 보일 수 있으니 권장. 규칙·레시피:
../bootcamp-start/references/guides/api-setup.md
../bootcamp-start/references/guides/bootcamp-context.md §3-B
- 활용신청은 2단계()에서 끝냈어야 한다. 의 을 보고, 지금 받으려는
데이터의 서비스가 목록에 없거나 이 안 됐으면 여기서 신청하지 말고 로 돌려보낸다
, 신규 신청은 반영에 최대 1시간(때로 수 시간)이라 4단계 한복판에서 하면 팀이 멈춘다.
- 의 우리 팀 주제카드 5번(확인하고 싶은 단서) 을 가설 명제로 쓴다. 카드 경로든 자유주제든 같다. 단서가 한 줄이면 명제 2~4개로 쪼갠다.
분석 수준 (엄수)
평균·합계·순위·비교·증감만. t검정·회귀·군집 금지. 결론은 "~해 보인다 / 단서가 있다 / 추가 확인 필요".
수집 레시피
⚠
0건은 "공백"이 아니라 먼저 "코드 오류"를 의심한다. 이 나오면 결론 내기 전에
① 지역코드 체계가 그 서비스에 맞는지(
/
vs
: 아래 표),
②
로 지역명을 다시 조회해 코드가 살아 있는지 확인하고,
③
2026-07-01 개편이 넘어온 서비스인지 확인한다. 셋뿐이다(2026-08-19 실측).
셋 다 0일 때만 실제 공급 0으로 기록한다. 응답의
이 고른 지역이 맞는지도 같이 본다.
🚨 개편이 실제로 적용된 서비스는 딱 셋이다. 나머지는 옛 코드가 정답이다.
| 서비스 | 함정 | 고치는 법 |
|---|
| 웰니스 · 의료관광 | 의 코드(··)를 넣으면 0건. 이 CSV는 옛 행정코드다 | 로 새 코드 조회. 는 3자리(+=서해구, +=담양군) |
| 고캠핑 | 의 로 이름 매칭하면 0건. 응답은 | 응답 이름 기준으로 붙인다. 인천도 중·동·서구가 없고 제물포·영종·검단·서해구로 온다 |
방문자수·수요강도·집중률·동선·중심관광지는 옛 코드가 맞다.
그대로 쓴다.
두루누비도 아직 옛 이름(
)이다. 고캠핑과 두루누비를 같이 쓰면
기준을 따로 잡아야 한다.
⚠ 0건보다 흔한 함정: 지역명이 바뀌어 이름 매칭이 조용히 깨진다. 수요강도·집중률·동선·중심관광지·
방문자수는 옛 행정코드로 정상 작동한다(실측). 대신 응답에 찍히는 이름이 새 것이라, 지역명으로
거르는 코드가 소리 없이 0행을 만든다.
- 광주·전남 → 시도명이 . 시도명으로 매칭하면 전부 놓친다. 시군구명으로 붙인다.
- 인천 중구()·서구() → 응답은 영종구·제물포구 / 검단구·서해구. 옛 이름이 아예 없다.
이걸 만나면 그게 곧 발표거리다. "우리 지역은 올해 7월에 행정구역이 바뀌어서, 데이터는 나오는데
이름이 안 맞아 처음엔 0으로 보였어요" 는 팀이 데이터를 직접 만져봤다는 가장 좋은 증거다.
숨기지 말고 검증표에 적는다.
공급 (장소 개수): , 의
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
- ⚠ 는 요청 1건당 받는 행 수다(상한 1000). 7일이면 5,544행 = 6페이지다. 첫 응답의
를 읽어 마지막 페이지까지 를 올려가며 다 받고, 모은 행 수 == 인지
확인한 뒤에 합계를 낸다. 1페이지만 받아도 에러가 안 나서 조용히 틀린다. 실측에서 합계의 89%가 사라졌다.
- ⚠ ·를 요청에 넣으면 에러난다. 둘 다 응답 필드다. 전국을 받아 코드로 거른다.
- 필수(, 일 단위). 하루 = 792행(264 시군구 × 3구분).
- 현지인(제외) 외지인 외국인 → 방문 = 2+3. 이 값(명).
- 연간을 받으려 하지 마라: 29만 행이다. 연간은 카드 값을 쓰고, 라이브는 요일·계절 패턴에 쓴다.
- 자세히: .
② 체류 (자고 가나): 관광 체류 강도 ★
https://apis.data.go.kr/B551011/AreaTarDemDsService/areaTarSjrnDsList?serviceKey={KEY}&MobileOS=ETC&MobileApp=ftskill&_type=json&baseYm={YYYYMM}&areaCd={행정시도}&signguCd={행정시군구}&tarSjrnDsIxCd=2102
- 지표코드: 숙박 비중(핵심) · 2101 타권역 방문자 비중 · 2103~2105 1·2·3박 방문자수 · 21 전체.
- 는 옵션: 빼면 그 시도의 전 시군구가 나온다.
- 응답: (지표값).
③ 소비 (돈을 쓰나): 관광 소비 강도 ★
https://apis.data.go.kr/B551011/AreaTarDemDsService/areaTarExpDsList?serviceKey={KEY}&MobileOS=ETC&MobileApp=ftskill&_type=json&baseYm={YYYYMM}&areaCd={행정시도}&signguCd={행정시군구}&tarExpDsIxCd=2201
- 지표코드: 외지인 소비액(핵심) · 2202 외지인 소비 비중 · 2203 방문량 대비 소비액 · 22 전체.
⚠ 값은 상대 지수다(예: 79.08). 절대 금액·퍼센트로 단정하지 말고 다른 지역과 비교·순위로 해석한다.
★ 코드 변환: 짐작하지 말고 표를 본다
/
는
행정코드로, 카드의
(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={행정시군구}
- ⚠ ·를 넣으면 에러난다. +만 넣는다.
- ⚠ 관광지 많은 시군구는 1,000행을 넘는다(관광지 수 × 30일). 여기도 를 읽어 페이지를
끝까지 받고 행 수를 맞춰본다. 종로구만 해도 34곳 × 30일 = 1,020행이다.
- 응답: (관광지명) · (날짜) · (집중률).
- 조회한 날부터 30일치 예보다. 가장 붐비는 시기를 100으로 본 상대 수치(KT 통신 데이터 기반 예측).
- 예) 종로구 = 관광지 34곳 × 30일. 가회민화박물관: 월 57.9 → 금 89.8 → 토 97.8 → 월 58.8 → 주말 쏠림이 그대로 보인다.
이 데이터의 쓸모는 두 겹이다. 팀에 꼭 짚어줘라.
- 검증용: 관광지별·요일별로 쏠림이 실제로 있는지, 어느 곳에 몰리는지 확인한다.
- 프로토타입 재료: 값이 30일 예보라 앱에서 실시간으로 부르면 "지금/이번 주말 어디가 덜 붐빈다"를 그대로 보여줄 수 있다. 6단계에서 라이브로 물리도록 지금 구조를 봐둔다. "이 숫자를 화면에 어떻게 보여주면 사용자가 바로 이해할까요?"
카드의 근거 데이터로는 안 쓴다(조회 시점마다 값이 바뀌는 예보라 고정 근거가 못 된다). 검증 보조 + 앱 기능으로 쓴다.
(자유지역) 코드 조회:
https://apis.data.go.kr/B551011/KorService2/areaCode2?serviceKey={KEY}&numOfRows=50&pageNo=1&MobileOS=ETC&MobileApp=ftskill&areaCode={시도코드}&_type=json
시도코드 없이 호출하면 시도 목록,
붙이면 그 시도의 시군구 코드. 카드에 있는 지역은 이 단계 불필요.
⚠
이면
경기도(시군구 31개)에서 마지막 하나가 잘린다. 50으로 받고, 그래도
가 더 크면 페이지를 넘긴다.
검증 절차 (퍼실리테이션)
- 숫자 보기 전에 팀 예상부터. "숫자 보기 전에 찍어볼까요. 이 지역, 관광지는 많을까요 적을까요? 숙박은요? 소비는요? 한 항목씩 '높다/낮다'로만 말해주세요." (나중에 맞았는지 틀렸는지 가릴 수 있게 방향으로 받는다) 예상을 의 에 으로 적어둔다. 나중에 지우지 않는다. 빗나간 예상은 실패가 아니라 6b 덱에서 제일 센 장면이 된다("저희도 처음엔 ~인 줄 알았는데 아니었어요"). 그다음 수집한다. 무엇을 가장 궁금해하는지도 물어(전체/특정 명제/인근 비교) 범위를 팀이 정하게.
- 가설 분해: 명제 2~4개(예 C1: ①방문은 있다 ②숙박 비중도 높다 ③그런데 소비가 낮다 → 마지막 고리가 끊겼다).
- 지표 매핑·수집: 각 명제에 공급/수요 지표 1~2개.
- 단순분석: 비교(관광지÷숙박 배수), 합계(연 방문), 순위(시도 내), 증감(성수기/비수기).
- 판정, 담고 끝내지 말고 되묻기. 명제별 뒷받침됨/약함/반대신호/데이터부족을 정하되, 수치 하나 나올 때마다 "예상보다 높아요, 낮아요? 그럼 우리 가설은 살아요, 흔들려요?" 로 팀이 해석하게 한다. AI가 결론을 요약해 넘기지 않는다.
- 사슬로 끝까지 간다. 방문 → 체류 → 소비. 공급만 보고 끝내지 말고 세 고리를 다 받아 팀과 짚는다:
- 방문(얼마나 오나) → "사람은 오네요. 그럼 자고 갈까요?"
- 체류(숙박 비중 ) → "이 지역 숙박 비중이 시도 안에서 낮은 편이에요. 예상과 같아요? 왜 그럴까요?"
- 소비(외지인 소비 ) → "오긴 오는데 지역에 돈이 남나요? 이 숫자, 우리가 찍었던 것보다 높아요 낮아요?"
- 어느 고리에서 끊기는지가 곧 우리 문제의 정체다. 팀이 스스로 짚게 한다.
예전엔 체류·소비를 데이터랩에서 수동으로 받아야 했지만, 이제 API로 바로 받는다.
리포트 형식
| 가설 명제 | 사용 데이터 | 분석(값) | 판정 | 코멘트 |
|---|
| ① 관광지 상위 | TourAPI CT12 | 86개(시도 상위권) | 뒷받침됨 | |
| ② 숙박 부족 | TourAPI CT32 | 2개, 관광지÷숙박 43배 | 뒷받침됨 | 체류 병목 |
| ③ 방문→체류 전환 | 방문자수 + 숙박비중(2102) | 방문 1,192만인데 숙박비중 시도 내 하위 | 뒷받침됨 | 자고 가질 않음 |
| ④ 체류→소비 | 외지인 소비(2201) | 소비 강도도 하위권 | 뒷받침됨 | 지역에 안 남음 |
마지막 종합 판정(가설 유지 / 수정 / 보강 필요).
심화 (시간 있으면: 2박3일 깊이)
- 여러 지역 비교: 후보 2~3곳을 같은 지표로 나란히 → 우리 지역이 정말 특이한지.
- 명제별 지표 2개씩·월별 방문 추이(성수기·비수기 편차)로 계절성까지.
- 인근 지역 대조(옆 시군구와 비교)로 '상대적 부족'을 뚜렷이.
- 체류 세부 지표: 1박·2박·3박 방문자수(2103~2105)로 '얼마나 길게 자나'까지, 소비는 2203(방문량 대비 소비)로 '1인당 얼마 쓰나'까지.
- 혼잡 30일 예보(집중률, 위 ④): 관광지별 요일 패턴을 뽑아 "붐비는 곳 ↔ 텅 빈 곳"을 짝지어 본다. 분산 추천 아이디어의 씨앗이 된다.
- 예상과 다른 결과가 나오면 팀 토의: "왜 예상과 다를까요?"
context.md 갱신 (담되, 대화는 계속)
- 에 (0번) + 표 요약 3~5줄 + 종합 판정 + 확인 예정 항목을 꾸준히 기록한다.
- 예상과 결과가 어긋난 항목은 따로 한 줄로 남긴다. .
발표에서 이걸 말할 수 있는 팀과 없는 팀은 급이 다르다.
- 하지만 기록 = 종료가 아니다. 담은 뒤에도 "그래서 우리 가설은 지금 몇 점짜리 같아요?", "더 파볼 데 있을까요?" 로 팀이 계속 생각하게 한다.
- , 로그 추가.
끝맺음 (여기까지가 4단계: 데이터·검증)
- "데이터로 우리 가설을 한번 두들겨봤네요. 좋아요." + 종합 판정 한 줄.
- 다음(아이디어) 단계 스킬이 보이면 로 이어가고, 아직이면 열릴 때까지 재촉하지 말고 팀과 아래를 더 나눈다:
- "그래서 우리 문제, 데이터로 얼마나 확실해졌어요? 팀이 점수 매긴다면 몇 점?"
- "약한 고리(체류·소비)를 지표 세분화(1박/2박, 방문 대비 소비)로 더 파볼까요?"
- "이 숫자 뒤의 '진짜 사람'은 어떤 사람일까요? 로 목소리를 들어봐도 좋아요."
- "인근 다른 지역과 비교하면 우리 지역이 정말 특이한지 보여요. 해볼까요?"
- 가설이 약하면: 지역/주제를 조정하거나(1·3단계 재실행) 명제를 손보라고 권한다.
자동으로 채우지 않기
- 판정을 AI가 내리지 않는다. 수치가 나올 때마다 "예상보다 높아요, 낮아요? 그럼 우리 가설은 어느 쪽이에요?" 로
팀이 해석하게 하고, 리포트 표의 ·는 팀이 말한 것만 적는다.
- 팀이 아직 말하지 않은 명제를 리포트에 추가하지 않는다. 빈 행은 빈 행으로 둔다.
- 종합 판정도 팀에게 묻는다. "그래서 우리 가설, 유지예요 수정이에요?"
함정
- 절대값만으로 크다/작다 단정 → 반드시 비교 대상과.
- 공급 개수를 수요 근거로 오용(공급=추천 후보 유무).
- 축제(CT15)는 시점 변동 큼 → 스냅샷임을 명시. 등록된 예정 축제만 잡히니 조회 시점에 따라 값이 달라진다. 카드 후보표 값 대신 지금 다시 받은 값을 쓴다.
- 한 달 급증을 추세로 착각(축제 등 이벤트 확인).