루프 엔지니어링을 알아보자

루프 엔지니어링을 10분에 설명하는 영상을 봤습니다. 보다가 「아, 내가 만들던 게 이거 절반이었구나」 싶은 대목이 있어서 정리해둡니다.

루프 엔지니어링이란?

영상이 출처로 든 건 구글 엔지니어 애디 오스마니가 2026년 6월에 쓴 글 하나입니다. 정의는 이 문장입니다.

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

루프 엔지니어링은 에이전트에게 프롬프트를 넣는 그 사람 자리에서 자기 자신을 치우는 일이다. 대신 그 일을 하는 시스템을 설계한다.

한 겹 더 들어가면 앤트로픽이 나옵니다. 오스마니 글이 인용한 발단은 Claude Code를 이끄는 보리스 체르니의 말입니다. 「나는 더 이상 클로드에 프롬프트하지 않는다. 루프를 돌린다. 내 일은 루프를 쓰는 것이다」. 다만 이 발언이 어느 자리에서 나온 것인지는 확인하지 못했습니다. 6월 초에 클립이 퍼졌고 옮기는 사람마다 문장이 조금씩 달라서, 따옴표를 붙여 옮기지는 않겠습니다.

한 사슬 안에서 말이 계속 바뀝니다. 체르니는 자기 작업 방식을 말했고, 오스마니는 그걸 엔지니어링 실천으로 세웠고, 앤트로픽 문서는 제품 기능으로 내렸고, 영상은 회사에서 일 맡기는 이야기로 옮겼습니다. 그렇다면 우리는 루프 엔지니어링을 우리 작업에 적용할 수 있지 않을까요? 글 후반부에 다루겠습니다.

이너 루프와 아우터 루프

영상에서는 이렇게 구분하고 있습니다.

• 이너 루프 — 생각하고 → 도구 쓰고 → 결과 보고 → 다시 생각하고. 이건 이미 만들어져 있습니다. 에이전트 자체가 그거니까요
• 아우터 루프 — 우리가 만드는 것. 정할 게 네 가지뿐입니다

①  언제 시작할지        ②  뭘 시킬지
③  됐는지 누가 판정할지  ④  언제 멈출지

자기가 하던 일을 여기 얹어보면 어느 칸이 비어 있는지가 바로 보입니다.

네 자리를 무엇으로 채우나

여기서 다시 오스마니로 돌아갑니다. 영상이 「네 자리」로 정리한 것을, 원문은 부품 목록으로 내놓습니다. 둘은 다른 이야기가 아니라 같은 것의 설계도와 부품표입니다. 겹쳐 보면 이렇게 됩니다.

부품	무엇	어느 자리를 채우나
자동화	루프를 깨우는 방아쇠. 일정·이벤트로 스스로 돈다	①
스킬	매번 다시 설명하지 않도록 굳혀둔 프로젝트 지식	②
커넥터	바깥 도구에 실제로 손을 대는 능력	②
작업 공간 분리	여러 개를 동시에 돌릴 때 서로 밟지 않게 사본을 나눈다	②
서브 에이전트	만드는 쪽과 검사하는 쪽의 분리	③

④는 부품이 아니라 내가 써 넣는 문장입니다. 뒤에서 따로 봅니다.

오스마니는 여기에 여섯째를 따로 붙입니다. 이게 가장 중요하기 때문입니다.

the model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesn't.

모델은 실행과 실행 사이에 전부 잊는다. 그러니 기억은 문맥이 아니라 디스크에 있어야 한다. 에이전트는 잊어도 저장소는 안 잊는다.

바퀴와 바퀴 사이를 잇는 게 이겁니다. 이게 없으면 매 바퀴가 첫 바퀴입니다.

[Fig. 1 — 네 자리와 부품]닫기 ✕Fig. 1 — 네 자리와 부품

① 언제 도느냐 — 방아쇠

**「자동화가 있어야 루프가 진짜 루프가 된다」**는 게 오스마니의 표현입니다.

Automations are what make a loop an actual loop and not just one run you did once.

자동화야말로 루프를 진짜 루프로 만드는 것이다. 한 번 돌려 본 것이 아니라.

영상은 이걸 「아무리 좋은 매뉴얼을 줘도 출근을 안 하면 아무 일도 안 일어난다」로 옮겼습니다.

앤트로픽 문서는 무엇이 깨우고 무엇이 멈추느냐로 루프를 넷으로 나눠 두었습니다. 분류가 곧 설계 선택지라서 그대로 옮겨둡니다.

종류	무엇이 깨우나	무엇이 멈추나
턴 기반	사용자 프롬프트	다 됐다고 보거나, 문맥이 더 필요할 때
목표 기반	사람이 실시간으로 건다	목표 달성 또는 최대 턴수
시간 기반	지정한 간격	취소하거나 일이 끝날 때
선제	이벤트 또는 일정	각 작업이 목표를 만나면

주의할 게 하나 있습니다. 「안이 틀렸으면 다시 다른 안으로 간다」는 건 방아쇠가 아니라 루프의 본체입니다. 그건 ③·④에 해당하고, ①은 어디까지나 첫 바퀴를 무엇이 굴리느냐입니다. 이 둘을 저는 한동안 헷갈렸습니다.

③ 누가 판정하느냐 — 만드는 쪽과 검사하는 쪽을 가른다

부품 다섯 중 오스마니가 구조적으로 가장 쓸모 있다고 한 게 이 자리입니다.

