오만함이 가져다준 쓴맛
몇 주 전, 금요일 오후 6시. 퇴근을 앞둔 나는 자신만만하게 git push
명령어를 입력했다. "이 정도 간단한 수정은 당연히 문제없겠지." 라는 생각과 함께. 하지만 10분 후, 동료들로부터 쏟아지는 에러 메시지 스크린샷을 보며 깨달았다. 완벽하다고 생각했던 내 코드가 실제로는 얼마나 엉성했는지를.
그날 밤, 집에서 긴급 핫픽스를 해야 했던 경험은 지금까지도 내게 중요한 교훈을 남겼다. Git 푸시는 단순한 업로드가 아니라, 팀 전체의 작업 흐름에 영향을 미치는 중요한 순간이라는 것을.
체크리스트라는 안전망
그 이후로 나는 푸시 전 체크리스트를 만들어 습관화했다. 처음에는 번거롭게 느껴졌지만, 점차 이것이 얼마나 소중한 안전망인지 깨닫게 되었다.
에러가 없는지 확인하기
가장 기본적이면서도 중요한 단계다. IDE의 빨간 밑줄, 콘솔의 에러 메시지들을 무시하고 푸시하는 것은 마치 브레이크 없는 차로 고속도로에 진입하는 것과 같다. 프로젝트에 맞는 빌드나 컴파일 명령어를 실행해 문법 오류나 컴파일 에러가 없는지 반드시 확인해야 한다.
특히 정적 타입 언어를 사용한다면, 타입 에러는 실행 시점의 예측 불가능한 버그로 이어질 수 있다. 코드 스타일 검사 도구나 린터가 설정되어 있다면 이것도 함께 실행해보자.
오타는 코드의 적
코드에서 오타는 단순한 실수가 아니라 잠재적 버그의 씨앗이다. 변수명, 함수명, 문자열 리터럴까지. 특히 API 엔드포인트나 환경 변수명의 오타는 런타임에야 발견되는 경우가 많아 더욱 위험하다.
내가 사용하는 방법 중 하나는 코드를 소리 내어 읽어보는 것이다. 묵독할 때는 놓치기 쉬운 오타들이 음성으로 읽을 때 더 명확하게 드러나곤 한다. 또한 코드 리뷰 도구나 IDE의 맞춤법 검사 기능도 적극 활용한다.
테스트 코드는 선택이 아닌 필수
"이 기능은 간단해서 테스트 코드가 필요 없어"라고 생각했던 적이 있나? 나도 그랬다. 하지만 가장 간단해 보이는 기능에서 가장 예상치 못한 버그가 발생하는 것이 프로그래밍의 아이러니다.
단위 테스트의 힘
새로운 기능을 추가했다면, 해당 기능에 대한 단위 테스트를 작성하는 것이 기본이다. 기존 기능을 수정했다면, 관련 테스트들이 여전히 통과하는지 확인해야 한다. 프로젝트에 설정된 테스트 명령어를 실행해 모든 테스트가 통과하는지 확인해보자.
특히 리팩토링 작업에서는 테스트 코드가 더욱 중요하다. 겉으로는 동일한 기능을 수행하는 것처럼 보이지만, 내부 로직이 변경되면서 예상치 못한 사이드 이펙트가 발생할 수 있기 때문이다.
통합 테스트와 E2E 테스트
개별 함수가 잘 동작한다고 해서 전체 시스템이 원활하게 돌아간다는 보장은 없다. API 호출, 데이터베이스 연동, 외부 서비스와의 통신 등을 검증하는 통합 테스트도 중요하다.
시간이 허락한다면 주요 사용자 시나리오를 커버하는 E2E 테스트도 실행해보자. 사용자 관점에서 애플리케이션이 제대로 작동하는지 확인할 수 있다.
추가 안전장치들
커밋 메시지 점검
좋은 커밋 메시지는 미래의 나와 동료들에게 주는 선물이다. 무엇을, 왜 변경했는지 명확하게 작성했는지 다시 한 번 확인해보자. "fix", "update" 같은 모호한 메시지보다는 구체적인 변경 내용을 담는 것이 좋다.
브랜치 상태 확인
현재 작업하고 있는 브랜치가 맞는지, 최신 main 브랜치와 동기화되어 있는지 확인하자. git status
와 git branch
명령어로 현재 상태를 파악하고, 필요하다면 git pull origin main
으로 최신 변경사항을 반영하자.
민감한 정보 검사
API 키, 비밀번호, 개인정보 등이 실수로 포함되지 않았는지 점검하는 것도 중요하다. .env
파일이나 설정 파일들이 .gitignore
에 제대로 등록되어 있는지도 함께 확인하자.
Git 푸시 전 필수 체크리스트
실제로 사용하고 있는 체크리스트를 공유한다. 처음에는 종이에 적어두고 하나씩 체크했지만, 이제는 자연스럽게 몸에 밴 습관이 되었다.
✅ 기본 검증
- 컴파일 및 빌드 확인: 프로젝트의 빌드 명령어로 컴파일 오류 검사
- 코드 스타일 검사: 린터나 포매터로 코드 규칙 준수 확인
- 정적 분석: 정적 타입 검사나 코드 분석 도구 실행
- 코드 오타 점검: 변수명, 함수명, 문자열 리터럴 확인
✅ 테스트 검증
- 단위 테스트 실행: 프로젝트의 테스트 명령어로 모든 테스트 실행
- 관련 테스트 통과 확인: 수정된 기능과 연관된 테스트들
- 새 기능 테스트 작성: 추가된 기능에 대한 테스트 코드 포함
✅ Git 상태 확인
- 브랜치 확인: 현재 브랜치가 올바른지 확인
- 최신 변경사항 동기화: 원격 저장소의 최신 변경사항 반영
- 스테이징 상태 점검: 커밋할 파일들과 변경 내용 확인
- 커밋 메시지 점검: 구체적이고 명확한 변경 내용 작성
✅ 보안 검증
- 민감한 정보 확인: API 키, 비밀번호, 개인정보 제거
- 환경 설정 파일:
.env
, 설정 파일이.gitignore
에 등록되어 있는지 확인 - 하드코딩된 값 점검: 개발용 URL이나 테스트 데이터 제거
완벽함을 향한 여정
체크리스트를 만들고 습관화한 지 몇 달이 지난 지금, 푸시 전 확인 과정이 번거로움이 아닌 안정감으로 다가온다. 물론 여전히 가끔 실수를 하지만, 그 빈도와 심각성은 현저히 줄어들었다.
완벽한 코드를 작성하는 것은 불가능하지만, 완벽을 향해 노력하는 과정에서 더 나은 개발자가 될 수 있다고 믿는다. Git 푸시 전 체크리스트는 그 여정의 작은 지도 같은 존재다. 때로는 귀찮고 시간이 걸리지만, 결국 우리를 더 안전한 목적지로 이끌어주는 소중한 도구가 아닐까.
'IT' 카테고리의 다른 글
Git으로 이미 추가된 ignored 파일 제거하기 - 왜 .gitignore를 만들어도 계속 추적될까요? (1) | 2025.09.02 |
---|---|
GPT로 이메일 작성 효율 200% 끌어올리기! 💌 (3) | 2024.11.29 |
GPT로 업무 자동화하기: 시간 도둑을 잡아라 (2) | 2024.11.29 |
회사에서 덜 스트레스 받고 오래 버티는 5가지 초능력 (1) | 2024.11.26 |
미래에서 온 기계, 인류를 돕다: 우리가 몰랐던 AI의 비밀 사명 (2) | 2024.11.26 |