FAST CAMPUS · CHAPTER 05 · KEYNOTE 2026

CHAPTER 05 · HARNESS ENGINEERING

5장. MCP형 하네스 프로젝트: 순서를 코드로 강제하는 법

순서를 코드로 강제하는 법

Fast Campus Harness Engineering Chapter Deck · decks/chapter-05.html

챕터 이동 이전 · 4장. 분업형 하네스 프로젝트 현재 · 5장. MCP형 하네스 프로젝트: 순서를 코드로 강제하는 법 다음 · 6장. AI Native 팀으로 가는 길 목차 5-1. 코드형 통제 도입 5-2. Capability Graph와 MCP 아키텍처 5-3. Satisfice 멈춤 기준 5장 통합 · MCP형 하네스 만들기 PROJECT · 5-4. 최종 프로젝트 및 케이스 스터디

COVER01 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE PART 5-1

MODULE · 5-1

5-1. 코드형 통제 도입

목표:
문서형·분업형으로 충분한 업무는 남기고,
순서·상태·재시도가 필요한 흐름만 MCP 후보로 올립니다.

LECTURE ARC 문서·분업 한계 → 필요 신호 3가지 → Ouroboros 워크스루 → 후보 flow

SECTION BREAK02 / 60

● SPEAKER NOTESSLIDE 02 / 60

섹션 전환

15~20분 슬라이드별 진행 계획

0:00-1:15 · 슬라이드 02 목표: "MCP를 쓰자"가 아니라 "MCP까지 필요한 업무만 남기자"로 프레임을 잡고, 5-1의 산출물이 다음 모듈의 설계 입력이 된다고 안내한다.
1:15-3:15 · 슬라이드 03 도입/문제상황: 규칙은 있는데 선행 질문, 명세 확정, 검수 통과 순서가 계속 깨지는 업무를 떠올리게 한다. 문서형·분업형으로 충분한 업무는 그대로 둔다고 강조한다.
3:15-6:45 · 슬라이드 04 핵심개념: 순서 강제는 gate, 상태 관리는 memory, 재시도는 branch라고 풀어 말한다. Ouroboros의 Seed, AC Tree, event store, rewind는 복제 대상이 아니라 관찰 언어로만 예고한다.
6:45-9:30 · 슬라이드 05 구조: md형 → 분업형 → MCP형을 통제 강도의 사다리로 비교하고, 어느 단계에서 "사람이 기억해서 지키는 운영"이 무너지는지 찾게 한다.
9:30-11:45 · 슬라이드 06 예시: 요구 확인 없이 실행으로 넘어간 흐름을 네 장면으로 읽으며, 어느 지점이 gate, memory, branch가 되는지 표시한다.
11:45-14:30 · 슬라이드 07 적용 워크스루: Ouroboros의 interview → Seed → execute → evaluate → event store/rewind 흐름을 gate, memory, branch 관찰표로 번역한다.
14:30-16:00 · 슬라이드 08 적용 질문: 본인 업무 하나에서 코드로 잠글 것과 사람 판단으로 남길 것을 구두로 나누게 한다.
16:00-18:30 · 슬라이드 09 실습 안내: MCP Candidate Flow를 채우며 순서, 상태, 재시도, 오케스트레이션 신호를 표시하고 5-2 Harness Graph 입력으로 남긴다.
18:30-19:30 · 슬라이드 10 요약/전환: 순서·상태·재시도가 확인된 업무만 5-2의 안/밖 경계 설계로 넘긴다.

5-1은 MCP로 바로 뛰어들지 않고, 어떤 신호가 보일 때 문서형 또는 분업형 하네스만으로 부족해지는지 판단하는 모듈이다.

오프닝에서 명확히 둘 기준은 두 가지다. 첫째, MCP는 더 고급이라서 선택하는 형식이 아니라 흐름을 사람이 기억해서 지키기 어려울 때 선택하는 통제 방식이다. 둘째, 5-4의 Ouroboros는 복제 대상이 아니라 4장에서 남긴 순서, 상태, 재시도, 평가, 복귀 지점의 빈칸이 어디에 고정되는지 관찰하는 reference anchor다.

2005-1-1 · 문서와 분업만으로 부족해지는 순간
2005-1-2 · gate·state·retry가 필요한 흐름 찾기
2005-1-3 · [실습] 내 업무의 MCP 후보 flow 찾기
Ouroboros anchor · interview → Seed → 실행 → 평가 → event store/rewind 흐름을 5-4에서 본격 분석하기에 앞서, 이 모듈에서는 필요성 route signal으로만 번역한다.

Primary source: curriculum.md rows 50-52.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-1-1

도입 목표: MCP로 올릴 업무만 남긴다

5-1. 코드형 통제 도입03 / 60

● SPEAKER NOTESSLIDE 03 / 60

2005-1-1 20분 확장 운영 · 00:00-20:00

5-1. 코드형 통제 도입의 이 클립은 20분 단독 진행을 기준으로 한다. 클립 제목은 문서와 분업만으로 부족해지는 순간이고, 핵심 내용은 사람이 마음대로 건너뛰는 순서는 코드로 잠근다이다. 산출물 기준은 강의 중 적용 질문 또는 다음 클립 입력로 둔다.

00:00-02:00 · 문제 연결: 문서와 분업만으로 부족해지는 순간의 문제 상황을 열고 핵심 문장 '사람이 마음대로 건너뛰는 순서는 코드로 잠근다'를 오늘의 route signal으로 둔다.
02:00-05:00 · 업무 신호: 본인이 실제 업무에서 같은 문제가 나타나는 신호를 찾게 한다. 추상 개념보다 최근 실패 흐름을 먼저 묻는다.
05:00-08:00 · 핵심 개념: 프롬프트 문장이 아니라 작업 구조, 경계, 확인 지점을 고정한다는 관점으로 개념을 정의한다.
08:00-11:00 · 구조화: 역할, 입력, 제약, 성공기준, 멈춤 조건 중 이 클립에서 잠가야 할 칸을 나누어 설명한다.
11:00-14:00 · 반례와 한계: 이 클립의 원칙이 적용되지 않는 경우를 짚고, 사람이 판단해야 할 영역을 남긴다.
14:00-17:00 · 적용 질문: 자기 업무 하나를 떠올리게 하고 오늘 배운 기준으로 한 줄 표시를 한다.
17:00-20:00 · 정리 / 전환: 핵심 문장을 다시 읽고 다음 클립에서 이어질 입력 또는 산출물로 연결한다.

20분 본인 운영 포인트

화면의 문장은 짧게 읽고, 실제 분량은 질문, 비교, 자기 업무 적용, 검수 멘트로 채운다.
본인이 적을 값은 한 번에 하나만 제시한다. 여러 칸을 동시에 채우게 하면 실습 시간이 산만해진다.
새 외부 사례나 검증되지 않은 수치 주장은 추가하지 않고 curriculum.md와 interview.md의 하네스 관점 안에서 설명한다.

진행 메모

curriculum.md 핵심 문장: 사람이 마음대로 건너뛰는 순서는 코드로 잠근다.
이 슬라이드는 목표와 문제상황을 같이 잡는다. 목표는 MCP를 권장하는 것이 아니라, 문서형과 분업형으로 충분한 업무를 먼저 걸러내는 것이다.
문서형 하네스는 규칙과 출력 형식을 고정하고, 분업형 하네스는 메인 세션의 맥락 소모를 줄인다. 하지만 어떤 단계를 반드시 먼저 해야 한다는 제약은 사람이 계속 지켜야 한다.
interview.md의 하네스 비유는 보충 맥락이다. 출발점, 중간 확인, 실패 시 복귀 지점이 필요해지면 그 흐름을 말로 부탁하지 말고 실행 구조로 만든다.
Ouroboros 참조 앵커를 짧게 예고한다. Seed와 AC Tree는 목표와 성공기준을 실행 입력으로 고정하는 예고편이고, event store와 rewind는 상태와 복귀 지점을 설명할 때 다시 연결한다.
다음 클립에서 이 필요 신호를 순서, 상태, 재시도 세 범주로 나눈다.

Primary source: curriculum.md rows 50-52.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-1 · RUNTIME LOCK-IN

한 런타임에 종속되면 정책 변화를 그대로 떠안는다. 그래서 런타임 독립으로 간다

2026-06-15 변화

headless / SDK가 별도 크레딧으로 분리

Claude Code의 -p 옵션(headless) 사용과 SDK를 통한 호출이 추가 $200 크레딧 한도에서만 처리된다. 한 세션 안 대화형 사용은 기존 Max Plan을 유지.

의미: 짚을 건 비용 액수가 아니라, Claude 한 곳에 자동화를 다 맡기면 이런 정책·요금 변화에 그대로 노출된다는 점이다.

결과

한 벤더에 종속되면 위험하다

지금까지 만든 하네스는 메인·보조를 나눴어도 모두 Claude 한 런타임 위에서 돌았다. 한 벤더의 정책·요금이 바뀌면 전체가 그 영향 아래 놓인다.

의미: 그래서 5장은 특정 런타임에 묶이지 않는 설계로 간다. capability를 런타임 독립 단위로 두고, adapter로 Claude·Codex 등을 갈아끼운다.

5-1. 코드형 통제 도입04 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-1-2

핵심개념: 기억이 아니라 강제해야 하는 신호

순서 강제

다음 단계 진입 조건을 코드가 확인한다.

상태 관리

현재 단계, 결정, 남은 질문을 다음 입력으로 남긴다.

재시도

실패 유형마다 가까운 체크포인트로 돌아간다.

Ouroboros 앵커

Seed, AC Tree, event store, rewind를 관찰 언어로 쓴다.

5-1. 코드형 통제 도입05 / 60

● SPEAKER NOTESSLIDE 05 / 60

2005-1-2 20분 확장 운영 · 00:00-20:00

5-1. 코드형 통제 도입의 이 클립은 20분 단독 진행을 기준으로 한다. 클립 제목은 gate·state·retry가 필요한 흐름 찾기이고, 핵심 내용은 gate·state·retry 신호가 보이면 workflow를 코드로 잠근다이다. 산출물 기준은 강의 중 적용 질문 또는 다음 클립 입력로 둔다.

00:00-02:00 · 문제 연결: gate·state·retry가 필요한 흐름 찾기의 문제 상황을 열고 핵심 문장 'gate·state·retry 신호가 보이면 workflow를 코드로 잠근다'를 오늘의 route signal으로 둔다.
02:00-05:00 · 업무 신호: 본인이 실제 업무에서 같은 문제가 나타나는 신호를 찾게 한다. 추상 개념보다 최근 실패 흐름을 먼저 묻는다.
05:00-08:00 · 핵심 개념: 프롬프트 문장이 아니라 작업 구조, 경계, 확인 지점을 고정한다는 관점으로 개념을 정의한다.
08:00-11:00 · 구조화: 역할, 입력, 제약, 성공기준, 멈춤 조건 중 이 클립에서 잠가야 할 칸을 나누어 설명한다.
11:00-14:00 · 반례와 한계: 이 클립의 원칙이 적용되지 않는 경우를 짚고, 사람이 판단해야 할 영역을 남긴다.
14:00-17:00 · 적용 질문: 자기 업무 하나를 떠올리게 하고 오늘 배운 기준으로 한 줄 표시를 한다.
17:00-20:00 · 정리 / 전환: 핵심 문장을 다시 읽고 다음 클립에서 이어질 입력 또는 산출물로 연결한다.

20분 본인 운영 포인트

화면의 문장은 짧게 읽고, 실제 분량은 질문, 비교, 자기 업무 적용, 검수 멘트로 채운다.
본인이 적을 값은 한 번에 하나만 제시한다. 여러 칸을 동시에 채우게 하면 실습 시간이 산만해진다.
새 외부 사례나 검증되지 않은 수치 주장은 추가하지 않고 curriculum.md와 interview.md의 하네스 관점 안에서 설명한다.

진행 메모

curriculum.md 핵심 문장: gate·state·retry 신호가 보이면 workflow를 코드로 잠근다.
이 슬라이드는 5-1의 핵심개념을 4분 정도로 충분히 펼친다. 세 단어를 gate, memory, branch로 바꿔 말하면 본인 업무에 대입하기 쉽다.
순서 강제는 "인터뷰를 하세요"라는 안내문이 아니라, 인터뷰 결과나 한 줄 명세가 없으면 다음 단계로 넘어가지 못하게 하는 gate다. 사람이 기억해서 지키면 문서형이고, 실행 구조가 막으면 MCP형 후보가 된다.
상태 관리는 로그를 많이 남기는 일이 아니라 다음 단계의 입력을 잃지 않는 일이다. 현재 단계, 확정한 결정, 남은 질문, 실패 이력이 다음 호출에 들어가지 않으면 새 세션은 같은 판단을 반복한다.
재시도는 실패를 한 번 더 시키는 것이 아니라 실패 유형을 보고 어느 체크포인트로 돌아갈지 고르는 branch다. 입력 누락이면 질문 단계, 기준 충돌이면 명세 단계, 품질 미달이면 검수 단계로 돌아간다고 예시를 든다.
Ouroboros 앵커는 네 단어로만 예고한다. Seed는 실행 입력 고정, AC Tree는 검수 기준, event store는 결정과 실패 이력, rewind는 복귀 지점이다.
interview.md의 Ouroboros 설명은 보충 맥락이다. Seed, AC Tree, Ralph 루프가 추측 대신 수렴을 만들었다는 철학을 본인의 업무용 MCP route signal으로 낮춰 적용한다.
본인 질문: "본인 업무에서 gate 없이 넘어가는 단계는 어디인가요?", "다음 세션이 반드시 알아야 할 memory는 무엇인가요?", "실패했을 때 처음부터가 아니라 어디로 branch해야 하나요?"
이때 "Ouroboros처럼 만들자"가 아니라 "내 업무에서 어떤 위치가 Seed, AC Tree, event store, rewind에 해당하는지 관찰하자"로 표현한다.
전환 멘트: 세 신호를 구분했으니, 이제 문서형·분업형·MCP형 중 어디까지 필요한지 판단 구조로 내려간다.

Primary source: curriculum.md rows 50-52.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-1 · STRUCTURE

판단 구조: 필요한 통제 강도만 올린다

하네스 형태	유지 기준	MCP 전환 신호
md형	규칙과 출력 형식을 문서로 고정하면 반복 가능하다.	규칙을 읽어도 선행 단계를 건너뛰면 품질이 무너진다.
분업형	작업 분해와 handoff로 메인 맥락을 지킬 수 있다.	handoff 뒤 현재 단계, 결정, 실패 이력이 계속 사라진다.
MCP형	진입 조건, 상태 기록, 재시도 분기가 실행 구조 안에 있어야 한다.	순서·상태·재시도가 반복 업무의 품질 조건이 된다.

5-1. 코드형 통제 도입06 / 60

● SPEAKER NOTESSLIDE 06 / 60

구조 설명

