저는 팀들이 LLM 채점 파이프라인 (scoring pipeline)을 개선하는 데 몇 주를 소비하고도, 실제 데이터에 적용했을 때 많은 점수가 무용지물이라는 것을 발견하는 과정을 지켜봐 왔습니다. 모델은 실제 관련성 (relevance)보다 키워드 밀도 (keyword density)에 보상을 줍니다. 출력물은 구조화된 것처럼 보이고, 수치도 범위 내에 있습니다. 하지만 결과는 사람이 판단하는 것과 일치하지 않습니다.

그 순간 당신은 깨닫게 됩니다. AI 기능을 출시하는 것은 프롬프트 (prompt)를 먼저 작성하는 것이 아니라는 것을 말입니다. 평가 (evaluation)를 먼저 작성함으로써 기능을 출시하는 것입니다.

아무도 말하지 않는 80/20의 함정

AI 기능을 구축하는 대부분의 팀은 동일한 패턴을 따릅니다. LLM 호출을 연결하고, 세 가지 예시로 테스트한 뒤, 완료되었다고 생각합니다. 그러다 프로덕션 (production) 환경에 배포되면 모델이 엣지 케이스 (edge cases)에서 환각 (hallucinate)을 일으키거나, 지시 사항을 무시하거나, 맞게 보이지만 실제로는 틀린 출력을 생성한다는 것을 발견하게 됩니다.

문제는 모델이 아닙니다. 당신이 시스템을 잘못된 대상으로 평가했다는 점입니다.

제 경험상, 80/20 법칙은 전통적인 소프트웨어와 달리 AI 기능에 다르게 적용됩니다. 초기 작업의 20%가 목표의 80%를 달성하게 해줍니다. 나머지 80%는 모두 평가 (evaluation)입니다. 즉, 엣지 케이스 (edge cases)를 포착하고, 품질을 측정하며, 출력을 수락할지 거부할지를 결정하는 과정입니다.

단 하나의 프롬프트 (prompt)를 작성하기 전에 평가 기준을 정의하지 않는다면, 당신은 그 80%의 시간을 사후 수습을 위한 긴급 상황 (fire drill) 속에서 보내게 될 것입니다. 버그를 예방하는 대신, 버그가 나타날 때마다 수정하게 될 것입니다.

평가 우선 파이프라인 (Eval-First Pipeline)을 구성하는 방법

제가 작업했던 채용 정보 플랫폼에서는 시스템이 매일 10,000개 이상의 공고를 처리합니다. 각 공고는 각 후보자 프로필에 대한 관련성 점수 (relevance score)가 필요합니다. LLM은 점수와 근거가 포함된 구조화된 JSON 출력을 생성합니다.

채점 프롬프트 (scoring prompt)를 작성하기 전에 제가 구축한 평가 구조는 다음과 같습니다:

interface ListingScoringEval {
  scoreRange: {
    min: number;  // 0
...

이것은 프롬프트 (prompt)가 아닙니다. 이것은 계약 (contract)입니다. 모델이 무엇인가를 생성하기 전에 유효한 출력이 정확히 어떤 모습이어야 하는지를 저에게 알려줍니다.

평가 (Eval)는 세 가지 역할을 수행합니다. 첫째, 출력 구조가 올바른지(올바른 필드, 올바른 타입)를 검증합니다. 둘째, 출력이 내부적으로 일관성이 있는지(추론 과정이 점수를 정당화하는지)를 확인합니다. 셋째, 알려진 실패 모드(빈 입력, 조작된 데이터)를 거부합니다.

진짜 테스트: 당신이 생각하지 못한 엣지 케이스 (Edge Cases)

평가는 제가 고려하지 못했던 문제를 잡아냈습니다. 일부 채용 공고에는 설명 없이 회사 이름과 직함만 포함되어 있었습니다. LLM은 어쨌든 점수를 생성하겠지만, 그 추론은 일반적이고 무의미할 것이었습니다.

평가는 다음 사항들을 표시했습니다. 최소 점수를 10점으로 설정하여 그 미만은 자동으로 거부되도록 했습니다. 하지만 더 중요한 것은, 모델이 내용이 없는 직무에 대해 의미 있는 15단어를 생성할 수 없었기 때문에 추론 검사 (reasoning check) 단계에서 빈 공고들을 잡아냈다는 점입니다.

다음은 출력이 데이터베이스에 도달하기 전에 실행되는 검증 함수입니다:

function validateScoringOutput(
  output: LLMScoringOutput,
  input: JobListing
...

이 함수는 모든 출력마다 실행됩니다. 통과하지 못하는 모든 것은 거부합니다. 예외는 없습니다. 평가 (Eval)가 실패하면 출력은 사용자에게 전달되지 않습니다.

이 단계를 건너뛰었을 때 발생하는 일

평가를 건너뛰고 바로 출시한다고 가정해 봅시다. 첫 일주일은 괜찮아 보일 것입니다. 그러다 한 채용 담당자가 "React 개발자"를 검색했는데, 85점을 받은 Java 백엔드 역할의 공고를 보게 됩니다. 그들은 클릭하고, 시간을 낭비하며, 플랫폼에 대한 신뢰를 잃게 됩니다.

그것은 단 하나의 잘못된 출력일 뿐입니다. 진짜 비용은 누적됩니다. 모든 잘못된 출력은 사용자들이 AI 기능을 무시하도록 훈련시킵니다. 그들은 점수를 신뢰하지 않게 됩니다. 필터를 사용하지 않게 됩니다. 당신은 사용자 경험을 적극적으로 저하시키는 기능을 만든 셈입니다.

저는 여러 프로젝트에서 이러한 패턴이 반복되는 것을 보았습니다. 팀들은 AI 기능을 출시하고, 그것은 해피 패스 (happy path)에서는 잘 작동하지만, 누군가 알아차릴 때까지 엣지 케이스 (edge cases)에서 조용히 실패합니다. 해결책은 항상 같습니다. 평가 (evaluation)를 추가하는 것입니다. 하지만 그때가 되면 당신은 처음부터 설계되지 않았던 시스템에 방어 기제를 사후에 끼워 맞추고 있는 상태가 됩니다.

평가 우선 워크플로우 (The Eval-First Workflow)

제가 현재 사용하고 있는 워크플로우는 다음과 같습니다. 초기에는 시간이 더 걸리지만, 나중에 디버깅(Debugging)에 소요되는 몇 주를 아껴줍니다.

1. 프롬프트(Prompt)를 작성하기 전에 평가 계약(Eval contract)을 작성합니다. 유효한 출력 형태(Output shape), 범위, 그리고 거절 기준(Rejection criteria)을 정의합니다.
2. 검증 함수(Validation function)를 구축합니다. 이 함수는 잘못된 출력을 자동으로 거절해야 합니다.
3. 평가(Eval)를 기준으로 프롬프트를 작성합니다. 출력이 정확히 어떤 모습이어야 하는지 명확히 알 수 있습니다.
4. 3개가 아닌 100개의 실제 사례로 테스트합니다. 모든 사례에 대해 평가를 실행합니다.
5. 대다수의 사례에서 평가를 통과할 때까지 프롬프트를 반복(Iterate)합니다.
6. 평가가 프로덕션(Production) 환경에서 실행되는 상태로 출시합니다. 모든 거절 사례를 로그(Log)로 남깁니다.

핵심 통찰은 평가(Eval)가 단순한 테스트 단계가 아니라는 점입니다. 그것은 프로덕션 가드(Production guard)입니다. 매번, 모든 출력에 대해 실행됩니다. 모델이 드리프트(Drift)하거나 새로운 엣지 케이스(Edge case)가 나타나면, 평가는 그것이 사용자에게 도달하기 전에 잡아냅니다.

이것이 창업자들에게 중요한 이유

AI 기능을 구축하고 있다면, 출력의 품질이 사용자의 신뢰 여부를 결정합니다. 대부분의 경우에만 작동하는 기능은 아예 기능이 없는 것보다 더 나쁩니다. 실패가 신뢰를 쌓는 속도보다 신뢰를 깎아먹는 속도가 더 빠르기 때문입니다.

평가 우선(Eval-first) 접근 방식은 시작하기 전에 무엇이 "좋은" 것인지 정의하도록 강제합니다. 이는 실패 모드(Failure modes)를 명시적으로 만듭니다. 그리고 테스트 단계뿐만 아니라 프로덕션에서도 잘못된 출력을 잡아낼 수 있는 메커니즘을 제공합니다.

만약 귀하의 팀이 AI 기능을 출시하면서 프로덕션에서 품질 문제에 직면하고 있다면, 그것이 바로 제가 도와드리는 부분입니다. 귀하의 특정 사용 사례에 맞는 평가 파이프라인(Eval pipeline)을 구조화하는 방법에 대해 기꺼이 의견을 나누고 싶습니다.

작성자: Abdul Rehman, 프로덕션 SaaS, MVP 및 AI 자동화를 구축하는 풀스택 AI 엔지니어. 더 자세한 내용은 PrimeStrides에서 확인하세요.