시리즈: 공공데이터에서 영업 시그널을 자동으로 발굴하기까지, 9편 읽기
"같은 데이터"라는 환상
30개 사이트에서 데이터를 가져오면, 30개의 다른 포맷이 온다. 이걸 "하나의 테이블"에 넣으려면 통일이 필요한데, 이 통일 작업이 상상 이상으로 골치가 아프다.
"데이터 포매팅이 그렇게 어려운가?"라고 물을 수 있다. 대답은 "각각은 쉽다. 하지만 82개를 동시에 하면 지옥이다."
기관명 하나 통일하는 데 82가지 변환 규칙
가장 기본적인 것부터 보자. "이 공고를 어느 기관이 냈는가."
각 사이트는 자기 기관을 다르게 부른다. 예를 들어 과학기술정보통신부만 해도:
- "과기정통부" (공식 약칭)
- "과기부" (흔히 쓰는 약칭)
- "과학기술정보통신부" (전체 이름)
- "MSIT" (영문 약칭)
- "미래창조과학부" (예전 이름)
이 다섯이 다 같은 기관이다. 82개 기관에 이런 변형이 각각 있다. 매핑 테이블만 수백 항목이다.
거기에 산하 기관까지 더해진다. "과기정통부 소프트웨어정책관"이 "과기부"에 속하는지, "정보통신정책연구원"이 어느 부처 산하인지. 이런 계층 관계까지 정리해야 한다.
날짜: 13가지 패턴을 하나로
앞에서도 다루지만, 날짜 통일 문제를 좀 더 구체적으로 보자.
실제로 처리해야 했던 패턴들
2026.03.052026-03-052026년 3월 5일26/03/053. 5.Mar 05, 2026202603052026년 03월 05일(수)
하나의 파서가 이 모든 걸 인식해야 한다. 그리고 이건 날짜 필드가 있는 경우의 이야기다. 날짜가 본문에 파묻혀 있는 경우, 아예 없는 경우는 또 다른 전략이 필요하다.
날짜가 없으면? 폴백 체인을 쓴다. 제목에서 추출 시도 → 게시물 ID에서 시간 정보 추정 → 최초 수집 시점을 대체값으로 사용. "정확한 날짜를 모르더라도 대략적인 시점은 알아야 한다"는 원칙.
URL: 간단해 보이지만 지뢰밭
"각 공고의 URL을 저장한다", 이 단순한 작업도 함정이 있다.
어떤 사이트는 상세 페이지 URL이 깨끗하다. https://example.go.kr/board/view/12345 같은 식.
하지만 어떤 사이트는 URL이 본문이 아니라 목록 페이지를 가리킨다. 개별 공고의 URL이 아니라 게시판 첫 페이지 URL이 저장되는 것. 실제로 특정 기관의 경우 고유 URL 비율이 5%에 불과했다. 100건의 데이터가 사실상 같은 URL을 가리키고 있었다는 뜻.
또 어떤 사이트는 JavaScript로 상세 페이지를 만들어서 URL이 상세 내용을 반영하지 않는다. 서버에서 URL에 서명을 붙여야만 접근 가능한 사이트도 있다. URL을 저장해도 나중에 다시 열릴 수 없는 경우.
콘텐츠 정규화: 본문을 "깨끗하게" 만드는 작업
각 사이트에서 가져온 본문 HTML은 용도에 따라 정제가 필요하다.
- 네비게이션 메뉴, 홈바, 푸터 등 비콘텐츠 영역 제거
- 인라인 스타일, 스크립트 태그 제거
- 인코딩 통일 (EUC-KR, ISO-8859-1 → UTF-8)
- 공백 정규화 (연속 공백, 줄바꿈 정리)
여기서도 폴백 전략이 필요하다. 메인 치환 로직으로 본문을 못 뽑으면, body 태그에서 네비게이션·헤더·푸터를 빼고 나머지를 본문으로 취급하는 식. 완벽하지는 않지만 아예 없는 것보다는 낫다.
왜 이게 간단하지 않은가
하나하나는 단순한 문제다. 기관명 매핑, 날짜 파싱, URL 검증, HTML 정제. 각각은 주니어 개발자도 할 수 있는 수준이다.
하지만 82개 기관 × 5가지 데이터 유형 × 소스별 예외 케이스를 곱하면, 조합의 수가 폭발적으로 늘어난다. 개별 문제의 난이도가 아니라 조합의 복잡도가 진짜 난관이다.
그리고 이 통일이 깨지면 후속 분석이 전부 무너진다. 날짜가 틀리면 타임라인 분석이 안 되고, 기관명이 통일되지 않으면 교차 연결이 안 되고, URL이 잘못되면 원본을 확인할 수 없다. 데이터 통일은 모든 후속 가치의 기반이다.
다음 에피소드에서는 이 일을 사람 손으로 할 수 있는지에 대해 이야기한다.
