1.1.1 전통적인 소프트웨어 개발(Software 1.0)의 정의: 명시적 로직과 결정론적 제어

1.1.1 전통적인 소프트웨어 개발(Software 1.0)의 정의: 명시적 로직과 결정론적 제어

컴퓨터 과학과 소프트웨어 공학의 발전 역사는 인간의 추상적인 의도를 기계가 물리적으로 실행할 수 있는 구체적인 명령어로 번역해 온 끝없는 진화의 궤적이다. 1950년대 메인프레임 시대가 태동한 이래로, 프로그래머들은 기계어와 어셈블리어를 거쳐 C, C++, Java, Python과 같은 고수준(High-level) 프로그래밍 언어를 설계하며 컴퓨팅의 기반을 다져왔다. 반세기 이상 소프트웨어 산업의 절대적인 표준이자 현대 디지털 문명의 인프라를 구축한 이 지배적인 패러다임을 우리는 ’전통적인 소프트웨어 개발’이라고 부른다.

인공지능 연구자이자 전 테슬라(Tesla) AI 디렉터인 안드레이 카패시(Andrej Karpathy)는 2017년 발표한 자신의 기념비적인 에세이 “Software 2.0“에서 이러한 전통적인 프로그래밍 방식을 ’Software 1.0’으로 명명하며, 새롭게 부상하는 데이터 기반의 신경망 아키텍처(Software 2.0)와 구조적으로 대비시켰다. 카패시의 정의에 따르면, Software 1.0은 인간 프로그래머가 특정 문제를 해결하기 위해 컴퓨터가 수행해야 할 모든 단계와 알고리즘을 명시적(Explicit)으로 작성하고, 기계는 이를 결정론적(Deterministic)으로 실행하는 방식을 의미한다. 즉, Software 1.0은 시스템의 상태 변화와 논리적 분기점 하나하나를 인간이 직접 설계하고 통제하는 철저한 화이트박스(White-box) 패러다임이다.

본 절에서는 Software 1.0을 규정하는 두 가지 핵심 기술적 축인 ’명시적 로직(Explicit Logic)’과 ’결정론적 제어(Deterministic Control)’의 학술적, 수학적, 공학적 근원을 깊이 있게 해부한다. 나아가 전통적 소프트웨어 공학에서 필수적인 무결성 검증 수단인 ’테스트 오라클(Test Oracle)’의 개념을 정립하고, 이러한 결정론적 시스템이 인공지능 모델의 비결정성(Nondeterminism)과 환각(Hallucination)을 통제하기 위한 ’결정론적 오라클(Deterministic Oracle)’로서 실전 아키텍처에 어떻게 융합되고 있는지 심층적으로 분석한다.

1. 명시적 로직(Explicit Logic)의 구조와 철학적 기반

Software 1.0의 가장 본질적인 특징은 알고리즘의 모든 논리적 흐름이 인간의 손에 의해 명시적으로 규정된다는 점이다. 소프트웨어 엔지니어링에서 명시적 프로그래밍(Explicit programming)이란 시스템이 달성해야 할 ’결과(What)’뿐만 아니라, 그 결과에 도달하기 위한 미시적인 ’과정(How)’까지 제어문과 데이터 구조를 통해 컴퓨터에게 직접 지시하는 것을 의미한다.

1.1 하향식 분할과 제어 흐름의 투명성

전통적 소프트웨어 개발은 거대한 도메인 문제를 더 이상 쪼갤 수 없는 단위 함수나 모듈로 분할하는 하향식(Top-down) 설계 방식에 의존한다. 개발자는 요구사항을 분석한 후, 이를 if-else 조건문, for/while 반복문, 그리고 명확하게 정의된 데이터 타입의 조합으로 변환한다. 이 과정에서 기계는 스스로 어떠한 논리도 유추하거나 학습하지 않으며, 오직 컴파일러나 인터프리터에 의해 기계어로 번역된 인간의 명령을 맹목적이고 충실하게 수행하는 실행기에 불과하다.

이러한 명시적 구조는 소프트웨어에 극단적인 투명성(Transparency)과 추적 가능성(Traceability)을 부여한다. 애플리케이션 실행 중 예외(Exception)가 발생할 경우, 엔지니어는 스택 트레이스(Stack trace)를 통해 정확히 몇 번째 파일의 어느 라인에서 예상치 못한 상태가 발생했는지 핀포인트로 추적할 수 있다. 이는 변수의 할당, 루프의 종료 조건, 분기문의 진입 여부가 모두 코드 텍스트라는 명시적 층위 위에 노출되어 있기 때문이다. 반면, 수억 개의 연속적인 실수 가중치(Weights) 행렬 곱셈으로 이루어진 Software 2.0의 신경망이나, 자연어 프롬프트(Prompt)에 의해 작동하는 Software 3.0 환경에서는 로직의 은닉화와 블랙박스화가 발생하여 이러한 직접적인 원인 규명이 불가능해진다.

논리 상수와 추론 규칙을 정의하는 학술적 관점에서도, 명시적 논리(Explicit logic) 시스템은 새로운 어휘나 구조를 추가할 때 기존의 고전적 법칙과 증명 패턴을 보존(Conservative extension)하면서 확장해 나가는 특성을 지닌다. 이는 기존의 증명된 로직 모듈을 캡슐화(Encapsulation)하여 블랙박스처럼 재사용하되, 그 내부의 로직 자체는 언제든 꺼내어 수학적으로 해석할 수 있는 Software 1.0의 모듈성(Modularity) 원칙과 궤를 같이한다.

1.2 호어 논리(Hoare Logic)와 프로그램의 공리적 증명

명시적 로직이 신뢰성을 확보할 수 있는 근본적인 이유는 알고리즘의 동작이 수학적이고 형식적인 방법(Formal methods)을 통해 증명 가능하기 때문이다. 1969년, 영국의 저명한 컴퓨터 과학자 C.A.R. 호어(C.A.R. Hoare)가 발표한 논문 “An Axiomatic Basis for Computer Programming“은 컴퓨터 프로그램의 실행 결과를 엄밀하게 추론하고 수학적으로 증명하기 위한 공리적 의미론(Axiomatic Semantics)의 토대를 마련했다.

호어 논리의 핵심은 프로그램의 상태 변화를 ’호어 삼조(Hoare Triple)’라는 논리식으로 모델링하는 데 있다. 이는 다음과 같이 표현된다.
\{P\} \; C \; \{Q\}
여기서 P는 프로그램 명령문 또는 코드 블록 C가 실행되기 직전에 참(True)이어야 하는 사전 조건(Precondition)을 의미하며, Q는 명령문 C가 정상적으로 실행을 종료한 후 반드시 만족되어야 하는 사후 조건(Postcondition)을 의미한다.

이 공리적 시스템은 Software 1.0의 제어 구조를 수학적으로 검증하기 위해 할당 공리(Assignment Axiom), 합성 규칙(Composition Rule), 조건문 규칙(Conditional Rule), 그리고 반복문 규칙(While Rule) 등 다양한 추론 규칙을 제공한다. 예를 들어, 루프(Loop) 불변성을 증명하는 규칙은 명시적 로직이 무한 루프에 빠지지 않고 의도한 횟수만큼만 실행된 뒤 결정론적인 결과에 도달함을 보장한다. 이러한 수학적 증명 가능성은 코드가 실행되기 전(Pre-compilation)에 정적 분석(Static analysis)과 타입 체킹(Type checking)을 통해 오류를 사전에 차단할 수 있게 해준다.

Software 1.0은 이러한 논리적 엄밀성 위에 구축되었기 때문에, 회계 처리, 금융 트랜잭션, 우주 항공 제어 시스템, 의료 기기 등 단 한 번의 비결정적 오류도 용납되지 않는 무결성 핵심(Safety-critical) 도메인에서 대체 불가능한 아키텍처로 자리 잡을 수 있었다.

2. 결정론적 제어(Deterministic Control)의 기저 원리와 오토마타 모델

명시적 로직이 소프트웨어의 ’의도’를 정적인 텍스트 형태로 규정한다면, 결정론적 제어(Deterministic Control)는 그 텍스트가 런타임 환경에서 언제나 동일한 결과를 산출하도록 보장하는 동적인 ’실행의 법칙’이다. 수학, 물리학, 그리고 컴퓨터 과학 전반을 관통하는 ’결정론적 시스템(Deterministic system)’의 정의는 시스템의 미래 상태 전개 과정에 어떠한 무작위성(Randomness)이나 확률적 변수도 개입되지 않는 시스템을 뜻한다.

결정론적 알고리즘(Deterministic algorithm)은 입력값과 명령어의 순서가 주어지면, 그 실행 과정이 완전히 결정되어 매 실행마다 정확히 동일한 궤적을 그리며 동일한 출력을 반환한다. 이는 동일한 프롬프트를 입력하더라도 샘플링 파라미터(Temperature 등)나 내부의 확률적 추론 과정에 의해 매번 다른 텍스트나 코드를 반환할 수 있는 인공지능 및 거대 언어 모델(LLM)의 비결정성(Nondeterminism)과 가장 극명하게 대비되는 Software 1.0만의 고유한 특성이다.

2.1 결정론적 유한 오토마타(DFA)와 상태 공간의 제어

Software 1.0 프로그램의 실행 논리는 근본적으로 오토마타 이론(Automata Theory)의 결정론적 유한 오토마타(Deterministic Finite Automaton, DFA) 모델로 치환하여 이해할 수 있다. DFA는 메모리가 제한된 추상 기계가 상태를 전이해 나가는 과정을 수학적으로 묘사한 모델이며, 다음과 같은 5-튜플(5-tuple) 형식으로 엄밀하게 정의된다.
M = (Q, \Sigma, \delta, q_0, F)

  • Q: 시스템이 가질 수 있는 유한한 상태(States)들의 집합.
  • \Sigma: 시스템이 받아들일 수 있는 유한한 입력 기호들의 집합 (알파벳).
  • \delta: 현재 상태와 입력을 받아 다음 상태를 결정하는 전이 함수(Transition function), \delta : Q \times \Sigma \rightarrow Q.
  • q_0: 시스템의 초기 상태 또는 시작 상태 (q_0 \in Q).
  • F: 시스템이 실행을 마치고 수락을 결정하는 최종 상태들의 집합 (F \subseteq Q).

DFA 모델에서 가장 핵심적인 부분은 바로 전이 함수 \delta의 결정론적 특성이다. 시스템이 특정한 현재 상태 q에 있고 입력값 a를 받았을 때, 전이할 수 있는 다음 상태는 \delta(q, a)에 의해 단 하나로 유일하게(Uniquely) 결정된다. 여러 개의 유효한 다음 상태를 가지거나 \epsilon-전이(입력 없는 전이)를 허용하는 비결정론적 유한 오토마타(NFA)와 달리, DFA는 실행 궤적이 분기되지 않고 단일한 선형 경로를 따른다.

컴퓨터의 중앙 처리 장치(CPU) 명령어 파이프라인부터 데이터베이스의 트랜잭션 처리, 그리고 애플리케이션의 비즈니스 로직에 이르기까지 Software 1.0 기반의 모든 프로그램은 이러한 결정론적 상태 기계(State Machine)의 거대한 구현체다. 개발자가 작성한 명시적 로직은 \delta 함수를 정의하는 작업이며, 런타임 환경은 입력 \Sigma를 받아 초기 상태 q_0부터 최종 상태 F까지 오차 없이 전이해 나가는 물리적 과정이다.

2.2 통제 이론(Control Theory)과 재현성(Reproducibility)의 가치

결정론적 제어는 제어 이론(Control Theory)의 관점에서도 중요하게 다루어진다. 시간 영역(Time-domain) 상태 공간 표현(State space representation)을 활용하는 현대 제어 이론에서, 결정론적 제어 문제는 시스템 외부로부터 예측할 수 없는 무작위 충격(Random shocks)이나 잡음(Noise)의 영향을 배제한 상태에서 시스템을 원하는 목표 상태로 안정적으로 유도하는 것을 다룬다.

