서버 CLI 도구 정리 — Wrangler, gh, Supabase CLI

개발 도구 · 1인 개발자 메모

서버 CLI 도구 정리
— Wrangler, gh, Supabase CLI

클라우드 인프라를 다루다 보면 결국 터미널로 돌아오게 됩니다. 사이드 프로젝트를 진행하면서 실제로 쓴 세 가지 CLI를 정리했어요.

2026-05-26 · 약 6분 소요

왜 이 글을 쓰게 됐냐

오늘 프로젝트 백엔드를 Cloudflare로 옮기기로 결정하면서 wrangler login을 입력하려는데 문득 이런 생각이 들었어요.

"이거 도대체 뭐지? 왜 굳이 CLI를 쓰는 거지?"

이미 gh는 일상적으로 쓰고 있고, 한때 Supabase CLI도 보던 시기가 있었는데 막상 셋의 차이를 누가 물어보면 즉답이 어렵더라고요. 정리해두면 다음에 도구를 고를 때도 빠를 것 같아 글로 남깁니다.

CLI가 대체 뭐길래?

CLI는 그냥 "이 서비스를 터미널에서 다루기 위한 공식 도구" 정도로 이해하면 충분해요. 웹 대시보드에서 마우스로 클릭해서 하는 일을 명령어로 대신 하는 거죠.

$ gh repo create <owner>/<repo> --private

✓ Created repository <owner>/<repo> on GitHub

$ wrangler d1 create my-app-db

✅ Successfully created DB 'my-app-db'

그런데 왜 굳이? 세 가지 이유가 있어요.

• 자동화 — 반복 작업을 스크립트로 묶을 수 있음
• 재현성 — 같은 명령은 같은 결과. 클릭은 사람마다 다름
• 코드와 한 화면 — 에디터 옆 터미널에서 바로 실행. 컨텍스트 전환 없음

그리고 결정적인 이유 하나 더 — 배포는 거의 항상 CLI로만 가능합니다. 웹 대시보드에 "배포" 버튼이 있는 경우도 있지만, 그 버튼이 결국 CLI 명령을 호출하는 경우가 많아요.

window의 경우

버전 확인

---

Wrangler

by Cloudflare · Workers / D1 / R2 / Queues

Cloudflare가 공식적으로 만든 도구입니다. Cloudflare Workers, D1, R2, Queues, Pages 같은 자사 서비스를 전부 이 도구 하나로 다뤄요.

자주 쓰는 명령어

명령	하는 일
wrangler login	Cloudflare 계정 인증 (브라우저 1회)
wrangler d1 create <이름>	D1 데이터베이스(SQLite) 생성
wrangler r2 bucket create <이름>	R2 버킷 생성
wrangler queues create <이름>	Queue 생성
wrangler d1 execute … migration.sql	DB에 SQL 실행
wrangler deploy	Workers 코드 배포
wrangler dev	로컬 개발 서버

언제 쓰나

Cloudflare 인프라를 쓰기로 했다면 선택지가 없어요. 리소스를 만들면 UUID가 나오는데, 그걸 wrangler.jsonc에 적어줘야 코드에서 접근(env.DB, env.BUCKET 등)할 수 있습니다. 리소스 ID를 받기 위해서라도 한 번은 거치게 됩니다.

직접 써본 솔직한 인상

Node v22 이상을 요구해요. 저는 v20에서 v22로 올리는 게 첫 관문이었습니다. 환경 요구사항이 꽤 깐깐한 편이에요.

설치는 글로벌이 아니라 프로젝트 devDependencies에 넣고 npx wrangler로 쓰는 게 추천 방식. 버전을 프로젝트별로 고정할 수 있어서 그런 것 같습니다.

📸 자리 — wrangler.jsonc 또는 wrangler d1 create 출력 스크린샷

---

gh

by GitHub · 저장소 · PR · 이슈 · 워크플로우

GitHub가 만든 공식 CLI. 저장소 생성, 이슈, PR, 워크플로우 등 GitHub에서 일어나는 거의 모든 일을 터미널에서 처리할 수 있습니다.

자주 쓰는 명령어

