루프 엔지니어링이란? 프롬프트 다음에 온 AI 활용 개념 쉽게 이해하기

루프 엔지니어링은 에이전트에게 매번 프롬프트를 넣던 '사람'의 자리를 시스템으로 대체하는 개념입니다. 2026년 6월 Addy Osmani가 이름 붙인 지 몇 주 만에 개발자들의 공용어가 됐습니다. 이 글을 읽으면 루프 엔지니어링이 프롬프트 엔지니어링과 뭐가 다른지, 비개발자가 지금 따라 해야 하는 건지까지 정리됩니다.

 

루프 엔지니어링은 AI에게 지시를 반복하던 사람을 '루프'라는 자동 시스템으로 바꾸는 일입니다.
프롬프트 엔지니어링의 대체가 아니라 그 위에 얹는 층이고, 2026년 7월 기준 대부분의 사용자에게는 아직 필요하지 않습니다.

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

가장 널리 인용되는 정의는 개발자 Addy Osmani가 2026년 6월 7일 자신의 블로그에 올린 글에서 나왔습니다.

그는 이렇게 정의합니다.

"루프 엔지니어링은 에이전트에게 프롬프트를 주는 사람의 자리를 스스로 대체하는 것이다.
그 일을 대신하는 시스템을 직접 설계한다."

여기서 에이전트는 단순 자동완성이 아니라, 파일을 읽고 고치고 명령까지 실행하는 AI 도구를 말합니다.

보통 우리는 이 에이전트에게 "이것 좀 해줘"라고 프롬프트를 넣습니다.

루프 엔지니어링은 그 지시를 사람이 매번 하지 않도록, 대신 지시하는 시스템을 만드는 것입니다.

이 글이 퍼진 계기는 오픈소스 AI 에이전트를 만드는 Peter Steinberger가 6월 초 X에 남긴 한 문장이었습니다.

"이제 코딩 에이전트에게 프롬프트를 넣지 마라. 에이전트에게 프롬프트를 넣어주는 루프를 설계하라."

비슷한 시기에 Anthropic에서 Claude Code를 이끄는 Boris Cherny도 공개 석상에서 "나는 더 이상 Claude에게 프롬프트를 넣지 않는다. 프롬프트를 대신 넣고 뭘 할지 판단하는 루프를 돌린다"고 말했습니다.

 

주방 시스템에 비유하면

비개발자라면 주방을 떠올리면 이해가 빠릅니다.

프롬프트는 요리사에게 "이 요리 한 접시 해줘"라고 한 번 지시하는 것입니다.

내가 옆에 서서 간을 보고, 부족하면 다시 시키고, 통과하면 그만 시킵니다.

루프 엔지니어링은 이 과정을 자동으로 도는 주방 시스템으로 바꾸는 일입니다.

"간을 봐라 → 부족하면 다시 조리해라 → 통과하면 끝내라"를 사람 없이 반복하도록 설계하는 것입니다.

오븐 타이머와 온도조절 장치를 떠올려도 됩니다.

내가 지켜보지 않아도 "다 익었나?"를 스스로 확인하고, 아니면 계속 굽고, 다 되면 멈춥니다.

이 '스스로 확인하고 멈추는 장치'가 뒤에서 설명할 검증 루프와 정지 규칙입니다.

 

프롬프트에서 루프까지, 계보 정리

루프 엔지니어링은 갑자기 튀어나온 개념이 아닙니다.

AI를 다루는 방식이 한 단계씩 올라온 흐름의 가장 위층입니다.

네 단계로 정리하면 이렇습니다.

단계	핵심 질문	한 줄 설명
프롬프트	어떻게 말하느냐	모델에게 넣을 입력을 설계
컨텍스트	무엇을 보느냐	제한된 창에 넣을 정보를 골라 담기
하네스	어디서 도느냐	파일·메모리·피드백이 있는 실행 환경에 연결
루프	누가 반복시키느냐	관찰→행동→검증→복구를 스스로 반복

컨텍스트에 대해 Anthropic은 "제한된 컨텍스트 창에 무엇을 넣을지 큐레이션하는 기술과 과학"이라고 공식 정의합니다.

하네스는 모델 하나를 실제로 일할 수 있는 환경에 연결한 것입니다.

루프는 그 하네스 위에서 타이머로 돌고, 필요한 도우미를 스스로 만들고, 자기 자신에게 다음 할 일을 먹여주는 층입니다.

개인적으로는 이 계보만 알아도 절반은 이해한 셈이라고 봅니다. 새 용어라기보다 오래된 자동화 아이디어에 이름을 붙인 쪽에 가깝기 때문입니다.

실제로 Pragmatic Engineer의 Gergely Orosz는 이 기법의 원조로 약 1년 전 'Ralph Wiggum' 루프를 공개한 Geoffrey Huntley를 지목합니다.

---

루프를 이루는 5개 부품과 메모리

Osmani는 실제로 도는 루프를 다섯 개 부품과 하나의 메모리로 분해합니다.

공장 라인을 떠올리면 각 부품의 역할이 선명해집니다.

Automations는 정해진 시간에 스스로 발동해 할 일을 찾아내고 분류합니다. 라인에서 물건을 계속 흘려보내는 컨베이어에 해당합니다.

Worktrees는 여러 에이전트가 동시에 일해도 파일이 서로 충돌하지 않게 작업 공간을 분리합니다.

Skills는 에이전트가 모르면 추측해버릴 프로젝트 지식을 미리 문서로 적어두는 부품입니다.

Plugins와 커넥터는 기존 도구나 외부 서비스, MCP에 에이전트를 연결합니다. MCP는 AI가 외부 도구와 안전하게 연결되도록 해주는 공통 규격입니다.

Sub-agents는 한쪽이 만들면 다른 쪽이 검사하도록, 생성과 검증을 다른 에이전트에게 나눠 맡깁니다.

마지막으로 메모리는 대화가 끝나도 상태를 남겨두는 저장소입니다.

"에이전트는 잊어도 저장소는 잊지 않는다." 사람도 깜빡하니 업무일지에 적어두듯, 에이전트도 매번 기억을 잃으니 노트를 디스크에 남겨두는 것입니다.

 

루프가 멈추지 않으면 왜 위험한가

루프에서 가장 흔하고 비싼 실수는 멈추는 규칙이 없는 것입니다.

제대로 된 루프는 네 가지 요소를 갖춥니다.

무엇이 루프를 시작시키는지(트리거), 어디까지 가면 끝인지(검증 가능한 목표), 다 됐는지 누가 확인하는지(검증자), 언제 멈추는지(정지 규칙)입니다.

특히 검증에는 원칙이 하나 있습니다.

"만든 사람이 자기 시험을 스스로 채점하지 않는다"는 것입니다.

답을 만든 모델이 그 답을 스스로 통과 처리하면 루프는 엉뚱한 결과를 붙잡고 계속 돕니다.

그래서 채점은 별도의 모델이나 독립된 검사에 맡깁니다. 검증 없는 루프는 사실상 돈을 태우는 일에 가깝습니다.

실제로 초기 'Ralph' 방식에서는 작업이 절반만 됐는데도 완료 신호가 먼저 나와 루프가 일찍 끝나버리는 문제가 있었습니다.

 

/goal과 /loop은 루프 엔지니어링일까

요즘 코딩 도구에는 루프를 돕는 기능이 실제로 들어왔습니다.

Codex가 2026년 4월 말 `/goal`을 실험적으로 내놓았고, 5월에 Claude Code에도 같은 기능이 들어왔습니다.

Claude Code 공식 문서에 따르면 `/goal`은 완료 조건을 걸어두면 매 턴이 끝날 때마다 작고 빠른 모델이 "됐나?"를 예/아니오와 이유로 판정합니다.

아니오면 그 이유를 힌트 삼아 계속하고, 예가 되면 자동으로 멈춥니다.

/goal 로그인 버그를 고치고 테스트를 통과시켜라.
     테스트가 모두 통과하면 완료. 또는 20턴 후 정지.

이렇게 "또는 20턴 후 정지" 같은 절을 넣어두면 무한 반복도 막습니다.

`/loop`은 성격이 조금 다릅니다. 정해진 시간 간격마다 프롬프트를 다시 실행하는 기능입니다.

정리하면 `/goal`은 조건이 충족될 때까지, `/loop`은 주기마다 반복입니다.

다만 이 둘은 루프를 돌리는 부품일 뿐, 그 자체가 루프 엔지니어링은 아닙니다.

진짜 루프 엔지니어링은 이런 부품으로 트리거·검증·정지·메모리를 조합해 하나의 시스템을 설계하는 일입니다.

📘 Claude Code /goal 공식 문서 보기 →

비용과 한계, 지금 꼭 해야 할까

루프는 공짜가 아닙니다.

사람이 한 번 지시하던 일을 시스템이 수십 번 반복하니 토큰 비용이 그만큼 불어납니다.

여러 자료가 공통적으로 언급하는 폭은 단일 에이전트가 약 4배, 여러 에이전트를 함께 돌리면 약 15배입니다.

중간 규모 코드베이스에서 50번쯤 루프를 돌리면 수십 달러에서 100달러 이상이 나올 수 있습니다.

월 20달러짜리 플랜에서 정지 규칙 없는 루프를 돌리면 요금과 사용 한도가 순식간에 바닥납니다.

기술 매체 AlphaSignal도 "대부분의 개발자는 아직 이게 필요 없다"고 짚습니다.

비용 말고도 '이해 부채'라는 문제가 있습니다.

루프가 뽑아낸 결과물은 돌아가긴 하지만 구조가 들쭉날쭉해서, 나중에 다른 사람이 이해하고 넘겨받기가 어렵습니다.

그래서 루프가 손해보다 이득인 상황에는 대체로 네 가지 조건이 필요합니다.

조건	이유
반복 작업이다	한 번만 할 일은 자동화 이득이 없다
자동 검증이 가능하다	사람이 매번 채점하면 루프의 의미가 없다
예산에 여유가 있다	토큰 비용이 몇 배로 뛴다
도구가 갖춰져 있다	부품이 없으면 시스템이 서지 않는다

이 중 하나라도 빠지면 이득보다 비용이 커지기 쉽습니다.

개인적으로는 지금 단계에서 비개발자가 서둘러 루프를 짜기보다, 프롬프트와 도구 사용에 먼저 익숙해지는 편이 낫다고 봅니다.

 

자주 묻는 질문

루프 엔지니어링이 프롬프트 엔지니어링을 대체하나요

대체가 아니라 위층입니다.

루프 안에서도 에이전트에게 좋은 지시를 넣어야 하므로 프롬프트 실력은 여전히 필요합니다.

다만 그 지시를 사람이 매번 하지 않고 시스템이 대신 하도록 만드는 것이 루프 엔지니어링입니다.

비개발자도 지금 시작해야 하나요

대부분은 아직 아닙니다.

앞서 본 네 가지 조건이 맞지 않으면 이득보다 비용이 큽니다.

반복되고, 자동으로 검증되며, 예산과 도구가 갖춰진 작업이 생겼을 때 검토해도 늦지 않습니다.

루프 엔지니어링이 뜨면 개발자는 사라지나요

그렇지 않습니다.

검증 기준을 정하고, 결과를 이해하고, 시스템을 설계하는 판단은 여전히 사람 몫입니다.

이 개념을 정리한 사람들도 "루프를 만들되 엔지니어로 남아라"는 말로 마무리합니다.

결론

루프 엔지니어링은 AI에게 매번 지시하던 사람을 자동 시스템으로 바꾸는 개념입니다.

프롬프트에서 컨텍스트, 하네스를 거쳐 올라온 가장 위층이고, 프롬프트 실력을 버리는 게 아니라 그 위에 얹는 방식입니다.

다만 비용이 몇 배로 뛰고 검증과 이해는 사람이 책임져야 하므로, 2026년 7월 기준으로는 대부분에게 아직 이른 이야기입니다.

지금은 용어의 뜻과 계보, 그리고 "언제 이득인지" 판단 기준을 알아두는 정도로 충분합니다.