루프 엔지니어링이란? Claude Fable 5가 연 '프롬프트 없는' AI 코딩 시대

여러분, AI 코딩 에이전트를 다루는 방식이 다시 한번 바뀌고 있습니다. Claude Code를 만든 보리스 체르니(Boris Cherny)는 최근 인터뷰에서 자신의 일하는 방식을 이렇게 설명했습니다.

나는 더 이상 Claude에서 프롬프트를 작성하지 않는다. 내 직업은 이제 루프를 작성하는 것이다.

이 발언이 담긴 클립은 X에서 크게 화제가 됐고, 클립이 퍼진 지 이틀 뒤에 Claude Fable 5가 출시됐습니다. 루프 엔지니어링(Loop Engineering)이라는 용어는 지난주부터 이미 X에서 폭발적으로 확산되고 있었는데요. 출시 당일 Anthropic 내부 엔지니어 랜스 마틴(Lance Martin)이 “Fable 5를 사용한 루프 설계”라는 글을 공개하면서, 이미 진행 중이던 논의에 기름을 부었습니다. 누군가는 “드디어 일하는 방식이 바뀐다”고 반기고, 누군가는 “그냥 용어 장난 아니냐”고 냉소하는 상황이죠.

이 글에서 정리하고 싶은 건 세 가지입니다. 첫째, 루프 엔지니어링이 무엇이고 Fable 5 출시 이전부터 이어져 온 논쟁의 맥락은 무엇인지. 둘째, 랜스 마틴의 두 가지 실험을 통해 왜 루프가 Fable 5급 모델에서 비로소 돌아가는지. 셋째, 이 용어가 단순한 유행어인지에 대한 제 판단과 함께, 실제로 루프를 설계하고 비용을 최적화하는 방법까지 다뤄 보겠습니다.

루프 엔지니어링 핵심 요약

• 루프 엔지니어링은 에이전트에게 프롬프트를 치는 행위 자체를 자동화하는 설계 기법이다. 목표 설정 → 실행 → 검증 → 수정 → 종료의 사이클을 사람 개입 없이 돌게 만든다.
• 좋은 루프인지 판단하는 질문은 두 가지다. AI가 결과를 신뢰할 만하게 평가할 수 있는가, 그리고 루프가 한 바퀴 돌 때마다 에이전트에게 남는 것이 있는가.
• 랜스 마틴의 첫 번째 실험인 파라미터 골프에서 Fable 5는 Opus 4.7 대비 약 6배 더 큰 벤치마크 개선을 보였다.
• 두 번째 실험인 컨티뉴얼 러닝 벤치에서 Fable 5는 실패 처리 5단계를 끝까지 완주한 유일한 모델이었다(검증 커버 비율 Fable 5 73% vs Opus 4.7 17%).
• 검증자 서브에이전트가 자기 평가보다 우수하다. 생성자와 검증자를 분리하는 것이 루프 설계의 핵심이다.
• 루프 패턴 자체는 2024년 12월 Anthropic의 “Building Effective Agents” 글에서 이미 소개된 개념이다. 모델이 발전하면서 비로소 실용 가능해졌다.
• 명확한 종료 조건과 검증 기준 없는 루프는 토큰 소각로가 된다. Fable 5에는 리드 엔지니어 역할만 맡기고 팬아웃 작업은 Opus나 Sonnet에 맡기면 비용을 약 1/3 수준까지 줄일 수 있다.

프롬프트에서 루프로: 작업 단위의 진화

폭발적으로 번진 루프 엔지니어링 논쟁

OpenClaw 창시자 피터 스타인버거(Peter Steinberger)는 “여기 당신의 wake-up call이 있다. 더 이상 코딩 에이전트를 프롬프트해서는 안 된다. 에이전트를 프롬프트하는 루프를 설계해야 한다”는 포스팅을 올렸습니다. 이 글은 좋아요를 2만 개 가까이 받으며 큰 주목을 받았죠. 구글의 유명 소프트웨어 엔지니어 애디 오스마니(Addy Osmani)도 자신의 블로그에 루프 엔지니어링을 잘 정리한 글을 올렸습니다. 한쪽에서는 일하는 방식의 전환이라고 반기고, 다른 한쪽에서는 또 하나의 유행어일 뿐이라는 반응으로 갈리는데요. 그래도 AI 에이전트를 활용하는 작업의 단위가 바뀌고 있다는 흐름 자체는 분명해 보입니다.

