Loop Engineering: AI에게 질문하는 것을 넘어, 일을 끝내는 구조 만들기

내기억에 생성형 AI, 제일 익숙했던 GPT가 처음 대중화되었을 때 가장 많이 언급된 용어는 Prompt Engineering이었다.

원하는 답변을 얻기 위해 역할과 조건, 출력 형식을 어떻게 작성해야 하는지가 중요했기 때문이다. 하지만 AI가 단순히 텍스트를 생성하는 것을 넘어 문서를 검색하고, 파일을 수정하고, 터미널과 외부 도구를 사용할 수 있게 되면서 고민의 범위도 넓어졌다.

이제는 좋은 프롬프트를 작성하는 것만으로 충분하지 않다.

AI가 어떤 정보를 참고해야 하는지, 어떤 도구를 사용할 수 있는지, 여러 작업을 어떤 순서로 수행해야 하는지, 결과를 어떻게 검증하고 수정할지까지 함께 설계해야 한다.

나는 Prompt Engineering에서 Context Engineering, Harness Engineering, Orchestration, Loop Engineering으로 기술이 순서대로 발전했다기보다, AI의 성능과 역할이 확장되면서 이를 적절하게 사용하는 방법을 설명하기 위한 연구와 실무 경험이 쌓였고, 그 과정에서 각각의 관점을 나타내는 용어가 등장한 것에 가깝다고 생각한다.

그중 최근 자주 언급되기 시작한 개념이 Loop Engineering이다.

Loop Engineering이란 무엇인가

Loop Engineering은 사람이 작업 단계마다 새로운 지시를 입력하는 대신, AI Agent가 실행 결과를 확인하고 다음 행동을 수정하면서 목표에 도달하도록 반복 구조를 설계하는 접근이다.

 

에이전트는 먼저 목표를 확인하고 작업 계획을 세운다. 이후 파일 수정이나 도구 실행과 같은 행동을 수행하고 그 결과를 관찰한다.

결과가 정해진 기준을 만족하지 못했다면 문제를 수정한 뒤 다시 실행한다. 목표를 달성하거나 종료 조건에 도달할 때까지 이 과정이 반복된다. 여기서 중요한 것은 단순히 같은 명령을 여러 번 실행하는 것이 아니다.

이전 실행의 결과가 다음 판단에 반영되어야 한다. 테스트가 실패했다면 오류 메시지를 읽고 수정 방향을 바꿔야 하며, 필요한 정보가 부족하다면 새로운 자료를 Context에 추가해야 한다.

즉, Loop Engineering의 핵심은 반복 자체가 아니라 피드백을 이용해 다음 행동을 바꾸는 것이다.

왜 지금 Loop Engineering이 주목받는가

기존의 대화형 AI에서는 한 번의 답변 품질이 중요했다.

사용자가 프롬프트를 작성하면 AI가 결과를 생성하고, 문제가 있다면 사용자가 다시 수정 요청을 보내는 방식이었다. 계획을 세우고 결과를 확인하며 다음 프롬프트를 작성하는 역할은 사람이 담당했다.

반면 Claude Code나 Codex 같은 AI Agent는 코드베이스를 읽고, 파일을 수정하고, 명령어를 실행하며, 테스트 결과를 다시 확인할 수 있다.

AI가 한 번의 답변을 생성하는 도구에서 여러 단계를 수행하는 작업 주체로 확장된 것이다.

이러한 환경에서는 다음과 같은 질문이 중요해진다.

• AI에게 어떤 목표를 제공할 것인가
• 어떤 정보와 도구를 사용할 수 있게 할 것인가
• 작업을 어떤 순서와 역할로 나눌 것인가
• 결과가 올바른지 어떻게 검증할 것인가
• 실패했을 때 무엇을 바꾸어 다시 시도할 것인가
• 언제 작업을 종료하거나 사람에게 넘길 것인가

Loop Engineering은 이 가운데 실행 결과를 다시 다음 행동에 연결하는 반복 구조에 초점을 맞춘다.

Prompt부터 Loop까지, 무엇이 다른가

Prompt, Context, Harness, Orchestration, Loop Engineering 은 서로를 대체하는 개념이라기보다 AI 시스템을 바라보는 서로 다른 설계 관점에 가깝다.

• Prompt Engineering: AI에게 무엇을 해야 하는지 전달한다.
  역할, 목표, 조건, 제약 사항과 출력 형식을 설계한다.
• Context Engineering: AI가 무엇을 알고 판단해야 하는지 설계한다.
  코드, 문서, 규칙, 이전 작업 기록, 테스트 결과와 메모리 중 현재 작업에 필요한 정보를 선택해 제공한다.
• Harness Engineering: AI가 실제로 행동할 수 있는 실행 환경을 설계한다.
  파일 시스템, 터미널, 검색 도구, 테스트 환경, 권한, 로그와 상태 관리 등이 여기에 포함될 수 있다.
• Orchestration: 복잡한 작업을 어떤 구조와 순서로 수행할지 설계한다.
  작업을 여러 단계로 나누고, 역할을 배정하며, 순차 또는 병렬 실행과 작업 간 의존성을 관리한다.
• Loop Engineering: 실행 결과를 어떤 기준으로 평가하고, 그 결과를 바탕으로 언제까지 다시 시도할지를 설계한다.
  평가, 상태 갱신, 재시도와 종료 조건이 핵심이다.

구분	핵심 질문
Prompt Engineering	무엇을 지시할 것인가
Context Engineering	무엇을 알고 판단하게 할 것인가
Harness Engineering	어떤 환경과 도구에서 행동하게 할 것인가
Orchestration	작업을 어떤 구조와 순서로 수행할 것인가
Loop Engineering	어떤 피드백을 바탕으로 언제까지 반복할 것인가

 

설명을 위해 이 순서로 나열할 수는 있지만, 이것이 공식적인 발전 단계나 반드시 지켜야 하는 구축 순서는 아니다.

예를 들어 Harness 내부에 Agent Loop가 포함될 수 있고, Loop 안에서 Orchestrator가 여러 에이전트를 조정할 수도 있다. 반대로 간단한 작업이라면 별도의 다중 에이전트 Orchestration 없이 하나의 에이전트가 실행과 검증을 반복할 수도 있다.

즉, 실제 시스템에서는 서로 겹치거나 포함될 수 있는 개념으로 보는 편이 적절하다.

강화학습의 보상 개념과 비슷한 것일까

Loop Engineering에서 테스트 통과, 평가 점수, 체크리스트 충족과 같은 결과는 에이전트가 다음 행동을 정하는 피드백이 된다.

이 때문에 행동의 결과에 따라 보상을 받고 다음 행동을 개선하는 강화학습과 비슷하다고 느낄 수 있다.

하지만 일반적인 Agent Loop에서 모델 자체가 다시 학습되는 것은 아니다. 테스트에 실패했다고 해서 모델의 가중치가 바로 변경되는 것이 아니라, 실패 결과가 다음 프롬프트와 Context, 작업 계획에 반영되는 방식이다.

따라서 Loop Engineering은 강화학습이라기보다 보상과 피드백이라는 비슷한 구조를 실행 과정에 활용하는 방식으로 구분하는 것이 적절하다.

좋은 Loop에는 검증과 종료 조건이 필요하다

Loop를 만든다고 해서 에이전트에게 단순히 “완료될 때까지 반복하라”고 지시해서는 안 된다.

먼저 무엇을 완료로 볼 것인지 명확해야 한다. 예를 들어 “코드를 개선하라”는 목표는 종료 시점을 판단하기 어렵다. 반면 “기능을 구현하고 기존 테스트와 신규 테스트를 모두 통과하라”는 목표는 비교적 명확한 기준을 가진다.

결과를 확인할 검증 방법도 필요하다.

• 테스트와 빌드 결과
• 요구사항 체크리스트
• 코드 또는 문서 형식 검사
• 별도 Reviewer Agent의 검토
• 사람의 최종 승인

에이전트가 “완료했다”고 말하는 것과 실제로 완료 조건을 충족한 것은 다르다. 따라서 가능하면 에이전트의 주장보다 테스트나 규칙처럼 확인할 수 있는 결과를 기준으로 사용해야 한다. 무한 반복을 방지할 종료 조건도 필요하다.

• 목표를 모두 충족했을 때
• 최대 반복 횟수에 도달했을 때
• 비용이나 토큰 한도를 초과했을 때
• 동일한 실패가 반복될 때
• 사람의 판단이 필요한 상황이 발생했을 때

좋은 Loop는 오래 실행되는 Loop가 아니다. 토큰비용을 생각했을 때도 이런 조건은 적절하게 꼭 포함되어야한다.

실행 결과를 검증하고, 실패 원인을 다음 행동에 반영하며, 해결할 수 없는 상황에서는 적절하게 멈출 수 있는 Loop가 좋은 Loop다.

Human-in-the-loop는 여전히 필요하다

Loop Engineering은 사람을 완전히 제거하는 자동화를 의미하지 않는다.

반복적인 실행과 일반적인 오류 수정은 에이전트가 담당할 수 있지만, 목표와 우선순위를 정하고 결과가 실제 요구사항에 맞는지 판단하는 일에는 여전히 사람의 역할이 필요하다.

특히 다음과 같은 작업에는 사람의 승인 지점을 두는 것이 안전하다.

• 외부 시스템 배포
• 중요한 파일 삭제 또는 변경
• 비용이 발생하는 작업
• 보안과 개인정보 관련 작업
• 고객이나 파트너에게 전달되는 결과
• 비즈니스 판단이 필요한 예외 상황

Human-in-the-loop는 Loop Engineering과 반대되는 개념이 아니다. AI가 반복 작업을 수행하되, 책임과 판단이 필요한 지점에서는 사람에게 작업을 넘기도록 설계하는 것 역시 Loop Engineering의 일부다.

마무리

Loop Engineering은 Prompt Engineering을 대체하는 새로운 단계라기보다, AI Agent를 실제 작업에 활용하면서 중요해진 설계 관점 중 하나다.

좋은 Prompt와 적절한 Context가 필요하고, 실제 행동을 가능하게 하는 Harness도 필요하다. 복잡한 작업에서는 Orchestration을 통해 역할과 순서를 조정할 수 있다.

Loop Engineering은 이러한 요소를 실행, 검증, 수정과 재시도의 흐름으로 연결한다.

핵심은 AI를 오래 실행하는 것이 아니다. 명확한 목표와 검증 기준을 제공하고, 실행 결과를 다음 행동에 반영하며, 적절한 시점에 완료하거나 사람에게 판단을 넘길 수 있도록 만드는 것이다.

AI에게 좋은 답변을 요청하는 것을 넘어, AI가 피드백을 이용해 실제로 일을 끝낼 수 있는 구조를 만드는 것.

 

이것이 Loop Engineering이 설명하려는 변화라고 생각한다.

 

참고 자료

• Addy Osmani, Loop Engineering
  https://addyosmani.com/blog/loop-engineering/
• OpenAI, Unrolling the Codex agent loop
  https://openai.com/index/unrolling-the-codex-agent-loop/
• OpenAI, Unlocking the Codex harness: how we built the App Server
  https://openai.com/index/unlocking-the-codex-harness/
• Anthropic, Building Effective AI Agents
  https://www.anthropic.com/research/building-effective-agents
• Anthropic, Effective context engineering for AI agents
  https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic, Effective harnesses for long-running agents
  https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Anthropic, Demystifying evals for AI agents
  https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents