Loop Engineering의 가치와 과설계 기준

핵심 요지

Loop Engineering의 가치는 “AI가 코드를 더 빨리 치게 하는 것”보다 넓다. 핵심은 어떤 작업을 자동화·상태·검증·위임·핸드오프가 있는 반복 시스템으로 감쌌을 때, 완료 시간과 작업 처리량, 그리고 품질을 입증하는 증거가 실제로 좋아지는지를 판단하는 것이다.

반대로 검증 가능한 성공 기준이 없거나, 단발 retrieval과 LLM 호출만으로 충분하거나, 지연·비용 절감이 품질 향상보다 중요한 낮은 위험도의 작업이라면 루프는 과설계가 될 수 있다. 이 노트는 loop-engineering의 실무 적용 가치를 판단하기 위한 기준을 정리한다.

근거와 판단 기준

1. “코드를 더 빨리 친다”보다 넓은 이유

loop-engineering의 핵심은 단일 프롬프트를 잘 쓰는 것이 아니라, 에이전트에게 프롬프트를 공급하고 결과를 검증하며 다음 행동을 결정하는 반복 시스템 자체를 설계하는 일이다. Addy Osmani의 원문도 루프를 “일을 찾고, 나누고, 검사하고, 완료 상태를 기록하고, 다음 행동을 결정하는 작은 시스템”으로 설명한다.

따라서 Loop Engineering의 가치는 단순한 코드 작성 속도보다 넓다. 작업 발견, 분배, 격리, 검증, 상태 저장, 사람에게 넘기는 핸드오프까지 포함한다.

2. 도입 여부를 판단하는 실무 기준

원문은 /goal처럼 검증 가능한 정지 조건을 두고, 작성자와 검사자를 분리하며, 상태 파일을 루프의 척추로 삼는 구조를 강조한다. 이는 “루프를 도입했을 때 실제로 완료까지의 시간, 처리 가능한 작업 단위, 품질 증거가 좋아지는가?”라는 질문과 잘 맞는다.

다음 네 가지를 함께 봐야 한다.

기준	질문
완료 시간	사람이 매번 프롬프트할 때보다 end-to-end 완료가 빨라지는가?
작업 길이	한 번의 대화보다 긴 작업을 상태 저장과 재시도로 안정적으로 끌고 가는가?
품질 증거	테스트, 린트, 로그, trace, 리뷰 결과처럼 확인 가능한 증거가 늘어나는가?
운영 부담	토큰 비용, 지연, 리뷰 대역폭, 권한 위험이 이득보다 작게 유지되는가?

3. 성공 기준이 없으면 루프는 위험하다

2026-06-14-loop-engineering은 루프의 단위가 프롬프트가 아니라 완료 기준이라고 정리한다. 테스트, 린트, 재현 절차, 비용 한도, 승인 조건이 없으면 루프의 “완료”는 증명이 아니라 주장에 머문다.

성공 기준 없는 루프는 자동화가 아니라, 사람이 보지 않는 곳에서 실패를 반복하는 구조가 될 수 있다.

4. 종료 조건은 관찰 가능한 증거여야 한다

품질 기준은 에이전트가 “done”이라고 말하는 순간이 아니다. 종료 조건은 가능한 한 환경에 남는 관찰 가능한 증거여야 한다. 코딩 에이전트라면 다음 신호가 우선순위를 갖는다.

종료 조건	성격	용도
Unit test	deterministic outcome check	함수·모듈 단위 회귀 방지
Integration test	deterministic outcome check	여러 컴포넌트가 함께 동작하는지 확인
Static analysis / type check / lint	deterministic structural check	실행 전 결함과 규칙 위반 탐지
Sandbox execution	grounded runtime check	실제 실행 환경에서 부작용·오류 관찰
Golden set	regression benchmark	알려진 입력/출력 쌍에서 품질 유지 확인
Model grader	qualitative or behavioral judge	코드 품질, 추론 과정, tool-use behavior 보조 평가
Human approval	calibrated high-risk gate	rubric 보정, 위험 변경, 제품 판단