4단계 진화: 타이핑에서 루프까지

코딩 에이전트 등장 이전에는 개발자가 코드를 직접 타이핑했습니다. 에이전트가 등장하자 코드 대신 프롬프트를 작성하게 됐고, LLM의 컨텍스트 윈도우가 한정돼 있다는 문제를 풀기 위해 컨텍스트 엔지니어링(Context Engineering)이 나왔죠. 이어서 자율적으로 동작하는 에이전트가 예상치 못한 방향으로 튀는 걸 막는 안전장치를 다는 하네스 엔지니어링(Harness Engineering)이 주목받았고, 이제 그다음 단계로 루프 엔지니어링이 등장했습니다.

단계	작업 단위	핵심 질문
프롬프트 엔지니어링	프롬프트 한 줄	어떻게 지시해야 원하는 결과가 나오는가
컨텍스트 엔지니어링	컨텍스트 윈도우	한정된 컨텍스트를 어떻게 관리하는가
하네스 엔지니어링	안전장치·실행 환경	자율 에이전트의 이탈을 어떻게 막는가
루프 엔지니어링	루프 전체	사람 없이 목표 달성까지 돌게 하려면 무엇이 필요한가

루프 엔지니어링이란 무엇인가

루프의 다섯 단계

루프 엔지니어링의 구조 자체는 단순합니다.

1. 목표를 정한다: 에이전트에게 달성해야 할 작업 목표를 부여한다
2. 에이전트가 실행한다: 목표를 향해 작업을 수행한다
3. 에이전트가 검증한다: 결과가 기준을 충족하는지 테스트한다
4. 실패하면 다시 고친다: 검증에서 발견된 문제를 수정한다
5. 통과하면 종료한다: 모든 기준을 만족할 때 루프를 끝낸다

기존에는 이 흐름을 개발자가 직접 수행했죠. “이거 만들어 줘”라고 치고, “만든 거 검증해 줘”라고 치고, 잘못됐으면 “잘못된 거 고쳐 줘”라고 치는 식으로 매 단계 프롬프트를 사람이 입력했습니다. 루프를 설계한다는 건 이 모든 과정을 사람 없이 진행할 수 있게 만드는 일입니다.

제대로 된 루프인지 판단하는 두 가지 질문

첫째, AI가 결과를 신뢰할 만하게 평가할 수 있는가. AI 스스로 결과를 신뢰할 만하게 평가하지 못한다면, 루프가 계속 돌아가는 것처럼 보여도 그건 완전히 환상에 불과합니다. 둘째, 루프가 한 바퀴 돌 때마다 에이전트에게 남는 것이 있는가. 에이전트가 루프를 수십 번 돌며 작업했는데 최종 결과물이나 학습 결과가 남아 있지 않다면, 그건 그냥 반복적인 자동화일 뿐이죠.

루프 엔지니어링이라는 용어 자체는 Fable 5 출시 때 처음 등장한 게 아니라 그 이전부터 있었습니다. 다만 지금까지는 이 두 가지 질문을 현재 모델이나 코딩 에이전트로 해결하기에 한계가 많았죠.

Fable 5에서 루프가 비로소 돌아가는 이유

랜스 마틴은 LangChain 초기 멤버로 컨텍스트 엔지니어링 분야에서 유명했고, 현재는 Anthropic 내부 엔지니어로 활동하고 있습니다. 그의 글은 이렇게 시작합니다.

Claude Fable 5와 같은 미토스(Mythos)급 모델은 Anthropic에서 우리 대부분이 일하는 방식을 바꿔 놓았다. 이 등급의 모델을 최대한 활용하는 데 도움이 될 두 가지 팁을 소개하겠다.

