승인 큐에서 죽은 파일럿
한 운영팀에 사흘 만에 만든 작은 보조 도구가 있었다. 내부 전용, 민감정보 없음, 자동 실행 없음 — 위험으로 따지면 가장 낮은 칸이다. 그런데 두 달을 떠 있었다. 회의가 격주였고, 안건이 밀렸고, “혹시 모르니 보안도 보자”가 붙었고, 보안은 또 다른 격주 회의를 기다렸다. 만든 사람은 다른 일로 넘어갔고, 도구는 큐 안에서 조용히 죽었다.
같은 조직에서 고객 권리에 영향을 주는 고위험 자동화는 정반대로 빨랐다. 데모가 좋았고, 한 임원이 밀었고, “일단 켜고 보완하자”로 통과됐다. 사고는 거기서 났다.
두 장면은 같은 병이다. 저위험을 고위험만큼 무겁게 심의하고, 고위험을 저위험만큼 가볍게 통과시킨다. 모든 승인을 같은 속도로 굴리면 거버넌스는 안전한 것을 막고 위험한 것을 흘려보낸다. 승인 체계를 운영에 넣어보며 가장 비싸게 배웠다. 병목은 통제가 많아서가 아니라 위험과 무관하게 균일해서 생긴다.
이 장은 짧다. 본문 척추가 아니라 신호이기 때문이다. 다룰 것은 둘뿐이다 — (1) 누가 무엇을 승인하는가(RACI), (2) 무엇을 사람이 안 보고 통과시키는가(Policy as Code, 정책을 코드로 집행하는 방식).
핵심 프레임: 승인은 분류가 먼저다
속도와 통제는 분리하는 게 아니라, 위험 등급으로 갈라 붙인다. 저위험은 사람을 거치지 않고 통과(패스트트랙), 고위험만 강화 심의로.
이 원리가 작동하려면 승인보다 분류가 먼저여야 한다. 요청을 저위험·일반·고위험으로 먼저 나눠야 적절한 경로로 보낼 수 있다. 분류를 건너뛰고 모든 요청을 같은 테이블에 올리는 순간, 저위험 도구가 고위험 안건 뒤에 줄을 선다. 도입부의 죽은 파일럿이 그 결과다.
분류 기준과 3트랙 판정(패스트트랙·일반 심의·강화 심의)은 16장의 위험 등급(Low/Medium/High/Critical)과 실행 경로 표를 그대로 쓴다(16장 참조). 이 장은 그 등급을 승인 경로로 번역하는 데만 집중한다.
승인 경로 결정 트리
[AI 사용 요청 접수]
│
▼
Q1. 내부 전용 + 민감정보 없음 + 자동 실행 없음 + 샌드박스인가?
├─ 예 ──────────────────────────────▶ 패스트트랙 (즉시 자동 승인, 사람 개입 0)
└─ 아니오
│
▼
Q2. 고객 권리·금전·법적 효력·민감정보·외부 쓰기 권한이 걸리는가?
├─ 예 ──────────────────────────────▶ 강화 심의 (운영+보안 위원회, 사람 필수)
└─ 아니오
│
▼
Q3. 이전에 승인된 패턴과 동일한 구성인가?
├─ 예 ──────────────────────────────▶ 자동 승인 + 기록 (정책 엔진)
└─ 아니오 ───────────────────────────▶ 일반 심의 (운영 위원회 Async)순서에 의미가 있다. 대부분의 내부 실험은 Q1에서 끝나고, 테이블에 올라가는 것은 Q2(고위험)와 Q3의 새 패턴뿐이다. 위원회를 비우는 것이 위원회를 빠르게 만드는 유일한 방법이다.
단계별 적용
1단계 — RACI 1장으로 책임 공백을 없앤다
승인이 막히는 첫 원인은 속도가 아니라 책임 공백이다. 미션에 owner가 없으면 착수가 멈추듯, 결정에 Accountable이 없으면 승인이 멈춘다. RACI를 길게 설계하지 마라. 리더가 요구할 것은 한 장이고, 설계 규칙은 네 개뿐이다.
| 규칙 | 의미 | 위반 시 증상 |
|---|---|---|
| Accountable은 1명·1조직 | 최종 책임을 다중 지정하지 않는다 | “둘 다 자기 일 아니라고 한다” |
| 고위험만 상위로 | 일반 케이스는 운영 위원회·실무에서 종결 | 사소한 건이 전략 위원회까지 올라간다 |
| 보안·법무는 기본 Consulted | 단, 고영향·민감정보·사고는 Approver | 모든 건에 보안 승인이 붙어 큐가 막힌다 |
| 영역 오너를 먼저 배정 | 중앙 조직이 보안·데이터·인프라를 대체하지 않는다 | “그건 우리 책임 아닌데요”가 핸드오프를 막는다 |
승인 RACI는 이 한 표로 충분하다. 행은 결정 유형, 열은 등급, 칸은 **최종 승인권자(Accountable)**다.
| 결정 유형 | 저위험(패스트트랙) | 일반(Medium) | 고위험(High/Critical) |
|---|---|---|---|
| 내부 생산성 도구 도입 | 정책 엔진 자동 (R/A) | 운영 위원회 | 보안 위원회 경유 |
| 고객 대면 기능 출시 | — | 운영 위원회 | 전략 위원회 |
| 민감정보 처리 | — | 보안 위원회 | 보안 책임자 + 법무 |
| 모델·벤더 변경 | 동일 패턴 자동 기록 | 운영 위원회 | 운영·전략 위원회 |
| 자율 실행 확대(외부 쓰기) | — | 운영 위원회 | 전략 위원회 (16장 참조) |
핵심: **저위험 열의 칸이 ‘사람’이 아니라 ‘정책 엔진’**이라는 것이 이 표의 전부다. 사람이 채울 칸은 오른쪽 두 열뿐이다.
2단계 — Policy as Code로 저위험을 사람에게서 떼어낸다
RACI가 ‘누가’를 정했다면, Policy as Code는 ‘사람이 아예 안 보는 경로’를 만든다. 사람이 정책(허용·금지 기준·등급 루브릭·패스트트랙 조건)을 정의하면, 엔진이 그것을 읽어 분류·검증·승인을 집행한다. 위원회는 정책 설계와 예외 심의에만 남는다.
| 활동 | 사람(위원회·팀) | 정책 엔진 |
|---|---|---|
| 정책 정의 | 허용·금지선·등급 루브릭·패스트트랙 조건을 정한다 | 정책을 읽고 해석한다 |
| 분류 | 경계·신규 패턴만 검토 | 입력 속성으로 자동 분류 |
| 승인 | 고위험·예외만 심의 | 패스트트랙 조건 충족 시 즉시 자동 승인 |
| 에스컬레이션 | 올라온 건을 심의 | 예외·고위험·경계를 자동으로 올림 |
| 감사 | 정책을 개선 | 모든 결정 근거를 자동 기록 |
엔진이 사람 개입 없이 즉시 처리하는 자동 통과 케이스는 좁고 분명해야 한다.
| 자동 통과 케이스 | 조건 |
|---|---|
| 패스트트랙 저위험 실험 | 내부 전용·민감정보 미사용·자동 실행 없음·샌드박스 |
| 기존 승인 범위 내 동일 패턴 변경 | 승인된 패턴과 동일 구성 |
| 만료된 예외 | 만료일 도달 시 자동 재심의 요청 |
| 비용 임계치 초과 | 설정 임계치 초과 시 자동 알림·에스컬레이션 |
주의: 자동 통과는 ‘책임 면제’가 아니다. 모든 자동 승인은 근거와 함께 기록되어야 한다. 기록되지 않은 자동 통과는 통제가 아니라 사각지대다.
3단계 — 엔진이 멈춰도 승인은 멈추지 않게 한다
“엔진이 죽으면 전부 멈추지 않나?” 그래서 대체 경로(Fallback)를 승인 체계의 일부로 함께 설계한다. 이하 Fallback으로 줄인다. 엔진 장애 시 저위험 건은 담당 팀 판단으로 1영업일 내 수동 승인하고, 복구 후 감사 로그에 소급 입력한다. 패스트트랙 자동 승인만 일시 불가일 뿐, 승인은 멈추지 않는다. Fallback을 빼고 출범한 엔진을 직접 굴려보며, 첫 점검일에 전사 승인이 멎고 나서야 그 빈칸이 보였다. Fallback 없는 Policy as Code는 승인하지 않는 게 맞다.
체크리스트 — 승인 경로를 가속으로 만들었는지
- 분류가 승인보다 먼저 있는가(등급을 나누는 단계가 요청 접수 직후에 있는가).
- 패스트트랙 4조건이 명문화되어 있는가(내부·비민감·비자동실행·샌드박스).
- 절대 금지선(Don’ts)이 따로 박혀 있는가(인사 자동 결정·무승인 민감정보 입력·무제한 에이전트 등).
- RACI에서 Accountable이 단일인가.
- 보안·법무가 고위험에만 Approver로 붙는가.
- 자동 승인이 근거와 함께 기록(감사 가능)되는가.
- 예외에 만료일과 종료 조건이 붙는가.
- 엔진 장애 Fallback이 설계에 포함되어 있는가.
- 영역 오너(domain/security/data/infra)가 요청 단계에서 지정되는가.
- 승인된 에이전트가 운영 등록부에 등록돼 추적되는가(16장) — 승인은 한 번, 운영은 계속된다.
하나라도 비면, 그 칸이 다음 병목이 된다.
흔한 실패모드
레드플래그는 회의에서 들리면 의심할 문장이다.
1 — 균일 심의. 등급과 무관하게 모든 요청을 같은 위원회·주기로 돌려 저위험이 고위험 뒤에 줄 서서 죽는다. 레드플래그: “일단 다 위원회에 올려서 보겠습니다.” 차단: 트리 Q1 — 패스트트랙을 먼저 빼낸다.
2 — 분류 생략. 등급으로 나누지 않고 선착순으로 처리해 우선순위가 매번 즉흥이 된다. 레드플래그: 접수 화면에 위험·데이터·자율성 입력 칸이 없다. 차단: “승인보다 분류가 먼저” 원칙.
3 — 보안·법무 전면 배치. 모든 건에 보안·법무 승인을 걸어 고위험을 깊이 볼 시간이 저위험 결재에 잠식된다. 레드플래그: 내부 비민감 도구에도 보안 사인오프가 걸려 있다. 차단: 보안·법무는 기본 Consulted, 고영향·민감정보·사고에서만 Approver.
4 — 자동화 = 무기록. 패스트트랙을 “사람이 안 보는 것”으로만 이해해 근거를 안 남겨 감사 시 “누가 왜 통과시켰나”를 못 댄다. 레드플래그: 자동 승인 건에 Approval ID·판단 근거가 없다. 차단: 자동 결정은 감사 가능해야 한다.
5 — 만료 없는 예외. 종료 조건 없는 “예외 승인”이 영구 통로가 되어 위험이 누적된다. 레드플래그: 예외 승인서에 만료일이 비어 있다. 차단: 예외는 사유·기간·만료일·보완계획을 함께 승인(최대 재검토 90일).
6 — Fallback 부재. 단일 엔진에 장애 절차가 없어 점검 한 번에 전사 승인이 멎는다. 레드플래그: “엔진 죽으면요?”에 답이 없다. 차단: 3단계 Fallback 절차.
통제의 총량은 줄지 않는다. 고위험에는 오히려 더 두꺼워진다. 바뀌는 것은 통제를 위험에 비례해 배분했다는 것뿐이다.
리더가 승인·요구할 신호
요구할 것
- 책임지는 AI 원칙(공정성·투명성·안전성·프라이버시·책임성·포용성)을 ‘허용 기준선’으로 명문화한 RACI 1장. 원칙이 선언으로만 떠 있으면 승인이 즉흥이 된다. “이 등급은 누가 승인하고, 무엇이면 자동 통과이며, 무엇은 절대 금지인가”의 한 장으로 번역해 오게 하라. 그 한 장이 없으면 테이블에 올리지 않는다.
- 모든 결정 유형에 단일 Accountable과, 저위험 칸의 ‘정책 엔진’ 명시. 자동 통과 건의 감사 기록. 예외의 만료일. 엔진 장애 Fallback.
반려할 것
- 위험 등급과 무관하게 모든 건을 같은 위원회에 올리는 균일 심의 설계.
- 보안·법무를 전 건 Approver로 박아 큐를 막는 설계.
- 근거를 안 남기는 자동 승인, 만료 없는 예외, Fallback 없는 단일 엔진.
승인할 것
- 저위험 패스트트랙 경로 — 내부 전용·민감정보 미사용·자동 실행 없음·샌드박스 4조건을 모두 만족하는 실험은 사람 심의 없이 정책 엔진이 즉시 통과시키도록 승인한다. 막으면 Shadow AI(우회 사용)만 늘 뿐이다.
- 절대 금지선(Don’ts) — 인사 의사결정 단독 자동화, 무승인 민감정보 입력, 무제한(외부 쓰기) 에이전트 배포, 허위 인간 위장, 설명 불가능한 고위험 자동화. 이 선은 등급과 무관하게 항상 차단이다. 패스트트랙을 넓게 열되 금지선은 타협하지 않는다.
위험 등급·자율성 레벨은 16장, 3계층 위임 경계는 18장 참조. 여기서 리더가 쥘 것은 단 두 레버다 — 저위험을 얼마나 넓게 자동으로 열 것인가, 금지선을 어디에 그을 것인가.
이 장의 요약
- 승인 병목은 통제가 많아서가 아니라 통제가 위험과 무관하게 균일해서 생긴다.
- 승인보다 분류가 먼저다. 저위험은 패스트트랙(엔진 자동 통과), 고위험만 강화 심의로 — 위원회를 비우는 것이 위원회를 빠르게 만든다.
- RACI는 한 장으로(단일 Accountable, 고위험만 상위로, 보안·법무는 기본 Consulted, 영역 오너 선배정). Policy as Code는 자동 통과도 근거를 기록하고 엔진 장애 Fallback을 함께 설계한다.
- 리더가 쥘 두 레버는 저위험을 얼마나 넓게 자동으로 열 것인가와 절대 금지선을 어디에 그을 것인가다.