보수적으로 잡아도, 프로젝트 전반에서 AI 에이전트 (AI agents)를 실행하기 위한 도구가 9,000개는 있습니다. 이것은 9,001번째 도구입니다. 알고 있습니다. 그래도 잠시만 머물러 주세요.

18년 동안 백엔드 (backend) 작업을 해왔고, 대부분은 PHP였으며, 대부분 에이전시를 통해 이루어졌습니다. 이는 제가 누군가의 인력 스프레드시트(staffing spreadsheet) 내의 한 항목으로서 커리어를 보냈다는 말을 정중하게 표현한 것입니다. 여러 프로젝트를 동시에 수행하고, 서로 다른 클라이언트와 서로 다른 시간대를 상대하며, 청구서 발행이 잘 되는 날의 제 공식적인 명칭은 "리소스 (resource)"였습니다. 그래서 AI 에이전트가 실제 업무를 수행할 수 있을 정도로 발전했을 때, 저는 에이전트가 코드를 작성할 수 있을지 의심하지 않았습니다. 대신 제가 어떻게 프로젝트 전반에 걸쳐 이 거대한 함대(fleet)를 관리할 수 있을지를 고민했습니다. 그리고 결국 깨달았습니다. 이것은 18년 동안 리소스였던 제가, 다시 리소스들의 작은 스프레드시트를 관리하는 매니저가 되려고 노력하는 과정이라는 것을요. 뱀이 자신의 꼬리를 찾아낸 격입니다. 어쨌든 저는 그것을 만들었습니다.

그 결과물인 Docket은 다음과 같습니다: 프로젝트 전반에서 OpenClaw 에이전트를 실행하기 위한 컨트롤 플레인 (control plane)이며, 의도적으로 강력한 AI의 도움을 받아 제작되었습니다. 목적은 제가 암기력을 증명하는 것이 아니라, 저 자신의 부족한 부분을 채우는 것이었습니다. 처음에는 Bash CLI로 시작했으나, 현재는 테스트를 거친 Python 패키지입니다. GitHub에 베타 버전이 있으며, 링크는 하단에 있습니다. 이것은 무언가를 판매하려는 것이 아니라, 저의 생각을 공개적으로 정리하는 과정입니다.

그리고 그 재작성 과정 어딘가에서, 모두가 제가 가질 것이라 예상했던 의문 — Bash가 적절한 언어인가? — 은 사라졌고, 더 나쁜 의문이 그 자리를 대신했습니다. 이 글은 실제로 그 더 나쁜 의문에 관한 것입니다. 솔직하게 말씀드리겠습니다.

내가 목표로 했던 것, 내가 숙달한 것이 아닌 것

어휘 사용 때문에 제가 실제보다 더 많이 아는 것처럼 들리기 전에 이 말을 하고 싶습니다. 저는 컨텍스트 격리 (context isolation), 에이전트당 git worktrees, 또는 부패 방지 계층 (anti-corruption layers)을 이해한 상태로 앉아 있었던 것이 아닙니다. 저는 그저 깨끗하고, 안정적이며, 유지보수가 가능하고, 테스트 가능한 코드를 원하며 앉았고, 코드가 형태를 갖출 때까지 AI를 그 방향으로 유도했을 뿐입니다.

그 형태는 실재합니다. 하지만 그 모든 부분을 제가 똑같이 완벽하게 파악하고 있는 것은 아닙니다.

그 형태가 하는 일을 명확히 설명하자면 다음과 같습니다: OpenClaw는 로컬 우선 (local-first) 에이전트 데몬 (daemon)으로, 단일 에이전트를 실행하는 데 탁월합니다. 하지만 에이전트 군단 (fleet)을 실행하면 이 시스템이 해결하지 못하는 문제들에 직면하게 됩니다. Docket은 포드 (pods)를 실행합니다 — 컨텍스트 (context)를 소유하고 저와 대화하지만 코드는 절대 건드리지 않는 리드 (Lead), 실제로 코드를 작성하는 임플리멘터 (Implementer), 그리고 선택적으로 리뷰어 (Reviewer)와 테스터 (Tester)가 그것입니다. 각 프로젝트는 서로 격리되어 있습니다. 각 에이전트에는 비용이 소진되면 작동을 멈추는 엄격한 지출 한도 (hard spend cap)가 설정되어 있습니다. 승인 게이트 (approval gate) 없이는 어떤 위험한 일도 일어나지 않습니다.

