공공데이터 5가지 함정

공공데이터는 무료로 공개되어 있고 출처도 명확합니다. 그래서 처음에는 내려받아서 바로 쓰면 될 것 같습니다. 그런데 실제로 열어보면 예상과 다른 지점에서 막힙니다.

데이터가 잘못된 것은 아닙니다. 여러 기관이 각자의 업무 기준으로 관리하던 정보를 개방한 것이라, 하나의 통일된 규격으로 정리되어 있지 않을 뿐입니다. 이 성격을 모르고 접근하면 원인을 찾는 데 시간을 많이 씁니다.

공공데이터를 다루면서 반복적으로 만나게 되는 문제 다섯 가지와 대응 방법을 정리했습니다.

1. 좌표계가 데이터마다 다릅니다

증상 — 위도·경도 컬럼이 있길래 지도에 찍었는데 엉뚱한 곳에 표시되거나, 값이 37.5가 아니라 195832.4 같은 큰 숫자로 들어 있습니다.

원인 — 국내 공공데이터는 여러 좌표계를 혼용합니다. 대표적으로 다음과 같습니다.

좌표계	특징
EPSG:4326 (WGS84)	위경도. 우리가 아는 37.xx, 127.xx 형태
EPSG:5179 (UTM-K)	미터 단위. 국내 지도 서비스에서 많이 쓰임
EPSG:5186 (중부원점)	미터 단위. 지적·행정 자료에서 자주 등장

대응 — 값의 자릿수로 먼저 판별합니다. 소수점 앞이 두 자리면 위경도, 여섯 자리 이상이면 미터 단위 투영좌표입니다. 어느 쪽인지 확인한 뒤 변환해서 쓰면 됩니다. 파이썬이라면 pyproj로 변환할 수 있습니다.

기술문서에 좌표계가 명시되지 않은 경우도 있는데, 이럴 때는 값을 알고 있는 지점(예: 시청 주소)과 대조해 역산하는 방법이 확실합니다.

2. 인코딩이 UTF-8이 아닙니다

증상 — CSV를 열었더니 한글이 전부 깨져서 보입니다. 코드에서 읽으면 UnicodeDecodeError가 납니다.

원인 — 상당수의 공공데이터 파일이 EUC-KR 또는 CP949로 저장되어 있습니다. 행정 업무에서 오랫동안 쓰인 인코딩이기 때문입니다. 반면 대부분의 프로그램은 UTF-8을 기본값으로 가정합니다.

대응 — 파일을 읽을 때 인코딩을 명시합니다. cp949로 먼저 시도하고, 실패하면 utf-8로 재시도하는 방식이 무난합니다. utf-8-sig도 함께 고려해야 합니다. 앞에 BOM이 붙어 있으면 첫 번째 컬럼명에 보이지 않는 문자가 섞여서, 컬럼을 찾지 못하는 문제가 생깁니다.

API로 받는 경우에도 응답 헤더의 인코딩과 실제 본문이 다른 경우가 있으므로, 한글이 깨지면 인코딩부터 의심하는 편이 빠릅니다.

3. 운영시간과 휴관일이 자유 텍스트입니다

증상 — 운영시간 컬럼을 파싱하려고 했는데 값이 제각각입니다. 09:00~18:00, 09시~18시, 평일 9-18(동절기 17시까지), 상시개방, - 같은 값이 한 컬럼에 섞여 있습니다.

원인 — 이 항목들은 사람이 읽을 것을 전제로 입력됩니다. 기관 담당자가 자유롭게 작성하다 보니 형식이 통일되지 않습니다. 휴관일도 마찬가지여서 매주 월요일, 월, 매월 첫째·셋째 월요일, 연중무휴가 함께 존재합니다.

대응 — 완벽한 파싱을 목표로 하면 끝이 없습니다. 이 값이 실제 운영과 어긋나는 이유는 개방 시설 쪽 사례에서 더 구체적으로 다뤘습니다. 현실적인 방법은 다음과 같습니다.

• 자주 등장하는 패턴 몇 가지만 정규식으로 처리한다
• 파싱에 실패한 값은 원문 그대로 보존해서 함께 보여준다
• 정규화된 값과 원문을 별도 컬럼으로 나눠 저장한다

원문을 버리지 않는 것이 중요합니다. 파싱 결과가 틀렸을 때 되돌아갈 근거가 남기 때문입니다.

4. 폐업과 변경이 늦게 반영됩니다

증상 — 데이터에는 정상 영업 중으로 되어 있는데 실제로는 문을 닫은 곳이 나옵니다. 반대로 새로 생긴 곳이 데이터에 없기도 합니다.

