루프 엔지니어링이란? AI 에이전트 반복 설계

루프 엔지니어링의 의미

루프 엔지니어링은 AI 에이전트가 실행하는 반복 주기를 설계하는 작업입니다. 무엇이 에이전트를 깨우는지, 에이전트가 무엇에 접근할 수 있는지, 출력 결과를 어떻게 확인하는지, 무엇이 실행을 중지하는지를 정합니다. 프롬프트 엔지니어링은 모델에 보내는 하나의 메시지를 구성합니다. 루프 엔지니어링은 사용자가 잠든 동안 수천 개의 메시지를 보내는 프로세스를 구성합니다. 작업의 단위가 프롬프트에서 루프로 이동합니다.

요약하면, 지침을 작성하는 데서 제어 시스템을 작성하는 것으로 전환합니다. 에이전트에는 여전히 정확한 지침이 필요합니다. 그러나 지침은 일정에 따라 실행되고, 코드의 격리된 복사본에서 작업하며, 테스트로 자체 결과를 검증하고, 예산이 소진되면 실행을 중단하는 주기 내부의 한 구성 요소가 됩니다.

이 용어가 2026년에 등장한 이유

이 명칭은 현재 공개적으로 정착되고 있습니다. GitHub repository cobusgreyling/loop-engineering는 처음 공개된 후 2개월 이내에 별 9,600개를 받았습니다(2026년 7월 기준). repository에는 "Stop prompting. Design the loop. Get a score."라는 문구가 있으며, 이러한 변화를 scheduling, worktrees, skills, plugins and connectors, sub-agents, 그리고 conversation 외부에 보존되는 durable memory라는 6가지 구성 요소로 정리합니다.

Anthropic에서 Claude Code를 이끄는 Boris Cherny의 다음 발언을 인용합니다.

더 이상 Claude에 prompt를 작성하지 않습니다. Claude에 prompt를 작성하는 loop를 실행하고 있습니다.

두 번째 repository인 AI-Builder-Club/skills는 별 1,100개에 가까운 관심을 받고 있으며(2026년 7월 기준), 두 역할을 직접 명시합니다. 하나는 agent가 repository에서 안전하게 테스트와 deploy를 수행할 수 있도록 만드는 "codebase harness"입니다. 다른 하나는 trigger가 발생하면 실행되어 작업을 수행하고, 학습한 내용을 shared file에 기록하여 다음 loop가 읽을 수 있도록 하는 workflow를 구축하는 "loop engineer"입니다.

어느 repository도 이 방식을 처음 만든 것은 아닙니다. nightly build, continuous integration에서 실행되는 linter, 또는 ticket을 생성하는 cron job을 실행해 본 사람이라면 누구나 그 구조를 알고 있습니다. 새로운 점은 이제 loop 내부의 worker가 비결정적이라는 것입니다. 따라서 주변 machinery가 수행해야 하는 작업도 달라집니다.

loop의 4가지 구성 요소

정상적으로 작동하는 모든 loop에는 다음 4가지 구성 요소가 있습니다. 이 중 하나라도 빠진 loop는 새벽 3시에 사용자를 깨웁니다.

• Trigger. 실행을 시작하는 이벤트입니다. timer, webhook, 새 pull request 또는 alert가 해당합니다.
• Boundary. 해당 실행 중 agent가 접근할 수 있는 files, credentials 및 network입니다.
• Verification. exit code를 반환하는 검사입니다. 이 검사 결과에 따라 실행 결과를 유지하거나 폐기합니다.
• Budget. 실행 성공 여부와 관계없이 실행을 종료하는 token, time 및 money 제한입니다.

이 4가지를 질문 형태로 다시 읽으면, 계속 실행 상태로 둘 agent에 대한 설계 검토 항목이 됩니다.

트리거: 에이전트를 실행하는 조건

타이머는 가장 단순한 트리거입니다. Linux 서버에서는 로그를 기록하고, 원하는 방식으로 재시도하며, 아직 실행 중인 유닛의 두 번째 복사본을 시작하지 않으므로 systemd timer가 cron보다 적합합니다. 이 마지막 특성은 에이전트 루프에서 가장 흔한 중복 실행 버그를 제거합니다. 두 실행이 동일한 브랜치를 동시에 수정하는 문제입니다.

유닛을 /etc/systemd/system/agent-loop.service에 작성합니다.

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

타이머를 /etc/systemd/system/agent-loop.timer에 작성합니다.

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers에는 미래 시각이 표시되는 NEXT 열과 남은 시간을 카운트다운하는 LEFT 열이 표시되어야 합니다. 결과가 비어 있으면 타이머가 활성화되지 않은 것입니다. enable을 --now 없이 사용하면 다음 부팅 시에만 타이머가 예약되기 때문입니다. TimeoutStartSec=1800도 생각보다 중요합니다. 입력을 기다리느라 멈춘 에이전트가 유닛을 영원히 active 상태로 유지할 수 있으며, 그러면 타이머가 다시 실행되지 않습니다. journalctl -u agent-loop.service -n 50으로 실행 기록을 확인합니다.

대신 cron으로 루프를 실행한다면 직접 중복 실행 방지 기능을 추가해야 합니다. cron은 두 번째 복사본을 그대로 시작하기 때문입니다.

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

잠금이 설정되어 있으면 flock -n이 status 1로 즉시 종료됩니다. 따라서 두 번째 실행은 첫 번째 실행과 경쟁하지 않고 조용히 종료됩니다. 동일한 systemd 서비스 및 타이머 설정을 에이전트인지 여부와 관계없이 서버의 모든 장기 실행 작업에 적용할 수 있습니다.

경계: 각 실행에 고유한 복사본 제공

작업 트리를 편집하는 에이전트는 커밋하지 않은 작업을 잃을 수 있는 에이전트입니다. Git worktree를 사용하면 이 작업을 저렴하게 격리할 수 있습니다. 각 실행에는 자체 디렉터리와 자체 브랜치가 할당되고, object store는 공유합니다.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list은 각 트리의 경로, 커밋 및 브랜치를 한 줄씩 출력합니다. 실행이 끝나면 git worktree remove /srv/agent/work/triage-01이 디렉터리를 삭제하고, git worktree prune이 디렉터리가 사라진 항목을 정리합니다. 이 시점부터 병렬 루프를 안전하게 실행할 수 있습니다. 서로 다른 2개의 디렉터리에서 서로 다른 2개의 브랜치를 사용하는 2개의 에이전트가 서로의 작업을 덮어쓸 수 없기 때문입니다.

이 경계는 자격 증명에도 적용됩니다. 자동으로 실행되는 루프는 장기간 유효한 토큰을 보유하며, 각 실행에서 토큰이 로그, 커밋 또는 모델 컨텍스트에 유출될 수 있습니다. 토큰의 권한 범위를 루프가 접근하는 하나의 repository로 제한하십시오. 가능하면 에이전트 자체의 shell이 볼 수 있는 환경에서 토큰을 제외하십시오. 루프에 production 접근 권한을 부여하기 전에 AI agents에서 secrets를 제외하는 방법을 읽으십시오. 더 강력한 격리가 필요하면 전체 루프를 각 실행 후 삭제할 수 있는 disposable VM에서 실행하십시오.

검증: 루프를 안전하게 만드는 게이트

이 부분이 루프와 명령을 입력하는 cron 작업을 구분합니다. 에이전트의 출력은 제안입니다. 게이트가 이를 결정합니다.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail은 해당 스크립트에서 실제로 중요한 작업을 수행합니다. -e이 없으면 실패한 git fetch을 무시하고 오래된 origin/main을 대상으로 실행을 계속합니다. -u이 없으면 변수 이름의 오타가 빈 문자열로 확장됩니다. 그러면 정리 작업이 즉시 실패하지 않고 잘못된 경로를 대상으로 실행됩니다.

if ! npm test 블록이 전체 개념을 담고 있습니다. 이미 신뢰하는 검사의 종료 코드, 즉 테스트 모음 또는 type checker가 해당 브랜치를 push할지 삭제할지를 결정합니다. 게이트가 없는 루프는 검토할 시간이 없는 작업을 생성합니다. 이는 작업을 전혀 하지 않는 것보다 나쁩니다. 게이트가 있는 루프는 사람 기여자의 브랜치가 통과해야 하는 것과 동일한 기준을 이미 통과한 브랜치를 생성합니다.

정직하게 실패하는 게이트를 선택합니다. 빈 diff에서도 통과하는 테스트 모음은 아무 작업도 하지 않는 것이 성공이라고 루프에 학습시킵니다. 테스트가 부실한 repository에서는 루프도 부실해집니다. 따라서 인기 repository에서는 "루프 작성"보다 먼저 "codebase를 agent-ready 상태로 만들기"를 우선합니다.

예산: 실행을 중단하는 조건

무한히 재시도하는 에이전트는 비용이 무제한으로 증가하는 에이전트입니다. 모든 루프에 wall-clock 제한을 설정하고 TimeoutStartSec를 통해 이를 적용합니다. 스크립트 내부에는 재시도 횟수를 설정하고, provider 계정에서는 지출 한도를 적용합니다. 그런 다음 각 실행에 발생한 비용을 기록합니다. 이렇게 하면 청구서에 나타나기 전에 루프의 비용 증가를 확인할 수 있습니다. 항상 실행되는 에이전트 VPS의 비용 관리에서는 회계 측면을 다루고, 턴 사이에 에이전트가 유지하는 컨텍스트 관리에서는 실행당 비용에 가장 큰 영향을 주는 요소를 다룹니다. 30분마다 동일한 repository를 다시 읽는 루프는 30분마다 그 비용을 지불하기 때문입니다.

비용 때문에 루프가 일반적으로 하나의 긴 세션보다 효율적입니다. 새로 시작하여 하나의 좁은 작업을 수행한 후 종료하는 실행은 컨텍스트를 작게 유지합니다. 8시간 동안 열린 세션은 이전의 모든 오류를 기록에 계속 포함하며, 매 턴마다 전체 transcript에 대한 비용을 지불하게 합니다.

인기 저장소에서 정형화한 패턴

loop-engineering 저장소에는 프로덕션 환경에서 사용하는 7가지 패턴이 정리되어 있습니다. 이 패턴들은 선언문이 아니라 메뉴처럼 읽을 가치가 있습니다. 일일 분류 작업, 검토 의견을 감시하고 응답하는 pull request 관리 작업, 실패한 빌드를 처리하는 지속적 통합 정리 작업, 종속성 정리 작업, 변경 로그 초안 작성 작업, 병합 후 정리 작업, 이슈 분류 작업입니다.

이 패턴들의 공통점은 범위가 좁고 명확한 통과 조건이 있다는 점입니다. "실패한 빌드 수정"에는 시스템이 읽을 수 있는 통과 조건이 있습니다. 반면 "코드베이스 개선"에는 그런 조건이 없습니다. 따라서 루프가 되지 않습니다. 일정에 따라 실행되는 혼란스러운 작업이 될 뿐입니다.

또한 이 패턴들은 모두 기록을 남깁니다. 두 저장소 모두 대화 밖으로 상태를 내보내 저장소의 파일에 기록합니다. 무엇을 실행했는지, 무엇을 발견했는지, 무엇을 결정했는지를 기록합니다. 이 파일은 루프의 메모리입니다. 따라서 두 번째 루프는 첫 번째 루프의 작업을 다시 찾지 않고 그 결과를 기반으로 작업할 수 있습니다. 실행이 종료되는 순간 모델의 컨텍스트가 사라지므로, 이 기록은 사후에 에이전트를 감사하는 방법이기도 합니다.

루프가 실패하는 경우

실패 원인은 단순하며, 여러 팀에서 반복됩니다.

• 게이트가 없습니다. 출력이 누적되고 아무도 검토하지 않으며 신뢰가 무너져 루프를 중지합니다.
• 중복 실행이 발생합니다. 하나의 브랜치에서 2개의 실행이 진행되거나 하나의 working tree에서 2개의 에이전트가 작업하여 충돌이 발생합니다. 그러면 에이전트가 충돌을 해결하려고 시도합니다.
• 조용히 변질됩니다. 검사가 실패를 감지할 만큼 강력하지 않아서 루프가 계속 통과합니다.
• 범위가 제한되지 않습니다. 사용량이 많은 repository에서 모든 커밋마다 실행되는 트리거는 하루 안에 비용 문제로 이어집니다.

각 문제의 해결 방법은 같습니다. 작업을 줄이고, 검사를 엄격하게 만들고, 실행을 기록합니다. 통과 조건을 한 문장으로 설명할 수 없다면 해당 작업은 아직 자동화할 준비가 되지 않은 것입니다.

용어 없이 시작하기

프레임워크는 필요하지 않습니다. 항상 켜져 있는 소형 Linux 서버, 필요할 때 테스트 모음이 실패하는 git repository, systemd timer 1개, 그리고 if이 포함된 shell script 1개면 전체 순환 구조를 만들 수 있습니다. 대부분의 사용자는 실제로 이것부터 시작하는 것이 좋습니다. 설계에 관한 질문은 도구를 선택하는 과정이 아니라 시스템을 실행하는 과정에서 답을 얻기 때문입니다. 하나의 순환 구조가 안정되면 두 번째 구조를 실행하는 일은 대체로 timer 1개와 worktree 1개를 추가하는 것뿐입니다. 기본 설정은 VPS에서 coding AI agent를 실행하는 방법을 참조하십시오. 직접 제어하는 hardware에서 agent 자체를 실행하려면 현재 사용할 수 있는 self-hosted AI agent 옵션을 참조하십시오.

FAQ

루프 엔지니어링은 프롬프트 엔지니어링과 다른가?

프롬프트 엔지니어링은 문구, 예시, 출력 형식 등 하나의 메시지를 최적화합니다. 루프 엔지니어링은 메시지를 둘러싼 주기를 최적화합니다. 여기에는 실행을 시작하는 트리거, 실행 환경인 샌드박스, 출력을 승인하거나 거부하는 검사, 실행을 종료하는 예산이 포함됩니다. 루프 안에서도 좋은 프롬프트가 필요합니다. 그러나 게이트와 트리거가 결과에 더 큰 영향을 주므로, 프롬프트는 더 이상 매일 조정하는 핵심 요소가 아닙니다.

에이전트 루프를 구축하려면 프레임워크가 필요한가?

아닙니다. systemd timer, 실행마다 사용하는 git worktree, 테스트 명령으로 끝나는 shell script, provider account의 지출 한도만으로 정의에 포함된 모든 요소를 처리할 수 있습니다. 프레임워크는 scheduling interface, shared memory format, multi-agent routing을 추가합니다. 이러한 기능은 여러 루프를 실행할 때 유용합니다. 하지만 첫 번째 루프를 시작하는 데 프레임워크가 필수는 아닙니다.

codebase harness란 무엇인가?

사람이 직접 개입하지 않아도 에이전트가 repository에서 작업할 수 있게 하는 요소의 집합입니다. 여기에는 한 번의 명령으로 실행되는 setup, 비대화형으로 실행되며 오류를 명확히 보고하는 test, linter, 변경 사항을 deploy하거나 preview하는 방법이 포함됩니다. 이 용어는 loop engineering과 같은 2026년 repository 흐름에서 등장했습니다. 실용적인 판단 기준은 간단합니다. 새로운 human contributor가 한 번의 명령으로 clone부터 green test까지 진행할 수 없다면, 에이전트도 그렇게 할 수 없습니다.

에이전트 루프가 큰 비용을 발생시키지 않게 하려면 어떻게 해야 하는가?

3곳에서 한도를 설정합니다. systemd unit에 TimeoutStartSec을 설정하여 멈춘 실행을 종료합니다. 성공할 때까지 반복하지 말고 script 내부에서 retry 횟수를 제한합니다. API account에 hard spend limit을 설정합니다. 에이전트가 이 한도를 우회하도록 설득할 수 없게 만드는 유일한 상한이기 때문입니다. 그런 다음 실행별 비용을 기록합니다. 비용이 2배로 증가하는 루프는 대개 범위가 조용히 확장된 루프입니다.

어떤 작업을 먼저 루프로 전환할 가치가 있는가?

기계가 읽을 수 있는 통과 조건이 있고 영향 범위가 작은 작업을 선택합니다. 실패한 build 수정, dependency 업데이트, changelog 재생성은 모두 적합합니다. test suite 또는 diff로 결과를 검증할 수 있기 때문입니다. refactoring이나 design처럼 개방형인 작업은 아직 적합하지 않습니다. 게이트가 확인할 대상이 없기 때문입니다. 게이트 없는 루프는 review debt를 생성하는 비용이 큰 방법일 뿐입니다.