AI 애플리케이션을 위한 온톨로지와 역량 모델링

분류: Layer 12 - AI 시스템 & LLM 애플리케이션 | 선수지식: L11-80 (평가), L12-40 (검색 증강 생성), L12-100 (Context)

AI 애플리케이션을 위한 온톨로지와 역량 모델링

1. 무엇을 배우는가

온톨로지(ontology)는 특정 도메인의 개념, 개념 사이 관계, 관계가 지켜야 할 제약을 명시한 의미 모델이다. 단어 목록을 만드는 데서 끝나지 않고, 서로 다른 데이터와 애플리케이션이 같은 용어를 같은 뜻으로 해석하게 한다.

역량 모델링(competency modeling)은 사람·에이전트·시스템이 어떤 상황에서 업무를 수행할 수 있는지를 행동과 증거로 정의하는 작업이다. **RAG(Retrieval-Augmented Generation, 검색 증강 생성)**는 질문과 관련된 외부 근거를 먼저 검색해 생성 입력에 붙이는 방식이고, **LLM-as-judge(대규모 언어 모델을 평가자로 쓰는 방식)**는 미리 정한 rubric에 따라 모델이 다른 답변이나 작업 결과를 점수화·분류하고 근거를 반환하게 하는 평가 패턴이다. 이 문서에서는 두 모델을 연결해 검색 결과와 판정이 같은 의미 계약을 공유하도록 설계한다.

학습 흐름은 다음 질문을 따른다.

무엇을 답해야 하는가?        -> competency question
어떤 개념이 필요한가?        -> class, relation, instance
어떤 상태가 유효한가?        -> constraint, cardinality
어떻게 저장하고 교환하는가?  -> JSON/application schema 또는 graph data model
어떻게 검색과 판정에 쓰는가? -> ontology + RAG + rubric
어떻게 바꾸고 비교하는가?    -> governance + versioning

2. Ontology의 정의와 경계

2.1 Taxonomy, ontology, knowledge graph

**Taxonomy(분류 체계)**는 대상을 상위·하위 범주로 나누는 계층 구조다. Incident > SecurityIncident > CredentialLeak처럼 “A는 B의 하위 종류다”를 표현하는 데 강하다. 그러나 “어떤 역할이 이 사고를 처리하는가”, “어떤 증거가 어떤 역량을 뒷받침하는가”까지 taxonomy만으로 표현하기는 어렵다.

**Ontology(온톨로지)**는 분류 계층에 관계의 의미와 제약을 더한다. 예를 들어 Role requires Competency, Evidence supports Behavior, Behavior demonstrates Competency를 별개의 관계로 정의하고, Evidence에는 원문 위치가 하나 이상 있어야 한다는 규칙도 둘 수 있다.

**Knowledge graph(지식 그래프)**는 개체와 관계를 노드·간선 형태로 저장한 데이터다. 온톨로지가 “무엇이 존재할 수 있고 관계가 무엇을 뜻하는가”라는 의미 모델에 가깝다면, 지식 그래프는 답변 42가 행동 B17의 증거다 같은 실제 instance를 담는다. 지식 그래프가 반드시 정교한 온톨로지를 가져야 하는 것은 아니며, 반대로 온톨로지도 반드시 graph DB에 저장할 필요는 없다.

구조	중심 질문	잘 표현하는 것	놓치기 쉬운 것
Taxonomy	무엇이 무엇의 하위 범주인가?	메뉴, 문서 분류, 상하위 개념	비계층 관계와 제약
Ontology	개념은 무슨 뜻이고 어떤 관계가 유효한가?	공유 의미, 관계, 제약, 추론 규칙	실제 데이터 운영 자체
Knowledge graph	실제 어떤 개체들이 어떻게 연결되어 있는가?	instance 연결, 다중 hop 탐색	명시하지 않은 의미와 품질 규칙
App schema	이 요청·레코드의 모양이 유효한가?	필드 타입, 필수값, API 입출력 검증	시스템을 가로지르는 관계의 의미

온톨로지를 특정 graph 표준이나 논리 언어의 동의어로 이해하면 범위가 지나치게 좁아진다. 작은 AI 앱은 JSON Schema와 TypeScript 타입으로도 온톨로지의 핵심인 공유 용어·관계·제약을 구현할 수 있다. 여러 데이터셋 연결, 명시적 추론, graph 검증이 필요해질 때 각각에 맞는 W3C 표준을 선택하면 된다.

2.2 핵심 철학: 의미와 제약을 공유 계약으로 만든다

온톨로지의 핵심은 그래프 모양이 아니라 암묵적 의미를 버전 가능한 공유 계약으로 바꾸는 것이다. 검색기는 ownership을 문서 label로 보고, prompt는 이를 책임감으로 해석하고, judge는 의사결정 권한으로 해석한다면 각 구성요소가 정상 동작해도 시스템 전체의 판정은 흔들린다.

공유 계약에는 최소한 다음이 들어간다.

안정적인 concept_id와 사람이 읽는 label을 분리한다.
relation의 방향과 뜻을 문장으로 정의한다.
허용되는 source·target class와 필수 개수를 제약으로 둔다.
검색 chunk와 judge 결과가 같은 concept·evidence 식별자를 사용한다.
모든 산출물에 ontology_version과 rubric_version을 남긴다.

이 계약은 모델에게 주는 긴 설명문이 아니다. 데이터 수집, chunk metadata, retrieval, prompt context, judge output, 분석 로그가 함께 참조하는 도메인 자산이다.

2.5 선행 기술의 한계 — Chunk label과 Prompt-local Glossary가 실패하는 이유

Naive RAG는 문서를 chunk로 나누고 embedding 유사도가 높은 문장을 가져온다. 이때 leadership, ownership, accountability, decision quality는 문맥상 가깝지만 채용·성과평가에서는 서로 다른 construct일 수 있다. **Construct(구성 개념)**는 직접 관찰할 수 없지만 평가가 측정하려는 추상 속성으로, 여기서는 협업·문제 해결·의사결정 품질 같은 대상이다.

Chunk에 label을 붙이면 검색 범위는 좁힐 수 있지만 다음 의미는 아직 없다.

ownership이 accountability의 동의어인지, 하위 역량인지, 구분해야 할 별도 개념인지
decision quality가 어떤 역할에 필요하고 어떤 행동으로 관찰되는지
한 문장이 여러 역량의 증거일 때 우선 관계와 근거 위치를 어떻게 남길지
label이 바뀌었을 때 오래된 chunk와 평가 결과를 어떻게 해석할지

Prompt-local glossary, 즉 prompt마다 붙이는 작은 용어집도 초기에는 유용하다. 그러나 prompt A는 ownership=끝까지 책임짐, prompt B는 ownership=의사결정 권한을 가짐으로 복제될 수 있다. 정의를 고쳐도 retriever metadata와 과거 judge 로그는 자동으로 함께 이동하지 않는다. 입력 토큰 한도 때문에 용어집 일부가 생략되면 같은 요청도 경로에 따라 다른 의미를 받는다.

따라서 문제는 “LLM이 용어를 모른다”가 아니라 의미의 원본과 변경 경로가 없다는 데 있다. 온톨로지는 모든 prompt를 길게 만드는 대신, 어떤 정의와 관계를 어떤 버전에서 가져왔는지 추적할 수 있게 한다.

3. 설계의 출발점: Competency Question

**Competency question(역량 질문)**은 “이 모델이 답할 수 있어야 하는 질문”이다. 온톨로지의 범위를 명사 수집이 아니라 실제 조회·판정 요구로 제한한다. 초기 ontology engineering에서 competency question을 범위 정의와 검증 기준으로 쓰는 접근은 TOVE 방법론에서도 제시됐다.

Q1. 이 지원자의 답변은 어떤 역량을 보여주는가?
Q2. 그 판단을 뒷받침하는 원문 증거는 무엇인가?
Q3. 같은 역량의 부정적 행동 신호는 무엇인가?
Q4. 이 업무에 필요한 최소 숙련도는 어느 수준인가?
Q5. 이 판정에는 어떤 ontology와 rubric 버전이 사용됐는가?

좋은 competency question은 모델 내부 구현이 아니라 사용자가 확인할 결과를 묻는다. 모든 역량을 계층화할 수 있는가?보다 incident commander 역할에 필요한 역량과 각 역량을 입증하는 답변 구간은 무엇인가?가 설계 경계를 더 잘 만든다.

작게 시작할 때는 다음 순서면 충분하다.

1. 업무 질문 수집: 검색·판정·설명해야 할 질문을 쓴다.
2. 답의 형태 작성: 기대하는 ID, 관계, evidence span을 먼저 적는다.
3. 최소 용어 추출: 질문과 답에 필요한 명사·동사만 고른다.
4. schema contract 연결: chunk metadata와 judge output 필드를 맞춘다.
5. 검증: 각 질문이 실제 데이터로 답해지는지 확인한다.

질문을 답하지 않는 class와 relation이 계속 늘어난다면 도메인 지식을 많이 담은 것이 아니라 범위를 잃은 것일 수 있다.

4. 모델의 구성 요소: Class, Relation, Instance, Constraint

4.1 네 요소의 첫 정의

Class(클래스): 같은 의미 규칙을 따르는 대상의 종류다. Competency, Behavior, Evidence, Role이 예다.
Relation(관계): 두 대상이 어떻게 연결되는지 나타내는 의미 있는 방향이다. Behavior demonstrates Competency처럼 동사로 읽혀야 한다.
Instance(인스턴스): class에 속하는 실제 개체다. competency.collaboration과 evidence.answer-42-span-3이 예다.
Constraint(제약): 어떤 연결과 값이 유효한지 정하는 규칙이다. relation의 source·target type, 필수 필드, 값 범위를 포함한다.

**Cardinality(카디널리티)**는 한 개체가 특정 관계 값을 몇 개 가져야 하거나 가질 수 있는지 나타내는 제약이다. 예를 들어 Evidence source_span 최소 1개는 근거 없는 판정을 막고, Evaluation used_rubric 정확히 1개는 한 결과의 채점 기준을 명확히 한다.

다만 이는 완전성 요구사항이지 OWL에서 누락을 자동 판정한다는 뜻이 아니다. OWL의 개방 세계 의미론에서는 source_span이 보이지 않아도 아직 알려지지 않은 값이 있을 수 있으므로 위반을 추론하지 않는다. source_span과 cardinality의 완전성은 RDF라면 SHACL, JSON/API라면 애플리케이션 입력·업무 규칙 검증으로 강제해야 한다.

기존 최소 모델을 유지하면서 instance와 constraint를 보태면 다음과 같다.

Class:
  Competency, Behavior, Evidence, Task, Role, Risk

Relation:
  role requires competency
  competency demonstrated_by behavior
  evidence supports behavior
  task has_risk risk

Instance:
  role.incident_commander
  competency.collaboration
  behavior.summarize_stakeholder_views
  evidence.answer_42_span_3

