스킬 시리즈 (01): 스킬 평가 — AI 스킬 품질을 정량화하는 방법

이중 계층 문제 (The Two-Layer Problem)

표준 소프트웨어 테스트에는 하나의 계층이 있습니다: 코드가 올바른 출력을 생성했는가? 스킬 평가에는 두 개의 계층이 있습니다:

계층 1 — 트리거 (Trigger): LLM이 이 입력이 해당 스킬을 호출해야 한다고 결정했는가?
계층 2 — 실행 (Execution): 스킬이 실제로 작업을 올바르게 완료했는가?

어느 한 계층이라도 건너뛰면 평가는 불완전합니다. 작업 성공률은 90%이지만 트리거 재현율 (Trigger Recall)이 60%인 스킬은 수치가 암시하는 것보다 훨씬 더 나쁜 사용자 경험을 제공합니다.

테스트 대상은 기술 블로그 기사를 작성하는 스킬인 rnd-technical-writer입니다. 20개의 트리거 케이스, 2회의 작업 완료 실행, 1회의 A/B 프롬프트 비교 — 모든 수치는 실제 출력에서 가져왔습니다.

평가 프레임워크 (Evaluation Framework)

트리거 평가 (Trigger Evaluation)

핵심 지표 (Core metrics):

재현율 (Recall)    = TP / (TP + FN)  ← 트리거되어야 하는 모든 입력 중, 실제로 트리거된 비율
정밀도 (Precision) = TP / (TP + FP)  ← 트리거된 모든 입력 중, 올바른 비율
F1 (F1 Score)     = 2 × Recall × Precision / (Recall + Precision)

테스트 세트 구성 (20개 케이스):

TP (True Positives — 트리거되어야 함)    ×8   ← 명시적인 작성/튜토리얼/심층 분석 요청
TN (True Negatives — 트리거되지 않아야 함) ×8   ← 질문, 시리즈 계획, 코드 도움
EDGE (경계 사례 - boundary cases)         ×4   ← 의미론적으로 모호하거나 혼합된 신호

명확한 TP/TN 케이스는 맞히기 쉽습니다. 경계 사례(Edge cases)는 스킬 설명이 실제로 어디에서 모호한지를 드러냅니다.

자동화 접근 방식 (Automation approach): 스킬 설명과 사용자 입력을 LLM에 전달하고, 해당 스킬이 트리거될지 예측하도록 요청한 뒤 구조화된 JSON을 반환하게 합니다:

TRIGGER_EVAL_PROMPT = """당신은 사용자 메시지가 특정 AI 스킬을 트리거할지 여부를 평가하고 있습니다.

스킬 사양:
...

작업 완료 평가 (Task Completion Evaluation)

두 단계의 확인 절차:

레벨 2 (구조적) — 규칙 기반 (rule-based), LLM 불필요:
  → 최소 기준 이상의 단어 / 글자 수
  → 코드 블록 존재 여부
...

판단 프롬프트 템플릿:

JUDGE_PROMPT = """당신은 전문 기술 콘텐츠 리뷰어입니다.
다음의 AI 생성 기술 기사를 평가하십시오.

...

실행 결과 (Run Results)

파트 1: 트리거 평가 (Trigger Evaluation)

혼동 행렬 (Confusion matrix): TP=11  TN=8  FP=1  FN=0
정확도 (Accuracy):  95%  (19/20)
재현율 (Recall):    100%
...

20개 사례 중 19개가 정확했습니다. 단 하나의 실패 사례는 다음과 같습니다:

입력 (Input):    "帮我写一个解析 JSON 的 Python 函数"
                 (JSON을 파싱하는 Python 함수를 작성해줘)
기대 결과 (Expected): no_trigger
...

파트 2: 작업 완료도 (Task Completion)

[T001] Redis TTL 설정 베스트 프랙티스 (영어)
  레벨 2 (Level 2): ✓ 모든 검사 통과
  기술적 정확도 (Technical accuracy): 4/5  |  깊이 (Depth): 3/5  |  명확성 (Clarity): 5/5  |  실용적 가치 (Practical value): 4/5
