AI 네이티브 SDLC 플레이북, 여섯 단계 중 먼저 바꿀 곳

Anthropic의 Applied AI 팀이 The AI-native SDLC playbook을 공개했습니다. 코딩 에이전트를 도입한 조직에서 생산성이 기대만큼 오르지 않는 이유를 진단하고, 소프트웨어 개발 수명주기 여섯 단계를 어떻게 재설계할지 단계별 실행 지침으로 정리한 문서입니다.

진단은 한 문장으로 요약됩니다. 전통적 SDLC는 코드 작성이 가장 오래 걸리고 비싼 단계라는 전제 위에 만들어졌는데 그 전제가 깨졌습니다. PRD와 산정 의식과 제품 보안 검토는 몇 주에서 몇 분기에 이르는 개발 기간 동안 정렬을 강제하려고 존재했습니다. 구현이 몇 시간으로 줄면 남은 장치들이 병목이 됩니다.

병목이 이동한 세 가지 방향

원문은 빌드 단계가 빨라질 때 세 가지가 동시에 참이 된다고 정리합니다.

현상	내용
병목의 좌우 이동	계획, 리뷰와 테스트, 배포가 여전히 사람 속도로 돌아가면서 새로운 제약이 됨
통제 수단의 무력화	사람이 쓴 코드를 한 줄씩 검토하는 방식은 에이전트가 diff 대부분을 쓰는 순간 유지 불가
거버넌스 비용 상승	예외 처리가 주 단위나 월 단위로 모이는 위원회를 계속 경유함

원문이 든 예가 보안 조직입니다. 보안팀 인원은 사람의 산출량에 맞춰 편성돼 있어서, 에이전트가 코드 산출량을 몇 배로 늘리면 검토 대기열이 쌓이거나 검토가 덜 된 코드가 배포됩니다. 규제 산업의 조직은 둘 다 받아들일 수 없습니다.

여섯 단계의 전환 내용

원문은 전통 방식과 AI 네이티브 방식을 스펙트럼의 양 끝으로 제시합니다. 대부분의 조직은 두 열 사이 어딘가에 있습니다.

단계	전통적 SDLC	AI 네이티브 SDLC
Plan	위원회가 요구사항을 모으고 워크숍과 승인을 거쳐 손으로 작성	Claude가 출처에서 문제점을 종합해 사람과 기계가 함께 읽는 intent.md로 기록
Design	분석가가 명세를 쓰고 디자이너가 다시 해석	요구사항과 설계를 한 세션으로 압축. 조직 정책을 skill로 인코딩해 제약으로 적용
Build	테스트와 코드를 손으로 작성하고 문서는 개발 후 작성	테스트와 코드를 AI가 생성. 조직 지식은 버전 관리되는 CLAUDE.md와 skill로 유지
Test	단계 경계마다 QA 게이트	구현 과정에 상시 eval을 엮어 넣음
Deploy	사람이 모든 줄을 검토하고 거버넌스는 리뷰 주기에 편승	에이전트 리뷰를 여러 겹으로 두고 사람 리뷰는 규제·핵심 코드에 집중
Maintain	사람이 운영 환경을 지켜봄	에이전트가 배포를 감시. 관리 한계를 벗어나면 진단해 새 intent.md로 루프에 재투입

오른쪽 열을 관통하는 것은 커밋된 산출물입니다. 각 단계는 산출물 하나를 버전 관리에 쓰면서 끝나고 다음 단계는 그것을 읽으면서 시작합니다. intent.md, spec.md, plan.md, 테스트를 포함한 diff, 리뷰 결과가 붙은 PR, 장애 기록이 그 사슬입니다. 커밋 이력이 그대로 감사 추적이 되어 누가 무엇을 요청했고 에이전트가 무엇을 만들었고 누가 승인했는지가 남습니다.

통제 수단의 계층

이 문서에서 실무적으로 가장 중요한 구분입니다. 원문은 skill과 hook의 성격을 명확히 나눕니다.

수단	성격	보장 수준	적용 위치
CLAUDE.md	세션마다 읽는 팀 지식	없음	저장소 루트, 한 페이지 이내
Skill	정책을 명시한 권고 통제	위반을 드물게 만듦	.claude/skills/, 또는 플러그인으로 조직 배포
Hook	행동 직전 실행되는 결정적 통제	허용·질의·차단을 매번 강제	.claude/settings.json
Managed settings	개인이 끌 수 없는 조직 정책	명령행 플래그로도 우회 불가	MDM 또는 관리 콘솔

