개발 블로그

Section 4 회고록

시간이 정말 빠르게 지나갔다. 내 시간 어디로 갔지? 6월에 시작했던 게 엊그제 같은데 벌써 프로젝트를 앞두고 있다. 프로젝트가 가까워지니까 이상하게 알 수 없는 자신감이(ㅋㅋ?) 생겨서 프로젝트보단 부트캠프 종료 후 취업이 더 걱정되기 시작했다. 포트폴리오를 만들려면 개인 프로젝트도 몇 개 더 해야할 텐데... ... 아이디어가 없다 (ㅠ) 서버쪽도 자신이 없어서 혼자서 잘 만들 수 있을까? 걱정이 태산이다. 

이건 딴 이야기지만 디자인할 땐 기획하고, 와이어프레임 만드는 게 너무너무 싫었는데 막상 코딩하니까 피그마로 기획하는 게 제일 할 만하더라 ㅋㅋㅋㅋㅋ 익숙함에 속아 소중함을 잊지 말자 (이거 아님) 디자인도 막상 할 땐 싫었지만 지금 와서 하니까 할만한 것처럼 코딩도 지금은 뭣같이 어려워서 아방방하게 울기만 할지라도 나중엔 뭐... 언젠가 할만해지는 날이 오지 않을까? 하고 생각한다. 

목표 상기

부트 캠프 무사 졸업

⇒ 코딩에 '코'도 모르는 사람을 이해시킬 수 있을 정도의 지식 갖추기

⇒ 1인분 하는 개발자 되기

2023년도 취업

⇒ 개인 프로젝트를 열심히 만들어 보자. 포트폴리오도 어떻게 만들 건지 생각해 두자.

Keep

1. 나 스스로가 선택한 길임을 잊지 말고 끝까지 최선을 다해보기
2. 건강 관리하기
3. 스트레스 관리하기

Problem

• 나 스스로가 선택한 길임을 잊지 말고 끝까지 최선을 다해보기 
  •  남들보다 뒤쳐지는데 노력도 열심히 안 하는 내 모습을 보며 은은하게 스트레스 축적되고 있는 거 같다.
• 건강 / 스트레스 관리하기
  • 원래 있던 지병이 오락가락한다. 좋을 때도 있고, 나빠질 때도 있고... 수면 패턴이랑 스트레스 때문인 거 같다.

Try

1. 계획적으로 살기

⇒  원래 계획하고 실행하는 것을 좋아하는 성격이다. (대신 계획대로 안 되면 2배로 스트레스를 받지만) 요샌 그래도 섹션 3때 보다 스트레스도 줄고, 번아웃도 괜찮아진 거 같아서 널널하게 일일계획을 짜고 실행하면서 계획적으로 사는 것에 시동을 좀 걸려고 노력하고 있다. 처음부터 빡빡하게 일정 짜고 공부하는 것보단 다시 습관 들이듯 하는 것이 계획대로 안 됐을 때 스트레스를 덜 받을 수 있을 것 같았기 때문이다.

2. 까먹지 말기

⇒  요새 청년 치매가 심각해진 거 같다. 안 적어두면 찜찜~하게 "뭐 해야됐던 거 같은데?" 하고만 기억이 나서 찜찜~하고 은은~하게 스트레스도 쌓여서 바로바로 메모장이나 플래너에 적어두려고 하고 있다. 

3. 까먹지 말기

⇒  요새 청년 치매가 심각해진 거 같다. 안 적어두면 찜찜~하게 "뭐 해야됐던 거 같은데?" 하고만 기억이 나서 찜찜~하고 은은~하게 스트레스도 쌓여서 바로바로 메모장이나 플래너에 적어두려고 하고 있다. 

마치며...

 섹션 4는 생각보다 빠르게 끝난 거 같다. 어려운 내용이 많았고, 이해가 안 되는 것들이 많지만 결국은 부트캠프 내내 한 이야기를 하고 있다는 생각이 든다. 오늘 배운 것이 일주일 전에 배운 거랑 이어진다거나... 이런 식으로 말이다. 코딩에 대해 찾아보다 보면 워낙 방대하고 프로그래밍 언어가 많다보니 뭐부터 배워야할 지 난감한데 부트캠프를 수료하면서 뭐부터 배우면 좋은 지에 대해 알게 되었다.

 페어 프로그램도 해 보기 전까진 으... 싶었는데 좋은 분들을 많이 만났고, 이런저런 대화를 해 보면서 세상 돌아가는 이야기도 듣고~ 어떻게 공부하고 계신지도 듣고~ 많은 도움과 공부 자극이 되었던 거 같다. 어려운 문제도 머리 하나보단 둘이 맞대니까 좀 더 쉽게 풀 수도 있었다.

 공부를 정말 코피날 정도로 열심히 해 본 기억은 없어서 내가 정말 코딩쪽 길이 맞는 걸까? 라는 생각이 자주 들었다. 코드를 제대로 짜고 있는 거 같지도 않고... 지식도 어정쩡하고... 차라리 실력을 갈고 닦아 그림 쪽으로 나가는 게 낫지 않을까 하는 생각도 자주 했는데... 그럴 때마다 이 시를 보며 마음의 위안을 얻었던 것 같다. 40기 아자아자 파이팅!

JavaScript

• Hoisting과 Temporal Dead Zone이 어떻게 연관되어 있는지 설명하세요.

=> 호이스팅은 선언되지 않은 함수, 변수를 import 구문으로 상단으로 끌어올려 사용할 수 있게 하는 방식을 뜻합니다.

브라우저 렌더링

• 브라우저 렌더링 방식에 대해 설명하세요.

=> 우선 HTML과 CSS 파일을 파싱해서 각각 DOM tree를 만듭니다. 그 다음 두 tree를 결합해 렌더링 tree를 만들고, 렌더링 tree에서 각 노드의 위치와 크기를 계산합니다. 계산된 값을 이용해 각 노드를 화면상의 실제 픽셀로 변환하고, 레이어를 만듭니다. 그 다음 만들어진 레이어들을 합성하여 실제 화면으로 나타냅니다.

• 리플로우와 리페인트에 대해 설명하세요.

=> 리플로우와 리페인트는 DOM 요소가 시각적으로 변경되었을 때, 다시 계산하고 화면에 그려주는 역할을 합니다. 리플로우는 발생하는 변화들에 맞춰 다시 계산 작업을 하는 역할을 하고 레이아웃이라고 부르기도 합니다. 리페인트는 다시 계산되어 변경된 요소들을 실제 화면에 그려주는 작업을 합니다. 그러므로 리플로우가 발생하면 필연적으로 리페인트도 따라옵니다.

• 반응형 웹은 무엇이고 장단점에 대해 설명하세요.

=> 반응형 웹이란 다양한 디바이스 환경에서 원활하게 렌더링되는 웹 페이지를 뜻합니다.

 반응형 웹의 장점은 모든 기기에서 최적화된 웹사이트를 제공할 수 있다는 점, 모바일과 웹사이트 두 가지 버전을 만들지 않아도 되기 때문에 비용, 시간, 인력을 줄일 수 있고 유지보수가 쉽다는 점, 검색엔진 노출이 용이하다는 점이 있습니다. 

 반응형 웹의 단점으론 사용자가 다른 기기로 이용할 생각이 없는데도 모든 기기를 위한 css를 전부 다운로드 해야하기 때문에 데이터를 낭비하고, 로딩 시간이 길어진다는 점이 있습니다.

• 자바스크립트 엔진의 콜 스택이 무엇인지 설명할 수 있나요?

=> 콜 스택이란 메모리 영역에서 스택 영역에 해당하며, 함수의 호출을 기록하는 스택 자료구조입니다.

번들링과 웹팩

• 번들링은 왜 필요한가요?

=> 번들링은 모듈간의 의존성을 파악해서 그룹화를 시켜주는 작업을 뜻합니다. 여러 개의 파일을 브라우저에서 로딩한다면 속도가 느려지고, 모듈 간의 변수 충돌 등 위험성이 존재하기 때문에 분리되어 있는 파일들을 하나로 묶어주는 번들링 작업이 필요합니다. (난독화 내용 추가) 

