AI 에이전트 실패를 재사용 가능한 'Skill'로 만드는 Skillify 방법론 분석 (id.news.hada.io)
목차(4)
한줄 요약
AI 에이전트가 같은 실수를 반복하지 않도록, 실패를 테스트 가능한 'Skill' 단위로 구조화하는 방법론이다.
무엇이 달라지나?
AI 에이전트 개발 현장에서 반복되는 고질적인 문제가 있다. 에이전트가 오답을 내면 프롬프트를 조금 수정하고, 얼마 뒤 비슷한 오류가 다시 발생한다. 이 사이클이 끊이지 않는 이유는 실패를 '구조'로 전환하지 않기 때문이다.
Y Combinator CEO 개리 탄이 제안한 Skillify는 이 문제를 정면으로 겨냥한다. 에이전트가 실패할 때 그 실패를 "Skill"로 변환한다. Skill은 세 가지 요소로 구성된다. 절차 지침을 담은 Markdown 파일(SKILL.md), 재현 가능한 결정론적 스크립트, 그리고 해당 Skill이 앞으로도 정상 동작하는지 검증하는 자동화 테스트다. 대화 중 "skillify it"이라고 말하면 에이전트가 10단계 프로세스를 자동으로 실행한다.
이 방법론의 핵심 통찰은 Latent와 Deterministic의 분리다. LLM이 판단해야 할 영역(추론, 맥락 이해)과 코드가 처리해야 할 영역(계산, 데이터 조회)을 명확히 나눈다. 실제 사례가 이를 잘 설명한다. 에이전트에게 "다음 회의가 언제냐"고 물었을 때 "28분 후"라고 답했지만, 실제로는 88분 후였다. LLM이 UTC→PT 시간대 변환을 머릿속으로 계산하다가 정확히 1시간을 틀린 것이다. 100ms 이내에 정확한 답을 줄 수 있는 스크립트가 이미 존재했는데도, 에이전트는 스크립트를 실행하는 대신 추론을 선택했다.
또 다른 사례에서는 10년 전 싱가포르 출장 일정을 묻자 에이전트가 외부 API를 5분간 호출하다가 뒤늦게 로컬에 이미 인덱싱된 3,146개의 캘린더 파일에서 바로 찾을 수 있다는 걸 발견했다. 스크립트로 즉시 해결 가능한 문제를 LLM 추론으로 돌린 전형적인 실수다.
10단계 체크리스트는 SKILL.md 작성 → 결정론적 스크립트 작성 → 유닛 테스트(vitest) → 통합 테스트 → LLM-as-judge 평가 → 트리거 리졸버 등록 → 리졸버 평가 → 도달 가능성/중복 감사 → E2E 스모크 테스트 → 브레인 파일링 규칙 순서로 진행된다. 이 모든 단계를 통과해야 비로소 하나의 Skill로 인정된다.
실무에서 어떤 의미인가?
LangChain처럼 1억 6천만 달러의 투자를 받은 프레임워크도 테스트 도구는 제공하지만, "무엇을 어떤 순서로 테스트해야 하는가"에 대한 워크플로우는 제공하지 않는다. Skillify는 이 공백을 채운다. 프레임워크가 헬스장 회원권이라면, Skillify는 구체적인 훈련 스케줄이다.
소프트웨어 공학에서 "모든 버그에는 회귀 테스트가 따라야 한다"는 원칙은 오래된 상식이다. 하지만 AI 에이전트 영역은 아직 이 수준에 도달하지 못했다는 게 개리 탄의 진단이다. 에이전트 Skill도 코드베이스처럼 테스트 없이는 시간이 지나면 腐敗(부패)한다.
또 하나 주목할 지점은 디스커버빌리티(discoverability) 문제다. 40개 이상의 Skill을 운영한 경험에서, 15%의 Skill이 리졸버에 등록되지 않아 사실상 어둠 속의 기능이 되어버렸다는 사실이 드러났다. 에이전트 시스템이 규모를 키울수록 어떤 Skill이 존재하는지 에이전트 자신이 인식하지 못하는 문제가 반드시 등장한다.
Nous Research의 Hermes Agent는 Skill을 자동으로 잘 생성하지만 검증 과정이 없다는 점도 언급된다. 생성과 검증, 두 가지가 함께 갖춰져야 한다는 것이 Skillify의 입장이다.
도입 전 체크포인트
Skillify 방법론을 실제 에이전트 시스템에 적용하기 전에 검토해야 할 사항들이 있다.
LLM 추론 vs. 스크립트 실행 경계 설계부터 시작하라. 현재 에이전트가 코드로 처리할 수 있는 작업을 LLM에게 맡기고 있지는 않은지 먼저 감사해야 한다. 시간대 변환, 날짜 계산, 로컬 파일 조회처럼 결정론적 정답이 존재하는 영역은 스크립트로 분리하는 게 기본이다.
테스트 인프라가 없다면 방법론 도입 전에 만들어라. vitest 같은 유닛 테스트 도구, 통합 테스트 환경, LLM-as-judge 평가 파이프라인이 미리 갖춰져 있어야 Skillify의 10단계가 의미를 가진다.
Skill 레지스트리를 처음부터 설계하라. 몇 개 안 될 때는 괜찮아 보여도, 규모가 커지면 리졸버에 등록되지 않은 Skill이 급증한다. 트리거 등록과 도달 가능성 감사를 처음부터 프로세스에 포함시켜야 한다.
실패 로그를 Skill 후보 큐로 연결하라. 에이전트가 실패할 때마다 그것이 자동으로 Skill화 프로세스의 입력이 되는 파이프라인을 구성해야 방법론이 지속 가능해진다.
자주 묻는 질문
Q.Skillify는 특정 프레임워크에서만 동작하는가?
원문에서 언급된 특정 기술 스택은 `vitest` 정도다. Skillify 자체는 프레임워크에 종속된 도구가 아니라 방법론이다. Markdown 파일 기반의 절차 문서, 결정론적 스크립트, 자동화 테스트를 조합할 수 있는 환경이라면 어떤 에이전트 시스템에도 적용 가능하다. LangChain을 사용하든 다른 프레임워크를 사용하든, 핵심은 실패를 구조화된 Skill로 전환하는 워크플로우를 갖추는 것이다.
Q.LLM-as-judge 평가 단계가 왜 필요한가?
결정론적 스크립트와 유닛 테스트만으로는 LLM의 추론 품질을 검증하기 어렵다. LLM이 개입하는 Latent 영역, 즉 맥락 이해나 판단이 필요한 부분은 다른 LLM이 평가자 역할을 하는 LLM-as-judge 방식이 현실적인 대안이다. 이 단계를 빠뜨리면 스크립트는 정상이지만 LLM 판단 오류가 반복되는 상황을 잡아낼 수 없다. 생성과 검증을 함께 갖추라는 Skillify의 원칙이 이 단계에서 가장 잘 드러난다.
Q.Skill이 '腐敗한다'는 게 구체적으로 어떤 상황인가?
API 스펙이 바뀌거나, 데이터 포맷이 변경되거나, 의존하는 외부 서비스가 업데이트될 때 기존 Skill이 조용히 오작동하기 시작하는 상황을 말한다. 테스트가 없으면 이 오작동이 발생해도 알아챌 방법이 없다. Skillify가 모든 Skill에 자동화 테스트를 필수로 요구하는 이유가 바로 이것이다. 코드베이스에서 테스트 없는 레거시 코드가 유지보수 지옥이 되듯, 테스트 없는 Skill도 동일한 문제를 일으킨다.