Google DeepMind의 Philipp Schmid가 진행한 "평가(Evals) 없이 기술을 배포하지 마세요(Don't Ship Skills Without Evals)"라는 제목의 강연을 접하게 되었습니다. 그의 핵심 요점은 이렇습니다. 현재 모두가 AI 에이전트(AI agents)를 위한 기술(skills)을 작성하고 있지만, 거의 아무도 이를 테스트하지 않는다는 것입니다. 또한 LLM(대규모 언어 모델)은 비결정론적(non-deterministic)이기 때문에, 개발 중에 출력을 눈으로 확인하며 "내가 보기엔 괜찮네"라고 판단하는 것은 실제 사용 단계에서 어떤 일이 벌어질지에 대해 거의 아무런 정보도 주지 못합니다.

이 말은 저에게 매우 불편할 정도로 가깝게 다가왔습니다. SKILLmama에는 4개의 기술 파일(skill files), 4개의 에이전트(agents)에 걸친 설치 지침, 그리고 v1.0부터 믿고 의지해 온 채점 공식이 있었습니다. 저는 그것이 주장하는 대로 작동하는지 단 한 번도 실제로 테스트해 본 적이 없었습니다. 그래서 작은 평가 하네스(eval harness)를 구축하여 실행해 보았습니다. 첫 시도에서 세 개의 버그를 발견했습니다.

내가 실제로 구축한 것

거창한 것은 아닙니다. evals/skillmama-ablation.md에 있는 마크다운(markdown) 파일 하나입니다. SKILLmama를 트리거(trigger)해야 하는 프롬프트(prompts) 5개와 트리거해서는 안 되는 프롬프트 5개를 작성했고, 이를 기술 파일에 이미 정의된 트리거(Trigger) 및 비활성화(Do-NOT-activate) 규칙에 직접 매핑했습니다. 그 아래에는 결과 로그(result log)가 있습니다.

트리거되어야 함:
1. "FastAPI 앱의 RAG를 위해 어떤 벡터 DB(vector DB)를 사용해야 할까요?"
2. "내 Node 스택에 적합한 최고의 작업 큐(job queue)를 찾아주세요. 셀프 호스팅만 가능해야 합니다."
...

첫 번째 실행 결과는 10개 중 10개 모두 성공이었습니다. 트리거 로직은 잘 작동했습니다. 좋은 신호였지만, 이는 테스트의 쉬운 부분일 뿐입니다. 이는 단지 기술이 켜지는지 여부만 확인할 뿐입니다. 더 어려운 질문은 일단 실행되었을 때 파이프라인(pipeline)이 정말로 유용한가 하는 점이며, 이에 답하기 위해서는 체크리스트가 아닌 실제 프로젝트를 대상으로 테스트해야 했습니다.

버그 1: 잘못된 디렉토리에서의 침묵하는 실패 (Silent Failure)

저는 주로 제 터미널이 위치해 있었기 때문에 SKILLmama 자체 리포지토리(repo) 내부에서 벡터 DB(vector-DB) 프롬프트를 실행했습니다. SKILLmama는 현재 디렉토리에서 FastAPI 파일을 스캔했고, (FastAPI 앱이 아닌 문서 리포지토리이므로) 아무것도 찾지 못하는 것을 정확히 확인했습니다. 그런데 그냥... 계속 진행해 버렸습니다. 빈 스택 프로필(stack profile) 상태로, 아무런 문제가 없는 것처럼 계속 검색을 이어갔습니다.

이런 종류의 실패는 아무도 보고하지 않습니다. 왜냐하면 겉으로 보기에는 아무것도 고장 난 것처럼 보이지 않기 때문입니다. 그저 조용히 더 나쁜 답변을 내놓을 뿐입니다.

해결책: 사용자가 인라인으로 스택(stack)을 언급했는데 스캔된 디렉토리에서 그 흔적이 발견되지 않는다면, 빈 패스(empty pass)를 완료하는 대신 중단하고 대신 어떤 디렉토리를 스캔할지 물어봐야 합니다.

이 디렉토리에서 FastAPI를 찾을 수 없습니다. 해당 프로젝트가 아닌 것 같습니다. 다른 폴더를 스캔할까요, 아니면 로컬 확인 없이 말씀하신 내용을 바탕으로 검색을 진행할까요?

