[WANTED] 프리온보딩 코스 week 1-2

jun gwon·2022년 11월 1일

원티드 프리온보딩

목록 보기

3/14

강의 section_1

두번째 강의의 첫번째 섹션에선
첫번째 과제물에 대한 피드백이 있었습니다.
장점과 단점에 대한 예시와 이유를 함께 강의주제 였습니다.

(해당 게시글은 실제 강의 내용을 그대로 옮겨적은것은 아니며, 주관적인 이해 및 판단으로 요약되어진 글입니다.)

첫번째 주제 : 과제 리뷰

Good Point

commit Convetion
- 협업, 또는 팀 단위로 개발을 할때는 공통된 commit 제목 규약을 가지고 하는것이 좋습니다.
- 참고로 한 레퍼런스가 있다면, 같이 올려두는것도 좋습니다.
idSelector는 지양
- react의 컴포넌트는 매우 자주 렌더링이 됩니다. react의 특성상 고유값이여야 하는 id는 매 렌더링시마다 값이 중복으로 사용되기 때문에 사용을 지양하여야 합니다.
로직의 분리 (응집도를 높이자)
- 연관된 기능끼리 뭉쳐져 있는 코드는 다른사람이 코드를 볼때 읽기 쉽게 합니다.
- 유지보수가 필요로 한 경우, 해당 영역에서만 처리하면 되기때문에 유지보수가 수월해집니다.

Bad Point

react state의 남용
- react의 state는 값이 변경되면 페이지가 리렌더링 됩니다. 이런 특성이 있기때문에, state가 바뀌면 UI가 바뀌는 경우에만 사용되어야 합니다.
- 때문에 state의 사용은 가능한 최소한으로 사용하는것이 좋습니다. state의 남용을 막기 위해서는 아래와 같은것을 생각해보는것이 좋습니다.
  - 부모로부터 props를 받은값을 다시 한번 state를 사용하진 않았는지
  - 시간이 지나도 변하지 않는 값이 state로 사용되고 있지는 않은지
  - 컴포넌트 안의 state나 props가 bool값인 경우 공통 분모를 통하여 최적화 시킬순 없는지
  - 단순히 어떠한 값의 bool값이 필요한 경우라면 이중부정 !! 을 사용하여 최적화 할순 없는지
불필요하면 익명함수 지양
- jsx의 onEvet 함수는 기본적으로 evt 인자를 넘겨주기때문에, 사용하고자 하는 함수가 evt인자 또는 인자를 필요로 하지 않는경우는 익명함수를 사용하지 않는것이 좋습니다.
주석은 필요한 경우만 사용
- 코드를 설명하는 주석은 최대한 지양해야합니다.
  - 나중에 코드가 수정될경우, 주석 또한 수정되어야 하는 번거로움이 있을수있고, 수정되지 않고 방치된 주석은 타인에게 혼란을 줄 수 있습니다.
- 코드로 설명이 불가능한 주석은 사용되면 좋습니다.
  - TODO 주석의 사용 : 이슈가 있어서 완성되진 못했지만, 나중에 수정을 해야 할 경우 사용되는 주석
  - FIXME 주석의 사용 : 지금은 처리 하지 못하지만, 나중에 처리해야 할 이슈를 적을 때 사용하는 주석

강의 section_2

두번째 섹션에서는 서버에 대한 강의가 있었습니다.

두번째 주제 : 서버

서버란, 무언가를 제공해주는 컴퓨터 입니다.

웹 환경에 있어 서버란, 프로그램 실행환경에서 네트워크를 통해 서버에 접근요청이 오면, 정해진 요청에 따라 특정 리소르를 응답합니다.

때문에 서버는 웹 환경에 있어, 없으면 안되는 필수적인 하드웨어적인 환경입니다.

이러한 서버를 관리하는 크게 두가지로 나뉘어져 왔습니다.

온 프레미스 환경

온 프레미스란, 서버를 서비스하는 회사에서 직접 관리하는 환경을 의미합니다.

장점
- 회사가 직접 서버를 관리하기 때문에, 소프트웨어는 물론, 물리적인 환경까지 온전히 통제할 수 있습니다.
- 때문에 중요한 환경에서는 온 프레미스 환경을 채택하는 경우가 많습니다.
단점
- 서버는 물리적인 실체이기때문에, 실제 제반 공간, 시설, 인력 등이 필요로 하며, 꾸준히 관리해야 하는 필요성이 있습니다. 즉, 초기 설치 비용이 비싸며, 유지보수 비용을 지속적으로 필요로 합니다.
- 설치된 서버의 수용량은 이후 변경이 어렵기 때문에, 순간적으로 많은 수용이 필요로 할 경우 정상적인 작동의 기대가 어려울 수 있습니다.
- 최근의 데이터센터 화재사고, 또는 기타 천재지변과 같이 예기치 못한 사건에 대해서는 취약할 수 있습니다.