Constraint:
  Evidence source_span cardinality: min 1
  Role requires Competency cardinality: min 1
  evidence supports target: Behavior only

Class와 instance의 경계는 고정된 철학 문제가 아니라 애플리케이션 질문에 달려 있다. IncidentCommander별 공통 규칙을 추론해야 하면 class가 유용하고, 역할 목록에서 단일 고정 값으로만 쓰면 instance 또는 enum이면 충분하다.

4.2 Construct, competency, behavior, evidence

평가 모델에서는 네 단어를 섞지 않는 것이 중요하다.

Construct: 측정하려는 추상 속성이다. 예: 협업.
Competency(역량): 특정 맥락에서 기대 성과를 내는 능력을 행동 수준과 함께 정의한 모델 단위다. 예: 사고 대응 중 이해관계자 관점을 조정한다.
Behavior(행동): 답변·로그·관찰에서 식별할 수 있는 수행 방식이다. 예: 상충하는 요구를 요약하고 합의 기준을 제시한다.
Evidence(증거): 어떤 행동이나 판정을 뒷받침하는 관찰 가능한 데이터와 그 위치다. 예: 답변의 3~4번째 문장 span.

Label은 판정 결과이고 evidence는 그 판정의 근거다. collaboration label만 저장하면 재검토할 수 없지만, concept ID와 원문 span을 함께 저장하면 ontology나 rubric이 바뀌었을 때 다시 판정할 수 있다.

5. RDF Triple과 Application Schema

**RDF(Resource Description Framework, 자원 기술 프레임워크)**는 웹에서 식별한 resource와 그 관계를 subject-predicate-object triple로 표현하는 W3C 데이터 모델이다. 여러 출처가 같은 식별자를 사용하면 triple을 한 graph로 합칠 수 있고, 각 triple은 방향을 가진 문장처럼 읽힌다.

<role.incident_commander> <requires> <competency.collaboration>
<behavior.summarize_views> <demonstrates> <competency.collaboration>
<evidence.answer_42_span_3> <supports> <behavior.summarize_views>

**OWL(Web Ontology Language, 웹 온톨로지 언어)**은 class, property, 동등성, 상하위 관계, 배타성 같은 의미 규칙을 논리 공리로 표현하는 W3C 언어다. **Entailment(함의)**는 주어진 공리와 사실이 참이면 논리적으로 반드시 따라오는 결론이고, **reasoner(추론기)**는 이런 결론을 계산하고 선언들의 일관성을 검사하는 소프트웨어다. 예를 들어 두 class가 서로 배타적인데 하나의 instance가 둘 모두에 속한다고 선언하면 추론기가 불일치를 드러낼 수 있다.

**SHACL(Shapes Constraint Language, 셰이프 제약 언어)**은 RDF data graph를 검증하는 W3C 언어다. **Shape(셰이프)**는 어떤 focus node와 그 property 값이 만족해야 할 타입·개수·값 조건을 묶은 검증 규칙이다. Evidence마다 source_span이 최소 1개인지 확인하는 일은 의미 추론보다 graph 검증에 가깝다. OWL과 SHACL은 경쟁 제품이 아니라 질문이 다르다. OWL은 선언된 의미에서 무엇이 따라오는지, SHACL은 현재 graph가 요구한 조건을 만족하는지에 초점이 있다.

애플리케이션 경계에서도 다음 세 책임을 분리한다.

계층	보장하는 것	보장하지 않는 것
TypeScript 정적 타입	컴파일 시 코드 안 값의 필드명·타입 사용	타입이 지워진 뒤 들어오는 외부 JSON의 런타임 유효성
JSON Schema 인스턴스 검증	런타임 JSON의 `required`, 타입, enum, 중첩 객체 같은 구조적 shape	참조 원문 조회나 임의의 필드 간 대소 비교를 포함한 업무 의미
애플리케이션 업무 규칙 검증	`start_char < end_char <= 원문 길이`, `answer_id` 존재 같은 교차 필드·외부 참조	다른 데이터셋 전체의 온톨로지 의미나 RDF graph의 SHACL 적합성

TypeScript는 개발 중 정적 안전망이지 런타임 validator가 아니다. JSON Schema는 받은 JSON instance의 구조를 검증하고, 애플리케이션 코드는 그 구조만으로 판단할 수 없는 source range와 참조 무결성을 검증한다. 같은 최소 계약을 JSON으로 쓰면 다음과 같다.

source_span이 빠진 작은 반례는 세 도구의 경계를 선명하게 보여준다.

선언: Evidence는 source_span을 최소 1개 가진다.
데이터: evidence.answer_42는 Evidence이지만 source_span triple이 없다.

OWL: 누락된 triple이 거짓이거나 위반이라고 결론 내리지 않는다.
     개방 세계 가정에서는 아직 알려지지 않은 source_span이 있을 수 있으므로,
     최소 cardinality 선언과 함께 있어도 일관된 모델일 수 있다.

SHACL: 검증 입력으로 선언한 data graph에서 source_span 값을 세고,
       sh:minCount 1인데 0개이므로 validation violation을 만든다.

JSON Schema: 요청 body의 required 필드로 source_span을 두면
             graph로 변환하거나 저장하기 전에 잘못된 요청 모양을 거부한다.

Application validation: source answer를 조회한 뒤 start_char와 end_char의 순서,
                        원문 길이 이내인지, answer_id가 실제로 존재하는지 확인한다.

