본문으로 건너뛰기
블로그로 돌아가기튜토리얼

AI 슬롭 고치는 법: eval loop 4단계가 '시스템'인 이유 (Hermes Agent)

12분 읽기0

AI 슬롭을 고치는 법: eval loop가 '시스템'인 이유 (Hermes Agent 사례)

"프롬프트를 더 잘 쓰면 되는 거 아닌가요?"

AI로 콘텐츠를 만들다가 결과물이 밋밋하거나 부정확할 때 — 흔히 말하는 AI 슬롭이 나올 때 — 많은 분들이 이렇게 생각하세요. 더 구체적으로, 더 길게, 더 정성껏 프롬프트를 써봅니다. 그런데 다음 날이면 또 비슷한 문제가 생기죠.

Machina(@EXM7777)가 2026-05-30에 발행한 X 아티클 "How To Fix AI Slop (Using Hermes)"는 이 함정을 정확히 짚어요. "slop is not a prompt problem, it is a systems problem." 슬롭은 프롬프트 문제가 아니라 시스템 문제라는 거죠.

이 글에서는 그 시스템 — eval loop — 이 무엇인지, 업계에서 어떻게 쓰이는지, 그리고 Hermes Agent가 이걸 어떻게 에이전트 내부에 제도화했는지 살펴볼게요.

AI 슬롭이란 무엇이고, 왜 프롬프트로 못 고치나

"슬롭(slop)"은 노력·품질·의미가 빠진 채 대량 생산된 AI 콘텐츠를 가리키는 말이에요. 프로그래머 Simon Willison이 2024-05-08 자신의 블로그에서 대중화했고("Slop is the new name for unwanted AI-generated content"), Merriam-Webster와 American Dialect Society 양쪽에서 2025년 올해의 단어로 선정됐을 만큼 지금은 업계 공용어가 됐습니다.

규모도 심각해요. 리서치 업체 Graphite에 따르면 신규 웹 글의 50% 이상이 AI 생성인데요, 2020년 약 5%에서 불과 몇 년 만에 급증한 수치예요. 인터넷이 점점 슬롭으로 채워지고 있는 셈이죠.

프롬프트로 이 문제를 못 고치는 이유는 분산 때문이에요. 같은 프롬프트라도 어떤 날은 훌륭하고, 어떤 날은 슬롭이 나와요. 프롬프트를 조금 더 다듬는 건 한 번의 시도에서 기대값을 약간 올릴 뿐, 매 출력의 품질 편차를 구조적으로 줄이지 못해요. 필요한 건 모든 출력을 발행 전에 걸러내는 항상성 장치 — 즉 시스템입니다.

eval loop 4단계: 생성 채점 게이트 발행, 그리고 루프백

Machina의 아티클 커버에는 터미널 UI로 파이프라인이 그려져 있어요. 내용을 그대로 옮기면 이렇습니다.

GENERATE  → "AI가 초안을 쓴다"
SCORE 0-1 → "벤치마크 대비 0~1로 채점한다"
GATE      → "0.7 이상이면 발행, 미만이면 재작업"
SHIP      → "통과한 깨끗한 출력만 내보낸다"

그리고 GATE에서 탈락한 출력은 빨간 화살표로 다시 GENERATE로 돌아가요. 아티클의 핵심 문장은 이겁니다.

"fail loops back. that loop is the system." 실패는 루프백한다. 그 루프 자체가 시스템이다.

행동 지침도 네 줄로 명확해요: "build a benchmark · score 0 to 1 · gate the ship · close the loop" — 벤치마크를 만들고, 0~1로 점수화하고, 발행을 게이팅하고, 루프를 닫아라.

여기서 0.7이라는 임계값과 0~1 스코어는 아티클이 제시한 예시 수치예요. 절대 법칙이 아니라 "이 정도가 기준선"의 예시입니다. 팀마다, 콘텐츠 타입마다 다르게 설정할 수 있어요.

eval loop 핵심 정의: AI가 생성한 출력을 벤치마크 대비 0~1로 자동 채점하고, 기준 점수(예: 0.7) 미만이면 재생성으로 루프백하며, 통과한 출력만 발행하는 닫힌 품질 관리 사이클. 이 루프를 구조적으로 운영하는 것 자체가 슬롭을 막는 '시스템'이다.

LLM-as-judge: 업계가 eval loop를 돌리는 방식

eval loop는 Machina 한 명의 의견이 아니에요. LLM 엔지니어링 업계의 표준 실천이고, 그 중심에 **LLM-as-judge(LLM이 LLM을 채점)**가 있어요.

