30초 답변
사람 승인은 모델이 “잘 모르겠다”고 말할 때만 받는 장치가 아니라, 외부 전송·삭제·결제·권한 변경·법적 의사표시처럼 결과가 크거나 되돌리기 어려운 행동을 실행하기 직전에 두는 통제 경계다. 승인 화면에는 도구 이름이 아니라 대상, 변경 전후 값, 영향, 근거, 되돌리기 가능 여부를 보여줘야 한다. 반대로 저위험 읽기와 쉽게 취소할 수 있는 초안 생성까지 모두 승인받으면 사용자는 내용을 읽지 않고 통과시키는 승인 피로에 빠진다.
이 글의 핵심
- 승인 여부는 모델의 확신도 하나가 아니라 영향도, 가역성, 권한, 데이터 민감도, 외부 노출로 결정한다.
- 승인 시점은 계획 수립 때가 아니라 실행 인자가 확정된 부작용 직전이어야 한다.
- 승인에는 승인·거절뿐 아니라 수정, 범위 축소, 이번만 허용, 작업 중단이 필요하다.
- 중단된 실행 상태를 안전하게 저장하고, 재개 시 정책과 대상이 변하지 않았는지 다시 검증해야 한다.
- 모든 클릭을 기록하는 것이 감사 로그가 아니다. 누가 무엇을 보고 어떤 변경을 승인했는지 재구성할 수 있어야 한다.
어떤 작업에 승인이 필요한가
OpenAI의 에이전트 구축 가이드는 민감하거나 되돌릴 수 없거나 영향이 큰 행동, 그리고 실패 임계치를 넘은 실행을 사람 개입의 대표 트리거로 제시한다. OWASP의 Excessive Agency 항목은 과도한 기능, 권한, 자율성이 예기치 않은 유해 행동의 원인이 될 수 있다고 설명한다. 이를 실무 정책으로 옮기면 다음 일곱 범주를 우선 검토해야 한다.
1. 외부에 메시지나 파일을 보내는 작업
이메일 발송, 고객 답변 게시, 메신저 공지, 계약서 전송은 조직 밖의 인식과 책임을 바꾼다. 초안 작성은 자동화할 수 있어도 수신자, 첨부 파일, 공개 범위와 최종 본문은 실행 직전에 확인한다.
2. 데이터를 삭제하거나 덮어쓰는 작업
계정 삭제, 문서 원본 교체, 대량 레코드 수정, 보존 기간 변경은 복구가 어렵다. 휴지통 이동처럼 복구 가능한 작업과 영구 삭제를 다른 도구로 분리하고, 영구 작업은 강화된 승인을 요구한다.
3. 결제·환불·구매·가격 변경
금전 행동은 금액뿐 아니라 통화, 대상 계정, 수수료, 반복 여부를 보여줘야 한다. 일정 금액 이하라도 첫 수취인, 비정상 빈도, 정책 예외라면 승인 등급을 올릴 수 있다.
4. 권한·계정·보안 설정 변경
사용자 초대, 관리자 권한 부여, API 키 발급, 방화벽 또는 공유 범위 변경은 이후 행동의 영향 범위를 넓힌다. 요청자가 자기 권한을 초과해 승인할 수 없도록 승인자 권한도 서버에서 검증한다.
5. 법적·규제·인사 판단
계약 수락, 규제 신고, 채용·징계 결정처럼 책임 주체가 명확해야 하는 작업은 모델 추천과 최종 결정을 분리한다. 승인은 책임을 모델에 넘기는 절차가 아니라 사람이 판단할 수 있게 근거와 반대 신호를 제공하는 절차다.
6. 민감 데이터의 조회·결합·반출
개인정보, 의료·재무 정보, 영업비밀은 읽기만 해도 위험할 수 있다. 평소 업무 범위를 벗어난 대량 조회, 서로 다른 데이터셋의 결합, 외부 모델이나 도구로의 전송에는 추가 확인과 목적 제한을 둔다.
7. 에이전트가 실패 임계치를 넘은 작업
동일 도구 반복, 서로 모순되는 결과, 예상 비용·시간 초과, 필수 근거 누락은 사람 인계 신호다. OpenAI 가이드도 재시도 또는 행동 한도를 넘으면 사람에게 넘기는 방식을 권한다. 이 경우 승인 요청보다 “검토가 필요한 상태”로 전환하는 편이 정확하다.
위험 기반 승인 매트릭스 만들기
도구마다 일률적으로 “항상 승인”을 붙이지 말고, 호출 인자와 실행 맥락까지 포함해 위험을 계산한다.
| 요소 | 낮은 위험 | 중간 위험 | 높은 위험 |
|---|---|---|---|
| 작업 성격 | 조회·검색 | 내부 초안·복구 가능한 변경 | 삭제·결제·외부 발송·권한 변경 |
| 가역성 | 상태 변경 없음 | 즉시 취소 또는 버전 복구 가능 | 복구 불가 또는 비용이 큼 |
| 범위 | 한 사용자·한 항목 | 팀·여러 항목 | 전사·대량·외부 대상 |
| 데이터 | 공개·일반 내부 | 제한 내부 | 개인정보·기밀·규제 데이터 |
| 권한 | 현재 사용자 범위 | 위임된 업무 범위 | 관리자·재무·보안 권한 |
| 확실성 | 인자와 정책 모두 검증됨 | 일부 해석 필요 | 대상·정책·근거가 모호함 |
권장 정책은 다음과 같다.
- 낮은 위험: 자동 실행하되 사용자에게 사용한 데이터와 결과를 알리고 로그를 남긴다.
- 중간 위험: 미리 보기, 실행 후 되돌리기, 범위 제한 중 하나 이상을 제공한다. 초기 운영이나 이상 징후에는 승인을 올린다.
- 높은 위험: 실행 직전 명시적 승인, 강한 인증, 최소 권한, 멱등성 키, 상세 감사 로그를 요구한다.
- 정책 위반 또는 모호함: 승인 요청으로 우회하지 말고 차단하거나 담당자 검토로 넘긴다. 사용자가 승인한다고 금지된 작업이 허용되는 것은 아니다.
모델의 자체 확신도는 보조 신호로만 쓴다. 높은 확신도로 잘못 행동할 수도 있고, 확신도 수치가 업무 위험을 대신하지도 못한다.
승인 흐름은 어떻게 설계해야 하나
1. 도구 계약에 위험 메타데이터를 붙인다
Tool Calling 기반 AI Agent 설계 전략의 도구 정의에 작업 유형, 가역성, 민감 데이터 사용 여부, 최대 범위, 필요한 승인 등급을 추가한다. 이름이 비슷한 읽기와 쓰기 도구는 분리한다. 예를 들어 “고객 관리” 하나보다 “고객 조회”, “고객 메모 초안”, “고객 메모 저장”이 정책을 적용하기 쉽다.
2. 실행 인자가 확정된 뒤 정책을 평가한다
“메일을 보낼 수 있음”이라는 계획만 승인받으면 실제 수신자와 내용이 바뀔 수 있다. 수신자, 제목, 본문, 첨부, 발신 계정이 확정된 도구 호출에 대해 정책 엔진이 승인 필요성을 판정한다.
3. 실행 상태를 중단 가능한 객체로 저장한다
OpenAI Agents SDK의 HITL 문서는 민감한 도구 호출에서 실행을 일시 중단하고 승인 또는 거절 후 상태를 재개하는 흐름을 설명한다. 구현체와 관계없이 작업 ID, 호출 ID, 도구 버전, 정규화된 인자, 정책 버전, 요청자, 만료 시각을 저장해야 한다. 대화 텍스트만 저장해서는 동일 실행을 안전하게 재개하기 어렵다.
4. 사람에게 업무 언어로 미리 보기를 제공한다
나쁜 승인 문구는 “send_email 함수를 실행할까요?”다. 좋은 문구는 “구매팀 외부 주소 3명에게 견적서 PDF를 첨부해 발송합니다. 외부 수신자 1명이 새로 포함되었습니다”처럼 대상과 변화를 드러낸다.
승인 화면에는 최소한 다음이 있어야 한다.
- 실행 목적과 요청 원문
- 변경 대상과 변경 전후 값
- 수신자·금액·권한·파일 범위
- 사용한 근거와 정책
- 되돌리기 방법 또는 불가능하다는 경고
- 승인 유효 시간과 이후 재검증 여부
5. 승인 이후에도 서버가 다시 검증한다
UI에서 승인된 인자를 그대로 믿지 않는다. 승인 토큰을 호출 ID와 인자 해시에 묶고, 승인자 권한, 대상 상태, 정책 버전, 만료를 서버에서 확인한다. 승인 후 고객 계정이나 가격이 바뀌었다면 이전 승인을 폐기하고 새 미리 보기를 만든다.
6. 실행은 멱등적으로 처리한다
네트워크 재시도나 사용자의 이중 클릭이 결제·발송을 두 번 만들지 않도록 호출별 멱등성 키를 사용한다. 성공 응답을 받지 못했을 때는 무조건 재호출하지 말고 대상 시스템에서 처리 여부를 조회한다.
7. 거절을 학습 가능한 피드백으로 남긴다
거절 사유를 “아니요” 하나로 끝내지 않는다. 수신자 수정, 범위 축소, 문구 변경, 근거 부족, 작업 자체 취소처럼 구조화하면 재요청과 평가에 쓸 수 있다. 다만 개인의 승인 선택을 곧바로 장기 메모리에 저장해서 전사 정책처럼 일반화해서는 안 된다.
사용자가 실제로 통제감을 느끼게 하는 UX
Microsoft HAX 가이드는 사용자가 AI를 호출하거나 무시하고, 잘못됐을 때 수정하고, 행동의 결과를 이해할 수 있도록 설계하는 원칙을 제시한다. 승인 화면을 하나 추가하는 것만으로 이 원칙이 충족되지는 않는다.
승인·수정·거절·중단을 모두 제공한다
사용자가 이메일 문구 하나를 고치기 위해 전체 작업을 거절하고 처음부터 다시 시작하게 만들면 승인 흐름은 병목이 된다. 안전한 필드는 화면에서 수정할 수 있게 하고, 수정으로 위험 등급이 바뀌면 정책을 다시 평가한다.
‘항상 허용’은 좁은 범위로 제한한다
“앞으로 이 도구 항상 허용”은 편리하지만 권한을 크게 넓힐 수 있다. 가능하면 “이 작업 동안”, “이 폴더 읽기만”, “이 수신자에게만”, “오늘까지”처럼 주체·대상·행동·시간을 묶는다. Anthropic의 신뢰할 수 있는 에이전트 설명은 도구별로 항상 허용, 승인 필요, 차단 같은 권한 수준을 사용자가 설정하는 사례를 든다.
일괄 승인은 동질적인 작업만 묶는다
20건을 한 번에 승인할 때는 모든 항목의 대상과 효과가 같은 정책 범위인지 확인한다. 위험도가 다른 항목을 숨긴 채 “20건 승인”만 보여주면 검토할 수 없다. 이상치, 외부 대상, 큰 금액은 별도로 강조하거나 묶음에서 제외한다.
사용자 경험·운영 실패 시나리오
실패 1: 승인 피로로 모든 요청을 통과시킨다
조회, 초안, 저장마다 팝업을 띄우면 승인이 보안 통제가 아니라 장애물이 된다. 실제 거절률, 검토 시간, 승인 직후 취소율을 보고 불필요한 경계를 줄인다. 저위험 작업은 사후 알림과 되돌리기로 전환할 수 있다.
실패 2: 승인 화면이 핵심 변화를 숨긴다
긴 JSON이나 모델 설명만 보여주면 사용자는 무엇이 달라지는지 알 수 없다. 업무 필드 단위의 변경 전후 비교와 위험 요약을 먼저 보여주고, 원본 인자는 상세 보기로 제공한다.
실패 3: 오래된 승인을 나중에 실행한다
승인 대기 중 권한, 재고, 환율, 문서 버전이 바뀔 수 있다. 유효 시간을 두고 실행 직전에 변경된 전제조건을 재검증한다. 중요한 값이 바뀌면 자동 실행하지 말고 새 승인을 요청한다.
실패 4: 거절했는데 에이전트가 다른 도구로 우회한다
특정 호출 거절을 목표 달성 실패로만 해석하면 에이전트가 유사 도구를 선택할 수 있다. 거절 범위를 호출 하나, 행동 종류, 전체 목표 중 무엇으로 적용할지 명시하고 작업 상태에 반영한다.
실패 5: 승인 후 중복 실행된다
브라우저 새로고침, 타임아웃, 메시지 큐 재전달로 동일 행동이 반복될 수 있다. 승인과 실행에 동일 호출 ID를 사용하고, 대상 시스템의 결과 ID를 저장하며, 재개 전에 이미 완료됐는지 확인한다.
실패 6: 다중 에이전트에서 승인 책임이 사라진다
하위 에이전트가 요청한 고위험 도구도 사용자와 연결된 최상위 작업에 승인 요청으로 나타나야 한다. 내부 에이전트 이름만 보여주지 말고 최초 사용자 요청, 위임 경로, 최종 행동을 함께 표시한다. 단일·멀티 구조 선택은 별도 비교 글에서 다룬다.
실무 체크리스트
- 모든 도구를 조회, 생성, 변경, 삭제, 외부 전송, 금전·권한 작업으로 분류했다.
- 영향도, 가역성, 범위, 민감도, 권한에 따른 승인 정책이 있다.
- 금지된 행동과 승인 가능한 행동을 구분했다.
- 승인 요청은 실행 인자가 확정된 부작용 직전에 발생한다.
- 대상, 변경 전후 값, 금액·수신자·권한, 근거와 복구 가능성을 보여준다.
- 승인자 권한과 직무 분리를 서버에서 검증한다.
- 호출 ID, 인자 해시, 정책·도구 버전, 만료 시각을 저장한다.
- 승인 후 상태와 정책을 다시 확인하고 달라지면 재승인한다.
- 실행 API에 멱등성 키와 처리 결과 조회 경로가 있다.
- 승인, 거절, 수정, 범위 축소, 작업 중단을 지원한다.
- 거절 범위가 우회 실행을 막도록 작업 상태에 반영된다.
- 승인 대기, 재개, 만료, 취소와 중복 메시지를 테스트했다.
- 승인률만 아니라 거절률, 검토 시간, 취소·복구율, 무검토 통과 신호를 모니터링한다.
- 감사 로그로 요청자, 승인자, 본 내용, 결정, 실제 실행 결과를 재구성할 수 있다.
자주 묻는 질문
Q1. 모델의 확신도가 낮을 때만 승인받으면 충분한가?
충분하지 않다. 모델이 높은 확신으로 잘못된 대상을 선택할 수 있고, 낮은 확신의 읽기 작업은 영향이 작을 수 있다. 확신도는 보조 신호로 쓰되 승인 정책의 중심은 행동의 영향, 가역성, 권한, 데이터 민감도여야 한다.
Q2. 모든 Tool Calling에 승인을 붙이면 가장 안전하지 않은가?
표면적으로는 안전해 보이지만 승인 피로 때문에 실제 검토 품질이 낮아질 수 있다. 읽기 전용·좁은 범위·복구 가능한 작업은 자동 실행과 명확한 결과 표시를 고려하고, 외부 발송·삭제·금전·권한처럼 중요한 경계에 사용자의 주의를 집중해야 한다.
Q3. 승인 로그만 있으면 사고 책임과 감사 요구를 충족할 수 있는가?
클릭 시각만으로는 부족하다. 승인 당시 사용자가 본 대상과 변경 내용, 근거, 정책·도구 버전, 승인자 권한, 실제 실행 결과가 함께 있어야 한다. 또한 승인으로 법적 또는 조직적 책임이 자동 이전되는 것은 아니므로 업무별 책임 체계와 보존 정책을 별도로 정해야 한다.
근거 자료
- OpenAI Agents SDK, Human-in-the-loop — 민감한 도구 호출의 일시 중단, 승인·거절, 상태 저장과 재개 흐름.
- OpenAI, A practical guide to building agents — 고위험 행동과 실패 임계치를 사람 개입 트리거로 삼는 설계 원칙.
- Anthropic, Trustworthy agents in practice — 인간 통제, 도구별 권한과 승인 수준을 포함한 신뢰 가능한 에이전트 원칙.
- Microsoft HAX Toolkit, Guidelines for Human-AI Interaction — 사용자 통제, 수정·복구, 시스템 상태와 영향의 명확한 전달을 위한 UX 지침.
- OWASP Gen AI Security Project, LLM08: Excessive Agency — 과도한 기능·권한·자율성으로 발생하는 에이전트 행동 위험과 제한 원칙.