코드는 몇 시간, 승인은 몇 주, 앤트로픽이 다시 짠 개발 절차

글은 Applied AI 팀의 Louis Claxton이 썼고, 앞선 작업을 바탕으로 삼았다며 Jim Blackhurst와 Will Steuk, Jamal Arif에게 감사를 적었습니다. 첫 문단은 조직들이 1년 전에는 상상하기 어려웠던 속도로 AI에게 코드를 쓰게 하는데, 코드 주변의 절차는 같은 속도로 바뀌지 않았다는 진단입니다. 승인 단계와 리뷰, 인수인계, 사내 규정이 그대로라서 Claude Code 같은 코딩 에이전트로 얻은 생산성이 그 절차에 묶여 있다는 설명입니다.

코드가 병목에서 빠지자 생긴 세 가지 일

지금의 개발 절차는 코드를 쓰는 단계가 가장 오래 걸리고 가장 비싸던 시절에 만들어졌습니다. 제품 요구사항 문서, 공수 산정 회의, 보안 검토는 몇 주에서 몇 분기씩 이어지는 개발 기간 동안 모두가 같은 방향을 보게 하려는 장치였습니다. 플레이북은 빌드 단계가 이 절차보다 빨리 돌기 시작하면 세 가지 일이 생긴다고 봤습니다.

병목이 빌드의 앞뒤, 곧 기획과 리뷰·테스트, 배포로 옮겨 갑니다. 통제도 현실과 어긋나서, 사람이 쓴 코드를 한 줄씩 읽던 리뷰는 에이전트가 변경분 대부분을 쓰는 순간 따라가지 못합니다. 예외 처리는 여전히 주간·월간 위원회를 거치니 거버넌스 비용도 불어납니다. 플레이북은 보안팀을 예로 들었습니다. 보안 인력은 사람이 만드는 코드량에 맞춰 꾸려졌기 때문에, 에이전트가 코드량을 몇 배로 늘리면 리뷰 대기열이 쌓이거나 검토가 덜 된 코드가 배포되고, 규제 산업은 두 결과를 모두 받아들일 수 없습니다.

앤트로픽은 이 문제를 자기 조직의 숫자로 먼저 공개한 적이 있습니다. 7월 21일 Claude 블로그에 실린 제이슨 클린턴의 보안 글을 보면, 앤트로픽 엔지니어 한 명이 분기마다 내보내는 코드가 2021~2025년 평균의 8배로 늘었고, 지금 머지되는 코드의 약 80%를 Claude가 쓰며 절반 넘게를 사내용 Claude Tag가 머지합니다. 같은 글은 대부분의 개발자가 에이전트를 여러 개씩 돌리게 되자 팀이 사람이 코드를 리뷰하는 속도만큼만 움직일 수 있다는 사실이 드러났고, 테스트·CI 단계가 가장 아픈 병목이 됐다고 적었습니다.

한 줄로 흐르던 절차를 고리로 묶었습니다

플레이북은 전통적인 SDLC(소프트웨어 개발 주기)와 AI 네이티브 SDLC의 양 끝을 단계별로 대비하고, 대부분의 조직은 두 열 사이 어딘가에 있다고 적었습니다. 단계마다 무엇을 커밋하고 끝내는지까지 옮기면 아래와 같습니다.

다음 단계는 앞 단계가 커밋한 파일을 읽으면서 시작합니다. 그래서 누가 무엇을 요청했고 에이전트가 무엇을 만들었으며 누가 승인했는지가 커밋 기록으로 이어지고, 플레이북은 이 커밋 사슬을 감사 추적(나중에 누가 무엇을 했는지 확인할 수 있는 기록)으로 봤습니다. 판단이 필요한 결정은 여전히 사람이 책임지되, 사람의 주의는 에이전트가 표시한 내용을 검토하는 단계 사이의 승인으로 모입니다.

처음부터 자동으로 이어지지는 않습니다. 플레이북은 처음에는 단계마다 손으로 프롬프트를 넣고, 승인된 산출물이 다음 단계를 저절로 여는 고리를 목표 상태로 삼으라고 적었습니다. 플레이북은 이 고리 안의 작업 단위를 「플레이」라고 부르고, 플레이마다 무엇이 달라지는지, 시작 조건, 실행 단계, 거버넌스, 효과를 재는 지표를 붙였습니다.

기획은 아이디어를 낸 사람이 직접 씁니다

