장면 1
우리나라 정부가 생산 관리하는 데이터를 공개하는 곳인 공공데이터 포털
- 동일한 제목의 자료를, 올린 지자체도 있고, 안올린 곳도 있다.
- CSV, Excel, XML 등 포맷이 제각기.
- 동일한 자료에 대해서도 데이터 제작 주체에 따라 구조가 달라지기도 한다.
- 예를 들어 열의 갯수가 모두 다른 경우
- 열로 분리, 콤마로 분리, 분리 안한 것 등등
*참고 : 영국의 경우 www(월드와이드웹)의 창시자 팀버너스리 경(Sir Tim berners-Lee)이 주도하는 ODI(Open Data Institute)와 공동으로, XML 기반으로 데이터 공유
장면 2
국가 공간정보를 공개하는 국가공간정보포털. (사례 : 버스노선)
- 지도데이터는 존재하지 않고, "공간정보목록정보"에만 존재
- 목록에 존재하는 지자체는 21개. (군산시는 버스노선마다 따로따로 올려서 51개)
- 데이터의 내용 및 구조에 관한 정보가 없는 경우 많음(예: 버스노선)
- 고유주소 없음(예 : 동두천시를 검색한 주소를 복사한후 새창에 붙이면 동작하지 않음
- "국가공간정보포털개방목록"에 BRM 분류가 있으나, 막상 클릭하면 아무것도 없는 항목 다수
- 지방자치단체에서 작성한 데이터는 거의 없는 듯
장면 3
지방자치단체간 데이터 교환
- A 지자체에서 인접한 B 지자체에 도로데이터 요청한다.
- B 지자체는 A 지자체에서 요청하는 포맷으로 변환하여 전송한다.
- A 지자체는 B 지자체의 데이터를 받은 후 그냥 사용할 수 없다. 왜그럴까?
도입
우리나라에서 데이터 교환 또는 유통체계에서 벌어지는 사례를 몇 가지 들었습니다. 공공데이터 포털에서 제공되는 데이터는, 공간정보보다 훨씬 간단한 text 정보임에도 제대로 공개/유통되지 못하고 있다고 많은 사람들이 지적하고 있습니다. 이걸 생각해보면 이보다 훨씬 구조가 복잡한 공간정보에 대한 유통 체계가 문제가 있는 것은 어쩌면 당연할 수도 있습니다.
정보공개/데이터 유통과 관련된 모든 문제는 데이터 유통체계가 미비하기 때문에 발생하는 것입니다. 유통체계가 뭐가 잘못된 것인지를 말하는 대신, 데이터 유통체계가 완벽하게 이루어지면 어떻게 데이터공개/교환/유통이 이루어질 수 있는지를 생각해 보겠습니다.
1. 개인정보보호, 보안 등 현행법에 저촉되지 않는 모든 데이터가 공개된다.
2. 모든 공개된 데이터의 상세한 내용및 구조가 별도의 데이터로서 공개된다.
3. 동일한 이름의 데이터에는 내용과 구조가 완전히 동일하다.
4. Machine Readable 한 포맷으로 공개된다.
5. 공개된 데이터의 구조도 함께 공개되며, 이 구조를 사용하여 자동 검증이 가능하다.
6. 이미 공개된 데이터가 일부 수정된 경우, 수정된 부분에 대해서 즉시 공개된다.
7. 공개된 데이터는 관련자에게 즉시 통지(notification)된다.
8. 해당 데이터의 사용자/기관은 (사람이 개입하지 않고) 자동으로 갱신된 데이터를 읽어오고,
이 데이터를 사용하여 자신의 데이터를 자동으로 수정한다.
대략 이렇게 정리할 수 있을 것 같습니다. 즉, 데이터를 어느 사이트에 올려 놓는다고 하여 유통이 되는 것이 아니라, 이런 식으로 기계간 통신(Machine to Machine)으로, 사람이 개입하지 않고 자동으로 처리될 수 있어야만 "궁극적"으로 데이터 유통이 된다고 할 수 있습니다. 이렇게만 되면, 어느 생산자든 데이터를 수정하면 그 데이터를 사용하는 사람의 데이터도 자동 수정되어, 결국 "실시간 갱신" 시스템이 완성될 수 있을 것입니다.
이러한 체계를 갖추기는 물론 매우 어렵습니다. 하지만, 불가능한 것은 아닙니다. 데이터 공급자의 의지와 노력 (+ 제도적 뒷받침), 그리고 공간정보 표준을 준수하면 이러한 체계를 갖출 수 있습니다. 그중에서 오늘 제가 할 이야기는 공간정보 표준, 그중에서도 유통과 밀접한 관련이 있는 "데이터의 내용과 구조"에 대한 내용입니다.
데이터의 내용과 구조(응용스키마)
"데이터의 내용 및 구조"를 이야기하면 보통 데이터 교환 포맷을 떠올립니다. 텍스트 위주의 DB라면 CSV나 XML 등이 교환포맷으로 많이 사용됩니다. Excel 파일로 올리는 곳도 많지만요. 공간정보 DB는 Shape 파일이나 GML 등의 포맷이 많이 이용됩니다. 물론 아직 DXF를 선호하는 분들도 있고요. 사실 데이터 포맷 자체는 큰 문제가 아닙니다. 한글파일이나 스캐닝한 영상을 올리지만 않고, 적절한 구조를 지원만 한다면 어떤 포맷을 사용해도 데이터 교환에는 그다지 큰 문제는 없습니다. 즉, (정확한 내용 및 구조를 가지고 있다면) 데이터 교환에 어떤 포맷을 사용해도 문제는 없다는 뜻입니다. 널리 알려지지 않은 포맷이라면 불편함이 더 많아질 뿐입니다.
하지만, 현재 국가공간정보포털에 올려진 파일은, 공각정보분야에서 일하는 사람이라면 누구나 잘 알고 있는 Shape 포맷으로 올려져 있는데, 왜 바로 가져다 쓸 수 없을까요? 그것이 바로 "데이터의 내용 및 구조"에 관한 문제입니다.
이종 시스템 간의 상호 작용을 성취하기 위해서는 두 가지 근본 문제가 결정되어야 한다. 첫 번째 문제는 공간 데이터의 내용의 의미와 논리적 구조를 정의하는 것이다. 이것은 응용 스키마에서 이루어져야 한다. 두 번째 문제는 응용 스키마와 관련된 데이터를 표현할 수 있으며, 시스템과 플랫폼 독립적인 데이터 구조를 정의하는 것이다."
이 글은 "KSXISO 19118 지리정보 - 인코딩" 표준의 6절에 있는 내용입니다. 이종 시스템간의 데이터 교환을 위해서는 첫번째 "공간데이터의 내용 및 구조" 정의, 두번째 "데이터 포맷" 정의가 필요하다는 뜻입니다.
데이터 포맷은 위에서 언급한 것처럼, 사실 데이터 교환에 참여하는 자들끼리 동일한 포맷을 사용한다면 큰 문제가 아니라고 말씀드렸습니다. 하지만, "데이터의 내용 및 구조"는 완전히 다른 문제입니다. 예를 들어 두개의 기관에서 도로데이터를 각각 다음과 같이 정의하였다고 해보겠습니다.
A 지자체(좌측)은 모든 도로를 하나의 "Road" 클래스로 분류하고, 5가지 속성을 갖는 것으로 정의했습니다.(이중 두개의 속성은 도형정보입니다.) B 지자체는 추상클래스인 Road 를 MainRoad 클래스와 AuxRoad 클래스가 상속받도록 정의했습니다. 물론 MainRoad와 AuxRoad는 구조가 다릅니다. 도로중심선(CenterLine)은 A 지자체에서만 정의하였고, 속성들이 서로 조금씩 다른 것도 있고 아얘 빠진 것들도 있습니다. (가상이니 심각하게 받아들이지 마시길...)
A 지자체에서 B 지자체에게 도로 데이터를 Shape 포맷으로 요청하면 어떻게 될까요. 당연히 B 지자체는 자신의 현재 구조 그대로 Shape 포맷으로 변환해서 넘겨줄 것입니다. 이 데이터를 받은 A 지자체는 다음과 같은 처리가 필요할 것입니다.
- B 지자체에서는 MainRoad와 AuxRoad로 분리되어 있는 클래스를 Road 클래스로 합쳐야 합니다.
- RoadCover 는 RoadSurface와 동일하므로 클래스명만 수정합니다.
- CenterLine은 존재하지 않으므로 RoadSurface를 사용하여 자동 생성합니다.
- DateOpen는 MainRoad에만 있으므로, AuxRoad 클래스는 임의의 날짜를 부여합니다.
- Name은 동일하므로 그대로 가져옵니다.
- Admin 도 DateOpen 과 동일한 방식으로 처리합니다.
결국 데이터는 넘겨받았지만, 모든 클래스들을 일일이 검사하고, 수정을 거쳐야만 사용할 수 있게 됩니다. 새로 처음부터 만드는 것보다야 훨씬 편하지만, 엄청 많은 수고가 필요합니다. 넘겨받을 클래스의 수가 많을 수록 더 많은 노력이 필요하겠죠.
U 라는 사업체가 있어서 이들 도로데이터를 가져와서 사용하는 경우엔 어떨까요? 먼저 A 지자체에서 데이터를 받아와 데이터를 불러들이는 프로그램을 짰습니다. 이제 B 지자체에서 데이터를 받아오면 새로 프로그램을 짜야 합니다. 또다른 데이터를 받아오면? 또다시 새로운 프로그램을 짜야죠. 이처럼 모든 기관별로 응용스키마가 조금씩 다르기 때문에 매번 조금씩 달리 편집해서 사용해야 합니다. 물론 데이터를 제공해준다는 가정하에요. 예전에 내비게이션용 도로지도를 제작하던 어떤 업체 관계자는, 매 지자체별로 별도로 접촉해서 자료를 얻어야 했는데 공개하지 않는다는 곳도 많았지만, 기껏 공개를 해도 이처럼 많은 편집/가공이 필요하다고 푸념했던 기억이 납니다.
이처럼 현재 공개된 자료들은 모두 사용하려는 사람들이 구조를 일일이 검사하고, 변환하는 프로시져를 만들고, 테스트하는 과정을 걸쳐야만 사용할 수 있습니다. 심지어는 텍스트 정보만 제공되는 공공데이터 포털도 마찬가지입니다. 어떤 한 기관에서 제공하는 자료라면 그나마 다행이지만, 여러 기관의 데이터를 취합해야 하는 경우 정말 많은 자원이 소요됩니다. 게다가 담당자가 바뀌거나, 시스템이 변경되면 모든 과정을 새로 밟아야 합니다.
관리기관별로 데이터 내용 및 구조(응용스키마)가 다른 이유는 자신의 목적에 따라 시스템을 구축하기 때문입니다. 처음 측량을 통해 생산한 원시데이터는 동일하더라도, 시스템을 구축할 때는 내부의 목적, 사용하는 하드웨어/소프트웨어의 종류 등에 따라 달라질 수 밖에 없습니다. 응용스키마가 원래 그런 성격이니까요.
공통 응용스키마
그럼 이처럼 데이터 생산/관리 기관별로 구조가 다른 상태에서 어떻게 데이터를 교환해야 할까요? 이것이 "KSXISO 19118 지리정보 - 인코딩" 표준에서 다루는 문제입니다. 아래는 이 표준의 그림 1 "두 시스템간의 데이터 교환의 개요"입니다.
이 그림을 간단하게 설명하면, 다음과 같습니다.
1. 다수의 시스템에 대하여 공통 응용스키마 I 를 정의해야 한다.
2. 내부 DB는 이 공통 응용스키마를 적용한 임시 내부 데이터베이스 M_AI 를 생성한다.
3. 이 표준에 따른 인코딩 서비스 R을 사용하여 자료를 공통포맷으로 변환한다.
4. 이렇게 만들어진 파일/스트림을 상대측에 전송한다.
즉, 자산의 내부 DB를 그냥 변환하는 것이 아니라, 공통 응용스키마를 적용하고, 공통 포맷을 적용하여 변환해야 한다는 것입니다. 물론 읽어들일 때는 이 반대의 수순을 밟으면 되고요.
여기에서 볼 수 있는 것처럼, 데이터 공유에 있어 가장 중요한 것은 데이터 공개/유통에 참여하는 모든 참여자가 공유하는 "공통 응용스키마"입니다. 공통 응용스키마를 사용하고 그것이 정확하게 지켜지기만 한다면, 어떤 포맷을 사용해도 문제없이 데이터를 공유할 수 있습니다.
XML 인코딩
그런데, KSXISO 19000 표준군에서는 모든 종류의 공간정보 교환에 XML 포맷으로 인코딩 할 것을 권장하고 있습니다. KSXISO 19118 인코딩에서는 데이터를 XML로 변환하는 규칙을 제시하고 있고, KSXISO 19136 지리마크업언어(GML)에서는 이 XML 변환규칙을 보다 정확하게 규정하고 있으며, KSX1SO 19139 메타데이터 XML 구현에서는 메타데이터를 XML 로 변환하고 공유하는 규칙을 다루고 있습니다. 즉, 데이터 교환은 가능한한 XML 을 이용하라는 것입니다.
그런데 XML(또는 GML)은 데이터 그 자체일 뿐입니다. XML을 사용한다고 하여 데이터 교환이 순조롭게 이루어질 수 없습니다. 데이터의 내용 및 구조(응용스키마)의 공유, 준수가 필수적으로 뒤따라야 합니다.
XML 스키마는 XSD(XML Schema definition)로 정의됩니다. XSD는 말그대로 XML 파일의 스키마를 정의하는 문법입니다. 일반 XML 파일은 <tag1> </tag1> 등과 같은 형태로 태그만 맞춰주면 어떠한 데이터도 추가할 수 있으습니다. 그러나, XSD를 정의하면 XSD에 정의되어 있는 항목외에는 들어갈 수 없고, XML에 XSD 정의항목이 빠졌다면 오류가 발생하게 됩니다. 즉, XML 과 XSD는 쌍으로 움직이고, 일정한 내용과 구조를 갖출 수 있게 됩니다.
이와 같이 XML 은 XSD가 존재하기 때문에 데이터와 응용스키마를 함께 공개/교환 할 수 있습니다. Shape 등 다른 포맷은 응용스키마를 일치시킨다고 해도, 해당 데이터가 응용스키마에 일치하는지 여부는 별도의 어플리케이션을 작성해야만 검증할 수 있습니다. 하지만, XSD+XML은 이 자체만으로 데이터 구조의 일관성을 유지할 수 있습니다.
19118 인코딩 표준에서는 UML로 작성된 응용스키마를 XSD로 변환하는 규칙도 제공합니다. 다음 그림은 이 표준의 "그림 C.1 - XML 기반의 변환규칙" 입니다.(일부 수정) 이 그림에서 말하는 것은, 공간정보 응용스키마는 XSD로 인코딩하고, 공간데이터(응용데이터)는 이 XSD를 기준으로 XML(GML) 로 변환한 후, 이 두개의 파일을 모두 제공하라는 것입니다. 이것이 ISO 표준에 따르는 것이죠.
따라서, 국가공간정보포털과 같은 데이터 교환장소에는 데이터를 GML(XML) 포맷으로 제공하는 외에도 다음과 같은 응용스키마 관련 정보를 함께 제공해야 합니다. 이중 위의 두가지는 사람들이 편하게 이해하기 위한 용도이고, 마지막 XSD는 컴퓨터가 직접 해석하기 위한 용도입니다. (이 이외에도 메타데이터에 관한 내용도 XML로 제공해야 하지만, 이는 생략합니다.)
- 응용스키마 (UML)
- 데이터딕셔너리 - 응용스키마 객체의 상세 해설
- XSD - XML 용 스키마
기존 공간정보를 다루는 입장에서 볼 때, Shape 파일 등이 널리 사용되고 있으므로, 이런 포맷을 사용하는 것이 더 낫다는 의견도 있을 수 있습니다. 하지만, XML 포맷을 사용하면 다음과 같은 장점이 있어서, 단순한 Shape 파일보다 월등한 편의성을 누릴 수 있습니다.
- XML 포맷은 사람들도 어렵지 않게 읽을 수 있지만, 무엇보다 컴퓨터 처리에 좋다.
- XML을 처리하기 위한 다양한 라이브러리가 존재하기 때문에(오픈 소스도 다수 존재함)
GIS 소프트웨어를 사용하지 않아도 일관성 검증이나 통계 등 간단한 데이터 처리가 가능하다.
- XML Validator
- XML DOM Parser
- XML 은 W3C에서 정의한 정보 교환/처리를 위한 표준으로 Web/IT 분야에 널리 사용되고 있으며,
특히 공간정보를 모르는 사람들도 장벽없이 처리할 수 있다.
- XML 파일의 스키마(구조)를 정확하게 정의하는 XSD (XML Schema Defintion)를 함께 제공하면,
데이터 구조의 검증이 아주 쉬워진다. 즉, 일관된 구조가 100% 유지할 수 있다.
이러한 장점이 있기 때문에, 데이터 공개/교환은 XML(GML)을 사용해야 한다는 것이 제 생각입니다. 아니 다른 포맷으로는 이러한 장점을 대체할 수 없으므로, 반드시 XML(GML)을 사용해야 합니다.
결론
이제 마무리를 지어야 할 때가 왔습니다. 제가 처음에 언급했던 "완벽한 데이터 유통체계"에 대해 다시 생각해보겠습니다.
1. 개인정보보호, 보안 등 현행법에 저촉되지 않는 모든 데이터가 공개된다.
2. 모든 공개된 데이터의 상세한 내용및 구조가 별도의 데이터로서 공개된다.
3. 동일한 이름의 데이터에는 내용과 구조가 완전히 동일하다.
4. Machine Readable 한 포맷으로 공개된다.
5. 공개된 데이터의 구조도 함께 공개되며, 이 구조를 사용하여 자동 검증이 가능하다.
6. 이미 공개된 데이터가 일부 수정된 경우, 수정된 부분에 대해서 즉시 공개된다.
7. 공개된 데이터는 관련자에게 즉시 통지(notification)된다.
8. 해당 데이터의 사용자/기관은 (사람이 개입하지 않고) 자동으로 갱신된 데이터를 읽어오고,
이 데이터를 사용하여 자신의 데이터를 자동으로 수정한다.
동일한 데이터에 대해 공통 응용스키마를 갖도록 하고 이를 XSD, GML 로 공개하는 체계가 갖추어진다는 것은, 이 여덟가지 중에서 2,3,4,5 항목에 해당합니다. 1번 항목은 제도적으로 해결해야 할 부분이며, 6,7,8 항목은 공개된 데이터를 실시간으로 전달할 수 있는 시스템의 구축이 필요합니다. 물론 이러한 내용도 일부(개념적 수준에서는) 표준에 정의되어 있습니다.
현재 국토지리정보원에서는 일부 지형지물에 대해 완공이 되는 즉시 측량을 실시하는 실시간 갱신작업을 실시하고 있는 것으로 압니다. 그런데, 이러한 측량이 완료되는 시점에서 국민에게 전달될 때까지의 시간 - 즉, 네이버/다음 등의 포털지도에 나타나기 까지의 시간은 최소 6개월 이상 걸릴 것으로 생각됩니다. 제가 지금까지 말씀드린 "데이터의 내용 및 구조"라고 통칭한 이러한 기술을 적용하여, 정말 실시간으로 데이터를 공유할 수 있는 날이 빨리 오기를 소망합니다.
민, 푸른하늘