사람 승인은 시스템이 실제로 할 수 있는 행동을 바꿀 때만 의미가 있습니다. 이미 되돌릴 수 없는 행동을 실행한 뒤 알림만 보내거나, 판단에 필요한 증거 없이 승인 버튼을 누르게 하거나, 한 사람이 검토할 수 없는 양의 요청을 계속 쌓는 구조는 실질적인 human-in-the-loop가 아닙니다.
NIST AI 위험 관리 프레임워크는 사람 역할과 책임, 감독 방법, 배포 여부 결정, 위험 허용 수준에 맞는 통제를 명확히 정의하고 문서화하도록 요구합니다. OWASP의 excessive agency 지침도 보안 관점에서 같은 결론을 제시합니다. 모델이 도구를 호출할 수 있다는 이유만으로 결제, 삭제, 발행, 권한 변경 같은 고영향 행동까지 위임해서는 안 됩니다.
이 글은 일반적인 업무 자동화에서 준비, 추천, 승인, 실행을 분리하는 8단계 설계법을 설명합니다. 글 발행, 메시지 전송, 기록 변경, 구매, 접근 권한 부여, 외부 시스템 조작 같은 업무에 적용할 수 있습니다. 의료·법률·안전·보안·규제 영역의 전문 검토를 대체하지는 않습니다.
1. 업무를 의사결정과 상태 변경으로 분해하기
먼저 모델이 아니라 현재 업무 흐름을 그립니다. 입력이 들어와 최종 결과가 나올 때까지 각 단계를 나열하고, 단순 조회인지, 초안 생성인지, 추천인지, 저장된 상태 변경인지, 외부 전달인지, 비용이나 의무를 만드는 행동인지 표시합니다.
각 단계에는 다음을 기록합니다.
- 담당 주체
- 읽고 쓰는 데이터
- 기준 저장소
- 내려야 하는 판단
- 실제 복구 가능성
- 오류가 발생했을 때의 최대 피해
- 검토자가 볼 수 있는 증거
- 승인 기한
“고객 요청을 처리한다”처럼 넓게 쓰지 마세요. 분류, 자료 조회, 초안 생성, 검토, 승인, 전송, 기록, 예외 처리로 나눠야 승인 경계가 보입니다.
모델이 답변 초안을 준비하는 것은 비교적 안전할 수 있습니다. 그러나 같은 모델이 그 답변을 외부 고객에게 바로 보내면 평판, 계약, 개인정보, 보안 문제가 발생할 수 있습니다. 준비와 실행은 같은 작업처럼 보여도 위험 수준이 다릅니다.
2. 영향과 복구 가능성으로 행동 등급 정하기
승인 강도는 오류의 결과에 맞춰야 합니다. 쉽게 되돌릴 수 있는 낮은 영향의 수정과 결제, 삭제, 권한 변경, 공개 발표, 계약상 의무를 만드는 행동을 같은 방식으로 다루면 안 됩니다.
실무에서는 다음 네 등급이 유용합니다.
| 등급 | 대표 행동 | 기본 통제 |
|---|---|---|
| 읽기 전용 | 검색, 요약, 비교 | 로그와 원출처 표시 |
| 되돌릴 수 있는 초안 | 글, 태그, 수정안 준비 | 외부 사용 전 사람 검토 |
| 제한된 쓰기 | 기록 수정, 티켓 생성, 콘텐츠 예약 | 승인, 검증, 복구 절차 |
| 고영향 행동 | 전송, 공개, 결제, 삭제, 권한 부여, 배포 | 지정 승인자, 독립 검사, 강한 권한 통제 |
복구 가능성은 추측이 아니라 입증되어야 합니다. 백업이 있을 것이라는 이유로 삭제를 안전하다고 분류하지 마세요. 실제 복원 절차, 보존 기간, 담당자와 복구 시간을 확인해야 합니다. 공개 게시물도 삭제할 수 있지만 복사본과 화면 캡처는 남을 수 있습니다.
영향을 판단하기 어렵다면 근거가 생길 때까지 더 엄격한 등급을 적용합니다.
3. 모델에 필요한 최소 기능과 권한만 주기
모델이 승인 대상보다 넓은 권한을 이미 가지고 있다면 승인 화면은 약한 통제에 불과합니다. 승인 기능을 만들기 전에 도구, 자격 증명, 접근 가능한 기록, 네트워크 목적지와 실행 범위를 줄이세요.
예를 들면 다음과 같습니다.
- 요약 업무에는 읽기 전용 권한만 제공
- 이메일 작성 도구에는 발송 권한을 제공하지 않음
- 콘텐츠 자동화는 Production이 아니라 검토 큐에 기록
- 제품 추천 에이전트에는 주문 권한을 제공하지 않음
- 고객 지원 도구가 답변과 계정 권한 변경을 동시에 수행하지 않게 분리
범용 셸, 브라우저, 데이터베이스, 파일시스템 도구보다 매개변수와 범위가 좁은 전용 도구를 사용합니다. 행동 허용 여부는 모델의 판단이 아니라 실제 downstream 시스템의 권한 검사로 강제해야 합니다.
OWASP는 excessive agency의 원인을 excessive functionality, excessive permissions, excessive autonomy로 구분합니다. 세 요소를 각각 줄이고, 가능하면 모두 줄여야 방어 가능한 경계가 만들어집니다.
4. 첫 번째 결과 발생 전에 승인 배치하기
좋은 승인 지점은 사람이 아직 피해를 막을 수 있는 마지막 순간입니다.
공개 글은 배포 완료 알림 이후가 아니라 발행 전에 승인해야 합니다. 이메일은 전송 전에, 데이터베이스 변경은 쓰기 transaction 전에, 구매는 결제와 계약 의무가 생기기 전에 승인해야 합니다.
모든 내부 단계마다 승인을 요구하는 것도 좋지 않습니다. 지나치게 많은 확인창은 검토자를 생각 없이 클릭하게 만듭니다. 낮은 위험의 준비 과정은 하나의 검토 패키지로 묶고, 실제 결과가 발생하는 전환점에만 명확한 승인을 둡니다.
승인을 기다리는 동안 시스템은 멈춰야 합니다. 응답 시간이 지났다고 자동 승인하거나, 과거에 승인한 비슷한 요청을 새 요청의 승인으로 재사용해서는 안 됩니다.
5. 실제 판단에 필요한 증거 제공하기
승인 요청은 무엇이 실행될지를 정확히 보여줘야 합니다. 모델이 만든 마지막 요약 문장만 보여주는 것으로는 부족합니다.
좋은 승인 패키지는 다음을 포함합니다.
- 실행될 행동을 평문으로 설명한 내용
- 정확한 대상과 범위
- 사용한 원자료와 링크
- 중요한 가정과 불확실성
- 이전 승인 상태와의 차이
- 정책·스키마·검증 결과
- 예상되는 부수 효과
- 복구 또는 롤백 경로
- 승인자의 신원과 권한
- 재생성해야 하는 만료 시각
콘텐츠 발행이라면 제목, route, 한·영 쌍, 출처, disclosure, 예약 시각과 diff를 보여야 합니다. 권한 변경이라면 대상 사용자, 역할, 적용 자원, 기간과 현재 권한을 보여야 합니다. 결제라면 공급자, 금액, 통화, 청구서, 예산 책임자와 중복 결제 검사 결과가 필요합니다.
검토자가 여러 시스템을 돌아다니며 판단 근거를 재구성하지 않게 하되, 원출처를 또 다른 AI 요약으로 대체해서도 안 됩니다.
6. 제안·검증·승인·실행을 분리하기
하나의 모델 응답이 행동을 제안하고, 스스로 유효하다고 판정하고, 승인하고, 바로 실행하도록 만들지 마세요. 작은 조직에서 한 사람이 여러 역할을 맡더라도 시스템 단계는 분리하는 것이 좋습니다.
권장 패턴은 다음과 같습니다.
- 제안자: AI 또는 사람이 후보 행동을 준비합니다.
- 검증기: 결정론적 검사가 스키마, 정책, 범위와 전제조건을 확인합니다.
- 검토자: 사람이 의미, 증거, 예외와 위험을 평가합니다.
- 승인자: 권한 있는 사람이 정확한 payload를 승인합니다.
- 실행기: 범위가 좁은 서비스가 승인된 행동만 수행합니다.
- 기록기: 누가 무엇을 승인했고 실제 결과가 무엇인지 보존합니다.
검증기는 누락 필드, 위험 경로, 오래된 버전, 예상하지 않은 파일 수, 중복 요청과 정책 위반을 사람에게 보여주기 전에 차단해야 합니다. 사람 판단은 소프트웨어가 정확히 검사할 수 있는 형식 문제가 아니라 의미와 결과에 집중해야 합니다.
영향이 큰 업무에는 독립 검토가 필요할 수 있습니다. NIST는 위험 허용 수준에 따라 시스템 개발에 직접 참여하지 않은 내부 전문가나 독립 평가자를 정기 평가에 포함하도록 권장합니다.
7. 승인을 정확하고 짧게 유효한 payload에 묶기
승인 후 내용이 바뀌었는데도 같은 승인을 사용할 수 있어서는 안 됩니다. 승인 대상 payload, 실행 대상, 승인자와 만료 시각을 안정적인 식별자나 digest에 묶으세요.
다음 중 하나라도 바뀌면 실행을 거부해야 합니다.
- 내용이나 매개변수
- 실행 대상
- 기준 record version
- 필수 증거
- 승인 유효 기간
- 승인자의 권한
- 이미 실행됐는지 여부
재시도로 결제, 전송, 발행, 삭제가 중복 실행되지 않도록 idempotency를 적용합니다. 수정 전 expected version을 기록하고 현재 상태가 다르면 fail closed 처리합니다.
Git 기반 발행에서는 expected head SHA가 좋은 예입니다. 검토한 commit이 여전히 PR head일 때만 merge되므로, 이동할 수 있는 branch 이름이 아니라 정확한 내용에 승인이 연결됩니다.
8. 거절·에스컬레이션·복구·모니터링 설계하기
승인 과정에는 예 버튼만 있어서는 안 됩니다. 거절, 수정 요청, 불확실, 시간 초과, 시스템 실패, 침해 의심에 대한 결과가 각각 필요합니다.
다음을 정하세요.
- 거절된 항목을 누가 받는가
- 모델이 자동으로 다시 작성할 수 있는가
- 재시도 횟수는 몇 번인가
- 언제 도메인 전문가에게 넘기는가
- 어떤 조건에서 영구 중단하는가
- 긴급 비활성화 방법은 무엇인가
- 무엇을 누가 롤백할 수 있는가
- 어떤 사건이 incident review를 시작하는가
승인율, 거절 이유, override 빈도, 검토 시간, 승인 후 발견된 오류, 중복 실행, 롤백 성공률과 우회 시도를 모니터링합니다. 승인율 99퍼센트는 준비 품질이 좋다는 뜻일 수도 있지만, 검토자가 내용을 보지 않고 승인한다는 신호일 수도 있습니다.
Prompt injection과 오염된 외부 문서도 threat model에 포함해야 합니다. 승인 화면은 신뢰 가능한 시스템 지시와 비신뢰 검색 문서의 문장을 구분해야 하며, 문서 안에 들어 있는 명령을 승인으로 취급해서는 안 됩니다.
승인 위치 판단표
| 업무 조건 | 권장 AI 역할 | 필요한 사람 통제 |
|---|---|---|
| 공개 자료 기반 읽기 전용 조사 | 검색·요약 | 중요한 사용 전 원출처 검토 |
| 쉽게 되돌릴 수 있는 내부 초안 | 후보안 준비 | 배포·공유 전 검토 |
| 범위가 제한된 기록 변경 | 정확한 diff 제안 | diff와 expected version 승인 |
| 외부 메시지 | 초안 작성만 | 수신자, 본문, 첨부와 전송 승인 |
| 공개 발행 | 준비·결정론적 검증 | 정확한 revision 승인 후 merge 또는 발행 |
| 결제·구매 | 자료 추출·비교 | 금액, 공급자, 예산과 중복 검사 승인 |
| 권한 변경 | 최소 권한안 추천 | 권한 있는 사람이 대상, 범위와 기간 확인 |
| 파괴적·안전 중요 행동 | 설명·시뮬레이션 | 수동 실행 유지 또는 다중 독립 통제 |
승인 게이트가 무효한 신호
- 모델이 다른 도구를 사용해 승인 없이 같은 행동을 실행할 수 있다.
- 검토자에게 정확한 payload와 증거가 아니라 요약만 보인다.
- 내용, 대상, 상태가 바뀌어도 승인이 계속 유효하다.
- 시간 초과가 자동 승인으로 처리된다.
- 한 번의 승인으로 미래의 무제한 행동이 허용된다.
- 검토자가 실제로 읽을 수 없는 양의 요청을 승인해야 한다.
- 거절해도 실행기가 계속 동작한다.
- 누가 무엇을 승인했고 무엇이 실행됐는지 로그로 증명할 수 없다.
- 사고 중에 업무를 빠르게 비활성화할 수 없다.
짧은 설계 체크리스트
- 업무를 의사결정과 상태 변경으로 분해했는가?
- 각 행동을 영향과 복구 가능성으로 분류했는가?
- 모델에 필요한 기능과 권한만 제공했는가?
- 첫 번째 결과 발생 전에 승인이 위치하는가?
- 검토자가 정확한 증거, 범위와 부수 효과를 보는가?
- 제안, 검증, 승인, 실행과 기록이 분리됐는가?
- 승인이 정확한 payload, version, 승인자와 만료 시각에 묶였는가?
- 거절, 에스컬레이션, 복구, 모니터링과 긴급 중단이 정의됐는가?
자동화 자체가 적절한지 판단할 때는 AI 자동화가 오히려 비효율적인 업무 7가지를 함께 사용하세요. 구현 전 데이터와 권한 경계는 AI 도구 도입 전 개인정보·보안 체크리스트로 검토할 수 있습니다.
확인한 기준 자료
- NIST AI RMF Core (새 창에서 열림)
- NIST AI RMF Appendix C: Human-AI Interaction (새 창에서 열림)
- NIST 생성형 AI 위험 관리 프로필 (새 창에서 열림)
- OWASP LLM06:2025 Excessive Agency (새 창에서 열림)
- OWASP LLM01:2025 Prompt Injection (새 창에서 열림)
자료 확인일: 2026-07-20