AI 에이전트가 실제로 작동하는지 어떻게 측정하는가

목차

2026년 5월 업데이트.

TL;DR: 대부분의 운영자들은 평가를 완전히 건너뛰고 에이전트가 작동한다고 가정합니다. 제 프레임워크: 예상 출력이 있는 5–10개의 알려진 입력으로 골든 셋 구성, 평이한 언어로 합격/불합격 기준 정의, 매주 로그 확인. 실제 실행 10번이 되기 전에 정교한 평가 시스템을 구축하지 마세요 — 그게 모멘텀을 죽이는 함정입니다.

[운영자 시각] 저는 컨설팅 브랜드와 텍사스 주 플루거빌의 피클볼 시설인 Pickleland에서 30개 이상의 프로덕션 AI 에이전트를 운영합니다. 어느 순간 에이전트를 실제로 사용하는 시간보다 드리프트를 걱정하는 시간이 더 많다는 것을 깨달았습니다. 이것이 제가 정착한 평가 프레임워크입니다 — 박사 학위 불필요, 커스텀 평가 플랫폼 불필요, Python 불필요.

아무도 말하지 않는 문제: 에이전트는 조용히 드리프트한다

인간 직원이 일을 잘못하기 시작하면 보통 알아챕니다. AI 에이전트가 쓰레기를 생산하기 시작하면, 인간이 마침내 확인할 만큼 뭔가 심각하게 잘못될 때까지 조용히, 대규모로 쓰레기를 계속 생산합니다.

모델 업데이트 후 “AI 언어 모델로서” 면책 조항을 추가하기 시작한 콘텐츠 에이전트가 있었습니다. 프롬프트 변수 이름이 변경되어 티켓 링크 포함을 중단한 이벤트 프로모터 에이전트도 있었습니다. 둘 다 요란하게 실패하지 않았습니다. 둘 다 그냥 조용히 저하되었을 뿐입니다.

해결책은 NASA급 모니터링 시스템을 구축하는 것이 아닙니다. 드리프트가 누적되기 전에 감지하는 간단하고 반복 가능한 체크를 갖추는 것입니다.

평가란 무엇인가 (운영자를 위해)

엔지니어들은 “eval”이라는 단어를 모델에서 벤치마크를 실행하는 것을 의미하는 데 사용합니다. 운영자에게는 더 간단한 것을 의미합니다: 에이전트가 구축한 목적에 맞는 일을 여전히 하고 있는지 알려주는 반복 가능한 테스트.

세 가지 구성 요소:

1. 골든 셋 — 이미 본 적 있는 5–10개의 실제 입력과 이미 좋다는 것을 알고 있는 예상 출력
2. 합격/불합격 기준 — 합격으로 인정되는 것을 정의하는 평이한 언어의 규칙
3. 예약된 체크 — 당신 또는 어시스턴트가 실제로 주기적으로 테스트를 실행함

그게 전부입니다. 프레임워크가 필요한 게 아닙니다. 규율이 필요합니다.

골든 셋 구축하기

프로덕션 로그에서 추출하세요. 이미 좋은 출력이 어떤 모습인지 알고 있는 5–10개의 실제 입력을 찾으세요. 이것이 당신의 그라운드 트루스입니다.

제 콘텐츠 파이프라인 에이전트의 골든 셋은 수동으로 작성했을 때 보이스 체크리스트를 통과한 5개의 게시된 포스트입니다. Pickleland 이벤트 프로모터의 경우 평균 이상의 참여도(좋아요만이 아닌 댓글 + 공유)를 얻은 과거 Facebook 포스트 5개입니다.

좋은 골든 셋을 위한 규칙:

• 실제 입력, 발명한 가상 입력이 아님
• 최소 하나의 엣지 케이스 포함 (까다로운 입력, 짧은 입력, 비정상적인 형식의 입력)
• 예상 출력을 문서화하여 보관 — 스크린샷, 텍스트 파일, 스프레드시트의 행
• 골든 셋에서 절대 삭제하지 않고 추가만 함

에이전트가 마지막으로 잘 작동하는 것으로 확인되었을 때 “좋은” 것이 어떻게 보였는지 정확히 기록하세요. 그게 예상 출력이 됩니다.

합격/불합격 기준 정의하기

모호한 기준은 쓸모없습니다. “출력이 좋아야 한다”는 항상 합격하는데, 합리화하기 때문입니다.

비전문가도 평가할 수 있는 체크리스트 항목으로 기준을 작성하세요. 다음은 제 콘텐츠 파이프라인 에이전트에 사용하는 실제 기준입니다:

콘텐츠 에이전트 합격/불합격 체크리스트:

• 포스트의 첫 100단어 내에 TL;DR 있음
• “오늘날의 급변하는 세계에서”나 “AI로서” 같은 문구 없음
• 최소 하나의 구체적인 숫자 또는 통계 있음
• 단어 수가 800–2000 사이
• 모든 내부 링크가 작동함 (404 없음)

Pickleland 이벤트 프로모터의 경우:

이벤트 프로모터 합격/불합격 체크리스트:

• 이벤트 이름이 소스 캘린더와 일치함
• 날짜와 시간이 정확함
• 티켓 링크가 존재하고 작동함
• 텍스트가 280단어 미만
• 포스트가 일반적인 채우기 문구를 사용하지 않음

5개 체크리스트 항목 중 4개가 통과되면 실행은 합격입니다. 3개 이하가 통과되면 불합격이며 다음 실행 전에 조사합니다.

Claude를 심사자로 사용하기

출력이 길거나 복잡한 에이전트에는 Claude Sonnet을 자동화된 심사자로 사용합니다. 수동 검토보다 빠르고 제가 스킵할 수 있는 것들을 잡아냅니다.

콘텐츠 에이전트에 사용하는 심사 프롬프트입니다:

You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards.

Evaluate the following post against these criteria:
1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO)
2. Contains at least one concrete number or specific example (YES/NO)
3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO)
4. Word count is between 800 and 2000 words (YES/NO)
5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO)

For each criterion, respond YES or NO with one sentence of explanation.
At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise.

Post to evaluate:
---
{{post_content}}
---

이것을 Cloudflare Worker로 실행합니다. 최신 초안을 가져와 이 프롬프트를 실행하고 결과를 Google Sheet에 씁니다. 전체 과정은 8초가 걸리고 실행당 약 $0.003이 듭니다.

이벤트 프로모터의 경우 심사 프롬프트가 더 단순합니다:

You are checking an AI-generated Facebook event post for accuracy and quality.

Source data:
- Event name: {{event_name}}
- Date: {{event_date}}
- Time: {{event_time}}
- Ticket URL: {{ticket_url}}

Generated post:
---
{{generated_post}}
---

Check:
1. Does the post correctly state the event name? (YES/NO)
2. Does the post correctly state the date and time? (YES/NO)
3. Does the post include the exact ticket URL? (YES/NO)
4. Is the post under 280 words? (YES/NO)
5. Is the tone inviting without using generic filler phrases? (YES/NO)

Output PASS if all 5 are YES, FAIL if any are NO. List which items failed.

어디를 보나: Cloudflare Worker 로그

Cloudflare Workers에서 에이전트를 실행한다면 (대부분의 경량 에이전트에 그렇게 합니다), 내장된 log tail이 최고의 도구입니다. 시작하기 위해 서드파티 로깅 서비스가 필요 없습니다.

주간 스팟 리뷰에서 확인하는 것:

• 오류 및 예외 — 충돌하거나 타임아웃된 모든 것
• 토큰 수 — 실행이 갑자기 정상의 3배 토큰을 사용하면 뭔가 변한 것
• 지연 급증 — 갑작스러운 속도 저하는 보통 프롬프트가 길어졌거나 모델이 고생하고 있음을 의미
• 출력 길이 드리프트 — 평균 출력이 600단어에서 200단어로 줄었다면 에이전트가 행동을 바꾼 것

매주 월요일 아침에 이것에 15분을 씁니다. Notion에 간단한 체크리스트가 있습니다: 각 에이전트의 로그 열기, 이상한 점 기록, 지난주 기준선과 토큰 사용량 비교. 이것이 전체 프로세스입니다.

스프레드시트 평가: 볼품없지만 작동한다

자동화가 없었을 때는 Google Sheet에서 평가를 실행했습니다. 처음 4주 동안 새 에이전트에는 아직도 이것을 사용합니다.

구조:

주당 5행. 10분 걸립니다. 연속으로 두 번 불합격하면 에이전트를 멈추고 계속하기 전에 프롬프트를 수정합니다.

이건 민망할 정도로 로우테크입니다. 이것이 세 번의 프롬프트 회귀를 프로덕션에 도달하기 전에 발견한 방법이기도 합니다.

하면 안 되는 것

실제 실행 10번 전에 평가 시스템을 구축하지 마세요. 두 번밖에 실행하지 않은 에이전트를 위해 2주를 들여 정교한 평가 파이프라인을 구축하는 창업자들을 봤습니다. 실제 프로덕션 데이터가 생기기 전까지는 “좋은 것”이 어떻게 보이는지 충분히 알지 못합니다.

발명한 합성 입력으로 평가하지 마세요. 합성 테스트 케이스는 프로덕션이 던지는 이상한 엣지 케이스를 놓칩니다. 항상 실제 로그로 시작하세요.

모든 것을 평가하지 마세요. 실패가 실제로 아프게 될 3–5개의 에이전트를 선택하세요 — 고객 대면 출력, 공개적으로 게시하는 모든 것, 결제를 트리거하는 모든 것. 여유가 생길 때까지 내부 유틸리티 에이전트는 건너뛰세요.

너무 일찍 자동화하지 마세요. 실제로 사용하는 스프레드시트가 확인을 잊어버리는 Datadog 대시보드보다 낫습니다. 수동으로 시작하고, 체크를 10번 실행하고 실제로 무엇을 찾고 있는지 알게 된 후에 자동화하세요.

운영자의 결론

평가가 유용하려고 엔지니어링 수준일 필요는 없습니다. 5–10개의 실제 입력으로 구성된 골든 셋, 합격/불합격 기준 체크리스트, 매주 월요일 15분의 로그 확인으로 에이전트 드리프트의 80%가 누적되기 전에 잡을 수 있습니다. 거기서 시작하세요. 아직도 아무 평가 없이 에이전트를 실행하고 있다면, 눈 감고 비행하는 것입니다 — 결국 뭔가가 충분히 공개적으로 실패해서 20분을 투자했으면 좋았을 텐데 하는 생각이 들 것입니다.