AI-native SDLC 플레이북

코드는 더 이상 병목 지점이 아닙니다

조직은 AI를 활용해 1년 전만 해도 상상할 수 없었던 속도로 코드를 작성하기 시작했지만, 코드 관련 프로세스도 그 변화를 따라가지 못했습니다.

많은 엔지니어링팀이 여전히 동일한 승인 절차, 검토, 인수, 정책을 적용하고 있어 Claude Code와 같은 에이전틱 코딩 솔루션을 사용해 얻을 수 있는 생산성 향상을 제한하고 있습니다.

소프트웨어 개발 수명주기(SDLC)는 소프트웨어를 아이디어에서 프로덕션으로 전환하는 전체 프로세스입니다. 대부분의 조직은 소프트웨어의 계획, 디자인, 빌드, 테스트, 배포, 유지보수를 포함하는 동일한 6개 단계를 기반으로 유사하게 실행하고 있습니다. 전통적으로 각 단계는 서로 다른 역할이 담당하는 단계였습니다. 제품 매니저는 요구 사항을 작성하고, 기술 아키텍트는 이를 디자인으로 전환하며, 엔지니어는 디자인을 바탕으로 구축합니다. 규제 대상 기업의 QA 팀이 이를 검증하고, 릴리스 팀이 출시하며, 운영 팀은 실행 상태를 모니터링합니다. 각 단계 사이의 작업은 문서, 티켓, 승인을 통해 진행됩니다.

기존의 소프트웨어 개발 수명주기(SDLC)는 각 단계에서 책임을 명확히 하고 통제하기 위해 많은 프로세스를 필요로 합니다. 그러나 기존의 SDLC는 코드 작성 및 구현에 가장 많은 시간과 비용이 많이 들었던 시대에 효율성을 극대화하도록 디자인된 것으로, 이제는 더 이상 그렇지 않습니다. PRD, 산정 절차, 제품 보안 검토 등은 모두 몇 주, 몇 달, 몇 분기에 걸리는 개발 과정 동안 방향을 일치시키기 위해 존재했습니다.

전통적인 SDLC는 모든 단계가 사람이 수행한다는 가정에 기반한 통제 기능도 갖추고 있습니다. 가장 많은 가치를 창출하는 조직은 사람의 참여를 유지하면서, 에이전틱 AI의 역량을 중심으로 프로세스를 재구축했습니다. 이 가이드에서는 고객과의 협업을 바탕으로 개발을 가속화하고 프로세스를 더 빠르게 실행할 수 있도록, SDLC의 각 단계에서 Claude를 내부적으로 통합하는 Applied AI 팀의 몇 가지 모범 사례를 소개합니다.

코드가 더 이상 병목 현상이 아니고, 빌드 단계가 기존 SDLC가 허용하는 것보다 더 빠르게 진행되면, 세 가지 사항이 실현됩니다.

• 병목 현상은 빌드 단계의 앞뒤로 이동합니다. 주로 계획, 검토/테스트, 배포 단계이며, 여전히 사람의 작업 속도로 진행됩니다.
• 통제 기능이 현실과 맞지 않게 되면서, 다루기 어려워집니다. 직접 작성했을 때는 각 줄을 검토하는 것이 의미가 있었지만, 에이전트가 대부분의 변경 사항을 작성하게 되면 따라갈 수 없습니다.
• 예외 사항을 처리하는 데 여전히 주간 또는 월간 회의와 위원회를 거쳐야 하므로, 거버넌스 비용이 증가합니다.

보안 병목 현상을 예로 들어 보겠습니다. 보안 팀의 규모는 사람의 결과에 맞춰 구성되므로, 에이전트가 코드 생산량을 몇 배로 늘리면 검토 대기열이 쌓이거나 충분한 검토를 거치지 않은 코드가 배포됩니다. 규제 대상인 조직은 어느 쪽도 용납할 수 없으므로, 보안 및 정책 검토 또한 에이전트에 맞춰 진행해야 합니다.

에이전틱 AI의 생산성 향상을 실현하고 안전하게 보호하려면, 기존의 SDLC 수명 주기에도 도입 단계와 동일한 수준의 혁신이 필요합니다.

AI 네이티브 SDLC란 무엇인가요?

AI 네이티브 SDLC는 기존의 통제 목표와 새로운 시행 방식을 결합한 재설계된 프로세스입니다. 선형적인 흐름 대신 순환 구조로 바뀌어, 각 지점마다 AI가 내장되어 있습니다. AI 네이티브 SDLC는 업무 인계와 후속 작업의 자동 실행을 지원하며, 기존 SDLC 단계간 수동으로 이루어지는 번거로운 인계 과정을 해결하는 데 도움이 됩니다.

또한 이러한 전환을 에이전틱 SDLC, AI SDLC 또는 단순히 에이전틱 소프트웨어 개발이라고도 부릅니다. 명칭은 다르지만 의미는 같습니다.

AI 네이티브 SDLC의 6단계에 걸친 변화

아래 표는 기존 SDLC와 Claude가 지원하는 AI 네이티브 SDLC 간의 차이를 정리한 것입니다. 대부분의 조직은 이 두 열에 제시된 방식의 어딘가에 위치합니다.

오른쪽 열을 통해 진행되는 스레드는 커밋된 아티팩트입니다. 각 단계는 버전 관리 기록(intent.md, spec.md, plan.md, 변경 사항 및 테스트, 검토 결과가 포함된 PR, 인시던트 기록 포함)을 작성하는 것으로 끝나며, 다음 단계는 이를 읽는 것으로 시작됩니다. 초기 단계에서는 .md 파일이 가장 중요한 아티팩트입니다. 그래야 제품 소유자와 에이전트가 동일한 파일을 읽고 그에 따라 조치할 수 있기 때문입니다. 빌드부터는 코드와 그 기록이 아티팩트가 됩니다. 이러한 커밋 내역은 감사 추적 기록이기도 합니다. 이것을 통해 누가 무엇을 요청했는지, 에이전트가 무엇을 생성했는지, 누가 승인했는지, 그 결과를 확인할 수 있습니다.

판단이 필요한 모든 결정은 사람이 책임져야 합니다. 에이전틱 SDLC 환경에서는 검토해야 하는 아티팩트에 따라 사람의 관심도 달라집니다.

플레이

플레이는 이 플레이북의 핵심이며, 전체 수명 주기를 포괄하는 6가지 비선형 단계(계획, 디자인, 빌드, 테스트, 배포, 유지보수)로 나뉘어 있습니다.

각 플레이의 내용은 다음과 같습니다.

• 달라지는 점
• 시작하기
• 구체적인 구현 단계
• 거버넌스 고려 사항
• 제대로 작동했는지 측정하는 방법

단계는 모듈식으로 진행되며, 조직은 자체 고유한 요구 사항에 따라 다양한 시점에 각기 다른 단계를 우선적으로 진행할 수 있습니다. 각 플레이는 '사전 요건'에 종속성을 명시하며, 이러한 관계는 종속성 그래프에서 더 자세히 설명합니다.

단계는 아티팩트를 커밋하는 것으로 마무리되며, 이 커밋은 다음 단계를 시작합니다. 승인된 intent.md는 요구 사항 및 디자인 승인, 승인된 spec.md는 계획 모드를 실행, 병합된 PR은 파이프라인을 실행하며, 프로덕션 내 통제 범위를 위반하면 다음 intent.md가 작성되면서 루프가 계속됩니다.

처음에는 각 단계에서 수동으로 프롬프트를 입력하지만, 최종 상태에서는 승인된 각 아티팩트가 다음 게이트로 이동하는 루프가 됩니다. 사람의 주의는 게이트에 집중되며, 각 단계를 처음부터 시작하는 대신 에이전트가 표시한 것을 검토합니다.

intent.md로 캡처

소프트웨어 개발 프로세스를 시작하는 intent.md는 다양한 경로를 통해 유입될 수 있습니다. 아이디어를 내거나, 티켓을 제출하거나, 알림을 통해 인시던트가 드러납니다(6단계: 유지보수 참조).

아이디어가 생기면 Claude와 함께 브레인스토밍을 진행해 마크다운 프로토스펙을 작성합니다. 기존의 SDLC에서는 같은 사람이 제품 팀의 다른 구성원에게 자신과 함께 또는 대신해 아이디어를 작성하도록 설득해야 했습니다.

Claude가 생성하는 프로토스펙은 사람이 읽을 수 있고, 버전이 관리되며, 다음 단계에서 즉시 사용할 수 있습니다. 프로토스펙 파일은 intent.md로 저장됩니다.

의도가 이벤트 트리거에서 시작되었든 에이전트에서 시작되었든, 동일한 단계가 적용됩니다. 제품 소유자가 에이전트가 작성한 intent.md를 커밋하기 전에 검토하고 수정합니다.

이 설정은 플랫폼 또는 엔지니어링 팀이 한 번만 처리하면 되는 작업입니다. 조직 전반에서 많은 기여자가 참여할 수 있기 때문에, 기술팀 구성원이 의도 홈을 구축하고 여기에 쓰기 권한을 부여할 사람을 결정해야 합니다.

리포지토리가 완성되면 git 경험이 없는 기여자가 git을 직접 사용할 필요가 없습니다. 대신 버전 관리 시스템(예: GitHub)의 커넥터를 통해 Claude가 대신 claude.ai 또는 Cowork에서 마크다운 파일을 커밋할 수 있습니다.

실행 방법

1. 제안자는 Claude에게 문제를 자신의 말로 설명합니다. 현재 할 수 없는 부분, 아이디어의 영향을 받는 대상, 더 나은 모습, 범위를 벗어나는 부분을 설명할 수 있습니다. 공식적인 언어는 필요하지 않습니다.
2. 아이디어가 구체화될 때까지 브레인스토밍을 진행합니다. Claude는 분석가가 흔히 묻는 질문 즉, 범위, 사용자, 제약, 성공 기준을 묻습니다.
3. Claude에게 조직의 템플릿을 활용해 결과를 intent.md로 작성해 달라고 요청합니다. 기술팀 구성원이 설정한 스킬로 인코딩하고, 리드가 승인할 수 있습니다. 여기에는 문제, 제안된 결과, 영향을 받는 사용자 및 시스템, 제약 사항, 미해결 질문 등이 포함됩니다.
4. Claude가 잘못 이해한 부분은 제안자가 수정합니다.
5. intent.md를 공유 홈에 커밋합니다. 작성자와 타임스탬프가 기록에 추가되며, 이후 제품 소유자가 아이디어의 후속 작업을 진행합니다.

# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.

## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.

## Proposed outcome
Customers see claim status, next step and expected date in the portal.

## Affected users and systems
Claims handlers, portal team, claims-core API.

## Constraints
No new PII in the portal session. Existing authentication only.

## Open questions
Do third-party loss adjusters need access too?

거버넌스 고려 사항

증빙 자료는 커밋된 intent.md로, 작성자, 타임스탬프, 전체 수정 기록이 포함되어 있습니다. 이 정보는 의도 홈의 git 기록에 남습니다. 제품 소유자가 승인하고, 의도를 2단계: 디자인으로 넘길지 수락 또는 거부 결정을 통해 결정하면, 병합 또는 최종 검토로 기록됩니다.

요구 사항 및 디자인

제품 소유자의 승인을 거치면 Claude는 승인된 intent.md를 가져와 요구 사항과 디자인 사양을 작성합니다. 이는 조직의 브랜드, 보안, 컴플라이언스, UX에 대한 스킬을 기준으로 합니다.

제품 소유자는 해당 사양을 검토하지만, 직접 작성하지는 않습니다. 이 프로세스의 목표는 엔지니어링팀이 계획을 세울 수 있도록 우려할 수 있는 영역이 표시된 스펙을 만드는 것입니다.

프론트엔드 작업이 가장 대표적인 예입니다. intent.md가 승인되면 제품 소유자는 intent.md에서 Claude Design(베타)의 디자인 목업을 작성하고 반복한 뒤, Claude Code로 내보내어 빌드 단계로 연결합니다.

실행 방법

1. 제품 소유자는 조직의 스킬을 제공한 세션을 열고 intent.md를 첨부합니다.
2. 제품 소유자는 프롬프트에서 intent.md를 지정하고, 제약을 명시하며, 우려 사항을 표시하도록 요청합니다. 처음에는 직접 실행한 뒤, 조직 수준의 슬래시 명령어로 전환합니다. 그다음 의도 홈에 intent.md를 승인하는 것을 트리거로 삼습니다. 병합 시 실행되는 비대화형 작업으로 구성하고, 조직의 스킬을 로드한 상태로 승인을 진행하고, spec.md를 풀 리퀘스트로 커밋합니다(이 작업은 5단계: 배포의 CI/CD 플레이에서는 이 작업에서 설명합니다). 이렇게 되면, 제품 소유자는 검토 단계부터 참여하게 됩니다.
3. 동일한 제품 소유자가 아이디어에 맞춰 스펙을 검토합니다. 스펙이 명시된 문제를 해결하는지, intent.md의 미해결 질문에 답변을 제공하는지, 계속 진행되는지 확인합니다.
4. 분석가가 우선 표시했을 수 있는 문제를 먼저 확인합니다. 엔지니어링팀이 스펙을 확인하기 전에 제품 소유자가 정책 소유자와 함께 각 문제를 해결합니다.
5. intent.md와 함께 spec.md를 커밋합니다. 두 파일에 요청된 내용과 결정된 내용이 기록됩니다.
6. 제품 소유자는 스펙과 의도를 구현할 것인지 결정하고, 조직에서 더 높은 위험으로 분류하는 경우 기술 리드와 협의합니다. 이러한 결정은 항상 팀원이 내리며, 스펙을 수락하는 것으로 3단계: 빌드의 계획 모드 플레이가 시작됩니다.

