에이전트 승인 설계 체크리스트: guardrail과 human review를 나누는 법
에이전트를 서비스에 붙일 때 가장 많이 과소평가되는 부분이 guardrail과 human review입니다. 모델이 똑똑해질수록 이 둘은 덜 중요해지는 게 아니라 더 중요해집니다. 검색 의도가 분명한 키워드로 정리하면 agent guardrails, human in the loop approvals, tool approval workflow, AI agent safety checklist가 핵심입니다. 많은 팀이 “위험한 액션은 사람 승인” 정도로만 생각하는데, 실제 운영에서는 무엇을 자동 차단하고 무엇을 사람에게 넘길지를 구체적으로 분리해야 합니다.
OpenAI의 Agents 문서도 이 점을 분명하게 설명합니다. input guardrail, output guardrail, tool guardrail은 자동 검증용이고, cancellation, edits, shell commands, 민감한 MCP action 같은 side effect는 human review로 멈추게 하라고 합니다. 이 구분을 제대로 안 하면 두 가지가 동시에 생깁니다. 위험한 행동은 너무 쉽게 통과하고, 반대로 사소한 행동까지 승인 대기열에 쌓여서 제품이 굼떠집니다.
guardrail과 approval를 헷갈리면 왜 운영이 무너지는가
간단히 정리하면 역할이 다릅니다.
- guardrail: 규칙에 따라 자동으로 통과/차단/수정한다
- approval: 애매하거나 위험한 실행을 사람 또는 정책 엔진이 최종 승인한다
문제는 이 둘을 뒤섞을 때 생깁니다. 예를 들어 “고객 환불은 위험하니 output guardrail로 문장을 검사하자”는 식의 접근은 틀렸습니다. 환불은 문장 품질 문제가 아니라 실행 권한 문제이기 때문입니다. 반대로 “사용자가 욕설을 넣었을 때 매번 사람 승인”도 비효율입니다. 이런 건 input guardrail에서 바로 막는 편이 맞습니다.
실무 기준으로 보는 4가지 통제 지점
에이전트 워크플로우를 설계할 때는 아래 네 군데를 분리해서 봐야 합니다.
1. 입력 단계: input guardrail
사용자 요청이 애초에 처리 대상인지 검사합니다.
적용 예시:
- 금지된 요청 차단
- PII 포함 여부 탐지
- 특정 업무 범위를 벗어난 질문 차단
- 악성 프롬프트 인젝션 패턴 필터링
여기서 중요한 건 값싸고 빠르게 막는 겁니다. 메인 에이전트를 돌리기 전에 잘라야 비용이 안 샙니다.
2. 추론/도구 단계: tool guardrail
모델이 특정 tool을 호출할 때 인자와 맥락을 검사합니다.
적용 예시:
- 금액 한도 초과 환불 차단
- 운영 환경에서 위험 명령 제한
- 고객 ID와 세션 사용자 불일치 차단
- 허용되지 않은 외부 도메인 전송 차단
이 계층은 실무적으로 가장 중요합니다. 에이전트 사고는 대개 “답변이 이상함”보다 “툴을 잘못 눌렀음”에서 시작하기 때문입니다.
3. 출력 단계: output guardrail
최종 응답이 외부로 나가기 전에 검사합니다.
적용 예시:
- 민감정보 마스킹
- 브랜드 톤/법무 표현 제한
- 구조화 출력 스키마 검증
- 금지된 문구 제거
이건 품질과 컴플라이언스 쪽에 가깝습니다. 하지만 이것만으로 실행 리스크는 못 막습니다.
4. 실행 단계: human review / approval
에이전트가 실제로 외부 상태를 바꾸는 액션을 하려면 멈추고 승인받게 하는 단계입니다.
적용 예시:
- 주문 취소
- 환불 승인
- 외부 이메일 발송
- DB 수정
- 배포/재시작
- 민감 MCP action 실행
핵심은 side effect가 있는지입니다. 되돌리기 어렵거나 외부 영향이 크면 승인 쪽으로 보내야 합니다.
어떤 액션을 승인 대상으로 보내야 하나
무조건적인 정답은 없지만, 실무에서는 아래 기준이 꽤 잘 먹힙니다.
승인 필요 가능성이 높은 액션
- 돈이 움직인다
- 고객 데이터가 바뀐다
- 외부 커뮤니케이션이 발생한다
- 운영 환경이 바뀐다
- 법적/계약적 책임이 생긴다
- 한 번 실행하면 복구 비용이 크다
자동화에 더 적합한 액션
- read-only 조회
- 초안 생성
- 분류/태깅
- 낮은 위험도의 내부 문서 요약
- 사람이 다시 검토할 중간 산출물 생성
즉 “사람이 다시 볼 수 있는 중간 결과”는 자동화해도 되고, “외부 세계를 바꾸는 확정 행동”은 승인으로 묶는 편이 안전합니다.
승인 흐름이 느려지지 않게 설계하는 법
많은 팀이 approval를 붙였다가 불평합니다. 전부 승인 대기라서 느리다는 겁니다. 대개 이유는 두 가지입니다.
첫째, 승인 단위가 너무 큽니다. 둘째, 승인 화면에 필요한 맥락이 없습니다.
예를 들어 아래 둘은 운영 난이도가 다릅니다.
나쁜 승인 요청
- “고객 관련 작업을 진행하시겠습니까?”
좋은 승인 요청
- “주문 18231에 대해 39,000원 환불 요청을 실행합니다. 사유: 중복 결제. 고객 계정: kim@example.com. 승인하시겠습니까?”
승인자는 문맥을 즉시 이해해야 합니다. 무엇을 왜 실행하는지, 영향 범위가 무엇인지 한 화면에 보이게 해야 합니다.
추천하는 approval 설계 패턴
패턴 1. risk tier로 나누기
- Tier 0: read-only, 무승인
- Tier 1: reversible draft action, 로그만
- Tier 2: customer-facing action, 승인 필요
- Tier 3: money / infra / privilege, 이중 승인 또는 제한된 승인자만 허용
이렇게 나누면 모든 액션을 같은 절차로 다루지 않아도 됩니다.
패턴 2. tool 자체에 approval 플래그를 넣기
OpenAI 예시처럼 tool 수준에서 needsApproval에 해당하는 개념을 두면 설계가 깔끔합니다. 위험한 액션을 프롬프트에 부탁하지 말고, 툴 선언 단계에서 표시해야 합니다.
패턴 3. guardrail 결과와 approval를 연결하기
예를 들어 금액이 10만 원 이하이면 정책 엔진 자동 승인, 초과하면 사람 승인으로 넘길 수 있습니다. 이 조합이 있으면 업무 속도와 안전을 같이 잡기 쉽습니다.
많이 놓치는 포인트 5가지
1. prompt는 정책이 아니다
“중요한 작업은 꼭 확인해”라고 써놓는다고 정책이 되지 않습니다. 승인 여부는 시스템 계층에서 강제돼야 합니다.
2. output guardrail만으로 안심하면 안 된다
문장이 멀쩡해도 잘못된 tool이 실행되면 이미 사고입니다.
3. approval는 감사 로그와 함께 가야 한다
누가 언제 어떤 이유로 승인했는지 안 남기면 사후 분석이 불가능합니다.
4. 거절 경로도 설계해야 한다
승인 거절 시 에이전트가 어떻게 설명하고, 어떤 대안 경로를 제안할지 정해야 합니다.
5. 승인 대기 상태를 복원 가능하게 저장해야 한다
실무에서는 승인자가 즉시 답하지 않습니다. 중단된 run을 저장하고 이어가는 구조가 꼭 필요합니다.
우리 팀에 바로 적용하는 방법
이번 주 안에 할 수 있는 현실적인 작업은 아래 정도입니다.
- 현재 에이전트가 호출하는 tool 목록을 뽑는다.
- 각 tool에 read-only / reversible / side-effect / high-risk 라벨을 붙인다.
- high-risk 액션은 approval 필수로 바꾼다.
- input/output/tool guardrail을 어디에 둘지 표로 정리한다.
- 승인 로그에 남길 필드를 정의한다.
추천 로그 필드는 최소 이 정도입니다.
- run id
- agent name
- tool name
- arguments summary
- requester
- risk tier
- approved/rejected by
- decision timestamp
- final outcome
결론: 좋은 에이전트는 똑똑한 모델이 아니라 통제 가능한 워크플로우다
에이전트를 운영에 붙이면 결국 질문은 하나로 모입니다. “이 행동을 지금 자동으로 실행해도 되는가?” 이 질문에 답하는 체계가 guardrail과 human review입니다.
정리하면 이렇습니다.
- 입력 문제는 input guardrail로 자른다
- 출력 문제는 output guardrail로 다듬는다
- 도구 인자와 정책 문제는 tool guardrail로 검사한다
- 외부 상태를 바꾸는 행동은 approval로 멈춘다
이 경계만 분명해도 AI agent safety는 훨씬 현실적인 수준으로 올라갑니다. 안전한 자동화는 느린 자동화가 아니라, 위험을 잘 분류한 자동화입니다.
실행 체크리스트
- tool 목록에 risk tier를 붙였다
- input / output / tool guardrail 위치를 분리했다
- 외부 상태를 바꾸는 액션에 human review를 붙였다
- 승인 요청 메시지에 영향 범위와 사유를 담았다
- 승인 거절 후 대체 플로우를 설계했다
- approval 로그와 재개 가능한 상태 저장을 준비했다
참고 소스:
- OpenAI API Docs, Guardrails and human review
- OpenAI API Docs, Agents / approvals interruption pattern