AI-Native SDLC, 실제 업무에 적용하기

The AI-Native SDLC Playbook : https://claude.com/blog/the-ai-native-sdlc-playbook

들어가며

기능 하나를 반나절이면 만들 수 있게 됐는데, 그 기능이 배포되기까지는 여전히 며칠이 걸립니다. 기획 의도를 다시 확인하고, PR 설명을 길게 쓰고, 리뷰어는 “이거 왜 이렇게 만들었죠?”를 물어보고, 그 답을 하려고 슬랙, 컨플루언스를 확인하는 시간이 늘었습니다.

Anthropic이 공개한 AI-Native SDLC Playbook은 정확히 이 문제를 다룹니다. 이 글에서는 플레이북의 내용을 정리하고, 그중 우리 팀 환경에 그대로 적용하기 어려운 부분을 어떻게 바꿔서 적용할지 정리해보려 합니다.

1. 배경: 코드는 더 이상 병목이 아닙니다

플레이북의 출발점은 단순합니다. AI 에이전트 덕분에 빌드 단계가 몇 주에서 몇 시간으로 압축됐고, 그 결과 사람의 속도로 작동하는 기획과 배포 단계가 새로운 병목이 되었다는 것입니다.

시간 배분의 변화

[전통적 SDLC]
기획  (15%)  ████▒▒
빌드  (70%)  █████████████████████████▒▒
배포  (15%)  ████▒▒
 
[AI-Native]
기획  (48%)  ███████████▒▒
빌드   (4%)  ▍▒▒
배포  (48%)  ███████████▒▒

각 블록은 대략적인 비율을 시각적으로 보여줍니다.

빌드가 4%로 줄어든 세상에서, 기존의 통제 방식(사람이 모든 라인을 읽는 리뷰)은 에이전트의 속도를 감당할 수 없습니다. 그렇다고 리뷰를 없앨 수는 없으니, 리뷰의 대상을 바꿔야 합니다. 코드 라인이 아니라 의도와 위험도를 보는 방향으로요.

플레이북은 단계별 차이를 이렇게 정리합니다.

단계	전통적 SDLC	AI-Native SDLC
기획 (Plan)	수작업 요구사항 정의, 워크숍	`intent.md` 기반 의도 캡처
설계 (Design)	분석가·디자이너의 분절된 핸드오프	설계 표준(Skills)이 주입된 단일 세션
구현 (Build)	수동 코드 작성 후 사후 문서화	`CLAUDE.md` 기반 자율 구현
검증 (Test)	단계 경계의 수동 QA 게이트	Continuous Evals 기반 연속 평가
유지보수 (Maintain)	사람의 모니터링과 수동 티켓 생성	이상 감지 시 새 `intent.md` 자동 생성

2. 핵심 메커니즘: Committed Artifact

가장 중요한 개념은 ‘Committed Artifact’ 입니다. 모든 단계가 버전 관리되는 마크다운 파일로 남고, 사람과 AI가 동일한 파일을 읽습니다.

The Artifact Chain

intent.md      →  spec.md          →  plan.md           →  PR & Diff
(아이디어와 의도)      (요구사항·정책 설계)     (실행 계획·변경 파일)      (최종 코드와 리뷰)

이 체인이 곧 감사 추적(Audit Trail)이 됩니다. 누가 요청했고, AI가 무엇을 만들었고, 누가 승인했는지가 커밋 히스토리에 영구히 남습니다.

여기서 ‘머신 액셔너블(Machine-actionable)’ 이라는 표현이 중요합니다. Notion이나 Jira에 아무리 잘 정리된 기획서가 있어도, 에이전트는 그걸 매번 사람이 복붙해줘야 읽습니다. 반면 저장소 안의 intent.md는 에이전트가 스스로 찾아 읽고 다음 단계를 실행할 수 있습니다.

3. 저장소 구조

권장 저장소 트리

root/
├── .claude/
│   ├── agents/          # 특정 임무를 수행하는 서브 에이전트
│   ├── skills/          # SKILL.md (보안, UX, 문서 작성 표준)
│   └── settings.json    # 권한 및 훅 설정
├── intent/
│   └── feature-[JiraID]/
│       ├── intent.md    # 기획 의도 및 문제 정의
│       ├── spec.md      # UI/API 상세 설계
│       └── plan.md      # 구현 순서 및 검증 계획
├── CLAUDE.md            # 프로젝트 컨벤션, 빌드/테스트 명령어
└── src/

여기서는 intent/feature-[JiraID]/ 처럼 티켓 ID를 폴더명에 사용합니다. 만약 Jira나 Linear를 사용하지 않는다면 ADR과 같이 특징을 담아도 좋습니다.

에이전트는 해당 폴더의 파일에만 집중하면 되므로 관련 없는 맥락을 끌어와 환각을 일으킬 여지가 줄어듭니다.
브랜치명(feature/PROJ-123), 폴더명(feature-PROJ-123), 티켓 ID가 같은 키로 묶여서 나중에 히스토리 파악에 용이합니다.

4. 사용 예시

1) intent.md — 왜 만드는지

intent/feature-PROJ-123/intent.md

# Intent: 지원자 목록 필터 저장 기능
 
- Jira: PROJ-123
- 작성자: (개발자) / 원 기획: (PO)
- 상태: draft | approved
 
## 문제 정의
채용 담당자가 매번 동일한 필터 조건을 다시 설정하고 있습니다.
주 3회 이상 같은 조건을 반복 입력한다는 CS 피드백이 있었습니다.
 
