-->

야간에 사람 없이 돌아가는 에이전트 파이프라인을 운영하거나 설계하는 엔지니어라면 이 글이 도움이 됩니다. 결론부터 말하면, 루프가 “완료했다”고 스스로 보고하는 작업 수와 실제로 끝까지 검증된 작업 수 사이의 간극을 줄이는 데는 검증 게이트, 체크포인트 롤백, 정체 감지 세 메커니즘 중 하나가 압도적으로 크게 기여하고, 나머지는 그 뒤를 받쳐주는 역할에 가깝습니다. 다만 압도적인 메커니즘을 혼자 켜두면 오히려 다른 방식으로 작업이 실패하는 함정이 있다는 점이 이 연구의 진짜 요점입니다.

완료율 격차라는 문제

무인 에이전트 루프, 즉 밤새 스케줄대로 돌거나 사람이 매 단계를 지켜보지 않는 자동화는 시도한 작업 수와 실제로 끝낸 작업 수가 일치할 때만 신뢰할 수 있습니다. 현실에서는 이 둘 사이에 큰 틈이 생깁니다. 에이전트가 아직 끝나지 않은 일을 끝났다고 스스로 선언해버리거나, 이전 진행 상황을 조용히 되돌려버리거나, 같은 행동만 반복하며 전혀 앞으로 나아가지 못하는 경우가 그렇습니다. 이 논문은 시도한 작업 수와 검증된 성공 작업 수의 차이를 완료율 격차라고 부르고, 어떤 하네스 메커니즘이 이 격차를 실제로 얼마나 좁히는지를 핵심 질문으로 삼습니다.

루프 엔지니어링 분야는 이미 표준적인 답을 몇 가지 내놓았습니다. 자기보고를 그대로 믿지 않고 독립적인 검증을 거쳐야만 완료를 인정하는 검증 게이트, 조용한 퇴행을 감지해 직전 정상 상태로 되돌리는 체크포인트 롤백, 진전 없이 같은 자리를 맴도는 상태를 감지해 전략을 바꾸는 정체 에스컬레이션이 그 세 가지입니다. 문제는 이 메커니즘들의 가치가 대개 설계 의도에서 나온 주장으로만 제시되고, “루프를 닫아라”는 슬로건 수준을 벗어나 실제로 측정된 적은 드물다는 점입니다. 세 메커니즘을 한꺼번에 넣고 루프가 좋아졌다고 해서, 셋 다 기여했는지 하나가 결과를 견인했는지 둘이 상호작용했는지는 결과만 봐서는 알 수 없습니다. 이 연구는 ThakiCloud가 실제로 운영하는 하네스, 즉 verify_gate.py의 검증 게이트, hermes-checkpoint-rollback의 롤백, loop-trigger-gate의 정체 정의를 그대로 가져와 이 질문에 통제 실험으로 답합니다.

측정 방법: 실측이 아닌 통제된 시뮬레이션

실제 LLM 기반 프로덕션 루프(pge-loop, Goal Mode의 daemon_tick)를 여덟 가지 메커니즘 조합으로 수천 번씩 재실행해 통계적으로 안정된 추정치를 얻는 것은 비용상 불가능합니다. 그래서 이 연구는 실제 프로덕션 코드의 판단 로직을 그대로 부호화한 CPU 전용 이산사건 시뮬레이션을 만들어 실제로 실행했습니다. 시뮬레이션이 주입하는 세 가지 결함은 각 메커니즘이 원래 막으려는 바로 그 실패 양상입니다. 조용한 퇴행, 성급하게 환각된 완료 자기보고, 진전 없는 정체가 그것입니다.

여기서 정직하게 짚어야 할 지점이 있습니다. 이 실험은 진짜 LLM이 도는 프로덕션 루프를 다시 실행한 것이 아니라, 그 하네스의 코드 의미론을 충실히 옮긴 합성 결함 주입 시뮬레이션입니다. 실제 LLM의 확률적 행동과 실제 작업의 의미론을 포기하는 대신, 여덟 개 구성을 CRN(공통 난수) 기법으로 분산을 줄여 통계적으로 안정된 추정치를 얻는 쪽을 택한 것입니다. 시드 30개, 시드마다 작업 300개씩을 검증(V), 롤백(R), 정체 에스컬레이션(S) 세 스위치의 온오프 여덟 조합에 모두 동일한 난수로 흘려보내, 조합 간 결과 차이가 순전히 메커니즘 로직에서 나오도록 설계했습니다. 각 작업은 5에서 20 사이의 진짜 난이도(진짜 완료에 필요한 진행 증가분 수)를 부여받고, 매 반복마다 55%의 진행, 15%의 퇴행, 30%의 정체 확률로 결과가 갈립니다. 정체가 세 번 연속되면 에스컬레이션이 켜져 있을 때 진행 확률이 85%까지 오르는 부스트 상태로 전환됩니다. 검증 게이트가 꺼져 있을 때는 매 반복마다 5%의 확률로 완료를 성급하게 자기보고하는 환각이 섞여 들어가고, 게이트가 켜져 있으면 이 성급한 주장은 결정론적으로 거부됩니다.

검증 게이트의 압도적 효과와 그 함정

여덟 개 조합 전체를 놓고 보면, 세 메커니즘을 모두 끈 기준선의 실제 성공률은 26.22퍼센트에 그칩니다. 세 메커니즘을 모두 켰을 때는 97.59퍼센트까지 올라가, 완료율 격차 71.37퍼센트포인트가 닫힙니다.

True-Success Rate by Mechanism Configuration 여덟 개 메커니즘 조합별 실제 성공률입니다. 세 메커니즘을 모두 켰을 때만 90퍼센트대에 도달하고, 검증 게이트가 꺼진 조합은 아무리 롤백과 에스컬레이션을 더해도 30퍼센트대를 넘지 못합니다. ThakiCloud AI Platform Demo 클러스터의 CPU 전용 잡으로 30개 시드, 시드당 300개 작업을 CRN 시뮬레이션으로 측정한 결과입니다.

두 지점 근사 섀플리 값으로 각 메커니즘의 기여를 나눠보면 검증 게이트가 55.3퍼센트포인트, 체크포인트 롤백이 15.2퍼센트포인트, 정체 에스컬레이션이 0.64퍼센트포인트를 차지합니다. 검증 게이트는 켜져 있는 모든 조합에서 거짓 성공률을 정확히 0으로 만드는 유일한 메커니즘이기도 합니다. 성급한 완료 주장을 구조적으로 거부하기 때문에 환각된 “완료” 상태가 아예 발생할 수 없는 것입니다.

그런데 이 압도적인 효과에는 대가가 따릅니다. 검증 게이트만 켜고 롤백과 에스컬레이션은 끈 조합에서는 평균 반복 횟수가 13.4회에서 23.7회로 거의 두 배가 되고, 반복 한도를 소진해 아무 결론도 내지 못하는 비율이 3.2퍼센트에서 24.1퍼센트로 치솟습니다. 예전 같으면 (틀리게) 완료를 선언하고 끝났을 작업들이 이제는 계속 반복을 강요받는데, 회복 수단이 없으니 그중 4분의 1가량이 그냥 반복 한도에 걸려 미완으로 남는 것입니다. 검증만 추가하고 멈춘 팀은 거짓 성공은 사라졌다고 안심하겠지만, 실은 실패의 모양만 바뀐 셈입니다.

체크포인트 롤백의 시너지와 의외로 약한 정체 감지

체크포인트 롤백을 단독으로 켰을 때의 효과는 10.1퍼센트포인트에 그치지만, 전체 구성에서 롤백만 빼봤을 때 떨어지는 폭은 20.3퍼센트포인트로 거의 두 배입니다. 두 메커니즘이 서로 독립적이지 않고 강하게 맞물려 있다는 뜻입니다. 이 시너지는 반복 한도 소진율에서 가장 선명하게 드러납니다. 검증 게이트가 거짓 완료라는 탈출구를 막아버리면 작업들이 반복 한도 앞에 쌓이는데(게이트만 켰을 때 24.1퍼센트 소진), 체크포인트 롤백이 바로 그 쌓인 작업들을 되찾아옵니다. 검증과 롤백을 함께 켜면 소진율이 3.0퍼센트로 떨어집니다. 롤백은 게이트가 혼자 만들어낸 반복 소진 비용을 완료된 작업으로 되돌리는 셈이고, 그 대가는 작업당 약 3.4회의 되돌려진 반복뿐입니다.

Shapley-Style Marginal Contribution per Mechanism 세 메커니즘이 닫은 71.4퍼센트포인트의 격차 중 검증 게이트가 55.3, 체크포인트 롤백이 15.2, 정체 에스컬레이션이 0.6퍼센트포인트를 차지합니다. 롤백의 단독 효과(10.1)보다 다른 메커니즘이 있을 때 빠지면 생기는 손실(20.3)이 두 배 큰 것이 초가산적 시너지를 보여줍니다. 실측이 아니라 두 지점 섀플리 근사에 기반한 해석적 모형입니다.

Mean Wasted Iterations per Task by Configuration 검증 게이트가 없을 때 롤백은 작업당 약 1.9회의 반복을 되돌리지만, 게이트가 있을 때는 약 3.3에서 3.4회를 되돌립니다. 게이트가 만들어낸 반복 소진 비용을 롤백이 그만큼 더 많이 회수하고 있다는 뜻입니다. 게이트가 켜진 구성은 실측값이고, 롤백이 꺼진 구성 일부는 해석적 모형값입니다.

반면 정체 에스컬레이션의 기여는 0.64퍼센트포인트에 그쳤습니다. 이는 이 논문에서 기존 통념과 가장 상반되는 결과입니다. 정체와 무한루프 감지는 루프 엔지니어링 커뮤니티가 오랫동안 무겁게 다뤄온 주제인데, 이번 실험에서 만든 결함 조합에서는 지배적인 실패 원인이 환각된 완료와 조용한 퇴행이지 문자 그대로의 무한 정체가 아니었기 때문에 에스컬레이션이 거의 효과를 내지 못했습니다. 이것을 정체 감지가 쓸모없다는 보편적 주장으로 읽으면 안 됩니다. 만성적인 정체 비율이 훨씬 높은 다른 결함 분포에서는 에스컬레이션이 훨씬 중요해질 수 있고, 이 실험 방법론이 바로 그런 질문에 답하도록 설계되어 있습니다. 즉 이번 결과는 이 특정 결함 조합에서의 범위 한정적 결론입니다.

회사, 사회, 과학에 남기는 의미

ThakiCloud 입장에서 이 결과는 자사의 쿠버네티스·에이전트 플랫폼에서 하네스 투자를 어디부터 강화해야 하는지에 대한 측정 기반 순위표입니다. 신념이 아니라 실측으로 검증 게이트를 먼저, 체크포인트 롤백을 다음으로 강화하고, 정체 에스컬레이션은 결함 분포가 실제로 정체 중심일 때만 우선순위에 올리라는 구체적 지침을 얻은 것입니다. 이는 jarvis와 pge-loop 하네스를 다음에 어디부터 손볼지 결정하는 데 바로 쓰입니다.

더 넓게 보면, 조용히 정체되거나 환각으로 표류하는 무인 루프를 실제로 멈추게 하는 메커니즘이 무엇인지 가려낼수록 낭비되는 GPU·컴퓨트 자원과 사람의 감시 부담이 줄어들어, 무인 자동화를 대규모로 배치하는 일이 더 안전해집니다. 그리고 과학적으로는 “검증으로 루프를 닫아라”는 식의 포지션 페이퍼 주장 대신, 각 메커니즘의 개별 기여와 상호작용 기여를 통제된 애블레이션으로 분리해 반증 가능한 근거로 대체했다는 점이 이 연구의 방법론적 기여입니다.

한계

가장 중요한 한계는 이 실험이 실제 LLM이 도는 프로덕션 루프를 라이브로 재실행한 것이 아니라, 그 코드 의미론에 충실한 합성 결함 주입 시뮬레이션이라는 점입니다. 메커니즘의 판단 로직은 실제 프로덕션 코드에 충실하지만, 결과는 언어 모델이 실제 작업을 수행한 결과가 아니라 파라미터화된 확률분포에서 뽑힌 값입니다.

또한 진행·퇴행·정체 확률과 환각 확률은 실측 트레이스에 맞춰 적합된 값이 아니라 손으로 정한 값입니다. 정체 에스컬레이션이 약하다는 결론이 바로 이 결함 분포에 종속적이라고 명시한 만큼, 실제 실행 로그로부터 확률을 적합시키면 정량적 귀속, 특히 정체 에스컬레이션의 거의 0에 가까운 기여도가 바뀔 수 있습니다. 실제 pge-loop·daemon_tick 실행 로그로부터 이 확률들을 적합시키는 것이 향후 연구의 핵심 방향입니다.

세 메커니즘은 ThakiCloud 자체 하네스(verify_gate.py, hermes-checkpoint-rollback, loop-trigger-gate)의 판단 로직을 그대로 옮긴 것이라, 결정론적 게이트가 아니라 확률적 게이트를 쓰거나 되돌리기가 아니라 분기 기반으로 롤백을 구현하는 다른 하네스에는 방법론은 그대로 옮겨가도 구체적인 수치는 재측정이 필요합니다. 마지막으로 이 연구는 완료 여부, 거짓 성공, 소진, 반복 횟수, 낭비된 반복만을 측정 대상으로 삼았고, 실제 소요 시간이나 토큰 비용, 이진 완료를 넘어선 작업 품질의 단계적 차이는 다루지 않았습니다.

논문 상세 페이지는 Hugging Face 데이터셋에서 확인할 수 있습니다.

참고