누군가 당신에게 "루프 엔지니어링 (loop engineering)"을 팔기 1년 반 전부터, 에이전트는 이미 "환경 피드백을 기반으로 루프 내에서 도구를 사용하는 LLM일 뿐"이었습니다 (Anthropic: Building Effective AI Agents). 용어는 새로워졌지만, 원시 개념(primitive)은 그렇지 않으며, 함정 또한 마찬가지입니다. 지난 분기에 단 한 번의 호출(single invocation)을 위해 튜닝했던 CLAUDE.md 예산과 적시 검색(just-in-time retrieval)은 작업 단위가 여러 개로 늘어날 때 더 크게 실패하는 것이 아닙니다. 그것들은 더 조용히 실패하며, 동일하게 비대해진 컨텍스트(context)에 더 많은 자율성을 부여하는 것은 상황을 개선하는 것이 아니라 악화시킵니다.

루프 엔지니어링은 당신이 이미 가지고 있던 원시 개념입니다

루프 엔지니어링을 완전히 새로운 분야(greenfield discipline)로 받아들이기 전에, 루프가 실제로 무엇인지 살펴보십시오. 그것은 에이전트가 이미 존재하던 방식입니다. Anthropic의 정의는 2024년 12월 이후 변하지 않았습니다. 에이전트는 "일반적으로 루프 내에서 환경 피드백을 기반으로 도구를 사용하는 LLM일 뿐"입니다 (Anthropic: Building Effective AI Agents). Simon Willison은 이 용어가 유행하기 9개월 전부터 해당 루프의 설계를 "개발해야 할 중요한 새로운 기술"이라고 불렀습니다. 그의 작업 정의도 동일합니다. LLM 에이전트는 "목표를 달성하기 위해 루프 내에서 도구를 실행하는 것"입니다 (Simon Willison: Designing agentic loops). Claude Agent SDK는 이와 동일한 사이클을 네 단계로 설명합니다 — "컨텍스트 수집(gather context) -> 행동 취하기(take action) -> 작업 검증(verify work) -> 반복(repeat)" (Anthropic: Building agents with the Claude Agent SDK).

따라서 Addy Osmani가 새로운 용어를 정의할 때 — "루프 엔지니어링(Loop engineering)은 에이전트에게 프롬프트를 입력하는 사람으로서의 당신 자신을 대체하는 것입니다. 대신 그것을 수행하는 시스템을 설계하는 것입니다" (Addy Osmani: Loop Engineering) — 이를 새로운 메커니즘의 등장이 아니라, _누가 루프를 실행하는가(who runs the loop)_의 변화로 읽어야 합니다. 기본 요소(primitive)는 당신이 수동으로 운전해 온 '수집/행동/검증(gather/act/verify)' 사이클과 동일합니다. 루프 엔지니어링은 턴(turn) 사이에 엔터(enter) 키를 누르는 것을 멈추기로 한 결정입니다.

"엔터 키를 누르는 것을 멈춘다"는 것의 구체적인 버전은 이 포스트 전체에서 계속 언급되는 산출물(artifact)인 '무인 야간 루프(unattended overnight loop)'입니다.

# Ralph 루프 — 매 반복마다 새로운 컨텍스트(context), 디스크 상의 상태(state).
while :; do cat PROMPT.md | agent; done

당신은 이를 PROMPT.md로 지정하고 저녁에 자리를 떠난 뒤, 아침에 그것이 만들어낸 결과물을 읽습니다. 이는 Geoffrey Huntley가 "Ralph"라고 대중화한 기술입니다 (Geoffrey Huntley: Ralph Wiggum as a "software engineer"). 저 코드 라인에서 새로운 것은 아무것도 없습니다. 그것은 while :; do ... done으로 감싸져 열쇠를 넘겨받은 당신의 싱글 인보케이션(single-invocation, 단일 호출) 에이전트일 뿐입니다.

따라서 이 프레임워크는 백지상태가 아니라 이주(migration)입니다: 루프 엔지니어링을 처음부터 배우는 새로운 규율이 아니라, 당신의 싱글 인보케이션 습관을 여러 번 실행하는 것으로 취급하십시오. 이러한 재정의(reframe)는 어디에서 문제가 발생하는지를 알려줍니다. 문제는 루프 구문(syntax)에 있지 않습니다. 그것은 단 한 줄일 뿐입니다. 문제는 작업 단위가 단일 호출(one invocation)이었고, 작업이 완료되는 순간 컨텍스트 윈도우(context window)가 초기화되었을 때 당신이 플레이북(playbook)에 심어두었던 모든 가정에 있습니다. 루프는 그 자리를 계속 유지할 뿐입니다.

