🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Autonomous Cross-Agent Workflow의 핵심은 Claude가 만들고 Hermes/GPT-5.5가 감사한 뒤 Claude가 다시 검증하는 반복 구조로, 새 agent wiki 생성의 품질 리스크를 줄이는 것이다.

📌 핵심 요점

1. 이 워크플로는 한 에이전트가 생성한 결과를 다른 에이전트·모델이 감사하고, 원래 에이전트가 그 감사 결과를 다시 확인하는 교차 검증 구조다.
2. 대상 작업은 agentwikis.com의 새 위키 생성이며, 초기 seed 데이터와 구조가 흔들리면 이후 유지보수 비용이 커지기 때문에 생성 단계부터 반복 검증이 중요하다.
3. Claude Code는 주제별 새 위키의 스캐폴딩, 소스 수집, 검증, 위키 생성, 설정 등록을 수행하고, 작업 완료 시 파일 상단의 finished 표시로 다음 단계를 연다.
4. 5분 cron과 wake gate는 finished 조건이 충족될 때만 Hermes 감사를 실행해 불필요한 호출을 줄이고, 이후 Claude /p가 감사 항목을 다시 검증한다.
5. 실제 사례에서는 Hermes 감사 항목 중 다수가 Claude 재검증에서 false positive로 분류됐고, 확인된 실제 문제는 size discipline 관련 항목 하나로 좁혀졌다.

🧩 배경과 문제 정의

• 이 영상은 한 에이전트가 만든 결과물을 다른 에이전트나 모델이 감사하고, 다시 원래 에이전트가 감사 내용을 검증하는 교차 검증 워크플로를 다룬다.
• 단일 멀티 에이전트 하네스 안에서만 처리하는 방식과 달리, Claude Code, Codex, Hermes Agent처럼 서로 다른 실행 환경을 오가면 작업 상태 전달, 트리거, 산출물 확인 방식이 더 복잡해진다.
• 적용 사례는 agentwikis.com의 새 agent wiki 생성 파이프라인이다. 새 위키 생성은 기존 위키 유지·보수나 갭 채우기와 달리 초기 데이터, 구조, 기준 자료의 품질이 이후 전체 품질에 큰 영향을 준다.
• 핵심 문제는 Claude가 초안을 생성하고, Hermes/GPT-5.5가 감사하며, Claude가 다시 재검증·수정하고, 사람이 최종 확인한 뒤 GitHub와 VPS까지 동기화하는 과정을 야간 자동화 흐름으로 안정적으로 연결하는 것이다.
• 제공된 section-detail 기준으로는 최종 공개 적용 이후의 추가 결론이나 후속 운영 결과는 별도 검증이 필요하다.

🕒 시간순 섹션별 상세정리

1. 교차 에이전트 감사 워크플로의 필요성

• 영상은 한 에이전트가 먼저 작업을 수행하고, 다른 에이전트가 그 결과를 감사 보고서로 점검한 뒤, 다시 원래 에이전트가 감사 내용을 확인하는 구조를 출발점으로 삼는다 [00:01]
• Claude Code, Codex, Hermes Agent를 오가는 방식은 실제 작업에서 자주 필요한 흐름이지만, 각 에이전트의 실행 환경과 상태 전달 방식이 달라 단순한 내부 멀티 에이전트 구성보다 구현 난도가 높다 [00:17]

2. 새 agent wiki 생성 파이프라인의 작업 성격

• 이번 자동화의 대상은 agentwikis.com에 새로운 agent wiki를 만드는 파이프라인이며, 이미 존재하는 위키를 업데이트하거나 누락된 내용을 보강하는 작업과는 요구사항이 다르다 [01:31]
• 새 위키 생성은 초기 기반 자료와 구조가 흔들리면 뒤의 품질 관리 비용이 커지기 때문에, 단순 생성보다 탄탄한 시작점과 반복 검증 체계를 갖추는 것이 중요하다 [01:52]

3. 주제 선정과 입력 파일 준비

• 새 위키의 주제는 검색 트래픽 리포트, 주간 요약, Team Garage 멤버 요청, 온라인 관심 흐름을 함께 참고해 선정된다 [03:33]
• 일일 리포트에는 어떤 위키가 많이 검색되는지와 트래픽 흐름이 담기며, Hermes, Hyperframes, Llama CPP처럼 반복적으로 관심을 받는 항목이 새 위키 수요 판단의 근거가 된다 [03:47]

4. Claude Code의 새 위키 생성 작업

• Claude Code 안의 new_wiki.py는 agent wiki의 seed 정보와 seed 데이터를 스캐폴딩하고 생성하는 핵심 스크립트로 묶인다 [05:20]
• 스크립트와 관련 파일에는 필요한 크기, 사용할 소스, 소스 검색 방식, ingest 대상, 위키 생성 방식이 포함되어 있어 별도 추가 프롬프트 없이 실행될 수 있는 구조다 [05:36]

5. finished gate와 Hermes 감사 트리거

• Claude의 생성 작업이 끝나면 텍스트 파일 맨 위에 finished가 기록되고, 이 표시가 이후 자동 감사 흐름을 여는 게이트 역할을 한다 [07:05]
• pre-run 스크립트는 특정 파일의 첫 줄이 정확히 finished인지 확인하고, 조건이 맞지 않으면 아무 일도 하지 않으며, 조건이 맞으면 wake agent를 통해 Hermes가 review.md 지침에 따라 감사에 들어간다 [07:18]

6. 5분 cron과 Claude P 최종 재검증

• cron job은 5분마다 실행되지만, finished 조건이 충족될 때만 실제 agent를 호출하므로 토큰 낭비 없이 자주 상태를 감시할 수 있다 [09:30]
• Claude build 단계가 가장 오래 걸리기 때문에 보통 overnight로 돌리고, 완료 후 파일 상단에 finished가 쓰이면 이미 설정된 cron이 Hermes 리뷰를 이어받는다 [09:47]

7. 크론 wake gate와 Hermes 감사 산출물 확인

• Claude 작업이 아직 진행 중일 때 cron 작업은 실패로 처리되지 않고 wake gate에서 스킵되며, 중복 실행 없이 기다리는 흐름이 정상 작동한다 [12:18]
• 몇 시간 뒤 원래 topics 폴더의 상단 파일이 finished 상태로 바뀌고, 이 변경이 cron 작업을 트리거해 Hermes 감사까지 완료된다 [12:38]

8. Claude 재검증과 false positive 분리

• Codex/Hermes의 감사 결과는 다시 Claude P로 넘어가며, 원래 실행의 마지막 단계에서 Claude가 감사 내용을 한 번 더 확인하는 재검증 보고서를 만든다 [13:50]
• foundational wiki는 정확한 기준 자료가 되어야 하므로, Opus 4.8이 초안을 만들고 Hermes의 GPT-5.5가 감사한 뒤 Claude가 다시 확인하는 다중 모델 검증 흐름이 필요하다고 드러난다 [14:21]

9. 실행 로그 검증과 위키 산출물의 실제 활용성

• Claude Code의 깊은 로그 확인에서는 전체 root loop가 정상 실행됐고, Claude 초안 작성, GPT-5.5 감사, Claude P reconciliation이 독립적인 증거 체인으로 맞물린 것으로 압축된다 [16:08]
• 지난주 다른 위키 감사에서는 실제 오류도 발견됐기 때문에, 이번 사례처럼 항상 깨끗하게 끝나는 것은 아니며 경우에 따라 제대로 된 수정 작업이 필요하다는 점이 중요하다 [16:37]

10. 수동 검수 이후 GitHub·VPS 동기화와 공개 적용

• 수동 검수 단계에서는 이상한 표현이나 명백한 오류, 가격·정책처럼 자주 바뀌는 항목을 확인하고, 통과한 뒤 private GitHub repo로 push한다 [17:46]
• VPS의 Admiral 에이전트는 결과를 pull하고 15분 타이머로 deploy/sync 스크립트를 실행하며, registry의 active wiki list를 기준으로 누락 위키 clone, 기존 위키 fast-forward pull, 변경 시 서비스 재시작을 처리한다 [18:20]
• 제공된 section-detail 기준으로 확인 가능한 마지막 마무리 논지는 수동 검수 이후 GitHub와 VPS를 거쳐 공개 환경에 반영되는 동기화 흐름이며, 18:20 이후의 추가 결론이나 발언은 입력 자료만으로는 검증이 필요하다 [18:35]

11. 자동 동기화의 무코딩 구조와 공개 사이트 확인

• 배포는 repos와 registry를 넘기면 서버가 다음 tick에서 스스로 reconcile하는 구조이며, 손수 코딩하거나 hard-coded list를 유지하지 않는다고 정리된다 [18:54]
• healthz 성격의 상태 확인 명령으로 live wiki status를 보고, 필요한 위키가 모두 반영됐는지 확인할 수 있다 [19:02]
• 새 위키들은 이후 agentwikis.com에서 에이전트와 사람이 모두 읽을 수 있는 상태가 된다 [19:08]
• 수동 검수와 VPS 반영을 마친 뒤 실제 agentwikis.com에서 Ollama, Hugging Face, Stable Diffusion 항목이 보이는지 확인한다 [19:30]

12. 위키 앱을 넘어선 일반적 멀티에이전트 감사 워크플로우