이 표는 1장과 4장에서 다룬 md형, 분업형 흐름을 버리지 않고, 필요한 경우에만 MCP형으로 올리는 판단 구조다.
md형은 규칙과 출력 형식이 핵심이고, 분업형은 작업 분해와 handoff가 핵심이다. 5-1에서는 여기에 순서, 상태, 재시도, 체크포인트가 필요한지를 추가로 본다.
강의 포인트는 "한 단계씩만 올린다"이다. 규칙만으로 안정화되면 md형에 둔다. 역할 분리와 handoff만으로 안정화되면 분업형에 둔다. 그래도 gate, memory, branch가 계속 깨질 때만 MCP형 후보로 올린다.
md형 행에서는 "규칙을 안 읽어서"가 아니라 "규칙을 읽어도 실행 순서가 제어되지 않아서" 문제가 생기는지 확인한다. 단순 누락은 문서 보강으로 충분할 수 있다.
분업형 행에서는 보조 세션이 일을 잘했는지가 아니라, handoff 이후에도 현재 단계와 결정 이력이 다음 실행에 남는지를 본다. 상태가 계속 사라지면 코드형 상태 관리가 필요해진다.
MCP형 행에서는 순서, 상태, 재시도가 반복 업무의 품질 조건인지 확인한다. 셋 중 하나만 약하게 있으면 과설계일 수 있고, 둘 이상이 반복적으로 품질을 어긋나면 다음 실습의 후보로 삼는다.
MCP형은 "더 고급이라서" 쓰는 것이 아니라, 사람이 기억해서 지키는 흐름이 품질을 어긋날 때 선택한다.
전환 멘트: 이제 이 판단 구조를 실제 흐름 하나에 대입해 어디를 잠글지 본다.

Primary source: curriculum.md rows 50-52.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-1 · SCENARIO

예시: 검수 전에 실행으로 건너뛴 업무

요구 확인 생략

선행 질문 없이 실행해 산출물은 빠르지만 기준이 비어 있다.

명세 없는 실행

어떤 결정이 끝났고 어떤 질문이 남았는지 다음 단계가 모른다.

검수 실패 반복

기준 미달 때 돌아갈 지점이 없어 같은 수정을 반복한다.

잠글 지점

질문 완료, 명세 확정, 검수 통과를 진입 조건으로 둔다.

5-1. 코드형 통제 도입07 / 60

● SPEAKER NOTESSLIDE 07 / 60

예시 해설

새 외부 사례가 아니라 본인 업무에 대입할 수 있는 일반적인 흐름으로 설명한다.
기본 장면은 "요청을 받자마자 실행한 뒤 검수에서 다시 막히는 반복 업무"다. 결과물이 빨리 나오는 것처럼 보여도, 나중에 검수 기준을 맞추느라 같은 수정을 반복한다.
요구 확인 생략은 gate 문제다. 질문 카드나 한 줄 명세가 비어 있는데 실행으로 넘어간다면, 이 흐름은 사람이 조심한다고 해결되지 않을 수 있다.
명세 없는 실행은 memory 문제다. 어떤 질문이 해결됐고, 어떤 결정이 보류됐고, 어떤 제약이 확정됐는지가 다음 단계의 입력으로 남아야 한다.
검수 실패 반복은 branch 문제다. 입력 누락이면 질문으로, 기준 충돌이면 명세로, 산출물 품질만 부족하면 실행 보정으로 돌아가야 한다. 모두 처음부터 다시 돌리면 하네스가 아니라 소모전이 된다.
핵심은 모든 단계를 자동화하는 것이 아니다. 질문 완료, 명세 확정, 검수 통과처럼 다음 단계로 넘어가기 전 반드시 확인해야 하는 지점을 찾는 것이다.
Ouroboros 관찰 언어로 바꾸면 질문·명세는 Seed 후보, 검수 기준은 AC Tree 후보, 결정과 실패 기록은 event store 후보, 돌아갈 지점은 rewind 후보가 된다. 단, 이 모듈에서는 구현하지 않고 필요성 판단에만 쓴다.
전환 멘트: 이 예시를 Ouroboros 흐름에 대입해도 같은 질문이 나온다. 복제하지 않고 관찰 언어로만 읽어 본다.

Primary source: curriculum.md rows 50-52.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-1 · OUROBOROS WALKTHROUGH

적용 워크스루: Ouroboros를 판단 언어로 읽기

Ouroboros 흐름	5-1 통제 신호	내 업무 판단 질문
Interview → Seed	gate · 질문과 명세 없이는 실행 금지	선행 입력이 비면 다음 단계를 막아야 하는가?
Seed → AC Tree	memory · 목표, 제약, 성공기준 보존	결정과 기준이 다음 단계 입력으로 남는가?
Execute → Evaluate	gate · 검수 전 완료 처리 금지	평가 없이 완료로 넘어가 품질이 어긋나는가?
Event store → Rewind	branch · 실패 유형별 복귀 지점	처음부터가 아니라 돌아갈 체크포인트가 있는가?

5-1. 코드형 통제 도입08 / 60

● SPEAKER NOTESSLIDE 08 / 60

Ouroboros 적용 워크스루

이 슬라이드는 5-4 case study의 예고편이다. Ouroboros를 복제 대상으로 소개하지 않고, 5-1의 필요성 후보 flow를 채우기 위한 관찰 언어로만 사용한다.
첫 행은 gate다. interview.md의 Socratic Interview와 Seed 흐름은 사람의 암묵지를 실행 가능한 입력으로 고정하는 장치로 설명한다. 본인 업무에서는 질문이나 한 줄 명세가 비었을 때 실행 단계 진입을 막아야 하는지 묻는다.
둘째 행은 memory다. Seed와 AC Tree는 목표, 제약, 성공기준이 다음 실행과 검수 단계에 남아야 한다는 예시다. 여기서 "문서를 저장한다"가 아니라 "다음 단계 입력으로 보존한다"는 차이를 강조한다.
셋째 행은 두 번째 gate다. execute 결과가 곧 완료가 아니라 evaluate를 통과해야 한다는 구조로 설명한다. 본인 업무에서는 검수 전 완료 처리 때문에 품질이 어긋난 경험을 떠올리게 한다.
넷째 행은 branch다. event store와 rewind는 결정, 실패 사유, 복귀 지점을 남겨 반복을 처음부터 다시 시작하지 않게 하는 관찰 포인트다. 이때 runtime 보장이나 설치 검증을 주장하지 않고, interview.md와 5-4 reference notes의 구조 설명 범위에 머문다.
본인 질문: "이 네 행 중 본인 업무에서 가장 자주 깨지는 것은 무엇인가요?", "그 지점은 문서 보강으로 충분한가요, 아니면 실행 구조가 막아야 하나요?"
전환 멘트: 이제 같은 질문을 자신의 업무에 적용해 코드로 잠글 지점과 사람 판단으로 남길 지점을 나눈다.

Primary source: curriculum.md rows 50-52.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-1 · APPLICATION QUESTION

적용 질문: 어디를 코드로 잠글까

순서

건너뛰면 품질이 무너지는 선행 단계

상태

다음 단계가 반드시 알아야 할 결정과 실패 이력은 무엇인가?

재시도

검수 실패 시 처음부터가 아니라 어디로 돌아가야 하는가?

사람 판단

코드가 대신 결정하면 안 되는 업무 맥락

5-1. 코드형 통제 도입09 / 60

● SPEAKER NOTESSLIDE 09 / 60

적용 질문

최근 반복 업무 하나를 떠올리게 하고, 네 질문에 짧게 답한다.
순서 질문은 "무엇을 먼저 해야 하는가"가 아니라 "건너뛰면 품질이 실제로 무너지는가"를 묻는다.
상태 질문은 다음 단계가 필요한 결정, 남은 질문, 실패 이력을 분리하게 한다. 재시도 질문은 실패했을 때 되돌아갈 가장 가까운 체크포인트를 찾게 한다.
사람 판단 질문은 5-2의 안/밖 경계로 이어진다. MCP 후보를 고르더라도 문제 정의와 최종 수용 판단까지 안쪽에 넣지 않는다는 점을 미리 깔아둔다.
전환 멘트: 이제 이 네 질문을 표로 옮겨 각자 업무가 md형, 분업형, MCP형 중 어디에 머물러야 하는지 결정한다.

Primary source: curriculum.md rows 50-52.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-1-3

[실습] 4-4 분업형 하네스에서 MCP로 바꿀 부분 가리기

실습 목표

4-4에서 만든 분업형 하네스의 어느 부분을 MCP로 잠글지 가린다.

수행 과제

각 단계의 순서·상태·재시도 신호를 보고 MCP 전환 부분을 표시하고, 묶을 스킬을 분류한다.

산출물

MCP 전환 후보 + 스킬 분류

완료 기준

분업형 하네스의 어느 부분이 MCP형으로 가고, 어떤 스킬로 묶이는지 설명할 수 있다.

MCP Candidate Flow

신호	확인 질문	표시	판단
순서 강제	인터뷰 → 명세 → 실행 순서를 어기면 품질이 무너지는가?	예 / 아니오	예면 MCP 후보
상태 관리	현재 단계, 결정, 실패 이력을 남겨야 하는가?	예 / 아니오	예면 MCP 후보
재시도	실패했을 때 돌아갈 체크포인트가 필요한가?	예 / 아니오	예면 MCP 후보
오케스트레이션	여러 단계와 도구 호출을 실행 구조가 묶어야 하는가?	예 / 아니오	상태·재시도와 함께 있으면 MCP형

5-1. 코드형 통제 도입10 / 60

● SPEAKER NOTESSLIDE 10 / 60

2005-1-3 20분 확장 운영 · 00:00-20:00

5-1. 코드형 통제 도입의 이 클립은 20분 단독 진행을 기준으로 한다. 클립 제목은 [실습] 내 업무의 MCP 후보 flow 찾기이고, 핵심 내용은 언제 MCP까지 가야 하는지 스스로 판단한다이다. 산출물 기준은 MCP Candidate Flow로 둔다.

00:00-02:00 · 산출물 확인: 이 클립은 실습이 반드시 필요하다. MCP Candidate Flow를 오늘의 제출 단위로 확인하고 핵심 문장 '언제 MCP까지 가야 하는지 스스로 판단한다'를 완료 기준으로 둔다.
02:00-04:00 · 입력 정리: 앞 클립에서 만든 질문, 표, 초안, route signal 중 이번 산출물에 넣을 입력만 고른다.
04:00-08:00 · 첫 작성: 빈칸을 완벽히 채우려 하지 말고 제목, 목적, 입력, 제약, 완료 기준부터 빠르게 적는다.
08:00-12:00 · 핵심 작성: 산출물의 중심 칸을 채운다. 모르는 값은 추측하지 않고 질문 또는 확인 필요로 남긴다.
12:00-15:00 · 자기 검수: 형식이 맞는지, 핵심 문장이 드러나는지, 사람 판단 영역이 남아 있는지 확인한다.
15:00-18:00 · 수정: 가장 모호한 문장 하나와 가장 위험한 빈칸 하나를 골라 좁힌다.
18:00-20:00 · 제출 / 전환: MCP Candidate Flow의 완료 기준을 확인하고 다음 클립에서 재사용할 값과 버릴 값을 나눈다.

20분 본인 운영 포인트

화면의 문장은 짧게 읽고, 실제 분량은 질문, 비교, 자기 업무 적용, 검수 멘트로 채운다.
본인이 적을 값은 한 번에 하나만 제시한다. 여러 칸을 동시에 채우게 하면 실습 시간이 산만해진다.
새 외부 사례나 검증되지 않은 수치 주장은 추가하지 않고 curriculum.md와 interview.md의 하네스 관점 안에서 설명한다.

실습 절차 / 체크포인트

실습 목표: 언제 MCP까지 가야 하는지 스스로 판단한다.
수행 과제: 최근 반복 업무 하나를 고르고, 단계가 반드시 지켜져야 하는지, 중간 상태를 저장해야 하는지, 실패 후 재시도가 필요한지 표시한다.
수행 절차 1: 최근 반복 업무 하나를 입력, 처리 단계, 산출물로 나눈다.
수행 절차 2: 순서 강제, 상태 관리, 재시도, 오케스트레이션 신호가 있는지 각각 표시한다.
수행 절차 3: md형으로 충분한 항목과 MCP형으로 넘겨야 할 항목을 나누고 판단 이유를 적는다.
본문의 후보 flow는 신호, 확인 질문, 표시, 판단 순서로 채운다. 모든 칸을 "예"로 만들 필요는 없고, 상태와 재시도까지 필요한 업무만 MCP형 후보로 올린다.
산출물 이름: MCP Candidate Flow.
체크포인트: 순서 강제가 약하면 md 규칙서로 충분한지 먼저 본다. 상태와 재시도까지 필요하면 MCP형 하네스 후보로 올린다.
체크포인트: 실습 결과가 다음 모듈의 MCP 안/밖 경계 설계로 이어져야 한다.
완료 확인 체크포인트: MCP Candidate Flow에 순서 강제, 상태 관리, 재시도, 오케스트레이션 신호와 선택한 하네스 유형이 적혀 있으면 실습 완료로 본다.

Primary source: curriculum.md rows 50-52.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-1 · SUMMARY

5-1 정리: MCP 후보만 다음 단계로 보낸다

5-1. 코드형 통제 도입11 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE PART 5-2

MODULE · 5-2

5-2. Capability Graph와 MCP 아키텍처

런타임(Claude / Codex / OpenCode / Hermes / Kiro / Copilot, Gemini 등 추가 adapter 포함)을 갈아끼워도 같은 workflow가 도는 추상화를
Capability Matrix와 Capability Graph로 묶는다.
MCP는 그 graph를 코드형 orchestration boundary로 강제하는 실행 지점이다.

LECTURE ARC MCP 뒤집기 → MCP 본질 + 2026-07-28 → Capability Matrix → 스킬 추상화 → 실습

SECTION BREAK12 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · MCP INVERSION

5-2의 출발

MCP를 새로운 시각으로 본다. 툴이 LLM을 쓴다

5-2. Capability Graph와 MCP 아키텍처13 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · INSIDE ooo run

ooo run 한 번이면 바깥엔 툴 콜 하나, 안엔 에이전트가 돈다

5-2. Capability Graph와 MCP 아키텍처14 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · WHY IT MATTERS

방향을 뒤집으니 셋이 동시에 풀렸다

런타임 독립

AgentRuntime + LLMAdapter 두 층을 두니 Claude Code든 Codex든 같은 워크플로우가 돈다. 설계 하나로 여러 플랫폼.

Hook 대체

이제 Codex에도 Hook이 생겼지만 훅 방식은 런타임마다 다르다. MCP 자체의 이벤트로 훅 역할을 대체하면 프로바이더 모두에서 같은 방식으로 순서를 강제할 수 있다. 런타임이 달라도 방식은 같다.

호출 구조 확정

LLM 출력은 비결정이다. 그래도 언제·무엇이·어떤 순서로 호출되는지는 코드가 정한다. 안에서 뭐라 답하든 파이프라인은 동일하게 흐른다.

5-2. Capability Graph와 MCP 아키텍처15 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · CONTEXT

MCP는 도구 통신 표준이다. 7/28부터 stateless 방식으로 바뀐다

MCP의 본질

headless 시대의 도구 통신 규약

모델이 외부 도구를 호출하는 표준. "어떤 모델"이 아니라 "어떤 도구를 어떻게 부르나"의 규약이다.

7/28의 본질

stateful → stateless 전환

sticky session + store + LB로 운영하던 구조가 사라지고 요청마다 완결된다. 일반 HTTP 인프라 위에서 돈다. 최종 2026-07-28.

5-2. Capability Graph와 MCP 아키텍처16 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2026-07-28 · CORE 3

stateless 전환의 핵심 3가지

initialize / initialized handshake 삭제

두 단계 핸드셰이크가 사라지고 프로토콜 버전·client info는 매 요청 _meta에 함께 보낸다. "쓸 때마다 capability를 묻는다"가 기본.

Mcp-Session-Id 삭제

세션 ID가 없어 요청이 어느 인스턴스에 떨어져도 처리된다. sticky session 없이 round-robin LB 하나면 충분.

explicit handle 패턴

stateful 흐름은 서버가 basket_id 같은 handle을 발급하고 모델이 다음 호출 인자로 넘긴다. 상태가 payload 인자로 나와 capability가 분명해진다.

5-2. Capability Graph와 MCP 아키텍처17 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2026-07-28 · OPS REF

MCP를 사용하면서 알아야 할 것들

번호	변화	의미
④	`Mcp-Method` / `Mcp-Name` 필수 헤더 + `ttlMs` / `cacheScope`	LB / gateway가 body 안 열고 라우팅. `tools/list` 캐싱 가능.
⑤	Extensions 독립 프레임워크 (MCP Apps + Tasks)	extension마다 독립 ID·버저닝. Tasks lifecycle 재설계 → 마이그레이션 필요.
⑥	Roots / Sampling / Logging deprecated	Roots→param/URI, Sampling→provider API, Logging→stderr/OTel. 12개월 유예.
⑦	OAuth/OIDC 강화	`iss` 검증 필수. CLI가 web으로 분류돼 localhost redirect 거부되던 문제 해결.
⑧	일정 + 에러 코드 변경	RC 2026-05-21 · 최종 07-28. 에러 `-32002` → `-32602`.

5-2. Capability Graph와 MCP 아키텍처18 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · INSIGHT

5-2의 한 줄

stateless가 강제하는 건 결국 "이 도구가 무엇을 할 수 있나"를 매번 분명히 알리는 일이다.

WHY 세션 없음→ 매 호출 독립→ capability가 호출 단위→ 도구 카탈로그가 자산

5-2. Capability Graph와 MCP 아키텍처19 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · RUNTIMES

런타임은 이미 6개 + 추가 adapter다. 하나에 종속되면 안 된다

Claude Code

Claude(Anthropic) · Max Plan · 기본 파일·Bash 도구

Codex CLI

GPT-5.4+ · OpenAI API key · per-token

OpenCode

provider 의존 · 기본 파일·Bash 도구

Hermes

NousResearch·로컬 · MCP 기반 custom skills

Kiro CLI

Claude(AWS) · Kiro AWS sign-in

Copilot CLI

live-discovered(Claude·GPT-5) · Copilot 구독

추가 adapter

providers/의 Gemini · Goose · LiteLLM · Anthropic SDK

∞

커스텀 런타임

AgentRuntime 구현 → runtime_factory.py 등록

5-2. Capability Graph와 MCP 아키텍처20 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · MATRIX

무엇이 같고 무엇이 런타임마다 다른가? 3 레이어로 나눠 본다

5-2. Capability Graph와 MCP 아키텍처21 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · CAPABILITIES

런타임이 선언하는 capability: 누가 무엇을 지원하나

호출하는 쪽은 추측하지 않는다. 런타임이 선언한 capability에 맞춰 호출 방식을 정한다.

5-2. Capability Graph와 MCP 아키텍처22 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · ADAPTER

Adapter 패턴: 런타임을 갈아끼우는 한 층

5-2. Capability Graph와 MCP 아키텍처23 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · SKILL

SKILL.md 한 장, 호출만 런타임마다 다르다

5-2. Capability Graph와 MCP 아키텍처24 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · CONNECT

4장 하네스 v1이 5장 Capability Graph가 된다

5-2. Capability Graph와 MCP 아키텍처25 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · OUROBOROS

Capability Graph: 스킬·도구·런타임이 한 구조로

5-2. Capability Graph와 MCP 아키텍처26 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · APPLY

본인 업무에 적용: 두 가지 질문

본인 업무는 지금 어느 런타임에서 도는가

다른 런타임으로 바꾸면 어디가 깨지는가? 모델·도구·인증·세션 중에서. 한 런타임에 묶여 있으면 정책 변화 한 번에 무너진다.

무엇은 같고 무엇은 다른가

같아야 할 것(workflow)과 달라도 될 것(runtime)을 나눈다. 같은 건 capability node로, 다른 건 adapter로.

도메인별 적용 예시

도메인	Workflow · 고정	Runtime · 교체	Integration
백엔드 운영	검증·롤백 규칙	Claude vs Codex	ooo skill vs subprocess
PM·기획	PRD 양식·검수 기준	ChatGPT·Notion AI	복붙 vs API
데이터 분석	쿼리·검수·알림 양식	BigQuery vs Snowflake	Jupyter vs dbt vs Slack
개인 사이드	요약·퀴즈 기준	Claude	ooo skill vs vscode

5-2. Capability Graph와 MCP 아키텍처27 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-2-3

[실습] 런타임 독립 하네스 그래프 설계하기

핵심

4-4 분업형 하네스 → 런타임 독립 그래프

기존 안/밖·단계·상태·재시도에 capability matrix(3 레이어)와 skill bundle을 더해 런타임 독립으로 올린다.

산출물

Runtime-independent Harness Graph

Candidate Workflow
Outside
Inside
State
Retry
Output Contract
Capability Matrix
Skill Bundle

시간

35분

1~6은 기존 흐름 25분, 7~8은 신규 10분. 5-1의 MCP Candidate Flow를 입력으로 가져온다.

준비물

입력: 5-1에서 MCP형 후보로 고른 업무 1개와 후보 flow 결과
도구: Markdown 편집기 (워크스페이스 폴더 안에 2005-2-3-mcp-design-draft.md로 저장)
참고: ouroboros docs/runtime-capability-matrix.md (세 레이어 구분 방식)
주의: 모든 판단을 자동화하지 않는다. 사람이 책임질 영역은 §2 Outside에 남긴다.

5-2. Capability Graph와 MCP 아키텍처28 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-2-3 · TEMPLATE

실습 산출물: 8 섹션 한눈에

§	섹션	핵심 질문
1	Candidate Workflow	업무 · 입력 · 산출물 · 사람 판단
2	Outside	사람이 책임질 것
3	Inside	입력 정리 → 명세 → 실행 → 검수
4	State & Checkpoints	단계 · 결정 · 실패 · 검수 기록

§	섹션	핵심 질문
5	Retry & Re-question	재시도 vs 재질문 · 복귀 지점
6	Output Contract	산출물 · 근거 · 남은 질문 · 요약
7	Capability Matrix NEW	Workflow / Runtime / Integration
8	Skill Bundle NEW	SKILL.md 묶음 · capability 선언

5-2. Capability Graph와 MCP 아키텍처29 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-2 · RECAP

5-2 회고

capability matrix + skill bundle로 런타임을 갈아끼울 수 있게 만든다

5-2. Capability Graph와 MCP 아키텍처30 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE PART 5-3

MODULE · 5-3

5-3. Satisfice 멈춤 기준

계속 좋아질 수 있다는 이유만으로 계속 돌리지 않게 만듭니다.
충분하면 exit, 부족하면 retry, 입력이 모호하면 ask-back으로 나눕니다.

SECTION BREAK31 / 60

● SPEAKER NOTESSLIDE 31 / 60

섹션 전환

15~20분 슬라이드별 진행 계획

0:00-1:30 · 슬라이드 22 목표: MCP형 하네스에서 반복보다 route가 먼저 필요하다는 점을 잡고, 5-2 Harness Graph 위에 exit·retry·ask-back loop를 붙인다고 안내한다.
1:30-3:30 · 슬라이드 23 문제상황: 계속 좋아질 수 있다는 이유로 루프가 끝나지 않고 검수 비용이 커지는 흐름을 설명한다.
3:30-5:30 · 슬라이드 24 핵심개념: 완벽보다 목적에 충분한 결과와 남은 불확실성 기록이 중요하다고 정리한다.
5:30-7:30 · 슬라이드 25 구조: exit, retry, ask-back을 condition과 next action으로 나눠 읽는다.
7:30-9:15 · 슬라이드 26 프레임워크: stop rule을 완료 신호, 실패 유형, 다음 행동, 운영 기록으로 이루어진 네 칸 계약으로 설명한다.
9:15-11:15 · 슬라이드 27 Ouroboros 앵커: evaluate, event store, rewind를 exit·retry·ask-back route 언어로만 읽고, 설치·실행·성능 보장은 말하지 않는다.
11:15-13:15 · 슬라이드 28 예시: 출력은 나왔지만 조건이 비어 있는 경우를 exit, retry, ask-back으로 가른다.
13:15-15:30 · 슬라이드 29 적용 질문: 각 단계의 exit condition, checkpoint, ask-back question을 표시한다.
15:30-18:30 · 슬라이드 30 실습 안내: exit·retry·ask-back loop를 완성한다.
18:30-19:30 · 슬라이드 31 요약/전환: 멈춤 기준이 최종 프로젝트의 운영 가이드로 이어진다고 정리한다.

5-3은 루프를 만드는 것보다 더 중요한, 루프를 언제 멈출지 정하는 모듈이다. 코드형 하네스는 반복을 가능하게 하지만, 멈춤 기준이 없으면 소모전이 된다.

Ouroboros grounding은 5-4 case study를 앞당겨 복제하는 용도가 아니라, 평가 이후의 상태 기록과 복귀 지점을 loop route 언어로 번역하는 용도다. 이 모듈에서는 repo 실행이나 성능을 주장하지 않고, interview.md의 Seed, AC Tree, event store, rewind 설명을 curriculum.md rows 56-58의 exit·retry·ask-back 흐름에 맞춰 낮춰 사용한다.

2005-3-1 · 완벽보다 중요한 멈출 기준
2005-3-2 · 충분히 괜찮으면 끝내는 stop rule
2005-3-3 · [실습] 내 하네스의 exit·retry·ask-back loop 만들기

Primary source: curriculum.md rows 56-58.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-3 · PROBLEM

문제상황: 루프가 계속 돌기만 할 때

끝없는 개선

더 나은 수정안이 가능하다는 이유로 완료가 미뤄진다.

검수 피로

매번 사람이 다시 보고 판단해야 해 하네스 운영 비용이 커진다.

실패 반복

입력이 부족한데도 같은 재시도를 반복해 수렴하지 않는다.

필요한 기준

종료, 재시도, 재질문을 먼저 정의해야 반복이 통제된다.

5-3. Satisfice 멈춤 기준32 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-3-1

핵심개념: 완벽보다 중요한 멈출 기준

5-3. Satisfice 멈춤 기준33 / 60

● SPEAKER NOTESSLIDE 33 / 60

2005-3-1 20분 확장 운영 · 00:00-20:00

5-3. Satisfice 멈춤 기준의 이 클립은 20분 단독 진행을 기준으로 한다. 클립 제목은 완벽보다 중요한 멈출 기준이고, 핵심 내용은 끝이 없으면 하네스가 아니라 소모전이다이다. 산출물 기준은 강의 중 적용 질문 또는 다음 클립 입력로 둔다.

00:00-02:00 · 문제 연결: 완벽보다 중요한 멈출 기준의 문제 상황을 열고 핵심 문장 '끝이 없으면 하네스가 아니라 소모전이다'를 오늘의 route signal으로 둔다.
02:00-05:00 · 업무 신호: 본인이 실제 업무에서 같은 문제가 나타나는 신호를 찾게 한다. 추상 개념보다 최근 실패 흐름을 먼저 묻는다.
05:00-08:00 · 핵심 개념: 프롬프트 문장이 아니라 작업 구조, 경계, 확인 지점을 고정한다는 관점으로 개념을 정의한다.
08:00-11:00 · 구조화: 역할, 입력, 제약, 성공기준, 멈춤 조건 중 이 클립에서 잠가야 할 칸을 나누어 설명한다.
11:00-14:00 · 반례와 한계: 이 클립의 원칙이 적용되지 않는 경우를 짚고, 사람이 판단해야 할 영역을 남긴다.
14:00-17:00 · 적용 질문: 자기 업무 하나를 떠올리게 하고 오늘 배운 기준으로 한 줄 표시를 한다.
17:00-20:00 · 정리 / 전환: 핵심 문장을 다시 읽고 다음 클립에서 이어질 입력 또는 산출물로 연결한다.

20분 본인 운영 포인트

화면의 문장은 짧게 읽고, 실제 분량은 질문, 비교, 자기 업무 적용, 검수 멘트로 채운다.
본인이 적을 값은 한 번에 하나만 제시한다. 여러 칸을 동시에 채우게 하면 실습 시간이 산만해진다.
새 외부 사례나 검증되지 않은 수치 주장은 추가하지 않고 curriculum.md와 interview.md의 하네스 관점 안에서 설명한다.

진행 메모

curriculum.md 핵심 문장: 끝이 없으면 하네스가 아니라 소모전이다.
완벽주의는 하네스에서 특히 위험하다. AI는 계속 수정안을 낼 수 있기 때문에 멈출 기준이 없으면 개선이 아니라 감시 비용이 늘어난다.
interview.md의 "노트북을 닫고 자도 될 정도로 믿을 수 있는가"라는 기준은 보충 맥락이다. curriculum.md의 멈춤 기준은 실패를 알아채고, 어디서 수렴했는지 남길 때 실무 기준이 된다.
다음 클립에서 satisfice를 낮은 품질이 아니라 실무적 종료 조건으로 설명한다.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-3-2

구조: 충분히 괜찮으면 끝내는 stop rule

Rule	끝내는 조건	다음 행동
종료	목표와 성공기준을 만족하고, 남은 개선이 업무 가치에 비해 작다.	결과, 판단 근거, 남은 불확실성을 남긴다.
재시도	형식, 검증, 실행 중 하나가 실패했지만 입력은 충분하다.	체크포인트로 돌아간다.
재질문	요구사항이나 route signal이 비어 있어 반복해도 수렴하지 않는다.	사람에게 묻고 명세를 갱신한다.

5-3. Satisfice 멈춤 기준34 / 60

● SPEAKER NOTESSLIDE 34 / 60

2005-3-2 20분 확장 운영 · 00:00-20:00

5-3. Satisfice 멈춤 기준의 이 클립은 20분 단독 진행을 기준으로 한다. 클립 제목은 충분히 괜찮으면 끝내는 stop rule이고, 핵심 내용은 satisfice가 실무 하네스의 핵심이다이다. 산출물 기준은 강의 중 적용 질문 또는 다음 클립 입력로 둔다.

00:00-02:00 · 문제 연결: 충분히 괜찮으면 끝내는 stop rule의 문제 상황을 열고 핵심 문장 'satisfice가 실무 하네스의 핵심이다'를 오늘의 route signal으로 둔다.
02:00-05:00 · 업무 신호: 본인이 실제 업무에서 같은 문제가 나타나는 신호를 찾게 한다. 추상 개념보다 최근 실패 흐름을 먼저 묻는다.
05:00-08:00 · 핵심 개념: 프롬프트 문장이 아니라 작업 구조, 경계, 확인 지점을 고정한다는 관점으로 개념을 정의한다.
08:00-11:00 · 구조화: 역할, 입력, 제약, 성공기준, 멈춤 조건 중 이 클립에서 잠가야 할 칸을 나누어 설명한다.
11:00-14:00 · 반례와 한계: 이 클립의 원칙이 적용되지 않는 경우를 짚고, 사람이 판단해야 할 영역을 남긴다.
14:00-17:00 · 적용 질문: 자기 업무 하나를 떠올리게 하고 오늘 배운 기준으로 한 줄 표시를 한다.
17:00-20:00 · 정리 / 전환: 핵심 문장을 다시 읽고 다음 클립에서 이어질 입력 또는 산출물로 연결한다.

20분 본인 운영 포인트

화면의 문장은 짧게 읽고, 실제 분량은 질문, 비교, 자기 업무 적용, 검수 멘트로 채운다.
본인이 적을 값은 한 번에 하나만 제시한다. 여러 칸을 동시에 채우게 하면 실습 시간이 산만해진다.
새 외부 사례나 검증되지 않은 수치 주장은 추가하지 않고 curriculum.md와 interview.md의 하네스 관점 안에서 설명한다.

진행 메모

curriculum.md 핵심 문장: satisfice가 실무 하네스의 핵심이다.
satisfice는 대충 끝내자는 말이 아니다. 현재 목적에 충분히 맞는 결과가 나왔을 때 멈추고, 남은 불확실성은 기록하는 기준이다.
재시도와 재질문을 구분한다. 입력이 충분한데 산출물이 실패하면 재시도하고, 입력이나 기준 자체가 비어 있으면 사람에게 다시 물어야 한다.
interview.md의 Ouroboros 설명은 보충 맥락이다. Seed와 평가 기준이 있어야 루프가 추측 대신 수렴하며, 이 표는 그 원리를 업무용 stop rule로 바꾼 것이다.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-3 · DECISION CONTRACT

프레임워크: stop rule은 네 칸 계약이다

완료 신호

어떤 성공기준을 만족하면 충분한가?

실패 유형

형식, 검증, 기준 누락 중 무엇이 실패했는가?

다음 행동

종료, 재시도, 재질문 중 하나로 고른다.

운영 기록

판단 근거와 남은 불확실성을 남긴다.

5-3. Satisfice 멈춤 기준35 / 60

● SPEAKER NOTESSLIDE 35 / 60

stop rule 프레임워크

이 슬라이드는 2005-3-2의 stop rule을 실제 loop protocol로 옮기기 위한 중간 프레임워크다. 본문은 짧지만, 말로는 네 칸을 하나의 계약처럼 설명한다.
완료 신호는 "더 고칠 수 없음"이 아니라 "목표와 성공기준을 만족했고 남은 개선의 업무 가치가 작음"이다. 이 표현을 반복해 satisfice가 낮은 품질의 변명이 아니라는 점을 고정한다.
실패 유형은 형식 실패, 검증 실패, 기준 누락을 분리한다. 형식과 검증 실패는 입력과 기준이 충분할 때 재시도 후보가 되고, 기준 누락은 재질문 후보가 된다.
다음 행동은 반드시 종료, 재시도, 재질문 중 하나여야 한다. "계속 개선"이라는 선택지를 그대로 두면 하네스가 루프만 만들고 운영 판단을 남기지 못한다.
운영 기록은 결과물 자체보다 운영을 가능하게 하는 정보다. 완료한 이유, 실패한 이유, 돌아갈 체크포인트, 사람에게 물을 질문을 남겨야 다음 실행이 같은 판단을 반복하지 않는다.
Ouroboros 관찰 언어로 바꾸면 Seed와 AC Tree는 완료 신호의 기준, evaluate는 실패 유형의 발견, event store는 운영 기록, rewind는 재시도할 체크포인트다. 이 연결은 구조 관찰이지 실행 보장이 아니다.
본인 질문: "본인의 Runtime-independent Harness Graph에서 완료 신호가 가장 모호한 단계는 어디인가요?", "그 모호함은 재시도로 해결되나요, 사람에게 다시 물어야 하나요?"
전환 멘트: 이제 이 네 칸을 Ouroboros의 평가 이후 흐름으로 읽어 본다. 복제하지 않고, 평가 뒤에 어떤 판단이 남아야 하는지만 본다.

Primary source: curriculum.md rows 56-58.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-3 · OUROBOROS ANCHOR

Ouroboros 앵커: 평가 뒤에는 판단이 남아야 한다

관찰 흐름	남겨야 할 것	5-3 번역
Seed · AC Tree	목표, 제약, 성공기준	종료 조건의 근거
Evaluate	어떤 기준을 통과하거나 실패했는지	종료 또는 재시도 판단
Event store	결정, 실패 사유, 남은 질문	운영 기록과 재질문 근거
Rewind	처음이 아닌 가까운 복귀 지점	재시도 체크포인트

5-3. Satisfice 멈춤 기준36 / 60

● SPEAKER NOTESSLIDE 36 / 60

Ouroboros grounding

이 슬라이드는 5-4의 Ouroboros case study를 미리 결론 내리는 시간이 아니다. 5-3의 멈춤 기준을 설명하기 위해 평가 이후에 어떤 정보가 남아야 하는지만 관찰한다.
Seed와 AC Tree는 종료 조건의 근거다. 본인이 "어떤 기준을 만족했기 때문에 충분하다고 말할 수 있는가"를 묻게 한다.
Evaluate는 완료 선언이 아니라 판단 지점이다. 통과하면 종료 근거를 남기고, 실패하면 입력과 기준이 충분한지 확인해 재시도와 재질문을 가른다.
Event store는 결정과 실패 사유를 남기는 관찰 언어다. 여기서 "로그를 많이 남긴다"가 아니라 다음 루프가 같은 판단을 반복하지 않게 필요한 최소 기록을 남긴다고 설명한다.
Rewind는 처음부터 다시 시작하지 않기 위한 복귀 지점이다. retry loop에는 반드시 어디로 돌아갈지가 적혀 있어야 한다.
source-fidelity guardrail: 이 모듈에서는 Ouroboros 설치, 실행, 성능, 생산성, 채택 규모를 주장하지 않는다. interview.md와 approved-source-checklist.md가 허용한 구조 언어만 사용한다.
본인 질문: "본인 업무에서 AC Tree에 해당하는 종료 기준은 무엇인가요?", "실패 이력을 남기지 않아서 같은 재시도를 반복한 적이 있나요?", "되돌아갈 가장 가까운 지점은 어디인가요?"
전환 멘트: 이제 같은 기준을 일반 업무 시나리오에 대입해 종료, 재시도, 재질문을 구분한다.

Primary source: curriculum.md rows 56-58.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-3 · SCENARIO

예시: 1page 초안 하나를 두고 끝낼지·다시 돌릴지·물어볼지 정한다

종료 · exit

결정권자가 바로 쓴다

1page가 결정·배경·성공기준을 담아 다음 결정으로 넘어간다. 더 다듬을 여지는 남은 불확실성으로만 적는다.

재시도 · retry

형식이 틀어졌다

제목 누락·표 깨짐처럼 형식이 실패했다. 회의록 입력은 충분하니 작업 체크포인트로 돌아간다.

재질문 · ask-back

기준이 비어 있다

회의록에 성공 기준도, 누가 읽을지도 없다. 몇 번을 돌려도 톤이 안 정해지면 사람에게 묻는다.

기록 · operate

판단을 남긴다

어떤 판단으로 끝냈는지, 복귀 지점, 남은 질문을 운영 기록에 남긴다.

5-3. Satisfice 멈춤 기준37 / 60

● SPEAKER NOTESSLIDE 37 / 60

예시 해설

회의록 → 1page 초안 하나를 놓고도 종료·재시도·재질문이 달라질 수 있다. 출력이 나왔다고 끝이 아니라는 게 satisfice의 핵심이다.
종료(exit): 1page가 결정·배경·성공기준을 담아 결정권자가 바로 다음 결정으로 간다면 끝낸다. 더 다듬을 여지는 남은 불확실성으로만 기록하고 다음 루프를 자동으로 열지 않는다.
재시도(retry): 제목 누락이나 표 깨짐처럼 형식이 틀어진 실패는 회의록 입력이 충분하니 작업 체크포인트로 돌아간다.
재질문(ask-back): 회의록에 성공 기준이나 "누가 읽을지"가 비어 몇 번을 돌려도 톤이 안 정해지면, 사람에게 묻거나 2장 인터뷰 하네스로 돌아간다.
전환 멘트: 이제 각자 Harness Graph의 단계마다 이 세 기준을 붙인다.

Primary source: curriculum.md rows 56-58.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-3 · APPLICATION QUESTION

적용 질문: 무엇을 보면 멈출 수 있나

exit condition

마무리해도 되는 output 신호. 목표·성공 신호에 연결한다

retry route

어떤 실패는 같은 입력으로 checkpoint에서 다시 실행해도 되는가?

ask-back route

어떤 불확실성은 사람이 답하기 전까지 진행하면 안 되는가?

checkpoint

retry가 돌아갈 node. 처음이 아니라 가까운 지점

5-3. Satisfice 멈춤 기준38 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-3-3

[실습] 내 하네스의 exit·retry·ask-back loop 만들기

실습 목표

언제 끝내고 언제 다시 돌릴지 정한다.

수행 과제

exit·retry·ask-back route를 업무 graph에 붙인다.

산출물

Loop Protocol · ask-back route 포함

완료 신호

하네스가 계속 돌지 않고 다음 action을 선택할 수 있다.

5-3. Satisfice 멈춤 기준39 / 60

● SPEAKER NOTESSLIDE 39 / 60

2005-3-3 20분 확장 운영 · 00:00-20:00

5-3. Satisfice 멈춤 기준의 이 클립은 20분 단독 진행을 기준으로 한다. 클립 제목은 [실습] 내 하네스의 exit·retry·ask-back loop 만들기이고, 핵심 내용은 언제 끝내고 언제 다시 돌릴지 정한다이다. 산출물 기준은 Loop Protocol로 둔다.

00:00-02:00 · 산출물 확인: 이 클립은 실습이 반드시 필요하다. Loop Protocol을 오늘의 제출 단위로 확인하고 핵심 문장 '언제 끝내고 언제 다시 돌릴지 정한다'를 완료 기준으로 둔다.
02:00-04:00 · 입력 정리: 앞 클립에서 만든 질문, 표, 초안, route signal 중 이번 산출물에 넣을 입력만 고른다.
04:00-08:00 · 첫 작성: 빈칸을 완벽히 채우려 하지 말고 제목, 목적, 입력, 제약, 완료 기준부터 빠르게 적는다.
08:00-12:00 · 핵심 작성: 산출물의 중심 칸을 채운다. 모르는 값은 추측하지 않고 질문 또는 확인 필요로 남긴다.
12:00-15:00 · 자기 검수: 형식이 맞는지, 핵심 문장이 드러나는지, 사람 판단 영역이 남아 있는지 확인한다.
15:00-18:00 · 수정: 가장 모호한 문장 하나와 가장 위험한 빈칸 하나를 골라 좁힌다.
18:00-20:00 · 제출 / 전환: Loop Protocol의 완료 기준을 확인하고 다음 클립에서 재사용할 값과 버릴 값을 나눈다.

20분 본인 운영 포인트

화면의 문장은 짧게 읽고, 실제 분량은 질문, 비교, 자기 업무 적용, 검수 멘트로 채운다.
본인이 적을 값은 한 번에 하나만 제시한다. 여러 칸을 동시에 채우게 하면 실습 시간이 산만해진다.
새 외부 사례나 검증되지 않은 수치 주장은 추가하지 않고 curriculum.md와 interview.md의 하네스 관점 안에서 설명한다.

실습 절차 / 체크포인트

실습 목표: 언제 끝내고 언제 다시 돌릴지 정한다.
수행 과제: Runtime-independent Harness Graph의 각 node에 exit condition, retry route, ask-back route를 붙인다.
수행 절차 1: Runtime-independent Harness Graph의 node별 output과 success signal을 protocol row로 옮긴다.
수행 절차 2: 각 row마다 충분하면 exit, 검증 실패면 retry할 route를 나눠 적는다.
수행 절차 3: 입력이나 판단 신호가 비어 있어 사람이 답해야 하는 경우를 ask-back route로 따로 표시한다.
산출물 이름: Loop Protocol. 각 row에는 exit condition, retry route, ask-back route를 모두 포함한다.
체크포인트: exit condition은 산출물의 목적과 success signal에 연결되어야 한다. "더 좋아질 수 있음"은 자동 retry 사유가 아니다.
체크포인트: retry route에는 되돌아갈 checkpoint가 있어야 하고, ask-back route에는 사람이 답해야 할 질문이 있어야 한다.
완료 확인 체크포인트: Loop Protocol의 각 row에 exit condition, retry route, ask-back route, checkpoint가 채워져 있으면 실습 완료로 본다.

Primary source: curriculum.md rows 56-58.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-3 · SUMMARY

5-3 정리: 반복보다 멈춤 기준을 먼저 둔다

5-3. Satisfice 멈춤 기준40 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE CHAPTER 05

CHAPTER 05 · SYNTHESIS

5장 통합. MCP형 하네스 만들기

5-1 필요성 판단 → 5-2 안/밖 경계 설계 → 5-3 종료·재시도 기준으로
코드형 통제 흐름을 완성합니다.

5-1 → 5-2 → 5-3 → PROJECT

CHAPTER 05 BREAK41 / 60

● SPEAKER NOTESSLIDE 41 / 60

5장 통합 전용 섹션 전환

이 섹션은 앞의 5-1부터 5-3까지의 curriculum.md 클립을 대체하지 않는다. 각 모듈에서 만든 MCP Candidate Flow, Runtime-independent Harness Graph, Loop Protocol를 5장 통합 MCP형 하네스 만들기의 5-1~5-3 흐름으로 다시 묶는다.

interview.md의 하네스 철학은 보충 맥락이다. 사람의 암묵지를 먼저 뽑고, 비결정적인 모델을 결정론적 실행으로 묶고, 상태와 실패 이력을 남겨 믿을 수 있는 워크플로우를 만든다는 관점만 가져온다.