원문의 표현대로 skill은 위반을 드물게 만들고 hook은 위반을 거의 불가능하게 만듭니다. 예외 없이 지켜야 하는 정책이 있다면 skill 뒤에 반드시 hook을 둬야 합니다. 관리형 설정 예시에는 비밀 파일 읽기 차단, 네트워크 도메인 허용 목록, 샌드박스 초기화 실패 시 기동 거부, 승인된 마켓플레이스 외 플러그인 차단, 최소 버전 강제가 들어 있습니다.

책임 분리도 유지됩니다. 코드를 쓴 에이전트는 그 코드를 승인할 경로가 없고 승인은 브랜치 보호 규칙을 통해 사람이 합니다.

측정 지표

원문은 각 단계마다 선행 지표와 후행 지표를 지정합니다. 도입 효과를 주장하려면 이 값들이 먼저 기록돼 있어야 합니다.

단계	선행 지표	후행 지표
Plan	첫 논의부터 intent.md 커밋까지 걸린 시간	제품 책임자가 수용한 intent.md 비율
Design	intent.md 커밋과 spec.md 커밋 사이 시간	빌드 시작 후 발생한 요구사항 재작업 건수
Build	첫 구현 시도로 머지된 변경 비율	변경당 재작업 사이클, 머지된 diff와 plan.md의 일치 여부
Test	에이전트 작성 변경의 CI 최초 통과율	PR당 리뷰 시간, 변경 실패율
Deploy	최초 리뷰까지 걸린 시간	머지 전 잡힌 결함 대비 운영에 유출된 결함
Maintain	한계 이탈부터 intent.md 생성까지 시간	동일 유형 장애의 재발률

도입 순서

원문은 플레이마다 선행 조건을 명시하고 선행 조건이 없는 것부터 시작하라고 안내합니다. 여기에 해당하는 항목은 CLAUDE.md 정비, skill 작성, hook 설정, intent.md 캡처, 피드백 루프 구성입니다.

가장 값싼 출발점은 피드백 루프입니다. 테스트와 빌드와 린트를 각각 한 줄 명령으로 만들고 CLAUDE.md의 명령 항목에 정상 출력 예시와 함께 적어 두면 세션이 사람에게 보고하기 전에 스스로 검증합니다. 버그 수정에서는 실패하는 테스트를 먼저 커밋하고 에이전트가 테스트 파일을 건드리지 못하도록 hook으로 막으라는 것이 원문의 지침입니다.

한국 조직에서 먼저 확인할 것

문서 전체가 git을 신뢰의 기반으로 삼습니다. 국내 도입 환경에서는 이 전제가 성립하는지부터 봐야 합니다.

확인 항목	왜 걸리는가
기록의 원본 위치	Jira나 요구사항 도구가 이미 규제 추적성을 갖고 있는 경우가 많습니다. 원문은 산출물마다 원본을 하나만 지정하라고 하며, 최소선은 양쪽에 상대 식별자를 남기는 연결입니다
망분리와 모델 접근	외부 API 호출이 막힌 환경이라면 Bedrock, Vertex, Foundry 경유 여부를 먼저 정해야 합니다
외주 개발 계약 구조	산출물이 문서 매수와 인월로 규정된 계약에서는 intent.md 중심 체인이 검수 기준과 충돌합니다
변경관리 위원회	원문은 위원회를 없애지 않고 hook으로 표현하라고 합니다. 승인 조건이 스크립트로 쓸 수 있을 만큼 명문화돼 있는지가 관건입니다
감사 대응	감사인이 커밋 이력을 증적으로 수용하는지 사전 합의가 필요합니다

오해하기 쉬운 지점

• 자동화 범위의 과대 해석: 에이전트는 운영 배포 게이트 앞까지만 행동하고 그 선을 넘지 못합니다
• 상시 eval의 대상: eval이 회귀 테스트하는 것은 에이전트를 조종하는 설정입니다. CLAUDE.md와 skill과 hook이 바뀔 때 돌립니다
• 병렬 세션의 한계: 원문은 두세 개를 출발점으로 제시하며 실질 상한은 한 사람이 제대로 검토할 수 있는 흐름의 수입니다
• 탐지 로직의 위치: 이상 탐지는 평균과 표준편차 기반의 결정적 스크립트가 맡습니다. 모델은 관리 한계를 벗어난 뒤에 호출됩니다

원문은 The AI-native SDLC playbook에서 볼 수 있습니다. 플레이마다 프롬프트 예시와 설정 파일 예시와 거버넌스 항목이 함께 실려 있어 사내 표준의 초안으로 쓸 수 있는 밀도입니다.