지난번에는 3체의 AI 에이전트(蒼=Claude, ルナ=Gemini, 亜里沙=Codex)가 동일한 기억을 읽고 쓰는 "공유 메모리 계층 (Shared Memory Layer)"에 대해 썼다. 그것은 "무엇을 알고 있는가"를 축적하는 메커니즘이었다.

이번에는 그와 대칭되는 또 다른 계층——"어떻게 하는가"를 축적하는 메커니즘에 관한 이야기다. Claude Code에는 "Skills"라는 기능이 있다. 특정 상황에서 자동으로 읽어들이는 방법론의 저장소다.

먼저 결론부터 말하겠다. 나의 Skills는 대부분 스스로 발명한 것이 아니다. 좋은 방법론을 여러 곳에서 찾아내어, 자신의 개발에 맞는 형태로 다시 다진 것이다. 이 기사는 그 출처를 솔직하게 정리하는 기록이 될 것이다.

Skills란 무엇인가

Skill은 하나의 Markdown 파일로 구성되며, 서두에 YAML의 frontmatter를 가진다.

---
name: grilling
description: >
...

description에 "어떤 때에 사용하는가"를 자연어로 적어두면, 에이전트가 상황을 보고 Skill을 자동으로 읽어들인다. 호출할 때마다 인간이 지정할 필요는 없다.

자신만의 OS에서는 Skill을 두 곳에서 운용하고 있다. _shared-ai/skills/ (蒼, ルナ, 亜里沙 3체 공통)와 .claude/skills/ (蒼 전용)다. "구현 전에 관련 Skill이 있다면 반드시 읽는다"라는 규칙을 지시 파일(Instruction file)에 적어두었기에, 작업의 요충지마다 알아서 참조된다.

여기까지는 기능 설명으로서 흔한 내용이다. 재미있는 점은 지금부터다. 실제로 어떤 Skill이 있는지 살펴보니, 그 출처가 깔끔하게 4가지 패턴으로 나뉘었다.

패턴 1: 이식——GitHub에서 발견하여 그대로 가져오기

grilling이라는 Skill 파일을 열면, 서두에 다음과 같이 적혀 있다.

mattpocock/skills 의 grill-me / grilling 을 蒼向け에 이식 (2026-07-02)

타인이 공개한 스킬 정의를 발견하여 자신의 운용에 맞춰 이식했다고 그대로 적혀 있다. 내용은 구현 전에 요구사항을 일문일답 형식으로 구체화해 나가는 수법이다. 질문은 하나씩, 답변을 기다린 후 다음으로, 가정보다 먼저 코드베이스를 조사한다——재작업(rework)을 줄이기 위한 절차들이 나열되어 있다.

같은 날(2026-07-02), 동일한 리포지토리에서 또 하나를 이식했다. handoff라는 Skill로, 세션을 종료할 때 다음 에이전트(또는 다음의 자신)가 최단 시간 내에 상황을 파악할 수 있도록 구조화된 문서(structured document)를 만드는 절차다. 좋은 것을 하나 발견하면 그 주변부도 함께 가져온다. 이식은 대개 이런 방식으로 이루어진다.

패턴 2: AI를 통한 외부 조사 큐레이션——인간의 손을 거치지 않는 편찬

game-dev-playbook이라는 Skill은 이식과는 만들어지는 방식이 다르다. 파일의 맨 앞에는 이렇게 적혀 있다.

2026-06-29, Sonnet 서브 에이전트 4체의 외부 조사(Web+GitHub, 출처 URL 포함)를 蒼(Fable)이 취사선택 및 대조하여 편찬.

여러 AI 서브 에이전트에게 방치형 게임의 수학이나 프레스티지(prestige) 설계, Steam 출시 전략 등을 외부 조사하게 하고, 그것을 다른 AI(당시의 Fable)가 단독으로 취사선택 및 대조하여 하나의 플레이북(playbook)으로 정리했다. 인간의 손은 개입되지 않았다. AI가 조사하고, AI가 편찬했다.

내부의 지견(각 프로젝트의 DECISIONS.md)이 "실제로 해본 결과"라면, 이 플레이북은 "외부의 시장 관점"이다. 양자를 대조하여 정답을 확인하는 방식으로 사용하도록 설계되었다.

패턴 3: 사용할 수 있을 때 기록해 두기

fable-mindset은 또 다른 출처를 가지고 있다.

Fable을 사용할 수 없게 되기 전에, Fable이 실제로 사용하던 판단 기준을 Fable 스스로 언어화하여 남겨두었다.

"암묵적으로 할 수 없는 것을 명시적으로 하라"——AI가 자신의 사고를 다음에 사용할 다른 AI(혹은 동일한 자신)를 향해 남긴 인수인계다. 읽기, 쓰기, 멈추기, 묻기, 각각의 국면에서 무엇을 기준으로 판단할지가 적혀 있다. 발견해서 이식한 것이 아니라, 사용할 수 있을 때 써달라고 한 것이다. 앞선 두 가지와는 질감이 조금 다르다.

패턴 4: 자작——전부가 빌려온 것은 아니다

지금까지 세 가지 모두 "외부에서 찾아 모은" 이야기였다. 하지만 그것으로 끝내버리면, 이번에는 그 자체가 정확하지 않게 된다. 실제로는 우리 스스로 처음부터 설계한 Skills도 있다.

honest-advisor는 출처가 명시되어 있지 않다. 하위 모델의 조언은 「추종」, 「얕은 망라」, 「입장 회피」라는 세 가지 측면에서 저하되기 쉽다는 observation (관찰)에서 시작하여, 반드시 입장을 취할 것, 급소를 하나 특정할 것, 숫자로 환산할 것이라는 대응책을 정의하고 있다. 이것은 찾아낸 것이 아니라, 우리가 직접 설계한 프로토콜이다.

daily-note 역시 마찬가지로 자작이며, 외부에서 영감을 받은 흔적은 없다. 매일의 작업이 끝날 때, 각 에이전트가 자신의 캐릭터 말투로 한마디를 남긴다는, 자신 OS 특유의 운용 그 자체를 Skill로 만들었다.

이식, AI에 의한 큐레이션, 사용할 수 있을 때 기록해 둔 것, 그리고 자작. 이 4가지가 혼재되어 있는 것이 실태다.

출처는 다르더라도, 공통된 것

출처가 무엇이든, Skill 파일에는 반드시 경위가 적혀 있다. 이식이라면 출처 URL, 큐레이션이라면 어떤 AI가 무엇을 어떻게 편찬했는지, 기록물이라면 언제 누구로부터 받았는지. 자작인 경우에도 숨기지 않고 자작임을 알 수 있도록 작성되어 있다.

이것은 규약이라기보다, 글을 쓸 때의 습관 같은 것이다. 하지만 이 습관 덕분에 나중에 다시 보았을 때 "이것은 어디에서 왔는가"를 즉시 알 수 있다. 이전에 작성한 공유 메모리 층의 CHARTER.md에도 같은 정신이 흐르고 있다 —— 출처를 알 수 없는 정보는 신뢰할 수 없다.

그리고 일단 Skill이 되면, 3체의 에이전트 전원이 그것을 바탕으로 움직이게 된다. 개인적으로 발견한 하나의 방법론이 팀 전체의 전제가 된다. 공유 메모리가 "무엇을 알고 있는가"를 맞춘다면, Skills는 "어떻게 하는가"를 맞춘다. 양쪽이 모두 갖춰져야 비로소 팀으로서 기능한다.

요약

Skills는 방법론을 발명하는 곳이 아니라, 좋은 것을 찾아내고, 수집하여, 자신들의 개발에 맞는 형태까지 다시 다지는 곳이었다. 다만 전부가 그런 것은 아니며, 직접 설계한 것도 분명히 존재한다 —— 그 혼재된 모습까지 포함하여 실태라고 생각한다.

이것으로 자신 OS를 지탱하는 4가지 메커니즘 —— 인격을 가진 에이전트, 공유 메모리 층, 진척 대시보드, 그리고 Skills —— 가 한 차례 모두 갖춰졌다.

다음 회차에서는 메커니즘 외부의 이야기를 쓰겠다. 3체의 AI 에이전트에게 실제로 목소리를 입힌 이야기다.

Discussion