P7-6.3 승인 정책 연습¶

Section ID: P7-6.3 Version: v2026.07.22

같은 운영 시나리오 안에서도 어떤 단계는 자동 실행하고 어떤 단계는 반드시 멈춰야 하는가를 직접 연습할 차례입니다. 승인 정책을 추상 원칙이 아니라 단계별 판단 기록으로 바꾸는 데 초점을 둡니다.

승인 정책(approval policy)과 보류 상태(hold state)를 손으로 재분류하면 도구를 쓸 수 있다와 지금 이 상황에서 자동 실행해도 된다가 서로 다른 판단이라는 점이 보입니다.

승인 정책이 그리는 실행 경계¶

• 조회 단계와 변경 단계는 왜 다른 승인 규칙을 가져야 하는가?
• 같은 변경 단계라도 왜 어떤 것은 즉시 보류해야 하는가?
• 보류 상태를 단순 실패가 아니라 운영 판단으로 어떻게 기록하는가?

핵심은 승인 정책과 보류 판단을 통해 실행 경계를 어디에 그을지 정하는 데 있습니다. 여기서 먼저 갈라야 하는 것은 모델 성능이나 검색 품질이 아니라, 같은 도구 호출이라도 어떤 단계는 자동으로 진행되고 어떤 단계는 반드시 멈춰야 하는가입니다.

판단 기준¶

• 단계별로 자동 실행 가능/승인 필요/즉시 보류를 구분할 수 있습니다.
• 보류가 기능 실패와 다른 운영 상태라는 점을 설명할 수 있습니다.
• 같은 장애 시나리오에서 더 안전한 실행 순서를 다시 써 볼 수 있습니다.

왜 승인 정책 연습이 필요한가¶

P7-6.2까지 읽으면 독자는 승인이 없으면 보류라는 원칙은 이해할 수 있습니다. 하지만 실제 운영에서는 거기서 한 단계 더 나아가 어디부터 승인 정책이 시작되는가, 왜 이 단계는 자동으로 돌리면 안 되는가, 보류 뒤 다음 행동은 무엇인가까지 직접 써 봐야 합니다.

문제가 되는 장면은 대체로 다음과 같습니다.

예를 들어 캐시 삭제 실행이 자동 복구처럼 보이면, 빠르게는 롤백보다 가벼워 보이니 자동 실행 가능이라고 적고 싶어질 수 있습니다. 하지만 더 안전한 다음 판단은 도구 이름의 무게감으로 결정하는 것이 아니라, 이 단계가 읽기인가 변경인가, 범위가 테스트 환경인가 프로덕션인가, 승인 없이 실행했을 때 독자 영향이 어디까지 가는가를 먼저 적는 것입니다. 그렇게 읽어야 겉보기에는 작은 변경과 운영 정책상 즉시 보류해야 하는 변경을 구분할 수 있습니다.

flowchart TD
  A["문제 장면<br/>캐시 삭제 실행이 빠른 복구처럼 보임"]
  B["빠른 판단<br/>가벼운 작업이니 자동 실행 가능"]
  C["행동 종류 확인<br/>읽기인가 변경인가"]
  D["영향 범위 확인<br/>테스트인가 프로덕션인가"]
  E["승인 필요성 확인<br/>무승인 실행 시 영향은 어디까지인가"]
  F["더 안전한 판단<br/>변경 범위와 승인 정책으로 판정"]

  A --> B
  A --> C --> D --> E --> F

즉, 에이전트 품질은 도구 수가 아니라 실행 경계를 얼마나 분명히 적는가에서도 갈립니다. 역할은 바로 그 경계를 독자가 직접 다시 그어 보는 데 있습니다.

입력 파일¶

• 단계 기록 파일: p7-6-permission-log.csv · CSV 미리보기
• 연습 정책 파일: p7-6-approval-cases.csv · CSV 미리보기
• 단계 기록 파일의 한 행 의미: 도구 한 단계의 권한·승인 기록
• 연습 정책 파일의 한 행 의미: 승인 정책을 다시 판단해 볼 단계 한 개

기존 권한 기록과 연습용 단계 후보를 함께 읽습니다. 이렇게 두면 이미 남아 있는 실행 기록과 새 정책 연습을 같은 운영 시나리오 안에서 연결해 읽을 수 있습니다.

연습 흐름¶

flowchart TD
  A["단계 읽기"]
  B["조회 / 변경 / 기록 구분"]
  C["자동 실행 가능 여부 판정"]
  D["승인 필요 / 보류 / 실행 가능 기록"]
  E["더 안전한 다음 행동 다시 쓰기"]

  A --> B --> C --> D --> E

이 흐름에서 중요한 점은 승인 여부만 보지 않고, 왜 이 범위에서는 보수적으로 멈춰야 하는가까지 함께 적는 것입니다.

실행 기록 기준¶

1. 같은 장애 시나리오 안에서 각 단계를 자동 실행 가능, 승인 필요, 즉시 보류로 다시 분류합니다.
2. 보류 단계 하나를 골라 더 안전한 다음 행동을 다시 씁니다.
3. 실행 순서를 바꾸면 왜 위험해지는지 한 문장으로 정리합니다.

Python 예제¶

예제는 승인 정책을 표로만 보지 않고 실제 분류 결과로 다시 읽는 것입니다. 코드가 길어 보이더라도 실제로는 권한 기록 위에 정책 판정(policy_decision)과 더 안전한 다음 행동을 한 번 더 얹는 구조입니다.

• 문제 상황: 에이전트 단계들을 승인 정책 기준으로 다시 분류한다.
• 입력: 기존 권한 기록 5개, 연습용 단계 후보 6개
• 기대 출력: 단계별 정책 판정, 자동 실행 가능 단계 목록, 즉시 보류 단계 목록, 재작성된 다음 행동
• 확인할 개념:
• 읽기 단계는 자동화하기 쉬워도 변경 단계는 별도 기준이 필요하다
• 보류는 막혔다는 뜻이 아니라 승인 절차를 먼저 밟으라는 뜻일 수 있다
• 영향 범위가 넓을수록 같은 변경 도구도 더 보수적으로 다뤄야 한다

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

# agent 도구 사용 사례를 읽기, 쓰기, 변경 권한과 승인 여부로 분류해 자동 실행, 승인 후 실행, 즉시 보류를 판단하는 예제입니다.
import csv
from pathlib import Path

base_path = Path("docs/assets/part-07/chapter-06/p7-6-permission-log.csv")
case_path = Path("docs/assets/part-07/chapter-06/p7-6-approval-cases.csv")

base_rows = list(csv.DictReader(base_path.open(encoding="utf-8")))
case_rows = list(csv.DictReader(case_path.open(encoding="utf-8")))
대표_base_steps = {str(step) for step in range(1, 6)}
대표_case_ids = {f"연습-{step:02d}" for step in range(1, 7)}
base_rows = [row for row in base_rows if row["step"] in 대표_base_steps]
case_rows = [row for row in case_rows if row["case_id"] in 대표_case_ids]

def classify_policy(row):
    permission = row["permission"]
    approved = row["approved"]
    scope = row["scope"]

    if permission == "읽기":
        return "자동 실행 가능", "관찰 단계이므로 현재 정책 안에서 자동화 가능"
    if permission == "쓰기" and "문서" in scope:
        return "자동 실행 가능", "서비스 상태를 바꾸지 않는 기록 단계"
    if permission == "변경" and approved == "예":
        return "승인 후 실행", "승인된 변경 단계이므로 제한적으로 진행 가능"
    if permission == "변경" and ("프로덕션" in scope or "공개" in scope):
        return "즉시 보류", "서비스 영향 범위가 커서 사람 승인과 재확인이 먼저 필요"
    return "추가 검토", "정책 기준이 더 필요함"

exercise_records = []
for row in case_rows:
    decision, reason = classify_policy(row)
    safer_next_action = (
        "현재 상태 보고 후 온콜 리드 승인 요청"
        if decision == "즉시 보류"
        else "기록 남기고 다음 조회 단계 진행"
    )
    exercise_records.append({
        "case_id": row["case_id"],
        "tool": row["tool"],
        "focus": row["focus"],
        "policy_decision": decision,
        "reason": reason,
        "safer_next_action": safer_next_action,
    })

summary = {
    "기존 기록 단계 수": len(base_rows),
    "연습 단계 수": len(exercise_records),
    "자동 실행 가능 단계 수": sum(
        record["policy_decision"] == "자동 실행 가능"
        for record in exercise_records
    ),
    "즉시 보류 단계 수": sum(
        record["policy_decision"] == "즉시 보류"
        for record in exercise_records
    ),
    "가장 먼저 다시 볼 단계": [
        record["case_id"]
        for record in exercise_records
        if record["policy_decision"] == "즉시 보류"
    ],
}

print("정책 연습 요약 =", summary)
print("읽은 기존 기록 파일 =", str(base_path))
print("읽은 연습 정책 파일 =", str(case_path))
print("연습 기록 =")
for row in exercise_records:
    print(row)

실행 결과 예시는 다음과 같습니다.

1
2
3
4
5
6
7

정책 연습 요약 = {'기존 기록 단계 수': 5, '연습 단계 수': 6, '자동 실행 가능 단계 수': 3, '즉시 보류 단계 수': 3, '가장 먼저 다시 볼 단계': ['연습-03', '연습-05', '연습-06']}
읽은 기존 기록 파일 = docs/assets/part-07/chapter-06/p7-6-permission-log.csv
읽은 연습 정책 파일 = docs/assets/part-07/chapter-06/p7-6-approval-cases.csv
연습 기록 =
{'case_id': '연습-03', 'tool': '롤백 실행', 'focus': '승인 없이는 멈춰야 하는 변경 단계', 'policy_decision': '즉시 보류', 'reason': '서비스 영향 범위가 커서 사람 승인과 재확인이 먼저 필요', 'safer_next_action': '현재 상태 보고 후 온콜 리드 승인 요청'}
{'case_id': '연습-05', 'tool': '캐시 삭제 실행', 'focus': '자동 복구처럼 보이지만 승인 정책이 필요한 단계', 'policy_decision': '즉시 보류', 'reason': '서비스 영향 범위가 커서 사람 승인과 재확인이 먼저 필요', 'safer_next_action': '현재 상태 보고 후 온콜 리드 승인 요청'}
{'case_id': '연습-06', 'tool': '임시 우회 설정 반영', 'focus': '영향 범위가 넓어 더 보수적으로 다뤄야 하는 단계', 'policy_decision': '즉시 보류', 'reason': '서비스 영향 범위가 커서 사람 승인과 재확인이 먼저 필요', 'safer_next_action': '현재 상태 보고 후 온콜 리드 승인 요청'}

결과를 어떻게 읽는가¶

이번 연습의 핵심은 변경 도구라서 위험하다보다 어느 범위까지 바꾸는가가 더 중요하다는 점입니다.

이 차이를 통해 독자는 두 가지를 잡아야 합니다.

• 자동 실행 가능은 성능 문제가 아니라 현재 정책 아래에서 안전 범위 안이라는 뜻입니다.
• 즉시 보류는 실패가 아니라, 다음 행동을 승인 요청이나 사람 검토로 바꾸라는 운영 신호입니다.

즉, 에이전트 프로젝트에서 중요한 것은 도구 호출 성공보다 어떤 상태에서 멈춰야 하는가를 미리 정하는 일입니다.

결과 해석 기준¶

• 같은 변경 단계라도 범위가 넓어지면 왜 더 보수적 판정이 필요한가?
• 보류 뒤에 붙는 다음 행동은 왜 단순 재시도가 아닌가?
• 조회 단계와 기록 단계는 왜 같은 자동 실행 가능이라도 다른 성격으로 읽어야 하는가?
• 승인값을 예로 바꾸면 무엇이 달라지고, 무엇은 여전히 남는가?

프로젝트 기록 예시¶

실습 뒤에는 다음 형식으로 짧게 기록해 두는 편이 좋습니다.

한 문단으로 쓰면 예를 들어 다음처럼 정리할 수 있습니다.

캐시 삭제 실행은 겉으로 보면 빠른 자동 복구처럼 보이지만, 범위가 결제 서비스 프로덕션이기 때문에 현재 정책에서는 즉시 보류로 두는 편이 안전하다. 이 단계는 기능 부족이 아니라 승인 절차 미완료 상태로 읽어야 하며, 더 안전한 다음 행동은 자동 재시도가 아니라 현재 상태 보고와 온콜 리드 승인 요청이다. 따라서 다음 반복에서는 복구 속도만 볼 것이 아니라 변경 범위와 승인 정책이 실제로 맞는지부터 다시 검토해야 한다.

직접 바꿔 보며 확인할 것¶

1. 롤백 실행의 approved 값을 예로 바꿔 봅니다. 관찰할 점: 보류가 사라져도 왜 여전히 변경 단계라는 사실은 남는가?

2. 상태 보고 작성의 범위를 외부 공지처럼 더 넓게 바꿔 봅니다. 관찰할 점: 시스템 변경은 아니어도 공개 범위가 넓어지면 판정이 더 보수적으로 이동하는가?

3. 연습 파일에 테스트 환경 재시작 같은 새 단계를 하나 추가해 봅니다. 관찰할 점: 같은 변경이어도 테스트 환경과 프로덕션 환경을 같은 기준으로 두면 왜 곤란한가?

판단 기준은 보류가 사라졌는가보다 변경 범위가 어디까지 열렸는가입니다. 승인값이 예로 바뀌어도 프로덕션 변경은 기록과 사후 확인을 남겨야 하고, 공개 범위가 넓어지면 시스템 변경이 아니어도 더 보수적으로 읽어야 합니다.

체크리스트¶

출처와 참고 자료¶

• 승인 정책 연습 파일: p7-6-approval-cases.csv
• 이 문서는 자체 실습 예시를 사용했습니다. 외부 자료를 직접 인용하지 않았습니다.