작동 방식은 간단해요. 판정자 LLM에게 채점 기준(관련성·충실성·정확성·편향 등)을 알려주고, 생성물을 평가하게 하는 거예요. 사람이 일일이 읽는 대신 수백 개의 출력을 배치로 채점할 수 있죠.

신뢰도와 한계

신뢰도는 꽤 높아요. LLM 판정자와 인간 리뷰어가 일치하는 비율이 약 85%인데, 이는 같은 과제에서 두 인간이 서로 일치하는 비율보다 높다는 보고가 있습니다(Confident AI).

단, 한계도 있어요. 후보 답안 간 점수 차이가 좁을수록 판정자 일관성이 크게 흔들린다는 분석이 있고(arXiv 2512.16041 등), 판정자 자체도 환각할 수 있어요. 그래서 **사람을 루프에 남겨두는 것(human-in-the-loop)**이 공통 권고예요.

PostHog는 아예 "Stop AI slop: Run evals with LLM-as-a-Judge"라는 제목으로 같은 논지를 제시해요. 수백~수천 개의 운영 trace를 배치 테스트해서 슬롭을 사냥하는 워크플로우죠. Langfuse 문서도 eval이 한 지점이 아니라 엔지니어링 루프 전반 — 발행 전(offline)과 발행 후(online) 모두 — 에서 돌아야 한다고 설명합니다.

Hermes Agent: eval loop를 에이전트 내부에 제도화한 사례

아티클 제목에 등장하는 "Hermes"는 NousResearch의 Hermes Agent(github.com/nousresearch/hermes-agent, MIT 라이선스, 슬로건 "The agent that grows with you")입니다.

일반 에이전트와 결정적으로 다른 점은 자기개선 루프예요. 경험에서 스킬을 만들고, 사용 중 그 스킬을 개선하고, 지식을 세션을 넘어 누적해요.

DSPy + GEPA: 실패 trace를 읽어 자기개선

자기진화 모듈 hermes-agent-self-evolution은 **DSPy + GEPA(Genetic-Pareto)**로 스킬·프롬프트·코드를 진화시켜요.

GEPA는 DSPy의 reflective 프롬프트 최적화기예요. 기존 최적화기가 보상을 단일 숫자로 뭉개는 것과 달리, 실행 trace(에러 메시지·추론 로그·피드백)를 자연어로 읽어 "왜 실패했는지"를 진단하고 표적 수정을 제안해요. 후보를 Pareto frontier로 유지해서 탐색과 견고성을 동시에 확보하고요.

논문(Agrawal et al., 2025, arXiv 2507.19457, ICLR 2026 oral)의 수치를 보면:

  • MIPROv2 대비 +13% 성능 향상
  • GRPO 대비 +20% 성능 향상
  • rollout 약 35배 절감

더 좋은 결과를, 훨씬 적은 비용으로 얻는다는 거예요.

Machina는 2026-05-31에 후속 트윗을 남겼어요: "this is the Hermes setup top 1% operators are using to get rid of AI slop" — 좋아요 1,908개, 답글 36개를 받았습니다. 상위 1% 운영자들이 AI 슬롭을 없애려고 쓰는 설정이라는 거죠.

요약하면, Hermes Agent는 Machina의 eval loop를 에이전트 내부의 상시 메커니즘으로 제도화한 사례예요. 실패(낮은 점수·에러)가 곧 다음 개선의 입력이 되는 구조 — Generate→Score→Gate→loop를 에이전트 스스로 돕니다.

1인 운영자가 오늘 시작하는 최소 eval loop

거창하게 시작할 필요 없어요. 최소 eval loop는 세 가지만 있으면 됩니다.

1. 벤치마크 5개 만들기

"좋은 출력"의 기준을 구체적인 질문 5개로 만드세요. 예시:

  • 핵심 주장이 출처와 일치하는가? (예/아니오)
  • 수치가 정확한가? 단위 혼동이 없는가? (예/아니오)
  • 타겟 독자가 바로 실행할 수 있는 내용인가? (1~5점)
  • 브랜드 톤과 일관성이 있는가? (1~5점)
  • 문장이 자연스럽고 구어체인가? (1~5점)

이 5개를 판정자 LLM(예: Claude Sonnet, GPT-4o)에게 넘기면 0~1 스코어로 받을 수 있어요.

2. 게이트 기준 설정하기

Machina의 예시처럼 0.7을 기준으로 삼거나, 팀 상황에 맞게 조정하세요. 처음엔 느슨하게 시작해서 rejection_rate를 보면서 올려가는 게 편해요. rejection_rate가 0에 가까워지면 게이트가 형식적으로 변하고 있다는 신호니까 기준을 높여야 해요.

