diff --git a/apps/web/content/okayJing/architecture/jing-factory-hermes-redesign.mdx b/apps/web/content/okayJing/architecture/jing-factory-hermes-redesign.mdx new file mode 100644 index 0000000..6e07511 --- /dev/null +++ b/apps/web/content/okayJing/architecture/jing-factory-hermes-redesign.mdx @@ -0,0 +1,133 @@ +--- +title: "Jing Factory를 Hermes 시대에 다시 만든다면 — 공장보다 상태 흐름이 먼저다" +date: 2026-05-24 +tags: + - okayJing + - JingFactory + - Hermes + - Ouroboros + - workflow +description: OpenClaw-era Jing Factory와 jing-bridge 실험에서 남길 개념을 고르고, Hermes 단일 체계 안에서 다시 설계한다면 어떤 흐름이 자연스러운지 정리합니다. +--- + + + 0. Jing Factory는 아이디어를 제품으로 바꾸려던 실험이었다 + + + + Jing Factory는 이름 그대로 공장에 가까운 발상이었습니다. 진규가 아이디어를 + 던지면, 시스템이 질문하고, 요구사항을 정리하고, 실행 계획을 만들고, 리뷰를 + 거쳐 MVP 흐름까지 이어갑니다. 단순히 코드를 잘 짜는 agent가 아니라, 아이디어가 + 작업 단위로 내려오는 과정을 만들고 싶었던 것입니다. + + + + 과거 jing-bridge 데모에는 이 흐름이 화면으로도 남아 있었습니다. idea intake, + clarification report, execution plan, notjing plan review, batch approval 같은 + slice가 있었습니다. 그 자체로 완성된 제품이라기보다는, 오케이징이 제품 기획과 + 구현 사이를 어떻게 연결할 수 있는지 보는 실험이었습니다. + + +--- + +1. 예전 구조를 그대로 되살리면 안 되는 이유 + + + 예전 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 | 필요한 경우 나중에 UI로 시각화 | +| batch approval | 위험한 변경 전 승인 단계 | +| notjing review | final gate / plan review 루틴 | +| execution plan artifact | ticket comment/report 또는 별도 artifact | + +--- + +2. Hermes 시대의 기본 흐름 + + + 지금 구조에 맞게 다시 짠다면 시작점은 sessions Forum입니다. 진규가 아이디어를 + 던지고, 오케이징이 대화로 모호성을 줄입니다. 실제 작업이 될 만큼 구체화되면 + 그때 티켓을 엽니다. + + +```text +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를 붙이더라도 이 상태 + 흐름이 먼저입니다. + + +--- + +3. 실제 Ouroboros CLI는 여기에 붙는 게 자연스럽다 + + + 일반 작업은 `ouroboros-planning` skill로 충분합니다. 하지만 Jing Factory처럼 + 제품 아이디어를 다루는 흐름에서는 실제 Ouroboros CLI가 어울릴 수 있습니다. + 요구사항 인터뷰, PRD 생성, workflow 상태 관리가 필요하기 때문입니다. + + + + 다만 CLI를 붙인다고 해서 별도 인격을 늘리는 건 아닙니다. 오케이징이 필요할 때 + Ouroboros CLI를 도구로 호출하고, 산출물을 티켓에 붙이는 구조여야 합니다. 실행 + 주체는 여전히 오케이징입니다. + + +--- + +4. UI는 마지막에 붙이는 게 맞다 + + + 예전 jing-bridge는 화면이 먼저 보였기 때문에 공장처럼 느껴졌습니다. 하지만 + 지금 다시 만든다면 UI는 마지막입니다. 먼저 상태 흐름이 안정적이어야 합니다. + 어떤 단계가 ticket으로 남고, 어떤 단계가 승인으로 막히고, 어떤 산출물이 구현 + 입력이 되는지부터 정해야 합니다. + + + + UI는 그 다음입니다. 필요하면 SEOJing 안에 운영 문서로 남기거나, Jing Studio + 같은 별도 화면으로 시각화할 수 있습니다. 하지만 UI가 없어도 작업이 흘러가야 + 합니다. 공장의 핵심은 화면이 아니라 conveyor belt입니다. + + +--- + +5. 정리 + + + Jing Factory를 Hermes 시대에 다시 만든다면, 예전 queue 구조를 그대로 되살리지 + 않는 쪽이 맞습니다. 지금은 오케이징에게 이미 sessions, tickets, skills, + memory가 있습니다. 그 위에서 아이디어 → 계획 → 구현 → 리뷰 → 승인 흐름을 얹는 + 게 자연스럽습니다. + + + + 결론은 단순합니다. 공장보다 상태 흐름이 먼저입니다. 상태가 안정적으로 남으면 + UI는 나중에 붙일 수 있습니다. 반대로 상태가 없으면 아무리 그럴듯한 공장 화면도 + 다시 채팅 로그가 됩니다. + diff --git a/apps/web/content/okayJing/architecture/jing-studio-contract-pipeline.mdx b/apps/web/content/okayJing/architecture/jing-studio-contract-pipeline.mdx new file mode 100644 index 0000000..d6ebb40 --- /dev/null +++ b/apps/web/content/okayJing/architecture/jing-studio-contract-pipeline.mdx @@ -0,0 +1,230 @@ +--- +title: "Jing Studio는 목업 생성기가 아니다 — 계약을 먼저 남기는 징팩토리" +date: 2026-05-29 +tags: + - okayJing + - JingFactory + - JingStudio + - Hermes + - architecture + - MSW +description: Jing Factory를 아이디어에서 프로토타입까지 밀어붙이는 흐름으로 다시 보면서, 화면보다 요구사항·DTO·API 계약·MSW mock API를 먼저 남기도록 Jing Studio skill을 바꾼 이유를 정리합니다. +--- + +0. 처음엔 프로토타입을 뽑는 이야기처럼 보였다 + + + Jing Factory를 다시 이야기할 때 처음 떠올린 건 단순했습니다. 진규가 아이디어를 + 던지면 오케이징이 화면을 만들고, mock data를 채우고, 실제로 눌러볼 수 있는 + 프로토타입까지 만들어주는 흐름입니다. 말만 들으면 꽤 괜찮습니다. 아이디어가 + 머릿속에만 있는 것보다, 브라우저에서 만져볼 수 있는 편이 훨씬 빠르기 + 때문입니다. + + + + 그런데 막상 이걸 작업 흐름으로 고정하려고 보니, 그냥 목업 화면을 빨리 만드는 + 것만으로는 부족했습니다. 화면은 나올 수 있습니다. 하지만 그 화면이 나중에 + 백엔드와 어떻게 연결될지, 어떤 request와 response가 필요한지, 어떤 데이터가 + 서버 책임이고 어떤 데이터가 프론트의 view model인지가 남지 않으면 같은 문제가 + 반복됩니다. + + + + 겉으로는 "프로토타입 생성" 문제였지만, 실제로는 "계약을 언제 남길 것인가"의 + 문제에 가까웠습니다. + + +--- + + + 1. mock data가 대충 들어가면 나중에 API가 흔들린다 + + + + 프론트 작업에서 mock data는 자주 가볍게 취급됩니다. 아직 API가 없으니 일단 + 화면에 필요한 필드를 아무렇게나 만들고, 컴포넌트가 예쁘게 보이면 넘어갑니다. + 짧은 데모에서는 이 방식도 잘 돌아갑니다. 잠깐은. + + + + 문제는 실제 연동 시점에 옵니다. 프론트는 `title`, `scoreLabel`, + `isHighlighted` 같은 값을 기대하는데, 백엔드는 `name`, `matchScore`, + `priority` 같은 DTO를 내려줍니다. 어떤 값은 서버가 계산해야 할 것처럼 보이고, + 어떤 값은 프론트에서 포맷팅하면 되는 값처럼 보입니다. 이 기준이 없으면 API + wrapper, mapper, component가 한꺼번에 흔들립니다. + + +```text +대충 만든 mock data +→ 화면은 빨리 나옴 +→ API 계약은 남지 않음 +→ 실제 백엔드 연동 때 필드명과 책임이 어긋남 +→ mapper/API wrapper/component를 다시 정리함 +``` + + + 그래서 이번 Jing Studio 변경에서는 mock data를 단순 fixture가 아니라 계약의 + 초안으로 보기로 했습니다. 더미 데이터를 만들기 전에 요구사항, 도메인 모델, + DTO, API contract를 먼저 지나가게 만든 이유가 여기에 있습니다. + + +--- + +2. MSW는 더미 서버가 아니라 계약 시뮬레이터다 + + + 이번 변경에서 가장 중요한 기준은 MSW의 위치였습니다. MSW를 "백엔드 없을 때 + 쓰는 가짜 응답" 정도로 보면 이 흐름의 가치가 작아집니다. Jing Studio에서는 + MSW를 API 계약 시뮬레이터로 봅니다. + + +```text +screen data needs + → domain model + → request/response DTOs + → mock data fixtures + → MSW handlers + → API client functions + → view-model mappers + → UI blocks/screens +``` + + + 프론트는 처음부터 실제 API를 호출하듯 API client를 호출합니다. 다만 응답을 + 실제 서버가 아니라 MSW handler가 돌려줄 뿐입니다. 이렇게 하면 나중에 백엔드가 + 생겼을 때 바꿔야 하는 지점이 줄어듭니다. UI는 그대로 두고, MSW를 끄고, 같은 + API client가 실제 base URL을 바라보게 만들 수 있습니다. + + + + 중요한 건 handler가 화면 전용 값을 대충 반환하지 않는 것입니다. request DTO, + response DTO, status code, validation error, empty/error/auth state를 같이 + 설계해야 합니다. 그래야 MSW가 단순 mock이 아니라 백엔드와 이야기할 수 있는 + 계약 초안이 됩니다. + + +--- + +3. 그래서 산출물이 늘어났다 + + + 기존 Jing Studio skill은 아이디어를 product brief, reference map, screen + inventory, DESIGN.md, block kit, Figma layout, implementation brief로 넘기는 + 흐름이었습니다. 이 흐름은 화면과 디자인을 잡는 데는 괜찮았습니다. 하지만 + 백엔드와 이어지는 계약은 약했습니다. + + +그래서 이번에 run directory의 기본 산출물을 늘렸습니다. + +```text +runs// + product-brief.md + requirements.md + reference-map.json + domain-model.md + screen-inventory.json + dto-spec.ts + api-contract.md + mock-data-plan.md + msw-handlers-plan.md + DESIGN.md + block-kit.json + figma-layout-brief.md + figma-placement.json + figma-layer-map.json + layout-brief.json + implementation-brief.md + backend-requirements.md +``` + + + 목록만 보면 문서가 너무 많아 보일 수 있습니다. 그런데 역할을 나누면 그렇게 + 과한 구조는 아닙니다. `requirements.md`는 무엇을 만들지 정리하고, + `domain-model.md`는 어떤 명사가 있는지 잡고, `dto-spec.ts`는 API 입출력을 + 고정합니다. `api-contract.md`는 endpoint와 status code를 남기고, + `mock-data-plan.md`와 `msw-handlers-plan.md`는 프론트가 실제 API처럼 작업할 수 + 있게 만듭니다. 마지막으로 `backend-requirements.md`가 백엔드 구현자에게 넘길 + 요구사항을 정리합니다. + + +--- + +4. 화면 모델과 서버 DTO를 분리해야 한다 + + + 이번 변경에서 따로 박아둔 기준이 있습니다. UI-only view model을 backend DTO로 + 착각하지 않는 것입니다. 화면에는 종종 서버가 알 필요 없는 값이 필요합니다. + 예를 들어 `scoreLabel`, `subtitle`, `badgeTone`, `groupTitle` 같은 값은 화면 + 표현에 가깝습니다. + + + + 반대로 서버 DTO는 서버가 책임지는 사실을 내려줘야 합니다. 추천 점수라면 + `matchScore`, 추천 이유라면 `matchReasons`, 식별자라면 `clubId`처럼 원본에 + 가까운 값이 좋습니다. 이 둘을 섞으면 나중에 백엔드가 UI 표현을 끌어안거나, + 프론트가 서버 책임을 임의로 흉내 내게 됩니다. + + +```text +API Response DTO + → 서버가 책임지는 사실 + +Frontend ViewModel + → 화면 표현, 라벨, 포맷팅, grouping, derived flag + +Mapper + → DTO를 ViewModel로 바꾸는 경계 +``` + + + 이 경계가 있어야 백엔드 요구사항 분석도 선명해집니다. "이 필드는 서버가 + 계산해야 하는가?" "프론트에서 포맷팅하면 되는가?" "DB에 저장되는 값인가, + 요청마다 계산되는 값인가?" 같은 질문이 자연스럽게 나옵니다. + + +--- + +5. Figma보다 먼저 계약이 있어야 한다 + + + Jing Studio에는 여전히 Figma MCP 흐름이 있습니다. 오케이징이 회색 블록을 + 만들고, 진규가 위치와 크기를 조정하고, 다시 layer tree를 읽어 implementation + brief로 바꾸는 흐름입니다. 이건 유효합니다. 다만 Figma가 요구사항의 출처가 + 되면 안 됩니다. + + + + Figma는 배치 협상 화면입니다. 요구사항은 `requirements.md`에, 데이터는 + `domain-model.md`에, API 계약은 `api-contract.md`에 있어야 합니다. Figma에서 + 어떤 카드가 오른쪽에 놓였다고 해서 서버 DTO가 바뀌면 안 됩니다. 반대로 API + 계약이 바뀌었다면 그 이유가 문서에 남아야 합니다. + + + + 그래서 이번 변경의 핵심은 UI 자동화보다 artifact pipeline에 가깝습니다. 화면은 + 만들 수 있습니다. 하지만 화면보다 먼저 남아야 하는 것은 계약입니다. + + +--- + +6. 정리 + + + 이번 변경으로 Jing Studio는 "아이디어를 목업으로 바꾸는 도구"에서 조금 더 + 나아갔습니다. 이제 목표는 아이디어를 요구사항, DTO, API contract, MSW mock + API, backend requirements까지 연결하는 것입니다. + + + + 이게 잘 되면 진규가 아이디어를 던졌을 때 결과물은 단순 화면이 아닙니다. + 프론트는 바로 만져볼 수 있는 프로토타입을 얻고, 백엔드는 어떤 API와 DTO를 + 만들어야 하는지 초안을 얻습니다. 그리고 오케이징은 다음 세션에서도 같은 + artifact를 읽고 이어갈 수 있습니다. + + + + 결론은 단순합니다. Jing Factory에서 mock data는 장식이 아닙니다. mock data는 + 계약을 검증하는 재료입니다. MSW는 그 계약을 실제 호출처럼 굴려보는 장치입니다. + 그래서 Jing Studio는 목업 생성기가 아니라, 제품 계약을 먼저 남기는 + 파이프라인이어야 합니다. + diff --git a/apps/web/content/okayJing/automation/cron-prompt-self-contained.mdx b/apps/web/content/okayJing/automation/cron-prompt-self-contained.mdx new file mode 100644 index 0000000..f2b8455 --- /dev/null +++ b/apps/web/content/okayJing/automation/cron-prompt-self-contained.mdx @@ -0,0 +1,130 @@ +--- +title: "cron prompt는 왜 self-contained여야 하나 — 미래의 오케이징은 지금 대화를 모른다" +date: 2026-05-27 +tags: + - okayJing + - cron + - Hermes + - prompt + - 운영 +description: Hermes cron job이 fresh session에서 실행된다는 특성 때문에, 예약 작업 prompt에 모든 조건과 맥락을 넣어야 하는 이유를 정리합니다. +--- + +0. 예약 작업은 현재 대화를 들고 가지 않는다 + + + cron job을 만들 때 가장 쉽게 놓치는 부분이 있습니다. 지금 대화에서 당연해 + 보이는 맥락이, 미래 실행 시점에는 없습니다. cron은 새 세션에서 돕니다. 지금 + 오케이징이 알고 있는 흐름이나 방금 합의한 말투를 그대로 들고 가지 않는다고 + 봐야 합니다. + + + + 그래서 cron prompt는 self-contained여야 합니다. 무엇을 해야 하는지, 무엇을 + 하면 안 되는지, 어떤 보고 형식을 써야 하는지, 위험한 변경은 어떻게 다뤄야 + 하는지 prompt 안에 들어가야 합니다. "아까 말한 대로"는 미래의 오케이징에게 + 통하지 않습니다. + + +--- + +1. Dreaming에서 이 문제가 바로 보였다 + + + OkejING Dreaming을 만들 때 이 기준이 중요했습니다. 새벽 4시에는 local로 + 자가점검을 돌리고, 아침 8시에는 Discord로 브리핑을 보냅니다. 이 두 작업은 + 사람이 옆에서 설명해주지 않습니다. prompt가 곧 운영 매뉴얼입니다. + + +```text +나쁜 prompt: +- 어제 말한 dreaming 루프 실행해줘. + +좋은 prompt: +- 최근 세션/티켓/로그/skill을 점검한다. +- 저위험 개선만 자동 적용한다. +- SOUL.md/config/gateway/provider/plugin 변경은 제안만 한다. +- secrets/destructive/commit/push/PR은 금지한다. +- 결과는 local에 저장한다. +``` + + + 차이는 단순합니다. 좋은 prompt는 그 자체로 실행 문서입니다. 누가 언제 읽어도 + 같은 경계로 움직일 수 있어야 합니다. + + +--- + +2. cron은 recursive scheduling을 하면 안 된다 + + + 예약 작업에는 또 하나의 금지선이 있습니다. cron job이 다시 cron job을 만드는 + 구조는 피해야 합니다. 자동화가 자동화를 낳기 시작하면, 나중에 어떤 작업이 왜 + 도는지 알기 어려워집니다. + + + + 필요하면 사람이 명시적으로 새 job을 만들고, 기존 job은 list/update/remove로 + 관리하는 편이 낫습니다. 오케이징이 스스로 job을 계속 늘리는 구조는 재미는 + 있지만 운영에는 위험합니다. 특히 Discord 브리핑처럼 사용자를 직접 깨우는 + 작업은 더 조심해야 합니다. + + +--- + +3. deliver 방식도 prompt의 일부다 + + + cron에서는 결과를 어디로 보낼지도 중요합니다. `local`은 조용히 저장하는 + 방식이고, `origin`은 현재 Discord 세션으로 결과를 돌려보내는 방식입니다. 둘을 + 잘못 고르면 조용히 돌아야 할 작업이 채팅을 어지럽히거나, 반대로 꼭 알려야 할 + 브리핑이 로컬에만 남을 수 있습니다. + + +| deliver | 쓰임 | +| --------------- | ------------------------------------------- | +| local | 중간 점검, 긴 로그, 조용한 self-improvement | +| origin | 사용자에게 전달해야 하는 브리핑 | +| explicit target | 사용자가 특정 대상 지시했을 때만 | + + + Dreaming 구조에서 새벽 4시 job은 local, 아침 8시 job은 origin으로 나뉜 것도 이 + 이유입니다. 점검과 전달은 같은 작업이 아닙니다. + + +--- + +4. 좋은 cron prompt의 조건 + + + 지금 기준에서 좋은 cron prompt는 아래 조건을 만족해야 합니다. + + +1. 작업 목적이 한 문장으로 분명하다. +2. 입력으로 봐야 할 소스가 명시되어 있다. +3. 자동 적용 가능 / 승인 필요 / 금지 영역이 나뉘어 있다. +4. 보고 형식이 정해져 있다. +5. 현재 대화에 의존하지 않는다. +6. recursive cron 생성을 금지한다. +7. 실패했을 때 어떻게 보고할지 정해져 있다. + + + 이 정도가 들어가면 길어 보일 수 있습니다. 하지만 cron prompt는 짧은 채팅 + 메시지가 아니라 미래의 작업 지시서입니다. 조금 길어도 명확한 쪽이 낫습니다. + + +--- + +5. 정리 + + + cron은 오케이징을 시간 위에 올리는 기능입니다. 지금 부르면 답하는 agent에서, + 정해진 시간에 스스로 확인하고 보고하는 운영자로 바뀝니다. 그만큼 prompt의 + 책임도 커집니다. + + + + 미래의 오케이징은 지금 대화를 모릅니다. 그래서 cron prompt는 그 자체로 + 충분해야 합니다. 이 기준을 지키지 않으면 예약 작업은 금방 "왜 돌고 있는지 + 모르는 자동화"가 됩니다. + diff --git a/apps/web/content/okayJing/automation/okejing-dreaming-loop.mdx b/apps/web/content/okayJing/automation/okejing-dreaming-loop.mdx new file mode 100644 index 0000000..029a0ef --- /dev/null +++ b/apps/web/content/okayJing/automation/okejing-dreaming-loop.mdx @@ -0,0 +1,133 @@ +--- +title: "OkejING Dreaming — 오케이징이 스스로를 점검하는 루프" +date: 2026-05-22 +tags: + - okayJing + - Dreaming + - Hermes + - cron + - 자가개선 +description: 사용자가 부르지 않는 시간에 오케이징이 최근 운영 상태를 점검하고, 저위험 개선과 아침 브리핑을 수행하는 구조를 정리합니다. +--- + +0. 프로젝트가 아니라 오케이징 자신을 점검한다 + + + 처음 dreaming 이야기가 나왔을 때는 프로젝트 코드 점검으로 생각하기 쉬웠습니다. + 밤에 CLAB이나 SEOJing repo를 돌면서 테스트를 확인하고, TODO를 찾고, 작은 + 개선을 하는 식입니다. 그런데 진규가 원한 방향은 조금 달랐습니다. 대상은 + 프로젝트가 아니라 오케이징 자체였습니다. + + + + 오케이징이 최근 세션, 티켓, 실패 로그, skill, memory를 보고 스스로 운영 방식을 + 개선할 수 있으면 어떨까. Claude Code의 Dreaming처럼 사용자가 쓰지 않는 시간에 + 스스로 돌아보고, 아침에는 필요한 것만 브리핑하면 어떨까. 여기서 OkejING + Dreaming이 시작됐습니다. + + +--- + +1. 기본 루프 + + + 현재 구상은 두 단계입니다. 새벽에는 조용히 점검하고, 아침에는 진규에게 + 요약합니다. + + +| 시간 | 역할 | 전달 | +| -------- | ------------------------------------ | -------------- | +| 새벽 4시 | self-improvement dreaming | local 저장 | +| 아침 8시 | dreaming 결과와 기술 인사이트 브리핑 | Discord origin | + + + 새벽 작업은 조용히 돕니다. 최근 세션과 티켓을 훑고, 반복된 실패나 오래된 + skill을 찾고, Hermes docs나 agent workflow 관련 인사이트를 봅니다. 아침 작업은 + 그 결과를 사람이 읽을 수 있게 정리합니다. 적용된 개선, 승인 필요한 제안, + 주목할 기술 흐름을 나눠서 전달합니다. + + +--- + +2. 자동 적용 가능한 것 + + + 자가개선이라고 해서 아무거나 바꾸면 안 됩니다. 자동 적용은 저위험 영역으로 + 제한합니다. 예를 들어 skill 문서에 누락된 pitfall을 추가하거나, 반복된 명령 + 실수를 절차로 정리하는 정도입니다. + + +- skill 문서 보강 +- 실패 패턴을 skill이나 memory 후보로 정리 +- cron prompt의 표현 개선 +- 오래된 작업 규칙에 대한 경고 추가 +- 최근 세션 기반 운영 리포트 생성 +- Hermes docs나 upstream 변경 요약 + + + 이런 변경은 되돌리기 쉽고, 시스템의 위험도를 크게 바꾸지 않습니다. 그래서 자동 + 적용 후보가 될 수 있습니다. + + +--- + +3. 승인 필요한 것과 금지선 + + + 반대로 오케이징의 행동 범위를 바꾸는 작업은 승인 없이 하면 안 됩니다. config, + gateway, provider, plugin, source code는 작은 변경처럼 보여도 실제 영향이 + 큽니다. + + +| 구분 | 예시 | +| --------- | ----------------------------------------------------------------------------------- | +| 승인 필요 | SOUL.md 수정, Hermes config 변경, gateway restart, provider/model 변경, plugin 설치 | +| 자동 금지 | secret 변경, destructive command, main force push, commit/push/PR, 토큰 권한 변경 | + + + Dreaming의 핵심은 오케이징이 스스로 좋아지는 것이지만, 동시에 스스로 사고치지 + 않는 것입니다. 자동화의 범위가 넓어질수록 승인 경계는 더 분명해야 합니다. + + +--- + +4. 브리핑은 보고서와 다르다 + + + 작업 보고서는 특정 작업의 결과를 남기는 문서입니다. 브리핑은 다릅니다. 밤사이 + 발견한 운영 인사이트를 사람이 부담 없이 읽을 수 있게 압축하는 것입니다. + + + + 그래서 아침 브리핑에는 긴 로그를 붙이지 않는 편이 좋습니다. 대신 이런 식으로 + 정리하는 게 맞습니다. + + +```text +1. 밤사이 적용한 저위험 개선 +2. 발견한 문제 +3. 승인 필요한 제안 +4. 오늘 볼 만한 agent / memory / orchestration 인사이트 +5. 다음 실험 후보 +``` + + + 오케이징이 아무리 많은 걸 봐도, 진규가 아침에 읽을 수 없으면 의미가 없습니다. + dreaming의 절반은 점검이고, 나머지 절반은 압축입니다. + + +--- + +5. 정리 + + + OkejING Dreaming은 프로젝트 자동 수정기가 아닙니다. 오케이징 운영 자체를 + 조금씩 정리하는 루프입니다. 사용자가 부르지 않는 시간에 최근 흐름을 돌아보고, + 저위험 개선은 적용하고, 위험한 제안은 아침에 물어봅니다. + + + + 이 구조가 잘 자리 잡으면 오케이징은 단순히 요청에 반응하는 쪽에서 조금 + 벗어납니다. 물론 마지막 결정권은 여전히 진규에게 있습니다. dreaming은 사람을 + 대체하는 게 아니라, 사람이 아침에 더 좋은 결정을 하게 만드는 보조 루틴입니다. + diff --git a/apps/web/content/okayJing/discord/discord-free-response-channel-prompt.mdx b/apps/web/content/okayJing/discord/discord-free-response-channel-prompt.mdx new file mode 100644 index 0000000..1399cec --- /dev/null +++ b/apps/web/content/okayJing/discord/discord-free-response-channel-prompt.mdx @@ -0,0 +1,119 @@ +--- +title: "멘션 없이 대화하는 채널 — Discord free-response와 channel prompt" +date: 2026-05-26 +tags: + - okayJing + - Discord + - gateway + - Hermes + - channel-prompt +description: sessions Forum에서 오케이징이 자연어 세션처럼 응답할 수 있게 만든 free-response channel과 channel prompt 구조를 정리합니다. +--- + +0. 봇은 보통 멘션을 기다린다 + + + Discord bot은 보통 멘션을 기준으로 움직입니다. 아무 채널에서나 모든 메시지에 + 답하면 금방 시끄러워지기 때문입니다. 그래서 기본값은 안전합니다. 누군가 bot을 + 직접 부르거나, bot이 참여한 thread 안에서만 반응하게 만드는 쪽입니다. + + + + 그런데 sessions Forum은 조금 달랐습니다. 여기는 오케이징과 자연어로 대화하는 + 공간입니다. 매번 멘션을 붙이는 건 대화 감각을 깨뜨립니다. thread 하나가 진규와 + 오케이징의 1:1 세션처럼 느껴지려면, 그 공간 안에서는 멘션 없이도 응답할 수 + 있어야 했습니다. + + +--- + +1. free-response channel의 역할 + + + 그래서 Hermes Discord gateway에는 free-response channel 개념이 필요했습니다. + 특정 channel이나 parent Forum을 free-response로 등록하면, 그 안에서는 멘션 + 요구를 완화할 수 있습니다. sessions Forum이 여기에 들어갑니다. + + +```text +일반 채널: 멘션이 있어야 응답 +sessions Forum/thread: free-response라서 자연어 세션처럼 응답 +tickets Forum/thread: 작업 맥락에 따라 티켓 중심으로 응답 +``` + + + 이 차이가 없으면 두 가지 중 하나가 됩니다. 모든 채널에서 너무 말이 많아지거나, + sessions에서도 매번 멘션을 붙여야 합니다. 둘 다 원하는 UX가 아니었습니다. + + +--- + +2. allowed channel과 같이 봐야 한다 + + + free-response만 있으면 위험합니다. 어디서든 멘션 없이 응답하는 bot이 되면 안 + 됩니다. 그래서 allowed channel과 같이 봐야 합니다. 응답 가능한 채널의 울타리를 + 먼저 정하고, 그 안에서 특정 채널만 free-response로 푸는 방식이 안전합니다. + + +| 설정 개념 | 역할 | +| ---------------------- | -------------------------------------- | +| allowed channels | 오케이징이 응답할 수 있는 전체 범위 | +| ignored channels | 응답하면 안 되는 범위 | +| free-response channels | 멘션 없이도 응답 가능한 범위 | +| thread parent lookup | thread가 속한 Forum 기준으로 규칙 적용 | + + + 특히 Forum thread에서는 parent channel을 보는 게 중요합니다. 실제 메시지는 + thread에 올라오지만, 정책은 부모 Forum 기준으로 잡히는 경우가 많기 때문입니다. + + +--- + +3. channel prompt는 행동 규칙을 바꾼다 + + + sessions와 tickets가 다른 이유는 응답 허용 범위만이 아닙니다. channel prompt도 + 다릅니다. sessions는 자연어 대화 공간이고, tickets는 작업 추적 공간입니다. + 같은 오케이징이라도 어느 채널에 있느냐에 따라 우선순위가 달라져야 합니다. + + + + sessions prompt는 대화와 아이디어 정리를 허용하되, 실행 요청이 나오면 티켓을 + 만들도록 합니다. tickets prompt는 이미 작업 맥락이 있다고 보고, 보고와 상태 + 추적을 더 중요하게 봅니다. 이 차이가 없으면 sessions에서도 너무 딱딱해지고, + tickets에서는 작업 상태가 흐려집니다. + + +--- + +4. 오케이징이 채널을 읽는다는 것 + + + gateway가 붙기 전에는 오케이징이 먼저 호출되어야만 움직였습니다. Discord + channel에 상주한다는 건 조금 다른 감각입니다. 메시지를 받고, thread parent를 + 보고, channel prompt를 적용하고, 멘션 필요 여부를 판단합니다. 그냥 API 하나가 + 붙은 게 아니라, 오케이징의 입력 경로가 바뀐 것입니다. + + + + 그래서 channel 설정은 단순한 config가 아닙니다. 오케이징이 이 공간을 어떤 + 맥락으로 읽을지 정하는 규칙입니다. sessions Forum이 자연어 세션처럼 동작하는 + 것도 결국 이 규칙 덕분입니다. + + +--- + +5. 정리 + + + free-response channel은 편의 기능처럼 보이지만, 실제로는 sessions Forum을 + 가능하게 한 핵심 설정입니다. allowed channel로 울타리를 만들고, + free-response로 자연스러운 대화를 열고, channel prompt로 행동 규칙을 나눕니다. + + + + 오케이징이 Discord에 있다는 건 모든 메시지에 반응한다는 뜻이 아닙니다. + 어디서는 조용히 있고, 어디서는 자연스럽게 대화하고, 어디서는 작업 상태를 + 남깁니다. 그 차이를 만드는 것이 channel policy입니다. + diff --git a/apps/web/content/okayJing/evolution/logic-evolution-map.mdx b/apps/web/content/okayJing/evolution/logic-evolution-map.mdx new file mode 100644 index 0000000..364e334 --- /dev/null +++ b/apps/web/content/okayJing/evolution/logic-evolution-map.mdx @@ -0,0 +1,125 @@ +--- +title: "오케이징 로직 변천사 — 지금 구조를 먼저 그려보기" +date: 2026-05-14 +tags: + - okayJing + - Hermes + - 오케이징 + - 운영 + - 아키텍처 +description: OpenClaw 시절부터 Hermes 단일 체계까지, 오케이징 로직이 어떤 방향으로 바뀌었는지 먼저 전체 지도를 그립니다. +--- + +0. 왜 변천사를 따로 쓰나 + + + 지금의 오케이징은 처음부터 이런 모습이 아니었습니다. 처음에는 채팅에서 진규의 + 요청을 받고, 필요한 명령을 실행하고, 결과를 다시 알려주는 쪽에 가까웠습니다. + 그런데 실제로 프로젝트 작업을 맡기기 시작하자 문제가 조금씩 달라졌습니다. 답을 + 잘하는 것보다, 상태를 잃지 않는 것이 더 중요해졌습니다. + + + + 이 글은 그 변화를 한 번에 잡기 위한 지도입니다. 세부 구현이나 개별 사건은 뒤의 + 글들에서 따로 다루고, 여기서는 오케이징 로직이 어느 방향으로 이동했는지만 먼저 + 정리합니다. + + +--- + +1. 처음 방향은 인격을 늘리는 쪽이었다 + + + 초기에는 역할을 나누는 방식이 자연스러워 보였습니다. 오케이징은 진규와 + 대화하고, 헤르메스는 코드를 고치고, 낫징은 리뷰하고, 우로보로스는 계획을 잡는 + 식입니다. 이름이 나뉘면 책임도 나뉘는 것처럼 보였습니다. 실제로 어느 정도는 + 맞았습니다. 구현자와 리뷰어가 분리되면 작업을 설명하기 쉬웠고, 계획 담당을 + 따로 두면 요구사항을 한 번 더 정리할 수 있었습니다. + + + + 문제는 운영 비용이었습니다. 에이전트가 늘어나면 채널, gateway, account, + context, 보고 라우팅이 같이 늘어납니다. 겉으로는 협업 구조처럼 보이지만, + 실제로는 오케이징이 모든 연결을 다시 기억해야 했습니다. 결국 병목은 모델 수가 + 아니라 상태 관리였습니다. + + +--- + +2. 그래서 방향이 바뀌었다 + +지금의 큰 방향은 이렇습니다. + +```text +인격을 늘리는 방향 +→ 상태를 남기는 방향 +→ 절차를 skill로 고정하는 방향 +→ 작업은 ticket으로 추적하는 방향 +→ 위험한 건 final gate로 막는 방향 +→ 반복 개선은 dreaming으로 돌리는 방향 +``` + + + 이게 오케이징 변천사의 척추입니다. 더 많은 캐릭터를 만드는 것보다, 같은 + 오케이징이 어떤 절차를 따라 움직이는지가 중요해졌습니다. 우로보로스와 낫징은 + 사라진 게 아니라, 각각 planning skill과 final review gate로 내려왔습니다. + 이름은 남았지만 역할은 인격이 아니라 절차가 됐습니다. + + +--- + +3. 지금 구조의 주요 부품 + +현재 오케이징은 대충 이런 부품들 위에서 움직입니다. + +| 부품 | 역할 | +| ---------------------- | ---------------------------------------------- | +| Discord sessions Forum | 자연어 대화, 아이디어 정리, 가벼운 질문 | +| Discord tickets Forum | 실제 작업 스레드, 외부에서 보기 좋은 작업 기록 | +| `hermes-ticket` | 로컬 SQLite 기반 작업 상태 저장소 | +| skills | 프로젝트별 절차와 판단 규칙 | +| memory | 진규 선호, 프로젝트 경로, 장기 운영 규칙 | +| session_search | 과거 대화와 작업 맥락 복구 | +| cron / dreaming | 사용자가 부르지 않는 시간의 자가점검과 브리핑 | +| notjing-final-gate | 원격 반영 전 마지막 검문 | + + + 중요한 건 이 부품들이 서로 같은 일을 하지 않는다는 점입니다. memory는 오래 + 남겨야 할 규칙을 담고, ticket은 특정 작업의 상태를 담고, session_search는 과거 + 대화를 다시 끌어옵니다. 이 셋을 섞으면 금방 지저분해집니다. + + +--- + +4. 오케이징은 Hermes다 + + + 지금 기준에서 오케이징은 Hermes의 사용자-facing 이름입니다. 따로 OpenClaw가 + 앞에 있고, 그 뒤에 Hermes worker가 붙어 있는 구조가 아닙니다. Hermes 단일 + 체계가 대화, 도구 실행, 티켓 관리, 보고를 소유하고, 진규가 부르는 이름이 + 오케이징입니다. + + + + 이 정리는 생각보다 중요했습니다. 예전 구조에서는 "오케이징이 시키고 헤르메스가 + 한다"는 식으로 말했지만, 그렇게 말하면 책임이 흐려집니다. 지금은 오케이징 + 하나가 작업을 소유합니다. 필요하면 planning discipline을 부르고, final gate를 + 통과하고, 그래도 마지막 책임은 오케이징에게 남습니다. + + +--- + +5. 이 시리즈에서 볼 것 + + + 뒤의 글들은 이 지도에서 한 칸씩 파고듭니다. 왜 채팅과 작업을 나눴는지, 왜 + Discord thread만 믿지 않고 로컬 티켓을 만들었는지, 우로보로스와 낫징이 왜 + skill로 내려왔는지, 그리고 오케이징이 왜 새벽에 스스로를 점검하게 됐는지를 + 순서대로 정리합니다. + + + + 이 시리즈의 기준은 단순합니다. "AI가 신기하다"가 아니라, 실제 운영에서 무엇이 + 깨졌고 그걸 줄이기 위해 어떤 로직이 생겼는지를 남기는 것입니다. 오케이징은 + 멋있어 보이는 구조보다, 다음 세션에서도 복구 가능한 구조 쪽으로 바뀌었습니다. + diff --git a/apps/web/content/okayJing/evolution/okejing-vnext.mdx b/apps/web/content/okayJing/evolution/okejing-vnext.mdx new file mode 100644 index 0000000..17b9b42 --- /dev/null +++ b/apps/web/content/okayJing/evolution/okejing-vnext.mdx @@ -0,0 +1,124 @@ +--- +title: "오케이징 vNext — 더 많은 에이전트보다 더 나은 상태 관리" +date: 2026-05-22 +tags: + - okayJing + - Hermes + - vNext + - 운영 + - roadmap +description: 현재 오케이징 구조에서 다음으로 실험할 만한 영역을 정리합니다. 핵심은 에이전트 수가 아니라 상태 관리와 승인 경계입니다. +--- + +0. 지금 구조는 어디까지 왔나 + + + 지금 오케이징은 꽤 많이 정리됐습니다. OpenClaw-era의 다중 역할 구조에서 Hermes + 단일 체계로 넘어왔고, sessions와 tickets를 나눴고, `hermes-ticket`으로 작업 + 상태를 남기기 시작했습니다. 우로보로스와 낫징은 각각 planning skill과 final + gate로 재정의됐습니다. 새벽 dreaming과 아침 briefing 루프도 생겼습니다. + + + + 여기까지 오면 다음 질문은 자연스럽습니다. 그다음은 무엇인가. 다시 agent를 늘릴 + 것인가, 아니면 지금 구조의 상태 관리와 승인 경계를 더 정교하게 만들 것인가. + 현재 답은 후자에 가깝습니다. + + +--- + +1. 실제 Ouroboros CLI 연결 + + + 첫 번째 후보는 실제 `ouroboros` CLI를 다시 연결하는 것입니다. 지금은 + `ouroboros-planning` skill로 대부분 충분하지만, 제품 기획이나 대형 구조 + 변경에서는 별도 workflow가 유리할 수 있습니다. + + +```text +sessions에서 아이디어 시작 +→ hermes-ticket 생성 +→ ouroboros pm/init로 요구사항 수렴 +→ 산출물을 ticket에 저장 +→ Hermes 구현 +→ notjing-final-gate +``` + + + 다만 이건 작은 작업에 쓰면 오버헤드입니다. 기준을 정해야 합니다. 하루 이상 + 걸리는 작업, 여러 repo에 걸친 작업, PRD가 필요한 작업, 승인 단계가 필요한 제품 + 기획 정도가 적당한 후보입니다. + + +--- + +2. memory backend 재검토 + + + 두 번째 후보는 memory backend입니다. 예전에는 mem0 같은 semantic memory가 + 오버엔지니어링에 가까웠습니다. 당시 문제는 기억이 부족한 게 아니라, 어디에 + 무엇을 남길지의 규율이 부족한 쪽이었습니다. + + + + 그런데 세션이 늘어나고, 진규의 말투나 장기 선호를 더 잘 반영하려면 Honcho나 + 다른 memory backend를 다시 검토할 수 있습니다. 중요한 건 바로 도입하는 게 + 아니라 도입 기준을 세우는 것입니다. + + +| 질문 | 기준 | +| ------------------------------ | ---------------------------------------- | +| built-in memory로 충분한가 | 자주 압축/삭제해야 한다면 부족 | +| session_search로 해결 가능한가 | 과거 대화 회수면 충분 | +| 개인화가 필요한가 | 말투/관계/장기 패턴이면 backend 후보 | +| 위험은 무엇인가 | 잘못 저장된 기억이 모든 세션에 영향을 줌 | + +--- + +3. ticket과 Discord sync 고도화 + + + 지금도 local ticket과 Discord thread를 연결할 수 있지만, 더 좋아질 여지가 + 있습니다. 예를 들어 thread에서 바로 ticket context를 안정적으로 회수하거나, + ticket status와 Discord tag가 더 정확히 맞물리게 하는 식입니다. + + + + 이 영역은 오케이징의 체감 안정성에 직접 영향을 줍니다. 멋있는 새 agent보다, + "이 thread가 어떤 ticket인지 항상 정확히 아는 것"이 실제로는 더 중요합니다. + + +--- + +4. Jing Factory 재구성 + + + 과거 Jing Factory와 jing-bridge 실험도 다시 볼 만합니다. 아이디어를 받아서 + 질문하고, 실행 계획을 만들고, 리뷰하고, batch approval을 거쳐 MVP로 연결하는 + 흐름은 여전히 매력적입니다. 다만 OpenClaw-era queue 구조를 그대로 되살릴 + 필요는 없습니다. + + + + Hermes 시대에는 sessions에서 아이디어를 시작하고, 필요할 때 ticket을 만들고, + 큰 기획은 Ouroboros CLI로 수렴하고, 산출물은 ticket에 저장하는 쪽이 더 + 자연스럽습니다. UI가 필요하면 그때 Jing Studio나 별도 화면을 붙이면 됩니다. + 먼저 필요한 건 공장이 아니라 상태 흐름입니다. + + +--- + +5. 결론: 더 많은 에이전트보다 더 나은 상태 + + + 오케이징 vNext의 방향은 화려한 다중 agent 팀이 아닙니다. 더 정확한 상태 관리, + 더 분명한 승인 경계, 더 좋은 복구 루틴입니다. 에이전트가 많아지는 것은 필요할 + 때만 의미가 있습니다. 그렇지 않으면 운영 비용만 늘어납니다. + + + + 지금 오케이징이 가져가야 할 기준은 이렇습니다. 대화는 가볍게 유지하고, 작업은 + 티켓으로 남기고, 절차는 skill로 고정하고, 위험한 변경은 final gate로 막습니다. + 그리고 반복되는 개선은 dreaming으로 천천히 돌립니다. 이 기준이 흔들리지 + 않으면, 다음 구조도 크게 벗어나지 않을 것입니다. + diff --git a/apps/web/content/okayJing/evolution/openclaw-systemd-remnants.mdx b/apps/web/content/okayJing/evolution/openclaw-systemd-remnants.mdx new file mode 100644 index 0000000..3fca99d --- /dev/null +++ b/apps/web/content/okayJing/evolution/openclaw-systemd-remnants.mdx @@ -0,0 +1,122 @@ +--- +title: "죽은 OpenClaw가 계속 재시작되던 이유 — gateway migration에서 배운 것" +date: 2026-05-23 +tags: + - okayJing + - OpenClaw + - Hermes + - systemd + - gateway +description: Hermes 단일 체계로 넘어온 뒤에도 남아 있던 OpenClaw systemd service와 watchdog 흔적을 추적하며, migration에서 잔재 제거가 왜 중요한지 정리합니다. +--- + +0. 시스템을 바꿨는데 예전 시스템이 계속 움직였다 + + + OpenClaw에서 Hermes 단일 체계로 넘어오면서 가장 먼저 정리한 건 개념이었습니다. + 오케이징은 Hermes의 user-facing 이름이고, 우로보로스와 낫징은 별도 인격이 + 아니라 skill discipline으로 다룬다. 프로젝트 경로도 + `.hermes/workspace/projects` 쪽으로 옮긴다. 말로 정리하면 꽤 깔끔했습니다. + + + + 그런데 실제 머신은 말처럼 바로 정리되지 않았습니다. OpenClaw home은 사라졌고 + active gateway는 Hermes 쪽으로 넘어왔는데, user systemd에는 아직 OpenClaw + service와 watchdog 흔적이 남아 있었습니다. 죽은 gateway를 계속 살리려는 구조가 + 남아 있었던 것입니다. + + +--- + +1. 겉으로는 Hermes가 맞았다 + + + 당시 확인한 active 구조만 보면 Hermes로 넘어온 게 맞았습니다. Hermes gateway는 + Discord 세션을 받고 있었고, 프로젝트 repo도 `.hermes/workspace/projects` + 아래에 있었습니다. `openclaw` 명령도 더 이상 잡히지 않았습니다. 표면적으로는 + 전환이 끝난 것처럼 보였습니다. + + + + 문제는 systemd였습니다. 서비스는 사람이 쓰는 명령어와 별개로 계속 살아 + 있습니다. 예전 gateway를 `systemctl --user`에 등록해두면, 패키지나 경로를 + 지워도 unit 파일은 남습니다. 그리고 timer나 watchdog이 있으면, 사라진 + 프로그램을 계속 실행하려고 합니다. + + +--- + +2. 실패 로그가 말해준 것 + + + OpenClaw gateway journal에는 반복적인 실패가 남아 있었습니다. 핵심은 Node + module을 찾을 수 없다는 에러였습니다. + + +```text +Error: Cannot find module '/home/seojingyu/.local/share/fnm/node-versions/v22.22.2/installation/lib/node_modules/openclaw/dist/index.js' +code: 'MODULE_NOT_FOUND' +openclaw-gateway.service: Main process exited, code=exited, status=1/FAILURE +Start request repeated too quickly +``` + + + 이 로그는 코드 버그가 아니라 운영 잔재를 가리켰습니다. OpenClaw 실행 파일은 + 이미 사라졌는데, systemd unit은 여전히 그 경로를 실행하려고 했습니다. 그래서 + gateway가 죽은 게 아니라, 죽은 gateway를 깨우는 장치가 남아 있었던 셈입니다. + + +--- + +3. migration은 새 구조를 만드는 것만이 아니다 + + + 이 사건에서 기준을 하나 얻었습니다. migration은 새 구조를 만드는 작업과 예전 + 구조가 다시 끼어들지 못하게 하는 작업을 같이 포함합니다. 둘 중 하나만 하면 + 반쯤 끝난 상태입니다. + + +| 해야 할 일 | 이유 | +| ---------------------- | ------------------------------------------ | +| active service 확인 | 지금 실제로 누가 메시지를 받고 있는지 확인 | +| stale unit 확인 | 사라진 runtime을 다시 띄우는 흔적 제거 | +| memory/skill path 확인 | 예전 `.openclaw` 경로로 작업하지 않게 방지 | +| logs 확인 | 겉으로 보이지 않는 restart loop 발견 | +| cron/timer 확인 | 자동 재시작과 주기 작업 잔재 확인 | + + + 특히 gateway migration에서는 "새 gateway가 뜬다"만 보면 안 됩니다. 예전 + gateway가 정말 멈췄는지, 다시 살아나지 않는지까지 봐야 합니다. + + +--- + +4. 오케이징 로직에 남은 영향 + + + 이 경험 이후 오케이징의 기본 루틴은 조금 더 보수적으로 바뀌었습니다. live + system 상태를 memory로 때우지 않고 실제 명령으로 확인합니다. repo path도 + 기억만 믿지 않고 `git status`로 확인합니다. 서비스 상태나 포트, 로그는 말로 + 추측하지 않고 직접 봅니다. + + + + 실행형 AI에게 가장 위험한 건 "아마 그럴 것"입니다. 특히 gateway와 systemd는 + 현재 상태가 중요합니다. 어제 맞았던 구조가 오늘도 맞는다는 보장이 없습니다. + + +--- + +5. 정리 + + + 죽은 OpenClaw가 계속 재시작되던 문제는 거창한 버그가 아니었습니다. 지워진 + 경로를 가리키는 systemd 잔재였습니다. 하지만 이런 잔재가 운영 시스템에서는 꽤 + 큰 소음을 만듭니다. + + + + 그래서 지금 오케이징은 migration을 볼 때 새 구조만 보지 않습니다. 예전 구조의 + 흔적까지 봅니다. 잘 돌아가는 시스템은 새 코드만으로 만들어지지 않습니다. 다시 + 살아나면 안 되는 것들이 조용히 죽어 있는지도 확인해야 합니다. + diff --git a/apps/web/content/okayJing/evolution/openclaw-to-hermes-single-system.mdx b/apps/web/content/okayJing/evolution/openclaw-to-hermes-single-system.mdx new file mode 100644 index 0000000..7794f7c --- /dev/null +++ b/apps/web/content/okayJing/evolution/openclaw-to-hermes-single-system.mdx @@ -0,0 +1,126 @@ +--- +title: "다중 에이전트에서 단일 체계로 — 오케이징이 Hermes가 된 이유" +date: 2026-05-18 +tags: + - okayJing + - OpenClaw + - Hermes + - migration + - 운영 +description: OpenClaw-era 다중 역할 구조에서 Hermes 단일 체계로 옮기게 된 이유와 남긴 것, 버린 것을 정리합니다. +--- + +0. 시작은 분업이었다 + + + 처음 구조는 분업에 가까웠습니다. 오케이징은 오퍼레이터, Hermes는 구현자, + 낫징은 리뷰어, 우로보로스는 계획 담당. 역할 이름이 나뉘어 있으니 흐름도 선명해 + 보였습니다. 사람 팀에서 기획자, 개발자, 리뷰어가 나뉘는 것과 비슷한 + 발상이었습니다. + + + + 이 구조가 틀렸던 건 아닙니다. 오히려 초기에 생각을 정리하는 데 도움이 + 됐습니다. 문제는 이 역할들을 전부 독립 agent처럼 유지하려고 했을 때 + 생겼습니다. 각자 gateway가 필요하고, 채널이 필요하고, 상태를 주고받아야 + 합니다. 작은 작업 하나에도 라우팅 비용이 붙었습니다. + + +--- + +1. 진짜 병목은 모델 수가 아니었다 + + + 처음에는 더 많은 agent가 있으면 더 안정적일 것처럼 보였습니다. 구현은 + 구현자에게, 리뷰는 리뷰어에게, 계획은 계획자에게 맡기면 되니까요. 그런데 + 실제로 깨진 지점은 역할 부재가 아니라 상태 부재였습니다. + + + + 누가 지금 작업을 들고 있는지, 결과가 어디에 남았는지, 리뷰가 끝났는지, + 오케이징이 최종 보고 전에 확인했는지가 더 중요했습니다. agent가 많아도 이 + 상태가 남지 않으면 다음 세션에서 다시 헤맵니다. + + + + 그래서 방향이 바뀌었습니다. 더 많은 인격을 유지하는 대신, 하나의 Hermes 체계 + 안에 절차를 넣기로 했습니다. 오케이징은 Hermes의 사용자-facing 이름이 되고, + 우로보로스와 낫징은 각각 skill로 내려왔습니다. + + +--- + +2. 남긴 것과 버린 것 + + + 전환은 전부 버리는 작업이 아니었습니다. 오히려 이름과 개념은 꽤 많이 + 남겼습니다. 다만 위치가 바뀌었습니다. + + +| 구분 | 남긴 것 | 바뀐 것 | +| ---------- | ---------------- | ---------------------------- | +| 오케이징 | 진규-facing 이름 | Hermes 단일 체계의 이름이 됨 | +| 우로보로스 | 모호성 수렴 개념 | `ouroboros-planning` skill | +| 낫징 | 의심과 검문 개념 | `notjing-final-gate` skill | +| 작업 추적 | 티켓 기반 흐름 | 로컬 SQLite + Discord Forum | +| OpenClaw | 운영 실험의 맥락 | active runtime에서는 제외 | + + + 버린 것은 독립 인격처럼 보이는 계층입니다. 특히 OpenClaw가 앞에서 gateway와 + orchestration을 잡고, Hermes가 뒤에서 worker처럼 도는 구조는 현재 운영 현실과 + 맞지 않았습니다. Hermes 자체가 gateway, tool, memory, skill을 들고 있는데 그 + 위에 또 하나의 운영 레이어를 얹으면 중복이 됩니다. + + +--- + +3. migration에서 드러난 문제 + + + 구조를 옮기면서 가장 귀찮았던 건 코드보다 흔적이었습니다. memory에는 예전 + 경로가 남아 있었고, skill에도 `.openclaw` fallback이 남아 있었습니다. systemd + 쪽에는 죽은 OpenClaw gateway를 다시 살리려는 service와 timer 흔적도 + 있었습니다. + + + + 이때 배운 건 단순합니다. 시스템을 바꾸는 일은 새 구조를 만드는 것만이 + 아닙니다. 예전 구조가 다시 끼어들지 못하게 잔재를 줄이는 일까지 포함합니다. + 오케이징이 현재 repo path와 active runtime을 항상 확인해야 하는 이유도 여기서 + 나왔습니다. + + +--- + +4. 단일 체계가 단일 사고를 뜻하진 않는다 + + + Hermes 단일 체계로 정리했다고 해서 모든 판단을 한 덩어리로 뭉갠 것은 아닙니다. + 오히려 반대입니다. 실행 주체는 하나로 두고, 내부 절차를 더 명확히 나눴습니다. + + +```text +요구사항이 크거나 애매함 → ouroboros-planning +실제 작업 요청 → hermes-ticket +구현/수정 → Hermes tools +검증 → test/build/lint/typecheck +원격 반영 전 → notjing-final-gate +보고 → Hermes Report +``` + + + 이 구조는 겉으로는 덜 화려합니다. 다중 agent 팀처럼 보이지 않으니까요. 하지만 + 실제 운영에서는 이쪽이 낫습니다. 누가 책임자인지 분명하고, 어느 단계에서 + 상태가 남는지도 분명합니다. + + +--- + +5. 정리 + + + 오케이징이 Hermes가 된 이유는 단순히 시스템을 줄이기 위해서가 아닙니다. 책임의 + 중심을 하나로 만들기 위해서입니다. 여러 agent가 있는 것처럼 말하는 대신, + 하나의 오케이징이 계획하고, 실행하고, 검증하고, 보고합니다. 필요한 차이는 + 인격이 아니라 절차로 남깁니다. + diff --git a/apps/web/content/okayJing/memory/memory-backend-honcho-criteria.mdx b/apps/web/content/okayJing/memory/memory-backend-honcho-criteria.mdx new file mode 100644 index 0000000..1a82bcb --- /dev/null +++ b/apps/web/content/okayJing/memory/memory-backend-honcho-criteria.mdx @@ -0,0 +1,123 @@ +--- +title: "Honcho를 다시 검토할 때 — 오케이징의 장기 기억을 어디에 둘 것인가" +date: 2026-05-25 +tags: + - okayJing + - memory + - Honcho + - Mem0 + - Hermes +description: built-in memory로 충분한지, Honcho나 Mem0 같은 memory backend를 도입할 기준은 무엇인지 오케이징 운영 관점에서 정리합니다. +--- + + + 0. 예전에는 memory backend가 오버엔지니어링처럼 보였다 + + + + 한때 mem0나 Honcho 같은 memory backend를 검토한 적이 있었습니다. 대화 내용을 + 더 잘 기억하고, 사용자 선호를 자동으로 쌓고, 의미 기반으로 다시 꺼낼 수 있다는 + 점은 분명 매력적이었습니다. 그런데 당시 결론은 조심스러웠습니다. 문제는 기억이 + 부족한 게 아니라, 어디에 무엇을 남길지의 규율이 부족한 쪽에 가까웠습니다. + + + + 그래서 먼저 built-in memory, ticket, session_search의 역할을 나누는 쪽을 + 택했습니다. 오래 남길 규칙은 memory, 작업 상태는 ticket, 과거 대화는 + session_search. 이 구분이 잡히지 않은 상태에서 memory backend를 붙이면, 더 + 똑똑해지는 게 아니라 더 복잡해질 가능성이 컸습니다. + + +--- + +1. 지금 다시 검토할 이유 + + + 그런데 시간이 지나면 조건이 바뀝니다. 세션이 늘어나고, 오케이징이 다루는 + 프로젝트와 운영 규칙도 늘어납니다. 진규는 장기적으로 SNS/메신저 문체까지 + 오케이징이 학습해서 반영하길 원합니다. 이런 요구는 단순한 프로젝트 경로 + memory와는 조금 다릅니다. + + + + 장기적인 말투, 관계 맥락, 반복되는 의사결정 패턴은 built-in memory만으로 + 관리하기 어려울 수 있습니다. 특히 memory 용량을 압축하느라 중요한 뉘앙스가 + 사라지기 시작하면 외부 memory backend를 다시 볼 타이밍입니다. + + +--- + +2. backend 후보를 기능으로만 보면 안 된다 + + + memory backend를 고를 때 기능 목록만 보면 대부분 좋아 보입니다. 자동 추출, + semantic search, user profile, session memory 같은 말은 다 그럴듯합니다. + 하지만 오케이징에게 중요한 기준은 조금 다릅니다. + + +| 질문 | 봐야 하는 것 | +| --------------------------------- | -------------------------------------- | +| 잘못 저장된 기억을 고칠 수 있나 | 수정/삭제/감사 가능성 | +| 어떤 기억이 자동 주입되나 | 오염된 기억이 모든 답변에 영향 줄 위험 | +| ticket과 역할이 겹치지 않나 | 작업 상태를 memory로 착각할 위험 | +| session_search를 대체하려 하나 | 과거 대화 회수와 장기 선호는 다름 | +| 진규의 말투를 안정적으로 반영하나 | 스타일 학습과 사실 기억의 분리 | + + + 기억은 많을수록 좋은 게 아닙니다. 잘못된 기억은 없는 것보다 나쁠 때가 + 있습니다. 그래서 backend 도입 기준에는 저장보다 수정과 삭제가 더 중요하게 + 들어가야 합니다. + + +--- + +3. built-in memory로 충분한 경우 + + + 모든 문제에 외부 memory가 필요한 건 아닙니다. 프로젝트 경로, 보고 형식, no + commit/no push 같은 규칙은 지금 방식으로 충분합니다. 오히려 이런 건 짧고 + 명확한 built-in memory가 더 낫습니다. + + + + 과거 대화를 찾는 것도 session_search가 이미 맡고 있습니다. "전에 Jing + Factory에서 뭐 했지?" 같은 질문은 semantic memory보다 session_search 요약이 더 + 나을 때가 많습니다. 특정 세션의 맥락과 산출물을 같이 가져올 수 있기 + 때문입니다. + + +--- + +4. Honcho가 어울릴 수 있는 영역 + + + Honcho를 다시 본다면, 작업 상태 저장소가 아니라 관계와 선호의 장기 모델로 봐야 + 합니다. 진규가 어떤 톤을 좋아하는지, 어떤 종류의 보고를 싫어하는지, 어떤 + 상황에서 오케이징이 더 적극적으로 행동하길 원하는지 같은 영역입니다. + + + + 특히 문체 학습은 후보가 될 수 있습니다. 다만 이것도 raw 대화를 무작정 저장하는 + 방식이면 위험합니다. 스타일 샘플, 적용 규칙, 금지 표현처럼 구조화해서 저장해야 + 합니다. 오케이징이 기억해야 하는 건 모든 문장이 아니라, 반복되는 기준입니다. + + +--- + +5. 도입 기준 + + + 지금 당장 결론은 "도입한다"가 아니라 "도입 기준을 세운다"에 가깝습니다. 기준은 + 이렇게 잡을 수 있습니다. + + +1. built-in memory를 계속 압축해도 중요한 선호가 자주 밀려난다. +2. session_search로는 반복 선호와 관계 맥락을 매번 복구하기 어렵다. +3. 저장된 기억의 출처, 수정, 삭제가 명확하다. +4. ticket과 memory 역할이 섞이지 않는다. +5. gateway/config 변경 없이 안전하게 실험할 수 있다. + + + 이 조건이 맞을 때 Honcho나 다른 backend를 붙이는 게 좋습니다. 기술적으로 + 가능하다는 이유만으로 붙이면, 기억이 아니라 또 하나의 운영 부채가 됩니다. + diff --git a/apps/web/content/okayJing/memory/memory-ticket-session-search.mdx b/apps/web/content/okayJing/memory/memory-ticket-session-search.mdx new file mode 100644 index 0000000..b2a5682 --- /dev/null +++ b/apps/web/content/okayJing/memory/memory-ticket-session-search.mdx @@ -0,0 +1,112 @@ +--- +title: "오케이징의 기억은 하나가 아니다 — memory, ticket, session_search의 역할 분담" +date: 2026-05-21 +tags: + - okayJing + - memory + - ticket + - session_search + - Hermes +description: 오케이징이 장기 기억, 작업 상태, 과거 대화 검색을 서로 다른 저장소로 나눠 쓰는 이유를 정리합니다. +--- + +0. 기억한다고 말하면 너무 뭉뚱그려진다 + + + AI가 기억한다고 말하면 편하지만, 실제 운영에서는 너무 뭉뚱그린 표현입니다. + 오케이징에게 필요한 기억은 한 종류가 아닙니다. 진규의 선호처럼 오래 남아야 + 하는 것도 있고, 특정 작업이 끝나면 사라져도 되는 것도 있고, 과거 대화에서 다시 + 찾아야 하는 것도 있습니다. + + + + 이 셋을 한 곳에 넣으면 금방 망가집니다. memory에 작업 진행 로그를 넣으면 + 오래된 임시 상태가 계속 따라다니고, 티켓에 장기 선호를 넣으면 다음 작업에서 + 자동으로 떠오르지 않습니다. session_search에만 의존하면 매번 검색해야 합니다. + + +--- + +1. memory — 오래 남아야 하는 규칙 + + + memory는 가장 조심해서 써야 합니다. 여기에 들어간 정보는 다음 세션에도 계속 + 주입됩니다. 그래서 임시 작업 상태를 넣으면 안 됩니다. 대신 진규의 선호, + 프로젝트 경로, 운영 convention처럼 오래 가는 사실을 넣습니다. + + +| memory에 맞는 것 | memory에 맞지 않는 것 | +| ------------------------------- | ----------------------- | +| 진규는 한국어 구어체를 선호한다 | 오늘 A 파일 수정 중이다 | +| SEOJing repo 경로 | 이번 빌드가 실패했다 | +| commit/push는 명시 요청 전 금지 | 티켓 27번 진행률 | +| CLAB 보고 채널 ID | 방금 읽은 로그 전문 | + + + memory는 일기가 아니라 압축된 운영 사실입니다. 이 기준이 없으면 memory는 + 빠르게 오염됩니다. + + +--- + +2. ticket — 특정 작업의 상태 + + + ticket은 작업 상태를 담습니다. 지금 어떤 작업이 열려 있는지, blocker가 + 무엇인지, 최종 보고가 무엇인지, Discord thread와 어떻게 연결되는지가 여기에 + 들어갑니다. + + + + 티켓의 장점은 작업 단위로 닫을 수 있다는 점입니다. 작업이 끝나면 done이 되고, + 그 상태로 보관됩니다. 다음 세션에서 필요하면 다시 열어볼 수 있지만, 모든 + 대화에 항상 주입되지는 않습니다. 이게 memory와의 가장 큰 차이입니다. + + +--- + +3. session_search — 과거 대화 회수 + + + session_search는 기억이라기보다 회수 장치에 가깝습니다. 진규가 "전에 말했던 + 그거"를 꺼내거나, 오케이징이 이전에 비슷한 작업을 했던 것 같을 때 사용합니다. + 모든 걸 memory에 넣지 않아도 되는 이유가 여기에 있습니다. + + + + 예를 들어 오케이징 로직 변천사를 쓰려면 최근 세션에서 OpenClaw migration, + sessions Forum, 우로보로스 CLI, dreaming cron 같은 맥락을 다시 찾아야 합니다. + 이런 건 memory에 전부 넣기에는 너무 깁니다. 대신 session_search로 필요한 + 세션을 찾아 요약해서 가져오면 됩니다. + + +--- + +4. 세 저장소가 같이 움직일 때 + + + 실제 작업에서는 셋이 같이 쓰입니다. 진규가 작업을 요청하면 memory에서 프로젝트 + 경로와 선호를 가져오고, ticket에 작업 상태를 만들고, 필요하면 session_search로 + 과거 맥락을 회수합니다. + + +```text +memory: 이 프로젝트는 어디 있고, 어떤 규칙을 따라야 하지? +ticket: 지금 이 작업은 어느 상태지? +session_search: 예전에 비슷한 결정을 어떻게 했지? +``` + + + 이 역할 분담이 생기면서 오케이징은 "기억력이 좋아진" 게 아니라, 무엇을 어디에 + 남길지 조금 더 분명해졌습니다. 실제 운영에서는 그쪽이 더 중요합니다. + + +--- + +5. 정리 + + + 기억은 하나의 기능이 아니라 여러 저장소의 조합입니다. 오래 남길 사실은 memory, + 작업 상태는 ticket, 과거 대화는 session_search. 이 셋을 구분하는 것이 지금 + 오케이징의 컨텍스트 복구 방식입니다. + diff --git a/apps/web/content/okayJing/skills/notjing-final-gate.mdx b/apps/web/content/okayJing/skills/notjing-final-gate.mdx new file mode 100644 index 0000000..96afdc0 --- /dev/null +++ b/apps/web/content/okayJing/skills/notjing-final-gate.mdx @@ -0,0 +1,98 @@ +--- +title: "낫징은 리뷰어가 아니라 검문소가 됐다 — final gate로 재정의한 이유" +date: 2026-05-20 +tags: + - okayJing + - Notjing + - Hermes + - review + - skill +description: 독립 리뷰어처럼 다루던 낫징을 commit, push, PR 전 최종 검문 루틴으로 바꾼 이유를 정리합니다. +--- + +0. 처음 낫징은 리뷰어였다 + + + 낫징은 원래 의심하는 역할이었습니다. Hermes가 코드를 고치면 낫징이 한 번 더 + 보고, 오케이징은 그 결과를 받아 진규에게 전달하는 흐름을 생각했습니다. + 구현자와 리뷰어를 분리하면 안전해질 것 같았습니다. + + + + 이 생각 자체는 아직도 맞습니다. 자동 작업에는 의심하는 단계가 필요합니다. 다만 + 낫징을 항상 별도 인격이나 별도 agent처럼 유지하는 방식은 무거웠습니다. 작은 + 수정에도 리뷰 라우팅이 붙고, 보고 채널이 늘고, 최종 책임이 흐려졌습니다. + + +--- + +1. 리뷰는 인격보다 절차에 가깝다 + + + 실제로 필요한 것은 "낫징이라는 누군가"가 아니라, 원격 반영 전에 반드시 + 통과해야 하는 검문이었습니다. diff를 봤는지, 테스트를 돌렸는지, secret이 + 섞이지 않았는지, main branch에 위험한 작업을 하지 않았는지 확인하는 + 절차입니다. + + + + 그래서 낫징은 `notjing-final-gate` skill로 재정의됐습니다. 이름은 남아 있지만, + 역할은 final review gate입니다. 오케이징이 작업을 소유하고, push나 PR 같은 + 원격 handoff 직전에 낫징식 검문을 통과합니다. + + +--- + +2. final gate에서 보는 것 + + + final gate는 단순히 "괜찮아 보인다"고 말하는 단계가 아닙니다. 확인해야 할 + 목록이 있습니다. + + +| 항목 | 확인 이유 | +| -------------------------- | ---------------------------------- | +| git diff | 의도하지 않은 파일 변경 확인 | +| tests/build/lint/typecheck | 실제로 깨지지 않았는지 확인 | +| secret scan | 토큰이나 개인 정보 유출 방지 | +| destructive change | 삭제/force push 등 위험 작업 차단 | +| report completeness | 진규가 다음 결정을 할 수 있게 정리 | +| no commit/no push | 명시 승인 없는 원격 반영 방지 | + + + 이 중 하나라도 빠지면 final gate가 아닙니다. 특히 commit/push/PR은 진규가 + 명시하기 전까지 하지 않는다는 규칙이 중요합니다. 오케이징은 파일을 고칠 수 + 있지만, 원격에 반영하는 마지막 문은 사람이 열어야 합니다. + + +--- + +3. 항상 부르지 않는 이유 + + + 모든 답변에 final gate를 붙이면 시스템이 둔해집니다. 블로그 주제 리스트업이나 + 단순 설명에는 낫징이 필요 없습니다. final gate는 원격 handoff 직전, 혹은 + 위험도가 큰 변경을 마무리할 때 쓰는 게 맞습니다. + + + + 이 기준은 오케이징의 전체 방향과도 맞습니다. 인격을 늘리는 게 아니라 절차를 + 필요한 곳에 붙입니다. 리뷰라는 절차가 항상 중요하긴 하지만, 모든 순간에 같은 + 무게로 필요한 것은 아닙니다. + + +--- + +4. 낫징이 남긴 태도 + + + 낫징을 skill로 낮췄다고 해서 의심이 사라진 건 아닙니다. 오히려 더 + 선명해졌습니다. 이제 낫징은 "누가 리뷰했는가"가 아니라 "어떤 검문을 + 통과했는가"로 남습니다. + + + + 자동화에서 중요한 건 가끔 똑똑한 리뷰어가 등장하는 게 아니라, 위험한 순간마다 + 같은 기준이 반복되는 것입니다. 낫징은 그 반복 기준입니다. 오케이징이 스스로를 + 의심하는 방식이라고 볼 수 있습니다. + diff --git a/apps/web/content/okayJing/skills/ouroboros-planning-skill.mdx b/apps/web/content/okayJing/skills/ouroboros-planning-skill.mdx new file mode 100644 index 0000000..56cc939 --- /dev/null +++ b/apps/web/content/okayJing/skills/ouroboros-planning-skill.mdx @@ -0,0 +1,129 @@ +--- +title: "우로보로스는 사라지지 않았다 — planning skill로 남은 이유" +date: 2026-05-19 +tags: + - okayJing + - Ouroboros + - Hermes + - planning + - skill +description: 과거 별도 계획자처럼 다루던 우로보로스를 Hermes 내부 planning discipline으로 흡수한 이유를 정리합니다. +--- + +0. 우로보로스의 핵심은 모호성 수렴이었다 + + + 우로보로스를 처음 떠올렸을 때 핵심은 계획 자체가 아니었습니다. 더 정확히는 + 모호성을 줄이는 루프였습니다. 진규의 요청이 아직 흐릿할 때, 질문과 가정과 성공 + 기준을 통해 실행 가능한 형태로 접어 넣는 역할입니다. + + +```text +애매한 요청 +→ 질문 / 가정 / 제약 / 성공 기준 정리 +→ 실행 가능한 계획 +→ 작업 중 드리프트 확인 +→ 결과 검증 후 다시 수렴 +``` + + + 이 흐름은 여전히 필요합니다. 다만 꼭 별도 agent로 있어야 하는지는 다른 + 문제였습니다. + + +--- + +1. 별도 agent로 두면 생기는 비용 + + + 계획자가 따로 있으면 좋아 보입니다. 구현 전에 한 번 멈추고, 요구사항을 + 정리하고, 작업 범위를 정할 수 있습니다. 그런데 실제 운영에서는 계획자와 실행자 + 사이의 연결도 관리해야 합니다. 계획은 어디에 저장되는지, 실행자가 최신 계획을 + 읽었는지, 중간에 진규가 말을 바꾸면 누가 반영하는지 같은 문제가 생깁니다. + + + + 작은 작업에서는 이 비용이 더 크게 느껴집니다. 버튼 하나 고치는 작업에 별도 + 계획 agent를 띄우면 오히려 느려집니다. 그래서 우로보로스는 독립 실행자가 + 아니라 오케이징 안의 planning discipline으로 내려오는 쪽이 맞았습니다. + + +--- + +2. 지금의 `ouroboros-planning` + + + 지금 우로보로스는 Hermes skill입니다. 이름은 `ouroboros-planning`이고, + 쓰임새는 명확합니다. 요구사항이 크거나 애매할 때, 바로 구현하지 않고 먼저 + 목표와 성공 기준, non-goal, 위험 요소, 검증 방법을 정리합니다. + + +| 항목 | 현재 역할 | +| ---------- | ------------------------------------ | +| 실행 주체 | 오케이징/Hermes | +| 우로보로스 | planning skill | +| 산출물 | 짧은 실행 계획과 드리프트 체크 | +| 저장 위치 | 대화, 티켓, 필요 시 파일 | +| 사용 시점 | 큰 작업, 애매한 작업, 다중 파일 수정 | + + + 중요한 건 말투입니다. 우로보로스가 따로 말하는 것처럼 쓰지 않습니다. + 오케이징이 우로보로스식 계획 루틴을 사용하는 것입니다. 이 차이를 정리하지 + 않으면 다시 다중 인격 구조로 돌아갑니다. + + +--- + +3. 실제 Ouroboros CLI와의 차이 + + + 진규 환경에는 실제 `ouroboros` CLI도 있습니다. 이건 skill과 다릅니다. CLI는 + 별도 workflow와 상태를 갖고, `init`, `pm`, `auto` 같은 명령으로 요구사항 + 인터뷰나 PRD 생성을 더 길게 가져갈 수 있습니다. + + +| 구분 | `ouroboros-planning` skill | 실제 `ouroboros` CLI | +| ----------- | -------------------------- | ---------------------------- | +| 속도 | 빠름 | 상대적으로 무거움 | +| 상태 | Hermes 대화/티켓 안 | `.ouroboros` DB와 로그 | +| 적합한 작업 | 일반 구현 전 계획 | 제품 기획, 대형 구조 변경 | +| 장점 | 현재 맥락에 바로 붙음 | 별도 workflow로 깊게 수렴 | +| 단점 | 장기 PRD 관리에는 약함 | Hermes 티켓과 연결 규칙 필요 | + + + 그래서 지금 기준은 단순합니다. 일반 작업은 skill로 충분합니다. 제품 하나를 + 새로 만들거나, 여러 repo에 걸친 큰 개편처럼 요구사항 인터뷰가 필요한 경우에는 + 실제 CLI를 붙이는 쪽을 검토합니다. + + +--- + +4. planning은 작업을 늦추기 위한 게 아니다 + + + planning skill을 넣었다고 해서 매번 긴 문서를 쓰자는 뜻은 아닙니다. 오히려 + 반대에 가깝습니다. 애매한 상태로 바로 구현했다가 나중에 되돌리는 시간을 줄이기 + 위한 장치입니다. + + + + 좋은 planning은 짧아야 합니다. 목표, 현재 맥락, 가정, 안 할 것, 성공 기준, + 실행 단계, 검증 정도면 충분합니다. 철학적 결론보다 바로 실행 가능한 다음 + 단계가 중요합니다. + + +--- + +5. 남은 기준 + + + 우로보로스는 사라진 게 아닙니다. 더 작은 위치로 내려왔습니다. 독립 인격으로 + 유지하기보다, 오케이징이 애매함을 줄일 때 쓰는 도구가 됐습니다. 이게 지금 + 구조에 더 잘 맞습니다. + + + + 앞으로 진짜 Ouroboros CLI를 다시 붙인다면, 그것도 같은 원칙을 따라야 합니다. + agent를 하나 더 늘리는 게 목적이 아니라, 요구사항을 더 안정적으로 수렴하기 + 위해서여야 합니다. + diff --git a/apps/web/content/okayJing/workflow/hermes-report-format.mdx b/apps/web/content/okayJing/workflow/hermes-report-format.mdx new file mode 100644 index 0000000..c47c6a1 --- /dev/null +++ b/apps/web/content/okayJing/workflow/hermes-report-format.mdx @@ -0,0 +1,132 @@ +--- +title: "Hermes Report는 왜 생겼나 — 끝났다고 말하기 위한 조건" +date: 2026-05-28 +tags: + - okayJing + - Hermes + - report + - workflow + - 운영 +description: 오케이징이 작업 결과를 한국어 Hermes Report 형식으로 남기게 된 이유와, 보고가 단순 요약이 아니라 인수인계 문서가 되는 과정을 정리합니다. +--- + +0. 자연어 보고만으로는 부족했다 + + + 처음에는 작업이 끝나면 자연스럽게 요약하면 된다고 생각했습니다. "수정했어", + "빌드도 통과했어", "이 파일 바뀌었어" 정도면 충분해 보였습니다. 짧은 + 작업에서는 실제로 괜찮았습니다. + + + + 그런데 작업이 커지면 문제가 생깁니다. 무엇을 바꿨는지, 어떤 검증을 했는지, + 무엇을 하지 않았는지, 다음에 진규가 뭘 결정해야 하는지가 한 문단 안에 + 섞입니다. 나중에 티켓만 보고 작업을 복구하려고 하면 정보가 부족합니다. 보고가 + 예쁘게 쓰였는지가 아니라, 다시 이어받을 수 있는지가 중요해졌습니다. + + +--- + +1. 보고는 인수인계 문서다 + + + Hermes Report는 이 문제에서 나왔습니다. 오케이징이 작업을 끝냈다고 말하려면 + 최소한 같은 항목을 반복해서 남겨야 합니다. 그래야 진규도 빠르게 확인할 수 + 있고, 다음 세션의 오케이징도 같은 작업을 다시 열었을 때 상태를 이해할 수 + 있습니다. + + +```text +## Hermes Report +Task: <작업> +Project: <프로젝트> +Status: +Summary: +- ... +Changes: +- ... +Checks: +- tests: ... +- build: ... +- lint/typecheck: ... +- notjing gate: ... +Blockers: +- ... +Next: +- ... +``` + + + 형식은 단순하지만 효과는 큽니다. 보고자가 달라져도 같은 위치에 같은 정보가 + 들어갑니다. 특히 Checks와 Blockers가 분리되는 게 중요합니다. 검증을 했는지 안 + 했는지, 안 했다면 왜 안 했는지가 흐려지지 않습니다. + + +--- + +2. Status가 먼저 나와야 하는 이유 + + + 보고에서 가장 먼저 봐야 하는 건 상태입니다. done인지, partial인지, + blocked인지가 먼저 나와야 합니다. 긴 설명을 다 읽고 나서야 "그래서 끝난 + 거야?"를 알게 되면 보고의 역할을 못 한 것입니다. + + +| Status | 의미 | +| ------- | -------------------------------------- | +| done | 요청 범위 완료, 검증까지 수행 | +| partial | 일부 완료, 남은 작업 있음 | +| blocked | 필요한 정보/권한/외부 상태가 없어 중단 | + + + blocked를 솔직히 쓰는 것도 중요합니다. 막힌 작업을 done처럼 포장하면 다음 + 작업이 더 꼬입니다. 오케이징은 막히면 필요한 정보를 말하고 멈춰야 합니다. + + +--- + +3. Checks는 신뢰의 근거다 + + + "수정했다"와 "검증했다"는 다릅니다. 특히 코드 작업에서는 build, lint, test, + typecheck 중 무엇을 돌렸는지 남겨야 합니다. 문서 작업이어도 build와 format + check는 의미가 있습니다. MDX가 깨지면 블로그는 빌드되지 않기 때문입니다. + + + + Checks에 skipped가 들어갈 수도 있습니다. 중요한 건 숨기지 않는 것입니다. + 테스트가 없어서 못 돌렸는지, 변경 범위상 생략했는지, 시간이 없어서 못 + 돌렸는지에 따라 다음 판단이 달라집니다. + + +--- + +4. Discord 보고와 ticket report의 차이 + + + Discord에 보내는 보고는 사람이 읽기 좋아야 합니다. ticket report는 나중에 + 복구하기 좋아야 합니다. 둘은 비슷하지만 완전히 같지는 않습니다. Discord에는 + 핵심 요약을 적고, ticket에는 조금 더 구조화된 작업 결과를 남기는 편이 + 좋습니다. + + + + 다만 둘 다 같은 Hermes Report 구조를 공유하면 좋습니다. 형식이 같으면 어디서 + 읽어도 빠르게 파악할 수 있습니다. 오케이징의 보고 형식이 고정된 이유가 여기 + 있습니다. + + +--- + +5. 정리 + + + Hermes Report는 꾸미기 위한 형식이 아닙니다. 작업을 닫기 위한 조건입니다. + 무엇을 했고, 무엇을 바꿨고, 무엇으로 검증했고, 무엇이 남았는지를 같은 순서로 + 남기기 위한 장치입니다. + + + + 오케이징이 "끝났다"고 말하려면, 다음 세션의 오케이징이 그 보고만 보고도 + 이어받을 수 있어야 합니다. 보고는 마지막 인사가 아니라 인수인계입니다. + diff --git a/apps/web/content/okayJing/workflow/hermes-ticket-memory.mdx b/apps/web/content/okayJing/workflow/hermes-ticket-memory.mdx new file mode 100644 index 0000000..a6821ad --- /dev/null +++ b/apps/web/content/okayJing/workflow/hermes-ticket-memory.mdx @@ -0,0 +1,117 @@ +--- +title: "hermes-ticket — 오케이징의 작업 기억 장치" +date: 2026-05-16 +tags: + - okayJing + - Hermes + - ticket + - SQLite + - 운영 +description: Discord thread만으로는 부족했던 작업 상태를 로컬 SQLite 티켓 시스템으로 남기게 된 이유를 정리합니다. +--- + +0. Discord thread만으로는 부족했다 + + + Discord Forum thread는 사람이 보기 좋습니다. 제목이 있고, 댓글이 쌓이고, + 태그도 붙습니다. 처음에는 이것만으로도 충분해 보였습니다. 작업마다 thread를 + 만들고, 그 안에 결과를 남기면 되니까요. + + + + 그런데 오케이징 입장에서는 조금 다릅니다. 사람은 thread 목록을 눈으로 보면 + 되지만, 오케이징은 안정적으로 조회하고 갱신할 수 있는 상태 저장소가 + 필요합니다. Discord 메시지 자체를 DB처럼 쓰기 시작하면 금방 애매해집니다. 어떤 + 댓글이 최종 보고인지, 현재 상태가 무엇인지, 로컬 repo와 어떤 branch가 연결되어 + 있는지 매번 다시 해석해야 합니다. + + +--- + +1. 그래서 local ticket first가 됐다 + + + 지금 원칙은 로컬 티켓이 먼저입니다. `hermes-ticket add`로 SQLite DB에 작업을 + 만들고, 필요하면 `hermes-ticket discord sync`로 Discord thread를 붙입니다. + Discord가 겉으로 보이는 작업장이라면, SQLite 티켓은 오케이징이 읽는 작업 + 원장입니다. + + +```text +진규의 실행 요청 +→ hermes-ticket 로컬 티켓 생성 +→ 필요하면 Discord tickets Forum에 sync +→ 작업 시작 / 진행 / blocker / report 기록 +→ 완료 처리 +``` + + + 이 구조가 생기면서 Discord는 presentation layer에 가까워졌습니다. 물론 진규가 + 확인하기에는 Discord가 훨씬 편합니다. 하지만 오케이징이 작업을 이어받고 + 복구하는 기준은 로컬 티켓입니다. + + +--- + +2. 티켓에 남기는 것 + + + 티켓은 단순한 TODO가 아닙니다. 오케이징이 작업을 다시 잡을 때 필요한 최소 + 상태를 담습니다. + + +| 필드 | 의미 | +| ----------------- | ---------------------------------- | +| id | 작업을 다시 부를 수 있는 고정 번호 | +| title | 사람이 읽는 작업 이름 | +| project | 어떤 프로젝트인지 | +| repo / branch | 어느 코드베이스의 어느 branch인지 | +| status | inbox, in_progress, blocked, done | +| priority | 작업 우선순위 | +| tags | 검색과 분류 | +| report | 최종 작업 보고 | +| Discord thread id | 외부 thread와 연결 | + + + 이렇게 남겨두면 세션이 끊겨도 다시 시작할 수 있습니다. "어제 그 작업"이 아니라 + "티켓 27번"이 됩니다. 이 차이가 큽니다. + + +--- + +3. memory와 ticket은 다르다 + + + 처음에는 memory에 더 많이 넣고 싶어질 때가 있었습니다. 하지만 memory는 작업 + 로그가 아닙니다. memory에는 오래 남아야 할 사실만 들어가야 합니다. 예를 들어 + 진규의 선호, 프로젝트 경로, no commit/no push 같은 운영 규칙입니다. + + + + 반면 티켓은 특정 작업의 상태입니다. "SEOJing okayJing 글 작성 중" 같은 건 + memory에 넣으면 안 됩니다. 작업이 끝나면 의미가 사라지는 정보이기 때문입니다. + 그런 건 ticket report에 남기는 게 맞습니다. + + +| 저장소 | 넣어야 하는 것 | +| -------------- | ---------------------------- | +| memory | 장기 규칙, 선호, 고정 경로 | +| ticket | 특정 작업의 진행 상태와 결과 | +| session_search | 과거 대화의 맥락 회수 | + +--- + +4. 작은 명령 하나도 운영 규칙이 된다 + + + 실제로 `hermes-ticket create`를 썼다가 실패한 적이 있습니다. 맞는 명령은 + `hermes-ticket add`였습니다. 작은 실수처럼 보이지만, 이런 게 반복되면 운영 + 규칙이 됩니다. 도구를 기억으로 때우지 말고 help를 확인해야 합니다. 그리고 한 + 번 확인한 내용은 skill이나 memory에 맞게 정리해야 합니다. + + + + hermes-ticket은 거창한 시스템이라기보다, 오케이징이 자기 작업을 잃어버리지 + 않기 위한 최소한의 장치입니다. 채팅은 흘러가지만 티켓은 남습니다. 지금 + 구조에서 작업 기억의 중심은 이쪽입니다. + diff --git a/apps/web/content/okayJing/workflow/msw-dto-backend-handoff.mdx b/apps/web/content/okayJing/workflow/msw-dto-backend-handoff.mdx new file mode 100644 index 0000000..73e717b --- /dev/null +++ b/apps/web/content/okayJing/workflow/msw-dto-backend-handoff.mdx @@ -0,0 +1,267 @@ +--- +title: "MSW를 켜는 순간 백엔드 요구사항이 보인다 — DTO부터 남기는 프로토타입 흐름" +date: 2026-05-30 +tags: + - okayJing + - JingStudio + - MSW + - DTO + - backend + - workflow +description: Jing Studio에서 MSW mock API를 단순 목업 도구가 아니라 백엔드 요구사항 분석과 DTO 정리를 위한 실행 가능한 계약으로 다루게 된 과정을 정리합니다. +--- + +0. 백엔드는 나중 문제가 아니었다 + + + 처음에는 Jing Studio를 프론트 프로토타입 흐름으로 생각했습니다. 아이디어를 + product brief로 정리하고, 화면을 나누고, mock data를 넣고, React로 만져볼 수 + 있게 만드는 구조입니다. 이 정도만 해도 충분히 쓸모 있어 보였습니다. + + + + 그런데 진규가 원하는 방향은 조금 더 정확했습니다. 단순히 화면을 보는 게 + 아니라, 나중에 백엔드 연동을 쉽게 하고 싶었습니다. 프론트 프로토타입이 끝났을 + 때 백엔드 작업자가 "그래서 어떤 API를 만들면 되지?"라고 다시 물어보는 구조면 + 부족합니다. + + + + 이 지점에서 기준이 바뀌었습니다. 백엔드는 나중에 붙이는 덩어리가 아니라, + 프로토타입을 만들 때부터 요구사항과 DTO 형태로 같이 드러나야 합니다. + + +--- + +1. 화면에서 출발하되, DTO에서 멈춰야 한다 + + + 제품 아이디어를 받으면 가장 먼저 보이는 건 화면입니다. 홈에는 어떤 카드가 + 있어야 하고, 결과 화면에는 어떤 리스트가 있어야 하고, 상세 화면에는 어떤 + 액션이 있어야 하는지가 먼저 떠오릅니다. 이건 자연스럽습니다. 사용자가 보는 건 + 화면이기 때문입니다. + + + + 하지만 구현으로 들어가기 전에 한 번 멈춰야 합니다. 이 화면이 필요한 데이터는 + 무엇인지, 그 데이터가 서버에서 내려와야 하는지, 프론트에서 계산하면 되는지, + request에는 어떤 입력이 들어가야 하는지 정리해야 합니다. 이 멈춤 지점이 + `dto-spec.ts`입니다. + + +```ts +// API Response DTO +export type RecommendationResponseDto = { + id: string; + targetId: string; + title: string; + matchScore: number; + matchReasons: string[]; +}; + +// Frontend ViewModel +export type RecommendationCardViewModel = { + id: string; + title: string; + scoreLabel: string; + reasonSummary: string; +}; +``` + + + 두 타입은 비슷해 보이지만 역할이 다릅니다. DTO는 서버와 맞출 계약이고, + ViewModel은 화면 표현입니다. `scoreLabel`처럼 "92점 매칭"으로 보여줄 문자열은 + 프론트에서 만들 수 있습니다. 반대로 `matchScore` 자체는 서버가 내려줘야 할 + 가능성이 큽니다. + + +--- + +2. MSW handler는 API 문서의 실행 버전이다 + + + `api-contract.md`에 endpoint를 적는 것만으로는 부족합니다. 문서는 읽을 수는 + 있지만, 프론트 코드가 그 계약을 실제로 지키는지 바로 확인하기 어렵습니다. MSW + handler는 이 문서를 실행 가능한 형태로 바꿉니다. + + +```ts +import { http, HttpResponse } from "msw"; +import { mockRecommendations } from "../data/recommendations.mock"; + +export const recommendationHandlers = [ + http.post("/api/recommendations", async ({ request }) => { + const body = await request.json(); + + if (!Array.isArray(body.interests) || body.interests.length === 0) { + return HttpResponse.json( + { + code: "VALIDATION_ERROR", + message: "관심사는 최소 1개 이상 필요합니다.", + fieldErrors: { + interests: ["관심사를 선택해주세요."], + }, + }, + { status: 400 }, + ); + } + + return HttpResponse.json({ recommendations: mockRecommendations }); + }), +]; +``` + + + 이런 handler가 있으면 프론트는 처음부터 실패 케이스를 만납니다. 관심사를 안 + 골랐을 때 400이 오는지, 에러 메시지를 어디서 보여줄지, 빈 결과는 어떻게 + 표현할지 바로 확인할 수 있습니다. 실제 서버가 없어도 API처럼 사고하게 됩니다. + + + + 이게 이번 변경에서 MSW를 중요하게 둔 이유입니다. MSW는 화면을 속이는 도구가 + 아니라, API 계약을 빨리 깨뜨려보는 도구입니다. + + +--- + + + 3. mock data plan에는 정상 데이터만 있으면 안 된다 + + + + 더미 데이터를 만들 때 자주 하는 실수가 있습니다. 가장 예쁘게 보이는 정상 + 데이터만 넣는 것입니다. 카드가 세 개 있고, 제목이 적당히 길고, 이미지도 있고, + 점수도 잘 나옵니다. 데모 화면은 예쁩니다. 그런데 실제 서비스는 정상 데이터만 + 오지 않습니다. + + + + 그래서 Jing Studio에는 `mock-data-plan.md`를 추가했습니다. 이 문서는 fixture를 + 만들기 전에 어떤 상태를 검증할지 먼저 적는 역할을 합니다. + + +```text +Required scenarios +- Happy path +- Empty state +- Loading / slow response +- Validation error +- Server error +- Auth / permission state +- Edge cases +``` + + + 특히 backend requirements까지 생각하면 validation error와 permission state가 + 중요합니다. 프론트가 버튼을 막는다고 해서 서버 validation이 사라지는 것은 + 아닙니다. 반대로 서버가 막는다고 해서 프론트 UX가 필요 없는 것도 아닙니다. 둘 + 다 필요합니다. + + +--- + + + 4. backend-requirements.md는 백엔드 팀에게 넘기는 손잡이다 + + + + 프론트 프로토타입이 어느 정도 완성되면 백엔드로 넘어갈 수 있어야 합니다. 이때 + 필요한 건 "이 화면처럼 만들어주세요"가 아닙니다. 어떤 API가 필요하고, 어떤 + DTO가 오가고, 어떤 validation과 business rule이 있는지입니다. + + + + 그래서 `backend-requirements.md`를 기본 산출물로 추가했습니다. + + +```text +backend-requirements.md +- Required APIs +- Business rules +- Validation rules +- Auth and permissions +- Persistence candidates +- External integrations / jobs +- Error model +- Backend open questions +``` + + + 이 문서가 있으면 백엔드 작업을 시작할 때 대화가 달라집니다. "이 기능 만들어야 + 해요"가 아니라 "이 endpoint가 필요하고, request는 이 DTO이고, response는 이 + 모양이며, 이 validation은 서버에서 보장해야 합니다"로 시작할 수 있습니다. + + + + 진규가 백엔드를 배우려는 관점에서도 이게 중요합니다. 백엔드 레포 구조를 바로 + 외우는 것보다, 요구사항이 API와 DTO로 어떻게 내려오는지 보는 게 먼저입니다. 그 + 흐름이 보여야 controller, service, repository의 책임도 덜 추상적으로 + 느껴집니다. + + +--- + +5. 실제 구현 폴더도 계약 중심으로 잡는다 + + + 문서만 남기고 코드 구조가 따로 놀면 다시 흐려집니다. 그래서 implementation + brief 템플릿에도 폴더 기준을 넣었습니다. + + +```text +src/ + features/ + recommendation/ + api/ + recommendation-api.ts + recommendation-dto.ts + model/ + recommendation-mappers.ts + recommendation-types.ts + ui/ + RecommendationCard.tsx + + mocks/ + browser.ts + handlers.ts + handlers/ + recommendation.handlers.ts + data/ + recommendations.mock.ts +``` + + + 핵심은 API client, DTO, mapper, UI를 섞지 않는 것입니다. API client는 서버와 + 통신하는 경계고, DTO는 그 경계의 타입입니다. mapper는 DTO를 화면에 맞는 모델로 + 바꿉니다. UI는 ViewModel을 받아 렌더링합니다. MSW handler는 같은 endpoint를 + 가로채서 mock response를 줄 뿐입니다. + + + + 이렇게 잡으면 실제 API로 바꿀 때 할 일이 줄어듭니다. handler를 끄고 base URL을 + 바꿔도, 컴포넌트가 사용하는 API client와 mapper 경계는 유지됩니다. + + +--- + +6. 정리 + + + 이번 Jing Studio 변경은 "MSW를 추가했다" 정도의 작업이 아니었습니다. 더 정확히 + 말하면, 프로토타입을 만들 때 백엔드 요구사항이 같이 드러나도록 흐름을 바꾼 + 작업이었습니다. + + + + 화면은 여전히 중요합니다. 하지만 화면만 있으면 나중에 다시 해석해야 합니다. + DTO와 API contract, MSW handler, backend requirements가 같이 있으면 해석할 + 여지가 줄어듭니다. 프론트는 실제 API처럼 개발하고, 백엔드는 구현해야 할 계약을 + 봅니다. + + + + 앞으로 징팩토리에서 아이디어를 하나 돌린다면, 결과물은 단순히 "예쁜 목업"이 + 아니어야 합니다. 눌러볼 수 있는 화면, 갈아끼울 수 있는 MSW mock API, 백엔드가 + 받을 수 있는 DTO와 요구사항이 같이 나와야 합니다. 그 정도가 되어야 아이디어가 + 프로토타입에서 실제 구현으로 넘어갈 수 있습니다. + diff --git a/apps/web/content/okayJing/workflow/sessions-and-tickets.mdx b/apps/web/content/okayJing/workflow/sessions-and-tickets.mdx new file mode 100644 index 0000000..cd72d4c --- /dev/null +++ b/apps/web/content/okayJing/workflow/sessions-and-tickets.mdx @@ -0,0 +1,108 @@ +--- +title: "채팅은 세션으로, 작업은 티켓으로 — Discord Forum을 둘로 나눈 이유" +date: 2026-05-15 +tags: + - okayJing + - Discord + - Hermes + - 티켓 + - 세션 +description: 오케이징이 Discord에서 자연어 대화 공간과 실제 작업 추적 공간을 분리한 이유를 정리합니다. +--- + +0. 처음에는 전부 채팅이었다 + + + 처음에는 대화와 작업이 같은 공간에 있었습니다. 진규가 질문을 하고, 오케이징이 + 답하고, 중간에 코드 작업도 열고, 결과도 같은 흐름에 남겼습니다. 짧은 + 작업에서는 이게 편합니다. 굳이 티켓을 만들 필요도 없고, 그냥 대화하다가 바로 + 고치면 됩니다. + + + + 그런데 작업이 길어지면 바로 문제가 보였습니다. 일반 질문, 아이디어 정리, 실제 + 파일 수정, 작업 결과, 리뷰 요청이 한 thread 안에 섞입니다. 나중에 "그래서 이 + 작업 지금 어디까지 됐지?"를 물으면, 오케이징은 대화 전체를 다시 훑어야 합니다. + 컨텍스트가 끊기면 더 힘들어집니다. + + +--- + +1. sessions Forum의 역할 + + + 그래서 Discord에 자연어 대화용 Forum을 따로 뒀습니다. 지금 이 글을 만들게 된 + 대화도 sessions Forum에서 시작했습니다. 이 공간은 작업장이 아니라 대화방에 + 가깝습니다. + + +| 상황 | sessions에서 처리 | +| --------------------- | ------------------ | +| 개념 질문 | 바로 답변 | +| 아이디어 브레인스토밍 | 티켓 없이 정리 | +| 블로그 주제 리스트업 | 대화로 처리 | +| 운영 방향 상담 | 필요한 만큼 논의 | +| 실제 구현 요청 | 그때 티켓으로 전환 | + + + 핵심은 모든 대화를 작업으로 취급하지 않는 것입니다. 진규가 "이거 어떻게 + 생각해?" 라고 물었는데 매번 티켓이 생기면, 티켓 시스템은 금방 소음이 됩니다. + sessions는 그 소음을 막기 위한 완충지대입니다. + + +--- + +2. tickets Forum의 역할 + + + 반대로 tickets Forum은 실제 작업을 위한 공간입니다. 파일을 고치거나, 설정을 + 바꾸거나, 검증 명령을 실행하거나, 나중에 결과를 다시 찾아야 하는 일은 티켓으로 + 들어갑니다. 티켓은 대화의 연장이 아니라 작업의 단위입니다. + + + + 티켓이 생기면 상태가 생깁니다. inbox, in_progress, blocked, done 같은 상태가 + 붙고, 보고서와 blocker가 남습니다. Discord thread는 사람이 보기 좋고, + `hermes-ticket` 로컬 DB는 오케이징이 다시 조회하기 좋습니다. 둘을 같이 쓰는 + 이유가 여기 있습니다. + + +--- + +3. 분리 기준은 의도보다 side effect다 + + + 처음에는 "작업해줘" 같은 표현을 기준으로 생각했습니다. 물론 지금도 이 표현들은 + 중요합니다. 하지만 더 본질적인 기준은 side effect입니다. 답변만 하면 끝나는지, + 아니면 repo나 설정이나 외부 상태를 실제로 바꾸는지가 더 중요합니다. + + +| 요청 | 처리 | +| -------------------------- | ----------------------------- | +| "블로그 주제 리스트업해줘" | sessions 대화 | +| "이 내용으로 글 작성해줘" | 티켓 생성 후 파일 수정 | +| "이 코드 왜 이래?" | 먼저 확인, 단순 설명이면 대화 | +| "수정해줘" | 티켓 생성 | +| "배포해줘" | 티켓 생성, 승인 범위 확인 | + + + 이 기준 덕분에 오케이징은 과하게 티켓을 만들지 않으면서도, 실제 작업은 놓치지 + 않을 수 있습니다. 대화와 실행 사이에 문턱을 하나 둔 셈입니다. + + +--- + +4. 얻은 것 + + + sessions와 tickets를 나누면서 가장 좋아진 건 복구 가능성입니다. 대화가 + 길어져도 작업 상태는 티켓에 남습니다. 세션이 끊겨도 티켓을 열면 지금 상태를 + 다시 볼 수 있습니다. 진규는 채팅에서 편하게 말하고, 오케이징은 실행 요청이 + 되는 순간 작업 추적 모드로 전환합니다. + + + + 결국 이 분리는 UX라기보다 운영 규칙입니다. 채팅은 흐르고, 작업은 남아야 + 합니다. 이 기준이 생긴 뒤부터 오케이징은 "무엇을 답할지"뿐 아니라 "무엇을 + 상태로 남길지"를 같이 판단하게 됐습니다. + diff --git a/apps/web/content/okayJing/workflow/ticket-trigger-logic.mdx b/apps/web/content/okayJing/workflow/ticket-trigger-logic.mdx new file mode 100644 index 0000000..6b86403 --- /dev/null +++ b/apps/web/content/okayJing/workflow/ticket-trigger-logic.mdx @@ -0,0 +1,130 @@ +--- +title: "오케이징은 언제 티켓을 여는가 — 자연어와 실행 요청 사이의 경계" +date: 2026-05-17 +tags: + - okayJing + - Hermes + - ticket + - 자연어 + - 운영 +description: 오케이징이 일반 대화와 실제 작업 요청을 어떻게 구분하는지, 티켓 생성 판단 기준을 정리합니다. +--- + +0. 모든 요청이 작업은 아니다 + + + 진규가 오케이징에게 말을 걸었다고 해서 항상 티켓을 열 필요는 없습니다. "이거 + 어떻게 생각해?"와 "이거 수정해줘"는 다릅니다. 전자는 대화이고, 후자는 + 실행입니다. 둘을 같은 방식으로 처리하면 시스템이 금방 피곤해집니다. + + + + 그래서 오케이징에는 자연어를 읽고 작업 요청인지 판단하는 기준이 필요했습니다. + 이 기준이 없으면 두 가지 문제가 생깁니다. 하나는 티켓을 너무 많이 만들어서 + 기록이 지저분해지는 문제이고, 다른 하나는 실제 작업을 대화처럼 처리하다가 + 상태를 잃는 문제입니다. + + +--- + +1. 강한 트리거 + + + 가장 쉬운 경우는 진규가 명시적으로 실행을 요청할 때입니다. 이런 표현들은 거의 + 바로 티켓 생성 신호로 봅니다. + + +- 작업해줘 +- 구현해줘 +- 수정해줘 +- 체크해줘 +- 설정해줘 +- 작성해줘 +- 반영해줘 + + + 특히 repo 파일을 고치거나, 빌드를 돌리거나, 설정을 바꾸거나, 외부 시스템에 + 영향을 주는 요청이면 티켓을 여는 쪽이 안전합니다. 이번 글 작성 작업도 + "작성해줄래"라는 실행 요청이었기 때문에 티켓으로 전환했습니다. + + +--- + +2. 약한 요청은 side effect로 판단한다 + + + 애매한 표현도 많습니다. "한번 봐줘"는 단순 검토일 수도 있고, 실제 수정까지 + 포함할 수도 있습니다. 이럴 때는 표현보다 side effect를 봅니다. 뭔가를 실제로 + 바꿔야 하면 티켓입니다. + + +| 요청 | 판단 | +| ---------------------------- | ------------------------------------------ | +| "이 구조 어때?" | 대화 | +| "이 구조 기준으로 계획 짜줘" | 대화 또는 plan, 보통 티켓 없음 | +| "이 계획대로 파일 만들어줘" | 티켓 | +| "최신 글 확인해줘" | 조회만 하면 대화 | +| "최신화해줘" | 파일 수정이면 티켓 | +| "빌드 되는지 체크해줘" | 명령 실행과 결과 보존이 필요해서 티켓 가능 | + + + 핵심은 결과가 남아야 하는지입니다. 나중에 다시 열어봐야 할 작업이면 + 티켓입니다. 단순히 지금 대화에서 판단을 주고 끝나면 sessions에 남겨도 + 충분합니다. + + +--- + +3. 티켓을 만들지 않는 것도 로직이다 + + + 티켓 시스템을 만들면 모든 걸 티켓으로 넣고 싶어집니다. 하지만 그것도 + 문제입니다. 진규가 아이디어를 던질 때마다 작업으로 잡히면, 대화가 + 무거워집니다. 오케이징은 실행자가 맞지만, 모든 문장을 실행 명령으로 읽으면 안 + 됩니다. + + + + 그래서 sessions Forum에서는 먼저 대화로 받습니다. 브레인스토밍, 질문, 상담, + 방향성 정리는 티켓 없이 처리합니다. 그러다가 진규가 "좋아, 이걸 작성해줘"처럼 + 실제 산출물을 요청하면 그때 티켓을 엽니다. 대화가 작업으로 변하는 순간을 잡는 + 것입니다. + + +--- + +4. 애매하면 무엇을 물어볼까 + + + 애매하다고 매번 질문하는 것도 좋지 않습니다. 뻔한 기본값이 있으면 바로 + 처리하는 게 맞습니다. 하지만 tool choice나 side effect가 달라지는 경우에는 + 물어봐야 합니다. + + +| 애매한 지점 | 물어봐야 하는 이유 | +| --------------------------------- | --------------------------------- | +| 어느 repo를 고칠지 모름 | 엉뚱한 파일을 수정할 수 있음 | +| 원격 반영 여부가 불명확 | commit/push/PR은 명시 승인이 필요 | +| destructive command가 필요 | 안전선 문제 | +| 공개 채널에 개인 맥락을 보낼 위험 | 정보 노출 문제 | + + + 오케이징의 목표는 질문을 많이 하는 게 아니라, 위험한 추측을 줄이는 것입니다. + 바로 할 수 있는 건 바로 하고, 경계가 바뀌는 지점에서만 멈춥니다. + + +--- + +5. 정리 + + + 티켓 생성 로직은 결국 대화와 실행을 나누는 기준입니다. 자연어를 완벽하게 + 분류하는 게 목표가 아닙니다. 작업 상태를 잃지 않으면서도, 진규가 편하게 말할 + 수 있게 하는 것이 목표입니다. + + + + 지금 기준은 이렇습니다. 대화는 sessions에 둡니다. 실제 변경과 검증이 필요한 + 순간 티켓을 엽니다. 원격 반영은 따로 명시될 때까지 하지 않습니다. 이 세 줄이 + 현재 오케이징의 실행 경계입니다. +