소프트웨어 공학에서 이러한 결정론적 시스템이 제공하는 가장 강력한 무기는 바로 ’재현성(Reproducibility)’이다. 애플리케이션에 버그나 결함이 존재하더라도, 결정론적 환경에서는 동일한 입력과 초기 상태를 주입하면 버그가 발생하는 정확한 실행 경로와 메모리 상태를 100% 재현할 수 있다. 이는 엔지니어가 결함의 근본 원인을 격리하고 디버거를 통해 변수의 상태를 추적하며 오류를 수정할 수 있게 하는 핵심 전제 조건이다.

반면, 기계 학습(Machine Learning) 모델은 본질적으로 확률적 최적화 과정에 의존하며, 구글 구글(Google)의 Sculley 연구진이 발표한 논문 “Hidden Technical Debt in Machine Learning Systems“에서 명명한 ‘CACE(Changing Anything Changes Everything)’ 원칙의 지배를 받는다. 입력 데이터 분포의 미세한 변화(Drift), 하이퍼파라미터의 조정, 훈련 환경의 작은 차이가 수백만 개의 가중치에 연쇄적인 파급 효과를 일으켜 전체 모델의 행동 양식을 완전히 바꾸어 놓을 수 있다. 소프트웨어 1.0의 모듈 캡슐화가 작동하지 않는 이러한 비결정론적 환경은, 기존의 재현성 기반 디버깅 체계를 철저히 붕괴시키며 AI 시스템 엔지니어에게 극도의 인지적 피로와 유지보수 비용을 초래한다.

비교 차원전통적인 소프트웨어 개발 (Software 1.0)AI 기반 소프트웨어 개발 (Software 2.0 / 3.0)
패러다임 정의인간이 코드를 작성하여 기계를 프로그래밍함최적화 과정(신경망 훈련)이나 프롬프트를 통해 모델을 조정함
핵심 동력명시적 로직 (Explicit Logic) 및 하드코딩된 규칙대규모 데이터, 수학적 최적화, 맥락 기반 확률적 추론
제어 및 실행 구조결정론적 제어 흐름, 유한 상태 기계(DFA) 기반 전이행렬 곱셈, 활성화 함수, 어텐션(Attention) 메커니즘
가시성(Observability)화이트박스 (코드 라인 단위의 투명한 추적 및 디버깅 가능)블랙박스 (내부 파라미터 연산의 설명 가능성 매우 낮음)
출력의 특성100% 예측 가능, 동일 입력에 대해 항상 동일한 출력확률적/비결정론적, 난수 및 샘플링 기법에 따라 출력 변동 가능
결함 수정 방법소스 코드의 로직 직접 수정, 리팩토링, 재컴파일데이터셋 정제, 가중치 재학습, 프롬프트 엔지니어링 수행

3. 테스트 오라클(Test Oracle)과 결정론적 그라운드 트루스(Ground Truth)

소프트웨어 시스템이 명시적 로직과 결정론적 제어로 이루어져 있다면, 그 시스템이 설계자의 의도대로 완벽하게 작동하는지 검증하는 수학적이고 공학적인 기준이 필요하다. 소프트웨어 테스팅 분야에서는 시스템의 실제 실행 결과와 비교하여 그 결과의 참/거짓을 판별해 주는 권위 있는 기준이나 메커니즘을 ’테스트 오라클(Test Oracle)’이라고 부른다.

3.1 테스트 오라클의 학술적 정의

테스트 오라클이라는 용어는 1978년 윌리엄 하우든(William Howden)의 기념비적인 연구에서 처음 제안된 이후, 소프트웨어 검증의 핵심 요소로 자리 잡았다. Earl Barr 등은 논문 “The Oracle Problem in Software Testing: A Survey“에서 테스트 활동(Test Activities)을 시스템에 자극(Stimulus)을 가하고 그 시스템의 반응(Response)을 관찰하여 올바른 동작을 식별하는 일련의 과정으로 체계화했다. Barr에 따르면, 테스트 오라클은 “테스트 대상 시스템(SUT, System Under Test)의 올바른 행동(Correct behavior)과 잘못된 행동(Incorrect behavior)을 구별하는 절차“로 정의된다.

전통적인 소프트웨어 테스팅에서는 테스트 입력(Test Input)과 이에 매칭되는 테스트 오라클(Test Oracle)이 결합되어 완전한 하나의 ’테스트 케이스(Test Case)’를 구성한다. 단위 테스트(Unit Testing) 프레임워크에서 개발자가 작성하는 assertEquals(expected, actual)와 같은 단언문(Assertion)이 가장 대표적인 명시적 테스트 오라클의 구현체다.

3.2 그라운드 트루스(Ground Truth)와 오라클의 건전성/완전성

결정론적 시스템에서 가장 이상적이고 완벽한 형태의 오라클은 ’그라운드 트루스 오라클(Ground Truth Oracle)’이다. 그라운드 트루스 G는 주어진 입력 상태에 대해 언제나 편향 없이 ’절대적으로 올바른 정답’을 산출하는 개념적이며 추상적인 오라클을 의미한다.

공학자들이 설계한 현실의 테스트 오라클 D가 얼마나 신뢰할 수 있는지를 평가하기 위해, 그라운드 트루스 G와의 관계를 바탕으로 두 가지 수학적 특성을 정의한다.

  1. 건전성(Soundness): 테스트 오라클 D가 어떤 시스템의 출력 a에 대해 결함이 있다고(False) 판별했을 때, 절대적 진리인 그라운드 트루스 G 역시 해당 출력 a를 결함으로 판별한다면 오라클 D는 건전하다. 이를 논리식으로 표현하면 D(a) \Rightarrow G(a)가 성립한다.
  2. 완전성(Completeness): 그라운드 트루스 G가 결함으로 판별하는 모든 출력 a에 대하여, 현실의 테스트 오라클 D 역시 예외 없이 이를 결함으로 적발해낸다면 오라클 D는 완전하다. 이는 G(a) \Rightarrow D(a)로 표현된다.

Software 1.0 패러다임 하에서는 입력과 알고리즘이 확정되어 있기 때문에, 인간 엔지니어는 사양서(Specification), 수학적 계산, 또는 이전 버전의 실행 결과(Regression Testing)를 활용하여 높은 건전성과 완전성을 지닌 결정론적 오라클을 비교적 수월하게 구축할 수 있었다.

3.3 오라클 문제(Oracle Problem)와 AI 비결정성의 충돌

그러나 현대 컴퓨팅이 다루는 도메인이 복잡해지고, 특히 인공지능 기반의 Software 2.0 및 Software 3.0 시스템이 도입되면서 전통적인 오라클 체계는 붕괴의 위기를 맞이하고 있다. 테스트에 대한 명확하고 단일한 ’정답’을 사전에 알 수 없거나, 정답을 계산하는 데 드는 비용이 무한대에 가까운 상황을 소프트웨어 공학에서는 ’오라클 문제(Oracle Problem)’라고 지칭한다.

거대 언어 모델(LLM)과 같은 AI 시스템은 본질적으로 통계적 분포에 기반하여 다음 토큰(Token)을 생성하는 확률적 기계다. 사용자가 “피보나치수열을 계산하는 파이썬 코드를 작성해 줘“라고 동일한 프롬프트를 주입하더라도, 모델은 매 실행마다 다른 변수명을 사용하거나, 재귀(Recursion) 대신 반복문(Iteration)을 사용하거나, 주석의 내용이 다른 코드를 생성할 수 있다. 이는 전통적인 테스트 자동화의 근간이었던 ‘정확한 값의 일치 여부(Exact match)’ 기반의 결정론적 오라클을 무용지물로 만든다.

결과가 다형적(Polymorphic)이고 주관적이며 비결정론적일 때, 단순한 텍스트 비교 오라클은 건전성과 완전성을 상실한다. AI 모델이 그럴싸한 거짓 정보를 생성하는 ‘환각(Hallucination)’ 현상이나 보안 취약점이 포함된 악성 코드를 출력할 경우, 기존의 QA(Quality Assurance) 파이프라인은 이를 정상적인 응답으로 오인(False Negative)하거나 문맥상 올바른 응답을 오류로 처리(False Positive)하는 치명적인 결함을 노출하게 된다. 이는 무결성이 생명인 비즈니스 애플리케이션에서 AI의 도입을 가로막는 가장 큰 기술적 장벽이다.

4. AI 기반 소프트웨어 개발에서의 결정론적 오라클(Deterministic Oracle) 구축 및 실전 예제

AI 기술의 폭발적인 발전은 텍스트 요약, 이미지 분석, 코드 자동 생성 등 비정형 데이터 처리 영역에서 인간의 인지 능력을 대체하는 혁신을 이룩했다. 하지만 재무 회계, 법률 검토, 인프라 보안 제어와 같이 극도의 정확성과 예측 가능성이 요구되는 엔터프라이즈 환경에서, 통제되지 않은 AI의 비결정성은 재앙적인 결과를 초래할 수 있다.

이러한 모순을 해결하기 위해 현대 소프트웨어 아키텍처는 매우 흥미로운 설계 패턴을 채택하고 있다. 바로 유연하지만 신뢰할 수 없는 인공지능(Software 2.0/3.0)의 출력물을 검증하고 통제하기 위해, 엄격한 규칙과 그라운드 트루스를 제공하는 전통적 명시적 로직(Software 1.0)을 역으로 ’결정론적 오라클(Deterministic Oracle)’로 활용하는 하이브리드 지능 시스템의 구축이다.

이는 지능적 에이전트의 사고와 행동을 명시적 코드가 제공하는 안전한 울타리(Guardrails) 내로 강제(Bounding)하는 방식이다. 이 접근법은 결정론적 오라클을 통해 AI 시스템의 결과를 검증 가능하게 만들고, 오류가 발생했을 때 이를 AI에게 피드백하여 자가 수정(Self-correction)을 유도하는 강력한 메커니즘을 제공한다. 다음의 세 가지 실전 예제는 Software 1.0 시스템이 인공지능 시대에 오라클로서 어떻게 기능하며 신뢰성을 극대화하는지 구체적으로 보여준다.

4.1 실전 예제 1: 세무/재무 시스템에서의 확정적 비즈니스 로직 검증 (전문가 시스템 모델)

세무 계산과 금융 트랜잭션은 확률적 근사치가 아닌 1\vert0의 결정론적 정확성만이 허용되는 영역이다. 인투잇 터보택스(Intuit TurboTax)와 같은 현대의 재무 및 세무 소프트웨어 시스템은 방대한 법적 규제와 국세청(IRS)의 세법 코드를 명시적인 if-then 조건문과 수학적 공식으로 하드코딩한 전형적인 Software 1.0 기반의 전문가 시스템(Expert System)이다.

최근 이러한 시스템에 생성형 AI 기술이 도입되면서 아키텍처의 분업이 이루어졌다. AI(Software 3.0)는 사용자의 복잡한 자연어 질문을 이해하고 비정형 영수증 데이터에서 필요한 파라미터(예: 연봉, 부양가족 수, 공제 대상 지출액)를 추출하는 유연한 인터페이스 역할만을 수행한다. 이렇게 추출된 파라미터는 JSON 형태의 구조화된 데이터로 파싱되어, 50년 이상 검증된 결정론적 Software 1.0 세무 엔진으로 전달된다.

  1. AI 컴포넌트 (인지 및 추출): 사용자의 채팅 내역에서 과세 연도, 급여, 기부금 등의 데이터를 추출한다. 이 과정은 확률적이며 환각에 의한 오류 가능성을 내포한다.
  2. 결정론적 오라클 (Software 1.0 엔진): 전달받은 파라미터를 입력값으로 하여 주 단위 세액 = (과세표준 * 주별 세율) - 누진공제액과 같은 명시적 규칙 기반의 함수를 실행한다. 이때 AI가 추출한 값이 법정 공제 한도를 초과하거나 필수 누락 데이터가 있는지 수학적으로 검증한다.
  3. 검증 피드백 루프: 결정론적 엔진이 계산한 최종 세액 데이터와 발생한 예외(Exception) 조건은 다시 AI 모델로 피드백된다. LLM은 이 확정된 데이터를 바탕으로 최종 응답 문장만을 포매팅하여 사용자에게 전달한다.

