Claude Code 1000시간 사용 후 남은 10개 스킬과 플러그인

URL: https://www.youtube.com/watch?v=KtEdSugo3Kw 날짜: 2026-08-20 원문 게시일: 2026-08-19 채널: 마일드코드 영상 길이: 11분 45초 주제: Claude Code Skills · Plugins · Vibe Coding 워크플로

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==Claude Code 스킬과 플러그인은 많이 설치할수록 좋은 것이 아니라, 자신의 반복 워크플로에 맞고 컨텍스트 비용과 권한을 감당할 수 있는 것만 남겨야 한다.==

• Claude Code에 기본으로 포함된 /deep-research, /goal, /batch만으로도 조사·목표 기반 실행·대규모 병렬 변경을 수행할 수 있다.
• superpowers, Remotion, gstack, Karpathy skills는 각각 개발 절차·영상 제작·운영 방식·코딩 원칙을 확장하지만, 사용자의 작업 방식과 맞지 않으면 오히려 꺼지게 된다.
• /doctor와 /context는 사용하지 않는 스킬·MCP·플러그인이 매 턴 차지하는 컨텍스트와 토큰 비용을 드러내며, 설치 전에도 플러그인의 비용과 구성 요소를 확인해야 한다.
• 남의 스킬은 남의 워크플로이므로 반복 작업을 직접 관찰하고, 같은 지시를 계속 복사하는 순간에 skill-creator로 자기 스킬을 검증하며 만들어야 한다.

마일드코드는 Claude Code를 개발자이자 1인 사업가로 장시간 사용하면서 결국 매일 쓰게 된 열 가지를 추렸다. 추천의 기준은 유명세나 목록의 길이가 아니라 실제 작업에서의 지속성이다. 영상의 결론은 도구를 많이 아는 사람이 아니라 자신의 작업 순서를 명확히 이해하고, 무엇을 자동화해야 하는지 판단하는 사람이 스킬을 잘 쓰는 사람이라는 데 있다. 만드는 일은 쉬워졌지만 배포·홍보·운영까지 이어지는 후속 워크플로는 여전히 사람이 설계해야 한다.

1. Claude Code 스킬을 고르는 기준

1.1. 많이 설치하는 것보다 실제로 남는 것이 중요하다

1. 장시간 사용 후 남은 도구

   1. 발표자는 Claude Code로 개발하지 않던 시절의 기억이 흐릿해질 만큼 오랫동안 Claude Code를 사용해 왔다.
   2. 현직 개발자이자 1인 사업가로서 잠자는 시간을 제외하면 거의 모든 시간을 Claude Code와 함께 보낸다고 말한다.
   3. 직접 여러 스킬을 만들고 다른 사람이 만든 스킬도 가져와 사용했지만, 지금까지 매일 쓰는 유용한 스킬의 수는 생각보다 많지 않았다.

2. 추천 목록의 조건

   1. 소개하는 항목은 누구나 받아서 쓸 수 있는 공개 스킬과 플러그인이다.
   2. 앞의 세 가지는 별도 설치 없이 Claude Code를 설치하면 이미 사용할 수 있는 기본 기능이다.
   3. 공식 카탈로그만으로도 항목이 매우 많고 커뮤니티까지 포함하면 전부 살펴보는 일이 사실상 불가능하므로, 실제 사용 경험을 기준으로 좁혀야 한다.

1.2. 공식 원본과 현재 버전을 직접 확인한다

1. 정리된 정보보다 원본을 본다

   1. 영상은 소개하는 항목마다 공식 문서와 GitHub 원본 파일을 직접 띄워 확인한다.
   2. 다른 사람이 정리한 블로그의 설명만 믿지 않고, 현재 명령어가 존재하는지와 실제 저자가 누구인지 원본에서 대조한다.
   3. Claude Code와 플러그인은 빠르게 바뀌므로 촬영 시점과 현재 버전 사이에 기능 차이가 있을 수 있다.

2. 설치 전 검증이 필요한 이유

   1. 오래된 블로그에는 이미 삭제된 명령어가 계속 소개될 수 있다.
   2. 플러그인 카탈로그에는 어떤 구성 요소가 함께 설치되는지와 컨텍스트 비용이 표시될 수 있다.
   3. 설치 전에 원본 문서·레포·마켓플레이스의 최신 상태와 권한 범위를 확인하면 낡은 정보와 과도한 설치를 피할 수 있다.

