승인 버튼만으로 AI는 안전해지지 않는다: AI 에이전트 HITL 설계

 

AI 에이전트가 이메일을 작성하고 “전송할까요?”라고 묻는다. 사람이 승인 버튼을 누르면 작업이 이어진다. 이 장면만 보면 Human-in-the-Loop, 줄여서 HITL을 구현하는 일은 간단해 보인다. 그러나 승인 이후 수신자가 달라지거나, 오래된 요청이 다시 실행되거나, 다른 사람이 대신 버튼을 눌러도 처리된다면 어떨까. 사람이 한 번 개입했다는 사실만으로 실행이 올바르게 통제되지는 않는다.

 

AI 에이전트의 승인 설계에서 중요한 것은 질문을 띄우는 행위보다 그 질문의 대상과 효력이다. 누가 무엇을 검토했는지, 어느 실행에 동의했는지, 동의한 내용이 실제 실행 직전에도 같은지 확인할 수 있어야 한다. 모델에게 “중요한 작업은 승인받아라”라고 지시하는 것과, 실행 경로에 승인 조건을 구현하는 것은 서로 다른 일이다.

 

이 글은 AI 에이전트의 Human-in-the-Loop 설계를 승인, 거절, 수정, 중단, 재개, 만료의 흐름으로 설명한다. LangGraph Interrupts와 OpenAI Agents SDK 공식 문서, AWS의 티오더 Text2SQL 구현 사례, 국내 개발 블로그를 비교했다. 자료 확인 기준일은 2026년 10월 25일이다. 이메일과 환불 관련 예시는 원리를 설명하기 위한 가상 시나리오이며 실제 서비스를 시험한 결과가 아니다.

 

먼저 핵심을 짚자. 좋은 HITL은 모든 행동을 멈추게 하는 기능이 아니다. 사람이 판단해야 할 지점을 골라 충분한 정보를 제공하고, 그 결정이 정해진 범위에서만 적용되도록 만드는 실행 구조다. 사용자에게 이미 허용받은 작업을 반복해서 묻는 것과, 권한이나 실행 대상이 달라진 상황에서 새 결정을 받는 일을 구분해야 한다.

Human-in-the-Loop는 매번 사람에게 묻는 기능이 아니다

Human-in-the-Loop는 AI가 수행하는 과정에 사람의 판단을 연결하는 방식이다. 요청의 의미를 확인하거나, 생성 결과를 수정하거나, 특정 행동을 승인하거나, 예외 상황을 담당자에게 넘기는 형태가 가능하다. 모든 HITL을 예 또는 아니오 버튼 하나로 이해하면 적용할 수 있는 범위를 좁히게 된다.

 

승인 빈도를 높이는 것이 곧 품질 향상이라고 단정할 수도 없다. 되돌리기 쉽고 사전에 허용된 조회까지 매번 묻는다면 자동화의 가치가 줄고 중요한 요청도 관성적으로 클릭하게 될 수 있다. 반대로 읽기 작업이라는 이유만으로 항상 영향이 작다고 볼 수도 없다. 민감한 자료를 외부로 보내거나 비용이 큰 조회를 수행할 수 있기 때문이다.

 

판단 기준은 도구 이름 하나보다 실제 작업의 범위와 영향에 가까워야 한다. 어떤 데이터를 어떤 대상으로 보내는지, 변경이 되돌릴 수 있는지, 사용자가 이미 정한 한도 안인지, 누가 책임지고 확인할 수 있는지를 살펴본다. 이 기준을 조직의 업무 규칙과 연결해야 일관된 실행 정책을 만들 수 있다.

 

예를 들어 사용자가 특정 문서의 초안을 작성하라고 요청했다면 초안을 만드는 단계마다 확인을 요구할 필요는 없을 수 있다. 그러나 초안 작성과 외부 발송은 영향이 다를 수 있다. 어느 단계까지 이미 허용되었는지는 사용자 요청과 서비스 정책에서 판단해야 한다. 무조건 멈추거나 무조건 진행하는 두 극단 대신 승인 범위를 명확하게 하는 것이 출발점이다.

또한 사람의 참여가 필요한 이유를 구분하면 화면과 지표도 달라진다. 정보가 부족해서 묻는 것인지, 생성한 내용을 검수하는 것인지, 권한이 필요한 실행을 승인하는 것인지가 다르다. 같은 “확인” 버튼을 쓰더라도 결정의 의미는 같지 않다. 실행 기록에도 무엇을 확인했는지 구분해 남기는 편이 좋다.

승인을 받기 전에 검토할 대상을 먼저 고정해야 한다

“이 작업을 진행할까요?”라는 질문만으로는 사람이 무엇에 동의했는지 알기 어렵다. 이메일이라면 수신자와 제목, 본문, 첨부 파일이 중요하다. 환불이라면 대상 주문, 금액, 통화, 처리 방식이 중요할 수 있다. 사람에게 보여 준 내용과 실제 도구에 넘길 내용을 연결할 수 있어야 승인이 의미를 갖는다.

 

가상의 이메일 에이전트를 생각해 보자. 검토 화면에는 고객 A에게 보내는 안내문이 보였는데, 승인 뒤 모델이 문장을 다시 생성하면서 수신자나 첨부 파일을 바꾼다면 이전 승인을 그대로 사용할 수 있을까. 내용이 달라졌다면 같은 결정 대상으로 보기 어렵다. 승인된 초안과 실행 후보 사이의 변경을 감지해야 한다.

 

이를 위해 승인 요청마다 고유한 식별자와 실행 후보의 버전을 둘 수 있다. 승인 대상에는 도구 종류, 정규화한 인자, 대상과 범위, 관련 정책 버전, 필요하다면 만료 시점을 연결한다. 어떤 필드를 포함할지는 업무에 따라 달라진다. 단순히 approved=true만 저장하면 대상이 바뀐 뒤에도 승인이 남아 있는 문제를 발견하기 어렵다.

 

내용의 지문이나 해시를 활용하면 승인 당시와 현재 후보가 같은지 비교하는 데 도움이 될 수 있다. 그러나 해시가 같다는 사실은 승인자가 정당한 권한을 가졌다는 뜻이 아니다. 또 누군가 실행 상태 전체를 바꿀 수 있다면 지문 하나를 확인하는 것만으로 신뢰가 생기지도 않는다. 내용 일치 확인과 사용자 인증 및 상태 무결성은 별도로 다뤄야 한다.

 

실행 직전에는 실제 사용하는 후보가 승인된 후보와 연결되는지 확인한다. 변경이 생기면 변경 범위를 보여 주고 새로운 검토가 필요한지 정책에 따라 판단해야 한다. 사람이 수정한 내용을 다시 모델이 마음대로 바꾸고도 승인된 것처럼 처리해서는 안 된다. 검토 결과가 실행 입력까지 이어지는 경로를 설계해야 한다.

사람이 누른 버튼과 실행 권한은 서로 다른 문제다

승인 화면을 볼 수 있다는 사실과 해당 작업을 승인할 권한이 있다는 사실은 다르다. 요청 식별자를 안다고 다른 팀의 작업을 승인할 수 있어서는 안 된다. 승인 요청의 소유자와 조직, 역할, 실행 대상에 따라 누가 어떤 결정을 내릴 수 있는지 서버에서 확인해야 한다. 화면에 버튼을 숨기는 일만으로는 이 확인을 대신할 수 없다.

 

OpenAI Agents SDK 공식 문서는 직렬화된 RunState가 실행 상태와 승인 결정, 대기 중인 도구 호출과 인자를 포함한다고 설명한다. 이 상태를 불러오는 함수 자체가 제출한 사람이나 스냅샷을 인증해 주는 것은 아니다. 라이브러리가 상태를 복원하는 기능과 애플리케이션이 승인자를 인증하는 기능은 다른 책임이다.

 

같은 문서는 브라우저나 모바일 승인 인터페이스에서 전체 스냅샷을 서버가 관리하고, 검토자에게는 볼 권한이 있는 도구 정보와 불투명한 결정 식별자만 제공하는 패턴을 안내한다. 클라이언트가 보내는 새 도구 인자나 대체 실행 상태를 그대로 믿지 않고 서버에 보관한 요청과 대조해야 한다는 취지다.

승인 응답을 받을 때도 사용자 이름을 요청 본문에서 가져오는 대신 실제 인증 세션과 연결해야 한다. 선택한 결정이 현재 대기 중인지, 승인자가 해당 실행에 권한이 있는지, 결정 값이 허용된 형식인지 검사한다. 식별자만 맞는지 확인하는 것과 권한을 확인하는 것은 다르다. 이 구분이 빠지면 다른 사람의 요청에 결정을 적용할 수 있다.

 

중복 클릭과 동시에 도착한 결정도 서버에서 다뤄야 한다. 화면의 버튼을 비활성화하면 사용성을 높일 수 있지만 다른 창이나 재전송된 요청까지 막는 실행 보장은 아니다. 대기 상태를 승인 또는 거절로 바꾸는 처리가 원자적으로 이루어져야 같은 결정을 여러 작업자가 동시에 소비하는 문제를 줄일 수 있다. 실제 부작용의 중복 방지는 실행 단계에서도 별도로 확인해야 한다.

중단과 재개를 단순한 함수 대기로 생각하면 생기는 오류

승인 대기는 사용자 응답이 몇 초 뒤에 올 수도 있고 다음 날 올 수도 있는 작업이다. 웹 요청이나 실행 프로세스를 계속 붙잡아 두는 방식만으로는 재시작과 장기 대기를 다루기 어렵다. 중단된 업무의 상태를 보존하고 나중에 적절한 실행 경로로 이어 갈 수 있어야 한다.

 

LangGraph의 interrupt는 외부 입력을 기다리기 위해 그래프 실행을 멈추는 기능이다. 공식 문서는 체크포인터와 thread_id를 이용해 상태를 저장하고 같은 실행 문맥을 다시 불러오는 흐름을 설명한다. 재개 입력은 Command의 resume 값으로 전달한다. 실제 사용하는 API와 스트리밍 방식은 설치한 버전의 문서를 확인해야 한다.

 

thread_id는 어떤 저장 상태를 불러올지 가리키는 실행상의 식별자다. 이를 알고 있다고 승인 권한이 생기는 것은 아니다. 사용자와 작업의 접근 통제는 별도로 구현해야 한다. 실행을 찾는 열쇠와 실행을 허가하는 권한을 같은 개념으로 취급하면 상태 복원 기능을 보안 기능으로 오해하게 된다.

 

운영에서는 메모리 안에만 저장하는 예시와 내구성 있는 저장소를 사용하는 구성을 구분해야 한다. 프로세스가 종료되면 사라지는 상태로 장기 승인을 기다리면 업무를 이어 가기 어렵다. 반대로 저장소에 남았다고 모든 외부 실행이 정확히 복구되는 것도 아니다. 체크포인트는 그래프 상태를 보존하며 외부 시스템의 부작용까지 자동으로 되돌리지 않는다.

 

중단 지점에는 사람이 판단할 수 있는 직렬화 가능한 정보를 전달하는 편이 좋다. 임의의 함수나 실행 중인 연결 객체처럼 복원하기 어려운 대상을 그대로 담는 대신, 검토할 내용과 안전한 참조를 명시한다. 상태가 어디에 얼마나 오래 보관되는지, 민감한 인자가 포함되는지도 함께 확인해야 한다.

LangGraph에서 재개하면 노드 앞부분이 다시 실행될 수 있다

LangGraph interrupt를 사용할 때 특히 중요한 점은 재개가 반드시 중단한 코드 줄 바로 다음에서 시작하는 방식은 아니라는 것이다. 공식 문서는 중단이 발생한 노드의 처음부터 다시 실행되어 interrupt 이전 코드도 재실행될 수 있다고 설명한다. 일반적인 함수 호출의 일시 정지처럼 생각하면 예상하지 못한 반복이 생길 수 있다.

 

예를 들어 하나의 노드에서 결제 기록을 만들고 그다음에 승인 입력을 기다리도록 구성했다고 하자. 재개할 때 기록 생성 코드가 다시 실행된다면 중복 데이터가 생길 수 있다. 더 근본적으로, 승인 대상인 변경을 승인 전에 수행했다면 이미 통제 지점을 지나친 것이다. 검토와 실제 부작용을 분리하는 것이 중요하다.

공식 문서는 interrupt 전에 호출하는 부작용이 재실행에 안전하도록 하거나, 부작용을 뒤로 옮기거나 별도 노드로 나누는 방식을 안내한다. 다만 부작용을 interrupt 뒤에 두었다고 모든 장애 상황에서 한 번만 실행된다는 보장이 자동으로 생기지는 않는다. 도구 실행 뒤 저장이 실패하는 경우처럼 다른 재시도 경계도 존재하기 때문이다.

 

또한 interrupt는 런타임에 중단을 알리는 특수한 예외를 이용한다. 이를 광범위한 try/except로 잡아 버리면 의도한 중단 신호가 제대로 전달되지 않을 수 있다. 오류가 날 수 있는 코드와 중단 호출을 구분하고 필요한 예외만 처리해야 한다. 일반적인 에러 처리 관습을 그대로 적용하기 전에 프레임워크의 실행 규칙을 확인하자.

 

한 노드 안에서 여러 interrupt를 호출한다면 순서도 중요하다. 공식 문서는 재개 값과 호출의 대응에 순서가 사용된다고 설명한다. 실행마다 일부 호출을 건너뛰거나 비결정적으로 순서를 바꾸면 의도한 질문과 응답이 어긋날 수 있다. 예제의 짧은 코드가 실제 여러 단계 승인에서도 그대로 안전하다고 가정하면 안 된다.

 

이 규칙은 LangGraph의 해당 실행 모델에 관한 설명이다. 모든 에이전트 SDK가 똑같이 노드 처음부터 재실행된다고 일반화하지 말아야 한다. OpenAI Agents SDK의 RunState처럼 다른 구조는 그 문서가 설명하는 저장과 재개 의미를 따라야 한다. 공통 개념은 비슷해도 구체적인 재실행 범위와 승인 상태의 수명은 다를 수 있다.

한 번 승인과 앞으로 항상 승인은 범위가 다르다

한 번의 도구 호출을 승인하는 것과 앞으로 같은 도구를 계속 허용하는 것은 다른 결정이다. 이메일 한 통을 검토한 사람이 같은 이름의 전송 도구가 수행할 모든 미래 발송까지 허용한 것은 아닐 수 있다. 승인 범위를 사용자가 이해할 수 있게 보여 주고 서비스 정책과 일치시켜야 한다.

 

OpenAI Agents SDK 문서는 특정 호출 ID에 대한 결정과 이후 같은 도구에 이어지는 결정을 구분한다. always_approve 같은 선택은 승인 상태가 재사용되는 동안 이후 호출에 영향을 줄 수 있다. 단순한 편의 옵션처럼 보이지만 실행 권한의 범위와 수명을 바꾸는 선택이다. 기본값과 상태가 언제 새로 만들어지는지 확인해야 한다.

 

특히 확인한 공식 문서는 로컬 ShellTool과 ApplyPatchTool의 지속 결정 범위에 별도 경고를 둔다. 실행기와 편집기의 권한이 달라도 도구 유형과 이름을 기준으로 결정이 적용될 수 있는 상황을 설명한다. 이 세부 동작은 사용하는 SDK 버전에 따라 확인해야 하며, 모든 도구의 승인 범위가 동일하다고 가정해서는 안 된다.

 

실무에서 범위를 정할 때는 도구 이름뿐 아니라 대상과 인자, 환경, 권한을 함께 본다. 개발 환경의 특정 파일 수정 승인과 운영 환경의 파일 수정 승인은 같은 의미가 아니다. 하나의 승인 상태를 재사용하는 과정에서 원래 검토한 경계가 확장되지 않는지 확인해야 한다. 이름이 같다는 사실만으로 동일한 영향의 작업이라고 판단하기 어렵다.

 

매번 승인받는 것이 부담이라면 사전에 허용한 범위와 한도를 코드로 명확히 정의하는 방법을 검토할 수 있다. 이 경우에도 정책이 무엇을 자동 허용하고 무엇을 별도로 판단하는지 보여야 한다. 사람의 지속 승인과 애플리케이션의 자동 정책 판정을 구분하면 운영자가 어떤 권한을 부여했는지 이해하기 쉽다.

승인을 기다리는 동안 세상은 계속 바뀐다

오전 10시에 재고와 가격을 확인하고 실행 후보를 만들었는데 오후 4시에 승인이 도착할 수 있다. 그사이 가격이 달라지거나 주문이 취소되거나 사용자의 권한이 바뀔 수 있다. 승인 당시의 문맥을 보존하는 일과 실행 시점의 유효성을 확인하는 일은 모두 필요하다.

 

이 문제는 일반적인 시스템에서 확인 시점과 사용 시점의 차이로도 다룬다. 에이전트에서는 모델이 후보를 생성하고 사람이 검토하는 시간이 추가되므로 차이가 더 길어질 수 있다. 오래된 후보에 대한 승인만으로 지금도 같은 조건이 성립한다고 볼 수 없다. 변할 수 있는 항목과 재확인이 필요한 조건을 정해 두는 편이 좋다.

 

