Claude가 로컬 모델에 작업을 위임하도록 만들고 싶었는데, 그게 MAF가 되었습니다.

저는 AI를 더 신뢰할 수 있게 만들고 비용을 덜 지출하고 싶어서 MAF를 만들기 시작했습니다.

제 아이디어는 간단했습니다. 복잡한 추론(reasoning), 계획(planning), 판단(judgment)에는 유료 Claude 기반 모델을 사용하고, 구현 작업은 로컬 모델을 사용하는 것입니다. 비싼 모델은 도움이 되는 곳에만 관여시키고, 로컬 모델에게는 처리할 수 있는 작업을 맡기는 식입니다.

당시 저는 제 워크플로우에 쉽게 맞는 옵션을 찾을 수 없었습니다. 로컬 모델로 실험해 본 것도 실망스러웠습니다. 간단하고 설명이 잘 된 작업은 작동했지만, 툴 호출(tool calls)이나 더 긴 에이전트 워크플로우는 컨텍스트 창(context window)을 초과했습니다.

Claude Code를 사용하기 시작했지만, 여전히 Ollama와 OpenCode를 통해 로컬 모델을 이용해 일부 사이드 태스크를 처리하고 싶었습니다.

저는 여러 접근 방식을 시도했습니다. 먼저 서브 에이전트(subagents) 방식이었고, 그다음에는 Claude Code가 OpenCode에게 간단한 작업을 위임하는 방법을 알려주는 스킬 브릿지(skill bridges)였습니다. 두 하네스(harnesses)—에이전트를 실행하는 툴—간의 자동 통신은 신뢰성이 떨어지거나 너무 많은 Claude 토큰을 사용했습니다.

하지만 진전은 있었습니다. 저는 Claude Code가 OpenCode를 구현하기 위한 지침이 담긴 태스크 파일(task file)을 작성하는 프로세스를 만들었습니다. 하지만 여전히 제가 직접 OpenCode에게 그 파일을 지정해 주어야 했습니다.

공유 보드(shared-board) 아이디어는 EuRuKo에서 Maciej Mensfeld와의 대화에서 나왔습니다. 그는 자신이 가진 에이전트 워크플로우와, 코딩 에이전트를 격리된 Incus 시스템 컨테이너 내에서 실행하는 툴인 Coi (Code on Incus)를 사용해 에이전트를 어떻게 분리했는지 설명했습니다. 그는 또한 칸반(Kanban)-같은 태스크 서비스(task service)를 통해 에이전트들이 조정되는 것에 대해서도 언급했습니다.

저에게 와닿았던 것은 에이전트들이 통신하기 위해 태스크 보드를 사용하는 아이디어였습니다. 저는 비슷한 것을 원했지만, 로컬 환경에서요: 작업을 조정하기 위해 외부 태스크 서비스나 웹 요청은 없어야 했습니다. 에이전트들은 여전히 클라우드 모델을 사용할 수 있지만, 그들의 보드와 메시지는 프로젝트 내에 존재해야 했습니다.

그것은 제가 에이전트들 간에 수동으로 태스크 파일을 전달하는 것을 넘어설 방법을 제시해 주었습니다. 그것이 바로 Multi_Agent_Flow (MAF)가 되었습니다.

다른 에이전트 런타임 대신 공유 보드 사용하기

MAF는 다양한 코딩 에이전트 도구들이 하나의 프로젝트에서 작업을 조정할 수 있게 해주는 접착제 역할을 합니다. MAF가 Claude Code, OpenCode, Codex 또는 Hermes를 대체하는 것은 아닙니다. 해당 도구들은 여전히 에이전트를 실행하며, 각 도구에 대해 설정한 모델 접근을 사용합니다.

사용자 구독으로 Claude Code를 사용하고 로컬 모델로 OpenCode를 사용할 수도 있고, 다른 하네스(harness)와 모델 조합을 선택할 수도 있습니다. MAF는 팀 전체가 동일한 제공업체를 사용할 것을 요구하지 않습니다. 미리 정의된 역할과 워크플로우 예시가 포함되어 있지만, 사용자 스스로도 정의할 수 있습니다.

