Git의 무시 규칙과 비밀 관리 도구: .gitignore부터 SOPS, gitleaks까지

.gitignore와 .git/info/exclude의 차이에서 출발해, 비밀 파일을 암호화해서 커밋하는 git-secret과 SOPS, 비밀 유출을 탐지하는 gitleaks까지 정리합니다. 상황별로 어떤 도구를 쓰면 좋을지 비교합니다.

Table of Contents

1. .gitignore vs .git/info/exclude
2. git-secret
3. SOPS (Secrets OPerationS)
4. gitleaks
5. 정리: 무엇을 쓸까
6. 참고 자료

API 키나 .env 파일 같은 비밀을 Git 저장소에서 다루는 방법은 크게 세 가지입니다. 아예 추적하지 않도록 무시하기, 암호화해서 커밋하기, 실수로 커밋되는 것을 탐지하기입니다. 각 방법마다 다른 도구가 발전해 왔습니다. 이 글에서는 Git의 무시 규칙인 `.gitignore`와 `.git/info/exclude`의 차이에서 출발해, 암호화 커밋 도구인 git-secret과 SOPS, 유출 스캐너인 gitleaks까지 정리합니다.

1. .gitignore vs .git/info/exclude

둘 다 같은 문법으로 무시할 파일 패턴을 적지만, 공유 여부가 다릅니다.

.gitignore .git/info/exclude

	`.gitignore`	`.git/info/exclude`
커밋 여부	커밋됨(공유)	커밋 안 됨(로컬 전용)
적용 범위	클론한 모두	내 클론만
용도	프로젝트 공통 무시 규칙	개인적인 무시 규칙

커밋 여부

커밋됨(공유)

커밋 안 됨(로컬 전용)

적용 범위

클론한 모두

내 클론만

용도

프로젝트 공통 무시 규칙

개인적인 무시 규칙

.gitignore: 저장소에 커밋되어 모든 협업자에게 적용됩니다. 빌드 결과물, node_modules/ 등 "누가 클론하든 무시해야 하는 것"을 적습니다.
.git/info/exclude: .git/ 안에 있어 커밋되지 않고 내 로컬 클론에만 적용됩니다. 개인 메모, 로컬 도구가 만드는 파일처럼 "나만 무시하고 싶은데 팀의 `.gitignore`를 더럽히긴 싫은 것"을 적습니다.
그 밖에 git config core.excludesFile`로 지정하는 전역 무시 파일(보통 `~/.config/git/ignore)도 있습니다. 이 파일은 내 머신의 모든 저장소에 적용됩니다.

셋 사이에 우선순위나 효과 차이는 없습니다. 셋 다 이미 추적 중인(tracked) 파일에는 영향을 주지 않고, 아직 추적되지 않은 파일만 무시합니다.

2. git-secret

git-secret은 저장소 안에 비밀 파일(API 키, .env, 인증서 등)을 암호화한 채로 커밋할 수 있게 해주는 서드파티 도구입니다. Git 자체 기능이 아니라 별도로 설치하는 bash 기반 도구이며, GPG 공개키 암호화를 씁니다.

2.1. 동작 방식

git secret init                 # .gitsecret/ 디렉터리 생성
git secret tell you@example.com # 복호화를 허용할 사람의 GPG 공개키 등록
git secret add .env             # 비밀 파일 지정(원본은 자동으로 .gitignore에 추가)
git secret hide                 # 등록된 공개키로 암호화한 .env.secret 생성 → 이것만 커밋
git secret reveal               # 클론한 팀원이 자기 GPG 개인키로 원본 복원

저장소가 공개되어도 암호화본만 노출되고, 등록된 GPG 키 소유자만 풀 수 있습니다. 팀원을 빼려면 git secret killperson 후 다시 hide 합니다. 단, 과거 커밋 히스토리의 암호화본은 그 사람이 여전히 풀 수 있으므로 비밀 자체를 교체해야 합니다.

2.2. 이름이 비슷한 다른 것들

git-secrets (AWS 제작, 복수형): 정반대 목적입니다. 커밋 내용에 AWS 키 같은 비밀이 실수로 들어가는 것을 막는 pre-commit 검사기입니다.
GitHub Secrets: GitHub Actions에서 쓰는 암호화된 환경 변수 저장 기능입니다.

2.3. 한계

GPG 키 관리 부담이 크고, 파일 전체를 통째로 암호화하므로 diff와 코드 리뷰가 불가능합니다. 요즘은 SOPS나 플랫폼 환경 변수(Vercel, Supabase 등), 시크릿 매니저(1Password, Doppler 등) 쪽이 더 널리 쓰입니다.

3. SOPS (Secrets OPerationS)

SOPS는 2015년 Mozilla에서 시작해 2023년 CNCF에 기증된(Sandbox 프로젝트) 암호화 파일 편집 도구입니다. 현재는 getsops 커뮤니티가 관리하며, 2026년 6월 30일 릴리스된 3.13.2가 최신입니다(2026년 8월 기준).

3.1. git-secret과의 결정적 차이: 값만 암호화

SOPS는 YAML, JSON, ENV, INI, BINARY 형식을 지원하며, 구조화된 파일에서는 키는 평문으로 두고 값만 암호화합니다.

# SOPS로 암호화한 YAML — 구조가 보인다
database:
    host: ENC[AES256_GCM,data:Tr7o...,type:str]
    password: ENC[AES256_GCM,data:CwE4...,type:str]
sops:
    age: ...
    lastmodified: "2026-08-01T..."

그래서 어떤 설정 항목이 바뀌었는지 diff와 코드 리뷰가 가능합니다. 파일 전체가 불투명한 blob이 되는 git-secret과의 가장 큰 차이입니다.

3.2. 키 백엔드: age, PGP, KMS, Vault