첫 산출물 intent.md는 사람의 아이디어나 티켓, 운영 알림에서 시작하고, 사람이 낸 아이디어라면 문제를 겪는 당사자가 Claude와 브레인스토밍해 씁니다. 전통 방식에서는 아이디어가 백로그와 사용자 스토리, 스토리 포인트, 정제 회의를 거치는 동안 담당자가 몇 번씩 바뀌어서, 개발팀에 닿는 내용이 처음 뜻과 멀어진다고 플레이북은 지적했습니다. AI 네이티브 방식에서는 발의자가 자기 말로 문제를 설명하고, Claude가 분석가처럼 범위와 사용자, 제약, 성공 조건을 되물은 뒤, 조직 양식에 맞춰 intent.md로 정리합니다.

원문의 예시는 보험 청구 상담입니다. 청구 운영팀 직원이 쓴 intent.md에는 고객이 청구 진행 상황을 물으려고 콜센터에 전화하고, 상담원이 통화 시간의 약 3분의 1을 상태 문의에 쓴다는 문제가 적혀 있습니다. 제약 조건으로는 포털 세션에 새 개인정보를 넣지 말 것과 기존 인증만 쓸 것을, 열린 질문으로는 외부 손해사정사도 접근이 필요한지를 남겼습니다.

저장 위치는 제품 저장소 안의 intent/ 폴더면 충분하다고 했고, git을 모르는 직원도 claude.ai나 Cowork에서 GitHub 커넥터를 통해 Claude가 대신 커밋하게 할 수 있습니다. 제품 책임자가 검토해 받아들이면 그 결정이 머지나 리뷰 종료로 기록됩니다. 효과는 첫 대화에서 intent.md 커밋까지 걸린 시간으로 재는데, 플레이북은 이 시간이 몇 주짜리 요구사항 수집에서 몇 시간으로 줄어들 것을 기대치로 적었습니다.

설계 단계에서 정책 충돌을 먼저 표시합니다

승인된 intent.md는 설계로 넘어가, Claude가 조직의 스킬을 불러온 채 요구사항·설계 스펙을 씁니다. 스킬은 Claude가 작업할 때 꺼내 읽는 지침 폴더로, 여기에 브랜드와 보안, 컴플라이언스, UX 기준을 넣어 둡니다. 제품 책임자는 스펙을 쓰지 않고 검토하고, 화면 작업이라면 intent.md를 바탕으로 Claude Design(베타)에서 목업을 다듬어 Claude Code로 넘깁니다. 원문에 실린 프롬프트는 스킬을 적용해 spec.md를 쓰되, 서로 모순되는 정책처럼 동시에 만족할 수 없는 부분은 우려 사항으로 분명히 적으라는 내용입니다.

정책이 스펙을 쓰는 순간 적용되면, 몇 주 뒤 리뷰에서 발견하던 위반을 설계 단계에서 표시할 수 있습니다. 제품 책임자는 표시된 우려부터 정책 담당자와 풀고, 위험도가 높은 변경은 기술 리드와 상의해 빌드로 넘길지 정합니다. 프롬프트는 처음에는 손으로 넣다가 조직 공용 슬래시 명령으로 만들고, 나중에는 intent.md가 머지되면 비대화형 작업이 스펙을 PR로 올리게 합니다. 지표는 intent.md와 spec.md의 커밋 시각 차이, 그리고 빌드를 시작한 뒤 스펙을 다시 고친 횟수입니다.

계획서는 대화를 못 본 엔지니어도 읽고 구현할 수준까지 다듬습니다

빌드는 플랜 모드에서 시작합니다. 플랜 모드는 Claude가 코드베이스를 읽기만 하고 고치지는 못하는 상태로, 엔지니어가 계획을 승인해야 파일 수정이 풀립니다. 엔지니어는 바뀌는 파일과 작업 순서, 구현을 증명할 테스트를 담은 계획을 받아 무엇이 깨질 수 있는지, 가장 위험한 단계가 어디인지, 왜 다른 방법을 버렸는지 따져 묻습니다. 대화를 보지 못한 엔지니어가 계획서만 읽고 구현할 수 있을 때까지 다듬어 plan.md로 커밋하고, 원문은 계획이 탄탄하면 구현은 대개 한 번에 끝난다고 적었습니다.

원문 예시의 plan.md에는 청구 시스템 API가 초당 50건에서 요청을 제한하니 화면 쪽에 캐시가 필요하다는 위험이 적혀 있습니다. 구현이 계획에서 벗어나면 같은 커밋에서 plan.md를 고치고, 둘을 맞추는 일을 훅으로 강제할 수도 있습니다. 가드레일이 성숙하면 편집마다 묻지 않는 자동 승인 모드가 일상 작업의 기본값이 되고, 사람의 리뷰는 편집을 지켜보는 일에서 긴 자율 세션의 결과물을 검토하는 일로 옮겨 갑니다.

한 엔지니어가 여러 세션을 함께 돌릴 수도 있습니다. 서로 다른 파일을 만지는 작업을 골라 작업마다 git 워크트리(한 저장소를 폴더 여러 개에 따로 펼쳐 두는 기능)를 하나씩 주고, 같은 파일을 만지는 작업은 한 세션에서 차례로 처리합니다. 플레이북은 두세 세션으로 시작해 제대로 리뷰할 수 있는 만큼만 늘리라고 했습니다. 반복되는 일은 서브에이전트로 넘기는데, 앱을 실행해 동작을 확인하는 검증 담당의 정의에는 아무것도 고치지 말고 보고만 하라는 문장이 들어 있습니다.

기존 시스템과의 관계도 따로 다뤘습니다. 업무 항목은 Jira에, 요구사항은 규제 추적 기능이 있는 도구에, 변경 승인은 변경관리위원회에 있는 조직이 많고, 감사인과 규제 기관이 이미 그 기록을 받아들이고 있어서 쉽게 걷어낼 수 없습니다. 플레이북은 산출물마다 원본을 가진 시스템을 하나로 정하라고 했고, 저장소를 원본으로 두는 방식, Jira나 ServiceNow를 원본으로 두고 MCP로 결과를 적어 넣는 방식, 서로의 ID와 커밋 해시를 적어 연결만 해 두는 방식을 선택지로 들었습니다.

CLAUDE.md는 한 페이지, 정책은 스킬로 권하고 훅으로 막습니다

는 신입이 첫날 알아야 할 것을 담는 파일입니다. 저장소에서 /init을 실행해 초안을 만든 뒤 빌드·테스트·린트 명령과 중요한 규약, Claude가 자주 틀리는 것만 남기고, 같은 실수가 두 번 나오면 그 교정을 추가합니다. 원문 예시에는 「돈은 언제나 BigDecimal로, double은 쓰지 않는다」「의존성 버전은 플랫폼팀 소관이라 올리지 않는다」 같은 줄이 있습니다. Claude가 세션을 시작할 때마다 전부 읽는 파일이라 한 페이지를 넘기지 말라는 규칙이 붙었고, 지침을 덜어낸 효과는 시스템 프롬프트의 80%를 지우고도 손실을 찾지 못한 앤트로픽의 실험에서 다룬 적이 있습니다.

정책을 적용하는 장치는 둘로 나뉩니다. 스킬은 권고형 통제라서 Claude가 코드를 쓸 때 정책을 적용할 가능성을 높이지만, 세션이 반드시 따르도록 강제하지는 못합니다. 훅은 Claude가 특정 동작을 할 때마다 스크립트를 실행해 허용하거나, 사람에게 묻거나, 막는 결정적 장치입니다. 빌드 단계의 훅 예시로는 생성된 클래스처럼 보호된 경로의 수정 차단, 편집 직후의 포매터·린터 실행, 변경분에 섞인 자격 증명 차단을 들었습니다.

스킬은 위반을 드물게 만들고, 훅은 위반을 거의 불가능하게 만듭니다.— Louis Claxton, 앤트로픽 Applied AI 팀

예외 없는 정책에는 스킬 뒤에 훅이나 PR 단계의 재검사 같은 결정적 장치를 두라는 것이 플레이북의 설명입니다. 스킬이 제대로 작동하는지는 정책을 인용한 PR 리뷰 지적이 0에 가까워지는지로 확인하고, 줄지 않으면 스킬이 불리지 않거나 문구가 공식 정책에서 벗어났다고 봅니다.

테스트 단계에서는 에이전트 설정도 회귀 시험을 받습니다

테스트 단계의 첫 원칙은 Claude가 자기 작업을 스스로 검증할 수단을 주는 것입니다. 검증 명령을 「make test」처럼 하나로 묶고, CLAUDE.md에 세 명령을 모두 돌려 출력을 붙여야 완료로 친다고 적습니다. 원문 예시 블록의 마지막 줄은 테스트가 실패하면 테스트는 그대로 두고 코드를 고치라는 문장입니다. 버그 수정은 실패하는 테스트를 먼저 커밋하고, 테스트 파일을 건드리지 않은 채 통과시키며, 수정 작업 중에는 훅으로 테스트 파일 편집을 막습니다. 화면 작업은 목업과 스크린샷을 비교하며 두세 번 반복하는 것이 보통이라고 했습니다.

