왜 당신의 에이전트는 멈추지 않는가 Image: AI generated

24/7의 자랑

“에이전트를 24시간 돌리고 있다.”

X에서 자주 보이는 말이다. 마치 에이전트가 오래 돌수록 더 많은 일을 하는 것처럼. 마치 사람이 잠을 자지 않으면 더 생산적인 것처럼.

하지만 이 문장 앞에서 드는 감각은 감탄이 아니라 의문이다.

“왜 아직 안 끝났지?”

멈출 수 있는 시스템이 건강한 시스템이다

527개 함수에 테스트를 작성하는 작업을 에이전트에게 맡겼다. 결과:

자율 에이전트:  40 / 527 완료 후 "다 했습니다" 선언
CLI 루프:     527 / 527 완주 후 종료

CLI 루프는 1시간이 걸렸다. 24시간이 아니다. 함수 하나를 처리하고, 검증하고, 통과하면 다음으로 넘어가고, 전부 끝나면 멈춘다. 이 루프의 핵심은 속도가 아니라 종료 조건이 기계적으로 정의되어 있다는 것이다.

TODO → 테스트 작성 → 커버리지 측정 → PASS/DONE → 다음 → ... → 전부 완료 → 멈춤

finite. measurable. monotonic. 그래서 수렴한다. 그래서 멈춘다.

멈출 수 있다는 건 약점이 아니다. 건강하다는 뜻이다.

멈추지 않는 세 가지 이유

에이전트가 장시간 돈다는 건 보통 세 가지 중 하나다.

1. 검증기가 약하다

"looks good"
"seems better"
"more scalable"
"clean architecture"

이런 것들은 수렴 기준이 아니다. 주관적 판단이다. go test는 pass/fail을 돌려주지만, “clean architecture"는 누가 판정하는가? 다른 LLM? 그건 술 취한 친구에게 “나 취했어?” 묻는 거다.

실증이 이를 뒷받침한다. 코드 평가용 LLM 심판은 의미가 같은 코드의 표면적 변형에도 편향돼 점수가 부풀거나 부당하게 깎이고(Moon et al. 2025), 모델은 사례의 58.19%에서 자기 답을 굽혀 동조한다(SycEval, Fanous et al. 2025). “looks good"은 정답성과 무관하다. 게다가 약한 기준은 멈추지 않는 데서 그치지 않는다 — 측정을 목표로 삼으면 측정이 망가지고(굿하트 법칙; Manheim & Garrabrant 2018), 능력 있는 추론 모델은 과제를 정면으로 푸는 대신 검증 절차 자체를 해킹한다(Bondarenko et al. 2025).

수렴 기준이 없으면 끝이 없다.

2. 작업 경계가 없다

"코드베이스를 개선해줘"
"아키텍처를 더 깔끔하게"
"계속 최적화해"

종료 조건이 없는 작업이다. 인간 개발자도 이런 목표로는 끝없이 헤맨다. 에이전트라고 다를 게 없다. “개선"은 방향이지 목적지가 아니다.

3. 엔트로피가 교정 속도를 넘는다

가장 흔하고 가장 교활한 패턴이다.

에이전트가 수정하면서 추상화를 추가한다. 간접 참조를 넣는다. 불필요한 일반화를 만든다. 코드는 “더 좋아지는” 것처럼 보이지만, 실제로는 새로운 엔트로피가 검증기가 제거하는 속도보다 빠르게 증가한다.

오늘 만든 추상화를 → 내일 다시 제거하고 → 모레 다시 추가한다

이것은 비단조적 최적화(non-monotonic optimization)다. 앞으로 가는 것 같지만 제자리다. 영구 운동 기계처럼 보이지만 에너지만 소비하고 있다. 이 경우에 에너지는 토큰이다.

대규모 실증이 이 드리프트를 포착한다. Cursor 도입은 단기 속도를 올렸지만 정적 분석 경고와 코드 복잡도는 지속적으로 증가했고, 이 누적이 장기 속도 둔화의 주 원인이었다(He et al. 2025, 807개 오픈소스 저장소). AI가 작성한 30만 건 이상의 커밋에서 도입된 이슈의 22.7%가 최신 버전까지 기술 부채로 살아남았다(Liu et al. 2026). 교정이 엔트로피를 따라잡지 못한다.

탐색 문제가 아니라 제약 충족 문제다

여기서 근본적인 관점의 차이가 드러난다.

“에이전트를 오래 돌리면 더 좋은 결과가 나온다"는 소프트웨어 엔지니어링을 **탐색 문제(search problem)**로 보는 시선이다. 넓은 공간을 오래 탐색하면 더 좋은 해를 찾을 것이라는 기대.

하지만 소프트웨어 엔지니어링은 본질적으로 **제약 충족 문제(constraint satisfaction problem)**다.

  • 타입이 맞아야 한다
  • 테스트가 통과해야 한다
  • 커버리지가 충족되어야 한다
  • 스키마가 일치해야 한다
  • 린트 규칙을 지켜야 한다

이 제약들을 모두 충족하면 끝이다. “더 탐색"할 필요가 없다. 제약을 정의하고, 충족시키고, 멈추는 것. 그것이 전부다.

코드는 이미 **기계적으로 검증 가능한 영역(machine-checkable domain)**이다. 컴파일러, 타입체커, 테스트, 커버리지, 린터, 스키마 검증 — 이 모든 것이 결정론적 검증기다. 이 검증기들이 존재하는데 왜 에이전트를 끝없이 탐색시키는가?

학습 연구도 같은 방향을 가리킨다. 단위 테스트 같은 결정론적 검증기를 보상으로 쓰면 — 검증 가능한 보상(verifiable reward) — 개방형 생성보다 코드 정확성이 높아진다(CodeRL, Le et al. 2022; RLTF, Liu et al. 2023). 검증기는 탐색을 좁히는 도구가 아니다. 애초에 이 문제가 탐색이 아니라 충족임을 드러내는 증거다.

좋은 루프의 조건

좋은 에이전트 루프는 다섯 단계로 닫힌다:

1. 작업 정의    — 무엇을 달성해야 하는가 (기계적으로 판정 가능한 목표)
2. 범위 제한    — 한 번에 하나의 단위 (함수, 엔드포인트, 파일)
3. 심볼릭 검증  — 결정론적 도구가 pass/fail 판정
4. 수렴        — 통과하면 다음으로, 실패하면 피드백과 함께 재시도
5. 종료        — 남은 항목이 없으면 멈춤

이 구조에서 LLM은 3번(생성)만 담당한다. 나머지는 전부 기계가 한다. 특히 “끝"을 기계가 결정한다는 것이 핵심이다. LLM에게 종료 판단을 맡기면 40/527에서 “다 했습니다"를 듣게 된다.

실험도 같은 방향이다. LLM에 자기 비판(self-critique)을 붙이면 추론·계획 과제에서 성능이 오히려 붕괴하고, 외부의 건전한 검증기를 붙일 때만 크게 향상된다(Stechly et al. 2024). 외부 피드백이 없는 내재적 자기 교정은 실패하거나, 때로는 교정 후 더 나빠진다(Huang et al. 2023). 종료를 LLM에게 맡기지 않는 데는 이유가 있다.

creative writing과 코드는 다르다

한 가지 예외가 있다. 모든 영역이 이렇지는 않다.

글쓰기, 마케팅, 디자인 — 이 영역은 검증기가 약하다. “이 문장이 좋은가?“를 기계적으로 판정할 수 없다. 이런 영역에서는 긴 탐색이 의미 있을 수 있다. 에이전트가 여러 변형을 생성하고, 사람이 고르는 방식.

하지만 코드는 다르다. 코드는 이미 결정론적 검증기로 가득한 세계다. 이 세계에서 장시간 방황(wandering)은 탐색이 아니라 표류(drift)다.

질문

당신의 에이전트는 지금 몇 시간째 돌고 있는가?

그것은 수렴하고 있는가, 아니면 표류하고 있는가?

멈출 수 있는가?

멈출 수 있다면, 왜 아직 안 멈췄는가?

관련 글

더 읽을거리 (외부)

출처

종료 판정 · 자기 검증의 한계

  • Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
  • Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · 자기비판의 불신뢰성

  • Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
  • Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
  • Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

드리프트 · AI 코드 복잡도 증가

  • He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
  • Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

검증 가능한 보상 · 검증기 기반 코드 생성

  • Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
  • Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

보상 해킹 · 명세 게이밍

  • Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
  • McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
  • Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
  • Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)