사양 기반 AI 워크플로우를 위한 의사결정 엔진

사양 기반 AI 워크플로우의 의사결정 엔진

웹사이트 · 문서화 · 사양 · 시작하기 · 비전 · 기여

AI-SDLC는 사양 기반 AI 워크플로우를 위한 의사결정 엔진입니다. 이는 사양 기반 개발 스택에서 실행 및 거버넌스(governance) 측면을 담당합니다. 운영자(Operators)가 정의 준비(Definition-of-Ready, DoR) 게이트를 통해 부하를 지탱하는 의사결정을 선행하고; 자율 오케스트레이터(autonomous orchestrator)가 종속성 그래프(dependency graph)를 통해 개발자 서브 에이전트(developer subagents)들을 배포합니다. 크로스-하네스 리뷰어(cross-harness reviewers)들(Claude × Codex × …)은 작업을 병렬로 검증하며; DSSE 증명서(attestations)가 모든 변경 사항을 봉인하고; 풀 리퀘스트(pull requests)는 스스로 열립니다.

핵심적인 이점은 **비용 비대칭성(cost asymmetry)**입니다. 즉, 운영자가 사전에 (전체 컨텍스트, 충분한 숙고 시간, 이해관계자 접근 권한을 가지고) 내리는 의사결정은 저렴하고 (대부분) 정확합니다. 반면, 불확실성 하에서 실행 도중에 이루어지는 AI의 결정은 비용이 많이 들고 종종 틀립니다. 이 프레임워크의 가치는

생산성 역설(Productivity paradox) — AI 도구를 사용하는 숙련된 개발자들은 자신이 20% 더 빠르다고 믿음에도 불구하고(METR 2025), 성숙한 코드베이스에서는 19% 느려지는 현상이 나타납니다. 품질 저하(Quality decline) — 리팩토링 비율이 25%에서 10%로 감소했으며, 코드 변경률(code churn)은 5.5%에서 7.9%로 증가했습니다(GitClear 2024). 안정성 퇴보(Stability regression) — AI 도입률이 25% 증가할 때마다 시스템 안정성은 7.2% 하락하는 상관관계가 있습니다(Google DORA 2024). 신뢰 격차(Trust gap) — 개발자 중 단 3%만이 AI 결과물에 높은 신뢰를 표현합니다(Stack Overflow 2025).근본적인 원인은 AI 에이전트가 나쁜 코드를 작성해서가 아닙니다. 문제는 코드베이스가 성장함에 따라 누가 이들을 어떻게 작동시킬지 아무도 조율하지 못한다는 것입니다. 모든 결정은 최악의 순간으로 미뤄지고, 가장 적은 컨텍스트를 가진 주체에 의해 내려집니다. AI-SDLC는 이를 뒤집습니다.

이 프레임워크는 하나의 응집력 있는 시스템이지만, 점진적으로 채택할 수 있는 다섯 가지 기둥(pillars) 형태로 제공됩니다.

'준비 정의 게이트(Definition-of-Ready gate)'(RFC-0011)는 운영자가 아직 결정하지 않은 작업을 전송하는 것을 거부합니다. 곧 출시될 '의사결정 카탈로그(Decision Catalog)'(RFC-0035, 초안)는 운영자의 미해결 질문 대기열을 일급 자원(first-class resource)으로 만듭니다. 이 대기열은 레버리지에 따라 순위가 매겨지고, 적절한 주체에게 라우팅되며, 프레임워크 추천 사항 + 반론 + 하위 결정 그래프와 함께 제시됩니다. 프레임워크가 추천하고; 운영자가 결정하며; 오케스트레이터가 실행합니다. → 개념 페이지

cli-orchestrator tick

은 의존성 그래프(RFC-0014)를 탐색하고, 입회 필터(admission filters)(차단됨, 진행 중, DoR, 전송 가능 여부)를 실행하며, 승인된 작업을 격리된 git 작업 트리(worktrees)로 전송하고, 단계 0부터 13까지의 파이프라인(dev agent → 3명의 리뷰어 → 증명서 서명(attestation sign) → PR 오픈)을 실행하며, 실패를 격리하고, 중단 시 체크포인트 커밋에서 재개합니다. 운영자는 타이핑하지 않고 모니터링만 합니다. 기능 플래그: AI_SDLC_AUTONOMOUS_ORCHESTRATOR=experimental

. → 개념 페이지 · 런북

세 명의 리뷰어 하위 에이전트가 모든 변경 사항에 대해 병렬로 실행됩니다. DSSE 엔벨로프는 각 검토 뒤에 있는 실행 하네스(harness)를 식별하는 harness 필과 verify-attestation...

독립성 강제 구현(independence by construction): Claude가 구현을 담당했다면, 코드 검토자나 테스트 검토자가 될 수 없습니다. Codex는 Claude의 작업을 검토하고 그 반대도 마찬가지입니다. 검토자 간 공모는 기계적으로 불가능합니다. → 개념 페이지 · 런북

다섯 개의 패널로 구성된 실시간 터미널 인터페이스: 결정 대기(RFC-0035), 파이프라인 + PR, 의존성 그래프, 설정, 및 분석. 전경(Foregrounds)은 핵심적인 결정을 로드하고 나머지 부분에서는 방해되지 않습니다. → 개념 페이지

전체 수명 주기를 위한 선언적 리소스: Pipeline,
Decision,
AgentRole,
QualityGate,
AutonomyPolicy,
AdapterBinding
— 모두 spec/schemas/ 아래에 JSON Schema (draft 2020-12)로 제공됩니다. 품질 게이트는 자문적(advisory) → 소프트 필수적(soft-mandatory) → 하드 필수적(hard-mandatory)으로 실행되며, 교차 하네스 검토와 DSSE 증명서가 필요합니다. 도입자는 규정 준수 자세(compliance posture)(RFC-0022)를 선언하고 프레임워크는 게이트 기본값을 도출합니다 — EU AI Act, NIST AI RMF, ISO 42001. → 명세

# 1. Claude Code 플러그인 설치 (권장)
/plugin marketplace add ai-sdlc-framework/ai-sdlc
/plugin install ai-sdlc@ai-sdlc
...

전체 설정, 러너 구성, 에이전트-러너 참조, 그리고 자율 오케스트레이터(autonomous-orchestrator) 옵트인에 대한 내용은 문서에서 확인할 수 있습니다:

→ 시작하기 · 튜토리얼 · API 참고 자료 · 운영 런북

이 프레임워크는 에이전트에 구애받지 않습니다 — Claude Code, Codex, Cursor, Copilot, Aider 또는 모든 OpenAI 호환 API가 가능합니다. 에이전트 러너 참조(Agent Runner Reference)를 확인하십시오.

만약 당신이 AI 에이전트이거나 이 코드베이스에 처음 기여하는 새로운 기여자라면, 다음 순서로 문서를 읽으십시오. 각 문서는 해당 관심사에 대한 표준 자료입니다:

— 조직화된 논지(Decision Engine, 비용 비대칭성, 운영자-결정 관리자 역할, 배제된 안티패턴). 이 저장소의 모든 결정은 여기에 근거해야 합니다.VISION.md

— 이 저장소에서 작업하는 모든 에이전트 또는 기여자를 위한 운영 규칙: git flow (항상 rebase, 절대 merge 금지), 브랜치 + 커밋 컨벤션, pre-push hooks, 증명서 요구 사항, 백로그 워크플로우, 패턴-C 작업 트리 격리(Pattern-C worktree isolation), 플러그인 MCP 라우팅.CLAUDE.md

작업 시작 전 로드하세요. — 프로젝트 거버넌스, IP 정책, CNCF 정렬.`CHARTER.md``

— 아키텍처 결정 레지스트리. 모든 핵심 설계 선택은 RFC(Request for Comments)로 존재합니다. 레지스트리 테이블은 숫자 및 라이프사이클 상태에 대한 표준 조회 지점이며, Critical Path 섹션은 종속성을 추적합니다.`spec/rfcs/README.md``

+`spec/spec.md``

— 규범적 명세: 리소스 모델, 정책 시행, 자율성, 에이전트(agents), 어댑터(adapters), 메트릭스(metrics).`spec/``

Claude Code 세션 내부에서 작업할 때의 표준 실행 경로:

코드 푸시 전에 내재화해야 할 경험 법칙:

병합은 다음을 따릅니다`governance.allowMerge``

`.ai-sdlc/agent-role.yaml``

, 이는 세션의 하드 규칙으로 렌더링됩니다. 병합이 허용되는 경우 유일한 경로는 cli-merge-if-eligible입니다.
; 원시(raw) 병합 명령어는 절대 실행하지 마십시오.항상 기능 브랜치를 main에 리베이스하세요. main을 병합하지 마십시오.패턴 C: 부모 작업 트리는 읽기 전용입니다. 모든 코드 작업은 .worktrees/<task-id>/에서 이루어집니다.

`./ai-sdlc execute``는 이를 자동으로 설정합니다.증명(Attestation)이 필요합니다main에 있는

. 소스 코드를 건드리는 Code PR은 리뷰어 체인에 의해 서명된 DSSE 엔벨로프를 포함해야 합니다. 문서 전용 PR은 예외입니다. 검토가 무엇을 의미하는지는 리뷰 정책을 참조하십시오.크로스 레포지토리 쓰기는 작업 프론매터(task frontmatter)의 permittedExternalPaths를 통해 이루어집니다.

플러그인의 슬래시 명령어와 MCP 도구는 ai-sdlc-plugin/README.md에 문서화되어 있습니다.

. Step 0-13 파이프라인은 pipeline-cli/README.md에 있습니다.

개발 환경 설정(pnpm install, 빌드, 테스트, 스키마 유효성 검사)은 docs/getting-started/ 및 CONTRIBUTING.md를 참조하십시오.

명세는 Kubernetes 스타일 API 성숙도(API maturity)를 따릅니다: 오늘날 v1alpha1이며,
v1beta1은 9개월의 폐기 기간(deprecation window)을 거치고, v1은 12개월의 기간을 거칩니다. 리소스 유형(Resource types), 정책 적용 수준(policy enforcement levels), 자율성(autonomy), 에이전트(agents), 어댑터(adapters)는 모두 spec/ 아래에 존재하며, JSON 스키마(draft 2020-12)는 spec/schemas/ 아래에 있습니다. 아키텍처 변경 사항은 RFC 프로세스를 거칩니다. 해당 레지스트리는 모든 RFC 번호 — 활성(active), 예약됨(reserved), 철회됨(withdrawn), 구현됨(implemented) — 의 표준 조회 지점입니다.

기여 (Contributing): CONTRIBUTING.md
— 버그 보고서, 기능 요청, 코드 및 명세 변경 사항 (RFC를 통해)
거버넌스 (Governance): GOVERNANCE.md
— 프로젝트 역할, 의사 결정, SIG 구조
정관 (Charter): CHARTER.md
— 미션, 범위(scope), IP 정책, CNCF 정렬(alignment)
라이선스 (License): Apache 2.0 — 상업적 및 오픈 소스 사용, 제한 없음
행동 강령 (Code of Conduct): Contributor Covenant v2.1