프롬프트에서 하네스까지 — Ouroboros, Ralph Loop, 그리고 Harness Engineering의 세계

AI 코딩 패러다임의 진화 | Ouroboros의 명세 우선 워크플로우 | 모호성 점수와 온톨로지 수렴 | Ralph Loop의 자율 진화 | Harness Engineering의 3대 기둥 | 랄프톤 우승 사례

이 글은 Q00/ouroboros GitHub 리포지토리(4.2k stars), team-attention/ralphthon 아티팩트, 이재규의 유튜브 인터뷰(“평범한 사업가” 채널, 2026.05.16) 및 ZEP.us 소개 자료, Harness Engineering 관련 자료들을 NotebookLM으로 정리한 내용을 바탕으로 작성했다.

AI 코딩 패러다임의 3차 전환기

2022년부터 2026년 현재까지, AI 개발 패러다임은 세 번의 전환기를 거쳤다.

세 개념의 포함 관계를 먼저 확정하면 이해가 쉽다. 하네스 엔지니어링(패러다임)이 가장 큰 틀이고, Ouroboros(구현체)가 그 안의 도구, Ralph Loop(내부 메커니즘)가 Ouroboros의 핵심 기능이다.

이 전환의 배경에는 바이브 코딩(Vibe Coding)의 한계가 있다. CI/CD가 에이전트 규모에서 붕괴하는 현상도 같은 맥락에서 관찰된다. 변경 사항(diff)을 제대로 검토하지 않고 AI의 제안을 전부 수락하는 방식은 단기적으로는 빠르지만, 코드가 비정상적으로 자라나는 ‘숙취’를 남긴다. AI가 인간의 암묵지를 자의적으로 추측하면서 결과물이 통제 불능으로 발산하기 때문이다.

개발자의 역할이 재정의되고 있다. 직접 코드를 치는 실무자에서, AI가 올바른 궤도를 달릴 수 있도록 “판을 까는 설계자”로 변화하고 있다.

Harness Engineering의 본질

하네스(Harness)는 원래 통제 불가능한 말을 올바른 방향으로 인도하기 위해 채우는 마구(고삐, 안장)를 의미한다. AI 에이전트 문맥에서는 강력하지만 어디로 튈지 모르는 AI 모델을 제약 조건과 피드백 루프를 통해 올바른 궤도에 가두는 인프라 시스템이다.

3대 핵심 기둥

1. 컨텍스트 엔지니어링. 프로젝트 저장소를 단일 진실 공급원(Single Source of Truth)으로 삼아, AI가 참조할 모든 아키텍처 규칙과 문서를 제공한다. AGENTS.md, CLAUDE.md 같은 파일이 이 역할을 한다.

2. 아키텍처 제약 조건. 단순한 프롬프트 지시가 아니라, 구조적 룰을 위반하면 빌드를 실패하게 만드는 게이트(Gate) 시스템이다. 3-티어 아키텍처의 계층 간 의존성을 강제하여 AI가 계층을 우회하지 못하도록 차단한다.

3. 엔트로피 관리(가비지 컬렉션). 시간이 지나면서 AI가 작성한 코드에 생기는 문서 간 불일치, 불필요한 종속성, 죽은 코드를 정기적으로 청소하는 에이전트를 운영한다. 코드의 엔트로피가 증가하는 것을 시스템적으로 관리하는 것이다.

GitHub에서도 이 흐름이 확인된다. 2026년 5월 기준 awesome-harness-engineering, learn-harness-engineering 등의 리포지토리가 활발히 생성되고 있다.

하네스 구축 자체에도 상당한 초기 투자(설계 역량, 테스트 인프라, 토큰 비용)가 필요하다. 소규모 팀이나 프로토타이핑 단계에서는 오버헤드가 진입 장벽이 될 수 있다. Claude Code Harness로 VibeCoding 후 코드 체계 잡기에서 실전 경험을 정리했다.

Ouroboros — 명세 우선(Specification-First) 워크플로우 엔진

