AI 네이티브 SDLC 플레이북 — 코드는 더 이상 병목이 아니다

1. 이 글은 무엇에 관한 글인가?

한 줄로 요약하면 이렇습니다.

코드 작성이 빨라진 만큼, 병목은 그 앞뒤로 옮겨갔습니다. 기획·설계·리뷰·테스트·배포는 여전히 사람 속도로 돌아갑니다. AI 네이티브 SDLC 플레이북은 "그 나머지를 어떻게 다시 짤 것인가" 에 대한 Anthropic의 답입니다.

지난 글들은 점점 위로 올라오는 중이었습니다. 하네스를 어떻게 짤 것인가 → 컨텍스트를 어떻게 덜어낼 것인가 → 모델을 어떻게 고를 것인가. 이번 글은 그 위 한 칸, 개발 프로세스 전체 입니다.

전제가 깨졌는데 프로세스는 그대로다

플레이북의 첫 문장이 사실상 전부입니다.

"Code is no longer the bottleneck." (코드는 더 이상 병목이 아니다)

지금 쓰는 SDLC는 코드 작성이 가장 오래 걸리던 시절 에 설계된 것입니다. 백로그, 리파인먼트, 스프린트, 코드 리뷰 큐 — 전부 "구현이 제일 비싸다"를 전제로 최적화된 구조입니다. 그런데 그 전제가 깨졌습니다.

에이전트가 30분 만에 PR을 만든다
   ↓
리뷰 큐에서 3일 대기한다
   ↓
"AI 도입했는데 왜 안 빨라지죠?"

빨라진 건 한 단계뿐이고, 나머지는 그대로이기 때문입니다. 한 단계만 10배가 되면 전체는 10배가 되지 않고, 병목이 옮겨갈 뿐입니다.

플레이북이 제안하는 규칙은 사실 하나다

여섯 단계, 수십 개의 플레이가 나오지만 관통하는 규칙은 한 줄입니다.

각 단계는 다음 단계가 읽을 수 있는 아티팩트를 커밋한다. ("each stage commits an artifact the next stage can read")

선형 단계가 아니라 루프 가 되는 이유가 여기 있습니다. 사람만 읽던 산출물(회의록, 지라 티켓, 컨플루언스 문서)이 에이전트가 읽고 다음 단계를 시작할 수 있는 입력 으로 바뀝니다.

2. 여섯 단계와 아티팩트 사슬

먼저 전체 그림입니다.

Plan     → intent.md      문제 · 원하는 결과 · 영향받는 시스템 · 제약 · 미해결 질문
Design   → spec.md        조직 표준을 스킬로 적용한 명세 + 플래그된 우려사항
Build    → plan.md → PR   플랜 모드로 합의한 계획, 그 계획대로 만든 diff + 테스트
Test     → eval 결과      설정(CLAUDE.md·스킬·훅)이 바뀔 때마다 도는 지속적 eval
Deploy   → 배포 기록      리뷰 findings · 승인 게이트 로그
Maintain → intent.md      인시던트 진단이 다시 1단계 포맷으로 돌아온다

마지막 줄이 핵심입니다. 운영에서 발견한 문제가 다시 intent.md로 쓰여 파이프라인 맨 앞으로 들어갑니다. 그래서 단계가 아니라 루프입니다.

전통적 방식과 무엇이 다른가

3. 단계별로 무엇이 바뀌나

3-1. Plan — 회의 대신 intent.md

아이디어를 낸 사람이 직접 Claude와 브레인스토밍해서 intent.md를 만듭니다. 사람이 읽을 수 있고 기계가 실행할 수 있는 프로토 스펙 입니다.

여기서 중요한 건 형식이 아니라 누가 쓰는가 입니다. 엔지니어가 아닌 사람에게 Claude 접근 권한을 주고, 버전관리되는 공용 저장 위치를 마련하는 게 이 단계의 인프라 요구사항입니다.

• 선행 지표 — 첫 대화부터 intent.md 커밋까지 걸린 시간 (주 → 시간)
• 후행 지표 — 2단계로 넘어간 intent.md의 생존율

3-2. Design — 요구사항과 설계가 한 세션으로 합쳐진다

승인된 intent.md를 조직의 스킬(브랜드·보안·컴플라이언스·UX)이 로드된 세션 에 붙이면 Claude가 spec.md를 냅니다. 걸리는 부분은 플래그로 표시됩니다.

표준을 스킬로 인코딩 했기 때문에, 정책이 "스펙을 쓰는 도중에" 적용됩니다. 리뷰 때 걸리는 게 아니라요.

플래그된 우려는 엔지니어가 스펙을 보기 전에 정책 담당자에게 라우팅됩니다. 이게 뒤에서 다시 나올 패턴입니다 — 사후 검사가 아니라 행위 시점 강제.

3-3. Build — 플랜 모드가 기본값

가장 두꺼운 단계입니다. 다섯 개의 플레이가 있습니다.

