
Planner, reviewer, coder를 늘리지.
OkayJing이 역할극형 planner/reviewer/coder 분리보다 Hermes Hub와 project/profile spoke 격리를 택한 이유를 정리합니다.
agent 시스템을 만들다 보면 planner, reviewer, coder를 나누고 싶어진다. 화면상으로도 팀처럼 보이고, 설명도 쉽다. 그런데 OkayJing에는 그 방식이 잘 맞지 않았다.
개인 AI 운영체계에 필요한 것은 여러 인격의 회의보다, 사용자-facing Hub와 격리된 task-world다. 누가 무슨 성격인지보다, 어떤 profile이 어떤 문맥과 권한을 갖고 어떤 artifact를 남기는지가 더 중요하다.
default profile은 개인 운영체계의 Hub다. 사용자와 대화하고, 최종 결정을 내리고, ticket/result ledger를 소유한다. 다른 profile에서 나온 결과를 흡수할지, archive할지, discard할지도 Hub가 판단한다.
stable spoke는 blog-project, ops-workspace처럼 프로젝트나 작업 세계의
문맥을 가진다. disposable spoke는 작업 단위 격리 실행에 가깝고, 기본
disposition은 archive나 discard다.
Hub가 가져올 것은 contract, artifact, verification, final result, reusable rule이다. 가져오지 말아야 할 것은 전체 worker transcript, 일회성 중간 context, self-report뿐인 결과다.
이 구조는 덜 화려하다. 대신 Hub가 덜 더러워진다. 실패한 실험은 버릴 수 있고, 성공한 작업도 필요한 근거와 규칙만 회수할 수 있다.
개인 AI 운영체계를 만들 때 planner, reviewer, coder 같은 이름을 붙이는 건 쉽다. 하지만 이름이 늘어난다고 격리가 생기지는 않는다. 같은 memory, 같은 작업 폴더, 같은 권한을 공유하면 결국 한 agent가 여러 가면을 쓰는 것과 크게 다르지 않다.
먼저 나눌 것은 인격이 아니라 작업 세계다. 장기 기억과 최종 판단을 맡는 hub를 두고, 실험이나 프로젝트 작업은 spoke profile이나 별도 workspace에서 처리한다. spoke가 실패하면 버리고, 성공하면 결과·근거·재사용 규칙만 hub로 회수한다. 이 구조가 작게 시작하기 좋다.
Post Q&A
Planner, reviewer, coder를 늘리지 않기로 했다 — Hermes-only hub-spoke 원칙 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!

OkayJing이 역할극형 planner/reviewer/coder 분리보다 Hermes Hub와 project/profile spoke 격리를 택한 이유를 정리합니다.

큰 모델 호출 전에 로컬 모델이 무엇을 해도 되고 무엇을 하면 안 되는지, OkayJing의 local evidence router 기준을 정리합니다.

OkayJing Local을 단순 ops dashboard가 아니라 desktop, tablet, mobile에서 실제 대화와 작업을 대체하는 표면으로 평가하는 기준을 정리합니다.
OkayJing 서식지가 ticket list 중심 UI를 넘어 worker, session, artifact, verification이 연결된 Pixel Office로 가야 하는 이유를 정리합니다.

DB, Markdown, ticket 같은 원천 리소스 동시성은 API가 맡고, chat/voice/approval은 Hermes gateway 의미를 따라야 한다는 경계를 정리합니다.
OkayJing이 플러그인, MCP, gateway, memory 같은 확장점을 기능 추가 지점이 아니라 책임과 권한의 경계면으로 보는 이유를 정리합니다.
OkayJing Local의 worker와 profile-spoke UI를 역할극이 아니라 capability, handoff contract, artifact lifecycle로 설계해야 하는 이유를 정리합니다.
Dreaming이 새 에이전트 프레임워크와 도구를 발견했을 때, 오케이징이 설치보다 표준 정렬·watch·검증 기준을 먼저 남기기로 한 이유를 정리합니다.
Jing Factory를 아이디어에서 프로토타입까지 밀어붙이는 흐름으로 다시 보면서, 화면보다 요구사항·DTO·API 계약·MSW mock API를 먼저 남기도록 Jing Studio skill을 바꾼 이유를 정리합니다.
OpenClaw-era Jing Factory와 jing-bridge 실험에서 남길 개념을 고르고, Hermes 단일 체계 안에서 다시 설계한다면 어떤 흐름이 자연스러운지 정리합니다.