변경 시점과 작성자를 남겨 버그가 언제 들어왔는지 좁힙니다.
이 파트에서 다루는 내용
형상관리는 변경을 설명하는 체계입니다
형상관리(SCM)는 코드, 설정, 문서, 빌드 스크립트처럼 프로젝트를 구성하는 산출물의 변경 이력을 추적하는 활동입니다.
좋은 형상관리는 누가, 언제, 무엇을, 왜 바꿨는지 남깁니다. 이 네 가지가 남아 있어야 장애 원인 추적, 롤백, 리뷰, 인수인계가 가능합니다.
실험이 실패하거나 배포가 깨졌을 때 특정 시점으로 복구합니다.
여러 사람이 같은 코드베이스에서 병렬 작업하고 충돌을 명시적으로 해결합니다.
CVS, SVN, Git의 구조 차이
SVN은 중앙 서버가 기준이고, 개발자는 서버에서 최신 코드를 받아 작업한 뒤 다시 커밋합니다.
Git은 각 개발자 로컬에 전체 이력이 있습니다. 네트워크가 끊겨도 커밋, 브랜치, 비교, 되돌리기가 가능합니다.
- 파일 단위 이력 관리
- 브랜치와 병합이 불편
- 현대 협업에는 한계가 큼
- 서버 저장소가 진실
- checkout/update/commit 중심
- 브랜치가 비교적 무겁게 느껴짐
- 로컬에 전체 이력 보유
- 브랜치가 매우 가벼움
- PR, CI/CD, AI 도구의 기본 인프라
Git으로 가는 이유
Git은 단순히 SVN의 최신 버전이 아닙니다. 협업 단위가 파일 잠금에서 브랜치와 리뷰로 바뀐 환경에 맞는 구조입니다.
현대 개발은 기능 브랜치, Pull Request, 자동 테스트, 자동 배포, AI 코드리뷰가 연결됩니다. 이 흐름의 공통 언어가 Git입니다.
Git은 코드를 저장하는 도구가 아니라 변경을 작게 나누고, 검토하고, 배포까지 연결하는 협업 프로토콜에 가깝습니다.
오래된 시스템은 SVN을 당장 버릴 수 없을 수 있습니다
구축된 지 오래된 시스템은 SVN에 수년치 이력, 배포 태그, 운영 감사 자료, 외주 인수인계 기록이 이미 쌓여 있을 수 있습니다.
이런 환경에서 Git 전환은 도구 교체가 아니라 이력, 권한, 배포 스크립트, 장애 추적 기준을 함께 바꾸는 일입니다. 그래서 실무 판단은 SVN 유지, Git 공존, 단계적 이전 중 무엇이 안전한지부터 시작합니다.
- 소스와 배포 절차가 안정적
- 변경 빈도가 낮음
- 감사·운영 이력이 SVN 기준으로 고정
- 신규 모듈은 Git
- 레거시 본체는 SVN
- 릴리스 기준과 변경 책임을 문서로 분리
- 이력 보존 필요 범위 결정
- 권한과 브랜치 전략 재설계
- CI/CD와 배포 스크립트 동시 전환
레거시 SVN 저장소는 낡았다는 이유만으로 이전하지 않습니다. 변경 빈도, 감사 필요성, 배포 자동화, 팀 숙련도를 보고 전환 비용보다 운영 이익이 클 때 움직입니다.