이 축은 다른 축과 혼동하기 쉬우므로 정확히 명명할 가치가 있습니다. 루프는 하나의 에이전트가 순차적으로 반복하는 것을 의미하며, 매 턴마다 동일한 컨텍스트 계보(context lineage)를 유지합니다. 많은 에이전트를 병렬로 실행하는 것은 다른 문제이며, 실패 모드도 다릅니다. 저는 다중 에이전트 컨텍스트 격리에서 논의한 것처럼 격리와 핸드오프(hand-off)에 대한 우려가 있습니다. 루프 엔지니어링은 순차적 축 위에 존재합니다: 에이전트 수가 늘어나는 것이 아니라, 하나의 반복 횟수가 늘어나는 것입니다. 이것이 지금 왜 중요한지는 측정 가능합니다. '에이전트가 자율적으로 완료할 수 있는 작업의 길이가 지난 6년간 약 7개월마다 두 배로 증가해 왔다'는 사실(METR: 장기 작업을 완료하는 AI 능력 측정)가 이를 증명합니다. 루프가 길어지면서, 첫 번째 턴에서 단순히 잘못된 가정이 오십 번째 턴에서는 큰 비용이 됩니다.

반복(Iteration)당 세금처럼 CLAUDE.md를 감사하세요

CLAUDE.md의 모든 '만약을 대비한' 줄을 한 번에 지불하는 수수료가 아니라, 매 반복마다 다시 지불해야 하는 비용으로 재읽으세요. 단일 호출에서 부풀려진(bloated) 명령어 파일은 고정 비용입니다. 에이전트는 이 파일을 로드하고, 아래쪽 근처의 규칙이 따르거나 명령어 상한선을 넘어서서 사라지게 됩니다—조용히, 한 번만요. 루프에서는 동일한 파일이 매 턴마다 다시 로드되고, 각 턴은 자신의 출력을 그 위에 쌓아 올립니다.

에이전트가 루프 내에서 실행되면 다음 추론(inference) 턴에 관련성이 있을 수 있는 데이터가 점점 더 많이 생성되며, 이 정보는 주기적으로 정제되어야 합니다.
— Anthropic: AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링

Refined(정제된)는 핵심적인 단어입니다. 컨텍스트는 스스로 정제되지 않습니다. 그대로 방치하면 기본적으로 비대해지는데, 그 이유는 "각 호출(invocation)마다 전체 추론 패스(inference pass)가 필요하며, 중간 결과물들이 유용하든 아니든 컨텍스트에 쌓이기 때문"입니다 (Anthropic: Introducing advanced tool use on the Claude Developer Platform). 상시 활성화된(always-on) 컨텍스트가 도달할 수 있는 규모는 과소평가하기 쉽습니다. Anthropic은 "최적화 전 도구 정의(tool definitions)가 134K 토큰을 소비하는 것을 목격했다"고 보고했습니다 (Anthropic: Advanced tool use). 이 수치는 도구 정의에 대한 것이지 귀하의 CLAUDE.md에 대한 것은 아니지만, 문제의 형태는 동일합니다. 즉, 이번 턴에 필요하든 아니든 모든 추론 패스에 올라타 있는 상시 활성화된 블록인 것입니다.

귀하의 야간 루프(overnight loop)가 가리키고 있는 파일에 대해 한 줄씩 적용할 감사(audit) 항목은 다음과 같습니다:

• 에이전트가 레포지토리에서 읽을 수 있는 아키텍처 정보인 경우 → 삭제하십시오. 이는 grep으로 필요할 때마다 찾아낼 수 있는 정보를 위해 매 반복(iteration)마다 지불하는 컨텍스트 낭비(context burn)입니다.
• 실제 실패를 초래한 적이 없는 "만약을 대비한" 선호도인 경우 → 삭제하십시오. 한 번의 호출에서는 하나의 방해 요소(distractor)였을 뿐이지만, 50번의 반복을 거치면 50개의 방해 요소가 됩니다.
• 반드시 지켜져야 하는 진정한 제약 조건인 경우 → 유지하십시오. 실행 가능한 체크(runnable check) 형태로 구사하고, 파일의 가능한 높은 위치로 옮기십시오. 위치가 뒤로 갈수록 영향력이 감쇠(decay)하기 때문입니다.
• 엄격한 안전 경계(hard safety boundary)인 경우 → 이는 권고 파일(advisory file)에 포함될 성질의 것이 아닙니다. 키보드를 잡은 인간이 없는 루프는 "에이전트가 보통 이를 준수한다"라는 말로는 충분하지 않은 바로 그 실행 상황입니다.

