AI 네이티브 SDLC 플레이북

이제 병목은 코드가 아닙니다

조직들은 1년 전만 해도 상상하기 어려웠던 속도로 AI를 활용해 코드를 작성하기 시작했습니다. 하지만 코드를 둘러싼 프로세스는 같은 속도로 바뀌지 않았습니다.

많은 엔지니어링 팀에는 여전히 예전과 똑같은 승인 게이트, 리뷰, 인계 절차, 정책이 남아 있습니다. 그래서 Claude Code 같은 에이전틱 코딩 솔루션으로 얻은 생산성 향상이 정체되고 있습니다.

소프트웨어 개발 수명 주기(SDLC)는 소프트웨어를 아이디어에서 프로덕션까지 가져가는 프로세스입니다. 대부분의 조직은 형태는 조금씩 달라도 계획, 설계, 빌드, 테스트, 배포, 유지보수라는 같은 여섯 단계를 운영합니다. 전통적으로 각 단계는 서로 다른 역할이 맡는 별개의 단계였습니다. 프로덕트 매니저가 요구사항을 작성하면 기술 아키텍트가 이를 설계로 바꾸고, 엔지니어가 그 설계대로 빌드합니다. 규제 산업 기업에서는 QA 팀이 이를 검증하고, 릴리스 팀이 배포하며, 운영 팀이 실행 중인 시스템을 모니터링합니다. 작업은 문서, 티켓, 승인을 거쳐 단계 사이를 오갑니다.

기존 소프트웨어 개발 수명 주기(SDLC)는 단계마다 책임 소재와 통제를 확보하기 위해 프로세스가 무겁습니다. 그런데 기존 SDLC는 코드를 작성하고 구현하는 단계에 가장 많은 시간과 비용이 들던 시대에 효율을 극대화하도록 설계된 것이고, 지금은 더 이상 그렇지 않습니다. PRD, 관례처럼 치르는 공수 산정, 제품 보안 리뷰는 모두 몇 주, 몇 달, 길게는 몇 분기가 걸릴 수도 있는 개발 기간 동안 팀의 방향을 억지로라도 맞추기 위해 존재했습니다.

기존 SDLC에는 모든 단계를 사람이 수행한다고 가정한 통제 장치도 있습니다. 가장 큰 가치를 만들어 내는 조직들은 사람이 루프 안에 계속 남아 있게 하면서, 지금 에이전틱 AI가 할 수 있는 일을 중심으로 프로세스를 다시 만들었습니다. 이 가이드에서는 Anthropic의 Applied AI 팀이 고객과 함께 일하며 얻은 경험을 바탕으로, 조직 안에서 SDLC의 각 단계에 Claude를 통합해 개발 속도를 높이고 프로세스를 더 빠르게 돌리는 모범 사례 몇 가지를 차례로 살펴봅니다.

코드가 더 이상 병목이 아니고 빌드 단계가 기존 SDLC가 감당할 수 있는 속도보다 빠르게 돌아가면, 세 가지 일이 벌어집니다.

병목이 빌드 단계의 앞뒤 단계로 옮겨 갑니다. 주로 계획, 리뷰·테스트, 배포 단계이며, 이 단계들은 여전히 사람의 속도로 진행됩니다.
통제 장치가 현실과 맞지 않게 되고 감당할 수 없게 됩니다. 사람이 코드를 작성하던 때에는 한 줄씩 손으로 리뷰하는 것이 합리적이었지만, 에이전트가 diff의 대부분을 작성하게 되면 리뷰가 그 속도를 따라갈 수 없습니다.
예외 사항이 여전히 매주나 매달 열리는 회의와 위원회를 거쳐야 하므로 거버넌스 비용이 늘어납니다.

이제 제약은 빌드가 아니라, 빌드 앞뒤에서 사람의 속도로 진행되는 단계들입니다. 빌드는 몇 시간으로 줄어들지만, 사람의 속도로 진행되는 단계들은 그대로 오래 걸립니다.

보안 병목을 예로 들어 보겠습니다. 보안 팀의 규모는 사람이 만들어 내는 결과물의 양에 맞춰져 있습니다. 그래서 에이전트가 코드 산출량을 몇 배로 늘리면, 리뷰 대기열이 쌓이거나 충분히 리뷰되지 않은 코드가 배포됩니다. 규제를 받는 조직은 어느 쪽도 받아들일 수 없으므로, 보안 검사와 정책 검사가 에이전트의 속도를 따라가야 합니다.

에이전틱 AI로 얻는 생산성 향상을 제대로 실현하고 에이전틱 AI를 안전하게 쓰려면, 기존 SDLC 전체가 구현 단계가 겪은 것과 같은 수준의 변화를 거쳐야 합니다.

AI 네이티브 SDLC란 무엇일까요?

AI 네이티브 SDLC는 기존의 통제 목표를 새로운 집행 방식과 결합해 새롭게 구상한 프로세스입니다. 프로세스는 선형으로 흘러가는 대신 루프가 되고, 모든 지점에 AI가 들어갑니다. AI 네이티브 SDLC에서는 인계가 자동으로 이루어지고 다음 플레이도 자동으로 시작됩니다. 덕분에 기존 SDLC에서 단계 사이의 인계가 수작업이고 번거롭다는 문제를 해결하는 데 도움이 됩니다.

이런 변화는 에이전틱 SDLC, AI SDLC, 또는 간단히 에이전틱 소프트웨어 개발이라고도 불립니다. 이름은 달라도 모두 같은 것을 가리킵니다.

AI 네이티브 SDLC의 여섯 단계에서 일어나는 변화

아래 표는 기존 SDLC와 Claude가 뒷받침하는 AI 네이티브 SDLC를 스펙트럼의 양 끝에 놓고 비교합니다. 대부분의 조직은 두 열 사이 어딘가에 있습니다.

단계	기존 SDLC	AI 네이티브 SDLC
계획	위원회가 요구사항을 수집하고, 워크숍과 승인 절차를 거쳐 추린 뒤 손으로 문서화	Claude가 원천 자료에서 바로 문제점을 종합해, 사람이 읽을 수 있고 기계가 바로 실행할 수 있는 `intent.md`에 기록
설계	분석가가 명세를 작성하고 디자이너가 이를 해석	스킬로 정리해 git으로 버전 관리하는 표준을 따르며, 에이전트와 함께하는 한 번의 작업 세션으로 요구사항과 설계를 압축
빌드	테스트와 코드를 손으로 작성하고, 문서는 주요 개발이 끝난 뒤에 작성	AI가 테스트와 코드를 생성하고, 조직에 쌓인 지식은 버전 관리되는 기계 판독용 `CLAUDE.md` 파일과 스킬로 유지
테스트	단계 경계마다 QA 게이트	구현 과정 전반에 걸쳐 평가(eval)를 지속적으로 실행
배포	사람이 코드를 한 줄씩 모두 리뷰하고, 거버넌스는 리뷰 주기에 맞춰 이루어지며 일관성이 떨어지는 경우가 많음	여러 겹의 에이전트 리뷰를 거치고, 사람의 리뷰는 규제 대상 코드와 핵심 코드에만 집중. 거버넌스는 AI가 행동하는 시점에 집행되며, 훅이 승인 게이트 역할을 함
유지보수	사람이 프로덕션을 지켜보며 버그를 찾음	에이전트가 운영 중인 배포를 모니터링. 관리 대역(control band)을 벗어나면 원인을 진단하고, 그 결과를 새 `intent.md`로 작성해 루프에 다시 넣음

오른쪽 열의 모든 항목은 커밋된 산출물로 이어져 있습니다. 각 단계는 산출물 하나를 버전 관리 시스템에 기록하면서 끝나고(intent.md, spec.md, plan.md, diff와 그 테스트, 리뷰 결과가 달린 PR, 장애 기록 등), 다음 단계는 그 산출물을 읽으면서 시작합니다. 초기 단계에서는 주로 .md 파일이 산출물이 됩니다. 프로덕트 오너와 에이전트가 같은 파일을 읽고 그에 따라 행동할 수 있기 때문입니다. 빌드 단계부터는 코드와 그 기록이 산출물이 됩니다. 이어진 커밋들은 감사 추적 기록(audit trail)이기도 합니다. 누가 무엇을 요청했고, 에이전트가 무엇을 만들었고, 누가 승인했는지가 남기 때문입니다.

판단이 필요한 모든 결정에는 여전히 사람이 책임을 집니다. 에이전틱 SDLC에서는 리뷰해야 할 산출물이 바뀌면서 사람이 주의를 기울이는 곳도 함께 옮겨 갑니다.

모든 단계는 다음 단계가 읽을 수 있는 산출물을 커밋합니다. 인텐트, 명세, 계획, diff, 리뷰 결과가 모여 감사 추적 기록이 됩니다.

플레이

플레이(play)는 이 플레이북의 핵심입니다. 플레이는 선형이 아닌 여섯 단계(계획, 설계, 빌드, 테스트, 배포, 유지보수)로 묶여 있으며, 이 단계들이 모여 수명 주기 전체를 다룹니다.

각 플레이는 다음 내용을 다룹니다.

무엇이 바뀌는지
시작하기
구현을 위한 구체적인 단계
거버넌스 고려 사항
효과가 있었는지 측정하는 방법

각 단계는 모듈식이라서, 조직은 각자의 필요에 따라 시기별로 서로 다른 단계를 먼저 바꾸기로 정할 수 있습니다. 각 플레이는 "선행 조건" 항목에 의존 관계를 밝혀 두며, 의존성 그래프가 이를 더 자세히 보여 줍니다.

한 단계는 산출물을 커밋하면서 끝나고, 그 커밋이 다음 단계를 시작합니다. 수락된 intent.md는 요구사항·설계 작업을 시작하고, 승인된 spec.md는 계획 모드를 시작합니다. 병합된 PR은 파이프라인을 실행하고, 프로덕션에서 관리 대역을 벗어나면 다음 intent.md가 작성되며, 그렇게 루프가 계속 이어집니다.

처음에는 각 단계를 직접 프롬프트로 실행하지만, 최종 목표는 수락된 산출물 하나하나가 다음 게이트를 작동시키는 루프입니다. 사람의 주의는 게이트에 집중됩니다. 각 단계를 처음부터 시작하는 대신, 에이전트가 표시한 항목을 리뷰하게 됩니다.

플레이는 단계별로 나열되어 있고, 화살표는 플레이를 도입할 순서를 나타냅니다. 둘은 서로 다릅니다. 점토색(clay)으로 표시된 플레이라면 어느 것으로든 시작할 수 있습니다. 점토색 플레이로 들어오는 화살표는 없으므로, 먼저 갖춰야 할 것이 없습니다. 다른 플레이는 그 플레이를 가리키는 화살표가 출발하는 플레이들을 먼저 도입하면 됩니다.

01. 계획

아이디어가 더 이상 누군가 문서로 정리해 주기를 기다리지 않습니다. 의도는 처음 제안한 사람의 말 그대로 한 번만 기록되고, 다음 단계가 바로 활용할 수 있는 버전 관리 산출물이 됩니다.

intent.md로 기록하기

소프트웨어 개발 프로세스를 시작하는 intent.md는 여러 경로로 들어올 수 있습니다. 누군가 아이디어를 떠올리거나, 티켓이 등록되거나, 알림을 통해 장애가 드러나는 경우입니다(6단계: 유지보수 참고).

누군가 아이디어를 떠올리면 Claude와 브레인스토밍해 마크다운 형식의 초기 명세(proto-spec)를 만듭니다. 기존 SDLC라면 이 사람은 프로덕트 팀원 한 명을 설득해서 아이디어를 함께 정리하거나 대신 정리해 달라고 해야 합니다.

Claude가 만든 초기 명세는 사람이 읽을 수 있고, 버전 관리되며, 다음 단계에서 곧바로 사용할 수 있습니다. 이 초기 명세는 intent.md로 저장됩니다.

의도가 이벤트 트리거에서 나왔든 에이전트에서 나왔든 같은 절차를 따릅니다. 에이전트가 작성한 intent.md는 커밋되기 전에 프로덕트 오너가 검토하고 바로잡습니다.

기존 방식	AI 네이티브 방식
아이디어는 누군가 실행에 옮기기 전까지 백로그 항목, 사용자 스토리, 스토리 포인트, 리파인먼트 회의를 차례로 거칩니다. 인계할 때마다 담당자가 바뀌기 때문에, 엔지니어링 팀에 도달할 무렵에는 처음 제안한 사람이 뜻한 바에서 여러 단계 멀어져 있습니다.	처음 제안한 사람이 Claude와 브레인스토밍하고, 그 결과를 자신의 표현으로 쓴 초기 명세인 `intent.md`로 기록합니다. 이 산출물에는 무엇을 원하는지, 왜 원하는지, 어떤 제약 조건이 있는지가 담깁니다. 반복되는 프로세스는 스킬로 정리해 둡니다.

시작하기

선행 조건: 없습니다.
인프라: 엔지니어가 아닌 사람도 쓸 수 있는 Claude 접근 권한(claude.ai 또는 Cowork), 합의된 intent.md 템플릿, 그리고 프로덕트 오너가 지켜보는 인텐트 공유 보관소가 필요합니다. 보관소는 버전 관리가 되어야 합니다. 제품이 하나라면 가장 간단한 보관소는 제품 리포지토리 안의 intent/ 폴더입니다. 이렇게 하면 산출물의 사슬이 그로부터 만들어진 코드 바로 옆에 놓입니다. 인텐트 전용 리포지토리는 인텐트가 여러 리포지토리에 걸쳐 있을 때만 관리 부담을 감수할 가치가 있고, 모노레포라면 디렉터리 하나로 충분합니다. 이 보관소가 이미 기록을 보관하고 있는 Jira나 요구사항 관리 도구와 어떤 관계인지는 3단계: 빌드의 참고 글에서 다룹니다.

이 설정은 플랫폼 팀이나 엔지니어링 팀이 한 번만 하면 됩니다. 조직 곳곳에서 많은 사람이 기여하게 되므로, 기술 팀원 한 명이 인텐트 보관소를 마련하고 누가 쓸 수 있는지 정해야 합니다.

리포지토리가 마련되고 나면 git 경험이 없는 기여자는 git을 직접 쓸 필요가 없습니다. 대신 버전 관리 시스템(예: GitHub) 커넥터를 연결하면 Claude가 claude.ai나 Cowork에서 기여자를 대신해 마크다운 파일을 커밋해 줍니다.

실행 방법

처음 제안한 사람이 자신의 말로 Claude에게 문제를 설명합니다. 지금 할 수 없는 일이 무엇인지, 이 아이디어가 누구에게 영향을 주는지, 무엇이 더 나아진 모습인지, 무엇이 범위 밖인지 설명할 수 있습니다. 격식을 갖춘 용어는 필요하지 않습니다.
아이디어가 구체적으로 정리될 때까지 브레인스토밍합니다. Claude는 분석가가 물어볼 법한 질문을 던집니다. 범위, 사용자, 제약 조건, 그리고 성공했을 때의 모습 같은 것들입니다.
조직의 템플릿에 맞춰 결과를 intent.md로 작성해 달라고 Claude에게 요청합니다. 이 템플릿은 기술 팀원이 스킬로 만들고 리드가 승인해 둘 수 있습니다. 템플릿에는 문제, 제안하는 결과, 영향을 받는 사용자와 시스템, 제약 조건, 열린 질문을 담을 수 있습니다.
처음 제안한 사람이 Claude가 잘못 이해한 부분을 바로잡습니다.
intent.md를 공유 보관소에 커밋합니다. 작성자와 타임스탬프가 기록에 남고, 프로덕트 오너가 거기서 아이디어를 넘겨받습니다.

# 인텐트: 보험금 청구 진행 상태 셀프서비스
작성자: J. Ortiz(청구 운영팀). 상태: 초안.

## 문제
고객이 청구가 어디까지 진행됐는지 묻기 위해 콜센터에 전화합니다.
담당자는 통화 시간의 약 3분의 1을 진행 상태만 묻는 문의에 씁니다.

## 제안하는 결과
고객이 포털에서 청구 진행 상태, 다음 단계, 예상 일자를 확인합니다.

## 영향을 받는 사용자와 시스템
청구 담당자, 포털 팀, claims-core API.

## 제약 조건
포털 세션에 새로운 개인 식별 정보(PII)를 추가하지 않습니다. 기존 인증만 사용합니다.

## 열린 질문
외부 손해사정사에게도 접근 권한이 필요한가요?

거버넌스 고려 사항

증거는 커밋된 intent.md입니다. 이 파일에는 작성자, 타임스탬프, 전체 수정 이력이 남고, 인텐트 보관소의 git 이력에 기록됩니다. 승인은 프로덕트 오너가 하며, 인텐트를 2단계: 설계로 넘길지 정하는 수락 또는 거부 결정은 병합이나 리뷰 종료로 기록됩니다.

측정 방법

선행 지표: 첫 대화부터 intent.md가 커밋될 때까지 걸린 시간입니다. 작성자와 타임스탬프가 기록되는 인텐트 보관소의 git 이력에서 확인할 수 있습니다. 몇 주씩 걸리던 요구사항 도출과 정제 주기가 몇 시간으로 줄어들 것으로 기대합니다.
후행 지표: 생존율, 즉 프로덕트 오너가 닫지 않고 2단계: 설계로 받아들인 intent.md 파일의 비율입니다. 수락 또는 거부 결정은 산출물의 병합이나 닫힌 리뷰로 기록됩니다. 여기에 더해, 같은 변경에 대해 첫 spec.md가 커밋된 뒤에 intent.md가 수정된 횟수도 봅니다.

02. 설계

요구사항과 설계가 한 세션으로 합쳐집니다. 정책은 몇 주 뒤 리뷰에서 발견되는 것이 아니라 명세를 작성하는 동안 적용됩니다.

요구사항과 설계

프로덕트 오너가 승인하면, Claude는 수락된 intent.md를 가져와 요구사항·설계 명세를 만듭니다. 이때 Claude는 브랜드, 보안, 컴플라이언스, UX에 관한 조직의 스킬을 따릅니다.

프로덕트 오너는 그 명세를 리뷰하지만 직접 작성하지는 않습니다. 이 프로세스의 목표는 엔지니어링 팀이 계획을 세울 수 있고, 우려되는 부분이 표시된 명세를 만드는 것입니다.

프런트엔드 작업이 가장 분명한 예입니다. intent.md가 수락되면 프로덕트 오너는 그 intent.md를 바탕으로 Claude Design(베타)에서 디자인 목업을 만들고, 목업을 반복해서 다듬은 뒤 Claude Code로 내보내 빌드합니다.

기존 방식	AI 네이티브 방식
요구사항과 설계는 서로 다른 팀이 맡는 별개의 단계입니다. 분석가가 아이디어를 요구사항으로 정식화하면, 디자이너가 그것을 다시 해석해 설계로 만듭니다. 이렇게 나누는 것은 책임 소재를 분명히 하기 위해서지만, 느리고 그 과정에서 정보가 손실됩니다.	두 단계가 프롬프트로 진행하는 한 세션 안에서 이루어집니다. Claude가 `intent.md`를 받아 조직의 스킬이 정한 제약 안에서 요구사항·설계 명세를 만들고, 우려되는 부분을 표시합니다.

시작하기

선행 조건: intent.md 파일을 작성하고, 브랜드, 보안, 컴플라이언스, UX 정책을 스킬로 작성해 둡니다.
인프라: Claude 접근 권한이 있는 프로덕트 오너가 필요합니다. 엔지니어링 기술은 필요하지 않습니다.

실행 방법

프로덕트 오너가 조직의 스킬을 사용할 수 있는 세션을 열고 intent.md를 첨부합니다.
프로덕트 오너의 프롬프트는 intent.md를 가리키고, 제약 조건을 명시하며, 우려 사항을 표시하라고 요구합니다. 처음에는 직접 실행하고, 그다음에는 조직 수준의 슬래시 명령으로 정리합니다. 그 뒤에는 인텐트 보관소에서 intent.md가 수락되는 것을 트리거로 삼습니다. 병합 시 실행되는 비대화형 작업을 두어, 조직의 스킬을 불러온 상태로 이 작업을 실행하고 spec.md를 풀 리퀘스트로 커밋합니다(필요한 연결 작업은 5단계: 배포의 CI/CD 플레이에서 다룹니다). 그 시점부터 프로덕트 오너가 처음 관여하는 지점은 리뷰가 됩니다.
같은 프로덕트 오너가 원래 아이디어와 비교하며 명세를 리뷰합니다. 명세가 제시된 문제를 해결하는지, intent.md의 열린 질문에 답했거나 다음 단계로 넘겼는지 확인합니다.
표시된 우려 사항부터 처리합니다. 분석가였다면 에스컬레이션했을 지점들이기 때문입니다. 프로덕트 오너는 엔지니어링 팀이 명세를 보기 전에 각 우려 사항을 해당 정책 담당자와 함께 해결합니다.
spec.md를 intent.md와 함께 커밋합니다. 이 두 파일에 무엇을 요청했고 무엇을 결정했는지가 기록됩니다.
프로덕트 오너는 명세와 인텐트를 빌드 단계로 넘길지 결정하고, 조직이 고위험으로 분류하는 사안은 기술 리드와 상의합니다. 이 결정은 언제나 사람인 팀원이 내리며, 명세를 수락하면 3단계: 빌드의 계획 모드 플레이가 시작됩니다.

예시(프롬프트)

첨부한 intent.md를 읽고, 이를 기존 코드베이스에 통합하기 위한 요구사항·설계 명세를 작성해 주세요. 사용할 수 있는 스킬을 적용해서 계획이 브랜드 가이드라인, 보안 정책, UX 표준을 따르도록 해 주세요. 엔지니어링 팀에 바로 넘길 수 있도록 명세 전체를 spec.md로 문서화해 주세요. 우려되는 부분, 특히 서로 충돌하는 정책을 모두 만족시킬 수 없는 부분은 분명하게 설명해 주세요.

거버넌스 고려 사항

몇 주 뒤 리뷰에서야 정책을 확인하는 것이 아니라, 명세를 작성하는 동안 현행 정책을 읽고 적용합니다. 조직의 스킬은 명세에 제약으로 적용됩니다. 명세, 그 명세를 만든 프롬프트, 당시 적용된 스킬 버전은 모두 버전 관리 시스템에 기록됩니다. 프로덕트 오너가 명세를 승인하고, 표시된 우려 사항은 지정된 정책 담당자에게 넘깁니다.

측정 방법

선행 지표: 같은 변경에 대한 intent.md 커밋과 spec.md 커밋 사이의 경과 시간(git 타임스탬프 두 개)입니다. 이를 예전의 요구사항·설계 주기와 비교합니다.
후행 지표: 빌드가 시작된 뒤에 발생한 요구사항 재작업입니다. 같은 변경에 대해 첫 plan.md 커밋보다 나중 날짜로 된 spec.md 커밋 수를 셉니다. git 로그에서 바로 확인할 수 있습니다.

03. 빌드

승인된 계획 없이는 아무것도 구현하지 않습니다. 조직에 쌓인 지식은 에이전트가 읽는 파일이 되고, 가드레일은 습관이 아니라 코드로 실행됩니다.

Claude Code 계획 모드를 기본 출발점으로

엔지니어는 Claude Code 세션을 계획 모드(plan mode)로 시작해 2단계: 설계에서 승인된 spec.md를 Claude에게 건넵니다. 그리고 Claude가 엔지니어에게 질문하게 하면서, 엔지니어가 만족할 때까지 계획을 반복해서 다듬습니다.

기존 방식 AI 네이티브 방식

엔지니어는 설계를 읽고 코드를 작성하기 시작합니다. 어떤 파일과 어떤 테스트를 건드릴지까지 포함해, 변경을 어떻게 할지는 엔지니어의 머릿속에만 있거나 잘해야 티켓 댓글에 남습니다. 다른 사람은 이를 리뷰할 수 없습니다. 리뷰어가 처음 보는 것은 완성된 diff이고, 그때는 재작업에 시간이 많이 걸립니다. 작업은 Claude가 계획 모드에서 작성한 계획서로 시작합니다. 계획 모드에서 Claude는 아무것도 바꾸지 않고 코드베이스를 읽을 수 있습니다. 엔지니어는 코드를 작성하기 전에 계획을 바로잡고, 승인된 버전을 plan.md로 커밋해 이후 단계에서 대조할 수 있게 합니다.

기존 방식	AI 네이티브 방식
엔지니어는 설계를 읽고 코드를 작성하기 시작합니다. 어떤 파일과 어떤 테스트를 건드릴지까지 포함해, 변경을 어떻게 할지는 엔지니어의 머릿속에만 있거나 잘해야 티켓 댓글에 남습니다. 다른 사람은 이를 리뷰할 수 없습니다. 리뷰어가 처음 보는 것은 완성된 diff이고, 그때는 재작업에 시간이 많이 걸립니다.	작업은 Claude가 계획 모드에서 작성한 계획서로 시작합니다. 계획 모드에서 Claude는 아무것도 바꾸지 않고 코드베이스를 읽을 수 있습니다. 엔지니어는 코드를 작성하기 전에 계획을 바로잡고, 승인된 버전을 `plan.md`로 커밋해 이후 단계에서 대조할 수 있게 합니다.

