코로나19 지역 분석 — 행정구역 인구부터 동선 핫스팟, 지역 온톨로지까지

워크숍 목표

다 끝내고 나면 D.Hub 안에서 다음 흐름을 한 사이클 손으로 통과한 셈이 됩니다.

• 시나리오 1개를 포털로 적재해 컬렉션 1종, 데이터셋 9종(입력 5 + 중간 4), 코드 노드 4종, 파이프라인 4종, 온톨로지 6엔티티/6관계, 에이전트 1종을 한꺼번에 등록합니다.
• 행정구역 3 계층(시도 / 시군구 / 동) 별 유동 인구 와 등록 거주 인구 두 원천을 복합키로 통합합니다.
• 환자 위치 + 선별 진료소 + 동선 핫스팟 세 감염 시그널을 같은 동 단위에 정렬해 한 동 안의 환자 군집 + 가용 진료소 가 한 화면에 들어오도록 합니다.
• 6 엔티티 / 6 관계의 지역 온톨로지에서 환자 → 핫스팟 → 동 → 시군구 → 시도 5-홉 경로를 펼쳐 봅니다.
• epidemic_assistant 에이전트 호출 시 자연어 질의로 특정 시군구의 환자 군집 + 핫스팟 분포 를 한 응답으로 받습니다 (선택).

전염병 감시 분야의 지역 단위 통합 분석 시나리오입니다. 환자·진료소·핫스팟 데이터를 행정구역 위계에 정렬하는 공간 조인 패턴이 핵심 학습 주제입니다. 권장 소요 시간은 90분.

사전 준비

• D.Hub 포털 접근 가능한 분석가 또는 엔지니어 계정 (Editor 권한 이상)
• 약 70KB 의 zip 한 개를 받을 다운로드 여유

1. 시나리오 적재 (10분)

포털 좌측 사이드바 컬렉션 → 더보기(⋯) → 가져오기 로 zip 을 올립니다.

manifest.json 순서대로 다음 자산이 올라갑니다.

1. 컬렉션 1종 — covid19 (alias: 코로나19 지역 분석)
2. 데이터셋 9종 — 입력 5 (floating_population, residents_population, region_dong_info, patient, clinics, hotspot_result), 중간 3 (region_dong, sido_filter, sigungu_filter)
3. 코드 4종 (Python) — join_populations, sido_filter, sigungu_filter, build_covid_ontology
4. 파이프라인 4종 — join_population, sido_filter, sigungu_filter, ontology_materialization
5. 온톨로지 — 엔티티 6종(patient, clinic, hotspot, sido, sigungu, dong), 관계 6종
6. 에이전트 — epidemic_assistant

적재 완료 후 좌측 트리에 covid19 한 컬렉션이 보입니다.

2. 인구 데이터 둘러보기 (12분)

이 시나리오의 출발점은 행정구역 × 인구 두 원천입니다.

floating_population — 동별 주간 유동 인구. 컬럼: sido_name, sigungu_name, dong_name, week_start_date, floating_count (해당 주의 평균 유동 인구).

residents_population — 동별 등록 거주 인구. 컬럼: sido_name, sigungu_name, dong_name, register_year, male_count, female_count, total_residents.

두 데이터셋의 스키마 탭 에서 복합키 (sido_name, sigungu_name, dong_name) 가 양쪽에서 같은 타입(string) 인지, 행정구역 명칭 표기가 일치하는지 (예: 세종특별자치시 vs 세종시) 확인합니다. §3 의 join 이 이 복합키에 의존합니다.

region_dong_info — 지역 메타데이터. 동 단위의 면적·좌표·상권 정보 등 부가 정보. 다음 단계의 행정 계층 룩업 에서 함께 사용됩니다.

3. 인구 통합 + 행정 계층 룩업 (15분)

covid19 컬렉션의 파이프라인 섹션에서 세 파이프라인을 차례로 실행합니다.

join_population — 노드 하나, join_populations 스크립트가 두 인구 원천을 복합키 (sido_name, sigungu_name, dong_name) 로 outer join → region_dong. 한 행에 유동 인구 와 거주 인구 가 함께 들어가고, 한쪽만 있는 동은 다른 쪽이 null 로 표시됩니다.

sido_filter — region_dong 에서 고유 시도 이름만 추출 → sido_filter. 컬럼은 단순히 sido_id (sido_name 그대로), sido_name.

sigungu_filter — region_dong 에서 시도 + 시군구 조합의 고유 행만 남김 → sigungu_filter. 컬럼: sigungu_id ("시도|시군구" 형식), sido_name, sigungu_name.

세 파이프라인을 차례로 Run 합니다. 끝나면 region_dong 의 행 수가 두 원천의 합집합 동 개수 와 일치하는지, sido_filter 가 17 행 (전국 시도) 이하인지 확인합니다.

4. 환자 · 진료소 · 핫스팟 데이터 (10분)

patient — 환자 기록. 컬럼: patient_id, age_group, gender, sido_name, sigungu_name, dong_name, infection_date. 위치는 환자가 생활한 동 으로 정규화돼 있습니다 (정확한 주소가 아닙니다).

clinics — 선별 진료소. 컬럼: clinic_id, clinic_name, clinic_type (screening / respiratory_dedicated), sample_available (boolean, 검사 가능 여부), address, latitude, longitude, sido_name, sigungu_name, dong_name.

hotspot_result — 동선 추적 핫스팟. 한 행 = 환자 두 명이 같은 동에서 같은 시간대에 머문 한 쌍. 컬럼: hotspot_id, patient_a_id, patient_b_id, dong_name, cross_start_time, cross_end_time, location_description.

