클로드 만든 개발자는 이제 프롬프트를 안씁니다 | Fable 5로 Loop Engineering
관심사 유튜브 채널 전일 영상 번들로 수집한 YouTube 자료. 채널: 개발동생, 게시: 2026-06-11 22:57 KST.
핵심 메타데이터
- URL: https://www.youtube.com/watch?v=QI1FNnUfiZg
- Video ID:
QI1FNnUfiZg - Channel: 개발동생
- Raw: 2026-06-11-yt-qi1fnnufizg-클로드-만든-개발자는-이제-프롬프트를-안씁니다-fable-5로-loop-engineering
기존 관련 문서 연결
설명
📌 지난 영상 1편: https://youtu.be/P7TyXy9w-NM 클로드 Fable 5 출시와 함께 다시 주목받는 말이 있습니다. 바로 “프롬프트를 잘 쓰는 것”이 아니라, “루프를 설계하는 것”입니다. Claude Code를 만든 개발자의 발언부터, Anthropic 엔지니어 Lance Martin의 Fable 5 실험, 그리고 직접 돌려본 /goal 루프와 비용 논쟁까지 정리했습니다. [타임스탬프] 0:00 C
TRANSCRIPT
여러분 클러드 코드를 만든 창시자죠. 보리스천이가 최근 인터뷰에서 이런 말을 했습니다. 나는 더 이상 클로드에서 프롬프트를 작성하지를 않는다. 내 직업은 이제 루프를 작성하는게 직업이다라고 하는 이런 클립이 이제 한번 X에서 터지게 되었는데요. 어, 그리고 해당 클립이 터지고 나서 이틀 뒤에 클로드 페이블 5가 출시가 되게 됩니다. 어제 관련 영상을 한번 올렸었고요. 어, 그리고 페이블이 출시된 당일에 엔트로픽 내부 엔지니어인 랜스마티이 이런 글을 올렸습니다. 페이블 5를 사용한 루프 설계라고 하는 글을 올리게 됩니다. 그래서 이번 영상에서는 프롬프트 시대가 끝난게 무슨 말인지 그리고 최근에 가장 화두가 되고 있는 루프 엔지니어링이 왜이 페이블이라고 하는 모델이 나오고 나서 더 의미가 있어졌는지에 대해서 말씀을 드려 보도록 하겠습니다. 어 지난주부터 X에서이 루프 엔지니어링이라고 하는 말이 폭발적으로 돌고 있는데요. 누구는 드디어 일하는 방식이 바뀐다라고 하고 또 누구는 그냥 이거 폼은 아니냐 또 용어 장난하냐라고 이런 반응들도 관리게 되고 있는데요. 어 그래서 오늘 어 세 가지를 다뤄 보려고 합니다. 어 첫 번째 루프 엔지니어링이 뭔지에 대해서 다뤄보도록 할 거고요. 어 그리고이 루프 엔지니어링이라고 하는 논쟁이이 페이블 5가 출시되기 이전부터 이미 이어지고 있었던 부분도 같이 보도록 하겠습니다. 어 그리고 이제 두 번째는 엔트로픽 엔지니어 랜스 마틴이 올린 글에서 왜 루프가이 페이블 5 모델에서 비로소 돌아갈 수가 있는지에 대해서도 보도록 할 거고요. 그리고 세 번째는 루프 엔지니어링이라고 하는이 용어가 용어 장난인지에 대해서 제 개인적인 의견에 대해서도 여러분들께 전달드리려고 합니다. 오픈클로 창시자인 피터 스타임버그가 이런 포스팅을 올렸습니다. 여기 당신의 월관 알림이 있습니다. 더 이상 코딩 에이전트를 프롬풋트해서는 안 된다는 겁니다. 당신은 에이전트를 프롬프트하는 루프를 설계해야 된다라고 하면서 이렇게 루프 설계에 관한 것을 또 글을 한번 올리게 되고 이것도 이제 거의 좋아요를 2만 개 가까이 받게 되면서 또 많은 주목을 받게 되었습니다. 어, 그리고 에디 오즈만이라고 하는 구글의 굉장히 유명한 소프트웨어 엔지니어가 있는데 어, 오즈마니 블로그에 이런 글이 또 올라오게 되었습니다. 여기서 이제이 루프 엔지니어링에 대해서 굉장히 설명을 잘 해 뒀거든요. 그래서 여러분들께 제 링크 공유 드릴 거니까 한 번씩 읽어 보시면 좋을 것 같고요. 한번 이제 요약을 해 보자면은 우리가 AI 에이전트를 활용해서 작업하는 작업의 단위가 이렇게 변경이 되었다라고 하는 겁니다. 첫 번째는 이제 프롬프트 엔지니어링부터 시작을 했고요. 그리고 나서 나온게 컨텍스트 엔지니어링이라고 하는게 나왔고요. 그리고 그다음은 이렇게 하네스 엔지니어링이라고 하는게 나오게 되었었죠.이 한네스 엔지니어링에 대해서도 제 영상에서 한번 다룬 적이 있었었죠. 어 그런데 또 다른 엔지니어링이 나오게 되어서 요즘에는 이제 루프 엔지니어링이라고 하는게 가장 주목받고 있는 에이전트 코딩 에이전트를 활용할 때 엔지니어링 기법이라고 보시면 될 거 같습니다. 그래서 소프트웨어 개발을 보게 되면은 코딩 에이전트의 등장 이전에는 우리가 타이핑을 하는게 있었고요. 그리고 나서 코딩 에이전트가 등장하게 되면은 코드를 직접 타이핑하지 않고 이렇게 프롬프트를 작성하게 되었고요. 그리고 이제 프롬프트를 잘 작성하다 보니까 LM 모델의이 컨텍스트 윈도우라고 하는게 한정이 되어 있어서이 한정된 컨텍스트 윈도우를 어떻게 하면 잘 관리할 수 있을지를 연구하는 컨텍스트 엔지니어링이라고 하는게 나오고요. 그러다가 얼마 전에는이 코딩 에이전트가 막 자율적으로 동작을 하는데 예상치 못한 곳으로 막 튀어나가거나 하는 이런 것들을 좀 방지하기 위해서 안전 장치를 달아주는이 하네스 엔지니어링이라고 하는 것도 엄청나게 많이 주목을 받게 되었었죠. 그런데 가장 최근 현 상황에서는이 루프 엔지니어링이라고 하는 개념이 새로 나오게 되었습니다. 그죠? 저도 최근까지는 한네스 엔지니어링에 대해서 굉장히 많이 다루게 되었는데 벌써이 다음 용어가 나온 거예요. 이제는 루프 엔지니어링이라고 하는게 뭔지에 대해서 여러분들께 한번 말씀을 드려 보도록 할 건데요. 그래서이 루프 엔지니어링이라고 하는 거는 사실 간단합니다. 첫 번째 목표를 정한다. 목표를 정하는게 첫 번째 단계고요. 그리고 두 번째 에이전트가 실행한다. 이게 두 번째 단계고 세 번째 에이전트가 검증한다.네 네 번째는 실패하면 다시 고친다. 그리고 다섯 번째 통과하면 종료한다라고 하는 이런 흐름을 가지고 에이전트가 어떤 작업에 대한 목표를 딱 주어졌을 때 그 목표가 완벽하게 다 구현이 되거나 모든 테스트가 다 통과할 때까지 계속해서 반복적으로 작업을 진행하고 테스트를 하고 검증하고 개선하고 하는 이런 모든 작업을 반복 실행하는 것을 의미를 합니다. 어 그런데 여기서 이런 모든 흐름을 기존에는 우리 개발자들이 하나씩 하나씩 에이전텍 이거 만들어 줘라고 하고 만든 거 검증해 줘라고 하고 검증된게 만약에 잘못됐으면은 잘못된 거 고쳐 줘라고 하고 이런 식으로 프롬프트를 치는 거를 개발자가 직접 했었는데 어 그런데이 루프를 설계한다라고 하는 것은 어 개발자가 직접 프롬프트를 치는 방식이 아니고요.이 모든 작업을 사람 없이 진행할 수 있게 만들어 주는게 루프 엔지니어링이라고 하는 겁니다. 어, 그렇다면 우리가이 루프를 제대로 구현했다라고 하는 것은 어떻게 판단할 수가 있을까요? 어, 첫 번째는 AI가 결과를 신뢰할 만하게 평가할 수 있나에 대한 질문을 해 봐야 할 것 같습니다. 어, 그런데 만약에 AI 자체가이 결과를 신뢰할 만한 평가를 해 주지 못한다고 하면은 사실이 루프를 통해서 뭔가가 계속 작업이 돌아간다라고 해도 그거는 이제 완전히 환상이라고 볼 수가 있을 것 같고요. 어, 그리고 두 번째는 루프가 한 바퀴 돌 때마다 에이전트에게 남는게 있는지에 대해서도 한번 검토를 해 봐야 될 것 같습니다. 예를 들어서 에이전트가 어떤 루프를 막 수십번을 돌면서 작업을 막 진행을 했는데 에이전트에게 최종적인 결과물이나 어떤 학습 결과가 남아 있지 않다라고 하면은 그거는 그냥 반복적인 자동화라고 우리가 볼 수가 있을 것 같고요. 어 사실이 루프 엔지니어링이라고 하는 용어는 이번 페이블 5가 나왔을 때 등장한 용어가 아니고 그 이전부터 이제 있었던 용어라고 보시면은 되는데 그런데 지금까지는이 두 가지 질문에 대해서 현재 모델이나 아니면 코딩 에이전트에서 이런 것들을 해결하는 데에 한계점이 좀 많이 있었습니다. 그런데 왜 페이블 5가 나온이 시점에이 루프 엔지니어링이라고 하는 용어가 더 많이 확산이 되게 되었냐를 보게 되면은이 페이블 5를 사용한 루프 설계라고 하는 포스팅을 한번 보도록 하겠습니다. 어이 포스팅은 랜스 마틴이라고 하는 엔트로픽 내부 엔지니어가 작성한 글인데요.이 사람은 이제 랭체인 초기 멤버로 컨텍스트 엔지니어링 쪽에서 유명했던 사람이고 지금은 이제 엔트로픽 내부 엔지니어로서 활동을 하고 있습니다. 클로드 페이블 5와 같은 미토스급 모델은 엔트로픽에서 우리 대부분이 일하는 방식을 바꿔 놓았다.이 등급의 모델을 최대한 활용하는데 도움이 될 두 가지 팁을 소개하겠다라고 하면서 글이 시작이 되게 되고요. 그래서이 글에서는 페이블 5를 사용한 두 가지 작은 실험에 대한 결과들이 공유가 되게 되는데요. 아까 전에 제가 말씀드린이 두 가지 질문에 정확하게 하나씩 하나씩 대응이 된다라고 보시면 될 거 같습니다. 어 첫 번째 실험은이 파라미터 골프라고 하는 실험인데요.이 파라미터 골프는 오픈이에서 실제로 연 오픈 소스 챌린지인데요. 조건이 굉장히 빡셉니다. 16MB 안에 들어가는 모델을 10분 안에 학습을 시켜야 되는데 H 열장으로 대결을 시키는 그런 챌린지라고 보시면 될 거 같고요. 그래서 이제 랜스는 여기다가 이제 페이블 5와 오프스 4.7 모델을 참여를 시켰고요. 자, 그래서 여기서 보이는게이 파라미터 골프에다가 어 페이블 5와 오프스 4.7 모델을 돌렸던 벤치마크 표라고 보시면 되고요. 핵심은이 좌측에 있는이 지표를 얼마나 빠르게 낮출 수가 있냐라고 하는게 핵심이라고 보시면 됩니다.이 좌측 지표가 낮으면 낮을수록 같은 시간, 같은 조건에서 언어 모델이이 모델링을 더 잘하고 있다라고 보시면은 되고요. 그래서이 오프스 4.7 모델과 페이블 5 모델을 보게 되면은이 수치장으로 보게 되면 이제 1.16 여기서 이제 2.2보다 조금 더 낮게 위치를 하고 있는데이 페이블 5가 한 여섯 배 정도 더 크게이 벤치마크를 개선했다라고 하고요.이 이 실험에서는 이런 수치적인 부분에 집중하기보다 여기 한번 보시면은이 페이블 5가 실험을 구조적 또는 스칼라적으로 분류할 때 더 큰 구조적 변화의 중점을 두었다라고 이렇게 얘기를 해 주고 있습니다. 그래서이 페이블 5는 이렇게 더 큰 구조적 변화에 중점을 두다 보니까 중간에 성능이 떨어지는 회기가 와도 계속 버티면서 막 밀어 붙였다라고 하고요. 그런데 이제 오프스 4.7 7 모델은 첫 번째 실험은 소폭의 성과를 거두었는데 그 이후에 있는 거의 모든 작업이 동일한 패턴으로 따랐는데 스칼라값을 조정하고 결과를 측정하고 결과가 긍정적이라면은 그대로 유지하는 방식으로이 페이블 5보다는 조금 더 소극적으로 작업을 하는 경향이 있다라고 합니다. 어 그리고이 부분도 우리가 주목을 해 봐야 되는 부분인 거 같은데요. 검증자 서브에트가 자기 평가보다 더 우수한 성능을 보이는 경향이 있다는 것을 확인을 했다라고 하거든요. 여기서 이제 자기 평가라고 하는 것은 내가 짠 코드를 내가 평가하게 했다라고 하는 거고이 검증자 서브 에이전트라고 하는 것은 내가 짠 코드를 내가 평가하지 않고 다른 에이전트 그러니까 서브 에이전트가 평가하게 했다라고 하는 부분입니다. 우리 사람도 그렇잖아요. 내가 만든 코드, 내가 만든 어떤 작업물 이런 것들에 대해서는 조금 더 평가를 후하게 하고 남이 맞는 것을 평가할 때는 조금 더 깐깐하게 보는 경향이 있는데이 코딩 에이전트를 활용할 때도 검증자와 평가자를 나누는게 굉장히 중요하다라고 볼 수가 있겠죠. 우리가 코딩 에이전트에게 루프를 설계할 때도이 검증자와 평가자를 분리하는게 굉장히 핵심적인 부분이라고 볼 수가 있을 것 같습니다. 자, 그리고 이제 두 번째 실험인데요. 두 번째 실험은 컨티뉴얼 러닝 벤치라고 해서 모델이 이제 세션을 왔다 갔다 하면서 학습하는지를 측정하는 벤치라고 보시면은 되고요. 그러니까 이제 AI가 어떤 작업을 진행을 할 때 한번 쓰고 버리는게 아니고 계속해서 경험을 쌓우면서 더 똑똑해질 수 있는지를 보는 벤치라고 보시면 될 거 같습니다. 그래서 여기서는이 모델이 실패를 어떻게 다루는지를 보게 되었는데요. 실패를 하게 되면은 그걸 이제 기록을 하게 되고 왜 실패했는지 조사를 하게 되고 그리고 진단을 검증된 사실로 변경을 하고 어 검증 결과를 일반적인 규칙으로 정리를 하고 다음번에는 또다시 그 규칙을 도출하는 대신에 기준의 규칙을 참고하게 만들 수가 있는지 이렇게 총 다섯 단계의 기준을 두고 이제 테스트를 해 봤다라고 보시면 되는데 어 소네 4.6 6모델은이 1단계에서 멈추게 되었다라고 하고요. 오프스 4.7 모델은 3단계 정도까지 갔다라고 하고 페이블 5 모델은 끝까지 완주를 했다라고 합니다. 그리고이 검증을 커버하는 비율을 측정을 해 봤을 때도이 페이블 5는 어 이렇게 73% 정도의 검증 커버 비율을 나타냈고요. 오프스 4.7 모델은 17% 정도의 검증 커버 비율을 나타냈다라고 합니다.이 두 가지 모델의 검증 커버 비율이 차이가 굉장히 많이 나죠. 전체적으로이 두 가지 실험은 공식 벤치는 아니고 소규모 벤치이긴 하지만 그래도이 결과가 굉장히 흥미로운 거 같고요.이 페이블 5 모델에 대해서 굉장히 좋은 찬사들이 많이 이루어지는 것도 있는데 어 안드리카파시도 이렇게 얘기를 했습니다. 질적으로 봐도 이것은 메이저 버전의 업그레이드를 정당화할 만한 획기적인 발전이다. 특히 매우 어려운 문제에 대해서 긴 문제 해결 세션에서 최고조에 달한다라고 하면서 복잡하거나 장기간 작업에서 굉장히 좋은 성능을 보인다라고 하는 이런 얘기를 했고요. 그런데 여러분들도 아마 느끼실 것 같은데요. 안전 장치가 지나치기 민감하게 설정이 되어 있다라고 이렇게 하고 있고 실제로 저도이 페이블 모델을 사용했을 때이 안전 장치 때문에 계속 뻘백되는 경우가 굉장히 많아 가지고 좀 불편한 경우가 종종 있었던 거 같아요. 그리고 페이블 5의 몇 가지 예시를 보여 드리면은 이렇게 3JS만으로 브라우저에서 실행되는 이런 3D 월드를 만들어내는 요런 사례도 있고요. 우주 시뮬레이션을 만들어 달라고 했는데 오프스 4.8 8 대비해서 페이블 5는 굉장히 많은 객체들을 생성을 해 가지고 이런 시뮬레이션을 만들어 주게 되었습니다. 주식 시장을 위한 마인크래프트 스타일 롤러코스터를 만들어라라고 이렇게 프롬프트를 했더니 한 번의 프롬프트만으로 이런 게임을 만들어 주기도 하고요. 이건 이제 보잉 747 벤치마크에서 AJI 수준의 작업을 해냈다라고 하는 거고 뭐 도시 폭풍 장면 같은 경우도 이렇게 잘 만들어 주는 모습을 확인을 할 수가 있습니다. 그래서 여러분들이 앞서 보신 것처럼 페이블 5 모델의 성능은 정말 정말 좋습니다. 그래서 우리가 페이블 5로 이런 식으로 루프를 돌려 볼 수가 있겠죠. 페이블 5 모델의 슬래시 골 명령어의 울트라 코드까지 활용하면은 루프는 정말 정말 잘 돌아간다라고 볼 수가 있을 것 같은데요. 그렇지만 저렇게 루프를 돌린다라고 하면은 이건 정말 토큰을 먹는 괴물이라고 느껴지는 것 같습니다. 우리가 토큰이 무한하지 않다라고 하면은 결국에는 사람이 루프 안에 있어야 되는게 아니냐라고 하는 이런 얘기들도 많이 나오고 있는데요. 어 그렇기 때문에 현재 시점에이 루프 엔지니어링이라고 하는게 주목받기 시작하지 않았나 생각이 되는 거 같습니다. 그렇지만 우리가 루프를 설계를 할 때 이런 명확한 종류 조건, 검증 기준이 없이 돌리는 루프는 자기 규정이 아니라 토큰 소각로라고 저는 생각을 하거든요. 루프를 돌릴 때 비싼 모델일수록 루프를 더 잘 설계를 해야 된다고 봅니다. 마지막으로 이제 밀어둔 질문 루프 엔지니어링 또 용어 장난 아니냐라고 하는 질문에 대해서 개인적인 의견을 말씀을 드리면은 사실이 루프 엔지니어링이라고 하는이 패턴 자체는 요즘에 나온 패턴이 아니고 예전부터 있던 패턴이라고 저는 생각을 하거든요. 24년도 12월 19일에 엔트로픽에서 빌딩티브 에이전트라고 이렇게 블로그 글을 한번 올렸었습니다. 여기서도 이런 식으로 이밸루에이터와 옵티마이저라고 하는 제너레이터와 이밸루에이터를 통해서 루프를 돌리는 이런 패턴들이 이미 얘기가 되고 있었었고요. 이외에도 에이전트에게 루프를 돌리는 이런 패턴들은 이전에도 존재하던 개념 중에 하나였는데 루프 패턴은 2년 전에도 있었는데 왜 그때는 활용하지 않고 이제 와서 다시 회자가 되고 있냐라고 하면은 크게는 이제 두 가지 문제가 있었습니다. 어 첫 번째는 이렇게 작은 수정만 반복하다가 제자리 갇히는 경우가 많이 있었고요. 그리고 두 번째는 검증 단계를 끝까지 완주하지 못하고 토큰만 태우는 이런 이슈들이 많이 있었기 때문에이 당시에는 이제 루프를 제대로 활용할 수가 없는 환경이었습니다. 그래서이 루프 엔지니어링이라고 하는 이런 용어가 새로 나오게 되는 이런 배경을 살펴보면은 결국에는 이제 LLM 모델이 굉장히 많이 발전했기 때문에 현재 모델에 맞춘 새로운 엔지니어링 패턴들이 나오게 된다라고 보시면 될 거 같고요. 예전에는 이런 루프를 사용해서 돌릴 수 있을 만한 그런 모델이 없었었고 그런데 이제는 페이블 5와 같은 모델이 나오면서이 루프를 돌릴 수 있을 만한 환경이 갖춰졌기 때문에 우리가 이런 루프 엔지니어링이라고 하는 이런 용어에 관심을 가질 필요는 있을 것 같습니다.이 루프 엔지니어링이라고 하는이 용어 자체가 살아남을지는 사실 잘 모르겠는데요. 그런데 이렇게 일하는 방식 자체는 우리가 가야 되는 방향성은 맞다라고 생각을 하고요. 그래서 페이블 파가 나온 지금 현재 시점을 보게 되면은 이제는 사람이 직접 프롬프트를 작성하기보다는 에이전트가 프롬프트를 작성하게 해야 하는 시점이라고 생각을 하고요. 그래서 이렇게 에이전트가 직접 프롬프트를 작성하게 만들게 하기 위해서는 첫 번째 루프를 구성하고 두 번째 에이전트에게 명확한 목표를 전달하고 세 번째는 스스로 테스트를 하게 하고 실패하면은 개선하는 프롬프트를 에이전트에게 작성하게 하고 그렇게 개선한 결과를 검증하고 다음번에 실패하지 않도록 메모리에 쌓아두고 그리고 마지막으로는이 위 모든 과정을 계속해서 반복하는 것을 만들게 되면은 여러분들만의 루프를 구성을 하실 수가 있겠죠? 그래서 제가 한번 예시로 루프를 돌려보고 있는데요. 페이블 5 모델을 사용을 하고 있고요. 그리고 울트라 코드를 사용을 해서 에포트 레벨을 높여 주었고 클로드 코드에서 이제 루프를 돌리는 가장 쉬운 방법은 이제 골 명령어를 활용을 하는 거죠. 스골 명령어를 활용한 다음에 여러분들이 진행하고자 하는 작업에 대한 목표를 정해 주시면 됩니다. 그래서 새로운 프로그래밍 언어 페이블을 만들고 그 언어만으로 3D 마인크래프트 게임을 만들어 달라라고 요청을 했고요. 이걸 이제 요청을 해 본 이유는이 페이블 모델의 진짜 성능을 한번 최대로 끌어내고 싶어서 요청을 했고 단순하게이 3D 마인크래프트 게임을 만드는 것에 대한 예제는 이미 너무나 많이 나와 있기 때문에 오프스 모델도 아마 이것도 잘 만들어 주지 않을까 생각이 돼서 페이블만이 할 수 있는 것이 뭐가 있을까를 생각을 해 봤을 때 어 프로그래밍 언어를 만들어서 이걸로 게임을 만들게 하면은 이건 좀 어려운 과제지 않을까라고 생각을 했습니다. 그리고 이렇게 제약 조건에 대해서도 설정을 해 주고 또 루프를 설계할 때 중요한 점은 여러분들이이 성공 기준에 대해서 정해 주는게 굉장히 중요하다라고 볼 수가 있습니다. 언제이 루프를 종료하고 언제 테스트를 하고 어떻게 하면 실패하는지에 대해서 알려 줘야지이 루프가 정상적으로 잘 돌아가게 될 수가 있다라고 보시면 될 거 같고요. 그래서 이제 영상 촬영 진행하는 동안에 루프가 다 마무리가 되었다라고 하는데 이렇게 빨리 끝나지는 않아야 되는데 벌써 끝났다라고 하네요. 한번 살펴보면은 언어 설계, 인터프리터 게임 테스트 문서까지 다 끝냈다라고 하고 인터프리터가 정상적으로 실행이 되었다. 게임 단어가 0이 나왔다. 레이캐스팅 로직이 페이블 소스 안에 있다. 채굴 설치 저장 자동 테스트 FPS가 10 이상이 나왔다라고 이렇게 성공 기준은 달성을 했다라고 하네요. C스타일 문법의 점페이블이라고 하는 확장자로 어 새로운 언어를 만들어 주었다라고 하고요. 그리고 파이썬으로 인터프리터를 만들어 줬다고 하는데 일단은 요거 게임 한번 실행을 해 보도록 할게요. 게임을 이렇게 실행하게 되면은 어 이렇게 움직이기가 가능하고요. 총을 발사하는 것도 가능하고요. 전체적으로 일단이 게임 자체는 지금 동작이 되는 것 같습니다. 어 그런데이 인터프리터 코드를 한번 봤을 때 어이 파이 게임이라고 하는 라이브러리를 사용해서 만들어 줬네요. 제가 이거는 원한 요구 사항이 아닌데이 파이게임 라이브러리를 사용을 하게 되었고요. 파이썬은 인터프리터 구연에만 사용을 하고 게임 로직 3D 렌더링 계산은 전부 페이블 소스에다가 넣어 달라라고 이렇게 제약을 저 걸어 주었는데 그리고 이런 식으로 인터프리터 내장 함수는 저수준만 허용해라라고 제약을 걸었는데 어 파이게임이라고 하는 것을 사용해서 만들어져서 어 사실상 이제 제가 만들려고 했던 그런 목표는 달성하지 못했다라고 보면 될 거 같습니다. 결과물이 좀 아쉬운 거 같기는 한데요. 그런데 제 실패 예시에서 볼 수 있는 점은이 루프를 설계할 때 목표와 제약 조건을 잘 정해 주는게 굉장히 중요한데 그것은 사실 그렇게 만만한 작업은 또 아니거든요. 그래서 이게 개발자의 엔지니어링 패턴 중에 하나로 또 자리를 잡아가는게 아닌가 싶네요. 어, 그리고 마지막으로는이 페이블 모델은 22일까지만 구독자에서 활용이 가능하니까 그때까지 최대한 많이들 활용을 해 보셨으면 좋을 거 같고요. 그리고 루프를 돌릴 때 비용을 절감할 수 있는 팁에 대해서 마지막으로 말씀을 드리고 마무리를 하도록 하겠습니다. 일단은 페이블 5는 진짜 너무 비싸니까 리드 엔지니어 역할만 맡기는게 더 좋다라고 생각을 하고요. 왜냐면은 모든 작업을 다 페이블 5에게 맡겨 버리면은 두 번의 작업만 시켰는데 200달러 구동 요금제에 한돌을 다 차감을 했다라고 하는 이런 사례들도 굉장히 많거든요. 그래서 간단한 펜아웃 하는 작업은 오프스나 소로 돌리고 복잡한 구조 설계나 검증 장기 루프만이 페이블 5에게 막히는 패턴이 가장 효율적이라고 생각을 합니다. 실제로 이렇게 하면은 비용을 거의 1/3에서 1/ 수준까지 줄일 수가 있으니까 페이블 모델 물론 좋지만 우리가 비용적인 부분을 생각을 하지 않을 수가 없기 때문에 어 지금부터 우리가이 루프를 돌릴 때 비용을 최적하는 구조를 좀 고민을 해 봐야 되는 시점인 것 같습니다. 그럼 저는 이번 영상은 여기서 마무리를 하도록 하고요. 다음 영상에서 더 좋은 정보 가지고 돌아오도록 하겠습니다.