우로보로스는 사라지지 않았다 — planning skill로 남은 이유

우로보로스를 처음 떠올렸을 때 핵심은 계획 자체가 아니었습니다. 더 정확히는 모호성을 줄이는 루프였습니다. 진규의 요청이 아직 흐릿할 때, 질문과 가정과 성공 기준을 통해 실행 가능한 형태로 접어 넣는 역할입니다.

이 흐름은 여전히 필요합니다. 다만 꼭 별도 agent로 있어야 하는지는 다른 문제였습니다.

계획자가 따로 있으면 좋아 보입니다. 구현 전에 한 번 멈추고, 요구사항을 정리하고, 작업 범위를 정할 수 있습니다. 그런데 실제 운영에서는 계획자와 실행자 사이의 연결도 관리해야 합니다. 계획은 어디에 저장되는지, 실행자가 최신 계획을 읽었는지, 중간에 진규가 말을 바꾸면 누가 반영하는지 같은 문제가 생깁니다.

작은 작업에서는 이 비용이 더 크게 느껴집니다. 버튼 하나 고치는 작업에 별도 계획 agent를 띄우면 오히려 느려집니다. 그래서 우로보로스는 독립 실행자가 아니라 오케이징 안의 planning discipline으로 내려오는 쪽이 맞았습니다.

지금 우로보로스는 Hermes skill입니다. 이름은 ouroboros-planning이고, 쓰임새는 명확합니다. 요구사항이 크거나 애매할 때, 바로 구현하지 않고 먼저 목표와 성공 기준, non-goal, 위험 요소, 검증 방법을 정리합니다.

중요한 건 말투입니다. 우로보로스가 따로 말하는 것처럼 쓰지 않습니다. 오케이징이 우로보로스식 계획 루틴을 사용하는 것입니다. 이 차이를 정리하지 않으면 다시 다중 인격 구조로 돌아갑니다.