Git 실무 가이드 · Part 1

형상관리와 Git이 나온 이유

SVN을 써본 직장인이 Git으로 넘어가기 전에 먼저 잡아야 할 개념 정리

작성 기준2026년 7월

이 파트에서 다루는 내용

CH 01 형상관리란 무엇인가CH 02 왜 형상관리 도구를 쓰는가CH 03 SVN, CVS, Git 어떻게 다른가CH 04 왜 결국 Git으로 가는가
01

형상관리는 변경을 설명하는 체계입니다

형상관리(SCM)는 코드, 설정, 문서, 빌드 스크립트처럼 프로젝트를 구성하는 산출물의 변경 이력을 추적하는 활동입니다.

좋은 형상관리는 누가, 언제, 무엇을, 왜 바꿨는지 남깁니다. 이 네 가지가 남아 있어야 장애 원인 추적, 롤백, 리뷰, 인수인계가 가능합니다.

이력 추적

변경 시점과 작성자를 남겨 버그가 언제 들어왔는지 좁힙니다.

되돌리기

실험이 실패하거나 배포가 깨졌을 때 특정 시점으로 복구합니다.

협업

여러 사람이 같은 코드베이스에서 병렬 작업하고 충돌을 명시적으로 해결합니다.

02

CVS, SVN, Git의 구조 차이

SVN은 중앙 서버가 기준이고, 개발자는 서버에서 최신 코드를 받아 작업한 뒤 다시 커밋합니다.

Git은 각 개발자 로컬에 전체 이력이 있습니다. 네트워크가 끊겨도 커밋, 브랜치, 비교, 되돌리기가 가능합니다.

CVS
초기 중앙집중형
  • 파일 단위 이력 관리
  • 브랜치와 병합이 불편
  • 현대 협업에는 한계가 큼
SVN
중앙 서버 기준
  • 서버 저장소가 진실
  • checkout/update/commit 중심
  • 브랜치가 비교적 무겁게 느껴짐
Git
분산 저장소
  • 로컬에 전체 이력 보유
  • 브랜치가 매우 가벼움
  • PR, CI/CD, AI 도구의 기본 인프라
03

Git으로 가는 이유

Git은 단순히 SVN의 최신 버전이 아닙니다. 협업 단위가 파일 잠금에서 브랜치와 리뷰로 바뀐 환경에 맞는 구조입니다.

현대 개발은 기능 브랜치, Pull Request, 자동 테스트, 자동 배포, AI 코드리뷰가 연결됩니다. 이 흐름의 공통 언어가 Git입니다.

핵심 관점

Git은 코드를 저장하는 도구가 아니라 변경을 작게 나누고, 검토하고, 배포까지 연결하는 협업 프로토콜에 가깝습니다.

04

오래된 시스템은 SVN을 당장 버릴 수 없을 수 있습니다

구축된 지 오래된 시스템은 SVN에 수년치 이력, 배포 태그, 운영 감사 자료, 외주 인수인계 기록이 이미 쌓여 있을 수 있습니다.

이런 환경에서 Git 전환은 도구 교체가 아니라 이력, 권한, 배포 스크립트, 장애 추적 기준을 함께 바꾸는 일입니다. 그래서 실무 판단은 SVN 유지, Git 공존, 단계적 이전 중 무엇이 안전한지부터 시작합니다.

SVN 유지
운영 안정 우선
  • 소스와 배포 절차가 안정적
  • 변경 빈도가 낮음
  • 감사·운영 이력이 SVN 기준으로 고정
Git 공존
부분 전환
  • 신규 모듈은 Git
  • 레거시 본체는 SVN
  • 릴리스 기준과 변경 책임을 문서로 분리
Git 이전
전환 프로젝트
  • 이력 보존 필요 범위 결정
  • 권한과 브랜치 전략 재설계
  • CI/CD와 배포 스크립트 동시 전환
현장 기준

레거시 SVN 저장소는 낡았다는 이유만으로 이전하지 않습니다. 변경 빈도, 감사 필요성, 배포 자동화, 팀 숙련도를 보고 전환 비용보다 운영 이익이 클 때 움직입니다.

체크

이 파트 완료 기준