2.2.5. 파생 오라클(Derived Oracle): 기존 시스템이나 대체 알고리즘의 결과를 정답으로 간주

새로운 알고리즘이나 프레임워크를 개발할 때, 수학적 명세(Specification)를 하나하나 코드로 역변환하여 참 오라클(True Oracle)을 빚어내는 것은 천문학적인 시간과 비용을 소모한다. 이러한 공학적 교착 상태에서 실무자들은 매우 영리하고 우회적인 접근법을 도입했는데, 그것이 바로 ‘파생 오라클(Derived Oracle)’ 혹은 ’의사 오라클(Pseudo-Oracle)’이라 불리는 기법이다.

파생 오라클의 철학은 “정답지를 처음부터 새로 만들 필요 없이, 이미 시장에서 검증되었거나 다른 방식으로 개발되어 신뢰성을 확보한 기존 시스템의 산출물을 그대로 우리의 정답으로 편입(Derive)시키자“는 데 있다. 본 절에서는 파생 오라클의 개념적 정의와 N-Version 프로그래밍, 그리고 섀도우 테스팅(Shadow Testing)과 같은 실무 적용 기법들을 상세히 해부한다.

1. 파생 오라클의 개념과 성립 조건

파생 오라클체계는 테스트 대상 시스템(SUT)과 동일한 목적을 수행하는 **대체 시스템(Alternative System)**을 진리의 원천으로 상정한다. 동일한 입력 $x$ 를 SUT와 대체 시스템 $S_{alt}$ 에 동시에 주입한 뒤, $S_{alt}$ 의 결괏값을 무결한 기대 결과(Expected Result)로 간주하여 비교 연산을 수행한다.

$\text{If } SUT(x) \not\equiv S_{alt}(x) \text{ then } \text{FAIL (SUT contains a defect)}$

이 판독 기제가 파국으로 치닫지 않고 정상 성립하기 위해서는 다음 두 가지 엄격한 공학적 전제 조건이 충족되어야 한다.

독립적 구현(Independent Implementation): SUT와 $S_{alt}$ 는 알고리즘의 논리적 전개 방식, 프로그래밍 언어, 혹은 개발팀이 철저히 분리(Decoupled)되어 있어야 한다. 동일한 코드를 복사해서 쓴다면 두 시스템이 완벽히 동일한 버그(Bug)를 공유하게 되므로, 오라클로서의 상호 교차 검토(Cross-validation) 의미가 상실된다.
$S_{alt}$ 의 상대적 무결성: 대체 시스템 $S_{alt}$ 가 완벽한 참 오라클일 필요는 없으나, 최소한 SUT보다는 오랜 기간 운영 환경(Production)에서 구동되며 신뢰도(Confidence Level)를 검증받은 레거시(Legacy) 시스템이어야 한다.

2. 파생 오라클의 핵심 구현 패턴

실무 소프트웨어 공학에서 파생 오라클은 시스템 이관(Migration)과 마이크로서비스 리팩터링 환경에서 결코 빠질 수 없는 검증 표준으로 자리 잡았다.

2.1. 다중 버전 프로그래밍 (N-Version Programming)

항공 우주 제어나 원자력 발전소 등 치명적(Safety-critical) 시스템에서 주로 쓰이는 기법이다. 완전히 동일한 요구사항 명세서를 3개의 각기 다른 개발팀(A, B, C)에게 나누어 주고, 서로 다른 언어와 논리로 3개의 프로그램(버전)을 개발하게 한다.
테스트 시나리오에서 시스템 A를 SUT로 삼을 때, 시스템 B와 C의 결괏값을 결합하여(예: 다수결 투표, Majority Voting) A를 평가하는 파생 오라클로 활용한다. 이 기법은 한 팀의 논리적 오류가 다른 팀의 로직으로 교차 검증된다는 점에 기인한다.

2.2. 섀도우 테스팅 (Shadow Testing / Parallel Run)

모놀리식(Monolithic) 아키텍처를 MSA(Microservices Architecture)로 마이그레이션할 때 필수적인 패턴이다.
과거의 구형 RDBMS 로직(레거시)을 $S_{alt}$ 로, 신규 개발된 클라우드 기반 로직을 SUT로 설정한다. 운영 환경으로 들어오는 실제 사용자 트래픽(Input)을 복제(Mirroring)하여 두 시스템에 동시에 흘려보낸다. 사용자는 기존 레거시 시스템의 응답만 받게 되므로 안전이 보장되며, 백그라운드에서는 파생 오라클 연산기가 두 시스템의 DB 상태 변이(State Mutation)를 1:1로 비교하여 신규 SUT 로직의 정합성을 검증한다.

graph TD
    subgraph Production Traffic
        U[Real User Requests <i>i</i>] --> Router{Traffic Router / Proxy}
    end

    subgraph Dual Execution Engine
        Router -->|Live Traffic| Legacy[Legacy System <i>S_alt</i>\n(파생 오라클의 원천)]
        Router -->|Mirrored Traffic| SUT[New Microservice\nSUT (System Under Test)]
    end

    Legacy -->|Serves User| U_Res[User Response]
    
    Legacy -.-> O_Legacy[Trusted Output <i>y_t</i>]
    SUT --> O_SUT[Actual Output <i>y_a</i>]

    subgraph Derived Oracle Sub-system
        O_Legacy --> Comp{결과 비교기\nComparator}
        O_SUT --> Comp
        
        Comp -->|<i>y_t</i> \u2261 <i>y_a</i>| Pass[무결점 동기화]
        Comp -->|<i>y_t</i> \u2260 <i>y_a</i>| Fail[SUT 로직 결함 발견!\n경고 발생]
    end

    classDef legacy fill:#eef,stroke:#33c,stroke-width:2px;
    classDef sut fill:#eff,stroke:#3cc,stroke-width:2px;
    classDef alert fill:#fdd,stroke:#d00,stroke-width:2px;

    class Legacy legacy;
    class SUT sut;
    class Fail alert;

3. 파생 오라클의 치명적 함정: 공통 원인 고장 (Common Cause Failure)

언뜻 보기에 파생 오라클 체계는 구현 비용이 저렴하고 즉시 대규모 테스트 데이터(Production Traffic)를 부을 수 있어 완벽해 보이지만, 공학자들은 이데 내재된 거대한 리스크를 **공통 원인 고장(Common Cause Failure, CCF)**이라 부른다.

동일한 지식의 오염: SUT와 레거시 시스템( $S_{alt}$ )이 서로 다른 언어나 프레임워크로 작성되었다 하더라도, 두 시스템을 작성한 개발자들이 동일한 논문, 동일한 오해의 소지가 있는 스택오버플로우(StackOverflow) 코드, 혹은 모호성이 가득한 동일한 명세서(Specification)를 기반으로 코딩을 진행했다면 어떻게 될까?
침묵의 카르텔(Cartel of Silence): 두 시스템은 동일한 “설계상의 치명적 버그“를 나란히 공유하게 된다. 이 경우 입력이 들어왔을 때 두 시스템 모두 ’똑같이 틀린 결괏값’을 도출한다 ( $SUT_{buggy}(x) \equiv S_{alt\_buggy}(x)$ ). 파생 오라클의 비교기(Comparator)는 두 값이 일치(\equiv)한다는 이유만으로 테스트 통과(Pass) 라는 최악의 오진(False Negative)을 합법화해버린다.

4. 소결: AI 패러다임 전환기에서의 레거시 재활용

파생 오라클 접근법은 기존 룰 베이스(Rule-based) 소프트웨어를 최신 생성형 AI 아키텍처로 대체하려는 오늘날의 테크 업계에서 폭발적으로 재평가받고 있다.

과거 검색 엔진의 추천 로직(결정론적 알고리즘)을 RAG(Retrieval-Augmented Generation) 기반의 AI 챗봇 시스템(비결정적 알고리즘)으로 마이그레이션 한다고 가정해 보자. 이 AI 챗봇이 사실에 입각한 온전한 정보를 제공하는지(Hallucination 방지) 판단하기 위한 가장 저렴하고 압도적인 검증 방어막은, 기존 검색 엔진이 내뿜던 결과 집합(Top-N Links)을 파생 오라클로 삼아 챗봇의 응답과 의미론적으로 교차 검증하는 것이다.
비록 공통 원인 고장(CCF)이라는 맹점이 존재하지만, 비결정성(Nondeterminism)이 쏟아내는 혼돈을 통제하기 위해 기존 결정론적 유산(Legacy)을 정답지 삼아 역이용하는 것은 여전히 실무에서 가장 타당한 공학적 해답으로 기능한다.