프론트엔드에서 개발을 진행하다 보면, 최적화를 위해 여러 가지를 알아볼 때가 분명 존재한다. 나의 경우에는 이번 프로젝트에서 여러 최적화를 진행하기로 하였고, 그 중 하나는 bundle size를 줄여보자는 것이었다.

bundle size가 커질수록 초기 로딩 시간이 늘어나고, 결국 사용자 경험에 좋지 않은 영향을 주므로 이번 기회에 해보자고 생각했다!

bundle-analyzer

최적화를 하기 전에, 프로젝트의 번들 파일이 어떻게 구성되었는지 확인해야 한다. 나는 bundle-analyzer를 사용하였다.

pnpm install @next/bundle-analyzer

프로젝트에서 next를 사용하므로, next.config.ts에 bundle-analyzer를 적용시켜준다.

import { NextConfig } from "next";
const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
});

...

export default withBundleAnalyzer(nextConfig);

해당 코드는, env 파일의 ANALYZE 스크립트 설정을 통해 언제 bundle-analyzer이 실행될 지 적용할 수 있다.

나의 경우 build 할 시 실행되도록 작성하였다.

ANALYZE=true pnpm run build

실행

build시, 프로젝트의 현재 번들 크기가 나타나게 된다.

client.html, edge.html, nodejs.html 총 3개의 번들링 결과를 시각적으로 분석해준다.

위의 충격적인 사진의 경우 client.html이다...

const Lottie = dynamic(() => import('lottie-react'), { ssr: false });

해당 lottie를 dynamic import 처리를 한 후 살펴보자!

크기가 많이 줄었다...

Dynamic import

Dynamic import를 사용하면 크게 3가지 장점을 얻을 수 있다.

1. 초기 로딩 시간 단축

초기 렌더에 꼭 필요한 코드만 번들링하고, 나머지는 사용 시점에 불러올 수 있다.

2. 코드 스플리팅

불필요한 코드가 최초 번들에 포함되지 않도록 분리할 수 있고, 사용자 상호작용에 따라 필요한 부분만 점진적으로 로드하여 전체적인 성능을 개선할 수 있다.

3. UX 개선

필요 없는 리소스를 나중에 불러오므로 더 빠른 첫 화면 렌더링을 경험할 수 있다.

마무리

현재는 간단하게 다른 지표를 확인하지 않고 bundle-analyzer만 활용하여 최적화를 진행해봤는데, 추후에는 lighthouse도 적용해서 전/후 결과를 비교해봐야겠다!

참고

GitHub-Webpack Bundle Analyzer [nextjs] bundle-analyzer를 사용한 최적화 일기

이번 협업 프로젝트에서 Storybook을 사용하게 되었는데, 멘토님께서 사용하는 것을 넘어서 Chromatic으로 배포하면 협업 간의 효율성을 향상할 수 있고, 디자인 시스템을 관리하는 부분에서 유용하다고 하셔서 배포를 고민하게 되었다.

그리고 PR 시 자동으로 Chromatic도 배포하도록 설정해보았다. Git Action을 사용하여 배포 주소를 보여주도록 하였다.

Chromatic 사용

Chromatic 이란?

스토리북 관리자가 만든 무료 배포 서비스이다. 스토리북을 클라우드에 안전하게 배포하고 호스팅할 수 있다.

Chromatic에 가입 후, 배포할 프로젝트를 선택한다. 해당 프로젝트에서 명령어를 통해 설치가 가능하다. 현재 pnpm을 사용하고 있으므로, pnpm으로 설치를 진행하였다.

pnpm install --save-dev chromatic

그리고, 다시 터미널에서 chromatic에 배포하면 된다.

npx chromatic --project-token=chpt_ ---

굉장히 쉽게 배포가 끝났다! 현재 프로젝트에 있는 storybook이 정상적으로 보이는 것을 확인할 수 있다.

Git Action을 통한 자동 배포

위의 chpt_ ---의 토큰을 깃허브에 등록할 수 있다.

해당 레포지토리의 Secrets and variables의 Actions에서 토큰을 등록할 수 있다.

등록 후, .github/workflows 폴더 안에 yml 파일을 생성한다. 공식 문서에서는 chromatic.yml파일로 생성하라고 하였지만, 이름은 크게 문제가 되지 않기에 나는 storybook.yml으로 생성하였다.

코드의 경우 짱잼이의 FE 개발 공부 저장소 블로그를 참고하였다. 해당 블로그의 프로젝트는 yarn을 사용하고 있어서 yml이 yarn 기준으로 되어있는데, 내가 진행하는 프로젝트의 경우 pnpm을 사용하므로 Corepack을 활성화하고, pnpm 명령어로 변경하여 진행하였다.

name: Preview

on:
  pull_request:
    branches: ['main', 'develop']

permissions:
  contents: write
  pages: write
  deployments: write
  id-token: write
  issues: write
  pull-requests: write

jobs:
  storybook-preview:
    runs-on: ubuntu-20.04

    steps:
      - name: 저장소 체크아웃
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Corepack 활성화
        run: corepack enable

      - name: pnpm 설치
        run: corepack prepare pnpm@latest --activate

      - name: 캐시 종속성
        id: cache
        uses: actions/cache@v3
        with:
          path: '**/node_modules'
          key: ${{ runner.os }}-node-${{ hashFiles('**/pnpm-lock.yaml') }}-storybook

      - name: 종속성 설치
        if: steps.cache.outputs.cache-hit != 'true'
        run: pnpm install

      - name: Chromatic에 게시
        id: chromatic
        uses: chromaui/action@v1
        with:
          projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
          token: ${{ secrets.GITHUB_TOKEN }}
          onlyChanged: true
          autoAcceptChanges: true

      - name: 현재 시간 가져오기
        uses: josStorer/get-current-time@v2
        id: current-time
        with:
          format: 'YYYY년 MM월 DD일 HH시 mm분 ss초'
          utcOffset: '+09:00'

    outputs:
      storybook_url: ${{ steps.chromatic.outputs.storybookUrl }}
      current_time: ${{ steps.current-time.outputs.formattedTime }}

  github-bot-storybook:
    runs-on: ubuntu-latest
    needs: [storybook-preview]

    steps:
      - name: PR 코멘트 남기기
        uses: thollander/actions-comment-pull-request@v2
        with:
          comment_tag: ${{ github.event.number }}-storybook
          message: |
            💄 Storybook: ${{ needs.storybook-preview.outputs.storybook_url }}
            🕖 Update: ${{ needs.storybook-preview.outputs.current_time }}

PR 시 배포가 정상적으로 이루어지는 모습을 확인할 수 있다!

참고

짱잼이의 FE 개발 공부 저장소 - [GitHub Action / Chromatic] 스토리북 PR 미리보기 배포 (feat. yarn) 스토리북(Storybook) 배포하기 공식문서 Storybook Chromatic 으로 배포하기

next/font

Next.js Font Optimization

next/font는 사용자 정의 글꼴을 포함한 글꼴을 자동으로 최적화, 외부 네트워크 요청을 제거하여 적용시켜준다.

나는 이번 프로젝트에서 next/font/local을 사용하였는데, local에서 불러온 글꼴 또한 자동으로 최적화를 해주어 사용하게 되었다.

Pretendard 설치 ✨

Pretendard github

9가지 굵기가 지원되고, 가변 글꼴 또한 지원되는 글꼴이다. 많은 프로젝트에서 사용되고 있는 system ui 대체 글꼴이다.

PretendardVariable.woff2 파일을 프로젝트에 넣어 주자. 나의 경우, src/fonts 폴더 안에 넣었다(next, app router)

적용해보자!

import localFont from 'next/font/local';

...

const pretendard = localFont({
  src: '../../fonts/PretendardVariable.woff2',
  display: 'swap',
  weight: '45 920',
  variable: '--font-pretendard',
});

layout.tsx 파일에 적용해준다.

src 경로의 경우, 파일이 위치한 알맞은 경로로 해줘야 한다.

