2026년 6월 30일

루프 엔지니어링이 뭐길래: AI에게 '일'이 아니라 '루프'를 줘야 하는 진짜 이유 (하네스 엔지니어링 다음)

AI한테 일 말고 루프를 줘라 — 한 번 시키고 내가 다시 vs 스스로 점검하고 다시

AI한테 일 시켜놓고 결국 내가 다시 붙잡고 앉아 있던 적, 있으시죠. 분명 똑똑한 모델인데 결과물은 한 번에 안 나옵니다. "더 좋게 고쳐줘" 하면 무한히 돌거나, 한 번 손대고 멋대로 멈춰버리고. 저도 한참을 그랬어요.

요즘 AI를 좀 깊게 쓰는 사람들 사이에서 '루프 엔지니어링(loop engineering)' 이라는 말이 돕니다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링… 그 다음 차례라는 거죠. 쉽게 말하면, AI가 스스로 "됐나?"를 확인하고 안 됐으면 알아서 다시 하게 만드는 것. 처음엔 저도 "또 새 단어 만들었네" 했습니다. 그런데 파보니까, 이게 제가 위에서 겪던 그 답답함의 정확한 정답이더라고요.

오늘 풀어볼 건 딱 하나. 루프가 대체 뭐고, 한 번 시키는 것과 뭐가 그렇게 다른가. 그래서 왜 이게 "AI 잘 쓰는 사람"과 "AI한테 끌려다니는 사람"을 가르는지 봅니다. 용어 자랑이 아니라, 본인 일에 바로 쓰라고 쓰는 글이에요.

프롬프트 → 컨텍스트 → 하네스 → 루프, 한 줄씩

복잡해 보이지만 줄 세우면 간단합니다. 다 "AI한테 어떻게 일 시킬까"의 진화 단계거든요.

프롬프트 엔지니어링 — 뭐라고 물을까 (질문을 잘 짜기)
컨텍스트 엔지니어링 — 뭘 쥐여줄까 (필요한 정보·자료를 넣어주기)
하네스 엔지니어링 — 어떤 환경에서 굴릴까 (AI가 쓸 도구, 해도 되는 일의 범위, 결과를 점검하는 장치까지 갖춘 '작업 환경')
루프 엔지니어링 — 그 환경 안에서 어떻게 돌릴까 (실행 → 점검 → 수정 → 반복의 순환)

프롬프트 → 컨텍스트 → 하네스 → 루프 4단계 흐름

비유하면 하네스가 '차 한 대'입니다. 엔진(모델)에 핸들, 브레이크, 차선, 경고등까지 갖춘 시스템이죠. 그런데 좋은 차를 줘도 한 바퀴 굴리고 멈추면 목적지엔 못 갑니다. 그 차로 목적지까지 실제로 굴러가는 '운전', 그게 루프예요. 차를 갖추는 게 하네스, 그 차로 도착할 때까지 달리는 게 루프.

왜 하필 지금 루프가 화제일까요. 모델이 이미 충분히 똑똑해졌기 때문입니다. 같은 엔진(모델)이라도, 이제 결과를 가르는 건 "더 똑똑한 모델"이 아니라 "어떻게 돌리느냐" 예요. 그리고 이건 누가 지어낸 유행어가 아닙니다. Claude를 만든 앤트로픽이 공식 문서에서 AI 에이전트가 일하는 방식을 딱 이 순환으로 정의했거든요 — 맥락 수집 → 실행 → 검증 → 반복(gather → act → verify → repeat). 심지어 이렇게 못박았죠. "자기 결과를 스스로 점검하고 고칠 수 있는 에이전트가 근본적으로 더 믿을 만하다. 실수가 커지기 전에 잡아내고, 어긋나면 스스로 바로잡으며, 반복할수록 나아지기 때문이다." 오늘 할 얘기가 사실 다 이 한 문장 안에 있습니다.

앤트로픽 공식 정의 — 맥락 수집·실행·검증·반복 순환도

왜 1. 한 번의 출력은 '추측', 루프는 '과정'

이게 핵심 중의 핵심입니다.

AI한테 일을 한 번 시키는 건, 주사위를 한 번 굴리는 것. 좋은 게 나올 수도, 어정쩡한 게 나올 수도 있죠. 그게 그 한 번의 '추측'입니다. 다음에 더 나아진다는 보장이 없어요. 추측은 쌓이지 않으니까요.

루프는 다릅니다. 결과를 내고 → 스스로 기준에 비춰보고 → 모자라면 그걸 딛고 다시 합니다. 한 번의 시도가 다음 시도의 발판이 되죠. 추측은 안 쌓이지만, 과정은 쌓인다.

추측 vs 과정 — 한 번 시킴은 안 쌓이고 루프는 쌓인다

뭔가 만들어 본 사람은 이 감각 압니다. 첫 초안이 최고인 경우는 없잖아요. 쓰고, 들여다보고, 고치고를 반복하면서 좋아지죠. 그 '초안 → 검토 → 다시 쓰기'가 바로 루프입니다. 그런데 우리가 AI한테 일을 시킬 땐 이상하게 그 검토·다시쓰기 단계를 통째로 빼먹고 한 방에 받으려고 해요. 그래놓고 "AI 결과물은 영 별로네" 하는 거죠. 루프는 그 빠진 단계를 다시 끼워 넣는 일입니다.

왜 2. 품질은 '내 시간'이 아니라 'AI가 반복한 횟수'에서 나온다

여기서 진짜 이득이 갈립니다.

루프가 없으면, 결과물 품질은 "내가 몇 번 들여다봤는가"에 묶입니다. 한 단계 더 좋게 만들려면 내가 한 번 더 봐야 하고, 한 번 더 고치라고 시켜야 하죠. 품질이 내 시간에 비례하는 구조. 그래서 AI를 써도 시간이 안 줄어요. 일은 AI가 하는데 검토는 내가 다 하니까요.

루프가 있으면, 품질은 "AI가 몇 번 반복했는가"에 묶입니다. 그리고 그 반복은 내 시간이 아니라 AI의 시간이라, 사실상 공짜예요. 내 시간을 거의 안 쓰고 품질이 올라간다. 이게 핵심이에요 — 품질을 '내가 검토한 횟수'에서 'AI가 반복한 횟수'로 옮기는 것.

품질은 어디서 나오나 — 내 시간 vs AI 반복 횟수

이게 진짜 위임입니다. 지난 글에서 AI에게 일을 넘기는 3단계 — 쪼개기·맡기기·남기기를 정리했는데, 거기서 한 걸음 더 들어가야 완성되는 게 이거예요. 실행만 넘기는 게 아니라 '점검과 수정까지' 넘기는 것. 실행만 넘기면 점검은 내 몫으로 남아서 결국 내가 병목이 됩니다. 점검까지 넘겨야 비로소 AI가 혼자 돌고, 나는 다 된 것만 받죠. 그 '점검까지 넘기는 장치'가 루프고요.

왜 3. 진짜 어려운 일은 '하기'가 아니라 '되는 걸 찾기'

곰곰이 보면, 어떤 일이든 진짜 어려운 대목은 "이걸 해라"가 아닙니다. "되는 걸 찾아라" 죠.

어떤 제목이 클릭을 부를까
어떤 문구가 사람을 멈추게 할까
어떤 접근이 이 상황에 먹힐까

이건 '실행'이 아니라 '찾기'입니다. 그리고 찾기는 본질적으로 한 방에 안 돼요. 후보를 만들고 → 따져보고 → 조정하고 → 다시. 이 구조, 어디서 봤죠? 네, A/B 테스트. 다들 아는 그것입니다.

루프 엔지니어링은 A/B 테스트의 사고방식을 '일 안으로' 끌고 들어온 겁니다. 차이는 하나. 그 지긋지긋한 반복을, 이제 내가 아니라 AI가 대신 돌려요. "후보 20개 뽑고, 이 기준으로 스스로 점검해서, 통과하는 5개만 가져와"처럼. AI를 '시키면 한 번 해주는 도구'가 아니라 '되는 답을 스스로 찾아내는 일꾼' 으로 바꾸는 거죠.

그래서 믿고 맡길 수 있느냐도 여기서 갈립니다. AI는 매번 확률로 답을 지어내요. 그래서 아무리 똑똑해도 한 번의 답은 어쩌다 틀릴 수 있죠. 한 번 시키면 그 운에 맡기는 거고, 점검하며 여러 번 돌리면 점점 정답에 가까워집니다. 그래서 일 잘하는 사람은 이렇게 생각해요 — "이 모델 멍청하네"가 아니라 "내 루프가 이 실수를 걸러내지 못했네." 더 좋은 모델을 기다릴 게 아니라, 고칠 건 내 루프라는 거죠.

💬 여기까지 읽으셨다면 — 오픈채팅방에서 매일 1개씩 AI 마케팅 인사이트를 받아보세요.

그래서 루프를 어떻게 만드나 — 딱 4가지

거창한 거 아닙니다. AI한테 일 시킬 때 네 가지만 얹으면 그게 루프예요.

목표 — 뭘 끝내야 하나
합격선 — 됐는지 어떻게 아나 (눈으로 셀 수 있는 기준)
수정 규칙 — 통과 못 하면 뭘 바꾸나
종료 조건 — 언제 멈추나 (통과하면 / 몇 번 돌면)

루프는 딱 4가지 — 목표·합격선·수정 규칙·종료 조건

이 중 90%는 두 번째, '합격선' 입니다. "좋아질 때까지"가 왜 망하냐면, 그건 합격선이 아니라 내 머릿속 느낌이거든요. 느낌은 AI가 못 봅니다. AI가 눈으로 확인할 수 있는 한 줄로 꺼내줘야 해요.

❌ 머릿속 느낌	✅ 눈으로 보는 합격선
"제목 좀 더 끌리게"	"제목 28자 이내 + 숫자 1개 포함 + 금지어 0개면 통과"
"본문 깔끔하게"	"한 문단 3줄 이내 + 소제목마다 핵심 1줄로 시작"
"후크 강하게"	"첫 문장에 손실·시간·돈 중 1개 키워드 포함"

합격선을 눈에 보이게 — 머릿속 느낌 vs 눈으로 보는 합격선

오른쪽처럼 한 줄을 주는 순간, AI가 혼자 돕니다. "28자 넘었네, 줄이자", "금지어 들어갔네, 바꾸자" 하면서요. 복붙해서 쓰는 골격은 이겁니다.

[목표]를 해줘.
합격 기준: [한 줄로 셀 수 있는 조건].
기준을 못 넘으면 안 넘은 항목만 고쳐서 다시 검사해.
통과하거나 3번 돌면 결과랑 함께 멈춰서 보고해.

실제로 저는 콘텐츠 카피를 뽑을 때 이 루프를 돕니다. 발행 직전에 제목 길이·금지 표현·숫자 유무를 매번 눈으로 훑던 걸, "제목 28자 이내 + 숫자 1개 + 금지어 0개면 통과, 아니면 그 항목만 고쳐서 다시. 3번 돌면 보고" 한 줄로 넘겼어요. 바뀐 건 하나. 이제 카피가 제 앞에 올 땐 이미 합격선을 넘긴 상태로 옵니다. 글자 세고 금지어 찾던 일은 사라졌죠.

마지막 한 가지만 기억하세요. 점검은 넘겨도, 판단은 안 넘긴다. 합격선을 넘었다고 다 좋은 결과는 아니거든요. "이 방향이 맞나"는 여전히 사람이 봐야 합니다. AI한테는 합격선 넘기는 단순 점검을 맡기고, 최종 판단은 내가 받는 것 — 그게 루프를 안심하고 돌리는 법이에요.

자주 묻는 질문

Q. 루프 엔지니어링, 하네스 엔지니어링이랑 뭐가 다른가요? 하네스는 AI가 일할 '환경'을 갖추는 일이에요 — 쓸 도구, 해도 되는 범위, 점검 장치까지. 루프는 그 환경 안에서 실행 → 점검 → 수정을 반복하는 순환 자체를 설계하는 일이고요. 차를 갖추는 게 하네스, 목적지까지 운전해 가는 게 루프. 둘은 대립이 아니라, 루프가 하네스 안에서 도는 겁니다.

Q. 합격 기준은 어떻게 정하나요? 지금 본인이 결과물을 검수할 때 무의식적으로 보는 것부터 꺼내보세요. 글자 수, 특정 단어 유무, 항목 개수처럼 세거나 찾을 수 있는 것이면 다 합격선이 됩니다. "느낌 좋게"는 빼고요.

Q. 모든 일에 루프를 만들어야 하나요? 아니요. 반복되는데 매번 같은 기준으로 검수하는 일부터. 한 번 하고 마는 일은 루프 만드는 게 더 비쌉니다. 매주·매달 돌아오는 일이 1순위예요.

Q. AI가 자기 검증하는 게 못 미더워요. 그래서 종료 조건에 "3번 돌면 사람한테 보고"를 넣는 겁니다. AI는 합격선 넘기는 단순 점검만 맡고, 최종 판단은 사람이 받죠. 점검을 넘긴다고 판단까지 넘기는 건 아니니까요.