9장 발표자료

9.1 Next.js로 리액트 개발 환경 구축하기

 

9.1.1 create-next-app 없이 하나씩 구축하기

 

1. npm init으로 package.json 만들기
2. react, react-dom, next 설치하기
3. devDependencies에 필요한 패키지 설치하기
   • typescript, @types/react, @types/react-dom, @types/node
   • eslint, eslint-config-next

 

9.1.2 tsconfig.json 작성하기

 

tsconfig.json에 타입스크립트 설정을 해준다.

 

작성하기 전에 

 

이렇게 JSON 최상단에 값을 넣으면 해당 JSON파일이 무엇을 의미하는지,

어떤 키와 어떤 값이 들어갈 수 있는지 알려준다.

 

올바른 값이 선언돼 있다면 VS Code나 웹스톰 같은 IDE에서 자동 완성이 가능해진다.

 

 

9.1.3 next.config.js 작성하기

 

Next.js 설정을 위한 next.config.js를 만든다.

 

본인이 사용하고 있는 next.config.js에서 사용 가능한 옵션을 확인하고 싶다면 깃허브 저장소에서 확인할 수 있다.

 

 

9.1.4 ESLint 와 Prettier 설정하기

 

앞에서 설치한 eslint-config-next 는 단순히 코드에 있을 잠재적인 문제를 확인할 뿐,

띄어쓰기나 줄바꿈과 같이 코드의 스타일링을 정의해주지 않는다.

 

이러한 작업을 수행하기 위해 @titicaca/eslint-triple을 설치해 사용한다.

 

 

9.1.5 스타일 설정하기

 

styled-components를 설치하고,

next.config.js에 styledComponents : true를 추가한다.

>> swc가 styled-components를 사용하는 코드를 더 빠르게 변환한다.

 

 

9.1.6 애플리케이션 코드 작성

 

애플리케이션 구동에 필요한 파일은 src 폴더 내부에 있고,

하위 폴더 목록을 살펴보자.

• pages : 이 폴더 하위의 내용은 모두 실제 라우터가 된다.
  • /: 메인페이지
  • /todos/:id : 상세페이지
• components: 페이지 내부에서 사용하는 컴포넌트를 모아둔 폴더
• hooks: 직접 만든 훅을 모아둔 폴더
• types: 서버 응답 타입 등 공통으로 사용하는 타입을 모아둔 폴더
• utils: 애플리케이션 전역에서 공용으로 사용하는 유틸성 파일을 모아둔 폴더

 

9.2 깃허브 100% 활용하기

 

9.2.1 깃허브 액션으로 CI 환경 구축하기

 

CI(Continuous Integration)

코드의 변화를 모으고 관리하는 코드 중앙 저장소에서
여러 기여자가 기여한 코드를 지속적으로 빌드하고 테스트해 코드의 정합성을 확인하는 과정.

 

CI는 코드의 변화가 있을 때마다 전체 소프트웨어의 정합성을 확인하기 위한 작업을 자동으로 실행해야 한다.

 

• 젠킨스(Jenkins)
  • CI에 필요한 다양한 기능을 제공하는 무료 솔루션
  • 편리하고 많은 플러그인을 통해 다양한 기능 통합 가능
  • 설치 및 유지보수가 번거로움
• 깃허브 액션
  • 깃허브에서 출시한 SaaS, 깃허브 저장소와 함께 사용할 수 있는 강력한 도구
  • 깃허브 저장소를 기반으로 깃허브에서 발생하는 다양한 이벤트를 트리거 삼아 다양한 작업을 할 수 있게 도와준다.
    • 깃허브의 어떤 브랜치에 푸시가 발생하면 빌드를 수행
    • 깃허브의 특정 브랜치가 메인 브랜치를 대상으로 PR(pull request)이 열리면 빌드, 테스트, 정적 분석을 수행
  • 다른 CI/CD(Continuous Integration/Continuous Delivery) 솔루션을 대체할 수 있어 CI/CD 서비스로 각광받게 됐다.

 

깃허브 액션의 기본 개념

 

• 러너(runner) : 파일로 작성된 깃허브 액션이 실행되는 서버.
• 액션(action): 러너에서 실행되는 하나의 작업 단위. yaml파일로 작성된 내용을 하나의 액션으로 볼 수 있다.
• 이벤트(event): 깃허브 액션의 실행을 일으키는 이벤트.
  • pull_request: PR과 관련된 이벤트 (PR이 열리거나, 닫히거나, 수정되거나, 리뷰 요청 등)
  • issues: 이슈와 관련된 이벤트
  • push: 커밋이나 태그가 푸시될 때 발생하는 이벤트
  • schedule: 저장소에서 발생하는 이벤트와 별개로 특정 시간에 실행되는 이벤트.
• 잡(jobs): 하나의 러너에서 실행되는 여러 스텝의 모음.
• 스텝(steps): 잡 내부에서 일어나는 하나하나의 작업. 이 작업은 병렬로 일어나지 않는다.

스텝을 엮어서 잡을 만든다 ( 여러 개의 잡은 병렬로 실행됨) > 액션(잡을 하나 이상 모아둔 것)을 러너가 실행한다.

 

 

깃허브 액션 작성하기

 

저장소의 루트에. github/workflows 폴더 생성 후 내부에 파일 작성하기. (확장자는. yml 또는. yaml로 지정)

 

예시 파일

 

브랜치에서 푸시하고 풀 리퀘스트를 만들어 확인해 보자.!

 

Details를 누르면 해당 액션의 실행 결과를 자세히 확인할 수 있다.

 

 

구체적으로 액션이 yaml파일 내에서 어떻게 작성됐고 각 값의 뜻은 무엇인지 알아보자.!

• name
  • 액션의 이름. (액션을 구별하는 데 도움이 되므로 지정하는 것이 좋다)
• run-name
  • 액션이 실행될 때 구별할 수 있는 타이틀명 (필수값 x -> 어떤 사람이  해당 액션을 트리거했는지 구별)
  • 설정돼 있지 않다면 풀 리퀘스트 이름이나 마지막 커밋 메세지 등이 출력된다.
• on
  • 필수값. 언제 이 액션을 실행할지를 정의한다(ex. 원격 저장소의 푸시가 발생했을 때)
• jobs
  • 필수값. 해당 액션에서 수행할 '잡'을 의미한다.
  • 한 개 이상 설정 가능, 여러 개를 지정하면 병렬로 실행된다.
    1. jobs.build: 임의로 지정한 이름으로, name과 같은 역할을 한다고 보면 된다. jobs의 하위 항복이므로 반드시 들여 쓰기 해야 한다.
    2. jobs.build.steps: 해당 잡에서 순차적으로 수행할 작업을 정의한다.
       1. uses: action/checkout@v3 :  action/checkout@v3을 사용해서 작업하겠다는 것을 의미
       2. uses : actions/step-node@v3:  actions/step-node@v3을 사용해서 작업하겠다는 것을 의미
       3. name : 'install dependencies' : 의존성을 설치하는 작업을 수행
       4. name : 'build' : CI를 위한 작업. 마지막 작업으로 빌드를 수행.
    3. jobs.build.runs-on: 어느 환경에서 해당 작업이 실행될지를 결정한다.(깃허브에서 제공하는 서버를 쓰고 싶다면 ubuntu-latest를 선언). 커스텀 러너를 쓰고 싶다면 저장소의 Settings에서 추가할 수 있다.

 

 

9.2.2 직접 작성하지 않고 유용한 액션과 깃허브 앱 가져다 쓰기

 

깃허브에서 제공하는  Marketplaces라는 서비스를 사용하면 여러 사용자가 만들어 놓은 액션을 손쉽게 가져다 쓸 수 있다.

 

 

