에이전트에게 일을 맡기기 전에 승인선부터 그리는 법
에이전트 자동화 전에 제안과 실행을 나누고 사람의 승인선, 권한, 재실행과 실패 복구 기준을 정하는 방법을 설명한다.
AI로 생성한 개념 이미지이며, 실제 업무 현장이나 시스템의 기록이 아니다.
에이전트가 거래처에 보낼 이메일을 잘 썼다. 담당자는 초안을 읽고 “좋아요”라고 답했다. 그 한마디는 문장에 대한 평가였을까, 실제 발송에 대한 승인일까? 첨부파일까지 포함한 승인이었을까, 수신자가 바뀌어도 유효할까? 사람이 이해한 승인과 시스템이 해석한 권한이 다르면, 자동화는 가장 매끄럽게 움직이는 순간 사고를 낼 수 있다.
자동화 논의는 흔히 어떤 도구를 연결할지에서 시작한다. 메일, 캘린더, 문서 저장소, 결제, 게시 시스템을 붙이면 에이전트가 할 수 있는 일이 늘어난다. 그러나 능력의 목록만 만들면 중요한 질문이 뒤로 밀린다. 어떤 상태를 읽을 수 있는가, 무엇을 준비할 수 있는가, 어느 행동은 사람의 명시적 승인 뒤에만 실행되는가. 승인선은 실행 직전에 붙이는 팝업이 아니라 워크플로의 구조다.
OpenAI Agents SDK의 human-in-the-loop 문서는 승인이 필요한 도구 호출에서 실행을 중단하고, interruption을 검토한 뒤 승인 또는 거절하여 상태를 이어가는 흐름을 설명한다. 승인이 오래 대기할 수 있다면 직렬화한 상태와 함께 에이전트 정의나 SDK 버전 표식을 저장하라고도 안내한다.[6] NIST AI RMF 부록은 AI를 사용하는 사람, 상호작용하는 사람, 관리·감독하는 사람의 역할과 책임을 분명히 구분해야 하며, 인간-AI 구성은 완전 자동부터 완전 수동까지 다양하다고 설명한다.[7] 즉 사람을 루프에 넣는 것만으로 충분하지 않다. 누가 무엇을 보고 어떤 권한으로 결정하는지를 구체화해야 한다.
읽기, 준비, 실행을 같은 권한으로 묶지 않는다
에이전트 행동을 세 층으로 나누면 승인선이 선명해진다.
관찰은 현재 상태를 읽는 일이다. 받은편지함 검색, 일정 조회, 문서 읽기, 재고 확인이 여기에 속한다. 읽기 전용이라도 개인정보와 영업비밀을 다룰 수 있으므로 무조건 안전한 것은 아니다. 접근 범위와 보존 정책이 필요하다.
준비는 외부 상태를 바꾸지 않는 산출물을 만드는 일이다. 이메일 초안, 일정 후보, 수정안, 결제 요청서, 게시 미리보기처럼 사람이 검토할 대상을 만든다. 많은 첫 자동화는 여기까지로도 충분한 가치가 있다.
실행은 외부 상태를 바꾼다. 발송, 게시, 삭제, 승인, 구매, 계정 변경이 해당한다. 실행 권한은 행동 이름만이 아니라 대상, 범위, 금액, 시점, 되돌림 가능성에 따라 더 잘게 나뉘어야 한다.
“메일 도구 사용 허용”은 지나치게 넓다. 검색 허용, 특정 프로젝트 초안 저장 허용, 내부 수신자에게만 발송 허용, 외부 수신자 발송은 매번 승인처럼 권한을 분리할 수 있다. 같은 도구 안에서도 관찰과 실행은 전혀 다른 위험을 갖는다.
승인 여부를 네 가지 축으로 판단한다
행동마다 네 축을 기록하면 승인 필요성을 비교하기 쉽다. 이는 [6]과 [7]을 실무 워크플로에 적용한 저자의 분류다.
- 영향: 잘못 실행됐을 때 누구에게 어떤 손해가 생기는가
- 가역성: 취소나 복구가 가능한가, 복구 전에 외부에 노출되는가
- 범위: 한 대상인가, 여러 고객·파일·계정에 동시에 적용되는가
- 민감도: 개인정보, 비밀정보, 법적 판단, 금전이 포함되는가
영향이 작고 되돌리기 쉬우며 범위가 좁은 행동은 정책으로 자동 승인할 수 있다. 예를 들어 지정된 임시 폴더에 미리보기 파일을 만드는 일이다. 영향이 크거나 비가역적이고 민감한 행동은 사람이 구체적인 실행안을 보고 승인해야 한다. 여러 고객에게 메시지를 보내거나 원본 파일을 삭제하는 일이 그렇다.
중간 영역에는 조건부 승인이 있다. 내부 캘린더에 30분짜리 가안 일정을 잡되 참석자는 추가하지 않기, 정해진 예산 안에서 견적 요청서를 만들되 결제는 하지 않기처럼 범위를 코드와 정책으로 제한한다. 사람의 승인을 모든 단계에 붙이는 대신 자동화가 움직일 수 있는 안전한 울타리를 만든다.
“이 작업 승인”에는 고정된 실행안이 필요하다
승인이 의미 있으려면 승인자가 본 내용과 실제 실행 내용이 같아야 한다. 따라서 승인 요청에는 최소한 다음이 보여야 한다.
- 행동: 무엇을 할 것인가
- 대상: 누구 또는 어떤 자원을 바꿀 것인가
- 내용: 실제 전송문, 파일, 명령, 금액
- 범위: 몇 건에 적용되는가
- 시점: 즉시인지 예약인지
- 되돌림: 취소 방법과 제한
- 근거: 왜 이 행동이 필요한가
승인 뒤 대상이나 내용이 바뀌면 이전 승인은 만료되어야 한다. 이메일 본문을 승인받은 뒤 수신자 목록이 늘었는데 그대로 발송된다면 승인은 장식에 불과하다. 실행안을 해시나 버전으로 고정하는 기술을 쓸 수도 있지만, 핵심은 승인 대상의 동일성을 보장하는 것이다.
모호한 자연어도 피한다. “진행해 주세요”가 초안 작성인지 발송인지 문맥에 따라 달라질 수 있다면 시스템은 실행 권한을 얻었다고 해석하지 않는다. 승인 화면에서 “외부 수신자 2명에게 이 본문과 첨부 1개를 지금 발송”처럼 행동을 다시 확인해야 한다.
가상의 행사 공지 워크플로
가상의 문화기관이 행사 공지를 만드는 과정을 보자. 에이전트는 승인된 기획서와 일정표를 읽고, 홈페이지와 뉴스레터용 문안을 만든다. 여기까지는 관찰과 준비다. 담당자는 날짜, 장소, 출연자 표기, 신청 링크를 검토한다.
그다음 행동은 세 갈래로 나뉜다.
- 내부 검토 폴더에 최종안을 저장: 정책 범위 안에서 자동 실행
- 홈페이지의 비공개 미리보기 갱신: 조건부 자동 실행, 기존 버전 보존
- 홈페이지 공개와 뉴스레터 발송: 지정 책임자의 명시적 승인 필요
승인 요청이 대기하는 동안 일정표가 바뀌었다면 어떻게 할까. [6]은 중단된 실행을 재개할 때 에이전트 정의와 SDK 버전을 함께 관리하는 기술적 주의를 다룬다. 여기에 업무 설계 차원의 검사가 추가로 필요하다. 에이전트는 입력 자료와 실행안이 바뀌었는지 대조하고, 변경됐다면 새 미리보기를 만들어 승인을 다시 받도록 설계할 수 있다. 일정표 변경에 따른 재승인은 SDK 문서가 보장하는 자동 기능이 아니라 이 글에서 제안하는 업무 규칙이다.
발행 뒤에는 실제 공개 페이지와 발송 대상을 다시 읽는다. 도구 호출이 성공했다는 응답은 작업 완료의 한 증거일 뿐이다. 승인된 내용과 실제 반영된 결과를 대조해야 승인선이 실행 이후까지 지켜졌는지 확인할 수 있다.
승인이 실패하는 네 가지 방식
첫째, 승인 피로다. 모든 읽기와 저장에 같은 경고창을 띄우면 사람은 내용을 읽지 않고 통과시키기 시작한다. 낮은 위험 행동은 좁은 정책으로 자동화하고, 중요한 승인만 눈에 띄게 해야 한다.
둘째, 권한 세탁이다. 사람이 상위 목표를 승인했다는 이유로 에이전트가 그 목표를 달성하는 모든 하위 행동까지 허용받았다고 해석한다. “행사를 홍보하라”는 지시는 유료 광고 결제나 전체 고객 발송을 자동으로 포함하지 않는다.
셋째, 낡은 승인이다. 입력, 모델, 도구 정의, 대상 목록이 바뀌었는데 과거 승인을 재사용한다. 승인에는 유효 조건과 만료 시점이 필요하다.
넷째, 책임 없는 인간 루프다. 아무나 버튼을 누를 수 있거나 승인자가 판단에 필요한 자료를 볼 수 없다. NIST가 역할과 책임의 구분을 강조하는 이유는 사람이 존재한다는 사실보다 감독 구조가 중요하기 때문이다.[7]
작은 실험은 거절과 변경에서 시작한다
안전한 첫 실험은 실제 발송이 없는 워크플로로 만든다. 가상의 수신자와 임시 저장소를 사용해 관찰, 준비, 승인 대기, 거절, 수정, 재승인, 실행 후 확인을 한 번씩 통과시킨다. 성공 경로만 시험하지 말고 다음 질문을 넣는다.
- 승인자가 거절하면 에이전트가 다른 표현으로 몰래 재시도하지 않는가
- 승인 대기 중 수신자가 바뀌면 기존 승인이 무효가 되는가
- 일부만 승인했을 때 나머지 행동이 멈추는가
- 승인 권한이 없는 사용자의 응답을 거부하는가
- 실행 뒤 실제 대상과 내용을 다시 확인하는가
이 과정을 통과한 뒤에도 곧바로 완전 자동으로 넓힐 필요는 없다. 반복 관찰에서 낮은 위험과 명확한 조건이 확인된 행동만 정책 승인으로 옮긴다. 고위험 행동은 자동화의 마지막 단계가 아니라 계속 사람이 맡을 단계일 수 있다.
에이전트 자동화의 수준을 “사람이 얼마나 빠졌는가”로 재면 승인선은 장애물처럼 보인다. 그러나 좋은 자동화는 사람을 없애는 대신 판단이 필요한 순간을 더 정확히 드러낸다. 에이전트가 일하기 전에 그 선을 그리면, 속도와 책임을 같은 워크플로 안에서 다룰 수 있다.
이 글의 근거와 한계
[6]은 OpenAI Agents SDK의 구체적 승인 흐름이고 [7]은 NIST의 일반 위험관리 지침이다. 다른 에이전트 프레임워크는 상태 저장과 승인 기능이 다를 수 있다. 관찰·준비·실행의 세 층, 네 가지 판단 축, 행사 공지 사례는 저자의 적용안이며 법률·금융·의료 등 고위험 업무에서는 별도의 규제와 전문 검토가 우선한다.
참고 자료
[6] OpenAI Agents SDK — Human-in-the-loop [7] NIST AI RMF Appendix C — Human-AI Interaction