드디어 터득한 Claude 에이전트 스킬 (엔지니어를 위한 분석)

IndyDevDan 구독자 43,800명

요약

이 영상에서는 Anthropic Cloud Code의 에이전트 스킬, 서브 에이전트, 커스텀 슬래시 커맨드, MCP 서버 등 주요 기능을 비교하고 적절히 사용하는 방법을 제시한다. PDF 자동 추출, 외부 API 통합, 병렬 워크플로우, 수동 명령 실행 같은 대표 사례로 네 가지 기능의 역할을 분류하며 혼동을 없앤다. 특히 프롬프트가 AI 에이전트 코딩의 핵심이며, 처음에는 슬래시 커맨드(프롬프트)를 기반으로 시작해 필요에 따라 서브 에이전트나 스킬로 확장할 것을 강조한다.

주요 키워드

프롬프트 에이전트 스킬 서브 에이전트 커스텀 슬래시 커맨드 MCP 서버 컨텍스트 윈도우 모듈러리티 컴포저빌리티 훅 출력 스타일

하이라이트

🔑 에이전트 스킬은 반복 워크플로우를 자동화하고 전용 디렉터리 구조로 모듈화해 에이전트가 자율적으로 트리거할 수 있도록 설계되었다.
⚡️ MCP 서버는 외부 API나 데이터 소스를 통합해 에이전트가 실시간으로 외부 연동 작업을 수행하게 돕는다.
🚀 서브 에이전트는 격리된 컨텍스트 창을 유지하며 병렬 워크로드를 처리할 수 있어 대규모 테스트나 감사 같은 작업에 적합하다.
🌟 커스텀 슬래시 커맨드는 프롬프트 기반 개발의 기본 단위로, 수동으로 호출해 단일 작업을 효율적으로 처리할 수 있다.
📌 네 가지 기능별 대표 사례를 통해 어떤 상황에 스킬, MCP, 서브 에이전트, 슬래시 커맨드를 선택할지 명확히 구분한다.
🔄 모듈러리티와 컴포저빌리티를 활용해 기능을 조합하거나 상호 호출하며 복합 워크플로우를 구축하는 방법을 소개한다.
💡 ‘프롬프트가 곧 코드다’라는 관점에서, 먼저 슬래시 커맨드로 프롬프트를 관리한 뒤 점진적으로 서브 에이전트나 스킬로 확장할 것을 권장한다.
🛠 코어 4(Core 4: 컨텍스트·모델·프롬프트·툴)를 기반으로 기능을 설계하고 조합해야 안정성과 확장성을 보장할 수 있다.
⚙️ 스킬의 장점(전문성 패키징, 컨텍스트 보호, 모듈러 구조)과 단점(프롬프트 내장 미지원, 신뢰성 검증 필요)을 균형 있게 평가한다.
🎯 최종적으로는 프로젝트 규모와 자동화 수준에 맞춰 슬래시 커맨드를 우선하고, 필요 시 서브 에이전트·MCP·스킬로 확장할 것을 제안한다.

용어 설명

에이전트 스킬 (Agent Skills)

파일 시스템 기반의 전문가 지식 묶음으로, 에이전트가 자동으로 반복 워크플로우에 적용하도록 트리거 및 모듈러리티 제공

서브 에이전트 (Sub Agents)

독립된 컨텍스트 윈도우에서 병렬화 가능한 워크로드를 위임해 처리하는 하위 에이전트

커스텀 슬래시 커맨드 (Custom Slash Commands)

명시적 수동 실행을 위한 사용자 정의 프롬프트 단축 명령으로, 프롬프트 기반 개발의 기본 단위

MCP 서버 (MCP Servers)

에이전트를 외부 API/데이터 소스와 연결해 통합 워크플로우를 지원하는 서버 기반 기능

프롬프트 (Prompt)

AI 모델에 입력하는 지시문으로, 에이전트 코딩의 핵심 단위이자 모든 기능의 기초

컨텍스트 윈도우 (Context Window)

AI 모델이 한 번에 참조할 수 있는 입력 길이로, 효율적 관리가 성능에 직결

모듈러리티 (Modularity)

기능을 독립적 디렉터리 구조로 분리해 재사용 및 유지보수를 쉽게 하는 특성

컴포저빌리티 (Composability)

스킬, 서브 에이전트, 슬래시 커맨드, MCP 서버 등 각 기능을 조합해 복합 워크플로우를 구축하는 능력

훅 (Hooks)

에이전트 실행 생명주기 단계에 명령을 결정론적으로 실행하도록 연결하는 자동화 도구

출력 스타일 (Output Styles)

에이전트의 작업 결과를 요약, 변환, 음성 합성 등 다양한 형태로 포맷팅하는 설정

Cloud Code의 에이전트 스킬, 서브 에이전트, 커맨드, MCP 서버 등 기능이 늘어나며 혼란스러워진 현황을 짚고, 간소화가 필요한 이유를 소개한다.

[00:00] 지난 주 동안 Claude의 에이전트 스킬 기능을 연구했으며, 현재는 에이전트 스킬, 서브 에이전트, 커스텀 명령어 등 다양한 기능을 사용할 수 있습니다. Claude Code는 2월 출시 이후 엔지니어링 방식을 혁신했지만 복잡해졌다고 설명합니다.

[00:35] 스킬은 간단하지만 MCP, 서브 에이전트, 커스텀 슬래시 명령어와 유사해서 언제 사용해야 하는지 혼란스럽다고 지적합니다. 올바른 사고방식과 잘못된 방식을 모두 보여주겠다고 약속합니다.

스킬·서브 에이전트·커스텀 커맨드를 무작정 병렬로 호출하는 사례를 통해, 기능별 차이를 모르면 오히려 복잡해지는 문제를 보여준다.

[01:08] 엔지니어링 문제 해결을 위한 잘못된 스킬 사용법을 예시로 들며, git work tree 관리를 위해 스킬, 서브 에이전트, 커스텀 명령어 중 어느 것을 사용해야 하는지 질문을 던집니다.

[01:39] 네 가지 주요 기능을 비교 분석합니다. 스킬은 에이전트에 의해 자동 트리거되는 점에서 돋보이며, 서브 에이전트도 유사하지만 사용자가 명시적으로 시작하는 슬래시 명령어와는 다르다고 설명합니다.

트리거 방식, 컨텍스트 효율성, 컨텍스트 지속성의 세 가지 관점에서 스킬·서브 에이전트·슬래시 커맨드·MCP 서버의 특성을 나란히 분석한다.

[02:10] 컨텍스트 효율성이 스킬의 큰 장점이라고 강조합니다. MCP 서버는 부팅 시 컨텍스트 윈도우를 많이 사용하지만, 스킬은 메타데이터, 지시사항, 리소스의 3단계 점진적 공개로 효율적이라고 설명합니다.

[02:40] 컨텍스트 지속성에서 서브 에이전트만 예외적이지만, 이것이 오히려 서브 에이전트의 장점이라고 설명합니다. 컨텍스트 윈도우를 격리하고 보호하는 기능을 제공하며, 병렬 개발에서 큰 우승자라고 결론짓습니다.

서브 에이전트를 이용해 포트별로 독립된 컨텍스트 창을 생성해 병렬 개발 환경을 구축하는 과정을 시연하며 장점을 강조한다.

[03:04] 워크플로 구축에 대한 설명과 함께 옐로우 트리 워크 트리가 포트 4010에서 성공적으로 생성되고 실행되기 시작합니다.

[03:15] 전문화 기능이 스킬에만 국한되지 않으며, 모든 기능을 전문화하고 공유할 수 있다고 설명합니다.

[03:24] 스킬의 핵심인 모듈성에 대해 설명하며, MCP 서버와의 유사점과 함께 스킬의 전용 디렉토리 구조라는 차별화 요소를 강조합니다.

[03:45] 워크트리 생성 스킬을 예시로 들어 에이전트가 호출할 수 있는 반복 가능한 솔루션 구축을 위한 전용 구조의 중요성을 설명합니다.

[04:07] 스킬, MCP 서버, 서브 에이전트, 슬래시 명령 간의 구성 관계에 대해 설명하며, 특히 스킬과 슬래시 명령의 높은 구성 가능성을 강조합니다.

[04:39] 기능들 간의 겹치는 부분이 많음을 인정하면서도, 전용 모듈형 구조와 에이전트 트리거라는 스킬만의 구별되는 접근 방식을 설명합니다.

PDF 자동 추출→스킬, Jira 연동→MCP, 보안 감사→서브 에이전트, 커밋 메시지 생성→슬래시 커맨드 등 네 가지 기능의 전형적 활용 예를 제시한다.

[05:10] 네 가지 기능의 명확한 용도를 제시합니다: 스킬은 자동 동작, MCP는 외부 통합, 서브 에이전트는 격리된 워크플로, 슬래시 명령은 수동 트리거용입니다.

[05:37] PDF에서 텍스트와 데이터를 자동으로 추출하는 구체적인 사용 사례를 제시하며, 시청자들에게 어떤 기능에 속하는지 추측해보도록 유도합니다.

