루프 엔지니어링: 에이전트에 직접 프롬프트하지 말고, 루프를 설계하라

루프 엔지니어링: 에이전트를 프롬프트하는 시스템 설계

루프 엔지니어링: 에이전트에 직접 프롬프트하지 말고, 루프를 설계하라

에이전트에게 매 턴 손으로 프롬프트를 던지던 시대가 끝나고 있다. Peter Steinberger는 이렇게 말했다. "코딩 에이전트에 매번 프롬프트하지 말고, 에이전트를 프롬프트하는 루프를 설계하라." Boris Cherny(Anthropic의 Claude Code 책임자)도 동의한다. "이제 Claude에 프롬프트하지 않고, 무엇을 할지 정하는 루프를 돌린다. 내 일은 루프를 작성하는 것." 루프 엔지니어링(Loop Engineering) 은 이 변화의 이름이다.

루프 엔지니어링이란 무엇인가

루프 엔지니어링은 에이전트를 직접 다루는 사람의 자리를 시스템으로 대체하는 작업이다. 사용자는 "목적"만 정의한다. AI는 완료 조건이 참이 될 때까지 스스로 반복한다. 이 재귀적 목표(recursive goal) 단위 하나가 바로 루프다. 단순한 harness가 아니라, 타이머로 발동해 작은 헬퍼를 생성하고 스스로에게 먹이를 주는 작은 공장이다. 지난 2년은 좋은 프롬프트와 풍부한 컨텍스트를 한 턴씩 주고받는 방식이었다. 이제는 작업을 분배하고 검증하고 결과를 기록하고 다음 작업을 결정하는 작은 시스템이 에이전트를 찌른다. 더 이상 도구의 문제가 아니다. 어느 도구를 고를지보다 어느 쪽에서도 동작하는 루프를 어떻게 설계할지가 핵심이다.

다섯 가지 구성 요소

루프에는 다섯 가지 핵심 요소가 있다. Claude Code와 Codex 모두 현재 이 다섯 가지를 전부 내장하고 있다. 이름만 조금 다를 뿐 능력은 동일하다.

Automations — 루프의 심장 박동이다. Codex의 Automations 탭, Claude Code의 /loop 명령이 여기에 해당한다. 정해진 주기마다 프롬프트를 재실행해 CI 실패를 요약하고 일일 이슈를 분류하고 커밋 브리핑을 작성한다. /goal은 더 강력하다. "test/auth의 모든 테스트 통과, lint clean" 같은 정지 조건을 주고 자리를 떠난다. 별도의 작은 모델이 매 턴 후 완료 여부를 검사해, 코드를 쓴 에이전트가 자기 숙제를 채점하지 않게 막는다.

Worktrees — 두 에이전트를 동시에 돌리면 같은 파일이 충돌한다. git worktree는 같은 repo 히스토리를 공유하면서 각자의 브랜치 위에 별도 작업 디렉터리를 만든다. Codex는 worktree를 내장했고, Claude Code는 --worktree 플래그와 isolation: worktree 옵션으로 동일한 격리를 제공한다. 다만 실제 병렬 수의 상한은 도구가 아니라 사용자의 리뷰 대역폭이 정한다.

Skills — 매 세션 차가운 상태로 시작하는 에이전트는 매번 프로젝트 컨텍스트를 추측으로 채운다. SKILL.md는 그 의도를 디스크에 적어두는 방식이다. 누적될수록 복리처럼 효과가 쌓인다. skill은 저작 포맷이고, plugin은 배포 방법이다. 여러 repo에 공유하거나 묶을 때 plugin으로 패키징한다.

Plugins·connectors — MCP 기반 connector가 에이전트로 하여금 이슈 트래커를 읽고 DB에 질의하고 Slack으로 메시지를 보내게 한다. plugin은 connector와 skill을 묶어 한 번에 설치하는 배포 단위다. Codex와 Claude Code 모두 MCP를 말하므로, 한쪽용 connector가 보통 다른 쪽에서도 그대로 동작한다.

Sub-agents — 코드를 쓴 모델은 자기 숙제를 채점할 때 관대하다. 그래서 두 번째 에이전트(때로는 다른 모델)가 첫 번째가 납득해 버린 부분을 잡아낸다. 한 에이전트는 탐색, 하나는 구현, 하나는 스펙 대비 검증. maker-checker 분리가 자동화의 신뢰성을 만든다. 보안 리뷰어는 high effort의 강한 모델, explorer는 빠른 read-only 모델처럼 역할별로 다른 모델을 부여한다.

여섯 번째는 메모리다. markdown 파일이나 Linear 보드 같은 단일 대화 밖의 저장소. 모델은 실행 사이를 잊지만 repo는 잊지 않는다. 이 디스크 기반 상태가 다음 날 아침 루프를 오늘 멈춘 지점에서 다시 살린다.

하나의 루프는 어떤 모양인가

매일 아침 automation이 repo에서 발동한다. triage skill이 어제의 CI 실패, 열린 이슈, 최근 커밋을 읽고 Linear 보드에 기록한다. 가치가 있는 각 항목마다 격리된 worktree를 열고, sub-agent가 수정 초안을 맡는다. 두 번째 sub-agent가 그 초안을 프로젝트 skill과 기존 테스트와 대비해 리뷰한다. 핵심은 이 단계들 중 어느 것도 사용자가 매번 프롬프트하지 않는다는 점이다. 한 번 설계하면 같은 루프가 매일 같은 모양으로 돈다.

루프가 대신해 주지 않는 세 가지

루프는 일을 바꾸지, 사람을 지우지 않는다. 오히려 루프가 좋아질수록 더 날카로워지는 세 가지 문제가 있다.

검증은 여전히 본인 몫이다. 무인으로 도는 루프는 무인으로 실수하는 루프다. verifier sub-agent를 분리하는 이유는 "끝났다"에 의미를 부여하기 위해서지만, 그래도 "done"은 증명이 아니라 주장이다. code review in the age of AI에서 Cherny는 일이 동작을 확인한 코드를 출하하는 것이라고 정의한다. 자동화는 그 확인을 도와줄 뿐 책임은 지지 않는다.

이해는 방치하면 썩는다. 루프가 직접 쓰지 않은 코드를 빨리 출하할수록 존재하는 것과 실제로 이해하는 것 사이 간극이 커진다. 이를 comprehension debt라고 한다. 매끄러운 루프는, 루프가 만든 것을 읽지 않으면 그 간극을 더 빨리 키운다.

편안한 자세가 위험한 자세다. 루프가 스스로 돌면 사용자는 의견 갖기를 멈추고 돌려받은 것을 그대로 받기 쉽다. cognitive surrender. 루프 설계는 판단을 갖고 하면 치료제, 사고를 피하려고 하면 가속제가 된다. 같은 행동, 정반대의 결과다.

그래서 우리도 따라 할 수 있는가

루프 엔지니어링은 일을 쉽게 만드는 기술이 아니다. 레버리지 지점이 옮겨진 것이다. 같은 루프를 만든 두 사람 중 한 명은 깊이 이해한 일을 더 빨리, 다른 한 명은 일을 이해하지 않으려고 사용한다. 루프는 그 차이를 모르지만 사용자는 안다. build the loop, stay the engineer.