여기서 SHACL의 닫힌 검증 경계는 지정한 data graph와 target shape다. 이를 전체 세계에 해당 값이 없다는 지식으로 확대하면 안 된다. 반대로 OWL cardinality를 API의 required-field 검사처럼 사용해서도 안 된다. OWL은 의미와 entailment, SHACL은 현재 RDF data graph의 적합성, JSON Schema는 JSON instance의 구조, 애플리케이션 검증은 교차 필드와 source range를 책임진다.

{
  "evidence_id": "evidence.answer_42_span_3",
  "supports_behavior": "behavior.summarize_stakeholder_views",
  "source_span": {
    "answer_id": "answer_42",
    "start_char": 118,
    "end_char": 176
  },
  "ontology_version": "2026-07-13"
}

필요	먼저 검토할 표현	이유
코드 작성 중 필드·타입 불일치 탐지	TypeScript	컴파일 시 잘못된 사용을 빠르게 찾음
외부 JSON의 필수 필드·타입·구조 검증	JSON Schema	런타임 instance의 구조 계약을 적용함
JSON 교차 필드·source range·참조 존재 검증	애플리케이션 validator, SQL constraint	원문과 업무 상태를 읽어야 판단할 수 있음
여러 데이터셋의 식별자와 관계 교환	RDF	triple을 합쳐 graph로 연결하기 쉬움
RDF graph의 필수값·타입·개수 검증	SHACL	shape와 validation report를 분리할 수 있음
상하위·동등·배타 관계에서 추론	OWL	형식 의미와 entailment를 표현함
다중 hop 탐색과 연결 분석	graph DB 또는 graph index	관계 순회가 핵심 접근 패턴이기 때문

도구를 많이 쓰는 것이 성숙도의 증거는 아니다. 애플리케이션 질문이 한 레코드 안에서 끝나면 RDF 변환과 reasoner 운영은 불필요한 비용이 될 수 있다.

6. Ontology + RAG

Ontology는 RAG의 세 지점에 연결된다.

Query interpretation: 사용자 표현을 안정적인 concept ID에 매핑한다.
Retrieval: relation을 따라 동의어·하위 행동을 확장하고 metadata filter를 적용한다.
Grounding: 생성 claim과 evidence chunk를 같은 concept ID로 연결한다.

{
  "chunk_id": "interview-guide-17",
  "concept_ids": ["competency.collaboration"],
  "behavior_ids": ["behavior.summarize_stakeholder_views"],
  "role_ids": ["role.incident_commander"],
  "evidence_type": "positive_anchor",
  "ontology_version": "2026-07-13"
}

이 metadata는 retriever, reranker, answer generator, evaluator가 공유한다. 검색기는 competency.collaboration에 맞는 chunk를 찾고, judge는 같은 ID의 rubric을 사용하며, 로그 분석기는 같은 ID로 실패를 집계한다.

**GraphRAG(Graph-based Retrieval-Augmented Generation)**은 문서에서 추출한 entity·relation graph나 그 요약을 retrieval에 활용하는 RAG 계열 접근이다. Microsoft Research의 초기 GraphRAG 연구는 entity knowledge graph와 community summary를 만들어 전체 corpus의 주제를 묻는 global question에 대응했다. 따라서 GraphRAG는 단순히 “vector DB 대신 graph DB”라는 뜻이 아니며, 어떤 graph를 만들고 어떤 query 범위에 쓰는지가 구현마다 다르다.

Ontology와 GraphRAG도 같은 개념이 아니다. Ontology는 의미 계약이고, GraphRAG는 graph 구조를 검색·요약에 이용하는 retrieval 설계다. 추출된 graph에 ontology를 적용하면 relation type과 제약을 안정시킬 수 있지만, 작은 metadata filter만 필요한 시스템에는 GraphRAG가 과할 수 있다.

7. Worked Example: Query에서 Retrieval과 Judge까지

상황은 incident commander 채용 답변에서 협업 역량을 평가하는 작은 시스템이다. 사용자의 질문은 다음과 같다.

이 답변이 incident 상황의 collaboration 역량을 보여주는가?
그렇다면 어떤 문장이 근거이며 어떤 행동 기준에 해당하는가?

7.1 Step 1: 질문을 ontology ID로 해석한다

Query interpreter는 자연어를 다음 계약으로 바꾼다.

{
  "role_id": "role.incident_commander",
  "competency_id": "competency.collaboration",
  "requested_evidence": "answer_span",
  "ontology_version": "2026-07-13"
}

Ontology에는 다음 관계가 있다.

role.incident_commander requires competency.collaboration
competency.collaboration demonstrated_by behavior.summarize_stakeholder_views
competency.collaboration demonstrated_by behavior.align_next_action

따라서 검색어를 모호한 협업 한 단어로 늘리는 대신, 관계가 명시된 두 behavior ID를 검색 조건에 포함한다.

7.2 Step 2: 근거와 rubric chunk를 검색한다

지원자 답변에는 다음 문장이 있다고 하자.

"보안팀과 고객지원팀의 우려를 각각 요약한 뒤,
복구 우선순위를 합의하고 30분 뒤 다시 판단하기로 했습니다."

Retriever는 role과 competency가 맞는 rubric chunk를 filter하고, 두 behavior 중 하나 이상과 연결된 anchor를 가져온다.

검색 결과 A: behavior.summarize_stakeholder_views, positive_anchor
검색 결과 B: behavior.align_next_action, positive_anchor
제외 결과 C: competency.decisiveness, role.engineering_manager

