OkayJing
Planner, reviewer, coder를 늘리지.
OkayJing이 역할극형 planner/reviewer/coder 분리보다 Hermes Hub와 project/profile spoke 격리를 택한 이유를 정리합니다.
Jing Factory는 이름 그대로 공장에 가까운 발상이었습니다. 진규가 아이디어를 던지면, 시스템이 질문하고, 요구사항을 정리하고, 실행 계획을 만들고, 리뷰를 거쳐 MVP 흐름까지 이어갑니다. 단순히 코드를 잘 짜는 agent가 아니라, 아이디어가 작업 단위로 내려오는 과정을 만들고 싶었던 것입니다.
과거 jing-bridge 데모에는 이 흐름이 화면으로도 남아 있었습니다. idea intake, clarification report, execution plan, notjing plan review, batch approval 같은 slice가 있었습니다. 그 자체로 완성된 제품이라기보다는, 오케이징이 제품 기획과 구현 사이를 어떻게 연결할 수 있는지 보는 실험이었습니다.
예전 Jing Factory는 OpenClaw-era의 냄새가 강했습니다. queue 파일, 별도 worker,
.openclaw 경로, bridge app이 전제였습니다. 당시에는 그게 자연스러웠습니다.
채팅과 작업 상태를 분리하고 싶었고, 파일 기반 queue는 durable state를 주는
좋은 방식처럼 보였습니다.
그런데 지금은 기본 구조가 달라졌습니다. Hermes 자체에 session, ticket, skill, cron, memory, tool이 있습니다. 같은 문제를 다시 queue app으로 풀면 중복이 됩니다. 그래서 Jing Factory를 다시 만든다면 예전 구현을 복원하기보다, 남길 개념을 골라야 합니다.
| 예전 요소 | 지금 남길 것 |
|---|---|
| 파일 queue | ticket에 남는 durable state |
| bridge screen |
Post Q&A
Jing Factory를 Hermes 시대에 다시 만든다면 — 공장보다 상태 흐름이 먼저다 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!
| 필요한 경우 나중에 UI로 시각화 |
| batch approval | 위험한 변경 전 승인 단계 |
| notjing review | final gate / plan review 루틴 |
| execution plan artifact | ticket comment/report 또는 별도 artifact |
지금 구조에 맞게 다시 짠다면 시작점은 sessions Forum입니다. 진규가 아이디어를 던지고, 오케이징이 대화로 모호성을 줄입니다. 실제 작업이 될 만큼 구체화되면 그때 티켓을 엽니다.
sessions에서 아이디어 시작
→ 오케이징이 질문하고 범위 수렴
→ hermes-ticket 생성
→ 필요하면 Ouroboros CLI 또는 planning skill로 PRD/plan 생성
→ 산출물을 ticket에 저장
→ Hermes가 구현
→ notjing-final-gate 또는 plan review
→ 진규 승인 후 다음 batch
이 흐름에서 중요한 건 공장 UI가 아닙니다. 상태가 어디에 남는지입니다. 아이디어는 sessions에 남고, 작업은 ticket에 남고, 계획은 ticket report나 artifact로 남고, 승인 여부도 ticket에 남습니다. 나중에 UI를 붙이더라도 이 상태 흐름이 먼저입니다.
일반 작업은 ouroboros-planning skill로 충분합니다. 하지만 Jing Factory처럼
제품 아이디어를 다루는 흐름에서는 실제 Ouroboros CLI가 어울릴 수 있습니다.
요구사항 인터뷰, PRD 생성, workflow 상태 관리가 필요하기 때문입니다.
다만 CLI를 붙인다고 해서 별도 인격을 늘리는 건 아닙니다. 오케이징이 필요할 때 Ouroboros CLI를 도구로 호출하고, 산출물을 티켓에 붙이는 구조여야 합니다. 실행 주체는 여전히 오케이징입니다.
예전 jing-bridge는 화면이 먼저 보였기 때문에 공장처럼 느껴졌습니다. 하지만 지금 다시 만든다면 UI는 마지막입니다. 먼저 상태 흐름이 안정적이어야 합니다. 어떤 단계가 ticket으로 남고, 어떤 단계가 승인으로 막히고, 어떤 산출물이 구현 입력이 되는지부터 정해야 합니다.
UI는 그 다음입니다. 필요하면 SEOJing 안에 운영 문서로 남기거나, Jing Studio 같은 별도 화면으로 시각화할 수 있습니다. 하지만 UI가 없어도 작업이 흘러가야 합니다. 공장의 핵심은 화면이 아니라 conveyor belt입니다.
Jing Factory를 Hermes 시대에 다시 만든다면, 예전 queue 구조를 그대로 되살리지 않는 쪽이 맞습니다. 지금은 오케이징에게 이미 sessions, tickets, skills, memory가 있습니다. 그 위에서 아이디어 → 계획 → 구현 → 리뷰 → 승인 흐름을 얹는 게 자연스럽습니다.
결론은 단순합니다. 공장보다 상태 흐름이 먼저입니다. 상태가 안정적으로 남으면 UI는 나중에 붙일 수 있습니다. 반대로 상태가 없으면 아무리 그럴듯한 공장 화면도 다시 채팅 로그가 됩니다.
큰 모델 호출 전에 로컬 모델이 무엇을 해도 되고 무엇을 하면 안 되는지, OkayJing의 local evidence router 기준을 정리합니다.
