이번 주에는 AI 툴링(tooling)이 무거운 프로토콜 통합(MCP 서버, 도구 스키마, 인증 흐름)에서 훨씬 더 가벼운 무언가인 **에이전트 기술 (Agent Skills)**로 이동하고 있다는 공감대가 형성되고 있습니다. 에이전트 기술이란 모델이 하나의 작업을 잘 수행하도록 가르치는 휴대 가능한 마크다운 (markdown) 파일입니다. 기술 (Skills)은 작성 비용이 더 저렴하고, 버전 관리가 용이하며, 도구 간에 이동할 수 있습니다.

하지만 아무도 이야기하지 않는 함정이 있습니다. 기술 (Skill)은 단지 야심 찬 프롬프트 (prompt)일 뿐이라는 점입니다. 그리고 프롬프트는 모델에 따라 다르게 동작합니다. 하나의 프론티어 모델 (frontier model)에서 아름다운 구조화된 출력 (structured output)을 생성하는 기술 (Skill)이, 더 작거나 다르게 튜닝된 모델에서는 무너질 수 있습니다. 코딩 어시스턴트, 문서 생성기, 내부 자동화 등 기술 (Skills)을 기반으로 무엇인가를 구축하고 있다면, 유료 API를 연결하여 토큰 (tokens)을 태우기 전에 어떤 모델이 실제로 당신의 기술 (Skill)을 올바르게 실행하는지 알아야 합니다.

이 글은 이를 위해 제가 권장하는 워크플로우를 소개합니다. 즉, 여러 모델을 대상으로 기술 (Skill)을 실행하고, 가능한 경우 출력을 결정론적 (deterministically)으로 점수화하며, 충분히 괜찮은 가장 저렴한 모델이 무엇인지 알려주는 작고 재현 가능한 평가 하네스 (evaluation harness)입니다. 핵심적인 지원 요소는 반복 작업(iteration)을 하는 동안 API 비용을 지불할 필요 없이, 무료 모델 액세스를 통해 이 모든 것을 수행할 수 있다는 점입니다.

"플레이그라운드(playground)에서 잘 작동했다"는 방식의 문제점

대부분의 사람들은 다음과 같이 기술 (Skill)을 테스트합니다:

1. 기술 (Skill)을 채팅 UI에 붙여넣습니다.
2. 입력값을 하나 줍니다.
3. 출력을 눈으로 확인합니다. 좋아 보입니다. 배포합니다.

이 방식은 세 가지 측면에서 실패합니다:

• 하나의 입력값으로는 아무것도 알 수 없습니다. 기술 (Skills)은 엣지 케이스 (edge cases), 즉 빈 입력, 적대적 포맷팅 (adversarial formatting), 예상 길이의 두 배인 입력값 등에서 실패합니다.
• 하나의 모델로는 아무것도 알 수 없습니다. 당신이 우연히 열어본 모델에서 기술 (Skill)이 견고한 것인지, 아니면 단순히 운이 좋았던 것인지 알 수 없습니다.
• 느낌(Vibes)으로는 차이(diff)를 비교할 수 없습니다. 다음 주에 기술 (Skill)을 수정할 때, 그것을 더 좋게 만들었는지 아니면 더 나쁘게 만들었는지 판단할 기준점 (baseline)이 없습니다.

해결책은 우리가 코드에 적용하는 것과 동일합니다. 바로 테스트 스위트 (test suite)입니다.

결과물: 기술 (Skill) 평가 하네스 (evaluation harness)

아래는 최소한의 실행 가능한 하네스 (harness)입니다 (Python 기반이며, requests와 엔드포인트 설정을 위한 .env 파일 외에는 별도의 의존성이 없습니다). 이는 오늘날 대부분의 호스팅 모델 제공업체(무료 티어 포함)가 지원하는 OpenAI 호환 채팅 완성 (chat completions) API를 가정합니다.

# skill_eval.py
import json, os, sys, time
import requests
...

그리고 의도적으로 까다로운 엣지 케이스 (edge cases)를 포함한 테스트 케이스 파일입니다:

[
  {
    "name": "happy path",
...

주목할 만한 두 가지 설계 결정 사항은 다음과 같습니다:

• temperature: 0 설정은 실행 결과들을 비교 가능하게 만듭니다. 샘플링 노이즈 (sampling noise)가 포함된 기술 (Skill) 평가는 점성술과 다를 바 없습니다.
• 결정론적 체크 (Deterministic checks)를 우선시하십시오. LLM-as-judge (판단자로서의 LLM)는 나중에 유용하지만, 먼저 신뢰할 수 있는 체크부터 시작하십시오: 유효한 JSON, 필수 부분 문자열 (substrings), 길이 제한, 스키마 검증 (schema validation) 등입니다. 이러한 방식이 기술 (Skill) 퇴보 (regressions)의 80%를 잡아냅니다.

무료 티어가 실제로 중요한 이유

이 워크플로우의 솔직한 경제학은 다음과 같습니다: 진지한 기술 (Skill) 평가는 4개의 모델 × 4~12개의 케이스 × 기술을 수정하는 동안 발생하는 여러 번의 반복 과정을 거칩니다. 무언가를 확정하기 전에 이미 수백 번의 호출이 발생할 수 있습니다. 유료 API 가격을 적용하면, "이 기술 (Skill) 아이디어는 작동하지 않는다"라는 결론으로 끝날 수도 있는 작업에 대해 실제 청구서가 발행되는 셈입니다.

이것이 바로 제가 사람들에게 MonkeyCode를 안내해 온 이유입니다. MonkeyCode는 일련의 모델에 대한 무료 액세스와 무료 서버 옵션을 제공하며, 이는 모델의 다양성이 필요하고 비용에 대한 불안이 없어야 하는 바로 이 단계 — 즉, 평가 및 반복 (evaluation and iteration) 단계에 매우 실용적인 샌드박스 (sandbox)가 되어줍니다. 공개 사항: 이 기사는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다.

구체적으로는: MC_ENDPOINT를 MonkeyCode 서버로 지정하고, 비교하려는 모델들을 CLI 인자로 나열한 뒤 하네스 (harness)를 실행하면 됩니다. 기술 (Skill) 파일과 테스트 케이스는 리포지토리 (repo) 내의 일반 파일이므로, 나중에 유료 프로덕션 엔드포인트로 이동할 때 환경 변수 하나만 변경하면 전체 테스트 스위트 (test suite)를 그대로 가져갈 수 있습니다. 이러한 이식성 (portability)이야말로 무거운 통합 대신 기술 (Skills) 중심 접근 방식을 취하고, 평가 하네스 (eval harness)를 제공업체에 종속되지 않게 유지할 때 얻을 수 있는 진정한 승리입니다.

결과 읽기: 결정 테이블 (decision table)

model_a: 4/4, model_b: 3/4, model_c: 2/4와 같은 요약 결과가 나왔을 때, 단순히 점수가 가장 높은 모델을 선택하지 마세요. 다음과 같이 결정하십시오:

한계점 및 권장하지 않는 대상

• 결정론적 체크(Deterministic checks)는 품질을 판단할 수 없습니다. "올바른 이름을 포함한 유효한 JSON"이 곧 "좋은 요약"을 의미하지는 않습니다. 주관적인 품질을 위해서는 결국 인간의 검토나 LLM-as-judge(판단자로서의 LLM)가 필요합니다. 이 테스트 프레임워크(harness)를 품질의 신탁(oracle)이 아닌, 회귀 테스트 게이트(regression gate)로 취급하십시오.
• 무료 티어는 변경됩니다. 모든 무료 서비스의 가용성, 속도 제한(rate limits), 모델 라인업은 예고 없이 변경될 수 있습니다. 프로덕션 출시를 위한 CI(지속적 통합) 과정에서 무료 엔드포인트(endpoint)에 절대 하드 의존(hard-depend)하지 마십시오. 반복 작업(iteration)에는 사용하되, 결과를 스냅샷으로 저장하고 출시 전 프로덕션 제공업체에서 다시 검증하십시오.
• 무료 서버는 민감한 데이터용이 아닙니다. 독점적인 코드베이스, 고객 데이터 또는 비밀 정보를 어떠한 무료 제3자 엔드포인트를 통해서도 전송하지 마십시오. 테스트 케이스를 정제(sanitize)하십시오.
• 적은 케이스 수는 기만적일 수 있습니다. 4개의 케이스는 스모크 테스트(smoke test)일 뿐입니다. 실제 출시 전에는 실제 입력 분포를 커버할 수 있도록 테스트 스위트를 확장하십시오.
• 만약 여러분의 "Skill"이 실시간 도구, 인증(auth), 또는 부수 효과(side effects, 예: 티켓 읽기, 코드 배포)를 필요로 한다면, 이 프롬프트 수준의 프레임워크는 적절한 계층이 아닙니다. 그럴 때는 MCP 스타일의 통합 테스트(integration testing)가 그 복잡성을 정당화해 줄 것입니다.

요약 (Takeaway)

Skills 대 MCP 논쟁은 더 유용한 핵심을 놓치고 있습니다: 어떤 메커니즘을 선택하든, 지침(instructions)이 곧 제품이며, 지침은 테스트를 받을 자격이 있다는 점입니다. 60줄 정도의 프레임워크, 몇 가지 적대적 케이스(adversarial cases), 그리고 무료 모델 샌드박스(sandbox)만 있다면 "플레이그라운드(playground)에서 보기에 괜찮아 보임"이라는 막연한 느낌을 실제적인 결정으로 대체하기에 충분합니다.

결제 설정을 먼저 하지 않고 워크플로우를 테스트해보고 싶다면, MonkeyCode의 무료 모델 액세스(free model access)를 첫 번째 스윕(sweep)을 실행하기 위한 합리적인 장소로 활용하세요. 그 후 동일한 스위트(suite)를 여러분이 실제로 배포하는 어떤 환경으로든 가져가서 사용하면 됩니다.