데이터 원천 간 엔티티 매칭

11/12(목)

한 줄 요약: 시스템마다 번호 체계가 다를 때, 양쪽에 함께 있는 다른 정보(필지번호·위치·이름)로 "같은 대상"을 짝짓고, 또 다른 정보로 다시 확인하는 일이다. 결과는 원본을 고치지 않고 별도 대응표에 근거·등급과 함께 적는다.

📍 만난 상황

• 2026-11-12 — 재난안전AI 1단계 평가 발표자료의 국토부 시설물 데이터 칸을 산출물과 대조하던 중이었다(→ 작업 5). 슬라이드의 "원천 간 대응표 / 식별자 매칭 83건"이 무슨 뜻인지에서 시작해 4번 물음 → 그날 일지
• 15:21 발표자료 검토 결과를 들은 뒤 "[원천 간 대응표]가 뭘 말하는 걸까?" → 다른 시스템에 따로 등록된 같은 시설물을 짝지어 적는 표라는 답.
• 15:24 평가장용 설명을 받은 뒤 "번호가 다른데 같은 건물인 건 어떻게 알았음?" → 83건은 번호가 똑같았던 경우라는 정정.
• 15:38 위치 정밀도 설명을 들은 뒤 "뭘 보고 같은 건물인지 아냐고, 실제 데이터로 보여 줘" → 강남구 건축물대장과 GIS건물통합정보를 PNU로 맞대 본 표를 받음.
• 15:41 그 표를 본 뒤 "FMS랑 건축물대장은 어떻게 연결해? 대응표는 뭘 말하는 거야" → 공통 키가 없어 안전정보 통합공개를 다리로 건너간다는 답.

🧩 쉽게 말하면

학교 명단과 학원 명단을 합친다고 해 보자. 학교는 학번 2401, 학원은 회원번호 M-77로 같은 학생을 적었다. 번호만 봐서는 같은 사람인지 모른다.

그래서 이름·생년월일·사는 동처럼 두 명단에 다 있는 정보로 짝을 짓는다. 동명이인이 있을 수 있으니 전화번호 뒷자리로 한 번 더 확인한다.

이렇게 짝지은 결과를 "학교 2401 = 학원 M-77"이라고 따로 적은 메모가 대응표다.

이게 없으면 같은 학생이 두 명으로 세어진다. 학교에만 있는 성적과 학원에만 있는 주소도 합칠 수 없다.

📖 제대로 알기

용어

• 엔티티(entity): 데이터가 가리키는 현실의 대상 하나. 건물 한 동, 교량 하나.
• 원천(source): 데이터를 내놓는 시스템. 예: FMS(시설물통합정보관리시스템), 건축HUB 건축물대장, GIS건물통합정보, 안전정보 통합공개.
• 엔티티 매칭: 서로 다른 원천의 레코드가 같은 엔티티인지 판정해 짝짓는 일. record linkage(레코드 연결), entity resolution이라고도 한다.
• 식별자(ID): 원천 안에서만 레코드를 구분하는 번호. 원천마다 체계가 다르다.
• 매칭 키: 두 원천에 똑같이 들어 있어 짝짓기에 쓰는 값.
• PNU(필지고유번호): 땅 한 필지를 가리키는 19자리 국가 표준 번호. 시군구 5 + 법정동 5 + 산 여부 1 + 본번 4 + 부번 4자리다.
• 대응표(crosswalk, 매칭 테이블): 매칭 결과를 "기준 ID · 대상 ID · 근거 · 등급 · 검증상태"로 적는 별도 표.

왜 두 단계로 나누나

1. 통합 식별자 붙이기: 원천 레코드마다 원천시스템코드:원천레코드키 같은 식별자를 붙인다. 레코드끼리 합치지 않는다.
2. 대응표에 관계 적기: "A의 이 레코드 = B의 저 레코드"를 따로 적는다. 원본은 그대로다.

매칭은 틀릴 수 있다. 원본을 합쳐 버리면 틀렸을 때 되돌리기 어렵다. 대응표면 그 행만 "기각"하면 된다.

근거별 신뢰등급

등급	무엇이 같나	쓰는 법
A	식별자 그대로 일치	거의 확실, 자동 채택
B	PNU·지번 일치 + 속성 확인	높음, 자동 채택
C	좌표 근접, 이름·행정구역 1:1	사람이 검토해 채택한 것만
D	이름·주소 글자가 비슷	참고용 연결

검증상태는 자동·검토대기·채택·기각 네 가지다. 지식그래프에서 "같은 시설물 한 노드"로 묶는 것은 A·B와 채택된 C뿐이다.

⚙️ 어떻게 동작하나