5-1: 순서, 상태, 재시도, 오케스트레이션 신호를 보고 MCP까지 필요한 업무인지 판단한다.
5-2: MCP 안쪽에는 순서, 상태, 재시도, 체크포인트를 넣고 바깥에는 판단, 입력, 결과 공유를 남긴다.
5-3: 종료, 재시도, 재질문 기준을 정해 루프가 소모전으로 변하지 않게 만든다.
PROJECT: 세 산출물을 Final Harness Graph와 런타임 독립 하네스 실행 데모로 연결한다.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE CHAPTER 05 FLOW

5장 통합 흐름: 판단하고, 경계를 긋고, 멈춤을 정한다

5-1

MCP Candidate Flow

순서 강제, 상태 관리, 재시도 신호가 있는 업무만 코드형 후보로 올린다.

5-2

Runtime-independent Harness Graph

안쪽 책임과 바깥 책임을 나누고 저장할 상태와 복귀 지점을 정한다.

5-3

Loop Protocol

충분하면 끝내고, 실패 유형에 따라 재시도와 재질문을 분리한다.

OUTPUT

최종 산출물

Final Harness Graph
런타임 독립 하네스 실행 데모

CHAPTER 05 FLOW42 / 60

● SPEAKER NOTESSLIDE 42 / 60

5-1~5-3 흐름 해설

이 흐름은 curriculum.md 5장의 클립 목적을 하나의 제작 순서로 정리한 것이다. 새로운 외부 사례나 검증되지 않은 수치를 넣지 않는다.
5-1은 MCP Candidate Flow다. 문서와 분업만으로 부족한지 확인하고, 상태 관리와 재시도까지 필요한 업무만 MCP형 후보로 남긴다.
5-2는 Runtime-independent Harness Graph이다. 순서, 상태, 재시도, 체크포인트는 코드형 통제 안쪽에 두고, 문제 정의와 최종 판단은 사람의 책임으로 남긴다.
5-3은 Loop Protocol다. satisfice를 낮은 품질의 변명이 아니라 실무적 stop rule로 사용하고, 재시도와 재질문을 구분한다.
OUTPUT은 5-4의 최종 산출물이다. 2005-4-2에서 Final Harness Graph를 만들고, 2005-4-3에서 런타임 독립 하네스 실행 데모로 마무리한다. interview.md의 표현처럼 AI가 추측할 필요가 없는 궤도를 만들되, 각자 도메인에 맞게 계속 진화시킬 수 있는 판단 구조를 남긴다.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE PART 5-4 · PROJECT

MODULE · 5-4

5-4. 최종 프로젝트 및 케이스 스터디

PROJECT · Ouroboros를 관찰하고,
4C → Capability Graph → MCP 하네스로 연결해
내 업무용 런타임 독립 하네스 실행 데모까지 완성합니다.

SECTION BREAK43 / 60

● SPEAKER NOTESSLIDE 43 / 60

섹션 전환

15~20분 슬라이드별 진행 계획

아래 시간표는 총 19분 30초 기준이다. 각 후속 노트에는 같은 시간 구간을 다시 적어 슬라이드별 페이스와 소스 경계를 확인할 수 있게 한다.

0:00-1:30 · 슬라이드 34 목표: 5-1, 5-2, 5-3 산출물을 최종 하네스 프로젝트로 묶는다고 안내한다.
1:30-3:15 · 슬라이드 35 문제상황: 최종 프로젝트가 좋은 프롬프트 모음으로 흩어지는 위험을 짚는다.
3:15-5:45 · 슬라이드 36 예시/케이스: Ouroboros를 순서, 상태, 재시도, 평가 흐름을 관찰하는 사례로 읽는다.
5:45-8:45 · 슬라이드 37 적용 워크스루: Ouroboros의 질문, Seed, 평가, 기록 흐름을 내 하네스의 gate, input, review, record로 번역한다.
8:45-11:30 · 슬라이드 38 라이브 예시: 새 요청이 발산하는 장면을 Seed, AC Tree, event store, rewind 관점으로 해설한다.
11:30-13:15 · 슬라이드 39 핵심개념: 전체 연결 파이프라인이 단계별 입력, 산출물, 통과 조건을 연결한다고 설명한다.
13:15-15:15 · 슬라이드 40 구조: Final Harness Graph에서 인터뷰, 명세, 작업, 검수의 경계를 확인한다.
15:15-16:45 · 슬라이드 41 적용 질문: 내 도메인에서 안쪽 책임, 바깥 판단, 저장 상태, 멈춤 기준을 결정한다.
16:45-18:30 · 슬라이드 42 실습 안내: 최종 하네스와 운영 가이드를 데모 가능한 형태로 정리한다.
18:30-19:30 · 슬라이드 43 요약/전환: Ouroboros 복제가 아니라 자기 도메인용 운영 구조를 남기는 것이 목표라고 말하고 마무리한다.

15분 / 20분 운영 큐

15분으로 압축할 때는 슬라이드 36의 repo path 설명을 핵심 4경로(bigbang, execution/evaluation, persistence, mcp/orchestrator)로 줄이고, 슬라이드 41의 질문은 한 명에게만 짧게 받는다.
20분까지 확장할 때는 슬라이드 37에서 각 행마다 본인 업무 번역 문장을 하나씩 더 말하게 하고, 슬라이드 42에서 운영 기록 예시를 한 번 더 점검한다.
시간을 줄이거나 늘려도 유지할 필수 흐름은 목표 → 문제상황 → Ouroboros 관찰 → 내 하네스 번역 → 최종 산출물 안내 → 요약이다.

5-4는 5장 통합 MCP형 하네스 만들기의 5-1~5-3 산출물을 최종 프로젝트로 묶는 구획이다. curriculum.md의 실습 및 산출물 값이 있으므로 세 클립 모두 실습/프로젝트 성격으로 다룬다.

PROJECT 1 · 2005-4-1 · [Case Study] Ouroboros: 끝없는 루프를 통제하는 프레임워크를 보고 순서, 상태, 재시도 강제 구조를 분석한다.
PROJECT 2 · 2005-4-2 · 4C → Capability Graph → MCP 하네스로 연결하기에서 Final Harness Graph를 만든다.
PROJECT 3 · 2005-4-3 · [최종 프로젝트] 내 업무용 런타임 독립 하네스 실행 데모에서 최종 하네스와 운영 가이드로 마무리한다.

오프닝에서 고정할 기준

이 모듈의 출발점은 새 도구 소개가 아니라 5-1, 5-2, 5-3에서 만든 산출물의 연결이다. MCP Candidate Flow, Runtime-independent Harness Graph, Loop Protocol가 서로 따로 있으면 최종 프로젝트는 여전히 문서 모음에 머문다.
본인이 먼저 확인시킬 질문은 "내 업무는 어떤 입력을 받고, 어떤 단계로 처리되고, 어떤 기준으로 완료되는가"이다. 이 질문에 답하지 못하면 뒤의 Ouroboros 관찰도 사례 감상으로 끝난다.
Ouroboros는 5-4의 reference anchor다. Seed, AC Tree, event store, rewind, evaluate, evolve 같은 이름을 제품 기능 소개로 외우게 하지 않고, 순서 강제, 상태 기록, 재시도/복귀, 종료 판단이 어디에 놓이는지 보는 관찰 언어로 사용한다.
강의 톤은 "Ouroboros처럼 만들자"가 아니라 "Ouroboros를 읽고 내 업무에서 코드형 통제가 필요한 지점을 찾자"로 유지한다. interview.md도 본인 결과물이 복사본이 아니라 자기 도메인용 하네스 사고방식이어야 한다고 설명한다.

2분 오프닝 말할 포인트

첫 30초는 5장의 누적 흐름을 되짚는다. 5-1은 왜 코드형 통제가 필요한지 판단했고, 5-2는 무엇을 안쪽과 바깥에 둘지 나눴고, 5-3은 언제 멈추거나 다시 물을지 정했다.
다음 45초는 최종 프로젝트의 산출물 기준을 밝힌다. 오늘 끝에 남아야 하는 것은 멋진 프롬프트가 아니라, 인터뷰 입력부터 검수와 운영 기록까지 이어지는 최종 하네스와 운영 가이드다.
그 다음 30초는 case study의 사용법을 제한한다. 공개 repo를 설치하거나 성능을 주장하지 않고, curriculum.md가 요구한 순서, 상태, 재시도 강제 구조만 관찰한다.
마지막 15초는 본인의 관찰 렌즈를 준다. "내 업무에서 Seed는 무엇이고, AC Tree는 무엇이고, event store와 rewind에 해당하는 운영 기록은 무엇인가"라는 질문으로 다음 슬라이드에 들어간다.

Primary source: curriculum.md rows 59-61.

Repo reference: lecture-decks.seed.yaml reference repo https://github.com/Q00/ouroboros, observation only.

Supporting reference: interview.md lines 39-48 for Ouroboros drift, non-cloning, and domain-specific harness framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · PROBLEM

문제상황: 최종 프로젝트가 프롬프트 모음으로 끝날 때

흐름 단절

인터뷰, 명세, 작업, 검수가 서로의 입력이 되지 않는다.

상태 부재

결정, 실패 사유, 복귀 지점이 운영 가이드에 남지 않는다.

검수 약화

완료 기준이 결과물 옆에 붙지 않아 데모가 설명으로만 끝난다.

프로젝트 목표

각 산출물을 하나의 실행 가능한 하네스와 운영 가이드로 연결한다.

5-4. 최종 프로젝트 및 케이스 스터디44 / 60

● SPEAKER NOTESSLIDE 44 / 60

문제상황

시간 큐 / 레퍼런스 주석

진행 시간: 1:30-3:15. 첫 30초는 프롬프트 모음으로 끝나는 위험을 말하고, 다음 60초는 흐름 단절·상태 부재·검수 약화를 하나씩 풀고, 마지막 15초는 Ouroboros 관찰로 넘어간다.
근거: curriculum.md rows 59-61의 최종 프로젝트 산출물 흐름과 interview.md lines 39-42의 "이론과 실제 운영은 다르다"는 경험담을 문제상황으로 낮춰 사용한다.

5-4의 위험은 최종 프로젝트가 좋은 프롬프트와 체크리스트를 모아둔 문서로 끝나는 것이다.
최종 하네스는 각 단계가 다음 단계의 입력이 되어야 한다. 인터뷰가 명세를 만들고, 명세가 작업 기준을 고정하고, 작업 결과가 검수와 종료 판단으로 이어져야 한다.
상태와 실패 대응이 운영 가이드에 남지 않으면 다음 실행에서 같은 판단을 다시 해야 한다.
전환 멘트: 먼저 Ouroboros를 완성품으로 베끼는 것이 아니라, 순서와 상태가 어떻게 남는지 관찰하는 사례로 본다.

문제상황 해설 확장

흐름 단절은 가장 흔한 실패다. 인터뷰에서 나온 결정이 명세에 반영되지 않고, 명세의 성공 기준이 작업 지시로 내려가지 않고, 작업 결과가 검수 기준과 연결되지 않으면 사람은 매 단계마다 다시 설명해야 한다.
상태 부재는 반복 실행에서 드러난다. 왜 이 결정을 했는지, 어느 실패에서 되돌아왔는지, 다음 실행에서 무엇을 재사용해야 하는지가 남지 않으면 하네스는 자동화가 아니라 기억력 테스트가 된다.
검수 약화는 데모 단계에서 드러난다. 결과물이 있어도 완료 기준이 붙어 있지 않으면 "좋아 보인다"와 "쓸 수 있다"를 구분할 수 없고, 5-3에서 만든 stop rule도 적용할 위치를 잃는다.
그래서 이 슬라이드의 핵심은 프롬프트 품질 비판이 아니다. 좋은 프롬프트라도 다음 단계의 입력, 상태 기록, 검수 기준, 복귀 지점으로 연결되지 않으면 최종 하네스가 되지 않는다는 점을 설명한다.

Ouroboros로 넘어가는 연결 멘트

Ouroboros를 보는 이유는 레퍼런스 자체를 소개하기 위해서가 아니다. interview → Seed → execute → evaluate → evolve가 하나의 관측 가능한 흐름으로 이어질 때, 방금 본 네 가지 문제가 어떻게 줄어드는지 확인하기 위해서다.
Seed와 AC Tree는 흐름 단절을 줄이는 관찰 지점이다. event store와 checkpoints, rewind는 상태 부재를 줄이는 관찰 지점이다. evaluate와 evolve는 검수 약화와 무한 반복을 분리해서 보는 관찰 지점이다.
이 연결은 source-fidelity guardrail 안에서만 말한다. 설치, 실행 성공, 성능, 채택 규모, 별점 같은 주장은 하지 않고, curriculum.md rows 59-61과 interview.md가 허용한 구조 언어에 머문다.

Primary source: curriculum.md rows 59-61.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-4-1

[Case Study] Ouroboros: 끝없는 루프를 통제하는 프레임워크

레퍼런스 역할

인터뷰, Seed, 실행, 평가, 진화를 하나의 관측 가능한 루프로 묶는 사례

핵심 메시지

순서, 상태, 재시도를 코드로 강제해 폭주를 막는 구현 사례

실습 목표

Ouroboros 구조를 MCP형 하네스 설계 기준으로 읽는다.

수행 과제

인터뷰, Seed, 실행, 평가, 진화에서 순서, 상태, 재시도 지점을 표시한다.

산출물

Ouroboros 핵심 로직 분석

순서interview → seed → execute → evaluate → evolve 순서가 어디서 강제되는지 표시
상태event store, checkpoints, rewind가 상태와 복귀 지점을 어떻게 남기는지 표시
검수검수 단계별 평가가 종료·재시도 판단을 어떻게 가르는지 표시
경계MCP와 orchestrator가 도구 호출과 런타임 차이를 어디서 제한하는지 표시

5-4. 최종 프로젝트 및 케이스 스터디45 / 60

● SPEAKER NOTESSLIDE 45 / 60

2005-4-1 20분 확장 운영 · 00:00-20:00

5-4. 최종 프로젝트 및 케이스 스터디의 이 클립은 20분 단독 진행을 기준으로 한다. 클립 제목은 [Case Study] Ouroboros: 끝없는 루프를 통제하는 프레임워크이고, 핵심 내용은 순서, 상태, 재시도를 코드로 강제해 폭주를 막는 구현 사례이다. 산출물 기준은 Ouroboros 핵심 로직 분석로 둔다.

