AI 평가가 새로운 계산 제약이 되고 있다

AI 평가(evals)가 새로운 컴퓨팅 병목이 되고 있다는 주장은, 모델 학습·추론에 필요한 GPU 자원이 아니라 "모델이 실제로 잘 동작하는지 검증하는 단계"가 개발 속도를 제약하기 시작했다는 의미다. LLM 기반 시스템은 결정론적 단위 테스트로 검증하기 어렵기 때문에, 골든 데이터셋에 대한 정답 비교, LLM-as-a-judge(다른 모델이 출력 품질을 채점), 휴먼 라벨러 평가, 시뮬레이션된 멀티턴 대화 등 여러 평가 파이프라인을 조합해야 한다. 문제는 이 평가 자체가 매번 수백~수천 건의 LLM 호출을 발생시키고, 프롬프트·모델·툴 정의를 조금만 바꿔도 회귀 테스트를 다시 돌려야 한다는 점이다. 결과적으로 평가 1회당 수십 분에서 수 시간이 걸리고, API 토큰 비용과 휴먼 라벨링 비용이 학습 비용을 빠르게 추월하는 사례가 늘고 있다.

실무 엔지니어 입장에서 가장 큰 변화는 "CI에서 단위 테스트가 5분 안에 끝나던" 개발 사이클이 깨지는 것이다. RAG 파이프라인, 에이전트, 함수 호출 워크플로우를 손볼 때마다 평가 셋 전체를 돌리지 않으면 실제 품질 변화 방향을 알 수 없고, 그렇다고 매 PR마다 풀 평가를 돌리면 머지 큐가 막힌다. 또한 LLM-as-a-judge는 채점 모델이 업데이트될 때마다 점수 분포가 흔들리는 비결정성 문제를 안고 있어, 절대 점수보다 A/B 비교, 페어와이즈 선호도, 통계적 유의성 검증 같은 기법을 추가로 도입해야 한다. 한국에서 LLM 서비스를 운영하는 팀은 한국어 특화 평가셋 부재 때문에 영어 기준 벤치마크가 통과해도 실제 사용자 경험이 나빠지는 이슈를 자주 겪으며, 도메인별·언어별 평가 셋 자체를 사내 자산으로 구축하는 비용이 빠르게 커지고 있다.

대응 차원에서 개발자가 챙겨야 할 핵심은 평가를 "한 번에 다 돌리는 무거운 배치"가 아니라 "계층화된 테스트 피라미드"로 재설계하는 것이다. 즉, PR 단위에서는 수십 건의 빠른 스모크 평가만 돌리고, 머지 전·일일 야간 빌드에서는 수백~수천 건의 회귀 평가, 릴리스 게이트에서만 풀 휴먼 평가를 통과시키는 식의 분리가 표준이 되어가고 있다. 도구 측면에서는 Braintrust, LangSmith, Promptfoo, Inspect AI, OpenAI Evals 같은 평가 전용 플랫폼이 트레이스·실험 비교·캐싱을 제공하므로, 자체 구축보다 우선 검토할 가치가 있다. 비용 절감 관점에서는 평가 호출에 프롬프트 캐싱을 적용하고, 입력이 동일한 회귀 케이스는 결과를 재사용하며, 비싼 모델은 후보군 필터링 후에만 호출하는 캐스케이드 구조를 권장한다.

마지막으로, 평가 데이터셋 자체를 코드처럼 버전 관리하고 데이터 드리프트를 모니터링해야 한다는 점을 강조할 필요가 있다. 프로덕션 로그에서 실패 케이스를 자동 수집해 평가셋에 합류시키는 "evaluation flywheel"을 구축하지 않으면, 시간이 지날수록 평가 통과율은 높지만 실제 사용자 경험은 악화되는 괴리가 발생한다. 또한 평가 파이프라인을 운영 비용·SLO·온콜 대상에 포함시켜야 하며, 평가 인프라를 다루는 "AI QA 엔지니어" 또는 "Eval Engineer" 역할이 신설되는 흐름을 미리 인지하고 사내 R&R을 정비해 두는 것이 좋다. 결국 LLM 시대의 경쟁력은 더 큰 모델을 부르는 능력이 아니라, 더 빠르고 신뢰할 수 있는 평가 루프를 누가 먼저 갖추느냐로 옮겨가고 있다.