MAF는 에이전트들이 하나의 저장소(repository)에서 작업을 조정하는 공유 방식을 제공합니다:

• 프로젝트 로컬 Taskwarrior 보드는 목표, 작업 및 주장(claims)을 기록합니다.
• 파일 인박스(File inboxes)는 역할과 워커 간의 메시지를 전달합니다.
• Git worktrees는 워커들에게 별도의 체크아웃을 제공합니다.
• 리소스 락(Resource locks)은 워커들이 공유하는 대상, 예를 들어 로컬 모델 호스트에 대한 접근을 직렬화할 수 있게 합니다.

공통 인터페이스는 coord CLI입니다. 에이전트는 보드를 읽거나 메시지를 보내기 위해 공급업체 SDK가 필요하지 않습니다. 단지 명령어를 실행하면 됩니다.

graphify와 Obsidian vault를 통해 선택적인 공유 메모리 계층(shared-memory layer)도 있습니다. Obsidian은 에이전트의 지식을 탐색하기 쉽게 만듭니다.

또한, 프로젝트 루트에서 .maf/bin/dashboard를 실행하여 시작할 수 있는 웹 대시보드도 있습니다. 여기에는 워커 상태, 작업 보드, 조정 활동이 표시됩니다. 또한 토큰 사용량을 줄일 방법을 제안하는 분석 도구도 포함되어 있습니다.

제가 가장 중요하게 생각하는 부분은 역할별로 도구를 선택하는 것입니다. 계획 및 검토 단계에서는 클라우드 모델을 유지하고, 범위가 지정된 구현 작업(scoped implementation work)은 다른 하네스로 라우팅할 수 있습니다. MAF는 조정 기능을 제공하지만, 로컬 모델이 작업을 정확하게 또는 저렴하게 수행할 것이라고 보장하지는 않습니다.

역할은 모델 이름이 아닌 책임입니다

아키텍트는 목표를 작업으로 분해합니다. 개발자는 이를 구현합니다. 테스터는 동작을 확인합니다. 리뷰어는 결과를 검토합니다.

예를 들어, 앱에 CSV 내보내기 기능을 추가한다고 상상해 봅시다. 아키텍트가 작업과 수용 기준을 정의합니다. 개발자가 이를 맡아 별도의 워크트리에서 구현하고, 테스터가 동작을 확인하며, 리뷰어가 변경 사항(diff)을 검토합니다. 만약 무언가 빠진 것이 있다면, 터미널 간에 메시지를 복사하는 것에 의존하기보다 받은 편지함(inbox)을 통해 피드백을 보냅니다.

프로젝트 관리자는 저와 아키텍트 사이에 앉아 있을 수 있습니다. 제가 결과물을 설명하면, 프로젝트 관리자가 목표를 만들고 보고합니다. 리드 역할들은 구현 작업을 맡지는 않습니다.

하네스(harness)는 역할을 실행하는 도구입니다. 워커(worker)는 해당 역할의 실행 인스턴스입니다. 여러 개의 워커가 동일한 역할을 수행할 수 있습니다.

이러한 구분이 중요한 이유는 제가 프로젝트 구조가 이번 달에 우연히 어떤 모델을 사용하느냐에 따라 의존하고 싶지 않기 때문입니다.

예를 들어, 이 명령어는 혼합된 팀을 구성합니다:

maf add claude:architect opencode:backend-developer claude:reviewer

이 명령은 플로우를 설치하고 역할 파일을 생성합니다. 에이전트를 시작하지는 않습니다.

여기서 OpenCode가 모델이 아니라 하네스입니다. 로컬 구현에 사용하려면, Ollama에서 제공하는 모델을 사용하도록 설정합니다.

미리 정의된 역할에만 국한되지 않습니다. 작가(writer), 편집자(editor), 연구원(researcher), 또는 교정자(proofreader)를 정의하고 각각에게 가장 적합한 하네스와 모델을 할당할 수 있습니다. maf role add NAME은 .maf/roles.yml에 스텁(stub)을 생성하며, 사용자가 책임과 권한을 채웁니다. 또한 아키텍트가 따르도록 자체 워크플로우를 .maf/workflow.md에 작성할 수도 있습니다.

MAF는 프로젝트의 추적 파일에서 제외됨