React

• Virtual DOM이 무엇이고, Virtual DOM이 어떤 면에서 좋은가요?

=> 버추얼 돔은 가상의 돔 객체로 실제 돔의 가벼운 사본 같은 개념입니다. 돔은 계층적 구조로 되어 있는 트리이기 때문에 저장된 데이터를 효과적으로 탐색하는 것에 초점이 맞춰있습니다. 실제 돔을 조작하는 일은 브라우저에 실제로 그리기 때문에 느리지만, 가상의 돔은 변화 전과 후를 비교하고 바뀐 부분만 적용하기 때문에 훨씬 속도가 빠르다는 장점이 있습니다. 또한 버추얼 돔을 사용하면 실제 DOM은 최소한의 작업만 수행하기 때문에 DOM의 업데이트 비용을 줄일 수 있다는 장점도 있습니다.

• Class Component와 Function Component의 차이점이 무엇인가요?

=> 

• React Hook의 사용 규칙에 대해 설명하세요.

=>

운영체제

• Node.js는 싱글 스레드인가요?

=> 

• JavaScript는 싱글 스레드입니다. 어떻게 싱글 스레드 방식으로 비동기 호출을 할 수 있는 지에 대해 설명할 수 있나요?

=> 

• Event Loop에 대해 설명할 수 있나요?

=> 

• 가비지 컬렉션이란 무엇이며, 가비지 컬렉션을 가진 언어에는 무엇이 있나요?

=>

자료구조

• Stack과 Queue의 차이점은 무엇인가요?

=> 

• Tree와 Graph의 차이점은 무엇인가요?

=> 

• 이진 탐색 방법에 대해 설명할 수 있나요?

=> 

CORS 정책이 필요한 이유

- 기본적으로 브라우저의 현재 주소와 요청한 API의 주소의 도메인이 일치해야 데이터에 접근할 수 있다.

- 다른 도메인에서 API를 요청해 사용할 수 있게 하려면 CORS 설정이 필요하다.

CORS

• 교차 출처 리소스 공유.
• 추가 HTTP 헤더를 사용해, 실행 중인 웹 애플리케이션이 다른 출처의 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제.

출처

• 웹 콘텐츠의 출처(origin)은 접근할 때 사용하는 URL의 스킴(프로토콜), 호스트(도메인), 포트로 정의된다. 두 객체의 앞의 3가지가 모두 일치하는 경우 같은 출처를 가졌다고 한다.
• 일부 작업은 동일 출처 콘텐츠로 제한되나, CORS를 통해 제한을 해제할 수 있다.

=> 로컬 환경(3000포트)에서 개발한 프로젝트를 클라이언트 서버의 API로 요청하게 되면, 차단되는 것을 경험할 수 있다. 하지만 귀찮다고 모든 출처의 접근을 허락한다면 보안성이 현저히 낮아지고, 해킹의 위험에 노출되게 된다. (DB에 쌓인 라이브 데이터가 갈취당하게 될 수도...)

=> 따라서, 모든 도메인이 아닌 특정 도메인만 허용하도록 구현해야 한다.

CORS 에러 해결 방법

프론트엔드가 백엔드에게 개발 서버 도메인을 허용해달라고 요청하고, 백엔드가 응답 헤더에 필요한 값을 담아 전달해야 한다.

(서버에서 적절한 응답 헤더를 받지 못하면 브라우저에서 에러가 발생하기 때문)

혹은 Proxy를 이용해 해결 가능하다.

Proxy 란?

: 프론트엔드가 백엔드에게 요청을 하고, 응답을 받고 하는 과정없이 CORS 정책을 우회할 수 있도록 만들어 준다.

• proxy를 사용해 CORS 정책을 우회하면,
  • 백엔드 서버는 응답을 React 앱으로 보내고, React 앱은 받은 응답을 백엔드 서버 대신 브라우저에게 전달하기 때문에 출처가 같아지게 된다.