...

파트 3: A/B 프롬프트 비교 (A/B Prompt Comparison)

[버전 A] 원본 시스템 프롬프트 (Original system prompt)
  가중치 적용 점수 (Weighted): 4.20/5

...

세 가지 엔지니어링 발견 사항 (Three Engineering Findings)

발견 1: 하나의 FP(False Positive)가 스킬 설명의 공백을 드러냄

실패한 사례는 다음과 같습니다: "JSON을 파싱하는 Python 함수를 작성해줘"

모델의 추론: 사용자가 무언가를 작성하기를 원함 — 즉, Python 코드라는 기술적인 결과물입니다. 스킬 설명에 기술 기사 또는 튜토리얼 작성이라고 명시되어 있으므로, "작성(write)"이라는 단어가 트리거를 발생시켰습니다.

설명에는 어떤 경우에 스킬이 트리거되어야 하는지는 명시되어 있었지만, "코드 작성"을 제외한다는 내용은 없었습니다. 모델은 불완전한 명세로부터 합리적인 추론을 내린 것입니다.

하나의 부정 예시(negative example)를 추가하면 해결됩니다:

다음의 경우 트리거하지 마십시오 (Do NOT trigger when):
  - 사용자가 코드 스니펫, 함수 또는 스크립트를 요청할 때 (코드를 직접 작성할 것)

그 추론 과정이 포함된 단 하나의 FP는 F1=0.96이라는 수치보다 더 유용합니다. 이는 스킬 설명에서 엄격하게 다듬어야 할 정확한 지점을 가리키기 때문입니다.

발견 2: 레벨 2 단어 수 검사가 중국어에서 조용히 실패함

T002 (Python 타입 힌트에 관한 중국어 기사)는 "너무 짧음: 165단어 (최소 300단어)"라고 보고했지만, 기사 내용은 시각적으로 완전했습니다.

문제는 구현 방식에 있습니다:

word_count = len(article.split())  # 공백을 기준으로 분리

중국어 텍스트는 단어 사이에 공백이 없습니다. 중국어 문장에 split()을 적용하면 의미 있는 단어 수(word count)가 아니라, 단 하나의 토큰이나 소수의 토큰만을 반환합니다. 게다가 모델이 출력을
markdown 코드 블록으로 감싸면서 단어 수 계산을 더욱 방해했습니다.

"165 words"는 실제로는 전체 중국어 기사였으며, 아마도 800자 이상의 콘텐츠였을 것입니다.

해결책:

def count_content_length(text: str) -> int:
    """CJK 텍스트는 글자 수(Characters)를, 라틴 문자는 단어 수(words)를 계산합니다."""
    clean = re.sub(r"`\*?\*?`", "", text, flags=re.DOTALL) # 코드 펜스(code fences) 제거
    cjk = len(re.findall(r"[一-鿿]", clean))
    if cjk > 50:
        return cjk
    return len(clean.split())

레벨 2(Level 2) 체크는 사소해 보이지만 언어적 가정을 포함하고 있습니다. 중국어와 영어가 혼용된 환경에서는 최소한 감지된 언어에 따라 길이 체크 로직을 분기해야 합니다.

발견 사항 3: LLM 판사(Judges)는 미세한 비교에서 실제적인 한계를 가짐

A/B 테스트의 두 프롬프트 모두 네 가지 차원 모두에서 동일한 점수(4/4/5/4)를 받았으며, 결과적으로 4.20/4.20으로 동점이 나왔습니다.

버전 B에는 세 가지 추가 사항이 있었습니다: 개발자의 고충(pain point)으로 시작하기, 최소 2개의 주석이 달린 코드 예시 포함하기, 체크리스트로 마무리하기. 관찰 가능한 구조적 변화가 있었음에도 불구하고, 판사(Judge)는 이들에게 동일한 점수를 부여했습니다.

두 가지 설명이 가능합니다:

1. 해당 입력값과 glm-4-flash 모델의 경우, 두 프롬프트 모두 실제로 유사한 출력을 생성했다.
2. 판사(Judge)의 채점 해상도(scoring resolution)가 너무 낮다 — 4점에서 5점 사이의 간격이 인간 검토자라면 알아차렸을 차이점들을 흡수해 버린다.