글에서 공유된 두 가지 소규모 실험은 앞서 본 두 가지 질문에 정확히 하나씩 대응합니다.

실험 1: 파라미터 골프, 전략과 평가 능력의 차이

파라미터 골프는 OpenAI가 실제로 연 오픈소스 챌린지로, 16MB 안에 들어가는 모델을 10분 안에 학습시켜야 하는 제약이 매우 엄격한 대회입니다. 랜스 마틴은 여기에 Fable 5와 Opus 4.7을 참여시켰는데요. 핵심 지표(낮을수록 같은 시간, 같은 조건에서 모델링을 더 잘하고 있다는 의미)를 기준으로 Fable 5가 약 6배 더 크게 벤치마크를 개선했습니다.

제가 더 흥미롭게 본 건 수치보다 접근 방식의 차이입니다. Fable 5는 실험을 구조적·스칼라적으로 분류할 때 더 큰 구조적 변화에 중점을 두었고, 중간에 성능이 떨어지는 회귀가 와도 버티면서 계속 밀어붙였습니다. 반면 Opus 4.7은 첫 실험에서 소폭의 성과를 거둔 뒤 거의 모든 작업이 동일한 패턴을 따랐죠. 스칼라 값을 조정하고, 결과를 측정하고, 긍정적이면 그대로 유지하는 소극적인 방식이었습니다.

검증자 서브에이전트가 자기 평가보다 낫다

이 실험에서 또 하나 주목할 결과는 검증자 서브에이전트가 자기 평가보다 더 우수한 성능을 보이는 경향이 확인됐다는 점입니다. 자기 평가는 내가 짠 코드를 내가 평가하는 거고, 검증자 서브에이전트는 내가 짠 코드를 별도의 서브에이전트가 평가하는 구조죠. 사람도 자기가 만든 작업물에는 평가가 후하고 남의 작업물은 깐깐하게 보는 경향이 있잖아요. 코딩 에이전트도 마찬가지라서, 생성자와 검증자를 분리할 때 더 신뢰할 만한 평가가 나옵니다. 루프를 설계할 때 검증자를 별도 에이전트로 두는 게 핵심인 이유입니다.

실험 2: 컨티뉴얼 러닝 벤치, 실패에서 배우는 능력

두 번째 실험은 모델이 세션을 오가며 학습하는지, 즉 한 번 쓰고 버리는 게 아니라 경험을 쌓으며 더 똑똑해질 수 있는지를 측정하는 벤치마크입니다. 모델이 실패를 어떻게 다루는지를 다섯 단계 기준으로 평가했습니다.

1. 실패를 기록한다
2. 왜 실패했는지 조사한다
3. 진단을 검증된 사실로 바꾼다
4. 검증 결과를 일반적인 규칙으로 정리한다
5. 다음번에는 규칙을 다시 도출하는 대신 기존 규칙을 참조한다

모델	도달 단계	검증 커버 비율
Sonnet 4.6	1단계에서 멈춤	-
Opus 4.7	3단계까지 도달	17%
Fable 5	5단계 완주	73%

두 실험 모두 공식 벤치마크가 아닌 소규모 실험입니다. 그래도 “루프가 돌 때마다 에이전트에게 남는 것이 있는가”라는 질문에 Fable 5만이 의미 있는 답을 내놓았다는 점에서, 결과가 꽤 흥미롭다고 봅니다.

Fable 5의 성능과 명확한 한계

“메이저 업그레이드를 정당화할 만한 발전”

안드레이 카파시(Andrej Karpathy)는 Fable 5를 이렇게 평가했습니다.

질적으로 봐도 이것은 메이저 버전의 업그레이드를 정당화할 만한 획기적인 발전이다. 특히 매우 어려운 문제에 대한 긴 문제 해결 세션에서 최고조에 달한다.