C는 embedding상 판단과 가깝더라도 role·competency 계약이 다르므로 제외된다. 다만 filter가 잘못된 ontology를 정확하게 만들지는 못한다. align_next_action 관계 자체가 빠져 있다면 관련 근거도 recall에서 사라진다.

7.3 Step 3: Competency rubric으로 판정한다

기존 역량 YAML 예시는 다음처럼 행동과 evidence anchor를 분리한다.

competency: "문제 해결"
levels:
  L1: "명확한 문제를 절차대로 해결"
  L2: "불명확한 문제를 분해하고 대안을 비교"
  L3: "시스템적 원인을 찾아 재발 방지 구조 설계"
evidence:
  positive:
    - "문제를 재정의했다"
    - "trade-off를 비교했다"
  negative:
    - "원인 없이 해결책부터 제시했다"

현재 예제의 collaboration rubric은 점수 anchor와 필수 evidence를 명시한다.

{
  "competency": "collaboration",
  "score_scale": [1, 2, 3, 4, 5],
  "anchors": {
    "1": "타인 관점을 무시하고 갈등을 키움",
    "3": "타인 의견을 듣고 합의점을 찾음",
    "5": "갈등 구조를 재설계하고 팀 학습으로 연결"
  },
  "required_evidence": "answer_span",
  "rubric_version": "3.2"
}

Judge는 검색된 정의·anchor·원문만 사용해 다음 구조를 반환한다.

{
  "score": 3,
  "competency_id": "competency.collaboration",
  "behavior_ids": [
    "behavior.summarize_stakeholder_views",
    "behavior.align_next_action"
  ],
  "evidence_spans": [
    "보안팀과 고객지원팀의 우려를 각각 요약한 뒤, 복구 우선순위를 합의"
  ],
  "missing_evidence": ["갈등 구조의 재발 방지 또는 팀 학습 연결"],
  "failure_mode": "partial_evidence",
  "ontology_version": "2026-07-13",
  "rubric_version": "3.2"
}

평균 3.7점만 저장하는 방식과 달리, 이 결과는 어떤 행동이 관찰됐고 무엇이 부족했는지 다시 확인할 수 있다. Query, retrieval, judge가 같은 ID와 버전을 사용했기 때문에 오판이 생겨도 어느 경계에서 의미가 어긋났는지 추적할 수 있다.

8. 정량 감각: Coverage, Fan-out, Migration Impact

Ontology 품질에 보편적인 합격 숫자는 없다. 대신 competency question과 실제 query distribution을 기준으로 규모와 변경 영향을 계산한다.

8.1 Question coverage

12개의 competency question 중 현재 데이터와 relation으로 9개만 답할 수 있다면 question coverage는 9 / 12 = 75%다. Role requires Competency 관계를 보강해 11개가 답해지면 11 / 12 = 91.7%가 된다. 91.7%가 보편적 합격선이라는 뜻은 아니다. 답하지 못한 1개가 법적 승인 권한처럼 고위험 질문이면, 단순 비율이 높아도 배포하면 안 된다.

Coverage는 최소한 다음처럼 나눠 본다.

Schema coverage: 질문에 필요한 class와 relation이 모델에 존재하는가?
Data coverage: 실제 instance와 evidence가 채워져 있는가?
Answer coverage: retrieval과 judge를 거쳐 기대한 필드로 답할 수 있는가?

세 값을 합치면 원인을 놓친다. 모델에는 관계가 있지만 데이터가 없는 문제와, 데이터는 있지만 retriever가 못 찾는 문제는 고치는 위치가 다르다.

8.2 Relation fan-out

한 competency에 behavior 4개, 각 behavior에 evidence pattern 3개가 연결되면 2-hop 확장의 원시 후보는 최대 4 x 3 = 12개다. 시작 competency가 10개인 query를 무제한 확장하면 중복 제거 전 최대 120개 후보가 생긴다. 실제 수는 공유 behavior와 filter 때문에 달라지지만, 이 계산은 관계 추가가 retrieval context를 얼마나 넓힐지 보여준다.

Fan-out이 커질 때 곧바로 relation을 삭제하지 않는다. 다음을 측정한다.

hop별 unique candidate 수
role·risk·version filter 이후 남는 수
최종 top-k의 precision과 evidence coverage
확장 전후 token과 latency 비용

도메인마다 적정 fan-out이 다르므로 2-hop이면 항상 위험 같은 임계값을 만들지 않는다. 후보가 늘었는데 새로운 evidence recall은 거의 늘지 않고 reranker 비용만 커지는 지점이 해당 시스템의 전환 신호다.

8.3 Migration impact

가상의 변경에서 competency.collaboration을 두 하위 concept로 분리한다고 하자. 12,000개 chunk 중 18%가 기존 ID를 쓰면 재분류 후보는 12,000 x 0.18 = 2,160개다. 이 ID를 retriever, judge, dashboard 세 consumer가 사용한다면 schema만 바꾸는 것으로 끝나지 않는다.

영향 후보:
  chunk 재분류        2,160개
  relation 재연결     기존 concept의 모든 incoming/outgoing edge
  rubric 재매핑       이전 점수 anchor와 새 하위 competency의 대응
  과거 결과 해석      old ontology_version을 유지할지 재평가할지 결정

18%나 2,160개도 기준값이 아니라 변경 계획을 세우기 위한 예시다. 실제 migration은 ID 사용량, 자동 매핑 confidence, 사람이 검수해야 할 고위험 subset, consumer별 배포 순서로 산정한다.

9. Competency Model과 Rubric

