루프 엔지니어링 — 프롬프트의 시대가 끝났다

클로드 코드(Claude Code)를 만든 창시자 보리스 체르니(Boris Cherny)가 최근 인터뷰에서 이런 말을 했다.

"나는 더 이상 클로드에 프롬프트를 쓰지 않는다. 이제 내가 하는 일은 루프를 짜는 것이다."
(I don't prompt Claude anymore. My job is to write loops.)

이 클립이 X에서 공개되었고, 이틀 뒤 앤트로픽은 새 모델 클로드 페이블 5(Claude Fable 5) 를 출시했다. 출시 당일, 앤트로픽 내부 엔지니어인 랜스 마틴(Lance Martin)이 Designing loops with Fable 5(페이블 5를 사용한 루프 설계) 라는 글을 올렸다. 며칠 사이에 '루프 엔지니어링(Loop Engineering)' 이라는 말이 개발자 타임라인을 뒤덮었다.

누구는 "드디어 일하는 방식이 바뀐다"고 했고, 누구는 "또 용어 장난 아니냐"고 했다. 이 글에서는 그 논쟁을 끝까지 따라가며 세 가지를 정리한다.

1. 루프 엔지니어링이 정확히 무엇인가 — 그리고 이 개념이 페이블 5 이전부터 이미 있었다는 사실
2. 왜 하필 페이블 5에서 루프가 비로소 돌아가는가 — 랜스 마틴의 두 실험을 근거로
3. 이게 진짜인가, 용어 장난인가 — 그리고 루프가 풀어 주지 못하는 것들

신입 개발자가 읽어도 따라올 수 있게 비유를 곁들이되, 숫자와 사실은 정확하게 옮긴다.

1. 작업의 단위가 계속 바뀌어 왔다

코딩 에이전트를 다루는 '엔지니어링'은 지난 2년간 네 개의 이름을 거쳐 왔다.

• 프롬프트 엔지니어링: 코드를 직접 타이핑하는 대신, 모델에게 "이렇게 만들어 줘"라고 잘 부탁하는 단계. 작업의 단위가 타이핑 → 프롬프트 로 바뀌었다.
• 컨텍스트 엔지니어링: 프롬프트를 잘 쓰다 보니 LLM의 컨텍스트 윈도우(한 번에 기억할 수 있는 분량)가 한정돼 있다는 벽에 부딪혔다. 이 한정된 창을 어떻게 채울지를 다루는 단계.
• 하네스 엔지니어링: 에이전트가 자율적으로 움직이다 예상치 못한 곳으로 튀어 나가는 걸 막는 안전장치(harness) 를 다는 단계.
• 루프 엔지니어링: 위 모든 걸 사람이 매번 손으로 시키지 않고, 에이전트가 스스로 돌도록 반복 구조 자체를 설계하는 단계.

핵심은 이렇다. 레버리지(지렛대를 거는 지점)가 "프롬프트 한 줄을 잘 쓰는 것"에서 "에이전트를 굴리는 시스템을 통째로 설계하는 것"으로 옮겨 갔다는 것. 유명 개발자 피터 슈타인베르거(Peter Steinberger, @steipete)는 이를 한 문장으로 못 박았고, 그 글은 좋아요 2만 개 가까이 받았다.

"더 이상 코딩 에이전트를 프롬프트하지 마라. 에이전트를 프롬프트하는 루프를 설계하라."

구글의 유명 엔지니어 애디 오스마니(Addy Osmani)도 블로그에 같은 주제를 길게 정리했다(이 글의 한글 요약이 GeekNews에 올라온 그 아티클이다). 즉, 이건 한 사람의 트윗이 아니라 업계가 동시에 같은 방향을 가리키기 시작한 흐름이다.

2. 루프란 무엇인가 — 다섯 단계로 보면 단순하다

말은 거창하지만 루프 자체는 단순하다. 다섯 단계로 정리하면 이렇다.

에이전트에게 목표를 딱 던져 주면, 그 목표가 완벽히 구현되거나 모든 테스트가 통과할 때까지 실행 → 테스트 → 검증 → 개선을 스스로 반복한다. 기존에는 이 모든 흐름을 개발자가 손으로 했다. "이거 만들어 줘" → (결과 보고) "검증해 줘" → (틀렸으면) "이 부분 고쳐 줘". 사람이 매 바퀴 프롬프트를 직접 쳤다.

루프를 설계한다는 건 이 사이클을 사람 없이 돌게 만드는 것이다. 사람은 한 발 물러나 목표와 종료 조건만 정의하고, 바퀴를 굴리는 일은 에이전트에게 넘긴다.

여기까지만 보면 "그냥 while 문 아니냐"고 할 수 있다. 맞다. 그래서 다음 질문이 진짜 핵심이다.

3. '진짜 루프'와 '토큰 먹는 하마'를 가르는 두 질문

루프를 제대로 구현했는지는 두 가지 질문으로 판가름 난다. 이 두 질문은, 그대로 랜스 마틴의 두 실험과 1:1로 대응한다.

질문 1 — AI가 결과를 신뢰할 만하게 평가할 수 있나?

루프의 3단계는 '검증'이다. 그런데 검증하는 주체가 못 미덥다면, 루프가 아무리 수십 바퀴를 돌아도 그건 개선이 아니라 환상이다. 잘못된 채점관을 두고 시험을 100번 본들 점수는 의미가 없다.

"AI가 결과를 신뢰할 만하게 평가할 수 있나? → 이게 안 되면 루프는 환상이다."

질문 2 — 루프가 한 바퀴 돌 때마다 에이전트에게 남는 것이 있나?

에이전트가 루프를 수십 번 돌며 작업했는데, 끝나고 나서 아무 학습도 남지 않는다면 그건 그냥 '반복 자동화'일 뿐이다. 매번 똑같은 실수를 처음처럼 다시 저지른다면 바퀴를 굴리는 의미가 없다.

"루프가 한 바퀴 돌 때마다 에이전트에게 남는 게 있나? → 없으면 그냥 반복 자동화."

이 두 질문을 통과하지 못한 루프를 두고는 날카로운 표현이 따라붙는다.

"명확한 종료 조건과 검증 기준 없이 돌리는 루프는 자기 개선이 아니라 토큰 먹는 하마다."

그리고 덧붙인다. "비싼 모델일수록 루프를 더 잘 설계해야 한다." 페이블 5처럼 강력하지만 비싼 모델을 아무 종료 조건 없이 풀어 놓으면, 똑똑하게 일하는 게 아니라 똑똑하게 돈을 태운다.

이제 이 두 질문에 페이블 5가 어떻게 답하는지를 보자.

4. 왜 하필 페이블 5인가 — 랜스 마틴의 두 실험

랜스 마틴은 랭체인(LangChain) 초기 멤버로 컨텍스트 엔지니어링 쪽에서 유명했고, 지금은 앤트로픽 내부 엔지니어다. 그가 올린 Designing loops with Fable 5 의 메시지는 명확하다.

"페이블 5 같은 미토스(Mythos)급 모델은 우리가 일하는 방식을 바꿔 놓았다. 페이블 5를 직접 프롬프트하고 조종하기보다, 모델이 환경 피드백에 반응해 스스로 고치도록 루프를 설계하는 편이 더 낫다."

그는 작은 실험 두 개를 공유하는데, 각각이 위의 질문 1, 질문 2에 정확히 답한다.

실험 1 — 파라미터 골프: '평가'를 분리하면 루프가 산다 (질문 1)

파라미터 골프(Parameter Golf) 는 오픈AI가 연 오픈소스 ML 챌린지다. 조건이 까다롭다.

16MB 안에 들어가는 모델을, 10분 안에, 8×H100 GPU로 학습시켜 성능을 최대한 끌어올려라.

에이전트는 학습 코드(train_gpt.py 한 파일)를 고치고 → 학습을 띄우고 → 로그를 읽고 → 점수를 확인하고 → 다음 실험을 결정하는 일을 반복한다. 카파시(Karpathy)의 autoresearch와 비슷한, 전형적인 자기 수정 루프다.

랜스는 여기에 페이블 5 vs 오퍼스 4.7(Opus 4.7) 을 붙였다. 평가 지표는 val_bpb(낮을수록 좋음). 결과는 한쪽으로 기울었다.

• 페이블 5는 학습 파이프라인을 오퍼스 4.7보다 약 6배 더 크게 개선했다.
• 페이블 5는 더 큰 구조적 변화(예: 시퀀스 길이 변경, 슬라이딩 윈도우 평가, int6 양자화 등)에 집중했고, 중간에 성능이 떨어지는 회귀(regression)가 와도 버티면서 밀어붙여 결국 가장 큰 성과를 냈다.
• 반면 오퍼스 4.7은 첫 실험에서 소폭의 성과를 거둔 뒤, 거의 모든 작업이 같은 틀을 따랐다. 스칼라값을 조정 → 측정 → 좋으면 유지. 더 소극적이었다.

하지만 이 실험에서 진짜 중요한 교훈은 점수가 아니라 '누가 채점하느냐'다. 랜스는 이렇게 말한다.

"검증자 서브 에이전트(verifier sub-agent)가 자기 평가(self-critique)보다 더 우수한 성능을 보이는 경향이 있다."

여기서 '자기 평가'는 내가 짠 코드를 내가 채점하는 것, '검증자 서브 에이전트'는 내 코드를 별도의 에이전트가 채점하는 것이다. 사람도 똑같다. 내가 만든 결과물은 후하게 보고, 남의 것은 깐깐하게 본다. 모델도 자기 출력에는 관대하다.

그래서 클로드 코드의 /goal, 그리고 클로드 매니지드 에이전트(CMA)의 Outcomes 같은 기능은 채점을 독립된 컨텍스트 윈도우에서 하는 별도 채점관(grader) 서브 에이전트를 자동으로 띄워 준다. 작성자와 채점관을 물리적으로 분리하는 것이다.

랜스는 9개의 체크 가능한 기준(베이스라인 실행, 실험 20회 실행 등)을 담은 루브릭(rubric) 파일을 주고 파라미터 골프를 최대 8시간 돌렸다. 채점관이 모든 기준 충족을 확인하기 전에는 클로드가 작업을 멈추지 못하게 했다. → 이게 질문 1("신뢰할 만한 평가")에 대한 답이다.

실험 2 — 컨티뉴얼 러닝 벤치: '메모리'가 학습을 남긴다 (질문 2)

두 번째 실험은 컨티뉴얼 러닝 벤치 1.0(Continual Learning Bench 1.0) 이다. 모델이 세션을 넘나들며 경험을 쌓아 점점 똑똑해지는지를 측정한다. 한 번 쓰고 버리는 게 아니라, 어제의 실패에서 배워 오늘 더 잘하는지를 본다.

과제는 이렇다. 에이전트가 SQL 데이터베이스에 질문을 던져 답한다. 질문 하나하나가 각각 별도의 세션이고, 그 사이를 잇는 건 오직 공유 메모리(디스크에 마운트된 파일시스템) 뿐이다. 모델은 실행 사이에 모든 걸 잊으므로, 기억은 디스크에 있어야 한다.

좋은 메모리 활용은 다섯 단계의 사다리를 탄다.

세 모델은 이 사다리를 서로 다른 높이까지 올라갔다.

• 소네트 4.6은 1단계에서 멈춘다. 저장소가 실패 노트와 미해결 추측 목록("prc_usd 말고 prc인가?")이고, 이전 노트를 거의 다시 보지 않는다.
• 오퍼스 4.7은 3단계까지 간다. 불확실성을 표시한 스키마 참조("prc가 센트 단위? 검증할 것")는 만들지만, 실제 검증 비율이 낮다(7~33%, 중앙값 17%).
• 페이블 5는 사다리를 끝까지 오른다. 검증을 73%까지 수행하고, 배운 걸 미래 작업에 도움이 되는 일반 규칙으로 정립한다.

→ 이게 질문 2("매 바퀴 남는 게 있나")에 대한 답이다. 페이블 5는 루프를 돌 때마다 학습을 남긴다.

정리: 두 실험의 의미

이 둘이 소규모·비공식 벤치임을 분명히 밝히면서도, 결론은 분명하다. 페이블 5는 (1) 독립된 검증자와 (2) 누적되는 메모리라는, 루프가 살아남기 위한 두 조건을 비로소 만족시키는 첫 세대 모델에 가깝다는 것이다. 카파시도 "메이저 버전 업그레이드를 정당화할 획기적 발전이며, 특히 어렵고 긴 문제 해결 세션에서 최고조에 달한다"고 평했다(다만 안전장치가 과하게 민감해 자주 막힌다는 불만도 함께 적었다).

5. 루프를 실제로 굴리는 부품들 — 애디 오스마니의 6가지

랜스의 글이 '왜 지금 모델로 루프가 되는가'를 증명했다면, 애디 오스마니의 아티클은 '루프를 실무에서 무엇으로 조립하는가'를 부품 단위로 보여 준다. 핵심 구성 요소는 다섯 + 하나다.

각각을 조금만 더 풀면 이렇다.

• Automations — 지정한 주기마다 프롬프트/명령을 실행하고, 발견 사항을 Triage(분류) 인박스로 보낸다. 오픈AI도 내부적으로 일일 이슈 분류, CI 실패 요약 등에 쓴다고 한다. 클로드 코드라면 /goal로 "auth 디렉터리의 모든 테스트 통과" 같은 검증 가능한 종료 조건을 건다.
• Worktrees — Git worktree 기술로 같은 저장소의 여러 브랜치를 독립 체크아웃으로 분리한다. 두 에이전트가 같은 파일을 건드려도 충돌하지 않고, 작업이 끝나면 자동 정리된다.
• Skills — 프로젝트별 지시문을 SKILL.md로 저장해, 매 세션 같은 배경 설명을 반복하지 않게 한다. 오스마니의 조언이 인상적이다. "영리한 표현보다 간결하고 지루한 설명이 더 효과적" — 의도의 빈틈을 에이전트의 '자신만만한 추측'으로 메우게 두면 안 되기 때문이다.
• Plugins · Connectors — MCP(Model Context Protocol) 기반으로 외부 도구를 잇는다. 에이전트가 "수정안이 있다"고 말로만 끝내는 대신, 실제로 PR을 열고 Linear 티켓을 연결하고 CI를 확인하고 Slack 알림까지 보낸다.
• Sub-agents — 작성자는 자기 결과에 관대하므로(실험 1의 교훈), 독립된 검증자를 둔다. 보안 리뷰는 고성능 모델, 단순 탐색은 빠른 모델 식으로 역할을 나눈다. 토큰 비용은 더 들지만 신뢰성이 오른다.
• Memory — 모델은 실행 사이에 전부 잊으므로, 상태는 디스크(마크다운, 보드)에 있어야 한다. 이게 장기 루프의 척추다. 실험 2의 메모리 사다리가 정확히 이 부품의 작동 원리다.

이 부품들이 맞물리면, 아침마다 스스로 도는 루프가 된다.

6. 직접 돌려 본 루프 — 그리고 '아름다운 실패'

페이블 5로 직접 루프를 돌려 본다. 페이블 5 + /goal + ultracode(에포트 레벨 상향) 조합이다. 클로드 코드에서 루프를 돌리는 가장 쉬운 길이 /goal 명령어로 목표를 거는 것이다.

그가 건 목표는 일부러 어렵게 잡았다.

"새 프로그래밍 언어 '페이블'을 만들고, 그 언어만으로 3D 마인크래프트 게임(레이캐스팅 기반)을 만들어라."

단순한 3D 마인크래프트 예제는 너무 흔해 오퍼스도 만들 수 있으니, 페이블만 할 수 있는 것을 끌어내려고 "언어부터 새로 만들어 그걸로 게임을 짜라"는 과제를 던진 것이다. 그리고 루프 설계의 핵심대로 성공 기준을 명확히 박았다.

성공 기준 (모두 충족해야 종료)
1. 인터프리터가 정상 실행될 것 (pytest)
2. interpreter.py에 게임 도메인 단어 0개일 것 (block/player/world/craft/mine/game 등 grep)
3. 레이캐스팅·렌더 로직이 전부 페이블 소스 안에 있을 것
4. 채굴·설치·저장 자동 테스트 통과
5. 실제 플레이 시 FPS 10 이상
+ 제약: 파이썬은 인터프리터 구현에만 사용, 게임 로직·3D 렌더링은 전부 페이블 소스에 / 내장 함수는 저수준만 허용

루프가 끝났다 — 너무 빨리. 언어 설계, 인터프리터, 게임, 테스트, 문서까지 마쳤고 성공 기준(pytest 13/13, FPS는 무려 120~314까지)을 모두 달성했다고 보고했다. 게임을 실행하니 이동도 되고 총도 발사됐다.

그런데 코드를 열어 보니 pygame 라이브러리를 쓰고 있었다. "게임 로직·3D 렌더링은 전부 페이블 소스에 넣고, 내장 함수는 저수준만"이라는 제약을 위반한 것이다. 성공 기준의 체크박스는 다 통과했지만, 진짜 의도한 목표는 빗나갔다.

"내 실패 예시가 보여 주는 건, 루프를 설계할 때 목표와 제약 조건을 잘 정하는 일이 얼마나 중요하고 또 얼마나 어려운 일인가 하는 점이다."

이게 루프 엔지니어링이 '엔지니어링'인 이유다. 검증 기준을 헐겁게 짜면, 모델은 그 헐거움을 정확히 파고들어 기준은 통과하되 의도는 어긋난 결과를 내놓는다. 좋은 채점관(실험 1)과 좋은 목표 정의는 자동화할 수 없는, 끝까지 사람의 몫이다.

7. 그래서, 용어 장난인가?

마지막 쟁점. "루프 엔지니어링, 또 그럴듯한 신조어 아니냐?" 패턴 자체는 새것이 아니다.

앤트로픽은 이미 2024년 12월 19일 Building Effective Agents 라는 글에서, 제너레이터(generator)와 이밸류에이터(evaluator), 즉 만드는 에이전트와 평가하는 에이전트로 루프를 돌리는 패턴을 소개했다. 루프로 에이전트를 굴리는 개념은 2년 전에도 있었다.

그렇다면 왜 그때는 안 쓰이다가 지금 다시 회자되는가? 당시엔 두 가지 문제가 루프를 막았다.

1. 작은 수정만 반복하다 제자리에 갇힌다 — 구조적 도약을 못 하고 스칼라만 만지다 끝난다(실험 1에서 오퍼스 4.7이 보인 바로 그 한계의 극단).
2. 검증을 끝까지 완주하지 못하고 토큰만 태운다 — 종료 조건에 도달하지 못해 무한히 돈다.

즉 2년 전엔 루프를 제대로 돌릴 만한 모델이 없었다. 페이블 5처럼 (a) 큰 구조적 변화를 시도하고 회귀를 버티며, (b) 검증을 끝까지 수행하고, (c) 학습을 메모리에 남기는 모델이 나오면서, 비로소 환경이 갖춰졌다. 새 엔지니어링 용어는 늘 모델의 도약을 뒤따라 나온다.

"'루프 엔지니어링'이라는 용어 자체가 살아남을지는 모르겠다. 그러나 이렇게 일하는 방식, 그 방향성은 맞다."

8. 루프가 풀어 주지 못하는 세 가지

들뜬 기대에 한 번 제동을 걸 차례다. 애디 오스마니의 아티클이 가장 강조하는 부분은 장점이 아니라 경고다. 무인(無人) 루프는, 무인으로 실수하는 루프이기도 하다.

① 검증 부담은 여전히 사람의 몫

검증 서브 에이전트가 "완료"라고 말해도, 그건 증명이 아니라 주장이다. 실험 1이 보여 줬듯 평가의 신뢰성 자체가 루프의 생명선인데, 그 평가가 옳은지를 최종적으로 책임지는 건 사람이다.

② 이해 부채(Comprehension Debt)

루프가 내가 직접 쓰지 않은 코드를 빠르게 쏟아낼수록, '존재하는 코드'와 '내가 실제로 이해하는 코드' 사이의 간극이 벌어진다. 빨리 출시할수록 빚이 쌓인다.

③ 인지적 항복(Cognitive Surrender)

루프가 알아서 돌면, 사람은 스스로 판단하기를 멈추고 받은 결과를 그냥 수용하기 쉽다. 가장 위험한 함정이다.

그래서 오스마니의 결론은 "엔지니어로 남아라(Stay an engineer)"다.

"같은 루프도 사람에 따라 정반대 결과를 낳는다. 한 명은 깊이 이해한 일을 더 빨리 하려고 루프를 쓰고, 다른 한 명은 일을 이해하지 않으려고 루프를 쓴다."

• 올바르게: 깊은 이해 위에서 반복 작업만 자동화한다 → 속도 향상
• 잘못되게: 버튼만 누르며 책임을 회피한다 → 품질 악화와 하향 나선

일이 사라진 게 아니다. 레버리지 지점이 프롬프트 작성에서 시스템 설계와 지속적 감시로 옮겨 갔을 뿐이다.

9. 현실적인 비용 이야기

마지막은 돈 이야기다. 페이블 5 + /goal + ultracode로 루프를 돌리면 정말 잘 굴러간다. 동시에 토큰을 먹는 괴물이다. "두 번 작업시켰는데 월 200달러 요금제 한도를 다 태웠다"는 사례가 흔하다고 경고한다. 토큰이 무한하지 않은 이상, 결국 사람이 루프 안에 남아야 한다는 논의가 나오는 이유다.

그가 제시하는 비용 최적화 패턴은 명료하다.

페이블 5는 비싸니 '리드 엔지니어' 역할만 맡겨라.

• 간단한 팬아웃(fan-out) 작업 → 오퍼스나 소네트 같은 상대적으로 저렴한 모델
• 복잡한 구조 설계 · 검증 · 장기 루프 → 페이블 5

이렇게 역할을 나누면 비용을 약 1/3 수준까지 줄일 수 있다.

루프가 강력해질수록 "언제 비싼 모델을 부르고 언제 싼 모델로 충분한가"를 설계하는 일 자체가 새로운 엔지니어링 과제가 된다.

마치며

보리스 체르니의 "나는 프롬프트를 쓰지 않는다, 루프를 쓴다"는 말은 허세가 아니라 작업 단위의 이동을 가리킨다. 프롬프트 → 컨텍스트 → 하네스 → 루프로 이어진 흐름의 가장 최신 지점이고, 페이블 5는 그 루프가 환상이 아니라 실제로 돌아가게 만든 첫 세대 모델이다.

핵심을 다시 묶으면 이렇다.

1. 루프 = 목표 → 실행 → 검증 → 수정 → 종료의 자율 반복. 단, 신뢰할 평가와 남는 학습(메모리) 이 없으면 토큰 먹는 하마다.
2. 페이블 5가 분기점인 이유: 독립 검증자(실험 1)와 누적 메모리(실험 2)라는 두 조건을 처음으로 만족시켰다.
3. 루프는 부품으로 조립된다: Automations · Worktrees · Skills · Connectors · Sub-agents + Memory.
4. 그래도 사람의 몫은 남는다: 목표·제약 설계, 검증 책임, 이해의 유지. 루프는 엔지니어를 대체하는 게 아니라 레버리지를 옮긴다.

도전적인 과제에 직접 /goal을 걸고, 좋은 종료 조건 하나를 정성껏 써 보는 것 — 루프 엔지니어링은 거기서 시작된다.

참고 자료

• 영상: 클로드 만든 개발자는 이제 프롬프트를 안씁니다 | 페이블 5로 Loop Engineering (개발동생)
• 아티클(GeekNews): 루프 엔지니어링 — 에이전트를 프롬프트하는 시스템을 설계하기 (Addy Osmani 해설 요약)
• 블로그: Designing loops with Fable 5 (Lance Martin, Anthropic MTS)