[온톨로지 기반 GraphRAG] (4) OWL과 SHACL

이번 편은 시리즈의 기술적인 내용이 많이 나오는데 본론(제약이 검색을 보조하는 구조)에 들어가기 전에 짚고 넘어가야 할 게 있다. OWL, SHACL, SWRL이 각각 뭐고, 서로 뭐가 다를까?

공부를 해도 개념만 보면 헷갈린다... 이게 쿼리 언어인가? 어떤 툴의 기능인가? 설정 파일인가? 감을 잡기 어렵다..

그리고 개인적으로도 OWL에서 domain/range를 선언하는 것과 SHACL이 하는 게 어떤 차이일까? 나도 이걸 명확하게 설명하려고 하니 한 번 정리가 필요했다.

1.LPG와 OWL의 차이

앞 편들에서 "LPG는 스키마 제약이 없다"고 계속 말해왔는데, 정확히 하면 LPG에 스키마가 아예 없는 건 아니다. 있긴하지만 성격이 다르다.

 

Neo4j 기준으로 LPG의 스키마 관리는 세 겹으로 나뉜다.

① 엔진이 강제하는 제약: 유니크 제약, 속성 존재 제약, 속성 타입 제약. 관계형 DB의 제약과 비슷한 결이다.

② 관찰되는 스키마: db.schema.visualization()처럼 선언된 스키마를 읽는 게 아니라 실제 데이터를 스캔해서 구조를 추론한다. 마약 데이터가 복잡하면 추론된 스키마도 복잡하다.

③ 그 외: "manages의 주어는 Person이어야 한다" 같은 의미 수준 규칙은 엔진이 몰라서, 애플리케이션 코드나 적재 파이프라인, 팀 컨벤션 문서가 담당한다.

 

RDF/OWL은 스키마(TBox)가 데이터(ABox)와 같은 그래프 안에 트리플로 존재한다.

"Employee는 Person의 하위 클래스다"라는 스키마 선언 자체가 :Employee rdfs:subClassOf :Person .이라는 한 줄의 데이터다. 

 

요약하면, LPG는 스키마를 강제하지 않아서 관리가 팀의 규율과 파이프라인 몫으로 남고, RDF/OWL은 스키마가 형식 언어라서 부담이 초기 만드는 단계로 앞당겨진다. 어느 쪽이 낫다기보다 비용을 언제 치르느냐의 차이일 수 있다.

 

2. OWL 추론을 위한 선언이지, 검증기가 아니다

처음 배울 때 직관과 반대라서 나도 많이 헷갈리는 지점이다.

 

OWL로 이렇게 선언했다고 가정하고,

:manages rdfs:domain :Person .    # manages의 주어는 Person

그리고 데이터에 이런 트리플이 들어왔다.

:projectX :manages :teamA .      # 프로젝트가 뭔가를 manage?

 

상식적으로는 "위반! 에러!"가 나야 할 것 같다. 그런데 OWL 추론기는 에러를 내지 않는다.

 

대신 이렇게 추론한다. "manages의 주어는 Person이라고 했지. projectX가 manages의 주어네. 그러면 projectX는 Person이구나."

 

그래서 :projectX a :Person이라는 새 트리플이 도출된다. 잘못된 데이터를 거부하는 게 아니라, 잘못된 데이터에 맞춰 세계를 넓혀버리는 것이다.

 

왜 이러냐면 OWL이 열린세계 가정(Open World Assumption) 이기 때문이다. 이 가정은 "명시되지 않은 것은 거짓이 아니라 아직 모르는 것"이라는 철학이다. 웹의 분산된 지식을 다루려던 시맨틱 웹의 설계 사상으로는 합리적인데, 데이터 품질 검증이라는 용도에는 정반대로 작동한다. OWL의 domain/range는 검증 규칙이 아니라 추론 규칙이다.

 

그럼 OWL은 뭘 위해 쓰는가. 새로운 사실을 도출하는 데 쓴다.

