🔥 Skillify: Garry Tan이 AI 에이전트 실수를 구조적으로 없애는 법
강의 목차
오늘 저녁 Garry Tan의 X 피드를 열었다가 커피잔을 다시 내렸다. 제목이 "How to really stop your agents from making the same mistakes"였다. 나도 요즘 내가 굴리는 에이전트가 같은 실수를 반복하는 꼴을 매일 본다. LangChain의 테스트 프레임워크를 깔아놓고도 뭘 어떻게 테스트해야 할지 감을 못 잡던 참이었다.
Garry는 YC 대표이자 GStack/GBrain을 만든 사람이다. 이번에 그가 내놓은 답은 "Skillify"다. 말이 거창해 보여도 원리는 단순하다. 모든 실패를 스킬로 영구화하라.
무슨 일이 일어났나
Garry는 자기 에이전트가 일주일 사이 두 번 헛짓을 했다고 적었다. 문제를 프롬프트 수정으로 덮지 않고, 실패 하나를 SKILL.md와 테스트 세트로 못 박는 10단계 체크리스트를 공개했다.
출발점에는 랭체인에 대한 노골적인 비판이 있다. LangChain은 2025년 10월까지 누적 1.6억 달러를 모아 12.5억 달러 밸류에이션에 도달했다 (verified 2026-04-22). LangSmith는 trajectory eval, LLM-as-judge, regression suite까지 꽤 정교한 도구를 제공한다. Garry의 표현을 그대로 옮기자면, "조각은 있지만 실무(practice)는 없다"는 것이다.
"LangChain gives you testing tools. It never tells you what to test, in what order, or when you're done."
결국 프레임워크를 고른 사용자는 "운동 계획 없는 헬스장 멤버십"을 얻은 셈이라는 비유다. 많은 AI 사용자가 에이전트를 테스트하지 않는 이유도 거기에 있다는 주장이 이어진다.
실패 두 개의 해부
Garry가 공개한 사례는 상당히 구체적이다.
실패 1. 10년쯤 전 싱가포르 출장을 언제 다녀왔냐고 물었더니, 에이전트가 살아있는 캘린더 API를 세 번 때려보고, 이메일 검색을 헤매다가 5분이 지나서야 로컬 인덱스에서 즉답을 찾았다. 3,146개의 캘린더 파일이 이미 grep 한 방이면 되는 자리에 놓여 있었는데, 에이전트는 쳐다보지도 않았다.
실패 2. 같은 날, "다음 미팅 28분 남았어요"라고 우겼다. 실제로는 88분이 남아있었다. UTC→PT 시차 계산을 머릿속에서 하다가 정확히 한 시간 틀린 것이다. 이미 context-now.mjs라는 스크립트가 50ms 안에 정답을 내뱉도록 만들어져 있었는데도 돌리지 않았다.
두 실패는 모양이 똑같다. 결정론적으로 끝낼 수 있는 일을 에이전트가 latent space, 그러니까 판단 공간에서 해결하려 들었다. 이게 Garry가 지난달부터 반복해 온 "thin harness, fat skills" 프레임의 핵심 경고다. 판단이 필요한 일은 마크다운 스킬로 밀어 넣고, 정확해야 할 일은 코드로 내려놓고, 런타임 자체는 얇게 유지해라. Skillify는 그 프레임에 "결함 관리"라는 고리를 하나 더 건 것이다.
Skillify 체크리스트 10단계
본문에서 제시한 10단계를 내 식으로 축약하면 이렇다.
- SKILL.md: 이름, 트리거, 강제 규칙을 담은 계약서
- 결정론적 스크립트: LLM이 할 필요 없는 일은 코드로
- 유닛 테스트: 순수 함수 단위 (글에서는 vitest, 공개된 GBrain 코드는
bun test) - 통합 테스트: 실제 데이터와 엔드포인트
- LLM 평가: LLM-as-judge로 품질과 프로세스 채점
- Resolver 트리거:
AGENTS.md에 라우팅 등록 - Resolver 평가: 라우팅이 진짜로 먹히는지 검증
- Check-resolvable + DRY 감사: 닿지 않는 스킬, 중복 스킬 탐지
- E2E 스모크 테스트: 파이프라인 끝까지
- 파일링 규칙: 지식 베이스 어디에 저장할지
10번까지 통과 못 하면 Garry의 기준에선 그건 스킬이 아니라 "오늘은 어쩌다 돌아가는 코드"다. 좀 까칠해 보이지만, 내 에이전트의 skills 폴더를 열어보면 반도 못 지킨다는 걸 인정해야겠다.
흥미로운 건 5번과 7번이다. LLM 평가는 단순히 출력 품질만 보는 게 아니라 프로세스도 본다. "15분 뒤 SFO 공항 도착할 수 있을까요?" 같은 프롬프트에서 에이전트가 context-now.mjs를 먼저 돌리지 않고 머릿속 계산으로 답하면, 그 eval은 실패 처리된다. 정답이어도 실패다. 이번엔 운 좋게 맞았지만 다음엔 틀릴 테니까.
Resolver 평가는 "이 의도는 이 스킬로 라우팅돼야 한다"는 50개 이상의 테스트 케이스를 돌린다. False negative(맞아야 하는데 안 걸리는 경우)와 false positive(엉뚱한 스킬이 걸리는 경우) 둘 다 잡는다. 40개 넘는 스킬을 쌓아본 사람이라면 이 고민이 남 얘기가 아닐 것이다. deploy-k8s와 kubernetes-deploy가 동시에 존재하고, 둘 중 어느 쪽이 뽑힐지는 매번 주사위다. 내 경험상 이런 암묵적 충돌은 월요일에 작성한 스킬이 목요일엔 잊혀지면서 시작된다.
"Skillify"가 동사가 되다
이 부분이 진짜 매력적이었다. Garry는 에이전트와 대화로 무언가를 해결한 뒤, 한마디만 던진다.
"hot damn it worked. can you remember this as a webhook skill and skillify it"
그러면 에이전트가 한 시간 동안 쌓은 맥락을 SKILL.md, 스크립트, 테스트, resolver 트리거, 문서로 응고시킨다. 다음번에 같은 문제를 만났을 때 이 지식은 자동으로 불려 나온다. 프로토타입이 그 자리에서 영구 인프라가 되는 워크플로우다.
OAuth 웹훅을 한 시간 삽질한 뒤 "skillify it"만 치면, 다음에 웹훅이 필요할 때는 스킬이 알아서 돈다. ngrok 링크를 보낼 때 반드시 curl로 활성 상태를 확인해달라는 요구도 한 줄이면 끝난다. 내가 보기엔 Garry가 말하는 "열 단어로 된 스펙"이 이 체크리스트 전체를 소환하는 셈이다.
내 작업 흐름에 대입해봤다. 블로그 글쓰기에서 자꾸 반복하는 문제(예: 링크 검증을 빼먹는다거나)를 생각해보면, 같은 실수를 세 번 만날 즈음에야 유틸을 하나 만든다. Garry의 프레임에선 한 번 만나자마자 "skillify it"이고, 그 자리에서 테스트까지 달린다.
Hermes Agent만으로는 부족하다는 주장
Garry는 Nous Research의 Hermes Agent를 좋게 평가하면서도 선을 긋는다. Hermes는 skill_manage라는 툴을 통해 에이전트가 직접 스킬을 만들고 고치고 지운다. 도구 호출이 다섯 번 이상인 복잡한 작업이 끝나면 자동으로 SKILL.md를 발행한다. 메모리 상한, 조건부 활성화, progressive disclosure까지 똑똑하게 설계돼 있다.
그런데 Hermes는 "생성"까지만 한다. 결정론적 코드에 유닛 테스트가 있는가? Resolver가 제대로 라우팅되는가? 상류 API가 바뀌어서 스킬이 조용히 쓰레기를 반환하고 있지 않은가? 이걸 매일 체크하는 건 GBrain의 몫이라는 설명이다. GBrain v0.10부터는 24개의 fat skill과 e2e/eval/unit test를 기본 탑재했다고 한다.
2005년 소프트웨어 공학이 정리한 명제, "테스트 없는 코드는 썩는다"를 에이전트 스킬에 그대로 이식했다는 게 Garry의 주장이다. 이 정도면 반박하기 어렵다.
내가 앞으로 할 것
처음에는 솔직히 "또 하나의 프레임워크 마케팅인가" 싶었다. 근데 글을 다 읽고 나니 방어하기가 힘들다. 내 에이전트 설정을 열어봐도 SKILL.md 몇 개 있을 뿐이고, resolver 평가는 없고, dark skill이 몇 개 있는지도 모른다. "오늘 어쩌다 돌아가는 코드"라는 표현이 아픈 이유는 그게 내 현실이기 때문이다.
당장 이번 주말에 해볼 일을 세 가지로 정리했다.
- 지금 있는 스킬들에 대해 check-resolvable 스크립트를 직접 만들어보기. 10개도 안 되니 한 시간이면 될 것 같다.
- 최근 일주일 내 에이전트가 헛짓한 케이스 두세 개를 뽑아서 SKILL.md와 유닛 테스트까지 만들어보기. "skillify it"을 실제로 쳐보는 게 목적이다.
- Garry의 GBrain 저장소를 클론해서
gbrain doctor가 뭘 어떻게 검사하는지 읽어보기.
에이전트가 같은 실수를 반복하는 게 짜증나는 건, 결국 내 시간이 반복해서 새어 나가서다. Garry가 1년 동안 축적해 온 실수들이 그의 에이전트를 만들어간다고 했다. 나도 이번 주 내 에이전트의 실수 한 개라도 영구화할 수 있으면, 다음 주의 미주는 그만큼 덜 짜증 낼 수 있을 것이다. 그거면 충분한 이유다.
참고 자료
- How to really stop your agents from making the same mistakes — Garry Tan — 본 글의 원 출처
- Thin Harness, Fat Skills — Garry Tan — Skillify 밑에 깔린 아키텍처 철학
- GBrain GitHub — Skillify 체크리스트를 집행하는 오픈소스 엔진
- GStack GitHub — Garry의 Claude Code용 코딩 스킬 패키지
- Hermes Agent — Nous Research —
skill_manage툴을 탑재한 자율 스킬 생성 에이전트 - LangSmith Evaluation — LangChain의 trajectory 및 LLM-as-judge 평가 플랫폼
- TechCrunch: LangChain hits $1.25B valuation — LangChain 누적 펀딩 맥락
YouTube 영상
