어제 이 블로그에 글 다섯 편이 올라왔습니다. 그 다섯 편이 발행되기까지 뒤에서 벌어진 일을 숫자로 적으면 이렇습니다. 첫 글은 린터에서 경고 10건을 맞고 두 번 고쳐서 통과했고, 두 번째 글은 11건, 세 번째는 6건이었습니다. 그런데 네 번째와 다섯 번째 글은 한 번에 통과했습니다. 같은 모델, 같은 세션인데 뒤로 갈수록 첫 시도 품질이 올라간 겁니다. 이 글은 그 차이를 만든 장치, 즉 루프에 대한 이야기입니다. 하네스 엔지니어링이 구조에 대한 글이었다면, 이번엔 그 구조 안에서 도는 엔진입니다.
한 방 생성은 복권이다
LLM에게 일을 시키고 첫 결과물을 그대로 쓰는 방식의 문제는 품질이 낮다는 게 아닙니다. 품질이 복불복이라는 겁니다. 같은 프롬프트도 어떤 날은 바로 쓸 만한 결과가 나오고 어떤 날은 미묘하게 어긋난 게 나옵니다. 확률적 시스템의 본성이라 프롬프트를 아무리 다듬어도 분산 자체는 사라지지 않습니다.
루프는 이 분산을 공정(工程)으로 바꿉니다. 한 번에 검사를 통과할 확률이 라면, 검사하고 고치기를 번 반복했을 때 통과할 확률은 이렇게 됩니다.
첫 시도 통과율이 70%라고 해봅시다. 한 번 더 돌면 91%, 두 번 더 돌면 97%입니다. 각 시도가 독립이라는 가정은 현실에서 정확히 성립하지 않지만(같은 약점은 반복되니까), 방향은 맞습니다. 품질을 모델의 그날 컨디션에 거는 대신, 반복 횟수라는 설계 변수로 옮기는 것. 이게 루프 엔지니어링의 핵심 거래입니다.
| 1회 통과율 p | 루프 1번 | 루프 2번 | 루프 3번 |
|---|---|---|---|
| 50% | 50% | 75% | 88% |
| 70% | 70% | 91% | 97% |
| 90% | 90% | 99% | 99.9% |
루프의 해부, 네 박자
루프 하나는 네 단계로 돕니다. 생성하고, 검사하고, 고치고, 다시 검사한다. 단순해 보이지만 성패는 두 번째 박자에 달려 있습니다.
검사 기준이 "잘 썼는지 봐줘"처럼 주관적이면 루프는 헛돕니다. 모델이 자기 결과물에 후한 점수를 주고 끝나거든요. 기준은 기계가 판정할 수 있어야 합니다. "린터 exit code 0", "스키마 검증 통과", "원본 수치와 100% 일치". 이런 기준은 모델이 자신을 속일 수 없고, 통과 못 하면 루프가 자동으로 한 바퀴 더 돕니다.
📌 좋은 종료 조건의 한 줄 테스트
"이 작업이 끝났는지 사람이 안 보고도 알 수 있는가?" 예라고 답할 수 없으면 루프를 걸 수 없는 작업입니다. 그땐 기준을 먼저 만들거나, 사람 검수를 루프의 한 박자로 설계해야 합니다.
루프의 네 가지 유형
현장에서 쓰는 루프는 대체로 넷 중 하나입니다.
1. 자기 검증 루프. 모델이 자기 결과물을 스스로 점검하고 고칩니다. 이 블로그의 글쓰기 절차에는 "이 글에서 아직 뭐가 AI스러운가?"를 자문하고 한 번 더 고치는 단계가 박혀 있습니다. 비용이 가장 싸지만, 자기가 낸 답을 자기가 채점하는 구조라 한계도 명확합니다. 보조 장치로는 좋고 유일한 검증이면 위험합니다.
2. 도구 검증 루프. 린터, 테스트, 스키마 검증기 같은 결정적(deterministic) 검사기가 판정합니다. 모델의 자비심이 끼어들 틈이 없어서 넷 중 가장 신뢰도가 높습니다. 어제 글 다섯 편을 통과시킨 것도 이 유형입니다. 검사기를 만드는 초기 비용이 들지만, 한 번 만들면 모든 작업에 영구히 적용됩니다.
3. 에이전트 루프. 도구를 호출하고, 결과를 관찰하고, 다음 행동을 정하는 반복. ReAct 패턴이라 불리는 구조로, Claude Code 같은 코딩 에이전트의 작동 원리 자체가 이겁니다. 앞의 두 루프가 "결과물 다듬기"라면 이건 "작업 진행하기"의 루프라서, 보통 그 안에 1·2번 루프가 중첩됩니다.
4. 사람 개입 루프. 기계 판정이 불가능한 지점에 사람을 박습니다. 이 블로그 초안의 TODO_HUNY 주석이 그 예입니다. 실제 경험과 수치는 기계가 검증할 수 없으니, 그 자리를 비워두고 사람이 채워야만 다음 단계로 가게 만든 겁니다. 사람을 "가끔 구경하는 감독"이 아니라 루프의 명시적 박자로 설계하는 게 요령입니다.
실전 일지, 다섯 편의 글이 통과한 길
이론은 여기까지 하고 어제 기록을 그대로 펼쳐봅니다. 다섯 편 모두 같은 루프(초안 생성 → 콘텐츠 린터 → 수정 → 재검사)를 돌았습니다.
| 순서 | 글 | 1차 검사 경고 | 루프 횟수 |
|---|---|---|---|
| 1 | 하네스 엔지니어링 입문 | 10건 (em-dash, AI 상투 표현) | 2회 |
| 2 | 실험·인과추론 논문 5편 | 11건 (em-dash) | 2회 |
| 3 | 생성형 AI 툴킷 12 | 6건 (em-dash) | 2회 |
| 4 | B2B Lead Scoring | 0건 | 1회 통과 |
| 5 | Claude Code deep-dive | 0건 | 1회 통과 |
재밌는 건 수렴 패턴입니다. 모델 자체는 글 사이에 학습하지 않는데도 4번째 글부터 첫 시도가 깨끗해졌습니다. 같은 세션 안에서 "소제목에 em-dash를 쓰면 걸린다"는 패턴이 작업 맥락에 쌓였기 때문입니다. 루프의 부수 효과인데, 검사기의 피드백이 명확할수록 이 세션 내 수렴이 빨라집니다. "10곳에서 걸렸다"보다 "소제목 8곳, 참고 링크 1곳, 제목 1곳"이 다음 시도를 더 크게 바꿉니다.
글 본문만 루프를 돈 것도 아닙니다. 대표 이미지 생성에서도 다섯 번째 글의 이미지가 잘못된 크기(1012x675)로 나오고 OG 이미지가 누락된 걸 검증 단계가 잡아서, 리샘플과 크롭으로 한 바퀴 더 돌고 통과했습니다. 검사가 없었다면 깨진 공유 카드가 그대로 나갔을 겁니다.
루프의 가치는 반복 그 자체가 아니라, 기계가 판정하는 통과 게이트에 있다.
{/* TODO_HUNY: 업무에서 루프 비슷한 걸 돌려본 경험이 있다면 (예: 리포트 자동화에서 숫자 검증 후 재생성, 또는 사람이 반려→재작성 사이클) 한 단락. 없으면 "글쓰기 말고 업무엔 아직 못 붙여봤다"는 솔직한 한 줄도 좋습니다. */}
종료 조건 설계, 무한 루프와 조기 종료 사이
루프를 걸 때 가장 먼저 정할 것은 "언제 멈추나"입니다. 양쪽에 함정이 있습니다.
한쪽은 무한 루프입니다. 검사 기준이 모순되거나(A를 고치면 B가 걸리는 구조) 모델 능력 밖의 기준이면 루프가 영원히 돕니다. 그래서 최대 반복 횟수는 필수이고, 한도에 닿으면 "통과 실패"를 사람에게 올리는 탈출구가 있어야 합니다. 보통 3회 안에 수렴하지 않으면 루프를 더 돌릴 게 아니라 기준이나 지시서를 고칠 차례입니다.
다른 쪽은 비용입니다. 루프 한 바퀴는 공짜가 아닙니다. 토큰, 시간, API 호출이 매번 듭니다. 모든 산출물에 5회 루프를 거는 건 과잉이고, 결과물의 중요도에 따라 횟수를 차등하는 게 맞습니다. 외부로 나가는 보고서는 깊게, 내부 메모는 얕게.
그리고 조용히 무서운 세 번째 함정이 있습니다. 검사기를 속이는 최적화. 측정이 목표가 되면 측정이 망가진다는 Goodhart의 법칙은 루프에도 적용됩니다. "em-dash를 쓰지 마라"는 검사를 통과하려고 모델이 더 어색한 문장 부호를 남발한다면, 검사는 통과해도 목표(자연스러운 글)는 멀어진 겁니다. 검사 항목이 늘어날수록 가끔 사람이 최종 결과물을 직접 읽어보는 표본 검사를 루프 바깥에 둬야 하는 이유입니다.
마케팅 업무에 이식하기
루프 설계는 코딩보다 마케팅 운영에 더 절실할 수 있습니다. 산출물이 외부로 나가는 일이 많으니까요. 시작점이 될 만한 조합 둘을 적어둡니다.
| 업무 | 생성 | 기계 검사 | 통과 못 하면 |
|---|---|---|---|
| 주간 리포트 | LLM이 지표 코멘트 작성 | 인용된 모든 수치가 원본 쿼리 결과와 일치하는지 대조 | 불일치 수치 명시하고 재작성 |
| 광고 카피 변형 | LLM이 변형 20개 생성 | 금칙어 사전 매칭 + 채널 글자수 제한 | 걸린 항목만 재생성 |
공통 구조가 보일 겁니다. 사람이 눈으로 하던 검사를 기계 검사로 바꾸고, 실패를 "반려"가 아니라 "자동 재시도"로 연결하는 것. 사람의 역할은 모든 산출물 검사에서 검사 기준의 설계와 표본 확인으로 올라갑니다. 생성형 AI 툴킷에서 소개한 프롬프트들도 이 루프 안에 넣을 때 진짜 안정성이 생깁니다.
하네스와 루프, 구조와 엔진
시리즈의 그림을 한 번 정리하겠습니다. 하네스가 지시서·도구·검증·기억이라는 구조라면, 루프는 그 구조 안에서 일이 실제로 굴러가게 하는 동작 방식입니다. 하네스 없는 루프는 기준 없이 헛돌고, 루프 없는 하네스는 한 방 생성의 복불복으로 돌아갑니다. 둘이 합쳐져야 "에이전트에게 일을 맡긴다"는 말이 성립합니다.
그리고 루프는 하네스 자체에도 적용됩니다. 사고가 나면 검사 룰을 추가하고, 다음 작업에서 그 룰이 걸리는지 보고, 또 고치는 것. 어제 린터에 탈AI 경고 룰을 추가한 것도, 그 룰에 제가 쓴 글이 처음으로 걸린 것도, 결국 하네스를 키우는 더 큰 루프의 한 바퀴였습니다.
마치며
LLM 도입에서 품질 문제를 만나면 대부분 프롬프트를 다듬는 쪽으로 갑니다. 그것도 필요하지만, 경험상 더 확실한 개선은 루프에서 나옵니다. 기계가 판정할 수 있는 통과 기준 하나를 만들고, 실패를 자동 재시도로 연결하는 것. 70%짜리 첫 시도를 97%짜리 공정으로 바꾸는 데 필요한 건 더 좋은 모델이 아니라 잘 설계된 반복입니다.
다음에 AI 결과물이 미덥지 않다면 프롬프트를 고치기 전에 물어보세요. "이 작업의 통과 기준을 기계가 판정할 수 있나?" 그 답이 루프를 걸 수 있는지 없는지를 정합니다.
Top comments (0)