AI 에이전트를 설계할 때 많은 팀은 처음에 정확도부터 붙잡는다. 답을 더 잘하게 만들고, 도구를 더 잘 고르게 만들고, 더 긴 작업을 끝까지 수행하게 만들고 싶어 한다. 물론 중요하다. 하지만 제품 수준에서는 다른 질문이 더 먼저 온다. 틀렸을 때 얼마나 위험한가. 실패했을 때 어디까지 망가질 수 있는가. 그리고 그 순간 누가, 어떻게 멈추고 되돌릴 수 있는가.
좋은 에이전트는 실수하지 않는 에이전트가 아니다. 그런 시스템은 없다. 좋은 에이전트는 실수해도 큰 사고를 내지 않는 에이전트다. 마치 좋은 자동차가 절대 미끄러지지 않는 자동차가 아니라, 미끄러질 때도 브레이크와 에어백과 차체 구조로 피해를 줄이는 자동차인 것처럼 말이다. 하네스의 안전장치도 똑같다. 모델의 판단이 조금 흔들려도, 작업이 예상과 다르게 흘러도, 그 실수가 곧바로 외부 사고로 번지지 않게 막아야 한다.
안전장치는 성능의 반대말이 아니다
안전장치를 이야기하면 가끔 이런 반응이 나온다. "그렇게 많이 막으면 에이전트가 쓸모없어지는 것 아닌가요?" 겉보기에는 그럴 수 있다. 자동화를 붙였는데 자꾸 멈추고, 승인받고, 제한된 범위 안에서만 움직이면 답답해 보이기도 한다.
하지만 실제 운영에서는 반대다. 안전장치가 없는 자동화는 초반에는 시원해 보여도 오래 못 간다. 한 번 큰 실수를 하면 팀 전체가 겁을 먹고, 권한을 회수하고, 결국 자동화를 꺼버리기 쉽다. 반대로 안전장치가 잘 설계된 시스템은 처음에는 조금 보수적으로 보일 수 있어도, 시간이 지날수록 더 많은 일을 맡길 수 있다. 신뢰가 쌓이기 때문이다.
즉, 안전장치는 에이전트를 약하게 만드는 장치가 아니라 오래 일하게 만드는 장치다. 브레이크가 달린 차가 더 멀리 달릴 수 있는 것과 같은 이치다.
안전한 구조는 "실패 가능성"이 아니라 "피해 반경"을 다룬다
에이전트 설계를 처음 접하면 실패를 없애려는 생각부터 하기 쉽다. 더 좋은 프롬프트, 더 좋은 모델, 더 좋은 평가셋을 찾는다. 물론 이것도 필요하다. 하지만 운영 시스템에서 더 실용적인 목표는 실패 자체를 0으로 만드는 것이 아니라, 실패의 피해 반경을 줄이는 것이다.
예를 들어 같은 잘못된 판단이라도 결과는 크게 다를 수 있다. 일정 후보를 잘못 고른 에이전트가 초안만 만들어 두었다면 사람 검토에서 잡히고 끝난다. 반면 같은 에이전트가 외부 고객에게 바로 확정 메일을 보내버리면 이야기가 달라진다. 모델의 실수는 비슷했지만, 하네스의 구조가 사고 규모를 갈랐다.
이 관점은 중요하다. 에이전트 안전성은 "얼마나 똑똑한가"보다 "어디서 멈추는가, 무엇을 바꾸지 못하게 하는가, 잘못 바꾼 것을 어떻게 되돌리는가"에서 훨씬 크게 결정된다.
멈춤 조건은 에이전트의 브레이크다
많은 팀이 에이전트에게 시작 신호는 잘 준다. 목표를 주고, 도구를 연결하고, 루프를 만들고, 결과를 내라고 한다. 그런데 의외로 자주 빠지는 것이 멈춤 설계다. 어디서 끝나야 하는지, 어느 순간 더 진행하면 안 되는지, 어떤 신호가 오면 사람에게 넘겨야 하는지가 모호하다.
멈춤 조건은 단순한 예외 처리 문장이 아니다. 그것은 에이전트의 브레이크다. 브레이크가 없는 시스템은 빠를 수는 있어도 안전하지 않다.
실무에서 멈춤 조건은 보통 몇 가지 층으로 나뉜다.
목표를 달성했고 검증도 통과했을 때 멈춘다.
같은 실패가 반복되고 새 진전이 없을 때 멈춘다.
시간, 비용, 토큰, 호출 수 같은 예산을 넘기기 전에 멈춘다.
권한 경계나 정책 경계를 건드리면 멈춘다.
외부 영향이 생기는 행동 직전에는 자동으로 멈추고 승인 대기로 전환한다.
여기서 특히 중요한 것은 무진전 상태에서의 멈춤이다. 에이전트는 성실해 보이면서도 같은 실수를 반복할 수 있다. 비슷한 검색을 되풀이하고, 이미 실패한 도구를 다시 부르고, 같은 파일을 여러 번 훑고, 같은 가설을 다른 말로 포장해 밀어붙인다. 겉으로는 열심히 일하지만 실제로는 제자리걸음이다. 이럴 때 "한 번 더 해보자"는 끈기가 아니라 "여기서 멈추자"는 판단이 필요하다.
좋은 하네스는 많이 시도하는 시스템이 아니라, 더 시도해도 달라질 것이 없는 순간을 알아채는 시스템이다.
멈춤 신호는 성공 신호보다 더 구체적이어야 한다
성공은 보통 한 문장으로 말할 수 있다. "테스트를 통과했다." "초안이 완성됐다." "분석 결과가 저장됐다." 그런데 멈춤은 더 복잡하다. 성공이 아닌 상태가 너무 많기 때문이다.
그래서 멈춤 신호는 가능하면 구체적으로 설계해야 한다. 단순히 error=true만 보는 것은 부족하다. 같은 오류라도 의미가 다르기 때문이다. 네트워크 일시 장애는 잠깐 후 재시도해볼 수 있지만, 권한 거부는 승인 경로로 보내야 한다. 대상 파일이 없다는 오류는 경로를 다시 확인하게 해야 하고, 결과가 정책에 어긋난다는 판정은 즉시 중단해야 한다.
실무적으로는 멈춤 신호를 네 갈래 정도로 분류해두면 유용하다.
재시도 가능 실패: 일시적인 네트워크 문제, 도구 응답 지연, 잠깐의 리소스 부족
재계획 필요 실패: 처음 가설이 틀렸거나, 다른 도구를 써야 하거나, 작업 분해가 잘못된 경우
승인 필요 상태: 읽기 단계는 끝났지만 이제 실제 반영이 필요한 경우
즉시 중단 상태: 정책 위반 가능성, 민감 정보 노출 위험, 대량 변경 징후, 예산 급상승
이렇게 나누면 시스템이 실패를 덜 감정적으로 다룬다. 모든 실패를 "다시 시도"로 몰아넣지 않고, 각 실패를 다른 제어 경로로 보낼 수 있다.
재시도는 끈기가 아니라 규율이어야 한다
재시도는 에이전트 시스템에서 매우 유용하다. 외부 API는 흔들릴 수 있고, 네트워크는 잠깐 끊길 수 있고, 모델 호출도 때로는 불안정할 수 있다. 이런 경우 재시도는 상당히 효과적이다.
문제는 재시도가 쉽게 습관이 된다는 점이다. 결과가 마음에 안 들면 또 시도하고, 오류가 나면 또 시도하고, 잘 모르겠으면 또 시도한다. 그러다 보면 재시도는 복구 기법이 아니라 비용 증폭기가 된다.
좋은 재시도는 세 가지 규율을 가진다.
첫째, 무엇을 재시도할 것인지가 분명해야 한다. 일시적인 장애에만 재시도하고, 논리적 오류나 권한 오류에는 다른 경로를 택해야 한다.
둘째, 몇 번까지 재시도할 것인지가 정해져 있어야 한다. 제한 없는 재시도는 자동 복구가 아니라 자동 루프다.
셋째, 재시도 사이에 무엇이 달라지는지가 있어야 한다. 시간 간격을 두거나, 다른 미러 엔드포인트를 쓰거나, 컨텍스트를 줄이거나, 계획을 바꿔야 한다. 아무것도 바뀌지 않는데 같은 요청만 다시 보내는 것은 복구가 아니다.
예를 들어 검색 API가 일시적으로 실패했다면 두세 번의 지수 백오프 재시도가 합리적일 수 있다. 하지만 "잘못된 테이블 이름으로 SQL을 계속 만들고 있다"는 문제에 재시도를 거는 것은 어리석다. 이 경우는 재시도가 아니라 재계획이 필요하다.
한마디로, 재시도는 "한 번 더!"를 외치는 버튼이 아니라, 제한된 조건에서만 열리는 작은 비상구여야 한다.
자동 수정과 자동 악화는 종이 한 장 차이다
자기 수정 능력은 에이전트의 매력적인 특성 중 하나다. 실패를 읽고, 원인을 추정하고, 다시 시도하고, 결과를 개선하는 흐름은 분명 강력하다. 하지만 이 구조는 언제든 자동 악화로 뒤집힐 수 있다.
예를 들어 코딩 에이전트가 테스트 실패를 고치겠다며 수정 범위를 계속 넓히는 상황을 떠올려 보자. 처음에는 작은 함수 하나를 고치려 했는데, 실패가 이어지자 설정 파일을 바꾸고, 의존성을 건드리고, 관련 없는 모듈까지 수정하기 시작한다. 에이전트 입장에서는 문제를 해결하려는 시도지만, 시스템 입장에서는 사고 반경이 커지고 있다.
그래서 자동 수정 구조에는 반드시 변경 폭 제한이 필요하다. 한 번의 수정에서 건드릴 수 있는 파일 수, 허용되는 작업 종류, 수정 가능한 디렉터리, 허용되는 명령 범위 등을 좁혀야 한다. 실패가 길어질수록 범위를 넓히는 것이 아니라, 오히려 사람 검토 쪽으로 보내야 한다.
좋은 하네스는 에이전트가 실패했을 때 더 큰 망치를 쥐여주지 않는다. 먼저 멈추게 하고, 바깥에서 상황을 보게 하고, 필요한 경우에만 더 큰 권한을 준다.
롤백은 "되돌리기 버튼"이 아니라 상태 관리 전략이다
안전장치를 이야기할 때 많은 사람이 롤백을 단순한 되돌리기 기능으로 생각한다. 물론 맞는 말이다. 하지만 실제 시스템에서는 조금 더 넓게 봐야 한다. 롤백은 단지 실행 후 취소하는 버튼이 아니라, 되돌릴 수 있는 형태로 상태를 바꾸는 설계 방식 자체에 가깝다.
같은 작업이라도 어떻게 실행하느냐에 따라 복구 난이도가 크게 달라진다. 예를 들어 운영 문서를 바로 수정하는 구조와 초안 사본을 만든 뒤 검토 후 교체하는 구조는 모두 같은 목적을 향하지만, 실패했을 때의 회복력은 완전히 다르다. 전자는 잘못 쓰면 원본이 바로 오염된다. 후자는 원본을 지킨 채 수정안을 버리면 끝난다.
그래서 좋은 하네스는 가능한 한 세상을 직접 바꾸기 전에 중간 상태를 만든다. 임시 브랜치, 초안 레코드, 발송 대기함, 스테이징 테이블, 샌드박스 파일 시스템 같은 것들이 여기에 속한다. 이런 중간층이 있으면 에이전트가 실수해도 실제 세계는 바로 바뀌지 않는다.
롤백은 실행 뒤에 생각하는 것이 아니라, 실행 전에 "어떻게 하면 나중에 쉽게 되돌릴 수 있을까"를 먼저 묻는 태도다.
복구 가능한 작업으로 바꾸는 세 가지 방법
모든 작업을 완벽하게 되돌릴 수는 없다. 이미 발송된 이메일, 외부 시스템에 반영된 일정, 사람에게 노출된 잘못된 메시지는 시간을 되감듯 지울 수 없다. 그래도 복구력을 높일 수는 있다. 보통 세 가지 방법이 실무에서 특히 유용하다.
첫째는 사전 스냅샷이다. 변경 전 상태를 저장해두면 복구 기준점이 생긴다. 파일이라면 원본 버전, 데이터라면 변경 전 레코드, 설정이라면 이전 구성값이 여기에 해당한다.
둘째는 보상 작업이다. 되돌리기 자체가 불가능할 때는 반대 동작을 설계해야 한다. 잘못 생성한 일정을 취소하고 사과 메일을 보내는 것, 잘못 업데이트한 CRM 상태를 이전 상태로 복원하는 것 등이 이런 방식이다.
셋째는 지연 반영이다. 즉시 반영하지 않고 대기 구간을 두는 방법이다. 발송 예약, 승인 대기 큐, 검토 전 게시 보류 같은 구조는 사실상 복구 시간을 벌어주는 장치다.
중요한 것은 복구가 기술적으로만 가능하다고 끝이 아니라는 점이다. 복구는 빨라야 하고, 누가 실행할지 분명해야 하고, 복구 이후 어떤 흔적을 남길지도 정해져 있어야 한다. 느리고 애매한 복구는 실전에서는 없는 복구나 비슷하다.
체크포인트가 있으면 긴 작업도 덜 무섭다
에이전트가 짧은 응답 한 번으로 끝나는 경우보다, 여러 단계 작업을 이어서 수행하는 경우가 점점 늘고 있다. 이때 복구를 어렵게 만드는 것은 한 번의 큰 실수보다, 긴 작업 중간의 작은 꼬임들이다. 앞단에서 잘못 읽은 정보를 바탕으로 중간 산출물이 쌓이고, 나중에는 어디서부터 어긋났는지 알기 어려워진다.
그래서 긴 작업에는 체크포인트가 필요하다. 작업을 일정 구간마다 저장하고, 그 지점부터 다시 시작할 수 있게 만드는 것이다. 체크포인트는 단순히 진행률 저장만 의미하지 않는다. 그 시점의 목표, 사용한 입력, 중간 결과, 변경된 상태, 남은 예산을 함께 보존해야 한다.
이 구조가 있으면 복구가 훨씬 쉬워진다. 처음부터 전부 다시 돌리지 않아도 되고, 잘못된 지점 이전으로 돌아가 다른 전략을 시도할 수 있다. 무엇보다도 긴 작업이 "한 번에 다 성공해야 하는 도박"이 아니라, 구간별로 통제 가능한 작업으로 바뀐다.
승인 게이트는 마지막 순간의 인터록이다
권한 설계가 행동 가능 범위를 정하는 지도라면, 승인 게이트는 위험 구간 앞에 놓인 인터록이다. 문은 열 수 있지만, 아무나 아무 때나 열 수는 없는 구조다.
승인 게이트의 핵심은 사람을 자주 부르는 데 있지 않다. 오히려 반대다. 정말 중요한 순간에만 선명하게 부르는 것이 중요하다. 승인 요청이 너무 자주 오면 사람은 결국 읽지 않게 된다. 그러면 승인 시스템은 존재하지만 판단은 사라진다.
좋은 승인 게이트는 보통 이런 순간에 배치된다.
외부 커뮤니케이션이 실제 발송되기 직전
공용 자산이나 운영 데이터를 변경하기 직전
삭제, 대량 변경, 권한 변경처럼 되돌리기 어려운 작업 직전
자동화가 정책 경계에 가까이 갔을 때
예외 상황이라 에이전트의 자신감보다 사람의 판단이 더 중요한 순간
여기서 중요한 것은 승인 요청의 문장이다. "계속할까요?"는 형편없는 승인 인터페이스다. 무엇을, 어디에, 얼마나, 왜 바꾸려는지 보여줘야 한다. 가능하다면 미리보기와 예상 영향 범위도 함께 보여주는 편이 좋다.
승인은 단순한 예외 처리 창이 아니다. 그것은 사람이 책임 있는 판단을 할 수 있게 만드는 정보 인터페이스다.
가장 안전한 자동화는 초안에서 멈출 수 있다
많은 업무는 사실 완전 자동 실행이 아니라 초안 자동화만으로도 큰 가치를 낸다. 이메일 답장, 일정 조정, 보고서 작성, 코드 패치, SQL 쿼리, 고객 응대 문안 같은 것들이 그렇다. 에이전트가 준비는 빠르게 하되, 마지막 반영은 사람이 누르게 하는 방식이다.
이 구조의 장점은 단순하다. 에이전트는 속도와 편의를 제공하고, 사람은 책임과 최종 판단을 맡는다. 특히 외부 영향이 큰 작업에서 이 조합은 매우 강력하다. 시스템은 실용적이면서도 과감하지 않다.
실무에서는 "완전 자동화가 목표"라고 쉽게 말하지만, 실제로 오래 살아남는 경우는 초안 자동화 → 제한된 실행 자동화 → 조건부 승인 자동화처럼 단계적으로 올라가는 구조가 많다. 처음부터 마지막 버튼까지 자동으로 누르게 만들기보다, 준비와 반영을 분리하는 편이 훨씬 안전하다.
단계적 자동화는 신뢰를 쌓는 방법이다
자동화 수준을 한 번에 높이는 것은 위험하다. 에이전트가 데모에서는 잘 보였더라도, 실제 데이터와 실제 사용자와 실제 예외 상황 속에서는 다른 얼굴을 보일 수 있다. 그래서 운영에서는 자동화 수준을 계단처럼 올려야 한다.
가장 현실적인 구조는 보통 다음과 같다.
관찰 모드: 에이전트는 읽고 분석하고 제안만 한다.
초안 모드: 실행 결과를 준비하지만 실제 반영은 하지 않는다.
제한 실행 모드: 좁은 범위의 가역적 작업만 자동으로 수행한다.
승인 기반 실행 모드: 영향이 큰 작업은 승인 후 실행한다.
선별 자율 모드: 충분히 검증된 좁은 작업군에 한해 자동 실행한다.
중요한 것은 이 계단을 기능 단위로 다르게 적용하는 것이다. 검색과 요약은 비교적 빠르게 자율화할 수 있다. 반면 외부 발송, 결제, 삭제, 운영 설정 변경은 훨씬 늦게 열어야 한다. 모든 작업을 한 등급으로 묶으면 설계가 거칠어진다.
단계적 자동화의 진짜 장점은 속도를 늦추는 데 있는 것이 아니라, 학습과 신뢰를 쌓을 시간을 버는 데 있다. 시스템이 어디서 흔들리는지, 사람들이 어디서 불안해하는지, 어떤 승인 문구가 혼란을 부르는지, 어떤 예외가 자주 발생하는지를 보면서 점진적으로 넓혀갈 수 있다.
샌드박스, 브랜치, 대기열은 모두 안전장치다
안전장치를 이야기하면 흔히 정책과 승인만 떠올리기 쉽다. 하지만 실행 환경 자체도 중요한 안전장치다. 에이전트가 일하는 장소를 어떻게 만들었느냐에 따라 사고 규모가 크게 달라진다.
예를 들어 코딩 에이전트가 바로 메인 브랜치를 수정하게 하는 것과, 임시 브랜치에서만 일하게 하는 것은 전혀 다르다. 업무 자동화 에이전트가 실제 발송함에 바로 접근하는 것과, 발송 대기열에만 넣을 수 있게 하는 것도 다르다. 데이터 분석 에이전트가 운영 DB에 직접 쓰는 것과, 스테이징 테이블에만 결과를 저장하는 것도 마찬가지다.
이런 구조들은 겉보기에 느려 보일 수 있지만, 실제로는 시스템을 훨씬 빠르게 개선하게 해준다. 왜냐하면 실패를 두려워하지 않고 실험할 수 있기 때문이다. 샌드박스와 브랜치와 대기열은 모두 "잘못되면 버릴 수 있는 공간"을 만들어 준다. 그 공간이 있어야 자동화는 대담해질 수 있다.
안전한 복구는 사람도 이해할 수 있어야 한다
복구 절차가 시스템 내부에서만 복잡하게 얽혀 있으면 실전에서 잘 작동하지 않는다. 문제가 커질수록 결국 사람의 개입이 들어오게 마련인데, 그때 운영자나 담당자가 상황을 이해하지 못하면 복구는 더 느려진다.
그래서 복구 설계는 기술적 정확성뿐 아니라 설명 가능성도 중요하다. 지금 무엇이 실패했는지, 어떤 상태가 바뀌었는지, 무엇을 되돌릴 수 있고 무엇은 되돌릴 수 없는지, 다음으로 어떤 조치를 해야 하는지가 사람이 읽을 수 있는 형태로 제공되어야 한다.
좋은 복구 인터페이스는 보통 다음 질문에 답할 수 있어야 한다.
어디서 실패했는가
무엇이 이미 실행되었는가
무엇은 아직 실행되지 않았는가
어떤 롤백 수단이 있는가
자동 복구가 가능한가, 아니면 사람 승인이 필요한가
복구 후 어떤 후속 조치가 필요한가
복구는 시스템의 뒷정리 기능이 아니다. 운영팀이 실제로 사고를 다룰 수 있게 만드는 실무 기능이다.
사용자에게도 "안전한 자동화"가 보여야 한다
안전장치는 내부 엔지니어링만의 문제가 아니다. 사용자가 시스템을 어떻게 느끼는지도 중요하다. 에이전트가 갑자기 조용히 많은 행동을 하고, 예상치 못한 시점에 외부 메시지를 보내고, 실패했는지 성공했는지 설명 없이 멈춰버리면 사람은 금방 불안해진다.
반대로 좋은 시스템은 적어도 중요한 순간을 드러낸다. 지금 초안을 만드는 중인지, 승인 대기인지, 위험한 변경이라 멈춘 것인지, 복구를 시도 중인지가 보이면 사용자는 시스템을 더 잘 신뢰할 수 있다.
에이전트의 안전성은 실제로 안전한 것만으로 충분하지 않다. 안전하게 작동하고 있다는 사실이 이해 가능해야 한다. 사용자 경험 측면에서도 이것은 매우 중요하다. 사람은 보이지 않는 자동화보다, 통제 가능하다고 느껴지는 자동화를 훨씬 오래 받아들인다.
실전에서 먼저 점검할 안전 설계 질문
안전장치와 복구 설계가 막연하게 느껴진다면, 거창한 프레임워크보다 몇 가지 질문부터 던져보는 편이 낫다.
이 에이전트는 어디서 자동으로 멈춰야 하는가.
어떤 실패는 재시도하고, 어떤 실패는 사람에게 넘겨야 하는가.
한 번의 실행에서 바뀔 수 있는 상태의 범위는 얼마나 되는가.
잘못 실행되었을 때 되돌릴 수 있는가. 되돌릴 수 없다면 중간 상태를 만들 수 있는가.
승인 요청은 정말 중요한 순간에만 뜨는가, 아니면 습관적으로 뜨는가.
자동화 수준을 지금보다 한 단계 낮춰도 충분한 가치를 낼 수 있는가.
긴 작업 중간에 안전하게 다시 시작할 체크포인트가 있는가.
대량 변경, 외부 발송, 삭제 같은 고위험 행동은 별도로 격리되어 있는가.
이 질문에 선명하게 답하지 못한다면, 시스템이 작동하더라도 아직 안전하게 운영된다고 보기는 어렵다.
잘 멈추는 에이전트가 오래 살아남는다
에이전트 설계에서 흔히 칭찬받는 것은 속도, 자율성, 영리함이다. 하지만 운영에서는 다른 미덕이 더 중요할 때가 많다. 멈출 줄 아는 능력, 범위를 넘지 않는 습관, 잘못 건드린 것을 복구할 수 있는 구조, 사람에게 적절한 순간에 도움을 요청하는 태도다.
좋은 하네스는 에이전트를 영웅으로 만들지 않는다. 대신 믿을 수 있는 작업자로 만든다. 무모하게 끝까지 밀어붙이는 시스템보다, 위험한 순간에 브레이크를 밟고, 수정안을 초안에 머물게 하고, 필요한 경우 되돌리고, 다시 안전한 지점에서 시작하는 시스템이 훨씬 더 제품답다.
자동화의 목표는 통제를 버리는 것이 아니다. 오히려 더 넓은 자동화를 가능하게 하는 새로운 통제 방식을 만드는 것이다. 안전장치와 복구 설계는 바로 그 통제의 기술이다.
결국 좋은 에이전트는 완벽한 에이전트가 아니다. 실수해도 큰 사고를 내지 않고, 사고가 나도 빨리 멈추고, 멈춘 뒤에는 다시 회복할 수 있는 에이전트다. 제품이 원하는 것은 천재성이 아니라 신뢰다. 그리고 신뢰는 대개 브레이크, 에어백, 그리고 복구 매뉴얼에서 시작된다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.