이것이 솔직한 브로슈어입니다. 마치 제품처럼 들리죠. 그 느낌을 기억해 두세요.

의문 1: 한 사람에게 컨트롤 플레인 (control plane)이 적절한 것인가?

저는 Bash를 떠남으로써 Bash에 대한 질문에 답했습니다 — 타입 (types)도 없고, 규율에 의존하는 에러 핸들링 (error handling), 그리고 하나의 기술로서의 테스트 (testing). Python은 Bash가 구조적으로 제공할 수 없는 안전망을 제공해 주었습니다.

하지만 제가 만든 것은 대부분 '나 자신'으로 구성된 군단을 위한 Kubernetes 형태의 사고방식입니다. 이러한 형태를 만드는 사람들은 실제 멀티 테넌트 (multi-tenant) 문제를 해결하고 있습니다. 저는 몇 개의 프로젝트를 가진 한 명의 개인일 뿐입니다; 아마 쉘 스크립트 (shell script)와 약간의 규율만으로도 살아남을 수 있었을 것입니다.

그렇다면 이 문제에 컨트롤 플레인이 필요했던 것일까요, 아니면 컨트롤 플레인을 구축하는 것 자체가 컨트롤 플레인을 배우는 방식인 것일까요? 저는 계속해서 스스로를 치켜세우는 답변을 찾으려 합니다. 그렇게 할 때면 저는 제 자신을 믿는 것을 멈추게 됩니다.

의문 2: 퍼스트 파티 (first-party) 도구들이 이 정도로 훌륭할 때, 사용 사례 (use case)가 존재할까?

만약 Claude Code, Codex, Antigravity가 모두 훌륭한 오케스트레이션 (orchestration)을 제공한다면, 누가 제 것을 필요로 할까요? 특정 벤더 (vendor) 안에 머무는 사람이라면 아무도 필요로 하지 않을 것입니다. 각각은 폐쇄된 정원 (walled garden)입니다 — Codex는 GPT에, Claude Code는 Claude에, Antigravity는 Gemini에 종속되어 있습니다. 그 어떤 것도 테스터는 저렴한 모델을 사용하고, 임플리멘터는 Sonnet을 사용하며, 리드는 무료 티어 (free tier)를 사용하는, 하나의 예산과 하나의 정책 아래에서 혼합된 군단 (mixed fleet)을 기꺼이 실행해주지 않을 것입니다.

그것이 틈새 시장 (niche)입니다. 누군가 그곳에 서 있는지는 별개의 문제입니다. 이 이야기는 거버넌스 (governance)와 감사 (audit) 요구 사항이 있는 팀에게만 매력적으로 다가옵니다 — 제가 혼자 배포하고 있는 것과는 정반대인 조직 말입니다. "실제 사용 사례"와 "실제 사람들이 참여하는 사용 사례"는 서로 다른 주장임이 드러납니다.

의문 3: 내가 신뢰하는 테스트와 내가 작성할 수 없는 테스트

결정론적인(deterministic) 절반은 진정으로 커버되었습니다. 설정(config), 격리(isolation), 비용 계산(cost math), 게이트 로직(gate logic) 등이 기존 Bash 동작에 고정(pinned)되어 있어, 재작성 과정에서 의미가 조용히 변할 수 없도록 했습니다. PHPUnit을 사용해 본 입장에서는 그 부분은 쉬웠습니다.

나머지 절반은 이렇습니다. 이 시스템은 LLM(대규모 언어 모델) 기반의 에이전트(agent)를 실행(dispatch)하는데, LLM은 같은 질문에 대해 두 번 같은 답을 내놓지 않습니다. 단위 테스트(unit test)가 작동하는 이유는 f(2)가 항상 4이기 때문입니다. 하지만 Lead → Implementer → Reviewer → Tester로 이어지는 실행 과정에는 그런 보장이 없습니다. 이를 제대로 테스트하는 것—평가 하네스(eval harnesses), 판사 모델(judge models), 전체 파이프라인에 걸친 회귀 테스트(regression)—은 첫 번째 프로젝트만큼이나 큰 규모의 두 번째 프로젝트이며, 저는 아직 그것을 구축하지 못했습니다.

테스트된 절반은 제가 자랑스럽게 여길 줄 아는 절반입니다. 테스트되지 않은 절반은 이 시스템이 실제로 작동하는지 여부를 결정짓는 절반입니다.

의문 4: 이걸 공개해야 할까요?

반대 의견: 빠르게 움직이는 데몬(daemon)을 쫓는 것은 가혹한 유지보수이며, 저는 현존하는 가장 자본력이 좋은 세 곳의 엔지니어링 조직(eng orgs)과 인접해 있고, 기여자가 한 명뿐인 저장소(repo)는 라이선스 파일이 붙은 일기장에 불과합니다.

찬성 의견: 공개적으로 방어해야 하고 아직 사실이 아닌 부분을 기록해야 한다는 사실만큼, 어떤 기능을 이해하도록 강제하는 것은 없습니다.

그래서 공개 상태를 유지합니다. 확신이 있어서가 아니라, 공개해야 할 이유는 기분이 좋은 날에 믿게 되는 이유들이고, 반대하는 이유는 새벽 2시에 믿게 되는 이유들이기 때문입니다. 저는 기분이 좋은 날의 논리에 따라 배포하며, 스타(star) 개수를 확인하지 않으려 노력합니다.

다른 네 가지 의문이 발을 딛고 있는 의문

저는 의도적으로 강력한 AI의 도움을 받아 이것을 만들었습니다. 따라서 제가 이해라고 부르는 것의 일부는 사실 이미 이해하고 있는 기계를 감독(supervised)한 것에 불과합니다—검토하고, 논쟁하고, 잘못된 버전을 버릴 수 있을 정도로 충분히 말이죠. 그것이 아무것도 아니라는 뜻은 아닙니다. 잘 검토하는 것이 이제는 기술일 수도 있습니다. 하지만 그것은 제 손에 익은 PHP만큼의 무게감을 갖지는 못하며, 저는 항상 그 경계선을 찾을 수 있는 것도 아닙니다.

저는 이 글 또한 비슷한 종류의 도움을 받아 쓰고 있습니다. 이 글 어딘가에는 혼자였다면 더 서투르게 표현했을 문장이 있을 것이고, 저는 그것을 지목할 능력을 상실했습니다. 내가 무엇을 배웠는지 모른다는 것에 관한 에세이를, 내가 그것을 배운 대상과 공동 집필하고 있습니다. 이 사실을 곱씹어 보십시오. 저도 그러려고 노력 중입니다.

Docket이 표준이 될 것이라고 제 커리어를 걸 수 있느냐고요? 아니요. 하지만 다시 만들 것이냐고요? 네 — 주로 제가 무엇을 배웠는지 여전히 모르기 때문이며, 이를 알아낼 수 있는 유일한 방법은 도움을 덜 받으면서 다음 것을 만들어보고 무엇이 무너지는지 확인하는 것뿐이기 때문입니다.

자, 여기 문이 열려 있습니다. 만약 여러분이 OpenClaw 플릿 (fleets)을 운영하고 있고 이 문제 — 여러 벤더가 뒤섞인 혼란, 조용히 빠져나가는 예산 — 가 이미 여러분의 문제라면, 와서 살펴보시고, 와서 망가뜨려 주십시오. 새벽 2시에 혼자서 무엇이 잘못되었는지 알아내는 것보다 여러분으로부터 어디서 무너지는지 듣는 편이 낫습니다. 저장소 (repo)는 아래에 있습니다.

Docket은 github.com/yielab/docket에서 오픈 소스 (Apache 2.0, beta)로 제공됩니다. 독립적인 프로젝트이며, OpenClaw 또는 OpenClaw Foundation과 관련이 없습니다.