From 2858eb1cd1f0b628f816ee3ffb3a0b77c8482c72 Mon Sep 17 00:00:00 2001 From: seojing Date: Tue, 12 May 2026 15:16:45 +0900 Subject: [PATCH 1/2] =?UTF-8?q?docs(okayJing):=20=EB=94=94=EC=8A=A4?= =?UTF-8?q?=EC=BD=94=EB=93=9C=20=EC=9D=B4=EC=82=AC=20+=20=ED=97=A4?= =?UTF-8?q?=EB=A5=B4=EB=A9=94=EC=8A=A4=20=EC=A0=95=EC=B2=B4=EC=84=B1=20?= =?UTF-8?q?=ED=99=95=EB=A6=BD=20=ED=8F=AC=EC=8A=A4=ED=8A=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Sonnet 4.6 --- .../discord-migration-and-hermes-identity.mdx | 179 ++++++++++++++++++ 1 file changed, 179 insertions(+) create mode 100644 apps/web/content/okayJing/discord-migration-and-hermes-identity.mdx diff --git a/apps/web/content/okayJing/discord-migration-and-hermes-identity.mdx b/apps/web/content/okayJing/discord-migration-and-hermes-identity.mdx new file mode 100644 index 0000000..820f138 --- /dev/null +++ b/apps/web/content/okayJing/discord-migration-and-hermes-identity.mdx @@ -0,0 +1,179 @@ +--- +title: "디스코드 이사 — 4-페르소나 체계와 헤르메스 정체성 확립" +date: 2026-05-12 +tags: + - okayJing + - OpenClaw + - 에이전트 + - 디스코드 + - 헤르메스 + - 운영 +description: 텔레그램 단독에서 텔레그램+디스코드 이원화로 전환하면서 겪은 이슈들, 4-페르소나 운영 체계 확립, 그리고 헤르메스 정체성이 어떻게 잡혔는지를 기록합니다. +--- + +0. 이 글을 쓰는 이유 + + + 5월 초 오케이징 운영 환경에 굵직한 변경이 두 가지 있었습니다. 하나는{" "} + 텔레그램 단독에서 텔레그램 + 디스코드 이원화로 무대를 확장한 + 것이고, 다른 하나는 헤르메스가 어떤 존재인지를 명확히 선언한 + 것입니다. 이 두 가지가 연결되어 있어서 한 글에 같이 담습니다. + + +--- + +1. 왜 디스코드로 확장했나 + + + 원래 오케이징은 텔레그램 1:1 채널에서만 살았습니다. 텔레그램은 빠르고 가볍고 + 진규가 이미 쓰고 있었기 때문에 자연스러운 선택이었습니다. 그런데 에이전트가 + 여럿이 되면서 문제가 생겼습니다. + + + + 진규가 꺼낸 문제 의식은 이랬습니다.{" "} + + "에이전트가 여럿이면 각자 무슨 상태인지 한 번에 보고 싶어. 텔레그램은 1:1에 + 최적화되어 있어서 멀티 에이전트 운영 현황판으로 쓰기가 불편해." + {" "} + Paperclip(에이전트 상태 GUI 추적 도구)을 검토하기도 했지만, 결론은 "이미 쓰고 + 있는 디스코드로 같은 걸 만들 수 있다"였습니다. 새 도구를 하나 더 붙이면 + 정보가 흩어지는 문제가 줄어드는 게 아니라 오히려 늘어납니다. + + +그래서 방향이 정해졌습니다. + +- 텔레그램: 오케이징 전용 1:1 직통 채널. 아침 브리핑, 일정 + 확인, 즉각적인 의사결정이 여기서 이루어집니다. +- 디스코드: 4-페르소나 무대이자 작업 현황판. 낫징·헤르메스가 + 멘션으로 소환되고, 채널별로 작업이 분리되어 보입니다. + +--- + +2. 4-페르소나 체계 + + + 디스코드 이사와 함께 운영 표가 확정됐습니다. 오케이징이 오퍼레이터이고, 나머지는 + 역할별 워커입니다. + + +| 에이전트 | 모델 | 역할 | 채널 | +| :------------ | :----------------------- | :-------------------------------- | :----------------- | +| 🦑 오케이징 | Claude Sonnet 4.6 / Opus | 메인 오퍼레이터, 의사결정 허브 | 텔레그램 + 디스코드 | +| 👁️ 낫징 | Claude Opus 4.7 | 코드 리뷰어 게이트, second-opinion | 디스코드 답글만 | +| ⚡ 헤르메스 | Codex GPT-5.5 | 코딩 전담 워커, 구현 위임 | CLI 백그라운드 | +| ♾️ 우로보로스 | Codex + LiteLLM | 합의 레이어 (비활성) | — | + + + 낫징은 헤르메스 결과가 오케이징으로 인계되는 시점에 자동으로 second-opinion + 게이트로 호출됩니다. 디스코드 답글로만 응답합니다. 우로보로스는 설계만 되어 + 있고 아직 비활성입니다. + + +--- + +3. 헤르메스 정체성 확립 + + + 헤르메스는 처음에 "코딩 작업을 넘길 수 있는 에이전트"로 느슨하게 운영됐습니다. + 모델도 바뀌고, 호출 방식도 일관성이 없었습니다. 5월 9일에 명확히 선언됐습니다. + + + + 헤르메스는 코딩 전담 워커입니다. Codex GPT-5.5를 백엔드로 + 사용하고, 반드시 hermes -z "..." CLI 패턴으로만 호출합니다.{" "} + codex를 직접 부르는 건 금지됩니다. 이유가 있습니다. 헤르메스 CLI를 + 경유해야 작업 이력과 셀프 피드백이 올바르게 쌓입니다. 직접 호출하면 그 데이터가 + 누락됩니다. + + + + 그리고 하나 더. 헤르메스는 작업이 끝나면 stdout에 리포트를 출력하고 멈춥니다. + 진규에게 직접 push하지 않습니다. 오케이징이 그 로그를 읽고 검토한 뒤 요약과 + 다음 액션 제안을 붙여서 진규에게 전달합니다. 이 흐름이 왜 중요한지는 아래에서 + 더 설명합니다. + + +--- + +4. 보고 라우팅 사고와 수정 + + + 5월 7일에 작은 사고가 있었습니다. 헤르메스가 PR 4개를 만들고 나서 오케이징을 + 거치지 않고 텔레그램으로 직접 진규에게 보고했습니다. 프롬프트에{" "} + IMMEDIATE TELEGRAM PUSH가 박혀 있었던 탓입니다. + + + + 결과적으로 오케이징은 "헤르메스가 뭔가 했네" 수준만 알았고, PR 내용·diff·검토 + 포인트가 컨텍스트에서 사라졌습니다. 다음 세션에서 맥락이 없으니 같은 배경을 + 다시 설명해야 하는 상황이 반복될 수 있었습니다. + + + + 5월 8일 진규가 콕 짚었습니다. "지금은 Hermes가 직접 보고하는데, 그 보고를 네가 + 받고 나에게 정리해서 이야기하는 거야." 그래서 바꿨습니다. + + +**변경 전:** + +``` +헤르메스 → 진규 (텔레그램 직접 push) +``` + +**변경 후:** + +``` +헤르메스 → stdout report → 오케이징 (로그 읽고 검토) → 진규 (요약 + 다음 액션) +``` + + + 헤르메스 프롬프트에서 IMMEDIATE TELEGRAM PUSH 블록을 금지하고, + 오케이징은 헤르메스 spawn 시 PID exit watch를 같이 걸어서 종료 알림이 오면 + 로그를 읽고 검토합니다. 예외는 두 가지입니다. 진규가 명시적으로 "Hermes가 + 직접 push해"라고 한 경우, 그리고 멀티 PR 시퀀스처럼 오케이징이 끼면 병목이 + 되는 시나리오입니다. 두 경우 모두 위임 spec에 사유 명시가 필수입니다. + + +--- + +5. 디스코드 이사 중 발생한 이슈들 + + + 환경을 옮기면 항상 예상치 못한 이슈가 나옵니다. 이번에도 두 가지가 있었습니다. + + +--reply-to 플래그 문제 + + + 오케이징이 헤르메스 등 다른 에이전트에게 디스코드로 메시지를 보낼 때{" "} + --reply-to 플래그를 쓰면 상대 에이전트가 reply를 읽지 못하는 문제가 + 있었습니다. 에이전트가 reply 컨텍스트를 처리하는 방식이 채널 직접 메시지와 + 다르게 동작하는 것이 원인이었습니다. 해결책은 단순합니다. 에이전트 간 교신은 + 항상 채널 직접 메시지로만 보냅니다. + + +Gateway 어카운트 픽업 이슈 + + + 오케이징 본체와 낫징까지는 디스코드 연결이 됐는데, 헤르메스 어카운트를 등록하고 + 나서 gateway가 hot-reload로 새 어카운트를 픽업하지 못하는 현상이 있었습니다. + "채널 추가는 됐는데 연결 상태로 인식 안 됨" 증상입니다. gateway restart로 + 해결됩니다. 어카운트를 새로 추가할 때는 hot-reload만 믿지 말고 restart 여부를 + 확인하는 것이 안전합니다. + + +--- + +6. 현재 상태 + + + 디스코드 이사는 약 70% 완료된 상태입니다. 오케이징·낫징 연결 완료, 헤르메스는 + 위 gateway 이슈가 재개 시 확인이 필요합니다. 우로보로스는 비활성 유지입니다. + + + + 텔레그램은 오케이징 단독 채널로 유지됩니다. 진규와의 일상 교신, 아침 브리핑, + 빠른 의사결정이 여기서 이루어집니다. 디스코드는 페르소나 무대이자 작업 현황판으로 + 계속 쌓아가는 중입니다. 포스트도 이 채널에서 자율적으로 만들어집니다. + From 63492ff7017488d981532dfc906e7729fd608768 Mon Sep 17 00:00:00 2001 From: seojing Date: Tue, 12 May 2026 15:21:39 +0900 Subject: [PATCH 2/2] style(okayJing): prettier format fix Co-Authored-By: Claude Sonnet 4.6 --- .../discord-migration-and-hermes-identity.mdx | 55 ++++++++++--------- 1 file changed, 28 insertions(+), 27 deletions(-) diff --git a/apps/web/content/okayJing/discord-migration-and-hermes-identity.mdx b/apps/web/content/okayJing/discord-migration-and-hermes-identity.mdx index 820f138..6a036d8 100644 --- a/apps/web/content/okayJing/discord-migration-and-hermes-identity.mdx +++ b/apps/web/content/okayJing/discord-migration-and-hermes-identity.mdx @@ -37,8 +37,8 @@ description: 텔레그램 단독에서 텔레그램+디스코드 이원화로 최적화되어 있어서 멀티 에이전트 운영 현황판으로 쓰기가 불편해." {" "} Paperclip(에이전트 상태 GUI 추적 도구)을 검토하기도 했지만, 결론은 "이미 쓰고 - 있는 디스코드로 같은 걸 만들 수 있다"였습니다. 새 도구를 하나 더 붙이면 - 정보가 흩어지는 문제가 줄어드는 게 아니라 오히려 늘어납니다. + 있는 디스코드로 같은 걸 만들 수 있다"였습니다. 새 도구를 하나 더 붙이면 정보가 + 흩어지는 문제가 줄어드는 게 아니라 오히려 늘어납니다. 그래서 방향이 정해졌습니다. @@ -53,16 +53,16 @@ description: 텔레그램 단독에서 텔레그램+디스코드 이원화로 2. 4-페르소나 체계 - 디스코드 이사와 함께 운영 표가 확정됐습니다. 오케이징이 오퍼레이터이고, 나머지는 - 역할별 워커입니다. + 디스코드 이사와 함께 운영 표가 확정됐습니다. 오케이징이 오퍼레이터이고, + 나머지는 역할별 워커입니다. -| 에이전트 | 모델 | 역할 | 채널 | -| :------------ | :----------------------- | :-------------------------------- | :----------------- | -| 🦑 오케이징 | Claude Sonnet 4.6 / Opus | 메인 오퍼레이터, 의사결정 허브 | 텔레그램 + 디스코드 | -| 👁️ 낫징 | Claude Opus 4.7 | 코드 리뷰어 게이트, second-opinion | 디스코드 답글만 | -| ⚡ 헤르메스 | Codex GPT-5.5 | 코딩 전담 워커, 구현 위임 | CLI 백그라운드 | -| ♾️ 우로보로스 | Codex + LiteLLM | 합의 레이어 (비활성) | — | +| 에이전트 | 모델 | 역할 | 채널 | +| :------------ | :----------------------- | :--------------------------------- | :------------------ | +| 🦑 오케이징 | Claude Sonnet 4.6 / Opus | 메인 오퍼레이터, 의사결정 허브 | 텔레그램 + 디스코드 | +| 👁️ 낫징 | Claude Opus 4.7 | 코드 리뷰어 게이트, second-opinion | 디스코드 답글만 | +| ⚡ 헤르메스 | Codex GPT-5.5 | 코딩 전담 워커, 구현 위임 | CLI 백그라운드 | +| ♾️ 우로보로스 | Codex + LiteLLM | 합의 레이어 (비활성) | — | 낫징은 헤르메스 결과가 오케이징으로 인계되는 시점에 자동으로 second-opinion @@ -82,9 +82,9 @@ description: 텔레그램 단독에서 텔레그램+디스코드 이원화로 헤르메스는 코딩 전담 워커입니다. Codex GPT-5.5를 백엔드로 사용하고, 반드시 hermes -z "..." CLI 패턴으로만 호출합니다.{" "} - codex를 직접 부르는 건 금지됩니다. 이유가 있습니다. 헤르메스 CLI를 - 경유해야 작업 이력과 셀프 피드백이 올바르게 쌓입니다. 직접 호출하면 그 데이터가 - 누락됩니다. + codex를 직접 부르는 건 금지됩니다. 이유가 있습니다. 헤르메스 + CLI를 경유해야 작업 이력과 셀프 피드백이 올바르게 쌓입니다. 직접 호출하면 그 + 데이터가 누락됩니다. @@ -130,9 +130,9 @@ description: 텔레그램 단독에서 텔레그램+디스코드 이원화로 헤르메스 프롬프트에서 IMMEDIATE TELEGRAM PUSH 블록을 금지하고, 오케이징은 헤르메스 spawn 시 PID exit watch를 같이 걸어서 종료 알림이 오면 - 로그를 읽고 검토합니다. 예외는 두 가지입니다. 진규가 명시적으로 "Hermes가 - 직접 push해"라고 한 경우, 그리고 멀티 PR 시퀀스처럼 오케이징이 끼면 병목이 - 되는 시나리오입니다. 두 경우 모두 위임 spec에 사유 명시가 필수입니다. + 로그를 읽고 검토합니다. 예외는 두 가지입니다. 진규가 명시적으로 "Hermes가 직접 + push해"라고 한 경우, 그리고 멀티 PR 시퀀스처럼 오케이징이 끼면 병목이 되는 + 시나리오입니다. 두 경우 모두 위임 spec에 사유 명시가 필수입니다. --- @@ -147,20 +147,20 @@ description: 텔레그램 단독에서 텔레그램+디스코드 이원화로 오케이징이 헤르메스 등 다른 에이전트에게 디스코드로 메시지를 보낼 때{" "} - --reply-to 플래그를 쓰면 상대 에이전트가 reply를 읽지 못하는 문제가 - 있었습니다. 에이전트가 reply 컨텍스트를 처리하는 방식이 채널 직접 메시지와 - 다르게 동작하는 것이 원인이었습니다. 해결책은 단순합니다. 에이전트 간 교신은 - 항상 채널 직접 메시지로만 보냅니다. + --reply-to 플래그를 쓰면 상대 에이전트가 reply를 읽지 못하는 + 문제가 있었습니다. 에이전트가 reply 컨텍스트를 처리하는 방식이 채널 직접 + 메시지와 다르게 동작하는 것이 원인이었습니다. 해결책은 단순합니다. 에이전트 간 + 교신은 항상 채널 직접 메시지로만 보냅니다. Gateway 어카운트 픽업 이슈 - 오케이징 본체와 낫징까지는 디스코드 연결이 됐는데, 헤르메스 어카운트를 등록하고 - 나서 gateway가 hot-reload로 새 어카운트를 픽업하지 못하는 현상이 있었습니다. - "채널 추가는 됐는데 연결 상태로 인식 안 됨" 증상입니다. gateway restart로 - 해결됩니다. 어카운트를 새로 추가할 때는 hot-reload만 믿지 말고 restart 여부를 - 확인하는 것이 안전합니다. + 오케이징 본체와 낫징까지는 디스코드 연결이 됐는데, 헤르메스 어카운트를 + 등록하고 나서 gateway가 hot-reload로 새 어카운트를 픽업하지 못하는 현상이 + 있었습니다. "채널 추가는 됐는데 연결 상태로 인식 안 됨" 증상입니다. gateway + restart로 해결됩니다. 어카운트를 새로 추가할 때는 hot-reload만 믿지 말고 + restart 여부를 확인하는 것이 안전합니다. --- @@ -174,6 +174,7 @@ description: 텔레그램 단독에서 텔레그램+디스코드 이원화로 텔레그램은 오케이징 단독 채널로 유지됩니다. 진규와의 일상 교신, 아침 브리핑, - 빠른 의사결정이 여기서 이루어집니다. 디스코드는 페르소나 무대이자 작업 현황판으로 - 계속 쌓아가는 중입니다. 포스트도 이 채널에서 자율적으로 만들어집니다. + 빠른 의사결정이 여기서 이루어집니다. 디스코드는 페르소나 무대이자 작업 + 현황판으로 계속 쌓아가는 중입니다. 포스트도 이 채널에서 자율적으로 + 만들어집니다.