루프 엔지니어링이란 — 지시하는 사람을 시스템으로 갈아 끼운다

AI에게 매번 세세하게 지시하는 걸 그만두고 "쓸수록 똑똑해지는 루프" 자체를 설계한다 — 요즘 화제인 루프 엔지니어링을 정의부터 단발 프롬프트와의 차이, 5가지 구성 요소 + 기억, Claude Code / Codex에서 조립하는 법, 안쪽 루프와 바깥쪽 루프까지 처음부터 체계적으로 풀어 보는 코스의 첫 글이다. 이 글에서는 루프 엔지니어링이라는 말이 어디서 나왔고 무엇을 가리키는지, 그리고 사람이 평가하는 자리가 어떻게 바뀌는지를 다룬다. 하네스 엔지니어링 기초를 읽었다면 그 위에 한 층을 더 얹는 얘기로 읽으면 되고, 다음 글 그냥 자동화와의 차이, 그리고 하네스의 한 층 위에서 기존 접근과의 관계를 본다.

자, 시작해 보자 ── 루프 엔지니어링이 대체 무슨 얘기냐

AI의 최전선이 같은 방향을 가리키기 시작했다

AI 코딩 최전선에 있는 사람들이 얼마 전부터 비슷한 표현으로 같은 방향을 가리키기 시작했다.

Anthropic에서 Claude Code를 만든 사람이자 책임자(creator / Head of Claude Code)인 보리스 체르니(Boris Cherny)는 팟캐스트 Acquired의 라이브 이벤트 Acquired Unplugged(2026년 6월) 인터뷰에서 이렇게 말했다고 전해진다.

나는 이제 Claude에게 지시를 주지 않는다. Claude에게 지시를 주고 무엇을 해야 할지 판단하는 루프가 돌아가고 있다. 내 일은 루프를 쓰는 것이다.

(원문 "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." — Acquired Unplugged(2026년 6월, WorkOS 주최). 인용문은 X를 통해 퍼진 축약판이고, 확정된 축어 트랜스크립트는 아니다.)

그가 말하는 바는 이렇다. 프롬프트를 한 줄씩 손으로 쓰는 작업에서, 그 작업을 대신해 주는 구조를 만드는 작업으로 자기 자리를 옮겼다.

거의 같은 시기, 개발자 피터 슈타인베르거(Peter Steinberger)도 X(2026년 6월 7일)에서 다른 각도로 같은 얘기를 했다.

매달 하는 얘기지만, 코딩 에이전트에게 지시를 주는 건 이제 그만둬야 한다. 에이전트에게 지시를 주는 루프를 설계해야 한다.

(원문: "Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.")

둘은 다른 사람이고 다른 자리에서 나온 별개의 발언이다. 그런데도 가리키는 방향은 정확히 겹친다. 이 공통된 발상에 루프 엔지니어링(Loop Engineering)이라는 이름을 붙이고 구성 요소까지 체계적으로 정리한 것이 애디 오스마니(Addy Osmani)가 2026년 6월 8일에 공개한 글 "Loop Engineering"이다. 이 가이드는 그 정리를 주된 토대로 삼는다.

이 코스를 다 읽으면 뭘 알게 되나

끝까지 읽으면 다음을 자기 말로 설명할 수 있게 된다.

• 루프 엔지니어링의 정의
• 사람의 평가 관점이 어떻게 바뀌는지(개별 출력을 하나하나 보는 게 아니라 루프 자체를 설계하고 평가하는 쪽으로 옮겨간다)
• 지금까지의 접근(프롬프트 → 컨텍스트 → 하네스)과의 관계 및 차이점(루프는 하네스의 '한 층 위'에 있다)
• 언제 써야 하는지(반복을 전제로 한 작업에 잘 듣고 단발 작업에는 과해지기 쉽다)
• 루프를 성립시키는 구성 요소(자동화·워크트리·스킬·커넥터·서브에이전트, 그리고 기억)
• 그걸 Claude Code나 Codex app에서 어떻게 조립하는지
• 안쪽 루프와 바깥쪽 루프라는 사고방식(쓸수록 똑똑해지는 구조)

AI 에이전트 지식은 지나치게 전제하지 않는다. 필요한 용어는 그때그때 풀어서 설명한다. 그럼 먼저 '루프 엔지니어링이란 무엇인가'부터 시작하자.

루프 엔지니어링이 뭔데? 지시하는 사람을 시스템으로 갈아 끼우는 것

한마디로 하면 '지시하는 역할'을 떼어내는 것

루프 엔지니어링은 한마디로 '에이전트에게 지시를 주는 사람'이라는 역할을 나 자신에게서 떼어내고 그 역할을 대신 수행하는 시스템(루프)을 설계하는 작업이다. 새로운 말이지만 어려운 개념은 아니다. 이게 뭘 가리키고 지금까지의 사용법과 뭐가 다른지 차례로 보자.

지시하는 사람을 지시하는 시스템으로 갈아 끼운다

출발점은 역할의 교체다. 오스마니의 원문은 이렇게 적는다.

"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."