실제 예시(프롬프트)

Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.

거버넌스 고려 사항

몇 주 후 검토 과정에서 발견되는 것이 아니라, 스펙을 작성하는 동안 정책을 읽고 적용합니다. 조직의 스킬은 스펙에 대한 제약으로 적용됩니다. 스펙, 이를 생성하는 데 사용된 프롬프트, 유효한 스킬의 버전은 모두 버전 관리에 기록됩니다. 제품 소유자가 스펙을 승인하고, 표시된 우려 사항을 지정된 정책 소유자에게 전달합니다.

Claude Code 계획 모드를 기본 시작점으로 활용

엔지니어는 계획 모드로 Claude Code 세션을 시작하고, Claude에게 2단계: 디자인에서 승인된 spec.md를 제공합니다. 그리고 인터뷰를 진행하며, 엔지니어가 만족할 때까지 계획을 반복적으로 검토합니다.

실행 방법

1. 엔지니어는 Claude와 함께 계획 모드로 세션을 시작합니다.
2. 엔지니어는 Claude에게 intent.md와 spec.md를 전달하고, 변경될 파일, 작업 순서, 이를 입증하는 테스트가 포함된 구현 계획을 요청합니다.
3. 변경으로 인해 어떤 문제가 발생할 수 있는지, 가장 위험한 단계는 무엇인지, Claude가 선택하지 않은 다른 옵션은 무엇인지 등을 묻고, 계획을 면밀히 검토합니다.
4. 대화 내용을 본 적 없는 엔지니어가 계획 변경 사항만으로도 직접 구현할 수 있을 때까지 반복해 진행합니다.
5. 승인된 계획을 plan.md로 커밋합니다. 이 계획은 감사 추적에 포함되며, PR 검토 플레이(5단계: 배포)가 이에 따라 최종 변경 내용을 확인합니다.
6. 계획을 수락하고 Claude가 구현하도록 합니다. 계획이 탄탄하다면, 단 한 번만에 구현되는 경우가 많습니다.
7. 구현 계획이 변경될 경우, 동일한 커밋에서 plan.md를 업데이트합니다. 후크를 사용하여 두 항목 간의 동기화를 적용하는 것도 고려합니다.

실제 예시(plan.md)

# Plan: claims status self-service (from intent.md 2026-06-02)

## Files that change
portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,
claims-api/tests/test_status.py

## Order of work
1. Add the status endpoint behind existing auth.
2. Panel against the endpoint.
3. Wire into the portal nav.

## Risks
The claims-core API rate-limits at 50 rps; the panel must cache.

## Proof
test_status.py covers the four claim states; screenshot matches the
approved mock.

거버넌스 고려 사항

디자인 검토는 코드가 생성되기 전에 이루어지며, 코드를 변경하려면 문서를 편집하기만 하면 됩니다. 엔지니어가 계획을 수락하기 전까지는 Claude가 파일을 편집할 수 없기 때문에, 계획 모드에서는 이를 자체적으로 시행합니다. 계획 및 수정 사항은 승인자와 함께 기록됩니다. 정기적인 변경 사항은 엔지니어의 승인을 거치며, 조직이 고위험으로 분류하는 변경 사항은 기술 리드나 아키텍트에게 전달됩니다.

Claude Code 자동 모드

Claude Code는 자동 모드에서도 실행할 수 있습니다. 엔지니어가 계획을 반복적으로 개선하여 만족스러운 수준에 도달한 후 계획을 승인하면, Claude는 편집마다 프롬프트 없이도 각 변경 사항을 적용합니다. 이후 플레이의 안전장치(조정된 CLAUDE.md, 정책 인코딩 스킬, 안전하지 않은 동작을 차단하는 후크, Claude가 실행할 수 있는 테스트 스위트)가 완성되면, 일상적인 작업에서는 자동 승인이 기본적으로 적용됩니다. 여기에는 제한된 spec.md, 적은 반복 반경, 테스트가 이미 다루는 코드가 포함됩니다.

이제 사용자가 에이전트의 편집을 지켜보고 작업을 검토하는 방식에서 벗어나, 더 긴 자율적인 세션 후 아티팩트를 검토하는 방식으로 전환되고 있습니다. 자동 승인 모드는 워크트리와 함께 사용할 때 개인과 팀 간의 병렬 처리를 가능하게 하며, 6단계: 유지보수에 설명된 대로 SDLC를 자율적으로 실행하고 루프를 마무리하는 데 필수적인 요소입니다.

CLAUDE.md

CLAUDE.md는 Claude에 새로운 참여자에게 필요한 컨텍스트를 제공하며, 여기에는 규칙, 명령어, 아키텍처, 팀이 가장 자주 발견하는 실수가 포함됩니다. 사람들의 머릿속과 위키에 존재하던 지식은 세션을 시작할 때마다 에이전트가 읽는 파일로 바뀝니다. 팀 전체가 유지보수하고, 실수가 있을 때마다 반복적으로 개선합니다.

실행 방법

1. 리포지토리에서 /init를 실행합니다. Claude는 발견한 내용을 토대로 초기 CLAUDE.md를 생성합니다.
2. 생성된 파일을 새로운 참여자가 첫날에 필요한 정보로 정리합니다. 빌드, 테스트, lint 명령어, 중요한 규칙, Claude가 반복적으로 잘못하는 부분은 그대로 유지합니다.
3. 리포지토리 루트에서 CLAUDE.md를 git로 체크인하면, 팀 전체가 하나의 버전을 공유하고, 변경 사항이 코드처럼 검토됩니다.
4. 여기서는 도움이 되는 실무 규칙이 있습니다. Claude가 동일한 실수를 두 번 반복하면 수정 사항이 CLAUDE.md에 저장됩니다.
5. Claude는 세션 시작 시 모든 내용을 읽으며, 오래된 내용은 아무런 이익도 없고 컨텍스트 공간만 차지하므로, 한 페이지 이내로 유지합니다.

실제 예시(CLAUDE.md)

# Payments service

