프롬프트를 멈추고 명세서를 시작하라: 우로보로스가 말하는 Agent OS의 조건
출처: AI SuperUser, 「하네스 엔지니어링이 궁금하다면 프롬프트를 멈추고 명세서를 작성하세요 l 랄프톤1위 수상자 우로보로스 개발자 이재규」, 2026-05-16. YouTube 자동 한국어 자막을 기반으로 정리했으므로 세부 용어에는 일부 자막 오류가 있을 수 있습니다.
AI 코딩 도구가 강해질수록 역설적으로 더 선명해지는 문제가 있다. 모델은 점점 더 많은 코드를 만들 수 있지만, 사용자는 여전히 “좋은 결과가 나올 때까지 슬롯머신을 당기는” 방식으로 일한다. 영상의 핵심 문장은 그래서 단순하다. 프롬프트를 더 잘 쓰는 법이 아니라, 프롬프트 이전의 명세 체계를 다시 설계해야 한다.
우로보로스 개발자 이재규는 자신을 “논디터미니스틱한 것을 디터미니스틱하게 바꾸는 사람”이라고 소개한다. 이 말은 LLM을 완전히 결정론적 시스템으로 만든다는 뜻이 아니다. 더 정확히는 비결정적 에이전트가 움직일 수 있는 계약면(contract surface) 을 좁히고, 그 안에서 실행·평가·진화가 반복되도록 하겠다는 뜻에 가깝다.
1. 병목은 모델 성능이 아니라 인간의 미정리된 의도다
영상 초반의 문제의식은 명확하다. 원샷으로 무언가를 만들려면 충분히 좋은 명세가 필요하다. 그렇지 않으면 모델은 발산하고, 사용자는 결과물을 보며 재작업한다. 이때 낭비되는 것은 단순한 토큰 비용이 아니라 생산성 그 자체다.
대부분의 AI 코딩 실패는 “출력 품질”의 문제처럼 보인다. 하지만 우로보로스의 관점에서는 실패의 상당 부분이 입력 이전에서 시작된다.
- 사용자의 머릿속 암묵지가 충분히 추출되지 않았다.
- 성공 기준이 코드 이전에 고정되지 않았다.
- 작업 단위가 에이전트가 수행하기 좋을 만큼 원자화되지 않았다.
- 평가가 “그럴듯해 보인다” 수준에서 끝난다.
그래서 우로보로스의 첫 단계는 코딩이 아니라 인터뷰다. 소크라테스식 질문으로 사용자의 애매한 요구, 숨은 제약, 성공 기준을 끄집어낸 뒤 그것을 seed spec으로 결정화한다.
2. SDD가 사라진 이유: 문서를 많이 넣는 것과 시스템이 되는 것은 다르다
영상 중반에서 흥미로운 대목은 SDD, 즉 Spec-Driven Development에 대한 진단이다. SDD는 한때 Claude Code와 함께 주목받았지만 오래 지속되지 못했다. 이재규의 해석은 “컨텍스트 엔지니어링에서 출발했기 때문”이다.
문서를 많이 넣으면 문제가 해결될 것처럼 보인다. 하지만 긴 컨텍스트는 모델의 primacy/recency bias와 lost-in-the-middle 문제를 만든다. 처음과 끝은 기억하지만 가운데의 핵심 제약은 흐려진다. 사용자가 버튼 하나를 원했는데 디자인 시스템을 만드는 식의 오버엔지니어링도 여기서 나온다.
따라서 명세는 단순히 긴 문서가 아니다. 명세는 다음 실행을 제한하는 계약이어야 한다.
| 느슨한 컨텍스트 | 실행 가능한 명세 |
|---|---|
| 참고자료를 많이 넣는다 | 성공 기준을 고정한다 |
| 모델이 알아서 해석한다 | 작업 단위를 원자화한다 |
| 대화가 길어질수록 흔들린다 | 실행·평가 루프가 같은 기준을 공유한다 |
| 결과를 보고 사람이 판단한다 | 평가자가 별도로 검증한다 |
핵심은 “텍스트를 더 많이 넣기”가 아니라 모델이 잊어도 시스템이 잊지 않는 구조를 만드는 것이다.
3. 우로보로스 루프: 인터뷰 → 시드 → 트리 → 실행 → 평가 → 진화
공개 README와 영상 설명을 합치면 우로보로스는 Agent OS를 이렇게 정의한다. 로컬 우선 런타임 레이어이며, 비결정적 에이전트 작업을 재현 가능하고 관측 가능하며 정책으로 묶인 실행 계약으로 바꾼다. 그 루프는 대략 다음과 같다.
- Interview — 소크라테스식 질문으로 사용자의 암묵지를 추출한다.
- Crystallize — 추출된 의도를 seed spec, ontology, acceptance criteria로 결정화한다.
- Decompose — acceptance criteria를 트리 구조로 쪼갠다. 각 task가 원자적인지 확인하며 계속 분해한다.
- Execute — Claude Code, Codex CLI, OpenCode, Hermes 등 실제 에이전트 런타임에 작업을 맡긴다.
- Evaluate — 실행 결과를 별도 평가 루프로 검증한다.
- Evolve — 결과물과 최초 seed를 비교해 빠진 의도와 새로 드러난 제약을 ontology에 반영한다.
중요한 것은 이 루프가 단순 자동화가 아니라는 점이다. 우로보로스는 에이전트가 “더 많이 하게” 만드는 도구라기보다, 에이전트가 덜 엉뚱하게 하게 만드는 도구다.
4. 스킬만으로는 부족한 이유: 자연어 절차는 모델에 종속된다
영상 후반에는 스킬과 서브에이전트, MCP에 대한 논의가 나온다. 이재규는 스킬을 부정하지 않는다. 스킬은 자연어 instruction으로 유용하다. 하지만 스킬이 두꺼워지고 모델별로 깎이기 시작하면 문제가 생긴다.
스킬은 자연어다. 해석자는 모델이다. 따라서 특정 모델에서 잘 돌던 스킬이 다른 모델, 혹은 같은 계열의 다음 버전에서 깨질 수 있다. 긴 스킬은 다시 lost-in-the-middle 문제를 만든다. 결국 두꺼운 스킬은 “절차”처럼 보이지만, 실제로는 모델 성능과 해석 습관에 크게 의존한다.
여기서 하네스의 역할이 나온다.
- 반복 가능한 것은 자연어가 아니라 도구 호출과 상태 전이로 내려야 한다.
- 판단이 필요한 것은 독립된 평가자나 서브에이전트로 분리해야 한다.
- 이벤트와 로그는 사람이 볼 수 있게 중계되어야 한다.
- 실패는 숨기지 말고 루프의 입력으로 다시 들어가야 한다.
이 방향은 NerdMakr/AutoGrowth 관점에서도 중요하다. “모든 입력은 에이전트로, 모든 출력도 에이전트에서”라는 철학은 방임형 자동화가 아니다. 오히려 인간이 개입하지 않아도 수렴할 수 있도록 계약, 관측, 평가, 피드백 경로를 만드는 일이다.
5. 관측 가능성: 블랙박스 에이전트는 오래 믿을 수 없다
우로보로스 데모에서 인상적인 부분은 TUI와 이벤트 중계다. 에이전트들이 어떤 phase에 있는지, 어떤 acceptance criteria가 쪼개지고 있는지, 어떤 generation에서 실패했는지, ontology가 어떻게 바뀌었는지를 보여준다.
이것은 단순한 개발자 편의 기능이 아니다. 에이전트 OS의 핵심 신뢰 장치다. 인간은 블랙박스를 오래 신뢰하지 못한다. 특히 여러 서브에이전트가 병렬로 움직이고, 평가와 진화가 반복되는 시스템에서는 “지금 무슨 일이 일어나는가”가 곧 제품의 일부가 된다.
관측 가능성이 없는 에이전트는 자동화가 아니라 도박에 가깝다. 관측 가능성이 있는 에이전트는 운영 가능한 시스템이 된다.
6. 실무 적용 체크리스트
이 영상의 메시지를 당장 팀의 AI 개발 흐름에 적용한다면, 다음 질문부터 시작할 수 있다.
- 이 작업의 seed spec은 한 문단으로 고정되어 있는가?
- 성공 기준은 사람이 보기 전에 에이전트가 검증할 수 있는 형태인가?
- 작업 단위는 한 에이전트가 끝까지 책임질 만큼 원자적인가?
- 실행자와 평가자가 분리되어 있는가?
- 결과물과 최초 의도를 비교해 명세가 진화하는 루프가 있는가?
- 스킬/프롬프트가 너무 두꺼워져 모델 해석에 의존하고 있지는 않은가?
- 진행 상황과 실패가 이벤트로 남고, 사람이 확인할 수 있는가?
결론: Agent OS는 ‘에이전트를 많이 붙이는 것’이 아니다
우로보로스가 던지는 진짜 질문은 “어떤 에이전트를 쓸 것인가”가 아니다. 질문은 이것이다.
비결정적 지능을 조직의 반복 가능한 생산 시스템으로 바꾸려면, 어떤 계약과 루프가 필요한가?
프롬프트는 여전히 필요하다. 스킬도 필요하다. 서브에이전트도 필요하다. 하지만 그것들이 흩어진 채 모델의 기분과 사용자의 재시도에 의존한다면, 우리는 여전히 슬롯머신을 당기고 있는 것이다.
하네스 엔지니어링의 다음 단계는 더 예쁜 프롬프트가 아니라 더 단단한 실행 계약이다. 그리고 그 계약은 인간의 암묵지를 추출하는 인터뷰에서 시작해, 명세와 평가와 진화 루프로 끝나야 한다.