Subscribe
Share
Share
Embed
AI 에이전트용 스킬, 플러그인, 다단계 워크플로우를 직접 만들 때 무엇을 고려해야 하는지 Anthropic, OpenAI, MCP 공식 문서와 엔지니어링 글을 바탕으로 정리합니다. 스킬과 지침 파일·도구·훅의 선택, description과 트리거, 컨텍스트 예산, 스크립트와 검증 게이트, 평가, 플러그인 배포와 버전, 서드파티 보안과 프롬프트 인젝션, 비용까지 다룹니다.
AI 에이전트용 스킬, 플러그인, 다단계 워크플로우를 직접 만들 때 무엇을 고려해야 하는지 Anthropic, OpenAI, MCP 공식 문서와 엔지니어링 글을 바탕으로 정리합니다. 스킬과 지침 파일·도구·훅의 선택, description과 트리거, 컨텍스트 예산, 스크립트와 검증 게이트, 평가, 플러그인 배포와 버전, 서드파티 보안과 프롬프트 인젝션, 비용까지 다룹니다.
참고 자료
이 에피소드의 음성은 TTS로 합성되었습니다.
kalee 가 공부하고자 하는 내용들을 두서없이 업로드하는 팟캐스트
진행자: 오늘은 나만의 skill, plugin, 그리고 workflow를 직접 만들 때 꼭 짚어야 할 포인트들을 얘기해 보려고 해요.
진행자: 요즘 에이전트 도구를 쓰다 보면 같은 지시를 계속 복사해 붙이게 되잖아요. 그러다 보면 아예 내 것으로 만들고 싶어지고요.
전문가: 맞아요. 그런데 막상 만들면 생각처럼 안 켜지거나, 켜져도 컨텍스트만 잡아먹거나, 남이 만든 걸 받았다가 보안 구멍이 생기기도 해요.
진행자: 그래서 오늘은 특정 제품 사용법보다는 Anthropic, OpenAI, 그리고 MCP 쪽 공식 문서와 엔지니어링 글을 중심으로, 도구를 가리지 않고 통하는 설계 원칙을 정리해 볼게요.
전문가: 네. 출처는 전부 공개 문서고, 설명란에 링크를 다 달아 둘게요.
진행자: 먼저 용어부터 맞추죠. skill이 정확히 뭐예요?
전문가: Anthropic 문서 정의로는 지침, 메타데이터, 그리고 선택적으로 스크립트나 템플릿 같은 리소스를 묶은 모듈이에요. 관련 있는 요청이 오면 에이전트가 알아서 꺼내 씁니다.
전문가: 형태는 단순해요. 폴더 하나에 SKILL.md라는 파일이 필수로 있고, scripts, references, assets 폴더는 선택이에요.
전문가: 이 형식은 Anthropic이 처음 만들어서 오픈 표준으로 공개했고, 지금은 여러 에이전트 제품이 채택했어요.
전문가: OpenAI도 ChatGPT와 Codex의 skill을 같은 구조로 설명하면서 이 agent skills 사양을 기반으로 한다고 링크하고 있고요.
진행자: 그럼 그냥 잘 쓴 prompt랑은 뭐가 달라요?
전문가: Anthropic은 prompt를 대화 단위의 일회성 지시로 보고, skill은 필요할 때만 로드되니까 대화마다 같은 안내를 반복할 필요가 없다고 설명해요.
전문가: 비유로는 새로 온 팀원을 위한 온보딩 가이드를 만드는 것과 비슷하다고 해요.
진행자: plugin은요?
전문가: plugin은 배포 단위예요. Claude Code 문서 기준으로 skill, subagent, hook, MCP 서버 같은 구성 요소를 한 단위로 설치하고 로드하는 디렉터리입니다.
진행자: MCP는 정확히 뭐의 약자예요?
전문가: Model Context Protocol, 모델 컨텍스트 프로토콜이에요. 에이전트를 외부 시스템의 도구와 데이터에 연결하는 표준 규약이라고 보시면 돼요.
전문가: OpenAI 문서 표현으로는 MCP 서버가 도구를 정의하고, 인증을 강제하고, 구조화된 데이터를 돌려주고, 외부 시스템에 실제 동작을 수행해요.
진행자: 그리고 workflow는 여러 단계를 이어 붙인 흐름이겠죠?
전문가: 네. Anthropic은 여기서 중요한 구분을 해요. workflow는 LLM과 도구가 미리 정의된 코드 경로로 움직이는 시스템이고, agent는 LLM이 스스로 과정과 도구 사용을 정하는 시스템이에요.
진행자: 좋아요. 그럼 첫 번째 포인트. 뭘 만들어야 할지부터 헷갈려요. 항상 켜 두는 지침 파일도 있잖아요.
전문가: 맞아요. Codex는 작업을 시작하기 전에 항상 AGENTS.md를 읽고, 전역 파일부터 저장소 루트, 하위 폴더 순으로 이어 붙여요. 합친 크기가 기본 32KiB에 이르면 더 붙이지 않고요.
전문가: Claude Code에도 CLAUDE.md가 같은 역할을 하는데, 문서가 기준을 꽤 명확히 줘요. 같은 지시나 체크리스트를 채팅에 반복해서 붙이고 있거나, CLAUDE.md의 한 부분이 사실이 아니라 절차로 커졌다면 skill로 빼라는 거예요.
전문가: 이유는 간단해요. CLAUDE.md는 늘 로드되지만 skill 본문은 쓸 때만 로드되거든요.
진행자: 그러니까 항상 지켜야 하는 사실이나 규칙은 지침 파일에, 가끔 필요한 절차는 skill에.
전문가: 네, 문서들을 종합하면 그렇게 나눌 수 있어요. 여기에 외부 시스템을 만져야 하면 MCP 같은 도구가 들어가고요.
전문가: Anthropic은 skill이 외부 도구가 얽힌 복잡한 workflow를 가르쳐서 MCP 서버를 보완하는 방향을 탐색하겠다고 밝혔어요. 도구는 손발이고 skill은 그걸 쓰는 요령인 셈이죠.
진행자: hook은 어디에 들어가요?
전문가: hook은 반드시 일어나야 하는 일에 써요. Claude Code 문서에 따르면 hook은 사용자가 정의한 셸 명령을 정해진 시점에 실행해서, LLM이 실행하기로 고르길 기대하는 대신 항상 일어나게 만들어요.
진행자: subagent도 비슷한 맥락이죠?
전문가: subagent는 컨텍스트를 나누는 도구예요. 자기만의 컨텍스트 창에서 별도 시스템 프롬프트와 도구 권한으로 일하고 요약만 돌려줘요. 검색 결과나 로그가 메인 대화를 넘치게 할 때 쓰라는 게 문서의 권고예요.
진행자: 두 번째 포인트로 가 볼게요. 만들었는데 안 켜지는 문제.
전문가: 이건 거의 description 문제예요. 필수 필드는 name과 description 두 개고, name은 최대 64자에 소문자, 숫자, 하이픈만, description은 최대 1024자예요.
전문가: 에이전트는 시작할 때 모든 skill의 name과 description만 미리 읽고, 요청이 거기에 맞으면 그때 본문을 읽어요. 그래서 description이 트리거의 짐을 전부 집니다.
전문가: Anthropic 문서는 description에 무엇을 하는지와 언제 쓰는지를 둘 다 넣으라고 하고, Claude가 이걸로 많게는 백 개가 넘는 skill 중에서 고른다고 해요.
전문가: 피해야 할 예로 든 게 문서를 도와준다, 데이터를 처리한다 같은 문장이에요.
진행자: 문장 스타일 같은 것도 정해져 있어요?
전문가: 여기서 출처끼리 살짝 갈려요. Anthropic은 description이 시스템 프롬프트에 들어가니까 3인칭으로 쓰라고 하고요.
전문가: agentskills.io 쪽 가이드는 이 skill을 언제 쓰라는 식의 명령형을 권해요. 에이전트가 행동할지 결정하는 중이니까 언제 행동할지 말해 주라는 거죠.
전문가: 형식은 다르지만 언제 쓰는지를 분명히 하라는 핵심은 같아요. 쓰는 도구에서 평가해 보고 고르면 됩니다.
진행자: 그 밖에 트리거 관련해서 알아둘 게 있나요?
전문가: agentskills.io 가이드에 재미있는 지적이 있어요. 에이전트는 혼자 처리하기 어려운 작업일 때 skill을 찾는 경향이 있어서, 이 PDF 읽어 줘 같은 단순한 요청은 description이 완벽해도 안 켜질 수 있대요.
전문가: 그리고 너무 좁게 쓰면 켜져야 할 때 안 켜지고, 너무 넓게 쓰면 엉뚱할 때 켜진다고 경고해요.
전문가: Codex 문서는 skill이 많아지면 목록에서 description을 먼저 줄인다고 해요. 그래서 핵심 용도와 트리거 단어를 앞쪽에 두라고 권하고요.
진행자: 반대로 저절로 켜지면 곤란한 skill도 있잖아요. 배포 같은 거요.
전문가: 그래서 호출 주체를 막는 스위치가 있어요. Claude Code는 disable-model-invocation을 켜면 Claude가 스스로 그 skill을 못 불러요. 문서 예시가 커밋이나 배포처럼 부작용이 있는 workflow예요.
전문가: 문서 표현 그대로 옮기면, 코드가 준비돼 보인다고 Claude가 배포를 결정하길 원하지는 않을 거라는 거죠.
전문가: Codex도 비슷하게 allow_implicit_invocation을 false로 두면 암묵적으로는 안 켜지고 명시적으로 부를 때만 동작해요.
진행자: 세 번째 포인트, 컨텍스트 예산이요. 여기서 progressive disclosure란 말이 계속 나오던데요.
전문가: 우리말로는 점진적 공개예요. 세 단계로 나눠 로드한다는 뜻이에요. 메타데이터는 늘 로드되고, SKILL.md 본문은 트리거될 때, 나머지 파일과 스크립트는 정말 필요할 때 읽어요.
전문가: 사양이 권하는 숫자도 있어요. 메타데이터는 대략 100토큰, 본문은 5000토큰 미만, SKILL.md는 500줄 미만이에요.
전문가: Anthropic 문서는 컨텍스트 창을 공공재라고 불러요. skill은 시스템 프롬프트, 대화 기록, 다른 skill의 메타데이터와 같은 공간을 나눠 쓰니까요.
전문가: 그래서 Claude는 이미 똑똑하다는 가정에서 출발해서 모델이 모르는 맥락만 넣으라고 해요. 이 문단이 토큰값을 하는지 스스로 물어보라는 거죠.
진행자: 그럼 긴 참고 자료는 어디에 둬요?
전문가: 별도 파일로 빼고 SKILL.md에서 링크해요. 이때 참조는 한 단계 깊이까지만 두라고 해요. 파일이 파일을 또 가리키면 모델이 앞부분만 훑고 넘어가서 정보가 빠질 수 있대요.
전문가: 그리고 100줄이 넘는 참고 파일은 맨 위에 목차를 두라고 권해요. 일부만 미리 봐도 전체 범위를 알 수 있게요.
진행자: 여러 개를 깔면 메타데이터만으로도 꽤 차지 않아요?
전문가: 그래서 제품들이 상한을 둬요. Codex는 처음 보여 주는 skill 목록에 기본으로 컨텍스트 창의 최대 2퍼센트를 쓰고, 넘치면 description을 줄이거나 일부 skill을 목록에서 빼요.
전문가: Claude Code는 사용자가 만든 subagent의 description 합이 15,000토큰을 넘으면 시작할 때 경고를 띄워요.
전문가: plugin도 마찬가지예요. 활성화된 plugin은 쓰는 세션만이 아니라 모든 세션의 일부가 되니까, 설치하는 것만으로 비용이 생겨요.
진행자: 네 번째 포인트로 넘어가죠. 범위를 어떻게 잡느냐.
전문가: Codex 문서의 첫 권고가 각 skill은 한 가지 일에 집중하라는 거예요. 이름도 Anthropic은 helper, utils처럼 모호한 이름을 피하라고 하고요.
전문가: 한 가지 일을 하면 description도 좁고 선명해지고, 평가하기도 쉬워지거든요. 이건 제 해석이지만 단일 책임 원칙이 skill에도 그대로 통하는 셈이에요.
진행자: 그 한 가지 일을 지시문으로 쓸지 스크립트로 쓸지는 어떻게 정해요?
전문가: Anthropic은 작업이 얼마나 깨지기 쉬운지에 맞춰 자유도를 정하라고 해요. 비유가 좋아요. 양옆이 낭떠러지인 좁은 다리라면 정확한 가드레일을 주고, 위험 없는 넓은 들판이라면 방향만 주라는 거예요.
전문가: 코드 리뷰처럼 여러 방법이 다 맞을 땐 텍스트 지침, 데이터베이스 마이그레이션처럼 순서가 정확해야 하면 정해진 스크립트를 그대로 돌리게 하라는 거죠.
전문가: 엔지니어링 블로그에는 이런 예가 나와요. 리스트 정렬을 토큰 생성으로 하는 건 정렬 알고리즘을 돌리는 것보다 훨씬 비싸고, 많은 작업은 코드만 줄 수 있는 결정적 신뢰성이 필요하다고요.
전문가: 게다가 스크립트를 실행하면 코드 자체는 컨텍스트에 안 들어가고 출력만 토큰을 써요.
진행자: OpenAI 쪽 관점도 같나요?
전문가: 방향은 같은데 강조점이 조금 달라요. Codex 문서는 결정적 동작이나 외부 도구가 필요할 때가 아니면 스크립트보다 지침을 선호하라고 해요. 그리고 입력과 출력을 명시한 명령형 단계로 쓰라고 하고요.
전문가: 제 정리로는 기본은 지침, 결정성이 필요한 부분만 스크립트라는 데서 두 쪽이 만나요.
진행자: 스크립트를 넣을 때 주의할 점은요?
전문가: Anthropic 문서는 오류를 모델에게 떠넘기지 말고 스크립트에서 직접 처리하라고 해요. 그리고 타임아웃 같은 설정값에 근거 없는 마법 숫자를 두지 말고 이유를 적으라고 하고요.
전문가: 또 이 스크립트를 실행하라는 건지, 참고로 읽으라는 건지를 지침에 분명히 적으라고 해요.
진행자: 다섯 번째, 검증이요. 결과가 맞는지는 어떻게 보장해요?
전문가: 가장 기본 패턴은 피드백 루프예요. 검증기를 돌리고, 오류를 고치고, 다시 돌리는 거죠. Anthropic은 이 패턴이 출력 품질을 크게 높인다고 해요.
전문가: 조금 더 무거운 작업에는 plan-validate-execute 패턴을 권해요. 바로 실행하지 말고 계획을 구조화된 파일로 만들고, 스크립트로 그 계획을 검증한 다음 실행하고, 마지막에 결과를 다시 확인하는 거예요.
전문가: 일괄 작업, 파괴적 변경, 위험도가 높은 작업에 쓰라고 하고요. 검증 스크립트의 오류 메시지는 어떤 필드가 없고 어떤 필드가 가능한지까지 구체적으로 알려 주라고 해요.
전문가: workflow 쪽에서도 같은 얘기를 해요. 프롬프트를 사슬처럼 이을 때 중간 단계마다 프로그램으로 검사하는 게이트를 넣을 수 있다고요.
전문가: agent라면 매 단계에서 도구 결과나 코드 실행 결과 같은 환경의 실제 결과를 받아서 진행 상황을 판단해야 한다고 강조하고요.
진행자: 그럼 skill 자체가 잘 만들어졌는지는 어떻게 평가해요?
전문가: Anthropic 문서의 권고가 꽤 단호해요. 문서를 많이 쓰기 전에 평가부터 만들라는 거예요.
전문가: 순서는 이래요. 먼저 skill 없이 대표 작업을 돌려 보고 실패를 기록해요. 그 빈틈을 겨냥한 시나리오 세 개로 평가를 만들고, skill 없는 기준선을 재요. 그다음 평가를 통과할 만큼만 최소한의 지침을 쓰고 반복하는 거죠.
전문가: 그리고 현재는 이런 평가를 돌리는 내장 방법이 없어서 직접 만들어야 한다고 문서에 적혀 있어요.
진행자: 트리거가 잘 되는지도 따로 재야 할 것 같은데요.
전문가: 네, agentskills.io 가이드가 구체적인 방법을 줘요. 켜져야 할 질문 8개에서 10개, 켜지면 안 될 질문 8개에서 10개, 합쳐서 20개 정도로 시작하래요.
전문가: 여기서 제일 가치 있는 음성 예시는 near miss예요. 키워드는 겹치는데 실제로는 다른 일이 필요한 질문이요. 날씨 묻는 질문처럼 뻔히 무관한 건 아무것도 시험하지 못한다고 해요.
전문가: 모델은 같은 입력에도 매번 다르게 반응하니까 질문마다 세 번쯤 돌려서 트리거 비율을 재고, 0.5를 기준으로 보라고 하고요.
진행자: description을 계속 고치다 보면 그 질문들에만 맞춰질 것 같은데요.
전문가: 그게 과적합이죠. 그래서 질문을 학습용 60퍼센트, 검증용 40퍼센트 정도로 나누고, 실패한 질문의 키워드를 그대로 description에 넣지 말라고 해요. 최종 버전은 검증 세트 통과율로 고르고, 보통 다섯 번 반복이면 충분하대요.
전문가: 출력 품질도 같은 원리예요. 두세 개 테스트 케이스로 시작해서 각각을 skill이 있을 때와 없을 때 두 번 돌려 비교하고, 매번 깨끗한 컨텍스트에서 시작하라고 해요.
전문가: Anthropic은 Claude를 두 역할로 나눠 쓰는 방법도 소개해요. 한 인스턴스와 함께 skill을 다듬고, skill만 로드한 새 인스턴스로 실제 작업을 시켜 보면서 어디서 막히는지 관찰하는 거예요.
전문가: 그리고 쓸 모든 모델로 테스트하라고 해요. 큰 모델에 딱 맞는 지침이 작은 모델에는 부족할 수 있다고요.
진행자: 여섯 번째로 workflow 자체 설계로 가 보죠. 여러 단계를 엮을 때 출발점은요?
전문가: Anthropic의 첫 권고는 가장 단순한 해법을 찾고 필요할 때만 복잡도를 올리라는 거예요. 경우에 따라선 agent 시스템을 아예 안 만드는 게 답일 수도 있다고 해요.
전문가: agent 시스템은 지연 시간과 비용을 더 나은 성능과 맞바꾼다는 점을 의식하라고 하고요.
전문가: 복잡도가 정말 필요하다면 잘 정의된 작업에는 예측 가능성과 일관성이 있는 workflow, 유연성과 모델 주도 결정이 필요한 곳에는 agent라는 게 그들의 정리예요.
진행자: 대표적인 workflow 패턴도 정리해 주시죠.
전문가: 다섯 가지예요. 단계를 사슬처럼 잇는 prompt chaining, 입력을 분류해서 보내는 routing, 나눠서 동시에 돌리는 parallelization, 중앙에서 쪼개 맡기는 orchestrator-workers, 생성하고 평가하며 고치는 evaluator-optimizer예요.
전문가: routing의 예로 쉬운 질문은 작고 싼 모델, 어려운 질문은 더 강한 모델로 보내서 비용과 성능을 맞추는 걸 들어요.
전문가: orchestrator-workers는 하위 작업을 미리 정할 수 없을 때 쓴대요. 여러 파일을 고쳐야 하는 코딩처럼 입력에 따라 할 일이 달라지는 경우요.
전문가: evaluator-optimizer는 평가 기준이 명확하고 반복해서 고칠수록 측정 가능한 가치가 생길 때 맞다고 하고요.
진행자: subagent는 이 패턴 중 어디에 들어가요?
전문가: orchestrator-workers의 worker에 가깝다고 볼 수 있어요. 다만 Claude Code 문서가 짚는 실용적 장점은 따로 있어요. 컨텍스트를 지키고, 도구를 제한해서 제약을 강제하고, 더 싼 모델로 보내서 비용을 통제하는 거예요.
전문가: 주의할 점은 subagent 요청도 메인 대화와 같은 사용량 한도에 잡힌다는 거예요. 공짜 병렬은 아니에요.
진행자: 프레임워크를 쓰는 건 어때요?
전문가: Anthropic은 프레임워크가 추상화 층을 더해서 실제 prompt와 응답을 가리고 디버깅을 어렵게 할 수 있다고 경고해요. LLM API를 직접 쓰는 것부터 시작하고, 프레임워크를 쓴다면 내부 동작을 이해하라고 하죠.
전문가: agent 설계의 세 원칙으로는 단순성, 계획 단계를 드러내는 투명성, 그리고 도구 문서와 테스트로 다듬은 에이전트와 컴퓨터 사이의 인터페이스를 꼽아요.
진행자: 도구 얘기가 나왔으니 MCP 서버를 직접 만들 때 포인트도 짚어 주세요.
전문가: Anthropic 블로그는 도구를 결정적인 시스템과 비결정적인 agent 사이의 새로운 계약이라고 표현해요.
전문가: 첫째, 도구가 많다고 좋은 게 아니래요. 모든 연락처를 돌려주는 도구보다 연락처를 검색하는 도구를 만들라는 예를 들어요. 에이전트가 전부 읽느라 컨텍스트를 낭비하니까요.
전문가: 둘째, 높은 신호의 정보만 돌려주고, 긴 응답에는 페이지 나누기, 필터, 잘라내기를 합리적인 기본값으로 두래요. 오류 메시지도 불투명한 코드 대신 무엇을 고치면 되는지 알려 주고요.
전문가: 셋째, 파라미터 이름은 user 대신 user_id처럼 모호하지 않게, 설명은 새로 온 동료에게 설명하듯 쓰라고 해요.
전문가: Anthropic이 SWE-bench용 agent를 만들 때 전체 prompt보다 도구 최적화에 더 많은 시간을 썼대요. 모델이 상대 경로에서 자꾸 실수하자 절대 경로만 받도록 도구를 바꿨더니 실수가 사라졌다고 하고요. 이걸 실수하기 어렵게 만드는 포카요케라고 불러요.
진행자: 일곱 번째, plugin으로 묶어서 배포할 때요.
전문가: 먼저 꼭 plugin이 필요한지부터 물어야 해요. Claude Code 문서는 skill, subagent, hook, MCP 서버 모두 plugin 없이 동작한다고 하고, 여러 개를 한 단위로 묶어 팀에 주거나 버전을 매겨 릴리스할 때 plugin을 쓰라고 해요.
전문가: OpenAI도 비슷하게 정리해요. skill은 재사용 workflow를 쓰는 형식이고, 저장소 하나 안에서 쓸 거면 skill 폴더로 충분하고, 널리 배포하거나 여러 skill을 묶거나 커넥터를 같이 실을 때 plugin으로 패키징하라고요.
전문가: ChatGPT와 Codex는 하나의 공통 plugin 디렉터리를 같이 쓴다고 하고요.
진행자: marketplace라는 말도 자주 보이던데요.
전문가: Claude Code 기준으로 marketplace는 plugin 목록과 각 plugin을 어디서 받을지 적은 카탈로그 파일이에요. 호스팅되는 스토어가 아니라는 점을 문서가 굳이 강조해요.
진행자: 버전 관리에서 흔한 실수가 있을까요?
전문가: 문서가 직접 짚는 함정이 있어요. plugin.json에 version을 적어 두고 올리지 않은 채 커밋만 푸시하면 사용자는 계속 옛 버전에 머물러요.
전문가: 그래서 릴리스마다 version을 올리든지, git 기반 marketplace라면 version을 빼고 커밋 해시를 버전으로 쓰게 하라고 해요.
전문가: 또 하나, 커스텀 skill은 제품 표면끼리 동기화되지 않아요. claude.ai, API, Claude Code에 각각 따로 올려야 하고, 실행 환경도 달라요. API에서는 네트워크가 없고 런타임에 패키지를 설치할 수 없어요.
진행자: 여덟 번째, 보안이요. 남이 만든 skill이나 plugin을 받을 때가 제일 걱정인데요.
전문가: Anthropic 문서는 skill을 직접 만들었거나 Anthropic에서 받은 것처럼 신뢰할 수 있는 출처에서만 쓰라고 해요. 악성 skill은 명시된 목적과 다르게 도구를 호출하거나 코드를 실행하게 만들 수 있으니까요.
전문가: 감사할 땐 SKILL.md만 보지 말고 스크립트, 이미지, 리소스까지 번들된 파일 전부를 보래요. 예상 밖 네트워크 호출이나 목적과 안 맞는 파일 접근을 찾으라고요.
전문가: 외부 URL에서 데이터를 가져오는 skill은 특히 위험하다고 해요. 가져온 내용에 악성 지시가 들어 있을 수 있고, 믿을 만한 skill도 외부 의존성이 바뀌면 오염될 수 있대요. 그래서 소프트웨어 설치처럼 다루라고요.
진행자: plugin은 더 위험하겠네요. 코드까지 돌리니까.
전문가: 네. Claude Code 문서는 설치한 plugin이 사용자 권한으로 임의의 코드를 실행할 수 있다고 분명히 적어요.
전문가: 중요한 건 권한 규칙과 샌드박스가 다루는 범위예요. 그건 Claude의 도구 호출에 적용되고, plugin이 스스로 돌리는 hook이나 MCP 서버 프로세스는 샌드박스 밖에서 사용자 전체 권한으로 돌아요.
전문가: 자동 업데이트가 켜져 있으면 내가 검토한 파일이 나중에 바뀔 수도 있고요. 그래서 커뮤니티 카탈로그는 대부분 항목을 특정 커밋으로 고정하고, 아카이브를 해시로 고정하면 내려받은 파일 해시가 다를 때 설치를 거부해요.
전문가: 설치 전에 실제로 읽어야 할 파일도 짚어 줘요. 각 hook이 실행하는 명령, MCP 서버의 명령이나 주소, 그리고 bin 폴더의 모든 파일이요.
전문가: marketplace 이름은 카탈로그를 누가 내는지 알려 줄 뿐 각 plugin이 무슨 일을 하는지는 알려 주지 않는다는 문장도 기억할 만해요.
전문가: OpenAI도 plugin hook은 실행 전에 검토하고 신뢰하라고 해요. 또 ChatGPT 계정으로 로그인을 연결해도 plugin에 데이터 접근이 자동으로 허락되지 않고, 권한 승인은 별도 단계라고 설명해요.
진행자: prompt injection 얘기도 빼놓을 수 없겠죠.
전문가: Simon Willison이 정리한 치명적 삼중주라는 개념이 있어요. 개인 데이터 접근, 신뢰할 수 없는 콘텐츠 노출, 외부로 통신하는 능력. 이 셋이 한 agent에 모이면 공격자가 데이터를 빼낼 수 있다는 거예요.
전문가: 그의 설명으로는 LLM은 지시가 어디서 왔는지로 중요도를 믿을 만하게 구분하지 못해요. 그래서 prompt에 따르지 말라고 적어도 매번 막힌다고 확신할 수 없고요.
전문가: 95퍼센트를 막는다는 가드레일 주장에 대해선 웹 보안에서 95퍼센트는 낙제점이라고 꼬집어요. 여러 도구를 섞어 쓰는 사용자에게 안전한 방법은 이 조합을 아예 피하는 것뿐이라는 게 그의 주장이에요.
진행자: 만드는 사람 입장에서는 어떻게 반영하면 될까요?
전문가: 제 해석을 붙이면, skill이나 plugin을 설계할 때 이 셋 중 무엇을 주는지 스스로 체크하는 거예요. 웹을 읽는 skill에 비밀 데이터 접근과 외부 전송까지 같이 주고 있다면 쪼개야 한다는 신호죠.
전문가: MCP 사양도 기준을 줘요. 도구 호출을 거부할 수 있는 사람이 루프에 있어야 한다고 권고하고, 신뢰할 수 있는 서버가 아니면 도구 동작을 설명하는 annotation도 신뢰하지 말라고 요구해요.
전문가: MCP 보안 모범 사례 문서는 로컬 MCP 서버를 원클릭으로 설정할 때 실행될 정확한 명령을 잘림 없이 보여 주고 명시적 승인을 받으라고 요구해요. 설정 안에 악성 시작 명령이 숨을 수 있으니까요.
전문가: 권한 범위도 처음부터 넓게 받지 말래요. 넓은 권한 토큰이 탈취되면 피해 반경이 커지니까, 최소 범위로 시작해서 필요할 때 단계적으로 올리라고요.
전문가: 서버가 자기에게 발급되지 않은 토큰을 받아 그대로 다른 API로 넘기는 token passthrough도 금지된 패턴이라고 못 박고 있어요.
진행자: 아홉 번째로 비용 얘기를 잠깐 하죠.
전문가: 비용은 앞서 나온 포인트에 다 녹아 있어요. 설치만 해도 메타데이터와 plugin 구성 요소가 매 세션 자리를 차지하고, agent 시스템은 지연과 비용을 성능과 맞바꾸죠.
전문가: 그래서 평가할 때 품질만 보지 말고 토큰과 시간도 같이 기록하라고 agentskills.io가 권해요. 품질은 크게 올리지만 토큰을 세 배 쓰는 skill은 더 좋고 더 싼 skill과는 다른 선택이라는 거죠.
전문가: 도구 평가에서도 Anthropic은 정확도 말고도 도구 호출 수, 토큰 소비, 도구 오류를 같이 모으라고 해요.
진행자: 마지막으로 유지보수 팁도 있을까요?
전문가: Anthropic 문서는 시간이 지나면 틀려질 정보를 넣지 말고, 용어를 일관되게 쓰라고 해요. 그리고 실제 사용에서 예상 밖 경로가 보이는지 관찰하면서 반복하라고 하고요.
전문가: 작업하다가 잘 된 접근과 자주 하는 실수를 모델에게 skill에 담게 하라는 팁도 있어요. 쓰면서 자라는 문서라고 생각하면 돼요.
진행자: 정리해 볼게요. 첫째, 무엇을 만들지부터 고르세요. 늘 지킬 규칙은 지침 파일, 가끔 필요한 절차는 skill, 외부 시스템은 MCP 같은 도구, 반드시 일어나야 하는 일은 hook이에요.
진행자: 둘째, description과 컨텍스트 예산이 성패를 가릅니다. 언제 쓰는지를 앞쪽에 분명히 쓰고, 본문은 짧게, 긴 자료는 한 단계 아래 파일로 빼세요.
진행자: 셋째, 결정성이 필요한 곳은 스크립트와 검증 게이트로 고정하고, 평가는 skill보다 먼저, 기준선과 함께 만드세요.
진행자: 넷째, 남이 만든 skill과 plugin은 소프트웨어 설치처럼 다루고, 개인 데이터와 외부 콘텐츠와 외부 통신이 한곳에 모이지 않게 설계하세요.
전문가: 하나 덧붙이면, 가장 단순한 것부터 시작하라는 말이 모든 포인트를 관통해요. skill 하나, 도구 몇 개로 충분하다면 거기서 멈추는 게 좋은 설계예요.
진행자: 오늘 언급한 공식 문서와 글은 전부 설명란에 링크해 뒀어요. 들어 주셔서 감사합니다.
전문가: 감사합니다.