깃허브에서 제공하는 기본 액션

• actions/checkout: 깃허브 저장소를 체크아웃하는 액션
• actions/setup-node: Node.js를 설치하는 액션.
• actions/github-script: Github API가 제공하는 기능을 사용할 수 있도록 도와주는 액션.
• actions/stale: 오래된 이슈나 PR을 자동으로 닫고나 더 이상 커뮤니케이션하지 못하도록 닫는다.
• actions/dependency-review-action: package.json, package-lock.json, pnpm-lock.yaml 등의 내용이 변경됐을 때 실행되는 액션.
• github/codeql-action: code-ql(깃허브의 코드 분석 솔루션)

 

calibreapp/image-actions

 

저장소에 포함돼 있는 이미지를 최적화하는 액션.

PR로 올라온 이미지를 sharp 패키지를 이용해 거의 무손실로 압축해서 다시 커밋한다.

 

lirantal/is-website-vulnerable

 

특정 웹사이트를 방문해 해당 웹사이트에 라이브러리 취약점이 존재하는지 확인하는 액션.

 

Lighthouse CI

 

구글에서 제공하는 액션, 라이트하우스를 CI 기반으로 실행할 수 있도록 도와주는 도구.

>> 프로젝트의 URL을 방문해 라이트하우스 검사를 실행한다.

 

 

9.2.3 깃허브 Dependabot으로 보안 취약점 해결하기

 

의존성에 문제가 있을 때, 이에 대해 문제를 알려주고 가능하다면 해결할 수 있는 풀 리퀘스트까지 열어준다.

 

버전

 

유의적 버전

버전은 주. 부. 수로 구성돼 있다.

1. 기존 버전과 호환되지 않게 API가 바뀌면 주 버전을 올리고,
2. 기존 버전과 호환되면서 새로운 기능을 추가할 때는 부 버전,
3. 기존 버전과 호환되면서 버그를 수정한 것이라면 수 버전을 올린다.

• 특정 버전으로 패키지를 배포하고 나면 그 버전의 내용은 절대 변경하지 말아야 한다.
• 주 버전 0은 초기 개발을 위해 쓴다.(아무 때나 마음대로 바꿀 수 있다)
• 수 버전은 반드시 그 이전 버전 API와 호환되는 버그 수정의 경우에만 올린다.

의존성

 

npm 프로젝트를 운영하는 데 필요한 자신 외의 npm 라이브러리를 정의해 둔 목록.

 

• dependencies
  • 해당 프로젝트를 실행하는 데 꼭 필요한 패키지 선언.
• devDependencies
  • npm install을 실행하면 설치되는 의존성
  • 개발 단계에서 필요한 패키지들을 선언.
• peerDependencies
  
  • 주로 서비스보다는 라이브러리와 패키지에서 자주 쓰이는 단위.
  • 직접적으로 해당 패키지를 require 하거나 import하지는 않지만 호환성으로 인해 필요한 경우를 의미.
  • 사용하려면 리액트 16.8 버전 이상이 필요하다.

 

 

9.3 리액트 애플리케이션 배포하기

 

가장 쉽고 빠르면서 안정적으로 배포할 수 있는 3가지 서비스에 대해 알아보자.!

 

9.3.1 Netlify

 

• 웹 애플리케이션을 배포할 수 있도록 도와주는 클라우드 컴퓨팅 서비스.
• React 앱을 포함해 Vue, Angular 등 다양한 프레임워크를 지원.
• Git과 연동되며, 코드가 변경되면 자동으로 새로운 버전을 빌드하고 배포.
• 무료 플랜을 제공하며, 소규모 프로젝트나 포트폴리오 웹사이트 배포에 유용하다.
• 기존 도메인을 연결할 수 있다.
• 배포와 관련된 알림을 추가할 수 있다.(실패하거나 성공 등 다양한 상황에서 알림을 받을 수 있다 > 알림 받을 채널 선택 가능)

 

