2.5.2. 확률적 결과에 대한 결정론적 검증 경계(Threshold) 설정 전략

2.5.1절에서 AI 오라클(Oracle)이 관측해야 할 3대 필수 요구사항(유창성, 사실성, 일관성)을 정의했다면, 이제 남은 것은 이 철학적이고 추상적인 지표들을 지속적 통합/지속적 배포(CI/CD) 파이프라인의 냉혹한 컨베이어 벨트에 어떻게 무사히 올려놓을 것인가 하는 공학적 과제다.

테스트 자동화 스크립트(예: Jenkins, GitHub Actions)는 “조금 유창함”, “대체로 사실임“과 같은 아날로그적 뉘앙스를 컴파일(Compile)할 수 없다. 코드는 오직 ’참( $1$ )’이거나 ’거짓( $0$ )’인 부울(Boolean) 상태만을 허용한다. 따라서 AI 오라클 설계의 성패는 모델이 반환하는 연속적인 확률(Probability) 점수를, 시스템이 이해할 수 있는 결정론적이고 단절적인 ‘경계치(Threshold)’ 로 얼마나 정교하게 치환할 수 있느냐에 달려 있다.

본 절에서는 코사인 유사도(Cosine Similarity)나 LLM-as-a-Judge의 스코어 보드와 같이 연속된 실수(Real Number, $\mathbb{R}$ )로 표현되는 AI의 평가 결과를 단호한 PASS와 FAIL로 쪼개는 경계선의 설정 철학과 그 내재적 딜레마를 심도 있게 구축한다.

1. 연속적 점수 공간(Continuous Score Space)의 이분화(Dichotomization)

전통적 일치성(Exact Match) 테스트 로직이 이산 수학(Discrete Mathematics)의 등식( $A == B$ ) 환경이었다면, 현대 AI 오라클의 엔진은 기본적으로 0에서 1 사이의 연속된 계량값을 뱉어낸다.

예를 들어 두 문장의 의미론적 동등성(2.4.4절 참조)을 비교하는 텍스트 임베딩 모델은 다음과 같이 결과를 산출한다.

구문 A와 구문 B의 코사인 유사도: $0.84128...$

오라클의 역할은 이 무한히 쪼개지는 소수점을 잘라내기 위해, 시스템이 용인할 수 있는 최소한의 품질 마지노선, 즉 **임계치( $\tau$ )**를 선언하는 것이다.
만약 임계치 $\tau = 0.85$ 로 설정된 시스템이라면, $0.84128$ 을 획득한 테스트 케이스는 그 의미가 아무리 훌륭하더라도 코드 상에서 즉시 FAIL(0)로 변환되어 폐기(Drop)된다. 반면 $\tau = 0.80$ 로 완화(Relax)된 시스템이라면 동일한 결과가 PASS(1)로 판독되어 무사히 프로덕션 환경에 배포된다.

이러한 이분화(Dichotomization) 작업이야말로 ’확률’의 안개 속에 있는 결과를 ‘결정론적’ 세계로 억지로 편입시키는 가장 강력하고도 위험한 공학 조치다.

2. 임계치(\tau) 설정의 뼈아픈 딜레마: 위양성 vs 위음성

그렇다면 “적절한 임계치 $\tau$ 는 몇인가?“라는 질문이 남는다. 안타깝게도 이 수치를 계산해 내는 수학적 절대 공식은 소프트웨어 공학에 존재하지 않는다. 임계치는 전적으로 비즈니스가 짊어질 수 있는 ’위험의 종류’에 따라 결정되는 트레이드오프(Trade-off)의 산물이다.

임계치 $\tau$ 를 움직이는 순간, 테스트 파이프라인에서는 필연적으로 두 가지 치명적 오류 중 하나가 기하급수적으로 폭증하게 된다.

2.1 높은 임계치 (High Threshold, 예: $\tau = 0.95$ )

오라클을 매우 보수적(Conservative)이고 엄격하게 설정할 경우다.

방어 효과: 사실과 조금이라도 다르거나(환각), 브랜드 톤앤매너에서 미세하게 벗어난 출력물은 모조리 FAIL 처리되므로, 치명적 결함이 프로덕션에 배포되는 **위양성(False Positive, 불량품 통과)**을 거의 $0\%$ 에 가깝게 방어할 수 있다.
부작용 (위음성의 폭발): 인간이 보기에 완벽히 훌륭하고 유창한 정답들조차도 유사도 $0.94$ 를 받아 파이프라인에서 탈락한다. 이를 **위음성(False Negative, 정상품 폐기)**이라 부르며, 개발자는 매일같이 실패한 빌드(Build) 파이프라인을 복구하느라 밤을 새우게 되는 유지보수 부채(Maintenance Debt) 지옥에 빠진다.

2.2 낮은 임계치 (Low Threshold, 예: $\tau = 0.70$ )

오라클을 매우 개방적(Lenient)이고 너그럽게 설정할 경우다.

방어 효과: 웬만한 변형 프롬프트나 뉘앙스의 차이는 방어하지 않고 무난히 통과(Pass)시켜 주므로, 개발 파이프라인이 중단되는 스트레스(위음성)가 급격히 줄어든다.
부작용 (위양성의 폭발): “환자에게 타이레놀을 투여하시오“라는 정답에 대해, AI가 “환자에게 타조를 투여하시오“라며 미세한 단어 변이(환각)를 발생시켰을 때 이를 잡아내지 못하고 PASS 스탬프를 찍어버린다. 고객의 생명과 직결되는 결함이 실서비스에 배포되는 최악의 재앙(위양성 폭발)을 초래한다.

graph LR
    subgraph Threshold Dynamics
        direction LR
        Score[0.0 Oracle Score 1.0]
        
        T_Low[/"Low Threshold (0.7)"/]
        T_High[/"High Threshold (0.9)"/]
        
        Score --> T_Low
        Score --> T_High
    end

    subgraph The Engineering Trade-off
        T_Low --> |Increases| FP[False Positives \n (Bugs reach Prod)]
        T_Low --> |Decreases| FN_Low[False Negatives \n (Dev Stress Down)]
        
        T_High --> |Decreases| FP_High[False Positives \n (Bugs Blocked)]
        T_High --> |Increases| FN[False Negatives \n (CI/CD Blocked)]
    end
    
    style FP fill:#fdd,stroke:#d00
    style FN fill:#fdd,stroke:#d00

3. 소결: 비즈니스 도메인에 종속된 동적 타협안

결론적으로, 확률적 결과에 대해 단 하나의 완벽한 결정론적 경계선(Golden Threshold)을 그으려는 시도는 환상에 불과하다. 임계치 설정은 순수한 소프트웨어 공학의 영역을 넘어 ’비즈니스 리스크 관리(Business Risk Management)’의 영역으로 확장되어야 한다.

테스트 자동화 엔지니어는 시스템의 모든 오라클에 $\tau = 0.85$ 라는 무식한 일괄 설정을 먹이는 대신, 각 모듈(Module)이 속한 **비즈니스의 위해도(Risk Level)**에 따라 임계치를 차등적으로 분배하는 고도의 수학적 설계도를 그려야만 한다.

이어지는 하위 절들에서는 이 막막한 트레이드오프 위에서 구체적으로 어떻게 경계선을 그어야 하는지 타개책을 모색한다.
**2.5.2.1절(비즈니스 리스크 기반의 허용 오차 할당)**에서는 도메인의 성격(의료 vs 엔터테인먼트)에 따라 임계치가 동적으로 변해야 하는 필연성을, 이어서 **2.5.2.2절(보수적 오라클과 개방적 오라클 운영의 트레이드오프)**에서는 이 상충하는 임계치 전략들이 실제 개발 속도와 품질에 어떠한 나비효과를 불러일으키는지 심층적으로 파헤칠 것이다.