신규하 블로그

이 영상이 흥미로운 이유는 “Claude Code 스킬을 어떻게 만들까"를 추상적으로 말하지 않기 때문입니다. 발표자는 Anthropic 팀이 내부에서 수백 개 스킬을 운영하면서 무엇이 실제로 먹히는지 압축해서 보여 줍니다. 그래서 초점은 예쁜 SKILL.md 문서를 쓰는 법이 아니라, 스킬이 왜 자꾸 흐트러지고 어떤 구조로 바꿔야 안정적으로 작동하는지 에 있습니다 (t=0). 영상 전체를 한 문장으로 줄이면 이렇습니다. 스킬은 정적인 프롬프트 파일이 아니라, 실패 기록과 보조 자료와 실행 제약을 함께 묶은 작업 패키지 여야 한다는 것입니다. 이 관점으로 보면 폴더 구조, description, gotchas, hooks, 팀 배포 방식이 모두 하나의 운영 문제로 연결됩니다 (t=22, t=262, t=313). 더보기

pbakaus/impeccable 가 흥미로운 이유는 “예쁜 프런트엔드 프롬프트 모음” 수준에서 끝나지 않기 때문입니다. 이 프로젝트는 디자인 품질 문제를 단순한 취향이나 모델 성능의 문제가 아니라, AI에게 줄 수 있는 디자인 어휘와 평가 기준이 부족한 문제 로 다시 정의합니다. 공식 사이트가 강조하듯, 사용자가 vertical rhythm 같은 말을 모르면 모델에게 그 수준의 수정을 요청하기도 어렵습니다. 그래서 Impeccable의 핵심은 “더 멋진 화면을 만들어 줘"가 아니라, 디자인 언어를 스킬과 명령으로 쪼개서 여러 AI 하네스에 이식 가능한 형태로 배포한다 는 데 있습니다. 2026년 3월 23일 기준으로 공식 사이트는 이 프로젝트를 1개의 종합 스킬과 20개의 디자인 명령으로 소개하고 있고, 실제 저장소 소스 디렉터리도 총 21개 스킬 중 20개를 user-invocable 명령으로 구성하고 있습니다. 더보기

gstack가 흥미로운 이유는 “Claude Code에 좋은 프롬프트 몇 개를 얹었다” 수준이 아니기 때문입니다. 이 영상이 보여 주는 핵심은 제품 기획, 엔지니어링 리뷰, QA, 배포, 회고를 각각 다른 역할로 분리해 AI를 한 명의 조수에서 하나의 팀처럼 운영하는 방식 입니다. 발표자는 이를 Garry Tan의 경험과 노하우를 Markdown 스킬로 빌려 오는 느낌이라고 설명하고, 실제로 /plan-ceo-review부터 /retro까지를 하나의 개발 사이클로 묶어 보여 줍니다 (근거: t=120, t=154, t=330). 날짜를 분리해서 보는 것도 중요합니다. 영상 설명란에는 업로드 시점 기준으로 “2.5만 stars” 와 “15개 skills"가 언급되지만, 제가 이 글을 쓴 2026-03-23 시점에 garrytan/gstack 저장소는 이미 4만 star를 넘겼고, 현재 README는 28개 skill을 소개하고 있습니다. 즉, 이 글은 2026-03-19에 공개된 영상의 설명 과 2026-03-23에 확인한 공식 문서의 현재 상태 를 구분해 함께 읽는 방식으로 정리합니다. YouTube Video GitHub Repository README 더보기

이 영상이 흥미로운 이유는 Google Stitch를 “Claude Code의 대체품” 으로 소개하지 않는다는 데 있습니다. 발표자는 오히려 Claude Code의 약점으로 느끼는 프런트엔드 디자인 구간만 Stitch로 먼저 처리하고, 그다음 코드를 Claude Code로 넘겨 제품화하는 식으로 역할을 나눠야 한다고 설명합니다. 즉 핵심은 모델 하나를 바꾸는 것이 아니라, 시작점을 어디에 두느냐를 바꾸는 데 있습니다 (근거: t=24, t=45, t=83, t=117, t=138). 그래서 이 글은 이 영상을 단순한 툴 소개가 아니라 영감 수집 -> Stitch에서 시안과 디자인 시스템 생성 -> 반복 탐색 -> 코드 내보내기 -> Claude Code에서 마무리 라는 워크플로 문서로 읽습니다. 발표자가 계속 강조하는 것도 “완제품을 한 번에 뽑는다” 가 아니라, 시각적 품질이 중요한 초반 탐색을 더 싼 비용과 더 빠른 반복으로 처리한 뒤 Claude Code에서 실제 앱으로 이어 가는 방식입니다 (근거: t=97, t=117, t=138, t=653, t=699, t=725). 더보기

에이전트 기반 개발에서 가장 흔한 실패는 기획 문서와 구현 흐름이 한 덩어리로 섞이는 순간 시작됩니다. 제품 판단이 흔들리면 구현 속도가 빨라질수록 더 멀리 돌아가고, 반대로 구현 규율이 약하면 좋은 PRD가 있어도 프로젝트는 중간에 흐트러집니다. 이럴 때 가장 실전적으로 잘 맞는 조합이 pm-skills 와 GSD 입니다. pm-skills 는 PRD, hypothesis, user stories, acceptance criteria 같은 PM 산출물을 구조화하는 쪽이 강하고, GSD 는 spec-driven 개발, phase 운영, 컨텍스트 관리, /gsd:do, /gsd:next, /gsd:ship 같은 실행 루프에 강합니다. 그리고 Claude Code는 공식적으로 skills 확장 구조를 지원합니다. 그래서 가장 실전적인 운영은 아주 단순하게 정리됩니다. 제품 정의는 pm-skills로 먼저 고정하고, GSD는 그 산출물을 받아 프로젝트 구조와 phase 실행을 관리하는 구조 입니다. 더보기

이 영상의 제목은 “코딩 배우지 마세요” 이지만, 실제로 보여 주는 내용은 코딩이 완전히 필요 없다는 선언에 가깝지 않습니다. 더 정확히 말하면 발표자는 SDK 설치나 Claude Code 문법부터 배우는 대신, Claude 데스크톱 대화창에서 에이전트가 따라야 할 역할 정의, 행동 규칙, 출력 형식을 먼저 말로 설명하고, 그 설명을 실행 가능한 지침 파일로 굳히는 흐름을 보여 줍니다. 즉 핵심은 “코드를 안 쳐도 된다” 가 아니라 “에이전트 명세를 자연어로 먼저 외주화할 수 있다” 에 있습니다 (근거: t=2, t=10, t=12, t=49, t=52, t=57). 그래서 이 글은 이 영상을 “주식 추천 프롬프트” 로 읽지 않고, 자연어 요청이 어떻게 MD 지침 파일, 에이전트 팀, 코워크(Cowork) 실행 컨텍스트, 병렬 리서치, PDF 보고서, 예약 작업으로 이어지는지 정리하는 워크플로 문서로 읽습니다. 영상 후반으로 갈수록 진짜 포인트는 종목명보다 운영 루프에 있습니다. 에이전트 명세 생성 -> 폴더 적재 -> Cowork 실행 -> 병렬 분석 -> 산출물 수정 -> 예약 실행 이라는 루프가 이 영상의 실전 가치입니다 (근거: t=68, t=146, t=217, t=263, t=347, t=465). 더보기

이 영상이 흥미로운 이유는 “대본만 넣으면 20분 만에 영상이 나온다” 는 선언 자체보다, 그 결과에 도달하기까지 30일 동안 어떤 시행착오가 있었는지를 꽤 투명하게 공개한다는 데 있습니다. 발표자는 이 영상 자체도 자신이 대본만 쓰고 나머지는 AI가 처리했다고 설명하면서, 프리미어 프로나 애프터이펙트, 캡컷 같은 편집 툴을 열지 않고도 모션 그래픽 영상을 자동 생성할 수 있다고 말합니다. 하지만 동시에 여기까지 오는 데 30일이 걸렸고, 오늘의 목적은 마법 같은 프롬프트를 자랑하는 것이 아니라 그 30일에서 건진 핵심 인사이트를 압축해서 공유하는 것이라고 못 박습니다 (근거: t=0, t=7, t=17, t=22, t=26, t=61). 더보기