■ human-in-the-loop 게이트 위치
표시가 없는 문장은 공식 문서에서 확인한 내용이에요. 다른 표시는 읽는 법
왜 배우나 — 시험이 요구하는 것
시험 목표 5.3 사람 검증 전략 · D5 규정·안전 14%Apply human-in-the-loop validation strategies
이 개념으로 푸는 판단 (할 수 있어야 하는 것)
- 5.3① 승인 요청이 하루 수백 개 — 전부 사람이 누르게 할까? — 사람 승인 게이트 위치 (빈도가 아니라 결과의 크기·되돌릴 수 있나)
- 5.2① 증상만 보고 실패에 이름을 붙일 수 있나? — 실패 유형 → 그 실패를 실제로 바꾸는 통제
- 7.3② 프로덕션 장애에서 에이전트는 어디까지? — 원인 조사(트리아지)와 복구 조치의 권한 경계
한눈에
사람 승인(human approval)은 행동 개수가 아니라 결과 크기에 건다. 되돌릴 수 없고 파괴적이거나 피해 범위(blast radius)가 남에게 미치는 행동 앞에만 사람을 세운다. 나머지는 자동으로 둔다. 사람은 언제든 멈추고 방향을 바꾼다
행동마다 승인시키면 승인 피로(approval fatigue)가 생긴다. 사람이 무엇을 승인하는지 안 본다. Claude Code 수동 권한 프롬프트는 실제로 93% 승인된다 (2026-09-28 조회)
비유 변경 관리와 같다. 표준 변경은 사전 승인 목록으로 자동 처리한다. 프로덕션 DB 삭제만 CAB 승인을 받는다. 모든 배포에 승인을 걸면 아무도 안 읽고 도장만 찍는다
ELI5
놀이터 선생님이 아이들을 지켜보는 방법을 고르는 거예요.
- 미끄럼틀 탈 때마다 허락을 받게 하면 선생님이 지쳐서 그냥 "응" 해요.
- 그래서 담 넘기처럼 다치면 되돌릴 수 없는 것만 허락받게 해요.
- 나머지는 놀게 두고, 선생님은 보다가 필요하면 멈춰요.
- 이 쪽은 "어디에 허락을 걸어야 하나"를 모아 둔 곳이에요.
개념 설명
원리
승인은 공짜가 아니다
- 승인의 비용은 사람의 주의력이다. 게이트가 많을수록 한 건당 주의가 준다. 이것이 승인 피로다. 수동 권한 프롬프트는 93% 승인된다.
- 그래서 게이트를 늘리면 보호가 늘지 않고 오히려 떨어질 수 있다. 도장만 찍는 승인은 보호가 아니다.
어디에 걸지는 틀렸을 때의 비용으로 정한다
- 되돌릴 수 있나 : 프로젝트 안 편집은 버전 관리로 되돌린다. 그래서 자동이다. force-push·대량 삭제는 못 되돌린다. 그래서 막는다.
- 피해 범위 : 내 것만인가, 공유 자원·남의 작업인가? 남에게 미치면 되돌릴 수 있어도 막는다(검토 우회·남에게 영향 묶음).
- 신뢰 경계 : 데이터가 밖으로 나가거나 밖의 코드를 들여오면 막는다. 기본으로 믿는 것은 지금 작업 중인 git repo 뿐이다.
층으로 거른다 (auto mode)
- 층은 아래 순서다.
- 1층 허용 목록(상태 못 바꾸는 도구)
- 2층 프로젝트 안 편집
- 3층 분류기(진짜 손해 가능성)
- 사람(반복 거부·고위험(high-stakes) 인프라)
- 위협은 4가지다. 과잉 행동(overeager) · 정직한 실수(피해 범위 오판) · 프롬프트 인젝션 · 목표가 어긋난 모델이다. 막는 법은 모두 "그 행동을 막기" 다.
- 주 표적은 과잉 행동이다. 악의 없이 도우려다 사용자가 허락한 선을 넘는다. 겉보기엔 합리적인 문제 해결이라 잡기 어렵다.
분류기의 약점
- 위험을 알아보는 것과 "사용자 동의가 이 행동까지 덮나" 를 판정하는 것은 다른 일이다. 놓친 것 대부분이 후자다.
- 그래서 고위험 인프라는 신중한 사람 검토를 남긴다.
핵심 질문 두 개
- 이 행동이 틀렸을 때 되돌릴 수 있나?
- 틀렸을 때 누가(나만 / 남까지) 다치나?
규칙과 판단
갈림길
①② 어디에 사람을 거나 [5.3①]
승인 없이
상태를 못 바꾸는 도구는 허용 목록에 둔다
자동
프로젝트 안 파일 편집은 분류기 없이 자동으로 둔다(버전 관리로 검토)
실행 전에 막고 사람에게
되돌릴 수 없고 파괴적이거나 피해가 남에게 미치는 행동 앞에만 사람이 선다
③④ 보기 가르기 [5.3①] [5.2①]
승인 피로
수동 확인의 93% 가 승인된다
보호 0
전부 건너뛰기다(유지보수 0·보호 0)
사람 검토를 유지한다
분류기는 고위험(high-stakes) 인프라의 신중한 사람 검토를 대신하지 않는다
일상 작업이면 맞는 방식이다
목록 5.3① 은 "두 번째 Claude 를 검토자로" 를 매력적인 오답으로 든다 (업계 일반 + ④). 그래도 일상 작업에서는 수동 승인 자리를 모델 분류기가 대신한다
먼저 뺀다
자세한 것은 ■ 최소 권한 에 있다
⑥ 동의 범위인가 [5.3①]
승인된 것
사용자가 말한 것만 승인된 것이다
미승인
에이전트가 스스로 고른 것은 사용자가 말하기 전까지 미승인이다. 한 번 승인했다고 계속 승인한 것은 아니다
흐름
그림 속 이름·금액·시간·토큰 수는 예시예요. 공식 한도·동작은 카드 본문 값이 기준.
장면 글로 보기
칸 : 에이전트 → 분류기 → 실행 → 사람
규칙 (사람) : 되돌릴 수 없고 파괴적이거나 피해가 남에게 미치는 행동 앞에만 선다
질문 : 사람은 어느 행동 앞에 서야 할까?
① 상태 안 바꾸는 도구 ✓
- 시작 : 에이전트 — 말 : “어떤 브랜치가 오래됐는지 먼저 볼게요”
- 건너뜀 : 분류기
- 읽기 : 에이전트 → 실행 : 읽기·검색은 허용 목록에 있다 — 쪽지 :
git branch -r/ → 브랜치 57개 - 끝 : 상태를 못 바꾸는 도구는 승인 없이 실행한다
② 되돌릴 수 없는 삭제 ✓
- 시작 : 에이전트 — 쪽지 : 사용자: / "오래된 브랜치 / 정리해 줘"
- 요청 : 에이전트 → 분류기 : 원격 브랜치를 일괄 삭제하려 한다 — 쪽지 :
git push origin/--delete …/ (브랜치 40개) - 막음 : 분류기 : 되돌릴 수 없고 파괴적이라 막는다 — 쪽지 : 차단 / 지시가 모호 / 되돌릴 수 없음
- 되돌림 : 분류기 → 에이전트 : 거부는 도구 결과로 돌아간다 — 쪽지 : tool_result: / 거부됨 (1번째) / → 안전한 길 찾기
- 올림 : 에이전트 → 사람 : 연속 3번 또는 총 20번 거부되면 사람에게 올린다 — 쪽지 : 연속 3번째 거부 / → 멈춤 / 사람 확인 대기
- 끝 : 되돌릴 수 없고 파괴적인 행동 앞에만 사람이 선다
③ 모든 행동에 승인 ≠
- 시작 : 에이전트 — 쪽지 : 오늘 행동 200개 / (읽기·편집·삭제)
- 요청 : 에이전트 → 사람 : 행동마다 승인을 요청한다 — 쪽지 : 허용할까요? / [예] [아니오] / (오늘 200번째)
- 도장 : 사람 : 수동 확인의 93% 를 승인한다 — 쪽지 : 예 · 예 · 예 … / 93% 그냥 승인
- 끝 : 승인 피로가 생긴다. 사람이 무엇을 승인하는지 안 본다
나머지 규칙
-
막혔을 때 : 거부는 도구 결과로 돌아간다. 에이전트는 더 안전한 길을 찾는다(우회 금지). 연속 3번 또는 총 20번 거부되면 멈추고 사람에게 올린다. 헤드리스(
claude -p)는 물을 사람이 없어 프로세스를 종료한다 (2026-09-28 조회) [5.3①] [7.3②]
규칙 원문 ①②③④⑥ (갈림길로 그린 규칙)
-
사람 앞에 세울 행동은 아래와 같다 (2026-09-28 조회) [5.3①]
- 되돌릴 수 없다
- 파괴적이다
- 공유 자원이나 남에게 영향을 준다
- 신뢰 경계 밖이다
기본 차단 규칙(20개가 넘는다)은 4개 범주로 묶인다
묶음 예 파괴·유출 force-push 로 이력 덮기 · 클라우드 저장소 대량 삭제 · 내부 데이터 외부 전송 보안 약화 로깅 끄기 · SSH 키·cron 심기 · 에이전트 자기 권한 설정 수정 신뢰 경계 넘기 외부 repo 코드 실행 · 자격증명 저장소 뒤지기 · 사용자가 말 안 한 서비스로 전송 검토 우회·남에게 영향 main 직행 push · 프로덕션 배포 · 에이전트가 안 만든 공유 자원·작업 수정 -
나머지는 자동으로 둔다. 층은 셋이다 [5.3①] [7.3②]
- 상태를 못 바꾸는 도구(읽기·검색·코드 탐색)는 허용 목록에 둔다
- 프로젝트 안 파일 편집은 분류기 없이 둔다(버전 관리로 검토)
- 진짜 손해 가능성이 있는 행동만 마지막 단계(분류기)로 보낸다
자율성 단계는 ■ 가장 작은 맞는 형태 에 있다. 사람은 언제든 멈추고 방향을 바꾼다
-
승인 피로 : 행동마다 승인하면 사람이 주의를 잃는다. 수동 확인의 93% 가 승인된다 [5.3①] [5.2①]
선택지는 셋이다
- 샌드박스 : 안전하지만 유지보수가 크다. 네트워크·호스트 접근이 필요하면 격리가 깨진다
- 전부 건너뛰기(
--dangerously-skip-permissions) : 유지보수 0·보호 0 이다 - 수동 확인 : 중간이다
auto mode 는 수동 승인 자리를 모델 분류기가 대신한다
-
분류기의 한계 : 실제 과잉 행동(overeager)을 17% 놓친다 (2026-09-28 조회). 위험은 알아보지만 "그 동의가 이 행동의 피해 범위까지 덮나" 를 틀린다. 그래서 전부 건너뛰기에 비하면 큰 개선이다. 모든 행동을 신중히 승인하던 사람에 비하면 후퇴일 수 있다. 분류기는 고위험 인프라의 신중한 사람 검토를 대신하지 않는다 [5.3①]
-
동의 범위 : 사용자가 말한 것만 승인된 것이다. 에이전트가 스스로 고른 것은 사용자가 말하기 전까지 미승인이다
- "브랜치 정리해 줘" 는 원격 브랜치 일괄 삭제 허락이 아니다
- "고칠 수 있어?" 는 질문이지 지시가 아니다
- 한 번 승인은 패턴이 아니다
더 깊이 : 판단 규칙 · 상황 변수 (설명)
판단 규칙
| 조건 | 답 | 근거 |
|---|---|---|
| 상태를 못 바꾸는 도구다(읽기·검색·코드 탐색) | 승인 없이 쓴다 (허용 목록) | claude-code-auto-mode "A fixed allowlist includes tools that can’t modify state" |
| 프로젝트 안 파일을 편집한다 | 분류기 없이 자동으로 두고, 버전 관리로 검토한다 | 같은 글 "in-project edits are reviewable via version control" |
| 요청이 모호하고, 되돌릴 수 없고 파괴적이다 | 막는다 | 같은 글 "the request was vague, the action irreversible and destructive" |
| 공유 인프라·남이 만든 자원을 바꾸거나, main 에 직행하거나, 프로덕션에 배포한다 | 막는다 | 같은 글 (Bypass review or affect others) |
| 고위험 인프라다 | 신중한 사람 검토를 유지한다(분류기로 대체하지 않는다) | 같은 글 |
| 비용·지출처럼 큰 결정(예 : 구독 해지) 직전이다 | 사람 승인(human approval)을 받는다 | safe-trustworthy-agents |
| 거부가 연속 3번 또는 총 20번이다 | 멈추고 사람에게 올린다 (헤드리스는 종료한다) | claude-code-auto-mode |
| 역할에 필요 없는 강한 도구다 | 확인창 말고 뺀다 | 가이드 샘플 1 정답 B · ■ 최소 권한 |
상황 변수
| 변수 | 값 | 답 쪽 | 등급 | 근거 |
|---|---|---|---|---|
| 되돌림 | 버전 관리로 되돌린다 | 자동 | 판단 규칙 2 | |
| 되돌림 | 못 되돌린다(이력 덮기·대량 삭제) | 막고 사람에게 올린다 | 판단 규칙 3 | |
| 대상 소유 | 에이전트가 만든 것 / 세션 작업 브랜치 | 허용 쪽이다 (예외 규칙) | "pushing to the session's working branch" | |
| 대상 소유 | 공유 자원 · 남이 만든 작업 | 막는다 | ||
| 사용자 지시 | 대상까지 명시했다 | 승인된 것이다 | ||
| 사용자 지시 | 모호하다("정리해 줘") · 질문이다("고칠 수 있어?") | 미승인이다 | ||
| 비교 기준 | 지금 전부 건너뛴다 | auto mode 가 큰 개선이다 | ||
| 비교 기준 | 지금 모든 행동을 신중히 수동 승인한다 | auto mode 는 후퇴일 수 있다 | ||
| 실행 환경 | 헤드리스(claude -p)·CI | 물을 사람이 없다. 거부가 쌓이면 종료한다 | ||
| 승인 건수 | 하루 수백 건 | 게이트를 줄여 위험 행동에만 건다 | 계산 | 뒤집히는 때 3 |
연습 문제
개발자가 코딩 Agent 에게 "오래된 브랜치 정리해 줘" 라고 했다. Agent 는 브랜치를 지우는 명령상태 바꿈을 만들었고, 대상은 팀이 같이 쓰는 원격 브랜치 40개공유 자원다. 팀은 "모든 행동에 확인창을 띄우자" 와 "권한 확인을 전부 끄자" 사이에서 고민한다. 이 행동은 어떻게 다뤄야 할까?
시험 대비
함정
- "모든 행동에 사람 승인을 거는 것이 가장 안전하다" 는 함정이다. 승인 피로가 생겨 93% 가 승인된다
- "승인이 귀찮으니 권한 확인을 전부 끈다" 는 함정이다. 보호가 0 이다. 대부분 상황에서 위험하다
- "분류기(auto mode)가 있으니 고위험 인프라도 사람 없이 간다" 는 함정이다. 분류기는 사람 검토를 대신하지 못한다
- "비슷한 걸 전에 승인했으니 이번도 OK" 는 함정이다. 한 번 승인은 패턴이 아니다. 그 동의가 이 행동의 피해 범위를 덮는지 봐야 한다
- "필요 없는 환불·삭제 도구를 두고 확인창을 띄운다" (샘플 1 C) 는 함정이다. 먼저 뺀다. 자세한 것은 ■ 최소 권한 에 있다
- "두 번째 Claude 를 검토자로" 는 목록 5.3① 의 매력적인 오답이다. 단 공식 auto mode 는 실제로 모델 분류기가 승인을 대신한다. 그래서 일상 작업이면 맞는 방식이고, 고위험이면 사람이 본다 (업계 일반 + ④)
- "강제 대기 시간 추가" 는 함정이다. 판단 기준(되돌릴 수 있나·피해 범위)을 바꾸지 않는다 업계 일반
- "AUP 의 Human-in-the-loop 가 이 게이트다" 는 함정이다. AUP 쪽 이름은 고위험 용도에서 자격 전문가가 내용·결정을 전달 전에 검토하라는 요구다. 이 카드는 되돌리기 어려운 행동 앞의 승인 위치를 다룬다. 자세한 것은 ■ AUP 고위험 용도 에 있다
신호
"Over time that leads to approval fatigue, where people stop paying close attention to what they're approving."
"Manual prompts sit in the middle, and in practice users accept 93% of them anyway."
"This would be blocked since the request was vague, the action irreversible and destructive, and the user may have only meant to delete local branches."
"It is not a drop-in replacement for careful human review on high-stakes infrastructure."
"If a session accumulates 3 consecutive denials or 20 total, we stop the model and escalate to the human."
"But humans should retain control over how their goals are pursued, particularly before high-stakes decisions are made."
더 깊이 : 뒤집히는 때 · 오답 재료 (설명)
뒤집히는 때
1. 되돌릴 수 있는데도 막아야 하는 때
- 조건 : 백업으로 되돌릴 수 있는 변경이다. 하지만 대상이 팀 공용 스테이징 큐와 다른 사람이 만든 예약 작업이다.
- 판단 : 기준은 "되돌림" 하나가 아니다. 기본 차단 묶음에 "에이전트가 안 만든 공유 자원·작업 수정" 이 따로 있다. 그래서 되돌릴 수 있어도 남에게 영향이면 막는다.
- 근거 : claude-code-auto-mode
2. 되돌릴 수 없어도 사람 없이 가는 때
- 조건 : 사용자가 "로컬 브랜치
exp-47지워 줘" 처럼 대상을 명시했다. - 판단 : 사용자가 말한 것이 승인의 범위다. 이름까지 댄 삭제는 에이전트가 고른 행동이 아니다. 그래서 이 행동은 동의 범위 안이다. 반대로 "오래된 브랜치 정리" 는 원격 일괄 삭제까지 포함하지 않는다.
- 등급 : (원칙) · 분류기가 실제로 어디까지 통과시키는지는 미해결 4
3. 하루 800건 행동 — 분류기 vs 사람, 숫자로
- 조건 : 하루 행동 800건 중 진짜 위험한 과잉 행동이 6건이라고 가정한다.
- 계산 : 분류기(전체 파이프라인)는 17% 를 놓친다. 6 × 0.17 ≈ 1건/일이 통과한다. 오탐은 0.4% 다. 794 × 0.004 ≈ 3건/일이 잘못 막히고, 각각 재시도 1번 비용이 든다.
- 비교 : 전부 건너뛰기면 6건이 전부 통과한다. 그래서 분류기가 크게 낫다. 모든 건을 신중히 보는 사람이면 이론상 0건이다. 그래서 분류기가 후퇴다. 그런데 실제 수동은 93% 승인이라 "신중한 사람" 전제가 무너진다.
- 등급 : 계산. 17%·0.4% 는 글의 평가 데이터 값이다(실제 과잉 행동 n=52, 실제 트래픽 n=10,000). 그래서 다른 트래픽에 그대로 맞는다는 보장은 없다.
4. 무인 파이프라인(헤드리스)
- 조건 : CI 에서
claude -p로 돌린다. - 판단 : 물을 사람이 없어서 거부가 쌓이면 프로세스가 종료된다. 사람 게이트가 필요한 행동(프로덕션 배포 등)은 그 파이프라인에 두지 않는다. 승인 단계를 따로 둔다.
- 등급 : 종료 동작은 확인 · 처방은 업계 일반
오답 재료
| 오답 | 왜 끌리나 | 왜 틀리나 | 등급 | 근거 |
|---|---|---|---|---|
| "모든 행동에 사람 승인" | 가장 안전해 보인다 | 승인 피로가 생긴다. 93% 가 승인되고 사람이 안 본다 | auto-mode | |
| "권한 확인을 전부 끔" | 속도·자율성이 끌린다 | 보호가 0 이다. 대부분 상황에서 위험하다 | auto-mode | |
| "분류기가 있으니 고위험 인프라도 자동" | 공식 기능이라 믿는다 | 신중한 사람 검토를 대신하지 않는다 | auto-mode | |
| "비슷한 걸 전에 승인했으니 OK" | 동의의 흔적이 있다 | 한 번 승인은 패턴이 아니다. 동의가 이 행동의 피해 범위를 덮는지 봐야 한다 | auto-mode | |
| "필요 없는 강한 도구를 두고 확인창" | 사람이 막으니 안전해 보인다 | 보완 통제(control)일 뿐이다. 먼저 뺀다 | 가이드 샘플 1 C 해설 | |
| "승인 빈도가 많으니 승인을 없앰" | 피로를 줄일 것 같다 | 빈도는 기준이 아니다. 되돌릴 수 없는 행동에는 계속 게이트를 둔다 | (원칙) | auto-mode |
| "두 번째 Claude 인스턴스를 검토자로" | 사람 비용 없이 검토한다 | 고위험 결정이면 오답이다. 일상 작업이면 공식 auto mode 방식과 같다. 그래서 보기 문맥으로 판단한다 | 업계 일반 | 미해결 3 |
| "강제 대기 시간을 둠" | 신중해질 것 같다 | 누가 무엇을 보는지를 바꾸지 않는다 | 업계 일반 | — |
| "사람을 아예 뺌" | 완전 자동화가 끌린다 | 큰 결정 전에는 사람이 통제권을 가진다 | safe-trustworthy-agents |
참고
더 깊이 : 출처 · 상태 · 미해결 (참고)
출처
- 가이드 목표 5.3 공식 시험 가이드 v1.0
- 샘플 1 공식 시험 가이드 v1.0
- claude-code-auto-mode
- safe-trustworthy-agents
상태
- 업계 일반 2줄
미해결
- 목록 문구 "빈도가 아니라 결과 크기" 의 '빈도' 는 원문에 없는 말이다. 원문 기준은 되돌릴 수 없음 · 파괴 · 피해 범위 · 동의 범위다 (claude-code-auto-mode).
- 목록의 문제 상황 "간호사용 triage 초안 vs 환자에게 가는 알림" 과 "환자에게 가는 알림" 예시는 받아 둔 원문에서 못 찾았다. 검색어는 patient·nurse·triage, 파일은 en-claude-code-auto-mode · en-safe-trustworthy-agents 다. 걸린 1건은 보안 이슈 triage 였다(safe-trustworthy-agents).
- 목록의 매력적인 오답 "두 번째 Claude 인스턴스를 검토자로" 는 공식 auto mode 와 부딪힌다. 공식 auto mode 는 모델 분류기가 사람 승인자를 대신한다( "acting as a substitute for a human approver"). 고위험·일상 중 어느 문맥인지로 갈린다.
- 명시 지시된 비가역 행동을 분류기가 실제로 통과시키는지는 모른다. 원칙만 있고 사례는 없다.
- 93% · 17% · 0.4% · 3/20 은 날짜 표기 없는 엔지니어링 글 값이다(분류기 = Sonnet 4.6 시점). 릴리스 노트에는 2026-05-28 "Auto mode 를 더 많은 사용자로 확대" 1줄만 있다(en-release-notes). 그래서 수치가 이후 바뀌었는지 모른다.
- 목록이 대비한 "샌드박싱 글 '권한 프롬프트 84% 감소'" 는 원문 파일이 없어 확인하지 않았다. HITL/HOTL 용어는 받은 원문 어디에도 없다(업계 용어).