2.3.1. 오라클 문제의 정의: 예상 결과를 산출하기 어렵거나 불가능한 상황

소프트웨어 테스팅의 가장 근본적인 전제는 “시스템에 특정 입력(Input)을 주었을 때, 시스템이 뱉어내야 하는 정답(Expected Output)을 엔지니어가 사전에 알고 있다“는 것이다. 그러나 현대의 정보 공학이 과학 시뮬레이션, 빅데이터 분석, 그리고 인공지능(AI)의 영역으로 확장되면서, 이 단순하고 당연해 보이는 대전제가 무너지기 시작했다.

학계에서는 테스트 대상 시스템(SUT)에 주어질 입력 $\vec{x}$ 에 대하여 올바른 결과 $\vec{y}$ 를 결정하는 알고리즘이나 메커니즘이 존재하지 않거나, 혹은 존재하더라도 정답을 도출하기 위한 공학적 비용이 현실적으로 불가능에 가까운 상황을 일컬어 **‘오라클 문제(The Oracle Problem)’**라고 정의한다.

본 절에서는 소프트웨어 자동화의 진형을 무너뜨리는 이 오라클 문제의 학술적 정의를 명확히 하고, 정답의 산출이 불가능해지는 근원적인 원인 계층을 분석한다.

1. 오라클 문제의 수학적 맥락과 붕괴 메커니즘

시스템을 함수 $f(x)$ 로 추상화하고, 테스트 입력 변수를 $x_i$ , 무결한 정답을 반환하는 가상의 참 오라클(True Oracle)을 $O(x)$ 라고 할 때, 일반적인 테스트 판독 메커니즘은 $f(x_i) \equiv O(x_i)$ 를 증명하는 과정이다.

여기서 오라클 문제가 발생한다는 것은 함수 $O(x_i)$ 자체를 구성하는 것이 불가능(Uncomputable) 하거나 실현 불가능(Infeasible) 해졌음을 의미한다. 이로 인해 테스트 파이프라인은 다음과 같은 거대한 단절을 겪게 된다.

입력 생성의 비대칭: 무작위 입력 생성기(Fuzzer)나 테스트 스크립트를 통해 $x_1, x_2, \dots, x_n$ 을 생성하고 시스템 $f(x)$ 를 가동하는 데는 마이크로초(Microsecond)밖에 걸리지 않는다.
정답 매핑의 단절: 반면, 생성된 수만 개의 $x$ 에 1:1로 대응하는 정답 집합 $y_1, y_2, \dots, y_n$ 을 매핑해 줄 오라클 함수 $O(x)$ 가 존재하지 않기 때문에, SUT가 도출한 결과가 올바른지 논리적으로 증명할 수단이 완전히 소멸된다.

graph TD
    subgraph Traditional Testing Flow
        I1[Test Input <i>x</i>] --> SUT1(System Under Test)
        I1 --> TO(True Oracle <i>O(x)</i>)
        SUT1 --> A1[Actual Output]
        TO --> E1[Expected Output]
        A1 --> Comp1{Comparator \n <i>A = E?</i>}
        E1 --> Comp1
    end

    subgraph The Oracle Problem
        I2[Test Input <i>x</i>] --> SUT2(System Under Test)
        I2 --> Missing[⛔ Oracle Function Missing \n or Too Complex]
        SUT2 --> A2[Actual Output]
        Missing -.->|Cannot Derive| E2[??? Unknown Expected Output]
        
        A2 --> Comp2{Comparator \n 판독 불가}
        E2 -.-> Comp2
    end
    
    style Missing fill:#fdd,stroke:#d00,stroke-width:2px;
    style E2 fill:#fdd,stroke:#d00,stroke-width:2px,stroke-dasharray: 5 5;

2. 예상 결과를 산출하기 불가능해지는 3가지 근원 영역

오라클 문제는 단순히 요구사항 명세서(Requirements)를 부실하게 작성하여 정답을 모르는 개발자의 나태함에서 비롯되는 것이 아니다. 이는 특정 도메인이 가지는 내재적 복잡도(Inherent Complexity)에 기인한다. 학계에서는 오라클 문제를 발생시키는 주요 원인을 크게 세 가지로 분류한다.

