2.3. 오라클 문제(The Oracle Problem)와 자동화의 한계

소프트웨어 테스팅 분야에서 수십 년간 엔지니어들을 괴롭혀 온 가장 근원적이고 극복하기 어려운 공학적 장벽이 존재한다. 모든 입력에 대해 시스템이 뱉어내야 할 정확한 정답(Expected Result)을 기계적으로 산출하거나 판별하는 것이 경제적으로, 혹은 물리적으로 불가능해지는 현상, 이를 학계에서는 **‘오라클 문제(The Oracle Problem)’**라고 명명한다.

앞선 2.2절에서 살펴보았듯, 인류는 이 완벽한 참 오라클(True Oracle)의 부재를 극복하기 위해 휴리스틱(Heuristic), 메타모픽 관계(Metamorphic Relation), 편법적 파생(Derived) 등 무수한 우회로를 진화시켜 왔다. 그러나 이러한 노력에도 불구하고 소프트웨어의 연산 공간은 끝을 알 수 없이 팽창해 왔으며, 결국 테스트 실행 자체는 셀레늄(Selenium)이나 CI/CD 파이프라인 무한히 자동화(Automation)할 수 있을지라도, 그 결과를 **“검증하는 뇌(Brain)”**의 자동화는 유한한 인간의 논리와 컴퓨팅 자원 안에서 한계에 봉착할 수밖에 없음을 깨닫게 되었다.

본 절에서는 소프트웨어 공학의 난제 중 난제로 꼽히는 ’오라클 문제’의 실체를 심층 해부한다. 이 고전적인 난제를 명확히 이해하는 것은, 왜 오늘날 비결정적(Nondeterministic) 거대 언어 모델(LLM)과 생성형 AI 시스템을 만났을 때 기존의 테스트 패러다임이 붕괴될 수밖에 없었는지, 그리고 우리가 왜 다시 철학적으로 타협할 수 없는 ’결정론적 정답지(Deterministic Ground Truth)’를 향해 회귀해야만 하는지를 밝히는 핵심적인 교두보가 될 것이다.

1. 자동화의 거대한 착시: ‘실행’ 비용 vs ‘검증’ 비용

소프트웨어 품질 보증(QA) 조직에서 코드를 실행하고 테스트 케이스를 생성하는 작업의 자동화 비율은 날이 갈수록 $100\%$ 에 수렴하고 있다. 자동화된 도구(Test Generator/Fuzzer)들은 1초에 수백만 개의 입력 $\vec{x}$ 를 시스템(SUT)에 우겨넣고 결과 $\vec{y}$ 를 반환받을 수 있다.

그러나 이 테스트 파이프라인의 완성도를 결정짓는 진짜 병목 현상은 실행 속도가 아니라, **“산출된 수백만 개의 $\vec{y}$ 가 참인지 거짓인지 기계가 스스로 판단할 수 있는가?”**에 있다.

오라클 문제가 통제되지 않은 환경에서는, 아무리 자동화된 테스트 실행을 쏟아부어도 결국 사람이 일일이 눈으로 결과를 확인(Eyeballing)해야 하는 파국적인 검증 비용이 발생한다.
즉, 테스트 자동화의 한계는 테스트 도구의 한계가 아니라, 필연적으로 오라클을 구축하고 연산하는 비용(Oracle Cost)의 한계로 귀결된다.

2. 하위 절의 전개 흐름

이러한 오라클 문제의 딜레마를 수학적, 경제적 관점에서 낱낱이 파헤치기 위해, 이어지는 하위 절에서는 다음과 같은 세부 주제들을 심층적으로 조망할 것이다.

2.3.1. 오라클 문제의 정의 (Definition of the Oracle Problem): 시스템의 예상 결과를 산출하는 알고리즘이 존재하지 않거나, 존재하더라도 비용이 너무 커서 오라클로서의 의미를 상실하는 철학적, 공학적 상황을 정의한다.
2.3.2. 테스트 불가능한 프로그램의 특징 (Non-testable Programs): 오라클 문제로 인해 전통적인 Test Pass/Fail의 이분법이 붕괴되는 “테스트 불가(Non-testable)” 도메인(예: 기동역학 복잡계 시뮬레이션, AI 모델)의 특성을 해부한다.
2.3.3. 오라클 비용의 딜레마 (Oracle Cost Dilemma): 시스템(SUT)을 개발하는 비용보다 오라클 구조를 설계하고 유지보수(Maintenance)하는 데 드는 비용이 압도적으로 직교하는 ‘오라클 비용 폭발’ 메커니즘을 분석한다.

우리는 이 장대한 오라클 문제의 본질을 거쳐, 마침내 확률과 통계의 늪에 빠져버린 AI 알고리즘 생태계 안에서 우리가 어떻게 새로운 결정론의 닻(Anchor)을 내려야 할지에 대한 해답으로 다가갈 것이다.