이 글은 프롬프트 엔지니어링 이후의 다음 단계로 등장한 ‘루프 엔지니어링(loop engineering)’ 개념을 정리합니다. 단순히 코딩 에이전트에게 잘 묻는 방법을 넘어서, 에이전트가 스스로 작업을 반복하고 판단하도록 만드는 시스템 설계 관점의 변화를 다룹니다. 왜 프롬프트 최적화가 한계에 다다랐는지, 루프란 무엇이며 어떻게 설계해야 하는지, 그리고 이 접근이 가진 위험과 시사점을 중심으로 설명합니다.
프롬프트에서 루프로: 추상화 수준의 변화
코딩 에이전트와의 상호작용은 계속 추상화되고 있습니다.
처음에는 프롬프트를 작성했고, 이후에는 컨텍스트를 정교하게 설계했습니다. 이제는 그 다음 단계로 “프롬프트를 직접 쓰지 않고, 프롬프트를 생성하는 루프를 설계하는 것”이 등장했습니다.
이 변화의 핵심은 질문 방식의 개선이 아니라, 질문을 자동으로 만들어내는 구조 자체를 만드는 것입니다. 즉, 에이전트를 직접 다루는 것이 아니라 에이전트를 움직이는 시스템을 설계하는 단계로 넘어간 것입니다.
“더 이상 프롬프트하지 말고, 루프를 설계하라”
이 관점을 명확하게 드러낸 발언들이 있습니다.
Boris Cherny는 이렇게 말합니다.
“나는 더 이상 Claude를 프롬프트하지 않는다. Claude를 프롬프트하는 루프를 돌린다. 내 일은 루프를 작성하는 것이다.”
Peter Steinberger 역시 같은 메시지를 전합니다.
이 흐름을 Addy Osmani는 “루프 엔지니어링”, 즉 사람이 하던 프롬프트 작업을 시스템으로 대체하는 것이라고 정의합니다.
중요한 점은 이것이 기존 에이전트를 더 잘 쓰는 요령이 아니라는 것입니다.
루프 엔지니어링은 전혀 다른 솔루션 아키텍처입니다.
- 에이전트로 문제를 푸는 것이 아니라
- 문제를 반복적으로 해결하는 시스템을 만든다
- “무엇을 물을까?”가 아니라
- “어떤 시스템이 원하는 결과를 지속적으로 만들어내는가?”를 고민합니다
루프 엔지니어링을 오해하면 생기는 문제
많은 팀이 루프 엔지니어링을 이렇게 오해합니다.
“기존 레포지토리에서 코딩 에이전트를 자동으로 더 잘 돌리는 방법”
하지만 실제로는 그렇지 않습니다.
루프 엔지니어링은 열려 있는 에디터에서 출발하지 않습니다.
처음부터 시스템 설계로 접근해야 합니다.
설계 시 반드시 답해야 할 질문들은 다음과 같습니다.
- 이 루프가 반복적으로 해결해야 할 문제는 무엇인가?
- 루프가 스스로 발견할 수 있는 작업 단위는 무엇인가?
(예: 실패한 테스트, 새로운 이슈, 오래된 의존성, 고객 리포트) - “완료(done)”를 어떻게 기계적으로 검증할 것인가?
- 실행 주기, 예산 한도, 상태(state)는 어떻게 관리할 것인가?
- 어디에서 인간에게 판단을 다시 넘길 것인가?
이 질문에 답하지 않은 상태에서 루프를 만드는 것은, 단순 자동화 이상도 이하도 아닙니다.
루프를 구성하는 핵심 요소
정리하면 하나의 루프는 다음과 같은 요소로 구성됩니다.
- 스케줄링: 언제, 얼마나 자주 실행되는가
- 격리된 Git 작업 환경: 작업 단위별 독립성
- 지속되는 스킬 파일: 루프가 축적하는 지식
- 실행 가능한 도구: 실제로 행동하는 인터페이스(MCP 등)
- 검증 전용 서브 에이전트(Verifier)
- 상태(State): 전체를 연결하고 반복을 가능하게 하는 핵심
이 중에서도 가장 먼저 설계해야 할 것은 검증기(verifier)입니다.
가장 어려운 문제: “Done”을 정의하는 검증기
루프는 목표를 만족시키는 것이 아니라, 당신이 정의한 ‘통과 조건’을 만족시킵니다.
여기서 핵심 문제가 발생합니다.
- Done은 사실이 아니라 주장(claim)이다
- 검증기는 당신이 “확인하라고 한 것만” 확인한다
- 조건이 목표보다 쉬우면, 루프는 잘못된 결과를 정확하게 반복 생산한다
이는 굿하트의 법칙(Goodhart’s Law)이 에이전트 형태로 나타난 것입니다.
제작자(maker)와 검증자(checker)를 분리한다고 해서 자동으로 안전해지지 않습니다.
검증 조건을 설계하는 일 자체가 루프 엔지니어링에서 가장 어려운 작업입니다.
루프의 성패를 가르는 변수는 사람이다
흥미로운 관찰이 있습니다.
같은 루프를 두 사람이 만들었을 때, 완전히 다른 결과가 나온다는 점입니다.
- 한 사람은 이미 잘 이해한 영역에서 속도를 높이는 데 사용하고
- 다른 사람은 이해를 회피하기 위해 루프에 모든 판단을 맡깁니다
루프는 이 차이를 구분하지 못합니다.
그래서 Addy Osmani는 이를 인지적 항복(cognitive surrender)이라고 부릅니다.
- 루프를 설계하는 행위는
- 판단을 강화하면 가속기가 되고
- 판단을 포기하면 위험 요소가 됩니다
비용과 운영: 루프는 인프라 문제다
루프는 매우 빠르게 비용 문제로 이어질 수 있습니다.
- 5분 주기로 실행되는 루프
- 매번 구현 에이전트와 검증 에이전트를 생성
- 토큰 예산은 순식간에 소모
그래서 반복 횟수 제한, 예산 상한, 비용 측정은 선택이 아니라 필수입니다.
이 글이 강조하는 핵심 메시지와도 맞닿아 있습니다.
신뢰성은 모델이 아니라 인프라와 제어 구조에 있다.
루프 엔지니어링은 프롬프트 엔지니어링보다 쉽지 않습니다.
오히려 더 어렵습니다.
왜냐하면 이제 문제는
- “어떻게 물을 것인가”가 아니라
- “어떤 시스템에 판단을 위임할 것인가”이기 때문입니다.
이 글의 결론은 명확합니다.
- 루프를 만들어라
- 하지만 생각을 멈추기 위해서가 아니라, 더 나은 판단을 확장하기 위해 만들어라
- 버튼을 누르는 사람이 아니라, 엔지니어로 남겠다는 전제로 설계하라
이것이 프롬프트 이후 시대의 에이전트 엔지니어링이 요구하는 태도입니다.
From Prompts to Loops: The Next Step of Agent Engineering
The way we talk to coding agents keeps moving up a level of abstraction. First we wrote prompts.
www.linkedin.com
'인공지능' 카테고리의 다른 글
| DSpark: DeepSeek-V4 추론 속도를 최대 85%까지 끌어올린 추측 디코딩 프레임워크 (0) | 2026.06.29 |
|---|---|
| Claude 사용 로그로 본 AI 활용 방식의 변화와 노동의 미래 (0) | 2026.06.29 |
| 에이전트형 AI가 바꾸는 업무 방식의 변화 (0) | 2026.06.29 |
| Qwen-AgentWorld: 언어 모델이 환경을 이해하고 예측하는 새로운 접근 (0) | 2026.06.28 |
| 오픈AI GPT-5.6 시리즈 공개, 성능·비용·보안 전략까지 한눈에 정리 (0) | 2026.06.28 |