• 발표자는 이 과정을 자신의 wikis 앱에 쓰고 있지만, 다른 많은 작업에도 유용할 수 있는 패턴이라고 본다 [19:42]
• 한 에이전트가 작업을 수행하고, 다른 모델을 쓰는 별도 에이전트가 audit·review를 맡아 실수를 점검하는 흐름이 핵심이다 [19:51]
• 이후 원래 에이전트나 모델이 감사 결과를 reconcile하고, auditor가 찾은 사항이 맞는지 다시 검증하는 구조로 마무리된다 [20:01]
• 이런 multi-agent agentic workflow가 유용하길 바란다고 정리하며, 더 효율적인 방식에 대한 의견과 좋아요·구독을 요청하고 영상을 끝낸다 [20:24]

🧾 결론

• 영상의 핵심은 “여러 에이전트를 많이 쓰는 것”이 아니라, 생성·감사·재검증의 책임을 서로 다른 실행 환경과 모델에 나누는 데 있다.
• Claude Code는 무거운 생성 작업을 맡고, Hermes/GPT-5.5는 독립 감사자 역할을 하며, Claude /p는 감사 결과를 그대로 믿지 않고 다시 사실 확인하는 단계로 쓰인다.
• finished gate, 5분 cron, wake agent, review.md 지침, Claude /p handoff가 결합되면서 overnight 자동 실행에 가까운 흐름이 만들어진다.
• 다만 자동화만으로 끝내지 않고, 공개 전에는 사람이 위키 본문과 개념, 가격·정책처럼 변동 가능성이 큰 항목을 직접 검수한다.
• 이 사례에서 확인된 중요한 교훈은 감사 결과도 오류를 낼 수 있으므로, 감사 자체를 다시 검증하는 reconciliation 단계가 필요하다는 점이다.

📈 투자·시사 포인트

• 에이전트 기반 콘텐츠·지식베이스 제작에 리소스를 투입할 때는 생성 모델의 성능만이 아니라, 감사와 재검증을 포함한 전체 운영 루프 설계가 중요하다.
• 새 위키처럼 초기 품질이 이후 유지보수 비용에 큰 영향을 주는 작업은 “초안 생성 자동화”보다 “초안 생성 후 검증 체계”가 더 큰 병목이 될 수 있다.
• cron, gate, non-interactive 실행, 명확한 review 지침처럼 단순한 운영 장치만으로도 여러 에이전트 간 자동 handoff를 구성할 수 있다는 점이 실무적으로 의미 있다.
• 감사 모델의 발견 사항을 자동으로 수정하지 않고 false positive를 분리한 점은, 자동화된 리뷰 시스템을 도입할 때 과잉 수정 리스크를 줄이는 방식으로 참고할 만하다.
• 검증 필요: 영상에서 언급된 Opus 4.8의 상대적 성능 판단, Claude /p 정책과 구독 플랜 사용량 조건은 업로드 시점 기준 설명이므로 실제 적용 전 최신 정책 확인이 필요하다.

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

• Claude Code의 Opus 4.8이 2026년 6월 23일 기준 “공개적으로 접근 가능한 모델 중 전반적으로 가장 강하다”는 평가는 발표자의 판단으로 제시되며, 별도 벤치마크나 외부 검증은 필요하다.
• finished 첫 줄 게이트, 5분 cron, Hermes wake agent, Claude 재검증까지의 흐름은 영상 속 사례에서 정상 작동한 것으로 설명되지만, 다른 주제·긴 작업·부분 실패 상황에서도 중복 실행이나 누락 없이 동작하는지는 추가 검증이 필요하다.
• Hermes/GPT-5.5 감사와 Claude 재검증이 실제 오류를 얼마나 안정적으로 잡아내는지, false positive와 missed issue 비율은 영상만으로 판단하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 새 위키 생성 파이프라인에 finished 게이트, 중복 실행 방지, 실패 재시도 조건을 명확히 문서화한다.
• Hermes 감사 보고서와 Claude reconciliation 보고서를 비교해 실제 오류, false positive, 미해결 항목을 분류하는 체크리스트를 만든다.
• 수동 검수 단계에서 가격·정책·빠르게 변하는 정보, 이상한 표현, 명백한 사실 오류를 우선 확인한다.
• cron 기반 자동 실행 로그에서 “스킵됨”, “Hermes 감사 완료”, “Claude 재검증 완료”, “VPS 동기화 완료” 상태를 추적할 수 있게 한다.

❓ 열린 질문

• 자동 감사 결과를 Claude가 다시 검증할 때, 어떤 기준으로 “수정 필요”, “false positive”, “무시 가능”을 나누는가?
• finished 파일 게이트 방식이 작업 실패, 부분 완료, 재실행 필요 상황을 충분히 표현할 수 있는가?
• 새 위키 생성 외에 기존 위키 유지·업데이트·갭 채우기에는 같은 교차 에이전트 구조를 얼마나 재사용할 수 있는가?