AI 에이전트 시대, 프롬프트보다 루프를 설계하라

AI 에이전트 생산성의 핵심이 개별 프롬프트에서 파일, 메모리, 검증 게이트로 구성된 반복 루프로 이동하는 흐름을 정리합니다.

요즘 AI 에이전트를 쓰는 사람들은 같은 문제를 겪는다. 처음 한두 번은 놀랍게 잘하지만, 작업이 길어지면 맥락을 잃고, 검증 없이 완료했다고 말하고, 같은 실수를 반복한다. 이 문제는 대부분 “프롬프트가 부족해서”가 아니라, 에이전트가 반복해서 일할 루프가 없어서 생긴다.

TL;DR

AI 에이전트 생산성의 중심은 “좋은 프롬프트”에서 “좋은 루프”로 이동하고 있다.
좋은 루프는 작업 발견 → 계획 → 실행 → 검증 → 기록 → 다음 반복을 파일과 도구로 고정한다.
AGENTS.md, PRD.md, progress.md, verification.md, STATE.md 같은 문서는 에이전트의 외부 기억장치다.
에이전트가 만든 결과물은 자기 확신이 아니라 테스트, 타입 체크, 린트, 스크린샷, replay eval 같은 hard signal로 통과시켜야 한다.
창업자와 PM의 새 역할은 “AI에게 일을 시키는 사람”이 아니라 “AI가 반복 가능하게 일하는 운영체제를 설계하는 사람”이다.

왜 지금 중요한가

AI 코딩 도구와 에이전트는 이미 충분히 강해졌다. 문제는 이제 “가능하냐”가 아니다.

문제는 이것이다.

같은 품질로, 여러 번, 긴 작업을, 안전하게 반복할 수 있느냐.

최근 수집한 자료들은 놀랄 정도로 같은 방향을 가리킨다.

LinkedIn의 Loop Engineering 글은 에이전트 실패의 병목이 프롬프트가 아니라 반복 구조 부재라고 말한다.
How to Create Loops with Claude는 프롬프트 하나보다 자동화, worktree, skills, connector, sub-agent, memory로 구성된 루프가 더 중요하다고 정리한다.
Context Engineering for AI Agents는 에이전트 성능 저하가 모델 자체보다 “모델이 무엇을 보고 있는가”에서 온다고 설명한다.
NAVER D2 발표는 스펙 변경 → 결함 탐지 → 프롬프트 최적화 → 검증으로 이어지는 closed-loop 파이프라인을 실제 서비스 맥락에서 보여준다.
Claude Code 에이전트 운영 영상들은 창업자/개발자가 직접 코딩하는 사람에서 계획과 검증의 director로 이동하고 있음을 보여준다.

즉, 흐름은 명확하다.

프롬프트 엔지니어링은 루프 엔지니어링의 일부가 되고 있다.

핵심 흐름

1. 프롬프트는 한 번의 응답을 만든다

프롬프트는 여전히 중요하다. 하지만 프롬프트는 기본적으로 “한 번의 샘플링”을 잘 만들기 위한 도구다.

짧은 질문에는 충분하다.

하지만 에이전트 작업은 다르다.

에이전트는 파일을 읽고, 코드를 고치고, 테스트를 돌리고, 실패를 보고, 다시 고친다. 이 과정이 10단계, 20단계로 길어지는 순간 문제가 생긴다.

원래 목표가 중간 컨텍스트에 묻힌다.
도구 출력이 너무 많아진다.
실패 원인을 다음 실행에 전달하지 못한다.
검증하지 않은 상태에서 “완료”라고 말한다.

이때 더 긴 프롬프트를 쓰는 것은 근본 해결책이 아니다. 오히려 컨텍스트를 더 복잡하게 만들 수 있다.

2. 루프는 반복 가능한 시스템을 만든다

루프는 한 번의 답변이 아니라 반복 구조다.

가장 단순한 루프는 이렇게 생겼다.

목표를 읽는다
필요한 맥락을 찾는다
작업을 계획한다
실행한다
검증한다
실패/결정/다음 액션을 기록한다
다음 실행이 그 기록을 읽는다

이 구조가 있으면 에이전트는 매번 처음부터 시작하지 않는다.

실패는 progress.md에 남고, 제품 판단은 PRD.md에 반영되고, 반복 운영 원칙은 AGENTS.md나 skill로 승격된다.

이게 쌓이면 에이전트는 단순 자동화가 아니라 점점 더 나은 작업 시스템이 된다.

3. 컨텍스트 엔지니어링은 루프의 운영 기술이다

Context Engineering for AI Agents는 중요한 관점을 준다.

에이전트가 망가지는 이유는 “모델이 나빠서”가 아니라 “모델이 지금 잘못된 것을 보고 있어서”인 경우가 많다.

컨텍스트에는 항상 경쟁이 있다.

시스템 프롬프트
도구 정의
도구 출력
대화 이력
검색된 문서
메모리
현재 작업 상태

모든 것을 한 번에 넣으면 좋아질 것 같지만 실제로는 반대다. 컨텍스트가 길어질수록 모델은 중요한 정보를 놓치기 쉽다.

그래서 루프에는 네 가지 전략이 필요하다.

전략	의미	예시
Write	컨텍스트 밖에 기록한다	`progress.md`, `STATE.md`, decision log
Select	지금 필요한 것만 고른다	task-specific context manifest
Compress	긴 자료를 압축한다	digest, summary, checklist
Isolate	작업을 분리한다	worktree, sub-agent, sidecar chat

좋은 루프는 이 네 가지를 의식적으로 설계한다.

실제 사례 / 원문에서 본 신호

Loop Engineering: 파일이 루프를 만든다

Sanguine Kim의 글은 에이전트 루프를 다섯 단계로 정리한다.

Discovery
Planning
Execution
Verification
Iteration

여기서 중요한 것은 이 루프가 “프롬프트 안에서” 만들어지지 않는다는 점이다.

루프는 파일과 운영 구조 안에서 만들어진다.

AGENTS.md: 에이전트의 운영 원칙과 안전 가드레일
customer.md: 누구를 위해 만드는지
PRD.md: 제품 목표, 범위, 성공 기준
progress.md: 현재 상태, 완료된 일, 막힌 일, 다음 액션

이 네 가지는 작은 팀의 운영 문서처럼 보이지만, 사실 에이전트의 외부 기억장치다.

Claude 루프: 자동화 + 메모리 + 검증자

How to Create Loops with Claude는 루프의 구성요소를 여섯 가지로 정리한다.

Automations
Worktrees
Skills
Connectors
Sub-agents
Memory

여기서 가장 실용적인 조언은 단순하다.

처음부터 거대한 시스템을 만들지 말고, 하나의 trigger와 하나의 memory file로 시작하라.

예를 들면 이렇다.

매일 오전 8시:
어제의 CI 실패, open issue, 최근 commit을 읽고
finding을 progress.md에 기록한다.

이 정도만 있어도 일회성 프롬프트보다 훨씬 강하다. 왜냐하면 사람이 다시 시키지 않아도 다음 실행이 이전 상태를 읽기 때문이다.

NAVER D2: 스펙이 바뀌면 프롬프트도 따라온다

NAVER D2 발표는 루프 엔지니어링의 좋은 실무 예시다.

문제는 쇼핑 에이전트의 답변 스펙이 자주 바뀐다는 것이었다. 기존 방식에서는 사람이 프롬프트를 수정하고, 테스트하고, 기존 케이스가 깨지지 않았는지 확인해야 했다.

해결은 다음 구조였다.

Markdown 기반 스펙 저장소
→ 결함 유형별 defect detection
→ 결함 결과를 reward signal로 사용
→ prompt optimization
→ 사람 승인과 검증

특히 중요한 지점은 “모듈을 넘는 결정은 사람이 한다”는 설계다.

에이전트는 자기 모듈 안에서 최적화한다. 하지만 결함을 없애려고 스펙 자체를 바꾸는 일은 사람이 승인한다.

이것이 안전한 루프다.

RSI와 Deployment Simulation: 루프는 judge만큼만 믿을 수 있다

Recursive Self-Improvement 글은 모든 자기개선 시스템을 한 줄로 요약한다.

candidate = mutate(best)
score = evaluate(candidate)
if score > best.score:
    best = candidate

여기서 핵심은 evaluate다.

평가자가 약하면 루프는 좋아지는 것이 아니라 편법을 배운다. OpenAI의 Deployment Simulation도 같은 메시지를 준다. 모델을 배포하기 전 실제 대화 분포에 가까운 데이터로 후보 모델 행동을 replay해 undesired behavior를 추정한다.

즉, 좋은 루프는 생성자보다 검증자가 먼저다.

작은 팀 사업에 주는 힌트

작은 팀의 방향은 “AI 에이전트/서비스와 글로벌 웹 유틸 실험으로 실제 돈을 버는 시스템”에 가깝다.

이 전략에도 루프가 필요하다.

글로벌 유틸 하나를 만들 때의 루프

1. 작은 유틸 페이지를 만든다
2. Search Console / analytics / error log를 본다
3. 사용자 검색 의도와 이탈 지점을 정리한다
4. 개선안을 만든다
5. Build가 수정한다
6. 테스트와 실제 페이지 확인을 통과한다
7. progress.md에 결과와 다음 실험을 남긴다

이 루프가 없으면 매번 새 아이디어를 만들고 잊어버린다.

이 루프가 있으면 작은 유틸이 시간이 지날수록 검색 의도와 제품 품질을 학습한다.

작은 팀 AI 운영에 필요한 기본 패키지

앞으로 AI 에이전트에게 의미 있는 작업을 넘길 때는 최소한 이 패키지가 있어야 한다.

PRD.md
- 문제
- 대상 사용자
- 범위 / 비범위
- 성공 기준

progress.md
- 현재 상태
- 완료된 것
- 막힌 것
- 다음 액션

verification.md
- 실행 명령
- 테스트 기준
- 스크린샷/브라우저 확인 기준
- 실패 시 되돌아갈 루프

이것이 없으면 AI 에이전트는 빠르게 만들 수는 있어도, 반복적으로 좋아지기는 어렵다.

바로 해볼 실험

실험 1. 다음 제품 작업부터 `progress.md`를 강제한다

작업 시작 전에는 에이전트가 progress.md를 읽게 한다. 작업 종료 후에는 반드시 갱신하게 한다.

형식은 짧아야 한다.

# Progress

## Done
- ...

## In Progress
- ...

## Blocked
- ...

## Next
- ...

## Verification
- [ ] test command
- [ ] browser check
- [ ] deployment check

길면 안 읽힌다. 루프 메모리는 짧고 살아있어야 한다.

실험 2. Build 지시문에 acceptance criteria를 넣는다

나쁜 지시문:

이 페이지 예쁘게 만들어줘.

좋은 지시문:

목표: 모바일에서 3초 안에 핵심 기능을 이해하게 한다.
성공 기준:
- Lighthouse mobile performance 90+
- CTA가 첫 화면에 보인다
- 사용자가 입력 없이 예시 결과를 볼 수 있다
검증:
- npm test
- npm run build
- Playwright screenshot 첨부

에이전트는 기준이 있을 때 더 오래 자율적으로 움직일 수 있다.

실험 3. 같은 에이전트가 자기 숙제를 채점하지 않게 한다

생성자와 검증자를 분리한다.

Writer: 구현한다.
Checker: 테스트, 시나리오, 정책 기준으로 실패를 찾는다.
Human: 애매한 제품 판단만 승인한다.

검증자는 “느낌상 괜찮다”가 아니라 hard signal을 봐야 한다.

리스크 / 반론

반론 1. 작은 작업에 문서가 너무 무겁지 않나?

맞다. 모든 작업에 거대한 PRD가 필요한 것은 아니다.

하지만 progress.md 한 장과 verification checklist 3줄은 무겁지 않다. 오히려 에이전트가 삽질하는 시간을 줄인다.

핵심은 문서의 양이 아니라 반복 가능한 상태를 남기는 것이다.

반론 2. 에이전트가 알아서 기억하면 안 되나?

세션 안에서는 기억하는 것처럼 보인다. 하지만 작업이 길어지고, 컨텍스트가 압축되고, 다음 날 다시 시작하면 많은 것이 사라진다.

에이전트는 잊는다. 파일은 잊지 않는다.

그래서 루프의 기억은 대화창이 아니라 저장소에 있어야 한다.

반론 3. 검증까지 자동화하면 너무 느려지지 않나?

검증이 없는 빠른 작업은 나중에 더 느려진다.

특히 AI 에이전트는 자신 있게 틀릴 수 있다. 따라서 최소 검증은 속도를 늦추는 장치가 아니라 재작업을 줄이는 장치다.

결론

AI 에이전트 시대의 생산성은 한 번의 멋진 답변에서 나오지 않는다.

잘 설계된 루프에서 나온다.

프롬프트는 여전히 필요하다. 하지만 프롬프트는 루프 안의 한 부품이다.

앞으로 중요한 역량은 다음 질문에 답하는 능력이다.

에이전트가 무엇을 보고 시작하는가?
실패와 결정을 어디에 기록하는가?
다음 실행은 이전 실행에서 무엇을 배워오는가?
결과물은 어떤 hard signal로 검증되는가?
사람은 어디에서 승인하고 어디에서 빠지는가?

이 질문에 답할 수 있다면, 에이전트는 단순한 도구가 아니라 작은 팀처럼 움직이기 시작한다.

그리고 그 순간부터 창업자의 일은 달라진다.

더 좋은 프롬프트를 쓰는 사람이 아니라, 더 좋은 운영 루프를 설계하는 사람이 이긴다.

Sources

Sanguine Kim — Loop Engineering
How to Create Loops with Claude
Context Engineering for AI Agents
NAVER D2 — 스펙만 바꾸면 프롬프트가 따라옵니다
How to Build Effective Claude Code Agents in 2026
Image: <chatgpt image 2>

Source links

Sanguine Kim — Loop Engineering
How to Create Loops with Claude
Context Engineering for AI Agents
NAVER D2 — 답변 생성 모델 자동화 파이프라인
How to Build Effective Claude Code Agents in 2026