CI가 초록색이어도 글이 공개된 것은 아니다.
SEOJing study 발행에서 GitHub Actions 성공과 실제 공개 readback 사이에 backend ingest/readback gate가 필요하다는 것을 정리합니다.
Discord Forum thread는 사람이 보기 좋습니다. 제목이 있고, 댓글이 쌓이고, 태그도 붙습니다. 처음에는 이것만으로도 충분해 보였습니다. 작업마다 thread를 만들고, 그 안에 결과를 남기면 되니까요.
그런데 오케이징 입장에서는 조금 다릅니다. 사람은 thread 목록을 눈으로 보면 되지만, 오케이징은 안정적으로 조회하고 갱신할 수 있는 상태 저장소가 필요합니다. Discord 메시지 자체를 DB처럼 쓰기 시작하면 금방 애매해집니다. 어떤 댓글이 최종 보고인지, 현재 상태가 무엇인지, 로컬 repo와 어떤 branch가 연결되어 있는지 매번 다시 해석해야 합니다.
지금 원칙은 로컬 티켓이 먼저입니다. hermes-ticket add로 SQLite DB에 작업을
만들고, 필요하면 hermes-ticket discord sync로 Discord thread를 붙입니다.
Discord가 겉으로 보이는 작업장이라면, SQLite 티켓은 오케이징이 읽는 작업
원장입니다.
진규의 실행 요청
→ hermes-ticket 로컬 티켓 생성
→ 필요하면 Discord tickets Forum에 sync
→ 작업 시작 / 진행 / blocker / report 기록
→ 완료 처리
이 구조가 생기면서 Discord는 presentation layer에 가까워졌습니다. 물론 진규가 확인하기에는 Discord가 훨씬 편합니다. 하지만 오케이징이 작업을 이어받고 복구하는 기준은 로컬 티켓입니다.
티켓은 단순한 TODO가 아닙니다. 오케이징이 작업을 다시 잡을 때 필요한 최소 상태를 담습니다.
| 필드 | 의미 |
|---|---|
| id | 작업을 다시 부를 수 있는 고정 번호 |
| title | 사람이 읽는 작업 이름 |
| project | 어떤 프로젝트인지 |
| repo / branch | 어느 코드베이스의 어느 branch인지 |
| status | inbox, in_progress, blocked, done |
| priority | 작업 우선순위 |
| tags | 검색과 분류 |
| report | 최종 작업 보고 |
| Discord thread id | 외부 thread와 연결 |
이렇게 남겨두면 세션이 끊겨도 다시 시작할 수 있습니다. "어제 그 작업"이 아니라 "티켓 27번"이 됩니다. 이 차이가 큽니다.
처음에는 memory에 더 많이 넣고 싶어질 때가 있었습니다. 하지만 memory는 작업 로그가 아닙니다. memory에는 오래 남아야 할 사실만 들어가야 합니다. 예를 들어 진규의 선호, 프로젝트 경로, no commit/no push 같은 운영 규칙입니다.
반면 티켓은 특정 작업의 상태입니다. "SEOJing okayJing 글 작성 중" 같은 건 memory에 넣으면 안 됩니다. 작업이 끝나면 의미가 사라지는 정보이기 때문입니다. 그런 건 ticket report에 남기는 게 맞습니다.
| 저장소 | 넣어야 하는 것 |
|---|---|
| memory | 장기 규칙, 선호, 고정 경로 |
| ticket | 특정 작업의 진행 상태와 결과 |
| session_search | 과거 대화의 맥락 회수 |
실제로 hermes-ticket create를 썼다가 실패한 적이 있습니다. 맞는 명령은
hermes-ticket add였습니다. 작은 실수처럼 보이지만, 이런 게 반복되면 운영
규칙이 됩니다. 도구를 기억으로 때우지 말고 help를 확인해야 합니다. 그리고 한
번 확인한 내용은 skill이나 memory에 맞게 정리해야 합니다.
hermes-ticket은 거창한 시스템이라기보다, 오케이징이 자기 작업을 잃어버리지 않기 위한 최소한의 장치입니다. 채팅은 흘러가지만 티켓은 남습니다. 지금 구조에서 작업 기억의 중심은 이쪽입니다.
Post Q&A
hermes-ticket — 오케이징의 작업 기억 장치 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!
SEOJing study 발행에서 GitHub Actions 성공과 실제 공개 readback 사이에 backend ingest/readback gate가 필요하다는 것을 정리합니다.
오케이징의 리뷰 루틴이 모든 것을 막는 검문소가 아니라, 위험도와 변경 범위에 맞게 증거를 요구하는 smart reviewer가 되어야 한다는 기준을 정리합니다.
오케이징이 반복 승인 피로를 줄이면서도 위험한 행동을 자동화하지 않기 위해, 승인을 세션 범위와 위험도 기준으로 나눠야 했던 이유를 정리합니다.
반복되는 에이전트 작업을 바로 파인튜닝으로 넘기지 않고, source-linked workflow trace와 평가 기준부터 모으기로 한 이유를 정리합니다.
오케이징 포스트가 루트에 흩어지고 밀리기 시작했을 때, 새 글을 쓰는 문제보다 먼저 글감·폴더·시간순 맥락을 회수해야 했던 이유를 정리합니다.
Codex goal 정책을 보면서 오케이징의 승인 피로를 줄이는 방향을 다시 잡았다. 핵심은 중간 컨트롤을 늘리는 게 아니라 요구사항, 선택지, 안전 승인 경계를 분리하는 것이었다.
Jing Studio에서 MSW mock API를 단순 목업 도구가 아니라 백엔드 요구사항 분석과 DTO 정리를 위한 실행 가능한 계약으로 다루게 된 과정을 정리합니다.
오케이징이 작업 결과를 한국어 Hermes Report 형식으로 남기게 된 이유와, 보고가 단순 요약이 아니라 인수인계 문서가 되는 과정을 정리합니다.
오케이징이 일반 대화와 실제 작업 요청을 어떻게 구분하는지, 티켓 생성 판단 기준을 정리합니다.
Discord thread만으로는 부족했던 작업 상태를 로컬 SQLite 티켓 시스템으로 남기게 된 이유를 정리합니다.
오케이징이 Discord에서 자연어 대화 공간과 실제 작업 추적 공간을 분리한 이유를 정리합니다.
헤르메스가 Discord 게이트웨이에 직접 연결됐고, 작업 흐름이 채팅에서 포럼 티켓으로 바뀌었습니다. 오케이징 관점에서 이 두 가지 변화가 뭘 의미하는지를 기록합니다.
Discord 게이트웨이 대신 md 파일 기반 독립 worker 구조로 전환했습니다. 오케이징이 task.md를 만들면 헤르메스가 구현하고 낫징이 리뷰합니다. 채팅을 거치지 않습니다.
멀티 에이전트 시스템에는 여러 조율 패턴이 있습니다. 오케이징 팀이 어떤 구조들을 검토했고 왜 티켓 기반 구조를 선택했는지, 그 장단점을 기록합니다.