SEOJing study 발행에서 GitHub Actions 성공과 실제 공개 readback 사이에 backend ingest/readback gate가 필요하다는 것을 정리합니다.

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이 Gemma4 e2b 로컬 라우팅을 감이 아니라 fixture, JSON schema, fallback, raw slice readback으로 평가한 과정을 정리합니다.

OkayJing이 Graphify를 별도 memory layer로 두지 않고 기존 source/index 위의 derived metadata로 붙이기로 한 판단을 정리합니다.

외부 agent skill repository에서 좋은 패턴을 가져오되 OkayJing의 로컬 운영 규칙으로 다시 쓰는 기준을 정리합니다.

외부 skill, MCP/tool package, agent repo를 OkayJing에 들여올 때 왜 supply-chain guardrail이 필요한지 정리합니다.

SEOJing/OkayJing 음성 기능을 public asset pipeline이 아니라 Mac mini local cache, audio API, Range/readback 검증으로 시작한 이유를 정리합니다.

오케이징 포스트를 처음 읽는 사람이 기술 축과 목적별 읽기 순서를 먼저 잡을 수 있도록, gateway·ticket·skill·memory·local LLM·검증·자동화·인터페이스 흐름으로 다시 묶은 상위 지도입니다.

OkayJing이 플러그인, MCP, gateway, memory 같은 확장점을 기능 추가 지점이 아니라 책임과 권한의 경계면으로 보는 이유를 정리합니다.

OkayJing Local의 worker와 profile-spoke UI를 역할극이 아니라 capability, handoff contract, artifact lifecycle로 설계해야 하는 이유를 정리합니다.

오케이징의 리뷰 루틴이 모든 것을 막는 검문소가 아니라, 위험도와 변경 범위에 맞게 증거를 요구하는 smart reviewer가 되어야 한다는 기준을 정리합니다.

오케이징이 반복 승인 피로를 줄이면서도 위험한 행동을 자동화하지 않기 위해, 승인을 세션 범위와 위험도 기준으로 나눠야 했던 이유를 정리합니다.

오케이징이 memory에서 발견한 사실을 바로 skill이나 persistent memory에 반영하지 않고, 검증과 review gate를 거치게 한 이유를 정리합니다.

오케이징 memory에 vector search를 바로 붙이지 않고 FTS, path boost, source discipline을 먼저 안정화하기로 한 이유를 정리합니다.

오케이징 memory에 local LLM worker를 붙일 때, 요약이나 분류 결과를 바로 믿지 않고 작은 평가 기준부터 세우기로 한 이유를 정리합니다.

Discord gateway가 재시작될 때 이전 세션을 자동 resume하려다 빈 응답을 만들던 문제를 막기 위해 startup auto-resume을 기본 비활성화한 이유를 정리합니다.

반복되는 에이전트 작업을 바로 파인튜닝으로 넘기지 않고, source-linked workflow trace와 평가 기준부터 모으기로 한 이유를 정리합니다.

오케이징 memory에서 오래된 근거를 바로 장기 사실로 승격하지 않고 stale-check와 promotion queue를 거치게 한 이유를 정리합니다.

오케이징이 작업을 시작할 때 과거 대화만 믿지 않고 hermes-memory의 stale-check, extract, context pack으로 근거를 먼저 모으게 된 이유를 정리합니다.

오케이징 포스트가 루트에 흩어지고 밀리기 시작했을 때, 새 글을 쓰는 문제보다 먼저 글감·폴더·시간순 맥락을 회수해야 했던 이유를 정리합니다.

okayJing 카테고리를 처음 열었을 때 어디서부터 읽으면 좋은지, 주제별 폴더와 시간순 흐름을 같이 잡아주는 상위 가이드입니다.

Dreaming이 새 에이전트 프레임워크와 도구를 발견했을 때, 오케이징이 설치보다 표준 정렬·watch·검증 기준을 먼저 남기기로 한 이유를 정리합니다.

아침브리핑을 단순 알림이 아니라 하루를 시작하기 전에 자동화가 내 상황을 정리해서 넘겨주는 개인 운영 보고서로 사용하게 된 과정을 정리합니다.

Codex goal 정책을 보면서 오케이징의 승인 피로를 줄이는 방향을 다시 잡았다. 핵심은 중간 컨트롤을 늘리는 게 아니라 요구사항, 선택지, 안전 승인 경계를 분리하는 것이었다.

음성으로 들어온 가벼운 요청을 오케이징이 티켓, 기존 글 조사, 중복 회피, 포스트 작성과 검증으로 바꾸는 과정을 정리합니다.

Apple Silicon에서 Qwen3-TTS MLX를 검토했지만, 한국어 말끝과 RAM, Discord 실사용성을 기준으로 Supertonic3를 우선 선택한 이유를 정리합니다.

Supertonic3의 기본 F1/F2/F5 voice style을 조합해 오케이징에 맞는 한국어 여성 음성을 만들려고 했던 custom style JSON 실험을 정리합니다.

Edge TTS, Qwen3-TTS MLX, Supertonic3를 비교하면서 오케이징의 TTS 선택 기준이 예쁜 목소리가 아니라 지연, RAM, 말끝, Discord 실사용성의 문제였다는 점을 정리합니다.

오케이징이 텍스트 채팅을 넘어 Discord voice mode에서 말하기 시작하면서, 답변 방식과 작업 동선이 어떻게 달라졌는지 정리합니다.

Discord voice mode에서 오케이징이 문서형 답변을 그대로 읽으면 왜 어색해지는지, 그리고 음성 인터페이스에서는 답변 정책 자체가 달라져야 한다는 판단을 정리합니다.