Competency model은 competency -> behavior -> evidence -> level을 연결한다. Rubric은 그 모델을 실제 판정에 적용하는 채점 규칙이다. 전자는 업무 성공의 구조를 설명하고, 후자는 특정 과제에서 점수나 label을 결정한다.

이 연결의 소유권 경계는 분명히 둔다. Ontology는 semantic ID, relation, evidence, version contract를 소유한다. Observability/Evals는 execution trace와 eval lifecycle을 소유하고, Psychometrics는 reliability, validity, fairness evidence와 의사결정의 정당화 근거를 소유한다. Ontology가 의미를 일관되게 연결한다는 사실만으로 측정 타당성(measurement validity)이 입증되는 것은 아니다.

좋은 rubric은 score anchor만 길게 쓰지 않는다.

어떤 construct와 competency를 측정하는지 고정한다.
positive·negative behavior를 관찰 가능한 문장으로 쓴다.
evidence source를 answer span, tool log, task result처럼 제한한다.
evidence가 부족할 때 추측하지 않고 insufficient_evidence를 반환한다.
비슷한 competency가 함께 나타날 때 우선순위나 multi-label 허용 여부를 정한다.

점수 anchor가 없으면 judge는 같은 답변에도 숫자를 다르게 사용할 수 있다. 반대로 anchor만 있고 evidence 요구가 없으면 설명이 그럴듯한 답변에 높은 점수를 주는 verbosity bias를 막기 어렵다. 따라서 점수, concept ID, evidence span, missing evidence, failure mode를 함께 저장한다.

10. Governance와 Versioning

도메인 모델은 코드처럼 변경된다. 용어 rename은 화면 label 수정으로 끝나지 않고 검색 index, rubric, 과거 평가 해석에 영향을 준다.

최소 governance record에는 다음이 필요하다.

change_id, 변경 전후 version, 적용 시점을 남긴다.
rename, split, merge, relation 변경처럼 의미 변화의 종류를 기록한다.
old concept와 new concept의 mapping 및 자동·수동 migration 범위를 정한다.
변경 승인 owner와 정기 review 또는 incident 기반 review 조건을 둔다.
영향을 받는 chunk, rubric, consumer, 과거 결과의 처리 방식을 명시한다.

같은 concept의 표현 변형은 label·alias로 관리하고, 서로 다른 concept의 연결은 단순한 synonym 유형이 아니라 term/concept mapping으로 관리한다. **SKOS(Simple Knowledge Organization System)**에서 concept scheme은 특정 분류·시소러스처럼 concept를 조직하는 체계이며, mapping property는 관례적으로 서로 다른 concept scheme의 concept를 정렬하는 데 쓴다. SKOS의 형식 조건이 같은 scheme 안의 mapping을 금지하는 것은 아니므로, scheme과 출처 정보도 함께 보존해야 한다.

A skos:exactMatch B는 넓은 범위의 정보 검색에서 A와 B를 서로 바꿔 쓸 수 있다는 높은 확신의 동등 매핑이다. 대칭이며, SKOS mapping property 중 유일하게 transitive이므로 A exactMatch B, B exactMatch C는 A exactMatch C를 함의한다.
A skos:broadMatch B는 B가 A보다 넓은 concept라는 방향성 있는 계층 매핑이다. narrowMatch가 그 역관계이며, broadMatch 자체는 transitive가 아니다. 같은 두 concept에 대한 broaderTransitive 관계가 따라올 수 있다는 사실과 broadMatch 연쇄가 새 broadMatch를 만든다는 주장을 구분해야 한다.
A skos:relatedMatch B는 상하위가 아닌 연관 매핑이다. 대칭이지만 transitive가 아니므로 A-B와 B-C의 연관만으로 A-C를 자동 확장하지 않는다.

따라서 broadMatch와 relatedMatch를 synonym으로 합치면 검색 편의를 위해 평가 construct의 경계를 지울 수 있고, exactMatch를 느슨하게 부여하면 transitive closure를 통해 의도하지 않은 concept까지 동등 취급할 수 있다.

change_id: ontology-2026-07-13-01
from_version: "2026-05-22"
to_version: "2026-07-13"
change:
  type: split
  source: competency.collaboration
  targets:
    - competency.collaboration.conflict_resolution
    - competency.collaboration.alignment
owner: people-analytics
effective_at: "2026-07-20"
migration:
  chunk_metadata: reclassify
  historical_scores: preserve_old_version
  rubric: map_then_human_review

운영 순서는 길 필요가 없지만 의미 호환성은 확인해야 한다.

Propose: competency question과 실제 실패 사례로 변경 이유를 남긴다.
Impact: 사용 중인 chunk, relation, rubric, consumer를 집계한다.
Migrate: old ID에서 new ID로 mapping하고 양쪽 버전을 읽는 기간을 둔다.
Validate: question coverage, retrieval 결과, judge agreement를 이전 버전과 비교한다.
Deprecate: old ID의 쓰기를 막되 과거 결과를 읽을 경로는 유지한다.

평가 추세를 비교할 때 score=3만 join하면 rubric drift를 숨긴다. 반드시 ontology와 rubric version을 함께 묶어 같은 의미·기준으로 생성된 결과끼리 비교해야 한다.

11. 언제 JSON Schema로 충분하고 언제 Graph가 필요한가

11.1 반례 A: JSON Schema로 충분한 경우

단일 고객지원 서비스가 답변마다 category, severity, evidence_span을 출력하고, category가 8개 고정 enum이며 다른 시스템과 다중 hop 관계를 조회하지 않는다고 하자. 필요한 것은 JSON의 필수 필드·enum·각 offset의 숫자 범위와, 애플리케이션의 start < end <= 원문 길이 검증이다.

