루프 엔지니어링: AI에게 일 대신 루프를 줘라
AI한테 일 시켜놓고 결국 내가 다시 붙잡고 앉아 있던 적, 있으시죠. 분명 똑똑한 모델인데 결과물은 한 번에 안 나옵니다. "더 좋게 고쳐줘" 하면 무한히 돌거나, 한 번 손대고 멋대로 멈춰버리고. 저도 한참을 그랬어요.
요즘 AI를 좀 깊게 쓰는 사람들 사이에서 '루프 엔지니어링(loop engineering)' 이라는 말이 돕니다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링… 그 다음 차례라는 거죠. 쉽게 말하면, AI가 스스로 "됐나?"를 확인하고 안 됐으면 알아서 다시 하게 만드는 것. 처음엔 저도 "또 새 단어 만들었네" 했습니다. 그런데 파보니까, 이게 제가 위에서 겪던 그 답답함의 정확한 정답이더라고요.
오늘 풀어볼 건 딱 하나. 루프가 대체 뭐고, 한 번 시키는 것과 뭐가 그렇게 다른가. 그래서 왜 이게 "AI 잘 쓰는 사람"과 "AI한테 끌려다니는 사람"을 가르는지 봅니다. 용어 자랑이 아니라, 본인 일에 바로 쓰라고 쓰는 글이에요.
프롬프트 → 컨텍스트 → 하네스 → 루프, 한 줄씩
복잡해 보이지만 줄 세우면 간단합니다. 다 "AI한테 어떻게 일 시킬까"의 진화 단계거든요.
- 프롬프트 엔지니어링: 뭐라고 물을까 (질문을 잘 짜기)
- 컨텍스트 엔지니어링: 뭘 쥐여줄까 (필요한 정보·자료를 넣어주기)
- 하네스 엔지니어링: 어떤 환경에서 굴릴까 (AI가 쓸 도구, 해도 되는 일의 범위, 결과를 점검하는 장치까지 갖춘 '작업 환경')
- 루프 엔지니어링: 그 환경 안에서 어떻게 돌릴까 (실행 → 점검 → 수정 → 반복의 순환)
비유하면 하네스가 '차 한 대'입니다. 엔진(모델)에 핸들, 브레이크, 차선, 경고등까지 갖춘 시스템이죠. 그런데 좋은 차를 줘도 한 바퀴 굴리고 멈추면 목적지엔 못 갑니다. 그 차로 목적지까지 실제로 굴러가는 '운전', 그게 루프예요. 차를 갖추는 게 하네스, 그 차로 도착할 때까지 달리는 게 루프.
왜 하필 지금 루프가 화제일까요. 모델이 이미 충분히 똑똑해졌기 때문입니다. 같은 엔진(모델)이라도, 이제 결과를 가르는 건 "더 똑똑한 모델"이 아니라 "어떻게 돌리느냐" 예요.
그리고 이건 누가 지어낸 유행어가 아닙니다. Claude를 만든 앤트로픽이 공식 문서에서 AI 에이전트가 일하는 방식을 딱 이 순환으로 정의했거든요. 맥락 수집 → 실행 → 검증 → 반복(gather → act → verify → repeat).
심지어 이렇게 못박았죠. "자기 결과를 스스로 점검하고 고칠 수 있는 에이전트가 근본적으로 더 믿을 만하다. 실수가 커지기 전에 잡아내고, 어긋나면 스스로 바로잡으며, 반복할수록 나아지기 때문이다." 오늘 할 얘기가 사실 다 이 한 문장 안에 있습니다.
왜 1. 한 번의 출력은 '추측', 루프는 '과정'
이게 핵심 중의 핵심입니다.
AI한테 일을 한 번 시키는 건, 주사위를 한 번 굴리는 것. 좋은 게 나올 수도, 어정쩡한 게 나올 수도 있죠. 그게 그 한 번의 '추측'입니다. 다음에 더 나아진다는 보장이 없어요. 추측은 쌓이지 않으니까요.
루프는 다릅니다. 결과를 내고 → 스스로 기준에 비춰보고 → 모자라면 그걸 딛고 다시 합니다. 한 번의 시도가 다음 시도의 발판이 되죠. 추측은 안 쌓이지만, 과정은 쌓인다.
뭔가 만들어 본 사람은 이 감각 압니다. 첫 초안이 최고인 경우는 없잖아요. 쓰고, 들여다보고, 고치고를 반복하면서 좋아지죠. 그 '초안 → 검토 → 다시 쓰기'가 바로 루프입니다.
그런데 우리가 AI한테 일을 시킬 땐 이상하게 그 검토·다시쓰기 단계를 통째로 빼먹고 한 방에 받으려고 해요. 그래놓고 "AI 결과물은 영 별로네" 하는 거죠. 루프는 그 빠진 단계를 다시 끼워 넣는 일입니다.
왜 2. 품질은 '내 시간'이 아니라 'AI가 반복한 횟수'에서 나온다
여기서 진짜 이득이 갈립니다.
루프가 없으면, 결과물 품질은 "내가 몇 번 들여다봤는가"에 묶입니다. 한 단계 더 좋게 만들려면 내가 한 번 더 봐야 하고, 한 번 더 고치라고 시켜야 하죠. 품질이 내 시간에 비례하는 구조. 그래서 AI를 써도 시간이 안 줄어요. 일은 AI가 하는데 검토는 내가 다 하니까요.
루프가 있으면, 품질은 "AI가 몇 번 반복했는가"에 묶입니다. 그리고 그 반복은 내 시간이 아니라 AI의 시간이라, 사실상 공짜예요. 내 시간을 거의 안 쓰고 품질이 올라간다. 이게 핵심이에요. 품질을 '내가 검토한 횟수'에서 'AI가 반복한 횟수'로 옮기는 것.
이게 진짜 위임입니다. 지난 글에서 AI에게 일을 넘기는 3단계: 쪼개기·맡기기·남기기를 정리했는데, 거기서 한 걸음 더 들어가야 완성되는 게 이거예요. 실행만 넘기는 게 아니라 '점검과 수정까지' 넘기는 것.
실행만 넘기면 점검은 내 몫으로 남아서 결국 내가 병목이 됩니다. 점검까지 넘겨야 비로소 AI가 혼자 돌고, 나는 다 된 것만 받죠. 그 '점검까지 넘기는 장치'가 루프고요.
왜 3. 진짜 어려운 일은 '하기'가 아니라 '되는 걸 찾기'
곰곰이 보면, 어떤 일이든 진짜 어려운 대목은 "이걸 해라"가 아닙니다. "되는 걸 찾아라" 죠.
- 어떤 제목이 클릭을 부를까
- 어떤 문구가 사람을 멈추게 할까
- 어떤 접근이 이 상황에 먹힐까
이건 '실행'이 아니라 '찾기'입니다. 그리고 찾기는 본질적으로 한 방에 안 돼요. 후보를 만들고 → 따져보고 → 조정하고 → 다시. 이 구조, 어디서 봤죠? 네, A/B 테스트. 다들 아는 그것입니다.
루프 엔지니어링은 A/B 테스트의 사고방식을 '일 안으로' 끌고 들어온 겁니다. 차이는 하나. 그 지긋지긋한 반복을, 이제 내가 아니라 AI가 대신 돌려요. "후보 20개 뽑고, 이 기준으로 스스로 점검해서, 통과하는 5개만 가져와"처럼. AI를 '시키면 한 번 해주는 도구'가 아니라 '되는 답을 스스로 찾아내는 일꾼' 으로 바꾸는 거죠.
그래서 믿고 맡길 수 있느냐도 여기서 갈립니다. AI는 매번 확률로 답을 지어내요. 그래서 아무리 똑똑해도 한 번의 답은 어쩌다 틀릴 수 있죠. 한 번 시키면 그 운에 맡기는 거고, 점검하며 여러 번 돌리면 점점 정답에 가까워집니다.
그래서 일 잘하는 사람은 이렇게 생각해요. "이 모델 멍청하네"가 아니라 "내 루프가 이 실수를 걸러내지 못했네." 더 좋은 모델을 기다릴 게 아니라, 고칠 건 내 루프라는 거죠.
💬 여기까지 읽으셨다면, 오픈채팅방에서 매일 1개씩 AI 마케팅 인사이트를 받아보세요.
그래서 루프를 어떻게 만드나: 딱 4가지
거창한 거 아닙니다. AI한테 일 시킬 때 네 가지만 얹으면 그게 루프예요.
- 목표: 뭘 끝내야 하나
- 합격선: 됐는지 어떻게 아나 (눈으로 셀 수 있는 기준)
- 수정 규칙: 통과 못 하면 뭘 바꾸나
- 종료 조건: 언제 멈추나 (통과하면 / 몇 번 돌면)
이 중 90%는 두 번째, '합격선' 입니다. "좋아질 때까지"가 왜 망하냐면, 그건 합격선이 아니라 내 머릿속 느낌이거든요. 느낌은 AI가 못 봅니다. AI가 눈으로 확인할 수 있는 한 줄로 꺼내줘야 해요.
| ❌ 머릿속 느낌 | ✅ 눈으로 보는 합격선 |
|---|---|
| "제목 좀 더 끌리게" | "제목 28자 이내 + 숫자 1개 포함 + 금지어 0개면 통과" |
| "본문 깔끔하게" | "한 문단 3줄 이내 + 소제목마다 핵심 1줄로 시작" |
| "후크 강하게" | "첫 문장에 손실·시간·돈 중 1개 키워드 포함" |
오른쪽처럼 한 줄을 주는 순간, AI가 혼자 돕니다. "28자 넘었네, 줄이자", "금지어 들어갔네, 바꾸자" 하면서요. 복붙해서 쓰는 골격은 이겁니다.
[목표]를 해줘.
합격 기준: [한 줄로 셀 수 있는 조건].
기준을 못 넘으면 안 넘은 항목만 고쳐서 다시 검사해.
통과하거나 3번 돌면 결과랑 함께 멈춰서 보고해.
실제로 저는 콘텐츠 카피를 뽑을 때 이 루프를 돕니다. 발행 직전에 제목 길이·금지 표현·숫자 유무를 매번 눈으로 훑던 걸, "제목 28자 이내 + 숫자 1개 + 금지어 0개면 통과, 아니면 그 항목만 고쳐서 다시. 3번 돌면 보고" 한 줄로 넘겼어요.
바뀐 건 하나. 이제 카피가 제 앞에 올 땐 이미 합격선을 넘긴 상태로 옵니다. 글자 세고 금지어 찾던 일은 사라졌죠.
마지막 한 가지만 기억하세요. 점검은 넘겨도, 판단은 안 넘긴다. 합격선을 넘었다고 다 좋은 결과는 아니거든요. "이 방향이 맞나"는 여전히 사람이 봐야 합니다. AI한테는 합격선 넘기는 단순 점검을 맡기고, 최종 판단은 내가 받는 것, 그게 루프를 안심하고 돌리는 법이에요.
자주 묻는 질문
Q. 루프 엔지니어링, 하네스 엔지니어링이랑 뭐가 다른가요? 하네스는 AI가 일할 '환경'을 갖추는 일이에요. 쓸 도구, 해도 되는 범위, 점검 장치까지. 루프는 그 환경 안에서 실행 → 점검 → 수정을 반복하는 순환 자체를 설계하는 일이고요. 차를 갖추는 게 하네스, 목적지까지 운전해 가는 게 루프. 둘은 대립이 아니라, 루프가 하네스 안에서 도는 겁니다.
Q. 합격 기준은 어떻게 정하나요? 지금 본인이 결과물을 검수할 때 무의식적으로 보는 것부터 꺼내보세요. 글자 수, 특정 단어 유무, 항목 개수처럼 세거나 찾을 수 있는 것이면 다 합격선이 됩니다. "느낌 좋게"는 빼고요.
Q. 모든 일에 루프를 만들어야 하나요? 아니요. 반복되는데 매번 같은 기준으로 검수하는 일부터. 한 번 하고 마는 일은 루프 만드는 게 더 비쌉니다. 매주·매달 돌아오는 일이 1순위예요.
Q. AI가 자기 검증하는 게 못 미더워요. 그래서 종료 조건에 "3번 돌면 사람한테 보고"를 넣는 겁니다. AI는 합격선 넘기는 단순 점검만 맡고, 최종 판단은 사람이 받죠. 점검을 넘긴다고 판단까지 넘기는 건 아니니까요.
함께 읽으면 좋은 글:
