루프 엔지니어링에는 표준 정의가 없고, 공통분모는 종료 조건입니다

1. 핵심 요약

공개 저장소를 조사한 논문에서는 트리거(실행을 시작하는 일정이나 이벤트)를 담은 GitHub Actions 워크플로 같은 루프 설정은 저장소에 남았지만, 실무 글이 권하는 상태 파일·예산 파일·검증 에이전트 정의는 사실상 커밋되지 않았습니다. 논문은 이를 “루프의 실행 중 상태가 버전 관리 밖에 있다”고 정리했습니다. [1]

수치는 모두 논문 원문에 나온 값입니다. 217곳은 저자들이 휴리스틱으로 찾은 후보 256곳을 직접 확인한 결과이며, 공개 저장소 전체의 도입률이 아닙니다. 조건은 6절과 8절에 적었습니다.

2. 용어 — 루프가 세 가지를 가리킵니다

‘루프’라는 말이 서로 다른 세 가지를 가리켜 혼동이 생깁니다. Macedo의 논문은 이 셋을 구분하라고 적었습니다. [2]

에이전트 루프는 Claude Code 공식 문서가 “맥락 수집 → 행동 → 결과 확인”의 세 단계를 반복한다고 설명하는 그것입니다. Agent SDK 문서는 도구 호출과 결과 처리 한 번을 턴이라 부르고, 모델이 도구 호출 없이 답하면 루프가 끝난다고 적었습니다. [3] [4]

하네스(harness)는 모델을 감싸고 도구를 제공하며 모델이 볼 맥락을 관리하는 소프트웨어 층입니다. Claude Code 문서는 Claude Code 자체를 이 층으로 설명합니다. [3] Lulla 등의 논문은 개발자가 에이전트를 다루는 방식을 네 층으로 정리했고, 루프 엔지니어링을 하네스보다 한 층 위에 두었습니다. [1]

출처: Lulla 등 [1]의 표 1. 각 층이 아래 층을 포함한다고 저자들이 적었습니다.

이 글에서 트리거는 실행을 시작하는 일정이나, PR 생성 같은 저장소 이벤트입니다. 종료 조건은 “이 상태가 되면 실행을 끝낸다”고 미리 적어 둔 조건입니다. 예를 들어 “npm test가 0으로 끝나고 다른 테스트 파일은 바꾸지 않았다”입니다. 종료 상태는 실행이 끝났을 때 붙이는 이름으로, 성공·할 일 없음·막힘·진전 없음·예산 소진처럼 구분합니다. [2]

3. 용어는 어디서 나왔나

Lulla 등은 이 용어가 2026년 6월 초 며칠 사이에 나온 세 가지 발언에서 시작됐다고 정리했습니다. 아래 인용은 이 글이 논문에서 옮긴 것이며, Osmani의 글만 원문을 직접 확인했습니다. [1]

Osmani의 글은 루프에 필요한 요소로 자동 실행, 작업 트리(worktree), 스킬, 플러그인·커넥터, 하위 에이전트, 그리고 디스크에 남는 기억을 꼽았습니다. “에이전트는 잊어도 저장소는 잊지 않는다”는 문장으로 상태를 대화 밖 파일에 두라고 권했습니다. 같은 글에서 그는 검증 에이전트를 따로 두어도 “끝났다”는 말은 주장이지 증명이 아니라고 적었습니다. [5]

새로운 개념이냐는 데에는 반론이 많았습니다. 논문이 정리한 실무자 반응에는 “이름만 바꾼 크론 작업”이라는 평가가 있었고, The Pragmatic Engineer의 Gergely Orosz는 약 210건의 답변을 모은 결과 구체적 사례 대부분이 크론 작업과 이벤트 트리거 두 가지였다고 정리했습니다. 논문은 이 용어가 새 분야인지, 과도기 기법인지, 마케팅 용어인지 아직 정리되지 않았다고 결론지었습니다. [1]

두 논문이 세운 정의는 이렇습니다.

• Lulla 등의 작업 정의 — 일정이나 이벤트로 코딩 에이전트를 반복 호출하고, 각 실행을 기계가 확인할 수 있는 종료 조건으로 묶는 자동 제어 구조를 설계하는 일. 잘 만든 루프는 실행 사이에 상태를 남기고, 구현 에이전트와 별개로 결과를 검증하고, 추론 비용에 상한을 두고, 무인 실행이 승인 없이 바꿀 수 있는 범위를 제한하고, 사람이 개입할 시점을 정합니다. [1]
• Macedo의 정의 — 사람이 설계해 하네스에 넘기는 ‘루프 명세’를 설계·평가하는 일. 명세는 다섯 부분으로 이뤄집니다. 트리거, 확인 가능한 목표, 실행, 검증, 그리고 실행을 이름 붙은 종료 상태로 끝내는 종료 규칙입니다. 여기에 대화가 아니라 디스크에 남는 기억이 더해집니다. [2]

표현은 다르지만 둘 다 종료 조건과 검증을 정의 안에 넣었습니다. 구현 에이전트와 독립된 검증까지 정의에 넣은 것은 Lulla 등이고, Macedo는 작업자와 확인자를 나누는 구조를 정의 밖의 설계 원칙으로 다뤘습니다. 이 글의 제목은 두 정의의 공통분모인 종료 조건을 가리킵니다.

4. 도구가 문서로 제공하는 것

Claude Code와 Codex는 2026년 상반기에 ‘목표 조건이 충족될 때까지 계속 작업하는’ 명령을 공식 기능으로 추가했습니다. Claude Code의 주간 변경 기록은 /goal을 2026년 5월 11~15일 주에 소개했고, OpenAI 쿡북은 Codex Goals가 Codex 0.128.0부터 제공된다고 적었습니다. 아래는 2026-10-06에 확인한 Claude Code 공식 문서와, Codex Goals를 설명한 OpenAI 쿡북의 내용입니다. [6] [9]

출처: Claude Code 문서 /goal [6], /loop [7], 훅 가이드 [8], Agent SDK 에이전트 루프 [4], OpenAI 쿡북 “Using Goals in Codex” [9]. Codex 쪽은 공식 레퍼런스가 아니라 OpenAI 직원이 쓴 쿡북 문서입니다.

Claude Code /goal의 평가자는 명령을 실행하거나 파일을 읽지 않습니다

Claude Code 문서에 따르면 /goal은 세션 범위의 프롬프트 기반 Stop 훅을 감싼 기능입니다. 턴이 끝날 때마다 조건과 지금까지의 대화를 소형 모델에 보내고, 소형 모델은 “아직 아님 / 충족 / 불가능” 중 하나와 짧은 이유를 반환합니다. 문서는 이 평가자가 명령을 실행하거나 파일을 읽지 않고, Claude가 대화에 드러낸 내용만으로 판단한다고 명시합니다. 그래서 조건을 “Claude의 출력으로 보여 줄 수 있는 것”으로 쓰라고 권합니다. 예를 들어 “npm test가 0으로 끝난다”처럼 측정 가능한 끝 상태 하나, 확인 방법, 바뀌면 안 되는 것을 적습니다. [6]

문서가 밝힌 다른 제약도 있습니다. 조건은 4,000자까지 쓸 수 있고, 실행 시간을 제한하려면 “또는 20턴 후 중단” 같은 절을 조건에 넣으라고 안내합니다. Claude가 도구를 쓰지 않은 채 평가자의 판정에 응답만 하는 턴이 여러 번 이어지면, Claude Code는 루프를 멈추고 사용자에게 제어를 넘깁니다. /goal은 권한 모드를 바꾸지 않으므로, 수동 모드에서는 허용되지 않은 도구 호출마다 여전히 확인을 요청합니다. [6]

Codex Goals는 예산 소진을 완료로 보지 않습니다

OpenAI 쿡북은 Goal을 스레드 범위의 “완료 계약”이라고 부릅니다. 무엇이 참이어야 하는지, 어떻게 확인하는지, 무엇을 지켜야 하는지를 담습니다. Goal의 상태는 활성·일시 정지·완료·예산 제한 중 하나이며, 모델은 증거가 뒷받침할 때만 완료로 표시할 수 있고 일시 정지·재개·삭제·예산 제한 전환은 사용자나 시스템이 맡는다고 적었습니다. 쿡북은 예산을 다 쓴 것은 목표를 완료한 것과 같지 않다고 명시하고, 그때는 진행 상황과 막힌 점을 요약하라고 안내합니다. “더 좋게 만들어 줘”처럼 끝이 모호한 일에는 Goal을 쓰지 말라는 것도 같은 문서의 권고입니다. [9]

멈춤 장치는 문서에 숫자로 적혀 있습니다

• Stop 훅 연속 차단 상한: Stop 훅이 Claude의 도구 호출 없이 8번 연속으로 종료를 막으면 Claude Code가 훅을 무시합니다. 문서는 입력의 stop_hook_active 값을 확인해 이미 계속 실행을 한 번 요청했다면 바로 끝내라고 안내합니다. [8]
• 반복 작업 7일 만료: /loop와 크론 도구로 만든 반복 작업은 생성 7일 뒤 마지막으로 한 번 실행되고 삭제됩니다. 문서는 이를 “잊힌 루프가 실행될 수 있는 기간을 제한하는 장치”라고 설명합니다. 이 작업은 세션 범위라 Claude Code가 켜져 있고 유휴 상태일 때만 실행됩니다. [7]
• SDK 기본값은 제한 없음: Agent SDK의 max_turns와 max_budget_usd는 기본값이 둘 다 제한 없음이고, 한도에 걸리면 error_max_turns·error_max_budget_usd 결과를 반환합니다. 문서는 운영용 에이전트에는 예산을 설정하는 것을 기본으로 권합니다. [4]

이 설계는 Anthropic이 2024-12-19 “Building effective agents”에서 적은 원칙과 같은 방향입니다. 그 글은 에이전트가 각 단계에서 도구 호출 결과나 코드 실행 같은 환경의 실제 결과로 진행을 판단해야 하고, 통제를 위해 최대 반복 횟수 같은 종료 조건을 두는 것이 흔하다고 적었습니다. 이 글에는 이후 도구 환경이 많이 바뀌었다는 안내가 붙어 있습니다. [10]

5. 완료를 누가, 무엇으로 확인하나

Macedo는 검증의 엄밀함을 다섯 단계로 나눴습니다. 이 글은 이 구분을 루프를 설계할 때 “지금 내 검증이 어느 단계인가”를 묻는 기준으로 씁니다. [2]

Macedo가 공개 루프 모음 한 곳(Loop Library)의 루프 50개를 직접 분류한 결과, 74%가 종료 상태에 이름을 붙였고, 70%가 1~2단계로 확인했으며, 66%가 확인 가능한 목표를 세웠습니다. 반면 트리거를 자동화한 루프는 22%(일정 12%, 이벤트 10%)였고, 78%는 사람이 직접 시작했습니다. 모델 판정을 주된 검증으로 쓴 루프는 11개(22%)였고, 대부분 작업 모델과 판정 모델을 나누거나 별도 비평자를 두었습니다. 저자는 이를 두고 “끝났는지 아는 문제”는 “사람 없이 실행하는 문제”보다 훨씬 많이 풀렸다고 해석했습니다. [2]

같은 논문은 피해야 할 설계를 다섯 가지로 정리했습니다. 이 가운데 루프 설계에 바로 쓰이는 것은 셋입니다.

• 스스로 승인하는 루프: 같은 모델이 만들고 채점하면 점수는 오르는데 품질은 오르지 않을 수 있습니다. 작업자와 확인자를 나누고, 자기 채점보다 1~2단계 확인을 쓰라고 권합니다. 채점 기준과 실행 기록의 권한을 나누는 문제는 에이전트 보상 해킹 리포트에서 다뤘습니다.
• 모델 판정을 결정적 확인처럼 보고: 실제로는 모델의 의견에 기대면서 결정적 확인처럼 높은 확신을 보고하는 경우입니다. 검증이 실제로 몇 단계인지 밝히라고 권합니다.
• 감시 없는 폭주: 작업과 관련된 종료 규칙, 진전 없음 감지, 예산 상한이 모두 없는 루프입니다. 이름 붙은 종료 상태, 진전 없음 감지, 예산 상한을 두고, 되돌릴 수 없는 행동은 사람 승인을 거치라고 권합니다.

Macedo는 루프가 맞지 않는 경우도 적었습니다. 새 피드백이 와도 다음 행동이 바뀌지 않는 일이라면 한 번 실행(필요하면 예약 실행)으로 충분하고, 재현 가능한 확인 방법이 없는 취향의 문제나 방향 자체를 모르는 신규 구축, 반복 비용을 회수하지 못하는 일에도 루프가 맞지 않는다고 봤습니다. [2]

6. 공개 저장소에서 확인된 루프

Lulla 등은 기존 AI 설정 데이터셋에서 ‘소프트웨어 프로젝트’로 분류된 저장소 36,710곳을 대상으로 2026-08-19에 한 번 스캔했습니다. GitHub에서 사라진 65곳을 빼면 36,645곳입니다. Claude Code, Codex, Copilot, Cursor, Gemini CLI, OpenCode, Hermes, OpenClaw 여덟 도구가 일정이나 이벤트로 실행되는 흔적을 찾았습니다. [1]

출처: Lulla 등 [1]의 표 2 가운데 일부 행. 분모는 스캔한 36,645곳입니다. ‘탐지가 맞았던 저장소’는 직접 확인에서 해당 장치가 규칙이 가리킨 그 장치로 판정된 수이며, 자율 실행이 실제로 일어났는지는 따로 판정했습니다. 그 결과가 아래 217곳이므로 242와 217은 서로 다른 기준의 값입니다. 상태 파일 2개는 직접 확인에서 루프와 무관한 같은 이름의 파일로 판정됐습니다. 종료 조건 0은 고정된 문구 목록이 하나도 맞지 않았다는 뜻이며, 저자들이 직접 살핀 256곳 중 55곳에서는 목표·종료 조건 장치가 기록됐고, 그중 여럿은 커밋된 프롬프트 안의 종료 상태나 재시도 상한 형태였습니다.

휴리스틱이 걸러 낸 256곳을 하나씩 확인한 결과, 217곳에서 자율 에이전트 실행이 실제로 있었습니다. 스캔 대상의 0.59%입니다. 33곳은 확인되지 않았고 6곳은 판정하지 못했습니다. 217곳 가운데 180곳은 저장소 이벤트로만 실행됐고 대부분 새 PR을 자동 리뷰하는 용도였습니다. 일정으로만 실행된 곳은 21곳, 둘 다 쓴 곳은 15곳, 워크플로가 고장 나 멈춘 곳이 1곳이었습니다. 도구별로는 Claude Code가 189곳, Codex 11곳, OpenCode 6곳, Gemini CLI 5곳, Cursor 4곳, Copilot 2곳이었습니다. [1]

저자들은 상태 파일이 없는 이유를 이렇게 해석했습니다. PR 리뷰 실행은 PR을 읽고 리뷰를 남긴 뒤 끝나고, 다음 실행은 다음 PR에서 새로 시작하므로 남길 상태가 없습니다. 일정 실행은 주로 이슈 분류였고, 이슈 트래커가 실행 사이의 할 일 목록을 이미 들고 있었습니다. 즉 “상태 파일을 커밋하라”는 실무 글의 권고가 지금 공개 저장소의 흔한 루프에는 해당되지 않는 경우가 많았다는 것입니다. [1]

성공으로 끝난 실행이 일을 했다는 증거는 아닙니다

논문이 든 사례에서 AI-Hypercomputer/xpk 저장소의 매시간 Gemini 이슈 분류 워크플로는 6,290회 실행됐지만, 대상 이슈 검색이 아무것도 찾지 못해 에이전트는 한 번도 실행되지 않았습니다. GitHub 실행 기록은 성공·실패만 보여 주고, 에이전트가 실제로 실행됐는지는 작업·단계 기록을 봐야 알 수 있었습니다. 저자들은 루프를 운영하는 팀에 세 가지를 권했습니다. [1]

• 할 일이 없으면 성공 대신 “할 일 없음”으로 보고합니다.
• 에이전트 단계가 얼마나 오래 실행됐는지 기록합니다.
• 각 실행이 무엇을 만들었는지(PR, 댓글, 커밋) 기록합니다.

재시도가 여러 층에서 겹칠 때 실제 호출 수와 중복 실행을 따지는 방법은 에이전트 재시도 설계 리포트에서 다뤘습니다.

7. 루프를 만들기 전 체크리스트

아래는 위 문서와 논문에서 끌어낸 이 글의 권고입니다. 각 항목의 효과를 측정한 연구는 이 글이 확인한 범위에서 없습니다.

• 루프가 필요한 일인지 먼저 봅니다. 결과를 보고 다음 행동이 바뀌지 않는 일이라면 예약 실행 한 번으로 충분합니다. [2]
• 종료 조건을 명령의 실행 결과로 씁니다. “npm test가 0으로 끝난다”처럼 확인 방법과, 바뀌면 안 되는 것을 함께 적습니다. Claude Code /goal의 평가자는 대화에 드러난 출력만 봅니다. [6]
• 완료를 판정하는 주체를 적습니다. 작업한 모델인지, 다른 모델인지, 테스트 같은 결정적 확인인지 정하고, 그 확인이 몇 단계인지 그대로 보고합니다. [2]
• 횟수와 비용 상한을 둡니다. SDK의 max_turns·max_budget_usd는 기본값이 제한 없음입니다. /goal에는 “또는 20턴 후 중단” 같은 절을 넣습니다. [4] [6]
• 종료 상태에 이름을 붙입니다. 성공·할 일 없음·막힘·진전 없음·예산 소진을 구분하고, 오류와 예산 소진을 성공으로 세지 않습니다. [2] [9]
• 실행이 실제로 일했는지 기록합니다. “할 일 없음” 보고, 에이전트 단계 실행 시간, 만든 산출물을 남깁니다. [1]
• 되돌릴 수 없는 작업에는 사람 승인을 둡니다. 그리고 그 승인을 할 사람이 루프가 만드는 PR 양을 감당할 수 있는지 확인합니다. 논문이 옮긴 실무자 반응에는 야간 실행이 연 PR이 검토 능력을 넘어 사람 승인이 형식만 남는다는 지적이 있었습니다. [1]

8. 아직 결론이 아닌 것

• 이 글은 2026-06-16 초기 노트를 다시 쓴 것입니다. 초기 노트는 실무자·개발사 블로그와 제품 문서를 바탕으로 여섯 요소 구조, 팀 도입 단계, 지표, 템플릿을 제시했지만, 수치와 주장마다 출처를 붙이지 않았습니다. 2026-10-06에 원문을 다시 대조하면서 확인되지 않는 주장과 근거를 다시 확인하지 않은 논문 인용 세 편, 직접 만든 템플릿을 뺐습니다.
• 자체 측정은 없습니다. /goal, /loop, Codex Goals를 이 글에서 직접 실행해 비교하지 않았습니다. 4절은 Claude Code 공식 문서와 OpenAI 쿡북의 설명입니다.
• 루프의 효과를 보여 주는 체계적 근거는 아직 없습니다. Lulla 등은 Stripe의 주당 약 1,300건 에이전트 PR이나 Firefox에 루프를 적용해 한 달에 보안 수정 423건을 냈다는 주장이 팟캐스트 인터뷰와 SNS 게시물에서 나온 자기 보고이며, 이를 뒷받침하는 연구나 데이터셋은 알지 못한다고 적었습니다. 이 글도 이 수치를 검증하지 않았습니다. 저자들의 통제 실험(대화형 사용, 목표 기반 실행, 예약 루프 비교)은 계획 단계입니다.
• 저장소 조사의 범위가 좁습니다. Lulla 등의 논문은 심사 중인 워크숍 논문입니다. 256곳의 판정은 LLM이 먼저 붙이고 저자 한 명이 최종 판정했으며, 독립된 두 명의 판정 일치도는 내지 않았습니다. 스캔은 용어가 생긴 지 약 10주 뒤 한 번이었고, 2026년 3월에 고정된 공개 저장소 목록만 봤습니다. 세션 안에서 실행한 /loop·/goal, 비공개 저장소, 플랫폼 자체 스케줄러는 흔적이 남지 않아 세지 못했습니다. 217곳은 실제 도입을 적게 잡은 값일 수 있습니다.
• Macedo의 수치는 공개 모음 한 곳의 50개 루프입니다. 단독 저자의 입장 논문이고, 분류도 저자 한 명이 했습니다. 무작위 표본이 아니며, 저자는 백분율에서 인과 결론을 끌어내지 않는다고 적었습니다. 설계 원칙 다수는 에이전트 루프 안쪽을 연구한 결과를 바깥 루프에 유추한 것이라고 저자 스스로 밝혔습니다.
• 도구 문서는 빠르게 바뀝니다. 4절은 2026-10-06 온라인 문서 기준입니다. Claude Code 문서는 일부 동작이 v2.1.234·v2.1.239·v2.1.246·v2.1.269 같은 버전부터라고 적고 있어, 설치한 버전에서는 다를 수 있습니다. Codex 쪽은 공식 레퍼런스가 아니라 쿡북 문서를 근거로 했습니다.
• 용어 자체가 오래가지 않을 수 있습니다. 논문이 옮긴 실무자 의견에는 /loop·/goal이 기본 기능이 되면서 일반 소프트웨어 개발자에게는 이 용어가 이미 쓸모를 잃어 가고 있다는 평가가 있었고, 2026년 7월에는 ‘그래프 엔지니어링’이라는 다음 용어도 나왔습니다. 다만 저자들은 비결정적인 작업자를 검증·예산·에스컬레이션으로 묶는 설계 문제는 이름과 관계없이 남는다고 봤습니다. [1]

9. 참고자료

모두 2026-10-06에 원문을 확인했습니다. 논문 두 편은 arXiv의 LaTeX 원본을 받아 표와 한계 절을 대조했습니다. Cherny·Steinberger·Orosz 등의 발언은 Lulla 등 [1]이 옮긴 것을 다시 인용했으며 원 게시물은 직접 열지 않았습니다.

2026-06-16 초기 노트를 2026-10-06에 현재 기준으로 다시 썼습니다. 초기 노트가 인용한 Kilo·Langfuse 글과 arXiv 2605.23135·2603.16975·2606.08793은 이번 판의 근거로 쓰지 않았습니다. 논문이 개정되거나 도구 문서가 바뀌어 내용이 달라지면 이 글을 고치고 개정 날짜를 적겠습니다.