• 리액트 앱이 서버로부터 받은 응답 데이터를 다시 브라우저로 전달하는 방법을 쓰기 때문에 브라우저는 CORS 정책을 위반한지 모른다.
• 별도의 응답 헤더를 만들 필요없음.

(1) Webpack Dev Server

브라우저 API를 요청할 때 백엔드 서버에 요청하지 않고, 현재 개발서버의 주소로 우회 요청을 하게 됨.

-> 웹팩 개발 서버에서 해당 요청을 받아 백엔드 서버로 전달함

-> 백엔드 서버에서 응답한 내용을 다시 브라우저쪽으로 반환함

웹팩 개발서버의 proxy 설정값은 웹팩 설정을 통해 적용하지만, 

CRA를 통해 만든 리액트 프로젝트에선 package.json에 "proxy" 값을 설정해주면 됨.

...
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
	"proxy" : "우회할 API 주소"
}

그리고 기존의 fetch 혹은 axios를 통해 요청하던 부분의 도메인을 수정함.

//수정전
export async function getAllfetch() {

    const response = await fetch('우회할 api주소/params');
    .then(() => {
			...
		})
}

//수정후
export async function getAllfetch() {

    const response = await fetch('/params');
    .then(() => {
			...
		})
}

(2) htttp-proxy-middleware 

위의 (1) 방법의 프록시는 전역설정이기 때문에, 종종 적용되지 않을 수도 있다.

그래서 수동으로 프록시를 설정해줘야 하는 상황이 발생할 수 있는데, 이때는 http-proxy-middleware 라이브러리를 사용해야 한다.

우선 npm으로 라이브러리 설치

npm install http-proxy-middleware --save

'src/setupProxy.js' 파일 생성 후 아래와 같이 작성

const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = function(app) {
  app.use(
    '/api', //proxy가 필요한 path prameter를 입력합니다.
    createProxyMiddleware({
      target: 'http://localhost:5000', //타겟이 되는 api url를 입력합니다.
      changeOrigin: true, //대상 서버 구성에 따라 호스트 헤더가 변경되도록 설정하는 부분입니다.
    })
  );
};

기존의 fetch 혹은 axios를 통해 요청하던 도메인 부분 수정.

//수정전
export async function getAllfetch() {

    const response = await fetch('우회할 api주소/params');
    .then(() => {
			...
		})
}

//수정후
export async function getAllfetch() {

    const response = await fetch('/params');
    .then(() => {
			...
		})
}

CI/CD란?

- CI : 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미함.

• CI를 성공적으로 구현할 경우, 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결 가능.

- CD : 지속적인 서비스 제공 및/또는 지속적인 배포를 의미함. (제공과 배포는 상호 교화적으로 사용됨)

• 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻함.
• 어쩔 때는 얼마나 많은 자동화가 이루어지고 있는 지를 설명하기 위해 별도로 사용되기도 함

CI/CD 단계

일반적인 앱의 개발 및 유지보수 단계

PLAN -> CODE -> BUILD -> TEST -> RELRASE -> DEPLOY -> OPERATE -> PLAN ...

+

지속적인 통합 (CI)

: 개발자를 위한 자동화 프로세스. 코드 - 빌드 - 테스트 단계에서 꾀할 수 있음

• Code : 개발자가 코드를 원격 코드 저장소(깃헙 리포지토리라던가) 에 push 하는 단계
• Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
• Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정

- 장점

• 보안 이슈, 에러 등을 쉽게 파악해 빠르게 개선 가능.
• 테스트가 완료된 코드를 빠르게 전달 가능.
• 지속적인 배포 가능.

지속적인 배포 (CD)

: 지속적인 서비스 제공 및 지속적인 배포를 의미. 릴리즈 - 디플로이 - 오퍼레이트 단계에서 꾀할 수 있음.

• Release : 배포 가능한 소프트웨어 패키지를 작성
• Deploy : 프로버저닝 ()을 실행하고 서비스를 사용자에게 노출함. 실질적 배포 부분.
• Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지함.

- 장점

• 운영팀이 빠르고 쉽게 애플리케이션을 프로덕션으로 배포할 수 있음.

