Claude Code 팀의 INTENT.MD와 AI 네이티브 개발 방식

URL: https://www.youtube.com/watch?v=rGaSkBWjoHA
날짜: 2026-09-04
채널: Tech Bridge

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코드 작성 속도가 더 이상 소프트웨어 개발의 병목이 아니라면, 기획부터 운영까지의 전체 소프트웨어 개발 수명주기(SDLC)를 에이전트 중심으로 어떻게 다시 설계할 것인가?==

• 전통적인 SDLC의 기획·설계·구축·테스트·배포·유지보수 흐름에서 사람이 하던 문서화·인수인계·검토를 버전 관리되는 아티팩트와 에이전트로 연결한다.
• 아이디어를 의도 파일 intent.md에 담고, 승인된 의도를 spec.md, plan.md, 코드와 테스트, PR과 리뷰 기록으로 이어지는 아티팩트 체인(artifact chain)으로 만든다.
• 에이전트가 반복 작업·테스트·리뷰·운영 진단을 맡되, 정책·보안·출시처럼 판단이 필요한 게이트에는 사람을 남긴다.

코드가 빠르게 생성되면서 시간과 비용의 중심은 구현 단계에서 앞뒤 단계로 이동했다. 따라서 AI-native SDLC는 단순히 코드를 잘 생성하는 프롬프트가 아니라, 사람과 에이전트가 같은 파일을 읽고 다음 단계로 자동 handoff하며, 각 결정과 검증을 Git 기록으로 남기는 운영 시스템이다.

1. 코드가 병목이 된 시대의 SDLC가 끝나다

전통적 SDLC가 코드 작성 속도를 전제로 설계됐다면, 에이전트 시대에는 인간 속도로 남은 프로세스가 전체 흐름을 붙잡는다.

1.1. 사람이 수행하던 여섯 단계

1. 아이디어에서 운영까지의 순차 흐름

   1. 기획(Plan): 앱의 종류와 목표를 정하고 요구사항을 모은다.
   2. 설계(Design): 요구사항을 구조와 동작 설계로 바꾼다.
   3. 구축(Build): 설계를 코드로 구현한다.
   4. 테스트(Test): 구현이 요구사항을 만족하고 기존 동작을 깨뜨리지 않는지 확인한다.
   5. 배포(Deploy): 변경사항을 운영 환경에 넣는다.
   6. 유지보수(Maintain): 버그와 운영 이슈를 처리한 뒤 다음 기능·버그·릴리스의 기획으로 돌아간다.

2. 단계별 역할 분리와 인수인계

   1. 서로 다른 담당자가 각 단계를 맡고, 문서·티켓·승인으로 작업을 넘긴다.
   2. 역할이 바뀔 때마다 원래 의도와 맥락이 일부 손실되며, 다음 담당자는 앞선 대화를 처음부터 다시 이해해야 한다.

1.2. 구현이 빨라진 뒤 드러난 병목

1. 가장 오래 걸리고 비쌌던 구축 단계의 붕괴

   1. 에이전트가 구현을 맡으면서 전통적으로 가장 긴 시간이 들던 구축 구간이 크게 압축된다.
   2. 압축된 구간에서 회수한 시간만큼 기획·검토·테스트·배포처럼 여전히 사람 속도로 돌아가는 단계가 상대적으로 커진다.

2. 기존 통제 방식의 불일치

   1. 사람이 모든 코드를 작성하던 시절에는 사람이 한 줄씩 검토하는 방식이 합리적이었다.
   2. 에이전트가 대부분의 diff를 만든 뒤에도 같은 방식으로 검토하면 출력량을 감당하지 못한다.
   3. 보안팀과 정책 검토팀이 사람의 코드 생산량에 맞춰져 있으면 검토 대기열이 쌓이거나, 검토가 덜 된 코드가 배포되는 양자택일이 생긴다.
   4. 예외를 주간·월간 회의와 위원회에 계속 보내면 생산성 향상과 함께 거버넌스 비용도 커진다.

2. AI-native SDLC의 중심: 의도를 파일로 고정하기

intent.md는 아이디어를 원래 발화자의 언어로 보존하면서 사람과 기계가 모두 다음 작업을 시작할 수 있게 하는 버전 관리 아티팩트다.

2.1. 전통적 백로그와 의도 파일의 차이

1. 백로그로 멀어지는 원래 아이디어

   1. 전통적 방식에서는 사용자 입력, 사용자 스토리, 스토리 포인트, backlog refinement, 소유권 이전과 인수인계를 거쳐 아이디어가 엔지니어링에 도착한다.
   2. 제품 담당자가 회의를 열고 요구사항을 수집해 PRD(Product Requirements Document)를 만들며, 워크숍과 이해관계자 대화로 내용을 종합한다.
   3. 담당자가 바뀔 때마다 원래 아이디어에서 몇 단계 떨어진 해석이 전달될 수 있다.

2. 발화자의 생각을 직접 남기는 방식

   1. 문제·기능·제품의 창시자가 Claude와 아이디어를 함께 구상한다.
   2. 창시자는 형식적인 전문 문법을 몰라도 되며, 현재 할 수 없는 일, 영향을 받는 사람, 더 나은 상태, 범위 밖의 일을 자신의 말로 설명한다.
   3. Claude는 분석가가 물을 법한 범위·사용자·제약·성공 조건을 질문하며 대화를 구체화한다.
   4. 대화 결과는 무엇을 원하는지, 왜 필요한지, 어떤 제약 아래 있는지를 담은 짧은 프로토 스펙(proto-spec) intent.md로 저장된다.

2.2. intent.md를 만드는 주체와 저장 방식

1. 발신자(originator)의 범위

   1. 의도 파일을 만드는 사람은 팀의 도메인 전문가일 필요가 없다.
   2. 버그를 제보한 고객, 새 기능을 생각한 제품 관리자, 프로세스 개선을 기록하려는 개발자도 발신자가 될 수 있다.
   3. 반복되는 수집 방식은 팀이 만든 의도 포착 스킬로 표준화할 수 있다.

2. 검토와 확정

   1. Claude가 작성한 파일은 처음 의도를 제시한 사람이 다시 읽고 오해를 고친다.
   2. 제품 소유자는 백로그 관점에서 우선순위와 처리 여부를 검토한다.
   3. 제품 소유자는 의도를 승인하거나 닫는 결정을 남기고, 승인된 파일만 다음 단계로 보낸다.

3. 공유 홈과 버전 관리

   1. 하나의 제품은 저장소 안의 intent/ 폴더에 파일을 두는 방식으로 시작할 수 있다.
   2. 여러 저장소에 걸친 의도는 전용 저장소를 사용할 수 있고, 모노레포에서는 디렉터리로 관리할 수 있다.
   3. Git을 직접 사용하지 못하는 기여자도 Claude가 버전 관리 시스템에 대신 커밋하도록 연결할 수 있다.
   4. 작성자·시각·수정 이력은 Git 기록에 남아 아이디어가 무엇에서 출발해 어떻게 바뀌었는지 보여준다.

2.3. 백로그 정리와 spec.md로의 이동

1. 백로그 분류

   1. 아이디어는 Notion이나 Linear에 모아 제품 소유자가 정리할 수 있다.
   2. 에이전트가 백로그의 이슈를 분류해 프런트엔드(front-end), 소규모·대규모 작업, 기능(feature) 여부, 우선순위 수준 등의 태그를 붙일 수도 있다.
   3. 이 흐름은 자연어로 시작한 intent.md를 실행 가능한 spec.md 아티팩트로 이동시키는 출발점이 된다.

