<div id="readability-page-1" class="page"><div>
    <p><span>
        <time datetime="2026-08-14">
            2026-08-14</time>
    </span>
    
</p>
    
    <p>.gitignore와 .git/info/exclude의 차이에서 출발해, 비밀 파일을 암호화해서 커밋하는 git-secret과 SOPS, 비밀 유출을 탐지하는 gitleaks까지 정리합니다. 상황별로 어떤 도구를 쓰면 좋을지 비교합니다.</p>

  
    
    <div id="content">
       
<div id="preamble">
<p>API 키나 <code>.env</code> 파일 같은 비밀을 Git 저장소에서 다루는 방법은 크게 세 가지입니다. 아예 추적하지 않도록 무시하기, 암호화해서 커밋하기, 실수로 커밋되는 것을 탐지하기입니다. 각 방법마다 다른 도구가 발전해 왔습니다. 이 글에서는 Git의 무시 규칙인 `.gitignore`와 `.git/info/exclude`의 차이에서 출발해, 암호화 커밋 도구인 git-secret과 SOPS, 유출 스캐너인 gitleaks까지 정리합니다.</p>
</div>
<div>
<h2 id="gitignore_vs_gitinfoexclude">1. .gitignore vs .git/info/exclude</h2>
<div>
<p>둘 다 같은 문법으로 무시할 파일 패턴을 적지만, <strong>공유 여부</strong>가 다릅니다.</p>
<table>
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th></th>
<th><code>.gitignore</code></th>
<th><code>.git/info/exclude</code></th>
</tr>
</thead>
<tbody>
<tr>
<td><p>커밋 여부</p></td>
<td><p>커밋됨(공유)</p></td>
<td><p>커밋 안 됨(로컬 전용)</p></td>
</tr>
<tr>
<td><p>적용 범위</p></td>
<td><p>클론한 모두</p></td>
<td><p>내 클론만</p></td>
</tr>
<tr>
<td><p>용도</p></td>
<td><p>프로젝트 공통 무시 규칙</p></td>
<td><p>개인적인 무시 규칙</p></td>
</tr>
</tbody>
</table>
<div>
<ul>
<li>
<p><strong><code>.gitignore</code></strong>: 저장소에 커밋되어 모든 협업자에게 적용됩니다. 빌드 결과물, <code>node_modules/</code> 등 "누가 클론하든 무시해야 하는 것"을 적습니다.</p>
</li>
<li>
<p><strong><code>.git/info/exclude</code></strong>: <code>.git/</code> 안에 있어 커밋되지 않고 내 로컬 클론에만 적용됩니다. 개인 메모, 로컬 도구가 만드는 파일처럼 "나만 무시하고 싶은데 팀의 `.gitignore`를 더럽히긴 싫은 것"을 적습니다.</p>
</li>
<li>
<p>그 밖에 <code>git config core.excludesFile`로 지정하는 전역 무시 파일(보통 `~/.config/git/ignore</code>)도 있습니다. 이 파일은 내 머신의 모든 저장소에 적용됩니다.</p>
</li>
</ul>
</div>
<p>셋 사이에 우선순위나 효과 차이는 없습니다. 셋 다 이미 추적 중인(tracked) 파일에는 영향을 주지 않고, 아직 추적되지 않은 파일만 무시합니다.</p>
</div>
</div>
<div>
<h2 id="git_secret">2. git-secret</h2>
<div>
<p><a href="https://sobolevn.me/git-secret/">git-secret</a>은 저장소 안에 비밀 파일(API 키, <code>.env</code>, 인증서 등)을 <strong>암호화한 채로 커밋</strong>할 수 있게 해주는 서드파티 도구입니다. Git 자체 기능이 아니라 별도로 설치하는 bash 기반 도구이며, GPG 공개키 암호화를 씁니다.</p>
<div>
<h3 id="동작_방식">2.1. 동작 방식</h3>
<div>
<pre><code data-lang="bash">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 개인키로 원본 복원</code></pre>
</div>
<p>저장소가 공개되어도 암호화본만 노출되고, 등록된 GPG 키 소유자만 풀 수 있습니다. 팀원을 빼려면 <code>git secret killperson</code> 후 다시 <code>hide</code> 합니다. 단, 과거 커밋 히스토리의 암호화본은 그 사람이 여전히 풀 수 있으므로 <strong>비밀 자체를 교체</strong>해야 합니다.</p>
</div>
<div>
<h3 id="이름이_비슷한_다른_것들">2.2. 이름이 비슷한 다른 것들</h3>
<div>
<ul>
<li>
<p><strong><code>git-secrets</code></strong> (AWS 제작, 복수형): 정반대 목적입니다. 커밋 내용에 AWS 키 같은 비밀이 실수로 들어가는 것을 막는 pre-commit 검사기입니다.</p>
</li>
<li>
<p><strong>GitHub Secrets</strong>: GitHub Actions에서 쓰는 암호화된 환경 변수 저장 기능입니다.</p>
</li>
</ul>
</div>
</div>
<div>
<h3 id="한계">2.3. 한계</h3>
<p>GPG 키 관리 부담이 크고, 파일 전체를 통째로 암호화하므로 diff와 코드 리뷰가 불가능합니다. 요즘은 SOPS나 플랫폼 환경 변수(Vercel, Supabase 등), 시크릿 매니저(1Password, Doppler 등) 쪽이 더 널리 쓰입니다.</p>
</div>
</div>
</div>
<div>
<h2 id="sops_secrets_operations">3. SOPS (Secrets OPerationS)</h2>
<div>
<p><a href="https://github.com/getsops/sops">SOPS</a>는 2015년 Mozilla에서 시작해 2023년 CNCF에 기증된(Sandbox 프로젝트) 암호화 파일 편집 도구입니다. 현재는 getsops 커뮤니티가 관리하며, 2026년 6월 30일 릴리스된 3.13.2가 최신입니다(2026년 8월 기준).</p>
<div>
<h3 id="git_secret과의_결정적_차이_값만_암호화">3.1. git-secret과의 결정적 차이: 값만 암호화</h3>
<p>SOPS는 YAML, JSON, ENV, INI, BINARY 형식을 지원하며, 구조화된 파일에서는 <strong>키는 평문으로 두고 값만 암호화</strong>합니다.</p>
<div>
<pre><code data-lang="yaml"># 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..."</code></pre>
</div>
<p>그래서 어떤 설정 항목이 바뀌었는지 diff와 코드 리뷰가 가능합니다. 파일 전체가 불투명한 blob이 되는 git-secret과의 가장 큰 차이입니다.</p>
</div>
<div>
<h3 id="키_백엔드_age_pgp_kms_vault">3.2. 키 백엔드: age, PGP, KMS, Vault</h3>
<p>GPG에 묶인 git-secret과 달리 네 계열의 키 관리 방식을 지원합니다.</p>
<div>
<ul>
<li>
<p><strong>age</strong> (개인·소규모 팀에 권장 — GPG보다 훨씬 단순한 현대적 파일 암호화 도구)</p>
</li>
<li>
<p>PGP(GPG)</p>
</li>
<li>
<p>AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS</p>
</li>
<li>
<p>HashiCorp Vault</p>
</li>
</ul>
</div>
<p>클라우드 KMS를 쓰면 IAM으로 접근을 제어하므로, "퇴사자가 과거 히스토리를 풀 수 있는" 문제도 키 접근 권한 회수로 해결됩니다.</p>
</div>
<div>
<h3 id="기본_사용_흐름_age_기준">3.3. 기본 사용 흐름 (age 기준)</h3>
<div>
<ol>
<li>
<p>`age-keygen -o ~/.config/sops/age/keys.txt`로 키 쌍을 생성합니다.</p>
</li>
<li>
<p>`.sops.yaml`에 어떤 파일을 어떤 키로 암호화할지 규칙을 선언합니다.</p>
</li>
<li>
<p>`sops secrets/prod.yaml`로 파일을 편집하면 저장할 때 자동으로 암호화됩니다.</p>
</li>
</ol>
</div>
<div>
<p>.sops.yaml</p>
<div>
<pre><code data-lang="yaml">creation_rules:
  - path_regex: secrets/.*\.yaml
    age: age1abc...  # 공개키</code></pre>
