온톨로지는 실제로 어디에 쓰이나

난이도 — 입문 (4편을 읽었다면 더 쉽다)

4편에서 RDF와 추론을 다루고, 5편에서 프론트엔드 코드에 이미 깔려 있다는 이야기를 했다. 그런데 한 가지가 계속 허전했다.

"그래서 이걸 진지하게 쓰는 데가 어디야?"

메타태그나 블로그 태그는 온톨로지의 아주 얕은 쪽이다. 이 글은 깊게 쓰는 곳을 본다. 먼저 직접 만져 보고, 실제 파일 형식을 읽어 보고, 그다음 의료와 국방으로 간다.

먼저 직접 해 보자 — 위키데이터

읽는 것보다 눌러 보는 게 빠르다. 위키데이터(Wikidata)는 세계 최대 공개 지식 그래프이고, 누구나 웹에서 바로 질의할 수 있다.

https://query.wikidata.org

여기 접속해서 아래를 붙여 넣고 왼쪽 파란 ▶ 버튼을 누르면 된다.

SELECT ?item ?itemLabel WHERE {
  ?item wdt:P31 wd:Q146 .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "ko,en". }
}
LIMIT 10

무슨 뜻인지 한 줄씩 보면 이렇다.

즉 "집고양이인 것들을 보여줘"다. 실행하면 역장 고양이 타마, 치료 고양이 오스카, 클린턴 대통령의 삭스 같은 유명한 고양이들이 나온다.

위키데이터에서는 모든 것에 번호가 붙는다. `Q`로 시작하면 사물·개념, `P`로 시작하면 관계다. Q146이 집고양이, P31이 "~의 사례다"인 식이다. 4편에서 "이름표는 주소로 적는다"고 한 것이 실제로는 이 번호 체계다.

진짜 재미있는 건 이 질의다

4편에서 "관계 자리를 비워 놓고 물어볼 수 있다"고 했다. 그걸 실제로 해 보자. 손흥민의 번호는 Q439722다.

SELECT ?propLabel ?valueLabel WHERE {
  wd:Q439722 ?p ?value .
  ?prop wikibase:directClaim ?p .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "ko,en". }
}
LIMIT 15

무엇이 들어 있는지 하나도 모르는 상태로 "손흥민에 대해 적힌 거 다 보여줘"라고 묻는 것이다. 결과 일부는 이렇다.

여기서 "군인으로서의 계급: 이등병"을 보자. 이게 RDF의 성격을 한 방에 보여준다.

축구선수를 담는 표를 설계할 때 "군인 계급" 칸을 만들 사람은 없다. 그런데 손흥민은 군 복무를 했으니 그 사실이 존재한다. 표라면 칸을 새로 만들고 나머지 선수 수만 명에게 빈칸을 남겨야 한다.

RDF에서는 그냥 줄 하나가 추가됐을 뿐이다. 4편에서 "칸을 추가하는 게 아니라 줄을 추가한다"고 했던 말이 바로 이런 상황을 뜻한다.

그래프를 물어봤는데 왜 표가 나오지?

여기서 한 번 걸릴 만한 지점이 있다. 그래프를 질의했는데 결과는 표로 나온다. 뭔가 잘못한 걸까?

아니다. `SELECT`은 원래 표를 돌려준다.

SELECT이 하는 일은 "빈칸에 들어갈 값의 조합을 찾아 오기"다. 빈칸이 ?관계, ?값 두 개니까 결과도 두 칸짜리 표가 된다. 그래프를 뒤져서 찾은 답을 표에 담아 주는 것이라, 표로 보이는 게 정상이다.

그래프 자체를 받고 싶으면 다른 질의 종류를 쓴다.

CONSTRUCT로 같은 것을 물어보면 이렇게 된다.

CONSTRUCT { ?s ?p ?o }
WHERE {
  VALUES ?s { wd:Q439722 }
  ?s ?p ?o .
}
LIMIT 10

이번엔 결과 컬럼이 내가 붙인 이름이 아니라 `subject` · `predicate` · `object`로 고정돼 나온다. 표처럼 그려 주긴 하지만, 받아온 것은 표가 아니라 트리플 묶음이다.

