AI의 중요한 출력물이 독립적으로 검증 가능하다면, AI가 완벽하게 신뢰할 수 있을 필요는 없습니다.

대규모 언어 모델(Large Language Models, LLMs)은 장기적 추론(long-horizon reasoning) 능력이 점점 더 향상되고 있습니다.

이 모델들은 수학적 문제를 탐구하고, 복잡한 소프트웨어를 작성하며, 과학적 가설을 세우고, 장시간 동안 자율 에이전트(autonomous agents)로서 작동할 수 있습니다.

하지만 이러한 모든 진보의 이면에는 근본적인 엔지니어링 문제가 숨어 있습니다:

모델이 틀렸을 때 우리는 어떻게 알 수 있을까요?

챗봇에게 잘못된 답변은 불편한 정도일 수 있습니다.

하지만 자율 연구 에이전트(autonomous research agent)에게 잘못된 증명, 안전하지 않은 코드 변경, 또는 잘못된 과학적 결론은 시스템 수준의 실패로 이어질 수 있습니다.

해결책은 또 다른 프롬프팅(prompting) 계층을 추가하는 것이 아닐 수도 있습니다.

그것은 다른 아키텍처(architecture)일 수 있습니다.

추론(Reason) → 공식화(Formalize) → 검증(Verify)

전형적인 LLM 워크플로우는 다음과 같습니다:

문제(Problem)
   ↓
LLM
...

문제는 명백합니다.

최종 검증 단계는 종종 다음과 같습니다:

"이 답변이 설득력 있게 보이는가?"

그것은 검증이 아닙니다.

더 강력한 아키텍처는 **생성(generation)**과 **수락(acceptance)**을 분리합니다:

flowchart TD
    A[Problem] --> B[LLM Reasoning]
    B --> C[Candidate Solution]
...

모델은 가능성들을 생성합니다.

공식화(formalization) 계층은 이러한 가능성들을 명시적인 산출물(artifacts)로 변환합니다.

검증기(verifier)는 해당 산출물이 공식적인 점검(formal checking)을 통과할 수 있는지 결정합니다.

이것은 근본적으로 다른 신뢰 모델입니다.

Astra 질문

Astra라고 불리는 OpenAI의 차세대 주요 모델 제품군에 대한 최근 보도는 추론, 인간의 공식화, 그리고 기계가 점검하는 검증을 포함하는 파이프라인을 통해 생성된 것으로 알려진 수학적 결과에 주목하고 있습니다.

이 글에서 중요한 질문은 독립적인 구현이 Astra 자체를 재현할 수 있는지 여부가 아닙.

그것은 불가능합니다.

모델은 아직 출시되지 않았으며, 보고된 수학적 결과를 재현하려면 기반 시스템에 대한 접근 권한이 필요합니다.

흥미로운 연구 대상은 바로 이 **파이프라인 패턴(pipeline pattern)**입니다.

보고된 구조는 다음과 같이 표현될 수 있습니다:

┌──────────────────────┐
│      Reasoning       │
│        LLM           │
...

이러한 구분은 중요합니다.

우리는 모델을 복제하는 것이 아니라, 루프(loop)의 형태를 복제하는 것입니다.

왜 LLM 추론(Reasoning)만으로는 충분하지 않은가

LLM은 확률적 생성기(probabilistic generators)입니다.

추론 과정(reasoning trace)이 엄밀해 보일 때조차, 엄밀해 보이는 모습 그 자체가 정확성의 증거는 아닙니다.

모델은 다음과 같은 행동을 할 수 있습니다:

• 보조정리(lemma)를 지어냄
• 정리(theorem)를 잘못 사용함
• 필요한 가정(assumption)을 건너뜀
• 유효하지 않은 대수적 변환(algebraic transformation)을 수행함
• 상관관계(correlation)와 인과관계(causation)를 혼동함
• 겉보기에는 올바르지만 엣지 케이스(edge cases)에서 실패하는 코드를 생성함

모델의 추론 예산(reasoning budget)을 늘리면 성능이 향상될 수는 있습니다.

하지만 그것이 근본적인 문제를 제거하지는 못합니다.

모델은 여전히 생성기(generator)로 남아 있습니다.

따라서 다음과 같이 요구하는 대신:

"절대 실수하지 마세요."

우리는 다음과 같이 설계할 수 있습니다:

"실수는 수용되기 전에 반드시 탐지되어야 합니다."

이것이 훨씬 더 확장 가능한 엔지니어링 요구사항입니다.

작은 검증 루프(Verification-Loop) 프로토타입

이 아키텍처를 탐구하기 위해, 사용 가능한 모델들과 Lean을 사용하여 파이프라인 구조를 재현하는 작은 3단계 프로젝트를 구성할 수 있습니다.

이 프로토타입은 Astra의 능력을 재현한다고 주장하는 것을 의도적으로 피합니다.

그 목적은 루프 자체의 엔지니어링 트레이드오프(engineering tradeoffs)를 측정하는 데 있습니다.

아키텍처는 다음과 같이 구성됩니다:

stage1_reasoning.py
        │
        ▼
...

이 프로젝트는 성공과 실패를 모두 기록합니다.

이 점이 중요합니다.

성공적인 결과만을 기록하는 검증 시스템은 검증 시스템이 아닌, 성공 보고 시스템(success-reporting system)으로 전락하기 쉽습니다.

1단계 — 추론 (Reasoning)

첫 번째 단계는 LLM에게 후보 솔루션(candidate solution)을 생성하도록 요청합니다.

최소한의 구현은 다음과 같습니다:

from anthropic import Anthropic

client = Anthropic()
...

이 출력물은 아직 증명(proof)이 아닙니다.

그것은 가설(hypothesis)입니다.

그 구분은 시스템 아키텍처에서 명시적이어야 합니다.

파이프라인은 이를 다음과 같이 취급해야 합니다:

LLM output = Candidate

이 아니라:

LLM output = Truth

2단계 — 정식화 (Formalization)

다음 단계는 비정형적인 추론을 정식화된 산출물 (artifact)로 변환하는 것입니다.

이 과정은 의도적으로 인간 참여형 (human-in-the-loop) 방식으로 설계되었습니다.

그 이유는 무엇일까요?

자연어는 명시성이 부족하기 때문입니다.

다음의 차이를 고려해 보십시오:

"이 수열은 분명히 귀납적으로 따릅니다."

그리고 다음을 명시적으로 정의하는 정식 증명 (formal proof) 사이의 차이:

• 명제 (proposition)
• 기저 사례 (base case)
• 귀납 가설 (induction hypothesis)
• 귀납 단계 (induction step)
• 결론 (conclusion)

정식화 (Formalization)는 숨겨진 가정들을 드러나게 만듭니다.

그 결과물은 다음과 같은 Lean 정리 (theorem)가 될 수 있습니다:

theorem sum_first_n (n : Nat) :
  2 * (∑ k in Finset.range (n + 1), k) = n * (n + 1) := by
  ...

여기서 정확한 증명 자체보다는 아키텍처적 전환이 더 중요합니다:

자연어 논증 (Natural-language argument)
          ↓
정식 명제 (Formal proposition)
...

3단계 — 검증 (Verification)

이제 산출물은 신뢰 경계 (trust boundary)에 도달합니다.

Lean에게 다음과 같이 묻는 것이 아닙:

"이 설명이 합리적으로 들리나요?"

Lean에게 요구되는 것은 정식 증명 (formal proof)을 확인하는 것입니다.

단순한 검증 래퍼 (verification wrapper)는 결과를 다음과 같이 명시적으로 처리할 수 있습니다:

import subprocess

result = subprocess.run(
...

중요한 것은 Python 코드가 아닙니다.

바로 상태 머신 (state machine)입니다.

             ┌──────────┐
             │ Candidate│
             └────┬─────┘
...

그리고 놀라울 정도로 중요한 세 번째 상태가 있습니다:

SKIPPED

만약 Lean이 설치되어 있지 않다면, 시스템은 다음과 같이 보고해서는 안 됩니다:

VERIFIED

대신 다음과 같이 보고해야 합니다:

SKIPPED_NO_LEAN_INSTALLED

알 수 없음 (Unknown)은 성공이 아닙니다.

검증 경계 (The Verification Boundary)

이것이 핵심 설계 원칙입니다.

LLM은 확률적 환경 (probabilistic environment) 내에서 작동합니다.

검증기 (verifier)는 산출물이 명시적인 규칙을 충족해야만 하는 경계를 정의합니다.

flowchart LR
    subgraph P[Probabilistic Layer]
        A[LLM]
...

이 패턴은 단순히 모델의 지능을 높이는 것보다 훨씬 더 강력해질 수 있습니다.

수학을 넘어 일반화되는 패턴

검증기가 반드시 Lean일 필요는 없습니다.

아키텍처는 도메인 특화적(domain-specific)일 수 있습니다.

소프트웨어 엔지니어링 (Software Engineering)

LLM
 ↓
Code
...

사이버 보안 (Cybersecurity)

AI
 ↓
Threat Hypothesis
...

과학 연구 (Scientific Research)

AI
 ↓
Scientific Hypothesis
...

자율 에이전트 (Autonomous Agents)

Agent
 ↓
Plan
...

구현 방식은 변합니다.

원칙은 변하지 않습니다.

API 계약으로서의 검증 (Verification as an API Contract)

이 아키텍처를 생각하는 또 다른 방법이 있습니다.

검증기(verifier)를 API 계약(API contract)으로 취급할 수 있습니다.

LLM은 다음과 같은 결과를 반환할 수 있습니다:

{
  "type": "candidate",
  "artifact": "...",
...

하지만 시스템은 단지 신뢰도(confidence)가 높다는 이유만으로 해당 후보(candidate)를 수락하지 않습니다.

시스템은 결국 다음과 같은 형태를 생성해야 합니다:

{
  "type": "verified_artifact",
  "status": "PASS",
...

이는 다음 두 가지 사이의 깔끔한 분리를 만들어냅니다:

모델 신뢰도 (model confidence)

와

시스템 수락 (system acceptance)

이 둘은 같은 것이 아닙니다.

모델은 99%의 확신을 가질 수 있지만 여전히 틀릴 수 있습니다.

검증된 결과물(verified artifact)은 모델이 왜 확신했는지에 대해 검증기가 이해할 필요 없이 수락될 수 있습니다.

무엇을 측정해야 하는가? (What Should We Measure?)

이 아키텍처가 진지한 연구 방향이 되려면, 벤치마크 정확도(benchmark accuracy)만으로는 불충분합니다.

우리는 전체 파이프라인(pipeline)을 측정해야 합니다.

모든 문제에 대해:

추론 토큰 (Inference tokens)
API 비용 (API cost)
시도 횟수 (Number of attempts)
...

유용한 실험 표는 다음과 같은 모습일 수 있습니다:

단순히:

"어떤 모델이 더 똑똑한가?"

가 아니라:

"어떤 시스템이 검증된 결과물(verified artifacts)을 가장 효율적으로 생성하는가?"

입니다.

검증의 실제 비용 (The Real Cost of Verification)

다음과 같이 보고된 API 비용은:

$200 / 문제

검증 파이프라인의 경제성을 설명하기에 충분하지 않습니다.

실제 비용에는 다음이 포함되어야 합니다:

추론 (Inference)
+
인간의 형식화 (Human formalization)
...

더 의미 있는 지표는 다음과 같습니다:

총 검증 비용 (Total Verification Cost)
────────────────────────
성공적으로 검증된 문제 (Successfully Verified Problems)

이는 인간의 개입 (Human intervention)이 상당할 때 특히 중요해집니다.

추론 (Inference) 비용이 20달러이지만 전문가의 형식화 (Formalization)에 2시간이 필요한 시스템은, 추론 비용이 100달러이지만 인간의 개입이 5분밖에 필요하지 않은 시스템보다 실제로는 더 저렴하지 않을 수 있습니다.

실패는 데이터다 (Failure Is Data)

이 아키텍처 (Architecture)의 가장 강력한 특성 중 하나는 실패가 측정 가능해진다는 점입니다.

다음과 같은 방식 대신:

AI가 실패함.

우리는 다음과 같이 구분할 수 있습니다:

생성 실패 (GENERATION_FAILURE)
형식화 실패 (FORMALIZATION_FAILURE)
타입 오류 (TYPE_ERROR)
...

이는 우리에게 훨씬 더 유익한 연구 루프 (Research loop)를 제공합니다.

flowchart TD
    A[문제 (Problem)] --> B[생성 (Generate)]
    B --> C[형식화 (Formalize)]
...

이 시스템은 단순한 AI 래퍼 (AI wrapper)가 아니라 하나의 실험 도구 (Experimental instrument)가 됩니다.

이 프로토타입이 주장하지 않는 것

여기서는 과학적 절제가 중요합니다.

이 프로토타입은 다음을 주장하지 않습니다:

• Astra를 재현함
• Astra의 모델 아키텍처 (Model architecture)를 재현함
• Astra가 보고한 수학적 결과를 재현함
• Astra의 추론 능력 (Inference capabilities)과 일치함
• 동등한 비용 대비 성능을 확립함
• Astra에 대한 모든 외부 주장을 독립적으로 검증함

이 프로토타입은 **검증 루프 아키텍처 (Verification-loop architecture)**를 재현합니다.

그것은 훨씬 더 좁은 범위이며, 훨씬 더 방어 가능한 주장입니다.

더 큰 변화: 모델 중심에서 검증 중심 AI로

수년 동안 AI의 발전은 주로 다음과 같은 틀 안에서 논의되어 왔습니다:

더 큰 모델 (Bigger model)
      ↓
더 많은 연산량 (More compute)
...

다른 패러다임이 가능합니다:

더 나은 생성기 (Better generator)
      ↓
더 나은 후보 결과물 (Better candidate artifacts)
...

모델은 여전히 매우 중요합니다.

하지만 모델이 더 이상 시스템의 전부는 아닙니다.

이는 최적화 목표 (Optimization target)를 변화시킵니다.

다음을 극대화하는 대신:

파라미터당 지능 (Intelligence per parameter)

우리는 다음과 같이 생각하기 시작할 수 있습니다:

연산량 및 인간의 노력 단위당 검증된 능력 (Verified capability per unit of compute and human effort)

이것이 훨씬 더 흥미로운 시스템 문제 (Systems problem)입니다.

장기적 아키텍처

미래의 연구 에이전트 (Research agent)를 상상해 보십시오.

과학적 목표 (Scientific objective)를 수신합니다.

가설 (Hypotheses)을 생성합니다.

시뮬레이션 (Simulations)을 작성합니다.

수학적 논거 (Mathematical arguments)를 제안합니다.

코드 (Code)를 생성합니다.

자신의 가정 (Assumptions)을 테스트합니다.

그리고 모든 중요한 산출물 (Artifact)은 시스템의 신뢰할 수 있는 상태 (Trusted state)의 일부가 되기 전에 반드시 검증 경계 (Verification boundary)를 통과해야 합니다.

flowchart TD
    A[Research Objective] --> B[AI Research Agents]

...

이것은 챗봇 (Chatbot)이 아닙니다.

이것은 **검증 지향적 연구 운영체제 (Verification-oriented research operating system)**에 더 가깝습니다.

근본 원칙 (The Fundamental Principle)

핵심 아이디어는 한 문장으로 요약될 수 있습니다:

확률적 시스템 (Probabilistic systems)에게 완벽하게 정확할 책임을 지우지 마십시오. 대신 독립적으로 검증 가능한 산출물 (Artifacts)을 생성할 책임을 지우십시오.

이것이 환각 (Hallucinations)을 제거하는 것은 아닙니다.

다만 그 결과(Consequences)를 변화시킬 뿐입니다.

잘못된 가설은 거부될 수 있습니다.

실패한 증명은 수정될 수 있습니다.

망가진 코드는 테스트를 통과하지 못할 수 있습니다.

유효하지 않은 계획은 제약 조건 (Constraints)에 의해 차단될 수 있습니다.

시스템은 다음과 같이 말할 수 있는 능력을 갖추게 됩니다:

"모르겠습니다."

또는, 더 중요하게는:

"이것을 검증할 수 없습니다."

이것은 자율적인 AI 시스템 (Autonomous AI system)이 가질 수 있는 가장 중요한 능력 중 하나일 것입니다.

다음 단계는 무엇인가? (What Comes Next?)

다음 단계는 또 다른 이론적 도표가 아닙니다.

바로 실험 (Experimentation)입니다.

엄격한 평가 (Rigorous evaluation)는 다음과 같이 이루어져야 합니다:

1. 통제된 문제 세트 (Controlled problem set)를 선정합니다.
2. 여러 개의 독립적인 후보 솔루션 (Candidate solutions)을 생성합니다.
3. 정확한 토큰 사용량 (Token usage)과 비용을 기록합니다.
4. 인간의 형식화 노력 (Human formalization effort)을 측정합니다.
5. 후보들을 형식적 산출물 (Formal artifacts)로 변환합니다.
6. Lean 검증 (Lean verification)을 실행합니다.
7. 모든 실패 모드 (Failure mode)를 기록합니다.
8. 수정 반복 횟수 (Repair iterations)를 측정합니다.
9. 총 검증 비용 (Total verification cost)을 계산합니다.
10. 재현 가능한 산출물 (Reproducible artifacts)과 결과를 공개합니다.

그 시점에서 검증 루프 (Verification loop)는 측정 가능해집니다.

그리고 일단 측정 가능해지면, 우리는 이를 최적화 (Optimizing)하기 시작할 수 있습니다.

마지막 생각 (Final Thought)

차세대 AI는 모델이 얼마나 추론 (Reason)할 수 있는지에 의해서만 정의되지 않을 수도 있습니다.

모델이 추론을 한 **이후 (After)**에 어떤 일이 일어나는지에 의해 정의될 수도 있습니다.

미래의 아키텍처는 다음과 같을 수 있습니다:

AI가 생성합니다.
인간이 구조화합니다.
기계가 검증합니다.
...

그것은 신뢰할 수 있는 AI (Trustworthy AI)에 대한 다른 비전입니다.

결코 실수를 하지 않는 AI가 아닙니다.

중요한 실수가 인지되지 않은 채 용납되기 어려운 AI 시스템입니다.

그리고 그것이 신뢰할 수 있는 장기적 지능 (Long-horizon intelligence)을 향한 훨씬 더 현실적인 경로일 수 있습니다.

기술 스택 (Technical Stack)

이 기사에서 설명하는 프로토타입은 다음을 중심으로 설계되었습니다:

• Python
• Anthropic API
• Lean 4
• Mathlib
• 결정론적 검증 (Deterministic verification)
• 명시적 실패 상태 (Explicit failure states)
• 비용 및 토큰 계측 (Cost and token instrumentation)

구현은 아키텍처 수준에서 의도적으로 제공자 중립적 (Provider-agnostic)으로 설계되었습니다.

모델은 변경될 수 있습니다.