LLM 애플리케이션은 표준 프롬프트만으로도 데모에서는 잘 동작하지만, 실제 프로덕션 환경의 복잡한 상황에서는 예상치 못한 실패를 자주 냅니다. 이 간극을 배포 전에 확인하려면 개발 단계에서 평가 체계를 갖춰야 합니다.
앞선 1편에서는 LLM 평가가 무엇이고, 어떤 방법과 지표로 품질을 측정하는지 다뤘습니다. 이번 편은 그 평가를 실제 개발 과정에 어떻게 붙이는가에 관한 내용입니다. 배포 전에 성능을 검증하는 데이터셋을 어떻게 만들고, 변경 사항을 어떻게 실험으로 비교하며, CI/CD 파이프라인에 어떻게 연결하는지를 정리합니다.
이 글은 어라이즈 AI(Arize AI)의 'The definitive guide to LLM evaluation' 중 사전 프로덕션(Pre-Production)과 CI/CD 부분을 바탕으로 합니다.
☑️ 개발 단계 평가란 무엇인가
개발 단계 평가는 애플리케이션을 프로덕션에 배포하기 전에, 선별하거나 생성한 데이터셋으로 성능을 검증하고 변경 사항을 실험으로 비교해 회귀를 걸러내는 과정입니다. 1편에서 다룬 오프라인 평가와 CI/CD 점검이 여기에 해당합니다. 오프라인 평가는 실시간 프로덕션 데이터가 아니라 통제된 환경에서 사전에 준비한 입력으로 모델을 시험합니다. 프롬프트 변경이나 모델 교체가 결과를 개선했는지, 기존에 잘 처리하던 응답을 망가뜨리지 않았는지를 배포 전에 확인하는 것이 목적입니다.
☑️ 골든 데이터셋이 개발 단계 평가의 출발점인 이유
골든 데이터셋은 신중하게 만들어지고 검증된 예시의 모음으로, 모델 성능을 평가할 때 기준이 되는 정답 역할을 합니다. 이 데이터셋은 많은 평가 전략의 토대가 되며, 평가 결과가 신뢰할 수 있고 일관되도록 뒷받침합니다. 데이터셋이 좁거나 지나치게 정제되어 있으면 평가 지표에서는 높은 점수가 나와도 실제 트래픽에서는 성능이 떨어질 수 있습니다. 골든 데이터셋은 애플리케이션이 지원하는 태스크, 자주 들어오는 요청, 어려운 엣지 케이스를 대표해야 합니다.
손수 만든 데이터셋
가장 기본적인 형태는 주제 전문가나 데이터셋 설계자가 직접 예시를 만드는 방식입니다. 모델이 처리해야 할 다양한 입력과 그에 대한 올바른 출력을 손으로 작성합니다. 이 방식의 강점은 특정 활용 사례나 엣지 케이스에 맞춘, 미묘하고 까다로운 예시를 만들 수 있다는 점입니다.
Ground Truth 주석
손수 만든 데이터셋에 사람이 정답을 부여하는 단계입니다. Ground Truth는 평가의 기준이 되는 올바른 답이나 라벨을 의미합니다. 예를 들어 어노테이터가 언어 모델의 출력을 기대 동작과 일치하는지에 따라 정답 또는 오답으로 라벨링하면, 이 값이 이후 모델 성능을 비교하는 기준점이 됩니다.
다중 어노테이터 검증
Ground Truth의 품질과 신뢰성을 확보하려면 여러 어노테이터가 각 예시를 독립적으로 라벨링해 검증합니다. 흔한 방식은 세 명 중 두 명 이상이 같은 라벨에 동의하면 그 라벨을 확정된 Ground Truth로 삼는 것입니다. 이러한 다중 어노테이터 전략은 개인의 편향이나 오류를 줄이고, 어노테이터 간 일치도(inter-annotator agreement)를 확인해 데이터셋의 신뢰성을 높입니다.
휴먼 어노테이션은 트레이스나 스팬에 커스텀 라벨을 붙이는 방식으로도 활용됩니다. 프로덕션 응답에 직접 주석을 달아 필터링과 분석에 쓰거나, 대화의 특정 부분에 범주를 부여해 모델이 어디서 성공하고 실패하는지 세밀하게 분석할 수 있습니다. 또한 휴먼 라벨 데이터는 CI/CD 테스트, few-shot 프롬프팅, 표적 평가를 위한 고품질 데이터셋으로 쓰입니다.
☑️ 합성 데이터셋 구축과 검증
합성 데이터셋은 실제 정보를 모방하도록 인위적으로 생성한 데이터셋입니다. 알고리즘이나 규칙으로 생성되며, 개발자와 연구자가 시험하려는 특정 패턴이나 시나리오를 표현하도록 만들어집니다. 고객 지원 대화, 질의응답 쌍, 다양한 어조의 제품 리뷰, 의도적 버그가 포함된 코드 조각 등이 예입니다.
합성 데이터는 통제된 실험 환경을 만들고, 엣지 케이스를 폭넓게 확보하며, 실제 사용자 데이터를 쓰지 않아 프라이버시를 보호할 수 있습니다. 특히 아직 출시하지 않은 애플리케이션을 개발하고 실험할 때, 일관된 실험 결과를 위한 골든 데이터로 활용됩니다.
합성 데이터셋 활용 시 주의점
합성 데이터셋은 한 번 만들고 끝나는 것이 아니라 지속적으로 관리해야 합니다. 정기적인 갱신 주기를 두어 모델 개선과 데이터 드리프트를 반영하고, 생성에 사용한 프롬프트·모델·후처리 과정을 기록해 투명성을 유지하며, 실제 데이터 및 최신 모델과 비교해 성능을 주기적으로 평가하는 것이 권장됩니다.
합성 데이터만으로는 사람이 자연스럽게 고려할 핵심 사례나 입력 유형을 놓칠 수 있습니다. 소수의 휴먼 라벨 예시를 포함하는 것만으로도 합성 데이터셋의 품질과 효과가 크게 향상될 수 있으며, 이는 모델이 적은 예시로 일반화해야 하는 few-shot 학습 상황에서 특히 효과적입니다. 다만 사람이 만든 예시를 추가할 때는 합성 데이터의 비중을 압도하지 않도록 균형을 맞추는 것이 좋습니다.
☑️ 평가 모델을 선택하는 기준
평가에 사용할 모델은 반복 빈도, 비용 대비 정확도, 유연성 요건에 따라 달라집니다. 많은 팀은 애플리케이션에 쓰는 것과 같은 기본 모델로 평가를 시작해 기준선을 잡습니다. 이후 비용을 낮추기 위해 소형 언어 모델(SLM)로 옮겨가는데, 소형 모델은 비용이 크게 낮고 가드레일 용도에 빠릅니다. 더 나아가 특정 평가에 특화된 파인튜닝 모델을 쓸 수도 있습니다. 선택의 핵심은 평가를 자주 반복한다는 전제 아래 비용과 정확도의 균형을 맞추는 것입니다.
☑️ CI/CD 실험으로 변경을 검증하는 방법
실험(experiment)은 선별한 데이터셋으로 LLM 애플리케이션의 변경을 체계적으로 시험하고 검증하는 절차입니다. 데이터셋을 정의하고, 출력을 생성하는 태스크를 만들고, 그 출력을 평가하는 평가자를 설정해 실행하면, 변경된 파이프라인이 얼마나 잘 동작하는지 측정할 수 있습니다. 실험은 세 가지로 구성됩니다.
- 데이터셋: 애플리케이션을 평가하기 위한 입력과, 선택적으로 기대 출력을 제공하는 예시 모음입니다. 프롬프트, 모델, 그 밖의 구성요소 변경에 따른 개선을 추적하는 데 쓰입니다.
- 태스크: JSON으로 직렬화 가능한 출력을 만드는 함수나 프로세스입니다. 시험하려는 LLM 기능을 재현하며, 예를 들어 프롬프트를 바꿨다면 새 프롬프트로 예시를 실행해 출력을 생성합니다.
- 평가자: 태스크의 출력을 받아 평가를 수행하는 함수입니다. 실험의 성공 여부를 판단하는 기준이 되며, LLM 기반 평가자부터 코드 기반 평가까지 여러 개를 정의할 수 있습니다.
실험은 프롬프트나 모델 변경뿐 아니라 애플리케이션이 조율되는 방식의 변경, 즉 새로운 통합, API 상호작용, 외부 함수 호출 같은 오케스트레이션 변경도 시험할 수 있습니다. 이를 통해 응답 시간이 개선되는지, 오류가 줄어드는지, 전체 사용자 경험이 나아지는지를 확인합니다.
평가 데이터셋을 만드는 방법
평가 데이터셋은 여러 경로로 만들 수 있습니다. 가장 권장되는 출발점은 수동 큐레이션으로, 애플리케이션이 처리해야 할 입력과 좋은 응답의 형태를 직접 정리하는 방식입니다. 고품질 예시는 20개 정도만으로도 큰 도움이 됩니다. 애플리케이션을 출시한 뒤에는 과거 로그가 유용한 자원이 됩니다. 사용자가 실제로 어떻게 쓰는지를 담고 있어, 부정적 피드백을 받은 지점이나 완료까지 오래 걸린 실행처럼 성능이 좋지 않았던 사례를 골라 데이터셋에 추가하면 이후 회귀를 시험할 수 있습니다. 예시가 어느 정도 모이면 합성 데이터로 빠르게 양을 늘릴 수 있는데, 합성 데이터는 원본 예시를 닮는 경향이 있으므로 먼저 좋은 수작업 예시를 몇 개 확보한 뒤 진행하는 것이 좋습니다.
☑️ 실험 결과는 흑백으로 나뉘지 않습니다
실험 결과를 해석할 때는 여러 결과가 섞여 나온다는 점을 이해해야 합니다. 어떤 평가는 개선되고 어떤 평가는 그렇지 않을 수 있습니다. 예를 들어 프롬프트 구조를 바꾸면 일관성 점수는 올라가지만 사실 정확성은 조금 낮아질 수 있습니다.
많은 팀은 검증용 예시를 손수 선별한 뒤, 평균 점수·F1·재현율·정밀도 같은 지표를 평가 결과 위에 얹어 성능을 판단합니다. 통계적 점검을 활용하는 것은 아직 보편적이지 않지만, 좋은 관행으로 점차 자리 잡고 있습니다. 중요한 것은 트레이드오프를 따져 애플리케이션의 목표에 맞는 개선을 우선하는 것입니다.
☑️ CI/CD 자동화와 변경 승격
CI/CD 파이프라인을 구성하면 애플리케이션이 진화하는 동안에도 통제력을 유지할 수 있습니다. 전통적인 소프트웨어와 마찬가지로 자동화된 테스트로 문제를 조기에 잡는 것이 중요합니다. 큐레이션된 데이터셋과 선호하는 평가 방법으로 변경을 자동 검증하는 실험을 만들고, 이를 GitHub Actions와 연동하면 코드를 푸시할 때마다 자동으로 테스트가 실행됩니다.
CI/CD 파이프라인에서 실행할 실험은 프로덕션을 최대한 가깝게 재현하는 것을 목표로 합니다. Ground Truth 평가는 무엇을 시험하든 항상 실행해야 하며, 여기서 실패하면 근본적으로 무언가 잘못된 것이므로 변경을 승격해서는 안 됩니다. 임계값 기반 실험은 할루시네이션이나 정확성 같은 지표가 정해진 기준을 넘는지 감지합니다. 예를 들어 할루시네이션 비율이 기준선 대비 크게 치솟으면 승격 전에 확인이 필요한 신호일 수 있습니다.
평가 실패로 PR을 막을지는 전통적인 단위 테스트와 비슷하게 다룹니다. Ground Truth 비교의 심각한 실패나 큰 지표 급등은 PR을 막아야 하지만, 모든 평가 실패가 PR을 막을 필요는 없으며 일부는 배포 이후 모니터링에 더 적합합니다. 이것이 곧 패러다임의 전환입니다. LLM 평가는 새로운 단위 테스트이며, 팀이 모든 실패에 대해 변경을 막지는 않더라도 이 평가들은 애플리케이션의 중대한 문제를 잡아내는 실제 테스트입니다.
한 가지 더 중요한 전환이 있습니다. LLM 애플리케이션은 코드 변경뿐 아니라 모델 업데이트나 프로덕션 입력의 드리프트에도 영향을 받습니다. 따라서 관련된 풀 리퀘스트나 활발한 개발 변경이 없을 때에도, 성능 변화를 감지하기 위해 실험을 정기적으로 실행할 필요가 있습니다.
☑️ 개발 단계 평가를 실제로 구현하려면
지금까지 살펴본 데이터셋 구축, 실험, CI/CD 연결은 방법론입니다. 이 방법론을 실제 개발 워크플로우에서 운영하려면 데이터셋 관리와 실험 실행, 파이프라인 연동을 하나로 묶는 도구가 필요합니다.
Arize AX는 이러한 개발 단계 평가를 지원하는 AI 옵저버빌리티·평가 플랫폼입니다. 프로덕션·스테이징·평가 과정에서 수집한 데이터로 데이터셋을 구성하고, 프롬프트·모델·오케스트레이션 변경을 실험으로 비교하며, 큐레이션된 데이터셋과 선호하는 평가 방법으로 변경을 자동 검증하는 실험을 만들 수 있습니다. 이 실험은 GitHub Actions와 연동되어 코드를 푸시할 때 자동으로 실행되므로, 수동 테스트 없이 변경의 안정성을 배포 전에 확인할 수 있습니다.
▶ Arize AX 자세히보기
☑️ 자주 묻는 질문
골든 데이터셋이란 무엇인가요?
골든 데이터셋은 신중하게 만들어지고 검증된 예시 모음으로, 모델 성능을 평가할 때 기준이 되는 정답 역할을 합니다. 손수 만든 예시, Ground Truth 주석, 다중 어노테이터 검증을 결합해 신뢰성과 다양성을 확보합니다.
합성 데이터셋은 어떻게 검증하나요?
합성 데이터셋은 정기적인 갱신 주기를 두고, 생성 과정을 기록해 투명성을 유지하며, 실제 데이터 및 최신 모델과 비교해 주기적으로 성능을 평가합니다. 소수의 휴먼 라벨 예시를 더하면 품질과 일반화 성능을 높일 수 있습니다.
실험(experiment)은 무엇으로 구성되나요?
실험은 데이터셋, 태스크, 평가자 세 가지로 구성됩니다. 데이터셋은 입력과 기대 출력을 제공하고, 태스크는 시험하려는 기능을 재현해 출력을 만들며, 평가자는 그 출력을 채점해 성공 여부를 판단합니다.
평가에 실패하면 항상 배포를 막아야 하나요?
그렇지 않습니다. Ground Truth 비교의 심각한 실패나 큰 지표 급등은 PR을 막는 것이 맞지만, 일부 평가 실패는 배포 이후 모니터링에 더 적합합니다. 불필요한 병목을 피하면서 중대한 문제만 걸러내는 균형이 중요합니다.
☑️ 마무리
개발 단계 평가는 배포 전에 품질을 검증하는 안전장치입니다. 골든 데이터셋과 합성 데이터셋으로 평가의 기준을 세우고, 실험으로 변경을 비교하며, CI/CD에 연결해 회귀를 조기에 잡는 것이 핵심입니다. 이번 편에서는 데이터셋 구축, 실험 구성, 결과 해석, CI/CD 자동화와 변경 승격을 살펴봤습니다. 다음 편에서는 배포 이후의 평가, 즉 프로덕션 가드레일과 자기 개선, 그리고 거버넌스를 다룹니다.
클라우드네트웍스는 Arize AI의 한국 공식 파트너로서, AI 옵저버빌리티·평가 플랫폼인 Arize AX의 도입과 구축을 지원합니다. LLM 애플리케이션의 개발 단계 평가 체계를 마련하는 데 관심이 있으시다면, 클라우드네트웍스로 문의해 주시기 바랍니다.
[출처 : Arize AI, "Pre Production LLM Evaluation", https://arize.com/llm-evaluation/pre-production-llm-evaluation/ , Arize AI, "CI/CD for LLM Apps", https://arize.com/llm-evaluation/ci-cd-for-llm-apps/ ]