[05:50] 화자가 다양한 자동화 작업들을 어떤 에이전트 기능으로 분류할지 설명하기 시작합니다. PDF 텍스트 추출 같은 반복 작업은 스킬로, Jira 연결 같은 외부 소스는 MCP 서버로 분류합니다.

[06:15] 보안 감사처럼 복잡하고 확장 가능한 작업은 서브 에이전트로, 커밋 메시지 생성 같은 단순한 일회성 작업은 슬래시 커맨드로 분류하는 기준을 제시합니다.

[06:50] 데이터베이스 쿼리는 MCP 서버로, 대규모 테스트 디버깅은 서브 에이전트로 분류합니다. 스타일 가이드 위반 감지처럼 반복적인 동작은 전용 스킬로 만드는 것이 좋다고 설명합니다.

[07:27] 실시간 날씨 데이터 가져오기는 서드파티 서비스 통합이므로 MCP로, UI 컴포넌트 생성은 간단한 일회성 작업이므로 슬래시 커맨드로 분류합니다.

[07:47] '병렬(parallel)'이라는 키워드가 나오면 무조건 서브 에이전트를 생각해야 한다고 강조합니다. 서브 에이전트만이 병렬 호출을 지원하며, 컨텍스트 격리가 필요한 작업에 적합하다고 설명합니다.

[08:11] MCP는 외부 통합에 관한 것임을 명확히 하며, 각 사용 사례에 적절한 기능을 매칭하는 방법론을 정리합니다.

[08:22] MCP와 서브 에이전트의 적절한 사용 시기를 설명합니다. 여러 서비스를 번들로 묶어 특정 기능으로 노출할 때는 MCP를, 격리된 컨텍스트와 병렬 처리가 필요할 때는 서브 에이전트를 사용해야 한다고 설명합니다.

[08:40] 스킬과 슬래시 명령어의 유사성과 차이점을 분석합니다. 두 기능은 매우 유사하지만 모듈성과 트리거 방식에서만 차이가 있다고 설명합니다.

[09:09] 많은 엔지니어들이 모든 슬래시 명령어를 스킬로 변환하는 것에 대해 비판적 관점을 제시합니다. 슬래시 명령어를 에이전트 코딩과 언어 모델의 기본 요소로 보며, 프롬프트 제거 시 신중함이 필요하다고 강조합니다.

[09:30] 스킬을 MCP/명령어나 서브 에이전트의 대체재가 아닌 구성 단위로 접근해야 한다는 관점을 제시합니다. 각각의 도구들이 고유한 역할을 가지고 있어 하나만 사용하면 안 된다고 설명합니다.

스킬과 슬래시 커맨드의 공통점·차이점을 트리거 방식과 모듈러리티 관점에서 비교하고, 단일 작업엔 슬래시 커맨드, 자동화 반복엔 스킬을 권장한다.

[09:45] 워크 트리 예시를 통해 실제 구현 사례를 보여줍니다. 세 가지 새로운 버전의 코드베이스가 구축되어 있으며, 에이전트들이 프롬프트, 서브 에이전트, 스킬을 사용해 동일한 작업을 수행하는 것을 확인할 수 있습니다.

[10:09] 스킬의 잘못된 사용법을 지적합니다. 서브 에이전트나 커스텀 슬래시 명령어로 해결할 수 있는 일회성 작업에는 스킬을 사용하지 말아야 한다고 조언합니다.

[10:31] 엔지니어링 관점에서 도구의 복잡성 증가에 대한 우려를 표현합니다. 같은 작업을 수행하는 여러 방법이 생기면서 혼란이 가중되고 있지만, 클로드 코드의 스킬 기능은 여전히 가치 있는 추가라고 평가합니다.

[11:04] Git work tree를 만드는 세 가지 방법을 소개하며, 기본적으로는 프롬프트로 생성하는 것을 권장하지만 병렬화가 필요한 경우 서브 에이전트를 사용할 수 있다고 설명합니다.

[11:24] 커스텀 슬래시 명령에서 서브 에이전트로 넘어가는 분기점을 설명하며, 기존 명령을 서브 에이전트에 넣어 병렬화를 구현하는 방법을 제시합니다.

모든 에이전트 코딩은 컨텍스트·모델·프롬프트·툴 네 가지로 구성됨을 설명하며, 이를 기반으로 기능 설계와 확장이 이루어져야 함을 강조한다.

[11:50] 합성 가능성 체인의 개념을 소개하며, 프롬프트가 모든 기능의 기본 단위라는 점을 강조합니다. 프롬프트를 관리하지 못하면 실패할 것이라고 경고합니다.

[12:34] 에이전트 코딩의 핵심 4요소(컨텍스트, 모델, 프롬프트, 도구)를 설명하며, 이것들을 마스터하는 것이 성공의 열쇠라고 강조합니다.

Git 워크트리 생성만 필요하면 프롬프트(슬래시 커맨드)로 충분하지만, 다수 트리 관리·병합·삭제 등 복합 작업에는 스킬을 도입해야 함을 예시로 제시한다.

[13:05] 처음 시작할 때는 복잡한 스킬이나 서브 에이전트보다는 단순한 프롬프트부터 시작하라고 조언하며, 모든 것이 결국 '토큰 인, 토큰 아웃'으로 귀결된다고 설명합니다.

[13:31] 언제 프롬프트에서 스킬로 넘어가야 하는지에 대한 중요한 질문을 제기하며, 단순한 git work tree 생성은 프롬프트로도 충분하지만 관리까지 고려하면 다를 수 있다고 암시합니다.

[13:48] git 워크 트리 관리의 복잡성에 대해 설명하며, 여러 트리를 동시에 관리하려면 단순한 프롬프트가 아닌 전용 스킬이 필요하다고 강조합니다.

[14:09] 스킬의 정의와 목적을 설명하며, 재사용 가능한 파일 시스템 기반 리소스로서 도메인별 전문 지식을 워크플로우에 통합하는 역할을 한다고 설명합니다.

[14:36] 실제 예시를 통해 스킬의 작동 방식을 보여주며, 새 인스턴스를 부팅하여 워크 트리 매니저 스킬을 시연합니다.

[15:00] 스킬에 대한 올바른 사고방식을 설명하며, 특정 문제 세트에 대한 전용 매니저 역할을 하는 반복 솔루션이라고 정의합니다.

[15:26] 일회성 작업과 반복 관리 작업의 차이를 구분하며, 복잡한 관리가 필요한 경우 수동 프롬프팅 대신 전용 스킬 구축의 필요성을 강조합니다.

[15:42] 실제 스킬 실행 예시를 보여주며, git 워크 트리 관리 명령(빨간 트리 제거, 보라색 트리 생성, 트리 나열)을 통해 스킬의 실용성을 시연합니다.

[16:19] 에이전트가 작업을 처리하는 동안 높은 수준에서 각종 기능들의 정의와 사용 시점에 대해 설명할 예정임을 언급하며, 에이전트 스킬의 용도를 소개합니다.

에이전트 스킬, MCP 서버, 서브 에이전트, 커스텀 슬래시 커맨드의 목적과 역할을 한눈에 정리해, 각 기능 간 중복 없이 명확히 사용하도록 안내한다.

[16:28] 에이전트 스킬은 에이전트가 반복되는 워크플로우에 자율적으로 적용하는 전문성으로, MCP 서버와는 완전히 별개의 개념입니다. MCP 서버는 외부 도구와 데이터 소스 연결을 담당합니다.

[16:47] 구성 레벨 관점에서 볼 때, 스킬이 최상위에 있고 MCP 서버, 하위 에이전트, 커스텀 슬래시 명령어 등을 포함할 수 있습니다. 순환적 구성이 가능하지만 명확한 계층 구조가 있습니다.

[17:35] 하위 에이전트는 주 에이전트의 컨텍스트 윈도우 밖에서 병렬로 작업할 수 있는 분리 가능한 전문 작업을 위해 사용됩니다. 컨텍스트를 잃어도 상관없는 작업에 적합합니다.

[18:02] 커스텀 슬래시 명령어는 재사용 가능한 프롬프트 단축어로, 가장 기본적이면서도 중요한 구성 요소입니다. 순수한 에이전트와 LLM에 가장 가까운 형태이기 때문입니다.

[18:27] 프롬프트 마스터는 필수입니다. 예외는 없습니다. 훌륭한 프롬프트 작성법을 피한다면 2025년, 2026년 그리고 그 이후에도 에이전틱 엔지니어로 성장할 수 없습니다. 프롬프트는 지식 작업의 기본 단위이며, 이를 이해하는 것이 성공의 열쇠입니다.

[19:03] 커스텀 슬래시 명령어는 대규모 프롬프트를 여러 에이전트와 함께 사용할 수 있게 해주는 기본적이면서도 매우 중요한 요소입니다.

