복수 AI 에이전트 시대의 Workspace Orchestration을 구축해 보았다

Words by Human, supported by AI

2개월 전, Claude Code의 설정을 dotfiles처럼 키워나가는 이야기에 대해 글을 썼습니다. CLAUDE.md(Claude Code에 읽히는 설정 파일)의 상속이 비대칭적이라는 점이나, hooks(실행 전후에 처리를 삽입하는 메커니즘)와 본문을 git으로 관리하는 법 등, '하나의 에이전트를 어떻게 준비시킬 것인가'에 대한 이야기였습니다.

그로부터 2개월이 지나, 에이전트가 1개에서 여러 개로 늘어나면서 문제의 형태가 바뀌었습니다. 이에 따라 제가 매일 만지고 있는 대상을 설정 파일에서 다른 곳으로 옮겼습니다.

지금의 고민은 "어떤 모델이 똑똑한가"가 아니라, "지금 누가 무엇을 하고 있고, 다음에 무엇을 해야 하며, 무엇을 기다리고 있는가"를 알 수 없게 된다는 점입니다. 에이전트를 늘릴수록 효과가 나타난 것은 똑똑한 모델을 선택하는 것보다(Fable 클래스의 모델은 예외일까요?), 늘어난 수하들을 묶어 관리하는 운영 쪽이었습니다. 관제, 위임, 대기, 순회. 이 글은 그 이야기에 대해 다룹니다.

서론: 지난번에는 Claude Code 설정 이야기였다

지난번 기사는 Claude Code라는 하나의 도구를 자신의 손에 익히는 이야기였습니다. 메모리에 무엇을 쓸 것인지, hooks로 무엇을 강제할 것인지, CLAUDE.md를 어떻게 계층화할 것인지. 요컨대, 칼을 가는 이야기입니다.

칼이 한 자루라면 가는 법을 극한까지 익히면 그만이었겠지만, Claude Code뿐만 아니라 Codex App, OpenCode, Hermes Desktop, 정해진 시간에 일어나는 Claude routine 등 손에 든 칼이 늘어났고, 또한 각각의 특기 분야가 달라 동시에 움직입니다 (Codex도 App Script를 경유한 운용으로 시도해 보았으나, 지금은 상용 레인에서는 벗어나 있습니다).

그렇게 되면 칼을 하나씩 갈고 있는 것만으로는 돌아가지 않게 됩니다. 누구에게 어떤 일을 맡길 것인지, 맡긴 뒤에 무엇을 기다릴 것인지, 끝난 결과를 어디에 모을 것인지. 칼을 가는 법이 아니라, 주방을 운영하는 방법의 문제가 되었습니다.

이 2개월 동안 제가 했던 것은 바로 그 "주방"을 구축하는 작업입니다.

2개월 동안 변한 것: 설정에서 Workspace 운영으로

에이전트가 1개일 때는 입력과 출력이 1대 1이었습니다. 내가 지시를 내리고, Claude Code가 응답한다. 끝. 설정만 잘 되어 있다면 그것으로 성립합니다.

개체가 늘어나면 여기에 "사이(간격)"가 생깁니다.

예를 들어, 아침에 Hermes Agent로 전날부터 정체된 업무를 파악합니다. 그것을 다른 에이전트에게 조사하게 합니다. 조사 결과를 보고, 구현은 구현에 특화된 아이에게 넘깁니다. 도중에 리뷰만 깊게 물어보고 싶어지면, 직접 움직이지 않는 상담역에게 던집니다. 나온 차이점(diff)을 확인하고, 마지막에 내가 push를 승인합니다.

이 일련의 과정에서 똑똑한 모델이 활약하는 장면은 사실 아주 일부입니다. 대부분은 "전달"과 "대기"와 "기록"이며, 이 부분이 막히면 전부가 멈춥니다.

즉, 모델의 똑똑함은 입구의 조건일 뿐이며, 대수가 늘어난 뒤에 효과를 발휘하는 것은 다른 변수입니다. 누구에게 넘길 것인가(위임), 언제 움직일 것인가(대기), 누가 전체를 볼 것인가(관제), 방치된 업무를 어떻게 수거할 것인가(순회). 설정의 이야기에서 운영의 이야기로. 다루는 단위가 통째로 한 단계 올라갔습니다. 저는 그렇게 생각합니다.

현재의 AI Workspace 전체상

등장인물을 나열해 보겠습니다. 역할로 나누면 다음과 같습니다.

역할	담당	특징	하는 일
입구	Hermes Desktop	상주 에이전트의 접수창구	아침 접수, 분류, 정체 관리
...

나열해 보면 인간의 조직과 닮았습니다. 접수처가 있고, 그것을 배분하는 사람이 있고, 실제로 움직이는 사람이 몇 종류 있으며, 상담을 해주는 고문이 있고, 야간 배치(batch)가 돌아가고 있습니다.

흐름도 일직선입니다. 입구에서 받고, 관제에서 배분하며, 실무자가 움직이고, 결과를 장부에 기록합니다. 도식화하면 다음과 같습니다.

중요한 것은 이 모든 것을 한 몸에 맡기지 않는 것입니다. 접수도 관제도 구현도 한 명이 다 하게 하면, 문맥(context)이 너무 커져서 그 아이는 도중에 무엇을 하고 있었는지 잊어버립니다. 역할별로 나누어 별개의 몸에 맡기는 것. 이것이 출발점이었습니다.

물론 처음부터 이 숫자를 다 맞출 필요는 없습니다. 독자분들이 따라 하신다면, 우선 "관제역"과 "실무역"을 나누는 것만으로도 충분하다고 생각합니다. 예를 들어, 관제는 Codex App나 Obsidian의 메모, 실무는 Claude Code로 하는 식입니다. 거기에 나중에 상담역이나 자동 순회를 추가해 나갑니다. 갑자기 완성형을 만들려고 하면 아마 운영 측면에서 먼저 한계가 올 것입니다.

Codex App을 Workspace Orchestrator로 사용하기

참고한 것은 steipete 님의 이러한 기술들입니다.

maintainer-orchestrator는 부모 스레드를 가볍게 유지하고, repo 작업은 워커(worker)에게 위임하며, 5분마다 모니터링하는 설계이며, github-project-triage는 issue/PR을 URL-first 방식으로 분류하여 Autonomous / Needs owner / Defer로 나누는 사상입니다. 이 부분은 상당히 채택할 만합니다.

관제탑을 무엇으로 할 것인가. 이 부분은 꽤 고민했습니다. 결론적으로, Codex App을 부모로 설정했습니다.

부모 스레드의 역할은 직접 손을 움직이는 것이 아닙니다. 재고 조사와 할당입니다. 우선 읽기만 하는 점검(read-only triage)을 수행하고, 그다음 무엇을 봐야 할지를 결정합니다. 손은 대지 않고, 눈만 움직입니다.

그 후에 자식 스레드(worker)를 만듭니다. 하나의 worker에는 하나의 리포지토리(repository), 하나의 목적만을 부여합니다. 이것저것 요구하지 않습니다. worker에게 넘길 때는 읽기만 해도 되는지, 내용을 수정해도 되는지, 무엇을 건드리면 안 되는지, 끝난 후에는 어떤 형태로 반환해야 하는지를 첫 지시 사항에 모두 적어둡니다.

부모가 내리는 판단은 궁극적으로 5가지 선택지로 요약됩니다.

• 스스로 진행한다
• worker에게 넘긴다
• 외부 App(Claude Code나 OpenCode)에게 넘긴다
• Git 조작(commit이나 push)으로 진행한다
• 인간의 확인을 받기 위해 멈춘다

이 중 마지막인 "멈춤"을 어디서 발동할 것인가. 이를 정해두지 않으면 관제탑이 폭주합니다. 저의 경우, 다음 중 하나라도 해당하면 반드시 멈추고 인간에게 넘기기로 결정했습니다.

외부와의 동기화, push, PR 생성, merge, 아카이브, 보호된 리포지토리, secrets 종류, 그리고 커밋되지 않은 변경 사항이 섞인 지저분한 상태. 요컨대, 되돌릴 수 없는 조작과 섞이면 사고가 나는 조작입니다. 이 부분은 똑똑한 모델이라 할지라도 자동으로 넘어가게 두지 않습니다. 넘어갈지 여부는 인간이 결정합니다.

Global Ops / Domain Ops / Worker / Parking / Auto

스레드가 늘어나면 이번에는 스레드 자체가 어지러워집니다. 20개 정도 나열되면 어떤 것이 살아있고 어떤 것이 죽어있는지 알 수 없게 됩니다. 그래서 스레드에 레인(lane)이라는 속성을 부여하여 취급을 달리하고 있습니다.

여기서 나오는 Global Ops, Domain Ops, Parking, Auto는 일반적인 개발 용어가 아니라, 저의 운영상 명칭입니다. 독자분들이 따라 하신다면 이름 그 자체보다는 "항상 보는 것", "작업 중에만 보는 것", "나중에 챙길 것", "자동으로 움직이는 것"을 구분한다는 정도로만 받아들여 주셔도 충분합니다.

레인	의미	pin 방침	실제 정보원
Global Ops	전체를 보는 부모 관제	상시 pin	계획 문서 / 대장
...

제 안에서는 Global Ops, Domain Ops, Worker가 주선(main line)입니다. 거기에 방치하면 보이지 않게 되는 Parking과, 움직이기 시작하면 로그가 늘어나는 Auto가 주변 레인으로 붙어 있습니다.

포인트는 pin 여부로 레인을 구분한다는 것입니다. 항상 눈에 담아두어야 할 것만 pin 하고, 그 외에는 pin 하지 않습니다. 전부 pin 하면 pin이 의미를 잃습니다.

또 하나, 저에게 효과적이었던 원칙이 있습니다. 대장을 정본(source of truth)으로 삼지 않는 것입니다.

스레드는 어디까지나 색인(index)입니다. 진짜 내용은 PR이나 커밋, 계획 문서, 리포지토리 안의 파일에 있습니다. 스레드 본문에 결론을 쌓아두면, 스레드를 읽을 수 없게 되는 순간 정보가 사라집니다. 따라서 스레드에는 "진짜 정보원은 여기"라는 지시점(durable source)을 반드시 갖게 하고, 내용은 그곳에 둡니다. 스레드가 사라지더라도 지시점이 살아있다면 복구가 가능합니다.

Parking 레인에는 한 단계 더 규칙을 두었습니다. 보류할 때는 "왜 잊고 싶지 않은지"와 "언제 재개할 것인지"를 반드시 적습니다. 내용이 비어 있는 Parking은 그저 방치일 뿐입니다. 이유와 재개 시점을 세트로 묶어야 비로소 보류가 됩니다.

Hermes와의 분업: 아침의 접수, 분류, 소비 파수꾼

입구에 배치한 것은 Hermes Agent입니다. Nous Research에서 만든 오픈 소스(Open Source) 자기 개선형 AI 에이전트(AI Agent)입니다. 공식 사이트에서는 데스크톱 앱이나 터미널을 통해 사용할 수 있는 에이전트로 소개되고 있으며, 영구 메모리(Persistent Memory), 자연어를 이용한 스케줄링, 서브 에이전트(Sub-agent)로의 위임, 웹 검색 및 브라우저 자동화, 로컬 및 Docker 등의 샌드박스(Sandbox) 실행을 다룰 수 있다고 설명되어 있습니다. 여기서는 세부적인 기능 소개가 아니라, 나만의 AI Workspace의 입구에 두는 접수원으로서 사용하고 있습니다.

참고로, 제 환경에서는 Hermes의 뒷단에 Kimi K2.7 Code를 사용하고 있습니다. 이는 Hermes 일반의 사양이라기보다 저의 현재 구성입니다. 입구의 담당자에게 아침의 접수와 분류를 맡기기에 딱 좋은 밸런스라고 느끼고 있습니다.

Hermes의 업무는 접수입니다. 아침에 전날부터 정체된 항목이나 캘린더 및 태스크(Task)에서 가져온 것들을 나열하고 분류하여, "이것은 Codex의 관제에 던져야 할 안건입니다"라고 초안까지 작성합니다. 구현은 하지 않습니다. 판단의 관제도 하지 않습니다. 어디까지나 입구에서 교통정리를 하는 역할입니다.

그중에서도 제가 중요하게 생각하는 역할이 있는데, 바로 '소비 파수꾼'이라고 부르는 역할입니다.