00:00-02:00 · 사례 목표: [Case Study] Ouroboros: 끝없는 루프를 통제하는 프레임워크를 기능 소개가 아니라 하네스 구조 관찰 대상으로 둔다. 핵심 문장 '순서, 상태, 재시도를 코드로 강제해 폭주를 막는 구현 사례'를 먼저 읽는다.
02:00-05:00 · 관찰 범위: repo 또는 문서에서 관찰 가능한 파일, 역할, 제약, 흐름만 본다. 실행 결과나 외부 평판은 주장하지 않는다.
05:00-08:00 · 하네스 번역: 사례에서 보이는 구조를 역할, 입력, 제약, 출력, 검수 기준 언어로 번역한다.
08:00-11:00 · 강점: 이 구조가 어떤 종류의 반복 업무, 맥락 보호, 순서 강제, 팀 공유를 돕는지 설명한다.
11:00-14:00 · 한계: 문서만으로 안 되는 일, 분업이 필요한 일, MCP가 필요한 일을 과장 없이 구분한다.
14:00-17:00 · 적용 질문: 본인의 업무에서 사례의 구조를 그대로 복사할 것과 버릴 것을 나누게 한다.
17:00-20:00 · 정리 / 전환: 관찰값을 다음 실습 또는 프로젝트 산출물의 입력으로 넘긴다.

20분 본인 운영 포인트

화면의 문장은 짧게 읽고, 실제 분량은 질문, 비교, 자기 업무 적용, 검수 멘트로 채운다.
본인이 적을 값은 한 번에 하나만 제시한다. 여러 칸을 동시에 채우게 하면 실습 시간이 산만해진다.
Ouroboros는 승인된 5장 MCP형 하네스 레퍼런스로만 다루고, 순서·상태·재시도 통제 관찰에 집중한다.

Case Study 역할

시간 큐 / 레퍼런스 주석

진행 시간: 3:15-5:45. 30초는 case study 역할, 75초는 순서·상태·재시도 관찰 축, 45초는 검증된 경로 목록, 30초는 실습 산출물 기준에 배분한다.
근거: curriculum.md row 59의 Ouroboros case study와 lecture-decks.seed.yaml의 Q00/ouroboros reference mapping만 사용한다. repo 설치, 실행 성공, 성능, 채택 규모는 말하지 않는다.

Ouroboros는 MCP형 하네스의 레퍼런스다. 이 case study의 연결점은 curriculum.md의 핵심 문장인 "순서, 상태, 재시도를 코드로 강제해 폭주를 막는 구현 사례"다.

interview.md의 Socratic Interview, Seed, AC Tree, Ralph 루프, event store, rewind 설명은 보충 관점으로만 사용한다. 학습자는 Ouroboros를 복제하려는 것이 아니라, 자신의 업무 하네스에서 어떤 흐름을 코드형 통제로 옮길지 판단하기 위해 repo 구조를 읽는다.

레퍼런스 repo: https://github.com/Q00/ouroboros. 설치나 실행 검증은 하지 않고 구조 관찰만 한다.

MCP형 하네스 사례 프레임

Ouroboros는 제품 소개가 아니라 MCP형 하네스 사례로 다룬다. 핵심은 LLM 호출 자체가 아니라 인터뷰 → Seed → 실행 → 평가 → 진화 흐름을 순서와 상태가 있는 실행 경계로 묶는 방식이다.
발표자는 interview.md의 표현처럼 "비결정적인 모델을 결정적인 실행으로 묶어내는 장치"라는 관점에서 설명하되, curriculum.md의 목적에 맞춰 순서 강제, 상태 저장, 재시도, 종료 판단을 중심으로 해설한다.
MCP형 하네스의 관찰 질문은 단순하다. 어떤 도구를 호출하는가보다 호출 전 조건, 실패 시 복귀 지점, 다음 단계로 넘기는 검수 조건이 repo 어디에 남아 있는지를 본다.

실습 절차 / 체크포인트

실습 목표: Ouroboros 구조를 MCP형 하네스 설계 기준으로 읽는다.
수행 과제: repo를 설치하거나 실행하지 않고, 공개 repo의 구조와 README를 보며 순서 강제, 상태 저장, 평가, 진화가 어디에 놓이는지 정리한다.
수행 절차 1: README와 디렉터리 이름만 기준으로 인터뷰, Seed, 실행, 평가, 진화 흐름을 표시한다.
수행 절차 2: 순서 강제, 상태 저장, 재시도, 종료 판단이 어느 경로와 파일명에 드러나는지 연결한다.
수행 절차 3: 설치나 실행 검증 없이 구조 관찰 결과를 Ouroboros 핵심 로직 분석에 요약한다.
산출물 이름: Ouroboros 핵심 로직 분석.
분석 섹션 작성 항목: 전체 연결 파이프라인, 상태/복귀 지점, 검수 기준, MCP/orchestrator 경계 네 축을 반드시 채운다.
체크포인트: curriculum.md 핵심 문장인 "순서, 상태, 재시도를 코드로 강제해 폭주를 막는 구현 사례"가 분석 결과에 드러나야 한다.
완료 확인 체크포인트: Ouroboros 핵심 로직 분석에 인터뷰, Seed, 실행, 평가, 진화와 순서·상태·재시도 위치가 연결되어 있으면 실습 완료로 본다.

검증된 Ouroboros 디렉터리 및 파일 경로

아래 항목은 이 case study에서 사용하는 경로만 모은 목록이다. GitHub Q00/ouroboros repo의 루트 파일과 README의 src/ouroboros/ 내부 구조를 기준으로 확인했으며, 설치나 실행 검증은 포함하지 않는다.

README.md · 학습자는 interview → seed → execute → evaluate → evolve 흐름과 Ralph 루프가 어떤 순서로 연결되는지 읽고, 무한 반복이 아니라 수렴 구조라는 점을 표시한다.
pyproject.toml · 학습자는 Python 기반 CLI/MCP 프로젝트의 의존성과 패키지 경계를 보고 어디까지가 실행 하네스의 배포 단위인지 확인한다.
src/ouroboros/bigbang/ · 학습자는 인터뷰, ambiguity scoring, brownfield explorer가 요구사항을 seed 이전 단계에서 어떻게 좁히는지 관찰한다.
src/ouroboros/execution/ · 학습자는 계층형 AC 분해가 실행 순서와 검수 단위를 어디에서 강제하는지 찾는다.
src/ouroboros/evaluation/ · 학습자는 검수 단계별 평가 게이트가 재시도와 종료 판단을 어떻게 분리하는지 확인한다.
src/ouroboros/evolution/ · 학습자는 Wonder/Reflect 재정의 흐름과 convergence detection이 반복을 진화 루프로 만들면서 어디에서 멈춤 기준을 두는지 본다.
src/ouroboros/persistence/ · 학습자는 event sourcing과 checkpoints가 상태 저장, rewind, 추적 가능성을 어떤 파일 경계로 담당하는지 표시한다.
src/ouroboros/mcp/ · 학습자는 MCP client/server integration이 외부 도구 호출을 어떤 통로로 제한하고 관찰 가능하게 만드는지 본다.
src/ouroboros/orchestrator/ · 학습자는 Claude Code, Codex CLI 등 실행 환경 경계가 모델 실행 환경을 바꿔도 같은 하네스 흐름을 유지하는 위치인지 확인한다.

Ouroboros MCP 하네스 아키텍처 설계 포인트

아키텍처의 중심은 interview → seed → execute → evaluate → evolve를 정해진 순서로 통과시키는 전체 연결 파이프라인이다. 좋은 프롬프트를 이어 붙인 것이 아니라, 각 단계의 입력, 산출물, 다음 단계 진입 조건을 코드형 경계로 둔다.
src/ouroboros/bigbang/과 Seed 관련 흐름은 입력 정제층이다. Socratic Interview로 사람의 암묵지를 꺼내고, Seed와 AC Tree로 실행 가능한 데이터 구조와 검수 단위를 만든다.
src/ouroboros/execution/과 src/ouroboros/evaluation/은 실행과 검수를 분리하는 검수 경계이다. 실행 결과가 바로 완료로 처리되지 않고 검수 단계별 평가 게이트를 거쳐 종료, 재시도, 재질문으로 나뉜다.
src/ouroboros/evolution/과 src/ouroboros/persistence/는 반복을 추적 가능한 반복 추적 경계로 바꾼다. Wonder/Reflect 재정의 흐름, convergence detection, event store, checkpoints, rewind가 있어 같은 실패를 반복하지 않고 이전 결정 지점으로 돌아갈 수 있다.
src/ouroboros/mcp/는 외부 도구 호출의 의미와 진입점을 제한하는 도구 호출 경계이고, src/ouroboros/orchestrator/는 Claude Code, Codex CLI 같은 런타임 차이를 흡수하는 실행 환경 경계다. 학습자는 도구 호출 자체보다 호출 전 조건, 상태 기록, 실패 후 복귀 지점이 어디에 남는지 본다.
따라서 Ouroboros의 MCP형 하네스 설계 핵심은 모든 판단을 안쪽에 넣는 것이 아니다. curriculum.md의 5-2 기준처럼 순서, 상태, 재시도, 체크포인트는 안쪽에 두고, 문제 정의와 최종 수용 판단은 바깥에 남긴다.

학습자 관찰 포인트

interview.md의 "비결정적인 모델을 결정적인 실행으로 묶어내는 장치"라는 설명은 보충 관점으로만 사용하고, curriculum.md의 순서·상태·재시도 강제 목적이 repo 구조에서 어떻게 나뉘는지 본다.
Ouroboros 핵심 로직 분석에는 각 경로 옆에 순서 강제, 상태 저장, 재시도, 종료 판단 중 어떤 역할을 하는지 한 줄로 적는다.
evaluation과 evolution이 무한 반복이 아니라 stop rule과 수렴 판단을 필요로 한다는 점을 5-3의 코드형 통제 기준과 연결한다.
레퍼런스 repo 설치/실행 검증은 하지 않고 README, 디렉터리명, 파일 경계만 학습자 관찰 근거로 사용한다.

Primary source: curriculum.md rows 59-61.

Repo reference: lecture-decks.seed.yaml reference repo https://github.com/Q00/ouroboros.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · OUROBOROS

같은 코드를 네 번 다르게 읽는다

5-4. 최종 프로젝트 및 케이스 스터디46 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · 4C 분업 경계

① 4C × Ouroboros: 4장에서 만든 네 경계가 코드 안에 그대로 있다

C₁ Contract · 계약

Seed · AC Tree

실행 전에 무엇을 할지 못 바꾸게 고정한다. 4장에서 만든 리프(목적·입력·범위·완료)와 같은 칸이다.

C₂ Context · 맥락

event store

세션이 끝나도 결정·실패 이력이 남아 다음 입력이 된다. 4장 handoff 양식이 하던 일이다.

C₃ Control · 통제

execute → evaluate

만드는 단계와 판정하는 단계를 섞지 않는다. 4장 3단 검수(형식·증거·보정)와 같다.

C₄ Confidence · 신뢰

consensus · drift

평가가 한 방향인지, 원래 목적에서 벗어났는지 보고 맡겨도 될지 정한다. 4장 verdict(통과·재작업·재질문·종료)와 같다.

5-4. 최종 프로젝트 및 케이스 스터디47 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · Capability 레이어

② Capability Matrix × Ouroboros: 같은 워크플로우, 6 native 런타임

Workflow Layer

모두 같다 · `core/`

Seed · AC tree · event store · 평가 원칙. 6 native 런타임이 같은 코드를 쓴다.

Runtime Layer

런타임마다 다르다 · `providers/`

각 adapter가 인증·도구·권한을 한 인터페이스로 정리한다. Native 6 + 추가 4.

Integration

진입점만 다르다 · `mcp/`·`cli/`·`tui/`

같은 워크플로우가 세 진입점으로 노출된다. 안쪽은 같다.

Declared capability

능력을 명시 선언

skill_dispatch · targeted_resume · structured_output. 호출 측이 추측하지 않는다.

5-4. 최종 프로젝트 및 케이스 스터디48 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · SKILL.md 묶음

③ 스킬 추상화 × Ouroboros: 묶음 단위로 런타임 독립

묶음 위치

`skills/*/SKILL.md`

SKILL.md + hooks + references가 한 폴더로 묶여 있다. 3장 워크스페이스와 같은 구조다.

호출 진입점

`commands/` · `plugin/skills/`

같은 SKILL.md가 Claude는 ooo <skill>, Codex는 ~/.codex/skills/로 배치.

capability 매칭

`skill_dispatch`

선언했으면 dispatcher로 라우팅, 아니면 SKILL.md를 인라인 prompt로 흡수.

재사용 자산

3장 워크스페이스는 그대로

3장 SKILL.md+hooks가 그대로 재사용된다. 변하는 건 호출 통로(adapter)뿐이다.

5-4. 최종 프로젝트 및 케이스 스터디49 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · Stop rule 멈춤

④ Stop rule × Ouroboros: 무한 루프를 막는 네 곳

exit conditions

`core/` 종료 로직

AC가 모두 passed면 종료. 본인: 단계별 통과 조건 명시.

consensus gating

`evaluation/`

3단 평가가 같은 방향이면 통과, 어긋나면 재시도·재질문. 본인: 통과·재작업·재질문·종료.

drift detection

`observability/`

Seed 의도에서 벗어나면 stop. 본인: "목적에서 벗어났나" 점검.

regression detection

`evolution/`

이전 단계보다 나빠지면 stop. 본인: "지난 단계보다 좋아졌나" 비교.

5-4. 최종 프로젝트 및 케이스 스터디50 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · 4C × OUROBOROS

Ouroboros는 4C를 코드로 구현한 것

5-4. 최종 프로젝트 및 케이스 스터디51 / 60

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · NEXT PRACTICE

다음 실습: Ouroboros 코드를 직접 뜯어본다

무엇을 하나

repo를 직접 읽는다

Ouroboros repo를 열고 4-4 분업형 하네스를 옆에 둔다. 설치·실행 없이 README와 디렉토리 구조만 본다.

무엇을 찾나

코드에서 네 가지를 한 줄씩

① 분업 네 경계: Contract·Context·Control·Confidence
② workflow / runtime / integration 분리
③ SKILL.md 묶음 위치
④ 멈춤 로직 네 곳: exit·consensus·drift·regression

입력

4-4 + 5-2 산출물

4장 분업형 하네스 v1 + 5-2 런타임 독립 하네스 그래프. 이게 분석의 출발점이다.

출력 → 빌드 재료

`providers/` 의 Claude·Codex 어댑터 한 쌍

두 어댑터가 공통 complete() 하나를 공유한다 — 같은 인터페이스, 런타임만 다름. 네 항목 분석은 4-2 설계도로, 이 어댑터 한 쌍은 4-3 review_parallel 빌드 재료로 넘어간다.

5-4. 최종 프로젝트 및 케이스 스터디52 / 60

● SPEAKER NOTESSLIDE 52 / 60

이 슬라이드는 실습 2005-4-1 안내로 바로 이어진다. 학습자가 실습으로 들어가기 전 "왜 4관점인지 / 어떤 입력으로 / 어떤 출력으로 / 25분 안 무엇을 본다"를 한 화면에 잡는다.

발화 멘트: 본인이 4-4에서 만든 분업형 하네스 v1이 있을 것이다. 그걸 펴 놓고 ouroboros repo를 옆에 두면, "내 네 칸이 ouroboros 어디에 있을까"가 자연스럽게 보인다. 그게 실습의 첫 단계.

