简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

헤르메스를 사용해 'AI 냄새'를 없애는 방법

이 글을 읽으려면 42 분

AI가 직접 결과물을 내놓지 못하게 하세요. 모든 출력은 먼저 품질 검사를 통과해야 합니다.

원문 제목: How To Fix AI Slop (Using Hermes)
원문 저자: @EXM7777
편역: Peggy

편집자 주: AI 생성 콘텐츠의 '쓰레기화'는 종종 프롬프트가 충분히 좋지 않거나, 모델이 충분히 강력하지 않거나, 컨텍스트가 충분히 완전하지 않기 때문이라고 여겨집니다. 하지만 이 글은 엔지니어링 시스템에 더 가까운 판단을 제시합니다. 문제는 입력 측이 아니라 출력 측에 있다는 것입니다.

저자는 많은 사람들이 프롬프트를 다시 작성하고, 모델을 업그레이드하고, 메모리를 활성화하고, 컨텍스트 파일을 쌓아 올리는 등 여러 시도를 반복했지만 AI 슬롭이 여전히 반복적으로 나타난다고 생각합니다. 그 이유는 이러한 방법들이 모두 '생성' 자체를 최적화하는 데 초점을 맞추고 있지만, 안정적인 품질 관리 메커니즘을 구축하지 않았기 때문입니다. 공장이 제품 출고 여부를 작업자의 감각에만 의존하지 않는 것처럼, AI 출력도 모델에서 사용자에게 직접 흘러가서는 안 되며, 테스트, 평가 및 차단이 부족합니다.

이 글의 핵심 솔루션은 Hermes라는 오픈소스 Agent에 eval loop를 구축하는 것입니다. 먼저 '좋은 출력'이 무엇인지 정의하고, 그 기준을 정량화 가능한 평가 체계로 변환한 후, 출시 전, 런타임 및 프로덕션 환경에서 지속적으로 감지합니다. 콘텐츠 제작에서의 공허한 표현이든, 제품에서의 환각 답변, 형식 오류 및 경험 저하이든, 본질적으로 측정되지 않은 AI 출력이 직접 수신자에게 도달하는 것입니다.

따라서 진정으로 중요한 것은 더 긴 프롬프트를 작성하는 것이 아니라, 누락된 품질 시스템 계층을 보완하는 것입니다. 테스트 사례, 평가 지표, 임계값, 회귀 테스트, 승인 버튼 및 프로덕션 환경 모니터링이 함께 이 메커니즘을 구성합니다. 이는 'AI 출력 품질'을 주관적인 느낌에서 관찰, 비교 및 수정 가능한 숫자로 만듭니다.

다음은 원문입니다:

어떤 사람들은 지속적으로 최고의 소프트웨어를 제공하고, 훌륭한 콘텐츠를 작성하거나, 놀라운 이미지를 생성하는 것처럼 보입니다. 여기에는 이유가 있습니다.

그들은 eval loop를 채택했지만, 당신은 아직 그렇지 않습니다.

당신은 더 나은 프롬프트를 시도하고, 더 비싼 모델로 교체하고, 더 긴 지침을 작성하고, 메모리 기능을 켜고, 소설처럼 방대한 컨텍스트 파일을 구축했지만, AI 쓰레기 콘텐츠는 여전히 계속 나타납니다.

그것이 반복적으로 나타나는 이유는 당신이 원래 고장나지 않은 계층을 계속 수선하고 있기 때문입니다.

AI 쓰레기 콘텐츠는 프롬프트 문제가 아니라 시스템 문제입니다. 마치 공장이 계속해서 결함이 있는 제품을 생산하는 경우, 문제는 특정 작업자가 아니라 품질 관리 메커니즘에 있습니다. 아무도 제품이 공장을 떠나기 전에 검사하지 않는 것입니다.

그래서 이 글에서 구축하려는 것은 바로 이 메커니즘입니다. 글을 다 읽고 나면, Hermes라는 오픈소스 에이전트에서 실행할 수 있는 eval loop를 갖게 됩니다. 이 루프는 각 출력물이 게시되기 전에 여러분의 기준에 따라 점수를 매기고, 게시 후에는 실제 출력 성능을 계속 모니터링합니다. 그리고 매번 실패를 새로운 테스트로 전환하여 품질 기준이 자동으로 상향 조정되도록 합니다.

우리는 단계별로 이를 구축해 나갈 것입니다. 최종적으로 얻을 수 있는 이점은 매우 구체적입니다: 진정으로 깨끗하고 신뢰할 수 있는 출력물을 얻을 수 있어, 한밤중에 다시 한 글자씩 확인할 필요가 없습니다. 직관적으로 확인할 수 있는 품질 점수를 갖게 됩니다. AI 쓰레기 콘텐츠는 사용자에게 도달하기 전에 차단되며, 사용자가 발견할 때까지 기다릴 필요가 없습니다.

이 글을 통해 얻을 수 있는 것들은 다음과 같습니다:

더 나은 프롬프트, 더 큰 모델, 메모리 기능만으로는 왜 AI 쓰레기 콘텐츠를 완전히 없앨 수 없는지, 그리고 실제로 효과가 있는 계층은 무엇인지;

AI 쓰레기 콘텐츠가 여러분의 작업에서 숨어 있는 두 곳: 콘텐츠 출력과 제품 출력; 그리고 왜 두 경우의 수정 방법이 완전히 동일한지;

eval loop가 무엇인지 쉽게 설명: 일상적으로 거의 실행되지 않는 이 품질 계층과, 왜 아무도 이를 구축하라고 알려주지 않았는지;

이번 주 안에 구축할 수 있는 품질 기준: 콘텐츠와 제품 모두에 적용 가능하며, 구체적으로 무엇을 측정해야 하고, 화면상의 어떤 숫자가 '좋은' 것인지;

완전한 구축 단계: Hermes가 이미 제공하는 구성 요소(skills, memory, cron, 승인 버튼)를 사용하여 전체 루프를 연결하고, 품질 게이트가 자동으로 작동하여 더 이상 수동으로 확인할 필요가 없도록 하는 방법.

만약 'AI 쓰레기 콘텐츠를 해결하는 5가지 프롬프트'를 기대하고 오셨다면, 이 글은 그런 내용이 아닙니다.

그런 것들은 분명 존재하지만, 실제로 효과적이지 않습니다. 이 글은 실제로 효과가 있는 버전에 관한 것입니다.

당신은 진짜 시도해야 할 것을 제외하고 거의 모든 것을 시도했습니다.

먼저 여러분이 이미 해온 일을 간단히 되짚어 보겠습니다: 프롬프트를 세 번, 네 번 다시 작성했습니다. 예시를 추가하고, 페르소나를 설정하고, '이렇게 하지 마세요'라는 긴 목록을 추가했습니다. 최첨단 모델로 업그레이드하고, 토큰당 5배 더 많은 비용을 지출했지만, 출력물은 더 자신감 있어졌을 뿐, 내용이 덜 공허해지지는 않았습니다. 메모리 기능을 켜고, 컨텍스트 파일을 구축하여 브랜드 톤, 과거 작업물, 스타일 가이드를 모두 주입했습니다.

이러한 각각의 작업을 수행하면 몇 번 괜찮은 생성 결과를 얻을 수 있습니다. 그러면 AI 쓰레기 콘텐츠가 다시 서서히 돌아옵니다.

이 모든 것은 입력 측면의 패치에 불과하기 때문입니다. 당신은 계속해서 '생성'하는 것을 다듬고 있지만, 진정으로 '차단'해야 할 것을 간과하고 있습니다. 아무리 좋은 총이라도 어둠 속을 향해 쏘기만 하면 아무것도 맞출 수 없습니다.

AI 쓰레기 콘텐츠는 출력 측면의 문제입니다. 문제는 모델이 좋은 결과물을 만들 수 없다는 것이 아니라, 중요한 사람에게 도달하기 전에 어떤 결과물이 좋고 나쁜지 미리 구분할 방법이 없다는 데 있습니다.

당신에게는 eval 루프도, 품질 기준도, 점수판도 없습니다. 그래서 계속 블라인드 튜닝을 하고 있는 것입니다. 프롬프트를 수정하고, 뭔가 나아진 것 같지만, 느낌은 측정이 아니며, 느낌만으로는 다음 50번의 생성 중 숨겨진 한 번의 형편없는 출력을 막을 수 없습니다.

그래서 당신은 자신을 탓하고, 프롬프트를 탓하고, Agent 설정을 탓하고, 컨텍스트 엔지니어링을 탓하기 시작합니다. 하지만 진정으로 부족한 것은 당신이 한 번도 배운 적 없는 AI 작업 방식의 한 계층입니다. 그리고 이 글을读完 후, 이 계층은 당신의 기기에서, Hermes 안에서 실행될 것입니다.

