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

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

AI 애플리케이션을 위한 온톨로지와 역량 모델링 — Domain Concepts, Competency Questions, Rubrics

1. 한 줄 정의

온톨로지는 도메인의 개념과 관계를 기계가 다룰 수 있게 명시한 모델이고, 역량 모델링은 어떤 사람·agent·시스템이 특정 업무를 수행할 수 있는지를 행동 기준과 평가 증거로 정의하는 작업이다.

2. 왜 중요한가

RAG 검색 품질 향상: “직책”, “역량”, “평가 항목”, “증거” 같은 관계가 없으면 chunk 유사도만으로 의미를 구분하기 어렵다.
평가 rubric의 기반: LLM-as-judge가 무엇을 봐야 하는지 기준을 구조화하고, 점수·근거·실패 유형의 schema가 된다.
도메인 지식 재사용: prompt마다 용어 정의를 복붙하지 않고 shared model로 관리한다.
권한·정책 연결: 역할, 업무, 허용 action을 graph로 연결하면 agent 권한 제어가 명확해진다.
SJT/평가 설계 기반: situational judgment test는 상황, 선택지, 역량, 채점 키가 연결되어야 한다.

2.5 선행 기술의 한계 — Chunk와 Label만으로 부족한 이유

Naive RAG는 문서를 chunk로 나누고 유사도 검색으로 답을 만든다. 그러나 도메인이 복잡해지면 “비슷한 문장”이 “같은 의미”를 보장하지 않는다.

예를 들어 leadership, ownership, accountability, decision quality는 문장상 비슷하지만 채용·성과평가에서는 서로 다른 역량일 수 있다. LLM judge에게 “좋은 답인지 평가해”라고만 하면 기준이 매번 흔들린다.

온톨로지는 개념과 관계를 명시한다. W3C OWL 문서는 ontology를 특정 도메인과 사용자 공동체가 공유하는 용어의 formalized vocabulary로 설명한다. 출처: W3C OWL 2 Overview. RDF는 resource에 대한 정보를 표현하는 데이터 모델로, subject-predicate-object triple을 통해 관계를 나타낸다. 출처: W3C RDF 1.1 Primer.

AI 애플리케이션에서는 무거운 OWL reasoner를 항상 도입할 필요는 없다. 중요한 것은 도메인 개념, 관계, 평가 질문, 증거 기준을 prompt와 code 밖의 명시적 자산으로 관리하는 것이다.

3. 핵심 개념

3.1 Ontology 최소 구성

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

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

LLM 앱에서는 RDF/OWL까지 가지 않아도 JSON Schema, TypeScript type, graph DB schema로 시작할 수 있다.

판단 기준은 “추론이 필요한가”와 “관계 변경이 평가 결과를 바꾸는가”다. 닫힌 용어 목록, 1~2단계 metadata filter, judge output 검증이 목적이면 JSON Schema와 ontology_version metadata로 충분하다. 반대로 다중 hop 관계를 따라 권한·선수지식·역량 충족 여부를 계산하거나, 동의어/상하위 개념/필수 cardinality 위반이 의사결정에 영향을 주면 graph DB, SHACL, OWL 같은 더 명시적인 제약 모델을 검토한다.

3.2 Competency Question

Competency question은 “이 모델이 답할 수 있어야 하는 질문”이다.

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

온톨로지 설계는 용어부터 시작하지 말고 이런 질문에서 시작해야 한다.

Domain Modeling/Ontology Design을 작게 시작할 때는 다음 5단계면 충분하다.

1. 업무 질문 수집: "무엇을 판단/검색/평가해야 하는가?"
2. 용어 후보 추출: 문서, 로그, 인터뷰에서 반복되는 명사와 동사를 모은다.
3. class/relation/evidence 분리: 개념 이름, 관계, 판단 근거를 섞지 않는다.
4. schema contract 작성: chunk metadata와 judge output에 들어갈 필드를 고정한다.
5. validation/governance: orphan concept, synonym collision, deprecated term, cardinality 위반, rubric version mismatch를 주기적으로 점검한다.

3.3 Competency Model

역량 모델은 보통 다음 구조를 가진다.

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

LLM judge는 이 구조를 rubric으로 사용한다.

3.4 Ontology + RAG

ontology는 RAG pipeline에 세 방식으로 붙는다.

Query expansion: ownership 검색 시 관련 행동·동의어를 확장
Metadata filter: role=backend, competency=incident_response로 검색 범위 제한
Answer grounding: 답변 claim을 ontology concept과 evidence chunk에 연결
Retrieval contract: chunk가 어떤 concept, task, risk, policy에 속하는지 명시해 검색 결과를 후속 평가와 같은 schema로 넘김

GraphRAG나 knowledge graph RAG는 이 방향의 확장이다.

실무에서는 ontology를 별도 지식 그래프 제품으로만 생각하지 말고 RAG의 schema contract로 다룬다. 예를 들어 문서 chunk metadata에 concept_id, competency_id, evidence_type, risk_level을 넣으면 retriever, reranker, answer generator, evaluator가 같은 필드를 공유한다. 이렇게 해야 검색 결과가 “관련 있어 보이는 문장”에서 끝나지 않고, “어떤 도메인 개념에 대한 어떤 증거인가”로 추적된다.

3.5 Ontology + LLM-as-Judge

judge prompt는 일반 문장보다 구조화된 rubric을 더 잘 따른다.

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

score anchor가 없으면 judge는 숫자를 일관되게 쓰기 어렵다.

여기서 competency model은 LLM eval의 schema 역할을 한다. competency, behavior, evidence, score_anchor, failure_mode를 분리하면 judge 출력도 단순 점수보다 감사 가능해진다.

{
  "score": 3,
  "competency_id": "collaboration.conflict_resolution",
  "evidence_spans": ["상대 의견을 먼저 요약했다"],
  "missing_evidence": ["합의 이후 실행 계획"],
  "failure_mode": "partial_evidence"
}

이 구조가 없으면 평가 결과를 모아도 “평균 3.7점”만 남고, 어떤 역량 정의가 흔들렸는지, 어떤 증거가 부족했는지, rubric drift가 어디서 시작됐는지 추적하기 어렵다.

3.6 Ontology Governance

도메인 모델도 버전 관리 대상이다.

concept 추가/삭제 이력
synonym merge 규칙
deprecated term
owner와 review 주기
평가 데이터와 rubric 버전 연결

모델 버전이 바뀌면 과거 평가 결과와 비교할 때 rubric drift를 고려해야 한다.

3.7 Silent Failure

증상	원인	복구
judge 점수 일관성 낮음	역량 정의와 score anchor 부족	competency model과 anchor 보강
RAG가 비슷하지만 틀린 문서 검색	개념 관계/metadata 없음	ontology 기반 filter, query expansion
prompt마다 용어가 다름	shared vocabulary 부재	glossary/ontology를 단일 원본화
평가 결과가 직무와 무관	competency question 미정의	업무 성공 기준에서 question 재작성
오래된 기준으로 평가	rubric version 관리 없음	ontology/rubric versioning
평가 로그를 분석하기 어려움	점수만 저장하고 concept/evidence 없음	judge output schema에 concept·evidence 필드 강제

4. 실무에서 어디에 쓰이나

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

5. 현재 내 업무와 연결점

이 저장소의 layer, prerequisites, lineage_oneliner도 작은 온톨로지다. 문서를 단순 목록이 아니라 “어떤 토픽이 어떤 토픽을 선행하는가”로 모델링했기 때문에 validate-topology가 가능하다. AI 앱에서도 같은 원리로 도메인 지식을 구조화하면 평가와 검색이 안정된다.

특히 LLM eval과 RAG를 따로 설계하면 검색 schema와 평가 schema가 어긋나기 쉽다. 이 저장소에서 prerequisites가 사이트 정렬과 검증 스크립트 양쪽에 쓰이듯, AI 앱에서도 ontology를 retriever metadata, prompt context, judge rubric, 분석 대시보드가 공유하는 단일 계약으로 두는 것이 핵심이다.

6. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
Taxonomy	Ontology	taxonomy는 계층 분류, ontology는 관계와 제약까지 표현
Ontology	Knowledge graph	ontology는 schema/의미 모델, knowledge graph는 instance data 포함
Competency	Skill	competency는 행동·상황·평가 기준 포함, skill은 능력 이름에 가까움
Rubric	Competency model	rubric은 채점 기준, competency model은 업무 역량 구조
Label	Evidence	label은 판정 결과, evidence는 판정을 뒷받침하는 원문

7. 체크리스트

도메인 개념을 class/relation/evidence로 나눠 설명할 수 있다.
competency question에서 ontology 설계를 시작할 수 있다.
역량별 score anchor와 positive/negative evidence를 만들 수 있다.
ontology를 RAG metadata filter와 query expansion에 연결할 수 있다.
ontology를 retriever, generator, judge가 공유하는 schema contract로 설계할 수 있다.
rubric version이 평가 결과 해석에 영향을 주는 이유를 설명할 수 있다.

8. 추가 학습 키워드

ontology engineering, competency questions, RDF, OWL, knowledge graph, SHACL, rubric design, competency model, GraphRAG, domain taxonomy

9. 내가 직접 확인해볼 것

현재 학습 토픽의 layer/prerequisites를 작은 ontology로 그려보기
“플랫폼 엔지니어 역량” 5개와 각 역량의 행동 증거 정의
같은 답변을 일반 judge prompt와 score anchor rubric으로 평가해 일관성 비교
RAG metadata에 concept, role, risk 필드를 넣고 검색 품질 비교

10. 5줄 요약

온톨로지는 AI 앱의 도메인 용어와 관계를 명시하는 의미 모델이다.
역량 모델은 업무 수행 능력을 행동 기준과 증거로 정의한다.
RAG와 LLM judge는 구조화된 개념·관계·rubric이 있을 때 안정된다.
competency question은 ontology가 실제로 답해야 할 질문을 정한다.
ontology와 rubric도 버전 관리해야 평가 drift를 추적할 수 있다.

11. 출처

최종 수정: 2026-05-22