2026년 6월경부터 "루프 엔지니어링 (Loop Engineering)"이라는 용어가 급격히 눈에 띄기 시작했습니다. 계기는 Claude Code를 만든 Anthropic의 Boris Cherny 씨의 "이제 Claude에게 직접 프롬프트를 쓰지 않는다. 루프를 쓰는 것이 나의 일이다"라는 발언과, Peter Steinberger 씨의 "에이전트에게 프롬프트를 하는 것이 아니라, 에이전트에게 프롬프트를 보내는 '루프'를 설계하라"는 주장입니다. 여기에 이름을 붙인 사람이 Google의 Addy Osmani 씨였습니다.

버즈워드(Buzzword)이기 때문에 사람마다 해석이 갈리기 쉽지만, 이 기사에서는 **"루프 엔지니어링으로 인간의 역할이 어떻게 변하는가"**를 축으로 개념, 구조, 그리고 실천 방법을 정리합니다 (특정 해석을 '정답'으로 강요하는 것이 아니라, 하나의 정리로서 읽어주시기 바랍니다).

• 루프 엔지니어링이란 무엇인가 (인간 역할의 변화)
• 여기서 말하는 「루프」의 구조 (내부 루프와 외부 루프)
• 하네스 엔지니어링 (Harness Engineering)과의 관계, 그리고 과거의 연장선이라는 점
• 개인 도구에서의 실천 (/goal과 /loop)
• 장시간 구동하는 요령과 놓치기 쉬운 주의점

요점은 간단합니다. 인간의 업무가 **「프롬프트를 순차적으로 작성하기」 → 「프롬프트가 자동으로 전송되는 루프를 만들기」**로 이동한다는 것입니다.

지금까지는 좋은 프롬프트를 쓰고, 돌아온 결과를 읽고, 다음 명령을 입력하는... 즉, "한 턴씩 에이전트를 손으로 잡고 있는" 상태였습니다. 루프 엔지니어링에서는 업무를 발견하고 → 할당하고 → 체크하고 → 기록하고 → 다음을 결정하는 작은 시스템을 만들어, 그 시스템 안에 에이전트를 밀어 넣습니다.

즉, 인간이 설계하는 대상이 프롬프트에서 루프로 이동한 것입니다.

엔지니어가 불필요해진다는 이야기가 아닙니다

Cherny 씨는 "뛰어난 엔지니어는 오히려 이전보다 더 중요해질 것"이라고 명시했습니다. 무엇을 만들지 결정하고, 고객과 대화하며, 팀을 조정하고, 루프가 지향해야 할 목표를 정의하는 것은 인간입니다. 일이 사라진 것이 아니라, "코드를 쓰는 것"에서 "코드를 쓰는 것을 쓰는 것"으로 한 단계 격상되었다는 정리입니다.

본질은 인간이 매번 프롬프트를 입력하는 대신, 시스템이 에이전트에게 프롬프트를 보내고 조건이 충족될 때까지 작업을 계속하는 것입니다.

여기에는 두 종류의 루프가 있습니다.

• 내부 루프 (Inner Loop): 실행 담당 에이전트가 작업하고, 판정 담당이 "완료되었는가"를 평가하며, 미완료 시 다시 돌려보내는 과정을 반복함.
• 외부 루프 (Outer Loop): 하나의 작업이 끝나면 다음 트리거(시스템 장애, CI 실패, 정기 실행 등)를 기다렸다가 다시 내부 루프를 기동함.

그리고 가장 중요한 설계 판단은 「실행 담당(코드를 작성)」과 「판정 담당(체크를 수행)」을 분리하는 것입니다. 동일한 문맥(Context) 내에서 자기만족하게 두지 않고, 별도의 모델과 별도의 컨텍스트에서 검증하게 함으로써, 루프가 "틀린 답을 자신만만하게 양산하는 장치"가 되는 것을 방지합니다.

