2.3.2. 테스트 불가능한 프로그램(Non-testable Programs)의 특징

2.3.2. 테스트 불가능한 프로그램(Non-testable Programs)의 특징

오라클 문제(The Oracle Problem)가 극단으로 치달을 때, 우리는 소프트웨어 공학에서 가장 마주하기 싫은 개념인 **‘테스트 불가능한 프로그램(Non-testable Programs)’**이라는 학술적 장벽을 만나게 된다. 소프트웨어 테스팅의 선구자인 엘레인 웨유커(Elaine Weyuker)가 1982년 논문 “On Testing Non-testable Programs“에서 처음 제시한 이 개념은, 코드를 물리적으로 실행할 수 없다는 뜻이 아니다. 코드를 컴파일하고 실행하여 결괏값을 눈으로 볼 수는 있으나, 그 결괏값이 ’올바른지’를 객관적이고 연역적인 오라클로 증명할 수 없는 프로그램 부류를 의미한다.

본 절에서는 프로그램이 어떠한 본질적 특성을 가질 때 ’테스트 불가능’의 영역으로 추락하는지 분석하고, 전통적 공학 방법론이 이러한 특성들 앞에서 왜 무력화되는지를 살펴본다.

1. 테스트 불가능성을 규정하는 3대 본질적 특징

프로그램이 스스로를 오라클의 영역 밖으로 밀어내는 주요 특징은 다음과 같이 크게 세 가지로 요약된다.

1.1 정답의 비연역성 (Non-deducibility of the Ground Truth)

가장 핵심적인 특징은 시스템의 명세서(Specification)나 도메인 지식으로부터 수학적인 정답을 도출(Deduce)해 낼 방법이 전무하다는 점이다.

  • 일반적인 세금 계산기 프로그램은 입력값(연봉, 세율)이 주어지면 곱셈과 덧셈이라는 연역적 과정을 통해 유일무이한 정답을 산출할 수 있다(테스트 가능).
  • 반면, ‘고객의 이탈 확률을 예측하는 추천 알고리즘’ 이나 ‘한국어 문장의 미묘한 뉘앙스를 번역하는 엔진’ 은 어떠한가? 고객이 실제로 해지할 때까지, 혹은 원어민이 그 문장을 읽고 감성적으로 “자연스럽다“고 느낄 때까지 우리는 그것이 정답인지 절대 알 수 없다. 결과를 산출하는 방정식 자체가 존재하지 않기 때문이다.

1.2 허용 공간의 무한성 (Infinity of the Plausible Space)

테스트 불가능한 프로그램은 하나의 고정된 스칼라(Scalar) 정답이 아니라, 무한히 넓은 ‘허용 공간(Plausible Space)’ 안에 들어오는 수많은 출력을 모두 정답으로 인정해야 하는 특성을 지닌다.

  • 기존의 결정론적 시스템은 출력 y 가 사전 정의된 정답 상수 C 와 정확히 일치(y \equiv C)하는지만 확인하면 되었다.
  • 그러나 자율주행 자동차의 핸들 꺾임 각도, 비정형 데이터를 요약하는 생성형 언어 모델의 텍스트 길이는 본질적으로 연속적(Continuous)이며 무한한 자유도를 지닌다. 수만 개의 다른 문장이나 다른 조향 각도 모두가 ’적절한 정답’일 수 있으므로, 어떤 것이 가장 완벽한 참인지 하나로 특정하는 오라클을 구축할 수 없다.

1.3 입력의 극단적 민감성과 비선형성 (Extreme Sensitivity & Non-linearity)

카오스 이론(Chaos Theory)이 지배하는 시스템처럼, 입력값의 미세한 변화가 결과에 예측할 수 없는 엄청난 변동을 유발한다.

  • 날씨 예측 시뮬레이터나 유체 역학 모델의 경우, 습도 입력값을 0.001%만 변경해도 10일 뒤의 예측 결과는 ’가뭄’에서 ’태풍’으로 완전히 뒤집힐 수 있다.
  • 이러한 시스템에서는 결과가 너무나 급진적으로 변론하므로 역함수를 구하여 원래의 입력을 추적(Back-tracking)하는 것도 불가능하며, 이전 실행 결과와 비교하는 일관성 오라클(Consistency Oracle)마저 완전히 붕괴하게 된다.

2. 테스트 불가능성의 스펙트럼

어떤 시스템도 처음부터 끝까지 100% 테스트가 불가능한 것은 아니다. 시스템 내부 구조에 따라 특정 모듈은 완벽히 테스트(Testable) 가능하며, 또 다른 모듈은 깊은 오라클 문제(Non-testable)에 빠져 있을 수 있다.

graph LR
    subgraph Testability Spectrum
        direction LR
        A[완전한 테스트 가능\n(Fully Testable)] --> B[부분적 테스트 가능\n(Partially Testable)]
        B --> C[테스트 불가능\n(Non-testable)]
    end

    A -.->|특징| F1[수학적 연역 함수\n명확한 상태 전이\n유한한 입력/출력]
    B -.->|특징| F2[근사치 허용 범위\n알려진 알고리즘 변형\n휴리스틱 기반 판독]
    C -.->|특징| F3[인지/감성적 판단 의존\n카오스/비선형적 특성\n다중 정답 허용 공간]

    subgraph Domain Examples
        direction TB
        E1(계산기, 급여 관리, RDBMS) 
        E2(검색 엔진, 압축 알고리즘) 
        E3(기계 번역, 기상 예측, LLM)
    end
    
    A === E1
    B === E2
    C === E3

    classDef high fill:#efe,stroke:#3c3,stroke-width:2px;
    classDef mid fill:#ffeda0,stroke:#f0a020,stroke-width:2px;
    classDef low fill:#fdd,stroke:#d00,stroke-width:2px;
    
    class A high;
    class B mid;
    class C low;

3. 테스트 불가성에 맞서는 현실적 방어 기제 (Pseudo-Testing)

전통적인 관점의 테스트 판독(Pass/Fail)이 불가능하다면 공학자들은 이 프로그램을 포기해야만 할까? 그렇지 않다. 엘레인 웨유커(E. Weyuker)는 이러한 비관적 시스템을 검증하기 위해 전통적 오라클을 우회하는 ‘방사형 테스트(Pseudo-testing)’ 기법들을 구상했다.

  • 메타모픽 테스팅 (Metamorphic Testing): 앞선 절에서 살펴보았듯, 정답 자체를 모른다면 입력에 대한 조작(Morphing)이 출력에 미치는 일관성(Relation)만을 간접적으로 증명한다.
  • 동위 객체 교차 검증 (Cross-validation with Peers): 동일한 문제를 푸는 다른 비결정적 시스템(예: 다른 기상 예측 모델)의 결과를 파생 오라클(Derived Oracle)로 삼아 편차(Deviation)를 분석한다. 시스템이 ’틀렸다’고 단정하는 대신 ’다른 모델들과 거리가 멀다’고 평가하는 것으로 타협한다.

4. 소결: 거대 언어 모델(LLM)은 역사상 가장 완벽한 테스트 불가능 프로그램

웨유커가 논문을 발표했던 1980년대에 테스트 불가능한 프로그램은 그저 일부 특수한 물리 시뮬레이터나 복잡한 병렬 시스템에 국한된 이론적 모델에 지나지 않았다.

그러나 21세기, 우리는 인류 역사상 가장 거대하고 완벽한 형태의 테스트 불가능 프로그램, 바로 대규모 언어 모델(LLM) 기반의 생성형 AI에 직면하게 되었다. LLM은 정답의 비연역성(창의적 텍스트), 허용 공간의 무한성(같은 질문에 매번 다르게 대답함), 입력의 비선형성(프롬프트 단어 하나에 응답 구조가 완전히 붕괴됨)이라는 3대 악조건을 모두 갖추고 있다.

이러한 궁극의 테스트 불가성을 공학적 효율선상에서 통제하기 위해서는 필연적으로 천문학적인 ’오라클 계산 비용’을 지불해야만 한다. 다음 절에서는 시스템의 기능 구현 자체보다 배보다 배꼽이 더 커지게 되는 ‘오라클 비용(Oracle Cost) 폭발’ 에 대해 탐구할 것이다.