서론

• Trellis는 "14개 이상의 플랫폼에 걸쳐 AI 코딩 에이전트에게 일관된 엔지니어링 워크플로우를 제공하는 것"을 목표로 하는 제3자 오픈 소스 템플릿(@mindfoldhq/trellis)입니다.
• OpenSpec은 이와 유사한 제3자 오픈 소스 프레임워크(@fission-ai/openspec)로, "스펙 기반 개발 (spec-driven development)"을 목표로 하며 델타 스펙 (delta specs)을 통해 변경 사항을 관리합니다.
• **AGE (Attractor-Guided Engineering)**는 nop-chaos-flux의 관행에서 성장한 방법론으로, 상태 공간 (state space) → 어트랙터 (attractor) → 궤적 (trajectory) → 제어 (control)라는 핵심 아이디어를 가지고 있습니다.
  • WeChat 공식 계정 시리즈 기사:
  • 《Harness 이전의 Attractor: 대규모 AI 개발을 위한 방법론》
  • 《스펙 기반 개발에서 Attractor-Guided Engineering으로》
  • 《왜 Attractor-Guided Engineering은 AI 에이전트 기술로 격하될 수 없는가》
  • 《제어 계층과 방향 계층 사이의 격차: OpenProse, NLAHs, 그리고 AGE》
• AGE는 많은 고정된 도구들을 전제하지 않습니다. 대신 도구는 실패가 반복되는 지점에서 점진적으로 나타나야 함을 강조합니다: 반복되는 오류 → 버그 노트 (bug note) → 교훈 (lesson) → 기술/프롬프트 (skill/prompt) → 감사 스크립트 (audit script) → 린트 규칙 (lint rule) → CI 가드 (CI guard).
• 핵심 발견: Trellis와 OpenSpec의 공통적인 한계는 두 방식 모두 **단일 변경 사항 (single change)**을 조직 단위로 사용한다는 점이며, 저장소 전반의 진실 (repository-wide truth)과 완전한 AI 자동화로 진화하기 위한 지원 역량이 부족하다는 것입니다. 이 분석은 AGE의 이론적 프레임워크에서 시작하여 세 가지 방식 간의 근본적인 차이점을 비교합니다.

분석

1. 포지셔닝: 세 가지 방식의 정체

Trellis:

• **제품화된 엔지니어링 프레임워크 (productized engineering framework)**로, npm install -g @mindfoldhq/trellis && trellis init을 통해 설치합니다.
• 3단계 워크플로우 (Plan → Execute → Finish), 태스크 관리 스크립트, 스펙 시스템 (spec system), 서브 에이전트 디스패치 (sub-agent dispatch), 그리고 멀티 플랫폼 훅 (multi-platform hooks)을 제공합니다.
• 툴체인 (toolchain)은 설계 시점에 결정됩니다: trellis-brainstorm, trellis-check, trellis-update-spec, trellis-break-loop 등과 같은 12가지 스킬 (skills)이 포함됩니다.
• 5가지 핵심 원칙: 코드 작성 전 계획 (Plan before code), 기억하는 것이 아닌 주입되는 스펙 (Specs injected not remembered), 모든 것을 영구 저장 (Persist everything), 점진적 개발 (Incremental development), 학습 내용 캡처 (Capture learnings).

OpenSpec:

• **제품화된 스펙 주도형 프레임워크 (productized spec-driven framework)**로, npm install -g @fission-ai/openspec && openspec init을 통해 설치합니다.
• 핵심 모델은 스펙 + 델타 + 아카이브 (spec + delta + archive) 사이클입니다: specs/ (신뢰할 수 있는 단일 원천, source of truth) ← merge ← changes/ (델타 스펙, delta specs).
• 각 변경 사항은 스키마 의존성 그래프 (schema dependency graph)에 따라 생성된 네 가지 산출물(artifacts) — 제안 (proposal) → 스펙 (specs) → 설계 (design) → 태스크 (tasks) — 을 포함합니다.
• 델타 스펙 (Delta specs)은 ADDED/MODIFIED/REMOVED를 사용하여 점진적 수정을 설명하며, 아카이브 시 메인 스펙으로 다시 병합(merge)됩니다.
• 4가지 철학: 경직되지 않은 유연함 (fluid not rigid), 폭포수 모델이 아닌 반복적 방식 (iterative not waterfall), 복잡하지 않은 간결함 (easy not complex), 브라운필드 우선 (brownfield-first).
• 25개 이상의 AI 도구에 대한 슬래시 커맨드 (slash command) 통합을 지원합니다.

