Claude Code의 intent.md?

intent.md에서 시작해 테스트·배포·운영까지 이어지는 ‘AI-Native SDLC’의 정체

최근 AI 코딩 도구를 사용하는 개발자라면 묘한 경험을 하게 된다.

몇 시간 걸리던 코드를 Claude Code나 다른 코딩 에이전트가 몇 분 만에 작성한다. 기능 하나를 구현하는 시간은 크게 줄었다. 그런데 프로젝트 전체가 그만큼 빨라졌느냐고 물으면 이야기가 달라진다.

요구사항을 정리해야 한다. 설계를 검토해야 한다. 테스트해야 한다. Pull Request를 리뷰해야 한다. 보안 정책도 확인해야 한다. 배포 승인도 받아야 한다.

코드는 빨라졌는데 코드 주변의 프로세스는 여전히 인간의 속도로 움직인다.

Anthropic은 바로 이 지점을 문제로 삼았다.

2026년 8월 21일 Anthropic은 Louis Claxton이 작성한 **「The AI-Native SDLC Playbook」**을 공개했다. 이어 Claude Academy에는 Plan → Design → Build → Test → Deploy → Maintain으로 구성된 14개 레슨의 실전 가이드가 공개됐다. Anthropic은 이를 자사 Applied AI 팀의 내부 경험과 고객사 적용 경험에서 나온 베스트 프랙티스를 정리한 것이라고 설명한다. (Claude)

며칠 뒤 개발자 Rob Shocks가 이를 intent.md, spec.md, plan.md 중심으로 설명한 영상도 공개하면서 개발자 커뮤니티에서 관심이 커지기 시작했다. (Modern Creator)

하지만 이 Playbook을 단순히 “Claude Code에 Markdown 파일 몇 개 추가하는 방법” 정도로 이해하면 핵심을 놓친다.

[Inference] 제가 이 문서를 읽으며 가장 중요하다고 본 부분은, Anthropic이 AI에게 코드를 잘 쓰게 만드는 방법이 아니라 AI가 개발 프로세스 전체를 이동할 수 있도록 ‘길’을 만드는 방법을 설명하고 있다는 점이다.

---

문제는 이제 코드를 만드는 속도가 아니다

Anthropic의 출발점은 상당히 명확하다.

기존 SDLC는 일반적으로 다음과 같은 흐름을 가진다.

아이디어
  ↓
요구사항
  ↓
설계
  ↓
개발
  ↓
테스트
  ↓
리뷰
  ↓
배포
  ↓
운영

과거에는 이 가운데 Build, 즉 실제 코드를 작성하고 구현하는 시간이 가장 비쌌다.

그래서 PRD가 필요했고, 스프린트 계획이 필요했고, 개발 일정 산정이 중요했다. 수주 또는 수개월 동안 진행될 구현을 시작하기 전에 최대한 많은 사람이 합의를 해야 했다.

그런데 코딩 에이전트가 Build 단계를 크게 압축하면 상황이 달라진다.

Anthropic은 이때 병목이 Build의 양옆으로 이동한다고 설명한다. 계획, 검토, 테스트, 배포 등은 여전히 인간 중심 프로세스로 남아 있기 때문이다. 특히 코드 생산량이 늘었는데 보안팀이나 리뷰어의 수가 그대로라면 검토 큐가 쌓이거나 충분히 검토되지 않은 코드가 배포되는 문제가 생길 수 있다. (Claude)

그래서 Anthropic이 제안하는 질문은 이것이다.

코딩만 AI-native로 바꿀 것이 아니라
SDLC 전체를 AI-native로 다시 설계하면 어떻게 될까?

---

핵심은 intent.md 하나가 아니다

AI-Native SDLC의 전체 구조를 단순화하면 다음과 같다.

       사람 / 장애 / 사용자 요구
                 ↓
             intent.md
                 ↓
              spec.md
                 ↓
              plan.md
                 ↓
        Implementation
          ↕       ↕
        Test     Eval
                 ↓
                PR
                 ↓
             AI Review
                 ↓
            Human Gate
                 ↓
              Deploy
                 ↓
             Monitoring
                 ↓
             Incident
                 ↓
          새로운 intent.md
                 ↺

여기에서 중요한 개념이 Artifact Chain, 즉 산출물의 연쇄다.

Anthropic의 설계에서는 각 단계가 끝날 때 다음 단계가 읽을 수 있는 산출물을 Git에 남긴다.

초기에는 intent.md, spec.md, plan.md 같은 Markdown 문서다. 이후에는 코드 diff와 테스트, PR과 리뷰 결과, 운영 단계에서는 incident record가 산출물이 된다.

그리고 다음 단계는 이전 사람이나 이전 AI의 대화 내용을 기억하는 대신 그 산출물을 읽고 시작한다.

Anthropic은 이 산출물들의 Git commit 기록 자체가 “누가 무엇을 요청했고, AI가 무엇을 만들었으며, 누가 승인했는지”를 추적할 수 있는 감사 기록이 된다고 설명한다. (Claude Academy)

[Inference] 이 관점에서 intent.md → spec.md → plan.md는 단순한 문서 작성법보다는 사람과 AI 에이전트 사이의 컨텍스트 전달 프로토콜에 더 가깝다.

---

1. intent.md — 무엇을 만들지가 아니라 왜 만드는지를 먼저 고정한다

첫 번째 산출물은 intent.md다.

여기서 흥미로운 점은 Anthropic이 이것을 완성된 PRD가 아니라 proto-spec이라고 부른다는 점이다.

누군가 문제가 있거나 새로운 아이디어를 발견하면 곧바로 Jira 티켓부터 작성하는 대신 Claude와 대화한다.

Claude는 분석가처럼 범위, 대상 사용자, 제약조건, 성공 조건 등을 질문한다. 그리고 대화를 정리해 intent.md를 생성한다.

Anthropic이 제시하는 주요 구조는 문제, 원하는 결과, 영향을 받는 사용자와 시스템, 제약조건, 미해결 질문 등이다. 생성된 내용은 사람이 다시 확인하고 수정한 후 Product Owner가 승인한다. (Claude Academy)

예를 들어 이런 식이다.

# Intent: 간편 로그인 개선

## Problem

신규 사용자의 회원가입 과정에서
인증 단계 이탈률이 높다.

## Proposed Outcome

Google과 Apple 로그인을 추가해
가입 과정을 단순화한다.

## Affected Users

신규 가입 사용자

## Affected Systems

auth-api
mobile-app
user-database

## Constraints

기존 계정과 소셜 계정의 중복을 허용하지 않는다.
현재 세션 구조는 유지한다.

## Open Questions

기존 이메일 계정을 소셜 계정과 연결할 것인가?

중요한 것은 여기서 아직 코드 이야기를 하지 않는다는 것이다.

React 컴포넌트를 어떻게 만들까?
DB 스키마를 어떻게 바꿀까?
OAuth 라이브러리는 무엇을 사용할까?

보다 먼저

문제가 무엇인가?
누구의 문제인가?
결과가 어떻게 달라져야 하는가?
무엇은 하면 안 되는가?

를 확정한다.

코딩 에이전트 시대에 오히려 이런 과정이 더 중요해질 수 있다. 구현 비용이 떨어지면 잘못 정의된 문제를 매우 빠른 속도로 구현해버리는 것도 가능하기 때문이다.

---

2. spec.md — 조직의 정책을 설계 단계에서 적용한다

승인된 intent.md는 다음 단계에서 spec.md로 변환된다.

여기서 등장하는 것이 Claude Skills다.

Anthropic은 브랜드 가이드, 보안 정책, 컴플라이언스, UX 표준과 같이 조직 전체에서 반복 적용해야 하는 지식을 Skill로 표현하도록 권장한다.

예를 들면 다음과 같다.

intent.md
    │
    ├── Security Skill
    ├── API Design Skill
    ├── UX Skill
    ├── Accessibility Skill
    └── Compliance Skill
          ↓
       spec.md

Product Owner가 intent.md를 Claude에게 전달하면 Claude는 해당 Skills를 제약조건으로 사용하여 요구사항과 설계를 작성한다.

정책 간 충돌이 있다면 숨기지 않고 별도로 표시하도록 요구한다. Product Owner는 이를 검토하고 필요하다면 보안 담당자나 정책 담당자와 해결한 후 spec.md를 승인한다.

Anthropic은 초기에는 이 과정을 사람이 직접 실행하되, 운영이 안정되면 승인된 intent.md가 merge되는 순간 자동 작업이 실행되고 spec.md PR을 생성하도록 발전시키는 방식까지 제안한다. (Claude Academy)

---

Skill은 프롬프트 파일과 조금 다르다

Anthropic은 Skill을 institutional knowledge, 즉 조직 지식을 실제 작업에 적용하는 장치로 설명한다.

예를 들어 회사에 이런 규칙이 있다고 하자.

외부 API는 모두 JWT 인증을 사용한다.
PII 정보는 로그에 남기지 않는다.
모든 state-changing API는 audit event를 생성한다.

이 내용을 Wiki에 작성해 두는 것으로 끝내지 않고:

.claude/
└── skills/
    └── secure-api-review/
        └── SKILL.md

처럼 Git으로 관리한다.

정책이 바뀌면 Skill을 수정한다.

다음 세션부터 AI가 새로운 정책을 읽는다.

Anthropic은 반복적으로 일관되게 적용해야 하는 조직 지식은 Skill로, 프로젝트 자체의 작업 방법과 구조는 CLAUDE.md로 분리하는 것을 권장한다. (Claude)

여기에서 아주 중요한 구분이 하나 있다.

Skill은 권고적(advisory) 통제다.

Claude가 해당 정책을 적용하도록 유도하지만, 그 자체로 정책 위반을 물리적으로 막지는 않는다.

반드시 지켜야 하는 규칙은 뒤에서 설명할 Hook 같은 deterministic control이 필요하다고 Anthropic 역시 명확하게 구분한다. (Claude)

---

3. plan.md — 코드를 작성하기 전에 구현 자체를 리뷰한다

spec.md가 승인되면 곧바로 코딩하는 것도 아니다.

Claude Code의 Plan Mode를 사용한다.

intent.md
      +
spec.md
      +
CLAUDE.md
      ↓
 Claude Code Plan Mode
      ↓
    plan.md
      ↓
     승인
      ↓
   Implementation

Plan Mode에서는 Claude가 코드베이스를 읽고 분석할 수 있지만 구현 파일을 변경하지 않는다.

Claude는 어떤 파일을 변경할지, 어떤 순서로 작업할지, 어떤 테스트가 성공을 증명할지를 정리한다.

엔지니어는 여기서 계속 질문한다.

이 변경 때문에 깨질 가능성이 있는 부분은?

가장 위험한 단계는?

다른 구현 방법은 무엇이 있었고
왜 이 방식을 선택했나?

Anthropic의 기준이 흥미롭다.

이전 대화를 한 번도 보지 않은 엔지니어도 plan.md만 읽고 구현할 수 있어야 한다.

그 수준까지 계획을 수정한 뒤 Git에 commit한다. (Claude Academy)

예를 들어 다음과 같다.

# Plan: Social Login

## Files

src/auth/oauth.ts
src/api/login.ts
src/components/LoginButtons.tsx
tests/auth/oauth.test.ts

## Order

1. OAuth provider abstraction 추가
2. Google provider 구현
3. Apple provider 구현
4. 기존 계정 중복 처리
5. UI 연결

## Risks

기존 이메일 계정과
OAuth 계정 중복 가능성

## Proof

unit test
integration test
browser login test

기존 개발에서는 구현 방법이 개발자의 머릿속에 있는 경우가 많았다.

그래서 리뷰어가 처음 보는 것은 완성된 diff였다.

이 방식은 다르다.

설계를 고칠 수 있을 때 설계를 먼저 리뷰한다.

코드 수백 줄을 작성한 뒤 되돌리는 대신 plan.md 몇 줄을 수정하는 것이다.

---

4. CLAUDE.md, Skill, Hook, Eval은 서로 역할이 다르다

이 Playbook을 이해하려면 다음 구성요소들을 구분하는 것이 중요하다. Anthropic은 CLAUDE.md를 새 팀원이 첫날 알아야 할 프로젝트 지식으로, Skills는 반복 적용해야 하는 조직 지식으로, Hooks는 실제 행동을 허용·질문·차단하는 통제 장치로 설명한다. Evals는 AI 설정 자체가 바뀌었을 때 기존 업무 수행 능력이 퇴행하지 않는지 검사하는 회귀 테스트 역할을 한다. (Claude Academy)

구성요소역할예

CLAUDE.md	프로젝트의 작업 지식	빌드 명령, 구조, 코딩 규칙
SKILL.md	반복 적용할 조직 지식	보안, API, UX 정책
plan.md	이번 작업의 실행 계획	수정 파일, 순서, 위험
Subagent	특정 역할을 수행하는 별도 컨텍스트	Verifier, Researcher
Hook	행동을 실제로 제한	특정 파일 수정 차단
Eval	에이전트의 회귀 테스트	Skill 변경 전후 성공률
REVIEW.md	AI 코드리뷰 기준	Bug/Security/Compliance

이 구조를 보면 AI 개발 시스템이 단순한 Prompt Engineering에서 상당히 멀어졌다는 것을 알 수 있다.

Prompt

  ↓

Project Context

  ↓

Skills

  ↓

Agents

  ↓

Hooks

  ↓

Evals

  ↓

Workflow

---

5. 여러 Agent를 돌릴 때 문서가 더 중요해진다

Anthropic은 Parallel Session과 Subagent도 별도 챕터로 다룬다.

Parallel Session은 각각 별도의 Git worktree를 사용한다.

Engineer
   │
   ├── Claude Session A
   │      └── worktree: feature-auth
   │
   ├── Claude Session B
   │      └── worktree: fix-payment
   │
   └── Claude Session C
          └── worktree: new-dashboard

각 세션은 서로의 컨텍스트를 모른다.

따라서 모든 세션이 공유하는 CLAUDE.md, 그리고 작업별 spec.md와 plan.md가 훨씬 중요해진다.

Anthropic은 처음에는 두세 개의 병렬 세션부터 시작할 것을 권한다. 제한 요소는 모델이 몇 개 실행될 수 있느냐가 아니라 사람이 몇 개의 작업 흐름을 제대로 검토할 수 있느냐이기 때문이다. (Claude Academy)

Subagent는 조금 다르다.

하나의 세션 안에서 별도의 컨텍스트와 도구 권한을 갖는 전문 작업자다.

예를 들어:

Main Agent
    │
    ├── Researcher
    ├── Code Simplifier
    └── Verifier

같은 구성이 가능하다.

특히 Verifier는 구현한 Agent와 다른 fresh context에서 결과만 검증하도록 만들 수 있다. Anthropic은 구현 과정 전체에 반복되는 feedback loop와 마지막에 새로운 관점으로 검사하는 verifier subagent를 명시적으로 구분한다. (Claude Academy)

---

6. 테스트의 목적도 달라진다

기존에는 AI가 코드를 작성하면 사람이 결과를 보고 테스트하는 흐름이 흔했다.

Anthropic은 방향을 반대로 잡는다.

Agent
 ↓
Code
 ↓
Build
 ↓
Test
 ↓
Fail
 ↓
Agent 수정
 ↓
Test
 ↓
Pass
 ↓
Human

사람에게 전달되기 전에 Agent 자신이 검증 루프를 반복한다.

이를 위해 Anthropic은 테스트와 빌드를 한 명령으로 실행할 수 있도록 만드는 것을 권장한다.

make test
make build
make lint

그리고 CLAUDE.md에 무엇이 성공 상태인지까지 명시한다.

UI 작업이라면 browser나 screenshot 도구를 사용해:

구현
 ↓
Screenshot
 ↓
Mock과 비교
 ↓
수정
 ↓
다시 Screenshot

을 반복한다. (Claude Academy)

버그 수정에는 더 흥미로운 패턴이 등장한다.

먼저 실패하는 테스트를 만든다.

그 테스트가 실제 버그 때문에 실패한다는 것을 확인하고 commit한다.

그 다음 Agent에게 코드를 수정하게 한다.

그런데 Agent가 문제를 쉽게 해결하려고 테스트 자체를 수정해버리지 못하게 Hook으로 테스트 파일 수정을 막을 수도 있다.

즉 검증 체계 자체를 Agent에게서 보호하는 것이다. (Claude Academy)

---

7. 이제는 코드뿐 아니라 AI 설정도 테스트해야 한다

여기서 Eval이 등장한다.

Anthropic은 최근 실제 업무에서 20~50개 정도의 작업과 정답 또는 허용 가능한 결과를 모아 eval suite를 구성하는 방식을 제시한다.

그리고 다음과 같은 파일이 바뀔 때 Eval을 실행한다.

CLAUDE.md

.claude/skills/**

.claude/hooks/**

Agent configuration

왜냐하면 이 파일들은 사실상 AI 개발자의 동작을 변경하는 프로그램이기 때문이다.

Skill 문장 하나를 바꿨는데 기존 작업 성공률이 떨어질 수도 있다.

따라서 코드에 regression test가 있듯이 Agent configuration에도 regression test가 있어야 한다는 발상이다.

Anthropic은 실제 production incident도 새로운 Eval로 추가해 같은 종류의 문제가 다시 발생하는지 지속해서 검사하도록 권장한다. (Claude Academy)

[Inference] 이 부분은 AI 코딩이 확산되면서 중요성이 커질 가능성이 높은 개념이다. 앞으로는 애플리케이션 코드뿐 아니라 “우리 회사의 AI 개발자가 제대로 행동하는가”를 검사하는 테스트 스위트가 별도로 관리될 수 있기 때문이다.

---

8. Hook은 프롬프트가 아니라 실제 제어 장치다

AI에게

Production DB는 절대 건드리지 마.

라고 적는 것은 Instruction이다.

Hook은 다르다.

Claude가 어떤 행동을 실행하기 직전에 스크립트가 개입한다.

Anthropic의 Hook은 조건에 따라:

ALLOW

ASK

BLOCK

을 수행할 수 있다.

예를 들어 production deploy 명령을 감지했는데 승인 정보가 없으면 실행 자체를 차단할 수 있다.

또 migration 파일 수정, infrastructure 변경, 테스트 파일 수정 등 특정 행동을 차단하는 것도 가능하다.

Anthropic은 규제가 강한 조직에서는 이러한 Hook과 permission, sandbox, MCP 서버 허용 목록을 관리자가 강제로 배포해 개별 엔지니어가 우회할 수 없도록 하는 예시까지 제시한다. (Claude Academy)

이를 계층으로 보면 꽤 이해하기 쉽다.

CLAUDE.md
   ↓
권장 작업 방법

Skill
   ↓
반복 정책

Hook
   ↓
행동 제어

CI
   ↓
검증

Branch Protection
   ↓
Merge 제어

Human Approval
   ↓
Production Gate

---

9. AI가 리뷰하고, 다시 AI가 수정한다

Pull Request 단계도 달라진다.

Anthropic은 Claude가 PR을 리뷰하고 동시에 자신의 PR에 달린 리뷰 의견을 받아 코드를 다시 수정하는 구조를 제시한다.

리뷰 정책은 REVIEW.md 같은 형태로 관리할 수 있다.

예를 들면:

Bug Review
Security Review
Compliance Review
spec.md 일치 여부
plan.md 일치 여부

등을 별도 패스로 검사한다.

중요한 점은 여기에서도 AI가 최종 승인자가 아니라는 것이다.

Anthropic의 예에서는 branch protection과 code owner approval이 그대로 남는다.

AI가 반복적이고 기계적인 검사를 담당하면 사람은 점점:

이 기능이 원래 의도와 맞는가?

위험을 감수할 만한가?

배포해도 되는가?

같은 판단에 집중하게 된다. (Claude Academy)

---

10. 배포에서도 원칙은 “Production Gate 앞까지”

CI/CD 안에서도 Claude Code를 non-interactive 방식으로 실행할 수 있다.

예를 들면 CI가 실패하면 Agent가 로그를 분석한다.

CI Failure
    ↓
Claude
    ↓
원인 분석
    ↓
Flaky test 여부 판단
    ↓
PR에 요약

그 다음 단계에서는 lint 수정이나 문서 갱신, review comment 대응 같은 쓰기 작업도 Agent에게 맡길 수 있다.

다만 Anthropic은 Agent의 변경이 직접 main으로 들어가지 않고 PR과 branch protection을 통하도록 만드는 구조를 제시한다.

실행 환경도 sandbox에 넣고, 장기 production credential을 Agent에게 주지 않는다.

Deployment, Status, Rollback 같은 작업은 MCP tool로 노출하고 환경별로 권한을 다르게 한다.

예를 들어 개발 환경에서는 자유롭게 배포하되 Production에서는 release manager의 승인을 Hook으로 요구하는 방식이다. (Claude Academy)

여기서 Anthropic이 제시하는 원칙을 압축하면 다음과 같다.

Agent는 Production Gate까지 갈 수 있다.
하지만 정해진 Gate를 스스로 넘어가지는 못한다.

---

11. 가장 흥미로운 것은 마지막 Maintain 단계다

여기까지였다면 상당히 발전된 DevOps 자동화 정도로 볼 수도 있다.

하지만 마지막 단계에서 전체 구조가 다시 intent.md로 연결된다.

Production
    ↓
Monitoring
    ↓
이상 징후
    ↓
Diagnosis
    ↓
intent.md
    ↓
spec.md
    ↓
plan.md
    ↓
Fix
    ↓
Test
    ↓
Deploy
    ↺

다만 Anthropic은 여기에서도 중요한 안전 장치를 둔다.

이상 징후를 감지하는 역할 자체를 LLM에게 맡기지 않는다.

Prometheus나 CI 데이터 같은 지표를 deterministic script가 감시한다.

Control Band를 벗어났을 때만 Claude가 호출된다.

공식 예에서는 대략 다음과 같은 단계가 소개된다.

1σ
→ Log

2σ
→ Claude Read-only Diagnosis

3σ
→ PR 제안 또는 사전 승인된 Runbook

Agent가 장애를 분석하면 그 결과를 다시 intent.md 형식으로 작성한다.

그리고 기존 SDLC가 다시 시작된다.

장애가 해결되면 그 장애 사례는 새로운 Eval로 추가된다. (Claude Academy)

결국 운영 과정까지 하나의 학습 루프가 된다.

문제
 ↓
수정
 ↓
검증
 ↓
배포
 ↓
관찰
 ↓
새로운 문제
 ↓
새 Intent

---

이것은 완전히 새로운 발상일까?

여기에서는 조금 냉정하게 볼 필요도 있다.

AI-Native SDLC를 구성하는 개별 아이디어 모두가 새롭게 등장한 것은 아니다.

Docs as Code는 이미 문서를 Markdown 같은 plain text로 작성하고 Git, Code Review, 자동 테스트를 사용하는 방식을 오래전부터 이야기해 왔다. (Write the Docs)

GitOps 역시 원하는 상태를 선언적으로 정의하고 version control에 저장하며 Agent가 이를 읽고 지속적으로 실제 상태와 동기화하는 구조를 핵심 원칙으로 삼고 있다. (OpenGitOps)

Policy as Code 역시 정책을 텍스트와 코드로 표현해 version control, testing, automated enforcement를 가능하게 만드는 접근이다. Open Policy Agent 같은 시스템은 이미 CI/CD에서 조직 정책을 자동으로 적용할 수 있다. (Open Policy Agent)

테스트를 개발 초기로 이동시키는 Shift-left Testing 역시 오래된 소프트웨어 엔지니어링 개념이다. (IBM)

[Inference] 따라서 Anthropic Playbook의 새로운 부분은 특정 기술 하나를 발명했다는 것보다는 Docs as Code + Policy as Code + CI/CD + Agent + Eval + Git 기반 감사 체계를 하나의 Agent 중심 SDLC로 결합했다는 데 있다고 보는 편이 정확하다.

---

그리고 Markdown 파일 이름 자체가 핵심도 아니다

intent.md가 화제가 되면서 자칫 파일명을 따라 만드는 것이 핵심처럼 보일 수 있다.

하지만 공식 Playbook을 자세히 읽어보면 Anthropic 역시 기존 Jira, ServiceNow, Figma, 요구사항 관리 시스템을 모두 없애라고 말하지 않는다.

기존 시스템이 감사와 규제의 공식 기록이라면 그대로 Source of Truth로 유지하면서 Markdown은 working copy로 사용할 수도 있다.

반대로 Git repository를 Source of Truth로 삼고 기존 시스템에는 commit SHA나 링크만 남기는 방법도 제시한다.

중요한 것은 각 산출물마다 무엇이 진짜 원본인지 명확하게 결정하고 서로 연결하는 것이다. (Claude)

즉:

intent.md라는 이름

보다 중요한 것은

사람과 Agent가
동일한 산출물을 읽을 수 있고

버전이 남으며

승인 기록이 존재하고

다음 단계가
그 산출물을 그대로 사용할 수 있는가?

이다.

---

AI-Native SDLC가 모든 팀을 위한 정답은 아니다

Anthropic도 이 Playbook의 주요 독자를 비교적 명확하게 정의한다.

Claude Code를 이미 사용하고 있고 Git repository와 CI pipeline을 운영하며, planning·approval·review·handoff가 새로운 병목이 되고 있는 engineering, platform, security 리더가 주요 대상이다. 특히 large enterprise와 regulated organization을 염두에 두고 작성됐다. (Claude Academy)

따라서 개인 프로젝트에 처음부터:

10개 Skill
8개 Hook
50개 Eval
4개 Subagent
3단계 Approval

을 만들 필요는 없다.

오히려 Agent 관리 체계 자체가 새로운 복잡성이 될 수 있다.

Anthropic 역시 각 Play를 modular하게 도입하도록 설명하고 있으며, 초기에는 각 단계를 수동으로 실행한 뒤 검증된 단계부터 자동 trigger로 연결하는 방향을 제시한다. (Claude Academy)

---

작은 팀이라면 이렇게 시작하는 편이 현실적이다

[Inference] 공식 Playbook을 소규모 개발팀에 맞게 축소한다면 다음 정도가 현실적인 출발점이라고 본다.

단계먼저 도입할 것목적

1	CLAUDE.md	프로젝트 지식 통일
2	intent.md → spec.md → plan.md	작업 컨텍스트 전달
3	build/test/lint feedback loop	Agent 자기 검증
4	Security/Verification Skill	반복 지식 표준화
5	Hook	중요한 규칙 강제
6	Verifier Subagent	독립 검증
7	Eval suite	Agent 설정 회귀 테스트
8	AI PR Review	리뷰 자동화
9	CI/CD Agent	운영 자동화
10	Monitoring → intent	폐쇄형 개발 루프

Repository 역시 처음에는 이런 수준이면 충분하다.

project/
│
├── CLAUDE.md
├── REVIEW.md
│
├── intents/
│   └── feature-login.md
│
├── specs/
│   └── feature-login.md
│
├── plans/
│   └── feature-login.md
│
├── .claude/
│   ├── skills/
│   │   ├── security/
│   │   └── verification/
│   │
│   ├── agents/
│   │   └── verifier.md
│   │
│   └── hooks/
│
├── evals/
│
└── src/

그 다음부터는 개발자가 매번 긴 프롬프트를 작성하는 대신:

Intent
  ↓
Spec
  ↓
Plan
  ↓
Implement
  ↓
Verify
  ↓
Review

라는 고정된 개발 프로토콜을 사용하게 된다.

---

결국 중요한 것은 ‘AI 개발자’가 아니라 ‘AI가 일할 수 있는 시스템’이다

지금까지 AI 코딩 도구의 경쟁은 대부분 이런 질문을 중심으로 진행됐다.

어떤 모델이 코드를 더 잘 만드는가?

Claude가 좋은가?
Codex가 좋은가?
Cursor가 좋은가?

어떤 프롬프트를 사용해야 하는가?

하지만 AI-Native SDLC Playbook은 조금 다른 질문을 던진다.

Agent가 아무리 빨리 코드를 만들더라도

무엇을 만들지 어떻게 전달할 것인가?

회사 규칙을 어떻게 알려줄 것인가?

결과가 맞는지 어떻게 스스로 검증하게 할 것인가?

어떤 행동은 어떻게 막을 것인가?

누가 승인할 것인가?

장애가 발생하면 어떻게 다시 개발 루프로 돌려보낼 것인가?

[Inference] 그리고 이 질문으로 넘어가면 개발자의 역할 역시 코드를 직접 생산하는 사람에서 코드와 Agent가 안전하게 생산될 수 있는 시스템을 설계하는 사람 쪽으로 조금씩 확장된다.

제가 Anthropic의 Playbook에서 가장 주목한 부분도 바로 이것이다.

intent.md가 중요한 것이 아니다.

spec.md도, plan.md도 그 자체가 목적은 아니다.

중요한 것은 이 파일들이 연결되어:

의도
→ 정책
→ 계획
→ 실행
→ 검증
→ 승인
→ 배포
→ 관찰
→ 다시 의도

라는 끊기지 않는 개발 루프를 만든다는 것이다.

코딩 에이전트가 충분히 강력해진 이후의 경쟁은 결국 모델 하나의 코딩 능력만으로 결정되지 않을 가능성이 있다.

[Inference] 오히려 더 큰 차이는 어떤 팀이 더 좋은 Artifact Chain, Skills, Verification, Evals, Hooks와 Human Gate를 갖추고 있는가에서 발생할 수 있다.

그 점에서 Anthropic의 AI-Native SDLC Playbook은 단순한 Claude Code 사용법이라기보다, “Agent 시대에 소프트웨어 조직은 어떤 운영체제를 가져야 하는가”에 대한 하나의 초기 설계안으로 읽어볼 가치가 있다.

---

참고한 주요 원문

Anthropic의 The AI-Native SDLC Playbook은 2026년 8월 21일 공개됐으며 전체 구조와 각 단계의 예제를 제공한다. Anthropic 공식 AI-Native SDLC Playbook Claude Academy에는 Plan, Design, Build, Test, Deploy, Maintain를 다루는 14개 레슨이 별도로 공개되어 있다. Claude Academy — AI-Native SDLC Playbook 이번 대화에서 처음 확인한 영상은 Rob Shocks의 관련 해설 영상이다. YouTube — Claude Codes New INTENT.MD, What is It?