AI 에이전트가 같은 실수를 반복하지 않게 만드는 확실한 방법

LangChain 이 1억 6천만 달러를 모금했습니다. 3년 간의 개발 끝에 기업 가치는 10억 달러에 달합니다. 테스트 플랫폼인 LangSmith 는 정말 정교합니다: 트레이젝토리 평가, 추적-데이터셋 파이프라인, LLM-as-judge, 회귀 테스트 스위트, 도구를 위한 유닛 테스트 프레임워크까지 갖추고 있습니다. 필요한 조각들은 모두 있습니다. 인정할 것은 인정합시다.

하지만 조각들이 모인다고 실천이 되는 건 아닙니다.

LangChain 은 테스트 도구를 제공합니다. 무엇을, 어떤 순서로 테스트해야 하는지, 언제 테스트가 완료된 것인지는 전혀 알려주지 않습니다.

다음과 같은 단계별로 구성된, 분명한 의견이 담긴 워크플로우는 존재하지 않습니다:

• 이런 실패가 발생했다
• 이제 스킬을 작성하라
• 이제 결정론적 코드를 작성하라
• 이제 유닛 테스트를 작성하라
• 이제 LLM 평가를 작성하라
• 이제 리졸버 트리거를 추가하라
• 이제 리졸버를 평가하라
• 이제 중복을 감사하라
• 이제 스모크 테스트를 하라
• 이제 올바르게 파일링하라

그런 루프는 존재하지 않습니다. 흩어진 기본 요소들로부터 스스로 발명해야 합니다. 많은 AI 사용자들이 여전히 에이전트를 전혀 테스트하지 않습니다. 선택한 프레임워크가 아마 운동 계획 없이 헬스장 멤버십만 준 것과 같기 때문입니다.

대부분의 AI 에이전트 "신뢰성"은 감(感)에 의존합니다. 프롬프트 수정. 더 큰 시스템 메시지. "환각을 생성하지 마세요" 같은 주문. 이런 것들은 대화가 복잡해지는 순간 무너집니다. 이 문제를 해결하기 위해 수억 달러를 모금한 프레임워크들은 모니터링 대시보드와 유닛 테스트 도우미를 제공하고 "행운을 빕니다"라고 말할 뿐입니다.

제 에이전트가 이번 주에 두 번 실수했습니다. 어떤 실패도 다시 일어나서는 안 됩니다. 제가 친절하게 부탁했기 때문이 아닙니다. 각 실패를 영구적인 구조적 수정으로 바꿨기 때문입니다: 매일, 영원히 실행되는 테스트가 있는 스킬로 말이죠.

저는 이 실천법을 "스킬리파이(skillify)"라고 부릅니다. 일단 사용하면, 에이전트가 같은 실수를 반복하지 않을 것입니다. 작동 방식은 이렇습니다.

실패 1: 이미 데이터베이스에 있던 출장

거의 10년 전, 캘린더 기록 어딘가에 묻혀 있는 오래된 출장에 대해 제 OpenClaw 에게 물어봤습니다. 간단한 질문이었고, 1초면 답이 나올 거라 생각했습니다.

하지만 에이전트는 이렇게 행동했습니다:

1. 실시간 캘린더 API 호출 → 차단됨 (너무 과거라서).
2. 이메일 검색 시도 → 잡음만 많고 결정적인 결과 없음.
3. 다른 파라미터로 캘린더 API 다시 시도 → 여전히 차단됨.
4. 5분 후, 로컬 지식 베이스를 검색해서 즉시 찾음.

답은 처음부터 제 데이터 속에 있었습니다. 2013년부터 2026년까지 3,146개의 캘린더 파일. 이미 인덱싱되어 있고, 이미 로컬에 있었습니다. grep 한 번이면 되는 거였죠.

에이전트가 그냥 거기를 먼저 보지 않은 겁니다.

제가 계속 글을 쓰고 있는 프레임워크(얇은 하네스, 두꺼운 스킬)에는 판단이 필요한 작업과 정밀함이 필요한 작업 사이의 중요한 구분이 있습니다. 저는 그것들을 잠재적(latent) 그리고 결정론적(deterministic)이라고 부릅니다. 캘린더 grep 은 결정론적입니다. 같은 입력, 같은 출력, 매번 동일합니다. 모델이 필요 없습니다. 하지만 에이전트는 어쨌든 잠재 공간에서 이 작업을 수행하며, 추론을 가동하고, API 를 호출하고, 결과를 해석했습니다. 단 세 줄짜리 스크립트로 즉시 답을 얻을 수 있었음에도 말이죠.

그것이 버그입니다. 틀린 답변이 아니라, 잘못된 측면에서 접근한 겁니다.

수정: calendar-recall (1단계 + 2단계)

얇은 하네스 / 두꺼운 스킬에서 스킬은 모델에게 작업에 접근하는 방법을 가르치는 마크다운 절차입니다. 무엇을 할지는 사용자가 제공합니다. 스킬은 과정을 제공합니다. 마치 메서드 호출과 같습니다: 동일한 절차이지만, 전달하는 내용에 따라 완전히 다른 결과가 나옵니다.

이번 실패에서 나온 스킬은 다음과 같습니다:

name: calendar-recall description: "Brain-first historical calendar lookup. ALWAYS use this before any live API for any event not in the future or the last 48 hours."

그리고 내부의 엄격한 규칙:

Live calendar APIs are ONLY for events in the FUTURE or the LAST 48 HOURS. Everything historical goes through the local knowledge base first.

이것이 작동하게 만드는 핵심은 바로 에이전트가 결정론적 스크립트를 직접 작성했다는 점입니다. 스킬 파일(마크다운, 잠재 공간에 존재)은 에이전트에게 문제를 어떻게 고칠지 알려줍니다. 에이전트는 스킬을 읽고, 캘린더 검색이 결정론적 작업임을 이해하고, 이를 처리할 스크립트를 생성했습니다:

$ node scripts/calendar-recall.mjs search "Singapore"

Found 2 matching day(s): ── 2016-05-07 ── Flight to Singapore, Mandarin Oriental check-in ── 2016-05-08 ── Lunch with investors at Fullerton Hotel

실행 시간이 100밀리초 미만인 코드입니다 (대부분 Bun 시작 시간이며, 실제 grep 은 1밀리초 미만). LLM 호출 없음. 네트워크 없음. 그저 로컬 파일일 뿐입니다.

전체 아키텍처가 작동하게 만드는 루프는 바로 이것입니다: 잠재 공간이 결정론적 도구를 구축하고, 결정론적 도구가 잠재 공간을 제약합니다. 에이전트는 calendar-recall.mjs 를 작성하기 위해 판단(잠재)을 사용했습니다. 이제 스킬은 에이전트가 캘린더 데이터에 대해 추론하는 대신 해당 스크립트를 실행하도록 강제합니다. 모델의 지능이 모델이 어리석은 짓을 하지 못하게 하는 제약 조건을 생성한 것입니다.

과거의 실패 경로는 구조적으로 도달할 수 없게 됩니다. 스킬은 "로컬을 먼저 검색하라"고 말합니다. 스크립트가 검색을 수행합니다. 에이전트는 이에 대해 똑똑한 척 하거나 다시 실수할 기회를 얻지 못합니다.

실패 2: "28분" (1단계 + 2단계 반복)

같은 날. 에이전트가 말합니다: "다음 미팅까지 28분 남았습니다."

현실: 88분 남음. 에이전트가 머릿속으로 UTC→PT 시간대 계산을 하다가 정확히 1시간 차이가 났습니다.

문제는, 이런 출력을 내는 스크립트(context-now.mjs)가 이미 존재했다는 것입니다:

{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "App Ops Sprint Planning", "minutesUntil": 88 }] }

약 50밀리초 만에 실행되는 코드입니다. 모호함이 전혀 없습니다. 에이전트가 그냥 실행하지 않은 겁니다.

이전과 같은 형태입니다: 결정론적 작업(타임스탬프 빼기)을 잠재 공간에서 수행한 것입니다. 스크립트에 답이 있었는데 모델이 암산을 하고 있었습니다.

수정: context-now, 스킬:

name: context-now description: "ALWAYS-ON discipline: run context-now.mjs before making ANY time-sensitive claim. Never do UTC→PT conversion in your head."

이러한 간단한 스킬이 있을 때와 없을 때의 차이는 다음과 같습니다:

스킬리파이: 여러분의 정신 건강을 지켜줄 패턴

두 번의 실패. 같은 형태. 에이전트는 올바른 도구를 가지고 있었지만, 규율 대신 영리함을 선택했습니다. 잘못된 기계 공간에서 잘못된 일이 일어났습니다.

일반적인 AI 설정에서, AI 는 사과하고, 더 잘하겠다고 약속하고, 2주 후에 다른 질문이나 다른 시간대로 같은 일이 다시 발생합니다. 에이전트는 버그에 대한 기억도, 버그에 대한 테스트도, 재발을 막을 방법도 없습니다.

스킬리파이가 해결책입니다. 모든 실패는 스킬이 됩니다. 모든 스킬에는 테스트가 있습니다. 버그는 구조적으로 반복이 불가능해집니다.

실패가 승격될 때 제가 사용하는 10가지 체크리스트는 다음과 같습니다:

□ 1. SKILL.md — 계약 (이름, 트리거, 규칙) □ 2. 결정론적 코드 — scripts/*.mjs (코드가 할 수 있는 일에 LLM 은 사용하지 않음) □ 3. 유닛 테스트 — vitest □ 4. 통합 테스트 — 라이브 엔드포인트 □ 5. LLM 평가 — 품질 + 정확성 □ 6. 리졸버 트리거 — AGENTS.md 의 항목 □ 7. 리졸버 평가 — 트리거가 실제로 라우팅되는지 확인 □ 8. 확인 가능 여부 + DRY 감사 □ 9. E2E 스모크 테스트 □ 10. 브레인 파일링 규칙

10가지 항목을 모두 통과하지 못하는 기능은 스킬이 아닙니다. 그냥 오늘 우연히 작동하는 코드일 뿐입니다.

위의 두 실패는 이미 1단계와 2단계를 거쳤습니다: SKILL.md(계약)를 작성하고, 결정론적 코드(에이전트가 구축한 다음 사용하는 스크립트)를 작성했습니다. 하지만 남은 8단계를 살펴보기 전에, 스킬리파이가 실제 사용에서 어떻게 보이는지 보여드리고 싶습니다. 단순히 실패에 대한 대응이 아니기 때문입니다. 그것은 동사가 되었습니다.

동사로서의 스킬리파이

저에게 있어, 제 OpenClaw(및 GBrain)를 구축할 때 체크리스트는 처음에는 실패 대응 프로토콜이었습니다. 그러다 제가 모든 것을 구축하는 방식이 되었습니다.

제 실제 워크플로우는 이렇습니다. 자연어로 에이전트와 대화합니다. 대화 속에서 함께 무언가를 구축합니다. 시도해보고, 작동하면 한 마디를 합니다:

Garry:

와, 드디어 작동했네. 이거 웹훅 스킬로 기억해서 스킬리파이 해줄래? 다음에 웹훅이 필요할 때 사용하게. 근데 왜 이걸 제대로 작동시키는 게 이렇게 어려웠을까? 어쨌든 지금은 좋아. DRY 도 적용해줘.

OAuth 웹훅 통합이었습니다. 작동시키는 데 한 시간을 썼습니다. 그리고 "스킬리파이 해줘"라는 말이 임시 세션을 테스트, 리졸버 항목, 문서를 갖춘 내구성 있는 스킬로 바꿔놓았습니다. 다음에 웹훅이 필요하면, 스킬이 존재합니다. 에이전트가 그것을 읽습니다. 그 한 시간 동안 얻은 고생 끝에 얻은 지식이 영구적으로 남게 됩니다.

또 다른 예입니다. 컨테이너가 특정 작업에는 헤드리스 브라우저가 필요하고, 다른 작업에는 제 데스크탑에서 헤드가 있는 브라우저가 필요하다는 것을 발견했습니다:

Garry:

좋아! 그러면 OpenClaw 에서 헤드리스 브라우저가 필요할 때마다 이걸 스킬로 기억해야겠어. 그리고 헤드가 있는 브라우저가 필요하면 사용자에게 gstack browser 를 실행하고 pair-agent 코드를 달라고 요청해야 한다는 것도 알게 됐어. 스킬리파이 해줘!

메시지 하나면 됩니다. 에이전트는 결정 트리, 결정론적 스크립트, 테스트를 포함한 skills/browser/SKILL.md 를 작성합니다. 이제 브라우저가 필요한 모든 향후 세션은 자동으로 올바른 도구로 라우팅됩니다.

또는 이런 경우도 있습니다. 에이전트가 실제로 작동하는지 확인하지 않고 계속 ngrok 링크를 보내는 것을 발견했습니다:

Garry:

링크를 보낼 때마다 curl 로 직접 확인해서 엔드포인트가 열려 있고 터널이 작동하는지 확인하는 스킬을 만들 수 있을까? 스킬리파이 해줘!

또는 거의 미팅을 놓칠 뻔했던 캘린더 이중 예약:

Garry:

여기 네가 작성해야 할 정기 스킬이 하나 있어. 캘린더 확인 스킬이야. 내일 오전 11시가 이중 예약되어 있어. 이런 것들을 확인하는 결정론적인 스킬을 만들어줘.

한 문장입니다. 코드, 스킬, 테스트, 리졸버 항목, 도달 가능성 감사. 10단계 체크리스트 전체가 한 번의 명령에 담겨 있습니다. 제 OpenClaw 는 그것을 알고, 실행하며, 이제는 하나의 루틴이 되었습니다. 수십 번 해봤습니다. 이것 없이는 살 수 없을 정도입니다.

패턴은 항상 같습니다: 대화 속에서 프로토타입을 만들고, 작동하는 것을 확인하고, "스킬리파이"라고 말하면 프로토타입이 영구적인 인프라가 됩니다. 저는 명세서를 작성하지 않습니다. 티켓을 제출하지 않습니다. 에이전트와 대화하고, 함께 문제를 해결하고, 그 해결책이 에이전트가 저 없이도 영원히 사용할 수 있는 스킬이 됩니다.

1억 6천만 달러의 프레임워크 자금이 놓친 것이 바로 이것입니다. 테스트 기본 요소가 아닙니다. 평가 도구가 아닙니다. 워크플로우입니다. 인간이 "잘 됐으니 이제 영구적으로 만들어"라고 말하는 순간, 시스템이 "영구적"이 무엇을 의미하는지 정확히 아는 것입니다: SKILL.md, 결정론적 코드, 유닛 테스트, 통합 테스트, LLM 평가, 리졸버 트리거, 리졸버 평가, DRY 감사, 스모크 테스트, 브레인 파일링. 열 단계. 한 단어.

나머지 8단계가 실제로 어떻게 적용되는지 보여드리겠습니다.

3단계: 유닛 테스트

클래식 vitest 입니다. 결정론적 함수, 결정론적 어서션. calendar-recall.mjs 는 parseEventLine, eventMatchesKeyword, searchKeyword, formatJson 과 같은 순수 함수를 내보냅니다. 각 함수는 픽스처 데이터(임시 디렉토리의 합성 캘린더 파일, 알려진 입력, 알려진 출력)에 대해 테스트됩니다.

이런 테스트가 잡아내는 버그의 종류: parseEventLine 이 위치 필드에 유니코드 문자가 있는 이벤트를 조용히 드롭하는 경우. dateFromPath 가 윤년 날짜에 대해 null 을 반환하는 경우. formatJson 이 참석자가 한 명일 때 attendees 배열을 생략하는 경우. 작고, 지루하고, 중요합니다. 스크립트가 잘못된 출력을 생성하면 스킬이 잘못된 답변을 생성하고, 에이전트는 자신 있게 잘못된 정보를 알려줍니다.

context-now 의 경우, 유닛 테스트는 시간대 형식, 조용한 시간 감지, DST 경계를 넘는 minutesUntil 계산을 검증합니다. 하나의 테스트는 DST 전환 3분 전의 시간을 입력으로 제공하고 출력이 60분 점프하지 않는지 확인합니다. 이것이 바로 "28분" 실패를 초래한 정확한 버그입니다. 이제 구조적으로 불가능해졌습니다.

저는 5개의 스위트에 걸쳐 179개의 유닛 테스트를 가지고 있습니다. 2초 미만으로 실행됩니다.

4단계: 통합 테스트

라이브 엔드포인트와 실제 데이터를 대상으로 합니다. calendar-recall.mjs 가 실제 브레인 저장소에서 이벤트를 실제로 찾는지, 테스트 픽스처에서만 찾는지 확인합니다. 캘린더 캐시가 오래되었거나 없을 때 context-now.mjs 가 유효한 JSON 을 생성하는지 확인합니다. 통합 테스트는 픽스처 데이터가 너무 깨끗했기 때문에 유닛 테스트가 놓치는 버그를 잡아냅니다. 실제 데이터에는 잘못된 형식의 이벤트 줄, 누락된 시간대 필드, Windows 줄 끝이 있는 캘린더 파일, 자정을 넘는 이벤트가 있습니다.

규칙: 스크립트가 실제 데이터에서 올바르게 작동하는지 수동으로 확인하고 있다면, 그 확인은 통합 테스트여야 합니다.

5단계: LLM 평가

여기가 흥미로워지는 부분입니다. 일부 출력은 평가에 판단을 필요로 합니다. "이 캘린더 요약이 유용한가?"는 스크립트가 예/아니오로 답할 수 있는 질문이 아닙니다. 그래서 LLM-as-judge 를 사용합니다: 한 모델이 다른 모델의 출력을 루브릭에 따라 평가하는 것입니다.

context-now 의 경우, 35개의 평가가 매일 실행됩니다. 그중 하나는 에이전트에게 "내 비행기가 약 45분 후에 출발하는데, SFO 에 제시간에 도착할 수 있을까?"와 같은 메시지를 제공하고, 에이전트가 답변 전에 context-now.mjs 를 실행하는지 아니면 머릿속으로 계산을 시도하는지 확인합니다. 에이전트가 유혹에 넘어가 스스로 시간을 계산하면 평가는 실패합니다.

또 다른 평가는 에이전트에게 UTC 타임스탬프를 제공하고 "그게 내 시간으로 몇 시지?"라고 묻습니다. 올바른 행동은 스크립트를 실행하고 결과를 인용하는 것입니다. 잘못된 행동은 정신적으로 변환을 수행하는 것입니다. 평가는 틀린 답변과 잘못된 과정을 모두 잡아냅니다. 왜냐하면 이번에 암산이 우연히 맞더라도 다음 번에는 틀릴 것이기 때문입니다.

제가 찾은 가장 솔직한 평가 휴리스틱: 대화 기록에서 "아 씨발"이나 "뭐야"라고 말한 부분을 검색해보세요. 그것들이 여러분이 놓치고 있는 테스트 케이스입니다.

6단계: 리졸버 트리거

리졸버는 컨텍스트에 대한 라우팅 테이블입니다: 작업 유형 X 가 나타나면 스킬 Y 를 로드합니다. 리졸버에 대한 자세한 내용은 여기에서 썼습니다. 각 스킬은 AGENTS.md 에 트리거 항목이 필요합니다. AGENTS.md 는 에이전트에게 어떤 스킬이 존재하고 언제 사용해야 하는지 가르치는 파일입니다.

리졸버 트리거는 마크다운 테이블의 행일 뿐입니다:

이 단계에서 잡아내는 버그: 새 스킬을 작성했지만 리졸버에 추가하는 것을 잊은 경우. 스킬은 존재합니다. 기능은 존재합니다. 시스템이 도달할 수 없습니다. 병원에 외과의사가 있지만 디렉토리에 등록되지 않은 것과 같습니다. 스킬이 아예 없는 것보다 더 나쁩니다, 시스템이 처리할 거라고 생각하기 때문입니다.

7단계: 리졸버 평가

이것은 대부분의 사람들이 완전히 놓치는 계층입니다. 리졸버 트리거는 "이 구문은 이 스킬로 라우팅되어야 한다"고 말합니다. 리졸버 평가는 실제로 그렇게 되는지 테스트합니다.

제 리졸버 평가 스위트는 다음과 같은 50개 이상의 테스트 케이스로 구성됩니다:

{ intent: 'check my signatures', expectedSkill: 'executive-assistant' }, { intent: 'who is Pedro Franceschi', expectedSkill: 'brain-ops' }, { intent: 'save this article', expectedSkill: 'idea-ingest' }, { intent: 'what time is my meeting', expectedSkill: 'context-now' }, { intent: 'find my 2016 trip', expectedSkill: 'calendar-recall' },

두 가지 실패 모드. 위음성: 스킬이 발동되어야 하지만, 트리거 설명이 잘못되었거나 누락되어 발동되지 않습니다. 위양성: 두 트리거가 겹쳐서 잘못된 스킬이 발동됩니다. "내일 내 캘린더 뭐 있지"는 calendar-check 로 라우팅되어야 하지, calendar-recall 이나 google-calendar 가 아닙니다. 세 가지 스킬, 세 가지 다른 시간 도메인, 그중 어느 것과도 합리적으로 일치할 수 있는 하나의 구문. 리졸버 평가는 사용자가 겪기 전에 모호함을 잡아냅니다.

저는 이러한 평가를 결정론적 구조 테스트(AGENTS.md 테이블이 올바른 매핑을 포함하는지)와 LLM 라우팅 테스트(주어진 의도에 대해 모델이 실제로 올바른 스킬을 선택하는지)로 모두 실행합니다. 두 계층 모두 중요합니다. 테이블이 올바를 수 있고, 모델이 여전히 트리거 설명이 모호하기 때문에 잘못 라우팅할 수 있습니다.

8단계: 확인 가능 여부 + DRY 감사

한 달 간 구축한 후, 40개 이상의 스킬이 생겼습니다. 일부는 특정 사건에 대한 응답으로 생성되었고, 다른 일부는 크론을 실행하는 하위 에이전트에 의해 생성되었습니다. 아무도 리졸버 테이블을 유지 관리하지 않았습니다. 스킬은 생성되었지만 등록되지 않았습니다.

그래서 check-resolvable 을 구축했습니다. 전체 체인을 검사하는 메타 테스트입니다: AGENTS.md 리졸버 → SKILL.md → 스크립트/크론. 유용한 작업을 수행하지만 리졸버에서 경로가 없는 스크립트가 존재한다면, 그것은 도달할 수 없는 것입니다. LLM 은 그것을 사용하는 방법을 결코 알지 못할 것입니다.

첫 실행에서 40개 이상의 스킬 중 6개의 도달할 수 없는 스킬을 발견했습니다. 시스템 기능의 15%가 암흑 상태였습니다.

• 비행기에 대해 물어봐도 아무도 호출할 수 없는 항공편 추적기.
• 크론에서만 실행되고 수동으로는 트리거될 수 없는 콘텐츠 아이디어 생성기.
• 스킬 디렉토리에 존재하지만 리졸버에 전혀 나열되지 않은 인용 수정기.

한 시간 만에 수정했습니다. AGENTS.md 에 트리거 항목을 추가하기만 하면 됩니다. 이제 check-resolvable 은 gbrain doctor 의 일부로 매주 실행됩니다. 세 가지를 확인합니다:

1. SKILL.md 가 있는 모든 스킬 디렉토리에 리졸버의 해당 항목이 있는지.
2. 스킬이 참조하는 모든 스크립트가 실제로 호출 가능한지(파일 존재, 올바른 함수 내보내기).
3. 모호한 라우팅을 유발할 수 있는 중복 트리거 설명을 가진 스킬이 없는지.

DRY 감사도 함께 실행됩니다. 조심하지 않으면 비슷한 작업을 수행하는 15개의 스킬이 생기고, 리졸버는 주사위 굴리기로 선택하게 됩니다. calendar-recall 의 경우:

같은 도메인의 4개 스킬. 중복 없음. 각자 자신의 차선이 있습니다. 이 매트릭스는 이 글을 위해 그린 다이어그램이 아닙니다. SKILL.md 안에 있으며, 감사 스크립트가 이를 파싱합니다. 다른 스킬의 차선을 침범하는 여섯 번째 캘린더 스킬을 만들면, 스킬이 출시되기도 전에 감사가 실패합니다.

9단계: E2E 스모크 테스트

전체 파이프라인, 처음부터 끝까지.

• 에이전트에게 "내가 싱가포르에 언제 갔었지?"라고 물어보고 calendar-recall.mjs를 실행하고, 올바른 답을 얻고, 올바르게 형식화하는지 확인합니다.
• "다음 미팅이 몇 시지?"라고 물어보고 context-now.mjs를 실행하는지, 암산을 하지 않는지 확인합니다.

스모크 테스트는 최후의 방어선입니다. 다른 모든 것이 통과할 수 있고, 조각들이 연결되지 않으면 시스템은 여전히 실패할 수 있습니다. 스킬이 올바를 수 있고, 스크립트가 올바를 수 있고, 리졸버가 올바를 수 있으며, 에이전트는 여전히 이 모든 것을 무시하고 즉흥적으로 처리하기로 선택할 수 있습니다. 스모크 테스트가 그것을 잡아냅니다.

10단계: 브레인 파일링 규칙

지식 베이스에 쓰는 모든 스킬은 내용이 어디로 가야 하는지 알아야 합니다. 사람은 people/ 로 이동합니다. 회사는 companies/ 로 이동합니다. 정책 분석은 civic/ 로 이동합니다. 브레인에 쓰는 13개의 스킬 중 10개가 잘못된 디렉토리에 파일링하고 있다는 것을 발견했습니다. 각자가 리졸버를 참조하는 대신 자신의 경로를 하드코딩했기 때문입니다.

파일링 규칙 문서는 일반적인 잘못된 파일링 패턴을 목록화합니다. 출처 대 원본. 사람 대 회사(누군가가 회사인 경우). 스킬은 페이지를 생성하기 전에 규칙을 읽습니다. 이후로 잘못된 파일링은 0건입니다.

GBrain: 스킬리파이가 살아있는 곳, 그리고 제 GBrain Skill Pack 에서 이를 적용해야 하는 이유

스킬리파이 패턴은 OpenClaw나 특정 하네스에만 국한되지 않습니다. 이는 GBrain에 내장되어 있습니다. GBrain 은 제가 작성한 오픈 소스 지식 엔진으로, 어떤 하네스 아래에서든 작동합니다. 브레인 저장소를 관리하고, 평가를 실행하며, 스킬을 내구성 있게 만드는 품질 관문을 시행합니다.

GBrain SkillPack 은 스킬, 리졸버 트리거, 결정론적 스크립트 및 테스트로 구성된 휴대용 번들입니다. OpenClaw/Hermes Agent 에게 요청하기만 하면 모든 에이전트 설정에 설치할 수 있습니다. 이것이 제 OpenClaw/Hermes Agent 를 위해 작성한 스킬과 기능을 여러분의 OpenClaw 에 자동으로 추가할 수 있는 방법입니다. 전체 10단계 스킬리파이 출력물이 패키징되어 있어 여러분의 OpenClaw/Hermes Agent 에 바로 적용하면 작동합니다.

앞서 언급한 스킬리파이 체크리스트는 제안이 아닙니다. 이것은 gbrain doctor 가 실제로 확인하는 내용입니다.

gbrain doctor --fix 는 DRY 위반 사항을 자동으로 수리하고, 중복된 블록을 규칙 참조로 대체하며, git 작업 트리 검사로 보호되어 아무것도 덮어쓰지 않도록 합니다.

Hermes Agent 만으로는 충분하지 않은 이유

Nous Research 의 Hermes Agent는 정말 훌륭한 기능을 제공합니다: 에이전트가 학습한 내용을 바탕으로 스킬을 생성, 패치 및 삭제할 수 있는 skill_manage 도구가 있습니다. 에이전트가 복잡한 작업을 완료하거나 오류로부터 복구할 때, 스킬을 제안하고 디스크에 기록합니다. 이는 에이전트가 스스로 획득하는 절차적 기억입니다. 점진적 공개(먼저 스킬 인덱스를 로드하고, 선택된 경우에만 전체 SKILL.md 를 가져옴). 제한된 메모리(MEMORY.md 는 2,200자로 제한). 조건부 활성화(필요한 도구를 사용할 수 없을 때 스킬이 자동 숨김). 똑똑한 설계입니다.

하지만 Hermes 는 스킬을 테스트하지 않습니다. 결정론적 코드에 대한 유닛 테스트가 없습니다. 라우팅을 확인하는 리졸버 평가가 없습니다. 암흑 스킬을 찾는 check-resolvable 이 없습니다. 중복을 잡는 DRY 감사가 없습니다. 무언가 변경될 때 빨간불이 켜지는 일일 건강 상태 점검이 없습니다.

테스트되지 않은 모든 스킬 시스템에서 제가 목격한 축적되는 실패 모드들:

• 에이전트가 월요일에 deploy-k8s 를 생성합니다. 목요일에 다른 대화에서 kubernetes-deploy 를 생성합니다. 둘 다 존재합니다. 둘 다 비슷한 구문에 트리거됩니다. 모호한 라우팅, 잘못된 시점에 잘못된 것이 발동될 때까지 아무도 눈치채지 못합니다.
• 스킬은 작성되었을 때 완벽하게 작동합니다. 6주 후 상류 API 의 형태가 변경됩니다. 스킬은 인간이 발견할 때까지 조용히 쓰레기를 반환합니다.
• 자율적으로 생성된 스킬이 일치하지 않는 약한 트리거를 가지고 있습니다. 고아가 되어 인덱스 토큰을 소비하고, 실행되지 않으며, 천천히 썩어갑니다.

이것이 "테스트 없이는 모든 코드베이스가 썩는다"는 문제이며, 소프트웨어 엔지니어링이 2005년에 이미 해결한 문제입니다. 에이전트 스킬도 다르지 않습니다. Hermes 는 생성을 아름답게 처리합니다. GBrain 은 검증을 처리합니다. 둘 다 필요합니다.

큰 아이디어

건강한 소프트웨어 엔지니어링 팀에서는 모든 버그에 테스트가 있습니다. 그 테스트는 영원히 존속합니다. 버그는 구조적으로 재발이 불가능해집니다. AI 에이전트도 같은 방식으로 작동해야 합니다.

모든 실패는 스킬이 됩니다. 모든 스킬에는 평가가 있습니다. 모든 평가는 매일 실행됩니다. 에이전트의 판단력은 영구적으로 향상됩니다. 현재 세션에서만이 아니라, 컨텍스트 윈도우가 유지되는 동안만이 아니라 말이죠.

출장 실패는 다시 발생하지 않을 것입니다. 시간대 실패는 다시 발생하지 않을 것입니다. 그리고 다음 실패가 나타날 때(그리고 나타날 것입니다, 이것은 엔트로피와 취향에 대한 적대적 게임이기 때문에) 그것도 스킬리파이될 것입니다.

1년 후 제가 함께 일할 에이전트는 지난 1년 동안 저지른 모든 실수에 의해 형성될 것입니다. 이것은 있으면 좋은 기능이 아닙니다. 이것이 전체 논지입니다.

대담하게 시도하십시오. 에이전트가 무언가를 하게 한 다음, 스킬리파이하십시오. 매일 그렇게 하면, 여러분이 원하는 모든 것을 하는 굉장히 똑똑한 OpenClaw 를 갖게 될 것입니다.

또는 간단히 GBrain 을 로드하고, 제가 이미 작성한 모든 코드를 사용하여, 더 빨리 Iron Man 의 Jarvis 에 도달할 수도 있습니다.

--

GStack 으로 Claude Code 속도 향상 github.com/garrytan/gstack

GBrain 으로 OpenClaw/Hermes Agent 에서 Iron Man 의 Jarvis 구축 github.com/garrytan/gbrain

https://x.com/garrytan/status/2042925773300908103

https://x.com/garrytan/status/2044479509874020852