[원티드 프리온보딩 프론트엔드 과정] 1차 세션

먼지·2022년 12월 20일

원티드 프리온보딩 코스

목록 보기

1/2

원티드 프리온보딩 프론트엔드 인턴십

프로젝트를 하기 전 알아야 할 팀으로 일하는 법, 개발자의 기본기

1. Overview

1.1. 개발자로서 갖춰야 할 역량

흔히 업무에 필요한 역량을 말할 때 크게 두 가지로 구분지어 말할 수 있음.

업무를 수행하는데 필요한 역량, 필요한 핵심 지식과 기술을 의미하는 "하드 스킬"
업무 효율성을 극대화하기 필요한 능력인 "소프트 스킬"
개발자에게 기술적인 역량인 하드 스킬 외에 커뮤니케이션, 소통, 협업 등을 강조하는 이유는 기술적인 능력은 어느 수준으로 갖춰져 있다고 생각하기 때문임. 하드 스킬이 일정 이상일 때 소프트 스킬이 빛을 발하는 것.

1.2. 개발자에게 왜 이걸 강조할까?

개발자 혼자선 하나의 프로덕트를 만들 수 없기 때문임. 특히 프론트엔드 개발자는 업무 특성 상 흔히 기획자, 디자이너, FE 개발자, BE 개발자로 구성돼있는 제품팀에서 모든 직군들과 가장 많이 소통을 해야 하는 포지션임. 따라서 이런 생소한 영역을 청자를 고려해서 알아들을 수 있게 쉽게 풀어서 설명할 수 있는 능력을 갖추는 것이 굉장히 중요함

1.3. 소통을 잘 하려면 어떻게 해야 할까?

내가 구현한 로직을 다른 사람들에게 설명하는 것은 굉장히 어려움. 내가 생각한 것을 잘 설명하고 듣는 사람의 수준을 고려해서 이해시켜야 하기 때문임

소통은 크게 말로 하는 소통과, 문서로 하는 소통으로 나눌 수 있음

구두로 소통을 할 때는 내가 말하는 목적은 ‘상대방을 이해시키기 위함' 임을 명심해야 함. 그렇기에 내가 알고있는 것, 말하고자 하는 것을 쏟아내듯이 말하는 것이 아니라 나의 생각을 잘 정리해서 말하는 것이 중요함.
문서로 하는 소통은 일반적으로 개발자는 구두로 하는 소통보다는 문서로 하는 비동기적 소통(비실시간)을 더 많이 하고 선호함. 문서라는 단어를 들었을때는 일반적으로 구글 시트, PDF, PPT, 노션 등의 툴을 떠올릴 수도 있지만 개발자가 주로 작성하는 문서는 commit, PR, 그리고 코드임.

2. Git & GitHub을 사용하면서 지켜야 할 것

2.1. Git & GitHub의 정의

Git은 분산 버전 관리 시스템
Git을 사용해서 코드의 버전을 관리하면서 손쉽게 코드를 이전으로 롤백하거나, 분리된 환경(브랜치)에서 개발 후 다른 환경과 병합하는 등의 과정을 손쉽게 활용할 수 있음
GitHub는 Git의 원격 저장소입니다. GitHub을 이용해 개인적으로만 사용할 수 있었던 Git의 기능들을 인터넷을 이용해서 여러 사람들이게 공유하고, 팀원들과 공동으로 작업할 수 있게 돼었음
Git과 GitHub는 현재 개발 생태계에서 분산 버전 관리 시스템의 표준. 대부분의 개발팀이 Git과 GitHub 또는 GitHub과 유사한 원격 저장소 시스템(GitLab, BitBucket) 등을 활용하면서 작업함

2.2. Commit Message

Git & GitHub은 이제는 버전 관리 시스템을 넘어서서 문서와 협업 툴의 역할 또한 수행하고 있음. 개발자가 다른 개발자의 코드를 분석할 때 이 코드가 어떤 목적을 가지고 언제 작성되었는가를 확인하기 위해서 가장 먼저 확인하는 것은 Git의 Commit Message임. 커밋 메세지를 올바르게 작성하는 기본적으로 지켜져야 할 사항으로 여기에 덧붙여 개발자는 팀을 이루어서 함께 작업을 함. 그렇기에 팀 내에서 일관된 커밋 메시지 규칙을 정하는 것은 필수적.

정리

Git과 GitHub은 단순한 버전관리도구를 넘어선 문서 & 협업 툴이다.
Git의 가장 기본적인 문서인 커밋 메시지를 잘 작성하는 것은 중요하다.
팀으로 작업을 진행한다면 팀의 커밋 메세지 규칙을 정하는 것은 필수적이다.

참고자료
Commit message guidelines
How to Write Good Commit Messages: A Practical Git Guide

2.3. History 관리 및 브랜치 관리 전략

Git을 사용하면서 앞서 강조했듯이 개별 커밋 메세지도 중요하지만 프로젝트의 전체적인 흐름이 어떻게 이루어져 있는지를 보기 위해서는 전체 커밋의 히스토리를 확인하게 될 것임. 이때 master의 commit history가 뒤죽박죽하다면 맥락을 파악하기 힘듦. 그러면 history를 깔끔하게 유지하기 위해선 커밋을 유의미한 단위로만 해야 할까? 명백히 한 단위로 떨어지는 결과물일 때만 커밋을 남겨야 할까?

작업중일때는 원하는만큼 커밋을 남기되, 최종적으로 브랜치의 작업이 완료되고 PR을 통해서 master에 머지 요청을 하기 전 시점에 적절하게 원하는 형태로 커밋을 정리해주면 됨. Git에서는 squash 를 통해서 여러 커밋들을 하나로 합칠 수 있음. squash 명령을 단독으로 수행할 수는 없으며 일반적으로 rebase 동작을 하면서 interative 모드를 이용해서 squash를 진행해줌. 참고자료와 검색, 팀원과의 토론을 통해서 팀 내에서 히스토리를 어떻게 깔끔하게 관리할 수 있을지 고민해보기

참고자료
Git 스쿼시 커밋

3. ESLint와 Prettier, Git Hook을 이용한 팀의 능률 올리기

3.1. Lintter & Code Formatter

하나의 프로젝트에서 작업자마다 각자 다른 코딩 스타일을 가지고 있고, 그것이 코드에 드러난다면 이 프로젝트를 제 3자가 읽기도 어려워지며, 팀원들끼리도 다른 팀원들이 작성한 코드를 읽고 이해하기가 힘들어짐. 이를 극복하기 위해서 팀으로 작업을 할 때는 여러 작업자들의 코딩 스타일을 일치시키기 위한 Lintter와 Code Formatter를 사용하는 것이 좋음

이러한 도구들을 사용하게 되면 어떤 형태의 문법을 지향하고 지양할지, 포맷팅은 쌍따옴표를 사용할지, 홑따옴표를 사용할지 등의 여부를 고민하지 않고 코드 작성 자체에 집중할 수 있도록 도와줌

자바스크립트 진영에서는 Linter로 ESLint를, Code Formatter 로는 Prettier를 사용하는것이 일반적임. ESLint는 코드 자체의 문법 교정과 더불어 코드 스타일링 기능도 포함하고 있음. 하지만 Prettier는 자동으로 코드의 스타일을 맞춰주는 것에 포커스돼있어서 빈번히 ESLint와 함께 사용됨.

코딩스타일은 팀에서 정할 수 있지만 이를 개인에게 위임한다면 강제성이 없기에 취약함. 불필요한 에너지 소모를 줄이기 위해서 코딩 스타일 자동화 툴이 필요함. 따라서 자동화 될 수 없는 컨벤션은 최소화 하는것이 좋고 필요한 경우에는 반드시 문서화 시켜야 함. 이런 자동화 툴들은 아무것도 없이 시작하는 것 보다 초기세팅은 다소 복잡할 수 있지만, 한번 해두면 지속적인 개발 생산성 향상에 도움을 줌.

3.2. ESLint

일관되고 버그를 피할수 있는 코드를 짜기위해서 만들어진 코드 분석 툴
작성된 코드의 구문을 분석하여 버그가 발생할 여지가 있거나, 불필요한 코드, 혹은 보안상 위험한 코드 등에 대한 경고를 띄워준다.
설정 커스터마이징을 허용해주기 때문에 필요한 규칙들을 커스텀해서 적용가능하다.

3.3. Prettier

코드 포맷팅 툴로, 포맷팅 룰을 커스터마이징할 수 있다
코드의 포맷팅을 툴을 사용함으로서 팀원 모두가 같은 포맷팅스타일을 공유할 수 있게 된다.
그로인해서 개발자는 포맷팅등 다소 중요하지 않은 요소들에 에너지를 낭비하지 않고 핵심적인 개발에 집중할 수 있게 된다.