"하네스 엔지니어링의 다음이 루프 엔지니어링"이라는 단순한 관계는 아닙니다. 루프를 돌리는 것을 전제로 하기 때문에, 하네스(에이전트를 구동하는 기반 시설)에 추가로 요구되는 요소가 나타난다는 관계입니다. 실제로 후술할 /goal과 같은 명령어는 "작업 루프를 돌리기 위한 하네스의 추가 요소"라고 할 수 있습니다.

또한, 루프 엔지니어링은 새롭게 발명된 것이라기보다, 지금까지의 시행착오의 연장선에 이름이 붙은 것입니다. "일정한 조건을 만족할 때까지 에이전트가 작업을 반복한다"는 발상 자체는 여러 곳에서 쌓여왔습니다.

이 래더(Ladder, Matt Van Horn 씨의 정리)로 말하자면, /goal 단독은 레벨 4입니다. Cherny 씨나 Steinberger 씨가 실제로 바라보고 있는 것은, **외부 루프를 감시·제어하는 오케스트레이터(Orchestrator)**가 존재하여, 들어오는 요구로부터 작업을 분리하고, 내부 루프를 돌리며, 전체가 자율적으로 돌아가는 레벨 5라고 생각됩니다.

Ralph 루프 (Ralph Loop)

Geoffrey Huntley 씨가 명명한 기법으로, 심슨 가족의 Ralph Wiggum에서 유래했습니다. 사양(Spec)에 대해 동일한 프롬프트를 while 루프를 통해 제공하고, 매번 완전히 새로운 인스턴스에서 한 번에 하나의 태스크씩 구현하게 하여 성공 조건에 도달할 때까지 반복하는 브루트 포스(Brute-force) 방식입니다. "예측 불가능한 세계 속에서 결정론적으로 단순하다"는 점이 이름의 유래입니다.

개인이 에이전틱 코딩(Agentic Coding) 도구로 실천한다면, /goal...

또는 /loop

의 도움을 받습니다. 이 두 가지는 자주 혼동되므로 차이점을 확실히 짚고 넘어갑시다.

커맨드	동작	용도
/goal	완료 조건이 충족될 때까지 프롬프트를 계속 주입한다. Claude Code에서는 별도의 모델이 완료 여부를 판정한다 (경량 모델이 기본값)	하나의 태스크를 끝까지 완수하게 함
/loop	일정 간격으로 (동일한) 프롬프트나 커맨드를 전송한다 (스케줄링)	PR 관리, CI 모니터링, 정기 집계 등 반복 작업

/goal은 "완료될 때까지 달리는" 내부 루프(inner loop), /loop는 "일정 간격으로 두드리는" 심박수(heartbeat)라고 생각하면 이해하기 쉽습니다. 외부 루프(outer loop)(이벤트를 통해 내부 루프를 기동하는 기반)는 이것들만으로는 완결되지 않기 때문에, cron이나 GitHub Actions, 각 도구의 스케줄/자동 실행 기능, 클라우드 버전의 Claude Code 등에 의존하게 됩니다.

/goal은 무턱대고 실행하는 것이 아니라, 골(goal)을 정성스럽게 설계하는 전 단계가 중요합니다. 한 실천가의 흐름은 다음과 같습니다.

포인트는 "무엇을 완료로 볼 것인가(골/goal)"를 사양(specification)과 테스트 케이스(test case)의 형태로 상세히 다듬어 두는 것입니다. 테스트 케이스는 "이 관점도 확인해줘", "그건 테스트의 의미가 없어"라고 인간이 리뷰하며 정밀도를 높입니다. 이 과정을 건너뛰면 /goal로 실행하더라도 엉뚱한 결과물만 쌓이게 됩니다.

Cherny 씨가 제시하는 "Opus를 몇 시간~며칠 동안 가동시키는 팁"은 대체로 다음과 같습니다.

• 권한을 오토(자동 승인) 모드로 설정한다
• 다이내믹 워크플로우(Dynamic Workflow)로 다수의 에이전트를 오케스트레이션(Orchestration)한다
• /goal과 /loop를 적절히 사용한다
• Claude Code를 클라우드에서 실행한다 (PC를 켜두지 않아도 실행됨)
• 에이전트가 자신의 성과를 처음부터 끝까지 스스로 검증할 수 있는 수단을 반드시 갖추게 한다 (테스트 자동화, 프론트엔드는 Playwright 등)

잊어서는 안 될 여섯 번째: 비용 상한선

루프는 "계속 호출하면 무한히 작업"하기 때문에, 며칠 동안 실행하면 청구 금액이 치솟습니다. 반복 횟수, 연속 실패 횟수, 달러 상한선 캡(Circuit Breaker)을 필수 설계 요구사항으로 포함해야 합니다.

대전제로서, 루프는 자동 주행을 위한 어시스트일 뿐, 그 자체로 좋은 성과를 만들어내는 것은 아닙니다. 오히려 너무 의존하면 만들어지는 결과물과 인간의 이해 사이가 점점 벌어지는(Drift) 문제가 발생합니다. 루프가 돌아가는 동안에는 기본적으로 블랙박스가 되기 쉽기 때문입니다.

그렇기에,

• 무엇을 완료로 볼 것인가(골/goal, 완료 조건)를 정성스럽게 정의한다
• 태스크를 어떻게 분할하고, 현재 무엇이 병렬로 진행되고 있는지 인간이 파악한다
• 실행 역할과 판정 역할을 나누고, 지속적인 리뷰와 검증 게이트(verification gate)로 신뢰성을 담보한다

와 같이, 인간의 리뷰와 도메인 지식(Domain Knowledge)이 필요한 부분은 소홀히 하지 않는 것이 핵심입니다. 루프가 빠르게 만드는 것은 "인간이 지시를 내리지 않으면 진행되지 않는다"라는 속도의 병목 현상일 뿐이며, 품질 보증은 또 다른 업무라는 구분을 의意识해야 합니다.

외부 루프를 어떻게 구현할 것인가

"특정 메일이 도착하면", "시스템이 특정 임계치를 넘으면"과 같은 이벤트 주도(Event-driven) 방식으로 내부 루프를 기동할 수 있다면, 정기 실행보다 유연하며 필요 없을 때 에이전트가 움직이지 않으므로 비용 측면에서도 유리합니다. 이를 구현하려면 클라우드 상에서 동작하는 기반(GitHub Actions, 각종 오케스트레이션 기반, 클라우드 버전 에이전트 등)이 필요합니다. 이 "외부 루프의 구현"이 현재 가장 어렵고, 향후 보급의 열쇠가 될 부분입니다.

• 루프 엔지니어링은 인간의 역할을 **"프롬프트를 쓰는 것" $\rightarrow$ "루프를 설계하는 것"**으로 옮기는 사고방식
• 루프에는 **내부 루프(실행 $\rightarrow$ 판정 $\rightarrow$ 재투입)**와 **외부 루프(트리거로 기동)**가 있으며, 실행 역할과 판정 역할을 나누는 것이 가장 중요
• 새로운 발명이 아니라 ReAct $\rightarrow$ AutoGPT $\rightarrow$ Ralph $\rightarrow$ /goal $\rightarrow$ 오케스트레이션으로 이어지는 축적의 연장선
• 로컬에서는 /loop(일정 간격)와 /goal(완료까지)을 구분해서 사용한다. 골을 사양과 테스트로 설계하는 것이 전 단계의 핵심
• 장시간 운용은 클라우드화, 자기 검증, 비용 상한선이 필수. 루프는 품질을 보증하지 않으므로, 드리프트(Drift)를 방지하기 위한 인간의 리뷰가 불가결함

「이제 Claude에게 직접 프롬프트를 쓰지 않겠다」라는 말은 자극적이지만, 그 본질은 레버리지(Leverage)가 발생하는 지점이 '단 한 번의 프롬프트'에서 '자율적으로 작동하는 메커니즘의 설계'로 옮겨갔다는 것입니다. 단순히 밀어붙이는 사람이 아니라, 설계하는 엔지니어로 남겠다는 마음가짐으로 루프(Loop)를 구축해 나갑시다.