루프 엔지니어링이란 무엇인가? AI 에이전트 설계의 핵심

루프 엔지니어링의 의미

루프 엔지니어링은 AI 에이전트가 실행되는 반복 주기를 설계하는 작업입니다. 여기에는 에이전트를 깨우는 조건, 접근 가능한 범위, 출력 검증 방식, 그리고 종료 조건이 포함됩니다. 프롬프트 엔지니어링이 모델에 전달할 하나의 메시지를 다듬는 작업이라면, 루프 엔지니어링은 사용자가 잠든 사이에도 수천 개의 메시지를 주고받는 프로세스를 설계하는 작업입니다. 즉, 작업의 단위가 프롬프트에서 루프로 이동하는 것입니다.

요약하자면, 지시사항을 작성하는 단계에서 벗어나 제어 시스템을 구축하는 단계로 나아가는 것입니다. 에이전트에게 여전히 좋은 지시사항이 필요하지만, 이는 이제 정해진 일정에 따라 실행되고, 격리된 코드 사본에서 작동하며, 테스트를 통해 스스로 결과를 증명하고, 예산이 소진되면 작업을 중단하는 순환 구조의 일부가 됩니다.

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

이 명칭은 현재 공개적으로 정착되고 있다. GitHub 저장소 cobusgreyling/loop-engineering는 처음 공개된 뒤 2개월 안에 별 9,600개를 넘겼고(2026년 7월 기준), "Stop prompting. Design the loop. Get a score."라는 문구 아래 2026-10-27에는 약 11,600개를 기록했다. 2026년 7월 README는 이러한 변화를 6가지 구성 요소로 분류했다. scheduling, worktrees, skills, plugins and connectors, sub-agents, 그리고 대화 외부에 유지되는 durable memory다. 현재 README에는 이 목록이 더 이상 없지만(2026-10-27 확인), 여전히 대화 외부의 파일에 loop의 상태를 저장한다.

이 저장소는 Anthropic에서 Claude Code를 이끄는 Boris Cherny를 영감의 원천 중 한 명으로 소개한다. 널리 알려진 그의 발언은 다음과 같다.

I don't prompt Claude anymore. I have loops running that prompt Claude.

두 번째 저장소인 AI-Builder-Club/skills는 별 1,300개에 가까운 관심을 받고 있으며(2026-10-27 기준), 두 역할을 직접 명시한다. 하나는 에이전트가 저장소에서 테스트와 배포를 안전하게 실행하도록 만드는 "codebase harness"이고, 다른 하나는 트리거가 발생하면 실행되어 작업을 수행하고 배운 내용을 공유 파일에 기록해 다음 loop가 읽을 수 있도록 workflow를 구축하는 "loop engineer"다.

어느 저장소도 이 방식을 발명한 것은 아니다. nightly build를 실행하거나, continuous integration에서 linter를 돌리거나, ticket을 생성하는 cron job을 운영해 본 사람이라면 이미 그 구조를 알고 있다. 새로운 점은 이제 loop 안에서 작업하는 worker가 비결정적이라는 것이다. 따라서 주변 machinery가 수행해야 하는 작업도 달라진다.

루프의 네 가지 구성 요소

정상적으로 작동하는 모든 루프에는 네 가지 구성 요소가 있으며, 이 중 하나라도 빠진 루프는 새벽 3시에 관리자를 호출하는 원인이 됩니다.

• Trigger(트리거). 실행을 시작하는 이벤트입니다. 타이머, 웹훅, 새로운 풀 리퀘스트, 알림 등이 해당합니다.
• Boundary(경계). 해당 실행 중에 에이전트가 접근할 수 있는 파일, 자격 증명, 네트워크 범위입니다.
• Verification(검증). 실행 결과물을 유지할지 폐기할지 결정하는 종료 코드 기반의 확인 절차입니다.
• Budget(예산). 성공 여부와 관계없이 실행을 종료시키는 토큰, 시간, 비용 제한입니다.

위의 네 가지 요소를 질문 형태로 바꾸어 검토하면, 운영을 시작하려는 모든 에이전트에 대한 설계 검토를 수행할 수 있습니다.

트리거: 에이전트를 깨우는 방법

타이머는 가장 단순한 트리거입니다. Linux 서버에서는 systemd 타이머가 cron보다 우월합니다. 로깅을 지원하고, 설정에 따라 재시도하며, 이미 실행 중인 유닛의 중복 실행을 방지하기 때문입니다. 마지막 특성은 에이전트 루프에서 가장 흔히 발생하는 중복 버그, 즉 두 개의 프로세스가 동일한 브랜치를 수정하는 문제를 해결합니다.

먼저 에이전트 전용 사용자를 생성하십시오. 이 사용자는 보안 경계의 일부이므로 /srv/agent만 소유해야 합니다.

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

그런 다음 /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 열이 나타나야 합니다. 결과가 비어 있다면 타이머가 활성화되지 않은 것입니다. --now 없이 enable만 실행하면 다음 부팅 시에만 예약되기 때문입니다. TimeoutStartSec=1800은 생각보다 중요합니다. Type=oneshot 서비스는 스크립트가 종료될 때까지 실행 중인 것으로 간주됩니다. systemd는 기본적으로 oneshot 유닛에 대해 시작 타임아웃을 비활성화하므로, 이 줄이 없으면 입력 대기 중 멈춘 에이전트는 유닛을 영원히 활성화 상태로 묶어둡니다. 이후 발생하는 모든 타이머 틱은 에이전트가 여전히 실행 중이라고 판단하여 아무것도 시작하지 않습니다. 이 줄을 추가하면 systemd는 30분 후 실행을 강제 종료하고 실패로 표시합니다. 유닛을 기본값인 Type=simple로 변경하면 TimeoutStartSec은 더 이상 실행 자체를 제어하지 않으며, RuntimeMaxSec=이 제한 설정이 됩니다. 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는 락이 걸려 있을 때 상태 코드 1을 반환하며 즉시 종료되므로, 두 번째 실행은 첫 번째 실행과 경쟁하지 않고 조용히 사라집니다. 동일한 systemd 서비스 및 타이머 설정 방식은 에이전트 여부와 관계없이 서버에서 실행되는 모든 장기 실행 작업에 적용됩니다.

경계: 각 실행에 독립적인 복사본 할당

작업 트리를 수정하는 에이전트는 커밋되지 않은 작업을 유실할 위험이 있습니다. Git worktrees를 사용하면 이를 저렴하게 해결할 수 있습니다. 각 실행은 하나의 객체 저장소를 공유하면서도 고유한 디렉터리와 브랜치를 가집니다.

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은 --force를 추가할 때까지 제거를 거부합니다. 이것이 아래의 게이트 스크립트가 실행을 폐기하는 경로에서만 강제로 제거를 수행하는 이유입니다. git worktree prune은 디렉터리가 사라진 항목을 정리합니다. 이 시점부터 병렬 루프는 안전해집니다. 두 개의 디렉터리에서 두 개의 브랜치를 작업하는 두 에이전트가 서로의 작업을 덮어쓸 수 없기 때문입니다.

경계는 자격 증명과도 관련이 있습니다. 무인으로 실행되는 루프는 장기 토큰을 보유하며, 모든 실행은 로그, 커밋 또는 모델 컨텍스트로 토큰이 유출될 가능성을 내포합니다. 토큰의 범위를 루프가 접근하는 하나의 저장소로 제한하고, 가능한 한 에이전트의 셸 환경에서 토큰을 제외하십시오. 루프에 프로덕션 접근 권한을 부여하기 전에 AI 에이전트에서 비밀 정보를 보호하는 방법을 읽어보시기 바랍니다. 더 강력한 차단을 원한다면 전체 루프를 실행 후 파기할 수 있는 일회용 VM에서 구동하십시오. 어떤 도구를 실행할지 결정하는 것 또한 코드를 작성하기 전 경계의 일부를 설정하는 과정입니다. 따라서 직접 구축해야 할 격리 수준을 결정하기 전에 Cowork의 관리형 샌드박스와 로컬 머신에서 실행하는 Claude Code의 비교를 읽어보는 것이 좋습니다.

검증: 루프를 안전하게 만드는 관문

이 부분은 단순한 반복 작업과 지능적인 자동화 루프를 구분 짓는 핵심입니다. 에이전트의 출력은 하나의 제안일 뿐이며, 이를 결정하는 것은 관문입니다.

#!/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가 없으면 변수명 오타가 빈 문자열로 확장되어, 실패를 알리는 대신 엉뚱한 경로에서 정리 작업이 수행될 수 있습니다. 마지막 줄에 --force을 의도적으로 넣지 않은 이유는, 추적되지 않거나 커밋되지 않은 파일이 트리에 남아 있을 경우 git이 삭제를 거부하게 하여, -e가 커밋되지 않은 작업을 무단으로 삭제하는 대신 오류를 발생시키며 실행을 종료하도록 하기 위함입니다.

if ! npm test 블록은 이 전체 개념의 핵심입니다. 이미 신뢰하는 검사 도구, 즉 테스트 스위트나 타입 체커의 종료 코드가 브랜치를 푸시할지 아니면 폐기할지를 결정합니다. 관문이 없는 루프는 검토할 시간이 없는 결과물만 양산하며, 이는 아예 작업을 하지 않는 것보다 못합니다. 관문이 있는 루프는 인간 기여자에게 요구되는 기준을 통과한 브랜치만을 생성합니다. 성공한 관문은 에이전트가 코드를 얼마나 수정했는지에 대해서는 아무것도 말해주지 않으므로, 에이전트가 작동하는 가장 작은 변경 사항만 선택하게 하는 규칙과 같은 상시 지침을 병행하는 것이 좋습니다. 이를 통해 diff를 작게 유지하여 검토 비용을 낮출 수 있습니다.

정직하게 실패하는 관문을 선택하십시오. 빈 diff에서도 통과하는 테스트 스위트는 루프에게 '아무것도 하지 않는 것이 성공'이라고 가르치는 꼴입니다. 테스트가 취약한 저장소는 취약한 루프를 갖게 되며, 이것이 바로 트렌딩 저장소들이 '루프 작성'보다 '코드베이스를 에이전트가 다루기 좋게 만들기'를 우선하는 이유입니다. 테스트 스위트가 단순히 라인을 실행하는 것을 넘어 실제로 회귀를 잡아낼 수 있는지 확인하고 싶다면, 변이 테스트(mutation testing)가 그 해답을 줄 것입니다. 또한 diff를 읽으라고 요구하는 대신 재실행 가능한 증거 보고서를 반환하는 에이전트를 사용하면, 그 결과를 직접 확실하게 검증할 수 있습니다.

예산: 실행을 중단시키는 요인

무한히 재시도하는 에이전트는 청구 금액을 제한 없이 늘립니다. 모든 루프에는 위에서 언급한 TimeoutStartSec을 통해 강제되는 시간 제한을 설정하고, 스크립트 내부에는 재시도 횟수를 지정하며, 제공자 계정 수준에서 지출 한도를 설정해야 합니다. 각 실행 비용을 기록하면 청구서가 나오기 전에 루프가 예산을 초과하는지 파악할 수 있습니다. 상시 가동 에이전트 VPS의 비용 관리에서는 회계 측면을 다루며, 에이전트가 턴마다 유지하는 컨텍스트 관리에서는 실행당 비용에 가장 큰 영향을 미치는 요소를 다룹니다. 30분마다 동일한 저장소를 다시 읽는 루프는 30분마다 그 비용을 지불하기 때문입니다.

비용 문제 때문에 보통 긴 세션 하나보다 루프 방식이 유리합니다. 새로 시작하여 좁은 범위의 작업을 수행하고 종료하는 실행은 컨텍스트를 작게 유지합니다. 8시간 동안 열려 있는 세션은 이전의 모든 실수를 기록에 담고 있으며, 매 턴마다 전체 대화 기록에 대한 비용을 지불하게 됩니다.

유행하는 저장소가 정리한 패턴

loop-engineering 저장소는 production pattern 8가지를 제시한다(2026-10-27 기준). 이는 선언문이 아니라 선택지 목록으로 읽을 만하다. Daily triage. GitHub Action으로 실행되며 state file을 유지하지 않는 얇은 loop. review comment를 감시하고 응답하는 pull-request babysitter. 실패한 build를 처리하는 continuous-integration sweeper. dependency sweeper. changelog drafter. Post-merge cleanup. Issue triage.

이 패턴에는 공통적으로 범위가 좁고 통과 여부를 명확히 판단할 수 있는 작업이 있다. "Fix the failing build"에는 기계가 읽을 수 있는 통과 조건이 있다. 반면 "Improve the codebase"에는 그런 조건이 없으므로 loop가 되지 않는다. 일정만 붙은 혼란스러운 작업이 될 뿐이다.

또한 모두 기록을 남긴다. 두 저장소 모두 대화 외부의 저장소 파일에 상태를 기록한다. 무엇을 실행했는지, 무엇을 발견했는지, 무엇을 결정했는지를 저장한다. 이 파일이 loop의 memory이며, 두 번째 loop가 첫 번째 loop의 작업을 다시 발견하지 않고 그 위에서 작업할 수 있는 이유다. 또한 사후에 에이전트를 감사하는 방법이기도 하다. 실행이 종료되는 순간 model의 context가 사라지기 때문이다. 실시간 coordination은 별도의 channel이며, 같은 시스템에서 실행 중인 한 Claude Code session이 다른 session에 작업을 넘길 수 있지만, 두 session 중 어느 것도 종료된 뒤에는 해당 교환 내용이 남지 않는다. 따라서 나중에 다시 확인할 수 있는 부분은 여전히 파일이다.

루프가 실패하는 경우

실패 사례는 지루하며, 여러 팀에서 반복적으로 발생합니다.

• 게이트 부재. 출력 결과가 쌓이지만 아무도 검토하지 않아 신뢰가 무너지고, 결국 루프가 꺼집니다.
• 중복 실행. 동일한 브랜치에서 두 번 실행되거나, 하나의 작업 트리에서 두 개의 에이전트가 작동하여 충돌이 발생하고, 에이전트가 이를 해결하려 시도합니다.
• 조용한 드리프트. 검사가 너무 약해 실패하지 않으므로 루프가 계속 통과됩니다.
• 제한 없는 범위. 바쁜 저장소의 모든 커밋마다 트리거가 작동하여 하루 만에 비용 문제로 이어집니다.

각 문제의 해결책은 동일합니다. 작업을 축소하고, 검사를 정교하게 만들고, 실행 기록을 남기는 것입니다. 통과 조건을 한 문장으로 설명할 수 없다면, 해당 작업은 자동화할 준비가 되지 않은 것입니다.

프레임워크 없이 시작하기

프레임워크는 필요하지 않습니다. 항상 켜져 있는 소규모 Linux 서버, 테스트 스위트가 실패해야 할 때 실패하는 git 저장소, systemd 타이머 하나, 그리고 그 안에 if이 포함된 셸 스크립트 하나면 완전한 루프가 구성됩니다. 도구를 선택하기보다 실제로 실행해 보면서 설계 문제를 해결할 수 있으므로, 대부분의 사용자는 바로 이 지점에서 시작하는 것이 좋습니다. 하나의 루프가 안정화되면, 두 번째 루프를 실행하는 것은 대체로 다른 타이머와 다른 worktree를 추가하는 문제일 뿐입니다. 기본 설정은 VPS에서 코딩 AI 에이전트를 실행하는 방법을 참조하고, 에이전트를 직접 제어하는 하드웨어에서 실행하고 싶다면 현재 자가 호스팅 가능한 AI 에이전트 옵션을 확인하십시오.

FAQ

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

프롬프트 엔지니어링은 문구, 예시, 출력 형식 등 하나의 메시지를 최적화합니다. 루프 엔지니어링은 메시지를 둘러싼 주기, 즉 실행을 시작하는 트리거, 실행되는 샌드박스, 출력을 수락하거나 거부하는 검사 단계, 그리고 종료를 결정하는 예산 등을 최적화합니다. 루프 내부에는 여전히 좋은 프롬프트가 필요합니다. 다만 프롬프트는 매일 조정해야 하는 대상에서 벗어나게 됩니다. 게이트와 트리거가 결과에 더 큰 영향을 미치기 때문입니다.

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

아니요. systemd 타이머, 실행당 하나씩 생성되는 git worktree, 테스트 명령으로 끝나는 셸 스크립트, 그리고 API 제공업체 계정의 지출 한도 설정만으로도 정의의 모든 부분을 충족할 수 있습니다. 프레임워크는 스케줄링 인터페이스, 공유 메모리 형식, 멀티 에이전트 라우팅 등을 추가해주며, 이는 여러 루프를 운영할 때 유용합니다. 첫 번째 루프를 만드는 데 필요한 필수 비용은 아닙니다.

코드베이스 하네스란 무엇인가요?

사람이 없어도 에이전트가 저장소에서 작업할 수 있도록 하는 일련의 장치입니다. 한 번의 명령으로 설정 가능하고, 비대화형으로 실행되며 실패 시 명확히 알리고, 린터를 포함하며, 변경 사항을 배포하거나 미리 볼 수 있는 환경을 의미합니다. 이 용어는 루프 엔지니어링과 같은 2026년의 저장소 문화에서 유래했습니다. 실질적인 테스트 방법은 간단합니다. 새로운 기여자가 한 번의 명령으로 clone부터 테스트 통과까지 완료할 수 없다면, 에이전트도 할 수 없습니다.

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

세 곳에서 제한을 설정하십시오. 위와 같은 Type=oneshot systemd 유닛에 TimeoutStartSec을 설정하여 멈춘 실행을 강제 종료하십시오(Type=simple 서비스의 경우 RuntimeMaxSec이 이에 해당합니다). 성공할 때까지 반복하는 대신 스크립트 내부에서 재시도 횟수를 제한하십시오. API 계정에 엄격한 지출 한도를 설정하십시오. 이는 에이전트가 우회할 수 없는 유일한 상한선입니다. 또한 실행당 비용을 기록하십시오. 비용이 두 배로 늘어나는 루프는 대개 범위가 조용히 확장된 루프이기 때문입니다.

어떤 작업을 가장 먼저 루프화하는 것이 좋은가요?

기계가 읽을 수 있는 통과 조건이 있고 영향 범위(blast radius)가 작은 작업을 선택하십시오. 실패한 빌드 수정, 의존성 업데이트, 변경 로그 재생성 등이 이에 해당합니다. 테스트 스위트나 diff를 통해 결과를 증명할 수 있기 때문입니다. 리팩토링이나 설계와 같은 개방형 작업은 아직 적합하지 않습니다. 게이트가 확인할 수 있는 기준이 없으며, 게이트 없는 루프는 리뷰 부채를 생성하는 가장 비싼 방법일 뿐입니다.