PK-PDCA BRIDGE · AI 활용 가이드

AI 네이티브 개발 6단계 (AI-Native SDLC)
PK-PDCA로 읽기

Anthropic이 2026년 8월에 낸 「AI 네이티브 SDLC 플레이북」은 소프트웨어 개발의 여섯 단계를 AI 기준으로 다시 짠 지침입니다. 이 가이드는 그 여섯 단계를 우리 PK-PDCA 순서로 옮겨 읽고, 개발자가 아닌 사람도 바로 쓸 수 있는 부분(의도 다섯 칸·승인 게이트·검증 습관)을 골라 설명합니다. 기준 시점 2026-09-06.

이 가이드의 한 줄

코드는 병목이 아니다
병목은 계획·검토·배포로 옮겨 갔다

※ 플레이북의 중심 주장입니다. AI가 코드를 빨리 쓰게 되자, 시간이 걸리는 곳은 "무엇을 만들지 정하는 일"과 "만든 것을 확인하고 내보내는 일"이 되었습니다. 그래서 단계마다 사람이 읽고 승인하는 문서 파일 하나를 남기게 했습니다.

1. 한 줄 요약 — 단계마다 파일 하나, 사람은 게이트에

여섯 단계는 계획 → 설계 → 구축 → 테스트 → 배포 → 유지입니다. 각 단계는 버전 관리되는 마크다운 파일을 남기고, 다음 단계는 그 파일을 읽으며 시작합니다. 그래서 커밋 기록이 곧 "누가 요청했고, AI가 무엇을 만들었고, 누가 승인했는지"의 감사 기록이 됩니다. 판단이 필요한 곳마다 사람이 승인해야 넘어갑니다.

파일이 단계를 잇는다

intent.md → spec.md → plan.md → 코드·테스트 → PR → 모니터링이 다시 intent.md로

PK-PDCA: P 문제 정의 → 설계 → P 계획 → D 실행 → C 검증 → 승인 → A 자산화. 순서가 같습니다.

사람은 판단만 한다

의도 승인, 설계 승인, 계획 승인, 코드 소유자 승인, 배포 승인 — 다섯 게이트

PK-PDCA: 우리 규칙 "AI가 최종 결정하지 않는 것"(실제 배포·비용·방향)과 같은 자리입니다.

반복되면 지침으로

같은 실수 두 번 → 지침 파일(CLAUDE.md) 한 줄, 검토에서 반복되는 발견 → 검토 규칙 파일

PK-PDCA: A 자산화 "원본은 문서에, 사본은 도구에". 지침·스킬·훅이 버전 관리되는 자산입니다.

2. 여섯 단계 한눈표

단계	남기는 파일	누가 쓰나	사람의 승인 게이트	PK-PDCA
1 계획 (Plan)	intent.md — 의도 다섯 칸	요청한 사람(AI와 대화하며)	제품 책임자가 읽고 수락	P 문제 정의
2 설계 (Design)	spec.md — 요구사항·설계, 어긋나는 곳 표시	AI(조직 규칙·스킬을 읽고)	제품 책임자, 우려 항목은 규정 담당자	K 지식 · 설계
3 구축 (Build)	plan.md — 파일·순서·위험·증거 기준, 그 뒤 코드	AI(계획 모드) → 엔지니어가 심문·승인 → AI 구현	엔지니어가 계획 승인. 위험한 변경은 기술 리드	P 계획 → D 실행
4 테스트 (Test)	테스트 결과·빌드 로그·화면 비교 — 증거	AI가 스스로 돌리고 통과까지 반복	자동 루프. 지침·스킬 변경은 평가 묶음(evals) 통과가 조건	C 검증
5 배포 (Deploy)	PR + 검토 결과, 배포 승인	AI가 PR을 열고 검토 의견 반영	자동 검토(버그·보안·계획 일치) → 코드 소유자 → 배포 관리자	승인 게이트
6 유지 (Maintain)	이상 감지 → 새 intent.md, 사건 기록, 수정 PR	통계 규칙이 감지, AI는 그 뒤 진단·제안	서비스 담당자 분류 → PR 검토 게이트	A 자산화 → 다시 P

숫자로 재는 법