The most useful structural thing in a loop, by far, is splitting the one who writes from the one who checks.

루프에서 구조적으로 단연 가장 쓸모 있는 것은, 쓰는 쪽과 검사하는 쪽을 가르는 것이다.

The loop runs while you are not watching, so a verifier you actually trust is the only reason you can walk away.

루프는 내가 안 보는 동안 돈다. 그러니 자리를 뜰 수 있는 유일한 근거는 내가 실제로 믿는 검사자다.

지시문을 다르게 주고, 아예 다른 모델을 쓰는 것도 방법이랍니다. 다만 서브 에이전트는 토큰을 더 태우니 두 번째 의견이 값어치 있는 자리에만 쓰라고 덧붙입니다.

④ 언제 멈추느냐 — 정지 조건

영상의 예시 대비가 선명합니다.

「좋은 보고서가 될 때까지」	안 됩니다
「필수 항목 5개가 모두 채워지고, 숫자 출처가 전부 링크될 때까지」	됩니다

그리고 안전장치는 겹으로 두랍니다. 검증 통과(정상 종료) → 최대 반복 횟수 → 시간·비용 한도 → 진전 없으면 중단. 안쪽에서 못 멈추면 바깥 겹이 잡게요. 루프가 계속 돌면 그게 곧 토큰 비용이니까요.

우리 일로 옮겨보면

최근 OA 대응검토 작업에서, 대응 방향을 제가 정해주는 대신 출원인 측 · 심사관 측 · 판정 셋을 서브 에이전트로 나눠 돌려본 적이 있습니다. 안을 내면 반박하고, 그걸 보고 표결하고, 더 나은 안이 안 나오면 멈추는 식으로요.

두 사건을 테스트해봤는데 모두 실패했습니다.

첫 번째 사건은, 심사관 에이전트가 출원인 에이전트보다 강하게 반박하는 경향이 있는 데다 판정 에이전트가 등록 판정을 내는 상황을 정지 조건으로 삼다 보니, 독립항에서 다투지 않고 등록 가능한 청구항을 병합하는 방안만 결과로 가져왔습니다.

두 번째 사건은 등록 가능한 특징을 찾는 것 자체가 어려운 건이었습니다. 결과가 나오는 데 2시간이 걸렸는데, 독립항에 부가하라고 제안한 특징은 인용문헌에는 없지만 공지의 기술이었습니다.

제가 했던 작업을 영상에서 제안한 네 자리에 얹어보면, 빈 칸과 잘못 채운 칸이 보입니다.

• ① 이 비어 있었습니다. 제가 앉아서 「돌려」라고 해야 도는 거였으니, 루프가 아니라 파이프라인이었습니다. 이건 몇 달째 고민 중인데 좋은 생각이 안 떠오릅니다
• ② 가 잘못 채워져 있었습니다. 출원인 에이전트에게는 제 경험상 현실적인 방안을 내라고 시켰는데, 심사관 에이전트에게는 「끝까지 반박해라」라고 시켰습니다. 지시의 세기가 한쪽으로 기울었고, 그것이 두 에이전트의 균형을 깨뜨렸습니다
• ③ 도 잘못 채워져 있었습니다. 검사자를 뒀는데 문헌 안에서만 보게 해뒀습니다. 「그 기술분야에서 통상의 지식을 가진 사람」이 아니었던 거죠
• ④ 도 잘못 채워져 있었습니다. 등록 판정을 정지 조건으로 잡았습니다. 독립항에서 다투는 안은 등록 판정을 받을 일이 거의 없으니 구조적으로 살아남지 못합니다. 정지 조건이 답의 종류를 미리 정해버린 것입니다 — 앞에서 본 「좋은 보고서가 될 때까지」와 같은 종류의 실수입니다

②와 ③은 사실 붙어 있습니다. 심사관 에이전트도 검사자니까요. 만드는 쪽과 검사하는 쪽을 가르기는 했는데, 검사자 쪽 눈금을 안 맞춘 것이 두 칸에 걸쳐 나타난 셈입니다.

남는 생각

두 번째 사건에서 나온 그 답은, 저는 보자마자 아니라고 봤습니다. 공지의 기술을 독립항에 갖다 붙인 것이었으니까요. 그래서 구글 이미지 검색 결과를 붙여서 「이건 시중에 흔한 물건이다」라고 알려줬습니다.

문제는 그 판단이 루프 안에 없었다는 것입니다. 제가 그 자리에 있어서 걸린 것이지, 루프가 스스로 잡은 게 아닙니다. 오스마니의 경고가 정확히 그 자리를 가리킵니다.

A loop running unattended is also a loop making mistakes unattended.

지켜보지 않는 채 도는 루프는, 지켜보지 않는 채 실수하는 루프이기도 하다.

When the loop runs itself its very tempting to stop having an opinion and just take whatever it gives back.

루프가 알아서 돌면, 의견 갖기를 그만두고 내주는 대로 받고 싶은 유혹이 아주 강해진다.

글의 마지막 절 제목이 「Build the Loop. Stay the Engineer.」 (루프를 만들되, 엔지니어로 남아라)인데, 읽고 나니 왜 그 순서인지 알겠습니다.

That's what makes loop design harder than prompt engineering, not easier.

그래서 루프 설계는 프롬프트 엔지니어링보다 쉬운 게 아니라 어렵다.