## Commands
- Build: make build
- Test: make test (unit), make itest (integration, needs docker)
- Lint: make lint (runs in CI; fix before pushing)

## Conventions
- Java 21, Spring Boot 3. No new Lombok.
- Money is always BigDecimal, never double.
- Every endpoint needs an integration test in src/itest.

## Architecture
- api/ holds REST controllers, core/ holds domain logic,
  adapters/ talks to external systems.
- Kafka events are defined in schemas/; never edit generated classes.

## Things Claude gets wrong
- Do not bump dependency versions; the platform team owns them.
- The legacy v1/ package is frozen; changes go in v2/.

거버넌스 고려 사항

CLAUDE.md는 버전 관리가 이루어지므로 에이전트가 사용하는 지침을 검토 및 감사할 수 있습니다. 팀 규칙은 파일 전체에 적용되고, 변경 사항은 git 기록에 기록되며, 코드 소유자는 PR 검토에서 해당 변경 사항을 승인합니다.

기관 지식으로서의 스킬

스킬은 조직이 기관 내부의 지식을 실용화하는 방식입니다. 지침은 명시적이고, 버전이 관리되며, 광범위하게 적용되며, 정책이 변경될 때 중앙에서 업데이트됩니다. 경험적 규칙: 일관되게 적용되어야 하는 기관 지식을 위한 스킬을 작성하고, CLAUDE.md나 프롬프트에 포함된 구성 요소에 대한 내용은 스킬로 작성하지 않습니다.

실행 방법

1. 현재 일관되지 않은 지식 중 하나를 선택합니다. 보안 표준, API 디자인 규칙, 브랜드 규칙 등이 해당합니다.
2. 스킬로 작성합니다. SKILL.md가 포함된 폴더로, 여기에서 프런트매터는 언제 트리거되는지, 본문은 수행할 작업을 알려줍니다. 엔지니어가 정책 소유자의 공식 자료를 바탕으로 Claude를 활용하여 이 정책을 작성합니다.
3. 스킬을 .claude/skills/<name>/ 리포지토리에 저장해 코드와 함께 제공하거나, 플러그인을 통해 조직 전체에 배포합니다.
4. 스킬의 트리거 여부를 테스트합니다. Claude에게 관련 작업을 다양한 방식으로 수행하도록 요청하고, 매번 스킬이 로드되는지 확인합니다.
5. 정책이 변경되면 스킬을 변경하고 정책 소유자에게 변경 사항을 승인하도록 요청합니다.
6. 엔지니어는 다음 세션에서 자동으로 새 버전을 사용하게 됩니다.

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

---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or
  modifying an external-facing endpoint, reviewing API code, or
  generating an OpenAPI spec.
---
# Secure API review

When you create or change an API endpoint:
1. Authentication: every endpoint requires the gateway JWT;
   no anonymous routes outside /health.
2. Input validation: validate request bodies against the OpenAPI
   schema and reject unknown fields.
3. Audit: every state-changing endpoint emits an audit event with
   actor, action, entity and timestamp.
4. Data classification: fields tagged pii in the schema must never
   appear in logs or error messages.

Run scripts/check-endpoints.sh and include its output in your summary.

거버넌스 고려 사항

스킬은 권고이지만, 통제의 역할을 합니다. 이를 통해 Claude는 코드를 작성하는 동안 정책을 적용할 수 있지만, 세션이 이를 준수하도록 강제하지는 않습니다. 반드시 지켜야 하는 정책이라면 해당 업무를 차단하는 후크나 PR 시 정책을 재검토하는 검토 패스처럼 해당 스킬에 결정적인 요소가 필요합니다. 이 스킬은 위반 사례를 낮추고, 후크는 사실상 위반이 거의 불가능하게 만듭니다. 스킬 호출은 세션 추적에 기록되며, 정책 소유자는 코드와 마찬가지로 스킬 변경 사항을 검토합니다.

빌드 시점의 안전장치인 후크

스킬은 권고형 통제이고, 후크는 그 뒤에 작동하는 결정론적 계층입니다. Claude의 작업 대부분은 구현 중 파일 편집과 셸 명령어에 의해 수행되므로, 결국 후크가 가장 자주 실행될 수 있는 단계는 빌드입니다.

빌드 단계 후크는 다음과 같은 기능을 수행할 수 있습니다.

• 생성된 클래스나 동결된 패키지와 같이 보호된 경로에 대한 편집을 차단합니다.
• 파일 편집 후 포매터와 린터를 실행해 드리프트가 누적되지 않도록 합니다.
• 자격 증명이 노출되지 않도록 합니다.

정책이 예외 없이 적용되어야 하는 스킬은 모두 지원합니다. 일치하는 작업마다 후크가 실행되므로, 빌드 단계의 후크는 빠르게 실행되고, 변경된 파일에만 적용해야 합니다. 전체 테스트 스위트와 같이 더 무거운 검사는 커밋 또는 PR 단계에서 수행하는 것이 좋습니다.

사람의 승인을 요청하는 후크는 5단계: 배포의 게이트에 포함됩니다. 빌드 중 승인 프롬프트가 진행되면 모든 세션의 중요 경로에 다시 사람의 승인이 필요하기 때문입니다.

병렬 세션 및 서브에이전트

엔지니어 한 명이 여러 가지 업무를 동시에 진행할 수 있습니다.

병렬 세션은 또 다른 완전한 Claude Code 인스턴스로, 자체 git 워크트리에서 별도의 작업을 수행합니다. 각 독립적인 세션은 다른 세션에 대해 아무것도 모르며, 이들을 주도하는 엔지니어가 유일한 공통점입니다.

서브에이전트는 단일 세션 내에서 범위가 지정된 보조로 실행되며, 앱이 예상대로 실행되는지 확인하는 것처럼 여러 작업에서 반복되는 업무에 적합합니다.

병렬 세션은 엔지니어가 동시에 진행하는 작업 수를 늘리는 반면, 서브에이전트는 각 세션이 자체 작업에 집중할 수 있도록 지원합니다. 엔지니어의 역할은 이러한 모든 것을 관리하고 검토하는 것입니다.

실행 방법

1. 엔지니어는 계획 모드 플레이(3단계: 빌드)의 계획을 활용해 작업이 독립적인지 확인하고, 작업을 서로 다른 파일을 편집하는 작업으로 나눕니다. 파일을 공유하는 작업은 단일 세션에서 차례로 실행합니다.
2. 각 병렬 작업마다 고유한 워크트리가 생성됩니다. 예를 들어 한 터미널에서는 claude --worktree feature-auth를, 다른 터미널에서는 claude --worktree fix-rate-limit를 사용합니다. 워크트리는 자체 브랜치에 있는 별도의 체크아웃으로, 파일에서 세션이 충돌하는 것을 방지합니다.
3. 2~3회 세션으로 시작하는 것이 적절합니다. 실질적인 한도는 한 사람이 올바르게 검토할 수 있는 스트림 수이므로, 검토가 밀리지 않는 범위에서 세션을 추가합니다.
4. 반복적인 작업은 서브에이전트로 만듭니다. .claude/agents/의 마크다운 파일로 정의하며, 이름, 사용 시점에 대한 설명, 사용할 수 있는 도구가 포함됩니다. 예로는 메인 에이전트 종료 후 불필요한 복잡성을 제거하는 코드 단순화 에이전트, 앱을 실행하고 동작을 확인하는 검증 에이전트, 메인 컨텍스트에 넘치지 않으면서 코드베이스의 탐색을 수행하여 보고하는 조사 에이전트 등이 있습니다. 정의를 git에 커밋하여 팀 전체가 공유하도록 합니다.

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

---
name: verifier
description: Runs the app and checks the change works before the session
  reports done
tools: Bash, Read
---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.

거버넌스 고려 사항

세션이 많을수록 결과물도 많아지므로, 리포지토리의 설정에서 제어해야 합니다. 후크와 권한 설정은 모든 세션에 적용되며, 세션의 작업 내용은 기록되어 해당 세션을 실행한 엔지니어에게 전달됩니다.

Claude에게 피드백 루프를 제공

테스트, 빌드, 스크린샷 변경 사항 등 Claude가 자체 작업을 검증할 수 있는 방법을 항상 제공해야 합니다. 세션은 엔지니어가 확인하기 전에 자체적으로 작업을 검증하고 오류를 수정합니다.

피드백 루프를 검증자 서브에이전트(3단계: 빌드)와 혼동해서는 안 됩니다. 피드백 루프는 전체 작업에서 업무와 마찬가지로 여러 번 반복됩니다. 반면 검증 서브에이전트는 세션이 작업이 완료되었다고 판단하면 새로운 컨텍스트 창을 실행해 최종 검증을 수행합니다. 이렇게 하면 코드를 작성할 때 사용한 가정에 판정이 영향을 받지 않습니다.

실행 방법

1. 현재 작업을 검증하는 데 일련의 명령어와 어느 정도의 환경 지식이 필요하다면, 실패 시 0이 아닌 종료 코드로 종료되는 'make test'나 'npm test'와 같은 단일 명령어로 통합합니다.
2. CLAUDE.md의 Commands 섹션에서 각 명령어를 정상적인 출력의 예시와 함께 나열합니다.
3. 목표를 명시하고 수치화할 수 있으므로, Claude가 사용자에게 묻지 않고도 작업을 검증할 수 있습니다. 예를 들어 "test_status.py의 모든 테스트 통과", "스크린샷이 첨부된 목업과 일치", "엔드포인트가 새 필드를 포함한 200 응답 반환" 등으로 표시할 수 있습니다.
4. 버그를 수정할 때는 먼저 실패하는 테스트를 작성합니다. Claude에게 버그를 테스트로 재현 및 실행하여 예상한 이유로 실패하는지 확인하도록 요청합니다. 그 테스트를 커밋합니다. 그런 다음 테스트를 편집하지 않고 Claude에게 통과를 요청하고, 마지막 단계부터 테스트 파일 후크로 제한을 적용합니다. 수정 전에 존재했고, 에이전트가 다시 작성할 수 없었던 테스트는 버그가 사라졌다는 증거가 됩니다.
5. UI 작업의 경우 시각적 검사로 루프를 마무리합니다. Claude에 브라우저나 스크린샷 도구를 제공하고, 목업을 전달하며, 반복적으로 진행하도록 합니다. 구현하고, 스크린샷을 찍고, 비교하고, 조정합니다. 2~3회 검토하는 것이 일반적이며, 매번 결과가 개선되어야 합니다.
6. 검증은 '완료'의 일부로 포함합니다. 지침은 CLAUDE.md에 명시합니다. 작업 완료를 보고하기 전에 테스트를 실행하고 결과를 보여줍니다.
7. 마지막으로, 루프 자체를 보호해야 합니다. 코드를 수정하는 에이전트가 해당 코드에 대한 검증을 약화시키면 안 되기 때문입니다. 수정 작업 중에 테스트 파일에 대한 편집을 차단하는 후크가 이를 수행합니다. 대신 검토 중인 변경 사항을 확인하고, 테스트에 영향을 미치는 수정 사항을 거부할 수도 있습니다.

실제 예시(CLAUDE.md verification block)

## Verifying your work

- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.

CI에서의 지속적인 평가

평가는 단계별 QA에 해당하는 AI 네이티브 방식입니다. 실제로는 에이전트 구성이 변경될 때마다 실행되는 평가 모음을 의미합니다. 새로운 모델로 교체하거나 프롬프트를 다시 작성할 때, 평가 모음은 에이전트가 여전히 동일한 표준에 따라 작업을 수행하고 있는지 알려줍니다.

평가는 지속적으로 갱신되어야 합니다. 모델이 개선됨에 따라 과거에는 변별력이 있던 사례가 더 이상 그렇지 못할 수 있으므로, 지속적인 모니터링을 통해 새로운 사례를 추가해야 합니다.

사용 사례에 따라 일부 팀은 변경 사항이 있을 때마다 평가를 진행하는 대신, 일정한 주기로 오프라인 평가를 진행하는 것을 선호할 수 있습니다. 아래 단계는 지속적인 평가를 위한 것입니다.

실행 방법

1. 플랫폼 엔지니어가 최근 작업에서 20~50개의 실제 작업과 각각의 예상/승인된 결과를 수집합니다.
2. 각 작업을 평가 항목으로 작성합니다. 프롬프트에 수용 가능 여부를 정의하는 검사(테스트 통과, 린트 통과, 동작 변경 없음, 정책 준수)를 포함합니다.
3. 평가 스위트는 일정에 따라 CLAUDE.md, 스킬 또는 후크가 변경될 때 CI에서 비대화 방식으로 실행됩니다. 이러한 구성은 에이전트를 조정하며, 코드에 따라 회귀 테스트를 수행해야 하기 때문입니다.
4. 결과에 따라 게이트 구성이 달라집니다. 스킬의 변경으로 통과율이 낮아지면, 병합 전에 검토를 거칩니다.
5. 각 프로덕션 인시던트는 해당 인시던트를 담당한 팀이 작성한 평가 결과를 받게 되며, 회귀 테스트로 스위트에 유지됩니다.

실제 예시(.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에게 에이전트 결과에 대응할 수 있는 게이트를 제공합니다. 병합 검사로 통과율 임곗값이 강제로 적용되며, 시간 경과에 따른 결과를 비교할 수 있도록 실행 기록을 보관합니다. 구성 변경은 해당 사항을 담당하는 팀에서 승인합니다.

PR 검토 루프에서의 AI

Claude는 검토를 제공하는 동시에 받기도 합니다. 새로 들어온 PR을 조직의 정책에 맞춰 검토하고, 자체 PR에 대한 검토 의견도 처리합니다. 이를 통해 엔지니어는 PR 검토 시 동작에 집중할 수 있으며, 이는 결국 의도와 위험을 판단하는 데 도움이 됩니다.

실행 방법

1. 관리형 코드 검토 서비스가 가장 빠르게 시작하는 방법입니다. 관리자가 이를 활성화하고 리포지토리를 선택하면 됩니다. 파이프라인을 제어해야 하거나, 자체 클라우드 계약을 통해 API 호출을 처리하려는 경우에는 claude-code-action을 사용하여 자체 CI에서 검토를 진행합니다(CI/CD 플레이에서 해당 사항을 다룹니다).
2. 기술 리드는 리포지토리 부분에 REVIEW.md로 검토 정책을 작성하고, 조직이 중요하게 생각하는 항목으로 구분합니다. 버그 및 논리적 오류, 보안 및 취약점, 스펙(요구 사항 플레이의 spec.md), 구현 계획(계획 모드 플레이의 plan.md), 디자인 원칙이 포함됩니다. REVIEW.md는 중요한 사항과 사소한 사항을 구분하고, 건너뛸 항목도 정의합니다.
3. 기술 리드는 사람의 판단 기준을 정합니다. 결과 자체로 PR을 승인하거나 차단하는 것이 아니며, 브랜치 보호에 따라 코드 소유자의 승인이 필요합니다. 결과를 기준으로 병합하려는 플랫폼 엔지니어는 검사 결과가 기계가 판독 가능한 형태로 제공하는 심각도 수치를 읽을 수 있습니다.
4. 검토자나 작성자가 검토 댓글에 @claude를 태그하면 Claude가 해당 의견을 반영하고 수정 사항을 알려 줍니다. PR 스레드에는 요청과 변경 사항이 모두 기록됩니다. 이 수정 루프는 claude-code-action을 통해 진행됩니다. 반면 관리형 서비스에서는 @claude review라는 댓글을 달면 새로운 검토가 요청됩니다. Claude가 연 PR의 경우, 더 나아가 Claude가 병합 과정을 맡길 수 있습니다. 팀은 사용자 정의 슬래시 명령어로 루프를 마무리합니다. 이 명령어는 해결되지 않은 검토 의견과 실패한 검토 결과를 확인하고, 이를 해결하며, 수정 사항을 푸시합니다. PR이 통과되고 코드 소유자의 승인을 기다릴 때까지 이 작업을 계속합니다.
5. 검토 결과 피드백을 CLAUDE.md에 반영합니다. 검토 중 같은 실수가 두 번째로 표시되면 해당 검토의 일환으로 수정 사항이 CLAUDE.md에 반영됩니다. 검토 결과가 CLAUDE.md를 읽기 때문에 다음 PR부터 해당 실수를 발견할 수 있습니다. 변경 사항으로 인해 CLAUDE.md가 더 이상 맞지 않는 경우에도 검토에서 표시합니다.
6. 한 달에 한 번, 기술 리드가 검토 결과를 평가해 검토자를 개선하고, REVIEW.md에서 사소한 사항의 수량 제한을 설정해 조정합니다. 자동 생성 경로와 CI가 이미 시행하고 있는 모든 항목은 제외됩니다.

실제 예시(REVIEW.md)

# Review instructions

## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles

## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.

## Cap the nits
Report at most five nits per review; summarize the rest as a count.

## Do not report
Generated files under src/gen/ and anything CI already enforces.

거버넌스 고려 사항

코드를 작성한 에이전트가 이를 승인할 수 없기 때문에, 업무 분리는 유지됩니다. REVIEW.md의 검토 정책은 모든 PR에 적용되며, 발견 사항, 수정, 평가 및 승인은 PR 기록에 남습니다. 따라서 PR이 감사 기록이 됩니다. 승인은 사람의 검토를 바탕으로 브랜치 보호 단계를 통해 이루어집니다.

프로덕션 규모에서 이러한 제어 방식이 어떻게 구성되는지 알아보려면 Anthropic의 AI 네이티브 SDLC 보안을 참조하세요.

승인 게이트로 사용되는 후크

빌드 단계에서는 후크를 안전장치로 사용해 사람이 개입하지 않아도 작업을 허용하거나 차단했습니다(3단계: 빌드). 후크를 통해 특정 담당자가 승인할 때까지 작업을 일시 중단할 수 있습니다. 이는 릴리스 게이팅에 필요한 기능입니다.

이 플레이가 5단계: 배포에 해당되는 이유는 릴리스 게이트가 가장 명확한 사례이기 때문이지만, 후크는 배포에만 국한된 것이 아니며, Claude가 활동하는 곳마다 실행됩니다. 예를 들어, 후크는 3단계: 빌드에서는 변경 티켓 없는 경우 마이그레이션 및 인프라에 대한 편집을 차단할 수 있으며, 4단계: 테스트에서는 수정 작업 중 에이전트가 테스트 파일을 편집하는 것을 중단할 수 있습니다.

실행 방법

1. 변경 관리 및 컴플라이언스를 지원하는 엔지니어링 리더십은 변경 관리 승인, 릴리스 승인, 보호된 경로 편집 등에서 사람의 승인 과정을 거쳐야 합니다.
2. 플랫폼 엔지니어는 각 게이트를 후크로 표현합니다. 후크는 Claude가 동작 전에 실행되는 스크립트로, 작업을 허용, 요청 또는 차단할 수 있습니다.
3. 팀 후크는 git의 .claude/settings.json에 저장되며, 협상 불가의 후크는 플랫폼 또는 IT 관리자가 소유한 관리형 설정으로 저장합니다. 개별 엔지니어는 이를 해제할 수 없습니다.
4. 차단에는 설명이 필요하므로, 후크가 작업을 중단하면 이유와 승인 경로가 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
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
   if [ -z "$RELEASE_APPROVAL" ]; then
     echo "Production deploys need a release authorization." >&2
     exit 2 # exit 2 blocks the action; the message goes to Claude
   fi
fi
exit 0

거버넌스 고려 사항

후크는 승인 게이트입니다. 게이트 조건은 매번 누구에게나 적용됩니다. 허용 및 차단 결정은 타임스탬프와 함께 기록됩니다. 또한 해당 게이트는 승인된 변경 티켓이든 릴리스 매니저의 승인이든, 유효한 승인 기준도 정의합니다.

CI/CD 통합 및 배포

CI/CD 파이프라인 내에서 비대화형 방식으로 Claude Code를 실행하고, 실행 방식을 샌드박스 환경으로 격리하여 장기간 실행되는 에이전트가 안전하게 작동하도록 합니다. 그리고 MCP 통합을 통해 배포를 공개하고, 에이전트가 필요로 하기 전에 롤백 경로를 미리 검증합니다.

실행 방법

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

실제 예시(파이프라인 단계)

- name: Triage failed build
  if: failure()
  run: >
    claude -p "Read the build log at out/build.log. Identify the most
    likely cause, say whether the failure looks flaky or real, and write a
    three-line summary for the PR thread." >> triage.md

거버넌스 고려 사항

기본 원칙은 에이전트가 프로덕션 게이트까지는 작업할 수 있지만, 이를 통과할 수는 없다는 것입니다. 아래의 통제 수단이 이 원칙을 강제합니다.

• 브랜치 보호는 에이전트가 작성한 모든 내용을 PR로 전환하며, main으로 직접 연결되는 경로는 없습니다.
• 프로덕션 배포 후크는 지정된 릴리스 매니저가 승인할 때까지 릴리스를 차단합니다. 각 비대화형 실행은 에이전트의 자체 ID에 따라 수행되므로, 파이프라인 로그에서는 에이전트의 작업과 이를 트리거한 엔지니어의 작업을 구분합니다.
• 환경별 권한 등급은 에이전트가 게이트에 도달하기까지 수행할 수 있는 작업의 범위를 설정합니다.

유지보수 및 루프 마무리

지금까지는 SDLC 프로세스의 각 단계에 Claude를 도입하는 방법을 살펴보았으며, 각 단계에서는 사람이 직접 초기 단계를 시작해야 했습니다. 그러나 이 단계에서는 Claude의 자율적인 실행에 초점을 맞추어 루프를 마무리합니다.

예를 들어, 지속적으로 실행되는 모니터링 에이전트는 버그 티켓이 등록되면 intent.md를 생성하고, 요구 사항, 계획, 빌드, 테스트, 검토 단계를 거칠 수 있습니다. 6단계: 유지보수는 헤드리스로 실행되며, 단계 간 독립적인 신뢰도 게이트가 있습니다. 결정론적 검토 또는 적대적 검토 에이전트를 통해 이전 단계의 결과물을 다음 단계로 진행할지 아니면 사람을 개입할지 결정합니다.

루프 마무리

결정론적 스크립트는 프로덕션을 모니터링하고, 통제 범위를 벗어나면 Claude를 호출합니다. 이탈 모니터링은 자율적으로 실행되는 루프의 패턴을 보여주는 유용한 예이며, 단계 마지막의 Claude Tag(공개 베타) 섹션에서는 다양한 채널을 통해 들어오는 작업을 다룹니다.

실행 방법

1. 서비스 소유자 또는 플랫폼 엔지니어는 CI 테스트 실패율, 배포 후 5xx 발생 비율, PR 사이클 타임 등 안정적인 기준을 갖는 지표 하나를 선택합니다.
2. 이들은 탐지 스크립트를 작성합니다. 일반적으로 규칙(웨스턴 일렉트릭 또는 유사한 방식)을 적용하여 지속적인 평균 및 표준 편차를 기준으로 검출 스크립트를 작성하므로, 스파이크는 물론 느린 드리프트도 포착할 수 있습니다. 스크립트는 버전 관리를 거쳐 단위 테스트를 거치며, 탐지는 모델을 포함하지 않고, 완전히 결정적인 방식으로 수행됩니다.
3. 대응 계층은 버전이 관리되는 설정(아래의 bands.yaml)에서 정의됩니다. 1σ에서는 스크립트가 기록만 남기고, 2σ에서는 Claude를 읽기 전용으로 호출하여 진단합니다. 3σ에서는 Claude가 행동할 수 있지만, 검토 게이트에서 PR을 열거나 사전 승인된 런북을 실행하는 경우로 제한됩니다.
4. 트리거 레이어는 GitHub 또는 GitLab의 예약된 워크플로우, 기존 모니터링 스택의 웹후크, 네트워크 내의 크론 작업이 될 수 있습니다. Claude는 CI 러너의 비대화형 단계로 실행되거나, 샌드박스 컨테이너의 Agent SDK 서비스로 상태 비저장 방식으로 실행됩니다. CI/CD 플레이에서는 배포 및 모델 액세스 옵션을 설명합니다. 실행은 상태 비저장 및 비대화형 방식이기 때문에, 누군가가 시작하지 않아도 루프가 시작되고 종료될 수 있습니다.
5. 에이전트는 1단계: 계획의 형식에 맞춰 intent.md로 진단을 작성하며, 여기에는 예외 현상과 그 증거, 제안된 결과, 영향을 받는 시스템, 그리고 미해결 질문이 포함됩니다. 이후에는 다른 모든 작업과 마찬가지로 파이프라인을 거칩니다.
6. 서비스 소유자 또는 온콜 엔지니어가 대기열을 분류하고, 제품 관련 발견 사항을 제품 소유자에게 전달합니다. 즉시 수정하거나, 일정을 잡거나, 종결할 수 있습니다. 종결은 통제 범위를 조정하고 노이즈를 줄이는 데 도움이 됩니다.
7. 수정이 배포되면, 해당 사건에 대한 평가(지속적인 평가 플레이)를 추가해 해당 문제가 더 이상 발생하지 않도록 방지합니다.

실제 예시(예: 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 검토 과정을 거칩니다. 에이전트가 트리거할 수 있는 런북은 사전에 승인된 상태입니다.

예시

• CI 테스트 실패율이 3σ를 초과하면, 에이전트는 불합리한 테스트를 격리하거나 되돌리기 위한 PR 메시지를 생성하고, 검토 게이트가 이를 결정합니다.
• 배포가 포함된 모니터링 구간에서 배포 후 5xx 비율이 3σ를 초과하면, 에이전트는 기존 롤백 파이프라인을 트리거합니다.
• PR 사이클 시간이 드리프트 규칙에 맞게 변경되면 에이전트는 엔지니어링 리더를 위한 보고서를 작성합니다. 해당 보고서는 실행 체계가 프로덕션 지표는 물론 프로세스 지표에서도 작동한다는 것을 보여줍니다.

반복적인 코드베이스 스캔

보안 스캔은 특정 모델의 코드베이스에 대한 특정 시점의 평가이며, 두 요소 모두 시간이 지나면 유효하지 않습니다. 코드는 매주 변경되며, 각 모델 세대마다 이전 모델이 놓쳤던 취약점을 찾아냅니다. AI 네이티브 해법은 호출 경로에 사람이 개입하지 않고, 일정에 따라 검사를 실행하며, 발견된 내용을 다른 코드베이스 변경 사항과 같은 게이트로 전달하는 것입니다.

Claude Security는 호스팅 형태의 예약 스캔 방식입니다. GitHub 리포지토리에 연결하고, Anthropic 인프라의 Claude Mythos 5에서 스캔을 실행합니다. 각 발견 내용은 보고되기 전에 검증되고, 신뢰도 등급이 추가됩니다. 제안된 패치는 웹의 Claude Code에서 검토 후 적용됩니다. 조직은 모델 자체에 접근하지 않아도 해당 결과를 확인할 수 있습니다.

실행 방법

1. 보안 리드가 리포지토리를 연결해 리포지토리, 서비스, 팀별 프로젝트로 정리하므로, 처음부터 발견된 결과의 소유권이 명확합니다.
2. 다른 도구나 이전 모델에서 스캔한 적이 있는 리포지토리를 포함해, 가장 중요한 리포지토리에 대한 첫 번째 전체 스캔을 실행합니다. 첫 번째 스캔을 기준으로 삼아야 합니다. 첫 번째 스캔에서는 정상적인 것으로 판단된 코드에서도 새로운 문제가 나타날 수 있습니다.
3. 프로젝트당 일정을 설정합니다. 활발하게 개발된 서비스의 경우 주 1회 스캔을 기본값으로 설정하는 것이 적절합니다. 리포지토리가 크거나 혼합된 경우, 디렉터리나 브랜치로 범위가 한정합니다.
4. 신뢰도 등급을 바탕으로 결과를 선별합니다. 종결에 이유를 명시하여 종결 사실이 기록되면, 다음 실행에서는 동일한 결과가 새로운 발견으로 표시되지 않습니다.
5. 범위가 한정된 발견 사항의 경우, 웹의 Claude Code에서 제안 패치를 열어 검토한 뒤, 다른 변경 사항과 마찬가지로 PR 검토 게이트를 통해 제출합니다. 수정안을 제안한 에이전트는 승인할 경로가 없습니다.
6. 아키텍처의 취약점이나 서비스 전반에서 반복되는 패턴과 같이 단일 패치를 넘어서는 범위의 문제의 경우, 1단계 형식의 intent.md로 작성하고, 계획 단계부터 시작합니다.
7. 수정 사항이 프로덕션에 배포되면 지속적인 평가 과정에서 취약성 등급에 대한 평가를 테스트 모음에 추가합니다. 그러면 에이전트를 사용하는 구성이 해당 취약점에 대해 테스트됩니다.
8. 발견 사항을 CSV 또는 Markdown 형식으로 내보내거나, 웹후크를 활용해 조직의 기존 추적 및 감사 시스템을 감사자가 이미 기록을 확인할 것으로 예상하는 기록 시스템으로 유지할 수 있습니다.

거버넌스 고려 사항

스캔은 조직 관리자의 통제하에 실행됩니다. 즉, 어떤 리포지토리가 연결되는지, 스캔 권한을 보유한 사람, 지출 한도가 모두 중앙에서 설정됩니다. 모든 발견 사항에는 검증 결과와 신뢰도 등급이 있으며, 모든 종결에는 이유가 기록됩니다. 따라서 스캔 기록은 무엇이 발견되었는지, 무엇이 수정되었는지, 그리고 의식적으로 수용한 것에 대한 감사 기록으로 간주됩니다.

수정은 스캔 자체가 아닌 PR 검토 게이트와 브랜치 보호를 통해 프로덕션에 반영됩니다. Claude Security는 기존의 정적 분석 및 의존성 검사를 보완합니다. 결정론적 검사는 CI에 유지되며, 모델 기반 스캔은 이러한 검사에서 탐지되지 않는 컨텍스트 의존적 취약점을 다룹니다.

Claude Tag를 통한 Claude의 즉시 대응

인시던트는 Slack이나 Teams 같은 업무용 커뮤니케이션 앱 등 다양한 수단을 통해 접수될 수도 있습니다. 밤 10시에 Slack 메시지 형태로 인시던트 채널에 긴급 수정을 요청하는 경우에도, 이제 즉시 조치를 취할 수 있습니다. Claude Tag(현재 Slack에서 공개 베타 버전으로 제공)는 Claude를 자체 ID로 해당 채널의 멤버가 되도록 합니다. 따라서 새로운 인시던트마다 첫 번째 응답자가 배정되고, 그 대응 자체가 향후 인시던트를 대비하는 루프의 일부이자 메모리로 남습니다.

대화와 기관의 지식은 채널에 남아 있으며, 채널의 누구나 직접 대응을 제시하고 실행할 수 있습니다. 팀 구성원이라면 누구나 가설을 검증하고, 새로운 선택지를 탐색하며, 채널 기록을 추적할 수 있습니다. Claude는 MCP 접근을 통해 지표가 기준 수준에 맞춰 있는지 확인하고, 스레드에서 이를 공유합니다. 그리고 사후 분석 내용을 작성하여 버전 관리가 되는 교훈 파일에 저장하여 향후 조사에서 참조할 수 있습니다.

Claude Tag가 처리하는 작업은 인시던트뿐만이 아닙니다. Claude는 MCP를 통해 티켓에서 태그되거나 채널에 요청을 받으면, 동일한 방식으로 작업을 분류합니다. 소규모의 수정 사항은 검토 게이트를 통해 PR로 제공되며, 더 큰 수정 사항은 1단계: 계획을 위한 intent.md로 작성되며, 이때부터 루프가 자체적으로 이어지기 시작합니다. 참조: Claude Tag가 Anthropic에서 CI/CD 온콜을 수행하는 방식을 확인하세요.

마무리

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

이러한 전환은 사람의 판단을 프로세스의 중심에 두며, 대기업 조직의 거버넌스 및 규제 요구 사항을 고려합니다.

이 가이드에서는 Applied AI 팀이 고객을 위해 일상적으로 실행하는 실제 모범 사례를 집약했습니다. 실용적이고 실행 가능한 리소스로 발견하셨기를 바랍니다.

참고 자료 및 감사의 말

아래 문서는 플랫폼 팀이 이러한 통제 기능을 설정하는 데 필요한 자료로, 실제 도입 순서에 따라 대략적으로 정리되어 있습니다.

Jim Blackhurst, Will Steuk, Jamal Arif에게 감사를 전합니다. 이 가이드는 세 분의 이전 작업에서 영감을 받아 작성된 것입니다.