클로드 코드를 10개월 정도 매일 켜 두고 써 본 뒤 남은 건 화려한 스킬 목록이 아니라 반복해서 손이 가는 여섯 개의 도구였다고 말한다. 리액트, 넥스트JS, 자동화, 클라이언트 작업, 자료 제작까지 해 보니 문제는 비슷하게 반복됐고, 그 문제를 막아 주는 도구도 결국 비슷하게 남았다는 이야기다.
flowchart LR A[깃허브 별점만 믿기 어려운 스킬 생태계] --> B[별점 조작과 프롬프트 인젝션 문제] B --> C[검증된 6개 도구를 계획 구현 리뷰 흐름에 배치] C --> D[버그 감소 세션 수명 연장 QA와 리뷰 효율 개선]
핵심 요약
- 10개월 동안 클로드 코드를 쓰며 실제로 매일 켜 두는 도구는 여섯 개 정도로 압축됐다고 정리한다.
- 깃허브 별점이 많아도 품질이 좋다는 보장은 없고, 설치 스크립트에 프롬프트 인젝션을 심어 별점을 유도하는 사례까지 있다고 짚는다.
- superpowers는 계획 수립, 테스트 우선, 코드 작성, 스펙 리뷰, 코드 품질 리뷰까지 묶어서 급하게 짠 코드를 줄이는 역할을 맡는다.
- gstack의 office-hours와 browse는 아이디어를 좁히는 질문과 빠른 브라우저 세션으로 기획과 QA 양쪽에서 자주 쓰인다고 설명한다.
- grill-me, improvement-architecture, codex:review, vercel react best practices, 그리고 pptx·pdf 스킬까지 이어 붙이면 코드 리뷰부터 결과물 문서화까지 한 흐름으로 이어진다.
왜 지금 중요한가
리액트 프로젝트, 넥스트JS 프로젝트, 자동화, 자료 제작처럼 분야가 달라도 같은 문제가 반복된다고 말한다. 그 와중에 깃허브가 “인스타그램처럼 변했다”고 표현할 만큼 별점 부풀리기와 바이럴용 프로젝트가 많아져서, 지금은 많이 알려진 도구보다 검증된 도구를 고르는 능력이 더 중요하다는 맥락이 또렷하다.
주요 내용
1. 별점보다 먼저 봐야 할 것들
초반부에서 가장 강하게 말하는 건 깃허브 별점을 그대로 믿지 말라는 점이다. 실제로 설치 스크립트에 프롬프트 인젝션을 심어 에이전트가 파일을 읽으면 성능과 상관없이 깃허브 별을 누르도록 유도하는 프로젝트가 있다고 설명한다. 그래서 “별 많다고 좋은 프로젝트라는 보장이 절대 없어요”라는 결론으로 이어지고, 클로드 코드를 진지하게 쓸 생각이라면 검증된 몇 개부터 시작하라고 권한다.
2. 설계와 분해는 superpowers에서 시작한다
superpowers는 스킬 하나가 아니라 여러 스킬이 들어 있는 플러그인으로 소개된다. 바로 코드를 뱉게 두지 않고, 먼저 계획을 세우고, 테스트를 먼저 쓰고, 그다음 코드를 쓰고, 끝나면 스펙과 코드 품질을 각각 한 번씩 다시 본다고 설명한다. 발표자는 여기서 brainstorming과 subagent-driven-development를 특히 많이 쓴다고 말하는데, brainstorming은 “누가 쓸 거예요?”, “성공 기준이 뭐예요?”, “어떤 문제 해결하는 거예요?” 같은 질문으로 요구사항을 정리하고, subagent-driven-development는 큰 일을 서브 에이전트에 나눈 뒤 다른 서브 에이전트가 결과물을 두 단계로 리뷰하게 만든다.
3. gstack은 아이디어 검증과 브라우저 QA를 빠르게 돌린다
gstack에서는 office-hours와 browse 두 개를 매일 쓴다고 한다. office-hours는 새 아이디어를 들고 가면 “진짜 수요가 있어요?”, “기존에 다들 어떻게 해결하고 있어요?”, “가장 좁은 진입점은 뭐예요?” 같은 질문 여섯 개를 던져 사업 아이디어를 더 좁고 날카롭게 만든다. browse는 백그라운드에 크롬 세션을 띄워 둬서 명령 하나가 100~200ms 안에 끝나고, 기존 방식보다 거의 20배 빠르다고 설명한다. 스크린샷, 로그인, 폼 체크, 콘솔 에러 확인까지 이 흐름으로 처리하고, 보통 클로드가 30분이면 망가지는데 이 조합을 켜 두면 두 시간도 간다고 말한다.
4. 리뷰, 리팩토링, 프론트엔드 품질, 문서화까지 이어 붙인다
코드를 짠 뒤에는 grill-me가 “이 useState 왜 여기 있어?”, “부모 컴포넌트로 올려야 되는 거 아니야?” 같은 식으로 1인 개발자에게 부족한 동료 역할을 해 준다고 설명한다. improvement-architecture는 “여기 이렇게 분리하면 테스트 쉬워져”, “이 부분 추상하면 재사용 가능해”처럼 구조를 통째로 다시 보게 해 주고, codex:review는 다른 모델 관점에서 한 번 더 훑어 클로드가 놓친 버그를 잡는 마지막 단계로 넣는다고 한다. 프론트엔드에서는 vercel react best practices가 useEffect 남용, 클라이언트·서버 컴포넌트 구분, 몇 년 전 패턴 재사용 같은 문제를 줄여 주고, 결과를 클라이언트에게 보여 줄 때는 pptx와 pdf 스킬로 슬라이드와 보고서를 자동 생성한다고 정리한다.
원문 발화 하이라이트
- [00:51~01:01] “설치 스크립트에 프롬프트 인젝션을 심어놔요. 에이전트가 그 파일을 읽으면 성능이랑 상관없이 무조건 기타 별을 누르도록 유도하는 거예요. 이런 식으로 별 수치를 조작해요.”
- [01:30~01:37] “일단 멈춰서 계획부터 세워요. 테스트 먼저 쓰고 그다음에 코드 쓰고. 끝나면 자기가 두 번 리뷰해요. 한 번은 스펙이 맞는지, 한 번은 코드 품질 어떤지요.”
- [03:18~03:23] “진짜 수요가 있어요. 기존에 다들 어떻게 해결하고 있어요? 가장 좁은 진입점은 뭐예요?”
- [03:42~03:46] “명령 하나당 100에서 200mm 안에 끝나요. 기존 방식보다 거의 20에 빠른 거예요.”
- [04:04~04:05] “둘 다 클로드를 차분하게 일하게 만드는 도구예요.”
바로 실행해 보기
- 새 기능을 넣기 전에 brainstorming 방식으로 요구사항부터 좁혀 본다. “누가 쓸 거예요?”, “성공 기준이 뭐예요?”, “어떤 문제 해결하는 거예요?” 세 질문에 답을 적은 뒤에만 구현으로 넘어간다.
- 구현 단계에서는 superpowers가 강조한 순서를 그대로 따라간다. 계획을 세우고, 테스트를 먼저 쓰고, 코드를 작성한 뒤, 결과물을 스펙 기준 한 번·코드 품질 기준 한 번 다시 본다.
- 코드가 나온 뒤에는 리뷰 루틴을 따로 둔다. grill-me처럼 상태 위치나 컴포넌트 분리 문제를 먼저 점검하고, improvement-architecture로 구조 분리 아이디어를 확인한 다음, 마지막에 codex:review처럼 다른 모델 관점 리뷰를 한 번 더 거친다.
참고
영상 메타
- 채널: 메이커 에반 | Maker Evan
- 제목: 400시간 만에 알게 된 Claude Code의 진짜 핵심 도구 6개
- 게시 시각(원문): 2026-05-13T03:17:37+00:00
- 영상: https://www.youtube.com/watch?v=BZPaZzjLIOY
- 썸네일: https://i3.ytimg.com/vi/BZPaZzjLIOY/hqdefault.jpg
수집 품질
- 자막 세그먼트: 308개
- 자막 문자수: 5540자
- 챕터 추출: 14개
- 콘텐츠 생성: Subagent 기반
AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.