AGE:

• 제품이 아닌 **방법론 (methodology)**입니다. npm 패키지도, 설치 명령어도 없습니다.
• AGE 템플릿은 문서의 책임과 프로세스를 정의하는 복사하여 사용하는 문서 스켈레톤 (https://github.com/entropy-cloud/attractor-guided-engineering-template)이며, 범용 도구(check-doc-links, check-oversized-files 등)가 함께 제공됩니다. 도메인 특화 도구는 실제 관행으로부터 추출해야 합니다.
• AGE 저자는 서로 다른 도메인에서 완전한 AGE 관행을 보여주는 몇 가지 대규모 예시 프로젝트를 오픈 소스로 공개했습니다:
  • nop-chaos-flux (https://github.com/entropy-cloud/nop-chaos-flux): 15개의 감사 파일(11개의 스캐너 포함), 22개의 프롬프트 (prompts), 66개의 버그 노트 (bug notes), 72개의 로그 (logs)를 포함하는 프론트엔드 로우코드 (low-code) 프레임워크입니다.
  • nop-entropy (https://github.com/entropy-cloud/nop-entropy): docs-for-ai/ 규범 문서와 ai-dev/ 개발 메모리 트랙 (development memory tracks)을 갖춘 백엔드 풀스택 (full-stack) 프레임워크입니다.
  • nop-chaos-next (https://gitee.com/canonical-entropy/nop-chaos-next): design/, input/, logs/, skills/를 활용한 경량화된 실습을 제공하는 애플리케이션 계층 프로젝트입니다.
• 이론적 프레임워크: 상태 공간 (state space) → 어트랙터 (attractor) → 궤적 (trajectory) → 제어 (control); 모든 실습 요소는 이로부터 도출될 수 있습니다.

2. 도구의 기원: 사전 설정 vs. 점진적 발생

Trellis는 12개의 내장된 기술 (skills)을 가지고 있습니다. 반면 AGE의 도메인 도구는 스스로 축적하거나 다른 프로젝트에서 빌려와야 합니다.

Trellis: 설계 시점에 결정되는 도구

Trellis의 12가지 기술은 프로젝트 생성 시점에 이미 존재합니다:

이러한 기술들은 범용적이며 특정 프로젝트와 무관합니다. 사용자들은 버그 이력이나 감사 결과(audit findings) 없이도 이러한 도구들을 사용할 수 있습니다. 이들 중 trellis-break-loop와 trellis-update-spec은 실패로부터 지식을 추출하는 메커니즘을 형성합니다 (자세한 내용은 섹션 3 참조).

AGE: 실무로부터 점진적으로 추출된 도구들

nop-chaos-flux에서의 도구 성장 체인은 명확하게 관찰됩니다:

체인 1: 하드코딩된 타입 디스패치 (hardcoded type dispatch) → 감사 스크립트 (audit script)

버그 발견: 렌더러 내 하드코딩된 타입 스위치 (hardcoded type switch)
  → 감사 결과 (audit finding): "렌더러는 레지스트리(registry)를 통해 디스패치해야 한다"는 아키텍처 계약 위반
  → 플랜 430: eliminate-hardcoded-type-dispatch-plan
...

체인 2: 누락된 렌더러 마커 (missing renderer markers) → 감사 스크립트 (audit script)

버그 발견: 렌더러가 계약에 따라 마커 클래스 (marker class)를 출력하지 않음
  → 심층 감사 차원 09에서 여러 번 나타남
  → 스크립트로 추출됨: scripts/audit/find-missing-renderer-markers.mjs

체인 3–5: 부정확한 반응형 구독 (imprecise reactive subscriptions), 실패 경로가 없는 비동기 (async without failure path), React 19 레거시 API → 각각에 대응하는 감사 스크립트가 존재함.

nop-entropy 또한 동일한 패턴을 따릅니다:

버그 발견: Java 코드에서 가공되지 않은 RuntimeException 사용
  → 컨벤션 (convention): NopException 하위 클래스를 사용해야 함
  → ast-grep 규칙으로 추출됨: ai-dev/tools/rules/java-lint-bare-runtimeexception.yml

즉시 사용 가능 (Out-of-the-Box) vs. 점진적 축적 (Gradual Accumulation)

새로운 Trellis 프로젝트는 즉시 12가지 기술 전체 + 워크플로우 상태 머신 (workflow state machine) + 크로스 플랫폼 훅 (cross-platform hooks)을 갖게 됩니다. 템플릿에서 시작하는 새로운 AGE 프로젝트는 범용 도구만을 가지고 있지만, nop-chaos-flux, nop-entropy, nop-chaos-next와 같은 오픈 소스 모범 사례를 참조하여 도메인 특화 도구들을 빠르게 구축할 수 있습니다. Trellis는 "오늘 바로 시작하기"에 적합하며, AGE는 "장기적인 진화"에 적합합니다.

3. 실패로부터 지식 추출하기: 서로 다른 깊이의 두 가지 메커니즘

Trellis와 AGE 모두 실패로부터 지식을 추출하지만, 산출물(artifact)의 형태와 자동화 정도가 다릅니다.

Trellis: 산문 형태의 명세(Prose Spec)로 추출

trellis-break-loop는 구조화된 5차원 버그 분석 프레임워크를 제공합니다:

1. 근본 원인 범주 (Root Cause Category): 5개 범주 (명세 누락 (Missing Spec) / 계층 간 계약 위반 (Cross-Layer Contract) / 변경 전파 실패 (Change Propagation Failure) / 테스트 커버리지 격차 (Test Coverage Gap) / 암묵적 가정 (Implicit Assumption))
2. 수정 실패 원인 (Why Fixes Failed): 4가지 실패 모드 (표면적 수정 (Surface Fix) / 불완전한 범위 (Incomplete Scope) / 도구의 한계 (Tool Limitation) / 멘탈 모델 (Mental Model))
3. 예방 메커니즘 (Prevention Mechanisms): 6가지 메커니즘 (문서화 (Documentation) / 아키텍처 (Architecture) / 컴파일 타임 (Compile-time) / 런타임 (Runtime) / 테스트 커버리지 (Test Coverage) / 코드 리뷰 (Code Review))
4. 체계적 확장 (Systematic Expansion): 유사한 문제 (similar issues) / 설계 결함 (design flaws) / 프로세스 결함 (process flaws)
5. 지식 캡처 (Knowledge Capture): 명세 파일의 의무적 업데이트 ("분석 내용이 채팅창에만 머물러 있다면 가치가 없습니다. 가치는 업데이트된 명세(specs)에 있습니다.")

분석 후, 지식은 trellis-update-spec을 통해 .trellis/spec/에 기록되며, 설계 결정 (Design Decision), 흔한 실수 (Common Mistake), 사례 연구 (Case Study) 등의 형태로 산문(prose)화되어 응결됩니다.

AGE: 점진적으로 자동화된 도구로 추출

AGE의 승급 사다리 (AGE Template AGENTS.md Rule 15):

Level 0: 반복되는 문제 발견 (discover repeated issues)
  ↓
Level 1: 버그 노트 (bug note) (docs/bugs/) — 명확하지 않은 근본 원인 기록
...

nop-chaos-flux의 docs/skills/ 디렉토리 (22개 프롬프트 파일):

핵심 차이점

두 방식 모두 실패로부터 지식을 추출하지만, 산출물의 형태와 자동화 수준이 다릅니다:

AGE가 단계를 높여 나갈 수 있는 이유는 특정 패턴이 반복되는지 추적하기 위해 시간 민감형 문서 카테고리(bugs/, lessons/, skills/)를 별도로 운영하기 때문입니다. 반면 Trellis는 지식을 명세(spec)로 한 번 응결시키며, 동일한 실수가 다시 발생했을 때 이를 업그레이드할 수 있는 경로가 없습니다.

4. 문서 구성: 도메인 적응형 vs. 프레임워크 적응형 + 규범적/역사적 분리

이것은 서로 밀접하게 얽혀 있는 두 가지 차원입니다. 즉, 누가 문서 구조를 결정하는가, 그리고 규범적 (normative) 정보와 역사적 (historical) 정보가 분리되어 있는가 하는 점입니다.

Trellis: 프레임워크 사전 설정 고정 구조, 규범적 및 역사적 정보 혼재

.trellis/                  # Trellis에 의해 강제되는 최상위 디렉토리
├── spec/                  # 패키지/계층별로 정리된 코딩 컨벤션 (coding conventions) + 축적된 학습 내용
│   ├── cli/backend/
...

이 구조는 Trellis 자체의 운영을 위해 존재합니다. spec/의 계층화는 get_context.py의 탐색 메커니즘 (discovery mechanism)을 지원하고, tasks/의 형식은 task.py의 생명주기 관리 (lifecycle management)를 지원하며, workspace/의 개발자 격리 (developer isolation)는 다중 사용자 시나리오를 지원합니다. 5가지 핵심 원칙(코드 작성 전 계획하기, 모든 것을 영속화하기 등)은 프로젝트 전반에 걸친 제약 사항입니다.

규범적 정보와 역사적 정보가 분리되어 있지 않습니다. trellis-update-spec의 템플릿 유형(설계 결정 (Design Decision), 흔한 실수 (Common Mistake), 사례 연구 (Case Study), 주의 사항 (Gotcha))은 자연스럽게 역사적 정보를 명세 (spec)에 작성하도록 유도합니다. trellis-break-loop 또한 5차원 분석 후에

workflow-state-contract.md (299행)에서: "두 가지 프로덕션 버그(Phase 1.3 jsonl curation skip, Phase 3.4 commit skip)가 정확히 이 실패 모드(failure mode)를 일으켰습니다."

명세(spec)에 혼합된 사례 연구(Case Studies)는 즉각적인 인과적 맥락("왜 이 규칙이 존재하는가")을 제공하는 반면, AGE는 동일한 맥락을 얻기 위해 파일 간 참조(cross-file references)를 필요로 합니다. 그 대가로 명세 파일이 비대해지며, AI가 읽을 때 "현재의 명세(current specification)"와 "역사적 교훈(historical lesson)"을 구분하지 못하게 됩니다.

AGE: 도메인 요구사항에 따른 조직화, 엄격한 규범적-역사적 분리

AGE의 문서 조직화에는 오직 두 가지 제약 조건만 존재합니다:

1. 점진적 공개 (Progressive disclosure): 최소한의 진입점(index / start-here)에서 시작하여 점진적으로 상세한 콘텐츠로 펼쳐집니다.
2. 규범적 내용과 시간 민감적 역사의 분리: 안정적인 파일은 안정적인 이름을 사용하며, 시간 민감적인 기록은 날짜를 포함합니다.

이 제약 조건 내에서, 각 프로젝트는 자신의 도메인 요구사항(domain needs)에 따라 문서 구조를 조직합니다.

nop-chaos-flux (프론트엔드 로우코드 프레임워크): docs/architecture/는 4단계 우선순위(programme → conventions → baseline → subsystems)에 따라 조직되며, docs/components/에는 100개의 컴포넌트 설계 문서가 있고, docs/references/는 가장 많이 사용되는 타입들을 하나의 파일로 압축합니다. 이것이 프론트엔드 프레임워크의 도메인 요구사항입니다.

nop-entropy (백엔드 풀스택 프레임워크): docs-for-ai/는 번호가 매겨진 접두사 읽기 순서(00→04)에 따라 조직되며, ai-dev/(개발 프로세스 메모리)와 분리되어 있습니다. 이는 사용자(users)와 개발자(developers)가 완전히 다른 대상이기 때문입니다.

AGE 템플릿 (애플리케이션 레이어 프로젝트): input/(가공되지 않은 PM 입력)이 requirements/(구현 준비가 된 요구사항) 및 backlog/(우선순위 큐)와 분리되어 있습니다. 이것이 애플리케이션 개발의 도메인 요구사항입니다.

AGE의 규범적/역사적 분리는 nop-chaos-flux 플랜 가이드 Rule 14에 의해 명시적으로 규정됩니다: