본문으로 건너뛰기
Kreath Archive
TechProjectsBooksAbout
TechProjectsBooksAbout

내비게이션

  • Tech
  • Projects
  • Books
  • About
  • Tags

카테고리

  • AI / ML
  • 웹 개발
  • 프로그래밍
  • 개발 도구

연결

  • GitHub
  • Email
  • RSS
© 2026 Kreath Archive. All rights reserved.Built with Next.js + MDX
홈TechProjectsBooksAbout
//
  1. 홈
  2. 테크
  3. 10장: 프로덕션 하네스 통합 전략
2026년 3월 27일·AI / ML·

10장: 프로덕션 하네스 통합 전략

전체 하네스 계층 통합, 하네스 성숙도 모델, CI/CD 파이프라인 통합, CLAUDE.md와 AGENTS.md 설계, 팀 협업 전략까지 하네스 엔지니어링의 완결편입니다.

22분786자9개 섹션
aitestingevaluationmlops
공유
harness-engineering10 / 10
12345678910
이전9장: 모니터링 하네스 — 프로덕션 관측과 피드백 루프

지난 9개 장에 걸쳐 하네스 엔지니어링의 개별 영역들을 살펴보았습니다. 모델 래핑, 테스트, 평가, 가드레일, 오케스트레이션, 배포, 모니터링. 각각이 중요하지만, 이들이 분리된 채로 운영되면 전체 시스템의 일관성이 깨집니다. 이번 마지막 장에서는 이 모든 것을 하나의 유기적인 시스템으로 통합하는 전략을 다루겠습니다.

이 장에서 다루는 내용

  • 전체 하네스 계층의 통합 아키텍처
  • 하네스 성숙도 모델(Harness Maturity Model)
  • CI/CD 파이프라인에 하네스 통합
  • CLAUDE.md와 AGENTS.md 설계
  • 팀 협업 전략
  • 실전 프로젝트 아키텍처

전체 하네스 계층 통합

개별 하네스들을 통합한 전체 아키텍처는 다음과 같습니다. 각 계층이 명확한 책임을 가지면서도, 공통 인프라(로깅, 메트릭, 설정 관리)를 공유합니다.

통합의 핵심 원칙

  1. 단일 설정 소스: 모든 하네스가 참조하는 설정은 하나의 저장소에서 관리합니다.
  2. 일관된 로깅: 모든 하네스가 동일한 형식으로 로그를 기록하여 추적을 용이하게 합니다.
  3. 공유 메트릭: 비용, 지연시간, 품질 메트릭을 통합 대시보드에서 확인합니다.
  4. 독립 배포: 각 하네스 컴포넌트를 독립적으로 업데이트할 수 있어야 합니다.

하네스 성숙도 모델

조직의 하네스 수준을 평가하고 개선 방향을 잡기 위한 성숙도 모델입니다. 모든 조직이 처음부터 레벨 5를 목표로 할 필요는 없습니다. 현재 수준을 파악하고 단계적으로 개선하는 것이 중요합니다.

5단계 성숙도 모델

레벨이름특징
1Ad-hoc모델 API 직접 호출, 하네스 개념 없음
2Basic래핑 패턴 적용, 기본 에러 처리, 수동 테스트
3Structured체계적 테스트, 평가 파이프라인, 기본 가드레일
4Managed자동화된 CI/CD, 카나리 배포, 실시간 모니터링
5Optimized피드백 루프 기반 자동 개선, 멀티에이전트 오케스트레이션
maturity_assessment.py
python
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
Tip

대부분의 팀은 레벨 2-3에 있습니다. 레벨 3에 도달하는 것만으로도 프로덕션 AI 시스템의 안정성이 크게 향상됩니다. 레벨 1에서 바로 레벨 5를 목표로 하기보다는, 한 단계씩 착실히 올라가는 것을 권장합니다.

CI/CD 파이프라인에 하네스 통합

AI 시스템의 CI/CD는 코드 검증에 더해 모델 평가와 안전성 검증을 포함해야 합니다.

.github/workflows/ai-system-ci.yml
yaml
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-rollback
Warning

CI/CD에서 실제 모델 API를 호출하는 테스트는 비용이 발생합니다. 골든 데이터셋의 크기를 적절히 관리하고, PR마다 전체 데이터셋을 실행하기보다 변경된 영역과 관련된 서브셋만 실행하는 전략이 실용적입니다.

CLAUDE.md와 AGENTS.md 설계

Anthropic이 제안한 CLAUDE.md와 AGENTS.md는 AI 에이전트의 하네스 설정을 코드 저장소에 포함시키는 표준입니다. 프로젝트의 맥락, 규칙, 제약사항을 AI가 직접 읽을 수 있는 형식으로 기술합니다.

