사람의 승인은 AI가 결과를 작성한 뒤, 실제 외부 발송이나 중요한 데이터 변경을 실행하기 직전에 두는 것이 출발점입니다. 조회·분류·초안 작성은 정해진 범위에서 자동으로 진행하고, 수신자·금액·권한·삭제처럼 영향이 큰 변경은 확인 가능한 실행 요청으로 묶으세요.
핵심 요약: 업무를 ‘준비’와 ‘실행’으로 나누고, 승인 대상을 정확한 내용과 버전에 연결하세요. 승인 화면에는 변경 전후·대상·근거·복구 방법을 보여 줍니다. 만료·거절·수정·재시도도 정상 흐름으로 설계해야 합니다. 아래 표와 체크리스트는 팀이 시작할 수 있는 편집 제안입니다.
[01]문장 품질보다 실행 권한을 먼저 나누세요
고객 문의를 요약하는 기능과 그 고객에게 답장을 보내는 기능은 같은 작업이 아닙니다. ‘고객 응대를 자동화한다’는 요구사항을 조회, 답변 초안, 담당자 검토, 실제 발송으로 나눠 적으세요. 초안이 정확해 보여도 수신자가 잘못되면 결과는 달라집니다.
OWASP는 과도한 기능·권한·자율성을 위험 요인으로 설명하고, 최소 권한과 영향이 큰 작업의 사람 승인을 권고합니다. 또한 허용 여부를 모델 판단에만 맡기지 말고 실제 연결 시스템에서 권한을 검사하도록 안내합니다.
보이드의 설계 제안은 실행 도구 자체를 나누는 것입니다. 초안 저장 도구에는 발송 권한을 주지 않고, 발송 도구는 서버가 확인한 승인 기록이 있을 때만 호출되도록 만듭니다. 입력 문서 안의 ‘승인 완료’라는 문장은 승인 기록으로 취급하지 않습니다.
[02]업무 영향과 복구 가능성으로 승인 표를 만드세요
다음은 가상의 고객 운영 자동화를 위한 시작 표입니다. 모든 회사에 같은 금액 한도나 자동 실행 범위를 적용하지 마세요. 실제 데이터의 민감도, 대외 약속, 변경을 되돌릴 수 있는지에 따라 책임자가 기준을 정해야 합니다.
| 작업 | 기본 처리 제안 | 실행 전 확인 |
|---|---|---|
| 허용된 문서 조회·요약 | 범위 안에서 자동 처리 | 사용자 접근 권한·데이터 범위 |
| 고객 답변 초안 저장 | 검토 가능한 초안 생성 | 원문 근거·미확인 정보 표시 |
| 고객에게 실제 답변 발송 | 발송 직전 승인 | 수신자·본문·첨부·약속 내용 |
| 주문 금액·환불 변경 | 업무 권한자의 명시 승인 | 대상 주문·변경액·한도·현재 상태 |
| 대량 삭제·권한 확대 | 초기 자동화 범위에서 제외 | 별도 변경 절차·복구 계획 |
작업을 잘게 나눌 수 있고 순서가 정해져 있다면 복잡한 자율 에이전트가 꼭 필요한 것은 아닙니다. Anthropic의 설계 글도 먼저 단순한 해법을 찾고 필요할 때 복잡도를 늘리도록 권합니다. 이 글에서는 고정된 ‘초안→검토→실행’ 흐름을 우선 검토할 것을 제안합니다.
[03]승인 화면은 무엇이 바뀌는지 보여 줘야 합니다
‘이 작업을 승인하시겠습니까?’만으로는 검토할 정보가 부족합니다. 가상 예시로 AI가 납기 변경 안내를 작성했다면, 승인자는 고객, 발송 주소, 기존 납기, 제안 납기, 안내 본문과 첨부파일을 한 화면에서 확인할 수 있어야 합니다. 이는 실제 고객 사례가 아닙니다.
- 대상: 고객·주문·문서 ID와 실제 수신자를 표시합니다.
- 변경: 현재 값과 제안 값, 발송될 전체 내용과 첨부를 보여 줍니다.
- 근거: 참조 문서와 조회 시각, 확인되지 않은 항목을 구분합니다.
- 선택: 승인·거절·수정 요청을 나누고 담당자와 만료 시간을 표시합니다.
승인 뒤 내용이 수정되면 이전 승인을 재사용하지 않는 방식을 권합니다. 실행 요청 ID와 내용 버전을 기록하고, 실행 시점에 권한과 현재 상태를 다시 검사하세요. 모델이 스스로 작성한 ‘승인됨’ 상태가 이 검사를 대신해서는 안 됩니다.
[04]거절·만료·재시도를 먼저 설계하세요
검토자가 자리를 비우거나 승인 중 주문이 취소될 수 있습니다. 승인 요청이 만료되면 자동 실행하지 않고 보류하고, 대상 상태가 바뀌면 새 내용으로 검토를 요청하는 방식을 제안합니다. 승인을 기다리는 동안 외부 시스템의 잠금을 오래 유지하는 구조도 피하세요.
구현 예시로 LangGraph의 interrupt는 상태를 저장하고 외부 입력까지 실행을 멈출 수 있습니다. 재개 시 해당 노드의 처음부터 다시 실행되므로, 중단 지점 앞의 부수 효과는 재실행을 고려해야 합니다. 문서는 이 부수 효과를 멱등하게 만들도록 안내합니다. 프레임워크의 중단 기능이 업무 승인 권한까지 자동으로 검증해 주는 것은 아닙니다.
실행 요청에는 중복 방지 키를 두고 대기·승인·실행 중·성공·실패를 구분하세요. 발송 API가 시간 초과됐다고 바로 재발송하지 말고, 외부 처리 결과를 먼저 조회할 경로를 준비합니다. 이미 전송된 메일은 취소가 불가능할 수 있으므로 복구 계획에는 담당자의 정정 연락도 포함할 수 있습니다.
[05]파일럿 검수에 포함할 체크리스트
처음에는 한 업무 흐름과 제한된 계정으로 검증하세요. 초안만 만드는 단계에서 승인자가 무엇을 고치는지 관찰한 뒤 실제 실행을 연결하면, 자동화 범위와 검토 정보의 부족을 함께 찾을 수 있습니다. 성공률이나 절감 시간을 미리 가정하지 말고 관찰 가능한 사건부터 기록합니다.
- 승인 없는 실행, 권한 없는 승인자, 다른 요청에 대한 승인 재사용이 차단되는가?
- 승인 후 내용 수정·주문 상태 변경·만료가 발생하면 다시 검토하는가?
- 거절과 수정 요청이 발송 없이 종료되며 담당자에게 남는가?
- 중복 클릭·재시작·API 시간 초과 후에도 같은 작업이 중복 실행되지 않는가?
- 실행자·승인자·내용 버전·결과를 추적하되 로그에 불필요한 개인정보를 남기지 않는가?
승인 대기 시간, 거절·수정 사유, 중복 실행과 수동 복구 건수를 따로 보세요. 대기 시간이 길다는 이유만으로 승인을 없애기보다, 검토에 필요한 정보나 담당자 배정이 빠져 있는지 확인합니다. 보이드와 범위를 논의할 때는 비식별 업무 예시 하나와 현재 승인 규칙을 준비하면 좋습니다.
- AI 자동화
- 사람 승인
- 실행 권한
- 업무 흐름
