루프 엔지니어링의 현실과 현명한 활용법

최근 AI 코딩 커뮤니티는 루프 엔지니어링이라는 새로운 개념에 뜨겁게 반응한다. 앤트로픽 개발자 보리스와 피터의 발언으로 촉발된 이 흐름은 마치 프롬프트 엔지니어링을 겨우 익힌 이들에게 또 다른 장벽처럼 느껴진다. 하지만 영상은 루프가 미래일 수 있지만, 지금 당장 모든 이에게 적합한 것은 아니며 명확한 이유가 존재한다고 강조한다.

루프 엔지니어링의 두 가지 접근

AI 코딩 워크플로우는 크게 두 가지 방식으로 나뉜다. 기존에 클로드 코드, 코덱스, 커서 등을 활용하던 방식은 휴먼 인 더 루프(Human-in-the-Loop) 방식이다. 반면 최근 유행하는 방식은 사람의 개입을 최소화하는 에이전틱 루프(Agentic Loop) 방식이다.

다음 표는 두 방식의 차이점을 설명한다.

분류	휴먼 인 더 루프	에이전틱 루프
개입 주체	사람	에이전트
작동 방식	1. 사람이 프롬프트 입력 → 2. 에이전트가 결과물 생성 → 3. 사람이 결과 확인/테스트 → 4. 불만족 시 다시 프롬프트 → 5. 반복	1. 사람이 기획 문서 생성 (최초 한 번) → 2. 루프 실행 → 3. 에이전트가 결과물 생성 → 4. 에이전트가 스스로 결과물을 피드백으로 사용 → 5. 에이전트가 스스로 판단하여 작업 계속 → 6. 끝날 때까지 3~5 반복
통제 방식	사람이 단계마다 방향을 잡고 통제하며 승인한다. (예: 랜딩 페이지 승인 후 백엔드 작업으로 넘어감)	사람이 한 번 ‘방아쇠’만 당기면, 에이전트가 “끝날 때까지 멈추지 마, 실수하지 마” 명령에 따라 자율적으로 진행한다.
예시	클로드 코드, 코덱스, 커서 활용 코딩	슬래시골, 슬래시 루프, 랄프 루프

에이전틱 루프는 사람이 자는 동안 앱이 완성되는 이론적으로 아름다운 그림을 제시한다. 그러나 현실에서는 끔찍하게 꼬이는 문제가 발생한다.

에이전틱 루프가 직면하는 문제

에이전틱 루프는 다음과 같은 두 가지 심각한 문제를 안고 있다.

에이전트는 반드시 가정을 한다

사람이 스펙 문서 한 장으로 AI에게 모든 것을 맡기면, AI는 기획서에 없는 모든 빈칸을 스스로의 가정으로 채운다. 디자인의 느낌, 아키텍처 결정, 엣지 케이스 처리 등 무수한 부분에 AI의 가정이 개입한다. 문제는 이 가정들이 높은 확률로 의뢰자의 머릿속 그림과 다르다는 점이다.

인간 개발자에게 기획서를 주고 단 한 번의 상의 없이 모든 것을 만들어 오게 했을 때 문제가 발생하는 것과 같다. 외주나 에이전시 일을 해본 사람이라면 고객의 머릿속 생각을 전부 끄집어내려고 노력해도, 결과물을 보여주면 “아, 이건 빠뜨렸네요. 제 말은 이런 뜻이었어요”라는 반응이 나온다는 것을 안다. 인간끼리도 서로를 완벽히 이해하기 어려운데, 문서 한 장으로 AI가 당신을 완벽히 이해할 리는 없다. 게다가 제품에 대한 생각은 개발 도중에도 계속 바뀐다. 아직 본인도 완전히 시각화하지 못한 앱을 루프에게 통째로 맡기는 것은 불가능하다.

루프는 돈을 태우는 기계다

두 번째 문제는 더욱 현실적인 비용이다. 루프는 에이전트가 자기 결과물을 읽고 다시 생성하며 이를 반복하는 구조이다. 이 과정에서 토큰 사용량이 기하급수적으로 불어난다. 앤트로픽의 개발자 피터는 실제로 한 달에 130만 달러(약 18억 원)어치 토큰을 소모했다고 직접 밝혔다.

루프를 전파하는 이들은 대개 모델 회사 내부 인력으로, 그들에게 토큰은 사실상 공짜나 다름없다. 이들에게 자가 치유 에이전트를 실험하는 것은 합리적인 선택이다. 무제한 뷔페에서 접시 수를 세는 사람이 없는 것과 같은 이치이다. 그러나 이 방법론이 월 2만 원짜리 구독을 쓰는 일반 사용자에게 그대로 적용되는 것이 문제이다. 월 구독료 200달러의 맥스 플랜이 아니라면, 루프는 고려할 가치조차 없는 선택지가 된다. 결과는 보장되지 않지만 비용은 확정적인 구조이다. 루프는 레버를 당기는 순간 토큰이 빠져나가고 잭팟이 터질지는 아무도 모르는 슬롯 머신과 같다. AI 회사는 항상 이긴다.

루프가 효과적인 단 하나의 분야, 코드 리뷰

영상이 루프의 무용론을 주장하는 것은 아니다. 루프가 현시점에서 돈값을 하는 곳이 딱 한 군데 존재한다. 바로 코드 리뷰 루프이다.

코드 리뷰 루프의 워크플로우는 다음과 같다.

1. AI로 코딩 후 버전 관리 시스템(예: 깃허브)에 푸시한다.
2. 깃허브에 설치된 코드 리뷰 에이전트(예: 그랩타일)가 자동으로 코드를 리뷰하고 5점 만점으로 점수를 매긴다.
3. 점수가 4점 미만이면 프로덕션 배포를 금지한다.
4. 점수가 낮으면 /grabtail loop 같은 스킬을 실행한다.
5. 에이전트가 리뷰를 읽고 코드를 수정하며 다시 푸시하고 새로운 리뷰와 점수를 기다린다.
6. 4점 이상이 나오거나 다섯 번 시도할 때까지 5단계를 자동 반복한다.

이 루프가 잘 작동하는 이유는 앱 빌딩 루프와 결정적으로 다른 특징 때문이다.

• 고정된 피드백: “점수를 4점 이상으로 올려라”는 명확한 지시이다.
• 숫자로 정의된 성공 기준: 취향이나 비전, 창의성이 개입할 틈이 없다.
• 이진적인 목표: 통과 아니면 실패만 존재한다.
• 외부 평가자: 리뷰 에이전트가 객관적인 평가를 제공한다.
• 구조화된 피드백: 점수와 구체적인 지적 사항이 제공된다.

이러한 구조 덕분에 루프가 폭주할 수 없다. 물론 이 루프조차 완벽하지 않다. 푸시하는 코드가 1천 줄을 넘어가면 리뷰 에이전트가 전체 맥락을 소화하지 못해 5점이 거의 나오지 않는다. 따라서 풀 리퀘스트(PR)를 1천 줄 이하로 쪼개는 추가 규칙이 필요하다. 가장 통제된 루프에서도 여전히 운영 규칙이 필요하다는 의미이다.

루프 활용 조건과 한계

다음 표는 루프 활용의 적합성과 부적합성을 비교한다.

루프 활용이 적합한 경우	루프 활용 시 실패하는 경우
피드백이 고정되고 자동으로 생성된다. (예: 테스트 통과 여부, 리뷰 점수)	결과물에 취향과 비전이 들어간다. (예: 제품, 디자인, 사용자 경험)
결과가 이진적이다. (예: 성공/실패, 통과/실패)	본인도 무엇을 원하는지 아직 명확하지 않다.
디테일에 관심이 없다. (예: 일회성 실험, 프로토타입, 내부 벤치마크 도구)	중간에 사람의 피드백을 받아야 하는 작업이다.
같은 패턴의 반복 생산이다. (예: 동일하고 규정된 공식의 템플릿 페이지 300개 생성)	토큰 예산이 유한하다.

루프로 앱을 만드는 것은 완전 자율 주행 버튼을 누르는 것과 같다. 가는 길에 괜찮은 식당이나 좋은 여행지가 보여도 이미 지나가면 들를 수 없다. 자율 주행 자동차는 이미 가던 길로 가게 설정되어 있기 때문이다. 하지만 스타트업이란 본래 중간에 계속 멈춰 사용자에게 물어보고 경로를 수정해야 하는 여정이다. 루프에는 그런 피드백을 수용하는 부분이 없다.

현재 시점의 결론

루프가 영원히 불가능하다는 이야기는 아니다. 모델 성능 향상, 정교한 하네스, 저렴해지는 토큰 비용 덕분에 먼 미래에는 100% 가능해질 것이다. 그러나 2026년 6월 현재의 결론은 다음과 같다.

1. 루프 전도사들의 환경과 일반 사용자의 환경은 다르다. 토큰이 공짜인 사람의 워크플로우를 유료 구독자가 그대로 따라하면 안 된다.
2. AI는 소스를 복제할 수는 있어도 창조할 수는 없다. 제품의 디테일, 감각, 비전은 여전히 사람이 루프 안에서 공급해야 한다.
3. 루프를 쓰고 싶다면 코드 리뷰처럼 피드백이 고정되고 목표가 숫자로 정의되는 좁은 구간부터 시작한다. 이것이 지금 당장 돈값을 하는 유일한 루프이다.

결론적으로 현재는 여전히 휴먼 인 더 루프가 가장 좋은 루프 방식이다. 유행과 트렌드에 무작정 올라타기 전에 자신의 토큰 잔고와 작업의 성격부터 확인하는 것이 현명한 접근법이다. AI 코딩 시장이 급변하는 시기이지만, 유명 인사들의 말에 귀를 기울이되 무조건적인 추종은 피해야 한다. 정보의 옥석을 가려 자신의 것으로 만드는 지혜가 필요하다.

출처

• 김플립 - LLM 코딩. (2026-06-12). 루프? 한 달에 18억 태우는 사람들의 워크플로우를 당신이 따라하면 안 되는 이유. 하지만 쓰는곳이 있다.. YouTube.