■ feedback loop 책임 표

feedback loop governance : signal → trigger → owner → action · 정기 트리거 · 넘으면 이해관계자 검토로 올리는 선6.3 본편

표시가 없는 문장은 공식 문서에서 확인한 내용이에요. 다른 표시는 읽는 법

왜 배우나 — 시험이 요구하는 것

시험 목표 6.3 피드백과 기대 맞추기 · D6 사람·문서 14%
Manage stakeholder feedback loops and expectation alignment (including SLAs)

이 개념으로 푸는 판단 (할 수 있어야 하는 것)

6.3② 월간 검토에서 법무팀이 놓친 조항 사례를 들고 왔다 — 이 피드백을 어디로 보내나? — 피드백 루프를 닫는 방법 (상태 보고 회의 vs 평가셋 편입)
6.5① 핸드오프가 끝났다 — 아키텍트가 계속 할 일 두 가지는? (복수 응답) — 수명주기 5단계(디스커버리·설계·핸드오프·모니터링·반복)는 되돌아오는 루프 — 핸드오프 뒤 할 일

한눈에

운영 중 신호마다 한 행을 적는다. 한 행에는 네 칸이 있다.

신호 : 무엇을 보나?
트리거 : 언제 움직이나?
지정된 담당자 : 누가 움직이나?
반드시 하는 행동 : 런북 실행 · 프롬프트 되돌리기 · 이해관계자 검토

대시보드 · 주간 품질 보고 · 공용 채널 알림은 모니터링일 뿐이다. 담당자와 행동이 없으면 아무 일도 생기지 않는다 업계 일반 표 구조는 Anthropic 문서 없음

공식 문서에서 가장 가까운 것은 셋이다 (셋 다 좁은 문맥이다. 루프 표로 넓힌 것은 해석이다)

eval 셋은 명확한 소유권이 있어야 쓸모가 있다
알림은 내 observability 백엔드의 몫이다
정기 작업에는 성공이 무엇인지와 결과로 무엇을 할지를 적는다

기술 루프(실패, eval 과제, CI)는 ■ 운영 → eval feedback loop 에 있다. 핸드오프 뒤 두 가지 일은 ■ lifecycle 루프 에 있다. 여기는 사람 쪽 feedback loop 를 다룬다. 누가 무엇에 반응하고, 언제 이해관계자(stakeholder)에게 올리나?

비유 온콜 에스컬레이션 정책과 같다. 알림마다 받는 사람, 응답이 없을 때의 다음 사람, 런북 링크가 정해져 있다. 공용 채널에만 쏘는 알림은 아무도 안 받는 알림이다

신호, 트리거, 이름 있는 소유자, 반드시 하는 행동이 한 행으로 이어져야 하고 대시보드·주간 보고·공용 채널 알림은 모니터링만이라는 그림 — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

ELI5

집에 화재경보기가 있어도, 울릴 때 누가 무엇을 할지 안 정하면 소용없어요.

경보마다 "누가 나가서 무엇을 한다" 를 정해 둬요.
연기가 아주 조금씩 나면 경보가 안 울려요. 그래서 매주 한 번 집을 둘러보는 날도 정해요.
불이 크면 혼자 끄지 말고 어른에게 알려요.
이 쪽은 "누가, 언제, 무엇을" 을 표 한 장에 적는 법이에요.

개념 설명

영상 — 알림 선보다 받는 사람이 먼저 (약 45초 · 소리 없음 · 자막). 알림 선 18%→12% · 하루 3건→40건 · 40건이면 걸러 보지 못함 = 설명 '뒤집히는 때 4'. 지원 품질 리드 · 당일 확인 · 런북 R-4 · transcript 30건 · 원인 기록 = 카드 흐름 ① 예시 값(업계 일반). 게이지 길이 비율은 그림용 작은 화면에서는 전체화면(⛶)으로 보세요.

원리

보여 주기 ≠ 루프

대시보드 · 주간 품질 보고 · 공용 채널 알림은 보여 주기(모니터링)일 뿐이다. 루프는 신호, 트리거, 지정된 담당자, 반드시 하는 행동이 이어진 것이다 (표 구조는 업계 일반).
공식 문서는 모니터링을 두고 두 가지를 말한다. 사후 대응이라 문제가 사용자에게 먼저 닿는다. 신호가 시끄럽다. 그래서 누군가 걸러 행동으로 바꿔야 의미가 생긴다.
공식의 소유권 문장은 eval 셋에 있다 ("clear ownership"). 표의 모든 행으로 넓힌 것은 해석이다.
Claude Code 텔레메트리도 원시 이벤트만 내보낸다. 알림·기준선은 내 SIEM·observability(관측 가능성) 백엔드 몫이다 (공식). 그래서 알림을 만들고 받는 사람을 정하는 것은 늘 내 쪽 일이다.

트리거 세 종류

임계값 : 선을 넘으면 돈다. 지출 임계값 알림과 비용 급증 알림이 공식 장치다.
품질 상시 : 통과율 높은 과제를 regression suite 로 계속 돌려 drift 를 잡는다 (공식).
정기 : 지표와 상관없이 정해진 때 돈다. 매주 transcript 표본을 읽고 사람 정기 검토로 보정한다 (공식). 규제 정기 감사와 마일스톤 시연도 여기에 든다 (업계 일반).

넘으면 이해관계자 검토로 올리는 선

미리 합의한 선(비용 한도 · 합격 기준 · 규제 점검)은 팀 혼자 정해도 되는 범위의 경계다. 넘으면 이해관계자(stakeholder)가 검토한다.
원인을 먼저 밝힌다(정당한 성장인가 · 버그인가). 그다음 trade-off(절충)를 들고 간다. 예산 재설정은 스폰서가 한다 (전부 업계 일반).

핵심 질문 두 개

이 신호가 울리면 누가, 무엇을 하나? 사람 이름과 동작으로 답할 수 있나?
이 신호가 선을 넘으면 팀이 정하나, 이해관계자가 정하나?

규칙과 판단

지표가 선을 넘으면 임계값 트리거, 선 안에서 조금씩 떨어지면 품질 행·달력 행, 정해진 때는 달력 트리거로 도는 세 경우를 나눈 그림 — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

갈림길

①⑤ 루프인가 [6.3②]

신호마다 지정된 담당자가 있나?대시보드 · 주간 보고 · 공용 채널 알림

없다 (보기만)

담당자·행동부터 채운다

대시보드 · 주간 품질 보고 · 공용 채널 알림은 모니터링일 뿐이다. 담당자와 행동이 없으면 아무 일도 생기지 않는다 업계 일반. eval 셋도 명확한 소유권이 있어야 쓸모가 있다

있다

행동이 정해졌나?"살펴본다" vs 런북

"살펴본다 · 주의 당부"

행동을 적는다

런북 실행 · 프롬프트 되돌리기 · 이해관계자 검토처럼 반드시 하는 행동을 적는다 업계 일반

정해졌다

↓ 아래 「언제 도나」 갈림길로 이어짐

다음 물음 — 무엇이 움직이면 도나?

②③ 언제 도나 [6.3②] [6.5①]

무엇이 움직이면 도나?

지표가 선을 넘는다 (비용 · 이관률)

임계값 트리거

지출 임계값 알림과 비용 급증 알림을 쓴다

조금씩 떨어진다 (선 안)

품질 행 · 정기 행

표의 품질 행은 상시 도는 regression suite 로 본다 (해석). 품질 트리거는 출시 전에 표에 적는다 업계 일반. 지표가 선을 안 넘어도 정해진 때 도는 행이 서서히 떨어지는 품질을 잡는다 업계 일반. 통과율 높은 capability eval 은 regression suite 로 옮겨 계속 돌며 drift 를 잡는다

지표와 상관없이 정해진 때

정기 트리거

피드백은 계속 분류한다. transcript 는 매주 표본을 뽑아 읽는다. 사람 정기 검토로 보정한다

④ 누가 정하나 [6.3①] [6.3②]

합의한 선을 넘었나?비용 한도 · 합격 기준 · 규제 점검

아니오 (선 안의 흔들림)

팀 안에서 처리한다

선 안의 작은 흔들림은 팀이 처리하고 기록한다 업계 일반

예

원인은 밝혔나?정당한 성장인가 · 버그인가

아직

원인부터 밝힌다

정당한 성장인가, 버그인가부터 밝힌다 업계 일반. 자세한 것은 ■ 비용 급증 추적 에 있다

밝혔다

이해관계자 검토로 올린다

팀 안에서 조용히 고치지 않고 trade-off 를 들고 간다. 예산 재설정은 스폰서가 결정한다 업계 일반. 자세한 것은 ■ trade-off 전달 에 있다

흐름

그림 속 이름·금액·시간·토큰 수는 예시예요. 공식 한도·동작은 카드 본문 값이 기준.

장면 글로 보기

칸 : 신호 → 트리거 → 담당자 → 행동

규칙 (담당자) : 지정된 한 사람

질문 : 이 신호가 뜨면 누가 움직일까?

① 담당자 있는 행 ✓

시작 : 신호 — 쪽지 : 환불 문의 / 사람 이관률 / 12% → 21%
발동 : 신호 → 트리거 : 선을 넘는다 — 쪽지 : 선: 18% 초과 / 이틀 연속
받음 : 트리거 → 담당자 : 지정된 담당자가 받는다 — 쪽지 : 지원 품질 리드 / 당일 확인
실행 : 담당자 → 행동 : 반드시 하는 행동을 한다 — 쪽지 : 런북 R-4 / transcript 30건 / 원인 기록
끝 : 신호, 트리거, 담당자, 행동이 한 행에 있다

② 공용 채널 알림만 ≠

시작 : 신호 — 쪽지 : 환불 문의 / 사람 이관률 / 12% → 21%
발동 : 신호 → 트리거 : 공용 채널에 뜬다 — 쪽지 : #cs-alerts / 3주째 매일
건너뜀 : 담당자
멈춤 : 트리거 → 행동 : 담당자가 없는 알림이다 ≠ — 쪽지 : 조치 0건 / 3주째 21%
끝 : 담당자와 행동이 없으면 아무 일도 생기지 않는다

③ 서서히 떨어지면 정기 행 ✓

시작 : 신호 — 쪽지 : 정답률 / 88 → 87 → 86% / 알림 선 80%
조용함 : 트리거 : 선 안이라 알림은 울리지 않는다 — 쪽지 : 알림 0건
타이머 : 트리거 : 매주 월요일 transcript 표본
발동 : 트리거 → 담당자 : 정기 트리거가 돈다 — 쪽지 : 매주 표본 30개 / 3주째 하락
실행 : 담당자 → 행동 : 반복인지 재설계인지 진단한다 — 쪽지 : 주제별 쪼개기 / 트레이스 확인
끝 : 지표가 선을 안 넘어도 정해진 때 도는 행이 서서히 떨어지는 품질을 잡는다

규칙 원문 ①②③④⑤ (갈림길로 그린 규칙)

한 행 : 한 행에 신호, 트리거, 지정된 담당자, 반드시 하는 행동을 적는다 업계 일반 [6.3②]

신호	트리거	담당자	행동
환불 문의 사람 이관률	18% 초과 이틀 연속	지원 품질 리드	런북을 실행한다. transcript 표본을 읽고 원인을 기록한다
월 API 지출	지출 임계값 알림	플랫폼 리드	원인을 추적한다. 합의한 선을 넘으면 스폰서가 검토한다
regression suite 정답률	배포마다 · 매일	eval 셋 담당자	떨어진 과제를 확인하고 프롬프트를 되돌린다
transcript 표본	매주 월요일	지원 품질 리드	30개를 읽고 새 실패는 eval 과제로 만든다

(표 값은 예시다 · 업계 일반)

대시보드 · 주간 품질 보고 · 위험 메모 · 공용 채널 알림은 모니터링일 뿐이다. 담당자와 행동이 없으면 아무 일도 생기지 않는다. 원인은 라우팅·모델이 아니라 비어 있는 책임이다 업계 일반

담당자는 지정된 한 사람이다. 행동은 "살펴본다" 가 아니라 반드시 하는 행동이다. 런북 실행 · 프롬프트 되돌리기 · 이해관계자 검토가 그런 행동이다 업계 일반

공식 근거는 아래 셋이다 (좁은 문맥이다. 루프 표로 넓힌 것은 해석이다)

eval 셋은 계속 손보고 명확한 소유권이 있어야 쓸모가 있다
Claude Code 는 원시 이벤트만 내보낸다. 이상 탐지·기준선·알림은 내 SIEM·observability(관측 가능성) 백엔드 몫이다
정기 작업 프롬프트에는 성공이 무엇인지와 결과로 무엇을 할지를 분명히 적는다

자세한 것은 ■ observability 세 신호 에 있다

품질 행은 출시 전에 : 임계값 알림만으로는 서서히 떨어지는 품질을 못 잡는다(어느 알림도 선을 안 넘는다). 그래서 품질 트리거는 출시 전에 담당자·행동과 함께 표에 적는다 업계 일반 [6.3②] [6.5①]

공식 문서는 운영 모니터링을 사후 대응이라고 한다. 문제가 사용자에게 먼저 닿는다. 신호도 시끄럽다

통과율 높은 capability eval 은 regression suite 로 옮겨 계속 돌며 drift 를 잡는다

그래서 표의 품질 행은 상시 도는 regression suite 로 본다 (해석). 자세한 것은 ■ 검증 층 에 있다

출시 뒤에 쓰는 표는 막았어야 할 사고 뒤에 써진다 업계 일반

떨어졌을 때 무엇부터 할지(트레이스 · 주제별 쪼개기 · 반복 vs 재설계)는 ■ lifecycle 루프 에 있다
정기 트리거 : 지표가 선을 안 넘어도 정해진 때 도는 행이다 [6.3②] [6.5①]

공식 문서는 피드백을 계속 분류하라고 한다. transcript 는 매주 일부를 뽑아 읽고 필요하면 더 깊이 본다

가장 잘하는 팀은 자동 eval, 운영 모니터링, 사람 정기 검토(보정)를 함께 쓴다

Claude Code 정기 작업 예는 매일 아침 PR 검토 · 매주 의존성 감사 · 밤새 CI 실패 확인이다

규제 배포의 정기 출력 감사도 정기 행이다. 마일스톤마다 합의한 합격 기준에 대고 실제 동작을 시연하는 것도 정기 행이다. 긴 상태 보고나 불만 폭발을 기다리지 않는다 업계 일반

지표가 선을 안 넘어도 정해진 때 도는 행이 서서히 떨어지는 품질을 잡는다 업계 일반
④
넘으면 이해관계자 검토로 올리는 선 : 미리 합의한 선(비용 한도 · 합격 기준 · 규제 점검)을 넘은 신호는 팀 안에서 조용히 고치지 않는다. 이해관계자 검토로 올린다. 정당한 성장인가, 버그인가부터 밝히고 trade-off 를 들고 간다 업계 일반 [6.3①] [6.3②]

예산 재설정과 범위 변경은 스폰서가 결정한다 업계 일반. 선택지 표 만드는 법은 ■ trade-off 전달 에 있다

선 안의 작은 흔들림은 팀이 처리하고 기록한다 업계 일반

비용 행의 공식 장치는 셋이다
- 지출 임계값 알림
- 비용 급증 알림 (Claude Code)
- 워크스페이스 지출 한도 : 마지막 안전판(backstop)이다
그래서 알림이 먼저이고, 한도는 멈추는 장치다 (순서는 해석). 원인 좁히기는 ■ 비용 급증 추적 에 있다

SLA 위반이면 무엇이 따르는지(구제 · 축소 운영 · 통보 대상)는 조항에 미리 적는다. 자세한 것은 ■ SLA 조항 쓰기 에 있다
사람 피드백(override · 반려 · 불만)도 한 행 : 담당자가 분류한다. 진짜 실패는 eval 과제로 만든다. 과정 본문은 ■ 운영 → eval feedback loop 에 있다 [6.3②]

더 깊이 : 판단 규칙 · 상황 변수 (설명)

판단 규칙

조건	답	등급	근거
대시보드·주간 보고는 있는데 담당자·행동이 없다	모니터링일 뿐이다. 담당자·행동부터 채운다	업계 일반 (공식 근거 확인)	demystifying-evals "clear ownership" (eval 셋 문맥)
알림이 공용 채널에만 뜬다	담당자 없는 알림이다. 받는 사람 1명과 행동을 정한다	업계 일반	—
알림·기준선을 누가 만드나? (Claude Code)	내 SIEM·observability 백엔드가 만든다		monitoring-usage
정기 작업(스케줄)의 지시를 쓴다	성공이 무엇인지와 결과로 무엇을 할지를 적는다		claude-code-common-workflows (Claude Code 스케줄 문맥)
품질이 선 안에서 조금씩 떨어진다	regression suite 를 상시 돌리고 정기 행을 둔다	(regression suite · 매주 표본) · 업계 일반(표의 행)	demystifying-evals
품질 트리거를 언제 적나?	출시 전에 적는다	업계 일반	출시 뒤 표는 사고 뒤에 써진다
지표와 상관없이 정기적으로 확인한다	정기 트리거를 둔다. 매주 transcript 표본을 읽고 사람이 정기적으로 보정한다		demystifying-evals
비용 신호다	지출 임계값 알림과 비용 급증 알림을 쓴다. 지출 한도는 마지막 안전판이다		usage-cost-api · monitoring-usage · optimizing-cost-intelligence
합의한 선을 넘었다	원인부터 밝히고 이해관계자 검토로 올린다. 예산 재설정은 스폰서가 한다	업계 일반	—
선 안의 흔들림이다	팀이 처리하고 기록한다	업계 일반	—
사람 피드백(override · 불만)이 온다	분류한다. 진짜 실패는 eval 과제로 만든다		■ 운영 → eval feedback loop (demystifying-evals)

상황 변수

변수	값	답 쪽	등급	근거
담당자	없다 · "팀 전체"	모니터링일 뿐이다	업계 일반	판단 규칙 1
행동	"살펴본다 · 주의 당부"	행동이 아니다. 런북 · 되돌리기 · 검토로 바꾼다	업계 일반	—
하락 모양	선을 한 번에 넘는다	임계값 트리거가 잡아낸다	(알림 장치)	usage-cost-api
하락 모양	주마다 조금씩 떨어진다	임계값만으로는 늦다. 품질 행·정기 행을 둔다	계산 · 업계 일반	뒤집히는 때 1
선을 넘은 원인	내 쪽 버그다. 되돌리면 끝난다	팀이 고치고 사실은 알린다	업계 일반	뒤집히는 때 2
선을 넘은 원인	정당한 성장이다. 예산을 다시 정해야 한다	이해관계자가 검토하고 스폰서가 결정한다	업계 일반	판단 규칙 9
알림 선	더 낮춘다	알림이 늘어 담당자가 걸러 보지 못한다	계산 · 업계 일반	뒤집히는 때 4
비용 알림	없고 지출 한도만 있다	첫 신호가 "요청이 막힘" 이 된다	(한도 = backstop) · 추론	뒤집히는 때 5

연습 문제

고객지원 Agent 를 운영한 지 석 달째다. 주간 품질 대시보드대시보드만는 매주 회의에서 공유되고, #cs-alerts 채널에는 "환불 문의 사람 이관률 21%" 알림이 3주째 뜬다알림 3주째. 아무도 손대지 않았다. 팀장은 "알림 선을 더 낮춰 더 자주 울리게 하자"고 한다. 먼저 무엇을 채울까?

시험 대비

함정

"주간 품질 대시보드를 매주 회의에서 공유하니 루프가 있다" 는 함정이다. 그것은 모니터링일 뿐이다. 담당자와 행동을 채운다 업계 일반
"공용 채널 알림이 매일 뜨니 누군가 볼 것" 은 함정이다. 담당자 없는 알림으로는 아무 일도 생기지 않는다 업계 일반
"알림 선을 낮춰 더 자주 울리게" 는 함정이다. 받는 사람이 없으면 소리만 커진다. 담당자·행동부터 채운다 업계 일반
"놓친 사례를 주간 상태 회의에서 공유하고 주의 당부" 는 함정이다. 주의 당부는 행동이 아니다. eval 셋에 안 들어가면 루프가 닫히지 않는다 업계 일반. 자세한 것은 ■ 운영 → eval feedback loop 에 있다
"품질은 임계값 알림으로 충분" 은 함정이다. 서서히 떨어지면 어느 알림도 선을 안 넘는다 업계 일반. 운영 모니터링은 사후 대응이다
"표는 출시 뒤 운영팀이 정리" 는 함정이다. 그 표는 막았어야 할 사고 뒤에 써진다 업계 일반
"비용 선을 넘었지만 팀 안에서 조용히 튜닝" 은 함정이다. 이해관계자 검토로 올린다. 예산 재설정은 스폰서가 정한다 업계 일반
"지출 한도가 있으니 비용 알림은 필요 없다" 는 함정이다. 한도에 닿으면 요청이 막힌다. 자세한 것은 ■ API 오류별 대응 에 있다. 한도는 마지막 안전판이다
반대쪽 함정도 있다. "선 안의 작은 흔들림도 전부 스폰서에게" 는 함정이다. 선 안은 팀이 처리하고 기록한다 업계 일반

신호

"An eval suite is a living artifact that needs ongoing attention and clear ownership to remain useful."

"Reactive; problems reach users before you know about them"

"Signals can be noisy"

"triage feedback constantly, sample transcripts to read weekly, and dig deeper as needed."

"The most effective teams combine these methods: automated evals for fast iteration, production monitoring for ground truth, and periodic human review for calibration."

"capability evals with high pass rates can “graduate” to become a regression suite that is run continuously to catch any drift."

"Budget monitoring: Set up alerts for spending thresholds"

"Anomaly detection, baselining, correlation across sessions, and alerting are the responsibility of your SIEM or observability backend."

"When writing prompts for scheduled tasks, be explicit about what success looks like and what to do with results."

"reviewing open PRs every morning, auditing dependencies weekly, or checking for CI failures overnight"

"workspace spend limits as the backstop"

"Manage stakeholder feedback loops and expectation alignment (including SLAs)" (가이드 목표 6.3)

보통은 선을 넘으면 이해관계자 검토로 올리지만, 배포 버그면 팀이 고치고 알리며, 감사 날엔 선 안이어도 올리고, 서서히 떨어지면 상시 regression 으로 잡는다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게) — 자세한 조건은 아래 '더 깊이'에 있어요

더 깊이 : 뒤집히는 때 · 오답 재료 (설명)

뒤집히는 때

1. 서서히 떨어지면 임계값은 한참 늦음

조건 : 주 4,000건을 처리한다. 정답률은 87% 에서 시작해 주마다 0.6%p 씩 떨어진다. 알림 선은 80% 미만이다.
계산 : 87 − 0.6 × k < 80 이면 k > 11.7 이다. 그래서 12주째에야 알림이 울린다. 그동안 늘어난 실패는 4,000 × 0.006 × (1 + 2 + … + 11) = 4,000 × 0.006 × 66 ≈ 1,580건이다.
전제 : 하락이 일정하다고 본다(그림용 가정). 건수는 주마다 같다.
처방 : 품질 행(regression suite 상시)과 정기 행(매주 transcript 표본)을 출시 전에 표에 넣는다. 매주 표본은 비율보다 새 실패 모양을 먼저 보여 준다. 표본 30개로 0.6%p 차이를 숫자로 가리기는 어렵다 (추론).
등급 : 계산 (하락 모양은 가정) · 처방은 업계 일반 (regression suite · 매주 표본은 확인)
근거 : demystifying-evals

2. 선을 넘었는데 팀 안에서 끝나는 때

조건 : 월 비용 선은 $9,000 인데 사흘 만에 $4,200 를 썼다. 원인은 배포한 재시도 코드다. 이 코드가 실패 요청을 끝없이 다시 보냈다. 되돌리니 평소 속도로 돌아왔다.
판단 : 다시 정할 예산도, 고를 trade-off 도 없다. 그래서 팀이 고친다. 선을 넘었다는 사실과 원인·조치는 이해관계자에게 알린다 (업계 일반). "조용히 고치지 않는다" 는 고치되 반드시 알린다는 뜻이다. 모든 수정을 스폰서 결정으로 올리라는 뜻이 아니다.
가르는 말 : 원인이 정당한 성장이라 예산·범위를 다시 정해야 하나? 그렇다면 그때 이해관계자 검토로 올린다.
등급 : 업계 일반. 원인 좁히기는 ■ 비용 급증 추적 에 있다

3. 선 안인데도 올리는 때 — 정기 행

조건 : 규제가 걸린 배포의 분기 출력 감사 날이다. 또는 계약 마일스톤의 합격 기준을 확인하는 날이다.
판단 : 지표가 하나도 안 움직여도 그날 행이 실행된다. 결과를 이해관계자가 봐야 하는 행이다 (업계 일반).
등급 : 업계 일반 (정기 사람 검토 자체는 확인이다. demystifying-evals)

4. 알림 선을 낮추자 — 소리만 커짐

조건 : 담당자 없는 이관률 알림이 하루 3건 뜬다. 선을 18% 에서 12% 로 낮췄더니 하루 40건이 됐다.
판단 : 받는 사람이 없으면 3건이든 40건이든 조치는 0건이다. 받는 사람이 있어도 하루 40건이면 걸러 보지 못한다 (업계 일반 — 승인 피로와 같은 모양, ■ human-in-the-loop 게이트 위치).
등급 : 업계 일반

5. 비용 알림 없이 지출 한도만 있을 때

조건 : 워크스페이스 지출 한도만 걸고 지출 임계값 알림은 만들지 않았다.
판단 : 공식 문서는 지출 한도를 마지막 안전판(backstop)으로 둔다. 그래서 알림 행이 없으면 첫 신호가 "요청이 막힘"(서비스가 멈춘다)이 된다. 자세한 것은 ■ API 오류별 대응 (지출 상한 429) 에 있다. 알림 행이 먼저이고, 한도는 멈추는 장치다 (순서는 추론).
등급 : (한도 = backstop · 임계값 알림 장치) · 추론(순서)
근거 : optimizing-cost-intelligence · usage-cost-api

오답 재료

오답	왜 끌리나	왜 틀리나	등급	근거
"주간 품질 대시보드를 매주 공유하니 루프는 있다"	눈에 보이니 관리되는 것 같다	보여 주기일 뿐이다. 담당자·행동이 없으면 아무 일도 생기지 않는다. 모니터링은 사후 대응이다	업계 일반 · 확인(사후 대응)	demystifying-evals
"놓친 사례를 주간 상태 회의에서 공유하고 담당자에게 주의 당부"	소통한 것 같다	행동이 아니다. eval 셋에 안 들어가면 루프가 닫히지 않는다	업계 일반	목록 6.3② 매력적인 오답 · ■ 운영 → eval feedback loop
"알림 선을 낮춰 더 자주 울리게"	더 민감하면 더 안전해 보인다	받는 사람이 없으면 소리만 커진다	업계 일반	뒤집히는 때 4
"품질은 임계값 알림 하나면 충분"	설정이 간단하다	서서히 떨어지면 어느 알림도 선을 안 넘는다	계산 · 업계 일반	뒤집히는 때 1
"표는 출시 뒤 운영팀이 정리"	출시가 급하다	막았어야 할 사고 뒤에 써진다	업계 일반	—
"비용 선을 넘었지만 팀이 조용히 튜닝"	스폰서를 번거롭게 하지 않는다	알리지 않고 고치지 않는다. 예산 재설정은 스폰서가 한다	업계 일반	뒤집히는 때 2
"선 안의 흔들림도 전부 스폰서에게" (반대)	투명해 보인다	선 안은 팀이 처리하고 기록한다	업계 일반	—
"지출 한도가 있으니 비용 알림은 필요 없다"	한도가 막아 준다	한도는 마지막 안전판이다. 닿으면 요청이 막힌다	추론	optimizing-cost-intelligence
"놓친 사례가 나왔으니 더 큰 모델로 교체"	모델 탓을 하기 쉽다	먼저 eval 과제로 만든다. 변경부터 묻는다		목록 6.3② 매력적인 오답 · ■ 운영 → eval feedback loop · ■ 변경부터 묻는 진단

참고

함께 보기

더 깊이 : 출처 · 상태 · 미해결 (참고)

출처

상태

업계 일반 12줄(표 구조 · 모니터링만 · 담당자 1명·행동 · 비어 있는 책임 · 출시 전 품질 행 · 출시 뒤 표 · 규제·마일스톤 일정 · 정기 행이 느린 하락을 잡아냄 · 올리는 선 · 원인 먼저 · 스폰서 결정 · 선 안은 팀)
해석 3곳(루프 표로 넓힘 · 품질 행 = regression suite · 알림 → 한도 순서)

미해결

신호, 트리거, 담당자, 행동의 표 구조와 담당자 1명, 올리는 선, 스폰서 결정은 Anthropic 공식 문장이 없다. 그래서 카드에서는 업계 일반으로 둔다. ccarp/raw/official-docs/en-*.md 에서 owner · clear ownership · on-call · escalat · stakeholder · governance 를 grep 했다(제외 = ko 판 · 받지 않은 문서). 나온 것은 아래뿐이다.
- eval 셋 소유권(demystifying-evals)
- 고객 에스컬레이션(customer-support-chat-full)
- 가이드 목표 6.3 문구
- 스킬 기업 배포 안내(agent-skills-overview)
규제 정기 감사(정기 일정)는 공식 문장을 못 찾았다. periodic · quarterly 를 grep 하면 dpa이 나온다. 이것은 Anthropic 자기 조직의 정기 위험 평가다. 그래서 고객 배포 규칙으로 쓰지 않는다.
"대시보드 ≠ 루프" 에 대한 공식 문장은 세 가지까지다(demystifying-evals). 모니터링은 사후 대응이다. 신호가 시끄럽다. 채점할 정답이 없다. "담당자가 없어 안 움직임" 은 업계 일반이다.
후보 절 규칙 2 의 "계획이 handoff 에서 끝나면 이 층이 비어 있다" 는 ■ lifecycle 루프 · 규칙 ②(핸드오프 뒤 모니터링 + 반복)와 같은 말이다. 그래서 여기서 따로 쓰지 않는다.
monitoring-usage 의 비용 급증 알림은 Claude Code 텔레메트리 문맥이다. API 앱의 비용 알림은 usage-cost-api 문장을 쓴다.