GPG에 묶인 git-secret과 달리 네 계열의 키 관리 방식을 지원합니다.

age (개인·소규모 팀에 권장 — GPG보다 훨씬 단순한 현대적 파일 암호화 도구)
PGP(GPG)
AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS
HashiCorp Vault

클라우드 KMS를 쓰면 IAM으로 접근을 제어하므로, "퇴사자가 과거 히스토리를 풀 수 있는" 문제도 키 접근 권한 회수로 해결됩니다.

3.3. 기본 사용 흐름 (age 기준)

`age-keygen -o ~/.config/sops/age/keys.txt`로 키 쌍을 생성합니다.
`.sops.yaml`에 어떤 파일을 어떤 키로 암호화할지 규칙을 선언합니다.
`sops secrets/prod.yaml`로 파일을 편집하면 저장할 때 자동으로 암호화됩니다.

.sops.yaml

creation_rules:
  - path_regex: secrets/.*\.yaml
    age: age1abc...  # 공개키

sops secrets/prod.yaml        # 편집기가 열리고, 저장하면 자동 암호화
sops -d secrets/prod.yaml     # 복호화 출력
sops -r -i secrets/prod.yaml  # 데이터 키 회전

encrypted_regex 옵션으로 특정 키(예: password|token)의 값만 골라 암호화하는 부분 암호화도 됩니다.

3.4. 생태계

Kubernetes GitOps 도구와 통합이 잘 되어 있습니다. Flux CD는 SOPS를 기본 지원하고, ArgoCD·Helm(helm-secrets)·Ansible(community.sops) 연동도 활발합니다.

4. gitleaks

앞의 두 도구가 비밀을 "안전하게 커밋"하는 쪽이라면, gitleaks는 반대로 비밀이 커밋되는 것을 찾아내고 막는 오픈소스 스캐너입니다. Go로 작성된 단일 바이너리이며, 가장 널리 쓰이는 비밀 탐지 SAST(Static Application Security Testing) 도구 중 하나입니다(GitHub 스타 2.7만+). 최신 릴리스는 2026년 3월의 v8.30.1입니다.

4.1. 무엇을 하나

AWS 키, GitHub 토큰, Slack 웹훅 등 흔한 비밀 패턴에 대한 내장 룰로 저장소를 스캔합니다. 정규식 + 엔트로피(무작위성) 검사를 조합합니다.
현재 파일뿐 아니라 git 히스토리 전체를 훑습니다. 지금은 지운 비밀이라도 과거 커밋에 남아 있으면 잡아냅니다.
결과는 JSON, CSV, JUnit, SARIF 형식으로 출력할 수 있어 CI 연동이 쉽습니다.

4.2. 기본 사용법

gitleaks git .            # 저장소의 커밋 히스토리 전체 스캔
gitleaks dir .            # 히스토리 없이 현재 디렉터리 파일만 스캔
gitleaks git . --pre-commit --staged   # 커밋 직전 스테이징된 변경만 검사

pre-commit 훅으로 걸어두면 비밀이 히스토리에 들어가기 전에 차단합니다. 사후에 발견해서 히스토리를 세척하는 것보다 훨씬 쌉니다.
CI에는 공식 GitHub Action(gitleaks/gitleaks-action)이 있습니다.
오탐은 .gitleaks.toml`의 allowlist나 해당 줄의 `# gitleaks:allow 주석으로 무시합니다. v8.28.0부터는 주 룰과 보조 룰이 근접 거리 안에서 함께 매칭돼야 탐지로 치는 composite rules로 오탐을 줄일 수 있습니다.

4.3. 알아둘 점: 개발은 후속작으로

메인테이너(Zach Rice)는 gitleaks를 기능 완성(feature-complete) 상태로 선언했고, 앞으로는 보안 패치만 나옵니다. 신규 개발은 같은 팀이 만드는 후속작 Betterleaks로 옮겨갔습니다. Betterleaks는 CEL(Common Expression Language) 기반 룰 검증을 도입해 CredData 데이터셋 기준 98.6% 재현율을 내세웁니다. 다만 gitleaks도 여전히 사실상 표준으로 널리 쓰이고 있습니다.

4.4. git-secrets와의 비교

2절에서 언급한 AWS의 `git-secrets`와 목적이 같지만, gitleaks가 룰이 훨씬 풍부합니다(수백 개 내장 패턴). 히스토리 스캔, 리포트 형식, 유지보수 활성도 면에서도 앞서서, 요즘은 gitleaks(또는 trufflehog) 쪽이 표준에 가깝습니다.

5. 정리: 무엇을 쓸까

상황 권장

상황	권장
개인 로컬에서만 무시하고 싶은 파일	`.git/info/exclude`
팀 공통으로 무시할 파일	`.gitignore`
저장소에 비밀을 암호화해 커밋 (개인·소규모)	SOPS + age
저장소에 비밀을 커밋, 클라우드 IAM 연동	SOPS + KMS
비밀을 아예 커밋하지 않기	플랫폼 환경 변수(Vercel 등), 시크릿 매니저
비밀이 실수로 커밋되는 것 방지	gitleaks(pre-commit 훅 + CI)

개인 로컬에서만 무시하고 싶은 파일

.git/info/exclude

팀 공통으로 무시할 파일

.gitignore

저장소에 비밀을 암호화해 커밋 (개인·소규모)

SOPS + age

저장소에 비밀을 커밋, 클라우드 IAM 연동

SOPS + KMS

비밀을 아예 커밋하지 않기

플랫폼 환경 변수(Vercel 등), 시크릿 매니저

비밀이 실수로 커밋되는 것 방지

gitleaks(pre-commit 훅 + CI)

6. 참고 자료

이 포스트는 Claude Code와 정상혁이 함께 작성했습니다.