Anthropic의 raw source: web-2026-07-02-anthropic-demystifying-evals-for-ai-agents은 transcript와 outcome을 분리한다. 에이전트가 마지막 메시지에서 “예약 완료”라고 말하는 것과, 실제 환경의 데이터베이스에 예약 레코드가 존재하는 것은 다르다. Loop Engineering에서도 마찬가지로, 루프의 종료 조건은 에이전트의 자기 선언이 아니라 테스트·실행·환경 상태·리뷰 결과 같은 증거여야 한다.

5. task / trial / grader / trace / outcome / harness를 분리해서 보기

Anthropic의 2026년 agent eval 글 기준으로 Loop Engineering의 품질 판단은 다음 개념을 분리해서 봐야 한다.

개념	Loop Engineering에서의 의미
Task	루프가 해결해야 하는 단일 작업 또는 시나리오
Trial	특정 task에 대해 루프를 한 번 실행한 기록
Transcript / trace	모델 메시지, tool call, 파일 변경, 로그 등 실행 경로
Outcome	trial 종료 후 환경에 남은 최종 상태와 결과
Grader	outcome이나 trace를 점수화하는 deterministic check, LLM judge, 사람 리뷰어
Evaluation harness	task 실행, 기록, 채점, 집계를 자동화하는 평가 인프라
Agent harness	모델이 도구를 쓰고 행동하게 만드는 실제 에이전트 실행 scaffold

중요한 점은 agent harness와 evaluation harness를 혼동하지 않는 것이다. 전자는 에이전트가 일을 하게 만드는 시스템이고, 후자는 그 에이전트+하네스 조합을 평가하는 시스템이다. 루프를 개선한다는 말은 둘 중 무엇을 바꾸는지 명확해야 한다.

6. Generator/evaluator loop의 위치

Anthropic의 raw source: web-2026-07-02-anthropic-building-effective-agents는 evaluator-optimizer workflow를 “한 LLM 호출이 생성하고, 다른 LLM 호출이 평가와 피드백을 제공하는 루프”로 설명한다. 이 구조는 loop-engineering의 작성자/검사자 분리와 잘 맞지만, 조건이 있다. 평가 기준이 분명하고 반복 개선이 측정 가능한 가치를 낼 때 적합하다.

coding agent에서는 deterministic outcome check가 중심이어야 한다. unit test, integration test, static analysis, sandbox execution이 루프의 1차 종료 조건이 되고, LLM rubric은 다음처럼 보조 평가로 두는 편이 안전하다.

코드 품질과 단순성
변경 범위가 task에 맞는지
tool-use behavior가 과도하거나 위험하지 않은지
trace상 불필요한 우회나 실패 반복이 있었는지
사람이 리뷰해야 할 위험 신호가 있는지

Human review는 모든 사소한 trial의 기본 grader가 아니라, rubric calibration과 high-risk case의 최종 승인 게이트로 남겨두는 것이 좋다.

7. 나쁜 종료 조건과 좋은 종료 조건

Loop Engineering에서 종료 조건을 설계할 때는 “agent가 그렇게 말했다”와 “환경에서 그렇게 관찰된다”를 분리해야 한다. 다음 표는 루프 종료 조건을 설계할 때의 실무 체크리스트다.

나쁜 종료 조건	좋은 종료 조건	개발자 설계 포인트
“수정 완료했습니다”라는 모델 문장	테스트 통과, 로그, diff, 재현 절차	agent 응답과 verifier output을 분리한다
LLM judge 단독 점수	deterministic check + LLM judge 보조	정답이 있는 영역은 deterministic gate를 우선한다
한 번 성공한 demo	capability eval + CI regression + production monitor	새 능력 측정과 기존 기능 보호를 다른 suite로 관리한다
trace 없는 성공률	outcome, transcript, latency, token/cost metric 동시 기록	실패 재현과 비용 제어까지 eval 대상에 넣는다

이 표의 핵심은 루프의 “성공”을 단일 숫자나 단일 응답으로 환원하지 않는 것이다. outcome은 최종 상태를, transcript/trace는 실패 경로와 tool-use behavior를, latency와 token/cost는 운영 가능성을 설명한다. 좋은 evaluation harness는 이들을 함께 기록하고, 어떤 grader가 어떤 증거를 보고 판단했는지 남긴다.

8. 자율성은 단계적으로 넓힌다

