이 글은 AI가 생성하는 결과물의 품질 문제, 즉 'Slop'을 해결하기 위한 평가 루프(Eval Loop)의 중요성과 구체적인 구축 방법을 설명합니다. 단순히 프롬프트 개선이나 모델 변경으로는 근본적인 해결이 어렵다는 점을 강조하며, Hermes라는 오픈소스 에이전트를 활용해 모든 AI 결과물을 표준에 따라 평가하고 관리하는 시스템을 제시하고 있습니다. AI 결과물의 품질을 일관되게 유지하고 싶다면 이 글이 큰 도움이 될 거예요! 🛠️📈

1. AI 결과물 품질 문제(Slop)의 본질 🤔

많은 사람들이 AI 결과물의 품질이 떨어질 때마다 프롬프트를 개선하고, 더 비싼 모델을 사용하고, 더 길게 지시사항을 작성하거나, 기억 기능을 활성화하고, 방대한 컨텍스트 파일을 구축하는 등 다양한 노력을 해왔을 거예요. 하지만 저자는 이런 시도들이 결국 "망가진 적이 없는 레이어를 계속 고치는 것"이라고 지적합니다. AI 결과물 품질 저하, 즉 'Slop'은 프롬프트 문제가 아니라 시스템 문제라는 거죠. 마치 불량품을 생산하는 공장이 작업자 문제가 아니라 품질 관리 문제를 겪는 것과 같다고 설명합니다. 아무도 제품이 출하되기 전에 품질을 확인하지 않기 때문에 문제가 발생한다는 거예요.

저자는 "더 나은 프롬프트, 더 큰 모델, 그리고 기억 기능이 왜 슬롭을 영원히 죽이지 못하는지, 그리고 실제로 효과가 있는 한 가지 레이어"가 무엇인지, 그리고 "슬롭이 숨어있는 두 가지 장소(콘텐츠 및 제품 결과물)와 왜 해결책이 동일한지"에 대해 자세히 설명해 줍니다. 결국 AI 결과물의 품질 문제는 "모델이 좋은 작업을 생성할 수 없다는 것이 아니라, 중요한 사람에게 도달하기 전에 좋은 작업과 나쁜 작업을 구별할 방법이 없다"는 데서 오는 것입니다.

"Slop은 프롬프트 문제가 아니라 시스템 문제입니다. 공장에서 불량품을 출하하는 것이 작업자 문제가 아니라 품질 관리 문제인 것과 마찬가지로, 건물에서 나가기 전에 아무도 출력을 확인하지 않습니다."

AI 모델은 비결정적이기 때문에 같은 프롬프트를 두 번 실행하면 두 가지 다른 결과가 나옵니다. 심지어 '완벽한' 프롬프트조차도 특정 비율의 실행에서는 불량한 결과물을 생성할 수 있고, 사용자는 클라이언트나 사용자가 문제를 발견하기 전까지는 어떤 실행이 문제인지 알 수 없습니다.

"모델은 비결정적입니다. 같은 프롬프트를 두 번 실행하면 두 가지 다른 답이 나옵니다. 이는 심지어 완벽한 프롬프트조차도 일부 실행에서 슬롭을 생성하고, 클라이언트나 사용자가 그것을 보기 전까지는 어떤 실행인지 알 수 없다는 것을 의미합니다."

2. 'Slop'이 숨어있는 두 가지 영역 🕵️‍♀️

AI 결과물의 품질 문제는 크게 두 가지 영역에서 발생하며, 놀랍게도 그 해결책은 동일하다고 합니다.

2.1. 콘텐츠 Slop 📝

여기에는 AI로 생성하여 자신의 이름으로 게시하는 모든 콘텐츠가 포함됩니다. 예를 들어 트윗, 기사, 이메일, 랜딩 페이지, 블로그 게시물 등이 있습니다. 이러한 콘텐츠 슬롭은 기술적으로는 문제가 없지만 "완전히 공허한" 작업처럼 보일 수 있어요. 겉으로는 괜찮아 보이지만 실제로는 알맹이가 없는 거죠. 각각의 개별 조각은 보낼 때 괜찮아 보였기 때문에 왜 실패했는지 설명하기 어렵습니다.

2.2. 제품 Slop 🛠️

이는 사용자들이 실제로 사용하는 AI 기능, 에이전트, 챗봇, 지원 응답, 데이터 추출 파이프라인 등을 의미합니다. 여기서 슬롭은 "완전한 확신을 가지고 전달된 잘못된 답변, 환각적인 숫자, 깨진 JSON 페이로드, 브랜드에 맞지 않는 어조"와 같은 형태로 나타납니다. 데모에서는 훌륭했지만 배포 후 조용히 품질이 저하되는 경우가 많습니다.

"콘텐츠 슬롭과 제품 슬롭은 모두 측정되지 않은 AI 결과물이 중간에 게이트 없이 바로 청중에게 가는 것입니다."

이 두 가지 유형의 슬롭은 동일한 문제에서 비롯되며, "Hermes"에서 구축하는 평가 루프는 동일한 방식으로 두 가지를 모두 평가할 수 있습니다. 콘텐츠 슬롭은 시끄럽게 망신을 주지만, 제품 슬롭은 조용히 사용자들을 떠나가게 만든다는 차이가 있을 뿐입니다.

3. 평가 루프(Eval Loop)란 무엇인가요? 🔄

평가 루프는 "AI 결과물을 표준에 따라 자동으로, 매번, 출하 전후에 평가하는 반복 가능한 테스트"라고 저자는 정의합니다. 아주 간단하죠? 하지만 AI를 사용하는 대부분의 사람들이 이 레이어를 놓치고 있다는 게 문제입니다.

기본적인 평가 루프는 다음과 같은 단계로 이루어집니다.

1. 결과물 생성: AI가 어떤 결과물을 만들어냅니다.
2. 벤치마크 점수화: 사전에 정의한 벤치마크에 따라 결과물에 점수를 매깁니다.
3. 불량 결과물 포착: 기준 미달의 결과물을 걸러냅니다.
4. 실패 원인 수정: 왜 낮은 점수가 나왔는지 분석하고 수정합니다.
5. 재점수화 및 통과: 다시 점수를 매기고, 통과한 결과물만 다음 단계로 넘어갑니다.

"평가 루프는 AI 결과물을 표준에 따라 자동으로, 매번, 출하 전후에 평가하는 반복 가능한 테스트입니다."

소프트웨어 엔지니어들은 오래전부터 '테스팅'이라는 이름으로 이러한 과정을 거쳐왔습니다. 테스트 없이 코드를 배포하는 일은 상상할 수 없지만, AI 업계에서는 모델에서 사용자에게 바로 결과물을 전달하는 경우가 흔하다는 거죠. 평가 루프가 없는 이유는 AI를 구축하는 사람들이 콘텐츠, 영업, 제품 출신이 많고, 엔지니어링 배경이 아니기 때문이라고 저자는 설명합니다. 이들에게 "결과물에 대한 테스트를 작성하라"는 개념이 낯설 수 있다는 것이죠.

3.1. 평가 루프가 작동하는 세 가지 시점 🎯

효과적인 평가 루프는 다음 세 곳에서 실행되어야 합니다.

1. 출하 전: 새로운 프롬프트나 모델을 기존 테스트 케이스에 대해 실행하여 이전보다 품질이 저하되지 않았는지 확인합니다. 이는 회귀 테스트(Regression Testing)로, 하나의 문제를 해결하려다 다른 세 가지를 조용히 망가뜨리는 것을 방지합니다.
2. 런타임 시: 결과물이 생성되는 즉시 점수를 매기고, 조건부 로직을 사용하여 사용자에게 도달하기 전에 실패를 포착합니다. 이는 보호 장치(Guardrail) 역할을 합니다.
3. 운영 환경(Production)에서: 실제 실행의 샘플을 지속적으로 평가하여 품질 저하가 시작되는 즉시 감지합니다. 고객이 불평하기 몇 주 전에 문제를 알아차릴 수 있게 해줍니다.

4. 품질 벤치마크 구축하기 📏

품질 벤치마크는 콘텐츠든 제품이든 상관없이 세 가지 핵심 요소로 구성됩니다.

1. 테스트 케이스 (Test Cases): '좋은' 결과물이 어떤 것인지 보여주는 실제 입력과 기대 출력 쌍입니다. (Ground Truth)

   • 콘텐츠의 경우: 가장 좋은 콘텐츠 20~50개를 모아 '골드 스탠더드'로 삼습니다. 당신이 이미 최고 수준에서 달성했던 기준을 추출하는 것이죠.
   • 제품의 경우: 실제 사용자 세션 로그에서 얻은 실제 입력값을 사용합니다. 출시 당시의 '해피 경로' 예시가 아니라, 당신의 시스템을 망가뜨리는 '이상한' 케이스들이 여기에 포함되어야 합니다.

2. 메트릭 (Metrics): 결과물을 0에서 1 사이의 점수로 변환하는 방법입니다.

   • 콘텐츠의 경우: 루브릭(Rubric)을 사용합니다. 예를 들어, 다음 네 가지 기준을 제안합니다.
     • 구체적인 실행 방법을 설명하는가?
     • 모든 청중이 이해할 수 있는가?
     • 구조화되어 있고 재현 가능하며 단계별로 설명되는가?
     • 새롭고 독창적인가?
     • 이 모든 것 위에, "누군가 이 글을 북마크하고 나중에 구현하기 위해 다시 돌아올 것인가?"라는 메타 기준이 중요하다고 강조합니다.

       "메타 기준: 누군가 이것을 북마크하고 나중에 구현하기 위해 다시 돌아올 것인가? 답이 '아니오'라면, 글이 아무리 깔끔하게 읽히더라도 그것은 슬롭입니다."

   • 제품의 경우: 작업에 맞는 메트릭을 사용합니다. 정확한 레이블이 필요한 경우 '정확한 일치', 구조가 중요한 경우 '유효성 검사기', 개방형 결과물인 경우 '의미적 유사성 + 판정자' 등을 활용합니다. 중요한 것은 숫자를 반환해야 한다는 것입니다.

3. 임계값 (Threshold): 이 선 아래의 결과물은 절대 출하되지 않도록 하는 기준선입니다.

   • 0.7이 합리적인 시작점이라고 제안하며, 0.7 미만은 재작업하거나 폐기해야 합니다. 임계값은 "좋아 보인다는 이유로 0.6점짜리를 통과시키지 않을 때만 작동"한다고 강조합니다. 중요한 것은 감정에 의존하지 않고 숫자에 따라 결정하는 것입니다.

5. Hermes에 평가 루프 구축하기: 6단계 🛠️

Hermes는 평가 루프를 위한 별도의 '품질 대시보드' 같은 기능은 제공하지 않지만, 대신 평가 루프를 직접 조립할 수 있는 기본 구성 요소를 제공합니다.

5.1. 1단계: Hermes를 설치하고 접근 가능한 상태로 만듭니다. 📲

Telegram과 같은 메시징 플랫폼에 Hermes를 연결하는 것이 중요합니다. 그래야 Hermes가 백그라운드에서 작업을 수행하다가 결정이 필요할 때 Slack이나 Telegram으로 알림을 보낼 수 있기 때문입니다.

5.2. 2단계: 골드 스탠더드를 Hermes의 메모리에 로드합니다. 🧠

Hermes는 지속적인 메모리 기능을 가지고 있어서, 당신의 벤치마크에 사용된 최고의 콘텐츠 20~50개를 한 번만 로드하면 에이전트의 장기 기억으로 저장됩니다. 이는 스크린샷이나 오래된 초안에 흩어져 있던 '진실'을 에이전트가 언제든지 쿼리할 수 있게 해줍니다.

5.3. 3단계: 루브릭을 판정자 스킬로 만듭니다. 🧑‍⚖️

Hermes에게 영어로 루브릭과 결과물을 받아서 기준별로 0~1점 점수와 한 줄짜리 이유를 반환하는 스킬을 만들도록 지시합니다. 이것이 바로 'LLM-as-a-judge'입니다. AI가 당신의 AI를 평가하는 셈이죠. 이 스킬은 Hermes의 절차적 기억으로 저장되어 한 번 인코딩되면 모든 결과물을 영원히 평가하게 됩니다.

"이것이 바로 LLM-as-a-judge입니다. 당신의 LLM을 평가하는 에이전트이며, 날카로운 루브릭을 가진 모델은 당신보다 더 일관된 비평가입니다. 왜냐하면 그것은 그 작품에 자아가 없고 당신이 몰래 자랑스러워하는 한 문장에 대한 애착도 없기 때문입니다."

5.4. 4단계: 테스트 스위트를 스킬로 만듭니다. 🧪

테스트 케이스와 메트릭 함수를 Hermes가 보유하고 버전 관리하는 스킬로 만듭니다. 분류를 위한 '정확한 일치', 추출을 위한 '정규 표현식', 구조를 위한 'JSON 및 키-값 유효성 검사기', 생성형 결과물을 위한 '의미적 유사성' 등 필요한 메트릭 라이브러리를 구축합니다. Hermes는 당신이 작업을 설명하면 채점 코드를 스스로 작성합니다.

5.5. 5단계: 회귀 테스트 및 승인 버튼으로 출하를 통제합니다. 🚦

새로운 프롬프트, 모델 변경, 파이프라인 조정 등 어떤 변경이든 테스트 스위트를 트리거하도록 설정합니다. Hermes는 모든 케이스를 재실행하고, 기준선과의 점수 차이를 계산한 다음, "점수가 0.81에서 0.74로 떨어졌습니다. 두 케이스에서 회귀가 발생했습니다. 승인하시겠습니까?"와 같은 알림을 Slack으로 보냅니다. 당신이 버튼을 눌러야만 진행되도록 하는 거죠.

5.6. 6단계: Cron으로 운영 환경을 모니터링하고 루프를 완성합니다. 🔄

Hermes의 내장 Cron 기능을 사용하여 실제 실행을 샘플링하고, 동일한 판정자 스킬로 점수를 매기고, 품질이 떨어지는 순간 즉시 DM을 보내도록 예약합니다. 이는 고객이 불평하기 몇 주 전에 품질 저하를 파악할 수 있게 해줍니다.

더욱 놀라운 점은, Slack에서 품질이 나쁜 결과물에 엄지손가락을 아래로 표시하면, Hermes가 이를 새로운 테스트 케이스로 스위트 스킬에 다시 기록한다는 것입니다. 실패한 실행은 영구적인 검사 항목이 되며, Hermes의 자기 개선 습관 덕분에 매주 테스트 스위트가 자체적으로 강화됩니다.

"Hermes가 자기 개선을 한다는 것이 특징입니다. 일주일마다 스위트가 스스로 강화되어, 당신이 잠든 사이에도 기준치가 올라갑니다."

결론 🌟

AI 결과물의 일관된 품질을 확보하지 못하는 이유는 당신이 프롬프트를 잘 만들지 못하거나 모델이 충분히 똑똑하지 않아서가 아닙니다. 바로 품질 단계가 없는 생성 단계만 운영하고 있기 때문입니다. 시스템의 절반만 구축해놓고 나머지 작동하는 절반을 탓하고 있는 거죠.

진정한 해결책은 더 나은 프롬프트가 아니라, 누락된 레이어를 추가하는 것입니다.

• '좋은 것'이 무엇인지 정의하고
• 그것을 숫자로 변환하고
• 모든 결과물을 그 기준에 따라 평가하며
• 기준 미달의 모든 것을 걸러내고
• 매주 기준치가 올라가도록 루프를 완성하는 것.

이제 이 레이어는 미래의 프로젝트가 아니라, 당신의 컴퓨터에서 실행되는 Hermes 에이전트 내에서 6단계만 거치면 구현할 수 있습니다. 이렇게 하면 'Slop'은 무작위로 발생하는 문제가 아니라, 마치 실제 공장이 고객에게 도달하기 전에 결함을 잡아내는 것처럼, 항상 출하 전에 포착할 수 있는 문제가 될 것입니다.

"프롬프트는 결코 시스템이 아니었습니다. 평가 루프가 시스템이고, Hermes는 그 시스템이 작동하는 곳이며, 이제 당신도 그것을 갖게 되었습니다."