2.2.4. 모델 기반 오라클(Model-based Oracle): 상태 전이 다이어그램 및 수학적 모델 활용

2.2.4. 모델 기반 오라클(Model-based Oracle): 상태 전이 다이어그램 및 수학적 모델 활용

앞서 논의한 참 오라클(True Oracle)이 ’궁극의 정답’을 요구하고, 휴리스틱(Heuristic)이 ’느슨한 정답’을 허용한다면, ‘모델 기반 오라클(Model-based Oracle)’ 은 시스템의 동작 원리 자체를 추상화(Abstraction)하여 평가의 기준으로 삼는 고도화된 공학적 방법론이다.

시스템이 거대해짐에 따라 개별 입력값에 대한 출력값을 일일이 하드코딩(Hard-coding)하여 테스트 케이스를 유지보수하는 것은 불가능에 가깝다. 모델 기반 테스팅(Model-Based Testing, MBT) 패러다임에서 파생된 이 오라클은, 개발 로직(Source Code)과는 완전히 독립된 설계도(Model)를 수학적 혹은 논리적으로 구축한 뒤, 이 모델을 가동시켜 시스템이 마땅히 뱉어내야 할 절대적 궤적(Trajectory)을 산출하여 SUT(System Under Test)와 비교한다.

본 절에서는 소프트웨어의 동적 행위(Dynamic Behavior)를 제어하고 검증하기 위해 모델 기반 오라클이 어떠한 수학적 상태 기계(State Machine)와 전이 로직을 오라클 정보의 원천으로 활용하는지 심층적으로 해부한다.

1. 모델 기반 오라클의 성립 조건과 정의

모델 기반 오라클은 SUT가 요구사항 명세(Requirements)를 충실히 따르고 있는지 확인하기 위해, 명세서를 ’기계가 실행할 수 있는(Executable) 정형 모델(Formal Model)’로 변환한 것을 의미한다.

  • 추상화 수준(Level of Abstraction): 오라클로 사용되는 모델은 실제 코드의 구현 디테일(예: 데이터베이스 연결 방식, 스레드 풀 관리 등)을 모두 소거하고, 오직 순수한 비즈니스 로직과 상태 전이만을 남겨 수학적 명제나 그래프(Graph)로 환원한 것이다.
  • 동적 예측(Dynamic Prediction): 일반적인 명세 기반 오라클이 정적인 텍스트나 타입(Type)을 검증한다면, 모델 기반 오라클은 Test\_Input 의 시퀀스(Sequence)를 모델 엔진에 주입하여, t_1, t_2, \dots, t_n 에 걸쳐 변화해야 할 완벽한 ’기대 상태(Expected State)의 흐름’을 동적으로 예측해 낸다.

2. 상태 전이 모델(State Transition Model)의 활용

모델 기반 오라클을 구축할 때 가장 광범위하게 쓰이는 도구는 유한 상태 기계(Finite State Machine, FSM) 혹은 확장된 상태 전이 다이어그램(UML State Machine Diagram)이다. 특히 전자상거래, ATM, 통신 프로토콜과 같이 사용자의 액션에 따라 내부 상태가 명확하게 전환되는 시스템에 필수적이다.

  • 상태 전이의 수학적 정의: 상태 집합 S, 이벤트 공간 E, 그리고 전이 함수 \delta 에 대하여 시스템 모델은 \delta(S_{current}, E_{trigger}) \rightarrow S_{next} 로 정의된다.
  • 오라클 연산 메커니즘: SUT에 특정 사용자 버튼 클릭 이벤트 E_1 (예: 결제 버튼)이 발생하면, SUT는 자체적으로 로직을 실행하여 트랜잭션을 진행한다. 이때 모델 기반 오라클의 내부 모델(Oracle Engine)도 동일한 이벤트 E_1 을 수신하고, 다이어그램상에 정의된 전이 함수에 따라 “현재 상태 카트(Cart)에서 결제 완료(Paid) 상태로 넘어가야 함“을 논리적으로 추론한다. 이후 SUT의 실제 DB 상태(Actual State)와 모델이 가리키는 정답 상태(Expected State)가 \equiv 인지 대조한다.
stateDiagram-v2
    direction LR
    
    %% Model-based Oracle Logic Flow
    state "Initial State: S0" as S0
    state "State: S1" as S1
    state "Error State" as Err
    
    S0 --> S1: Event(A) \n / Action X
    S0 --> Err: Event(B) \n / Reject
    S1 --> S0: Event(C) \n / Reset
    
    note right of S0
        오라클 내부 모델(FSM)은
        명세서를 기반으로
        완벽한 그래프 궤적을 
        사전에 들고 있다.
    end note

위의 상태 전이 다이어그램이 곧 정답을 도출하는 룰 엔진(Rule Engine)이 되며, SUT가 Event(A)를 받아 Action X가 아닌 Action Y를 수행하면 모델은 즉각적으로 경로 위반(Path Violation) 결함을 보고하게 된다.

3. 마르코프 체인(Markov Chain) 및 확률적 수학 모델

상태가 명확하게 끊어지는 동기식 논리 시스템 외에, 통신 트래픽 부하, 성능 테스트, 그리고 머신러닝의 일부 비결정적 영역을 검증할 때는 확률 기반의 수학적 모델이 오라클로 사용된다.

  • 확률 모델 오라클: 마르코프 체인 모델을 검증 잣대로 사용할 경우, 오라클은 “상태 A 에서 상태 B 로 전이될 통계적 확률은 P(A \rightarrow B) = 0.8 이다“라는 수학적 기댓값을 들고 있다. 수만 번의 모의 테스트(Simulation)를 SUT에 수행시킨 뒤, SUT가 도출해 낸 빈도수(Frequency)가 오라클 모델이 제시한 확률 기댓값과 통계적으로 유의미하게 일치하는지 카이제곱(\chi^2) 검정 등으로 판독한다.

4. 모델 기반 오라클의 공학적 딜레마

모델 기반 오라클은 이론상 가장 우아한(Elegant) 검증 형태지만, 실제 엔터프라이즈 환경에서 완전하게 도입하기에는 다음과 같은 치명적 딜레마가 존재한다.

  1. 모델 무결성(Model Integrity)의 역설: 구현 코드(SUT)를 검증하기 위해 작성된 추상 설계도(Model) 자체가 개발자의 논리적 오류나 명세 해석의 오해로 인해 버그를 포함하고 있을 수 있다. “누가 모델을 검증할 것인가?(Who tests the tests?)“라는 근원적인 오라클 문제(Oracle Problem)로 다시 회귀하게 된다.
  2. 명세의 노후화(Specification Decay): 애자일(Agile) 조직에서 비즈니스 로직은 하루에도 수십 번 변경된다. 코드가 변경될 때마다 오라클의 판단 근거인 상태 전이 모델 다이어그램을 코딩 수준으로 정교하게 지속(Sync) 업데이트 유지보수하는 작업은 파국적인 공학 부채(Debt)를 발생시킨다.

5. 소결: AI 패러다임 붕괴에 대비한 교두보

전통적 소프트웨어에서 모델 기반 오라클은 통신 프로토콜이나 항공 제어 등 엄격한 상태 통제가 필요한 영역에 제한적으로 국한되어 쓰이곤 했다.

그러나 챗GPT(ChatGPT)와 같은 대화형 에이전트(LLM Agent)가 도입되면서, “AI의 상태 추적(State Tracking)” 은 시스템 붕괴를 막기 위한 핵심 전장으로 떠올랐다. 생성형 AI가 “인사 -> 주문 받기 -> 결제 안내” 라는 챗봇 시나리오 흐름을 멋대로 건너뛰지(Hallucination) 않고 정해진 궤도 내에서 응답을 생성하고 있는지 통제하기 위해, 우리는 반드시 이 모델 기반 오라클(상태 전이 다이어그램)을 AI의 검증 파이프라인(Guardrails) 안에 이식시켜 억지로 상태 불변성(State Invariant)을 강제해야만 한다. 이것이 나중에 다루게 될 AI 시대 결정론적 오라클의 뼈대다.