1. 후보 좁히기(블로킹: 비교할 쌍을 미리 줄이는 일) — 매칭 키가 같은 레코드끼리만 후보로 묶는다. 모든 쌍을 비교하면 너무 많다.
2. 다시 확인하기 — 키 말고 양쪽에 따로 적힌 속성을 대조한다. 건물이면 사용승인일·연면적·지상층수·용도.
3. 관계 모양 보기 — 1:1인지, 한 필지에 여러 동(1:N)인지, 짝이 없는지 나눈다.
4. 등급·상태 기록 — 확인이 다 맞으면 B, 애매하면 C로 내려 검토대기.
5. 공통 키가 없으면 다리 건너기 — 두 원천 모두와 이어지는 세 번째 원천을 거친다.

flowchart LR
  F["FMS<br/>시설물번호<br/>주소는 구까지"] -->|"① 번호 일치"| S["안전정보 통합공개<br/>같은 번호 + 지번"]
  S -->|"② 지번 → PNU"| G["GIS건물통합정보<br/>PNU + 건물 속성"]
  G -->|"③ 이름·준공일 대조"| R["대응표에 기록"]

FMS와 건축물대장 사이엔 공통 키가 없다. 그래서 FMS 번호를 그대로 쓰는 안전정보 통합공개로 지번을 얻고, 그 지번으로 건물 데이터에 닿은 뒤 속성으로 확인한다.

🧪 예시

• 예시 1 · 일상에 빗대어: 택배 회사 두 곳의 고객 명단을 주소로 합친다. 같은 주소가 100건 나왔다.
• 85건은 그 주소에 집이 한 채라 바로 짝이 맞는다. 이름까지 같으면 확정.
• 10건은 다세대 주택이라 주소만으로 어느 집인지 모른다. 이름·호수를 더 봐야 한다.
• 5건은 이사 와서 사람이 바뀌었다. 주소는 같아도 다른 고객이다.

• 주소 = PNU, 다세대 = 한 필지 여러 동, 이사 = 재건축이다.

• 예시 2 · 실제로는: 강남구 건축물대장(건축HUB)과 GIS건물통합정보를 PNU로 맞대는 SQL이다.

  SELECT r.bld_id AS register_id, g.bld_id AS gis_id,
         CASE WHEN r.use_apr_day = g.use_apr_day
               AND abs(r.tot_area - g.tot_area) < 1
               AND r.grnd_flr = g.grnd_flr
              THEN 'B' ELSE 'C' END AS grade
  FROM register r
  JOIN gis_building g ON g.pnu = r.pnu
  WHERE (SELECT count(*) FROM gis_building x
         WHERE x.pnu = r.pnu) = 1;
  

  ① JOIN … ON g.pnu = r.pnu: 같은 땅 위의 건물만 후보로 잇는다(블로킹). ② CASE …: 사용승인일·연면적·층수가 다 맞으면 B, 하나라도 다르면 C로 내린다. ③ WHERE … = 1: 그 필지에 GIS 건물이 한 동뿐인 1:1만 남긴다. 여러 동이면 따로 처리한다.

실제 결과(건축물대장 6,697건 ↔ GIS 28,228건): - 1:1 5,202건. 그중 4,654건(89.5%)은 사용승인일·연면적·지상층수·용도가 모두 같았다. - 한 필지 여러 동 684건, 짝 없음 811건. - 역삼동 601-15 "반디빌딩"은 건물 번호 자릿수부터 다르지만(14자리 vs 28자리) PNU·이름·사용승인일·연면적 3486.6㎡·12층이 모두 같다. - 반례: 역삼동 601-1은 PNU가 같은데 대장은 2025년 18층, GIS는 2004년 7층이다. 재건축이 GIS에 아직 반영되지 않았다.

FMS 강남구 122건을 다리로 건너간 결과는 122 → 55(번호로 지번 확보) → 23(그 필지에 건물 있음) → 4(이름·준공일 일치)였다. 남은 19건은 교량·역·터널이 대표 필지의 엉뚱한 건물에 걸린 경우다.

⚖️ 비교 · 흔한 오해

이름	무엇을 잇나	예
원천 간 (식별자) 대응표	레코드 ↔ 레코드	대장 건물 ↔ GIS 건물
원천 코드 대응표	코드값 → 표준 코드값	건축HUB 구조 코드 → 표준 구조형식코드
SQL 조인	키가 같은 행을 즉석 결합	근거·검토 기록이 남지 않음

