루프 엔지니어링이란? AI 코딩 에이전트를 직접 프롬프트하지 않는 새로운 작업 방식

루프 엔지니어링은 코딩 에이전트에게 매번 직접 지시하는 대신, 목표·자동화·워크트리·스킬·커넥터·서브에이전트·외부 메모리가 반복 실행되는 시스템을 설계하는 방법입니다. 개념과 아키텍처, 실전 도입 순서, 주의점을 쉽게 정리했습니다.

AI 코딩 에이전트를 쓰다 보면 어느 순간 비슷한 패턴을 반복하게 됩니다.

사용자: 이 이슈를 분석해 줘.
에이전트: 분석했습니다.
사용자: 그럼 수정해 줘.
에이전트: 수정했습니다.
사용자: 테스트해 줘.
에이전트: 테스트가 실패했습니다.
사용자: 오류를 고쳐 줘.
에이전트: 다시 수정했습니다.

처음에는 이 방식도 충분히 생산적입니다.
하지만 프로젝트가 커지고 반복 작업이 늘어나면 사용자는 점점 에이전트의 관리자가 됩니다.

다음 프롬프트를 직접 작성하고
실패한 작업을 다시 설명하고
여러 에이전트의 작업 순서를 조율하고
같은 프로젝트 규칙을 매번 전달하고
결과를 확인한 뒤 다음 행동을 다시 지시합니다

이 문제를 해결하려는 새로운 작업 방식이 루프 엔지니어링(Loop Engineering) 입니다.

한 줄 결론
루프 엔지니어링은 에이전트에게 매번 직접 프롬프트하는 대신,
목표를 받으면 계획·실행·검증·기록·재시도가 자동으로 반복되는 시스템을 설계하는 일입니다.

루프 엔지니어링이 왜 등장했을까?

지금까지 AI 코딩 도구의 중심에는 프롬프트가 있었습니다.

좋은 프롬프트 작성
→ 적절한 컨텍스트 제공
→ 결과 확인
→ 다음 프롬프트 작성

이 방식은 사람이 전체 흐름을 잡고 있을 때 잘 작동합니다.

하지만 아래 작업을 매일 반복한다면 이야기가 달라집니다.

새 이슈 분류
CI 실패 원인 요약
최근 커밋 검토
반복되는 테스트 수정
문서와 코드의 불일치 탐지
여러 브랜치의 병렬 구현
작업 상태를 외부 시스템에 기록

이런 일은 사람이 매번 새 프롬프트를 작성하는 것보다,
에이전트에게 일을 배정하고 결과를 검사하는 시스템으로 만드는 편이 더 효율적입니다.

루프 엔지니어링의 핵심 변화는 다음과 같습니다.

기존 방식
사람 → 프롬프트 → 에이전트 → 결과 → 사람 → 다음 프롬프트

루프 엔지니어링
사람 → 목표·정책 정의 → 자동 실행 루프 → 검증 → 완료 또는 재시도

즉, 사람은 매 턴의 지시자가 아니라 루프 설계자와 최종 검증자가 됩니다.

루프란 무엇인가?

여기서 말하는 루프는 단순한 while 문보다 넓은 개념입니다.

루프는 목표를 받아 다음 과정을 반복합니다.

목표 확인
→ 현재 상태 읽기
→ 다음 작업 선택
→ 실행
→ 결과 검증
→ 상태 기록
→ 완료 조건 확인
→ 미완료라면 다시 반복

중요한 점은 루프가 무조건 영원히 실행되는 것이 아니라는 점입니다.

좋은 루프에는 반드시 다음이 있어야 합니다.

명확한 목표
실행 가능한 작업 단위
완료 조건
실패 조건
최대 반복 횟수
비용 한도
사람에게 넘기는 조건

이 조건이 없으면 루프는 자동화가 아니라 비용을 계속 소비하는 무한 반복이 될 수 있습니다.

루프 엔지니어링의 핵심 6요소

루프 엔지니어링을 구성하는 핵심 요소는 다음 6가지로 정리할 수 있습니다.

1. Automations — 자동 실행 조건

자동화는 루프를 시작시키는 트리거와 실행 규칙입니다.

예를 들어:

새로운 GitHub 이슈가 생성됐을 때
CI 테스트가 실패했을 때
매일 오전 9시에
특정 라벨이 붙었을 때
배포 이후 오류율이 기준을 넘었을 때

자동화가 없다면 결국 사용자가 매번 에이전트를 직접 실행해야 합니다.

이벤트 감지
→ 작업 생성
→ 에이전트 실행
→ 결과 저장

좋은 자동화는 “AI가 알아서 무엇이든 하게 하는 것”이 아니라
정해진 조건에서 정해진 범위의 작업만 시작하게 하는 것입니다.

2. Worktrees — 충돌 없는 병렬 작업 공간

여러 에이전트가 같은 Git 저장소를 동시에 수정하면 충돌이 발생하기 쉽습니다.

Git worktree를 사용하면 같은 저장소를 여러 작업 디렉터리로 나눌 수 있습니다.

project/
├── main-worktree/
├── issue-142-worktree/
├── issue-143-worktree/
└── docs-update-worktree/

각 에이전트는 자기 작업 공간에서 독립적으로 작업합니다.

장점:

파일 수정 충돌 감소
브랜치별 작업 격리
여러 이슈 병렬 처리
실패한 작업을 쉽게 폐기
결과를 PR 단위로 검토 가능

워크트리는 멀티 에이전트 코딩에서 단순한 Git 기능을 넘어
에이전트별 샌드박스 역할을 합니다.

3. Skills — 프로젝트 지식의 재사용

에이전트는 새 세션을 시작할 때마다 프로젝트의 규칙을 다시 배워야 합니다.

예를 들면:

테스트 실행 방법
배포 절차
코드 스타일
특정 디렉터리의 역할
데이터베이스 마이그레이션 규칙
금지된 작업
완료 보고 형식

이 지식을 프롬프트에 매번 반복하기보다
SKILL.md, AGENTS.md, CLAUDE.md 같은 문서로 저장할 수 있습니다.

skills/
├── run-tests/
│   └── SKILL.md
├── fix-ci/
│   └── SKILL.md
├── create-migration/
│   └── SKILL.md
└── review-pr/
    └── SKILL.md

좋은 스킬 문서는 설명만 하지 않습니다.

# 목표
실패한 Python 테스트의 원인을 찾고 최소 수정으로 해결한다.

# 입력
- 실패 로그
- 관련 테스트 파일
- 관련 구현 파일

# 절차
1. 실패 테스트만 재현
2. 원인 후보를 기록
3. 최소 수정
4. 전체 테스트 실행

# 완료 조건
- 대상 테스트 통과
- 전체 테스트 회귀 없음
- 변경 이유 문서화

스킬은 에이전트에게 “똑똑하게 행동하라”고 요구하는 대신
프로젝트에서 검증된 행동 절차를 제공하는 장치입니다.

4. Connectors — 외부 시스템 연결

코딩 에이전트가 실제 업무 흐름에 참여하려면 저장소 밖의 시스템과 연결되어야 합니다.

대표적인 연결 대상:

GitHub / GitLab
Linear / Jira
Slack
데이터베이스
로그·모니터링 서비스
사내 문서
배포 플랫폼
MCP 서버
내부 API

커넥터가 연결되면 루프는 이런 흐름을 만들 수 있습니다.

Linear 이슈 읽기
→ GitHub 브랜치 생성
→ 코드 수정
→ 테스트 실행
→ PR 생성
→ Slack으로 검토 요청
→ 결과를 Linear에 기록

다만 커넥터는 편리한 만큼 위험합니다.

특히 다음 권한은 제한해야 합니다.

프로덕션 DB 쓰기
배포 실행
비밀 값 조회
파일 삭제
결제·사용자 계정 변경
외부 메시지 전송

초기에는 읽기 권한 중심으로 시작하는 것이 안전합니다.

5. Sub-agents — 역할별 작업 분리

큰 작업을 하나의 에이전트에게 모두 맡기면 컨텍스트가 길어지고 판단이 흐려집니다.

서브에이전트를 역할별로 나누면 작업을 병렬화하고 책임을 분리할 수 있습니다.

예시:

Planner Agent
├── 작업 분해
├── 우선순위 결정
└── 완료 조건 정의

Implementation Agent
├── 코드 수정
└── 변경사항 설명

Test Agent
├── 테스트 실행
├── 실패 분석
└── 회귀 검증

Review Agent
├── diff 검토
├── 보안 위험 확인
└── 요구사항 충족 확인

중요한 점은 서브에이전트 수를 무조건 늘리는 것이 아닙니다.

역할 분리가 필요한 경우에만 사용해야 합니다.

작업이 독립적으로 나뉠 수 있는가?
서로 다른 도구가 필요한가?
결과를 명확하게 합칠 수 있는가?
병렬 실행 이익이 통신 비용보다 큰가?

작은 작업까지 여러 에이전트로 쪼개면 오히려 느려지고 토큰 비용이 늘어납니다.

6. Memory — 대화 밖에 남는 상태

AI 모델은 한 세션 안의 대화를 기억하더라도,
새 실행이 시작되면 이전 상태를 정확히 이어받지 못할 수 있습니다.

그래서 루프에는 외부 메모리가 필요합니다.

예시:

docs/agent/
├── GOAL.md
├── PLAN.md
├── STATUS.md
├── DECISIONS.md
├── FAILURES.md
└── VERIFY.md

또는 다음 시스템을 메모리로 사용할 수 있습니다.

GitHub Issues
Linear 보드
데이터베이스
벡터 검색
체크포인트 파일
이벤트 로그

외부 메모리에 반드시 기록해야 할 내용:

현재 목표
완료된 작업
남은 작업
실패한 접근
검증 결과
사용한 비용
다음 실행의 시작점

메모리가 없다면 루프는 매번 같은 실수를 반복할 가능성이 커집니다.

전체 실행 아키텍처

루프 엔지니어링의 전체 구조를 단순화하면 다음과 같습니다.

사용자 목표
   ↓
Automation Trigger
   ↓
Planner / Router
   ↓
Agent Loop
├── Skills
├── Worktree
├── Sub-agents
└── Connectors
   ↓
실행 결과
   ↓
검증 게이트
   ↓
외부 메모리 기록
   ↓
완료 조건 확인
   ├── 완료 → 사람에게 결과 전달
   └── 미완료 → 다음 반복

이 구조에서 가장 중요한 것은 검증 게이트입니다.

검증 없이 자동으로 반복하는 시스템은 빠르게 코드를 만들 수 있지만,
빠르게 잘못된 방향으로 갈 수도 있습니다.

검증은 왜 반드시 사람의 몫으로 남아야 할까?

루프 엔지니어링은 사람을 완전히 제거하는 방식이 아닙니다.

오히려 사람의 역할을 다음처럼 바꿉니다.

기존:
매 단계 프롬프트 작성 + 실행 지시 + 오류 수정

루프 엔지니어링:
목표 정의 + 정책 설정 + 품질 검증 + 중요 결정 승인

사람이 반드시 개입해야 하는 지점:

요구사항 해석이 바뀌는 결정
데이터 삭제
보안 정책 변경
프로덕션 배포
비용이 큰 실행
외부 사용자에게 메시지 전송
법적·재정적 판단
설계 방향의 대규모 변경

핵심 원칙은 다음과 같습니다.

Build the loop, stay the engineer.
루프를 만들되, 엔지니어의 판단까지 넘기지는 않는다.

좋은 완료 조건의 예

나쁜 완료 조건:

코드를 잘 수정한다.

좋은 완료 조건:

- issue #142의 재현 테스트가 통과한다.
- 기존 테스트 120개가 모두 통과한다.
- ruff check가 성공한다.
- API 응답 형식은 변경하지 않는다.
- 수정 파일은 src/search/와 tests/search/로 제한한다.
- 변경 이유와 검증 결과를 PR 설명에 기록한다.

완료 조건은 에이전트가 스스로 “끝났다”고 판단하는 기준입니다.

측정할 수 없는 목표는 루프가 끝나지 않거나,
불완전한 결과를 완료로 처리하게 만듭니다.

작은 프로젝트에 적용하는 최소 구조

처음부터 멀티 에이전트와 Kubernetes까지 도입할 필요는 없습니다.

아래 정도면 충분한 MVP입니다.

project/
├── AGENTS.md
├── docs/agent/
│   ├── GOAL.md
│   ├── STATUS.md
│   └── VERIFY.md
├── scripts/
│   ├── run_tests.sh
│   └── verify.sh
└── .github/
    └── workflows/
        └── agent-check.yml

최소 루프:

1. GOAL.md 읽기
2. 현재 코드와 STATUS.md 확인
3. 작업 하나 수행
4. verify.sh 실행
5. 실패하면 원인을 기록하고 재시도
6. 성공하면 STATUS.md 갱신
7. 사람에게 diff 검토 요청

이 정도만 구현해도 매번 같은 설명을 반복하는 비용이 크게 줄어듭니다.

실전 예시: CI 실패 자동 수정 루프

목표

main 브랜치의 CI 실패 원인을 분석하고,
안전한 경우 수정 PR을 만든다.

실행 흐름

GitHub Actions 실패 감지
   ↓
실패 로그 수집
   ↓
관련 파일 검색
   ↓
전용 worktree 생성
   ↓
테스트 재현
   ↓
최소 수정
   ↓
전체 테스트 실행
   ↓
Review Agent가 diff 검토
   ↓
PR 생성
   ↓
사람의 최종 승인

중단 조건

- 3회 수정 후에도 테스트 실패
- 20개 이상의 파일 변경 필요
- DB 스키마 변경 발견
- 보안 관련 코드 수정 필요
- 예상 비용 한도 초과

이 조건에 걸리면 루프는 무리하게 계속 진행하지 않고 사람에게 넘깁니다.

토큰 비용을 통제하는 방법

루프는 반복 실행되므로 단발성 프롬프트보다 비용이 커질 수 있습니다.

다음 전략이 필요합니다.

1. 작업 단위를 작게 유지

전체 저장소를 매번 다시 분석하지 않습니다.

2. 관련 파일만 검색

변경 대상과 테스트 파일만 컨텍스트에 넣습니다.

3. 최대 반복 횟수 설정

예: 수정 시도 최대 3회

4. 저비용 모델과 고성능 모델 분리

분류·요약: 빠르고 저렴한 모델
설계·복잡한 수정: 고성능 모델
최종 리뷰: 별도 검증 모델 또는 사람

5. 실행 결과를 외부 메모리에 저장

이미 확인한 정보를 매번 다시 추론하지 않게 합니다.

6. 실패 루프 탐지

같은 오류가 반복되면 자동 중단합니다.

루프 엔지니어링의 장점

반복 작업 감소

같은 종류의 작업을 매번 지시하지 않아도 됩니다.

병렬 처리

여러 워크트리와 서브에이전트로 독립 작업을 동시에 진행할 수 있습니다.

프로젝트 지식 재사용

스킬과 외부 메모리로 팀의 규칙을 계속 재활용할 수 있습니다.

작업 추적 가능

각 단계의 실행 결과와 검증 기록을 남길 수 있습니다.

운영 확장성

단발성 대화가 아니라 지속적으로 작동하는 에이전트 시스템으로 발전시킬 수 있습니다.

위험과 한계

1. 자동화된 오류의 확대

잘못된 목표나 검증 규칙이 있으면 같은 실수를 빠르게 반복합니다.

2. 비용 폭증

반복 횟수와 컨텍스트 크기를 제한하지 않으면 토큰과 실행 비용이 커집니다.

3. 권한 위험

외부 시스템과 연결된 에이전트는 실제 데이터를 변경할 수 있습니다.

4. 복잡성 증가

작은 작업에 과도한 구조를 적용하면 직접 수행하는 것보다 느릴 수 있습니다.

5. 검증 책임

에이전트가 “완료”라고 보고해도 실제 품질을 보장하지는 않습니다.

따라서 첫 적용 대상은 다음 조건을 만족하는 작업이 좋습니다.

반복적이다
+ 결과를 자동 검증할 수 있다
+ 실패해도 피해가 작다
+ 입력과 출력이 명확하다

어떤 작업부터 자동화해야 할까?

1단계: 읽기 전용 작업

이슈 분류
로그 요약
변경사항 요약
문서 검색
코드베이스 구조 분석

2단계: 검증 가능한 수정

포맷팅
린트 오류 수정
단순 테스트 추가
문서 링크 수정
의존성 업데이트 PR

3단계: 제한된 기능 개발

명확한 완료 조건이 있는 작은 이슈
독립적인 모듈 수정
자동 테스트가 충분한 영역

4단계: 복잡한 운영 작업

배포
데이터 마이그레이션
외부 고객 영향 작업
장시간 멀티 에이전트 프로세스

처음부터 4단계로 가면 시스템 복잡도와 위험이 급격히 커집니다.

자주 묻는 질문

Q1. 루프 엔지니어링과 프롬프트 엔지니어링은 무엇이 다른가?

프롬프트 엔지니어링은 한 번의 요청을 더 잘 수행하도록 입력을 설계합니다.

루프 엔지니어링은 여러 번의 실행이 자동으로 이어지도록
전체 작업 시스템과 피드백 구조를 설계합니다.

Q2. 하네스 엔지니어링과 같은 개념인가?

관련이 매우 깊지만 강조점이 다릅니다.

하네스 엔지니어링: 모델 주변의 도구·컨텍스트·훅·실행 환경 전체
루프 엔지니어링: 그 구성 요소들이 목표를 향해 반복 실행되는 흐름

하네스가 작업 환경이라면, 루프는 그 환경에서 움직이는 자동 실행 사이클이라고 볼 수 있습니다.

Q3. 꼭 여러 에이전트가 필요할까?

아닙니다.

하나의 에이전트만 사용해도 계획·실행·검증·기록이 반복되면 루프입니다.

멀티 에이전트는 역할 분리와 병렬 처리가 실제로 도움이 될 때만 추가하면 됩니다.

Q4. Claude Code나 Codex에서 바로 적용할 수 있을까?

가능합니다.

다음 요소부터 시작하면 됩니다.

프로젝트 지침 파일
반복 실행 스크립트
Git worktree
테스트·린트 명령
상태 기록 파일
GitHub Actions 또는 예약 실행
MCP나 API 커넥터

도구 자체보다 완료 조건과 검증 구조를 먼저 설계하는 것이 중요합니다.

마무리

AI 코딩 에이전트가 발전할수록 사람은 더 많은 프롬프트를 작성해야 할까요?

루프 엔지니어링은 반대 방향을 제안합니다.

사람이 에이전트에게 매번 다음 행동을 알려주는 대신,
에이전트가 목표를 향해 반복하고 검증할 수 있는 시스템을 설계하자.

핵심 구성은 어렵지 않습니다.

자동화
+ 워크트리
+ 스킬
+ 커넥터
+ 서브에이전트
+ 외부 메모리
+ 검증 게이트

하지만 진짜 핵심은 도구 목록이 아닙니다.

무엇을 자동화할지
언제 중단할지
무엇을 검증할지
어떤 결정은 사람에게 남길지

이 네 가지를 명확하게 설계하는 것이 루프 엔지니어링의 본질입니다.

AI가 더 오래 일하게 만드는 것보다,
올바른 방향으로 반복하고 틀렸을 때 멈추게 만드는 능력이 더 중요합니다.

참고 자료

Addy Osmani, “Loop Engineering”
https://addyosmani.com/blog/loop-engineering/
GeekNews, “루프 엔지니어링 - 에이전트를 프롬프트하는 시스템을 설계하기”
https://news.hada.io/topic?id=30336
GeekNews, “Loop Engineering - Addy Osmani”
https://news.hada.io/topic?id=30301

이 글은 2026년 6월 공개 자료를 기준으로 작성했습니다.
루프 엔지니어링은 아직 빠르게 정리되고 있는 개념이므로, 실제 적용에서는 작은 자동화부터 시작하고 비용·권한·검증 조건을 명시적으로 설정하는 것이 안전합니다.

저작자표시 비영리 변경금지 (새창열림)