AI 에이전트한테 업무를 다 맡기면 편하긴 한데, 되돌리기 어렵거나 돈·법 문제가 얽힌 작업만큼은 사람이 마지막에 한 번은 꼭 봐줘야 해요. 이게 바로 Human-in-the-loop(HITL), 사람이 승인 버튼을 눌러야 실제로 실행되는 구조인데요. 이번 글에서는 어떤 순간에 이 승인 절차가 꼭 필요한지, 승인 화면에는 뭐가 들어가야 하는지, 실무에서 자주 나오는 시나리오랑 체크리스트까지 한 번에 정리해봤어요.
완전 자동화가 위험해지는 지점들
에이전트가 사람 확인 없이 모든 판단을 혼자 내리면 생각보다 큰 사고로 이어지는 경우가 많아요. 민감한 정보가 그대로 공개돼버리거나, 잘못된 게시물이 올라가거나, 계정 권한이 엉뚱하게 상승하거나 삭제되는 일이 실제로 벌어지거든요. 결제 쪽에서는 잘못된 환불이나 이중 청구 같은 금융 사고가 생길 수 있고, 계약서를 자동으로 처리하다 보면 부적절한 서명이 나갈 위험도 있죠. 삭제나 덮어쓰기로 데이터가 영구히 망가지는 것도 흔한 사고 유형이에요.
HITL을 두는 이유는 명확해요. 위험이 큰 결정 지점에서만 사람 판단을 끼워 넣어 오류와 법적 리스크를 줄이고, 승인 이력을 남겨서 책임 소재를 분명히 하고, AI가 확신하지 못하는 부분을 사람이 보완해주는 거예요.
승인 화면에 꼭 들어가야 하는 것들
승인 버튼만 있고 정작 뭘 승인하는지 애매하면 그건 없느니만 못해요. 승인 화면에는 “무엇을(작업 요약)”, “어디에(대상 시스템·계정·리소스)”, “어떤 권한으로(읽기/쓰기/삭제/관리)”, “예상되는 영향”, “되돌릴 수 있는지와 그 방법”까지 구체적으로 보여줘야 해요. 승인 전에 미리 시뮬레이션이나 프리뷰를 보여주는 것도 중요하고, 승인해서 실행한 뒤에도 결과가 제대로 반영됐는지 검증하는 단계가 따로 있어야 해요. 승인만 받고 실행 결과를 안 보는 구조는 반쪽짜리인 거죠.
이 위에 권한 통제(RBAC/ABAC로 최소 권한 적용), 상태·메모리 관리(승인 대기·승인·거부·실행중·완료 같은 상태 보존), 도구 연동(DB·결제·이메일·배포 시스템 호출 시 별도 보호층), 감사·모니터링(로그와 알림, 이상 탐지)까지 갖춰지면 구조가 완성돼요. 흐름으로 보면 트리거가 들어오면 에이전트가 제안을 만들고, 호출할 도구와 리소스를 식별하고, 승인 화면을 띄워 담당자에게 알리고, 승인되면 실제로 실행한 다음 결과를 검증하고 로그를 남기는 순서예요.
실제로 이런 순간엔 사람이 봐야 해요
블로그나 뉴스 게시물을 에이전트가 초안까지 써서 자동 게시하려는 상황이라면, 승인 화면에 초안 원문과 출처 인용 여부, 민감 키워드 체크 결과, 공개될 채널을 다 보여주고 저작권 이슈가 감지되면 추가 검토 목록을 띄워야 해요. 게시 후 24시간은 모니터링하면서 신고나 수정 절차도 준비해두는 게 좋고요.
계정 권한을 바꾸는 작업, 특히 누군가에게 관리자 권한을 부여하는 제안이라면 대상자와 요청 사유, 현재 권한, 접근 가능해질 리소스 목록, 되돌리는 절차를 승인 화면에 명시하고 중요한 건은 2인 이상 다중 승인을 걸어야 해요. 변경 이력은 불변 로그로 남기고요.
환불이나 결제 처리도 마찬가지예요. 주문번호, 환불 사유, 금액, 환불 수단, 사기 가능성 점수, 관련 정책 링크를 승인 화면에 다 보여주고 금액이 크거나 의심스러운 거래는 수동 처리로 넘겨야 해요. 결제 게이트웨이를 호출하기 전에 사용자 신원과 주문 상태를 먼저 검증하는 것도 필수고요.
계약서 전자서명처럼 법적 문서를 다룰 때는 주요 조항 요약과 변경된 조항을 하이라이트로 보여주고, 법무 검토가 필요한지와 위험도를 표시해줘야 해요. 일정 임계값이 넘는 계약은 최종 검토자 승인이 필수고, 서명 후엔 원본 문서와 서명 이력(타임스탬프, IP)을 그대로 보관해야 하죠.
도입 전 체크리스트
승인 프로세스를 붙이기 전에 이 정도는 미리 점검해두면 나중에 덜 고생해요.
- 모든 API 호출은 TLS로 암호화하고, 서비스 계정과 API 키는 최소 권한으로 분리했나요
- 승인 UI와 로그 접근을 RBAC로 제한하고 있나요
- 개인정보는 저장·전송 시 암호화하고, 승인자가 보기 전에 민감 데이터를 마스킹하나요
- 모델 호출량과 승인자 인건비, 외부 API 비용까지 포함해 예산을 산정했나요
- 승인 대기 시간(SLA)을 정의하고, 장애 시 수동 오버라이드 절차를 문서화했나요
- 승인·감사 로그를 충분한 기간 보존하고 검색할 수 있게 해뒀나요
처음 도입할 땐 범위를 작게 잡는 게 훨씬 안전해요. 내부 테스트 채널만 쓰고, 승인자도 한 명으로 시작해서 승인 화면의 정보 구성부터 다듬은 다음, 로그를 전부 남기면서 2주 단위로 정책을 보완해나가는 방식을 추천해요.
자주 걸리는 실수들
가장 흔한 실수는 승인 화면이 부실해서 담당자가 뭘 승인하는지도 모른 채 눌러버리는 경우예요. 대상 리소스나 예상 결과가 표시되지 않으면 이런 일이 생기는데, 승인 화면 포맷을 “무엇·어디·권한·영향”으로 표준화하고 프리뷰 기능을 붙이고 승인자 교육을 하면 많이 줄어들어요.
승인은 됐는데 정작 실행 단계에서 외부 API가 실패해버리는 경우도 있어요. 실행 전에 권한과 데이터 형식을 미리 검증하고, 실패했을 때 재시도할지 수동으로 롤백할지 규칙을 명확히 정해두고, 실패 알림과 에스컬레이션 체계를 갖춰두면 대응이 훨씬 매끄러워져요. 모델이 민감 정보를 그대로 제안에 포함시키는 경우도 종종 나오는데, 이건 정규표현식이나 분류 모델로 민감성 검사를 추가하고 승인 화면에 뜨기 전에 자동 마스킹을 걸어두는 식으로 막을 수 있어요.
결국 HITL은 자동화 속도를 조금 늦추는 대신 큰 사고를 막아주는 안전장치예요. 모든 작업에 다 붙일 필요는 없고, 되돌리기 어렵거나 영향이 큰 지점만 골라서 승인 화면을 제대로 설계하는 게 핵심이에요. 가격이나 지원 버전처럼 자주 바뀌는 정보는 항상 사용 중인 플랫폼의 공식 문서에서 최신 값을 확인하시고요.
