Claude Code를 위한 메타 하네스: Devflow

Claude Code용 메타 하네스(meta-harness). Claude Code는 뛰어난 엔지니어 한 명을 제공합니다. Devflow는 이 주변에 엔지니어링 조직을 설치합니다: 위임하는 오케스트레이터, 전문 에이전트 로스터, 리뷰 문화, 기관 메모리, 그리고 배포 파이프라인입니다. 에이전트 기반 개발(agentic development)을 실제로 제품으로 만드는 팀으로 전환하려는 개발자를 위해 구축되었습니다.

Claude Code는 강력합니다. 하지만 단일 에이전트는 팀이 아닙니다. 모든 세션은 처음부터 시작하며, 대화 사이에 컨텍스트가 사라지고, 리뷰는 일회성이고 피상적이며, 품질은 사용자가 요청하는 것에 달려 있습니다. 부족한 것은 바로 엔지니어링 팀이 제품을 출시하게 만드는 것들입니다: 메모리, 표준, 리뷰 문화, 그리고 배포 프로세스입니다.

Devflow가 이를 해결합니다. 한 번 설치하면 잊어버릴 수 있습니다.

하나의 기능, 네 개의 명령어, 전체적인 시야(bird's-eye view) — 각 명령어는 프롬프트가 아니라 에이전트 파이프라인입니다:

you: /plan add rate limiting to the /api/upload endpoint
Skim · Explore orient in the codebase — relevant modules, existing middleware patterns
Design gap analysis: completeness, security, performance
...

이것이 **오케스트레이션된 흐름(orchestrated flow)**입니다. 사용자는 모든 단계 사이에서 루프 안에 머무릅니다. 주변 모드(ambient mode)를 사용하면 명령어조차 필요하지 않습니다: 작업을 설명하면 오케스트레이터가 동일한 파이프라인을 통해 라우팅합니다.

주변 오케스트레이션(Ambient orchestration). 메인 세션 자체가 테크 리드가 됩니다: 세션 시작 시 주입되는 헌장(charter)은 이를 전문 에이전트에게 작업을 위임하고 판단만을 주요 흐름으로 유지하는 순수 오케스트레이터로 만듭니다. Plan-mode 핸드오프는 자동으로 /implement를 실행합니다.

초기화하고 잊어버리세요.

직원이 배치된 에이전트 로스터(staffed agent roster). 명시적인 모델 할당을 가진 17개의 전문 에이전트가 있습니다 — 분석에는 Opus, 실행에는 Sonnet, I/O에는 Haiku를 사용합니다. devflow agents를 통해 모든 에이전트의 모델을 재할당할 수 있으며, 외부 모델 라우팅(devflow proxy)을 통해 GPT 모델도 포함됩니다.

최대 20개의 병렬 Review 에이전트. 보안(Security), 아키텍처, 성능, 복잡성, 일관성, 회귀(Regression), 테스트 등 다양한 측면을 검토합니다. 각 에이전트는 심각도(severity), 신뢰도 점수(confidence scoring) 및 구체적인 수정 방안과 함께 발견 사항을 생성합니다. 조건부 Review 에이전트는 관련성이 있을 때 활성화됩니다 (예: .ts 파일의 TypeScript, 스키마 변경을 위한 데이터베이스, diff에서 규제된 표면이 감지될 때의 컴플라이언스). 모든 발견 사항은 자동으로 검증 및 해결됩니다.

영속적인 메모리. 세션 컨텍스트는 재시작, /clear, 그리고 컨텍스트 압축에도 살아남습니다. 에이전트는 이전에 멈춘 지점부터 정확하게 작업을 이어갑니다.

자가 학습(Self learning). 백그라운드 에이전트가 사용자의 세션 대화에서 아키텍처 결정 사항과 알려진 함정(pitfalls)을 감지하고 이를 .devflow/learning/decisions.md 및 .devflow/learning/pitfalls.md에 기록합니다. 이는 수동으로 정리할 필요 없이 모든 향후 검토 및 구현 세션에 정보를 제공합니다.

기능 지식 기반(Feature knowledge bases). 기능 영역별로 큐레이션된 KNOWLEDGE.md 파일을 통해 패턴, 관례(conventions), 그리고 주의해야 할 점(gotchas)을 팀과 공유할 수 있습니다 — 이 파일들은 git으로 추적되며 공유됩니다. 계획(Planning), 구현(implementation), 검토 워크플로우가 이를 자동으로 로드하고 변경 후 새로 고칩니다.

항상 활성화된 규칙(Always-on rules). 13가지의 초압축 엔지니어링 원칙(각 약 10줄)이 모든 프롬프트에 로드됩니다 — 보안, 품질, 그리고 언어별 가이드라인(TypeScript, React, Go, Python, Java, Rust), 그리고 컴플라이언스가 활성화된 경우 컴플라이언스 규칙도 포함됩니다. 규칙은 사용자가 선택한 플러그인에서만 설치되므로, Go 프로젝트에 React 규칙이 적용되지 않습니다. ~/.devflow/rules/{name}.md 또는 devflow rules shadow <name>을 통해 모든 규칙을 재정의할 수 있습니다.

41개의 스킬(skills) (플러그인 소유 40개 + 기능 소유 규정 준수 스킬 1개로, 모든 장치에 설치됨).스킬은 선택한 플러그인과 해당 플러그인이 사용한다고 선언하는 모든 것을 위해 설치됩니다. 따라서 기본 플러그인 세트는 40개 중 32개를 설치하며, Go 프로젝트는 React 스킬을 절대 받지 못합니다. 대부분의 스킬은 전문가 자료에 기반하고 있습니다 — 동료 검토 논문(peer-reviewed papers), 정전식 서적(canonical books), 산업 표준으로 뒷받침됩니다: 보안(OWASP, Shostack), 아키텍처(Parnas, Evans, Fowler), 성능(Brendan Gregg), 테스트(Beck, Meszaros), 디자인(Wlaschin, Hickey), 규정 준수(GDPR, HIPAA, PCI DSS, SOC 2, ISO 27001, SOX, NIST SSDF, OWASP ASVS) 등 총 200개 이상의 출처가 있습니다.

스킬 섀도잉(Skill shadowing). 내장된 스킬을 자신만의 버전으로 덮어쓸 수 있습니다. 파일을 ~/.devflow/skills/{name}/에 넣으면, 설치 프로그램은 기본값 대신 사용자의 것을 사용합니다 — 활성화 방식은 동일하지만 규칙은 사용자 정의입니다. 플러그인 선택 범위 밖에 있는 스킬의 섀도우는 원래 자리에 남아 있습니다: 설치되지 않고, 절대 삭제되지 않으며, 해당 플러그인을 다시 선택하는 순간 살아납니다.

내장된 규정 준수(Compliance built in). 여섯 가지 규제 프레임워크 — GDPR, HIPAA, PCI DSS, SOC 2, ISO 27001, SOX. 모든 설치에는 여섯 가지 프레임워크 참조를 포함하는 검토 스킬이 함께 제공됩니다: devflow compliance --enable은 사용자가 선택한 정확한 프레임워크에 대한 항상 활성화된 규칙을 추가합니다. 저장소는 .devflow/project.json에서 자체 프레임워크를 선언할 수 있습니다 (`

, 또는 devflow tracker --set <id>를 통해 나중에 설정할 수 있습니다.; 이는 사용자의 기기 기본값으로 설정합니다. 저장소는 .devflow/project.json에서 자체 프레임워크를 선언할 수 있으며, devflow는 그곳의 설정을 자동으로 따릅니다 — 하나의 기기로 Jira 저장소와 GitHub 저장소를 나란히 작업할 수 있습니다. 모든 설치에는 모든 제공업체의 메커니즘(47개의 생성된 참조 파일, 이들 중 도구 호출 계약 포함)과 백그라운드 에이전트가 포함됩니다. 왜냐하면 풀 리퀘스트는 사용자가 어떤 트래커나 저장소를 선택하든 GitHub에 머무르기 때문입니다. GitHub가 아닌 트래커에서 해당 에이전트는 제공업체당 한 번(프로젝트 키, 이슈 유형, 필수 필드, 워크플로우 전환, 참조 렌더링 방식 등) 사용자의 관례를 학습하고 이를 ~/.devflow/tracker/{provider}.md에 작성합니다. 따라서 추적 가능성은 #123을 가정하는 대신 사용자의 트래커의 어휘를 구사하게 됩니다. 각 제공업체의 관례는 그것을 처음 사용하는 저장소에서 학습됩니다. 이 파일들은 사용자 소유이며: 수동으로 편집할 수 있고, 제거 과정에서도 유지되며, 만약 어떤 것이 더 이상 자체 제공업체를 명시하지 않는다면 조용히 신뢰하는 대신 거부합니다. GitHub가 기본값이며 설정이 필요 없습니다: 백그라운드 실행이나 관례 파일이 없습니다.

전체 수명 주기. 핵심 흐름을 넘어: /explore는 코드베이스를 지식 기반으로 매핑하고, /research는 신뢰 인식 합성(trust-aware synthesis)을 통해 다중 유형의 리서치를 수행하며, /debug는 경쟁 가설들을 병렬로 조사하고, /bug-analysis는 검토 전에 버그를 찾아내며, /self-review는 Simplify + Scrutinize 품질 점검을 실행하고, /release는 학습된 설정으로 배포합니다.

모든 것이 조합 가능합니다. 21개의 플러그인(핵심 12개 + 선택적 9개). 필요한 것만 설치하세요.

HUD. 지속적인 상태 표시줄이 모든 프롬프트마다 업데이트됩니다 — 프로젝트, 브랜치, diff 통계, 컨텍스트 사용량, 모델, 주간/월간 합계를 포함한 비용, 할당량 재설정 타이머 및 설정 개수 등을 한눈에 확인할 수 있습니다.

~/devflow · main · +2 -1 · v2.0.0+3
Context ████░░░░ 42% · 5h ████░░░░ 45% (2h 15m) · 7d ████████ 70% (3d 12h)
Opus 4.6 (1M) · 3 MCPs 2 rules · $1.42 · $18.50/wk · $62.30/mo

보안(Security). Deny 리스트는 위험한 도구 패턴을 기본적으로 차단하며, 초기화 시 구성하거나 devflow security로 언제든지 토글할 수 있습니다.

(--enable
/--disable
/--status
).

프롬프트 엔지니어링은 컨텍스트 엔지니어링이 되었고, 현재의 최전선은 **그래프 엔지니어링(graph engineering)**입니다. 이는 에이전트 기반 작업(agentic work)을 긴 대화가 아닌 노드, 의존성 및 게이트의 명시적 그래프로 설계하는 것입니다. Devflow는 이를 즉시 사용할 수 있는 레시피 형태로 제공합니다.

어떤 상황에 무엇을 사용해야 하는지: 오케스트레이션된 흐름(orchestrated flow)은 **기능(feature)**용이며, 그래프 워크플로우는 **시스템(system)**용입니다. 사양(spec)에서 시작하여 티켓의 의존성 그래프로 분해한 다음, 웨이브별로 전달합니다. 즉, 하나의 웨이브를 계획하고, 하나의 웨이브를 구축하며, 사양이 배포될 때까지 반복합니다:

you: /dynamic-tickets specs/billing-v2.md
Ticket factory spec → 14 dependency-graphed tickets across 4 waves
each ticket adversarially reviewed
...

그래프 실행은 토큰을 자율성(autonomy)과 교환합니다. 각 웨이브의 의사 결정 게이트에서 호출을 수행하면, 그 웨이브가 구축합니다. 단일 빌드 실행만으로 20시간 이상 무인 상태로 진행될 수 있습니다. 실제로는 일상적으로 오케스트레이션된 흐름 내에서 활동하게 되며, 전체 시스템을 배포할 때 그래프 워크플로우를 사용하게 됩니다. 둘 다 동일한 에이전트, 품질 게이트(quality gates), 메모리 및 학습된 결정을 공유합니다.

npx devflow-kit init

그게 전부입니다. 이 대화형 마법사(interactive wizard)는 권장 기본값(Recommended defaults) 또는 고급 흐름(Advanced flow)을 제공하며, 플러그인 선택, 기능 구성, 규정 준수 프레임워크 및 보안 설정을 포함합니다. 주변 모드(Ambient mode), 작업 메모리(working memory), 학습은 기본적으로 활성화되어 있습니다. 비대화형 방식은 npx devflow-kit init --recommended입니다.

.
Devflow가 생성하는 모든 것은 .devflow/ 아래에 존재합니다.

— 작업 메모리, 결정 및 함정(pitfalls), 기능 지식 기반(feature knowledge bases), 명명 규칙(naming conventions), 문서(docs) 및 임시 잠금 파일(transient locks). 처음 사용할 때 Devflow는 프로젝트 루트의 .gitignore 파일에 하나의 블록을 추가합니다.

. 이는 개발자별 런타임 상태를 사용자의 기기에 유지하고, 세 가지 항목을 통해 git으로 공유합니다: 기능 지식 기반(feature knowledge bases), 학습된 명명 규칙(learned naming conventions), 그리고 .devflow/project.json에 있는 팀 설정입니다.

이것들은 증거 정책(evidence policy)을 담고 있습니다:

# Devflow 런타임 데이터 — 기본적으로 로컬 (메모리, 학습, 문서, 잠금 파일).
# git으로 공유: .devflow/features/ 아래의 기능 지식 기반 (index.md 및
# 모든 {slug}/KNOWLEDGE.md), .devflow/conventions.md (명명 권한), ...

!.devflow/policy.json

라인은 팀 동료들이 이전 버전의 devflow를 사용할 때도 정책 파일을 읽을 수 있도록 퇴임된(retired) 정책 파일을 유지합니다 (증거 정책 참조). 사용자의 블록이 라인보다 앞설 경우, 다음 훅 실행 또는 devflow init이 누락된 라인을 해당 블록 내부에 삽입하며, 새로운 블록은 이를 가지고 있습니다 — 파일의 끝에는 절대 아닙니다. 따라서 자신을 더 아래에서 다시 무시(re-ignore)하더라도 여전히 유효합니다. 쌍으로 된 라인들—!.devflow/features/
그리고 .devflow/features/*—는 필수적입니다: git은 재포함되는 파일을 찾기 위해 제외된 디렉토리 안으로 절대 내려가지 않습니다. 마지막 .claudeignore
라인은 사용자의 .gitignore가 이미 자체적인 .claudeignore 또는 !.claudeignore 항목을 가지고 있을 때는 생략됩니다.

지식 기반이나 명명 규칙을 로컬로 유지하려면, .devflow/features/ 또는 .devflow/conventions.md를 자신의 .gitignore에 추가하세요. /.devflow/ 라인은 프로젝트 전체를 제외하도록 선택합니다: Devflow는 사용자의 .gitignore를 그대로 둡니다.

자세한 사용법은 docs/commands.md를 참조하세요.

PR 댓글 게시는 /code-review와 /resolve의 경우 가시성 게이트(visibility-gated)입니다 (기본적으로 공개 저장소에서는 카운트만 표시하는 스텁). 그리고 게시되는 모든 본문은 사용자의 기기를 떠나기 전에 비밀 정보가 제거됩니다(secret-scrubbed). 이는 개인 .devflow/config.json 파일의 reviewPublication(auto, full 또는 off)을 통해 설정할 수 있습니다.

또한, .devflow/project.json에 있는 팀 값은 단지 상한선일 뿐입니다: 이 값을 낮출 수는 있지만, 높일 수는 없습니다. required 증거 정책 하에서는 off로 설정해도 카운트만 표시하는 스텁이 게시되어 PR에 기록이 남습니다. 테스트 계획 증거 댓글은 reviewPublication이 full이 아닌 경우 스텁입니다 — 자세한 내용은 docs/commands.md를 참조하세요.

저장소는 팀 전체의 선택을 확정하기 위해 .devflow/project.json을 커밋할 수 있습니다. 모든 키는 선택 사항이며, 알 수 없는 키는 무시되고, devflow는 이 파일을 절대 작성하지 않습니다: