Ouroboros: AI가 코드를 쓰기 전에, 먼저 “무엇을 만들지”를 끝까지 묻는 시스템

요즘 AI 코딩 도구를 쓰다 보면 이상한 순간이 있습니다.
모델은 점점 똑똑해졌는데, 결과물은 생각보다 자주 빗나갑니다.

이유는 단순합니다.
AI가 코드를 못 짜서가 아니라, 우리가 원하는 것을 충분히 구체화하지 못한 채 바로 구현으로 들어가기 때문입니다.

Q00의 Ouroboros는 바로 그 지점을 정면으로 겨냥합니다. 이 프로젝트는 “좋은 프롬프트를 쓰는 법”보다 한 단계 앞에 있습니다. 애초에 프롬프트를 잘 쓰는 문제조차 넘어, 사람의 모호한 요구를 인터뷰로 해체하고, 명세로 굳힌 뒤, 그 다음에야 실행하는 시스템입니다. 저장소의 소개 문구도 이 철학을 분명하게 말합니다. “Stop prompting. Start specifying.” (GitHub)

당신이 말한 포인트도 정확합니다.
“중요한 계획을 해야 하는데, 내 스스로 질문하기 귀찮을 때 인터뷰 형식으로 문제를 구체화시킨다.”
Ouroboros의 매력은 딱 거기에 있습니다. 그냥 질문 몇 개 던지는 챗봇이 아니라, 질문을 통해 문제의 ontology, 즉 ‘이 문제가 본질적으로 무엇인가’를 파고드는 도구라는 점이 핵심입니다. (GitHub)

---

프로젝트 소개

Ouroboros는 명세 우선(specification-first) AI 개발 시스템입니다. 처음부터 코드를 생성하지 않고, 먼저 사용자와의 Socratic 인터뷰를 통해 숨겨진 가정과 빠진 조건을 드러낸 뒤, 이를 불변 Seed 명세로 고정하고, 이후 실행·평가·진화 루프로 이어갑니다. 저장소 기준으로 이 프로젝트는 Claude Code 플러그인으로 소개되며, 동시에 Python 기반 CLI, MCP 서버/클라이언트, TUI 모니터를 갖춘 꽤 큰 워크플로 엔진 형태로 발전해 있습니다. 2026년 3월 21일 기준 저장소는 약 1.6k 스타, 최신 릴리스는 v0.25.0, 메인 언어는 Python이며 일부 Rust TUI 크레이트를 포함합니다. (GitHub)

기술 스택도 꽤 명확합니다. 패키지 메타데이터를 보면 Python 3.12 이상을 요구하고, LiteLLM, Anthropic SDK, MCP, SQLAlchemy asyncio, aiosqlite, Claude Agent SDK, Rich, Prompt Toolkit 등을 사용합니다. 즉, 이 프로젝트는 단순한 프롬프트 모음이 아니라 LLM 라우팅, 이벤트 저장, 세션 복구, MCP 연동, 터미널 관측성까지 포함한 실제 런타임 시스템입니다. (GitHub)

---

왜 이 프로젝트가 등장했을까

Ouroboros가 흥미로운 이유는 “AI가 코딩을 대신한다”는 서사에 올라타면서도, 실제로는 그 반대 지점을 본다는 데 있습니다.

보통 AI 코딩 실패는 출력 문제처럼 보입니다. 코드가 틀렸고, 구조가 어설프고, 요구사항을 놓칩니다. 그런데 이 저장소는 문제를 다르게 진단합니다. 병목은 모델의 능력이 아니라 인간의 명확성이라고 봅니다. README에서도 “Most AI coding fails at the input, not the output”이라고 못 박고 있습니다. (GitHub)

이 철학은 단순히 “질문을 더 많이 하자” 수준이 아닙니다. 문서에서 반복해서 강조하는 건 Socratic Questioning과 Ontological Analysis입니다.
예를 들어 “task 관리 CLI를 만들고 싶다”는 말은 사실 아무것도 정하지 않은 말일 수 있습니다.

• task는 삭제 가능한가, 보관 가능한가
• 개인용인가, 팀용인가
• 우선순위는 숫자인가 enum인가
• 완료의 정의는 무엇인가
• due date가 필수인가 선택인가

