2.1.5. 오라클 정보의 원천: 요구사항 문서, 도메인 지식, 레거시 시스템, 사용자 기대치

소프트웨어 시스템이 기대하는 바에 따라 정상적으로 동작하는지를 기계적으로 판별해 내는 오라클(Oracle)은, 결국 “정답은 무엇이어야 하는가?“라는 물음을 해결하기 위해 공학적 진실의 근원(Source of Truth)을 확보해야 한다. 오라클은 무에서 유를 창조하는 마법의 상자가 아니며, 시스템 명세나 외부 지식 체계를 코드로 번역하고 모델링(Modeling)한 결과물일 뿐이다. 따라서 오라클 프레임워크의 질적 성취와 검증 커버리지(Coverage)는 이 ’오라클 정보의 원천(Sources of Oracle Information)’을 얼마나 정확하게 확보하고 시스템화하느냐에 전적으로 달려있다.

본 절에서는 테스트 오라클이 정답 레이블(Ground Truth)을 합성하기 위해 참거짓의 근거로 삼는 4대 핵심 정보 원천—요구사항 문서, 도메인 지식, 레거시 시스템, 그리고 사용자 기대치—을 상세히 해부한다.

1. 요구사항 문서 및 명세서 (Requirements & Specifications)

소프트웨어 엔지니어링의 정석에 비추어 볼 때, 가장 객관적이고 우선순위가 높은 오라클의 원천은 바로 시스템 설계 단계에서 도출된 문서들이다.

상태 머신과 수리적 룰(Mathematical Rules): “대출 자격 심사 모듈은 신용 점수 $x \geq 700$ 이고 대출금 $y \leq 5000$ 일 때만 승인(True)을 반환해야 한다“와 같은 비즈니스 룰 엔진이나 결정표(Decision Table)는 모호성이 배제되어 있어, 자동화된 단위 테스트(Unit Test)의 Assertion 구문으로 1:1 직역(Translation)이 가능하다.
API 컨트랙트(Contracts): OpenAPI(Swagger)나 JSON Schema 명세는 시스템의 반환값이 지켜야 할 타입(Type)과 구조(Structure)의 완벽한 잣대가 되며, 이를 오라클 정보로 활용할 경우 프로토콜 수준의 정합성을 기계적으로 확정 지을 수 있다.
한계점: 이들은 완벽하지만 경직되어 있다. 자연어 문장이나 인간의 감성, 이미지 등 명시적 다이어그램으로 규정할 수 없는 AI 시스템의 비정형(Unstructured) 응답 앞에서는 잣대 자체가 무력화된다.

2. 도메인 지식 및 과학적 공리 (Domain Knowledge & Axioms)

모든 소프트웨어 로직을 텍스트 기반 명세서로 남길 수는 없다. 때로는 해당 시스템이 포괄하는 산업 도메인의 근본적인 절대 지식(Axioms)이나 물리 법칙이 거시적인 오라클로 작용한다.

도메인 제약(Domain Constraints): 의료 기록 처리 시스템에서 환자의 ’퇴원일’이 ’입원일’보다 과거일 수 없다는 사실이나, 금융 트랜잭션에서 ’잔고는 음수가 될 수 없다(마이너스 통장 제외)’는 등의 지식은 명세서에 명시되어 있지 않더라도 테스트 오라클 생성기(Generator)가 반드시 도출해 내야 하는 본질적인 참값의 필터(Filter)로 작용한다.
속성 기반 테스팅(Property-based Testing): 앞서 설명한 도메인 지식을 프로그래밍 영역으로 가져온 것이 바로 속성(Property) 기반의 오라클이다. 예를 들어 배열 정렬(Sorting) 알고리즘을 테스트할 때, 정확히 배열 내 요소가 어떤 순서로 배치될지(입력값 기반 Ground truth)는 몰라도 “출력 배열의 길이는 입력과 같아야 하며, 인덱스 $n$ 의 값은 항상 $n+1$ 의 값보다 작거나 같아야 한다“는 공리에 기반하여 시스템을 판정할 수 있다.

3. 기존 레거시 시스템 (Legacy Systems / Reference Models)

실무 환경(Production)에서 신규 시스템이나 대규모 리팩터링(Refactoring) 파이프라인을 구축할 때 가장 값싸고 강력하게 활용할 수 있는 오라클의 원천이다.

