2년 전 회사에서 발표한 내용인데 포스팅해 본다.

나에게는 TypeScript에서 제네릭을 활용한 완벽한 타입 추론에 대해 흥미가 있었던 시절이 있었다. 그때 공부했던 내용이다.

타입스크립트에서 코드 레벨이 아닌 타입 레벨에서의 코딩 방법을 알아보자.

목차

• TypeScript에 대해서, 서론
• 타입스크립트는 완전 튜링하다
• 제네릭과 조건문, 반복문
  • 제네릭 (Generics)
  • 조건문
  • 반복문
• Currying의 타입 구현하기
  • 인자가 2개인 케이스
  • 인자가 3개인 케이스
• 마무리

TypeScript에 대해서, 서론

javascript의 슈퍼셋으로 나온 언어이다.
다들 javascript에서 타입이 없기에 타입스크립트를 적용하게 되면 완벽한 프로그래밍을 할 수 있을 거라 생각을 할 텐데 대부분은 Generics를 마주하게 되면서 좌절을 겪으며 any 타입 도배로 코드를 작성하게 된다.

그러면 타입스크립트를 사용하는 이유가 없어지는 것 같이 보이게 된다.

사실 any가 나쁜 건 아닌데, 이와 관련된 조롱 밈도 많이 돌아다닌다.

타입스크립트는 완전 튜링하다

튜링 머신이란?

수학자 앨런 튜링이 1936년에 제시한 개념으로 계산하는 기계의 일반적인 개념을 설명하기 위
한 가상의 기계이며 오토마타의 일종이다

튜링하다는 증명은 TS_issues_14833에 설명되어 있다.

우리가 알 수 있는 내용은 아무튼 TS의 타입 시스템은 완전 튜링하니,
타입 시스템 자체를 하나의 프로그래밍 언어처럼 사용할 수 있을 정도로 강력하다고 볼 수 있다.

이제부터는 실제로 제네릭과 조건부 타입 등을 이용해 타입 레벨에서 어떻게 프로그래밍할 수 있는지 살펴보자.

제네릭과 조건문, 반복문

제네릭 (Generics)

제네릭은 선언 시점이 아니라 생성 시점에 타입을 명시하여 하나의 타입만이 아닌 다양한 타입을
사용할 수 있도록 하는 기법이다.

type A<T> = T;
type B = A<number>; // number
type C = A<string>; // string

제네릭으로 선언된 A를 함수처럼 인자로 타입을 받아서 어떤 타입이 될지를 정할 수가 있다.

조건문

그렇다면 타입 레벨에서의 조건문은 어떻게 사용하는지 보자.
여기서 주요 키워드는 extends 이다.

type User {
  name: string;
  email: string;
}

type IsHasField<T, FieldName extends string> = FieldName extends keyof T
  ? true
  : false;

type HasEmailField<T> = IsHasField<T,'email'>
type UseHasEmailField = HasEmailField<User> // true

해당 키워드의 역할은 3가지가 있다.

1. 조건문 역할 (if)
2. 타입 제한
3. 타입 확장

예시에서는 if 문의 조건문 역할을 수행하여서 FieldName에 있는 키일 경우 true로 타입이 추론되게 되어있다.

반복문

타입 시스템에서는 for문이나 while문 같은 문법이 없다. 다만 재귀는 가능하여서 재귀로 반복문을 수행해야 한다.

여기서 중요 키워드는 infer (타입 변수 할당) 이다.

type IsAllNumber<T extends unknown[]> = T extends [infer First, ...infer Rest]
  ? First extends number
    ? IsAllNumber<Rest>
    : false
  : true;

type A = IsAllNumber<[1, 2, 3]>; // true
type B = IsAllNumber<[1, 2, "knowre"]>; // false

위 예시를 보면 extends와 infer를 사용하여서 첫 번째 요소를 변수에 할당한 이후에 그 값이 number인지 비교를 하고, 맞으면 나머지 요소들을 다시 재귀로 돌려주면서 다음 요소를 순회하고 있다.

infer로 요소 하나를 판별하고 나머지 요소로 재귀를 돌림으로써 반복문을 수행하는 것이다.

Currying의 타입 구현하기

위 내용을 바탕으로 Currying 타입을 구현해보자.
이걸 할 수 있으면 웬만한 타입은 다 만들 수 있을 것이다.

/** Currying 이란..? */
function curry(fn) {
  return function curried(...params) {
    if (fn.length === params.length) {
      return fn(...params);
    }

    return curried.bind(this, ...params);
  };
}

const add = (a: number, b: number) => a + b;

const curriedAdd = curry(add);

const addFive = curriedAdd(5);

console.log(curriedAdd(2, 3)); // 5
console.log(curriedAdd(2)(4)); // 6
console.log(addFive(3)); // 8

일단 커링(Currying)에 대해서 설명하자면, 함수를 받아서 함수를 리턴하는데, 그 함수는 모든 파라미터가 다 전달된 시점에서 실행이 되게 하는 함수이다. 일부 파라미터만 전달하게 되면 다시 함수를 리턴한다.

함수의 실행 시점을 뒤로 미룰 수가 있어서 함수형 프로그래밍에서는 필수적으로 사용하게 된다.

이걸 타입으로 구현한다면 curriedAdd 함수는 함수 or number 를 리턴하는 타입일 것이고, addFive 함수는 number를 리턴하는 함수 타입일 것이다.

본격적으로 구현하기 전에 다른 유틸 타입들을 먼저 살펴보자.

type AnyFn = (...params: any) => any;

type Parameters<T extends AnyFn> = T extends (...params: infer P) => any
  ? P
  : never;
// type A0 = Parameters<(a: string, b: number) => boolean>
// [a: string, b: number]

type ReturnType<T extends AnyFn> = T extends (...params: any[]) => infer R
  ? R
  : never;
// type A1 = ReturnType<() => 'returnType'>
// 'returnType'

type Head<T extends any[]> = T extends [infer First, ...any[]] ? First : never;
// type A2 = Head<[1, 2, 3, 4, 5]>
// 1

type Tail<T extends any[]> = T extends [any, ...infer Rest] ? Rest : never;
// type A3 = Tail<[1, 2, 3, 4, 5]>
// [2, 3, 4, 5]

type Length<T extends any[]> = T["length"];
// type A4 = Length<[1, 2, 3, 4, 5]>
// 5

타입 선언부 아래 주석에서 첫 번째 줄은 사용 예시이고, 두 번째 줄은 해당 타입의 모습이다.
천천히 읽어보면 이해가 될 것이다.

이제 본격적으로 커링을 만들어 볼 건데, 인자가 2개인 케이스부터 만들어보고 3개 이상인 케이스를 만들면서 커링을 완성 시킬 것이다.

인자가 2개인 케이스

대강 인터페이스가 어떻게 될지 생각해보자.

const add = (a: number, b: number) => a + b;

const curry = (() => {}) as Curry;

/**
 * 기대하는 타입 값
 * `((a, b) => a + b) & ((a) => (b) => a + b)`
 */
const curried = curry(add);

const addFive = curried(5); // (b: number) => a + b
const eight = curried(5, 3); // number

curried 된 함수 값은 두 가지 타입이 같이 존재할 것이다.

((a, b) => a + b) & ((a) => (b) => a + b)

일단 전달 받은 함수에서 리턴값과 파라미터값을 추출해내서 새로운 타입으로 만들어야 한다.

type Curry<Fn extends AnyFn> = Curried<Parameters<Fn>, ReturnType<Fn>>;

제네릭으로 받은 값에서 파라미터와 리턴값을 추출해내서 새로운 타입 Curried로 넘겨준다. 이제 Curried를 만들어보자.

type Curried<P extends any[], R> = P extends [infer Head, ...infer Rest]
  ? HasTail<P> extends true
    ? ((a: Head) => Curried<Rest, R>) & // 커링된 함수
        ((a: Head, ...b: Rest) => R) // 커링 없이 모든 인자 받아서 실행
    : (a: Head) => R // head 하나만 넘어옴
  : never;

넘겨 받은 파라미터값을 순회하면서 타입을 조합해 줘야 한다. 따라서 extends와 infer를 사용해 순회할 수 있는 준비를 하고, 무한 재귀가 되면 안 되니까 마지막 조건을 정의해 준다.
그것은 바로 파라미터를 모두 순회했을 때이다. 5번 줄의 (a: Head) => R 이 부분이다.

재귀는 HasTail로 마지막인지 판단하고, 두 개의 타입을 묶어서 만든다. (3, 4번 줄)

인자가 3개인 케이스

여기는 좀 더 어렵다. 순회하면서 모든 파라미터를 들고 가야 하면서, 마지막 지점을 알 수 있어야 한다.
인터페이스를 생각해보자.

const foo = (a: number, b: string, c: boolean) => true;

/**
 * 기대하는 타입값
 * (
 *   (a: number) => (
 *     (b: string) => (c: boolean) => boolean) &
 *     ((b: string, c: boolean) => boolean)
 *   )
 * ) &
 * ((a: number, b: string) => (c: boolean) => boolean) &
 * ((a: number, b: string, c: boolean) => boolean)
 */
const curriedFoo = curry(foo);

type Curry<Fn extends AnyFn> = Curried<Parameters<Fn>, ReturnType<Fn>>;

일단 앞의 Curry와 동일하게 해주고 새로운 Curried를 구현한다.

type Curried<
  P extends any[],
  R,
  PrevParams extends any[] = [], // 모든 params를 저장하기 위해서 앞전에 커링된 인자를 보관하기 위한 값
> = P extends [infer Head, ...infer Tail]
  ? HasTail<P> extends true
    ? ((...params: [...PrevParams, Head]) => Curried<Tail, R>) & // 커링된 함수를 리턴.
        Curried<Tail, R, [...PrevParams, Head]> // 커링 없이 실행한 함수 리턴
    : (...params: [...PrevParams, Head]) => R // Arg가 1개 남았을 경우 모든 Params를 넣어서 실행하는 함수
  : never;

앞에 인자 2개일 때와 다르게 제네릭을 하나 더 추가하여서 (4번 줄) 순회할 때 모든 파라미터를 끌고 간다.

그리고 그 뒤는 비슷하다. 마지막 부분(9번 줄)에는 모든 파라미터를 넣어서 실행하는 함수 리턴으로 마무리하고, 순회 부분에서는 두 가지 타입을 만들어서 리턴한다. (7~8번 줄)

커링 없이 실행한 함수는 모든 파라미터를 들고 마지막 지점까지 갈 수 있도록
Curried<Tail, R, [...PrevParams, Head]>(8번 줄)으로 만들어주고,

커링된 함수 부분은 값을 소비하고 나머지 파라미터값으로 새로운 커링 타입을 만든다.
((...params: [...PrevParams, Head]) => Curried<Tail, R>)(7번 줄)

마무리

이해가 안 된다면 넘어가도 좋다. 타입 레벨단 코딩은 가독성이 무척 안 좋기 때문에 이해하려고 노력할 필요는 없는 것 같다.

그리고 제네릭 잘 쓰면 좋긴 하다만, 너무 복잡해지는 경우가 있고 가독성도 매우 떨어진다. 실제 로직과는 아무 상관이 없는데 타입 프로그래밍만 주구장창 하고 있는 모습을 보면 뭐하고 있나 싶기도 하다.

제네릭을 적재적소에 잘 사용하면서 단순하고 심플하게 하는 게 좋을 것 같다. 비록 any를 쓰더라도.

개발 업무를 하게 되면서 내 손목도 지키고 편안하게 업무를 수행할 수 있도록 도구들을 많이 갈고 닦았다. 그 과정에 대해 공유한다.

목차

• 1. GUI 환경에서 CLI, TUI 환경 위주에서 작업
• 2. Dotfiles 구성
• 3. Keyboard Layout 전환
• 마무리

1. GUI 환경에서 CLI, TUI 환경 위주에서 작업

때는 취직 후 개발 일을 시작한지 3개월 되었을 무렵이였다. 당시 vscode로 코딩을 하고 있었다.

마우스를 사용하면서 코드와 파일을 이동했는데, 오른손이 매번 키보드와 마우스 사이를 오가는 것이 불편혔고 손목에도 부담이 갔다.

이 문제를 개선하고자 nvim을 사용하기 시작했고, 자연스럽게 터미널에서 주로 작업을하게 되었다. 그 과정에서 CLI환겅에도 익숙해졌다.

현재 AI 시대에 와서는 CLI 환경에 익숙한 작업 방식이 더 큰 장점으로 다가오고 있다.

GUI에서 CLI로 전환한 몇 가지 툴들을 소개하겠다.

2. Dotfiles 구성

1번을 거지게 되면 CLI 툴들의 설정 파일이 여러 개 생기게 된다.
이와 더불어 개발 환경의 초기 설정 구조가 잡히게 되는데 이를 관리해 줄 패키지 매니저가 필요하게 된다.

필자는 nix로 패키지 관리하고, 설정 파일들을 dotfiles 레포에 저장하고 있다.

3. Keyboard Layout 전환

업무 중 타이핑을 하면서도 손목이 꺽이면서 불편함이 발생하였고, 레이아웃도 변경을 하였다.

일단 키보드에 손을 두는 방식을 Angle mod 로 변경 하였다.

손목이 꺽이지 않아 너무 편하였고 이에 맞는 최적화된 레이아웃으로 변경하였다.

QWER -> Colemak -> Colemak-dh -> Canary

현재 영문은 Canary에 정착을 한 상태이고,

두벌식 -> 세벌식 390 -> 신 세벌식 P2

한글은 신 세벌식 P2에 정착한 상태이다.

마무리

위 여정은 앞으로도 계속될 것 이며, 과거에 비해서 지금 개발 환경과 일하는 방식은 아주 편해졌다.

경험담이나 그 과정에서 겪은 힘든 점 등을 내 관점에서 좀 더 서술하고 싶지만 미니멀리스트답게 담백하게 마무리한다.

지금 블로그는 nextjs의 mdx지원 기능을 이용해서 구현되었고, vercel로 호스팅중 이다.
블로그 리모델링할 겸 해서 개선하고 싶은 점이 있어서 구조좀 변경 할려고 한다.
그런데 오랜만에 할려고 하니까 어떤 구조인지 기억이 안나서 포스팅을 해본다.

Netxjs로 블로그 만들기

nextjs문서

Feature 항목

• mdx 파싱하여 html으로 변환 해서 페이지로 만들기
  • remark¹, rehypo² 를 사용해서 변환 과정을 거친다.

    mdx -> remark -> rehype -> html

  • 마크다운의 코드 블럭 스타일 처리 (prism 사용)

• sitemap³ 만들기
  • SEO를 위해 필요함

• RSS Feed 설정

구현 하기

1. mdx 파싱해서 -> 페이지 만들기

nextjs에서 turbo pack를 사용해서 할려면은 next.config.ts에서 설정해 줘야 한다.

// next.config.ts
import createMDX from "@next/mdx";
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  pageExtensions: ["js", "jsx", "md", "mdx", "ts", "tsx"],
};

const withMDX = createMDX({
  options: {
    remarkPlugins: [
      "remark-breaks",
      "remark-gfm",
      ["remark-toc", { heading: "목차" }],
    ],
    rehypePlugins: [
      ["rehype-slug"],
      [
        "rehype-autolink-headings",
        {
          behavior: "append",
        },
      ],
      ["rehype-katex", { strict: true, throwOnError: true }],
      "rehype-plugin-image-native-lazy-loading",
      ["rehype-prism-plus", { defaultLanguage: "js", ignoreMissing: true }],
    ],
  },
});

