Fabro: 에이전트를 지켜보는 대신 작업 절차를 Graphviz 그래프로 정의해 실행하는 오케스트레이터

9bow · 9월 4, 2026, 9:30오전

Fabro 소개

코딩 에이전트를 실무에 도입하면 선택지가 둘로 좁혀집니다. 에이전트가 실행되는 동안 화면을 지켜보며 매 단계 방향을 잡아 주거나, 손을 떼고 나중에 50개 파일이 바뀐 diff를 한꺼번에 받아 검토하는 것입니다. 지켜보는 방식에서는 개발자가 에이전트의 속도에 묶여 대기 시간이 그대로 낭비되고, 나중에 검토하는 방식에서는 검토 부담이 사람이 처리할 수 있는 양을 넘어섭니다. 어느 쪽이든 절차가 사람의 머릿속에만 있어서 다음 작업에서 그대로 재현되지도 않습니다.

이번에 소개할 Fabro는 그 절차를 파일로 꺼내 놓는 오케스트레이터입니다. 어떤 단계를 어떤 순서로 실행하고 어느 모델에 맡기고 어디서 사람이 판단할지를 Graphviz DOT 파일에 그래프로 적어 두면, Fabro가 그 그래프를 따라 에이전트와 셸 명령과 사람 승인을 차례로 실행합니다. 그래프 파일은 텍스트라 diff를 볼 수 있고 리뷰와 버전 관리가 되므로, 팀이 쓰는 개발 절차를 소스 코드처럼 다룰 수 있습니다.

Fabro는 Qlty Software가 Rust로 개발해 MIT 라이선스로 공개한 프로젝트입니다. 런타임(Runtime) 의존성이 없는 단일 실행 파일 하나로 배포되어 Python이나 Node.js, Docker를 미리 깔아 두지 않아도 됩니다. Qlty가 함께 운영하는 상용 코드 품질 제품 Qlty와는 별개의 저장소이고, Fabro 자체에는 유료 등급이 없어 개인 노트북에서 실행하든 사내 서버에 올리든 같은 이미지와 같은 워크플로우 엔진을 씁니다.

Fabro와 기존 코딩 에이전트 사용 방식 비교

같은 작업을 세 가지 방식으로 처리할 때 무엇이 달라지는지 정리하면 다음과 같습니다:

항목	에이전트 REPL을 지켜보기	CI 파이프라인에 맡기기	Fabro
절차가 어디에 있는가	사람의 머릿속과 대화 기록	YAML 설정 파일	`.fabro` 그래프 파일
분기와 되돌림	사람이 그때그때 판단	통과와 실패 두 갈래	조건 분기, 반복, 병렬, 사람 게이트
사람이 개입하는 지점	모든 단계	없음	그래프에 지정한 게이트에서만
단계별 모델 선택	세션 전체가 한 모델	해당 없음	노드마다 스타일시트 규칙으로 지정
실행 기록	대화 스크롤	잡 로그	이벤트, 체크포인트, Git 브랜치 커밋

가운데 열이 비교의 기준점입니다. CI 파이프라인은 절차를 파일로 적어 둔다는 점에서 Fabro와 같은 편에 있지만, 통과와 실패라는 두 신호로 설계되어 있어 에이전트가 만들어 내는 양과 판단의 미묘함을 감당하지 못합니다. Fabro는 그 자리에 조건 분기와 반복, 병렬 실행, 그리고 사람이 선택하는 게이트를 넣습니다.

모델을 작업마다 바꿔 쓰는 것도 다릅니다. 에이전트 세션 하나는 보통 한 모델로 끝까지 가는데, 요청 단위로 모델을 갈아 주는 Weave Router 같은 프록시가 그 자리를 메워 왔습니다. Fabro는 프록시 계층이 아니라 그래프 노드에 규칙을 붙여 계획 단계는 저렴한 모델에, 구현 단계는 프런티어 모델에 배정합니다.

Fabro는 누구에게 맞는가

같은 형태의 작업을 반복하면서 그 절차를 팀이 공유해야 하는 소규모 전문 개발 팀에게 Fabro가 가장 잘 맞습니다. 그래프 파일이 저장소에 들어가므로 절차 자체를 리뷰하고 개선할 수 있고, 검증 단계를 그래프에 박아 두면 실패할 때마다 수정 루프가 자동으로 돌아갑니다. 24시간 돌려야 하는 작업이나 노트북 밖에서 격리해 실행해야 하는 작업이 있다면 자체 호스팅 모드가 그 요구를 받습니다.

반대로 한 번만 하고 끝나는 작업이나 탐색적인 작업에는 Fabro가 오히려 부담입니다. 절차가 아직 정해지지 않은 일을 그래프로 적으려면 그래프를 먼저 설계해야 하는데, 그 비용은 대화창에서 바로 시작하는 것보다 큽니다. 또한 Fabro는 CLI만으로 끝나지 않고 서버로 동작하므로 fabro server start 로 서버를 띄우고 브라우저 설치 마법사를 한 번 거쳐야 합니다. 클라우드 샌드박스는 Daytona의 VM을 쓰므로 그쪽 환경을 따로 준비해야 합니다. 성숙도도 함께 볼 항목입니다. GitHub 릴리즈가 모두 -nightly 접미가 붙은 프리릴리즈로만 올라와 있고 안정 릴리즈 태그는 아직 없으며, Homebrew 포뮬러 이름도 fabro-nightly 입니다.

Fabro의 워크플로우 그래프와 노드 유형

Fabro의 워크플로우는 Graphviz DOT 문법으로 적습니다. 아래는 사람이 계획을 승인한 뒤에 에이전트가 코드를 쓰는 계획 승인 구현 워크플로우이고, 그래프를 그림으로 그리면 다음과 같습니다:

Fabro의 계획 승인 구현 워크플로우 그래프

같은 워크플로우의 DOT 원문입니다:

digraph PlanImplement {
    graph [
        goal="Plan, approve, implement, and simplify a change"
        model_stylesheet="
            *        { model: claude-haiku-4-5; reasoning_effort: low; }
            .coding  { model: claude-sonnet-4-5; reasoning_effort: high; }
        "
    ]

    start [shape=Mdiamond, label="Start"]
    exit  [shape=Msquare, label="Exit"]

    plan      [label="Plan", prompt="Analyze the goal and codebase. Write a step-by-step plan.", reasoning_effort="high"]
    approve   [shape=hexagon, label="Approve Plan"]
    implement [label="Implement", class="coding", prompt="Read plan.md and implement every step."]
    simplify  [label="Simplify", class="coding", prompt="Review the changes for clarity and correctness."]

    start -> plan -> approve
    approve -> implement [label="[A] Approve"]
    approve -> plan      [label="[R] Revise"]
    implement -> simplify -> exit
}

노드의 실행 방식은 type 속성이 정하고, type 이 없으면 Graphviz shape 이 정합니다. 둘 다 없을 때는 script 속성이 있는 노드가 명령 노드가 되고 나머지는 모두 에이전트 노드가 됩니다. 주요 노드 유형은 다음과 같습니다:

노드	Graphviz shape	동작
에이전트(Agent)	`box`	셸, 파일 편집, 서브 에이전트 도구를 쓰는 LLM을 에이전틱 루프로 실행
프롬프트(Prompt)	`tab`	도구 없이 LLM 호출 한 번, 분석과 요약에 사용
명령(Command)	`parallelogram`	설정된 샌드박스 안에서 셸 스크립트를 실행하고 출력을 다음 노드의 맥락으로 전달
사람(Human)	`hexagon`	워크플로우를 멈추고 사람이 경로를 고를 때까지 대기, 나가는 간선의 라벨이 선택지
대기(Wait)	`insulator`	지정한 시간만큼 멈춤
조건(Conditional)	`diamond`	실행 맥락의 값으로 간선을 선택, 조건 없는 간선이 기본 경로
병렬 분기(Parallel)	`component`	여러 분기를 동시에 실행, 기본 동시 실행 수는 4
병합(Merge)	`tripleoctagon`	모든 분기가 끝난 뒤 합류

에이전트 노드에는 fidelity 속성으로 앞 단계의 맥락을 얼마나 넘길지 지정할 수 있습니다. 기본값인 compact 는 앞 단계들의 구조화된 요약을 넘기고, full 은 요약 없이 전체 맥락을, truncate 는 목표와 실행 ID만 넘깁니다. 긴 워크플로우에서 앞 단계 출력이 뒤 단계의 컨텍스트를 다 잡아먹는 문제를 노드 단위로 조절하는 장치입니다.

다만 병렬 분기에는 저장소가 밝혀 둔 주의 사항이 있습니다. 모든 분기가 같은 체크아웃과 같은 작업 디렉토리 를 공유하므로 한 분기의 파일 변경이 다른 분기에 즉시 보입니다. Fabro는 분기별로 파일을 격리하지 않고 경로를 잠그지도, 충돌을 감지하지도, 겹치는 쓰기를 경고하지도 않습니다. 그래서 작업 공간 변경이 결정적이어야 한다면 분기를 읽기 전용으로 설계하거나 분기마다 겹치지 않는 파일과 디렉토리를 배정해야 합니다.

Fabro가 모델을 고르는 방식

노드마다 모델을 손으로 적는 대신, Fabro는 그래프 속성 model_stylesheet 에 CSS와 비슷한 규칙을 씁니다. 위 예시에서 * 규칙은 모든 노드에 Haiku를 낮은 추론(reasoning) 강도로 배정하고, .coding 클래스가 붙은 implement 와 simplify 노드는 Sonnet을 높은 추론 강도로 받습니다. 선택자와 적용 우선순위는 다음과 같습니다:

선택자	문법	대상	우선순위
전체	`*`	모든 노드	0
shape	`box`, `tab`, `hexagon` 등	해당 Graphviz shape를 가진 노드	1
클래스	`.classname`	`class="classname"` 인 노드	2
ID	`#nodeid`	그 ID를 가진 노드 하나	3