이러한 아키텍처 분리에서 Software 1.0 엔진은 AI의 언어적 추론에 재무적 그라운드 트루스를 제공하는 오라클 역할을 완벽히 수행하며, 시스템 전체의 법적 준거성을 100% 보장하게 된다.

4.2 실전 예제 2: 자연어 기반 데이터베이스 쿼리 (NL2SQL)와 실행 기반 엔진 오라클

데이터베이스 분석 영역에서 사용자의 자연어를 SQL 코드로 변환하는 NL2SQL(Natural Language to SQL) 기능은 가장 각광받는 AI 활용 사례 중 하나다. LLM은 “2025년 1분기 캘리포니아 지역에서 가장 많이 팔린 제품 상위 5개를 보여줘“라는 질문을 받아 SELECT SQL 쿼리로 변환하는 데 뛰어난 성능을 보인다. 그러나 LLM이 생성한 텍스트 쿼리가 문법적으로 완벽한지, 조인(Join) 구조가 스키마에 맞는지, 또는 권한 밖의 테이블에 접근하려 하지 않는지 보장할 방법은 LLM 내부에는 존재하지 않는다.

이러한 검증의 부재를 해결하기 위해 오라클(Oracle)의 Autonomous Database에 탑재된 Select AI와 같은 기능은, 관계형 데이터베이스 관리 시스템(RDBMS)의 파서(Parser)와 옵티마이저(Optimizer) 엔진 자체를 결정론적 오라클로 활용한다.

  1. NL2SQL 확률적 생성: LLM이 메타데이터 프롬프트를 바탕으로 후보 SQL 쿼리를 생성한다.
  2. DB 엔진 오라클 검증: 생성된 SQL 문은 즉시 실행되거나 사용자에게 반환되지 않고, 강력한 Software 1.0 기반의 데이터베이스 엔진에 주입되어 검증 절차를 거친다.
  3. 결정론적 판별 및 피드백:
  • 구문/의미 분석(Syntax & Semantic Check): SQL 파서는 괄호의 짝, 식별자의 유효성, 그리고 카탈로그를 조회하여 테이블 및 컬럼명이 실제 스키마에 존재하는지(예: 대소문자 구분 및 오타 여부) 결정론적으로 확인한다.
  • 권한 및 보안 검사: 해당 세션을 실행하는 사용자가 생성된 쿼리의 뷰(View)나 테이블에 대해 열람 권한이 있는지 확인한다.
  1. 자가 치유(Self-Healing) 프로세스: 만약 결정론적 오라클(DB 엔진)이 ORA-00904: invalid identifier와 같은 구문 에러나 권한 에러를 반환하면, 이 정확한 에러 코드와 설명은 시스템 로그에 기록될 뿐만 아니라 다시 LLM 에이전트에게 전송된다. 에이전트는 이를 근거로 쿼리의 오류를 인식하고 스스로 수정(Verify-or-fix)하는 루프를 돈다.

이 아키텍처를 통해 최종적으로 실행되는 데이터는 LLM의 환각이 완전히 제거된, 명시적 데이터베이스 엔진에 의해 무결성이 입증된 확정적 데이터가 된다. 이는 생성된 코드의 정확도를 실행(Execution) 결과와 컴파일러를 통해 판별하는 동적 오라클의 가장 발전된 형태다.

4.3 실전 예제 3: 자율형 에이전트 워크플로우의 결정론적 오케스트레이션 (상태 기계 기반 제어)

최근 AI 소프트웨어 공학은 단순 질의응답을 넘어, LLM이 시스템의 상태를 인지하고 계획(Plan)을 세워 도구(Tool)를 능동적으로 호출하는 자율형 AI 에이전트(Autonomous AI Agents) 패러다임으로 진화하고 있다. ReAct(Reasoning and Acting)와 같은 프레임워크가 대표적이다. 그러나 에이전트에게 인프라 제어 권한이나 API 호출 권한을 무제한으로 부여하는 것은 시스템을 무한 루프에 빠뜨리거나 파괴적인 명령을 실행하게 할 위험성이 극히 높다.

이러한 에이전트의 비결정적 행동 공간(Action Space)을 안전하게 제어하기 위해, 오케스트레이션(Orchestration) 계층에 전통적인 Software 1.0의 상태 기계(State Machine)와 유향 비순환 그래프(DAG, Directed Acyclic Graph) 구조를 투입하는 방식이 표준으로 자리 잡고 있다. 오라클 클라우드 인프라스트럭처(OCI)의 Generative AI Agents ADK(Agent Development Kit)를 활용한 멀티 스텝 워크플로우 예제가 이를 명확히 보여준다.

클라우드 서버의 비정상 로그를 분석하고 문제가 발생한 서버를 종료(Shutdown)하는 권한을 지닌 장애 대응 AI 에이전트가 있다고 가정하자.

  1. 확률적 추론(Probabilistic Reasoning): 에이전트는 수집된 로그를 분석하고 “서버 A에 메모리 누수가 발생했으므로 재부팅이 필요하다“고 판단하여 restart_server(A) 도구 호출을 시도한다.
  2. 결정론적 워크플로우 제어(Deterministic Control Flow): 에이전트가 도구를 호출하기 직전, 오케스트레이터의 파이썬(Python) 명시적 로직이 가로채기(Interceptor)로 작동한다.
  • if server.status == 'CRITICAL_PROD': require_human_approval()
  • 이와 같이 하드코딩된 ’승인 게이트(Approval Gate)’나 ’정책 확인 로직(Policy Check)’은 예외 없이 엄격하게 실행된다.
  1. 오라클 기반 행동 제약: LLM 시스템 프롬프트에 “핵심 프로덕션 서버는 절대 허락 없이 끄지 마라“라고 지시하는 것은 환각이나 프롬프트 인젝션(Prompt Injection)에 의해 우회될 확률적 리스크가 존재한다. 그러나 Software 1.0 레벨의 if-else 제어문은 우회나 협상이 불가능한 결정론적 물리 법칙으로 기능하며, 에이전트의 위험한 행동을 원천 차단하는 오라클이 된다.