지속적인 배포 사례

깃헙 페이지.

지정한 디렉터리에 정해진 방식에 따라 잘 커밋만 하면 깃헙 페이지가 알아서 해당 index.html 파일을 해당 디렉터리에 있는 파일들을 잘 번들링해서 깃헙 페이지 서버에 업로드함. (자동으로 인터넷에 배포)

배포 자동화

- 필요한 이유

• 수동적이고 반복적인 배포 과정을 자동화해서 시간 절약 가능
• 휴먼 에러를 방지할 수 있음
  
  • 휴먼 에러란? 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수를 뜻함.

CI/CD 파이프라인

: 배포 과정을 자동화시키는 방법을 뜻함.

배포 과정

1. 개발자가 코드를 원격 저장소에 push

2. (code) 코드 저장소

3. (build, test, release) 테스트/ 빌드 서버

4. 모든 과정을 통과한 빌드를 배포 서버로 전달 -> (deploy) 프로비저닝 배포 서버

6. 애플리케이션 서버 (결과물을 유저가 확인)

=> 코드가 빌드 되고, 최종적으로 배포되는 단계까지를 일련의 자동화 단계로 만드는 것을 "파이프라인을 구축한다"고 표현함.

CI/CD 파이프라인을 구성하는 기본 단계와 수행 작업

파이프라인 : 소스 코드의 관리부터, 실제 서비스로의 배포 과정을 연결하는 구조를 뜻함.

  전체 배포 과정을 여러 단계로 분리함. 각 단계는 파이프라인 안에서 순차적으로 실행되며, 각 단계마다 주어진 작업(Actions)을 수행함.

• Source 단계 : 원격 저장소에 관리되고 있는 소스 코드에 변경사항이 생길 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행.
• Build 단계 : 앞에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공함. 단계를 거쳐 생성된 결과물을 다음 단계로 전달함.
• Deploy 단계 : 전단계에서 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행.

파이프라인 구성 요소 및 장점

• 빌드 (소프트웨어 컴파일)
• 테스트 (호환성 및 오류 검사)
• 릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
• 배포 (개발에서 프로덕션 환경으로의 변환)
• 규정 준수 및 유효성 검사

Github Actions이란?

: 깃헙이 공식적으로 제공하는 빌드, 테스트, 배포 단계 파이프라인을 자동화할 수 있는 CI/CD 플랫폼

• 레포지토리에서 Pull Request, Push 같은 트리거로 깃헙 작업 워크플로를 구성함.
  • 워크플로란? 하나 이상의 작업이 실행되는 자동화 프로세스. 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행됨
• 워크플로는 .yml(혹은 .yaml) 파일에 의해 구성됨.
• 테스트, 배포 등 기능에 따라 여러개의 워크플로를 만들 수 있음.
• 생성된 워크플로는 .github/workflows 디렉토리 이하에 위치함.
• 비공개 레포지토리는 깃헙액션의 작동 용량과 시간이 제한되어 있음. 공개 레포지토리는 무료로 사용 가능.

YAML, AML

: (Yet Another Markup Language)의 약자, 사람이 읽을 수 있는 데이터 직렬화 언어를 의미함.

- 배우기 쉬운 프로그래밍 언어.

- 다른 프로그래밍 언어와 함께 사용할 수 있음

=> 유연성과 접근성이 좋아 자동화 프로세스를 생성하는 데에도 사용됨.

name: Bare Minimum Requirements
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Bare Minimum Requirements
        uses: actions/setup-node@v1
        with:
          node-version: '16'
      - run: npm install
      - run: npm test

• key-value 형태로 작성된 파일. 계층 구조를 가짐.(JSON과 같음) 
• 큰따옴표없이 문자열 작성 가능. => 한 눈에 들어옴
• {} 형태로 감싸줄 필요 없음. => 스코프를 잘못 쓸 일이 사라짐
• 주석 사용 가능 (JSON은 못씀)
• JSON의 상위호환격. => 기존 json 문서를 yaml 파일로 사용하거나 원하는 부분만 손보기 가능. (반대도 가능)

문법

# : 주석

--- : 문서 시작 (선택 사항)

... : 문서 끝 (선택 사항)

#기본 표현
# : 다음엔 무조건 공백 문자가 와야함
key: value

int, string, boolean, 리스트, 매핑을 지원함.

int, string 타입은 스칼라라고 부르고, 배열 혹은 리스트는 시퀀스라 부름.

#객체 표현
key: 
	key: value
    key: value
   
#가독성을 위해 이렇게 작성하기도 함
key: {
	key: value
    key: value
}

#줄바꿈 표현 |
#줄바꿈 무시표현 >

key: |
	hello world
    i'm kimcoding.
    
key: >
	hello world
    i'm kimcoding.

#value에 :가 들어간 경우 반드시 따옴표 필요
#이렇게 쓰면 error남
key: value:

#이렇게 써야함
key: "value:"

마이 아고라 스테이츠 레퍼런스 코드를 깃헙 액션을 통해 s3로 배포하는 법에 대해 공부했다.

yml 파일 적는 법은 생각보다 어렵지 않았다. 

그런데 aws 아이디와 키 오류를 만나서 이것저것 찾아봤는데 정말 뭐가 뭔지 모르겠더라...

기다려서 새로온 메일에 적힌 걸로 바꿔서 넣어봤더니 잘 됐다... (?)

결국 aws 엑세스 키랑 시크릿 키값이 잘 못되어서 안 되는 문제였다.

s3 배포 링크

https://fe-70-heera1.s3.ap-northeast-2.amazonaws.com/index.html

Lighthouse

사이트를 검사해(성능, 접근성, PWA, SEO 등) 성능 측정하여 웹 페이지의 품질을 개선할 수 있는 자동화 툴

npm install -g lighthouse

Zigzag 홈페이지 Lighthouse 사용해 보기

더보기

 

<개선해야할 점>

(1) 차세대 형식을 사용해 이미지 제공하기

=> 용량이 큰 PNG, JPEG 확장자가 아닌 WebP나 AVIF 사용하여 데이터 소비량 줄이기

 

 

(2) 효율적으로 이미지 인코딩하기

=> 이미지 CDN 사용, 이미지 압축, 애니메이션 GIF를 비디오로 대체 등을 통해 이미지를 최적화하여 데이터 소비량 줄이기

 

 

(3) 이미지 크기 적절하게 설정하기

사용자 화면에 렌더링된 버전보다 큰 이미지가 페이지에 제공되고 있음.

반응형 이미지 제공하기 : 이미지 크기 조정 도구 Sharp npm 패키지와 ImageMagick CLI 도구를 사용하기

 

=> 반응형 이미지 제공을 통해 적절한 크기의 이미지를 제공하여 데이터를 절약하고 로드 시간을 줄이기

 

 

(4) 네트워크 페이로드가 커지지 않도록 관리하기

네트워크 페이로드는 긴 로드 시간과 높은 상관관계가 있음. ( => 사용자는 더 많은 셀룰러 데이터에 대한 비용을 지불하게 됨)

페이로드 크기를 줄이는 법 :

• 네트워크 페이로드 최소화 및 압축하기
• 이미지 확장자를 WebP나 AVIF 로 변경하기
• 페이지에 반복 방문 시 리소스를 다시 다운로드하지 않도록 요청을 캐시하기

 

(5) 캐시 정책을 사용하여 정적인 에셋 제공하기

=> 캐시를 사용하여 반복 방문시 리소스를 다시 다운로드하지 않도록 만들기

 

 

(6) 웹 폰트가 로드되는 동안 텍스트가 계속 표시되는지 확인하기

폰트를 로드하는데 시간이 많이 걸리는 대용량 파일인 경우, 일부 브라우저는 글꼴이 로드될 때까지 텍스트를 숨기면서 보이지 않는 텍스트의 플래시(텍스트를 숨겨버림)를 일으킴.

 

=> 보이지 않는 텍스트가 표시되지 않도록 시스템 글꼴을 일시적으로 표시하여 개선함.

 CSS에 @font-face 스타일에 font-display: swap 을 포함하면 대부분의 최선 브라우저에서 텍스트의 플래시를 피할 수 있음

 

 

번들링 : 사용자가 더 쉽고 빠르게 프론트엔드 애플리케이션에 접근할 수 있도록 용량을 줄이거나 파일을 최소화하여 유저에게 전달하는 과정. 실질적으로 여러 제품이나, 코드, 프로그램을 묶어서 패키지로 제공하는 행위를 의미함.

즉, 프론트엔드 개발자에게 번들링이란 “사용자에게 웹 애플리케이션을 제공하기 위한 파일 묶음" 이다.

Webpack

프론트엔드 애플리케이션 배포를 위해 가장 많이 사용하는 번들러.

웹 팩이란?

여러 개의 파일을 하나의 파일로 합쳐주는 모듈 번들러를 의미한다.

모듈 번들러란?

HTML, CSS, JavaScript 등의 자원을 전부 각각의 모듈로 보고 이를 조합해 하나의 묶음으로 번들링(빌드)하는 도구이다.

• 모던 웹 발전으로 JS 코드의 양이 많이 증가함. 또 대규모 의존성 트리를 가지고 있는 대형 웹 애플리케이션이 등장하면서 세분화된 모듈 파일이 폭발적으로 증가함. 이 모듈 단위의 파일을 호출해 브라우저에 띄울 때 JS 언어 특성에 따라 발생하기 쉬운 각 변수들의 스코프 문제를 해결해야 했고, 각 자원을 호출할 때에 생겨나는 네트워크 쪽 코스트도 신경 써야 했음.
• 위와 같은 복잡성에 대응하기 위해 하나의 시작점(Ex. React App의 index.js 등)으로부터 의존성을 가지는 모듈을 모두 추적하여 하나의 결과물로 만들어내는 모듈 번들러가 등장하게 됨.

웹 팩에서의 모듈

• 웹팩에서의 모듈은 JS뿐만 아니라 HTML, CSS, 혹은 .jpg나 .png 같은 이미지 파일들도 전부 포함한 포괄적인 개념이다.
• 위와 같은 이유로 웹 팩의 주요 구성 요소인 로더를 통해 다양한 파일도 번들링이 가능하다.

빌드와 번들링

빌드?

개발이 완료된 앱을 배포하기 위해 하나의 폴더로 구성하여 준비하는 작업.

번들링?

묶음의 개념. 파일을 묶는 작업 그 자체를 말함. 파일은 의존적 관계에 있는 파일들.

=> 모듈 간의 의존성 관계를 파악해 그룹화 하는 작업이라고 할 수 있음.

웹 팩의 필요성

1) 웹 애플리케이션의 빠른 로딩 속도와 높은 성능.

  - 웹팩을 사용하면 같은 타입의 파일들을 묶어서 요청 및 응답을 받을 수 있기 때문에 네트워크 코스트가 줄어들기 때문.

2) JS ES6의 문법들을 ES5 로 변호나해주는 바벨로더를 사용 가능.

 - 개발자가 원하는 최선의 개발 방식을 선택해 개발할 수 있게끔 지원.

웹팩의 핵심 개념

• Entry
• Output
• Loaders
• Plugins
• Mode
• Browser Compatibility

Target

기본값은 web.

module.exports = {
  target: ["web", "es5"],
};

Entry

프론트엔드 개발자가 작성한 코드의 "시작점".

엔트리 속성은 엔트리 포인트라고도 하며, 웹팩이 내부의 디펜던시 그래프를 생성하기 위해 사용해야 하는 모듈이다.

웹팩은 엔트리 포인트를 통해 직간접적으로 의존하는 다른 모듈과 라이브러리를 찾을 수 있다.

//기본 값
module.exports = {
	...
  entry: "./src/index.js",
};

//지정 값
module.exports = {
	...
  entry: "./src/script.js",
};

Output

생성된 번들을 내보낼 위치, 파일의 이름을 지정하는 방법을 웹팩에 알려주는 역할.

