공공데이터 표준화: 기관별 용어·코드·주소와 변경 이력 관리

1장. 열 이름은 같아졌는데 데이터의 뜻은 더 틀려졌다#

세 기관이 보유한 공공시설 데이터를 하나로 합친다고 하겠습니다.

A기관:

시설상태 = 2

B기관:

시설상태 = C

담당자는 두 값을 모두:

미운영

으로 바꿨습니다.

표면적으로는 완벽한 표준화입니다.

서로 달랐던 코드가 하나로 통일됐습니다.

하지만 원래 의미를 확인해 보니:

A기관
2 = 휴업

B기관
C = 폐업

이었습니다.

휴업 시설은 다시 운영할 수 있습니다.

폐업 시설은 영업을 종료한 시설입니다.

두 상태를 미운영 하나로 통합하면서 중요한 업무 의미가 사라졌습니다.

이것이 공공데이터 표준화에서 가장 흔한 문제입니다.

표현을 같게 만드는 것과 의미를 같게 만드는 것은 전혀 다른 작업이다.

2장. 공공데이터 표준화는 이름을 통일하는 작업이 아니다#

표준화라고 하면 다음 작업부터 떠올리기 쉽습니다.

서울시
→ 서울특별시

LIB
→ 도서관

01
→ 운영

물론 이런 작업도 필요합니다.

하지만 실제 표준화의 핵심은:

이 값은 정확히 무엇을 뜻하는가?

어느 기간에 이 의미가 유효했는가?

원천 기관에서는 어떤 값이었는가?

누가 어떤 규칙으로 변환했는가?

를 설명할 수 있게 만드는 것입니다.

3장. 같은 단어도 기관마다 다른 사건을 뜻할 수 있다#

두 기관에 모두 다음 열이 있다고 하겠습니다.

등록일

A기관의 등록일:

민원 신청 접수일

B기관의 등록일:

행정기관 승인 완료일

입니다.

열 이름은 완벽하게 같습니다.

하지만 같은 날짜로 분석하면 안 됩니다.

예를 들어 업무 처리기간을 계산할 때:

승인일 - 등록일

을 사용하면 A와 B에서 전혀 다른 지표가 만들어집니다.

4장. 이름보다 정의가 먼저다#

표준 용어를 만들 때:

등록일

이라는 이름부터 정하는 것이 아니라 먼저 개념을 분리해야 합니다.

예:

신청접수일

승인완료일

최초등록일

시스템입력일

이 네 날짜는 서로 다릅니다.

이후 각 기관의 필드를 어떤 표준 개념에 연결할지 결정합니다.

5장. 세 기관의 시설 데이터를 예제로 사용해 보자#

다음 원천 데이터가 있다고 하겠습니다.

기관	시설종류 원값	시설주소 원값	갱신일
A	도서관	서울시 중구 예시로 1	2026-09-01
B	LIB	서울특별시 중구 예시로 1	2026-09-20
C	체육시설	NULL	2026-08-30

겉으로 보면 A와 B의 주소는 매우 비슷합니다.

그러나:

주소가 비슷하다
=
같은 시설

이라고 단정할 수는 없습니다.

6장. 주소 문자열은 실체 식별자의 대체물이 아니다#

두 시설의 주소가 다음처럼 같습니다.

서울특별시 중구 예시로 1

그 건물 안에 다음 시설이 함께 있을 수도 있습니다.

도서관

주민센터

체육시설

민원실

따라서 동일 시설 판정에는 추가 정보가 필요할 수 있습니다.

시설 고유 ID

기관 ID

사업자 또는 운영 주체

좌표

시설명

유효기간

주소 표준화와 동일 시설 식별은 별도의 문제입니다.

7장. 표준화는 네 가지 층으로 나눠 보면 이해하기 쉽다#

대표적으로 다음을 구분할 수 있습니다.

구분	질문
표준 용어	이 데이터의 의미는 무엇인가?
표준 도메인	어떤 형식과 값 범위를 허용하는가?
표준 코드	허용 값 각각은 무엇을 뜻하는가?
데이터 요소	실제 데이터 열에 어떤 표준을 적용하는가?

이 네 가지를 섞으면 이름만 통일되고 실제 의미는 달라질 수 있습니다.

8장. 표준 용어는 단어가 아니라 개념을 정의한다#

예를 들어:

시설종류

라는 표준 용어를 만든다고 하겠습니다.

정의는 단순히:

시설의 종류

라고 쓰기보다 더 구체적으로 만드는 편이 좋습니다.

예:

공공서비스 제공을 위해 관리되는 시설을 업무 기능에 따라 분류한 값.

이 정의를 기준으로:

업종

건물용도

시설분류

기관유형

이 같은 개념인지 다른 개념인지 판단합니다.

9장. 표준 도메인은 값의 구조와 허용 범위를 정의한다#

예를 들어 시설 상태 코드의 도메인을:

OPEN

TEMP_CLOSED

CLOSED

UNKNOWN

으로 정할 수 있습니다.

