공공정보 활용, ‘링크드 데이터’로 똑똑하게

가 +
가 -

공공기관에서 보유한 각종 정보와 통계자료 등을 공개하는 움직임이 활발해졌습니다. 이런 시도는 정책기관의 운영을 투명하게 만들고, 캐비닛에 묻혀 있다 사라질 정보들을 시민이 활용하게 돕습니다. 흔히 ‘정부2.0’이라고 하는데요. 이런 공공정보들을 보다 효율적이고 영리하게 활용할 수 있는 방법을 제시하는 방법을 오원석 탑쿼드란트코리아 이사님이 기고하셨습니다. 블로터닷넷 독자 여러분과 공유합니다.

공공정보는 사용되면 사용될수록 가치가 높아진다. 물론, 공개가 허락되어야 하겠지만, 국민이라면 모두가 활용할 수 있도록 해야 한다.

최근 들어 서울시의 열린데이터광장이나 한국정보화진흥원의 공유자원포털을 통해 다양한 데이터들이 API를 통해 공개되고 있다. 국토해양부나 문화체육관광부 등 많은 중앙부처와 지방자치단체들도 앞다퉈 공공정보를 개방하고 있거나 개방에 대한 요구를 느끼고 있다.

공공정보는 보통 REST와 같은 URL(URI)형식으로 질의해 얻고자 하는 정보에 접근하는 식의 오픈API 형태로 제공되곤 한다. 서울시 열린데이터광장의 건설알림이 서비스의 경우 아래와 같은 형식으로 해당 데이터에 접근할 수 있다.

비슷한 방법으로 서울시 열린데이터광장의 전통시장 정보서비스도 아래와 같은 형식으로 해당 데이터에 접근할 수 있다.

위와 같은 형식으로 오픈API에 접근해 서비스에 활용할 수도 있지만, 다른 방법도 있다. 위 두 가지 데이터에 한 번에 접근해 서비스에 활용하거나, 원하는 조건을 통해 해당되는 데이터에만 접근해 서비스에 활용하려면 어떡해야 할까. 이런 경우에 대안으로 제시될 수 있는 것이 ‘링크드 데이터‘(Linked Data)다.

링크드 데이터는 뒷단에 트리플(RDF)이라는 조금은 생소한 형식의 데이터를 저장해 놓고, API나 SPARQL 질의를 통해 원하는 데이터에 접근할 수 있도록 한다. 오픈API와 비교해 링크드 데이터의 특성을 간략하게 비교해보면 아래와 같다.

  1. 오픈API는 정의된 형식으로만 데이터에 접근 가능하다. 뒷단의 데이터베이스 구조를 파악하더라도, 원하는 형식의 조건을 구성해 질의하는 것이 불가능하다.
  2. 오픈API는 각각의 정의된 형식으로 데이터에 접근하므로 각기 다른 API 세트를 섞어 사용할 수 없다. 다만 프로그램 코드에서 이를 비교해 섞는 것은 가능하지만, 데이터에 접근하는 과정에서 섞을 수는 없다.
  3. 오픈API 결과는 데이터를 객체화하지 않는다. 데이터는 각각의 특성을 통해 객체로 표현될 수 있다. 물론 REST 방식과 XML이나 json 결과 형식을 통해서 오픈API의 결과도 객체로 표현하고 활용할 수 있지만, 보통 오픈API를 통해서는 객체화를 사용하지 않는다.

위에서 예시로 보인 오픈API에 대한 결과 데이터를 아주 간단하게 링크드 데이터로 표현해 보았다. 링크드 데이터 도메인은 곧이어 설명할 KDATA를 활용했으며, 아주 간단하게 아래와 같이 모델을 설계했다. 사실, 이처럼 아주 간단하게 모델을 설계해서는 링크드 데이터의 진면목을 느낄 수 없다. 이는 간단한 설명을 위한 예시에 불과하다.

건설알림이

  • 건설명
  • 건설예산
  • 공사일자
  • 주소
  • 행정구역

전통시장

  • 전통시장명
  • 버스정보
  • 지하철정보
  • 연락처
  • 주소
  • 행정구역

위의 예시로 발행된 링크드 데이터는 총 6개이며, 그 중 하나인 영동전통시장의 모습은 아래와 같다.

링크드 데이터는 객체간 연결을 통해 데이터를 풍부하게 하고, 이를 웹에서 공유·활용하는 목적을 갖고 있다. 예시에서는 서울시에서 공개한 오픈API와 비교해 간단히 설명하고자 객체간 연결점을 만들지는 않았다.

이제 간단하게나마 발행된 링크드 데이터를 통해 오픈API와 링크드 데이터의 차이점을 설명해 보자

