Ⅰ. 서 론
완전 자율주행 차량 한 대는 다양한 센서와 통신 장치를 통해 방대한 양(1.4TB/시간 ~ 19TB/시간)의 이질 적 데이터를 지속적으로 생성하는 초대용량 데이터 소스이다(Heinrich, 2017). 이러한 데이터는 차량 단위에 서 수집·저장되는 수준을 넘어, 도로 인프라, 관제 시스템, 서비스 플랫폼으로 연계되면서 다양한 형식과 주 기로 축적·유통된다. 이와 같이 대규모로 생성·수집되는 자율주행 데이터가 실제 서비스 고도화와 후속 연구 개발에 재사용되기 위해서는 데이터 자체뿐 아니라 이를 설명하는 메타데이터의 체계적 관리와 표준화가 필 수적이다.
그러나 현재 자율주행 데이터의 경우 기관, 장비, 시스템 플랫폼 등에 따라 데이터가 상이한 구조와 용어 체계로 기술되고 있어 데이터 간 상호운용성과 재사용성이 충분히 확보되지 못한 한계가 있다. 차량, 장비 또는 시스템 단위에서 정의한 데이터 항목과 스키마는 해당 환경 내에서는 활용 가능하지만, 다른 환경에서 는 동일 데이터임에도 서로 다르게 인식되는 한계가 있다. 이로 인해 데이터의 의미를 일관되게 파악하기 어 렵고, 이기종 데이터 간 통합·분석 및 타 서비스와의 연계에도 제약이 발생한다. 따라서 자율주행 R&D-실증- 서비스 전 주기를 포괄하면서 다양한 데이터 유형을 공통된 관점에서 기술 할 수 있는 통합 메타데이터 구 조와 표준을 마련하기 위한 연구가 요구된다.
이러한 구조적 이질성과 단절 문제를 해결하기 위한 핵심 전략으로 메타데이터(metadata)의 체계적 설계가 주목받고 있다(Greenberg, 2005;Shin et al., 2019). 메타데이터는 데이터 구조(Structure), 의미(Semantics), 출처 (Provenance), 권한(Rights), 활용조건(Usage conditions) 등을 명시적으로 기술함으로써, 데이터 연결성과 상호 운용성을 보장 할 수 있다(NISO, 2004). 특히 자율주행 분야는 다중 소스 데이터를 다루기 때문에 메타데이 터 기반 설명 구조는 재현성(reproducibility), 신뢰성(reliability), 확장성(scalability) 확보에 중요한 역할을 한다. 따라서 본 연구는 자율주행 데이터의 통합적 관리 및 상호운용성 강화를 위해 메타데이터를 체계적으로 설 계하는 것을 목적으로 한다. 이를 위해 자율주행 데이터의 특징과 활용 목적을 반영한 핵심 클래스(Class) 구 조를 정의하고, 각 클래스 내 속성(Property)을 설계한다. 이를 통해 자율주행 데이터의 체계적 축적, 데이터 셋 관리의 효율화, 민간 및 공공의 활용 확산 등 학술적·산업적 파급 효과를 도모하고자 한다.
Ⅱ. 기존 연구고찰
1. 메타데이터 개념
메타데이터라는 용어는 1969년 Jack E. Myers가 처음으로 제안한 것으로 알려져 있으며, 이후 1980년대 들 어 관련 분야에서 사용이 확산되었다. 이후 컴퓨터과학, 통계, 데이터베이스, 도서관·정보학 분야 등 다양한 분야에서 널리 활용되어 왔다(Greenberg, 2005). 일반적으로 메타데이터는 ‘데이터에 대한 데이터’로 정의되 며, 데이터 속성에 대한 설명과 맥락 및 품질 등을 기술함으로써 객체의 특성을 문서화하고 사용자가 데이터 를 정확히 이해할 수 있도록 돕는다(Greenberg, 2005). 이를 통해 사용자는 메타데이터를 기반으로 보다 정확 하고 효율적인 데이터 검색을 수행할 수 있으며, 관련 자원 간 연관성을 파악하여 데이터 활용성을 높일 수 있다(Shin et al., 2019).
메타데이터는 단순한 기술 속성을 넘어, 기능적 측면에서 이해될 수 있다. Lagoze et al.(1996)은 메타데이 터의 기능을 구조적(Structural), 관리적(Administrative) 등 여섯 가지 유형으로 구분하고 각 유형이 자원의 식 별, 조직화, 보존, 접근성 제고에 기여함을 제시하였다(Table 1 참조). 이는 메타데이터가 단순히 데이터에 부 가되는 보조 정보가 아니라, 데이터의 품질과 활용 가치를 좌우하고 자원 간 상호운용성과 재사용성을 뒷받 침하는 핵심 인프라임을 시사한다.
<Table 1>
Definition of metadata(Source: Lagoze et al., 1996)
| Title | Definition |
|---|---|
| Terms and Conditions | This is metadata that describes the “rules” for use of an object. |
| Administrative data | This is metadata that relates to the management of an object in a particular server or repository. |
| Content ratings | This is a description of attributes of an object within a multidimensional scaled rating scheme as assigned by some rating authority. |
| Provenance | This is data defining source or origin of some content object. |
| Linkage or relationship data | Content objects frequently have multiple complex relationships to other objects. |
| Structural data | This is data defining the logical components of complex or compound objects and how to access those components. |
이러한 일반적인 메타데이터 논의는 자율주행 데이터 환경에서도 그대로 적용되며, 특히 대규모 이기종 데이터를 통합·관리하기 위한 데이터 카탈로그 모델 설계와 밀접하게 연관된다. 다음 절에서는 공공 데이터 카탈로그 표준인 DCAT 및 교통·자율주행 분야 메타데이터 모델을 중심으로 기존 연구를 검토하고, 본 연구 가 제안하는 메타데이터 구조와의 차별점을 도출하고자 한다.
2. 메타데이터 사례 분석
1) 일반 메타데이터 사례
메타데이터는 다양한 분야에서 폭넓게 활용되어 왔다. 더블린 코어(Dublin Core)는 1995년 3월 미국 오하 이오주 더블린에서 열린 워크숍에서 제안되었으며, 데이터 상호운용성과 신속한 자원 검색을 목적으로 개발 되었다(DCMI, 2020). 더블린 코어는 비전문가도 이해할 수 있도록 15개 핵심 속성을 정의하고 경량 구조를 채택함으로써 높은 확장성을 확보하였다.
한국교육학술정보원(Korea Education and Research Information Service: KERIS)은 교육정보 서비스 제공자 및 시스템 간 상호호환성 확보를 위해 KEM (Korea Education Metadata)을 개발하였다. KEM은 더블린 코어 속성을 재사용하여 설계된 LOM (Learning Object Metadata)의 9개 카테고리를 기반으로 하며, 일부 글로벌 메 타데이터 표준 속성을 재사용하는 한편 한국 교육과정 관련 속성을 추가하였다(KERIS, 2022).
SKOS (Simple Knowledge Organization System)는 분류체계 등 지식 조직 체계의 상호운용성 확보를 위해 개발된 메타데이터 모델이다. SKOS 최신 권고안(2009년 8월 18일 기준)은 4개 클래스와 28개 속성을 정의하 고 있으며, 더블린 코어 메타데이터의 일부 속성을 재사용하여 설계되었다(Miles and Bechhofer, 2009).
FOAF (Friend of a Friend)는 사람, 조직, 활동, 관계 등에 대한 정보를 웹 상에서 공유·활용할 수 있도록 하 는 메타데이터 모델로, 소셜 네트워크 정보를 표현하기 위해 사용된다. 공개된 FOAF 명세 중 버전 0.99(2014 년 1월 14일 게시)에서는 총 13개 클래스와 62개 속성을 정의하고 있으며, 이 역시 더블린 코어 메타데이터 의 일부 속성을 재사용하여 설계되었다(Brickley and Miller, 2014).
DCAT (Data Catalog Vocabulary)는 데이터 검색과 상호운용성 강화를 목적으로 개발된 메타데이터 표준으 로, 최신 버전(Version 3, 2024년 8월 22일 기준)은 총 15개 클래스와 88개 속성을 정의한다. DCAT은 더블린 코어 메타데이터 속성을 광범위하게 재사용하고, 데이터셋, 분배, 데이터 서비스 등 데이터 카탈로그 관점의 핵심 개념을 중심으로 설계되었다(W3C, 2024).
행정안전부 공공데이터포털은 공공기관이 생성하거나 취득하여 관리하는 공공데이터를 한 곳에서 제공하 는 통합 창구로 2011년에 시범 구축 및 서비스 개시 이후 운영되고 있다(Yeon et al., 2014). 현재 포털은 메타 데이터 다운로드에서 schema.org 및 DCAT 형식을 제공하며, DCAT 기반 3개 클래스 및 24개 고유 속성1)을 확인 할 수 있어 국내 공공데이터 환경에서 DCAT 기반 메타데이터 모델의 실질적인 적용 사례를 제공한다.
2) 자율주행 및 교통 관련 메타데이터 사례
TTA(2008)는 시내 및 고속도로 교통정보에 대한 메타데이터 표준으로, 교통정보 데이터의 상호운용성 확 보를 목적으로 개발되었다. 총 6개 클래스와 58개 속성을 정의하였으며, 더블린 코어 메타데이터 속성 세트 를 재사용하여 설계되었다. 다만 교통정보 데이터셋 수준에 초점을 맞추고 있어 교통 서비스, 사업, 연구과 제 등 상위 수준 관리 정보를 포괄적으로 기술하는 데에는 한계가 있다.
Shin et al.(2019)은 교통 분야 이기종 데이터 간 검색성과 상호운용성 확보를 위해 DCAT-Trans 메타데이터 모델을 제안하였다. DCAT 표준 기반으로 총 6개 클래스와 49개 속성을 정의하였으며, RDF (Resource Description Framework)2)/DCAT 구조를 준용함으로써 공공 교통데이터 카탈로그에서 검색·연계 기능을 강화하였다. 그러나 주로 공공 교통데이터셋 중심 설계로 자율주행 연구·실증·서비스 전 주기를 포괄하는 구조로 확장하는 데에는 제약이 있다.
ETSI (European Telecommunications Standards Institute)의 SmartM2M (Machine-to-Machine) 기술위원회는 2020년 자율주행 및 차량 네트워킹 환경에서 데이터 상호운용성 확보를 목적으로 SAREF4AUTO (Smart Applications REFerence ontology for Automotive domain) 온톨로지 기반 메타데이터 표준을 개발하였다(ETSI, 2024). SAREF4AUTO는 차량, 센서, 기능, 메시지 등 자동차 도메인의 개체와 관계를 세밀하게 모델링하는 데 강점을 가지지만, 데이터셋·카탈로그 관점에서 사업·서비스·연구과제 등 관리 정보를 기술하는 데에는 초 점이 맞추어져 있지 않다.
Lubrich(2021)는 스마트 주차 시스템(smart parking systems)의 데이터 제공을 효율적으로 검색·평가하기 위 해 기능·기술·콘텐츠 관점의 계층적 분류체계(taxonomy)를 도출하고, 이를 RDF 기반 메타데이터 모델로 정 식화하였다. 제안된 메타데이터 모델은 DCAT, 더블린 코어 등 기존 데이터 카탈로그 어휘를 재사용하는 한 편, 주차 인프라, 수요, 결제 정보를 표현하기 위한 도메인 특화 클래스와 속성을 정의하였다. 이는 특정 스 마트 주차 서비스에 특화된 도메타데이터 모델로서 의의가 있으나, 자율주행 데이터 전체를 포괄하는 범용 카탈로그 모델과는 범위 측면에서 차이가 있다.
Park and Song(2022)은 DCAT-Trans를 확장하여 교통데이터의 복잡한 시공간 관계와 계통 표현을 위한 RDF 속성과 어휘를 정의하였다. 선행연구에서 제안된 6개 클래스 스키마(Catalog, Dataset, Taxonomy, Location, Relationship, Distribution)를 그대로 준용하면서 각 클래스 스키마에 총 13개 속성을 추가하였다. 이 중 5개 클래 스(Catalog, Dataset, Taxonomy, Location, Relationship)에 DCAT 기본 속성과 DCAT-Trans 특화 속성을 포함한 53 개 속성을 정의하였으며, Distribution 클래스는 DCAT 표준 속성을 그대로 사용하도록 설계하였다. 이를 통해 교통데이터 내부의 시공간·계통 관계를 정교하게 표현할 수 있으나, 여전히 Dataset· Distribution 수준에 초점을 두고 있어 상위 관리 계층 정보의 통합적 표현에는 한계가 있다.
Lubrich et al.(2024)는 NAP·모빌리티 데이터 포털 간 메타데이터 상호운용성 확보를 위해 DCAT-AP 확장 사양인 mobilityDCAT-AP를 제안하였다. 본 메타데이터 모델은 DCAT-AP의 핵심 4개 클래스(Catalogue, CatalogRecord, Dataset, Distribution)를 중심으로 모빌리티 도메인에서 필요한 추가 클래스(Mobility Data Standard 등)와 transportMode, mobilityTheme, networkCoverage, mobilityDataStandard 등 다수의 모빌리티 특화 속성을 의무 (M: Mandatory), 권고(R: Recommended), 선택(O: Optional)으로 구분하여 정의하였다. 이를 통해 유럽 NAP·모빌 리티 데이터 포털 간 메타데이터 상호운용성을 강화하였으나, 자율주행 데이터의 세부 과제, 메시지, 데이터 프레임 및 데이터 요소 수준까지 세분화하여 관리하는 모델로 활용되기에는 한계가 있다.
3. 시사점
본 연구의 목적은 자율주행 데이터의 통합적 관리 및 상호운용성 강화를 위해 메타데이터를 체계적으로 설계하는 데 있다. 따라서 본 절에서는 선행연구 고찰을 통해 경량 코어 기반과 도메인 특화 확장이라는 설 계 원칙을 도출하고, 이를 본 연구의 6계층 메타데이터 클래스·속성 체계 설계에 반영하고자 한다.
문헌 검토 결과, 일반 메타데이터 사례들은 더블린 코어와 같은 경량 코어 메타데이터를 공통 기반으로 삼고, 각 도메인의 요구에 따라 속성을 확장·재사용하는 방식으로 상호운용성과 확장성을 확보해 온 것으로 나타났다. 이러한 패턴은 자율주행 도메인에서도 공통 코어 구조와 도메인 특화 속성을 결합해 메타데이터 를 설계할 수 있음을 시사한다.
한편 자율주행 및 교통 분야 메타데이터 사례들은 교통정보, 공공 교통데이터 카탈로그, 차량·센서 온톨로 지, 모빌리티 포털 상호운용성 등 각기 다른 목적에 특화된 모델을 제안하며 데이터의 구조화와 연계를 지원 해 왔다. 그러나 이들 모델은 대체로 특정 데이터셋이나 서비스 유형 중심으로 설계되어, 사업·서비스·연구 과제 등 관리 계층과 규격 요소(메시지·프레임·데이터요소)를 데이터 전 주기 관점에서 통합적으로 기술하는 구조는 충분히 제시하지 못한다.
이에 본 연구는 이러한 공백을 보완하기 위해 6계층 구조를 기반으로 관리 계층과 규격·의미 계층을 연계 하는 메타데이터 체계를 제안한다. 또한 DCAT v3 및 더블린 코어 등 표준 어휘를 우선 재사용하고, 자율주 행 도메인에서 추가로 필요한 항목은 kadif3) 특화 속성으로 보완함으로써 상호운용성과 확장성을 함께 고려 하였다. 이를 통해 규격의 출처 추적, 과제·서비스 간 비교, 요소 단위 재사용 후보 도출 등 자율주행 데이터 의 통합적 관리에 필요한 활용 가능성을 명확히 제시한다.
Ⅲ. DCAT 구조 분석
1. DCAT의 개요
DCAT(Data Catalog Vocabulary)은 분산된 데이터셋과 데이터 서비스를 기술하고 이들에 대한 검색성과 상 호운용성을 높이기 위해 W3C에서 제안한 RDF 기반 메타데이터 표준이다. DCAT은 데이터 카탈로그 (Catalog), 데이터셋(Dataset), 분배(Distribution) 등 데이터 자원의 조직·발견·연계를 위한 핵심 개체와 관계를 정의함으로써, 공공데이터 포털, 과학 데이터 저장소 등 다양한 데이터 플랫폼에서 공통된 메타데이터 구조 로 활용되고 있다.
DCAT은 2014년 최초 권고된 이후 개정 과정을 거쳐 2024년 8월 DCAT v3를 권고되었다. DCAT v3에서는 데이터 서비스, 품질, 정책, 버전 관리 등 데이터 거버넌스 측면을 포괄하도록 구조가 확장되었다(W3C, 2024). 특히 DCAT v3는 데이터 품질 및 적합성, 접근 정책과 라이선스, 데이터셋·분배·서비스 간 버전 관계 를 명시적으로 기술할 수 있도록 지원함으로써, FAIR(Findable, Accessible, Interoperable, Reusable) 원칙 구현 을 위한 메타데이터 기반을 제공한다.
2. DCAT v3의 주요 클래스 및 속성 구조
<Fig. 1>은 DCAT v3의 전체적인 구조를 나타내며, 7개 주요 클래스4) 중심으로 모델이 구성된다. dcat:Resource 는 카탈로그에 등재될 수 있는 임의의 리소스를 추상화한 상위 클래스이며, dcat:Catalog, dcat:Dataset, dcat:DataService는 모두 이를 상속하는 하위 클래스이다. dcat:Resource는 식별자, 제목, 설명, 발행자, 주제, 시공간 범위, 라이선스 등 공통 속성을 제공하며, 하위 클래스는 이들 속성을 공유함으로써 다양한 종류의 리소스를 공통된 구조 안에서 표현할 수 있다. dcat:Catalog는 특정 기관이나 플랫폼이 보유한 데이터 자원의 집합을 나타내 며, 카탈로그 수준에서 발행 주체, 업데이트 주기, 포함된 리소스 목록 등을 기술하는 속성이 추가로 사용된다.
dcat:Dataset은 하나의 발행자나 기관이 생산·관리하는 데이터 모음을 의미하며, 형식, 품질, 주제, 시공간 범위 등 데이터 내용과 맥락을 상세히 표현하는 속성을 가진다. dcat:Distribution은 데이터셋의 접근 가능한 구체적 형태를 나타내며, 파일 형식, 접근 URL (Uniform Resource Locator), 미디어 타입, 압축·인코딩 방식 등 데이터 제공 형식과 관련된 속성을 중심으로 정의된다. dcat:DataService는 API (Application Programming Interface)와 같은 인터페이스를 통해 하나 이상의 데이터셋이나 데이터 처리 기능에 접근할 수 있도록 하는 서비스 자원을 표현하며, 서비스 엔드포인트, 지원 프로토콜, 연결된 데이터셋 등을 기술하는 속성을 포함한 다. dcat:DatasetSeries와 dcat:CatalogRecord는 각각 데이터셋 집합과 카탈로그 메타데이터 레코드를 표현하는 보조적 클래스이다.
이와 같이 DCAT v3는 상위 클래스(dcat:Resource)의 공통 속성과 각 클래스의 특화 속성을 계층적으로 결 합함으로써, 다양한 데이터 자원과 제공 방식을 일관된 데이터 카탈로그 모델 안에서 표현할 수 있도록 한 다. 본 연구에서는 이러한 DCAT v3의 클래스·속성 구조를 기반으로 자율주행 도메인의 사업·서비스·연구과 제·메시지·데이터 수준을 단계적으로 표현할 수 있는 6계층 메타데이터 클래스를 설계하였다. 즉, dcat:Dataset 중심의 표준 모델과 더블린 코어 등 표준 어휘를 우선 재사용하되, 자율주행 데이터는 연구개발 단계에서 규격이 과제·서비스 단위로 정의되고 dcat:Distribution·dcat:DataService 수준이 확정되기 전에도 메시 지·요소 단위의 비교·재사용이 요구된다는 점을 고려하여 거버넌스(사업-서비스-연구과제) 계층과 규격·의미 (메시지-프레임-데이터요소) 계층을 추가로 명시하였다. 또한 모든 계층에 공통 적용되는 코어 속성(예: dcterms:title, dcterms:description, dcterms:identifier)과 상위 계층의 관리정보(예: dcterms:startDate/endDate, 기관 정보 등), 하위 계층의 규격·의미정보(예: dcterms:conformsTo, kadif:unit, kadif:validValueRange)를 구분하여 계 층별 특화 속성을 도출하였다. 이를 기반으로 다음 절에서는 6계층 클래스와 공통·특화 속성 체계를 정리하 고, 적용 예시를 제시한다.
Ⅳ. 데이터 설명 및 데이터 카탈로그 클래스 설명
1. 데이터 설명
본 연구는 자율주행 관련 사업의 22개 세부과제 대상으로 하였다. 각 과제에서 정의한 데이터 명칭, 생성 주체, 형식, 주기 등 dcat:Dataset 관점의 항목을 추출한 뒤 의미가 동등·유사한 항목을 통합하고 중복을 제거 하는 정규화 과정을 수행하였다. 이 과정에서 자율주행 도메인 전문가 검토를 통해 용어 체계를 정리하고, 데이터의 생산·활용 맥락을 기준으로 데이터 유형을 재분류하였다.
실제 데이터 플랫폼이 구축되기 전 단계이므로, 메시지·프레임·데이터 요소 가운데 (1) 동일한 서비스 목 적과 활용 시나리오를 위해 함께 사용되고 (2) 동일한 기관·시스템이 하나의 관리·제공 단위로 취급하며 (3) 하나의 메시지/테이블 구조로 일관되게 저장·처리하는 범위를 하나의 가상 데이터셋으로 간주하였다. 예를 들어 MSG_AutonomousMap과 같은 자율차전용지도 제공 메시지는 하나의 가상 데이터셋으로 정의된다.
<Table 2>는 가상 데이터셋이며, 이를 Business-Service-ResearchProject-Message-DataFrame-DataElement 6계층 구조로 재편하였다. 상위 3계층에서는 사업·서비스·연구과제 수준의 관리정보를 하위 3계층은 메시지·프레 임·데이터 요소 수준의 구조·의미 정보를 기술하도록 설계하였다. 연구개발 단계에서는 배포(Distribution), 데 이터 서비스(DataService), 카탈로그(Catalog, CatalogRecord) 및 시계열 데이터셋(DatasetSeries)에 대한 정의가 미비하므로 dcat:Dataset 중심의 메타데이터 설계에 초점을 두었다. 이를 통해 데이터 규격을 가상 데이터셋 단위로 통합하고, 향후 상호운용성 확산 가능성을 검토하고자 하였다.
<Table 2>
Minimal example of a message-level virtual dataset and its key metadata fields
| Label (Message) | Definition | Example |
|---|---|---|
| Message | name of message | Road Management System Information |
| Conformance standard | Applicable standard for this message | SAE J 2735:2024 |
| Standard body | Responsible standards body | SAE |
| ID | Unique identifier for the message | 1.2.410.200053.- |
| ⋮ | ⋮ | ⋮ |
본 연구에서 제안한 메타데이터 구조는 특정 사업에 종속된 고정스키마가 아니라 표준 어휘 기반의 카탈 로그 관점 설계 원칙에 따라 정의되었다. 특히 하위 3계층(Message-DataFrame-DataElement)은 메시지·테이블· 필드 등 데이터 규격의 구조·의미 정보를 기술하는 계층으로 부처·기관·플랫폼이 달라지더라도 규격 수준에 서 공통적으로 적용될 수 있어 상호운용성에 직접 기여한다. 상위 3계층(Business-Service-ResearchProject)은 데이터의 생산·운영 거버넌스를 기술하기 위한 추상 계층으로 정의하여, 타 부처 사업·민간 실증·지자체 플 랫폼 등에서도 조직 구조에 맞게 명칭과 관계를 치환하여 적용할 수 있다.
2. 자율주행 메타데이터 클래스 정의
앞 절에서 정의한 가상 데이터셋을 체계적으로 기술하기 위해, 본 절에서는 DCAT v3의 클래스·속성 구조 를 기반으로 Business-Service-ResearchProject-Message-DataFrame-DataElement의 6개 메타데이터 클래스를 설계 하였으며, 다음 절에서 클래스 별 속성을 설계한다. 상위 3계층(Business, Service, ResearchProject)은 사업·자율 주행서비스·연구과제 수준 관리 정보를, 하위 3계층(Message, DataFrame, DataElement)은 자율주행 데이터 규 격서에 정의된 메시지·프레임·데이터 요소 수준 구조·의미 정보를 표현하도록 구성하였다. 또한 dcat:Dataset 을 중심 자원으로 두고 각 계층 클래스를 연계하였으며, 더블린 코어 어휘를 공통으로 활용하되 필요시 도메 인 특화 속성을 추가하였다. <Fig. 2>는 Dataset 중심의 6계층 클래스 관계 개요도를 나타낸 것이다.
<Fig. 2>
Overview of the proposed six-layer metadata class structure (this study); detailed attributes are provided in Table 2.
Business 클래스는 정책·사업 단위를 표현한다. 사업명, 사업 기간, 주관·참여 기관, 과제번호 등을 속성으로 가지며, 이를 통해 특정 사업에서 정의된 데이터 규격의 전체 범위, 사업 간 데이터 규격 비교가 가능하다. Service 클래스는 사업 하위의 서비스 분야를 나타내며, 서비스명, 유형, 목적, 담당 기관 등을 기술하여 서비스 별로 연계된 ResearchProject, Message, DataFrame, DataElement를 추적할 수 있도록 한다. ResearchProject 클래스 는 22개 세부 연구과제를 표현하며, 과제명, 수행 기간, 주관·참여 기관, 연구 목표, 연구 분야, 기대효과 등을 속성으로 가진다. 각 ResearchProject는 하위 Message·DataFrame·DataElement와 연계를 통해 특정 과제에서 정의 된 데이터 규격 집합을 식별하고 후속 과제에서의 재사용·확장 근거를 제공한다.
Message 클래스는 MSG_* 형태로 정의된 메시지 단위 규격을 표현한다. 메시지명, 설명, 관련 표준, 메시 지를 생성하는 장치 유형, 전송 주기, 생성 주체, 등록·수정일시 등을 메타데이터로 관리하며, 가상 데이터셋 의 논리적 분배 단위로 간주한다. DataFrame 클래스는 DF_* 형태의 프레임 구조를 나타내며, 프레임 ID·명 칭, 상위 Message와 관계, 포함 필드 목록, 데이터 타입 등을 기술함으로써 메시지 내부 스키마를 표현한다.
마지막으로 DataElement 클래스는 DE_* 단위의 개별 데이터 요소를 표현한다. 항목명과 설명, 단위, 허용 값 범위, 참조 데이터셋 이름, 식별자, 관련 표준 등을 메타데이터로 부여하여 과제 간 데이터 요소를 비교· 매핑할 수 있도록 하였다. 예를 들어 vehSpeed, vehicle_speed, speed_kmh 등으로 상이하게 정의된 항목을 동 일 개념으로 통합함으로써 향후 실제 데이터셋 구축 시 스키마 매핑과 통합 비용을 줄이고 상호운용성과 재 사용성을 높일 수 있다.
3. 메타데이터 속성 설계 및 표준 어휘 매핑
본 연구에서 제안한 6개 메타데이터 클래스에 대한 세부 속성 정의와 표준 어휘 매핑 결과는 6계층 클래 스의 역할(상위: 관리정보, 하위: 규격·구조·의미정보)에 따라 각 클래스가 반드시 기술해야하는 정보를 도출 한 후 이를 표준어휘로 우선 매핑하고 부족한 항목을 도메인 특화 속성으로 보완하는 절차로 수행하였다. 구 체적으로 (1) W3C DCAT v3 및 더블린 코어 Terms (dcterms) 등 국제 표준 메타데이터 어휘를 우선 재사용하 고, (2) 자율주행 데이터 규격서 기술에 필요하나 표준 어휘만으로 표현이 어려운 관리·설명 항목(예: 사업/서 비스/과제 맥락, 활용·운영 정보 등)은 kadif: 접두어를 사용하는 도메인 특화 속성으로 정의하였다. 또한 속 성은 모든 클래스에 공통으로 적용되는 코어 속성과, 상위 3계층(Business-Service-ResearchProject)의 맥락/거버 넌스 속성, 하위 3계층(Message-DataFrame-DataElement)의 규격·구조·의미 속성으로 구분하여 구성함으로써 사업·과제 간 규격 비교, 요소 단위 재사용 후보 도출 및 의미 매핑을 지원하도록 설계하였다.
<Table 3>는 6계층 메타데이터 모델에서 각 클래스별 속성 구성을 정량적으로 요약한 것이다. 속성은 모 든 클래스에 공통적으로 적용되는 코어 속성(Core)과 상위 3계층(Business-Service-ResearchProject)의 관리·거버 넌스 정보를 기술하는 관리 속성(Management), 하위 3계층(Message-DataFrame-DataElement)의 규격·구조·의미 정보를 기술하는 구조·의미 속성(Technical)으로 구분하여 집계하였다. 또한 각 속성의 어휘 출처를 표준 어 휘(Standard: dcterms/dcat/foaf/vcard/adms 등)와 도메인 특화 어휘(kadif)로 구분하여 재사용 및 확장 현황을 함 께 제시하였다. 요약 결과, 상위 계층 클래스는 클래스당 31~33개 속성으로 구성되며 관리 속성 비중이 높고, 하위 계층은 15~18개 속성으로 구성되며, 구조·의미 속성 비중이 상대적으로 큰 것으로 나타났다. 또한 모든 클래스에서 표준 어휘 재사용이 우세하되, 자율주행 도메인에서 추가로 필요한 항목은 KADIF 특화 속성으 로 보완하였다. 요약표는 속성 구성의 전반적 경향을 보여주며, 실제 구현을 위해서는 클래스별 속성의 구체 항목과 정의를 함께 확인할 필요가 있다. 이에 클래스별 전체 속성 목록과 정의 및 표준 어휘 매핑 결과는 <Table 4>에 정리하였다.
<Table 3>
Summary of properties by six-layer metadata class
| Class | Properties | Vocab | Notes | ||||
|---|---|---|---|---|---|---|---|
| Total | Core | Management | Technical | Standard | KADIF | ||
| kadif:Business | 31 | 2 | 29 | 0 | 20 | 11 | startDate/endDate, organization, vision |
| kadif:Service | 31 | 2 | 29 | 0 | 21 | 10 | hasPartOf/subject, purpose, contactPoint |
| kadif:ResearchProject | 33 | 2 | 31 | 0 | 24 | 9 | researchOutput, expectedEffects, applicationPlan |
| kadif:Message | 18 | 2 | 6 | 10 | 12 | 6 | conformsTo, transmissionPeriod, hasPhysicalSourceType |
| kadif:DataFrame | 15 | 2 | 5 | 8 | 11 | 4 | referenceDatasetName, dataFormat, isPartOf/hasPart |
| kadif:DataElement | 16 | 2 | 5 | 9 | 10 | 6 | validValueRange, unit, referenceDatasetName |
<Table 4>
Property definitions and vocabulary mapping
*B:Business, S:Service, R:ResearchProject, M:Message, DF:DataFrame, DE:DataElement
| Property | Definition | Class | Vocabulary |
|---|---|---|---|
| versionNote | A description of changes between the current version and previous versions | B; R; S | adms |
| accessURL | The URL through which the dataset can be accessed or distributed | B; R; S | dcat |
| contactPoint | Responsible Person | B; R; S | dcat |
| contributor | The name of the joint research institution | R | dcat |
| dataCatalog | A web-published catalog for data discovery | B; R; S | dcat |
| dataset | A dataset included and linked within the data repository | B; R; S | dcat |
| distribution | A property linking datasets to their available distributions | B; R; S | dcat |
| keyword | Core concepts and terms representing the entity | B; R; S | dcat |
| resource | A resource registered in the data catalog | B; R; S | dcat |
| service | An endpoint included in the catalog that provides access to data | B; R; S | dcat |
| themeTaxonomy | A knowledge organization system used to classify datasets | B; R; S | dcat |
| accessRights | Access restrictions and conditions | DE; DF; M | dcterms |
| conformsTo | Referenced standard/specification | DE; DF; M | dcterms |
| creator | Entity that initially created the entity | M | dcterms |
| description | A general description of the entity | All | dcterms |
| endDate | The end date | B; R; S | dcterms |
| format | Encoding format of the entity | M | dcterms |
| hasPart | Subclasses of the entity | DF; M | dcterms |
| hasPartOf | The superclass of the entity | R; S | dcterms |
| identifier | Representation of the dataset identifier | DE; DF; M; R | dcterms |
| isPartOf | Superclasses of the entity | DE; DF | dcterms |
| issued | Date the entity was registered in the system | DE; DF; M | dcterms |
| modified | Date the entity was updated in the system | DE; DF; M | dcterms |
| publisher | Standard/policy issuing organization | DE; DF; M | dcterms |
| rightsHolder | Copyright holder | DE; DF; M | dcterms |
| startDate | The start date | B; R; S | dcterms |
| subject | The detailed domain area (e.g., five subfields of autonomous driving) | B; R; S | dcterms |
| title | The title of the entity | All | dcterms |
| homepage | The main web page of the catalog | B; R; S | foaf |
| organization | The government organization responsible for the entity | B; R; S | foaf |
| PersonInCharge | Person in Charge | B; R; S | kadif |
| applicationPlan | The application plan of the research | R | kadif |
| dataFormat | Format in which the dataframe is encoded for storage or exchange | DF | kadif |
| department | Department of the responsible person | B; S | kadif |
| expectedEffects | The expected effects of the research | R | kadif |
| hasPhysicalSourceType | Physical device associated with the message | M | kadif |
| headerInformation | Fixed header information of the message | M | kadif |
| managementagency | The designated agency managing the business | B | kadif |
| purpose | A statement specifying the concrete objective of the entity | B; R; S | kadif |
| referenceDatasetName | The name of the unique dataset referenced by the entity | DE; DF | kadif |
| researchOutput | The research output of the study | R | kadif |
| researchProjectName | The name of the sub-project | B; S | kadif |
| researchProjectObjective | Research Project | B; S | kadif |
| resourceStatus | The status of data within a specific entity process context | B; R; S | kadif |
| responsiblePerson | The person responsible at the executing organization | B; S | kadif |
| responsibleProjectOrganization | The leading research organization | B; S | kadif |
| specializedinstitution | The specialized institution in charge of the entity | B; R; S | kadif |
| standardComplianceStatus | Status of the entity compliance with standards | DE; DF; M | kadif |
| transmissionPeriod | Transmission cycle of the entity | DE; M | kadif |
| transmissionTechnology | Physical/wireless technology used to transmit the message | M | kadif |
| unit | The SI notation unit used in the data element | DE | kadif |
| usageNote | Notes or cautions on the use of data, such as specific usage guidelines | DE; DF; M | kadif |
| utilizeInformation | Information used in the research | R | kadif |
| validValueRange | The valid range permitted in the data element | DE | kadif |
| vision | The vision of the entity | B; R; S | kadif |
| fn | Name of the responsible | B; R; S | vcard |
| hasEmail | Email of the responsible person | R | vcard |
| hasTelephone | Telephone extension of the responsible person | B; R; S | vcard |
| organization-name | Company name of the responsible person | B; R; S | vcard |
<Table 4>는 6계층 메타데이터 모델을 구성하는 각 클래스의 속성 정의와 표준 어휘 매핑 결과를 제시한다. 표준 어휘 매핑의 일관성 확보를 위해, 공통적으로 모든 클래스에는 title, description 등 기본 식별·설명 속성을 부여하고 상위 3계층(Business·Service·ResearchProject)에는 startDate/endDate, organization, 등 사업·서비스·과제 맥락과 거버넌스 정보를 표현하는 관리 중심 속성을 적용하였다. 반면 하위 3계층(Message·DataFrame· DataElement)에는 conformsTo, publisher, unit 등 데이터 규격의 구조·의미·품질을 기술하는 속성 중심으로 구성 하였다. 또한 issued/modified, accessRights, rightHolder 등 기반으로 등록·갱신 이력, 접근권한 등의 정보를 관리 할 수 있도록 하였다. 이와 같은 속성 설계를 통해 상위 계층에서는 관리정보를 하위 계층에서는 규격의 구조· 의미 정보를 동일한 원칙으로 기술할 수 있으며, DCAT 기반 데이터 카탈로그 환경으로 확장, 타 도베인 메타 데이터와 상호운용성 확보를 동시에 도모하고자 하였다.
Ⅴ. 메타데이터 모델 적용 사례 및 활용 시나리오
1. 과제 기반 메타데이터 모델 적용 예시
앞 장에서 설계한 6계층 메타데이터 모델의 적용 가능성을 검토하기 위해, 본 장에서는 국-1 과제5)를 대 상으로 실제 데이터 규격에 대한 매핑 예시와 검색·연계 시나리오를 제시한다. 특히 자율주행 관련 사업의 세부 과제 대상으로 Business-Service-ResearchProject-Message-DataFrame-DataElement 클래스가 실제 데이터 규 격 구조를 어떻게 반영하는지 살펴본다. 또한 <Table 3>에서 정의한 속성이 실제로 어떤 값으로 기술되는지 확인 할 수 있도록 본 절에서는 대표 클래스에 대해 주요 속성 예시 값을 함께 제시한다. 예시 값은 규격서 에 기재된 항목 기반으로 하되 설명 목적의 가상 값을 포함한다.
<Fig. 3>는 국-1 과제에 대한 메타데이터 클래스 구조를 개략적으로 나타낸 것이다. 상위 계층에서 Business 클래스는 사업 전체를 Service 클래스는 국-1 과제가 속한 서비스 분야를 표현한다. ResearchProject 클래스는 국-1 과제명을 제목으로 하고 과제 기간, 주관·참여 기관, 연구 목표, 기대효과 등을 메타데이터로 기술하여 사업·서비스 수준 목표와의 연계를 명시한다.
<Fig. 3>
Example of 6-layer metadata mapping for the ADTI program (Business-Service-ResearchProject-Message- DataFrame-DataElement)
Message 클래스에서는 국-1 과제 데이터 규격서에 정의된 MSG_AutonomousMap과 같은 메시지 단위를 메 타데이터로 등록한다. 해당 Message에는 메시지명과 설명, 관련 표준, 메시지를 생성하는 장치 유형, 전송 주 기, 생성 주체 및 등록일 등을 부여하였다. DataFrame 클래스는 MSG_AutonomousMap 내부의 프레임을 각각 하나의 DataFrame으로 표현하고, 상위 메시지와 관계 기반으로 프레임의 기능과 포함 필드 목록을 기술한다.
마지막으로 DataElement 클래스에서는 각 프레임에 포함된 개별 데이터 요소를 데이터 요소명, 단위, 허용 값 범위, 참조 데이터셋 이름, 관련 표준 등으로 기술하였다. 이를 통해 국-1 과제에서 정의한 지도·인프라 관련 데이터 규격이 사업-서비스-연구과제-메시지-데이터프레임-데이터요소로 이어지는 계층구조안에 일관 되게 수용될 수 있음을 확인하였다. <Table 5>는 주요 클래스에 대한 대표 속성값 예시를 제시하며, <Table 4>의 속성 정의가 실 적용시 어떤 값 형태로 채워지는지 보여준다. 일부 값은 가상 값으로 표기하였다.
<Table 5>
Example property values for the six-layer metadata classes
| Class | Property | Example value |
|---|---|---|
| ResearchProject | title | Development of a crowdsourcing-based digital road and transportation infrastructure convergence platform technology |
| ResearchProject | startDate/endDate | 2021-04-01 / 2026-12-31 |
| ResearchProject | organization | MOLIT |
| Message | title | MSG_AutonomousMap |
| Message | identifier | 1.2.410.200053.- |
| Message | conformsTo | SAE J2735:2024 (illustrative) |
| Message | transmissionPeriod | 100 ms (illustrative) |
| DataElement | title | DE_Latitude |
| DataElement | description | Latitude at the time of information provision |
| DataElement | unit | 0.1 micro degree |
| DataElement | validValueRange | -900000000 ~ 900000001 |
2. 검색 및 연계 활용 시나리오
제안한 메타데이터 모델은 자율주행 연구개발 단계에서 정의된 데이터 규격을 사업·서비스·연구과제·메시 지·데이터프레임·데이터요소 단위로 연결함으로써 다음과 같은 활용 시나리오를 지원할 수 있다.
첫째, 서비스별 데이터 규격 현황 조회가 가능하다. 예를 들어 “이용자 편의증진 서비스에서 사용되는 메 시지 규격 목록”을 검색하면 해당 Service에 연계된 ResearchProject와 Message 클래스를 따라가면서 관련 메 시지 규격과 프레임, 데이터요소를 일괄적으로 확인 할 수 있다. 이는 서비스 기획 단계에서 데이터 요구사 항을 점검하거나, 여러 과제에 흩어져 정의된 규격을 서비스 관점에서 재구성하는 데 유용하다.
둘째, 과제 간 데이터 규격 재사용 후보 도출을 지원한다. 특정 연구과제에 연결된 Message, DataFrame, DataElement 기준으로, 동일·유사한 구조를 갖는 다른 과제의 규격을 질의함으로써 재사용 가능성이 높은 메 시지·프레임·데이터 요소를 식별할 수 있다. 예를 들어 국-1 과제에서 정의한 차량 속도 관련 DataElement와 동일한 의미를 가진 요소가 다른 과제에서 어떤 이름과 구조로 정의되어 있는지 비교할 수 있다.
셋째, 데이터 요소 단위의 의미 통합 및 온톨로지 연계가 가능하다. DataElement 클래스에 정의된 항목명, 단위, 허용값 범위, 관련 표준 정보를 활용하면, 과제별로 상이하게 정의된 데이터 요소를 의미적으로 매핑 하여 표준 용어 체계나 도메인 온톨로지와 연결할 수 있다. 이는 향후 실제 데이터셋 구축 시 스키마 매핑과 데이터 통합 비용을 절감하고, 상호운용성을 높이는 기반이 된다.
넷째, 향후 데이터 플랫폼 구현을 위한 사전 설계 도구로 활용될 수 있다. 본 연구의 메타데이터 구조는 아직 Distribution 및 DataService 수준의 물리적 배포·서비스 정의 이전 단계에 해당하지만, Dataset 중심의 메 타데이터를 선제적으로 정립함으로써, 향후 데이터 카탈로그, API 게이트웨이, 데이터 마켓플레이스 등의 구 현 시 설계 기준으로 활용될 수 있다.
Ⅵ. 결 론
본 연구는 자율주행 데이터 상호운용성 강화를 위해, 자율주행 관련 사업의 22개 세부 과제에서 정의한 데이터 규격을 대상으로 DCAT 기반 메타데이터 모델을 설계하는 것을 목적으로 수행되었다. 이를 위해 Business, Service, ResearchProject, Message, DataFrame, DataElement 등 6개 주요 클래스를 정의하고 각 클래스 별로 15개에서 33개에 이르는 세부 속성을 설계하였다. 모든 속성은 W3C DCAT v3 중심으로 더블린 코어 Terms, FOAF 등 표준 어휘를 우선 재사용하여 정의하였으며, DCAT에서 제공하지 않는 속성의 경우 DCAT 이 참조하는 다른 표준 어휘를 활용하고 그마저도 부합하지 않는 경우 kadif 접두어를 사용하는 신규 속성을 정의함으로써 확장성과 유연성을 확보하였다.
이러한 설계를 통해 본 연구는 기존 범용 메타데이터 표준이 가지는 한계를 보완하고, 자율주행 연구 도메 인에 최적화된 6계층 메타데이터 체계를 제시하였다. 특히 Business-Service-ResearchProject-Message-DataFrame- DataElement로 이어지는 계층 구조는 데이터셋 관리뿐 아니라 연구과제 기록, 서비스 제공을 위한 데이터 교환, 데이터 규격 재사용 분석 등 다양한 활용 맥락에서 적용 가능성을 높인다. 또한 설계 과정에서 국제 표준을 근거로 삼음으로써, 국내외 다양한 데이터 인프라와의 연계 및 상호운용성이 강화될 수 있음을 확인하였다. 따라서 본 연구 결과는 단순한 모델 제안에 그치지 않고, 향후 실제 데이터 플랫폼에서의 메타데이터 관리와 응용을 위한 기반을 제공한다는 점에서 학문적·실무적 의의를 갖는다.
본 연구의 향후 연구 방향은 다음과 같다. 첫 번째로 본 연구에서 설계한 메타데이터 모델은 구조적 정의 와 속성 수준에서 정합성을 확보하는데 중점을 두었으나, 실제 데이터셋 및 서비스 환경에 적용하기 위한 실 증적 검증 과정이 추가로 필요하다. 특히 다양한 도메인에 적용했을 때 속성 간 불일치나 활용상 제약이 나 타날 수 있으므로, 실제 데이터 기반 검증 연구가 요구된다. 두 번째로 메타데이터는 단순한 기술적 체계를 넘어 데이터 활용성 및 가치 평가와도 직결된다. 따라서 향후에는 본 연구 모델 기반으로 데이터셋의 품질 특성, 재사용 가능성 분석, 서비스 연계성 평가 등의 평가 지표를 개발하여 메타데이터가 데이터 생태계 내 에서 가지는 실질적 효과를 측정할 필요가 있다. 마지막으로 본 연구는 데이터 규격 기반으로 메타데이터를 설계하다보니 정적인 속성에 맞춰 설계되었다. 그러나 데이터와 서비스는 시간이 지남에 따라 동적으로 변 화한다. 따라서 메타데이터 모델이 동적 속성 변화와 시계열적 관리를 지원할 수 있도록 확장하는 방향이 필 요하다. 이러한 연구는 장기적으로 데이터 자산의 전체 생애주기 관리를 가능하게 하고, 보다 지능적인 데이 터 플랫폼 구축으로 이어질 수 있을 것이다.