4. 설치

4.1. eslint

npm install eslint --save-dev

4.2. prettier

npm install prettier --save-dev

4.3. eslint-config-prettier

eslint는 linting 기능을, prettier는 formatting을 담당하는 구조가 이상적이지만, eslint에는 일부 formatting 관련된 rule도 포함되어 있음
이 rule들이 prettier와 다른 설정을 가지고 있다면 설정 충돌이 발생함. 따라서, eslint에서 formatting 관련 rule들을 모두 해제해야할 필요가 있음 수동으로 진행할 수도 있지만, 이를 적용해주는 eslint plugin이 존재

npm install eslint-config-prettier --save-dev

4.4. optional

package들을 설치하면 terminal에서 명령어를 통해서 eslint와 prettier를 실행할 수 있음. IDE에서는 일반적으로 terminal 명령어로 실행하는 것 뿐만 아니라, 에디터 차원에서 파일을 저장할 때 formatting을 적용해주고, 에디터에서 eslint의 메세지들을 확인할 수 있게 해주는 기능들을 플러그인 형태로 제공하기에 원할시 사용할 수 있음

5. 설정

위와 같이 패키지들을 설치하면 이제 eslint와 prettier를 사용할 수 있지만 아직 팀원들간의 일관적인 규칙을 적용하지는 않은 상태임. 실제 프로젝트에서는 팀에 맞게 커스터마이징해서 사용하며, 팀원들간 항상 똑같은 설정을 사용하는 것이 보장되어 있어야 하기에 eslint와 prettier는 프로젝트내에 설정파일을 이용해서 설정을 공유하고 적용하는 방법을 제공해주고 있음

5.1 Prettier 설정

프로젝트의 루트 디렉토리에 .prettierrc.확장자 파일을 통해서 설정을 할 수 있음. 설정파일의 확장자 형식은 다양하게 지원하고 있음. (JSON, YAML, JS, TOML)

// .prettierrc.js

module.exports = {
	printWidth: 100, // printWidth default 80 => 100 으로 변경
	singleQuote: true, // "" => ''
    arrowParens: "avoid", // arrow function parameter가 하나일 경우 괄호 생략
};

참고자료
Options · Prettier

5.2. ESLint 설정

eslint 설정은 커스터마이징 할 수 있는 부분이 많고, 언어별(js, ts 등), 환경별(web, node, react 등) 세팅을 해줘야 하는 부분이 많아서 다소 복잡함. 처음부터 모든 rule 하나하나 설정하는 것이 불필요하거나 불편하다고 판단되는 경우와 다른 사람들이 이미 정의해둔 config를 설치한 후 확장해서 사용가능. eslint에서 기본적으로 제공되지 않는 특정 환경을 위한 rule들을 추가하고 싶을 경우에는 plugin을 이용할 수 있음.

// .eslintrc
    
{
	"extends": ["react-app", "eslint:recommended"],
    "rules": {
	    "no-var": "error", // var 금지
        "no-multiple-empty-lines": "error", // 여러 줄 공백 금지
        "no-console": ["error", { "allow": ["warn", "error", "info"] }], // console.log() 금지
        "eqeqeq": "error", // 일치 연산자 사용 필수
        "dot-notation": "error", // 가능하다면 dot notation 사용
        "no-unused-vars": "error" // 사용하지 않는 변수 금지
    }
}

참고자료
Rules - ESLint - Pluggable JavaScript Linter
Configuration Files - ESLint - Pluggable JavaScript Linter
Plugins - ESLint - Pluggable JavaScript Linter

6. Husky

6.1. 도입배경

eslint와 prettier를 도입한다고 끝이 아님. 아무리 패키지를 설치하고 룰을 설정해도 작업자가 사용을 안 하면 효과가 없음. (귀찮은데 린트 꺼야지=스파이) 개인이 매번 확인해서 실행하는 것은 실수가 발생할 여지가 있으며 강제성이 없기 때문에 자동화를 통해 자동으로 적용되게 특정 상황에서 강제로 적용되게 하는 것

6.2. 문제해결방안

자동화를 통해서 신경쓰지 않아도 자동으로 적용이 되게하고 특정 상황에서 강제로 적용이 되게 하자. commit된 코드는 무조건 formatting이 완료되어야 하고, push된 코드(중요)는 무조건 eslint가 pass된 상태에서 push가 되도록 자동화를 구축해야 함