export default withMDX(nextConfig);

mdx파일 수집해서 페이지로 만들기

// mdx파일들 읽어서 객체화하기
export function getBlogSlugs() {
  const dir = path.join(process.cwd(), "src", "content", "blog");

  return fs
    .readdirSync(dir)
    .filter((file) => path.extname(file) === ".mdx")
    .map((file) => path.basename(file, path.extname(file)));
}

export async function importBlogContent(slug: string): Promise<ContentModule> {
  const module = await import(`@/content/blog/${slug}.mdx`);

  return {
    ...module,
    metadata: MetadataSchema.parse(module.metadata),
  };
}

export async function getAllBlogContents() {
  const contents = await Promise.all(
    getBlogSlugs().map(async (slug) => {
      const { metadata } = await importBlogContent(slug);

      return {
        metadata,
        slug,
      };
    }),
  );

  contents.sort((a, b) =>
    b.metadata.publishedAt.localeCompare(a.metadata.publishedAt),
  );

  return contents.filter(({ metadata }) => !metadata.public);
}

// app/blog/[slug]/page.tsx
export const dynamicParams = false;

export function generateStaticParams() {
  return getBlogSlugs().map((slug) => ({ slug }));
}

export default async function Page({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;

  const { default: Content, metadata } = await importBlogContent(slug);

  if (metadata.public) {
    return notFound(); // Render 404 page
  }

  return <Content />;
}

2. sitemap 구성하기

// app/sitemap.ts
export const dynamic = "force-static";

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await getAllBlogContents();

  const routes = ["", "blog"].map((route) => ({
    url: `${siteMetadata.siteUrl}/${route}`,
    lastModified: new Date().toISOString(),
  }));

  const blogRoutes = posts
    .filter(({ metadata }) => !metadata.public)
    .map(({ metadata, slug }) => {
      const date = new Date(metadata.publishedAt);
      const hours = date.getHours();

      return {
        url: `${siteMetadata.siteUrl}/blog/${slug}`,
        lastModified: new Date(date.setHours(hours - 9)).toISOString(),
      };
    });

  return [...routes, ...blogRoutes];
}

3. RSS Feed
   현재 딱히 필요하진 않아서 미구현.

마무리

오랜만에 코드를 다시 보니 당시에는 이해하고 작성했던 구조도 시간이 지나면서 많이 잊어버렸다.
이번 글은 리모델링을 시작하기 전에 현재 블로그가 어떤 방식으로 동작하는지 다시 정리해보기 위한 기록이다.

이후 리모델링은 마크다운 파싱을 조금 더 유연하게 처리하기 위해 Next.js의 Turbopack 기반 MDX 처리 대신, 빌드 타임에 remark•rehype를 직접 사용하는 방식으로 구조를 변경했다.

또한 데이터베이스 관계도와 같은 다이어그램을 표시할 수 있도록 Mermaid 지원도 추가했다.

좋은 기술 블로그란 무엇인가? 사실 나는 잘 모르겠고 긱뉴스에 포스팅된 글이 있다.
GeekNews_실무 중심 블로그

위 포스팅과 별개로 내가 생각하는 기술 블로그는
기술 관련된 이야기를 올려야 한다고 생각해왔다.
단순히 공식 문서에 있는 사용법을 정리하는 글보다는, 직접 개발하면서 마주했던 문제와 이를 해결해 나간 과정이 담긴 글이 더 가치 있다고 믿었다.

그런 생각 때문인지 글을 써놓고도 공개하지 않은 포스팅이 많아졌고, 점점 포스팅 자체가 어려워졌다. 기준이 높아질수록 글을 쓰는 부담도 함께 커졌던 것 같다. 하지만 기술 이야기만 하는 블로그보다는, 가끔은 내 생각과 경험도 함께 기록하고 싶다는 마음이 들었다.

