개념 해설 · 2026-08-26
EL과 QL은 또 다른 이유로 표현력을 깎았다
클래스 30만 개와, 기존 관계형 DB가 각자 다른 벽에 부딪혔다
1편 끝에 OWL 2의 네 프로파일 이름만 적어두고 넘어갔다. RL과 DL은 시리즈 내내 다뤘으니, EL과 QL이 남았다. 이 둘은 RL/DL과 다른 축에서 표현력을 깎았다.
RL과 DL의 트레이드오프는 "무엇을 규칙으로 풀고 무엇을 논리식으로 풀 것인가"였다. 이건 추론 방식의 문제였다. EL과 QL은 추론 방식이 아니라 온톨로지가 놓인 상황 자체가 다르다. 하나는 클래스가 지나치게 많은 상황이고, 다른 하나는 온톨로지 아래 이미 다른 시스템(관계형 DB)이 버티고 있는 상황이다.
EL: 클래스 30만 개를 몇 초 만에 정리해야 했다
SNOMED CT는 의료 용어 온톨로지다. 클래스가 30만 개가 넘는다. "심근경색"이 "허혈성 심장질환"의 하위 개념이고, "허혈성 심장질환"이 "심장질환"의 하위 개념이라는 식의 관계가 이 규모로 얽혀 있다.
DL reasoner로 이 정도 규모를 분류(classification)하려고 하면 시간이 감당이 안 된다. DL은 표현력이 넓은 대신, 그 표현력을 계산하는 비용이 온톨로지가 커질수록 예측하기 어려워진다는 걸 2편에서 봤다. 클래스 30만 개짜리 온톨로지에 그 비용을 그대로 물리면, 분류 하나 돌리는 데 시간이 얼마나 걸릴지 아무도 장담 못 한다.
OWL 2 EL은 이 문제에 표현력을 깎는 방식으로 답했다. 클래스 교집합(intersection)과 존재 한정(someValuesFrom, "SOME")은 허용하지만, 합집합(unionOf)과 부정(complementOf), 전칭 한정(allValuesFrom), cardinality 제약은 뺐다. 이렇게 줄인 표현력 안에서는 정합성 검사·클래스 포함관계 판정·인스턴스 판정이 전부 다항 시간(polynomial time) 안에 끝난다는 게 수학적으로 보장된다. 온톨로지가 커져도 계산 시간이 통제 불능으로 튀지 않는다는 뜻이다.
이 보장이 이론으로만 끝나지 않는다. ELK라는 EL 전용 reasoner는 30만 개 클래스짜리 SNOMED CT를 노트북에서 몇 초 만에 분류한다. 같은 작업을 범용 DL reasoner에 맡기면 훨씬 오래 걸리거나 아예 끝나지 않을 수 있다. EL이 무엇을 뺐는지가 아니라, 뺀 덕분에 무엇이 가능해졌는지를 보여주는 숫자다.
왜 합집합과 부정을 빼면 다항 시간이 보장되는지는 작은 예로 감이 잡힌다. "NOT HeartDisease"라는 부정 클래스가 있으면, reasoner는 그 클래스에 속하는지 판정하려고 존재하는 모든 클래스를 뒤져 "HeartDisease가 아닌 것"을 걸러내야 한다. 클래스가 늘어날 때마다 이 판정 범위도 같이 늘어난다. 합집합도 비슷하다. "A OR B"에 속하는지 확인하려면 A인지 B인지 매번 분기해서 따져야 하고, 이런 분기가 겹겹이 쌓이면 경우의 수가 클래스 수에 비례하지 않고 훨씬 빠르게 불어난다. EL은 존재 한정과 교집합만 허용해서, 이런 분기나 전역 탐색이 필요한 상황 자체를 만들지 않는다. "x가 A AND (B SOME C)에 속하는가"는 A에 속하는지, B SOME C에 속하는지를 각각 독립적으로 확인하고 합치면 끝나는 판정이라, 클래스 수가 늘어도 판정 하나의 비용은 크게 안 늘어난다.
QL: 기존 DB를 건드리지 않고 온톨로지로 물어야 했다
QL은 다른 상황에서 나온다. 회사에 이미 관계형 DB가 있다. 테이블과 컬럼으로 데이터가 쌓여 있는데, 그 위에 "고객"이나 "주문" 같은 개념 수준의 질문을 던지고 싶다. 온톨로지를 얹어서 개념으로 묻고 싶은데, DB 데이터를 온톨로지 형태로 다시 옮기는 건 하고 싶지 않다.
OWL 2 QL은 이 상황을 겨냥한다. 질의 응답(conjunctive query answering)을 표준 관계형 DB 시스템으로 그대로 처리할 수 있게 설계됐다. 온톨로지로 던진 질문을 SQL 질의로 재작성(rewriting)해서, 원본 DB에 그대로 물어보고 결과를 받는 구조다. 데이터는 한 줄도 옮기지 않는다.
이게 되려면 표현력을 QL 쪽에서도 깎아야 한다. subclass 관계의 왼쪽(하위 개념 쪽)에는 존재 한정을 허용하지만 오른쪽(상위 개념 쪽)에는 안 되는 식으로, 질의 재작성이 SQL 하나로 안전하게 끝나는 범위 안에만 머문다. 그 대가로 QL은 데이터 크기에 대해 LOGSPACE, 사실상 인덱스만 잘 타면 가벼운 비용으로 질의 응답을 보장한다. reasoner가 매번 추론을 새로 도는 게 아니라, SQL로 바뀐 질의를 DB 엔진이 처리한다.
재작성이 실제로 어떻게 일어나는지 보면 이렇다. "HeartPatient subClassOf (hasCondition SOME HeartDisease)"라는 정의가 있고, 사용자가 "HeartPatient를 다 보여줘"라고 물었다고 하자. 원본 DB에는 patients 테이블과 conditions 테이블만 있고 HeartPatient라는 개념은 어디에도 저장돼 있지 않다. QL reasoner는 이 질의를 "conditions 테이블에서 병명이 HeartDisease 계열인 행을 찾고, 그 환자 id로 patients 테이블을 조회하라"는 SQL로 풀어 쓴다. HeartDisease 아래 하위 질환이 여러 개 있으면 그 목록까지 반영해 SQL의 IN 절이나 UNION으로 펼친다. DB에는 새 테이블도, 새 컬럼도 추가되지 않는다. 질의만 온톨로지의 정의를 반영해 넓어질 뿐이다. 반대로 "hasCondition SOME HeartDisease"가 subclass의 오른쪽(어떤 클래스이기 위한 조건)에 있었다면 얘기가 달라진다. "이 환자가 HeartPatient의 상위 개념에 속하려면 어떤 질환이 존재해야 한다"는 조건은 존재를 가정하는 방향이라, SQL 하나로 안전하게 풀어 쓸 수 있는 형태를 벗어난다. QL이 왼쪽에서는 존재 한정을 허용하고 오른쪽에서는 막는 이유가 여기 있다.
2편에서 RL 규칙을 subclass_edges 테이블과 recursive CTE로 컴파일하는 이야기를 했는데, QL은 이 발상을 표준으로 만든 프로파일에 가깝다. 다만 RL은 "온톨로지 규칙을 미리 계산해 테이블로 굳혀둔다"는 쪽이고, QL은 "질의 자체를 SQL로 번역해 매번 원본 DB에 묻는다"는 쪽이라 방향이 다르다.
네 프로파일은 각자 다른 벽을 겨눴다
| 프로파일 | 무엇을 뺐나 | 대신 얻은 것 |
|---|---|---|
| DL | 안 뺌 (표현력 최대) | 정밀한 논리 추론, 대신 비용 예측 어려움 |
| RL | 논리식 기반 추론 | 규칙 기반 추론, 실시간·대규모 ABox에 적합 |
| EL | 합집합·부정·전칭·cardinality | 클래스 수가 커져도 다항 시간 분류 |
| QL | 복합 클래스 정의 대부분 | 기존 관계형 DB로 질의 응답 그대로 처리 |
RL과 DL의 트레이드오프는 "규칙이냐 논리식이냐"였다. EL과 QL은 다른 질문에서 나왔다. EL은 "클래스가 이렇게 많아도 분류가 끝나긴 하는가"였고, QL은 "이미 있는 DB를 안 건드리고 개념으로 물을 수 있는가"였다. 넷 다 "표현력을 다 쓰면 안 된다"는 같은 원칙 위에 있지만, 그 원칙이 겨눈 벽은 각각 달랐다.
시리즈를 매듭지으며
PROV와 SKOS를 보다가 시작한 질문("결국 RDF/OWL로 다 표현할 수 있는 것 아닌가")에는 네 개의 답이 있었던 셈이다. 시소러스 데이터의 잘못된 추론을 막으려는 답(SKOS), 대규모 provenance 기록의 비용을 누르려는 답(PROV-O, RL), 정밀한 설계 검증이 필요한 답(DL), 클래스 30만 개를 감당하려는 답(EL), 기존 DB를 그대로 쓰려는 답(QL). 표현력을 얼마나 깎을지는 매번 다시 물어야 하는 질문이었다.
이 시리즈를 시작할 때는 "RDF/OWL이 다 표현할 수 있다"는 전제 자체가 질문이라고 생각했다. 네 편을 거치고 나니 전제는 그대로 두고, 그 전제 다음에 오는 질문이 계속 갈라졌다. 어떤 관계는 표현하면 안 됐고(SKOS), 어떤 관계는 표현은 하되 계산은 누르고(PROV-O, RL), 어떤 관계는 정의 자체가 검증 대상이었고(DL), 어떤 상황은 클래스 수가 벽이었고(EL), 어떤 상황은 이미 있는 시스템이 벽이었다(QL). 온톨로지 하나를 설계한다는 건 표현력을 최대로 쓰는 일이 아니라, 지금 붙잡고 있는 상황에 맞는 벽을 골라 그 안에 머무는 일에 더 가까웠다.