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

루프 엔지니어링의 의미

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

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

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

현재 이 명칭은 대중적으로 확립되는 과정에 있습니다. GitHub 저장소 cobusgreyling/loop-engineering는 (2026년 7월 기준) 등장한 지 2개월 만에 별 9,600개를 넘었으며, "프롬프팅을 멈추고, 루프를 설계하고, 점수를 얻으라"는 슬로건을 내걸고 있습니다. 이 저장소는 이러한 변화를 스케줄링, 워크트리, 기술, 플러그인 및 커넥터, 하위 에이전트, 대화 외부에서 유지되는 지속적 메모리라는 6가지 구성 요소로 정리합니다.

이 저장소는 Anthropic에서 Claude Code를 이끄는 Boris Cherny의 말을 인용합니다.

저는 더 이상 Claude에게 프롬프트를 입력하지 않습니다. Claude에게 프롬프트를 전달하는 루프를 실행하고 있을 뿐입니다.

두 번째 저장소인 AI-Builder-Club/skills은 (2026년 7월 기준) 별 1,100개에 육박하며 두 가지 역할을 직접적으로 명시합니다. 에이전트가 테스트를 실행하고 배포하기에 안전한 저장소를 만드는 "코드베이스 하니스(codebase harness)"와, 트리거에 따라 작동을 시작해 작업을 수행하고 학습한 내용을 공유 파일에 기록하여 다음 루프가 읽을 수 있게 만드는 "루프 엔지니어(loop engineer)"가 그것입니다.

두 저장소 모두 이 관행을 처음 발명한 것은 아닙니다. 야간 빌드, 지속적 통합(CI) 환경의 린터, 혹은 티켓을 생성하는 cron 작업을 실행해 본 사람이라면 이미 그 형태를 알고 있을 것입니다. 새로운 점은 루프 내부의 작업자가 이제 비결정적(non-deterministic)이라는 것이며, 이는 주변 기계 장치가 수행해야 할 역할을 변화시킵니다.

루프의 네 가지 구성 요소

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

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

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

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

타이머는 가장 단순한 트리거입니다. 리눅스 서버에서는 systemd 타이머가 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 열이 표시되어야 합니다. 결과가 비어 있다면 타이머가 활성화되지 않은 것입니다. --now 없이 enable만 실행하면 다음 부팅 시에만 스케줄이 잡히기 때문입니다. TimeoutStartSec=1800는 보이는 것보다 중요합니다. 입력을 기다리며 멈춰버린 에이전트는 유닛을 계속 활성 상태로 유지하게 만들며, 이 경우 타이머는 다시 작동하지 않습니다. 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 worktree prune으로 사라진 디렉터리의 항목을 정리합니다. 이 시점부터 병렬 루프는 안전해집니다. 두 디렉터리의 두 브랜치에서 작업하는 두 에이전트가 서로의 작업을 덮어쓸 수 없기 때문입니다.

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

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

이 단계가 루프와 단순히 타이핑만 하는 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 블록이 이 개념의 핵심입니다. 이미 신뢰하는 검사 도구, 테스트 스위트, 또는 타입 체커의 종료 코드가 브랜치를 푸시할지 아니면 폐기할지를 결정합니다. 관문이 없는 루프는 아무도 검토할 시간이 없는 결과물을 만들어내며, 이는 아예 작업을 하지 않는 것보다 더 나쁩니다. 관문이 있는 루프는 인간 기여자도 통과해야 하는 동일한 기준을 이미 충족한 브랜치를 생성합니다. 통과된 관문은 에이전트가 코드를 얼마나 수정했는지에 대해서는 알려주지 않으므로, 에이전트가 작동하는 가장 작은 변경 사항을 선택하게 만드는 규칙과 같은 상시 지침을 검사와 함께 사용하는 것이 좋습니다. 이를 통해 diff를 검토하기 쉬운 수준으로 작게 유지할 수 있습니다.

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

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

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

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

트렌딩 리포지토리가 정형화하는 패턴

loop-engineering 리포지토리는 7가지 프로덕션 패턴을 나열하며, 이는 선언문이라기보다 메뉴로서 읽어볼 가치가 있습니다. 일일 트리아지(triage). 리뷰 코멘트를 감시하고 답변하는 풀 리퀘스트 베이비시터. 실패한 빌드를 포착하는 지속적 통합(CI) 스위퍼. 의존성 스위퍼. 변경 로그 초안 작성기. 머지 후 정리. 이슈 트리아지.

이들의 공통점은 명확한 관문이 있는 좁은 범위의 작업이라는 점입니다. "실패한 빌드 수정"은 기계가 읽을 수 있는 통과 조건이 있습니다. 반면 "코드베이스 개선"은 그렇지 않으므로 루프가 될 수 없습니다. 이는 일정에 따라 움직이는 혼란이 될 뿐입니다.

또한 이들은 기록을 남깁니다. 두 리포지토리 모두 대화 내용에서 상태를 분리하여 리포지토리 내의 파일로 밀어 넣습니다. 무엇이 실행되었고, 무엇을 발견했으며, 어떤 결정을 내렸는지를 기록합니다. 그 파일은 루프의 기억 장치이며, 첫 번째 루프가 수행한 작업을 두 번째 루프가 재발견하는 대신 그 위에서 구축할 수 있는 이유입니다. 또한 모델의 컨텍스트는 실행이 종료되는 순간 사라지기 때문에, 사후에 에이전트를 감사하는 방법이기도 합니다. 실시간 조정은 별도의 채널이며, 동일한 머신에서 한 Claude Code 세션이 다른 세션으로 작업을 넘겨줄 수 있지만, 그 교환 과정 중 어떤 것도 세션보다 오래 지속되지 않으므로 파일은 나중에 다시 읽을 수 있는 유일한 부분으로 남습니다.

루프가 실패하는 경우

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

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

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

프레임워크 없이 시작하기

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

FAQ

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

프롬프트 엔지니어링은 문구, 예시, 출력 형식 등 단일 메시지를 최적화합니다. 루프 엔지니어링은 메시지를 둘러싼 주기 전체를 최적화합니다. 여기에는 실행을 시작하는 트리거, 실행 환경인 샌드박스, 출력을 수락하거나 거부하는 검사 단계, 실행을 종료하는 예산 설정이 포함됩니다. 루프 내부에는 여전히 좋은 프롬프트가 필요합니다. 다만 게이트와 트리거가 결과에 더 큰 영향을 미치므로, 프롬프트를 매일 수정할 필요는 없어집니다.

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

아닙니다. systemd 타이머, 실행 단위별 git worktree, 테스트 명령어로 끝나는 셸 스크립트, 그리고 API 제공업체 계정의 지출 한도 설정만으로도 루프의 모든 요소를 구현할 수 있습니다. 프레임워크는 스케줄링 인터페이스, 공유 메모리 형식, 다중 에이전트 라우팅 등을 제공하며, 이는 여러 루프를 운영할 때 유용합니다. 첫 번째 루프를 만드는 데 반드시 필요한 것은 아닙니다.

코드베이스 하네스(codebase harness)란 무엇인가요?

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

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

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

어떤 작업을 가장 먼저 루프화해야 하나요?

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