오푸스4.8 Workflow vs 크라우니코드 오케스트레이션 — 비교·개선·Alt 1,2,3

개요

오푸스4.8에는 외부 JS를 작성해 컨텍스트를 저장하고 서브에이전트가 최적으로 사용하는 기능이 있다 (Workflow 도구). 현재 크라우니코드(agent.sh 5단 파이프라인 + 플랫파일 DB + ~/.claude/knowledge/ 다세션 메시)와 비교해 장단점을 정리하고, 두 시스템의 장점을 합친 단일 매니페스트 → 다중 런타임 백엔드 개선안을 정의한다. 클로드가 아니거나(타 LLM), 다른 사람의 클로드 계정이거나, LLM이 전혀 없는 경우를 위해 Alt 1·2·3 백엔드도 설계한다.

---

1. 오푸스4.8 Workflow 기능의 실체

Workflow 도구 = 결정적 멀티에이전트 오케스트레이션.

• agent(prompt, {schema}) — 서브에이전트 생성. schema 지정 시 구조화 출력이 도구 계층에서 검증되어 객체로 반환 (파싱 불필요)
• pipeline(items, stage1, stage2…) / parallel(thunks) — fan-out. stage 간 컨텍스트가 반환값으로 프로그래밍적 전달 (배리어 없는 파이프라인이 기본)
• 저널 + resumeFromRunId — 동일 prefix는 캐시 결과 즉시 반환, 편집된 지점부터 라이브 재실행 (정확한 재개)
• budget — 토큰 예산 인식 → 에이전트 수/깊이 동적 스케일
• 스크립트는 파일로 영속, 백그라운드 실행, 완료 시 알림

핵심 가치: 제어흐름이 모델 변덕이 아니라 JS 코드로 결정적, 컨텍스트 핸드오프가 schema로 보장, 자동 저널/재개, 토큰 예산.

---

2. 현재 크라우니코드 오케스트레이션의 실체

구성	내용
컨텍스트 저장	플랫파일 .dat(pipe구분: keywords 586KB, 학습 64K줄), SQLite gigafactory.db(909KB)
다세션 컨텍스트	~/.claude/knowledge/ (PLAN.md·LIVE_STATUS.md·sessions.json·plan.json·cells.json)
동기화	훅(PreToolUse heartbeat / Stop deregister) + LaunchAgent harvest 5분 주기
오케스트레이션	agent.sh 5단계(의도→검색→조립→검증→학습), run_multi로 "A 하고 B" 분해
에이전트간 전달	stdout 파이프 문자열 + 임시파일 /tmp/의미어_multi_$$.han
통합 브리지	claude-integration.sh (ask=규칙우선 / teach=학습 / status)

핵심 가치: 영속·다세션 공유(19+ 세션이 같은 파일 메시 공유), 플랫폼 독립(순수 POSIX bash, 클로드 없어도 동작), 한선씨 정합(규칙엔진·.한선).

---

3. 비교 — 장단점

축	크라우니코드 (현재)	오푸스4.8 Workflow	우위
컨텍스트 저장	플랫파일+SQLite+knowledge/ (영속)	runId 저널 (세션내)	크라우니 (영속성)
컨텍스트 전달	stdout 문자열/임시파일 (비정형)	schema 검증 객체 (정형)	Workflow
오케스트레이션	bash 루프 + 모델 판단 (비결정적)	JS 결정적 제어흐름	Workflow
재개/저널	없음 (수동 재실행)	resumeFromRunId 캐시 재생	Workflow
토큰 예산	인식 안 함	budget 동적 스케일	Workflow
병렬성	순차 위주	parallel/pipeline 동시(최대16)	Workflow
플랫폼 의존	없음 (영구·POSIX)	클로드 Opus 4.8 전용 (계정·과금 종속)	크라우니
한선씨 정합	정통 (.한선/규칙엔진)	외부 의존성 (JS)	크라우니
다세션 메시	19+ 세션 공유	단일 런 격리	크라우니
자립도(LLM 0%)	규칙엔진 직접매칭 가능	LLM 필수	크라우니

결론: 보완적. Workflow는 세션 내 결정적 오케스트레이션·구조화 핸드오프·저널 재개·예산에서 우월. 크라우니코드는 영속·다세션 공유·플랫폼 독립·한선씨 자립에서 우월. → 둘을 합친다.

---

4. 개선된 방법 — 단일 매니페스트(SSOT) → 다중 런타임 백엔드

워크플로우를 한 번만 선언형 매니페스트(.flow.json + .한선 동반)로 기술하고, 실행 환경에 따라 백엔드를 자동 선택한다. → Workflow의 장점(결정적 fan-out·구조화 핸드오프·저널·예산)을 도입하면서 플랫폼 독립·한선씨 정합 유지.

매니페스트가 표현하는 것

jsonc{
  "name": "...", "budget": 500000, "resume": "auto",
  "stages": [
    { "id": "find",   "intent": "버그 찾기", "schema": {...}, "phase": "Find" },
    { "id": "verify", "intent": "검증",     "schema": {...}, "after": "find", "mode": "parallel" }
  ]
}

stage = (id, intent, schema, agentType, phase) / edge = after + mode(pipeline|parallel) / budget·resume.

백엔드 4종

경로	환경	실행 방식	resume/저널/예산
Native	클로드 Opus 4.8 (본인 계정)	매니페스트 → Workflow JS 컴파일 → native Workflow 도구	플랫폼이 무료 제공
Alt 1	클로드지만 다른 사람 계정 / Workflow 미가용	매니페스트 → agent.sh/claude-integration.sh 오케스트레이터가 5단계로 순차/병렬 실행. schema는 stdout JSON으로 강제	우리가 ~/.crownycode/runs/<id>.jsonl에 기록
Alt 2	클로드 아님 (타 LLM: GPT/Gemini/로컬)	LLM-agnostic 어댑터. schema를 프롬프트에 명시 강제(structured-output 흉내)	우리 런너가 관리
Alt 3	LLM 전혀 없음 (순수 규칙엔진)	agent() 호출을 패턴DB 직접매칭 + 셀코어 규칙으로 치환. LLM 윤활유 0%	우리 런너가 관리

→ "외부 JS 의존"을 Native 경로에만 한정. 나머지는 한선씨/규칙으로 자립.

역수출 (크라우니 강점을 Native에도)

Native Workflow 실행 결과를 종료 시 harvest로 ~/.claude/knowledge/에 흡수 → 단일 런 격리를 깨고 다세션 메시에 합류. (Workflow의 약점인 영속·공유를 우리 강점으로 보강)

---

5. 관련 파일

• 매니페스트 스펙: ~/Downloads/CrownyTVM/crownycode-flow/manifest.schema.json
• 예제: ~/Downloads/CrownyTVM/crownycode-flow/example.flow.json
• 포터블 런너(디스패처): ~/Downloads/CrownyTVM/crownycode-flow/cc-flow
• 한선씨 동반(매니페스트 모델 + Alt3 규칙실행): ~/Downloads/CrownyTVM/crownycode-flow/흐름실행.한선
• Native JS 이미터: ~/Downloads/CrownyTVM/crownycode-flow/native-emit.sh
• 기존 통합 브리지: ~/Downloads/CrownyTVM/crownycode-agent/claude-integration.sh

6. 진행 현황 (2026-06-09 갱신)

항목	상태
Native 이미트 (한선씨)	✅ 기본 경로 흐름이미터.한선 — schema 직렬화+fanout/parallel+budget 완비. cc-flow가 구동, python판과 byte-identical 출력 (2개 매니페스트 검증)
Native 이미트 (py)	✅ 폴백 전용 (crowny 바이너리 미발견 시). done-convert 처리됨
Alt 1 (클로드 타계정)	✅ agent.sh 오케스트레이션 + 저널
Alt 2 (타 LLM)	✅ 실호출 + 준수율 튜닝 — OpenAI/Gemini/Anthropic 라우팅, 펜스/산문 제거+required 키 검증(extract_validate)+불일치 시 재시도(기본 2회, CC_FLOW_RETRY), 키 없으면 Alt3 폴백
Alt 3 (LLM 0%)	✅ 패턴DB 직접매칭, 2/2 stage 규칙매칭
환경 탐지	✅ native/alt1/alt2/alt3 자동
harvest 역수출	✅ 완료 — 모든 백엔드 종료 시 자동(harvest:true) → crowny-knowledge.sh add crownyflow/... 셀 메시 + FLOW_RUNS.md. Native는 cc-flow harvest <이름> < results.json으로 Workflow 반환값 흡수 → 단일런 격리 해소. Stop 훅에 cc-flow harvest-all(멱등) 연결 — 세션 종료 시 미역수출분 자동 흡수
resume 정규화	✅ 완료 — stage 콘텐츠 해시(sha1{id,intent,schema,after,mode,fanout}[:12])=캐시 키. 최장 불변 prefix 재사용, 첫 변경 stage부터 그 이후 전부 재실행(선행 입력 변경=후행 무효, Workflow resumeFromRunId와 동일 의미). --no-resume로 전체 강제 재실행. 검증: 무변경=전부 캐시 / verify만 변경=review 캐시·verify 재실행 / no-resume=전부 재실행

잔여 이슈

• 한선씨판 schema 직렬화 → 완료. native-emit.py 폴백 강등, done-convert
• Alt 2 모델별 JSON 준수율 튜닝 → 완료 (extract_validate 검증 + 재시도 + 프롬프트 강화)
• harvest 역수출 → 완료 (셀 메시 crownyflow/* + FLOW_RUNS.md, Native 결과 흡수 포함)
• cc-flow는 bash 글루(env탐지/curl/메시) — convert 대기열 유지. 핵심 로직(이미트·규칙실행)은 한선씨 자립
• 한선씨 JSON 파서 함정(맵 2종, \r) → 매니페스트 파싱은 python 마샬링 경유 (한선씨 직접 파싱은 차기)
• resume 키 정규화 규약 → 완료 (최장 불변 prefix 캐시, --no-resume)
• harvest Stop 훅 연결 → 완료 (~/.claude/settings.json Stop 체인에 cc-flow harvest-all 추가, 멱등)
• Native↔Alt 교차 재개 → 완료. 단일 저널 스키마 {stage,status,payload,key,backend} 통일, resume 포인터를 백엔드별→흐름별(<flow>.last.jsonl)로 변경, Native harvest가 매니페스트로 stage 키 부착. 어느 백엔드로 실행하든 직전 실행을 교차 재개. 검증: Native 결과 harvest → Alt3가 2/2 캐시 재사용
• 안정화: test.sh 회귀 15건 전부 PASS (격리 RUNS, 메시 부작용 차단). set -u 버그(동일 local 문 내 자기참조) 수정. JSON 포맷 compact 통일. CC_FLOW_RUNS 격리 변수 도입. README.md 추가