전체 하네스 계층 통합, 하네스 성숙도 모델, CI/CD 파이프라인 통합, CLAUDE.md와 AGENTS.md 설계, 팀 협업 전략까지 하네스 엔지니어링의 완결편입니다.
지난 9개 장에 걸쳐 하네스 엔지니어링의 개별 영역들을 살펴보았습니다. 모델 래핑, 테스트, 평가, 가드레일, 오케스트레이션, 배포, 모니터링. 각각이 중요하지만, 이들이 분리된 채로 운영되면 전체 시스템의 일관성이 깨집니다. 이번 마지막 장에서는 이 모든 것을 하나의 유기적인 시스템으로 통합하는 전략을 다루겠습니다.
개별 하네스들을 통합한 전체 아키텍처는 다음과 같습니다. 각 계층이 명확한 책임을 가지면서도, 공통 인프라(로깅, 메트릭, 설정 관리)를 공유합니다.
조직의 하네스 수준을 평가하고 개선 방향을 잡기 위한 성숙도 모델입니다. 모든 조직이 처음부터 레벨 5를 목표로 할 필요는 없습니다. 현재 수준을 파악하고 단계적으로 개선하는 것이 중요합니다.
| 레벨 | 이름 | 특징 |
|---|---|---|
| 1 | Ad-hoc | 모델 API 직접 호출, 하네스 개념 없음 |
| 2 | Basic | 래핑 패턴 적용, 기본 에러 처리, 수동 테스트 |
| 3 | Structured | 체계적 테스트, 평가 파이프라인, 기본 가드레일 |
| 4 | Managed | 자동화된 CI/CD, 카나리 배포, 실시간 모니터링 |
| 5 | Optimized | 피드백 루프 기반 자동 개선, 멀티에이전트 오케스트레이션 |
from dataclasses import dataclass
@dataclass
class MaturityAssessment:
"""하네스 성숙도 평가"""
# 레벨 1: Ad-hoc
has_model_abstraction: bool = False
has_error_handling: bool = False
# 레벨 2: Basic
has_retry_logic: bool = False
has_output_parsing: bool = False
has_basic_logging: bool = False
# 레벨 3: Structured
has_automated_tests: bool = False
has_eval_pipeline: bool = False
has_input_guardrails: bool = False
has_output_guardrails: bool = False
has_golden_dataset: bool = False
# 레벨 4: Managed
has_cicd_integration: bool = False
has_canary_deployment: bool = False
has_realtime_monitoring: bool = False
has_cost_tracking: bool = False
has_alerting: bool = False
# 레벨 5: Optimized
has_feedback_loop: bool = False
has_drift_detection: bool = False
has_auto_remediation: bool = False
has_multi_agent_orchestration: bool = False
@property
def level(self) -> int:
if not (self.has_model_abstraction and self.has_error_handling):
return 1
level_2 = all([
self.has_retry_logic,
self.has_output_parsing,
self.has_basic_logging,
])
if not level_2:
return 2
level_3 = all([
self.has_automated_tests,
self.has_eval_pipeline,
self.has_input_guardrails,
self.has_output_guardrails,
])
if not level_3:
return 3
level_4 = all([
self.has_cicd_integration,
self.has_canary_deployment,
self.has_realtime_monitoring,
self.has_cost_tracking,
])
if not level_4:
return 4
level_5 = all([
self.has_feedback_loop,
self.has_drift_detection,
self.has_auto_remediation,
])
return 5 if level_5 else 4
@property
def next_steps(self) -> list[str]:
"""현재 레벨에서 다음으로 해야 할 것"""
current = self.level
steps = []
if current <= 1:
if not self.has_model_abstraction:
steps.append("모델 추상화 계층 구현 (3장 참조)")
if not self.has_error_handling:
steps.append("기본 에러 처리 및 재시도 로직 추가")
elif current <= 2:
if not self.has_automated_tests:
steps.append("속성 기반 테스트 도입 (4장 참조)")
if not self.has_eval_pipeline:
steps.append("평가 파이프라인 구축 (5장 참조)")
if not self.has_input_guardrails:
steps.append("입력 가드레일 추가 (6장 참조)")
elif current <= 3:
if not self.has_cicd_integration:
steps.append("CI/CD에 평가 게이트 통합")
if not self.has_realtime_monitoring:
steps.append("실시간 모니터링 대시보드 구축 (9장 참조)")
elif current <= 4:
if not self.has_feedback_loop:
steps.append("사용자 피드백 루프 구현")
if not self.has_drift_detection:
steps.append("드리프트 감지 시스템 추가")
return steps대부분의 팀은 레벨 2-3에 있습니다. 레벨 3에 도달하는 것만으로도 프로덕션 AI 시스템의 안정성이 크게 향상됩니다. 레벨 1에서 바로 레벨 5를 목표로 하기보다는, 한 단계씩 착실히 올라가는 것을 권장합니다.
AI 시스템의 CI/CD는 코드 검증에 더해 모델 평가와 안전성 검증을 포함해야 합니다.
name: AI System CI/CD
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
lint-and-type-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pnpm install
- run: pnpm lint
- run: pnpm typecheck
unit-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pnpm install
- run: pnpm test:unit
# 하네스 코드의 결정적 테스트
eval-gate:
runs-on: ubuntu-latest
needs: [unit-tests]
steps:
- uses: actions/checkout@v4
- run: pnpm install
- name: 골든 데이터셋 평가
run: |
pnpm eval:golden --dataset eval/golden_v12.json
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
- name: 평가 결과 확인
run: |
# 통과율 95% 미만이면 실패
pnpm eval:check --min-pass-rate 0.95
safety-check:
runs-on: ubuntu-latest
needs: [unit-tests]
steps:
- uses: actions/checkout@v4
- run: pnpm install
- name: 가드레일 테스트
run: |
pnpm test:guardrails
- name: 프롬프트 인젝션 테스트
run: |
pnpm test:injection --dataset eval/injection_tests.json
deploy-canary:
runs-on: ubuntu-latest
needs: [eval-gate, safety-check]
if: github.ref == 'refs/heads/main'
steps:
- name: 카나리 배포 (5%)
run: deploy --strategy canary --percentage 5
- name: 모니터링 대기 (1시간)
run: monitor --duration 3600 --check-interval 300
- name: 승격 또는 롤백
run: deploy --auto-promote-or-rollbackCI/CD에서 실제 모델 API를 호출하는 테스트는 비용이 발생합니다. 골든 데이터셋의 크기를 적절히 관리하고, PR마다 전체 데이터셋을 실행하기보다 변경된 영역과 관련된 서브셋만 실행하는 전략이 실용적입니다.
Anthropic이 제안한 CLAUDE.md와 AGENTS.md는 AI 에이전트의 하네스 설정을 코드 저장소에 포함시키는 표준입니다. 프로젝트의 맥락, 규칙, 제약사항을 AI가 직접 읽을 수 있는 형식으로 기술합니다.
# 프로젝트 개요
이 프로젝트는 [설명]입니다.
## 기술 스택
- Framework: Next.js 16 (App Router)
- Language: TypeScript (strict mode)
- Styling: Tailwind CSS v4
## 핵심 규칙
1. TypeScript strict 모드를 사용합니다. any 타입은 금지입니다.
2. 모든 변경 후 빌드가 통과해야 합니다.
3. 컴포넌트는 함수 선언을 사용합니다.
## 코딩 컨벤션
- 파일명: 컴포넌트는 PascalCase, 유틸리티는 kebab-case
- import 순서: React/Next -> 외부 -> 내부 -> 타입
- 커밋: Conventional Commits 형식
## 디렉토리 구조
src/
app/ # App Router 페이지
components/ # UI 컴포넌트
lib/ # 유틸리티AGENTS.md는 CLAUDE.md보다 더 구체적으로, 에이전트의 행동 규칙과 도구 사용 가이드를 기술합니다.
# 에이전트 행동 규칙
## 허용된 행동
- 파일 읽기 및 분석
- 코드 리뷰 및 제안
- 테스트 코드 작성
- 문서 업데이트
## 금지된 행동
- 프로덕션 데이터베이스 직접 접근
- 환경 변수 파일(.env) 수정
- main 브랜치에 직접 푸시
- 사용자 확인 없이 파일 삭제
## 도구 사용 가이드
### 파일 수정 시
1. 반드시 기존 파일을 먼저 읽을 것
2. 변경 범위를 최소화할 것
3. 변경 후 관련 테스트를 실행할 것
### 코드 실행 시
1. 샌드박스 환경에서만 실행
2. 네트워크 접근이 필요한 코드는 사전 확인
3. 실행 시간 제한: 60초
## 에스컬레이션
다음 상황에서는 사용자에게 확인을 요청하세요:
- 10개 이상의 파일 수정
- 의존성 패키지 추가/삭제
- 보안 관련 코드 변경
- 성능에 영향을 줄 수 있는 변경CLAUDE.md와 AGENTS.md는 코드와 함께 버전 관리됩니다. 프로젝트의 규칙이 변경되면 이 파일도 함께 업데이트합니다. 이것이 바로 하네스를 코드로 관리하는 PaC(Prompt as Code) 접근법의 실체입니다.
하네스 엔지니어링은 혼자 하는 작업이 아닙니다. 개발팀, 데이터팀, 운영팀이 협업하여 하네스의 각 계층을 담당합니다.
| 역할 | 담당 하네스 계층 | 주요 책임 |
|---|---|---|
| 백엔드 개발자 | 모델 래핑, 오케스트레이션 | 모델 추상화, 도구 통합, API 설계 |
| ML 엔지니어 | 평가, 모니터링 | 벤치마크 설계, 품질 메트릭, 드리프트 감지 |
| 보안 엔지니어 | 가드레일 | 인젝션 방어, 콘텐츠 필터링, 접근 제어 |
| DevOps/SRE | 배포, 모니터링 | CI/CD 파이프라인, 카나리 배포, 알림 |
| 프로덕트 매니저 | 테스트 (골든 데이터셋) | 기대 동작 정의, 품질 기준 설정 |
프롬프트 변경은 코드 변경과 동일한 리뷰 프로세스를 거쳐야 합니다.
지금까지의 내용을 종합한 실전 프로젝트의 디렉토리 구조입니다.
project/
CLAUDE.md # 프로젝트 규칙 (AI가 읽는 문서)
AGENTS.md # 에이전트 행동 규칙
src/
harness/
model/
adapter.py # 모델 추상화 (3장)
fallback.py # 폴백 체인 (3장)
pipeline/
preprocessor.py # 입력 전처리 (3장)
postprocessor.py # 출력 후처리 (3장)
prompt_composer.py # 프롬프트 구성 (3장)
guardrails/
input_guard.py # 입력 가드레일 (6장)
output_guard.py # 출력 가드레일 (6장)
pii_masker.py # PII 마스킹 (6장)
orchestration/
agent.py # 에이전트 오케스트레이터 (7장)
tool_registry.py # 도구 레지스트리 (7장)
sub_agent.py # 서브에이전트 관리 (7장)
monitoring/
cost_tracker.py # 비용 추적 (9장)
latency_tracer.py # 지연시간 추적 (9장)
quality_monitor.py # 품질 모니터링 (9장)
drift_detector.py # 드리프트 감지 (9장)
deployment/
config.yaml # 배포 설정 (8장)
prompts/
system_v5.txt # 시스템 프롬프트 (버전 관리)
few_shot_v3.json # 퓨샷 예제
eval/
golden_v12.json # 골든 데이터셋 (4장)
injection_tests.json # 인젝션 테스트 (6장)
benchmarks/ # 벤치마크 스위트 (5장)
tests/
unit/ # 단위 테스트 (하네스 코드)
integration/ # 통합 테스트 (목 모델)
eval/ # 평가 테스트 (실제 모델)
.github/
workflows/
ci.yml # CI 파이프라인
eval-gate.yml # 평가 게이트
deploy.yml # 배포 파이프라인
이 구조를 처음부터 모두 갖출 필요는 없습니다. 성숙도 모델 레벨 2에서는 model/과 pipeline/만으로 시작하고, 레벨이 올라감에 따라 guardrails/, monitoring/, orchestration/을 추가하는 점진적 접근을 권장합니다.
이 시리즈에서 다룬 내용을 한 문장으로 요약하면 이렇습니다.
AI 시스템의 경쟁력은 모델이 아니라 하네스에서 결정됩니다.
같은 모델을 사용해도 하네스 품질에 따라 40점 이상의 성능 차이가 발생할 수 있다는 사실은, 하네스 엔지니어링이 선택이 아닌 필수임을 의미합니다. 2026년은 "어떤 모델을 쓰느냐"보다 "모델을 어떻게 감싸느냐"가 중요한 시대입니다.
| 장 | 핵심 메시지 |
|---|---|
| 1장 | Agent = Model + Harness. 하네스가 전체 시스템의 80%입니다. |
| 2장 | 래핑, 미들웨어, 사이드카, 파이프라인, 이벤트 기반 5가지 패턴을 상황에 맞게 조합합니다. |
| 3장 | 모델 추상화로 공급자 교체 비용을 줄이고, 스키마 기반으로 출력을 제어합니다. |
| 4장 | 비결정적 출력은 속성으로 테스트하고, 골든 데이터셋으로 회귀를 방지합니다. |
| 5장 | lm-evaluation-harness, Inspect AI, HELM으로 모델과 에이전트를 체계적으로 평가합니다. |
| 6장 | 다계층 가드레일로 프롬프트 인젝션, 유해 콘텐츠, PII 노출을 방어합니다. |
| 7장 | 에이전트 라이프사이클, 도구 제어, 서브에이전트 위임, 체크포인팅으로 복잡한 워크플로우를 조율합니다. |
| 8장 | 카나리 배포, 섀도우 테스팅, A/B 테스트로 안전하게 릴리즈합니다. |
| 9장 | 토큰 비용, 지연시간, 품질, 드리프트를 실시간으로 추적하고, 피드백 루프로 개선합니다. |
| 10장 | 전체 하네스를 통합하고, CI/CD와 팀 협업 체계를 구축합니다. |
하네스 엔지니어링은 아직 초기 단계의 분야입니다. 표준이 정립되고 있고, 도구들이 빠르게 진화하고 있습니다. 이 시리즈가 여러분의 AI 시스템을 한 단계 더 견고하게 만드는 데 도움이 되었기를 바랍니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
토큰 사용량, 지연시간, 비용 추적, 드리프트 감지, 품질 모니터링, 알림 설계, 피드백 루프 등 AI 시스템의 관측 가능성 파이프라인을 다룹니다.
카나리 배포, 섀도우 테스팅, A/B 테스트, 블루-그린 배포, 롤백 전략 등 AI 시스템을 프로덕션에 안전하게 배포하는 전략을 다룹니다.
에이전트 라이프사이클 관리, 도구 오케스트레이션, 서브에이전트 관리, 상태 관리, 에러 복구 등 복잡한 AI 워크플로우를 조율하는 방법을 다룹니다.