한 고객지원 책임자가 AI를 사건 시스템에 연결하기 전에, 개인 정보를 지운 환불 티켓 한 건으로 시험을 했다. 환불 날짜는 비어 있었고, 상담 기록에는 택배가 이미 발송됐다고 적혀 있었지만, 배송 조회에는 “운송장 생성"만 떠 있었다. 책임자가 AI에게 맡긴 범위는 하나였다. 지금 있는 증거를 바탕으로 답장 초안을 준비하는 것.
초안은 금방 나왔다. 이어서 AI는 메일 발송 도구를 부르고, 추측한 배송 상태를 사건에 다시 써 넣고, 내친김에 같은 고객의 다른 티켓까지 열려고 했다. 이 흐름이 모델 스스로 “확실하지 않다"고 말해 주기만을 기대할 수밖에 없다면, 세 동작은 이미 선을 넘은 뒤다.
그래서 AI가 언제 멈추고 사람에게 물어야 하는지는 모델의 자기 평가에 맡기지 않고, 시스템이 볼 수 있는 사건으로 적어 둔다. 멈출 때는 다른 사람이 이어받을 수 있는 기록도 남긴다.
모델의 자기 평가를 유일한 스위치로 삼을 수는 없다
모델이 솔직하게 “확실하지 않다"고 말하는지는 모든 공급자가 개선하고 있지만, 그것을 유일한 스위치로 삼기에는 맞지 않는다. 빈 날짜를 자신 있게 채울 수도 있고, 서로 모순되는 두 배송 상태를 평균 내 그럴듯한 답 하나로 만들 수도 있다.
Anthropic의 엔지니어링 가이드는 AI 에이전트가 단계마다 도구 실행 결과 같은 환경에서 “실제 상태"를 얻고, 체크포인트나 막히는 지점에서 멈춰 사람의 의견을 받으라고 권한다. 동시에 중지 조건을 정하고, 샌드박스에서 충분히 시험하고, 적절한 안전장치를 두라고 한다. OpenAI의 에이전트 개발 키트는 구체적인 방법을 보여 준다. 민감한 도구에 승인이 필요하다고 미리 표시해 두면, 실행이 그 지점에서 멈추고 상태를 저장한 뒤, 사람이 승인하거나 거절해야 이어진다. 두 자료가 가리키는 것은 같다. 통제 지점은 모델 바깥에 두고, 시스템이 알아볼 수 있어야 한다.
네 가지 상황을 멈춤 사건으로 적는다
핵심 항목이 비어 있다. 결과를 정하는 항목이 비어 있다. 예를 들어 환불 날짜다. 올바른 결과는 초안에 빠진 항목을 표시하는 것이지, “오늘"로 채우는 것이 아니다.
출처가 서로 모순된다. 상담 기록과 배송 데이터의 말이 다르다. 올바른 결과는 양쪽의 값, 시각, 출처를 나란히 놓고 사람에게 판단을 넘기는 것이지, 한쪽을 고르는 것이 아니다.
다음 단계가 밖으로 무언가를 보낸다. 메일 발송, 시스템에 다시 쓰기, 결제, 삭제, 권한 변경은 모두 초안이 외부 사실이 되는 순간이다. 여기서 멈추고 정확한 미리 보기를 넘긴다.
중단 뒤 상태를 알 수 없다. 도구가 시간 초과 직전에 쓰기에 성공했을 수도 있다. 먼저 현재 상태를 확인하고, 이어 갈지 보완할지를 정한다. 그냥 다시 돌리면 두 번째 메일을 보내거나 두 번째 결제를 할 수 있다. 중간에 실패했을 때의 정리 방법은 자동화가 중간에 멈췄다면, 다시 돌리기 전에 이미 무슨 일이 있었는지부터 확인한다을 참고하자.
승인하는 것은 동작 한 번이지, 일의 종류 전체가 아니다
“이 민원을 처리해 줘"는 실행할 수 있는 승인이 아니다. 승인 내용에는 받는 사람, 초안 버전, 인용한 주문과 배송 상태, 호출할 도구, 이번 호출로 무엇이 바뀌는지를 적는다. 하나라도 바뀌면 예전 승인은 무효가 된다. 그래야 익숙한 “보내기” 버튼만 보고 내용이나 받는 사람이 바뀐 것을 놓치는 일을 막을 수 있다. AI 보안 위험을 정리하는 국제 커뮤니티 OWASP도 영향이 큰 동작은 실행 전에 사람이 승인하고, 권한 확인은 모델에 맡기지 말고 하위 시스템에서 하라고 권한다.
흐름이 코드를 고친다면 승인 대상은 이번 변경분, 테스트 결과, 되돌리는 방법이다. 이 issue를 coding agent에 맡길 수 있는지는 첫 번째 diff를 적을 수 있느냐에 달렸다를 참고하자.
멈춘 뒤의 기록은 다음 사람이 받아 들 수 있어야 한다
멈출 때 “자료 부족, 사람이 확인해 주세요"라고만 돌려주면 조사 전체를 이어받는 사람에게 던지는 셈이다. 멈춤 기록에는 적어도 다음이 있어야 한다. 계기가 된 사건, 어떤 동작 앞에서 멈췄는지, 끝낸 일과 못 끝낸 일, 각 결론의 출처, 이미 일어났을 수 있는 외부 영향, 다음 담당자, 그리고 외부 영향을 늘리지 않는 다음 단계.
도입할 때 모든 예외를 한 번에 적을 필요는 없다. 실제 흐름 하나를 골라 첫 번째로 밖에 나가는 동작을 찾고, 누락, 모순, 상태 불명에 대해 각각 한 번씩 깨뜨리는 시험을 한다. 멈추는 지점, 승인 내용, 기록이 안정적으로 재현되면 그다음 도구를 연결한다.
AI 정리 카드
이미 AI가 연결된 업무 흐름 하나를 점검해, 멈춰야 할 때 멈추는지, 멈출 때 다른 사람이 이어받을 수 있는 기록을 남기는지 확인하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/claude-opus-4-8-honesty-matters-in-workflows/
글의 관점은 이렇다. AI가 언제 멈춰야 하는지는 모델이 스스로 확실하지 않다고 말하는 데 기댈 수 없다. 시스템이 볼 수 있는 사건으로 적는다. 핵심 항목 누락, 출처 간 모순, 다음 단계가 밖으로 무언가를 보내는 일, 중단 뒤 상태를 알 수 없음. 승인하는 것은 정확한 동작 한 번이고, 멈출 때는 이어받을 수 있는 기록을 남긴다.
내가 허락한 이 흐름을 읽기 전용으로 따라가 달라. 보내기, 다시 쓰기, 삭제, 결제, 권한 변경은 하지 말 것.
1. 내용이 처음 외부 사실이 되는 단계를 찾고, 그것이 무엇을 바꾸는지 설명할 것;
2. 그 전에 핵심 항목 누락, 서로 모순되는 출처, 중단 뒤 확인할 수 없는 상태가 있는지 살필 것. 항목마다 읽은 필드, 파일 이름, 도구 결과를 인용하고, 읽지 못한 것은 "미확보"로 표시할 것;
3. 승인 내용 초안을 쓸 것. 승인할 정확한 동작, 받는 사람이나 쓰기 위치, 근거 데이터, 승인할 사람;
4. 멈춤 기록을 쓸 것. 계기 사건, 어느 단계 앞에서 멈췄는지, 끝낸 일과 못 끝낸 일, 이미 일어났을 수 있는 외부 영향, 다음 담당자, 외부 영향을 늘리지 않는 다음 단계.
마지막에는 하나만 고를 것. 원래 범위에서 계속, 초안이나 읽기 전용 확인으로 축소, 사람이 정할 때까지 멈춤 유지. 상태를 알 수 없으면 먼저 현재 상태를 확인하고, 그냥 다시 돌리지 말 것.
참고 자료
- Anthropic Engineering (official): Building effective agents — https://www.anthropic.com/engineering/building-effective-agents (2024-12-19)
- OpenAI Agents SDK official documentation: Human-in-the-loop — https://openai.github.io/openai-agents-python/human_in_the_loop/ [accessed: 2026-10-11]
- OWASP Gen AI Security Project: LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ [accessed: 2026-10-11]
