개발자들은 여전히 API 토큰, 비밀번호, 자격 증명을 코드나 .env 파일에 직접 넣고 Git에 푸시합니다. 사이드 프로젝트와 프로덕션 모두에서 마찬가지입니다.
이유는 단순합니다. 자동화와 배포 워크플로에 시크릿을 넘길 제대로 된 방법이 없으면 Git이 유일하게 믿을 만한 선택처럼 보입니다. «나중에 정리하지.» 하지만 Git에 한 번 들어간 것은 진짜로 사라지지 않습니다.
Git이 시크릿에 위험한 이유
Git은 버전 관리 시스템입니다. 커밋된 모든 것이 히스토리에 남습니다. 최신 커밋에서 토큰을 지워도 이전 커밋에는 그대로 있습니다. 히스토리는 로컬 저장소, 자동화 에이전트, 미러, 포크로 복제됩니다. 시크릿이 커밋에 포함된 순간 노출된 것으로 봐야 합니다.
저장소 접근 권한은 필요 이상으로 넓은 경우가 많습니다. 외부 용역, 임시 기여자, 테스트용 포크 — 누구나 보면 안 되는 자격 증명을 볼 수 있습니다.
GitHub와 GitLab은 자격 증명을 적극적으로 스캔합니다. 플랫폼이 토큰을 표시하면 유출된 것으로 간주하고 즉시 폐기하세요.
Git 대신 써야 할 것
시크릿은 정적 파일이 아닙니다. 코드 밖에 두고, 권한을 통제하고, 로테이션을 지원하며, 환경별로 격리되어야 하는 접근 자격 증명입니다.
Vault나 OpenBao를 운영할 수도 있지만, 인프라·유지보수·운영 부담이 따릅니다.
Semaphore에는 자동화 워크플로에 바로 통합된 Key Store가 있습니다. 시크릿은 다음 둘 중 한 곳에 둘 수 있습니다.
- Semaphore의 암호화 데이터베이스(기본값)
- HashiCorp Vault, Devolutions, OpenBao 같은 외부 저장소(PRO 기능)
간단한 내장 옵션을 쓰거나 기존 기업용 시크릿 시스템에 연결하면 됩니다. 별도 설정 없이 동작합니다.
Key Store에 넣는 것
- API 토큰
- SSH 키
- 비밀번호
- 환경 변수
- JSON 및 기타 설정 파일
시크릿은 코드베이스에 닿지 않습니다. 작업 실행 시점에만 주입됩니다. 개발, 스테이징, 프로덕션용 자격 증명을 나누고 특정 사용자·팀·워크플로로 범위를 제한할 수 있습니다.
실제로 어떻게 쓰나요
Key Store를 만들고 시크릿을 추가한 뒤 워크플로 설정에서 참조합니다. Semaphore가 실행 시 값을 주입합니다.
예를 들어 AWS 배포에서 액세스 키는 해당 작업이 도는 동안, 그 작업을 실행하는 에이전트에서만 존재합니다. 개발자는 시크릿을 보지 않습니다. Git을 거치지 않습니다.
예시
UI에서 Secret 생성: Secrets → New Secret 후 변수 추가:
AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY
워크플로에서 시크릿 이름으로 참조하면 Semaphore가 실행 시 환경 변수로 주입합니다.
blocks:
- name: Deploy
task:
secrets:
- name: aws-credentials
jobs:
- name: deploy
commands:
- aws s3 sync ./dist s3://my-bucket
SSH의 경우 개인 키 파일이 들어 있는 시크릿을 만듭니다. Semaphore가 자동으로 ~/.ssh/에 둡니다.
blocks:
- name: Deploy via SSH
task:
secrets:
- name: production-ssh-key
jobs:
- name: deploy
commands:
- ssh deploy@production-server "cd /app && git pull"
Key Store와 다른 방식
| 방식 | 안전 | 가시성 | 폐기 가능 |
|---|---|---|---|
Git의 .env |
아니오 | 팀 전체 | 아니오 |
| GitHub Actions Secrets | 부분적 | 경우에 따라 | 예 |
| Semaphore Key Store | 예 | 범위 제한 | 예 |
게다가 코드 수정 없이 토큰을 로테이션하고, 역할·팀별 접근을 제어하고, 환경마다 다른 시크릿을 쓸 수 있습니다.
정리
Git에 커밋된 토큰은 유출된 것으로 간주해야 합니다. 히스토리는 기여자, 포크, 미러, 자동화 에이전트로 퍼지며 — 복사본마다 노출 지점이 늘어납니다.
Key Store는 시크릿을 저장소 밖에 두고 실행 시에만 주입하며 로테이션과 접근을 통제합니다. Ansible, Terraform, OpenTofu, PowerShell 자동화를 하는 팀에게 이건 선택적 인프라가 아니라 기반입니다.
옵션 1
Git의 시크릿 = 노출된 시크릿. 영원히.
Git 히스토리는 포크, 미러, CI 에이전트에 복제됩니다. 커밋된 토큰 하나는 무기한 유출된 토큰입니다.
왜 반복되는지, Semaphore Key Store가 어떻게 해결하는지 정리했습니다.
옵션 2
Semaphore Key Store의 시크릿 처리:
→ 토큰, SSH 키, 환경 변수를 저장소 밖에 보관
→ 작업 설정에서 {{ your_secret }}로 참조
→ 실행 시 해당 에이전트에서 그 작업에만 주입
개발자는 보지 못합니다. Git을 타지 않습니다.
자세한 글 → [링크]
Semaphore Key Store가 어떻게 동작하는지, 왜 있는지 정리한 글을 게시했습니다.
한 줄로: 시크릿은 Git에 두면 안 됩니다. 절대로. 하지만 대안이 없으면 개발자는 계속 그렇게 합니다.
Key Store는 Semaphore 자동화 워크플로에 직접 연결됩니다. 실제 흐름은 다음과 같습니다.
- UI에서 Key Store 생성
- 시크릿 추가 — API 토큰, SSH 키, 환경 변수, 설정 파일
- 작업 설정에서
{{ your_secret }}로 참조 - Semaphore가 실행 시 에이전트에서 해당 작업에만 주입
개발자는 시크릿을 보지 않습니다. 저장소에도 남지 않습니다. 작업이 끝나면 실행 환경에서 사라집니다.
사용자, 팀, 환경별로 접근을 제한할 수 있습니다. 코드 한 줄도 바꾸지 않고 토큰 로테이션. dev, 스테이징, 프로덕션용 자격 증명 분리.
Ansible, Terraform, OpenTofu를 쓰는 팀에게는 «돌아간다»와 «진짜 안전하다» 사이에 빠져 있던 조각입니다.
자세한 글 →
