저는 10년 동안 코드를 작성해 왔습니다. 지난달 Claude Code는 저를 다시 초보자처럼 느끼게 만드는 무언가를 보여주었습니다.

그것이 저보다 똑똑했기 때문이 아닙니다. 그것은 더 빠르고, 더 일관적이었으며, 제가 이전에 본 적 없는 시스템을 사용했기 때문입니다. Anthropic은 이를 Skills 시스템이라고 부릅니다. 커뮤니티는 이를 "superpowers"라고 부르기 시작했습니다. 제 프로젝트 saas.pet에서 3주 동안 매일 사용해 본 결과, 몇 가지 의견이 생겼습니다.

제가 실제로 발견한 내용은 다음과 같습니다.

Superpowers Skill 시스템이란 무엇인가?

2025년 말, Anthropic은 Claude Code에 Skills 레이어를 추가했습니다. 아이디어는 간단합니다. 작업을 시작할 때마다 긴 프롬프트 (prompt)를 작성하는 대신, 재사용 가능한 "기술 (skill)"을 한 번 정의하는 것입니다. Claude는 세션 시작 시 이를 읽습니다. 이는 해당 프로젝트의 모든 작업에 모델이 접근하는 방식을 형성합니다.

이는 .cursorrules 파일과 비슷하지만, 더 구조화되어 있고 에이전트 루프 (agent loop)에 더 긴밀하게 통합되어 있다고 생각하면 됩니다.

A skill은 마크다운 (markdown) 파일입니다. 이는 /mnt/skills/ 디렉토리에 존재합니다. 이름, 설명, 그리고 제약 사항, 패턴, 선호도를 설명하는 본문(body)을 가지고 있습니다. Claude는 당신의 코드에 손을 대기 전에 이를 읽습니다.

일반적인 시스템 프롬프트 (system prompt)와의 차이점은 범위 (scope)와 지속성 (persistence)입니다. 프롬프트는 세션마다 변경됩니다. 반면 skill은 프로젝트마다 변경되며, 중첩될 수 있습니다. 데이터베이스 패턴을 위한 skill, UI 컴포넌트를 위한 다른 skill, 테스트 접근 방식을 위한 또 다른 skill을 가질 수 있습니다.

기능	일반 프롬프트 (Normal Prompt)	Superpowers Skill
범위 (Scope)	단일 세션	전체 프로젝트
...	...	...

아키텍처의 변화는 실재합니다. 당신은 "매번 Claude에게 무엇을 할지 말하는 것"에서 "당신이 일하는 방식을 한 번에 Claude에게 가르치는 것"으로 이동하고 있습니다.

그것으로 실제로 무엇을 만들었나

저는 AI 코딩 도구를 추적하고 순위를 매기는 디렉토리인 saas.pet을 운영하고 있습니다. 제가 계속 수동으로 했던 일 중 하나는 리뷰 페이지 요약을 작성하는 것이었습니다. 각 도구에는 짧은 설명, 사용 사례 분석, 그리고 비교 노트가 포함됩니다.

Skills(기술)를 적용하기 전에는 도구 하나당 약 30분이 소요되었습니다. 매번 똑같은 인지적 작업(cognitive work)을 반복해야 했습니다. 도구의 문서를 열고, 핵심 주장(key claims)을 추출하고, 저만의 말투로 형식을 맞추고, 내부 구조를 추가하는 식이었죠.

저는 이를 위해 하나의 Skill(기술)을 작성했습니다. 여기에는 저의 편집 스타일, 제가 중요하게 생각하는 필드(fields), 사용하는 어조(tone), 그리고 피해야 할 패턴들을 정의했습니다. 이미 잘 알고 있는 다섯 가지 도구를 대상으로 이를 테스트했습니다.

결과는 페이지당 약 5분이 걸렸습니다. 시간 절약 효과는 확실했습니다. 하지만 저를 놀라게 한 것은 그 부분이 아니었습니다.

저를 놀라게 한 부분은 바로 _일관성(consistency)_이었습니다. 다섯 번째 도구에 대한 결과물은 첫 번째 도구의 결과물과 구조적으로 동일해 보였습니다. 필드 순서도 같았습니다. 주장이 불확실할 때 사용하는 완곡한 표현(hedging language)도 같았습니다. 내부 링크 로직(internal linking logic)도 동일했습니다.

수동으로 이 작업을 할 때는 기준이 흔들립니다. 첫 번째 페이지에는 포함했던 내용을 세 번째 페이지에서는 빠뜨리기도 합니다. 하지만 Skill(기술)은 흔들리지 않습니다.

그 일관성이야말로 실제 가치입니다. 속도가 아니라 말이죠.

내가 처음에 했던 실수들

저의 초기 세 가지 Skill(기술)은 형편없었습니다. 단순히 조금 안 좋은 수준이 아니라, 쓸모가 없었습니다.

첫 번째는 너무 모호했습니다. 저는 "전문적이면서도 친근한 어조로 작성하라"와 같은 식으로 썼습니다. Claude는 이미 그렇게 하고 있었습니다. 저는 Claude에게 새로 작업할 만한 아무런 정보도 주지 않았던 것입니다.

두 번째는 너무 길었습니다. 한 번에 모든 것을 다루려고 시도했습니다. 어조, 서식(formatting), 링크 전략, 데이터 소스, 출력 구조까지 말이죠. Claude는 이를 읽고 나서 기본적으로 대부분을 무시해 버렸습니다. 신호(signal)가 노이즈(noise) 속에 파묻혀 있었기 때문에 일반적인 동작(generic behavior)으로 돌아가 버린 것입니다.

세 번째는 상충하는 지침(conflicting instructions)이 있었습니다. 한 섹션에서는 "간결하게 작성하라"고 말하면서, 다른 섹션에서는 "항상 상세한 비교 표를 포함하라"고 했습니다. Claude는 둘 중 하나를 선택하고 다른 하나는 버렸습니다.

네 번째는 제대로 작동했습니다. 무엇이 바뀌었는지 소개하겠습니다:

• 하나의 기술, 하나의 관심사. 저의 작업 기술은 리뷰 페이지 구조를 검토하는 범위만 다룹니다.
• 추상적인 것보다 구체적인 것. "장단점에 불렛 포인트(bullet points)를 사용하세요"가 "정리하세요"보다 훨씬 낫습니다.
• 지침보다 예시. 샘플 출력 블록을 하나 포함했습니다. 그것 하나만으로도 200단어의 설명보다 더 가치 있었습니다.
• 명시적인 트리거 (Explicit triggers). 기술을 언제 적용하고 언제 무시해야 하는지 정확하게 알려주었습니다.

저의 조언은 이렇습니다: 워크플로에서 가장 반복적인 단 하나의 작업부터 시작하세요. 그 한 가지를 위한 기술을 작성하세요. 그것이 제대로 작동하게 만드세요. 그러고 나서, 오직 그 이후에만 두 번째 기술을 작성하세요.

Cursor 및 Copilot과의 비교

Cursor는 Background Agent와 .cursorrules 시스템을 통해 유사한 기능을 제공합니다. 철학은 비슷하지만 구현 방식은 다릅니다. Cursor는 이를 IDE 레이어에 내장(bake)시켰습니다. 반면 Claude Code는 이를 파일 시스템 아티팩트(file system artifact)로 취급합니다. 팀 워크플로 측면에서는 파일 시스템 방식이 버전을 관리하고 공유하기에 더 쉽습니다.

Copilot은 여전히 대부분 완성(completion) 모드에 머물러 있습니다. 다음 줄을 제안할 뿐입니다. 프로젝트 수준에서 지속적인 기술(skill)이나 규칙 시스템을 가지고 있지 않습니다. Microsoft가 에이전트적(agentic) 기능으로 명확히 이동하고 있지만, 2026년 중반 현재까지 기술(skills)이 하는 일과 직접적으로 경쟁할 만한 기능은 출시되지 않았습니다.

저의 솔직한 견해는 이렇습니다: 기술(skill) 시스템은 올바른 추상화(abstraction)입니다. 기술을 작성하는 것은 실제로 읽히는 문서를 작성하는 것과 매우 비슷하게 느껴집니다. 이는 해결할 가치가 있는 좋은 문제입니다.

하지만 아직 초기 단계입니다. Claude가 기술을 부분적으로 무시하는 엣지 케이스(edge cases)를 경험했습니다. 잘못된 기술을 불러오는 세션도 있었습니다. 기술 관리(skill management)를 둘러싼 툴링(tooling)은 여전히 거칠기 때문에, 대부분의 팀이 마찰 없이 채택할 수 있을 정도로 매끄러워지려면 6개월에서 12개월 정도는 더 걸릴 것으로 보입니다.

Claude Code가 Cursor, Copilot 및 나머지 분야와 어떻게 경쟁하는지 추적하고 싶다면, saas.pet/find/?q=claude+code에서 실시간 순위를 확인하실 수 있습니다. 이 순위는 도구들이 새로운 기능을 출시함에 따라 업데이트됩니다.

시작하는 방법

오늘 바로 이것을 시도해보고 싶다면, 가장 빠른 경로는 다음과 같습니다.

1단계. Claude Code에서 반복적으로 수행하는 작업 중 하나를 선택하세요. 열 개가 아니라, 딱 하나만 고르세요.

2단계. 스킬 파일 (skill file)을 작성하세요. 300단어 이내로 유지하세요. 원하는 출력 결과에 대한 구체적인 예시를 하나 포함하세요. 작성한 파일은 프로젝트의 스킬 디렉토리 (skill directory)에 저장하세요.

3단계. 성능을 판단하기 전에 실제 작업 세 가지에 적용해 보세요. 첫 번째 실행은 종종 어색하게 느껴질 수 있습니다. 세 번째 실행쯤 되면 이 스킬이 도움이 되는지, 아니면 단순히 마찰 (friction)만 가중시키는지 알 수 있을 것입니다.

Anthropic 문서에서 기술적인 설정 방법을 다루고 있습니다. 설정은 어려운 부분이 아닙니다. 진짜 어려운 부분은 Claude의 동작을 유용한 방향으로 실제로 변화시킬 수 있는 스킬을 작성하는 것입니다. 이를 위해서는 반복적인 개선 (iteration)이 필요합니다.

마지막 생각

스킬 시스템은 Anthropic이 개발자들을 위해 출시한 기능 중 최근 들어 구조적으로 가장 흥미로운 요소입니다. 이것은 마법이 아닙니다. 하나의 규율 (discipline)입니다. Claude가 일관되게 수행하기를 원하는 것이 무엇인지 신중하게 생각한 다음, Claude가 사용할 수 있는 방식으로 그것을 기록해야 합니다.

스킬을 작성하는 과정은 저 자신의 멘탈 모델 (mental models)이 얼마나 허술했는지를 깨닫게 해주었습니다. Claude가 일관성을 갖도록 만드는 과정은 저 스스로가 먼저 일관성을 갖도록 강제했습니다.

더 넓은 AI 코딩 도구 생태계가 어떻게 변화하고 있는지 알고 싶다면, 저는 AI 코드 에디터 (AI code editors) 순위를 포함하여 25개 이상의 도구를 saas.pet에서 추적하고 있습니다. 순위는 상황 변화에 따라 업데이트됩니다. 이 분야가 귀하의 업무에 중요하다면 북마크할 가치가 있습니다.

Alex는 AI 기반 개발자 도구 디렉토리인 saas.pet의 창립자입니다.