Loop Engineering은 그 정의보다 더 빠르게 퍼지고 있는 용어 중 하나입니다.

이는 보통 두 가지 부정적인 결과를 초래합니다. 어떤 이들은 이를 또 다른 AI 버즈워드 (buzzword)로 치부하며 무시합니다. 다른 이들은 이를 마법처럼 취급합니다. 프롬프트 앞에 /loop를 붙이기만 하면, 자신이 잠든 동안 에이전트가 바로 서비스에 적용 가능한 수준의 결과물을 만들어낼 것이라고 기대합니다.

두 해석 모두 틀렸습니다.

실질적인 정의는 더 간단합니다:

Loop Engineering은 명확한 목표 (goal), 제한된 행동 (bounded action), 검증 (verification), 상태 유지 (state persistence), 그리고 중단 규칙 (stop rules)을 갖춘 반복 가능한 사이클로서 AI 에이전트 작업을 설계하는 관행입니다.

다시 말해, 이것은 프롬프트 트릭 (prompt trick)이 아닙니다. 장기 실행되는 AI 작업을 위한 엔지니어링 규율 (engineering discipline)입니다.

문제점: 당신이 여전히 루프 (loop) 역할을 하고 있습니다

대부분의 개발자는 코딩 에이전트를 다음과 같이 사용합니다:

1. 프롬프트를 작성합니다.
2. 에이전트가 코드를 수정하게 둡니다.
3. 수동으로 테스트를 실행합니다.
4. 실패 내용을 다시 붙여넣습니다.
5. 에이전트에게 다시 시도하라고 요청합니다.
6. 작동할 때까지 또는 포기할 때까지 반복합니다.

AI가 작업을 수행하는 것처럼 보이지만, 실제로는 당신이 여전히 스케줄러 (scheduler), QA 엔지니어 (QA engineer), 상태 관리자 (state manager), 그리고 중단 조건 확인자 (stop-condition checker) 역할을 하고 있습니다.

에이전트는 단일 지시사항을 실행합니다. 결과가 올바른지, 다음 단계가 진행되어야 하는지, 어떤 오류가 중요한지, 무엇이 변경되었는지, 그리고 작업이 언제 완료되는지를 결정하는 것은 바로 당신입니다.

Loop Engineering은 이러한 책임들을 당신의 머릿속에서 꺼내어 명시적인 워크플로우 (workflow)로 옮깁니다.

A 좋은 루프는 에이전트가 시작하기 전에 다음 질문들에 답합니다:

• 완료 (done)란 무엇을 의미하는가?
• 허용된 범위 (scope)는 어디까지인가?
• 각 반복 (iteration)에서 무엇이 일어나야 하는가?
• 결과는 어떻게 검증 (verified)될 것인가?
• 진행 상황은 어디에 기록되는가?
• 에이전트는 언제 멈춰야 하는가?
• 어떤 행동에 인간의 승인이 필요한가?

이것이 바로 변화의 핵심입니다. 프롬프트 엔지니어링 (Prompt Engineering)이 단일 응답을 개선하려고 노력한다면, Loop Engineering은 여러 응답이 검증 가능한 결과로 수렴하도록 만드는 것을 목표로 합니다.

중요한 어휘 (The Vocabulary That Matters)

/goal과 /loop에 대해 이야기하기 전에, 몇 가지 관련된 개념을 분리하여 이해하는 것이 도움이 됩니다.

프롬프트 엔지니어링 (Prompt Engineering)

프롬프트 엔지니어링 (Prompt Engineering)은 좋은 단일 지시문 (single instruction)을 작성하는 것입니다.

예시:

auth 모듈에서 실패하는 테스트를 수정하고 변경된 내용을 설명하세요.

이는 작은 작업에는 효과적일 수 있습니다. 하지만 범위 (scope), 검증 방법 (verification method), 실패 정책 (failure policy), 또는 중단 조건 (stop condition)을 정의하지는 않습니다.

원샷 (one-shot) 요청의 경우에는 괜찮을 수 있지만, 다단계 코딩 작업 (multi-step coding work)에서는 취약합니다.

컨텍스트 엔지니어링 (Context Engineering)

컨텍스트 엔지니어링 (Context Engineering)은 모델이 각 단계에서 무엇을 볼 것인지(지시문, 파일, 도구 출력, 메모리, 로그, 검색 결과, MCP 데이터, 이전 상태 등)를 결정하는 것입니다.

장시간 실행되는 에이전트 (long-running agents)는 매 턴마다 새로운 컨텍스트 (context)를 생성합니다. 단순히 히스토리 (history)를 계속 추가하기만 하면, 모델은 명확성을 얻는 대신 노이즈 (noise)만 더 많이 얻게 됩니다.

훌륭한 컨텍스트 엔지니어링은 신호가 높은 정보 (high-signal information)를 유지하고, 상태 (state)를 에이전트가 다시 읽을 수 있는 파일로 외부화 (externalize)합니다.

하네스 엔지니어링 (Harness Engineering)

하네스 (harness)는 에이전트가 실행되는 환경입니다.

코딩 에이전트 (coding agents)의 경우, 이는 보통 다음을 의미합니다:

• 프로젝트 지시문 (Project instructions): CLAUDE.md, AGENTS.md 또는 유사한 파일
• 권한 규칙 (Permission rules): 에이전트가 자동으로 실행할 수 있는 것과 승인이 필요한 것
• 도구 (Tooling): MCP 서버, 브라우저 액세스, GitHub, 데이터베이스, 디자인 도구
• 훅 (Hooks): 편집 후 포맷팅, 커밋 전 린트 (lint), 도구 호출 로그 기록
• 서브에이전트 (Subagents): 리뷰, 조사, 검증을 위한 별도의 컨텍스트
• 메모리 (Memory): 지속적인 프로젝트 결정 사항 및 반복되는 선호도

루프 (loop)는 이 하네스 위에서 실행됩니다. 하네스가 없다면, 에이전트는 매번 사용자의 프로젝트 구조, 명령, 컨벤션 (conventions), 그리고 경계 (boundaries)를 추측해야 합니다.

추측은 많은 에이전트 실패가 시작되는 지점입니다.

루프 엔지니어링 (Loop Engineering)

가장 작은 단위에서 루프 (loop)는 다음과 같이 보입니다:

목표 읽기 (Read goal) -> 실행 (act) -> 검증 (verify) -> 상태 기록 (write state) -> 계속 또는 중단 (continue or stop)

이것은 전통적인 스크립트 (script)와는 다릅니다.

스크립트는 고정된 단계를 반복합니다. 루프형 에이전트 (looped agent)는 상태 (state)를 평가하고, 다음 행동을 선택하며, 오류를 처리하고, 계획 (plan)을 업데이트합니다.

그러한 유연성은 유용합니다. 하지만 경계 (boundaries)를 정의하지 않는다면 위험할 수도 있습니다.

검증기 (Verifier)

검증기 (verifier)는 증거 계층 (evidence layer)입니다.

검증기는 "이것이 완료되었다고 생각하나요?"라고 물어서는 안 됩니다. 대신 다음과 같은 증거를 확인해야 합니다:

• 테스트가 통과했는가?
• 빌드 (build)가 통과했는가?
• 차이점 (diff)이 허용된 범위 내에 머물러 있는가?
• 링크가 열리는가?
• 스크린샷이 목표 상태 (target state)와 일치하는가?
• 구현 (implementation)이 작성된 수락 기준 (acceptance criteria)을 충족하는가?

가장 좋은 검증기는 종종 작업자 (worker)와 분리되어 있습니다. 동일한 에이전트가 동일한 컨텍스트 (context) 내에서 코드를 작성하고 결과를 판단한다면, 자신의 실수를 합리화할 수 있기 때문입니다.

메모리 및 상태 (Memory and State)

메모리 (memory)와 상태 (state)는 서로 연관되어 있지만, 동일하지는 않습니다.

메모리는 장기적인 프로젝트 지식 (long-term project knowledge)입니다:

