Forem: Heetae Kim

How to used CORS?

Heetae Kim — Sun, 23 Jun 2024 15:45:28 +0000

CORS?

웹 애플리케이션에서 HTTP 프로토콜을 통해 데이터를 요청하고 응답을 받는다.
즉, 웹 사이트는 URL이라는 출처를 가지고 요청을 하게 되는데, 동일 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용 하는 것을 제한하는 보안 방식을 SOP(Same Origin Polict)라 한다.

이는 악의를 가진 사용자가 정보를 탈취하거나 잠제적인 악성 문서를 격리하기 위해 브라우저에서 사용되는 방식이다.

그러나 웹 이라는 오픈스페이스 환경에서 다른 출처에 있는 리소스를 사용하는 일이 빈번하게 발생하게 되고 무작정 막을 수 없기 때문에 CORS(Cross Origin Resource Sharing) 라는 보안 방식이 등장하게 되었다.

동일 출처란 두 URL의 프로토콜, 포트(명시한 경우), 호스트가 모두 같은 출처이다.

SOP(Same Origin Policy)

다른 출처의 리소스를 사용하는 것을 제한하는 보안 방식.
XMLHttpRequest, Fetch API 처럼 JavaScript로 서로 다른 도메인에 대한 요청은 SOP 정책을 따른다.

CORS(Cross Origin Resource Sharing)

다른 출처의 자원을 공유하는 보안 방식.
교차 출처 리소스 공유(CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다. 즉, 우리가 가져오는 리소스들이 안전한지 검사하는 관문이다.
link, script, img, video, audio, iframe 태그 및 @font-face 처럼 교차 삽입의 경우 CORS 정책을 따른다.

출처를 비교하는 로직은 서버에 구현된 스펙이 아닌 브라우저에 구현된 스펙이다.

정리하자면 CORS 정책이 적용되는 네트워크 요청의 경우, 네트워크 요청(request)에는 현재 요청을 보내는 사이트의 Origin 헤더가 존재해야 하고, 네트워크 응답(response)에는 그에 상응하는 Access-Control-Allow-Origin 헤더가 존재해야 한다.

결과적으로 요청의 Origin 헤더와 응답의 Access-Control-Allow-Origin 헤더에 명시된 도메인이 일치해야만 네트워크 요청이 정상적으로 마무리되고 우리가 원했던 리소스를 가져올 수 있게 된다. -> CORS 이슈는 SOP에 의해 발생한다.

항상 이론을 이해하면서 고개를 끄덕이지만 실제로 접하면...

CORS 동작에 따른 3가지 시나리오

위에서 설명한 바와 같이 CORS는 다음과 같은 과정을 가진다.

클라이언트에서 HTTP 프로토콜을 사용하여 요청을 보내게 되는데 이 때 헤더에 Origin 으로 요청의 출처를 담아서 함께 보낸다.
서버에서 Access-Control-Allow-Origin 에 요청의 출처를 담아 클라이언트로 응답을 보낸다.
클라이언트에서 응답을 받으면 브라우저가 Origin과 Access-Control-Allow-Origin을 비교하여 SOP를 위반했는지 확인한다.

이러한 동작은 아래의 3가지 시나리오에 의해 다시 달라진다.

Preflight Request
Simple Request
Credentialed Request

Preflight Request

브라우저가 예비요청과 본 요청으로 나누어 서버로 전송하게 되는데, 이 예비요청을 Preflight 라고 한다.

실제 요청이 전송하기 안전한지 확인하기 위해 실제 요청 이전에 수행하는 사전 요청이다.
서버는 응답 헤더에 Access-Control-Allow-Origin 값을 전달하여 브라우저가 SOP 위반 여부를 판단하게 한다.
Access-Control-Allow-Origin: * | (origin)
OPTIONS 메서드를 사용하여 사전 요청을 보낸다.
일반적으로 CORS가 발생하는 요청이다.

Simple Request

명확한 명칭은 없지만 Preflight Request를 보내지 않고 서버에게 요청을 하는 것을 단순 요청(Simple Request)라고 한다.

하지만 아무 때나 단순 요청을 사용할 수 있는 것은 아니고, 특정 조건을 만족하는 경우에만 예비 요청을 생략할 수 있다. 게다가 이 조건이 조금 까다롭기 때문에 일반적인 방법으로 웹 어플리케이션 아키텍처를 설계하게 되면 거의 충족시키기 어려운 조건들이라 필자도 이런 경우를 거의 경험하지는 못 했다.

사전 요청을 보내지 않고 바로 서버에 요청을 보낸다.
서버는 응답 헤더에 Access-Control-Allow-Origin 값을 전달하여 브라우저가 SOP 위반 여부를 판단하게 한다.
Access-Control-Allow-Origin: * | (origin) | null
Access-Control-Allow-Origin: <origin> 인 경우 Vary 속성도 같이 제공해야 한다. MDN 참고

Simple Request는 아래 조건을 전부 만족해야 요청이 가능하다.

GET, HEAD, POST 메소드 중 하나를 사용

Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width 를 제외한 헤더를 사용하면 안된다.

Content-Type 사용 시 application/x-www-from-urlencoded, multipart/form-data, text/plain 만 허용

Credentialed Request

Credentialed Request은 요청 시 보안을 강화하고 싶을 때 사용하는 방법이다.
일반적으로 XMLHttpRequest, fetch는 별도 옵션 없이 브라우저의 쿠키 정보, 인증과 관련된 헤더를 요청에 넣지 않지만, Credentialed Request를 통해 헤더에 인증과 관련된 정보를 넣을 수 있다.

이때 요청에 인증과 관련된 정보를 담을 수 있게 해주는 옵션이 바로 credentials 옵션이다.

credentials 옵션 3가지

same-origin : 기본값이며, 같은 출처 간 요청에만 인증 정보를 담게 한다.

include : 모든 요청에 인증 정보를 담는다.

omit : 모든 요청에 인증 정보를 담지 않는다.

same-origin이나 include와 같은 옵션을 사용하여 리소스 요청에 인증 정보가 포함된다면, 이제 브라우저는 다른 출처의 리소스를 요청할 때 단순히 Access-Control-Allow-Origin만 확인하는 것이 아니라 Access-Control-Allow-Credentials: true 를 서버에서 응답 헤더에 포함하여 전달해 주어야 한다.

기존 CORS 방식에서 인증 관련 헤더를 포함할 때 사용하는 요청이다.
요청 헤더에 credentials 옵션을 사용하게 되면 인증 관련된 헤더를 넣을 수 있다.
서버는 응답 헤더에 Access-Control-Allow-Origin : * 값을 사용할 수 없으며, 명시적인 URL 이어야 한다.
서버는 응답 헤더에 반드시 Access-Control-Allow-Credentials : true 가 있어야 클라이언트의 인증 포함 요청에 허용이 가능하다.

ref: https://evan-moon.github.io/2020/05/21/about-cors/
ref: https://beomy.github.io/tech/browser/cors/

How to used Suspense?

Heetae Kim — Thu, 20 Jun 2024 11:12:06 +0000

React 18부터 Suspense가 API 요청에 따른 loading 상태를 표현할수 있게 되었다. 그에 따라 react-query, swr 같은 data fetching 라이브러리 역시 Suspense를 지원하고 있다. Suspense 옵션만 true 로 설정해주면, API 요청이 알아서 내부 처리를 통해 Suspense를 동작시킨다. 이로써 loading 상태를 선언적으로 보여줄 수 있게 되었다.

추상화에 대한 편리함과 사용법은 인지하고 있었지만, 추상화에 가려진 Suspense의 깊은 동작 원리에 대해서는 인지하지 못하였다.

프로젝트를 통해 Suspense 사용으로 로딩 성능이 저하되는 경험을 통해 Suspense가 어떻게 로딩 성능을 저하 시킬 수 있는지 이번 글을 통해 그 문제점과 해결책을 고민해 보았다.

data fetching 라이브러리로 react-query가 사용되었다.
정확히 말하면 data fetching을 편리하게 사용하고 관리할 수 있도록 도와주는 라이브러리 react-query가 사용되었다.

Use Suspense



function App() {
  return (
    <Suspense fallback={<div>...loading</div>}>
      <TodoList />
    </Suspense>
  );
}

function TodoList() {
  const { data: todoList } = useQuery("todos", () => client.get("/todos"), {
    suspense: true,
  });

  return (
    <div>
      <section>
        <h2>Todo List</h2>
        {todoList?.data.map(({ id, title }) => (
          <div key={id}>{title}</div>
        ))}
      </section>
    </div>
  );
}

상위에서 Suspense로 컴포넌트를 감싸주고, useQuery 옵션에서 suspense:true로 설정해 주기만 하면 fallback으로 Loading 상태를 렌더 한다. TodoList 에서 API fetch가 발생하는 동안 Loading fallback을 보여주는 것이다.

그럼 Suspense는 어떻게 동작하는 것인가?

Suspense는 React에서 데이터 로딩 상태를 처리하기 위해 도입된 개념으로, 주로 비동기 작업과 연관되어 있다.

Suspense의 동작 원리는 Promise의 상태와 밀접하게 관련되어 있으며, 이를 통해 비동기 데이터를 손쉽게 처리할 수 있다.

Pending 상태 (대기 중):

컴포넌트가 비동기 작업을 통해 데이터를 가져올 때, 해당 Promise는 처음에 pending 상태가 된다.
이 시점에서 Suspense는 로딩 상태를 감지하고, fallback으로 지정된 로딩 UI를 표시한다.
예를 들어, 네트워크 요청이 완료될 때까지 스피너(spinner)나 로딩 메시지가 표시될 수 있다.

Fulfilled 상태 (완료됨):

비동기 작업이 성공적으로 완료되면 Promise는 fulfilled 상태가 된다.
이 때 Suspense는 로딩 UI를 제거하고, 데이터를 성공적으로 가져온 컴포넌트를 화면에 렌더링한다.
예를 들어, 서버에서 데이터를 성공적으로 받아와 화면에 데이터를 표시한다.

Rejected 상태 (실패함):

비동기 작업이 실패하면 Promise는 rejected 상태가 된다.
이 경우, Suspense 자체는 실패 상태를 처리하지 않지만, 컴포넌트 내부에서 에러 경계(Error Boundary)를 사용하여 에러를 처리할 수 있다.
예를 들어, 네트워크 오류가 발생하였을 경우 에러 메시지를 표시한다.

Suspense 남용의 문제

아래 예시에서는 Before 컴포넌트를 Suspense가 감싸고 있다.
그리고 내부에서 2개의 Query를 요청하고 있다.



// App.jsx
function App() {
  return (
    <Suspense fallback={<div>...loading</div>}>
      <Before />
    </Suspense>
  );
}

// Before.jsx
const BASE_URL = "https://jsonplaceholder.typicode.com";
const client = axios.create({ baseURL: BASE_URL });

function Before() {
  const { data: todoList } = useQuery("todos", () => client.get("/todos"), {
    suspense: true, // ✨
  });

  const { data: postList } = useQuery("posts", () => client.get("/posts"), {
    suspense: true, // ✨
  });

  return (
    <div style={{ display: "flex" }}>
      <section>
        <h2>Todo List</h2>
        {todoList?.data.map(({ id, title }) => (
          <div key={id}>{title}</div>
        ))}
      </section>
      <section>
        <h2>Post List</h2>
        {postList?.data.map(({ id, title }) => (
          <div key={id}>{title}</div>
        ))}
      </section>
    </div>
  );
}

API 요청이 어떻게 가고 있는지 네트워크 탭을 살펴보면

network waterfall을 만들고 있다. 해당 문제점을 겪으면서 앱의 로딩 시간이 길어지게 되었다.

왜 이런 현상이 발생하였을까? 원인은 바로 Suspense의 잘못된 사용, 아니 잘 모르고 사용한 원인이 더 크다.

위에서 설명한 대로 Suspense는 Promise 상태에 따라서 children 또는 fallback 컴포넌트를 반환한다. 즉, pending 상태일 때에는 Loading을 반환하고 있고, children을 실행시키지 않는다.

그렇기 때문에, 하나의 API 요청이 발생하면 children 컴포넌트의 실행은 멈추고 fallback을 반환하게 된다. Promise가 fulfilled 상태가 되면 다시 children을 반환하여 children 컴포넌트를 렌더링한다.

이러한 이유 때문에 Suspense가 감싸고 있는 하나의 컴포넌트에서 2개 이상의 요청을 할 때 네트워크 병목 현상이 발생하게 된다.

해결 방법 1 - Component와 Suspense 1:1 대응

Suspense 내의 컴포넌트에서 두 개 이상의 요청이 발생하면 네트워크 water fall이 직렬로 처리되는 현상이 생긴다. 그렇다면 한 컴포넌트에 하나의 요청을 유지하면 해결된다.

✨ 두 개 요청 모두 useQuery, suspense: true 로 요청 시

아래 코드는 2개의 컴포넌트로 분리하고, 각각 Query 요청을 수행하고, 각각 Suspense로 감싸준 코드이다.



function AfterEachSuspense() {
  return (
    <div>
      <div style={{ display: "flex" }}>
        <section>
          <h2>Todo List</h2>
          <Suspense fallback={<div>...loading</div>}>
            <TodoList />
          </Suspense>
        </section>
        <section>
          <h2>Post List</h2>
          <Suspense fallback={<div>...loading</div>}>
            <PostList />
          </Suspense>
        </section>
      </div>
    </div>
  );
}

const TodoList = () => {
  const { data: todoList } = useQuery("todos", () => client.get("/todos"), {
    suspense: true, // ✨
  });

  return (
    <div>
      {todoList?.data.map(({ id, title }) => (
        <div key={id}>{title}</div>
      ))}
    </div>
  );
};

const PostList = () => {
  const { data: postList } = useQuery("posts", () => client.get("/posts"), {
    suspense: true, // ✨
  });

  return (
    <div>
      {postList?.data.map(({ id, title }) => (
        <div key={id}>{title}</div>
      ))}
    </div>
  );
};

네트워크 요청 결과는 다음과 같다.

병목 현상을 해결하고 정상적으로 병렬 처리되는 모습을 확인할 수 있다.

Suspense가 분리되었고, 각각의 Suspense가 각각의 children을 관장하므로 병렬적으로 실행되는 것이 당연한 결과다.

하지만 이 방식은 상황에 따라서 문제가 될 수 있다.

바로, 로딩 상태가 제각각 이라는 것이다.

위 네트워크 탭에서 todos와 posts 요청을 보면 끝나는 시간이 다르며, 각각의 Suspense 는 각각의 네트워크 요청이 끝나는 것을 감지하여 children을 렌더링 한다. 즉, 요청이 먼저 끝난 컴포넌트가 먼저 보여지게 된다.

TodoList가 먼저 렌더링 된다면 유저에게 버벅거리는 느김을 줄 수 있다는 점에서 유저 경험을 악화시킬 가능성도 있다. 이는 상황에 따라서 좋은 경험일 수 있고, 좋지 않은 경험일 수도 있다.

정리하자면, 컴포넌트를 분리한 후, 각각 Suspense를 감싸주는 것은 유저 경험을 악화시킬 가능성이 있다. 그렇다면 두 컴포넌트 모두 로딩이 끝나는 시점에 한번에 렌더링 하는 방법을 생각할 수 있겠다.

해결 방법 2 - Component와 Suspense n:1 대응

위와 같이 컴포넌트로 Query를 감싸여 요청을 분리하였지만, Suspense는 하나로 감싸고 있는 점이 다르다.



function AfterSameSuspense() {
  return (
    <div>
      <Suspense fallback={<div>...loading</div>}>
        <div style={{ display: "flex" }}>
          <section>
            <h2>Todo List</h2>
            <TodoList />
          </section>
          <section>
            <h2>Post List</h2>
            <PostList />
          </section>
        </div>
      </Suspense>
    </div>
  );
}

네트워크 요청 결과는 동일하게 병렬 처리되고 있으며, 임의의 API call이 먼저 끝나는 상황이다.

의도한 대로, 두 요청이 모두 끝날 때를 기다리고 렌더링이 수행된다.

이는 Suspense 내부 코드를 살펴봐야 정확히 알겠지만, Suspense 내부에서 API 요청이 발생한 소재를 파악하여, 그곳은 fallback으로 대체하고, 나머지 부분은 정상적으로 실행시키는 것을 알 수 있다.

해결 방법 3 - useQueries

여러 개의 query를 병렬로 실행시킬 수 있게 해주는 useQueries는 Suspense와 함께 사용 시 정상적으로 동작하지 않는 이슈가 있는데 v4.5.0 패치에 해당 사항이 수정되었다.



const results =   useQueries({queries: [
  {queryKey: ["posts"], queryFn: () => fetch("/posts") , suspense: true},
  {queryKey: ["comments"], queryFn: () => fetch("/comments"), suspense:true},
  {queryKey: ["issues"], queryFn: () => fetch("/issues"), suspense:true }
]})

useQueries를 사용하면 컴포넌트 내부 context를 이용해 병렬적으로 api를 호출할 수 있어서 context 사용을 위한 부가적인 구현을 하지 않아도 된다는 장점이 있다.

마치며

가독성과 클린 코드도 좋지만 무분별한 Suspense를 사용으로 로딩 성능을 저하 시키는 결과를 나을 수 있다. 그렇듯 Suspense의 장점만 인지하고 Suspense를 사용해서는 안 되며, 동작 원리와 적절한 poc를 통해 고민해 보아야 한다.

전역 상태 관리 Recoil과 Zustand

Heetae Kim — Wed, 19 Jun 2024 15:59:47 +0000

Recoil과 Zustand는 React 애플리케이션에서 상태 관리를 도와주는 라이브러리이다. 두 라이브러리 근본적인 기능은 같지만, 서로 다른 방식으로 상태 관리를 구현하여 사용된다.

Recoil

Recoil은 Facebook에서 개발한 상태 관리 라이브러리로, React와 긴밀하게 통합되어 있으며, 주로 atom과 selector를 사용한다. Recoil은 비동기 상태 관리와 Tree Shaking을 지원하며, 복잡한 상태 관리가 필요한 큰 규모의 애플리케이션에 적합하다.

Atom과 Selector:

Atom : 상태의 기본 단위 이다. 상태를 읽고 쓸 수 있다.
Selector : 파생된 상태를 생성하는 데 사용된다. 다른 atom 또는 selector의 값을 기반으로 새로운 값을 계산할 수 있다.

비동기 상태 관리:

Recoil은 비동기 상태 관리 기능을 내장하고 있어, 네트워크 요청과 같은 비동기 작업을 쉽게 처리할 수 있다.

Tree Shaking:

사용하지 않는 상태와 로직은 번들에서 제거되어 성능을 최적화할 수 있다.

// store.js
import { atom, selector } from 'recoil';

export const textState = atom({
  key: 'textState', // unique ID (with respect to other atoms/selectors)
  default: '', // 초기값 설정(default value)
});

export const charCountState = selector({
  key: 'charCountState', // unique ID
  get: ({ get }) => {
    const text = get(textState);
    return text.length;
  },
});

// App.js
import React from 'react';
import { RecoilRoot } from 'recoil';
import CharacterCounter from './CharacterCounter';

function App() {
  return (
    <RecoilRoot>
      <CharacterCounter />
    </RecoilRoot>
  );
}

export default App;

// CharacterCounter.js
import { useRecoilState, useRecoilValue } from 'recoil';
import { textState, charCountState } from '/store'

function CharacterCounter() {
  return (
    <div>
      <TextInput />
      <CharacterCount />
    </div>
  );
}

function TextInput() {
  const [text, setText] = useRecoilState(textState); // text 구독

  const onChange = (event) => {
    setText(event.target.value);
  };

  return (
    <div>
      <input type="text" value={text} onChange={onChange} />
      <br />
      Echo: {text}
    </div>
  );
}

function CharacterCount() {
  const count = useRecoilValue(charCountState); // count 구독

  return <>Character Count: {count}</>;
}

export default CharacterCounter;

Zustand

Zustand는 가볍고 사용하기 쉬운 상태 관리 라이브러리로, 단순한 상태 관리 패턴을 제공한다. 간단한 API로 작은 규모의 프로젝트에 적합하다.

초소형 및 간단한 API:

Zustand는 매우 간단한 API를 제공하며, 상태를 설정하고 구독하는 방식이 직관적이다.

미들웨어 지원:

상태 변경을 감지하고, 로깅, 비동기 작업 등을 처리할 수 있는 미들웨어를 지원한다.

React 훅 기반

훅을 사용하여 상태를 관리하며, recoil 처럼 별도의 Provider를 사용할 필요가 없다.

좋은 성능:

블필요한 리렌더링을 최소화하고, 작은 번들 크기로 성능을 최적화 할 수 있다.

// store.js
import create from 'zustand';

const useStore = create((set) => ({
  text: '',
  setText: (text) => set({ text }),
  charCount: () => get().text.length,
}));

// App.js
import CharacterCounter from './CharacterCounter';

function App() {
  return (
    <div>
      <CharacterCounter />
    </div>
  );
}

export default App;

// CharacterCounter.js
import { useStore } from './store';

function CharacterCounter() {
  return (
    <div>
      <TextInput />
      <CharacterCount />
    </div>
  );
}

function TextInput() {
  const { text, setText } = useStore((state) => state); // text 구독

  const onChange = (event) => {
    setText(event.target.value);
  };

  return (
    <div>
      <input type="text" value={text} onChange={onChange} />
      <br />
      Echo: {text}
    </div>
  );
}

function CharacterCount() {
  const charCount = useStore((state) => state.charCount); // charCount 구독

  return <>Character Count: {charCount}</>;
}

export default CharacterCounter;

💡

Zustand 내부에 store를 만드는 코드를 보자면, setState가 partial과 replace로 나눠져 있는데, partial은 state의 일부분만 변경하고 싶을 때 사용하고, replace는 state를 완전히 새로운 값으로 변경하고 싶을 때 사용한다.

subscirbe 함수는 listener를 등록하는데, listener는 마찬가지로 Set 형태로 선언되어 추가와 삭제, 그리고 중복 관리가 용이하게끔 설계되어 있다. 즉, 상태값이 변경될 때 리렌더링이 필요한 컴포넌트에 전파될 목적으로 만들어 진 것이다.

destroy는 listener를 초기화하는 역할을 한다.

createStore는 이러한 getState, setState, subscribe, destory를 반환한다.

비교

복잡성:

Recoil은 Atom과 Selector 등 더 많은 개념이 필요하여 복잡하지만, 복잡한 상태 관리에 유리하다. 반면 Zustand는 단순한 API로 직관적이며, 작은 프로젝트에 적합하다.

비동기 상태 관리:

Recoil은 비동기 상태 관리를 기본적으로 지원한다. Zustand 역시 비동기 작업을 처리할 수 있지만, Recoil 만큼의 기본 지원은 없다.

퍼포먼스:

Recoil의 경우 Tree Shaking과 최적화된 상태 관리로 큰 애플리케이션에서도 좋은 성능을 보인다. 반면 Zustand는 매우 가벼운 라이브러리로 불필요한 리렌더링을 최소화하여 성능을 최적화 한다.
Recoil은 라이브러리 업데이트 주기가 오래 되어 안정성이 낮으며, Zustand는 최근에 나왔지만 최신 업데이트로 안정성이 개선되고 있다.

마무리

Recoil과 Zustand는 각각의 장단점이 있으며, 프로젝트의 요구 사항에 따라 적절한 라이브러리를 선택하여 사용하면 된다.

항해99 취업 리부트 코스 회고

Heetae Kim — Wed, 12 Jun 2024 08:34:26 +0000

코스 이전 백그라운드

필자는 코스를 선택하기 이전에 금융 SI 개발자였다.

그리고 서비스 개발자 즉, 프론트엔드 개발자로 커리어 다시 시작하기 위해 개인 프로젝트 서비스를 만들고 알고리즘 문제도 풀면서 코딩테스트 준비도 하였다.

많은 준비에도 매번 항상 서류 탈락을 면치 못하였다.

오랜 탈락을 겪고 나니 높은 자존감도, 긍정적인 성격도 점점 낮아지는 내리막길로 접어들기 시작했다.

코스 이전 고민

부트캠프나 국비지원, 독학 등 개발자가 되기 위한 또는 시작하기 위한 방법들은 다양하다.

수많은 기관과 각 종 채용 연계 프로그램을 통해 개발자가 넘쳐나기 시작하였다. 연달아 코로나가 터지고 비대면이 증가하면서 개발자에 대한 수요는 기하급수적으로 올라갔다. 말 그대로 개발자 호황기다.

그러다 2022년 이후 개발자 시장은 완전히 바뀌었다.

이전 개발자 붐으로 인해 수 많은 개발자들이 시장에 넘쳐 나고, 금리 상승 및 스타트업 투자 급감 등으로 인해 개발자 채용 시장은 인력 감축하고 생존 모드에 들어섰다.

이후 많은 신입 개발자들은 높은 채용 요구사항과 더불어 3년 이상 경력자들과 경쟁하여 채용 바늘 구멍을 통과해야 하는 현실로 바뀌었다.

그런 현실을 반영하여 경쟁에서 뒤쳐지지 않기 위해 필자는 항해99 취업 리부트 코스를 지원하였다.

코스 선택 이유

결론부터 말하자면 취업 지원에 진심이다.

그리고 현재 시장을 누구보다 잘 알고 도움을 주기 때문에 지원하게 되었다.

더군다나, 다른 개발자 분들과 네트워킹을 통한 환경이 구축되어 있기 때문에 많은 도움을 받고 의지할 수 있기 때문이기도 하다.

정리하자면 장점은 다음과 같다.

취업 지원을 아낌없이 해준다.

온라인으로 진행되어도 네트워킹 참여도가 활발하다.

이력서, 코딩테스트, 프로젝트, 면접 등 취업 전반에 필요한 항목을 점검하고 보완할 수 있다.

수료 이후에도 이력서 및 면접 코칭이 가능하다.

멘토링 시스템을 통해 원하는 질문에 대한 답변을 얻을 수 있다.

발등에 불 떨어질 일은 없다.

이 중에서 현재 불안한 시장에서 부족한 이력서와 면접 실력을 지속적으로 피드백 해주고 지속적으로 고쳐나갈 수 있다는 장점이 이 취업 리부트 코스만의 가장 큰 장점이라 생각한다.

코스 이후

필자가 가장 만족하는 부분은 이력서와 코테 부분이다.

이력서 작성방법, 코딩테스트 대비 방법 등 무엇이든 방법을 알고 그 방법을 잘 적용하여 내 것으로 만든다면 많은 시간과 노력 대비 효과적인 결과를 만들어 낼 수 있는 것 같다.

현재 이력서와 이전 이력서를 비교하면 어떻게 이전 이력서를 가지고 취업지원을 하였는지 부끄럽다.

코딩테스트 역시 방법을 알고 시작하니 앞으로 어떻게 코테에 대비해야 하는지, 부족한 부분은 어떻게 매꿀 수 있는지 방향성을 알게 되었다.

면접 실력 향상에는 왕도가 없다. 꾸준히 지원하고 실전 경험을 쌓는 것이 중요하다고 생각한다. 그리고 지속적인 지원을 받을 수 있어서 면접에 대한 부담을 조금은 덜게 되었다.

필자는 항해에서 코딩테스트 문제를 풀고 백준 플래티넘을 달성하였다.

마지막 한마디

무엇이든지 시작하고 있다면 좋은 징조라 생각한다.

아무것도 하지 않는 것 보다 지금 내게 가장 필요한 것을 찾고 그것을 바로 시작하면 된다.

필자 역시 이 코스를 수료하고 나서 앞으로 필요한 것들이 많이 생겨났다.

오픈소스 기여하기

코딩테스트 필수 유형 정복하기

맛집 블로그 키우기

개발자 커뮤니티 활성화하기

좋은 프로젝트 코드(가독성, 추상화 등)에 대한 POC

사용자 100명 이상 운영되는 서비스 배포해보기

이전과 비교하여 취업 시장에서 유리해진 점은 확실하다.

모든지 자기 하기 나름이다.

항해에서 만난 팀원분들과 유의미한 시간을 보내게 된 것에 감사하다.

팀원들 덕분에 수여받은 상 1 : 이미지 보기

팀원들 덕분에 수여받은 상 2 : 이미지 보기

팀원 맛집 블로그 : 구경가기

12조 분들과 게더에서 찰쿠닥📸
(한분은 프랑스 가셔서 같이 참여 못함)

✨이벤트✨
취업 리부트 코스 지원서를 작성할 때 [할인]란에 취리코 2기 김희태를 입력하면
10만 원을 할인해 주신다고 하니 꼭 저를 이용하셔서 혜택 누리시길 바랍니다.

Toss의 퍼널(Funnel) 패턴 적용해보기

Heetae Kim — Wed, 05 Jun 2024 15:01:09 +0000

"토스 SLASH 23의 퍼널: 쏟아지는 페이지 관리하기" 를 참고하여 작성되었습니다.

링크

토스에서는 다른 통신사들 처럼 요금제 가입 신청서를 받고있다.
차별화된 점은 한 페이지로 이루어진 폼 대신, 한 페이지에 한 항목만 제출하는 UI를 가지고 있다.

하지만 이런식으로 많은 페이지들을 한 번에 관리하기란 쉽지 않다.
위 발표에서는 이러한 페이지들을 효과적으로 관리하는 방법에 대해서 설명하고 있다.

퍼널(Funnel)

퍼널의 사전적인 뜻인 깔대기 와 같은 모양을 띠기 때문에 붙여진 이름이라고 한다.
이러한 깔대기 모양인 퍼널을 토스의 회원가입 절차에 적용되어 있다고 한다.

그렇다면 어떻게 플로우를 관리할지 궁금한데, 토스에서는 두 가지 예시를 들어주었다.

기존 퍼널 방식

완료 버튼을 이용해 router를 이동하면서 페이지마다 수집하는 유저의 정보를 전역상태에 저장하며 마지막 페이지에서 api를 호출하는 정석적인 구현방법

토스 퍼널 방식

useState를 활용하여 유저 정보 및 page step을 지역상태로 만들어주고, 가입방식, 주민번호, 집주소 등 현재 어느 UI를 보여줘야하는지 페이지를 조건부 처리하여 step에 따라 원하는 UI로 업데이트 시켜주며 마지막 step에서 api를 호출하는 방법



const [registerData, setRegisterData] = useState()
const [step, setStep] = useState<"가입방식"|"주민번호"|"집주소"|"가입성공">("가입방식")

return (
  <main>
    {step === "가입방식" && <가입방식 onNext={(data) => setStep("주민번호")} />} 
    {step === "주민번호" && <주민번호 onNext={() => setStep("집주소")} />} 
    {step === "집주소" && <집주소 onNext={async () => setStep("가입성공")} />} 
    {step === "가입성공" && <가입성공Step />}
  </main>
)

기존 퍼널의 아쉬운 점 및 보완

기존 퍼널 방식도 완벽해 보이지만 몇 가지 아쉬운점이 있다.

페이지 흐름이 흩어져있다.
가입 플로우를 파악하기 위해서는 3개의 컴포넌트 파일을 넘나들어야 한다.
한 가지 목적을 위한 상태가 흩어져 있다.
상태를 수집하는 곳과 사용하는 곳이 달라서, api에 기능을 추가하거나 버그를 수정할 때 전체 페이지를 넘나들며 데이터 흐름을 파악해야 한다.

이를 보완하는 방법이 토스 퍼널 방식에서 확인할 수 있다.

그 방법으로는 퍼널의 응집도를 높이고 추상화를 통해 라이브러리화를 수행한다.
이 두 가지 키워드를 가지고 기존 방식의 단점을 보완한다.

응집도 높이기



const [registerData, setRegisterData] = useState()
const [step, setStep] = useState<"가입방식"|"주민번호"|"집주소"|"가입성공">("가입방식")

return (
  <main>
    {step === "가입방식" && <가입방식 onNext={(data) => {
      setRegisterData(prev => ({ ...prev, 가입방식: data })) // 이하 동일
      setStep("주민번호")
    }} />} 
    {step === "주민번호" && <주민번호 onNext={() => setStep("집주소")} />} 
    {step === "집주소" && <집주소 onNext={async () => {
      await fetch("/api/register", { data }) // API 호출 장소 변경
      setStep("가입성공")
    }} />} 
    {step === "가입성공" && <가입성공Step />}
  </main>
)

useState를 이용해 지역상태를 만들어주고 가입방식, 주민번호 등 현재 어느 UI를 보여줘야 하는지 state에 저장한다.
그러면 하나의 컴포넌트 페이지에서 흩어져있는 페이지들을 한 페이지에 응집시켜 관리가 용이하게 만들어 줄 수 있다.
그리고 step 상태에 따라 각 UI 컴포넌트를 조건부 렌더링하고, '다음' 버튼을 누를 때 step 상태를 원하는 UI로 업데이트 한다.
결과적으로 step의 이동을 상위 컴포넌트에서 관리하여 UI 흐름을 한 곳에서 관리할 수 있게 되었다.

마지막으로 API 호출에 필요한 상태도 상위에서 한 번에 관리하면 어떤 상태가 어떤 UI에서 수집되고 있는지 한 눈에 볼 수 있으며, 이제 더 이상 파일을 넘나들면서 전역 상태를 관리하지 않아도 된다.

추상화로 재사용성 높이기



const [registerData, setRegisterData] = useState()
const [step, setStep] = useState<"가입방식"|"주민번호"|"집주소"|"가입성공">("가입방식")

return (
  <main>
    <Step if={step === "가입방식"}>
      <가입방식 onNext={() => setStep("주민번호")} />
    </Step>
    <Step if={step === "주민번호"}>
      <주민번호 onNext={() => setStep("집주소")} />
    </Step>
  // ...
  </main>
)

각 step을 컴포넌트로 따로 만들어 주어 중복된 step 처리를 추상화 해준다.

그리고 props를 조금 더 깔끔하게 작성해 줄 수 있을 것 같다.



const [registerData, setRegisterData] = useState()
const [step, setStep] = useState<"가입방식"|"주민번호"|"집주소"|"가입성공">("가입방식")

return (
  <main>
    <Step name="가입방식">
      <가입방식 onNext={() => setStep("주민번호")} />
    </Step>
    <Step name="주민번호">
      <주민번호 onNext={() => setStep("집주소")} />
    </Step>
   // ...
  </main>
)

예제 코드를 보면 조건문을 삭제하고 name만 props로 남겼으며, 컴포넌트가 깔끔해진 것을 볼 수 있다.

만들고보니 Step 컴포넌트가 현재 퍼널의 step을 알고 있어야 하므로, 이를 위해 퍼널에서 직접 관리하고 있던 step 상태도 내부 로직으로 옮겨주기 위해 상태를 담은 함수인 커스텀 훅을 만들어 Step 컴포넌트와 상태를 같이 관리할 수 있게 코드를 짜줍니다. (useFunnel 커스텀 훅 생성)



function useFunnel() {
  const [step, setStep] = useState()

  const Step = (props) => {
    return <>{props.children}</>
  }

  const Funnel = ({ children }) => {
    // name이 현재 step 상태와 동일한 Step만 렌더링
    const targetStep = children.find(childStep => childStep.props.name === step);
    return Object.assign(targetStep, { Step })
  }

  return [Funnel, setStep]
}



const [registerData, setRegisterData] = useState()
const [step, setStep] = useFunnel<"가입방식"|"주민번호"|"집주소"|"가입성공">("가입방식")

return (
  <Funnel>
    <Funnel.Step name="가입방식">
      <가입방식 onNext={() => setStep("주민번호")} />
    </Funnel.Step>
    <Funnel.Step name="주민번호">
      <주민번호 onNext={() => setStep("집주소")} />
    </Funnel.Step>
    // ...
  </Funnel>
)

여기까지 퍼널의 응집도와 추상화를 거쳐서 보다 가독성있고 재사용성이 높은 퍼널을 완성하였다.

퍼널은 완성하였지만 한 가지 불편한 점이 존재하는데, 현재 코드는 단일 URL이라 step 사이에 뒤로가기, 앞으로가기 지원이 안 되는 불편함이 존재한다.
이를 router의 shallow push API를 사용해 쿼리파라미터를 업데이트해줘서 가능하도록 구현할 수도 있다.

내 코드에 적용하기

커머스 플랫폼을 사용하면 주문 결제 과정을 반드시 거치게 된다.

필자는 커머스 플랫폼 프로젝트에서 토스의 퍼널 패턴을 적용해 결제 과정 즉, 결제 퍼널을 적용하였다.

장바구니에 담겨진 상품을 주문하면 배송지 주소 > 주문 목록, 결제 완료 의 3단계를 거치게 된다.

간단하고 심플한 결제 과정인데 굳이 퍼널 패턴을 적용한 이유는 코드 리펙토링을 수행하면서 유연한 유지보수가 가능하도록 하기 위해 퍼널을 적용하였다.

처음으로 결제 프로세스를 구현해 보았기 때문에 언제든지 결제 프로세스는 변경될 수 있으며, 또한 언제든지 유연하게 코드 수정 및 스타일 수정이 가능하도록 하기 위해 퍼널 패턴을 프로젝트에 적용해 보았다.

useFunnel



import { ReactElement, ReactNode, useState } from 'react';

export interface StepProps {
  name: string;
  children: ReactNode;
}

export interface FunnelProps {
  children: Array<ReactElement<StepProps>>;
}

export const useFunnel = (defaultStep: string) => {
  const [step, setStep] = useState(defaultStep);

  // Step
  const Step = (props: StepProps): ReactElement => {
    return <>{props.children}</>;
  };

  // Funnel
  const Funnel = ({ children }: FunnelProps) => {
    const targetStep = children.find((childStep) => childStep.props.name === step);

    return <>{targetStep}</>;
  };

  const nextClickHandler = (nextStep: string) => {
    setStep(nextStep);
  }

  const prevClickHandler = (prevStep: string) => {
    setStep(prevStep);
  }

  return {
    Funnel,
    Step,
    currentStep: step,
    nextClickHandler,
    prevClickHandler
  } as const;
};



const { Funnel, Step, nextClickHandler, prevClickHandler, currentStep } = useFunnel(steps[0].name);

부모 컴퍼넌트에서 useFunnel을 선언해 주어 자식 컴포넌트 props로 값을 전달하여 모든 상태 관리 및 함수는 최상위 부모 컴포넌트에서 관리해 주도록 하였다.

바로 아래 자식 컴포넌트 코드가 퍼널을 적용한 컴포넌트 코드이다.

Funnel 적용



export const OrderSetup = (
  { 
    steps, 
    Funnel, 
    Step, 
    nextClickHandler, 
    prevClickHandler, 
    order, 
    onSetOrder 
  }: OrderSetupProps) => {

  return (
    <>
      <Funnel>
        <Step name="배송지입력">
          <OrderAddress
            onNext={() => nextClickHandler(steps[1].name)}
            onSetOrder={onSetOrder}
            order={order}
          />
        </Step>

        <Step name="주문목록확인">
          <OrderList
            onPrev={() => prevClickHandler(steps[0].name)}
            onNext={() => nextClickHandler(steps[2].name)}
            order={order}
          />
        </Step>

        <Step name="결제완료">
          <OrderResult />
        </Step>
      </Funnel>
    </>
  )
}

마치며

토스의 코드를 흉내내어 퍼널의 개념을 적용해 보았지만, 커스텀 훅과 합성 컴포넌트를 구현하면서 추상화에 대한 고민도 한층 늘었다.

또한 결제 프로세스의 추상화 및 응집도에 대한 POC 과정도 이번 토스 퍼널 패턴을 통해 큰 도움이 되었다.

끝으로 진유림님과의 프라이빗 네크워킹을 신청해 보았는데, 기회가 된다면 꼭 한번 만나 뵙고 싶다. 링크

감사합니다.

React, Click outside area of element.

Heetae Kim — Mon, 27 May 2024 11:12:59 +0000

이러한 메뉴 혹은 모달, 그리고 커스텀 셀렉트박스를 만들 때 외부 영역을 클릭하면 닫히게 만들고 싶은 경우가 있다. 프로젝트를 수행하면서 이를 구현한 방법을 두 가지로 나누어 구현하였다.

useState와 Overlay를 활용한 방법

메뉴나 모달이 렌더링 되는 상태를 관리하는 useState와 outside를 담당하는 Overlay 컴포넌트가 함께 렌더링 된다. 여기서 Overlay 컴포넌트 클릭 시 메뉴마 모달 컴포넌트가 언마운트 된다.

import { useState } from "react";

const SelectComponent = () => {
  const [isDropMenuOpen, setDropMenuOpen] = useState(false);

  const toggleDropMenu = (e: React.MouseEvent<HTMLLIElement>) => {
    setDropMenuOpen((prevState) => !prevState);
  };

  return (
    <ModalWrapper>
      <ModalBtn type="button" onClick={toggleDropMenu}>
        Show Menu
      </ModalBtn>

      {isDropMenuOpen && (
        <>
          <Modal className="modal">
            {/* ...Modal Content */}
          </Modal>
          <Overlay onClick={() => setDropMenuOpen(false)} />
        </>
      )}
    </ModalWrapper>
  );
};

export default SelectComponent;

구현 방법은 간단하다. toggleDropMenu 함수를 통해 모달 view 여부를 토글해 주는 함수를 만들고, 버튼에는 onClick 이벤트를 적용해주고, Overlay 컴포넌트에는 setState를 false로 함수를 선언해 주면 된다.

예제 코드는 아래 CodeSandBox 사이트를 통해 테스트를 진행할 수 있다.

예제코드보기

useRef와 WebAPI를 활용한 방법

모달의 객체를 메모이제이션 하는 useRef hook과, 클릭 된 이벤트 target element가 ref의 자식 요소에 포함되어 있는지 판별을 통해 outside 클릭 시 메뉴나 모달 컴포넌트가 언마운트 된다.

import { useState, useEffect, useRef } from "react";

const SelectComponent = () => {
  const [isDropMenuOpen, setDropMenuOpen] = useState(false);
  const modalRef = useRef<HTMLElement>(null);
  const btnRef = useRef<HTMLElement>(null);

  const toggleDropMenu = (e: React.MouseEvent<HTMLLIElement>) => {
    setDropMenuOpen((prevState) => !prevState);
  };

  useEffect(() => {
    const eventCallback = (e: MouseEvent): void => {
      if (modalRef.current && !modalRef.current.contains(e.target as Node)) {
        if (btnRef.current.contains(e.target as Node)) return;
        setDropMenuOpen(false);
      }
    };

    document.addEventListener("mousedown", eventCallback);
    return () => document.removeEventListener("mousedown", eventCallback);
  }, []);

  return (
    <ModalWrapper>
      <ModalBtn ref={btnRef} type="button" onClick={toggleDropMenu}>
        Show Menu
      </ModalBtn>
      {isDropMenuOpen && (
        <>
          <S.Modal ref={modalRef} className="modal">
            {/* ...Modal Content */}
          </S.Modal>
        </>
      )}
    </ModalWrapper>
  );
};

export default SelectComponent;

구현 방법은 Web API의 인스턴스 메소드은 contains를 활용한 것이 전부라고 해도 될 정도로 간단하다. useEffect 안에 선언된 contains 메소드가 클릭 이벤트를 통해 메뉴 및 모달이 포함된 element라면 return을, 아니라면 메뉴 및 모달 컴포넌트를 언마운트 한다.

contains(otherNode)

Node 인터페이스의 contains() 메소드는 노드가 주어진 노드의 자손인지, 즉 노드 자체인지, 직계 자식(childNodes) 중 하나인지, 자식의 직계 자식 중 하나인지 등을 나타내는 Boolean 값을 반환합니다.

예제 코드는 아래 CodeSandBox 사이트를 통해 테스트를 진행할 수 있다.

예제코드보기

두 방식의 차이점

EventListener는 등록된 이벤트에 맞는 동작이 일어나도록 듣고(감시하고) 있기 때문에 removeEventListener를 적절하게 해주지 않으면 메모리 누수의 원인이 된다.

그러나 useState를 이용한 방법은 부모 태그와 자식 태그의 위치를 이용한 방법이기 때문에 때때로 사용하기 어려운 환경일 수 있다. 그러므로 상황에 따라 적절한 방법을 선택하여 사용하는 것이 중요하다고 할 수 있다.

Lighthouse를 활용하여 LCP 점수 개선하기.

Heetae Kim — Thu, 23 May 2024 12:24:19 +0000

필자의 Lighthouse Performance 점수는 이렇다.

me: 🤦‍♂️

개선해야 할 항목들은 다음과 같다.

Lighthouse 점수가 웹 성능에 절대적인 성능으로 귀결되지는 않는다. 그렇지만 개발 이후 성능 최적화에 좋은 지표가 되므로 가장 중요한 LCP 점수를 높여 보려고 한다.

LCP(Largest Contentful Paint)

최대 콘텐츠 렌더링 시간 즉, 뷰포트에서 가장 큰 콘텐츠 엘리먼트가 나타날 때 측정한다.

페이지의 주요 내용이 화면에 렌더링이 완료되는 시기를 결정하는데 사용된다.

이미지 최적화

Largest Contentful Paint element - 12,350ms

현재 콘텐츠에 이미지를 포함하고 있으며, 이미지는 LCP에 큰 영향을 미칠 수 있기 때문에 이미지를 최적화하고 적절한 포맷을 사용하는 것이 중요하다고 한다.

적절한 포맷 사용

JPEG, PNG 대신 WebP 로 최신 포맷을 사용하여 개선 시도.

이미지 크기 최적화

불필요하게 큰 이미지를 줄이고 필요한 크기만 사용.
이미지 가로 크기를 1200px -> 400px 로 수정 (비율 유지)

지연 로드

화면에 보이지 않는 이미지들은 lazy-loading 하여 불필요한 렌더링이 발생하지 않도록 시도. ```html


**결과**
- Before
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n7svr849j8j9kzeurn0p.png)

- After
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yeepe9p8ydx79g2ic994.png)

Load Delay는 `9,507ms` -> `6,060ms` 으로 약 `37%` 개선되었으며, 
Load Time도  `3,740ms` -> `2,380ms` 으로 약 `37%` 개선되었다.

&nbsp;

## 폰트 최적화

**Enable text compression - Potential savings of 9,691 KiB**

다음으로는 웹 폰트 로딩이 페이지 렌더링을 차단하지 않도록 최적화를 수행하였다.

`font-display: swap` 속성을 사용하여 폰트 로딩 중에도 텍스트가 표시되도록 하였다.
```css


@font-face {
    font-family: "Noto Sans KR", sans-serif;
    src: url(https://fonts.googleapis.com/css2?family=Noto+Sans+KR:wght@300..600) format("woff2");
    font-display: swap;
  }

swap은 웹폰트가 로드되기 전에 사용자에게 기본 시스템 폰트로 텍스트를 표시합니다. 그리고 웹폰트 로딩이 완료되면 텍스트가 웹폰트로 교체된다. 이 방식은 사용자 경험을 향상시키는 데 일반적으로 사용되는 값이라고 한다.

JavaScript 최적화

Minify JavaScript - Potential savings of 2,832 KiB

JavaScript 파일이 크거나 로딩이 차단되면 LCP에 악영향을 미칠 수 있다고 한다.
그래서 찾은 개선 방법으로 코드 분할(Code Spliting)과 지연 로딩(Lazy-Loading)이 있다고 한다.

코드 분할 및 지연 로드

필자는 이미 이전에 현재 사용자가 보는 페이지에 따라 필요한 JavaScript 파일을 다운로드 받도록 하기 위해 React의 lazy함수를 통해 지연 코드 분할을 수행하였다. ```tsx

lazy(() => import('some-large-module').then(module => {
// Use the module
}));


### 사용하지 않는 모듈 제거
추가적으로 수행한 최적화 방법으로 사용하지 않는 JS 및 모듈 파일들을 제거하거나 최소화 하였다. 이유는 필요 없는 파일들을 다운 받는 과정에서 필수적인 다운로드가 blocking 으로 지연되면 LCP 역시 저하될 수 있기 때문이다.

무거운 라이브러리를 Spread로 import 하지 않고 필요한 모듈만 import 하여 가져와 사용하도록 수정하였다. -> [블로그 글 참고](https://dev.to/hxxtae/lighthousereul-hwalyonghan-tree-shaking-8ie)

&nbsp;

## Vite 설정 파일 수정

이전 까지의 최적화를 수행하여도 LCP의 점수에는 큰 영향이 없었다. 그래서 ChatGPT한테 추가적인 방법을 물어보았더니 다음과 같은 방법을 제시해 주었다.

> `vite-plugin-compression`을 사용하여 Vite 설정을 통해 빌드된 파일을 미리 압축하는 방법으로 LCP를 단축 시킬 수 있다. 
> 이는 빌드된 파일을 `Gzip` 및 `Brotli` 형식으로 미리 압축하여 서버가 이를 효율적으로 제공할 수 있도록 한다.

### vite-plugin-compression 설치
```bash


npm install vite-plugin-compression --save-dev

Vite 설정 파일 수정 (vite.config.js)



// vite.config.js
import compression from 'vite-plugin-compression';

export default defineConfig({
  plugins: [
    react(),
    compression({ algorithm: 'gzip' }), // Gzip 압축 활성화
    compression({ algorithm: 'brotliCompress', ext: '.br' }) // Brotli 압축 활성화
  ]
});

위 설정을 저장한 후 프로젝트를 빌드하면 Gzip 및 Brotli 형식으로 압축된다.

최종결과

결과는 드라마틱 하지 않았지만 전반적으로 개선된 것을 확인할 수 있다.

FCP : 6.8s -> 5.1s
LCP : 12.4s -> 8.7s
TBT : 30ms -> 0ms
CLS : 0.001
SI : 7.5s -> 5.5s

그럼 왜 점수가 많이 오르지 않을까? 이 사실을 같은 항해99 멤버인 원민님에게 답을 얻을 수 있었다.

일반적으로 개발 환경에서는 디버깅을 쉽게 할 수 있도록 여러가지 추가적인 리소스를 요청하는데 이것이 Lighthouse 점수에 계산되기 때문이다.

여기에서 말하는 리소스라는 것은 개발 과정에서 발생한 오류를 추적할 수 있는 로그 같은 로직적인 부분일 수 있고, 디버깅 시 정확한 코드 위치를 판단할 수 있는 소스맵 같은 파일일 수도 있다.

그래서 프로덕션 빌드 시 이와 같은 파일들은 사용자에게 제공할 필요가 없고 성능 최적화를 위해 리소스들이 모두 빠지게 되므로 프로덕션 환경에서는 개발 환경 보다 성능 상 이점을 누릴 수 있을 것이며 Lighthouse Performance 점수 또한 높을 것이다.

Lighthouse 점수를 개선해야 한다면, 최종 사용자 입장에서 볼 수 있는 프로덕션 환경에서 개선하는 것이 더 적절하다고 할 수 있다.

마무리

LCP를 개선하는 과정을 통해서 얻은 내용을 정리하면 이렇다.

Lighthouse 실행 시점 마다 점수의 격차가 크다.
최적화된 이미지를 저장하고, 불러오고, 보여주는 것이 LCP에 영향이 크다.
vite.config.js 에서 크기가 큰 모듈들을 코드 분할하여 불필요한 JS를 제거해 주는 것으로도 LCP 향상에 도움이 된다.
Lighthouse 측정은 프로덕션 환경에서 진행하는 것을 권장한다.
LCP는 데이터가 불러오는 속도에 영향을 많이 받기 때문에 SSR 방식도 고려하면 좋을 것 같다.

앞서 말했던 것 처럼 LCP 점수가 절대적이거나 중요한 것은 아니다. 하지만 높은 점수는 사용자에게 좋은 경험을 제공하는 것은 분명하다.

그리고 LCP 시간은 2.5s 이하면 좋다고 한다. 앞으로 최적화를 진행할 때 기준을 두고 진행하면 좋을 것 같다.

긴 글 읽어주셔서 감사합니다.

[참고한 글]
Lighthouse를 기반으로 LCP 성능 개선하기
Light House에서 LCP 측정항목 개선해서 성능점수 올리기
라이트하우스와 함께한 성능 개선 고군분투기
내가 프로젝트에서 최적화를 진행했던 방법들 (With React+Vite)

Named export를 동적 import() 호출하기

Heetae Kim — Wed, 22 May 2024 02:30:02 +0000

필자는 프로젝트를 진행하면서 page 컴포넌트를 default export 방식으로 컴포넌트를 내보내어 코드를 작성하였다.

// Component default export
function MyPage () => { ... }
export default MyPage;

// Component import
import MyPage from './pages/MyPage';

페이지 컴포넌트에 default export로 굳어진 습관도 무시할 수 없지만, 페이지는 단 한개의 페이지 컴포넌트 뷰의 기능을 담당해야 하기 때문에 default로 작성하였다.

그러나 default export 의 단점으로 import 하는 과정에서 휴먼 에러가 발생할 수 있다는 단점과 import 코드 라인이 늘어나는 단점이 존재하기 때문에 이번에는 named export를 통해 컴포넌트를 export 하였다.

// Component named export
export const MyPage= () => { ... }

// Component import
import { MyPage } from './pages';

named export로 변경 후 import 하는 과정에서 자동으로 컴포넌트 name을 선언해 주며, 여러 export된 컴포넌트 및 함수를 name으로 import 할 수 있는 장점이 생겼다.

React.lazy로 import

각 페이지 컴포넌트를 최적화 하기 위해 React.lazy 를 사용하여 동적으로 컴포넌트를 import 하였다.

React v16.6.0의 외부 라이브러리 없이 코드 로드(load)를 연기할 수 있는 React.lazy를 도입하였다.
react.dev-lazy

즉, React.lazy 함수는 동적 import를 통해 컴포넌트를 지연 로드하여 렌더링할 수 있게 해준다.

Before:

import { MyPage } from './pages';

function AppComponent() {
  return (
    <div>
      <MyPage />
    </div>
  )
}

After:

const MyPage = React.lazy(() => import('./pages/MyPage'));

function AppComponent() {
  return (
    <div>
      <MyPage />
    </div>
  )
}

그리고 바로 다음에서 문제가 발생, 아래에 다음과 같은 메시지가 있다.

React.lazy takes a function that must call a dynamic import(). 
This must return a Promise which resolves to a module with a default export containing a React component.

번역하면 이렇다.

React.lazy는 동적 import()를 호출하는 함수를 받습니다. 이 함수는 React 컴포넌트를 포함하는 default export 모듈로 해석되는 Promise를 반환해야 합니다.

그래서 아래와 같이 변경하라고 한다.

function MyPage () => { ... }
export default MyPage;

해결방법

하지만 default export로 export 하지 않는다면 어떻게 해야 할까 고민 중에 ChatGPT를 통해 그 답을 얻을 수 있었으며 이 경우, 컴포넌트를 가져올 때 import() 코드를 약간 변경해야 한다.

const MyPage = React.lazy(
  () => import('./pages/MyPage/index.tsx').then((module) => ({ default: module.MyPage }))
);

필자는 MyPage라는 폴더를 두고 그 안에 index.tsx 파일로 컴포넌트를 생성해 주었다. 그리고 중요한 점은 확장자 명을 반드시 붙여 주어야 한다.

정리하자면 import()가 반환하는 Promise에 체이닝을 추가하여 default export를 추가하는 작업을 하고 있는 것이다.

이렇게 React.lazy로 가져온 named export된 컴포넌트의 경우 위와 같은 형식으로 lazy 함수를 작성해 주어야 한다.

그리고 기억해야 할 것으로 React.lazy로 가져온 컴포넌트는 반드시 React.Suspense 안에서 렌더링 되어야 한다는 점을 기억해야 한다.

최종적으로 변경된 전체 코드는 아래와 같다.

const MyPage = React.lazy(
  () => import('./pages/MyPage/index.tsx').then((module) => ({ default: module.MyPage }))

function AppComponent() {
  return (
    <div>
      <Suspense fallback="loading..." />
        <MyPage />
      <Suspense/>
    </div>
  )
}

Lighthouse를 활용한 Tree Shaking(with Build)

Heetae Kim — Tue, 21 May 2024 12:47:17 +0000

프로젝트를 마치고 Build를 진행하고 나서 다음과 같은 결과가 나왔다.

흠... 좋은데? 🤦‍♂️

빌드된 파일도 크고 빌드 시간도 길다. 이를 해결하는 과정을 진행해 보자.

마침 Lighthouse를 통해 LCP 시간을 줄이고 있는데 Treemap을 활용해서 Tree Shaking을 진행해보고 싶었다.

Lighthouse 탭에서 스크롤을 내리다 보면 View Treemap 버튼이 있다.

아래 사진을 보면 빌드된 각 파일의 크기를 알 수 있다.

@mui/icons-material
@mui-material
firebase/firestore
devs/chunk
react-dom
...

라이브러리 경량화1 (MUI)

필자는 프로젝트에 mui 를 사용하였다. 그런데 거의 대부분 컴포넌트 및 파일에서 모듈 전체 멤버를 import하여 필요한 컴포넌트를 불러와 사용하였다.

당시에는 몰랐지만 import { AbcRounded } from '@mui/icons-material' 처럼 가져오게되면, @mui/icons-material에서 내보내고있는 모든 모듈이 번들 사이즈에 포함된다.

필요한 모듈만 사용하기 위해 @mui/icons-material 와 @mui-material 라이브러리를 default export로 정의된 경로만 import하는 방식으로 변경해 주고 다시 Treemap 확인!

아래 이미지는 @mui/icons-material 만 진행한 이미지이다.
@mui-material 번들 사이즈는 다음 이미지를 확인

결과

@mui/icons-material: 6.1MiB -> 1.8KiB
@mui-material: 1.5MiB -> 711.3KiB

라이브러리 경량화2 (Firebase)

Treemap을 보면서 다음으로 큰 비중을 차지하고 있는 Firebase가 보였다.

검색을 통해 찾은 결과 많은 firebase SDK를 사용하고 있다면 다음과 같은 방법으로 SDK를 경량화 할 수 있다고 한다.

해당 솔루션이 바로 Firestore Lite 이다.

그리고 다음과 같이 모든 파일에 존재하는 경로를 변경해 주었다.



// as-is
import { getFirestore } from 'firebase/firestore';

// to-be
import { getFirestore } from 'firebase/firestore/lite';

그리고 Treemap 확인!

결과

firebase/firestore: 519.6KiB -> 172.0KiB

주의할 점으로 지원되지 않는 API 기능들도 있으니 확인하고 적용하면 되겠다.

또한 Firestore Lite는 실시간 업데이트와 연결이 필요 없는 앱에 적합하다고 한다.

그리고 나서 프로젝트 빌드 실행!

빌드 결과

빌드 크기: 1,074KB -> 803.93KB
빌드 시간: 1m 46s -> 6.20s

이 정도면 어느 정도는 빌드 최적화를 수행한 것 같지만 아직 한 가지 더 할 것이 남아있다.

빌드 경량화

파일을 빌드하면 다음과 같은 경고 문구가 뜬다



- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.

Using dynamic import() to code-split the application 방법은 이미 적용 되었으니 다음 방법으로 시도해 보려고 한다.

내용을 번역해 보면, 청크 개선을 위해build.rollupOptions.output.manualChunks 사용하라고 한다. 그 방법은 여기 에 있다고 한다.

즉, 청크 파일을 Code Split 하여 빌드 크기를 줄일 수 있다는 의미로 해석된다. 그래서 청크파일 중 크기가 가장 큰 파일을 분할해 주었다.



// vite.config.js
build: {
  rollupOptions: {
    output:{
      manualChunks(id) {
        if (id.includes('node_modules')) {
          return id.toString().split('node_modules/')[1].split('/')[0].toString();
        }
      }
    }
  }
}

블록을 분해하여 큰 블록을 더 작은 블록으로 나누는 방법이라고 한다. 이렇게 전부 코드를 분할하는 방식 보다는 다음과 같은 방식으로 변경해 주었다.



// vite.config.js
build: {
  rollupOptions: {
     output: {
       manualChunks: {
         firebase: [
           'firebase/app',
           'firebase/auth',
           'firebase/storage',
           'firebase/firestore',
          ],
          react: [
            'react-dom',
            'react-query',
            'react-router-dom'
          ],
        }
     },
  },
},

큰 사이즈의 라이브러리들만 골라 선언해 주었다.

큰 사이즈의 라이브러리는 사용자가 처음 페이지를 방문할 때 필요 없는 자원들을 모두 불러오기 때문에 초기 로딩 속도를 지연시킬 수 있기 때문에 큰 사이즈 라이브러리를 대상으로 코드 분할해 주었다.

그리고 빌드 후 확인!

빌드 결과

빌드 크기: 803.93KB -> 289KB
빌드 시간: 6.20s -> 5.57s

마무리

최종적으로 빌드 시간이 단축되고 크기도 줄어서 사용자에게 최적화된 렌더링 경험을 줄 수 있게 되었다.

이 모든 작업을 요약하면 Tree Shaking과 Code Split 만으로도 좋은 최적화 결과를 얻을 수 있다는 사실을 알게 되었다.

React Dev Tools의 Profiler를 활용한 렌더링 성능 개선

Heetae Kim — Mon, 20 May 2024 10:55:22 +0000

필자는 개인 프로젝트에서 최적화를 수행하면서 컴포넌트에 console.log나 console.count를 작성하여 컴포넌트의 리렌더링 횟수를 확인하였다.

그러다 React Developer Tools의 Profiler 기능이 생긴 이후에 컴포넌트 리렌더링 측정이 매우 편리해지고 리렌더링이 발생한 컴포넌트 타겟을 쉽게 알 수 있어서 자주 사용하고 있다.

그래서 이번 프로젝트에서도 React Dev Tools를 활용하여 컴포넌트 렌더링 성능을 개선해 보았다.

필자가 수행한 프로젝트는 온라인 북 커머스 플랫폼이다.

먼저, React DevTools를 브라우저에 설치해야 합니다. Chrome과 Firefox에서 확장 프로그램으로 제공된다. 다운로드

설치가 완료되면 브라우저 개발자 도구에 "Components", "Profiler" 탭이 추가된다.

리렌더링이 자주 발생하는 곳 찾기

성능을 개선하기 위해서 먼저 가장 리렌더링이 많이, 자주 발생하는 컴포넌트를 찾아야 한다.

생각이 먼저 떠오른 컴포넌트는 리스트 형식으로 여러 목록을 렌더링하는 조회 페이지가 떠올랐다. 해당 페이지는 북 데이터를 무한 스크롤로 구현하였다.

스크롤을 내리면 카테고리와 관련된 책 데이터를 API 요청을 통해 페이지네이션된 데이터를 클라이언트로 데이터를 받아와 컴포넌트로 렌더링 된다.

성능 개선 전

위 이미지에 대해 간략히 설명하자면 이렇다.

BooksScroll 페이지에 대한 렌더링 지표이다.
부모 컴포넌트는 ul element, 자식 컴포넌트는 Book 컴포넌트이다.
렌더링된 페이지에서 동일한 자식 컴포넌트(Book)가 리렌더링된다.
만일 자식 요소가 100, 1000 이상으로 많아질 경우 불필요한 리소스 비용이 발생하게 된다.

목표는 바로 자식 컴포넌트의 불필요한 리렌더링을 방지하는 것이 목표다.

개선 방법

React.memo 활용

컴포넌트의 리렌더링을 방지하는 방법 중 메모이제이션 기법을 활용한 memo를 컴포넌트에 적용하는 방법이 있다.

자식 컴포넌트에 memo 메서드를 적용하여 해당 컴포넌트를 메모이제이션 한다.

메모이제이션된 컴포넌트는 다음 렌더링 과정에서 가상 컴포넌트가 DOM 객체와 비교하는 과정을 거치면서 렌더링 대상에서 제외시킨다.

export const Book = React.memo(({ item, category }: BookProps) => {
  return (
    <React.Fragment>
      <S.Item >

        ...more code line

      </S.Item>
      <Divider variant="fullWidth" />
    </React.Fragment>
  )
})

필자는 named export를 사용하였기 때문에 위와 같이 적용하였다.

memo 사용 시 주의할 점으로 메모이제이션 적용된 컴포넌트의 props에 참조 객체나 함수가 있는지 확인해야 한다. 만일 useCallback이나 useMemo가 적용되지 않은 참조 객체나 함수를 props로 받을 경우 컴포넌트에 memo를 적용하여도 다시 리렌더링이 발생할 수 있다.

성능 개선 후

성능 개선 전과 비교하면 렌더링이 일어나지 않는 컴포넌트를 확인할 수 있다. 이렇게 아주 미세한 최적화 과정이지만 데이터가 방대한 경우에는 좋은 최적화 결과를 얻을 수 있을 것이라 생각한다.

Rendered at을 확인해 보면 모든 렌더링 마다 리렌더링이 발생하였던 이전과 달리 단 한번만 렌더링이 발생한 것을 확인할 수 있다.

현재 북(Book) 이미지도 같이 렌더링 하고 있는데, 이미지 최적화를 통한 LightHouse 렌더링 성능 측정을 통해 LightHouse 최적화 방법도 시도해 볼 예정이다.