const path = require('path');

module.exports = {
	...
  output: {
    path: path.resolve(__dirname, "docs"), // 절대 경로로 설정을 해야 합니다. //내보낼 위치
    filename: "app.bundle.js", //번들 이름
    clean: true
  },
};

Loder

웹팩은 기본적으로 JS와 JSON 파일만 이해함.

로더를 사용하면 웹팩이 다른 유형의 파일을 처리하거나, 유효한 모듈로 변환해 애플리케이션에 사용하거나 디펜던시 그래프에 추가 가능.

module.exports = {
	...
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, "css-loader"],
        exclude: /node_modules/,
      },
    ],
  },
};

• (필수) test: 변환이 필요한 파일들을 식별하기 위한 속성
• (필수) use: 변환을 수행하는데 사용되는 로더를 가리키는 속성
• exclude: 바벨로 컴파일하지 않을 파일이나 폴더를 지정. (반대로 include 속성을 이용해 반드시 컴파일해야 할 파일이나 폴더 지정 가능)

Plugin

플러그인을 사용하면 번들을 최적화, 에셋 관리 또는 환경변수 주입 등 광범위한 작업을 수행할 수 있게 됨.

• 플러그인을 사용하려면, require()를 통해 플러그인을 먼저 요청해야 함.
• 플러그인 배열에 사용하고자 하는 플러그인을 추가. (대부분의 플러그인은 사용자 옵션을 통해 지정 가능)
• new 연산자를 사용해 호출하여 플러그인의 인스턴스를 만듬 (다른 목적으로 플러그인을 여러 번 사용하도록 설정할 수 있어짐)

const webpack = require('webpack');
const HtmlWebpackPlugin = require("html-webpack-plugin");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");

module.exports = {
  ...
  plugins: [
    new HtmlWebpackPlugin({
      template: path.resolve(__dirname, "src", "index.html"),
    }),
    new MiniCssExtractPlugin(),
  ],
};

Optimization(최적화)

웹팩 버전 4부터 선택한 항목에 따라 최적화 실행.

• 최적화하기 위해 다양한 옵션이 지원됨. 대표적으로 minimize와 minimizer.
• minimize : TerserPlugin 또는 optimization.minimize에 명시된 plugins로 bundle 파일을 최소화(=압축)시키는 작업 여부를 결정
• minimizer : defualt minimizer을 커스텀된 TerserPlugin 인스턴스를 제공해서 재정의할 수 있습니다.

module.exports = {
  ...
  optimization: {
    minimizer: [
      new CssMinimizerPlugin(),
    ]
  }
};

과제 1을 진행하면서 어려웠던 점?

튜토리얼은 제대로 차근차근 따라하다보니 잘 적용이 됐는데 아고라 스테이츠 레퍼런스 코드를 적용하려니까 오류가 계속해서 났다.

 특히 ERR_ABORTED 404 와 Uncaught SyntaxError: Cannot use import statement outside a module 가 계속 떴는데 404는 제일 윗 파일인 index.html 스크립트의 경로 위치가 잘못 되어있었다. npm build로 index.html이 2개가 되다보니까 경로를 잘못 적었던 것 같다.

Uncaught SyntaxError: Cannot use import statement outside a module 에러는 최상단 index.html 파일 스크립트 부분에 <script type="module" /> 을 추가했다. 

전체적으로 app.bundle.js와 html 파일 끝에 넣는 스크립트 파일들의 경로에서 삐끗해서 난 오류들이 많았다.

그리고 app.bundle.js 파일에 cmd+k+f 를 하면 코드가 자동 정렬이 안 되고 갑자기 흰색으로 바뀌어버리더라... 이건 무슨 오류인지 아직까지도 미지수다.

(ver.22.09.28) app.bundle.js 의 코드들이 하얗게 뜨는 이유를 찾아냈다.

어느 게시글에서 봤는 지 분명 저장해 뒀던 거 같은데... 게시글이 사라졌다.

정확하진 않지만 webpack.config.js 파일에 mode로 es5 를 추가하지 않아 생긴 문제인 거 같다.