무엇을 증거로 끝났다고 판정할지는 앤트로픽이 앱 하나를 끝내지 못한 모델에게 하네스를 새로 짜 준 실험에서도 문제의 중심이었습니다. 플레이북은 여기에 에이전트 설정 자체를 시험하는 단계를 하나 더 얹었습니다. 최근 실제 작업 20~50개와 그 합격 결과를 평가 케이스로 만들고, 정해진 일정과 CLAUDE.md·스킬·훅이 바뀔 때마다 CI에서 돌리며, 통과율을 떨어뜨린 스킬 변경은 머지 전에 리뷰를 받게 합니다. 프로덕션 인시던트가 날 때마다 그 사고를 맡은 팀이 케이스를 하나씩 추가합니다.

에이전트는 프로덕션 배포 직전까지만 일합니다

배포 단계에서는 리뷰가 양방향으로 돕니다. Claude가 들어오는 PR을 조직 정책대로 리뷰하고, 자기 PR에 달린 코멘트는 @claude 호출을 받아 직접 고친 뒤 푸시합니다. 리뷰 정책은 저장소 최상위의 REVIEW.md에 적는데, 원문 예시는 버그, 보안, 스펙 준수의 세 가지 검토로 나누고, 동작을 깨뜨리거나 데이터를 유출하거나 정책을 어기는 지적만 Important로 올리며, 스타일 지적은 리뷰 한 번에 다섯 개까지만 보고하게 했습니다. 지적 사항만으로는 PR을 승인하거나 막지 못하고, 머지에는 브랜치 보호 설정에 따라 코드 오너의 승인이 필요합니다.

플레이북은 이 구조를 코드를 쓴 에이전트가 자기 코드를 승인할 길이 없어서 직무 분리가 유지된다고 설명했습니다. 제이슨 클린턴의 7월 글에는 사내에서 같은 방식을 쓴 뒤의 숫자가 있습니다. 에이전트에게 지적마다 타당하다는 근거를 쓰게 하자 실질적인 리뷰 코멘트가 달린 PR의 비율이 16%에서 54%로 올랐고, 과거 claude.ai 인시던트를 일으킨 버그의 약 3분의 1은 지금의 자동 검사로 잡혔을 것이라는 분석입니다. 같은 글은 인터콤이 PR의 19%를 자동 승인한다는 사례도 인용했습니다.

승인 게이트는 훅으로 만듭니다. 원문에는 프로덕션 배포 명령을 감지해 릴리스 승인이 없으면 실행을 막고 이유를 출력하는 스크립트가 그대로 실려 있고, 팀 공용 훅은 저장소 설정 파일에, 양보할 수 없는 훅은 엔지니어가 끌 수 없는 관리형 설정에 둡니다. 규제 산업용 관리형 설정 예시는 비밀 파일 읽기와 임의의 외부 통신을 막고, 운영체제 수준 샌드박스에서 허용한 도메인으로만 통신하게 하며, 승인된 플러그인 저장소를 거친 스킬과 훅만 쓰게 합니다. 플레이북은 이 설정을 출발점으로 삼아 고쳐 쓰라고 했고, 막는 항목마다 할 수 있는 일이 줄어드니 저장소 데이터의 등급에 맞춰 조정하라고 적었습니다.

CI/CD 파이프라인에서는 실패한 빌드의 원인 분류나 변경 기록 초안처럼 읽기만 하는 판단부터 맡기고, 쓰기 작업은 기존 게이트 뒤에 둡니다. 모델 호출은 API로 하거나, 트래픽을 회사의 클라우드 계약 안에 둬야 하는 조직이라면 AWS Bedrock, Google Vertex, Microsoft Foundry를 거치게 했습니다. 에이전트 작업은 컨테이너에서 수명이 짧은 토큰으로 돌리고 프로덕션 자격 증명은 기본으로 주지 않으며, 배포와 상태 확인, 롤백은 환경별로 범위를 정한 MCP 도구로 엽니다. 개발 환경에서는 에이전트가 자유롭게 배포하지만 프로덕션에서는 릴리스를 준비하는 데까지만 하고, 릴리스 담당자가 승인하며, 훅이 그 게이트를 강제합니다.

운영 단계에서는 3σ를 넘어야 에이전트가 움직입니다

마지막 단계는 사람이 시작하지 않아도 도는 고리입니다. 프로덕션 지표를 지켜보는 탐지는 끝까지 결정적인 스크립트가 맡고 모델은 끼지 않습니다. 이동 구간의 평균과 표준편차로 관리 밴드를 정하고, 벗어난 정도에 따라 에이전트에게 허용하는 범위를 나눕니다.

