처음에는 대화와 작업이 같은 공간에 있었습니다. 진규가 질문을 하고, 오케이징이 답하고, 중간에 코드 작업도 열고, 결과도 같은 흐름에 남겼습니다. 짧은 작업에서는 이게 편합니다. 굳이 티켓을 만들 필요도 없고, 그냥 대화하다가 바로 고치면 됩니다.
그런데 작업이 길어지면 바로 문제가 보였습니다. 일반 질문, 아이디어 정리, 실제 파일 수정, 작업 결과, 리뷰 요청이 한 thread 안에 섞입니다. 나중에 "그래서 이 작업 지금 어디까지 됐지?"를 물으면, 오케이징은 대화 전체를 다시 훑어야 합니다. 컨텍스트가 끊기면 더 힘들어집니다.
그래서 Discord에 자연어 대화용 Forum을 따로 뒀습니다. 지금 이 글을 만들게 된 대화도 sessions Forum에서 시작했습니다. 이 공간은 작업장이 아니라 대화방에 가깝습니다.
| 상황 | sessions에서 처리 |
|---|---|
| 개념 질문 | 바로 답변 |
| 아이디어 브레인스토밍 | 티켓 없이 정리 |
| 블로그 주제 리스트업 | 대화로 처리 |
| 운영 방향 상담 |
Post Q&A
채팅은 세션으로, 작업은 티켓으로 — Discord Forum을 둘로 나눈 이유 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!
| 필요한 만큼 논의 |
| 실제 구현 요청 | 그때 티켓으로 전환 |
핵심은 모든 대화를 작업으로 취급하지 않는 것입니다. 진규가 "이거 어떻게 생각해?" 라고 물었는데 매번 티켓이 생기면, 티켓 시스템은 금방 소음이 됩니다. sessions는 그 소음을 막기 위한 완충지대입니다.
반대로 tickets Forum은 실제 작업을 위한 공간입니다. 파일을 고치거나, 설정을 바꾸거나, 검증 명령을 실행하거나, 나중에 결과를 다시 찾아야 하는 일은 티켓으로 들어갑니다. 티켓은 대화의 연장이 아니라 작업의 단위입니다.
티켓이 생기면 상태가 생깁니다. inbox, in_progress, blocked, done 같은 상태가
붙고, 보고서와 blocker가 남습니다. Discord thread는 사람이 보기 좋고,
hermes-ticket 로컬 DB는 오케이징이 다시 조회하기 좋습니다. 둘을 같이 쓰는
이유가 여기 있습니다.
처음에는 "작업해줘" 같은 표현을 기준으로 생각했습니다. 물론 지금도 이 표현들은 중요합니다. 하지만 더 본질적인 기준은 side effect입니다. 답변만 하면 끝나는지, 아니면 repo나 설정이나 외부 상태를 실제로 바꾸는지가 더 중요합니다.
| 요청 | 처리 |
|---|---|
| "블로그 주제 리스트업해줘" | sessions 대화 |
| "이 내용으로 글 작성해줘" | 티켓 생성 후 파일 수정 |
| "이 코드 왜 이래?" | 먼저 확인, 단순 설명이면 대화 |
| "수정해줘" | 티켓 생성 |
| "배포해줘" | 티켓 생성, 승인 범위 확인 |
이 기준 덕분에 오케이징은 과하게 티켓을 만들지 않으면서도, 실제 작업은 놓치지 않을 수 있습니다. 대화와 실행 사이에 문턱을 하나 둔 셈입니다.
sessions와 tickets를 나누면서 가장 좋아진 건 복구 가능성입니다. 대화가 길어져도 작업 상태는 티켓에 남습니다. 세션이 끊겨도 티켓을 열면 지금 상태를 다시 볼 수 있습니다. 진규는 채팅에서 편하게 말하고, 오케이징은 실행 요청이 되는 순간 작업 추적 모드로 전환합니다.
결국 이 분리는 UX라기보다 운영 규칙입니다. 채팅은 흐르고, 작업은 남아야 합니다. 이 기준이 생긴 뒤부터 오케이징은 "무엇을 답할지"뿐 아니라 "무엇을 상태로 남길지"를 같이 판단하게 됐습니다.
오케이징의 리뷰 루틴이 모든 것을 막는 검문소가 아니라, 위험도와 변경 범위에 맞게 증거를 요구하는 smart reviewer가 되어야 한다는 기준을 정리합니다.