정적 스킬은 죽은 스킬입니다

어젯밤 저는 Claude Code 가이드에 설정 레퍼런스 섹션을 출시했습니다. 15개 항목. 모든 인용은 라인 번호에 대해 grep으로 검증했습니다. 비평 루프가 깨끗하게 돌아온 후 확신을 가지고 출시했습니다. .md 파일을 커밋할 즈음, 저는 이미 v3가 필요해지리라는 것을 알고 있었습니다. 제가 뭔가 잘못해서가 아니라, 가이드가 바뀌고, 기저의 제품이 바뀌고, 사용자 질의가 이동하며, 방금 출시한 섹션은 제가 자리를 떠나는 순간부터 표류하기 시작할 것이기 때문입니다.

스킬은 그것이 Markdown 레퍼런스 섹션이든 .claude/skills/의 에이전트 스킬 정의든, 누군가가 그 트래젝토리를 지켜보는 동안에만 살아 있습니다. 지켜보기를 멈추는 순간, 스킬은 정적이 됩니다. 정적 스킬은 제자리에서 쇠퇴합니다.

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

저는 수개월 동안 그 실패 모드를 몸소 겪어왔습니다. 어떤 에이전트 하네스용 스킬이든 만들고 있다면 여러분도 마찬가지일 것입니다.

TL;DR

에이전트 스킬은 출시된 후 더 이상 개선되지 않습니다. 사용자들은 동일한 실패 모드를 독립적으로 발견하고, 그 발견은 결코 스킬 자체로 피드백되지 않습니다. Ma 등은 이를 집단 지능 문제로 규정합니다. 크로스 유저 및 시간에 걸친 상호작용은 스킬이 언제 작동하고 언제 실패하는지에 대한 신호이지만, 이를 스킬 업데이트로 집계할 생태계 수준의 메커니즘은 존재하지 않습니다. 그들의 SkillClaw 프레임워크는 집계된 트래젝토리를 진화 신호로 취급하고, 반복되는 행동 패턴을 식별하여 개선안 또는 기능 확장으로 변환하는 자율 에볼버(evolver)를 실행할 것을 제안합니다.¹ 초록은 “OpenClaw”를 재사용 가능한 스킬을 사용하는 LLM 에이전트의 예로 인용하는데, 저는 초록만으로는 OpenClaw를 구체적으로 출시된 제품으로 식별할 수 없었고, 이 게시물에서 그것에 대해 추측하지 않을 것입니다. 제가 주장하려는 것은 논문이 기술하는 구조적 문제가 Claude Code, Codex, Cursor 또는 자체 하네스용 스킬을 만드는 모든 사람에게 그대로 적용된다는 점입니다. 요지는 이렇습니다. 여러분의 스킬 라이브러리가 실제 사용에서 나오는 트래젝토리를 지속적으로 수집하지 않는다면, 그것은 출시되는 날부터 죽은 것입니다.

핵심 요약

• 스킬 제작자: 스킬이 출시되었다고 작업이 끝나는 것이 아닙니다. 스킬이 어떻게 사용되는지 지켜보고, 반복되는 실패 모드를 포착하며, 그것을 다시 스킬 정의로 피드백하는 루프를 갖추었을 때 작업이 완료됩니다. 출시는 스킬의 수명의 시작이지 끝이 아닙니다.
• 하네스 제작자: 모든 스킬 호출을 그 트래젝토리(입력, 도구 호출, 출력, 오류 상태)와 함께 로깅하세요. 그 로그가 진화 신호입니다. 로깅하고 있지 않다면 스킬을 개선하는 것이 아니라 유지할 뿐입니다.
• Jiro 정신의 실천자들: SkillClaw 논문은 Shokunin 패턴을 스킬에 적용한 것의 학술적 표현입니다. 스킬은 공예입니다. 트래젝토리는 수련입니다. 진화는 숙달의 추구입니다. 정적 = 죽음.

논문이 실제로 말하는 것

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

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

이것은 특정 실패 모드에 관한 주장이지, 모든 스킬이 쇠퇴한다는 주장이 아닙니다. 결코 호출되지 않는 스킬은 쇠퇴하지 않습니다. 문제를 보고하지 않는 한 사용자에 의해서만 호출되는 스킬은 눈에 띄게 쇠퇴하지 않습니다. 쇠퇴는 여러 사용자가 각자 같은 실패의 자기 버전을 마주하고, 시스템이 그러한 마주침을 단일 업데이트로 집계할 방법이 없을 때 드러납니다. (이 마지막 문장은 논문이 아닌 제 프레이밍입니다.)