날짜라면:

YYYY-MM-DD

형식을 사용할 수 있습니다.

수량이라면:

0 이상의 정수

처럼 정의할 수 있습니다.

도메인은 단순 데이터 타입보다 넓은 업무 규칙을 포함할 수 있습니다.

10장. 문자열이라는 데이터 타입만으로는 부족하다#

다음 두 열은 모두 문자열입니다.

facility_name varchar

status_code varchar

하지만 의미는 완전히 다릅니다.

시설명:

자유 텍스트

시설상태코드:

허용 코드 집합만 가능

따라서:

VARCHAR

라는 물리 데이터 타입과:

시설상태코드 도메인

을 분리해서 생각해야 합니다.

11장. 표준 코드는 값과 의미를 함께 관리한다#

표준 상태 코드를 다음처럼 정했다고 하겠습니다.

코드	의미
OPEN	운영
TEMP_CLOSED	휴업
CLOSED	폐업
UNKNOWN	미확인

이제 기관별 값을 여기에 연결합니다.

12장. 기관 A와 B의 코드를 매핑해 보자#

A기관:

1 = 운영
2 = 휴업

B기관:

O = 운영
C = 폐업
X = 의미 미확인

변환표:

기관	원천 코드	표준 코드
A	1	OPEN
A	2	TEMP_CLOSED
B	O	OPEN
B	C	CLOSED
B	X	UNKNOWN

이렇게 하면 휴업과 폐업의 차이를 보존할 수 있습니다.

13장. 원천 기관까지 코드 키에 포함해야 한다#

다음 코드를 생각해 보겠습니다.

A기관에서는:

01 = 운영

B기관에서는:

01 = 신청

일 수 있습니다.

따라서 매핑 키를 단순히:

source_code

로 만들면 안 됩니다.

개념적으로:

source_system
+
source_code

가 필요합니다.

14장. SQL로 기관별 코드 매핑을 해보자#

WITH raw(
    source,
    facility_id,
    status_code
) AS (
    VALUES
        ('A', 'F1', '1'),
        ('A', 'F2', '2'),
        ('B', 'F3', 'O'),
        ('B', 'F4', 'C'),
        ('B', 'F5', 'X')
),
code_map(
    source,
    source_code,
    public_status
) AS (
    VALUES
        ('A', '1', '운영'),
        ('A', '2', '휴업'),
        ('B', 'O', '운영'),
        ('B', 'C', '폐업')
)
SELECT
    r.facility_id,
    r.source,
    r.status_code,
    COALESCE(
        m.public_status,
        '미확인'
    ) AS public_status
FROM raw r
LEFT JOIN code_map m
  ON m.source = r.source
 AND m.source_code = r.status_code
ORDER BY r.facility_id;

결과:

시설	기관	원천 코드	표준 상태
F1	A	1	운영
F2	A	2	휴업
F3	B	O	운영
F4	B	C	폐업
F5	B	X	미확인

15장. 매핑되지 않은 값을 임의로 추측하지 않는 것이 중요하다#

B기관의:

가 코드 사전에 없습니다.

담당자가 생각하기에:

아마 폐업일 것이다.

라고 판단해:

X → CLOSED

로 변환하면 안 됩니다.

현재 우리가 알고 있는 사실은:

X의 의미를 아직 모른다.

입니다.

따라서:

UNKNOWN

또는 별도의 매핑 오류 상태로 남기는 것이 더 정확합니다.

16장. 모른다는 상태를 보존하는 것도 표준화다#

표준화는 모든 값을 강제로 표준 코드에 넣는 작업이 아닙니다.

오히려:

미확인

원천 오류

해당 없음

비공개

미수집

같은 상태를 구분하는 것이 중요합니다.

모두 빈 문자열 하나로 합치면 의미가 사라집니다.

17장. NULL 하나에도 여러 이유가 숨어 있다#

시설 주소가 NULL이라고 하겠습니다.

가능한 이유는:

아직 조사하지 않음

주소 자체가 없는 시설

공개 제한

원천 시스템 누락

연계 오류

적용 대상 아님

등입니다.

단순히:

주소 없음

이라고만 표시하면 이용자가 원인을 알 수 없습니다.

18장. 결측 사유를 별도 코드로 관리할 수 있다#

예:

코드	의미
NOT_COLLECTED	미수집
NOT_APPLICABLE	해당 없음
WITHHELD	공개 제한
SOURCE_ERROR	원천 오류
UNKNOWN	사유 미확인

시설주소:

NULL

와 함께:

address_missing_reason
=
NOT_COLLECTED

을 제공할 수 있습니다.

19장. 결측 사유가 있어야 완전성 계산도 정확해진다#

시설 100개가 있습니다.

그중 주소가 실제로 필수인 시설:

90개

입니다.

주소가 입력된 시설:

81개

입니다.

완전성:

81 / 90
=
90%

입니다.

전체 100개를 분모로 사용하면:

81%

가 됩니다.