가상의 환불 요청이라면 이미 다른 담당자가 처리했는지, 남은 환불 가능 금액이 같은지 확인할 수 있다. 이메일이라면 첨부 파일 버전이나 수신 대상이 바뀌었는지 확인할 수 있다. 무엇을 다시 검사할지는 업무에 맞춰 정해야 한다. 모든 데이터를 무조건 다시 생성하면 검토한 대상 자체가 바뀔 수 있다는 점도 고려하자.

 

만료 시간은 이런 경계를 표현하는 한 방법이다. 다만 일괄적으로 짧게 정하면 사용자가 계속 새 요청을 만들어야 할 수 있다. 가격처럼 빠르게 변하는 조건과 문서 초안처럼 비교적 안정적인 대상을 같은 규칙으로 처리할 필요는 없다. 만료의 이유와 이후 가능한 행동을 사용자에게 설명해야 한다.

 

변경이 발견되면 이전 승인을 조용히 재사용하지 않는 편이 좋다. 무엇이 달라졌는지와 다시 검토할 범위를 보여 주자. 조건이 그대로라면 이미 허용된 범위 안에서 이어 갈 수 있지만, 대상과 영향이 달라졌다면 새 결정이 필요할 수 있다. 재검토의 기준을 정하면 불필요한 반복 확인도 줄일 수 있다.

거절과 수정 그리고 만료를 별도 상태로 다뤄야 한다

승인하지 않았다는 상황에도 여러 의미가 있다. 사용자가 명시적으로 거절했는지, 입력을 수정하려는지, 아직 응답하지 않았는지, 요청이 만료되었는지를 구분해야 한다. 이 상태들을 모두 실패나 아니오로 합치면 재개 경로와 사용자 안내가 부정확해질 수 있다.

 

거절한 실행은 모델이 다른 도구 이름이나 다른 경로를 선택해 같은 효과를 내도록 이어져서는 안 된다. 단순한 도구 오류와 달리 승인 거절은 실행 허가가 없다는 의미다. 모델에게 반환하는 결과에도 이 차이가 드러나야 하며, 실제 실행 계층의 권한 확인도 유지되어야 한다.

 

수정은 특히 조심해야 한다. 검토자가 이메일의 본문을 고쳤다면 수정한 버전을 실행 대상으로 정하고 이후 변경 여부를 확인해야 한다. 금액이나 대상이 바뀌었다면 관련 검증과 권한도 다시 볼 수 있다. “수정 후 진행”이라는 버튼이 모든 종류의 수정에 같은 의미를 갖는다고 가정하면 안 된다.

 

시간 초과 역시 자동 승인과 같지 않다. 응답이 없을 때는 업무 정책에 따라 계속 대기하거나 만료시키거나 담당자에게 넘길 수 있다. 사용자의 침묵을 실행 허가로 해석하려면 그 동작 자체가 사전에 명확하게 합의되어 있어야 한다. 단순히 작업을 끝내기 위해 승인 값을 추정해서는 안 된다.

 

취소와 실행 중단도 구별해야 한다. 아직 시작하지 않은 작업은 취소할 수 있어도 외부 시스템에서 이미 진행된 작업은 되돌릴 수 없을 수 있다. 실행을 멈추라는 요청이 도착했을 때 실제 외부 상태를 확인하고 가능한 조치와 한계를 알릴 수 있어야 한다. 화면에 취소됨이라고 표시하는 것만으로 이미 발생한 부작용이 사라지지는 않는다.

실제 사례에서 보는 의도 확인과 실행 확인의 차이

AWS 기술 블로그의 티오더 Text2SQL 에이전트 티스푼 구현 사례는 두 단계의 Human-in-the-Loop를 설명한다. 첫 단계에서는 사용자의 데이터 조회 요구를 어떻게 이해했는지 자연어 계획으로 보여 준다. 두 번째 단계에서는 생성한 SQL을 공개하고 실행 여부를 확인한다. 서로 다른 오류를 다른 시점에서 검토하는 구조다.

 

첫 번째 검토에서는 기간, 지표, 대상과 집계 의미를 바로잡을 수 있다. 사용자가 “지난달 주문 수”라고 말했을 때 주문 건수와 주문한 매장 수를 혼동했다면, SQL이 문법적으로 맞아도 의도와 다른 결과가 나온다. 실행 코드를 만들기 전에 의미를 확인하는 것이 불필요한 후속 작업을 줄일 수 있다.

 

