왜 AI 시스템에 평가 CI가 필요한가

코드 CI는 기능적 회귀 (functional regression)를 방지합니다: 누군가 A를 변경했을 때 B가 망가진다면, CI가 이를 즉시 포착합니다.

AI 시스템도 동일한 보호가 필요합니다. 세 가지 유형의 변경 사항은 눈에 보이는 오류를 발생시키지 않으면서 조용히 품질을 저하시킬 수 있습니다:

프롬프트 (Prompt) 변경:
  토큰 비용을 줄이기 위해 시스템 프롬프트를 수정함
  → 답변 관련성 (Answer Relevancy)이 15% 하락할 수 있음
...

2단계 전략

1단계: 빠른 평가 (Fast Evaluation, 매 커밋 시 수행)

목표: 빠른 속도 (< 3분), 명백한 품질 회귀 포착, 전체 커버리지 지향 아님.

설계 원칙:

• 10-20개의 "골든 케이스 (golden cases)" — 가장 중요하고 가장 대표적인 질문들
• 시나리오 카테고리당 최소 1-2개의 케이스
• 과거에 실패했던 경험이 있는 엣지 케이스 (edge cases) 우선순위 지정

# fast_eval_cases.yaml
FAST_EVAL_CASES = [
    {"id": "FE01", "scenario": "factual",    "question": "환불 정책이 무엇인가요?", ...},
...

CI 설정:

# .github/workflows/fast_eval.yml
name: Fast Quality Gate
on:
...

2단계: 전체 평가 (Full Evaluation, 스케줄링 또는 대규모 변경 시 수행)

목표: 전체 커버리지 (100개 이상의 케이스), 트렌드 추적, 릴리스 결정 지원.

# .github/workflows/full_eval.yml
name: Full Quality Evaluation
on:
...

품질 게이트 (Quality Gate) 설계

차단(Block)하는 것 vs 경고(Alert)만 하는 것

모든 지표 하락이 PR을 차단해야 하는 것은 아닙니다. CI가 너무 자주 실패하면 팀은 게이트를 우회하기 시작합니다.

# eval_gates.yaml
gates:
  # PR 차단 (critical gates)
...

델타 게이트 (Delta gates)는 절대적 게이트 (absolute gates)보다 더 민감합니다:

def check_gates(current: dict, baseline: dict, gates: list) -> list[str]:
    failures = []
    for gate in gates:
...

델타 리포트 (Delta Reports): 리뷰어에게 점수뿐만 아니라 변화를 보여주기

PR 평가 코멘트는 단순히 "충실도 (Faithfulness): 0.82"라고만 말해서는 안 됩니다. 그 숫자를 보는 리뷰어는 맥락을 알 수 없습니다 — 지난번보다 높았나요? 낮았나요? 이번 변경이 상황을 개선했나요, 아니면 악화시켰나요?

좋은 PR 평가 코멘트 형식:

## AI 품질 평가 리포트 (AI Quality Evaluation Report)

시간: 2026-07-16 14:23  |  케이스 수: 10  |  소요 시간: 2.1분
...

Baseline Management (베이스라인 관리)

베이스라인 (Baseline)은 "마지막으로 확인된 양호한 상태"입니다. 베이스라인 관리가 부실하면 품질 게이트 (Quality Gates)는 무용지물이 됩니다.

베이스라인 업데이트 규칙:

class BaselineManager:
    def should_update_baseline(self, current: dict, previous: dict) -> bool:
        # 규칙 1: 현재 결과가 유의미하게 개선됨 (모든 지표에서 평균 +0.02 이상)
...

피해야 할 행동:

• 실패하는 CI를 통과시키기 위해 베이스라인을 업데이트하는 것 ("임계값 (threshold)이 너무 엄격하네, 좀 낮춰야겠다")
• 코드 버전 태그 (code version tag)와 연결하지 않고 베이스라인을 저장하는 것 (롤백 (rollback)을 불가능하게 만듦)

Full Evaluation Engineering Architecture (전체 평가 엔지니어링 아키텍처)

Code / Prompt / Knowledge Base Change (코드 / 프롬프트 / 지식 베이스 변경)
          ↓
Fast Eval (10 cases, < 3 min) (빠른 평가 (10개 케이스, 3분 미만))
...

Summary (요약)

1. 두 단계의 계층 구조가 속도와 커버리지 사이의 트레이드오프 (tradeoff) 문제를 해결합니다: 빠른 평가 (Fast evaluation, 10개 케이스, 3분)는 모든 커밋 (commit) 시 실행되며, 전체 평가 (Full evaluation, 100개 이상의 케이스)는 매주 실행됩니다. 서로 다른 트리거 (trigger)와 목적을 가집니다.
2. 델타 게이트 (Delta gates)는 절대적 게이트 (absolute gates)보다 더 민감합니다: 현재 점수가 0.82라는 정보는 유용하지 않지만, 이번 변경으로 인해 0.08의 하락이 발생했다는 정보는 즉각적인 조치를 가능하게 합니다.
3. PR 코멘트는 단순히 점수만 보여주는 것이 아니라 변화를 보여주어야 합니다: "도구 정확도 (Tool Correctness)가 0.13 하락함"은 조치 사항을 지시하지만, "도구 정확도 (Tool Correctness): 0.60"은 그렇지 않습니다.

실제 기업급 워크플로우에서 검증된 AI 에이전트와 기술의 큐레이션 마켓플레이스인 PrimeSkills를 확인해 보세요. 불필요한 내용은 빼고, 실제로 작동하는 것들만 제공합니다.

저의 Homepage에서 더 유용한 지식과 흥미로운 제품들을 찾아보세요.