결과를 다른 모양으로 보기

결과창 왼쪽 아래 `Table ▾` 를 누르면 보기 방식을 바꿀 수 있다. Graph builder를 고르면 관계를 그래프로 그려 준다.

재미있는 건 일부 항목이 회색으로 비활성돼 있다는 점이다. Map은 결과에 좌표가 있어야, Tree는 부모-자식 관계가 있어야 켜진다. 즉 내 질의가 뽑아 온 모양에 따라 쓸 수 있는 시각화가 정해진다.

실제 파일은 어떻게 생겼나 — Turtle

4편에서는 트리플을 읽기 쉽게 늘어놓았지만, 실제 파일은 Turtle이라는 문법으로 적는다. .ttl 확장자를 쓰고, 이름은 Terse RDF Triple Language의 줄임이다.

@prefix ex:   <https://example.org/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:손흥민  a          ex:축구선수 ;
           ex:소속팀   ex:토트넘 ;
           ex:별명     "쏘니" .

ex:토트넘  a          ex:프리미어리그팀 ;
           ex:연고지   ex:런던 .

ex:프리미어리그팀  rdfs:subClassOf  ex:축구팀 .

기호는 다섯 개만 알면 읽을 수 있다.

맨 아래 subClassOf 한 줄이 4편에서 본 추론의 근거다. "프리미어리그팀은 축구팀의 한 종류"라고 적어 두면, 토트넘이 축구팀이라는 걸 아무도 적지 않아도 기계가 끌어낸다.

같은 내용, 다른 표기

RDF를 적는 방법은 여러 가지다. 내용은 같고 문법만 다르다. 같은 문서를 들여쓰기만 바꿔 저장하는 것과 비슷하다.

N-Triples는 이렇게 앙상하다. 약어가 없어서 한 줄이 길어지지만, 기계가 처리하기엔 오히려 편하다.

<https://example.org/손흥민> <https://example.org/소속팀> <https://example.org/토트넘> .

참고로 앞에서 본 위키데이터 화면의 다운로드 버튼에는 Turtle이 없다. JSON·TSV·CSV 같은 표 형식만 준다. SELECT 결과는 표라서 그렇다. Turtle로 받으려면 CONSTRUCT 질의를 API로 직접 호출하면서 원하는 형식을 지정해야 한다.

의료 — 온톨로지가 가장 크게 성공한 분야

여기서부터가 본론이다. 온톨로지를 가장 오래, 가장 크게 쓰는 곳은 병원과 생명과학이다. 이유가 세 가지 있다.

첫째, 용어가 난장판이다. 심근경색, myocardial infarction, MI, heart attack이 전부 같은 것이다. 병원마다, 나라마다, 의사마다 다르게 쓴다.

둘째, 추론이 실제로 필요하다. "심혈관질환 환자를 모두 찾아라"는 질의에 심근경색이나 협심증으로만 기록된 환자도 나와야 한다. 계층을 타고 내려가는 추론이 없으면 환자를 놓친다.

셋째, 모호함이 사람을 죽인다. 약물 상호작용 경고나 알레르기 확인 같은 데서 용어가 어긋나면 사고가 난다.

주요 온톨로지는 이렇다.

희귀질환 진단 — 추론이 사람을 돕는 순간

가장 인상적인 사례는 HPO(Human Phenotype Ontology)다.

희귀질환은 의사가 평생 한 번 볼 수도 있는 병이다. 증상 조합을 다 외우는 건 불가능하다. 그래서 환자 증상을 HPO 용어로 기록하면, 시스템이 그 조합과 맞아떨어지는 후보 질병과 유전자를 추론해 제시한다.

사람 기억력으로 안 되는 일을 온톨로지가 메우는 것이다. 1편에서 "개는 숨을 쉰다"로 설명했던 그 추론이, 여기서는 진단을 돕는 데 쓰인다.

Gene Ontology나 HPO는 이런 모양으로 배포된다. is_a 한 줄이 계층을 만들고, 그게 추론의 근거가 된다.