주소가 업무적으로 필요하지 않은 10개까지 오류로 센 것입니다.

20장. 빈칸을 0으로 바꾸면 새로운 사실을 만들어 버릴 수 있다#

공공 체육시설의 이용자 수가 비어 있다고 하겠습니다.

NULL

의 의미가:

측정하지 않음

일 수 있습니다.

이를:

으로 바꾸면:

이용자가 한 명도 없었다.

라는 새로운 사실을 만들어 버립니다.

미측정
≠
0

입니다.

21장. 코드의 현재 의미만 저장하면 과거 파일을 잘못 해석할 수 있다#

A기관에서 코드:

의 의미가 2026년에는:

도서관

이었다고 하겠습니다.

2027년부터 코드 체계가 변경되어:

01 = 문화시설

이 됐습니다.

문자열 자체는 같습니다.

의미만 달라졌습니다.

22장. 코드에는 유효기간이 필요하다#

코드 매핑을 다음처럼 저장할 수 있습니다.

기관	원코드	표준코드	유효 시작	유효 종료
A	01	LIB	2026-01-01	2026-12-31
A	01	CULTURE	2027-01-01	이후

이제 2026년 자료와 2027년 자료를 서로 다른 의미로 해석할 수 있습니다.

23장. 현재 코드표로 과거 자료 전체를 다시 변환하면 위험하다#

2026년 파일:

을 2027년의 최신 코드표로 해석하면:

문화시설

이 됩니다.

하지만 실제 당시 의미는:

도서관

이었습니다.

따라서 과거 공개 자료를 재처리하려면:

데이터 기준일
+
코드표 버전

이 필요합니다.

24장. 변환 규칙도 버전 관리해야 한다#

예:

FACILITY_STATUS_MAP v1

에서는:

A:2
→ 미운영

이었다고 하겠습니다.

나중에 의미 손실을 발견해:

FACILITY_STATUS_MAP v2

에서는:

A:2
→ 휴업

으로 수정했습니다.

공개 파일에 어떤 버전이 적용됐는지 남겨야 과거 결과를 재현할 수 있습니다.

25장. 원값을 버리면 잘못된 표준화를 되돌리기 어렵다#

A기관 원값:

을 표준화하면서:

미운영

으로 바꿨습니다.

원래 2를 삭제했습니다.

나중에 2=휴업이라는 사실이 밝혀졌습니다.

하지만 이미 데이터에는:

미운영

만 남아 있습니다.

원천이 A의 2였는지 B의 C였는지 알 수 없습니다.

26장. 표준값과 원천값을 함께 보존하는 것이 안전하다#

예:

source_system = A

source_status_code = 2

standard_status_code = TEMP_CLOSED

mapping_version = v2

처럼 저장합니다.

이 구조라면 매핑 규칙이 틀렸을 때 다시 변환할 수 있습니다.

27장. 데이터 계보를 구조로 표현하면#

flowchart LR
    A["기관 A 원천<br/>status=2"] --> M["매핑 규칙 v2"]
    M --> S["표준 상태<br/>TEMP_CLOSED"]
    S --> P["공개 API·CSV"]

나중에 공개 데이터의 TEMP_CLOSED가 어디에서 왔는지 역추적할 수 있습니다.

28장. 주소 표준화와 동일 시설 판정은 분리하자#

다음 두 주소가 있습니다.

서울시 중구 예시로 1

서울특별시 중구 예시로 1

표현을:

서울특별시 중구 예시로 1

로 통일할 수 있습니다.

이것은 주소 표현 표준화입니다.

하지만 두 행이 같은 시설인지 판단하려면 추가 정보가 필요합니다.

29장. 주소 정규화는 문자열 비교 정확도를 높일 뿐이다#

주소 정규화에서 다음 작업을 할 수 있습니다.

서울시
→ 서울특별시

불필요한 공백 제거

도로명 표기 통일

우편번호 표준화

이렇게 하면 같은 주소를 더 잘 찾을 수 있습니다.

하지만:

표준 주소 동일
=
시설 동일

은 아닙니다.

30장. 안정적인 시설 ID가 필요하다#

공개 CSV에서 다음처럼 행 번호를 시설 ID로 사용했다고 하겠습니다.

다음 달에 맨 앞에 신규 시설이 추가됐습니다.

기존 번호가 모두 바뀝니다.

이용자는:

시설 3 삭제

시설 4 신규

처럼 잘못 해석할 수 있습니다.

31장. 행 번호와 식별자는 다르다#

좋은 시설 ID는 재배포되어도 같은 시설에 대해 안정적으로 유지되어야 합니다.

예:

facility_id
=
F00001238

이렇게 하면:

9월 파일

10월 파일

11월 파일

에서 같은 시설을 추적할 수 있습니다.

32장. 시설이 실제로 폐지되더라도 ID를 재사용하지 않는 편이 안전하다#

시설 F100이 폐업했습니다.

나중에 같은 주소에 다른 시설이 생겼습니다.

새 시설에도:

F100

