2.3.4. 부분 오라클(Partial Oracle)의 현실적 타협과 한계

오라클 비용(Oracle Cost)이 지수 함수처럼 폭발하여 프로젝트의 채산성을 무너뜨릴 때, 소프트웨어 공학자들은 $100\%$ 완벽한 정답(True Oracle)을 포기하는 대신 비즈니스가 허용할 수 있는 수준의 ’불완전한 정답’을 채택하는 전략적 후퇴를 강행한다. 이처럼 시스템 출력의 모든 상태가 아닌 특정 속성(Property)이나 부분 집합(Subset)만을 검증 대상으로 축소시킨 오라클을 **‘부분 오라클(Partial Oracle)’**이라고 정의한다.

부분 오라클은 완벽을 추구하던 전통적인 화이트박스(White-box) 지향의 테스팅에서 벗어나, “틀린 것을 모두 잡아낼 수는 없지만, 적어도 명백한 헛소리만은 걸러내자“라는 블랙박스(Black-box) 지향의 실용주의적 타협 산물이다. 본 절에서는 부분 오라클이 작동하는 핵심 검증 범주와, 비용 절감의 대가로 짊어져야 하는 치명적인 위양성(False Positive)의 한계를 심층 분석한다.

1. 부분 오라클의 접근법: 범위를 좁히는 3가지 타협

오라클 비용을 선형으로 떨어뜨리기 위해 부분 오라클은 SUT(System Under Test)의 출력값 $\vec{y}$ 전체를 비교하는 대신, $\vec{y}$ 를 형태적, 논리적으로 가공한 프로파일(Profile)만을 검증한다.

1.1 타입 및 포맷 검증 (Type & Format Check)

산출된 결과값의 의미(Meaning) 자체는 버리고, 그 값이 약속된 자료형(Data Type)과 구조적 포맷을 따르는지만 판별한다.

예시: 항공권 예약 API가 “편도 145만 원“이라는 정답 대신 “편도 900만 원“을 반환하더라도, 부분 오라클은 “가격이 Int형 숫자로 들어왔고, JSON의 필드가 깨지지 않았다“는 이유만으로 통과(Pass) 판정을 내린다.

1.2 경계값 및 범위 검증 (Range & Boundary Check)

출력값이 도메인 특성상 물리적으로, 혹은 비즈니스 로직상 가능한 논리적 상/하한의 테두리(Boundary) 안에 속해 있는지만 판별한다.

예시: 확률을 계산하는 시스템의 출력 $y$ 에 대해 완벽한 참값을 모를지라도, 최소한 $0 \le y \le 1$ 이어야 한다는 공리는 명확하다. 만약 시스템이 $-0.5$ 나 $1.2$ 를 반홚한다면 이는 볼 것도 없이 명백한 결함(Fail)이다.

1.3 핵심 키워드 유무 (Keyword Containment)

정형화된 값이 아닌 자연어나 로그 형태의 출력을 검증할 때, 전체 문맥이나 정확도를 파악할 오라클 능력이 부재하므로 사전에 정의된 ‘필수 포함 단어’ 또는 ’금칙어’를 잣대로 삼는다.

예시: 챗봇 모델 테스트 시 문장의 자연스러움을 인간처럼 판별하는 것은 경제적으로 불가능하므로, “죄송합니다”, “Error”, “Exception” 등의 단어가 응답에 포함되어 있는지만을 정규표현식(Regex)으로 필터링한다.

graph TD
    subgraph SUT Output Space
        O1[System Output <i>y</i> \n (e.g., JSON response)]
    end

    subgraph The True Oracle (Ideal but Impossible)
        TO{Is <i>y</i> exactly mathematically \n and logically correct?}
    end

    subgraph The Partial Oracle (Realistic Compromise)
        direction LR
        P1{Check 1: \n Is <i>y</i> a valid JSON?}
        P2{Check 2: \n Is <i>y.price > 0</i>?}
        P3{Check 3: \n Does <i>y.message</i> not contain 'null'?}
    end

    O1 -.->|Cost: 🚀 Infinite| TO
    O1 -->|Cost: 📉 Linear/Cheap| P1
    P1 -->|Pass| P2
    P2 -->|Pass| P3
    P3 -->|Pass| Ok((PARTIAL \n PASS))

    classDef ideal fill:#fdd,stroke:#d00,stroke-dasharray: 5 5;
    classDef real fill:#efe,stroke:#3c3,stroke-width:2px;
    
    class TO ideal;
    class P1,P2,P3,Ok real;

2. 비용 타협의 대가: 오라클의 누수(Oracle Leakage)와 리스크

부분 오라클은 테스트 자동화 파이프라인(CI/CD)을 빠른 속도로 가동할 수 있게 해주는 필수적인 윤활유다. 그러나 정답의 깊이를 타협한 대가로 엔지니어들은 치명적인 논리 결함이 통과되어 버리는 극심한 오라클 누수(Oracle Leakage) 현상을 감내해야 한다.

위음성(False Negative)의 지옥: 부분 오라클 환경에서 ’테스트 성공(Pass)’은 “시스템이 완벽하게 돌아간다“는 뜻을 잃어버리고, “운 좋게 오라클의 듬성듬성한 그물망(Boundary Check)을 피해서 작동했다“는 의미로 격하된다. 이는 버그가 운영 환경(Production)까지 무사통과하는 치명적인 위음성 지표 상승을 부른다.
검증의 환상(Illusion of Verification): 수천 개의 부분 오라클을 욱여넣어 테스트 커버리지(Test Coverage)를 100%로 달성했을지라도, 본질적인 도메인 정확도(Semantic Accuracy)는 하나도 검증되지 않은 껍데기뿐인 커버리지일 확률이 높다. 시스템의 품질(Quality)을 거짓으로 평온하게 위장하는 환상을 만든다.

3. 소결: AI 검증의 1차 바리케이드로서의 재조명

과거 수리적 정확성이 생명인 금융, 항공 도메인에서 부분 오라클은 멸시받는 ‘저품질(Low-fidelity)’ 오라클의 대명사였다. 그러나 수십 차원의 문맥과 파라미터를 갖춘 LLM 인공지능이 등장하면서 상황이 반전되었다.

AI의 대화 생성 로직은 앞서 규정한 ’테스트 불가능 코드’이므로, 인간 오라클(Human Oracle)을 투입하기 전 첫 번째 방어선으로 부분 오라클을 세울 수밖에 없다. **“완벽한 문장인지는 모르겠지만, 적어도 JSON 포맷으로 떨어졌고, 비속어 필터는 피해 갔다”**는 사실 하나만으로 부분 오라클은 AI 애플리케이션의 할루시네이션(Hallucination) 폭발을 일차적으로 억제하는 가장 현실적이고 강력한(가성비 높은) 타협안이 되었다.

하지만 이조차도 ’진정한 의미’를 사유하지는 못하기에, 결국 마지막 검증의 짐은 인간의 뇌 연산이라는 최악의 병목, **‘인간 오라클(Human Oracle)’**에게 떠넘겨지게 된다. 다음 절에서는 테스트 자동화 구조를 근본에서부터 역행시켜 버리는 이 지독한 병목 현상을 파헤친다.