마무리는 providers/에서 닫는다. base.py의 complete() 하나에 claude_code_adapter·codex_cli_adapter 두 구현 — "같은 인터페이스, 런타임만 다름"을 눈으로 확인시키고, 이 어댑터 한 쌍이 4-3 review_parallel(인용 ∥ 사실 병렬 검수) 빌드 재료임을 분명히 한다. 4관점 관찰이 곧바로 "내가 쓸 어댑터"로 수렴한다.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · APPLIED WALKTHROUGH

적용 워크스루: Ouroboros 흐름을 내 하네스로 번역하기

관찰 단계	Ouroboros 참조	내 하네스 번역
인터뷰 · gate	Socratic Interview → Seed	실행 전 비어 있으면 안 되는 입력을 막아 둔다.
명세 · spec	Seed → AC Tree	목표, 제약, 성공기준을 작업 단위 옆에 붙인다.
작업·검수 · review	Execute → Evaluate	만드는 단계와 판정하는 단계를 섞지 않는다.
운영 · operate	Event store → Rewind	실패 사유, 결정, 복귀 지점을 다음 실행 입력으로 남긴다.

5-4. 최종 프로젝트 및 케이스 스터디53 / 60

● SPEAKER NOTESSLIDE 53 / 60

적용 워크스루 해설

시간 큐 / 레퍼런스 주석

진행 시간: 5:45-8:45. 표의 네 행을 각각 약 35초씩 설명하고, 마지막 40초는 "Ouroboros 이름 → 내 하네스 질문 → 설계도 문장" 번역 리듬을 시연한다.
근거: curriculum.md rows 59-61의 최종 설계도 요구와 interview.md lines 21, 29, 45-46의 Seed, event store, rewind, 도메인별 판단 프레임을 연결한다.

이 슬라이드는 5-4의 별도 적용 워크스루 섹션이다. 앞 슬라이드가 Ouroboros를 사례로 소개했다면, 여기서는 같은 구조를 본인의 최종 하네스 설계 언어로 번역한다.
첫 행은 인터뷰(gate)다. interview.md의 Socratic Interview와 Seed 설명, 그리고 src/ouroboros/bigbang/ 관찰을 바탕으로 "실행 전에 비어 있으면 안 되는 입력"을 gate로 낮춰 설명한다.
둘째 행은 명세(spec)다. Seed와 AC Tree는 제품 기능 소개가 아니라 목표, 제약, 성공기준을 다음 실행 단위가 읽을 수 있게 만드는 관찰 언어로 쓴다.
셋째 행은 작업·검수(review)다. src/ouroboros/execution/과 src/ouroboros/evaluation/은 설치나 실행 보장 없이, 작업과 판정의 경계가 어디에 놓이는지 읽는 참고 경로로만 다룬다.
넷째 행은 운영(operate)이다. src/ouroboros/persistence/와 rewind 표현은 실패 사유와 복귀 지점을 다음 실행 입력으로 남기는 구조를 설명할 때만 사용한다.
라이브 진행은 한 행씩 "Ouroboros 이름 → 내 하네스 질문 → 설계도에 적을 문장" 순서로 말한다. 예를 들어 Seed는 "AI가 임의로 채우면 안 되는 입력은 무엇인가"로 번역하고, event store는 "다음 운영자가 반드시 알아야 할 결정은 무엇인가"로 번역한다.
source-fidelity guardrail: repo 설치, 런타임 성공, 성능, 채택 규모, 별점은 말하지 않는다. curriculum.md rows 59-61, interview.md, 승인된 repo path 관찰 범위에 머문다.

Primary source: curriculum.md rows 59-61.

Repo reference: lecture-decks.seed.yaml reference repo https://github.com/Q00/ouroboros.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · LIVE EXAMPLE

라이브 예시: 요청이 새 과제로 발산할 때

원래 요청

런타임 확장 흐름을 문서에 반영하는 리브랜딩 과제

발산 신호

검토 중 자동 감사 시스템이라는 새 작업이 등장한다.

통제 질문

이 제안은 현재 Seed와 AC Tree 안에 있는가?

운영 판단

기록하고, 재질문하고, 필요하면 체크포인트로 돌아간다.

5-4. 최종 프로젝트 및 케이스 스터디54 / 60

● SPEAKER NOTESSLIDE 54 / 60

라이브 예시 해설

시간 큐 / 레퍼런스 주석

진행 시간: 8:45-11:30. 45초는 원래 요청, 45초는 발산 신호, 45초는 Seed/AC Tree 확인 질문, 30초는 event store/rewind 관점의 운영 판단으로 나눈다.
근거: interview.md lines 39-40의 Ouroboros drift anecdote를 본인 경험으로만 사용한다. 새 외부 사례나 성공률, 성능, repo 런타임 보장은 추가하지 않는다.

이 예시는 interview.md의 Ouroboros 경험담을 5-4의 라이브 설명용으로 낮춘 것이다. "이론과 실제 운영은 다르다"는 포인트를 먼저 말하고, 예시가 새 외부 사례가 아니라 인터뷰에 나온 본인 경험임을 밝힌다.
원래 요청은 런타임 확장 흐름을 문서에 반영하는 리브랜딩 과제다. body에는 간결하게만 두고, 구체 이름을 길게 늘어놓지 않는다.
발산 신호는 검토 과정에서 "문서만 고치는 대신 자동 감사 시스템을 만들자"는 새 제안이 생기는 장면이다. 이 제안이 유익할 수도 있지만, 현재 Seed와 AC Tree를 바꾸는 순간인지 확인해야 한다.
통제 질문은 세 가지다. 첫째, 새 제안이 기존 성공기준 안에 있는가. 둘째, 새 작업이 들어오면 완료 기준이 어떻게 바뀌는가. 셋째, 지금 진행 중인 흐름은 이어갈지, 중단하고 재질문할지, 체크포인트로 돌아갈지 결정했는가.
Ouroboros 관찰 언어로 풀면 Seed는 원래 요청과 제약, AC Tree는 완료 판단, event store는 "왜 방향을 바꾸기로 했는지"의 기록, rewind는 이전 결정 지점으로 돌아가는 복귀 경로다.
본인 번역 문장: "내 하네스가 새 아이디어를 발견했을 때, 바로 실행하지 않고 현재 목표의 변경인지 별도 과제인지 판정하는 칸이 있는가?"라고 묻는다.
전환 멘트: 이 예시를 보고 나면, 다음 슬라이드에서 그 파이프라인이 한 단계라도 끊기면 무엇이 무너지는지 본다. 단순한 순서도가 아니라 발산을 통제하는 운영 구조라는 점이 드러난다.

Primary source: curriculum.md rows 59-61.

Supporting reference: interview.md lines 39-40 for the Ouroboros drift anecdote and lines 45-48 for non-cloning framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · CORE CONCEPT

한 단계가 끊기면 그 다음이 무너진다

인터뷰(gate) 누락

추측이 시작된다

다음 단계가 쓸 질문·결정이 없어 빈자리를 임의로 채운다.

명세(spec) 누락

목표가 흐려진다

제약·성공기준이 비어 작업 단계가 알아서 추측한다.

검수(review) 누락

검수가 사라진다

판정 없이 완료 처리돼 오류가 그대로 나간다.

운영(operate) 누락

같은 실패 반복

결정·복귀 지점 기록이 없어 다음 실행이 처음부터 시작한다.

5-4. 최종 프로젝트 및 케이스 스터디55 / 60

● SPEAKER NOTESSLIDE 55 / 60

핵심개념

시간 큐 / 레퍼런스 주석

진행 시간: 11:30-13:15. 네 카드의 책임을 20초씩 설명하고, 남은 시간은 interview 없이 seed가 비는 경우와 review 없이 operate로 넘어가는 경우를 비교한다.
근거: curriculum.md rows 60-61의 "전체 연결"과 "런타임 독립 하네스 실행 데모" 산출물을 중심으로 설명하고, interview.md의 Seed, AC Tree, event store, rewind는 보충 관찰 언어로만 둔다.

전체 연결 파이프라인은 5-4의 핵심 개념이다. 좋은 프롬프트를 여러 개 나열하는 것이 아니라, 각 단계의 입력과 산출물이 다음 단계로 이어지는 연결 구조를 만든다.
interview는 질문과 결정을 남기고, seed 또는 spec은 목표와 제약, 성공기준을 실행 입력으로 고정한다.
execute와 review는 작업과 검수를 분리한다. operate는 종료, 재시도, 재질문, 복귀 지점을 운영 가이드로 남긴다.
Ouroboros 관찰은 이 구조를 이해하기 위한 참고다. 4장의 v1 하네스가 runtime surface와 workflow를 분리했다면, 여기서는 Seed, AC Tree, event store, rewind라는 이름으로 상태와 복귀 지점까지 같이 본다. 본인 결과물은 자기 업무용 최종 하네스와 운영 가이드다.

핵심개념 단계별 해설

interview 단계의 책임은 답변을 많이 모으는 것이 아니라 모호한 자리를 줄이는 것이다. 본인은 업무 목표, 금지 조건, 입력 자료, 완료 기준, 예외 상황을 질문으로 끌어내고 다음 단계가 사용할 결정 목록으로 남긴다.
seed / spec 단계의 책임은 그 결정을 실행 가능한 입력으로 고정하는 것이다. 여기서 목표, 제약, 성공 기준이 흐릿하면 execute 단계가 다시 추측하게 되므로, 2장의 Define 고정과 5-2의 안/밖 경계를 다시 연결한다.
execute / review 단계의 책임은 만드는 일과 판정하는 일을 섞지 않는 것이다. 작업자는 작은 단위의 산출물을 만들고, review는 AC Tree나 체크리스트처럼 분리된 기준으로 종료, 재시도, 재질문을 가른다.
operate 단계의 책임은 한 번의 성공을 다음 실행의 자산으로 바꾸는 것이다. 결정, 실패 사유, 되돌아갈 지점, 다음 질문을 운영 가이드에 남겨야 하며, 이 지점에서 event store와 rewind가 관찰 언어로 다시 연결된다.

Ouroboros 앵커와 본인 산출물의 차이

Ouroboros의 interview → Seed → execute → evaluate → evolve 흐름은 전체 연결 파이프라인을 설명하는 기준점이다. 4장에서 만들었던 node·edge·guard·route가 상태 기록과 복귀 지점을 만나면 어떻게 더 운영 가능한 구조가 되는지 보여주는 관찰 언어로 쓴다. 하지만 본인이 제출하는 것은 Ouroboros 구조도 복사본이 아니라 자기 업무의 Final Harness Graph다.
Seed는 "내 업무에서 AI가 추측하면 안 되는 실행 입력"으로 번역한다. AC Tree는 "작업 결과를 작게 나누어 판정하는 기준"으로 번역한다. event store와 rewind는 "다음 실행에서 재사용할 운영 기록과 복귀 지점"으로 번역한다.
강의 중에는 네 카드가 서로 이어지는 순서를 계속 강조한다. interview 없이 seed를 쓰면 입력이 빈약하고, seed 없이 execute를 시작하면 추측이 늘고, review 없이 operate로 넘어가면 운영 가이드가 근거 없는 기록으로 남는다.

본인이 던질 확인 질문

내 하네스에서 인터뷰 단계에 반드시 들어와야 하는 입력은 무엇인가?
seed / spec에 고정하지 않으면 AI가 임의로 채울 위험이 큰 결정은 무엇인가?
execute 결과를 review가 판정할 때 형식, 의미, 목적 기준은 어디에 적혀 있는가?
operate 단계에서 다음 실행을 위해 남겨야 하는 결정, 실패, 복귀 지점은 무엇인가?

Primary source: curriculum.md rows 59-61.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-4-2

구조: 2~5장에서 만든 하네스를 회의록 → 1page 한 줄로 잇는다

실습 목표

하네스를 단순 프롬프트 묶음이 아닌 파이프라인으로 엮기

수행 과제

2~5장의 인터뷰·명세·작업·검수·운영을 한 파이프라인으로 잇는다.

산출물

Final Harness Graph

완료 기준

각 단계의 입력, 출력, 실패 시 복귀 지점이 보인다.

Final Harness Graph 구성 — 회의록 → 1page

인터뷰 · 2장"이 1page를 누가, 어떤 결정을 위해 읽는가"를 인터뷰 하네스로 물어 요구사항·Define을 만든다.
명세 · 3장그 Define을 회의록→1page 변환 규칙(고정·남김·질문)으로 옮겨 매번 같은 형식으로 잠근다.
작업 · 4장ask·build·review sub agent로 회의록을 1page 초안까지 끌고 간다.
검수 · 4→5장인용 검사(Claude)·사실 검사(Codex)를 MCP로 병렬 실행(review_parallel)→merge해 통과·재작업·재질문을 나눈다.
운영 · 5장순서·상태·재시도·멈춤(exit·retry·ask-back)을 코드로 강제한다. ask-back이면 2장 인터뷰 하네스로 돌아가 spec을 갱신한다.

5-4. 최종 프로젝트 및 케이스 스터디56 / 60

● SPEAKER NOTESSLIDE 56 / 60

2005-4-2 20분 확장 운영 · 00:00-20:00

5-4. 최종 프로젝트 및 케이스 스터디의 이 클립은 20분 단독 진행을 기준으로 한다. 클립 제목은 4C → Capability Graph → MCP 하네스로 연결하기이고, 핵심 내용은 하네스를 단순 프롬프트 묶음이 아닌 파이프라인으로 엮기이다. 산출물 기준은 Final Harness Graph로 둔다.

00:00-02:00 · 산출물 확인: 이 클립은 실습이 반드시 필요하다. Final Harness Graph를 오늘의 제출 단위로 확인하고 핵심 문장 '하네스를 단순 프롬프트 묶음이 아닌 파이프라인으로 엮기'를 완료 기준으로 둔다.
02:00-04:00 · 입력 정리: 앞 클립에서 만든 질문, 표, 초안, route signal 중 이번 산출물에 넣을 입력만 고른다.
04:00-08:00 · 첫 작성: 빈칸을 완벽히 채우려 하지 말고 제목, 목적, 입력, 제약, 완료 기준부터 빠르게 적는다.
08:00-12:00 · 핵심 작성: 산출물의 중심 칸을 채운다. 모르는 값은 추측하지 않고 질문 또는 확인 필요로 남긴다.
12:00-15:00 · 자기 검수: 형식이 맞는지, 핵심 문장이 드러나는지, 사람 판단 영역이 남아 있는지 확인한다.
15:00-18:00 · 수정: 가장 모호한 문장 하나와 가장 위험한 빈칸 하나를 골라 좁힌다.
18:00-20:00 · 제출 / 전환: Final Harness Graph의 완료 기준을 확인하고 다음 클립에서 재사용할 값과 버릴 값을 나눈다.

20분 본인 운영 포인트

화면의 문장은 짧게 읽고, 실제 분량은 질문, 비교, 자기 업무 적용, 검수 멘트로 채운다.
본인이 적을 값은 한 번에 하나만 제시한다. 여러 칸을 동시에 채우게 하면 실습 시간이 산만해진다.
새 외부 사례나 검증되지 않은 수치 주장은 추가하지 않고 curriculum.md와 interview.md의 하네스 관점 안에서 설명한다.