의사 오라클 (Pseudo-Oracles): 동일한 목적을 지녔지만 구형 언어로 작성되었거나 구조가 낙후된 레거시 시스템(Reference System)을 진리값의 근원으로 재활용한다. 새로운 SUT와 낡은 Reference System에 동일한 입력을 가해 결과를 1:1로 비교(Comparator)하는 섀도우 테스팅(Shadow Testing) 기법이 여기에 속한다.
AI 도입 시의 기준점: 향후 AI 기반 솔루션으로 마이그레이션(Migration)할 때, AI가 만들어낸 비결정적 산출물을 기존 RDBMS 기반의 결정적 시스템이 내뿜던 결과물과 비교하는 방식으로 오라클 프레임워크를 훈련시킬 수 있다. (예: 챗봇이 추천한 상품 리스트와, 기존 추천 알고리즘이 내뿜은 상품 리스트 간의 교집합 비율 검증 등)

4. 사용자 기대치 및 암묵적 동의 (User Expectations & Implicit Oracles)

시스템 명세나 명확한 코드로 정의할 수 없으나, 인간과 상호작용하는 시스템(HCI)이 반드시 따라야 할 암묵적인 잣대들을 의미한다.

암묵적 오라클(Implicit Oracles): 시스템은 실행 도중 “예기치 않게 종료(Crash)되어서는 안 되며”, “10초 이상 화면을 멈춰서(Hang)도 안 되고”, “운영 체제의 파일 디스크립터 시스템을 파괴해서도 안 된다.” 이것은 따로 명세 문서가 없더라도 어떤 시스템에나 공통적으로 적용되는 묵시적인 오라클 원천이다.
사용자의 감성적 잣대(Heuristic Expectation): UI/UX 환경, 비전(Vision) 렌더링 시스템, 언어 생성 등에서 “이 그림이 어색하지 않은가?”, “이 문장이 무례하지 않은가?“와 같이 오직 인간의 인지 능력으로만 정오를 판별할 수 있는 영역이다. 이 원천은 자동화의 가장 큰 난제였으며, AI가 생성한 ’무례한 고객 응대 챗봇 텍스트’를 기계적으로 잡아내지 못한 것도 이 암묵적 기대치를 코드 잣대(Logic)로 변환할 수 없었기 때문이다.

graph TD
    subgraph "Sources of Oracle Information"
        A[요구사항 문서 & 명세서\n(수학적 룰, API Schema)] 
        B[도메인 지식 & 공리\n(불변 속성, 물리 법칙)]
        C[레거시 시스템\n(이전 버전 비교, Pseudo Oracle)]
        D[사용자 기대치\n(Crash 방지, 감성적 Heuristic)]
    end

    A -->|연역적 검증 모델| E(Test Oracle Engine)
    B -->|속성 기반(Property) 필터| E
    C -->|회귀 및 상대적 동치성 대조| E
    D -->|암묵적 예외 통제 수준| E

    E --> F[결정론적 판별\n(Deterministic Verification)]

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

5. 소결: 파편화된 원천의 통합과 AI의 개입

성공적인 테스트 자동화 파이프라인은 단 하나의 오라클 원천에 의존하지 않는다. API의 타입 제약은 ’명세서’를 원천 삼아 통제하고, 데이터 전환의 1:1 대조는 ’레거시 시스템’을 원천 삼으며, 근원적인 비즈니스 금기 사항은 ’도메인 지식’을 원천으로 삼아 다층적인 방어망(Multi-layered Defense)을 구축해야만 한다.

그러나 기존의 정보 원천 4가지만으로는 앞마당에 닥친 AI 시스템의 비결정적 환각(Nondeterministic Hallucination) 현상을 견고하게 방어하기 역부족이라는 사실이 점점 명백해지고 있다. 사용자 기대치(감성, 뉘앙스)의 영역은 기계가 다루기엔 지나치게 추상적이었고, 명세 기반 방식은 지나치게 경직되어 있기 때문이다. 결국 우리는 파편화된 오라클 원천들을 통합하고, 확률에 숨겨진 진리가 우리의 명세 및 도메인 지식과 충돌하지 않도록 철저히 모니터링할 “AI 모델 자체를 오라클 정보의 새로운 원천으로 삼는 하이브리드 검증 기법(LLM-as-a-Judge)” 을 고안해내야 하는 운명을 맞이하게 된 것이다.