Q00/ouroboros는 “Stop prompting. Start specifying.”을 모토로 하는 Agent OS다. AI가 코드를 쓰기 전에, 막연한 아이디어를 검증된 명세로 바꿔주는 명세 우선 워크플로우 엔진이다.

대부분의 AI 코딩은 출력이 아니라 입력 단계에서 실패한다. 병목 현상의 원인은 AI의 능력이 아니라, 우리가 뭘 만들지 덜 정한 채 시작하기 때문이다. — Ouroboros 한국어 README

하나의 순환 — Interview부터 수렴까지

Ouroboros의 전체 흐름을 한눈에 보면 다음과 같다. 모호한 아이디어가 소크라테스식 인터뷰를 거쳐 명확한 명세(Seed)로 crystallize되고, Double Diamond로 실행되며, 3단계 평가를 통과한 결과가 다시 다음 세대의 입력으로 들어가는 루프다.

Interview → Seed → Execute → Evaluate
    ↑                           |
    +──── Evolutionary Loop ────+

Interview에서 숨겨진 가정을 드러내고, Seed에서 불변 명세를 만들고, Execute에서 Double Diamond로 분해 실행하고, Evaluate에서 3단계 검증을 거친다. 평가 결과가 충분히 수렴하지 않으면 다시 Interview로 돌아가 진화를 계속한다. 온톨로지 유사도가 0.95 이상이 되면 루프가 멈춘다.

소크라테스식 질문법

Ouroboros는 소크라테스의 철학을 차용한다. 좋은 질문은 더 깊은 질문으로 이어지며, 더 깊은 질문은 언제나 온톨로지(ontology)적이다. “이걸 어떻게 하지?”보다 “이게 정확히 뭐지?”를 먼저 묻는다.

"내가 원하는 게 뭐지?"   →   "내가 원하는 게 정확히 뭐지?"
"Task CLI를 만들자"      →   "Task가 뭐지? Priority는 뭐지?"
"인증 버그를 고치자"      →   "이게 근본 원인일까, 아니면 증상일까?"

이 철학을 Double Diamond 구조로 구현한다 — 두 개의 마름모가 각각 발산(diverge)과 수렴(converge)을 담당한다:

첫 번째 다이아몬드에서 질문을 넓혀(diverge) 온톨로지가 또렷해질 때 좁히고(converge), 두 번째 다이아몬드에서 설계 옵션을 넓혀 검증된 결과물로 좁힌다.

모호성 점수(Ambiguity Score)

Interview는 느낌으로 끝나지 않는다. 수학적 계산 점수가 기준 밑으로 내려와야 끝난다.

Ambiguity = 1 − Σ(clarityᵢ × weightᵢ)

각 차원의 가중치는 다음과 같다:

임계값: Ambiguity ≤ 0.2 — 이 아래로 내려와야 Seed(명세)를 생성할 수 있다.

왜 0.2일까? 가중 명확도가 80%면 남은 불확실성이 작아서 코드 수준의 판단으로도 충분히 풀 수 있기 때문이다. 그보다 모호하면 아직 아키텍처를 감으로 정하는 단계다.

9개의 에이전트 — 아홉 개의 사고(Nine Minds)

9개의 에이전트가 각자 다른 관점으로 교차 검증한다:

Seed에서 실행까지 — Assertion Criteria Tree

인터뷰가 끝나면 생성된 Seed는 어설션 크리테리아 트리(Assertion Criteria Tree)로 분해된다. 각 작업(job)이 아토믹(atomic)한지 판단하여 더 작은 단위로 쪼개고, DFS(Depth-First Search) 형태의 트리를 구성하여 하나의 에이전트가 처리하기 좋은 단위로 만든다. 이 과정에서 바이어스(bias)가 제거되며, 각 단계별로 실행이 이루어진다.

3단계 검증 게이트

평가(Evaluation)는 세 단계로 진행된다:

1. Mechanical — 무료. 기계적 검증 (타입 체크, 린트, 빌드 등). 자식 노드가 부모 노드로부터 평가받으며, 실패 시 에이전트들이 해결 방안을 논의한다
2. Semantic — 의미적 검증. 서로 다른 에이전트가 결과물을 보고 명세대로 완수했는지 교차 평가
3. Multi-Model Consensus — 다중 모델 합의. 여러 AI 모델이 독립적으로 평가하여 합의하며, 빠진 부분이 있으면 실패(fail) 처리

실패한 작업은 QA 모드를 통해 수정하거나, 진화 과정을 통해 개선된다.

Human-Outsider Loop

단계별 인간 검증도 가능하지만, Ouroboros는 휴먼 아웃사이더 루프(Human-outsider loop)를 지원한다. AI가 만든 결과물을 병렬로 처리할 때 큰 효율을 얻을 수 있는 방식으로, 인간이 루프 밖에서 모니터링하며 필요시에만 개입한다. 모니터링을 통해 작업이 잘 진행되었는지 파악하고, 필요시 이전 세대로 돌아가 다시 실행하거나 멈출 수 있다.

Ralph Loop — 멈추지 않는 진화 사이클

우로보로스(자기 꼬리를 삼키는 뱀)는 단순한 상징이 아니라 아키텍처 그 자체다:

Interview → Seed → Execute → Evaluate
    ↑                           |
    +──── Evolutionary Loop ────+

각 순환은 같은 것을 반복하는 게 아니다. 평가 결과가 다음 세대의 입력으로 돌아가고, 시스템이 지금 뭘 만드는지 분명해질 때까지 계속 진화한다.

ooo ralph 명령어는 수렴에 도달할 때까지 세션 경계를 넘어 지속적으로 진화 루프를 돌린다. 각 단계는 무상태(stateless)로 움직이며, EventStore가 전체 계보(lineage)를 다시 만들 수 있어 머신이 재시작돼도 중단된 지점에서 이어진다.

Ralph Cycle 1: evolve_step(lineage, seed) → Gen 1 → action=CONTINUE
Ralph Cycle 2: evolve_step(lineage)       → Gen 2 → action=CONTINUE
Ralph Cycle 3: evolve_step(lineage)       → Gen 3 → action=CONVERGED
                                                +-- Ralph 종료. 온톨로지가 안정됨.

온톨로지 수렴 — 뱀이 멈추는 시점

진화 루프는 끝없이 돌지 않는다. 연속된 세대가 온톨로지적으로 같은 스키마를 만들면 멈춘다:

Similarity = 0.5 × name_overlap + 0.3 × type_match + 0.2 × exact_match

임계값: Similarity ≥ 0.95 — 이 선을 넘으면 루프가 수렴하고 멈춘다.

시스템은 병리적 패턴도 함께 감지한다:

Gen 1: {Task, Priority, Status}
Gen 2: {Task, Priority, Status, DueDate}     → similarity 0.78 → CONTINUE
Gen 3: {Task, Priority, Status, DueDate}     → similarity 1.00 → CONVERGED

두 개의 수학적 관문: 충분히 분명해질 때까지는 만들지 않고(Ambiguity ≤ 0.2), 안정될 때까지는 진화를 계속한다(Similarity ≥ 0.95).

Ralph Loop와 Ouroboros의 관계 — 비교

랄프톤(Ralphthon) 우승 사례 — 이재규

이재규는 ZEP.us(네이버제트 × 슈퍼캣의 메타버스 교육 플랫폼)의 대표로, 랄프톤(Ralphthon) 1회 대회에서 우승했다. 랄프톤은 Ouroboros의 Ralph Loop를 기반으로 한 AI 코딩 해커톤으로, 2026년 3월 샌프란시스코에서 OpenAI 후원으로 열려 150명 이상이 참가했다.

우승의 비결

이재규의 유튜브 인터뷰에 따르면, 우승팀은 7시간 만에 인간의 개입 없이 10만 줄의 코드를 생성했다. 핵심 비결은 다음과 같다:

1. 모호성 점수의 철저한 제거. 코딩 시작 전 133번의 소크라테스식 인터뷰를 거쳐 모호성 점수를 0.05까지 낮추었다. 기본 임계값(0.2)보다 훨씬 엄격한 기준을 적용한 것이다.

2. 압도적 테스트 코드. 10만 줄 중 7만 줄(70%)이 테스트 코드였다. 강력한 자가 검증 시스템 덕분에 AI가 스스로 거짓말을 잡아내며 루프를 돌 수 있었다. 테스트가 곧 하네스였던 것이다.

3. 키보드를 건드리지 않은 개발. 인간은 코드를 직접 작성하지 않았다. 모호성을 제거하고, 테스트 코드로 안전망을 구축한 뒤, Ralph Loop가 수렴할 때까지 자율적으로 돌도록 내버려 두었다.

”I ship code I don’t read” — 하네스 구축 실전

Stripe의 AI 에이전트 팀은 인간 개발자의 개입 없이 주당 1,000개 이상의 PR을 스스로 처리한다고 한다. 하네스의 완성도는 “내가 이거 돌려놓고 노트북 덮고 자러 가도 아침에 수습할 일이 없는가”에 달려 있다.

인간이 아닌 에이전트를 위한 코드

“나는 내가 읽지 않는 코드를 배포한다(I ship code I don’t read)” — 이 말의 진정한 의미는, 인간이 읽기 좋은 코드가 아니라 AI 에이전트가 이해하고 고치기 좋은 구조적 환경(하네스)을 만드는 것이 궁극적인 생산성 향상의 길이라는 것이다.

유연성(Rippable) 확보

AI 모델은 무섭게 발전하므로, 특정 모델에 맞춰 복잡하게 만든 파이프라인은 나중에 짐이 될 수 있다. 하네스는 모델이 발전하면 언제든 쉽게 뜯어낼 수(rippable) 있도록 모듈형으로 유연하게 설계되어야 한다.

Ouroboros 내부에서도 이 원칙이 적용된다. PAL Router는 3단계 비용 최적화(Frugal 1x → Standard 10x → Frontier 30x)를 적용하며, 실패 시 자동 상향, 성공 시 자동 하향하여 모델 변화에 유연하게 대응한다.

Ouroboros 내부 구조

Ouroboros는 Python 3.12+ 기반으로 18개 패키지, 166개 모듈로 구성되어 있다:

src/ouroboros/
├── bigbang/         Interview, 모호성 점수 산정, brownfield 탐색
├── routing/         PAL Router — 3단계 비용 최적화 (1x / 10x / 30x)
├── execution/       Double Diamond, 계층적 AC 분해
├── evaluation/      Mechanical → Semantic → Multi-Model Consensus
├── evolution/       Wonder / Reflect 순환, 수렴 감지
├── resilience/      4가지 정체 패턴 감지, 5가지 측면 페르소나
├── observability/   3요소 드리프트 측정, 자동 회고
├── persistence/     Event Sourcing (SQLAlchemy + aiosqlite), 체크포인트
├── orchestrator/    런타임 추상화 레이어 (Claude Code, Codex CLI, OpenCode, Hermes)
├── core/            타입, 에러, Seed, 온톨로지, 보안
├── providers/       LiteLLM 어댑터 (100+ 모델)
├── mcp/             MCP 클라이언트/서버
├── plugin/          플러그인 시스템 (스킬/에이전트 자동 탐색)
├── tui/             터미널 UI 대시보드
└── cli/             Typer 기반 CLI

드리프트(Drift) 측정은 Goal(50%) + Constraint(30%) + Ontology(20%) 가중치로 계산되며, 임계값 ≤ 0.3을 유지한다.

Skill vs Sub-Agent

Ouroboros는 스킬(Skill)과 서브 에이전트(Sub-Agent)를 구분한다. 스킬은 자연어로 된 지시사항이지만 결정론적으로 실행되지 않을 수 있으며, 모델에 따라 호환성 문제가 발생할 수 있다. 반면 서브 에이전트는 더 구조화된 방식으로 작동하며 모델 변경에 따른 영향을 덜 받는다. Ouroboros는 스킬의 한계를 인지하고 하네스, 서브 에이전트, 네이티브 기능, MCP 등을 조합하여 안정적이고 유연한 시스템을 구축한다.

Agent OS로서의 비전과 MCP Mesh

이재규 인터뷰에 따르면, Ouroboros는 단순한 도구가 아닌 에이전트 OS로 진화할 계획이다. 다양한 하네스와 Claude Code, Codex CLI, OMC, OMO 등 여러 AI 도구들을 쉽게 올리고 활용할 수 있는 플랫폼을 지향한다. 분할 정복(Divide and Conquer)을 통해 복잡한 문제를 해결하며, MCP(Multi-call Protocol)를 활용하여 여러 MCP를 호출하는 방식으로 다양한 문제를 해결한다.

MCP는 모델 간의 소통 프로토콜로, HTTP와 유사하게 다양한 모델 및 툴과의 연동을 가능하게 한다. Ouroboros는 MCP 서버를 클라이언트로 활용하는 방식으로, 내부에서 다른 MCP를 호출하는 기능을 구현하여 확장성을 높였다. 이는 MCP 매쉬(Mesh)를 형성하며, 네트워크적으로도 유연하게 연결될 수 있다.

토큰 효율성과 비용 trade-off

하네스 엔지니어링 시대의 핵심은 토큰을 어떻게 효율적으로 사용하느냐이다. 이는 생산성과 직결된다. 단순히 많이 돌려서 좋은 결과가 나오기를 기대하는 것은 토큰 낭비다.

다만 Ralph Loop는 수렴할 때까지 최대 30세대를 돌며, 9개 에이전트가 교차 검증하고 3단계 평가(Mechanical/Semantic/Multi-Model Consensus)를 수행하는 구조상 토큰 소비량이 상당할 수 있다. 특히 Multi-Model Consensus 단계에서는 여러 모델을 독립 호출하므로 비용이 배증한다. 랄프톤 우승팀이 133번의 인터뷰와 7만 줄의 테스트 코드 생성에 소비한 총 토큰 비용은 공개되지 않았다. PAL Router의 비용 계층(Frugal/Standard/Frontier)이 완화책이지만, 전체 워크플로우의 ROI는 프로젝트 규모와 복잡도에 따라 달라진다.

실시간 모니터링 — TUI Dashboard

Ouroboros는 Textual 기반의 TUI(Text User Interface) 대시보드를 제공한다. ooo run이나 ooo evolve를 실행할 때 별도 터미널에서 함께 띄우면, 워크플로우의 전 과정을 실시간으로 모니터링할 수 있다.

# 설치 및 실행
uvx --from 'ouroboros-ai[tui]' ouroboros tui monitor

TUI는 4개의 화면을 제공한다:

Dashboard 화면은 세 영역으로 구성된다:

1. Double Diamond Phase Bar — 현재 실행 단계(Discover → Define → Design → Deliver)를 상단에 표시. 활성 단계가 자동으로 하이라이트된다
2. AC Execution Tree — 수용 기준(Acceptance Criteria)의 계층 구조를 트리로 시각화:

3. Node Detail Panel — 트리에서 선택한 AC의 ID, 상태, 깊이, 전체 내용을 표시

추가로 s 키로 Session Selector(세션 전환), e 키로 Lineage(진화 계보 — 세대별 온톨로지 변화 추적) 화면에 접근할 수 있다.

AI 시대, 개발자의 가장 강력한 해자(Moat)

AI 기저 모델(base model)은 누구나 쓸 수 있는 코모디티(commodity)가 되었다. 그러나 두 가지 능력은 여전히 인간의 영역이다:

1. 문제 정의 능력. 무엇을 만들지 본질을 파고드는 모호함 제거 능력. Ouroboros의 Interview가 자동화하지만, “무엇을 물어볼 것인가”의 시작점은 여전히 인간의 몫이다.

2. 시스템 설계 역량. 매번 다른 결과를 내는 비결정적(non-deterministic) AI를 흔들림 없는 결정론적(deterministic) 궤도 위에 올려놓는 하네스 설계. 모델이 아닌 시스템을 고치는 사고방식.

뱀은 반복하지 않는다 — 진화한다. — Q00/ouroboros

참고 자료