플레이북은 지표를 두 층으로 둡니다. 선행 지표는 의도 문서를 쓰는 데 걸린 시간과 첫 검토까지 걸린 시간, 후행 지표는 출시 전에 잡은 결함 수와 같은 사고의 재발 감소입니다.

우리 KPI(교수자 준비 시간·학습자 자립률)와 같은 구조입니다. 앞 숫자로 흐름을, 뒤 숫자로 품질을 봅니다.

3. intent 다섯 칸 — 모든 일의 첫 문서

의도 문서는 개발자가 아니어도 쓸 수 있게 만들어졌습니다. 채팅에서 AI와 이야기하며 다섯 칸을 채우고, 그대로 저장소에 올리면 됩니다. 칸은 다섯 개뿐입니다.

문제
지금 무엇이 불편하고, 누구에게, 왜 문제인가. 해결책이 아니라 상황을 씁니다.
제안 결과
잘 되면 어떤 모습인가. 숫자 하나를 넣으면 뒤 단계의 완료 기준이 됩니다.
영향받는 사용자와 시스템
누가 쓰고, 어느 화면·데이터·규칙이 바뀌는가. 빠뜨리면 설계에서 우려로 튀어나옵니다.
제약
지켜야 할 것. 비용·개인정보·로그인 없음·기존 방식 유지 같은 조건.
미해결 질문
아직 모르는 것을 숨기지 않고 적습니다. 설계 단계가 이 질문에 답하거나 사람에게 되묻습니다.

※ 우리 문제 정의 7문항과 겹칩니다. 7문항은 학습자용으로 잘게 나눈 것이고, 다섯 칸은 팀에 넘기는 문서용입니다. 이 플랫폼의 계획서(Plan)도 이 다섯 칸으로 시작합니다(2026-09-06부터).

🔎 더 자세히 알아보기 (로그인 불필요)

🤖 구글 AI 검색 🔍 네이버 AI 검색

새 창이 안 열리면 「질문 복사」를 눌러 쓰시는 AI에 붙여넣으세요.

4. 단계별 상세 — 무엇을 하고, 무엇이 끝의 표시인가

1 계획 — 의도를 한 번만, 요청한 사람의 말로.
끝의 표시: 다섯 칸이 채워진 intent.md가 저장소에 올라가고 제품 책임자가 수락했다. 템플릿은 조직에서 하나로 통일한다.
2 설계 — AI가 규칙을 읽고 설계를 쓴다.
끝의 표시: spec.md에 요구사항·설계와 함께 "조직 규칙(브랜드·보안·개인정보·UX)과 어긋날 수 있는 곳"이 표시돼 있고, 사람이 그 항목을 결정했다. 화면이 있는 일은 디자인 도구에서 시안을 먼저 만들어 넘긴다.
3 구축 — 계획을 먼저 승인받고, 그다음 코드.
끝의 표시: AI가 계획 모드에서 질문한 뒤 파일·순서·위험·증거 기준을 적은 plan.md를 냈고, 엔지니어가 심문해 승인했다. 구현 중 계획과 달라지면 같은 커밋에서 plan.md도 고친다. 지침 파일(CLAUDE.md)은 한 쪽 안에 규칙·명령·구조·흔한 실수를 담고, 같은 실수가 두 번 나오면 한 줄을 더한다.
4 테스트 — AI가 스스로 확인하고 증거를 남긴다.
끝의 표시: 테스트·빌드가 한 명령으로 돌고 통과 기준이 숫자로 적혀 있다. 버그는 실패하는 테스트를 먼저 쓰고, AI는 테스트 파일을 고치지 못하게 막는다(훅). 화면은 스크린샷이 시안과 맞을 때까지 반복. 지침·스킬·훅을 바꿀 때는 실제 과제 20~50개짜리 평가 묶음(evals)이 통과해야 한다.
5 배포 — 검토는 양방향, 사람은 한 단계 위를 본다.
끝의 표시: AI가 검토 규칙 파일(REVIEW.md)대로 세 번(버그·보안·계획 일치) 검토해 [중요]/[사소]를 붙였고, 코드 소유자가 승인했고, 운영 배포는 훅이 배포 관리자 승인을 요구했다. 사람의 눈은 "계획이 의도한 대로 됐는가"로 올라간다. 배포·상태·되돌리기는 MCP 도구로 만들고, 개발·스테이징·운영마다 자율 범위를 다르게 둔다.
6 유지 — 감지는 통계로, 판단은 사람이.
끝의 표시: 지표(테스트 실패율·배포 뒤 오류·PR 처리 시간)를 평균·표준편차 규칙으로 감시하고, 임계를 넘을 때만 AI를 부른다(2σ 진단, 3σ 제안). AI의 진단은 새 intent.md가 되어 분류 대기열로 가고, 수정은 반드시 PR 검토 게이트를 지난다. 고친 사고 종류는 평가 묶음에 추가해 재발을 막는다.

피해야 할 것(플레이북이 경고하는 것) — 계획 단계 건너뛰기 · 낡은 지침 파일 · 검토 규칙 없는 검토 · AI에게 운영 배포 권한을 상시로 주는 것 · 감지를 모델에 맡기는 것 · 되돌리기를 연습하지 않는 것 · 이유 없이 경보를 무시하는 것.

5. 파일 네 개, 누가 쓰고 누가 승인하나

플레이북은 파일 이름과 다섯 칸까지 제안했고, 그 안의 흐름(누가 초안을 쓰고 누가 승인하나)은 도입하는 팀이 채웁니다. 아래는 국내 개발자의 도입 정리 영상(2026-09-05)이 그린 표를 우리 말로 옮긴 것입니다. 원칙은 한 줄, 초안은 AI, 중요한 결정은 사람.

파일	답하는 질문	초안	승인·책임	비고
CLAUDE.md (AGENTS.md)	AI가 지켜야 할 규칙은?	—	팀	이미 있던 파일. 규칙·맥락. 바꾸면 고정 점검을 다시 돌린다
intent.md	왜 만드나? 모든 개발의 시작점	AI(아이디어 있는 누구나 요청)	제품 책임자	기획서·스프린트 문서를 대체. 다섯 칸 + 성공 기준
spec.md	무엇을, 어떤 요구사항과 설계로?	AI	제품 책임자	회사 정책이 설계에 들어가므로 제품을 아는 사람이 승인
plan.md	어떤 코드를 어떤 순서로, 무엇으로 검증?	AI	개발자	코드 직전. 코드베이스 맥락이 필요해 개발자가 확정

폴더 하나에 한 벌
저장소에 intents/<기능 이름>/ 폴더를 만들고 그 안에 intent·spec·plan 세 파일만 둡니다. 설계가 둘 필요해지면 의도를 둘로 쪼갭니다. 큰 기능은 작은 의도 여러 개로 나누는 편이 빠릅니다.
승인은 합치기(머지)로
영상의 흐름은 슬랙에서 AI를 부름 → intent 초안 PR → 제품 책임자가 합치면 승인 → 자동으로 spec 초안 PR → 다시 합치면 승인 → 개발자가 plan 확정 → 기능 브랜치. 사람 승인은 두 번뿐이고, 진실의 원천은 저장소 하나입니다.
생략해도 되는 때
오타·명백한 버그처럼 할 일이 분명한 수정은 의도 없이 바로 고칩니다. 혼자 일한다면 큰 기능을 시작할 때만 의도를 남겨도 됩니다. 한 번에 다 바꾸지 말고 필요한 것부터 한 단계씩.
우리 플랫폼의 적용
이 저장소는 docs/intents/<일감>/에 세 파일을 두고, 머리에 「작성(초안): 에이전트 · 승인: 박사님 날짜」를 적습니다. intent·spec은 박사님이, plan은 만드는 에이전트가 확정합니다(작업 규칙 3-9, 2026-09-06).

6. 개발자가 아닌 사람에게 이 지침이 뜻하는 것

플레이북의 말	우리 일에서는
intent.md 다섯 칸	강의 기획·사업계획서·플랫폼 개선 요청을 다섯 칸으로 먼저 쓴다. 이 플랫폼의 계획서 머리가 이 칸이다.
설계에서 "어긋나는 곳" 표시	AI에게 초안을 시킬 때 "우리 규칙과 어긋날 수 있는 곳을 [우려]로 표시해 달라"고 한 줄 덧붙인다.
계획 승인 뒤 구현	바이브 코딩에서 "먼저 계획만 보여 달라, 코드는 내가 승인한 뒤에"라고 말한다. 방향 수정이 문서 한 줄로 끝난다.
자기 검증과 증거	결과물을 받을 때 "무엇으로 확인했는지 증거(테스트·스크린샷·출처)를 붙여 달라"고 요구한다. 검증(C) 습관이다.
두 번 반복되면 지침에	AI가 같은 실수를 두 번 하면 맞춤 설정·프로젝트 지침·스킬에 한 줄을 더한다. 가이드 「AI 자산화 방법」의 지침 8줄이 그 자리다.
사람은 게이트에 선다	배포·비용·이름·방향·외부 발송은 AI가 결정하지 않는다. 잘하는 AI보다 멈출 곳을 아는 AI.

7. 판정 퀴즈 — 어느 단계를 건너뛰었나

8. 프롬프트 5종 — 의도 · 설계 · 계획 · 검토 · 쪼개기

대괄호 [ ]는 슬롯 이름, 중괄호 { } 안만 내 상황으로 바꾸면 됩니다. 챗GPT·클로드·제미나이 어디서나 같은 원리로 동작합니다. 코드를 모르는 분도 가·나는 그대로 쓸 수 있습니다.

가. 의도 문서(intent) 다섯 칸 만들기

[R·역할] 당신은 {내 업종}의 일을 아는 기획 코치입니다. 아래 다섯 칸을 채워 "의도 문서(intent)"를 만들어 주세요. 코드나 해결책은 아직 쓰지 마세요.

# Intent: {기능 또는 문제 이름}
작성자: {이름} · 날짜: {YYYY-MM-DD} · 상태: 초안

1. 문제 — 지금 무엇이 불편하고 누구에게 왜 문제인가: {예: 강의 뒤 학습자가 프롬프트를 다시 찾지 못한다}
2. 제안 결과 — 잘 되면 어떤 모습인가(숫자 하나 포함): {예: 복사한 프롬프트가 보관함에 쌓여 다음 주에 80%가 다시 쓴다}
3. 영향받는 사용자와 시스템: {예: 학습자·강사, 브릿지 보관함 화면}
4. 제약 — 지켜야 할 것: {예: 로그인 없음, 무료, 개인정보 저장 금지}
5. 미해결 질문 — 아직 모르는 것: {예: 기기를 바꾸면 보관함이 사라져도 되는가}

[형식] 각 칸 3줄 이내. 내가 쓰지 않은 사실은 지어내지 말고 [확인 필요]로 표시.
[마지막] "이 의도가 맞습니까? 고칠 칸이 있으면 번호로 말해 주세요"라고 물어 주세요.

나. 설계 문서(spec) — 어긋나는 곳까지

[R·역할] 당신은 요구사항 문서를 쓰는 설계자입니다. 아래 의도 문서(intent)를 읽고 설계 문서(spec)를 만들어 주세요.

[입력] 의도 문서:
{여기에 intent 다섯 칸을 붙여 넣기}

[규칙] 우리가 지켜야 할 기준: {예: 모바일 우선, 글자 크기 3단계, 개인정보 저장 금지, 유료 기능은 안내만}

[출력]
1. 해야 할 일 목록(사용자가 무엇을 할 수 있게 되는가) — 번호 매김
2. 하지 않을 일(범위 밖)
3. 화면·데이터·규칙 가운데 바뀌는 것
4. 위 기준과 어긋날 수 있는 곳 — [우려] 표시와 이유, 사람이 결정할 질문
5. 완료 판정 기준 — 숫자로

[마지막] 의도 문서의 다섯 칸과 이 설계가 하나씩 이어지는지 표로 보여 주세요.

다. 계획 문서(plan) — 코드보다 먼저

[R·역할] 당신은 구현 계획을 세우는 개발 리드입니다. 아직 코드를 쓰지 말고, 아래 설계 문서(spec)로 계획 문서(plan)만 만들어 주세요.

[입력] 설계 문서:
{여기에 spec 붙여 넣기}

[먼저] 계획을 쓰기 전에 나에게 질문 3개까지 하세요(모르는 것·결정이 필요한 것). 내가 답하면 계획을 씁니다.