[Term]
id: GO:0006915
name: apoptotic process
is_a: GO:0012501 ! programmed cell death

한 가지 덧붙이면, SNOMED CT는 무료가 아니다. 라이선스가 필요하다. 자유롭게 살펴볼 수 있는 건 Gene Ontology, HPO, LOINC 쪽이다. 한국의 질병 분류는 ICD를 바탕으로 한 KCD를 쓴다.

국방·정보 분석 — 뜻밖의 뿌리

이쪽도 실제 사용처다. 그리고 재미있는 역사가 있다.

우리가 쓰는 온톨로지 언어 OWL의 직계 조상이 DAML인데, 이건 DARPA Agent Markup Language의 줄임이다. 이름 그대로 미 국방부 DARPA가 자금을 댄 프로젝트였다. DAML이 유럽의 OIL과 합쳐져 DAML+OIL이 되고, 그것이 W3C 표준 OWL이 됐다.

즉 지금 웹 표준인 온톨로지 언어의 뿌리에 국방 연구가 있다.

실제 쓰임은 세 갈래다.

연결 분석(link analysis) — 정보 분석의 핵심 업무다. 사람·조직·사건·장소·계좌를 노드로 놓고 관계를 이어서 "이 인물과 저 조직이 몇 다리로 연결되는가"를 추적한다. 본질적으로 지식 그래프 문제다. 상용 사례로는 팔란티어(Palantir)가 유명한데, 자사 플랫폼의 데이터 모델을 아예 "온톨로지"라고 부른다.

지휘통제 데이터 교환 — NATO의 JC3IEDM(STANAG 5525)이 대표적이다. 여러 나라 군대가 연합작전을 하려면 "적", "부대", "위치"의 뜻이 서로 통해야 한다. 나라마다 시스템이 다르니 공통 의미 모델이 필수다.

센서 융합 — 위성·레이더·통신처럼 성격이 다른 데이터를 합칠 때 공통 의미 체계가 필요하다.

그 밖의 분야

그리고 요즘 가장 활발한 곳은 AI다. LLM의 환각과 다단계 추론 약점을 지식 그래프로 보완하는 접근이 널리 시도되고 있다. 벡터 검색은 "비슷한 문서"를 잘 찾지만, "A의 상사의 상사"처럼 관계를 여러 번 타는 질문은 그래프가 훨씬 잘한다.

왜 하필 이 분야들이었나

목록을 보면 공통점이 있다. 범위가 좁고, 참여자가 협력할 동기가 강한 분야다.

2000년대 초에는 "시맨틱 웹이 웹 전체를 기계가 이해하게 만든다"는 큰 그림이 있었다. 그 그림은 그대로 실현되지 않았다. 모두가 합의해야 하는 비용이 너무 컸기 때문이다.

반면 의료와 생물학은 성공했다. 목숨과 연구 재현성이 걸려 있으니, 수십 년에 걸쳐 합의를 만들 이유가 있었다.

4편에서 적었던 결론이 이 역사의 교훈과 정확히 맞아떨어진다.

직접 설계는 최소로, 이미 있는 공용 사전을 최대한 재사용하고, 추론은 꼭 필요한 곳에만.

정리

• 위키데이터에서 지금 바로 질의해 볼 수 있다. 개념을 읽는 것보다 한 번 눌러 보는 게 빠르다.
• 실제 파일은 Turtle로 적는다. 기호 다섯 개만 알면 읽힌다.
• 의료가 가장 성공한 분야다. 용어 통일, 추론, 안전이라는 세 가지 이유가 모두 강했다.
• 국방도 실제 사용처이고, 뜻밖에도 OWL의 뿌리가 DARPA 프로젝트다.
• 온톨로지가 성공하는 조건은 기술이 아니라 합의 가능성이다.

여기서 시리즈를 마친다. 1편에서 옷장 서랍·지하철 노선도·가족관계도로 시작한 이야기가, 병원과 국방 표준까지 왔다. 세 용어를 구분하는 것으로 시작했지만 결국 남는 질문은 하나다. 이 데이터에서 무엇을 관계로 볼 것인가.