Loop Engineering 입문: AI 에이전트 시대에 '프롬프트를 쓰는 것'에서 '루프를 설계하는 것'으로

AI 코딩 에이전트를 사용하다 보면, 다음과 같은 경험을 하지 않으신가요?

• 첫 번째 지시는 잘 되었지만, 다음에 무엇을 요청해야 할지 매번 고민한다
• 구현은 빠르지만, 리뷰·수정·재실행 관리가 인간 측에 남아 있다
• 에이전트가 도중에 문맥(Context)을 잃고, 같은 설명을 몇 번이고 반복한다
• "테스트해줘", "고쳐줘", "다시 한번 확인해줘"라는 지시를 인간이 수동으로 돌리고 있다

이 상태는 AI를 사용하고 있는 것 같지만, 실제로는 인간이 AI의 작업 큐(Job Queue) 겸 프로젝트 매니저가 되어 있는 상태입니다.

그래서 주목받고 있는 것이 Loop Engineering입니다.

한마디로 말하자면, Loop Engineering이란,

AI 에이전트에게 매번 프롬프트(Prompt)를 쓰는 것이 아니라, AI 에이전트가 목적 달성까지 자율적으로 생각하고, 실행하고, 검증하며, 필요하다면 인간에게 되돌려주는 "루프(Loop)" 그 자체를 설계하는 사고방식

입니다.

이 기사에서는 Loop Engineering을 단순한 유행어가 아니라, 실제 개발·운영에 적용할 수 있는 설계 패턴으로서 정리합니다.

기존의 AI 활용은 대부분 다음과 같은 흐름이었습니다.

인간이 지시한다
↓
AI가 답변한다
...

이것은 Prompt Engineering의 연장선입니다.

반면, Loop Engineering에서는 다음과 같이 생각합니다.

골(Goal)을 정의한다
↓
에이전트가 상태를 확인한다
...

즉, 설계 대상이 "1회의 프롬프트"가 아니라, 반복하는 제어 시스템으로 바뀝니다.

관점	Prompt Engineering	Context Engineering	Loop Engineering
주요 설계 대상	1회의 지시문	모델에 전달하는 정보	반복 실행하는 메커니즘
...

중요한 것은, 이것들이 대립되는 개념이 아니라는 점입니다.

Loop Engineering은 Prompt Engineering이나 Context Engineering 위에 올라갑니다.

프롬프트가 부실하다면, 루프는 "부실한 작업을 고속으로 반복하는 장치"가 됩니다.

컨텍스트(Context)가 오염되어 있다면, 루프는 "잘못된 전제를 계속 유지하는 장치"가 됩니다.

즉, Loop Engineering은 마법이 아니라, 프롬프트·컨텍스트·평가·권한 관리를 통합하여 설계하는 상위 레이어입니다.

AI 에이전트의 능력이 올라갈수록, 인간의 병목 구간은 "코드를 쓰는 것"에서 "일을 어떻게 맡길 것인가"로 이동합니다.

특히 개발 현장에서는 단발적인 생성보다 다음과 같은 작업이 더 많아집니다.

• PR(Pull Request)의 차이(Diff)를 확인한다
• 테스트 실패를 조사한다
• 작은 수정을 넣는다
• 의존성 라이브러리 업데이트를 확인한다
• 보안 경고를 정리한다
• Issue를 분류한다
• 문서와 구현의 차이를 메운다

이것들은 1회의 프롬프트로 완결되기 어려운 태스크입니다.

오히려 상태를 보고, 판단하고, 실행하고, 검증하며, 필요하다면 인간에게 되돌려주는 루프에 적합합니다.

Loop Engineering을 구현할 경우, 최소한 다음 요소들을 설계합니다.

포인트는 AI에게 "열심히 해줘"라고 부탁하는 것이 아니라, 다음을 명확히 하는 것입니다.

• 무엇을 달성하면 완료인가
• 무엇을 보고 현재 상태를 판단하는가
• 어떤 도구(Tool)를 사용해도 되는가
• 어떤 조작은 금지하는가
• 몇 번 실패하면 멈추는가
• 어떤 조건에서 인간에게 되돌리는가

먼저, 루프의 목적을 명확히 합니다.

나쁜 예:

리포지토리를 적당히 유지보수해줘

좋은 예:

매일 아침 9시에 리포지토리를 확인하고, 다음을 실행한다.
- 실패하고 있는 CI를 검출한다
- 원인이 경미한 의존 관계·타입 에러·Lint 에러라면 수정 PR을 만든다
...

목적은 AI가 해석할 수 있을 뿐만 아니라, 인간이 리뷰할 수 있는 입도(Granularity)로 설정해야 합니다.

AI 에이전트는 아무것도 설계하지 않으면 세션이 끊기는 순간 문맥을 잃습니다.

따라서 루프에는 외부 상태(External State)가 필요합니다.

예:

.loop/state.md
.loop/history.json
.loop/decisions.md
...

상태에는 다음을 남깁니다.

• 지난번에 무엇을 했는가
• 무엇이 실패했는가
• 어떤 판단을 인간에게 위임했는가
• 다음 재개 시 무엇을 봐야 하는가
• 이미 시도한 수정은 무엇인가

상태 관리가 없는 루프는 기억력이 없는 작업자에게 매번 같은 일을 부탁하는 것과 같습니다.

루프는 AI가 사용할 수 있는 도구를 가짐으로써 비로소 가치를 발휘합니다.

예:

• Git 조작
• 테스트 실행
• Lint 실행
• Issue 생성
• PR 생성
• CI 로그 취득
• 문서 업데이트
• Slack 알림
• 티켓 업데이트

하지만 도구가 늘어날수록 리스크도 증가합니다.

따라서 권한은 최소한으로 제한합니다.

permissions:
  github:
    contents: read
...

Loop Engineering에서는 AI의 똑똑함뿐만 아니라, AI에게 무엇을 허용하고 무엇을 금지할 것인가가 중요합니다.

루프에는 반드시 검증이 필요합니다.

AI가 코드를 작성할 수 있다는 것과 그 코드가 올바르다는 것은 별개의 문제입니다.

최소한 다음과 같은 검증을 포함합니다.

• Unit Test (단위 테스트)
• Integration Test (통합 테스트)
• Type Check (타입 체크)
• Lint (린트)
• Security Scan (보안 스캔)
• Build (빌드)
• 차분 리뷰 (Diff Review)
• 사양과의 대조

더욱 중요한 것은 구현자와 검증자를 분리하는 것입니다.

Implementer Agent (구현 에이전트):
- 코드 작성
- 수정안 작성
...

동일한 에이전트가 자신의 결과물을 평가하면 판정이 관대해지기 쉽습니다.

사람의 개발에서도 구현자와 리뷰어를 분리하는 것과 같습니다.

Loop Engineering에서 가장 위험한 것은 멈추지 않는 루프입니다.

정지 조건은 처음에 설계합니다.

예:

다음 중 하나를 만족하면 정지한다.
- 모든 테스트가 성공했다
- PR을 생성했다
...

'성공하면 멈춘다'만으로는 불충분합니다.

'위험해지면 멈춘다'

'판단이 어려워지면 사람에게 넘긴다'

'비용이 너무 많이 들면 멈춘다'

이 세 가지도 필요합니다.

Loop Engineering은 인간을 불필요하게 만드는 설계가 아닙니다.

오히려 인간의 판단을 어디에 둘 것인지를 명확히 하는 설계입니다.

사람에게 넘겨야 하는 케이스:

• 사양 판단이 필요할 때
• 보안 영향이 있을 때
• 과금·요금·계약과 관련될 때
• 운영 DB에 영향을 줄 때
• 고객 데이터에 접근할 때
• 파괴적 변경(Breaking Change)이 필요할 때
• 테스트로는 판단할 수 없는 UX 변경이 있을 때

사람에게 넘길 때는 단순히 '실패했습니다'가 아니라, 판단하기 쉬운 형식으로 전달합니다.

## Human Review Required
### 목적
CI 실패 수정
...

이를 통해 인간은 처음부터 상황을 읽을 필요가 없어집니다.

여기서는 간이적인 'Daily Triage Loop'를 생각해 보겠습니다.

목적:

• 매일 아침 CI 실패, 오래된 PR, 미분류 Issue를 확인한다
• 자동 수정할 수 있는 것은 PR을 생성한다
• 판단이 필요한 것은 Issue 코멘트로 정리한다

.github/
workflows/
daily-triage.yml
...

# Daily Triage Loop Goal
이 루프는 리포지토리의 유지보수 작업을 매일 실행한다.
## 대상
...

# Loop Policy
## Stop Conditions
다음의 경우에는 작업을 정지하고 사람에게 리뷰를 요청한다.
...

name: Daily Triage Loop
on:
  schedule:
...

실제로는 triage-loop.js 안에서 다음과 같은 작업을 수행합니다.

1. GitHub API로부터 Issue / PR / CI 결과 취득
2. .loop/state.md 를 읽음
3. AI에게 현재 상태와 정책을 전달
...

중요한 것은 AI에게 자유롭게 셸(Shell)을 다루게 하는 것이 아니라, 허용된 액션 중에서 선택하게 하는 것입니다.

실무에서 Loop Engineering을 시작한다면 다음 템플릿을 사용하는 것이 정리하기 쉽습니다.

# Loop Design
## 1. Name
예: Daily PR Triage Loop
...

코드를 개선해줘

이것은 위험합니다.

개선의 정의가 없기 때문에 루프가 끝나지 않습니다.

개선 계열의 루프에서는 반드시 측정 가능한 조건을 둡니다.

- 테스트 성공
- Lint 에러 0건
- 기존 API 호환성 유지
...

AI 에이전트에게 너무 넓은 권한을 주면 사고의 영향 범위가 넓어집니다.

피해야 할 예:

- 운영 환경으로의 직접 배포
- main 브랜치로의 직접 push
- DB 삭제 권한
...

AI 에이전트는 유능한 신입 엔지니어로 대우하는 정도가 안전합니다.

읽기부터 시작하여, 다음으로 PR 생성, 마지막으로 제한적인 자동 머지(Merge)라는 순서로 단계적으로 범위를 넓혀갑니다.

구현한 후, 스스로 문제가 없는지 확인한다

이것은 취약합니다.

최소한 기계적인 검증을 넣어야 합니다.

- 테스트 (Test)
- 타입 체크 (Type Check)
- 린트 (Lint)
...

가능하다면 구현 에이전트(Implementation Agent)와는 별도의 검증 에이전트(Verification Agent)를 사용합니다.

루프(Loop)는 편리하지만, 너무 많이 돌리면 토큰 비용이 불어납니다.

특히 위험한 경우는 다음과 같습니다.

• 고빈도 cron
• 거대한 리포지토리(Repository) 전체를 읽기
• 다수의 서브 에이전트 (Sub-agent)
• 긴 이력을 매번 투입
• 실패 시 무제한 재시도 (Retry)

대책:

- 실행 빈도를 낮춘다
- 차분(Diff)만 읽는다
- 컨텍스트(Context)를 요약한다
...

Loop Engineering으로 개발 속도가 올라가면, 인간이 코드를 이해하는 속도를 넘어설 때가 있습니다.

이를 이해 부채 (Understanding Debt) 라고 부를 수 있습니다.

AI가 대량의 PR을 만들고, 테스트도 통과하고 있습니다.

하지만 팀의 누구도 설계 의도를 설명할 수 없습니다.

이는 매우 위험합니다.

대책:

• AI 생성 PR도 반드시 인간이 읽는다
• 주 단위로 AI 변경 사항의 요약(Summary)을 확인한다
• 설계 판단은 ADR(Architecture Decision Record)에 남긴다
• 큰 차분(Diff)은 자동 머지(Merge)하지 않는다
• "왜 이 변경을 했는지"를 PR 본문에 쓰게 한다

AI가 구현을 빠르게 하더라도, 책임은 인간에게 남습니다.

갑자기 완전 자율 루프를 만들 필요는 없습니다.

추천하는 방식은 다음 3단계입니다.

1단계: 인간 중심 (Human-in-the-loop)

AI는 분석만 수행하고, 인간이 판단합니다.

예:

매일 아침, 미처리 Issue · 실패한 CI · 오래된 PR을 정리하여 Slack에 보고한다

리스크가 낮고 도입하기 쉽습니다.

2단계: 인간 승인 (Human-approval)

AI가 수정안이나 PR을 만들고, 인간이 승인합니다.

예:

Lint 에러나 타입 에러를 수정하는 PR을 AI가 작성하고, 인간이 리뷰한다

실무에서는 이 단계가 가장 균형이 좋습니다.

3단계: 완전 자동화 (Full Automation)

AI가 제한된 범위 내에서 자동 수정 · 자동 머지합니다.

예:

문서의 링크 깨짐 수정이나 의존성 라이브러리의 patch 업데이트를 자동 머지한다

단, 충분한 테스트 · 권한 제어 · 감사 로그(Audit Log)가 있는 경우에 한정해야 합니다.

Loop Engineering은 코딩뿐만 아니라 인프라 운영에도 적합합니다.

Trigger:
CloudWatch / Datadog / Prometheus의 알람
Actions:
...

Trigger:
Pull Request 생성 시
Actions:
...

Trigger:
Dependabot Alert
Trivy / Snyk / GitHub Advisory
...

도입 전에 다음을 확인합시다.

- [ ] 루프의 목적이 명확한가
- [ ] 성공 조건은 측정 가능한가
- [ ] 정지 조건은 정의되어 있는가
...

이 체크리스트에 답할 수 없다면, 아직 자율도를 높여서는 안 됩니다.

Loop Engineering은 "AI에게 멋진 프롬프트를 쓰는 기술"이 아닙니다.

그것은 AI 에이전트를 개발 · 운영 프로세스 속에서 안전하게 작동시키기 위한 제어 설계 (Control Design) 입니다.

중요한 포인트는 다음과 같습니다.

• 프롬프트가 아니라, 반복하는 메커니즘을 설계한다
• 목표 · 상태 · 실행 · 검증 · 정지 조건을 명확히 한다
• 구현자와 검증자를 분리한다
• 권한은 최소한으로 한다
• 비용과 이해 부채를 관리한다
• 인간의 판단 포인트를 설계에 포함시킨다

AI 에이전트 시대의 엔지니어링에서는 코드를 쓰는 능력뿐만 아니라, AI가 안전하게 일할 수 있는 환경을 설계하는 능력이 중요해집니다.

앞으로 개발자의 업무는 AI에게 매번 지시를 내리는 것이 아니라, AI가 올바르게 나아가고, 틀리면 멈추며, 필요할 때 인간에게 돌아오는 루프를 설계하는 일이 될지도 모릅니다.

• Akshay Pachaar, “Loop Engineering Clearly Explained”
• Addy Osmani, “Loop Engineering”
• Business Insider, “Forget prompt engineering: 'Loop engineering' is all the rage now”
• Zenn, “Loop Engineering 입문: AI 코딩 에이전트를 구동하는 시스템을 설계한다”