아침에 알림을 주는 에이전트는 내버려 두면 배경화면이 되어버립니다. 처음 며칠은 보겠지만, 머지않아 "또 왔네" 하며 그냥 지나치게 됩니다. 알림만 내보내는 파수꾼은 언젠가 반드시 무시당합니다. 이는 제가 여러 번 겪었던 과정입니다.

그래서 파수꾼의 설계를 바꿨습니다. 알림을 내보내고 끝내는 것이 아니라, 내보낸 알림이 소비되었는지까지 파수꾼이 확인하게 합니다. 정체된 것이 정체된 채로 남아 있다면, 그것 자체를 다시 집어 들어 다음 제안으로 연결합니다. 파수꾼이 내놓은 정보를 다른 누군가(대부분 관제인 Codex)가 제대로 먹고 있는지, 먹다 남은 것을 파수꾼이 회수하는 방식입니다. 파수꾼 자신을 소비되는 루프(Loop)에 포함시킨다는 발상입니다.

Hermes와 관제의 경계는 다음과 같이 나누었습니다.

• Hermes 내에서 완결되는 것: 아침 확인, 정체 항목 정리, 캘린더 및 태스크의 가벼운 정리, Codex에 전달할 초안 작성
• 관제(Codex)에 넘기는 것: 리포지토리(Repository) 조사, 구현, 테스트, 리뷰, Git 조작, 여러 리포지토리에 걸친 구분
• 인간에게 확인하고 멈출 것: 대상 리포지토리가 모호할 때, 운영 환경의 DB나 API, auth(인증)나 secrets(비밀값)에 접근할 때

여기서 말하고 싶은 것은, Hermes는 인간을 대체하는 것이 아니라는 점입니다. 입구를 다른 몸체로 분리하여 관제와 연결했습니다. 대체가 아니라 접속입니다. 입구와 관제를 하나의 몸체에 몰아넣지 않는 것이 현재로서는 가장 효과적입니다.

덧붙여 한 가지 주의사항을 적자면, Hermes에게 사용자의 수기 메모(나중에 나올 tasks/today.md)를 읽게 하고 있지만, 읽기만 하도록 설정했습니다. 멋대로 수정하게 두지 않습니다. 입구 담당자가 수기 노트를 멋대로 정리하기 시작하면 그것대로 사고가 될 수 있기 때문입니다.

Delegate 설계: OpenCode / Claude Code / oracle

실제 업무를 어떻게 배분할 것인가. 이 부분은 "똑똑한 모델에게 전부 시키는 것"이 정답이 아니었던 지점입니다.

역할로 나누면 다음과 같습니다.

App	위치	적합한 업무	관제 측에 남기는 것
Claude Code	무거운 구현·리뷰	운영 코드, 복잡한 구현, 설계 판단, 깊은 리뷰	리포 해결, 채택 여부, Git, PR
...

Cursor도 이전에는 이 표에 포함했었습니다. IDE 문맥(Context)이 활용되는 편집에는 편리했지만, 최근에는 상용을 중단했습니다. 지금은 무거운 구현은 Claude Code, 양을 돌리는 곳은 OpenCode, 판단만 묻고 싶은 곳은 oracle로 나누는 방식이 저에게 더 잘 맞습니다.

OpenCode는 주로 Go 플랜으로 물량을 처리하는 프레임으로 보고 있습니다. 부족한 부분은 API로 보충하거나, 최근에는 Ollama Cloud Pro를 사용하는 구성도 후보로 두고 있습니다. 이 또한 아직 고정된 것은 아니며, 비용과 속도, 품질의 균형을 보며 조정하는 중입니다.

친구가 구독하면 $5를 획득합니다. 친구에게도 $5가 부여됩니다. 관심 있는 분은 이용해 주세요!

배분 판단은 대체로 다음 순서로 생각합니다.

• 보안, 인증, secret, 운영 환경, 결제, 개인정보에 접촉한다 → 똑똑한 구현 담당자(Claude Code)에게 직접
• 설계나 아키텍처 판단이 필요하다 → 직접 수행하거나 oracle에게 상담
• 변경 사항이 몇 개의 파일, 수십 줄 내외로 끝난다 → 위임하지 않고 직접 수행 (위임 비용이 더 높음)
• 단순하고, 양이 많고, 반복적이며, 시간이 걸린다 → OpenCode에 위임

그림으로 나타내면 다음과 같습니다.