## 제안된 결과물
자주 쓰는 필터 조합을 저장하고 한 번에 불러올 수 있게 합니다.
 
## 영향 받는 시스템
- 지원자 목록 페이지
- 필터 상태 관리 로직
- 신규 API: 저장된 필터 CRUD
 
## 제약 사항
- 저장 개수는 계정당 10개로 제한합니다.
- 팀 공유 기능은 이번 범위에서 제외합니다.
 
## 열린 질문
- 필터 이름 중복을 허용하는가? → (PO 확인 필요)

2) spec.md — 어떻게 생겼는지

프론트엔드 작업이라면 아래 항목을 채웁니다.

항목	내용
UI 컴포넌트 계층	신규 컴포넌트와 재사용 가능한 기존 컴포넌트 구분
상태 관리 설계	로컬/서버/전역 상태의 소유 주체와 데이터 흐름
API 연동 규격	OpenAPI(Swagger) 링크, 요청·응답 스키마 매핑
접근성(A11y)	키보드 네비게이션, 포커스 트랩, 스크린 리더 레이블
디자인 토큰	브랜드 가이드라인 및 디자인 시스템 준수 여부
엣지 케이스	로딩, 빈 상태, 에러, 권한 없음

3) plan.md

intent/feature-PROJ-123/plan.md

## 변경 파일
- `src/features/applicants/api/savedFilters.ts` (신규)
- `src/features/applicants/hooks/useSavedFilters.ts` (신규)
- `src/features/applicants/ui/FilterBar.tsx` (수정)
 
## 구현 순서
1. API 클라이언트와 타입 정의
2. 훅 구현 + 단위 테스트
3. FilterBar에 UI 연결
4. E2E 시나리오 추가
 
## 리스크
- FilterBar는 대시보드에서도 사용 중 → props 변경 시 파급 효과 확인
- 목록 재조회가 필터 변경마다 발생하면 성능 저하 우려
 
## 검증 계획 (Proof)
- [ ] `pnpm test` 전체 통과
- [ ] 저장/불러오기/삭제 3개 시나리오 E2E 통과
- [ ] 필터 10개 초과 시 400 응답과 토스트 노출 확인
- [ ] 키보드만으로 저장·선택 가능한지 확인

플레이북에서 강조하는 개념이 Proof입니다. “테스트 잘 됐습니다”가 아니라, 에이전트가 스스로 통과 여부를 판정할 수 있는 구체적 기준을 미리 적어두는 것입니다. 이게 있으면 에이전트가 코드 생성 → 테스트 → 실패 진단 → 수정을 사람 개입 없이 반복할 수 있습니다.

4. Skill로 문서 작성 자동화하기

이 과정을 Skill로 만들어 작성 시간을 줄이고, 업무 방식을 동일하게 가져갑니다.

핵심적인 내용으로 동료들과 함께 만들어가는 것을 권장드립니다.

.claude/skills/create-intent/SKILL.md

---
name: create-intent
description: Jira 티켓 내용을 바탕으로 intent/feature-[JiraID]/intent.md를 생성합니다.
---
 
# Intent 문서 생성
 
## 절차
1. 입력받은 Jira 티켓 ID와 본문을 파싱합니다.
2. `intent/feature-[JiraID]/` 디렉터리를 생성합니다.
3. 아래 섹션을 **반드시 포함**하여 intent.md를 작성합니다.
   - 문제 정의 / 제안된 결과물
   - 영향 받는 시스템 및 제약 사항
   - Jira ID 매핑 및 작성자 정보
4. `.claude/skills/` 의 보안·UI 표준과 충돌하는 요구사항이 있으면
   문서 상단에 `## 확인 필요` 섹션으로 먼저 표기합니다.
5. 비즈니스 로직이 불명확하면 **추측하지 말고 질문**한 뒤,
   답변을 받아 `열린 질문` 섹션을 갱신합니다.
 
## 금지 사항
- 티켓에 없는 요구사항을 임의로 추가하지 않습니다.
- 구현 방법(spec/plan의 영역)을 intent.md에 섞지 않습니다.

5. 가드레일: 조직의 지식을 코드로

플레이북은 팀의 규칙을 세 계층으로 나눠 관리하라고 제안합니다.

Layers of Defense

Hooks         ← 결정적 통제. 예외 없음. 스크립트로 차단
Skills        ← 권고적 통제. 보안 가이드·API 표준 인코딩
CLAUDE.md     ← 컨벤션. 신규 입사자에게 필요한 모든 맥락

계층	성격	예시
`CLAUDE.md`	컨벤션	빌드/테스트 명령어, 폴더 구조, 네이밍 규칙
`.claude/skills/`	권고	접근성 체크리스트, API 에러 처리 표준
Hooks	강제	마이그레이션 파일 수정 차단, 프로덕션 설정 접근 차단

마치며

AI-Native SDLC는 기존에 우리가 업무하던 방식을 좀 더 AI 자동화하는 부분에 가까우며, 그 과정을 Github으로 옮겨오는 과정입니다.

grill-me와 같이 의사결정 과정을 코드베이스에 남기는 것처럼, 실제 현업에서 사용하는 기획부터 개발까지의 과정을 남기는 것입니다.

각 회사의 업무환경에 맞추어 동료들과 함께 설계해나가면 더 재미있는 개발이 될 것 같습니다 :)