클로드 디자인 스킬 50개, 무엇을 설치하고 무엇을 참고할까

먼저 세 종류를 구분해야 합니다

Skill은 `SKILL.md`에 작업 순서와 선택 조건을 적은 묶음입니다. MCP는 Claude가 브라우저나 외부 서비스에 연결할 때 쓰는 규격으로, 로그인 정보와 파일 접근 같은 추가 권한이 생길 수 있습니다. 설계 아이디어는 설치 없이 팀 문서나 체크리스트로 적용할 수 있습니다.

아래 50개는 원래 목록을 찾기 위한 이름입니다. 각 이름의 실제 유형과 추천 단계는 글 아래 근거표가 기준입니다. "아이디어 참고" 항목은 설치 추천이 아닙니다.

실제 Skill: SKILL.md와 배포 저장소가 확인됨
외부 연결 도구: MCP·CLI·API 키처럼 별도 권한이 필요함
설계 아이디어: 설치하지 않고 문서·체크리스트로 활용

판단 순서: 유형 확인 → 운영 주체 확인 → 요구 권한 확인 → 한 항목만 시험

처음 읽을 때는 50개를 다 보지 않아도 됩니다

목록은 작업 결과에 따라 다섯 구역으로 나뉩니다. 웹 화면을 만들면 화면 디자인부터, 포스터나 영상이면 이미지·영상부터, 대화형 서비스를 설계하면 AI 제품 만들기부터 읽으면 됩니다. 프롬프트 설계와 신뢰·안전은 결과물을 만든 뒤 품질과 권한을 다듬는 두 번째 선택지입니다.

각 항목은 아래 근거표의 추천 단계와 함께 봅니다. 우선 추천은 공식 운영 주체나 충분한 공개 근거가 확인된 후보입니다. 검토 후 사용은 설치 파일·외부 API·브라우저 권한을 먼저 읽어야 합니다. 아이디어 참고는 설치 대상으로 권하지 않습니다.

새 웹 서비스를 만드는 1인 개발자

기능은 있지만 화면 구조가 정리되지 않은 1인 개발자라면 `frontend-design` 하나로 첫 화면을 만들고 `impeccable`로 위계와 간격을 다듬는 조합을 권합니다. 실제 모바일·데스크톱 동작 확인에는 `playwright-mcp`를 검토할 수 있지만, 로그인 프로필과 다운로드 권한을 분리할 수 있을 때만 연결합니다.

`designer-skills` 묶음 전체와 `theme-factory`, `brandkit`을 처음부터 함께 설치하는 선택은 제외합니다. 역할이 겹쳐 어느 지침이 결과를 바꿨는지 알기 어렵기 때문입니다. 한 화면을 완성한 뒤 브랜드 규칙이 반복해서 흔들릴 때만 테마 역할을 추가하는 편이 낫습니다.

정기적으로 카드뉴스를 만드는 콘텐츠 담당자

텍스트와 도표가 중심인 카드뉴스에는 공식 `canvas-design`을 우선 추천합니다. 수치를 설명해야 한다면 `data-visualization`의 지침을 참고하되, 근거 자료와 축·단위 검증은 별도로 해야 합니다. 짧은 영상까지 필요할 때만 Remotion 공식 제작 스킬을 별도 프로젝트에서 검토합니다.

API 키와 설치 스크립트를 요구하는 `nano-banana`, `banana-claude`, 여러 MCP를 한꺼번에 넣는 `remotion-superpowers`는 첫 선택에서 제외합니다. 이미지 생성이 반드시 필요하고 비밀 관리와 출력 권리를 확인할 수 있을 때 한 도구만 제한적으로 추가합니다.

고객 대화형 AI를 운영하는 제품팀

제품팀에는 화면을 예쁘게 만드는 스킬보다 `human-in-the-loop`, `escalation-design`, `output-quality-rubrics`의 아이디어가 먼저입니다. 중요한 실행을 사람이 승인하고, 상담 실패를 정해진 담당자에게 넘기며, 결과 품질을 같은 기준으로 평가해야 하기 때문입니다.

이 후보들은 설치만으로 권한을 강제하지 않습니다. 실제 차단은 애플리케이션 코드와 역할 권한으로 구현해야 합니다. `frustration-detection`과 `emotional-design`을 고객 자동 분류나 제재에 바로 연결하는 선택은 제외합니다. 감정 추정은 틀릴 수 있고 취약한 사용자를 과도하게 분류할 위험이 있습니다.

추천 목록은 이렇게 활용하면 좋습니다

50개를 한 작업에 붙이는 방식은 권하지 않습니다. 지금 만드는 것이 웹 화면인지, 이미지인지, 대화형 제품인지 먼저 정한 뒤 해당 분야의 생성 도구와 검수 도구를 하나씩 골라 시작합니다.

이름이 실제 설치형 스킬, 외부 도구, 설계 방법론을 함께 가리킬 수 있습니다. 아래 원본 링크에서 추천 단계를 먼저 보고, 검토 후 사용은 실행 파일과 권한을 읽은 뒤 판단하세요. 아이디어 참고는 설치하지 않고 팀의 프롬프트, 체크리스트와 평가 기준으로 활용하는 편이 좋습니다.

화면 디자인은 만들기와 눈으로 확인하기를 묶습니다

화면을 예쁘게 만드는 도구 하나만으로는 완성도가 잘 오르지 않습니다. 코드를 생성하는 역할과 실제 화면을 열어 어긋남을 찾는 역할이 달라서입니다. 예를 들어 `frontend-design`이나 `impeccable` 계열의 지침으로 화면을 만든 뒤, 브라우저 자동화로 모바일과 데스크톱 화면을 직접 확인하는 식이 더 안정적입니다.

`theme-factory`와 `brandkit`처럼 색, 글자, 로고 규칙을 다루는 역할은 매 화면마다 새 취향을 발휘하지 않게 해줍니다. 먼저 색상 수, 글자 크기 단계, 여백 단위와 버튼 모양을 정해 두면 생성 도구가 바뀌어도 화면의 인상은 크게 흔들리지 않습니다.

추천 조합은 단순합니다. 새 화면 제작에는 생성 역할 하나, 브라우저 검수 하나, 브랜드 규칙 하나를 둡니다. 이미 있는 화면을 고칠 때는 새 생성 도구를 추가하기보다 `impeccable` 같은 점검 역할과 브라우저 검수에 집중하는 편이 낫습니다.

이미지와 영상은 결과물 형식부터 정합니다

`nano-banana`, `canvas-design`, `remotion-superpowers`, `blender-motion`은 모두 시각 결과를 다루지만 필요한 작업 환경은 완전히 다릅니다. 한 장의 대표 이미지를 만들려는 사람에게 영상 편집과 3D 도구까지 한꺼번에 붙이는 것은 도움이 되지 않습니다.

먼저 최종 파일을 정하면 선택지가 줄어듭니다. 사진이나 일러스트 한 장이면 이미지 생성·편집 도구, 수정 가능한 카드뉴스면 캔버스나 벡터 기반 도구, 반복 제작하는 짧은 영상이면 코드 기반 영상 도구, 공간과 입체 움직임이 핵심이면 3D 도구가 맞습니다.

여기에 반드시 검수 조건을 붙여야 합니다. 이미지라면 글자 오탈자, 손과 물체의 형태, 브랜드 색, 사용권과 출력 크기를 확인합니다. 영상이라면 첫 장면의 이해도, 자막 안전 영역, 소리 없이 봐도 뜻이 통하는지, 프레임 끊김과 최종 길이를 확인합니다. 프롬프트를 잘 쓰는 능력보다 이 합격 조건이 결과의 차이를 더 크게 만듭니다.

AI 제품 설계 항목은 기능 목록이 아니라 대화 흐름입니다

`context-window-design`, `conversation-patterns`, `generative-ui` 같은 항목은 버튼 하나로 켜는 장식이 아닙니다. 사용자가 무엇을 말했고, 시스템이 무엇을 기억하며, 다음 행동을 어떤 형태로 보여줄지 정하는 제품 설계에 가깝습니다.

가령 여행 계획을 돕는 AI라면 모든 정보를 한 번에 묻기보다 날짜와 지역부터 받고, 다음 단계에서 예산과 취향을 묻는 편이 자연스럽습니다. 답변도 긴 문장만 내놓기보다 후보 카드와 수정 버튼을 함께 보여줄 수 있습니다. 사용자가 지친 기색을 보이면 선택지를 줄이고, 결제나 삭제처럼 되돌리기 어려운 순간에는 사람의 확인을 받습니다.

