- 발행일
시맨틱 웹의 이해 — 공부한 개념이 그대로 실무 도메인이 된 경우
시맨틱 웹(Semantic Web)의 이해
표준데이터 관리 시스템 업무를 맡게 되면서 급하게 공부했던 정리입니다. 시맨틱 웹은 웹 자원의 의미와 관계를 기계가 이해할 수 있도록 구조화된 데이터를 제공하는 확장된 웹이고, W3C가 표준화를 주도합니다. 개념 정리를 앞에 두고, 이 개념들이 실제 시스템 설계로 이어진 이야기를 뒤에 붙였습니다.
1. 배경 — 웹의 진화와 시맨틱 웹의 자리
| 웹 1.0 | 웹 2.0 | 웹 3.0 | |
|---|---|---|---|
| 사용자 역할 | 소비자 (읽기 전용) | 생산자 + 소비자 (UCC) | 데이터 소유자 |
| 데이터 관리 | 중앙 서버 | 플랫폼 | 분산 네트워크 |
| 핵심 기술 | 정적 HTML | AJAX, RSS, 오픈 API | 블록체인, AI, 시맨틱 기술 |
시맨틱 웹이 웹 3.0 문맥에서 자주 언급되는 건, "링크로 연결된 문서"를 넘어 "의미로 연결된 데이터" 로 가자는 방향이 웹 3.0의 지향과 맞물리기 때문입니다. 전통적인 웹이 데이터의 표현에 중점을 뒀다면, 시맨틱 웹은 데이터 간의 의미 있는 연결과 기계 해석 가능성에 중심을 둡니다.
2. 두 층위의 "시맨틱"
같은 단어가 두 층위로 쓰여서 처음에 헷갈렸던 부분입니다.
구조 기반 — HTML5 시맨틱 태그. 문서의 구획에 의미를 주는 것: <header> <nav> <main> <article> <section> <aside> <footer> <figure>/<figcaption> <time> <details>/<summary>. 접근성과 SEO의 기반이지만, 여기까지는 "문서 구조"의 의미입니다.
데이터 기반 — 어휘(Vocabulary) 체계. 데이터 자체에 의미를 주는 것. 어휘란 "어떤 단어를 써야 의미가 통할지 정해놓은 사전"입니다.
| 어휘 체계 | 용도 | 예 |
|---|---|---|
| Schema.org | 검색엔진용 구조화 데이터 | itemtype="https://schema.org/Person" |
| Dublin Core (DCMI) | 문서·자원의 메타데이터 | dct:title, dct:creator, dct:modified |
| FOAF | 사람과 관계 | foaf:name, foaf:knows |
| SKOS | 분류 체계 | skos:broader, skos:narrower |
| DCAT | 데이터 카탈로그 | dcat:Dataset, dcat:Distribution |
HTML 속성으로는 마이크로데이터(itemscope/itemprop), RDFa(typeof/property/resource), 접근성의 ARIA(role/aria-*)가 이 층에 속하고, 요즘 검색엔진 대응의 실전은 JSON-LD입니다:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Person",
"name": "김연아",
"jobTitle": "피겨 스케이팅 선수",
"sameAs": ["https://ko.wikipedia.org/wiki/김연아"]
}
</script>
3. RDF — 모든 것은 트리플이다
RDF(Resource Description Framework)는 정보를 주어–술어–목적어(Triple) 로 표현하는 W3C 표준 데이터 모델입니다.
"바나나는 노란색이다" →
<urn:바나나, urn:색, urn:노랑>
이 단순한 구조가 핵심인 이유는, 트리플을 쌓으면 그래프가 되고 그래프끼리는 URI만 맞으면 자동으로 연결되기 때문입니다. RDFa는 이 RDF를 HTML 속성 안에 심는 표기법이고요 — RDF가 독립적인 데이터 모델이라면, RDFa는 웹 문서 안에서 그걸 표현하는 방식입니다.
4. 링크드 데이터와 그 4원칙
링크드 데이터는 시맨틱 웹을 실현하는 방법론입니다. 팀 버너스리의 4원칙:
- URI로 자원을 식별하라 —
http://example.org/fruit/banana - HTTP로 참조 가능하게 하라 — 그 URI에 접속하면 실제 내용이 나와야 함
- RDF/SPARQL로 의미 있는 정보를 제공하라 — 기계가 읽을 수 있는 구조로
- 다른 자원으로의 링크를 포함하라 — DBpedia의 바나나와 연결
여기에 공개 라이선스가 붙으면 LOD(Linked Open Data)가 됩니다. 오픈 API와의 차이가 시험에 나올 것처럼 생겼지만 실무적으로도 중요한 구분입니다:
| 링크드 데이터 | LOD | 오픈 API | |
|---|---|---|---|
| 목적 | 의미적 연결 | 의미적 연결 + 공개 | 기능 중심 데이터 제공 |
| 형식 | RDF 트리플 | RDF 트리플 + 오픈 라이선스 | JSON/XML |
| 기계 해석 | 의미까지 가능 | 의미까지 가능 | 구조만 가능, 의미는 부족 |
오픈 API의 "temperature": 22.5는 구조는 있지만 그게 섭씨인지, 어느 지점 온도인지의 의미는 스키마 밖(문서)에 있습니다. 시맨틱 웹은 그 의미를 데이터 안으로 넣자는 것이고요.
5. 온톨로지 — 개념과 관계의 명세
사람은 문맥으로 이해하지만 컴퓨터는 못 하니, 어떤 개념이 무엇과 어떻게 관련되는지를 명시적 체계로 만들어 주는 것이 온톨로지입니다.
| 구성 요소 | 사람 언어로 | 예시 |
|---|---|---|
| 클래스 | 명사 개념, 분류 | 올림픽, 도시, 사람 |
| 인스턴스 | 구체적 개체 | 평창, 김연아 |
| 속성 | 특징, 값 | 개최연도 = 2018 |
| 관계 | 동사, 연결 | 평창 → 개최했다 → 올림픽 |
6. 메타데이터, 데이터 카탈로그, DCAT
메타데이터는 데이터를 설명하는 데이터입니다 — 본문이 "무엇인지, 어디서 왔는지, 어떻게 연결되는지"를 알려주되 본문 자체는 포함하지 않습니다. 시맨틱 웹에서 메타데이터는 부가 설명이 아니라 데이터를 의미적으로 연결하는 핵심 수단입니다.
데이터 카탈로그는 조직의 데이터 인벤토리 — 어떤 데이터가 어디 있고, 무슨 뜻이고, 누가 만들었는지의 목록입니다. 장점(검색·품질·거버넌스)은 명확하지만 비용도 명확합니다: 초기 구축에 사람 손이 많이 들고, 실제 데이터와 메타데이터가 어긋나기 시작하면 신뢰가 무너지며, 사용자가 설명을 안 달아주면 빈 껍데기가 됩니다.
DCAT은 그 카탈로그를 기술하는 W3C 표준 어휘입니다. 기관마다 "제목/타이틀/이름"으로 제각각인 표현을 dct:title 하나로 통일해, 서로 다른 기관의 카탈로그를 기계가 자동으로 해석하게 합니다.
<dcat:Dataset>
<dct:title>서울시 인구 데이터</dct:title>
<dct:description>서울시의 연도별 인구 통계입니다.</dct:description>
</dcat:Dataset>
구조는 dcat:Catalog(카탈로그) → dcat:Dataset(데이터셋) → dcat:Distribution(배포 단위: CSV, API 등)이고, 제목·설명은 Dublin Core를, 제공 기관은 FOAF를 빌려 씁니다 — 어휘 체계들이 서로를 참조하며 조립되는 구조입니다.
7. 실무에서 — 공부가 그대로 도메인이 됐다
여기까지가 당시 공부 노트고, 이 글을 다시 꺼낸 이유는 이 개념들이 교양으로 끝나지 않았기 때문입니다. 표준데이터 관리 시스템이 정확히 이 구조 위에 서 있습니다.
- 5절의 온톨로지 표가 그대로 데이터 모델이 됐습니다. 클래스·인스턴스·속성·관계는 비유가 아니라 시스템의 실제 테이블이에요. 그리고 그 전환이 순탄치 않았습니다 — 처음엔 표준데이터를 고정 컬럼으로 모델링했다가, "무엇을 1급 개체로 다뤄야 하나"를 다시 물으며 인스턴스 기반 모델로 전환했고, 속성의
range도 문자열로 뒀다가 클래스 참조로 분리했습니다. 온톨로지 개념을 RDB로 옮기는 간극이 이 시스템 설계 작업의 본질이었어요. - Dublin Core는 화면 설계 지침이 됐습니다. 상세 화면의 항목 구성(
dct:title,dct:modified등)과 "값이 URL이면 상호 참조 링크로 렌더"하는 방식은 DCMI Terms 페이지 스타일을 따랐습니다. 표준 어휘를 쓴다는 건 필드명만 빌리는 게 아니라 표현 관례까지 따라간다는 뜻이었습니다. - 6절 데이터 카탈로그의 단점 목록은 예언이 됐습니다. 공부할 때 "메타데이터가 실제 데이터와 어긋나면 신뢰도 저하"라고 적었는데, 운영에서 정확히 그 문제와 싸웠습니다. 카탈로그는 만드는 것보다 어긋나지 않게 유지하는 것이 일이었어요.
- 교통 데이터에 DCAT이 왜 어려운가(실시간성·구조 다양성·도메인 어휘 부재)는 실제 업무 질문이었습니다. 관련 표준 조사는 ITS·V2X 표준 정리에 따로 있습니다.
돌아보면
- 개념 공부와 실무의 거리가 이렇게 가까운 경우는 드물었습니다. 프런트 경력 대부분의 공부는 "언젠가 쓸 지식"이었는데, 이 글의 내용은 다음 분기에 테이블 설계로 돌아왔어요. 도메인이 표준(W3C) 위에 있는 시스템에서는 표준 문서 읽기가 곧 요구사항 분석이었습니다.
- 한계 — 이 글은 RDF를 다루지만 실제 시스템은 트리플 스토어가 아니라 RDB 위에 온톨로지 구조를 얹은 것입니다. SPARQL, 추론(reasoning), OWL의 표현력 같은 시맨틱 웹의 깊은 층은 써보지 못했고, 그 층이 필요한 규모가 언제 오는지도 아직 모릅니다.