이 영상에서 단테는 Anthropic이 공개한 "AI 네이티브 SDLC 플레이북"의 내용을 단계별로 정리했습니다. 핵심은 INTENT.md에서 시작해 스펙, 계획 문서로 이어지는 문서 흐름을 만들고, 에이전트를 빌드 단계뿐 아니라 개발 생명 주기 전체에 참여시키는 방식입니다. 팀에서 Claude Code, Codex, Cursor 같은 코딩 에이전트를 쓰면서 개발 프로세스를 어떻게 다시 짤지 고민하는 분께 맞는 내용입니다.
병목은 코드가 아니라 프로세스
SDLC(소프트웨어 개발 생명 주기)는 계획, 설계, 빌드, 테스트, 배포, 유지보수로 이어지고, 다음 기능이나 버그가 생기면 다시 처음으로 돌아가는 흐름입니다. 에이전트가 오기 전에는 이 중 빌드 단계가 시간과 비용을 가장 많이 차지했습니다.
플레이북의 주장은 "이제 병목은 코드가 아니라 프로세스"라는 것입니다. 에이전트 덕분에 빌드 구간이 크게 줄었으니, 이제 나머지 단계를 에이전트로 어떻게 개선할지가 과제라는 이야기입니다.
계획 단계: 에이전트가 먼저 인터뷰하고 INTENT.md를 만든다
예전 계획 단계는 요구 사항을 모으고, 문서를 쓰고, 워크숍을 열어 이해관계자 의견을 취합하는 방식이었습니다. 새 방식은 반대로 에이전트가 먼저 사람을 인터뷰합니다. 어떤 기능인지, 어떤 버그인지, 무엇을 만들려는 것인지 묻고, 사람은 자신의 경험과 도메인 지식을 대화에 최대한 쏟아 놓습니다. 단테도 자신이 원하는 것을 에이전트가 완전히 이해할 때까지 반복해서 질문하게 하는 방식을 쓴다고 말합니다.
그러면 에이전트가 핵심 문제를 뽑아 INTENT.md 파일로 정리합니다. 사람이 읽어도 되고 에이전트가 바로 실행해도 되는 형태입니다. 프로젝트에 intent 폴더를 만들고 그 안에 저장하면 되며, Cursor, Claude Code, Codex 어디서든 쓸 수 있습니다. 예를 들어 다크 모드를 추가하고 싶다면, 에이전트와 원하는 동작을 이야기한 뒤 그 결과를 INTENT.md로 남기는 식입니다.
INTENT.md가 만들어졌다고 끝이 아닙니다. 처음 이슈를 낸 사람(오리지네이터)이 에이전트가 쓴 내용을 확인하고, 둘 다 만족할 때까지 고칩니다. 오리지네이터는 전문가일 필요가 없고, 버그를 제보한 고객이나 기능을 제안한 PM일 수도 있습니다. 인텐트가 쌓이면 종류별로 파일명에 접두어를 붙이기도 하고, 이를 백로그로 정리하는 일은 프로덕트 오너가 맡습니다. 단테는 백로그 정리를 에이전트에게 맡겨 프론트엔드 여부, 작업 크기, 우선순위 태그를 달게 하기도 한다고 소개했습니다.
설계 단계: 인텐트에서 스펙으로
인텐트가 확정되면 훅이나 자동화 프로세스로 스펙을 생성합니다. 이렇게 단계마다 문서가 하나씩 붙어 이어지는 것을 플레이북은 아티팩트 체인이라고 부릅니다. Anthropic은 인텐트를 스펙으로 바꾸는 샘플 프롬프트를 제공하는데, 대략 다음 내용입니다.
- 첨부된 INTENT.md를 읽고 요구 사항과 설계 스펙을 만든다.
- 사용 가능한 스킬을 적용해 계획하고 브랜드 가이드라인을 지킨다.
- 결과를 SPEC.md로 문서화한다.
구체적인 스킬까지 주는 것은 아니어서, 이를 바탕으로 팀에 맞는 스킬을 직접 만들 수 있습니다. 기본 플랜 모드를 써도 되고 전용 스킬을 만들어도 됩니다. 스타일 가이드 같은 조직의 기준은 AGENTS.md나 정책 스킬에 담아, 스펙을 만들 때뿐 아니라 아티팩트 체인 전체에서 지켜지게 하는 것이 중요합니다.
빌드와 테스트: PLAN.md와 검증 기준
빌드 단계에서는 엔지니어가 인텐트와 스펙을 Claude Code나 Cursor의 플랜 모드에 넣어 PLAN.md를 만듭니다. 플레이북은 이 계획에서 무엇이 잘못될 수 있는지 계속 질문하라고 권합니다. 목표는 PLAN.md 하나만 다른 엔지니어나 에이전트에게 넘겨도, 인텐트나 스펙을 보지 않고 바로 구현할 수 있는 수준입니다. 여러 에이전트와 서브에이전트가 단계를 나눠 맡기 때문에, 이전 대화를 몰라도 시작할 수 있어야 하기 때문입니다.
좋은 계획에는 바꿀 파일, 작업 순서, 할 일 목록, 리스크와 제약, 그리고 증명이 들어갑니다. 증명은 계획대로 됐는지 판단할 기준으로, 린트나 테스트처럼 결정적인 형태여야 합니다. 규모 있는 조직이라면 계획, 인텐트, 스펙 문서의 버전과 수정 이력을 기록해 AI의 효과를 지표로 증명할 수 있게 하라고 권합니다.
빌드 속도를 위해 플레이북은 오토 모드를 추천합니다. 단테는 통제된 환경에서 시작해 권한을 하나씩 승인하며 넓혀 가고, 허용할 도구, 웹 소스, 패키지 정책이 쌓이면 이를 권한 설정에 반영하는 방식을 권했습니다. 워크트리로 여러 에이전트를 병렬로 돌리고, 훅으로 구현 후 계획을 자동 업데이트하거나 특정 폴더 수정, 승인되지 않은 npm 패키지 업그레이드를 막을 수 있습니다.
테스트 단계에서는 사람이 보기 전에 에이전트가 최대한 많이 확인하게 합니다. 에이전트가 테스트를 작성해 기존 기능이 깨지지 않았는지 확인하고, 린트와 빌드 오류를 보고, Playwright 같은 도구로 실제 화면을 테스트하고 스크린샷까지 남기게 할 수 있습니다. 또 이미 해결한 이슈 20개 정도를 기대 결과와 함께 모아 두고, 모델이나 스킬이 바뀔 때마다 돌려 퇴보하지 않는지 확인하는 평가를 CI에 넣어 두라고 제안합니다.
배포와 유지보수
배포 단계에서는 사람 리뷰 후 에이전트가 PR을 만들고, PR마다 Claude가 정책과 보안 기준으로 리뷰합니다. 리뷰 코멘트를 처리하는 별도 인스턴스를 두거나, 특정 승인자나 릴리스 게이트를 통과해야만 배포되도록 훅을 걸 수도 있습니다.
단테가 가장 야심찬 부분으로 꼽은 것은 유지보수입니다. 기존 유지보수는 새벽 알림을 받고 대응하는 반응적인 단계였지만, 플레이북은 장애 알림, 티켓, Slack 메시지, 정해진 스케줄이 사람 없이 바로 Claude를 호출하게 합니다. Claude는 비동기로 진단하고, 로그와 티켓을 바탕으로 스스로 INTENT.md를 만들어 해결 방안까지 제시합니다.
단테는 이미 다른 방법론이나 자신만의 워크플로를 쓰고 있다면 버리고 갈아탈 필요는 없다고 말합니다. 각 단계에 사람을 얼마나 둘지는 팀과 위험도에 따라 달라집니다.
정리
- 플레이북의 전제는 에이전트를 빌드에만 쓰지 말고 SDLC 전체에 참여시키자는 것입니다.
- 에이전트가 사람을 인터뷰해 INTENT.md를 만들고, 이것이 스펙과 PLAN.md로 이어지는 아티팩트 체인이 됩니다.
- PLAN.md는 다른 에이전트가 이전 대화 없이 구현할 수 있을 만큼 자세해야 하고, 린트·테스트 같은 증명 기준을 담아야 합니다.
- 권한, 훅, 워크트리, CI 평가로 에이전트를 빠르게 돌리면서도 통제할 수 있습니다.
- 정답은 하나가 아니며, 팀의 위험도에 맞게 사람의 리뷰 지점을 남겨 두는 것이 중요합니다.