코드보다 먼저 바꿔야 할 6단계 개발 프로세스 AI-Native SDLC Playbook 분석

Anthropic이 2026년 8월 21일 공개한 AI-Native SDLC Playbook을 처음 읽었을 때, 가장 눈에 들어온 문장은 의외로 새로운 모델이나 새로운 코딩 기능에 관한 말이 아니었습니다.

Code is no longer the bottleneck.

코드는 더 이상 병목이 아니라는 선언입니다. 에이전트가 코드를 작성하는 속도는 이미 사람이 기존 프로세스 안에서 검토하고 승인하고 배포할 수 있는 속도를 넘어섰습니다. 그런데 많은 조직은 여전히 예전과 같은 승인 게이트, 티켓, 핸드오프, 회의, 수동 리뷰를 유지합니다.

그러면 어떤 일이 생길까. Build 단계만 몇 시간으로 줄고, Plan과 Design은 몇 주, Review와 Deploy는 며칠씩 걸린다. 생산성이 올라간 게 아니라 파이프라인 한가운데에 작은 자동화 섬 하나가 생긴 셈입니다.

이 플레이북의 가치는 “Claude Code로 코드를 빨리 작성하는 법”에 있지 않습니다. 개발 생명주기 자체를 선형 프로세스에서 커밋 가능한 산출물이 다음 단계를 자동으로 여는 루프로 바꾸자는 제안에 있습니다.

기존 SDLC의 전제는 이미 깨졌다

전통적인 SDLC는 대체로 Plan, Design, Build, Test, Deploy, Maintain의 여섯 단계로 나뉩니다. 제품 담당자가 요구사항을 정리하고, 설계자가 디자인을 만들고, 개발자가 구현하고, QA가 검증하고, 릴리스 팀이 배포하고, 운영 팀이 모니터링합니다.

이 구조는 코드 작성이 가장 비싸고 오래 걸리던 시기에 합리적이었다. PRD와 추정 회의는 개발 전에 정렬하기 위한 장치였고, 보안 검토는 구현 결과를 사람이 천천히 읽는 방식으로 작동했다. 각 단계의 소유자를 나눈 것도 책임 소재를 분명히 하기 위해서였다.

문제는 구현 속도만 급격히 달라졌다는 데 있습니다. 에이전트는 수십 개 파일을 읽고, 테스트를 만들고, 코드를 수정하고, 명령을 실행합니다. 반면 조직의 승인 위원회는 여전히 일주일에 한 번 열린다. 보안 팀의 검토 처리량은 사람이 작성하던 코드 양을 기준으로 잡혀 있습니다. PR 리뷰어는 diff의 모든 줄을 직접 읽으려 합니다.

따라서 코드가 빨라질수록 병목은 좌우로 이동합니다.

• Plan: 무엇을 만들어야 하는지 합의하는 시간
• Design: 요구사항과 정책을 설계로 바꾸는 시간
• Test/Review: 결과가 의도와 정책을 만족하는지 확인하는 시간
• Deploy: 운영 환경에 안전하게 내보내는 시간

특히 규제 산업에서는 보안 검토 큐가 길어지거나 검토되지 않은 코드가 배포되는 두 가지 나쁜 선택만 남습니다. AI-Native SDLC는 이 문제를 “사람을 빼자”로 해결하지 않습니다. 사람의 판단은 남겨두되, 사람이 매번 처음부터 읽어야 하는 자료와 기계적으로 확인할 수 있는 통제를 에이전트와 자동화된 게이트로 옮긴다.

AI-Native SDLC는 선이 아니라 루프다

Anthropic이 제시하는 전환은 다음과 같다. 전통적인 개발은 단계 사이를 문서, 티켓, 사인오프로 이동합니다. AI-native 개발은 각 단계의 결과를 Git에 커밋하고, 그 커밋이 다음 단계를 시작하게 합니다.

아이디어는 intent.md가 됩니다. 승인된 의도는 spec.md가 됩니다. 설계는 plan.md로 구체화됩니다. 구현은 diff와 테스트가 됩니다. PR에는 자동 리뷰 결과가 남습니다. 운영 중 이상이 발견되면 진단 결과가 다시 새로운 intent.md로 들어옵니다.

이 연결이 중요한 이유는 파일 확장자가 Markdown이어서가 아닙니다. 하나의 산출물이 사람과 에이전트 모두에게 읽히고, 버전 관리되며, 다음 작업의 입력으로 바로 사용되기 때문이다. 커밋 기록은 “누가 무엇을 원했고, 에이전트가 무엇을 만들었으며, 누가 승인했는가”를 보여주는 감사 추적이 됩니다.

다만 여기서 Git을 만능 도구로 오해하면 곤란합니다. 이미 Jira, ServiceNow, Figma, 규제용 요구사항 시스템이 있는 조직은 그것들을 하루아침에 버릴 수 없습니다. 플레이북도 기존 시스템을 없애라고 하지 않습니다. 대신 산출물마다 하나의 source of truth를 정하고, 나머지는 링크나 복사본으로 유지하라고 합니다. 최소한 문서에 이슈 ID를 넣고, 이슈에는 커밋 SHA를 남겨도 전환을 시작할 수 있습니다.

1. Plan: 아이디어를 intent.md로 고정한다

Plan 단계에서 중요한 것은 요구사항을 더 정교한 회의 문서로 만드는 데 있지 않습니다. 아이디어의 출발점이 된 사람의 언어를 가능한 한 덜 잃고, 다음 단계가 실행할 수 있는 형태로 고정하는 것입니다.

사용자는 “고객이 청구 상태를 확인하려고 콜센터에 전화한다”처럼 문제를 자신의 말로 설명합니다. Claude는 영향을 받는 사용자와 시스템, 제약, 성공 조건, 미해결 질문을 묻습니다. 그 결과가 intent.md입니다. 제품 담당자는 파일을 검토하고 수정한 뒤 커밋합니다.

이 방식은 기존 백로그 작성 흐름과 다릅니다. 기존에는 아이디어가 티켓, 사용자 스토리, 스토리 포인트, 정제 회의, 요구사항 문서로 여러 번 번역됩니다. 번역이 반복될수록 원래의 문제의식은 희미해지고, 엔지니어링에 전달되는 것은 처음 의도와 몇 단계 떨어진 문장이 됩니다.

intent.md는 완성된 요구사항 명세가 아닙니다. 오히려 “왜 이 일을 하는가”를 보존하는 proto-spec에 가깝습니다. 그래서 좋은 템플릿에는 기능 목록만 들어가면 안 됩니다.

# Intent: 청구 상태 셀프서비스

## Problem
고객이 청구 상태를 물어보려고 콜센터에 전화한다.

## Proposed outcome
포털에서 현재 상태, 다음 단계, 예상 처리일을 확인한다.

## Constraints
- 기존 인증만 사용한다.
- 새 PII를 브라우저 세션에 추가하지 않는다.

## Open questions
- 외부 손해사정인도 접근해야 하는가?

이 단계에서 측정할 값도 분명하다. 첫 대화에서 커밋된 intent.md까지 걸린 시간이 얼마나 줄었는지, 그리고 제품 담당자가 다음 단계로 받아들인 의도의 비율이 어떤지다. 문서를 잘 쓰는 것보다 아이디어가 실행 가능한 기록으로 바뀌는 시간을 줄이는 것이 목적입니다.

2. Design: 요구사항과 설계를 한 세션으로 압축한다

승인된 intent.md를 입력으로 Claude가 요구사항 및 설계 명세를 만듭니다. 여기서 조직의 브랜드 규칙, 보안 정책, 컴플라이언스, UX 표준은 자연어로 매번 다시 설명하는 지침이 아니라 version-controlled Skills로 주입됩니다.

전통적인 구조에서는 분석가가 요구사항을 쓰고 디자이너가 그것을 해석합니다. 책임 분리를 위해 필요한 구조였지만, 그 과정에서 요구사항과 디자인 사이에 손실이 생깁니다. AI-native 흐름에서는 제품 담당자가 원래 의도를 확인하고, 에이전트는 코드베이스와 정책을 함께 읽어 spec.md를 만듭니다. 에이전트는 정책 충돌이나 위험한 가정을 “해결한 척”하지 않고 우려 사항으로 표시합니다.

이 장면에서 사람의 역할은 줄어드는 동시에 더 중요해집니다. 제품 담당자는 문서의 문장을 대신 작성하지 않아도 되지만, 이 명세가 정말 문제를 해결하는지, 열린 질문이 답변됐는지, 위험을 누가 승인해야 하는지는 판단해야 합니다. 설계가 맞는지 확인하는 판단을 코드가 생성된 뒤로 미루지 않는 것도 포인트다.

3. Build: 코드를 쓰기 전에 plan.md를 승인한다

플레이북은 Claude Code의 plan mode를 구현의 기본 진입점으로 제안합니다. 에이전트가 코드를 수정하기 전에 저장소를 읽고, 변경 파일, 작업 순서, 위험 요소, 검증 방법을 담은 plan.md를 만듭니다. 엔지니어는 “무엇이 깨질 수 있는가”, “가장 위험한 단계는 무엇인가”, “왜 다른 대안을 선택하지 않았는가”를 물으며 계획을 다듬는다.

이것은 개발자의 사고 과정을 문서화하자는 정도의 이야기가 아닙니다. 완성된 diff를 보고서야 설계 오류를 발견하는 비용을 앞단의 문서 편집 비용으로 바꾸는 장치다. 계획이 틀렸다면 아직 파일을 건드리지 않았으므로 수정이 싸다.

# Plan: 청구 상태 셀프서비스

## Files that change
- portal/src/claims/StatusPanel.tsx
- claims-api/routes/status.py
- claims-api/tests/test_status.py

## Risks
claims-core API가 초당 50건으로 제한되므로 패널에 캐시가 필요하다.

## Proof
네 가지 청구 상태를 테스트하고 승인된 목업과 스크린샷을 비교한다.

구현 중 계획에서 벗어나면 코드만 수정하지 말고 plan.md도 같은 커밋에서 업데이트합니다. 이 규칙이 지켜져야 계획과 실제 변경의 차이가 숨겨지지 않습니다. 안정적인 테스트와 훅, 저장소 맥락이 충분히 쌓이면 일상적이고 위험이 낮은 작업은 auto mode로 여러 세션에서 병렬 처리할 수 있습니다. 다만 자동 수락은 신뢰의 출발점이 아니라, 통제가 축적된 뒤의 운영 모드다.

CLAUDE.md는 위키가 아니라 실행 맥락이다

Build 단계에서 특히 실용적인 제안이 CLAUDE.md다. 새로 합류한 개발자가 첫날 알아야 할 명령, 아키텍처, 규칙, 에이전트가 반복해서 틀리는 내용을 저장소 안에 둔다.

## Commands
- Test: make test
- Lint: make lint

## Conventions
- Money는 항상 BigDecimal을 사용한다.
- 모든 endpoint에는 integration test가 있어야 한다.

## Things Claude gets wrong
- 생성된 클래스는 직접 수정하지 않는다.
- frozen 된 v1 패키지 대신 v2에 변경한다.

중요한 점은 길게 쓰지 않는 것이다. Claude가 매 세션 읽는 파일이므로 한 페이지 안에 유지하고, 같은 실수가 두 번 반복됐을 때 교정을 추가합니다. 이 파일이 팀의 기억을 대체한다기보다, 팀의 암묵지를 에이전트가 매번 같은 방식으로 읽을 수 있는 형태로 바꾼다고 보는 편이 정확합니다.

조직 공통 정책은 CLAUDE.md와 분리해 Skills로 둔다. 보안 API 검토처럼 여러 작업에 반복 적용되는 지식은 .claude/skills/<name>/SKILL.md에 적고, 필요하면 플러그인으로 조직 전체에 배포합니다. 반면 Skill은 권고적 통제다. 반드시 지켜야 하는 정책은 보호된 경로 편집 차단, formatter/linter 실행, credential 유출 방지 같은 Hook이나 PR 검토가 뒤에서 다시 확인해야 합니다.

4. Test: 테스트를 끝의 문이 아니라 지속적인 평가로 바꾼다

전통적인 QA는 단계 경계에 놓인 게이트다. AI-native SDLC에서는 테스트와 평가가 구현 중 계속 실행됩니다. 특히 에이전트의 설정이 바뀌면 코드 변경과 같은 수준으로 회귀 검증해야 합니다.

여기서 설정은 모델만 뜻하지 않습니다. CLAUDE.md, Skills, Hooks, 프롬프트가 모두 에이전트의 행동을 바꿉니다. 따라서 이 파일들을 고쳤는데 테스트를 실행하지 않는 것은 핵심 라이브러리를 고치고 테스트를 건너뛰는 것과 비슷합니다.

실무적인 시작점은 최근 작업에서 20~50개의 실제 과제를 골라 프롬프트와 합격 조건을 함께 저장하는 것이다. 테스트 통과, lint 통과, 기존 동작 보존, 정책 준수처럼 결과를 판정할 수 있어야 합니다. CI가 비대화형으로 에이전트를 실행하고, 설정 변경 PR과 일정 주기에 eval suite를 돌린다. 운영 장애가 발생하면 해당 장애를 영구적인 eval 케이스로 추가합니다.

이 설계는 “AI가 만든 코드라서 테스트가 더 필요하다”는 수준을 넘습니다. 에이전트가 바뀌었을 때 조직의 개발 능력이 퇴행하지 않았는지를 측정하는 회귀 테스트다. 모델 교체, 프롬프트 변경, 정책 수정이 모두 제품 품질의 변경이 됩니다.

5. Deploy: 에이전트는 생산 게이트 앞에서 멈춘다

Deploy 단계에서 에이전트는 PR을 리뷰하고, 자신의 PR에 달린 리뷰 의견을 처리하고, 실패한 검사를 고칠 수 있습니다. 하지만 사람의 승인 없이 main에 직접 쓰거나 운영 배포까지 진행해서는 안 됩니다. 브랜치 보호와 code owner 승인이 최종 책임선을 만듭니다.

리뷰의 초점도 달라진다. 사람이 모든 줄을 같은 깊이로 읽는 대신, 에이전트가 버그, 보안, 컴플라이언스 검토를 일관되게 수행하고 중요도별로 결과를 올린다. 사람은 이 변경이 의도한 문제를 해결하는지, 위험을 받아들일 수 있는지에 집중합니다.

REVIEW.md에 리뷰 패스를 명시할 수 있습니다. 예를 들어 논리 오류와 경계 조건, injection과 인증 누락, spec.md 및 plan.md와의 일치 여부를 각각 검사하고, Important와 Nit의 기준을 정의합니다. CI가 이미 보장하는 생성 파일이나 포맷 오류를 또 보고하지 않도록 제외 범위도 정합니다.

여기서 중요한 운영 원칙은 승인 요청을 Build 중 매번 띄우지 않는 것입니다. 승인 프롬프트가 모든 병렬 세션의 실행 경로에 들어가면 사람이 다시 병목이 됩니다. 사람이 개입해야 하는 판단은 Deploy 게이트에 모으고, 나머지는 빠르고 결정적인 Hook과 CI 검사로 처리합니다.

6. Maintain: 운영 이상을 다시 intent.md로 넣는다

가장 흥미로운 부분은 Maintain 단계입니다. 전통적인 유지보수는 사람에게 티켓이나 장애가 도착한 뒤 누군가 작업을 시작하는 방식입니다. AI-native 유지보수는 모니터링 시스템의 trigger가 사람 없이 에이전트를 호출하고, 진단 결과를 다시 개발 루프에 넣는다.

예를 들어 CI 테스트 실패율, 배포 후 5xx 비율, PR cycle time에 안정적인 rolling baseline을 둔다. 편차가 1시그마면 기록만 하고, 2시그마면 읽기 전용 진단을 실행하며, 3시그마면 에이전트가 PR을 열거나 사전 승인된 rollback runbook을 호출할 수 있습니다. 이상 감지는 모델이 아니라 결정적인 스크립트가 맡는다. 모델은 경계가 넘은 뒤 진단하고, 허용된 경로로만 행동합니다.

진단 결과는 문제, 근거, 영향을 받는 시스템, 제안 결과, 미해결 질문을 담은 intent.md가 됩니다. 이후 Plan부터 Deploy까지 동일한 게이트를 통과합니다. 장애가 해결되면 그 사례를 eval에 추가합니다. 이 구조가 자리 잡으면 운영에서 발견된 문제가 사후 회고 문서에만 머물지 않고 코드와 테스트의 변화로 돌아옵니다.

이 루프에는 반드시 권한 경계와 rollback 경로가 있어야 합니다. “자율 운영”을 production에 대한 무제한 쓰기 권한으로 해석하면 안 됩니다. 에이전트가 할 수 있는 일은 버전 관리되는 설정으로 제한하고, 호출·진단·triage·승인을 모두 로그로 남겨야 합니다.

이 플레이북의 진짜 주제는 Claude가 아니다

표면적으로는 Claude Code, Skills, Hooks, Agent SDK를 활용하는 Anthropic의 실천 가이드다. 그러나 더 일반적인 메시지는 조직의 개발 지식을 실행 가능한 파일과 게이트로 바꾸라는 데 있습니다.

CLAUDE.md는 에이전트가 읽는 팀의 맥락이다. SKILL.md는 반복 적용되는 정책이다. Hook은 절대 깨지면 안 되는 규칙을 결정적으로 막는다. intent.md, spec.md, plan.md는 사람과 에이전트가 공유하는 작업 계약입니다. Continuous evals는 이 계약과 에이전트 설정이 여전히 유효한지 감시합니다.

이 관점에서는 에이전트를 도입했는데 생산성이 오르지 않는 조직의 문제도 설명됩니다. 모델 성능이 부족해서가 아니라, 에이전트가 읽을 수 있는 최신 맥락이 없고, 작업의 수락 기준이 없으며, 산출물 사이의 연결이 없기 때문이다. 개발자는 매 세션 같은 설명을 반복하고, 에이전트는 같은 실수를 반복하고, 리뷰어는 이미 자동화할 수 있는 사실 확인을 다시 합니다.

반대로 좋은 하네스는 에이전트에게 더 많은 자유를 주는 장치가 아닙니다. 어떤 파일을 읽어야 하는지, 어떤 규칙을 따라야 하는지, 어디에서 멈춰야 하는지, 실패하면 어떤 산출물을 남겨야 하는지를 명확히 하는 장치다.

도입할 때 가장 먼저 할 일

전사적인 SDLC 개편부터 시작할 이유는 없습니다. 위험이 낮고 반복적인 한 종류의 변경을 골라 산출물 체인을 실험하는 편이 낫습니다.

예를 들어 작은 내부 도구 기능에 intent.md와 spec.md를 도입하고, Claude Code plan mode에서 plan.md를 승인한 뒤, CI에서 테스트와 에이전트 리뷰를 실행합니다. 저장소에는 짧은 CLAUDE.md를 두고, 반복되는 보안 규칙 하나만 Skill로 만듭니다. 운영 자동화는 그 다음이다.

성과는 “AI가 몇 줄을 작성했는가”보다 다음 지표로 보는 편이 낫습니다. 의도에서 명세까지 걸린 시간, 계획 승인에서 PR 병합까지의 시간, 첫 시도에 통과한 비율, PR당 재작업 횟수, 리뷰 시간, CI에서 잡은 회귀와 운영에서 발견한 회귀의 비율, 장애가 새 eval로 등록되기까지 걸린 시간이다.

이 순서를 지키면 자동화의 범위를 늘리면서도 사람이 책임져야 할 판단을 놓치지 않을 수 있습니다. 반대로 문서와 게이트 없이 auto mode부터 켜면, 빠른 코드 생성이 빠른 재작업 생성으로 바뀔 가능성이 높습니다.

Anthropic의 블로그 원문과 Claude Academy의 입문 강의는 AI-native SDLC를 완성된 제품 도입 매뉴얼이라기보다, 조직이 자기 프로세스를 다시 설계할 때 사용할 수 있는 플레이북으로 제시합니다. 가장 중요한 변화는 개발자가 코드를 덜 쓰는 것이 아닙니다.

사람은 의도와 위험을 판단하고, 에이전트는 반복 작업과 증거 수집을 수행하며, Git에 남은 산출물과 자동화된 게이트가 둘 사이를 연결합니다. 코드가 빨라진 시대에 필요한 것은 더 빠른 타이핑이 아니라, 그 속도를 감당할 수 있는 개발 시스템입이다.