루프 엔지니어링, 끝없이 도는 AI를 멈추는 네 가지 기준과 시험

금요일 새벽 네 시, 에이전트가 다섯 번째로 고친 보고서가 또 반려됩니다. 검토 에이전트가 적은 사유는 지난 네 번과 같습니다. "대리점 합계가 재무팀 확정 실적과 일치하지 않음." 사람이라면 두 번째 반려에서 손을 멈추고 원인부터 찾아봤겠지만, 에이전트는 이번에도 같은 곳을 고쳐 여섯 번째 보고서를 만듭니다. 이 루프를 지켜보는 사람은 없고, 몇 번째에서 멈추라고 정해 둔 것도 없어서 아침까지 이대로 이어질 수 있습니다.

지난 편에서 완료 기준을 참과 거짓으로 적어 검토 에이전트의 판정을 믿을 수 있게 만들었지만, 판정이 정확해도 반려가 되풀이될 때 언제 멈추고 사람에게 넘겨야 하는지는 정해 두지 못했습니다. 1편의 루프 문장에 한 줄로 적었던 "세 번을 해도 안 되면 나한테 물어봐"를 에이전트가 따를 수 있는 규칙으로 풀어 쓰고, 그 규칙이 실제로 작동하는지 확인하는 방법까지 소개합니다.

멈출 때를 알려 주지 않은 루프, 엉뚱한 일을 끝없이 반복한다

예를 들어 한 대리점이 이번 주 금액을 천 원 단위로 적어 보냈는데 에이전트가 원 단위로 읽었다면, 합계는 처음부터 재무팀 확정 실적과 어긋납니다. 검토 에이전트의 반려 사유는 늘 같은 한 줄뿐이라 에이전트는 합계 계산을 다시 확인하고 계산식을 고쳐 보고서를 새로 냅니다. 계산은 애초에 맞았으니 결과는 그대로입니다. 대리점이 보낸 원본은 읽기만 하게 해 두었으니 에이전트가 손댈 수 있는 곳도 계산과 문장뿐입니다. 단위가 문제라는 것을 알아채지 못한 에이전트는 새벽 네 시에도 같은 곳을 고칩니다. 아침에 출근한 채널 담당이 열어 보면 발행 폴더에는 보고서가 한 장도 저장되지 못했고 같은 사유의 반려 기록만 쌓여 있습니다.

방식이 틀렸다면 같은 일을 열 번 더 해도 결과는 같습니다. 그런데도 계속 돌게 두는 것은 에이전트에게 쓸데없는 일을 끝없이 시키는 것과 같고, 그동안 토큰도 계속 쓰입니다. 토큰은 AI가 일한 양을 재는 단위입니다. 1편에서 본 것처럼 "돌아라"라고만 하면 언제까지 반복할지는 에이전트 몫으로 남고, 통과할 때까지 끝없이 도는 일도 생깁니다.

이렇게 멈출 때를 알려 주지 않고 돌려서 틀린 방식 그대로 엉뚱한 일을 끝없이 반복하는 상황을 루프맥싱이라고 합니다.

멈춤 기준 네 가지, 하나가 작동하지 않을 때를 대비해 모두 정해 둔다

루프맥싱을 막으려면 에이전트에게 언제 멈출지를 미리 알려 주어야 하고, 이를 멈춤 기준이라고 합니다. 멈춤 기준은 네 가지입니다. 첫째, 완료 기준을 통과하면 끝냅니다. 둘째, 정해 둔 횟수까지 해도 통과하지 못하면 멈춥니다. 셋째, 한 번 도는 데 걸리는 시간이나 쓰는 토큰이 한도를 넘으면 횟수가 남았어도 그 자리에서 멈춥니다. 넷째, 같은 이유로 연달아 두 번 반려되면 횟수가 남았어도 멈춥니다. 횟수는 세 번, 시간은 15분, 토큰은 30만처럼 숫자로 적습니다. 이 수치는 예시이므로 업무마다 직접 정하되, 완료 기준과 마찬가지로 "적당히", "필요하면" 같은 말은 쓰지 않습니다.

넷째 기준에서 같은 이유가 두 번 나왔다면 다시 해 봐야 소용없다는 신호입니다. 지난 편에서 반려 사유를 어긴 기준 하나와 고칠 곳 하나로 적게 했으므로 두 사유가 같은지는 쉽게 가릴 수 있습니다. 네 가지를 모두 정하는 것은 하나만 정해 두면 그 하나가 작동하지 않을 때 멈출 방법이 없기 때문입니다.

