AI 에이전트 자동화를 운영하다 보면 모델이 틀린 답을 낼 때보다 훨씬 조용하고 빠르게 번지는 문제가 있다. 훅(hook), 즉 생명주기 이벤트에 붙어 있는 자동 실행 코드가 스스로를 다시 호출하는 구조다. 모델이 잘못된 추론을 하면 결과물을 보고 알아차릴 수 있지만, 재귀 실행은 로그가 쌓이고 비용이 빠져나가는 동안 겉으로는 아무 일도 없어 보인다. 발견했을 때는 이미 되돌리기 어려운 상태인 경우가 많다.
훅이 루프가 되는 순간
훅은 원래 단순하다. "이 시점이 오면 이 코드를 한 번 실행한다"가 전부다. 세션 종료, 작업 완료, 파일 변경처럼 정해진 이벤트에 붙어 있고, 한 번 실행하고 끝나는 게 정상 동작이다.
그런데 그 훅 안에서 새 에이전트 세션이나 새 프로세스를 만들면 구조가 달라진다. 새로 만들어진 세션이 같은 설정 파일을 로드하고, 같은 훅이 걸려 있는 환경에서 작업을 마치면, 그 세션의 종료 이벤트가 또 훅을 발화시킨다. 종료가 생성을 낳고, 생성이 다시 종료를 낳는 순환이다.
루프라는 설계 개념에는 반드시 멈추는 조건이 들어간다. "테스트가 모두 통과하면 멈춘다", "최대 다섯 번 재시도한다" 같은 종료 규칙이 루프의 정의 안에 있다. 반면 훅에는 그런 장치가 없다. 한 번 실행하고 끝나는 게 전제이기 때문이다. 훅이 루프처럼 반복되기 시작했는데 멈추는 규칙이 없다면, 외부 제한(비용 한도, 세션 한도, 시스템 리소스 고갈)이 먼저 걸릴 때까지 계속 돈다.
한 가지 더 짚어둘 점이 있다. 이 상황은 설정 파일 한 줄의 변경으로 만들어진다. 훅 타입이 에이전트 내부 실행에서 외부 CLI 프로세스 실행으로 바뀌는 순간, 위험도는 완전히 다른 수준으로 올라간다. 코드 리뷰나 배포 파이프라인에서는 이 변화가 눈에 잘 띄지 않는다.
재귀가 이미 시작됐다는 조기 신호
재귀 실행은 대개 즉시 눈에 보이지 않는다. 문제가 드러날 때쯤이면 피해가 상당히 진행된 상태다. 그래서 패턴을 먼저 알아두는 것이 중요하다.
비용과 작업 크기가 맞지 않는다. 작은 작업을 하나 시켰는데 토큰 사용량이나 API 비용이 그와 비례하지 않게 높다면, 그 작업 자체가 아니라 작업이 끝난 뒤에 뭔가 더 돌고 있다고 의심해야 한다.
캐시 읽기 비율이 비정상적으로 높다. 자동 생성된 세션들이 같은 컨텍스트, 같은 프롬프트, 같은 에이전트 목록을 반복해서 읽는다. 실제 토큰 소비 중 캐시 읽기가 압도적으로 많다면, 새로 추론하는 작업보다 같은 환경을 반복 부팅하는 상황일 가능성이 크다.
세션 파일 수가 갑자기 폭증한다. 에이전트 런타임은 세션마다 로그를 남긴다. 짧은 시간 안에 세션 파일이 수백, 수천 개 생겼다면 사용자가 직접 시작한 세션이 아니라 자동으로 생성된 세션이 쌓이는 것이다.
시스템 리소스에 2차 영향이 생긴다. 백그라운드에서 프로세스가 계속 생성되면 CPU 사용률이 올라가고, 짧은 시간에 작은 파일이 수천 개 만들어지면 파일 시스템 레이어가 부하를 받는다. 로컬 환경이라면 팬 소음이나 비정상적인 발열이 신호가 될 수 있다.
rate limit 오류가 반복 로그에 섞인다. 사용자가 별다른 작업을 하지 않는데 한도 초과 오류가 로그에 남는다면, 백그라운드 세션들이 API를 계속 두드리고 있다는 뜻이다.
이 신호들이 동시에 여러 개 나타난다면, 가장 최근에 바꾼 설정 파일과 훅 구성을 먼저 열어봐야 한다. 모델 버전이나 설치 방식보다 거기를 먼저 보는 것이 순서상 맞다.
설계 단계에서 경계를 그어야 하는 이유
재귀 실행 문제를 모니터링으로만 잡으려 하면 항상 늦다. 이미 비용이 나간 뒤에 알아채는 구조이기 때문이다. 애초에 재귀가 발생할 수 없는 설계를 만드는 쪽이 훨씬 효과적이다.
종료 계열 이벤트 훅에서는 새 에이전트 세션을 만들지 않는다. SessionEnd, TaskComplete처럼 실행이 끝나는 시점에 붙는 훅이 새 세션을 생성하면, 그 세션의 종료가 같은 훅을 다시 발화시킨다. 이 구조 자체를 피하는 것이 가장 확실한 방어다.
훅 안에서는 LLM을 호출하지 않는다. 훅은 로그 기록, 타임스탬프 저장, 정적 파일 검사처럼 결과가 확정적이고 실행 시간이 짧은 로컬 작업에 써야 한다. LLM 호출은 응답 시간, 비용, 실패, 재시도, 컨텍스트 로딩을 모두 끌고 온다. 이것이 매 이벤트마다 자동으로 붙으면 통제하기 어렵다.
백그라운드 실행으로 프로세스를 분리하지 않는다. nohup, &, disown은 프로세스를 부모 세션에서 완전히 끊어 독립 실행되게 하는 셸 관용구다. 일반 스크립트에서는 유용하지만, 에이전트 런타임 안에서 새 세션을 이렇게 띄우면 무슨 일이 벌어지는지 추적하기 어렵고, 문제가 생겼을 때 개입할 방법이 없다.
LLM이 꼭 필요한 후처리는 명시적 커맨드로 분리한다. "세션이 끝나면 자동으로 정리해줘"가 아니라 "정리가 필요할 때 내가 이 명령을 직접 호출한다"로 바꾼다. 자동 실행과 명시적 실행 사이의 선을 흐릿하게 두면, 어떤 실행이 사람이 의도한 것인지 나중에 판단하기 어렵다.
실행 상한을 코드 안에 박아둔다. 자동 실행 구조라면 최대 실행 횟수, 쿨다운 기간, 동시 실행 프로세스 수 제한 중 하나라도 반드시 넣는다. 이 장치가 없는 자동화는 재귀 외에도 예상치 못한 반복 호출에 무방비다.
지금 운영 중인 훅 설정 점검하기
에이전트 자동화를 이미 운영 중이라면, 설정 파일을 코드만큼 신중하게 다루고 있는지 확인할 필요가 있다. 훅 설정은 코드 리뷰 대상에 넣는다. 설정 파일의 변경 이력을 커밋 단위로 추적하지 않으면 언제 어떤 내용이 바뀌었는지 소급하기 어렵고, 재귀 구조가 언제 심어졌는지 파악하는 데도 시간이 걸린다.
훅 설정에 종료 계열 이벤트가 있는지, 그 안에서 에이전트 CLI나 API를 다시 호출하는지, 백그라운드 실행 키워드가 섞여 있는지를 한눈에 확인하려면 아래 명령을 쓸 수 있다.
rg 'hooks|SessionEnd|claude -p|nohup|disown' .claude ~/.claude
결과가 반환된다면, 각 줄이 어떤 맥락에서 나오는지 직접 들여다봐야 한다. 명령 하나로 진단이 끝나는 건 아니지만, 점검을 시작할 위치를 잡는 데는 충분하다.
비용 한도와 실행 경계는 운영 정책이 아니라 설계 요소다
에이전트 자동화를 처음 설계할 때 비용 한도나 실행 상한을 "나중에 운영하면서 조정할 것"으로 미루는 경우가 많다. 하지만 재귀 실행은 발생 속도가 빠르고, 발견하는 데 시간이 걸린다. 그 사이에 발생한 비용은 되돌릴 수 없다.
세션 안에서 반복되는 루프는 타임아웃이나 반복 횟수 제한으로 어느 정도 막을 수 있다. 그런데 한 세션의 종료가 다음 세션을 만드는 구조, 즉 세션 경계를 넘어서는 재귀는 세션 내부 안전장치가 아무 역할을 하지 못한다. 이 경우 방어는 훅 설계 자체에서 나와야 한다. 새 세션을 만들 수 있는 코드가 종료 이벤트에 붙지 않도록 구조를 만드는 것이 유일한 사전 방어다.
API 제공사의 월간 지출 한도는 최후의 보루로는 유용하지만, 재귀 실행에 대한 실시간 방어는 아니다. 한도에 걸리기 전까지 비용은 이미 발생하고, 한도 초과로 세션이 끊겨도 재귀 구조가 남아 있으면 한도가 초기화되는 시점에 다시 시작될 수 있다.
훅은 얼마나 많은 일을 자동으로 처리할 수 있는지보다, 어떤 일을 하면 안 되는지를 먼저 정한다. 지금 운영 중인 에이전트 훅에 종료 이벤트 트리거가 있다면, 그 안에 새 세션이나 외부 에이전트 프로세스를 만드는 코드가 있는지 오늘 확인해볼 가치가 있다. 멈추는 규칙 없이 반복할 수 있는 구조가 하나라도 있다면, 언제 발동할지만 모를 뿐 조건은 이미 갖춰진 상태다.