6.3. 실행방안

git hook 도입! git hook 이란? git에서 특정 이벤트 발생하기 전, 후로 특정 hook 동작을 실행할 수 있게 하는 것. (ex. commit, push 전후) git hook 설정은 까다롭고, 모든 팀원들이 사전에 repo를 클론 받고 메뉴얼하게 사전 과정을 수행해야지만 hook이 실행됨을 보장할 수 있음. git hook 세팅 이런 것도 자동화되면 좋겠다.. 해결법은? husky라는 라이브러리

6.4. Husky

Husky - Git hooks

husky는 git hook 설정을 도와주는 npm package로, 번거로운 git hook 설정이 편하고 npm install 과정에서 사전에 세팅해둔 git hook을 다 적용시킬 수 있어서 모든 팀원이 git hook 실행이 되도록 하기가 편함. husky를 통해서 모든 팀원이 신경 쓰지 않고도 pre-commit, pre-push hook을 설정 가능함

얘는 개발용 Zero dependencies로, husky가 의존하는 또다른 라이브러리가 없어서 다른 라이브리가 수정돼도 허스키가 안 돌아가지 않는다는 것! 그래서 안정적이고 가벼워서 번들 사이즈에 크게 영향을 미치지 않음.

6.5. Husky를 통한 Git Hook 적용

npm install husky --save-dev
npx husky install (처음 husky 세팅하는 사람만 실행 필요)
1. npx husky install : husky에 등록된 hook을 실제 .git에 적용시키기 위한 스크립트
2. add postinstall script in package.json
  - 이후에 clone 받아서 사용하는 사람들은 npm install후에 자동으로 husky install 이 될 수 있도록 하는 설정

// package.json

{
	"scripts": {
	    "postinstall": "husky install"
    },
}

scripts 설정

// package.json
   
{
    "scripts": {
	    // 푸시전에항상💩
        "postinstall": "husky install",
    	"format": "prettier --cache --write .",
    	"lint": "eslint --cache .", // 에러가발견되면스크립트중단됨
    },
}

add pre-commit, pre-push hook
1. npx husky add .husky/pre-commit "npm run format"
2. npx husky add .husky/pre-push "npm run lint"

6.6. 참고사항

git hook에서 eslint 에러가 발견하면 실행중인 script가 종료되기에 이 rule에 대해서 error로 설정할 지 warn으로 설정할 지 잘 고려해야함

예시

아래와 같이 되어있으면 console.log 코드가 있어도 푸쉬가 되지만

"no-console": ["warn", { "allow": ["warn", "error", "info"] }]
error로 설정할 경우 console.log가 하나라도 있으면 푸쉬가 안됨
"no-console": ["error", { "allow": ["warn", "error", "info"] }]

참고사항

린트에서 warning도 엄격하게 하나도 허용하지 않으려면
eslint --max-warings=0 으로 옵션을 붙여서 스크립트를 실행하면 됨

// package.json

{
  "scripts": {
		"lint": "eslint --cache --max-warnings=0",
  },
}

마무리

라이브러리 설치 전에 얘가 진짜 필요한가? 얼만큼 무거운가? 용량 번들 사이즈를 고려하거나 어떤 기술을 사용하기 전에 이게 왜 나왔는지, 어떤 게 불편해서 어떤 문제를 해결하기 위해 나왔는지 진지하게 생각해본 적이 거의 없다.

그냥 요즘 인기가 많고 프론트엔드 개발자라면 써야 한다니까 공식 문서를 보지 않고 빠르고 쉽게 배우기 위해 강의릍 통해 학습하다 보니 점점 이런 방법에 익숙해져서 새로운 기술을 배울 때 이해가 잘되지 않아 배우는데 시간이 오래 걸렸던 것 같다..

세션 1차 강의를 들으면서 내가 가볍게 알고 있던 내용을 한 번 더 짚고 갈 수 있어서 좋았고, 개발자가 뭔지 생각할 수 있는 좋은 시간이 됐다. 기술 역량, 소통, 커밋 메시지, 협업, 이걸 왜 배우는지 등 중요하고 알고 있지만 제대로 지키지 않는 것들을 앞으로 열심히 하나하나 체크해가면서 개발 공부를 해야겠다!

먼지

꾸준히 자유롭게 즐겁게