이런 질문을 하지 않으면, AI는 겉보기로는 멀쩡한 결과물을 내더라도 결국 다시 뜯어고치게 됩니다. 그래서 Ouroboros는 “어떻게 만들까”보다 먼저 “그게 정확히 무엇인가”를 묻습니다. 이게 이 프로젝트가 등장한 기술적 배경입니다. (GitHub)

---

핵심 아이디어: 프롬프트가 아니라 인터뷰를 설계한다

이 프로젝트를 한 문장으로 요약하면 이렇습니다.

AI에게 바로 시키지 말고, 먼저 AI가 나를 인터뷰하게 만들어라.

여기서 인터뷰는 장식이 아닙니다. 실제로 Big Bang 단계에서 인터뷰 엔진이 돌아가고, 각 응답 뒤에는 ambiguity score가 계산됩니다. 문서상 인터뷰는 모호성 점수(ambiguous score)가 임계치 이하가 되어야 끝나며, README 기준 기본 게이트는 Ambiguity ≤ 0.2입니다. 이 수치가 만족돼야 Seed를 생성할 수 있습니다. (GitHub)

이 부분이 특히 좋습니다.
많은 도구가 “질문 몇 개 던지고 나서 알아서 진행”하는데, Ouroboros는 ‘이제 충분히 명확한가’를 감으로 판단하지 않고 수치화합니다.

공식 문서에 나온 식은 다음과 같습니다.

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

그리고 greenfield 기준으로 goal clarity 40%, constraint clarity 30%, success criteria 30% 비중으로 평가합니다. brownfield 작업에서는 기존 코드베이스 이해도까지 포함합니다. 즉, “질문을 한다”보다 더 정확히 말하면, 질문의 결과를 구조화하고 정량화해서 명세 생성 가능 여부를 판정하는 시스템입니다. (GitHub)

---

핵심 기능 1: Interview → Seed

사용자 관점에서 가장 체감되는 기능은 당연히 인터뷰입니다. CLI 문서 기준으로 ouroboros init "..." 또는 Claude Code 안에서는 ooo interview "..." 같은 흐름으로 시작합니다. 인터뷰는 초기 아이디어를 받아 점진적으로 질문을 던지고, 이를 바탕으로 Seed라는 불변 명세를 만듭니다. CLI 문서에서도 init 명령은 “interactive interview to refine requirements”로 설명됩니다. (GitHub)

Seed는 이 시스템의 헌법 같은 존재입니다. 아키텍처 문서에 따르면 Seed에는 목표, 제약사항, acceptance criteria, ontology schema, 종료 조건 등이 들어가며, 한 번 생성되면 frozen Pydantic 모델로 고정됩니다. 즉 실행 과정에서 마음대로 바꾸는 게 아니라, 바꾸려면 그 변경 자체가 검증 대상이 됩니다. (GitHub)

이게 왜 중요하냐면, 일반적인 AI 개발 도구는 대화가 길어질수록 목표가 미묘하게 바뀌기 쉽습니다. Ouroboros는 그 drift를 막기 위해 먼저 Seed를 굳혀버립니다.

예를 들어, 당신이 말한 식의 사용 장면을 이런 식으로 표현할 수 있습니다.

ouroboros init "중요한 개인 계획을 세우고 싶은데, 아직 목표와 제약이 정리되지 않았다"

그다음 인터뷰는 이런 방향으로 흘러가게 됩니다.

- 이 계획이 성공했다는 것은 어떤 상태인가?
- 시간 제약은 무엇인가?
- 실패하면 가장 큰 비용은 무엇인가?
- 당신이 아직 결정하지 못한 핵심 변수는 무엇인가?
- 이것이 문제인가, 아니면 더 큰 문제의 증상인가?

즉, “답변 입력창이 제일 많이 선택되는 선택지”라는 농담이 왜 나오는지 알겠습니다. 실제 가치가 답을 내가 길게 쓰는 데 있는 게 아니라, 내가 생각하지 않았던 질문을 강제로 만나게 하는 데 있기 때문입니다.

---

핵심 기능 2: PAL Router

Ouroboros가 단순 인터뷰 봇이 아닌 이유는, 인터뷰 이후 실행 단계에서도 꽤 엔지니어링다운 설계를 갖고 있기 때문입니다.

대표적인 것이 PAL Router(Progressive Adaptive LLM) 입니다. 이 라우터는 작업 복잡도에 따라 모델 티어를 Frugal, Standard, Frontier로 나누고, 비용 배수를 각각 1x, 10x, 30x로 설명합니다. 전략은 명확합니다. 처음엔 싼 모델로 시작하고, 실패할 때만 상향합니다. 반대로 안정적으로 성공하면 다시 하향합니다. (GitHub)