2. 승인 후 자동으로 생성되는 사양

   1. 의도가 커밋되거나 어떤 방식으로든 승인되면, 승인 이벤트를 훅(hook) 또는 자동화 프로세스의 트리거로 삼을 수 있다.
   2. Claude가 intent.md를 읽고 요구사항 및 설계 사양을 spec.md에 완전히 기록한다.
   3. 샘플 프롬프트는 첨부된 의도 문서를 읽고 요구사항·설계 스펙을 만들며, 사용 가능한 기술과 브랜드 가이드라인을 적용하라고 요구한다.
   4. 의도 파일에 담긴 생각을 구체적인 설계로 바꾸는 과정에는 별도의 정답 기술을 강제하지 않는다.

3. 조직별 맞춤화

   1. Cursor·Claude Code·Codex의 기본 플랜 모드를 그대로 사용할 수 있다.
   2. 팀의 작업 방식을 반영한 맞춤형 사양 생성 스킬을 직접 만들 수도 있다.
   3. 스타일 가이드·정책·스킬을 AGENTS.md 같은 파일에 기록하면 조직의 모범 사례를 사양 생성에 적용할 수 있다.
   4. 이 정책은 spec.md뿐 아니라 아티팩트 체인의 모든 파일에 일관되게 적용돼야 한다.

3. 아티팩트 체인과 빌드 모드

intent.md에서 시작한 결정은 spec.md와 plan.md를 거쳐 코드·테스트·PR로 이어지며, 각 단계의 결과물이 다음 단계의 입력이 된다.

3.1. 계획을 먼저 쓰는 빌드 시작

1. 사양과 의도를 에이전트에 전달

   1. 엔지니어는 승인된 intent.md와 spec.md를 Cursor의 플랜 모드, Claude Code 또는 유사한 에이전트 환경에 입력한다.
   2. 결과는 변경 파일, 작업 순서, 할 일, 위험 요소, 제약 조건, 성공을 증명할 방법을 담은 plan.md다.

2. 계획을 심문(interrogate)하기

   1. 계획이 어떤 변경을 일으키고 무엇을 깨뜨릴 수 있는지 질문한다.
   2. 가장 위험한 단계와 선택하지 않은 대안을 따져 계획을 보완한다.
   3. 계획을 처음 보는 엔지니어도 의도·사양 문서를 다시 참고하지 않고 구현할 수 있을 때까지 대화와 수정을 반복한다.
   4. 계획을 승인한 뒤에야 구현이 시작되며, 구현이 계획에서 벗어나면 같은 커밋에서 plan.md도 갱신한다.

3. 인수인계의 최소 단위가 문서가 되다

   1. 모든 SDLC 단계를 하나의 에이전트와 하나의 대화가 맡는 구조는 컨텍스트 창(context window)의 한계에 부딪힌다.
   2. 독립 에이전트와 하위 에이전트가 각자의 컨텍스트에서 일을 처리하고, 문서화된 계획과 의도가 대화의 연결부가 된다.
   3. 여러 담당자가 같은 문제의 서로 다른 부분을 해결해도 각 담당자는 이전 대화를 모른 채 문서에서 시작할 수 있다.

3.2. 병렬 에이전트와 작업 트리

1. 계획을 독립 작업으로 나누기

   1. 에이전트 하네스(agent harness)는 계획을 서로 독립적으로 수행할 수 있는 작업들로 나눈다.
   2. 독립적인 작업은 여러 에이전트와 하위 에이전트가 동시에 처리한다.
   3. 병렬 변경은 Git 작업 트리(worktree)에 격리해 파일 충돌을 줄인다.

2. 도구에 구애받지 않는 실행

   1. Cursor, Claude Code, Codex 중 무엇을 사용하든 프로젝트에 intent 폴더를 만들고 의도 파일을 두는 원칙은 같다.
   2. Git 작업 트리가 낯선 사람을 위해 별도 학습 자료가 필요할 수 있지만, 여러 에이전트가 여러 작업을 동시에 처리하려면 핵심적인 기반이 된다.

3.3. 자동 모드와 안전한 권한

1. 자동 모드의 조건

   1. Claude Code는 엔지니어가 계획을 승인하고 충분히 다듬은 뒤, 편집마다 확인을 받지 않고 변경을 적용하는 자동 모드(auto mode)를 사용할 수 있다.
   2. 자동 모드는 조직별 워크플로와 위험도에 따라 선택하며 모든 팀에 맞는 단일 해법은 아니다.
   3. 작은 영향 범위(blast radius), 촘촘한 사양, 이미 테스트된 코드, 성숙한 거버넌스가 있을수록 일상 업무의 자동 승인을 확대하기 쉽다.

2. 권한을 먼저 좁히기

   1. 잠금된 개발 환경과 미리 설정한 저장소 권한 안에서 에이전트를 시작하고, 필요할 때만 권한을 추가 승인한다.
   2. 에이전트가 접근할 수 있는 도구·웹 소스·다운로드 패키지의 정책을 정한다.
   3. Cursor와 Claude Code의 권한 설정으로 허용 범위를 고정하면 관리자가 매 순간 개입하지 않아도 에이전트가 더 빠르게 움직인다.

3. 자동화를 방해하는 권한과 자동화하는 권한의 균형

   1. 자동 모드를 원활하게 만들려면 허용된 행동과 차단해야 할 행동을 조직 정책으로 명시해야 한다.
   2. 권한을 무제한으로 주는 것이 목표가 아니라, 안전한 내부 루프는 자동화하고 위험한 경계는 막는 것이 목표다.

4. 테스트를 기다리는 단계에서 지속적 피드백 루프로

에이전트가 사람보다 먼저 가능한 많은 검증을 수행하면 QA 대기와 피드백 지연이 줄고, 사람은 결과와 위험을 판단하는 데 집중할 수 있다.

4.1. 전통적 테스트의 지연

1. 며칠을 기다리는 QA 게이트

   1. 개발자가 작업을 개발 환경으로 넘긴 뒤 테스터나 QA 담당자가 올 때까지 며칠을 기다릴 수 있다.
   2. QA가 피드백과 수정사항을 보내면 다시 개발과 검증을 반복하므로 전체 사이클이 길어진다.

2. AI-native 테스트의 선행 검증

   1. 인간 엔지니어 또는 QA가 접근하기 전에 에이전트가 가능한 많은 테스트를 실행한다.
   2. 빌드가 끝나면 처음부터 끝까지 linting과 검토를 수행하고, 개발 과정에서 문제가 생기지 않는지 확인하는 테스트를 작성한다.
   3. 테스트가 통과하는지 확인한 뒤 프로젝트를 lint하고 build해 오류가 없는지 검증한다.

4.2. 결정론적 검사와 에이전트 검사의 결합

1. 린팅(linting)의 역할

   1. 린팅은 코드나 문서를 훑으며 특정 기준의 존재·부재 또는 특정 구문과의 일치 여부를 코드로 검사한다.
   2. 파일 단위의 결과는 통과·실패라는 이진(yes/no) 판정으로 나온다.
   3. 이런 결정론적 검사와 테스트는 성공 기준을 기계가 반복해서 확인하게 하는 기초 안전망이다.

2. 브라우저와 화면 검증

   1. 고급 사용자는 Playwright, TestSprite, Cursor Browser 같은 도구와 에이전트를 이용해 소프트웨어를 실제로 테스트할 수 있다.
   2. 에이전트는 서버를 띄우고 소프트웨어를 실행한 뒤 스크린샷 또는 화면 녹화본을 제공할 수 있다.
   3. 화면 기반 증거가 충분히 엄격하게 수집되면 사람이 직접 확인하는 시간을 크게 줄일 수 있다.

3. 검증을 담당하는 별도 에이전트

   1. 한 에이전트가 만든 결과를 새 컨텍스트의 검증 에이전트가 확인하면, 처음 코드를 만든 에이전트의 가정에 덜 물든 판정을 얻을 수 있다.
   2. 에이전트 하네스는 반복 검증을 하위 에이전트로 분리해 메인 컨텍스트를 보존한다.

4.3. 스킬·모델 변경을 평가하는 지속적 통합

1. 변경 대상의 확대

   1. 코드만 평가하는 것이 아니라 에이전트 스킬과 모델 업그레이드에도 평가(evaluation)를 적용한다.
   2. 좋은 프롬프트나 새 모델이 실제 워크플로를 개선하는지, 기존 성능을 퇴보시키는지 지속적으로 확인한다.

2. 회귀 테스트 묶음

   1. 코드베이스에서 해결한 문제와 중요한 사례를 약 20개 정도 모아 예상 결과 세트를 만든다.
   2. 새 모델·새 기술·새 업무 방식이 들어올 때 같은 사례 묶음을 실행해 SDLC가 퇴보하지 않았는지 확인한다.
   3. 이 평가는 AI 도입이 실제로 업무 흐름에 얼마나 효과적인지 DORA 지표 및 프로젝트의 선행·후행 지표로 입증하는 데도 쓰인다.

5. 배포와 거버넌스: 에이전트가 움직이는 동안 정책을 실행하기

배포 단계의 목표는 사람 검토를 없애는 것이 아니라, 동일한 검토를 에이전트가 반복 수행하고 사람을 중요한 판단 게이트에 집중시키는 것이다.

5.1. 커밋·PR·비동기 리뷰

1. 브랜치와 풀 리퀘스트

   1. 에이전트는 개발 브랜치나 프로덕션 브랜치에 직접 쓰기보다 자체 브랜치 또는 작업 트리에서 변경한다.
   2. 변경이 끝나면 풀 리퀘스트(PR)를 만들고, 사람이 변경사항을 살펴본 뒤 메인 코드베이스에 추가해 달라고 요청한다.

2. 양방향 코드 리뷰

   1. Claude 코드 리뷰어는 별도 인스턴스로 PR을 검토한다.
   2. 정책·보안 프로토콜에 따라 리뷰하고, PR을 수용하지 않거나 AI-native SDLC 자체의 변경을 요구할 수 있다.
   3. 리뷰 결과는 PR에 남으며, 사람은 모든 줄의 문법보다 의도에 맞는 동작과 위험 수용 여부를 판단한다.

3. 비동기 처리

   1. PR이 생성될 때마다 리뷰 에이전트가 비동기적으로 실행되므로 사람이 리뷰어를 기다리는 시간이 줄어든다.
   2. 에이전트가 연 PR의 댓글을 다시 에이전트가 처리하고 수정사항을 올리는 루프도 만들 수 있다.

5.2. 훅과 결정론적 게이트

1. 훅(hook)의 기본 역할

   1. 구현이 끝나면 계획을 자동으로 업데이트한다.
   2. 특정 폴더의 편집을 차단하거나, 아직 승인하지 않은 NPM 패키지 업그레이드를 막는다.
   3. 사람이 매번 지시하지 않아도 저장소의 안전 규칙과 프로세스 상태를 최신으로 유지한다.

2. CI Preview와 다층 검사

   1. PR이 완료되면 보안 검사를 수행하는 별도 에이전트인 CI Preview가 실행된다.
   2. 린팅과 게이트 검사 같은 결정론적 검사로 정해진 기준을 확인한다.
   3. Cursor, Bugbot, Claude 보안 검토와 같은 에이전트가 오류를 찾아내는 비결정론적 검토도 결합한다.

3. 승인 권한의 분리

   1. 특정 권한이 없거나 특정 담당자의 승인이 없거나 출시일이 되지 않았으면 배포가 중단되도록 장치를 둔다.
   2. 에이전트가 코드를 작성해도 최종 출시와 고위험 변경의 책임은 사람에게 남긴다.
   3. 훅은 모든 사람에게 같은 조건을 적용하고, 허용·차단 결과와 시각을 기록해 감사 흔적을 만든다.

6. 유지보수에서 운영 루프를 닫기

유지보수는 사람이 티켓을 발견하고 다시 일을 시작하는 사후 대응 단계에서, 이벤트가 사람 없이 Claude를 호출하고 새로운 intent.md로 흐름에 재진입하는 단계로 바뀐다.

6.1. 전통적 유지보수의 사각지대

1. 사람을 기다리는 운영 이슈

   1. 점심을 먹으러 나간 시간, 당직 시간, 새벽 3시에 서버 다운 알림을 받은 순간처럼 사람이 자리에 없을 때 문제가 발생할 수 있다.
   2. 티켓이 이미 백로그에 너무 많이 쌓여 완전히 무시되거나, 다른 장애가 터져 후속 조치가 코드베이스에 반영되지 않을 수 있다.

2. AI-native 운영 트리거

   1. 보안 침해, 새 티켓, Slack 채널 메시지, 일정 또는 모니터링 이벤트가 트리거가 된다.
   2. 사람의 컴퓨터 접속을 기다리지 않고 Claude가 비동기적으로 문제를 진단하고 조치를 취한다.

6.2. 운영 이벤트를 새로운 의도로 되돌리기

1. 진단 결과의 아티팩트화

   1. Claude는 발견한 로그, 전송된 티켓 또는 메시지를 근거로 자체 intent.md 파일을 생성한다.
   2. 파일은 어떤 문제가 일어났는지, 어떤 지표가 깨졌는지, 영향을 받는 시스템과 제안된 대응을 다시 SDLC의 시작점에 기록한다.

2. 통제 밴드와 선제 조치

   1. 팀은 지키고 싶은 특정 지표를 미리 정할 수 있다.
   2. 테스트 중 페이지 오류가 발생하거나 API 사용량 제한이 급격히 증가하면 에이전트가 이를 진단하고, 진단 의도와 일련의 제안을 생성하도록 트리거할 수 있다.
   3. 진단·제안·후속 작업은 사용자가 컴퓨터에 접속하기 전에도 진행될 수 있다.

3. 유지보수 루프의 재진입

   1. 운영에서 발견한 intent.md는 다시 요구사항·설계·계획·구축·테스트·리뷰·배포 단계를 통과한다.
   2. 한 번의 장애 대응이 일회성 티켓으로 끝나지 않고, 재발 방지 코드와 평가 사례로 이어지는 학습 루프가 된다.

7. 전체 흐름과 조직별 도입 방식

AI-native SDLC는 한 번에 기존 프로세스를 폐기하는 교체 작업이 아니라, 사람의 판단이 필요한 지점을 보존하면서 반복 가능한 연결부부터 자동화하는 점진적 변화다.

7.1. 한 사이클에 남는 사람과 에이전트의 역할

1. 연결된 전체 흐름

   1. 계획과 의도를 intent.md로 정리한다.
   2. 승인된 의도를 spec.md로 구체화한다.
   3. 엔지니어가 spec.md와 intent.md를 바탕으로 plan.md를 심문하고 승인한다.
   4. 에이전트와 하위 에이전트가 작업 트리에서 코드를 병렬 구현한다.
   5. 테스트·린팅·브라우저 검증·화면 증거와 지속적 평가를 통과시킨다.
   6. PR, 보안 검토, 정책 훅, CI 게이트를 거쳐 배포한다.
   7. 운영 이벤트와 지표 위반이 새로운 intent.md가 되어 다음 사이클을 연다.

2. 인간의 관심이 이동하는 지점

   1. 중요도가 낮은 단계는 필요한 만큼의 사람 또는 에이전트로 처리하거나 에이전트만으로 구성된 시스템을 사용할 수 있다.
   2. 사람은 모든 줄을 직접 생산·검사하는 역할에서 의도, 위험, 정책 예외, 출시 승인과 같은 판단을 맡는 역할로 이동한다.
   3. 자동화 범위는 워크플로·팀·규제 수준·보안 요구사항에 맞춰 정해야 하며, 자동 모드를 무조건 적용할 이유는 없다.

7.2. 기존 방법과 함께 도입하기

1. 기존 프레임워크를 버리지 않는 선택

   1. Superpowers, BMAD 또는 팀이 직접 만든 유사한 방법론을 이미 사용하고 있다면 처음부터 완전히 폐기할 필요가 없다.
   2. 핵심은 특정 도구 이름이 아니라 의도·사양·계획·검증·권한·감사 기록을 연결하는 원칙이다.

