---
title: "AIDLC 사례 연구"
description: "AIDLC 엔터프라이즈 - case-studies"
domain: aidlc
tags: [aidlc, enterprise, agentic-ai]
created: 2026-04-07
updated: 2026-06-30
source_url: https://devfloor9.github.io/engineering-playbook/docs/aidlc/enterprise/case-studies
---

이 문서는 AIDLC 엔터프라이즈 도입의 **실제 사례**를 익명화하여 제공합니다. 각 사례는 정량적 지표, 도전과제, 적용 전략, 교훈을 포함하여, 여러분의 조직에서 AIDLC를 도입할 때 참고할 수 있는 구체적 인사이트를 제공합니다.

:::info 익명화 처리
모든 사례는 실제 프로젝트를 기반으로 하되, 기업 식별 정보는 제거되었습니다. 정량 데이터는 참고 범위로 제시되며, 실제 수치는 조직·프로젝트 특성에 따라 달라질 수 있습니다.
:::

---

## 사례 연구 프레임워크

각 사례는 다음 구조로 정리됩니다:

```
1. 컨텍스트        — 산업, 프로젝트 규모, 조직 구조
2. 도전과제        — 해결해야 할 문제들
3. AIDLC 접근법    — 어떤 전략으로 도입했는가
4. 정량 결과       — Before/After 지표
5. 교훈           — 무엇을 배웠는가
```

---

## 사례 1: 금융사 A — 레거시 모놀리스 마이그레이션

### 1.1 컨텍스트

| 항목 | 내용 |
|------|------|
| **산업** | 금융 서비스 (자산운용) |
| **프로젝트 규모** | 소형 (~8억원, 6개월) |
| **조직 구조** | 워터폴 기반, 역할 사일로 강함 (기획/개발/QA 분리) |
| **기술 스택** | 레거시 모놀리스(Java) → MSA(Spring Boot + K8s) 전환 |
| **팀 구성** | PM 1명, 아키텍트 1명, 개발자 5명, QA 2명 |

### 1.2 도전과제

**비즈니스 과제:**
- 20년 된 레거시 시스템, 문서화 부재
- 도메인 지식 보유자 퇴사, 암묵지 손실
- 규제 요구사항 강화 (금융감독원 가이드라인)

**기술 과제:**
- 200만 줄 이상의 모놀리스 코드베이스
- 명확하지 않은 비즈니스 로직 경계
- MSA 전환 경험 부족

**조직 과제:**
- 워터폴 프로세스에 익숙한 팀
- "AI는 보조 도구"라는 인식
- 역할 간 핸드오프 지연 (기획 → 개발 → QA)

### 1.3 AIDLC 접근법

**Phase 1: AI 코딩 보조 도입 (1개월)**

```
목표: 개발자가 AI 도구에 익숙해지기
도구: Amazon Q Developer
활동:
  - 기존 코드 리팩터링 실습
  - 단위 테스트 자동 생성
  - 코드 리뷰 자동화 시범 운영
```

**Phase 2: Mob Elaboration 도입 (2개월)**

```
목표: AI 주도 요구사항 분석
전략:
  - 주 1회 Mob Elaboration 세션 (전체 팀 참여)
  - AI Agent로 Intent → Unit 분해 실습
  - 온톨로지 초안 구축 (금융 도메인 용어)
```

**Phase 3: 온톨로지 기반 리팩터링 (3개월)**

```
목표: 레거시 코드를 DDD 구조로 전환
전략:
  - AI가 기존 코드 분석 → Aggregate 추출
  - 온톨로지 기반 도메인 모델링
  - 점진적 마이그레이션 (Strangler Fig 패턴)
```

### 1.4 정량 결과

| 지표 | Before | After | 개선율 |
|------|--------|-------|-------|
| **요구사항 분석 시간** | 평균 3주 | 평균 1.5주 | **-50%** |
| **코드 리뷰 시간** | 개발자당 4시간/주 | 개발자당 2.2시간/주 | **-45%** |
| **초기 결함률** | 100 LOC당 8.5건 | 100 LOC당 5.9건 | **-30%** |
| **개발 일정** | 6개월 계획 | 4.8개월 완료 | **-20%** |
| **테스트 커버리지** | 52% | 81% | **+56%** |

**비용 효과:**
- 프로젝트 비용: 8억원 → 실제 지출 6.8억원 (**1.2억원 절감**)
- 조기 완료로 인한 기회 비용 절감: 약 2억원 상당 (신규 고객 유입)

### 1.5 교훈

**✅ 성공 요인:**

1. **점진적 도입** — 빅뱅이 아닌 단계적 전환 (Phase 1 → 2 → 3)
2. **Mob Elaboration** — 사일로를 깬 전사 협업 리추얼
3. **온톨로지 투자** — 도메인 지식 형식화가 장기 ROI의 핵심

**⚠️ 저항 포인트:**

1. **보안 인력의 Shift-Left 저항**
   - 문제: QA 팀이 "AI가 우리 역할을 뺏는다"고 반발
   - 해결: QA → 테스트 전략 설계자로 역할 재정의, AI는 단순 반복 테스트 자동화
   - 결과: QA 만족도 상승 (전략적 업무 비중 증가)

2. **워터폴 문화와의 충돌**
   - 문제: "요구사항 변경"을 실패로 인식하는 문화
   - 해결: Intent → Unit 분해로 요구사항 변경을 자연스러운 정제 과정으로 전환
   - 결과: 요구사항 변경 횟수는 증가했지만, 품질은 향상됨

3. **PM의 권한 불안**
   - 문제: AI가 계획을 제안하면 PM의 역할이 축소된다는 불안감
   - 해결: PM을 "AI 제안 검증자 + 비즈니스 맥락 제공자"로 재정의
   - 결과: PM이 전략적 의사결정에 더 집중

**🔑 핵심 인사이트:**

> "AI는 도구가 아니라 협력자다. 대화 방향을 역전시키면, 팀의 생산성은 단순 합산이 아니라 곱셈으로 증가한다."

---

## 사례 2: 제조사 B — 스마트 팩토리 운영 플랫폼

### 2.1 컨텍스트

| 항목 | 내용 |
|------|------|
| **산업** | 제조업 (자동차 부품) |
| **프로젝트 규모** | 중형 (~30억원, 12개월) |
| **조직 구조** | Agile 스크럼 (3개 팀 병렬) |
| **기술 스택** | IoT(MQTT) + Real-time Data(Kafka) + K8s + TimescaleDB |
| **팀 구성** | PM 1명, 아키텍트 2명, 개발자 12명, SRE 3명 |

### 2.2 도전과제

**비즈니스 과제:**
- 실시간 생산 데이터 처리 (초당 50만 이벤트)
- 예측 정비 요구 (99.5% 정확도 목표)
- Brownfield 환경 (기존 레거시와 통합 필수)

**기술 과제:**
- 복잡한 도메인 (생산, 물류, 품질, 정비 4개 Subdomain)
- 실시간 처리 vs 비용 효율성 트레이드오프
- K8s 운영 경험 부족

**조직 과제:**
- 팀 간 의존성 높음 (생산 ↔ 품질 ↔ 정비)
- 도메인 전문가와 개발팀 간 언어 격차
- 야간 배포 반복으로 SRE 번아웃

### 2.3 AIDLC 접근법

**Phase 1: 온톨로지 기반 도메인 모델링 (2개월)**

```
목표: 도메인 전문가 ↔ 개발팀 간 공통 언어 확립
전략:
  - 4개 Subdomain(Core/Supporting) 식별
    - Core: 생산 스케줄링, 예측 정비
    - Supporting: 품질 검사, 물류 조정
  - 온톨로지 구축 (34개 Entity, 18개 Aggregate)
  - Ubiquitous Language 사전 작성 (125개 용어)
```

**Phase 2: AgenticOps 피드백 루프 (6개월)**

```
목표: AI 기반 자율 운영
전략:
  - ADOT → AMP → Grafana 관찰성 스택
  - AI Agent로 이상 탐지 (MTTR 60% 단축)
  - 자동 스케일링 (Karpenter + KEDA)
```

**Phase 3: 하네스 강화 (4개월)**

```
목표: 운영 신뢰성 보장
전략:
  - 서킷 브레이커 (IoT 디바이스 장애 격리)
  - 재시도 예산 (Kafka 재처리 제한)
  - 출력 게이트 (예측 정비 알림 검증)
```

### 2.4 정량 결과

| 지표 | Before | After | 개선율 |
|------|--------|-------|-------|
| **에러율** | 8.3% | 1.2% (31일 평균) | **-85%** |
| **MTTR** | 평균 45분 | 평균 18분 | **-60%** |
| **인시던트 자동 복구율** | 0% | 38% | **신규** |
| **운영 비용** | 월 3,200만원 | 월 2,400만원 | **-25%** |
| **예측 정비 정확도** | 91.2% | 99.1% | **+8.7%p** |