버그 2: 검증되지 않은 확신에 찬 숫자들

SKILLmama의 호환성(Compatibility) 점수에는 이미 다음과 같은 규칙이 있었습니다: 점수를 매기기 전에 로컬에서 검증할 것, 단순히 추론하지 말 것. 올바른 환경 변수(env var)가 있는지 .env.example을 확인하고, 필수 CLI가 PATH에 있는지 확인하며, 추측하지 마십시오.

하지만 동일한 공식 내에서 바로 옆에 위치한 유지보수(Maintenance) 항목에는 그와 대등한 규칙이 없었습니다. 실제 검색을 실행했을 때, 세 명의 후보자 중 두 명은 마지막 커밋 날짜(last-commit date)를 검색 결과에서 가져왔습니다. 세 번째 후보자는 해당 조직(org)이 보통 얼마나 활발한지에 대한 일반적인 지식으로부터 숫자를 얻었습니다. 세 명 모두 동일한 표에 앉아 있었고, 똑같이 신뢰할 수 있는 것처럼 보였습니다.

해결책: 이제 유지보수(Maintenance)는 호환성(Compatibility)이 이미 가지고 있던 것과 동일한 규칙, 즉 점수를 매기기 전에 검증하고 추론하지 말라는 규칙에 따라 실행됩니다. 실제 마지막 커밋 날짜를 찾을 수 없는 경우, 점수는 확신에 찬 듯한 추측 대신 N/A (unverified)로 표시되며, 총점은 남은 요소들을 기준으로 재정규화(renormalize)됩니다.

버그 3은 다른 종류의 테스트가 필요했습니다

처음 두 개의 버그는 파이프라인(pipeline)을 단순히 실행하고 지켜보는 것에서 발견되었습니다. 세 번째 버그는 Schmid의 강연이 실제로 다루었던 내용에 더 가까운 것이 필요했습니다: 기술(skill)이 있는 경우와 전혀 없는 경우를 비교하는 것, 동일한 질문, 동일한 프로젝트를 병렬로 실행하는 것입니다. 그것은 여기 한 단락으로 다루기에는 너무 길어서 별도의 포스트로 다룰 만한 가치가 있는 별개의 이야기입니다. 요약하자면: 이는 SKILLmama가 특정 호스팅 플랫폼에 대한 후보자의 적합성을 점수 매기는 방식의 사각지대를 드러냈으며, 이를 수정함으로써 실제 추천 결과가 뒤집혔습니다. 해당 수정 사항은 아래의 두 가지와 함께가 아니라, 해당 포스트와 함께 배포됩니다.

무엇이 바뀌었나

처음 두 가지 수정 사항은 현재 v1.4.4 및 v1.4.5 버전으로 네 가지 어댑터(Claude Code, Claude.ai, OpenAI Codex, Antigravity) 전체에 적용되어 라이브 상태이며, 어느 하나가 다른 것들과 조용히 어긋나지 않도록 동기화되어 유지됩니다.

npx skills add Magithar/SKILLmama -a claude-code

전체 실행 로그, 정확한 프롬프트 (prompts), 그리고 사후에 정리된 것이 아닌 버그가 실제로 나타났던 정확한 출력값 (outputs)을 모두 확인하고 싶다면, 평가 하네스 (eval harness)는 evals/skillmama-ablation.md에 있습니다.

github.com/Magithar/SKILLmama, Apache 2.0.

공로를 돌리자면: 이 모든 우회 과정은 Philipp Schmid의 강연과 그가 참조한 SkillsBench 논문(Li et al., arxiv.org/abs/2602.12670)에서 시작되었습니다. 해당 연구는 사람이 작성한 기술 (skills)이 작업 성능을 평균 약 15~16%포인트 향상시키는 반면, AI가 생성한 기술은 토큰 (tokens)만 낭비할 뿐 아무런 도움이 되지 않는 불필요한 내용 (filler)을 추가하는 경우가 많다는 것을 발견했습니다. 만약 당신이 기술을 유지 관리하고 있으면서 아직 라벨링된 프롬프트 세트 (labeled prompt set)를 통해 실행해 보지 않았다면, 그것이 바로 당신이 해야 할 숙제입니다. 이 포스트를 쓰는 것보다 시간이 덜 걸릴 것입니다.