2026년 6월에 단숨에 확산된
**Loop Engineering (루프 엔지니어링)**은, "AI에게 좋은 프롬프트를 입력하는 것"이 아니라 "AI에게 프롬프트를 계속해서 내보내는 메커니즘(루프)을 설계하는 것"이라는 패러다임 - 다만 현재 논의되고 있는 것은 거의
개발 도메인 (Development Domain) (CI 복구·lint·의존성 업데이트)에 관한 이야기 - 우리가 개발하고 있는 TechHive Agents (THA)는 이를
업무 도메인 (Business Domain) (HR 업무의 BPO)에서 상용 구현하고 있다. 루프를 업무에 도입하면 설계의 중심이 "검증의 자동화"에서 **"상태의 외부화 (Externalization of State)"와 "에스컬레이션 설계 (Escalation Design)"**로 이동한다 - 본 기사에서는 루프 엔지니어링의 4요소를 THA의 아키텍처 (컨텍스트 레저 / 리스크 티어 HITL / MCP 단일 입구)에 매핑하여, 업무 루프 특유의 설계 판단을 정리한다.

발단은 2026년 6월 7일, Peter Steinberger 씨 (OpenClaw 제작자)의 두 문장으로 된 포스트였다.

You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

다음 날에는 Google의 Addy Osmani 씨가 블로그 기사 "Loop Engineering"을 통해 개념을 정식화했다. 나아가 Anthropic에서 Claude Code를 이끄는 Boris Cherny 씨의 발언이 상징으로서 반복적으로 인용되고 있다.

I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

요점은 하나다. 레버리지(Leverage)의 소재가 "프롬프트를 입력하는 것"에서 "프롬프트를 입력하는 시스템을 설계하는 것"으로 옮겨갔다는 것이다.

"태스크를 찾는다 → 실행한다 → 검증한다 → 안 되면 고친다 → 다음을 결정한다" ── 이 사이클의 각 단계에서 기존에는 인간이 다음 수를 내놓았다. AI가 아무리 빨라도 인간이 바통을 넘겨줄 때까지 작업은 멈춘다. 루프 엔지니어링은 이 인간 병목(Human Bottleneck)을 제거하여, 조건을 만족할 때까지 시스템 스스로가 사이클을 돌린다.

각 레이어는 아래를 대체하는 것이 아니라 그 위에 쌓인다.

레이어	시기	설계 대상
① 프롬프트 엔지니어링 (Prompt Engineering)	~2024	1회성 지시의 질
...	...	...
③ 루프 엔지니어링 (Loop Engineering)	2026/6~
	③를 자율 주행시키는 반복 제어

Osmani 씨의 정리와 각지의 구현 사례를 횡단하면, 루프의 골격은 다음 4요소로 수렴한다.

1. 트리거 (Trigger)
스케줄, 이벤트, 조건으로 발화하는 메커니즘. 이것이 있어야 비로소 "한 번 실행한 것"이 아니라 "루프"가 된다.

2. 에이전트 (Agent)
에이전트 본체. 이 부분은 하네스 엔지니어링 (Harness Engineering)의 영역이며, 루프는 그보다 한 단계 위인 제어 레이어다.

3. 검증기 (Verifier)
성공을 기계적으로 판정할 수 없는 태스크는 루프화에 적합하지 않다. 개발 도메인에서 이 수법이 선행하고 있는 이유는 테스트, 타입 체크, lint라는 강력한 자동 검증기 (Verifier)가 처음부터 존재하기 때문이다.

4. 상태 관리 (State Management)
똑똑한 루프는 진행 상황을 대화 컨텍스트에 쌓아두지 않는다. git 이력, progress 파일, 태스크 정의와 같은 외부의 영속적 결과물로 상태를 분리한다. 매번 신선한 컨텍스트로 재시작하더라도, 외부 기록으로부터 "어디까지 끝났는지"를 다시 읽어 들여 속행할 수 있다. 장시간 태스크에서 파탄 나지 않는 이유는 여기에 있다.

여기서부터가 본론이다. 현재의 루프 엔지니어링 담론은 거의 모두가 개발 태스크 (CI 복구 트리아지, 의존성 업데이트 PR, lint 수정 패스)를 소재로 삼고 있다.

우리는 TechHive Agent (THA)라는, AI 에이전트를 "파견되는 디지털 직원"으로서 HR 부문에 제공하는 BPO 플랫폼을 개발하고 있다. 채용 매체 운영, 지원자 대응, 경리 처리와 같은 **업무 워크플로우 (Business Workflow)**를 에이전트가 정기적·이벤트 주도형으로 자율 실행한다.

즉 구조적으로는 업무 도메인의 루프 엔지니어링을 상용 구현하고 있는 셈이다. 그리고 실제로 해보니, 개발 루프와 업무 루프는 설계의 중심이 명확히 다르다.

개발 루프의 검증은 결정적 (deterministic)이다. 테스트가 통과하느냐 통과하지 못하느냐의 문제다. 업무 루프에는 그런 것이 없다. "지원자에게 보내는 답장 문구가 적절한가", "근태 데이터의 대조 결과가 올바른가"를 기계적으로 완벽하게 판정할 수는 없다.

THA에서는 이를 Risk Tier라는 개념으로 흡수하고 있다. 태스크를 완전 자동 판정하려고 하는 것이 아니라, 액션의 불가역성(irreversibility)에 따라 계층화하고, 계층마다 검증의 주체를 바꾼다.

Tier	액션의 성질	검증의 주체
T1	읽기 전용	자동 (루프 내에서 완결)
...

이는 루프 엔지니어링 용어로 말하자면, verifier를 단일한 자동 판정기가 아니라, 에스컬레이션(escalation) 기능이 포함된 다층 게이트(multi-layered gate)로 설계하는 것을 의미한다. 서두에서 소개한 담론에서도 "정말로 어려운 것은 검증·정지 조건·인간으로의 에스컬레이션 설계"라고 지적되었지만, 업무 도메인에서는 이것이 난관이 아니라 설계의 주인공이 된다.

개발 루프의 progress.txt는 컨텍스트 범람(context overflow) 대책을 위한 실용적인 테크닉이다. 업무 루프에서는 사정이 달라진다. "에이전트가 언제·무엇을·어떤 근거로 실행했는가"는 고객에 대한 설명 책임과 감사의 대상이 된다.

THA에서는 session_contexts라는 **append-only 레저(ledger)**를 업무 상태의 SoT (Source of Truth)로 삼고 있다.

• 에이전트 세션은 매번 새롭게(fresh) 기동하며, 레저로부터 업무 문맥을 다시 읽어온다.
• 실행 결과는 오직 추가(append)만 가능하다 (덮어쓰기나 삭제 없음).
• "지난주의 연속된 작업", "지난번의 에스컬레이션 결과"도 레저를 통해 인계받는다.

핵심은 이것이 루프의 재개 가능성과 감사 가능성을 동일한 메커니즘으로 보장한다는 점이다. 개발 루프의 "상태의 외부화"를 업무에 도입하면, 자연스럽게 회계 장부와 같은 설계에 도달하게 된다.

자율 루프가 폭주했을 때 피해 범위를 결정하는 것은 "에이전트가 무엇에 접근할 수 있는가"이다. THA에서는 에이전트가 DB나 외부 API에 접근하는 경로를 단 하나의 MCP 서버로 집약하고 있다.

Agent Session ──> MCP (/mcp) ──> 인증 ──> Risk Tier 체크 ──> 툴 실행 ──> 감사 로그

루프 엔지니어링의 문맥에서 말하자면, 이는 정지 조건을 프롬프트가 아닌 인프라로 강제하는 설계다. "T3 이상은 승인 없이 실행하지 마라"라고 프롬프트에 쓰는 것이 아니라, MCP 레이어에서 물리적으로 통과시키지 않는 것이다. 비결정적인 LLM 런타임에 대한 신뢰성 엔지니어링(reliability engineering)으로서, 게이트는 확률적인 층(프롬프트)이 아니라 결정적인 층(API)에 두어야 한다는 것이 우리의 결론이다.

THA에는 두 가지 실행 모드가 있다.

• Mode A (Scheduled Worker): cron / webhook / 메일 수신을 트리거로, 오케스트레이터 페르소나가 업무 워크플로우를 자율 실행한다. session_contexts로 업무 장부를 관리한다.
• Mode B (Ad-hoc Assistant): 채팅으로부터의 요청에 응답하는 범용 에이전트다. 업무 장부는 가지지 않는다.

이는 루프 엔지니어링 용어에서의 **closed loop (자율 주행) / open loop (인간 주도)**의 분리에 해당한다. 중요한 것은 이 경계를 운영 규칙이 아니라 타입 시스템(type system)과 설정으로 강제하고 있다는 점이다. Mode B의 에이전트가 멋대로 업무 루프에 참여할 수는 없다.

루프 엔지니어링 요소	개발 도메인의 전형	THA (업무 도메인)에서의 구현
트리거	cron, CI 이벤트	webhook / cron / 메일 수신 (Mode A)
상태의 외부화	progress.txt, git 이력	session_contexts append-only 레저
verifier	테스트·타입·lint	Risk Tier 다층 게이트 (T1 자동 ~ T4 이중 승인)
정지 조건	예산·최대 시도 횟수	MCP 레이어에서의 인프라 강제 + HITL
에스컬레이션	issue 생성	T3/T4 승인 플로우 (인간의 대기 시간을 포함한 루프 재개 설계)

루프 엔지니어링에는 구조적인 한계가 지적되어 왔으며, 업무 도메인에서는 이것이 더욱 심각하게 작용한다.

① 리뷰 병목 현상 (Review Bottleneck). 생성량을 10배로 늘려도 인간이 리뷰할 수 있는 양은 변하지 않는다. 개발 분야라면 리뷰되지 않은 PR(Pull Request)이 쌓일 뿐이지만, 업무 도메인에서는 T3 승인 대기 건이 쌓이면 업무 자체가 중단된다. 그렇기에 THA에서는 "무엇을 T1/T2로 넘길 수 있는가(=인간을 거치지 않고 흘려보낼 수 있는가)"를 판별하는 것이 도입 설계의 핵심 작업이 된다.

② 토큰 비용 (Token Cost). 자율 루프(Autonomous Loop)의 비용은 단발적 이용보다 몇 배에서 수십 배까지 불어난다. 업무 BPO에서는 "이 업무를 인간이 수행할 때 몇 분이 걸리는가"를 기준으로 한 가격 설계와, 루프 측의 비용 관리(캐시 전략·모델 선택의 계층화)를 세트로 고려해야 한다.

③ 판단을 요하는 태스크는 남는다. "완료"의 정의에 인간의 판단이 필요한 태스크는 루프화에 적합하지 않다. 루프 설계란, 맡길 범위와 인간이 남길 범위의 경계 획정 그 자체이며, 이는 개발이든 업무든 변하지 않는 보편 법칙이라고 생각한다.

• 루프 엔지니어링은 "프롬프트를 입력하는 것"에서 "프롬프트를 입력하는 메커니즘을 설계하는 것"으로의 레버리지 이동이다.
• 개발 도메인에서 앞서 나가는 이유는 강력한 자동 검증기(Verifier, 테스트)가 처음부터 존재하기 때문이다.
• 업무 도메인으로 가져올 경우, 설계의 무게 중심은 **검증의 다층화 (Risk Tier) · 상태의 감사 가능한 외부화 (append-only Ledger) · 인프라 레벨의 정지 조건 (MCP 단일 입구)**로 옮겨간다.
• 루프가 아무리 똑똑해져도, 최종적인 품질 판단과 책임은 인간이 갖는다. 엔지니어의 일은 사라지는 것이 아니라, "루프를 설계하고 감독하는 것"으로 옮겨간다.

지난 기사에서는 THA의 방법론(Methodology)을 "비결정론적인 LLM 런타임(Runtime)에 대한 신뢰성 엔지니어링"으로 정리했다. 이번에 루프 엔지니어링이라는 보조선을 그어보니, 당시의 설계 판단군(BFC / Skill / Risk Tier)은 "업무 루프를 안전하게 자율 주행시키기 위한 반복 제어 설계"였다고 다시 말할 수 있다. 이름이 나중에 따라온 듯한 느낌이다.

• Addy Osmani, "Loop Engineering" (2026-06-07)
• Peter Steinberger 씨의 X 포스트 (2026-06-07)
• Boris Cherny 씨의 발언 (Acquired Unplugged, WorkOS 주최, 2026-06-02)