그래서 앞으로는 기술과 에세이를 함께 담는, 나만의 블로그로 운영해보려고 한다.
아직 정리가 덜 된 글이라도 일단 써보고 올려보자. 글을 쓰는 과정 자체가 생각을 정리하게 만들고, 결국 더 나은 글로 이어질 테니까.

React Re Rendering

발표하기 위해 만든 자료이며 발표 자료로 대체합니다.

개발할 때는 주로 neovim을 사용하다 보니, 터미널에서 모든 작업을 수행하는 데
쉘이 켜지는 속도가 갑자기 너무 느린 게 느껴지는 것이었다.

느린 원인을 찾고 개선하기 위한 여정이다.

목차

• 원인 찾기
• 개선 하기
• 결과
• 추가적으로

원인 찾기

zsh-bench을 돌려보았다.

# 설치하고 실행
> ~/zsh-bench/zsh-bench

눈 여겨볼건 이거다. first_prompt_lag_ms=1409.696

처음 키고 프롬프트 입력할수 있을때 까지 1409ms가 걸린다.
그러면 이제 zsh/zprof를 사용하여 무엇 때문에 느린지 살펴보자

# .zshrc 에 해당 라인 추가
> zmodload zsh/zprof

# 실행
> zprof

nvm이 많이 느린편인걸 알 수 있다.

개선 하기

nvm을 제거하고 하는김에 플러그인 매니저까지 변경하였다.

• nvm 대안책 찾기 => Volta
• oh-my-zsh => antidote

본인은 nix¹를 사용하기에 아래와 같이 설정을 하였다.

# configuration.nix
{
  environment.systemPackages = with pkgs; [
    ...
    antidote
    volta
  ]

  programs.zsh = {
    enable = true;
    enableBashCompletion = false;
    enableCompletion = false;
    variables = {
      ZDOTDIR = "$HOME/.config/zsh";
    };
    promptInit = ''
      fpath=(${pkgs.antidote}/share/antidote/functions $fpath)
      autoload -Uz antidote
    '';
  };
}

결과

first_prompt_lag_ms가 39.118ms로 줄었다. (97.22% 빨라짐)
volta 도 nvm 보다 휠씬 간단하고 빠르다.

아주 쾌적하고 만족스럽다.🙂

추가적으로

omz 프레임워크를 벗어나니 sub-string-search 기능이 빠져있다.
zsh-vi 모드를 사용하기에 해당 기능도 넣어주었다.

function zvm_before_init() {
    # up, down 시 히스토리 substring search
    autoload -U history-search-end
    zle -N history-beginning-search-backward-end history-search-end
    zle -N history-beginning-search-forward-end history-search-end

    # zsh-vi-mode
    zvm_bindkey viins '^[[A' history-beginning-search-backward-end
    zvm_bindkey viins '^[[B' history-beginning-search-forward-end
    zvm_bindkey vicmd '^[[A' history-beginning-search-backward-end
    zvm_bindkey vicmd '^[[B' history-beginning-search-forward-end
}

설정은 제dotfiles에서 볼 수 있습니다.

웹 개발을 하다보면 이미지를 다루게 될 일이 많다.
여기에서 유저가 이미지를 업로드 하는 기능이 있다면 주의해야될 점이 있다.
보통 핸드폰으로 찍은 사진을 업로드를 할텐데, 이 경우 용량은 2~3MB 정도 된다.
이러한 이미지들을 그대로 사용한다면 이제 웹페이지는 느려지는 것이다.

웹에서 적합한 이미지 크기는 네트워크 환경에 따라 다르고, 이미지의 역할에 따라 다르긴 할텐데 ChatGPT한테 물어본 결과 300kb이하가 적당하다고 한다.
그렇다면 이미지를 어떻게 줄일수 있을까?

방법1: 업로드 용량 제한하기

