# Loop Engineering — 엔지니어의 일은 『루프를 짜는 것』이 되었다

> 『My job is to write loops.』 프롬프트에서 루프 설계로. Prompt→Context→Harness→Loop로 추상도가 올라가는 새 흐름과, 비용 폭발·이해 부채라는 현실적 리스크를 정리합니다.

Date: 2026-07-06

Tags: AI, Loop Engineering, Claude Code, 에이전트, 개발 방법론

---

![](https://img.wiredxeco.com/wiredxeco/loop-engineering/hero.webp)

엔지니어의 일은 어느새 「코드를 짜는 것」에서 「AI에게 코드를 짜게 하는 구조를 설계하는 것」으로 옮겨 갔습니다. 그 최신형이 바로 **Loop Engineering（루프 엔지니어링）** 입니다.

한 번의 프롬프트를 다듬는 것이 아니라, AI 에이전트를 **시간축을 따라 자율적으로 계속 돌리는 「루프」 그 자체를 설계한다.** 엔지니어가 정의하는 것은 「목적」과 「정지 조건」뿐. 세부 구현이나 수정은 루프 안에서 AI가 스스로 끝까지 해낸다. 이 사고방식이 2026년 상반기에 단숨에 퍼졌습니다.

## 계기는 「내 일은 루프를 짜는 것이다」

불씨를 지핀 것은 Anthropic에서 Claude Code 개발을 이끄는 Boris Cherny 씨의 한마디였습니다.

> **My job is to write loops.（내 일은 루프를 짜는 것이다）**

2026년 6월의 이 발언은, 엔지니어의 역할이 「매번 프롬프트를 치는 사람」에서 「AI를 자율적으로 움직이는 구조를 설계하는 사람」으로 이동하고 있음을 지나칠 만큼 정확히 짚어냈습니다. 그래서 업계에서 단숨에 확산되었다고 생각합니다.

현장 감각으로도 납득이 됩니다. AI에게 일문일답으로 지시를 내리는 동안, 사람은 계속 화면 앞에 붙어 있어야 합니다. 그것은 「AI를 쓰고 있는」 것 같지만, 실제로는 **사람이 병목이 되어 있는** 상태입니다. 루프를 설계할 수 있으면, 사람은 자는 동안에도 AI를 일하게 할 수 있습니다. 레버리지의 자릿수가 달라집니다.

## Loop Engineering이란 무엇인가

AI와 관계 맺는 방식은, 지난 몇 년 사이에 계단을 오르듯 추상도를 높여 왔습니다.

- **Prompt Engineering** — 한 번의 지시문을 다듬는다
- **Context Engineering** — AI에게 건네는 문맥 정보를 설계한다
- **Harness Engineering** — 에이전트를 움직이는 틀（툴·권한·실행 환경）을 설계한다
- **Loop Engineering** — 그 틀을 시간축을 따라 자율적으로 계속 돌리는 「루프」로 설계한다（지금 여기）

가장 아래의 Prompt Engineering은 「그때뿐인 장인 기술」이었습니다. 위로 갈수록, **한 번 설계하면 반복해서 효과를 내는 「자산」** 이 됩니다. Loop Engineering은 그 정점으로, 사람은 구체적인 작업 절차를 쓰지 않습니다. 쓰는 것은 「무엇이 달성되면 끝인가」라는 조건뿐. 그다음은 에이전트가 시도와 수정을 반복하며 거기에 도달합니다.

## 루프를 떠받치는 6가지 구성 요소

자율 루프는 대략 다음 6개의 부품으로 이루어집니다. 여기가 Loop Engineering의 설계 대상입니다.

- **스케줄링（Trigger）** — 언제 움직이기 시작하는가. cron이나 `/loop` 같은 명령으로 기동 조건을 정한다
- **목표 조건（Goal）** — 무엇이 충족되면 멈추는가. 달성할 때까지 에이전트를 계속 돌리는 종료 조건
- **격리 워크스페이스（Isolation）** — 여러 에이전트가 동시에 움직여도 충돌하지 않는 환경. git worktree 등으로 작업 공간을 나눈다
- **검증자（Verifier）** — AI 자신이 쓴 코드를, 다른 로직·다른 모델로 검증하는 구조. 「쓴 본인에게 채점시키지 않는」 것이 핵심
- **영속 메모리（Memory）** — 세션을 넘어 학습 내용을 이어받는다. 같은 실패를 매번 되풀이하지 않기 위한 기억
- **커넥터（Connector）** — GitHub나 Slack 등 외부 시스템과 연동해, 실제로 행동을 일으키기 위한 접속구

순서대로 보면 알 수 있듯이, **프롬프트의 능숙함은 여기에 하나도 들어 있지 않습니다.** Loop Engineering에서 요구되는 것은 소프트웨어 설계 그 자체의 감각입니다.

## 실전 도구와, 이미 시작된 열광

이 개념은 이론만의 이야기가 아닙니다. 오픈소스 `cobusgreyling/loop-engineering`라는 CLI 도구 모음이 실제로 이 사고방식을 구현하고 있으며, 공개 후 짧은 기간에 **4,800개 이상의 스타** 를 모았습니다. 위의 6요소를 명령줄에서 조립할 수 있게 한 것으로, Loop Engineering이 「버즈워드」에서 「만질 수 있는 도구」로 옮겨 가고 있다는 방증이라고 생각합니다.

## 만능은 아니다 — 3가지 현실적 리스크

여기까지 읽으면 마법처럼 들리지만, 실제로 돌려 보면 명확한 대가가 있습니다. 이 부분을 보지 않고 도입하면 호되게 당합니다.

### 비용 폭발

루프는 「끝날 때까지 계속 돈다」는 것이 본질입니다. 뒤집어 말하면, **정지 조건의 설계를 잘못하면 하염없이 토큰을 계속 소비한다.** 하룻밤 방치했더니 모르는 사이에 수만 엔이 녹아 있었다는 사고는 드물지 않습니다. 목표 조건과 똑같이 「폭주를 멈추는 가드레일（상한 토큰·타임아웃·연속 실패 시 중단）」의 설계가 중요합니다.

### 검증 책임은 사람에게 남는다

Verifier를 끼워도, 그것은 어디까지나 「AI에 의한 1차 체크」입니다. **최종적으로 운영에 내보내는 판단의 책임은 끝까지 사람에게 남습니다.** 루프가 「테스트 전부 그린」이라고 보고해 와도, 그 테스트 자체를 AI가 허술하게 썼다면 의미가 없습니다. 자동 검증을 지나치게 믿지 않는 것이, 역설적으로 루프를 안전하게 돌리는 요령입니다.

### 이해 부채의 축적

이것이 가장 조용하고, 가장 무서운 리스크입니다. AI가 생성한 코드를 사람이 읽지 않게 되면, 시스템의 전체 그림이 누구의 머릿속에도 남지 않게 됩니다. **나중에 갚을 수 없는 「이해의 상실」** 이 쌓여 갑니다.

기술 부채는 다시 쓰면 갚을 수 있지만, 이해 부채는 「애초에 무엇을 어떻게 고치면 되는지 모르는」 상태입니다. 장애가 일어난 심야에, 자사의 코드인데 아무도 내부를 설명하지 못한다——이것은 루프의 생산성으로 얻은 시간을, 장래에 한꺼번에 이자를 붙여 되빼앗기는 거래가 될 수 있습니다.

## 결론 — 루프를 설계하는 것은, 아직 사람의 일

Loop Engineering은 「엔지니어를 불필요하게 만드는 것」이 아닙니다. 사람이 레버리지를 거는 지점을, **프롬프트에서 「자율적인 시스템（루프） 그 자체의 설계」로 한 단계 끌어올리는 것** 입니다.

멈추는 법을 모르는 자동화는 그저 폭주이고, 내용을 이해하지 못하는 생산성은 그저 부채의 앞당겨 쓰기입니다. 그렇기에 목적·정지 조건·검증, 그리고 「어디까지 AI에게 맡기고, 어디는 사람이 읽을 것인가」의 선 긋기를 설계할 수 있는 사람의 가치는, 오히려 올라갑니다.

주식회사 와이어드&에코에서는 Claude Code나 에이전트를 전제로 한 개발 플로우의 설계·도입 지원을 하고 있습니다. 「AI에게 쓰게 하고 있지만, 리뷰와 운용이 따라가지 못한다」 「자율 루프를 안전하게 돌리는 구조를 만들고 싶다」 같은 상담을 받고 있습니다. 부담 없이 문의해 주세요.