main 브랜치에 직접 push하기 전에 내가 확인하는 것들

팀이 없으면 PR 리뷰도 없고, CI가 없으면 자동 검사도 없다. 그러다 보니 main에 바로 push하다가 빌드가 깨지거나, 타입 오류가 운영에 그대로 올라가는 일이 생긴다. 요즘은 push 전에 짧게라도 아래 순서를 돌린다.

빌드 먼저 돌린다

npm run build

로컬 dev 서버에서는 잘 돌아가도 빌드 단계에서 타입 오류나 import 문제가 터지는 경우가 적지 않다. 특히 Next.js에서 서버 컴포넌트와 클라이언트 컴포넌트를 섞어 쓰다 보면 dev에서는 넘어가는 게 build에서 걸리기도 한다. 1분도 안 걸리는 확인이라 습관으로 만들어 두는 게 낫다.

변경 범위를 한 번 훑는다

git diff HEAD
git status

작업하다 보면 의도치 않게 바꾼 파일이 섞여 있을 때가 있다. 특히 에디터가 자동 저장하면서 공백이나 줄 끝 문자를 건드리는 경우가 그렇다. diff를 한 번 훑으면 "이거 왜 바뀌었지?" 싶은 파일을 미리 골라낼 수 있다.

실제 요청이 깨지지 않는지 확인한다

빌드가 성공했다고 끝이 아니다. API 응답이 달라졌거나, 페이지 경로가 바뀌었다면 실제 URL로 한 번 찔러본다.

curl -s -o /dev/null -w "%{http_code}" https://내도메인.com/api/health

staticly 생성된 페이지는 빌드 결과물을 npm run start로 올려서 브라우저로 직접 확인하는 편이 제일 확실하다.

커밋 메시지는 짧게라도 이유를 남긴다

fix, update 한 단어로 끝내면 나중에 git log를 봤을 때 무슨 의도였는지 알 수가 없다. "왜"를 한 줄이라도 적어두면 두 달 뒤에 bisect 돌릴 때 구한다.

---

이 루틴이 완벽하지는 않다. 테스트가 없으면 로직 버그는 놓친다. 하지만 빌드 실패와 의도치 않은 변경 두 가지는 이 정도로도 꽤 걸러진다.