요즘 유행하는 Loop Engineering, 알고 보면 어렵지 않다

by

개요

이 영상은 최근 보리스 체니와 피터 슈타인버거 같은 유명 개발자들이 언급하면서 유행하기 시작한 “루프 엔지니어링” 개념을 명확하게 정리합니다. 핵심 메시지는 루프 엔지니어링이 갑자기 등장한 어려운 신개념이 아니라, 기존 기법들의 자연스러운 연장선이며 모든 사람에게 적합한 것은 아니라는 점입니다. 트렌드에 휩쓸려 불안해할 필요 없이 자신의 프로젝트 규모에 맞는 기법을 선택하면 된다는 안심을 주려는 것이 영상의 목적입니다.

이 영상은 코드팩토리 채널이 제작한 콘텐츠로, AI 코딩 도구와 프로그래밍 관련 실무 콘텐츠를 다루는 채널입니다. 영상에서는 클로드 코드에 딥리서치를 시켜 가져온 정보를 기반으로 직접 설명용 웹사이트와 데모를 만들어 개념을 시각적으로 풀어냅니다.

핵심 내용

랄프 루프, 하네스 엔지니어링, 루프 엔지니어링의 차이

화자는 시청자들이 가장 헷갈려 하는 지점이 “랄프 루프”, “하네스 엔지니어링”, “루프 엔지니어링” 이 세 가지가 어떻게 다른가라고 봤습니다. 핵심은 이 개념들이 서로 “대립”하는 것이 아니라 “중첩”된다는 것입니다. 표현은 조금 이상하지만 정확한 표현이라고 강조합니다.

랄프 루프는 가장 먼저 나온 기법으로, 에이전트를 오랫동안 반복적으로 돌릴 수 있게 하기 위해 만들어진 단순하고 무식한 기법입니다. 중요한 점은 랄프 루프가 굉장히 옛날에 나왔다는 것으로, 당시는 롱러닝 에이전트라는 개념이 존재하지 못하던 시대였습니다. 한 번 프롬프팅해서 하네싱 안에서 오랫동안 작업할 수 있는 기능 자체가 없던 시기였다는 점을 기억해야 순서가 이해됩니다.

랄프 루프의 작동 방식과 컨텍스트 문제

랄프 루프가 나올 때쯤(작년경)에는 200K 컨텍스트에 대한 문제가 있었고, PRD나 체크포인트를 만들었을 때 매번 작업이 끝나면 다음 작업을 실행하기 위해 휴먼 인 더 루프가 중간에 들어가야 했습니다. 이를 멈추고 싶지 않으니 “알아서 계속 반복해서 작업하라”는 것을 구현하기 위해 만든 것이 랄프 루프입니다.

이때 가장 중요했던 개념이 “니들 인 헤이스택”이라 불리는 컨텍스트 디그라데이션 문제였습니다. 문맥이 꽉 차면 퍼포먼스가 낮아진다는 것으로, 지금도 유효하지만 옛날보다 많이 나아졌습니다. 그래서 퍼포먼스를 항상 최적 상태로 유지하기 위해 태스크를 잘게 쪼개는 것이 랄프 루프에서 가장 중요했습니다. 매번 하나의 태스크를 실행할 때마다 그 결과만 디스크에 저장해 컨텍스트를 최소화한 다음, 새로운 에이전트를 띄워 새로운 컨텍스트에서 다음 작업을 하면 훨씬 빠르고 효율적이라는 것이 유행의 첫 번째 이유였습니다. 이 작업은 완성도를 높이는 것이 아니라 0번부터 10번까지 프로그레스를 진행하는 데 포커스가 맞춰져 있었습니다.

하네스 엔지니어링

하네스 엔지니어링은 정의가 사람마다 다르지만, 쉽게 말하면 메타프롬프팅 안에 이미 정의되어 있는 “어떤 스코프 안에서 어떻게 진행해야 하는지”에 대한 것입니다. 이를 파일로 저장해 관리하면 그 자체가 하나의 하네스가 되며, 코드나 딥리서치처럼 여러 에이전트가 유기적으로 움직이는 작업을 하면 다이나믹하게 만들어진 하네스가 됩니다.

화자는 사람들이 “하네스를 만들어야 한다”는 키워드에 너무 집착한다고 봅니다. 어느 정도 스코프가 정해지면 좋지만, 하네스를 상세하게 짤수록 시간이 더 걸리고 오히려 더 안 되는 결과를 얻게 됩니다. 요즘 하네스 엔지니어링을 디테일하게 직접 하지 않는 이유는, 울트라 코드 같은 도구를 쓰면 어차피 다이나믹하게 하네스가 생겨나기 때문입니다. 따라서 그런 다이나믹한 하네스가 생겨날 수 있는 환경만 제공하면 됩니다. 하네스 엔지니어링은 오랫동안 목표를 향해 가면서 정한 조건을 벗어나지 않도록 제한하는 방식으로, 0에서 100까지 가는 과정에서 무엇을 해야 하고 무엇을 하면 안 되는지에 대한 정의입니다.

루프 엔지니어링의 진짜 의미

루프 엔지니어링의 첫 번째 정의는 “나를 대체하는 시스템”으로, 프롬프트를 매번 직접 입력하지 않아도 된다는 것입니다. 여기서부터 헷갈리기 시작하는데, 아무것도 안 해도 AI가 자비스처럼 모든 작업을 한다는 뜻이 아닙니다. 랄프 루프에서 했던 것을 조금 더 상세하게 나눈 것으로 이해할 수 있습니다.

결국 골이든 울트라 코드든 딥리서치든, AI가 “나 이만큼 다 했어요”라고 하면 그 뒤에 사람이 프롬프트를 넣어 완성도를 올리는 작업을 계속 반복해야 합니다. 루프 엔지니어링이 말하는 것은 첫 번째 프롬프트는 있어야 하지만, 두 번째·세 번째·n번째 프롬프트를 줄여야 한다는 것입니다. n번째 작업을 반복해 완성도를 올리고 맨 마지막에만 사람에게 돌아와 “끝났어요”라고 할 수 있다면 루프 엔지니어링을 하고 있는 것입니다.

화자는 “you shouldn’t be prompting coding agents anymore”라는 포스트가 마치 프롬프팅을 아예 하면 안 되는 것처럼 들리지만, 실제 루프 엔지니어링 서술을 보면 “행동하고, 관찰하고, 결정한 다음, 반복하라”고 되어 있다고 설명합니다. 즉 무에서 유를 한 번에 창출하는 것이 아니라, 액트 → 옵저브 → 디사이드 → 리피트의 루프가 도는 순간마다 만들고 싶은 기능의 완성도가 계속 올라가는 과정입니다.

실전 가이드

영상에서 화자는 루프 엔지니어링이 올바르게 적용되는 예시로 두 가지를 구체적으로 보여줍니다.

먼저 경쟁자 분석 사례입니다. “쇼핑몰 사이트를 만들고 알아서 완성도를 올려”라고 막연하게 말하는 것은 루프 엔지니어링이 아닙니다. 대신 “경쟁자 B의 A/B 테스트 방식을 그대로 베껴서, 우리 방식과 완전히 일치할 수 있도록 계속 반복 작업하고, 반복할 때마다 어떤 결과가 있었는지 리포트로 상세히 정의해 달라”고 요청하는 것이 루프 엔지니어링입니다. x, y, z 요소가 있어야 한다는 조건과 시뮬래리티(유사도)를 측정하라는 조건을 세워주면, AI가 그 조건을 맞춰가며 기능의 완성도를 높입니다.

다음으로 화자가 직접 만든 “고양이 그리기 루프” 데모입니다. 이미지를 하나 넣으면 순수 HTML 캔버스와 자바스크립트로 최대한 비슷하게 그려내도록 했습니다. 작동 방식은 다음과 같습니다. 1회차부터 직전 최고 결과물에 직접 비평을 반영해 수정하고, 이를 헤드리스 렌더링으로 관찰합니다. 그 다음 원본 이미지와 AI가 그린 이미지를 비교해 0부터 100까지 유사도 점수를 매기고, 무엇을 바꾸면 점수가 오를지 비평을 리뷰 파일에 적습니다. 이 내용을 상태 파일에 저장하고 뷰어에 반영한 뒤 다시 반복합니다. 유사도 90%에 도달하면 통과하고, 반복할 때마다 n번째 결과를 따로 저장합니다. 이 프롬프트 역시 딥리서치를 기반으로 메타프롬프팅한 것입니다.

23번째 이터레이션까지 가자 첫 번째의 대충 그린 결과와 비교해 눈, 얼굴, 고개 각도까지 입체감과 완성도가 크게 높아졌습니다. 다만 아트워크나 창작물은 트레시홀드(임계값)를 코드로 정확히 판단하기 어려워, 유사도 점수를 다소 자유롭게 매기게 됩니다.

비판적 검토

이 영상은 유행하는 용어를 신격화하지 않고 시기적·기술적 맥락 속에서 차분하게 정리한다는 점이 강점입니다. 특히 랄프 루프 → 하네스 엔지니어링 → 루프 엔지니어링의 등장 순서를 컨텍스트 디그라데이션, 롱러닝 에이전트의 부재 같은 당시 기술 한계와 연결해 설명한 부분이 인상적입니다.

화자가 가장 강조하는 비판적 관점은 “프로젝트 스코프의 차이”입니다. 보리스 체니처럼 수많은 피처가 유기적으로 얽힌 거대한 프로젝트에서는 새 기능이 기존 기능과 완벽히 융화되고 다른 것을 깨뜨리지 않는지 판단하는 것이 가장 중요하며, 이때 루프 엔지니어링이 사람의 개입 없이 완성도를 끝까지 올리는 데 큰 힘을 발휘합니다. 반면 사이드 프로젝트나 MVP를 막 벗어난 작은 프로젝트, PMF를 찾는 단계에서는 프론티어 모델의 성능이 워낙 좋아 루프를 여러 번 돌릴 만큼 어려운 작업이 아닐 수 있습니다. 이런 경우 루프를 짜고 돌리는 데 시간과 토큰만 낭비하게 됩니다.

또한 화자는 콘텐츠 제작자들이 조회수를 위해 포모(FOMO)를 만들며 과장하는 경향이 있음을 솔직하게 인정하며, 새 기법에 휩쓸리기보다 “라이트 잡(right job)에 맞는 기법”을 쓰라고 조언합니다. 다만 영상은 구체적인 트레시홀드 자동 판단 방법이나 대규모 프로젝트에서의 구체적 설정 예시는 깊게 다루지 않아, 실제 적용 시에는 추가 학습이 필요합니다.

핵심 요점

  1. 랄프 루프, 하네스 엔지니어링, 루프 엔지니어링은 대립이 아니라 중첩 관계이며, 등장 순서와 당시 기술 한계를 알면 자연스럽게 이해됩니다.
  2. 랄프 루프의 핵심은 컨텍스트 디그라데이션을 피하기 위해 태스크를 잘게 쪼개고, 결과만 디스크에 저장한 뒤 새 컨텍스트에서 다음 작업을 진행하는 것입니다.
  3. 하네스 엔지니어링을 지나치게 디테일하게 짜면 오히려 시간이 더 걸리고 결과가 나빠집니다. 다이나믹한 하네스가 생겨날 환경만 제공하면 됩니다.
  4. 루프 엔지니어링은 첫 프롬프트를 없애는 것이 아니라, 완성도를 올리기 위한 n번째 반복 프롬프트를 자동화해 마지막에만 사람이 개입하도록 만드는 것입니다.
  5. 가장 중요한 것은 프로젝트 규모와 본인의 이해도에 맞는 기법을 선택하는 것입니다. 트렌드에 휩쓸려 작은 프로젝트에 루프 엔지니어링을 억지로 적용하면 토큰과 시간만 낭비됩니다.

참고자료

Leave a Comment