현대 DevOps 환경에서 Git은 단순한 버전 관리 도구를 넘어 Single Source of Truth(단일 진실 공급원) 역할을 한다.
코드부터 인프라 설정까지 모든 것이 여기에 기록되며, CI/CD 파이프라인의 시작점이 된다.
개발자와 운영자가 공유하는 이 "진실의 저장소"가 바로 협업과 자동화의 기반이다.
Git vs GitHub
많은 개발자들이 Git과 GitHub을 혼용하지만, Git은 도구(Tool)이고 GitHub은 서비스(Service)다.
파일과 클라우드 스토리지를 비교하듯, Git은 로컬에서 버전을 관리하는 엔진이고 GitHub은 그 엔진을 클라우드에서 공유·협업하는 플랫폼이다.
DevOps 환경에서 이 둘의 조합이 필수적인 이유를 명확히 이해하자.
핵심 비교 테이블
| 비교 항목 | Git (Version Control Tool) | GitHub (Hosting Service) |
|---|---|---|
| 정의 | 로컬 버전 관리 소프트웨어 | 웹 기반 Git 저장소 호스팅 서비스 |
| 설치 위치 | 개인의 로컬 컴퓨터 | 클라우드 서버 (인터넷 상) |
| 핵심 기능 | 변경 이력 추적, 브랜치/머지 관리 | 팀 협업, PR/코드 리뷰, CI/CD 통합 (Actions) |
| 오프라인 작업 | ✅ 완전 가능 (로컬 저장소 독립 실행) | ❌ 불가능 (인터넷 연결 필수) |
| 인터페이스 | CLI(터미널) 또는 GUI (Sourcetree 등) | 웹 브라우저 기반 직관적 UI |
| 용량/비용 | 무료 (오픈소스) | 무료/유료 플랜 (Private Repo 제한) |
실무적 Insight: 언제 무엇을 사용하나?
Git만으로 가능한 영역
💻 로컬 개발 환경
git init # 새 저장소 생성
git add . # 파일 스테이징
git commit # 로컬 커밋 (오프라인 가능)
git branch # 브랜치 관리- 개인 프로젝트, 오프라인 작업 시 Git 단독 사용.
- IaC 실험, 로컬 테스트 등 독립 개발에 최적.
GitHub이 필요한 DevOps 영역
🌐 GitHub + Git 워크플로우
git push origin main # 공유 저장소 동기화
Create Pull Request # 팀 리뷰 요청
GitHub Actions # 자동 CI/CD 실행- 팀 협업, 코드 리뷰, 자동화 파이프라인 구축 시 GitHub 필수.
- 컨테이너 빌드 → Kubernetes 배포 워크플로우에서 PR 승인 후 Actions가 트리거된다.
핵심: Git은 인터넷 없이도 동작하지만, DevOps의 본질인 공유와 자동화를 위해 GitHub 같은 원격 호스팅 서비스가 반드시 필요하다.
DevOps에서의 Git 위상: 왜 필수인가?
Git은 DevOps 생태계에서 다음과 같은 핵심 역할을 수행한다:
- CI/CD 트리거: Git Commit이 자동화 파이프라인을 발동시키는 첫 신호탄이다.
- 코드로서의 인프라(IaC): Kubernetes 매니페스트, Terraform 설정 등 모든 인프라 정의를 코드로 관리한다.
- 투명한 협업: 변경 이력과 코드 리뷰를 통해 기술 부채를 체계적으로 관리한다.
Git이 없으면 "누가 언제 무엇을 변경했는지" 추적할 수 없고, 자동화도 불가능하다. DevOps는 결국 코드로 모든 것을 표현하고 자동화하는 문화이므로, Git은 그 출발점이다.
Step 1. 메커니즘 이해: 데이터 흐름 파악
Git은 파일 변경을 세 단계로 체계적으로 관리한다
- Working Directory: 실제 파일 수정이 일어나는 공간. 실험적 변경을 자유롭게 테스트한다.
- Staging Area:
git add로 커밋할 파일을 선별. 중요한 변경만 선택적으로 포함한다. - Local Repository:
git commit으로 영구 스냅샷 생성. 버전이 확정된다.
이 구조는 개발자가 자유롭게 실험하면서도, 운영 환경에 반영될 코드만 엄선할 수 있는 유연성을 준다. DevOps에서 특히 IaC 변경처럼 위험도가 높은 작업에 필수적이다.
Step 2. 워크플로우 최적화: 브랜치 전략
브랜치는 Git의 가장 강력한 기능으로, 병렬 개발을 가능하게 한다:
MAIN (안정화 브랜치)
├── C1, C2 (프로덕션 릴리스)
└── C5, C6 (핫픽스)
FEATURE/새기능 (개발 브랜치)
├── C3 (기능 개발)
└── C4 (테스트 완료)- MAIN 브랜치: 프로덕션에 바로 반영 가능한 안정 버전만 유지.
- FEATURE 브랜치: 새로운 기능이나 IaC 변경을 독립적으로 개발. 메인 코드에 영향 없음.
DevOps 환경에서는 infra/terraform-v2 같은 브랜치를 만들어 인프라 변경을 검증한 후 병합한다. 이는 실수로 프로덕션 클러스터를 망가뜨리는 사고를 방지한다.
Step 3. 분산 관리와 동기화: GitHub 협업 허브
Git의 로컬 저장소와 GitHub의 클라우드 저장소가 연결되는 구조
- PUSH: 로컬 변경사항을 GitHub로 업로드.
- PULL: 팀원의 최신 변경을 가져와 동기화.
GitHub는 단순 저장소를 넘어 이슈 트래킹, 프로젝트 보드, Actions(CI/CD)까지 제공한다. DevOps 팀은 IaC 설정을 GitHub에서 공유하며, 모든 운영자가 동일한 클러스터 상태를 유지한다.
Step 4. 품질 보증: Pull Request와 코드 리뷰
Pull Request(PR)는 Git 워크플로우의 품질 게이트다:
DevOps Code Review 예시:
"이 Dockerfile의 베이스 이미지를 Alpine으로 변경하면
보안과 이미지 크기가 개선될 것 같습니다."
- SRE Engineer BPR 과정:
1. 자동 테스트: CI 파이프라인이 단위테스트, 보안 스캔, 컨테이너 빌드 실행.
2. 동료 리뷰: SRE, 개발자, 보안팀이 코드 품질 검토.
3. 승인 후 병합: 모든 게이트 통과 시 MAIN 브랜치에 반영.
DevOps에서 PR은 "개인이 아닌 팀이 책임지는 코드"를 보장한다. 특히 인프라 변경처럼 영향 범위가 큰 경우 필수적이다.
도구를 넘어선 DevOps 표준
Git과 GitHub은 단순 도구가 아니다.
현대 소프트웨어 배포와 인프라 관리의 근간으로, 여기서 확정된 "코드"는 컨테이너로 패키징되고 Kubernetes로 배포된다.
DevOps 문화에서 Git은 협업의 언어이자 자동화의 출발점이다. 코드 리뷰를 통해 지식을 공유하고, 브랜치 전략으로 위험을 관리하며, PR로 품질을 보증하는 이 워크플로우가 바로 조직의 개발 성숙도를 결정한다.
이제 Git에서 시작된 이 여정이 컨테이너 → CI/CD → 오케스트레이션으로 이어지는 전체 DevOps 파이프라인의 첫걸음이다.
