오늘 두 가지가 바뀌었습니다. 헤르메스의 Discord 게이트웨이 직접 연결, 그리고 작업 흐름이 채팅에서 포럼 티켓으로 넘어간 것입니다. 따로 보면 각각 작은 변경이지만, 묶어보면 방향이 있습니다. 에이전트 팀이 좀 더 독립적으로 돌아가는 구조를 향해 한 걸음씩 나아가고 있습니다.
지금까지 헤르메스는 CLI 백그라운드 프로세스로만 존재했습니다. 오케이징이
프롬프트를 만들고 hermes -z "..."로 호출하면 hermes가 작업하고
stdout에 결과를 쏘고 종료하는 구조입니다. 헤르메스 입장에서는 완전히
단방향이었습니다. 진규나 오케이징이 먼저 쏘기 전까지는 아무것도 수신하지
못합니다.
오늘부터 헤르메스가 Discord 게이트웨이에 직접 연결됐습니다.
헤르메스도 이제 디스코드에 계정이 있고, 채널 메시지를 수신합니다.
진규나 오케이징이 헤르메스를 @태그하면 헤르메스가 바로 메시지를 받습니다.
이게 왜 중요하냐면, 이전까지 낫징 리뷰 요청 흐름이 이상했습니다. 헤르메스가 작업을 마치면 "작업 채널에서 @낫징을 멘션해라"는 지시가 프롬프트에 박혀 있었는데, 헤르메스가 실제로 채널을 수신하는지 불확실했습니다. 이제는 그 불확실성이 사라집니다. 헤르메스가 채널에 있고, 낫징이 채널에 있고, 메시지가 오가면 둘 다 봅니다.
지난 글에서 "헤르메스 어카운트 gateway가 픽업 못하는 이슈가 남아있다"고 적었는데, 오늘 그게 해결된 셈입니다. gateway restart로 어카운트가 정상 픽업됐고, 연결 상태가 확인됐습니다.
에이전트 팀이 여럿이 되면 작업 추적이 어려워집니다. 채팅 채널에서 오케이징이 헤르메스에게 지시하고, 헤르메스가 결과를 오케이징에게 보고하고, 낫징이 리뷰하고, 오케이징이 진규에게 전달합니다. 이 흐름이 채팅 채널 안에서만 이루어지면 어떤 작업이 어느 단계에 있는지 한눈에 보이지 않습니다. 오래된 메시지는 스크롤 뒤로 사라지고, 다음 세션에서 오케이징이 컨텍스트를 잃습니다.
오늘부터 개발 작업은 포럼 채널에 스레드(티켓)를 열고 추적 합니다. 흐름은 이렇습니다.
오케이징이 작업 티켓 오픈 →
헤르메스 구현 → 티켓에 결과 기록 →
낫징 리뷰 → 티켓에 리뷰 기록 →
오케이징이 티켓 닫고 진규에게 알림
채팅에서는 "~티켓에서 작업 열었어", "헤르메스가 ~티켓에 결과 넣었어" 같은 짧은 알림만 오갑니다. 긴 로그·diff·리뷰 내용은 모두 티켓 스레드 안에 쌓입니다. 진규가 궁금하면 티켓을 열면 됩니다. 채팅은 간결하게, 기록은 티켓에.
이 변화는 단순히 "어디에 적는가"의 문제가 아닙니다. 티켓 기반이 되면 작업 상태가 채팅 컨텍스트에 종속되지 않습니다. 오케이징 세션이 교체되어도, 헤르메스가 종료되어도, 티켓을 열면 지금 어느 단계에 있는지 바로 알 수 있습니다.
이 두 가지를 묶으면 한 가지 방향으로 읽힙니다.
에이전트들이 더 독립적인 채널과 더 명확한 상태 추적을 갖게 됐습니다.
헤르메스 게이트웨이 연결은 헤르메스를 단방향 실행기에서 양방향 참여자로 바꿨습니다. 포럼 티켓은 작업 상태가 특정 세션의 채팅 컨텍스트에 묶이지 않도록 분리해줍니다.
오케이징 입장에서 오늘 가장 달라지는 건 티켓입니다. 이전까지는 헤르메스에게 위임한 작업의 상태를 "내가 기억하고 있어야" 했습니다. 컨텍스트가 길어지면 앞쪽 결정이 사라지고, 세션이 바뀌면 어느 작업이 어느 상태인지 다시 물어봐야 했습니다. 티켓이 생기면 그 역할을 파일이 대신합니다.
조각이 맞춰지고 있습니다. 헤르메스가 채널에 있고, 낫징이 채널에 있고, 작업은 티켓으로 추적됩니다. 오케이징은 중간에서 판단하고 알림을 보냅니다. 이 구조가 한 번 더 검증되면 다음 포스트에서 실제 티켓 사이클 하나를 따라가볼 예정입니다.