시작하기

선행 조건: 인텐트 산출물(intent.md 또는 spec.md)이 있다면 그것이 필요하고, CLAUDE.md 파일이 있으면 도움이 됩니다.
인프라: 리포지토리에 접근할 수 있는 Claude Code가 필요합니다.

실행 방법

엔지니어가 Claude와 함께 계획 모드로 세션을 시작합니다.
엔지니어는 Claude에게 intent.md와 spec.md를 주고, 변경되는 파일, 작업 순서, 변경을 증명할 테스트를 명시한 구현 계획을 요청합니다.
이 변경이 무엇을 망가뜨릴 수 있는지, 어느 단계가 가장 위험한지, Claude가 택하지 않은 다른 방법은 무엇인지 물으며 계획을 꼼꼼히 따져 봅니다.
대화를 한 번도 보지 못한 엔지니어도 계획만 보고 변경을 구현할 수 있을 때까지 반복합니다.
승인된 계획을 plan.md로 커밋합니다. 계획은 감사 추적 기록에 포함되고, PR 리뷰 플레이(5단계: 배포)에서 최종 diff를 이 계획과 대조합니다.
계획을 수락하고 Claude에게 구현을 맡깁니다. 계획이 탄탄하면 한 번에 구현되는 경우가 많습니다.
구현이 계획에서 벗어나면 같은 커밋에서 plan.md를 업데이트합니다. 훅을 사용해 두 파일이 항상 맞춰지도록 강제하는 방법도 고려해 보세요.

예시(plan.md)

# 계획: 보험금 청구 진행 상태 셀프서비스 (2026-06-02 intent.md 기반)

## 변경되는 파일
portal/src/claims/StatusPanel.tsx (신규), claims-api/routes/status.py,
claims-api/tests/test_status.py

## 작업 순서
1. 기존 인증 뒤에 상태 엔드포인트를 추가합니다.
2. 엔드포인트를 사용하는 패널을 만듭니다.
3. 포털 내비게이션에 연결합니다.

## 위험 요소
claims-core API는 초당 50건(50 rps)으로 요청을 제한하므로 패널에서 캐시해야 합니다.

## 검증
test_status.py가 네 가지 청구 상태를 모두 다루고, 스크린샷이
승인된 목업과 일치합니다.

거버넌스 고려 사항

설계 리뷰는 코드가 생성되기 전, 방향을 바꾸려면 문서만 고치면 되는 시점에 이루어집니다. 계획 모드는 이를 자체적으로 강제합니다. 엔지니어가 계획을 수락하기 전까지 Claude는 파일을 수정할 수 없기 때문입니다. 계획과 그 수정본은 누가 수락했는지와 함께 기록됩니다. 일상적인 변경은 엔지니어가 승인하고, 조직이 고위험으로 분류하는 변경은 기술 리드나 아키텍트에게 넘어갑니다.

측정 방법

선행 지표: 첫 구현에서 바로 병합되는 변경의 비율, 그리고 계획 승인부터 PR 병합까지 걸린 시간입니다. 필요한 데이터는 PR 메타데이터에 담겨 있어야 합니다.
후행 지표: 변경당 재작업 횟수(이것도 PR 메타데이터에서 확인합니다)와, 병합된 diff가 커밋된 plan.md와 여전히 일치하는 빈도입니다.

자동 모드로 실행하는 Claude Code

Claude Code는 자동 모드로도 실행할 수 있습니다. 엔지니어가 계획을 반복해 다듬고 만족해서 승인하면, Claude는 수정할 때마다 확인을 묻지 않고 각 변경을 적용합니다. 이후 플레이에서 다루는 가드레일(잘 다듬은 CLAUDE.md, 정책을 담은 스킬, 안전하지 않은 행동을 차단하는 훅, Claude가 실행할 수 있는 테스트 스위트)이 성숙해지면, 일상적인 작업에서는 자동 수락이 기본값이 됩니다. 여기서 일상적인 작업이란 spec.md가 빈틈없고, 영향 범위가 작고, 테스트가 이미 다루는 코드를 말합니다.

이제 중심은 사용자가 에이전트의 수정을 지켜보며 행동 하나하나를 리뷰하는 것에서, 더 오래 자율적으로 진행된 세션이 끝난 뒤 산출물을 리뷰하는 것으로 옮겨 갑니다. 자동 수락 모드를 워크트리와 함께 쓰면 개인과 팀 전체에서 병렬 작업이 더 쉬워집니다. 또한 6단계: 유지보수에서 설명하는 것처럼 SDLC를 자율적으로 실행하고 루프를 닫는 데 꼭 필요합니다.

참고

레거시 시스템과 기준 원본

프로세스가 만들어 내는 모든 산출물에 적용됩니다.

기존 SDLC 프로세스는 아마 이미 산출물을 추적하고 있을 것입니다. 다만 마크다운 파일로 하지 않을 뿐입니다. 작업 항목은 Jira에, 요구사항은 규제 추적 기능이 내장된 도구에, 디자인은 Figma에 있고, 변경 승인은 변경 심의 위원회를 거칠 수 있습니다. 감사인과 규제 기관이 이미 이 시스템들을 인정하고 있고 다른 팀들도 이에 의존하고 있어서, 이 시스템들은 대체하기가 어렵습니다. 따라서 AI 네이티브 SDLC는 기존 시스템에 맞춰 들어가야 합니다.

AI 네이티브 SDLC로 전환할 때는 프로세스가 만들어 내는 산출물마다 한 시스템을 기준 원본(source of truth)으로 정하고, 나머지 시스템은 원본의 사본이나 링크만 갖게 합니다. 아래 구성 중 하나로 기준 원본을 하나로 정할 수 있으며, 산출물마다 다른 구성을 선택할 수 있습니다.

리포지토리를 기준 원본으로 삼는 방식. 마크다운 산출물이 공식 기록이 되고, 레거시 시스템은 커밋 안의 파일을 참조합니다. 모든 기록이 하나의 도구에 하나의 타임스탬프 기준으로 남기 때문에, 엔지니어링 중심 조직에서는 가장 깔끔한 구성 중 하나가 될 수 있습니다.

레거시 시스템을 기준 원본으로 삼는 방식. Jira, ServiceNow, 또는 요구사항 관리 도구가 공식 기록을 보관하고, 마크다운 산출물은 작업용 사본이 됩니다. Claude는 세션을 시작할 때 기록을 읽고, 명세나 계획을 만든 바로 그 세션에서 MCP 커넥터를 통해 결과를 다시 기록합니다.

최소 기준으로서의 연결. 모든 산출물에 기록 ID를 적고, 모든 레거시 기록에는 마크다운 파일의 커밋 SHA를 남깁니다. 기준 원본이 두 개가 된다는 점을 받아들인다면, AI 네이티브 SDLC로 전환할 때 연결부터 시작하는 것이 좋습니다.

레거시 시스템과 마크다운 중심 시스템은 둘 사이에 연결 고리가 있거나 둘 중 하나를 기준 원본으로 선언하기만 하면 함께 쓸 수 있습니다.

CLAUDE.md

CLAUDE.md는 새로 합류한 사람에게 필요한 맥락을 Claude에게 줍니다. 규칙, 명령어, 아키텍처, 그리고 팀이 가장 자주 마주치는 실수가 여기에 담깁니다. 예전에는 사람들 머릿속과 위키에 있던 지식이, 에이전트가 세션을 시작할 때마다 읽는 파일이 됩니다. 이 파일은 팀 전체가 관리하고, 실수가 생길 때마다 고쳐 나갑니다.

시작하기

선행 조건: 없습니다.
인프라: 리포지토리, 설치된 Claude Code, 그리고 코드베이스를 잘 아는 엔지니어 한 명이 필요합니다.

실행 방법

리포지토리에서 /init을 실행합니다. Claude가 리포지토리에서 찾은 내용으로 초기 CLAUDE.md를 만듭니다.
생성된 파일을 새로 합류한 사람이 첫날 알아야 할 내용으로 줄입니다. 빌드·테스트·린트 명령어, 중요한 규칙, Claude가 계속 틀리는 내용은 남깁니다.
CLAUDE.md를 리포지토리 루트에 두고 git에 체크인합니다. 그래야 팀 전체가 한 버전을 공유하고, 변경 사항도 코드처럼 리뷰됩니다.
이때 도움이 되는 작업 규칙이 있습니다. Claude가 같은 실수를 두 번 하면 그 수정 내용을 CLAUDE.md에 넣는 것입니다.
한 페이지 이내로 유지합니다. Claude는 세션을 시작할 때 파일 전체를 읽기 때문에, 오래된 내용은 아무 이득 없이 컨텍스트만 차지합니다.

예시(CLAUDE.md)

# 결제 서비스

## 명령어
- 빌드: make build
- 테스트: make test (단위), make itest (통합, docker 필요)
- 린트: make lint (CI에서 실행되니 푸시 전에 수정하세요)

## 규칙
- Java 21, Spring Boot 3을 사용합니다. Lombok은 새로 도입하지 않습니다.
- 금액은 항상 BigDecimal로 다루고, double은 절대 쓰지 않습니다.
- 모든 엔드포인트에는 src/itest에 통합 테스트가 있어야 합니다.

## 아키텍처
- api/에는 REST 컨트롤러, core/에는 도메인 로직이 있고,
  adapters/는 외부 시스템과 통신합니다.
- Kafka 이벤트는 schemas/에 정의되어 있습니다. 생성된 클래스는 절대 수정하지 마세요.

## Claude가 자주 틀리는 것
- 의존성 버전을 올리지 마세요. 의존성은 플랫폼 팀이 관리합니다.
- 레거시 v1/ 패키지는 동결되었습니다. 변경은 v2/에 하세요.

거버넌스 고려 사항

CLAUDE.md는 버전 관리되므로, 에이전트가 따르는 지침을 리뷰하고 감사할 수 있습니다. 팀의 규칙은 이 파일을 통해 적용되고, 파일의 변경 사항은 git 이력에 기록되며, 코드 소유자가 PR 리뷰에서 그 변경을 승인합니다.

측정 방법

선행 지표: CLAUDE.md가 막았어야 할 실수를 Claude가 얼마나 자주 반복하는지 봅니다. CLAUDE.md의 수정이나 변경은 git 이력으로 추적해야 합니다.
후행 지표: 새 팀원이 첫 PR을 병합하기까지 걸리는 시간입니다. PR 이력에서 확인합니다.

조직의 지식을 담은 스킬

스킬은 조직에 쌓인 지식을 실제 업무에 적용하는 수단입니다. 스킬에 담긴 지침은 명시적이고, 버전 관리되며, 폭넓게 적용되고, 정책이 바뀌면 중앙에서 업데이트됩니다. 경험칙은 이렇습니다. 일관되게 적용해야 하는 조직의 지식은 스킬로 작성하고, CLAUDE.md나 프롬프트에 들어가야 할 내용은 스킬로 만들지 않습니다.

시작하기

선행 조건: 필수 조건은 없습니다. CLAUDE.md가 있으면 에이전트의 작업 지식을 리포지토리 안에 둘 수 있어 도움이 되지만, 스킬이 여기에 의존하지는 않습니다.
인프라: 지정된 담당자와 문서화된 기준 원본이 있는 정책 하나가 필요합니다.

실행 방법

지금 일관되지 않게 적용되고 있는 지식 하나를 고릅니다. 보안 표준, API 설계 규칙, 브랜드 규칙 등이 될 수 있습니다.
그 지식을 스킬로 작성합니다. 스킬은 SKILL.md가 들어 있는 폴더로, 프런트매터에는 언제 작동하는지를, 본문에는 무엇을 해야 하는지를 적습니다. 엔지니어가 정책 담당자의 기준 원본을 바탕으로 Claude의 도움을 받아 작성합니다.
스킬을 리포지토리의 .claude/skills/<name>/에 두어 코드와 함께 배포하거나, 플러그인을 통해 조직 전체에 배포합니다.
스킬이 제대로 작동하는지 테스트합니다. 관련 작업을 여러 방식으로 Claude에게 요청하고, 매번 스킬이 로드되는지 확인합니다.
정책이 바뀌면 스킬을 수정하고, 그 변경을 정책 담당자에게 승인받습니다.
엔지니어들은 다음 세션부터 새 버전을 자동으로 사용하게 됩니다.

