이전 글: 사이드 프로젝트 개발 과정 - (개발 환경 조성)
배경
제품을 완성하는 완성하는 기술은 정말 많다. 내가 선택한 기술과 왜 해당 기술을 선택했는지, 또한 해당 기술들을 세팅한 과정에 대해 얘기해보려고 한다. 참고로 나는 프론트엔드 개발자다
기술 스택
Typescript
TypeScript는 타입을 미리 지정해서 사용해야 하기 때문에 Javascript보다 학습 난이도가 높지만, 코딩 작업 시 에러가 발생하는 것을 예방해 주고, 생산성과 코드의 안정성을 동시에 확보할 수 있다는 장점이있다.
요즘 프로젝트를 보면 자바스크립트로 진행되는 경우는 거의 본적이 없다.
Next.js
Next.js는 여러가지 장점이 있다. 아래와 같은 이유들 때문에 선택하게 되었다.
이미지 최적화
우리 서비스는 이미지 위주 서비스 이다. 옷, ootd의 사진을 저장하고 공유하기때문에 이미지 최적화가 잘 되어야한다고 생각했다. Next/Image기능을 통해 유저에게 빠른 이미지 렌더링, 그리고 placeholder를 통한 스켈레톤 이미지 또한 제공할 수 있다.
파일 기반 라우팅
Next.js는 파일 시스템을 기반으로 하는 라우팅을 제공한다. pages 디렉토리에 파일을 생성하는 것만으로도 새로운 페이지를 쉽게 추가할 수 있다. 이는 라우팅 설정을 간단하게 만들어주고, 프로젝트 구조를 직관적으
로 관리할 수 있게 해준다.
자동 코드 스플리팅
Next.js는 각 페이지를 자동으로 코드 스플리팅하여 각 페이지에 필요한 코드만 로드하도록 최적화한다. 이는 초기 로딩 시간을 줄이고, 애플리케이션의 성능을 향상시킨다.
SSR(서버사이드 렌더링)은요??
SSR의 경우 서버 부하가 증가가 된다. 또한SSR를 사용하는 주된 이유 중 하나가SEO때문인데, 우리 서비스는 웹이 아닌 앱이기때문에 문제가 되지 않다고 생각했다.
또한 사이드 프로젝트라는 재정적 한계가 있는 특성을 고려해SSR은 도입하지 않기로 했다.
취업후 SSR을 고려해보기로...
- 서버사이드 렌더링에 대해 많이 찾아보았지만, 제가 이해를 잘못 했을 수도 있습니다. 혹시 다른 의견 있으신분은 댓글로 남겨주시면 정말 감사하겠습니다 :)
React
요즘 vue에대한 말이 많긴 하지만 아직까진 react의 사용이 트렌드인것 같다.
나도 react를 주로 사용해왔기때문에 react를 선택했다.
styled-component
이번 프로젝트에선 디자인 시스템을 통한 디자이너와의 협업을 진행하기로 했다.
디자인 시스템은 개발 속도 향상, 일관성 등의 장점 있다. 디자인 시스템을 위한 css 스택을 선택하는 과정에서 나는 아래와 같은 장점이 있는 styled-component를 선택했다.
재사용 가능한 컴포넌트
styled-components를 사용하면 스타일이 적용된 컴포넌트를 쉽게 만들고 재사용할 수 있습니다. 이를 통해 일관된 디자인 패턴을 유지할 수 있다.
동적 스타일링
props를 통해 동적으로 스타일을 적용할 수 있어, 다양한 변형이 필요한 경우에도 동일한 컴포넌트를 사용할 수 있다.
글로벌 테마
styled-components는 글로벌 테마를 지원하여, 전체 애플리케이션의 스타일을 중앙에서 관리할 수 있게 한다.
아래는 내가 디자인 시스템을 만드는 예시이다.
theme
theme.ts
import lineHeight from './font/lineHeight';
import weight from './font/weight';
import fontSize from './font/fontSize';
import color from './colors';
const theme = {
fontSize,
lineHeight,
weight,
color,
};
export default theme;
font
design
fontSize.ts
const fontSize = {
xs: '10px',
sm: '12px',
base: '14px',
md: '16px',
lg: '18px',
xl: '24px',
xxl: '32px',
};
export default fontSize;
Body3
import styled from 'styled-components';
interface Body3State {
state?: string;
}
const Body3 = styled.p<Body3State>`
font-weight: ${({ theme }) => theme.weight.regular}; //400
font-size: ${({ theme }) => theme.fontSize.base}; //14px
line-height: ${({ theme }) => theme.lineHeight.base}; //20px
${(props) =>
props.state === 'emphasis' &&
`
font-weight: ${props.theme.weight.semibold};
`}
${(props) =>
props.state === 'underline' &&
`
text-decoration: underline;
`}
`;
export default Body3;
Component(사용 예시)
<Body3 className="taggedUser">@{taggedUserName}</Body3>
color
design
color.ts
const color = {
subdued: '#b2f8ff',
accent: '#58efff',
error: '#ec0000',
grey_100: '#ffffff',
grey_95: '#f3f3f3',
grey_90: '#dbdbdb',
...
}Component(사용 예시)
border-bottom: 2px solid ${props= > props.theme.color.grey_80};recoil
우리 서비스는 로그인을 하지 않으면 콘텐츠에 접근할 수 없도록 설계했다. 그래서 로그인한 유저의 Id 라는 상태를 전역으로 가지고 있어야하는데, 주로 atom식 전역 상태 관리를 해주는 recoil를 상태관리 라이브러리로 선택했다.
페이스북에서
recoil을 계속 업데이트 해주고 있지 않다. 게다가 페이스북에서 최근recoil에서jotai를 사용하는 pr를 업데이트한걸로 보았다. 우리 서비스도recoil에서jotai로 마이그레이션 해야할 날이 올 것 같다.
https://github.com/facebook/sapling/commit/547b205eab16fc78d73ec8edb38b2b2bdc84ddf2
환경 세팅
husky, eslint, prettier
개발자마다 코드를 작성하는 방법과 습관은 다르다. 하지만 팀 프로젝트인 만큼 코드 작성 규칙을 정하고 통일성있게 코드를 작성해야 한다. 이에 저는 git hook를 사용해 코드 작성 규칙 뿐만 아니라 커밋 메세지 또한 일관된 규칙으로 작성하게 해주었다.
husky
- commit-msg: 커밋 메시지를
commitlint로 검사한다. - pre-commit: 현재 브랜치가
main인지 확인하고,lint-staged를 실행하여 스테이지된 파일을 린트한다. - lint-staged: 스테이지된 .ts 및 .tsx 파일을
prettier, eslint로 자동 수정 및 린트한다.
아래는 커밋 규칙입니다.
commitlint.config.js
module.exports = {
// 커밋 메시지 규칙을 정의하는 기본 설정을 확장한다.
extends: ['@commitlint/config-conventional'],
// 커밋 메시지 규칙을 개별적으로 정의한다.
rules: {
// 커밋 메시지 본문의 첫 줄이 빈 줄인지 확인하는 규칙 (경고 수준 1, 항상 적용).
'body-leading-blank': [1, 'always'],
// 커밋 메시지 본문의 한 줄 길이를 최대 100자로 제한하는 규칙 (오류 수준 2, 항상 적용).
'body-max-line-length': [2, 'always', 100],
// 커밋 메시지 푸터의 첫 줄이 빈 줄인지 확인하는 규칙 (경고 수준 1, 항상 적용).
'footer-leading-blank': [1, 'always'],
// 커밋 메시지 푸터의 한 줄 길이를 최대 100자로 제한하는 규칙 (오류 수준 2, 항상 적용).
'footer-max-line-length': [2, 'always', 100],
// 커밋 메시지 헤더의 최대 길이를 100자로 제한하는 규칙 (오류 수준 2, 항상 적용).
'header-max-length': [2, 'always', 100],
// 커밋 메시지 범위(scope)가 소문자로 작성되어야 하는 규칙 (오류 수준 2, 항상 적용).
'scope-case': [2, 'always', 'lower-case'],
// 커밋 메시지의 주제(subject)가 특정한 형식을 따르지 않아야 하는 규칙 (오류 수준 2, 절대 적용).
'subject-case': [
2,
'never',
['sentence-case', 'start-case', 'pascal-case', 'upper-case'],
],
// 커밋 메시지의 주제(subject)가 비어 있지 않아야 하는 규칙 (오류 수준 2, 절대 적용).
'subject-empty': [2, 'never'],
// 커밋 메시지 주제(subject) 끝에 마침표가 없어야 하는 규칙 (오류 수준 2, 절대 적용).
'subject-full-stop': [2, 'never', '.'],
// 커밋 메시지 타입(type)이 소문자로 작성되어야 하는 규칙 (오류 수준 2, 항상 적용).
'type-case': [2, 'always', 'lower-case'],
// 커밋 메시지 타입(type)이 비어 있지 않아야 하는 규칙 (오류 수준 2, 절대 적용).
'type-empty': [2, 'never'],
// 커밋 메시지 타입(type)이 지정된 목록 중 하나여야 하는 규칙 (오류 수준 2, 항상 적용).
'type-enum': [
2,
'always',
[
'chore', // 자잘한 작업
'docs', // 문서 수정
'feat', // 새로운 기능
'fix', // 버그 수정
'refactor', // 리팩토링
'style', // 코드 포맷 변경
'test', // 테스트 코드 추가 또는 수정
'security', // 보안 관련 수정
'setting', // 설정 관련 수정
],
],
},
};
https://velog.io/@wns450/%ED%99%98%EA%B2%BD%EC%84%A4%EC%A0%95-%ED%95%B4%EB%B3%B4%EA%B8%B0-husky
env
env.local
환경변수가 작성되는곳. 이 파일은 반드시 gitignore에 추가해야한다.
개발, 테스트, 배포 환경에 따라 다를 수 있는 설정을 담는다.
예시
NEXT_PUBLIC_DOMAIN_HOST="http://localhost:3000/"env.template
환경 변수의 이름과 기본 형식을 제공하여, 프로젝트에서 어떤 환경 변수가 필요한지 명확히 한다. 팀원들이 동일한 환경 변수를 사용하도록 하여, 개발 환경 설정을 일관되게 유지한다.
새 팀원이 프로젝트에 합류할 때, .env.template 파일을 참고하여 .env 파일을 쉽게 설정할 수 있다.
constant.ts
env 파일의 변수들을 상수에 할당하는 페이지이다. 역할에 따라 dev.constant.ts와 business.constant.ts로 나누었다.
develop.constant.ts 예시
export const NEXT_PUBLIC_DOMAIN_HOST = process.env.NEXT_PUBLIC_DOMAIN_HOST;
business.constant.ts 예시
export const HELPER_TEXT_KOREAN_INITIAL = '한글 초성은 사용할 수 없습니다.';
정리
오늘은 내가 선택한 기술 스택과 선택한 이유에 대해 적어보았다. 앞으로 여러 마이그레이션을 거쳐 바뀌게 되면 수정하도록 하겠다.
- typescript
- Next.js
- styled-component
- recoil
- husky, prettier, eslint
이전글: 사이드 프로젝트 개발 과정 - (개발 환경 조성)
다음글: 사이드 프로젝트 개발 과정 - (추상화 기준 잡기)