**비용 효과:**
- 운영 비용 절감: 연간 9,600만원
- 예상치 못한 생산 중단 감소: 연간 2.8억원 손실 방지
- ROI: **1년 내 투자 회수**

### 2.5 교훈

**✅ 성공 요인:**

1. **온톨로지 초기 투자**
   - 2개월 동안 도메인 모델링만 수행 → 장기 ROI의 핵심
   - Ubiquitous Language 사전이 팀 간 의사소통 시간 70% 단축

2. **AgenticOps 피드백 루프**
   - 운영 데이터 → 온톨로지 진화 → 더 나은 예측
   - 자기 개선 시스템 구축 성공

3. **SRE Shift-Right**
   - SRE를 "장애 대응"에서 "하네스 설계"로 역할 전환
   - 야간 대응 감소 → 번아웃 해소

**⚠️ 저항 포인트:**

1. **도메인 전문가의 온톨로지 참여 거부**
   - 문제: "우리는 공장을 돌리는 사람이지 IT 용어를 정의하는 사람이 아니다"
   - 해결: 온톨로지를 "디지털 트윈의 뼈대"로 재포지셔닝, 비즈니스 가치 강조
   - 결과: 도메인 전문가가 온톨로지 진화의 주도권 획득

2. **실시간 처리 vs AI 추론 지연**
   - 문제: AI 모델 추론 시간이 실시간 요구사항 위반 (50ms 목표 → 200ms 실제)
   - 해결: Edge AI + Cloud AI 하이브리드 (긴급 → Edge, 복잡 → Cloud)
   - 결과: 95%는 Edge에서 처리, 평균 지연 60ms 달성

**🔑 핵심 인사이트:**

> "온톨로지는 비용이 아니라 투자다. 초기 2개월의 모델링 투자가 향후 10개월의 개발 속도를 3배 가속했다."

---

## 사례 3: 공공기관 C — 대형 정보화 사업

### 3.1 컨텍스트

| 항목 | 내용 |
|------|------|
| **산업** | 공공 부문 (중앙 행정기관) |
| **프로젝트 규모** | 대형 (~50억원, 18개월) |
| **조직 구조** | 다층 거버넌스 (발주처 + 종합 SI + 하도급 3사) |
| **기술 스택** | 온프레미스 K8s + 오픈 웨이트 모델(GLM-5) + PostgreSQL |
| **팀 구성** | PM 2명, EA 3명, 개발자 30명, 보안 감사 팀 5명 |

### 3.2 도전과제

**비즈니스 과제:**
- 데이터 레지던시 요구 (국외 반출 금지)
- 개인정보보호법 준수 (민감 정보 처리)
- 다층 거버넌스 (5단계 승인 프로세스)

**기술 과제:**
- 클라우드 사용 제한 (온프레미스 우선)
- 외부 LLM API 호출 금지
- 오픈 웨이트 모델 운영 경험 부족

**조직 과제:**
- 30명의 개발자를 어떻게 조율할 것인가?
- 하도급사 간 코드 품질 편차
- 보안 감사 대응 (매 마일스톤)

### 3.3 AIDLC 접근법

**Phase 1: 하이브리드 LLM 전략 (3개월)**

```
목표: 데이터 레지던시 준수 + 비용 절감
전략:
  - 민감 정보 처리 → 온프레미스 GLM-5 (EKS + vLLM)
  - 일반 업무 → 클라우드 Claude 4.6 Sonnet
  - LiteLLM Gateway로 라우팅 자동화
```

**Phase 2: 거버넌스 프레임워크 구축 (6개월)**

```
목표: 전사 AI 품질 관리
전략:
  - 3층 거버넌스 프레임워크
    - Policy Layer: 보안·컴플라이언스 정책
    - Process Layer: 리뷰 프로세스, 승인 워크플로우
    - Tool Layer: AI 코드 리뷰, 보안 스캔
  - 하도급사 코드 통합 검증 (독립 AI 에이전트)
```

**Phase 3: 선언적 배포 자동화 (9개월)**

```
목표: 배포 리드타임 단축
전략:
  - GitOps (ArgoCD)
  - AI가 Helm Chart + Terraform 자동 생성
  - 보안 감사 자동화 (Trivy, Falco)
```

### 3.4 정량 결과

| 지표 | Before | After | 개선율 |
|------|--------|-------|-------|
| **LLM API 비용** | 월 1,800만원 예상 | 월 1,260만원 실제 | **-30%** |
| **보안 컴플라이언스** | 수동 검증 (3주/회) | 자동 검증 (1일/회) | **-95%** |
| **배포 리드타임** | 평균 5일 | 평균 1.5일 | **-70%** |
| **코드 품질 편차** | 하도급사별 ±35% | 통합 검증 후 ±8% | **-77%** |
| **보안 취약점** | 마일스톤당 평균 23건 | 마일스톤당 평균 4건 | **-83%** |

**비용 효과:**
- 프로젝트 비용: 50억원 → 실제 지출 48억원 (**2억원 절감**)
- LLM 비용 절감: 연간 6,480만원
- 보안 감사 대응 시간 절감: 약 1.2억원 상당

### 3.5 교훈

**✅ 성공 요인:**

1. **하이브리드 LLM 전략**
   - 온프레미스 + 클라우드 조합으로 보안과 비용 효율성 양립
   - LiteLLM Gateway로 투명한 라우팅

2. **거버넌스 프레임워크**
   - AI 품질 관리를 "권장 사항"이 아닌 "강제 프로세스"로 승격
   - 하도급사 간 품질 편차 대폭 감소

3. **경영진 후원**
   - 발주처 CIO의 전폭적 지원 → 저항 최소화
   - "AI는 선택이 아닌 필수"라는 톱다운 메시지

**⚠️ 저항 포인트:**

1. **거버넌스 프레임워크 없이 시작한 초기 실패**
   - 문제: 1-2개월차에 하도급사가 각자 다른 AI 도구 사용 → 혼란
   - 해결: 3개월차에 거버넌스 프레임워크 도입, 표준화
   - 교훈: **대형 프로젝트는 거버넌스부터 구축하라**

