정적 스킬은 죽은 스킬이다

어젯밤 저는 Claude Code 가이드에 Settings Reference 섹션을 출시했습니다. 항목은 15개. 모든 인용은 라인 번호에 grep으로 대조했습니다. 비평 루프가 깨끗하게 돌아온 뒤 확신을 가지고 출시했습니다. .md 파일을 커밋하던 시점에 이미 v3가 필요하리라는 것을 알고 있었습니다. 잘못한 게 있어서가 아니라, 가이드는 바뀌고 밑바탕의 제품도 바뀌고 사용자 쿼리도 변하기 때문입니다. 제가 방금 출시한 그 섹션은 제가 자리를 떠나는 순간부터 표류하기 시작할 것이었습니다.

스킬이란 (Markdown 참조 섹션이든 .claude/skills/의 에이전트 스킬 정의든) 누군가가 그 트래젝토리를 지켜보는 동안에만 살아있습니다. 지켜보기를 멈추는 순간 정적이 됩니다. 정적 스킬은 제자리에서 쇠퇴합니다. 아래 글은 에이전트 인프라가 프로덕션에서 어떻게 진화하는지를 기록하는 AI 엔지니어링 시리즈의 일부입니다.

정적 AI 에이전트 스킬은 출시되는 순간 학습을 멈추기 때문에 실패합니다. 실제 호출 트래젝토리(실제 사용에서 발생한 입력, 도구 호출, 출력, 에러 상태)를 수집하는 피드백 루프가 없으면, 스킬은 변화하는 제품이나 이동하는 사용자 쿼리, 반복되는 실패 모드에 적응할 수 없습니다. 여러 사용자가 독립적으로 같은 우회법을 재발견하는 동안 스킬 정의는 얼어붙은 채로 남습니다. 해법은 사용 패턴을 자동화된 스킬 업데이트로 변환하는 연속적인 트래젝토리 집계입니다.

Ma, Yang, Ji, Wang, Wang의 새 arxiv 논문(“SkillClaw: Let Skills Evolve Collectively with Agentic Evolver,” 2026년 4월)은 이 문제를 연구 수준에서 정식화합니다.¹ 이들의 서두 프레이밍을 그대로 인용하면 다음과 같습니다. “OpenClaw 같은 대규모 언어 모델(LLM) 에이전트는 복잡한 작업을 수행하기 위해 재사용 가능한 스킬에 의존하지만, 이러한 스킬은 배포 후 대체로 정적인 상태로 남아 있다. 그 결과 비슷한 워크플로, 도구 사용 패턴, 실패 모드가 사용자 전반에 걸쳐 반복적으로 재발견되며, 시스템이 경험을 통해 개선되는 것을 방해한다.”¹

저는 몇 달간 그 실패 모드 속에서 살아왔습니다. 어떤 에이전트 프레임워크용 스킬이든 만들고 있다면 여러분도 마찬가지입니다.

TL;DR

에이전트 스킬은 출시된 뒤 개선이 멈춥니다. 사용자들은 같은 실패 모드를 독립적으로 발견하고도 그 발견을 스킬 자체로 되돌려 보내지 않습니다. Ma 등은 이를 집합 지능 문제로 규정합니다. 교차 사용자 및 시간에 걸친 상호작용은 스킬이 언제 동작하고 언제 실패하는지에 관한 신호이지만, 이를 스킬 업데이트로 집계하는 생태계 수준의 메커니즘이 존재하지 않습니다. 이들의 SkillClaw 프레임워크는 집계된 트래젝토리를 진화 신호로 취급하고, 반복되는 행동 패턴을 식별해 정제나 기능 확장으로 변환하는 자율 에볼버를 실행하는 방식을 제안합니다.¹ 초록은 재사용 가능한 스킬을 사용하는 LLM 에이전트 사례로 “OpenClaw”를 언급합니다. 초록만으로는 OpenClaw를 특정한 출시 제품으로 식별할 수 없었고, 이 글에서 그에 관해 추측하지 않겠습니다. 제가 주장하는 바는 이 논문이 기술하는 구조적 문제가 Claude Code, Codex, Cursor, 또는 자체 에이전트 프레임워크용 스킬을 만드는 모든 사람에게 맞아떨어진다는 것입니다. 요지는 이것입니다. 여러분의 스킬 라이브러리가 실제 사용에서 나오는 트래젝토리를 지속적으로 수집하고 있지 않다면, 그 스킬은 출시된 날부터 죽은 것입니다.