</div>
</div>
<div>
<pre><code data-lang="bash">sops secrets/prod.yaml        # 편집기가 열리고, 저장하면 자동 암호화
sops -d secrets/prod.yaml     # 복호화 출력
sops -r -i secrets/prod.yaml  # 데이터 키 회전</code></pre>
</div>
<p><code>encrypted_regex</code> 옵션으로 특정 키(예: <code>password|token</code>)의 값만 골라 암호화하는 부분 암호화도 됩니다.</p>
</div>
<div>
<h3 id="생태계">3.4. 생태계</h3>
<p>Kubernetes GitOps 도구와 통합이 잘 되어 있습니다. Flux CD는 SOPS를 기본 지원하고, ArgoCD·Helm(helm-secrets)·Ansible(community.sops) 연동도 활발합니다.</p>
</div>
</div>
</div>
<div>
<h2 id="gitleaks">4. gitleaks</h2>
<div>
<p>앞의 두 도구가 비밀을 "안전하게 커밋"하는 쪽이라면, <a href="https://gitleaks.org/">gitleaks</a>는 반대로 <strong>비밀이 커밋되는 것을 찾아내고 막는</strong> 오픈소스 스캐너입니다. Go로 작성된 단일 바이너리이며, 가장 널리 쓰이는 비밀 탐지 SAST(Static Application Security Testing) 도구 중 하나입니다(GitHub 스타 2.7만+). 최신 릴리스는 2026년 3월의 v8.30.1입니다.</p>
<div>
<h3 id="무엇을_하나">4.1. 무엇을 하나</h3>
<div>
<ul>
<li>
<p>AWS 키, GitHub 토큰, Slack 웹훅 등 흔한 비밀 패턴에 대한 <strong>내장 룰</strong>로 저장소를 스캔합니다. 정규식 + 엔트로피(무작위성) 검사를 조합합니다.</p>
</li>
<li>
<p>현재 파일뿐 아니라 <strong>git 히스토리 전체</strong>를 훑습니다. 지금은 지운 비밀이라도 과거 커밋에 남아 있으면 잡아냅니다.</p>
</li>
<li>
<p>결과는 JSON, CSV, JUnit, SARIF 형식으로 출력할 수 있어 CI 연동이 쉽습니다.</p>
</li>
</ul>
</div>
</div>
<div>
<h3 id="기본_사용법">4.2. 기본 사용법</h3>
<div>
<pre><code data-lang="bash">gitleaks git .            # 저장소의 커밋 히스토리 전체 스캔
gitleaks dir .            # 히스토리 없이 현재 디렉터리 파일만 스캔
gitleaks git . --pre-commit --staged   # 커밋 직전 스테이징된 변경만 검사</code></pre>
</div>
<div>
<ul>
<li>
<p><strong>pre-commit 훅</strong>으로 걸어두면 비밀이 히스토리에 들어가기 전에 차단합니다. 사후에 발견해서 히스토리를 세척하는 것보다 훨씬 쌉니다.</p>
</li>
<li>
<p>CI에는 공식 GitHub Action(<code>gitleaks/gitleaks-action</code>)이 있습니다.</p>
</li>
<li>
<p>오탐은 <code>.gitleaks.toml`의 allowlist나 해당 줄의 `# gitleaks:allow</code> 주석으로 무시합니다. v8.28.0부터는 주 룰과 보조 룰이 근접 거리 안에서 함께 매칭돼야 탐지로 치는 composite rules로 오탐을 줄일 수 있습니다.</p>
</li>
</ul>
</div>
</div>
<div>
<h3 id="알아둘_점_개발은_후속작으로">4.3. 알아둘 점: 개발은 후속작으로</h3>
<p>메인테이너(Zach Rice)는 gitleaks를 기능 완성(feature-complete) 상태로 선언했고, 앞으로는 보안 패치만 나옵니다. 신규 개발은 같은 팀이 만드는 후속작 <strong>Betterleaks</strong>로 옮겨갔습니다. Betterleaks는 CEL(Common Expression Language) 기반 룰 검증을 도입해 CredData 데이터셋 기준 98.6% 재현율을 내세웁니다. 다만 gitleaks도 여전히 사실상 표준으로 널리 쓰이고 있습니다.</p>
</div>
<div>
<h3 id="git_secrets와의_비교">4.4. git-secrets와의 비교</h3>
<p>2절에서 언급한 AWS의 `git-secrets`와 목적이 같지만, gitleaks가 룰이 훨씬 풍부합니다(수백 개 내장 패턴). 히스토리 스캔, 리포트 형식, 유지보수 활성도 면에서도 앞서서, 요즘은 gitleaks(또는 trufflehog) 쪽이 표준에 가깝습니다.</p>
</div>
</div>
</div>
<div>
<h2 id="정리_무엇을_쓸까">5. 정리: 무엇을 쓸까</h2>
<div>
<table>
<colgroup>
<col>
<col>
</colgroup>
<thead>
<tr>
<th>상황</th>
<th>권장</th>
</tr>
</thead>
<tbody>
<tr>
<td><p>개인 로컬에서만 무시하고 싶은 파일</p></td>
<td><p><code>.git/info/exclude</code></p></td>
</tr>
<tr>
<td><p>팀 공통으로 무시할 파일</p></td>
<td><p><code>.gitignore</code></p></td>
</tr>
<tr>
<td><p>저장소에 비밀을 암호화해 커밋 (개인·소규모)</p></td>
<td><p>SOPS + age</p></td>
</tr>
<tr>
<td><p>저장소에 비밀을 커밋, 클라우드 IAM 연동</p></td>
<td><p>SOPS + KMS</p></td>
</tr>
<tr>
<td><p>비밀을 아예 커밋하지 않기</p></td>
<td><p>플랫폼 환경 변수(Vercel 등), 시크릿 매니저</p></td>
</tr>
<tr>
<td><p>비밀이 실수로 커밋되는 것 방지</p></td>
<td><p>gitleaks(pre-commit 훅 + CI)</p></td>
</tr>
</tbody>
</table>
</div>
</div>
<div>
<h2 id="참고_자료">6. 참고 자료</h2>

</div>
    </div>

    

    
</div></div>

JBake

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: 저장소에 커밋되어 모든 협업자에게 적용됩니다. 빌드 결과물, 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)
6. 참고 자료
getsops/sops (GitHub)
SOPS 공식 문서
SOPS 릴리스
Ansible community.sops 가이드
Gitleaks 공식 사이트
gitleaks/gitleaks 릴리스
Betterleaks 소개 (BleepingComputer)
이 포스트는 Claude Code와 정상혁이 함께 작성했습니다.

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

댓글