출근하기 전 새벽에 공부하느라 급하게 쓰는 거라 굉장히 횡설수설하다.
프론트엔드라고 하면 단순하게 화면을 그리는 개발자라고 생각하기 쉽다.
하지만 단순하게 화면을 그리는 것 이외에 할 것이 많다. 개발만 한다고 해서 다 되는 게 아니라는 것이다.
우리가 프론트엔드로 살아남으려면, 프론트엔드의 개발 로직을 알아야 한다.
단순하게 그림을 그리는 것 이외에 브라우저의 동작 방식이라든지 프레임워크의 라이프 사이클을 알아야 한다든지, 그런 것들은 프론트엔드의 개발을 더 깊게 하기 위해서 하는 것이고, 이외에 시작부터 끝까지 알아야 한다는 말.
개발을 하기 전에…
블로그를 만들기로 결정했다. 화면을 만들고, 기능을 추가하기 전에 해야 할 일이 있다.
물론 기획이 있겠지만, 그 전에 “개발 환경 세팅”을 해야 한다.
ai가 나와 있는 상태지만, 모르는 상태에서 기계 제국의 앞잡이를 하려고 하면 결국 기계에게 잡아먹히고 만다.
나 같은 경우 대충 31248번은 잡아먹힌 듯했다. 31249번 먹히지 않기 위해 꼼꼼히 공부하는 것이다…
개발 환경 세팅을 하지 않으면 높은 확률로 그 프로젝트는 흐지부지되기 마련이다. (나도 알고 싶지 않았다)
개발 환경 세팅 (대충 생각이 나는 것들만)
어떤 언어/프레임 워크를 쓸 것인가?
어떤 전역 변수 관리를 쓸 것인가?
어떤 통신 관리 플랫폼을 쓸 것인가?
어떤 스타일 플랫폼을 쓸 것인가?
문법 에러, 코드 스타일은 어떻게 할 것인가?
깃과의 연동은 어떻게 할 것인가?
이런 상황에서, 보통 1번은 다들 곧잘 생각을 해낸다.
요즘 프론트엔드 추세에 맞춰서 말이다.
타입스크립트 + Next.js를 사용하고, ES Lint와 Prettier를 사용하여 코드 포맷팅을 하고, Zustand를 사용하여 전역 관리, axios 혹은 Tanstack을 사용하여 통신 관리를 할 것이다.
그러나 여기에서 중요한 점은, 2번과 3번이다. 이걸 간과한다면 우리의 블로그가 담긴 깃이 아주 더러워진다.
아무렇게나 개발을 하고, 아무렇게나 저장하고, 아무렇게나 커밋을 쳐서 아무렇게나 올려도 혼자 개발하면 장땡이다. 그 코드를 받는 주체도 나, 쓰는 주체도 나이기 때문에 원망하거나 칭찬할 상대는 나밖에 없다. 하지만 이런 기초적인 것을 대충한다면 스스로 해 줄 것은 칭찬이 아닌 야유뿐이다.
Git과의 연동, 어떻게 하면 예쁘게 할 수 있을까?
Git에다가 프로젝트를 올린다는 것은 나의 프로젝트를 온라인 보관함에 넣는다는 것이다.
이 프로젝트가 건축 프로젝트라면, 삽을 푼다는 뜻이다. 나는 내 집을 만들 때 아무렇게나 만들기 싫다.
만드는 것은 급하니 어떻게든 그냥 한다고 쳐도, 정리를 잘해야 내일의 내가 봤을 때 올곧고 예뻐야 한다는 것이다.
그렇다. 정리. 정리를 해야 한다.
코드를 작성하고, 커밋을 하기 전에 코드 정리를 깨끗하게 해야 한다.
깃에 올라간 프로젝트는 무균의 상태가 되어야 한다는 뜻이다.
언제라도 꺼내서 볼 때, 언제든 다시 시작을 할 때 한참 헤메지 않도록 나 스스로와의 약속을 지켜야 한다.
그러려면 깃에 올리기 전에 철저한 검사(에러, 콘솔, 불필요한 변수, 동작하는지? 등)를 해야 한다.
만약 개발했다고 쳐도 동작 안 하면 어쩔 건가? … 혼자라면 그럴 수 있겠지만 팀이라면?…
옛날에는 Git Hooks라는 것으로 커밋을 하기 전에 내 코드가 드러운지 깨끗한지 판별을 했다. 지금도 Git과 연결된 프로젝트이고, 프로젝트 구성원이 나 혼자라면 충분히 불편함 없이 할 수 있다. (거기에서만 개발을 하거나 스크립트를 복붙해서 가지고 다닐 거라면…)
동작 방식을 위해 Git Hooks이 어떻게 쓰이는지부터 알아보자.
Git Hooks
Git 설치 시 기본적으로 내장되어 있다.
.git/hooks/ 디렉터리에 pre-commit.sample 혹은 pre-push.sample 같은 파일들이 보일 텐데, 그것들을 지우면 활성화가 된다.
그 파일 안에 실행할 쉘 스크립트를 작성하면 끝이다.
다만, 실행 권한이 있어야 한다. (chmod +x .git/hooks/pre-commit)
git hooks는 굉장히 많은 단계에서의 스크립트를 지원한다. 붉은색은 무조건 필요, 노란색은 팀 협업 시 필요, 나머지는 그냥 알아서 하자.
post-applypatch : 이메일로 받는 패치 파일 적용
post-checkout : git checkout으로 브랜치 바꾼 직후 - npm install 자동 실행해 의존성 패키지 맞춤
post-commit : 커밋이 완료된 직후 - 커밋 완료 같은 데스크탑 알림 띄우기
post-merge : git merge가 끝난 직후 : 변경된 라이브러리 자동 설치 등
post-rewrite : git commit —amend나 rebase로 기록 덮어쓴 후 - 변경사실 기록/알림
pre-applypatch : 이메일로 받는 패치 파일 적용
pre-auto-gc : git이 내부 청소 하기 전에 실행
pre-commit : git commit 입력 후, 커밋 생성 전 - 코드 포맷팅, 간단 유닛 테스트
pre-merge-commit : 머지 커밋 만들기 직전
pre-push : git push 실행 직전 - 통합 테스트 돌리기
pre-rebase : git rebase 실행 직전 - 이미 원격에 올라간 브랜치를 실수로 리베이스 하지 못하게 막음
prepare-commit-msg : 커밋 메시지 에디터 열리기 전 - 커밋 메시지 템플릿에 이슈 번호, 브랜치 이름 자동으로 넣을 때
commit-msg : commit 입력하고 엔터 친 직후 실행 - 커밋 메시지 내용이 규칙에 맞는지 검사
붉은색 위주로 스크립트를 실행하고 싶다고 치자. 그런데 스크립트를 만드는 건 꽤 까다롭다… (물론 요즘은 ai가 다 해 주지만, 물론 권한 실행 같은 것도 걍 스크립트 명령어로 만들면 되지만…)
.githooks/pre-commit에 저장하고, chmod +x .git/hooks/pre-commit 으로 실행
#!/bin/sh
# 1. 스테이징된(Staged) 파일 내용에서 'console.log' 검색
# grep -q: 출력 없이 찾기만 함 / exit 1: 실패(커밋 중단)
if git diff --cached | grep -q 'console.log'; then
echo "❌ [Error] 코드에 'console.log'가 남아있습니다."
echo " 지우거나 주석 처리 후 다시 커밋해주세요."
exit 1
fi
# 2. 문제 없으면 통과
exit 0
이걸 언제 하나하나 다 만들고 있지? 바쁜데? 게다가 재미 때가리도 없다… 아니지, 시간이 많으면 재미있겠지… ‘[Error] 코드에 ‘console.log’가 남아 있습니당~!’ 이런 식으로 이름만 넣어도 커스텀한 것 같고 참 즐겁겠지… 이걸 만들어 주는 놈이 있다면 얼마나 좋을까…
- 그걸 해결해 주는 Husky는 2편에서 -