AI 에이전트를 처음 쓸 때 대부분의 사람들은 '원샷 프롬프트(one-shot prompt)' 방식을 씁니다. '이 코드 버그 고쳐줘', '이 문서 요약해줘'처럼 한 번 물어보고, 답을 받으면 끝입니다. 간단한 작업에는 이것으로 충분합니다. 하지만 복잡한 작업에서는 한계가 분명하게 드러납니다.
원샷의 한계: 야근하는 인턴
원샷 프롬프트는 '밤새 작업하고 아침에 결과물을 올려놓는 인턴'에 비유할 수 있습니다. 중간에 막히는 부분이 생겨도 혼자 추측해서 진행하고, 결과물이 맞는지 스스로 검증하지 못하며, 다음에 비슷한 작업을 할 때도 이전 경험이 전혀 남아 있지 않습니다.
- 중간 오류가 있어도 멈추지 않고 끝까지 달립니다 — 결과물이 틀릴 수 있습니다.
- 맥락이 길어지면 초반 지시사항을 잊어버립니다 — 컨텍스트 유실이 발생합니다.
- 성공했는지 실패했는지 기계적으로 확인하지 않습니다 — 주관적 판단에 의존합니다.
- 다음 작업에서 같은 실수를 반복합니다 — 학습이 없습니다.
루프 엔지니어링(Loop Engineering)이란
루프 엔지니어링은 에이전트를 '한 번 시키고 끝'이 아니라, 반복하는 사이클(cycle)로 운용하는 방식입니다. 각 반복마다 에이전트는 현재 상태를 파악하고, 행동하고, 결과를 확인하고, 기록하고, 다음 단계를 결정합니다.
기본 에이전트 루프의 5단계
- 찾기(Observe): 현재 상태를 읽습니다. 파일, 테스트 결과, 이전 기록을 확인합니다.
- 실행(Act): 목표를 향한 행동을 취합니다. 코드 수정, API 호출, 파일 작성 등입니다.
- 검증(Verify): 행동의 결과를 기계적으로 확인합니다. 테스트 실행, 타입 체크, 린트 등입니다.
- 기록(Record): 무엇을 했고, 결과가 어땠는지 외부 파일에 기록합니다.
- 결정(Decide): 목표를 달성했으면 종료, 아니면 다음 반복을 시작합니다.
루프가 강력한 이유
루프의 핵심 강점은 피드백이 즉시 반영된다는 것입니다. 테스트가 실패하면 그 정보가 다음 반복의 입력이 됩니다. 이전 시도의 기록이 남아 있어 같은 실수를 반복하지 않습니다. 인간이 매 단계를 직접 확인하지 않아도 에이전트가 스스로 방향을 바로잡을 수 있습니다.
| 항목 | 원샷 프롬프트 | 루프 엔지니어링 |
|---|---|---|
| 중간 오류 처리 | 무시하고 계속 | 감지하고 방향 전환 |
| 성공 확인 | 주관적 판단 | 기계적 검증 |
| 기록 | 없음 | 외부 상태 파일에 기록 |
| 반복 작업 | 매번 새로 지시 | 자동 반복 + 학습 |
| 적합한 작업 | 단순·단발성 | 복잡·반복·장기 |
언제 루프를 쓸까
모든 작업에 루프가 필요한 것은 아닙니다. '이 함수 이름 좀 바꿔줘' 같은 단순 작업은 원샷으로 충분합니다. 하지만 CI 파이프라인 수리, 대규모 리팩터링, 자동 PR 리뷰처럼 여러 단계가 있고 중간 검증이 필요한 작업에는 루프가 훨씬 안전하고 효율적입니다.
원샷 vs 루프 판단 프롬프트
아래 작업이 원샷 프롬프트로 충분한지, 루프가 필요한지 분석해 줘.
[작업 내용]
{여기에 작업 설명}
다음 기준으로 판단해 줘:
1. 단계 수: 3단계 이상이면 루프 고려
2. 검증 가능성: 기계적으로 성공 여부를 확인할 수 있는가
3. 반복성: 비슷한 작업이 반복될 예정인가
4. 리스크: 실패해도 쉽게 롤백 가능한가
판단 결과와 이유를 알려주고, 루프가 필요하다면 기본 사이클을 설계해 줘.루프가 필요한지 판단하는 빠른 기준: '이 작업이 실패했을 때 스스로 발견할 방법이 있는가?' — 있으면 루프를 설계하세요. 없으면 먼저 검증 방법부터 만드세요.
루프는 잘못 설계하면 오히려 위험합니다. 검증 없는 루프는 잘못된 방향으로 계속 달릴 수 있습니다. 루프를 만들기 전에 반드시 '성공 기준'을 기계적으로 정의하세요.