지금 오케이징은 꽤 많이 정리됐습니다. OpenClaw-era의 다중 역할 구조에서 Hermes
단일 체계로 넘어왔고, sessions와 tickets를 나눴고, hermes-ticket으로 작업
상태를 남기기 시작했습니다. 우로보로스와 낫징은 각각 planning skill과 final
gate로 재정의됐습니다. 새벽 dreaming과 아침 briefing 루프도 생겼습니다.
여기까지 오면 다음 질문은 자연스럽습니다. 그다음은 무엇인가. 다시 agent를 늘릴 것인가, 아니면 지금 구조의 상태 관리와 승인 경계를 더 정교하게 만들 것인가. 현재 답은 후자에 가깝습니다.
첫 번째 후보는 실제 ouroboros CLI를 다시 연결하는 것입니다. 지금은
ouroboros-planning skill로 대부분 충분하지만, 제품 기획이나 대형 구조
변경에서는 별도 workflow가 유리할 수 있습니다.
sessions에서 아이디어 시작
→ hermes-ticket 생성
→ ouroboros pm/init로 요구사항 수렴
→ 산출물을 ticket에 저장
→ Hermes 구현
→ notjing-final-gate
다만 이건 작은 작업에 쓰면 오버헤드입니다. 기준을 정해야 합니다. 하루 이상 걸리는 작업, 여러 repo에 걸친 작업, PRD가 필요한 작업, 승인 단계가 필요한 제품 기획 정도가 적당한 후보입니다.
두 번째 후보는 memory backend입니다. 예전에는 mem0 같은 semantic memory가 오버엔지니어링에 가까웠습니다. 당시 문제는 기억이 부족한 게 아니라, 어디에 무엇을 남길지의 규율이 부족한 쪽이었습니다.
그런데 세션이 늘어나고, 진규의 말투나 장기 선호를 더 잘 반영하려면 Honcho나 다른 memory backend를 다시 검토할 수 있습니다. 중요한 건 바로 도입하는 게 아니라 도입 기준을 세우는 것입니다.
| 질문 | 기준 |
|---|---|
| built-in memory로 충분한가 | 자주 압축/삭제해야 한다면 부족 |
| session_search로 해결 가능한가 | 과거 대화 회수면 충분 |
| 개인화가 필요한가 | 말투/관계/장기 패턴이면 backend 후보 |
| 위험은 무엇인가 | 잘못 저장된 기억이 모든 세션에 영향을 줌 |
지금도 local ticket과 Discord thread를 연결할 수 있지만, 더 좋아질 여지가 있습니다. 예를 들어 thread에서 바로 ticket context를 안정적으로 회수하거나, ticket status와 Discord tag가 더 정확히 맞물리게 하는 식입니다.
이 영역은 오케이징의 체감 안정성에 직접 영향을 줍니다. 멋있는 새 agent보다, "이 thread가 어떤 ticket인지 항상 정확히 아는 것"이 실제로는 더 중요합니다.
과거 Jing Factory와 jing-bridge 실험도 다시 볼 만합니다. 아이디어를 받아서 질문하고, 실행 계획을 만들고, 리뷰하고, batch approval을 거쳐 MVP로 연결하는 흐름은 여전히 매력적입니다. 다만 OpenClaw-era queue 구조를 그대로 되살릴 필요는 없습니다.
Hermes 시대에는 sessions에서 아이디어를 시작하고, 필요할 때 ticket을 만들고, 큰 기획은 Ouroboros CLI로 수렴하고, 산출물은 ticket에 저장하는 쪽이 더 자연스럽습니다. UI가 필요하면 그때 Jing Studio나 별도 화면을 붙이면 됩니다. 먼저 필요한 건 공장이 아니라 상태 흐름입니다.
오케이징 vNext의 방향은 화려한 다중 agent 팀이 아닙니다. 더 정확한 상태 관리, 더 분명한 승인 경계, 더 좋은 복구 루틴입니다. 에이전트가 많아지는 것은 필요할 때만 의미가 있습니다. 그렇지 않으면 운영 비용만 늘어납니다.
지금 오케이징이 가져가야 할 기준은 이렇습니다. 대화는 가볍게 유지하고, 작업은 티켓으로 남기고, 절차는 skill로 고정하고, 위험한 변경은 final gate로 막습니다. 그리고 반복되는 개선은 dreaming으로 천천히 돌립니다. 이 기준이 흔들리지 않으면, 다음 구조도 크게 벗어나지 않을 것입니다.