왜 더 나은 프롬프트가 이 문제를 해결하지 못하며, 왜 사람들이 여전히 계속 시도하는가

프롬프트는 가설이고, 출력은 결과이며, eval은 이 둘을 폐쇄 루프로 연결하는 유일한 것입니다.

이 폐쇄 루프가 없으면 당신은 영원히 추측 속에 머물게 됩니다. 가설을 조정하고, 눈으로 결과 하나를 확인한 후 승리를 선언합니다. 같은 프롬프트가 실제로 30%의 시간 동안 쓰레기를 생성한다는 사실을 절대 발견하지 못합니다. 매번 눈앞의 출력 하나만 보기 때문입니다.

모델은 비결정적입니다. 같은 프롬프트를 두 번 실행하면 두 개의 다른 답변이 나옵니다. 이는 '완벽한' 프롬프트조차도 특정 비율의 실행에서 AI 쓰레기 콘텐츠를 생성한다는 것을 의미합니다. 그리고 고객이나 사용자가 실제로 보기 전까지는, 당신은 그것이 어느 실행인지 전혀 알 수 없습니다.

따라서 완벽한 프롬프트는 품질 보증이 아니라, 승률이 약간 높은 동전 던지기에 불과합니다. 그리고 당신은 지금 매번 동전 던지기의 결과를 그대로 발송하고 있는 것입니다.

사람들이 계속 프롬프트에 희망을 거는 이유는 간단합니다. 프롬프트는 당신이 볼 수 있는 유일한 레버이기 때문입니다. 그것을 편집할 수 있고, 편집하면 통제감을 느끼게 됩니다.

측정은 보이지 않습니다. 아무도 측정에 관한 강의를 팔지 않으며, '이 eval suite로 출력 품질이 10배 향상되었습니다'라는 제목의 바이럴 게시물도 없습니다. 그래서 모든 논의는 단독으로 사용해서는 문제를 전혀 해결할 수 없는 그 레버에 갇혀 있습니다.

AI 출력물이 항상 깔끔한 사람들은 프롬프트를 더 잘 쓰는 게 아닙니다. 그들은 당신이 없는 하나의 레버리지를 가지고 있을 뿐입니다: 모든 출력을 공개하기 전에 일정한 기준으로 측정한다는 점입니다. 바로 이 측정 메커니즘이 그들의 프롬프트를 마법처럼 보이게 만듭니다.

AI 쓰레기는 두 곳에 숨어 있습니다

AI 쓰레기는 오직 두 곳에만 숨어 있으며, 거의 모든 사람이 그중 하나만 주목합니다.

첫 번째 장소는 당신의 콘텐츠 출력입니다.

트윗, 기사, 이메일, 랜딩 페이지, 게시물 등 AI로 생성하여 자신의 이름으로 공개하는 모든 것이 여기에 해당합니다.

여기서 AI 쓰레기는 종종 '기술적으로는 맞지만 완전히 텅 빈' 작품처럼 보입니다. 타임라인의 모든 AI 계정이 내보내는 것처럼 들립니다: 겉으로는 정확하지만 내부는 공허합니다.

공개적으로 실패하지만 그 이유를 설명할 수 없습니다. 보내기 버튼을 누를 때 각각의 게시물이 개별적으로는 괜찮아 보이기 때문입니다.

두 번째 장소는 당신의 제품 출력입니다.

당신이 출시한 AI 기능, Agent, 챗봇, 고객 응답기, 정보 추출 파이프라인 등 사용자가 실제로 접하는 모든 것이 여기에 해당합니다.

여기서 AI 쓰레기는 절대적인 확신을 가진 잘못된 답변, 환각된 숫자, 손상된 JSON 출력, 브랜드에 맞지 않는 톤, 또는 데모에서는 훌륭했지만 세 번 배포 후 조용히 성능이 저하된 출력으로 나타날 수 있습니다.

공개적으로 즉시 죽지 않습니다. 침묵 속에서 퍼져 나갑니다. 각 사용자는 조금씩 나쁜 경험을 받지만, 대부분은 당신에게 말하지 않습니다. 그들은 그냥 떠납니다.

이 둘은 같은 병이며, 해결책도 동일합니다.

콘텐츠 쓰레기와 제품 쓰레기는 본질적으로 측정되지 않은 AI 출력으로, 중간에 품질 게이트 없이 바로 청중 앞에 전달됩니다.

유일한 차이는 위험과 가시성입니다. 콘텐츠 쓰레기는 공개적으로 당황하게 만들고, 제품 쓰레기는 조용히 비즈니스를 갉아먹습니다. 그리고 우리가 Hermes에서 구축할 이 루프는 동일한 skill로 둘 다 점수를 매깁니다. 이렇게 하면 서로 다른 시나리오를 위해 두 개의 시스템을 유지할 필요 없이 하나의 품질 시스템으로 모든 생성 콘텐츠를 관리할 수 있습니다.

eval loop이란 정확히 무엇인가

eval loop은 반복 실행 가능한 테스트입니다. AI 출력이 게시되기 전과 후에, 자동으로 사용자가 정의한 기준과 비교하여 점수를 매깁니다.

이것이 전부입니다. 정말 간단하죠. 그리고 바로 이 부분이 대부분의 AI 빌더들이 놓치고 있는 계층입니다.

출력 생성 → 사용자가 정의한 기준에 따라 점수 매기기 → 기준 미달 결과 차단 → 실패한 부분 수정 → 재평가 후, 테스트를 통과한 출력만 다음 단계로 전달

소프트웨어 엔지니어들은 오래전부터 이 메커니즘을 가지고 있었습니다. 바로 '테스트'입니다. 여러분은 절대 테스트 없이 코드를 게시하고 프로덕션 환경에서 잘 돌아가길 바라지 않을 겁니다. 하지만 지금 업계 전체가 AI 출력을 이렇게 게시하고 있습니다: 모델에서 바로 사용자에게, 오직 감과 기도에 의존해서 말이죠.

거의 아무도 eval loop을 가지고 있지 않습니다. 그 이유는 인구 구성과 관련이 있습니다. 오늘날 AI로 무언가를 구축하는 사람들 중 상당수는 콘텐츠, 영업, 제품, 스타트업 출신이지 엔지니어링 배경이 아닙니다. 그래서 '출력에 대한 테스트 작성'은 그들의 도구 상자에 없었던 것입니다. Eval은 '진정한 엔지니어'만 사용하는 인프라처럼 들리고, 가장 필요로 하는 사람들은 오히려 무의식적으로 자신이 사용할 자격이 없다고 느끼게 됩니다.

이것을 비결정적 시스템을 위한 단위 테스트라고 생각하면 됩니다. 코드가 실행되는지 여부를 테스트하는 것이 아니라, 출력이 충분히 좋은지 테스트하는 것입니다. 충분히 많은 사례에 대해 테스트하여 특정 나쁜 생성 결과가 쉽게 숨어 지나가지 못하도록 해야 합니다.

eval loop은 세 곳에서 실행됩니다. 우리가 구축할 시스템은 이 세 가지 단계에 이를 배치할 것입니다:

게시 전: 저장된 사례 세트를 사용하여 새로운 프롬프트나 새 모델을 테스트하고, 성능이 저하되지 않았는지 확인합니다. 이것이 회귀 테스트로, 하나의 수정이 한 문제를 해결했지만 조용히 다른 세 곳을 망가뜨리는 것을 방지합니다.

런타임: 출력이 생성되는 동안 점수를 매기고, 조건부 로직이 실패한 결과가 사용자에게 도달하기 전에 차단합니다. 이것이 가드레일입니다.

프로덕션 환경: 실제 실행 결과를 지속적으로 샘플링하여 점수를 매깁니다. 이렇게 하면 품질이 떨어지기 시작한 당일에 문제를 발견할 수 있고, 일주일 후 고객이 불평할 때까지 기다리지 않아도 됩니다.

첫 번째 유형은 스프레드시트로도 구성할 수 있습니다. 하지만 이 세 가지 테스트를 지속적으로 실행하면서, 동시에 이것을 당신의 두 번째 직업으로 만들지 않으려면, 바로 이것이 우리가 이를 Agent에 넣는 이유입니다.

일단 품질이 숫자가 되면, AI 쓰레기는 더 이상 반복적으로 느껴지는 감정이 아니라, 수정할 수 있는 버그가 됩니다. 감정은 디버깅할 수 없지만, 0.82에서 0.61로 떨어진 점수는 디버깅할 수 있습니다.

벤치마크: 다음에 구축할 세 가지 구성 요소

벤치마크에는 세 가지 구성 요소가 있습니다. 콘텐츠를 평가하든 제품을 평가하든, 동일한 세 가지 요소입니다:

테스트 케이스: 실제 입력과 이에 대응하는 고품질 출력 샘플, 즉 당신의 그라운드 트루스(ground truth)입니다.
지표: 출력을 점수로 변환하는 방법, 가급적이면 0에서 1 사이의 점수여야 합니다.
임계값: 이 선 아래에 있는 콘텐츠는 절대 게시를 허용하지 않습니다.

이 세 가지를 구축하면 품질 관문을 갖게 됩니다. 하나라도 빠지면, 그것은 단지 바람에 불과합니다. 이번 섹션에서는 각 부분에 무엇을 넣어야 하는지 설명한 후, 이 세 가지를 모두 Hermes에 연결하겠습니다.

콘텐츠의 경우, 테스트 케이스는 당신의 골드 스탠다드입니다.

가장 좋은 20~50개의 작품을 찾아보세요: 실제로 성과가 좋았던 콘텐츠, 저장된 게시물, 당신이 온전히 이름을 걸고 싶은 글들. 이것이 '좋은 것'의 모습입니다. 당신은 기준을 공중에서 만들어내는 것이 아니라, 이미 최고의 상태에서 달성했던 기준을 추출하는 것입니다.

콘텐츠의 경우, 지표는 일종의 평가 척도입니다.

점수의 신뢰성은 그 뒤에 있는 평가 척도의 신뢰성에 달려 있습니다. 따라서 당신이 진정으로 믿는 '좋은 콘텐츠 기준'을 코드화해야 합니다. 콘텐츠의 경우, 나는 네 가지 기준으로 각 작품을 평가합니다:

특정 작업을 어떻게 수행하는지 설명하는가? 단지 느낌만 주는 것이 아니라, 독자가 내일 바로 행동에 옮길 수 있는가?

목표 독자 모두가 이해할 수 있는가? 전문 용어의 장벽이나 업계 내부자만 아는 표현이 없는가?

구조가 명확하고, 재사용 가능하며, 단계별로 전개되는가? 단지 감동을 주는 것에 그치지 않는가?

충분히 새로운가? 독자가 이전에는 이런 방식으로 할 수 있다는 것을 몰랐던 내용인가?

이 네 가지 기준 위에 있는 메타 기준은: 독자가 이 콘텐츠를 저장하고, 나중에 돌아와서 따라 할 것인가?

만약 대답이 '아니오'라면, 아무리 글이 깔끔하게 읽혀도 그것은 AI 쓰레기 콘텐츠입니다.

핵심은 평가 척도 자체에 있습니다. 모호한 척도, 예를 들어 "이 콘텐츠가 좋은가? 매력적인가?"는 모호한 점수만을 만들어냅니다. 구체적인 척도, 예를 들어 "이 콘텐츠에 바로 복사해서 사용할 수 있는 템플릿이나 작업 매뉴얼이 최소한 하나 포함되어 있는가?"는 신뢰할 수 있는 점수를 만들어냅니다. 당신이 자신의 취향을 실제로 글로 옮겨야만, judge가 당신의 취향을 이어받을 수 있습니다.

제품의 경우, 테스트 케이스는 로그에서 나옵니다.

로그와 실제 사용자 세션에서 기능이 실제로 마주하는 입력값을 추출해야 합니다. 출시 당일에 테스트한 세 가지 해피 패스 예시만 보지 마세요. 시스템을 실제로 무너뜨리는 것은 종종 이상한 케이스이며, 그런 이상한 케이스는 모두 로그 속에 숨어 있습니다.

제품의 경우, 지표는 작업 자체와 일치해야 합니다.

각 입력값에 대해 어떤 출력이 올바른지 정의하고, 지표를 작업 유형과 일치시키세요. 정답 레이블이 하나뿐이면 정확히 일치하는 방식을 사용하고, 구조가 반드시 성립해야 하면 검증기를 사용하며, 출력이 개방형이면 의미 유사도와 판단기를 사용하세요. 지표가 해야 할 일은 단 하나, 숫자를 반환하는 것입니다. 숫자만이 임계값에 들어갈 수 있기 때문입니다.

콘텐츠와 제품의 경우, 임계값은 지켜야 할 선입니다.

0.7은 합리적인 출발점입니다. 0.7 미만의 모든 콘텐츠는 예외 없이 게시 전에 재작업되거나 폐기되어야 합니다. 임계값은 '이게 마음에 들어'라는 이유로 0.6 결과를 절대 넘기지 않을 때만 진정한 효과를 발휘합니다. 그 의미는, 깊은 밤에 자기 투영이 담긴 판단을 의사 결정에서 제거하는 데 있습니다.

이것이 바로 벤치마크입니다. 이제, 이 벤치마크가 스스로 작동하도록 만들어야 합니다.

Hermes에서 이 루프 구축하기

Hermes에는 기본적으로 eval 버튼이나 '품질'이라는 대시보드가 있어 'AI 쓰레기 콘텐츠 방지'를 켤 수 있는 기능이 없습니다.

하지만 Hermes가 제공하는 것은 사실 더 좋습니다. 바로 eval 루프의 원시 구성 요소를 제공한다는 점입니다. 이러한 기본 기능을 한 번만 조립하면 진정으로 이를 소유할 수 있습니다.

이러한 구성 요소에는 다음이 포함됩니다. 스스로 작성하고 재사용할 수 있는 스킬, 세션을 넘어 확장되는 영구 메모리, 내장된 크론, 모든 플랫폼으로 전송 가능한 전달 기능, Slack의 승인 버튼, 그리고 핵심 메커니즘에 내장된 자기 개선 습관.

Hermes는 스스로를 '당신과 함께 성장하는 에이전트'라고 부릅니다. 그리고 이러한 성장이 바로 우리가 구축하려는 루프입니다.

그러니 이제 연결을 시작하겠습니다. 총 여섯 단계입니다.

첫 번째 단계, Hermes를 당신이 접근할 수 있는 곳에 배포하세요.

Hermes를 설치하고 Telegram에 연결하세요. 이는 생각보다 더 중요한데, 품질 게이트는 당신을 방해할 수 있을 때만 진정으로 효과적이기 때문입니다. Hermes는 20개 이상의 채널에서 실행될 수 있으며, Slack과 Telegram에서 승인 버튼을 기본적으로 푸시할 수 있습니다. 즉, Agent가 백그라운드에서 작업을 완료하고, 당신의 결정이 필요할 때 살짝 어깨를 두드려 줍니다.

두 번째 단계, 당신의 골드 스탠다드를 메모리에 로드하세요.

Hermes는 세션을 넘어 성장하는 지속적 메모리를 가지고 있으며, 완전한 크로스 세션 리콜을 지원합니다. 따라서 벤치마크에 있는 20~50개의 최고 작품을 한 번만 넣어두면 계속 유지됩니다.

이 부분은 보통 스크린샷, 오래된 초안, 흩어진 파일에 분산되어 있습니다. 하지만 여기서는 Agent의 장기 메모리가 되어, 쿼리 가능하며 점수를 매길 때 비교하는 ground truth가 됩니다.

세 번째 단계, 당신의 평가 척도를 judge skill로 만드세요.

이것이 전체 시스템의 핵심입니다. 자연어로 Hermes에게 한 번만 말하면 됩니다: 출력물과 평가 척도를 받아, 각 기준에 대해 0에서 1 사이의 점수와 한 줄의 이유를 반환하는 skill을 생성하세요.

이것이 바로 LLM-as-a-judge입니다: Agent가 당신의 LLM 출력을 평가하도록 하는 것입니다. 명확하고 날카로운 평가 척도와 함께라면, 모델은 당신보다 더 안정적인 비평가가 됩니다. 자존심이 없고, 당신이 은근히 자랑하는 문장을 삭제하는 데 망설이지 않기 때문입니다.

이것을 일회성 프롬프트가 아닌 skill로 만드는 이유는, Hermes의 skills가 본질적으로 절차적 메모리이기 때문입니다. Agent는 이를 작성하고 저장하며 반복적으로 재사용합니다. 당신은 자신의 취향을 한 번만 코딩하면, 이후의 모든 출력에 대해 지속적으로 점수를 매길 수 있습니다.

게다가 skills는 복리 효과를 냅니다. Nous는 20개 이상의 자체 생성 skills를 가진 Agent가 유사한 작업을 완료할 때 속도가 40% 향상된다는 것을 발견했습니다. 더 이상 프로세스를 반복적으로 재발견할 필요가 없기 때문입니다. 당신의 judge도 더 많이 실행될수록 더 날카로워집니다.

네 번째 단계, 테스트 스위트를 표가 아닌 skill로 만드세요.

당신의 테스트 케이스와 지표 함수는 함께 Hermes가 저장하고 버전 관리하는 하나의 스킬(skill)로 통합됩니다. 지표 라이브러리는 특정 작업에 따라 결정됩니다. 분류 작업에는 정확한 일치(Exact Match)를 사용하고, 추출 작업에는 정규 표현식(Regex)을 사용하며, 구조화된 출력에는 JSON 검증기(Validator)와 키-값(Key-Value) 검증기를 사용하고, 생성형 출력에는 의미 유사도(Semantic Similarity)를 사용합니다.

개방형 작업의 경우, 당신의 판단 스킬(Judge Skill)을 사용하세요. Hermes가 직접 채점 코드를 작성합니다. 당신은 작업을 설명하기만 하면 되며, Hermes가 그에 맞는 지표를 구축합니다. 이 모든 것은 하나의 장소에 저장되어 에이전트(Agent)가 직접 관리하며, 언젠가 찾지 못할 엑셀 시트에 흩어져 있지 않습니다.

5단계, 회귀 테스트(Regression Test)와 승인 버튼으로 출시 관문을 지키세요.

이것은 전체 시스템에서 가장 레버리지가 높은 습관이면서도, 장기간 수동으로 유지하기 가장 어려운 습관입니다. 그래서 우리는 이를 에이전트(Agent)에게 맡깁니다.

프로세스를 연결한 후에는, 새로운 프롬프트, 교체된 모델, 조정된 파이프라인 등 어떤 변경 사항이든 자동으로 테스트 스위트(Test Suite)가 실행됩니다. Hermes는 모든 케이스를 다시 실행하고, 기준선(Baseline) 대비 점수 변화를 계산한 후, 조용히 배포하지 않고 Slack을 통해 알림을 보냅니다: "점수가 0.81에서 0.74로 하락했습니다. 두 케이스에서 성능 회귀(Regression)가 발생했습니다. 승인하시겠습니까?"

당신이 승인 버튼을 클릭한 후에야, Hermes는 다음 단계를 진행합니다.

`/goal` 명령어를 사용하여 Hermes를 이 작업에 지속적으로 고정시킬 수 있으며, 에이전트(Agent)가 여러 대화 세션에 걸쳐 동일한 목표를 향해 실행되도록 할 수 있습니다. 더 큰 작업의 경우, 멀티 에이전트(Multi-Agent) 칸반 보드를 통해 실행 프로세스를 분해하고, 병렬로 채점한 후 실행 시간을 예약할 수도 있습니다.

이렇게 하면 품질 관문(Quality Gate)이 상시 프로세스가 되며, 당신이 기억해서 수동으로 해야 하는 작업이 아닙니다.

6단계, cron을 사용하여 프로덕션 환경을 모니터링하고 피드백 루프(Closed Loop)를 완성하세요.

Hermes에는 내장 cron 기능이 있어 결과를 모든 플랫폼으로 전송할 수 있습니다. 따라서 정기적인 작업을 예약하여 실제 실행 결과를 샘플링하고, 동일한 판단 스킬(Judge Skill)로 점수를 매긴 후, 점수가 기준선 아래로 떨어지는 순간 개인 메시지로 알림을 받을 수 있습니다.

이렇게 하면 품질이 저하되기 시작한 당일에 문제를 발견할 수 있으며, 일주일 후에 고객이 불만을 제기할 때까지 기다릴 필요가 없습니다.

"Eval 점수가 하락했습니다"는 즉시 처리할 수 있는 문제이지만, "어떤 고객이 좀 불만스러워하는 것 같습니다"는 그렇지 않습니다.

다음은 전체 시스템이 복리 효과를 내기 시작하는 핵심 부분입니다.

Slack에서 특정 출력에 대해 엄지손가락을 내리면, Hermes가 이를 테스트 스위트 스킬에 새로운 테스트 케이스로 기록합니다. 실패한 실행은 영구적인 검사 항목이 됩니다.

또한, 자기 개선이 Hermes의 핵심 메커니즘이지 나중에 추가된 기능이 아니기 때문에, 이 테스트 스위트는 매주 자동으로 더 견고해집니다.

당신이 잠을 자는 동안에도 품질 기준선은 계속 상승합니다.