2012.12_ 서울시 공공데이터 Open api 검증보고서

페이지 1 / 91
서울시 - 열린데이터광장
OpenAPI 검증
참여연구원
코드나무 : 강현숙
코드나무 : 오원석
코드나무 : 이명진
코드나무 : 권오현
코드나무 : 장지윤

페이지 2 / 91
목 차
I. 개요
1. 개요
2. 검증 방법
3. 검증 대상
II. OpenAPI 검증 - 공통
1. 중요이슈
1.1. 용어(Vocabulary)
1.2. OpenAPI 운영을 위한 URL 디자인
1.3. 참조값에 대한 표현
1.4. 위치정보
1.5. 데이터 형식(포맷)
1.6. 메타데이터 디자인
1.7. 에러 레포팅
1.8. 검색 기능
1.9. OpenAPI 요청자 인증 관리
1.10. 데이터 생성 기준 일자
2. 작은이슈
2.1. API 에 대한 API
2.2. 페이징 방식 개선
2.3. 개별 OpenAPI URL
2.4. CDATA 남용
III. OpenAPI 검증 - 서비스별
1. 일반행정, 교통, 안전
2. 환경, 보건, 복지, 산업경제
3. 문화관광, 도시관리
IV. 결론
1. 결론

페이지 3 / 91
I. 개요
1. 개요
공공정보를 시민과 국민 모두가 적극적으로 활용할 수 있도록 하기 위해, 서울시는 최근 선도적으로
공공정보를 개방하고 있다. 공공정보 개방 및 제공과 관련된 방법으로 csv 형태의 파일 제공이나
데이터베이스 파일 제공, OepnAPI 서비스 제공과 같은 방법을 활용하고 있으며, OpenAPI 에 대한
비중이 지속적으로 늘어나고 있다. 서울시는 공공정보 개방에 대해 타 기관이나 지방자치단체에
선도적인 모습을 보이고 있는 것이 사실이며, “서울시-열린데이터광장”이 해당 서비스를 담당하고 있다.
해당 서비스와 관련된 내용은 http://data.seoul.go.kr 에서 확인할 수 있다.
지속적으로 OpenAPI 가 늘어나기 때문에 사용자 입장에서의 활용 측면도 고민해 봐야 할 시점이다.
이에, 공학 입장에서의 OpenAPI 에 대한 품질 검증 및 기술적 접근이 아닌, 사용자 관점에서의 활용성
측면에 대한 의견을 기반으로 본 검증을 실시하였으며, 보고서는 공통항목과 개별 서비스 항목에 대한
의견으로 구분하였다. 또한 공통항목은 참여 연구진의 의견에 따라 중요이슈(Major Issue)와
작은이슈(Minor Issue)로 구분하여 정리하였으며, 개별적으로 모든 OpenAPI 서비스에 대한 검증 및
정리는 수행하지 않았다.
2. 검증 방법

페이지 4 / 91
본 검증에는 서울시의 OpenAPI 서비스를 사용자 측면에서 바라볼 수 있는 다섯 명의 연구진이 참여
하였으며 위의 그림과 같은 프로세스로 검증을 수행하였다.
1 첫 번째 단계에서는 검증계획을 수립하였으며, 서울시 열린데이터광장에서 제공하는
OpenAPI 를 검증하는 과정에 대해 협의하고, 검증방향에 대한 방법을 도출하였다.
2 두 번째 단계에서는 검증계획에 따라 서울시 열린데이터광장의 OpenAPI 를 개별적으로
점검하였으며, 다섯 명의 연구진이 20 개씩 각자 할당된 서비스를 조사하였다. 이를 통해 본
보고서의 작성 윤곽을 도출하였으며, 조사 결과에 따라 서울시 열린데이터광장에서 제공하는
OpenAPI 서비스에 공통적으로 적용될 수 있는 공통 이슈와 개별적 서비스에 적용될 수 있는
개별 이슈로 보고서의 윤곽을 도출하였다.
3 세 번째 단계에서는 두 번째 단계의 개별 서비스 조사 결과를 토대로 공통 이슈에 대해 중요
이슈와 작은 이슈로 검증 항목을 선별하였으며, 선별된 항목에 대해 전문 분야와 관심 분야를
고려하여 검증 항목 정리를 할당하였다.
4 네 번째 단계에서는 각자 할당된 항목을 기준으로 기술적 조사와 함께 정리를 수행하였다.
5 다섯 번째 단계에서는 네 번째 단계 진행 중에 발생한 추가 고려사항을 반영하였다.
6 마지막으로 보고서 작성 및 교정을 수행하였다.
3. 검증 대상
서울시-열린데이터광장에는 OpenAPI 이외에도 파일, 맵, csv 등의 형식으로 공공정보를 개방하고 있다.
이중에서 활용도가 가장 높은 것이 OpenAPI 이며, OpenAPI 에 대한 수요가 나날이 늘어감에 따라
OpenAPI 를 대상으로 사용자 관점에서 검증을 수행하였다. 사용자 관점에서 검증을 수행했다는 것은
기술적 관점에서의 접근보다는 사용자 관점에서의 활용성에 초점을 맞추었다는 것이다. 또한 본
보고서에서 참조한 서울시 열린데이터광장의 OpenAPI 서비스는 2012 년 11 월 23 일 현재 서울시
열린데이터광장에 목록화 되어 있는 129 건을 대상으로 하였다.

페이지 5 / 91
II. OpenAPI 검증 - 공통
1. 중요 이슈 (Major Issue)
1.1. 용어(Vocabulary)
1.1.1. 현상 및 문제점
현재 “서울시-열린데이터광장”에서 서비스되는 대략 120 여종의 OpenAPI 들은 XML 형식이나
json 형식으로 결과값을 반환하는 기능을 제공한다. XML 이나 json 형식은 데이터를 구조적으로
표현하기 위해 필드(태그 또는 속성)와 값(Value)를 이용하며, 필드가 값을 감싸고 있는 형태를 지닌다.
필드는 일반적으로 값을 활용하기 위한 중간 매개체 역할을 한다. OpenAPI 를 이용해 특정 서비스를
개발하는 경우 서비스명과 인증키, 그리고 몇 가지의 조건을 입력으로 매칭되는 결과값을 반환 받는데,
이때 반환된 결과값에 접근하기 위해서는 필드를 파싱하여 해당되는 값에 접근한다.
따라서 필드는 중요한 의미를 지닌다. 첫 번째로는 가독성에 대한 것이다. 필드는 기계적으로 파싱하여
해당되는 값에 접근하기 위한 용도로도 사용되지만 이를 구별하거나 판단하고 서비스를 기획하는
시점에도 중요한 역할을 한다. 두 번째는 서비스(OpenAPI)간 협력에 대한 것이다. 두 가지 이상의
서비스를 조합하여 하나의 기능을 만들고자 하는 경우, 서로 같은 필드명을 사용한다면 개발자
입장에서는 서비스를 개발할 때 많은 수고를 덜 수 있다. 세 번째는 표준에 대한 것이다. 표준은 보통
혼란과 혼동을 피해가기 위한 역할을 수행하는데, 특정 명칭을 사용한다는 약속은 많은 부분에서
OpenAPI 를 기획 또는 개발, 배포하는 과정에서 서비스간의 혼동과 혼란을 막아줄 수 있다.
물론, 모든 필드명을 엄격하게 기준을 정해 모두가 약속을 지켜야 한다는 것은 아니다. 약속과 표준을
정하고 되도록이면 이를 지켰을 때 더 좋은 데이터 환경을 제공할 수 있고, 공공정보 활용도는 높아질 수
있다.
현재 서울시에서 배포하고 공개한 120 여종 서비스(OpenAPI)의 경우, 사용하는 필드명이 통일성 없이
제각각 사용되고 있어, 서비스를 매쉬업해서 기능을 개발한다거나 두 가지 데이터를 조합하고자 할 때

페이지 6 / 91
많은 불편함을 초래하고 있다. 주소를 포함하는 XML 형식의 결과값은 아래처럼 같은 주소라는 속성에
대해 서로 다른 필드명을 사용하고 있다.
● 전통시장 정보(http://data.seoul.go.kr/metaview.jsp?id=OA-1176)
○ 주소명 : M_ADDR
● 장애인 시설정보(http://data.seoul.go.kr/metaview.jsp?id=OA-1220)
○ 소재지 : ADDR
● 시장마트정보(http://data.seoul.go.kr/metaview.jsp?id=OA-1175)
○ 마트주소 : M_MART_ADDR
● 가격안정모범업소(http://data.seoul.go.kr/metaview.jsp?id=OA-1173)
○ 업소주소 : SH_ADDR
위의 서비스에서 사용하고 있는 필드명은 모두 주소(Address)를 의미하고 있는 듯하다. 하지만 각각
서로 다른 필드명을 사용하고 있다. 연락처와 관련된 다른 예시를 보자.
○ 전화번호 : TEL
○ 업소전화번호 : SH_PHONE
● 전통시장정보(http://data.seoul.go.kr/metaview.jsp?id=OA-1176)
○ 상인회연락처 : M_TEL
○ 마트연락처 : M_MART_PHONE

페이지 7 / 91
위치정보를 나타내는 경우도 다르지 않다. 각각의 서비스마다 위도와 경도를 표현하는 필드명을
상이하게 사용하고 있다. 아래는 그와 관련된 몇 가지 예시이다.
● 구두수선소 공간정보(http://data.seoul.go.kr/metaview.jsp?id=OA-1197)
○ X 좌표 : X_COORD
○ Y 좌표 : Y_COORD
● 공원정보정보조회(http://data.seoul.go.kr/metaview.jsp?id=OA-394)
○ X 좌표(WGS84) : LONGITUDE
○ Y 좌표(WGS84) : LATITUDE
○ X 좌표(GRS80TM) : G_LONGITUDE
○ Y 좌표(GRS80TM) : G_LATITUDE
● 도시계획 공간정보(http://data.seoul.go.kr/metaview.jsp?id=OA-1065)
○ 경도(WGS84 경도)(DEPTH : 4) : lon
○ 위도(WGS84 경도)(DEPTH : 2) : lat
● 서울안심먹거리 목록(http://data.seoul.go.kr/metaview.jsp?id=OA-1188)
○ X 좌표 : CTF_X
○ Y 좌표 : CTF_Y
마지막으로 하나의 경우만 더 살펴보자. 각각의 서비스에는 명칭정보가 포함되어 있다. 물론 서비스
성격마다 명칭의 세부적인 의미는 다르지만 결국은 해당 서비스가 제공하고 있는 자원에 대한 명칭이다.
업소정보와 같은 경우 업소명, 시장정보와 같은 경우 시장명 등이 대표적이다. 아래는 그 예시이다.
○ 업소명 : SH_NAME
● 전통시장정보(http://data.seoul.go.kr/metaview.jsp?id=OA-1176)
○ 시장명 : M_NAME

페이지 8 / 91
○ 마트이름 : M_MART_NAME
● 공원정보조회(http://data.seoul.go.kr/metaview.jsp?id=OA-394)
○ 공원명 : P_PARK
1.1.2 권고 의견
위에서는 각각 주소, 연락처, 위치정보, 명칭과 관련된 필드명이 제각각 사용되고 있는 예시를 보였다.
이는 다음과 같이 통일화된 방법으로 표현이 가능하다.
● 주소 : Address
● 연락처 : Telephone
● 위치정보 : LAT, LONG
● 명칭 : Name 또는 Title
물론 아주 간단하게 위의 예시를 사용한다고 해서, 용어가 가져다 주는 모든 문제에 대한 것을 해결할
수는 없다. 위의 예시를 사용한다고 해도 그것 모두가 해결될 수는 없는 경우도 있다는 것이다. 연락처
정보와 같은 경우 하나의 서비스에 두 가지 이상의 연락처 정보를 포함해야 하기도 하고, 명칭과 같은
경우 상위명칭, 하위명칭 등으로 구분될 수도 있다. 이를 모두 해결하기 위해서는 메타데이터 구조를
위한 스키마가 필요하다. 필드의 상하 구조를 이용하는 방법이 하나의 예시가 될 수 있다. 예를 들면
다음과 같다.
● 주소정보
○ Address
■ Office_Address
■ Home_Address
● 명칭정보
○ Name

페이지 9 / 91
■ Sub_Name
■ Alternative_Name
● 위치정보
○ LAT
○ LONG
이는 시소러스 체계를 이용하는 방법과 유사하다 할 수 있다. 다만 본 문서에서 메타데이터 구조를 위한
스키마까지 깊게 언급하는 것은 범위를 넘어갈 수 있기 때문에 메타데이터 구조에 대한 언급은 더 이상
하지 않도록 하겠다. 다만, 활용 가능한 용어(Vocabulary)를 선별 또는 구축하여 모든 서비스에서
통일성을 갖고 필드에 활용하면 해당 서비스를 활용하는 사용자 입장에서는 많은 혼란을 제거할 수 있다.
필드명이 통일성을 갖고 모든 서비스에서 활용할 수 있는 방법을 생각해 보자. 첫째는 기존에 구축되어
있거나 많이 사용되는 용어체계를 활용하는 것이다. Dublin Core, FOAF, SKOS, Bibliographic Ontology,
schema.org 등을 이용하는 것이다. 주로 시맨틱웹이나 온톨로지 영역에서 많이 사용되는 것들이지만,
시맨틱웹이나 온톨로지에 대한 개념을 꼭 반영해야 한다는 것은 아니다. 누구나 많이 이용하는
용어체계를 활용하자는 것이다. 둘째는 위에서 언급한 용어체계들을 이용해서 권고할 수 있는
용어체계를 구축하고 배포하는 것이다.
위의 두 가지 방법 모두를 고려해 볼 수 있다. 다만 더욱 중요하게 생각해야 하는 것은 표준과 약속,
그리고 배려를 통해 혼동과 혼란을 막고 활용성을 높이는 것이다.

페이지 10 / 91
1.2. OpenAPI 운영을 위한 URL 디자인
현재 서울시에서 운영하고 있는 OpenAPI 의 일반적인 형식은 다음과 같다.
● http://OpenAPI.seoul.go.kr:8080/인증키/요청타입/서비스명/기타
기본적으로 서울시 OpenAPI 는 URL 형식을 취하고 있으며, 서울시 OpenAPI 를 호출하기 위한 기본
URL 에 사용자 인증을 위해 부여 받은 인증키와 응답형식 지정을 위한 요청 타입, 그리고 해당 서비스의
서비스 명을 포함하고 있다.
여기에 각각의 서비스 이용에 필요한 정보들을 URL 로 구성하여 하나의 OpenAPI 에 대한 질의를
구성한다. 예를 들어, ‘건설정보 : 건설알림이’의 경우 다음과 같은 변수를 사용하여 하나의 OpenAPI 요청
URL 을 구성하게 된다.
 ‘건설정보 : 건설알림이’의 URL 변수 목록 - http://data.seoul.go.kr/metaview.jsp?id=OA-1222
변수명 타입 변수 설명 값 설명
인증키 STRING(필수) 인증키 OpenAPI 에서 발급된 인증키
요청타입 STRING(필수) 요청파일 타입 xml : xml, xml 파일 : xmlf, 엑셀파일 : xls,
json 파일 : json
서비스명 STRING(필수) 서비스명 ListConstructionWorkService
요청시작건수 INTEGER(필수) 요청시작건수 정수 입력
요청종료건수 INTEGER(필수) 요청종료건수 정수 입력
FCT_F25_NM STRING(선택) 자치구 구분 자치구명
PJT_END_DIV NUMBER(선택) 프로젝트
종료여부
프로젝트 종료여부(진행:0, 종료:1)

페이지 11 / 91
위와 같은 변수명을 이용하여 다음과 같은 예시 URL 을 구성할 수 있다.
● 건설공사 정보조회
○ http://OpenAPI.seoul.go.kr:8088/sample/xml/ListConstructionWorkService/1/5/
● 종로구 건설공사 정보조회
○ http://OpenAPI.seoul.go.kr:8088/sample/xml/ListConstructionWorkService/1/5/종로구/
● 동대문구 종료 건설공사 정보조회
○ http://OpenAPI.seoul.go.kr:8088/sample/xml/ListConstructionWorkService/1/5/동대문구
/1/
위에서 살펴본 것과 같이 서울시에서 제공하고 있는 OpenAPI 는 기본적으로 각각의 필요 변수를
이용하여 URL 을 구성하고 해당 서비스를 이용하도록 제공하고 있다.
하지만 이러한 형태로 URL 을 구성할 경우 다음과 같은 문제가 발생할 수 있다. 기본적으로 URL 은
OpenAPI 에 대한 서비스 기능의 계층과 특성을 명시적으로 표현하여야 하며, OpenAPI 를 이용하는
사용자가 직관적으로 이해할 수 있도록 구성되어야 한다.
가. 확장성
현재 기본적인 OpenAPI 의 형식이 앞서 언급한 것과 같이 질의를 위해 필요한 변수 정보들이 모두
URL 의 구분명으로 활용되고 있다. 이러한 형태로 OpenAPI 의 URL 을 구성할 경우 향후 확장성에 제한이
있을 수 있다. 예를 들어, 운영 중인 서비스에 대해 새로운 변수가 추가될 경우 이를 또 하나의
구분명으로 URL 에 통합해야만 한다. 이는 향후 서비스에 대한 간단한 변수의 변경이 생겼을지라도 전체
URL 의 형식이 변경되기 때문에 기존에 OpenAPI 를 운영 중인 서비스들이 모두 일괄적으로 변경된
형식으로 전환을 해야만 하는 문제가 발생할 수 있다. 또한 서비스를 제공하는 서비스 제공자의
입장에서도 URL 이 변경되기 때문에 유지보수에 많은 비용을 발생시킬 수 있다. 따라서 향후 서비스에
대한 추가 및 변경에 대한 확장성을 고려한다면 OpenAPI 서비스 URL 에 대한 기본적인 형식을 지켜서
운영되어야만 한다.

페이지 12 / 91
나. 서비스 이용 방식의 통일성
앞서 언급한 것과 같이 서울시에서 제공하고 있는 OpenAPI 는 기본적으로 URL 방식을 사용하고 있다.
하지만 ‘도시계획정보 : 도시개발사업’과 같이 URL 형식과 변수를 RPC 형태의 질의 문자열로 혼합하여
이용하는 서비스가 혼재하고 있다.
● ‘도시계획정보 : 도시개발사업’의 요청 주소
○ http://OpenAPI.seoul.go.kr:8089/OpenAPI/SearchUrbanDev.jsp
위와 같은 OpenAPI 의 URL 을 이용하여 필요 변수를 다음과 같은 RPC 형태의 질의로 서비스를
요청한다.
● 사업명에 '마곡'포함되는 도시개발사업
○ http://OpenAPI.seoul.go.kr:8089/OpenAPI/SearchUrbanDev.jsp?key=4150495f32303833
616c657837323130&bizName=마곡
위의 URL 은 인증 정보를 key 변수로 표현하고 도시개발 사업명에 마곡이란 단어가 포함되어 있는
도시개발사업을 질의하기 위해 RPC 형태의 질의를 구성한 OpenAPI 호출 URL 이다. 이와 같이 현재
공개된 서울시 OpenAPI 의 이용 방식이 URL 을 이용한 형태와 RPC 형태의 질의를 구성하여 이용할 수
있는 OpenAPI 형태가 혼재되어 있다.
따라서 OpenAPI 서비스의 일관성을 유지하기 위해서는 하나의 형태로 통일하여 운영할 필요성이
있다.
다. 리스트 형과 상세정보 요청을 위한 URL 의 구분
현재 운영 중인 OpenAPI 의 대부분이 리스트 형태의 질의를 수행하기 위한 형태를 가지고 있으며,
이러한 OpenAPI 에 각 자원에 대한 모든 정보들이 포함되어 있다. 예를 들어, ‘시설정보 : 장애인
시설정보’ OpenAPI 의 경우 하나의 OpenAPI 를 이용하여 장애인 시설정보에 대한 모든 정보를 질의할
수 있다.

페이지 13 / 91
‘시설정보 : 장애인 시설정보’ OpenAPI 의 호출 결과 예시
위의 그림은 장애인 시설정보를 질의하기 위한 ListDisabledFacilitiesService OpenAPI 의 결과이다.
그림에서 <row> 엘리먼트가 하나의 장애인 시설에 대한 정보를 의미하며, <row> 엘리먼트의 내용은
그에 대한 상세정보를 나타낸다. 즉, 현재 운영 중인 서울시의 OpenAPI 의 대부분은 목록을 요청하는
것과 해당 리소스에 대한 상세 정보를 요청하는 OpenAPI 에 대한 구분을 하지 않고 있다.
하지만 이러한 형태로 운영할 경우 단순히 해당 목록을 필요로 하는 경우에도 전체 데이터에 대한
정보가 결과로 반환되기 때문에 서비스를 제공하는 측면에 있어서 서버에 부하를 가져올 수 있으며,
사용자 입장에서는 각각의 개별적 리소스에 접근 할 수 있는 방법이 없으므로 개발하는 서비스에서
일일이 해당 정보를 잠시 또는 장기적으로 보관하고 있다가 사용하여야 한다. 따라서 서버의 부담을
줄이면서 사용자의 필요에 맞추어 서비스를 제공하기 위해서는 목록을 요청하기 위한 OpenAPI 와 해당
데이터에 대한 상세정보를 요청하기 위한 OpenAPI 가 독립적으로 운영되어야 한다.
라. 반환 형태에 대한 표현

페이지 14 / 91
현재 서울시에서 제공하고 있는 OpenAPI 는 XML, XML 파일, XSL, JSON 형태의 결과 형식을 지원하고
있으며, 이러한 응답형식을 지정하기 위해 URL 의 구분명을 이용하여 그 타입을 지정하고 있다.
● 건설공사 정보에 대한 JSON 형태의 결과조회
○ http://OpenAPI.seoul.go.kr:8088/sample/json/ListConstructionWorkService/1/5/
위 예제는 건설공사 정보를 JSON 형태의 결과로 제공 받기 위한 OpenAPI 의 URL 형태이다. 위와 같은
형태는 응답형식을 명시적으로 지정하여 OpenAPI URL 에 대한 가독성을 높일 수 있기는 하지만
OpenAPI 의 전체적인 URL 디자인 측면의 권고사항에 위배된다.
1.2.2. 권고의견
OpenAPI 를 통해 제공되는 모든 서비스는 고유한 서비스 URL 을 가지고 있으며, URL 은 서비스가
제공하는 자원의 분류적인 특성이나 행위적인 의미를 표현한다. 따라서 URL 명명은 서비스로 제공될
정보 자원에 대한 식별자를 정의하는 중요한 활동이며, 사용자가 직관적으로 이해할 수 있도록
구성되어야 한다.
가. 서비스에 대한 명명 규칙
URL 과 서비스에 대한 명명은 해당 서비스에 대한 행위적인 의미를 표현하기 때문에 아주 중요한
활동 중 하나이다. 이러한 서비스 명명은 사람이 직관적으로 읽고 이해할 수 있는 형태로 이루어져야
보다 효율적으로 활용될 수 있다.
행정안전부에서 고시한 “공유서비스 개발 가이드라인” 지침을 보면 서비스 명에 대해 사람이 읽을 수
있는 직관적인 명사로 구성할 것을 권고하고 있다. 예를 들어, 공원에 대한 정보를 요청하는 서비스라면
그 서비스에 대한 이름을 “park”라고 지정하도록 권장한다. 이는 기존의 SOAP 방식의 서비스 명명
규칙과 다른 RESTful API 의 독특한 형태에 기인하는데, RESTful API 의 경우 서비스에 대한 기능이 HTTP
상태(GET, POST, PUT, DELETE)에 의해 결정되기 때문에 서비스 이름을 명명할 때 행위에 대한 명명
규칙이 필요 없기 때문이다.

페이지 15 / 91
또한 O’REILLY 에서 출판된 “REST API Design Rulebook”을 보면 URL 을 위해 “_”보다는 “-” 기호를
사용할 것을 권장하고 있으며, URI 를 위해 명사의 형태로 소문자를 이용해 명명할 것을 권고하고 있다.
나. 분류체계로써의 URL 활용
현재 서울시에서 제공하고 있는 OpenAPI 는 126 건에 달하고 있다. 향후 더 많은 OpenAPI 가 개발 및
공개될 것이며, 따라서 이를 효과적으로 분류할 수 있는 분류체계가 필요하다. 일반적으로 URL 에서의
구분명은 하나의 디렉토리 의미로써 어떤 자원들에 대한 집합을 의미한다. 따라서 URL 의 구분명은
OpenAPI 의 서비스에 대한 분류체계로 활용될 수 있으며, 서비스 개수가 많아질 경우 계층 구조의
서비스 분류체계를 URL 경로 상에 명시함으로써 보다 효율적인 OpenAPI 에 대한 URL 의 표현이
가능하다.
예를 들어, 현재 ‘화장실정보 : 서울시 화장실 공공정보 POI 정보조회’ OpenAPI 와 ‘공원정보 : 공원정보
정보조회’ OpenAPI 는 다음과 같은 서비스 URL 을 가지고 있다.
● ‘화장실정보 : 서울시 화장실 공공정보 POI 정보조회’의 요청 주소
○ http://OpenAPI.seoul.go.kr:8088/sample/xml/SearchPublicToiletPOIService
● ‘공원정보 : 공원정보 정보조회’의 요청 주소
○ http://OpenAPI.seoul.go.kr:8088/sample/xml/SearchParkInfoService
두 개의 서비스를 이용하기 위한 URL 은 분류체계에 대한 구분 없이 서비스의 이름만을 가지고 있다.
이러한 형태의 URL 보다는 향후의 늘어날 수 있는 서비스를 고려하여, 분류체계를 URL 에 명시할 것을
권장한다.
● ‘화장실정보 : 서울시 화장실 공공정보 POI 정보조회’의 요청 주소
○ http://OpenAPI.seoul.go.kr:8088/pubInfo/public-toilets
● ‘공원정보 : 공원정보 정보조회’의 요청 주소
○ http://OpenAPI.seoul.go.kr:8088/pubInfo/parks

페이지 16 / 91
위의 예제는 서울시 화장실 공공정보 POI 정보조회 API 와 공원정보 정보조회 API 에 대한 분류체계를
URL 상에 명명한 예이다.
이를 위해서는 우선 서비스에 대한 분류체계를 수립할 필요가 있다. 이렇게 수립한 분류체계를
활용하여 서비스를 구성할 때 각 분류체계를 URL 상에 명시하여 OpenAPI 서비스에 대한 URL 을
작성하도록 한다. 분류체계 수립을 위해서는 정부에서 고시한 업무참조모델(BRM)이나
서비스참조모델(SRM)을 활용할 수 있다.
다. 집합 형태의 요청과 자원 형태의 요청에 대한 분리
앞서 문제점에서 언급한 것과 같이 현재 서울시에서 제공하고 있는 OpenAPI 는 리스트의 형태를
질의하기 위한 OpenAPI 와 하나의 자원에 대한 질의를 수행하기 위한 OpenAPI 에 대한 구분이 존재하지
않는다. 이러한 경우 단순히 목록을 필요로 하는 경우에도 전체 상세정보와 함께 결과가 반환되기 때문에
서버에 많은 부담을 줄 수 있을 뿐 아니라 클라이언트를 개발할 때에도 서비스에 대한 속도 및 불필요한
정보를 걸려내야 하는 부가적인 작업이 필요하다.
REST 형태의 API 를 통해 제공되는 정보의 타입은 크게 두 가지로 구분할 수 있다. 첫 번째는
Document 혹은 Resource(자원) 형태로 분류될 수 있는 것으로써, 하나의 개체에 대한 정보를 의미한다.
다른 한 가지는 Collection(집합 혹은 리스트) 타입으로써 하나 이상의 자원에 대한 집합의 형태를
의미한다.
서비스를 위한 URL 을 복수 형태의 명사로 이름을 명명할 경우는 집합의 형태를 의미하며, 단수
명사를 사용할 경우는 하나의 자원을 의미한다. 이는 서비스를 위한 URL 을 설계할 때 상위 Path 는 하위
Path 의 집합을 의미하도록 계층적 구조로 반영되어야 한다. 즉, 하위 자원에 대한 Collection 형태의 자원
집합이 존재하는 경우 상위 Path 명은 복수형으로 하며, 복수의 자원이 존재하지 않는 단일 자원의
경우는 단수형으로 URL 체계를 구성한다.
● ‘공원정보 : 공원정보 리스트 조회’의 요청 주소
○ http://OpenAPI.seoul.go.kr:8088/pubInfo/parks
● ‘공원정보 : 마로니에 공원정보 조회’의 요청 주소
○ http://OpenAPI.seoul.go.kr:8088/pubInfo/park/72

페이지 17 / 91
위의 예시는 공원정보에 대한 목록을 요청하는 OpenAPI 와 하나의 공원에 대한 정보를 요청하는
OpenAPI 가 구분된 형태를 가지고 있다. 공원의 경우 집합의 형태가 존재하기 때문에 복수형 명사
“parks”를 서비스의 명으로 지정하였으며, 이러한 서비스에 대해 공원정보에 대한 리스트가 반환된다. 이
경우 반환결과에는 공원 각각에 대한 상세정보가 아닌 개략적인 정보를 반환하도록 결과가 설계되어야
하며, 반드시 각 공원에 대한 세부 정보를 요청하기 위한 링크 정보를 포함하여야 한다. 두 번째 예제는
마로니에 공원에 대한 상세 정보를 요청하기 위한 OpenAPI 이다. 마로니에 공원에 대한 ID 를 활용하여
OpenAPI 를 위한 URL 을 구성한다.
한 가지 추가적인 사항은 집합에 대한 단일 자원 OpenAPI 를 구성할 경우 숫자와 같은 ID 를 활용하는
것 보다는 사용자가 URL 로부터 어떤 자원에 대한 요청인지를 직관적으로 읽고 이해할 수 있도록 다음과
같이 자원에 대한 이름을 활용하는 것을 권고한다.
● ‘공원정보 : 마로니에 공원정보 조회’의 요청 주소
○ http://OpenAPI.seoul.go.kr:8088/pubInfo/park/marronnier
앞서 언급한 내용을 정리하면, OpenAPI 를 위한 URI 구성은 다음과 같은 형태를 권장한다.
● http://OpenAPI.seoul.go.kr:8088/분류 1/분류 2/.../집합/자원/집합/자원/...
라. 질의를 위한 형태
현재 서울시 OpenAPI 에서는 집합 형태의 리스트에 대한 페이징을 위해 다음과 같이 독립적인 URL 을
구성하도록 유도하고 있다.
● 1 부터 5 까지의 ‘공원정보 : 공원정보 정보조회’의 현재 요청 주소
○ http://OpenAPI.seoul.go.kr:8088/sample/xml/SearchParkInfoService/1/5
하지만 페이징과 같이 어떤 집합 형태에 대해 필터링을 위해서는 독립적인 URL 을 구성하기 보다
서비스의 수행에 필요한 요청 변수 정보를 질의 문자열로 넘기는 RPC 형태의 HTTP GET 메소드를
활용하는 것을 권장한다. 이는 서비스 행위의 대상이 되는 자원을 식별하기 위한 조건이 다양하거나

페이지 18 / 91
복잡한 경우 조건을 쉽게 표현할 수 있다는 장점이 있으며, 집합 형태의 요청에 대한 필터링을 위한
용도로 적합하다. 특히 페이징의 경우 집합 자원에 대한 필터링을 목적으로 하기 때문에 질의 문자열을
활용하는 것이 독립적인 URL 을 구성하는 것보다 적합하다.
● 1 부터 5 까지의 ‘공원정보 : 공원정보 정보조회’의 권고 요청 주소
○ http://OpenAPI.seoul.go.kr:8088/pubInfo/parks?pageSize=5&pageStartIndex=1
위의 예시는 공원정보에 대한 목록을 얻기 위해 첫 번째 레코드로부터 5 개의 레코드를 얻기 위한
OpenAPI URL 의 예이다. 시작 번호를 나타내는 pageStartIndex 요청 변수와 반환될 레코드의 개수를
지정하기 위한 pageSize 요청 변수를 사용하여 공원정보 목록을 요청한다. 이 외에도 집합에 대한
필터링을 목적으로 하는 경우에는 질의 문자열을 활용할 것을 권고한다.
마. 반환 형태에 대한 지정
서울시 OpenAPI 는 JSON 과 XML 을 포함하여 여러 가지 형태의 반환 형태를 지정할 수 있다. 이를
표현하기 위해 반환 받고자 하는 파일의 형태를 URL 에 명시하도록 OpenAPI 정책을 운영하고 있다.
하지만 앞서 언급한 것과 같이 OpenAPI 를 위한 URL 은 서비스에 대한 직관적이고 명시적인 표현을
위한 목적으로 서비스에 대한 분류체계와 서비스 이름을 표현하기 위해 활용되어야 한다.
따라서 OpenAPI 서비스에 대한 반환 형태를 지정하기 위해서는 다음과 같은 두 가지 형태의 방법이
활용될 수 있다. 첫 번째는 요청 메시지의 HTTP Request 헤더에 반환 타입을 명시하는 방법이다.
GET /pubInfo/parks HTTP/1.1
Accept: application/json
위의 예시는 HTTP Request 헤더에 메시지의 반환 형태를 지정하는 것을 보여주고 있다. 위와 같은
요청에 따라 서버는 서비스에 대한 응답으로써 JSON 형태의 결과를 반환해 준다.
두 번째 방법은 URI 경로 내에 반환 받고자 하는 데이터 타입을 다음과 같이 확장자의 형태로
명시하는 방법이다.
● ‘공원정보 : 마로니에 공원정보 조회’에 대한 JSON 반환 형태 지정 요청 주소

페이지 19 / 91
○ http://OpenAPI.seoul.go.kr:8088/pubInfo/parks/marronnier.json
위의 예제는 마로니에 공원에 대한 상세 정보를 요청하는데 있어서 반환 형태를 JSON 으로 지정하고
있다. 이를 위해 확장자와 같은 형태를 이용하여 서비스에 대한 반환 형태를 표현하고 있다. 이러한 두
가지 형태가 일반적으로 OpenAPI 에서 반환 형태를 지정하기 위한 방법으로 활용되고 있으며,
행정안전부에서 고시한 “공유서비스 개발 가이드라인”에서는 명시적인 URI 기반의 설정 방식을
권고하고 있다.

페이지 20 / 91
1.3. 참조값에 대한 표현
데이터베이스를 효율적으로 운용하기 위해 열거형의 형태를 가진 데이터의 경우 일반적으로 그에
대한 참조코드를 이용하여 참조값 형태로 표현하는 것이 일반적이다. 서울시에서 제공하고 있는
OpenAPI 에서도 이와 같은 형태의 데이터에 대해 참조값을 이용하여 데이터를 제공하는 형태를 가지고
있다.
● ‘대기정보 : 서울시 권역별 오존 예경보’의 출력 값
순번 출력명 출력설명
1 APPLC_DT 발표시간(YYYYMMDDHHMI)
2 FA_ON 예/경보 구분(f : 예보, a : 경보)
3 POLLUTANT 오염물질 종류
4 CAISTEP 예보 등급
5 ALARM_CNDT 행동요령(예보)
6 MSRRGN 권역코드(100 : 도심권 - 종로구, 중구, 용산구
101 : 서북권 - 은평구, 서대문구, 마포구
102 : 동북권 - 성동구, 광진구, 동대문구, 중랑구, 성북구,
강북구, 도봉구, 노원구
103 : 서남권 - 양천구, 강서구, 구로구, 금천구, 영등포구,
동작구, 관악구
104 : 동남권 - 서초구, 강남구, 송파구, 강동구)
7 ALERTSTEP 경보 등급
8 CNDT1 행동요령(경보)

페이지 21 / 91
‘대기정보 : 서울시 권역별 오존 예경보’의 경우 출력 값으로 권역을 의미하는 권역코드를 반환한다.
OpenAPI 를 통해 해당 코드가 어떤 권역을 의미하는지에 대한 정보를 확인할 수 있지만 이러한
형태로만 제공될 경우 사용자 입장에서는 하드코딩 형태로 각각의 해당 코드가 의미하는 지역을 코드에
직접 입력하여 서비스를 개발해야 하는 문제점이 발생할 수 있다. 이에 따라 향후 코드의 수정이나 추가
및 변경에 대해 그에 대응하여 애플리케이션을 수정해야만 하는 번거로움이 발생한다.
또한 어떤 서비스의 경우는 코드값이 반환값에 포함되어 있지만, 해당 코드값에 해당하는 참조값이
어디에 있는지 확인할 수 없는 경우도 있다. 아래의 경우가 그런 경우인데, 분류(구분명, DIV_NAME)에
대한 자세한 정보를 어디에서도 확인할 수 없다.
 장애인 시설정보(http://data.seoul.go.kr/metaview.jsp?id=OA-1220)

페이지 22 / 91
1.3.2 권고 의견
이러한 문제점을 해결하기 위해 다음과 같은 두 가지 형태의 방법이 활용될 수 있을 것으로 판단된다.
가. 참조코드에 대한 값을 질의할 수 있는 OpenAPI 의 제공
첫 번째 방법은 참조코드에 대해 그 코드의 의미를 질의할 수 있는 OpenAPI 를 제공하는 것이다. 예를
들어, 권역에 대한 참조코드를 질의할 수 있는 새로운 OpenAPI 를 정의하고 이를 이용하여 해당
권역코드의 실제 값을 반환 받을 수 있도록 제공한다.
● ‘권역코드 조회’를 위한 OpenAPI 예시
○ http://OpenAPI.seoul.go.kr:8088/code/areas/100.xml
● ‘권역코드 조회’를 위한 OpenAPI 의 결과 예시
위와 같은 형태의 권역코드를 위한 OpenAPI 를 제공함으로써 향후 코드의 추가, 변경 및 삭제에
유연하게 대체할 수 있는 애플리케이션의 개발이 가능할 것으로 판단된다.
나. 참조코드와 함께 해당 참조코드에 대한 값을 반환
또 하나의 다른 방법은 해당 코드와 함께 해당 코드 값의 정보를 함께 반환하는 것이다. 예를 들어,
다음과 같이 권역코드와 함께 실제 값을 반환한다.
● ‘대기정보 : 서울시 권역별 오존 예경보’에 권역코드 값을 포함한 결과 값

페이지 23 / 91
참조에 대한 코드와 함께 코드가 의미하는 값을 제공하기 위해 두 가지 방법 모두가 활용될 것으로
판단되며, 효율적인 정보 제공 및 개발자 입장에서 애플리케이션의 효율성을 높이기 위해 필요한
기능이라 판단된다.

페이지 24 / 91
1.4. 위치정보
1.4.1 현상 및 문제점
최근 지도와 연계한 다양한 형태의 애플리케이션이 증가함에 따라 주소를 포함하고 있는 정보에
대해서는 일반적으로 그에 해당하는 좌표 정보를 함께 제공하고 있다. 이렇게 제공된 좌표 정보는 지도
서비스와의 매쉬업을 통해 사용자에게 보다 직관적인 서비스를 제공할 수 있도록 한다.
서울시의 OpenAPI 도 다수의 OpenAPI 가 주소 정보를 제공하고 있으며, 그에 대한 좌표 정보를 함께
제공하고 있다. 하지만 일부 서비스에 대해서는 좌표 정보를 제공하지 않고 있으며, 보다 효율적인
애플리케이션 개발을 위해서는 좌표 정보를 함께 제공함으로써 개발자의 만족도를 높일 수 있다.
예를 들어, 다음과 같은 ‘물가정보 : 시장마트정보’ OpenAPI 의 경우, 주소 정보는 포함하고 있지만 그에
대한 좌표 정보는 제공되고 있지 않다.
● ‘물가정보 : 시장마트정보’의 결과 값

페이지 25 / 91
1.4.2 권고 의견
개발자의 만족도를 높이고 OpenAPI 에 대한 활용성을 높이기 위해서는 주소 정보가 포함된 결과에
대해서는 항상 그에 대한 좌표 정보도 함께 제공되어야 한다. 물론 네이버나 구글에서 제공하고 있는
변환 API 를 사용하는 것이 가능하기는 하지만, OpenAPI 의 결과에 기본적으로 포함되어 제공될 경우
그러한 번거로움을 줄이고 보다 쉽게 애플리케이션이 개발이 가능할 것으로 판단된다.

페이지 26 / 91
1.5. 데이터 형식(포맷)
현재 서울시에서 제공하고 있는 OpenAPI 의 문제점 중 하나는 데이터 값의 형식이 서비스 별로
상이하다는 것이다. 특히 금액, 주소, 날짜 등의 값 표현 방식이 각 서비스마다 다르게 사용되고 있다. 각
항목에 대해 구체적으로는 다음과 같다.
가. 금액
아래의 [예시 1], [예시 2]와 같이 금액에 대한 결과 값이 단위에 대한 구분이 없으며, 값 만이 반환되기
때문에 개발자가 OpenAPI 설명에 대한 문서를 보거나 액수를 보고 직접 관찰한 후 적당한 단위를
추정하여 애플리케이션을 개발해야 하는 문제가 발생한다. 때문에 수치에 추가적으로 금액의 정확한
단위 정보를 제공하거나 표현 단위를 통일할 필요가 있다.
● 예시 1. 서울시 지출현황_일자별 사업 지출금액 : ListExpenditureBizByDay
○ ( http://data.seoul.go.kr/metaview.jsp?id=OA-1226 )
○ 요청 : /sample/xml/ListExpenditureBizByDay/1/5/
○ 반환(PAY_AMT) : 5250000000 (원 단위로 반환)
● 예시 2. 건설정보_건설알림이 : ListConstructionWorkService
○ 요청 : /sample/xml/ListConstructionWorkService/1/5/
○ 반환(TOT_PJT_AMT) : 47 (억 단위로 반환)
나. 주소

페이지 27 / 91
현재 서울시의 OpenAPI 중 주소를 서비스 요청에 대한 결과로 반환하는 여러 서비스들이 존재한다.
하지만 해당 주소를 표현하는 방법이 서비스에 따라 도로명 새주소, 지번 구주소, 도로명 새주소 + 지번
구주소의 형태로 서로 다르게 제공되고 있다. 이에 대해 모든 OpenAPI 에서 일관된 규칙을 가지고
제공하는 편이 혼동을 줄일 수 있는 방법이라 판단된다.
● 예시 1. 물가정보_시장마트정보 : ListMarketInfoServer
○ 요청 :/sample/xml/ListMarketInfoServer/1/5/
○ 반환(M_MART_ADDR) : 은평구 대조동 98-29 (구 주소 체계 반환)
● 예시 2. 시설정보_장애인 시설정보 : ListDisabledFacilitiesService
○ 요청 : /sample/xml/ListDisabledFacilitiesService/1/5/
○ 반환(ADDR) : 강남구 강남대로 120 길 52(논현동 180-3) 401 호 402 호 (도로명 주소 +
구 주소 모두 반환)
다. 날짜/시각
현재 날짜와 시각을 표현하는데 있어서도 그 표현이 통일되지 않을채 제공되고 있다. 아래의 [예시 1],
[예시 2]에서 반환하는 각 필드가 포함하는 정보의 양이 다름을 감안하더라도(예시 1 은 년도, 월, 일, 시,
분 모두 포함하는 반면 예시 2 는 년도, 월만 포함) 필드의 세부 정보들을 구분하는 구분자의 유무 혹은
종류의 차이로 인해 서비스 개발 시 서비스에 따라 개별적으로 코드를 개발해야 하는 어려움을 겪을 수
있다. 특히 날짜/시각 데이터의 경우 서비스 사용자에게 가공된 상태로 제공될 수 있음을 고려한다면
포맷에 대한 약속이 정해져 있거나 시스템에 의존적이지 않은 날짜/시각 데이터가 제공되어야 할 필요가
있다.
● 예시 1. 대기정보_서울시 미세먼지 예경보 : ForecastWarningMinuteParticleOfDustService
○ 요청 : /sample/xml/ForecastWarningMinuteParticleOfDustService/1/1/
○ 반환(APP_LC) : 201211150900 (년도, 월, 일, 시, 분에 대한 구분자 없이 반환)

페이지 28 / 91
● 예시 2. 물가정보_생필품가격 : ListNecessariesPricesService
○ 요청 : /sample/xml/ListNecessariesPricesService/1/5/
○ 반환(P_YEAR_MONTH) : 2012-11 (년도, 월에 대한 구분자로 - 사용)
1.5.2 권고 의견
가. 금액
금액과 같은 데이터의 표현 형식을 통일하기 위해서는 그에 대한 단위 정보를 제공하거나 기본적으로
사용되는 단위(금액의 경우 ‘원’)를 이용하여 그 값을 통일성 있게 제공하여야 한다. 예를 들어, 금액에
대한 수치 데이터, 단위 데이터를 같이 제공한다면 OpenAPI 를 사용하는 개발자는 NUMBER 필드와
UNIT 필드를 조합해 정확한 금액 + 단위의 액수를 서비스할 수 있게 된다.
● 예시 1 에 대한 권고의견
서울시 일자별 사업비 지출금액 항목이라는 것을 고려하였을 때 단위는 ‘원’단위의 금액으로 추정된다.
NUMBER 라는 하위 노드를 추가하여 수치 금액에 대한 정보를 전달하고, NUMBER 와 동일한 레벨의
노드에 UNIT 이라는 하위 노드를 추가하여 수치 금액의 단위에 대한 정보를 분리해서 전달한다면 정확한
금액 정보에 대한 제공이 이루어질 수 있다.
● 예시 2 에 대한 권고의견

페이지 29 / 91
건설사업 예산 금액 항목이라는 것을 고려하였을 때 47 이라는 수치에 대한 단위는 ‘억 원'단위의
금액으로 추정된다. NUMBER 라는 하위 노드를 추가하여 수치 금액에 대한 정보를 전달하고,
NUMBER 와 동일한 레벨의 노드에 UNIT 이라는 하위 노드를 추가하여 수치 금액의 단위에 대한 정보를
분리해서 전달한다면 정확한 금액 정보에 대한 제공이 이루어질 수 있다.
나. 주소
현재 정부의 주도하에 도로명 새주소의 사용을 독려하고, 이에 따라 도로명 새주소의 사용이 확산되고
있기는 하지만, 아직까지 지번 구주소가 많이 활용되고 있는 과도기적 단계에 있다. 따라서 아직까지는
새주소와 구주소를 모두 병기하는 방식으로 통일하는 것이 보다 효율적으로 판단된다. 또한 둘에 대한
명확한 구분을 하여 결과 값을 반환하여야 한다.
다. 날짜/시각
날짜와 시각 데이터에 대한 통일성을 위해서는 날짜/시각 데이터는 Unix Timestamp 형태로 결과값을
제공하거나 yyyy-MM-dd HH:mm:ss 와 같이 구분자에 대한 통일된 규칙 정의가 필요하다.
● 권고의견(Unix Timestamp)
아래와 같이 Unix Timestamp 로 날짜/시각 정보를 전달하게 되면 OpenAPI 사용자가 날짜/시각
데이터에 대한 포맷을 신경쓰지 않고 정확한 데이터를 취득할 수 있고, 필요한 경우 자신이 원하는
디스플레이 포맷으로 변경하기가 매우 용이하다. 특히, 시간대까지 고려하여야 할 필요가 있는 경우

페이지 30 / 91
시차를 가감하여 날짜/시간 데이터를 재가공해야 하는데 Unix Timestamp 로 제공될 경우 연산이
용이하다는 장점을 가질 수 있다.
하지만 ‘예시 2’의 “2012-11”과 같이 축약된 날짜/시각 데이터만을 전달하고자 하는 경우 “2012-11-01
00:00:00”에 대한 Unix Timestamp 인 “1351728000”을 전달하고 연도, 월 데이터만을 추출해 사용할 것을
OpenAPI 문서에 별도로 표기해야 하는 단점도 존재한다.
● 예시 1
● 예시 2
날짜와 시각에 대한 데이터 표현을 위해 yyyy-MM-dd HH:mm:ss 형식을 사용할 경우 ‘예시 2’와 같이
축약된 날짜/시각 데이터를 전달하는 경우에도 네트웍 사용의 낭비를 방지할 수 있고, Human
Readable 한 데이터를 전달할 수 있어 취득한 데이터를 그대로 사용하고자 하는 경우 큰 장점이 있다.
다만, 데이터를 재가공하거나 디스플레이 포맷을 변경해야 할 필요가 있을 경우 OpenAPI 사용자가
정해진 포맷을 바탕으로 데이터를 파싱하여 연산하거나 포맷을 변경해야 하는 번거로움이 있는 것이
단점이다.
● 예시 1
● 예시 2

페이지 31 / 91
1.6. 메타데이터 디자인
서울시에서 제공하고 있는 OpenAPI 중 일부는 리스트 형태의 값을 결과로 제공하고 있다. 예를 들어,
다음과 같은 ‘서울시립미술과 전시정보’ OpenAPI 는 해당 작품에 대해 한 명 이상의 작가가 결과에
포함되어 있다.
● 서울시립미술관_전시정보 : ListExhibitionOfSeoulMOAService
서울시립미술관_전시정보의 출품작가 필드는 다수의 출품 작가를 표현하기 위해 콤마(,)로 구분한
작가의 이름을 나열한 문자열을 반환하고 있다. 이와 같은 제공 방식은 (1) 출품작가와 관련한
메타데이터를 모두 소실한 상태로 제공되는 문제와 (2) OpenAPI 사용자가 콤마(,)라는 구분자를 기준으로
문자열을 파싱해야 하는 문제점을 가지고 있다.
출품작가 관련 메타데이터가 소실된 문제는 출품작가를 매개로 하여 다른 OpenAPI 서비스 및
데이터와의 연관관계 확장을 어렵게 만드는 요인 중 하나이다. 또한 결과의 기본적 구조를 위한 파싱
이외에 추가적으로 파싱(Parsing)을 해야 하는 문제는 개발 리소스를 증가시키고, 영문명의 경우 간혹
콤마(,)가 포함된 경우가 있기 때문에 데이터 가공의 부정확성을 일으킬 수 있다.
1.6.2 권고 의견
앞서 언급한 문제점을 해결하기 위한 대안으로 리스트와 같은 형태를 가지고 있는 반환 값은 리스트
형태를 표현하기 위한 구조를 이용하여 리스트형 데이터 표현을 제안한다. 출품작가들의 인원수와 함께

페이지 32 / 91
출품작가에 대한 메타데이터를 포함한 리스트를 전달하는 방식으로 데이터를 제공할 경우 출품작가의
메타데이터를 활용할 수 있게 된다. 또한, 출품작가에 대한 ID 와 같은 정보를 추가적으로 쉽게 제공할 수
있으며, 이를 통해 다른 OpenAPI 서비스나 데이터 셋과의 연계 및 확장이 용이하다는 장점이 있다.

페이지 33 / 91
1.7. 에러 레포팅
현재 서울시에서 제공하고 있는 OpenAPI 는 다양한 형태의 에러에 대해 에러코드를 이용하여 값을
반환하고 있다. 하지만 결과가 없는 경우에 대해서는 다음과 같이 ‘해당하는 데이터가 없습니다.’라는
단순한 문자열 만을 결과로 제공하고 있다. 애플리케이션 입장에서 동일한 형태의 결과 분석을 위해서는
결과가 없는 경우 일지라도 OpenAPI 를 통해 요청한 결과의 형태로 에러 메시지를 반환해야 한다.
● 요청한 질의에 대한 결과가 없을 경우의 응답 결과
또한 다음의 그림에서 살펴보는 것과 같이 결과가 없는 경우에 대해 정상적으로 처리되었음을 의미하는
200 응답코드가 반환되는 것을 확인할 수 있다. HTTP 헤더의 응답코드 200 은 해당 요청이 정상적으로
처리되었음을 의미하는 것이며, 잘못된 요청에 대해서는 그에 적절한 응답코드를 반환해야만 한다.
● 요청한 질의에 대한 결과가 없을 경우의 HTTP 헤더

페이지 34 / 91
1.7.2 권고 의견
OpenAPI 에 대한 결과는 에러가 발생할 경우라도 사용자가 지정한 형태로 결과가 반환되어야 하며,
그에 적절한 에러코드가 HTTP 헤더에 명시되어 있어야 한다.
HTTP 헤더의 204 응답코드는 올바른 요청을 하였지만 그에 대해 반환할 결과가 없음을 의미하는
코드이다. 따라서 반환 결과가 없을 경우에는 위와 같은 형태의 HTTP 헤더를 반환하는 것이 적절하다.
● HTTP 헤더에 올바른 응답코드의 적용
Request URL:http://OpenAPI.seoul.go.kr:8088/sample/xml/ForecastWarningOzoneService/101/105/
Request Method:GET
Status Code:204 OK
또한 다음과 같이 사용자가 요청한 형태의 반환 결과를 제공하여야 한다.
● 사용자가 요청한 타입에 적절한 형태의 에러 메시지 반환

페이지 35 / 91
이러한 형태로 결과를 반환함에 따라 사용자는 HTTP 헤더의 응답코드를 통해 해당하는 결과가 없다는
것을 파악할 수 있으며, 반환된 결과의 본문이 사용자가 요청했던 형태로 제공됨에 따라 동일한 처리
방법을 이용하여 에러 처리가 가능하다.

페이지 36 / 91
1.8. 검색 기능
현재 “서울시-열린데이터광장”에서 서비스되는 대부분의 OpenAPI 들은 List 형식으로 결과값을
반환하며 요청시작건수와 요청종료건수로 한번에 반환 받을 수 있는 사이즈를 제한하고 있다. 또한
필터할 수 있는 값으로 강남구, 동작구 등의 자치 값을 조건으로 둘 수 있도록 되어 있다. 아래
건설알림이의 예시를 보자.
● 건설알림이(http://data.seoul.go.kr/metaview.jsp?id=OA-1222)
위의 그림에서 알 수 있듯이 건설알림이 서비스에 조건으로 둘 수 있는 인자들은 자치구 구분과
프로젝트 종료여부, 요청건수에 대한 것뿐이다. 하지만 추가적으로 지하철 공사와 관련된 종료 또는
진행중인 건설알림이 정보가 필요할 경우 이를 필터링할 수 있는 방법이 현재는 없다. 물론 공사구분과
같은 형식으로 해당 분류 또는 코드 값을 추가해도 되지만, 모든 서비스에 사용자가 필요하다고 요청하는
모든 필드를 추가 또는 반영하는 것은 거의 불가능에 가깝다. 다만, 현재 제공되는 서비스에서 이를
필터할 수 있는 방법을 제공하면 가능하다.
1.8.2 권고 의견

페이지 37 / 91
모든 경우의 필터를 고려할 수 없기 때문에 각각의 해당하는 필드명에 조건으로 특정 단어를 포함 또는
제거 형식을 둘 수 있도록 하면 서비스를 개발하는 입장에서 좀 더 유연하게 해당 서비스를 활용할 수
있다. 현재 건설알림이는 아래와 같은 출력 값이 있다.
예를 들어, 건설알림이 서비스에서 프로젝트 명에 특정 단어를 포함하는 결과만 반환 받고자 하는 경우
다음의 예제에서와 같이 프로젝트 명을 필터링 할 수 있는 기능을 제공하는 것이 가능하며, 앞서 리스트
형식은 개체를 다루지 않기 때문에 Query String 형식으로 제공하면 된다. Query String 형식으로
요청인자를 보낼 경우 다음과 같은 형태로 제공될 수 있다.
● http://OpenAPI.seoul.go.kr:8088/id=sample&type=xml&serviceName=ListConstructionWorkSer
vice&start=1&end=5&FCT_F25NM=종로구&PJT_NAME=지하철
현재와 같은 방식일 경우에는 아래와 같이 검색 필드를 “PJT_NAME=지하철”과 같은 형식으로 지정할
수 있다.
● http://OpenAPI.seoul.go.kr:8088/sample/xml/ListConstructionWorkService/1/5/종로구/PJT_NAM
E=지하철

페이지 38 / 91
물론 모든 필드에 이를 부여한다는 것은, 성능과 운영에 악영향을 미칠 수 있으므로 설명(Description)
필드는 제외한다거나, 용어체계가 정립될 경우 특정 필드는 검색 조건이 가능한 필드라고 미리 정의해
놓는 방법도 고려해 볼 수 있을 것 것이다. 개발자 입장에서는 데이터를 받아와서 필터링을 하는 것도
가능하지만 해당 서버에서 필터링을 한 후 조건을 만족하는 값만 제공해 주는 것이 주고 받는 데이터
양이나 성능을 고려해 봤을 때 더욱 좋을 것이라 생각된다.

페이지 39 / 91
1.9. OpenAPI 요청자 인증 관리
현재 서울시 OpenAPI 는 각 개인에 인증키를 항당하여 OpenAPI 에 대한 사용 권한을 부여하고 있다.
서울시 OpenAPI 를 이용하기 위해 사용자가 인증키를 요청하면 아래 그림과 같이 인증키가 생성되어
사용할 수 있게 된다.
발급된 인증키는 OpenAPI 서비스를 요청할 때 반드시 포함되어야 하는 필수 매개변수이며, 서비스
요청에 대한 URL 을 구성하는 하나의 요소로 활용된다. 클라이언트 브라우저에서 OpenAPI 에 직접적인
호출이 발생하는 경우 요청 주소 및 인증정보와 같은 정보들이 URL 을 통해 다른 이용자에게 쉽게
노출되어 서비스가 이루어진다. 이 공개된 인증키를 타인이 도용하게 되는 경우 OpenAPI 운영측에서는
요청에 사용된 인증키 정보에 대해 실제 어떤 사용자가 요청을 한 것인지 정확한 정보를 파악하기
어려워 부작용이 있을 수 있다.
또한, 실제 1 초단위로 OpenAPI 요청을 수행하는 프로그램을 통해 확인해 본 결과 약 25,000 번의
요청이 연속적으로 수행되었지만 해당 인증키에 대한 요청을 중단하는 상황이 나타나지 않았다. 인증키
별로 OpenAPI 요청 수 제한을 두지 않을 경우, 악의적인 사용자에 의해 OpenAPI 서비스가 과부하에
빠져 전체 서비스의 성능에 악영향을 끼칠 소지가 있다.
1.9.2 권고 의견

페이지 40 / 91
OpenAPI 로부터 정보를 요청하는 서비스의 종류에 따라 다를 수 있지만 인증키는 외부에 노출되어 다른
사용자가 도용할 가능성이 충분하다는 가정하에 관리가 되어야 할 필요가 있다. 다음 그림은 주요
포털업체에서 OpenAPI 인증키를 관리하는 페이지의 화면인데, 발급 시점부터 인증키가 실제 사용될
URL 베이스(base)를 입력하게하여 그 외의 도메인에서부터 오는 요청은 응답해주지 않는 방법을 택하고
있다. 또한 발급된 인증키를 삭제할 수도 있어 도용이 의심되는 경우 인증키를 삭제하고 재발급 받아
변경할 수 있는 관리 기능을 제공하고 있다.
그리고 OpenAPI 서비스에 대한 지나친 과부하를 방지하기 위해 일별 100,000 개의 요청으로 상한
건수를 제한하는 것 또한 성능에 대한 문제 가능성을 방지할 수 있는 방법이라 할 수 있다.

페이지 41 / 91
1.10. 데이터 생성 기준 일자
현재 서울시에서 제공하고 있는 OpenAPI 중에는 그 결과가 특정 시기 단위로 업데이트되어 관리될
필요가 있는 서비스들이 존재하고 있다. 이러한 시기에 따라 변하는 데이터의 경우 생성 시점을 알지
못하면 활용할 수 없다. 예를 들어 “전통시장 : 전통시장 정보
( http://data.seoul.go.kr/metaview.jsp?id=OA-1176 )"는 입력 등록일자는 있으나 조사일시 데이터는
없다.
‘지역별 수질 현황 정보( http://data.seoul.go.kr/metaview.jsp?id=OA-130 )’는 매일 30 분 단위로
정기적으로 업데이트되는 데이터인데 현재 측정일시 정보를 제공하지 않는다. 따라서 사용자는 최근
30 분내에 측정한 데이터라고 추측해야만 한다.

페이지 42 / 91
데이터에는 생성시점을 명확하게 표기하는게 필요하다. 생성 시점이 명확하지 않은 데이터로 서비스를
개발할 경우 그 차이로 인해 이용자가 불편을 겪게 되고, 서비스 개발자와 이용자간의 불필요한 분쟁이
발생할 수도 있다.
1.10.2 권고 의견
‘생필품 가격( http://data.seoul.go.kr/metaview.jsp?id=OA-1170 )’이나 ‘개인 서비스 요금
정보( http://data.seoul.go.kr/metaview.jsp?id=OA-1169 )’ 같은 비정기 조사 데이터의 경우 메타데이터에
데이터를 생성한 시점(조사시점)을 포함하는 것이 필요하다.
‘ 지역별 수질 현황 정보( http://data.seoul.go.kr/metaview.jsp?id=OA-130 )’ 같은 정기 측정 데이터는
각각의 데이터에 측정 일시라는 항목을 추가하여 생성 시점을 포함하는 것을 권고한다.

페이지 43 / 91
2. 작은 이슈 (Minor Issue)
2.1. API 에 대한 API
OpenAPI 서비스는 예기치 못한 상황을 맞아서 서비스를 제공하지 못할 수도 있다. 또한 더 이상
데이터를 업데이트하지 않는다거나, 혹은 분기별 조사가 마무리되어 새로운 데이터가 업데이트되었을
수도 있다.
이들 개별 API 와 관련된 상태 정보 및 부가 정보를 API 의 메타데이타라고 한다. 현재 OpenAPI
서비스는 다음의 메타데이터를 제공한다.
● 분류체계
● 담당자와 담당자 연락처 : 이름, 부서, 연락처
● 제공기관과 부서
● 저작권자와 저작권자 연락처
● 태그
● URL
● 등록일자
이들 메타데이터는 두 가지 측면에서 필요한 정보가 누락되어 있다. (1) 현재 API 상태를 알 수가 없고,
(2) 메터데이터를 API 형태로 제공하지 않는다는 점이다.
현재 OpenAPI 의 상태를 알 수 없으므로 서비스 개발자는 “잘 작동할 것이다"라고 믿고 개발을
진행해야 하며, 오류가 발생할 시 원인을 찾는데 어려움을 겪게 될 수 있다. OpenAPI 형태로 제공되지
않는 까닭에 등록일자가 업데이트되어도 서비스 개발자가 API 사이트로 찾아오지 않는 한 그 사실을 알
수가 없다.
2.1.2 권고 의견

페이지 44 / 91
서비스에 대한 메타데이터를 OpenAPI 형태로 제공할 경우 서비스 개발자가 얻게 되는 이점은 다음과
같다.
● API 상태를 확인하고 오류 상태를 확인하며 대비할 수 있다.
● 데이터의 최종 업데이트 날짜를 확인하고 기존에 가져온 데이터와 비교해서, 데이터를 다시
가져올지 여부를 결정할 수 있다.
● 이러한 작업을 자동으로 처리할 수 있다.
따라서 현재의 메타데이터에 다음의 데이터를 추가하여 개별 OpenAPI 에 대한 의 메타데이터를
반환하는 OpenAPI 를 제공하는 것이 바람직하다.
● 서비스의 상태 : 정상, 일시 중지, 제공 중단
● 최종 업데이트 일 : 날짜 형식
● 전체 데이터 : 건수

페이지 45 / 91
2.2. 페이징 방식 개선
현재 서울시에서 제공하고 있는 OpenAPI 중 데이터 목록을 조회하는 서비스는 요청시작건수,
요청종료건수를 필수 입력 값으로 이용해 조회할 목록의 범위를 결정할 수 있다.
하지만 이 같은 경우 OpenAPI 를 활용한 서비스에서 페이징을 구현할 때 항상 현재 사용자가 보고 있는
데이터의 시작, 종료 인덱스를 기억하고 있어야 하고 다음 요청에 대한 시작, 종료 인덱스를 계산해
주어야 하는 불편함이 존재한다.
현실적으로 페이징이 될 만큼 많은 데이터가 존재하는 OpenAPI 요청에 대해서 일반적으로 가장 첫
번째 쿼리가 0 번째부터 시작하며, 이러한 OpenAPI 가 제공하는 목록에 대한 페이징 기능이 주로 특정
건수만큼을 반복적으로 추가로 조회해 누적해가는 방식으로 진화함에 따라 매 요청마다 시작, 끝
인덱스를 계산해야 하는 것은 개발자에게 번거로운 작업일 수 있다.
특히, OpenAPI 서비스 측에서는 성능적인 문제를 고려하여 응답 건수에 대한 상한 건수 제한을 두어야
하는데, 이 또한 인덱스를 계산하는 과정에 반영이 되어야 한다. 때문에 OpenAPI 서비스의 운영 중
정책이 바뀌어 응답 건수에 대한 상한값이 변경된다면 기존에 작성된 소스들이 변경되어야 하는 문제가
발생할 수 있다.
2.2.2 권고 의견
다음의 그림은 Facebook API 에서 리스트형 데이터를 요청했을 때 응답된 json 데이터의 일부를 캡쳐한
것이다. 모든 응답마다 paging 이라는 필드에 previous, next 요청 url 을 반환하여 요청자가 다음 요청에
대해서 시작, 종료 인덱스를 계산할 필요없이 직접 호출을 할 수 있다. 이 경우 OpenAPI 에서 제한하는
응답 건수 상한보다 더 많은 요청을 하더라도 다음 요청을 위한 계산을 다시 할 필요가 없고, 운영 도중
상한 건수에 대한 정책이 바뀌더라도 계산 로직을 수정하지 않아도 되는 장점을 가지고 있다.

페이지 47 / 91
2.3. 개별 OpenAPI URL
현재 서울열린데이터광장 서비스는 OpenAPI 의 분류 목록이나 개별 OpenAPI 에 대한 상세 페이지로
자바스크립트를 활용해 브라우징을 한다. 따라서 브라우저의 URL 은 고정된 채로 브라우저 내의 내용만
바뀌는데 이 경우 개별 API 의 URL 을 알 수가 없다.
예를 들어 “서울시 지출 현황 : 일별 지출 총액 ( http://data.seoul.go.kr/metaview.jsp?id=OA-1224 )”
API 의 메타데이터 URL 은 알 수가 없다.
즉, 개별 OpenAPI 의 URL 이나 목록, 분류별 URL 을 제공하지 않고, 다음 세 가지의 URL 만을 유지하는
형태라 사용하기 불편하다.
● 목록 : http://data.seoul.go.kr/openinf/dataset/datasetlist.jsp
● 메타데이터 : http://data.seoul.go.kr/openinf/dataset/datasetview.jsp
● OpenAPI : http://data.seoul.go.kr/openinf/OpenAPI/OpenAPIview.jsp
2.3.2 권고 의견
목록과 분류별로 바로 접근할 수 있는 URL 과 개별 OpenAPI 의 메타데이터로 접근할 수 있는 URL 이
필요하고, 해당 URL 을 통해 서비스 설명 페이지에 대한 접근이 가능하도록 하여 사용자가 인지할 수
있어야 한다.
예를 들어 환경 분류와 서울시 환경 경보 OpenAPI 의 경우 다음과 같이 URL 을 정의할 수 있다.
● 환경 분류 : http://data.seoul.go.kr/openinf/dataset/datasetlist.jsp?infoType=1002
● 서울시 환경 경보 API 메타데이터뷰 :
http://data.seoul.go.kr/openinf/dataset/datasetview.jsp ?service=WarningYellowDustService

페이지 48 / 91
2.4. CDATA 남용
현재 제공되는 서울시-열린데이터광장의 OpenAPI 는 반환 값 형식으로 XML 형식을 지원하고 있다.
XML 형식의 반환값 에는 모든 태그가 CDATA 섹션을 이용하고 있는데, XML 에서 CDATA
섹션(<![CDATA[ ~ ]]>)은, ‘<’ 와 ‘>’ 기호 같은 특수문자를 포함하기 위한 목적으로 사용된다. 하지만
현재 서울시의 결과값 경우에는 특수문자를 포함하지 않는 모든 필드에 CDATA 를 이용하고 있다. 아래는
“장애인 시설정보”의 예시이다.
○ 출력값

페이지 49 / 91
○ http://OpenAPI.seoul.go.kr:8088/sample/xml/ListDisabledFacilitiesService/1/5/ 결과
예시
위의 출력값 설명과 결과 예시를 볼때, AREA_NAME(구별)은 자치구명을 의미하는 듯 하다. 기본적으로
자치구명은 특수문자를 사용하지 않을 것이다. 또한 TEL(전화번호), FAX(팩스)도 그럴것이며,
좌표정표(BLDG_X, BLDG_Y)도 특수문자는 필요없을 것이다.
2.4.2 권고 의견
CDATA 는 XML 형식의 특수성으로 특수문자를 사용하여야 할 경우 이용하는 부분이다. 프래그래밍
언어와 파서에 따라, CDATA 파싱을 지원하지 않는 경우도 있다. 물론 지원하는 경우도 있지만, CDATA 가
필요하지 않은 섹션에 CDATA 를 남용하는 것은 올바른 방법이 아니다. 따라서 특수문자가 포함될 수
있는 필드를 선별하여 CDATA 남용을 방지함으로써 XML 의 취지에 보다 부합하게 활용될 수 있을
것으로 판단된다.

페이지 50 / 91
III. OpenAPI 검증 - 서비스별
1. 일반행정, 교통, 안전
1.1. 120 상담정보 : 자주묻는질문 자치구 업무매뉴얼 상세 조회
1.1.1 분류체계필터
● 일반행정
1.1.2. 등록일자
● 2012.05.11
1.1.3. OpenAPI 설명
● http://data.seoul.go.kr/metaview.jsp?id=OA-1130
1.1.4. 항목별 의견
● 업무명(JOB_NM)에 대한 구분이 있으면 분류가 용이할 수 있음
● FAQ 구분(FAQ_TP)에 대한 참조 정보가 없음
1.2. 지하철정보 : 호선별 지하철 첫차와 막차 정보 검색
● 교통
1.2.2. 등록일자
● 2012.07.30

페이지 51 / 91
1.2.4. 항목별 의견
● WEEK_TAG(요일), INPUT_TAG(상/하행선), FR_CODE(외부코드), STATION_CD(전철역코드) 등에
대한 설명 및 참조값 연결이 없음
● 호선&역명 조합으로 API 에 접근할 수 있으면 좋을 것 같음
1.3. 교통정보 : 교통 돌발상황 조회
● 교통
1.3.2. 등록일자
● 2012.04.13
1.3.4. 항목별 의견
● 담당 기관 및 담당과 정보가 없음.
● 예정인 공사와 지난 사고 등의 구분이 구체적이지 못함
● 예정인 공사와 사고 등으로 인한 정체 정보는 서비스가 구분되는 것이 좋을 듯 함.
1.4. 분실물정보 : 보관 분실물 사진 이미지
● 교통
1.4.2. 등록일자
● 2011.12.15

페이지 52 / 91
1.4.4. 항목별 의견
● 해당하는 데이터가 없습니다.
● 분실물 ID 가 서비스 호출의 필수 값이며, 분실물 ID 를 알아야 해당 서비스를 사용할 수 있음.
● “분실물정보 : 보관 분실물 목록 조회” 서비스와 연동하여 활용할 수 있지만, 조회된 목록의
대부분이 사진정보를 제공하지 않고 있음
○ http://openapi.seoul.go.kr:8088/sample/xml/SearchLostArticleImageService/1/5/590997
89
94
90
1.5. 분실물정보 : 보관 분실물 목록 조회
● 교통
1.5.2. 등록일자
● 2011.12.15
1.5.4. 항목별 의견
● 해당하는 데이터가 없습니다.
● 분실물 ID 가 서비스 호출의 필수 값이며, 분실물 ID 를 알아야 해당 서비스를 사용할 수 있음.
● CODE(습득물품코드)가 요청인자에는 있지만 제공되는 반환 값에는 없음.
● CODE(습득물품코드)는 필수 요정인자가 아니어도 될 것 같음.
● CODE(습득물품코드)가 지하철인데, 수령가능장소(TAKE_PLACE)가 대부분 “회사내 분실센터”라고
나오고 있음. “회사내 분실센터”가 구체적으로 어디이며, 어떤 것인지에 대한 설명이 부족하며,

페이지 53 / 91
습득물품코드가 왜 지하철인지 알 수 없음.
(http://openapi.seoul.go.kr:8088/sample/xml/ListLostArticleService/6/10/b2/)
1.6. 분실물정보 : 보관 분실물 정보
● 교통
1.6.2. 등록일자
● 2011.12.15
1.6.4. 항목별 의견
● 1.5 분실물정보 : 보관 분실물 목록 조회 와 연동하여 활용 가능
● 1.4 보관 분실물 사진 이미지, 1.5 보관 분실물 목록 조회 서비스와 분리되지 않는 것이 활용도가
더 좋아 보임
1.7. 지하철정보 : 역명 지하철역 검색 기능
● 교통
1.7.2. 등록일자
● 2011.12.15
1.7.4. 항목별 의견

페이지 54 / 91
● http://openapi.seoul.go.kr:8088/sample/xml/SearchInfoBySubwayNameService/1/5/신대방
이라고 요청할 경우 “신대방”만 검색됨, “신대방”이라는 문자를 포함하는 “신대방역삼거리”등도
같이 검색되면 좋을 듯 함
● 좌표정보가 없음 - 역코드로 지하철역 위치조회 서비스와 분리되지 않아도 될 듯 함
1.8. 수해예방정보 : 서울시 하천 수위 정보
● 안전
1.8.2. 등록일자
● 2011.05.18
1.8.4. 항목별 의견
● 서비스를 요청할 때 “구청코드”로만 요청이 가능하며, “구청명”으로는 요청이 불가능 함.

페이지 55 / 91
2. 환경, 보건, 복지, 산업경제
2.1 대기정보 : 서울시 미세먼지 예경보
● 환경
2.1.2 등록일자
● 2012.09.07
2.1.3 OpenAPI 설명
2.1.4 항목별 의견
● 날짜형식이 YYYYMMDDHHMI 임. 표준 형식으로 바꾸는 것을 권고함.
2.2 대기정보 : 서울시 권역별 오존 예경보
● 환경
2.2.2 등록일자
● 2012.09.07
● 날짜형식이 YYYYMMDDHHMI 임. 표준 형식으로 바꾸는 것을 권고함.
● 서울시에서 사용하는 권역코드 고유값이 있다면, 권역코드를 그 값으로 바꾸는 것을 권고함.

페이지 56 / 91
2.3 대기정보 : 서울시 황사 경보
● 환경
2.3.2 등록일자
● 2012.09.07
● 데이터가 나오지 않음.
2.4 대기정보 : 실시간 서울 대기환경 평균
● 환경
2.4.2 등록일자
● 2012.08.27
● 통합대기환경지수에 관한 설명을 메타데이터에 추가하는 것을 권고함. ( 참조: 통합대기환경지수
http://air.gb.go.kr/at_environment/CAI.jsp )
● 데이터 결과값에 단위 정보를 추가하는 것을 권고함. ( XML 의 경우 속성으로 지정 )

페이지 57 / 91
2.5 대기정보 : 실시간 자치구별 대기환경정보
● 환경
2.5.2 등록일자
● 2012.08.27
● 파라메터로 사용해야 하는 측정소 행정코드 정보를 확인하는 API 를 메타데이터에 명시할 것을
권고함 ( 2.6 대기정보 : 대기 지역 구 검색 )
● 측정소 행정코드 정보가 서울시 API 에서 공통적으로 사용할 수 있는 코드인지 확인이 필요함.
● 데이터 결과값에 단위 정보를 추가하는 것을 권고함. ( XML 의 경우 속성으로 지정 )
2.6 대기정보 : 대기 지역 구 검색
● 환경
2.6.2 등록일자
● 2012.08.27
● 서울시의 다른 API 와 공통적으로 사용하는 코드체계를 사용할 것을 권고함.

페이지 58 / 91
2.7 물가정보 : 개인서비스요금정보
● 환경 > 생활환경
2.7.2 등록일자
● 2012.06.15
● 지오코드값이 필요함
● 업종코드와 업종, 동, 품목코드에서 사용하는 값이 나타내는 의미를 메타데이터 항목에 설명하고,
코드를 서울시 API 가 공통적으로 사용하는 체계를 사용할 것을 권고함.
● 현재는 같은 업소의 개별 품목을 각각의 항목으로 반환하고 있음. 업소별 메뉴를 묶어서
목록으로 구성한 후 업소 항목 안에 포함시키는 방식으로 데이터를 구성하기를 권고함.
2.8 청소차량정보 : 서울시 도로분진 청소현황
● 환경 > 생활환경
2.8.2 등록일자
● 2012.05.30

페이지 59 / 91
● 데이터가 나오지 않음
2.9 공원정보 : 공원 프로그램 총 건수 조회
● 환경 > 공원녹지
2.9.2 등록일자
● 2012.01.03
● 의견 없음
2.10 공원정보 : 공원 프로그램 정보조회
2.10.2 등록일자
● 2012.01.03

페이지 60 / 91
2.10.4 항목별 의견
● 공원 항목 안에 같은 공원의 프로그램을 목록으로 구성하는 메타 데이터 구성 방식을 취하거나,
프로그램 정보를 항목으로 제공하고 공원 관련 정보는 존재하는 다른 API 에서 제공하기를
권고함. 현재는 프로그램안에 공원 정보를 여러번 제공함.
● EDUTIME 을 10,11,12 형식과 15:00~15:50 형식을 기준 없이 제공함. 형식을 맞출 것을 권고함.
2.11 공원정보 : 공원정보 총 건수 조회
2.11.2 등록일자
● 2012.01.03
2.11.4 항목별 의견
● 의견 없음
2.12 공원정보 : 공원정보 정보조회
2.12.2 등록일자
● 2012.01.03

페이지 61 / 91
2.12.4 항목별 의견
● 전화번호 중 02-731-0395~7/0585 형태로 제공되는 데이터가 있음. 개별 전화번호를 별도의
항목으로 구성해 제공할 것을 권고함.
● 지역 정보를 ‘강북구'등의 문자열에 더해 서울시 API 가 사용하는 공통 코드값을 추가로 제공할
것을 권고함.
2.13 수질정보 : 수질 지역 목록 구 검색 기능
● 환경 > 수질환경
2.13.2 등록일자
● 2011.12.15
2.13.4 항목별 의견
● 구의 코드값은 서울시 API 가 사용하는 공통 코드값을 사용할 것을 권고함.
2.14 수질정보 : 수질 지역 목록 동 검색
2.14.2 등록일자
● 2011.12.15

페이지 62 / 91
2.14.4 항목별 의견
● 동의 코드값은 서울시 API 가 사용하는 공통 코드값을 사용할 것을 권고 함.
2.15 수질정보 : 지역별 수질 현황 정보 제공
2.15.2 등록일자
● 2011.12.15
2.15.4 항목별 의견
● 파라미터에 사용하는 값을 참조할 수 있도록 메타데이터에 2.13 과 2.15 의 수질 지역 목록 구와
동 검색 API 정보를 추가할 것을 권고 함.
● 전기전도도, PH, 잔류염소, 탁도, 수온 항목에 단위 값에 해당하는 정보를 추가로 제공할 것을
권고 함. XML 의 경우 unit 속성으로 제공하는 것을 권고 함.
2.16 식품위생정보 : 서울안심먹거리 목록
● 보건 > 식품

페이지 63 / 91
2.16.2 등록일자
● 2012.07.25
2.16.4 항목별 의견
● 데이터를 생성한 날짜 혹은 안심먹거리 지정 기준 일자를 메타정보에 추가할 것을 권고함.
● 인증분야에 관한 설명이나 설명을 볼 수 있는 페이지의 URL 을 메타정보에 추가할 것을 권고함.
● CTF_GU 필드에 새주소가 아닌 ‘1’이라는 값만 들어 있음
● 좌표값인 CTF_X, CTF_Y 를 서울시 API 에서 지정하는 표준 좌표 체계 형식으로 바꾸거나 추가할
것을 권고함.

페이지 64 / 91
3. 문화관광, 도시관리
3.1 문화정보 - 문화시설 테마분류 목록 제공
● 문화관광
3.1.2. 등록일자
● 2012.04.02
3.1.4. 항목별 의견
● 문화시설 위치 좌표 제공 필요(공통의견)
● SUBJCODE, THEMECODE 에 대한 명칭 조회 서비스는 제공되고 있음(공통의견)
● 위치 주소 정보가 구 주소 체계로만 나옴(공통의견)
3.2 문화정보 - 문화시설 교통정보 목록 제공
● 문화관광
3.2.2. 등록일자
● 2012.04.02

페이지 65 / 91
3.2.4. 항목별 의견
● 필요 데이터
● 주차 가능 여부
● 인근 이용가능한 주차장 정보
● TRAFTYPE 에 대한 명칭 조회 서비스 연동 필요(공통의견)
● TRAFTYPE, TRAFINFO 에 대한 분리된 메타데이터 제공 필요(공통의견,) TRAFTYPE 이 A(지하철,
공항버스)여서 TRAFINFO 에 “1 노선(시청)”이라는 지하철 정보와 “602”라는 공항버스 노선
정보가 콤마(,)로 구분되어 같이 제공되고 있음
3.3 문화정보 - 문화시설 상세정보 제공
● 문화관광
3.3.2. 등록일자
● 2012.04.02
3.3.4. 항목별 의견
● MNG_CODE 관리번호의 사용 용도를 알 수 없음
● SAN_YN 의 값이 Y/N 둘 중 어떤 값도 아닌 상태로 비어있음
● THEMECODE 는 다른 API 에서도 사용하는데, 값이 비어있음
● BON_BUN, GU_BUN 의 의미/사용 용도를 알 수 없고 값이 비어있음
● OPEN_DAY, SEAT_CNT 값이 비어있음
● X_COORD, Y_COORD 에 대한 좌표계를 알 수 없음
3.4 문화정보 - 문화시설 주소 검색

페이지 66 / 91
● 문화관광
3.4.2. 등록일자
● 2012.04.02
3.4.4. 항목별 의견
● 위치 좌표 정보(공통의견)
● 반환 주소가 구 주소 체계임(공통의견)
3.5 문화정보 - 문화시설명 검색
● 문화관광
3.5.2. 등록일자
● 2012.04.02
3.5.4. 항목별 의견
3.6 문화정보 - 문화시설 주제분류 목록 제공

페이지 67 / 91
● 문화관광
3.6.2. 등록일자
● 2012.04.02
3.6.4. 항목별 의견
● 반환 주소가 구 주소체계임(공통의견)
● THEMECODE 값이 비어있음
3.7 문화정보 - 문화시설 테마분류 목록 검색(코드값조회용)
● 문화관광
3.7.2. 등록일자
● 2012.04.02
3.7.4. 항목별 의견
● 의견 없음
3.8 문화정보 - 문화시설 주제분류 목록 검색(코드값조회용)
● 문화관광

페이지 68 / 91
3.8.2. 등록일자
● 2012.04.02
3.8.4. 항목별 의견
● 의견 없음
3.9 문화정보 - 주제분류별 공연행사 검색
● 문화관광
3.9.2. 등록일자
● 2012.04.02
3.9.4. 항목별 의견
● 동일한 내용의 공연행사가 복수개의 문화시설에서 공연된다면 본 API 에서 별도의 조회 결과로
분리되어 반환되어야 [공연행사 상세 정보 제공-http://data.seoul.go.kr/metaview.jsp?id=OA-
135]와 함께 사용될 수 있음
● THEMECODE 목록에 0 은 없는데, 0 값이 반환되고 있음
3.10 문화정보 - 공연행사 주제분류 목록 검색(코드값 조회용)

페이지 69 / 91
● 문화관광
3.10.2. 등록일자
● 2012.04.02
3.10.4. 항목별 의견
● 의견 없음
3.11 문화정보 - 공연행사 상세 정보 제공
● 문화관광
3.11.2. 등록일자
● 2012.04.02
3.11.4. 항목별 의견
● ORG_CODE 의 사용 용도를 알 수 없음
● FAC_CODE 가 반환값 중 가장 중요한 값 중 하나인데, 비어있음
● aORG_DOE 가 비어있음
● 공연시간 정보가 메타데이터 형태로 제공되어야 함(공통의견)
● 정보 제공일자, 정보 수정일자를 제공하고 있음(공통의견)

페이지 70 / 91
● AGELIMIT, IS_FREE, PLAYER, PROGRAM, CONTENTS 정보가 비어있음
3.12 문화정보 - 공연행사 기간 검색
● 문화관광
3.12.2. 등록일자
● 2012.04.02
3.12.4. 항목별 의견
3.13 문화정보 - 공연행사 장소명 검색
● 문화관광
3.13.2. 등록일자
● 2012.04.02
3.13.4. 항목별 의견
● [공연행사 기간 검색-http://data.seoul.go.kr/metaview.jsp?id=OA-134]API 와 통합되어 교차
검색이 되었으면 좋겠음.

페이지 71 / 91
● 기간 검색 조건이 추가되면 좋겠음.
3.14 문화정보 - 공연행사 명 검색
● 문화관광
3.14.2. 등록일자
● 2012.04.02
3.14.4. 항목별 의견
● [공연행사 기간 검색-http://data.seoul.go.kr/metaview.jsp?id=OA-134]API 와 통합되어 교차
검색이 되었으면 좋겠음
● 기간 검색 조건이 추가되면 좋겠음
3.15 서울시립미술관 - 소장품정보(중문-번체)
● 문화관광
3.15.2. 등록일자
● 2012.11.22

페이지 72 / 91
3.15.4. 항목별 의견
● ART_CODE_NAME 에 대한 ART_CODE 정수값이 필요
● HEIGHT - 작품규격-(평면/입체):세로 정보가 필요함
● 필드명 SUBJECT_C2, MATERIAL_C2, DESC_C2 에서 _C2 suffix 를 제거해야 함(공통의견)
● 필드명 NAME_C 는 NAME 으로 suffix 를 제거해야 함(공통의견)
● 작가명(한자)에 영문명이 들어간 데이터가 있음
3.16 서울시립미술관 - 소장품정보(중문-간체)
● 문화관광
3.16.2. 등록일자
● 2012.11.22
3.16.4. 항목별 의견
● 필드명 SUBJECT_C1, MATERIAL_C1, DESC_C1 에서 _C1 suffix 를 제거해야 함(공통의견)
● 작가명(한자)에 영문명이 들어간 데이터가 있음
3.17 서울시립미술관 - 소장품정보(일문)

페이지 73 / 91
● 문화관광
3.17.2. 등록일자
● 2012.11.22
3.17.4. 항목별 의견
● 필드명 SUBJECT_J, MATERIAL_J, DESC_J 에서 _J suffix 를 제거해야 함(공통의견)
● 일문 서비스 API 인데 NAME_C 필드에 중문 데이터가 들어가 있음
● 작가명(일문)에 영문명이 들어간 데이터가 있음
3.18 서울시립미술관 - 전시정보(영문)
● 문화관광
3.18.2. 등록일자
● 2012.09.14
3.18.4. 항목별 의견
● DP_NAME 에 대한 DP_CODE 정수값이 필요
● DP_PLACE 에 대한 상세한 주소, 위치 좌표가 함께 제공되어야 함

페이지 74 / 91
● DP_PHONE, DP_MASTER, DP_INFO 필드가 비어있음
● DP_ARTIST 목록 정보를 리스트 형태로 메타데이터와 함께 반환해야함(공통의견)
3.19 서울시립미술관 - 소장품정보(영문)
● 문화관광
3.19.2. 등록일자
● 2012.09.14
3.19.4. 항목별 의견
● 앞서 나열한 [소장품정보]의 다른 언어 API 들 모두 조회 건수가 다름
● 필드명 SUBJECT_E, MATERIAL_E, DESC_E, NAME_E 에서 _J suffix 를 제거해야 함(공통의견)
● 일문 서비스 API 인데 NAME_C 필드에 중문 데이터가 들어가 있음
● TECHNIQUES 필드가 비어있음
● 작가명(일문)에 영문명이 들어간 데이터가 있음
3.20 서울시립미술관 - 소장품정보

페이지 75 / 91
● 문화관광
3.20.2. 등록일자
● 2012.08.31
3.20.4. 항목별 의견
● TECHNIQUES 도 다른 필드와 같이 중문-번체, 중문-간체, 일문, 영문을 모두 제공해야 함
● 작가명(일문) 필드 추가 필요
● 앞서 나열한 [소장품정보]의 다른 언어 API 들 모두 조회 건수가 다름(이 때문에 한글 필드외에
동일한 정보의 다른 필드가 비어있는 경우가 많음)
● SUBJECT_K, SUBJECT_C1, SUBJECT_C2 와 같이 필드명으로 구분하지 않고 다양한 언어에 대한
필드별 메타데이터 제공 필요(공통의견)
● 영문 작가명 필드에 한글 작가명이 반환됨
3.21 서울시립미술관 - 교육정보
● 문화관광
3.21.2. 등록일자
● 2012.08.31

페이지 76 / 91
3.21.4. 항목별 의견
● EDU_PLACE 에 대한 주소, 좌표 정보 제공 필요(공통의견)
● APP_OPEN_TIME, APP_CLOSE_TIME 이 ‘오후 2 시’ 대신 ‘14:00’와 같이 숫자롤 반환되어야 함
● ISFREE 의 반환값이 Y/N 이나 0/1 이 아니라 ‘무료’라는 값이 반환됨
● 기간별 검색, 강의/강사명 검색 기능 추가 요망
3.22 서울시립미술관 - 전시정보
● 문화관광
3.22.2. 등록일자
● 2012.08.31
3.22.4. 항목별 의견
● DP_PLACE 에 대한 주소, 좌표 정보 제공 필요(공통의견)
● DP_ART_CNT 반환값이 ‘총 862 점'이라는 문자열이 아니라 정수형이어야 함
● 요청 DP_LAN 에 따라 총 반환 결과가 다름
● DP_ARTIST 의 반환값이 리스트형이므로 메타데이터와 함께 구분되어 반환되어야 함
3.23 서울역사박물관 - 유물정보(중국어)
● 문화관광

페이지 77 / 91
3.23.2. 등록일자
● 2012.09.17
3.23.4. 항목별 의견
● 유물 소장중/전시중인 기관에 대한 정보
● 유물정보(중국어), 유물정보(일어), 유물정보(영어), 유물정보별로 반환되는 데이터 필드 종류가
모두 다름
● 언어별 반환 총 건수가 다름
3.24 서울역사박물관 - 유물정보(일어)
● 문화관광
3.24.2. 등록일자
● 2012.09.17
3.24.4. 항목별 의견
● 유물정보(중국어), 유물정보(일어), 유물정보(영어), 유물정보별로 반환되는 데이터 필드 종류가
모두 다름
● 언어별 반환 총 건수가 다름
3.25 서울역사박물관 - 유물정보(영어)

페이지 78 / 91
● 문화관광
3.25.2. 등록일자
● 2012.09.17
3.25.4. 항목별 의견
● MCPST_00 필드를 통해 사이즈 정보(예. ‘width : 106.3cm / length : 64.2cm’)를 제공하고 있는데
WIDTH, HEIGHT 등 메타데이터 형태로 정보를 분리해서 제공해야 함
● MCPST_00 와 같이 뒤에 붙은 _00 이라는 suffix 는 필드명의 의미를 알 수 없으므로 좋은 네이밍
룰이 아님
3.26 서울역사박물관 - 유물정보
● 문화관광
3.26.2. 등록일자
● 2012.09.17
3.26.4. 항목별 의견
● MCWEBREF16, MCWEBREF17, MCWEBREF26, MCWEBREF27, MCWEBREF28, MCWEBREF40 과
같은 네이밍 룰은 필드의 의미를 알기 어려움

페이지 79 / 91
3.27 체육정보 - 공공체육시설별 운영프로그램
● 문화관광
3.27.2. 등록일자
● 2012.10.10
3.27.4. 항목별 의견
● CLASS_S(강좌시작일), CLASS_E(강좌종료일)정보가 모두 비어있음
● FEE_FREE(가격무료확인)필드는 Y/N 값을 반환하는데, 하나를 제외하고는 모두 비어있음
● ADDRESS(주소)필드가 구 주소체계로 제공됨(공통의견)
● 종목명 검색 이외에 주소 검색 기능 추가 요망
3.28 도로굴착-도로굴착 공사 정보
● 도시관리
3.28.2. 등록일자
● 2012.11.29
3.28.4. 항목별 의견
● WORK_TERM(착공일 ~ 준공일)정보를 착공일, 준공일 분리해서 제공해야 함

페이지 80 / 91
● ROAD_TYPE 의 경우 특별시도/구도 이외의 값이 없다면 코드값으로 제공할 필요가 있음
● PACK_NAME 의 경우 차도/보도 이외의 값이 없다면 코드값으로 제공할 필요가 있음
3.29 건설정보-건설알림이
● 도시관리
3.29.2. 등록일자
● 2012.10.19
3.29.4. 항목별 의견
● FCT_F25_NM(자치구 구분)필드의 경우 의미를 알 수 없는 네이밍 룰이고, 거의 대부분 비어있음
● OFFCE_ADDR 필드는 모두 비어있음
● SITE_ADDR 필드의 주소는 구 주소 체계임(공통의견)
● PJT_DATE(사업기간) 정보는 ‘2012-07-23~2012-12-09’보다는 사업시작, 사업종료 날짜 필드를
구분해서 제공해야 함
● PJT_BGN_DATE(사업착수일)필드는 201207 로 PJT_DATE 와 날짜 포맷이 맞지 않음
● TOTAL_PJT_AMT(사업금액)필드는 단위 메타데이터와 같이 제공되어야 함(공통의견)
3.30 도로점용공간정보-구두수선소 공간정보
● 도시관리
3.30.2. 등록일자

페이지 81 / 91
● 2012.08.24
3.30.4. 항목별 의견
● X_COORD, Y_COORD 가 위도/경도 좌표계가 아니라 어떤 좌표계값인지 정보 필요
● WITH_PNU_NM(인접지 주소-동), WITH_ADDR2(인접지 주소-번지)는 분리되지 않고 다른
API 처럼 전체의 주소가 반환되어야 함
● 요청 필드의 WITH_PNU_NM 도 다른 API 의 주소 검색 방법 ‘강서구/화곡동’과 통일시킬 필요가
있음
3.31 부동산 가격정보-개별공시지가
● 도시관리
3.31.2. 등록일자
● 2012.06.22
3.31.4. 항목별 의견
● 의견 없음
3.32 도시계획정보-위치기반 도시계획정보
● 도시관리

페이지 82 / 91
3.32.2. 등록일자
● 2012.03.14
3.32.4. 항목별 의견
● 공통의견 사항들을 잘 지키고 있는 API 이지만, 목록을 반환하는 다른 모든 API 의 방식과 결과
반환 방식이 달라 통일 필요
● (대부분의 API 는 서비스명을 최상위 노드로, 그 하위에 list_total_count 를 가장 먼저 반환하고 각
건별로 row 라는 노드로 묶여있는데, 여기에서는 result 라는 최상위 노드에 대해서
list_total_count 를 반환하지 않고 건별 데이터도 row 가 아닌 item 이라는 노드로 묶여있음)
3.33 도시계획정보-도시건축공동위원회
● 도시관리
3.33.2. 등록일자
● 2012.03.14
3.33.4. 항목별 의견
● 전체 데이터 건수가 1 건 뿐임
● 500 Internal Error 가 자주 발생해 데이터 조회에 실패하는 경우가 대부분
● (대부분의 API 는 서비스명을 최상위 노드로, 그 하위에 list_total_count 로 전체 건수를 반환하고
각 건별로 row 라는 노드로 묶여있는데, 여기에서는 result 라는 최상위 노드에 대해서

페이지 83 / 91
totalCount 라는 필드를 통해 전체 건수를 반환하고 건별 데이터도 row 가 아닌 item 이라는
노드로 묶여있음)
3.34 도시계획정보-도시계획위원회
● 도시관리
3.34.2. 등록일자
● 2012.03.14
3.34.4. 항목별 의견
● 전체 데이터 건수가 1 건 뿐임
● (대부분의 API 는 서비스명을 최상위 노드로, 그 하위에 list_total_count 로 전체 건수를 반환하고
각 건별로 row 라는 노드로 묶여있는데, 여기에서는 result 라는 최상위 노드에 대해서
totalCount 라는 필드를 통해 전체 건수를 반환하고 건별 데이터도 row 가 아닌 item 이라는
노드로 묶여있음)
3.35 도시계획정보-시행계획고시
● 도시관리
3.35.2. 등록일자
● 2012.03.14

페이지 84 / 91
3.35.4. 항목별 의견
● ONTENTS 필드의 반환 값이 HTML Style 관련 정보를 모두 포함하고 있음. 텍스트 정보를
보여주는 스타일은 API 사용자가 결정해야 할 부분이므로 불필요한 정보들을 모두 아래
내용들이 필요
반환 방식이 달라 통일 필요. (대부분의 API 는 서비스명을 최상위 노드로, 그 하위에
list_total_count 로 전체 건수를 반환하고 각 건별로 row 라는 노드로 묶여있는데, 여기에서는
result 라는 최상위 노드에 대해서 totalCount 라는 필드를 통해 전체 건수를 반환하고 건별
데이터도 row 가 아닌 item 이라는 노드로 묶여있음)제거하고 축약된 정보를 제공할 필요가 있음
3.36 도시계획정보-시행계획공고
● 도시관리
3.36.2. 등록일자
● 2012.03.14
3.36.4. 항목별 의견
● ONTENTS 필드의 반환값이 HTML Style 관련 정보를 모두 포함하고 있음. 텍스트 정보를
보여주는 스타일은 API 사용자가 결정해야 할 부분이므로 불필요한 정보들을 모두 아래
내용들이 필요

페이지 85 / 91
반환 방식이 달라 통일 필요. (대부분의 API 는 서비스명을 최상위 노드로, 그 하위에
3.37 도시계획정보-결정고시
● 도시관리
3.37.2. 등록일자
● 2012.03.14
3.37.4. 항목별 의견
● LOCATION 필드에 대한 좌표 정보 추가 필요
반환 방식이 달라 통일 필요 (대부분의 API 는 서비스명을 최상위 노드로, 그 하위에
3.38 도시계획정보-열람공고
● 도시관리
3.38.2. 등록일자

2012.12_ 서울시 공공데이터 Open api 검증보고서

2012.12_ 서울시 공공데이터 Open api 검증보고서

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (7)

Semelhante a 2012.12_ 서울시 공공데이터 Open api 검증보고서

Semelhante a 2012.12_ 서울시 공공데이터 Open api 검증보고서 (20)

Mais de codenamu

Mais de codenamu (14)

2012.12_ 서울시 공공데이터 Open api 검증보고서