클라우드 컴퓨팅 환경

클라우드 컴퓨팅이란, 직접적으로 서버를 구비하지않고, 클라우드 서비스를 이용하여 서버를 작동시키는 환경을 의미합니다.

장점
- 고객이 직접 물리적인 서버를 운영 할 필요가 없습니다
- 원하는 사양, 원하는 시간을 직접 조정할 수 있습니다.(이것이 가능한 이유는 클라우드 서비스는 여러개의 컴퓨터를 연결하여 하나의 컴퓨터 같이 연산 가능하게 하여 제공하기 때문입니다.)
- 지역에 크게 구애받지 않습니다.
  - 만약 유럽,아메리카에서도 서비스를 시작하고자 할때, 그 지역의 클라우드 서버를 사용 한다면 원활한 운영이 가능합니다.
단점
- 온 프레미스의 장점의 정 반대입니다. 고객측은 클라우드 서비스의 통제에 관여할수 없기때문에, 서비스가 원활하게 이루어지기를 기대할 수 밖에 없습니다.

클라우드 컴퓨팅의 분류

클라우드 컴퓨팅은 IaaS , Paas , SaaS 와 같은 3계층의 형태로 나뉘어질 수 있습니다.

IaaS(Infrastructure as a Service)
- 클라우드 서비스의 가장 기본적인 형태입니다.
- 설정되어 있지 않은 컴퓨터를 대여 받는 수준입니다.
- 때문에 사용자는 많은 부분을 직접 구성, 관리를 해줘야 하는 단점이 있습니다.
- 대표적인 서비스는 AWS의 EC2가 있습니다.
PaaS(Platform as a Service)
- 구성 요소들을 플랫폼화 해서 제공해주는 형태입니다.
- 소프트웨어의 운영 및 관리를 PaaS에 위임하기 때문에 개발자들은 효율적인 개발을 할 수 있습니다.
- 단점으로는, PaaS는 IaaS에 비해, 플랫폼에 종속적인면이 강해지며, 접근이 허용되지 않아 제어가 안되는 문제, IaaS보다는 높은 비용문제 등의 단점이 있습니다.
- 대표적인 서비스로는 Heroku,Github Pages 등이 있습니다.
SasS(Software as a Service)
- 고객이 바로서비스를 사용할 수 있게, 소프트웨어 까지 모두 제공되어지는 형태입니다.
- 클라우드 서비스를 통해 서비스가 제공되기때문에, 고객이 PC에 직접 파일을 설치할 필요가 없거나, 고객의 컴퓨팅 사양이 중요치 않은 경우가 많습니다.
- 대표적인 서비스로는 Slack,NetFlix 등이 있습니다.

AWS

AWS는 클라우드 컴퓨팅 서비스를 제공하는 프로바이더로, 현재 전세계에서 가장 많이 사용되어지는 클라우드 컴퓨팅 서비스입니다.
AWS는 단순히 컴퓨팅 자원의 제공 뿐만 아니라, 이를 편리하게 관리 할 수 있도록 도와주는 여러 서비스를 제공하며 높은 안정성, 확장성, 보안성 등을 가지고 있습니다.

이번 섹션에서 다루어본 주제는 S3 였습니다.

S3는 Simple Storage Service의 약자로서, 단순한 형태의 파일 보관소라고 생각 할 수 있습니다.
특정 파일, 이미지 등을 저장하고 인터넷상으로 접근할수있게 하는 서비스로도 사용될 수 있지만,
CRA를 통하며 빌드된 파일, index.html은 정적인 파일이며, 렌더링이 CSR로 작동한다는 특징이 있어, 이를 이용하여 S3 서비스를 이용해서 웹 페이지를 배포할 수 있습니다.

S3를 이용하는 방법

가장 기본적인 사용법 입니다.

AWS의 S3로 접근하여 버킷을 생성합니다.
- 버킷의 이름은 고유하여야 하며, 서비스 지역을 설정하고, 버킷의 퍼블릭 액세스 차단 설정을 해제하여야 합니다.
생성된 버킷의 속성 TAB 에서 하단의 웹 사이트 호스팅 기능을 활성화 합니다.
- 이때 인덱스 문서, 에러페이지 문서는 index.html로 동일하게 합니다.
권한 탭의 버킷정책 설정에서 사용하고자 하는 정책을 설정합니다.
- 객체에 대한 접근 권한을 json형식으로 작성할수있습니다.
- 많이 사용되어지는 형식의 정책은 아래와 같습니다.
```
{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "<name>",
        "Effect": "Allow",
        "Principal": "*",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::<버킷 네임>/*"
    }
]
}
```

version은 사용하고자 하는 정책 버전을 말하며
Statement에서 직접적으로 사용하고자 하는 정책을 설정합니다.
Sid는 만드는 정책의 이름을 의미하며
Effect는 허용여부를 의미합니다.
Principal은 누구에게 허용할 것인지를 의미하며, "*"은 모두가 접근 할 수 있는것을 의미합니다.
Action은 무엇을 할것인지를 의미하며, 위와 같은 설정에서는 s3의 오브젝트를 가져가는것을 허용할것을 말합니다.
Resource는 무엇을 가져갈것인지를 말하며, 위와 같이 버킷네임/* 로 설정 될 경우 모든 파일을 가져갈수 있다는것을 의미합니다.

위와 같은 설정 이후, 객체 탭으로 이동하여, 자신이 오나성한 CRA의 build를 통해 정적인 html파일을 만들고, build 파일안의 파일들을 모두 객체 폴더에 업로드 합니다.
속성 탭의 권한 웹 사이트 호스팅에 생성되어 잇는 url을 통해 완성한 CRA의 페이지로 이동이 가능하게 됩니다.

강의 section_3

섹션 3에서는 CI/CD에 대해 다루어보았습니다.

세번째 주제 : CI/CD

CI/CD의 의미

CI/CD란 Continuous Integration(CI)와 Continuous Delivery/Deployment(CD)를 통합해서 부르는 용어입니다.

CI/CD를 이용한다는것은 개발과정에서 필요한 빌드,테스트,배포 등의 과정을 자동화 한다는것입니다.

CI의 관심사는 코드를 지속적으로 통합해 나가는것을 의미합니다. 중요한것은 에러가 발생하지 않는지 체크해주는것. 머지 후에도 제대로 관리가 되어질 수 있을까 라는 것. 유효한 코드인지 검사해주는 것. 이러한 것들에 대한 체크를 CI는 자동화 해준 다는 것입니다.

CD의 관심사는 CI과정을 통과한 코드를, 실제 사용자가 사용하는 Production 환경에 배포하는것이며, CD는 이러한 과정을 자동화하는것입니다.

즉, CI/CD 과정이란, CI에서 코드에 문제가 없는지를 검사하며, CD에서 CI를 통과한 코드를 배포하는 과정을 자동화 한다는것을 의미합니다.

CI/CD 플랫폼의 종류와 사용 이유

1. 클라우드 플랫폼의 종류

CI/CD의 사용은 파이프라인을 구축하여 사용합니다. 파이프라인을 구축하고, 사용하기 위해서는 CI/CD 플랫폼을 사용하게되는데, 이러한 CI/CD플랫폼 또 한 2가지 분류로 나뉘게 됩니다.

크게 설치형과 클라우드 형으로 나뉘게 되는데,
설치형으로는 Jekins가 대표적이며, 클라우드형으로는 GitHub Actions 등이 있습니다.

설치형의 장점으로는 온-프로미스 서버와 유사하게, 실행환경의 통제가 가능하다는 장점이 있습니다.

클라우드형의 장점으로는 별도의 컴퓨팅 자원이 필요 없이, 서비스 제공자가 모두 운영해준다는 장점이 있습니다.
하지만 플랫폼에서 제공해주는 수준까지만 사용 가능하기 때문에, 세부적인 조정이 불가능 하다는 단점이 있습니다.

2. 사용 이유

현재의 개발자는 상대적으로 많은 업무를 맡고 있습니다. 개발자는 기본적인 개발 이외에도, 고객의 피드백에 대해서 빨리, 그리고 자주 개선해야 하는 등의 추가적인 업무 등, 맡고 있는 업무가 하드웨어적인 개발환경보다 많이 있습니다.

이러한 환경에서 개발자는 CI/CD를 통해 코드의 유효성 검사와 배포를 자동화를 맡김으로서, CI/CD를 위한 시간 할애를 하지않고, 본연의 개발업무에 집중할 수 있게 해줍니다, 또한 해당 과정에서 오류가 발생할시 자동적으로 개발자에게 이를 알려주는 기능 또한 가지고 있기때문에 CI/CD는 개발환경을 효율적으로 나아갈 수 있도록 도와줍니다.

GitHub Action를 사용한 CI/CD

1.GitHub Action을 사용하는 장점

클라우드 형이라 관리가 쉽습니다.
GitHub Repo와의 연동이 쉽습니다.
Repo안에서 CI/CD까지 함께 구축하고 관리할수있다는 이점
타 CI/CD 플랫폼 보다 초기 러닝커브가 낮다는 점
다른 사람이 만들어둔 좋은 설정들이 공유되어 있고, 쉽게 사용이 가능하다는 점

2.사용방법

Repo안에서 CI/CD를 자동화 하기 위해선 프로젝트 최상위 .github/workflows/ 경로에 cicd.yml 을 작성하여야 합니다. 이는 일종의 규약입니다.
CI/CD를 위한 파이프라인을 작성합니다. 아래는 CI/CD 통해 테스르를 자동화하고, AWS에 배포까지 하는 과정을 담은 파이프 라인입니다.

 name: <NAME>

on:
  push:
    branches:
    - <Branch>
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - run: npm ci
    - run: npm run test
    - run: npm run build
    - name: deploy to s3
      uses: jakejarvis/s3-sync-action@master
      with:
        args: --delete
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'ap-northeast-2'
        SOURCE_DIR: 'build'

name은 워크플로우 이름입니다.
on은 언제 이벤트가 실행될것인지를 의미합니다.
push설정을 하여, push가 될경우 자동화 될 수 있도록 설정되었습니다.
branches는 어느 브랜치에 push될 경우 자동화 할것인지를 의미합니다. 기본값은 master로 되어 잇으며, 이경우에는 따로 설정할 필요가 엇습니다.
workflow_dispatch 는 GitHub Action Page에서도 수동으로 CI/CD를 할 수있게 하는 옵션입니다.
jobs는 실행할 작업 목록을 의미합니다. jobs는 여러개의 스텝을 가질 수 있습니다.
deploy 라고 명시되어 있는 부분은 jobs에서 실행할 첫번째 작업의 name입니다. 이것은 수동적으로 변경할수있습니다.
runs-on 은 git actions에서 제공하는 클라우드의 어느 환경에서 실행할것인지를 의미합니다.
steps는 어떠한 작업을 할것인지를 의미합니다
uses는 타인이 만들어둔 지정된 워크플로우를 사용한다는것을 의미합니다.
npm ci는 npm install과 유사하지만, cleanInstall을 의미하며, 완벽히 정확한 버전의 패키지만을 설치한다는 차이점이 있습니다.
이후 빌드까지의 작업이 이어집니다.
name은 하단에 이어질 step 파이프라인 작업의이름입니다.
uses를 통하여 jakejarvis/s3-sync-action@master의 파이프라인 설정을 가져와 사용하였음을 의미합니다.
with은 옵션으로서, aws는 파일이 추가되면 기존의 파일을 제거하는 설정을 가지고 잇습니다. 이것을 args: --delete로 표시합니다.
env는 step에서 사용할 환경설정입니다.
시크릿 정보들은 repo - setting - secret - action secrets 에서 환경값을 설정할수있습니다. 위 문서에서는 버킷,키 아이디, 액세스 키 등을 등록해야 합니다.
AWS_REGION 는 사용할 aws 클라우드 서비스의 위치를 의미합니다.
SOURCE_DIR 는 배포된 파일에서 어떤 dir 내부의 파일을 사용할것인지를 의미합니다.
AWS_SECRET_ACCESS_KEY와 같은 경우, AWS 설정을 터미널 환경에서도 사용하기 위해 발급받아야 하는 토큰값입니다.
- 이를 발급받기 위해선 개인setting - 보안자격증명 - 액세스 키 부분에서 key를 발급받아야 합니다.

마무리 소감

이번 강의에서는 저번 과제에 대한 피드백과 서버,CI/CD에 대해 공부하였습니다.

총 3시간내외 강의였는데, 정말 밀도있는 수업이라고 느꼈습니다.
몇번 따라해보기는 했지만, 두루뭉실하게 남아있던 클라우드 서비스, CI/CD에 대해서 이번 기회로 어느정도 확실한 개념과 사용법을 익힐 수 있었습니다.

사실 프론트엔드는 웹 VIEW 쪽만 잘 하면 되지 않을까라는 생각도 하긴 했엇는데, 강사님이 마지막에 말씀해주신 프론트엔드 개발자는 단순히 개발뿐만 아니라, 여러분야에 대해 협업을 해야하고, 또한 알고 있어야 하는게 필수불가결 하다는걸 강조하셨습니다.

특히, CI/CD와 같은경우, 프로덕트 배포에서 문제가 생겻을때 빠르게 문제가 발생했는지 확인하고 대응하는 능력이 있어야 하기 때문에, 중요도가 높다고 강조하신게 제 좁은 시야를 넓혀주신 느낌이였습니다.

jun gwon

이전 포스트

[WANTED] ASSIGNMENT_1

다음 포스트