훅으로 생명주기 이벤트 자동화, 플러그인으로 기능 확장 배포, 출력 스타일로 결과 요약·음성합성 포맷을 설정하는 방법을 설명한다.

[19:16] 훅스는 결정론적 자동화로 특정 라이프사이클 이벤트에서 명령을 실행하여, 항상 에이전트 판단에만 의존하지 않고 균형을 맞출 수 있게 해줍니다.

[19:30] 전술적 에이전트 코딩에서는 에이전트를 ADWs AI 개발자 워크플로로 밀어내어 기존 코드 세계와 에이전트의 새로운 세계를 결합해야 스케일링이 가능합니다.

[19:48] 플러그인은 다른 기능들과 겹치지 않는 간단한 기능으로, 작업 세트를 패키징하고 배포하여 클라우드 코드 확장을 공유하고 재사용할 수 있게 해줍니다.

[20:05] 아웃풋 스타일은 에이전트 작업 완료 후 텍스트 투 스피치 같은 다양한 방식으로 결과를 요약하고 출력하는 기능입니다.

[20:28] 스킬은 구성적 프롬프트를 사용하여 작업을 수행하며, 이러한 기능들을 적절히 구분해서 사용하는 것이 중요합니다.

[20:45] 기능들에 얽매이지 말고 자신에게 맞는 것을 사용하되, 슬래시 명령어에 대한 강한 편향을 가지고 여러 명령어를 구성할 때는 스킬을 고려해야 합니다.

프롬프트 기반 커스텀 커맨드를 우선으로, 필요 시 서브 에이전트·MCP 서버·스킬을 단계적으로 확장할 것을 권장하며, 스킬 장단점을 8/10 평가로 정리한다.

[21:08] 에이전트 스킬 기능에 대한 의견으로, 에이전트에 의해 호출되어 자율성을 높일 수 있다는 장점이 있지만 몇 가지 문제점도 존재합니다.

[21:34] 에이전트의 자율성을 극대화하여 더 많은 작업을 위임하는 것이 핵심이며, 컨텍스트 보호와 점진적 공개 기능이 MCP 서버와 차별화되는 장점이라고 설명합니다.

[21:48] 전용 격리된 파일 시스템 패턴을 통해 스킬들을 논리적으로 구성하고 그룹화할 수 있어, 에이전트 작업의 작성, 수정, 배포가 매우 용이해졌다고 평가합니다.

[22:06] 에이전트 호출 기능과 함께 가장 큰 장점이며, 에이전틱 접근법으로 에이전트가 자동으로 올바른 작업을 수행한다는 점을 높이 평가합니다.

[22:27] 하지만 완전하지 않은 부분이 있다고 지적하며, 하위 에이전트나 프롬프트를 중첩할 수 없고, 번들 내에 commands나 agents 디렉토리가 없다는 한계를 비판합니다.

[22:56] 모든 에이전트 기능 중 프롬프트가 가장 중요한 요소임을 강조하며, 클로드 코드 팀이 이 패턴을 만들면서 프롬프트 임베딩을 지원하지 않는 것에 대한 불만을 표현합니다.

[23:07] git 작업 트리 관리가 성공적으로 완료되었다는 시스템 메시지를 확인한 후, 다시 주요 논점으로 돌아가 가장 중요한 기본 요소를 스킬 내부에 전용 방식으로 넣을 수 없는 문제를 지적합니다.

[23:38] 신뢰성이 중요한 이슈라고 지적하며, 특히 여러 스킬을 연결할 때 에이전트가 올바른 스킬을 순서대로 사용할지에 대한 우려를 표현하고, 프로덕션 배포 가능성에 대한 의문을 제기합니다.

[24:20] 클로드 스킬의 신뢰성에 대한 불확실성과 더 많은 테스트가 필요하다는 점을 언급하며, 채널에서 스킬을 적극 활용할 계획을 밝힙니다.

[24:33] 스킬의 핵심 문제점을 지적합니다. 기존 프롬프트 엔지니어링과 커스텀 슬래시 명령어로도 같은 일을 할 수 있다는 점과, 스킬은 본질적으로 구획화된 프롬프트 엔지니어링에 불과하다고 분석합니다.

[24:51] 스킬의 실제 혁신성에 의문을 제기합니다. 새로운 것이 많지 않지만, 에이전트 중심의 전용적이고 구체적인 운영 방식을 제공한다는 점에서는 여전히 강력하다고 평가합니다.

[25:24] 개인적인 경험과 평가를 공유합니다. 반복 워크플로우용 스킬들을 구축했고, 이 릴리스의 중요성을 인정하며 10점 만점에 8점을 준다고 평가합니다.

[26:04] 스킬이 기존 기능을 대체하는 것이 아니라 더 높은 구성적 레벨에서 기능들을 묶어주는 역할이라고 명확히 설명합니다.

[26:20] 시청자들에게 제공할 리소스들을 소개합니다. 네 가지 스킬과 메타 스킬, 비디오 프로세서 등의 구체적인 예시를 들며, 스킬을 활용한 엔지니어링 발전 방법을 제안합니다.

[00:00] 지난 주 내내 에이전트 스킬 문제를

[00:01] 해결하기 위해 작업해왔습니다. 이제 여러분은

[00:05] 에이전트 스킬, 서브 에이전트, 커스텀

[00:08] 슬래시 명령어, 출력 스타일, 플러그인, 훅,

[00:12] 메모리 파일, 그리고 MCP 서버를 사용할 수 있습니다.

[00:16] 이 모든 것이 무엇을 위한 것일까요? 저는

[00:19] Claude Code가 2월에 처음 출시된 이후부터

[00:22] 계속 사용해왔습니다. 출시 이후로

[00:24] 지난 15년간 엔지니어로 일하면서

[00:27] 작성한 것보다 더 많은 코드를 생성했습니다. 이 도구는

[00:30] 엔지니어링을 바꿔놨지만, 한때

[00:32] 간단했던 이 도구가 한 해 동안

[00:35] 복잡해져서, 이제 단순화해보겠습니다. 스킬은

[00:38] 간단하지만, MCP,

[00:41] 서브 에이전트, 커스텀 슬래시 명령어와 너무 유사해서

[00:44] 언제 스킬을 사용해야 하는지 알기 어렵습니다.

[00:46] 스킬에 대한 올바른 사고방식이 있고

[00:47] 잘못된 방식도 있습니다. 저는

[00:49] 여러분의 엔지니어링에 이 기능이 무엇을 할 수 있는지

[00:51] 명확히 하기 위해 두 가지 모두 보여드리고 싶습니다.

[00:54] 스킬은 강력하지만

[00:56] 항상 스킬을 만들어야 하는 것은 아닙니다.

[00:59] 이 모든 강력한 Claude Code 기능들을

[01:01] 이해해 보겠습니다.

[01:08] 먼저 엔지니어링 문제를 해결하기 위해

[01:10] 스킬을 잘못 사용하는 방법을 살펴보겠습니다.

[01:12] 여기 왼쪽에는 스킬, 가운데에는 서브

[01:15] 에이전트, 오른쪽에는 커스텀 슬래시 명령어가

[01:18] 있습니다. 짠, 짠, 짠. 만약 여러분이

[01:21] 병렬 에이전트 코딩으로 동시에

[01:23] 여러 솔루션을 생성하고 있다면

[01:25] git work tree를 만들어본 적이 있을 겁니다.

[01:28] 여기서 질문입니다. 이 세 가지 방법 중

[01:31] 어떤 것이 git work tree를

[01:33] 만들거나 관리하는 올바른 방법일까요?

[01:36] 이에 답하기 위해서는 이러한 기능들이

[01:39] 실제로 어떻게 다른지 이해해야 합니다.

[01:42] 여기 상단에 우리가 나란히 비교할

[01:45] 네 가지 주요 기능이 있습니다. 그리고 왼쪽에는

[01:47] 기능들이 있습니다. 자, 가장 중요한

[01:49] 세 가지 기능부터 시작해보겠습니다.

[01:51] 스킬은 여기서 바로 돋보이는데

[01:54] 에이전트에 의해 트리거되기 때문입니다. 만약

[01:56] 에이전트에게 어떤 방향을 제시하면

[01:59] 올바른 스킬을 트리거할 것입니다.

[02:01] 서브 에이전트도 이런 면에서 매우 유사합니다.

[02:03] 여러분이 명시적으로 시작하는

[02:06] 슬래시 명령어와는 달리, 다음으로

[02:08] 컨텍스트 효율성이 있습니다.

[02:10] 이것은 스킬의 큰 장점입니다.

[02:12] 부팅 시 컨텍스트 윈도우를

[02:15] 폭발시키는 MCP 서버와 달리

[02:18] 스킬은 매우 컨텍스트 효율적입니다.

[02:20] 이것은 그들이 매우 중요하다고

[02:21] 자주 언급하는 것으로, 저도 정말

[02:23] 중요하다고 생각합니다. 그들이

[02:24] 자세히 다루는 것이 기쁩니다.

[02:26] 점진적 공개의 세 단계가 있습니다.

[02:29] 메타데이터 레벨, skill.md 파일의

[02:31] 실제 지시사항, 그리고

[02:34] 에이전트가 필요할 때 스킬에서

[02:36] 가져오는 모든 리소스가 있습니다.

[02:38] 마지막으로 컨텍스트 지속성입니다.

[02:40] 여기서 유일한 패자는 서브 에이전트입니다.

[02:42] 하지만 물론 이것이 서브 에이전트를

[02:44] 훌륭하게 만드는 요소입니다. 서브 에이전트는

[02:47] 컨텍스트 윈도우를 격리하고 보호합니다.

[02:49] 공유 가능성은 그리 중요하지 않습니다.

[02:50] git을 사용할 수 있고, 플러그인을 사용할 수 있고

[02:52] 이것들을 공유할 수 있습니다.

[02:53] >> 레드 트리 워크 트리가 포트

[02:55] 4020과 5193에서 라이브로 실행 중입니다. 병렬

[02:58] 개발 준비 완료.

[02:58] >> 좋네요. 우리 트리 중 하나가

[03:00] 나왔습니다. 서브 에이전트는 병렬화를 위한다면

[03:02] 큰 우승자입니다

[03:04] 워크플로를 구축하는 거죠.

[03:05] Dan, 포트 4010에서 옐로우 트리 워크 트리를 성공적으로

[03:07] 생성하고 시작했습니다. 현재 실행 중입니다.

[03:08] 좋습니다. 이제 레드 트리, 블루 트리,

[03:11] 옐로우 트리까지 모두 준비됐네요. 환상적입니다.

[03:13] 전문화 기능이 스킬에만 고유한 것이라고

[03:15] 생각할 수 있지만, 그렇지 않습니다.

[03:17] 이 기능들 중 어떤 것이든 전문화할 수 있습니다.

[03:19] 물론 이 모든 것을 원하는 방식으로 공유할 수도 있고요.

[03:22] 중요한 것은 모듈성입니다.

[03:24] 이것이 스킬을 진정으로 차별화하는 요소죠.

[03:25] 스킬은 MCP 서버와 마찬가지로 전용 솔루션을

[03:29] 제공한다는 점에서 유사합니다.

[03:32] 사실 MCP 서비스보다도 더 모듈화되어 있습니다.

[03:34] 스킬은 전용 디렉토리 구조를

[03:36] 가지고 있기 때문이죠.

[03:38] 이 '워크트리 생성 스킬'을 보면,

[03:41] 가장 중요한 점은

[03:43] 반복 가능한 솔루션을 구축하기 위한

[03:45] 전용 구조가 있다는 것입니다.

[03:46] 우리 에이전트가 이를 호출할 수 있도록 말이죠.

[03:48] 이것이 스킬의 주요 이점입니다.

[03:51] 따라서 여기서 모듈성이 정말 중요합니다.

[03:53] 모듈성이 매우 높거든요.

[03:55] 서브 에이전트나 슬래시 명령과는 달리

[03:57] 이런 기능을 직접 구현해야 했던

[03:59] 이전 영상들에서 보여드린 것처럼요.

[04:01] 마지막 단계에서는 더 흥미로워집니다.

[04:03] 구성에 대해 생각하기 시작하는 지점이거든요.

[04:05] 여기서 많은 혼란이 생겨납니다.

[04:07] 스킬, MCP 서버, 서브 에이전트,

[04:09] 슬래시 명령에 대해 이야기할 때 말이죠.

[04:12] 특히 스킬과 슬래시 명령은

[04:13] 매우 구성하기 쉽습니다.

[04:16] 사실 이 모든 항목들을 서로

[04:18] 순환적으로 구성할 수 있습니다.

[04:21] 서브 에이전트는 예외입니다.

[04:24] 서브 에이전트는 다른 서브 에이전트를 사용할 수 없거든요.

[04:26] 하지만 스킬의 경우, 스킬은 프롬프트를 사용할 수 있고,

[04:28] 다른 스킬도 사용할 수 있습니다.

[04:30] 스킬은 MCP 서버를 사용할 수 있고

[04:32] 물론 서브 에이전트도 사용할 수 있습니다.

[04:34] 이것이 기능별 분석입니다.

[04:37] 보시다시피 겹치는 부분이 많습니다.

[04:39] 이 점을 강조하는 게 중요합니다.

[04:41] 새로운 것은 접근 방식입니다.

[04:43] 전용 모듈형 디렉토리 구조와

[04:46] 효율적인 컨텍스트를 얻게 되죠.

[04:48] 서브 에이전트에서도 있었던 기능이지만,

[04:51] 이것들은 우리 에이전트에 의해 트리거됩니다.

[04:52] 이것이 MCP, 서브 에이전트,

[04:54] 슬래시 명령 대신 스킬을 사용해야 하는

[04:57] 구별되는 패턴입니다.

[04:59] 바로 명확하지 않다는 것도 알고 있습니다.

[05:02] 그래서 이 네 가지 기능을 언제 사용해야 하는지에 대한

[05:04] 구체적인 사용 사례들을 살펴보겠습니다.

[05:07] 스킬은 진정으로 자동 동작을 위한 것입니다.

[05:10] MCP는 외부 통합을 위해 만들어졌고,

[05:13] 서브 에이전트는 병렬화도 가능한

[05:15] 격리된 워크플로를 위한 것입니다.

[05:18] 그리고 슬래시 명령은 수동 트리거입니다.

[05:21] 필요할 때 배포할 수 있는

[05:23] 수동 컴퓨팅 단위죠.

[05:25] 여기서 큰 경쟁은 스킬과

[05:27] 슬래시 명령 사이에서 벌어집니다.

[05:29] 구체적으로 말하면, 이것들은 사용자 정의 슬래시 명령입니다.

[05:32] 자, 몇 가지 사용 사례를 살펴보겠습니다.

[05:35] PDF에서 텍스트와 데이터를

[05:37] 자동으로 추출하는 경우,

[05:39] 이 네 가지 중 어디에 속한다고 생각하시나요?

[05:42] 이 과정을 진행하면서 좋은 추측을 해보시고

[05:44] 댓글로 대략 몇 개를 맞췄는지

[05:46] 그리고 제 생각과 일치하는지 알려주세요.

[05:50] 이 사용 사례들을 어디에 분류할지

[05:52] 결정해보겠습니다. 좋습니다,

[05:53] 자동으로, 맞죠? 그 핵심 키워드가

[05:55] 바로 '자동(automatic)'입니다. 만약 항상

[05:57] 이것이 실행되길 원한다면,

[05:59] 스킬로 만드는 것이 좋습니다. PDF에서

[06:02] 텍스트와 데이터를 추출하고 싶다면,

[06:04] 이것은 스킬입니다. 그런데 Jira에 연결하고 싶다면?

[06:08] 이는 외부 소스이므로

[06:10] 당연히 MCP 서버가 필요합니다.

[06:12] 좋습니다. 다음은 뭘까요?

[06:13] 계속 분석해봅시다. 포괄적인 보안 감사를

[06:15] 실행하고 싶다면? 이 경우는

[06:17] 까다롭습니다. 정말 까다로운데,

[06:19] 확장 가능해야 하고

[06:21] 컨텍스트 윈도우에 실제로 필요하지 않으며

[06:24] 자동으로 실행되길 원하지 않기 때문입니다.

[06:25] 특정 시점에 직접 시작하는

[06:27] 작업으로 만들고 싶을 거예요.

[06:29] 그래서 이는 서브 에이전트로 만드는 것이 좋겠습니다.

[06:31] 그럼 일반적인 커밋 메시지 생성은

[06:34] 어떨까요? 여기서는 간단한

[06:36] 단일 단계 작업이 있습니다.

[06:38] 이런 경우의 까다로운 점은

[06:40] 스킬로도 쉽게 만들 수 있고,

[06:42] 슬래시 커맨드로도 만들 수 있고,

[06:43] 서브 에이전트로도 만들 수 있다는 것입니다.

[06:45] 하지만 어느 것이 가장 좋을까요? 저는 이것을

[06:48] 간단한 슬래시 커맨드로 만드는 것이 최선이라고 생각합니다.

[06:50] 그럼 데이터베이스 쿼리는 어떨까요?

[06:52] 이는 전형적인 사례입니다. 당연히

[06:54] MCP 서버가 필요합니다. 최소한

[06:56] MCP 서버로 시작하는 것이 좋습니다.

[06:58] 구성 가능성에 대해서는 잠시 후에

[06:59] 이야기하겠습니다. 실패한 테스트를

[07:01] 수정하고 디버깅하면서 이를 대규모로

[07:03] 진행하고 싶다면? 당연히 이것을

[07:06] 서브 에이전트 안에 넣고 싶을 거예요.

[07:08] 확장할 수 있고, 그냥 작업을

[07:09] 완료하면 됩니다. 어떤 에러가 있는지는

[07:12] 상관없어요. 그냥 수정해서

[07:13] 대규모로 처리하면 됩니다. 좋습니다.

[07:16] 스타일 가이드 위반을 감지하고 싶다면?

[07:17] 이는 흥미로운 사례입니다. 특정 동작이나

[07:20] 반복적인 동작을 인코딩하고 싶을 때는

[07:22] 전용 스킬로 만드는 것이 좋다고 생각합니다.

[07:25] 좋습니다. API에서 실시간 날씨 데이터를

[07:27] 가져오는 것은 뻔한 사례죠. MCP입니다.

[07:30] 이는 서드파티 서비스와

[07:32] 통합하는 것이니까요.

[07:33] 여기 멋진 사례가 있습니다.

[07:35] 컴포넌트를 만들고 싶다면? 어떤 UI

[07:37] 프레임워크를 사용하든 삽입하세요.

[07:39] 더 이상 아무도 신경 쓰지 않고

[07:41] 중요하지도 않습니다. 이는 간단한

[07:43] 일회성 작업으로 커스텀 슬래시 커맨드로

[07:45] 인코딩하고 싶을 거예요.

[07:47] 좋습니다. 환상적입니다. 여기 핵심

[07:50] 키워드가 있습니다. '병렬(parallel)'이라는 단어를 보면

[07:52] 항상 서브 에이전트를 떠올려야 합니다.

[07:55] 다른 것들은 병렬 호출을 지원하지 않거든요.

[07:57] 서브 에이전트만 가능합니다.

[07:58] 그래서 병렬 키워드를 보고

[08:00] 뭔가를 병렬화하고

[08:01] 컨텍스트 윈도우를 격리하고 싶을 때마다

[08:04] 말이죠. 그리고 나중에 그 컨텍스트를

[08:05] 잃게 되는 것을 감안해야 합니다.

[08:07] 실제로 잃게 될 테니까요.

[08:09] 그냥 서브 에이전트에 넣으면 됩니다.

[08:11] 이는 서브 에이전트용입니다. 여기 적절한

[08:14] 기능과 함께 몇 가지 사용 사례가 있습니다.

[08:17] 다음에 설정해야 한다고 생각합니다. MCP가

[08:20] 외부 통합에 관한 것이라는 것은 분명하고

[08:22] 여러 서비스를 번들로 묶어서

[08:25] 에이전트에 특정 기능으로 노출하고 싶다면

[08:26] MCP를 사용하는 게 분명히 맞습니다.

[08:29] 격리된 컨텍스트 윈도우를 원하고

[08:31] 컨텍스트를 잃어도 괜찮으며

[08:33] 병렬 처리를 원한다면

[08:35] 서브 에이전트를 사용하는 게 분명합니다.

[08:38] 더 혼란스러운 건

[08:40] 스킬 대 슬래시 명령어입니다.

[08:42] 스킬과 MCP는 매우 구분됩니다.

[08:46] 스킬은 물론 MCP 서버를 사용할 수 있습니다.

[08:48] 모든 것을 스킬로 구성할 수 있지만

[08:51] 슬래시 명령어로도 구성할 수 있습니다.

[08:53] 그리고 여기서 흥미로워집니다.

[08:56] 이 기능 세트를 보면

[08:57] 슬래시 명령어와 스킬은

[08:59] 매우 유사합니다.

[09:01] 유일한 차이점은 모듈성과 누가 트리거하느냐입니다.

[09:04] 이건 정말 흥미롭습니다.

[09:07] 지금 많은 엔지니어들이

[09:09] 스킬에 올인하고 있습니다.

[09:10] 모든 슬래시 명령어를

[09:12] 스킬로 변환하고 있습니다.

[09:14] 그건 큰 실수라고 생각합니다.

[09:17] 저는 슬래시 명령어를 에이전트 코딩의

[09:20] AI 코딩의, 그리고 언어 모델의

[09:22] 기본 요소로 봅니다.

[09:24] 프롬프트를 제거할 때는

[09:26] 매우 신중해야 합니다.

[09:28] 제가 무슨 의미인지 정확히 보여드리겠습니다.

[09:30] 스킬을 구성 단위로 접근하는 방식을

[09:32] MCP/명령어나 서브 에이전트의 대체재가 아닌

[09:35] 것으로 보는 제 생각을 보여드리겠습니다.

[09:38] 이들은 모두 구분되기 때문입니다.

[09:39] 이 중 하나만 사용한다면

[09:41] 이 기능들을 제대로 사용하지 않는 것입니다.

[09:43] 클로드 코드를 제대로 사용하지 않는 것입니다.

[09:45] 워크 트리가 있으니

[09:46] 빠르게 확인해보겠습니다.

[09:48] 트리로 가보면

[09:50] 이 코드베이스의 세 가지 새로운 버전이

[09:53] 완전히 구축되어 있습니다.

[09:54] 환경 변수 파일도 있고

[09:56] 앱으로 가보면

[09:58] 클라이언트 서버가 보입니다. 모든 것이

[10:01] 여기 있습니다. 우리 에이전트는

[10:04] 프롬프트 서브 에이전트와 스킬을 사용해

[10:06] 똑같은 작업을 수행합니다.

[10:09] 이건 스킬을 잘못 생각하는 방식입니다.

[10:11] 서브 에이전트나 커스텀 슬래시 명령어로

[10:13] 일회성 작업을 할 수 있다면

[10:16] 스킬을 사용하지 마세요.

[10:17] 스킬은 그런 용도가 아닙니다.

[10:20] 스킬을 어떻게 생각해야 할까요?

[10:23] 우리가 시작한 세 가지 에이전트

[10:24] 작업 단위가 있습니다.

[10:26] 세 가지 다른 기능으로

[10:28] 같은 작업을 완료했습니다.

[10:29] 이제 여기서 까다로워집니다.

[10:31] 이 도구에 대한 혼란이 많은 부분입니다.

[10:33] 엔지니어링에서는

[10:35] 같은 일을 하는 여러 방법을 원하지 않습니다.

[10:38] 일을 끝내는 한 가지 전용 방법을 원합니다.

[10:40] 그래서 혼란스러운 겁니다.

[10:42] 클로드 코드는 점점 더

[10:44] 큰 도구가 되고 있습니다.

[10:47] 성공하는 것들은 성장하는 경향이 있고

[10:49] 어느 시점에서 독창성을 잃습니다.

[10:51] 그것을 구별되게 만든 것을 잃죠.

[10:53] 클로드 코드가 그런 상황은 아니라고 생각합니다.

[10:55] 이 기능이 마음에 듭니다.

[10:57] 생태계, 도구, 엔지니어에게

[11:00] 순 플러스라고 생각합니다.

[11:01] 스킬을 제대로 사용하는 방법은 뭘까요?

[11:04] git work tree를 만드는 방법이죠. 명확하게 말하면

[11:06] 세 가지 뚜렷한 방법으로 할 수 있어요. 결국엔

[11:09] 이 중 어느 것이든 만들 수 있다고 생각해요.

[11:11] 하지만 여기서 진짜 답은

[11:13] 아마 git work tree를 만드는 프롬프트를 원할 거예요.

[11:17] 무슨 일이 일어났는지 볼 수 있기를 원하죠.

[11:18] 그리고 이런 걸 많이 만들 필요가 없다면,

[11:21] 병렬화할 필요가 없어요, 맞죠?

[11:22] 하지만 만약 병렬화가 필요하다면,

[11:24] 서브 에이전트를 사용하면 돼요, 맞죠?

[11:26] 그게 완벽한, 그러니까

[11:28] 커스텀/명령에서 서브 에이전트로 넘어가는

[11:30] 분기점이에요. 병렬화가 필요하면

[11:32] 기존의 커스텀 슬래시 명령을 가져와서

[11:34] 서브 에이전트에 넣을 수 있어요.

[11:36] 실제로, 그게 바로 우리가

[11:39] 여기서 한 일이에요. 실제로

[11:40] 이 서브 에이전트 프롬프트를 자세히 보면

[11:43] 서브 에이전트가 슬래시 명령 도구로

[11:45] 프롬프트를 구성하게 하고 있어요.

[11:48] 우리 프롬프트를 호출하고 있죠. 그래서

[11:50] 합성 가능성의 체인으로

[11:52] 들어가기 시작하는 거예요, 맞죠?

[11:54] 기본 레벨 단위가 프롬프트인 곳에서,

[11:58] 즉 커스텀 슬래시 명령이요.

[12:00] 이런 기능들을 어떻게 합성하느냐가

[12:02] 매우 중요해요. 좋습니다.

[12:04] 그리고 우리 스킬에서 이걸 더 밀어붙일 수 있어요.

[12:06] 우리가 뭘 하는지 아세요? 지시사항이에요.

[12:08] 슬래시 명령 도구를 사용하세요.

[12:10] 좋아요, 여기서 우리는 모든 기존 기능들의

[12:14] 원시 형태로서 프롬프트를 보고 있어요.

[12:16] 저는 수년간 이걸 말해왔어요,

[12:17] 솔직히, 생성형 AI 혁명이

[12:19] 시작된 이후부터요. 프롬프트를

[12:22] 포기하지 마세요. 프롬프트는

[12:25] 지식 작업과 프로그래밍의

[12:27] 기본 단위예요. 프롬프트를

[12:29] 만들고 관리하는 방법을 모르면

[12:31] 질 거예요. 왜 그럴까요?

[12:34] 모든 것이 결국 네 가지로

[12:36] 귀결되기 때문이에요. 에이전트 코딩의

[12:38] 네 가지 요소가 있어요.

[12:41] 컨텍스트, 모델, 프롬프트, 그리고 도구예요.

[12:43] 이것들을 이해하고, 만들고

[12:46] 관리할 수 있다면 이길 거예요. 왜냐하면

[12:48] 모든 에이전트가 핵심 4요소이기 때문이고,

[12:51] 이런 에이전트 코딩 도구들이

[12:53] 만들 모든 기능들이 핵심 4요소를

[12:55] 직접 기반으로 만들어질 거예요.

[12:58] 이게 기초예요. 이게 기반이에요.

[12:59] 기본기를 마스터하면 합성 단위도,

[13:01] 기능도 마스터하고, 그러면

[13:03] 도구도 마스터할 거예요.

[13:05] 그래서 항상 커스텀 슬래시 명령으로

[13:08] 시작하는 게 그렇게 중요한 거예요.

[13:11] 처음 시작할 때는 항상

[13:12] 그냥 프롬프트를 만들라고 추천해요.

[13:15] 스킬을 만들지 마세요.

[13:17] 서브 에이전트도 만들지 마세요.

[13:19] MCP 서버도 만들지 마세요.

[13:21] 단순하게 유지하세요. 프롬프트를 만드세요.

[13:24] 모든 것은 결국 프롬프트예요.

[13:26] 토큰이 들어가고, 토큰이 나와요.

[13:28] 그래서 병렬화를 원한다면

[13:30] 서브 에이전트로 갈 수 있어요.

[13:31] 그럼 언제 스킬로 가느냐, 맞죠?

[13:34] 이게 중요한 질문이에요.

[13:36] git work tree를 만드는 데 있어서

[13:38] 언제 프롬프트에서 스킬로 넘어가느냐?

[13:40] 그냥 프롬프트를 쉽게 사용할 수 있어요, 맞죠?

[13:43] 하나의 프롬프트가 문제를 해결해줘요.

[13:45] 하지만 git work tree를 관리하는

[13:47] 문제를 해결하고 싶다면, 맞죠?

[13:48] 여기서 트리를 열면, 이제 세 개의 git

[13:50] 워크 트리를 관리하고, 읽고,

[13:53] 병합하고, 제거해야 하죠. 우리에게는

[13:56] 스킬이 필요합니다. 우리의 git

[13:59] 워크 트리를 관리하는 스킬이 필요해요.

[14:02] 여기서 하나의 프롬프트로는 부족합니다.

[14:04] 재사용 가능한 솔루션으로 확장하고 싶어요.

[14:07] 당연히 스킬이 필요하죠. 이것이 바로

[14:09] 스킬이 만들어진 이유입니다. 재사용 가능한

[14:13] 파일 시스템 기반 리소스가 도메인별

[14:15] 전문 지식을 워크플로우

[14:17] 맥락과 모범 사례로 전문가화시키는 거죠.

[14:21] 음, 대충 넘어갔네요.

[14:22] 제대로 읽지 않았지만,

[14:24] 요점은 알겠죠. 이것이 바로

[14:26] 스킬의 전부입니다. 스킬은

[14:28] 전용 솔루션을 제공합니다.

[14:30] 반복되는 문제를 에이전트 우선 방식으로

[14:33] 해결하는 체계적인 구조를 말이죠.

[14:36] 제가 정확히 무슨 말인지

[14:37] 보여드리겠습니다. 새 인스턴스를

[14:39] 부팅하고 여기 스킬로 가면,

[14:41] 축소해서 스킬을 보면,

[14:42] 워크 트리 매니저 스킬이 있습니다.

[14:45] 훨씬 더 구축되어 있죠.

[14:47] 리스트 스킬 같은 것을 할 수 있어요.

[14:49] 여기서 메타 스킬과 비디오

[14:51] 프로세서 스킬이 있는 걸 볼 수 있습니다.

[14:54] >> 댄, 클라우드 코드

[14:55] 환경에서 사용할 수 있는

[14:57] 네 가지 스킬을 나열했습니다.

[14:59] >> 이것이 스킬에 대한

[15:00] 올바른 사고방식입니다.

[15:01] 특정 문제 세트의 매니저인

[15:03] 스킬이 있습니다.

[15:06] 특정 문제에 대한 반복 솔루션이죠.

[15:09] 실제로 워크 트리를 만들기만 하면

[15:11] 되는 경우 슬래시 크리에이트하고

[15:14] 끝이죠. 브랜치를 주고,

[15:16] 브랜치를 고유하게 만들 추가

[15:18] 세부사항을 제공하고, 환경

[15:20] 변수를 설정하고, 적절한

[15:22] 클라이언트 서버 포트를 설정하고,

[15:24] 끝이죠. 일회성입니다. 하지만

[15:26] 관리가 필요하고, 방금 전

[15:27] 프롬프트들을 보셨죠? 여러

[15:29] 요소를 관리해야 한다면, 수동으로

[15:32] 프롬프팅하는 걸 멈추세요. 이런

[15:33] 사용자 정의 슬래시 명령어를 혼자

[15:35] 처리하는 걸 멈추고, 정말로

[15:37] 집중해서 스킬을 구축하세요.

[15:39] 실행해보죠. 실제로

[15:40] 스킬을 실행해보겠습니다. 트리를

[15:42] 다시 불러오고 이제 이것들을

[15:44] 관리해보죠. git 워크 트리 관리,

[15:47] 빨간 트리 제거, 보라색 트리 생성

[15:50] 오프셋 4로 포트를 오프셋하고

[15:54] 트리를 나열합니다. 이것이 스킬

[15:56] 세트입니다. 우리는 전용 스킬로

[15:58] git 워크 트리 관리 문제를

[16:01] 해결했습니다. 이것이 스킬의

[16:02] 핵심입니다. 실행하겠습니다.

[16:04] 에이전트가 이 작업을 시작할 것입니다.

[16:06] 여기서 중요한 포인트가 있습니다.

[16:07] 에이전트가 이것을 단계별로

[16:09] 처리하는 동안 몇 가지 정의를

[16:11] 살펴보겠습니다. 돌아왔을 때

[16:12] 빨간 트리가 제거되고 보라색

[16:14] 트리가 추가된 것을 볼 수 있어야 하고,

[16:17] 현재 트리들의 요약을 보고 싶습니다.

[16:19] 높은 수준에서 몇 가지

[16:20] 정의를 살펴보죠.

[16:22] 이 모든 기능들이 어디에 맞는지,

[16:24] 언제 각각을 사용하는지 말입니다.

[16:25] 에이전트 스킬은 사용자 정의를 패키지화할 때 사용합니다.

[16:28] 에이전트가 반복되는 워크플로우에

[16:30] 자율적으로 적용하는 전문성입니다.

[16:33] 매우 중요하고 구별되는 개념이죠. MCP

[16:35] 서버는 에이전트를 외부 도구와

[16:37] 데이터 소스에 연결하는 것입니다.

[16:40] 제가 보기에는 에이전트 스킬과

[16:42] MCP 서버 사이에는 겹치는 부분이

[16:45] 거의 없습니다. 완전히 별개입니다.

[16:47] 명확히 하자면, 저는

[16:49] 구성 레벨로 생각하는 걸 좋아합니다.

[16:50] 무엇이 무엇을 사용해야 하는지 말이죠.

[16:53] 스킬은 여러 MCP 서버를 가질 수 있습니다.

[16:55] 스킬은 여러 하위 에이전트를 가질 수 있습니다.

[16:57] 스킬은 여러 커스텀 슬래시 명령어를

[16:59] 가질 수 있습니다. 하지만 MCP 서버는

[17:02] 더 낮은 수준의 단위입니다.

[17:04] MCP 서버가 스킬을 사용하지는

[17:06] 않겠죠. 여기엔 명령 체계가 있습니다.

[17:09] 흥미롭게도 슬래시 명령어는

[17:11] 기본 단위이면서 동시에 구성 요소

[17:14] 역할을 하는 매우 원시적인 요소라고

[17:16] 생각합니다. 물론 커스텀

[17:17] 슬래시 명령어를 가져와서 스킬 세트를

[17:20] 실행할 수 있고, MCP 서버를 실행하고

[17:22] 하위 에이전트도 실행할 수 있습니다.

[17:24] 이런 것들이 어떻게 구성되는지

[17:26] 매우 흥미롭습니다. 여기서 많은

[17:28] 순환적 구성을 만들 수 있는데,

[17:30] 저는 확실히 스킬을 구성 계층의

[17:32] 최상위에 두겠습니다.

[17:34] 그럼 계속해보죠. 에이전트 스킬이

[17:35] 있고, MCP 서버가 있습니다.

[17:37] 외부 데이터 소스죠. 하위 에이전트도

[17:39] 있고, 하위 에이전트는 분리 가능한

[17:42] 전문 작업을 별도 컨텍스트로

[17:45] 위임하여 병렬로 작업할 수

[17:47] 있게 해줍니다. 하위 에이전트는

[17:49] 매우 명확합니다. 하위 에이전트를

[17:50] 언제 사용할지 안 할지는

[17:52] 매우 명확하다고 생각합니다.

[17:54] 주 에이전트의 컨텍스트 윈도우

[17:56] 밖에서 작업하고 싶고 위임할 수 있으며

[17:58] 끝에 컨텍스트를 잃어도

[18:00] 상관없을 때 사용합니다. 커스텀

[18:02] 슬래시 명령어도 있습니다.

[18:03] 이는 수동으로 호출하는

[18:05] 재사용 가능한 프롬프트 단축어입니다.

[18:07] 저는 커스텀 슬래시 명령어를

[18:09] 과소평가하고 있습니다. 하나만

[18:11] 선택해야 하고 나머지는

[18:12] 잊어도 된다면, 확실히 커스텀

[18:14] 슬래시 명령어 숙련도를

[18:17] 우선시해야 합니다. 왜냐하면

[18:19] 이것이 순수한 에이전트 플러스

[18:21] LLM에 가장 가까운 구성 단위이기

[18:24] 때문입니다. 사용자 프롬프트를

[18:27] 전달하는 것이죠. 프롬프트를

[18:29] 마스터해야 합니다. 예외는 없습니다.

[18:31] 훌륭한 프롬프트 작성법과

[18:34] 반복 가능한 방식으로 구축하는 법을

[18:37] 이해하지 않고 피한다면,

[18:39] 에이전틱 엔지니어로 성장할 수 없고,

[18:41] 2025년, 2026년 그리고 그 이후에도

[18:43] 엔지니어로 성장할 수 없습니다.

[18:46] 프롬프트는 지식 작업의

[18:47] 기본 단위입니다. 이에 대한

[18:49] 예외는 없습니다. 이를 이해한다면

[18:52] 성공할 것입니다. 이것은

[18:53] 반복해서 나오는 내용이고,

[18:55] Tactical Agentic Coding과 Agentic

[18:58] Horizon 내부의 큰 주제입니다.

[19:00] 더 나아가 정말로 마스터하고

[19:01] 싶다면 설명란에 링크를

[19:03] 대규모 프롬프트를 여러 에이전트와 함께

[19:06] 사용하는 거죠. 좋습니다, 이게 커스텀

[19:07] 슬래시 명령어입니다. 이것이 기본 요소죠.

[19:09] 좋습니다, 이건 정말 매우

[19:12] 중요합니다. 그럼 다음은 뭘까요?

[19:13] 자, 계속해서 이 모든

[19:14] 기능들을 살펴보죠. 물론 훅스가 있습니다.

[19:16] 훅스는 정말 훌륭해요. 이건 결정론적

[19:18] 자동화로 특정 라이프사이클

[19:20] 이벤트에서 명령을 실행합니다. 맞죠? 여기서

[19:22] 우리는 결정론적 요소를 추가하는 거예요

[19:23] 항상 에이전트의 판단에만 의존하기보다는요.

[19:26] 그래서 이런 것들의 균형을 맞춰야 해요.

[19:28] 맞죠? 그래서 다시 말하지만 전술적

[19:30] 에이전트 코딩에서 우리는 에이전트 밖으로

[19:32] 밀어내서 ADWs AI 개발자 워크플로로

[19:35] 가져가는데, 여기서는 기존 코드의

[19:37] 세계와 에이전트의 새로운 세계를

[19:39] 결합합니다. 정말로 스케일을 확장하려면

[19:41] 둘 다 필요해요. 그리고 훅스는 우리가

[19:44] 결정론적 자동화에 접근할 수 있게 해줍니다. 좋습니다, 그럼

[19:46] 여기서 또 뭐가 있을까요? 플러그인이 있네요.

[19:48] 이건 간단해요. 다른 기능들과

[19:50] 겹치는 부분이 전혀 없어요.

[19:52] 플러그인은 이런 작업 세트들을

[19:54] 패키징하고 배포할 수 있게 해줍니다. 이건

[19:57] 그렇게 흥미로운 건 아니에요. 그냥

[19:58] 클라우드 코드 확장을 공유하고 재사용하는

[20:01] 방법일 뿐이죠. 좋습니다, 마지막으로 여기에

[20:02] 아웃풋 스타일이 있습니다. 그리고 여기서

[20:05] 보셨듯이, 맞죠? 저는 아웃풋

[20:06] 스타일을 24/7 사용하고 있어요. 우리 에이전트가

[20:08] 이 작업을 마치면, 실제로

[20:10] 텍스트 투 스피치 아웃풋 스타일을 사용해서

[20:12] 작업을 요약하게 될 거예요. 여기 아래로 스크롤하면

[20:15] 제가 가지고 있는 여러 아웃풋

[20:16] 스타일들을 보실 수 있어요. 이전에 채널에서

[20:18] 이것에 대해 얘기했었죠. 저는

[20:20] observable tools diff 텍스트 투 스피치

[20:22] 요약을 사용하고 있어요. 그리고 여기서 보시면 우리는

[20:24] 마지막 단계인 work trees 나열

[20:26] 프롬프트에 있습니다. 그리고 여기서 매우 중요한 건

[20:28] 제 스킬이 구성적 프롬프트를

[20:31] 사용한다는 거예요, 맞죠? 작업을 수행하기 위해

[20:33] 프롬프트를 사용하고 있어요. 정말 훌륭한

[20:35] 내용이네요. 이게 아웃풋 스타일입니다.

[20:36] 이것이 이런 기능들을 구분하고

[20:38] 언제 각각을 사용해야 하는지

[20:40] 도움이 되길 바라요. 결국엔

[20:41] 여러분에게 맞는 걸 사용하시면 되요, 맞죠?

[20:45] 이런 기능들이, 이런

[20:46] 클라우드 코드의 유행어 같은 기능들이

[20:49] 여러분의 작업 배포를 막도록

[20:51] 두지 마세요. 알겠죠? 여러분에게 맞는 걸 사용하세요.

[20:53] 하지만 저는 슬래시 명령어에 대해

[20:55] 강한 편향을 가지라고 말하고 싶어요. 그리고

[20:57] 여러 슬래시 명령어들을 구성하는 것에 대해

[20:59] 생각할 때, 서브 에이전트나 MCPS를

[21:01] 스킬로 만드는 것을 고려해보세요.

[21:03] 알겠죠? 하지만 여러분의 스킬은 다시 말하지만

[21:05] 여러 슬래시 명령어들을 가져야 해요. 이제 이것이 저를

[21:08] 이 기능에 대한 제 의견으로

[21:11] 이끕니다. 마음에 들지만, 이 기능에는

[21:13] 문제점들도 있어요.

[21:16] 그래서 빠르게 이 장단점

[21:17] 리스트를 살펴보겠습니다. 이게

[21:19] 에이전트 스킬이에요. 그리고 여러분과 함께

[21:21] 이것을 살펴보겠습니다. 제가 좋아하는 것과

[21:22] 싫어하는 것을 말씀드릴게요. 그리고 제 장단점에

[21:23] 동의하시는지 아래 댓글로

[21:25] 알려주세요. 저는 이게 에이전트에 의해

[21:27] 호출된다는 점이 좋아요, 맞죠? 우리는 자율성에

[21:30] 기대고 싶어해요, 맞죠? 자율성을

[21:32] 높이는 거죠

[21:34] 가능한 최대치로 설정하는 거죠. 좋습니다. 이렇게 하는 겁니다.

[21:36] 에이전트에게 더 많은 작업을 위임합니다.

[21:38] 컨텍스트 보호 기능이 마음에 들어요.

[21:40] 점진적 컨텍스트 창 적용이죠.

[21:42] 점진적 공개라고 부르는 기능입니다.

[21:44] MCP 서버와는 다르게 말이죠.

[21:46] MCP는 컨텍스트 창을 완전히 태워버리거든요.

[21:48] 이건 전용 격리된

[21:50] 파일 시스템 패턴이라는 점이 좋습니다.

[21:54] 이제 스킬들을 논리적으로 구성하고 그룹화할 수 있어요.

[21:57] 작성, 업데이트, 생성, 수정이

[21:59] 정말 쉬워지고

[22:02] 에이전트가 할 수 있는 작업을 배포하는 것도 간단해집니다.

[22:04] 정말 훌륭합니다.

[22:06] 솔직히 이건 에이전트 호출 기능 다음으로

[22:08] 에이전트 스킬의 가장 큰 장점이에요.

[22:11] 다른 요소들을 구성할 수 있고

[22:13] 다른 기능들도 마찬가지입니다.

[22:14] 그리고 마지막으로

[22:16] 정말 중요한 점은

[22:17] 이것이 에이전틱 접근법이라는 것입니다.

[22:19] 이게 바로 당신이 보고 싶어하는 것이죠.

[22:21] 에이전트가 그냥 올바른 작업을 수행합니다.

[22:24] 좋은 점들이 많지만

[22:25] 마음에 들지 않는 부분도 있어요.

[22:27] 완전하지 않다는 점입니다.

[22:29] 무슨 말이냐면, 하위 에이전트를 중첩할 수 없고

[22:32] 프롬프트도 중첩할 수 없습니다. 왜 안 되는 걸까요?

[22:35] 왜 이런 기능이 없는 걸까요?

[22:37] 번들 내부에서 말이에요.

[22:39] 스킬용 파일 시스템 VM 대신

[22:42] /commands 디렉토리는 어디 있나요?

[22:44] agents 디렉토리는 어디 있나요?

[22:47] 클로드 코드 팀이 왜

[22:49] 끝까지 가지 않았을까요?

[22:50] 재사용 가능한 솔루션을 위한 번들을 만든다면

[22:53] 왜 프롬프트를 포함시킬 수 없는 건가요?

[22:56] 모든 에이전트 중에서

[22:58] 가장 중요한 기능은 바로 프롬프트입니다.

[23:01] 누구든지 이 기능 출시로

[23:03] 혼동하지 말길 바랍니다.

[23:04] 프롬프트가 가장 중요한 것입니다.

[23:07] 댄, git 작업 트리를 성공적으로 관리했습니다.

[23:09] 좋아요.

[23:10] red 트리를 제거하고

[23:11] 포트 4040과 13에 purple 트리를 생성했습니다.

[23:13] 그리고 실행 중인 세 개의 작업 트리를 모두 나열했습니다.

[23:18] 작업이 완료되었지만

[23:20] 제 이야기를 마저 해보겠습니다.

[23:22] 왜 가장 중요한 기본 요소를

[23:24] 전용 방식으로 스킬 내부에 넣을 수 없는 걸까요?

[23:27] 물론 제가 직접 엔지니어링할 수는 있지만

[23:30] 그들이 이 패턴을 만들고 있는데

[23:32] 끝까지 가면 되는 거 아닌가요?

[23:34] 이게 제 가장 큰 불만이고

[23:36] 이 기능에 대한 유일한 요청사항입니다.

[23:38] 신뢰성이 흥미로운

[23:40] 이슈가 될 것 같습니다.

[23:42] 에이전트가 실제로

[23:44] 연결될 때 올바른 스킬을 사용할까요?

[23:47] 개별적으로는 덜 걱정되지만

[23:49] 이것들을 쌓아 올릴 때는

[23:51] 이게 그들이 언급한

[23:52] 주요 기능 중 하나인데

[23:55] 기능을 구성하고 스킬을 결합하는 것이

[23:58] 얼마나 신뢰할 수 있을까요?

[24:00] 실제로 프로덕션에 배포할 수 있을까요?

[24:02] 실제로 다섯 개의 스킬을 연결해서

[24:04] 연속으로 호출되기를

[24:05] 기대할 수 있을까요?

[24:08] 아니면 다시 프롬프트를 사용해야 할까요?

[24:10] 슬래시xyz를 실행한 다음

[24:13] 슬래시 zyx를 호출하면 올바른 순서로 실행될 거라고 보장할 수 있거든요.

[24:18] 그래서 저는... 아직 명확하지 않네요

[24:20] 아직 스킬이 얼마나 신뢰할 수 있는지는 확실하지 않습니다.

[24:23] 물론 더 많은 테스트가 필요하죠. 구독 버튼을

[24:24] 눌러주시고, 좋아요와 댓글도

[24:25] 남겨주세요. 그래야 유튜브 알고리즘이

[24:27] 여러분이 관심 있다는 걸 알 수 있거든요.

[24:28] 우리는 스킬을 적극적으로 활용해서

[24:30] 이 채널에서 정말 무엇을 할 수 있는지

[24:32] 보여드릴 예정입니다. 제가 가진

[24:33] 마지막 이슈는 이 모든 걸 프롬프트

[24:36] 엔지니어링과 커스텀 슬래시 명령어, 그리고

[24:39] 슬래시 명령어 도구로도 할 수 있다는 점입니다.

[24:41] 여기서 문제는 스킬이 본질적으로

[24:45] 구획화된 프롬프트 엔지니어링과 모듈성이라는 것입니다.

[24:47] 여기서 진짜 질문은

[24:49] 실제 혁신이 무엇인가 하는 거죠.

[24:51] 맞죠? 여기서 정말 새로운 게 뭘까요?

[24:53] 제 생각엔 그리 많지 않은 것 같습니다.

[24:56] 동시에, 에이전트를 에이전트 중심의

[24:59] 방식으로 운영할 수 있는 전용이고

[25:02] 구체적인 방법을 갖는 것은 여전히 강력합니다.

[25:04] 네, 매우 흥미로운 부분이죠.

[25:05] 이건 꽤 간단한 기능입니다.

[25:07] 일종의 얇은 의견 주도적 파일

[25:10] 구조인데, 이전에도 할 수 있었던 거거든요.

[25:12] 그래서 잘 모르겠어요. 저도

[25:13] 아직 이걸 이해하려고 노력 중입니다.

[25:15] 여기엔 실제로 새로운 게 없어요.

[25:16] 이건 클로드 코드 팀이

[25:18] 반복적인 솔루션들을 에이전트 중심의

[25:21] 방식으로 쉽게 번들링할 수 있게 만든 것 같아요.

[25:24] 이게 제가 정리한 장단점 목록입니다.

[25:26] 저는 반복적인 워크플로우를 위한

[25:29] 여러 스킬을 구축했습니다. 지금은

[25:31] 사용자 디렉토리에 구체적인 스킬들을

[25:34] 잔뜩 쌓아올리고 있어요.

[25:36] 이 릴리스가 중요하다는 건 분명합니다.

[25:38] 여기 상단에 이런 큰 배너도 있고요.

[25:40] 클로드 코드 팀, 앤트로픽 엔지니어들이

[25:42] 정말 이 기능을 밀고 있는데

[25:43] 충분한 이유가 있다고 생각합니다.

[25:45] 이건 강력하고 전용 플랫폼 전체에서

[25:47] 엔지니어들과 일반 사용자들이

[25:49] 반복적인 에이전트 중심 솔루션을

[25:52] 만들 수 있게 해주는 전용 방법입니다.

[25:55] 맞죠? 우리는 도메인별 전문성을

[25:57] 에이전트 중심의 방식으로 만들고 있어요.

[26:00] 그래서 저는 이 기능이 마음에 들고 사용하고 있습니다.

[26:02] 10점 만점에 8점을 주겠어요.

[26:04] 분명한 건 이게 기존 기능이나

[26:07] 능력을 대체하지 않는다는 것입니다.

[26:09] 이건 MCP나 명령어, 서브 에이전트를

[26:11] 대체하는 게 아닙니다. 이건

[26:13] 이런 기능들을 묶어서 특정 문제를

[26:15] 반복적인 방식으로 해결할 수 있게 해주는

[26:18] 더 높은 수준의 구성적 레벨입니다.

[26:20] 이 코드베이스는 여러분이

[26:22] 사용할 수 있도록 제공됩니다.

[26:24] 설명란에 링크가 있어요.

[26:25] 이 네 가지 스킬 모두에

[26:27] 접근할 수 있습니다. 그리고 메타 스킬도

[26:29] 준비했어요. 이 스킬로 다른 스킬들을

[26:31] 만들 수 있습니다. 이건 정말정말정말

[26:34] 강력한 에이전틱 추상화로

[26:36] 언제든 사용할 수 있어요. 무언가를 만드는

[26:38] 걸 만드세요. 이건 전술적 에이전틱

[26:40] 코딩의 중요한 주제입니다. 다시 한번,

[26:41] 설명란에 링크가 있어요. 그다음엔

[26:43] 실제 전용 스크립트가 있는

[26:45] 비디오 프로세서가 있는데, 이 스킬은

[26:48] 다양한 비디오 파일 처리와 관리,

[26:50] 전사본 만들기 등을 전문으로 합니다.

[26:51] 맞죠? 그래서 스킬을 어떻게 활용해서

[26:53] 엔지니어링을 발전시킬 수 있는지

[26:55] 몇 가지 아이디어를 드리고 싶었습니다.

[26:56] 이걸 가져다가 스킬을 이해하고 자신만의 것으로

[26:59] 만들어보세요. 끝까지 보셨다면

[27:00] 꼭 좋아요와 댓글로 알고리즘에

[27:03] 관심 있다는 걸 알려주세요.

[27:04] 다음 주 월요일에 여러분의 에이전트

[27:07] 코딩을 위한 큰 아이디어로 만나뵙겠습니다.

[27:10] 집중하시고 계속 만들어보세요.