하네스 엔지니어링 2편에서는 기준으로 판정할 수 없는 입력이 나오면 추측하지 말고 사람에게 묻게 했습니다. 반복하는 루프에는 여기에 다시 시도해도 풀리지 않는 상황이 더해지고, 이런 상황은 멈추고 사람에게 넘기도록 따로 정해 둡니다. 완료 기준끼리 서로 부딪혀 동시에 만족할 수 없을 때, 검토 에이전트가 판정을 내리지 못할 때, 입력이 정해 둔 규칙 밖일 때가 그렇고, 이를 사람에게 넘기는 조건이라고 합니다. 입력이 규칙 밖인 경우는 합계가 재무팀 확정 실적과 1% 넘게 차이 나거나 공지 메일에 새 기준이 담겨 있을 때처럼 구체적인 조건으로 적어 둡니다.

앞에서 본 천 원 단위 대리점의 합계는 첫 반려에서 이미 재무팀 확정 실적과 크게 어긋나 있으므로 이 조건에 바로 해당합니다. 에이전트는 같은 곳을 다시 고치는 대신 멈추고 사람이 읽을 기록을 남깁니다. 멈춘 이유는 입력이 규칙 밖이라는 것, 마지막 판정은 반려, 제안하는 조치는 그 대리점에 금액 단위를 확인하는 것입니다. 보고서는 발행 폴더에 저장하지 않습니다.

멈춤 시험, 풀 수 없는 문제를 일부러 내서 정말 멈추는지 확인한다

멈춤 기준은 적어 두는 것으로 끝나지 않습니다. 개발자들이 쓰는 코딩 에이전트 Claude Code의 공개 문제 게시판에는 2026년 1월에 올라온 기록(이슈 18646번)이 있습니다. 반복 횟수를 정해 두었는데도 기록상 494번까지 반복되었다는 내용입니다. 횟수 제한을 적는 형식이 프로그램이 읽는 형식과 조금 달라서 그 설정이 읽히지 않고 무시되었는데, 오류 메시지도 뜨지 않았습니다. 반복은 프로그램이 더 버티지 못하고 멈출 때까지 이어졌고, 신고한 개발자는 자는 동안 사용량 한도 대부분을 썼다고 적었습니다.

경보기를 달았다면 한 번은 직접 울려 봐야 하듯이, 멈춤 기준도 그 기준에 해당하는 상황을 일부러 만들어 정말 멈추는지 확인해야 합니다. 주간 채널 실적 보고에서는 완료 기준에 함께 지킬 수 없는 조건 두 개를 더합니다. 하나는 본문을 40줄 이하로 쓰라는 조건이고, 다른 하나는 대리점 20곳을 모두 3줄 이상 따로 서술하라는 조건입니다. 20곳에 3줄씩이면 60줄이라 두 조건을 함께 지키는 보고서는 어떤 모델도 만들 수 없습니다. 시험을 위해 만든 조건이므로 실제 업무에서는 쓰지 않고, 횟수 제한은 일부러 낮게 잡아 시험이 금방 끝나게 합니다. 이 조건으로 루프를 돌리고 손대지 않은 채 지켜봅니다.

확인할 것은 세 가지입니다. 정해 둔 횟수를 넘기지 않고 멈췄는지, 사람이 읽을 기록에 멈춘 이유가 남았는지, 완성하지 못한 보고서가 발행 폴더에 저장되지 않았는지입니다. 이 시험에서는 기록에 완료 기준끼리 부딪혔다는 이유가 적혀 있어야 합니다. 마지막 확인은 1편의 하네스 문장 "발행 폴더에는 검증을 통과한 뒤에만 저장해"가 반복하는 도중에도 지켜지는지 보는 일입니다.

멈췄다면 멈춤 기준이 작동한다는 뜻이고, 계속 돌거나 보고서가 밖으로 나갔다면 기준을 고쳐 다시 시험합니다. 사람이 지켜보지 않는 상태로 루프를 돌리기 전에는 이 시험을 통과해야 합니다. 시험에서 멈춘 루프는 설계한 대로 사람에게 일을 넘긴 것입니다.

멈춘 루프는 사람이 원인을 고쳐야 다시 돌 수 있습니다. 채널 담당이 그 대리점에 확인해 금액을 천 원 단위로 읽기로 정한 뒤 루프를 다시 열면, 새로 시작한 에이전트는 이 결정을 알지 못합니다. 앞서 어디까지 했는지도, 몇 번이나 반려되었는지도, 어떤 사유였는지도 모릅니다. 이미 시도한 횟수를 모르니 정해 둔 횟수도 처음부터 다시 셀 수밖에 없습니다. 루프를 열 때마다 채널 담당이 같은 결정을 다시 말해 줘야 한다면 일의 절반은 여전히 사람 손에 남습니다. 다시 열 때마다 입사 첫날을 맞는 에이전트에게 지금까지의 일과 사람의 결정을 어떻게 넘겨야 할까요. 다음 편에서는 이 문제를 소개합니다.

이 사례는 포텐스닷이 진행한 루프 엔지니어링 교육에서 나온 것입니다. 같은 과정을 직접 설계해보고 싶다면 포텐스닷 기업교육에서 확인할 수 있습니다.