• :Employee rdfs:subClassOf :Person → 직원을 조회하면 Person 쿼리에도 걸린다 (상속)
• :partOf a owl:TransitiveProperty → 부품→모듈→제품 체인에서 부품→제품이 자동 도출된다 (전이)
• :manages owl:inverseOf :managedBy → 한 방향만 저장해도 반대 방향 질의가 된다 (역속성)

OWL과 SPARQL의 장점으로 얘기했던 것들이 전부 이 추론 능력이다.

3. SHACL 검증

OWL이 검증을 안 해주니까, 검증 전용 표준이 따로 만들어졌다. 그게 SHACL(Shapes Constraint Language, 2017년 W3C 권고)이다. 정체를 명확히 하면 아래와 같다.

• SHACL은 쿼리 언어가 아니다. 특정 툴의 기능도 아니다. RDF로 작성하는 제약 선언 언어다. "Employee 노드는 이런 모양이어야 한다"를 기술한 것이 Shape이고, Shape들을 모아둔 문서를 Shapes Graph라고 부른다
• Shapes Graph는 그 자체로는 아무것도 안 한다. 검증기(validator)라는 별도 프로그램이 (데이터 그래프, Shapes Graph)를 입력받아 검증 리포트(Validation Report)를 출력한다. 오픈소스로는 파이썬의 pySHACL, Java의 TopBraid SHACL 등이 있고, 상용 트리플스토어(GraphDB, Stardog 등)는 적재 시점 검증 기능으로 내장하고 있다

즉, SHACL Shape은 일종의 소스 코드이고, 검증기는 그걸 실행하는 프로그램이고, Validation Report가 실행 결과다.

 

실제 Shape이 어떻게 생겼는지 보자. "직원은 부서에 정확히 1개 소속되어야 하고, 소속 대상은 반드시 부서여야 한다"는 규칙이다.

:EmployeeShape a sh:NodeShape ;
    sh:targetClass :Employee ;          # 이 Shape은 모든 Employee에 적용
    sh:property [
        sh:path :worksIn ;              # worksIn 속성은
        sh:minCount 1 ; sh:maxCount 1 ; # 정확히 1개
        sh:class :Department ;          # 값은 Department 인스턴스여야 함
    ] .

 

그리고 파이썬에서는 이렇게 검증할 수 있다.

from pyshacl import validate

conforms, report_graph, report_text = validate(
    data_graph="employees.ttl",
    shacl_graph="shapes.ttl",
)
print(conforms)      # False
print(report_text)   # 어느 노드가 어떤 제약을 어떻게 위반했는지

 

핵심은 SHACL이 닫힌세계로 검사한다는 점이다.

 

직원 노드에 worksIn이 없으면 OWL처럼 "아직 모르는 것"으로 넘어가지 않고 "minCount 1 위반"이라고 리포트에 적는다. 그리고 이 리포트가 구조화된 RDF라서, self-correction 루프처럼 기계가 읽고 다음 행동을 결정하는 입력으로 쓸 수 있다. 이러한 특성이 SHACL이 중요한 이유다.

 

여기서 내가 헷갈렸던 것은 "OWL에도 cardinality 제약이 있지 않나?" owl:maxCardinality 같은 게 있어서 유사하다 생각해서 직관적인 이해가 어려웠다. 그런데 조사해보니 이것도 domain/range와 똑같은 함정이 있다.

 

OWL의 cardinality는 세계에 대한 논리적 주장이지, 데이터 검사 규칙이 아니다.

worksIn에 owl:maxCardinality 1을 선언했는데 어떤 직원이 부서 A와 B 양쪽에 worksIn으로 연결되어 있으면, OWL 추론기는 "위반"이라고 하는 대신 "그럼 A와 B는 같은 부서구나(owl:sameAs)"라고 결론낸다. RDF에서는 서로 다른 URI가 같은 실체를 가리킬 수 있다는 전제가 있기 때문이다. A와 B가 서로 다르다고 명시(owl:differentFrom)되어 있을 때에만 비로소 논리 모순이 검출된다. owl:minCardinality는 값이 그래프에 하나도 없어도 "어딘가에 존재할 텐데 아직 모를 뿐"으로 처리되어 아무 일도 일어나지 않는다.

 