이 경우 JSON Schema, 작은 애플리케이션 validator, 버전 필드로 충분하다. graph DB와 OWL을 도입해도 새로운 competency question에 답하지 못하고, 변환·동기화·운영 경로만 늘어날 가능성이 크다. “도메인 용어가 있다”는 이유만으로 knowledge graph가 필요한 것은 아니다.

11.2 반례 B: Graph + SHACL이 정당화되는 경우

교육 플랫폼이 수천 개 토픽의 선수지식, 직무별 필수 역량, 평가 문항, evidence를 여러 팀에서 함께 관리한다고 하자. 질문이 이 학습자가 목표 직무까지 부족한 역량은 무엇이며, 그 역량을 채우는 토픽 중 현재 선수지식을 만족하는 것은 무엇인가?라면 여러 relation을 순회해야 한다.

Graph 접근은 Learner has Competency -> Role requires Competency -> Topic teaches Competency -> Topic requires Topic 경로를 탐색하는 데 유리하다. RDF를 쓴다면 SHACL로 orphan evidence, 잘못된 target type, 필수 relation 누락을 배포 전에 검증할 수 있다.

11.3 OWL까지 검토할 경우

SecurityIncidentResponder가 IncidentResponder의 하위 class이고, CriticalIncident 처리자는 반드시 PrivilegedOperator여야 한다는 선언에서 새로운 소속이나 충돌을 추론해야 한다면 OWL의 형식 의미가 가치가 있다. 단순 path query를 실행하는 것만으로 충분하면 graph query와 validation이 더 이해하기 쉽고 운영 비용도 낮을 수 있다.

제품 선택에서 책임을 제약 하나로 합치지 않는다. 코드가 필드를 올바른 타입으로 쓰는가는 TypeScript, 런타임 JSON instance에 필수 필드와 구조가 있는가는 JSON Schema, offset 순서와 source range가 실제 원문에 맞는가는 애플리케이션 validator의 질문이다. 현재 RDF data graph가 target shape를 만족하는가는 SHACL, 상하위·동등·배타 선언에서 어떤 사실이 따라오는가는 OWL reasoner가 맡는다. 특히 OWL의 개방 세계 추론은 source_span 누락을 위반으로 추론하지 않으므로 SHACL이나 애플리케이션 검증을 대신하지 않는다.

선택 질문을 정리하면 다음과 같다.

질문	Yes일 때 검토할 것
판단이 한 JSON record 안에서 끝나는가?	Application schema
여러 dataset의 식별자를 안정적으로 연결해야 하는가?	RDF 또는 명시적 graph schema
관계를 2-hop 이상 따라가는 query가 핵심인가?	Graph index/DB, query-specific projection
RDF instance의 필수값·타입·개수를 검사해야 하는가?	SHACL
상하위·동등·배타 규칙에서 새 사실을 추론해야 하는가?	OWL과 reasoner
변경이 검색·평가·분석 여러 consumer에 전파되는가?	Versioned ontology와 migration governance

12. 실패 신호와 원인

관측 가능한 실패 신호

비슷하지만 틀린 chunk가 반복 검색됨

concept ID는 같지만 relation·role·risk 경계가 없거나 synonym을 과도하게 합쳤을 수 있다.

오답 chunk가 공유하는 relation과 filter 전후 precision을 확인한다.

정답 근거가 index에 있는데 검색되지 않음

ontology relation 또는 chunk tagging coverage가 비어 있을 수 있다.

schema coverage와 data coverage를 분리해 누락 edge와 미태깅 chunk를 찾는다.

Judge 점수가 근거 없이 높음

score anchor는 있지만 required evidence와 cardinality 검증이 없을 수 있다.

evidence span 없는 판정을 실패시키고 missing_evidence를 별도 필드로 받는다.

Prompt마다 같은 용어의 판정이 다름

prompt-local glossary가 복제됐거나 ontology version이 context에 기록되지 않았을 수 있다.

실행 로그에서 concept ID·정의 hash·ontology version을 비교한다.

같은 답변의 Judge 판정이 반복 실행마다 갈림

예를 들어 같은 rubric·version으로 20개 답변을 3회 평가했는데 6개에서 최고점과 최저점이 2점 이상 벌어졌다면 construct 정의, score anchor, evidence 규칙 중 모호한 경계를 의심한다.

이 수치를 보편 임계값으로 쓰지 말고 문항별 disagreement와 evidence span 차이를 모아 rubric을 보정한다.

평가 결과가 직무 성공 기준과 무관함

예를 들어 고득점 답변 10개 중 4개가 incident 조정 행동 없이 유창한 표현만 근거로 삼았다면 competency question과 role·task 연결이 약한 것이다.

고득점 근거를 실제 직무 행동과 대조하고 관련 없는 judge 기준을 제거한다. 4/10은 설명용 예시이지 합격선이 아니다.

관계 확장 후 latency와 token만 증가

relation fan-out이 커졌지만 새로운 evidence recall은 거의 늘지 않았을 수 있다.

hop별 후보 수, dedup 이후 수, top-k precision, evidence coverage를 함께 본다.

배포 후 과거 점수 추세가 갑자기 변함

ontology split·merge 또는 rubric anchor 변경을 같은 시계열로 합쳤을 수 있다.

ontology_version과 rubric_version별로 분리하고 mapping 정책을 확인한다.

Graph validation은 통과하지만 업무 질문에 답하지 못함

shape가 데이터 모양만 검사하고 competency question coverage를 보장하지 않기 때문이다.

각 competency question을 executable test case로 연결한다.

Orphan concept와 deprecated ID 사용이 늘어남

owner·migration·deprecation 정책 없이 용어만 추가했을 수 있다.

incoming/outgoing edge, active consumer, old ID write를 정기적으로 집계한다.

Graph가 있다는 사실은 의미가 정확하다는 보장이 아니다. 잘못 정의한 relation은 잘못된 답을 더 일관되게 만들 수 있다. 실패 분석은 모델 환각만 의심하지 말고 query interpretation -> relation expansion -> metadata coverage -> rubric selection -> evidence validation -> version join 경계를 순서대로 본다.

13. 실무 적용과 저장소 예제

적용 범위는 다음처럼 넓다.

HR/채용 SJT, 인터뷰 평가, 성과 리뷰 자동 보조
사내 정책 Q&A의 용어·규정·예외 관계 모델링
보안/컴플라이언스 agent의 risk taxonomy와 허용 action 연결
교육 플랫폼의 학습 목표·선수지식·평가 문항 연결
고객지원 시스템의 제품 기능·문제 유형·해결 절차 연결

이 저장소의 layer, prerequisites, lineage_oneliner도 작은 ontology 역할을 한다. 문서를 단순 목록으로 두지 않고 토픽 A는 토픽 B의 선수지식이다라는 relation과 방향을 정했기 때문에 validate-topology가 역행 edge와 cycle을 검사할 수 있다.

Class: Topic, Layer
Instance: rag-fundamentals, ontology-and-competency-modeling, L12
Relation:
  ontology-and-competency-modeling requires rag-fundamentals
  ontology-and-competency-modeling belongs_to L12
Constraint:
  prerequisite layer <= document layer
  same-layer prerequisite learning_order < document learning_order

이 예제는 반드시 RDF로 옮겨야 한다는 뜻이 아니다. 현재 YAML frontmatter와 validation script가 질문과 제약을 충분히 처리한다면 application schema가 적절하다. 나중에 여러 교육과정의 토픽·직무 역량·학습자 evidence를 연결해 다중 hop 추천을 해야 할 때 graph 표현의 가치가 커진다.

14. 자주 헷갈리는 개념

개념 A	개념 B	차이점
Taxonomy	Ontology	Taxonomy는 계층 분류, ontology는 비계층 관계와 제약까지 표현
Ontology	Knowledge graph	Ontology는 의미 모델, knowledge graph는 실제 instance와 관계 데이터
RDF	OWL	RDF는 triple graph 모델, OWL은 그 위에서 풍부한 의미·추론 규칙을 표현
OWL	SHACL	OWL은 entailment 중심, SHACL은 주어진 RDF graph의 shape 검증 중심
Ontology	GraphRAG	Ontology는 공유 의미 계약, GraphRAG는 graph를 retrieval에 활용하는 설계
Competency	Skill	Competency는 맥락·행동·평가 기준을 포함하고 skill은 능력 이름에 가까움
Construct	Evidence	Construct는 측정하려는 추상 속성, evidence는 이를 추론할 관찰 데이터
Rubric	Competency model	Rubric은 과제별 채점 규칙, competency model은 업무 역량의 구조
Label	Evidence	Label은 판정 결과, evidence는 판정을 뒷받침하는 원문·로그·결과

15. 학습 체크리스트

Ontology와 competency modeling 이해 점검

taxonomy·ontology·knowledge graph의 경계를 사례로 설명할 수 있다
competency question에서 class·relation·instance·constraint를 도출할 수 있다
RDF·OWL·SHACL·application schema가 답하는 질문을 구분할 수 있다
retriever와 judge가 같은 concept·evidence·version 계약을 사용하게 설계할 수 있다
relation fan-out과 question coverage를 계산하되 보편 임계값으로 오해하지 않는다
JSON Schema로 충분한 경우와 graph·SHACL·OWL이 정당화되는 경우를 구분할 수 있다
ontology split·merge가 chunk·rubric·과거 평가에 미치는 영향을 추적할 수 있다

16. 직접 확인해볼 것

긴 제품 환경을 만들 필요는 없다. 종이나 작은 JSON 파일만으로 다음을 확인할 수 있다.

작은 관찰 실습

현재 저장소의 layer·prerequisites를 class·instance·relation·constraint로 나눠 그려보기
엔지니어 역량 5개와 각 역량의 positive·negative behavior, evidence span 규칙 정의하기
같은 답변을 일반 judge prompt와 score anchor·required evidence가 있는 rubric으로 평가해 결과 구조 비교하기
RAG metadata에 concept_id·role_id·ontology_version을 넣고 filter 전후 오답 chunk를 비교하기
한 concept의 1-hop·2-hop 후보 수를 세고 relation 추가 전후 evidence coverage와 token 수 비교하기

17. 5줄 요약

Ontology는 taxonomy보다 넓고 knowledge graph와 구분되는, 개념·관계·제약의 공유 의미 계약이다.
Competency question은 모델 범위를 정하고 ontology가 실제 업무 질문에 답하는지 검증한다.
Class·relation·instance·constraint를 app schema 또는 RDF로 표현하고, 필요할 때 SHACL·OWL·graph 탐색을 선택한다.
Ontology와 RAG, competency rubric을 연결하면 query·retrieval·judge가 같은 concept와 evidence를 추적한다.
Coverage·fan-out·migration impact와 version을 관측해야 정교한 모델이 운영 가능한 계약이 된다.

18. 출처

최종 수정: 2026-07-13