결론적으로, 자율형 에이전트가 보여주는 인지적 유연성과 도구 활용 능력은 LLM이라는 확률적 엔진에서 비롯되지만, 그 행동이 시스템에 미치는 파급 효과를 통제하고 안전한 상태 전이를 보장하는 것은 명시적 코드로 짜인 결정론적 제어 워크플로우(Deterministic Workflow Control)의 몫이다.

5. 소결: 확률의 바다를 항해하기 위한 결정론적 닻, 명시적 로직

Andrej Karpathy가 예견한 Software 2.0으로의 전환, 그리고 나아가 자연어가 프로그래밍 언어를 대체하는 Software 3.0(Promptware) 시대로의 패러다임 이동은 기계에 인간과 유사한 지능을 부여하고 전통적 코딩의 한계를 크게 확장시켰다. 이제 소프트웨어 엔지니어들은 이미지 픽셀 구조에서 윤곽선을 식별하기 위한 복잡한 수학적 필터를 하드코딩하거나, 자연어의 뉘앙스를 처리하기 위해 무수히 많은 정규 표현식(Regular expressions)을 작성하지 않는다. 이러한 인식론적, 추론적 병목은 방대한 데이터와 최적화 알고리즘에 의해 스스로 가중치를 갱신하는 신경망의 영역으로 성공적으로 이양되었다.

그러나 소프트웨어 공학의 궁극적 사명이 단지 복잡한 연산을 수행하는 것에 그치지 않고, 그 연산 결과를 예측 가능하게 만들며 안전하고 신뢰할 수 있는 시스템으로 프로덕션 환경에 배포하는 것에 있음을 결코 간과해서는 안 된다. 확률적 시스템인 인공지능은 그 구조적 본질로 인해 스스로 생성한 출력물의 절대적 진실성이나 무결성을 내부적으로 담보할 수 없으며, 이러한 오라클 문제(Oracle Problem)는 실전 도입을 가로막는 치명적인 약점이다.

이러한 맥락에서 볼 때, Software 1.0의 명시적 로직과 결정론적 제어는 결단코 극복하고 폐기해야 할 구시대의 레거시(Legacy)가 아니다. 오히려 그것은 불확실성과 무작위성이 팽창하는 AI 모델의 출력을 검증하고, 행동 반경을 엄격하게 제한하며, 궁극적으로 시스템의 법적, 비즈니스적 무결성을 담보하는 최후의 보루이자 ’결정론적 오라클’로서 그 진정한 공학적 가치가 재조명되고 있다.

미래의 AI 네이티브 애플리케이션(AI-Native Application) 아키텍처는 무정형의 데이터를 처리하고 인지적 유연성을 제공하는 신경망 엔진(Software 2.0/3.0)과, 절대적인 비즈니스 규칙과 상태 전이를 관장하는 명시적 제어 코드(Software 1.0)가 정교한 톱니바퀴처럼 결합된 하이브리드 트랜잭션 시스템으로 진화할 것이다. 호어 논리의 공리적 증명과 유한 오토마타의 상태 전이에 기초한 명시적 로직이 결정론적 신뢰를 뒷받침하지 않는다면, 그 어떠한 고도화된 인공지능 시스템도 오류에 대한 무관용 원칙이 지배하는 실전 엔터프라이즈 환경의 높은 문턱을 결코 넘어설 수 없을 것이다.

