루프 엔지니어링: 스스로 반복하고 검증하는 에이전트 시스템

출처: https://youtu.be/DQq-z4wROTc · Cloud Codes · 8:31 · 2026-06-26

요지

루프 엔지니어링은 사람이 매 단계마다 프롬프트를 입력하는 대신, 에이전트가 작업을 발견하고 계획·실행·검증하도록 반복 구조를 설계하는 방식이다.
기본 루프는 목표와 종료 조건을 중심으로 발견 → 계획 → 실행 → 검증을 반복한다.
안정적인 루프에는 자동화, 격리된 작업 트리, 프로젝트 지식을 담은 스킬, 외부 도구 커넥터, 독립된 하위 에이전트와 지속성 있는 메모리가 필요하다.
성능을 좌우하는 핵심은 결과를 만드는 생성기보다 성공 여부를 판단하는 검증기이며, 가능하면 작성자와 검증자를 분리해야 한다.
명확한 성공 조건과 안전장치가 없는 루프는 비용만 쓰면서 결과를 반복 수정하는 ‘진전 없는 자동화’가 되기 쉽다.
가장 자율적인 도구부터 선택하기보다 목적을 달성할 수 있는 최소 수준의 자율성을 채택하고, 인간은 결과를 이해하고 최종 책임을 져야 한다.

개요

프롬프트 중심의 작업에서는 사람이 매번 에이전트의 출력을 읽고, 오류를 판단하고, 다음 지시를 작성한다. 즉 사람이 반복문의 제어 흐름이었다. 루프 엔지니어링은 이 반복을 코드와 규칙으로 외부화하여, 사람이 개별 응답을 조작하는 운영자에서 에이전트 시스템을 설계하는 역할로 이동하는 접근이다.

중요한 변화는 에이전트의 생성 능력이 아니라 ‘좋은 결과가 무엇인지’를 기계적으로 판정하는 능력이 희소해진다는 점이다. 테스트, 린트, 브라우저 검증, 리뷰 에이전트처럼 신뢰할 수 있는 검증 수단이 있어야 반복이 실제 개선으로 이어진다. 검증할 수 없는 목표를 자동화하면 루프는 많은 작업을 수행하더라도 올바른 방향으로 나아간다는 보장이 없다.

배경 / 사전 지식

에이전트는 언어 모델에 코드 실행, 파일 편집, 검색 같은 도구를 결합하여 여러 단계의 작업을 수행하는 프로그램이다. 한 번의 에이전트 실행에 제공되는 프롬프트, 문맥, 도구와 실행 규칙의 묶음을 하네스(harness)라고 볼 수 있다. 루프는 이 하네스보다 한 단계 바깥에서 실행을 시작하고, 결과를 검사하고, 다음 실행에 필요한 상태를 넘겨주는 제어 시스템이다.

여러 에이전트가 같은 저장소에서 동시에 일하면 파일 변경이 충돌할 수 있다. Git worktree는 하나의 저장소에서 브랜치별 작업 디렉터리를 따로 제공하므로 각 에이전트의 작업 공간을 물리적으로 격리하는 데 유용하다. MCP(Model Context Protocol) 같은 연결 계층은 에이전트가 이슈 추적기, 데이터베이스, 메시징 서비스 등 외부 시스템과 상호작용하게 한다.

언어 모델의 대화 문맥은 영구 저장소가 아니다. 실행이 끝난 뒤에도 작업 현황을 유지하려면 Markdown 상태 파일, 이슈 보드 또는 데이터베이스처럼 대화 밖에 존재하는 메모리가 필요하다. 저장소와 외부 상태가 다음 실행의 사실 원천이 되어야 루프가 매번 처음부터 프로젝트를 재해석하지 않는다.

핵심 개념

프롬프트에서 루프로

프롬프트 방식에서는 사람이 지시 → 출력 확인 → 후속 지시를 반복한다. 루프 방식에서는 사람이 목표, 단계, 검증 규칙, 종료 조건과 예산을 먼저 정의하고 시스템이 반복을 수행한다. 영상은 이를 운영자에서 시스템 설계자로의 역할 변화라고 설명한다.

생성기와 검증기

모든 루프는 작업물을 만드는 생성기와 품질을 판정하는 검증기로 나눌 수 있다. 생성기는 코드나 문서를 작성하는 모델이며, 검증기는 테스트 결과, 정적 분석, 명세 비교 또는 별도의 리뷰 모델이 될 수 있다. 생성 능력이 충분히 좋아진 환경에서는 무엇이 ‘완료’인지 정확히 판정하는 검증기가 전체 시스템의 병목이 된다.

검증 규칙을 작성하는 일은 사실상 보상 함수를 정의하는 일이다. 예를 들어 “랜딩 페이지를 개선하라”는 주관적이지만 “모바일 화면에서 가로 스크롤이 없고, Lighthouse 접근성 점수가 95 이상이며, 기존 전환 버튼이 유지되어야 한다”는 검증 가능한 기준이다.

다섯 구성 요소와 메모리

자동화: 일정이나 이벤트에 따라 작업 발견과 분류를 시작하는 심장 박동이다.
Worktree: 동시 실행되는 에이전트마다 독립된 브랜치와 체크아웃을 제공한다.
스킬: 프로젝트 규칙, 빌드 절차와 반복적으로 필요한 도메인 지식을 재사용 가능한 지침으로 보존한다.
커넥터: MCP 등을 통해 이슈 추적기, 데이터베이스, Slack, Stripe 같은 실제 도구에 접근하게 한다.
하위 에이전트: 작성, 조사, 검증 등의 역할을 분리한다. 특히 작성자와 검증자를 분리하면 자기 결과를 관대하게 평가하는 편향을 줄일 수 있다.
외부 메모리: 완료된 일과 다음 작업을 실행 사이에 보존한다. 대화가 아니라 저장소나 작업 보드가 지속 상태를 담당한다.

폐쇄 루프와 개방 루프

폐쇄 루프는 성공 조건을 사전에 고정하고 매 단계에서 이를 검사한다. 예측 가능하고 비용을 제한하기 쉬워 테스트 복구, 형식 변환, 의존성 업데이트처럼 판정 기준이 분명한 작업에 적합하다.

개방 루프는 목표만 주고 탐색의 여지를 넓힌다. 새로운 해결책이나 창의적인 결과를 얻을 수 있지만 종료 판단이 어렵고 토큰과 시간이 빠르게 늘어날 수 있다. 실무에서는 테스트 같은 강제 조건을 품질의 하한으로 유지하면서 일부 항목에만 개방형 지시를 추가하는 혼합 방식이 안전하다.

자율성의 단계

루프는 사람이 직접 중단하는 단순 셸 반복문에서 시작해, 별도 모델이 완료를 판정하는 목표 명령, 지속적인 목표 추적 시스템, 상시 실행 에이전트로 확장할 수 있다. 영상의 권장 원칙은 작업을 완수할 수 있는 가장 낮은 자율성부터 선택하는 것이다. 자율성이 높아질수록 장애 범위, 비용과 감독 부담도 함께 커진다.

작동 원리

목표를 관찰 가능한 상태로 바꾼다. “코드를 개선한다” 대신 “전체 테스트와 린트를 통과시키며 공개 API를 유지한다”처럼 완료 상태를 명시한다.
작업을 발견하고 우선순위를 정한다. 테스트 실패, 이슈 큐 또는 모니터링 경보에서 다음 작업을 선택한다.
실행 계획을 만든다. 변경 대상, 예상 영향, 사용할 도구와 검증 순서를 정한다.
격리된 환경에서 실행한다. 에이전트별 worktree와 브랜치를 만들고 허용된 범위 안에서 파일을 변경한다.
독립적으로 검증한다. 테스트와 정적 분석 같은 결정적 검사부터 수행하고, 필요한 경우 별도의 리뷰 에이전트가 명세와 결과를 비교한다.
결과와 학습을 외부 메모리에 기록한다. 시도한 변경, 실패 원인, 남은 작업과 검증 증거를 다음 실행이 읽을 수 있는 곳에 저장한다.
종료 조건을 평가한다. 모든 검사가 성공하면 결과물을 제출하고, 실패하면 진단 정보를 다음 반복의 입력으로 넘긴다. 최대 반복 횟수, 시간 또는 비용 한도에 도달하면 사람에게 에스컬레이션한다.

이 구조에서 ‘완료’라는 에이전트의 문장은 증거가 아니다. 테스트 로그, 빌드 산출물, 변경 diff, 브라우저 녹화처럼 사람이 재검토할 수 있는 결과가 완료 주장을 뒷받침해야 한다.

코드 예시

다음 Bash 스크립트는 테스트가 통과할 때까지 수정 에이전트를 최대 6회 실행하는 단순한 폐쇄 루프다. ./agent-fix는 테스트 로그를 입력받아 현재 작업 트리의 코드를 수정하는 프로젝트별 명령이라고 가정한다.

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

max_rounds=6
log_file="test-output.log"

for ((round = 1; round <= max_rounds; round++)); do
  echo "[round ${round}/${max_rounds}] running tests"

  if npm test >"$log_file" 2>&1; then
    echo "Verification passed."
    exit 0
  fi

  echo "Tests failed; asking the agent to diagnose and apply a fix."
  ./agent-fix --input "$log_file" --constraint "Do not change public APIs"
done

echo "Verification did not pass within ${max_rounds} rounds." >&2
exit 1

npm test가 검증기이고 ./agent-fix가 생성기다. 검증기가 성공할 때만 종료 코드 0을 반환하며, 여섯 번 실패하면 무한 반복하지 않고 사람에게 제어권을 돌려준다. 실제 환경에서는 별도 worktree에서 실행하고, 린트·타입 검사·보안 검사도 검증 조건에 추가하며, 각 반복의 diff와 비용을 기록해야 한다.

함정·실수

모호한 성공 조건: “더 좋게 만들어라”처럼 측정할 수 없는 목표는 여러 번 다른 결과만 만들 수 있다. 자동 검사나 구체적인 수용 기준으로 ‘좋음’을 정의한다.
자기 검증: 작성한 모델에게 완료 여부까지 맡기면 자신의 선택을 정당화하기 쉽다. 결정적 테스트를 우선하고 별도의 지침을 받은 리뷰 에이전트를 보조 검증자로 둔다.
무제한 반복: 종료 조건이 없으면 비용만 증가하거나 같은 실패를 반복한다. 최대 횟수, 시간, 토큰, 금액과 연속 무진전 기준을 설정한다.
공유 작업 공간 사용: 여러 에이전트가 한 체크아웃을 수정하면 충돌과 오염이 발생한다. 에이전트별 worktree와 브랜치를 사용한다.
대화만 메모리로 사용: 실행이 바뀔 때 과거 결정과 진행 상황이 사라진다. 상태와 학습을 저장소, 이슈 보드 또는 데이터베이스에 기록한다.
근거 없는 완료 선언: 에이전트의 “완료했다”는 보고를 그대로 승인하지 않는다. 테스트 로그, diff, 스크린샷이나 재현 가능한 산출물을 요구한다.
과도한 자율성: 단순한 작업에 상시 에이전트를 도입하면 운영 위험만 커질 수 있다. 수동 종료가 가능한 작은 루프부터 확장한다.
이해의 외주화: 결과물을 읽지 않으면 인간의 시스템 이해가 쇠퇴하고 결함을 판단하기 어려워진다. 루프가 만든 변경도 정기적으로 검토하고 설계 지식을 유지한다.

베스트 프랙티스

먼저 테스트 복구나 정형화된 유지보수처럼 성공 조건이 명확한 작업으로 시작한다.
기능 조건뿐 아니라 “공개 API 변경 금지”, “마이그레이션은 하위 호환” 같은 불변 조건도 검증기에 포함한다.
빠르고 저렴한 검사를 앞에 배치하고, 통합 테스트나 모델 리뷰처럼 비싼 검사는 뒤에 실행한다.
코드 작성자, 테스트 작성자와 최종 리뷰자의 역할 및 문맥을 분리한다.
각 실행을 최소 권한의 격리 환경에서 수행하고 배포, 결제, 데이터 삭제 같은 고위험 동작에는 인간 승인을 둔다.
매 반복마다 입력, 변경 diff, 검사 결과, 비용과 종료 사유를 기록하여 실패를 재현할 수 있게 한다.
저장소를 에이전트가 읽기 쉽고 즉시 실행하며 자동 검증할 수 있는 상태로 유지한다. 명확한 구조, 최신 실행 지침과 원클릭 테스트가 중요하다.
개방형 탐색이 필요하면 테스트와 정책을 품질 하한으로 고정한 뒤 제한된 항목에만 창의적 재량을 허용한다.
같은 실패가 반복되거나 결과가 개선되지 않으면 프롬프트를 계속 재시도하지 말고 사람에게 진단 자료와 함께 에스컬레이션한다.
루프 간 공유 메모리는 유용하지만, 잘못된 학습도 전파될 수 있으므로 변경 이력과 검토 절차를 둔다.

참고

Claude Code의 목표(goal) 명령: 작업을 수행한 모델과 별도의 더 빠른 모델이 종료 여부를 판단하는 사례로 소개된다.
Git worktree: 병렬 에이전트에 독립된 체크아웃과 브랜치를 제공하는 격리 수단으로 언급된다.
MCP(Model Context Protocol): 에이전트 루프를 이슈 추적기, 데이터베이스, Slack, Stripe 등 외부 도구와 연결하는 기반으로 언급된다.
영상은 2026년 6월에 ‘loop engineering’이라는 명칭과 12쪽 분량의 현장 가이드가 확산됐다고 설명하지만, 해당 가이드의 제목이나 링크는 명시하지 않는다.