복잡도 계산도 꽤 구체적입니다.

• 토큰 수 30%
• 도구 의존성 수 30%
• AC 트리 중첩 깊이 40%

그리고 실패가 누적되면 Frugal → Standard → Frontier로 승급합니다. 이런 구조는 “좋은 모델을 무조건 비싸게 돌리자”가 아니라, AI 워크플로를 비용 최적화된 분산 시스템처럼 다룬다는 느낌을 줍니다. (GitHub)

---

핵심 기능 3: Double Diamond 실행

실행 단계는 디자인 씽킹에서 가져온 Double Diamond 패턴을 따릅니다.

• Discover: 문제를 넓게 탐색
• Define: 핵심 문제를 좁혀 정의
• Design: 해결책을 넓게 탐색
• Deliver: 실제 구현으로 수렴

문서상 execution/double_diamond.py, decomposition.py, atomicity.py, subagent.py 같은 모듈로 구현되어 있고, acceptance criteria를 재귀적으로 분해해 처리합니다. atomic한 작업이면 바로 Design/Deliver로 가고, atomic하지 않으면 2~5개의 자식 AC로 분해한 뒤 재귀적으로 수행합니다. 깊이 제한은 5, 깊이가 3 이상이면 컨텍스트를 압축하는 식의 안전장치도 있습니다. (GitHub)

이 구조를 개발자 관점에서 보면 아주 실용적입니다.
왜냐하면 “요구사항 전체를 한 번에 생성”하는 대신, 성공 조건이 있는 작은 실행 단위로 계속 쪼개기 때문입니다.

---

핵심 기능 4: Evaluation 파이프라인

Ouroboros의 또 다른 강점은 “생성”보다 “검증”을 꽤 무겁게 본다는 점입니다.

평가 파이프라인은 3단계입니다.

1. Mechanical: lint, build, test, static analysis 같은 저비용 체크
2. Semantic: acceptance criteria 충족, 목표 정합성, drift, uncertainty 평가
3. Consensus: 필요할 때만 다중 모델 합의 수행 (GitHub)

특히 좋은 부분은 Consensus를 무조건 돌리지 않는다는 점입니다.
아키텍처 문서에 따르면 다음과 같은 조건에서만 Stage 3가 발동합니다.

• Seed 수정
• ontology 변화
• 목표 재해석
• drift > 0.3
• semantic uncertainty > 0.3
• lateral thinking 채택 (GitHub)

즉, 평가 비용도 구조적으로 통제합니다.
이 프로젝트는 전반적으로 “철학적인 말”을 많이 하지만, 실제 구현은 꽤 현실적입니다. 비용, 실패, 드리프트, 상태 복구 같은 운영 문제를 계속 의식하고 있습니다.

---

핵심 기능 5: Ralph와 진화 루프

README에서 인상적인 부분 중 하나가 ooo ralph 입니다.
이건 한 번 실행하고 끝나는 커맨드가 아니라, 세션 경계를 넘어 지속적으로 진화 루프를 반복하는 모드입니다. EventStore를 통해 전체 lineage를 재구성하므로, 재시작 후에도 이어서 진행할 수 있다고 설명합니다. (GitHub)

루프 구조는 다음과 같습니다.

이 루프는 무한 반복이 아니라 ontology similarity ≥ 0.95가 되면 수렴으로 판정하고 멈춥니다. 또 3세대 연속 정체, A-B-A-B 식 진동, 질문 중복 70% 이상, 최대 30세대 같은 병적 패턴도 감지합니다. (GitHub)

이 부분은 그냥 “에이전트가 알아서 계속 개선한다”가 아니라, 반복을 종료시키는 수학적 기준이 있다는 점에서 의미가 있습니다.

---

프로젝트 아키텍처 분석

이 저장소를 아키텍처 관점에서 보면, 사실 핵심은 “질문 시스템”이 아니라 이벤트 소싱 기반 AI 워크플로 엔진입니다.

문서의 시스템 구조를 재구성하면 대략 이렇게 이해할 수 있습니다.

조금 더 구체적으로 보면, 이 시스템은 크게 여섯 층으로 읽힙니다.

1) Plugin Layer

Claude Code plugin 시스템과 연결되는 층입니다. README와 architecture 문서 기준으로 9개 스킬과 9개 에이전트가 있으며, 질문 전용 Socratic Interviewer, essence를 찾는 Ontologist, 사양을 굳히는 Seed Architect, 검증을 맡는 Evaluator 등이 분리돼 있습니다. (GitHub)

2) Core Layer

여기에는 Seed, acceptance criteria tree, ontology schema 같은 핵심 데이터 모델이 있습니다. 특히 Seed가 immutable이라는 점이 전체 설계의 기준점입니다. 실행 과정 전체가 결국 이 Seed를 중심으로 drift를 측정합니다. (GitHub)

3) Orchestration / Execution Layer

Big Bang → PAL Router → Double Diamond → Resilience → Evaluation → Secondary Loop로 이어지는 6단계 파이프라인이 있습니다. 즉 “인터뷰 후 실행”이 아니라, 명세 생성 이후의 풀 라이프사이클이 모두 구조화돼 있습니다. (GitHub)

4) State Layer

이 프로젝트를 진짜 시스템으로 보이게 만드는 부분입니다. 모든 상태 변경이 SQLite 기반 Event Store에 append-only 이벤트로 기록됩니다. 단일 events 테이블에 UUID, aggregate_type, aggregate_id, event_type, payload JSON, timestamp, consensus_id 등이 들어가고, 재생(replay)을 통해 세션을 복원할 수 있습니다. 5분 주기 체크포인트와 3단계 롤백 깊이도 문서화돼 있습니다. (GitHub)

5) Presentation Layer

TUI 모니터가 따로 있습니다. 대시보드, 실행 타임라인, 로그 뷰어, 디버그 상태 인스펙터를 제공하며, 실행 중 다른 터미널에서 상태를 관찰할 수 있습니다. 이건 실제 운영 경험을 꽤 중시한다는 뜻입니다. (GitHub)

6) Integration Layer

MCP 서버 모드와 MCP 클라이언트 모드를 모두 지원합니다. 즉 다른 AI 클라이언트에 Ouroboros 기능을 노출할 수도 있고, 반대로 외부 MCP 서버의 툴을 가져와 실행 중 사용할 수도 있습니다. 이 지점은 장기적으로 “명세 생성기”를 넘어 AI 워크플로 허브로 가려는 방향성으로 읽힙니다. (GitHub)

---

코드로 보면 어떤 느낌인가

공식 문서의 CLI를 기준으로 하면 가장 기본 흐름은 이렇습니다.

# 1) 아이디어를 인터뷰로 구체화
ouroboros init "Build a REST API for task management"

# 2) 생성된 seed를 실행
ouroboros run seed.yaml

# 3) 실시간 모니터링
ouroboros tui monitor

Claude Code 플러그인 안에서는 더 직관적인 흐름을 강조합니다.

ooo setup
ooo interview "I want to build a task management CLI"
ooo seed
ooo run
ooo evaluate

이 순서만 봐도 이 프로젝트의 세계관이 드러납니다.
대부분의 에이전트 도구는 run이 중심인데, Ouroboros는 interview와 seed가 중심입니다. (GitHub)

---

실제로 언제 쓰면 좋은가

이 프로젝트는 모든 개발 작업에 무조건 필요한 도구는 아닙니다. 오히려 문제가 구현보다 정의에 있는 상황에서 진가가 나옵니다.

예를 들면 이런 경우입니다.

1) 요구사항이 너무 추상적일 때

“개인 생산성 앱을 만들고 싶다”
“팀용 내부 툴이 필요하다”
“AI 에이전트 기반 자동화 시스템을 만들고 싶다”

이런 말은 시작점으로는 좋지만, 바로 코드를 뽑기에는 위험합니다. 이때 Ouroboros는 문제를 질문 가능한 조각들로 깨뜨리는 인터뷰 엔진으로 쓸 수 있습니다. (GitHub)

2) 브라운필드 프로젝트에서 요구가 자꾸 흔들릴 때

v0.20.0 릴리스에는 인터뷰가 코드베이스를 읽고 더 타깃된 질문을 하도록 개선됐다는 내용이 있습니다. 즉 기존 저장소를 가진 팀이 “뭘 바꿔야 하지?”를 정리할 때도 쓸 수 있습니다. 단순 greenfield 생성기보다 훨씬 유용한 방향입니다. (GitHub)

3) 실행보다 검증 비용이 더 큰 작업일 때

