지표 루프 닫기 · AI 네이티브 SDLC 플레이북

이전의 모든 단계는 사람이 시작해야 하지만, Stage 6에서는 초점이 Claude의 자율 실행으로 옮겨가 루프를 닫습니다. 예를 들어, 지속적으로 실행되는 모니터링 에이전트는 버그 티켓이 생성된 것을 계기로 intent.md를 생성하고, 요구사항, 계획, 빌드, 테스트, 검토 단계를 거쳐 진행될 수 있습니다. Stage 6: Maintain은 헤드리스로 실행되며, 단계 사이에 독립적인 신뢰 게이트—결정론적 검사 또는 적대적 검토 에이전트—가 있어 이전 단계의 출력이 계속 진행될지 아니면 사람에게 에스컬레이션될지를 결정합니다.

변경되는 사항

기존 방식 AI 네이티브

유지보수는 반응적인 단계입니다. 모든 티켓이나 인시던트는 사람이 조치를 취하고 프로세스를 재시작할 때까지 기다립니다. 새벽 3시에 알림이 울려도 놓칠 수 있고, 티켓은 누군가 처리할 때까지 백로그에 남아 있을 수 있으며, 다른 화재가 먼저 발생하면 사후 분석 조치가 코드베이스에 전혀 반영되지 않을 수도 있습니다. 제어 밴드 위반, 티켓, 채널 메시지, 또는 일정과 같은 트리거가 사람의 개입 없이 Claude를 호출합니다. Claude는 진단하고, 게이트된 경로를 통해서만 조치를 취하며, 발견한 내용을 intent.md로 작성하고, 이는 위에서 설명한 단계들을 거칩니다. 사람은 그 작업을 분류하고 검토할 뿐, 더 이상 시작할 필요가 없습니다.

기존 방식	AI 네이티브
유지보수는 반응적인 단계입니다. 모든 티켓이나 인시던트는 사람이 조치를 취하고 프로세스를 재시작할 때까지 기다립니다. 새벽 3시에 알림이 울려도 놓칠 수 있고, 티켓은 누군가 처리할 때까지 백로그에 남아 있을 수 있으며, 다른 화재가 먼저 발생하면 사후 분석 조치가 코드베이스에 전혀 반영되지 않을 수도 있습니다.	제어 밴드 위반, 티켓, 채널 메시지, 또는 일정과 같은 트리거가 사람의 개입 없이 Claude를 호출합니다. Claude는 진단하고, 게이트된 경로를 통해서만 조치를 취하며, 발견한 내용을 `intent.md`로 작성하고, 이는 위에서 설명한 단계들을 거칩니다. 사람은 그 작업을 분류하고 검토할 뿐, 더 이상 시작할 필요가 없습니다.

결정론적 스크립트가 프로덕션을 감시하다가 제어 밴드가 위반되면 Claude를 호출합니다. 위반 모니터링은 루프가 자율적으로 실행되는 패턴의 유용한 예시이며, 단계 마지막의 Claude Tag(퍼블릭 베타) 섹션에서는 다른 채널을 통해 들어오는 작업을 다룹니다.

제어 밴드란

제어 밴드는 지표의 정상 수준을 중심으로 한 범위이며, 탐지 스크립트는 이를 지난 30일간의 시간별 측정값의 평균으로 계산합니다. 스크립트는 또한 표준편차인 시그마(σ), 즉 측정값이 평균에서 일반적으로 얼마나 벗어나는지를 계산합니다. 1σ 밴드는 평균에 1σ를 더한 값에서 끝나고, 2σ 밴드는 평균에 2σ를 더한 값에서 끝나는 식입니다.

안정적인 지표의 측정값이 종형 곡선을 따른다면, 약 6개 중 1개가 1σ를 초과하고, 44개 중 1개가 2σ를 초과하며, 740개 중 1개가 3σ를 초과합니다. 한 달에 720개의 측정값이 있다면, 우연만으로도 하루에 약 4개가 1σ를 초과하고, 한 달에 16개가 2σ를 초과하며, 한 달에 1개가 3σ를 초과합니다. 이것이 1σ 등급이 로그만 남기는 이유이며, 노이즈만으로도 한 달에 한 번 정도 발생할 수 있는 3σ 등급조차 게이트된 경로로 제한되는 이유입니다.

1956년 품질 관리 핸드북에서 유래한 Western Electric 규칙은 3σ를 결코 넘지 않을 수도 있는 느린 드리프트를 포착합니다. 이 규칙은 최근 5개 측정값 중 4개가 1σ를 초과하거나, 연속 8개가 평균을 초과하는 경우를 표시합니다.

시작하기

전제 조건: 루프에 재시작을 위한 구조화된 출력을 제공하는 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을 여는 것이나 사전 승인된 런북을 트리거하는 것으로만 제한됩니다. 드리프트 규칙은 2σ로 간주됩니다.
트리거 계층은 GitHub나 GitLab의 예약된 워크플로, 기존 모니터링 스택의 웹훅, 또는 네트워크 내부의 크론 작업일 수 있습니다. Claude는 CI 러너에서 비대화형 단계로 실행되거나 샌드박스 컨테이너 내의 Agent SDK 서비스로 실행되는 등 상태 비저장 방식으로 실행되며, CI/CD 플레이에서 배포 및 모델 접근 옵션을 다룹니다. 실행이 상태 비저장이고 비대화형이기 때문에, 아무도 시작하지 않아도 루프가 시작되고 끝날 수 있습니다.
에이전트는 진단 내용을 Stage 1: Plan 형식의 intent.md로 작성하며, 이상 현상과 그 증거, 제안된 결과, 영향을 받는 시스템, 그리고 미해결 질문을 다룹니다. 이후 해당 발견 사항은 다른 모든 것과 마찬가지로 파이프라인을 거칩니다.
서비스 소유자 또는 온콜 엔지니어가 큐를 분류하며, 제품에 영향을 미치는 발견 사항은 제품 소유자에게 전달합니다. 즉시 수정, 일정 예약, 또는 기각 중 하나를 선택합니다. 기각은 밴드를 조정하고 노이즈를 줄이는 데 도움이 됩니다.
수정 사항이 배포되면, 향후 이러한 문제로부터 보호되도록 해당 인시던트에 대한 평가(지속적 평가 플레이)를 추가합니다.

실제 모습

예를 들어, CI 테스트 실패율을 모니터링하는 bands.yaml은 다음과 같습니다:

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] }

이 예시의 나머지 부분은 동일한 파일을 프로덕션 지표에 적용하며, 첫 번째 줄만 metric: status_5xx_rate로 변경됩니다. 이 지표는 보험사의 청구 상태 엔드포인트에서 발생하는 5xx 오류의 비율입니다.

이 스크립트는 표준 라이브러리만 사용하는 33줄의 Python 코드입니다. 평균과 σ를 계산하고 최신 측정값이 속하는 가장 심각한 등급을 출력합니다.

python

"""Reads 30 days of hourly readings on stdin as a JSON list, oldest first. Prints the tier the newest one lands in."""
import json
import statistics
import sys

MIN_SIGMA = 0.01   # in the metric's own units, so a flat baseline does not turn every blip into a breach

def above(readings, line, need, out_of):
    """True if at least `need` of the last `out_of` readings sit above `line`."""
    return sum(r > line for r in readings[-out_of:]) >= need


def tier(readings):
    baseline = readings[:-1]   # everything before the newest reading
    if len(baseline) < 24:
        sys.exit("need at least a day of readings before the newest one")
    mean, sigma = statistics.mean(baseline), max(statistics.stdev(baseline), MIN_SIGMA)
    rules = [  # worst first; only the high side matters for an error rate
        ("3sigma", "reading above 3 sigma", above(readings, mean + 3 * sigma, 1, 1)),
        ("2sigma", "reading above 2 sigma", above(readings, mean + 2 * sigma, 1, 1)),
        ("2sigma", "drift: 4 of 5 readings above 1 sigma", above(readings, mean + sigma, 4, 5)),
        ("2sigma", "drift: 8 readings in a row above the mean", above(readings, mean, 8, 8)),
        ("1sigma", "reading above 1 sigma", above(readings, mean + sigma, 1, 1)),
    ]
    for name, rule, tripped in rules:
        if tripped:
            return {"tier": name, "rule": rule, "reading": readings[-1],
                    "mean": round(mean, 4), "sigma": round(sigma, 4)}
    return {"tier": "none", "reading": readings[-1], "mean": round(mean, 4), "sigma": round(sigma, 4)}


if __name__ == "__main__":
    print(json.dumps(tier(json.load(sys.stdin))))

매시간 스크립트를 실행하는 예약된 작업은 출력된 등급을 bands.yaml에서 조회하고, 해당 등급의 도구나 경로로 Claude를 시작합니다. propose 등급의 경우, 이는 gh pr create와 런북을 트리거하는 단일 명령을 포함하는 허용 목록을 의미합니다.

고객은 포털의 패널에서 청구 상태를 확인하며, 이 패널은 각 응답을 60초 동안 캐시합니다. 13:52에 배포된 릴리스가 이 캐시를 0으로 설정했다고 가정해 봅시다.

이제 모든 페이지 조회가 엔드포인트 뒤에 있는 오래된 시스템인 claims-core에 도달합니다. 이 시스템은 초당 50개의 요청을 허용하며, 이를 초과하면 거부하기 시작합니다. 14:00에 스크립트는 다음과 같이 출력합니다:

json

{"tier": "3sigma", "rule": "reading above 3 sigma", "reading": 1.9, "mean": 0.2, "sigma": 0.02}

3σ 등급은 propose에 매핑되며, 이는 에이전트를 앞서 나열된 두 경로로 제한합니다. 위반 몇 분 전에 릴리스가 배포되었으므로, 에이전트는 사전에 승인된 rollback-deploy 런북을 실행합니다. 그런 다음 발견한 내용을 Stage 1에서 사람이 사용하는 것과 동일한 형식으로 intent.md에 작성합니다:

markdown

# Intent: status endpoint 5xx after release 4f2c9e1
Author: monitoring agent (status_5xx_rate, 3 sigma). Status: draft.
## Problem
The 5xx rate on GET /claims/{id}/status read 1.9% at 14:00. The 30-day mean is 0.2%.
Release 4f2c9e1 went out at 13:52. It changes CACHE_SECONDS in StatusPanel.tsx from 60 to 0.
With no cache, every page view reaches claims-core, which allows 50 requests a second (CLAUDE.md).
## Proposed outcome
Customers get fresher status without the portal passing the claims-core limit.
## Affected users and systems
Portal customers, claims-api, claims-core API.
## Constraints
The panel's spec.md allows status to be up to 60 seconds old (R4). The claims-core limit is fixed.
## Action already taken
Ran the rollback-deploy runbook at 14:02. It reported version 8c41d07 live again at 14:04.
## Open questions
Who asked for live status, and is 60 seconds too slow for them?

수정 사항이 배포되면, 위 7단계에서처럼 해당 인시던트는 평가를 남깁니다. 이 평가는 인시던트를 유발한 요청을 에이전트에게 제공하며, 캐시가 사라진 경우 실패합니다. 여기서 from은 실행이 시작되는 커밋이고, may_change는 건드릴 수 있는 폴더를 나열합니다:

json

{
  "name": "status-panel-keeps-its-cache",
  "source": "Incident: status endpoint 5xx after release 4f2c9e1",
  "from": "4f2c9e1~1",
  "prompt": "Customers say the claim status panel feels stale. Make it feel live. Run the tests before you finish.",
  "may_change": ["claims-api/routes", "claims-api/tests", "portal/src"],
  "checks": [
    { "name": "tests pass", "run": "make test" },
    { "name": "lint clean", "run": "make lint" },
    { "name": "panel still caches", "run": "grep -Eq 'CACHE_SECONDS = [1-9]' portal/src/claims/StatusPanel.tsx" }
  ]
}

거버넌스 고려사항

등급 경계는 버전 관리되는 설정에서 강제되며, 권한 및 관리형 설정이 프로덕션 접근을 거부합니다. 호출, 발견 사항, 분류 결정은 타임스탬프와 함께 기록됩니다. 서비스 소유자가 발견 사항을 분류하고 승인하며, 그 결과로 발생하는 변경 사항은 일반적인 PR 검토 게이트를 거치고, 에이전트가 트리거할 수 있는 런북은 사전에 승인되었습니다.

측정 방법

선행 지표: 밴드 위반부터 분류 큐에 intent.md가 생성되기까지의 시간을, 인시던트부터 사후 분석 조치까지의 기존 시간과 비교합니다. 탐지 스크립트의 로그에는 위반 타임스탬프와 인시던트 등급이 기록됩니다.
후행 지표: 병합된 수정 사항이 된 발견 사항의 비율(분류 큐 대비 실제 PR 이력), 그리고 동일한 유형의 반복 인시던트 수로, 수정 사항이 평가 스위트에 케이스를 추가함에 따라 감소해야 합니다.

예시

CI 테스트 실패율이 3σ를 위반하면, 에이전트는 불안정한 테스트를 격리하거나 되돌리기 PR을 열고, 검토 게이트가 결정합니다.
배포 후 5xx 비율이 해당 기간 내 배포와 함께 3σ를 위반하면, 에이전트는 기존 롤백 파이프라인을 트리거합니다.
PR 사이클 타임이 드리프트 규칙을 발동시키면, 에이전트는 엔지니어링 리더십을 위한 보고서를 작성하며, 이는 이 하네스가 프로덕션 지표뿐 아니라 프로세스 지표에도 작동함을 보여줍니다.

Claude Tag를 통한 Claude 온콜

인시던트는 Slack이나 Microsoft Teams와 같은 업무용 커뮤니케이션 앱 등 다른 경로를 통해서도 발생할 수 있습니다. 인시던트는 인시던트 채널에 올라온 긴급 수정 요청을 위한 밤 10시 Slack 메시지처럼 보일 수 있으며, 이제는 즉시 조치될 수 있습니다. Claude Tag(현재 Slack에서 퍼블릭 베타로 제공)는 Claude를 고유한 신원으로 해당 채널의 구성원으로 만들어, 각 새로운 인시던트가 첫 대응자를 갖게 되고 대응 자체가 향후 인시던트를 위한 루프와 메모리의 일부가 됩니다.

대화와 조직 지식은 채널에 남아 있으며, 채널에 있는 누구나 대응을 안내하고 조치할 수 있습니다. 모든 팀원은 가설을 테스트하고, 새로운 옵션을 탐색하며, 실시간으로 조사할 수 있고, 채널 기록이 감사 가능성을 더해줍니다. MCP에 대한 접근을 통해 Claude는 지표가 기준선으로 돌아왔는지 확인하고 스레드에서 이를 확인해 주며, 향후 조사에서 읽을 수 있는 버전 관리되는 교훈 파일에 사후 분석을 작성합니다.

인시던트만이 Claude Tag가 처리하는 유일한 작업은 아닙니다. MCP를 통해 티켓에 태그되거나 채널에서 요청받으면, Claude는 동일한 방식으로 작업을 분류합니다. 작고 범위가 명확한 수정 사항은 검토 게이트를 거치는 PR로 도착하며, 더 큰 작업은 Stage 1: Plan을 위한 intent.md로 작성되고, 이 시점에서 루프는 스스로를 먹여 살리기 시작합니다.

변경되는 사항

제어 밴드란

시작하기

실행 방법

실제 모습

거버넌스 고려사항

측정 방법

예시

Claude Tag를 통한 Claude 온콜