명령	하는 일
gh auth login	GitHub 계정 인증
gh repo create <이름>	저장소 생성 (--private / --public)
gh repo view <소유자/이름>	저장소 정보 조회
gh pr create	PR 생성
gh pr list	PR 목록
gh issue list	이슈 목록

언제 쓰나

가장 일상적입니다. 새 저장소를 만들 때 웹 브라우저로 가서 양식 채우는 대신 한 줄로 끝나요.

gh repo create <owner>/<repo> --private

PR을 만들 때도 git push 후 gh pr create로 본문까지 한 번에 넣을 수 있어요. PR 본문을 작성할 때마다 매번 브라우저 띄우는 게 의외로 흐름을 끊는데, CLI는 그 흐름을 안 끊죠.

다중 계정 주의

gh는 여러 GitHub 계정을 동시에 로그인 상태로 둘 수 있는데, "활성 계정"이 하나만 있어요. 다른 계정 작업을 하다가 본 계정으로 돌아왔는데 토큰이 만료돼 있는 경우가 종종 있습니다. gh auth status로 자주 확인하는 습관이 좋아요.

---

Supabase CLI

by Supabase · DB · Edge Functions · 타입 생성

Supabase의 자사 도구. 데이터베이스 마이그레이션, Edge Functions 배포, 타입 자동 생성 등을 담당합니다.

자주 쓰는 명령어

명령	하는 일
supabase login	계정 인증
supabase init	프로젝트 초기 세팅
supabase start	로컬 Supabase 스택 실행 (Docker)
supabase db diff	스키마 변경 감지 → 마이그레이션 SQL 생성
supabase db push	마이그레이션을 원격 DB에 적용
supabase functions deploy	Edge Function 배포
supabase gen types typescript	스키마에서 TS 타입 자동 생성

언제 쓰나

Supabase를 백엔드로 쓴다면 거의 필수입니다. 특히 스키마 변경을 코드로 관리하고 싶을 때 가치가 커요. 로컬 DB에서 변경하고 → supabase db diff로 SQL 추출 → 원격에 push 하는 워크플로우가 매끄러워요.

이번 프로젝트에서는?

쓰지 않기로 결정했습니다. 처음엔 후보였는데, 이 프로젝트는 사용자당 이미지 40장 정도가 누적되는 구조라 Storage egress 비용이 부담이었어요. Cloudflare R2가 egress 무료라는 차이가 컸습니다.

다만 Supabase CLI 자체의 사용성은 셋 중 가장 잘 다듬어진 느낌이었어요. 로컬 Docker 스택으로 운영 환경을 재현하는 기능이 특히 인상적입니다.

---

셋을 한눈에 비교

	Wrangler	gh	Supabase CLI
만든 곳	Cloudflare	GitHub	Supabase
주된 용도	Workers / D1 / R2 등 인프라 관리	저장소 · PR · 이슈 관리	DB 스키마 · 함수 배포
로컬 개발 서버	wrangler dev	해당 없음	supabase start (Docker)
배포 기능	wrangler deploy (필수)	해당 없음	supabase functions deploy
Node 버전 요구	v22+	무관 (Go 바이너리)	무관 (Go 바이너리)
설치 권장	npx 또는 devDep	시스템 패키지 매니저	시스템 패키지 매니저

정리하며

CLI마다 그 회사가 가장 잘 하는 일이 다릅니다.

• Wrangler는 "인프라를 코드로"가 강점이에요. wrangler.jsonc 하나가 곧 인프라 정의입니다.
• gh는 "GitHub 워크플로우의 마찰을 줄이는 것"이 강점이고요.
• Supabase CLI는 "DB 변경을 안전하게 운영에 반영하는 것"이 강점입니다.

세 도구 모두 공통점이 있는데, 한 번 적응하면 브라우저로 돌아갈 일이 거의 없어진다는 점이에요. 처음 명령어 외울 때만 잠깐 답답하고, 그 뒤로는 쾌적합니다.

다음 글에선 실제로 Wrangler로 Cloudflare D1 + R2 + Queues를 세팅하는 과정을 적어볼 예정이에요.