
.gitignore 생성기로 저장소 깔끔하게 관리하기
📷 Pixabay / Pexels.gitignore 생성기로 저장소 깔끔하게 관리하기
.gitignore 파일을 직접 작성하는 건 번거롭고, 보통은 Stack Overflow에서 복사하게 되죠. 더 좋은 방법이 있습니다.
대부분의 개발자가 .gitignore를 어떻게 처리하는지 솔직하게 얘기해봅시다. 새 프로젝트를 시작하면서 .gitignore 추가를 잊고, node_modules나 .env 파일을 처음 몇 번의 커밋에 밀어 넣은 뒤 허둥지둥 수습합니다. 아니면 "gitignore node"를 검색해서 Stack Overflow에서 몇 년 전에 올라온 답변을 복사하죠. 대체로 잘 되긴 하는데, 본인 환경에 맞지 않는 부분은 놓치기 마련입니다.
더 나은 방법이 있습니다. 30초면 됩니다. 하지만 먼저 .gitignore가 왜 중요한지, 잘못 설정했을 때 무슨 일이 생기는지부터 짚고 넘어가겠습니다.
.gitignore가 생각보다 중요한 이유
저장소를 깔끔하게 유지하는 게 당연한 이유겠지만, 그것보다 덜 명확하면서도 실제로 치명적인 이유들이 있습니다.
보안. .env 파일을 실수로 커밋하는 건 API 키와 데이터베이스 비밀번호 같은 시크릿이 GitHub에 올라가는 가장 흔한 경로 중 하나입니다. 코드가 공개 저장소에 올라가는 순간, 자동화된 봇이 몇 분 안에 그 키를 스캔합니다. GitHub가 알림을 보내지만 그때는 이미 키가 노출된 뒤입니다. .gitignore로 미리 막는 게 사후 수습보다 훨씬 낫습니다.
성능. 빌드 결과물, 로그 파일, 바이너리 에셋으로 부풀어 오른 저장소는 클론도 느리고, 작업 자체가 고통스럽습니다. node_modules가 히스토리에 들어가면 간단히 지울 방법이 없습니다. git rebase나 filter-branch 없이는 모든 기여자에게 영향을 줍니다.
불필요한 노이즈 제거. macOS의 .DS_Store, Windows의 Thumbs.db, 에디터 임시 파일들은 diff를 지저분하게 만들고 서로 다른 환경을 쓰는 팀원들 사이에서 쓸데없는 충돌을 만듭니다.
제대로 된 .gitignore는 이 모든 것을 처리합니다. 문제는 "제대로"가 기술 스택, OS, 에디터, 사용 도구에 따라 다르다는 것입니다. Stack Overflow에서 복사해도 되긴 하는데 뭔가 빠집니다 — 그 답변은 특정 년도에 특정 설정을 가진 누군가를 위해 쓰여진 것이니까요.
자주 저지르는 실수들
node_modules를 너무 늦게 gitignore에 추가하는 경우
거의 통과의례처럼 흔한 실수입니다. npm init하고 코드 좀 짜고, git add . 하고, git commit — 그러면 80MB짜리 node_modules가 저장소 히스토리에 영원히 남습니다.
이후에 .gitignore에 node_modules/를 추가해도, 이미 추적 중인 파일은 자동으로 무시되지 않습니다. 명시적으로 추적 해제해야 합니다:
git rm -r --cached node_modules
git commit -m "node_modules 추적 중단"
--cached 플래그가 핵심입니다. 파일시스템에서 지우지 않고 Git 인덱스(스테이징 영역)에서만 제거합니다. 이후에 .gitignore에 node_modules/를 추가하면 제대로 동작합니다.
.env 파일 커밋
이게 정말 위험한 경우입니다. 실제 자격증명이 담긴 .env 파일은 절대 원격 저장소에 올라가면 안 됩니다. 해결책은 간단합니다: 파일을 만들기 전에 .gitignore에 추가하세요. 더 좋은 방법은 필요한 환경 변수 목록을 빈 값이나 예시 값으로 채운 .env.example 파일을 커밋하는 것입니다.
# .gitignore
.env
.env.local
.env.production
.env.*.local
.env.example이나 .env.template은 .gitignore에 추가하면 안 됩니다 — 이것들은 팀원들과 공유하기 위한 것입니다.
너무 많이 무시하는 경우
반대 문제도 있습니다. 와일드카드를 너무 과하게 쓰다가 커밋해야 할 설정 파일, 마이그레이션 스크립트, 스키마 파일까지 블로킹해버린 .gitignore를 본 적이 있습니다. *.config는 합리적으로 보이지만 webpack.config.js와 jest.config.js까지 무시해버립니다.
결과물은 무시하고, 입력 파일은 무시하지 마세요.
OS 전용 파일 미처리
.DS_Store는 macOS가 폴더 표시 설정을 저장하는 방식입니다. Thumbs.db는 Windows의 썸네일 캐시입니다. 둘 다 저장소에 있으면 안 됩니다. 글로벌 gitignore로 처리하는 것이 가장 깔끔하지만(뒤에서 설명), 프로젝트 레벨에서도 커버하는 게 안전망이 됩니다.
.gitignore 생성기 사용법
빈 파일에서 시작하거나 오래된 Stack Overflow 답변을 복사하는 대신, .gitignore 생성기를 사용하면 실제 스택에 맞는 완전한 .gitignore를 1분 안에 만들 수 있습니다.
사용 방법:
- .gitignore 생성기를 엽니다
- 언어/프레임워크 선택 (Node.js, Python, Go, Rust, Java 등)
- 운영체제 선택 (macOS, Windows, Linux)
- 에디터 또는 IDE 선택 (VS Code, JetBrains, Vim 등)
- 추가 도구 선택 (Docker, Terraform 등)
- 생성된 결과를 복사해서 프로젝트의
.gitignore에 붙여 넣기
생성된 결과에는 JetBrains의 .idea/ 디렉토리, VS Code의 .vscode/ 폴더(공유 설정 파일을 위한 예외 포함), macOS .DS_Store, Python의 __pycache__와 .pytest_cache, 빌드 디렉토리, 로그 파일, 런타임 결과물 같은 것들이 모두 포함되어 있습니다.
마법이 아닙니다 — 이 패턴들은 커뮤니티가 유지 관리하는 것들입니다(주로 github.com/github/gitignore의 템플릿 기반). 생성기는 단순히 어떤 템플릿을 어떻게 조합할지 알 필요 없이 스택에 맞는 올바른 조합을 만들어줍니다.
이미 추적 중인 파일 처리
.gitignore에 무언가를 추가하는 것은 이후 추적만 막습니다. 이미 커밋된 파일은 명시적으로 추적 해제하기 전까지 Git이 계속 추적합니다.
명령어 패턴은 다음과 같습니다:
# 단일 파일 추적 해제
git rm --cached 파일/경로
# 전체 디렉토리 추적 해제
git rm -r --cached 디렉토리/경로/
# 전체를 추적 해제하고 현재 .gitignore 기준으로 재추가
git rm -r --cached .
git add .
git commit -m ".gitignore 규칙을 추적 파일에 적용"
마지막 방법 — 인덱스에서 모든 것을 제거하고 재추가 — 은 핵 옵션이지만, .gitignore가 오랫동안 불완전했다면 가장 깔끔한 해결책입니다. 실제 파일은 건드리지 않고 현재 .gitignore를 기준으로 추적 항목을 재설정합니다.
한 가지 중요한 점: 이 방법은 앞으로의 저장소에만 영향을 미칩니다. 이전 커밋에서 커밋된 파일은 여전히 git 히스토리에 남아 있습니다. 시크릿을 커밋했고 히스토리에서 지워야 한다면, git filter-branch나 git-filter-repo 같은 도구를 사용하고 강제 푸시해야 하는 더 복잡한 과정이 필요합니다.
글로벌 gitignore로 개인 설정 관리하기
대부분의 개발자가 모르거나 잊고 있는 패턴: 글로벌 gitignore 파일입니다.
프로젝트의 .gitignore에는 팀 전체와 관련된 패턴을 넣어야 합니다. 하지만 일부는 개인 설정에 관한 것들입니다 — 에디터, OS, 워크플로우 도구. 모든 프로젝트의 .gitignore에 .DS_Store를 추가하는 방법도 있지만, 개인 선호도로 프로젝트 파일이 지저분해집니다. 더 깔끔한 해결책은 글로벌 gitignore입니다.
설정 방법:
# 파일 생성
touch ~/.gitignore_global
# git이 사용하도록 설정
git config --global core.excludesFile ~/.gitignore_global
그런 다음 개인 무시 항목을 ~/.gitignore_global에 추가합니다:
# macOS
.DS_Store
.AppleDouble
.LSOverride
# Windows
Thumbs.db
ehthumbs.db
Desktop.ini
# VS Code
.vscode/
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
# JetBrains
.idea/
*.iml
*.iws
# Vim
*.swp
*.swo
*~
한번 설정하면 Git이 자신의 모든 저장소에 이 패턴을 자동으로 적용합니다. 프로젝트 .gitignore에 .DS_Store를 다시는 추가할 필요가 없습니다.
구분법: 프로젝트 .gitignore는 팀 전체에 도움이 되는 프로젝트 관련 무시 항목, 글로벌 .gitignore는 본인에게만 해당하는 에디터/OS 설정.
와일드카드가 역효과를 낼 때
.gitignore 패턴의 와일드카드는 강력하지만 주의가 필요합니다.
*는 슬래시를 제외한 모든 것과 매칭됩니다. *.log는 프로젝트의 모든 .log 파일을 무시합니다. 대부분 원하는 동작입니다.
**는 슬래시를 포함한 모든 것과 매칭됩니다. **/logs는 프로젝트 어디서든 logs/ 디렉토리를 무시합니다. 중첩 디렉토리에 유용합니다.
앞의 /는 패턴을 프로젝트 루트에 고정합니다. /node_modules는 루트의 node_modules만 무시합니다. 슬래시 없이 node_modules를 쓰면 어디서든 무시합니다.
뒤의 /는 디렉토리를 지정합니다. build/는 build라는 디렉토리만 무시합니다. 슬래시 없이 build를 쓰면 build라는 파일도 무시합니다.
역효과가 나는 경우: 예상보다 더 많이 걸리는 광범위한 패턴. 흔한 예시:
**/build는 커밋하고 싶은docs/build나examples/build를 포함해 어디서나 모든build디렉토리를 무시합니다*.json은package.json도 무시합니다 (이러면 안 됩니다)
의심스러울 때는 더 광범위하게보다는 더 구체적으로 작성하세요. .gitignore 업데이트 후에는 git status로 실제로 어떤 효과가 있는지 확인하세요.
Node.js + Docker + VS Code 완전한 .gitignore 예시
흔한 설정에 대한 실제 .gitignore 예시입니다: Node.js 앱, Docker 컨테이너화, VS Code 에디터, macOS 사용하지만 팀원들이 다양한 플랫폼 사용.
# Node.js
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
.pnpm-store/
.npm
# 빌드 결과물
dist/
build/
out/
.next/
.nuxt/
.cache/
# 환경 파일
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
# (.env.example은 커밋할 것)
# 런타임 및 로그
logs/
*.log
pids/
*.pid
*.seed
*.pid.lock
# 테스팅
coverage/
.nyc_output/
.jest-cache/
# TypeScript
*.tsbuildinfo
# Docker
.docker/
# VS Code
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
*.code-workspace
# macOS
.DS_Store
.AppleDouble
.LSOverride
# Linux
*~
# Windows
Thumbs.db
ehthumbs.db
Desktop.ini
$RECYCLE.BIN/
첫 커밋 전에 확인하기
.gitignore를 설정하기 가장 좋은 시점은 첫 git add . 이전입니다. 새 프로젝트를 시작할 때:
git init- 즉시 .gitignore 추가 (생성기나 템플릿 사용)
- 그 다음 파일 추가 시작
이 순서대로 하면 "이미 추적됨" 문제가 아예 발생하지 않습니다. 기존 프로젝트에서 취약한 .gitignore를 발견했다면, 저장소가 아직 젊을 때 초기에 감사하고 개선하는 것이 6개월 치 커밋이 쌓인 후에 하는 것보다 훨씬 덜 고통스럽습니다.
.gitignore 생성기는 탄탄한 출발점을 얻는 가장 빠른 방법입니다. 스택에 맞게 실행하고, 필요한 프로젝트별 패턴을 추가하고, 개인 에디터 설정은 글로벌 gitignore로 처리하세요. 10분의 설정이 나중에 수 시간의 수습을 막아줍니다.
깔끔한 .gitignore 워크플로우와 함께 유용한 도구들:
- UUID 생성기 — 환경 설정에서 고유 ID 생성에 유용
- Base64 인코더/디코더 — 환경 파일의 인코딩된 시크릿 처리에 자주 사용
- JSON 포매터 — 설정 파일 가독성 유지에 유용