예시(.claude/skills/secure-api-review/SKILL.md)

---
name: secure-api-review
description: API 보안 표준을 적용합니다. 외부에 노출되는 엔드포인트를
  만들거나 수정할 때, API 코드를 리뷰할 때, OpenAPI 명세를
  생성할 때마다 사용하세요.
---
# 보안 API 리뷰

API 엔드포인트를 만들거나 변경할 때는 다음을 지키세요.
1. 인증: 모든 엔드포인트는 게이트웨이 JWT를 요구해야 합니다.
   /health 외에는 익명 경로를 두지 않습니다.
2. 입력 검증: 요청 본문을 OpenAPI 스키마로 검증하고,
   알 수 없는 필드는 거부합니다.
3. 감사: 상태를 바꾸는 모든 엔드포인트는 행위자, 행동, 엔터티,
   타임스탬프를 담은 감사 이벤트를 발행해야 합니다.
4. 데이터 분류: 스키마에서 pii 태그가 붙은 필드는 로그나 오류
   메시지에 절대 나타나서는 안 됩니다.

scripts/check-endpoints.sh를 실행하고, 그 출력을 요약에 포함하세요.

거버넌스 고려 사항

스킬은 통제 장치이지만, 권고 수준의 통제입니다. 스킬이 있으면 Claude가 코드를 작성하는 동안 정책을 적용할 가능성이 높아지지만, 세션이 반드시 이를 따르도록 강제하는 것은 없습니다. 항상 지켜져야 하는 정책이라면 스킬 뒤에 결정론적인 장치가 있어야 합니다. 해당 행동을 차단하는 훅이나, PR 단계에서 정책을 다시 확인하는 리뷰 패스가 그 예입니다. 스킬은 위반을 드물게 만들고, 훅은 위반을 거의 불가능하게 만듭니다. 스킬 호출은 세션 트레이스에 기록되고, 정책 담당자는 스킬 변경을 코드처럼 리뷰합니다.

측정 방법

선행 지표: 정책 담당자가 정책 변경을 승인한 시점부터 업데이트된 스킬이 병합될 때까지 걸린 시간입니다. 스킬 폴더에 대한 PR에서 확인합니다.
후행 지표: 해당 정책을 근거로 든 PR 리뷰 지적 사항의 수입니다. 코드를 작성하는 동안 스킬이 정책을 적용하기 시작하면 이 수는 0에 가까워져야 합니다. 0에 가까워지지 않는다면, 스킬이 작동하지 않고 있거나 스킬의 내용이 공식 정책과 어긋나기 시작한 것입니다.

빌드 단계의 가드레일로서의 훅

스킬이 권고 수준의 통제라면, 훅은 그 뒤를 받치는 결정론적인 계층입니다. 구현 중에 Claude가 하는 행동은 대부분 파일 수정과 셸 명령이므로, 훅이 가장 자주 실행되는 곳은 결국 빌드 단계가 됩니다.

빌드 단계의 훅은 다음과 같은 일을 할 수 있습니다.

생성된 클래스나 동결된 패키지 같은 보호 경로의 수정을 차단합니다.
파일을 수정한 뒤 포매터와 린터를 실행해, 코드 스타일이 어긋난 채로 쌓이지 않게 합니다.
자격 증명이 diff에 들어가지 않게 합니다.

예외 없이 지켜져야 하는 정책을 담은 스킬은 모두 훅으로 뒷받침하세요. 훅은 조건에 맞는 행동마다 실행되므로, 빌드 단계의 훅은 빨라야 하고 변경된 파일로 범위가 한정되어야 합니다. 전체 테스트 스위트처럼 무거운 검사는 커밋이나 PR 단계에서 실행해야 합니다.

사람에게 승인을 요청하는 훅은 5단계: 배포의 게이트들과 함께 둬야 합니다. 빌드 중에 승인 요청이 뜨면, 병렬로 실행 중인 모든 세션의 핵심 경로에 다시 사람이 끼어들게 되기 때문입니다.

병렬 세션과 서브에이전트

엔지니어 한 명이 여러 갈래의 작업을 동시에 진행할 수 있습니다.

병렬 세션은 또 하나의 완전한 Claude Code 인스턴스로, 자신만의 git 워크트리에서 별도의 작업을 수행합니다. 독립된 각 세션은 다른 세션에 대해 전혀 모르며, 세션들이 공유하는 것은 그 세션들을 조종하는 엔지니어뿐입니다.

서브에이전트는 한 세션 안에서 실행되는, 범위가 한정된 도우미입니다. 자체 컨텍스트 창과 도구 제한을 가지며, 앱이 예상대로 동작하는지 검증하는 일처럼 여러 작업에서 반복되는 일에 알맞습니다.

병렬 세션은 엔지니어가 동시에 진행할 수 있는 작업 수를 늘리고, 서브에이전트는 각 세션이 자기 작업에 집중하게 해 줍니다. 엔지니어가 할 일은 이 모든 것을 조종하고 리뷰하는 것입니다.

기존 방식	AI 네이티브 방식
엔지니어 한 명은 한 번에 작업 하나를 맡고, 하루나 일주일 중 상당 부분을 빌드와 테스트, 리뷰어를 기다리는 데 씁니다. 기다리는 동안 다른 작업으로 전환할 수는 있지만, 맥락을 전환하는 일이 꽤 피곤하기 때문에 그렇게 하는 사람은 많지 않습니다.	엔지니어 한 명이 여러 Claude 세션을 동시에 실행합니다. 각 세션은 자기 워크트리에서 자기 작업을 맡습니다. 반복되는 일은 자체 컨텍스트와 도구 제한을 가진 서브에이전트가 맡습니다. 엔지니어의 일은 오케스트레이션으로 바뀌고, 결국에는 루프를 만들고 모니터링하는 일로 바뀝니다.

시작하기

선행 조건: 모든 세션이 읽는 파일이므로 CLAUDE.md가 필요합니다. 피드백 루프(4단계: 테스트)도 도움이 됩니다. 세션이 스스로 작업을 검증할 수 있으면 엔지니어가 덜 감독해도 되기 때문입니다.
인프라: 격리는 워크트리로 이루어지므로 git 리포지토리가 필요합니다. 또한 조직이 안전하다고 보는 명령어에 대해서는 세션이 승인 요청을 기다리지 않도록 권한 설정을 조정해 두어야 합니다.

실행 방법

엔지니어는 계획 모드 플레이(3단계: 빌드)에서 만든 계획을 보고 서로 독립적인 작업이 어디인지 파악한 뒤, 작업을 서로 다른 파일을 건드리는 단위로 나눕니다. 파일을 공유하는 작업은 한 세션에서 차례로 진행합니다.
병렬 작업마다 자체 워크트리를 둡니다. 예를 들어 한 터미널에서는 claude --worktree feature-auth를, 다른 터미널에서는 claude --worktree fix-rate-limit를 실행합니다. 워크트리는 자기 브랜치를 가진 별도의 체크아웃이므로 세션끼리 파일이 충돌하지 않습니다.
처음에는 세션 두세 개로 시작하는 것이 적당합니다. 현실적인 상한은 한 사람이 제대로 리뷰할 수 있는 작업 갈래의 수이므로, 리뷰가 따라가는 동안에만 세션을 늘리세요.
반복되는 일은 서브에이전트로 만듭니다. 서브에이전트는 .claude/agents/에 있는 마크다운 파일로 정의하며, 각 파일에는 이름, 언제 사용하는지에 대한 설명, 사용할 수 있는 도구를 적습니다. 예를 들어 메인 에이전트가 작업을 마친 뒤 불필요한 복잡성을 걷어 내는 코드 단순화 에이전트, 앱을 실행해 동작을 확인하는 검증 에이전트, 메인 컨텍스트를 넘치게 하지 않으면서 코드베이스를 탐색하고 결과를 보고하는 조사 에이전트가 있습니다. 팀 전체가 공유할 수 있도록 정의 파일을 git에 체크인하세요.

예시(.claude/agents/verifier.md)

---
name: verifier
description: 세션이 완료를 보고하기 전에 앱을 실행해 변경이 제대로
  동작하는지 확인합니다
tools: Bash, Read
---
make run으로 앱을 시작하세요. 변경된 동작과, 가장 가까이 인접한 흐름
두 개를 실행해 보세요. 무엇을 실행했는지, 무엇을 봤는지, plan.md와
일치하지 않는 동작이 있는지 보고하세요. 아무것도 고치지 말고 보고만 하세요.

거버넌스 고려 사항

세션이 많아지면 산출물도 많아지므로, 통제는 리포지토리의 설정에서 이루어져야 합니다. 리포지토리에 있는 훅과 권한 설정은 모든 세션에 적용되고, 세션이 한 일은 기록되며 그 세션을 실행한 엔지니어에게 귀속됩니다.

측정 방법

선행 지표: 리뷰 품질을 유지하면서 엔지니어 한 명이 동시에 운영하는 세션 수(OpenTelemetry 내보내기 데이터로 집계), 그리고 하루 중 기다리지 않고 세션을 조종하는 데 쓴 시간의 비율입니다.
후행 지표: 엔지니어 한 명이 일주일에 병합하는 변경 수입니다. PR 이력으로 산출한 재작업 비율과 함께 봅니다.

04. 테스트

모든 세션은 사람이 보기 전에 자기 작업을 직접 확인합니다. 에이전트를 조종하는 설정도 에이전트가 작성하는 코드처럼 회귀 테스트를 거칩니다.

Claude에게 피드백 루프 주기

테스트든, 빌드든, 스크린샷 비교든, Claude가 자기 작업을 검증할 수단을 항상 마련해 주세요. 그러면 세션은 엔지니어가 보기 전에 스스로 작업을 확인하고 실수를 고칩니다.

피드백 루프를 검증 서브에이전트(3단계: 빌드)와 혼동하면 안 됩니다. 피드백 루프는 작업 전체에 걸쳐, 작업에 필요한 만큼 여러 번 실행됩니다. 반면 검증 서브에이전트는 최종 확인을 하나로 묶어 두는 방법 중 하나로, 세션이 작업을 마쳤다고 판단한 시점에 새 컨텍스트 창에서 한 번 실행됩니다. 이렇게 하면 코드를 만들어 낸 가정에 판정이 휘둘리지 않습니다.

기존 방식	AI 네이티브 방식
코드가 동작한다는 신호가 늦게 옵니다. CI는 몇 분 뒤, 테스터는 며칠 뒤, 프로덕션은 몇 주 뒤에야 알려 줍니다. 에이전트가 코드를 만드는 상황에서 신호가 늦다는 것은 사람이 에이전트의 결과물을 전부 확인해야 한다는 뜻이고, 결국 그 사람이 병목이 됩니다.	세션에는 사람이 보기 전에 자기 작업을 확인할 수단이 주어집니다. 테스트를 실행하고, 빌드를 실행하고, 스크린샷을 찍습니다. Claude는 확인을 통과할 때까지 반복하므로, 엔지니어에게 도달하는 결과물은 이미 확인을 통과한 상태입니다. 이 루프를 설정하는 일은 세션을 실행하는 엔지니어의 몫이며, 아래 단계는 그 엔지니어를 위해 쓴 것입니다.

기존 방식

AI 네이티브 방식

코드가 동작한다는 신호가 늦게 옵니다. CI는 몇 분 뒤, 테스터는 며칠 뒤, 프로덕션은 몇 주 뒤에야 알려 줍니다. 에이전트가 코드를 만드는 상황에서 신호가 늦다는 것은 사람이 에이전트의 결과물을 전부 확인해야 한다는 뜻이고, 결국 그 사람이 병목이 됩니다.

세션에는 사람이 보기 전에 자기 작업을 확인할 수단이 주어집니다. 테스트를 실행하고, 빌드를 실행하고, 스크린샷을 찍습니다. Claude는 확인을 통과할 때까지 반복하므로, 엔지니어에게 도달하는 결과물은 이미 확인을 통과한 상태입니다. 이 루프를 설정하는 일은 세션을 실행하는 엔지니어의 몫이며, 아래 단계는 그 엔지니어를 위해 쓴 것입니다.

시작하기

선행 조건: 없습니다.
인프라: 각각 명령어 하나로 로컬에서 실행되는 테스트 스위트와 빌드가 필요합니다. UI 작업이라면 Claude가 결과를 볼 수 있는 수단이 매우 중요합니다. 브라우저 도구나 MCP로 연결한 스크린샷 유틸리티가 그 예입니다.

실행 방법