핵심 요점

• 스킬 저자: 스킬이 출시된다고 일이 끝나는 게 아닙니다. 스킬이 어떻게 쓰이는지 지켜보고, 반복되는 실패 모드를 포착하고, 그것을 스킬 정의로 되먹이는 루프가 갖춰져야 일이 끝난 것입니다. 출시는 스킬의 수명의 끝이 아니라 시작입니다.
• 프레임워크 제작자: 모든 스킬 호출을 트래젝토리와 함께 로깅하세요. 입력, 도구 호출, 출력, 에러 상태까지. 그 로그가 진화 신호입니다. 로깅하지 않고 있다면 스킬을 개선하는 것이 아니라 유지만 하고 있는 것입니다.
• Jiro 지향 실천자: SkillClaw 논문은 스킬에 적용된 쇼쿠닌 패턴의 학문적 언어입니다. 스킬은 craft입니다. 트래젝토리는 수련입니다. 진화는 숙련의 추구입니다. 정적 = 죽음.

논문이 실제로 말하는 것

초록의 주장을 신중히 풀어낸 다음, 제가 프레이밍을 확장하는 지점을 명확히 표시하겠습니다.

문제 정의(초록 기준). LLM 에이전트는 복잡한 작업을 수행하기 위해 재사용 가능한 스킬에 의존합니다. 이 스킬은 배포 후 대체로 정적인 상태로 남습니다. 비슷한 워크플로, 도구 사용 패턴, 실패 모드가 사용자 전반에 걸쳐 반복적으로 재발견됩니다. 시스템은 경험을 통해 개선되지 않습니다.¹

저자들은 특정한 실패 모드를 겨냥하는 것이지, 모든 스킬이 쇠퇴한다는 보편적 주장을 하는 것이 아닙니다. 한 번도 호출되지 않는 스킬은 쇠퇴하지 않습니다. 한 사용자만 호출하고 문제를 보고하지 않는 스킬은 가시적으로 쇠퇴하지 않습니다. 쇠퇴는 여러 사용자가 각자 같은 실패의 자기 버전을 만나고, 시스템이 그 만남들을 단일 업데이트로 집계할 방법이 없을 때 드러납니다. (마지막 문장은 제 프레이밍이지 논문의 프레이밍이 아닙니다.)

기존의 공백(초록 기준). 초록은 교차 사용자 상호작용이 “스킬이 언제 동작하고 실패하는지에 관한 보완적 신호를 제공하지만, 기존 시스템에는 이러한 이질적 경험을 신뢰할 수 있는 스킬 업데이트로 변환하는 메커니즘이 결여되어 있다”고 말합니다.¹ 하중을 지탱하는 주장은 여기 있습니다. 공백은 아무도 스킬 개선을 생각하지 않았다는 데 있지 않습니다. 공백은 트래젝토리를 집계하고, 반복되는 패턴을 식별하고, 그것을 업데이트로 변환하는 생태계 수준의 메커니즘이 없다는 데 있습니다.

SkillClaw 파이프라인(초록 기준). 초록은 연속 파이프라인을 다음과 같이 기술합니다. SkillClaw는 “사용 중에 생성된 트래젝토리를 집계하고 이를 자율 에볼버로 처리하며, 에볼버는 반복되는 행동 패턴을 식별해 기존 스킬을 정제하거나 새 기능으로 확장하여 스킬 집합에 대한 업데이트로 변환한다.”¹ 시스템은 업데이트된 스킬을 공유 저장소에 유지하고 사용자 간 동기화하므로, 한 맥락에서 발견된 개선이 사용자 노력 없이도 시스템 전반으로 전파됩니다.¹

평가(초록 기준). 논문은 Qwen3-Max를 기반 모델로 사용해 WildClawBench라는 벤치마크에서 SkillClaw를 평가합니다. 초록의 문구 자체는 출판본에서 문법적으로 깨져 있습니다. “experiments on WildClawBench show that limited interaction and feedback, it significantly improves the performance of Qwen3-Max in real-world agent scenarios.”¹ 저는 이를 다음과 같이 읽습니다. 제한된 상호작용과 피드백 하에서도 SkillClaw는 베이스라인 대비 유의미한 성능 개선을 만들어낸다. 초록은 구체적인 수치를 게시하지 않으며, 전체 논문에 실려 있을 것으로 짐작됩니다.

