업무 질문이 온톨로지의 계약이 되는 순간

Competency question을 예상 답, 추론 범위, 변경 회귀와 연결해 지식 그래프·온톨로지의 설계 요구와 검증 기준으로 사용하는 방법을 살펴본다.

AI로 생성한 개념 이미지이며, 실제 시스템 화면이나 운영 중인 온톨로지의 기록이 아니다.

가상의 전시 운영팀이 묻는다. “작품 ‘빛의 정원’의 2024년 전시 버전에 쓰인 프로젝터는 무엇이며, 그 장비가 바뀌면 다시 확인해야 할 설치 문서는 무엇인가?” 이 질문에 답하려면 작품 이름을 찾는 것만으로 부족하다. 작품과 버전, 전시 참여, 장비, 설치 문서가 구별되어야 하고, 어느 관계를 직접 기록하며 어느 관계를 추론할지도 정해야 한다. 답이 없을 때는 장비가 없다는 뜻인지, 기록이 아직 없다는 뜻인지도 구분해야 한다.

이런 질문을 competency question(CQ)이라고 부른다. CQ는 온톨로지가 지원해야 하는 업무 질문을 자연어로 적은 것이다. 그러나 질문 목록만 모아 두면 요구사항 메모에 그친다. 질문이 어떤 개념과 관계를 요구하는지, 어떤 답을 기대하는지, 어떤 추론을 허용하는지, 모델을 바꿨을 때 무엇을 다시 시험할지까지 연결해야 계약으로 작동한다.

이 글은 CQ를 데이터 입력 검사의 다른 이름으로 다루지 않는다. 최근 SHACL 글이 현재 데이터 그래프에 필수값과 형식이 갖춰졌는지를 다뤘다면, 여기서는 질문을 표현할 수 있는지, 공리와 사실에서 기대한 답이 나오는지, 변경이 기존 답의 의미를 깨뜨리지 않는지를 다룬다. 아래의 적용 절차는 관련 연구를 바탕으로 정리한 DEXA의 AKM 설계 제안이며, 실제 운영 시스템에 이미 구현되었다는 보고가 아니다.

질문을 설계 계약으로 읽기

CQ의 계보에서 자주 언급되는 Grüninger와 Fox의 1995년 방법론은 motivating scenario에서 출발해 비형식 질문을 만들고, 이를 표현하는 용어와 공리를 정한 뒤, 질문의 답을 보장하는 조건을 검토한다. 저자들은 CQ가 특정한 존재론적 약속을 자동으로 만들어 내는 것은 아니며, 선택한 개념화와 공리가 요구를 충족하는지 평가하는 기준이라고 설명한다.[1] 같은 질문에 답하는 모델이 둘 이상일 수 있기 때문에 CQ는 유일한 정답 설계도가 아니다.

그래도 질문은 모델에 무엇을 넣을지 결정하는 강한 근거가 된다. “작품 목록은 무엇인가?”만 필요하다면 작품명과 식별자로도 시작할 수 있다. 앞의 장비 변경 질문을 계약으로 채택하면 모델의 부담이 달라진다. 작품과 전시 버전을 하나로 합치기 어렵고, 장비 사용을 작품의 영구 속성으로 두기도 어렵다. 특정 버전에서 특정 장비가 사용되었다는 사건이나 구성 관계, 그 판단을 뒷받침하는 문서가 필요해진다.

여기서 먼저 적을 것은 클래스 이름이 아니라 답의 형태다. 예를 들어 예상 답을 다음처럼 정할 수 있다.

• 대상 버전: 작품 W의 2024 전시 버전 V
• 직접 사용 장비: 프로젝터 P
• 영향 문서: 설치 지침 D와 보정 기록 C
• 근거 상태: V와 P의 연결은 설치 목록에서 확인, C는 P의 모델군을 참조하므로 재검토 대상
• 답변 보류 조건: 버전 식별자가 없거나 장비와 문서의 관계 방향을 확인할 수 없음

예상 답은 현재 데이터에서 우연히 나오는 문자열이 아니다. 질문을 통과했다고 판정할 수 있는 최소 의미 구조다. relatedTo 하나로 모든 것을 연결해도 검색 결과는 많이 나올 수 있지만, 어떤 장비가 실제로 쓰였는지와 어떤 문서가 단지 비슷한 주제를 언급하는지를 구분하지 못한다. CQ는 관계의 이름과 방향, 시간 범위, 근거 수준을 더 구체적으로 만들도록 압박한다.

2024년에 공개된 CQ 유형 연구는 질문을 범위 설정, 내용 검증, 기반 온톨로지 정렬, 관계 분석, 메타속성 분석 등 서로 다른 목적으로 구분한다. 모든 CQ가 단순 조회형 질문은 아니며, 표현 언어나 내용 범위의 한계 때문에 형식화할 수 없는 질문도 있다고 지적한다.[2] 따라서 “누가 무엇을 했는가?”와 “이 관계는 시간에 따라 달라질 수 있는가?”를 같은 시험으로 취급해서는 안 된다. 전자는 구체적인 답 집합을 요구할 수 있고, 후자는 관계의 성격을 정하는 모델링 판단을 요구한다.

자연어 질문을 시험 자산으로 바꾸기

좋은 CQ 묶음은 자연어 문장, 형식 질의, 고정된 사례, 기대 결과가 서로 연결되어 있다. 자연어는 도메인 담당자와 합의하는 접점이고, SPARQL 같은 질의는 모델이 실제로 질문을 표현할 수 있는지 확인하는 실행 형식이다. 사례 데이터는 답을 계산할 작은 세계를 제공하며, 기대 결과는 통과와 실패를 나눈다.

앞의 질문에는 정상 사례만 두면 부족하다. 장비 P를 쓴 버전 V와 설치 문서 D를 넣으면 정답 경로가 동작하는지만 알 수 있다. 이름이 같은 다른 작품 버전, 작품 설명에서 P를 언급했지만 실제 사용 기록은 없는 경우, 장비는 확인됐으나 문서 연결이 없는 경우도 함께 둬야 한다. 이때 기대 결과는 각각 “다른 버전은 제외”, “언급만으로 사용 사실을 추론하지 않음”, “장비는 답하되 영향 문서는 미상으로 남김”이 된다.

이 구성을 빼면 질의가 실행된다는 사실과 업무 질문에 올바르게 답한다는 사실을 구별하기 어렵다. 너무 넓은 경로로도 결과 행은 만들 수 있다. 반대로 온톨로지에 필요한 개념이 있어도 질의가 잘못 작성되면 답을 놓친다. 그래서 CQ 시험은 적어도 다음 세 층을 따로 기록해야 한다.

1. 표현 가능성: 질문에 필요한 대상·관계·조건을 현재 어휘로 구별할 수 있는가.
2. 답의 적합성: 고정 사례에서 포함해야 할 답과 제외해야 할 답이 예상과 일치하는가.
3. 추론 경계: 직접 사실, 공리에서 따라 나오는 사실, 아직 알 수 없는 상태가 섞이지 않는가.

2025년 Lippolis 등의 연구는 사용자 이야기와 100개의 CQ를 요구사항으로 사용해 LLM이 OWL 초안을 만드는 두 기법을 평가했다. 평가는 CQ 모델링 비율만 보지 않고 불필요한 클래스와 속성, 구조적 문제, 전문가의 질적 판단을 함께 다뤘다.[3] CQ에 답하는 요소를 많이 생성했다고 좋은 온톨로지가 되는 것은 아니라는 뜻이다. 요구에 없는 속성을 넉넉히 추가하면 우연히 질문을 맞힐 가능성은 커지지만, 중복과 유지보수 비용도 늘어난다.

같은 해 공개된 Bench4KE는 실제 온톨로지 프로젝트 네 곳에서 모은 전문가 CQ 101개로 자동 CQ 생성 도구를 비교하는 기준선을 제안했다. 이 연구가 보여 주는 현재적 문제는 “질문을 자동으로 많이 만들 수 있는가”보다 질문 생성과 평가를 어떻게 재현 가능하게 비교할 것인가에 있다.[4] LLM이 낸 질문은 후보로는 쓸 수 있지만, 업무 담당자가 기대 답과 제외 조건을 붙이지 않으면 모델의 계약으로 승격되지 않는다.

추론과 변경의 회귀 범위를 정하기

CQ의 쓰임이 선명해지는 때는 온톨로지의 추론 규칙을 바꿀 때다. 예를 들어 usesEquipment의 역관계로 usedByVersion을 제공하면 같은 사실을 반대 방향에서도 찾을 수 있다. 장비 모델군과 설치 문서 사이의 규칙을 추가하면 특정 장비 교체가 어떤 문서 검토로 이어지는지 계산할 수도 있다. 이 기능은 편리하지만, 규칙이 넓어질수록 의도하지 않은 답도 함께 늘어난다.

추론을 도입할 때 CQ에는 “답해야 하는 것”과 함께 “답하면 안 되는 것”을 넣어야 한다. 장비 P가 모델군 M에 속하고 문서 D가 M을 다룬다는 이유로 D를 재검토 후보로 제시하는 것은 허용할 수 있다. 그러나 같은 제조사의 모든 문서를 영향 문서로 확장하거나, 작품 소개에 장비명이 한 번 등장했다는 이유로 실제 사용 장비라고 단정하는 것은 금지할 수 있다. 이런 제외 사례가 없으면 추론의 재현율만 커지고 의미의 정밀도는 무너질 수 있다.

변경 회귀는 파일이 열리는지만 확인하는 검사가 아니다. 클래스 병합, 관계 방향 변경, 상위 관계 추가, 동일성 규칙 수정 가운데 하나만 일어나도 기존 CQ의 답 집합과 근거 경로가 달라질 수 있다. 변경 요청에는 영향을 받는 CQ를 연결하고, 이전 버전과 새 버전의 차이를 다음 네 가지로 분류할 수 있다.

• 의도한 추가: 새 장비 교체 규칙 때문에 문서 C가 재검토 후보에 포함됨
• 의도한 제거: 단순 언급 문서가 사용 근거에서 제외됨
• 설명 가능한 재분류: 직접 답이던 항목이 추론 답으로 표시됨
• 회귀: 다른 작품 버전의 장비가 현재 버전 답에 섞임

Gómez-Pérez는 온톨로지 평가에서 일관성뿐 아니라 완전성, 간결성, 확장 가능성, 작은 변경에 대한 민감도를 함께 살펴야 한다고 정리했다.[5] 이 관점에서 CQ 회귀표는 “버전이 올라갔다”는 기록을 업무에 생긴 변화로 번역한다. 답이 달라졌다면 누가 의도했고 어떤 근거로 허용했는지가 남아야 한다. 결과가 같아도 근거 경로가 직접 사실에서 폭넓은 추론으로 바뀌었다면 검토 대상이 될 수 있다.

모든 CQ를 매번 전부 실행하는 방식도 비용이 크다. 각 CQ가 의존하는 클래스, 속성, 공리, fixture를 목록으로 만들면 변경된 요소와 연결된 시험을 우선 실행할 수 있다. 다만 공통 상위 개념이나 동일성 규칙처럼 영향 범위가 넓은 요소를 바꿀 때는 부분 실행을 신뢰하기 어렵다. 그때는 전체 CQ 묶음을 돌리고 답 집합뿐 아니라 제외 사례와 근거 유형까지 비교해야 한다.

AKM에서는 작은 질문 묶음부터 시작한다

DEXA의 AKM에 이 접근을 적용한다면 새 온톨로지 플랫폼을 먼저 도입할 이유는 없다. 이미 반복해서 묻지만 문서 검색만으로 답의 경계를 정하기 어려운 업무 질문 하나를 고르는 편이 낫다. 예를 들면 “같은 프로젝트의 어느 결정이 어떤 산출물 버전에 반영되었고, 아직 반영되지 않은 결정은 무엇인가?”처럼 대상의 동일성, 변경 시점, 근거 문서를 함께 요구하는 질문이다.

처음에는 CQ 카드 한 장이면 충분하다. 카드에는 질문, 질문을 쓰는 사람과 결정, 예상 답 형식, 포함·제외 사례, 미상으로 남길 조건, 필요한 개념과 관계, 실행 질의, 영향을 주는 모델 요소를 적는다. 구현 전에는 이 카드로 도메인 담당자와 용어를 맞추고, 구현 뒤에는 같은 카드를 fixture와 회귀 시험에 연결한다. 질문 문구를 바꿀 때도 단순 편집으로 끝내지 않고 예상 답과 기존 시험의 의미가 달라지는지 확인한다.

실무의 모든 질문을 CQ로 만들 필요는 없다. 단발성 탐색 질문, 답이 계속 변하며 별도 의사결정에 쓰이지 않는 질문, 모델 밖의 원문 판단이 핵심인 질문까지 고정 계약으로 만들면 유지비만 커진다. 반대로 반복되는 결정에 쓰이고, 틀린 답의 비용이 크며, 여러 사람이 답의 의미를 다르게 해석하는 질문은 좋은 후보가 된다.

CQ가 계약이 되면 온톨로지 설계 논쟁의 초점도 달라진다. “이 클래스를 넣을까?” 대신 “어떤 질문의 어떤 답을 위해 필요한가?”를 묻게 된다. “추론이 더 풍부해졌다” 대신 “새로 나온 답과 잘못 포함된 답은 무엇인가?”를 본다. “모델을 정리했다” 대신 “기존 업무 보장 가운데 무엇이 유지되고 무엇이 바뀌었는가?”를 확인한다.

물론 이 방식이 온톨로지의 사실성을 자동으로 보증하지는 않는다. fixture의 기대 답이 틀릴 수 있고, 업무 담당자가 중요한 질문을 빠뜨릴 수도 있으며, 형식 질의가 자연어 의도를 잘못 번역할 수도 있다. 그래서 CQ 계약에는 작성자, 검토자, 근거, 모델 버전, 마지막 재검토 시점을 남겨야 한다. 계약은 한 번 쓰고 잠그는 명세가 아니라, 업무가 바뀔 때 무엇을 다시 합의하고 시험해야 하는지 알려 주는 변경 기준이다.

Sources

1. Michael Grüninger, Mark S. Fox, Methodology for the Design and Evaluation of Ontologies, IJCAI-95 Workshop, 1995.
2. C. Maria Keet et al., Discerning and Characterising Types of Competency Questions for Ontologies, 2024.
3. Anna Sofia Lippolis et al., Ontology Generation using Large Language Models, 2025.
4. Anna Sofia Lippolis et al., Bench4KE: Benchmarking Automated Competency Question Generation, 2025.
5. Asunción Gómez-Pérez, Evaluation of Ontologies, 2001.