지금 작업을 확인하려면 여러 명령어를 차례로 실행해야 하고 환경에 대한 지식도 어느 정도 필요하다면, 이를 "make test"나 "npm test"처럼 실패하면 0이 아닌 종료 코드를 반환하는 단일 타깃으로 묶습니다.
CLAUDE.md의 명령어 섹션에 각 명령어와 정상적인 출력 예시를 함께 적습니다.
Claude가 여러분에게 묻지 않고도 작업을 확인할 수 있도록 목표를 정하고, 측정할 수 있게 만듭니다. 예를 들면 "test_status.py의 모든 테스트 통과", "스크린샷이 첨부한 목업과 일치", "엔드포인트가 새 필드와 함께 200을 반환" 같은 식입니다.
버그 수정이라면 실패하는 테스트부터 작성합니다. Claude에게 버그를 테스트로 재현하게 하고, 테스트를 실행해서 예상한 이유로 실패하는지 확인합니다. 그 테스트를 커밋합니다. 그런 다음에야 테스트는 고치지 말고 테스트가 통과하게 만들라고 Claude에게 요청합니다. 이 제한은 마지막 단계에서 설명하는 테스트 파일 훅으로 강제합니다. 수정 전부터 있었고 에이전트가 고쳐 쓸 수 없었던 테스트는 버그가 사라졌다는 증거가 됩니다.
UI 작업이라면 시각적 확인으로 루프를 닫습니다. Claude에게 브라우저나 스크린샷 도구와 목업을 주고 반복하게 합니다. 구현하고, 스크린샷을 찍고, 비교하고, 조정합니다. 두세 번 반복하는 것이 보통이며, 반복할 때마다 결과가 나아져야 합니다.
검증을 "완료"의 조건으로 삼습니다. 이 지침은 CLAUDE.md에 둡니다. 작업 완료를 보고하기 전에 테스트를 실행하고, 그 출력을 보여 주게 합니다.
마지막으로 루프 자체를 보호해야 합니다. 코드를 고치는 에이전트가 그 코드에 대한 검사를 약하게 만들 수 있어서는 안 되기 때문입니다. 수정 작업 중에 테스트 파일 수정을 차단하는 훅이 이 역할을 합니다. 다른 방법은 리뷰에서 diff를 확인하고, 테스트를 건드린 변경은 모두 거부하는 것입니다.

예시(CLAUDE.md의 검증 블록)

## 작업 검증하기

- 빌드: make build ("Build succeeded"로 끝나야 합니다)
- 테스트: make test (모두 통과해야 합니다. 실패하는 테스트를 건너뛰거나 삭제하지 마세요)
- 린트: make lint (경고 0개)

작업 완료를 보고하기 전에 세 가지를 모두 실행하고, 출력을 붙여 넣으세요.
테스트가 실패하면 테스트가 아니라 코드를 고치세요.

거버넌스 고려 사항

강제하는 항목

작업 완료를 보고하기 전의 검증, 그리고 수정 작업 중 에이전트의 테스트 파일 수정 차단입니다. 조직이 이를 반드시 보장하려 한다면 둘 다 훅으로 구현합니다.

증거

Claude가 실행하고 붙여 넣은 "make test"의 출력 그대로, 빌드 로그, 또는 스크린샷 비교 결과입니다. 따라서 증거는 도구 체인에서 나옵니다.

기록 위치

세션 기록에 남고, OpenTelemetry 내보내기를 통해 조직의 관측성 스택으로 전달됩니다. PR의 체크 실행 결과에도 남으므로, 리뷰어와 나중의 감사인 모두 확인할 수 있습니다.

승인 주체

PR을 리뷰하는 코드 소유자입니다. 기계적인 증거가 이미 첨부되어 있으므로, 코드 소유자는 의도와 위험에 집중할 수 있습니다.

측정 방법

선행 지표: 에이전트가 작성한 변경의 첫 CI 통과율입니다. CI 시스템에서 이미 이 지표를 지원합니다.
후행 지표: PR당 리뷰 시간(PR 메타데이터에서 확인)입니다. 예전에 리뷰어가 잡던 문제를 테스트가 잡기 시작하면 이 시간은 줄어들어야 합니다. 장애 추적 시스템에서 확인하는 변경 실패율도 함께 봅니다.

CI에서 지속적으로 실행하는 평가

평가(eval)는 단계별 관문(stage-gate) 방식 QA의 AI 네이티브 버전입니다. 실제로는 에이전트의 설정이 바뀔 때마다 실행되는 평가 스위트를 말합니다. 새 모델로 교체하거나 프롬프트를 다시 쓰면, 평가 스위트가 에이전트가 여전히 같은 수준으로 일을 해내는지 알려 줍니다.

평가 스위트는 계속 갱신해야 하는 대상으로 봐야 합니다. 모델이 발전하면 한때 변별력이 있던 사례가 더 이상 변별력을 갖지 못하게 되므로, 지속적인 모니터링에서 나온 새 사례를 추가해야 합니다.

활용 사례에 따라 어떤 팀은 변경이 있을 때마다가 아니라 정해진 주기로 오프라인에서 평가를 실행하는 편을 선호할 수도 있습니다. 아래 단계는 지속적인 평가를 위한 것입니다.

시작하기

선행 조건: CLAUDE.md와 피드백 루프(4단계: 테스트)가 필요합니다.
인프라: Claude Code를 비대화형으로 실행할 수 있는 CI, 그리고 평가 실행에 쓸 예산이 잡힌 API 키가 필요합니다.

실행 방법

플랫폼 엔지니어가 최근 작업에서 실제 작업 20개에서 50개를, 기대한 결과 또는 수락된 결과와 함께 수집합니다.
각 작업을 평가로 작성합니다. 평가는 프롬프트, 그리고 수용 가능한 결과를 정의하는 검사(테스트 통과, 린트 오류 없음, 동작 변화 없음, 정책 준수)로 이루어집니다.
스위트는 정해진 일정에 따라, 그리고 CLAUDE.md, 스킬, 훅이 바뀔 때마다 CI에서 비대화형으로 실행됩니다. 이 설정이 에이전트를 조종하므로, 코드와 똑같이 회귀 테스트를 받아야 하기 때문입니다.
설정 변경은 평가 결과를 기준으로 통과 여부를 정합니다. 통과율을 떨어뜨리는 스킬 변경은 병합되기 전에 리뷰를 받습니다.
프로덕션 장애가 생길 때마다 그 장애를 담당했던 팀이 평가를 하나씩 작성하고, 이 평가는 회귀 테스트로 스위트에 계속 남습니다.

예시(.github/workflows/agent-evals.yml)

name: Agent evals
on:
  pull_request:
    paths: ['CLAUDE.md', '.claude/**']
  schedule:
    - cron: '0 2 * * *'
jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @anthropic-ai/claude-code
      - name: Run eval suite
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          for eval in evals/*.json; do
            claude -p "$(jq -r '.prompt' $eval)" \
              --allowedTools "Read,Edit,Bash(make test)" \
              --output-format json > result.json
            ./evals/check.sh "$eval" result.json
          done

거버넌스 고려 사항

평가는 QA에 에이전트의 산출 속도를 따라갈 수 있는 게이트를 마련해 줍니다. 통과율 기준은 병합 검사로 강제되고, 실행 결과는 기록되어 시간에 따라 비교할 수 있으며, 설정 변경은 그 설정을 담당하는 팀이 승인합니다.

측정 방법

선행 지표: 스위트가 실행될 때마다 보고하는 평가 통과율의 추이, 그리고 프로덕션 장애가 영구적인 평가로 자리 잡기까지 걸리는 시간입니다.
후행 지표: CI에서 잡아낸 회귀와 프로덕션에서 발견된 회귀를 비교합니다. 프로덕션 회귀는 장애 추적 시스템에서 가져옵니다.

05. 배포

리뷰는 양방향으로 이루어지고, 거버넌스는 에이전트가 행동하는 시점에 집행됩니다. 에이전트는 프로덕션 게이트 직전까지 모든 일을 하고, 게이트를 넘어서는 일은 하지 않습니다.

PR 리뷰 루프 안의 AI

Claude는 리뷰를 하기도 하고 받기도 합니다. 들어오는 PR을 조직의 정책에 비춰 리뷰하고, 자신이 연 PR에 달린 리뷰 댓글을 처리합니다. 덕분에 엔지니어는 PR 리뷰에서 동작에 집중할 수 있고, 이는 결국 의도와 위험을 판단하는 일로 귀결됩니다.

기존 방식	AI 네이티브 방식
리뷰 역량은 사람의 산출량에 맞춰 계획되었습니다. PR은 리뷰어가 전부 읽을 때까지 기다리고, 리뷰 품질은 리뷰어의 업무량에 따라 들쭉날쭉하며, 백로그가 쌓이는 동안 작성자는 리뷰를 독촉하러 다닙니다.	모든 PR이 똑같은 리뷰 패스를 거치고, 지적 사항은 심각도순으로 정리됩니다. 사람의 주의는 한 단계 위로 올라가, 변경이 계획한 의도대로 동작하는지, 위험이 수용 가능한지를 판단하는 데 쓰입니다.

시작하기

선행 조건: 3단계: 빌드에서 업데이트한 CLAUDE.md 파일이 필요합니다. 리뷰 패스가 문서화된 정책을 강제한다면 스킬도 필요하고, 정의된 서브에이전트도 있어야 합니다.
인프라: Claude 연동이 설치된 리포지토리가 필요합니다. 관리자가 활성화하는 관리형 Code Review(리서치 프리뷰) 서비스를 쓰거나, 자체 CI에서 claude-code-action을 실행하면 됩니다. 필요하다면 AWS Bedrock, Google Vertex, Microsoft Foundry를 통해 모델을 호출할 수 있습니다(배포 방식은 CI/CD 플레이에서 다룹니다). 코드 소유자의 승인을 요구하는 브랜치 보호 정책도 두는 것이 좋습니다.

실행 방법

가장 빨리 시작하는 방법은 관리형 Code Review 서비스입니다. 관리자가 서비스를 활성화하고 리포지토리를 선택하면 됩니다. 파이프라인을 직접 통제해야 하거나 API 호출을 자체 클라우드 계약을 통해 보내고 싶다면, 자체 CI에서 claude-code-action으로 리뷰를 실행하세요(필요한 연결 작업은 CI/CD 플레이에서 다룹니다).
기술 리드가 리포지토리 루트에 REVIEW.md로 리뷰 정책을 작성합니다. 정책은 조직이 중요하게 여기는 패스별로 나눕니다. 버그와 논리 오류, 보안과 취약점, 그리고 명세(요구사항 플레이의 spec.md), 구현 계획(계획 모드 플레이의 plan.md), 설계 원칙을 지켰는지 확인하는 준수 여부입니다. REVIEW.md에는 무엇이 Nit이 아니라 Important로 분류되는지, 무엇을 건너뛸지도 정의합니다.
기술 리드가 사람이 판단할 기준을 정합니다. 지적 사항만으로 PR이 승인되거나 차단되지는 않으며, 브랜치 보호 정책은 여전히 코드 소유자의 승인을 요구합니다. 지적 사항에 따라 병합을 막고 싶은 플랫폼 엔지니어는 체크 실행이 기계 판독용 집계로 게시하는 심각도별 개수를 읽어 활용할 수 있습니다.
리뷰어나 작성자가 리뷰 댓글에 @claude를 태그하면, Claude가 그 댓글을 처리하고 수정 사항을 푸시합니다. PR 스레드에는 요청과 변경이 모두 기록됩니다. 이 수정 루프는 claude-code-action을 통해 실행됩니다. 관리형 서비스에서는 @claude review라고 댓글을 달면 대신 새 리뷰를 요청하게 됩니다. Claude가 연 PR이라면 한 걸음 더 나아가, 병합될 때까지 Claude가 PR을 돌보게 하세요. 팀들은 이 루프를 커스텀 슬래시 명령으로 감싸 둡니다. 이 명령은 PR에서 해결되지 않은 리뷰 댓글과 실패한 체크를 훑어서 처리하고 수정 사항을 푸시하는 일을, PR이 모두 통과하고 코드 소유자의 승인만 남을 때까지 반복합니다.
리뷰 지적 사항은 CLAUDE.md에 다시 반영됩니다. 리뷰에서 같은 실수가 두 번째로 지적되면, 그 리뷰의 일부로 수정 내용을 CLAUDE.md에 넣습니다. 리뷰도 CLAUDE.md를 읽기 때문에, 다음 PR부터는 그 실수를 잡아냅니다. 또한 리뷰는 어떤 변경 때문에 CLAUDE.md가 낡게 되었을 때도 이를 지적합니다.
기술 리드는 한 달에 한 번 설정을 조정합니다. 지적 사항을 평가해 리뷰어가 나아지게 하고, REVIEW.md에서 Nit의 양을 제한합니다. 생성된 경로와 CI가 이미 강제하는 항목은 제외합니다.

예시(REVIEW.md)

# 리뷰 지침

## 패스
세 가지 패스를 실행하고, 각 지적 사항에 해당 패스를 태그하세요.
- 버그: 논리 오류, 깨진 엣지 케이스, 눈에 잘 띄지 않는 회귀
- 보안: 인젝션 위험, 인증 공백, 로그에 남은 PII
- 컴플라이언스: 변경이 spec.md, plan.md, 설계 원칙과 일치하는지

## 여기서 Important의 의미
Important는 동작을 망가뜨리거나, 데이터를 유출하거나, 정책을 위반하는
지적 사항에만 쓰세요. 스타일과 이름 짓기는 nit입니다.

## nit 개수 제한
리뷰 한 번에 nit은 최대 다섯 개까지만 보고하고, 나머지는 개수로 요약하세요.

## 보고하지 않을 것
src/gen/ 아래의 생성된 파일, 그리고 CI가 이미 강제하는 모든 항목.

거버넌스 고려 사항

코드를 작성한 에이전트는 그 코드를 승인할 방법이 없으므로 직무 분리가 유지됩니다. REVIEW.md의 리뷰 정책은 모든 PR에 적용되고, 지적 사항, 수정, 평가, 승인은 PR 이력에 기록됩니다. 따라서 PR 자체가 감사 기록이 됩니다. 승인은 지적 사항을 참고한 사람이 브랜치 보호를 통해 합니다.

이런 통제 장치가 프로덕션 규모에서 어떻게 맞물리는지는 Anthropic이 AI 네이티브 SDLC를 보호하는 방법을 참고하세요.

측정 방법

선행 지표: 첫 리뷰까지 걸리는 시간(몇 분으로 줄어들어야 합니다), 그리고 사람이 브랜치를 건드리지 않고 해결된 리뷰 댓글의 비율입니다. 데이터는 Git에 바로 저장됩니다.
후행 지표: 병합 전에 잡아낸 결함과 취약점을 프로덕션까지 새어 나간 것과 비교합니다. PR 이력과 장애 추적 시스템에서 가져옵니다.

승인 게이트로서의 훅

빌드 단계에서는 훅을 가드레일로 써서, 사람이 개입하지 않고 행동을 허용하거나 차단했습니다(3단계: 빌드). 훅은 승인을 물을 수도 있습니다. 특정인이 승인할 때까지 행동을 멈춰 두는 것인데, 릴리스 게이트에 필요한 것이 바로 이 기능입니다.

이 플레이를 5단계: 배포에 둔 것은 릴리스 게이트가 가장 분명한 사례이기 때문입니다. 하지만 훅은 배포에만 쓰이는 것이 아니라, Claude가 행동하는 곳이라면 어디서든 실행됩니다. 예를 들어 3단계: 빌드에서는 변경 티켓 없이 마이그레이션과 인프라를 수정하는 것을 막을 수 있고, 4단계: 테스트에서는 수정 작업 중 에이전트가 테스트 파일을 고치지 못하게 할 수 있습니다.

시작하기

선행 조건: 없습니다.
인프라: 변경 프로세스에서 요구하는 승인 목록을 문서로 정리해 두어야 합니다.

실행 방법

엔지니어링 리더십이 변경 관리 및 컴플라이언스 담당자와 함께, 반드시 남겨야 할 사람의 승인 게이트 목록을 정합니다. 변경 관리 승인, 릴리스 승인, 보호 경로 수정 같은 것들입니다.
플랫폼 엔지니어가 각 게이트를 훅으로 구현합니다. 훅은 Claude가 행동하기 전에 실행되는 스크립트로, 행동을 허용하거나, 승인을 묻거나, 차단할 수 있습니다.
팀 훅은 git에 있는 .claude/settings.json에 두고, 양보할 수 없는 훅은 플랫폼 관리자나 IT 관리자가 소유한 관리형 설정에 둡니다. 관리형 설정에 있는 훅은 개별 엔지니어가 끌 수 없습니다.
차단할 때는 이유를 설명해야 합니다. 훅이 행동을 멈추면, 그 이유와 승인받는 경로가 Claude의 출력에 나타나도록 합니다.

예시(.claude/settings.json)

{
    "hooks": {
      "PreToolUse": [
        {
          "matcher": "Bash",
          "hooks": [
            { "type": "command",
              "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh" }
          ]
        }
      ]
    }
}

게이트 스크립트(.claude/hooks/production-gate.sh)

#!/bin/bash
# 프로덕션 배포에는 지정된 릴리스 승인이 필요합니다
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
   if [ -z "$RELEASE_APPROVAL" ]; then
     echo "프로덕션 배포에는 릴리스 승인이 필요합니다." >&2
     exit 2 # exit 2는 행동을 차단하며, 메시지는 Claude에게 전달됩니다
   fi
fi
exit 0

거버넌스 고려 사항

훅이 곧 승인 게이트입니다. 게이트 조건은 매번, 모든 사람에게 강제됩니다. 허용과 차단 결정은 타임스탬프와 함께 기록됩니다. 게이트는 무엇을 승인으로 인정할지도 정의합니다. 승인된 변경 티켓일 수도 있고, 릴리스 관리자의 승인일 수도 있습니다.

적용 예시: 규제 산업 기업을 위한 관리형 설정

플랫폼 팀이 MDM이나 관리 콘솔로 배포하며, 엔지니어는 이 중 어떤 것도 수정하거나 재정의할 수 없습니다.

{
  "permissions": {
    "deny": [
      "Read(.env*)",
      "Read(./secrets/**)",
      "WebFetch",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "allow": [
      "Bash(git *)",
      "Bash(make build)",
      "Bash(make test)",
      "Bash(make lint)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": [
        "git.internal.example.com",
        "registry.npmjs.org"
      ]
    },
    "credentials": {
      "files": [
        {
          "path": "~/.ssh",
          "mode": "deny"
        },
        {
          "path": "~/.aws/credentials",
          "mode": "deny"
        }
      ],
      "envVars": [
        {
          "name": "GITHUB_TOKEN",
          "mode": "deny"
        }
      ]
    }
  },
  "allowManagedHooksOnly": true,
  "disableSideloadFlags": true,
  "allowManagedMcpServersOnly": true,
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "example-corp/approved-plugins"
    }
  ],
  "requiredMinimumVersion": "2.1.193"
}

통제 관점에서 본 각 줄의 효과

permissions.deny는 비밀 정보가 에이전트의 컨텍스트에 들어가지 않게 하고, 도구를 통한 임의의 네트워크 외부 전송을 차단합니다. permissions.allow는 안전한 내부 작업 루프를 미리 승인해 두어, 거부 목록 때문에 승인 요청이 쏟아져 사람이 지치는 일이 없게 합니다.

disableBypassPermissionsMode와 allowManagedPermissionRulesOnly를 함께 쓰면, 어떤 엔지니어도, 어떤 프로젝트 파일이나 명령줄 플래그도 규칙을 넓힐 수 없습니다.

sandbox는 권한 설정으로 막을 수 없는 틈을 메웁니다. 도구 수준에서 WebFetch를 거부해도 셸 명령이 네트워크에 접근하는 것까지 막지는 못하지만, OS 수준의 도메인 허용 목록은 외부 전송 자체를 차단합니다.

failIfUnavailable과 allowUnsandboxedCommands는 샌드박스를 게이트로 만듭니다. 샌드박스를 초기화할 수 없으면 Claude Code는 시작을 거부하고, 샌드박스 안에서 실패한 명령은 샌드박스 밖에서 다시 시도할 수 없습니다.

credentials는 거부 규칙이 남겨 둔 틈을 메웁니다. permissions.deny는 Claude의 파일 도구를 통제하지만, 샌드박스 안의 셸 명령은 기본적으로 여전히 ~/.ssh나 ~/.aws/credentials를 읽을 수 있습니다. 이 블록은 그런 읽기를 거부하고, 샌드박스에서 실행되는 모든 명령의 환경에서 지정된 비밀 정보를 제거합니다.

allowManagedHooksOnly를 쓰면 이 플레이의 승인 게이트만 훅으로 실행되고, 로컬에서는 어떤 훅도 추가하거나 대체할 수 없습니다.

disableSideloadFlags와 strictKnownMarketplaces를 쓰면 엔지니어 컴퓨터에 있는 모든 스킬, 에이전트, 훅, MCP 서버가 조직이 승인한 플러그인 마켓플레이스를 통해서만 들어오고, 홈 디렉터리에서 들어오는 일은 없습니다.

allowManagedMcpServersOnly는 에이전트가 쓸 수 있는 도구 범위를 플랫폼 팀이 관리하는 허용 목록으로 만듭니다.

requiredMinimumVersion은 승인된 최소 버전보다 낮은 버전에서는 시작을 거부합니다. 따라서 통제 장치는 조직이 실제로 평가한 빌드에서 집행됩니다.

위 설정은 그대로 복사하라는 권장안이 아니라, 상황에 맞게 조정할 출발점으로 생각하세요. 거부 규칙을 하나 추가할 때마다 그만큼 기능을 포기하게 되며, 적절한 균형은 리포지토리의 데이터 등급에 따라 다릅니다. 설정 레퍼런스에는 관리형 설정 전용 키를 포함해 모든 키가 문서화되어 있습니다. code.claude.com/docs/en/settings

측정 방법(훅 자체)

선행 지표: 각 승인 게이트에서 기다리는 시간입니다. 모든 훅 결정은 타임스탬프와 허용 또는 차단 판정과 함께 OpenTelemetry 내보내기 데이터에 기록되므로, 게이트별 대기 시간을 확인할 수 있습니다.
후행 지표: 훅 도입 전후로 프로덕션까지 도달한 게이트 위반 건수입니다. 장애 추적 시스템에서 확인합니다.

CI/CD 통합과 배포

CI/CD 파이프라인 안에서 Claude Code를 비대화형으로 실행하고, 오래 실행되는 에이전트가 안전하게 돌 수 있도록 실행 환경을 샌드박스로 격리하세요. MCP 연동을 통해 배포 기능을 제공하고, 에이전트가 롤백 경로를 쓸 일이 생기기 전에 미리 연습해 두세요.

기존 방식	AI 네이티브 방식
파이프라인은 결정론적인 스크립트를 실행하고, 판단이 필요한 일은 모두 사람을 기다립니다. 불안정한 테스트(flaky test)를 분류하거나, 변경 로그를 작성하거나, 빌드가 왜 깨졌는지 알아내는 일이 그렇습니다. 배포와 롤백은 사람이 압박 속에서 따라 하는 런북입니다.	판단이 필요한 단계에서는 Claude가 파이프라인 안에서 비대화형으로 실행됩니다. 실행 환경은 샌드박스이고, 자격 증명은 범위가 한정되어 있습니다. 배포 도구는 MCP를 통해 에이전트에게 제공되므로, 변경을 작성하고 테스트한 워크플로가 조직이 환경별로 정한 게이트 안에서 그 변경을 배포하고 롤백까지 할 수 있습니다.

기존 방식

AI 네이티브 방식

파이프라인은 결정론적인 스크립트를 실행하고, 판단이 필요한 일은 모두 사람을 기다립니다. 불안정한 테스트(flaky test)를 분류하거나, 변경 로그를 작성하거나, 빌드가 왜 깨졌는지 알아내는 일이 그렇습니다. 배포와 롤백은 사람이 압박 속에서 따라 하는 런북입니다.

판단이 필요한 단계에서는 Claude가 파이프라인 안에서 비대화형으로 실행됩니다. 실행 환경은 샌드박스이고, 자격 증명은 범위가 한정되어 있습니다. 배포 도구는 MCP를 통해 에이전트에게 제공되므로, 변경을 작성하고 테스트한 워크플로가 조직이 환경별로 정한 게이트 안에서 그 변경을 배포하고 롤백까지 할 수 있습니다.

시작하기

선행 조건: PR 리뷰 루프 안의 Claude와 승인 게이트로서의 훅이 필요합니다. 자동화가 게이트를 거치는 작업을 가속하기 전에 게이트가 먼저 있어야 하기 때문입니다.
인프라: claude-code-action이 설치된 CI 플랫폼, 또는 claude -p를 호출할 수 있는 러너가 필요합니다. 모델은 API로 접근하거나, 트래픽이 조직의 클라우드 계약 안에 머물러야 한다면 Bedrock, Foundry, Vertex를 통해 접근합니다. 배포 대상을 위한 MCP 서버와, 상시 프로덕션 자격 증명이 없는 에이전트 작업용 샌드박스 프로필도 필요합니다.

실행 방법

플랫폼 엔지니어는 읽기 전용 판단 단계부터 시작합니다. 파이프라인 작업에서 claude -p를 사용해 실패한 빌드를 분류하거나, 불안정한 테스트를 요약하거나, 변경 로그 초안을 작성합니다.
린트 수정, 생성된 문서 업데이트, @claude 멘션을 통한 리뷰 댓글 처리 같은 작업에는 기존 게이트 뒤에 쓰기 단계를 추가합니다. 에이전트가 작성한 것은 모두 브랜치 보호를 거치는 PR로 들어오며, 에이전트가 main에 푸시할 경로는 없습니다.
실행은 샌드박스에서 이루어집니다. 에이전트 작업은 네트워크 정책이 적용된 컨테이너에서 수명이 짧고 범위가 한정된 토큰으로 실행되며, 기본적으로 프로덕션 자격 증명을 갖지 않습니다.
배포 기능을 MCP로 제공합니다. 배포, 상태 확인, 롤백이 환경별로 범위가 정해진 도구가 되므로, 에이전트의 배포 권한은 자격 증명이 든 셸 스크립트가 아니라 허용 목록이 됩니다.
환경별로 자율성의 단계를 나눕니다. 개발 환경에서는 에이전트가 자유롭게 배포합니다. 프로덕션에서는 에이전트가 릴리스를 준비하고 릴리스 관리자가 이를 승인하며, 훅이 프로덕션 게이트를 강제합니다. 스테이징은 그 중간 어딘가에 있습니다.
롤백은 파이프라인에서 가장 많이 연습한 경로여야 합니다. 에이전트가 실행할 수 있고 스테이징에서 정기적으로 실행해 보는 단일 명령이어야 합니다. 루프 닫기 플레이(6단계: 유지보수)는 관리 대역을 벗어났을 때 이 롤백을 호출하므로, 롤백은 미리 검증해 두어야 합니다.

예시(파이프라인 단계)

- name: Triage failed build
  if: failure()
  run: >
    claude -p "out/build.log의 빌드 로그를 읽으세요. 가장 가능성이 높은
    원인을 찾고, 실패가 불안정한 테스트 때문인지 실제 문제인지 말하고,
    PR 스레드에 올릴 세 줄 요약을 작성하세요." >> triage.md

거버넌스 고려 사항

핵심 원칙은 에이전트가 프로덕션 게이트 직전까지는 행동할 수 있지만 게이트를 넘을 수는 없다는 것입니다. 아래 통제 장치가 이 원칙을 강제합니다.

브랜치 보호는 에이전트가 작성하는 모든 것을 PR로 만들고, main으로 가는 직접 경로를 없앱니다.
프로덕션 배포 훅은 지정된 릴리스 관리자가 승인할 때까지 릴리스를 막습니다. 비대화형 실행은 모두 에이전트 자신의 ID로 이루어지므로, 파이프라인 로그에서 에이전트가 한 일과 실행을 시작한 엔지니어가 한 일을 구분할 수 있습니다.
환경별 권한 등급이 게이트에 이르기까지 에이전트가 할 수 있는 일의 범위를 정합니다.

측정 방법

선행 지표: 사람을 호출하지 않고 분류된 파이프라인 실패의 비율입니다. CI/CD 파이프라인 로그에서 가져옵니다.
후행 지표: DORA(DevOps Research and Assessment) 지표입니다. CI 시스템과 배포 도구가 이미 이 지표를 내보냅니다.

06. 유지보수

루프가 닫힙니다. 호출 경로에 사람이 없는 상태에서 트리거가 Claude를 호출하고, Claude가 발견한 내용은 intent.md가 되어 파이프라인으로 다시 들어갑니다.

유지보수와 루프 닫기

지금까지는 SDLC 프로세스의 각 단계에 Claude를 추가하는 방법을 살펴봤고, 각 단계의 첫 작업은 사람이 시작해야 했습니다. 하지만 이 단계에서는 루프를 닫기 위해 Claude를 자율적으로 실행하는 데 초점을 맞춥니다.

예를 들어 계속 실행되는 모니터링 에이전트는 버그 티켓이 등록되면 이를 계기로 intent.md를 만들고, 요구사항, 계획, 빌드, 테스트, 리뷰 단계를 차례로 거치게 할 수 있습니다. 6단계: 유지보수는 헤드리스로 실행됩니다. 단계 사이에는 독립적인 신뢰도 게이트가 있어서, 결정론적 검사나 적대적으로 리뷰하는 에이전트가 이전 단계의 결과물을 계속 진행할지 사람에게 에스컬레이션할지 결정합니다.

기존 방식 AI 네이티브 방식

유지보수는 사후 대응 단계입니다. 모든 티켓과 장애는 누군가 처리하고 프로세스를 다시 시작해 주기를 기다립니다. 새벽 3시에 울린 알림은 놓칠 수 있고, 티켓은 누군가 가져갈 때까지 백로그에 머물 수 있으며, 다른 장애가 먼저 터지면 사후 분석에서 나온 조치가 코드베이스에 아예 반영되지 않을 수도 있습니다.

관리 대역 이탈, 티켓, 채널 메시지, 일정 같은 트리거가 사람을 거치지 않고 Claude를 호출합니다. Claude는 원인을 진단하고, 게이트가 있는 경로를 통해서만 행동하며, 발견한 내용을 intent.md로 작성합니다. 이 intent.md는 앞에서 설명한 단계들을 거칩니다. 사람은 그 작업을 분류하고 리뷰하며, 더 이상 작업을 직접 시작할 필요가 없습니다.

기존 방식	AI 네이티브 방식
유지보수는 사후 대응 단계입니다. 모든 티켓과 장애는 누군가 처리하고 프로세스를 다시 시작해 주기를 기다립니다. 새벽 3시에 울린 알림은 놓칠 수 있고, 티켓은 누군가 가져갈 때까지 백로그에 머물 수 있으며, 다른 장애가 먼저 터지면 사후 분석에서 나온 조치가 코드베이스에 아예 반영되지 않을 수도 있습니다.
관리 대역 이탈, 티켓, 채널 메시지, 일정 같은 트리거가 사람을 거치지 않고 Claude를 호출합니다. Claude는 원인을 진단하고, 게이트가 있는 경로를 통해서만 행동하며, 발견한 내용을 `intent.md`로 작성합니다. 이 `intent.md`는 앞에서 설명한 단계들을 거칩니다. 사람은 그 작업을 분류하고 리뷰하며, 더 이상 작업을 직접 시작할 필요가 없습니다.

루프 닫기

결정론적 스크립트가 프로덕션을 지켜보다가 관리 대역을 벗어나면 Claude를 호출합니다. 관리 대역 이탈 모니터링은 루프가 자율적으로 돌아가는 패턴을 보여 주는 좋은 예입니다. 다른 채널로 들어오는 작업은 이 단계 마지막의 Claude Tag(퍼블릭 베타) 섹션에서 다룹니다.

시작하기

선행 조건: 루프가 다시 시작될 수 있도록 구조화된 결과물을 제공하는 intent.md가 필요합니다. Claude로 가속한 PR 리뷰, 행동의 경계 역할을 하는 훅, 그리고 CI/CD의 롤백 경로(가장 높은 자율성 단계에서 호출합니다)도 필요합니다.
인프라: 탐지 스크립트가 조회할 수 있는 메트릭 저장소(Prometheus, CI 시스템의 API 또는 그에 준하는 것), 리포지토리 읽기 권한이 필요합니다. 또한 CI에서 Claude Code를 비대화형으로 실행할 수단이나, 웹훅을 받는 서비스를 위한 Agent SDK가 필요합니다.

실행 방법

서비스 오너나 플랫폼 엔지니어가 안정적인 이동 기준선이 있는 메트릭 하나를 고릅니다. CI 테스트 실패율, 배포 후 5xx 비율, PR 사이클 타임 같은 것들입니다.
탐지 스크립트를 작성합니다. 보통 이동 구간의 평균과 표준 편차에 규칙(Western Electric 규칙 등)을 적용해, 급등뿐 아니라 느린 변화도 관리 대역에서 잡아내도록 합니다. 스크립트는 버전 관리되고 단위 테스트를 거치며, 탐지는 모델이 전혀 관여하지 않고 완전히 결정론적으로 이루어집니다.
대응 단계는 버전 관리되는 설정 파일(아래의 bands.yaml)에 정의합니다. 1σ에서는 스크립트가 기록만 하고, 2σ에서는 진단을 위해 Claude를 읽기 전용으로 호출하며, 3σ에서는 Claude가 행동할 수 있습니다. 다만 그 행동은 리뷰 게이트로 가는 PR을 열거나 미리 승인된 런북을 실행하는 것으로 한정됩니다.
트리거 계층은 GitHub나 GitLab의 예약 워크플로, 기존 모니터링 스택의 웹훅, 또는 네트워크 내부의 크론 작업이 될 수 있습니다. Claude는 상태 없이(stateless) 실행됩니다. CI 러너의 비대화형 단계로 실행하거나, 샌드박스 컨테이너 안에서 Agent SDK 서비스로 실행합니다. 배포와 모델 접근 방식은 CI/CD 플레이에서 다룹니다. 실행이 상태 없이 비대화형으로 이루어지므로, 아무도 시작하지 않아도 루프가 시작되고 끝날 수 있습니다.
에이전트는 진단 결과를 1단계: 계획 형식의 intent.md로 작성합니다. 여기에는 이상 징후와 그 증거, 제안하는 결과, 영향을 받는 시스템, 열린 질문이 담깁니다. 그 뒤로 이 발견 사항은 다른 작업과 똑같이 파이프라인을 거칩니다.
서비스 오너나 온콜 엔지니어가 대기열을 분류하고, 제품과 관련된 발견 사항은 프로덕트 오너에게 넘깁니다. 지금 수정할지, 일정을 잡을지, 기각할지 정합니다. 기각 결정은 관리 대역을 조정하는 데 쓰여 노이즈를 줄이는 데 도움이 됩니다.
수정 사항이 배포되면 해당 장애에 대한 평가를 추가합니다(지속적 평가 플레이). 그래야 앞으로 같은 문제를 막을 수 있습니다.

예시(CI 테스트 실패율을 모니터링하는 bands.yaml)

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

거버넌스 고려 사항

단계 경계는 버전 관리되는 설정에서 강제되고, 권한 설정과 관리형 설정은 프로덕션 접근을 거부합니다. 호출, 발견 사항, 분류 결정은 타임스탬프와 함께 기록됩니다. 서비스 오너가 발견 사항을 분류하고 승인하며, 그 결과로 생기는 변경은 일반적인 PR 리뷰 게이트를 거칩니다. 에이전트가 실행할 수 있는 런북은 미리 승인된 것들입니다.

측정 방법

선행 지표: 관리 대역 이탈부터 분류 대기열에 intent.md가 올라오기까지 걸린 시간입니다. 이를 예전에 장애 발생부터 사후 분석 조치까지 걸리던 시간과 비교합니다. 탐지 스크립트의 로그에는 이탈 타임스탬프와 장애 단계가 남아 있습니다.
후행 지표: 병합된 수정으로 이어진 발견 사항의 비율(분류 대기열을 실제 PR 이력과 대조), 그리고 같은 유형의 장애가 반복되는 횟수입니다. 수정할 때마다 평가 스위트에 사례가 추가되므로, 반복 횟수는 점점 줄어들어야 합니다.

예시

CI 테스트 실패율이 3σ를 넘으면, 에이전트는 불안정한 테스트를 격리하거나 되돌리기 PR을 열고, 리뷰 게이트가 결정합니다.
배포 후 5xx 비율이 3σ를 넘고 그 구간 안에 배포가 있었다면, 에이전트는 기존 롤백 파이프라인을 실행합니다.
PR 사이클 타임이 변화 감지 규칙에 걸리면, 에이전트는 엔지니어링 리더십을 위한 보고서를 작성합니다. 이 사례는 하네스가 프로덕션 메트릭뿐 아니라 프로세스 메트릭에도 통한다는 것을 보여 줍니다.

탐지는 결정론적으로 유지합니다. Claude는 관리 대역을 벗어난 뒤에야 호출되며, 단계에 따라 Claude가 할 수 있는 일이 정해집니다.

정기적인 코드베이스 스캔

보안 스캔은 특정 시점의 코드베이스를 특정 모델로 살펴본 결과일 뿐이고, 코드베이스와 모델 둘 다 시간이 지나면 낡습니다. 코드는 매주 바뀌고, 모델은 세대가 바뀔 때마다 이전 모델이 놓친 취약점을 찾아냅니다. AI 네이티브 방식의 해법은 호출 경로에 사람이 없도록 일정에 따라 스캔을 실행하고, 발견한 내용을 코드베이스의 다른 모든 변경과 같은 게이트로 보내는 것입니다.

Claude Security는 예약 스캔을 호스팅 형태로 제공하는 서비스입니다. GitHub 리포지토리를 연결하면 Anthropic 인프라에서 Claude Mythos 5로 스캔이 실행되고, 각 발견 사항은 보고되기 전에 검증되어 신뢰도 등급이 붙습니다. 제안된 패치는 웹용 Claude Code에서 리뷰하고 적용합니다. 조직은 모델 자체에 접근할 필요 없이 발견 사항을 받아 볼 수 있습니다.

기존 방식 AI 네이티브 방식

보안 스캔은 릴리스나 감사를 앞두고 실행하는 일회성 이벤트입니다. 보고서는 추적 시스템으로 가고, 다음 이벤트까지 백로그를 손으로 하나씩 처리합니다. 그 사이에 작성된 코드는 PR 리뷰에서 잡아낸 만큼만 보호됩니다. 연결된 모든 리포지토리를 대상으로, 사용할 수 있는 가장 뛰어난 모델로 일정에 따라 스캔을 실행하고, 누군가 읽기 전에 발견 사항을 검증합니다. 각 발견 사항은 관리 대역 이탈과 같은 방식으로 처리합니다. PR 하나로 끝나는 수정은 리뷰 게이트를 거치고, 그보다 큰 것은 intent.md가 됩니다. 커버리지는 첫 실행이 아니라 마지막 실행 시점을 기준으로 따집니다.

기존 방식	AI 네이티브 방식
보안 스캔은 릴리스나 감사를 앞두고 실행하는 일회성 이벤트입니다. 보고서는 추적 시스템으로 가고, 다음 이벤트까지 백로그를 손으로 하나씩 처리합니다. 그 사이에 작성된 코드는 PR 리뷰에서 잡아낸 만큼만 보호됩니다.	연결된 모든 리포지토리를 대상으로, 사용할 수 있는 가장 뛰어난 모델로 일정에 따라 스캔을 실행하고, 누군가 읽기 전에 발견 사항을 검증합니다. 각 발견 사항은 관리 대역 이탈과 같은 방식으로 처리합니다. PR 하나로 끝나는 수정은 리뷰 게이트를 거치고, 그보다 큰 것은 `intent.md`가 됩니다. 커버리지는 첫 실행이 아니라 마지막 실행 시점을 기준으로 따집니다.

시작하기

선행 조건: 발견 사항이 다른 변경과 똑같이 리뷰를 거치도록, PR 리뷰 게이트와 승인 게이트로서의 훅(5단계: 배포)이 필요합니다. PR 하나로 처리하기에는 너무 큰 발견 사항을 위해 1단계: 계획의 intent.md 형식도 필요합니다.
인프라: Claude Security는 Claude Enterprise 조직에 퍼블릭 베타로 제공됩니다. 대상 리포지토리(클라우드에서 호스팅되는 github.com)에 Anthropic GitHub App이 설치되어 있어야 하고, 웹용 Claude Code가 활성화되어 있어야 하며, 지출 한도를 설정한 상태로 추가 사용량(Extra Usage)이 켜져 있어야 합니다. 또한 스캔을 실행할 사람들에게 프리미엄 시트가 있어야 하고, 관리자가 claude.ai/admin-settings/claude-code에서 이 기능을 켜야 합니다. 스캔 비용은 Mythos 5 요금을 기준으로 사용량에 따라 청구되므로, 지출 한도는 리포지토리의 규모와 수에 맞춰야 합니다.

실행 방법

보안 리드가 리포지토리를 연결하고 리포지토리, 서비스, 팀 단위의 프로젝트로 묶습니다. 그래야 처음부터 발견 사항을 누가 담당하는지 분명해집니다.
가장 중요한 리포지토리부터 첫 전체 스캔을 실행합니다. 다른 도구나 이전 모델로 이미 스캔했던 리포지토리도 포함합니다. 첫 스캔을 기준선으로 삼으세요. 첫 스캔에서는 문제가 없다고 여겼던 코드에서도 발견 사항이 나올 가능성이 높습니다.
프로젝트별로 일정을 정합니다. 활발히 개발 중인 서비스라면 매주가 적절한 기본값입니다. 리포지토리가 크거나 여러 성격의 코드가 섞여 있다면 스캔 범위를 디렉터리나 브랜치로 좁히세요.
신뢰도 등급을 참고해 발견 사항을 분류합니다. 기각할 때는 이유를 남기세요. 그래야 기각 결정이 기록되고, 다음 실행에서 같은 발견 사항이 새 항목으로 다시 올라오지 않습니다.
범위가 한정된 발견 사항이라면 제안된 패치를 웹용 Claude Code에서 열어 리뷰하고, 다른 변경과 똑같이 PR 리뷰 게이트로 보냅니다. 수정을 제안한 에이전트는 그 수정을 승인할 방법이 없습니다.
아키텍처의 약점이나 여러 서비스에 걸쳐 반복되는 패턴처럼 패치 하나로 끝나지 않는 것은 1단계 형식의 intent.md로 작성해 계획 단계부터 시작합니다.
수정 사항이 프로덕션에 릴리스되면 해당 취약점 유형에 대한 평가를 지속적 평가 플레이의 스위트에 추가합니다. 그러면 그때부터 에이전트를 조종하는 설정이 그 유형에 대해 계속 테스트됩니다.
발견 사항을 CSV나 마크다운으로 내보내거나 웹훅을 사용해, 감사인이 이미 기대하는 곳인 조직의 기존 추적 시스템과 감사 시스템을 공식 기록 시스템으로 유지합니다.

거버넌스 고려 사항

스캔은 조직의 관리자 통제 아래에서 실행됩니다. 어떤 리포지토리를 연결할지, 누가 스캔 시트를 가질지, 지출 한도를 얼마로 할지를 모두 중앙에서 정합니다. 모든 발견 사항에는 검증 결과와 신뢰도 등급이 있고, 모든 기각에는 이유가 있습니다. 따라서 스캔 이력은 무엇이 발견되고, 수정되고, 의식적으로 수용되었는지를 보여 주는 감사 기록이 됩니다.

수정 사항은 스캔에서 바로 프로덕션으로 가지 않고, PR 리뷰 게이트와 브랜치 보호를 거쳐 프로덕션에 도달합니다. Claude Security는 기존의 정적 분석과 의존성 스캔을 보완합니다. 결정론적 검사는 CI에 그대로 두고, 모델 기반 스캔은 그런 검사가 찾도록 만들어지지 않은, 맥락에 따라 달라지는 취약점을 맡습니다.

측정 방법

선행 지표: 연결된 리포지토리 중 정기 스캔 일정이 잡힌 비율, 그리고 발견 사항이 보고된 시점부터 그 패치가 PR 리뷰 게이트에 들어가기까지 걸린 시간입니다. 스캔 이력과 PR 메타데이터에서 확인합니다.
후행 지표: 예약 스캔으로 찾은 취약점을, 프로덕션에서 또는 외부 제보로 발견된 취약점과 비교합니다(장애 추적 시스템에서 확인). 그리고 여러 번 스캔을 거친 리포지토리에서 스캔당 발견 사항 수의 추세를 봅니다. 수정과 평가가 쌓일수록 이 수는 줄어들어야 합니다.

Claude Tag로 Claude를 온콜에 투입하기

장애는 Slack이나 Teams 같은 업무용 메신저를 통해 들어올 수도 있습니다. 밤 10시에 장애 채널에 긴급 수정을 요청하는 Slack 메시지가 올라오는 식인데, 이제는 이런 장애도 즉시 처리할 수 있습니다. Claude Tag(현재 Slack에서 퍼블릭 베타로 제공)는 Claude를 자체 ID를 가진 채널 구성원으로 만듭니다. 그래서 새 장애마다 첫 대응자가 생기고, 대응 과정 자체가 루프의 일부이자 이후 장애에 대비한 기억이 됩니다.

대화와 조직의 지식은 채널에 남고, 채널에 있는 누구나 대응을 이끌고 실행할 수 있습니다. 팀원 누구나 실시간으로 가설을 검증하고, 새로운 방안을 탐색하고, 조사할 수 있으며, 채널 이력은 감사 가능성을 높여 줍니다. Claude는 MCP 접근을 통해 메트릭이 기준선으로 돌아왔는지 확인하고 스레드에서 이를 알린 뒤, 이후 조사에서 읽을 수 있도록 버전 관리되는 교훈 파일에 사후 분석을 작성합니다.

Claude Tag가 맡는 일은 장애만이 아닙니다. MCP를 통해 티켓에서 태그되거나 채널에서 요청을 받으면, Claude는 그 작업도 같은 방식으로 분류합니다. 작고 범위가 분명한 수정은 리뷰 게이트를 거치는 PR로 올라오고, 그보다 큰 것은 1단계: 계획을 위한 intent.md로 작성됩니다. 이 시점부터 루프는 스스로 일감을 공급하기 시작합니다. 참고: Anthropic에서 Claude Tag가 CI/CD 온콜을 맡는 방법.

채널이 곧 감사 추적 기록입니다. 요청, 진단, 사람의 승인, 수정이 모두 장애를 처리한 곳에 그대로 남습니다.

맺음말

모델과 하네스가 더 발전하면서, 조직은 코드를 만드는 방식뿐 아니라 소프트웨어 개발 수명 주기 전체를 바꿀 수 있게 되었습니다.

이 변화는 사람의 판단을 프로세스의 중심에 두고, 대기업 조직의 거버넌스와 규제 요구 사항을 고려합니다.

이 가이드는 Anthropic의 Applied AI 팀이 고객을 위해 매일 실행하는 실제 모범 사례를 모아 정리한 것입니다. 실용적이고 바로 실행할 수 있는 자료가 되었기를 바랍니다.

루프는 계속 돌아갑니다. 사람의 판단은 그 위에 있습니다.

참고 자료

아래 문서는 플랫폼 팀이 이런 통제 장치를 설정하는 데 필요한 자료로, 대략 실제로 도입하는 순서대로 정리했습니다.

AI 네이티브 SDLC 플레이북

이제 병목은 코드가 아닙니다

AI 네이티브 SDLC란 무엇일까요?

AI 네이티브 SDLC의 여섯 단계에서 일어나는 변화

플레이

01. 계획

intent.md로 기록하기

실행 방법

거버넌스 고려 사항

02. 설계

요구사항과 설계

실행 방법

예시(프롬프트)

거버넌스 고려 사항

03. 빌드

Claude Code 계획 모드를 기본 출발점으로

실행 방법

예시(plan.md)

거버넌스 고려 사항

자동 모드로 실행하는 Claude Code

레거시 시스템과 기준 원본

CLAUDE.md

실행 방법

예시(CLAUDE.md)

거버넌스 고려 사항

조직의 지식을 담은 스킬

실행 방법

예시(.claude/skills/secure-api-review/SKILL.md)

거버넌스 고려 사항

빌드 단계의 가드레일로서의 훅

병렬 세션과 서브에이전트

실행 방법

예시(.claude/agents/verifier.md)

거버넌스 고려 사항

04. 테스트

Claude에게 피드백 루프 주기

실행 방법

예시(CLAUDE.md의 검증 블록)

거버넌스 고려 사항

CI에서 지속적으로 실행하는 평가

실행 방법

예시(.github/workflows/agent-evals.yml)

거버넌스 고려 사항

05. 배포

PR 리뷰 루프 안의 AI

실행 방법

예시(REVIEW.md)

거버넌스 고려 사항

승인 게이트로서의 훅

실행 방법

예시(.claude/settings.json)

게이트 스크립트(.claude/hooks/production-gate.sh)

거버넌스 고려 사항

적용 예시: 규제 산업 기업을 위한 관리형 설정

CI/CD 통합과 배포

실행 방법

예시(파이프라인 단계)

거버넌스 고려 사항

06. 유지보수

유지보수와 루프 닫기

루프 닫기

실행 방법

예시(CI 테스트 실패율을 모니터링하는 bands.yaml)

거버넌스 고려 사항

예시

정기적인 코드베이스 스캔

실행 방법

거버넌스 고려 사항

Claude Tag로 Claude를 온콜에 투입하기

맺음말

참고 자료

Search the archive