블로그 배포 파이프라인과 깃이그노어를 첫 발행 시점에 정비한 이유

.gitignore 보강하고 publish 스크립트에 서버 버전 sync 로직을 붙였다. 작은 chore 커밋이지만, 이런 인프라 잡일을 미루면 나중에 팀 전체가 골치 아파진다는 걸 경험상 잘 알아서 바로 처리했음.

왜 지금 했나

블로그 첫 포스트(2026-05-20-welcome.md)를 올리는 시점에 맞춰서 배포 흐름을 한 번 전체적으로 점검했다. 처음 세팅할 때는 "일단 돌아가면 되지" 마인드로 publish.sh 을 대충 작성해두는 경우가 많은데, 그게 쌓이면 나중에 "왜 로컬이랑 서버 버전이 다르지?" 같은 불필요한 디버깅 시간이 발생한다.

.gitignore 쪽도 마찬가지다. 처음에 빠뜨린 항목들이 있으면 빌드 산출물이나 로컬 환경 파일이 슬쩍 커밋되는 사고가 생긴다. 혼자 쓰는 레포라도 나중에 다시 클론하거나 다른 환경에서 열었을 때 문제가 생기면 결국 내가 다 처리해야 하니까.

변경 내용 정리

publish.sh 의 서버 버전 sync 는 대략 이런 구조를 염두에 뒀다.

# 빌드 후 서버 측 버전 파일도 함께 갱신하는 패턴
BUILD_VERSION=$(git rev-parse --short HEAD)

npm run build

# 서버에 현재 커밋 해시 기록
echo "$BUILD_VERSION" > dist/VERSION

rsync -avz dist/ user@server:/path/to/deploy/

커밋 해시를 VERSION 파일로 박아두면 "지금 서버에 뭐가 떠 있지?" 를 바로 확인할 수 있다. 롤백 포인트 추적할 때도 유용하고, 나중에 CI/CD 붙일 때도 이 패턴이 자연스럽게 연결된다.

.gitignore 는 초반에 챙기는 게 맞다

팀 프로젝트에서 코드리뷰할 때 가장 자주 피드백 남기는 항목 중 하나가 .gitignore 누락이다. 특히 이런 항목들은 초반에 한 번에 정리해두는 편이 낫다.

• 빌드 산출물 (dist/, build/, .next/ 등)
• 로컬 환경 변수 (.env.local, .env.*.local)
• 에디터 설정 (.vscode/, .idea/)
• OS 메타파일 (.DS_Store, Thumbs.db)
• 패키지 캐시 (node_modules/, .cache/)

누락된 채로 한 번 커밋되면 히스토리에 박혀버려서 나중에 지우기가 꽤 번거롭다. git filter-branch 나 BFG Repo Cleaner 로 처리할 수 있지만, 그 작업 자체가 팀 전체 브랜치에 영향을 주기 때문에 애초에 안 들어가게 막는 게 압도적으로 낫다.

회고

첫 포스트 올리는 날 배포 파이프라인까지 같이 정리한 건 잘한 선택이었다. 콘텐츠 작업과 인프라 작업을 분리해서 생각하다 보면 인프라 쪽은 항상 미뤄지는데, 어차피 발행 시점에 publish.sh 돌리면서 보이는 문제니까 그 자리에서 바로 고쳤다.

작은 chore 커밋이지만 이런 게 쌓여야 "이 레포는 관리되고 있다"는 신뢰가 생긴다. 혼자 쓰는 블로그 레포라도 그 기준은 똑같이 적용하는 편이다.

끝.

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

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

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