처음 Git을 사용할 때는 단순히 “코드 저장 도구” 정도로 생각했습니다.
하지만 실제 프로젝트를 운영하면서 Git은 단순 백업이 아니라 작업 흐름 자체를 관리하는 도구에 더 가깝다는 것을 느끼게 되었습니다.
처음에는:
- commit
- push
- pull
정도만 사용해도 충분하다고 생각했습니다.
하지만 프로젝트 규모가 커지고 수정이 반복되면서 다음과 같은 상황들을 자주 경험하게 되었습니다.
- 수정 전 상태로 다시 돌아가야 하는 경우
- 여러 기능을 동시에 작업하는 경우
- 실수로 잘못된 코드가 올라간 경우
- 운영 버전과 개발 버전을 분리해야 하는 경우
특히 혼자 개발할 때는 Git 사용이 단순해 보이지만, 시간이 지나면 이전 작업 기록이 굉장히 중요해진다는 점을 많이 느끼게 되었습니다.
예전에는 파일을 직접 복사해서:
- project_final
- final_real
- final_last
같은 방식으로 관리하기도 했지만, 결국 어느 시점부터는 관리가 어려워졌습니다.
Git을 사용하면서 가장 편리했던 부분은 “변경 이력”을 남길 수 있다는 점이었습니다.
예를 들어:
- 어떤 파일을 수정했는지
- 언제 변경했는지
- 왜 수정했는지
를 기록으로 남길 수 있었고, 문제가 발생했을 때 이전 상태를 비교하기도 훨씬 쉬워졌습니다.
특히 실제 운영 프로젝트에서는:
- 기능 추가
- 긴급 수정
- 테스트 코드
- 고객별 대응
등이 계속 반복되기 때문에 작업 흐름 관리가 매우 중요했습니다.
최근에는 AI 도구를 사용하면서 코드 생성 속도가 빨라졌지만, 오히려 Git 기록 관리의 중요성은 더 커지고 있다고 느끼고 있습니다.
AI가 빠르게 코드를 만들어 주더라도 결국:
- 어떤 변경이 있었는지
- 왜 수정했는지
- 어느 시점부터 문제가 발생했는지
를 추적하는 것은 여전히 사람이 관리해야 하기 때문입니다.
현재는 작은 프로젝트라도 가능하면 처음부터 Git 저장소를 구성하는 습관을 유지하려고 하고 있습니다.
완벽한 브랜치 전략까지는 아니더라도, 최소한 변경 기록을 남기고 이전 상태를 복구할 수 있다는 점만으로도 Git은 충분히 큰 도움이 되는 도구라고 생각합니다.