이 도구는 주요 설치를 .maf/에 유지합니다. 클론의 일반적인 Git 상태에서 이 파일들을 제외하기 위해 .git/info/exclude를 사용합니다. 지식 그래프(knowledge graph)는 graphify-out/에 별도로 존재합니다.

MAF는 또한 Git 훅(hooks)과 하네스별 파일(harness-specific files)을 설치합니다. 이것들은 도구가 설정 자체를 프로젝트의 추적되는 소스 파일 외부로 유지하더라도, 로컬 환경에 실제 변경 사항을 가져옵니다. 깨끗한 Git 상태가 아무것도 변경되지 않았음을 의미하지는 않습니다.

에이전트들의 코드와 프로젝트 문서는 여전히 일반적인 Git 워크플로우를 거칩니다. MAF의 로컬 설정은 그 외부로 유지됩니다.

MAF 실행하는 다양한 방법들

처음에는 모든 하네스를 대화형(interactively)으로 실행했습니다. 그렇게 하면 각 에이전트가 자체 터미널 창에서 무엇을 하는지 볼 수 있었고, 필요할 때 프로세스를 세밀하게 관리(micromanage)할 수 있었습니다.

이제 저는 프로젝트 매니저 역할을 하는 단일 에이전트와 대화합니다. 나머지 팀은 제가 직접 시작하는 터미널에서 --dispatch 모드로 실행됩니다. 디스패처는 작업이나 메시지를 기다리다가, 작업이 생기면 해당 에이전트를 호출합니다. 또한 프로젝트 매니저에게 아키텍트와 함께 팀을 구성해 달라고 요청할 수 있으며, 이는 설정한 워커 제한(worker limits)과 허용된 하네스 내에서 이루어집니다.

주의할 점이 하나 있습니다: 디스패치 모드는 Claude Code, Codex, 그리고 Hermes에 대한 승인 프롬프트(approval prompts)를 우회합니다. OpenCode는 역할 파일(role file)의 권한을 사용합니다. 별도의 작업 트리(worktrees)는 변경 사항들을 분리하는 데 도움이 되지만, 보안 샌드박스(security sandbox)는 아닙니다. 접근 권한을 부여해도 괜찮다고 느끼는 환경에서만 비감독 워커(unattended workers)를 사용하십시오.

어떤 방식이 자신에게 맞는지 확인하기 위해 다양한 접근 방식을 시도해 보세요. 저는 더 많은 부분을 비감독으로 남겨두기 전에 조정 과정을 지켜보고 싶었기 때문에 대화형 세션부터 시작했습니다.

작은 규모로 시도해 보기

전체 팀으로 시작할 필요는 없습니다. 아키텍트와 개발자 한 명으로 시작하여 그들이 어떻게 협력하는지 관찰하고, 필요할 때 다른 역할을 추가하세요.

코디네이션 레이어(coordination layer)를 위해 Ruby 3.0 이상, Git, 그리고 Taskwarrior가 필요합니다. 실제 에이전트 작업을 위해서는 필요한 모델 접근 권한을 가진 코딩 에이전트 하네스가 설치되어 있어야 합니다. Graphify는 선택 사항이지만 공유 지식 측면에서 권장됩니다.

gem install maf
maf version
maf guide

그런 다음 프로젝트에서 코딩 에이전트를 열고 다음과 같이 요청할 수 있습니다:

Run maf guide. Read the output and help me set it up.

MAF는 GitHub에서 오픈 소스로 공개되었고, RubyGems에도 게시되었습니다.

진행하면서 MAF에 대해 에이전트에게 질문할 수 있습니다. 이는 모든 명령어를 먼저 학습하게 하는 대신 사용자 정의 역할(custom roles)이나 워크플로우를 추가하는 과정을 안내해 줄 수 있습니다.

저와 다른 워크플로우를 가진 분들의 피드백을 받고 싶습니다. 만약 MAF를 사용해 보신다면, 어떤 도구들을 사용했는지, 그리고 설정이나 조정 과정에서 어디가 혼란스러웠는지 알려주세요. 버그를 발견하시면 재현 가능한 예시와 함께 이슈(issue)를 열어주시면 감사하겠습니다.