🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Fable 5와 Mythos class models 시대의 /Plan Skill은 에이전트에게 사고를 맡기는 도구가 아니라, 사람이 원하는 결과·검증 기준·작업 맥락을 구조화해 더 나은 계획 아티팩트를 만들기 위한 핵심 엔지니어링 레이어다.

📌 핵심 요점

1. 발표자는 계획을 코딩 에이전트에 그대로 외주화하면 모델이 사용자의 의도와 판단 기준을 추측하게 되므로, 계획 skill 자체를 직접 설계해야 한다고 본다.
2. Plan F3는 engineer 개인, engineering team, AI agent가 모두 읽고 실행할 수 있는 살아 있는 계획 문서를 목표로 하며, 단순 프롬프트가 아니라 생성·수정·참조 갱신·빌드·이미지 생성 워크플로까지 포함한다.
3. 새 계획 템플릿은 속도와 토큰 비용보다 성능을 우선하며, Mythos급 모델이 코드베이스와 문제 공간을 더 잘 internalize하도록 큰 스펙, HTML 구조, 이미지, 메타데이터를 적극 활용한다.
4. 핵심 구조는 problem, solution, 관련 파일, 신규 파일, phase별 구현 계획, 체크리스트, validation commands, notes로 정리되며, 각 phase는 실행과 검증이 닫힌 루프를 이루도록 설계된다.
5. 영상의 마지막 주장은 “좋은 계획이 곧 좋은 엔지니어링”이라는 원칙으로 수렴하며, 평균적인 에이전트 결과에서 벗어나려면 자신의 도메인 지식과 작업 방식을 skill과 template 안에 인코딩해야 한다는 것이다.

🧩 배경과 문제 정의

• Fable 5와 Mythos class 모델의 등장으로, 기존 계획 skill을 더 정교한 방식으로 재설계할 필요가 생겼다.
• 계획은 agentic engineering의 핵심 도구다. 이를 모델이나 agent에게 그대로 맡기면, 원하는 결과와 판단 기준을 모델이 추측하게 된다.
• 목표는 속도나 token 비용을 줄이는 데 있지 않다. 더 나은 계획 artifact를 만들어 engineer, engineering team, AI agent가 함께 활용할 수 있는 구조를 세우는 것이다.

🕒 시간순 섹션별 상세정리

1. 계획 skill을 외주화하지 않아야 하는 이유

• 계획 meta skill을 처음부터 다시 만드는 이유는 Fable 5와 Mythos class 모델이 더 높은 planning ability를 열었고, 좋은 계획이 곧 좋은 engineering이라는 전제 때문이다 [00:07]
• 계획 skill은 engineer와 agent가 함께 쓰는 핵심 도구이므로, 이를 coding tool이나 agent에게 그대로 맡기면 모델이 사용자의 의도와 기준을 이미 안다고 가정하는 위험이 생긴다 [00:20]

2. 새 디렉터리와 raw.md에서 시작하는 메타 skill 설계

• 새 프로젝트 디렉터리 plan F3를 만들고 기존 자료 일부만 참고하면서, 중요한 planning meta skill을 처음부터 다시 구성하는 작업이 시작된다 [01:33]
• Cursor는 tab completion 모델 때문에 쓰던 도구였지만 agent interface 중심으로 바뀌었고, 이번 작업에서는 VS Code를 열어 더 직접적인 작성 흐름으로 전환한다 [01:49]

3. Mythos 모델에서 planning과 reviewing의 제약이 바뀌는 지점

• Mythos class 모델은 새로운 capability를 열지만, 그 성능은 계획 단계에 얼마나 upfront investment를 넣는지에 크게 좌우된다 [03:08]
• 계획에 더 많은 노력을 먼저 투입할수록 이후 review 부담은 줄어들며, 모델 capability가 커질수록 이 tradeoff는 더 뚜렷해진다 [03:23]

4. 성능 우선의 tradeoff와 큰 스펙을 쓰는 방식