을 재사용하면 과거와 현재 시설이 하나로 연결될 수 있습니다.

식별자의 안정성에는 재사용하지 않는 것도 포함될 수 있습니다.

33장. 변경 유형까지 공개하면 파일 비교가 쉬워진다#

예:

facility_id = F100

change_type = ADDRESS_CORRECTION

또는:

NEW

UPDATED

CLOSED

CORRECTED

같은 변경 정보를 제공할 수 있습니다.

이용자는 전체 파일을 매번 비교하지 않고도 변경 내용을 추적하기 쉬워집니다.

34장. 게시일과 데이터 기준일을 구분해야 한다#

공개 파일이:

2026-09-27

게시됐습니다.

하지만 실제 데이터는:

2026-09-01

기준입니다.

이용자가 게시일만 보면 최신 9월 27일 자료라고 오해할 수 있습니다.

따라서:

published_at

data_as_of

를 구분하는 것이 좋습니다.

35장. 원천 갱신일과 통합 반영일도 다를 수 있다#

기관 B가 시설 주소를:

9월 20일

수정했습니다.

통합 플랫폼 반영:

9월 22일

공개 API 배포:

9월 23일

이라고 하겠습니다.

세 날짜는 다릅니다.

source_updated_at

integrated_at

published_at

을 구분하면 지연 원인을 찾기 쉽습니다.

36장. “최신 데이터”라는 표현은 어느 시간을 뜻하는지 밝혀야 한다#

다음 문구는 모호합니다.

최신 시설 데이터입니다.

무엇이 최신일까요?

원천 기관의 마지막 수정?

통합 플랫폼 적재?

공개 파일 생성?

API 제공?

기준 시점을 명확하게 제공해야 이용자가 최신성을 판단할 수 있습니다.

37장. 코드 변경은 데이터베이스만 고치면 끝나는 일이 아니다#

B기관이:

LIB

를:

LIBRARY

로 바꾸겠다고 요청했습니다.

영향을 받는 곳은 다양합니다.

ETL 매핑

공개 API

검색 필터

CSV 파일

이용자 프로그램

통계 집계

문서

코드 하나의 변경도 인터페이스 변경이 될 수 있습니다.

38장. 코드 변경에는 호환 기간이 필요할 수 있다#

기존 API 이용자는:

facilityType=LIB

로 검색하고 있습니다.

오늘부터 갑자기:

LIBRARY

만 허용하면 기존 프로그램이 실패합니다.

일정 기간:

LIB
+
LIBRARY

를 모두 허용하거나 버전이 다른 API를 제공하는 방식도 검토할 수 있습니다.

39장. 변경 관리 흐름을 그려보면#

flowchart TD
    R["표준 변경 요청"] --> I["영향 분석"]
    I --> A["의미·매핑 검토"]
    A --> V["버전·적용일 결정"]
    V --> T["샘플 데이터 시험"]
    T --> P["승인"]
    P --> D["배포"]
    D --> M["오류·미매핑 모니터링"]

표준화는 데이터 정제 작업이 아니라 지속적인 변경 관리 과정입니다.

40장. 데이터 소유자와 스튜어드의 역할은 다르다#

예를 들어 시설 데이터에서 역할을 나누면:

역할	책임 예
데이터 소유자	공개 범위·품질 목표·접근 승인
데이터 스튜어드	용어·코드·결측 규칙·품질 이슈
기술 관리인	파일·API·로그·백업·접근 제어
기관 간 협의체	여러 기관의 의미 충돌·변경 일정

조직마다 명칭은 다를 수 있지만 누가 어떤 결정을 내리는지가 명확해야 합니다.

41장. 기술 담당자가 원천의 빈 주소를 추정해서 채우면 안 되는 이유#

시설 C의 주소가 비었습니다.

기술 담당자가 지도에서 검색해 가장 비슷한 주소를 넣었습니다.

NULL
↓
서울특별시 중구 ...

파일의 완전성은 올라갑니다.

하지만 실제 시설 위치인지 검증되지 않았습니다.

완전성 ↑

정확성 ?

입니다.

원천 담당자의 확인을 거치는 것이 필요합니다.

42장. 표준화와 데이터 품질은 연결되어 있지만 같은 것은 아니다#

표준 코드:

OPEN

을 사용하고 있다고 하겠습니다.

형식은 완벽합니다.

하지만 실제 폐업 시설을:

OPEN

으로 잘못 등록했다면 데이터는 틀렸습니다.

즉:

표준 준수
≠
정확성 보장

입니다.

표준화는 품질 관리의 기반 중 하나입니다.

43장. 표준화를 했는데 미확인 비율이 증가할 수도 있다#

변환 전에는 모든 원천 코드가 값으로 존재했습니다.

변환 후:

UNKNOWN

이 5% 생겼습니다.

품질이 나빠진 것처럼 보일 수 있습니다.

하지만 실제로는 과거에 의미를 억지로 추정하던 값을:

모름

으로 정확하게 표시한 것일 수 있습니다.