(루프 엔지니어링이란, 에이전트에게 지시를 주는 사람으로서의 자기 자신을 대체하는 것. 대신 그 일을 하는 시스템을 당신이 설계한다.)

그럼 여기서 말하는 루프는 뭘까. 오스마니는 이렇게 설명한다.

"A loop ... a recursive goal where you define a purpose and the AI iterates until complete."

(루프란…… 목적(purpose)을 정의하고, AI가 완료될 때까지 반복하는 재귀적 목표로 볼 수 있다.)

즉 루프란 목적을 한 번 정의해 두면 AI가 그 달성까지 스스로 반복해서 움직이는 처리다. 사람이 '다음은 이렇게', '그다음은 이렇게' 하고 한 단계씩 지시하는 대신 '이게 완료된 모습이다'라는 목적만 준다. 나머지는 에이전트가 현재 상태를 보고 실행하고 결과를 확인하고, 아직 모자라면 다시 실행한다. 완료 조건에 닿을 때까지 이걸 돌린다.

가까운 비유를 들면 요리 레시피를 한 줄씩 구두로 지시하는 걸 그만두고 '이 한 접시를 완성한다'는 목표와 간을 보는 기준(완료 조건)만 넘기는 감각에 가깝다. 절차 자체는 만드는 쪽이 조립한다.

한 바퀴의 모양 ── 발견·실행·검증·기억·재실행

이 변화는 작업의 모양에 주목하면 더 뚜렷해진다. 지금까지의 사용법은 프롬프트를 한 번 던지고 결과를 받으면 끝이었다. 루프에서는 그 한 바퀴가 대체로 다음 단계를 밟는다. 게다가 자동으로 다음 바퀴로 들어간다.

1. 발견(discover) — 지금 무슨 일이 벌어지고 있는지, 무엇을 풀어야 하는지 찾아낸다
2. 실행(act) — 찾아낸 과제를 실행에 옮긴다
3. 검증(verify) — 그 실행이 정말 통했는지 확인한다
4. 기억(remember) — 알아낸 것과 진행 상황을 남긴다
5. 재실행(repeat) — 아직 완료가 아니면 다시 1로 돌아간다

단발 프롬프트와의 결정적 차이는 검증과 기억이 내장돼 있다는 점, 그리고 자동으로 다음 바퀴로 들어간다는 점이다. 한 번의 응답으로 끝나지 않고 완료 조건을 만족할 때까지 스스로 굴러간다. (Claude Code가 한 턴 안에서 도구를 부르고 결과를 읽어 다음 행동을 정하는 기본 사이클은 에이전틱 루프의 동작 원리에 정리돼 있다. 여기서 말하는 루프는 그 사이클을 여러 번 기동하는 한 층 위의 구조다.)

사람의 일은 끝의 모양과 옳음을 확인하는 방법을 정하는 것

이 지점에서 사람의 역할이 바뀐다. 지금까지는 좋은 지시를 입력하는 사람이었다. 루프 엔지니어링에서는 그 역할이 루프를 설계하는 사람이 된다. 지시를 한 줄씩 쓰는 대신 다음 두 가지를 정하는 게 사람의 일이 된다.

• 완료 조건: 어떻게 되면 끝인가(= 언제 루프를 멈출 것인가)
• 검증 역할: 각 바퀴의 결과가 옳은지를 누가(어떤 에이전트가) 어떻게 확인할 것인가

'에이전트에게 지시를 주는 사람'을 자신에게서 떼어내 시스템으로 갈아 끼운다. 파고들면 그 알맹이는 끝의 모양과 옳음을 확인하는 방법을 설계하는 일이다.

사람이 평가하는 자리가 바뀐다

평가 대상이 답에서 구조로 옮겨간다

정의를 다시 풀어 쓰는 김에 한 단계만 더 들어가 본다. 사람이 무엇을 평가하는가, 그 변화다.

기존의 프롬프트 중심 사용법에서 사람은 개별 출력을 하나씩 평가했다. '이 답변은 좋다/아니다', '여기를 고쳐라' 하면서 나온 결과물을 일일이 고쳤다.

루프 엔지니어링에서는 사람이 손대는 자리 자체가 움직인다. 개별 출력에서 루프(프로세스) 자체로 옮겨간다. 완료 조건은 적절한가, 검증 역할은 충분히 엄격한가, 기억은 제대로 남는가. 평가 대상이 한 번의 답에서 답을 계속 만들어 내는 구조로 옮겨 간다.

솔직히 밝히자면 여기는 이 가이드의 해석이다

한 가지는 솔직히 밝혀 둔다. '개별 출력이 아니라 프로세스를 평가한다'는 정리는 이 가이드의 해석이다. 오스마니의 원전에서도, 이 가이드가 참조한 2차 정보에서도 이 문장을 그대로 서술한 곳은 찾지 못했다.

다만 원전이 사람의 역할을 완료 조건과 검증 역할의 설계에 둔다는 데서 끌어낸 해석으로 제시한다. 누군가의 주장으로 단정하지는 않는다. 이런 선 긋기를 제대로 하는 것도 루프의 검증 정신에 통한다고 본다.

다음 글: 그냥 자동화와의 차이, 그리고 하네스의 한 층 위