여기까지가 초록이 기술하는 논문입니다. 저자들은 공유 스킬을 가진 다중 사용자 에이전트 생태계가 자동 스킬 업데이트로 이어지는 자동 트래젝토리 집계로부터 이익을 얻는다고 제안하며, 그 구현이 제한적 피드백 조건하에서도 Qwen3-Max 성능을 유의미하게 개선한다고 보고합니다.

논문이 말하지 않는 것(그리고 제가 더하는 것)

초록은 재사용 가능한 스킬을 사용하는 에이전트의 한 예(“OpenClaw 같은 LLM 에이전트”)로 “OpenClaw”를 언급합니다. 초록만으로는 OpenClaw가 무엇인지 알 수 없고, 특정 출시 제품으로 빠르게 식별할 수도 없었습니다. 논문의 프레임워크(SkillClaw)는 OpenClaw 특정이 아니라 다중 사용자 에이전트 생태계 일반을 겨냥하므로 “OpenClaw가 무엇인가”라는 질문은 논증에 거의 부수적입니다. 이 글을 읽고 논문이 Claude Code에 관한 것이라고 오해하는 사람이 없도록 표시해 둡니다. 그렇지 않습니다. 논문은 OpenClaw를 예시로 지명하며 SkillClaw를 일반 메커니즘으로 제안합니다.

제가 논문과 별개로 주장하는 바는, 논문이 기술하는 구조적 문제가 제가 Claude Code 스킬 생태계에서 실제로 겪어 온 문제와 맞아떨어진다는 것입니다. 이 주장은 제 것이지 논문의 것이 아닙니다. 제가 왜 그렇게 보는지 설명하겠습니다.

Claude Code 생태계의 스킬은 정적 아티팩트로 출시됩니다. 스킬은 작업 수행 방식을 기술하는 SKILL.md 파일(또는 지원 파일 묶음)입니다. 한 번 작성합니다. 커밋합니다. 슬래시 명령이나 @skill-name 자동완성으로 참조합니다. 커스텀 스킬 만들기의 메커니즘은 간단합니다. 출시되고 나면 정적 아티팩트가 됩니다. 스킬이 실제로 어떻게 쓰이는지 지켜보거나, 무엇이 잘 되고 무엇이 실패하는지에 따라 스킬 정의를 갱신하는 자동 메커니즘은 없습니다.

서로 다른 사용자들이 같은 실패 모드를 독립적으로 만납니다. 제가 출시한 스킬마다 특정 조건에서만 나타나는 반복적 실패 모드가 최소 하나씩은 있습니다. 누군가 제가 예상하지 못한 입력으로 스킬을 호출하고, 엣지 케이스에 부딪히고, 수동으로 우회하고, 넘어갑니다. 다른 어딘가의 다른 사람이 같은 엣지 케이스에 부딪혀 자신만의 우회법을 만듭니다. 스킬 자체는 결코 바뀌지 않습니다.

집합 신호는 실재하지만 사용되지 않습니다. 제가 출시한 모든 스킬의 모든 호출 트래젝토리를 볼 수 있다면, 반복되는 실패 모드를 한나절이면 찾아낼 수 있을 겁니다. 그 신호는 모든 개별 사용자의 세션 기록 안에 존재합니다. 다만 어디에도 집계되어 있지 않아서 아무도 그에 대해 행동하지 않을 뿐입니다.

해법은 수동이거나 부재합니다. 지금 스킬 개선을 위한 유일한 메커니즘은 제가 제 사용에서 문제를 알아차리거나, 누군가 이슈를 등록하거나, 누군가 PR을 여는 것뿐입니다. 이 모든 경로는 사용자 노력을 요구합니다. 트래젝토리 데이터가 이미 존재하고 그것이 스킬 업데이트를 자동으로 공급해야 한다는 SkillClaw 논문의 핵심 통찰이 바로 우리에게 없는 메커니즘입니다.

이상이 논문의 프레이밍이 Claude Code에 어떻게 적용되는지에 관한 제 주장입니다. 논문이 말하는 바가 아닙니다. 제가 제 일에 비추어 논문을 읽는 방식입니다.

