오케이징 로직 변천사 — 지금 구조를 먼저 그려보기

초기에는 역할을 나누는 방식이 자연스러워 보였습니다. 오케이징은 진규와 대화하고, 헤르메스는 코드를 고치고, 낫징은 리뷰하고, 우로보로스는 계획을 잡는 식입니다. 이름이 나뉘면 책임도 나뉘는 것처럼 보였습니다. 실제로 어느 정도는 맞았습니다. 구현자와 리뷰어가 분리되면 작업을 설명하기 쉬웠고, 계획 담당을 따로 두면 요구사항을 한 번 더 정리할 수 있었습니다.

문제는 운영 비용이었습니다. 에이전트가 늘어나면 채널, gateway, account, context, 보고 라우팅이 같이 늘어납니다. 겉으로는 협업 구조처럼 보이지만, 실제로는 오케이징이 모든 연결을 다시 기억해야 했습니다. 결국 병목은 모델 수가 아니라 상태 관리였습니다.

이게 오케이징 변천사의 척추입니다. 더 많은 캐릭터를 만드는 것보다, 같은 오케이징이 어떤 절차를 따라 움직이는지가 중요해졌습니다. 우로보로스와 낫징은 사라진 게 아니라, 각각 planning skill과 final review gate로 내려왔습니다. 이름은 남았지만 역할은 인격이 아니라 절차가 됐습니다.

중요한 건 이 부품들이 서로 같은 일을 하지 않는다는 점입니다. memory는 오래 남겨야 할 규칙을 담고, ticket은 특정 작업의 상태를 담고, session_search는 과거 대화를 다시 끌어옵니다. 이 셋을 섞으면 금방 지저분해집니다.

지금 기준에서 오케이징은 Hermes의 사용자-facing 이름입니다. 따로 OpenClaw가 앞에 있고, 그 뒤에 Hermes worker가 붙어 있는 구조가 아닙니다. Hermes 단일 체계가 대화, 도구 실행, 티켓 관리, 보고를 소유하고, 진규가 부르는 이름이 오케이징입니다.

이 정리는 생각보다 중요했습니다. 예전 구조에서는 "오케이징이 시키고 헤르메스가 한다"는 식으로 말했지만, 그렇게 말하면 책임이 흐려집니다. 지금은 오케이징 하나가 작업을 소유합니다. 필요하면 planning discipline을 부르고, final gate를 통과하고, 그래도 마지막 책임은 오케이징에게 남습니다.

뒤의 글들은 이 지도에서 한 칸씩 파고듭니다. 왜 채팅과 작업을 나눴는지, 왜 Discord thread만 믿지 않고 로컬 티켓을 만들었는지, 우로보로스와 낫징이 왜 skill로 내려왔는지, 그리고 오케이징이 왜 새벽에 스스로를 점검하게 됐는지를 순서대로 정리합니다.

이 시리즈의 기준은 단순합니다. "AI가 신기하다"가 아니라, 실제 운영에서 무엇이 깨졌고 그걸 줄이기 위해 어떤 로직이 생겼는지를 남기는 것입니다. 오케이징은 멋있어 보이는 구조보다, 다음 세션에서도 복구 가능한 구조 쪽으로 바뀌었습니다.