신규하 블로그

gstack를 그냥 “Claude Code용 스킬 모음"으로 보면 이 프로젝트의 핵심을 놓치기 쉽습니다. 이 영상이 보여 주는 진짜 포인트는, 하나의 에이전트에게 모든 일을 몰아주는 대신 CEO, 엔지니어링 매니저, QA, 릴리즈 엔지니어처럼 역할을 분리하고 그 순서를 워크플로로 고정했다는 점입니다. 발표자는 이를 Garry Tan의 노하우를 Markdown 스킬로 빌려 오는 경험이라고 설명하고, 실제로 기획부터 브라우저 QA, 회고까지를 하나의 개발 루프로 연결해 보여 줍니다 (t=135, t=154, t=330). 날짜를 분리해서 읽는 것도 중요합니다. 영상은 2026-03-19에 업로드됐고, 설명란에는 업로드 시점 기준으로 15개 스킬과 2.5만 스타가 언급됩니다. 반면 제가 2026-03-24에 GitHub API로 확인했을 때 garrytan/gstack 저장소는 스타 43,925개, 포크 5,500개였고, 현재 README는 specialist skills와 power tools를 합쳐 28개의 slash command를 안내합니다. 즉 이 글은 영상이 전하는 설계 철학과 2026-03-24 기준 공식 저장소 상태를 구분해서 읽는 정리입니다. YouTube 영상 gstack 저장소 gstack README 더보기

프롬프트 엔지니어링은 AI에게 잘 부탁하는 기술이다. 하네스 엔지니어링은 AI가 잘못된 방향으로 갈 수 없도록 구조 자체를 설계하는 기술이다. DIO의 Forward Deployed Engineer(FDE) 김지운 님은 Claude를 쓰든, OpenAI Codex를 쓰든, Gemini를 쓰든 동일한 코드 구조와 문서가 나오는 시스템을 구축하는 데 수백 시간을 투자했다. 배달 플랫폼 4개 소프트웨어를 3개 모델에 시키면 12개의 결과물이 나오는데, 그 12개가 실질적으로 동일하다는 것을 직접 시연했다. 이것이 하네스 엔지니어링의 목표다. 더보기

이 영상이 흥미로운 이유는 “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 실행을 관리하는 구조 입니다. 더보기