[오픈대화] 바이브코딩과 GitHub — 저장소 보안, .gitignore, 기술 스택 선택 가이드

클로드코드로 개발을 시작했다면, 이제 GitHub를 어떻게 활용해야 하는지 알아봅시다. 이 글에서는 저장소 보안 설정부터 기술 스택 선택, 서비스 홍보까지 실전에서 바로 쓸 수 있는 내용을 다룹니다.

1. GitHub에서 가장 중요한 두 가지 기능

클로드코드로 개발하는 우리 입장에서 GitHub에서 가장 중요한 기능은 두 가지입니다.

Push (푸시) — 코드 백업 및 버전 관리

코드가 업데이트될 때마다 GitHub에 올려두면:

버전별로 저장 → 이전 버전으로 언제든 되돌아갈 수 있음
백업 → 컴퓨터가 고장나도 코드는 안전
히스토리 관리 → 언제 무엇을 바꿨는지 기록이 남음

Actions (액션) — 자동화 배포

코드를 올리면 자동으로 배포까지 처리해주는 기능입니다. 코드를 push하면 자동으로 웹사이트가 업데이트되는 식으로, 여러 배포를 한 번에 자동으로 처리할 수 있어요.

2. 저장소 공개 vs 비공개 — 지금 당장 확인하세요

GitHub 저장소를 처음 만들면 공개(Public) 또는 비공개(Private) 중 선택합니다. 기본값이 공개인 경우가 있어서 꼭 확인해야 합니다.

공개 저장소 (Public)

전 세계 누구나 내 코드를 볼 수 있음
다른 사람들이 코드를 가져다 쓸 수 있음

비공개 저장소 (Private)

나와 초대한 사람만 볼 수 있음
개인 서비스 개발 시 기본 원칙

⚠️ 왜 중요한가?

요즘 바이브코딩으로 비개발자들이 GitHub를 처음 사용하면서, 저장소가 공개로 설정된 줄도 모르고 사용하는 경우가 많습니다. 이를 악용해서 민감한 API 토큰이나 개인정보를 찾아다니는 사람들도 있습니다.

저장소 비공개로 변경하는 방법:

클로드에게 이렇게 요청하세요:

내 GitHub 저장소를 비공개로 변경해줘

또는 GitHub 웹사이트에서:

저장소 → Settings → Danger Zone → Change repository visibility → Private

Mac / Windows 공통 — GitHub 웹사이트에서 직접 변경하거나 클로드에게 요청하면 됩니다.

언제 공개로 해도 될까?

오픈소스로 모든 소스를 공개하고 싶을 때
MCP처럼 누구나 사용하게 하고 싶을 때
서비스 소개 README만 있는 홍보용 레포일 때

3. API 키와 민감한 정보 — .gitignore로 보호하기

저장소를 비공개로 바꿨다고 안심하면 안 됩니다. 코드 안에 API 키가 직접 들어있으면 비공개 저장소라도 위험합니다.

올바른 방법: 환경변수 파일로 분리하기

1단계: 민감 정보는 .env.local 파일에 저장

# .env.local
NEXT_PUBLIC_API_KEY=여기에_api키
FIREBASE_SECRET=여기에_시크릿

2단계: .gitignore에 등록해서 GitHub에 올라가지 않게 처리

.gitignore 파일에 아래 내용이 있어야 합니다:

.env.local
.env
.env.production

클로드코드로 프로젝트를 만들면 보통 자동으로 설정해주지만, 한번 확인해두는 게 좋아요.

클로드에게 확인 요청:

.gitignore에 .env.local이 포함되어 있는지 확인해줘

절대 하면 안 되는 것

// ❌ 이렇게 코드에 직접 넣으면 안 됩니다
const apiKey = "sk-실제api키값";

비공개 저장소라도 코드에 직접 들어가면 보안 위험이 있습니다.

4. 기술 스택 선택 — 웹과 앱을 함께 만들 때

Firebase의 큰 장점: 프로젝트별 독립 무료 할당량

Firebase는 프로젝트를 여러 개 만들어도 각 프로젝트마다 무료 할당량이 별도로 주어집니다. 통합 계산이 아닌 독립 계산이에요.

→ 초기 단계에서는 여러 서비스를 만들어도 사실상 무료로 사용 가능

Next.js + Flutter 병행 vs Flutter 통합

클로드에게 스택 변경을 요청하면 이런 제안을 받을 수 있습니다:

"Next.js(웹) + Flutter(앱) 병행 구조도 선택지야. 백엔드(Firebase + Cloud Functions)만 공유하면 돼."

이 제안이 틀린 건 아니지만, 웹과 앱을 별개로 두 개 만들라는 뜻입니다.

구조	의미	장점	단점
Next.js + Flutter 병행	웹 따로, 앱 따로	웹 SEO 최적화	두 개를 각각 만들어야 함
Flutter 통합	웹+앱 하나의 코드	통합 UI, 개발 효율	웹 SEO 상대적으로 불리

어떤 걸 선택할까?

앱이 메인이고 웹은 부가적인 경우 → Flutter 통합 추천

웹 검색 유입이 중요한 경우 → Next.js + Flutter 병행

실제 많이 쓰는 패턴

많은 서비스들이 이렇게 조합합니다:

JS(Next.js) 랜딩페이지: "지금 다운로드하세요!" 같은 앱 소개 사이트 — SEO 특화
Flutter: 앱 + 앱과 동일한 사용성의 웹
Firebase + Cloud Functions: 두 프론트엔드가 공유하는 백엔드

5. GitHub README 소개 페이지 — 홍보 수단으로 활용하기

서비스를 만들었다면 홍보도 중요합니다. 코드 저장소는 비공개로 두면서, 서비스 소개만 담은 공개 레포를 따로 만들 수 있어요.

"서비스 만드는 것보다 사람들이 사용하게 만드는 게 더 힘들어요. 이런 거 하나라도 더 홍보 수단으로 만들어두는 게 좋아요."

오픈소스 레포 vs README 소개 레포

종류	내용	예시
오픈소스 레포	모든 소스코드 공개	Claude-Code-Usage-Monitor
README 소개 레포	README.md 하나만 있는 서비스 소개	github.com/smy383/ttapp-releases

README 소개 레포는 소스코드 없이 서비스 소개글, 스크린샷, 다운로드 링크 등만 담습니다.

만드는 방법