<script>
  const fileInput = document.getElementById("fileInput");

  fileInput.addEventListener("change", function () {
    const file = fileInput.files[0];

    if (!file) return;

    const maxSizeMB = 1; // 1MB 제한
    const maxSizeBytes = maxSizeMB * 1024 * 1024;

    if (file.size > maxSizeBytes) {
      toast("용량이 너무 커요");
    } else {
      toast("성공!");
    }
  });
</script>

파일 인풋에서 받아온 파일에 대한 용량을 알 수가 있다.
여기서 최대 용량 이하만 받도록 하는 것이다.

방법2: 클라이언트에서 리사이징하기

사이즈만 줄여도 용량이 많이 줄어든다.
웹에서는 canvas api를 사용해서 사이즈를 줄일수가 있다.

원하는 사이즈의 canvas를 만들고 그안에 이미지를 그려서 바이너리로 추출하는 방식이다.

<script>
  const upload = document.getElementById("upload");

  upload.addEventListener("change", async function () {
    const file = this.files[0];

    const img = new Image();
    img.src = URL.createObjectURL(file);

    img.onload = () => {
      const MAX_WIDTH = 800;
      const scale = MAX_WIDTH / img.width;
      const width = Math.min(img.width, MAX_WIDTH);
      const height = img.height * scale;

      // 캔버스 태그 생성
      const canvas = document.createElement("canvas");
      canvas.width = width;
      canvas.height = height;

      // 이미지 그리기
      const ctx = canvas.getContext("2d");
      ctx.drawImage(img, 0, 0, width, height);

      // 압축된 blob로 변환
      canvas.toBlob(
        (blob) => {
          if (blob) {
            // 미리보기 url
            const resizedUrl = URL.createObjectURL(blob);

            // 서버에 업로드하려면 `blob`을 formData 등에 넣어서 전송
            // const formData = new FormData();
            // formData.append("file", blob, "resized.jpg");
          }
        },
        "image/jpeg",
        0.8,
      ); // JPEG 포맷, 품질 80%
    };
  });
</script>

방법3: 백엔드에서 처리하기

nodejs에서는 sharp가 대표적인 이미지 압축 및 변환 라이브러리다.

과거 실무 중에 적용 시킨 사례를 소개한다.

적용전

export const parseImagesMiddleware = [
	bindMiddleware(multer().array('images', STUDY_PLAN_IMAGES_UPLOAD_MAX_COUNT)),
	(req, res, next) => {
		const files = req.files ?? []

		req.files = files.map(file => ({
			fileName: parseFileName(file, req.params.planId),
			buffer: file.buffer,
		}))

		next()
	}),
]

적용후

export const parseImagesMiddleware = [
  bindMiddleware(multer().array("images", STUDY_PLAN_IMAGES_UPLOAD_MAX_COUNT)),
  asyncHandler(async (req: any, _res, next) => {
    const files = req.files ?? [];

    const webpFiles = await Promise.all(
      files.map(async (file) => ({
        fileName: parseFileName(file, req.params.planId, "webp"),
        buffer: await sharp(file.buffer).webp().toBuffer(),
      })),
    );

    req.files = webpFiles;

    next();
  }),
];

sharp로 손실 압축을 하여 webp포멧으로 만들어 저장한다.
이렇게 했을시 어느정도 압축이 되는지 살펴보면,
아래는 핸드폰 에서 캡쳐사진이고 용량은 978.5kb 이다.

이 사진을 위같이 webp로 손실압축을 하면 100.4kb가 된다.
87.9%가 압축된 거다.

효과는 확실한데 여기서 주의할 점이 있다.
sharp는 cpu 자원을 많이 사용하기에 위같이 서버에서 다이렉트로 사용하긴 무리가 있다.
그래서 최종적으로 적용한 방법은 서버에서는 원본을 저장하고,
람다에서 sharp를 쓰는 방법으로 이미지를 최적화 하였다.

결론

결국엔 위 세가지 방법 모두 사용해야 되지 않나 싶은데,
실용적인 관점에서는 우선 1번 부터 적용하고 필요성에 따라 2번 3번 순으로 적용하면 될 것 같다.