해당 감사를 건너뛰는 데 따르는 신뢰성 비용은 주장되는 것이 아니라 측정되는 것입니다. 18개의 모델과 194,480회의 호출을 대상으로 한 Chroma의 연구에 따르면, "모델은 컨텍스트 (context)를 균일하게 사용하지 않으며, 대신 입력 길이가 길어질수록 성능이 점점 더 불안정해집니다" (Chroma: Context Rot). 이는 특정 업체의 마케팅 문구가 아닙니다. Chroma는 _컨텍스트 부패 (context rot)_라는 용어를 만들었으며, Anthropic 또한 자사 제품 페이지에서 동일한 발견을 기록하고 있습니다: "토큰 수가 증가함에 따라 정확도와 회상률 (recall)이 저하되는데, 이는 컨텍스트 부패 (context rot)라고 알려진 현상입니다" (Anthropic: Context windows). 단일 호출 (single invocation)은 컨텍스트 부패 비용을 한 번만 지불하지만, 루프 (loop)는 매 턴마다 비용을 지불하며, 루프가 계속해서 추가하는 출력물과 함께 그 청구액은 복리로 불어납니다.

존재감보다 제시 방식: 50번째 턴을 위해 축약하라

루프가 오작동할 때 본능적으로 하게 되는 행동은 한 줄을 추가하는 것, 즉 에이전트가 놓친 규칙을 명시하는 것입니다. 이는 존재감 (presence)을 최적화하는 방식입니다. 즉, 규칙이 기술적으로 파일 안에 들어가게 만드는 것이죠. 하지만 존재감은 잘못된 목표입니다. Chroma의 더 날카로운 발견은 "모델의 컨텍스트에 관련 정보가 존재하는지 여부가 전부가 아니라, 그 정보가 어떻게 제시 (presented)되는지가 더 중요하다"는 것입니다 (Chroma: Context Rot). 첫 번째 턴에서는 300줄짜리 CLAUDE.md와 60줄짜리 파일 모두 기술적으로는 당신의 규칙을 포함하고 있습니다. 하지만 루프 자체의 출력물이 위로 쌓이는 50번째 턴에 이르면, 규칙이 여전히 읽기 쉬운 것은 60줄짜리 파일입니다. 규칙이 처음에 존재하는지 여부가 아니라, 실행이 깊게 진행되었을 때 파일이 어떻게 읽히는지를 기준으로 축약하고 순서를 정하십시오.

깔끔한 원샷 (One-Shot) 데모는 당신이 가진 가장 취약한 증거다

저자의 판단. 루프(loop)가 데모보다 단순히 더 자주 실패하는 것이 아니라, 더 조용히(quieter) 실패한다는 것은 측정된 결과가 아닌 저자의 추론입니다. 이는 두 가지 근거가 있는 전제로부터 도출됩니다: 모델은 자신의 이전 오류에 대해 자기 조건화(self-conditioning)를 수행하며 (Sinha et al.), 자율적인 실행은 "오류가 누적될 가능성(the potential for compounding errors)"을 내포하고 있다는 점입니다 (Anthropic). 깔끔한 첫 번째 턴(turn)은 당신이 가진 50번째 턴에 대한 데이터 중 가장 정보량이 적은 데이터 포인트입니다.

결점 없는 단일 실행은 자율성에 관한 의사결정을 내릴 때 제시할 수 있는 최악의 증거입니다. 왜냐하면 단계별 신뢰도(per-step reliability)는 단일 턴 신뢰도(single-turn reliability)와는 다른 양이며, 그 격차는 측정 가능한 것이기 때문입니다.

모델의 단계별 정확도(per-step accuracy)는 단계 수가 증가함에 따라 저하됩니다. 이는 단순히 긴 컨텍스트(long-context)의 한계 때문만이 아닙니다. 흥미롭게도 우리는 자기 조건화(self-conditioning) 효과를 관찰했습니다. 즉, 컨텍스트에 이전 턴의 오류가 포함되어 있을 때 모델은 실수를 저지를 가능성이 더 높아집니다.
— Sinha et al.: The Illusion of Diminishing Returns

그들의 가장 날카로운 데이터 포인트는 깔끔한 데모로부터 외삽(extrapolating)하는 것에 정면으로 반합니다: "작은 모델이 거의 완벽한 단일 턴 정확도를 가질 때조차, 더 큰 모델은 현저히 더 많은 턴을 정확하게 실행할 수 있습니다." 단일 턴 정확도는 모델이 얼마나 많은 턴을 버텨낼 수 있는지를 예측하지 못합니다.

