서론

Garelier는 Claude Code / Codex CLI를 역할 분담, 파일 전달, 지식(Knowledge), 품질 게이트(Quality Gate)로 묶기 위한, human-supervised 방식의 로컬 관리 멀티 에이전트(Multi-agent) 개발 프레임워크입니다.

리포지토리는 여기 있습니다.

Garelier는 AI 에이전트에게 "그저 코드를 쓰게 하기" 위한 것이 아닙니다.

장시간의 AI 개발에서 발생하기 쉬운 다음과 같은 문제들을 억제하기 위한 제어층(Control layer)입니다.

• 사양이나 목적에서 조금씩 벗어남
• 작업 상태가 채팅 로그에 파묻힘
• 여러 에이전트가 동일한 영역을 망가뜨림
• 구현자의 자기 신고만으로 결과물을 신뢰하게 됨
• 안전 확인이나 독립적인 리뷰 전에 통합해 버림
• 세션이 바뀌었을 때, 판단 이유나 미완료 태스크가 사라짐
• target 브랜치에 인간의 승인 전 변경 사항이 섞임

Garelier는 이것들을 의지로 관리하는 것이 아니라, blueprint, control, runtime, role, lane, gate, studio, approval, promote라는 명시적인 흐름으로 나누어 관리합니다.

Garelier가 지향하는 것

Garelier의 목적은 AI가 자유롭게 움직이게 하는 것이 아닙니다.

오히려 반대로, AI 에이전트가 움직여도 되는 범위, 써도 되는 장소, 판단해도 되는 내용, 상위 역할(Role)로 올려보내야 할 내용을 구분합니다.

중심이 되는 생각은 다음 세 가지입니다.

1. AI 작업을 프로젝트 측에 남기기

AI와의 대화만으로 개발을 진행하면, 작업의 전제, 판단, 미완료 사항, 리뷰 결과가 대화 로그에 갇히기 쉽습니다.

Garelier에서는 작업의 정본(Source of truth)을 프로젝트 루트의 __garelier/<pm_id>/control/

또는 __garelier/<pm_id>/runtime/

에 남깁니다. 프로젝트 외부로 나가서 사용할 수도 있습니다.

control/은 blueprint, roadmap, backlog, decisions, risks, quality gates, knowledge 등의 영속적인 정보를 가집니다.

runtime/은 현재 진행 중인 작업, inbox/outbox, dispatch, lane lock, review result 등의 실행 시점 상태(Runtime state)를 가집니다.

이를 통해 AI 세션이 끊기더라도 프로젝트 측에서 상태를 복구하기 쉬워집니다.

<pm_id>는 여러 명이 사용하기 위한 작업 컨테이너와 같은 의미를 가집니다. git 기반으로 로드맵(control)이 하나가 되어 버리면 AI에 대한 작업 분할이 어려워집니다. <pm_id>는 이를 계층별로 나누어 주기 때문에, 동일한 git 리포지토리에서 분업 관리하며 진행할 수 있습니다.

2. 판단하는 AI와 실행하는 AI를 분리하기

Garelier에서는 PM, Dock, Worker, Guardian, Observer, Concierge 등의 역할이 나누어져 있습니다.

이는 이름을 늘려 복잡하게 만들기 위함이 아닙니다. 작업 내용의 명칭이 아니라, 목적에 따라 명칭을 붙여 구분한 것입니다.

중요한 것은, 설계하는 역할, 구현하는 역할, 조사하는 역할, 안전을 확인하는 역할, 리뷰하는 역할, 외부 조작을 하는 역할을 유착시키지 않는 것입니다.

예를 들어, 코드를 작성한 Worker가 그대로 최종 통합이나 외부 push까지 판단해 버리면 리뷰 경계가 약해집니다.

Garelier에서 Worker는 자신의 workbench에서 작업하고, Dock이 통합을 관리하며, Guardian / Observer가 gate를 담당하고, Concierge가 승인된 외부 조작을 실행합니다.

3. target 브랜치에 넣기 전에 studio 브랜치에서 멈추기

Garelier는 작업 결과물을 즉시 target 브랜치에 넣지 않습니다.

먼저 studio 브랜치에 모읍니다.

workbench / anvil / satchel / shelf
-> studio
-> user approval
...

studio는 AI 작업의 통합 및 검증 장소입니다.

target은 사용자가 소유한 최종 브랜치입니다.

Garelier가 target에 접촉하는 것은 사용자의 명시적 승인 후입니다. 여기가 중요한 경계가 됩니다.

gitflow 등에서 말하는 feature가 사용자의 작업 브랜치라면, 그것을 target이라고 부르고, 거기서 studio를 만들어 Garelier는 작업을 AI에게 시킵니다.

전체 흐름

Full Garelier의 기본적인 흐름은 다음과 같습니다.

User
-> PM
-> blueprint
...

크게 보면, Garelier는 다음과 같은 흐름으로 진행됩니다.

• 사용자가 garelier-pm에 목적을 전달함
• PM이 blueprint를 생성함
• Dock가 blueprint를 phase / assignment로 분해함
• Worker / Scout / Smith / Librarian이 담당 영역을 처리함
• Guardian이 안전·의존성·라이선스 등을 확인함
• Observer가 독립적인 리뷰를 수행함
• Dock가 studio에 통합함
• PM이 사용자에게 승인을 요청함
• Concierge가 승인된 promote / push / tag 등을 실행함
• target에 반영됨

여기서 중요한 점은, AI가 마음대로 최종 브랜치로 진행하는 것이 아니라, 중간에 **확인 지점(checkpoint)과 책임 경계(responsibility boundary)**가 놓여 있다는 것입니다.

11개의 역할

Garelier의 Full 구성에서는 11개의 역할이 등장합니다.

각 역할은 작업 범위, 소유하는 브랜치나 파일, 대화 상대가 정해져 있습니다.

PM

PM은 사용자의 의도를 Garelier 내부의 작업 단위로 변환하는 역할입니다.

주요 책무는 roadmap, blueprint, backlog, decision, promote 판단을 다루는 것입니다.

PM은 사용자와 대화하며 무엇을 만들 것인지, 어디까지가 범위인지, 무엇을 성공 조건으로 할 것인지를 정리합니다.

PM은 구현자가 아닙니다.

PM의 역할은 사용자의 의도를 모호한 상태로 작업자에게 흘려보내지 않고, blueprint로서 정의하며, 필요한 판단을 내리고, 마지막에 studio에서 target으로 진행해도 될지를 감독하는 것입니다.

Dock

Dock은 Full Garelier의 실행 관리자입니다.

PM이 만든 blueprint를 phase나 assignment로 분해하여 Worker, Scout, Smith, Librarian에게 할당합니다.

Dock은 작업 순서, 의존 관계, 통합 타이밍, merge gate를 관리합니다.

Worker나 Scout 같은 작업자들은 기본적으로 PM과 직접 소통하지 않습니다.

작업자의 질문이나 BLOCK은 Dock에게 모이며, Dock이 해결할 수 있는 것은 해결하고 사용자의 판단이 필요한 것만 PM에게 올립니다.

이를 통해 PM은 설계 판단에 집중하고, Dock은 실행 중 상태의 정합성을 유지합니다.

Worker

Worker는 커밋(commit)을 동반하는 구체적인 작업을 담당합니다.

예를 들어 기능 구현, 버그 수정, 리팩터링 (refactoring), 테스트 추가, 문서 편집 등입니다.

Worker는 자신 전용의 workbench branch / worktree를 가집니다.

Worker는 자신의 담당 범위만 변경하며, 완료 후에 report를 반환합니다.

중요한 것은 Worker가 스스로 마음대로 studio나 target에 통합하지 않는 것입니다.

