[AI] CI/CD 파이프라인에 AI 모델 평가 자동화 단계 추가하기

CI/CD 파이프라인에 AI 모델 평가 자동화 단계를 넣는다는 것은, 빌드가 성공했는지만 보는 단계에서 한 걸음 더 나아가 응답 품질까지 배포 기준에 포함시키는 일입니다. 코드 테스트와 달리 AI 결과물은 비결정적이라서, 사람이 눈으로 몇 번 확인하는 방식만으로는 회귀를 잡기 어렵습니다. 최근에는 OpenAI Evals, LangSmith, Weave 같은 도구도 모두 평가를 개발 단계와 배포 전 단계에 연결하는 흐름을 강조하고 있습니다. 

CI/CD 파이프라인에 AI 모델 평가 자동화 단계가 왜 필요한가

CI/CD라고 하면 보통 빌드, 단위 테스트, 정적 분석, 배포 정도를 먼저 떠올립니다. 그런데 AI 기능이 들어오면 이야기가 조금 달라집니다. 문법 오류가 없고 API 호출도 정상인데, 응답 품질이 이전보다 나빠지는 경우가 생기기 때문입니다.

이럴 때 필요한 것이 평가 자동화 단계입니다. 쉽게 말하면 “이번 변경이 정말 더 나아졌는가”를 데이터셋 기반으로 확인하는 절차입니다. OpenAI 문서도 evals를 모델 출력이 기대한 스타일과 내용 기준을 만족하는지 점검하는 구조화된 테스트로 설명하고 있고, LangSmith 역시 개발 단계에서 데이터셋 기반으로 버전 비교와 회귀 탐지를 하는 흐름을 제시합니다. 

 

어떤 평가를 자동화할지 먼저 구분해야 합니다

실무에서는 AI 평가를 한 덩어리로 보면 금방 복잡해집니다. 먼저 어떤 종류의 평가를 파이프라인에 넣을지 나누는 편이 좋습니다. 이 구분이 선행되어야 배포 차단 기준도 명확해집니다.

1. 정답 비교가 가능한 평가

분류, 라벨링, 구조화된 JSON 생성처럼 기대 결과가 비교적 명확한 작업입니다. 이 경우 정확도, 정밀도, 재현율, 포맷 일치 여부 같은 기준으로 자동화하기 좋습니다. CI 단계에 가장 먼저 넣기 쉬운 유형도 보통 여깁니다.

2. 기준 응답 대비 품질 평가

챗봇, 요약, 검색 응답 생성처럼 정답이 하나로 고정되지 않는 작업입니다. 이 경우에는 정답 문자열 완전 일치보다 사실성, 누락, 금지 응답 여부, 형식 준수 여부를 보는 편이 낫습니다. LangSmith는 이런 평가를 오프라인 평가와 온라인 평가로 나누고, 다양한 evaluator 방식을 함께 설명합니다.

3. LLM-as-a-judge 방식

사람 평가 기준을 완전히 코드화하기 어려울 때 쓰는 방식입니다. 다만 이 방식은 편리하다고 해서 무조건 CI의 차단 조건으로 바로 쓰기보다는, 초반에는 참고 지표로 두는 것이 안전합니다. 평가자 자체도 흔들릴 수 있기 때문입니다.

4. 안전성 및 정책 준수 평가

금지어, 개인정보 노출, 프롬프트 인젝션 대응, 민감한 답변 제한처럼 서비스 정책과 직접 연결되는 항목입니다. 이런 평가는 배포 전 게이트에 두기 좋습니다. 결과가 애매하면 팀 내부 기준이 흔들리기 쉬워서, 처음부터 pass/fail 규칙을 문서화해 두는 편이 낫습니다.

 

CI/CD 파이프라인에서 AI 모델 평가 자동화 단계를 넣는 위치

이 주제에서 자주 헷갈리는 부분이 있습니다. 평가를 무조건 배포 직전에 한 번만 돌리면 된다고 생각하기 쉽지만, 실제로는 단계별로 나누는 편이 훨씬 운영하기 쉽습니다.

1. Pull Request
   - 프롬프트/평가셋/모델 설정 변경 감지
   - 빠른 샘플 평가 실행
   - 기준 미달 시 머지 차단

2. Main 브랜치 병합 후
   - 전체 회귀 평가 실행
   - 이전 기준선과 비교
   - 리포트 저장

3. Staging 배포 전
   - 실제 서비스 설정 기준 통합 평가
   - 정책 위반, 포맷 오류, 주요 시나리오 재검증

4. 운영 반영 후
   - 온라인 샘플링 평가
   - 사용자 로그 기반 재평가
   - 평가셋 보강

GitHub Actions 문서 기준으로도 워크플로는 이벤트에 따라 여러 job을 정의하고, job 간 선행 관계를 구성할 수 있습니다. 그래서 build, test, eval, deploy를 순서대로 분리하는 구조가 자연스럽습니다.

 

실무에서 추천하는 최소 구조

처음부터 거대한 평가 체계를 만들 필요는 없습니다. 오히려 그렇게 시작하면 데이터셋 관리와 결과 해석이 더 어려워집니다. 처음에는 작고 선명한 기준으로 출발하는 편이 좋습니다.

평가셋

20개에서 50개 정도의 대표 시나리오부터 시작하면 충분합니다. 사용자 질문 유형, 실패가 치명적인 케이스, 자주 회귀하는 케이스를 우선 담습니다. 이 데이터셋은 코드와 같이 버전 관리하는 편이 좋습니다.

평가 기준

처음에는 2~4개 정도만 두는 것이 좋습니다. 예를 들면 정답 포함 여부, JSON 포맷 유효성, 금지 응답 여부, 근거 포함 여부 정도입니다. 기준이 너무 많으면 결과가 좋아졌는지 나빠졌는지 판단하기 어려워집니다.

기준선

현재 운영 중인 프롬프트나 모델 조합을 기준선으로 저장해 두어야 합니다. 그래야 새로운 변경이 절대 점수만 높은지 보는 것이 아니라, 기존보다 실제로 좋아졌는지를 비교할 수 있습니다.

차단 규칙

모든 지표가 좋아야만 배포하는 방식은 잘 굴러가지 않습니다. 실무에서는 “정책 위반 0건”, “포맷 성공률 100%”, “핵심 시나리오 정확도 기준선 이상”처럼 차단 조건을 소수로 두는 편이 유지하기 쉽습니다.

 

GitHub Actions 기준으로 보면 어떻게 연결할 수 있는가

CI/CD 파이프라인에 AI 모델 평가 자동화 단계를 추가할 때 가장 흔한 출발점은 GitHub Actions입니다. 워크플로 파일 안에서 일반 테스트 job 다음에 eval job을 두고, eval 결과가 기준을 넘지 못하면 배포 job이 실행되지 않도록 구성하면 됩니다. GitHub Actions는 workflow YAML로 job과 dependency를 정의하는 구조이기 때문에 이 흐름을 만들기 어렵지 않습니다. 

name: ai-eval-pipeline

on:
  pull_request:
    paths:
      - "prompts/**"
      - "evals/**"
      - "src/**"
  push:
    branches: [ main ]

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Unit test
        run: npm test

  ai-eval:
    needs: build-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Run evals
        run: npm run eval:ci

  deploy:
    needs: ai-eval
    runs-on: ubuntu-latest
    steps:
      - name: Deploy
        run: ./deploy.sh

위 예시는 구조를 보여주기 위한 최소 형태입니다. 실제로는 여기서 secrets 주입, 기준선 비교, 결과 아티팩트 업로드, 실패 리포트 생성까지 붙게 됩니다. 중요한 것은 eval을 별도 job으로 분리해 결과 해석과 실패 원인을 명확히 하는 것입니다.

 

도구는 무엇을 기준으로 고르면 좋은가

도구 선택은 팀이 이미 쓰는 개발 흐름과 얼마나 잘 붙는지가 중요합니다. 기능 수가 많다고 항상 좋은 것은 아닙니다. 평가셋 관리, 실행 편의성, 결과 비교, CI 연동, 추적성 정도를 기준으로 보면 판단이 쉬워집니다.

OpenAI Evals

평가라는 개념 자체를 빠르게 붙여보기 좋습니다. OpenAI 공식 문서도 evals를 모델 변경이나 프롬프트 변경 시 성능을 확인하는 핵심 절차로 설명합니다. 내부적으로 어떤 항목을 테스트할지 정리하는 데 도움이 됩니다.

LangSmith

애플리케이션 단위에서 평가와 추적을 함께 보려는 팀에 잘 맞습니다. 데이터셋, target function, evaluator 개념이 비교적 분명해서, “이번 체인이 왜 점수가 떨어졌는가”를 따라가기 편합니다. 공식 문서도 오프라인 평가와 운영 중 모니터링을 함께 다룹니다. 

W&B Weave

평가 실행과 실험 추적을 함께 보려는 경우에 잘 맞습니다. Weave 문서에서도 Evaluation 객체를 데이터셋과 스코어 함수의 조합으로 설명하고 있고, 애플리케이션 테스트와 추적을 같이 가져가는 흐름을 안내합니다.

팀에 이미 Python 실험 환경이 있고 데이터셋 중심으로 비교를 많이 한다면 이런 도구들이 편합니다. 반대로 초기 단계라면 꼭 특정 플랫폼부터 도입하기보다, 사내 스크립트와 간단한 점수 계산부터 시작해도 충분합니다.

 

처음 적용할 때 자주 틀리는 부분

실무에서는 평가 자동화보다 평가 기준 정의에서 더 많이 막힙니다. 파이프라인 연결 자체는 어렵지 않은데, 무엇을 통과로 볼지 합의되지 않으면 금방 유명무실해집니다.

샘플이 너무 적거나 너무 편향된 경우

잘 나온 예시 몇 개만 모아두면 배포 전에는 늘 통과하는데 운영에서는 금방 어긋납니다. 대표 실패 케이스를 일부러 넣어두는 편이 더 도움이 됩니다.

모든 점수를 하나로 합치려는 경우

정확도, 형식 준수, 안전성, 사용자 만족 신호는 성격이 다릅니다. 이것을 한 점수로만 압축하면 왜 실패했는지 읽기 어려워집니다. 그래서 CI에서는 보통 치명 조건과 참고 지표를 나눠 두는 편이 낫습니다.

비결정성을 고려하지 않는 경우

같은 입력이라도 출력이 달라질 수 있습니다. 그래서 한 번의 실행 결과만 보고 통과 여부를 확정하면 흔들릴 수 있습니다. 핵심 시나리오는 반복 실행하거나, 온도와 출력 포맷을 통제해 비교 가능성을 높여야 합니다.

프롬프트와 평가셋 버전이 분리된 경우

이 부분은 협업할 때 특히 헷갈립니다. 프롬프트만 바뀌고 평가셋은 그대로이거나, 반대로 평가 기준만 바뀌는 경우가 생기면 결과 해석이 모호해집니다. 둘 다 함께 버전 관리하고 변경 이유를 남겨 두어야 합니다.

 

팀 협업 관점에서 보면 어떤 식으로 운영하는 것이 좋은가

AI 모델 평가는 한 명이 감으로 판단하는 구조보다, 팀이 공유 가능한 기준으로 바꾸는 것이 중요합니다. 그래서 PR 리뷰 때도 “좋아 보입니다”보다 “핵심 시나리오 30개 중 정책 위반 0건, 구조화 응답 성공률 유지”처럼 읽을 수 있어야 합니다.

이 관점에서 보면 평가 자동화 단계는 단순한 품질 검사보다 커뮤니케이션 도구에 가깝습니다. 프롬프트 엔지니어, 백엔드 개발자, QA, 운영 담당자가 같은 기준표를 보게 해 주기 때문입니다.

예시 운영 원칙

- prompts/ : 프롬프트 버전 관리
- evals/datasets/ : 평가 입력셋
- evals/rubrics/ : 평가 기준 정의
- evals/baseline/ : 기준선 결과 저장
- .github/workflows/ai-eval.yml : CI 평가 파이프라인

이 정도만 정리해도 변경 이력이 훨씬 읽기 쉬워집니다. 특히 누가 어떤 기준을 바꿨는지 추적할 수 있어야, 평가 실패가 도구 문제인지 실제 품질 저하인지 구분하기 쉬워집니다.

 

CI/CD 파이프라인에 AI 모델 평가 자동화 단계를 넣을 때의 실무 기준

정리하면 이 주제는 설정형이면서 동시에 품질 관리 체계 설계에 가깝습니다. 그래서 도구를 먼저 고르기보다, 어떤 변경을 막고 싶은지부터 정하는 것이 더 중요합니다.

개인적으로는 다음 순서로 가는 편이 가장 깔끔합니다. 첫째, 핵심 시나리오 평가셋을 만든다. 둘째, 치명 조건과 참고 지표를 나눈다. 셋째, PR 단계에서는 빠른 샘플 평가만 돌린다. 넷째, main 병합 후 전체 회귀 평가를 돌린다. 다섯째, 운영 로그를 다시 평가셋에 반영한다.

이렇게 가면 CI/CD 파이프라인에 AI 모델 평가 자동화 단계를 추가하더라도 팀이 감당할 수 있는 복잡도 안에서 시작할 수 있습니다. 처음부터 완벽한 평가 시스템을 만들기보다, 배포를 막아야 하는 실패를 정확히 잡는 구조부터 만드는 편이 훨씬 오래 갑니다.