무엇이 바뀌고 어디서 시작할 것인가 · AI 네이티브 SDLC 플레이북

조직들은 1년 전만 해도 상상할 수 없었던 속도로 AI를 사용해 코드를 작성하기 시작했지만, 코드를 둘러싼 프로세스는 같은 속도로 변화하지 못했습니다.

소프트웨어 개발 생명주기(SDLC)는 소프트웨어를 아이디어에서 프로덕션까지 이끄는 과정입니다. 대부분의 조직은 계획, 설계, 빌드, 테스트, 배포, 유지보수를 포괄하는 동일한 여섯 단계의 어떤 버전을 운영합니다.

변화의 양상

아래 표는 전통적인 SDLC와 Claude가 지원하는 AI 네이티브 SDLC 사이의 스펙트럼 양 끝을 보여줍니다. 대부분의 조직은 두 열 사이 어딘가에 위치합니다.

단계	전통적인 SDLC	AI 네이티브 SDLC
계획	위원회가 요구사항을 수집하고, 워크숍과 승인을 거쳐 정제한 뒤 수작업으로 작성	Claude가 소스로부터 직접 문제점을 종합하여 사람이 읽을 수 있고 기계가 실행할 수 있는 `intent.md`에 담아냄
설계	분석가가 명세를 작성하고, 디자이너가 이를 해석	요구사항과 설계가 에이전트와의 단일 작업 세션으로 압축되며, 스킬로 인코딩되고 Git에서 버전 관리되는 표준의 안내를 받음
빌드	테스트와 코드를 수작업으로 작성하고, 주요 개발이 끝난 후 문서를 작성	AI가 테스트와 코드를 생성하며, 조직의 지식은 버전 관리되는 기계 판독 가능한 `CLAUDE.md` 파일과 스킬로 유지됨
테스트	단계 경계에서의 QA 게이트	구현 전반에 엮여 있는 지속적인 평가
배포	사람이 모든 코드 줄을 검토하며, 거버넌스는 흔히 일관성 없이 리뷰 사이클에서 이루어짐	에이전트 기반 검토가 여러 겹으로 이루어지고, 사람의 검토는 규제 대상 및 중요 코드에 한정됨. 거버넌스는 AI가 동작하는 동안 강제되며, 훅이 승인 게이트 역할을 함
유지보수	사람이 프로덕션에서 버그를 감시	에이전트가 실제 배포를 모니터링함. 제어 범위를 벗어난 사항은 진단되어 새로운 `intent.md`로 루프에 다시 기록됨

판단이 필요한 모든 결정에 대해서는 여전히 사람이 책임을 집니다.

플레이는 플레이북의 핵심이며, 전체 생명주기를 포괄하는 여섯 개의 비선형 단계(계획, 설계, 빌드, 테스트, 배포, 유지보수)로 그룹화되어 있습니다.

각 플레이는 다음을 다룹니다:

각 플레이는 "전제 조건" 아래에 의존성을 명시하며, 의존성 그래프가 이를 더 자세히 보여줍니다.

플레이는 모듈식으로 구성되어 있으며, 조직은 고유한 필요에 따라 서로 다른 시점에 서로 다른 단계의 전환을 우선시하도록 선택할 수 있습니다.

위 그래프의 맨 위 행에 있는 여섯 개의 플레이는 전제 조건이 없습니다: