코드가 병목이 아니게 된 뒤의 소프트웨어 개발 수명주기, Anthropic의 AI 네이티브 SDLC 플레이북

TL;DR

• 플레이북의 출발 진단은 구현 속도가 급격히 빨라졌는데 승인, 리뷰, 인수인계 같은 주변 프로세스는 그대로라서 병목이 빌드의 앞뒤 단계로 옮겨 갔다는 것이다. 기존 통제는 사람이 코드를 썼다는 가정 위에 있어 에이전트 속도를 따라가지 못한다.
• 해법은 선형 흐름을 루프로 바꾸는 것이다. 각 단계가 다음 단계가 읽을 산출물(intent.md, spec.md, plan.md, diff, 리뷰 결과, 인시던트 기록)을 버전 관리에 커밋하고, 그 커밋이 감사 기록이 된다.
• 통제의 무게는 조언에서 강제로 옮겨 간다. 스킬은 권고이고 훅이 결정적 차단을 맡으며, 에이전트는 운영 게이트까지만 행동하고 그 너머는 사람이 승인한다.
• 사람의 주의는 라인별 리뷰에서 의도와 위험 판단, 그리고 게이트에서 에이전트가 표시한 항목 검토로 옮겨 간다.
• 이 글은 Claude를 파는 회사의 가이드이며, 제시된 효과 지표는 측정 방법일 뿐 달성 결과가 아니다. 일부 기능은 공개 베타다.

병목이 빌드의 양옆으로 옮겨 갔다

플레이북은 코드가 더는 병목이 아니라는 진단으로 시작한다. 조직은 1년 전에는 상상할 수 없던 속도로 AI를 통해 코드를 쓰기 시작했지만 그 둘레의 프로세스는 같은 속도로 바뀌지 않았다. 소프트웨어 수명주기는 계획, 설계, 구현, 테스트, 배포, 유지보수의 여섯 단계이고 전통적으로 각 단계는 다른 역할이 맡아 문서와 티켓과 승인으로 일을 넘긴다. 이 구조는 코드를 쓰는 일이 가장 오래 걸리고 비싼 시대에 효율을 극대화하도록 설계되었다는 설명이다. PRD, 추정 의식, 보안 검토가 모두 몇 주에서 몇 분기 걸리는 개발 동안 정렬을 강제하려고 존재했다.

이 전제가 깨지면 세 가지가 사실이 된다. 병목이 빌드 앞뒤의 계획, 리뷰와 테스트, 배포로 이동한다. 에이전트가 변경분 대부분을 쓰는 상황에서는 모든 줄을 손으로 검토하는 통제가 감당할 수 없게 된다. 예외가 주간이나 월간 위원회로 올라가므로 거버넌스 비용이 커진다. 글은 보안팀이 사람의 산출량에 맞춰 편성되어 있어서 에이전트가 코드를 늘리면 검토 대기열이 쌓이거나 검토가 덜 된 코드가 배포된다는 예를 든다. 규제 산업은 둘 다 받아들일 수 없으므로 보안과 정책 점검이 에이전트의 속도를 따라와야 한다.

선형 흐름을 루프로, 커밋된 산출물이 실

AI 네이티브 SDLC는 옛 통제 목표를 유지하되 집행 방식을 바꾼 프로세스로 정의된다. 선형 흐름이 루프가 되고 모든 지점에 AI가 들어가며 단계 간 인수인계와 다음 플레이 촉발이 자동화된다. 핵심 아이디어는 모든 단계가 다음 단계가 읽을 산출물 하나를 버전 관리에 커밋하고 끝난다는 것이다. 초기 단계의 산출물은 마크다운 파일이다. 제품 담당자와 에이전트가 같은 파일을 읽고 행동할 수 있기 때문이다. 구현 이후에는 산출물이 코드와 그 기록이다. 커밋의 연쇄가 곧 누가 무엇을 요청했고 에이전트가 무엇을 만들었고 누가 승인했는지의 감사 추적이 된다.

승인된 intent.md가 요구사항과 설계 단계를 촉발하고 승인된 spec.md가 계획 모드를, 병합된 PR이 파이프라인을, 운영에서 통제 대역을 넘은 사건이 다음 intent.md를 쓰게 한다. 처음에는 각 단계를 손으로 프롬프트하다가 최종적으로 각 승인된 산출물이 다음 게이트를 발동하는 루프를 목표로 한다. 글은 사람이 모든 판단이 필요한 결정에 책임을 지며 사람의 주의가 검토해야 할 산출물을 따라 이동한다고 못 박는다.

계획과 설계, 의도 한 장으로 시작한다

계획 단계에서는 아이디어를 낸 사람이 자기 말로 Claude와 구상해 intent.md라는 초기 명세를 만들고 제품 담당자가 검토 후 커밋한다. 기존에는 백로그 항목, 사용자 스토리, 스토리 포인트, 정제 회의를 거치며 각 인수인계마다 원래 의도에서 멀어졌다. 템플릿은 스킬로 코드화하고 git 이력이 저자와 시각을 남긴다. 선행 조건은 없고 비엔지니어가 쓸 수 있는 Claude 접근과 버전 관리 저장소가 필요하다. 글은 깃에 익숙하지 않은 기여자를 위해 커넥터로 Claude가 대신 커밋하게 하는 구성을 제안한다. 예시는 콜센터로 들어오는 청구 상태 문의를 포털 셀프서비스로 줄이는 작업이다.

설계 단계에서는 요구사항과 설계가 하나의 프롬프트 세션으로 합쳐진다. Claude가 승인된 intent.md와 조직의 브랜드, 보안, 컴플라이언스, UX 정책을 담은 스킬을 입력으로 받아 spec.md를 쓰고 우려 지점을 표시한다. 제품 담당자는 스펙을 쓰지 않고 검토하며 표시된 우려는 정책 담당자와 해소한 뒤에야 엔지니어링에 넘긴다. 정책이 몇 주 뒤의 리뷰에서 발견되는 대신 스펙이 쓰이는 동안 적용된다는 점이 이득이다. 측정 지표는 intent와 spec 커밋 사이의 경과 시간, 그리고 빌드 시작 뒤 스펙이 다시 바뀐 횟수다.

빌드, 계획 모드와 CLAUDE.md와 스킬과 훅

빌드 단계의 기본값은 계획 모드다. 엔지니어가 승인된 스펙을 주고 Claude가 코드를 읽기만 하면서 계획을 세우고 인터뷰하며 엔지니어가 계획을 고친 뒤 승인본을 plan.md로 커밋한다. 계획 모드에서는 엔지니어가 수락하기 전에는 파일을 수정할 수 없어서 설계 리뷰가 코드 생성 이전에 일어난다. 구현이 계획에서 벗어나면 같은 커밋에서 plan.md를 갱신하고 훅으로 동기화를 강제할 수 있다. 계획이 탄탄하면 구현은 한 번에 끝나는 경우가 많다고 한다. 자동 수락 모드는 가드레일이 성숙한 뒤 일상적 작업의 기본이 되고 사용자가 편집을 지켜보는 대신 긴 자율 세션 뒤의 산출물을 검토하는 쪽으로 무게가 이동한다.

CLAUDE.md는 새로 온 사람이 알아야 할 명령, 관례, 구조, 자주 틀리는 것을 담은 한 쪽 분량의 파일이다. 같은 실수를 두 번 하면 교정 내용을 거기에 넣는 작업 규칙이 제안된다. 스킬은 일관되게 적용해야 하는 조직 지식을 운영 가능하게 만든 것으로, 트리거 조건이 담긴 SKILL.md로 쓰고 저장소나 플러그인으로 배포한다. 글은 스킬이 어디까지나 권고형 통제라고 분명히 한다. 반드시 지켜야 하는 정책은 그 뒤에 결정적 장치, 곧 행동을 차단하는 훅이나 PR에서 다시 점검하는 리뷰 단계가 있어야 한다. 스킬은 위반을 드물게 만들고 훅은 거의 불가능하게 만든다. 빌드 단계의 훅은 보호 경로의 수정 차단, 포맷터와 린터 실행, 자격 증명이 diff에 들어가는 것 방지를 맡는다. 병렬 작업은 각자 별도 워크트리에서 도는 여러 세션과, 단일 세션 안의 범위가 제한된 서브에이전트로 나뉘며 세션 수의 현실적 한계는 한 사람이 제대로 검토할 수 있는 흐름의 수다.

테스트와 배포, 에이전트는 운영 게이트 앞까지

테스트 단계의 원칙은 에이전트가 자기 작업을 스스로 검증할 수단을 항상 갖는 것이다. 테스트와 빌드, 스크린샷 비교를 한 명령으로 묶고 CLAUDE.md에 기대 출력과 함께 적는다. 버그 수정은 실패하는 테스트를 먼저 쓰고 그것을 수정하지 않고 통과시키게 하며 수정 작업 중 테스트 파일 편집을 막는 훅이 루프를 보호한다. 평가(evals)는 단계 경계 QA의 AI 네이티브 대응물이다. 최근 작업에서 뽑은 20~50개 과제로 스위트를 만들고 CLAUDE.md, 스킬, 훅이 바뀔 때 CI에서 돌려 통과율이 떨어지면 병합 전에 검토한다. 운영 사건마다 평가가 하나씩 추가된다.

배포 단계에서는 Claude가 리뷰를 주고받는다. 모든 PR이 동일한 리뷰 패스를 거치고 발견 사항이 심각도순으로 매겨지며 리뷰 정책은 저장소의 REVIEW.md에 버그, 보안, 스펙과 계획 준수의 패스로 적는다. 발견 사항이 스스로 승인하거나 차단하지는 않고 승인은 분기 보호 규칙을 통해 코드 소유자가 한다. 코드를 쓴 에이전트가 그것을 승인할 길이 없으므로 직무 분리가 유지된다. 훅은 승인 게이트도 된다. 프로덕션 배포 명령을 가로채 릴리스 승인이 없으면 종료 코드 2로 차단하고 사유를 에이전트에게 알려 준다. 규제 기업용 관리형 설정 예시는 비밀 파일 읽기와 임의 네트워크 접근 거부, 샌드박스 강제, 관리형 훅과 MCP만 허용, 최소 버전 요구를 보여 준다. 글은 이것을 그대로 복사할 권고가 아니라 출발점으로 다루라고 한다. 파이프라인에서는 읽기 전용 판단 단계에서 시작해 쓰기 단계를 게이트 뒤에 두고 배포와 롤백을 환경별로 범위를 제한한 MCP 도구로 노출하며 개발은 자유롭게 하되 프로덕션은 릴리스 관리자가 승인하게 자율성을 환경별로 나눈다. 글이 강조하는 원칙은 에이전트가 프로덕션 게이트까지는 행동하되 넘지는 못한다는 것이다.

유지보수, 루프를 닫는다

여섯 번째 단계는 사람이 호출 경로에 없는 상태에서 루프를 닫는다. 결정적 스크립트가 운영 지표를 지켜보다 통제 대역을 넘으면 Claude를 부른다. 탐지 자체는 모델 없이 롤링 기준선과 웨스턴 일렉트릭 규칙 같은 통계로 하고 대역에 따라 권한이 달라진다. 1시그마에서는 기록만 하고 2시그마에서는 읽기 전용으로 진단하며 3시그마에서는 PR을 열거나 사전 승인된 런북을 실행할 수 있다. 에이전트는 진단을 intent.md 형식으로 써서 파이프라인에 되먹인다. 예시로 CI 테스트 실패율이 3시그마를 넘으면 불안정 테스트를 격리하거나 되돌리기 PR을 열고 배포 직후 5xx 비율이 3시그마를 넘으면 기존 롤백 파이프라인을 실행한다. 수정이 배포되면 해당 사건의 평가를 추가해 재발을 막는다.

예약된 코드베이스 스캔은 보안 스캔이 한 시점의 진술일 뿐이라는 문제의식에서 나온다. 코드는 매주 바뀌고 모델 세대마다 찾는 취약점이 다르므로 스캔을 일정에 따라 돌리고 발견을 다른 변경과 같은 게이트로 보낸다. 글은 이를 호스팅하는 제품으로 Claude Security를 소개하는데, 엔터프라이즈 공개 베타이고 소비량 기준으로 과금되며 검증된 발견과 신뢰도 등급을 붙인다고 적는다. Slack에서 사건 채널의 구성원으로 일하는 Claude Tag도 공개 베타로 소개된다. 이 둘은 제품 설명이며 효과는 글에서 검증되지 않았다.

읽을 때 유의할 점

이 글은 Anthropic 자신의 Applied AI 팀이 고객과 일하며 얻은 관행을 정리한 벤더 가이드다. 각 플레이에 리딩과 래깅 지표가 붙어 있지만 어느 것도 실제 값은 공개되지 않는다. 몇 주가 몇 시간으로 줄어든다는 식의 기대는 측정 목표이지 보고된 결과가 아니다. 글의 예시 코드와 설정은 설명용이며 이 노트에서 실행하지 않았다. 또 모든 처방이 자사 제품과 연결돼 있어서 다른 도구로 같은 구조를 구현할 때 무엇이 필요한지는 글이 다루지 않는다.

그래도 글에서 구조적으로 가져갈 만한 통찰은 분명하다. 첫째, 병목이 이동했다는 진단은 어느 조직이든 자기 프로세스에서 사람 속도로 남은 단계를 찾는 질문이 된다. 둘째, 단계마다 커밋되는 산출물을 감사 추적으로 쓰는 설계는 도구와 무관하게 적용할 수 있다. 셋째, 권고형 통제와 결정적 통제를 구분하고 반드시 지켜야 할 것 뒤에 훅 같은 강제 장치를 두는 원칙이다.

참고 자료

Louis Claxton — The AI-native SDLC playbook (Claude Blog)