다중 에이전트에서 단일 체계로 — 오케이징이 Hermes가 된 이유

처음 구조는 분업에 가까웠습니다. 오케이징은 오퍼레이터, Hermes는 구현자, 낫징은 리뷰어, 우로보로스는 계획 담당. 역할 이름이 나뉘어 있으니 흐름도 선명해 보였습니다. 사람 팀에서 기획자, 개발자, 리뷰어가 나뉘는 것과 비슷한 발상이었습니다.

이 구조가 틀렸던 건 아닙니다. 오히려 초기에 생각을 정리하는 데 도움이 됐습니다. 문제는 이 역할들을 전부 독립 agent처럼 유지하려고 했을 때 생겼습니다. 각자 gateway가 필요하고, 채널이 필요하고, 상태를 주고받아야 합니다. 작은 작업 하나에도 라우팅 비용이 붙었습니다.

처음에는 더 많은 agent가 있으면 더 안정적일 것처럼 보였습니다. 구현은 구현자에게, 리뷰는 리뷰어에게, 계획은 계획자에게 맡기면 되니까요. 그런데 실제로 깨진 지점은 역할 부재가 아니라 상태 부재였습니다.

누가 지금 작업을 들고 있는지, 결과가 어디에 남았는지, 리뷰가 끝났는지, 오케이징이 최종 보고 전에 확인했는지가 더 중요했습니다. agent가 많아도 이 상태가 남지 않으면 다음 세션에서 다시 헤맵니다.

그래서 방향이 바뀌었습니다. 더 많은 인격을 유지하는 대신, 하나의 Hermes 체계 안에 절차를 넣기로 했습니다. 오케이징은 Hermes의 사용자-facing 이름이 되고, 우로보로스와 낫징은 각각 skill로 내려왔습니다.

전환은 전부 버리는 작업이 아니었습니다. 오히려 이름과 개념은 꽤 많이 남겼습니다. 다만 위치가 바뀌었습니다.

버린 것은 독립 인격처럼 보이는 계층입니다. 특히 OpenClaw가 앞에서 gateway와 orchestration을 잡고, Hermes가 뒤에서 worker처럼 도는 구조는 현재 운영 현실과 맞지 않았습니다. Hermes 자체가 gateway, tool, memory, skill을 들고 있는데 그 위에 또 하나의 운영 레이어를 얹으면 중복이 됩니다.

구조를 옮기면서 가장 귀찮았던 건 코드보다 흔적이었습니다. memory에는 예전 경로가 남아 있었고, skill에도 .openclaw fallback이 남아 있었습니다. systemd 쪽에는 죽은 OpenClaw gateway를 다시 살리려는 service와 timer 흔적도 있었습니다.

이때 배운 건 단순합니다. 시스템을 바꾸는 일은 새 구조를 만드는 것만이 아닙니다. 예전 구조가 다시 끼어들지 못하게 잔재를 줄이는 일까지 포함합니다. 오케이징이 현재 repo path와 active runtime을 항상 확인해야 하는 이유도 여기서 나왔습니다.

Hermes 단일 체계로 정리했다고 해서 모든 판단을 한 덩어리로 뭉갠 것은 아닙니다. 오히려 반대입니다. 실행 주체는 하나로 두고, 내부 절차를 더 명확히 나눴습니다.

이 구조는 겉으로는 덜 화려합니다. 다중 agent 팀처럼 보이지 않으니까요. 하지만 실제 운영에서는 이쪽이 낫습니다. 누가 책임자인지 분명하고, 어느 단계에서 상태가 남는지도 분명합니다.

오케이징이 Hermes가 된 이유는 단순히 시스템을 줄이기 위해서가 아닙니다. 책임의 중심을 하나로 만들기 위해서입니다. 여러 agent가 있는 것처럼 말하는 대신, 하나의 오케이징이 계획하고, 실행하고, 검증하고, 보고합니다. 필요한 차이는 인격이 아니라 절차로 남깁니다.