2.4.2.1. 다중 정답(Multiple Valid Answers)을 허용하는 테스트 케이스의 본질

소프트웨어 품질 공학에서 고전적인 테스트 케이스(Test Case)의 철학은 오컴의 면도날(Occam’s Razor)과 같이 간결했다. 하나의 질문(Input)에는 오직 단 하나의 절대적 정답(Single Valid Answer)만이 존재해야 하며, 이 정점을 빗겨가는 모든 결괏값은 가차 없이 버그(Bug)로 간주되었다.

그러나 앞서 2.4.2절에서 살펴보았듯, 거대 언어 모델(LLM)이 창출해 내는 확률적이고 의미론적인(Semantic) 세계에서 이러한 ’단일 정답’의 강박은 테스트 프레임워크 자체를 마비시키는 가장 큰 공학적 장애물이 되었다. “내일 서울 날씨가 어때?“라는 프롬프트에 대응하는 정답은 “비가 옴”, “강수 확률 높음”, “우산을 준비할 것” 등 수십 가지의 형태(Morphology)로 분기될 수 있기 때문이다.

본 절에서는 단일 정답의 파괴를 인정하고, **‘다중 정답(Multiple Valid Answers)’**을 근본적으로 허용하는 현대 AI 테스트 케이스의 본질적인 변화와, 이를 수리적이고 구조적으로 통제하기 위한 공학적 접근 방식을 심층적으로 조망한다.

1. 정답의 기하학적 패러다임 전환: 점(Point)에서 다각형(Polygon)으로

다중 정답을 허용한다는 것은, 오라클(Oracle)이 정답을 판별하는 기하학적 공간이 1차원의 점(Point)에서 다차원 벡터 공간의 범위(Boundary/Polygon)로 확장되었음을 의미한다.

점 기반 판독 (Point-based Assertion): 입력 $\vec{x}$ 에 대한 정답 공간 $S$ 가 단일한 요소 $y_{expected}$ 만을 포함한다. 즉, $S = \{y_{expected}\}$ 이며, 실제 결과 $y_{actual} \equiv y_{expected}$ 인지 문자열 단위로 해시(Hash) 비교를 수행한다.
범위 기반 판독 (Boundary-based Assertion): 입력 $\vec{x}$ 에 대하여, 정답 공간 $S$ 는 비즈니스 로직을 훼손하지 않는 무한한 가능성의 집합 $S = \{y_1, y_2, y_3, \dots, y_n\}$ 으로 정의된다. 오라클은 $y_{actual} \in S$ 인지, 즉 결과가 ‘허용 가능한 동치성 공간(Semantic Equivalence Space)’ 안에 안정적으로 속해(Containment) 있는지를 판별해야 한다.

graph LR
    subgraph Traditional Assertion: Point Match
        P_Exp((Expected\nOutput '42'))
        P_Act[Actual Output '42.0']
        
        P_Act -.-> |Fail: String Mismatch| P_Exp
    end

    subgraph AI Assertion: Semantic Boundary
        direction TB
        S_Boundary{"Semantic Space (Intent: Rain)"}
        
        A1[Output: "비가 옵니다"]
        A2[Output: "우산을 챙기세요"]
        A3[Output: "강수 확률 80%"]
        E1[Output: "내일은 맑습니다"]
        
        A1 --> |Belongs To| S_Boundary
        A2 --> |Belongs To| S_Boundary
        A3 --> |Belongs To| S_Boundary
        E1 -.-> |Out of Bounds (Fail)| S_Boundary
    end
    
    style P_Exp fill:#fdd,stroke:#d00,stroke-width:2px;
    style S_Boundary fill:#efe,stroke:#3c3,stroke-width:2px;

2. 다중 정답을 통제하는 시스템 설계의 본질

’다중 정답’을 허용한다고 해서, 시스템이 뱉어내는 아무 말 대단치(Hallucination)를 모두 정답으로 인정하겠다는 의미가 결코 아니다. 다중 정답 테스팅의 핵심은 무한한 분기를 인정하되, 그 분기가 반드시 지켜야만 하는 핵심 제약 조건(Constraints)을 뼈대로 세워 오라클을 재구축하는 것에 있다.

이러한 테스트 케이스를 설계하기 위해 공학자들은 기존의 AssertEquals(expected, actual) 문법을 버리고 다음과 같은 검증 패턴을 채택한다.

2.1 정답 후보군 리스트 검증 (List / Set Containment)

정답이 될 수 있는 유한한 N개의 후보군을 도메인 전문가(Domain Expert)가 사전에 작성하여 집합(Set)으로 만든 후, 시스템의 출력이 해당 집합 안에 포함되는지 확인한다.

구현: AssertTrue( ["비", "소나기", "우산"].any(keyword in actual_output) )
한계: 출력의 다양성이 집합 N개를 벗어날 경우(예: “하늘에서 물방울이 떨어집니다”), 올바른 정답임에도 여전히 위음성(False Negative) 고장이 발생한다. 생성형 모델의 무한한 변수를 모두 하드코딩 리스트로 막는 것은 불가능에 가깝다.

2.2 제약 조건 프로그래밍 (Constraint-based Programming)

출력값의 텍스트가 무엇이냐가 아니라, 출력값이 특정한 논리적 속성(Properties)을 지니고 있는가를 평가한다. 이는 이전에 다루었던 부분 오라클(Partial Oracle)의 철학을 극대화한 형태다.

구문론적 제약 (Syntactic Constraints): “출력은 반드시 3문장 이내인가?”, “결과 포맷이 지정된 JSON 스키마(Schema)를 준수하는가?”
의미론적 제약 (Semantic Constraints): “출력 내용 중에 부정적 감성어(Negative Sentiment)가 포함되지 않았는가?”

2.3 정보의 포괄성 판독 (Information Subsumption)

기계 독해(QA)나 요약(Summarization) 도메인에서 다중 정답을 다룰 때 가장 중요한 척도다. 출력된 텍스트의 길이가 다르더라도, “이 대답 속에 우리가 요구한 핵심 팩트(Fact)가 손실 없이 포함되어 있는가?“를 판별하는 데 집중한다.

예컨대, 기준 정답이 “사과의 가격은 1000원” 일 때, “현재 시장에서 판매되는 사과의 단가는 1000원으로 책정되어 있습니다“라는 출력은 불필요한 서술어가 붙었음에도 불구하고 핵심 팩트를 완전히 포함(Subsumption)하고 있으므로 패스(Pass)로 처리해야 한다.

3. 소결: 모호성을 통제하기 위한 새로운 지표의 예고

결론적으로, 다중 정답을 허용하는 테스트 케이스의 본질은 **‘정확도(Accuracy)의 집착에서 타당성(Validity)의 포용으로의 전환’**이다. 테스터는 더 이상 시스템이 자신이 미리 적어 놓은 글자와 똑같이 뱉어내기를 기대해서는 안 되며, 시스템의 응답이 비즈니스의 ‘의도(Intent)’ 반경 내에 무사히 착륙했는지를 검토하는 항법사(Navigator)로 역할이 바뀌어야 한다.

그러나, “의미론적 제약“이나 “핵심 팩트의 포함 여부“를 기계가 코드로 판독하는 과정 역시 인간의 ’주관적 해석’을 수반하기에 필연적인 모호성 문제에 맞닥뜨리게 된다.

어떠한 근거로 기계가 “가독성이 높음“이나 “정중한 톤앤매너가 지켜졌음“을 0과 1로 수치화하여 테스트 성공을 판별할 수 있을까? 이어지는 2.4.2.2절에서는 가장 계량화하기 힘든 주관적 품질들(Subjective Qualities)을 억지로 객관적(Objective) 지표로 변환하려 했던 공학계의 치열한 사투와 그 뼈아픈 한계들을 집중적으로 추적할 것이다.