새벽 1시에 PR이 쌓이기 시작한다. 팀이 야근을 한 게 아니다. 여러 에이전트 루프가 각자 할 일을 찾아서, 고치고, 검증하고, PR을 연 것이다. 사람이 하나하나 프롬프트를 넣지 않았는데도. Jason Zhou가 자기 회사 얘기로 푼 장면인데, 요즘 이걸 “loop engineering”이라고 부른다.
처음 들으면 또 에이전트 마케팅 신조어인가 싶다. 절반은 맞다. 그런데 까보면 절반은 진짜로 새로운 얘기가 들어 있다. 문제는 그 둘이 섞여 있어서, 새로운 쪽이 잘 안 보인다는 것이다.
이미 다룬 절반: inner loop
대부분의 글이 루프를 두 겹으로 나눈다. 안쪽(inner loop)은 우리가 매일 쓰는 에이전트 런타임이다. Claude Code나 Codex에 task를 주면, 맥락을 읽고 도구를 쓰고 결과를 확인하며 끝까지 간다. 추론하고, 행동하고, 관찰하고, 다시 추론하는 그 사이클. 여기서 답하려는 질문은 하나다 — 이 task를 어떻게 하면 안정적으로 끝낼까.
이 층은 결국 “모델 바깥”의 문제다. 컨텍스트, 스킬, 도구 정의, task 분해, 검증기. Anthropic이 Building Effective Agents에서 정리한 evaluator-optimizer 패턴이나, OpenAI Agents SDK의 Runner 추상화, Martin Fowler가 harness engineering이라고 부른 것. 전부 inner loop을 잘 돌리는 기술이다. Böckeler의 한 줄 공식이 깔끔하다. Agent = Model + Harness.
그런데 이 얘기는 전에 「모델 바깥의 전쟁」에서 한 번 길게 다뤘다. Plan → Act → Observe → Verify, evaluator를 일급 요소로 두기, 상태 기계, 사람이 게이트를 쥐는 액션. loop engineering 글에 나오는 inner loop 얘기는 거의 그것의 재탕이다. 그래서 여기서는 빠르게 넘어간다. 새로운 건 한 칸 바깥에 있다.
새로운 절반: 누가 일을 시키나
Addy Osmani가 outer loop을 정의한 문장이 핵심을 찌른다.
Loop engineering은 에이전트에게 프롬프트를 넣는 사람, 그러니까 당신 자신을 대체하는 일이다. 그 일을 대신 하는 시스템을 설계하는 것이다.
inner loop이 “이 task를 어떻게 끝낼까”라면, outer loop의 질문은 “다음에 뭘 할지 누가 정하나”다. 답은 사람이 아니라 트리거다 — cron, 웹훅, 인시던트, 다른 에이전트. 사람이 프롬프트 창 앞에 앉아 있을 필요가 없어진다. 새벽 1시에 PR이 쌓인 건 그래서다.
여기까지는 그냥 “스케줄러 붙인 자동화” 아닌가 싶다. 차이는 다음 지점에서 갈린다.
루프가 복리가 되는 곳: 공유 메모리
단일 루프 하나는 그냥 잘 만든 cron job이다. 흥미로워지는 건 여러 루프가 서로의 기록을 읽기 시작할 때다.
Zhou의 템플릿이 쓰는 구조는 단순하다. 영속적인 아티팩트(signals, tickets, tasks, docs)를 폴더로 두고, 모든 루프가 같은 폴더에 읽고 쓴다. 그리고 전역 LOG.md 하나. 큰 작업 전에 최근 기록 몇 줄을 읽고, 끝나면 한 줄 남긴다.
이게 왜 다른가. 지원 루프가 “export 기능이 어디 있는지 모르겠다”는 문의를 다섯 번 받고 시그널을 하나 만든다. 같은 시간 SEO 루프는 “트래픽은 좋은데 전환이 안 되는 페이지”를 발견하고 또 다른 시그널을 남긴다. 제품 루프는 이 둘을 한꺼번에 읽고, 원래 분석 데이터만 봤을 때보다 export 문제가 더 크다는 결론에 도달한다. 광고 루프가 찾은 “클릭률 높은데 받쳐주는 콘텐츠가 없는 키워드”는 그대로 SEO 루프의 입력이 된다.
루프들이 고립된 자동화가 아니라 회사가 학습한 것의 공유 지식베이스 위에서 도는 것이다. 이게 복리(compound)라는 말의 실체다. 각 루프의 결과가 다른 루프의 다음 판단을 바꾼다. LangChain이 네 겹 중첩 루프로 정리한 글에서도 같은 명제가 핵심이다. 바깥 루프의 한 사이클이 안쪽 루프를 더 똑똑하게 만든다는 것.
무인 루프의 진짜 난제: 언제 멈추나
여기서 흔히 빠지는 함정이 있다. outer loop을 “더 화려한 자동화”로 이해하는 것이다. 그런데 24시간 사람 없이 도는 루프의 가장 어려운 부분은 일을 시작하는 게 아니라 멈추는 것이다. 끝을 모르는 에이전트는 토큰을 태우거나, 더 나쁘게는 틀린 일을 자신 있게 반복한다.
Matthew Berman 쪽이 모은 Loop Library가 흥미로운 건 31개 루프마다 정지조건이 명시돼 있다는 점이다. 정지조건을 모아 보면 몇 가지 유형으로 갈린다.
- 목표 달성형 — “load time이 50ms 밑으로”, “테스트 커버리지 100%“처럼 검증 가능한 수치에 닿으면 멈춘다
- 고갈형 — 프로덕션 에러를 훑다가 더 고칠 게 없으면 멈춘다
- 시도 상한형 — 버그를 두 번 재현 못 하면 포기한다
- 연속 통과형 — N번 연속 통과해야 끝, 한 번 실패하면 streak 리셋
- 베이스라인 초과형 — holdout에서 기존 버전을 이길 때만 새 버전을 채택한다
- 예산 소진형 — 토큰/시간 예산이 바닥나면 멈춘다
Osmani가 쓰는 /goal 패턴도 같다. “test/auth가 전부 통과하고 lint가 깨끗할 때까지”처럼 검증 가능한 조건이 참이 될 때까지 돌린다. 그리고 중요한 건, 그 완료 판정을 구현한 에이전트 자신이 하게 두지 않는다는 것이다. 별도 모델이나 sub-agent가 채점한다. 자기 답안을 자기가 채점하면 루프는 항상 “다 됐다”고 한다.
여기에 한 겹 더 필요한 게 내구성이다. 몇 시간씩 도는 루프는 중간에 죽는다. LangGraph가 1.0에서 durable execution을 전면에 내세운 이유가 이것이다 — 노드마다 상태를 체크포인트로 저장해서, 죽어도 멈춘 지점에서 다시 시작한다. 사람의 승인을 기다리는 것도 “시계를 기다리는 것”과 똑같이 다룬다. 무인 루프를 실제로 굴리려면 멋진 프롬프트보다 이 인프라가 먼저다.
다들 같은 걸 다른 이름으로
재밌는 건 이걸 부르는 이름이 진영마다 다르다는 점이다. Zhou와 Forward Future는 loop engineering, Fowler는 harness engineering, Osmani는 “프롬프트하는 나를 대체하기”, LangChain은 네 겹 루프. Karpathy는 좀 더 멀리서 본다. 그는 autonomy slider라는 말로, 자율성은 한 번에 끝까지 올리는 게 아니라 시스템과 평가가 같이 좋아지는 만큼 천천히 올리는 다이얼이라고 했다. “2025년은 에이전트의 해”가 아니라 “에이전트의 10년”이라는 그의 말이, 무인 루프를 대하는 가장 정직한 태도에 가깝다.
오픈소스 계보로 봐도 이건 신조어가 아니다. 2023년 AutoGPT(별 17만)가 자율 루프의 원형을 보여줬고, OpenHands(별 7만)의 CodeAct는 실행하고 결과를 확인하고 다시 도는 루프 그 자체다. 이름만 새것일 뿐, 흐름은 3년째 이어지고 있다.
결국 다시 판단으로
그래서 loop engineering의 결론은 의외로 화려하지 않다. 실행을 무인으로 돌릴수록, 사람에게 남는 일은 줄지 않고 위로 올라간다. 무엇을 트리거할지, 어떤 시그널을 믿을지, 언제 멈춰야 하는지, 어디서 사람이 게이트를 쥘지를 정하는 일.
Osmani가 남긴 경고가 정확하다. 검증 없는 루프는 오류를 복리로 쌓고(미감독 오류), 빠른 자동화는 배포된 코드와 내 이해 사이에 간극을 만들고(이해 부채), 편한 자동화는 비판적 사고를 멈추라고 유혹한다(인지 항복).
루프를 만들어라. 단, 그냥 버튼 누르는 사람이 아니라 계속 엔지니어로 남을 작정인 사람처럼 만들어라.
이건 전에 「병목은 이미 판단으로 옮겨갔다」에서 한 얘기와 같은 자리에서 만난다. 코드를 쓰는 일이 거의 공짜가 되면서 병목이 판단으로 옮겨갔다고 썼는데, loop engineering은 그 판단을 시스템 설계로 옮긴 버전이다. 정지조건을 어떻게 짜고, 검증을 누구에게 맡기고, 자율성 다이얼을 어디까지 올릴지 — 그게 이제 엔지니어가 실제로 설계하는 것이다. 루프를 잘 돌리는 회사가 빨라지는 게 아니다. 자는 동안에도 학습하는 시스템을 가진 회사가 복리로 벌어진다.