실습 절차 / 체크포인트

시간 큐 / 레퍼런스 주석

진행 시간: 13:15-15:15. 30초는 실습 목표, 60초는 인터뷰·명세·작업·검수 네 칸의 입력/출력 설명, 30초는 실패 시 복귀 지점 체크로 진행한다.
근거: curriculum.md row 60의 Final Harness Graph 산출물에 맞춘다. Ouroboros 관찰값은 구조 참고이며 설계도 복사본을 요구하지 않는다.

실습 목표: 하네스를 단순 프롬프트 묶음이 아닌 파이프라인으로 엮기.
수행 과제: 인터뷰 질문, 명세 항목, 작업 분해, 검수 기준, Loop Protocol을 하나의 설계도로 연결한다.
수행 절차 1: 2장 인터뷰 하네스 산출물(요구사항·Define), 3장 회의록→1page 변환 규칙, 4장 sub agent 분업·검수, 5장 MCP flow/graph/loop를 한곳에 모은다. 이 넷이 한 파이프라인의 인터뷰·명세·작업·검수·운영 다섯 단계가 된다.
수행 절차 2: 각 산출물이 다음 단계의 입력이 되도록 인터뷰, 명세, 작업, 검수, 종료 흐름을 화살표로 잇는다.
수행 절차 3: 흐름이 끊기는 지점에는 추가 질문, handoff, 재시도 기준 중 어떤 장치가 필요한지 표시한다.
수행 절차 4: 각 단계 옆에 입력, 출력, 저장할 상태, 실패 시 복귀 지점, 사람이 판단할 조건을 한 줄씩 적는다.
인터뷰 하네스(2장)는 두 곳에 끼운다 — 변환 전 "이 1page는 무엇을 위한 것인가"를 정하는 앞 gate, 그리고 검수가 ask-back을 띄울 때 다시 돌려 spec을 갱신하는 재질문 지점.
산출물 이름: Final Harness Graph.
체크포인트: 인터뷰 단계는 모호함을 줄이고, 명세 단계는 What을 고정하며, 작업 단계는 실행 단위를 나누고, 검수 단계는 결과가 목적에 맞는지 판정해야 한다.
체크포인트: 각 단계가 다음 단계의 입력을 만든다는 점이 보여야 한다. 단순히 좋은 프롬프트를 순서대로 모은 문서가 되면 안 된다.
체크포인트: 2005-4-1의 Ouroboros 관찰값은 설계도에 복사하지 않고, 4장 v1에서 남긴 순서 강제, 상태 저장, 재시도, 종료 판단의 빈칸을 채우는 참고 구조로만 반영한다.
완료 확인 체크포인트: Final Harness Graph에 인터뷰, 명세, 작업, 검수, 종료 단계의 입력·출력과 실패 시 복귀 지점이 보이면 실습 완료로 본다.

Primary source: curriculum.md rows 59-61.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · APPLICATION QUESTION

적용 질문: 내 업무용 하네스는 어디서 마무리되나

시작 입력

실행 전 반드시 있어야 할 문제 정의·성공기준

상태 저장

다음 실행자가 이어받을 결정·실패 사유·체크포인트를 어디에 남기나?

검수 기준

결과가 목적에 맞는지 어떤 기준으로 판정할 것인가?

운영 가이드

종료·재시도·재질문을 선택하는 사람과 시점

5-4. 최종 프로젝트 및 케이스 스터디57 / 60

● SPEAKER NOTESSLIDE 57 / 60

적용 질문

시간 큐 / 레퍼런스 주석

진행 시간: 15:15-16:45. 네 질문을 빠르게 읽고, 본인이 가장 불안한 한 칸만 고르게 한 뒤 그 칸이 실행 전 gate인지 운영 기록인지 확인한다.
근거: curriculum.md rows 59-61의 프로젝트 산출물 기준과 interview.md lines 45-48의 "자기 도메인에 맞는 하네스" 프레임을 사용한다.

이 질문은 최종 데모 직전의 점검이다. 각자 만든 설계도가 실제 운영 가능한지 확인한다.
시작 입력에는 문제 정의, 원본 자료, 성공기준처럼 실행 전 비어 있으면 안 되는 항목을 둔다.
상태 저장에는 결정과 실패 사유, 체크포인트를 둔다. 검수 기준에는 결과가 목적에 맞는지 판정할 기준을 둔다.
운영 가이드에는 종료, 재시도, 재질문을 누가 언제 선택하는지 남긴다. 이 답이 있어야 최종 데모가 결과물 설명이 아니라 하네스 운영 설명이 된다.

Primary source: curriculum.md rows 59-61.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 2005-4-3

[최종 프로젝트] 내 업무용 런타임 독립 하네스 실행 데모

실습 목표

수강 후 바로 가져갈 실무용 최종 결과물 완성

수행 과제

내 업무용 하네스를 완성하고, 검수를 MCP로 병렬 실행하는 흐름까지 데모한다.

산출물

런타임 독립 하네스 실행 데모

완료 신호

사용 조건, 실행 순서, 실패 대응, exit/retry/ask-back route가 설명된다.

Loop Protocol · route section

route	condition	next action	operation log
exit	목표와 success signal을 만족하고 남은 개선이 업무 가치에 비해 작다.	결과를 확정한다.	verdict 근거와 남은 uncertainty
retry	형식, 검증, 실행 중 하나가 실패했지만 입력은 충분하다.	checkpoint로 돌아가 실패한 검사만 다시 돌린다(통과 결과 보존).	실패 사유와 복귀 node
ask-back	요구사항이나 판단 신호가 비어 반복해도 수렴하지 않는다.	2장 인터뷰 하네스를 다시 돌려 spec을 갱신한다.	질문과 갱신된 condition

5-4. 최종 프로젝트 및 케이스 스터디58 / 60

● SPEAKER NOTESSLIDE 58 / 60

2005-4-3 20분 확장 운영 · 00:00-20:00

5-4. 최종 프로젝트 및 케이스 스터디의 이 클립은 20분 단독 진행을 기준으로 한다. 클립 제목은 [최종 프로젝트] 내 업무용 런타임 독립 하네스 실행 데모이고, 핵심 내용은 수강 후 바로 가져갈 실무용 최종 결과물 완성이다. 산출물 기준은 [산출물] 런타임 독립 하네스 실행 데모로 둔다.

00:00-02:00 · 목표 / 산출물: 이 클립은 실습이 반드시 필요하다. [산출물] 런타임 독립 하네스 실행 데모를 완성 대상으로 두고 핵심 문장 '수강 후 바로 가져갈 실무용 최종 결과물 완성'를 완료 신호로 읽는다.
02:00-05:00 · 입력 확인: 앞 클립의 체크리스트, 설계도, 관찰값, 빈칸을 모아 지금 쓸 입력과 버릴 입력을 나눈다.
05:00-09:00 · 조립: 목적, 입력, 처리 규칙, 출력 형식, 금지사항, exit condition을 하나의 하네스 산출물로 조립한다.
09:00-13:00 · 흐름 검수: 사용자가 이 산출물을 복붙하거나 실행 흐름으로 따라갔을 때 어디서 질문하고 어디서 멈추는지 확인한다.
13:00-17:00 · 보정: 누락된 제약, 과한 자동화, 사람 판단 영역 침범을 찾아 수정한다.
17:00-20:00 · 데모 / 완료: [산출물] 런타임 독립 하네스 실행 데모이 다음 장 또는 실무에서 재사용 가능한지 한 문장으로 설명하고 마무리한다.

20분 본인 운영 포인트

화면의 문장은 짧게 읽고, 실제 분량은 질문, 비교, 자기 업무 적용, 검수 멘트로 채운다.
본인이 적을 값은 한 번에 하나만 제시한다. 여러 칸을 동시에 채우게 하면 실습 시간이 산만해진다.
새 외부 사례나 검증되지 않은 수치 주장은 추가하지 않고 curriculum.md와 interview.md의 하네스 관점 안에서 설명한다.

실습 절차 / 체크포인트

시간 큐 / 레퍼런스 주석

진행 시간: 16:45-18:30. 35초는 최종 산출물 구성, 45초는 exit·retry·ask-back route, 25초는 데모에서 반드시 말할 운영 기록으로 진행한다.
근거: curriculum.md row 61의 "[산출물] 런타임 독립 하네스 실행 데모"를 그대로 따른다. interview.md의 non-cloning framing은 운영 가이드 방향을 설명하는 보충 근거다.

실습 목표: 수강 후 바로 가져갈 실무용 최종 결과물 완성.
수행 과제: 앞에서 만든 MCP Candidate Flow, Runtime-independent Harness Graph, Loop Protocol, Final Harness Graph를 하나로 묶어 데모 가능한 형태로 정리한다.
수행 절차 1: 앞 실습 산출물을 최종 하네스 본문, 실행 순서, 운영 가이드 섹션으로 재배치한다.
수행 절차 2: 실제 업무 요청 하나를 넣었을 때 시작 입력, 중간 상태, 검수, 종료까지 설명할 데모 흐름을 만든다.
검수 단계는 인용·사실 검사를 MCP(review_parallel)로 병렬 실행→merge하는 것으로 데모한다. 인용은 Claude(Anthropic 메시지 API), 사실은 Codex(codex exec)로 — 같은 프롬프트·다른 런타임이라 5-2 런타임 독립이 코드로 드러난다. 바깥에선 콜 하나, 안에선 두 세션이 병렬로 도는 것을 보여주고, 한쪽만 실패하면 통과 결과를 보존한 채 실패한 검사만 다시 돌린다는 점을 짚는다. 실습 자료(2005-4-3)에 import 없이 바로 돌아가는 최소 스켈레톤이 들어 있다.
수행 절차 3: 실패했을 때 재시도할 지점과 사람이 다시 판단해야 할 조건을 운영 가이드에 남긴다.
수행 절차 4: 데모 마지막에는 결과물뿐 아니라 어떤 기준으로 멈췄는지, 다음 운영자가 어디를 보면 되는지까지 설명한다.
실행 기준 섹션: 본문 Loop Protocol처럼 exit, retry, ask-back을 나누고 각 route의 condition, next action, operation log를 채운다. ask-back은 사람에게 막연히 묻는 대신 2장 인터뷰 하네스를 다시 돌려 spec을 갱신하는 단계로 연결한다.
산출물 이름: [산출물] 런타임 독립 하네스 실행 데모.
체크포인트: 운영 가이드에는 시작 입력, 실행 순서, 상태 기록 위치, 실패 대응, exit condition, 사람이 다시 판단해야 하는 ask-back condition이 들어가야 한다.
체크포인트: interview.md에 적힌 강의 목표는 보충 기준으로만 사용한다. "Ouroboros 복사본"을 만드는 것이 아니라, 본인 도메인에 맞는 하네스를 계속 진화시킬 수 있는 판단 구조를 남긴다.
완료 확인 체크포인트: [산출물] 런타임 독립 하네스 실행 데모에 사용 조건, 실행 순서, 상태 기록, 실패 대응, exit/retry/ask-back route, 데모 흐름이 들어 있으면 실습 완료로 본다.

Primary source: curriculum.md rows 59-61.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE 5-4 · SUMMARY

1장에서 5장까지

하네스 엔지니어링은 비결정적인 AI를 deterministic하게 묶어 원하는 결과를 얻어낸다

markdown으로 규칙을 잠그고, sub agent로 일을 나누고, MCP로 순서를 코드로 강제했다. 도구는 매 장 단단해졌지만 목표는 하나였다 — 매번 달라지는 모델에서 매번 같은 결과를 뽑아낸다.

5-4. 최종 프로젝트 및 케이스 스터디59 / 60

● SPEAKER NOTESSLIDE 59 / 60

요약 / 전환

시간 큐 / 레퍼런스 주석

진행 시간: 18:30-19:30. 30초는 화면의 한 줄 — "비결정적인 AI를 deterministic하게 묶는 일" — 을 짚고, 20초는 markdown→sub agent→MCP 1~5장 회고, 10초는 6장의 팀 확장으로 전환한다.
근거: curriculum.md rows 59-61과 interview.md lines 45-48의 도메인별 하네스 판단 프레임을 결론으로 사용한다.

화면 메시지: 하네스 엔지니어링은 비결정적인 AI를 deterministic하게 묶어 원하는 결과를 얻는 일이다. markdown으로 규칙을 잠근 1~3장, sub agent로 일을 나눈 4장, MCP로 순서를 코드로 강제한 5장이 같은 목표의 세 단계였다고 한 번에 회고한다.
그 위에 interview.md의 결론을 얹는다 — Ouroboros 복제가 아니라, 그 설계 사고를 자기 업무의 순서·상태·재시도·멈춤 기준으로 번역하는 것이 이 강의가 남기는 능력이다.
최종 하네스와 운영 가이드에는 사용 조건, 실행 순서, 저장할 상태, 실패 대응, 종료 기준, 데모 흐름이 남아야 한다.
다음 장에서는 이 개인 하네스를 팀의 공유 인프라, 관측, 플레이그라운드 관점으로 확장한다.

Primary source: curriculum.md rows 59-61.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.

FAST CAMPUS · CHAPTER 05 · KEYNOTE END

CLOSING · CHAPTER 05

MCP형 하네스 프로젝트 정리

문서와 분업으로 만든 흐름을, 순서와 상태와 멈춤 기준이 있는 코드형 하네스로 확장했습니다.

완료: decks/chapter-05.html Cover · Dividers · Clip slides · Speaker notes

챕터 이동 이전 · 4장. 분업형 하네스 프로젝트 현재 · 5장. MCP형 하네스 프로젝트 다음 · 6장. AI Native 팀으로 가는 길 정리 5-1 · 코드형 통제 도입 5-2 · Capability Graph와 MCP 아키텍처 5-3 · Satisfice 멈춤 기준 CHAPTER 05 · 5-1~5-3 흐름 PROJECT · 최종 하네스와 Ouroboros

WRAP-UP60 / 60

● SPEAKER NOTESSLIDE 60 / 60

정리 멘트

5-1. 코드형 통제 도입: 사람이 마음대로 건너뛰는 순서는 코드로 잠근다.
5-2. Capability Graph와 MCP 아키텍처: workflow layer, runtime adapter, integration surface를 분리해 런타임 독립 하네스 그래프로 만든다.
5-3. Satisfice 멈춤 기준: 충분하면 exit, 부족하면 retry, 입력이 모호하면 ask-back으로 route를 나눈다.
5-4. 최종 프로젝트: Ouroboros를 사례로 읽고 Final Harness Graph와 런타임 독립 하네스 실행 데모로 마무리한다.

다음 장에서는 개인의 하네스를 팀의 생태계와 운영 인프라로 확장한다.

Primary source: curriculum.md rows 50-61.

Supporting reference: interview.md deterministic execution, Seed, AC Tree, Ralph loop, event store, rewind, and Ouroboros framing.