원인 — 데이터의 갱신 주기와 현실의 변화 속도가 다릅니다. 폐업 신고가 접수되고, 그것이 시스템에 반영되고, 개방 데이터로 다시 배포되기까지 여러 단계를 거칩니다. 기관에 따라 이 주기가 일 단위이기도 하고 월 단위이기도 합니다.

대응 — 데이터의 기준일을 반드시 함께 표시합니다. 이용자가 정보의 시점을 알 수 있어야 판단할 수 있기 때문입니다.

또한 데이터를 최종 답이 아니라 후보를 좁히는 도구로 위치시키는 것이 맞습니다. 최종 확인은 해당 기관이나 시설의 공식 안내에서 하도록 안내하는 편이 정확합니다.

5. 식별자가 안정적이지 않습니다

증상 — 지난달 데이터와 이번 달 데이터를 비교했더니 같은 시설의 관리번호가 달라져 있거나, 같은 시설이 이름만 조금 다르게 두 건으로 존재합니다.

원인 — 관리번호가 기관 내부 업무 기준으로 부여되는 경우, 데이터 재생성 과정에서 값이 바뀔 수 있습니다. 또 지점이 여러 개인 시설이나 이름이 변경된 시설은 중복으로 남기도 합니다.

대응 — 제공된 관리번호만으로 이력을 추적하지 않는 것이 안전합니다. 이름, 주소, 좌표를 조합한 자체 식별 키를 만들어 두면 갱신 시 대조가 가능합니다.

주소 역시 표기가 흔들리므로(도로명과 지번 혼용, 공백과 괄호 차이) 비교 전에 정규화가 필요합니다.

결함이 아니라 성격입니다

다섯 가지 모두 데이터가 잘못 만들어진 결과라기보다 어떻게 만들어졌는지가 드러난 것에 가깝습니다. 여러 기관이 각자의 업무를 처리하려고 쌓아온 기록을 개방한 것이므로, 하나의 서비스처럼 정돈되어 있으리라 기대하면 어긋납니다.

이 전제를 받아들이면 대응도 달라집니다. 데이터를 고쳐 쓰려 하기보다, 어떤 성격의 값이 들어오는지 먼저 확인하고 그에 맞춰 쓰는 쪽으로 순서가 바뀝니다.

새 파일을 열었을 때 첫 5분

위 다섯 가지는 나중에 발견할수록 손해가 커집니다. 지도에 다 찍고 나서 좌표계가 다른 걸 알면 처음부터 다시 해야 합니다. 그래서 파일을 받자마자 순서대로 확인하는 습관이 결국 시간을 아낍니다.

새 데이터를 열면 이 순서로 봅니다.

1. 한글이 깨지는지 먼저 봅니다. 깨져 있으면 파일을 다시 받을 게 아니라 cp949로 읽습니다. 파일이 잘못 받아진 것이 아니라 저장된 인코딩이 다른 것입니다.
2. 좌표 열의 자릿수를 봅니다. 소수점 앞이 두 자리면 위경도, 여섯 자리를 넘어가면 평면 직각좌표 쪽입니다. 애매하면 위치를 아는 지점 하나를 찍어보면 바로 갈립니다. 기술문서에 적혀 있는 경우도 많으니 먼저 보는 편이 빠릅니다.
3. 운영시간·휴관일 같은 자유 텍스트 열에서 서로 다른 값이 몇 종류나 나오는지 셉니다. 종류가 수십 가지면 파싱으로 해결할 생각을 접고 원문을 그대로 보여주는 쪽으로 설계를 바꿉니다.
4. 기준일 열이 있는지 확인하고, 없으면 내려받은 날짜를 파일 이름에 박아둡니다. 나중에 두 파일을 비교할 때 이 한 줄이 있고 없고가 갈립니다.
5. 행을 다시 찾을 수 있는 키가 있는지 봅니다. 없으면 기관명과 시설명을 합쳐 직접 만들어 둡니다.

다섯 가지를 확인하는 데 5분이면 충분하고, 이 5분을 건너뛰면 대개 반나절을 되돌립니다.

값 자체가 실제와 다른 경우는 여기서 해결되지 않습니다. 폐업한 곳이 남아 있거나 주소가 틀린 것은 제공 기관이 고쳐야 하는 문제이고, 알리는 경로가 따로 있습니다. 그 절차는 이 블로그의 오류 신고 편에서 다뤘습니다.

---

다섯 가지 항목은 공공데이터포털(data.go.kr)의 이용가이드와 각 데이터의 기술문서를 참고하되, 실제로 파일을 열어 겪은 순서대로 정리했습니다. 좌표계 구분은 국토지리정보원의 좌표계 안내를 따랐고 2026년 8월 기준입니다.
같은 함정이라도 기관마다 정도가 다릅니다. 여기 적은 것은 여러 데이터에서 공통으로 반복된 것들입니다.