불확실성을 드러내는 것도 품질 개선입니다.

44장. 작은 샘플로 코드 변경을 먼저 시험하자#

시설 100건에 새 매핑을 적용했다고 하겠습니다.

결과:

운영
70

휴업
10

폐업
15

미확인
5

입니다.

바로 배포하기보다 미확인 5건을 먼저 조사합니다.

어느 기관인가?

어떤 원천 코드인가?

신규 코드인가?

입력 오류인가?

를 확인할 수 있습니다.

45장. 매핑 커버리지도 품질 지표가 될 수 있다#

전체 원천 행:

100건

표준 코드로 정상 매핑:

95건

이라면:

매핑 커버리지
=
95 / 100
=
95%

입니다.

나머지 5건을 임의로 기타 코드로 보내서 100%를 만드는 것보다 실제 미확인 상태를 관리하는 편이 낫습니다.

46장. 하지만 매핑률 100%가 의미 보존 100%는 아니다#

A의 휴업과 B의 폐업을:

미운영

으로 모두 매핑하면 기술적인 매핑률은:

100%

입니다.

하지만 의미는 손실됐습니다.

따라서 다음 두 지표는 다릅니다.

매핑 성공률

의미 보존 품질

47장. 정보 손실은 역변환 가능성을 보면 발견하기 쉽다#

표준값:

미운영

만 보고 원래 값이:

A의 휴업

인지:

B의 폐업

인지 알 수 없다면 정보가 합쳐졌습니다.

원천 코드와 출처를 함께 보존하면 이런 손실을 줄일 수 있습니다.

48장. 공개 CSV에는 값만 넣지 말고 해석 정보도 제공해야 한다#

이용자는 기관 내부 시스템을 모릅니다.

따라서 다음 메타데이터가 중요합니다.

컬럼 설명

단위

코드표

결측 사유

자료 기준일

갱신 주기

좌표계

문자 인코딩

변환 기준 버전

정정 문의 경로

CSV 파일 하나만 제공하는 것보다 활용성이 크게 좋아집니다.

49장. 좌표 데이터는 좌표계가 없으면 숫자 두 개에 불과하다#

시설 위치:

x = 953123.4

y = 1954232.2

가 있다고 하겠습니다.

좌표계 정보를 모르면 위경도인지 투영 좌표인지 알기 어렵습니다.

따라서:

EPSG 코드

좌표 순서

단위

같은 정보가 필요합니다.

표준화는 값뿐 아니라 해석 조건까지 포함합니다.

50장. 숫자의 단위가 다르면 같은 컬럼으로 합치면 안 된다#

A기관:

면적
120

단위
㎡

B기관:

면적
36.3

단위
평

단순히:

facility_area

컬럼 하나에 넣으면 비교할 수 없습니다.

단위를 통일하거나 단위를 별도 필드로 명확하게 관리해야 합니다.

51장. 날짜에서도 기준 시간이 필요하다#

예:

2026-10-01 00:30

시간대가 없으면:

KST?

UTC?

를 알기 어렵습니다.

공공 API를 여러 시스템에서 사용한다면 시간대와 기준 시점을 명확히 하는 것이 좋습니다.

52장. 공개 자료의 법적 제공 여부는 데이터별로 확인해야 한다#

2026년 10월 1일 기준 국가법령정보센터에 표시된 현행 「공공데이터의 제공 및 이용 활성화에 관한 법률」은 2026년 8월 28일 시행본입니다. 제17조는 공공기관이 보유·관리하는 공공데이터를 제공하도록 하면서 정보공개법상 비공개대상정보나 정당한 이용허락을 받지 않은 제3자 권리 등이 포함된 경우를 예외로 두고, 기술적으로 분리 가능한 경우 해당 부분을 제외한 제공을 규정하고 있습니다. 따라서 특정 데이터셋의 공개 가능 여부는 실제 포함 정보와 적용 법령·권리관계를 개별적으로 확인해야 합니다.

53장. “공공데이터니까 전부 공개 가능하다”는 판단은 위험하다#

시설 데이터 안에도 다음 정보가 섞여 있을 수 있습니다.

담당자의 개인 휴대전화

개인 주소

계약 상대방 정보

제3자 권리 자료

보안상 제한 정보

따라서 데이터셋 이름만 보고 전체 공개 가능 여부를 판단해서는 안 됩니다.

필요하면 공개 가능한 열과 제한 대상 열을 분리하는 구조를 검토해야 합니다.

54장. 이용 조건도 실제 데이터셋 기준으로 확인해야 한다#

공공데이터 목록에는 이용요건 등이 함께 관리될 수 있습니다. 현행 공공데이터법 제19조도 제공목록과 이용요건의 공표를 규정하고 있습니다. 따라서 특정 자료를 재사용할 때는 포털 전체의 일반 설명만이 아니라 해당 데이터셋에 실제 표시된 이용조건을 확인하는 것이 안전합니다.

55장. 제공 후 오류 신고 경로도 데이터 품질의 일부다#

