루프 엔지니어링(Loop Engineering)이란? AI 코딩 에이전트가 스스로 일하게 하는 시스템 설계법

루프 엔지니어링(Loop Engineering)은 AI 코딩 에이전트가 한 번 답하고 끝나는 것이 아니라, 행동하고 결과를 관찰한 뒤 다음 단계를 스스로 정해 목표가 달성될 때까지 반복하도록 그 피드백 루프를 설계하는 방법론입니다. 사람이 매번 프롬프트를 거는 대신, 에이전트에게 프롬프트를 거는 시스템을 만들어 에이전트가 스스로 일을 처리하게 합니다.

이 글에서는 Loop Engineering이 무엇인지, 기존 프롬프트 엔지니어링과 무엇이 다른지, 잘 만든 루프의 구성 요소와 설계 방법, Claude Code에서 직접 써보는 명령어, 그리고 도입할 때 주의할 점까지 정리해보겠습니다.

루프 엔지니어링(Loop Engineering) 핵심 요약

• 프롬프트하는 사람을 대체 내가 한 턴씩 지시하던 자리를, 일감을 찾아 처리하고 다음을 정하는 시스템이 대신합니다. 작업의 주체가 사람에서 루프로 옮겨갑니다.
• 이미 도구에 들어와 있음 한때는 직접 bash 스크립트로 짜야 했던 루프의 부품들이, 이제 Claude Code와 Codex 제품 안에 기본 기능으로 들어와 있습니다.
• 다섯 부품 + 메모리 자동화, 워크트리, 스킬, 플러그인·커넥터, 서브에이전트라는 다섯 조각에, 대화 밖에 상태를 저장하는 메모리가 더해져 루프가 완성됩니다.
• 검증 분리가 핵심 코드를 쓴 에이전트가 자기 결과를 채점하면 너무 후합니다. 만드는 에이전트와 검증하는 에이전트를 나누는 것이 신뢰의 출발점입니다.
• 비용과 검증은 여전히 사람 몫 잘못 설계된 루프는 토큰을 태우거나 무한히 돕니다. 무인으로 도는 루프는 실수도 무인으로 하므로, 종료 조건과 사람의 검토가 반드시 필요합니다.

루프 엔지니어링(Loop Engineering)이란?

루프 엔지니어링(Loop Engineering)은 AI 코딩 에이전트가 작업을 계획하고, 코드를 바꾸고, 결과를 관찰하고, 방을 수정하는 과정을 반복하도록 그 피드백 루프를 설계하고 운영하며, 개선하는 하는 방법론입니다. 

AI 도구를 한 번에 코드를 뽑아내는 생성기로 보는 대신, 소프트웨어 작업을 반복 시스템으로 다루는 관점에서 나오게 되었습니다.

이 개념이 부상한 배경에는 단발성 프롬프트의 한계가 있습니다. 실제 프로젝트에는 겉으로 드러나지 않는 제약, 불안정한 테스트, 오래된 관행, 배포 규칙, 불완전한 요구사항이 섞여 있습니다. 그래서 그럴듯한 코드를 한 번 만들어내는 모델만으로는 부족하고, 결과라는 증거를 보고 다음 단계를 고쳐가는 과정이 필요합니다.

이런 한계를 넘어서기 위해 AI를 다루는 방식도 함께 진화해 왔습니다. 사람이 프롬프트를 잘 쓰는 데 집중하던 프롬프트 엔지니어링에서, 모델에 맥락을 잘 넣어주는 컨텍스트 엔지니어링, 작업 환경을 설계하는 하네스(harness) 엔지니어링을 거쳐, 이제는 에이전트가 스스로 반복하는 루프를 설계하는 루프 엔지니어링으로 옮겨가고 있습니다. 

루프(Loop)를 이루는 5가지 부품과 메모리

1) 자동화(Automations)

루프를 한 번 돌린 작업이 아니라 진짜 '루프'로 만드는 심장입니다. 스케줄에 따라 스스로 일감을 찾아내고 분류하는 역할로, 어제의 CI 실패를 훑거나 열린 이슈를 점검하는 일을 사람 없이 주기적으로 수행합니다.

2) 워크트리(Worktrees)

여러 에이전트를 동시에 돌리면 같은 파일을 건드려 충돌이 납니다. git 워크트리는 각 에이전트에 별도 작업 디렉터리를 줘서, 한 에이전트의 수정이 다른 에이전트의 작업에 닿지 않게 격리합니다.

3) 스킬(Skills)

매 세션마다 프로젝트 맥락을 처음부터 다시 설명하지 않도록, 프로젝트 지식을 파일로 적어두는 것입니다. 규칙, 빌드 절차, "이건 예전 사고 때문에 이렇게 안 한다" 같은 관행을 한 번 적어두면 에이전트가 매 실행마다 읽습니다.

4) 플러그인과 커넥터

커넥터는 에이전트를 외부 도구에 연결하는 다리이고, 플러그인은 커넥터와 스킬을 하나로 묶어 배포하는 패키지입니다. 에이전트를 이슈 트래커, 데이터베이스, Slack 같은 실제 도구에 연결하고, 그 설정을 하나로 묶어 팀이 한 번에 가져다 쓰게 해서, 에이전트가 말로만 끝내지 않고 직접 PR을 열고 티켓을 연결하고 채널에 알리게 하는 역할을 합니다. 

5) 서브에이전트(Sub-agents) 

서브 에이전트는 루프에서 가장 유용한 구조로, 코드를 만드는 쪽과 검사하는 쪽처럼 역할별로 필요한 에이전트를 따로 생성하는 것입니다. 

하나의 에이전트가 자기가 짠 코드를 자기가 검사하면 문제를 놓치기 쉽기 때문에, 서브에이전트가 있어 만든 쪽이 놓친 오류를 다른 에이전트가 잡아낼 수 있습니다. 

루프의 진행을 기록해 다음 바퀴로 잇는 메모리 

앞의 다섯이 일을 하는 부품이라면, 메모리는 그 일의 진행 상황을 루프 밖에 기록해 다음 바퀴로 잇는 장치입니다. 

무엇이 끝났고 무엇이 남았는지를 적어두는 저장소로, 마크다운 파일이나 Linear 보드처럼 대화 바깥에 따로 둡니다. 모델은 실행이 끝나면 그 내용을 잊어버리는데, 이 기록이 바깥에 남아 있어 다음 실행이 멈춘 자리에서 작업을 이어갈 수 있습니다. 

하나의 루프는 이렇게 생겼습니다

부품과 명령어를 합치면, 한 줄의 작업 흐름이 작은 관제판으로 바뀝니다. 한 가지 예시 흐름을 보겠습니다.

매일 아침 자동화가 저장소에서 돕니다. 그 프롬프트는 분류 스킬을 불러 어제의 CI 실패, 열린 이슈, 최근 커밋을 읽고 결과를 마크다운 파일이나 Linear 보드에 적습니다. 

처리할 가치가 있는 항목마다 격리된 워크트리를 열어 서브에이전트 하나가 수정 초안을 만들고, 두 번째 서브에이전트가 그 초안을 프로젝트 스킬과 기존 테스트에 비춰 검증합니다. 

커넥터가 PR을 열고 티켓을 갱신합니다. 루프가 처리하지 못한 것은 사람의 분류 받은함으로 넘어옵니다. 상태 파일이 이 전체의 척추 역할을 해서, 무엇을 시도했고 무엇이 통과했고 무엇이 남았는지 기억하므로, 다음 날 아침 실행은 오늘 멈춘 자리에서 이어집니다.

여기서 핵심은, 사람이 그 단계들을 하나하나 프롬프트로 지시하지 않았다는 점입니다. 한 번 설계했을 뿐입니다. 그게 ‘프롬프트하는 나를 시스템으로 대체한다’는 말의 실제 모습이고, 부품이 같기 때문에 Codex에서든 Claude Code에서든 같은 루프가 됩니다.

루프 엔지니어링(Loop Engineering)은 

어떻게 설계해야할까?

첫째, 종료 조건부터 정합니다. 

루프 로직보다 먼저 '완료'가 어떤 모습인지 적어야 합니다. ‘모든 테스트 통과, lint 오류 없음’처럼 기계가 판단할 수 있어야 진짜 종료 조건입니다. ‘코드가 좋아 보이면’은 검사 모델이 판단할 수 없어 루프가 영영 돌거나 엉뚱하게 멈춥니다. 성공 조건과 함께 ‘10번 돌려도 진전 없으면 사람에게 넘김’ 같은 실패 출구도 같이 정해야 합니다.

둘째, 작업을 쪼갭니다. 

한 루프에 너무 큰 일을 통째로 맡기면 검증도 복구도 어려워집니다. 통과·실패를 명확히 가를 수 있는 단위로 잘라, 각 조각이 독립적으로 완료 판정을 받게 합니다.

셋째, 검증을 만드는 쪽과 분리합니다. 

코드를 쓴 에이전트가 자기 결과를 채점하면 너무 후합니다. 별도의 검증 에이전트(또는 /goal의 검사 모델)에게 ‘이 작업이 정말 됐는지’ 확인을 맡겨야, 루프의 '완료'가 주장이 아니라 근거가 됩니다.

넷째, 피드백을 가공해서 돌려줍니다. 

오류가 나면 스택 트레이스를 통째로 던지지 말고, 어디서 났는지·직전에 뭘 하려 했는지·처음 보는 오류인지 반복인지를 정리해 줍니다. 같은 실수를 반복하며 토큰을 태우는 루프는 대개 모델이 아니라 피드백이 거칠어서입니다.

다섯째, 예산에 상한을 둡니다. 

반복당 도구 호출 횟수와 최대 턴 수에 한도를 정하고, 진전 없이 예산을 다 쓰면 그것 자체를 "이 길은 막혔다"는 신호로 읽어 다른 전략으로 보냅니다. 종료 조건이 루프의 출구라면, 예산은 비용의 안전장치입니다.

여섯째, 메모리를 대화 밖에 둡니다. 

무엇을 시도했고 무엇이 남았는지를 마크다운이나 보드 같은 디스크에 적습니다. 모델은 실행 사이에 다 잊으므로, 이 기록이 있어야 루프가 어제 멈춘 자리에서 이어집니다.

설계가 끝나면 반드시 실패 케이스로 테스트해야 합니다. 잘 풀리는 경우만 돌려보면 종료 조건이 진짜 작동하는지 알 수 없습니다. 

작업 정의를 일부러 빈틈 있게 주거나, 오류를 뱉는 도구를 물리거나, 아예 풀 수 없는 과제를 던져, 루프가 막혔을 때 제대로 빠져나오는지를 확인하는 것이 좋습니다.

루프 엔지니어링(Loop Engineering) 주의사항

Loop Engineering은 일의 방식을 바꾸지만, 사람을 일에서 지우지는 못합니다. 오히려 루프가 좋아질수록 더 날카로워지는 문제가 있습니다.

아직 초기 단계의 접근입니다. 

이 방법론을 지지하는 전문가들도 아직 검증 중이며 신중해야 한다고 말합니다. 핵심 워크플로에 전면 도입하기 전, 제한된 범위에서 비용과 효과를 함께 확인하는 것이 안전합니다.

모든 작업에 루프가 필요한 건 아닙니다. 

한 번으로 끝나는 일은 그냥 프롬프트를 쓰는 게 낫습니다. 반복되고 통과·실패 신호가 명확한 작업에서만 루프를 만드는 것이 효율적입니다.

토큰 비용을 먼저 관리해야 합니다. 

루프는 반복 구조라 사용 패턴에 따라 비용이 크게 출렁입니다. 특히 서브에이전트는 각자 모델과 도구를 돌리므로 토큰을 더 씁니다. 종료 조건과 호출 예산을 설계 단계에서 정해야 합니다.

편한 자세가 가장 위험합니다. 

루프가 알아서 돌면 의견 갖기를 멈추고 결과를 그냥 받아들이고 싶어집니다. 루프를 판단력 있게 설계하면 약이 되지만, 생각을 피하려고 설계하면 독이 됩니다. 같은 행동인데 결과가 정반대입니다.

검증은 여전히 사람 몫입니다. 

무인으로 도는 루프는 실수도 무인으로 합니다. 검증 서브에이전트를 분리하는 이유가 루프의 '완료'에 의미를 부여하기 위해서지만, 그 '완료'조차 증명이 아니라 주장입니다. 결국 사람이 동작을 확인한 코드만 내보내야 합니다.

루프 형태의 작업방식, 명령어로 체험해보기

Codex Goal 사용법, 목표만 설정하면 끝까지 간다

Claude Code /goal 출시: 목표만 주면 AI가 끝까지 처리한다

Claude Code /ultrareview 사용법, 실행만 하면 끝까지 검수한다