이렇게 작성한 경우, 밑의 body에 전체적으로 적용해주면 된다!

      <body className={`${pretendard.variable} font-pretendard`}>
        <QueryProvider>{children}</QueryProvider>
      </body>

현재 tanstack query, tailwind를 사용하고 있기에 className과 QueryProvider가 존재한다.

Tailwind 설정

export default {
    theme: {
        extend: { 
              fontFamily: {
                pretendard: ['var(--font-pretendard)'],
      ...

tailwind.config.ts 파일에 해당 font를 extend로 설정해준다.

실제 사용 화면 💻

tailwind에 추가로 fontSize 관련 확장도 하였기에, 밑의 코드처럼 작성해보았다!

적용이 매우 잘 된 모습을 확인할 수 있다!

Tailwind가 뭔가요?

엄청나게 많은 유틸리티 클래스를 가지고, 해당 유틸리티를 통해서 조합하여 쉽게 css를 작성할 수 있는 CSS 프레임워크다.

테일윈드의 공식 문서를 살펴보면, 정말 많은 양의(진짜 다 못센다) 클래스들이 세팅되어 있는데, 심지어 간단하고 원래 CSS 작성법을 알면 유추가 가능한 수준이라 러닝커브가 높지 않다.

<h3 className="mb-8 text-lg font-semibold" />

bootstrap이 좋나요, Tailwind가 좋나요?

몇 년 전까지만 해도 bootstrap이 tailwind보다 더 널리 사용되었지만, 현재 2024년을 기준으로 tailwind가 시장에서 더 널리 사용되고 있다.

bootstrap vs tailwindCSS

npm trends에서도 확실히 알 수 있을 정도의 차이이다.

사실 둘의 차이를 구분하는 것은 꽤나 어려운게, bootstrap의 경우 디자인 되어 있는 클래스를 사용하는 것이고, tailwind는 css를 빠르고 간단하게 인라인으로 작성하기 위해 사용된다.

하지만 가장 유명한 CSS 프레임워크이니 만큼, 현재 사용 척도를 알기에는 충분하다고 생각된다.

Tailwind를 왜 사용하나요?

공식문서에 따르면 반응형 디자인을 지원하고, hover와 focus 등을 지원하며, 다크 모드 또한 쉽게 적용할 수 있고, 스타일 재사용이 가능하며, tailwind.config의 extend를 통해 사용자가 원하는 디자인을 편리하게 추가할 수 있다는 점을 기존 CSS와 차별화되는 핵심적인 기능으로 알려주고 있다.

개인적으로, 클래스의 네이밍 등에 사용하는 시간이 단축되고 정해진 값을 끼워맞추는 작성방식이기에 개발 속도가 비약적으로 빨라졌다.

또한, 일관적인 디자인을 지원하므로 웹페이지에서 통일성을 주기 쉬우며, 이는 좋은 사용자 경험으로 이어진다고 생각한다.

그럼 단점은 없나요? 👀

세상에 단점 없는 사람이 없듯이, 테일윈드도 단점이 존재한다.

일단, 위의 장점과 상충되는 문제로 못생긴 코드를 꼽는다.

<div className="absolute bottom-full left-1/2 mb-14 hidden w-max -translate-x-1/2 transform group-hover:block">
  <div className="text-sm-medium bg-gray-90 relative z-10 rounded-lg px-8 py-4 text-sm text-white/90">
    {children}
    <div className="border-t-gray-90 absolute left-20 top-full h-0 w-0 -translate-x-1/2 border-x-8 border-t-8 border-x-transparent" />
  </div>
</div>

_ 으아악_

직관적이면서도 못생긴 코드여서, 해당 단점은 아무래도 영원히 고쳐지지 않을 듯 싶다.

또한, JS 코드가 사용할 수 없다. 설정을 열심히 만지면 구현이 가능하긴 하지만 굉장히 번거롭고 까다로운 길을 택해야 한다.

설치하는 방법

npm install -D tailwindcss
npx tailwindcss init

tailwind 공식 문서

next를 사용하는 경우, next를 설치할 때 tailwind를 사용하는지 물어본다!

tailwind를 능숙하게 사용하는 방법

tailwind의 불편한 점을 보완하기 위한 라이브러리가 많이 나와있는데, 그 중 유명한 3가지를 뽑자면 clsx, cva, tailwind-merge이다.

또한, tailwind CSS의 클래스를 권장 클래스 순서에 따라 정렬해주는 prettier 플러그인도 존재한다. prettier-plugin-tailwindcss

해당 라이브러리와 플러그인에 관해서는 다음에 정리하도록 하자!

참고

Tailwind CSS 공식문서 Hello Tailwind CSS! | 장점, 단점, 사용법 bootstrap VS tailwindcss

10월 7일부터, 11월 1일까지 코드잇에서 약 4주간의 인턴 생활을 진행하였다.

스프린트를 마무리하고, 앞으로 뭘 해야 하나 하던 나에게 코드잇 인턴십 공고는 정말 가뭄의 단비와도 같았다. 한 치의 망설임도 없이 바로 신청하였고, 정말 다행스럽게도 인턴십에 합격하게 되었다! 엄청 많은 사람들 중에서 합격했다는 게 기분이 되게 좋으면서도 싱숭생숭했다. 못 하면 어떡하지...

부트캠프에서도 스스로 성장하였다고 생각하였고, 인턴 기간동안에도 1달 동안 회의하고 코딩하고, 정말 많은 것을 배웠다고 생각한다.

팀 분배 및 프로젝트

총 10명의 인원들로 인턴 생활을 시작하였고, 5명씩 나눠지게 되었다. 하나의 프로젝트를 팀마다 각자의 방식으로 풀어나가게 되었다.

진행하게 된 프로젝트는 Codeit Resources라는 프로젝트였다. 코드잇 사내에서 사용할 회의실 예약, 좌석 예약 및 관리 프로그램을 제작하는 것이었다.

또한, 인턴에 합격된 인원은 전부 다 프론트엔드였는데, 5명으로 나누고 그 중 2명은 FE, 2명은 BE, 1명은 PM으로 진행하게 되었다. 나는 아직은 프론트엔드 기술을 더 갈고 닦고 싶어서 FE로 진행하게 되었다.

진행 과정 및 어려움

프로젝트 처음부터 살짝 난항이 있었는데, 나는 살면서 처음 보는 Turborepo를 사용하게 되었다. 여러 개의 저장소가 하나의 큰 저장소에서 관리되는 방식이었다. 꽤나 낯설기도 하고, 하나의 큰 config에서 참조하여 각자 레포의 eslint나 tsconfig, tailiwnd config를 설정하는 것이 꽤나 낯설면서도 재미있었다! 새로운 기술을 접하다 보니 의욕도 생기는 느낌이었다.

하지만 재미와 어려움은 별개의 문제이기에, 저장소의 구조를 이해하는 것에도 시간이 꽤 소요되었다. 심지어, 우리는 vercel stylelint 를 웹에서 적용하여 개발하였는데, 정말... 까다로운 lint 규칙이 많아서 당황했다.

그리고 패키지 버전 관리도 꽤나 어려움을 겪었지만, 그 문제는 어찌저찌 해결하였기에 처음에는 순탄하지 않았지만 그래도 개발 속도에 진척이 있었다.

가장 큰 문제는, 개발 기간이 4주도 채 되지 않았다는 것이다. 총 인턴 기간 4주 중에서 일주일은 서로 프로젝트 관련 회의, 기본 레포지토리 세팅, 기술 스택 선정 및 일정 관리... 예상 외로 촉박한 기간에 부담을 느꼈다. 지금 생각하면 조금 내려놓고 해도 되었을 듯 하다.

우리 팀은 맨 처음 회의를 진행하면서, 이번 인턴십의 목표를 '도전'으로 잡았다. 그 목표에 맞게 진행하면서, 정말 많이 배웠다. 사실 백엔드와 이렇게 직접적으로 협업해본 적이 아주 예전이라 걱정이 많았었는데, 스스로 API를 이해하고 Model 등을 보면서 연결해보니 백엔드 코드도 명세서 없이 이해할 수 있게 될 정도로 성장한 것 같다.

아쉬웠던 점

기간이 촉박함에 따라, 스스로 도전을 칭했음에도 여러 공통 컴포넌트를 빠르게 쳐버리는 선택을 하면서(...) 완성도가 떨어지는 결과를 가져오게 되었다.

또한 컴포넌트가 지나치게 무겁고 두꺼워지는 문제가 발생하였는데, 이 문제는 추후 리팩토링으로 해결하고 있으나 리팩토링에 걸리는 시간을 생각하면 이상적인 개발 방향은 아니었던 것 같다.

개인적으로, 해야 하는 양이 많아지면서 저절로 퇴근한 후에 집에서도 코딩을 계속 진행하였는데, 밤에 코딩하니까 배가 고프고... 무언가를 먹고 싶고... 먹으면 졸려서 코딩을 잘 못하는 식곤증의 무한루프에 빠진 적도 있다. 사실 이게 가장 힘들었다... 한 번 깨진 수면패턴은 쉽게 돌아오지 않는다는 사실이 너무 뼈아팠다😂

다시 하면 정말 잘 할 수 있는데 시켜주시면 안 되나요

위의 말만 보면 정말 너무 힘들어요... 자고 싶어요... 과 같은 경험이었던 것 같지만, 사실 스스로 정말 재미있고 신나게 인턴생활을 즐겼다고 생각한다!

마지막에, 엄청난 실력의 소유자이신 에이든 님의 지도를 따라 각자 프로젝트 동안 느꼈던 것들을 정리하면서 이야기를 나누었던 시간이 있었다. 모두 1달이라는 짧은 시간동안 열심히 달려오고, 그만큼 생각나는 것도 많았을건데 이 기회에 서로 더 이해하면서 각자 힘들었던 점과 생각을 공유해서 더 기억에 남는 것 같다.

우리 팀 최고 ㅠ.ㅠ

너무너무 아쉽지만, 그만큼 열심히 달렸다고 생각한다. 그리고 열심히 달렸음에도, 아직 부족한 점을 절실히 깨달았다.

긍정적인 조직문화와, 밝은 에너지를 한껏 받고 마무리한 인턴이었다. 앞으로도 더 열심히, 꾸준하게 준비해서 꼭 취업에 성공하자...!!!

같이 인턴을 진행했던 분들 정말 감사하고, 언제나 친절하게 인턴분들을 세심하게 신경써주신 이유정 매니저님과 기술적으로도, 멘탈적으로도 많은 도움을 주신 에이든 님 정말 감사했습니다!

너무 막연하게 생각한 것이 아닐까 생각했다. 대학교를 졸업하면 바로 취업할 수 있을 것으로 생각한 나로서는, 사회는 내 생각 이상으로 차갑고 냉정하게 신입을 골라내었다. 심지어, 요즘은 수없이 많은 사람이 개발자의 꿈을 안고 도전하는 시대가 아닌가. 취업을 위해서는 열망으로는 부족했다. 나를 어필할 수 있는 포트폴리오, 다듬어진 이력서, 그리고 무엇보다 지금보다 몇 배는 뛰어난 개발 실력이 필요했다.

이 생각을 하게 된 이후로, 나는 수많은 부트캠프를 찾아보기 시작했다. 그 중 가장 마음에 드는 커리큘럼과(react, ts, next, tailwind, 심지어 jest와 storybook까지!) 강의 사이트로 유명한 코드잇의 부트캠프를 선택하게 되었다.

👀 성장했을까...?

사실 개발 실력으로는 과거의 나에 비해서 많은 성장을 이루었다고 생각한다.

예전에 모르는 라이브러리를 보면 지레 겁을 먹고, 간단한 css도 기억이 가물가물해서 여러 군데를 돌아다니다 해결했던 나로서는, 지금의 성장이 정말 피부로 느껴졌다. 일단 모르는 라이브러리를 봐도 겁이 나지 않는다...! 공식문서의 소중함을 절절히 깨달았다.

하지만, 과거의 내가 너무 부족했다는 사실에 근거하였을 때, 지금도 정말 부족한 부분이 많은 개발자라는 것은 변함없는 사실이라고 생각한다. 세상사 완벽한 사람이 어디 있을까 하지만... 스스로 지식의 깊이를 더하고 싶다는 생각을 자주 한다.

스프린트의 기간 동안 총 3개의 프로젝트를 하였다. 기초, 중급, 심화 프로젝트로 구성되어 있다. 기초 시절의 나는 정말로... 정말로 심각한 사람이었지만 점점 팀원들의 격려와 주강사님의 친절하면서도 자세한 설명을 들으며 성장해갔다.

사실 수료한 것만으로도 잘했다고 생각한다. 6개월 동안 마음을 다잡고, 꾸준히 한 것만으로도 대단하다! 그렇지만, 열심히 해서 많은 것을 얻어갔다고 생각한다.

🕶️ 앞으로 어떻게 해야 할까

스프린트는 분명 나에게 커다란 성장의 발판이 되어주었다. 하지만 현재의 나로 만족할 수 있는가?

모르고 있을 때는 조금만 하면 넘을 수 있을 거 같은데, 막상 조금이라도 발을 담가보면 치열하게 노력해야 넘어갈 수 있는 곳이 개발이라고 생각한다. 앞으로 더 꾸준히 커리어를 쌓아가며 열심히 노력하자. 나중에 나 스스로 당당하게 한 명의 개발자라고 할 수 있게끔 자신감을 얻는 것을 목표로 할 것이다.

여담

스프린트 회고록을 작성하면서, 사실 프로젝트에서 기술적으로 성장한 부분과, 어려웠던 부분을 초점으로 두고 작성해야 할까 많이 고민하였다.

그런 부분은 나중에 또 작성하면 되는 거 아닐까 하며 글을 작성한다.

6개월이라는 시간 동안 꾸준히 수강생들을 독려해주고 응원해준 스프린트 매니저님들과, 주강사님과, 멘토님에게 정말 감사하다고 전하고 싶다. 나중에라도 꼭 만날 수 있는 기회가 있으면 좋겠다!

그리고 열심히 동고동락하며 긴 기간 동안 달려온 스프린터들에게도 감사하다. 다들 너무 좋은 성격과 밝은 에너지의 소유자여서 즐겁게 코딩할 수 있었다!

진짜 여담

사실 이 글은 2개월 전에 올려야지 올려야지 하다가 마음에 안 들어서 안 올리고, 이렇게 소감을 쓰는 게 맞나 싶어서 안 올린... 화석화가 진행 중인 글이다.

나중에 꼭 만나고 싶었던 매니저님들은 엄청나게 좋은 기회로 코드잇 인턴으로 뽑혀서 만나게 되었다! 정말 행복했다😊

짧다면 짧은 시간 동안 열심히 개발했고, 팀원들이랑 꾸준히 의논해가며 부족한 점을 채워가며 발전하는 시간이여서 더 뜻깊었던 시간이었다.

기초 프로젝트에서 스스로 만족하지 못했던 부분과, 부족하다고 생각되던 부분을 여러모로 채워나갈 수 있어서 정말... 만족스럽게 마무리한 프로젝트였다🤩

Wiki-viki 깃허브 링크

중급 프로젝트 Wikid

프로젝트 선정 이유

Wikid라는 프로젝트는, 지인들의 위키를 작성하고 공유하는 서비스이다.

기초 프로젝트와 비슷하게 4개의 프로젝트 주제 중 선택할 수 있었는데, 타인의 위키를 작성한다는 점, 마크다운 에디터 등을 사용할 수 있다는 점, 스프린트에서 매주 진행하던 스프린트 미션과 다른 부분이 많다는 점 등... 팀원들과의 회의를 통해 프로젝트를 선정하게 되었다.

또한, 난이도가 가장 높다는 부분이 선정 이유 중 하나였다. 다들 너무 잘해서 난이도 높은 프로젝트를 해도 무리가 없을 듯 했다.

🍀 완전 위키비키자나~

프로젝트를 정한 후, 프로젝트에 특별함을 더하기 위해(같은 시안으로 진행하는 팀이 많다 보니, 특별한 네이밍과 로고 등은 개발 능률을 향상시켜준다고 생각한다...) 프로젝트 이름을 정하던 도중 위키비키라는 이름이 선정되었다.

긍정적(낙관적) 사고를 기반으로, 타인이 나에 대한 위키를 써준다니 완전 럭키비키잖아~ 라는 생각으로 네이밍을 진행했는데, 찰떡같은 이름이라고 생각한다. 개발하는 내내 프로젝트에 애정을 가지고 임할 수 있었다.

기술 스택

Next. js, TypeScript, Tailwind Css, Zustand 등을 사용하였다.

Next.js

Next.js의 경우 페이지 라우터를 사용하였다. 앱 라우터의 경우 페이지 라우터에 비해 높은 러닝커브와, 비교적 안정적이지 않다는 점, 현재 개발하는 프로젝트가 소규모 프로젝트라는 점 등으로 인해 제외되었다.

TypeScript

TypeScript의 경우, 자바스크립트의 여러가지 단점을 보완해주기 때문에(타입 지정으로 인해) 필수라고 생각되어 사용하였다. API에서 받는 데이터 등의 타입을 미리 지정해두고 사용하니 쉽게 개발할 수 있었다.

Tailwind CSS

Tailwind CSS의 경우, 팀 내에서 여러 의견이 나왔던 기술이다. Tailwind를 아예 사용해보지 않은 사람이 있었고, 이미 styled components, module.css 등으로 css를 작성하는 경우가 많았기 때문이다.

이에 대해서 해결하기 위해 팀적으로 기술적인 스터디를 진행해서, 어떤 기술 스택을 도입하기 전에 현재 우리가 진행할 프로젝트에 어울릴지, 장점과 단점은 무엇인지 매일 의견을 나누었다.

결론적으로, Tailwind의 획기적으로 감소되는 css 코드 작성 시간(처음에는 러닝커브가 존재하지만, 조금 익숙해지면 정말 빠르게 작성할 수 있다), next에서 추천하는 방식(빌드 타임에 스타일시트를 가져오는 방식이다), 클래스 네이밍 고민 시간 절약... 등으로 인해 Tailwind를 사용하게 되었고, 지금은 매우 만족하면서 사용하고 있다. 다음 프로젝트에서도 Tailwind를 계속 사용할 예정이다.

extend로 미리 피그마 시안의 color와 font style을 지정해두고 사용하니 정말 편리했다.

Zustand

Zustand는 사실 공부의 목적으로 사용하였다. 전역 상태관리 라이브러리를 사용해보고 싶었는데, 현재 zustand가 가장 많이 사용되는 상태관리 라이브러리고, 비교적 러닝커브가 낮고(프로젝트 기간이 짧은 나에게는 정말 큰 이점이었다), 번들 사이즈가 정말 작다는 점 등으로 인해 선택하게 되었다.

물론 React의 Context API를 사용하여 상태 관리가 가능하지만, 학습적인 측면이 더 컸다고 생각한다.

회고

KPT 방식으로 진행하였다.

👏 Keep

서로를 배려하여 트러블 없이 즐겁게 프로젝트를 완수했다. 매일 데일리 스크럼을 통해 각자의 작업 상황을 파악했다. 리뷰 속도가 빠르며, 팀원들끼리 아낌없이 칭찬하고 부족한 부분에 대해서는 꼼꼼하게 피드백했다. 본인이 맡은 일에 대해 책임을 가지고 마감 기한보다 빠르게 작업했다. 사용자 경험 측면을 고려하고, 기능 및 성능 개선과 리팩토링 등 부가 요소에도 신경쓰며 작업했다.

😢 Problem

마감 기한이 다가올수록 본인이 구현해야 할 작업에 집중하다 보니 코드 리뷰가 늦어졌다. 다들 개발을 쉬지 않고 너무 열심히 하다 보니 컨디션이 좋지 않을 때가 있었다. 이슈 트래킹과 일정 관리 도구를 활용하지 않아 프로젝트의 전체 진행 상황 파악이 어려웠다. 디스코드에 잡담이 많아 중요한 메시지를 놓치거나 찾기 어려웠다.

💪 Try

시간 분배에 신경을 쓰며 코드 리뷰에 시간을 투자해 봐야겠다.. 건강을 잘 챙기고 쉴 때는 쉬면서 작업해 봐야겠다. 다음 프로젝트에서는 일정이 길기 때문에 노션, 깃허브 프로젝트, 지라 등 다양한 도구들을 사용하여 관리를 해 봐야겠다. 잡담은 새로 스레드를 만들어 사용하거나 새로운 채널을 파서 소통해 봐야겠다.

개인적인 문제점

컴파운드 패턴 미사용

컴파운드 패턴에 대해 자세히 알지 못했고, 시간적으로 여유가 없어 Prop Drilling이 일부분 일어나는 컴포넌트를 작성하였다. 나중에 리팩토링을 진행하면서 어느 정도 해결하였지만, 처음부터 컴파운드 패턴을 사용하여 컴포넌트를 더 구조화하였으면 어떨까 하는 아쉬움이 존재한다.

이슈 트래킹 방식의 문제점

깃허브 이슈를 브랜치를 생성하는 용도로 사용한 것 같다. 정말 긴급한 버그나, 바로 수정해야 할 핫픽스, 기능적 에러 등을 이슈에다가 보관하였으면 좋았을 것 같다.

PR 세분화

중간에 게시글 상세 페이지를 구현할 때, 아무 생각 없이 페이지 전체를 구현한 후 PR을 올렸었다. 하지만 그 때 기능적으로 추가된 부분이 정말 많았어서(게시글 삭제, 댓글 작성, 댓글 수정, 댓글 삭제, 게시글 좋아요 표시, 댓글 무한스크롤 등...) 전체적으로 file change가 많아서 PR도 오래 걸렸고, 코드 리뷰도 오래 걸렸고, merge도 뒤늦게 되었다.

PR을 세분화하고, 이슈의 하위 이슈를 만들어서 관리하도록 하자!

개인 KPT 회고

이제 KPT로 회고해보도록 하자.

👏 Keep

기능 구현을 깔끔하게 완료하였다. 사용자 경험 측면을 고려하여, 애니메이션과 framer motion 등을 사용하여 부드럽게 만들었다. 데일리 스크럼, 팀 미팅 등에 꾸준히 참여하였고, PR 또한 꾸준히 작성하였다.

😢 Problem

코어타임을 지정해두었지만, 개발을 코어타임이 아닌 밤에 했던 적이 꽤나 존재하였다... 너무 늦게 자서 기상 시간이 점점 늦어져 몸상태가 말이 아니었다...

💪 Try

이슈트래킹 방식에 대해 더 생각해보자! 일찍 자고 일찍 일어나자! 다른 팀원의 장점을 열심히 흡수해보도록 하자!

맡은 부분에 대해 회고를 남길까 헀지만, 전체적으로 작성하는 회고를 남기기로 하였다. 중급 프로젝트를 너무 만족스럽게 마무리해서 정말 좋다! 다음 프로젝트도 열심히 해서 유종의 미를 거둬보도록 하자!😎

TanStack Query란 무엇인지, 왜 사용하는지 한 번 알아보도록 하자!

✨ TanStack Query란?

TanStack Query 공식사이트

서버 상태 가져오기, 캐싱, 동기화 및 업데이트를 보다 쉽게 다룰 수 있도록 도와주는 라이브러리이다. 클라이언트 상태와 서버 상태를 명확히 구분하기 위해 만들어졌다.

데이터를 불러오다 보면 코드가 복잡해지는 경우가 많은데, 그런 방식과 달리 간단하고 직관적으로 사용할 수 있다.

기능

• 캐싱
• 동일한 데이터에 대한 중복 요청을 단일 요청으로 통합
• 백그라운드에서 오래된 데이터 업데이트
• 데이터가 얼마나 오래되었는지 알 수 있다.
• 데이터 업데이트를 가능한 빠르게 반영
• 페이지네이션 및 데이터 지연 로드와 같은 성능 최적화
• 서버 상태의 메모리 및 가비지 수집 관리
• 구조 공유를 사용하여 쿼리 결과를 메모화

사용하는 방법

npm install @tanstack/react-query

해당 라이브러리를 설치한 후, QueryClient를 import해서 새로운 쿼리 클라이언트를 만들어야 한다. 그리고 그것을 QueryClientProvider를 통해 App 컴포넌트의 자손 컴포넌트에 전달해야 한다.

import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import HomePage from './HomePage';

const queryClient = new QueryClient();

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <HomePage />
    </QueryClientProvider>
  );
}

export default App;

💡 useQuery

useQuery 공식문서 TanStack Query에 존재하는 다양한 API중 하나로, GET 요청에 대한 데이터를 관리한다.

useQuery({
  queryKey: ['posts', username],
  queryFn: () => getPostsByUsername(username),
  staleTime: 60 * 1000,
});

queryKey 필수 값이고, 해당 쿼리에 사용할 쿼리 키이다.

queryFn 백엔드에서부터 데이터를 받아오는 함수를 지정해주자.

staleTime 데이터가 언제까지 fresh 상태를 유지할 것인지 정할 수 있다.

isPending, isError를 통해 로딩 처리와 에러 처리 또한 가능하다.

정말 너무너무 많으므로 다른 것이 궁금하면 공식문서를 참고하도록 하자!

🤔 useMutation

useMutation 공식문서

데이터베이스에 값을 추가하거나 변경, 삭제하는 경우 사용한다. POST, PATCH, PUT, DELETE 요청에 대한 데이터를 관리한다.

const mutation = useMutation({
  mutationFn: PatchByUsername(name),
  onMutate() {
    /* ... */
  },
  onSuccess(data) {
    console.log(data);
  },
  onError(err) {
    console.log(err);
  },
  onSettled() {
    /* ... */
  },
});

onSuccess, onError 메서드를 통해 성공했을 시, 실패했을 시 response 데이터를 핸들링할 수 있다.

onMutate는 mutation 함수가 실행되기 전에 실행되고, mutation 함수가 받을 동일한 변수가 전달된다.

onSettled는 try...catch...finally 구문의 finally처럼 요청이 성공하든 에러가 발생하든 상관없이 마지막에 실행된다.

참고

TanStack Query react-query-tutorial 카카오페이 프론트엔드 개발자들이 React Query를 선택한 이유

그런데, 너무 단순한 동작만 반복하는 느낌이 들어서... 아직 css 고수가 아닌 나는 좀 더 쉬운 방법이 없을까 찾아보게 되었다.

그래서 찾은 것이 lottie!!!

💡 Lottie

에어비엔비에서 개발한 오픈소스 모바일 라이브러리이다. Json 기반 애니메이션 파일을 사용하여 애니메이션을 렌더링한다.

벡터 기반의 애니메이션이므로, 아무리 확대해도 깨지지 않는다는 장점이 있다!

png와 gif에 비해, 정말 획기적인 용량을 보여주는 lottie! 한 번 사용해봐야 할 것 같지 않은가...

어떻게 적용하나요?

일단 lottiefiles에 접속하여, 원하는 애니메이션을 검색한다.

원하는 애니메이션을 찾았다면, json 파일 형식으로 다운로드를 하면 된다.

그 후에, npm에서 lottie-react를 install해주도록 하자.

npm i lottie-react

이제 컴포넌트에 lottie를 import 후 적용하면 된다!

import Lottie from 'lottie-react';
import CheckLottie from '@/../public/lottie/check.json';

...

<Lottie animationData={CheckLottie} />

후기

프로젝트를 여러모로 이쁘게 만들어준다. 아이콘이 밋밋하거나, 움직여서 사용자의 시선을 끌게 할 때 등, 여러 상황에서 사용할 수 있을 것 같다!

자세히 알기 위해서는, 우선 인증이 무엇인지에 대해 알아야 한다.

인증

어떤 사용자 또는 장치의 신원을 확인하는 과정

예시로, 신원을 확인하기 위해 신분증을 제출하는 경우 등을 인증절차라고 할 수 있다.

인가

어떤 개체가 어떤 리소스에 접근할 수 있는지, 어떤 동작을 수행할 수 있는지 검증하는 것

접근 권한을 얻는 일을 말한다.

예시로, 신원을 확인하여 회원가입을 진행한 A와 B가 존재한다고 하자. A가 게시글을 작성하였을 때, B는 A가 작성한 게시글에 대해 수정과 삭제의 권한을 가지고 있지 않다. 타인의 리소스에 대해 인가되어 있지 않기 때문이다.

✨ 인증은 인가로 이어지지만, 인가는 인증으로 이어지지 않는다.

세션 기반 인증

세션이란?

서버가 저장하는 사이트 방문자들에 대한 기록이다. id, ip 주소, 마지막 방문 시기, 사용한 브라우저 등의 정보가 담겨 있다.

세션 기반 인증

세션을 사용한 인증 방식이다. 유저가 로그인 할 시, 서버는 세션 정보를 기록한 뒤 세션을 식별하는 id를 Set-Cookie로 클라이언트에 응답하게 된다. 클라이언트가 서버에 요청할 때, 서버에서 응답한 쿠키를 자동으로 포함하게 된다.

서버는 클라이언트의 쿠키에 담긴 세션 id만 확인해서 방문자의 신원을 파악할 수 있다!

일정한 기간이 지나거나, 클라이언트에서 로그아웃 요청을 보낼 경우 해당 세션이나 로그인 유저를 만료 처리한다.

토큰 기반 인증

인증 토큰

유저에 대한 정보를 암호화한 문자열이다. 특정 콘텐츠에 대해 접근할 수 있게 해주기 때문에 Access Token이라고도 한다. JWT (JSON Web Token) 형식을 가장 많이 사용하고 있다.

토큰 기반 인증

유저의 로그인 상태를 저장하고, 요청이 올 때마다 저장 및 확인하지 않고도 유저를 식별할 수 있다. 대신, 토큰 자체를 해석해서 사용하게 된다.

유저가 로그인 할 시, 유저를 식별할 수 있는 id, 만료일 등의 내용이 담긴 토큰을 만들어 클라이언트에게 응답한다. JWT의 경우 디지털 서명이 존재해 토큰의 내용이 위변조 되었는지 서버측에서 확인이 가능하다. 이후 클라이언트는 응답으로 받은 토큰을 서버에 요청할 때 Authorization 헤더에 담아 전송한다. 서버는 클라이언트의 토큰을 비밀키를 사용해 해석, 유효성 검증 및 유저를 특정한다.

만료 시간이 지나지 않고, 토큰을 가지고 있는 경우에는 항상 로그인 상태를 유지할 수 있다. 로그아웃을 하고 싶으면 클라이언트에서 저장한 토큰을 삭제하면 된다.

세션과 토큰 인증의 차이

사이즈

세션의 경우 Cookie 헤더에 세션 id만 보내면 되므로 트래픽을 적게 사용한다. 토큰의 경우(JWT) 사용자 인증 정보, 토큰의 발급 시각, 만료 시각, 토큰의 id 등의 정보를 담으므로 세션 id에 비해 정보가 방대하여 더 많은 네트워크 트래픽을 사용한다.

효율성

토큰 기반 인증의 장점이다.

세션 기반 인증의 경우, 서버는 항상 로그인 세션을 저장하고 매 리퀘스트가 일어날 때 유저가 누구인지 비교해야 한다.

토큰 기반 인증의 경우 토큰 자체 내용을 해석하면 되기에 효율적으로 작동이 가능하다.

유연성

토큰 기반 인증의 경우, 토큰을 발행하는 방법이 똑같고, 시크릿 키만 존재한다면 발행을 한 곳과 확인을 하는 곳이 달라도 유연하게 인증이 가능하다.

RESTful API

세션 정보와 같이 서버가 상태 정보를, 예를 들어 유저가 로그인을 했는지 안 했는지를 저장하고 있는 걸 stateful하다고 표현한다.

REST에 부합하기 위해서는, 서버가 상태 정보를 저장하지 않는 특성(stateless)이 있어야 한다.

서버는 클라이언트에서 보내는 정보만으로 충분히 상태를 파악할 수 있어야 한다!

이 기준으로 보았을 때, 토큰 기반 인증이 더 어울린다고 할 수 있다.

무효화

세션 기반 인증의 장점 중 하나이다. 서버에서 세션 데이터를 따로 관리하므로 특정 세션을 손쉽게 무효화가 가능하다.

안전장치를 더 쉽게 사용할 수 있다는 점으로 이해하도록 하자.

참고

Using Session Cookies Vs. JWT for Authentication 코드잇-세션vs토큰 기반 인증

스프린트 미션을 하다가, React + JavaScript로 이루어진 프로젝트를 타입스크립트로 마이그레이션 하는 미션을 받게 되었다.

마침 타입스크립트를 배우고 있던 도중이라 정말 잘 해봐야지...! 하면서 열심히 하였으나, 처음이다 보니 너무 삽질을 많이 했다.

적용이 생각보다 어렵다. 그냥 확장자 바꾸고 뭐 하면 끝 아니냐~ 하지만 정말 생각보다 오류가 많았다.

적용 순서

1. TypeScript 설치

npm install --save typescript

만약, 사용하고 있는 라이브러리가 있다면 설치해주도록 하자. Node의 경우, ts를 해석하지 못하므로 꼭 ts-node를 설치해주도록 하자!

npm install --save @types/node @types/react @types/react-dom

style-components를 사용하고 있다면 @types를 설치하도록 하자.

npm install @types/styled-components --save-dev

2. tsconfig.json 생성하기

tsc --init

tsconfig란, 타입스크립트를 자바스크립트로 변환할 때의 설정을 정의해 놓은 파일이다.

{

  "compilerOptions": {

    "baseUrl": "src",

    "target": "es5",

    "lib": ["dom", "es2015"],

    "allowJs": true,

    "checkJs": false,

    "skipLibCheck": true,

    "strict": true,

    "esModuleInterop": true,

    "allowSyntheticDefaultImports": true,

    "module": "esnext",

    "moduleResolution": "node",

    "resolveJsonModule": true,

    "isolatedModules": true,

    "noEmit": true,

    "jsx": "react", // or "react-jsx" for React 17+

    "forceConsistentCasingInFileNames": true,

  },

  "include": ["src"]

}

3. custom.d.ts 파일 추가

d.ts 파일이란 타입만 저장할 수 있는 파일 형식이다.

나중에 js, jsx 파일을 tsx로 확장자 변경을 하게 된다면, 분명 import 시 svg, png 등을 인식하지 못하는 문제가 일어난다.

타입스크립트의 타입 시스템 범위 밖에 있으므로 오류가 일어나기에, 우리는 custom.d.ts라는 파일을 만들고 여기 안에 커스텀 타입을 선언하여 오류가 나지 않도록 할 것이다!

declare module '*.svg' {
  const content: any;
  export default content;
}

declare module '*.png' {
  const content: any;
  export default content;
}

declare module '*.jpg' {
  const content: any;
  export default content;
}

declare module '*.jpeg' {
  const content: any;
  export default content;
}

4. 😤 대망의 확장자명 변경 (tsx)

이제 드디어 확장자명 변경을 할 시간이 왔다! 여기서 중요한 것은, js, jsx를 전부 tsx로 변경해야 한다는 점이다.

이 글은 React+Typescript를 사용한다는 것을 전제로 작성하였으므로, 꼭 tsx로 변경해주길 바란다.

4.1 슬픈 오류의 시간

나는 처음에 ts와 tsx가 헷갈렸기에 아무 생각 없이 "js로 작성되어 있는건 ts로, jsx인 거는 tsx로 바꾸면 되겠지~" 라고 생각했지만, 정말 큰 오산이였다.

~은 값을 참조하지만, 여기서는 형식으로 사용되고 있습니다...

이 오류는 타입스크립트가 값과 타입을 제대로 구분하지 못할 때 생기는 문제인데, ts는 기본적으로 jsx 문법을 인식하지 못한다. tsx는 React 컴포넌트의 타입을 자동으로 추론하고 처리할 수 있어서(JSX 구문을 인식) 오류가 일어나지 않는 것이다.

이런 오류를 겪기 싫으면 tsx로 해두자

빨간 줄 천지인 프로젝트를 볼 수 있는데, HTML 타입과 Props 타입 등을 천천히 정해가면서 오류를 없애보자!

interface를 적재적소에 활용하는 것이 많은 도움이 된다.

결론적으로, TypeScript가 우리가 작성했던 코드, 컴포넌트의 타입을 올바르게 추론하고 검사할 수 있도록 하나하나 지정해두자.

4.2 다 지정해야 하나요?

article useState의 경우, 초깃값으로 []가 지정이 되어 있기에 정확한 타입 추론이 어렵다. 이런 경우에는

위와 같이 정확하게 타입을 지정해주는 것이 좋다.

keyword useState의 경우, 초깃값으로 ""이 지정되어 있다. 이런 경우 TypeScript는 type 추론을 정확하게 할 수 있으므로 굳이 지정해줄 필요가 없다!

처음부터 너무 엄격하게 적용하지 말고, 점진적으로 strict 레벨을 증가시키도록 하자.

마치며

JavaScript에서 TypeScript로 마이그레이션 하는 것은 예상 외로 시간이 많이 걸리니 넉넉하게 잡아두고 해보자!

참고 자료

타입스크립트로 바꾸기(벨로그) 타입스크립트 환경으로 마이그레이션하기(벨로그) 자바스크립트 코드에 타입스크립트를 적용할 때 주의해야 할 점(핸드북)

자바스크립트에 타입을 부여한 언어입니다. 자바스크립트의 확장된 언어라고 볼 수 있습니다!

자바스크립트 기반으로 작동되기에, 브라우저에서 실행하기 위해서는 ts 파일을 js 파일로 변환해주는 과정이 필요합니다. 이를 '컴파일 과정'이라고 합니다.

자바스크립트에 어떤 한계가 있나요?

일단, 자바스크립트는 동적 타입 언어입니다. 런타임 환경에서 타입을 결정하는 언어입니다. 배우기 쉬우며, 타입을 따로 지정하지 않아도 된다는 장점이 존재합니다.

하지만 실행 도중 제가 생각한 타입과 다른 타입이 결과값으로 나온다면... 자바스크립트는 바로 타입 에러를 띄워버립니다. 정말 무서운 에러들입니다

타입스크립트는 어떤 이점이 있나요?

타입스크립트는 점진적 타입 언어입니다.

동적 타입 시스템과, 정적 타입 시스템을 혼합한 것 같은 타입 시스템을 사용합니다.

정적 타입 시스템처럼 변수의 타입을 코드 실행 전에 결정하고, 타입 오류가 없는지 프로그램 실행 전에 코드를 검사합니다.

동적 타입 시스템처럼 모든 변수에 일일히 타입을 명시하지 않아도, 변수에 담기는 초기값을 기준으로 자동으로 타입을 알아서 추론하기도 합니다.

이런 특징을 통해, 컴파일 단계에서 오류를 포착할 수 있고, 어떤 타입의 값이 필요한지 바로 파악이 가능합니다.

🤔 타입스크립트는 항상 좋나요?

타입스크립트는 위와 같이 정말 좋은 점을 많이 가지고 있지만, 결국 자바스크립트의 장점인 유연성이 사라진 형태입니다. any 등으로 보완할 수 있지만, 사용하는 시점에서 타입스크립트의 장점이 많이 퇴색된다고 생각합니다.

또한, 처음에 입문하기에 어려우며 코드 작성을 할 때 자잘한 타입을 전부 지정해야 하므로 시간이 오래 걸린다는 단점이 있습니다.

그래도, 사용하면 확실히 좋다!

컴파일 단계에서 오류를 포착할 수 있으므로, 에러를 예방하는 효과가 정말 크다고 생각합니다. 또한, 코드를 통해 어떤 타입의 값이 필요한지 쉽게 파악이 가능하여 흐름을 이해하기 쉽고, 협업에 도움이 됩니다.

참고

타입스크립트 핸드북 한 입 크기로 잘라먹는 타입스크립트 타입스크립트 공식문서

// 1번
let num = 1;

// 2번
setTimeout(() => {
  num = 2;
}, 0);

// 3번
num = 3;

// 4번
console.log(num);

다행히도 비동기 실행에 대한 공부를 어느 정도 했던 상태인지라, 간단하게 답을 유추할 수 있었다. 이 코드를 이해하기 위해선 일단 비동기 실행에 대해 알아봐야 한다!

비동기 실행이 뭔데?

특정 코드의 연산이 끝날 때까지 코드의 실행을 멈추지 않고, 다음 코드를 먼저 실행하는 자바스크립트의 특성을 의미한다.

// #1
console.log('Hello');
// #2
setTimeout(function() {
    console.log('Bye');
}, 3000);
// #3
console.log('Hello Again');

위의 예제 코드를 보았을 때, 비동기 실행에 대한 이해가 없다면 실행 순서를 다음과 같은 결과값으로 생각할 것이다.

1. Hello 출력
2. 3초 뒤 Bye 출력
3. Hello Again 출력

하지만 실제 실행시켜보면 순서가 다른 걸 알 수 있다.

1. Hello 출력
2. Hello Again 출력
3. 3초 뒤 Bye 출력

위의 setTimeout 함수의 콜백은 비동기적으로 실행되기에, 실행 흐름이 다음 코드로 바로 넘어가서 나중에 콜백이 실행되는 것이다.

비동기 실행을 하는 함수들

1. fetch
2. setTimeout 특정 함수의 실행을 원하는 시간만큼 뒤로 미루기 위해 사용
3. setInterval 특정 콜백을 일정한 시간 간격으로 실행하도록 등록
4. addEventListener 클릭과 같은 특정 이벤트가 발생 시, 실행할 콜백을 등록하는 메소드.

예제 답

결론적으로, 맨 위의 예제에 대한 답은 3이다. console.log가 실행될 당시의 num의 값은 3이기 때문이다.

참고

MDN_ 비동기 프로그래밍(JS) 비동기 실행의 간단한 동작 순서

클라이언트가 웹 서버에서 사용자 리퀘스트의 목적 혹은 종류를 알리는 수단이다.

주요 메소드

💡 GET : 리소스 조회

서버에서 클라이언트가 요청하는 경우, URL 입력, 링크 클릭의 경우에도 GET에 해당한다. GET 요청은 멱등성을 가져, 여러 번 조회를 하여도 리소스는 변하지 않는다. GET 요청에서 서버에 데이터를 전달하는 경우, 쿼리스트링을 통해 전달한다.

💡 POST : 리소스 생성, 수정

새로운 리소스를 생성, 기존 리소스를 수정하기 위해 서버에 데이터를 보내는 메서드이다. 리퀘스트 바디를 사용하고, 일반적으로 캐시되지 않는다. 서버의 데이터 변경이 일어날 수 있다. 멱등성을 가지지 않아, 여러 번 리퀘스트를 반복할 겨우 동일한 응답을 보장할 수 없다.

💡 PUT : 리소스 대체, 수정, 없을 경우 생성

새로운 리소스를 생성하거나 기존 리소스를 수정하기 위해 서버에 데이터를 보내는 메서드이다. 서버에 리소스가 없을 경우 생성, 있을 경우 클라이언트가 보낸 데이터로 대체한다. 멱등성을 가진다.

💡 DELETE : 리소스 삭제

지정한 리소스를 삭제하는 메서드이다. 서버의 데이터를 삭제하는 변경을 하며, 멱등성을 가진다.

💡 PATCH : 리소스 부분 변경(수정)

기존 리소스의 부분적 수정을 위한 메서드이다. PUT은 데이터의 완전 대체이고, PATCH는 부분 수정을 한다. 멱등성을 가지지 않는다.

HEAD

특정 리소스를 GET 메서드로 요청 시, 돌아올 헤더를 받기 위한 메서드이다.

OPTION

서버와 브라우저가 통신하기 위한 통신 옵션을 확인하기 위한 메서드이다. 어떤 method, header, content-type을 제공하는지 확인할 수 있다.

CONNECT

대상 자원으로 식별되는 서버에 대한 연결 요청을 하는 메서드이다.

참고

HTTP 메서드란? MDN HTTP 요청 메서드

자식 요소에서 부모 요소로 이벤트가 전파되는 것

기본적으로 이벤트 버블링이 일어난다. event.stopPropagation() 메서드로 전파를 막을 수 있다.

이벤트 캡처링

부모 요소에서 자식 요소로 이벤트가 전파되는 것

캡처링에서 이벤트 핸들러를 동작시키려면,addEventListener의 세번째 프로퍼티에 true 혹은 {capture: true}를 전달하면 된다.

이벤트 위임

비슷한 방식으로 여러 요소를 다뤄야 할 때 사용한다. 요소의 공통 조상에 이벤트 핸들러를 하나만 할당해도, 여러 요소를 다룰 수 있기에 편리하다.

버블링을 꼭 써야하는가?

버블링은 꼭 멈춰야 하는 상황이 아닌 이상 사용하는 것이 좋다. 버블링을 막아야 해결되는 문제는 커스텀 이벤트를 통해 해결할 수 있고, 이벤트 위임이라는 효율적인 방식을 사용하여 코딩할 수 있기 때문이다.

참고

이벤트 위임 이벤트 전파와 이벤트 위임 이해하기 이벤트 버블링과 캡처링에 대한 정리

중복 선언 허용, 스코프, 호이스팅을 기준으로 살펴볼 것이다.

변수 선언 방식

💡var

• 선언과 초기화가 동시에 진행된다.
• 재선언, 재할당이 가능하다.

var ex1;
console.log(ex1); //undefined

// 아무것도 할당하지 않을 시 undefined 값이 암묵적으로 할당된다.

/*
1. 선언 단계 : 변수 이름을 등록
2. 초기화 단계 : 값을 저장하기 위해 메모리 공간을 확보, undefined 할당해 초기화
이전에 다른 애플리케이션이 사용했던 값(쓰레기 값)이 남아 있을 수 있다.
*/

💡let (ES6)

• 선언만 이루어진다.
• 재선언이 불가능하고, 재할당이 가능하다.

let ex1;
console.log(ex1); //undefined
ex1 = 1;
console.log(ex1); // 1

💡const (상수, ES6)

• 선언만 이루어진다. 선언과 동시에 초기화를 해야 한다.
• 재선언, 재할당이 불가능하다.

const ex1 = 0;
ex1 = 1; //TypeError

중복 선언 허용

var의 경우 허용하지만, let과 const는 허용하지 않는다.

var user = "Bae";
var user = "Jun"; //에러는 발생하지 않는다.

alert(user); // Jun

let myName;
let myName; // SyntaxError

스코프

💡스코프란?

• 식별자(변수명, 함수명, 클래스명…)의 유효범위를 뜻한다.
• 전역에 선언된 전역변수는 전역 스코프를 가져 모든 곳에서 참조가 가능하다.
• 지역에 선언된 지역변수는 지역 스코프를 가져 해당 지역, 하위 지역에서만 참조된다.

var의 경우 함수 스코프를 지원하고, let과 const의 경우 블록 스코프를 지원한다.

var foo = 123; // 전역 변수

console.log(foo); // 123

{
var foo = 456; // 전역 변수
}

console.log(foo); // 456

let foo = 123; // 전역 변수

{
  let foo = 456; // 지역 변수
  let bar = 456; // 지역 변수
}

console.log(foo); // 123
console.log(bar); // ReferenceError: bar is not defined

호이스팅

💡호이스팅이란?

• 변수 선언문이 코드의 선두로 끌어 올려진 것처럼 동작하는 자바스크립트 고유의 특징

let, const로 선언한 변수는 선언되기 이전에 사용할 수 없다. var 로 선언한 변수는 함수 스코프를 기준으로 선언되기 이전에도 변수에 접근이 가능하다.

console.log(myVariable);
let myVariable; // Uncaught ReferenceError

console.log(myVariable);
var myVariable; //undefined

참조

PoiemaWeb

오래된 var

자바스크립트에서는 원시값과 참조값 두 가지 데이터 타입이 존재한다.

💡원시값

• 기본 자료형(단순한 데이터)를 의미한다.
• Number, String, Boolean, Null, Undefined , Symbol , BigInt
• 변수에 원시값을 저장 시, 변수의 메모리 공간에 실제 데이터 값이 저장된다.

let a = 1; 
let b = a;

a = 123;

console.log(a); // 123
console.log(b); // 1

//변수에 기본형을 할당 시, 새로운 메모리 공간에 독립적인 실제값이 복사된다.

💡참조값

• 여러 자료형으로 구성되는 메모리에 저장된 객체를 의미한다.

• Object , Functio , Array …

• 변수에 객체를 저장 시, 독립적인 메모리 공간에 값을 저장하고 변수에 저장된 메모리 공간의 참조를 저장하게 된다.

  → 할당된 변수를 조작하는 것은, 객체가 아닌 해당 객체의 참조를 조작하는 것이다.

let obj1 = {num:1};
let obj2 = obj1;

obj1.num = 123;

console.log(obj1); // num:123
console.log(obj2); // num:123

//변수에 참조형을 할당 시, 해당 객체의 메모리 주소값이 복사된다.

얕은 복사

객체의 메모리 주소 값을 복사하는 것!

💡방법

1. Array.prototype.slice()
/* start ~ end 인덱스까지 기존 배열에서 추출하여 새로운 배열을 리턴.
    start, end를 설정하지 않을 시 기존 배열을 전체 얕은 복사
    slice() 메소드의 경우 기본적으로 얕은 복사 수행 */

2. Object.assign(생성할 객체, 복사할 객체);

3. Spread 연산자(전개 연산자)

깊은 복사

실제 값을 복사하는 것!

💡방법

1. JSON.parse(JSON.stringfy(obj))
/* stringfy의 경우 객체를 json 문자열로 변환
    이 과정에서 객체의 참조가 모두 끊어짐
    객체를 json 문자열로 변환 후 
    다시 parse를 통해 원래 객체로 만든다. */

    - 가장 간편하다.
    - function이 있는 경우, undefined도 처리한다
    - 다른 방법에 비해 느리다는 단점이 있다.

2. 커스텀 재귀 함수
    - 객체의 함수도 제대로 표현할 수 있다.
    - 복잡하다.

3. Lodash와 같은 외부 라이브러리
    - 사용에 제약이 없다면 가장 효과적이다.

참조

[JavaScript] 깊은 복사, 얕은 복사

[JS] 얕은 복사, 깊은 복사 차이 쉽게 이해하기

브랜치를 나누는 전략 중 하나이다.

• main: 정식 배포의 기준이 되는 브랜치이다. 언제나 배포 가능한 상태로 유지되어야 하는 브랜치이다.
• develop: 개발 중인 코드를 관리하는 브랜치이다. 새로운 기능 개발, 개발된 변화를 담은 버전 배포작업이 시작될 수 있다.
• feature: 개발할 기능을 위한 브랜치이다. 기능 개발이 완료될 시, develop으로 병합되고 feature는 제거된다.
• release: 배포를 위한 브랜치이다. 배포 전 마무리 작업, 버그 수정이 이루어진다. 완료 시 main, develop으로 병합되고 제거된다.
• hotfix: 긴급한 버그 수정을 위한 브랜치이다. master 브랜치를 기준으로 생성하게 된다.

왜 branch를 분류하나요?

협업 중 수정된 코드의 충돌을 방지하기 위해서

장점

• 안정적인 배포를 위한 구조
• 긴 개발 주기에 적합, 복잡한 기능 개발 버그 수정에 유용

단점

• 브랜치가 많아지고, 관리해야 할 작업 증가
• 작은 규모의 프로젝트에는 비효율적

참고

git-flow 도구 github Convention 정리, 모음 git flow란

여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이다.

독립적으로 어떤 작업을 진행하기 위한 개념

브랜치를 나누지 않으면, 여러 사람이 commit할 경우 충돌이 일어날 확률이 높다. 또한, 서로 작업한 commit 내역을 내 로컬 repo에 계속 반영해야 한다!

branch merge

현재 branch에서 다른 branch를 합칠 때 사용한다.

Create a merge commit

각각의 branch에 남은 commit을 히스토리에 그대로 남긴다.

commit 이력을 모두 남겨야 할 때 사용한다.

git merge {머지할 브랜치}

Squach and merge

개발용 branch에 있던 내용을 하나로 합쳐서 중앙 branch에 하나의 commit으로 저장하는 전략

기존 변경사항들의 상세내용보다, merge 자체에 목적을 두고 사용한다.

다만, 개발용 branch에서 어떤 코드를 언제 바꿨는지에 대해 헷갈릴 수 있으므로 주의!

git merge --squash

![] (https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbBNK1m%2FbtrVo5r9pF5%2F9qrwyTxP3XGHwk7jpBQd8K%2Fimg.png)

Rebase and merge

Rebase라는 기능을 이용한다.

히스토리의 Base를 직접 옮겨서 처리하는 방식이므로, 개발용 branch에서 변경한 내용을 중앙 branch에서 변경한 것처럼 바꿔버릴 수 있다!

Merge commit이 없으므로, 어느 시점에 Merge가 되었는지 나중에 판단하기 어렵다.

git merge -ff

그래서, 뭐가 더 좋나요?

특정 기능 개발 후 develop branch에 머지하려고 하면, Squash and Merge가 유용하다.

develop branch를 production branch로 merge하고자 할 때는 develop branch에 분기가 남아있다면, production branch는 간결하게 유지하고자 Rebase and Merge가 유용하다.

참고

https://ssocoit.tistory.com/273

Position

글의 흐름에서 벗어나서, 요소를 자유롭게 배치할 때 사용하는 속성이다.

• static, relative, absolute, fixed, sticky 가 있다.
• top, bottom, left, right 속성으로 위치를 변경한다.

static

요소를 일반적인 문서 흐름에 따라 배치한다. 기본값으로 지정된다.

relative

요소를 일반적인 문서 흐름에 따라 배치한다. top 등의 값에 따라 위치가 변경된다.

absolute

요소를 일반적인 문서 흐름에서 제거한다. 페이지 레이아웃에 공간도 배정하지 않는다. 가장 가까운 위치 지정 조상 요소에 대해 상대적으로 배치된다. 조상 중 위치 지정 요소가 없을 시 초기 컨테이닝 블록을 기준으로 삼아 배치된다. .

fixed

요소를 일반적인 문서 흐름에서 제거하고, 페이지 레이아웃에 공간도 배정하지 않는다. 뷰포트의 초기 컨테이닝 블록을 기준 삼아 배치된다. 마우스 스크롤로 화면을 바꾸어도 움직이지 않는다! 네비게이션을 만들 때 많이 사용된다.

sticky

static처럼 원래 위치에 있따가, 정해진 위치에 브라우저가 스크롤되면 fixed처럼 고정되어 배치된다.

참고

MDN-Position