원문은 세 가지 예를 들었습니다. CI 테스트 실패율이 3σ를 넘으면 에이전트가 불안정한 테스트를 격리하거나 되돌리기 PR을 올리고, 배포 직후 5xx 오류율이 3σ를 넘으면 기존 롤백 파이프라인을 돌리며, PR 처리 시간이 서서히 늘면 경영진용 보고서를 씁니다. 진단 결과는 1단계 형식의 intent.md로 쓰여 다시 기획으로 들어가고, 담당 엔지니어는 대기열에서 지금 고칠지, 일정에 넣을지, 기각할지를 고릅니다. 전통 방식에서는 새벽 3시에 울린 알림을 놓칠 수 있고 사후 분석의 조치가 코드까지 닿지 못하기도 한다고 원문은 적었습니다.

슬랙으로 들어오는 긴급 요청은 Claude Tag가 받습니다. 공개 베타로 슬랙에서 쓸 수 있는 이 기능은 Claude를 자기 이름으로 인시던트 채널에 넣어 첫 대응을 맡기고, 요청과 진단, 사람의 승인, 수정이 채널에 그대로 남게 합니다. 작고 경계가 분명한 수정은 리뷰 게이트를 거치는 PR로, 그보다 큰 일은 intent.md로 정리돼 기획 단계로 돌아갑니다.

어디서부터 시작하나

플레이마다 선행 조건이 적혀 있고, 의존성 그림의 맨 윗줄에 있는 다섯 개는 무엇도 먼저 갖출 필요가 없는 출발점입니다. 아이디어를 intent.md로 받기, CLAUDE.md 만들기, 세션에 피드백 루프 달기, 훅으로 승인 게이트 세우기, 플랜 모드로 시작하기입니다. 반대로 CI/CD 자동화는 PR 리뷰와 승인 게이트를 선행 조건으로 두었습니다. 게이트가 갖춰진 뒤에야 자동화가 그 게이트를 거쳐 속도를 낼 수 있다는 설명입니다.

플레이마다 git과 PR 기록에서 바로 읽을 수 있는 지표가 붙어 있는 것도 특징입니다. 기획은 첫 대화부터 커밋까지의 시간, 빌드는 첫 구현에서 머지되는 변경의 비율, 테스트는 에이전트가 쓴 변경의 첫 CI 통과율, 배포는 DORA 지표(배포 빈도와 변경 실패율처럼 개발 조직의 속도와 안정성을 재는 네 지표)로 재도록 했습니다.

플레이북에 없는 것

효과를 증명하는 숫자는 없습니다. 플레이별로 무엇을 잴지는 구체적이지만, 이 방법을 도입한 고객사가 어디이고 주기가 얼마나 줄었는지는 공개되지 않았습니다. 인용할 수 있는 실측은 앤트로픽 자신과 인터콤의 숫자이고, 앤트로픽은 머지 코드의 80%를 Claude가 쓰는 회사라 대부분의 조직과 출발점이 다릅니다.

제품 의존도 짙습니다. 설계 단계의 Claude Design은 베타, 배포 단계의 관리형 Code Review는 연구 프리뷰, 운영 단계의 Claude Tag는 공개 베타로 표기돼 있습니다. 리뷰는 자체 CI에서 claude-code-action으로 돌리는 길도 적혀 있지만, 채널로 들어오는 인시던트 대응은 공개 베타인 Claude Tag를 전제로 해서 그 부분의 도입 시점은 제품 출시 일정에 묶입니다.

사람의 검토가 형식에 그칠 위험도 남습니다. 플레이북은 병렬 세션의 실질적 상한을 한 사람이 제대로 리뷰할 수 있는 작업 줄기의 수로 잡았습니다. 커밋 사슬은 각 게이트에서 누군가 산출물을 실제로 읽을 때 감사 추적으로 쓰이고, 에이전트가 문서를 쓰는 비용이 줄어든 만큼 사람이 읽을 문서는 늘어납니다.

Claude Code 팀이 6월 3일 같은 블로그에 쓴 글에는 공들여 짠 6개월짜리 로드맵이 3개월째에 이미 낡았다는 대목이 있습니다. 플레이북도 비슷한 전제 위에 서 있어서, 절차를 한 번 새로 짜는 데서 멈추지 않고 평가 케이스와 CLAUDE.md, 관리 밴드를 계속 고쳐 가는 운영을 요구합니다. 원문은 이 고리가 계속 돌고 사람의 판단은 그 위에 머문다는 문장으로 끝납니다.

읽어 주셔서 고맙습니다.

초이 드림