완화 방법:

• 단일 샷 채점(single-shot scoring) 대신 승률 비교(win-rate comparison)를 사용하십시오 (5회 이상의 비교를 실행하고, 승률이 60%를 초과하는 경우를 유의미한 것으로 간주).
• 판사(Judge)에게 단순히 점수를 부여하는 것이 아니라, 각 버전의 구체적인 장점을 나열하도록 요청하십시오.
• 스킬(Skill) 모델과 판사(Judge) 모델을 동일하게 사용하지 마십시오. 자기 평가(self-evaluation)는 신뢰할 수 없습니다. 판정에는 더 강력한 모델을 사용하십시오.

구현 로드맵

1주 차:
□ 가장 우선순위가 높은 스킬(Skill)에 대한 완전한 테스트 세트 구축 (TP:TN:edge = 8:8:4)
□ 수동으로 실행하여 기준이 되는 재현율(Recall) / 정밀도(Precision) 수치 확립

2주 차:
□ 작업 완료(Task completion) 평가 추가 (Level 2 구조적 평가 + Level 3 LLM-as-Judge)
□ 중국어 단어 수 계산 버그 수정
□ 스킬(Skill) 문서에 점수 기록

3주 차:
□ 스킬을 수정하고, 평가 프레임워크를 사용하여 개선 사항 검증
□ 하나의 완전한 "수정 → 평가 → 결론" 사이클을 문서화

설계 체크리스트 (Design Checklist)

트리거 평가 (Trigger evaluation)

• 테스트 세트가 TP / TN / 에지 케이스(edge cases)를 포함하는가 (8:8:4는 합리적인 시작 비율임)
• 스킬 설명에 부정적 예시(Negative examples, “~할 때는 트리거하지 마시오”)가 포함되어 있는가
• F1 점수가 0.9 미만인 경우, 스킬 설명의 모호한 트리거 언어를 먼저 점검했는가

작업 완료 평가 (Task completion evaluation)

• Level 2 단어 수 계산 시 중국어에 대해 split()이 아닌 글자 수(character count)를 사용하는가

• Level 2에서 구조를 확인하기 전에 마크다운 코드 펜스(markdown code fences)를 제거하는가

• 판사 모델(Judge model)이 해당 스킬이 사용하는 모델보다 더 강력한가

A/B 비교 (A/B comparison)

• 싱글샷(single-shot) 점수가 동일할 경우, 멀티 런 승률(multi-run win-rate, 5회 이상 비교)로 전환하는가
• 판사(Judge)와 대상(Subject)은 서로 다른 모델이어야 하는가

요약 (Summary)

1. F1 점수는 어디를 봐야 할지 알려주지 않지만, 실패 사례는 알려준다: 단 하나의 FP(False Positive)가 스킬 설명의 모호한 문장을 직접적으로 가리켰습니다. 이는 95%의 정확도보다 훨씬 더 실행 가능한(actionable) 정보입니다.
2. Level 2 체크에는 숨겨진 언어적 가정이 있다: 중국어에 대한 split() 사용은 버그입니다. 코드 펜스(code-fence)로 감싸는 것은 사소하다고 생각했던 길이 확인 과정을 망가뜨립니다.
3. LLM 판사는 미세한 차이를 위해 여러 샘플이 필요하다: 4.20 대 4.20의 동점은 프롬프트가 동일하다는 뜻이 아니라, 점수 해상도(scoring resolution)가 한계에 도달했음을 의미합니다.

참고 문헌 (References)

• Promptfoo A/B testing
• 전체 데모 코드: skill-01-trigger-eval

실제 엔터프라이즈급 워크플로에서 검증된 AI 에이전트 및 스킬 큐레이션 마켓플레이스인 PrimeSkills를 확인해 보세요. 군더더기 없이 실제로 작동하는 것들만 모았습니다.

_제 홈페이지에서 더 유용한 지식과 흥미로운 제품들을 찾아보세요.