또 새로운 용어? Loop Engineering: Claude Code, RLM, Dynamic Workflow (Jeongmin Lee, LinkedIn 2026-06-09)

요약

Jeongmin Lee가 2026년 6월 9일 LinkedIn에 올린 한국어 카드 포스트다. loop engineering이라는 신조어가 무엇을 가리키는지 정의하고, 그 정의를 RLM(Recursive Language Model)이라는 모델 구조에 연결해 7개 항목으로 풀어낸다.

글의 중심 주장은 두 문장으로 요약된다. loop engineering은 에이전트를 프롬프트하는 시스템을 설계하는 일이다. 그리고 RLM을 이해해야 Claude Code의 dynamic workflow가 왜 그렇게 설계됐는지 보인다.

저자는 용어 인플레이션에 대한 방어도 함께 편다. 새로운 용어 놀이를 많이 한다는 비아냥이 있다는 것을 인정하면서도, loop 자체는 LLM의 부족한 판단력을 구조적으로 극복한다는 점에서 근거가 충분하다고 적는다. 저자 자신이 3개월 전에도 같은 취지의 글을 썼다는 언급이 이 방어의 근거로 붙는다.

이 자료는 1차 연구가 아니라 인용과 해설로 이루어진 2차 자료다. 저자가 직접 측정한 수치는 없고, 세 사람의 발언과 RLM 논문의 구조를 요약해 전달한다. 따라서 loop engineering의 효과를 재는 근거가 아니라, 흩어져 있던 개념들을 하나의 설명 순서로 엮은 입문 지도로 읽는 것이 적절하다.

배경

용어의 출발점은 두 사람의 발언이다. 두 발언 모두 프롬프트 작성이 아니라 루프 설계가 실제 작업이라고 말한다는 점에서 같은 방향을 가리킨다.

이 발언들이 겨냥하는 것은 사람이 매 단계 개입하는 기존 작업 방식이다. 사람이 프롬프트를 입력하고, 결과를 확인하고, 다시 입력한다. 저자는 이 방식에 한계가 있다고 진단한다. 판단과 진행의 주도권이 매번 사람에게 돌아오기 때문에 사람이 자리를 비우면 작업도 멈춘다.

loop engineering은 그 자리를 자동 순환으로 대체하려는 시도다. 저자가 제시하는 순환은 다섯 단계로 이어진다.

두 방식의 차이는 반복 횟수가 아니라 반복을 누가 이어 붙이는가에 있다. 기존 방식에서는 사람이 매 회차의 연결 고리이고, loop engineering에서는 그 고리가 시스템 안으로 들어간다.

저자가 용어 논쟁을 다루는 태도도 배경의 일부다. 지난 3년간, 그리고 최근 수 개월 사이 등장한 여러 용어들 때문에 사용자들의 피로감이 매우 높다는 사실을 저자는 먼저 인정한다. 그 위에서 loop만큼은 근거가 있다고 주장하는 구성이다.

그 근거로 저자가 드는 것은 두 가지다. 하나는 본인이 3개월 전에도 같은 취지의 글을 썼다는 사실이고, 다른 하나는 loop가 LLM의 부족한 판단력을 구조적으로 극복한다는 진단이다. 뒤쪽 문장이 이 글의 논리적 출발점에 해당한다. 모델 하나의 판단이 미덥지 않다면 그 판단을 여러 번 나누어 서로 검증하게 만드는 구조로 보완한다는 발상이기 때문이다. 본문 전체는 이 발상이 RLM이라는 구체적 구조로 어떻게 구현되는지를 따라간다.

핵심 개념

본문을 읽는 데 필요한 개념은 다섯 가지다. 순서대로 풀이하면 뒤의 방법 절이 그대로 이어진다.

loop engineering은 에이전트를 프롬프트하는 시스템을 설계하는 일을 뜻한다. 설계 대상이 문장 하나가 아니라 태스크 발견부터 다음 태스크 결정까지 이어지는 순환 전체라는 점이 이 이름의 요지다.

REPL은 코드를 한 줄씩 받아 실행하고 결과를 즉시 돌려주는 대화형 실행 환경을 말한다. 실행 사이에 값이 변수로 남아 있으므로, 앞에서 만든 결과를 이름으로 다시 불러 쓸 수 있다는 점이 이 환경의 특징이다.

RLM은 Recursive Language Model의 약어로, 컨텍스트를 통째로 적재하지 않고 REPL 환경의 변수로 두는 모델 구조를 가리킨다. 에이전트가 그 변수에서 필요한 부분만 골라 읽는다. 앞의 REPL 특징이 여기서 그대로 쓰인다. 값이 변수에 남아 있으니 모델이 그 값을 자기 컨텍스트로 옮기지 않고도 다룰 수 있다.

scaffold는 모델 주위에 짜 놓은 보조 실행 구조를 뜻한다. RLM에서 scaffold는 print 출력을 강제로 자르는 역할을 맡아, 불필요한 정보가 컨텍스트를 채우지 못하게 한다.

서브에이전트는 상위 에이전트가 위임한 작업을 격리된 컨텍스트에서 수행하는 하위 실행 단위다. 본문의 핵심 논점은 이 서브에이전트가 결과를 어떤 형태로 상위에 돌려주는가에 있다.

KV cache hit은 이전 요청에서 만들어 둔 key와 value 캐시를 다시 쓰는 비율을 말한다. 같은 앞부분을 반복해서 다시 계산하지 않아도 되므로 이 비율이 높을수록 추론 비용이 내려간다.

방법

루프를 이루는 다섯 building block

저자는 Addy Osmani가 loop engineering을 다섯 building block으로 정리했다고 인용한다. 본문은 다섯 이름만 나열하고 각 블록이 무엇을 하는지는 설명하지 않는다. 아래 표의 역할 열은 본 글의 서술이 아니라 원출처를 다룬 Loop Engineering (Addy Osmani, 2026-06-07) 페이지에서 옮겨 온 것이다.

본 글에서 이 목록이 하는 일은 loop engineering이 단일 기법이 아니라 여러 도구의 조합이라는 점을 보이는 것이다. 저자는 이 조합을 소개한 뒤 곧바로 이론적 근거로 넘어간다.

RLM의 컨텍스트 처리

RLM과 기존 LLM의 차이는 입력을 다루는 시점에서 갈린다. 보통 LLM은 입력 전체를 context window에 한꺼번에 올린다. RLM은 그렇게 하지 않는다.

이 구조가 노리는 효과는 컨텍스트 오염 차단이다. 에이전트가 읽을 범위를 스스로 정하고 출력이 scaffold 단에서 잘리기 때문에, 불필요한 정보가 컨텍스트를 채우는 일이 줄어든다.

두 장치가 서로 다른 방향을 막는다는 점이 중요하다. 변수 보관은 입력 쪽에서 들어오는 양을 줄이고, print 출력 절단은 실행 중에 생겨나는 양을 줄인다. 전자는 에이전트가 스스로 고르는 선택이고 후자는 scaffold가 강제하는 제약이다. 에이전트가 실수로 큰 값을 출력하더라도 그 결과가 컨텍스트로 흘러들지 않는 이유가 여기에 있다.

저자는 RLM 논문을 읽어보면 이 구조가 명쾌하게 잡힌다고 덧붙이지만 논문의 제목, 저자, 연도는 본문에 적지 않는다.

서브에이전트 결과의 반환 방식

본문이 가장 공들여 설명하는 대목은 서브에이전트 결과가 상위로 돌아오는 경로다. 기존 CodeAct와 서브에이전트를 조합한 구조에서는 서브에이전트 결과 전체가 상위 컨텍스트에 올라갔다. RLM의 llm_query()는 다른 경로를 쓴다.

이 차이가 만드는 결과는 두 가지다. 하나는 상위 에이전트의 일이 결과 재생성에서 변수 검증으로 줄어든다는 것이다. 다른 하나는 최종 출력의 길이가 상위 모델이 한 번에 생성할 수 있는 분량에 묶이지 않는다는 것이다. 변수는 값을 그대로 담고 있을 뿐이라 상위 모델이 그 내용을 다시 써 내려갈 필요가 없기 때문이다.

FINAL()이 이 흐름의 종착점이다. 상위 에이전트는 변수의 내용을 옮겨 적는 대신 그 변수를 FINAL()에 넘겨 최종 결과로 확정한다. 값이 한 번도 토큰으로 풀리지 않고 그대로 전달되므로, 서브에이전트가 만든 분량이 아무리 커도 상위 단계에서 다시 비용이 발생하지 않는다.

Claude Code dynamic workflow

저자는 Claude Code의 dynamic workflow가 이 구조를 그대로 가져갔다고 본다. dynamic workflow는 Opus 4.8과 함께 출시된 기능이다.

구조의 목적은 단일 context window에서 생기는 세 가지 실패를 막는 것이다. agentic laziness는 에이전트가 할 일을 끝까지 하지 않는 현상, self-preferential bias는 자기 산출물을 후하게 평가하는 편향, goal drift는 진행 도중 목표에서 벗어나는 현상을 가리킨다. 저자는 에이전트가 긴 작업 중간에 멈추거나 결과를 대충 넘기던 현상에 이유가 있었다고 진단하면서, RLM이 이 세 가지를 구조로써 차단한다고 정리한다.

즉 컨텍스트를 격리하는 설계는 성능 최적화의 부산물이 아니라 실패 모드를 겨냥한 대응이라는 것이 저자의 해독이다.

실행 패턴 세 가지

dynamic workflow 위에서 쓸 수 있는 패턴으로 본문은 세 가지를 든다.

세 패턴은 서브에이전트를 쓰는 목적이 서로 다르다. 첫째는 처리량을 늘리려고 나누고, 둘째는 정확성을 높이려고 검증자를 분리하며, 셋째는 선택지를 비교하려고 경쟁시킨다.

이 목적 차이는 앞 절의 컨텍스트 격리와 맞물린다. fan-out-and-synthesize는 각 서브에이전트가 자기 몫만 보면 되므로 격리가 분업의 전제가 된다. adversarial verification은 검증자가 구현자의 사고 과정을 물려받지 않아야 편향이 끊기므로 격리가 검증의 전제가 된다. tournament는 후보들이 서로의 답에 영향을 받지 않아야 비교가 성립하므로 격리가 공정성의 전제가 된다.

적용 범위에 대해 저자는 개발 업무 밖까지 넓혀 잡는다. 코드 리팩토링뿐 아니라 리서치 검증이나 서포트 티켓 분류 같은 비개발 업무에서도 Claude Code 안에서 바로 쓸 수 있다는 서술이다.

비용

RLM 구조가 비용 면에서 유리하다는 것이 본문의 여섯 번째 항목이다. 근거는 두 가지로 제시된다.

첫째는 캐시 재사용이다. 서브에이전트가 한 단계씩 작업하면 system prompt와 이전 메시지가 그대로 유지된다. 앞부분이 바뀌지 않으므로 캐시를 계속 재사용할 수 있고, 저자는 KV cache hit 비율이 90%까지 올라갈 수 있다고 적는다.

둘째는 읽기 범위의 축소다. 에이전트가 읽을 범위를 직접 결정하므로 전체 프롬프트를 매번 스캔하는 비용이 빠진다. 앞선 절에서 설명한 컨텍스트 변수 모델이 그대로 비용 이점으로 연결되는 지점이다.

다만 이 두 가지는 구조가 주는 잠재적 이점이고, 현재 실제 운영 비용은 별개 문제라는 것이 다음 절의 내용이다.

한계

본문이 스스로 인정한 한계는 세 가지다.

1. 토큰 사용량이 크다. 현재의 dynamic workflow는 토큰을 많이 쓴다. 저자는 여기에 자제 기준을 하나 붙인다. 일반 코딩 작업에 verifier 5개를 붙일 필요는 없다는 것이다. 즉 패턴을 최대치로 적용하는 것이 기본값은 아니다.
2. 환경 구축 부담이 크다. 이 환경을 직접 만드는 것도 비용 면에서 아직 부담이 크다고 적는다.
3. 용어 피로감이 높다. 지난 3년간, 그리고 최근 수 개월 사이 등장한 여러 용어들로 사용자들의 피로감이 매우 높다. loop engineering이라는 작명이 비아냥의 대상이 되는 맥락을 저자가 인정한다.

전망은 두 조건으로 제시된다. 모델 비용이 내려가고 cache hit 비율이 높아질수록 loop의 활용은 기본값이 된다는 것이다. 저자는 마무리에서 RLM이 무엇인지 알아두라고 권하며, 그래야 dynamic workflow가 왜 그렇게 설계됐는지 보이고 다음 스텝으로 무엇을 준비해야 하는지 감이 잡힌다고 적는다. 이어서 지난 몇 년간 Transformer 쇠퇴론을 비롯한 여러 비관 속에서도 프론티어 랩이 주장한 내용이 결국 AI 발전의 큰 방향에 모두 반영되었다는 회상을 덧붙인다.

자료 성격과 검증 범위

이 페이지의 근거는 3,200자 남짓의 LinkedIn 포스트 한 편뿐이다. 인용 대상을 확인하려면 별도 자료가 필요하다는 점을 명시해 둔다.

• 본문에 등장하는 수치는 KV cache hit 비율 90%와 verifier 5개 두 가지뿐이고, 둘 다 측정값이 아니라 서술 안의 언급이다.
• RLM 논문은 제목, 저자, 연도 없이 개념만 인용된다. 본 wiki에서는 Recursive Language Models (RLM) 페이지가 그 1차 자료를 다룬다.
• Addy Osmani의 다섯 building block도 이름만 인용된다.
• 본문 끝에 lnkd.in 단축 URL 2개(giBBf-fe, gM8ZviyE)가 첨부돼 있으나, 어느 자료를 가리키는지는 본문에 적혀 있지 않다.
• 포스트의 상호작용 지표는 좋아요 158개, 댓글 2개다(수집 시점 2026-06-10).

핵심 용어

관련 페이지

• Loop Engineering (Addy Osmani, 2026-06-07): 본 글이 인용한 다섯 building block의 원출처. 본 글이 이름만 나열한 자리를 요소별 절로 전개하고 persistent state를 여섯 번째 보조 요소로 덧붙인다.
• Recursive Language Models (RLM): 본 글이 이론적 기반으로 지목한 RLM 논문. REPL 컨텍스트 변수 모델과 재귀 호출 구조를 1차 자료로 다루므로, 본 글이 요약만 한 대목의 근거를 여기서 확인할 수 있다.
• 더 이상 Claude를 프롬프팅하지 않습니다 >> 하지만 프롬프트는 여전히 중요합니다: 최적화 대상이 프롬프트에서 컨텍스트, harness, loop로 옮겨온 흐름을 한 장에 담은 한국어 LinkedIn 카드 포스트. 같은 형식과 같은 주제를 다룬 짝이다.
• Harness Engineering (Team Attention, 2026): harness engineering을 여섯 단계 실행 절차로 정리한 한국어 슬라이드 자료. 본 글이 loop의 이론적 근거를 다룬다면 이 자료는 실행 순서를 다룬다.
• Beyond the Prompt: Claude Code (Arpan Patel, 2026-05-26): Boris Cherny의 자기 검증 원칙을 Claude Code 운영 절차로 풀어낸 실전 가이드. 본 글이 인용만 한 Boris의 발언이 어떤 설정으로 이어지는지 보여준다.
• The Art of Loop Engineering (Sydney Runkle, 2026-06-16): loop를 agent, verification, event-driven, hill climbing 네 겹으로 쌓은 LangChain 측의 정리. 본 글의 단일 loop 서술보다 층위 구분이 세밀하다.