동국대학교 동아리 박람회에 앞서, 신입생들을 포함한 교내 재학생들에게 더 쉽고 빠르게 동아리 부스, 공연 정보 등을 제공하고자 교내 동아리 박람회 사이트 TF팀에 들어가 프론트엔드 개발을 하고 있다. 프론트엔드 개발 팀은 나 포함 3명으로 구성되어 있다.
이런 팀 단위 프로젝트를 진행할 때, 나는 기술적 의사결정 과정을 가장 중요하게 여긴다. 각자 자신이 익숙한 기술스택으로 개발을 진행하는 것이 아닌, 더 나은 프로젝트, 더 나은 개발 경험을 위해서 필수이기 때문이다.
아래는 버전 관리 전략, 패키지 매니저, 빌드 도구, 스타일링, 배포 등에 있어 기술적 의사결정을 내린 근거를 바탕으로 작성했고, 기록으로 남기며 이를 공유하고자 한다.
깃허브 플로우(Github Flow)
본 프로젝트에서는 Github Flow를 버전 관리 전략으로 선택했다. 이는 빠른 배포 주기와 명확한 협업 프로세스를 기반으로 하는 간결하고 효율적인 워크플로우이다.
선정 이유
-
단순한 구조 : Github Flow는 브랜치 전략이 단순하여 작은 단위의 작업에도 적용하기 쉽다.
-
빠른 배포 가능: 개발 중인 기능을 빠르게 병합 및 배포할 수 있기 때문이다.
-
코드 리뷰 중심의 협업 강화: Pull Request 기반으로 코드 리뷰를 필수적으로 진행하도록 하여 코드 품질을 유지할 수 있다.
Yarn
패키지 매니저로 Yarn을 사용하면 프로젝트의 효율성과 안정성을 높일 수 있다.
선정 이유
-
속도와 효율성: Yarn은 병렬 설치 방식을 채택하여 npm보다 빠른 패키지 설치 속도를 제공한다.
-
의존성 고정: Yarn은 yarn.lock 파일을 사용하여 의존성 버전을 고정함으로써 의도치 않은 업데이트로 인한 충돌을 방지할 수 있다.
-
캐싱 시스템: 한 번 설치한 패키지는 로컬에 저장되어, 재설치 시 속도를 대폭 단축시킨다.
Vite
빌드 도구로 Vite를 사용하여 프로젝트 개발 효율성을 높였다.
선정 이유
-
빠른 개발 서버: Vite는 ES 모듈 기반 개발 서버를 제공하여 코드 변경 시 빠른 HMR(Hot Module Replacement)을 지원한다.
-
경량성과 간결함: 설정이 간단하고, 최소한의 구성으로 바로 개발을 시작할 수 있다.
-
최신 기술 지원: 최신 프레임워크와 라이브러리(Vue, React 등)를 기본적으로 지원한다.
styled-components
스타일링 도구로 styled-components를 선택했다.
선정 이유
-
CSS-in-JS 방식: 컴포넌트와 스타일을 함께 관리할 수 있어 코드의 응집도가 높아진다.
-
동적 스타일링: props에 따라 스타일을 조건부로 적용할 수 있다.
-
팀원들의 익숙함: 팀원들이 이전 프로젝트에서 사용 경험이 많아 생산성을 높일 수 있다.
Netlify
배포 플랫폼은 기존 Vercel에서 개인 레포지토리에 CI/CD를 구성해 배포를 진행했으나, 이러한 문제를 해결하고자 Netlify를 선택했다. 구체적인 이유는 아래와 같다.
선정 이유
-
Organization 레포지토리 연동: Netlify는 Organization 레포지토리의 특정 브랜치에 직접 트리거를 걸어 배포할 수 있다.
-
자동 배포: PR 생성 시 Deploy Preview 기능을 통해 자동으로 미리보기 배포 링크를 생성한다.
-
브랜치별 배포: develop과 main 브랜치에 각각 다른 배포를 설정하여 테스트와 실제 배포를 분리할 수 있다.
결론
모든 의사결정 과정은 모든 팀원들과 초기 데일리 스크럼 속에서 이뤄졌다. 이번 프로젝트에서 기술적 의사결정 과정은 단순히 기술 스택을 선택하는 것에 그치지 않고, 팀의 협업 방식과 개발 효율성을 극대화하는 데 중점을 두었다. 이러한 기술적 의사결정 과정은 단순히 현재 프로젝트에만 국한되지 않고, 이후의 프로젝트에서도 효율적이고 체계적인 협업 경험을 제공하는 중요한 경험이 될 것이라고 생각한다.
