온톨로지 엔지니어링
13분 읽기
확장 개념 (engineering-playbook 독자 콘텐츠)
온톨로지·하네스 엔지니어링은 AWS Labs AIDLC 공식 방법론 에 포함되지 않은, engineering-playbook 의 독자 확장 콘텐츠입니다. DDD + 2026년 Agentic AI 베스트 프랙티스를 반영해 엔터프라이즈 AI 신뢰성을 강화했습니다. 공식 AIDLC 적용 시 이 축은 선택적으로 도입 가능합니다.
"프롬프트 엔지니어링은 온톨로지 엔지니어링이다" — 2026 AI 커뮤니티 컨센서스
온톨로지 엔지니어링은 업무 개념과 개념 간 관계, 지켜야 할 규칙을 기계가 읽을 수 있는 스키마로 정리하는 작업입니다. 팀이 함께 쓰는 업무 용어(DDD의 Ubiquitous Language)를 스키마로 옮겨, AI가 생성한 결과가 정해진 규칙을 따르는지 검증하는 데 사용합니다.
1. 온톨로지란 무엇인가
1.1 Typed World Model로서의 온톨로지
**온톨로지(Ontology)**는 도메인 지식을 형식화한 "typed world model"입니다. DDD의 Ubiquitous Language가 팀 내 소통을 위한 비형식적 합의였다면, 온톨로지는 이를 AI가 기계적으로 이해하고 준수할 수 있는 구조화된 스키마로 변환합니다.
핵심 특징:
- 형식성: 엔티티, 관계, 제약 조건이 명시적으로 정의됨
- 타입 안전성: 모든 도메인 개념이 타입 시스템으로 표현됨
- 검증 가능성: 제약 조건을 자동으로 검증할 수 있는 구조
- 진화 가능성: 운영 데이터를 통해 지속적으로 정제됨
1.2 DDD Ubiquitous Language와의 관계
| 측면 | Ubiquitous Language | 온톨로지 |
|---|---|---|
| 형식성 | 비형식적 합의 (자연어) | 형식 스키마 (타입 정의) |
| 범위 | 팀 내 소통 | AI 에이전트 + 팀 + 코드 |
| 검증 | 수동 리뷰 | 자동 제약 검증 |
| 진화 | 문서 업데이트 | 피드백 루프 기반 자동 정제 |
| AI 이해 | 불가능 (암묵적 맥락) | 가능 (명시적 구조) |
DDD의 Aggregate, Entity, Value Object, Domain Event는 온톨로지의 기본 빌딩 블록이 됩니다. 차이는 이들의 관계와 제약이 기계 판독 가능한 형식으로 표현된다는 점입니다.
2. 왜 온톨로지가 필요한가
2.1 AI 에이전트 실패의 근본 원인
아래 실패 사례에는 업무 개념, 개념 간 관계, 규칙이 에이전트의 문맥 안에서 일관되게 정의되지 않았다는 공통점이 있습니다. 명시적인 스키마는 이 문제를 확인하고 줄이는 데 도움이 됩니다. 모델의 한계와 프롬프트 오류는 별도로 평가해야 합니다.
전형적인 실패 패턴:
- 맥락 유실: 사용자, 주문, 태스크, 규칙의 정의가 프롬프트 안에 흩어져 있으면 AI는 맥락을 잃음
- 환각 생성: 명시적 제약이 없으면 AI는 "논리적으로 그럴듯한" 하지만 틀린 추론을 생성
- 일관성 부재: 동일 개념에 대한 정의가 세션마다 달라져 예측 불가능한 동작 발생
2.2 온톨로지가 해결하는 문제
1. 환각 방지
- 모든 도메인 개념이 명시적으로 정의되어 AI가 임의로 해석할 여지 제거
- 엔티티 간 관계가 형식화되어 존재하지 않는 연결을 생성할 수 없음
2. 도메인 정확성 보장
- 불변 조건(invariant)이 온톨로지에 인코딩되어 위반 시 자동 탐지
- 도메인 이벤트의 전이 경로가 명시되어 잘못된 상태 전환 차단
3. 컨텍스트 일관성
- 온톨로지가 AI 에이전트의 컨텍스트 윈도우에 주입되어 모든 생성 작업의 기준이 됨
- 세션 간, 에이전트 간 동일한 도메인 이해 보장
2.3 실전 증거
정량적 개선 효과
HITL(Human-in-the-Loop) 기반 온톨로지 피드백 루프 통합 시:
- 정확도 31% 향상
- False Positive 67% 감소
- 에러율 8.3% → 1.2% (31일 만에 달성)
피드백 루프 미적용 시: $28K 비용에 에러율 8.3%→7.9% 미미한 개선.
3. 온톨로지 구조
3.1 DDD 개념의 온톨로지 매핑
domain_ontology:
aggregates:
Payment:
description: "결제 처리의 트랜잭션 경계"
invariants:
- "amount는 0보다 커야 한다"
- "status 전이: CREATED → PROCESSING → COMPLETED | FAILED"
- "FAILED 상태에서 재시도는 최대 2회"
entities:
- PaymentMethod:
type: "enum"
values: ["CARD", "BANK", "WALLET"]
- Customer:
attributes:
- customerId: "UUID"
- tier: "enum[BASIC, PREMIUM, ENTERPRISE]"
value_objects:
- Money:
currency: "ISO 4217"
amount: "decimal(19,4)"
invariants:
- "amount >= 0"
- "currency는 null일 수 없음"
domain_events:
- PaymentCreated:
trigger: "결제 요청 수신"
data: ["paymentId", "amount", "customerId"]
timestamp: "ISO 8601"
- PaymentCompleted:
trigger: "PG 승인 완료"
data: ["paymentId", "pgTransactionId"]
- PaymentFailed:
trigger: "PG 거부 또는 타임아웃"
data: ["paymentId", "errorCode", "reason"]
relationships:
- "Payment CONTAINS PaymentMethod (1:1)"
- "Customer INITIATES Payment (1:N)"
- "Payment EMITS PaymentCreated (1:1)"
- "Payment EMITS PaymentCompleted | PaymentFailed (1:1, mutually exclusive)"
constraints:
- "동일 Customer의 동시 결제는 최대 3건"
- "PROCESSING 상태는 최대 30초 유지, 초과 시 자동 FAILED 전환"
- "PaymentMethod 변경은 CREATED 상태에서만 가능"
3.2 Knowledge Source 계층
온톨로지 구축 시 지식 소스의 신뢰도를 계층화하여 관리합니다.
| 우선순위 | 소스 | 예시 | 신뢰도 | 활용 방식 |
|---|---|---|---|---|
| 1 | 실제 구현 코드/PR | awslabs/ai-on-eks, Helm chart 소스코드 | 최고 | 실제 동작하는 코드 기준 |
| 2 | 프로젝트 GitHub 이슈/릴리스 | NVIDIA/KAI-Scheduler, ai-dynamo/dynamo | 높음 | 개발자 간 사실 교환 |
| 3 | 공식 문서 | docs.nvidia.com, docs.aws.amazon.com | 중간 | 일반론, 업데이트 지연 가능 |
| 4 | 블로그/튜토리얼 | Medium, AWS Blog | 낮음 | 특정 시점의 스냅샷 |
실전 교훈: 공식 문서만으로는 부족하다
온톨로지 구축 시 공식 문서(Official Documentation)만 참조하면 AI는 "논리적으로 그럴듯한 추론"을 "검증된 사실"로 혼동합니다.
실제 사례:
- 문제: AWS EKS Auto Mode 공식 문서에 "AWS가 GPU 드라이버를 관리한다"고 기술 → AI가 "GPU Operator 설치 불가"로 비약 → 비교표, 아키텍처, 권장사항 전체가 오염
- 원인: 실제 구현 레포(awslabs/ai-on-eks PR #288)를 확인하지 않고 공식 문서의 일반론만으로 추론
- 결과: "기술적 불가능"이라는 잘못된 전제가 문서 전체로 전파되어 12개 이상의 비교표와 아키텍처 권장사항이 모두 틀림
원칙: AI가 생성한 기술 문서는 반드시 **실제 구현 코드와 교차 검증(cross-validation)**해야 합니다. 공식 문서의 "할 수 없다"는 "아직 문서화되지 않았다"일 수 있습니다.
3.3 규칙 템플릿 계층
온톨로지는 단순 스키마를 넘어 실행 가능한 규칙으로 확장됩니다.
rule_templates:
validation_rules:
- rule_id: "PAYMENT_AMOUNT_POSITIVE"
condition: "Payment.amount > 0"
error_message: "결제 금액은 0보다 커야 합니다"
severity: "ERROR"
- rule_id: "PAYMENT_STATUS_TRANSITION"
condition: |
IF current_status == "CREATED" THEN next_status IN ["PROCESSING", "FAILED"]
ELIF current_status == "PROCESSING" THEN next_status IN ["COMPLETED", "FAILED"]
ELSE invalid_transition
error_message: "잘못된 결제 상태 전환"
severity: "ERROR"
business_rules:
- rule_id: "MAX_CONCURRENT_PAYMENTS"
condition: "COUNT(Payment WHERE customer_id = X AND status = 'PROCESSING') <= 3"
error_message: "동시 처리 중인 결제가 최대 한도를 초과했습니다"
severity: "WARNING"
action: "QUEUE_PAYMENT"
이 규칙 템플릿은:
- 코드 생성 시: 검증 로직으로 자동 변환
- 테스트 생성 시: 경계 조건 테스트 케이스로 자동 도출
- 런타임 시: 가드레일(guardrail)로 동작
4. 3중 피드백 루프: 살아있는 온톨로지
온톨로지는 한 번 정의하면 끝나는 정적 스키마가 아닙니다. 운영 데이터와 개발 경험을 통해 지속적으로 진화하는 살아있는 모델입니다.
4.1 피드백 루프 구조
글씨가 작으면 확대해서 확인할 수 있습니다.
다이어그램
4.2 각 루프의 역할
| 루프 | 주기 | 트리거 | 온톨로지 변화 | 예시 |
|---|---|---|---|---|
| Inner Loop | 분 단위 | 테스트 실패, 하네스 위반 | 제약 조건 추가/수정 | 누락된 invariant 발견: "amount > 0" 제약 추가 |
| Middle Loop | 일 단위 | PR 리뷰에서 반복 패턴 | 엔티티/관계 스키마 갱신 | 반복되는 에러 패턴 → 새로운 Value Object 추가 |
| Outer Loop | 주 단위 | 운영 인시던트, SLO 위반 | 도메인 모델 구조 재설계 | P99 지연 시간 증가 → Aggregate 경계 재정의 |
4.3 Inner Loop: 즉각적 제약 정제
시나리오: AI가 생성한 코드가 테스트 실패
# AI 생성 코드 (1차 시도)
def create_payment(amount: float, customer_id: str):
payment = Payment(
amount=amount, # amount가 음수일 수 있음을 간과
customer_id=customer_id,
status="CREATED"
)
return payment
# 테스트 실패
def test_negative_amount():
with pytest.raises(ValueError):
create_payment(-100, "customer-123")
# AssertionError: ValueError not raised
# 온톨로지 제약 추가
invariants:
- "amount > 0"
# AI 재생성 코드 (2차 시도)
def create_payment(amount: float, customer_id: str):
if amount <= 0:
raise ValueError("결제 금액은 0보다 커야 합니다")
payment = Payment(...)
return payment
효과: 분 단위로 제약 조건이 정제되어 동일 에러 재발 방지.
4.4 Middle Loop: 스키마 구조 개선
시나리오: PR 리뷰에서 반복 패턴 발견
## PR 리뷰 메트릭 (7일간)
- "Currency mismatch" 에러: 12건
- "Amount precision loss" 에러: 8건
- 공통 패턴: Money를 float로 처리하여 정밀도 손실
## 온톨로지 갱신
value_objects:
- Money:
currency: "ISO 4217"
amount: "decimal(19,4)" # float → decimal 변경
invariants:
- "amount >= 0"
- "currency는 null일 수 없음"
효과: 반복되는 에러 패턴이 온톨로지 스키마에 반영되어 구조적으로 차단됨.
4.5 Outer Loop: 도메인 모델 재설계
시나리오: 운영 인시던트 — P99 지연 시간 SLO 위반
## 인시던트 분석
- 원인: Payment Aggregate가 고객 히스토리까지 포함하여 과도하게 비대
- 영향: 결제 조회 시 불필요한 데이터 로드 → DB 쿼리 증가
## 온톨로지 재설계
# Before
aggregates:
Payment:
entities:
- Customer (전체 히스토리 포함)
# After
aggregates:
Payment:
entities:
- CustomerReference (ID만 참조)
CustomerProfile: # 별도 Aggregate로 분리
entities:
- PaymentHistory
효과: Aggregate 경계 재정의를 통해 P99 지연 시간 42% 감소.
5. SemanticForge 패턴: Knowledge Graph 통합
5.1 Knowledge Graph as Constraint Satisfaction Harness
온톨로지를 Knowledge Graph로 구체화하면 SemanticForge 패턴을 적용할 수 있습니다. Knowledge Graph가 constraint satisfaction 하네스 역할을 하여 AI가 생성하는 코드의 논리적/구조적 환각을 원천 차단합니다.
글씨가 작으면 확대해서 확인할 수 있습니다.
다이어그램
5.2 SemanticForge 적용 예시
Knowledge Graph 구조:
// 엔티티 정의
CREATE (p:Aggregate {name: "Payment"})
CREATE (pm:Entity {name: "PaymentMethod", type: "enum"})
CREATE (m:ValueObject {name: "Money"})
// 관계 정의
CREATE (p)-[:CONTAINS {cardinality: "1:1"}]->(pm)
CREATE (p)-[:USES {cardinality: "1:1"}]->(m)
// 제약 조건
CREATE (p)-[:INVARIANT {rule: "amount > 0"}]->(m)
CREATE (p)-[:INVARIANT {rule: "status transition: CREATED → PROCESSING → COMPLETED|FAILED"}]->(p)
AI 생성 시 검증:
# AI가 생성한 코드
payment.amount = -100 # 제약 위반
# SemanticForge가 Knowledge Graph를 쿼리하여 검증
query = """
MATCH (p:Aggregate {name: "Payment"})-[:INVARIANT]->(m:ValueObject {name: "Money"})
WHERE m.rule CONTAINS "amount > 0"
RETURN m.rule
"""
# 제약 위반 탐지 → AI에게 재생성 요청
효과: AI가 Knowledge Graph에 인코딩된 제약을 위반하는 코드를 생성할 수 없음.
5.3 참고 자료
- SemanticForge: Knowledge Graph 기반 환각 방지
- Knowledge Graph를 제약 만족 하네스로 활용하는 구체적 패턴 제시
6. HITL(Human-in-the-Loop) 통합
6.1 HITL의 전략적 역할
HITL을 자율성의 과도기가 아닌 온톨로지 진화의 전략적 설계 요소로 배치합니다. 인간 피드백이 온톨로지 정제의 핵심 신호입니다.
글씨가 작으면 확대해서 확인할 수 있습니다.
다이어그램
6.2 HITL 통합 효과
정량적 증거
- 정확도 31% 향상: AI 생성 코드의 도메인 정확성
- False Positive 67% 감소: 불필요한 에러 알림 감소
- 에러율 8.3% → 1.2%: 31일 만에 달성
비용 비교:
- 피드백 루프 미적용: $28K 비용, 에러율 8.3%→7.9% (미미한 개선)
- HITL 기반 피드백 루프: 운영 비용 대폭 감소, 에러율 85% 감소
6.3 HITL 피드백 수집 포인트
| 단계 | HITL 개입 지점 | 온톨로지 개선 방향 |
|---|---|---|
| Inception | Mob Elaboration 검토 | 도메인 제약 정의 정교화 |
| Construction | PR 리뷰 | 엔티티 관계 스키마 갱신 |
| Operations | 인시던트 포스트모템 | 도메인 모델 구조 재설계 |
6.4 참고 자료
- Human-in-the-Loop in Agentic AI — 2026-03
- How to Build an AI Agent Feedback Loop — Braincuber, 2026-03
7. Kiro Spec + 온톨로지 통합
7.1 온톨로지를 Spec에 임베딩
Kiro Spec의 requirements.md에 온톨로지를 직접 포함하여 AI 에이전트가 요구사항 분석 단계부터 도메인 제약을 인식하도록 합니다.
requirements.md 예시:
# Payment Service 배포 요구사항
## 기능 요구사항
- REST API 엔드포인트: /api/v1/payments
- DynamoDB 테이블과 연동
- SQS를 통한 비동기 이벤트 처리
## 비기능 요구사항
- P99 지연 시간: < 200ms
- 가용성: 99.95%
- 자동 스케일링: 2-20 Pod
## 도메인 온톨로지
### Aggregates
#### Payment
- **Invariants:**
- amount는 0보다 커야 한다
- status 전이: CREATED → PROCESSING → COMPLETED | FAILED
- FAILED 상태에서 재시도는 최대 2회
- **Entities:**
- PaymentMethod: enum[CARD, BANK, WALLET]
- Customer: { customerId: UUID, tier: enum[BASIC, PREMIUM, ENTERPRISE] }
- **Value Objects:**
- Money: { currency: ISO 4217, amount: decimal(19,4) }
- **Domain Events:**
- PaymentCreated: { trigger: "결제 요청 수신", data: [paymentId, amount, customerId] }
- PaymentCompleted: { trigger: "PG 승인 완료", data: [paymentId, pgTransactionId] }
- PaymentFailed: { trigger: "PG 거부 또는 타임아웃", data: [paymentId, errorCode, reason] }
### Relationships
- Payment CONTAINS PaymentMethod (1:1)
- Customer INITIATES Payment (1:N)
### Constraints
- 동일 Customer의 동시 결제는 최대 3건
- PROCESSING 상태는 최대 30초 유지, 초과 시 자동 FAILED 전환
7.2 온톨로지 기반 코드 생성
Kiro AI 에이전트는 이 온톨로지를 컨텍스트 윈도우에 주입하여:
-
코드 생성 시: 엔티티 관계와 invariant를 자동 준수
func CreatePayment(amount decimal.Decimal, customerID uuid.UUID) (*Payment, error) {
if amount.LessThanOrEqual(decimal.Zero) {
return nil, errors.New("결제 금액은 0보다 커야 합니다")
}
// 온톨로지 제약 자동 적용
} -
테스트 생성 시: 도메인 이벤트의 전이 경로를 기반으로 경계 케이스 자동 도출
func TestPaymentStatusTransition(t *testing.T) {
// 온톨로지의 상태 전이 규칙을 기반으로 자동 생성
t.Run("CREATED to PROCESSING", ...)
t.Run("PROCESSING to COMPLETED", ...)
t.Run("Invalid transition: COMPLETED to CREATED", ...)
} -
코드 리뷰 시: 온톨로지 위반 자동 탐지
## 온톨로지 위반 탐지
- ❌ Line 42: amount가 음수일 수 있음 (invariant 위반)
- ❌ Line 58: COMPLETED → PROCESSING 전이 시도 (잘못된 상태 전환)
8. 온톨로지와 생산성: ROI 증거
8.1 에러율 감소 사례
실전 데이터
Before (온톨로지 미적용):
- 초기 에러율: 8.3%
- 투자: $28K
- 31일 후 에러율: 7.9%
- 개선: 0.4%p (미미)
After (온톨로지 + 피드백 루프 적용):
- 초기 에러율: 8.3%
- 31일 후 에러율: 1.2%
- 개선: 7.1%p (85% 감소)
- 추가 효과: False Positive 67% 감소, 정확도 31% 향상
8.2 생산성 지표
| 지표 | 온톨로지 미적용 | 온톨로지 적용 | 개선율 |
|---|---|---|---|
| PR 리뷰 시간 | 평균 45분 | 평균 18분 | 60% 감소 |
| 테스트 커버리지 | 68% | 89% | 31%p 증가 |
| 프로덕션 인시던트 | 월 12건 | 월 2건 | 83% 감소 |
| 평균 수정 시간 | 2.3일 | 0.4일 | 83% 감소 |
8.3 참고 자료
- Why Ontology Matters for Agentic AI in 2026 — Ken Huang & Bhavya Gupta
- Why AI Agents Fail Without Ontologies — Nihal Parmar, 2026-03
9. AIDLC 3단계별 온톨로지 적용
9.1 Inception: 도메인 온톨로지 정의
활동:
- Mob Elaboration을 통한 도메인 개념 추출
- Aggregate, Entity, Value Object, Domain Event 정의
- 제약 조건(invariant) 명시
- Knowledge Graph 초기 구축
산출물:
requirements.md내 도메인 온톨로지 섹션- Knowledge Graph 스키마 (Neo4j/RDF)
온톨로지 피드백:
- Inner Loop: Mob Elaboration 세션 내 즉각적 정제
- 목표: 요구사항 정제 루프를 통해 온톨로지 초안 완성
9.2 Construction: 코드 생성 제약
활동:
- 온톨로지를 AI 에이전트 컨텍스트에 주입
- 온톨로지 기반 코드 생성 및 테스트 생성
- PR 리뷰 시 온톨로지 위반 자동 탐지
산출물:
- 온톨로지 제약을 준수하는 코드
- 도메인 이벤트 기반 통합 테스트
- PR 리뷰 메트릭 (온톨로지 위반 횟수)
온톨로지 피드백:
- Inner Loop: 테스트 실패 시 제약 조건 추가
- Middle Loop: PR 리뷰 패턴 분석 → 스키마 갱신
- 목표: 반복 에러 패턴을 온톨로지에 반영하여 구조적 차단
9.3 Operations: 운영 컨텍스트 모델 진화
활동:
- 운영 관찰성 데이터를 온톨로지 피드백으로 활용
- 인시던트 분석을 통한 도메인 모델 재설계
- SLO 위반 패턴을 제약 조건으로 인코딩
산출물:
- 운영 데이터 기반 온톨로지 갱신
- 인시던트 포스트모템 → 온톨로지 재설계 문서
- AIOps 통합: 관찰성 데이터 → 온톨로지 자동 정제
온톨로지 피드백:
- Outer Loop: 주 단위 인시던트 리뷰 → 도메인 구조 재설계
- 목표: 운영 경험을 온톨로지에 지속적으로 반영 (AIOps → AIDLC)
9.4 3단계 통합 효과
글씨가 작으면 확대해서 확인할 수 있습니다.
다이어그램
효과:
- Inception에서 정의한 온톨로지가 Construction에서 코드 생성을 제약
- Construction에서 발견한 패턴이 온톨로지를 정제
- Operations에서 발생한 인시던트가 온톨로지 구조를 재설계
- 순환 피드백을 통해 온톨로지가 지속적으로 진화
10. 관련 문서
10.1 AIDLC 신뢰성 듀얼 축
온톨로지는 WHAT + WHEN(도메인 제약 정의)을 담당하며, HOW(검증 메커니즘)는 하네스 엔지니어링이 담당합니다. 두 축의 협력으로 AI 생성 코드의 신뢰성을 보장합니다.
글씨가 작으면 확대해서 확인할 수 있습니다.
다이어그램
10.2 방법론 통합
10.3 기업 적용
10.4 운영 통합
- 자율 대응: Outer Loop의 운영 피드백을 자동화하는 AIOps 통합
참고 자료
핵심 논문 및 아티클
- Why Ontology Matters for Agentic AI in 2026 — Ken Huang & Bhavya Gupta
- Why AI Agents Fail Without Ontologies — Nihal Parmar, 2026-03
- SemanticForge: Knowledge Graph 기반 환각 방지
- How to Build an AI Agent Feedback Loop — Braincuber, 2026-03
- Human-in-the-Loop in Agentic AI — 2026-03
관련 프레임워크
- Kiro: MCP 네이티브 AI 코딩 에이전트, 온톨로지 기반 코드 생성 지원
- Neo4j: Knowledge Graph 구축 및 제약 검증
- SemanticForge: Knowledge Graph 기반 환각 방지 패턴