광고 모달 백업 파일 삭제로 레포 위생 개선

.bak 파일 하나 지웠다. 단순한 커밋인데, 오히려 이런 작은 흔적이 팀 코드베이스 위생에서 제일 신경 쓰이는 부분이라는 걸 다시 느꼈다.

발생 배경

sed 명령어는 macOS 환경에서 -i 옵션을 쓸 때 백업 파일을 자동으로 생성한다. Linux의 sed -i는 백업 없이 인플레이스 수정을 하지만, macOS의 BSD sed는 -i '' 처럼 빈 문자열을 붙여줘야 하고, 잘못 쓰면 .bak 확장자로 원본 파일 백업이 남는다.

# macOS에서 이렇게 쓰면 .bak 파일이 생긴다
sed -i .bak 's/old/new/g' target.astro

# 인플레이스로만 쓰고 싶다면
sed -i '' 's/old/new/g' target.astro

이번에 AdGateModal.astro에 sed 작업을 하면서 .bak이 남겨졌고, 그게 그대로 커밋 스테이징 전에 걸러지지 않고 레포에 들어올 뻔했다. 정확히는 이미 src/components/AdGateModal.astro.bak이 트래킹 대상으로 잡혀 있었다는 얘기다.

정리한 내용

이번 커밋에서 한 일은 두 가지다.

.gitignore에 *.bak을 추가하는 것만으로는 부족하다. 이미 git이 트래킹하고 있는 파일은 .gitignore를 추가해도 계속 추적된다. git rm --cached로 인덱스에서 먼저 제거해야 비로소 무시 대상이 된다. 이 부분을 빠뜨리면 "왜 .gitignore 넣었는데도 계속 잡히지?"라는 질문이 팀에서 나온다. 주니어 때 나도 한 번 겪었던 함정.

# 이미 트래킹된 파일을 .gitignore 적용 대상으로 만들려면
git rm --cached src/components/AdGateModal.astro.bak

왜 이런 파일이 레포에 들어오면 문제인가

• 빌드 파이프라인 오염: Astro 프로젝트 특성상 src/components/ 하위를 컴포넌트로 인식하거나 번들링 과정에서 예상치 못한 파일을 집어들 수 있다. .bak 파일이 빌드 결과물에 영향을 줄 가능성은 낮지만, CI에서 파일 목록을 기준으로 뭔가를 처리할 때 불필요한 노이즈가 된다.
• 코드리뷰 혼란: PR 디프에 .bak 파일이 등장하면 "이게 뭐지?"라는 코멘트가 달린다. 리뷰어 집중력을 분산시키는 건 항상 나쁘다.
• 레포 오염 누적: 이런 임시 파일들이 하나둘 쌓이면 나중에 정리할 때 출처도 불명확하고 지워도 되는지 판단이 어려워진다.

팀 입장에서 .gitignore 관리는 "한 번 잘 잡아두면 이후엔 신경 안 써도 되는" 작업이다. 그래서 이번에 *.bak 추가한 김에 비슷한 패턴들도 같이 점검했다. 이런 류의 임시 파일들은 보통 아래처럼 묶어두면 편하다.

# Editor / OS / tool artifacts
*.bak
*.tmp
*.swp
*.DS_Store

사실 이 커밋 자체가 별거 아니라 그냥 넘어갈 수도 있었다. 근데 총괄 입장에서 이런 잡티가 쌓이는 게 제일 싫다. 코드 품질은 기능 구현만이 아니라 이런 위생 관리에서도 드러난다. 작은 커밋이지만 다음번엔 sed 쓸 때 백업 파일 여부 한 번 더 확인하게 됐으니 그걸로 충분하다.

끝.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.