• 팀 선호도 (team preferences)
• 아키텍처 결정 (architectural decisions)
• 반복되는 제약 사항 (recurring constraints)
• 에이전트가 세션 전반에 걸쳐 기억해야 할 사항들

상태 (state)는 현재 작업 진행 상황 (current task progress)입니다:

• 완료된 사항
• 실패한 사항
• 차단된 사항 (blocked)
• 다음 반복 (iteration)에서 가장 먼저 읽어야 할 사항

유용한 최소한의 설정은 다음과 같습니다:

AGENTS.md 또는 CLAUDE.md       # 장기적인 프로젝트 규칙
LOOP-STATE.md               # 현재 루프 진행 상황
IMPLEMENTATION_PLAN.md      # 현재 계획 및 체크리스트
...

상태 (state)가 없다면, 루프는 종종 반복 기계 (repetition machine)가 됩니다. 바빠 보이기는 하지만 계속해서 동일한 사실을 재발견하게 됩니다.

중단 규칙 (Stop Rules)

중단 규칙 (stop rules)은 브레이크와 같습니다.

모든 루프에는 최소한 두 가지 종류의 규칙이 필요합니다:

• 성공 중단 (Success stop): 어떤 증거가 작업이 완료되었음을 증명하는가
• 실패 중단 (Failure stop): 에이전트가 시도를 멈추고 인간에게 제어권을 넘겨야 하는 시점

예시:

성공 (Success):
- pnpm test auth 통과
- auth 커버리지 (coverage) 80% 이상 유지
...

중단 규칙이 없는 에이전트 루프는 자동화가 아닙니다. 그것은 비용 리스크 (cost risk)입니다.

/goal vs /loop

Claude Code에서 /goal과 /loop는 두 가지 서로 다른 루프 형태 (loop shapes)를 나타냅니다.

Claude Code 문서에 따르면, /goal은 완료 조건 (completion condition)을 설정합니다. Claude는 작업을 계속 수행하며 매 턴마다 목표에 도달했는지 확인합니다.

/loop는 현재 Claude Code 세션 내에서 특정 간격으로 프롬프트 (prompt)를 반복해서 실행합니다. 이는 폴링 (polling), 모니터링 (monitoring), 리마인더 (reminders), 또는 외부 상태 변화 (external state changes)를 기다리는 데 더 적합합니다.

요약하자면 다음과 같습니다:

명령 (Command)	핵심 질문	중단 조건 (Stop condition)	최적의 용도
/goal	어떤 상태가 완료로 간주되는가?	목표 달성 또는 실패 규칙 트리거	마이그레이션 (migrations), 실패하는 테스트, 문서, 이슈 정리
/loop	얼마나 자주 확인해야 하는가?	외부 이벤트, 인간의 중단, 명시적 규칙	배포 확인, PR 모니터링, 예정된 리뷰

중요한 이식성 (portability) 관련 세부 사항이 있습니다.

엔지니어링 패턴은 도구 간에 전이되지만, 명령 이름은 그렇지 않습니다.

Claude Code는 문서에 /goal과 /loop를 포함하고 있습니다. Codex는 AGENTS.md, 자동화 (Automations), 하위 에이전트 (Subagents), 워크플로 (Workflows), 그리고 CLI 워크플로를 강조합니다. 모든 에이전트 도구가 동일한 슬래시 명령 (slash commands)을 노출한다고 가정하지 마세요.

이식 가능한 루프 명세 (loop specifications)를 작성한 다음, 이를 사용 중인 도구에 매핑하세요.

/goal을 사용해야 할 때

작업에 검증 가능한 종료 지점 (verifiable endpoint)이 있을 때 /goal을 사용하세요.

나쁜 예:

/goal 프로젝트를 더 좋게 만들기

좋은 예:

/goal 인증 마이그레이션 (auth migration) 완료:

다음 조건 충족 시 완료:
...

핵심은 장황함이 아니라 검증 가능성 (verifiability)입니다.

만약 목표를 테스트, 빌드, 디프 (diffs), 파일 내용, 스크린샷, 링크 확인, 메트릭 (metrics), 또는 명확한 인간 수락 기준 (human acceptance criteria)으로 확인할 수 없다면, 그것은 루프를 돌릴 준비가 되지 않은 것입니다.

/loop를 사용해야 할 때

주요 작업이 무언가를 반복적으로 확인하는 것일 때 /loop를 사용하세요.

예시:

/loop 5m 프로덕션 배포가 완료되었는지 확인:

각 반복 (iteration):
...

전형적인 /loop 작업들:

• 5분마다 배포 상태 확인 (check deployment status every 5 minutes)
• PR에 새로운 리뷰 코멘트가 달렸는지 모니터링 (monitor whether a PR has new review comments)
• 일일 프로젝트 상태 요약 생성 (generate a daily project status summary)
• 외부 서비스가 복구되었는지 감시 (watch whether an external service has recovered)
• 실패한 작업 또는 로그를 주기적으로 처리 (periodically process failed jobs or logs)

나쁜 /loop 작업들:

• 일회성 질문 (one-shot questions)
• 모호한 아이디어 구상 (vague ideation)
• 고위험 프로덕션 변경 (high-risk production changes)
• 인간의 맥락(human context)이 결여된 제품 방향 결정 (product direction decisions without human context)
• 중단 조건이 없는 "이것을 계속 개선해줘" ( "keep improving this" with no stop condition)

"이것을 계속 개선해줘"는 자율 에이전트(autonomous agent)에게 내릴 수 있는 가장 위험한 지시 중 하나입니다. 여기에는 종료 지점도, 경계도, 비용 상한선도 없습니다.

재사용 가능한 루프 명세 템플릿 (A Reusable Loop Spec Template)

본격적인 작업을 위해서는 루프 명세(loop spec)를 PROMPT.md, LOOP-SPEC.md, 또는 IMPLEMENTATION_PLAN.md와 같은 파일에 작성하세요.

# 목표 (Goal)

최종 상태를 한두 문장으로 설명합니다.
...

이 템플릿은 에이전트에게 무엇을 할지(what to do)뿐만 아니라 어떻게 일할지(how to work)를 알려줍니다.

Codex에서의 대응 방식

만약 Codex를 사용하고 있다면, 동일한 패턴을 세 가지 계층으로 매핑하겠습니다.

첫째, 리포지토리 수준의 지침을 위해 AGENTS.md를 사용하세요. OpenAI의 Codex 문서에서는 AGENTS.md를 프로젝트 가이드라인, 테스트 명령, 코딩 표준 및 제약 사항을 위한 장소로 설명합니다.

최소한의 예시:

# 리포지토리 지침 (Repository Instructions)

## 명령 (Commands)
...

둘째, 예약된 또는 반복적인 확인을 위해 Codex Automations를 사용하세요.

셋째, 연구, 검증, 로그 분석 또는 리뷰가 별도의 컨텍스트에서 수행되어야 할 때는 하위 에이전트(Subagents)와 워크플로우(Workflows)를 사용하세요.

주의사항은 Claude Code와 동일합니다. 병렬 에이전트(parallel agents)는 공짜가 아닙니다. 이들은 더 많은 토큰을 소비하고 조정 오버헤드(coordination overhead)를 발생시킵니다. 컨텍스트 오염(context pollution)을 줄이거나 검증 품질을 높일 수 있을 때만 사용하세요.

루프 엔지니어링(Loop Engineering)이 실제로 해결하는 것

인간의 QA 전달 작업(QA relay work)을 줄여줍니다

당신은 여전히 최종 결과를 검토합니다. 하지만 테스트 출력과 다음 에이전트 지침 사이에서 수동적인 가교 역할을 하는 것은 중단하게 됩니다.

긴 작업을 복구 가능하게 만듭니다 (It makes long tasks recoverable)

명확한 LOOP-STATE.md는 에이전트가 거대한 채팅 기록 (chat transcript)에 의존하는 대신, 이전 반복 (iteration) 단계부터 작업을 재개할 수 있게 해줍니다.

그것은 확신을 증거로 대체합니다 (It replaces confidence with evidence)

에이전트는 종종 확신에 차 있습니다. 하지만 증거가 더 낫습니다.

반복되는 작업 (Looped work)은 테스트 로그 (test logs), 빌드 출력 (build output), 차이점 (diffs), 스크린샷 (screenshots), 링크 확인 (link checks), 벤치마크 결과 (benchmark results), 또는 명시적인 수락 기준 (acceptance criteria)과 함께 종료되어야 합니다.

그것은 반복되는 작업을 팀의 자산으로 만듭니다 (It turns repeated work into team assets)

첫 번째 루프 명세 (loop spec)를 작성하는 것은 느립니다. 두 번째는 더 빠릅니다. 세 번째에 이르면, 그것은 아마도 재사용 가능한 워크플로우 (workflow), 기술 (skill), 자동화 (automation), 또는 프로젝트 템플릿 (project template)에 포함될 것입니다.

이것이 프롬프트 (prompt)와 엔지니어링 관행 (engineering practice)의 차이입니다.

세 가지 실질적인 시나리오 (Three Practical Scenarios)

1. 가짜 인용이 없는 연구 브리프 (Research briefs without fake citations)

흔한 실패 사례: AI에게 연구 브리프 (research brief) 작성을 요청하면, 깨진 링크이거나 주장을 뒷받침하지 않는 참조 (references)가 포함된 그럴듯한 주장들을 반환합니다.

루프 버전은 검증 (verification)을 요구해야 합니다:

/goal 연구 브리프 작성이 완료됨:

완료 조건:
...

루프는 더 빨리 쓰는 것에 관한 것이 아닙니다. 근거 없는 주장을 게시하지 않는 것에 관한 것입니다.

2. 프론트엔드 지속성 버그 수정 (Fixing a frontend persistence bug)

설정 페이지에 "저장됨"이라고 표시되지만, 새로고침 후 설정이 사라진다고 가정해 봅시다.

좋은 루프:

/goal 설정 지속성 버그가 수정됨:

완료 조건:
...

이 방식은 작업에 자연스러운 단계(재현, 진단, 수정, 테스트, 검증)가 있기 때문에 효과적입니다.

3. 0에서 1로 제품 구축하기 (Building a 0-to-1 product)

Andrew Ng이 정의한 세 가지 제품 루프 (product loops) 프레임워크는 유용합니다:

• 에이전트 코딩 루프 (Agentic coding loop): 에이전트가 명세 (spec)에 따라 구축, 테스트 및 수정합니다.
• 개발자 피드백 루프 (Developer feedback loop): 개발자가 제품의 방향을 검토하고 명세를 업데이트합니다.
• 외부 피드백 루프 (External feedback loop): 실제 사용자, 알파 테스터, 또는 A/B 테스트가 제품 비전을 변경합니다.

이 루프들은 서로 다른 속도로 실행됩니다.

코딩 루프는 몇 분마다 실행될 수 있습니다. 개발자 피드백 루프는 몇 시간마다 실행될 수 있습니다. 외부 피드백은 며칠 또는 몇 주가 걸릴 수 있습니다.

이 세 가지를 모두 동일하게 자동화하려고 시도하지 마십시오.

저의 실질적인 판단은 다음과 같습니다: 첫 번째 루프(loop)는 고도로 자동화될 수 있습니다. 두 번째 루프는 여전히 인간의 제품 맥락(product context)이 필요합니다. 세 번째 루프는 결코 조작되어서는 안 됩니다. 사용자 피드백(User feedback)은 사용자가 무엇을 원할지에 대한 모델의 추측으로 대체될 수 없습니다.

핵심은 인간을 완전히 제거하는 것이 아닙니다. 인간을 반복적인 저수준의 전달 작업(low-level relay work)에서 벗어나게 하여, 다시 판단(judgment), 방향 설정(direction), 그리고 수용(acceptance)의 영역으로 돌려보내는 것입니다.

일반적인 실패 모드 (Common Failure Modes)