프로젝트 초기화 커밋으로 개발 기초 다지기

The Button (grow-the-button) 프로젝트의 초기 구현이 시작됐다. 새 프로젝트의 첫 커밋이 들어왔는데, 흥미롭게도 실제 기능 구현이 아닌 환경 설정과 보일러플레이트 파일들만 들어갔다. 단순히 "프로젝트 만들고 시작했네" 정도로 볼 수도 있지만, 사실 이 커밋이 이후 몇 개월간 팀의 개발 경험과 코드 품질을 좌우하는 기초가 될 거라 생각한다.

첫 커밋에 담긴 것들

겉으로는 "설정 파일 몇 개 추가"지만, 실제로는 앞으로 이 프로젝트에 합류할 개발자들이 첫 git clone 후에 경험할 전체를 결정하는 것이다.

왜 이 파일들이 첫 커밋에 필요한가

ESLint 설정부터 생각해보자. 새 프로젝트에서 코딩 스타일 규칙을 나중에 추가하면 어떻게 될까? 아마도 리팩토링 지옥이 될 거다. 이미 작성된 코드가 새로운 규칙을 위반하면, 오래된 커밋들까지 수정해야 하고, 팀원들 간에 "어떤 스타일이 정답인지"에 대한 논쟁도 생긴다. 처음부터 "우리의 코드는 이렇게 쓴다"는 기준을 정하고 시작하면, 모든 코드가 그 기준으로 자동 검사되고, 리뷰도 "이건 우리 규칙 위반이네"라는 객관적 지적이 된다.

Next.js 설정도 마찬가지다. 초기에는 next.config.ts가 비어있을 수 있지만, "이 프로젝트는 Next.js를 쓰고, 타입스크립트로 설정한다"는 신호를 남기는 것 자체가 중요하다. 나중에 이미지 최적화, 환경 변수 관리, 빌드 최적화 같은 것들이 필요해질 때, 이 파일이 그 집결지가 되고, 팀원들도 "아 여기 건드려야 하는구나" 하고 자연스럽게 찾을 수 있다.

.env.example은 신입 개발자나 신규 팀원의 온보딩을 극단적으로 쉽게 만든다. 대충 설명하지 않아도 "이 파일을 보고 .env 만들어"라고 한 줄 말하면 끝난다. 예제 값들이 있으니 어떤 환경변수가 필요한지, 어떤 형식인지 바로 알 수 있다. 이게 없으면? 영원히 "어... 뭐가 필요하지?" 하면서 물어본다.

.gitignore는 "우리가 얼마나 신경 쓰는지"를 보여주는 파일이다. node_modules/, .env, 개발 환경의 임시 파일들을 명시적으로 제외함으로써, 팀원들이 깜빡해도 시스템이 자동으로 막아준다. 한 번 환경변수가 깃에 올라가는 실수를 겪고 나면, 그 중요성을 뼈저리게 느낀다.

팀 차원에서 느껴지는 효과

사실 이 커밋 자체는 실제 기능을 하나도 추가하지 않는다. 하지만 다음 날 팀원이 이 저장소를 클론할 때, ESLint가 자동으로 코드를 검사하고, npm run dev 를 치면 정확한 환경변수 가이드가 있고, README에 프로젝트의 목표가 정리돼 있다면—그것이 바로 "우리 팀은 기초를 소홀히 하지 않는다"는 신호가 된다.

새 프로젝트를 시작할 때 설정에 신경을 쓰지 않으면, 중반 이후로 갈수록 기술부채가 쌓인다. 코드 품질 관리가 일관성 없어지고, 팀원마다 다른 스타일로 짜고, 환경 문제로 인한 버그도 늘어난다. 반대로 처음부터 "우리가 이렇게 하자"는 기준을 만들어두면, 6개월 뒤에도 그 기준이 유지되고, 새로운 팀원도 쉽게 따라간다.

회고

프로젝트를 시작할 때마다 배우는 게 있다. "처음이 반"이라는 말이 정말 맞다. 기능 구현도 중요하지만, 그 기능을 만들 팀원들이 편하게 작업할 환경을 먼저 만드는 것이 리더의 책임이다. 이번 초기화 커밋은 보이지 않는 곳에서 조용히 팀의 개발 경험을 높여주는 작업이었다.

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

• 외장SSD 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

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