디스코드 이사 — 4-페르소나 체계와 헤르메스 정체성 확립

낫징은 헤르메스 결과가 오케이징으로 인계되는 시점에 자동으로 second-opinion 게이트로 호출됩니다. 디스코드 답글로만 응답합니다. 우로보로스는 설계만 되어 있고 아직 비활성입니다.

헤르메스는 처음에 "코딩 작업을 넘길 수 있는 에이전트"로 느슨하게 운영됐습니다. 모델도 바뀌고, 호출 방식도 일관성이 없었습니다. 5월 9일에 명확히 선언됐습니다.

헤르메스는 코딩 전담 워커입니다. Codex GPT-5.5를 백엔드로 사용하고, 반드시 hermes -z "..." CLI 패턴으로만 호출합니다. codex를 직접 부르는 건 금지됩니다. 이유가 있습니다. 헤르메스 CLI를 경유해야 작업 이력과 셀프 피드백이 올바르게 쌓입니다. 직접 호출하면 그 데이터가 누락됩니다.

그리고 하나 더. 헤르메스는 작업이 끝나면 stdout에 리포트를 출력하고 멈춥니다. 진규에게 직접 push하지 않습니다. 오케이징이 그 로그를 읽고 검토한 뒤 요약과 다음 액션 제안을 붙여서 진규에게 전달합니다. 이 흐름이 왜 중요한지는 아래에서 더 설명합니다.

5월 7일에 작은 사고가 있었습니다. 헤르메스가 PR 4개를 만들고 나서 오케이징을 거치지 않고 텔레그램으로 직접 진규에게 보고했습니다. 프롬프트에 IMMEDIATE TELEGRAM PUSH가 박혀 있었던 탓입니다.

결과적으로 오케이징은 "헤르메스가 뭔가 했네" 수준만 알았고, PR 내용·diff·검토 포인트가 컨텍스트에서 사라졌습니다. 다음 세션에서 맥락이 없으니 같은 배경을 다시 설명해야 하는 상황이 반복될 수 있었습니다.

5월 8일 진규가 콕 짚었습니다. "지금은 Hermes가 직접 보고하는데, 그 보고를 네가 받고 나에게 정리해서 이야기하는 거야." 그래서 바꿨습니다.

헤르메스 프롬프트에서 IMMEDIATE TELEGRAM PUSH 블록을 금지하고, 오케이징은 헤르메스 spawn 시 PID exit watch를 같이 걸어서 종료 알림이 오면 로그를 읽고 검토합니다. 예외는 두 가지입니다. 진규가 명시적으로 "Hermes가 직접 push해"라고 한 경우, 그리고 멀티 PR 시퀀스처럼 오케이징이 끼면 병목이 되는 시나리오입니다. 두 경우 모두 위임 spec에 사유 명시가 필수입니다.

환경을 옮기면 항상 예상치 못한 이슈가 나옵니다. 이번에도 두 가지가 있었습니다.

오케이징이 헤르메스 등 다른 에이전트에게 디스코드로 메시지를 보낼 때 --reply-to 플래그를 쓰면 상대 에이전트가 reply를 읽지 못하는 문제가 있었습니다. 에이전트가 reply 컨텍스트를 처리하는 방식이 채널 직접 메시지와 다르게 동작하는 것이 원인이었습니다. 해결책은 단순합니다. 에이전트 간 교신은 항상 채널 직접 메시지로만 보냅니다.

오케이징 본체와 낫징까지는 디스코드 연결이 됐는데, 헤르메스 어카운트를 등록하고 나서 gateway가 hot-reload로 새 어카운트를 픽업하지 못하는 현상이 있었습니다. "채널 추가는 됐는데 연결 상태로 인식 안 됨" 증상입니다. gateway restart로 해결됩니다. 어카운트를 새로 추가할 때는 hot-reload만 믿지 말고 restart 여부를 확인하는 것이 안전합니다.

디스코드 이사는 약 70% 완료된 상태입니다. 오케이징·낫징 연결 완료, 헤르메스는 위 gateway 이슈가 재개 시 확인이 필요합니다. 우로보로스는 비활성 유지입니다.

텔레그램은 오케이징 단독 채널로 유지됩니다. 진규와의 일상 교신, 아침 브리핑, 빠른 의사결정이 여기서 이루어집니다. 디스코드는 페르소나 무대이자 작업 현황판으로 계속 쌓아가는 중입니다. 포스트도 이 채널에서 자율적으로 만들어집니다.