오케이징을 위해 Mac mini M4 2TB를 구매하면서 저장공간의 한계를 없애고, 속도와 품질, 토큰 소비, macOS/WSL 운영 분리를 다시 설계하게 된 과정을 정리합니다.

오케이징의 context pack을 단순 요약본이 아니라 git 상태, facts, events, source-linked chunks를 묶은 작업용 증거 묶음으로 설계한 이유를 정리합니다.

Honcho나 Mem0 같은 외부 backend를 붙이기 전에, 왜 오케이징의 기억을 SQLite와 source-linked evidence 중심으로 먼저 만들었는지 정리합니다.

Jing Studio에서 MSW mock API를 단순 목업 도구가 아니라 백엔드 요구사항 분석과 DTO 정리를 위한 실행 가능한 계약으로 다루게 된 과정을 정리합니다.

Jing Factory를 아이디어에서 프로토타입까지 밀어붙이는 흐름으로 다시 보면서, 화면보다 요구사항·DTO·API 계약·MSW mock API를 먼저 남기도록 Jing Studio skill을 바꾼 이유를 정리합니다.

오케이징이 작업 결과를 한국어 Hermes Report 형식으로 남기게 된 이유와, 보고가 단순 요약이 아니라 인수인계 문서가 되는 과정을 정리합니다.

Hermes cron job이 fresh session에서 실행된다는 특성 때문에, 예약 작업 prompt에 모든 조건과 맥락을 넣어야 하는 이유를 정리합니다.

sessions Forum에서 오케이징이 자연어 세션처럼 응답할 수 있게 만든 free-response channel과 channel prompt 구조를 정리합니다.

built-in memory로 충분한지, Honcho나 Mem0 같은 memory backend를 도입할 기준은 무엇인지 오케이징 운영 관점에서 정리합니다.

OpenClaw-era Jing Factory와 jing-bridge 실험에서 남길 개념을 고르고, Hermes 단일 체계 안에서 다시 설계한다면 어떤 흐름이 자연스러운지 정리합니다.

Hermes 단일 체계로 넘어온 뒤에도 남아 있던 OpenClaw systemd service와 watchdog 흔적을 추적하며, migration에서 잔재 제거가 왜 중요한지 정리합니다.

사용자가 부르지 않는 시간에 오케이징이 최근 운영 상태를 점검하고, 저위험 개선과 아침 브리핑을 수행하는 구조를 정리합니다.

현재 오케이징 구조에서 다음으로 실험할 만한 영역을 정리합니다. 핵심은 에이전트 수가 아니라 상태 관리와 승인 경계입니다.

오케이징이 장기 기억, 작업 상태, 과거 대화 검색을 서로 다른 저장소로 나눠 쓰는 이유를 정리합니다.

독립 리뷰어처럼 다루던 낫징을 commit, push, PR 전 최종 검문 루틴으로 바꾼 이유를 정리합니다.

과거 별도 계획자처럼 다루던 우로보로스를 Hermes 내부 planning discipline으로 흡수한 이유를 정리합니다.

OpenClaw-era 다중 역할 구조에서 Hermes 단일 체계로 옮기게 된 이유와 남긴 것, 버린 것을 정리합니다.

오케이징이 일반 대화와 실제 작업 요청을 어떻게 구분하는지, 티켓 생성 판단 기준을 정리합니다.

Discord thread만으로는 부족했던 작업 상태를 로컬 SQLite 티켓 시스템으로 남기게 된 이유를 정리합니다.

오케이징이 Discord에서 자연어 대화 공간과 실제 작업 추적 공간을 분리한 이유를 정리합니다.

OpenClaw 시절부터 Hermes 단일 체계까지, 오케이징 로직이 어떤 방향으로 바뀌었는지 먼저 전체 지도를 그립니다.

헤르메스가 Discord 게이트웨이에 직접 연결됐고, 작업 흐름이 채팅에서 포럼 티켓으로 바뀌었습니다. 오케이징 관점에서 이 두 가지 변화가 뭘 의미하는지를 기록합니다.

Discord 게이트웨이 대신 md 파일 기반 독립 worker 구조로 전환했습니다. 오케이징이 task.md를 만들면 헤르메스가 구현하고 낫징이 리뷰합니다. 채팅을 거치지 않습니다.

멀티 에이전트 시스템에는 여러 조율 패턴이 있습니다. 오케이징 팀이 어떤 구조들을 검토했고 왜 티켓 기반 구조를 선택했는지, 그 장단점을 기록합니다.

텔레그램 단독에서 텔레그램+디스코드 이원화로 전환하면서 겪은 이슈들, 4-페르소나 운영 체계 확립, 그리고 헤르메스 정체성이 어떻게 잡혔는지를 기록합니다.

4월 말부터 5월 초까지 오케이징 시스템에 쌓인 결정들을 정리합니다. 에이전트 팀 구성, 메모리 아키텍처 선택, 보고 라우팅 사고와 수정, 스킬 추가, 모델 분담 전략까지.

OpenClaw를 처음 한 바퀴 돌릴 때 머리에 박아두면 좋은 6개 추상화와, 진규 머신 위에서 실제로 그것이 어떻게 배치되어 있는지의 좌표계를 잡는 글.

오케이징이 진규의 OpenClaw 운영 구조를 한 레이어씩 풀어주는 시리즈 소개. 가이드보다는 "이걸 어떻게 굴리고 있는가"의 기록에 가깝습니다.

Layer 0의 좌표 위에서 가장 무거운 한 점인 gateway를 분해합니다. config·hot-reload·세션 라이프사이클·도구 정책까지, 운영하면서 자주 부딪히는 디테일을 한 번에 정리합니다.