3.6.3 모호성 통제를 위한 부분 점수(Partial Credit) 도입 여부와 공학적 채점 기준

3.6.3 모호성 통제를 위한 부분 점수(Partial Credit) 도입 여부와 공학적 채점 기준

소프트웨어 공학의 정통적인 단위 테스트(Unit Test)는 수십 년간 **1(Pass) 아니면 0(Fail)**이라는 매우 냉혹하고도 깔끔한 이분법적(Binary) 채점 체계를 엄격하게 따라왔다. 컴파일러의 세계에서 코드는 완벽하게 빌드되거나 크래시가 나거나 둘 중 하나이며 둘 사이의 회색 지대란 존재할 수 없기 때문이다.
하지만 비결정적이고 창의적인 자연어(Natural Language)를 생성해 내는 거대 AI 모델의 평가 체계에 이 구시대적인 엄밀한 이분법을 억지로 끼워 맞추어 적용하면, 파이프라인 전체의 성능 변화를 파악하는 데 있어 매우 심각한 수학적, 통계적 왜곡(Statistical Distortion) 현상이 발생한다.

예를 들어, 프롬프트 엔지니어가 챗봇 시스템에게 “우리 은행의 이체 수수료 면제 조건 3가지를 정확히 알려줘“라는 질문을 테스트 케이스로 던졌다고 가정해 보자.

  • [모델 A 버추얼 런]: 면제 조건 3가지를 모두 완벽하게 식별하여 순서대로 대답했다.
  • [모델 B 버추얼 런]: 면제 조건 중 2가지는 정확하게 맞혔으나, 마지막 1가지는 엉뚱한 환각 정보로 빠뜨렸다.
  • [모델 C 버추얼 런]: 고객에게 모욕적인 욕설을 뱉으며 조건 안내 자체를 완전히 침묵하고 거부했다.

만약 CI/CD 오라클 파이프라인이 과거 소프트웨어 공학의 ‘전부 아니면 전무(All-or-Nothing)’ Pass/Fail 로직만을 고집스럽게 따른다면, 기가 막히게도 아쉽게 하나를 틀린 모델 B와 쌍욕을 한 모델 C는 시스템상 완전히 동일하게 취급되어 무정하게 ‘Fail(0점)’ 처리된다.
이러한 거친 채점 방식은 모델 B가 C보다 실제 프로덕션 서버 운영 환경의 기대치(UX)에 훨씬 더 가깝게 전진하고 동작했다는 엔지니어링적 진보의 진실(Engineering Truth)을 까맣게 가려버리며, 매일매일 이어지는 잦은 모델 파인튜닝(Fine-tuning) 업그레이드 전후의 미세한 알고리즘 성능 향상 궤적을 메트릭스가 매우 둔감하게(Insensitive) 놓치도록 눈을 멀게 만드는 최악의 원인이 된다.

따라서 최신 AI 오라클 시스템 아키텍처의 정답지 컴포넌트는 자연어 특유의 의미론적 모호성을 수치적으로 섬세하게 통제하고 개선을 감지해 내기 위해, **‘연속적인 부분 점수(Partial Credit & Floating Score)’**라는 새로운 차원의 유연한 평가 기준을 반드시 스키마에 도입해야만 한다.

1. 부분 점수 시스템의 해체 설계 원칙: 독립적 평가 항목(Sub-metrics)의 분리

부분 점수를 기술적으로 깔끔하게 도입하기 위해서는, 어설프게 LLM 판사(LLM-as-a-Judge)에게 “0점부터 10점 사이로 채점해 줘“라고 뭉뚱그려 프롬프트를 던지는 낭만을 버려야 한다. 대신 아키텍트는 철저한 단일 책임 원칙(SRP)에 따라 단일 테스트 케이스의 거대한 정답(Ground Truth) 덩어리를, 상호 완벽하게 **독립적이고 원자적인 여러 개의 하위 평가 항목(Atomic Sub-metrics)**들로 메스를 대어 분해(Decomposition)해야 한다.

  • [정밀 채점 정답지 JSON 스키마 구조 예시]: 
    {
  "test_case_id": "QA-TC-105-FEE_EXEMPTION",
  "expected_outputs": {
    "metrics": [
      {"id": "fact_1_included", "type": "regex_match", "target": "급여 이체", "weight": 0.4},
      {"id": "fact_2_included", "type": "regex_match", "target": "자동 이체", "weight": 0.4},
      {"id": "format_correct", "type": "schema_validate", "is_bullet_list": true, "weight": 0.2}
    ],
    "calculation_mode": "weighted_sum"
  }
}


위의 체계적인 JSON 스키마 예시에서 파이프라인 채점 오라클은 텍스트 응답을 향해 3개의 파편화되고 독립된 Assert 쿼리를 비동기로 병렬 실행한다.
만약 모델이 앞선 두 개의 핵심 비즈니스 팩트는 정확히 맞혀냈으나 지시된 불릿 리스트(Bullet List) 포맷을 무시하고 불친절한 줄글로 뭉뚱그려 작성했다면, 이 복합 테스트의 최종 결과는 단순한 Fail(0점)이 아니라 수학적으로 **`0.8점 (80%)`**이라는 연속성 있는 실수(Floating Point) 스코어 메트릭으로 산출된다. 이 0.8점이라는 수치는 대시보드에서 전일 빌드(0.4점) 대비 두 배나 훌륭한 개선이 일어났음을 아름답고 명확하게 증명해 낸다.

## 2.  언제 부분 점수를 도입하고, 언제 엄격히 버릴 것인가 (도입의 딜레마)


그러나 MLOps 부서가 모든 테스트 케이스 스위트(Test Suite)에 부분 점수를 남발하고 관대하게 적용해서는 절대 안 된다. 부분 점수는 성능 개선을 보여주는 달콤한 마약이지만, 동시에 시스템의 치명적 구멍(Vulnerability)을 가리는 양날의 검(Double-edged Sword)이다. 아키텍트는 다음의 두 가지 극단적인 도메인 기준에 따라 채점 스크립트를 철저히 분리 라우팅해야 한다.

1.  **[반드시 도입해야 하는 경우 (Recall-heavy & Generative Task)]:**
광범위한 사내 문서 정보 검색 요약, 다중 조건 브레인스토밍, 기획서 초안 작성 등 **'하나라도 더 많은 요소를 최대한 풍부하게 뽑아내는 것(High Recall)'**이 전체 비즈니스 가치 창출에 결정적으로 중요한 태스크이다. 이러한 영역에서는 이분법적 Fail이 잦을 경우 개발자의 사기만 꺾이므로, 촘촘하게 설계된 부분 점수(Continuous Metric)가 프롬프트 엔지니어링의 미세한 방향타와 성능 개선을 매일 추적하는 가장 훌륭한 나침반 지표로 작용한다.
2.  **[절대 도입해서는 안 되는 금기 영역 (Mission Critical & Fact-checking Task)]:**
제약 바이오 처방 스펙 제공 시스템에서 알약의 밀리그램 용량을 소수점 하나 잘못 기재하거나, 금융 뱅킹 결제 트랜잭션 시스템에서 계좌 승인 코드 번호를 단 한 글자라도 잘못 출력하는 경우이다. 이런 사람의 생명이나 수억 원의 자산이 직결된 치명적인 팩트 체킹(Fact-checking) 오라클 태스크에서는, 100글자 중 99글자를 맞혔더라도 단 하나의 파라미터 오류가 시스템 전체의 법적 신뢰성과 컴플라이언스를 즉각 `$0`으로 붕괴시킨다. 이 영역에서는 무자비할 정도로 전통적이고 엄격한 이분법적 불관용(`1 or 0`, Boolean strict Assert) 로직을 고수하여, 어떤 압박에도 오라클의 보안 기준을 1%도 타협하지 말아야 한다.

결론적으로 부분 점수 스키마의 체계적인 도입 결단은, 사내 정답지 시스템을 단순하고 멍청한 'O/X 기계 채점기'의 수준을 넘어, 현재 우리 AI 파이프라인의 수천 개 노드(Node) 중 어느 특정 신경망 부위가 질병에 취약한지(사실 논리 추출 부서인지, 아니면 단순 마크다운 포맷팅 프레젠테이션 부서인지)를 정밀하게 진단해 내고 수술을 지시하는 최고급 **'종합 데이터 건강 검진 아키텍처 센터(Comprehensive Data Diagnostic Center)'**로 격상시키는 가장 결정적인 모멘텀이 된다.