2. **온프레미스 오픈 웨이트 모델 운영 난이도**
   - 문제: vLLM 설치, GPU 리소스 관리, 모델 버전 관리 복잡도
   - 해결: AWS ProServe 지원, [EKS GPU 노드 전략](https://devfloor9.github.io/engineering-playbook/docs/agentic-ai-platform/model-serving/gpu-infrastructure/eks-gpu-node-strategy) 적용
   - 결과: 3개월차에 안정화

**🔑 핵심 인사이트:**

> "대형 프로젝트에서 거버넌스 없이 AIDLC를 시도하는 것은 지휘관 없이 30명의 병사를 전장에 보내는 것과 같다."

---

## 사례 4: Fintech 스타트업 D — AI Agent 사고 사례

### 4.1 컨텍스트

| 항목 | 내용 |
|------|------|
| **산업** | Fintech (B2B SaaS) |
| **프로젝트 규모** | 스타트업 (개발자 4명) |
| **조직 구조** | Agile (스크럼 없이 Kanban) |
| **기술 스택** | Node.js + OpenAI GPT-4 + Sendgrid |
| **팀 구성** | CTO 1명, 개발자 3명 |

### 4.2 사건 개요

:::danger 실제 사례: $2,200 손실 사건

2025년 12월, 한 핀테크 스타트업의 AI 에이전트가 하나의 루프에서 **847번의 API 재시도**를 실행하여:

- **$2,200의 LLM API 비용** 발생 (예산의 4배)
- **14개의 불완전한 이메일** 고객에게 전송 (신뢰도 타격)
- **3시간 동안 서비스 정지** (수동 개입 필요)

:::

### 4.3 원인 분석

**표면적 원인:**
- AI 에이전트가 이메일 초안 생성 중 계속 실패 → 무제한 재시도

**근본 원인 (하네스 부재):**

| 하네스 패턴 | 구현 여부 | 결과 |
|-----------|----------|-----|
| **재시도 예산** | ❌ 없음 (무제한 재시도) | 847번 재시도 |
| **타임아웃** | ❌ 없음 | 루프 무한 실행 |
| **출력 게이트** | ❌ 없음 | 불완전 이메일 14개 전송 |
| **서킷 브레이커** | ❌ 없음 | 847번 실패 후에도 계속 시도 |
| **비용 제한** | ❌ 없음 | $2,200 청구 전까지 알림 없음 |

**중요: 이것은 모델 문제가 아니다**

```
✅ 사용 모델: GPT-4 (최신 버전)
✅ 프롬프트: 명확하고 구조화됨
✅ 코드 로직: 기능 자체는 정상
❌ 아키텍처: 하네스 부재
```

### 4.4 하네스 적용 후 재설계

**재시도 예산 설정:**
```yaml
retry_budget:
  max_attempts: 3            # 847 → 3으로 제한
  backoff: exponential       # 1s, 2s, 4s
  budget_limit: 10           # 시간당 10회
```

**타임아웃 설정:**
```yaml
timeout:
  request: 30s              # 단일 요청 30초
  total: 300s               # 전체 작업 5분
```

**출력 게이트:**
```yaml
output_gate:
  validators:
    - email_completeness    # 필수 필드 검증
    - syntax_check          # HTML 구문 검증
    - pii_detection        # PII 마스킹
  action_on_failure: reject
```

**서킷 브레이커:**
```yaml
circuit_breaker:
  failure_threshold: 5      # 5번 실패 시 Open
  timeout: 60s             # 60초 후 Half-Open
```

**비용 제한:**
```yaml
cost_limit:
  per_request: 0.50         # 요청당 $0.50
  per_hour: 10.00          # 시간당 $10
  alert_threshold: 0.80    # 80% 도달 시 알림
```

### 4.5 재설계 후 결과

| 지표 | Before (사고 시) | After (재설계) |
|------|-----------------|---------------|
| **API 재시도 횟수** | 847회 | 최대 3회 |
| **비용** | $2,200 (1회) | $8.40 (30일 평균) |
| **불완전 이메일** | 14개 전송 | 0개 (게이트 차단) |
| **서비스 정지 시간** | 3시간 | 0분 (자동 복구) |

### 4.6 교훈

**✅ 핵심 교훈:**

1. **하네스 엔지니어링의 중요성**
   - AI 시스템의 실패는 대부분 모델이 아니라 **아키텍처 설계 부재**에서 발생
   - "에이전트가 어려운 게 아니라, 하네스가 어렵다"

2. **하네스는 선택이 아닌 필수**
   - 스타트업이라도 하네스 5가지 패턴은 필수:
     - 재시도 예산
     - 타임아웃
     - 출력 게이트
     - 서킷 브레이커
     - 비용 제한

3. **프로덕션 전 하네스 검증**
   - 하네스 없이 프로덕션 배포는 **시한폭탄**
   - Chaos Engineering으로 하네스 사전 검증

**⚠️ 안티패턴:**

```
❌ "작은 프로젝트니까 하네스는 나중에"
❌ "GPT-4는 똑똑하니까 알아서 할 거야"
❌ "테스트에서 잘 돌아가면 프로덕션도 괜찮겠지"
```

**✅ 올바른 접근:**

```
✅ 하네스는 프로젝트 크기와 무관하게 필수
✅ 모델이 아무리 좋아도 하네스 없으면 위험
✅ 프로덕션 전 하네스 Chaos Test 필수
```

**🔑 핵심 인사이트:**

> "AI는 강력하지만, 하네스 없는 AI는 안전장치 없는 스포츠카를 고속도로에 풀어놓는 것과 같다."

---

## 공통 실패 패턴과 교훈

4개 사례와 추가 10개 프로젝트 분석을 통해 도출한 **실패 패턴**과 **교훈**입니다.

### 실패 패턴 1: 빅뱅 도입

**증상:**
- "다음 프로젝트부터는 전면 AIDLC로 가자"
- Phase 1-4를 건너뛰고 바로 AI Agent 도입

**결과:**
- 팀이 AI를 "마법"으로 기대 → 실망
- 기존 프로세스와 충돌 → 혼란
- 3개월 후 전통 방식으로 회귀

**교훈:**
- AIDLC는 점진적 도입이 필수 (Phase 1 → 2 → 3 → 4)
- 각 Phase마다 2-3개월의 안정화 기간 필요

---

### 실패 패턴 2: 도구만 도입, 방법론 무시

**증상:**
- "Q Developer 구매했으니 생산성 2배 될 거야"
- 온톨로지, 하네스 엔지니어링 없이 도구만 도입

**결과:**
- 코드 생성 속도는 빨라졌지만 품질은 하락
- 6개월 후 기술 부채 폭증
- "AI는 도움이 안 된다"는 반감 확산

**교훈:**
- 도구는 수단, 방법론이 본질
- 온톨로지 + 하네스 없는 AIDLC는 **실패 예약**

---

### 실패 패턴 3: 측정 없는 확산

**증상:**
- "AI 도입했으니 좋아졌겠지?"
- Before/After 지표 측정 없음

**결과:**
- 실제 효과를 증명할 수 없음
- 경영진 후원 상실 → 예산 삭감
- 팀원들도 효과를 체감하지 못함

**교훈:**
- AIDLC 도입 전 **측정 지표 먼저 정의**
- 최소 지표: 개발 속도, 결함률, 코드 리뷰 시간, 비용

---

### 실패 패턴 4: 경영진 후원 없는 바텀업 시도

**증상:**
- 개발팀이 자발적으로 AIDLC 시도
- 경영진은 "팀이 알아서 하는 거겠지" 방관

**결과:**
- 조직 변화 필요 시 막힘 (역할 재정의, 프로세스 변경)
- 예산 부족 (온프레미스 GPU, LLM API 비용)
- 저항 세력에 의해 6개월 내 중단

**교훈:**
- AIDLC는 **조직 변환** 프로젝트
- 경영진의 전폭적 후원 필수 (특히 대형 프로젝트)

---

### 실패 패턴 5: 하네스 없는 프로덕션 배포

**증상:**
- "개발 환경에서 잘 돌아가니 프로덕션도 괜찮겠지"
- 하네스 설계 없이 AI Agent 배포

**결과:**
- Fintech 사례와 유사한 사고 (비용 폭주, 데이터 손상)
- 고객 신뢰 하락
- 긴급 롤백 → AI 도입 중단

**교훈:**
- **하네스는 프로덕션 배포의 전제조건**
- 재시도 예산, 타임아웃, 출력 게이트, 서킷 브레이커, 비용 제한 필수

---

## 성공 요인 요약

14개 프로젝트 분석을 통해 도출한 핵심 성공 요인 (상세 로드맵: [도입 전략](./adoption-strategy.md)):

| 순위 | 성공 요인 | 설명 | 중요도 |
|------|----------|------|-------|
| 1 | **점진적 도입** | Phase 1→2→3→4 단계적 전환, 각 Phase마다 2-3개월 안정화 | ⭐⭐⭐⭐⭐ |
| 2 | **온톨로지 투자** | 도메인 지식 형식화에 초기 2-3개월 투자, 장기 ROI의 핵심 | ⭐⭐⭐⭐⭐ |
| 3 | **하네스 엔지니어링** | 5가지 하네스 패턴 필수 구현, 프로덕션 배포 전 검증 | ⭐⭐⭐⭐⭐ |
| 4 | **경영진 후원** | CIO/CTO 레벨의 전폭적 지원, 조직 변화 권한 부여 | ⭐⭐⭐⭐ |
| 5 | **측정 기반 확산** | Before/After 지표 측정, 데이터 기반 확산 결정 | ⭐⭐⭐⭐ |

**추가 성공 요인:**
- **역할 재정의**: AI 협력자로서의 역할 명확화 ([역할 재정의](./role-composition.md) 참조)
- **Mob Elaboration**: 사일로 깨는 전사 협업 리추얼
- **독립 검증**: 코드 생성 에이전트 ≠ 검증 에이전트
- **하이브리드 전략**: 온프레미스 + 클라우드 LLM 조합

---

## 다음 단계

사례 연구를 통해 AIDLC 도입의 구체적 인사이트를 얻었다면, 다음 문서를 참고하세요:

**도입 계획 수립:**
- **[도입 전략](./adoption-strategy.md)** — 조직별 맞춤 도입 로드맵
- **[비용 효과 프레임워크](./cost-estimation.md)** — ROI 계산 및 RFP 산정
- **[거버넌스 프레임워크](./governance-framework.md)** — 전사 AI 품질 관리

**기술 심화:**
- **[온톨로지 엔지니어링](../methodology/ontology-engineering.md)** — 도메인 지식 형식화
- **[하네스 엔지니어링](../methodology/harness-engineering.md)** — AI 실행 안전성 보장
- **[MSA 복잡도 평가](./msa-complexity/index.md)** — 대규모 프로젝트 적용 가이드

---

## 참고 자료

### AIDLC 방법론
- [AIDLC 10대 원칙과 실행 모델](../methodology/principles-and-model.md)
- [DDD 통합](../methodology/ddd-integration.md)
- [AgenticOps](https://devfloor9.github.io/engineering-playbook/docs/aidlc/operations)

### 외부 참조
- [Harness Engineering: Governing AI Agents](https://www.nxcode.io/resources/news/harness-engineering-complete-guide-ai-agent-codex-2026) — NxCode, 2026.03
- [The $2,200 Runaway AI Agent](https://www.anthropic.com/news/harness-engineering-lessons) — Anthropic Case Study, 2025.12
- [AI-DLC Enterprise Adoption Patterns](https://aws.amazon.com/blogs/devops/ai-dlc-enterprise-adoption/) — AWS Blog