스킬에 적용된 쇼쿠닌 패턴

craft를 생각할 때 계속 떠오르는 프레이밍이 하나 있습니다. 스시 장인 오노 지로가 정전적 예시입니다. 60년간 같은 일. 매일, 그는 카운터에서 벌어지는 일을 지켜보고, 기법을 조정하고, 샤리의 밥 온도, 칼 각도, 타이밍을 다듬습니다. 일 자체가 훈련 신호입니다. 실천자가 곧 집계자입니다.

저는 전에 쇼쿠닌 / 품질 루프 프레이밍에 관해 쓴 적이 있습니다. 핵심 생각은 이렇습니다. craft는 피드백 루프입니다. 일을 하고, 일을 지켜보고, 무엇이 깨졌는지 알아차리고, 조정하고, 다시 일을 합니다. 반복 또 반복. 숙련은 의도한 것과 실제로 일어난 것 사이의 델타에, 그리고 그 델타를 다음 시도로 가져가려는 의지에 깃듭니다.

정적 스킬은 그 루프를 깨뜨립니다. 스킬을 출시합니다. 지켜보기를 멈춥니다. 스킬이 의도한 것과 실제로 일어나는 것 사이의 델타는 당신이 결코 보지 못하는 수백 개의 세션에 쌓입니다. 장인이 카운터에 없으니 스킬은 나아지지 않습니다.

SkillClaw 논문은 자동화된 집계자를 제안합니다. 사람의 대체가 아니라, 모든 트래젝토리를 지켜보고, 세션 전반에서 무엇이 깨졌는지 알아차리고, 스킬 정의로 되돌아갈 업데이트를 제안하는 메커니즘입니다. 야심이 과하지 않습니다. 스킬이 자신의 배포에서 살아남기를 바란다면 사실상 최소 기준입니다.

이것이 실제로 어떻게 보이는가

SkillClaw 패턴을 제가 오늘 유지 중인 Claude Code 스킬에 대해 구축한다면, 다음이 필요합니다.

1. 모든 스킬 호출에 대한 트래젝토리 로그. 스킬이 실행될 때마다 입력, 호출한 도구, 출력, 에러 상태, 최종 처리 결과(사용자가 결과를 수용했는가? 되돌렸는가? 다시 썼는가?)를 기록합니다. 세션 수준 로깅은 Claude Code에 이미 있습니다. 문제는 그것이 세션 전반에 걸쳐 집계되어 스킬 소유자에게 추출되는가입니다.

2. 패턴 감지기. 트래젝토리 로그를 읽어 반복되는 패턴을 식별하는 것. 같은 입력 부류가 같은 실패로 이어지는 경우, 같은 도구 호출이 같은 방식으로 실패하는 경우, 서로 다른 사용자 맥락에서 같은 엣지 케이스가 나타나는 경우. 요구되는 것은 구조화된 트래젝토리 데이터에 대한 클러스터링이지 AGI가 아닙니다.

3. 제안 생성기. 감지된 패턴이 주어지면, 스킬에 대한 업데이트 후보를 초안으로 만듭니다. 새로운 처리 분기, 추가 예시, SKILL.md 본문에 들어갈 추가 제약. 업데이트는 제안이지 이미 출시된 변경이 아닙니다.

4. 게이트. 모든 제안된 업데이트는 사람 리뷰, 사실 확인(제가 다른 모든 것에 적용하는 것과 같은 엄격한 게이트), 비평 루프를 거친 뒤에야 출시됩니다. 자동화는 집계를 담당하지 출시를 담당하지 않습니다.

5. 배포. 제안된 업데이트가 수용되면 해당 스킬의 모든 사용자에게 전파됩니다. 중앙집중형 생태계에서는 자명합니다(정본 스킬을 갱신하면 모두가 풀합니다). 분산형 생태계에서는 더 어렵습니다.

대부분은 이미 Claude Code에 존재합니다. 세션 로깅, 버저닝된 스킬 정의, 운영 중인 비평 루프. 빠진 조각은 세션 트래젝토리를 스킬 업데이트로 연결하는 집계 및 패턴 감지 레이어입니다. 커맨드, 스킬, 서브에이전트, 규칙의 조직 분류는 이미 구조적 토대를 제공합니다. 빠진 것은 배포 이후에도 각 범주를 살아 있게 유지하는 피드백 채널입니다.

불편한 함의

지난 6개월간 제가 출시한 모든 스킬은 SkillClaw 논문이 기술하는 바로 그 의미에서 죽어 있습니다. 스킬을 작성합니다. 제가 직접 씁니다. 문제를 알아차립니다. 제가 쓰는 스킬에서 고칩니다. 제 스킬은 저에게는 좋아집니다. 다른 누군가가 독립적으로 같은 문제를 알아차리고 무언가를 등록하지 않는 한, 다른 사람에게는 좋아지지 않습니다.

어젯밤 Settings Reference에 대해 한 작업이 바로 이 패턴입니다. Claude Code 가이드는 공유 아티팩트입니다. 사용자들이 특정 config 키를 쿼리합니다. 저는 어떤 config 키가 검색되는지 알려주는 GSC 데이터를 볼 수 있습니다. 그것이 집계된 트래젝토리 데이터입니다. 말 그대로 가이드의 어떤 스킬이 호출되고 있고 결과가 어디에 안착하는지 알려줍니다. 그리고 제가 그 데이터를 들여다보기 전까지, 가이드는 정적이었습니다. 몇 주간 정적이었습니다. 아무도 트래젝토리를 지켜보지 않아서가 아니라, 그것을 지켜볼 수 있는 사람이 저뿐이었고, 저에게 다른 할 일이 있었기 때문입니다.

SkillClaw 논문은 그 문제의 학문적 정식화입니다. 실제 메커니즘은 더 단순합니다. 트래젝토리 데이터에서 스킬 업데이트로 이어지는 자동 파이프라인이 없다면, 여러분의 스킬은 제자리에서 늙어가고 있는 것입니다. 어떤 사용자에게, 어떤 조건에서는 여전히 동작할지도 모릅니다. 그러나 더 나아지고 있지는 않습니다.

유일한 질문은 스킬이 출시되는 순간 죽는다는 것을 받아들일 것인가, 아니면 스킬을 살려두는 감시자를 만들 것인가입니다. 복합 컨텍스트 원리가 여기 적용됩니다. 각 트래젝토리 관찰은 다음 관찰과 복리로 쌓이고, 스킬의 가치는 그것이 수집하는 피드백과 함께 비선형적으로 성장합니다. 반대로 컨텍스트를 아키텍처로 취급한다는 것은 스킬의 구조가 새로운 정보를 흡수할 능력 자체를 결정한다는 사실을 인정하는 것입니다.

최소 기능 집계자

이 글을 시작하기 전까지 제 스킬에 대한 트래젝토리 집계는 0이었습니다. 전무했습니다. 수동으로 읽을 수 있는 세션 기록은 있었지만, 세션 전반에서 패턴을 드러내는 것은 전혀 없었습니다. 그것이 바로 논문이 기술하는 정적 스킬 병리이고, 저는 그 속에서 돌고 있었습니다.

지금 당장, 오늘 제가 출시할 수 있는 가장 작은 실제 산출물은 이것입니다. 제 자체 세션 전반에서 모든 스킬 호출을 기록하는 단일 텍스트 파일. 추가-전용. 타임스탬프 + 스킬 이름 + 입력 형상 + 최종 처리 결과(수용 / 수정 / 되돌림). 패턴 감지기 없음. 자율 에볼버 없음. 그냥 로그만.

그 파일이 최소 기능 집계자입니다. SkillClaw가 아닙니다. SkillClaw가 존재한다면 필요로 할 입력 레이어이고, 제 스킬에 반복되는 실패 모드가 있는지 보기도 전에 제가 필요로 하는 입력 레이어입니다. 그것 없이는 추측하는 것입니다. 그것이 있으면, 적어도 스킬을 리뷰할 때 로그를 손으로 훑으며 물을 수 있습니다. 이번 달에 같은 고장이 세 번 일어났는가?

그것이 약속입니다. 파일 하나. 추가-전용. 호출마다 기록. 스킬 리뷰 시 검토.

이것이 작동한다면 다음 층은 패턴 감지기입니다. 패턴 감지기가 작동한다면 다음 층은 제안 생성기입니다. 논문의 야심은 다중 사용자 생태계 전반에서 돌아가는 완전 자율 에볼버입니다. 저의 야심은 어둠 속에서 돌고 있지 않는 것입니다.

FAQ

논문의 “OpenClaw”는 Claude Code과 같은 것인가요?

아닙니다. 그리고 저도 OpenClaw가 무엇인지 말해줄 수 없습니다. 초록은 재사용 가능한 스킬을 사용하는 에이전트의 한 예로 “OpenClaw 같은 LLM 에이전트”를 언급하지만 정의하지 않습니다. 초록만으로는 특정한 출시 제품으로 빠르게 식별할 수 없었습니다. 중요한 점은, 논문의 SkillClaw 프레임워크가 OpenClaw나 Claude Code 특정이 아니라 다중 사용자 에이전트 생태계 일반을 겨냥한다는 것입니다. OpenClaw가 무엇이든, 이 논문은 Claude Code 논문이 아니며, 이 글에 실린 Claude Code에 관한 제 주장은 제 것이지 논문의 것이 아닙니다.¹

이 논문의 실제 새로운 기여는 무엇인가요?

초록에 따르면, 다중 사용자 에이전트 생태계에서 집합 스킬 진화를 위한 프레임워크로서 (1) 사용자와 시간에 걸쳐 트래젝토리를 집계하고, (2) 자율 에볼버를 돌려 반복 패턴을 감지하고, (3) 패턴을 사용자 간 동기화되는 공유 저장소의 스킬 업데이트로 변환하는 것입니다.¹ 새로움은 “스킬이 개선될 수 있다”가 아닙니다(그건 자명합니다). 새로움은 개선 루프가 사람 주도가 아니라 자율적이고 트래젝토리 주도여야 한다고 제안하는 데 있습니다.

논문이 구체적인 개선 수치를 보고하나요?

초록은 제한된 피드백 조건하에서 Qwen3-Max를 사용해 WildClawBench라는 벤치마크에서 개선을 “유의미하다”고 기술하지만, 구체적인 수치를 게시하지는 않습니다.¹ 수치를 원하면 전체 논문이 출처입니다.

스킬 정의에 대한 git 풀 리퀘스트와는 어떻게 다른가요?

PR은 사람이 개시하는 메커니즘입니다. 누군가 문제를 알아차리고, 수정안을 작성하고, PR을 등록하고, 리뷰하고, 병합해야 합니다. 모든 단계에 사람의 노력이 필요합니다. 논문이 제안하는 SkillClaw 프레임워크는 자율 집계입니다. 시스템이 많은 사용자에 걸친 패턴을 스스로 알아차리고, 수정안을 스스로 제안하며, 어떤 단일 사용자도 무언가를 등록할 필요 없이 업데이트를 동기화합니다.¹ 그 자율 버전이 특정 생태계에 바람직한지 또는 안전한지는 별개의 질문입니다. 논문의 기여는 그것이 기술적으로 정합적임을 보여주는 데 있습니다.

이것이 제 커스텀 Claude Code 스킬에 적용되나요?

논문은 특정 Claude Code 스킬 생태계에 대해 어떤 주장도 하지 않습니다. 논문과는 별개로 제 주장은, 구조적 문제(스킬이 정적 아티팩트로 출시되고, 실패 모드가 각 사용자에 의해 독립적으로 재발견되며, 집계 메커니즘이 없는 것)가 Claude Code 스킬에 적용되며, Claude Code이든 유사한 에이전트 프레임워크든 스킬을 만드는 사람이라면 트래젝토리 주도 개선 루프를 어떻게 구축할지 고민해야 한다는 것입니다. 그것은 제 의견이지 논문의 발견이 아닙니다.

쇼쿠닌과의 연결은 무엇인가요?

쇼쿠닌 / 품질 루프 프레이밍은 숙련이 의도한 것과 실제로 일어난 것 사이의 델타를 다음 시도로 가져가는 데서 온다고 주장합니다. 정적 스킬은 델타가 장인이 결코 보지 못하는 세션에 쌓이기 때문에 그 루프를 깨뜨립니다. SkillClaw는 그 루프를 닫는 학문적 버전입니다. 델타 수집을 자동화하여 스킬로 되먹입니다. 규율은 같고, 메커니즘이 다릅니다.

참고문헌