평가: AI 실험에서 신뢰할 수 있는 프로덕션으로

• 기반 모델도 발전했지만, 안심하고 프로덕션에 활용할 수 있게 한 진정한 변화는 체계적인 평가 관행에서 비롯되었습니다.

• 잘 설계된 평가는 제품 관리자, AI 거버넌스 책임자, CTO가 AI 에이전트를 대규모로 안전하게 배포하고, AI를 고립된 장난감이 아닌 경쟁 우위로 전환하도록 돕습니다.

• 그러한 확신은 ‘이 모델이 최고’라는 공개 벤치마크가 아니라, 실제 비즈니스 맥락을 반영하는 사용자 질의, 엣지 케이스, 도메인별 시나리오를 기준으로 AI 에이전트의 행동을 평가하는 데서 나옵니다.

• 목표는 측정 가능한 결과를 통해 그러한 확신에 근거를 마련하는 것입니다. 성공하려면 사실 정확성, 적절한 어조, 속도, 비용 효율성 등 비즈니스 요구와 위험 허용 수준에 맞춰 "좋음"을 구체적이고 측정 가능한 기준으로 정의해야 합니다.

• 전체 시스템에 평가를 내재화하고(계측, 로깅, A/B 테스트, 가드레일), 엄밀성과 효율성의 균형을 맞추면 팀은 배포 속도와 견고성을 높일 수 있습니다.

대부분의 기업은 직원들이 ChatGPT나 Gemini를 시험 삼아 사용하는 데 익숙합니다. 하지만 위험 부담이 큰 워크플로나 환경에 LLM을 투입하는 경우는 훨씬 드뭅니다.

그 이유는 충분히 타당했습니다. 품질이 일관되지 않았고, 환각이나 바람직하지 않은 행동의 위험이 이 기술의 잠재적 이점보다 컸기 때문입니다.

지난 1년 동안 이러한 위험과 보상의 균형은 크게 달라졌습니다. 일부는 기반 모델의 성능 향상 덕분이지만, 상당 부분은 평가(또는 ‘eval’)가 점차 체계화된 결과입니다. 평가는 저희와 고객이 불과 몇 주 만에 대규모 고객 대면 에이전트를 안심하고 배포할 수 있게 합니다.

이 가이드에서는 평가의 기본 요소와 설계·구현 방법, 프로덕션 사용 사례에서의 운영 방법을 설명합니다.

평가의 목표는 완벽한 모델을 찾는 것이 아니라, 모델의 행동이 비즈니스 요구, 사용자의 기대, 조직의 위험 허용 수준에 부합한다는 근거 있는 확신을 얻는 것입니다.

모든 평가 전략의 출발점에는 간단한 질문이 있습니다. ‘좋음’이란 어떤 모습인가? 답은 구체적이어야 합니다. 어떤 조직에서 ‘좋음’은 엄격한 허용 범위 내의 사실 정확성을 뜻하지만, 다른 조직에서는 속도, 비용 효율성 또는 고유한 어조를 우선할 수 있습니다. 사용 가능한 데이터부터 적용되는 규제 의무까지, 운영상의 모든 제약 조건이 이 정의를 결정합니다.

무엇보다 '좋음'은 실제로 측정할 수 있는 요소로 구성되어야 합니다. 성공이 유용한 금융 안내를 제공하는 것이라면, 유용성은 사실적 정확성, 적절한 면책 고지, 개인화된 추론, 안전한 경계 등의 속성으로 표현되어야 합니다. ‘좋음’을 측정 가능한 기준으로 정의했다면, 다음은 결과를 어떻게 분석하고 해석할지 정해야 합니다. 이 결과를 실제 조치로 이어가야 평가가 단순한 주관적 판단을 넘어 하나의 방법론이 됩니다.

모든 평가 파이프라인은 서로 연결된 세 가지 축을 기반으로 합니다.

1. 입력/벤치마크: 일반 성능을 보여 주는 대표적인 실제 사례와 도메인 적용 가능성을 검증하기 위해 선별한 내부 데이터세트입니다.

2. 모델 행동: 모델을 호출하는 방식입니다(검색 증강 생성, 요약, 구조화된 정보 검색, 도구 사용).

3. 지표: 성능을 측정하고 해석하는 방법입니다.

입력은 시스템이 실제로 마주할 환경을 대표해야 합니다. 가장 의미 있는 인사이트는 고객 질의, 금융 시나리오, 산업별 사례와 같은 실제 예시에서 나옵니다. 이러한 사례를 기준으로 테스트해야만 모델이 사용자에게 필요한 미묘한 차이를 제대로 이해하고 비즈니스 요구를 충족하는지 알 수 있습니다.

프롬프트 구성, 검색이나 도구 사용의 오케스트레이션, 컨텍스트 제공 방식 등 모델의 행동도 모델 자체만큼 중요합니다. 동일한 두 모델도 배포 방식에 따라 매우 다르게 행동할 수 있습니다. 따라서 평가 설계에 이 계층도 포함해야 합니다.

마지막은 지표입니다. 수치만으로 전체 상황을 파악하기는 어렵지만, 적절한 지표를 선택하면 시스템의 행동을 해석할 수 있습니다. 지연 시간, 정확성, 안전성, 일관성, 편향, 비용, 사용자 만족도를 종합하면 프로덕션 시스템을 다차원적으로 파악할 수 있습니다. 핵심은 프로젝트나 비즈니스의 KPI에 부합하면서 사용자에게 가장 중요한 특성을 드러내는 지표를 선택하는 것입니다. 단순한 지표가 더 정확하고 비용도 적게 드는 경우가 많으며, 잘못된 지표 선택은 팀의 판단을 흐릴 수 있습니다. 지표 선택 시 다음 사항을 고려하세요.

좋은 지표 선택의 예:

• 고객 서비스 챗봇: 최초 문의 해결률(상담 이관 없이 사용자 문제가 해결되었는가?), 평균 처리 시간, 사용자 만족도 점수, 상담원 이관률

• 금융 리서치 도구: 인용 정확도(출처가 적절히 제시된 주장의 비율), 정답 데이터로 검증한 사실 정밀도, 검색 관련성(올바른 문서를 찾았는가?), 도메인 전문가가 평가한 추론 일관성

• 코드 생성 어시스턴트: 구문 정확성, 테스트 통과율, 보안 취약점 수, 작동하는 솔루션을 얻기까지 걸린 시간

잘못된 지표 선택의 예:

• 응답 길이만 품질의 대리 지표로 사용하기(길다고 더 좋은 것은 아님)

• 정확성과의 상충 관계를 고려하지 않고 속도만 측정하기

• 모델 신뢰도 점수를 실제 정확성과 대조해 검증하지 않고 추적하기

• 사용자 대상 검증 없이 모델 내부의 퍼플렉시티에만 의존하기

피해야 할 일반적인 지표의 함정:

• 상충하는 지표: 상충 관계를 인정하지 않은 채 속도와 포괄성을 동시에 최적화하는 경우

• 벤치마크 과적합: 테스트 세트에서는 95%를 달성했지만 실제 사용자의 행동 차이로 인해 프로덕션에서는 실패하는 경우

규제가 엄격한 한 금융 서비스 고객에게는 심층 리서치 솔루션의 정확성이 무엇보다 중요했습니다. 저희는 전문가가 만든 QA 데이터세트와 도구로 생성한 데이터세트를 함께 설계해 정밀도뿐 아니라 시스템이 올바른 도구를 선택하고 정보를 검색하는 능력까지 평가함으로써 정확성과 추론 품질을 균형 있게 파악했습니다. 핵심은 사실 정확성(전문가 검증), 검색 품질(관련 문서의 정밀도/재현율), 추론 일관성(논리 흐름의 구조화된 평가)이라는 여러 차원을 측정하는 것이었습니다.

미묘한 품질 평가에 LLM 심사위원을 활용해야 하는 경우

LLM 심사위원은 두 번째 AI 모델을 평가자로 사용하여 사람의 검토를 확장 가능한 자동 품질 채점으로 대체합니다. 더 단순한 지표로 필요한 정확성을 얻을 수 있는데도 LLM 심사위원을 남용하는 경우가 많습니다. 하지만 유용성, 근거 충실성, 추론 품질, 어조, 정책 해석처럼 지표가 의미론적이어서 결정론적 검사와 채점으로 품질을 포착할 수 없는 경우에는 유용할 수 있습니다. 수많은 프롬프트/모델 변형에 걸쳐 확장 가능한 피드백을 수집하고, 명확한 평가 기준과 구조화된 출력 스키마를 정의해야 할 수 있습니다. 효과적으로 활용하려면 다음 단계를 따르세요.

• 평가 기준의 차원을 명시적으로 정의합니다. 정확성, 근거 충실성, 정책 준수, 실행 가능성, 어조.

• 심사 응답에는 구조화된 출력값(JSON 스키마)을 사용합니다.

• 실패 분석을 위해 이진 통과 점수와 진단 텍스트를 모두 기록합니다.

• 릴리스 주기마다 사람이 레이블을 지정한 샘플을 기준으로 심사 결과를 보정합니다.

• 위험 부담이 큰 도메인에서는 이중 심사나 주기적인 합의 검사를 사용합니다.

• 시간 경과에 따른 심사 편향 변화와 불일치율을 추적합니다.

벤치마크 데이터세트는 정답이 알려진 테스트 사례를 선별해 고정한 것으로, 모델을 일관되게 평가하고 버전별 결과를 공정하게 비교하는 데 사용됩니다. 일반적으로 입력(예: 사용자 질의), 예상 출력이나 기준 판단, 채점용 평가 기준/레이블이 포함됩니다. 공개 벤치마크 테스트는 최첨단 모델의 성능을 비교하는 데 사용되며, 시스템을 설계할 때 어떤 모델이 적합한 후보인지 초기에 검토하는 용도로 유용합니다.

하지만 공개 벤치마크에는 알려진 문제가 있으므로, 자체 시스템에서는 이를 비즈니스 맥락의 성능을 대신하는 지표로 삼을 수 없습니다.

• 오염: 모델이 벤치마크 데이터로 학습되었을 수 있으므로 같은 데이터세트로 평가하면 답안지를 보며 채점하는 것과 같습니다.

• 포화: 이미 모든 상위 모델의 점수가 최고 수준이므로 성능 향상이나 저하는 몇 퍼센트포인트에 그치며, 테스트 결과의 자연스러운 변동 범위 안인 경우가 많습니다.

• 좁은 범위: 벤치마크 데이터는 고도로 선별하고 정제되어 실제 작업을 반영하지 못합니다. 일부는 LLM으로 생성되어 실제 데이터의 복잡성과 엣지 케이스(오타, 특이한 표현, 노이즈가 많은 이미지)를 반영하지 못합니다.

학생이 애플리케이션에 문장형 문제 풀이를 도와달라고 요청합니다.

활용할 수 있는 공개 벤치마크의 예: GSM8K(초등학교 수준의 수학 추론)

• 선택 가능한 고난도 세트: MATH.

이 벤치마크가 유용한 이유:

• 일반적인 수학 추론에 어떤 모델이 더 뛰어난지 빠르게 비교할 수 있습니다.

• 본격적인 제품 평가에 투자하기 전에 활용할 수 있는 좋은 1차 필터입니다.

그래도 자체 데이터세트가 필요한 이유:

애플리케이션에는 GSM8K가 테스트하지 않는 요구 사항이 있습니다.

• 자체 교육과정의 표현과 주제 순서,

• 대상 연령대에 맞는 설명 방식,

• 모호하거나 오타가 많은 학생 질문의 처리 방식,

• 정책 규칙(예: 힌트와 전체 답변을 제공하는 시점).

효과적인 검증의 핵심은 애플리케이션별 평가 벤치마크를 만드는 것입니다. 이 데이터세트는 실제 상호작용, 일반적인 엣지 케이스, 발생 가능한 실패 유형을 바탕으로 구성해야 합니다. 새로운 제품이나 프로세스를 구현할 때는 쉽지 않은 작업일 수 있습니다. 하지만 대부분은 기존 제품에서 데이터를 수집하거나 초기 테스트 단계부터 최대한 일찍 수집할 수 있습니다. 애플리케이션을 개발한 후에는 제품의 발전에 맞춰 벤치마크도 진화해야 하며, 시간이 지날수록 더 풍부하고 대표성 있게 구성해야 합니다.

애플리케이션별 벤치마크와 모델 선택의 연계는 매우 중요합니다. 벤치마크는 솔루션의 작동 여부뿐 아니라 어떤 모델 크기와 사후 학습 기법의 조합이 필요한 성능을 가장 경제적으로 제공하는지도 보여 줍니다. 사전 학습 모델(ChatGPT에서 ‘PT’가 의미하는 것)의 가장 강력한 개선은 재학습이 아니라 "사후 학습" 기법에서 나옵니다.

이러한 기법은 모델이 접근할 수 있는 정보, 그 정보의 구조, 추론 시 모델을 안내하고 오케스트레이션하는 방식을 조정하는 데 중점을 둡니다. 사후 학습 기법의 예는 다음과 같습니다.

• 추론 과정 프롬프팅과 동적 컴퓨팅 할당(어려운 문제일수록 더 오래 생각)

• 여러 출력을 생성한 뒤 최선의 결과를 선택하는 자기 일관성

• 검색 증강 생성(RAG), 퓨샷 예시, 에이전트 기반 워크플로 등의 컨텍스트 구성과 오케스트레이션

• 모델이 내부 매개변수를 넘어 행동할 수 있게 하는 도구 사용과 외부 지식 접근

• 구조화된 데이터와 비구조화된 데이터를 효율적으로 검색하고 추론하도록 설계한 지식 표현 및 저장 전략

이러한 사후 학습 기법은 시스템 성능을 크게 개선할 수 있지만 상충 관계도 수반합니다. 오케스트레이션, 검색, 추론 계층이 추가될 때마다 시스템 복잡성, 추론 시간, 운영 비용이 증가합니다. 하지만 적절히 적용하면 올바른 사후 학습 기법의 조합을 통해 성능 요구 사항을 충족하면서도 더 작고 빠르며 저렴한 모델을 사용할 수 있습니다. 모델 크기를 키우는 대신 더 나은 시스템 설계로 성능을 확보하는 것입니다.

이러한 균형은 애플리케이션마다 다르므로, 애플리케이션별 평가를 바탕으로 최적의 기법 조합을 결정해야 합니다. 이를 통해 오케스트레이션을 더 추가해도 유의미한 개선이 없는 지점을 파악하고, 팀은 목표 성능 달성에 필요한 최소한의 사후 학습 복잡성을 선택할 수 있습니다.

AI 솔루션은 데이터베이스, API, 사용자 인터페이스, 오케스트레이션 계층, 모니터링 인프라 등을 아우르는 전체 시스템으로 보아야 합니다. 따라서 평가는 전체 스택에 걸쳐 이루어져야 합니다. 잠재적 문제를 지속적으로 파악하고 책임 있게 속도를 높이려면 시스템의 핵심 부분을 모니터링해야 합니다.

시스템의 핵심 부분을 모니터링한다는 것은 다음을 의미합니다.

• 측정 가능한 결과를 얻도록 파이프라인을 계측합니다.

• 모든 조정의 영향을 확인할 수 있도록 실험을 기록합니다.

• 주요 변경 사항을 배포하기 전에 간단한 A/B 비교를 통해 잠재적인 성능 저하를 테스트합니다.

데이터 기반 반복은 사각지대 없이 프로토타입에서 프로덕션까지의 여정을 단축합니다. 로깅과 모니터링은 애플리케이션의 실제 사용 방식을 이해하는 데도 중요합니다. 관측 가능성을 확보하는 예시는 다음과 같습니다.

• 1단계: request_id, user_segment, intent와 함께 사용자 요청이 들어옵니다.

• 2단계: 추적 로그에 모델 버전, 프롬프트 버전, 검색 문서, 도구 호출을 기록합니다.

• 3단계: LLM 심사위원이 응답을 채점합니다(correctness, groundedness, policy_risk).

• 4단계: 규칙 엔진이 임계값을 평가합니다.

