Anthropic이 코드 짜기 전에 쓰라고 한 intent.md｜AI 네이티브 SDLC 6단계와 실제 적용 구조

※ 기준일: 2026년 9월 6일

1. Anthropic의 AI-Native SDLC Playbook이란?

Anthropic은 Claude Code를 이용해 코드를 작성하는 방법만 설명하는 것이 아니라, AI가 대부분의 코드를 생성하게 되었을 때 소프트웨어 개발 프로세스 자체를 어떻게 바꿔야 하는가를 AI-Native SDLC Playbook으로 정리했습니다.

Claude Academy의 공식 과정 역시 AI가 코드를 빠르게 작성하기 시작하면 기존의 계획, 리뷰, 테스트, 배포 과정이 새로운 병목이 될 수 있다고 설명합니다. 따라서 코드 작성 단계만 자동화하는 것이 아니라 SDLC 전체의 흐름을 바꾸는 것이 핵심입니다.

공식 플레이북은 다음과 같은 6개의 Stage로 구성됩니다.

여기서 중요한 것은 6단계가 단순히 Plan → Design → Build → Test → Deploy → Maintain 순서로 한 번 실행되고 끝나는 프로세스가 아니라는 것입니다.

Anthropic은 각 단계의 산출물이 다음 단계의 트리거가 되고, 운영에서 발생한 문제는 다시 새로운 intent.md가 되어 전체 프로세스를 반복하는 구조를 설명합니다.

2. 왜 하필 intent.md인가?

기존 소프트웨어 개발에서는 새로운 아이디어가 생기면 보통 다음과 같은 과정을 거칩니다.

아이디어
  ↓
회의
  ↓
Backlog
  ↓
User Story
  ↓
요구사항 정리
  ↓
Design
  ↓
개발 티켓
  ↓
개발

이 과정에서 문제가 하나 생깁니다.

처음 아이디어를 낸 사람이 생각했던 내용과 실제 개발자에게 전달되는 내용 사이에 차이가 생길 수 있다는 것입니다.

Anthropic은 AI-Native SDLC에서 이 문제를 originator의 의도를 처음부터 버전 관리되는 artifact로 남기는 방식으로 해결하려고 합니다.

그 역할을 하는 것이 intent.md입니다.

3. intent.md는 프롬프트가 아니라 Proto-Spec이다

intent.md를 단순히 "Claude에게 전달할 프롬프트를 저장하는 파일"이라고 이해하면 이 플레이북의 핵심을 놓치게 됩니다.

Anthropic이 설명하는 intent.md는 사람이 읽을 수 있고, Git으로 버전 관리되며, 다음 단계에서 바로 사용할 수 있는 proto-spec입니다.

즉 다음 질문에 답하는 문서입니다.

• 무슨 문제가 있는가?
• 무엇이 달라지기를 원하는가?
• 누가 영향을 받는가?
• 어떤 제약이 있는가?
• 아직 결정하지 못한 것은 무엇인가?

4. Anthropic 공식 intent.md 5개 필드

공식 플레이북에서 제시하는 기본적인 intent.md 구조는 다음과 같이 이해할 수 있습니다.

# Intent: [기능 또는 문제 이름]
Author: [이름]
Status: draft
## Problem
현재 누가 어떤 문제를 겪는가?
근거는 무엇인가?
## Proposed outcome
문제가 해결되면 무엇이 달라지는가?
## Affected users and systems
사용자:
시스템:
## Constraints
반드시 지켜야 하는 것:
범위 밖:
## Open questions
아직 결정하지 못한 것은 무엇인가?

실제 Anthropic 예제에서도 Problem → Proposed outcome → Affected users and systems → Constraints → Open questions 구조를 사용합니다.

5. intent.md 작성 과정도 AI-Native하게 바뀐다

중요한 것은 사람이 처음부터 완벽한 요구사항 문서를 작성해야 하는 것이 아닙니다.

아이디어를 낸 사람이 자신의 언어로 문제를 설명하면 Claude와 대화를 통해 범위, 사용자, 제약, 성공 조건 등을 구체화합니다.

그리고 Claude에게 그 결과를 조직의 템플릿에 맞춰 intent.md로 작성하도록 합니다.