그리고 이 단계에서 가장 실무적인 규칙 두 개가 나옵니다.

"Claude가 같은 실수를 두 번 하면, 그 교정은 CLAUDE.md로 들어간다."

"버그 수정은 실패하는 테스트를 먼저 쓰고 커밋한다. 그 다음에야 테스트를 고치지 말고 통과시키라고 시킨다."

두 번째 규칙이 특히 중요합니다. 테스트를 나중에 시키면 에이전트는 자기 구현에 맞춘 테스트 를 씁니다. 순서를 뒤집는 것만으로 오라클이 구현으로부터 독립됩니다.

또 하나 — 피드백 루프. Claude가 사람에게 보여주기 전에 스스로 테스트를 돌리고, 빌드하고, 스크린샷을 찍어 확인하게 만드는 것입니다. 검증을 사람 쪽에 남겨두면 그게 새 병목이 됩니다.

3-4. Test — eval이 게이트가 아니라 실이 된다

QA가 경계에서 문을 지키는 대신, eval 스위트가 구현 과정에 짜여 들어갑니다.

핵심은 언제 도는가 입니다. CLAUDE.md·스킬·훅이 바뀔 때 돕니다. 즉 에이전트의 설정을 코드처럼 취급하고, 그 변경에 회귀 테스트를 거는 것 입니다. 그리고 프로덕션 인시던트는 전부 영구 eval이 됩니다.

통과율 임계치를 머지 체크로 강제하고, 실행 기록을 남겨 비교한다.

이게 자가치유 하네스에서 다뤘던 "규칙을 더할 때도 검증받아라"와 정확히 같은 이야기입니다.

3-5. Deploy — 리뷰의 층위가 올라간다

Claude가 들어오는 PR을 정책 기준으로 리뷰하고, 자기가 낸 PR의 리뷰 코멘트도 직접 처리합니다. 테크리드는 REVIEW.md에 리뷰 정책 을 씁니다 — 어떤 패스(버그·보안·컴플라이언스)를 돌릴지, 심각도는 어떻게 나눌지, 사소한 지적(nit) 상한은 몇 개인지, 무엇을 제외할지.

"모든 PR이 동일한 리뷰 패스를 받는다. 사람의 주의는 한 층 위로 올라간다 — 이 변경이 계획이 의도한 것을 하고 있는가로."

그리고 훅이 승인 게이트 역할을 합니다. 프로덕션 배포는 지정된 사람의 승인 전까지 멈춥니다. 허용·차단 결정은 타임스탬프와 함께 로그로 남습니다.

배포 자체는 MCP로 스코프된 자격증명을 통해 노출합니다. 개발 환경은 에이전트가 자유롭게, 프로덕션은 게이트를 통과해야만.

"롤백은 파이프라인에서 가장 많이 연습된 경로여야 한다." 자율 에이전트가 롤백을 쓰게 하려면, 그 전에 스테이징에서 정기적으로 굴려봤어야 합니다.

3-6. Maintain — 루프를 닫는다

프로덕션 지표(테스트 실패율, 배포 후 5xx, PR 사이클 타임)를 감시하는 스크립트가 결정론적 규칙(Western Electric) 으로 이상을 판정합니다. 그리고 편차 정도에 따라 대응 권한을 나눕니다.

권한을 상황의 심각도에 비례시키는 이 설계가 개인적으로 이 플레이북에서 가장 인상적인 부분이었습니다. "에이전트에게 권한을 줄 것인가 말 것인가"가 아니라 "언제 얼마나 줄 것인가" 로 질문이 바뀝니다.

그리고 진단 결과는 1단계 포맷의 intent.md로 쓰여 트리아지 큐에 들어갑니다. 루프가 닫힙니다.

Slack/Teams 통합(Claude Tag)도 같은 원리입니다. Claude가 인시던트 채널의 멤버로 들어가 1차 대응을 하고, 대화가 그대로 감사 추적 이 됩니다.

"채널이 곧 감사 추적이다 — 요청, 진단, 사람의 승인, 수정이 전부 인시던트가 처리된 자리에 남는다."

4. 통제 장치 네 가지 — 무엇을 어디에 둘 것인가

실무에서 가장 자주 헷갈리는 지점입니다. 넷 다 "에이전트에게 규칙을 주는 것"인데 성격이 전부 다릅니다.

여기서 읽어야 할 신호는 강제력 열 입니다. CLAUDE.md와 스킬은 모델이 따라주기를 기대하는 것이고, 훅과 eval은 모델이 협조하지 않아도 성립하는 것 입니다. 지켜져야만 하는 규칙을 CLAUDE.md에 적어놓고 안심하는 게 흔한 실수입니다.

플레이북의 표현: "차단은 스스로를 설명해야 한다." 훅이 막을 때 왜 막았는지 알려주지 않으면 에이전트는 우회를 시도합니다.

5. 지표 — 선행만 재면 반드시 망한다