이때 필요한 것은 스킬 열 개가 아니라 상태를 적은 작은 흐름도입니다. “현재 아는 정보”, “다음에 물을 한 가지”, “도구를 실행하기 전 확인”, “실패했을 때 돌아갈 곳”을 정하면 기억 관리, 점진적 공개, 사람 개입과 인계 원칙이 한 흐름 안에서 작동합니다.

프롬프트 10개는 하나의 문서로 합칠 수 있습니다

시스템 지시문 구조, 성격, 말투, 예시, 제약, 문맥 관리와 버전 관리는 따로 떨어진 기술처럼 보이지만 실제로는 하나의 작업 명세서에 들어갑니다. 역할과 목표를 먼저 쓰고, 사용할 정보와 하지 말아야 할 일을 정한 뒤, 좋은 입력과 출력 예시를 붙이는 순서면 충분합니다.

복잡한 문제를 다룬다고 해서 모델의 숨은 사고 과정을 길게 요구할 필요는 없습니다. 대신 필요한 중간 결과를 밖으로 드러내는 편이 좋습니다. 예를 들어 “후보 세 개를 비교표로 만들고, 선택 이유와 확인이 필요한 사실을 나눠 써라”처럼 검수할 수 있는 산출물을 요구합니다.

버전 관리도 중요합니다. 지시문을 고칠 때마다 전체를 덮어쓰면 무엇이 좋아졌는지 알 수 없습니다. 날짜나 버전을 붙이고, 바꾼 이유와 통과해야 할 대표 사례 몇 개를 함께 보관하면 프롬프트가 감에 의존하는 문장에서 반복해서 개선할 수 있는 제품 자산으로 바뀝니다.

신뢰와 안전은 마지막 점검표가 아닙니다

가드레일, 편향 점검, 품질 기준과 사람에게 넘기는 절차는 출시 직전에 덧붙이는 문구가 아닙니다. 어떤 일을 자동으로 해도 되는지 정하는 순간부터 함께 설계해야 합니다. 식당 추천의 실수와 송금 실행의 실수는 피해가 다르므로 같은 확인 절차를 쓸 수도 없습니다.

가벼운 초안 작성은 자동 실행하고 사용자가 고치게 할 수 있습니다. 외부 전송, 결제, 삭제, 개인정보 처리처럼 되돌리기 어렵거나 피해가 큰 행동은 실행 직전에 대상과 범위를 다시 보여주고 확인받아야 합니다. 확실하지 않은 정보는 추측으로 채우지 않고 무엇을 확인하지 못했는지 표시합니다.

`output-quality-rubrics`, `failure-taxonomy`, `task-success-metrics`가 가리키는 핵심도 여기에 있습니다. 좋은 답의 조건을 미리 적고, 실패를 몇 가지 유형으로 나누고, 실제 성공 여부를 측정해야 합니다. “자연스러운 답변” 같은 모호한 기준보다 “요청한 세 항목을 모두 포함했는가”, “근거 없는 숫자가 없는가”, “실행 전 확인을 받았는가”처럼 판정 가능한 기준이 낫습니다.

목적별 추천 목록은 이렇게 고를 수 있습니다

웹사이트나 앱 화면을 만드는 사람에게는 `frontend-design`, `impeccable`, `playwright-mcp`, `theme-factory` 조합을 먼저 권합니다. 첫 도구로 화면의 큰 구조를 만들고, 두 번째로 색과 정렬을 다듬고, 브라우저에서 실제 결과를 확인한 뒤, 마지막으로 색·글자·간격 규칙을 고정하는 흐름입니다. 이미 디자인 시스템이 있다면 `theme-factory`보다 기존 브랜드 규칙을 우선합니다.

브랜드 이미지와 카드뉴스가 목적이라면 `brandkit`, `nano-banana`, `canvas-design` 세 가지면 시작할 수 있습니다. 로고·색·폰트 기준을 먼저 정하고, 이미지 생성 도구로 소재를 만든 뒤, 수정 가능한 캔버스에서 문구와 배치를 마무리합니다. 데이터가 중심인 콘텐츠만 `data-visualization`을 추가합니다.