이 결과와 그 주의사항들을 함께 가져가십시오. 정직한 버전이 무서운 버전보다 더 유용하기 때문입니다. 이 결과는 실제 도구 루프(tool loop)가 아닌 합성 실행 합계(synthetic running-sum) 작업에서 측정되었습니다. 또한 동일한 저자들은 "사고(thinking)가 자기 조건화(self-conditioning)를 완화한다"는 점을 발견했습니다. 그리고 직관과는 반대로, 더 큰 모델이 자기 조건화에 더 취약하며, 덜 취약하지 않습니다. 따라서 주장은 "큰 모델은 루프에서 멍청해진다"가 아닙니다. 그보다 더 좁고 회피하기 어려운 주장입니다: 싱글샷 정확도(single-shot accuracy)는 루프 신뢰도(loop reliability)를 예측하지 못하며, 외삽을 깨뜨리는 메커니즘은 모델이 자신의 이전 실수를 정답(ground truth)으로 읽는다는 것입니다.

실행 중인 아티팩트(artifact)에서 발생하는 메커니즘은 다음과 같습니다. 밤샘 루프(overnight loop)가 12번째 반복(iteration)에서 잘못된 판단을 내린다고 가정해 봅시다. 예를 들어, 토큰 갱신(token-refresh) 흐름을 잘못 읽어 auth.go를 수정하고 이를 커밋(commit)합니다. 12번째 이후의 모든 반복은 새로운 컨텍스트(context)를 열고, 현재 상태의 저장소(repo)를 읽으며, 그 잘못된 auth.go가 확립된 사실로서 존재하는 것을 발견합니다. 루프는 더 이상 자신의 실수를 디버깅(debugging)하는 것이 아니라, 그 실수 위에 결과물을 쌓아 올리고 있는 것입니다. 새벽 3시가 되면, 모델은 결코 내리지 말았어야 할 결정과 코드베이스를 일치시키기 위해 30번의 반복을 소모한 상태가 되며, 터미널은 그 과정 내내 꾸준하고 자신감 있는 진행 상황을 보여줍니다. 이것이 바로 Anthropic이 경고한(Anthropic: Building Effective AI Agents), 관리되지 않은 채 실행되는 오차 누적(compounding-errors) 경로입니다. 한 번의 잘못된 판단이 미치는 폭발 반경(blast radius)은 더 이상 당신이 잡아낼 수 있는 단일 턴(turn)에 그치지 않습니다. 그것은 해당 커밋을 읽는 모든 턴이 됩니다.

이것이 바로 데모가 생략을 통해 거짓말을 하는 이유입니다. 밤샘 루프를 대중화한 Geoffrey Huntley는 그 비결정론(nondeterminism)에 대해 직설적으로 말합니다. Ralph는 경로를 이탈할 수 있으며, 모델이 스스로의 작업에 점수를 매기게 두는 대신 프로그래밍 방식의 검증(programmatic verification)을 구축하지 않는다면, 컴파일조차 되지 않는 망가진 코드베이스를 마주하며 깨어날 수 있다는 것입니다(Geoffrey Huntley: Ralph Wiggum as a "software engineer"). 당신에게 보여준 데모는 첫 번째 시도에 깨끗하게 배포되어 보존된 실행 결과일 뿐입니다. 경로를 이탈한 실행 결과들은 기록되지 않으며, 이것이 바로 깔끔한 원샷(one-shot) 데모가 현장에서 가장 취약한 증거인 정확한 이유입니다.

단일 프롬프트에는 결코 없었던 두 영역에 예산을 할당하라

단일 프롬프트에는 루프가 가지지 못한 두 가지가 있습니다. 바로 자연스러운 종료와 작업이 지속되는 시간만큼만 유지되는 메모리입니다. 작업이 끝나면 윈도우(window)가 비워지고, "완료(done)\

종료(stop)부터 시작하십시오. Anthropic의 기본 원칙은 "작업은 완료 시 종종 종료되지만, 제어력을 유지하기 위해 (최대 반복 횟수와 같은) 종료 조건(stopping conditions)을 포함하는 것도 일반적이다"(Anthropic: Building Effective AI Agents)입니다. 이를 가장 구체적으로 다루는 가이드(field guide)에서는 세 가지를 명시하고 있으며, 관리되지 않는 루프(unattended loop)에는 이 세 가지가 모두 필요합니다: