🤖 레슨

루프 엔지니어링 — 프롬프트하는 루프를 설계하라

2026년 6월 지금 가장 뜨거운 말: "프롬프트를 치지 말고, 에이전트를 프롬프트하는 루프를 설계하라." 자는 동안 도는 일의 비밀.

① 오늘의 미션

사장님은 간을 한 번만 보지 않는다

된장국 간을 맞출 때를 떠올려보세요. 간 보고 → 싱거우면 된장 풀고 → 다시 간 보고 → 맞으면 멈춤. 한 번 휘젓고 끝이 아니라, 될 때까지 도는 것이죠.

그런데 우리는 지금까지 AI에게 '한 번 시키기'만 해왔어요. 시키고 → 결과 보고 → 아쉬우면 또 시키고… 그 '간보고 고치기'를 사람인 내가 돌았던 거예요. 오늘은 그 고리를 시스템에게 넘기는 법 — 2026년 6월 지금 가장 뜨거운 개념, 루프 엔지니어링입니다.

설명을 따라 진행하면, 여기서 직접 쳐보게 돼요 👇

~/my-shop

$ _

📚 「루프 엔지니어링 — 프롬프트하는 루프를 설계하라」 레슨 내용 전체 텍스트로 훑어보기

사장님은 간을 한 번만 보지 않는다

이 개념이 번진 과정이 흥미로워요. 바로 지금 일어나고 있는 일이거든요.

"Loops replace prompts"

🔥 2026년 6월 7일 — OpenClaw를 만든 Peter Steinberger가 선언해요: "이제 코딩 에이전트에게 프롬프트를 치고 있으면 안 된다. 에이전트에게 프롬프트하는 루프를 설계해야 한다."
📣 Google의 Addy Osmani가 이를 정리해 확산시키고, Anthropic Boris Cherny의 실전 사례들과 합류하면서 업계의 화두가 됐어요 — "루프가 프롬프트를 대체한다."

루프 설계란: 한 번 답하고 끝이 아니라, 실행 → 관찰 → 판단 → 재시도를 목표 달성까지 도는 시스템을 만드는 일이에요.

'프롬프트를 친다'와 '루프를 설계한다'의 결정적 차이는 뭘까요?

맞아요. 프롬프트는 한 턴의 지시문을 잘 쓰는 일이고, 루프는 무엇을·언제 프롬프트할지, 그리고 결과가 '합격'인지 판정하는 기준까지 시스템이 정하게 설계하는 일이에요. 내가 매번 간을 보는 게 아니라, 간보는 고리 자체를 만들어두는 거죠.

같은 '가격 오타 잡기'를 두 방식으로 비교해보세요.

💬 프롬프트 엔지니어링: 한 턴의 지시문을 최적화.
· "가격 오타 고쳐줘" → 답이 오면 끝
· 다 고쳐졌는지 판정은 내 몫
· 남았으면 내가 또 시켜야 함

🔁 루프 엔지니어링: 도는 시스템을 설계.
· 실행→관찰→판단→재시도를 목표 달성까지
· 합격 기준(오타 0개)을 시스템이 판정
· 내가 자는 동안에도 돎

말로만 듣지 말고 실물을 봐요. Claude Code엔 /loop가 있어요. 개발자들 사이에선 "/loop 내 PR들 돌보면서 빌드 깨지면 고치고, 리뷰 코멘트 오면 반영해줘"를 걸어두고 자는 게 유명한 사용법이에요. 우리는 가게 버전으로 돌려봐요.

/loop 우리 가게 페이지들 돌보면서, 깨진 곳 있으면 고치고, 새 고객 문의가 오면 답 초안 만들어줘

— 가게 돌보기 루프를 걸어요

이게 루프예요. 내가 매번 "점검해줘"를 칠 필요 없이, 시스템이 스스로 프롬프트하며 돌아요. 사장님이 주무시는 동안에도요. 🌙

그럼 루프를 '설계'한다는 건 뭘 정하는 걸까요? 딱 3가지예요. 간 맞추기에 대보면 —

루프 설계 3요소

1️⃣ 반복할 일 — 무엇을 도는가 → "간 보고, 안 맞으면 간하기"
2️⃣ 종료 조건 — 언제 멈추는가 → "간이 맞으면"
3️⃣ 검증 — 합격을 누가·어떻게 판정하는가 → "맛보기 — 기준은 우리 가게 레시피"

셋 중 가장 중요한 게 검증이에요. 검증 없는 루프는 폭주합니다 — '맞았는지' 모른 채 영원히 휘젓는 국솥을 상상해보세요.

종료 조건도 검증도 없이 /loop 첫 페이지를 계속 더 좋게 고쳐줘 라고 걸어두면 어떻게 될까요?

맞아요. '더 좋게'는 끝이 없는 목표예요. 언제 멈출지(종료 조건), 무엇이 합격인지(검증)가 없는 루프는 폭주해요 — 잘 되던 페이지를 계속 뒤집으면서요. 루프의 힘은 도는 데서가 아니라 제대로 멈추는 데서 나옵니다.

루프 설계 3요소를 한 줄로. 빈칸에 들어갈 말은?

정답, 검증이에요. 반복할 일·종료 조건·검증 — 이 셋이 갖춰져야 루프이지, 하나라도 빠지면 폭주 장치예요. 특히 검증은 합격선을 시스템에게 알려주는 일이라 빠뜨리기 쉽고 가장 중요해요.

이제 직접 설계해봐요. 한 문장 안에 반복할 일·종료 조건·검증이 모두 들어가게 루프를 걸어보세요.

모든 반찬 페이지의 유통기한 표기를 검사하고 틀린 건 고쳐줘. 틀린 곳이 0개가 되면 멈춰 — 3요소를 모두 담아 루프를 설계해요

cat loop-report.txt — 루프가 남긴 결과를 확인해요

방금 친 한 문장에 3요소가 다 들어 있었어요. 이게 '프롬프트를 친 것'이 아니라 '루프를 설계한 것'이에요. 그리고 보세요 — 폭주하지 않고 스스로 멈췄죠.

루프가 도는 한 바퀴를 순서대로 맞춰보세요. (↑↓로 정렬)

정확해요. 실행 → 관찰 → 판단 → 재시도/종료. 사장님이 간 맞출 때 몸으로 돌던 그 고리를, 이제 시스템이 돌아요. 사람은 루프를 설계하고 감독하는 자리로 올라가는 거죠.

내가 자는 동안 도는 루프 — 어디 위에서 돌아야 안전할까요? (지난 레슨을 떠올려보세요)

맞아요. 루프는 하네스 위에서 돕니다. 가드레일 없는 루프는 폭주를 밤새 반복하는 장치가 돼요. 지난 레슨의 작업장 설계(하네스 엔지니어링)가 바닥이고, 그 위에서 루프가 도는 것 — 두 레슨이 한 세트인 이유예요.

한 줄로

프롬프트를 치지 말고, 프롬프트하는 루프를 설계하라. 루프 = 실행→관찰→판단→재시도를 목표 달성까지 도는 시스템. 설계 3요소는 반복할 일·종료 조건·검증 — 그리고 루프는 반드시 하네스 위에서 돌립니다.

다음 레슨 예고 — 헤르메스

작업장(하네스)을 짓고, 그 위에 도는 고리(루프)까지 걸었어요. 그럼 마지막 질문 — 이걸 아예 가게에 상주시키면 어떨까요? 세션이 끝나도 나를 기억하고, 일하면서 스스로 요령(스킬)을 만들어가는 에이전트, 헤르메스를 다음 레슨에서 만납니다. 🏠