Claude Code 확장은 많이 설치할수록 좋아지는 게 아니다. 실제 병목은 보통 코드 생성보다 기획 없는 구현, 배포 전환, 웹 자료 수집, 외부 도구 연결, 보안 점검에서 생긴다. 이 글은 Claude Code에 붙여볼 만한 6가지 skill/MCP/tool을 “내 상황에서 먼저 쓸 만한가” 기준으로 정리한다.
먼저 skill과 MCP를 구분해야 한다. Claude Code의 skill은 특정 작업 방식을 가르치는 지침 묶음에 가깝고, MCP는 외부 시스템 기능을 Claude Code 안에서 호출하게 해주는 연결 방식에 가깝다. 공식 문서에서도 Claude Code는 skills와 MCP 서버 연결을 따로 다룬다. MCP 개념 자체가 낯설다면 먼저 MCP란 무엇인가를 보고 오면 아래 판단이 훨씬 쉬워진다.

빠른 선택표
| 지금 막히는 지점 | 먼저 볼 후보 | 설치 전 체크할 것 |
|---|---|---|
| 아이디어는 많은데 제품이 산으로 간다 | GStack | 개발 속도를 높이는 도구가 아니라 질문과 검증을 늘리는 도구다 |
| 만든 앱을 배포할 때마다 터미널 밖으로 나간다 | Hostinger MCP | API 토큰, 도메인 등록, 검증용 환경이 먼저다 |
| 웹 자료를 여러 페이지에서 구조적으로 뽑아야 한다 | Firecrawl | 단순 검색이 아니라 크롤링 범위와 출력 형식이 핵심이다 |
| 이메일, 답장, SNS 문장이 너무 AI처럼 보인다 | Humanizer | 사실 검증이나 논리 개선 도구가 아니다 |
| Gmail, Notion, Drive 등 연결 도구가 너무 많다 | Composio | 연결 앱이 적으면 허브를 하나 더 두는 비용이 더 클 수 있다 |
| vibe coding 결과물을 배포하기 불안하다 | VibeSec | 보안 리뷰를 끝내는 도구가 아니라 멈춰 세우는 체크포인트다 |
이 표에서 하나만 골라도 충분하다. 특히 MCP는 외부 시스템 권한을 Claude Code에 연결하는 방식이라 “편해 보인다”보다 “이 권한을 넘겨도 되는가”가 먼저다.
1. GStack: 바로 만들기 전에 질문을 강제로 늘린다
GStack은 영상에서 Gary Tan 쪽 공개 bundle로 소개된 Claude Code skill 묶음이다. 영상 기준으로는 23개 skill이 있고, office hours, plan, CEO review, review, QA 같은 흐름을 통해 제품을 만들기 전에 질문을 더 많이 하게 만든다.
이 도구가 맞는 사람은 “무엇을 만들지”보다 “왜 만들어야 하는지”가 자주 흐려지는 사람이다. 영상 예시는 YouTube 비즈니스용 내부 회계 소프트웨어다. invoice, expense, financial health 추적 기능을 바로 구현하는 대신, office hours가 먼저 실제 고통 지점과 사용 이유를 묻는다.
여기서 장점은 코드 품질보다 제품 방향이다. Claude Code로 바로 구현하면 화면은 빨리 나온다. 하지만 실제 사용자가 매일 열 이유가 없는 앱도 그만큼 빨리 만들어진다. GStack은 그 속도를 일부러 늦춰서 기획, CEO 관점 리뷰, 엔지니어링 리뷰, QA를 거치게 한다.
이미 요구사항이 명확하고 작은 수정만 하는 상황이라면 GStack은 무겁다. 버튼 하나 고치는데 CEO review까지 돌릴 필요는 없다. 신규 제품, 사내 툴, 돈이나 운영 판단이 걸린 기능을 만들 때 먼저 써볼 만하다.
2. Hostinger MCP: 배포 자동화의 핵심은 토큰과 도메인이다
Claude Code로 앱을 만든 뒤 가장 귀찮은 순간은 배포 전환이다. VPS를 사고, 도메인을 연결하고, DNS를 확인하고, Node.js 앱을 올리는 일은 코드 작성과 다른 종류의 피로를 만든다. Hostinger MCP는 이 배포 관련 작업을 Claude Code 안으로 끌어오려는 선택지다. Hostinger도 API MCP Server 문서에서 MCP 서버 설정과 토큰 연결 흐름을 안내한다.
실전에서 중요한 건 설치 명령보다 API 토큰 관리다. 영상에서는 Hostinger API 페이지에서 MCP config를 복사하고, API token을 만들어 Claude Code 설정에 넣은 뒤 /mcp로 연결을 확인한다. 다만 토큰을 프롬프트에 그대로 붙여 넣는 방식은 테스트용으로 잠깐 쓰고 지울 때나 가능한 편법에 가깝다. 계속 쓸 값이라면 환경 변수나 별도 비밀값 관리 방식으로 다뤄야 한다.
또 하나의 숨은 마찰은 도메인 등록이다. “이 URL로 배포해줘”라고 말하려면 도메인 소유자 정보와 등록 절차가 끝나 있어야 한다. 도메인이 아직 장바구니에 있거나 등록 정보가 미완성인 상태에서는 Claude Code가 배포를 시도해도 마지막에서 막힌다.
Hostinger MCP는 데모 사이트나 개인 프로젝트를 빠르게 올릴 때 매력적이다. 하지만 운영 중인 서비스라면 바로 실서비스에 연결하지 말고, 검증용 도메인이나 별도 테스트 환경부터 시작하는 게 맞다. Claude Code가 배포를 대신해도 운영 책임까지 대신 지지는 않는다.
3. Firecrawl: 한 페이지 요약이 아니라 대량 수집이 필요할 때
Firecrawl을 “Claude Code가 웹을 못 볼 때 대신 쓰는 도구” 정도로 보면 아쉽다. 진짜 쓸모는 여러 페이지를 크롤링하고, 일반적인 브라우징/검색 흐름에서 안정적으로 모으기 어려운 내용을 구조화된 결과로 뽑을 때 나온다. Firecrawl은 MCP 연동을 공식 문서로 제공한다.
영상에서는 YC 회사 디렉터리에서 AI 스타트업 페이지를 여러 개 크롤링하고, 회사 설명, 채용 중인 창업자, 투자 단계 같은 정보를 뽑는 예시가 나온다. 300개가 넘는 페이지를 약 10분 동안 처리해 Markdown 결과로 받았다는 사례다. 핵심은 “빠르다”보다 “반복 수집을 사람이 하지 않아도 된다”에 있다.
Firecrawl을 쓸지 말지는 세 가지로 판단하면 된다.
- 페이지가 여러 개이고 링크를 따라가야 하는가
- 결과를 Markdown, JSON, 표처럼 일정한 구조로 받아야 하는가
- 검색 결과 제목이 아니라 실제 페이지 본문이 필요한가
셋 중 하나만 해당하면 검토할 만하다. 반대로 문서 한두 개를 읽는 일이라면 기본 검색이나 브라우저 확인이 더 단순하다. 크롤링은 비용, 사이트 정책, 접근 권한 문제가 함께 따라오므로 수집 범위와 출력 형식을 먼저 정하고 시작해야 한다.
4. Humanizer: 문장은 부드럽게 만들지만 판단은 바꾸지 못한다
Humanizer는 가장 가벼운 축에 속한다. Claude Code가 만든 이메일, 댓글, SNS 문장, 고객 응대문이 너무 AI처럼 보일 때 /humanize 흐름으로 톤을 다듬는 용도다. 과한 대시, 반복되는 AI식 표현, 지나치게 매끈한 문장을 줄이는 데 쓸 수 있다.
개발자에게도 문장은 계속 필요하다. PR 설명, 릴리즈 노트, 고객 답장, 내부 공지, 채용 메시지처럼 “정확하지만 너무 기계적인 문장”을 다듬는 데 시간이 줄어든다.
다만 Humanizer를 사실 검증 도구처럼 쓰면 안 된다. 원문이 틀렸으면 더 자연스럽게 틀린 문장이 된다. 논리가 빈약하면 더 읽기 쉬운 빈약한 문장이 된다. 그래서 사용 순서는 “내용 확인 → 사실 검증 → 톤 정리”가 맞다.
이 도구는 마지막 10%를 정리하는 데 쓰면 좋다. 처음부터 Humanizer에 맡기면 문장이 편해지는 대신 책임져야 할 기술 판단이 흐려질 수 있다.
5. Composio: 연결 도구가 많아질 때 생기는 과적재를 줄인다
Claude Code에 Gmail, Google Drive, Notion, Slack, 광고 계정, CRM을 직접 하나씩 붙이기 시작하면 문제가 생긴다. 연결 자체도 번거롭지만, 더 큰 문제는 Claude Code가 너무 많은 tool 정의를 한꺼번에 보게 된다는 점이다. 새 기기로 옮길 때 다시 연결해야 하는 피로도 생긴다.
Composio는 이 문제를 허브 방식으로 풀려는 도구다. 여러 앱은 Composio 쪽에 연결해두고, Claude Code는 Composio를 통해 필요한 도구를 찾고 호출한다. 공식 문서도 앱 연결과 에이전트/툴 연동을 중심으로 구성되어 있다.
영상의 예시는 Gmail이다. Composio에서 Gmail을 연결한 뒤 Claude Code에서 “최근 이메일 3개를 민감정보 없이 요약해줘”라고 요청한다. Claude Code가 Gmail의 모든 액션을 항상 들고 있는 게 아니라, Composio를 통해 필요한 작업을 호출하고 정리된 결과를 받는 흐름이다.
도입 기준은 간단하다. 연결한 앱이 두세 개 이하라면 아직 필요 없을 가능성이 높다. 반대로 업무 도구가 늘어나 Claude Code 세션이 산만해지고, 새 환경에서 매번 연결을 반복하고 있다면 Composio가 체감된다.
6. VibeSec: 배포 직전에 “잠깐 멈춤”을 만드는 보안 장치
VibeSec은 vibe coding 결과물이 그대로 실서비스에 들어가는 위험을 줄이려는 보안 skill 후보로 볼 수 있다. 영상에서는 배포 전 코드베이스를 훑으며 API key 노출, 인증 없는 데이터 접근, 취약한 구현 같은 문제를 찾는 흐름으로 소개된다.
이런 도구는 배포 직전에 한 번 돌리는 것도 의미가 있지만, 더 좋은 위치는 개발 초반이다. Claude Code가 처음부터 인증, 권한, 비밀값, 입력 검증을 의식하도록 만드는 쪽이 나중에 고치는 것보다 싸다.
여기서 선을 분명히 그어야 한다. VibeSec을 돌렸다고 보안 검토가 끝나는 것은 아니다. 최소한 secret 노출 여부, 인증이 필요한 route, 관리자 권한, 의존성 취약점, 로그에 민감정보가 찍히는지 정도는 별도로 확인해야 한다. 결제, 로그인, 고객 데이터, 관리자 페이지가 있으면 사람의 코드 리뷰도 필요하다.
개인 프로젝트라도 배포되는 순간 위험의 성격이 달라진다. “내 컴퓨터에서 잘 돈다”와 “인터넷에 열어도 된다”는 완전히 다른 기준이다.
설치 순서는 이렇게 잡는 게 낫다
처음부터 여섯 개를 다 설치하지 말고, 지금 가장 자주 막히는 지점 하나만 고르는 편이 낫다.
새 프로젝트를 자주 시작하지만 끝까지 쓸 만한 제품이 잘 안 나온다면 GStack부터 본다. Claude Code 설정과 MCP 활용 자체를 더 넓게 정리하고 싶다면 Claude Code 잘 쓰는 법도 함께 보는 편이 좋다.
배포를 자주 반복한다면 Hostinger MCP가 후보지만, 먼저 검증용 도메인과 토큰 관리 방식을 정해야 한다. 웹 리서치나 데이터 수집이 반복된다면 Firecrawl이 더 먼저다. 다만 출력 스키마 없이 “알아서 정리해줘”라고 시작하면 결과 품질이 흔들린다.
업무 도구가 너무 많아졌다면 Composio를 검토한다. 글쓰기 마찰이 잦다면 Humanizer는 가볍게 붙일 수 있다. 마지막으로 로그인, 결제, 관리자 페이지, 고객 데이터가 들어간 앱을 배포한다면 VibeSec 같은 보안 체크 도구를 늦게라도 넣어야 한다.
결론: Claude Code 확장은 병목 하나를 정확히 줄일 때 값이 있다
GStack은 제품 방향, Hostinger MCP는 배포, Firecrawl은 웹 수집, Humanizer는 문장 톤, Composio는 외부 도구 허브, VibeSec은 보안 점검에 가깝다. 여섯 개 모두 “Claude Code를 더 똑똑하게 만드는 도구”라고 묶을 수는 있지만, 실제로 줄여주는 마찰은 서로 다르다.
가장 현실적인 선택은 지금 작업에서 반복해서 짜증 나는 지점을 하나 고르는 것이다. 기획 없이 구현부터 한다면 GStack, 배포가 귀찮다면 Hostinger MCP, 웹 수집이 반복된다면 Firecrawl, 연결 도구가 산만하다면 Composio, 배포 전 불안하다면 VibeSec이다. Humanizer는 글쓰기 마찰이 잦을 때 마지막 정리용으로 두면 된다.
Claude Code를 잘 쓰는 방법은 모든 확장을 다 넣는 것이 아니다. Claude Code가 해도 되는 일과 사람이 직접 확인해야 하는 일을 나누는 것이다.
FAQ
Claude Code MCP는 많이 붙일수록 좋은가요?
아니다. MCP는 외부 도구와 권한을 연결하므로 편해지는 만큼 보안과 선택 문제가 생긴다. 자주 쓰는 병목부터 하나씩 붙이는 편이 낫다.
VibeSec 같은 보안 skill을 돌리면 배포해도 안전한가요?
그렇게 보면 안 된다. 보안 skill은 위험을 줄이는 체크포인트다. secret 관리, 인증/권한 확인, 의존성 점검, 코드 리뷰는 별도로 필요하다.
'SW > 인공지능' 카테고리의 다른 글
| Claude J-space 쉽게 이해하기: AI가 의식을 가진 게 아니라, 더 그럴듯하게 틀릴 수 있다는 신호 (0) | 2026.07.11 |
|---|---|
| RDT-1B 논문 리뷰: 회귀가 놓친 “여러 정답”을 디퓨전으로 살린 로봇 파운데이션 모델 (0) | 2026.07.11 |
| AI 네이티브 개발: 바이브 코딩을 실제 앱으로 바꾸는 2026년 실전 기준 (0) | 2026.07.07 |
| AI 엔지니어 연봉 현실: 주니어·미드레벨·시니어 구간별 준비 기준 (0) | 2026.07.06 |
| 2026 개발자 프로젝트 10선: AI 에이전트 피로감 사이에서 볼 만한 것들 (0) | 2026.07.04 |