2.1.3. 테스트 대상(SUT)과 오라클 간의 상호작용 메커니즘

2.1.3. 테스트 대상(SUT)과 오라클 간의 상호작용 메커니즘

테스트 오라클(Test Oracle) 시스템과 테스트 대상 시스템(System Under Test, 이하 SUT)은 논리적으로 분리된 별개의 개체(Entity)이지만, 검증(Verification)이라는 거시적 목적을 달성하기 위해 테스트 실행 주기(Execution Cycle) 내내 긴밀하게 데이터를 교환하고 상태(State)를 동기화해야 한다. 만약 두 시스템 간의 상호작용이 타이밍 불일치(Timing Mismatch)를 겪거나, SUT의 내부 상태가 오라클에 투명하게 관측(Observable)되지 않는다면, 오라클 시스템 자체가 오판(False Positive/Negative)을 내리는 치명적 결함으로 이어진다.

본 절에서는 테스트 생명주기 내에서 SUT와 오라클이 어떠한 인터페이스(Interface)와 동기화 메커니즘을 통해 상호작용하는지, 그 구조적 패턴(Structural Pattern)을 세 단계로 나누어 상세히 분석한다.

1. 전제 조건 동기화 및 입력 주입 (Pre-condition Synchronization & Input Injection)

테스트의 일관성을 확보하기 위해서는 SUT와 오라클 시스템이 테스트 수행 직전에 동일한 초기 상태(Initial State) 를 공유해야 한다. 이를 전제 조건 동기화(Pre-condition Synchronization)라 명명한다.

  • 상태 격리(State Isolation): 이전 테스트의 잔여 데이터가 현재 테스트에 영향을 미치지 않도록, 데이터베이스 초기화(Database Teardown/Setup), 캐시 무효화(Cache Invalidation), 모의 객체(Mock Object)의 재설정 등이 선행되어야 한다.
  • 동시 주입(Concurrent Injection): 테스트 드라이버(Test Driver)는 테스트 케이스 T 에 명시된 입력 데이터 i 를 SUT의 엔트리 포인트(Entry Point, 예: API 엔드포인트 혹은 UI)에 주입함과 동시에, 오라클의 생성기(Generator) 모듈에도 이를 병렬로 전달한다.

이 단계에서 SUT는 i 를 받아 실제 비즈니스 로직 연산을 시작하고, 오라클은 i 와 스펙(Spec)에 기반하여 기대 결과 o_{expected} 도출 연산을 동시에 혹은 비동기적으로(Asynchronously) 수행하기 시작한다.

2. 관측 가능성(Observability) 및 결과 포획 (Result Capture)

SUT가 연산을 완료했다면, 오라클은 SUT가 내뿜는 결과(Output)를 수학적 비교가 가능한 형태로 온전히 포획(Capture)할 수 있어야 한다. 이 단계에서 SUT와 오라클 간 상호작용의 질을 결정짓는 핵심 공학 속성이 바로 관측 가능성(Observability)이다.

  • 직접 출력 포획 (Direct Output Capture): 가장 단순한 상호작용 패턴이다. SUT의 함수(Function)가 반환하는 리턴 값(Return Value)이나 HTTP Response의 Payload를 오라클이 메모리상에서 직접 스니핑(Sniffing)하여 수집한다.
  • 간접 관측 (Indirect Observability): 현대의 복잡한 시스템에서는 함수가 단순히 스칼라 값을 반환하고 끝나지 않는다. SUT가 연산의 결과로 데이터베이스의 레코드를 수정하거나, Kafka와 같은 메시지 큐(Message Queue)에 이벤트를 발행하는 등 ’부작용(Side Effect)’을 초래하는 경우가 대다수다.
  • 이러한 경우, 오라클은 SUT의 직접 반환값이 아닌, 메트릭 훅(Metric Hook), 로그 파일(Log File), 혹은 별도의 DB 조회 쿼리(Query)를 통해 SUT의 ‘상태 전이(State Transition)’ 결과를 간접적으로 폴링(Polling)하거나 콜백(Callback)으로 수집하는 복잡한 상호작용을 거쳐야 한다.