[출력]
1. 만들거나 고칠 파일 목록과 순서
2. 단계마다 "끝났다는 증거"(테스트 통과, 화면 200, 스크린샷 등)
3. 위험과 되돌리는 방법
4. 사람이 승인해야 넘어가는 지점 — [승인] 표시

[규칙] 계획과 다르게 진행하게 되면 코드와 같은 커밋에서 이 계획 문서도 함께 고칩니다.

라. 세 번 검토(REVIEW) — 만든 사람이 아닌 눈으로

[R·역할] 당신은 코드 검토자입니다. 아래 변경을 세 번에 나눠 검토하고, 만든 사람이 아닌 다른 눈으로 봐 주세요.

[입력] 변경 내용(diff 또는 파일):
{붙여 넣기}
계획 문서(plan): {붙여 넣기 또는 링크}

[검토 3회]
1회 — 버그·논리 오류: 잘못 동작할 입력과 상태를 구체적으로
2회 — 보안·개인정보: 비밀값·개인정보·외부 전송·권한
3회 — 계획 일치: 설계·계획 문서와 다른 곳, 빠진 완료 기준

[출력] 발견마다 [중요] 또는 [사소] 표시, 파일과 위치, 왜 문제인지 한 문장, 고치는 방법 한 문장.
[규칙] 확실하지 않으면 [확인 필요]. 칭찬은 생략하고 발견만.

마. 의도 하나로 갈지, 쪼갤지 판정

[R·역할] 당신은 개발 흐름을 설계하는 리드입니다. 아래 일감을 읽고 "의도(intent) 하나로 갈지, 둘 이상으로 쪼갤지"를 판정해 주세요.
[목표] 판정 한 줄 → 이유 세 가지 → 쪼갠다면 각 의도의 이름과 한 줄 문제 → 의도 없이 바로 고쳐도 되는 작은 수정이면 그렇게 말해 주세요.
[기준] 폴더 하나에 의도·설계·계획 한 벌씩. 설계(spec)가 둘 필요하면 의도를 쪼갠다. 오타·명백한 버그처럼 할 일이 분명하면 의도를 생략한다.
[일감] {하려는 일: 예 — 홈페이지에 지식 위키 메뉴를 넣고, 검색에도 나오게 하고, 세션 카드에 링크도 붙이기}
[형식] 표(의도 이름 · 문제 한 줄 · 승인자 · 예상 크기 상/중/하).

9. 출처와 기준 시점

1층 원문
Anthropic, 「The AI-Native SDLC Playbook」(claude.com 블로그, 2026-08-21). 여섯 단계·파일 체인·게이트·지표의 출처.
1층 공식 강좌
Claude Academy, 「The AI-Native SDLC Playbook」 코스(14개 레슨, 대상은 개발팀·제품 책임자·비기술 기여자). intent.md 템플릿 필드의 출처.
2층 검증된 이론
슈하트·데밍의 PDCA 사이클과 관리도(평균·표준편차 규칙). 플레이북 6단계의 감지 규칙이 이 전통을 따른다. 데밍 『Out of the Crisis』(MIT Press 1986, 권위 채점 25/25).
3층 현장 사례
국내 개발자 유튜브 채널 「Anthropic 제안한 코드 짜기 전에 무조건 쓰라는 파일 | AI 네이티브 SDLC 도입 정리」(2026-09-05, 36분) — 파일 네 개와 승인자 표, intents 폴더 구조(폴더 하나에 intent·spec·plan 한 벌), 슬랙→intent PR→CI spec→plan→기능 PR 흐름. 발표자 스스로 "Anthropic은 intent 폴더까지 제안했고 그 안의 흐름은 제가 채운 것"이라고 구분했다. 스크립트 전문으로 확인(2026-09-06), 사실 관계는 1층 원문과 대조했다.

※ 기능 이름(Claude Design·Claude Security·Claude Tag 등)은 2026-09 시점 베타·정식이 섞여 있어 공식 안내로 확인하세요. 이 가이드는 원문 문장을 옮기지 않고 구조와 원리를 다시 쓴 것입니다.

🔎 더 자세히 알아보기 (로그인 불필요)

🤖 구글 AI 검색 🔍 네이버 AI 검색

새 창이 안 열리면 「질문 복사」를 눌러 쓰시는 AI에 붙여넣으세요.