2. 설치 없이 바로 쓰는 기본 기능 세 가지

2.1. /deep-research: 검색이 아니라 교차 검증 리서치

1. 웹을 여러 출처에서 조사한다

   1. /deep-research에 질문 하나를 던지면 웹에서 여러 페이지를 가져와 조사한다.
   2. 한 곳에서 본 내용을 그대로 믿지 않고 다른 출처와 대조한다.
   3. 조사 결과는 출처가 붙은 리포트 형태로 정리되어 사용자가 원문을 다시 확인할 수 있다.

2. 사업 아이디어를 검증하는 방식

   1. 발표자는 만들 것을 정하기 전에 비슷한 서비스가 이미 존재하는지 조사한다.
   2. 경쟁 서비스의 사용자가 어디에서 불편을 느끼는지, 어떤 방식으로 돈을 받는지, 시장에 어떤 대안이 있는지를 한 번에 확인한다.
   3. 블로그 한두 개만 읽고 결론을 내리는 것보다 여러 출처를 교차 검증한 리포트가 제품 방향을 잡는 데 유리하다.

2.2. /goal: 방법 대신 목표를 맡긴다

1. 목표 조건을 걸어 두는 명령어

   1. /goal은 Claude Code에 달성해야 하는 목표와 조건을 설정하는 기능이다.
   2. Claude는 목표가 충족될 때까지 여러 턴을 넘겨 가며 작업을 진행한다.
   3. 목표가 달성되거나 불가능하다고 판단하면 멈추므로 무한정 작업을 붙잡고 있지는 않는다.

2. 목표와 수단을 분리한다

   1. 발표자는 무엇을 달성해야 하는지는 명확하지만 거기까지 갈 방법은 자신도 모를 때 /goal을 사용한다.
   2. 직접 단계별 방법을 지정하는 대신 목표만 걸고, Claude가 시도·실패·수정·재시도를 반복하게 한다.
   3. 예를 들어 회원 가입이 처음부터 끝까지 동작한다는 목표를 걸어 두고 다른 일을 하면 매 턴마다 “계속해 달라”고 입력하는 기계적 동작이 사라진다.

3. 상태 확인과 중단

   1. 인자 없이 명령어를 실행하면 현재 걸어 둔 목표와 최근 달성한 목표를 확인할 수 있다.
   2. 중간에 멈추고 싶으면 clear 또는 stop을 붙여 목표 실행을 종료할 수 있다.
   3. 자동 실행을 맡기더라도 결과가 실제로 목표를 충족하는지 최종 검증은 사람이 해야 한다.

2.3. /batch: 대규모 변경을 독립 작업으로 쪼갠다

1. 프로젝트를 독립 단위로 분해한다

   1. /batch는 먼저 프로젝트를 훑은 뒤 작업을 대략 5개에서 30개 정도의 독립적인 단위로 나눈다.
   2. 계획을 먼저 보여 주고 사용자의 승인을 기다린다.
   3. 승인 후 각 단위마다 백그라운드 에이전트를 붙여 병렬로 실행한다.

2. 격리된 Git worktree와 검증

   1. 각 에이전트는 격리된 Git worktree에서 작업하므로 서로의 변경이 충돌할 가능성을 줄인다.
   2. 각 단위는 테스트를 실행하고 Pull Request를 만든다.
   3. 한 폴더 전체를 다른 기술로 전환하는 것처럼 규모가 크고 서로 독립적인 변경에 적합하다.

3. 병렬성의 비용

   1. 에이전트를 한 번에 최대 30개까지 실행할 수 있는 만큼 토큰도 빠르게 소모된다.
   2. 작업이 실제로 독립적인지 확인하지 않으면 병렬성이 오히려 충돌과 검토 부담을 만든다.
   3. /batch는 빠른 대량 변경을 위한 기능이지, 모든 작업을 무조건 병렬화하는 명령어가 아니다.

3. 설치해서 쓰는 개발 워크플로 확장

3.1. superpowers: 코드를 바로 쓰지 않는 절차

1. 개발 방식 자체를 바꾼다

   1. 앞의 세 가지가 필요할 때 호출하는 기능이라면 superpowers는 개발하는 방식 자체를 바꾼다.
   2. “무엇을 만들어 달라”고 하면 곧바로 코드를 작성하지 않고 먼저 질문한다.
   3. 요구사항을 확인한 뒤 설계를 보여 주고 승인을 받고 계획을 세운다.

2. 구현 전 검증 절차

   1. 계획이 승인되면 worktree를 만들고 서버 에이전트를 붙인다.
   2. 구현보다 먼저 테스트를 작성하는 방식으로 개발한다.
   3. 마지막에는 별도의 리뷰를 돌려 결과를 다시 확인한다.

3. 사용 범위를 조절한다

   1. 질문·설계·승인 절차가 추가되므로 급하게 작은 버그 하나를 고칠 때는 답답하게 느껴질 수 있다.
   2. 발표자는 새 기능을 처음 설계할 때는 켜지만 단순한 버그 수정에는 끈다고 말한다.
   3. 설치 가능한 공식 마켓플레이스가 있더라도 자신의 작업 속도와 검증 수준에 맞춰 적용 범위를 정해야 한다.

3.2. Remotion 플러그인: 영상 제작을 코드로 다룬다

1. 웹 기술 기반 영상 제작

   1. Remotion은 웹 기술로 영상을 만드는 도구이며, 만든 회사가 Claude Code 플러그인을 직접 제공한다.
   2. 플러그인에는 영상 만들기, 스튜디오 실행, 렌더링, 자막, 지도 애니메이션 등 12개의 스킬이 포함되어 있다.
   3. 영상 편집 프로그램을 직접 조작하는 대신 코드로 화면과 데이터를 정의하고 렌더링할 수 있다.

2. 반복 영상 제작의 효율

   1. 발표자는 자신의 영상 일부를 Remotion으로 만든다.
   2. 숫자나 데이터가 바뀌면 코드에서 해당 값만 수정한 뒤 다시 렌더링하면 된다.
   3. 같은 형식의 영상을 반복해서 만드는 사람에게는 편집 프로그램을 열고 수작업으로 수정하는 시간을 크게 줄여 준다.

3. 콘텐츠 제작자에게 맞는 도구

   1. 무언가를 만들어 설명하는 사람은 영상 제작 과정 자체를 개발 워크플로로 편입할 수 있다.
   2. 데이터 기반 설명 영상이나 반복 포맷을 운영할 때 코드의 재사용성과 자동화가 특히 유용하다.
   3. 영상 제작을 하지 않는 개발자에게는 이 플러그인의 가치가 상대적으로 작을 수 있으므로 목적에 맞게 선택해야 한다.

4. 다른 사람의 운영 방식을 읽는 플러그인

4.1. gstack: 창업자의 하루를 명령어로 공개한다

1. Garry Tan의 운영 명령어 모음

   1. gstack은 Y Combinator 대표 Garry Tan이 만든 Claude Code 도구로 소개된다.
   2. 약 54개의 스킬과 명령어가 포함되어 있으며, 규모보다 명령어의 성격이 흥미로운 사례로 제시된다.
   3. /office-hours, CSO 관점의 계획, CEO 리뷰 같은 명령어는 일반적인 개발 명령어가 아니라 회사 운영 방식을 반영한다.

2. 명령어에 담긴 업무 방식

   1. office hours는 Y Combinator가 창업자들을 상담하는 방식을 연상시키며 문제를 함께 점검하는 흐름을 담는다.
   2. CEO 리뷰는 대표의 관점에서 계획을 다시 살펴보게 한다.
   3. gstack을 보면 명령어 목록이 단순한 기능 모음이 아니라 한 사람이 실제로 일하는 순서와 판단 기준의 표현임을 알 수 있다.

4.2. 설치보다 아이디어 수집에 활용한다

1. 초보자에게는 직접 설치를 권하지 않는다

   1. gstack은 일반 플러그인 설치 방식이 아니라 setup script를 직접 실행하는 방식으로 소개된다.
   2. 포함된 스킬이 많아 초보자가 전체 구조와 권한과 비용을 파악하기 어렵다.
   3. 발표자는 gstack을 설치하지 않고 명령어 목록을 읽으며 자신의 워크플로에 필요한 아이디어만 가져온다.

2. 반복 작업을 발견하는 레퍼런스

   1. gstack은 Garry Tan이 어떤 일을 자동화했는지 한눈에 보여 준다.
   2. 사용자는 자신의 반복 작업과 Claude Code에서 반복되는 문제를 gstack의 명령어와 비교할 수 있다.
   3. 남의 도구를 그대로 복사하기보다 그 도구가 해결하는 업무 문제를 추출해 자기 스킬로 다시 만드는 접근이 안전하다.

5. andrej-karpathy-skills: 원칙은 유용하지만 저자를 확인한다

5.1. 네 가지 코딩 원칙

1. 코딩 전에 생각한다

   1. 구현을 바로 시작하기 전에 무엇을 만들고 왜 만드는지 먼저 정리한다.
   2. 목표와 제약을 확인하면 불필요한 코드 생성과 되돌리기를 줄일 수 있다.

2. 단순하게 간다

   1. 가능한 가장 단순한 설계를 우선한다.
   2. 복잡한 추상화와 과도한 기능을 추가하기 전에 현재 문제를 해결하는 최소 구조를 선택한다.

3. 수술하듯 최소한만 고친다

   1. 변경 범위를 필요한 부분으로 제한한다.
   2. 관련 없는 코드까지 한꺼번에 바꾸지 않으면 회귀 위험과 리뷰 부담을 줄일 수 있다.

4. 목표를 놓치지 않는다

   1. 구현 과정에서 새로운 아이디어를 발견해도 원래 달성하려던 목표를 기준으로 우선순위를 유지한다.
   2. 좋은 코드나 새 기술을 추가하는 일이 제품 문제 해결을 방해하지 않도록 한다.

5.2. 유명한 이름과 실제 저자를 분리한다

1. Karpathy가 직접 만든 스킬이 아니다

   1. 스킬에는 Andrej Karpathy의 이름이 붙어 있지만 실제 파일을 확인하면 저자는 다른 개발자다.
   2. 해당 개발자가 Karpathy가 쓴 글을 읽고 네 가지 원칙으로 정리해 만든 것이다.
   3. 유명인의 이름이 붙었다는 사실만으로 공식 도구나 본인 제작물이라고 판단해서는 안 된다.

2. 원칙을 프롬프트 규칙으로 활용한다

   1. 초보자는 이 네 가지 원칙만으로도 Claude Code가 더 단순하고 똑똑해진 것처럼 느낄 수 있다.
   2. 다만 스킬의 이름보다 실제 파일의 출처와 내용과 유지 상태를 먼저 확인해야 한다.
   3. 원칙을 그대로 설치하기보다 자신의 코드 리뷰 기준과 맞는지 검토한 뒤 적용하는 것이 바람직하다.

6. /doctor: 설치한 도구를 점검하고 정리한다

6.1. 사용하지 않는 구성 요소와 컨텍스트 비용을 찾는다

1. 설정 진단

   1. /doctor는 별도 설치가 필요 없는 기본 기능이다.
   2. 사용자가 설치해 두고 호출하지 않는 스킬·MCP·플러그인을 찾아 보여 준다.
   3. 각 구성 요소가 매 턴 소비하는 컨텍스트 비용과 느린 훅도 함께 점검한다.

2. CLAUDE.md와 상시 로딩 규칙

   1. CLAUDE.md가 지나치게 커졌다면 내용을 줄이는 방향을 제안한다.
   2. 항상 로딩되는 규칙을 필요할 때만 켜지는 스킬로 옮기는 방법도 제안한다.
   3. 변경 전에 무엇을 발견했는지 먼저 보여 주고 사용자의 승인을 묻기 때문에 자동 정리로 인한 위험을 줄인다.

3. 사용하지 않은 도구를 드러내는 진단

   1. 발표자는 /doctor를 처음 실행했을 때 두 달 동안 한 번도 호출하지 않은 스킬이 줄줄이 나와 민망했다고 말한다.
   2. 설치한 도구의 숫자가 실제 생산성을 의미하지 않는다는 사실을 보여 주는 사례다.
   3. 정기적으로 실제 사용 빈도와 컨텍스트 비용을 점검해야 도구가 작업을 돕는지 방해하는지 알 수 있다.

6.2. 컨텍스트는 공짜가 아니다

1. 설치 전 비용 확인

   1. 플러그인 상세 화면에는 context cost가 표시된다.
   2. 해당 플러그인이 매 턴 컨텍스트를 얼마나 사용하는지와 함께 설치되는 구성 요소를 미리 볼 수 있다.
   3. 기능이 많다는 이유로 플러그인을 계속 설치하면 사용할 때뿐 아니라 매 턴의 토큰 사용량도 늘어날 수 있다.

2. 컨텍스트가 차면 과거를 잊는다

   1. 세션 컨텍스트가 가득 차면 Claude가 앞에서 나눈 이야기를 잊기 시작할 수 있다.
   2. 사용하지 않는 플러그인과 상시 로딩 규칙이 소중한 컨텍스트 공간을 차지하면 실제 문제 해결에 필요한 정보가 밀려난다.
   3. /context로 현재 세션이 무엇으로 채워져 있는지 확인하고, 큰 규칙은 필요할 때만 로드되는 스킬로 분리하는 것이 대응책이다.

3. 관리의 기준

   1. 모든 규칙을 CLAUDE.md에 넣는 방식은 편해 보이지만 매 턴 비용을 만든다.
   2. 자주 쓰지 않는 지침은 스킬로 분리해 필요할 때만 켜는 편이 컨텍스트와 비용을 관리하기 좋다.
   3. 스킬과 플러그인은 기능 목록이 아니라 세션 자원을 사용하는 실행 구성 요소로 봐야 한다.

7. 플러그인의 권한과 공급망 위험

7.1. 플러그인은 사용자의 권한으로 코드를 실행한다

1. 권한 범위

   1. Claude Code 플러그인은 사용자의 권한으로 코드를 실행할 수 있다.
   2. 이는 단순한 프롬프트 묶음이 아니라 로컬 환경과 파일과 명령어에 영향을 줄 수 있는 실행 구성 요소라는 뜻이다.
   3. 설치한 플러그인의 코드와 스크립트를 신뢰할 수 있어야 한다.

2. Anthropic의 검증 범위

   1. 영상에서 소개한 공식 문서에는 Anthropic이 플러그인 내부에 무엇이 들어 있는지 통제하거나 검증하지 않는다고 적혀 있다고 설명한다.
   2. 공식 카탈로그에 보인다는 사실만으로 모든 플러그인의 코드가 안전하다고 간주할 수 없다.
   3. 플러그인마다 원본 레포와 설치 스크립트와 실행 권한을 따로 확인해야 한다.

7.2. 신뢰할 수 있는 출처와 최신성 확인

1. Trail of Bits의 선별 마켓플레이스

   1. 보안 회사 Trail of Bits는 플러그인 레포와 스크립트를 한 줄씩 읽고 승인하는 별도 마켓플레이스를 만들었다.
   2. 사람이 내용을 검토했다는 점은 무작위 커뮤니티 설치보다 신뢰 판단에 도움이 된다.
   3. 그래도 사용자는 자신의 권한으로 실행되는 코드를 직접 확인해야 하며, 검토 여부가 위험을 완전히 제거하지는 않는다.

2. 오래된 정보의 위험

   1. 블로그에는 이미 삭제된 명령어가 여전히 소개될 수 있다.
   2. 공식 문서에 삭제된 명령어라고 적혀 있어도 과거 글은 계속 검색 결과에 남는다.
   3. 설치 명령과 사용법은 현재 공식 문서와 원본 레포에서 다시 확인해야 한다.

8. claude-code-setup: 남의 목록 대신 내 프로젝트를 진단한다

8.1. 공식 플러그인이 현재 프로젝트를 살핀다

1. 내가 만드는 것을 직접 분석한다

   1. claude-code-setup은 Anthropic이 직접 만든 플러그인으로 소개된다.
   2. 사용자가 만들고 있는 프로젝트를 열어보고 현재 구조와 작업 방식에 맞는 자동화를 추천한다.
   3. 인터넷에서 인기 있는 스킬 목록을 그대로 보여 주는 것이 아니라 자신의 프로젝트에 필요한 것을 진단한다.

2. 반복 작업을 자동화 후보로 바꾼다

   1. 매번 반복하는 작업을 찾아 어떤 것을 자동화하면 좋은지 제안한다.
   2. 사용자는 자신이 어떤 일을 반복하고 있는지 명확히 보지 못할 때도 프로젝트 기반의 추천을 통해 출발점을 얻을 수 있다.
   3. 추천이 모두 정답은 아니지만 자동화할 대상을 전혀 모르겠을 때 좋은 진단 도구가 된다.

8.2. 개인 프로젝트에 맞는 자동화가 출발점이다

1. 상담의 한계를 보완한다
   1. 마일드코드의 구독자들은 바이브 코딩 과정에서 겪는 문제를 상담하지만, 발표자가 모든 프로젝트를 직접 살펴볼 수는 없다.
   2. 각 프로젝트의 반복 문제를 사용자가 직접 진단할 수 있는 도구로 claude-code-setup을 추천한다.
   3. 남의 프로젝트에서 효과가 난 스킬보다 자신의 코드베이스에서 반복되는 문제를 먼저 보는 편이 자동화 성공률을 높인다.

9. skill-creator: 남의 워크플로를 자기 스킬로 바꾼다

9.1. 남의 스킬이 그대로 맞지 않는 이유

1. 스킬은 워크플로의 압축물이다

   1. 다른 사람이 만든 스킬은 그 사람이 일하는 순서와 판단 기준을 담고 있다.
   2. 같은 개발 도구를 사용해도 프로젝트·팀·품질 기준·배포 방식이 다르면 동일한 스킬이 같은 효과를 내지 못한다.
   3. 좋은 스킬을 전부 설치해도 자신의 문제가 풀리지 않는 이유는 도구가 부족해서가 아니라 워크플로가 다르기 때문이다.

2. 사례로 본 부적합

   1. 발표자는 자신의 작업 방식에 맞춘 스킬을 많이 만들었지만, 자신의 목록에 없다고 해서 다른 사람에게 유용하지 않은 것은 아니라고 설명한다.
   2. 반대로 자신에게 잘 맞는 스킬을 그대로 배포해도 다른 사람의 업무에는 맞지 않을 수 있다.
   3. superpowers의 질문 중심 흐름이 싫은 사람은 좋은 도구를 설치하고도 꺼 버리게 되고, gstack의 창업자 운영 방식도 모든 개발자에게 필요한 것은 아니다.

9.2. 반복 지시를 스킬로 만들고 효과를 검증한다

1. 스킬화의 신호

   1. 공식 문서가 제시하는 간단한 기준은 같은 지시를 계속 복사하고 있다면 스킬로 만들 때가 되었다는 것이다.
   2. 반복되는 지시는 이미 사용자의 워크플로에 일정한 패턴이 존재한다는 뜻이다.
   3. 패턴을 명시적인 스킬로 만들면 매번 긴 지시를 다시 입력하지 않아도 된다.

2. 스킬 크리에이터의 역할

   1. skill-creator는 단순히 템플릿을 찍어 주는 도구가 아니다.
   2. 만든 스킬을 켠 상태와 끈 상태에서 각각 실행해 실제 효과가 있는지 비교한다.
   3. 이런 비교까지 해야 스킬이 지시문을 예쁘게 포장한 것인지, 실제로 작업 결과를 개선하는지 확인할 수 있다.

10. 도구 목록보다 자기 워크플로가 먼저다

10.1. gstack에서 읽어야 할 핵심은 명령어 수가 아니다

1. 업무 순서가 명령어로 나타난다

   1. gstack이 대단한 이유는 스킬 수가 많아서가 아니라 만든 사람이 자신의 일하는 순서를 정확히 알고 있기 때문이다.
   2. 업무 순서를 알고 있으니 자동화할 작업을 구분할 수 있고, 그 결과가 명령어로 표현된다.
   3. 자기 워크플로를 정확히 이해하지 못하면 무엇을 자동화해야 할지도 결정하기 어렵다.