두 번째 검토는 실제 실행 후보를 확인하는 단계다. 사례는 Athena의 EXPLAIN을 이용한 구문 검증과 별도로, 구문이 맞아도 비즈니스 로직 오류나 의도치 않은 전체 테이블 스캔이 생길 수 있어 SQL 확인이 필요했다고 설명한다. 자동 검사와 사람 검토가 서로 다른 질문을 다룬다는 점이 중요하다.

 

그렇다고 모든 서비스가 반드시 두 번 승인받아야 한다는 결론은 아니다. 이 사례의 데이터 조회 업무와 사용자 환경에 맞춘 구성이다. 다른 업무에서는 이미 정해진 정책으로 자동 처리할 수 있는 범위가 더 넓거나, 반대로 별도 전문 검토가 필요할 수 있다. 승인 횟수보다 각 검토가 어떤 오류를 잡는지가 중요하다.

 

또한 사례는 버튼 비활성화로 중복 처리를 줄이는 사용자 인터페이스를 설명한다. 이를 읽을 때 화면에서의 중복 방지와 서버의 권한 및 동시성 보장을 구분해야 한다. 공식 SDK 문서가 안내하는 서버 소유 상태와 승인자 인증 같은 원칙을 함께 검토하면 예시를 실제 서비스로 옮길 때의 빈틈을 찾기 쉽다.

검토 화면은 더 많은 정보보다 올바른 비교를 제공해야 한다

사람에게 긴 JSON 전체를 보여 준다고 검토가 좋아지는 것은 아니다. 중요한 대상과 변경을 찾기 어렵다면 형식적인 클릭만 늘 수 있다. 업무 언어로 핵심을 요약하고 필요할 때 상세 정보로 내려갈 수 있게 구성하는 편이 도움이 된다. 요약이 실제 실행 후보와 일치하는지도 확인해야 한다.

 

이메일에서는 수신자와 외부 발송 여부, 첨부 파일을 먼저 볼 수 있다. 데이터 변경에서는 변경 전후 값과 대상 개수, 되돌릴 수 있는 범위가 중요할 수 있다. SQL에서는 조회 기간과 필터, 다루는 테이블과 결과 범위를 확인할 수 있다. 모든 업무에 같은 화면을 복사하는 것보다 검토자가 발견해야 할 오류에 맞춰 정보를 배치하자.

 

모델이 작성한 “문제없음”이라는 평가만 크게 보여 주면 검토가 편향될 수 있다. 확인된 사실과 자동 검증 결과, 아직 확인하지 못한 조건을 나누어 표시해야 한다. 근거 자료를 확인할 수 있는 참조와 원래 사용자 요청을 연결하면 의도와 실행 후보를 비교하기 쉽다. 확인 불가 항목을 숨겨서는 안 된다.

 

수정 전후의 차이를 보여 주는 것도 유용하다. 대상이나 금액이 바뀌었는데 본문 전체를 다시 읽어야 한다면 사람이 변화를 놓칠 수 있다. 다만 시각적인 차이만으로 의미 변화가 모두 드러나는 것은 아니다. 단위나 시간대처럼 표시가 작아도 영향이 큰 항목을 업무별로 강조할 수 있다.

검토자에게 보여 주는 도구 이름과 인자도 외부 입력으로 취급해야 한다. 공식 SDK 문서는 이를 화면에 표시할 때 적절하게 이스케이프하도록 안내한다. 도구 결과나 문서 안의 문장이 승인 권한을 바꾸는 지시가 되어서는 안 된다. 검토 인터페이스도 에이전트가 다루는 다른 입력과 마찬가지로 신뢰 경계를 가져야 한다.

장기 대기와 배포 변경까지 고려해야 승인 흐름이 완성된다

승인 대기 상태가 남아 있는 동안 새 버전의 애플리케이션이 배포될 수 있다. 프롬프트와 도구 정의가 바뀌거나 SDK가 업데이트되면 이전 상태를 새 코드로 그대로 복원하기 어려울 수 있다. 장기 대기는 저장만의 문제가 아니라 코드와 상태의 호환성 문제이기도 하다.

 

OpenAI Agents SDK 문서는 대기 중인 작업과 함께 에이전트 정의나 SDK의 버전 표식을 저장하는 방식을 안내한다. 나중에 적절한 코드 경로로 상태를 복원하기 위한 것이다. 버전 번호를 적었다고 호환성이 자동으로 생기는 것은 아니다. 실제 재개 정책과 지원 기간을 서비스에서 정해야 한다.

 

LangGraph에서도 노드의 중단 호출 순서나 상태 구조를 변경하면 진행 중인 실행에 영향을 줄 수 있다. 어떤 변경을 기존 대기 작업에 적용할지, 기존 버전으로 마무리할지, 만료 후 새 요청으로 전환할지를 정해야 한다. 배포가 끝났다는 이유로 이전 승인을 새로운 실행 의미에 조용히 적용해서는 안 된다.

 

대기 상태에는 개인정보나 내부 업무 내용이 포함될 수 있다. 접근 권한과 보존 기간을 정하고 완료되거나 만료된 상태를 언제 지울지 관리하자. 실행 기록을 남길 필요가 있어도 전체 인자와 원문을 모두 장기간 보존해야 한다는 뜻은 아니다. 감사에 필요한 최소 기록과 민감한 실행 상태를 나누어 볼 수 있다.

 

장애 복구에서도 “승인되었으니 다시 실행”이라는 단순한 규칙은 위험할 수 있다. 외부 작업이 이미 끝났는데 결과 저장만 실패했을 수 있기 때문이다. 재개 전에 외부 상태를 확인할 수 있는지, 같은 결정이 이미 소비되었는지 조사해야 한다. 승인 기록, 실행 시도, 실제 처리 결과를 연결하면 복구 판단의 근거가 생긴다.

평가는 승인율이 아니라 잘못된 실행을 줄였는지로 한다

승인 버튼이 자주 눌린다고 좋은 시스템이라고 볼 수 없다. 모든 요청을 자동 허용하면 승인율은 높아질 수 있지만 의미 있는 통제가 되지 않는다. 반대로 올바른 거절과 수정이 늘었다면 오류를 발견하는 구조가 작동하는 것일 수 있다. 지표는 사용자의 업무 목적과 연결해서 해석해야 한다.

 

평가에는 승인된 후보가 실제 실행 입력과 일치하는지, 거절한 작업이 다른 경로로 실행되지 않는지, 권한 없는 사용자의 결정이 적용되지 않는지를 포함할 수 있다. 오래된 승인, 중복 클릭, 동시에 도착한 승인과 취소, 프로세스 재시작 같은 경계 사례도 필요하다. 정상 흐름 한 번이 성공한 것으로 재개 구조 전체를 검증했다고 보기 어렵다.

 

수정 사례도 넣어 보자. 수신자를 바꾸거나 금액을 줄이거나 조건을 추가했을 때 수정한 내용이 최종 실행에 반영되는지 확인한다. 수정으로 인해 새 검증이 필요해졌는데 기존 결과를 재사용하지는 않는지 살펴본다. 사람이 고쳤다는 사실이 모든 유효성 검사를 대신하는 것은 아니다.

운영 지표에는 검토 대기 시간, 수정 비율, 만료율, 잘못된 승인 요청 비율과 검증된 실행 결과를 함께 볼 수 있다. 낮은 위험의 작업에 불필요하게 승인이 많이 발생하면 정책이나 도구 설명을 조정할 근거가 된다. 중요한 작업이 승인 없이 지나갔다면 선택 규칙과 실행 경계부터 확인해야 한다.

 

사람의 검토 품질도 환경에 영향을 받는다. 확인할 자료가 부족하거나 요청이 너무 많으면 판단이 어려워진다. 따라서 “사람이 승인했다”는 문장만으로 시스템의 모든 책임을 넘길 수는 없다. 자동 검증과 명확한 정보 제공, 권한 제어, 실행 후 확인이 함께 있어야 HITL이 실질적인 역할을 한다.

자주 묻는 질문

Q. 프롬프트에 승인받으라고 쓰면 HITL이 구현되나요?

지시는 도움이 될 수 있지만 실행 허가를 강제하는 구조와는 다르다. 도구 실행 경로에서 승인 필요 여부를 판정하고 상태와 결정을 연결해야 한다. 모델이 요청을 따르지 않거나 다른 경로를 택해도 같은 권한 경계가 유지되는지 확인해야 한다.

Q. LangGraph의 thread_id를 알면 재개 권한이 있나요?

아니다. thread_id는 저장된 실행 상태를 찾는 식별자다. 누가 해당 상태를 읽고 승인하고 재개할 수 있는지는 애플리케이션에서 인증과 권한으로 확인해야 한다. 식별자 소유와 실행 허가는 별개의 문제다.

Q. interrupt 다음 줄부터 그대로 이어서 실행되나요?

LangGraph 공식 문서는 재개할 때 중단이 발생한 노드의 처음부터 다시 실행된다고 설명한다. interrupt 이전 코드가 재실행될 수 있으므로 부작용을 신중하게 배치해야 한다. 다른 SDK에는 그 SDK의 재개 규칙을 확인해야 한다.

Q. 한 번 승인한 도구는 다음에도 자동으로 써도 되나요?

일회성 호출 승인과 지속 허용은 다르다. 사용자가 허용한 범위와 SDK의 승인 상태 수명 및 도구 식별 규칙을 확인해야 한다. 이름이 같아도 대상과 권한, 실행 환경이 달라지면 같은 결정으로 볼 수 없을 수 있다.

Q. 승인 버튼을 비활성화하면 중복 실행을 막을 수 있나요?

사용자 인터페이스에서 중복 클릭을 줄일 수 있지만 서버 재전송과 동시 요청까지 보장하는 것은 아니다. 대기 결정의 원자적인 소비와 실행 단계의 중복 방지, 외부 결과 확인이 별도로 필요할 수 있다. 어떤 단계가 무엇을 보장하는지 구분해야 한다.

Q. 모든 단계에서 사람에게 물어야 더 안전한가요?

반드시 그렇지는 않다. 과도한 확인은 검토 부담과 관성적인 클릭을 늘릴 수 있다. 사전에 허용된 범위와 변경의 영향을 기준으로 필요한 지점을 고르고, 이미 허용된 작업의 반복 확인을 줄이는 편이 실용적이다. 중요한 것은 승인 횟수보다 승인 대상과 범위의 명확성이다.

좋은 HITL은 사람이 판단할 수 있는 경계를 만든다

AI 에이전트의 Human-in-the-Loop는 멈춤 버튼을 하나 추가하는 작업보다 넓다. 검토할 실행 후보를 정하고, 정당한 사람이 결정하게 하며, 그 결정이 정해진 대상과 시간 안에서만 쓰이도록 연결해야 한다. 중단과 재개, 수정과 거절, 만료와 복구까지 하나의 흐름으로 다뤄야 한다.

 

자동화의 속도와 사람의 판단은 무조건 반대되는 목표가 아니다. 불필요한 확인을 줄이고 중요한 차이를 분명하게 보여 주면 사람이 판단할 지점도 더 선명해진다. 승인 버튼의 존재보다 승인된 내용과 실제 실행이 일치하는지, 변화와 장애가 생겨도 그 관계를 확인할 수 있는지가 좋은 HITL을 가르는 기준이다.

공식 문서와 한국어 기술 블로그 출처

LangGraph 공식 문서, Interrupts. 상태 저장과 thread_id, Command를 이용한 재개, 노드 재실행과 중단 호출 순서 및 부작용 처리 규칙을 확인했다. 문서의 개념을 설명했으며 특정 버전에 종속된 전체 실행 코드를 그대로 재현하지 않았다. 원문: https://docs.langchain.com/oss/python/langgraph/interrupts

Interrupts - Docs by LangChain

 

OpenAI Agents SDK 공식 문서, Human-in-the-loop. 호출별 승인과 지속 결정, RunState 직렬화, 서버 소유 승인 상태와 승인자 인증, 장기 대기 작업의 버전 관리 원칙을 확인했다. 세부 지원 도구와 승인 범위는 사용하는 버전에서 다시 확인해야 한다. 원문: https://openai.github.io/openai-agents-python/human_in_the_loop/

Human-in-the-loop - OpenAI Agents SDK

 

AWS 기술 블로그, 티오더의 Text2SQL 에이전트 티스푼 구현 사례. 2026년 4월 17일 게시. 의도 확인과 SQL 실행 확인을 나눈 두 단계 HITL, 구문 검사와 업무 의미 검토의 차이를 설명하는 실제 적용 사례다. 사례의 승인 횟수를 모든 업무의 필수 조건으로 일반화하지 않았다. 원문: https://aws.amazon.com/ko/blogs/tech/torder-text2sql-case/

티오더의 Text2SQL 에이전트 티스푼 구현 사례 | Amazon Web Services

 

ybin's, LangGraph 기초 5: Interrupt가 필요한 이유. 2026년 1월 3일 게시. 한국어 개발 블로그에서 중단, 체크포인트, 동일한 thread_id로 재개하는 과정을 설명하는 전개를 비교했다. 예제 코드를 운영용 인증과 권한 제어까지 구현된 서비스로 간주하지 않았다. 원문: https://gksyb4235.tistory.com/71