2.1.4. 명세 기반(Specification-based) 오라클과 구현 기반(Implementation-based) 오라클

2.1.4. 명세 기반(Specification-based) 오라클과 구현 기반(Implementation-based) 오라클

테스트 오라클이 정답 레이블(Ground Truth)을 합성하고 도출해 내기 위해서는 반드시 그 ’진실의 기준점’이 될 원천 자료 체계가 필요하다. 소프트웨어 테스팅 분과에서는 이 기대 결과(Expected Result)를 연역해 내는 추론의 성격과 정보의 출처에 따라 오라클을 크게 두 가지 범주로 분류한다. 바로 명세 기반 오라클(Specification-based Oracle) 과 구현 기반 오라클(Implementation-based Oracle) 이다.

두 오라클 체계는 시스템을 검증하는 철학적 기조가 상이하며, 향후 AI 및 대규모 언어 모델(LLM) 기반의 기능들을 테스트할 때 각기 다른 한계점과 적용 가능성을 지닌다. 본 절에서는 두 체계의 공학적 정의를 명확히 하고, 상호 보완적으로 작동하는 원리를 규명한다.

1. 명세 기반 오라클 (Specification-based Oracle)

명세 기반 오라클은 테스트 대상 시스템(SUT) 내부 구조를 전혀 알지 못하는 블랙박스(Black-box) 상태에서, 시스템이 “무엇을(What) 수행해야 하는가“를 규정한 외부 설계 문서를 진리값의 원천으로 삼는 오라클 체계다.

  • 정보의 원천: 요구사항 명세서(Requirements Specification), UML 설계도, 데이터베이스 상태 전이 다이어그램, OpenAPI(Swagger) 명세서, 사용자 매뉴얼 등 외부에서 정의되고 합의된 절대적 규율.
  • 작동 메커니즘: SUT가 구현되기 이전에, 명시된 수식이나 상태 모델(State Model)을 기반으로 실행 가능한(Executable) 형태의 기계적 오라클로 변환된다. 예를 들어 “비밀번호는 반드시 8자리 이상, 특수문자를 1개 이상 포함해야 한다“는 설계 명세가 있다면, 오라클 시스템은 정규표현식(Regex)을 이용한 룰 엔진을 구축하여 SUT의 결과값을 검증한다.
  • 장점과 한계: SUT의 실제 프로그래밍 언어나 구현 로직에 종속되지 않으므로 가장 객관적인(Objective) 참거짓을 판별할 수 있다. 그러나 ’자연어(Natural Language)’로 작성된 명세서의 모호성 문제로 인해, 복잡한 비즈니스 로직을 자동화된 단일 명세 오라클로 100% 매핑하는 것은 불가능에 가깝다. 더욱이 “문장을 요약하라“는 식의 AI 태스크에서는 명백한 ‘명세’ 자체를 수학적으로 기재하기 어렵다는 치명적인 한계에 직면한다.

2. 구현 기반 오라클 (Implementation-based Oracle)

명세 기반 오라클이 “시스템이 수행해야 할 설계 목적“을 검증한다면, 구현 기반 오라클은 시스템의 “어떻게(How) 동작하고 있는가“라는 구체적인 논리 흐름(Logical Flow)과 코드 자체의 무결성에 진리값의 기반을 둔 화이트박스(White-box) 및 그레이박스(Gray-box) 접근법이다.

  • 정보의 원천: SUT의 소스 코드(Source Code), 이전 버전의 레거시(Legacy) 코드베이스, 혹은 시스템 내부에서 상태를 전이시키는 디자인 패턴(Design Pattern).
  • 작동 메커니즘: 대표적인 예가 슈도 오라클(Pseudo-Oracle) 혹은 N-Version 프로그래밍이라 불리는 기법이다. 완전히 동일한 요구사항을 기존의 안정된 레거시 시스템 S_1과 새롭게 작성된 SUT S_2에 동시에 입력한 뒤, 양쪽의 출력이 정확히 \equiv 을 이루는지 비교한다. 또한 단위 테스트(Unit Test)에서 개발자가 내부 클래스의 상태 변화(예: 변수 값의 증감)를 직접 Assert 문으로 하드코딩하는 것 역시 구현 기반 오라클의 행위이다.
  • 장점과 한계: 복잡한 정적 사양서를 기계어로 번역하는 수고 없이, 기존의 신뢰받는 코드를 그대로 정답 계산기로 역이용(Reverse-use)할 수 있어 대규모 자동화에 효율적이다. 그러나 만약 기준이 되는 이전 버전의 코드 자체에 은닉된 버그가 내재하고 있거나, 새롭게 도입된 기능(Feature)이 기존 방식과 의도적으로 달라야만 한다면 구현 기반 오라클 자체가 오판(False Alarm)을 양산하는 부채(Debt)로 전락한다.

3. 두 오라클의 상호 보완적 아키텍처

실무의 엔터프라이즈 환경에서는 단 하나의 오라클 범주만으로 견고한 파이프라인을 지탱할 수 없다. 비즈니스 룰과 같은 정적이고 변경할 수 없는 제약 조건은 명세 기반으로 통제하고, 알고리즘의 리팩터링(Refactoring) 최적화 등 형태는 바뀌어도 거시적 결과가 유사해야 하는 런타임 검증은 구현 기반으로 방어하는 듀얼 아키텍처(Dual Architecture)가 요구된다.

graph TD
    subgraph Specifications
        A(Business Requirements) -->|연역적 모델화\nDeductive| B[명세 기반 오라클\nSpecification-based]
        C(API Contracts / JSON Schema) --> B
    end
    
    subgraph Implementation Context
        D(Stable Legacy System\nPrevious Version) -->|상대적 동치성 계산\nRelative/Regression| E[구현 기반 오라클\nImplementation-based]
        F(Internal Unit Modules) --> E
    end

    subgraph SUT Execution Boundary
        G[Input Data <i>i</i>] --> H[System Under Test\nVibe & Probability]
        H -.-> I[Actual Result]
    end

    I -->|Rule Violation Check| B
    I -->|Consistency Check| E
    
    B -->|Pass/Fail| J((Final Verdict\nCI/CD Halt))
    E -->|Pass/Fail| J

    classDef spec fill:#eef,stroke:#33c,stroke-width:2px;
    classDef impl fill:#efe,stroke:#3c3,stroke-width:2px;
    
    class A,C,B spec;
    class D,F,E impl;

4. 소결: AI 패러다임이 던지는 새로운 도전장

전통적 테스팅에서는 이 두 가지 오라클 체계의 톱니바퀴가 비교적 매끄럽게 맞물려 돌아갔다. 그러나 챗봇, 자동 코드 생성기, RAG 시스템 등의 AI 모듈 앞에서는 이 두 체계 모두 근원적 도전에 직면한다.

자연어의 맥락적 응답은 명확한 ’명세(Specification)’로 추출할 공식이 부재하고, AI의 통계 확률 계산 모델은 하드코딩 방식의 ’구현(Implementation)’으로 대조하기에는 그 상태 공간의 폭발(State Explosion) 현상이 너무 거대하기 때문이다. 두 오라클의 본질적 강점과 교착 상태를 인지하는 것은, 향후 우리가 구성해야 할 “AI를 역이용하는 하이브리드 오라클“이나 “강제 구조화 포맷(Structured Output)“의 절대적 필요성을 규명하는 훌륭한 이론적 교두보가 될 것이다.