도입부: 에이전트 스킬은 데모에서는 그럴듯하게 보이지만, 모델/프롬프트/데이터가 조금만 바뀌어도 조용히 품질이 무너질 수 있습니다. 이 글에서는 “추측이 아닌 측정”으로 스킬을 검증하는 테스트 프레임워크 관점과, 팀에서 누가 어떤 모델을 쓰더라도 핵심 숫자는 동일하게 만드는 실전 접근을 정리합니다.
왜 스킬에 “테스트”가 필요한가: 잘 되던 게 조용히 깨지는 회귀(regression)
에이전트 스킬은 코드라기보다 “프롬프트 + 툴 호출 + 후처리”의 조합인 경우가 많아서, 겉으로는 잘 동작해 보여도 다음 이유로 성공/실패가 들쭉날쭉해집니다.
- 모델 변경: 같은 입력이라도 모델마다 출력 형식/해석/반올림/누락 처리 방식이 달라집니다.
- 프롬프트/스킬 로직 변경: 작은 문구 수정이 결과를 바꿀 수 있습니다.
- 데이터/정책 변경: “이번달”, “누락”, “손실액” 같은 용어 정의가 바뀌면 결과가 달라집니다.
- 비결정성(nondeterminism): temperature, tool 선택 정책, 요약 방식이 조금만 달라도 결과가 흔들립니다.
즉 “스킬이 잘 동작한다”는 느낌은 유지보수 관점에서 위험합니다. 소프트웨어처럼 **명세(spec)와 테스트(측정)**가 필요합니다.
팀의 목표를 다시 정의하기: “모델 성능 향상”이 아니라 “업무 결과의 표준화”
대화에서 제가 중요하다고 본 지점은 이 부분입니다.
- 팀원들이 각자 다른 AI/모델을 쓰더라도
- 우리 팀 업무에 특화된 스킬을 이해하고
- 동일한 업무 요청에는 일관성 있는 결과를 내야 합니다.
여기서 “일관성”은 현실적으로 두 레이어로 나뉩니다.
- 핵심 산출물(숫자): 100% 동일해야 함 (허용 오차 0)
- 부가 산출물(설명/인사이트): 모델마다 달라도 됨
이렇게 나누면, “완전히 동일한 텍스트”를 강제하려다 생기는 비용을 줄이면서도 업무 품질을 안정화할 수 있습니다.
스킬 테스트 프레임워크의 핵심: ‘동작함’을 측정 가능한 합격 기준으로 만들기
Anthropic의 Skill-Creator가 강조하는 방향은 전형적인 소프트웨어 개발 방식과 같습니다.
- 유닛 테스트/벤치마크로 합격 기준을 자동 검증
- 변경(모델/프롬프트/스킬) 시마다 회귀 테스트로 조용한 깨짐을 조기 발견
- A/B 비교로 “좋아진 것 같은데?”가 아니라 실제로 좋아졌는지 측정
저는 이를 팀 스킬 표준화로 번역하면 아래 3가지를 먼저 정의하는 일이라고 봅니다.
1) “정답”을 정의할 수 있는 테스트 케이스(골든 데이터셋)
예: 다음 3가지 대표 요청을 골든 케이스로 만들 수 있습니다.
- 월별 팀별 실적 합계
- 이번달 실적 등록 누락 현황
- 실적등록 누락으로 인한 손실액
여기서 중요한 건 단순히 “데이터 소스를 고정”하는 수준이 아니라, 입력 파라미터가 같으면 결과가 같도록 테스트를 설계하는 것입니다.
- 입력:
{month=2026-04, team=A} - 기대 출력(정답 숫자):
{performance_total=..., missing_count=..., loss_amount=...} - 허용 오차: 숫자는 0(완전 일치)
2) 스킬이 지켜야 할 ‘필수 포함/금지/허용 변형 범위’
팀 표준화는 보통 “완전 동일한 출력”보다 다음이 유지되는지가 중요합니다.
- 필수 포함: 집계 기간, 팀 기준, 핵심 숫자 3종
- 금지: 임의 가정으로 숫자 생성, 근거 없는 보정값 적용
- 허용: 설명 문구 스타일, 인사이트 제안, 리스크 코멘트
3) 실패 유형 분류(디버깅 가능하게 만들기)
테스트가 실패했을 때 “왜 틀렸는지”를 추적할 수 있어야 개선이 됩니다. 예를 들면:
- 기간 해석 오류(타임존/월 기준)
- 중복 제거 기준 차이
- 누락의 정의 해석 차이
- 반올림/버림 규칙 차이
- 필터/조인 조건 누락
이 분류는 단순 통계가 아니라, 다음 개선의 방향을 정해주는 나침반입니다.
“핵심 숫자 동일”을 현실로 만드는 설계: 결정적 계산 vs LLM 생성 분리
대화에서 결론적으로 제가 강하게 추천한 방식은 이겁니다.
- 핵심 숫자 산출은 결정적 컴포넌트가 담당합니다.
(고정 SQL, 저장 프로시저, 파이썬 집계, 버전 고정된 데이터 스냅샷 등) - LLM은 숫자를 “계산”하지 않고, 결과를 설명/해석합니다.
이렇게 역할을 분리하면 “모델이 달라도 숫자는 동일”이라는 목표를 기술적으로 달성하기 쉬워집니다. LLM에게 자유서술로 숫자 계산까지 맡기는 순간, 모델별 암묵 규칙 차이(반올림/결측 처리/필터 해석)가 숫자를 흔들 가능성이 커집니다.
예시 구조(개념 코드)
def get_metrics(month: str, team: str) -> dict:
# 결정적(Deterministic) 계산 레이어
# - 고정된 쿼리/집계
# - 동일 입력이면 동일 출력
return {
"month": month,
"team": team,
"performance_total": 128340000,
"missing_count": 7,
"loss_amount": 3520000,
"currency": "KRW"
}
def skill(month: str, team: str, llm) -> dict:
metrics = get_metrics(month, team)
# LLM은 설명만 생성(숫자 자체는 metrics를 그대로 사용)
explanation = llm.generate(f"""
다음 지표를 바탕으로 요약과 인사이트를 작성하세요.
지표: {metrics}
조건: 숫자는 재계산하거나 변경하지 말고 그대로 인용하세요.
""")
return {
"metrics": metrics, # 테스트 대상(핵심 숫자)
"explanation": explanation # 변형 허용(인사이트/문장)
}
이 설계에서 테스트는 훨씬 명확해집니다. 핵심 숫자는 JSON으로 고정되니, 모델이 바뀌어도 스킬의 “정답”을 측정할 수 있습니다.
어떤 테스트를 돌릴까: 유닛 테스트 + 회귀 테스트 + A/B 비교
스킬 테스트 프레임워크를 팀에 도입한다면, 저는 아래 순서가 현실적이라고 봅니다.
- 골든 테스트 5개 만들기
- 가장 실패 비용이 큰 요청부터(보통 실적 합계)
- 회귀 테스트 자동화
- 모델 변경, 프롬프트 수정, 데이터 파이프라인 수정 시마다 실행
- A/B 비교
- “모델 A vs B”, “프롬프트 v1 vs v2”에서
- 핵심 숫자 일치율(= 100%가 목표)
- 형식 준수율(JSON 스키마 통과율)
- 설명 품질(휴먼 평가 또는 간단한 룰 기반 점수)
를 분리해 비교
- “모델 A vs B”, “프롬프트 v1 vs v2”에서
여기서 핵심은, “스킬이 잘 되는 것 같다”가 아니라 스킬이 합격 기준을 통과하는지를 계속 확인하는 운영 체계를 만드는 것입니다.
인사이트: 스킬의 품질은 ‘모델 성능’보다 ‘명세+테스트’가 좌우하는 경우가 많습니다
처음 질문이 “스킬이 잘 작동하면 모델 성능이 향상된 건가?”였는데, 저는 현업에서는 종종 반대라고 느낍니다.
- 모델이 좋아져서 해결되는 문제도 분명 있지만,
- 팀이 원하는 건 대개 “창의성”이 아니라 “업무 산출물의 일관성”이며,
- 일관성은 모델보다 결정성 있는 계산 + 테스트 가능한 명세에서 더 많이 나옵니다.
특히 “핵심 숫자는 항상 동일” 같은 요구는, LLM을 잘 고르는 문제라기보다 LLM이 흔들릴 수 있는 영역을 시스템적으로 분리하고, 그 결과를 테스트로 고정하는 문제에 가깝습니다.
마무리
스킬 테스트 프레임워크의 출발점은 단순합니다. “동작함”을 말로 정의하지 말고, 측정 가능한 합격 기준과 골든 테스트 케이스로 고정하는 것입니다. 팀에서 누구든 어떤 모델을 쓰든 핵심 숫자가 동일해야 한다면, 숫자는 결정적으로 계산하고 LLM은 설명을 맡기는 구조로 바꾸는 것부터 시작해보시길 권합니다.