짧은 영상을 반복해서 만들려면 `banana-claude`로 장면별 이미지 지시를 정리하고 `remotion-superpowers`나 `claude-remotion` 가운데 하나를 고르는 편이 좋습니다. 입체 공간과 카메라 움직임 자체가 결과의 핵심일 때만 `blender-motion`을 추가합니다. 단순한 숏폼에 3D 효과와 후반 작업 도구까지 모두 붙일 필요는 없습니다.

대화형 AI 제품을 설계한다면 `conversation-patterns`, `progressive-disclosure`, `generative-ui`, `human-in-the-loop`를 추천합니다. 대화가 이어지는 규칙을 잡고, 한 번에 보여주는 정보를 줄이고, 답을 버튼과 카드로 바꾸며, 중요한 실행 전에 사람이 확인하도록 만드는 조합입니다. 긴 대화를 실제로 기억해야 할 때만 `context-window-design`을 더합니다.

프롬프트를 자주 관리하는 팀에는 `system-prompt-structure`, `constraint-specification`, `few-shot-patterns`, `prompt-versioning`이 실용적입니다. 역할과 목표를 정하고, 금지 조건과 출력 형식을 명시하고, 좋은 예시를 붙인 뒤, 변경 이력을 남기는 순서입니다. 감정적인 상담이나 브랜드 고객 응대처럼 말투가 중요한 경우에만 `tone-calibration`과 `emotional-design`을 추가합니다.

신뢰와 안전이 중요한 서비스에는 `guardrail-design`, `trust-calibration`, `output-quality-rubrics`, `handoff-protocols`를 기본으로 권합니다. 하지 말아야 할 행동, 확신이 낮을 때의 표현, 답변 합격 기준, 사람에게 넘길 조건을 차례로 정합니다. 의료·금융·법률이나 외부 전송·결제·삭제를 다루면 `harm-anticipation`과 `escalation-design`도 함께 검토해야 합니다.

처음 고른다면 이 다섯 역할이면 충분합니다

분야를 아직 정하지 못했다면 설치부터 하지 않는 편이 낫습니다. 화면을 고칠 때는 `impeccable` 같은 실제 Skill 한 개를 검토하고, 브라우저 조작이 꼭 필요할 때만 `playwright-mcp`를 별도 권한으로 연결합니다. `system-prompt-structure`와 `output-quality-rubrics`는 우선 팀 문서의 지시문 구조와 품질표로 적용할 수 있습니다. 이미지가 필요한 작업에서만 API 키와 출력 권리를 확인한 뒤 `nano-banana` 같은 도구를 시험합니다.

다만 이 다섯 이름이 모두 같은 설치 방식으로 제공된다는 뜻은 아닙니다. `impeccable`처럼 실제 스킬로 배포되는 항목이 있는 반면, 시스템 지시문 구조나 품질 평가표는 팀 문서와 테스트로 직접 구현하는 편이 더 맞을 수 있습니다. 이름보다 역할을 먼저 고르고, 공식 배포처가 확인되는 도구만 설치하는 것이 안전합니다.

처음에는 세 가지 조합만 만들면 됩니다

웹 화면을 고치려면 화면 개선 지침, 브라우저 검수, 브랜드 규칙을 묶습니다. 카드뉴스를 만들려면 이미지 생성, 수정 가능한 편집 도구, 출력 규격 검사를 묶습니다. 고객 응대 AI를 만들려면 대화 흐름, 지시문 명세, 사람에게 넘기는 조건을 묶습니다.

각 조합을 한 번 실행한 뒤에는 결과보다 실패 기록을 먼저 남깁니다. 화면이 모바일에서 잘렸는지, 이미지의 문자가 틀렸는지, AI가 묻지 않은 정보를 지어냈는지 적습니다. 다음 작업에서 그 실패를 막는 규칙 하나만 추가하면 도구 상자는 작아도 점점 단단해집니다.

좋은 스킬 목록의 가치는 50개라는 숫자에 있지 않습니다. 내가 놓친 역할을 보여주는 지도라는 데 있습니다. 지도 전체를 짐처럼 들고 다니기보다, 오늘 갈 곳에 필요한 도구만 골라 쓰는 것이 더 빠르고 안전합니다.