CLAUDE.md의 구조

CLAUDE.md
markdown
# 프로젝트 개요
 
이 프로젝트는 [설명]입니다.
 
## 기술 스택
 
- 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의 구조

AGENTS.md는 CLAUDE.md보다 더 구체적으로, 에이전트의 행동 규칙과 도구 사용 가이드를 기술합니다.

AGENTS.md
markdown
# 에이전트 행동 규칙
 
## 허용된 행동
 
- 파일 읽기 및 분석
- 코드 리뷰 및 제안
- 테스트 코드 작성
- 문서 업데이트
 
## 금지된 행동
 
- 프로덕션 데이터베이스 직접 접근
- 환경 변수 파일(.env) 수정
- main 브랜치에 직접 푸시
- 사용자 확인 없이 파일 삭제
 
## 도구 사용 가이드
 
### 파일 수정 시
1. 반드시 기존 파일을 먼저 읽을 것
2. 변경 범위를 최소화할 것
3. 변경 후 관련 테스트를 실행할 것
 
### 코드 실행 시
1. 샌드박스 환경에서만 실행
2. 네트워크 접근이 필요한 코드는 사전 확인
3. 실행 시간 제한: 60초
 
## 에스컬레이션
 
다음 상황에서는 사용자에게 확인을 요청하세요:
- 10개 이상의 파일 수정
- 의존성 패키지 추가/삭제
- 보안 관련 코드 변경
- 성능에 영향을 줄 수 있는 변경
Info

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               # 배포 파이프라인
Tip

이 구조를 처음부터 모두 갖출 필요는 없습니다. 성숙도 모델 레벨 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 시스템을 한 단계 더 견고하게 만드는 데 도움이 되었기를 바랍니다.

핵심 요약

  • 통합 아키텍처: 하네스의 각 계층이 독립적이면서도 공통 인프라를 공유하는 구조를 설계합니다.
  • 성숙도 모델: 5단계(Ad-hoc - Basic - Structured - Managed - Optimized)로 현재 수준을 평가하고 개선합니다.
  • CI/CD 통합: 린트, 단위 테스트, 평가 게이트, 안전성 검사, 카나리 배포를 자동화합니다.
  • CLAUDE.md/AGENTS.md: 프로젝트 규칙과 에이전트 행동 규칙을 코드와 함께 버전 관리합니다.
  • 팀 협업: 백엔드, ML, 보안, DevOps가 각자의 전문 영역에서 하네스를 담당합니다.
  • 점진적 도입: 처음부터 모든 것을 갖추려 하지 말고, 성숙도 레벨을 단계적으로 올려갑니다.

이 글이 도움이 되셨나요?

관련 주제 더 보기

#ai#testing#evaluation#mlops

관련 글

AI / ML

9장: 모니터링 하네스 — 프로덕션 관측과 피드백 루프

토큰 사용량, 지연시간, 비용 추적, 드리프트 감지, 품질 모니터링, 알림 설계, 피드백 루프 등 AI 시스템의 관측 가능성 파이프라인을 다룹니다.

2026년 3월 25일·19분
AI / ML

8장: 배포 하네스 — 안전한 모델 릴리즈

카나리 배포, 섀도우 테스팅, A/B 테스트, 블루-그린 배포, 롤백 전략 등 AI 시스템을 프로덕션에 안전하게 배포하는 전략을 다룹니다.

2026년 3월 23일·17분
AI / ML

7장: 오케스트레이션 하네스 — 워크플로우 제어

에이전트 라이프사이클 관리, 도구 오케스트레이션, 서브에이전트 관리, 상태 관리, 에러 복구 등 복잡한 AI 워크플로우를 조율하는 방법을 다룹니다.

2026년 3월 21일·16분
이전 글9장: 모니터링 하네스 — 프로덕션 관측과 피드백 루프

댓글

목차

약 22분 남음
  • 이 장에서 다루는 내용
  • 전체 하네스 계층 통합
    • 통합의 핵심 원칙
  • 하네스 성숙도 모델
    • 5단계 성숙도 모델
  • CI/CD 파이프라인에 하네스 통합
  • CLAUDE.md와 AGENTS.md 설계
    • CLAUDE.md의 구조
    • AGENTS.md의 구조
  • 팀 협업 전략
    • 역할 분담
    • 프롬프트 리뷰 프로세스
  • 실전 프로젝트 아키텍처
  • 시리즈를 마치며
    • 시리즈 전체 요약
  • 핵심 요약