루프 엔지니어링 기초: AI 작업의 반복과 종료 조건 정하기
루프 엔지니어링은 AI 작업을 실행하고 결과를 검사한 뒤 계속할지 멈출지 정하는 반복 절차를 설계하는 일입니다. Ralph 사례와 기존 그림을 살펴보고, 가상 메모로 수정 후 재검사와 성공 종료, 자료 부족에 따른 중단을 구분합니다.
목차
세 줄로 먼저 읽기
이번 방문에서 한 편은 바로 볼 수 있습니다.
AI에게 “빠진 항목을 고쳐줘”라고 요청하고 결과를 확인한 뒤 다시 수정을 요청하는 일이 있습니다. 이 과정을 반복할 때는 무엇을 확인하고 언제 멈출지 정해야 합니다. 루프(loop)는 이처럼 되풀이하는 흐름을 뜻합니다.
루프 엔지니어링은 작업 실행, 결과 검사, 다음 행동과 종료를 정하는 반복 절차를 설계하는 일입니다. 에이전트는 도구를 사용해 작업하는 AI 시스템입니다. 반복을 자동화할 수도 있지만 사람이 확인하는 단계를 포함할 수도 있습니다.
위 그림은 코드 작업의 반복을 간추린 예시입니다. 명세는 만들 결과의 조건, 빌드는 코드를 실행하거나 배포할 형태로 만드는 과정, 테스트는 예상한 결과가 나오는지 확인하는 검사입니다. 그림에는 매회 새 에이전트가 시작한다고 적혀 있지만 모든 루프가 그런 것은 아닙니다. 같은 대화를 이어 쓰거나 상태를 저장해 이어받는 구성도 있습니다. 실제 반복에는 성공했을 때 나가는 경로와 실패했을 때 멈추는 경로도 필요합니다.
루프 엔지니어링은 무엇을 말하는 걸까요?
각 용어를 어느 것이 더 발전했는지 순서로 외우기보다 무엇을 정하는지 구분하면 됩니다.
- 프롬프트 엔지니어링: 에이전트에게 주는 요청과 지시를 구성합니다.
- 컨텍스트 엔지니어링: 에이전트가 참고할 문서와 코드, 규칙 등 정보를 구성합니다.
- 하네스 엔지니어링: 사용할 도구와 실행 환경, 권한과 검사 절차를 구성합니다.
- 루프 엔지니어링: 언제 실행하고 어떤 결과에 따라 반복하거나 멈출지 구성합니다.
서로 겹치는 설계 관점이며 루프를 만들었다고 지시문이나 자료가 필요 없어지지는 않습니다. 하네스 엔지니어링 기초에서 자료와 권한, 검사의 관계를 먼저 볼 수 있습니다.
이 용어가 쓰인 배경
Addy Osmani는 2026년 6월의 Loop Engineering에서 사람이 매번 다음 요청을 입력하는 대신 일을 찾고 맡기고 확인하는 시스템을 설계하는 관점을 제안했습니다. 같은 글은 6월 22일 O’Reilly에도 재게재됐습니다. 글에서 인용한 Peter Steinberger와 Boris Cherny의 발언도 이런 작업 방식의 변화를 설명합니다.
이는 실무자들의 제안이며 모든 사용자가 이미 이런 방식으로 전환했다는 조사 결과는 아닙니다. 단발성 질문이나 직접 확인하며 진행하는 작업에는 대화 방식이 충분할 수 있습니다. 반복 횟수가 많아도 성공 여부를 판단할 기준이 없다면 자동화부터 하기 어렵습니다.
가장 단순한 루프는 어떻게 생겼을까요?
Geoffrey Huntley의 Ralph 기법은 에이전트를 반복 실행하는 사례로 자주 언급됩니다. 아래는 원문에 실린 역사적 예시입니다. 종료 조건이 없는 명령이므로 처음 따라 할 실행 명령으로 쓰지 않습니다. claude-code라는 표기도 원문 표기이며 현재 Claude Code의 일반 실행 명령 claude와 다릅니다.
while :; do cat PROMPT.md | claude-code ; done같은 지시 파일을 프로그램에 반복 전달하는 무한 루프입니다. 이 한 줄만으로 성공 판정이나 비용 제한이 생기지는 않습니다. 주변 자료는 다음 역할을 합니다.
- PROMPT.md: 매회 동일하게 들어가는 지시문. "명세를 읽고, 계획에서 가장 중요한 일 하나를 골라 구현하라"
- specs/ 폴더: 만들 것의 명세를 담은 문서들
- fix_plan.md: 남은 일 목록. 에이전트가 매회 갱신
- 작업 크기 제한: 한 번에 맡길 범위를 작게 정해 결과를 대조하기 쉽게 함
위 그림은 지시문 구성을 단순화한 예시입니다. 현재 공개 원문에는 가장 중요한 10개 일을 고르라는 내용도 있어 그림의 ‘하나’가 원문의 고정 규칙은 아닙니다. 빌드와 테스트에 보조 에이전트 하나를 쓰는 내용도 해당 사례의 선택입니다. 이런 문장은 작업 지침이며 실제 권한이나 프로세스 수를 강제로 제한하지 않습니다.
위 그림에서는 명세와 계획을 마련한 뒤 반복을 시작합니다. 그림의 ‘일이 끝날 때까지’만으로는 충분하지 않습니다. 완료를 무엇으로 확인하는지와 실패가 반복될 때 멈출 기준을 추가해야 합니다. 특정 프로젝트의 성공 사례가 다른 프로젝트에서도 같은 결과를 보장하지는 않습니다.
루프를 잘 쓰려면 무엇을 챙겨야 할까요?
Osmani는 여러 작업을 운영하는 구성으로 다음 도구들을 제안했습니다. 모든 작은 루프에 여섯 가지가 필수인 것은 아닙니다.
- 자동 실행(automations): 정해진 시간에 스스로 시작되는 작업. 매일 아침 이슈를 분류하는 일 등
- 작업 공간 분리(worktrees): Git 작업 폴더를 나눠 수정 충돌을 줄임. 같은 파일을 합칠 때의 충돌과 외부 서비스 공유까지 없애지는 않으며 접근 권한 제한과도 다름
- 스킬(skills): 프로젝트 지식을 문서로 만들어 매번 설명하지 않아도 되게 함
- 연결 도구(connectors): 할 일과 오류를 기록하는 이슈 트래커, 자료를 보관하는 데이터베이스 등 외부 도구와의 연결
- 서브에이전트(subagents): 만드는 역할과 검사하는 역할을 별도 에이전트로 분리
- 외부 상태(external state): 진행 상황을 파일이나 보드에 기록해 다음 반복이 이어받게 함. 새 실행에 이전 대화가 전달되지 않거나 일부만 전달될 수 있으므로 필요한 상태를 명시적으로 전달함
이 중 검사 역할 분리는 공식 기능으로도 들어와 있습니다. 위 도판은 Claude Code 공식 문서의 비교 다이어그램을 한국어로 재구성한 것으로, 결과만 보고하는 서브에이전트와 서로 소통하며 일을 나누는 에이전트 팀의 구조 차이를 보여줍니다. 별도 검토자는 다른 관점을 줄 수 있지만 정확성을 보장하지 않습니다. 검토자에게도 원자료와 완료 기준이 필요합니다. 단순한 작업에서는 한 에이전트와 직접 검증으로 충분할 수 있으며, 팀 기능의 제공 상태와 제약은 공식 문서를 확인합니다.
구성 요소보다 먼저 정할 것이 두 가지 있습니다. 종료 조건과 실패 탈출구입니다. “정해 둔 검사가 통과하고 요청한 결과가 확인되면 성공 종료”와 “반복 횟수, 시간, 비용 한도에 닿거나 같은 오류가 계속되면 실패 중단”을 따로 정합니다. 테스트를 지우거나 검사 기준을 낮춰 통과시키지 못하도록 수정 범위도 정합니다.
사람은 그럼 무엇을 해야 할까요?
루프가 일을 대신한다면 우리는 무엇을 하는지 궁금해질 수 있습니다. Osmani는 후속 글 Own the Outer Loop에서 이를 안쪽 루프와 바깥 루프로 구분했습니다. 조사하고, 구현하고, 검증하고, 반복하는 안쪽 루프는 에이전트가 돌리고, 그 결과를 내보낼지 말지 판정하고 그 판정을 설명할 책임을 지는 바깥 루프는 사람이 갖는다는 구분입니다.
이는 역할을 나누는 한 가지 방법입니다. 자동 결과를 확인 없이 받아들이면 잘못된 변경을 놓치거나 원인을 설명하기 어려워질 수 있습니다. 반복을 늘리기 전에 결과를 검토할 시간과 처리할 수 없는 문제의 인계 방법을 정합니다.
작은 반복을 직접 판정해 봅니다
다음은 실제 일정과 관계없는 가상 메모입니다. 계정 연결이나 AI 호출 없이 종이나 메모 앱에서 할 수 있습니다.
[원자료]
1. 토요일 오전: 책 반납
2. 토요일 오후: 장보기
3. 일요일 오전: 산책
[초안]
토요일 오전에 책을 반납하고 오후에 장을 봅니다.
[검사 기준]
세 일정의 요일, 시간대, 할 일이 모두 들어 있어야 합니다.
원자료에 없는 시각과 장소는 넣지 않습니다.
수정 시도는 최대 2회이며 같은 오류가 연속 두 번의 검사에서 나오면 중단합니다.초안에서 빠진 것은 일요일 오전 산책입니다. ‘일요일 오전에 산책합니다’를 추가한 뒤, 이미 있던 토요일 두 일정까지 다시 대조합니다. 세 일정이 모두 맞으면 성공 종료입니다. 두 번째 수정까지도 일정이 빠져 있다면 횟수 한도에 따른 실패 중단이며 성공으로 기록하지 않습니다.
앞의 작업을 종료한 뒤 별도의 연습으로 원자료의 세 번째 줄을 3. 일요일: 산책으로 바꿉니다. 새 자료로 다시 시작할 때는 ‘요일과 할 일을 보존하고 시간대가 없으면 미확인으로 표시’라는 새 기준을 정합니다. 실패한 검사를 통과시키려고 기존 목표를 낮추는 것이 아니라, 새 자료에 맞는 다른 요청을 시작하는 것입니다. 실제 일정이 미정인지까지는 알 수 없습니다. 이전 초안의 오전을 그대로 유지하면 근거 없는 정보가 됩니다. ‘일요일에 산책합니다. 시간대는 원자료에서 확인할 수 없습니다’로 고친 뒤 다른 두 일정도 대조합니다.
만약 요청이 ‘세 일정의 정확한 시간대까지 확정’인데 원자료에 시간대가 없다면 계속 고쳐도 해결할 수 없습니다. 이런 경우는 자료 부족으로 중단하고 빠진 정보를 확인해야 합니다. 반복 횟수를 늘리는 것으로 정답을 만들 수는 없습니다.
이 흐름을 실행 절차로 쓰면 다음과 같습니다. 아래는 프로그램에 바로 붙여 넣는 코드가 아닌 의사코드입니다.
원자료와 완료 기준, 반복/시간/비용 한도를 읽는다
필수 자료가 없으면 시작하지 않고 자료 부족으로 기록한다
다음 실행에 필요한 시간과 비용 범위를 확인한다
한도 안에서 결과를 만들고 실행 중에도 제한을 감시한다
결과를 원자료와 기준에 대조한다
일치하면 성공으로 끝낸다
필요한 자료가 없으면 자료 부족으로 중단한다
반복/시간/비용 한도에 닿으면 한도 중단으로 끝낸다
같은 오류가 연속 두 번이면 원인 확인을 위해 중단한다
그렇지 않으면 다음 실행 전 한도를 확인하고 오류를 수정해 다시 대조한다
마지막 결과와 검사 근거, 종료 이유를 기록한다글로 적은 비용 한도가 결제를 자동으로 차단하지는 않습니다. 실제 운영에서는 사용하는 도구의 예산과 실행 제한 기능을 연결하고, 한 번의 요청이 끝나기 전에도 제한할 수 있는지 확인합니다.
예약 실행과 목표 달성 반복은 다릅니다
매주 글을 점검하는 예약 실행은 정해진 때 작업을 시작하는 기능입니다. 한 글의 오류를 고치고 재검사하는 목표 반복은 한 작업 안에서 계속할지 판단하는 기능입니다. 둘을 함께 쓸 수도 있지만 같은 뜻은 아닙니다.
블로그 제목 점검이라면 처음에는 글 하나의 제목과 내용이 맞는지 직접 확인하고 수정 제안을 만듭니다. 검색 유입 감소만 보고 제목이 원인이라고 단정하지 않습니다. 원자료와 검사 방법이 준비된 뒤 반복 대상과 주기, 실패 시 기록할 내용, 게시 여부를 결정할 사람을 정합니다. 예약을 켰다는 사실이 게시 권한까지 부여하지는 않습니다.
반복을 여러 수준으로 나누어 볼 수도 있습니다. 아래 기존 설명 그림은 토큰 생성, 도구를 사용하는 한 차례 작업, 목표 달성 반복, 반복 절차를 수정하는 작업을 구분합니다. 토큰은 모델이 글을 처리하는 단위이며 반드시 단어 하나와 같지는 않습니다.
그림의 초, 분, 시간, 일은 이해를 위한 예시이지 고정 실행 시간은 아닙니다. 토큰 생성이 문장 끝에서 항상 종료되는 것도 아닙니다. 처음부터 이런 여러 수준을 구현하기보다, 작업 하나에서 완료와 중단을 구분하고 수정 후 결과를 다시 확인하는 연습부터 시작할 수 있습니다.
Sources
제대로 이해했는지 한 문제로 확인해 볼까요?
답을 고르면 바로 풀이가 나와요.
루프 엔지니어링에서 에이전트를 반복 실행시키기 전에 반드시 정해 두어야 하는 것은 무엇일까요?
이 글이 도움이 되었나요?
메일, 회의록, 리포트처럼 반복되는 일을 AI로 자동화하는 순서와 안전장치를 다룹니다
코스 전체 보기 →
새 글과 AI 소식을 메일로 받아 보세요
AI가 바꾸는 일과 도구, 측정 실무 이야기를 매주 한 번 보내 드려요.