• 새로운 Mythos class 모델은 planning accuracy와 planning ability를 높여, 원하는 결과를 더 정확하게 지정할 수 있는 조건을 만든다 [04:51]
• agent 작업에서는 performance, speed, cost가 늘 tradeoff를 만들며, 새 plan template은 최적 성능을 위해 speed와 token cost를 의도적으로 희생한다 [05:18]

5. V1 plan format과 templated engineering의 역할

• property-based engineering 흐름으로 넘어가며, 기존 V1 spec은 purpose, variables, output, instructions, workflow, plan format으로 구성된 단순하지만 반복 검증된 구조로 드러난다 [07:37]
• workflow는 agent가 일을 끝내기 위해 따르는 step-by-step action이고, plan format은 실행 때마다 결과 품질을 크게 좌우하는 핵심 요소다 [08:01]

6. Plan F3의 대상 독자와 property 설계

• Mythos class 모델의 intelligence ceiling을 활용하려면 plan skill과 template이 구체적인 property, 즉 section 단위의 구조를 가져야 한다 [09:22]
• 계획 output은 agent drive factor에 의해 생성·수정·소비되며, 대상 독자는 engineer 개인, engineering team, AI agent의 세 집단으로 압축된다 [09:52]

7. 토글 가능한 인간 개입과 갱신형 메타데이터 구조

• 질문·답변 섹션은 작업 범위를 명확히 하는 장치이며, 인간 개입은 기본값이 아니라 필요할 때만 켜는 토글 구조로 설계된다 [12:00]
• 목표는 zero touch engineering에 가깝게 인간을 루프 밖으로 빼되, 작업 강도나 타이밍이 맞지 않을 때는 다시 개입할 수 있게 만드는 것이다 [12:07]

8. 검증 루프와 계획 작성의 엔지니어링 가치

• 검증과 테스트 섹션은 완료 조건을 닫힌 루프로 만들고, 작업이 끝나지 않았을 때 에이전트가 반복할 수 있는 명확한 결과 기준을 제공한다 [13:17]
• 새 파일과 기존 파일 구분, 동기화된 HTML·이미지 스타일, 집중된 임베디드 이미지, 목적·문제·해결 구조가 계획 템플릿의 주요 구성요소가 된다 [13:37]

9. Plan F3 템플릿 순서 정리와 에이전트 투입

• 계획의 미래는 즉흥적 vibe coding이 아니라, 먼저 설계하고 계획하는 방식에서 만들어진다는 관점이 중심에 놓인다 [15:23]
• 새 plan F3 meta skill의 prompt template은 헤더, 목적·문제·해결, H1 제목, HTML 우선 phases, 이미지·스타일 동기화, 검증 섹션, 새 파일 섹션, 작업 항목 순서로 압축된다 [15:31]

10. 로컬 스킬 생성과 초기 스캐폴드 정리

• Opus 4.8 고사고 모드가 사용되지만, 단순 템플릿 생성 작업에는 과한 모델 투입이며 Fable급 모델에도 과한 수준의 작업으로 취급된다 [16:31]
• Fable 재출시와 관련된 논란에서는 jailbreak의 정교함, 정부 보고, Anthropic guardrail의 강도 같은 정치적·운영적 변수가 주변 맥락으로 등장한다 [16:50]

11. HTML·이미지 중심 출력과 목적·지시문 재구성

• QQQ 같은 검색 마커는 섹션 이동과 편집 속도를 높이는 내부 표식으로 쓰이며, 앞서 적은 속성 목록은 실제 구현 작업 목록까지 자연스럽게 보여준다 [18:53]
• 계획 포맷은 HTML을 기본으로 삼고, 이미지 생성 기능도 포함하는 방향으로 정해진다. ChatGPT 이미지 모델을 활용해 계획 산출물에 필요한 이미지를 생성하는 구상이다 [19:12]

12. 독립형 Mythos 스킬과 살아 있는 계획 아티팩트

• 이 스킬은 Mythos급 모델의 차세대 능력을 전제로 설계되며, 외부 의존성을 줄인 독립형 skill을 목표로 한다 [20:46]
• 하나의 skill 안에 이미지 생성, create workflow, plan update, 실제 엔지니어링 build, 이미지 생성 workflow를 함께 담아 계획 관련 작업을 포괄한다 [21:04]

13. 계획 템플릿의 기본 구조를 단순화하고 HTML 전환을 준비

• 초기 구조는 먼저 마크다운으로 작성한 뒤 Opus 4.8이 HTML 형식으로 전환하는 흐름을 전제로 한다. HTML 우선 구조는 사람, 팀, 에이전트가 같은 계획서를 읽고 활용하기 위한 기반이다 [24:02]
• 복잡도나 solution approach 같은 항목은 제거하고, 관련 파일은 기존 파일과 신규 파일로 나눈다. 변경 대상과 생성 대상을 분리해 계획의 실행 범위를 더 명확히 한다 [24:25]

14. phase별 실행 단위와 체크리스트를 살아 있는 스펙으로 구성

• phase 이름은 고정된 해결책을 과하게 지시하지 않도록 잡고, 각 phase 안에는 bullet checklist를 둔다. 작업 중 에이전트가 스펙을 계속 업데이트하는 living artifact 구조가 핵심이다 [25:10]
• step-by-step task와 testing strategy는 별도 상위 섹션으로 두지 않고 각 phase 내부에 넣는다. phase마다 실행 순서와 검증 전략이 함께 붙어 작업 단위별 완료 기준이 분명해진다 [25:41]

15. 검증 명령과 문제·해결 정의로 계획 산출물의 품질을 고정

• acceptance criteria는 제거하고, 각 phase 완료를 증명하는 validation commands를 최종 검증 수단으로 삼는다. phase별 testing task와 같은 명령을 재사용해 계획과 검증 사이의 중복을 줄인다 [27:24]
• 수백 번 이상 재사용할 스킬이기 때문에, 원하는 출력 형식을 앞단에서 선명하게 정의하는 데 시간을 투자한다. 빠른 코딩보다 에이전트가 반복적으로 같은 품질의 결과를 내는 구조가 더 중요하다 [27:50]

16. Git 기반 되돌림 지점과 에이전트 투입을 위한 초기 skill 정리

• raw 상태를 확인한 뒤 git init과 기본 커밋을 추가한다. 마음에 들지 않는 변경을 되돌릴 안전장치가 생기고, 이후 에이전트 작업의 기준점도 고정된다 [29:04]
• workflow는 요구사항 분석, 프롬프트 파싱, 코드베이스 탐색, 솔루션 설계, 계획 문서화, 파일 생성, 저장 흐름을 포함한다. 기존 report 개념은 제거하고 핵심 구성 요소를 제공하는 방향으로 바뀐다 [29:35]

17. HTML 우선 템플릿 전환과 에이전트 범위 제어

• 에이전트 작업은 plan template을 HTML 형식으로 재설계하고 instruction을 업데이트하는 방향에서 시작된다. Mythos급 모델에 맞는 더 효율적인 계획 산출물을 만들기 위한 업그레이드다 [30:55]
• 메타 planning skill은 낮은 등급 모델에서도 사용할 수 있지만, 핵심 효율은 최상위 Mythos급 모델에서 나온다. 이 구간의 구현은 단일 Claude Code 에이전트를 쓰는 기본적인 agentic coding 흐름으로 진행된다 [31:12]

18. metadata, questionable, 이미지 가이드, workflows로 계획서 확장

• metadata header는 collapsible details 항목으로 바뀌고, purpose·problem·solution에 더해 dedicated workflows가 추가된다. 워크플로는 에이전트가 실제로 어떻게 일해야 하는지를 규정하는 핵심 장치다 [33…] [33:39]
• questionable section은 notes 위에 추가되며, questionable 값이 true일 때만 나타나는 조건부 섹션으로 구성된다. 중복된 Q&A 섹션은 하나로 정리되고, 모델이 한 요청을 과도하게 확장하는 문제도 다시 확인된다 [33:54]

19. 워크플로 디렉터리로 다중 실행 경로를 분리

• 스킬 안에 workflows 디렉터리를 만들고, 사용자 프롬프트에 따라 어떤 워크플로를 호출할지와 어떤 파일을 읽을지를 표로 정리하는 구조가 출발점이 된다 [36:01]
• 계획 스킬은 이미지 생성, 계획 기반 빌드, 참조 갱신, 계획 수정, 계획 생성까지 다섯 가지 워크플로를 포함하며, 단일 스킬 안에서 여러 실행 경로를 빠르게 선택할 수 있다 [36:46]

20. 이미지 생성과 계획 컨텍스트를 별도 규칙으로 확장

• KISS는 구현을 핵심으로 단순화하라는 압축 지시어로 쓰이며, 이미지 생성 워크플로도 생성과 업데이트라는 두 경로로 나뉜다 [37:56]
• 이미지 생성의 create는 보통 계획 생성 중 실행되고, update는 명시적 요청이나 계획 변경이 있을 때 실행되는 조건부 경로로 압축된다 [38:23]

21. 계획을 반복 사용 가능한 살아 있는 아티팩트로 정리

• 계획 생성 워크플로에는 이미지 생성 단계와 조건부 질문 단계가 추가되며, 계획 작성 과정에서 시각 자료와 불확실성 처리까지 함께 다루는 흐름이 생긴다 [39:31]
• 계획 포맷은 수백 번, 수천 번 재사용될 핵심 구조로 다뤄지며, 전방 참조·역참조·커밋·수정일·이미지·할 일 목록이 하나의 계획 안에 축적된다 [39:45]

22. 계획 수정과 변경 이력을 별도 워크플로로 고정

• update plan 워크플로는 기존 계획을 수정하는 경로이며, 메타데이터 갱신, 외과적 변경, 변경 기록 반영이 핵심 규칙이 된다 [41:15]
• amend 섹션은 계획 실행 이후 발생한 변경 이력을 남기기 위한 영역으로 추가되며, 계획 수정과 참조 갱신 워크플로가 이 기록을 계속 누적한다 [41:31]

23. 빌드 실행 워크플로와 단계별 상태 관리

• build plan 워크플로는 실제 구현을 맡는 에이전트를 위한 경로이며, 사용자 프롬프트에 계획 경로가 있거나 추론 가능해야 하고 모든 이미지와 1단계 깊이의 역참조를 읽는다 [42:34]
• 빌드 에이전트는 새로운 컨텍스트 창을 가진 특화 에이전트라는 전제에서 무거운 컨텍스트를 받아들이며, “하나의 에이전트, 하나의 프롬프트, 하나의 목적” 전략을 따른다 [42:51]

24. 이미지 슬롯, 자유 작성 영역, 검증·IDE 실행까지 마무리

• 계획 스킬은 첫 버전부터 강력해야 하며, 계획 스킬은 메타 스킬이나 프롬프트 템플릿과 함께 에이전트 시스템에서 가장 중요한 축이 된다 [44:14]
• 이미지 슬롯은 문제, 해결책, phase별 영역, 조건부 질문, notes 영역에 배치되며, notes에서는 계획 에이전트가 필요한 세부 내용을 더 자유롭게 추가할 수 있다 [44:54]

25. 기존 HTTP 기반 에이전트 통신에서 Iron 기반 V1 실험으로 전환

• 파이 코딩 에이전트가 새 스킬을 읽는 가운데, 기존 agent-to-agent 통신은 간단한 HTTP 서버를 통해 다른 에이전트를 즉시 호출하는 구조로 드러난다 [48:07]
• Iron은 애플리케이션 사이에 직접 연결을 만드는 기술로, Tailscale처럼 네트워크 연결성을 제공하되 애플리케이션 내부에 내장되어 별도 서버 의존을 줄일 수 있는 방식이다 [48:42]

26. 새 계획 포맷으로 Iron 통신 계획을 Opus에서 생성

• 입력 프롬프트에는 Py versus Claude Code 확장, 수정 대상인 파이 코딩 에이전트 확장, 요구사항, 관련 문서가 함께 포함되며, 새 spec 포맷은 이를 바탕으로 계획을 만든다 [49:40]
• 실행 모델은 Fable 5가 아니라 Opus 4.8이며, Opus만으로도 목표 결과의 80~90% 수준에 도달할 수 있다는 전제에서 새 planning prompt를 검증한다 [49:55]

27. 계획 대상 코드베이스와 Iron 재구현 목표가 구체화

• 생성된 요구사항은 임시 디렉터리 사용, PyCroco 리서치, 공개 GitHub 코드베이스인 Py versus Claude Code 기반 분석을 포함한다 [51:00]
• 기존 코드베이스에는 PyCodingAgent 커스텀 확장들이 있고, 그중 HTTP 기반 통신 네트워크의 동작을 담은 확장이 Iron 재구현의 출발점이 된다 [51:15]

28. HTML과 이미지 토큰을 활용한 메타 플래닝의 비용과 이점

• 약 6분간의 리서치 뒤 완성된 HTML 계획이 만들어지며, HTML은 더 많은 유용 토큰을 제공해 에이전트가 목표에 가까운 산출물을 만들 가능성을 높인다 [52:02]
• HTML과 이미지 생성은 토큰과 시간이 더 들지만, 결과 품질을 우선한다면 처음부터 그 비용을 감수하는 설계로 접근한다 [52:19]

29. 병렬 이미지 생성과 브라우저 기반 HTML 계획 검토

• 에이전트는 8개 파일을 병렬로 생성하려 하며, 별도의 parallel 키워드가 없었음에도 이미지 생성 병목을 줄이기 위해 병렬 처리를 선택한 점이 모델의 판단 능력으로 드러난다 [54:10]
• 이미지 생성은 빠르게 끝나지만 품질 설정이 낮을 가능성이 있어, wide format과 high quality를 항상 사용하도록 추가 지시가 들어간다 [54:46]

30. 단계별 이미지·검증 매트릭스·템플릿화된 엔지니어링의 효과

• 새 해법은 중앙 허브를 Iron gossip swarm으로 대체하고, 단일 환경변수와 topic identity 중심 설정을 통해 peer-to-peer 통신 구조를 만들 가능성을 보여준다 [56:41]
• 구현 계획은 관련 HTML 파일과 새 파일, phase별 실행 순서, top-to-bottom 작업 흐름을 포함하며, 각 phase마다 이미지가 붙어 작업 의도를 빠르게 파악할 수 있게 한다 [57:04]

31. Plan F3 skill의 확장성과 차세대 모델 대비

• 새 Plan F3 skill은 Fable과 이후 세대 모델에서 더 강한 결과를 낼 수 있는 기반으로 제시되며, 링크를 통해 바로 사용할 수 있는 형태로 제공된다 [1:00:04]
• 프롬프트에는 여전히 개선 여지가 있고, 특히 동적 노드 기반 다이어그램을 위해 SVG 지원을 넣으면 이미지 생성보다 시간과 토큰 비용을 줄일 수 있다 [1:00:20]

32. 사고를 외주화하지 않는 에이전틱 엔지니어링 원칙

• 업계에는 손으로 직접 코딩하거나 깊이 생각하기보다 에이전트에 무의식적으로 프롬프트를 던지는 흐름이 늘고 있으며, 이런 방식은 시간이 갈수록 더 나쁜 결과로 이어질 수 있다 [1:00:38]
• Aider 같은 도구는 이미 손으로 치는 작업을 크게 줄였고, 기술 발전은 생산성을 높이는 동시에 실무자의 일부 역량을 약화시키는 자연스러운 변화를 만든다 [1:00:56]

🧾 결론

• 이 영상은 Fable 5 자체의 기능 소개라기보다, Fable 5와 Mythos급 모델을 전제로 계획 skill을 어떻게 재설계할지 보여주는 실전형 메타 엔지니어링 기록에 가깝다.
• 발표자의 핵심 문제의식은 “에이전트가 더 똑똑해질수록 사람이 덜 생각해도 된다”가 아니라, “에이전트가 더 똑똑해질수록 사람이 더 정교한 계획과 기준을 제공해야 한다”는 쪽에 있다.
• Plan F3는 계획 문서를 일회성 산출물이 아니라 코드베이스 안에서 계속 갱신되는 living artifact로 다루며, 생성일·수정 이력·커밋·참조·이미지·작업 상태 같은 정보를 누적하는 구조를 지향한다.
• HTML과 이미지 중심 계획서는 토큰과 시간이 더 들지만, 사람·팀·AI agent가 같은 문맥을 공유하게 만드는 장점이 있으며, 발표자는 이 비용을 성능 향상을 위한 의도적 투자로 본다.
• 검증 필요: 영상 안에서는 Plan F3가 더 강한 Mythos급 모델에서 더 큰 효과를 낼 가능성이 제시되지만, 실제 성능 향상 폭은 별도의 비교 실험, 반복 사용 결과, 모델별 산출물 품질 평가가 필요하다.

📈 투자·시사 포인트

• 시간·토큰·설계 노력의 투자 관점에서 보면, 반복적으로 쓰일 planning skill이나 agent harness는 초기에 더 많은 비용을 들여 템플릿과 검증 구조를 정교화할수록 장기 재사용 가치가 커진다.
• 에이전트 활용의 병목은 단순 코딩 속도보다 planning과 reviewing으로 이동하고 있으며, 좋은 계획 템플릿은 후속 리뷰 비용을 줄이고 실행 품질을 안정화하는 레버로 작동할 수 있다.
• 조직 관점에서는 개인만 이해하는 프롬프트보다 팀과 AI agent가 함께 읽을 수 있는 표준 계획 아티팩트가 중요해질 수 있으며, HTML·메타데이터·참조 구조는 협업과 추적성을 높이는 장치가 된다.
• 기술 선택 측면에서는 이미지 생성이 항상 최선은 아니며, 발표자도 후반부에서 SVG 같은 구조적 표현이 시간과 토큰 비용을 줄일 수 있는 대안이 될 수 있다고 언급한다.
• 검증 필요: Plan F3 방식이 실제 프로젝트에서 기존 마크다운 계획, 단순 체크리스트, 또는 일반 agent prompt보다 얼마나 더 나은 결과를 내는지는 프로젝트 규모·모델 성능·팀 운영 방식에 따라 달라질 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 검증 필요: 영상에서는 Fable 5와 Mythos class 모델이 planning ability를 크게 끌어올린다는 전제로 논의하지만, 실제 모델 성능·출시 상태·명칭 체계는 영상 내용만으로는 독립 확인되지 않는다.
• 검증 필요: Opus 4.8이 Fable 5·Mythos급 모델이 할 수 있는 일의 80~90% 수준을 보여준다는 평가는 발화자의 실험적 판단으로 보이며, 객관적 벤치마크나 반복 실험 결과는 별도로 제시되지 않았다.
• 검증 필요: Plan F3 skill이 링크를 통해 사용 가능하다고 언급되지만, 실제 배포 위치, 최신 버전, 설치 방법, 라이선스 조건은 section-detail만으로 확인할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복 사용할 planning skill은 agent에게 바로 맡기기 전에 먼저 raw.md처럼 목적, 문제, 독자, 출력 형식, 검증 기준을 글로 정리한다.
• 계획 템플릿을 engineer 개인, engineering team, AI agent가 모두 읽고 실행할 수 있는 구조로 설계한다.
• 각 phase마다 작업 체크리스트, 실행 순서, testing strategy, validation command를 함께 넣어 닫힌 검증 루프를 만든다.
• 계획 문서의 metadata에 생성일, 수정 이력, 관련 커밋, 세션 ID, agent name, back reference, forward reference를 관리한다.

❓ 열린 질문

• Plan F3 같은 HTML·이미지 기반 계획서가 실제 코드 품질, 리뷰 시간, 재작업률을 얼마나 개선하는지 어떻게 측정할 수 있을까?
• 모든 작업에 고비용 planning template을 적용해야 할까, 아니면 작업 복잡도에 따라 lightweight plan과 full plan을 나누는 기준이 필요할까?
• 이미지 생성이 계획 이해에 도움을 주는 경우와 오히려 유지보수 비용만 늘리는 경우를 어떻게 구분할 수 있을까?