Worker의 성과는 Dock이 수령하며, 필요한 gate를 통과한 후에 통합합니다.

Scout

Scout는 커밋을 동반하지 않는 조사·검증·실행 확인을 담당합니다.

예를 들어 웹 조사, 벤치마크 (benchmark), 전수 테스트, 외부 API 상태 확인, 배포 확인, 메트릭 (metrics) 수집 등입니다.

Scout의 성과는 코드 변경이 아닌 inspection(점검) 결과로 남습니다.

Scout는 구현하는 것이 아니라, 판단 재료를 만드는 역할입니다.

PM이나 Dock은 Scout의 inspection을 보고 blueprint, backlog, 다음 assignment를 조정할 수 있습니다.

Smith

Smith는 통합 후의 hardening(경화/강화)을 담당합니다.

Worker의 성과가 studio에 들어온 후, 결합 테스트, E2E, 시스템 테스트, 릴리스 준비, 사양 정합성, 보안·라이선스 확인 등을 수행합니다.

Smith는 Worker의 미완료 기능을 대신 처리해 주는 역할이 아닙니다.

Smith의 역할은 통합된 상태가 깨지지 않았는지, 릴리스나 운용을 견딜 수 있는지, 사양과 모순되지 않는지를 확인하고 필요한 hardening을 수행하는 것입니다.

Librarian

Librarian은 지식 관리(Knowledge Management)를 담당합니다.

외부 정보의 동기화, 내부 규약화, 런북(runbook)화, 소스 레지스트리(source registry), 루틴 레지스트리(routine registry), 보안 지식(security knowledge), 외부 운영 지식(external operations knowledge) 등을 다룹니다.

AI 에이전트가 매번 그 자리에서 추측하는 것이 아니라, 프로젝트 고유의 규칙이나 참조해야 할 정보를 가질 수 있도록 합니다.

Garelier에서 지식(knowledge)은 보조 정보가 아니라, 게이트(gate)나 작업 판단의 근거가 됩니다.

예를 들어 Guardian은 Librarian이 관리하는 보안 지식(security knowledge)을 참조하여 판정합니다.

Concierge는 Librarian이 관리하는 외부 운영 지식(external operations knowledge)을 읽고 외부 조작을 실행합니다.

사용자가 Librarian의 지식에 규약이나 작업 방식을 추가로 저장해 나가면, AI가 이를 읽고 작업을 진행하도록 설정할 수 있습니다. 이는 확장 기능입니다.

Artisan

Artisan은 Dock, Worker, Scout, Smith, Librarian의 범위를 단독으로 담당하는 역할(role)입니다.

Full Garelier에서는 Dock lane과 Artisan lane이 존재합니다.

Dock lane은 Dock가 여러 역할을 통제하는 조정된 경로(coordinated path)입니다.

Artisan lane은 Artisan이 단독으로 작업을 통과시키는 경로(path)입니다.

두 lane 모두 최종적으로는 studio에 도달합니다.

단, lane은 동시에 실행되지 않습니다. runtime/lane.lock에 의해 배타 제어(exclusive control)됩니다.

Artisan은 단독 실행할 수 있는 강력한 역할이지만, Guardian / Observer의 게이트(gate)를 건너뛰고 target으로 진행하는 것은 아닙니다.

Guardian

Guardian은 안전, 프라이버시, 의존성, 라이선스 등의 게이트(gate)를 담당합니다.

기밀 정보, PII(개인 식별 정보), 위험한 변경, 의존성, 라이선스, 보안 정책(security policy) 등을 확인하고 PASS, PASS_WITH_NOTES, BLOCK, NO_OPINION 등의 평결(verdict)을 반환합니다.

Guardian은 코드를 구현하는 역할이 아닙니다.

또한 외부 조작을 실행하는 역할도 아닙니다.

Garelier에서는 판정하는 역할과 외부 조작을 수행하는 역할을 분리합니다.

Guardian이 안전 판정을 수행하고, Concierge가 승인된 외부 조작을 수행함으로써, 보안 판단과 외부 쓰기(external write)가 동일한 역할에 집중되지 않도록 합니다.

Observer

Observer는 커밋 프리(commit-free)의 독립적인 리뷰/조언 역할입니다.

Observer는 Dock lane과 Artisan lane 모두에서 동작합니다.

Observer는 lane.lock을 획득하지 않으며, 브랜치(branch)를 소유하지도, 머지(merge)하지도 않습니다.

따라서 lane의 배타 제어나 통합 책임을 해치지 않으면서 외부에서 리뷰할 수 있습니다.

Observer의 역할은 구현자나 통합 담당자와는 다른 관점에서 diff, 리포트(report), 설계, 작업 결과 등을 확인하는 것입니다.

Observer의 평결(verdict)은 PASS, PASS_WITH_NOTES, REWORK_RECOMMENDED, BLOCK, NO_OPINION 등입니다.

Concierge

Concierge는 PM이 승인한 외부 조작을 실행하는 역할입니다.

예를 들어 studio에서 target으로의 프로모션(promote), 태그(tag), 푸시(push) 등입니다.

Concierge는 코드를 구현하지 않습니다.

방침을 결정하지도 않습니다.

게이트(gate) 역할도 수행하지 않습니다.

역할은 PM과 사용자의 승인 후에 외부로 기록하는 조작을 격리하여 실행하는 것입니다.

Garelier에서 외부 조작은 편리하기 때문에 자동화하는 것이 아니라, 위험하기 때문에 격리합니다.

Wanderer

Wanderer는 확정 전의 PM 설계를 외부에서 리뷰하는 어드바이저리(advisory) 역할입니다.

블루프린트(blueprint)나 큰 설계 변경 등, 비자명한(non-trivial) PM 설계에 대해 별도의 세션인 Codex / Claude Code 등을 사용하여 독립된 관점에서 리뷰합니다.

Wanderer는 커밋(commit)하지 않습니다.

브랜치(branch)나 lane도 가지지 않습니다.

판단 권한도 없습니다.

어디까지나 조언 역할입니다.

부재(absence), 침묵(silence), rate limit(속도 제한) 등으로 사용할 수 없는 경우에는 Observer가 폴백(fallback)합니다.

이 역할(role)은 다른 역할과 달리, 별도의 터미널을 실행하여 메시지를 주고받으며 작업을 진행합니다.

외부 모델에 의한 리뷰 이외의 용도로도 검토 중인 역할입니다.

역할(Role) 목록

정리하면, 각 역할은 다음과 같습니다.

Role	주요 책무	보호 대상
PM	사용자 의도를 blueprint / roadmap / promote 판단으로 변환	목적, 범위, 승인 경계
...

Branch와 작업 공간

Garelier는 target project 내에서 Garelier가 관리하는 branch / worktree를 사용하여 작업을 분리합니다.

대표적인 branch 이름은 다음과 같습니다.

target
└── garelier/<target-slug>/<pm_id>/studio
├── garelier/<target-slug>/<pm_id>/workbench/#/<task>
...

의미는 다음과 같습니다.

이름	용도
target	사용자 소유의 최종 브랜치
...

Garelier가 보호하는 것은 작업의 속도만이 아닙니다.

어떤 역할이, 어느 장소에서, 무엇을 작성해도 되는지를 구분함으로써 책임 경계(responsibility boundary)를 추적하기 쉽게 만듭니다.

Control과 Runtime

Garelier에서는 영구적인 정본(source of truth)과 실행 중인 일시적 상태를 구분합니다.

__garelier/<pm_id>/
control/
runtime/

control/은 프로젝트 관리상의 정본입니다.

예를 들어, 다음과 같은 정보를 둡니다.

• project_dashboard
• roadmap
• backlog
• decisions
• risks
• quality_gates
• blueprints
• inspections
• delegation
• request_intake
• knowledge

runtime/은 현재 동작 중인 실행 상태입니다.

예를 들어, 다음과 같은 정보를 둡니다.

• manifest
• backlog queue
• inbox / outbox
• lane.lock
• dispatch event
• escalation
• review result
• role status

이러한 분리를 통해 '프로젝트로서 남겨야 할 판단'과 '지금 당장 필요한 실행 상태'를 섞이지 않게 다룰 수 있습니다.

Blueprint

Blueprint는 PM이 만드는 작업 사양입니다.

사용자의 요청을 그대로 Worker에게 전달하는 것이 아니라, 목적, 범위, 제약, 수락 조건, 확인 방법, 리스크, 담당 역할 등을 정리합니다.

Blueprint를 두는 이유는 AI가 기세에 밀려 바로 구현에 들어가는 것을 방지하기 위해서입니다.

AI는 작은 작업이라면 대화 흐름 속에서 진행할 수 있지만, 긴 작업에서는 전제가 모호한 상태로 움직이기 쉽습니다.

Garelier에서는 먼저 PM이 blueprint를 만들고, 작업자는 그 정본을 보고 움직입니다.

Gate

Garelier에서는 통합(integration) 전에 gate를 거칩니다.

주요 gate는 Guardian과 Observer입니다.

Guardian은 안전, 프라이버시, 의존성, 라이선스 등을 확인합니다.

Observer는 독립적인 리뷰를 수행합니다.

나아가 외부 조작은 Concierge에 격리됩니다.

implementation
-> Guardian
-> Observer
...

이러한 흐름을 통해 AI가 구현한 내용을 구현자 자신의 판단만으로 target에 넣지 않도록 합니다.

Status Web

Garelier에서는 진행 중인 태스크, 큐(queue), 리뷰 상태를 Status Web에서 확인할 수 있습니다.

AI 에이전트의 작업은 채팅만으로 추적하면 파악하기 어려워집니다.

Status Web은 다음과 같은 정보를 읽기 전용으로 확인하기 위한 것입니다.

• 현재 무엇이 동작하고 있는가
• 어떤 assignment가 대기 중인가
• 어떤 role이 BLOCKED 상태인가
• Guardian / Observer의 판정은 어떠한가
• promote 가능한 상태인가
• 어디에서 사용자 승인을 기다리고 있는가

작업 상태를 대화 로그에만 가두지 않는 것이 목적입니다.

사용 흐름

이용하려는 프로젝트의 git root에서 Claude Code를 열고, garelier-pm skill을 활성화하여 대화합니다.

도입 예시는 다음과 같습니다.

/plugin marketplace add aby-studio-works/garelier
/plugin install garelier@garelier

셋업 후에는 기본적으로 PM에게 말을 겁니다.

garelier-pm으로 이 프로젝트를 셋업해줘

PM은 리포지토리를 조사하여 stack, build/test command, target branch 등을 감지합니다.

그 후에는 다음과 같이 진행합니다.

<하고 싶은 일>의 blueprint를 만들어줘

그 blueprint대로 진행해줘

Status Web을 실행해줘

사용자는 내부 역할(role)별 세부 명령어를 직접 외울 필요가 없습니다.

기본적으로 PM에게 의도를 전달하면, PM이 각 역할(role)에 할당합니다.

위 내용은 하나의 예시일 뿐이므로, 불렛 포인트나 이미 존재하는 사양서(specification)의 경로를 PM에게 전달하며 계획해줘라고 말하면, 로드맵으로부터 백로그(backlog)화, blueprint 등을 순차적으로 진행해 줍니다. 그 이후에는 진행해줘나 /goal, /loop 등을 사용하면 됩니다.

때때로 오류로 인해 멈춰 있는 경우가 있으므로, tasks나 subagent 표시가 없다면 PM에게 잘 되고 있어?라고 물어보세요. 어떤 식으로든 작업이 진행될 것입니다.

Garelier가 무겁게 느껴지는 이유

Garelier는 단순한 AI 보조 도구가 아닙니다.

역할(role)의 수도 많고, branch나 worktree, control, runtime, gate, Status Web도 존재합니다.

이는 입구를 가볍게 보이게 하기 위한 설계가 아니라, AI 에이전트가 장시간 작업할 수 있도록 하기 위한 제어 설계(control design)입니다.

Garelier가 무겁게 느껴지는 이유는 Garelier가 다루려는 문제가 무겁기 때문입니다.

• 다중 에이전트의 작업 충돌
• 세션 단절 후의 복귀
• 메인 브랜치(main branch) 보호
• 외부 조작의 격리
• 보안·라이선스 gate
• 구현자와 리뷰어의 분리
• 지식의 정본화(source of truth)
• PM 판단과 실행 상태의 분리

작은 수정 작업뿐이라면 이 제어는 과할지도 모릅니다.

하지만 AI를 프로젝트 내의 지속적인 작업자로 취급할 경우, 제어가 느슨할수록 나중에 사고의 원인을 추적하기 어려워집니다.

Garelier의 위치

Garelier는 AI 에이전트 집합이 아닙니다.

또한 단순한 리뷰 에이전트도 아닙니다.

Garelier는 AI 코딩 작업을 상태(state)·역할(role)·작업 장소·품질 게이트(quality gate)·승인 경계로서 관리하기 위한 제어 프레임워크(control framework)입니다.

한마디로 정의하자면 다음과 같습니다.

Garelier는 Claude Code / Codex CLI의 장시간 AI 개발을 깨지지 않고 진행하기 위한 local-first 방식의 멀티 에이전트 개발 제어 계층(control layer)입니다.

Full Garelier에서는 여러 역할(role)이 동시에 존재합니다.

단, 가치는 '역할이 많다는 것'에 있지 않습니다.

가치는 이러한 역할들이 blueprint, control, runtime, lane, gate, studio, approval, promote라는 흐름으로 연결되어 있다는 점에 있습니다.

의존성

• Git
• gitleaks
• Bun
• Wezterm (Wanderer 역할을 사용할 경우의 메시지 주고받기)
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS를 통한 메시지 통신

"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}

비제휴 및 면책 사항

Garelier는 OpenAI, Anthropic, Claude Code, Codex CLI와 공식적인 제휴, 승인, 스폰서 관계가 아닙니다.

Claude Code, Codex CLI 및 기타 제품명·서비스명은 각 소유자의 상표 또는 서비스명입니다.

또한, Garelier는 현재 상태 그대로(as-is) 제공됩니다.

프로젝트 적용, 외부 조작, 생성물 확인, AI 실행 CLI의 이용 판단은 이용자의 책임하에 이루어져야 합니다.

요약

Garelier는 AI 코딩을 빠르게 보이게 만들기 위한 얇은 보조 도구가 아닙니다.

AI 에이전트에게 장시간 또는 여러 역할 (Role)을 수행하게 할 때, 사양 (Specification), 진행 상황 (Progress), 작업 위치 (Workspace), 리뷰 (Review), 안전 확인 (Safety Check), 승인 (Approval), 승격 (Promotion)을 분리하여 관리하기 위한 프레임워크입니다.

Full Garelier의 중심은 다음과 같은 흐름입니다.

User
-> PM
-> Blueprint
...

Garelier의 목표는 AI에게 자유롭게 작업을 맡기는 것이 아닙니다.

AI가 강력해졌기 때문에, 어디까지 맡기고, 어디서 멈추며, 어떤 판정을 통과시키고, 언제 인간이 승인할지를 명시하는 것입니다.

이를 위한 제어 계층 (Control Layer)이 바로 Garelier입니다.

Discussion