Post
Loop Engineering: 에이전트에 프롬프트하지 말고, 프롬프트하는 루프를 설계하라
원문: Addy Osmani — “Loop Engineering: designing the systems that prompt agents” 한국어 소개: GeekNews, 시각언어연구소 전편: Harness Engineering: 에이전트 우선 소프트웨어 개발 방법론 — 이 글은 그 다음 칸이다 작성: 2026.07.22 목적: 하네스 다음 단계인 “루프”를 정의·위계·구성요소·리스크·실행 가이드까지 한 번에 정리한다
0. 한 줄 요약
지난 2년은 좋은 프롬프트를 쓰는 법을 배우는 시간이었다. 이제 무게중심은 에이전트를 대신 찔러 주는 시스템(루프)을 설계하는 법으로 옮겨간다.
“더 이상 코딩 에이전트에 프롬프트하지 마라. 에이전트에게 프롬프트하는 루프를 설계하라.” — Peter Steinberger
“이제 나는 Claude에 직접 프롬프트하지 않는다. Claude에 프롬프트하고 다음 할 일을 정하는 루프를 돌린다. 내 일은 루프를 작성하는 것이다.” — Boris Cherny (Anthropic, Claude Code)
서로 다른 진영의 두 사람이 독립적으로 같은 말을 했다는 점이 핵심이다. 이건 한 도구의 마케팅이 아니라 방향이다.
1. Loop Engineering이란?
1.1 정의
루프(Loop) 는 목적을 정의하면 AI가 완료될 때까지 반복하는 재귀적 목표(recursive goal) 다.
사람이 매 턴 다음 프롬프트를 쳐 주는 대신, 작업을 찾아 분배하고 → 검증하고 → 완료를 기록하고 → 다음 작업을 결정하는 작은 시스템을 만들어 그 시스템이 에이전트를 찌르게 한다.
예전: 사람 → 프롬프트 → 답 확인 → 프롬프트 → 답 확인 → ... (계속 붙어 있어야 함)
루프: 사람 → [목표·검증·중단조건 설계] → 시스템이 알아서 반복 → 사람은 결과만 검토
1.2 개념적 위계: Prompt → Context → Harness → Loop
전편에서 Prompt → Context → Harness까지 정리했다. 루프는 그 네 번째 칸이다.
| 차원 | Prompt | Context | Harness | Loop |
|---|---|---|---|---|
| 관심 범위 | 단일 프롬프트 | 단일 추론의 입력 | 시스템 전체(환경) | 여러 실행에 걸친 운영 |
| 핵심 질문 | 어떻게 말할까? | 무엇을 보여줄까? | 무엇을 방지·측정·수정할까? | 누가·언제 이 하네스를 돌릴까? |
| 사람의 위치 | in the loop | in the loop | on the loop | on the loop (자율) |
| 비유 | 문장 | 인수인계 문서 | 자동차(차체·환경) | 엔진(스스로 도는 심장) |
네 가지는 대체 관계가 아니라 누적 관계다. 좋은 루프 안에도 좋은 하네스·컨텍스트·프롬프트가 전부 필요하다. 다만 가장 큰 지렛대(leverage)가 “루프 설계”로 이동했다.
1.3 in the loop → on the loop
가장 짧게 요약하면 사람의 역할 이동이다.
- in the loop: 결과물을 직접 고친다. 매 턴 개입한다.
- on the loop: 결과물이 아니라 루프(하네스) 자체를 고친다. 개별 결과는 검증만 한다.
Böckeler의 Relocating Rigor(엄격함의 재배치)와 같은 논리다. 필요한 규율의 총량은 줄지 않는다. 적용 위치가 코드 → 하네스 → 루프로 옮겨갈 뿐이다.
2. 루프의 순환 구조
목표(Goal) → 계획(Plan) → 실행(Act) → 관찰(Observe) → 검증(Check) → 수정(Revise)
↑ │
└──────────── 검증 미통과 시 회귀 ─────────────┘
│
완료(Done) → 정지
핵심은 검증 가능한 정지 조건이다. “끝날 때까지 무한정 돌려라”는 즉시 붕괴한다. 완료를 스스로 판정할 수 있어야 사람이 자리를 뜰 수 있다.
3. 루프의 6대 구성요소
불과 1년 전만 해도 이걸 하려면 bash 스크립트 더미를 직접 짜야 했지만, 지금은 구성요소가 제품(Claude Code · Codex)에 그대로 탑재되어 있다. 이름만 조금 다를 뿐 능력은 동일하다.
| # | 구성요소 | 역할 | 한 줄 |
|---|---|---|---|
| 1 | Automations | 루프의 심장 박동 | 일정마다 스스로 발동해 할 일을 발견·분류(triage) |
| 2 | Worktrees | 충돌 방지 | 여러 에이전트가 동시에 일해도 파일이 안 부딪히게 작업 폴더 분리 |
| 3 | Skills | 프로젝트 지식 | 규칙·절차·”이건 이렇게 안 한다”를 적어두면 매 실행마다 읽음(SKILL.md) |
| 4 | Plugins / Connectors | 도구 연결 | 이슈 트래커·DB·Slack 등 실제 도구에 연결(MCP 표준) |
| 5 | Sub-agents | 만들고 검사 | 코드 쓰는 쪽과 검사하는 쪽을 분리 |
| 6 | Memory | 대화 밖 기억 | 완료한 것·다음 할 것을 파일/보드에 기록 |
3.1 왜 Memory가 디스크에 있어야 하나
모델은 실행 사이에 모든 것을 잊는다. 그래서 상태는 컨텍스트(대화)가 아니라 디스크(markdown 파일, 이슈 보드)에 있어야 한다.
에이전트는 잊어도, 저장소(repo)는 잊지 않는다.
이 상태 파일이 루프의 척추다. 오늘 어디까지 시도했고 무엇이 통과했으며 무엇이 열려 있는지를 기억하기에, 내일 아침 실행이 오늘 멈춘 지점에서 이어진다.
3.2 Skills = 의도 부채(intent debt)를 갚는 곳
에이전트는 매 세션을 차가운 상태로 시작하고, 의도의 빈틈을 자신만만한 추측으로 메운다. Skill은 그 의도를 외부에 적어둔 것이다. 컨벤션·빌드 단계·”그 사건 때문에 이렇게는 안 한다” 같은 걸 한 번 적어두면 매 실행마다 읽는다. 없으면 루프가 매 사이클 프로젝트를 0에서 재유도하고, 있으면 복리처럼 누적된다.
4. 두 프리미티브: /loop 과 /goal
두 도구 모두 이 둘을 제공한다. 차이는 언제 멈추느냐다.
/loop |
/goal |
|
|---|---|---|
| 정지 | 정해진 주기마다 재실행 (끝 미정) | 조건이 참이 될 때까지 (끝 정함) |
| 용도 | 감시·점검 (“5분마다 배포 상태 확인”) | 목표 달성 (“test/auth 전부 통과 + lint clean”) |
4.1 핵심 안전장치: 채점자를 분리한다
/goal은 매 턴마다 별도의 작은 모델이 “정말 끝났는지”를 검사한다. 코드를 쓴 에이전트가 자기 채점자가 되지 않도록 정지 조건 자체에 maker·checker 분리를 적용하는 것이다.
노트북을 닫아도 계속 돌리려면 전체를 GitHub Actions 같은 서버 자동화로 넘길 수 있고, 에이전트 생애주기 특정 시점에 셸 명령을 발사하는 hooks도 쓸 수 있다.
5. Maker / Checker 패턴
루프에서 가장 유용한 구조는 단연 코드를 쓰는 쪽과 검사하는 쪽의 분리다.
코드를 쓴 모델은 자기 숙제를 채점할 때 너무 관대하다. 다른 지시문과 때로는 다른 모델을 가진 두 번째 에이전트가, 첫 번째가 스스로 납득해 버린 것을 잡아낸다.
1. 파일 읽기 · 문제 위치 파악
2. [Maker] 코드 수정 실행
3. [Checker] 테스트·빌드 후 에러 로그 분석 (때로는 다른 모델)
4. 불합격 → 1단계로 회귀. 통과할 때까지 자율 반복
루프는 보지 않는 동안 돈다. 그래서 신뢰할 수 있는 검증자(verifier)가 있어야 자리를 뜰 수 있다. /goal이 내부적으로 하는 일도 결국 이것 — 새 모델이 작업한 쪽 대신 완료 여부를 판단한다.
6. 하나의 루프는 어떻게 생겼나
합쳐 놓으면 단일 대화창이 작은 제어판으로 바뀐다.
매일 아침 [Automation] 이 repo에서 실행
└→ [Skill(triage)] 호출: 어제의 CI 실패·열린 이슈·최근 커밋을 읽어 [Memory] 파일에 기록
└→ 할 가치가 있는 항목마다 [Worktree] 를 열어
└→ [Maker sub-agent] 가 수정 초안 작성
└→ [Checker sub-agent] 가 프로젝트 Skill·기존 테스트로 리뷰
└→ [Connector] 가 PR을 열고 티켓을 갱신
└→ 처리 못한 것은 사람 확인함(triage inbox)으로
핵심은 이 단계들 중 어느 것도 매번 프롬프트하지 않았다는 점이다. 한 번 설계했을 뿐이다.
7. 냉정한 현실: 4대 리스크
자동화의 단물은 달지만, 통제되지 않은 루프의 청구서는 차갑고 무겁다.
| 리스크 | 내용 |
|---|---|
| 💸 비용 폭탄 | 퇴근길에 켜둔 루프가 단일 모듈 수정에 4~6시간·약 1억 토큰을 소모한 실증 사례. 사용량 과금 구조에서 설계 실수 한 번이 재무 타격 |
| 🌀 모델 붕괴(Model Collapse) | AI가 스스로 만든 편향된 산출물을 검증 없이 다시 입력으로 먹으면 품질이 하향 평준화되며 무너짐. “가짜 성공에 도취”되는 되먹임 |
| 📉 이해 부채(comprehension debt) | 내가 직접 쓰지 않은 코드를 빨리 출하할수록, 존재하는 것과 실제로 이해하는 것 사이 간극이 벌어짐 |
| 😴 인지적 항복(cognitive surrender) | 루프가 알아서 도니 의견 갖기를 멈추고 돌려받은 걸 그대로 수용. 같은 도구가 사람에 따라 정반대 결과를 냄 |
루프 엔지니어링은 “많이 돌게 하는 기술”이 아니라 “제때 멈추는 기술” 이어야 한다. 이상 징후가 보이면 안전하게 자동 중단하고 사람의 통제권으로 복귀시키는 중단 조건 설계가 핵심이다.
역설적으로, 잘 설계한 루프는 비용을 줄인다. 공개된 하네스 실험에서도 무작정 도는 버전보다 정교하게 통제된 버전이 품질은 같으면서 비용은 더 낮았다. 관건은 “얼마나 오래 도느냐”가 아니라 “얼마나 정확히 멈추느냐”다.
8. 루프 설계 6대 체크리스트
안정적인 자율 루프는 아래 여섯 뼈대를 반드시 갖춰야 한다.
- Goal — 무엇을 완수해야 루프가 끝나는가
- Context — 연산 중 참고할 규칙·스타일 가이드
- Tools — 실제 실행 가능한 도구·권한 범위
- Check Criteria — 성공·실패를 정량적으로 판단하는 기준
- State Memory — 어디까지 진행됐는지 아카이빙
- Stop Condition — 무한 루프를 막고 사람에게 판단을 이양하는 탈출 규칙
도입 초기에는 4(검증 기준) 과 6(중단 조건) 을 가장 먼저, 가장 보수적으로 잡아라. 이 둘이 비용 폭탄과 가짜 성공을 막는 안전벨트다.
9. 실행 가이드: 무엇부터 루프로 만들까
9.1 좋은 후보의 3원칙
루프에 맞는 작업은:
- 반복적이고
- 성공·실패를 기계가 판정 가능하며
- 실수해도 되돌릴 수 있는 작업
9.2 시작하기 좋은 작업
| 작업 | 정지 조건 예 |
|---|---|
| 야간 로그 분류·요약 | 오늘치 로그 전부 분류 완료 |
| 회귀 테스트 통과까지 수정 | 기존 테스트 전부 green + lint clean |
| 코드·쿼리 표준 점검 | 정적 검사 규칙 위반 0건 |
| 의존성 업그레이드 후 빌드 복구 | 빌드 성공 + 핵심 시나리오 통과 |
9.3 반드시 사람 승인을 끼우는 지점
- 운영 데이터의 직접 변경
- 비가역 배포·릴리스
- 위험 명령(삭제·강제 푸시 등)의 무승인 실행
- 민감정보의 외부 전송
“자동화 과신” 대신 문서 + 읽기 전용 접근 + 사람 QA 조합이 안전한 출발점이다.
10. 결론: Build the loop, stay the engineer
루프는 일하는 방식을 바꿀 뿐 사람을 지우지 않는다. 오히려 루프가 좋아질수록 사람의 판단이 더 날카로워야 한다.
- 검증은 여전히 사람 몫이다. “done”은 증명이 아니라 주장이다. 동작을 확인한 것만 출하하라.
- 이해를 방치하지 마라. 루프가 만든 것을 읽지 않으면 이해 부채가 복리로 쌓인다.
- 레버리지가 이동했다. 일이 쉬워진 게 아니라, 실력의 승부처가 “루프의 품질”로 옮겨갔을 뿐이다.
같은 루프를 만든 두 사람 중 한 명은 깊이 이해한 일을 더 빨리 하고, 다른 한 명은 일을 이해하지 않으려고 그것을 쓴다. 루프는 그 차이를 모르지만, 당신은 안다.
Build the loop, stay the engineer — 루프를 만들되, 그저 시작 버튼을 누르는 사람이 아니라 끝까지 엔지니어로 남을 사람처럼 만들 것.
참고
- Addy Osmani, Loop Engineering: designing the systems that prompt agents
- GeekNews — 루프 엔지니어링
- 시각언어연구소 — 하네스 다음, 루프 엔지니어링
- 전편: Harness Engineering: 에이전트 우선 소프트웨어 개발 방법론
댓글