하지만 여기서 AI가 작성한 내용을 그대로 승인하지 않습니다.

아이디어를 낸 사람이 Claude가 잘못 이해한 부분을 수정하고, 그 결과물을 Product Owner가 검토한 뒤 Git에 커밋합니다.

6. Stage 1 — Plan

① Capture as intent.md

첫 번째 단계는 아이디어를 intent.md로 만드는 것입니다.

시작점은 반드시 새로운 기능일 필요도 없습니다.

• 사람이 새로운 아이디어를 낸 경우
• 티켓이 생성된 경우
• 운영 장애가 발생한 경우
• 모니터링에서 이상 징후가 발견된 경우

특히 마지막 항목이 Stage 6과 연결되는 중요한 부분입니다. 운영 중 발생한 문제가 다시 intent.md가 되어 새로운 개발 사이클을 시작할 수 있습니다.

7. Stage 2 — Design : intent.md → spec.md

Product Owner가 intent.md를 승인하면 다음 단계는 Requirements and Design입니다.

여기서 Claude는 승인된 intent.md를 읽고 요구사항과 설계를 포함하는 spec.md를 생성합니다.

이때 중요한 차이가 있습니다.

기존 방식에서는 요구사항 분석과 디자인이 여러 사람과 단계로 나뉘어 전달될 수 있습니다.

AI-Native SDLC에서는 Claude가 intent.md를 바탕으로 요구사항과 설계를 하나의 작업 흐름으로 구체화합니다.

그리고 조직의 보안, 브랜드, 컴플라이언스, UX 등의 정책은 Skills를 통해 적용할 수 있습니다.

intent.md

사용자 검색이 불편하다.
사용자가 이름, 사번, 이메일을
하나의 검색창에서 검색할 수 있게 하고 싶다.

↓

spec.md

# Requirements and Design
## Requirements
- 이름으로 검색할 수 있어야 한다.
- 사번으로 검색할 수 있어야 한다.
- 이메일로 검색할 수 있어야 한다.
## User experience
- 하나의 검색 입력창을 사용한다.
- 검색 결과는 기존 사용자 목록 UI와 호환한다.
## Security
- 기존 인증 정책을 유지한다.
- 권한 없는 사용자의 데이터가 노출되지 않아야 한다.
## Concerns
- 기존 검색 API의 성능 영향을 확인해야 한다.

그리고 spec.md 역시 AI가 만들었다고 바로 개발로 넘어가는 것이 아닙니다.

Product Owner가 원래의 intent.md와 비교하여 "이 설계가 정말 우리가 원했던 문제를 해결하는가?"를 검토합니다.

8. Stage 3 — Build : spec.md → plan.md → Code

이제 엔지니어링 단계입니다.

Anthropic이 여기에서 강조하는 것이 Claude Code Plan Mode를 구현보다 먼저 시작하는 것입니다.

즉 Claude에게 바로 "코드 작성해"라고 하지 않습니다.

먼저 코드베이스를 읽고 구현 계획을 만들게 합니다.

계획에서 반드시 확인해야 할 것

• 어떤 파일을 변경하는가?
• 어떤 순서로 작업하는가?
• 무엇이 깨질 가능성이 있는가?
• 가장 위험한 변경은 무엇인가?
• 어떤 테스트로 결과를 증명할 것인가?
• 다른 방법은 왜 선택하지 않았는가?

이 과정을 반복하여 처음 보는 엔지니어도 plan.md만 읽고 구현할 수 있는 수준까지 계획을 구체화하는 것이 핵심입니다.

plan.md 예시

# Plan: 사용자 검색 개선
## Files that change
- Controllers/UserController.cs
- Services/UserService.cs
- Views/User/Search.cshtml
- Tests/UserSearchTests.cs
## Order of work
1. 기존 사용자 검색 구조 분석
2. 검색 조건 확장
3. Service 로직 변경
4. 화면 검색 조건 변경
5. 테스트 추가
## Risks
- 기존 사용자 검색 기능에 영향을 줄 수 있음
- 검색 조건 증가에 따른 DB 성능 확인 필요
## Proof
- 기존 테스트 통과
- 신규 검색 조건 테스트 통과
- 빌드 성공

9. "Nothing is implemented without an accepted plan"

Build 단계에서 가장 중요한 원칙 중 하나입니다.

승인된 계획 없이 구현하지 않는 것입니다.

Claude가 먼저 계획을 작성하고, 엔지니어가 계획을 검토하고, 계획이 승인된 다음 실제 코드를 작성합니다.

구현 과정에서 계획과 실제 코드의 차이가 발생하면 plan.md도 함께 업데이트하여 계획과 구현의 동기화를 유지할 수 있습니다.

10. CLAUDE.md는 intent.md와 무엇이 다른가?

이 부분은 AI-Native SDLC를 이해할 때 상당히 중요합니다.

따라서 intent.md와 CLAUDE.md는 경쟁 관계가 아닙니다.

intent.md는 특정 작업의 "왜"에 가깝고, CLAUDE.md는 프로젝트가 지속적으로 알아야 할 "어떻게"에 가깝습니다.

Anthropic 공식 플레이북에서도 CLAUDE.md는 Build 단계에서 기관의 지식(institutional knowledge)을 버전 관리 가능한 형태로 유지하는 수단으로 설명됩니다.

11. Skills는 CLAUDE.md와 또 다르다

조직 전체에서 반복적으로 적용해야 하는 정책은 Skills로 만들 수 있습니다.

예를 들어 다음과 같은 정책이 있다고 가정해 보겠습니다.

• 외부 API는 반드시 인증해야 한다.
• PII는 로그에 기록하지 않는다.
• 특정 API 규칙을 반드시 지켜야 한다.
• 특정 UI 작업에는 브랜드 규칙을 적용한다.

이런 조직 지식을 .claude/skills/<name>/SKILL.md 형태로 버전 관리할 수 있습니다.

다만 Skill 자체는 강제 장치가 아닙니다. 반드시 지켜야 하는 정책이라면 Anthropic은 Hook이나 PR Review 등의 결정론적인 통제 장치를 함께 사용하는 방식을 설명합니다.

12. Stage 4 — Test : AI에게 스스로 검증할 방법을 준다

AI가 코드를 빠르게 만드는 환경에서는 "사람이 나중에 확인한다"는 방식만으로는 병목이 생깁니다.

Anthropic은 Claude가 자신의 작업을 직접 검증할 수 있도록 feedback loop를 제공하라고 설명합니다.

예를 들면:

• 테스트 실행
• 빌드 실행
• Lint 실행
• API 응답 확인
• 브라우저 화면 확인
• 스크린샷 비교

즉 다음과 같은 방식입니다.

Code 작성
   ↓
Test / Build / Screenshot
   ↓
실패
   ↓
Claude가 원인 분석
   ↓
수정
   ↓
다시 검증
   ↓
통과

이렇게 하면 사람이 코드를 처음부터 모두 읽고 기계적인 오류를 찾아내는 부담을 줄일 수 있습니다.

TDD도 AI-Native 방식으로 바뀐다

버그 수정에서는 특히 테스트를 먼저 만드는 방식이 유용합니다.

Anthropic의 예시는 먼저 재현 가능한 실패 테스트를 만들고, 그 테스트가 예상대로 실패하는지 확인한 뒤, 테스트를 수정하지 않고 코드만 수정하여 통과시키는 방식입니다.

버그 발견
  ↓
실패 테스트 작성
  ↓
실제로 실패하는지 확인
  ↓
테스트 커밋
  ↓
코드 수정
  ↓
테스트 통과

13. Continuous Evals

Test 단계에서 또 하나 중요한 개념이 Continuous Evals입니다.

테스트를 개발이 끝난 뒤 한 번 실행하는 것이 아니라 개발 과정과 CI에 지속적으로 연결하여 새로운 변경이 기존 품질을 깨뜨리지 않는지 계속 확인하는 방식입니다.

결과적으로 AI가 만든 코드가 자기 검증 → CI 검증 → PR 검토를 차례로 통과하도록 피드백 루프를 구성합니다.

14. Stage 5 — Deploy : PR도 AI-Native하게 바꾼다

코드가 완성됐다고 바로 배포하지 않습니다.

Anthropic은 PR Review 과정에서도 AI를 활용하는 구조를 설명합니다.

Claude가 PR을 검토하면서 다음과 같은 부분을 확인할 수 있습니다.

• 버그
• 논리적 오류
• 보안 문제
• 정책 위반
• spec.md와의 불일치
• plan.md와 실제 변경의 불일치

사람이 모든 코드를 처음부터 끝까지 동일한 깊이로 검토하는 대신, AI가 먼저 기계적인 검토를 수행하고 사람은 의도와 위험도, 최종 승인에 집중하는 구조입니다.

15. PR Review에서도 중요한 것은 사람의 승인이다

AI가 PR을 리뷰한다고 해서 AI가 최종 승인자가 되는 것은 아닙니다.

Anthropic 공식 예시에서는 AI가 발견 사항을 제공하더라도 Branch Protection과 Code Owner 등의 인간 승인 구조를 유지합니다.

즉:

AI 구현
  ↓
AI Test
  ↓
AI PR Review
  ↓
문제 수정
  ↓
Human / Code Owner Review
  ↓
Approve
  ↓
Merge

16. Hooks는 AI의 행동을 통제하는 Approval Gate

AI가 실제 파일을 수정하거나 명령을 실행할 수 있게 되면 "AI에게 하지 말라고 말하는 것"만으로는 충분하지 않은 경우가 있습니다.

Anthropic은 이런 경우 Hooks를 승인 게이트로 사용할 수 있다고 설명합니다.

Hook은 Claude가 특정 행동을 수행하기 전에 허용(allow), 질문(ask), 차단(block)할 수 있는 결정론적인 제어 장치입니다.

예를 들어:

• Production 배포 전 승인
• Migration 파일 변경 제한
• 보호된 경로 수정 제한
• 특정 테스트 파일 수정 제한
• 특정 명령 실행 제한

이런 부분은 특히 실무에서 중요합니다. AI에게 "하지 마"라고 프롬프트로 알려주는 것과 실제로 실행 자체를 차단하는 것은 전혀 다른 수준의 통제이기 때문입니다.

17. CI/CD까지 연결하면 Deploy가 자동화된다

Anthropic은 CI/CD에서도 Claude를 활용할 수 있도록 설명합니다.

예를 들어 CI에서 빌드가 실패하면 Claude가 로그를 분석하고 원인을 요약할 수 있습니다.

더 나아가 수정이 필요한 경우에도 AI가 직접 main 브랜치에 쓰는 것이 아니라 PR을 통해 변경 사항을 전달하고 Branch Protection을 통과하도록 하는 구조를 권장합니다.

CI 실패
  ↓
Claude 분석
  ↓
수정
  ↓
PR 생성
  ↓
Branch Protection
  ↓
Review
  ↓
Merge

18. Stage 6 — Maintain : 운영이 다시 intent.md가 된다

AI-Native SDLC에서 가장 재미있는 부분이 바로 Maintain 단계입니다.

일반적인 개발 프로세스는 보통 다음과 같습니다.

개발
 ↓
배포
 ↓
운영
 ↓
장애
 ↓
사람이 티켓 생성
 ↓
다시 개발

Anthropic은 여기에 AI를 연결합니다.

Production
   ↓
Monitoring
   ↓
Control Band 초과
   ↓
Claude 진단
   ↓
intent.md 생성
   ↓
Product Owner / 담당자 Triage
   ↓
spec.md
   ↓
plan.md
   ↓
Build
   ↓
Test
   ↓
PR
   ↓
Deploy
   ↓
Production

이렇게 되면 개발 프로세스가 하나의 닫힌 Loop가 됩니다.

19. 완성형 AI-Native SDLC Loop

Anthropic 공식 플레이북에서는 승인된 intent.md가 다음 단계의 요구사항/설계를 시작시키고, 승인된 spec.md가 Plan Mode를 시작시키며, Merge된 PR이 pipeline을 시작하고, Production의 control-band breach가 새로운 intent.md를 만든다는 연결 구조를 설명합니다.

20. Slack이나 Ticket에서 시작하는 것도 가능하다

이 구조가 재미있는 이유는 모든 개발 요청이 반드시 사람이 Git에 직접 Markdown 파일을 만들어야 하는 것은 아니라는 점입니다.

Anthropic의 Maintain 예시에서는 티켓이나 채널에서 Claude가 요청을 받아 작은 범위의 작업은 PR로 연결하고, 규모가 큰 작업은 intent.md로 만들어 다시 Plan 단계로 보내는 흐름을 설명합니다.

Slack / Ticket
     ↓
Claude
     ↓
작은 변경인가?
   ↙       ↘
 Yes        No
  ↓          ↓
PR        intent.md
             ↓
          spec.md
             ↓
          plan.md
             ↓
           Build

결국 사람에게 단순 반복 업무를 계속 넘기는 것이 아니라 AI가 요청을 분류하고, 필요한 수준의 artifact를 만들고, 정해진 승인 게이트를 통과시키는 구조입니다.

21. 실제 적용할 때 가장 중요한 것은 폴더 구조다

여기부터는 Anthropic 공식 구조와 실제 프로젝트 적용을 구분해서 볼 필요가 있습니다.

Anthropic 공식 자료에서는 단일 제품의 경우 가장 단순한 intent 저장 위치로 프로젝트 Repository의 intent/ 폴더를 사용할 수 있다고 설명합니다.

반면 아래 구조는 실제 프로젝트에 적용하기 위한 권장 운영 구조입니다.

권장 폴더 구조

intent/
│
├── README.md
│
├── ship-tracking/
│   ├── intent.md
│   ├── spec.md
│   └── plan.md
│
├── user-search/
│   ├── intent.md
│   ├── spec.md
│   └── plan.md
│
└── attendance-extension/
    ├── intent.md
    ├── spec.md
    └── plan.md

여기서 README.md에는 이 폴더의 운영 규칙과 각 단계의 Source of Truth를 설명해 두는 방식이 좋습니다.

22. 왜 기능마다 폴더를 하나씩 만드는가?

기능 하나에 대해 다음 세 가지 artifact를 하나의 단위로 묶습니다.

ship-tracking/
│
├── intent.md
├── spec.md
└── plan.md

이렇게 하면 Git에서 다음 관계를 쉽게 추적할 수 있습니다.

• 왜 이 기능을 만들었는가?
• 무엇을 만들기로 결정했는가?
• 어떻게 구현하기로 했는가?
• 실제 코드와 계획이 일치하는가?
• 요구사항이 구현 도중 변경되었는가?

특히 나중에 장애가 발생했을 때 단순히 코드 diff만 보는 것이 아니라 의도 → 요구사항 → 구현 계획 → 실제 변경을 역추적할 수 있습니다.

23. "폴더당 intent·spec·plan 하나씩" 규칙

실제 적용에서는 하나의 변경 단위를 명확하게 만드는 것이 중요합니다.

이 규칙의 목적은 단순히 파일을 깔끔하게 관리하는 것이 아니라 하나의 변경 단위와 하나의 의도 사이의 관계를 명확하게 유지하는 것입니다.

24. PR 흐름도 분리한다

여기서도 Anthropic 공식 플레이북과 실제 프로젝트 적용안을 구분해야 합니다.

Anthropic 공식 플레이북의 핵심은 각 artifact의 승인/merge가 다음 단계를 트리거하는 구조입니다.

이를 실제 Git 운영에 적용하면 다음과 같이 설계할 수 있습니다.

intent/ship-tracking
        ↓
intent.md PR
        ↓
Product Owner 승인
        ↓
merge
        ↓
spec.md 생성
        ↓
spec.md PR
        ↓
Product Owner 승인
        ↓
merge
        ↓
feature/ship-tracking
        ↓
Claude Code Plan Mode
        ↓
plan.md
        ↓
구현
        ↓
Test / Eval
        ↓
Feature PR
        ↓
AI Review
        ↓
Human / Code Owner Review
        ↓
merge
        ↓
CI/CD
        ↓
Deploy

주의할 점: 위의 구체적인 브랜치 이름과 "PR 하나에 산출물 하나"라는 운영 규칙은 Anthropic이 모든 조직에 강제하는 공식 규칙이 아닙니다. Anthropic 공식 플레이북의 artifact/approval 원칙을 실제 Git workflow에 적용한 운영안입니다.

25. PR 하나에 산출물 하나라는 원칙

실제 프로젝트에서는 단계별 승인 책임을 분명하게 하기 위해 다음과 같이 운영할 수 있습니다.

26. 단계별 책임을 분리하면 무엇이 좋아지는가?

이 구조의 가장 큰 장점은 AI가 모든 것을 결정하지 않는다는 것입니다.

27. "초안은 AI, 승인은 사람"이라는 구조

전체 플레이북을 관통하는 중요한 원칙입니다.

AI는 문서를 만들고, 코드를 작성하고, 테스트하고, 리뷰할 수 있습니다.

하지만 중요한 판단 지점에서는 사람이 남습니다.

AI Draft
   ↓
Human Review
   ↓
Approved Artifact
   ↓
Next Stage

이 구조가 있기 때문에 AI의 생산성을 높이면서도 제품 의도와 위험에 대한 인간의 책임을 유지할 수 있습니다.

28. 기존 SDLC와 AI-Native SDLC 비교

29. 코드가 더 이상 유일한 병목이 아니다

AI 코딩 도구가 충분히 발전하면 개발자가 코드 한 줄 한 줄을 직접 작성하는 시간이 줄어듭니다.

그러면 오히려 다음 과정이 병목이 됩니다.

• 요구사항을 기다리는 시간
• 설계를 기다리는 시간
• 코드 리뷰 대기
• 테스트 대기
• 배포 승인 대기
• 운영 문제를 발견하고 티켓으로 만드는 시간

AI-Native SDLC는 바로 이 부분을 AI와 자동화로 연결하려는 접근입니다.

30. 그렇다면 개발자의 역할은 없어지는가?

오히려 개발자의 역할이 더 높은 수준으로 이동한다고 보는 편이 정확합니다.

개발자가 직접 모든 코드를 작성하는 것에서 다음과 같은 일을 더 중요하게 수행하게 됩니다.

• 요구사항의 정확성 판단
• 아키텍처 판단
• 위험도 판단
• AI가 만든 계획 검증
• AI 결과의 품질 검증
• 보안 및 운영 정책 결정
• 승인 게이트 관리
• AI가 지속적으로 사용할 프로젝트 지식 관리

31. 실제 프로젝트에 단계적으로 적용하는 방법

모든 것을 한 번에 자동화할 필요는 없습니다.

오히려 Anthropic의 플레이북 자체도 각 play가 모듈식이며 조직이 필요한 단계부터 도입할 수 있도록 설명합니다.

1단계 — intent.md부터 도입

intent/
└── feature-name/
    └── intent.md

우선 모든 신규 기능을 바로 개발하지 말고 "왜 만드는가?"를 Markdown으로 남기는 것부터 시작합니다.

2단계 — spec.md 추가

intent/
└── feature-name/
    ├── intent.md
    └── spec.md

3단계 — plan.md 추가

intent/
└── feature-name/
    ├── intent.md
    ├── spec.md
    └── plan.md

4단계 — 테스트 자동화

Claude가 직접 Build와 Test를 수행할 수 있도록 테스트 및 빌드 명령을 표준화합니다.

5단계 — PR Review 자동화

AI Review를 CI/PR에 연결하고 사람이 최종 승인합니다.

6단계 — Hooks / CI/CD

위험한 작업에는 deterministic gate를 적용합니다.

7단계 — 운영 Loop

Metrics → AI 진단 → intent.md까지 연결하면 완성형 loop에 가까워집니다.

32. ASP.NET MVC + C# + MSSQL 프로젝트에 적용한다면

기존 ASP.NET MVC 프로젝트에도 이 개념은 충분히 적용할 수 있습니다.

다만 중요한 것은 Anthropic 공식 예시를 그대로 복사하는 것이 아니라 현재 프로젝트의 개발 방식에 맞춰 artifact를 연결하는 것입니다.

Project/
│
├── intent/
│   ├── README.md
│   │
│   ├── employee-search/
│   │   ├── intent.md
│   │   ├── spec.md
│   │   └── plan.md
│   │
│   └── attendance-extension/
│       ├── intent.md
│       ├── spec.md
│       └── plan.md
│
├── .claude/
│   ├── settings.json
│   ├── hooks/
│   └── skills/
│
├── CLAUDE.md
│
├── Controllers/
├── Models/
├── Services/
├── Views/
├── Scripts/
│
└── Tests/

예를 들어 MSSQL 작업이 포함된다면 plan.md에 단순히 "DB 수정"이라고 적는 것보다 어떤 테이블을 읽고, 어떤 Stored Procedure 또는 SQL을 변경하며, 예상 영향 범위와 검증 방법을 무엇으로 할지까지 기록하는 것이 좋습니다.

33. 최종적으로 만들고 싶은 구조

                    ┌──────────────────┐
                    │   IDEA / TICKET  │
                    │   INCIDENT       │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │    intent.md     │
                    │      PLAN        │
                    └────────┬─────────┘
                             │ 승인
                             ▼
                    ┌──────────────────┐
                    │     spec.md      │
                    │     DESIGN       │
                    └────────┬─────────┘
                             │ 승인
                             ▼
                    ┌──────────────────┐
                    │     plan.md      │
                    │      BUILD       │
                    └────────┬─────────┘
                             │ 승인
                             ▼
                    ┌──────────────────┐
                    │   CODE + TEST    │
                    │   TEST / EVAL    │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │   AI PR REVIEW   │
                    │  HUMAN APPROVAL  │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │      CI/CD       │
                    │     DEPLOY       │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │    PRODUCTION    │
                    │     METRICS      │
                    └────────┬─────────┘
                             │
                    Control Band Breach
                             │
                             ▼
                    ┌──────────────────┐
                    │   NEW intent.md  │
                    └──────────────────┘
                             │
                             └─────── Loop ───────→
  

34. 영상에서 설명하는 전체 흐름

제공된 영상의 흐름을 기준으로 보면 핵심은 다음과 같이 정리할 수 있습니다.

35. 결론 — intent.md는 시작점일 뿐이다

처음 보면 intent.md는 아주 단순한 Markdown 파일처럼 보입니다.

하지만 실제로 중요한 것은 파일 자체가 아닙니다.

개발 프로세스의 시작점을 코드가 아니라 Intent로 바꾸는 것이 핵심입니다.

그리고 그 Intent를 버전 관리되는 artifact로 만들고, 다음 단계에서 AI가 이를 읽어 spec.md를 만들고, 다시 엔지니어가 Claude Code Plan Mode에서 plan.md를 만들고, 그 계획을 승인한 후에야 코드를 작성합니다.

이후에는 AI가 테스트하고, AI가 PR을 리뷰하고, Hook이 위험한 행동을 제어하고, CI/CD가 배포를 수행하고, Production의 이상 징후가 다시 intent.md로 돌아옵니다.

36. 참고 자료

• Anthropic / Claude — The AI-Native SDLC Playbook
• Claude Academy — The AI-Native SDLC Playbook
• Claude Academy — Capture as intent.md
• Claude Academy — Requirements and design
• Claude Academy — Claude Code plan mode as the default starting point
• Claude Academy — Give Claude a feedback loop
• Claude Academy — AI in the PR review loop
• Claude Academy — Hooks as approval gates
• Claude Academy — CI/CD integration and deployment
• Claude Academy — Closing the loop on metrics

※ Anthropic 공식 내용과 실제 프로젝트 적용을 구분하여 작성했습니다. intent.md, spec.md, plan.md의 역할과 AI-Native SDLC 6단계는 Anthropic 및 Claude Academy 공식 플레이북을 기준으로 정리했습니다.

※ intent/기능-slug/ 아래에 intent.md, spec.md, plan.md를 두는 구조와 "PR 하나에 산출물 하나" 및 브랜치 운영 방식은 공식 플레이북의 artifact/approval 원칙을 실제 프로젝트에 적용하기 위한 권장안입니다.

#AI네이티브SDLC #intentmd #specmd #planmd #Anthropic #Claude #ClaudeCode #AI개발 #AICoding #SDLC #소프트웨어개발 #개발방법론 #개발생산성 #ASPNetMVC #CSharp #MSSQL #Git #CI_CD