루프 엔지니어링 — 작업장에
'야간 교대조'를 들이다

끝난 줄 알았던 이야기의 다음 층

3편에서 하네스를 공개하면서 이 진화 이야기를 마무리했다고 생각했어요. 지침(1층) 위에 강제·실행·안전망(2~4층)을 얹었으니, AI가 일하는 환경으로는 완성이라고요. 그런데 몇 주를 더 굴려보니 마지막 불편 하나가 그대로 남아 있었어요. 시동은 여전히 내가 건다는 것.

매주 금요일이면 용어집에 올릴 새 용어 리서치를 시키고, 매일 아침이면 뉴스 수집을 확인하고, 백업이 밀리지 않았는지 점검하고. 작업장은 훌륭한데, 내가 출근해서 문을 열어야만 돌아가는 공장이었던 거예요. 잘 만든 하네스일수록 이 아이러니가 선명해져요 — 일 하나하나는 빨라졌는데, '일을 시키는 일'은 고스란히 내 몫으로 남아요.

이 마지막 층을 업계는 이제 루프 엔지니어링이라고 부르기 시작했어요. 2026년 들어 자리 잡기 시작한 신조어인데, 기저 개념은 이미 공식 문서에 있어요. 하나씩 볼게요.

사실, 하네스 안에도 루프는 이미 있었다

고백하자면 3편의 작업장에도 루프는 이미 여러 개 돌고 있었어요. 턴이 끝날 때마다 자동 저장(체크포인트)이 돌고, 지시가 들어올 때마다 라우팅이 돌고, 세션이 시작될 때마다 브리핑이 주입되고, 세션이 끝나면 백업이 원격 저장소로 밀려나가요. 전부 hook이 만드는 반복이죠.

그런데 이 루프들에는 공통점이 있어요. 전부 '내가 연 세션 안'에서만 돌아요. 세션이 닫히면 작업장 전체가 잠들어요. 말하자면 하네스의 루프는 품질을 지키는 반복이에요 — 내가 일을 시키는 동안, 매 턴 빠뜨리면 안 되는 것들을 대신 챙겨주는. 루프 엔지니어링이 노리는 건 다른 종류의 반복이에요. 목적을 향한 반복 — 내가 없어도, "이게 되면 끝"이라는 기준에 닿을 때까지 스스로 도는 것.

둘은 한 핏줄이기도 해요. 앞 편의 결론이 "규칙을 '부탁'이 아니라 자동 실행으로"였다면, 이번 편은 그 문장의 목적어만 바뀌어요. 하네스는 '규칙'을 구조로 만들었고, 루프는 '반복'을 구조로 만들어요.

루프 엔지니어링이란 — '목적 달성까지'의 반복

정의부터 분명히 할게요. 루프 엔지니어링은 사람이 매번 프롬프트를 치는 대신, 트리거(언제 시작하나)·완료 기준(뭐가 되면 끝나나)·검증(제대로 됐나)을 설계해서 에이전트가 '작업→검증→반복'을 스스로 돌게 만드는 일이에요.

뿌리는 공식 문서에 있어요. Anthropic은 에이전트의 작동을 "맥락 수집 → 행동 → 검증 → 반복(gather context → take action → verify work → repeat)"이라는 피드백 루프로 정의해요. 그리고 업계에서 에이전트 정의로 가장 널리 인용되는 Simon Willison의 한 줄도 이래요 — "에이전트는 목적을 달성하기 위해(to achieve a goal) 루프 안에서 도구를 돌리는 LLM이다."

출처: Building agents with the Claude Agent SDK(Anthropic) · Designing agentic loops(Simon Willison)

여기서 중요한 건 '루프'가 아니라 '목적을 달성하기 위해' 쪽이에요. 그냥 반복시키는 건 쉬워요. 어려운 건 두 가지예요 — 목적에 닿을 때까지 계속 가게 만드는 것, 그리고 닿았을 때(혹은 잘못 갔을 때) 멈추게 만드는 것. 그래서 실무자들 사이에 도는 경구 하나를, 저도 루프를 설계할 때마다 빌려서 물어요.

"완료 기준을 말할 수 없으면, 그건 루프가 아니라 소원이다."(개발 블로그 sabrina.dev의 표현이에요.) "알아서 잘 정리해줘"는 소원이에요. "발행된 글 전체를 스캔해서 이 규칙 위반이 0건이면 통과, 1건이라도 있으면 알림"은 루프고요. 루프 엔지니어링의 절반은 이 완료 기준을 검증 가능한 문장으로 바꾸는 일이에요.

하네스와 루프 — 공간의 설계, 시간의 설계

그럼 하네스 엔지니어링과는 정확히 뭐가 다를까요. 제가 정리한 구도는 이래요. 하네스는 공간의 설계고, 루프는 시간의 설계예요.

그래서 관계를 세 문장으로 줄이면 이래요.

• 루프는 하네스의 대체가 아니라, 하네스를 시간 축으로 돌리는 것이에요. 하네스가 5층으로 높아진 게 아니라, 그 건물 전체에 교대 근무가 생긴 거예요.
• 하네스 없는 루프는 위험해요. 검증 게이트 없이 반복만 시키면, 잘못된 산출물이 밤새 대량생산돼요. 루프는 하네스 위에서만 안전해요.
• 루프 없는 하네스는 아까워요. 일이 제대로 되게 만들어놓고, '일을 시키는 일'은 계속 사람이 하는 상태니까요.

루프의 해부 — 다섯 가지 부품

실제로 루프 하나를 설계할 때 정하는 건 다섯 가지예요.

• ① 트리거 — 언제 시동이 걸리나. 매일 아침 7시(스케줄), 수집이 끝난 직후(이벤트), 새 요청이 들어왔을 때(API). 사람의 기억력이 트리거인 한, 그 일은 바쁜 주에 반드시 빠져요.
• ② 작업 — 한 바퀴에서 실제로 하는 일. 루프 하나에 일 하나만 시키는 게 정석이에요. 실패 원인을 격리할 수 있고, 산출물을 읽기도 쉬워요.
• ③ 검증 — 작업한 자신이 아니라 별도의 판정자가 결과를 확인해요. 규칙 기반 검사(맞춤법·형식·수치), 테스트, 검수 에이전트. 3편에서 "AI는 그럴듯하게 틀린다"고 했죠 — 루프에서는 그 틀림이 반복·증폭되니까 검증이 더 중요해요.
• ④ 완료 기준(+상한) — 뭐가 되면 멈추나. 그리고 얼마까지 돌아도 되나. 횟수·비용·시간 상한이 없는 루프는 잠재적 사고예요.
• ⑤ 사람 게이트 — 발행·삭제·발송처럼 되돌릴 수 없는 행동 앞에는 사람의 승인을 놓아요. 어디에 놓을지가 루프 설계의 가장 중요한 판단이에요(뒤에서 자세히).

'상태 영속화'는 Anthropic이 장기 실행 에이전트 하네스 글에서 공식화한 원리이기도 해요. 에이전트의 기억(컨텍스트)은 세션마다 리셋되니, 진행 상황을 진행 파일과 git 기록에 남겨 다음 바퀴가 이어받게 하라는 것. 2편에서 본 "적어두지 않은 건 사라진다"가 루프의 세계에서도 그대로 통해요.

출처: Effective harnesses for long-running agents(Anthropic, 진행 파일 + git 히스토리로 세션 간 다리 놓기)

실전 — 지금 돌고 있는 교대조들

이론이 아니라는 걸 보여드릴 차례예요. 이 글을 쓰는 시점에 제 작업장에서 실제로 돌고 있는 루프들이에요. 정기로 도는 것부터 요청할 때만 도는 것까지 아홉 계열인데, 대표만 추릴게요.

게이트 이야기 — '금지'가 아니라 '불가능'으로

루프 설계에서 제일 공들인 부분이 이거예요. 위 루프들에는 공통점이 있는데, 비가역 행동(발행·삭제·발송) 앞에 전부 사람이 서 있어요. 그리고 그 게이트를 세우는 방식이 중요해요.

처음엔 규칙으로 적었어요 — "승인 없이 발행하지 마." 그런데 3편에서 정리했듯, 문서의 규칙은 부탁이에요. 그래서 게이트도 하네스 방식으로 바꿨어요. 신조어 루프의 경우, 발견을 담당하는 클라우드 쪽에는 발행에 필요한 열쇠(데이터베이스 쓰기 권한)를 아예 주지 않았어요. 발행 열쇠는 제가 승인한 뒤에 여는 별도 절차에만 있어요. 무승인 발행이 '하면 안 되는 일'이 아니라 '할 수 없는 일'인 거예요. 뉴스 파이프라인의 '초안으로만 쌓기', 메일함 루프의 '격리까지만'도 같은 원리예요 — 권한과 구조로 긋는 선이, 프롬프트로 긋는 선보다 세요.

이건 업계가 수렴 중인 방향이기도 해요. 에이전트 자율성을 다룬 연구는 사용자의 역할을 다섯 단계로 나눠요 — 직접 조작자부터, 협업자, 자문 대상, 승인자(approver), 관찰자까지. 포인트는 자율성 수준이 AI의 능력에 따라 정해지는 게 아니라 설계자가 의도적으로 정하는 결정이라는 거예요. 저는 "읽고 정리하는 건 관찰자, 비가역 행동은 승인자"로 정해두고 모든 루프에 같은 기준을 적용해요. GitHub이 에이전트 자동화(gh-aw)를 설계하면서 저장소 접근을 기본 읽기 전용으로 두고 "에이전트는 머지할 수 없다"고 못 박은 것도 같은 사상이에요.

출처: Levels of Autonomy for AI Agents(Feng 외, 2025) · Continuous AI in practice(GitHub, 2026)

브레이크 없는 루프 — 남의 사고에서 배우기

게이트와 상한이 왜 이렇게까지 중요한지는, 그게 없던 쪽의 기록이 말해줘요.

• 지시를 무시하고 프로덕션을 지운 에이전트(2025-07) — 한 코딩 플랫폼의 AI 에이전트가 "코드 변경 금지" 지시 중에 운영 데이터베이스를 삭제했어요. 기업 1,190여 곳 데이터가 날아갔고, 에이전트는 가짜 데이터를 만들어 이를 덮으려고까지 했어요. CEO가 공개 사과한 이 사건의 교훈은 명확해요 — "하지 마"라는 지시는 게이트가 아니에요. 운영 환경 접근 권한 자체를 끊는 것이 게이트예요.
• 11일간 아무도 몰랐던 4만 7천 달러(보고 사례, 2026) — 리서치 파이프라인에서 검증 에이전트가 "분석이 부족하다"고 반려하면 분석 에이전트가 다시 만들고, 또 반려하고… 두 에이전트가 서로를 11일간 호출하며 약 4만 7천 달러를 태운 사례가 보고됐어요. 발견 경로가 뼈아파요 — 알림이 아니라 사람이 청구서를 보고 알았어요. 루프 감지도, 비용 상한도, 횟수 제한도 없었던 거예요.

두 번째 사례를 전한 글의 문장이 루프 실패의 본질을 정확히 찔러요. "AI 에이전트는 일하는 채로 실패한다. 프로세스는 살아 있고, API 호출은 성공한다." 사람의 실패는 멈추니까 눈에 띄는데, 루프의 실패는 계속 돌아서 안 보여요. 그래서 무한 루프의 원조 격인 기법(잠시 뒤에 나와요)을 공식 플러그인으로 만든 Anthropic조차 최대 반복 횟수 옵션을 표준으로 달았어요. 루프를 발명한 진영 스스로 브레이크를 표준 장착한 거예요.

출처: Fortune(2025-07) · AI Incident Database #1152 · The AI agent that cost $47,000(DEV, 보고 사례)

업계 지도 — 이 흐름은 어디까지 왔나

루프 엔지니어링이라는 말 자체는 새것이지만, 흐름은 2025년부터 뚜렷했어요. 지도를 그려보면 —

• 극단 실험: Ralph 기법(2025-07) — 같은 프롬프트 파일을 셸의 무한 루프로 AI에 계속 먹이는, 문자 그대로 '배시 한 줄'짜리 기법. 진행 상태를 AI의 기억이 아니라 파일과 git에 쌓는다는 원리가 핵심이에요. 창안자는 5만 달러짜리 외주 상당의 신규 프로젝트를 약 297달러의 컴퓨팅으로 해냈다고 주장하면서도, 기존 코드베이스에는 본인도 쓰지 않는다고 한계를 그어요.
• 최소 사례: cron + 테이블 하나(2025-04) — 한 연구자는 데이터베이스 테이블 1개와 정기 실행 몇 개만으로 가족용 AI 비서를 만들었어요. 아침마다 일정·날씨·우편물을 브리핑하는. "쓸모 있는 개인 도구에 화려한 기법은 필요 없다"는 게 그의 결론이에요. 루프의 최소 단위는 트리거 하나 + 상태 저장소 하나예요.
• 명명: Continuous AI(2025~) — GitHub의 연구 조직은 이 흐름에 CI/CD(지속적 통합·배포)에 빗댄 이름을 붙였어요. 전통 CI가 '정답이 있는 검사'를 자동화했다면, Continuous AI는 판단이 필요한 잡무(문서 낡음 감지, 이슈 분류)를 자동화한다는 구분이에요.
• 인프라의 공식화: 스케줄 실행(2026) — Claude Code에는 프롬프트·저장소·연결을 묶어 클라우드에서 정기 실행하는 routines 기능이 생겼어요(집필 시점 기준 research preview 단계). 노트북을 닫아도 도는 루프가 공식 기능이 된 거예요. GitHub Actions의 스케줄 실행과 결합하는 패턴은 공식 문서가 예제로 안내하고요.
• 판정자: eval 루프 — "eval(평가 기준)이 곧 스펙이자 인수 기준이자 로드맵"이라는 담론이 힘을 얻고 있어요. 루프가 도는 세계에서는 평가 기준이 곧 기획서라는 거죠. 제 골든셋 회귀 루프도 이 사상의 실무 축소판이에요.

출처: Ralph Wiggum as a "software engineer"(Geoff Huntley) · Stevens(Geoffrey Litt) · Continuous AI(GitHub Next) · Automate work with routines(공식 문서) · Evals are the new PRD(Braintrust)

숫자로 보는 현재 상태

※ 이 글을 쓰는 시점의 실측 구성이에요. 루프는 계속 추가·조정되니 숫자보다 구조를 봐주세요.

마무리 — 루프의 네 가지 원칙

이 루프들을 굴린 경험과 남의 사고 기록에서 추린 원칙 네 개로 줄일게요.

자주 묻는 것