토큰 비용을 줄이는 작업이 스타일시트 한 줄 수정으로 끝난다는 것이 이 설계의 실용적인 이점입니다. 루트 그래프의 스타일시트는 MiniJinja 템플릿이기도 해서 실행 입력과 서버 변수를 읽을 수 있지만, goal 과 env, secrets 는 노출되지 않습니다. 저장소는 사용자 입력을 스타일시트 문법에 그대로 끼워 넣지 말고 정해진 선언으로 매핑하라고 안내합니다.

Fabro가 실행을 기록하고 검증하는 방식

아래 그림은 작성 시점(Author Time)의 파일들이 런타임에서 어떻게 처리되는지를 보여 주는 저장소의 구조 도식입니다. .fabro 워크플로우와 .toml 실행 설정과 .env API 키가 그래프 파서를 거쳐 워크플로우 엔진으로 들어가고, 노드 핸들러가 LLM 제공자와 샌드박스와 사람 입력을 외부 의존성으로 호출합니다:

여기서 노드와 스테이지의 구분이 이 기록 구조의 핵심입니다. 노드는 작성 시점에 그래프 파일에 정의한 단계이고, 스테이지는 그 노드가 실제로 실행된 것입니다. 선형 워크플로우에서는 노드 하나가 스테이지 하나를 만들지만, 구현과 테스트와 수정이 반복되는 루프에서는 같은 노드가 한 번의 실행 안에서 여러 스테이지를 만듭니다. 그래서 그래프 화면은 노드를 보여 주고 실행 타임라인은 스테이지를 보여 주며, 스테이지마다 입력과 출력, 소요 시간, 토큰 사용량이 따로 기록됩니다.

단계마다 코드 변경과 실행 메타데이터를 Git 브랜치에 커밋하는 것도 기록 장치입니다. 저장소는 이를 근거로 어느 변경이든 이어서 실행하거나 되돌리거나 추적할 수 있다고 설명합니다. 검증은 테스트 스위트와 린터, 타입 검사기, 그리고 LLM을 심사자로 쓰는 방식(LLM-as-judge)을 그래프에 계층으로 넣어 처리하고, 실패하면 수정 루프가 자동으로 이어집니다.

실행 화면은 웹 UI로도 제공됩니다. 아래는 저장소가 공개한 Runs 화면으로, 작업이 Working, Pending, Verify, Merge 네 단계에 나뉘어 있고 각 카드에서 실행을 들여다보거나(Watch) 도중에 방향을 바꾸거나(Steer) 에이전트가 던진 질문에 답할 수 있습니다:

Fabro 설치와 실행

설치 방법은 네 가지입니다. 앞의 두 가지는 코딩 에이전트에게 설치 안내 문서를 그대로 넘기는 방식입니다:

# Claude Code로
curl -fsSL https://fabro.sh/install.md | claude

# Codex로
codex "$(curl -fsSL https://fabro.sh/install.md)"

# Homebrew로
brew install fabro-sh/tap/fabro-nightly

# Bash로
curl -fsSL https://fabro.sh/install.sh | bash

릴리즈 바이너리와 멀티 아키텍처 Docker 이미지에는 SLSA(Supply-chain Levels for Software Artifacts) 빌드 출처 증명(Build Provenance attestation)이 함께 배포되므로, 받은 산출물이 저장소의 GitHub Actions 워크플로우에서 빌드된 것인지 확인할 수 있습니다.

설치한 뒤에는 서버를 띄우고 프로젝트마다 초기화합니다:

fabro server start     # 브라우저에서 설치 마법사가 열립니다
                       # 마법사가 끝나면 서버가 종료되므로, 다시 실행해 사용합니다

cd my-project
fabro repo init        # 프로젝트마다 한 번

헤드리스(Headless) 환경이나 스크립트로 설정해야 하면 fabro install 이 같은 설정을 CLI 마법사로 진행합니다. 로컬 모드에서 상태는 ~/.fabro/ 아래에 저장되고 CLI는 기본적으로 유닉스 소켓으로 서버와 통신합니다. 팀이 함께 쓰거나 24시간 실행해야 하면 같은 Docker 이미지를 docker compose 로 올리거나 AWS ECS, Cloud Run, Kubernetes 같은 컨테이너 서비스에 배포합니다. 공개 인터넷에서 접근해야 할 때는 Caddy 같은 리버스 프록시를, 사내에서만 접근하게 하려면 Tailscale 서비스를 앞에 두라고 안내합니다.

Fabro의 라이선스

Fabro는 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.

Fabro 공식 홈페이지

Fabro 문서 사이트

Fabro 프로젝트 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임은 이런 글들을 한국어로 정리해 나누고 있습니다. 회원으로 가입하시면 주요 글들을 이메일로 보내드리고, 텔레그램(Telegram)과 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 다음 글을 정리하는 데 힘이 됩니다~