플레이북이 모든 단계마다 선행/후행 지표를 쌍으로 제시하는 데는 이유가 있습니다.

에이전트는 선행 지표를 아주 쉽게 좋게 만듭니다. PR은 10배로 늘고, 첫 리뷰까지 시간은 분 단위가 되고, 아이디어에서 스펙까지는 하루면 됩니다. 그런데 그게 품질이 유지된 상태에서의 가속인지, 나중에 갚을 빚인지 는 선행 지표만으로 절대 알 수 없습니다.

특히 이 두 개가 좋은 후행 지표입니다.

• 머지된 diff가 커밋된 plan.md와 얼마나 자주 일치하는가 — 계획대로 갔는지
• 첫 plan.md 이후에 같은 변경의 spec.md가 몇 번 더 커밋됐는가 — 요구사항이 뒤집혔는지

아티팩트를 커밋해두면 이 둘이 자동으로 측정 가능해집니다. 아티팩트 사슬의 진짜 값어치가 여기 있습니다. 감사 추적은 부수효과고, 본체는 측정 가능성 입니다.

6. 이 저장소에 대입해보면

읽기만 하면 남는 게 없으니, 지금 이 블로그 저장소를 여섯 단계에 대봤습니다.

솔직히 개인 블로그에 여섯 단계가 다 필요하지는 않습니다. 프로덕션 승인 게이트나 3σ 자율 대응은 이 규모에서는 과합니다. 하지만 규모와 무관하게 가져올 게 둘 있습니다.

① eval이 없는 게 제일 큰 구멍입니다. pre-commit이 lint·테스트·E2E를 다 돌리지만, 그건 전부 애플리케이션 코드 를 검사합니다. CLAUDE.md를 고치거나 하네스 스킬을 바꿨을 때 그게 에이전트 동작을 나쁘게 만들었는지 확인하는 장치는 하나도 없습니다. 설정을 코드처럼 취급하라는 게 이 플레이북의 요지인데, 정작 그 설정만 테스트 밖에 있는 셈입니다.

② plan.md는 혼자 일해도 값이 있습니다. 계획을 커밋해두면 나중에 "왜 이렇게 했더라"를 diff가 아니라 의도로 되짚을 수 있습니다. 1인 저장소에서도 3개월 뒤의 나는 남 입니다.

7. 오해하기 쉬운 지점

오해 1 — "결국 문서를 더 쓰라는 얘기 아닌가?"

아닙니다. intent.md·spec.md·plan.md는 사람에게 보고하는 문서가 아니라 다음 단계의 입력 입니다. 읽는 주체가 다릅니다.

구분 기준은 간단합니다. 아무도(사람도 에이전트도) 읽지 않는 아티팩트는 지우세요. 다음 단계가 실제로 그 파일을 먹고 시작하지 않는다면, 그건 플레이북이 말하는 아티팩트가 아니라 그냥 문서입니다.

오해 2 — "사람 리뷰가 없어지는 것"

반대입니다. 리뷰의 층위가 올라갑니다.

전: "이 diff에 버그 있나?"      ← 기계가 더 잘하는 질문
후: "이 변경이 plan.md의 의도대로인가?"  ← 사람만 답할 수 있는 질문

버그·보안·컴플라이언스 패스는 에이전트가 모든 PR에 동일하게 겁니다. 사람이 하던 것보다 일관됩니다(사람은 금요일 오후에 대충 봅니다). 남는 질문은 판단이 필요한 것들입니다.

오해 3 — "이건 대기업 얘기"

여섯 단계 전체 + Managed Settings + 3σ 자율 대응은 그렇습니다. 하지만 아티팩트 규칙 하나 는 혼자서도 오늘 적용할 수 있습니다. 플랜 모드로 계획을 받고, 그걸 커밋하고, 머지할 때 대조하는 것 — 인프라가 필요 없습니다.

8. 정리

그리고 이건 앞선 글들과 같은 이야기의 다른 축입니다.

• 자가치유 하네스 — 규칙을 더할 때 검증하라
• 덜어내는 컨텍스트 엔지니어링 — 규칙을 덜어낼 때 검증하라
• 모델 고르기 — 모델을 고를 때 검증하라
• 이번 글 — 프로세스를 바꿀 때 도 검증하라. 그게 eval이다

플레이북의 마지막 문장이 이 글의 마지막 문장으로도 적당합니다.

"루프는 계속 돈다. 사람의 판단은 그 위에 남는다." ("The loop keeps running. Human judgement stays above it.")

자동화되는 건 루프고, 자동화되지 않는 건 그 루프를 어디로 돌릴지 정하는 일 입니다.

참고 문서

• Anthropic, The AI-Native SDLC Playbook (2026)
• Anthropic, Claude Code Hooks · Agent Skills
• 이전 글 — 모델 고르기 · 덜어내는 컨텍스트 엔지니어링 · 자가치유 하네스 엔지니어링