루프의 기본 전략은 자율성을 한 번에 키우는 것이 아니라, 제어 표면을 단계적으로 넓히는 것이다. 권장 순서는 다음과 같다.

단계	설명	다음 단계로 넘어갈 조건
Single call	도구 없이 단일 LLM 호출로 답을 만든다	단일 호출의 실패 유형과 baseline 품질을 안다
Tool augmentation	검색, 파일 읽기, 테스트 실행 같은 제한된 도구를 붙인다	도구 호출이 품질을 실제로 개선하고 비용이 감당 가능하다
Fixed workflow	정해진 순서의 단계형 workflow로 실행한다	반복되는 절차가 안정화되고 실패 지점이 기록된다
Evaluator-optimizer	생성자와 평가자를 분리해 feedback loop를 만든다	평가 기준이 명확하고 반복 개선의 이득이 측정된다
Bounded autonomous loop	제한된 범위 안에서 에이전트가 다음 행동을 고른다	종료 조건, 비용 한도, 롤백, 사람 승인 경계가 있다

각 단계마다 최소한 다음 안전장치를 둔다.

Baseline eval: 더 복잡한 루프가 단순한 방식보다 실제로 나은지 비교한다.
Max iteration: 무한 반복을 막는다.
Timeout: 긴 실행이 비용과 지연을 잠식하지 않게 한다.
Cost cap: 토큰·도구·인프라 비용의 상한을 둔다.
Rollback 기준: 어떤 변경을 되돌릴지, 어떤 상태로 복구할지 미리 정한다.

이 순서는 Anthropic의 “단순한 구성부터 시작하고, 필요한 경우에만 agentic pattern을 추가하라”는 원칙과도 맞다. Loop Engineering의 성숙도는 자율성을 많이 주는 정도가 아니라, 자율성을 늘릴 때마다 관측·평가·복구 경계도 함께 늘리는 정도로 판단해야 한다.

9. 코딩 에이전트 성능은 모델만으로 결정되지 않는다

raw source: web-2026-07-02-openhands-sdk와 raw source: 2026-07-02-swe-agent-agent-computer-interfaces는 코딩 에이전트의 성능이 모델 자체만이 아니라, 모델을 둘러싼 tool/runtime/interface 설계에 크게 좌우된다는 점을 보여준다.

사례	하네스/인터페이스 요소	Loop Engineering 관점의 의미
OpenHands SDK	Python/REST API, Bash 실행, file edit, web browsing, MCP, REST 기반 Agent Server, Docker/Kubernetes 실행	코딩 에이전트는 모델 호출이 아니라 실행 도구, 서버, 샌드박스, 배포 표면까지 포함한 제품형 하네스 위에서 동작한다
SWE-agent	파일 탐색, 코드 편집, 테스트 실행, repository navigation, context management에 맞춘 agent-computer interface	같은 모델이라도 ACI가 좋아지면 SWE-bench류 작업에서 행동과 성능이 달라질 수 있다

SWE-agent 논문의 핵심은 LM agent를 사람과 같은 UI의 사용자로만 보지 말고, agent에게 맞춘 컴퓨터 인터페이스의 사용자로 보자는 점이다. 코딩 작업에서는 파일을 찾고, 작은 단위로 편집하고, 테스트를 실행하고, 실패 로그를 다시 컨텍스트에 넣는 방식 자체가 성능을 만든다.

따라서 Loop Engineering에서 “모델을 바꿀 것인가?”는 마지막 질문에 가깝다. 먼저 ACI와 하네스의 제어 표면을 봐야 한다.

파일 탐색 결과가 agent가 쓰기 좋은 단위로 제공되는가?
편집 도구가 diff와 rollback을 남기는가?
테스트 실행과 실패 로그가 다음 trial의 컨텍스트로 들어가는가?
web/MCP/REST 도구 권한이 task 범위에 맞게 제한되는가?
local, Docker, Kubernetes 같은 실행 환경 차이가 eval에 반영되는가?

이 관점은 “모델 성능”과 “루프 성능”을 분리하게 해 준다. 같은 모델을 쓰더라도 agent-computer interface, context compression, tool schema, sandbox, evaluation harness가 달라지면 결과는 달라진다.

10. 코딩 루프의 ACI 설계 변수

SWE-agent 관점에서 ACI는 단순히 “도구를 많이 주는 것”이 아니다. agent가 파일을 찾고, 편집하고, 명령을 실행하고, 관찰 결과를 다시 추론에 쓰는 모양을 설계하는 일이다.

설계 변수	왜 중요한가	실전 구현 힌트
file/search affordance	repo 탐색 실패가 잘못된 patch로 이어진다	검색 결과를 압축하고, 읽은 파일과 라인을 trace에 남긴다
editor interface	모델이 의도한 diff와 실제 diff가 어긋날 수 있다	patch 단위 적용, diff check, rollback을 기본화한다
command sandbox	테스트와 빌드, shell은 검증기이자 위험 권한이다	timeout, allowlist, workdir, secret redaction을 둔다
observation shape	긴 로그는 다음 reasoning을 오염시킨다	실패 요약, exit code, 핵심 stack trace, 재현 명령을 구조화한다

이 네 변수는 raw source: 2026-07-02-swe-agent-agent-computer-interfaces가 말하는 “agent-computer interface가 성능을 바꾼다”는 주장을 실무 설계 항목으로 바꾼 것이다. 좋은 코딩 루프는 agent에게 더 많은 권한을 주기 전에, agent가 읽고 행동하고 관찰하는 표면을 먼저 정리한다.

11. 단발 retrieval + LLM 호출이면 충분한 작업

루프는 자동화, 워크트리, 스킬, 커넥터, 서브에이전트, 상태 저장소를 결합하므로 고정 비용이 있다. 질문 답변, 짧은 요약, 단순 검색처럼 한 번의 retrieval과 LLM 호출로 충분한 작업이라면 루프를 두르는 것은 오히려 지연과 복잡도를 늘릴 수 있다.

12. 운영 도입 순서

자율 루프를 운영 환경에 넣을 때는 기능을 한 번에 켜지 않는다. 먼저 실패가 보이게 만들고, 그다음 권한과 상태, 반복, 복구 경계를 차례로 추가한다.

도입 순서	목표	다음 단계로 가는 조건
1. deterministic verifier	test, lint, rubric, human gate 정의	실패가 기계적으로 관찰된다
2. scoped tools	읽기/쓰기/실행 권한을 분리	side effect와 secret 노출이 통제된다
3. state schema	trace, observation, decision, artifact 구조화	재개, 디버깅, 요약이 가능하다
4. bounded retry	max iteration, timeout, cost cap 설정	실패가 무한 반복되지 않는다
5. HITL/rollback	고위험 변경 승인과 복구 경로 확보	운영 환경에서 안전하게 확장 가능하다

이 순서는 “자율성을 얼마나 줄 것인가”보다 “실패를 어디서 멈추고 어떻게 되돌릴 것인가”를 먼저 묻는다. Loop Engineering의 운영 성숙도는 agent가 혼자 할 수 있는 일의 크기가 아니라, 실패를 관찰·제한·복구할 수 있는 정도로 판단해야 한다.

13. 루프 효과 근거의 강도를 구분한다

Loop Engineering의 효과를 말할 때는 수치 자체보다 근거의 종류를 먼저 봐야 한다. 통제 실험과 공식 통계는 비교적 강한 근거지만 적용 범위가 제한되고, vendor·언론 보도는 방향성 근거로 읽는 편이 안전하다.

지표	수치	근거 종류	읽는 법
과제 완료 시간 (raw source: `2026-07-02-copilot-productivity-rct`)	control 대비 55.8% 빠름	통제 실험	표준화 과제 한정. 모든 업무로 일반화 불가
조직 비용 절감 (raw source: `web-2026-07-02-stanford-ai-index-2025-economy`)	service ops 49%, supply chain 43%, SW eng 41%가 절감 보고. 대부분 10% 미만 폭	공식 통계	절감 “여부” 비율이지 평균 절감률이 아님
작업 시간 지평 (raw source: `web-2026-07-02-metr-long-tasks`)	약 7개월마다 2배	벤치마크 연구	긴 작업일수록 loop/eval 필수라는 구조적 근거
AI 코딩 도구 사용 (raw source: `web-2026-07-02-stack-overflow-2025-survey-ai-tools`)	전문 개발자 다수가 사용 또는 도입 예정	대규모 설문	사용 의향이지 생산성 증거는 아님
Claude Code 도입 규모	다수 기업 도입, 빠른 성장	vendor·언론 보도	독립 검증 ROI가 아니라 채택 신호로만 읽는다

이 표는 “AI coding/agent loop가 효과가 있다”를 한 문장으로 말하지 않기 위한 장치다. 같은 수치라도 통제 실험, 공식 통계, 벤치마크, 설문, vendor 보도는 증거 강도가 다르다. 루프 설계에서는 adoption signal과 productivity evidence를 분리해야 한다.

실무적으로는 다음 순서로 읽는다.

통제 실험: 특정 과제와 지표에 대해 강하지만 범위가 좁다.
벤치마크 연구: capability trend를 보지만 실제 조직 ROI와는 다르다.
공식 통계: 시장·조직 단위 방향성은 강하지만 원인 추론은 약하다.
대규모 설문: 사용률과 의향은 보이나 생산성 효과는 직접 말하지 않는다.
vendor/언론 보도: 채택 신호로는 유용하지만 독립 검증 ROI로 취급하면 안 된다.

따라서 Loop Engineering의 효과를 주장하려면 최소한 “어떤 작업에서, 어떤 종료 조건으로, 어떤 baseline 대비, 어떤 비용과 품질 증거를 기록했는가”를 함께 제시해야 한다.

14. low-stakes 작업과 비용·지연 우선 작업

2026-05-24-agent-harness-engineering-survey는 하네스 설계의 핵심 제약으로 비용·품질·속도 트릴레마를 든다. 더 강한 검증과 더 긴 루프는 품질을 올릴 수 있지만 토큰, 지연시간, 인프라 비용도 함께 올린다.

따라서 품질 증거보다 빠른 응답과 낮은 비용이 더 중요한 low-stakes 작업에서는 루프가 과설계가 될 수 있다. 좋은 루프 설계는 “무엇을 자동화할 것인가”만큼 “무엇은 루프화하지 않을 것인가”를 정하는 일이다.

16. 논문 기반 루프 패턴 맵

Loop Engineering의 논문 기반은 단일한 “Loop Engineering paper”가 아니다. 더 정확한 맵은 행동 루프, 도구 루프, 자기수정 루프, 탐색 루프, 장기 경험 루프, 평가 루프의 조합이다.

분류	대표 자료	가져갈 설계 원리
행동 루프	raw source: `2026-07-02-react-reasoning-acting`, raw source: `2026-07-02-swe-agent-agent-computer-interfaces`	행동 결과를 observation으로 받아 다음 reasoning/state에 반영
도구 루프	raw source: `2026-07-02-toolformer`, ReAct, OpenAI built-in tools	tool schema, call timing, provenance, side-effect boundary 설계
자기수정 루프	raw source: `2026-07-02-self-refine`, raw source: `2026-07-02-reflexion`	feedback/reflection은 로그가 아니라 다음 시도의 structured state
탐색 루프	raw source: `2026-07-02-tree-of-thoughts`	branching은 품질을 살 수 있지만 token/cost budget과 pruning 필요
장기 경험 루프	raw source: `2026-07-02-voyager`	반복 경험을 reusable skill/memory로 축적할 때 state 설계가 중요
평가 루프	raw source: `2026-07-02-swe-bench`, raw source: `web-2026-07-02-metr-long-tasks`	최종 산출물이 실제 task를 끝냈는지 test/subset/time horizon으로 판정

ReAct는 Thought → Action → Observation trajectory로 reasoning과 acting을 결합했다. Toolformer는 외부 API 호출 여부, 호출 시점, 인자, 결과 통합을 학습 문제로 만들었다. Reflexion과 Self-Refine은 실패 피드백 또는 self-feedback을 다음 trial의 state로 되돌리는 test-time 루프를 보여준다.

Tree of Thoughts와 Voyager는 루프의 폭과 시간축을 확장한다. ToT는 thought 후보를 생성·평가·탐색·백트래킹하는 search process로 inference를 재해석했고, Voyager는 environment feedback, executable skill library, self-verification을 묶어 Minecraft에서 장기 skill accumulation을 시도했다.

SWE-bench와 SWE-agent는 이 논의를 software engineering으로 가져온다. repository navigation, file edit, command feedback, test verification, ACI가 모두 성능 변수다. 따라서 코딩 루프는 단순한 prompt loop가 아니라 행동·도구·상태·탐색·기억·평가 루프의 합성물로 봐야 한다.

17. Benchmark shift: 정답 텍스트에서 작업 완료로

평가의 단위가 “정답 텍스트”에서 실제 작업 완료와 실패 복구로 옮겨가고 있다. raw source: 2026-07-02-swe-bench 계열과 raw source: web-2026-07-02-metr-long-tasks은 이 변화를 잘 보여준다.

raw source: 2026-07-02-swe-bench는 500개 human-filtered subset을 제공한다. 각 instance는 문제 설명이 명확한지, test patch가 올바른지, 주어진 정보로 해결 가능한지 사람이 검토한 subset이다. Verified leaderboard는 simple LM agent loop부터 RAG system, multi-rollout, review type system까지 다양한 코딩 시스템을 함께 비교한다. 즉 leaderboard 점수는 모델만이 아니라 loop, retrieval, rollout, review, ACI 설계의 합성 성능이다.

METR의 long-task 연구는 agent 성능을 “얼마나 긴 작업을 끝낼 수 있는가”로 측정하는 task-completion time horizon을 제안한다. 이 관점에서는 단일 문항 정답률보다, 여러 행동을 이어 붙이고 실패를 복구하며 최종 상태를 만드는 능력이 중요해진다.

Loop Engineering에서 가져갈 변화는 다음과 같다.

이전 평가 관점	새 평가 관점	루프 설계 의미
정답 텍스트가 맞는가	실제 task가 끝났는가	final answer보다 outcome check가 중요
단일 호출 성능	여러 step의 trajectory와 recovery	state, retry, observation, verifier가 평가 대상
모델 leaderboard	model + harness + tool + review system leaderboard	모델 교체 전 loop/ACI 차이를 분리해야 함
평균 정답률	task time horizon과 난이도 분포	긴 작업일수록 budget, compaction, rollback이 필수

따라서 코딩 에이전트의 benchmark shift는 Loop Engineering을 선택 사항이 아니라 평가 대상 자체로 만든다. 좋은 루프는 답을 잘 생성하는 것에 그치지 않고, repository를 탐색하고, patch를 적용하고, test feedback을 읽고, 실패를 복구하며, 최종 outcome을 verifier로 입증해야 한다.

미래성은 evaluation axis다. raw source: 2026-07-02-swe-bench, raw source: web-2026-07-02-metr-long-tasks, tracing/eval은 agent가 실제로 무엇을 끝냈고 어떤 증거를 남겼는지 묻는다. 앞으로의 코딩 에이전트 경쟁력은 “더 그럴듯한 답변”보다 완료된 작업, 재현 가능한 trace, 검증 가능한 outcome을 얼마나 안정적으로 남기는가로 갈린다.

18. 루프 시스템의 안티패턴과 해결

루프 시스템의 버그는 일반 코드 버그처럼 명확한 예외로 드러나지 않는 경우가 많다. 더 자주 보이는 증상은 그럴듯하게 잘못된 결과를 내거나, 비용만 태우고 멈추지 않거나, 같은 실패를 무한히 반복하는 것이다. 대부분은 모델 자체의 결함이라기보다 루프 설계의 빈틈에서 온다.

안티패턴	증상	근본 원인	해결
검증기 없는 루프	agent가 “완료”라고 말하는데 결과가 틀림	모델 자기 선언을 종료 조건으로 씀	test/static check/human gate를 종료 조건으로
상태 없는 재시도	같은 실패를 반복	실패 증거가 다음 state에 반영 안 됨	verifier feedback을 state에 append
무한 루프·비용 폭주	멈추지 않고 토큰만 소모	max iteration, timeout, budget 부재	bounded retry + stop reason 기록
Context rot	긴 작업 후 품질 급락, 엉뚱한 참조	오래된·상충·과다 history 누적	compress, select, 격리; compaction 도입
Observation noise	실패 후 모델이 헤맴	raw 로그 전체를 그대로 되돌림	실패 요약, exit code, 핵심 trace만 구조화
권한 과다	의도치 않은 쓰기·삭제·외부 호출	scoped tool, approval gate 부재	least privilege, 고위험 action 승인
Tool-local guardrail 부재	manager agent는 통과했는데 하위 tool이 위험한 side effect 실행	agent-level input/output guardrail만 믿고 tool 호출 지점 검증 생략	side effect tool 옆에 argument/result validation과 approval interruption 배치
Memory/context poisoning	이전 세션·RAG·tool 결과의 악성 지시가 다음 run까지 영향	외부 content를 trusted instruction처럼 저장·재사용	memory 격리, TTL/크기 제한, sanitization, provenance/audit 적용
multi-agent 분산	병합 시 충돌·일관성 붕괴	full trace 미공유, write ownership 불명확	single writer + merge verifier, 또는 trace 공유
캐시 파괴	지연·비용 급증	대화 중 tool 목록·모델·prefix 변경	변경은 새 메시지 append로, prefix 보존

진단의 출발점은 “모델이 왜 그랬을까?”가 아니라 “어떤 state와 observation, verifier 결과가 그 행동을 만들었는가?”여야 한다. 재현 가능한 trace가 없으면 디버깅이 아니라 추측이다.

19. 루프 진단 체크리스트

루프가 이상하게 동작하면 모델을 바꾸기 전에 아래 순서로 좁힌다. 대부분의 문제는 앞의 1~3번에서 잡힌다.

종료 조건 확인. agent의 “done”이 무엇으로 판정되는가? 모델 문장이면 그게 1차 원인이다.
state 반영 확인. 직전 실패 증거가 다음 호출의 context에 실제로 들어갔는가? trace로 확인한다.
예산 경계 확인. max iteration, timeout, cost cap, stop reason이 정의돼 있는가?
observation 형태 확인. 도구 출력이 요약·구조화돼 있는가, raw dump인가?
context 크기 확인. 프롬프트가 비정상적으로 커졌는가? compaction이 필요한 시점인가?
권한 경계 확인. 도구 권한이 작업에 필요한 최소로 좁혀져 있는가?

디버깅에 꼭 남길 trace field는 다음과 같다.

step        n
state_in    {budget, done, last_proof}
action      tool_name, args, scope
observation exit_code, summary, error_kind
proof       verifier_result, failures[]
decision    continue | retry | handoff | stop(reason)

트러블슈팅 원칙: “모델이 왜 그랬을까”로 시작하지 않는다. trace를 펼쳐 어떤 state와 observation, verifier 결과가 그 행동을 만들었는지부터 본다. 재현 가능한 trace가 없으면 디버깅이 아니라 추측이다.

요약 기준

Loop Engineering을 적용할 만한 작업은 보통 다음 성격을 갖는다.

반복적으로 발생한다.
성공/실패를 관찰 가능한 outcome으로 검증할 수 있다.
여러 단계의 상태를 보존해야 한다.
작업자와 검증자를 분리할수록 품질이 좋아진다.
자율성을 단계적으로 키울 수 있고 각 단계의 baseline eval이 있다.
ACI의 file/search, editor, command sandbox, observation shape를 설계할 수 있다.
사람의 직접 프롬프트보다 자동 발견·분류·핸드오프가 더 가치 있다.

반대로 다음 조건에서는 루프를 피하는 편이 낫다.

한 번의 질문 답변으로 충분하다.
검증 가능한 완료 기준이나 outcome check가 없다.
실패 비용이 낮고 품질 증거가 중요하지 않다.
토큰 비용과 지연시간이 더 중요한 제약이다.
max iteration, timeout, cost cap, rollback 기준을 둘 수 없다.
도구 권한과 observation schema를 통제할 수 없다.
실패를 재현할 trace field를 남기지 않는다.
사람이 결과를 읽고 이해할 여유가 없다.

description	Loop Engineering의 가치는 “AI가 코드를 더 빨리 치게 하는 것”보다 넓다.
tags	ai-coding, ai-agents, automation, harness

LLM Wiki

탐색기