2. 잘 쓰는 사람과 못 쓰는 사람의 차이

   1. Claude Code 명령어를 몇 개 외웠는지가 사용 능력을 결정하지 않는다.
   2. 무엇을 만들려는지와 어떤 순서로 완성할지가 정리되어 있는지가 더 중요하다.
   3. 도구를 많이 아는 사람보다 자신의 문제와 반복 작업을 명확히 아는 사람이 같은 도구에서 더 큰 결과를 얻는다.

10.2. 만들기 이후의 운영이 진짜 문제다

1. 구현은 쉬워졌지만 운영은 남는다

   1. 발표자는 개인적으로 여러 서비스를 직접 운영하면서 만드는 일은 이제 쉬워졌다고 느낀다.
   2. 어려운 부분은 만든 뒤 배포하고 사람들에게 알리고, 서비스가 깨지지 않게 잘 운영하는 것이다.
   3. 코드 생성 능력이 좋아져도 제품의 유통·사용자 획득·장애 대응·지속 운영은 자동으로 해결되지 않는다.

2. Claude Code가 대신 정하지 못하는 것

   1. Claude Code는 구현과 반복 실행을 도울 수 있지만 제품을 어떤 방식으로 운영할지는 대신 결정하지 않는다.
   2. 배포 전략과 홍보 채널과 운영 기준은 사용자의 사업과 워크플로에 맞춰 직접 설계해야 한다.
   3. 따라서 스킬과 플러그인 탐색은 개발 자동화의 끝이 아니라 운영 시스템을 설계하는 출발점이어야 한다.

주요 발언 모음

“결국 제게 남은 몇 가지 유용한 스킬은 생각보다 많지 않더라고요.”

“방법을 제가 정해서 시키는 게 아니라 목표만 걸어두고 수단은 클로드가 직접 찾게 하는 거예요.”

“남의 스킬은 남의 워크플로예요.”

“플러그인은 여러분 권한으로 아무 코드나 실행할 수 있는 것이에요.”

“같은 지시를 계속 복붙하고 있으면 그때가 스킬로 만들 때다.”

“명령어를 몇 개 아느냐가 아니라 뭘 만들려고 하는지가 정리가 되어 있느냐입니다.”

“만드는 건 이제 쉬워졌는데 문제는 그다음이더라고요.”

핵심 데이터 & 수치

• 11분 45초: 영상 전체 길이.
• 2026-08-19: YouTube 원문 게시일.
• 10개: 발표자가 1000시간 이상 Claude Code를 사용한 뒤 지금도 매일 쓰는 것으로 추린 스킬·플러그인 수.
• 3개: 별도 설치 없이 Claude Code에 기본 포함된 /deep-research, /goal, /batch.
• 5~30개: /batch가 프로젝트를 나누는 독립 작업 단위의 대략적인 규모.
• 최대 30개: /batch에서 병렬로 붙일 수 있다고 소개된 백그라운드 에이전트 규모.
• 12개: Remotion Claude Code 플러그인에 포함된 스킬 수.
• 약 54개: gstack에 포함된 것으로 소개된 스킬·명령어 규모.
• 두 달: 발표자가 /doctor를 처음 실행했을 때 한 번도 호출하지 않은 스킬이 쌓여 있던 기간.
• 컨텍스트 비용: 플러그인과 상시 로딩 규칙이 매 턴 차지하는 토큰 자원으로, 설치 전 확인해야 하는 비용이다.

참고한 원본 자료

• Claude Code 공식 문서: 커맨드 레퍼런스
• Claude Code 공식 문서: /goal 전용 페이지
• Claude Code 공식 문서: 다이내믹 워크플로
• Claude Code 공식 문서: 플러그인 탐색과 설치
• Claude Code 공식 문서: 컨텍스트 윈도우 시뮬레이션
• Anthropic 블로그: 다이내믹 워크플로
• 공식 플러그인 카탈로그: claude.com/plugins
• obra/superpowers
• remotion-dev/claude-code-plugin
• garrytan/gstack
• forrestchang/andrej-karpathy-skills
• addyosmani/web-quality-skills
• trailofbits/skills-curated
• anthropics/skills의 skill-creator

결론 및 시사점

1. Claude Code의 공식 기본 기능부터 확인하면 별도 설치 없이 리서치·목표 기반 실행·병렬 변경을 시작할 수 있다.
2. /goal은 방법을 미리 정하기 어려운 문제에서 목표와 수단을 분리해 반복 실행을 맡기는 방식이다.
3. /batch는 독립 작업에 강력하지만 병렬 에이전트 수만큼 토큰과 리뷰 비용이 커진다.
4. superpowers는 새 기능의 설계·승인·테스트·리뷰 절차를 강화하므로 작업 규모에 맞게 켜야 한다.
5. 플러그인은 기능 묶음이면서 사용자 권한으로 코드를 실행하는 공급망 구성 요소이므로 원본과 스크립트를 확인해야 한다.
6. /doctor와 /context로 사용하지 않는 도구와 상시 로딩 규칙의 컨텍스트 비용을 정기적으로 정리해야 한다.
7. claude-code-setup은 인기 목록을 복사하는 대신 자신의 프로젝트에서 반복되는 자동화 후보를 찾는 출발점이다.
8. skill-creator는 같은 지시를 반복하는 업무를 자기 스킬로 만들고 켠 상태와 끈 상태의 효과를 비교하게 한다.
9. 남의 스킬을 그대로 설치하기보다 그 스킬이 해결하는 워크플로를 추출해 자신의 업무에 맞게 재설계해야 한다.
10. AI 코딩 시대의 핵심 경쟁력은 명령어 암기가 아니라 자신의 제품·개발·운영 순서를 이해하고 자동화할 대상을 고르는 능력이다.

핵심 요약 (20줄)

Claude Code를 오래 사용해도 실제로 매일 남는 스킬과 플러그인의 수는 많지 않다. 공식 카탈로그와 커뮤니티의 모든 항목을 설치하기보다 자신의 작업에 필요한 것만 골라야 한다. /deep-research는 여러 웹 페이지를 교차 검증하고 출처가 붙은 리포트를 만든다. 제품을 만들기 전 경쟁 서비스와 고객 불편과 수익 모델을 조사할 때 /deep-research가 유용하다. /goal은 달성 조건만 설정하고 목표에 도달하는 방법은 Claude가 찾게 하는 기능이다. /goal은 회원 가입처럼 끝까지 검증해야 하는 작업을 맡기고 다른 일을 할 때 효과적이다. /batch는 프로젝트를 5~30개의 독립 단위로 나눠 백그라운드 에이전트와 격리된 worktree에서 처리한다. /batch는 테스트와 Pull Request까지 자동화하지만 병렬 에이전트 수만큼 토큰을 빠르게 소모한다. superpowers는 질문·설계·승인·계획·테스트·리뷰를 거쳐 코드를 작성하는 개발 절차를 만든다. Remotion 플러그인은 영상 제작과 자막과 렌더링을 코드로 다뤄 반복 영상의 시간을 줄인다. gstack은 Garry Tan의 회사 운영 방식과 판단 순서를 명령어 모음으로 보여 주는 레퍼런스다. gstack은 초보자가 그대로 설치하기보다 자신의 반복 업무를 발견하는 아이디어 자료로 활용할 수 있다. Karpathy skills의 네 원칙은 코딩 전 사고·단순화·최소 변경·목표 유지이며 실제 저자는 Karpathy가 아니다. /doctor는 사용하지 않는 스킬·MCP·플러그인과 느린 훅과 컨텍스트 비용을 점검한다. 플러그인과 상시 로딩 규칙이 컨텍스트를 차지하면 Claude가 앞선 대화를 잊기 시작할 수 있다. 플러그인은 사용자 권한으로 코드를 실행하므로 공식 카탈로그에 있다는 이유만으로 무조건 신뢰해서는 안 된다. claude-code-setup은 남의 추천 목록이 아니라 자신의 프로젝트를 보고 필요한 자동화를 제안한다. skill-creator는 같은 지시를 반복하는 업무를 스킬로 만들고 켠 상태와 끈 상태의 효과를 비교한다. 남의 스킬은 남의 워크플로이므로 자신의 업무 순서와 맞지 않으면 좋은 도구도 꺼지게 된다. AI 코딩의 다음 문제는 만드는 일이 아니라 배포·홍보·장애 없는 운영을 자신의 워크플로로 설계하는 일이다.