기존의 공백 (초록에서). 초록은 크로스 유저 상호작용이 “스킬이 언제 작동하고 언제 실패하는지에 대한 보완적 신호를 제공하지만, 기존 시스템은 그러한 이질적인 경험을 신뢰할 수 있는 스킬 업데이트로 전환할 메커니즘이 부족하다”고 진술합니다.¹ 이것이 핵심을 지탱하는 주장입니다. 아무도 스킬 개선에 대해 생각하지 않았다는 것이 아닙니다. 트래젝토리를 집계하고, 반복되는 패턴을 식별하고, 이를 업데이트로 변환하는 생태계 수준의 메커니즘이 없다는 것입니다.

SkillClaw 파이프라인 (초록에서). 초록은 연속적인 파이프라인을 설명합니다. SkillClaw는 “사용 중에 생성된 트래젝토리를 집계하고 이를 자율 에볼버로 처리하며, 반복되는 행동 패턴을 식별하여 기존 스킬을 개선하거나 새로운 기능으로 확장함으로써 스킬 세트에 대한 업데이트로 변환합니다.”¹ 업데이트된 스킬은 공유 리포지토리에서 관리되며 사용자 간에 동기화되어, 한 맥락에서 발견된 개선 사항이 사용자의 노력 없이 시스템 전체로 전파됩니다.¹

평가 (초록에서). 논문은 Qwen3-Max를 기저 모델로 사용하여 WildClawBench라는 벤치마크에서 SkillClaw를 평가합니다. 출판된 버전에서 초록의 문장은 문법적으로 깨져 있습니다. “WildClawBench에서의 실험은 제한된 상호작용과 피드백, 실제 에이전트 시나리오에서 Qwen3-Max의 성능을 상당히 향상시킨다는 것을 보여준다.”¹ 저는 이것을 다음과 같이 읽습니다. 제한된 상호작용과 피드백으로도, SkillClaw는 여전히 베이스라인 대비 상당한 성능 향상을 만들어냅니다. 초록은 구체적인 수치를 공개하지 않습니다. 전체 논문에는 있을 것으로 보입니다.

그것이 초록이 기술하는 논문입니다. 저자들은 공유 스킬을 가진 다중 사용자 에이전트 생태계가 자동화된 트래젝토리 집계를 통해 자동화된 스킬 업데이트를 공급받음으로써 혜택을 본다고 제안하고, 그들의 구현이 제한된 피드백 조건에서 Qwen3-Max 성능을 상당히 향상시킨다고 보고합니다.

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

초록은 재사용 가능한 스킬을 사용하는 에이전트의 한 예로 “OpenClaw”를 인용합니다(“OpenClaw와 같은 LLM 에이전트”). 저는 초록만으로 OpenClaw가 무엇인지 모릅니다. 구체적으로 출시된 제품으로 빠르게 식별할 수 없었습니다. 논문의 프레임워크(SkillClaw)는 OpenClaw에 특화된 것이 아니라 다중 사용자 에이전트 생태계 일반을 위한 해법으로 제시되므로, “OpenClaw가 무엇인가”라는 질문은 대체로 논의와 별개입니다. 이 게시물을 읽고 논문이 Claude Code에 관한 것이라고 오해하는 사람이 없도록 표시해 둡니다. 아닙니다. 논문은 OpenClaw를 예시로 이름을 대고 SkillClaw를 일반 메커니즘으로 제안합니다.

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

Claude Code 생태계의 스킬은 정적 산출물로 출시됩니다. 스킬은 작업이 어떻게 수행되어야 하는지 기술하는 SKILL.md 파일(또는 지원 파일 번들)입니다. 한 번 작성합니다. 커밋합니다. 슬래시 명령어나 @skill-name 자동완성으로 참조합니다. 일단 출시되면 정적 산출물입니다. 스킬이 실제로 어떻게 사용되는지 지켜보고 무엇이 작동하고 무엇이 실패하는지에 기반해 스킬 정의를 업데이트하는 자동 메커니즘은 없습니다.

서로 다른 사용자가 독립적으로 같은 실패 모드에 부딪힙니다. 제가 출시한 모든 스킬에는 특정 조건에서만 나타나는 반복 실패 모드가 적어도 하나씩 있습니다. 누군가가 제가 예상하지 못한 입력으로 스킬을 호출하고, 엣지 케이스에 부딪히며, 수동으로 우회하고, 넘어갑니다. 다른 곳의 다른 사람이 같은 엣지 케이스에 부딪히고 자기 나름의 우회를 합니다. 스킬 자체는 변하지 않습니다.

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

해결책은 수동이거나 부재합니다. 현재 스킬 개선을 위한 유일한 메커니즘은 제가 제 자신의 사용에서 문제를 알아채거나, 누군가가 이슈를 제기하거나, 누군가가 PR을 여는 것입니다. 모두 사용자 노력이 필요한 경로입니다. SkillClaw 논문의 핵심 통찰 — 트래젝토리 데이터가 이미 존재하며 자동으로 스킬 업데이트로 변환되어야 한다는 것 — 이 바로 우리에게 결여된 메커니즘입니다.

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

스킬에 적용되는 Shokunin 패턴

공예에 대해 생각할 때 제가 계속 되돌아오는 프레이밍이 있습니다. 스시 장인 오노 지로가 대표적인 예입니다. 60년 동안 같은 일. 매일 카운터에서 일어나는 일을 지켜보고, 기술을 조정하며, 밥의 온도, 칼의 각도, 샤리의 타이밍을 다듬습니다. 일 자체가 훈련 신호입니다. 장인이 집계자입니다.

저는 얼마 전 Shokunin / 품질 루프 프레이밍에 대해 글을 썼습니다. 핵심 아이디어는 이렇습니다. 공예는 피드백 루프입니다. 일을 하고, 일을 지켜보고, 무엇이 깨졌는지 알아채고, 조정하고, 다시 일을 합니다. 반복해서. 숙달은 의도한 것과 실제로 일어난 것 사이의 델타 안에, 그리고 그 델타를 다음 시도로 가지고 가려는 의지 안에 살아 있습니다.

정적 스킬은 그 루프를 끊습니다. 스킬을 출시합니다. 지켜보기를 멈춥니다. 스킬이 의도한 것과 실제로 일어난 일 사이의 델타는 여러분이 결코 보지 못하는 백 개의 서로 다른 세션에 쌓입니다. 장인이 카운터에 없기 때문에 스킬은 나아지지 않습니다.

SkillClaw 논문은 자동화된 집계자를 제안합니다. 인간을 대체하는 것이 아니라, 모든 트래젝토리를 지켜보고 세션 전반에서 무엇이 깨졌는지 알아채며 스킬 정의에 다시 반영할 업데이트를 제안하는 메커니즘입니다. 그것은 황당한 야심이 아닙니다. 스킬이 자신의 배포에서 살아남기를 바란다면 실제로 최소 기준선입니다.

실제로 이것이 어떻게 생겼는가

오늘 유지보수하는 Claude Code 스킬에 SkillClaw 패턴을 적용하여 구축하고 싶다면, 필요한 것은 다음과 같습니다.

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

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

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

4. 게이트. 모든 제안된 업데이트는 출시 전에 사람의 검토, 사실 검증(제가 다른 모든 것에 적용하는 동일한 엄격한 게이트), 비평 루프를 거칩니다. 자동화는 집계를 하는 것이지 출시를 하는 것이 아닙니다.

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

대부분은 이미 Claude Code에 존재합니다. 세션 로깅이 있고, 스킬 정의는 버전 관리되며, 비평 루프는 운영 중입니다. 빠진 조각은 세션 트래젝토리를 스킬 업데이트에 연결하는 집계 및 패턴 탐지 레이어입니다.

불편한 함의

지난 6개월 동안 제가 출시한 모든 스킬은 SkillClaw 논문이 기술하는 그 의미 그대로 죽어 있습니다. 저는 스킬을 작성합니다. 제가 직접 사용합니다. 문제를 알아챕니다. 제가 사용하는 스킬에서 문제를 고칩니다. 스킬은 저를 위해 나아집니다. 다른 누군가가 독립적으로 같은 문제를 알아채고 무언가를 제기하지 않는 한, 다른 누구를 위해서도 나아지지 않습니다.

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

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

유일한 질문은 여러분의 스킬이 출시되는 순간 죽어 있다는 것을 받아들이느냐, 아니면 그것을 살려두는 감시자를 구축하느냐입니다.

최소 실행 가능한 집계자

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

바로 오늘 그것에 맞서 제가 출시할 수 있는 가장 작은 실질적 산출물은 다음과 같습니다. 제 자신의 세션 전반에 걸쳐 모든 스킬 호출을 기록하는 단일 텍스트 파일, 추가 전용, 타임스탬프 + 스킬 이름 + 입력 형태 + 최종 처리(수용 / 수정 / 되돌림) 포함. 패턴 탐지기 없음. 자율 에볼버 없음. 그냥 로그입니다.

그 파일이 최소 실행 가능한 집계자입니다. 그것은 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 또는 유사한 하네스용 스킬을 만드는 누구나 트래젝토리 기반 개선 루프를 어떻게 구축할지 생각해야 한다는 것입니다. 그것은 제 의견이지 논문의 결론이 아닙니다.

Shokunin 연결은 무엇인가요?

Shokunin / 품질 루프 프레이밍은 숙달이 의도한 것과 실제로 일어난 것 사이의 델타를 다음 시도로 가지고 감으로써 온다고 주장합니다. 정적 스킬은 델타가 장인이 결코 보지 못하는 세션에 쌓이기 때문에 그 루프를 끊습니다. SkillClaw는 그 루프를 닫는 것의 학술적 버전입니다. 델타 수집을 자동화하고 그것을 스킬로 다시 공급하는 것. 규율은 동일하고, 메커니즘만 다릅니다.

참고문헌