서론
내가 활동중인 동아리에서 진행하던 프로젝트가 마무리에 들어서면서 개발할 기능도 거의 마무리되어 딱히 할 일이 없던 찰나, 동아리 채팅방에 신규 프로젝트를 진행한다는 글을 보게 되었다.
이때까지만 해도 2~3주면 프로젝트가 끝나는줄 알고있었다.
남는게 시간이고, 이전에 하던 프로젝트를 하면서 개발에 약간의 자신감을 가지게되면서 지원하게 되었다.
다만, 0부터 시작하는 프로젝트가 처음이였고, 2~3명이서 개발을 진행하는데, 나 때문에 개발에 지장이 생기면 어떡하지?하는 걱정이 밀려왔다. 그래도 이 프로젝트가 도움이 될거라고 생각하고 진행하게되었다.
기술스택
0부터 시작하는 프로젝트였기에, 나 포함 팀원들이 모여 회의를 하면 사용할 기술스택을 정했다.
이전 프로젝트까지는 CRA를 이용하여 React프로젝트를 생성했지만, 이번에는 Vite를 사용하기로 결정하였다.
Vite
Vite는 CRA에 비해 장점이 많다.
일단 빠르다!
Vite를 사용하지 않는다면, Webpack이 빌드작업을 마쳐야 페이지가 제공되어, 페이지가 렌더링되기까지 시간이 걸렸다.
하지만 Vite는 Native ESM을 이용하여 소스코드를 제공하며, 이는 브라우저가 번들러의 작업을 차지하도록 한다.
즉, Vite는 브라우저가 요청하는 소스코드를 변환하고 제공하기만 하면 되기때문에 최초실행시간이 굉장히 빨라지는것이다.
또한, 기존의 번들러 기반의 개발은 코드가 업데이트되면 번들링 과정을 다시 거쳐야하지만, Vite는 수정된 모듈만 교체하기에, 갱신 시간에 그다지 영향을 주지 않는다.
스타일
이번 프로젝트는 메인프로젝트가 아닌 사이드프로젝트로서 UI/UX 트랙없이 진행하는 프로젝트였기에, 디자인도 프론트엔드가 맡아서 해야했다.
하지만, 프론트엔드가 퀄리티 있는 디자인을 하는것은 쉽지 않은 일이기에 디자인 프레임워크로 MUI를 사용하기로 하였다.
또한 Styling 라이브러리도 정해야 했는데, 이전 프로젝트들은 SCSS에 BEM 방법론을 적용하여 사용하고 있었다. 하지만 이 방법은 styled-components에 비해 불편했고, styled-components를 적용하려고 했지만, styled-components에 가장 큰 단점이 존재했다.
<S.Container>
<Button/>
<S.Container/>위 처럼사용되기에 컴포넌트와 스타일이 구분이 안갈뿐더러, 스타일에 적용한 태그가 <div>인지 <span>인지 구분하기가 매우 어려웠다.
그래서 이번에는 styled-components의 단점을 모두 해결한 Emotion을 사용하기로 했다.
@emotion/react를 사용하면 컴포넌트와 스타일도 구분되고, 스타일이 적용되는 태그를 확인할 수 있으며, 스타일컴포넌트의 편리성도 챙길 수 있다.
<div css={S.Container}>
<Button/>
<div/>태그와 스타일과 컴포넌트가 모두 명확히 구분된다!!
다만 위처럼 사용하기 위해서는 사전 환경설정이 필요하다.
환경설정없이 위와같이 사용하기 위해서는 사용하는 파일에서 다음과 같이 작성해줘야 한다.
/** @jsxImportSource @emotion/react */
import { css } from '@emotion/react'; 환경설정을 한다면 다음과 같이 적용하면 된다.
.eslintrc.cjs의 rules에 다음 규칙을 적용하여 lint에러를 꺼주자.
"react/no-unknown-property": ["error", { ignore: ["css"] }],
.tsconfig.json의 compilerOptions에 다음 내용을 추가해주자.
"jsxImportSource": "@emotion/react",
yarn berry
이전 프로젝트에서는 yarn 1버전을 사용하고 있었다.
새로운 프로젝트를 만드는 겸, yarn 버전을 높이기로 결정하였다.
yarn berry는 yarn과 다르게 장점이 되게 많았다.
Plug'n'Play
기존의 node_modules대신 패키지 정보들은 .zip 형태로 .yarn/cache에 저장하고 의존성 트리 정보를 .pnp.cjs에 저장한다.
이를 통해 의존성 검색을 최적화 할 수 있게되었다.
Zero install
패키지 정보를 .yarn/cache에 저장하고 파일들을 github에 올릴 수 있게되면서 패키지 설치가 필요없게 되었다. 기존에는 다른 개발자가 라이브러리를 설치했을 때 yarn install을 해주지 않으면 에러가 발생했으나, 이제는 별도의 설치과정이 필요없다!
개발환경 구축
지금까지 이미 만들어진 프로젝트에서 기능을 추가하거나 수정하기만 한 나로서는 초기 개발환경 구축이 얼마나 편리한 개발경험을 제공해주는지 알지 못했다.
초기 개발환경 구축에서 많은 어려움이 있었는데 정리해보고자 한다.
Github Actions
.github/workflows에 lint check과정을 추가하여 PR을 올렸을 때 자동으로 lint check를 해주며, 개발자의 실수를 방지할 수 있다.
절대경로 사용
기본적으로 React에서는 상대경로를 사용하게 된다. 하지만 상대경로는 다른 폴더의 파일을 참조할 때 굉장히 길어지고, 복잡해질 수 있다.
상대경로를 사용하기위해서는 초기설정이 필요하다.
이번 프로젝트에서 사용한 기술스택은 React+Vite+Typescript이기 때문에 여기에 맞는 환경설정을 해주었다.
vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import tsconfigPaths from 'vite-tsconfig-paths';
// https://vitejs.dev/config/
export default defineConfig({
base: './',
plugins: [react(), tsconfigPaths()],
});tsconfig.json
{
"compilerOptions": {
"baseUrl": "./src",
}
}이제 상대경로를 다음과 같이 사용할 수 있게 된다.
import { acceptMember } from 'api/admin';ESLint
이전 프로젝트와 다르게 Vite환경에서 airbnb 플러그인을 적용하면서 초기설정방법이 약간 달라졌다.
다음과 같은 초기설정을 해주도록 하자. 기본 설정에서 추가되는 내용만 정리해보았다.
.eslintrc.cjs
module.exports = {
extends: [
'airbnb',
"airbnb/hooks",
"airbnb-typescript"
],
ignorePatterns: ['dist', '.eslintrc.cjs', 'vite.config.ts'],
parserOptions: {
ecmaVersion: 'latest',
sourceType: 'module',
project: './tsconfig.json',
},
settings: {
'import/resolver': {
node: {
extensions: ['.js', '.jsx', '.ts', '.tsx'],
},
},
},
}env파일 환경설정
Vite는 기존 CRA와 env 파일을 import해서 사용하는 방식이 다르다.
export const API_PATH = import.meta.env.VITE_REACT_APP_API_PATH;
CRA와 사용방법이 다른 것을 확인할 수 있다.
또한, 환경 변수의 타입을 정의하여 env파일을 import하여 사용할 때 추론이 되도록 하였다.
/// <reference types="vite/client" />
export type EnvVar = {
VITE_NODE_ENV: 'development' | 'production';
VITE_REACT_APP_API_PATH: string;
};
declare global {
interface ImportMetaEnv extends EnvVar {}
}이제 import.meta.env.까지만 작성해도 나머지가 추론되도록 사용할 수 있다!
본격적인 개발시작
기술스택 선정부터 초기환경설정까지 거의 일주일이 걸렸다..
이 프로젝트는 2~3주짜리 단기 프로젝트가 아니라 2~3주짜리 스프린트였던것이다!
단순 단기 프로젝트라면 개발이 약간 밀려도 추후 일정에 영향이 없겠지만, 스프린트이기 때문에 개발일정에 차질이 생긴다면 다음 스프린트 일정에도 영향을 줄게 분명해보였다.
개발일정을 맞추기 위해 일주일동안 개발에 몰입했던 것 같다.
스프린트?
소프트웨어 개발 방법론 중 애자일 방법론으로 작은 규모의 개발을 짧은 개발 주기를 반복하여 요구사항을 구현하는 방법이다.
후기
일주일 동안 나를 비롯한 팀원들이 목표한 MVP기능을 모두 구현해냈다.
짧은 단위로 작업이 이뤄지는 스프린트 특성상 코드 퀄리티가 좋다라고는 못하겠지만, 기능을 구현하는 속도는 확실히 빠르긴 했다. 코드 퀄리티는 동아리 소그룹인 리팩토링 그룹에서 레거시 코드를 보면서 챙겨야할 것 같다.
이전까지 장기간의 프로젝트만을 진행하면서 구체적인 코드리뷰와 코드 컨벤션에 신경을 쓰면서 기능을 구현해내는 속도가 많이 느려졌고, 데드라인이 없다보니 작업이 루즈해지는 경향도 없지 않았던 것 같다. 이번에 스프린트로 개발을 진행하면서 약간의 코드 컨벤션을 포기하고 데드라인이 정해져 있다보니 빠른속도로 기능을 구현할 수 있었던 것 같다.
0부터 시작하는 프로젝트 그리고 짧은 단위의 스프린트. 정말 좋은 경험이였고, 많이 성장할 수 있었던 시간이였다.