2. 자동화의 스펙트럼

   1. 단순 반복문(loops)부터 시작해 그래프 공학(graph engineering), 완전 자동화된 반복문, 대규모 오케스트레이션 시스템으로 확장할 수 있다.
   2. 범위는 작은 팀의 파일 기반 워크플로부터 조직 전체의 에이전트 운영, 더 나아가 문명 공학(civilization engineering)까지 다양하게 상상할 수 있다.

3. 현실적인 시작점

   1. 현재 조직의 SDLC에서 사람이 반복적으로 기다리는 단계를 하나 고른다.
   2. 그 단계의 입력과 출력에 이름을 붙이고, 사람이 읽고 에이전트가 처리할 수 있는 Markdown 아티팩트로 남긴다.
   3. 자동화가 안전하게 작동하는지 결정론적 검사와 사람이 필요한 승인으로 검증한다.
   4. 실제 효과를 선행·후행 지표와 DORA 지표로 측정하고, 스킬·모델·정책 변경 때 회귀 평가를 실행한다.

주요 발언 모음

“코드는 더 이상 병목이 아니다. 병목은 당신의 프로세스다.”

“에이전트가 빌드 단계에만 관여하는 것을 넘어 전체 소프트웨어 개발 수명주기에 활용된다.”

“의도 파일은 누구든 만들 수 있다. 개발자일 수도 있고, 버그를 제보한 고객일 수도 있다.”

“모든 사람에게 맞는 만능 해결책은 없다.”

핵심 데이터 & 수치

• 2배 빠른 구현: 에이전트로 구축 단계를 크게 줄인 뒤, 나머지 SDLC 단계도 어떻게 개선할지 질문한다.
• 약 20개 회귀 사례: 코드베이스에서 해결한 문제를 모아 새 모델·기술·업무 방식이 SDLC를 퇴보시키지 않는지 평가한다.
• 50가지 계획 작성법: 계획 형식은 여러 가지일 수 있지만, 변경 파일·작업 순서·위험·제약·증거와 성공 기준을 포함해야 한다.
• 며칠의 QA 대기: 전통적 흐름에서 개발 완료 후 테스터나 QA 담당자를 기다리는 시간이 피드백 지연의 사례로 제시된다.
• 새벽 3시 장애: 사람이 자리에 없을 때 서버 다운 알림이 발생해도 운영 에이전트가 먼저 진단할 수 있는 유지보수 시나리오다.
• DORA 지표: 선행·후행 지표와 함께 AI가 조직 워크플로에 실제로 효과적인지 확인하는 측정 수단으로 사용한다.

결론 및 시사점

1. intent.md는 단순한 메모가 아니라 발화자의 생각과 제약을 보존하는 AI-native SDLC의 시작점이다.
2. intent.md → spec.md → plan.md → 코드·테스트 → PR·리뷰 → 운영 진단이라는 연결된 아티팩트 체인이 사람의 인수인계 손실을 줄인다.
3. 구현을 자동화할수록 계획·검증·보안·배포·거버넌스를 코드와 파일로 명시해야 하며, 자연어 지침만으로는 충분하지 않다.
4. 스킬은 정책을 권고하는 계층이고, 훅·린팅·테스트·CI 게이트는 반드시 지켜야 하는 정책을 결정론적으로 실행하는 계층이다.
5. 자동 모드는 권한을 좁힌 환경, 작은 영향 범위, 촘촘한 테스트와 평가, 명확한 승인 게이트가 갖춰진 일상 업무부터 확대해야 한다.
6. 사람의 역할은 사라지는 것이 아니라 코드 생산자에서 의도 형성자·위험 판단자·품질 검증자·거버넌스 책임자로 이동한다.
7. 가장 실용적인 도입은 기존 도구를 전부 바꾸는 일이 아니라, 반복되는 한 단계를 파일 기반 아티팩트와 자동 훅으로 연결하고 지표로 효과를 확인하는 일이다.