공개 데이터에 시설 주소 오류가 발견됐습니다.

이용자가 이를 발견했는데:

어디에 신고해야 하는지 모름

이라면 오류가 오랫동안 유지될 수 있습니다.

따라서 데이터와 함께:

문의처

오류 신고 방법

정정 주기

수정 이력

을 제공하는 것이 좋습니다.

56장. 정정하면 파일 버전도 바뀌어야 한다#

9월 시설 목록 v1에:

F100 주소 오류

가 있었습니다.

9월 28일 수정했습니다.

새 파일을 같은 이름으로 조용히 덮어쓰면 과거 다운로드 사용자와 결과가 달라집니다.

예:

facility_2026_09_v1.csv

facility_2026_09_v2.csv

처럼 버전이나 정정 시각을 관리할 수 있습니다.

57장. 과거 공개 결과를 재현할 수 있어야 한다#

사용자가 묻습니다.

9월 20일에 다운로드한 파일에서는 F100이 서울이었는데 지금은 왜 부산입니까?

답하려면 다음 정보가 필요합니다.

당시 공개 파일 버전

원천 값

정정 시각

변환 규칙

정정 사유

이 정보가 없다면 현재값만 보여줄 수 있을 뿐 변화 이유를 설명할 수 없습니다.

58장. 공개 데이터에는 두 종류의 이력이 필요할 수 있다#

실제 세계의 변화#

시설 이전

시설 폐업

운영기관 변경

데이터 오류의 정정#

오타 수정

잘못된 주소 수정

코드 매핑 수정

둘은 다릅니다.

실제 변화와 데이터 정정을 같은 UPDATED 하나로 표현하면 이용자가 의미를 구분하기 어렵습니다.

59장. 유효시간과 시스템시간을 구분하면 변경을 더 정확히 설명할 수 있다#

시설이 실제 이전한 날짜:

9월 1일

기관이 시스템에 수정한 날짜:

9월 5일

통합 플랫폼에 들어온 날짜:

9월 6일

공개된 날짜:

9월 7일

입니다.

각각 다른 의미를 가집니다.

valid_from

source_updated_at

ingested_at

published_at

처럼 관리할 수 있습니다.

60장. 공공데이터 표준화 전체 구조를 보면#

flowchart TD
    A["기관별 원천 데이터"] --> B["원천값 보존"]
    B --> C["용어·도메인 표준화"]
    C --> D["기관별 코드 매핑"]
    D --> E["미확인·결측 분리"]
    E --> F["품질 검증"]
    F --> G["공개용 표준 데이터"]
    G --> H["CSV·API"]
    H --> I["정정·오류 신고"]
    I --> J["변경 승인·새 버전"]
    J --> C

표준화는 한 번 하고 끝나는 변환 작업이 아닙니다.

61장. 표준화 품질을 측정하는 지표#

예를 들어 다음과 같은 지표를 관리할 수 있습니다.

지표	의미
매핑 커버리지	표준 코드로 해석 가능한 원천 비율
미확인 코드 수	사전에 없는 코드
필수 필드 완전성	필요한 값이 있는 비율
정정 처리시간	오류 신고부터 수정까지 시간
신규 코드 반영시간	기관 코드 변경부터 표준 반영까지 시간
원천 추적 가능률	공개값에서 원천까지 역추적 가능한 비율

단순히 “표준 준수율” 하나보다 실질적인 운영 상태를 잘 보여줍니다.

62장. 공개 데이터 100건을 점검하는 예#

시설:

100건

주소 필수 대상:

90건

주소 존재:

81건

주소 완전성:

81 / 90
=
90%

상태 코드 정상 매핑:

95건

미확인:

5건

매핑 커버리지:

95%

입니다.

두 지표는 서로 다른 품질 문제를 보여줍니다.

63장. 중복 시설 후보와 실제 동일 시설도 구분해야 한다#

표준 주소가 같은 시설 후보:

8쌍

이 발견됐다고 하겠습니다.

추가 확인 결과:

동일 시설
5쌍

같은 건물의 다른 시설
2쌍

확인 불가
1쌍

입니다.

따라서:

주소 중복 8쌍
=
실제 중복 시설 8쌍

이라고 발표하면 안 됩니다.

64장. 표준화 변경 전 검증할 질문#

새로운 표준을 배포하기 전에는 다음을 확인하는 것이 좋습니다.

원천 값과 표준 값의 의미가 정말 같은가?
한 원천 값이 여러 표준 의미로 나뉘지는 않는가?
여러 원천 의미를 하나로 합치면서 정보가 사라지지 않는가?
미확인 값은 몇 개인가?
과거 자료에도 같은 규칙을 적용할 수 있는가?
코드의 유효기간을 관리하는가?
변환 규칙 버전을 남기는가?
원천값을 다시 확인할 수 있는가?
기존 API 소비자가 영향을 받는가?
결측 사유가 보존되는가?
현재값과 과거값을 구분할 수 있는가?
변경을 되돌릴 수 있는가?

65장. 공개 데이터 체크리스트#

공개 단계에서는 다음을 함께 확인할 수 있습니다.

안정적인 식별자가 있는가?

자료 기준일이 있는가?

게시일과 기준일을 구분하는가?

코드표를 제공하는가?

단위를 제공하는가?

좌표계를 제공하는가?

결측값의 의미를 설명하는가?

갱신 주기를 밝히는가?

정정 문의 경로가 있는가?

변경 이력이 있는가?

적용 이용조건을 확인했는가?

제한 정보가 섞이지 않았는가?

CSV 파일이 열린다는 사실만으로 재사용 가능한 공공데이터가 되는 것은 아닙니다.

66장. 표준화에서 가장 위험한 세 가지 자동 변환#

첫 번째는:

빈 값
→ 0

입니다.

두 번째는:

미확인 코드
→ 가장 비슷한 코드

입니다.

세 번째는:

비슷한 주소
→ 동일 시설

입니다.

세 경우 모두 데이터 모양은 깔끔해집니다.

하지만 원래 없던 사실을 새로 만들어낼 수 있습니다.

67장. 좋은 표준화는 불확실성을 숨기지 않는다#

좋은 데이터는 모든 칸이 채워진 데이터와 같지 않습니다.

경우에 따라:

UNKNOWN

NOT_APPLICABLE

WITHHELD

NOT_COLLECTED

같은 값을 명확하게 표현하는 데이터가 더 좋은 데이터입니다.

이용자는 이런 상태를 바탕으로 자신의 분석에서 제외하거나 별도로 처리할 수 있습니다.

68장. 핵심 정리#

공공데이터 표준화에서 가장 중요한 원칙은 다음입니다.

같아 보이는 값을 같은 의미라고 가정하지 않는다.

A기관의:

와 B기관의:

가 모두 운영하지 않는 시설처럼 보여도 실제 의미는:

A 2
→ 휴업

B C
→ 폐업

일 수 있습니다.

이를 모두:

미운영

으로 합치면 값의 모양은 통일되지만 업무 의미는 사라집니다.

표준화는 다음 구조를 함께 관리해야 합니다.

원천 기관

원천 값

표준 값

변환 규칙

규칙 버전

유효기간

자료 기준일

주소 역시:

서울시
→ 서울특별시

처럼 표현을 정규화할 수 있지만 주소가 같다고 같은 시설이라고 단정해서는 안 됩니다.

시설 ID·운영기관·좌표·시설명·유효기간 같은 추가 근거가 필요할 수 있습니다.

결측값도 중요합니다.

NULL

하나로:

미수집

해당 없음

비공개

원천 오류

를 모두 표현하면 이용자는 값을 해석할 수 없습니다.

따라서 결측의 이유도 데이터로 관리하는 것이 좋습니다.

코드와 표준은 시간이 지나면서 바뀝니다.

같은 01이라도 2026년과 2027년의 의미가 다를 수 있습니다.

그래서 현재 코드표만 보관하는 것이 아니라:

valid_from

valid_to

mapping_version

같은 이력을 관리해야 과거 공개 파일을 당시 의미로 다시 해석할 수 있습니다.

또한 표준화 과정에서 원천값을 삭제하면 잘못된 매핑을 발견했을 때 되돌리기 어렵습니다.

표준화된 값과 원래 값을 함께 추적할 수 있어야 한다.

는 원칙이 중요합니다.

마지막으로 공공데이터의 품질은 파일 안의 값만으로 결정되지 않습니다.

자료 기준일

코드 정의

단위

결측 의미

좌표계

갱신 주기

정정 경로

변경 이력

이 함께 있어야 외부 이용자가 데이터를 올바르게 해석할 수 있습니다.

공공데이터 표준화의 최종 목표는 모든 기관이 똑같은 문자열을 사용하는 것이 아닙니다.

서로 다른 기관의 데이터를 합쳐도 같은 값은 같은 의미로 해석되고, 다른 의미는 구분되며, 변환된 결과를 원천까지 다시 추적할 수 있게 만드는 것입니다.

표준화가 성공했는지를 판단할 때도 가장 먼저 물어야 할 질문은 이것입니다.

표준 코드를 보고도 원래 데이터가 무엇을 뜻했는지 설명할 수 있는가?

그리고 하나를 더 확인해야 합니다.

몇 년 뒤 코드가 바뀌어도 오늘 공개한 자료를 오늘의 의미 그대로 다시 해석할 수 있는가?

이 두 가지가 가능해야 공공데이터 표준화가 단순한 형식 통일을 넘어 실제 데이터 거버넌스로 이어집니다.

공공데이터 표준화: 기관별 용어·코드·주소와 변경 이력 관리

1장. 열 이름은 같아졌는데 데이터의 뜻은 더 틀려졌다#

2장. 공공데이터 표준화는 이름을 통일하는 작업이 아니다#

3장. 같은 단어도 기관마다 다른 사건을 뜻할 수 있다#