oracle에 대해 보충하겠습니다. oracle은 직접 움직이지 않습니다. 구현하게 하는 것이 아니라, 판단만을 묻는 상대입니다. "이 설계와 저 설계 중 어느 쪽이 더 나을까?", "이 트레이드오프 (trade-off)에서 놓친 부분은 없을까?"라고 묻습니다. 신탁을 듣는 이미지이기에 저는 oracle이라고 부르고 있습니다. 수하(手駒) 중에 '만드는 사람'뿐만 아니라 '생각해 주는 사람'을 한 명 두어 놓으면, 설계 단계에서 막혔을 때 효과적입니다.

그리고 어떤 App에 위임할 때도, 전달 방식을 정형화하고 있습니다. 누구의 의뢰인지, 어느 리포 (repo)의 어느 브랜치 (branch)인지, 어떤 파일만 건드려도 되는지, 무엇을 해서는 안 되는지, 어떤 커맨드 (command)까지 허용할지, 언제까지인지, 끝난 후에는 어디로 돌려줄지. 이것을 매번 작성합니다. 마치 대여증과 같습니다.

App 간에 업무를 넘기면, 상대는 자신의 컨텍스트 (context)를 알지 못합니다. 그래서 "건드려도 되는 범위"와 "해서는 안 되는 일"을 명시하지 않으면, 잘해보려는 생각에 불필요한 파일까지 수정해 버립니다. 대여증을 매번 붙이는 것이 번거롭지만, 이를 생략하면 사후 처리에 드는 비용이 더 높았습니다.

AI 작업을 미아로 만들지 않는 종료 형식

위임한 에이전트 (agent)가 보내오는 보고. 이것이 제각각이면 결국 이쪽에서 해석하는 수고가 늘어납니다. 그래서 종료 형식을 고정하고 있습니다.

딱 3가지입니다. current state, next action, wait condition. 현재 어떤 상태인지, 다음에는 무엇을 할 것인지, 무엇을 기다리고 있는지입니다.

current state	next action	wait condition
lint는 수정함. 테스트는 미착수	테스트를 작성하고 실행	(없음, 계속 진행 가능)
...

왜 이 3가지일까요? 내가 다음에 어디를 봐야 할지 즉시 결정할 수 있기 때문입니다.

wait condition이 "인간의 승인"이라면 내 차례입니다. "다른 스레드 (thread)의 결과"라면 아직 대기. "없음"이라면 그대로 진행해도 좋습니다. 보고가 장문의 감상문이라면 이를 파악하는 데 시간이 걸립니다. 3가지로 압축시키면, 보고를 보는 순간 "내가 움직일지, 기다릴지"를 알 수 있습니다.

사소하지만, 이 형식을 모든 에이전트 공통의 종료 방식으로 정한 뒤로 미아가 되는 경우가 상당히 줄었습니다.

장부로 운용하기: thread ledger / tasks/today.md / automation registry

여기까지 오면서 스레드가 늘어나고, 위임이 늘어나고, 자동화가 늘어났습니다. 이것을 기억만으로 관리하는 것은 불가능합니다. 3가지 장부에 기록하고 있습니다.

thread ledger나 automation registry도 제 운용 체계 내에서의 명칭입니다. 일반적인 용어라기보다, 스레드와 자동화를 잊지 않기 위한 색인에 이름을 붙인 것뿐입니다.

첫 번째, thread ledger (스레드 장부). 어떤 스레드가 어떤 레인 (lane)에서, 어느 리포 (repo)에서, 어떤 목적으로 움직이고 있는가. 그리고 앞서 말한 3종 세트 (current state / next action / wait condition), 마지막으로 확인한 시각, 재개 시점, 실제 정보원 (durable source). 스레드를 읽을 수 없게 되었을 때는 장부의 제목이나 작업 디렉토리 (directory)에서 검색하고, 그래도 안 된다면 "복구 필요" 표시를 해둔 뒤, 내가 스레드에 한마디 던져서 되살려냅니다. 스레드 그 자체보다 장부를 더 신뢰하는 운용 방식입니다.

실제 장부는 단순한 Markdown입니다. 분위기는 이 정도면 충분합니다.

| thread | lane | current state | next action | wait condition | durable source |
|---|---|---|---|---|---|
| AI Workspace 기사 | Domain Ops | 초안 있음 | 독자 리뷰 반영 | Gemini 리뷰 | content/blog/drafts/... |

thread ledger의 예

두 번째, tasks/today.md. 이것은 장부라기보다 내 손안의 메모장입니다. 오늘 할 일을 대충 적어두는 곳입니다. AI에게 이곳을 읽게는 하지만, 내용을 고쳐 쓰게 하지는 않습니다. 어디까지나 인간의 scratchpad (연습장)이며, 정본(正本)이 아닙니다. AI가 멋대로 형식을 정리하기 시작하면 내 사고의 거친 느낌이 사라져 버리기 때문에, 이곳은 성역으로 두고 있습니다.

세 번째, automation registry (자동화 레지스트리/대장). 정해진 시간에 동작하는 것, 상주하고 있는 것, heartbeat (하트비트) 방식으로 살아있는 것. 각각이 어떤 메커니즘으로, 무엇을 입력으로 받아, 무엇을 출력하며, 언제 종료되는가. 한 가지 지키고 있는 원칙은 여기에 secret (비밀 값)이나 token (토큰)의 실체를 적지 않는 것입니다. "로컬 환경 변수를 사용한다"라거나 "이 토큰의 위치"와 같이 취급 방법만 적습니다. 내용은 적지 않습니다. 대장이 실수로 공유되더라도 사고가 나지 않도록 하기 위함입니다.

세 가지를 나란히 놓고 보면, 성격? 혹은 성질?이 다르다는 것을 알 수 있습니다.

대장	무엇의 색인인가	누가 작성하는가	정본(원본)인가
thread ledger	동작 중인 스레드	관제 (및 자신)	색인 (정본은 별도)
...

공통점은 모두 "정본 그 자체는 아니다"라는 점입니다. 대장은 지도이며, 보물은 다른 곳에 묻혀 있습니다. 지도에 보물을 적어 넣으면, 지도를 잃어버리는 순간 보물도 사라집니다.

요약: AI Workspace는 키워나가는 운영 시스템

지난번에는 설정을 키워나가는 이야기에 대해 다루었습니다. 이번에는 운영을 키워나가는 이야기가 되었습니다.

지난 2개월 동안 가장 깊이 체감한 것은, 에이전트(Agent)를 늘리면 병목 현상(Bottleneck)이 모델의 지능에서 운영 설계로 옮겨간다는 사실입니다. 똑똑한 모델은 매달 나오듯 등장합니다. 하지만 늘어난 수하들에게 역할을 부여하고, 인계 방식을 결정하며, 대기와 기록을 순환시키는 메커니즘은 아무도 나누어 주지 않습니다. 스스로 구축할 수밖에 없습니다.

직접 구축해보며 깨달은 것은, 결국 하고 있는 일이 인간의 조직 운영과 매우 흡사하다는 점입니다. 접수 창구를 나누고, 관제를 한 명에게 집중시키고, 실무자를 적재적소에 배치하며, 상담역을 두고, 인수인계 양식을 통일하고, 대장을 통해 기억을 외부로 빼내며, 갑자기 완전 자동화하지 않는 것. 새로운 이야기는 하나도 없습니다. 단지 상대가 AI가 되었을 뿐입니다.

솔직히 아직 갈 길이 멉니다. 레인(Lane)을 나누는 방식은 다음 주에 바뀌어 있을지도 모르고, 소비 관리자(Consumption Manager)는 여전히 벽지화(Wallpapering) 현상과 싸우는 중입니다. 자동 순회도 거의 수동인 상태입니다. 그럼에도 불구하고, 설정을 만지작거리던 시절보다 머릿속은 훨씬 차분해졌습니다. "누가 무엇을 하고 있고, 다음에 무엇을 해야 하며, 무엇을 기다리고 있는지"를 대장만 보면 알 수 있게 되었기 때문이라고 생각합니다.

에이전트를 하나씩 연마하는 단계는 아마 이제 끝났을 것입니다. 이제부터는 늘어난 개체들을 어떻게 하나로 묶을 것인가. Workspace를 운영 시스템으로서 키워나가는 것. 아직 암중모색하는 단계이지만, 그런 2년 차에 접어든 기분이 듭니다.

Discussion