공공데이터를 지도에 올리기 전, 빠진 행부터 확인하기

원본과 배포 파일 사이를 따라가기

2026년 11월 4일 바쿠오 로컬 프로젝트의 scripts/build-dataset.mjs를 확인한 기록입니다. 이 글에서 확인한 것은 소스의 처리 과정이며, 공개 서비스가 같은 소스와 데이터를 배포하고 있는지까지 확인한 결과는 아닙니다.

빌더는 지오코딩 결과 파일을 읽고 필수 필드, 업종·주소 조건, 좌표 범위를 검사한 뒤 언어별 JSON을 만듭니다. 검사를 통과하지 못한 행은 다음 단계로 넘어가지 않습니다. 따라서 완성된 JSON만 보면 어떤 매장이 어떤 이유로 빠졌는지 알기 어렵습니다. 원본 파일과 최종 파일을 함께 보아야 하는 이유입니다.

제외 조건은 데이터의 의미를 바꾼다

이 빌더의 isRoadShop()은 온라인 사업자나 호텔·여행사 등으로 추정되는 이름과 주소를 제외합니다. 이는 방문 가능한 일반 매장을 추리는 편집 규칙입니다. 공식적인 영업 상태 확인이나 폐업 판정을 수행한 것과는 다릅니다.

문자열 규칙은 빠르게 적용할 수 있지만 정상 매장을 제외할 수도 있습니다. 도입 전에 실제 제외 행을 표본으로 읽고, 어떤 유형을 목록에 담으려는지 설명해야 합니다. 등록 목록의 전체 건수를 서비스에 표시되는 매장 수와 같은 것으로 소개해서도 안 됩니다.

좌표를 숫자로 바꾸기 전에 빈값부터 검사하기

자바스크립트의 Number('')와 Number(null)은 0입니다. 숫자 변환에 성공했다는 사실만으로 좌표가 있다는 뜻은 아닙니다. 아래 예제는 설명용 가상 행을 검사하며 바쿠오의 실제 빌더 코드를 복제한 것이 아닙니다. Node.js나 브라우저 콘솔에 붙여 실행할 수 있습니다.

function inspect(row) {
  if (row === null || typeof row !== 'object' || Array.isArray(row)) return 'INVALID_ROW';
  if (typeof row.name !== 'string' || !row.name.trim()) return 'MISSING_NAME';
  if (typeof row.address !== 'string' || !row.address.trim()) return 'MISSING_ADDRESS';
  for (const key of ['lat', 'lng']) {
    const value = row[key];
    if (value === null || value === undefined ||
        (typeof value !== 'number' && typeof value !== 'string') ||
        (typeof value === 'string' && !value.trim()) ||
        !Number.isFinite(Number(value))) return 'INVALID_COORDINATE';
  }
  const lat = Number(row.lat), lng = Number(row.lng);
  return lat >= -90 && lat <= 90 && lng >= -180 && lng <= 180
    ? 'CHECK_ADDRESS_MATCH' : 'OUT_OF_RANGE';
}
console.log(inspect(null));
console.log(inspect([]));
console.log(inspect({name: 'Example shop', address: 'Example address', lat: '', lng: 127}));
console.log(inspect({name: 'Example shop', address: 'Example address', lat: 37, lng: 127}));

출력은 차례로 INVALID_ROW, INVALID_ROW, INVALID_COORDINATE, CHECK_ADDRESS_MATCH입니다. null과 배열은 행 객체가 아니므로 먼저 거부합니다. 마지막 결과도 주소 검증 완료라는 뜻은 아닙니다. 값이 비어 있지 않고 지구 좌표 범위에 있다는 것까지만 통과했습니다. 문자열은 원본 형식을 보존한 뒤 필요한 필드에만 변환을 적용하는 편이 원인을 추적하기 쉽습니다.

경계 안에 있는 점도 틀릴 수 있다

확인한 빌더에는 한국 주변을 대상으로 정한 사각 범위 검사가 있습니다. 이는 위도·경도 뒤바뀜이나 멀리 떨어진 좌표를 찾는 1차 검사에 도움이 됩니다. 국경선 판정이나 건물 위치 확인을 대신하지는 않습니다.

주소가 서울인데 좌표가 부산에 있어도 사각 범위에는 들어갈 수 있습니다. 이런 경우 원본 주소, 지오코딩 응답, 지도 표시 위치를 대조해야 합니다. 반올림한 좌표의 소수 자릿수도 위치 정확도를 보장하지 않습니다. 원본 측정과 주소 해석의 오차가 먼저 영향을 줍니다.

갱신할 때 확인할 결과물

원본 파일의 제공 기관·게시일·이용 조건을 기록하고 원본을 보존합니다.
통과·제외·검토 보류 행을 이유와 함께 나눠 확인합니다. 제외 건수가 바뀌면 규칙 변경과 원본 변경을 구분합니다.
같은 등록 식별자가 중복되었는지, 서로 다른 매장이 같은 주소를 쓰는지 확인합니다. 주소만으로 합치지 않습니다.
결과 JSON의 필수 필드와 언어별 ID 대응을 확인하고, 지도에서 대표 행을 직접 대조합니다.

이 절차는 현재 빌더가 전부 구현하고 있다는 설명이 아니라 배포 검토 때 사용할 확인 목록입니다. 문자 정리에는 Unicode 정규화도 쓸 수 있지만 원본의 오타나 잘못된 주소를 자동으로 해결해 주지는 않습니다. 관련 위치 검토는 주소와 좌표계 글에서 이어집니다.

바쿠오 · 사용 안내 →