루프 엔지니어링? 그거 원래 하네스입니다 — 그런데 진짜 봐야 할 건 따로 있습니다

들어가며 — 무슨 일이 있었나

이달 둘째 주, 타임라인에 같은 서사가 반복되고 있습니다. 발화점은 개발자 Peter Steinberger가 X에 올린 한 문장입니다 — “이제 코딩 에이전트에 직접 프롬프트하지 마라. 에이전트에게 프롬프트를 거는 루프를 설계하라.” 이 글이 수백만 조회수를 기록했고, Claude Code를 만든 Anthropic의 Boris Cherny도 “나는 더 이상 클로드에 직접 프롬프트하지 않는다, 루프가 대신 한다”고 호응했습니다. 곧이어 Addy Osmani가 이 흐름에 루프 엔지니어링(Loop Engineering)이라는 이름을 붙여 정리했고, 유튜브 채널들이 일제히 받아 옮기기 시작했습니다.

썸네일은 약속이라도 한 듯 비슷합니다. 프롬프트는 끝났다, 루프는 다르다, 명령자가 아니라 시스템 설계자가 돼라.

먼저 결론부터 말하면, 이 프레이밍은 절반만 맞습니다. 그리고 다들 같은 표면만 복사하는 사이에, 정작 같은 주에 나온 1차 소스의 알맹이는 거의 잘려나갔습니다. 이 글은 그 둘을 갈라보려고 씁니다.

1. “프롬프트는 끝났다”는 틀렸습니다

가장 자극적인 문장이 가장 부정확합니다. 루프는 프롬프트를 대체하지 않습니다.

루프를 돌리려면 결국 각 단계의 지시 품질이 받쳐줘야 합니다. 더 결정적으로, 루프의 심장인 검증 기준(rubric)과 목표(goal)를 정의하는 일 자체가 고도의 프롬프트 작업입니다. 모델에게 “무엇을 통과로 볼 것인가”를 언어로 명세하는 것 — 이게 프롬프트가 아니면 무엇입니까.

이름을 붙인 당사자조차 그렇게 말하지 않습니다. Osmani의 글을 직접 읽어보면, 직접 프롬프트하는 것도 여전히 유효하며 루프는 그 위에 얹는 것이라는 단서가 분명히 달려 있습니다. “프롬프트는 끝났다”는 원문이 아니라 요약본들이 만든 문장입니다.

그러니 정확한 표현은 “프롬프트가 끝났다”가 아니라 “프롬프트 위에 한 층이 더 얹혔다”입니다. 대체가 아니라 적층입니다. 한 번 쓰고 끝나는 단발 프롬프트에서, 검증·반복·기억을 포함한 시스템을 설계하는 쪽으로 무게중심이 옮겨갔을 뿐입니다. 저는 이미 발행한 글에서 프롬프트는 죽지 않았다고 썼습니다 — 죽은 건 꼼수고, 명확히 정의하고 명확히 건네는 능력은 더 귀해진다고요. 이번 흐름은 그 명제의 반복 증명입니다.

2. 루프 = 하네스(harness)의 리브랜딩

“루프 엔지니어링”이라는 단어를 처음 듣고 새로운 패러다임이라 느꼈다면, 한 꺼풀만 벗겨보겠습니다.

목표·통과 기준을 적은 마크다운 파일 (goal·rubric) = 평가 기준(assertion)을 명문화한 eval harness
필수 통과 / 측정 / 평가 기준 = pass-fail gate + metrics + LLM-as-judge
운영 감시 루프 = CI에 물린 자동 검증 + 자가 수정 파이프라인
자동 처리 vs 사람 호출 경계선 = human approval gate

하나하나 뜯어보면 새로운 게 없습니다. 모델에게 일을 시키고, 통과/실패 기준을 걸고, 실패하면 스스로 고치게 하고, 위험한 영역은 사람이 승인하게 막습니다. 이건 harness-driven development, 혹은 eval-driven development라는 이름으로 이미 돌아가던 방식입니다.

“하네스”라고 하면 안 팔리고 “루프는 다르다”라고 하면 조회수가 나옵니다. 용어만 새것이고 알맹이는 그대로입니다. 강의에서 누군가 “루프 방식 아세요?”라고 물으면 “그거 하네스입니다” 한마디로 정리됩니다.

그리고 “고성능 LLM이 등장해서 비로소 루프가 가능해졌다”는 인과도 부풀려졌습니다. 자기 검증 루프와 eval harness는 모델 성능과 무관하게 예전부터 돌리던 구조입니다. 모델이 좋아지면서 루프당 성공률이 올라간 것이지, 루프 자체가 새로 생긴 게 아닙니다.

3. 그런데 — 다들 놓친 알맹이가 있습니다

여기까지만 쓰면 흔한 “또 마케팅이네” 글입니다. 하지만 같은 주에 나온 1차 소스를 직접 읽어보면, 유튜브 요약들이 통째로 잘라낸 두 가지가 보입니다. Anthropic의 Lance Martin이 쓴 “Designing loops with Fable 5”입니다. 발화점이 된 여섯 단어짜리 선언이 아니라, 루프를 실제로 돌려본 실험 기록이고 — 실무에서 진짜 쓸모 있는 부분은 여기에 있습니다.

(1) 채점자를 분리하십시오 — 자기 채점은 오염됩니다

핵심은 “모델이 스스로를 채점하면 안 된다”는 것입니다. 같은 문맥 안에서 자기 출력을 자기가 평가하면 판단이 오염됩니다. Lance Martin의 실험에서 독립된 컨텍스트 윈도우에서 채점하는 별도의 검증 에이전트(verifier sub-agent)가 자기 비평(self-critique)보다 일관되게 우수했습니다. 이건 한 사람의 의견이 아닙니다 — Anthropic의 공식 Fable 5 프롬프트 가이드도 같은 권고를 합니다. 지난 글에서 다뤘던 바로 그 대목입니다.

답은 단순합니다. 채점은 작업과 같은 세션에서 하면 안 됩니다. 자기가 푼 시험지를 자기가 채점하면 후하게 주기 마련이니까요. 루프를 짤 때 이 분리를 안 하면, 그럴듯한 자기합리화만 쌓인 채 “통과”가 찍힙니다. 결과를 받아 고치는 일은 재생성이 아니라 평가라고 썼던 것과 같은 줄기입니다 — 평가의 눈은 작업의 눈과 떨어져 있어야 합니다.

여기서 “우리 회사에선 안 되는 얘기”라고 느끼실 수 있습니다. 검증 에이전트니 서브에이전트니 하지만, 기업 환경에서는 보안 승인을 받은 모델 하나만 쓸 수 있는 경우가 대부분이니까요. 그런데 이 권고의 핵심은 다른 모델이 아니라 다른 컨텍스트입니다. 작업 이력이 없는 새 세션이면 충분합니다. 같은 모델이라도 새 채팅을 열고, 결과물과 통과 기준만 건네서 채점시키는 것 — 그게 검증 에이전트의 가장 수동적인, 그러나 본질은 그대로인 구현입니다. 회사가 켜준 도구 하나로도 오늘부터 할 수 있습니다. 도구 선택의 기준은 성능이 아니라 회사가 쓸 수 있는 것이라고 썼는데, 이 원칙은 그 기준을 통과합니다.

(2) 메모리는 단순 저장이 아니라 5단계로 익습니다

두 번째는 메모리를 세션을 가로지르는 바깥 루프(outer loop)로 본다는 관점입니다. 그냥 “기억하게 하면 좋다” 수준이 아닙니다. 메모리는 다음 단계를 거치며 점점 쓸모 있어집니다.

실패 기록(fail) — 무엇이 틀렸는지 기록합니다
원인 조사(investigate) — 왜 틀렸는지 원인을 팝니다
검증(verify) — 추측을 검증된 사실로 굳힙니다
증류(distill) — 개별 사실을 일반 규칙으로 증류합니다
참조(consult) — 다음 작업에서 그 규칙을 참조합니다

메모리의 가치는 양이 아니라 익은 정도에서 나옵니다. 쌓는 게 아니라 증류하는 겁니다.

흥미로운 건 모델마다 어디서 멈추느냐가 갈린다는 점입니다. 어떤 실행은 “실패 노트”만 잔뜩 쌓고 1단계에서 멈춥니다. 어떤 실행은 원인 추측까지는 적어두지만 검증으로 굳히지 못한 채 멈춥니다. 가장 강한 실행은 끝까지 가서 검증된 규칙으로 증류해 다음 작업에 실제로 써먹습니다 — Lance Martin의 실험에서 이 차이가 이전 세대 모델 대비 약 6배의 개선 폭으로 벌어졌습니다. 앞서 “모델이 좋아지면서 올라간 건 루프당 성공률”이라고 했는데, 그 성공률의 실체가 바로 이것입니다. 루프라는 구조가 새로 생긴 게 아니라, 같은 구조 안에서 모델이 몇 단계까지 가느냐가 달라진 겁니다.

즉, 메모리의 가치는 양이 아니라 얼마나 익었느냐에서 나옵니다. 미해결 추측만 잔뜩 적어둔 저장소는 다음 세션에서 거의 참조되지 않습니다. 많은 “AI에게 메모리를 붙였다” 사례가 1~2단계에 머무는 이유입니다. 마크다운만 쌓으면 그냥 폴더라고 썼던 것과 정확히 같은 구조입니다 — 사람의 지식이 연결돼야 자산이 되듯, AI의 메모리는 증류돼야 자산이 됩니다.

정리 — 무엇을 버리고 무엇을 가질 것인가

버릴 것: “프롬프트는 끝났다”, “완전히 새로운 패러다임이다”라는 자극적 프레이밍. 이건 마케팅입니다.
가질 것: 단발 프롬프트에서 검증·반복·기억을 설계하는 시스템으로 무게중심을 옮긴다는 방향성. 이건 맞습니다.
진짜 챙길 것: 채점자를 작업자와 분리하십시오. 그리고 메모리는 쌓지 말고 증류하십시오. 이 둘이 다들 놓친 실전 포인트입니다.

용어가 바뀌었다고 일이 바뀐 건 아닙니다. “루프”라는 새 간판이 걸렸지만, 안에서 돌아가는 건 여전히 잘 설계된 하네스입니다. 다만 그 하네스를 제대로 짜는 법 — 채점을 어떻게 떼어내고, 기억을 어떻게 익히는가 — 거기서 실력이 갈립니다.

간판 말고 그 아래를 보십시오.

출처

이 글의 사실관계는 위 출처를 따르며, 해석과 현장 관점은 박상훈의 견해입니다.