3. 루프 닫기

탈락한 출력이 어디로 가는지 명확히 정해두세요. 단순하게는 "재생성 1회 → 채점 → 통과하면 발행, 실패하면 사람이 검토"처럼요. 중요한 건 탈락이 발행으로 새는 구멍을 막는 것이에요.

사람을 루프에 남겨두는 것, 잊지 마세요. LLM 판정자도 환각하니까요.

QJC 사례: Generator-Evaluator 페어와 팩트체크 게이트

저희 content-automation 파이프라인은 이미 이 구조로 운영되고 있어요. 참고로 공유할게요.

Generator-Evaluator 페어: 콘텐츠 타입별로 1:1 페어가 돌아요. 예를 들어 thread-writer(작가)와 thread-reviewer(검수자)가 한 쌍이에요. 검수자가 0~100으로 채점하고, score ≥ 70이면 통과, 미만이면 fix_assignments(무엇을 어떻게 고치라는 지시)와 함께 작가에게 되돌려 최대 2회 재생성해요. Machina의 GENERATE→SCORE→GATE→loop와 구조가 같아요.

팩트체크 게이트: 여기에 Phase 1.5·4.5·6.5 팩트체크 게이트가 겹쳐요. P0 이슈(단위 혼동·시제 불일치·365일 이상 된 출처 사용)가 1건이라도 있으면 발행 자체가 차단돼요. "gate the ship"의 강제판이에요.

pipeline-metrics: 각 검수자의 verdict를 시계열로 적재해 rejection_rate를 측정해요. 이게 루프가 형식적으로 변질되는지 — rejection이 0으로 수렴하면 게이트가 유명무실해진 것 — 을 감시하는 계측이에요.

그리고 저는 Hermes Agent를 실제로 운영하고 있어요. 개인 Hermes(~/.hermes/)와 패스트캠퍼스 수강생 봇 Hermes(~/.hermes-fastcampus/)를 완전 격리해서 쓰고 있고요. Machina의 아티클은 "남의 팁"이 아니라 제가 매일 돌리는 도구에 대한 글이었던 셈이에요.

마무리

AI 슬롭을 고치는 건 프롬프트를 더 잘 쓰는 게 아니에요. 생성→채점→게이트→발행의 eval loop를 시스템으로 운영하는 것이에요.

  • 벤치마크를 만드세요
  • 0~1로 점수화하세요
  • 기준 미달은 루프백하세요
  • 루프를 닫으세요

그리고 사람을 루프에 남겨두세요. 그게 전부예요.

오늘 바로 벤치마크 5개 만드는 것부터 시작해보세요. 생각보다 어렵지 않아요.

자주 묻는 질문 (FAQ)

Q: eval loop를 도입하면 콘텐츠 생성 속도가 느려지지 않나요?

처음엔 약간 느려질 수 있어요. 하지만 탈락-재생성 횟수가 줄어들면서 전체 사이클은 오히려 빨라지는 경우가 많아요. 특히 발행 후 수정이나 클레임 대응에 드는 비용과 비교하면, eval loop를 도입하는 게 훨씬 효율적이에요. Hermes Agent처럼 자기개선 루프가 안정되면 reject 비율 자체가 점점 낮아지고요.

Q: LLM-as-judge는 신뢰할 수 있나요? LLM도 틀리지 않나요?

네, LLM 판정자도 환각하고 틀려요. 그래서 "사람을 루프에 남겨두라"는 게 공통 권고예요. LLM-as-judge는 수백 개의 출력을 빠르게 필터링하는 1차 관문이고, 점수 차이가 좁거나 중요한 판단은 사람이 최종 확인해야 해요. LLM 판정자와 인간의 일치율이 약 85%라는 건 "자동화 가능한 부분"이 많다는 뜻이지, 사람을 완전히 대체한다는 뜻이 아니에요.

Q: eval loop를 시작하려면 어떤 도구가 필요한가요?

처음엔 정말 단순하게 시작해도 돼요. Claude API나 OpenAI API에 채점 기준이 담긴 프롬프트를 넣고, 출력을 JSON으로 받아서 점수를 비교하는 스크립트 하나면 충분해요. Langfuse나 PostHog 같은 LLM 관측가능성 도구를 붙이면 trace를 시각화하고 배치 평가를 더 편하게 할 수 있어요. Hermes Agent + DSPy + GEPA는 그보다 더 나아가 자기개선까지 자동화하는 수준이에요.

관련 글

참고자료