온톨로지 평가 방법론 정리: OQuaRE 정량 지표와 컴피턴시 질문 기반 검증 방식

핵심 메시지

• 온톨로지 품질은 하나의 점수로 요약되지 않기 때문에, 세미나는 구조적 정량 평가와 기능적·의미적 평가라는 두 축으로 나눠 접근한다.
• OQuaRE는 소프트웨어 품질 국제 표준인 SQuaRE를 온톨로지에 옮겨 온 프레임워크로, 지표를 계산해 1~5점으로 변환하고 이를 모아 특성별 강약점을 드러낸다.
• 컴피턴시 질문 기반 방식은 순서를 뒤집는다. 온톨로지를 만든 뒤 질문에 답하는지 확인하는 대신, 답해야 할 질문을 먼저 쓰고 거기서 테스트를 뽑아 온톨로지를 만든다.
• 질문에서 전제를 뽑아내면 '피자 클래스가 존재해야 한다' 같은 설계 조건이 되고, 이 조건들이 그대로 오서링 테스트가 된다.
• 두 논문은 경쟁 관계가 아니라 시점이 다르다. 질문 기반 방식은 구축 단계에서, OQuaRE는 완성된 산출물 평가 단계에서 쓰일 때 서로 보완한다.

쉽게 이해하기

서울대학교 산업공학과 석사과정 고재용 씨가 DSBA 연구실의 온톨로지·지식그래프 스터디에서 온톨로지 평가 방법론을 발표한 세미나다. 온톨로지를 평가하려 들면 기준이 한둘이 아니다. 구조가 안정적인지, 개념 사이의 관계가 충분한지, 수정과 확장이 가능한지, 다른 시스템과 잘 연결되는지, 사용자의 질문에 답할 수 있는지가 모두 평가 대상이다. 발표자는 그래서 품질을 단일 점수로 설명하기 어렵다고 보고, 정량적이고 객관적인 구조 품질 평가와 상대적으로 주관적인 기능적·의미적 평가로 나눠 논문 두 편을 소개한다. 두 논문에는 공통 저자가 있어 같은 흐름 속에서 나온 연구로 볼 수 있다는 설명도 덧붙인다.

설명의 공통 소재로는 직접 만든 피자 온톨로지가 쓰인다. 피자, 토핑, 고객 같은 개념이 클래스가 되고, 개념과 개념을 잇는 오브젝트 프로퍼티와 개념에 값을 붙이는 데이터 프로퍼티가 클래스들을 연결한다. 마르게리타 피자나 고객 001처럼 실제 객체 하나하나는 인디비주얼이 된다. 이렇게 만든 온톨로지를 두고 '이게 과연 괜찮은 온톨로지인가'를 묻는 것이 세미나의 출발점이다.

첫 논문 OQuaRE는 목적이 비슷한 온톨로지가 여러 개 있을 때 어느 것이 내 문제에 가장 맞는지 판단할 표준이 없다는 문제의식에서 출발한다. 기존 평가는 순위나 품질 같은 기준이 제각각이었다. OQuaRE는 소프트웨어 산출물이 사용자 요구를 만족하는지 검증하기 위해 만들어진 ISO/IEC 표준 SQuaRE를 온톨로지도 소프트웨어 산출물로 보고 옮겨 왔다. 평가하려는 요소를 '특성'으로 두고, 이를 하위 특성으로 쪼갠 다음, 하위 특성을 계산할 지표를 정의한다. 실제 계산은 반대 방향이다. 지표를 먼저 구하고, 지표를 모아 하위 특성 점수를 내고, 하위 특성을 다시 묶어 특성 점수를 만든다. 특성으로는 구조, 기능 적합성, 유지보수성, 신뢰성, 사용 용이성, 다른 시스템과의 결합 가능성, 이식성 등이 제시되지만 사용자가 자기 목적에 맞게 빼거나 더할 수 있다.

발표자는 피자 온톨로지의 유지보수성을 실제로 계산해 보인다. 비건 피자를 추가할 때 토핑 계층 일부만 고치면 되고 기존 피자들은 영향을 받지 않으니 유지보수성이 좋다고 말할 수는 있지만, 그것만으로는 너무 주관적이다. 그래서 모듈성, 재사용성, 분석 용이성, 변경 용이성, 변경 안정성 같은 하위 특성으로 나누고, 각각을 클래스당 프로퍼티·관계의 평균 개수, 계층의 최대 깊이, 클래스당 직접 하위 클래스 수 같은 지표로 잰다. 원래 값은 그대로 쓰지 않고 1점에서 5점까지의 척도로 변환하는데, 가장 만족스러운 경우가 5점이고 수용 불가한 경우가 1점이다. 이때 같은 지표라도 어떤 특성에는 가점, 다른 특성에는 감점으로 작용한다는 점이 중요하다. 이렇게 모듈성 4.66, 재사용성 5, 분석 용이성 4, 변경 용이성 5, 변경 안정성 3.33이 나오면 이를 평균해 유지보수성 4점이라는 결과를 얻는다. 논문은 측정 단위 온톨로지와 세포 종류 온톨로지에서 이 지표 기반 평가가 사람이 직접 한 평가와 비슷한 경향을 보였다고 보고한다.

두 번째 논문은 컴피턴시 질문 기반 온톨로지 오서링을 다룬다. 도메인을 잘 아는 전문가는 구조화된 표현을 쓰기 어렵고, 온톨로지 전문가는 도메인 지식이 부족하니 양쪽 다 어렵다는 것이 문제의식이다. 이 접근은 온톨로지가 답할 수 있어야 하는 질문을 먼저 적는다. '돼지고기가 들어간 피자는 무엇인가', '버섯이 없는 피자는 무엇인가', '가장 싼 피자는 무엇인가' 같은 것들이다. 이 질문들이 곧 온톨로지의 기능 요구사항이 된다. 다음으로 질문을 분해해 전제를 뽑는다. '돼지고기가 들어간 피자는 무엇인가'라는 질문이 성립하려면 피자 클래스가 있어야 하고, 돼지고기 토핑 클래스가 있어야 하고, 둘을 잇는 프로퍼티가 있어야 하며, 피자가 돼지고기 토핑을 가질 수도 있고 안 가질 수도 있어야 한다. 무조건 가지거나 무조건 안 가지면 연결 고리가 의미를 잃기 때문이다. 이 전제들이 그대로 오서링 테스트로 바뀌고, 온톨로지가 테스트를 통과하는지 검사할 수 있게 된다. 저자들은 질문을 모아 보니 12가지 패턴으로 정리되고 그중 여섯 개가 대표적으로 쓰인다는 점도 발견했다.

발표자는 이 방식이 걸려 넘어지는 지점도 짚는다. 하나는 답을 비교하거나 고르게 만드는 수식어다. '가장 싼'은 피자 하나만 보는 게 아니라 모든 피자와 모든 가격의 연결 관계를 훑어야 답할 수 있다. 수식어는 관계의 개수를 세는 종류와 데이터 값을 비교하는 종류로 나뉘는데, '토핑이 가장 많은 피자'는 연결된 프로퍼티 개수를, '가장 싼 피자'는 실제 가격 값을 비교해야 한다. 더 어려운 것은 세 개 이상의 대상이 한 관계로 동시에 묶이는 n항 관계다. '비건 고객에게 가장 좋은 피자는 무엇인가'는 피자, 고객, 식이 선호, 적합도를 모두 통합해야 답할 수 있어 단순한 이항 연결로는 표현되지 않는다. 논문은 추천이라는 새 클래스를 만들어 피자, 고객, 식이 선호를 하나로 묶는 방식으로 이를 푼다. 다만 이는 정답이 아니라 하나의 예시이며, 질문에 맞는 구조를 찾아 모델링해야 한다는 것이 논문의 취지라고 발표자는 정리한다.

결론에서 발표자는 두 논문을 하나의 흐름으로 붙인다. 온톨로지를 만드는 동안에는 컴피턴시 질문으로 테스트를 만들어 통과하는 구조를 세우고, 완성된 뒤에는 OQuaRE로 지표를 계산해 특성별 강약점을 분석하는 식이다. 한계도 분명하다. OQuaRE는 도메인마다 좋은 값의 기준이 달라지는 임계값 문제가 있고, 하위 특성의 중요도가 다른데도 단순 평균으로 묶어 버린다. 질문 기반 논문은 오서링 테스트가 실제로 효율과 생산성을 높이는지 검증을 후속 과제로 남겼고, 법률처럼 복잡한 도메인에서는 적용이 제한적일 수 있으며, 12가지 유형에 맞춰 질문해야 한다는 제약도 있다. 발표자는 사용자가 자유롭게 던진 질문을 대형 언어 모델이 정해진 유형으로 정형화해 주는 모듈을 앞단에 두면 이 제약을 풀 수 있을 것이라고 제안한다.

주요 인사이트

• 온톨로지 평가를 '몇 점짜리인가'로 환원하지 않고 특성별 강약점 프로파일로 보여주는 것이 OQuaRE의 실용적인 장점이다. 어떤 온톨로지는 구조는 좋지만 다른 기준에서 약할 수 있다.
• 같은 지표가 어떤 특성에는 가점, 다른 특성에는 감점으로 작용한다는 점은 지표를 단순 합산하면 안 되는 이유를 잘 보여준다.
• 질문을 먼저 쓰고 온톨로지를 나중에 만드는 순서 뒤집기는 소프트웨어 개발의 테스트 우선 방식과 발상이 같다.
• 질문에 답이 나오는지가 아니라 질문이 성립하는지를 본다는 점이 핵심이다. 전제를 뽑아내는 순간 그것이 설계 조건이 된다.
• n항 관계를 별도의 클래스로 승격시키는 해법은 추천처럼 여러 요소를 동시에 엮어야 하는 실무 문제에서 반복해서 쓸 수 있는 패턴이다.
• 자유로운 질문을 정해진 패턴으로 바꿔 주는 언어 모델 모듈을 앞단에 붙이자는 제안은, 논문이 나온 시점의 제약을 지금 기술로 푸는 자연스러운 확장 방향이다.

자주 묻는 질문

관련 AI 소식