세 입력의 공간 단위 는 모두 동 입니다. 다음 단계의 온톨로지가 환자 → 동, 진료소 → 동, 핫스팟 → 동 세 관계로 모두 같은 dong 노드에 모이도록 설계됐습니다.

5. 지역 온톨로지 + 그래프 탐색 (15분)

ontology_materialization 파이프라인을 Run 합니다. build_covid_ontology 가 5 입력 + 3 중간 데이터셋을 batch 모드로 읽어 다음 6 엔티티 + 6 관계를 upsert 모드로 적재합니다.

관계 6종:

• belongs_to_sido (시군구 → 시도) — 행정 계층 위
• belongs_to (동 → 시군구) — 행정 계층 아래
• resides_in (환자 → 동)
• located_in (진료소 → 동)
• within (핫스팟 → 동)
• involved_in (환자 → 핫스팟)

그래프 탐색기 에서 한 환자의 감염 위치 컨텍스트 를 5-홉 경로로 띄웁니다.

MATCH (p:patient)-[:involved_in]->(h:hotspot)-[:within]->(d:dong)
       -[:belongs_to]->(sg:sigungu)-[:belongs_to_sido]->(s:sido)
RETURN p, h, d, sg, s
LIMIT 25

한 환자의 위치 컨텍스트 (개인 → 핫스팟 → 동 → 시군구 → 시도) 가 그래프 한 화면에 잡힙니다. 같은 환자가 여러 핫스팟 에 연관되거나, 한 동에 환자 군집 + 진료소 가 함께 놓이는 패턴이 시각적으로 한 번에 떨어집니다.

이어서 한 동에서 시작해 동선이 교차한 환자 네트워크 를 펼쳐 봅니다.

MATCH (d:dong {dong_name: '명동'})<-[:within]-(h:hotspot)<-[:involved_in]-(p:patient)
RETURN d, h, p
LIMIT 50

한 동 안에서 어떤 시간대에 누가 누구와 마주쳤나 의 네트워크가 한 그래프에 펼쳐집니다. 노드를 더블 클릭해 이웃 핫스팟 으로 확장하면 감염 전파 후보 경로가 더 길어집니다.

6. 한 동 단위의 분석 — 환자 × 진료소 × 인구 밀도 (15분)

이번 단계는 한 동의 운영 시점 을 직접 짭니다. 그래프 탐색기에서 한 환자 군집이 잡힌 동 하나를 선택합니다 (시드 데이터 기준 서울 강남구 역삼1동 추천). 다음 네 가지를 한 화면에 모읍니다.

1. 그 동의 total_residents 와 floating_count — region_dong 미리 보기에서 한 행 찾기. 유동 ≫ 거주 면 출퇴근 인구가 큰 업무 지구.
2. 그 동의 환자 수 — patient 미리 보기에서 dong_name 필터링. 시드 기준 평균 2–8 명.
3. 그 동 안의 진료소 — clinics 미리 보기에서 dong_name + sample_available = true 필터링. 0–3 개.
4. 그 동의 핫스팟 — hotspot_result 의 dong_name 필터링. 핫스팟 1개당 환자 2명 쌍.

이 네 숫자가 진료소 부족 동 (환자 5명 + 진료소 0개) 같은 운영 시그널을 직접 보여 줍니다. 시드 데이터는 일부러 진료소 분포 불균형 을 심어 뒀습니다 — 일부 시군구는 환자 대비 진료소가 부족합니다.

7. 다음 단계 + 회고 (5분)

여기까지 왔다면 한 공공보건 시나리오 위에서 다음 다섯 흐름을 한 번씩 통과한 셈입니다.

• 두 인구 원천의 복합키 outer join
• 행정 계층 3 단 룩업 테이블 추출
• 환자·진료소·핫스팟 세 시그널의 동 단위 정렬
• 6 엔티티 그래프의 5-홉 환자 위치 컨텍스트 경로
• 한 동의 운영 시점 4 숫자 묶음

끌리는 방향으로 한 발 더:

• epidemic_assistant 에이전트 를 호출해 "강남구 역삼1동의 환자 수와 진료소 분포는?" 같은 자연어 질의를 한 사이클 돌립니다. 에이전트가 동 단위 그래프 쿼리를 자동 생성합니다.
• 엔지니어 코스 의 파이프라인 스케줄링 으로 가서, 환자·핫스팟 데이터가 매시간 적재 된다는 가정 하에 ontology_materialization 의 자동 실행을 등록합니다.
• 자기 도메인 의 위계 + 위치 데이터 (학교 학군, 매장 상권, 인프라 자산) 에 본 형판을 옮깁니다.

검증 체크리스트

• 컬렉션 covid19 에 입력 5 + 중간 3 데이터셋이 모두 올라가 있는지
• join_population 실행 뒤 region_dong 의 한 행이 유동 인구 + 거주 인구 두 측정을 함께 갖고 있는지
• sido_filter 실행 결과의 행 수가 전국 시도 개수 이하 (시드 기준 17 이하) 인지
• 그래프 탐색기에서 patient 한 노드를 시작점으로 5-홉 경로 (patient → hotspot → dong → sigungu → sido) 를 펼칠 수 있는지
• 한 동 단위의 환자 × 진료소 × 핫스팟 × 인구 밀도 4 숫자를 한 화면에 모을 수 있는지 (§6 의 핵심 결과)