4장. 이름보다 정의가 먼저다#

5장. 세 기관의 시설 데이터를 예제로 사용해 보자#

6장. 주소 문자열은 실체 식별자의 대체물이 아니다#

7장. 표준화는 네 가지 층으로 나눠 보면 이해하기 쉽다#

8장. 표준 용어는 단어가 아니라 개념을 정의한다#

9장. 표준 도메인은 값의 구조와 허용 범위를 정의한다#

10장. 문자열이라는 데이터 타입만으로는 부족하다#

11장. 표준 코드는 값과 의미를 함께 관리한다#

12장. 기관 A와 B의 코드를 매핑해 보자#

13장. 원천 기관까지 코드 키에 포함해야 한다#

14장. SQL로 기관별 코드 매핑을 해보자#

15장. 매핑되지 않은 값을 임의로 추측하지 않는 것이 중요하다#

16장. 모른다는 상태를 보존하는 것도 표준화다#

17장. NULL 하나에도 여러 이유가 숨어 있다#

18장. 결측 사유를 별도 코드로 관리할 수 있다#

19장. 결측 사유가 있어야 완전성 계산도 정확해진다#

20장. 빈칸을 0으로 바꾸면 새로운 사실을 만들어 버릴 수 있다#

21장. 코드의 현재 의미만 저장하면 과거 파일을 잘못 해석할 수 있다#

22장. 코드에는 유효기간이 필요하다#

23장. 현재 코드표로 과거 자료 전체를 다시 변환하면 위험하다#

24장. 변환 규칙도 버전 관리해야 한다#

25장. 원값을 버리면 잘못된 표준화를 되돌리기 어렵다#

26장. 표준값과 원천값을 함께 보존하는 것이 안전하다#

27장. 데이터 계보를 구조로 표현하면#

28장. 주소 표준화와 동일 시설 판정은 분리하자#

29장. 주소 정규화는 문자열 비교 정확도를 높일 뿐이다#

30장. 안정적인 시설 ID가 필요하다#

31장. 행 번호와 식별자는 다르다#

32장. 시설이 실제로 폐지되더라도 ID를 재사용하지 않는 편이 안전하다#

33장. 변경 유형까지 공개하면 파일 비교가 쉬워진다#

34장. 게시일과 데이터 기준일을 구분해야 한다#

35장. 원천 갱신일과 통합 반영일도 다를 수 있다#

36장. “최신 데이터”라는 표현은 어느 시간을 뜻하는지 밝혀야 한다#

37장. 코드 변경은 데이터베이스만 고치면 끝나는 일이 아니다#

38장. 코드 변경에는 호환 기간이 필요할 수 있다#

39장. 변경 관리 흐름을 그려보면#

40장. 데이터 소유자와 스튜어드의 역할은 다르다#

41장. 기술 담당자가 원천의 빈 주소를 추정해서 채우면 안 되는 이유#

42장. 표준화와 데이터 품질은 연결되어 있지만 같은 것은 아니다#

43장. 표준화를 했는데 미확인 비율이 증가할 수도 있다#

44장. 작은 샘플로 코드 변경을 먼저 시험하자#

45장. 매핑 커버리지도 품질 지표가 될 수 있다#

46장. 하지만 매핑률 100%가 의미 보존 100%는 아니다#

47장. 정보 손실은 역변환 가능성을 보면 발견하기 쉽다#

48장. 공개 CSV에는 값만 넣지 말고 해석 정보도 제공해야 한다#

49장. 좌표 데이터는 좌표계가 없으면 숫자 두 개에 불과하다#

50장. 숫자의 단위가 다르면 같은 컬럼으로 합치면 안 된다#

51장. 날짜에서도 기준 시간이 필요하다#

52장. 공개 자료의 법적 제공 여부는 데이터별로 확인해야 한다#

53장. “공공데이터니까 전부 공개 가능하다”는 판단은 위험하다#

54장. 이용 조건도 실제 데이터셋 기준으로 확인해야 한다#

55장. 제공 후 오류 신고 경로도 데이터 품질의 일부다#

56장. 정정하면 파일 버전도 바뀌어야 한다#

57장. 과거 공개 결과를 재현할 수 있어야 한다#

58장. 공개 데이터에는 두 종류의 이력이 필요할 수 있다#

실제 세계의 변화#

데이터 오류의 정정#

59장. 유효시간과 시스템시간을 구분하면 변경을 더 정확히 설명할 수 있다#

60장. 공공데이터 표준화 전체 구조를 보면#

61장. 표준화 품질을 측정하는 지표#

62장. 공개 데이터 100건을 점검하는 예#

63장. 중복 시설 후보와 실제 동일 시설도 구분해야 한다#

64장. 표준화 변경 전 검증할 질문#

65장. 공개 데이터 체크리스트#

66장. 표준화에서 가장 위험한 세 가지 자동 변환#

67장. 좋은 표준화는 불확실성을 숨기지 않는다#

68장. 핵심 정리#

이 페이지의 목차