• 5단계: 임계값을 위반하면 알림을 보내고 대체 경로/사람의 검토로 전달합니다.

• 6단계: 실패 사례를 분류 대기열에 추가한 후 벤치마크 백로그에 반영합니다.

실제 사용자는 설계자가 예상한 대로만 행동하지 않습니다. 일부는 지침을 잘못 이해합니다. 어떤 사용자는 의도적으로 취약점을 탐색합니다. 이러한 엣지 케이스는 이상 현상이 아니라 매우 중요한 신호입니다. 잘 구현된 평가 파이프라인은 이를 포착하고 분석하여 향후 테스트에 반영합니다. 사각지대 없이 빠르게 반복하려면 개발 후 평가를 덧붙이는 것이 아니라 시스템에 처음부터 내재화해야 합니다.

처음부터 가드레일과 모니터링을 내재화할 것을 권장합니다.

• 애플리케이션별 벤치마크를 사용해 모델 지표와 성능 저하를 정기적으로 추적합니다.

• 엣지 케이스나 적대적 입력을 수집하고 검토하여 애플리케이션별 벤치마크 데이터세트에 추가합니다.

• 이러한 평가 지표를 핵심 KPI와 일치시킵니다.

• 새로운 위험을 간과하거나 편향의 영향을 받지 않는지 확인하기 위해 데이터세트와 벤치마크를 정기적으로 점검합니다.

• 지표가 저하되면 자동 알림이 울리도록 구현합니다(예: 정확성이 85% 미만이면 검토 시작).

• 위험 부담이 큰 결정(법률 자문, 의료 안내, 금융 거래)에는 사람의 검토 절차를 유지합니다.

벤치마크를 실행할 때마다 컴퓨팅 자원과 에너지가 소모됩니다. 불필요한 실험은 매번 비용을 늘립니다. 책임 있는 평가는 엄밀성과 효율성의 균형을 맞춰야 합니다.

에너지와 비용이 급증하지 않도록 다음과 같은 실질적인 조치를 취할 수 있습니다.

• 가능하면 작은 모델을 사용합니다. 저렴한 모델로 초기 실험을 진행하고 접근 방식이 검증된 후에만 확장하세요.

• 프롬프트와 API 호출을 캐시합니다.

• 에너지를 고려해 일정을 계획합니다(일괄 처리, 스팟 인스턴스, 유연한 우선순위).

• 성능과 함께 컴퓨팅 사용량도 추적합니다.

새롭게 등장하는 AI 규제에도 주의를 기울여야 합니다. 전용 법률이 없더라도 다음과 같은 기존 체계와 필수 조치는 여전히 적용됩니다.

데이터 보호:

• 적절한 동의 없이 벤치마크 데이터세트에 개인 식별 정보(PII)가 포함되지 않도록 합니다.

• 기록된 질의에 데이터 보존 정책을 적용합니다.

• 데이터 삭제 요청을 처리할 수단을 제공합니다.

평등과 편향:

• 인구통계학적 집단별로 성능을 테스트합니다.

• 벤치마크를 만들 때 다양한 집단을 대표하도록 구성합니다.

인권과 투명성:

• 사용자가 알 수 있도록 모델의 한계를 명확히 문서화합니다.

• 위험 부담이 큰 결정에는 설명을 제공합니다.

• 중요한 애플리케이션에는 사람의 감독을 적용합니다.

평가는 일회성 행사가 아니라 계속 진화하는 시스템입니다. 빠르게 변화하는 분야에서는 얼마나 신속하게 테스트하고 학습하며 적응해 모델과 새로운 솔루션을 더 효과적으로 배포하느냐가 경쟁력이 됩니다.

평가를 엔지니어링과 제품 관리의 핵심 활동으로 내재화하면 팀은 더 빠르고 안전하게 혁신할 수 있습니다. 먼저 AI 애플리케이션의 맥락에서 ‘좋음’을 정의하고 평가 플랫폼을 구축하세요. 그런 다음 반복할 때마다 프로덕션 준비 상태를 확신할 수 있는 애플리케이션별 벤치마크로 발전시키세요.