2.1 인지적/논리적 불가능성 (Logical / Cognitive Impossibility)

가장 대표적으로 기계 학습(Machine Learning) 프로세스와 그래픽 비전(Vision) 알고리즘이 여기에 속한다.

고양이를 판별하는 AI 비전 모듈에 새로운 사진 1만 장(Test Inputs)을 집어넣었다고 가정해 보자. 이 사진들에 고양이가 있는지 없는지를 100% 장담하는 기계적 참 오라클 공식을 수학적으로 작성할 수 있는가? 불가능하다. 정답을 매핑할 수 있는 유일한 매체는 사진을 일일이 확인하는 ’인간의 뇌(Eyeballing)’뿐이다.
기계 번역이나 챗봇의 자연어 생성(NLG) 역시 “어떤 문장이 가장 자연스러운가?“라는 주관적이고 인지적인 영역에 속하므로, 연역적 계산을 통한 예상 결과 산출이 원천적으로 차단된다.

2.2 복잡계 및 거대 시뮬레이션의 비선형성 (Complexity in Simulations)

입력 변수들이 서로 비선형적(Non-linear)으로 상호작용하여 결과를 도출하는 화학 반응 시뮬레이터, 기동 역학 프레임워크, 기상 예측 모델 등이다.

수백만 개의 나비 효과 변수가 반영된 기상 예측 프로그램(SUT)이 “내일의 강수 확률 $45.2\%$ “를 뱉어냈을 때, 이것이 “정답“이라고 어떻게 확신할 수 있는가? 오라클이 정답을 산출하려면 SUT보다 훨씬 더 정교하고 완벽하게 우주를 흉내 내는 또 다른 아키텍처를 만들어야 하는데, 이는 앞 절에서 배운 ’재창조의 역설(Paradox of Re-creation)’에 당면하여 사실상 불가능하다.

2.3 경제적 계산 제약 (Economic and Practical Infeasibility)

알고리즘적으로 정답을 역산할 수 있다는 것을 수학적으로 증명할 수는 있으나, 그 연산에 소모되는 자원이 지구상의 컴퓨팅 파워를 초과하거나 비즈니스적 가치를 아득히 뛰어넘는 경우다.

예를 들어 NP-난해(NP-Hard)에 속하는 최적화 문제(외판원 순회 문제, 대규모 물류 배차 최적화 등) 로직을 테스트할 경우, 시스템이 도출한 경로가 “절대적으로 최단 경로인가?“를 검증하는 오라클은 무차별 대입(Brute-force) 연산을 돌려야만 정답을 알 수 있다. 결과 검증에 수십 년이 걸린다면 이는 실현 불가능(Infeasible)한 오라클 문제로 판별된다.

3. 소결: AI 패러다임이 맞이한 재앙적 딜레마

과거의 엔지니어들은 이 오라클 문제를 만날 때마다 도메인을 축소하거나 휴리스틱(Heuristic) 오라클을 사용해 교묘하게 피해왔다. 기상 시뮬레이션이나 암호화 테스팅은 전체 소프트웨어 산업에서 소수의 하드코어 특수 분야였기 때문이다.

그러나 생성형 AI(Generative AI)가 등장하면서, 이 오라클 문제는 더 이상 특수한 과학계의 학술적 난제가 아니라 평범한 마이크로서비스(MSA) 백엔드 개발자와 프론트엔드 엔지니어의 일상을 파괴하는 거대한 보편적 재앙으로 다가왔다. LLM이 생성하는 예측 불가능한 텍스트 응답 하나하나가 철저한 오라클 문제의 한복판에 위치하기 때문이다.

우리는 이 문제를 본질적으로 회피할 수 없음을 인정해야 한다. 바로 이어질 하위 절들에서는 이 절망적인 지점을 파고들어, ’테스트 불가능한 프로그램(Non-testable Programs)’의 한계와 정답을 창출하려는 행위가 어떻게 비즈니스를 파산으로 이끄는 ’오라클 비용’을 유발하는지 집중 조명한다.