• 오해 1: "83건은 번호가 다른데 맞춘 결과" → 아니다. 번호가 똑같았던 A등급 한 쌍이다. 안전정보 통합공개가 FMS 번호를 그대로 가져다 써서, FMS 1,854건과 안전정보 346건을 대조하니 83건이 일치했다.
• 왜 헷갈리기 쉽나: 바로 앞에 "시스템마다 번호가 다르다"는 설명을 들었다. 슬라이드엔 "식별자 매칭 83건"이 대응표 상자 안에 있어 전체 결과처럼 보였다.
• 오해 2: "번호가 다르면 같은지 알 방법이 없다" → 번호는 원천 안에서만 통하는 이름표다. 현실의 건물은 땅(PNU)·위치·이름·준공일 같은 다른 흔적을 양쪽에 남긴다.
• 왜 헷갈리기 쉽나: DB에서 표를 이을 때는 늘 "같은 키 값"으로 JOIN한다. 그래서 키가 다르면 이을 수 없다고 느낀다. 실제로는 잇는 키(PNU)와 확인하는 속성(승인일·면적·층수)을 따로 고르는 것이다.
• 오해 3: "PNU가 같으면 같은 건물" → 재건축, 한 필지 여러 동, 건물이 아닌 시설에서 틀린다. "영동5교 = 선경아파트9동" 같은 오류가 실제로 나왔다.
• 오해 4: "대응표 = 몇 건짜리 결과" → 대응표는 표의 구조다. 건수는 원천 쌍·등급마다 따로 센다.

🛠️ 실무에서는

• 원천마다 식별자와 위치 표현 수준(좌표·지번·구 단위)을 먼저 표로 정리한다.
• 매칭 키는 국가 표준 코드(PNU, 법정동코드)를 먼저 찾는다. 자릿수·하이픈·산 여부 표기를 맞춘다.
• 키 하나로 확정하지 않는다. 항상 다른 속성으로 확인한다.
• 1:1 건수만 말하지 말고 1:N·짝 없음 건수도 같이 보고한다.
• C·D의 기준값(몇 m 이내, 이름이 몇 % 비슷)은 표본으로 검증해 정한다. 1차년도엔 규칙만 있고 기준값은 2차년도 확정이다.
• 대상 종류를 본다. FMS↔건축물대장 매칭은 펌프장·다중이용건축물 같은 건물형에만 의미가 있다.
• 매칭률이 갑자기 떨어지면: 원천 갱신 시점 차이(재건축 미반영), 키 형식 변화부터 본다.

❓ 자주 묻는 질문

• Q. 89.5%가 맞았으면 나머지 10%는 틀린 매칭인가? A. 꼭 그렇진 않다. 면적 소수점·갱신 시점 차이일 수도, 진짜 다른 건물일 수도 있다. 그래서 C로 내려 사람이 본다.
• Q. 공통 키가 하나도 없으면? A. 다리 원천을 찾거나, 좌표 근접·이름 유사로 C·D 매칭을 한다. 확실도가 낮아 채택된 것만 쓴다.
• Q. 왜 원본 데이터에 바로 합치지 않나? A. 틀린 매칭을 되돌리고, "왜 같다고 봤는지" 근거를 추적하려고.
• Q. 평가장에서 한 줄로 말하면? A. "시스템마다 같은 시설물을 다른 번호로 관리해서, '이것과 저것은 같은 시설물'이라는 관계를 근거·신뢰등급과 함께 따로 기록한 연결표입니다."

🔭 더 깊이 보기

• 이름 유사도와 거리 기준은 어떻게 정하나? — C·D등급 기준값을 정할 때 바로 필요하다.
• 확률적 레코드 연결(Fellegi–Sunter 모델)은 무엇인가? — 여러 속성의 일치를 점수 하나로 합치는 표준 방법이다.
• 좌표가 점이 아니라 도형이면 "같은 위치"를 어떻게 판정하나? — C등급(위치 근접) 기준을 정할 때 공간 관계 판정이 필요하다.
• 관련 주제: DE-9IM 공간 관계 판정, 지오코딩과 참조 데이터 매칭, H3 격자 체계와 해상도, DB 정규화와 연결 표, 좌표계 변환과 pyproj

📚 참고 자료

• Record linkage (위키백과, 영문) — 엔티티 매칭의 정의, 결정적·확률적 방법의 차이 · 링크
• Splink 문서 (영문 오픈소스 문서) — 블로킹·속성 비교·점수 매기기를 실제 도구로 보는 법 · 링크
• 국토교통부_건축HUB_건축물대장정보 서비스 (공공데이터포털) — 표제부의 PNU 구성 항목, 사용승인일·연면적 열 이름 확인. 포털에서 제목으로 검색 · 공공데이터포털

🗓️ 이력

• 2026-11-12: "원천 간 대응표"의 뜻에서 시작해, 번호가 다른데 같은 건물을 어떻게 아는지 실제 데이터로 확인하기까지 4번 물음 → 일지

🕸️ 연결된 주제

바로 이어진 주제 5개전체 지도에서 보기 →

다른 주제 랜덤으로 보기