요구 해석이 한번 틀어지면 구현보다 수정 비용이 커지는 경우가 있습니다. B2B 관리툴, 내부 운영 시스템, 업무 자동화 도구, 규칙이 많은 CLI/백오피스 도구가 그렇습니다. 이런 작업은 초반 질문이 좋을수록 전체 리워크 비용이 줄어듭니다.

4) 혼자 중요한 계획을 구체화해야 할 때

이건 개발 밖의 영역까지 확장 가능합니다.
당신이 느낀 것처럼, “스스로 질문을 만들기 귀찮은데 정리는 해야 하는 상황”에서 꽤 쓸모 있습니다. 다만 이 경우엔 코드를 만드는 용도보다, 문제 명세화 인터뷰 도구로 쓰게 됩니다. README의 철학 자체가 인간의 clarity를 높이는 데 초점이 있기 때문에, 이건 의외로 프로젝트의 본질에 잘 맞는 사용법입니다. (GitHub)

---

이 프로젝트가 좋은 이유

제가 이 저장소를 좋게 보는 이유는 세 가지입니다.

첫째, AI 시대의 진짜 병목을 정확히 짚습니다.
모델 성능 경쟁이 아니라 요구 정의의 부실함이 더 큰 문제라는 진단은 설득력이 있습니다. README, 아키텍처 문서, 인터뷰 흐름, ambiguity gate가 모두 그 철학에 맞춰 정렬돼 있습니다. (GitHub)

둘째, 철학을 코드 구조로 내렸습니다.
많은 프로젝트가 “Socratic”, “ontology”, “agentic” 같은 단어를 마케팅으로 소비하는데, Ouroboros는 실제로 interview 엔진, ambiguity score, immutable seed, drift control, event sourcing, consensus trigger 같은 형태로 구현합니다. (GitHub)

셋째, 운영 관점이 생각보다 탄탄합니다.
TUI, 체크포인트, 세션 재개, MCP 연동, 비용 티어링은 해커톤 장난감보다 한 단계 위입니다. 특히 append-only 이벤트 로그와 replay 가능성은 장기 실행 에이전트에서 매우 강력한 설계입니다. (GitHub)

---

아쉬운 점과 현실적인 한계

좋은 프로젝트지만, 아직 거칠고 빠르게 진화하는 오픈소스라는 느낌도 분명합니다.

현재 열린 이슈를 보면 동시 세션 실행 시 SQLite lock/state collision 문제가 올라와 있습니다. 또 Stage 3 multi-model consensus가 OpenRouter 미설정 시 실제 다중 모델 투표처럼 보이지만 내부적으로는 그렇지 않다는 이슈도 있습니다. 즉, 아키텍처 아이디어는 강하지만, 운영 규모가 커질수록 상태 저장과 모델 구성의 일관성은 더 다듬어야 합니다. (GitHub)

릴리스 로그를 봐도 인터뷰 프롬프트 전달 문제, MCP 인터뷰 응답 불능, EventStore 통합, Windows 호환성 같은 수정이 최근까지 계속 이뤄졌습니다. 다시 말해 이 프로젝트는 안정화 완료 제품이라기보다, 아주 빠르게 진화 중인 실험적이지만 유망한 시스템에 가깝습니다. (GitHub)

---

한 줄 평가

Ouroboros는 “AI가 대신 만들어준다”는 환상을 파는 도구가 아닙니다.
오히려 더 냉정합니다.

당신은 아직 무엇을 만들지 충분히 이해하지 못했다. 그러니 먼저 질문받아야 한다.

이 메시지를 시스템 설계로 밀어붙인 프로젝트입니다.

그래서 이 저장소의 진짜 가치는 코드 생성기가 아니라,
질문 생성기,
더 정확히는 문제를 명세로 수렴시키는 인터뷰 엔진에 있습니다.

당신이 느낀 인상,
“무언가 중요한 계획을 해야 하는데 내 스스로 질문하기 귀찮을 때 인터뷰 형식으로 구체화시켜준다”는 감상은 꽤 본질적입니다.

다만 제 해석을 한 줄 덧붙이면 이렇습니다.

Ouroboros는 질문을 대신 해주는 도구가 아니라,
질문을 통해 생각의 빈칸을 강제로 드러내는 도구입니다.

그리고 AI 시대에는, 그게 생각보다 훨씬 중요한 인프라일 수 있습니다. (GitHub)