실제 사례들도 인상적입니다. Three.js만으로 브라우저에서 실행되는 3D 월드를 만들어내고, 우주 시뮬레이션 과제에서는 Opus 4.8 대비 훨씬 많은 객체를 생성해 냈습니다. “주식 시장을 위한 마인크래프트 스타일 롤러코스터를 만들어라”라는 단 한 번의 프롬프트로 게임을 완성했고요. 보잉 747 벤치마크에서 AGI 수준의 작업을 해냈다는 평가나 도시 폭풍 장면 같은 과제의 결과물도 확인할 수 있습니다.

안전장치 민감도와 토큰 비용

다만 한계도 분명합니다. 안전장치가 지나치게 민감하게 설정돼 있어서, 실사용에서 작업이 안전장치에 자주 걸리는 불편이 종종 생깁니다. 저도 직접 써보면서 이것 때문에 막히는 경우가 꽤 있었습니다. 그리고 루프를 돌리면 토큰을 먹는 괴물이 됩니다. Fable 5에서 /goal 명령어와 울트라 코드(ultracode)까지 활용하면 루프는 매우 잘 돌아가지만, 토큰이 무한하지 않다면 결국 사람이 루프 안에 있어야 하는 것 아니냐는 논의가 나오는 이유죠. 그래서 지금 시점에 루프 엔지니어링이 주목받기 시작했다고 봅니다.

분명한 건, 명확한 종료 조건과 검증 기준 없이 돌리는 루프는 자기 교정이 아니라 토큰 소각로라는 점입니다. 비싼 모델일수록 루프를 더 잘 설계해야 합니다.

루프 엔지니어링은 용어 장난인가

2024년부터 존재한 패턴

제가 보기에 루프 패턴 자체는 최근에 나온 게 아닙니다. 2024년 12월 19일 Anthropic이 공개한 “Building Effective Agents” 블로그 글에는 이미 생성자(Generator)와 평가자(Evaluator)로 루프를 돌리는 Evaluator-Optimizer 패턴이 소개돼 있었거든요. 에이전트에게 루프를 돌리게 하는 패턴은 그 외에도 이전부터 존재하던 개념입니다.

그때는 안 되고 지금은 되는 이유

2년 전에도 있던 루프 패턴이 그동안 활용되지 못한 이유는 크게 두 가지입니다. 첫째, 작은 수정만 반복하다가 제자리에 갇히는 경우가 많았습니다. 둘째, 검증 단계를 끝까지 완주하지 못하고 토큰만 태우는 이슈가 잦았죠. 당시 모델로는 루프를 제대로 활용할 수 없는 환경이었던 겁니다.

결국 루프 엔지니어링이라는 용어의 등장 배경은 LLM이 발전하면서 현재 모델에 맞춘 새로운 엔지니어링 패턴이 나오는 흐름으로 이해할 수 있습니다. 예전에는 루프를 돌릴 만한 모델이 없었지만, 이제 Fable 5 같은 모델이 나오면서 루프를 돌릴 수 있는 환경이 갖춰졌습니다. 용어 자체가 살아남을지는 알 수 없지만, 이런 일하는 방식 자체는 가야 할 방향이 맞다고 봅니다.

실습: /goal 명령어로 루프 설계해 보기

과제 설계: 새 프로그래밍 언어로 게임 만들기

Claude Code에서 루프를 돌리는 가장 쉬운 방법은 /goal 명령어를 활용하는 겁니다. Fable 5 모델에 울트라 코드(ultracode)로 에포트 레벨을 높인 뒤, 제가 준 과제는 이거였습니다. “새로운 프로그래밍 언어 Fable을 만들고, 그 언어만으로 3D 마인크래프트 게임을 만들어라.” 단순한 3D 마인크래프트 게임 예제는 이미 매우 흔해서 Opus 모델도 잘 만들 테니까요. Fable 5만이 할 수 있는 어려운 과제를 골라 모델의 성능을 최대로 끌어내려는 의도였습니다.

제약 조건도 함께 걸었습니다. 파이썬은 인터프리터 구현에만 사용할 것, 게임 로직과 3D 렌더링 계산은 전부 Fable 소스에 넣을 것, 인터프리터 내장 함수는 저수준만 허용할 것. 루프 설계에서 중요한 건 성공 기준을 명확히 정해 주는 것입니다. 언제 루프를 종료하고, 언제 테스트하고, 무엇이 실패인지 알려 줘야 루프가 정상적으로 돌아갑니다.

결과와 실패에서 얻은 교훈

루프는 예상보다 훨씬 빨리 완료를 보고했습니다. 언어 설계, 인터프리터, 게임, 테스트, 문서까지 마쳤고, C 스타일 문법의 .fable 확장자 언어와 파이썬 인터프리터를 만들었죠. 인터프리터 정상 실행, 레이캐스팅 로직의 Fable 소스 포함, 채굴·설치·저장 자동 테스트 통과, FPS 10 이상 등 성공 기준을 달성했다고 보고했고, 실제로 게임을 실행하면 이동과 발사가 동작했습니다.

그런데 인터프리터 코드를 확인해 보니 Pygame 라이브러리를 사용하고 있었습니다. 저수준 내장 함수만 허용한다는 제약을 명시했는데도 요구 사항과 다른 구현이 나온 거죠. 결과적으로 원래 의도한 목표는 달성하지 못했습니다. 이 실패 사례가 보여 주는 건 분명합니다. 루프 설계에서 목표와 제약 조건을 잘 정의하는 일은 생각보다 만만치 않다는 것, 그리고 바로 그렇기 때문에 루프 설계가 개발자의 엔지니어링 패턴 중 하나로 자리 잡아 가고 있다는 겁니다.

루프 비용 최적화 전략

Fable 5는 매우 비쌉니다. 모든 작업을 Fable 5에 맡겨 버리면 두 번의 작업만으로 200달러 구독 요금제의 한도를 전부 소진했다는 사례가 많을 정도예요. 참고로 Fable 5는 22일까지만 구독 요금제에서 활용할 수 있으니, 그때까지 최대한 써보시는 걸 추천합니다.

비용을 줄이는 가장 효율적인 패턴은 역할 분담입니다.

• Fable 5 = 리드 엔지니어: 복잡한 구조 설계, 검증, 장기 루프만 맡긴다
• Opus / Sonnet = 실행 팀원: 간단한 팬아웃(fan-out) 작업을 맡긴다

팬아웃은 여러 개의 단순 작업을 병렬로 흩뿌려 동시에 처리하게 하는 패턴인데요. 최상위 모델의 판단력이 굳이 필요하지 않은 영역이죠. 이렇게 구성하면 비용을 약 1/3 수준까지 줄일 수 있습니다. 모델 성능이 좋아질수록 루프를 돌릴 때 비용을 최적화하는 구조를 함께 고민해야 하는 시점입니다.

마무리: 에이전트가 프롬프트를 작성하게 하라

결론부터 말하면, Fable 5가 나온 지금은 사람이 직접 프롬프트를 작성하기보다 에이전트가 프롬프트를 작성하게 해야 하는 시점입니다. 자신만의 루프를 구성하려면 다음 순서를 따르면 됩니다. 루프를 구성하고, 에이전트에게 명확한 목표를 전달하고, 스스로 테스트하게 하고, 실패하면 개선 프롬프트를 에이전트가 직접 작성하게 하고, 개선 결과를 검증하고, 다음번에 같은 실패를 반복하지 않도록 메모리에 쌓아 두고, 이 모든 과정을 반복하게 만드는 겁니다.

제가 말하고 싶은 핵심은 두 가지입니다. 생성자와 검증자를 분리해 평가의 신뢰도를 확보할 것, 그리고 명확한 종료 조건과 성공 기준 없이 루프를 돌리지 말 것. 이 두 가지가 갖춰지지 않은 루프는 자기 교정이 아니라 토큰 소각로가 됩니다. 루프 엔지니어링이라는 용어가 살아남든 아니든, 목표를 주면 에이전트가 스스로 만들고 검증하고 고치는 작업 방식은 분명히 가야 할 방향이라고 봅니다.