개념 해설 · 2026-08-26
이 관계는 규칙인가, 정의인가
새 관계를 하나 만들 때마다 물어야 하는 세 가지 질문
2편 끝에서 막힌 질문이 있었다. equivalentClass 하나를 두고도 "AlternateName equivalentClass Alias"처럼 단순 동치 선언은 RL 규칙 하나로 충분했고, "Manager equivalentClass (Employee AND manages SOME Employee)"처럼 조건부로 정의된 동치는 DL 없이는 판정이 안 됐다. 같은 구문(equivalentClass)인데 하나는 RL이고 하나는 DL이었다. 구문만 보고는 구분이 안 된다는 뜻이다.
온톨로지에 새 관계를 하나 추가할 때마다 이 판단을 다시 해야 한다. 관계 이름과 구문만 보고는 안 되고, 그 관계가 실제로 어떻게 쓰일지까지 봐야 갈린다는 걸 equivalentClass 사례가 보여줬다. 매번 감으로 정할 수는 없어서, 1편에서 본 SKOS와 PROV-O의 선택, 2편에서 정리한 RL/DL의 계약을 절차로 압축해봤다.
질문 1: 이 관계는 늘 같은 종류의 사실인가
SKOS는 개념을 클래스가 아니라 인스턴스로 설계해서 애초에 subClassOf를 그대로 쓸 구조가 아니었다. 그런데 설령 개념을 클래스로 설계했다 해도, broader라는 이름 안에 상하위 개념과 부분-전체가 섞여 있어서 강한 의미를 주기 어려웠을 것이다. 관계 하나가 매번 다른 종류의 사실을 가리킨다면, 그 관계에 강한 의미(subClassOf 같은)를 주면 안 된다. 강한 의미를 주는 순간 reasoner는 그 의미가 항상 성립한다고 가정하고 전이적 추론을 돌린다.
반대로 관계가 항상 같은 종류의 사실만 가리킨다면 강하게 정의해도 된다. "hasManager"가 언제나 "고용 관계에서의 상급자"만 가리킨다면, domain/range를 강하게 걸고 inverseOf도 정의할 수 있다. PROV-O의 wasGeneratedBy도 마찬가지다. 이 관계는 맥락에 따라 다른 걸 뜻하지 않는다. 언제나 "이 Entity가 이 Activity에서 만들어졌다"는 한 가지 사실이다. 그래서 OWL 클래스와 property로 강하게 정의해도 문제가 안 생겼다.
질문 2: 틀린 추론과 비싼 계산 중 뭐가 더 두려운가
SKOS는 틀린 추론을 더 두려워했다. 검증되지 않은 시소러스 데이터에서 전이적 추론이 자동으로 돌면, 원문에 없는 관계가 사실처럼 나온다. 그래서 표현 자체를 약하게 만들어 틀린 추론이 발생할 여지를 없앴다.
PROV-O는 비싼 계산을 더 두려워했다. Provenance 기록은 표현이 명확하고 관계도 안정적이지만, 기록량이 많고 조회가 실시간이다. 어느 Agent가 만든 결과를 다음 turn에서 바로 참조해야 하는데, 그 결과가 어느 활동에서 나왔는지 확인하는 조회가 매번 복합 논리식을 풀어야 한다면 응답이 늦어진다. 그래서 표현은 다 갖추되 추론 프로파일을 RL로 눌러서 계산 비용을 예측 가능하게 만들었다.
내가 만드는 관계도 이 둘 중 어느 쪽이 더 아픈지 먼저 정해야 한다. 사람이 검수하지 않은 데이터가 많이 들어오는 관계라면 SKOS 쪽으로, 데이터는 깨끗한데 양이 많고 실시간 조회가 필요한 관계라면 PROV-O 쪽으로 기운다.
질문 3: 결론이 규칙 하나로 나오는가, 논리식을 풀어야 나오는가
마지막은 2편에서 다룬 형태 그대로다. "x type A, A subClassOf B ⊢ x type B"처럼 사실 하나와 규칙 하나를 맞대면 결론이 바로 나오면 RL이다. "Alice type Person, Alice hasChild Bob, Bob type Person"처럼 여러 사실을 논리식(Parent ≡ Person AND hasChild SOME Person)에 대입해야 결론이 나오면 DL이다.
이 구분이 앞의 두 질문과 늘 나란히 가지는 않는다. "같은 종류의 사실"이면서 "논리식을 풀어야" 나오는 관계도 있다. 이런 경우엔 DL로 정의하되, 그 정의가 실제로 자주 쓰이는지를 본다. 자주 쓰이면 설계 시점에 DL reasoner로 한 번 돌려서 결과를 RL 규칙(또는 그냥 assert된 사실)으로 미리 굳혀두고, runtime에는 그 굳힌 결과만 둔다. PROV-O가 다섯 개 예외를 제외하고 RL에 머문 것도 이 방식에 가깝다. 표현은 DL로 하되, 자주 쓰는 결론은 미리 계산해서 RL 급으로 내려둔다.
이 절충이 통하는 건 그 정의가 데이터가 바뀔 때마다 다시 계산해야 하는 게 아니라는 전제 위에서다. 정의된 클래스의 멤버십이 새 사실이 들어올 때마다 크게 바뀐다면, 미리 굳혀둔 결과가 금방 낡는다. 그럴 땐 절충이 아니라 DL reasoner를 runtime 가까이 둘 수밖에 없고, 그 비용을 감수할지는 다시 질문 2로 돌아가서 판단해야 한다.
실제로 하나 판정해보면
"supersedes"라는 관계를 새로 만든다고 하자. 문서 버전 관리에서 "이 문서가 저 문서를 대체한다"는 뜻이다. 세 질문에 통과시켜본다.
질문 1: 늘 같은 종류의 사실인가. 그렇다. supersedes는 언제나 "새 버전이 이전 버전을 대체한다"는 한 가지 의미만 가진다. broader처럼 상하위와 부분-전체가 섞이지 않는다. 강하게 정의해도 안전한 쪽이다.
질문 2: 뭐가 더 두려운가. 문서 이력이 잘못 연결되면(예: 대체 관계가 순환하면) 사용자가 최신 문서를 못 찾는다. 계산량보다 틀린 연결이 더 아프다. SKOS 쪽에 가깝다.
질문 3: 결론이 규칙 하나로 나오는가. "A supersedes B, B supersedes C ⊢ A supersedes C"는 규칙 하나로 풀린다. 다만 이 사슬이 순환하면(A가 결국 A를 대체하면) 모순이다. 순환 여부를 검사하는 건 RL 규칙 하나로는 안 되고, 그래프 전체를 훑어야 한다.
세 질문의 답이 갈렸다. 관계 자체는 RL로 정의할 수 있지만, 순환 검사는 DL reasoner의 consistency check에 가까운 작업이다. 그래서 supersedes는 RL 규칙(전이적 전파)으로 runtime에 두되, 새 supersedes 관계를 추가할 때마다 순환이 생기는지는 설계·검증 시점에 별도로 확인하는 쪽으로 정리된다. 관계 하나가 꼭 RL 아니면 DL로 깔끔하게 갈리지는 않았다.
세 질문을 하나로 합치면
| 질문 | RL 쪽 | DL 쪽 |
|---|---|---|
| 관계가 늘 같은 사실인가 | 아니오, 맥락마다 다르다 | 예, 항상 같은 의미다 |
| 뭐가 더 두려운가 | 틀린 추론 | 비싼 계산 |
| 결론이 어떻게 나오는가 | 규칙 하나로 즉시 | 논리식을 풀어야 |
세 질문에 답이 갈리면 판단이 애매해진다. 그럴 땐 DL로 정의만 해두고 runtime에는 미리 계산한 결과만 올리는 절충이 있다는 걸 PROV-O가 보여준다. 정의는 정확하게 해두고, 그 정의가 만드는 계산은 설계 시점에 한 번만 치른다.
아직 남은 것
이 절차를 지금 온톨로지 스킬의 스키마 하나하나에 적용해보진 않았다. 관계 열 개쯤 실제로 이 세 질문에 통과시켜보면, 질문이 세 개로 충분한지 아니면 더 필요한지가 보일 것 같다. 특히 "질문 1"과 "질문 3"이 갈리는 관계, 그러니까 늘 같은 사실인데 계산은 논리식을 풀어야 나오는 관계가 얼마나 자주 나오는지가 지금은 감이 없다.
처음 질문("결국 RDF/OWL로 다 표현할 수 있는 것 아닌가")에 RL과 DL 두 계약만 놓고 답하면 "표현은 다 되지만 다 쓰면 안 된다"였다. 다 쓰지 않기로 할 때, 무엇을 남기고 무엇을 뺄지 정하는 절차가 이 세 질문이었다. SKOS와 PROV-O는 이미 그 절차를 통과한 결과물을 보여준 거고, 내가 만드는 온톨로지는 이제 그 절차를 직접 통과시켜야 한다.
다만 이 세 질문은 RL과 DL 사이에서만 유효하다. OWL 2에는 규칙이냐 논리식이냐와는 다른 축에서 표현력을 깎은 프로파일이 두 개 더 있다. EL과 QL이다.