6. 참고 자료

  1. Programming’s Evolution: From Code to Conversations in the AI Era | by Piyush Kashyap, https://medium.com/@piyushkashyap045/programmings-evolution-from-code-to-conversations-in-the-ai-era-2edd01a705c2
  2. The transition from Software 1.0 to Software 2.0 | Insights | Liontrust Asset Management PLC, https://www.liontrust.com/insights/blogs/2025/02/the-transition-from-software-1-to-software-2-short
  3. Beyond Bolt-On AI: A New Way to Build Software - APIscene, https://www.apiscene.io/ai-and-apis/ai-first-software-architecture/
  4. Software 2.0 - Andrej Karpathy – Medium, https://karpathy.medium.com/software-2-0-a64152b37c35
  5. 2월 15, 2026에 액세스, https://karpathy.medium.com/software-2-0-a64152b37c35#:~:text=Software%201.0%20is%20code%20we,this%20training%20data%20correctly%E2%80%9D)..](https://karpathy.medium.com/software-2-0-a64152b37c35#:~:text=Software%201.0%20is%20code%20we,this%20training%20data%20correctly”).)
  6. Reflections on Trusted AI Frameworks after two years - GitHub Pages, https://la3d.github.io/nuggets/posts/frameworks-reflection/
  7. Navigating the Three Eras of Software Development: A Strategic Guide for Executives, https://robbieallen.medium.com/navigating-the-three-eras-of-software-development-a-strategic-guide-for-executives-fee108db9007
  8. The Future of Software - Max Davish, https://www.maxdavish.com/blog/future-of-software
  9. Intramorphic Testing: A New Approach to the Test Oracle Problem - ETH Zurich Research Collection, https://www.research-collection.ethz.ch/server/api/core/bitstreams/30763e1f-803c-4e57-ae67-db38fc84cfc1/content
  10. Interpretability Guided ECG Denoising with Tsetlin Machines - POLITECNICO DI TORINO, https://webthesis.biblio.polito.it/38644/1/tesi.pdf
  11. Stop Coding Like It’s 2015 (and here’s why most traditional software rules fail in the AI era), https://levelup.gitconnected.com/stop-coding-like-its-2015-2c1f3728b735
  12. The AI Cost-Cutting Fallacy: Why “Doing More with Less” is Breaking, https://towardsai.net/p/machine-learning/the-ai-cost-cutting-fallacy-why-doing-more-with-less-is-breaking-engineering-teams
  13. Implicit vs. Explicit in Programming: Key Differences - Incredibuild, https://www.incredibuild.com/blog/implicit-vs-explicit-in-programming-key-differences
  14. What’s the Difference Between Implicit vs. Explicit Programming? - CloudBees, https://www.cloudbees.com/blog/what-is-the-difference-between-implicit-vs-explicit-programming
  15. 2월 15, 2026에 액세스, [https://medium.com/@jsathiskumar/ai-software-development-vs-traditional-software-development-part1-ed761cbc6090#::text=Traditional%20Software%20Development%3A%20Developers%20write,rules%20to%20produce%20consistent%20outputs.](https://medium.com/@jsathiskumar/ai-software-development-vs-traditional-software-development-part1-ed761cbc6090#::text=Traditional Software Development%3A Developers write, https://medium.com/@jsathiskumar/ai-software-development-vs-traditional-software-development-part1-ed761cbc6090#:~:text=Traditional%20Software%20Development%3A%20Developers%20write,rules%20to%20produce%20consistent%20outputs.
  16. The cognitive cost of non-determinism: Why AI engineering burns out differently | by Dominik Franczyk | Jan, 2026 | Medium, https://medium.com/@franczykdominik/the-cognitive-cost-of-non-determinism-why-ai-engineering-burns-out-differently-e658bff41ac8
  17. Guest Post - Food for Thought: What Are We Feeding LLMs, and How Will this Impact Humanity? - The Scholarly Kitchen, https://scholarlykitchen.sspnet.org/2023/12/11/guest-post-food-for-thought-what-are-we-feeding-llms-and-how-will-this-impact-humanity/
  18. IMPLICIT AND EXPLICIT STANCES IN LOGIC - ILLC Preprints and Publications, https://eprints.illc.uva.nl/1583/10/2018.Implicit.Explicit.5.pdf
  19. (PDF) Implicit and Explicit Stances in Logic - ResearchGate, https://www.researchgate.net/publication/328999203_Implicit_and_Explicit_Stances_in_Logic
  20. 1 IMPLICIT AND EXPLICIT STANCES IN LOGIC - ILLC Preprints and Publications, https://eprints.illc.uva.nl/id/eprint/474/1/PP-2013-02.text.pdf
  21. (Open Access) An Axiomatic Basis for Computer Programming, https://scispace.com/papers/an-axiomatic-basis-for-computer-programming-reprint-4re8jktrv4?citations_page=34
  22. Axiomatic Semantics and Hoare Logic Programming Languages (graduate) Spring 2025 - CS@Purdue, https://www.cs.purdue.edu/homes/suresh/565-Spring2025/lectures/Week10.pdf
  23. Lectures 20, 21: Axiomatic Semantics, https://www.csd.uoc.gr/~hy546/Lecture20-21.pdf
  24. Axiomatic Semantics, https://cseweb.ucsd.edu/classes/wi10/cse230/lectures/lec5.pdf
  25. Deterministic system - Wikipedia, https://en.wikipedia.org/wiki/Deterministic_system
  26. Deterministic system – Knowledge and References - Taylor & Francis, https://taylorandfrancis.com/knowledge/Engineering_and_technology/Systems_%26_control_engineering/Deterministic_system/
  27. Difference between Deterministic and Non-deterministic Algorithms - GeeksforGeeks, https://www.geeksforgeeks.org/dsa/difference-between-deterministic-and-non-deterministic-algorithms/
  28. Defeating Nondeterminism in LLM Inference - Thinking Machines Lab, https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
  29. The Definitive Guide to Prompt Engineering: From Principles to Production - Sundeep Teki, https://www.sundeepteki.org/advice/the-definitive-guide-to-prompt-engineering-from-principles-to-production
  30. ROLE OF DETERMINISM IN THEORY OF COMPUTATION | by Aahan Jain | Medium, https://medium.com/@aahan.jain20/role-of-determinism-in-theory-of-computation-ebccaeb6dd0a
  31. 2월 15, 2026에 액세스, [https://en.wikipedia.org/wiki/Deterministic_finite_automaton#::text=11.1%20Further%20reading-,Formal%20definition,an%20initial%20(or%20start)%20state](https://en.wikipedia.org/wiki/Deterministic_finite_automaton#::text=11.1 Further reading-,Formal definition, https://en.wikipedia.org/wiki/Deterministic_finite_automaton#:~:text=11.1%20Further%20reading-,Formal%20definition,an%20initial%20(or%20start)%20state
  32. Deterministic finite automaton - Wikipedia, https://en.wikipedia.org/wiki/Deterministic_finite_automaton
  33. Deterministic algorithm - Wikipedia, https://en.wikipedia.org/wiki/Deterministic_algorithm
  34. State machine - Glossary - MDN Web Docs, https://developer.mozilla.org/en-US/docs/Glossary/State_machine
  35. Control theory - Wikipedia, https://en.wikipedia.org/wiki/Control_theory
  36. Deterministic Optimal Control, https://www.math.uic.edu/~hanson/pub/SIAMbook/bk0AdetctrlAppendfinal.pdf
  37. Determinism in software engineering - Buttondown, https://buttondown.com/nelhage/archive/determinism-in-software-engineering/
  38. Determinism in Software - The Good, the Bad, and the Ugly, https://thrawn01.org/posts/determinism-in-software—the-good,-the-bad,-and-the-ugly
  39. The Architecture of LLM-Powered Applications: How It Differs from Conventional Software Architecture - Craig Risi, https://www.craigrisi.com/post/the-architecture-of-llm-powered-applications-how-it-differs-from-conventional-software-architecture
  40. 2월 15, 2026에 액세스, [https://eu.36kr.com/en/p/3345724973996929#::text=So%2C%20Software%201.0%20programs%20the,neural%20networks%20had%20fixed%20functions.](https://eu.36kr.com/en/p/3345724973996929#::text=So%2C Software 1.0 programs the, https://eu.36kr.com/en/p/3345724973996929#:~:text=So%2C%20Software%201.0%20programs%20the,neural%20networks%20had%20fixed%20functions.
  41. Building the Software 2 0 Stack (Andrej Karpathy) - YouTube, https://www.youtube.com/watch?v=y57wwucbXR8
  42. From Code To Vibes: Andrej Karpathy On The New Era Of Software | Verdentra, https://www.verdentra.com/article/from-code-to-vibes-andrej-karpathy-on-the-new-era-of-software/
  43. The Evolution of Observability: From Monoliths to AI Agents, https://www.honeyhive.ai/post/the-evolution-of-observability-from-monoliths-to-ai-agents
  44. The transition from Software 1.0 to Software 2.0 | Insights | Liontrust Asset Management PLC, https://www.liontrust.com/insights/blogs/2025/02/the-transition-from-software-1-to-software-2
  45. Software 1.0 vs Software 2.0 vs Software 3.0: A 3-Minute Breakdown | by Rohan Sharma, https://medium.com/@agile.cadre.testing/software-1-0-vs-software-2-0-vs-software-3-0-a-3-minute-breakdown-2fb17a16340f
  46. What is Deterministic AI: Concepts, Benefits, and Its Role in Building Reliable AI Agents (2025 Guide) - Kubiya, https://www.kubiya.ai/blog/what-is-deterministic-ai
  47. On Andrej Karpathy’s “Software 2.0” | by Seth Weidman | Medium, https://medium.com/@sethweidman/on-andrej-karpathys-software-2-0-a293cc15357
  48. What is Test Oracle in Software Testing? - testRigor AI-Based Automated Testing Tool, https://testrigor.com/blog/what-is-test-oracle-in-software-testing/
  49. The Oracle Problem in Software Testing: A Survey - Earl Barr, https://earlbarr.com/publications/testoracles.pdf
  50. (PDF) The Oracle Problem in Software Testing: A Survey - ResearchGate, https://www.researchgate.net/publication/276255185_The_Oracle_Problem_in_Software_Testing_A_Survey
  51. Test Oracle Strategies for Model-based Testing - University at Albany, https://www.albany.edu/faculty/offutt/research/papers/testOracle.pdf
  52. The Oracle Problem in Software Testing: A Survey - EECS 481, https://eecs481.org/readings/testoracles.pdf
  53. The Oracle Problem in Software Testing: A Survey - IEEE Xplore, https://ieeexplore.ieee.org/iel7/32/7106034/06963470.pdf
  54. Testing AI Systems: Handling the Test Oracle Problem - DEV Community, https://dev.to/qa-leaders/testing-ai-systems-handling-the-test-oracle-problem-3038
  55. The End of “Expected Result”: Why Traditional QA Fails in the AI Era | by Sadi Yıldız | Trendyol Tech | Feb, 2026 | Medium, https://medium.com/trendyol-tech/the-end-of-expected-result-why-traditional-qa-fails-in-the-ai-era-ba8318a3cbb5
  56. POLARIS: Is Multi-Agentic Reasoning the Next Wave in Engineering Self-Adaptive Systems? - arXiv, https://arxiv.org/html/2512.04702v1
  57. Solver-in-the-Loop: MDP-Based Benchmarks for Self-Correction and Behavioral Rationality in Operations Research - arXiv, https://arxiv.org/html/2601.21008v2
  58. Deterministic Execution as a Superior AI Substrate | by Robert Anderson | Medium, https://medium.com/@rdo.anderson/deterministic-execution-as-a-superior-ai-substrate-22dc4a8d2b51
  59. AIware in the Foundation Model Era - IEEE Xplore, https://ieeexplore.ieee.org/iel8/52/11316879/11319541.pdf
  60. Oracle-Verified Reasoning Supervision via Deterministic Generation (Verify-or-Fix + Witnesses + Traces) - Datasets - Hugging Face Forums, https://discuss.huggingface.co/t/oracle-verified-reasoning-supervision-via-deterministic-generation-verify-or-fix-witnesses-traces/172284
  61. Example of Tax Calculation Tax Formula - Oracle Help Center, https://docs.oracle.com/en/cloud/saas/financials/25d/faitx/example-of-tax-calculation-tax-formula.html
  62. Deterministic Functions in Oracle - Oracle Consulting Services | USA | 99% Customer Retention | Doyensys, https://doyensys.com/blogs/deterministic-functions-in-oracle/
  63. Introducing Select AI – Natural Language to SQL Generation on Autonomous Database, https://blogs.oracle.com/machinelearning/introducing-natural-language-to-sql-generation-on-autonomous-database
  64. Verify, Observe, and Secure your Generative AI usage with Oracle Autonomous AI Database Select AI | machinelearning, https://blogs.oracle.com/machinelearning/verify-observe-and-secure-your-gen-ai-usage-with-adb-select-ai
  65. Examples of Using Select AI - Oracle Help Center, https://docs.oracle.com/en-us/iaas/autonomous-database-serverless/doc/select-ai-examples.html
  66. Deterministic Workflow - Oracle Help Center, https://docs.oracle.com/en-us/iaas/Content/generative-ai-agents/adk/api-reference/examples/deterministic-workflow.htm
  67. The Agentic Transformation of Software Engineering | by Daniel Bentes | Medium, https://medium.com/@danielbentes/the-agentic-transformation-of-software-engineering-81d1d5dbd51e
  68. Beyond Pipelines: A Survey of the Paradigm Shift toward Model-native Agentic AI - arXiv, https://arxiv.org/html/2510.16720v2
  69. Tesla’s Neural Network Revolution: How Full Self-Driving Replaced 300000 Lines of Code with AI | FredPope.com, https://www.fredpope.com/blog/machine-learning/tesla-fsd-12
  70. What The Potential Of Software 2.0 Means For Tech Leaders - Forbes, https://www.forbes.com/councils/forbestechcouncil/2023/04/20/what-the-potential-of-software-20-means-for-tech-leaders/
  71. human Ai co↔Creation - POLITesi, https://www.politesi.polimi.it/bitstream/10589/240452/3/2025_07_Zoni.pdf
  72. What is a Deterministic System? | Vstorm Glossary, https://vstorm.co/glossary/deterministic-system/