9.3.2 Vercel

 

• Netlify와 비슷한 클라우드 플랫폼 서비스로 Next.js를 비롯한 Turborepo, SWC를 만든 회사이다. 
• 최신 프레임워크를 지원하며, 정적 사이트나 서버리스 애플리케이션을 관리하기에 적합하다.
• Github, GitLab, BitBucket과 쉽게 연동되어, 코드를 push 하면 자동으로 빌드하고 배포한다.
• 기존 도메인 연결 가능.
• 글로벌 CDN(Content Delivery Network)을 사용하여 전 세계 사용자에게 빠르게 콘텐츠를 전달한다.
• 서버 사이드 렌더링(SSR), 정적 생성(SSG) 등 Next.js의 모든 기능을 완벽하게 지원한다.(다른 프레임워크도 배포 가능)

 

9.3.3 DigitalOcean

 

• 미국의 클라우드 컴퓨팅, 호스팅 플랫폼 업체.
• 저장소를 바탕으로 바로 배포할 수 있는 서비스를 제공.
• GitHub Student Pack에 포함되어 있어 학생 계정으로 가입한 깃허브에 200달러 상당의 무료 크레딧을 제공한다.
• 다양한 리소스에 대해 문서화가 상세하게 되어있고, 자체 블로그에 개발과 관련된 포스팅을 자주 올리고 있다
• Vercel과 Netlify는 정적인 웹사이트 배포에 초점을 두고 있다면, DigitalOcean은 AWS와 Google Cloud Platform과 비슷하게 다양한 클라우드 컴퓨팅 서비스를 제공한다.
• 기존 도메인 연결 가능.

 

 

9.4 리액트 애플리케이션 도커라이즈 하기

 

이전에 살펴본 방법은 트래픽이 적은 개인용 프로젝트나 테스트용, 혹은 어드민 페이지나 MVP 프로젝트를 만드는 데는 적합하지만

본격적으로 사용자에게 서비스하기 위한 웹 애플리케이션을 서비스하기에는 적절하지 않음.

 

>>애플리케이션을 자유롭게 커스터마이징 하는 데 있어 제약이 있다.

>>빌드 횟수, 팀 멤버의 수, 사용하는 컨테이너의 스펙 등에 크게 의존하기 때문에 유연한 비용 체계를 유지하기 어렵다.

 

요즘은 애플리케이션을 하나의 컨테이너로 만들어 빠르게 배포하는 것이 일반적.

 

>> 컨테이너를 만드는 데 사용되는 것이 바로 도커(Docker)

 

 

도커

 

- 서비스 운영에 필요한 애플리케이션을 격리해 컨테이너로 만드는 데 이용하는 소프트웨어.

 

 

도커가 왜 필요할까?

 

• 운영체제(OS)와 상관없이 어디서든 동일한 환경 제공
• 내 컴퓨터에선 잘 되는데, 서버에선 안 돼요!라는 문제를 해결

 

도커의 동작 방법

• 애플리케이션과 그 실행 환경을 이미지라는 파일로 만들고, 이 이미지를 기반으로 컨테이너를 실행한다.

컨테이너 
애플리케이션이 독립된 환경에서 실행되도록 만들어주는 공간

 

 

장점

• 프로젝트마다 요구되는 환경을 바로 실행할 수 있다.
• 환경 차이로 인한 에러를 방지할 수 있다.
• Docker 이미지를 만들어 어디서나 실행 가능한 형태로 배포 가능.
• 백엔드, DB 등 의존성을 Docker로 로컬에서 쉽게 테스트.

 

 

도커라이즈 하는 방법

1. Docker 설치 (https://www.docker.com/)
2. Dockerfile 생성
3. Docker 이미지 빌드
4. Docker 컨테이너 실행
5. 프로덕션 환경 배포
   • Docker Hub나 클라우드 서비스(AWS, GCP, Azure 등)에 업로드하여 배포