1. 오픈API는 정의된 형식으로만 데이터에 접근 가능하다. 뒷단의 데이터베이스 구조를 파악하더라도, 원하는 형식의 조건을 구성해 질의하는 것이 불가능하다.

다시 설명하면, 오픈API는 서비스 제공자가 정의해 제공하는 형식으로만 데이터에 접근할 수 있다. 우리가 데이터베이스를 이용하듯, 원하는 조건으로 원하는 데이터에 접근하는 인터페이스를 제공하지 않는다. 서비스 제공자 입장에서는 불특정 다수의 서비스 요청을 미리 모두 정의한다는 것은 사실상 불가능하다. 링크드 데이터를 이용하면 서비스 제공자는 웹을 통해 데이터 모델과 데이터를 발행하고, 서비스 사용자는 웹에 발행된 데이터를 통해 구조를 파악해 원하는 조건으로 원하는 데이터에 접근할 수 있다. 이것을 가능하게 하는 것이 링크드 데이터이며, 링크드 데이터에 질의하기 위한 인터페이스를 제공하는 것이 SPARQL Endpoint다.

위의 3가지 건설알림이 서비스 중 ‘지하철공사와 관련된 공사’에만 접근하고자 하는 경우를 생각해보자. 오픈API에서는 이러한 형식의 조건과 질의를 잘 사용하지 않는다. 모든 경우를 예상해 정의할 수도 없다. 건설명에 ‘지하철 공사와 관련된 공사’라 할지라도 ‘지하철’이라는 키워드가 들어가 있지 않을 수도 있지만, 간단한 설명을 위해 모든 지하철공사명에는 “지하철”이라는 키워드를 포함하고 있다고 가정하겠다.

● 지하철공사와 관련된 공사

SELECT ?name ?건설명
WHERE {
?name <http://data.kdata.kr/resource/건설명> ?건설명 .
?name rdf:type ?타입 .
?타입 rdfs:subClassOf owl:Thing .
filter regex(?건설명, “지하철”) .
}

● SPARQL 질의 설명

○ 건설명이라는 필드에 ‘지하철’이라는 키워드를 포함하는 인스턴스(객체)와 건설명을 리턴하시오

● 결과

name 건설명
http://data.kdata.kr/resource/contruction_1 서울지하철 9호선 2단계 915공구 건설공사(T/K)
http://data.kdata.kr/resource/contruction_2 서울지하철 9호선 2단계 916공구 건설공사(T/K)

2. 오픈API는 각각의 정의된 형식으로 데이터에 접근하므로 각기 다른 API 세트를 섞어 사용할 수 없다. 다만 프로그램 코드에서 이를 비교해 섞는 것은 가능하지만, 데이터에 접근하는 과정에서 섞을 수는 없다.

또다시 위 예시에서 ‘논현동과 관련 있는 건설알림이나 전통시장’에 대한 정보에 동시에 접근하고 싶다고 가정해 보자.

● 논현동과 관련 있는 건설알림이나 전통시장

SELECT ?name ?타입 ?주소
WHERE {
?name <http://data.kdata.kr/resource/주소> ?주소 .
?name rdf:type ?타입 .
?타입 rdfs:subClassOf owl:Thing .
?name rdfs:label ?명칭 .
filter regex(?주소, “논현동”) .
}

● SPARQL 질의 설명

○ 주소 필드에 ‘논현동’이라는 키워드를 포함하는 인스턴스(객체)와 인스턴스 타입, 주소를 리턴하시오

● 결과

name 타입 주소
http://data.kdata.kr/resource/NonHyunMarket http://data.kdata.kr/resource/전통시장 서울시 강남구 논현동 227-4
http://data.kdata.kr/resource/contruction_1 http://data.kdata.kr/resource/건설알림이 논현동 차병원 사거리~삼성동 힐스테이트 아파트
http://data.kdata.kr/resource/yeongdongTraditionalMarket http://data.kdata.kr/resource/전통시장 서울시 강남구 논현동 140외 44필지

위의 예시에서 보듯 아주 간단하다. 두 가지 서비스 모두 ‘주소’ 정보를 포함하고 있으므로, 두 가지 서비스를 섞은 질의가 가능하다.

서로 다른 서버에서 서로 다른 도메인으로 서비스된다 하더라도 문제없다. 링크드 데이터는 서로 분리돼 있는 모델(데이터)을 HTTP와 SPARQL을 이용해 연결해 한 번에 질의하는 것이 가능하다. 그것이 링크드 데이터의 강점 중 하나이기도 하다.

3. 오픈API 결과는 데이터를 객체화하지 않는다. 데이터는 각각의 특성을 통해 객체로 표현될 수 있다. 물론 REST 방식과 XML이나 json 결과 형식을 통해서 오픈API의 결과도 객체로 표현하고 활용할 수 있지만, 보통 오픈API를 통해서는 객체화를 사용하지 않는다.

위의 예시에서와 같은 경우, 조건을 만족하는 결과를 통해 해당 객체에 접근하고자 하는 경우가 발생할 수 있다. 1번과 2번의 예에서 발생한 객체는 다음과 같다.

1번에서 발생한 객체

2번에서 발생한 객체

위 객체들은 HTTP를 통해 해당 객체에 직접 접근이 가능하다. 위의 URL(URI) 그대로 웹브라우저에서 확인해보면 해당 객체 정보를 확인할 수 있다. 또 다른 형식으로도 객체에 접근할 수 있다. http://data.kdata.kr/resource/NonHyunMarket (논현시장)을 통해 각각의 객체가 지원하는 데이터 형식의 예를 들면 다음과 같다.

각각의 형식에 대해서는 다음에 기회가 되면 다시 설명하도록 하겠다.

비록 소량의 데이터로 예시를 보였고 강남구 데이터의 극히 일부만 사용됐지만, 서비스에서 활용할 데이터가 많아지거나, 결과를 리턴받은 뒤 비교해야 할 데이터가 많아진다면 성능에 대한 부분도 간과할 수 없다. 서비스 생산 속도나 기획 속도, 테스트 성능도 무시할 수 없다. 서비스 기획에 대한 아이디어 구상 중에도 데이터를 활용하는 범위가 넓어질 수 있다.

KDATA는 이런 링크드 데이터의 강점을 활용하고자 만들어졌다. 공공정보가 링크드 데이터로 발행되기 위한 모습을 미리 점검해보는 차원이기도 하다. 또한, 공공기관에서 오픈API 방식으로 공개하는 공공정보를 링크드 데이터로 변환하는 것도 가능하다. 다만, 이 서비스는 아직은 제공되지 않는다.

KDATA는 W3C의 시맨틱웹 표준 기술로 링크드 데이터를 구현해 공개 기반 데이터 웹 생태계에 한걸음 가까이 다가가기 위한 노력이다. 링크드 데이터의 확산을 통해 자유로운 웹 공간에서 데이터는 보다 유익하고 유용하게 활용될 수 있으며, 연결된 데이터의 탐색과 활용으로 지능적인 웹을 구현할 수 있다.

현재 KDATA는 기업, 시설, 야구선수, 문화재, 초중고교 등의 데이터와 행정 데이터를 포함하고 있으며, http://kdata.kr/kdata/dataset.jsp에서 관련 정보들을 제공한다. 유용한 질의나 예제 질의는 http://kdata.kr/sparql/usefulsparql.jsp에서 확인할 수 있다. 서울시나 한국정보화진흥원 등에서 공개하고 있는 여러 데이터셋을 계속 추가하고 있다.

KDATA는 시민의 힘으로 만들고 키워야 한다. 그러기 위해서는 링크드 데이터의 유용성을 보다 널리 알려야 한다. 링크드 데이터가 유용한 방법이라는 것이 알려져야 많은 사람들과 함께할 수 있기 때문이다.

공공정보, 오픈 데이터가 관심사로 떠오르고 있으며, 많은 공공정보들이 공개되고 있다. 여러가지 형식으로 공개되고 있지만 데이터의 재사용성을 높이고 또 다른 곳에서 공개된 관련 데이터들과의 활용도를 높이는 데는 링크드 데이터가 제격이다.

다만 링크드 데이터는 아직 사용하기 어렵고 대중적이거나 일반적이지 못한 것이 사실이다. 하지만 사용하는 개발자들이 늘어나고 대중화된다면 보다 사용하기 쉬운 일반적인 것으로 바뀌게 될 것이다.

데이터는 공유되고 협업돼 활용될 때 그 가치가 높아진다. 문화재청이 공개하는 남대문 정보와 국토해양부가 공개하는 남대문 지역정보, 한국관광공사가 공개하는 남대문 근처 관광명소와 맛집 정보는 각자 공개돼도 좋지만, 서로 연결되면 활용가치는 배가될 것이다.

공공정보를 공개하면 정부는 투명해지고 국민은 알찬 정보를 활용할 수 있어 좋다. 더 많은 공공정보가 공개되고, 더 많은 아이디어가 나오고, 더 많은 유용한 플랫폼과 개발도구들이 나오길 희망한다.

글쓴이 오원석. ㈜탑쿼드란트코리아 이사. KDATA를 기획·개발했으며 공공정보 활용 커뮤니티 ‘코드나무‘와 페이스북 공개그룹 ‘열려라 공공데이터‘에서 열심히 활동하고 있다. 시민들에게 공공정보를 링크드 데이터로 활용할 수 있는 플랫폼으로 제공하고자 한다.

네티즌의견(총 6개)