루프 감지는 정체 감지가 아닙니다: 반복하지 않으면서 제자리도는 에이전트 잡기

이 글은 BEACON(저장대학교, arXiv:2605.06078)을 자세히 읽고 시작한 장기 작업 에이전트 설계 노트 시리즈의 첫 글입니다.

에이전트가 긴 작업을 견뎌 내려면 두 가지가 제대로 되어야 한다고 생각합니다.

• 목표를 향해 계속 진전해야 합니다. 이는 컨텍스트 압축(무엇을 잊어도 안전한가), 마일스톤 설계(단계가 정말 끝났는지 어떻게 아는가), 정체 방지(막히면 이를 감지할 무언가가 필요하다)로 나뉩니다.
• 스스로 돌아보고 개선할 수 있어야 합니다.

이 글은 정체 방지를 다룹니다. 저희에게 가장 큰 비용을 치르게 한 문제이기 때문입니다.

증상

사용자 제보가 있었고 내부에서도 확인했습니다. 매우 긴 작업 일부가 중간부터 더 이상 전진하지 않았습니다.

로그를 보면 에이전트는 바쁩니다. 파일을 읽고, 검색하고, 명령을 실행하며 한시도 쉬지 않습니다. 하지만 30분 뒤에도 아무것도 진전되지 않았습니다.

처음에는 컨텍스트 손실로 설명했습니다. 압축으로 이미 시도한 경로의 기록이 사라져 에이전트가 다시 시도한다는 것이었습니다. 코드와 로그를 함께 읽어 보니 이는 이야기의 절반에 불과했습니다.

이미 3단계 보호 장치가 있었습니다

세 번째 단계의 주석은 그대로 옮기면 이렇습니다. "컨텍스트 손실 후 헛돌고 있을 수 있음"을 나타내는 복합 신호. 누군가는 이미 이를 예상했습니다. 따라서 문제는 아무것도 만들지 않았다는 것이 아니라, 만든 장치로 잡을 수 없었다는 것이었습니다.

사각지대: 셋 모두 입력 측 감지기입니다

각 단계가 기준으로 삼는 시그니처는 tool name + canonicalized args입니다. 이것은 정확히 한 가지 질문에 답합니다. 같은 일을 두 번 하고 있는가?

하지만 막힌 유능한 모델은 호출을 반복하지 않습니다. 이렇게 합니다.

파일 A 읽기 → grep X → 다른 줄 범위로 A 다시 읽기
  → 조금 다른 명령 실행 → 파일 B 읽기 → 다시 grep 검색 …

모든 호출의 시그니처가 다릅니다. 세 단계 모두 아무 반응이 없습니다. 그리고 이 전체 구간에서 검증 가능한 상태 변화는 0입니다. 실제로 다시 쓴 파일도 없고, 새로운 결과를 낸 명령도 없고, 되돌릴 수 없는 일이 전혀 일어나지 않습니다.

루프 감지는 정체 감지가 아닙니다. 전자는 입력을 봅니다. 후자는 출력을 봐야 합니다.

논문은 바로 그 출력 측 정의를 제공합니다

BEACON의 구간 내 보상:

r_t = R_ms · γ^(t_k − t)    if the segment ends in a milestone
    = 0                     otherwise

마일스톤으로 끝나지 않는 구간은 그 안에 동작이 몇 개 있든 정확히 0을 받습니다. 동작 횟수는 공식에 아예 들어가지 않습니다. 저희가 본 것 중 바쁨 ≠ 진전을 가장 깔끔하게 수식화한 것입니다.

베이스라인 계층은 더 엄격합니다. 베이스라인은 그룹 평균 단계당 수익이므로, 그룹 평균이 5단계인데 8단계가 걸린 구간은 어드밴티지 전체가 음수 쪽으로 기울며 초과분에 비례해 페널티가 커집니다. 헛돌기는 단지 보상이 없는 것이 아니라 적극적으로, 비례해서 불이익을 받습니다.

논문의 그림 8은 마지막 두 동작이 동일한 −2.20을 받는 실패 궤적을 보여 줍니다. 마지막 마일스톤 이후 다음 마일스톤에 끝내 도달하지 못한 꼬리 구간이 바로 헛돌기의 수학적 형태입니다. 흔한 현상이기도 합니다. 하위 목표를 하나 이상 완료하고도 전체 작업에 실패하는 궤적은 표본의 39–47%로 꾸준히 나타납니다.

절제 실험 하나가 단계 수 기반 트리거를 배제합니다

임의의 단계 수로 나누는 것은 효과가 거의 없습니다. 실제 구조를 따라 나누는 것은 큰 효과가 있습니다.

이제 저희의 세 번째 단계 기준인 도구 루프 예산 75% 소진을 다시 보세요. 임의의 단계 수에 따른 트리거입니다. 무엇을 달성했는지가 아니라 얼마나 소비했는지 묻습니다. 올바른 형태는 다음과 같습니다.

✗  if steps > N                              → intervene
✓  if steps > N AND zero verified milestones → intervene

두 번째는 실제로 진전하는 긴 작업에서는 잘못 작동하지 않습니다. 그런 작업은 진행 중에 마일스톤에 도달하기 때문입니다. 첫 번째는 잘못 작동합니다.

증폭 피드백 루프도 있습니다

상수를 나란히 놓아 보세요. 압축은 컨텍스트 창의 82%에서 시작됩니다. 헛돌기 수렴은 압축 두 번과 루프 예산 75% 소진이 있어야 작동합니다.

헛돌기 → 맥락이 가득 참 → 압축 실행 → 지속 상태가 요약 과정에서 사라짐
     → 잃어버린 내용을 다시 도출 → 더 오래 헛돌기

헛돌기 감지기는 압축이 반복되었다는 관찰로 헛돌기를 추론하지만, 압축은 바로 그 기억 상실을 일으키는 단계입니다. 감지기는 후속 증상을 감지하며 루프가 두 번 돌 때까지 기다려야 합니다.

더 나쁜 것은 개입 방식입니다. 모델이 지속 상태를 다시 기준으로 삼도록 유도합니다. 압축으로 사라진 것이 바로 그 지속 상태라면 다시 기준으로 삼을 것이 남아 있지 않습니다. 상태 계층의 문제에 프롬프트 계층의 임시방편을 적용하는 셈입니다.

추가하려는 것: 출력 측 정체 감지

두 카운터로 구성한 네 번째 단계입니다. 둘 다 호스트가 이미 기록하는 도구 관찰값에서 기계적으로 도출하며, 어느 쪽도 모델의 판단이 필요하지 않습니다.

마지막으로 검증된 마일스톤 이후의 단계 수. 가장 단순한 진척도 지표이며, 단독이 아니라 위의 복합 기준 안에서 사용합니다.

중복을 제거한 새로운 상태 변화. 둘 중 더 유용한 지표입니다.

• 콘텐츠 해시가 이전 읽기와 같은 파일 읽기는 새로운 정보가 아닙니다. 같은 파일을 다른 줄 범위에서 다시 읽어도 해시는 바뀌지 않습니다.
• 이름, 종료 코드, 출력 해시가 모두 이전 실행과 같은 명령은 새로운 정보가 아닙니다.
• 쓰기 후 해시가 쓰기 전 해시와 같다면 실제로 아무것도 바뀌지 않았다는 뜻입니다.

이 카운터는 시그니처 비교가 놓치는 경우를 정확히 겨냥합니다. 모든 동작은 다르지만 정보 증가는 0인 경우입니다. 기준은 기계적이며 의미 이해가 필요하지 않습니다.

그다음에는 한 번의 유도가 아니라 지속적인 압박이 필요합니다.

모델이 볼 수 있도록 맥락에 카운터 표시
  → 계획 수정을 강제 (이 경로로는 진전할 수 없음을 인정)
    → 사용자에게 질문
      → 중단하되 이미 달성한 마일스톤은 보존

마지막 단계가 중요합니다. 실행을 멈추려면 얻은 성과를 보존한 채 멈춰야 합니다. 논문에서 버려지는 것으로 측정한 바로 그 39–47%의 부분적 진전입니다.

논문이 제공하지 않는 것

BEACON은 학습 방법입니다. 학습된 정책이 덜 헤매도록 그래디언트를 형성하지만, 자체적인 런타임 감지나 개입 메커니즘은 없습니다. 진전의 정의를 제공할 뿐 제어기를 제공하지는 않습니다. 임계값, 단계별 대응, 중단 조건은 저희가 설계해야 합니다.

단계당 베이스라인에도 기준이 될 그룹 평균 구간 길이가 필요합니다. 실제 서비스에서는 보통 특정 사용자 작업을 정확히 한 번만 실행하므로 그룹이 없습니다. 가능한 최선의 대체재는 유사한 작업의 과거 통계이지만 잡음이 훨씬 크고, 논문이 제공하는 분산 분리 보장도 전혀 없습니다.

첫 조치는 수정이 아니라 측정입니다

판단 로직을 바꾸기 전에 계측을 추가해 지금은 답할 수 없는 질문에 답하려고 합니다. 실제 서비스에서 일어나는 정체 중 기억 상실형은 얼마나 되고, 그래디언트 부재형은 얼마나 될까요?

• 주로 호출 시그니처는 모두 다른데 정보 증가가 0인 현상을 동반한다면 → 그래디언트 부재형입니다. 기존 세 단계로는 구조적으로 잡을 수 없으며, 출력 측 감지가 해결책입니다.
• 주로 이미 압축으로 사라진 내용을 다시 읽는 현상을 동반한다면 → 기억 상실형입니다. 수정해야 할 것은 압축이 보존하는 내용입니다.

이 두 결론은 완전히 다른 투자를 요구합니다. 먼저 측정하는 것이 먼저 설계하는 것보다 저렴하며, 관찰값이 이미 있으므로 계측 비용은 거의 들지 않습니다.

위의 모든 내용은 이 노트에서 정의하지 않은 채 사용한 하나의 개념, 검증된 마일스톤에 의존합니다. 다음 노트는 이를 다룹니다. 단계가 완료되었다는 선언이 왜 완료의 증거가 아닌지, 제품에 이미 존재하지만 한 번도 연결되지 않은 두 부분은 무엇인지, 논문에는 없는 한 가지 기준, 즉 중요성이 아니라 비가역성을 보아야 하는 이유를 설명합니다.