3. 타이밍 통제와 동치성 평가 (Timing Control & Equivalence Evaluation)

오라클이 SUT의 실제 결과(Actual Result)를 성공적으로 수집했다면, 마지막 상호작용은 시스템 간의 타이밍 제어와 오라클 판정기의 결론 도출로 이어진다.

  • 동기화 장벽(Synchronization Barrier): 비동기(Asynchronous) 시스템이나 프론트엔드 UI를 테스트할 때 주로 발생하는 난제다. SUT의 연산이 비동기 이벤트 루프(Event Loop)에서 아직 완료되지 않았음에도 오라클이 섣불리 결과 포획을 시도하면, 값의 부재(Null)로 인해 테스트가 억울하게 실패하는 Flaky Test(불안정한 테스트) 현상이 발생한다. 따라서 오라클은 SUT가 완전한 Idle 상태(유휴 상태)에 돌입했음을 증명하는 이벤트 프로미스(Promise Resolution)나 타임아웃 래치(Timeout Latch)를 통해 상호작용 시점을 통제해야 한다.
  • 동치성 연산(Equivalence Operation): 타이밍 문제가 해소되고 SUT의 o_{actual} 과 오라클 자체의 o_{expected} 가 오라클의 메모리 영역에 공존하게 되면, 비교기(Comparator)가 개입하여 상호 대조를 시작한다. 이 과정에서 도출된 \equiv (일치) 혹은 \not\equiv (불일치) 결과가 판정기(Verdict)로 넘겨지며 최종 SUT-오라클 간의 한 사이클 (Cycle) 인터랙션이 종료된다.
sequenceDiagram
    participant SUT as 테스트 대상(SUT)
    participant Driver as 테스트 드라이버
    participant Oracle as 오라클 시스템(Generator/Comparator)
    participant Env as 환경(DB/Queue/State)

    Note over SUT, Oracle: 1. 전제 조건 동기화 (상태 격리)
    Driver->>Env: 환경 초기화 (Teardown & Setup)
    
    Note over SUT, Oracle: 2. 데이터 동시 주입
    par Input to SUT
        Driver->>SUT: 입력 (Input <i>i</i>) 주입
    and Input to Oracle
        Driver->>Oracle: 입력 (Input <i>i</i>) 및 Spec 전달
    end
    
    activate SUT
    SUT->>Env: 부작용(Side Effects) 기록
    SUT-->>Driver: 동기/비동기 반환 (Return Value)
    deactivate SUT
    
    activate Oracle
    Oracle->>Oracle: O(i, s) -> 기대 결과 (Expected) 생성
    
    Note over SUT, Oracle: 3. 결과 포획 및 관측
    Driver->>Oracle: SUT 반환값 전달
    Oracle->>Env: 간접 관측(DB State 파악) 요청
    Env-->>Oracle: 변경된 상태 반환
    
    Note over Oracle: 4. 동치성 평가
    Oracle->>Oracle: Comparator 연산 (Actual \u2261 Expected)
    Oracle-->>Driver: 최종 판정 (Verdict: Pass/Fail)
    deactivate Oracle

4. 소결: 단방향(One-way)에서 양방향 관측(Two-way Observation)으로

전통적인 시스템에서 SUT와 오라클의 상호작용은 주로 입력을 주고 출력을 받아내는 단순한 블랙박스(Black-box) 핑퐁(Ping-pong) 게임이었다. 그러나 분산 시스템 아키텍처와 더불어 향후 다루게 될 AI가 결합되는 현대 시스템에서는, 오라클이 SUT의 내부 가중치(Weights)나 확신도(Confidence Score), 비결정론적 로깅 등 깊숙한 계층을 찔러보는(Probing) 양방향 화이트박스(White-box) 상호작용으로 점차 고도화되고 있다.

이러한 상호작용 메커니즘을 탄탄하게 구축하지 못하면, 향후 AI의 무작위적(Stochastic) 환각과 비동기적인 토큰 스트리밍(Token Streaming) 반응 속도를 오라클이 쫓아가지 못하고 붕괴하는 사태를 맞이하게 될 것이다.