반면 SHACL의 sh:minCount/sh:maxCount는 지금 그래프에 실제로 존재하는 트리플 개수를 세고, 어긋나면 위반을 보고한다. 같은 cardinality라는 단어를 쓰지만 하는 일이 완전히 다른 것이다.

 

	OWL	SHACL
목적	새 사실의 추론	데이터 형태의 검증
세계관	개방세계 (모르는 건 미정)	폐쇄세계 (없으면 위반)
이상한 데이터를 만나면	사실을 도출해서 수용	위반 리포트 출력
cardinality의 의미	논리적 주장 (초과 시 sameAs 추론)	실제 트리플 개수 검사
실행 주체	추론기 (reasoner)	검증기 (validator)
산출물	추론된 트리플	Validation Report (RDF)

 

 

4. SWRL  도메인 규칙로 새 사실 만들기

SWRL(Semantic Web Rule Language)은 OWL 공리로는 표현이 안 되는 if-then 규칙을 쓰는 언어다. 이것도 쿼리가 아니고 툴 기능도 아니고, 규칙 선언 언어이며 추론기(Pellet 등, 주로 Protégé에서 사용)가 실행한다.

Person(?p) ∧ hasCertificate(?p, :CertA) ∧ hasExperience(?p, ?y) ∧ swrlb:greaterThan(?y, 3)
    → eligibleFor(?p, :RoleB)

 

해석하면 "자격증 A가 있고 경력이 3년 넘으면 직무 B에 적격"이라는 규칙이다.

 

실행하면 조건을 만족하는 사람마다 eligibleFor 트리플이 새로 도출된다. 그러니까 SWRL은 성격상 OWL 에 가깝다. 검증이 아니라 추론(사실 생성)을 한다.

 

참고로 실무에서는 SWRL 대신 SHACL-AF(SHACL Advanced Features)로 같은 일을 하는 경우가 많아졌다고 한다.

SHACL-AF는 SHACL 본 권고안에 담기지 않은 확장 기능을 모은 W3C 문서인데(정식 Recommendation이 아니라 Working Group Note라는 점은 알아둘 것), 핵심은 SHACL Rules다.

Shape이 조건을 검사하는 데서 멈추지 않고, 조건을 만족하는 노드에 대해 새 트리플을 도출하는 규칙을 쓸 수 있게 한다. 단순한 패턴은 sh:TripleRule로, 복잡한 건 SPARQL CONSTRUCT를 그대로 품는 sh:SPARQLRule로 쓴다.

 

SWRL이 하던 if-then 사실 생성을 SHACL 문법 안에서 하는 셈이라, 검증(SHACL)과 규칙(SHACL Rules)을 표준 하나로 다룰 수 있고, pySHACL이 규칙 실행까지 지원해서 도구 접근성도 좋다. 그 밖에 커스텀 타깃, SHACL 함수 같은 확장도 SHACL-AF에 포함되어 있다.

 

여기까지 정리하면 역할 분담이 선명해진다. OWL은 어휘와 추론(상속·전이·역), SWRL/SHACL 규칙은 도메인 규칙 추론, SHACL은 검증으로 이해할 수 있다. 셋 다 RDF 위에서 돌아가는 선언 언어이고, 각각 추론기/검증기라는 실행 주체가 따로 있다.

5. 온톨로지 기반 검색과 추론

실제 현업에서의 요구사항이나 질문은 다중 홉이 필요한 경우가 많다.

예를 들어, "김OO과 같은 자격증을 가진 사람이 참여한 프로젝트의 발주처는?" 같은 질문은 시드 엔티티(김OO)에서 출발해 그래프를 몇 홉 확장해가며 근거를 모아야 한다.

 

제약이 없는 GraphRAG는 이 확장을 임베딩 유사도나 LLM의 판단에 맡긴다. 여기에 앞서 설명한 것들을 활용하면 확장의 매 단계가 통제된다.

 

확장 허가는 OWL. 노드 n에서 속성 p를 따라 확장하려 할 때, n의 타입이 p의 domain과 호환되는지 먼저 본다. Project 노드에서 :manages를 따라가는 확장은 domain 위반이므로 후보에서 제외한다. 쿼리 생성 시점이 아니라 탐색의 매 홉마다 적용하는 것이다. 역속성·전이 속성 덕에 확장 방향의 표현력은 오히려 늘어난다.

 

후보 가지치기는 SHACL. 확장으로 모인 부분 서브그래프를 Shape으로 검증해서, 위반(sh:Violation)이 있는 후보는 쳐낸다. 예컨대 "부서 소속이 2개인 직원"이 경로에 끼어 있다면 그 데이터는 오염됐을 가능성이 높으니, 그 경로를 근거로 쓰지 않는 것이다. 매 홉 전체 검증은 비싸니까 새로 늘어난 부분(frontier)만 증분 검증하는 식으로 비용을 관리한다.

 

근거 보강은 SWRL/SHACL 규칙. 모인 근거 위에서 도메인 규칙을 발화시켜 파생 사실을 추가한다. 이때 파생 트리플에는 "어느 규칙이 만들었는지"를 태그로 남긴다

이 구조의 성질을 한 줄로 말하면: 생성기(LLM)에 도달하는 근거는 전부 Shape 검증을 통과한 것으로 제약한다는 것이다. LLM이 환각을 일으킬 여지가 없어지는 건 아니지만, 적어도 "오염된 근거 때문에 생기는 환각"은 구조적으로 차단된다.

6. 한계점

이 구조가 공짜가 아니라는 것도 적어둔다. 첫째, 매 홉 검증은 지연을 더한다. 증분 검증으로 완화해도 무제약 탐색보다는 느리다. 둘째, Shape의 품질이 곧 검색의 품질이 된다. 지나치게 엄격한 Shape은 멀쩡한 근거를 쳐내고(과잉 차단), 느슨한 Shape은 있으나 마나다. Shape 저작이 프롬프트 엔지니어링만큼이나 중요한 엔지니어링 활동이 된다는 뜻이다. 셋째, OWL의 개방세계와 SHACL의 폐쇄세계가 한 시스템에 공존하므로, 어떤 판단을 어느 가정으로 했는지 설계 문서에 남겨두지 않으면 나중에 디버깅이 괴로워진다.

 

다음 5편은 이렇게 모은 근거로 답을 만들 때, "이 답이 어떤 쿼리·어떤 공리·어떤 검증을 거쳤는지"를 답변에 딸려 보내는 provenance 이야기다.

 

참고

글에서 언급한 표준들은 전부 공개 문서라 원문을 직접 볼 수 있다.

• SHACL  W3C Recommendation (2017). 검증 언어의 본 표준
• SHACL-AF (Advanced Features)  W3C Working Group Note. SHACL Rules, 커스텀 타깃 등. 정식 권고안이 아니라는 점 유의
• OWL 2  W3C Recommendation, Overview. 프로파일(QL/EL/RL) 설명 포함
• RDF Schema (RDFS)  W3C Recommendation. rdfs:domain, rdfs:range, rdfs:subClassOf의 원 출처
• SWRL  W3C Member Submission (2004). 표준 트랙에 오르지 못한 제안 문서지만 Protégé 생태계에서 사실상 표준처럼 쓰였다
• pySHACL  GitHub. 이 글의 검증 예제에 사용한 오픈소스 검증기. SHACL-AF 규칙 실행도 지원