자라는 것을 잘하는 개발자

Electron 배포 및 자동 업데이트 (feat. AWS S3 & electron-updater)

xiubin — Mon, 4 Sep 2023 16:10:42 +0900

Electron Build Lifecycle

https://www.electronforge.io/core-concepts/build-lifecycle

데스크탑 애플리케이션을 빌드하고 배포하는 과정에서 주목해야 할 부분은 배포 가능한 파일을 생성하는 단계이다. 웹과 달리 패키징 단계에서 생성된 번들을 가지고 OS별 설치 프로그램을 생성해야 한다. 이 단계에서 대응하고자 하는 OS별, 플랫폼별로 모두 빌드해줘야 한다.

electron-builder를 선택한 이유

electron 앱을 패키징하고 배포하기 위해 사용하는 대표적인 도구는 Electron Forge로 문서에서 소개되어 있다. Electron Forge의 가장 큰 장점은 분산되어 있는 배포 작업용 패키지들을 통합해서 빌드 파이프라인을 최소한의 구성으로 생성할 수 있다는 것이다. electron-builder 역시 분산되어 있는 패키지들을 어느 정도 통합해 두긴 했지만 배포에 필요한 스크립트를 대부분 직접 짜야한다는 것이다.

서로 장단점이 있지만 electron-builder를 사용하고자 했던 가장 큰 이유는 자동 업데이트 기능에 있다.

업데이트가 있을 때마다 유저가 새로운 설치 파일을 직접 다운로드하는 것은 굉장히 번거로운 일이다. 그렇다면 애플리케이션에서 자동으로 업데이트가 있음을 감지하고 다운로드한다면 어떨까? 이것을 가능하게 해주는 기능이 바로 electron의 자동 업데이트 기능이다.

Electron Forge로 자동 업데이트를 구성하려면 오픈 소스로 깃허브에 릴리즈 하거나 자체 업데이트 서버를 구성해야 했다. 그러나 우리 프로젝트는 오픈 소스가 아닐뿐더러 업데이트 서버를 자체적으로 운영하기에는 관리 포인트가 늘어나기 때문에 좋은 방법이 아니었다.

그래서 자동 업데이트를 지원하는 electron-builder에서 소개하는 electron-updater를 함께 사용하기로 했다.

A complete solution to package and build a ready for distribution Electron, Proton Native app for macOS, Windows and Linux with “auto update” support out of the box.

electron-builder를 소개하는 문구에서 볼 수 있듯이 별도의 구성 없이 "auto update"를 지원한다는 것을 강조하고 있음을 볼 수 있다.

By default, Electron Forge will only build your app for the operating system it's running on.

그리고 빌드에 관한 electron-forge 문서를 살펴보면 실행 중인 운영체제용으로만 앱을 빌드할 수 있고, 크로스 플랫폼 빌드를 하기 위해서는 별도로 빌드 머신을 이용해서 빌드 파이프라인을 구성해야 한다고 되어있다. 그래서 개발 편의성을 위해 macOS에서도 windows 앱을 빌드하고 배포할 수 있도록 electron-builder를 선택하기로 결정했다.

AWS S3 버킷 생성 및 AWS Access key 구성

Window App Store 또는 Mac App Store에 올리지 않는다면 누구나 웹에서 앱을 다운로드할 수 있도록 배포할 필요가 있다. 이를 위해 AWS S3에 public으로 게시하는 방법을 아래에서 소개하겠다.

1. AWS IAM 서비스에서 access 키 발급

우선 AWS IAM 서비스에서 사용자를 추가해서 발급받은 키(AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)를 저장해 둔다.

그리고 파일 읽기 및 업로드 등을 위해 AmazonS3FullAccess 권한을 부여한다.

2. AWS S3 버킷 생성

버킷을 생성할 때 객체 소유권 - ACL은 활성화하고, 퍼블릭 액세스 차단은 모두 비활성화해 준다. 그리고 버킷 정책을 아래와 같이 추가한다.

{
    "Version": "2012-10-17",
    "Id": "Policy1234",
    "Statement": [
        {
            "Sid": "asdf",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your-app/*"
        }
    ]
}

3. AWS access key 추가

Amazon S3 options. AWS credentials are required, please see getting your credentials. Define AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables. Or in the ~/.aws/credentials

위와 같이 문서에서 제공한 방법은 두 가지이다. 환경변수를 추가하는 것과 컴퓨터 루트 폴더에 추가하는 것이다.

방법1. env 파일에 환경변수로 추가하기

AWS_ACCESS_KEY_ID = 
AWS_SECRET_ACCESS_KEY =

방법2. AWS CLI 설치해서 설정하기

최신 버전의 AWS CLI 설치 또는 업데이트 - AWS Command Line Interface

이전 버전에서 업데이트하는 경우 unzip 명령을 실행하면 기존 파일을 덮어쓸지 묻는 메시지가 표시됩니다. 스크립트 자동화와 같은 경우에 이러한 프롬프트를 건너뛰려면 unzip에 대한 -u 업데이

docs.aws.amazon.com

위 문서를 참고해서 AWS CLI를 설치한다. 설치 후 키를 추가하기 위해 터미널에서 aws configure 명령어를 실행한다.

실행 후 IAM에서 발급받은 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY 를 입력하고, 생성한 버킷의 region을 입력한다.

완료 후 터미널에서 aws configure list 명령어를 실행해서 잘 추가됐는지 확인한다.

electron-builder 구성

Publish - electron-builder

Publish The publish key contains a set of options instructing electron-builder on how it should publish artifacts and build update info files for auto update. String | Object | Array where Object it is Keygen, Generic Server, GitHub, S3, Spaces or Snap Sto

www.electron.build

파일을 AWS S3에 배포하기 위해서 publish 옵션을 구성해줘야 한다. 세부적인 옵션은 위 문서를 참고하면 된다.

electron-builder 구성은 디폴트로는 electron-builder.yml 파일에서 작성하면 된다.

appId: com.electron.app
//...생략
publish:
    provider: s3 //배포 공급자
    bucket: your-app //S3 버킷 이름
    region: ap-southeast-1 //S3 버킷 지역
    acl: public-read //S3 ACL 권한
    publishAutoUpdate: true // 자동 업데이트 정보 파일 배포 여부

그리고 package.json에 OS 별로 빌드 스크립트를 작성해 준다. 공식 문서에는 빌드가 병렬로 진행되기 때문에 하나의 빌드 명령어에 멀티 플랫폼을 지정해주는 것이 좋다고 나와 있다.

"build": "npm run typecheck && electron-vite build",
"deploy:win": "npm run build && electron-builder --win --x64 --config --publish always",
"deploy:mac-x64": "npm run build && electron-builder --mac --x64 --config --publish always",
"deploy:mac-arm64": "npm run build && electron-builder --mac --arm64 --config --publish always"
"deploy:all": "npm run build && electron-builder -mwl --config --publish always"

위와 같이 구성해 놓으면 S3로 배포할 준비는 완료된 것이다.

배포 완료

테스트로 deploy:mac-arm64 배포 스크립트를 실행하면 S3로 배포되는 것을 아래 로그에서 볼 수 있다.

S3 버킷을 확인하면 아래와 같이 파일이 업로드된 것을 확인할 수 있다.

electron-updater 자동 업데이트

electron-updater를 사용하면 간단한 설정 몇 가지만 진행하면 자동 업데이트 기능을 구현할 수 있다. 자동 업데이트 가능한 대상은 디폴트로 DMG, AppImage, NSIS 가 있다.

그리고 macOS의 경우 자동 업데이트가 작동하려면 반드시 코드 서명이 필요하고, windows의 경우는 코드 서명이 없어도 가능하다. 코드 서명에 대한 글은 이전 글에서 자세히 작성해 뒀다.

electron-updater 라이브러리에서 자동 업데이트의 핵심 함수는 checkForUpdates이다. 이 함수를 통해 업데이트 여부를 체크하고 업데이트가 필요하다면 업데이트를 진행하게 된다.

그렇다면 업데이트 여부를 어떻게 체크하는 걸까? 정답은 latest.yml 파일에 있다. 위 배포 스크립트를 실행하면 latest.yml (또는 latest-mac.yml for macOS, 또는 latest-linux.yml for Linux) 파일이 생성되고 함께 올라간다. 이 파일에는 파일의 버전 정보, 배포 날짜 등이 담겨있는데, 버전을 변경해서 배포하게 되면 버전 정보, 배포 날짜 등이 수정돼서 올라간다. 앱이 실행되면 이 파일을 읽어서 버전이 다를 경우 자동 업데이트가 실행되는 구조이다.

자동 업데이트를 진행하는 방식에는 두 가지가 있다.

사용자의 의사와는 관계없이 자동으로 업데이트를 진행하는 방식 - checkForUpdatesAndNotify
사용자가 직접 업데이트를 진행해야 하는 방식 - checkForUpdates

checkForUpdatesAndNotify를 사용하게 되면 업데이트 가능한 상황에는 운영체제의 시스템 알림 창을 띄워서 업데이트 진행 여부를 묻게 된다. 여기서 주의해야할 점은 시스템 알림 설정에서 앱에 대한 알림을 꺼두면 업데이트 알림을 볼 수 없다. 다만 알림은 오지 않더라도 업데이트 다운로드는 자동으로 되고 앱을 종료하고 다시 실행하게 되면 업데이트된 버전이 실행된다. 따라서 업데이트 알림을 반드시 보여주고 싶거나 업데이트 여부를 유저가 결정하도록 하게 하려면 직접 업데이트 알림창 UI를 구현해서 렌더링해야한다.

이와 달리 checkForUpdates를 사용하면 사용자에게 별도의 알림 없이 업데이트를 진행하게 된다. 흔히 말하는 잠수함 패치와 같은 것으로 보면 된다. 여기서 주의해야 할 점은 업데이트를 진행한다는 것은 업데이트 버전 파일만 다운로드하는 것이다. 업데이트된 파일을 실행하려면 프로그램을 종료한 후에 다시 실행해야 한다.

이를 위해 유저가 직접 프로그램을 종료한 후에 다시 실행하는 방법도 있지만, 업데이트 다운로드 완료 이후에 바로 업데이트 된 파일을 실행하고 싶다면 다운로드 완료 시점에 quitAndInstall 메소드를 호출하면 된다.

그리고 macOS 앱은 일반적으로 닫기 버튼을 클릭해도 애플리케이션이 완전하게 종료되는 것이 아니라 'active' 상태로 있다. 위와 같이 앱에 흰색 dot이 표시가 되어 있으면 'active' 상태라고 할 수 있다.

이처럼 macOS 전용 데스크톱앱은 기본적으로 close와 quit 액션이 나뉘어 있어서 electron에서도 두 가지 액션에 대한 가이드를 주고 있다. 닫기 버튼을 클릭해서 윈도우 창이 닫힐 때(close) 앱이 종료되지(quit) 않도록 데스크탑앱을 개발해야 한다. electron 앱에서는 디폴트로 닫기 버튼을 클릭하면 앱이 종료되는데, macOS에서는 앱을 종료하지 않도록 'window-all-closed' 이벤트에서 예외처리를 해줘야 한다.

위에서 언급한 'active' 된 상태는 macOS 운영체제에서만 있는 상태이므로 electron 공식 문서에도 보면 'activate'라는 이벤트가 macOS 전용으로 있는 것을 확인할 수 있다. 그래서 자동 업데이트 여부 체크하는 코드를 'activate' 이벤트가 발생했을 때도 추가해줘야 한다. 그렇지 않으면 앱을 종료하고 다시 실행했을 때만 자동 업데이트 여부가 체크된다.

checkForUpdates 함수는 앱이 실행됐을 때 한 번 호출되기 때문에 앱이 실행 중일 때 업데이트를 지속적으로 감지하려면 setInterval을 통해 업데이트 여부를 주기적으로 체크해 주는 코드를 추가하면 된다.

위 내용을 바탕으로 electron-updater를 활용한 자동 업데이트 기능 구현 코드는 아래와 같다.

import { app, shell, BrowserWindow } from 'electron'
import { join } from 'path'
import { electronApp, optimizer, is } from '@electron-toolkit/utils'
import { autoUpdater } from 'electron-updater' //  추가
import log from 'electron-log' //  추가

function createWindow(): void {
  //...생략
}

/**  자동 업데이트 log start **/
autoUpdater.on('checking-for-update', () => {
  log.info('checking-for-update')
})
autoUpdater.on('update-available', () => {
  log.info('update-available')
})
autoUpdater.on('update-not-available', () => {
  log.info('update-not-available')
})
autoUpdater.on('error', (err) => {
  log.info('error : ' + err)
})
autoUpdater.on('download-progress', (progressObj) => {
  const log_message = 'download: ' + progressObj.percent + '%'
  log.info(log_message)
})
/**  자동 업데이트 log end **/

autoUpdater.on('update-downloaded', () => {
  log.info('update-downloaded')
  //   업데이트 파일 자동 다운로드 이후 애플리케이션 종료하고 다시 실행
  autoUpdater.quitAndInstall() 
})

app.whenReady().then(() => {
  electronApp.setAppUserModelId('com.electron')

  app.on('browser-window-created', (_, window) => {
    optimizer.watchWindowShortcuts(window)
  })


  //  자동 업데이트 등록 
  autoUpdater.checkForUpdates()
  /**
  주기적으로 업데이트 감지하려면 아래와 같이 코드 작성
  setInterval(() => {
  	autoUpdater.checkForUpdates()
  }, 30000)
  */

  createWindow()

  app.on('activate', () => {
    if (BrowserWindow.getAllWindows().length === 0) {
		autoUpdater.checkForUpdates() //  mac os용
		createWindow()
  })
})

app.on('window-all-closed', () => {
  if (process.platform !== 'darwin') {
    app.quit()
  }
})

그리고 위 코드를 보면 electron-log를 활용한 부분을 볼 수 있다. 자동 업데이트에 대한 로그를 쉽게 볼 수 있도록 위와 같이 로깅 작업을 해두면 좋다. 로그 파일은 아래와 같은 위치에서 확인할 수 있다.

on Linux: ~/.config/{app name}/logs/{process type}.log
on macOS: ~/Library/Logs/{app name}/{process type}.log
on Windows: %USERPROFILE%\AppData\Roaming\{app name}\logs\{process type}.log

Electron Code Signing (코드 서명)

xiubin — Fri, 25 Aug 2023 16:10:45 +0900

내 맥북에서는 잘 되는데 다른 사람 맥북에서는 실행이 안되네?
윈도우에서 실행은 가능한데 SmartScreen filter에 걸리네?

데스크탑 앱을 처음 만들어 보는 사람이라면 위와 같은 상황을 모두 한 번 쯤은 겪어봤을 것이다. 나 역시 그랬다

이번에 Electron으로 데스크탑 앱을 만들어야했는데, 데스크탑 앱 개발에 대한 기본 지식이 부족한 상황이었다. electron-vite를 사용해서 개발 환경을 구축하는데는 무리가 없었지만, 역시나 예상대로 빌드와 배포를 하는데 엄청난 시간과 노력이 필요했다.

위 문제를 해결하는데도 며칠 동안 리서치하며 해결방안을 찾아냈다. 위 문제의 정답은 코드 서명에 있었다.

코드 서명이란?

코드 서명(Code Signing)은 실행 파일과 스크립트에 디지털 서명을 하는 과정으로, 서명 이후에 코드가 변조되거나 손상되지 않음을 보장한다. 진위와 무결성 확인을 위해 암호화 해시를 사용한다. 코드 서명을 하지 않으면 각 운영 체제에서 보안 검사가 트리거되어 제대로 앱이 실행되지 않을 수 있다.

코드 서명을 해야하는 이유

(1) windows에서 앱 실행 방지 (2) macOS에서 앱 실행 방지

(3) 브라우저에서 실행 파일 다운로드 경고

패키징을 완료한 앱을 사용자들에게 배포했을 때 위 화면과 같이 운영 체제 보안 검사를 트리거하지 않도록 앱에 서명해야 한다. Windows와 macOS는 기본적으로 서명되지 않은 응용 프로그램의 다운로드 또는 실행을 방지한다. Windows에서는 인증서가 없거나 신뢰 수준이 낮은 경우 사용자가 앱을 실행하려고 할 때 보안 경고창이 표시된다. macOS에서 시스템은 변경 사항이 실수로 도입되었는지 또는 악성 코드에 의해 도입되었는지 여부에 관계없이 앱에 대한 모든 변경 사항을 감지할 수 있다. 서명되지 않은 앱을 배포할 수는 있지만 권장하지 않는다. macOS Catalina(버전 10.15)부터 사용자는 서명되지 않은 앱을 열려면 여러 수동 단계를 거쳐야 한다.

그리고 코드 서명을 해야 하는 가장 큰 이유는 macOS의 경우 코드 서명을 하지 않으면 자동 업데이트가 불가능하다는 것이다. 진행중인 프로젝트에서 구현해야 할 기능 중에 electron 앱의 자동 업데이트 기능이 있기 때문에 코드 서명을 꼭 진행해야 했다.

macOS 앱 코드 서명 하는 방법

macOS에는 애플리케이션 배포를 위한 두 가지 보안 기술인 코드 서명(code signing) 및 공증(notarization)이 있다. 코드 서명은 앱 작성자의 신원을 인증하고 배포 전에 변조되지 않았는지 확인하는 행위이고, 공증은 자동화된 malware 검사를 위해 앱을 Apple 서버로 보내는 추가 확인 단계이다.

Mac App Store(MAS) 외부에 배포될 앱은 반드시 코드 서명이 되어있어야 한다. macOS 10.15(Catalina)부터 운영 체제 보안 검사를 비활성화하지 않고 사용자 컴퓨터에서 실행하려면 응용 프로그램에 코드 서명 및 공증이 모두 필요하다. Mac App Store(MAS)에 배포하는 앱은 MAS 제출 프로세스에 공증과 유사한 자동 검사가 포함되기 때문에 공증이 필요하지 않다.

macOS 앱은 MAS에 배포하는 것과 MAS 외부에 배포하는 것으로 나뉘는데, 아래에서는 외부에 배포하는 것을 기준으로 macOS(darwin) 애플리케이션 파일(.app)에 코드 서명과 공증하는 방법을 안내하고자 한다.

1. Developer ID Application certificate 생성

macOS 앱용 코드 서명 인증서는 Apple Developer Program 멤버십을 구입하여 Apple을 통해서만 얻을 수 있다. 인증서 타입은 여러 가지가 있는데 Electron 앱에 코드 서명 및 공증까지 하려면 Developer ID Application certificate가 필요하다. Developer ID Application certificate는 Mac App Store 외부에서 배포되는 앱에 서명하는 용도로 사용한다. 만약 다른 타입의 인증서로 코드 서명을 하면 공증에 실패한다.

https://www.rocketride.io/blog/macos-code-sign-notarize-electron-app

How to code sign and notarize an electron app in 2022

8 steps to make your Electron app ready for distribution on Mac OS

www.rocketride.io

인증서 생성 단계를 스크린샷과 함께 구체적으로 보고 싶다면 위 블로그를 참고하면 좋을 것 같다.

Apple Developer Program 멤버십을 구입한다.
인증서 서명 요청(CSR/CertificateSigningRequest.certSigningRequest) 파일을 생성하기 위해 맥북에서 '키체인 접근' 실행 후 상단 메뉴에서 '인증서 지원 > 인증기관에서 인증서 요청'을 선택한다. 이 파일은 코드 서명에 필요한 인증서를 생성하는데 필요하다.
입력창이 뜨면 애플 개발자 계정 이메일 및 이름을 작성하고 요청 항목에 ‘디스크에 저장’을 선택한다.
Developer ID Application 인증서를 생성하기 위해 애플 개발자 계정 사이트의 Certificates, IDs & Profiles 메뉴로 들어간다.
Certificates 메뉴에서 파란색 플러스 아이콘을 클릭하고, 목록에서 Developer ID Application 인증서를 선택한다.
다음 스텝에서 'Profile Type: G2 Sub-CA (Xcode 11.4.1 or later)' 선택하고, 2번 단계에서 받았던 인증서 서명 요청 파일(CSR)을 파일 업로드 항목에서 업로드해서 인증서 생성을 요청한다.
인증서 파일(developerID_application.cer) 다운로드 후 키체인에 등록한다.
키체인에 등록이 완료되면 아래와 같은 화면을 키체인 접근에서 확인할 수 있다.
인증서가 잘 설치 됐는지 터미널에서 security find-identity -p codesigning -v 명령어를 입력해서 사용 가능한 코드 서명 인증서가 있는지 확인한다.

키체인 등록 완료 화면

터미널 명령어 입력해서 코드 서명 가능 인증서 있는지 체크

2. electron-builder-config.js , entitlements.mac.plist 파일 작성

/* eslint-disable node/no-unpublished-require */
require('dotenv').config()

const config = {
  appId: 'com.electron.app',
  productName: 'app',
  directories: {
    buildResources: 'build'
  },
  artifactName: '${productName}-${os}-${arch}-latest.${ext}',
  //...생략
  mac: {
    target: [
      {
        target: 'default',
        arch: ['arm64', 'x64']
      }
    ],
    notarize: {
      teamId: process.env.APPLE_TEAM_ID
    },
    category: 'public.app-category.utilities',
    hardenedRuntime: true,
    gatekeeperAssess: true,
    entitlements: 'build/entitlements.mac.plist',
    entitlementsInherit: 'build/entitlements.mac.plist',
  }
}

module.exports = config

electron-builder-config,js 파일에 mac용 빌드 옵션 구성을 해준다.

hardendRuntime: macOS 앱에 대한 보안 보호 및 리소스 액세스를 관리하는 기능이고, 이것을 활성화해야 공증이 가능하다.
참고링크1, 참고링크2
gatekeeperAssess: 이 항목을 true로 설정하면 코드 서명을 했는지 @electron/osx-sign 패키지에서 검증해준다.
entitlements: entitlements란 macOS 에서 실행 파일에 특정 기능(예: 카메라,마이크 등 장치에 대한 엑세스)을 부여하는 권한이다. 이 권한들은 코드 서명 시에 저장된다. 여기에는 권한을 작성한 파일의 경로를 작성한다. entitlementsInherit란 배포 번들에 대한 보안 설정을 상속하는 하위 권한에 대한 경로이다.
참고링크1, 참고링크2, 참고링크3

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
  </dict>
</plist>

build 폴더에 위와 같이 entitlements 권한을 작성한 entitlements.mac.plist 파일을 생성한다.

3. build 실행 시 electron-builder 내부적으로 코드 서명 진행

진행 중인 프로젝트에서는 electron-builder를 사용해서 패키징과 배포를 진행하고 있다. 이 도구를 사용하게 된 이유에 대해서는 자동 업데이트 글에서 더 상세하게 작성하도록 하겠다. 아무튼 electron-builder는 내부적으로 @electron/osx-sign 패키지를 사용해서 코드 서명을 진행한다. 빌드 타임에 macOS의 keychain에서 유효한 인증서를 찾으면, @electron/osx-sign을 사용해서 코드 서명을 진행한다.

그리고 빌드 플랫폼에 따라 인증서를 자동으로 선택해 준다. mas일 경우 3rd Party Mac Developer Application: * (*) 인증서를 선택하고 darwin일 경우 Developer ID Application: * (*) 인증서를 선택해서 코드 서명을 한다.

(참고 링크)

"scripts": {
	"build:mac": "electron-vite build && electron-builder --mac --config electron-builder-config.js"
 }

package.json 에서 위와 같이 mac용 빌드 스크립트를 구성하고 빌드를 실행하면, electron-builder의 빌드 스크립트 중에 MacPackager.ts 스크립트 파일에서 코드 서명이 진행된다.

macOS 앱 공증하는 방법

공증은 앱 심사가 아니다. Apple 공증(Notarizaion) 서비스는 Developer ID 인증서로 서명한 소프트웨어에 악성 코드가 있는지 자동으로 스캔하고 보안 검사를 수행하는 시스템이다. 검사를 마치고 배포를 위해 내보낼 준비가 완료되면 Gatekeeper에서 소프트웨어가 공증을 받았음을 식별할 수 있도록 해당 소프트웨어에 티켓이 첨부된다.

한마디로 Gatekeeper가 MAS 외부에서 배포되는 앱이 안전한지 체크하고 사용자를 악성 코드로부터 보호해 주는 역할을 한다.

"앱스토어 외부에서 다운로드한 이 소프트웨어는 신뢰할 수 있습니다."라고 도장을 쾅쾅 찍어준다고 생각하면 된다.

사용자가 소프트웨어를 처음 설치하거나 실행할 때 공증을 받았음을 식별할 수 있는 티켓이 있으면 Gatekeeper에 Apple이 소프트웨어를 공증했음을 알려준다. 그런 다음 Gatekeeper는 초기 실행 알림 창에 설명 정보를 배치하여 사용자가 앱 실행 여부에 대해 정보에 입각한 선택을 할 수 있도록 돕는다.

공증이 완료된 실행파일을 처음 실행할 경우에는 아래와 같은 알림 창이 뜬다.

1. ASP(App-Specific-Password) 생성

App-Specific-Password는 공증에 사용하는 툴인 notarytool에 Apple 관련 자격 증명을 제공할 때 사용한다. 이것을 사용해서 공증하게 되면 Apple 이외의 개발자가 만든 앱에 안전하게 로그인할 수 있다.

https://appleid.apple.com/ 에 애플 개발자 계정으로 로그인
App-Specific-Password 생성 후 복사
env 파일에 Apple 관련 정보 입력

APPLE_ID = 애플_개발자_계정
APPLE_APP_SPECIFIC_PASSWORD = 생성된_App-Specific-Password 
APPLE_TEAM_ID = 애플_개발자_멤버십_팀_ID

2. electron-builder-config.js 파일에서 공증 옵션 추가

공식 문서에서 공증에 대한 블로그 포스팅 링크를 제공하길래 처음에는 포스팅 그대로 따라했었다. afterSign Hook에 직접 작성한 notarize.js 스크립트를 실행하도록 했다. 근데 멀티 아키텍쳐로 빌드 스크립트를 구성해서 실행하는데 첫 번째 아키텍처는 afterSign Hook이 잘 실행되는데, 두 번째 아키텍처는 afterSign Hook이 돌지 않고, electron-builder 빌드 스크립트 중 MacPackager 스크립트 파일이 실행되는데 심지어 공증할 때 notarytool을 사용하는 것이 아니라 altool을 사용하는 것이었다.

notarize: module:app-builder-lib/out/options/macOptions.NotarizeOptions | Boolean | “undefined” - Options to use for @electron/notarize (ref: https://github.com/electron/notarize). Supports both legacy and notarytool notarization tools. Use false to explicitly disable

이를 해결하기 위해 다시 공식 문서를 훑어보기 시작했고 Mac 빌드 옵션에 notarize 라는 것을 찾을 수 있었다. 하지만 옵션을 추가해도 공증 툴을 계속 altool을 사용하길래 원인이 무엇인지 파악하기 위해 electron-builder 의 MackPackager 스크립트 코드를 훑어보기 시작했다. 코드를 살펴보니 notarize 옵션을 추가할 때 반드시 teamId를 넣어야 notarytool이 실행되는 코드를 발견했다.

private generateNotarizeOptions(appPath: string, appleId: string, appleIdPassword: string): NotarizeOptions {
    const baseOptions = { appPath, appleId, appleIdPassword }
    const options = this.platformSpecificBuildOptions.notarize
    if (typeof options === "boolean") {
      return {
        ...baseOptions,
        tool: "legacy",
        appBundleId: this.appInfo.id,
      }
    }
    if (options?.teamId) { //  코드 핵심
      return {
        ...baseOptions,
        tool: "notarytool",
        teamId: options.teamId,
      }
    }
    return {
      ...baseOptions,
      tool: "legacy",
      appBundleId: options?.appBundleId || this.appInfo.id,
      ascProvider: options?.ascProvider || undefined,
    }
  }

위 코드를 보면 teamId가 옵션으로 들어와야지만 notarytool을 사용하는 것을 볼 수 있다.

/* eslint-disable node/no-unpublished-require */
require('dotenv').config()

const config = {
  appId: 'com.electron.app',
  productName: 'app',
  directories: {
    buildResources: 'build'
  },
  artifactName: '${productName}-${os}-${arch}-latest.${ext}',
  //...생략
  mac: {
    target: [
      {
        target: 'default',
        arch: ['arm64', 'x64']
      }
    ],
    //   아래 옵션 추가
    notarize: {
      teamId: process.env.APPLE_TEAM_ID
    },
    category: 'public.app-category.utilities',
    hardenedRuntime: true,
    gatekeeperAssess: true,
    entitlements: 'build/entitlements.mac.plist',
    entitlementsInherit: 'build/entitlements.mac.plist',
  }
}

module.exports = config

정리하자면 electron-builder에서 공증을 위해 내부적으로 @electron/notarize 패키지를 사용하고, 코드 서명 이후에 공증이 진행된다. 공증을 위해서는 mac 빌드 옵션에 위와 같이 notarize 옵션을 작성해주고 애플 개발자 멤버십 팀 id 를 입력해줘야한다.

빌드 실행 후 위와 같은 로그가 뜨면 코드 서명과 공증이 모두 완료된 것이다!

macOS 앱 코드 서명 및 공증 Trouble shooting

CloudKit query for test.app ... failed due to "Record not found".
Could not find base64 encoded ticket in response for ...
The staple and validate action failed! Error 65.

1. 다른 타입의 인증서(Apple Development)로 코드 서명 했을 때 에러 발생
➡️ 올바른 타입의 인증서(Developer ID Application)로 코드 서명하기

Notarizing using the legacy altool system. The altool system will be disabled on November 1 2023. Please switch to the notarytool system before then.
You can do this by setting "tool: notarytool" in your "@electron/notarize" options. Please note that the credentials options may be slightly different between tools.
Error: Failed to upload app to Apple's notarization servers

xcrun: error: unable to find utility "altool", not a developer tool or in PATH

2. electron/notarize 패키지 버전이 낮을 때("^1.2.3”) default로 설정된 공증 툴이 ‘altool’ 이어서 에러 발생
➡️ 해결 방법1: 최신 버전(2.1.0)으로 업그레이드 (electron-builder 24.6.3 버전 말고 24.6.4 버전 사용 필요)

➡️ 해결 방법2: 공증 옵션 중 tool을 ‘notarize’로 명시

3. 빌드된 실행파일의 아키텍처가 다를 경우 오류 발생

➡️ 아키텍처 별로 빌드할 수 있도록 수정

mac: {
    target: [
      {
        target: 'default',
        arch: ['arm64', 'x64']
      }
    ],
}

4. 키체인에서 코드 서명에 사용할 인증서가 신뢰되지 않은 인증서라고 표시

➡️ Apple Worldwide Developer Relations Certification Authority를 설치

macOS에서 Windows 앱 코드 서명하는 방법

Windows 앱을 서명할 수 있는 인증서는 EV 코드 서명 인증서, 코드 서명 인증서 두 가지 타입이 있다. 일반적인 코드 서명 인증서는 앱을 설치할 때 경고를 표시하는데, 이 경고는 충분한 사용자가 앱을 설치하고 신뢰가 쌓이면 사라진다고 한다. 그러나 EV 코드 서명 인증서는 경고 없이 즉시 실행 가능하다. 아래에서는 EV 코드 서명 인증서를 활용해서 서명하는 방법을 작성했다.

코드 서명 인증서 구매

Windows Authenticode 코드 서명 인증서는 다양한 업체에서 구매할 수 있고, 가격도 다양하다. 일반적인 코드 서명 인증서는 신뢰도가 쌓일 때까지 경고창을 띄우기 때문에, 회사에서는 Digicert에서 EV 코드 서명 인증서를 구매했다.

EV CodeSign 인증서

EV(Extended Validation) Codesign 인증서는 Microsoft의 SmartScreen 경고 메시지를 즉시 해제할 수 있고, 엄격한 심사 프로세스 및 하드웨어 보안 요구 사항이 포함되어 있기 때문에 최종 사용자의 신뢰도를 높일 수 있는 인증서이다.

하지만 가장 큰 단점은 코드 서명에 사용할 프라이빗키를 하드웨어 토큰 형식(ex. USB)으로 관리해야 한다는 것이다. 그래서 CI 프로세스에 사용하기 위해 키를 export 할 수가 없다.

Jsign을 사용해서 macOS에서 Windows 앱에 코드 서명하기

Unix에서 Windows 앱 서명이 지원된다. 이를 달성하기 위한 여러 가지 방법이 있다. 기본적으로 PKCS 11을 사용하여 코드에 서명할 수 있는 애플리케이션이 필요하다. 여기서 사용할 애플리케이션은 Jsign이다.

아래 electron-builder 공식 문서 내용을 참고해서 진행해보고자 한다.

https://www.electron.build/tutorials/code-signing-windows-apps-on-unix#signing-windows-app-on-maclinux-using-jsign

Sign a Windows app on macOS/Linux - electron-builder

Sign a Windows app on macOS/Linux Info Described setup and configuration is required only if you have EV code signing certificate. The regular certificates supported out of the box. Signing Windows apps on Unix is supported. There are multiple methods to a

www.electron.build

1. 코드 서명을 위한 사전 작업

Jsign 은 플랫폼 독립적인 Microsoft Authenticode의 Java 구현이며 Linux의 osslsigncode 및 Windows의 SignTool 또는 Unix 시스템의 Mono 개발 도구와 같은 기본 도구에 대한 대안을 제공한다.

Jsign을 사용해서 코드 서명을 하려면 Java를 설치해야 한다. 그리고 USB 토큰을 읽어서 코드 서명을 진행할 수 있는 클라이언트 툴이 필요하다.

safeNet Authentication Client 를 다운로드한다.
SafeNet Authentication Client Tools를 실행한다.
digicert USB 삽입 후 로그온을 진행해서 패스워드를 입력한다. 인증서의 패스워드는 반드시 비공개로 유지해야 한다.
루트 경로에 hardwareToken.cfg 파일 생성 후 아래 코드 작성한다.
library 경로는 PKCS 11 module을 가진 library의 경로인지 체크해 보고 작성한다.
Java를 설치(현재 14.0.2 설치) 하고 코드서명 툴인 Jsign 을 동일 경로에 설치한다.

// hardwareToken.cfg 파일
name = HardwareToken
library = /Library/Frameworks/eToken.framework/Versions/A/libeToken.dylib
slotListIndex = 0

2. 루트 경로에 sign.js 파일 생성

CERTIFICATE_NAME은 SafeNet Authentication Client Tools 실행 후 Issued To 에 해당하는 이름 입력
TOKEN_PASSWORD는 EV Codesign 인증서의 패스워드 입력

// eslint-disable-next-line node/no-unpublished-require
require('dotenv').config()

exports.default = async function (configuration) {
  // do not include passwords or other sensitive data in the file
  // rather create environment variables with sensitive data

  const CERTIFICATE_NAME = process.env.WINDOWS_SIGN_CERTIFICATE_NAME
  const TOKEN_PASSWORD = process.env.WINDOWS_SIGN_TOKEN_PASSWORD

  console.log('start sign')

  require('child_process').execSync(
    // your commande here ! For exemple and with JSign :
    `java -jar jsign-5.0.jar --keystore hardwareToken.cfg --storepass "${TOKEN_PASSWORD}" --storetype PKCS11 --tsaurl <http://timestamp.digicert.com> --alias "${CERTIFICATE_NAME}" "${configuration.path}"`,
    {
      stdio: 'inherit'
    }
  )
}

3. 빌드 옵션에 인증서 이름 작성 및 sign.js 파일 경로 추가

https://www.electron.build/configuration/win#WindowsConfiguration-certificateSubjectName

Any Windows Target - electron-builder

Any Windows Target The top-level win key contains set of options instructing electron-builder on how it should build Windows targets. These options applicable for any Windows target. target = nsis String | TargetConfiguration - The target package type: lis

www.electron.build

If you are using an EV Certificate, you need to provide win.certificateSubjectName in your electron-builder configuration.
certificateSubjectName String | “undefined” - The name of the subject of the signing certificate, which is often labeled with the field name issued to.

위 문서에 따르면 아래와 같이 빌드 옵션에 인증서의 이름을 작성하고, sign.js 파일 경로를 추가한다.

afterSign: build/notarize.js

//   인증서 이름 작성 및 sign 스크립트 경로 추가
win:
  executableName: sampleApp
  certificateSubjectName: CERT_NAME
  sign: ./sign.js

4. windows 전용 빌드 스크립트 추가 및 실행

    "build:win": "electron-vite build && electron-builder --win --x64 --config",

코드 서명을 완료하게 되면 위와 같은 로그가 뜬다. Adding Authenticode signature to ... 라는 문구가 나오면 코드 서명이 정상적으로 실행된 것으로 확인 가능하다. 그리고 앱을 실행해 보면 MS SmartScreen Filter에 걸리지 않고 정상적으로 실행된다.

Storybook과 Vitest에서 MSW 모킹 핸들러 재사용하기

xiubin — Fri, 18 Aug 2023 12:03:37 +0900

프론트엔드 개발자의 작업 능률은 Storybook과 MSW를 만나기 전과 후로 나뉜다고 할 수 있다. 프론트엔드 개발을 하면서 가장 불편한 점 중 하나가 백엔드 개발에 대한 의존성이 높다는 점이다. 백엔드 API가 완성되어야 데이터 처리를 진행할 수 있는데, 보통 UI 작업을 먼저 진행해도 백엔드 작업이 끝나기 전까지 대기하는 상황이 종종 있었다. 물론 Mocking 데이터를 직접 만들어서 UI가 제대로 렌더링 되는지 확인할 수는 있었지만 꽤나 번거로운 일이었다.

하지만 Storybook을 만나면서 백엔드 API 없이도 데이터에 대한 다양한 케이스를 만들어서 미리 정확한 UI를 만들어 보며 시각적 테스트를 진행할 수 있게 됐다. 그리고 MSW를 도입하면서 API가 완성되지 않아도 백엔드팀에서 Schema만 받을 수 있다면 데이터 처리 작업도 수월하게 진행할 수 있었다. API 리스폰스를 직접 변경하면서 다양한 케이스의 UI를 바로 확인하면서 효율적으로 개발할 수 있었다.

그리고 훌륭한 두 가지 도구에 Vitest 라는 테스트 러너를 기반으로 테스트 코드를 작성하게 됐는데, 여기서 문제점이 발생했다. Storybook과 테스트 파일에서 MSW로 모킹하는 코드가 중복으로 작성되고 있었다. 이를 해결하기 위해 Storybook에서 작성한 Story 컴포넌트를 Vitest 테스트에서 재활용하고, 중복 작성된 MSW 코드를 제외하고 테스트 코드를 깔끔하게 정리한 방법을 아래에서 소개하도록 하겠다.

프로젝트 환경

electron-vite + React + TypeScript

테스트 코드 작성 흐름

시각적 테스트
- Storybook에 Story 작성
- Story에 MSW 모킹 코드 추가
컴포넌트 단위 통합 테스트
- Vitest 기반 test 파일에서 작성한 Story Import 해서 재사용
- 스토리에 추가된 MSW 모킹 재사용

테스트 도구 설치

yarn add -D vitest @storybook/testing-react @testing-library/jest-dom @testing-library/react jsdom msw-storybook-addon

Vitest : Vite 환경에서 테스트를 진행할수 있도록 도와주는 프레임워크 (Jest와 호환)
@testing-library/jest-dom : Dom 요소 matcher를 제공하는 라이브러리
@testing-library/react : React 컴포넌트를 테스팅할 수 있도록 도와주는 라이브러리
msw-storybook-addon : Storybook에서 MSW 모킹을 도와주는 라이브러리
@storybook/testing-react : 단위 테스트에서 스토리를 재사용 할 수 있도록 도와주는 라이브러리
jsdom : node 환경에서도 브라우저 환경을 테스트할 수 있도록 Dom 구현체를 제공해 주는 라이브러리

Vitest Configuration

import { defineConfig } from 'vitest/config'
import { resolve } from 'path'

export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: 'vitest-setup.ts',
    alias: {
      '@renderer': resolve('src/renderer/src')
    }
  },
  build: {
    rollupOptions: {
      input: {
        index: resolve(__dirname, 'src/renderer/index.html')
      }
    },
    sourcemap: true
  }
})

.storybook/preview.tsx

Vitest의 주요 장점 중 하나는 Vite와의 통합 구성이 가능하다는 것이다. Vitest를 사용하기 전에 Vite 환경에 Jest를 사용해보려고 했는데 Jest를 실행하기 위해 여러 디펜던시들이 필요했고, 설정도 Vitest보다 복잡했다. 그래서 차라리 Vite 환경에는 Vitest를 사용하는 것이 더 적합하다는 생각이 들었다.

간단하게 vite.config.ts 파일에서 test 프로퍼티에 테스트 관련 옵션을 추가해 주면 테스트 가능한 환경이 된다. 또한, resolve.alias가 설정되어 있다면 그 설정 그대로 테스트 코드에서도 활용 가능하다.

하지만 현재 프로젝트에서 사용하는 electron-vite에서 vitest 설정을 지원하지 않고 있다. (관련 Github Issue)

따라서 기존 vite configuration 파일이었던 electron.vite.config.ts 에서 테스팅 관련 설정이 불가하므로 vite.config.ts 파일을 생성해서 테스팅 및 빌드 관련 옵션을 추가해줘야 한다.

build 프로퍼티의 rollupOptions에서 entryPoint를 지정해 준다.
test 프로퍼티에 Vitest 관련 옵션을 추가한다.
- globals: vitest는 글로벌 API를 기본적으로 제공하지 않는다. 하지만 Jest와 같이 describe, it, expect 함수를 글로벌로 사용하고 싶다면 true로 설정해 준다. 그리고 타입스크립트가 작동하려면 tsconfig.json에 types 필드에 vitest/globals를 추가해 준다.
- environment: vitest는 기본적으로 node 환경에서 실행되기 때문에 브라우저 환경을 테스트하기 위해서는 jsdom으로 설정해줘야 한다.
- setupFiles: 테스트 전에 실행되는 파일의 경로이다.
- alias: 테스트 파일에서 사용할 경로 별칭을 설정해 줄 수 있다.

Storybook에서 MSW 사용하기

1. MSW 초기화 함수 실행 및 MSW addon loader를 글로벌하게 제공하도록 설정한다.

import React from 'react'
import type { Preview } from '@storybook/react'
import '../src/renderer/src/config/index.css'
import { initialize, mswLoader } from 'msw-storybook-addon'
import { handlers } from '../src/renderer/src/mocks/handler'
import SampleProvider from '../SampleProvider'

initialize()

const preview: Preview = {
  parameters: {
    msw: {
      handlers //optional
    }
  },
  loaders: [mswLoader],
  decorators: [
    (Story) => (
      <SampleProvider>
        <Story />
      </SampleProvider>
    )
  ]
}

export default preview

.storybook/preview.tsx

msw-storybook-addon의 initialize 함수 호출해서 스토리북에서 MSW를 사용할 수 있도록 MSW를 초기화해 준다.

만약 전체 스토리에서 전역적으로 필요한 리퀘스트 핸들러가 있다면, parameters 속성에서 MSW로 모킹한 리퀘스트 핸들러들을 넣어준다. 그렇지 않다면 이 속성은 생략해 준다.

그리고 MSW addon loader를 글로벌하게 제공하도록 loaders에 addon을 추가한다.

번외로 Storybook에서 Context Provider를 사용하는 법은 decorators를 활용하면 된다. decorators는 스토리에 필요한 요소들로 감싸서 렌더링 하는 데 사용된다. 이를 활용해서 글로벌로 Context Provider로 감싸서 스토리를 렌더링 하면 스토리에서 context에 접근할 수 있다.

2. Storybook에서 기존에 사용하던 service worker 파일을 읽을 수 있도록 static 파일 경로 설정을 해준다.

import type { StorybookConfig } from '@storybook/react-vite'

const config: StorybookConfig = {
  staticDirs: ['../src/renderer'], 
}
export default config

.storybook/main.ts

electron-vite에서 제공하는 템플릿에서 정적 에셋을 담는 폴더는 src/renderer 폴더에 해당하므로 service worker 등록에 필요한 파일은 여기에 위치해 있다. 따라서 Storybook 역시 정적 에셋 폴더 위치를 동일한 위치로 지정해야 MSW가 작동할 수 있다.

보통 React 애플리케이션은 npx msw init public/ 명령어를 통해 public 폴더에 생성한다.

3. MSW를 브라우저와 노드 환경에 따라 실행되도록 구성한다.

동일한 리퀘스트 핸들러를 공유할 수 있지만 실행되는 환경마다 다르게 프로세스를 구성한다.

import { setupServer } from 'msw/node'
import { handlers } from '../../mocks/handlers'

export const server = setupServer(...handlers)

server.ts

import { setupWorker } from 'msw'
import { handlers } from '../../mocks/handlers'

export const worker = setupWorker(...handlers)

browser.ts

위와 같이 노드와 브라우저 각각 서비스 워커를 별도로 등록해 준다.

import '@testing-library/jest-dom'
import { server } from './src/renderer/src/test/env/server'

beforeAll(() => server.listen({ onUnhandledRequest: 'error' }))

afterAll(() => server.close())

afterEach(() => server.resetHandlers())

vitest-setup.ts

테스트 별로 모킹에 의한 사이드 이펙트를 없애기 위해 테스트 수행 후 모킹한 핸들러를 초기화하는 코드를 작성한다.

그리고 이 파일을 각 테스트마다 실행할 수 있도록 vite.config.ts 파일에서 setupFiles에 위 파일 경로를 작성해 준다.

import { worker } from './test/env/browser'

if (process.env.NODE_ENV === 'development') {
  worker.start()
}

src/renderer/src/main.tsx

브라우저에서 실행할 서비스 워커는 렌더러 폴더의 main 파일에서 등록해 준다.

4. 스토리에서 MSW 모킹 하는 코드를 추가한다.

import Sample from './Sample'
import { sampleHandlers } from '@renderer/mocks/handlers/sample-handler'

export const Default: Story = {
  render: (args) => <Sample />
  parameters: {
    msw: {
      handlers: sampleHandlers
    }
  }
}

sample.stories

parameters에 스토리에서 필요한 모킹 핸들러를 추가해 준다. 위와 같이 작성하면 컴포넌트 내부에서 API를 호출했을 때 MSW가 가로채서 모킹 한 리스폰스로 응답한다.

테스트에 사용할 customRender 함수 생성

전역으로 공급되는 요소들을 매번 테스트 코드에 작성하기 불편하므로 render 함수를 커스텀해서 사용하는 것이 좋다. 아래에서는 @testing-library/react의 render 함수를 래핑하는 customRender 함수를 생성해서 export 해서 사용한다.

import { RenderOptions, render } from '@testing-library/react'
import { server } from '../env/server'
import SampleProvider from '../SampleProvider'

function mockStoryHandlers(story) {
  server.use(...(story.type.parameters?.msw?.handlers || []))
}

interface IProvidersProps {
  children: React.ReactElement
}

const AllTheProviders = ({ children }: IProvidersProps) => {
  return (
    <SampleProvider>
		{children}
    </SampleProvider>
  )
}

const customRender = (ui: React.ReactElement, options?: Omit<RenderOptions, 'queries'>) => {
  mockStoryHandlers(ui)
  return render(ui, { wrapper: AllTheProviders, ...options })
}

export * from '@testing-library/react'

export { customRender as render }

mockStoryHandlers 함수를 통해 테스트할 스토리에 parameters?.msw?.handlers 가 있는지 확인하고 스토리에서 사용한 API를 모킹하도록 한다.
Context Provider로 렌더링 할 요소를 감싸준다.

VITEST에서 MSW 사용 및 Story 재사용

import { render, waitFor } from '@renderer/test/utils/test-utils'
import { composeStories } from '@storybook/testing-react'
import * as SampleStories from './Sample.stories'

const { SampleAmpty } = composeStories(SampleStories)

describe('Sample', () => {
  test('Sample 리스트가 없는 경우 빈 화면을 표시한다', async () => {
    const { getByText } = render(<SampleAmpty />)
    await waitFor(() => expect(getByText('Empty')).toBeInTheDocument())
  })
})

composeStories 함수를 통해 테스트에서 스토리 컴포넌트를 재사용할 수 있도록 변환해 준다.
위에서 만들었던 customRender 함수로 렌더링을 해서 MSW 모킹 코드를 재사용하고 context를 전역적으로 사용할 수 있도록 한다.

좋은 도구들을 최대한 활용해서 개발 능률을 최대치로 끌어올려보자!

참고 자료

https://fe-developers.kakaoent.com/2022/220317-integrate-msw-storybook-jest/

https://testing-library.com/docs/react-testing-library/setup/#custom-render

https://mswjs.io/docs/getting-started/integrate

https://storybook.js.org/addons/msw-storybook-addon

https://blog.mathpresso.com/msw로-api-모킹하기-2d8a803c3d5c

https://vitest.dev/guide/

React 프로젝트 구조 설계를 넘어서 프론트엔드 아키텍처 설계에 대한 고찰

xiubin — Fri, 19 May 2023 17:52:00 +0900

React 폴더 구조를 어떻게 구성할까?
비즈니스 로직은 어떻게 분리할까?

React와 같은 라이브러리로 신규 서비스를 개발하게 되면 프론트엔드 팀에서 가장 첫 번째로 고민해야 할 요소는 프로젝트의 폴더 구조라고 생각한다. Next.js와 같은 프레임워크로 개발을 하게 되면 폴더 구조가 어느 정도는 정해져있기 때문에 고민해야 할 부분이 비교적 적다. 하지만 React의 경우에는 정해진 폴더 구조는 없고 일반적인 접근 방식만을 제안하고 있다. 따라서 개발자에 따라서 프로젝트 설계 방법이 천차만별일 것이고 설계에 정답은 없다.

1년 차때는 프론트엔드 프로젝트 구조 설계에 대해 깊은 고민을 하지 않고 내가 자주 쓰고 익숙한 패턴을 그대로 가져다가 새로운 서비스에 적용하곤 했다. 하지만 10년 차 동료 개발자가 프론트엔드 구조 설계에 있어서 충분히 고민하고 우리 비즈니스에 적합한 구조로 설계하는 것을 보게 됐다. 이를 통해 프론트엔드 아키텍처를 설계할 때 좋은 설계가 어떤 것인지 조금은 알게 됐다.

이번 글에서는 React 프로젝트 구조 설계에 DDD(도메인 주도 설계)를 기반으로 한 Structure based on Feature를 사용해보며 느꼈던 점과 프론트엔드에서 좋은 아키텍처 설계란 무엇일까에 대한 고찰을 작성해보고자 한다.

DDD(Domain Driven Design)란?

소프트웨어의 본질은 해당 소프트웨어 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다.

DDD(Domain Driven Design)란 도메인 주도 설계 라고 하며, 말 그대로 도메인을 중심으로 설계하는 방법이다.

https://vueschool.io/articles/vuejs-tutorials/domain-driven-design-in-nuxt-apps/

여기서 도메인이란 소프트웨어로 해결하고자 하는 문제 영역(problem domain)을 의미한다. 예를 들어 온라인 쇼핑몰이라는 큰 서비스에서 결제, 주문, 배송 등과 같이 전체 서비스를 분리한 각각의 비즈니스 영역을 의미한다. 그리고 이렇게 분리한 도메인을 중심으로 설계하는 것을 도메인 주도 설계라고 한다.

DDD의 주요 설계 원칙은 Loose Coupling(느슨한 결합)과 High Cohesion(높은 응집)이다. 도메인들 간에는 느슨한 결합을 하고 도메인 내에서는 높은 응집을 해야한다. 이를 위해 도메인을 잘 분리해야 하는 것이 필수적이다.

DDD와 Hexagonal Architecture

The hexagonal architecture, or ports and adapters architecture, is an architectural pattern used in software design. It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters. This makes components exchangeable at any level and facilitates test automation.

Hexagonal Architecture의 핵심은 관심사의 분리를 통해 유연한 소프트웨어를 만드는 것이라고 할 수 있다. DDD의 원칙에 헥사고날 아키텍처를 사용한다면 도메인을 중심으로 설계하면서 계층간의 분리로 인해 시스템의 확장성을 높일 수 있다.

https://www.youtube.com/watch?v=FeDBlSBPUz8

헥사고날 아키텍처에서 의존성은 바깥에서 안으로 단방향 의존성을 가지며 어댑터를 통해서만 인프라 영역에 접근할 수 있게 된다. 이와 같이 어댑터 요소가 생김으로써 애플리케이션의 외부 인터페이스를 비교적 자유롭게 교체할 수 있는 유연함을 가지게 된다.

UI (Presentaion) Layer : 애플리케이션과의 커뮤니케이션을 담당하는 계층이다. 쉽게 말해 일반적인 UI 컴포넌트라고 보면 된다. 예로 React UI 컴포넌트들의 구성이라고 할 수 있다.
Adapter Layer: Redux가 이 계층에 해당한다. 어댑터는 포트와 애플리케이션 코어 간의 요청과 응답을 변환하는 역할을 한다. 예를 들어 Redux를 활용해서 UI에서 사용할 state와 action을 정의한다고 볼 수 있다.
Infrastructure Layer: 레이어 간의 커뮤니케이션을 책임진다. 예를 들어 서버와 통신하는 구현체를 인프라 레이어에 두게 되면 도메인이나 애플리케이션에 의존하는 구조를 만들 수 있다. 그리고 예를 들어 data fetching 기술을 fetch API를 사용하다가 이것을 Axios 라이브러리로 변경할 수 있는 작업이 용이해지고 안쪽 레이어에 영향을 최소화시킬 수 있다.
Application Layer: 비즈니스 로직이 들어있는 Use Cases들의 집합이다. 예를 들어 온라인 쇼핑몰에서 ‘카트에 추가하기’ 라는 유스 케이스에서 발생하는 액션들을 구현한다.
Domain Layer: 도메인과 관련된 객체들의 집합이다. 도메인 레이어의 핵심은 외부로부터 독립적이라는 것이다. 예를 들어 온라인 쇼핑몰의 ‘카트에 추가하기’ 기능에서 유저 스스로 카트 추가 버튼을 눌러서 아이템이 추가됐는지 또는 프로모션 코드를 통해 자동으로 아이템이 카트에 추가됐는지는 도메인 레이어에서 신경 쓰지 않는다. 도메인 레이어에서는 추가할 아이템을 받아서 카트 아이템을 업데이트해주기만 하면 된다.

React 프로젝트 폴더 구조에 DDD를 적용해보자

우리 팀에서 사용한 프로젝트 폴더 구조는 DDD를 기반으로 한 ‘Structure based on Feature’이다. 이 폴더 구조는 동료 개발자와 함께 이 링크를 참조해서 설계를 진행했다. Structure based on Feature 구조에서 키포인트는 도메인 별로 폴더를 분리해서 도메인 내의 응집성을 높이고 서로 다른 도메인 간의 의존도를 낮추는 것이다.

이를 적용한 React 프로젝트 폴더 구조는 아래와 같다.

src/
|-- assets/
|-- components/
|-- config/
|-- constants/
|-- features/
|   |-- user/
|   |   |-- api/
|   |   |-- assets/
|   |   |-- data/
|   |   |-- hooks/
|   |   |-- pages/
|   |   |-- routes/
|   |   |-- utils/
|   |   |-- views/
|-- hooks/
|-- layout/
|-- pages/
|-- routes/
|-- styles/
|-- utils/
|-- App.tsx
|-- index.html

assets: 공통으로 사용하는 이미지, 폰트 등
components: 디자인 시스템에 기반한 공통으로 재사용하는 컴포넌트
features: 도메인별 집합 폴더
- api: 도메인에서 사용하는 api
- assets: 도메인에서 사용하는 이미지, 비디오 등
- data: 도메인에서 사용하는 swr 데이터 (상태 관리 도구에 따라 store, contexts 등 다양한 명칭 가능)
- hooks: 도메인에서 사용하는 react hook
- pages: 도메인 routes path와 맵핑되는 페이지
- routes: 도메인별 routes
- utils: 도메인에서 사용하는 유틸리티 함수
- views: 도메인 페이지에 사용되는 컴포넌트
hooks: 공통으로 사용하는 react hook
layout: 장치별(PC/Mobile) 레이아웃 컴포넌트
pages: 정적 콘텐츠 페이지들 집합 폴더
routes: 최상위 및 하위 도메인 경로 맵핑
styles: 전역 스타일
utils: 공통으로 사용하는 유틸리티 함수 및 객체

서비스를 운영해 보며 느낀 DDD기반 Structure based on Feature 구조의 장점

1. 유지보수 및 확장에 용이하다

도메인 별로 유지보수 작업이 용이하다. 현재 프로젝트에서 도메인 별로 R&R을 했기 때문에 수정사항이 생겨도 작업하기 수월하다. 또한, 기존 작업자가 공백이 생겨 다른 작업자가 해당 도메인을 맡게 됐을 때도 그 도메인에 대한 이해만 한다면 유지보수에 용이하다.

그리고 도메인 간에 결합이 낮기 때문에 여러 개발자들이 동시에 서로 다른 기능을 개발할 때 각자의 개발 영역이 다른 개발 영역에 미치는 영향이 낮다. 현재 운영 중인 프로젝트의 경우 동시다발적으로 신규 기능이 추가되거나 기존 기능 수정사항 요청이 많은 상황이다. 따라서 각자의 맡은 도메인 영역이 다른 도메인에 주는 영향을 최소화하며 사이드이펙트를 줄일 수 있다.

그리고 추후 특정 도메인을 별도로 분리해서 배포하고자 하는 니즈가 있는 것으로 파악되기 때문에 DDD를 적용한 프로젝트는 확장성 측면에서도 좋다.

2. 협업에 있어서 커뮤니케이션이 원활하다

협업에는 항상 커뮤니케이션이 따라오는데 서로 같은 용어를 사용하더라도 다르게 이해할 수 있다. 예를 들어 온라인 쇼핑몰 비즈니스에서 Product라는 용어가 있다고 가정하자. Order 도메인을 다루는 팀은 Product를 바라볼 때 가격이나 재고 상품의 옵션을 볼 수 있고, Customer Support 도메인을 다루는 팀은 제품의 배송기간이나 평점을 보게 된다. 이처럼 같은 용어에 대해 서로 다른 관점으로 바라보게 되면 커뮤니케이션에 혼동이 올 수 있다. 하지만 DDD의 핵심 중 하나인 유비쿼터스 언어를 활용하게 되면 커뮤니케이션의 어려움을 낮출 수 있다.

유비쿼터스 언어란 특정 도메인에서 특정 용어가 해당 도메인에서의 의도를 명확히 반영하고 핵심 개념을 잘 전달할 수 있는 언어이다. 그리고 모든 구성원들이 같은 용어에 대해 같은 것을 바라보는 것이 핵심이다. 용어가 정의될 때마다 용어 사전에 기록하고 명확하게 정의함으로써 모든 구성원이 공유해야 한다.

이처럼 도메인에서 사용하는 용어를 코드에 반영함으로써 개발자에게 코드의 의미를 해석해야 하는 부담을 줄여주고 코드의 가독성을 높이고 이해하는 시간을 절약할 수 있다. 특히 업계 특성상 일반적이지 않은 용어들이 많은데 이러한 용어들을 명확히 정의하고 코드에 사용하면 개발자가 비즈니스 이해도를 높이는 동시에 타직군과의 커뮤니케이션도 원활하게 진행될 수 있다.

서비스를 운영해 보며 느낀 아쉬운 점

1. 유비쿼터스 언어 사전을 만들지 못했다

프론트엔드 팀에서는 비즈니스 이해도를 기반으로 도메인을 분리하고 유비쿼터스 언어를 코드에 반영했다. 하지만 비즈니스라는 것이 중간에 바뀌지 말란 법이 없기 때문에, 특정 도메인에서 사용했던 용어가 개념은 같지만 용어가 바뀐 경우도 발생했다. 이런 경우 코드에 사용한 유비쿼터스 언어를 모두 교체해줘야 하는데 시간에 쫓겨 그렇지 못한 상황이 생겼다.

그리고 서비스들이 추가되면서 유비쿼터스 언어들이 많이 늘어났는데 실무자들이 그것에 대해 정확히 인지를 하지 못하고 기획, 서버, 프런트 각각 다른 용어를 사용하면서 커뮤니케이션에 혼선이 생기기도 했다. 유비쿼터스 언어 사전을 만들어서 프로젝트를 진행했다면 좋았겠다는 아쉬움이 남는다.

2. 특정 도메인에 종속된 컴포넌트를 다른 도메인에서도 사용했다

예를 들어 user 도메인에서 사용하던 ‘스팸 메일함 확인’이라는 컴포넌트가 있었다. 그런데 이 컴포넌트가 다른 도메인에서도 동일하게 사용되어야 하는 케이스가 발생했다. DDD에 따르면 이런 경우는 공통 컴포넌트 쪽으로 해당 컴포넌트를 옮겼어야 했는데, 이를 지키지 못하고 user 도메인에서 export 해서 사용한 부분이 있다. 해당 부분은 추후 리팩토링을 해야겠다.

또 다른 프론트엔드 아키텍처 설계 방법론, FSD

FSD는 DDD와 견주어도 괜찮을 법 한 프론트엔드 아키텍처 설계 방법론이라고 생각한다. 이 방법론은 동료 개발자가 알려줬는데 처음에는 현재 프로젝트 구조와 비교해서 장점을 캐치하지 못했다. 하지만 문서를 전반적으로 읽어보니 비즈니스 요구 사항들이 빠르게 변화하고 추가되는 우리 회사 비즈니스에 적합한 방법론이라는 생각이 들었다.

Feature-Sliced Design (FSD)는 프론트엔드 애플리케이션을 스캐폴딩하기 위한 아키텍처 방법론이다. 이 방법론의 주요 목적은 끊임없이 변화하는 비즈니스 요구 사항에 직면하여 프로젝트를 더 이해하기 쉽고 체계적으로 만드는 것이다.

https://feature-sliced.design/

Welcome | Feature-Sliced Design

Architectural methodology for frontend projects

feature-sliced.design

FSD의 특징은 아래와 같다.

Explicit business logic: 도메인 범위 덕분에 쉽게 찾을 수 있는 아키텍처
Adaptability: 새로운 요구 사항에 따라 아키텍처 구성 요소를 유연하게 교체하고 추가할 수 있다.
Tech debt & Refactoring: 사이드이펙트 없이 각각의 모듈을 독립적으로 수정할 수 있다.
Explicit code reuse: DRY(Do not Repeat Yourself)와 로컬 맞춤형에서 밸런스를 유지할 수 있다.

FSD에서 프로젝트는 다음으로 구성된다. layers가 있고, 각 layer는 slices로 구성되고, 각 slice는 segments로 구성된다. 자세한 사항은 FSD 문서를 참조하면 좋고, 현재 우리 비즈니스에 어떻게 적용해 볼지 고민해 봤다.

React 프로젝트 폴더 구조 설계에 FSD를 적용해 봤다. 문서에 있는 예제들과는 살짝 다르게 각 레이어에서 최대한 도메인별로 분리를 했고, 레이어의 도메인마다 슬라이스를 생성하는 방향으로 설계해 봤다.

src/
|-- shared/
|   |-- ui/
|   |-- lib/
|   |   |-- utils/
|   |   |-- hooks/
|   |-- config/
|   |-- constants/
|   |-- types/
|-- entities/
|   |-- user/
|   |   |-- ui/
|   |   |-- model/
|   |   |-- lib/
|   |   |-- api/
|-- features/
|   |-- user/
|   |   |-- signup/
|   |   |-- signin/
|-- widgets/
|   |-- user/
|   |   |-- ui/
|   |   |   |-- profile/
|   |   |-- lib/
|-- pages/
|   |-- user/
|   |   |-- signup/
|-- app/
|   |-- styles/
|   |-- routes/
|   |-- assets/
|-- App.tsx
|-- index.html

이게 FSD의 정석은 아닐 수 있지만 비즈니스 요구 사항에 따라 체계적이고 깔끔하게 만들 수 있는 아키텍처 중 하나라고 생각이 든다. 새로운 프로젝트를 진행하거나 기존 프로젝트를 리팩터링 할 때 이 방법론을 사용해 보고자 한다. 사용해보고 이 방법론에 대해서는 또 어떤 것을 느꼈는지 언젠가 글을 남겨보려고 한다.

그래서 좋은 설계란 무엇일까?

아키텍처 설계 방법론은 굉장히 다양하고, 좋은 설계를 위한 원칙도 굉장히 많다.

내가 생각하는 좋은 설계란 프로그램을 유지보수하기 쉬운 설계라고 생각한다. 유지보수하기 쉽다는 것은 다양한 비즈니스 요구 사항에 맞춰서 확장 가능하고 유연하게 설계가 되어있다는 것이다. 그리고 이렇게 유지보수 하기 쉬운 설계는 구성원들 간의 커뮤니케이션을 도와주는 역할도 한다. 도메인에 대한 이해를 기반으로 좋은 설계를 하게 되면 서로 커뮤니케이션이 쉬워지고 끊임없이 변화하는 비즈니스에 따라 개발도 수월해질 것이다.

결국 좋은 설계를 위한 방법론들 중에서 정답은 없다고 생각한다. 어떤 설계 방법론이 옳은지 따지기 보다 개발을 용이하게 할 수 있도록, 비즈니스의 복잡도로 인한 개발에 드는 비용을 줄일 수 있도록 하는 것이 좋은 설계라고 생각한다. 설계는 코드를 작성하기 전에 팀원들과 함께 고민해서 큰 틀을 잡아두고, 지속적인 리팩토링을 통해 좋은 설계로 나아가면 될 것이다.

아래 문서를 참고하며 글을 작성했으며 보기를 꼭 추천드린다.

[컨퍼런스 리뷰 / 고퍼런스] Onboard your Life to the Web3

xiubin — Tue, 4 Apr 2023 12:12:25 +0900

Web3 업계에 종사하면서 프로젝트의 성공 요인 중에 하나는 커뮤니티라는 것을 크게 느끼고 있다. 이번 고퍼런스 역시 고스트 프로젝트의 커뮤니티를 좀 더 탄탄하게 만드는 동시에 더 확장할 수 있는 것을 목표로 한 것 같다. 고스트 프로젝트 홀더뿐만 아니라 비홀더까지 초청한 점이 눈에 띄었다. 강연과 네트워킹 시간을 적절히 섞어서 시간 분배를 잘 한 점도 눈에 띄었다. 그리고 단순한 친목 모임이 아니라 블록체인 지식을 쉽게 더 전파하기 위해 훌륭한 연사까지 초청했다! 그 모든 것을 NFT 홀더들이 직접 준비한 것도 정말 멋있었다.

고퍼런스와 같은 밋업이 많아져서 Web3 세상에 많은 사람들이 관심을 조금이라도 가진다면 Mass Adoption이 가능할 수 있다고 본다!

이번 고퍼런스에 대한 상세 내용은 아래에서 확인할 수 있다.

https://creative1y.notion.site/creative1y/Ghoference-Season2-2023-0ae2cf18426f4d15a27472d14a4a67fa

Ghoference Season2 (2023)

고퍼런스 시즌2: Onboard your Life to the Web3

creative1y.notion.site

고퍼런스를 주최한 홀더분의 인터뷰도 아래에서 확인할 수 있다.
https://kr.nestree.news/news/articleView.html?idxno=2913

홀더들이 자발적으로 완성한 웹3 콘퍼런스, ‘고퍼런스’ - 네스트리NFT뉴스

많은 전문가들이 꼽는 NFT 투자 요소 중 하나는 ‘탄탄한 커뮤니티’다. 홀더들을 팬으로 만들지 못하는 프로젝트는 금세 사그라들기 마련. 잠시 잠깐 빛이 나는 순간도 있지만, 오래가지 않는다

kr.nestree.news

12시 30분부터 식사 및 1차 네트워킹 시간이었는데 너무 일찍 도착하는 바람에 가보고 싶었던 샐러드 집에 왔다. 육회 샐러드라니!! 육회랑 아보카도랑 이렇게 잘 어울리다니,, 충격과 감동,, 소스도 너무 잘 만들었더라! 앞으로 자취하는 동안 내 최애 샐러드 집이 될 듯

행사장에 들어서자마자 눈을 사로잡는 포스터들과 굿즈들이 놓여있었다.

두둑이 먹고 1시쯤 도착했는데 아기자기한 포장박스에 샌드위치가 담겨 있었다. 세션 중간에 샌드위치 먹어봤는데 너무 맛있었다! 음료수뿐만 아니라 맥주까지 있더라 ㅋㅋㅋ 강연 시작 전에 네트워킹 시간이 있어서 나도 네트워킹에 참여해 봤다. 쟁글 팀원 분이랑 얘기도 나눠보고 국내 거래소, NFT 크리에이터까지 세션이 시작하기 전에도 즐거운 시간을 가질 수 있어서 좋았다.

해시드 라운지도 처음 와서 구경하고, 해시드 캠핑 의자 같은 것도 너무 귀엽고 편하고 ㅎㅎ

고퍼런스에서 굿즈를 나눠주는 이벤트도 진행했다. 트위터 인증하면 추첨해서 굿즈 주고, 연사 분들이 강연 중간에도 나눠주시기도 했다.

우리는 운 좋게도 굿즈를 3개나 받아왔다ㅋㅋㅋㅋ 반팔티, 후드티, 장패드 싹쓸이!

이번 오프라인 참석 규모는 120명이고 온라인은 40명 규모로 꽤나 크게 진행됐다.

다만 아쉬웠던 점은 연사 분의 목소리와 한쪽 공간에서 네트워킹 하시는 분들의 목소리가 뒤섞여서 약간 어수선한 분위기에서 강연이 진행됐다. 물론 연사 분의 목소리는 마이크를 사용해서 크기 때문에 더 잘 들렸지만 웅성 웅성하는 소리들이 강연 듣는 것에 조금 방해가 되긴 했다 :(

고퍼런스 첫 번째 연사는 이화체인 학회장인 IRENE님이 진행해 주셨다. 주제는 "학생의 시선에서 바라본 크립토 시장과 Web3 개발자의 삶" 으로 진행됐다. 블록체인 업계에서 Web3 개발자 학생에게 유리한 점과 학습 방법을 위주로 강연을 진행하셨다. 강연 내용은 아래와 같다.

1. 학생과 주니어에게 열려있는

- 학생 지원 프로그램들이 많다.

- 상대적으로 주니어들의 대기업 취업 입사 기회가 많고 연봉과 근무환경이 좋다.

2. 다양한 기회들

- 프로젝트 앰버서더, 펠러우쉽, 커피챗 등을 통해 프로젝트 협업, 채용 제안 등의 기회를 잡을 수 있다.

- 꾸준히 공부하면서 개인 미디어 활동 관리가 중요하다.

3. 커뮤니티를 통한 소중한 인연들

- 밋업, 홀더 커뮤니티, 커피챗 등을 통한 네트워킹이 많고 좋은 멘토, 파트너, 친구를 만들 수 있다.

4. 학습 방법 : 학회, 스터디, 교육 모임, 밋업

- 학회에서 공부하는 것을 추천한다. 커리큘럼과 함께 꾸준히 공부할 수 있고 프로젝트,해커톤,외부행사,연계 인턴십,학회원 네트워킹 등 다양한 기회가 많다.

- 지금 운영되고 있는 학회는 이화체인, 디사이퍼, BAY, 블록체인밸리, CURG 등이 있다.

- 스터디나 교육커뮤니티로는 루디움,붐랩스,블파스 등이 있다.

5. 학습 방법 : 온라인 공부

- 온라인 강의로는 Bildspace, Figment Learn, 각 체인별 리소스를 참고하면 좋다. 부트캠프로는 Encode Club이 있고, 기본 개념이나 리서치는 쟁글,a41,마마벤처스,Binance Academy, 암호화폐 정리노트(텔레그램채널), Jayplayco(텔레그램채널) 등을 참고하면 된다.

6. 학습 방법 : Web3 생태계에 직접 참여하기, 커리어 시작하기

- 소액 투자해서 Web3 서비스 단계별로 체험해 보는 것이 가장 직관적이고, 프로젝트 커뮤니티들에 참여해 보자.

- 직접 업계에서 일을 해보는 것이 최고의 방법이다. 많은 시간을 쏟아서 학습이 가능하고 트렌트를 빠르게 캐치할 수 있다.

다음 연사로는 해시드의 안수빈 님이 진행해 주셨고, 주제는 "Welcome to On-Chain Data World(Feat. Web3 DA Life)" 였다. 원래도 좋은 아티클을 많이 작성하시고 텔레그램 채널도 잘 구독하고 있어서 꼭 뵙고 싶었는데 이렇게 고퍼런스에서 뵙게 돼서 정말 영광이었다. 나랑 이름이 같아서 그런지 자꾸 비교하게 되는... 같은 안수빈이지만 정말 대단한 안수빈님! 나도 언젠간 내 이름으로 사람들 앞에서 강연을 할 수 있는 그런 사람이 됐으면 좋겠다 :) 안수빈님의 강연 내용은 아래와 같다.

1. 온체인 데이터 사용

- 온체인 데이터로 사용자의 행동을 알면 무엇을 할 수 있는지 생각해 보자.

2. 분석가의 대표적인 유형

- Trader: DaaS로 좋은 거래 기회 발견

- Detective/ Alert: Explorer를 통한 추적 및 확인

- Trend Setter: 생태계 정보를 다양한 방면으로 수집 및 분석

3. 용도에 따라 다양한 온체인 서비스

- Explorer: Etherscan과 친구들

- Query: Dune, Flipside Crypto

- No-Code: TokenTerminal, DefiLlama,L2Beat,Artemis

4. No-code: 하루의 시작과 함께

- TokenTerminal: 요새 어떤 서비스가 잘나가나? (Trending Contract, Fee, Revenue)

- DefiLlama: 디파이에는 별일 없지? (DeFi TVL, Volume)

- L2Beat: 요새 L2가 대세라며? (L2 TVL)

- Artemis: 체인에는 무슨 일이 있을까?(L1,L2 DAU, Daily Txs)

5. 더 깊은 온체인 데이터 분석을 하고 싶다면?

- 프로토콜 매커니즘: 컨트랙트와 토크노믹스

- 데이터 분석과 시각화: 통계 기법과 인지과학

- 관계형 데이터베이스와 쿼리문: SQL

- 도메인 지식: 다양한 지표

이어서 다음 강연은 "Web2/Web3 VC는 어떤 일을 할까 about Web 2.5" 라는 주제로 미래에셋벤처투자의 유수형님과 필로소피아벤처스의 오영택님이 진행해 주셨다. Web3 업계에서 전통 VC들이 어떤 고민들을 하고 있고 어떤 방향으로 나아가면 좋을지 개인적인 의견을 공유해 주셨다. 강연 내용은 아래와 같다.

1. Web3 업계에서 VC 투자란?

- Web3 업계에서 VC 투자란 주로 private round에서 SAFT 또는 Equity with Token warrant 등의 계약으로 프로젝트가 ICO, IDO 등 을 통해 불특정 다수에게 뿌려지기 전 투자하는 것을 의미한다. 또한 Web3에 관련 있는 기업의 지분 투자를 의미하기도 한다.

2. Web3 업계에서 VC의 역할이란?

- 어떤 팀에게 투자해야 하는지에 대한 마땅한 기준이 아직 없다. 왜냐하면 업계가 early이고 valuation 로직도 발전되지 않았기 때문이다.

- 투자한 팀에게 어떤 역할을 해주는지는 기존 VC에서 좀 더 추가되는 부분이 있다. 기존 VC는 브랜딩, HR, 라운드 리드, 네트워킹 등을 해줬다면 여기에 더해 같이 토크노믹스를 짜는 등 같이 연구를 진행하기도 한다. Hashed의 Unopnd, 블로코어 같이 프로젝트를 직접 만들어 나가는 경우도 존재한다.

- 토큰의 경우 유동성이 조기에 열려서 exit 타이밍을 잡는 게 비교적 유연하다. 하지만 Exit 흐름이 대중들에게 보이기 때문에 펌프 앤 덤프 비판을 받을 수는 있다. 그러나 기본적으로 락업 스케줄이 SAFT 등에 명시되어 있다.

3. 좋은 Web3 VC란?

- 강력한 믿음이 필요하다. 믿음에 의한 롱 텀 뷰를 갖고 윤리적인 플레이를 하는 VC가 필요하다.

- 투자자이자 플레잉 코치 역할이 필요하다. 자본이 아니라 지혜로 승부 보는 투자자가 되어야 한다.

4. 전통 VC에게 Web3 투자가 어려운 이유

- Due Diligence(실사/투자심사)에서 무엇을 봐야 할지에 대해서 어려움을 겪는다. 회계 재무를 볼 수 있는 지표가 없다. 그렇다면 다른 점에서 심사를 거쳐야 한다. 성장하는 시장인지, 비즈니스 모델은 어떤지, 그동안의 실험 성과가 있는지, 팀 구성은 어떻게 되어있는지를 본다.

- 일반적으로 한 번의 투자로 승부를 본다. 주주로서 지속적인 모니터링을 진행하지만 대부분 한번의 투자뿐이다.

- 아직 블록체인 업계에서 성공적인 M&A 사례가 없고, 투자자 락업이 있고, 너무 빠른 상장으로 구주 판매 기회가 없어서 Exit 이 쉽지 않다. 더 큰 난관은 법인 계좌를 개설하는 것이다.

이어지는 강연은 전 해시드 팀원이자 현재 Factomind 소속이신 Nathan 님이 "22년 Recap 및 23년 Market Preview" 라는 주제로 진행됐다. 시장 예측은 사실상 불가능하다는 것을 다들 알고 있을 것이다. 하지만 시장 내에서 예측이란 무엇일까에 대한 고찰을 정말 알기 쉽게 풀어주셨다. 요즘 내가 읽고 있는 책에서도 블랙 스완에 대한 내용을 다루고 있는데, 블랙 스완을 대처하는 자세가 정말 중요한 것 같다는 생각이 많이 들었다. 자세한 내용은 Nathan님의 트위터 스레드를 참고하면 좋을 것 같다. 내용을 간단하게 요약해 보자면 아래와 같다.

- 블랙 스완이란 아무도 예측하지 못한 이례적인 사건을 의미한다.

- 예측은 연속적인 행동이고 변하는 상황에 맞추어 예측치를 업데이트하기를 주저하지 말자.
- 현재 시장의 유동성이 현저히 낮기 때문에 예측의 난이도가 높다는 것을 인지하자.
- 블랙 스완 이벤트가 일어났을 때 행동할 수 있는 대비 전략을 준비해 두자.
- 금융시장 내 원론과 정의 공부를 통해 기회를 포착하자.

다음 강연은 슈퍼블록 김재윤님이 "다음세대 DeFi는 어떻게 진화할까?" 라는 주제로 진행해 주셨다. 평소에 재윤티비 유튜브를 즐겨보고 있었는데 요즘은 영상이 자주 안올라와서 아쉬운 ㅎㅎ 재윤님께서는 디파이의 변천사를 위주로 강연을 진행해주셨다. 내용은 아래와 같다.

1. 이자 농사(yield farming)의 등장

- 스시스왑이 등장하며 유니스왑을 공격했다. 유동성 공급자들에게 SUSHI 토큰을 분배하면서 유니스왑의 유동성을 많이 빼앗아왔다.

- 이처럼 토큰을 발행하여 유동성을 끌어들이는 전략이 보편화 됐다.

2. 현실의 문제를 해결하기 시작

- 실제 자산의 가격정보를 온체인 상에 반영한 미러링된 자산을 거래할 수 있는 디파이 프로토콜인 미러 프로토콜 등장

- 헤지펀드들의 공매도 포지션을 청산시키는 게임스탑 사태가 발생하고 증권거래 앱인 로빈후드에서 게임스탑 주식 매수 버튼을 비활성화했다. 이와 달리 검열 저항성을 보여주는 디파이 미러프로토콜로 많은 사람들이 이주하기 시작했다.

3. 기존 자산 시장의 한계

- 세상에는 수많은 유무형의 가치가 존재하지만 자산화된 가치들은 그 종류도 매우 적을뿐더러 자유롭게 거래하기가 어렵다.

4. 블록체인의 효용

- 블록체인은 누구나 원하는 가치를 쉽게 데이터화, 즉 토큰화시킬 수 있도록 해준다.

- STO 가이드라인을 살펴보면, 다양한 권리를 증권화하여 발행 및 유통할 수 있다. 비정형적 증권을 장외시장에서 거래할 수 있다.

고스트 프로젝트 홀더들이 자발적으로 모여서 Web3 시장을 리뷰하고 앞으로의 발전 방향성에 대해 토론할 수 있는 의미 있는 시간이었다. 고퍼런스의 목표인 많은 사람들에게 보다 쉬운 정보로 블록체인 세상을 전파하고자 하는 목표는 어느 정도 달성할 수 있게 된 자리라고 생각한다. 추후에 또 열리게 된다면 꼭 참여하고 싶은 고퍼런스이다.

블록체인 스타트업 프론트엔드 개발자의 입사 1주년 회고

xiubin — Wed, 22 Feb 2023 13:17:56 +0900

중국어통번역학과를 졸업한 내가 어느덧 2년 차 개발자가 됐다!!

하지만 개발자로 지내면서 학습 내용은 틈틈이 개인 노션이나 블로그에 작성해 왔지만, 나를 돌아볼 시간은 없었던 것 같다.

그래서 이번 회고를 통해서 내가 1년 동안 무엇을 했고 어떤 걸 배웠는지, 그리고 앞으로 해야 할 일들을 정리하고자 한다.

개발자로서 작성하는 첫 번째 회고의 주제는 블록체인 스타트업 프론트엔드 개발자의 입사 1주년이다.

1. 프리랜서 개발자로 시작하다

현재 다니는 회사에 오기 전 어떤 경험을 쌓았는지부터 시작해야 할 것 같아서 이야기를 한 번 풀어본다.

개발자로서의 내 첫 커리어는 상주 프리랜서 프론트엔드 개발자로 시작을 했다.

개발 공부를 병행하며 YAPP 동아리 활동을 마치고 취업 준비를 하려던 즈음에, 노마드코더 커뮤니티에서 많은 도움을 주시던 Flynn님께서 리액트 프리랜서 개발자 채용 공고를 공유해 주셨다. 지원할 당시 개발 공부한 지 1년도 안된 초보 였기 때문에 프리랜서는 전혀 생각지 못한 선택지였다. 하지만 채용 공고의 기술 스택이 굉장히 매력적이었고, 업무 경험을 하루빨리 쌓아 보고 싶다는 욕구가 강했다.

그래서 개인 프로젝트 하나와 동아리에서 진행한 팀 프로젝트 하나를 포트폴리오에 담고 면접을 보러 갔다.

개발자로서 첫 면접이었는데, 정말 떨렸던 기억이 난다. 주로 개인 프로젝트의 기술 사용에 대해 많은 질문을 하셨고, 최선을 다해 답변했다.

그 결과 개발자로서 첫 면접에 첫 합격 통보를 받게 됐고, 프론트엔드 개발자로서의 첫 발걸음을 내딛게 되었다.

채용 공고 내용 일부

프리랜서로 참여하게 된 프로젝트는 LG 생활건강에서 발주한 미국 온라인 쇼핑몰 리뉴얼 작업이었다.

꽤나 대형 프로젝트였던걸로 기억하는데, 구현해야 하는 페이지가 130여 개였고, 페이지마다 구현해야 할 기능도 다양했다.

투입 초기에는 프론트엔드 개발자 1명, 퍼블리셔 1명이 전부여서 지레 겁을 먹었지만, 몇 달 후에 프론트엔드 개발자가 3명이 더 채용돼서 안도의 한숨을 내쉬었던 기억이 있다. 이렇게 큰 프로젝트에 실무자로 투입되자마자 트렌디했던 기술 스택은 다 사용해 본 것 같다.

(React, Redux, Redux-Saga, Redux-Thunk, Storybook, TypeScript, styled-components)

물론 학습하면서 바로 바로 실무에 사용해야 해서 꽤나 버겁긴 했지만, 좋은 기회였고 짧은 시간 내에 많은 걸 배울 수 있었다. 그리고 함께 일하는 백엔드 개발자들 뿐만 아니라 LG CNS 직원분들과도 협업해야 해서 다양한 포지션의 분들과 끊임없이 소통하며 개발해야 했다.

첫 직장에서 기술적으로도 성장했지만 협업을 하는 부분에 있어서도 많은 성장을 이룬 것 같다.

(이와 관련해서 더 자세한 얘기는 추가적으로 글을 쓸 시간이 되면 다른 포스팅에서 다뤄보고 싶다.)

경험이라고는 팀 프로젝트 하나 있는 비전공자 신입 개발자를 믿고 채용해 준 것에 대해 감사했고, 이에 보답하기 위해 약 7개월 동안 개인적인 성장과 동시에 팀 내에서 1인분을 하기 위해 정말 고군분투했다.

하지만, 시작을 프리랜서로 시작했던 나는 프리랜서보다는 좀 더 안정적인 정규직을 구하고 싶었고 다시 취업 준비를 시작했다.

2. 취업 준비, 그리고 블록체인 스타트업으로 입사

첫 번째 취업을 단 한 번의 면접으로 하게 됐기 때문에 사실상 제대로 취업 준비를 해본 경험이 없었다. 그래서 두 번째 취업 준비를 할 땐 많은 준비가 필요했다. 알고리즘 공부, 과제 전형 준비, 기술 면접 공부 등 다양한 준비를 하며 약 6개월을 보냈다.

코딩테스트는 자바스크립트로 준비했고 여러 인터넷 강의를 시청하고 문제는 프로그래머스에서 주로 풀었다.

과제 전형은 주로 바닐라 자바스크립트로 구현하는 것이 나와서 이에 따른 공부를 추가적으로 했고,

기술 면접은 인터넷 강의, 유튜브, 블로그 자료들을 참고해서 노션에 따로 정리해서 질의응답 리스트를 만들어서 준비했다.

실제로 받았던 프론트엔드 개발 면접 질문은 따로 포스팅을 했는데, 생각보다 많은 유입이 들어와서 놀랐다.

그리고 취업 준비를 하면서 백수인 상태로 지낼 수 없었기에 크몽에서 간단한 퍼블리싱 작업을 통해 지속적인 수입을 창출해 냈다.

퍼블리싱 의뢰를 받으면서 HTML, CSS에 대한 이해도를 끌어올려 나가는 동시에, 좋은 작업물로 의뢰인들에게 만족감을 줘서 뿌듯했다.

(좌)면접 질문/답변 노션 정리 (우)판매한 크몽 서비스 리뷰

개발자로 취업 준비를 하기 이전에도 수많은 낙방을 경험했기에 많은 기업에 지원하고 탈락의 고배를 마셔도 크게 좌절하진 않았던 것 같다. 대기업의 신입 전형 코딩테스트는 정말 대부분 어려웠고, 합격하는 게 나에게는 하늘의 별따기였다.

그래도 포기하지 않고 여기저기 문을 두드려본 결과 면접까지 가게 된 회사들이 있었고 최선을 다해 면접에 임했다.

그 결과 운 좋게 현재 다니고 있는 회사를 알게 됐고 블록체인에 관심이 많았던 나는 입사를 결심하게 됐다.

사실 내가 개발자의 꿈을 가지게 된 건 이전에 다녔던 블록체인 회사에서 블록체인 공부를 개발자들과 함께 하면서부터였던 것 같다.

블록체인이라는 기술이 탄생하게 된 스토리텔링부터가 굉장히 신선했고, 공부할수록 흥미가 생겼다. 그래서 원래는 블록체인 개발자가 되는걸 꿈꿨는데, 비록 지금은 그 꿈과는 약간은 멀어졌지만 그래도 DApp 개발자로 일을 할 수 있다는 게 입사 당시에는 정말 기뻤다.

3. 패럴랙스 스크롤링으로 한 편의 애니메이션을 만들다

출근 첫날, 여러 층을 둘러보며 감탄을 금치 못했던 기억이 난다.

아무것도 없는 곳에서 일하다가 17층 건물을 통째로 쓰는 회사로 입사를 하다니... 성공했다 나 자신

상주 프리랜서로 근무할 때는 복지라고는 1도 없었고, 장비 지원도 없고, 심지어 모니터도 내 돈으로 샀었는데..

최신 장비 지원! 간식 무제한 지원! 맛있는 밥 제공! 코인 노래방, 당구, 포켓볼, 탁구대 구비!

~~너무 회사 홍보 글 같은데~~

입사 당시 회사 내부

아무튼 입사하고 일주일 정도는 비즈니스에 대한 설명과 블록체인에 대한 이해도를 높이는 시간을 가졌다. 그리고 나는 입사한 지 일주일 만에 바로 비즈니스와 관련된 티저 페이지와 랜딩 페이지 개발을 해야 했다. 당시 개발 인력은 컨트랙트 개발자 1명과 나, 총 2명이 전부였다.

랜딩페이지에 패럴랙스 스크롤링을 사용한 이유

원래는 패럴랙스 스크롤링 말고 서비스를 소개하는 애니메이션 영상을 띄우기로 했었다. 하지만 회사 측에서 한 패럴랙스 스크롤 사이트를 접하게 되면서 이 기법에 완전히 빠져들어버렸다. 하지만 나는 랜딩페이지를 패럴랙스 스크롤링 기법으로 구현하는 것에 처음에는 반대하는 입장이었다. 왜냐하면 애니메이션으로도 이미 충분히 영상이 잘 뽑혔는데, 이걸 굳이 다시 각 scene마다 리소스를 따서 패럴랙스 스크롤링으로 만든다는 것이 이해되지 않았다. 그리고 랜딩 페이지라는 것은 서비스를 소개하기 위한 것인데, 서비스를 파악하기 위해 사용자가 상당히 긴 스크롤을 내려가면서 꽤나 상당한 노력을 들여야 한다니.

그러나 당시 블록체인 서비스의 소개 사이트들을 대부분 둘러봤을 때 인터랙티브한 사이트는 많이 없었기 때문에 화려한 인터랙션이 들어간 랜딩 페이지 하나만으로도 눈길을 끌 수 있을 거라는 의견이 강했고, 나도 이에 설득당했다..

예상되는 씬이 생각보다는 많지 않았고 스크롤 길이가 엄청나게 길지는 않아서 조금의 노력으로 화려한 인터랙티브 효과를 볼 수 있었다. 이를 통해 다른 사이트보다 좀 더 차별화를 두고 관심을 끌 수 있었던 것 같다.

입사하자마자 만들게 된 티저 페이지를 구현할 때도 svg 파일의 path를 이용해서 애니메이션을 구현하며 신기한 애니메이션의 세계로 진입하게 됐는데, 랜딩 페이지는 패럴랙스 스크롤링을 구현해야 한다니! 입사하자마자 처음 시도하는 것들의 연속이었다.

하지만 프론트 개발자는 나 하나..! 반드시 구현해야 한다는 일념 하나로 열심히 서칭하고 강의도 들어보고 했다.

그 결과, 빠른 시일 내에 익히고 도입할 수 있는 GSAP의 Scroll Trigger 라이브러리를 사용하는 것을 선택했다.

스크롤 트리거는 말 그대로 스크롤 기반으로 애니메이션을 구현하는 건데, 트리거 엘리먼트를 지정하고 뷰포트에 트리거 엘리먼트가 등장하면 지정한 엘리먼트의 애니메이션이 작동된다. 사용법도 익히기 쉽고 성능도 좋아서 처음 시도한 것 치고 금방 구현할 수 있었다.

패럴랙스 스크롤 랜딩 페이지 개발에 대한 자세한 이야기는 아래 포스팅에서 확인할 수 있다.

애플처럼 화려한 Parallax Scroll 랜딩 페이지 개발해보기

Parallax scrolling is a web site trend where the background content (i.e. an image) is moved at a different speed than the foreground content while scrolling. 패럴랙스 스크롤링 기법을 간단히 말하면 스크롤에 따른 애니메이션 효

xiubindev.tistory.com

4. 설레이는 첫 DApp 개발

디앱(DApp)이란 블록체인을 기반으로 돌아가는 탈중앙화 분산 애플리케이션을 말한다. 쉽게 말해서 이더리움 기반 디앱이면, 디앱에서 상호작용하는 데이터들이 이더리움 블록체인에 기록되고 불러내어지는 애플리케이션이라고 이해하면 된다.

입사하고 랜딩페이지를 만들었던 시간을 제외하고 약 한 달 정도는 블록체인과 DApp 개발 강의를 많이 보고 기초를 다졌다. 이전 직장에서 기본 개념은 익혔고, 퇴사 이후에도 판교에서 블록체인 강의도 듣고 멋사에서 진행했던 프로젝트도 진행해봤기 때문에 다행히도 배우는 데 진입 장벽은 그나마 높지 않았던 것 같았다. 혼자 스터디하는 데 도움이 됐던 링크들을 공유한다.

1. 유튜브
https://www.youtube.com/@DappUniversity
https://www.youtube.com/@stone_chain
https://www.youtube.com/@jaeyuntv
2. 깃허브
https://github.com/ConsenSys/ethereum-developer-tools-list/blob/master/README_Korean.md
3. 문서
https://academy.binance.com/en

하지만... 공부를 하는 것과 실무에 적용하는 것은 천지 차이라는 것을...

그래서 참고할 만한 DeFi 오픈소스 프로젝트가 있는지 열심히 찾아보다가 PancakeSwap 이라는 프로젝트를 발견했다. 정말 사막의 오아시스 같은 존재였고, 실무에서 사용하기 위해 필요한 부분만 골라서 분석하기 시작했다. 모든 소스 코드를 다 분석하기에는 나 혼자서는 역부족이었기에... 모듈 위주로 분석하고 차용하기로 결정했다. 그래도 이 오픈소스 하나만 분석해도 어떤 방향으로 나아가야 할지 명확해졌고 정말 큰 도움이 됐다

4-1. DApp 프론트엔드 개발 환경 구축하기

일반 App과 DApp의 가장 큰 차이점은 서버와 데이터베이스가 중앙화되어있는지 여부이다.

예를 들어, 일반 애플리케이션은 서버에서 아이디와 비밀번호를 관리하고 유저가 이를 애플리케이션과 상호작용하는 데 사용하지만, DApp은 별도로 아이디와 비밀번호를 위한 서버를 구축하지 않고, 블록체인에서 스마트 컨트랙트와 상호작용할 수 있는 Address(EOA)와 Private key를 유저가 직접 가지고 있는 상태에서 서비스를 이용하게 된다.

즉, 서버가 아닌 프론트엔드에서 유저가 블록체인과 상호작용하도록 하는 기능을 구현해야 한다. 이를 위해서는 Address(EOA)와 Private key가 필요한데 상용화된 블록체인 지갑을 사용할 수 있다. DApp 개발에서 프론트엔드의 핵심적인 역할은 유저가 블록체인 지갑을 애플리케이션에서 사용할 수 있도록 연동해주고 스마트 컨트랙트와 상호작용할 수 있도록 해주는 것이다.

우리는 블록체인 메인넷 중에 BNB 스마트체인 위에서 DApp 개발을 진행하기로 했고, 블록체인 지갑 연동은 메타마스크(Metamask) 지원하기로 했다. 개발환경은 기존에 익숙한 React 개발 환경에 PancakeSwap을 참고하여 Web3 관련 개발 환경까지 구축하기로 결정했다. 개발 시작 당시 프론트엔드는 나 혼자여서 기술 스택을 함께 상의할 팀원이 없어서 아쉽긴 했다. 그래도 약 한 달 후에 시니어 개발자 분이 오셔서 천만다행이었지만!! 역시 시니어 개발자시라 빠르게 기술 습득을 하고 적용하시는 게 멋졌다

아무튼 내가 제로베이스에서 구축한 DApp 프론트엔드 개발 환경은 아래와 같다.

Yarn, Webpack, React.js, TypeScript, SWR, Emotion, ESLint

Ethers.js
이더리움 블록체인과 상호 작용하기 위한 라이브러리이며, 유용한 유틸리티가 많다. BNB 스마트체인은 EVM과 호환되기 때문에 이더리움 관련 개발 도구를 사용할 수 있다.

bignumber.js
블록체인에서 많은 작업은 JavaScript에서 사용할 수 있는 안전한 값의 범위를 벗어난 숫자에서 작동한다. 이 라이브러리는 모든 크기의 숫자에 대해서 연산을 안전하게 할 수 있도록 도와준다. Ethers.js 라이브러리에도 BigNumber 관련 유틸리티가 있지만, bignumber.js 라이브러리가 더 정교하게 다룰 수 있고 유틸리티도 훨씬 많아서 좋은 것 같다.

web3-react
디앱 빌딩 프레임워크로, 블록체인 지갑 연동뿐만 아니라 스마트컨트랙트와 상호작용에 사용할 수 있다.

2021년 12월, 노션에 정리해뒀던 메타마스크 사용 코드

원래 web3-react 라이브러리를 몰랐을 때는 Metamask 공식 문서를 참고해서 블록체인 연동 관련 코드를 다 짜놨었다. 노션에 개발 기능 정의, 코드 예제 등 다 작성했었는데, PancakeSwap 오픈소스를 알게 되고 나서 코드를 다시 새로 다 짰다 어쨌든 메타마스크 지갑을 연결하는 원리는 같지만 web3-react는 DApp과 관련된 데이터의 상태들을 쉽게 관리할 수 있어서 편리해서 사용하게 됐다. 그리고 메타마스크 외에 다른 지갑들도 쉽게 연동할 수 있는 것이 큰 장점이다.

web3-react 사용 방법에 대해서는 간단하게 포스팅을 한 번 해서 아래 글에서 확인해 볼 수 있다.

web3-react로 DApp에 지갑 연동 구현하기

이더리움 DApp을 개발하기 위해서 블록체인 지갑 연동은 필수라고 할 수 있다. 이더리움 기반 블록체인 지갑에는 여러 종류가 있는데 레저 나노, 트레저원, 메타마스크, 마이이더월렛, 트러스트

xiubindev.tistory.com

4-2. ESLint를 자동화해보자

커밋하기 전에 lint 에러가 있는 경우 커밋을 하지 못하도록 하기 위해 git hook을 활용했다. 이를 위해 husky와 lint-staged를 사용했고 커밋 전 staging area에 있는 파일들을 lint로 검사했다. 이와 관련해서 ESLint를 자동화해보자 라는 제목으로 포스팅을 했고, 아래 글에서 확인할 수 있다. 함께 작업하는 동료가 늘어날 때 굉장히 유용한 것 같다. commit 외에 다른 hook을 활용해서 프로젝트에 적용해 봐도 좋을 것 같다.

ESLint를 자동화해보자 (feat. husky & lint-staged)

Lint 코드의 오류나 버그, 스타일 등을 점검하는 것을 lint라고 부른다. 린트는 코드의 가독성을 높이는 것뿐만 아니라 자바스크립트와 같은 동적 언어의 특성인 런타임 버그를 예방하는 역할도

xiubindev.tistory.com

4-3. 웹팩 성능 최적화를 통해 개발 효율성을 극대화해보자

사실 예전에는 웹팩으로 큰 사이즈의 프로젝트를 번들링 해본 적이 없어서 빌드 속도가 느릴 수 있다는 것을 인지하지 못했다. 그리고 입사해서 m1 맥북 13 프로를 지원받았기 때문에 더더욱 성능 이슈를 겪을 일이 없었다. 하지만 동료 개발자분이 들어오시고 이전에 사용하셨던 윈도우 노트북으로 개발을 하시는데 내 개발환경 성능과 비교했을 때 상당히 느리다는 것을 알게 되었다.

첫 빌드가 30초 걸리고 dev server를 첫 구동하는데 90초라니... 이게 2022년도에 있을 수 있는 일인가!! 심지어 프로젝트 사이즈가 엄청나게 큰 시점도 아니었는데 말이다. 이를 계기로 동료 개발자분이 먼저 최적화를 조금 하시다가, 내가 이어받아서 최대한의 성능 최적화는 다 하게 됐다. 웹팩을 최적화한 결과, 성능을 5배 ~ 18배 개선할 수 있었다. 최적화와 관련된 자세한 사항은 아래 글에 작성했다.

웹팩 성능 최적화를 통해 개발 효율성을 극대화 해보자 ✨

이 글은 윈도우로 개발하는 동료로부터 시작되었습니다..! 사실 m1 맥북 13 프로를 쓰는 나로서는 개발하는데 성능의 문제성을 크게 느끼지 못했다. 서버 사양도 나쁘지 않아서 배포하는데도

xiubindev.tistory.com

4-4. DApp 개발 트러블 슈팅

메타마스크 지갑 연결, 네트워크 감지 및 변경, Token 조회/전송, Token 추가, DeFi(staking, unstaking, approve, claim) 등 다양한 기능을 개발하면서 정말 많은 이슈가 있었지만 해결하면서 뿌듯함을 느꼈고 재미있었다!

1. 일반 애플리케이션을 개발할 때도 개발 서버와 운영 서버를 나눠서 개발하듯이 블록체인도 마찬가지로 테스트넷과 메인넷의 개념이 있다. 그래서 개발할 때 테스트넷과 메인넷을 구별해서 환경 설정을 해야 한다. 아래 코드를 참고하면 좋을 것 같다.
그리고 테스트넷 환경에서 스마트컨트랙트를 실행시키려면 tBNB 토큰이 있어야 하는데, 이 토큰을 얻기 위해서는 faucet이라는 것을 활용해야 한다. 여기서 캡차를 풀고 개발용으로 개인 메타마스크 지갑을 생성하고 지갑 주소를 넣으면 무료로 들어오는데, 24시간 기준 1번 가능하다.

export const RPC_URL = isDevelopment
  ? 'https://data-seed-prebsc-1-s1.binance.org:8545'
  : 'https://bsc-dataseed.binance.org';
export const BASE_BSC_SCAN_URL = isDevelopment ? 'https://testnet.bscscan.com' : 'https://bscscan.com';
export const SNAPSHOT_BASE_URL = isDevelopment ? 'https://testnet.snapshot.org' : 'https://hub.snapshot.org';
export const CHAIN_ID = isDevelopment ? 97 : 56;
export const CHAIN_NAME = isDevelopment ? 'BNB Smart Chain Testnet' : 'BNB Smart Chain';
export const TOKEN_ADDRESS = isDevelopment
  ? '0x12346'
  : '0x12345';

2. 메타마스크 연결을 시도할 때 웹은 익스텐션, 모바일은 앱이 설치 돼있는지 먼저 확인을 해야한다. 온보딩 예제는 메타마스크 공식 문서에 친절하게 나와있어서 그대로 따라 하면 된다. 온보딩 외에 마주했던 이슈는 메타마스크가 잠금 상태일 때 연결 시도를 요청하면 아무 반응이 없었던 것이다. 그래서 이를 해결하기 위한 방법을 공식 문서에서 찾게 됐다. 개발을 하면 할수록 문서를 꼼꼼하게 읽어야겠다는 생각이 든다. 해결법은 여기서 확인할 수 있다.

실험적 API라고 적혀서 언제 없어질지는 모르는 메소드이긴 하지만 ethereum._metamask.isUnlocked() 를 호출하면 잠금상태인지 아닌지 boolean 값을 리턴해준다. 잠금상태이면 지갑 잠금을 풀어야 한다는 팝업을 띄워주고 잠금이 해제된 상태에서 지갑 연결을 시도하면 된다.

3. 블록체인에서 많은 작업은 JavaScript에서 사용할 수 있는 안전한 값의 범위를 벗어난 숫자에서 작동한다. 따라서 안전한 값을 벗어난 숫자에 대해서 연산을 할 수 있도록 개발하는 것이 가장 중요하다. 최대한 number 연산자는 쓰지 않고 모든 크기의 숫자를 다룰 수 있는 라이브러리를 활용해서 정교하게 연산을 하는 것이 좋다. 그리고 메타마스크에서 트랜잭션을 보낼 때 대부분 Hex string으로 변환해서 보내야 한다. 예를 들어 BNB 토큰을 전송할 때는 ethers.utils.parseUnits 유틸리티 함수를 통해 input에 입력된 value를 토큰 decimals에 맞게 BigNumber로 변환한 후, ethers.utils.hexValue 유틸리티 함수를 통해 이를 Hex string으로 변환하면 된다.

5. Next.js로 풀스택 개발 도전

스타트업에게 홈페이지가 왜 중요할까? 당연한 얘기지만 스타트업은 인재 채용에 있어서 정말 많은 어려움을 겪는다. 그중에 가장 큰 이유는 회사에 대한 정보가 많이 부족하기 때문일 것이다. 알려진 것이 많이 없으니 지원자 입장에서는 채용 공고를 보더라도 스타트업에 지원하기가 쉽지 않다. 그래서 회사가 추구하는 비전, 문화, 복지 등을 회사 홈페이지에서 잘 노출해야 할 필요성이 있다. 채용 공고에 회사에 대한 내용을 구구절절 써놓는 것보다 제대로 된 회사 홈페이지 하나만 있어도 지원자의 눈길을 끌 수 있기 때문이다.

우리 회사 진짜 좋은데... 어떻게 말로 표현할 방법이 없네...

우리도 채용에 있어서 난관을 겪고 있는 상황이었어서 리브랜딩을 하는 것과 동시에 회사 소개 및 채용 홈페이지를 개발하기로 결정했다.

5-1. 개발 환경 구축하기

회사 홈페이지를 개발하는 데 사용한 기술 스택은 다음과 같다.

Next.js, TypeScript, SWR, emotion.js, prisma, SQLite, jsonwebtoken, gsap

Next.js를 선택한 가장 큰 이유는 SSR, SEO 등 다양한 장점을 가지고 있지만, 그중에서도 Next.js 하나로 풀스택 개발을 할 수 있기 때문이었다. 정적인 페이지가 아니라 어드민 기능(로그인, 로그아웃, 채용공고 CRUD, 팀원 CRUD, 아티클 CRUD)까지 있어야 했기 때문에 풀스택 프레임워크인 Next.js를 사용했다. 당시 개발 리소스가 넉넉하지 않았고 채용을 위해서는 빠른 시일 내에 개발을 완료해야 했기 때문에 혼자 개발하기에는 적절한 프레임워크라고 판단했다.

그리고 데이터베이스는 팀원이 추천해 준 SQLite를 사용했다. SQLite가 프로젝트에 적합한 이유는 다음과 같다. 가볍고, db 파일 하나로 데이터베이스 정보를 관리하기 때문에 간편하고, 초기 설정이 거의 없기 때문에 빠른 개발이 가능하다. 큰 단점 중에 하나는 동시성이 제한되는 점이 있는데, 동시 쓰기 작업이 거의 이뤄지지 않을 것이라는 판단하에 이 단점은 제쳐두고 사용하기로 결정했다.

그리고 ORM으로는 Prisma를 사용했다. Prisma는 Node.js와 TypeScript 환경에서 데이터베이스에 쉽게 접근할 수 있도록 해주는데, 직접 사용해 보면서 이렇게 편할 수가 있나 싶을 정도로 개발 생산성이 무척 뛰어났다. 실무에서 백엔드를 다뤄보는 건 처음이었는데도 불구하고 개발 편의성이 높은 도구들을 활용해서 빠른 시일 내에 개발할 수 있었다.

5-2. 트러블 슈팅

1. Next.js Middleware로 토큰 검증 및 리다이렉트하기

채용 홈페이지를 만들면서 어드민 기능도 추가해야 해서, 서브 도메인을 별도로 생성하지 않고 같은 도메인에 /admin 경로를 추가하여 작업하기로 했다. 어드민 경로만 알고 있으면 누구나 어드민 페이지에 접근은 할 수 있는 상황이었다. 따라서 어드민 경로로 접근하면 로그인하지 않았을 때는 로그인 화면을 보여주고, 로그인을 했을 때는 어드민 세부 페이지로 리다이렉트 해줘야 했다.

처음에 생각했던 방법은 _app.tsx 파일에서 useEffect를 사용해서 pathname이 어드민 경로일 경우 토큰 검증을 해서 리디렉션 조건을 걸고자 했다. 그런데 이렇게 하면 접근 불가한 페이지로 바로 진입했을 경우 해당 페이지 화면이 잠깐 보였다가 리다이렉트가 되는 문제가 있었다. 이 문제는 토큰 검증이 끝나기 전에는 로딩 화면을 렌더링 하고 검증이 끝난 후 해당 페이지를 렌더링 하면 된다. 하지만 로그아웃 상태에서 모든 어드민 경로 페이지에 접근했을 때 로딩 화면을 보여주지 않고 바로 /signin 페이지로 리다이렉트 해주고 싶었다.

그래서 두 번째로 적용해 본 방법은 모든 어드민 페이지가 서버 사이드 렌더링이었기 때문에 getServerSideProps를 활용해 redirect 객체를 리턴하는 것이었다. 서버에서 토큰을 검증하고 원하는 페이지를 바로 렌더링 해주기 때문에 로딩 화면이나 접근 불가 페이지가 노출되지 않는 장점이 있다. 하지만 이 방식은 모든 어드민 페이지에 동일한 코드를 넣어줘야 한다는 단점이 있었다.

Middleware allows you to run code before a request is completed, then based on the incoming request, you can modify the response by rewriting, redirecting, modifying the request or response headers, or responding directly.

마지막으로 적용한 방법은 Next.js의 Middleware를 사용하는 것이었다.

미들웨어를 사용하면 request를 기반으로 response를 직접 제어할 수 있다. 쉽게 말해 요청이 들어오면 요청이 완료되기 전에Authentication, Bot protection, Redirects and rewrites 등의 작업을 할 수 있다.

미들웨어에서 쿠키에 토큰이 있으면 토큰 검증해서 성공한 경우 어드민 컨텐츠 페이지로 리다이렉트를 해주고, 만약 토큰이 없거나 유효하지 않은 토큰일 경우 /signin 페이지로 리다이렉트를 해줬다. 그리고 미들웨어에서 jsonwebtoken 라이브러리를 사용하지 못해서 찾아보니까 미들웨어가 Edge runtime에서 작동하기 때문에 라이브러리가 동작하지 않는 것이었다. 그래서 Edge runtime에서도 작동하는 jose 라이브러리의 jwtVerify 메소드를 활용해서 토큰을 검증해 줬다. 그리고 /admin 경로에서만 미들웨어를 실행할 수 있도록 config에 matcher를 어드민 경로로 작성해 줬다.

import { NextRequest } from 'next/server'
import { NextResponse } from 'next/server'
import { jwtVerify } from 'jose'

export async function middleware(request: NextRequest) {
  const token = request.cookies.get('token') ?? ''
  const JWT_TOKEN_KEY = process.env.JWT_TOKEN_KEY ?? ''

  try {
    if (token) {
      const { payload } = await jwtVerify(token, new TextEncoder().encode(JWT_TOKEN_KEY))
      if (!request.nextUrl.pathname.startsWith('/admin/signin') && !payload?.loginId) {
        return NextResponse.redirect(new URL('/admin/signin', request.url))
      }
    } else {
      return NextResponse.rewrite(new URL('/admin/signin', request.url))
    }
  } catch (error) {
    return NextResponse.rewrite(new URL('/admin/signin', request.url))
  }

  if (request.nextUrl.pathname === '/admin') {
    return NextResponse.rewrite(new URL('/admin/careers', request.url))
  }
}
export const config = {
  matcher: '/admin/:path*',
}

2. Prisma와 SQLite 활용해서 DB 구축하기

Prisma is an open source next-generation ORM.
- Prisma Client: Auto-generated and type-safe query builder for Node.js & TypeScript
- Prisma Migrate: Migration system
- Prisma Studio: GUI to view and edit data in your database.

Prisma를 처음 사용해 보면서 타입스크립트와 정말 잘 맞는 ORM이라고 생각했다. type-safe 쿼리를 통해 데이터를 안전하게 관리할 수 있고, 데이터베이스에 접근할 때 에디터에서 자동완성이 제공되는 게 정말 편리했다.

prisma를 셋업 하면 가장 중요한 게 prisma schema인데, 이 스키마를 베이스로 직관적인 데이터 모델링을 할 수 있다. schema 파일에 데이터베이스 연결 및 generator를 정의하고, 데이터베이스에 사용할 모델을 생성하면 된다.

나는 SQLite를 사용했기 때문에 prisma 폴더 내에 db 파일을 생성해서 서버에 업로드하는 방식을 채택했다.

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["referentialIntegrity"]
}

datasource db {
  provider             = "sqlite"
  url                  = env("DATABASE_URL")
  referentialIntegrity = "prisma"
}

model User {
  id        Int      @id @default(autoincrement())
  role      Int      @default(1)
  loginId   String   @unique
  password  String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}
...생략

prisma는 기본적으로 환경변수를 사용하기 위해 prisma를 셋업 하면 루트 디렉토리에 생기는 .env 파일을 불러온다. 그래서 .env 파일에 DATABASE_URL 환경변수를 저장하고 url에 불러와서 사용했다. 하지만 데이터베이스를 개발용과 프로덕션용으로 구분하기 위해 .env.development, .env.production 으로 구분지어서 파일명을 변경했더니, prisma cli를 사용할 때 환경변수를 찾지 못한다는 에러가 발생했다.

공식 문서를 찾아보니 개발 환경에 따라 여러 env 파일을 사용하는 방법이 나와있었다. dotenv-cli 패키지를 사용해서 prisma가 사용해야 하는 환경변수 파일을 지정할 수 있다. dotenv의 -e 옵션으로 env 파일을 지정할 수 있다.

그리고 데이터베이스를 파일 하나로 관리하고 있기 때문에, 로컬에 있는 프로덕션 DB와 서버에 있는 DB를 동기화하기 위해서는 추가적인 작업이 필요했다. 이를 위해 현재 DB 파일이 있는 우분투 서버에 접속해서 파일을 받아와서 동기화하는 작업을 migrate 스크립트에 추가했다.

 "migrate:dev": "dotenv -e .env.development -- npx prisma migrate dev --name sqlite-init",
 "migrate:prod": "scp -r -i '프라이빗키_경로' 서버_접속_경로 ./prisma && dotenv -e .env.production -- npx prisma migrate --name sqlite-init",

6. DApp 교육 과정 수료 및 해커톤 참가, 그리고 수상까지

블록체인 업계에서 일하는 건 처음이다 보니 아무래도 스스로 스터디를 많이 하려고 했다. 그래서 온라인 강의도 많이 듣고 무료 교육 과정이 있으면 찾아서 듣곤 했다. 교육 과정 중에 해커톤이 있는 과정도 있어서 교육을 수료하고 실제로 디앱을 만들어 해커톤에 참가해 보면서 실무에 도움이 될만한 기술을 많이 습득하게 됐다. 온라인 강의를 제외하고 교육 과정은 2번을 수료했고 해커톤은 총 3번을 참가했다.

6-1. NFT 블록체인 마켓 앱 만들기 with 그라운드X

회사에서 초창기에 Klaytn 기반으로 디앱을 만들 가능성이 있다고 해서 미리 스터디도 해둘 겸 멋쟁이사자처럼에서 진행하는 NFT 블록체인 마켓 앱 만들기라는 교육과정에 참여하게 됐다. 원래 회사 입사 전 취준생이었던 시절에도 같은 교육 과정을 잠깐 들었었는데 취준과 병행하다 보니 제대로 수료하지 못했었다. 심지어 그때는 유료 강의였는데 이번에는 무료 교육 과정으로 풀려서 한 번 더 참여하게 됐다.

5주 동안 온라인 교육을 들으면서 클레이튼 기반 애플리케이션을 설계하고 개발하는 방법에 대해 익히고 3주 동안 해커톤을 진행했다. 해커톤은 서버 개발자2,기획자1,앱 개발자1 그리고 나까지 다섯 명이 팀을 이루게 됐다.

스마트 컨트랙트와 프론트엔드 부분은 거의 내가 담당했는데, 스마트 컨트랙트는 레퍼런스가 많아서 개발에 엄청난 어려움은 없었지만, 프론트엔드에서 컨트랙트 호출을 연동하는 부분에 있어서 클레이튼 관련 레퍼런스가 생각보다 부족해서 어려움이 있었다. caver.js 버전에 따라 달라지는 부분도 많았고, caver.js 공식 문서를 정독해도 해결이 안됐던 부분은 클레이튼 개발자 포럼을 적극 활용했는데, 그래도 하루 이틀이면 답변이 달려서 다행이었다.

첫 디앱 개발 해커톤이어서 부족한 점도 많았지만, 팀원들도 바쁜 와중에 끝까지 포기하지 않고 참여해 준 결과 4위라는 값진 결과를 얻을 수 있었다! 개발과 관련된 문서나 코드는 아래 깃허브에서 확인할 수 있다. 지금 와서 보면 굉장히 부족하지만 5주간의 교육과 3주간의 작업물 치고는 나름 만족스럽다.

BadgeMeal

BadgeMeal has 3 repositories available. Follow their code on GitHub.

github.com

6-2. BNB 체인 해커톤

Klaytn 해커톤은 회사에서 나 혼자 참여했는데, 이번 BNB 체인 해커톤은 회사 동료들이 모여서 참가하기로 했다. 동료 한 명이 새롭게 블록체인 개발 파트에 합류하게 돼서, 동료의 컨트랙트 개발 스터디 겸 다 같이 해커톤에 참여하기로 했다. 사실 상금이 목적에 조금 더 가깝긴 했는데.. 아무튼 이번 교육은 지난번 멋사에서 진행했던 교육 과정보다 훨씬 알찬 내용이어서 유익했다. 기술적인 측면과 동시에 블록체인 프로젝트들의 현황도 알려주고 그에 따른 어떤 기술이 필요한지 파악하기 수월했다. 예를 들어 화이트리스트 수집 기능, 리빌 기능, 오픈제플린 적극 활용하기 등 실무에서 쓸법한 것들을 알게 돼서 좋았다.

첫 해커톤 보다 개발은 수월하게 진행됐다. 기능 구현하면서 서버 쪽 리소스가 필요 없어서 스마트 컨트랙트와 프론트에만 집중하면 됐다. 클레이튼 메인넷으로 개발할 때는 카이카스와 클립 모두 연동해야 웹,모바일 모두 실행할 수 있었는데, 이번에는 메타마스크 하나만 연동하면 되니 개발에 공수가 덜 들었다. 워들 게임비 BNB 송금, NFT 민팅/조회 등등 원했던 기능 대부분을 시간 내에 구현할 수 있었다.

4주 간의 온라인 교육 과정이 끝나고 오프라인으로 해커톤 데모데이가 진행됐다. 팀별로 부스를 설치하고 팀 상호 평가 및 심사위원 평가가 진행됐다. 그 결과 우리 팀은 최우수상을 수상했다! 퇴근하고 며칠간 고생했던 보람이 있었다. 나중에 받은 상금으로 다 같이 회사 근처에서 때깔 좋은 소고기도 맛있게 먹었다ㅎㅎ

아 그리고 지난번 온라인 교육과정에서 같은 팀원이었던 분을 이번 해커톤에서 오프라인으로 처음 뵙게 돼서 정말 반가웠다. 그분은 군대 전역 직전에 해커톤을 참여하러 휴가 중에 시간을 냈다고 하신다... 정말 리스펙!

BDDC

BNB Chain Defi Degen Club. BDDC has 2 repositories available. Follow their code on GitHub.

github.com

6-3. BNB 체인 이노베이션 해커톤

BNB 체인 해커톤에서 수상한 팀에게 BNB 체인 이노베이션 해커톤 참가 기회를 부여해 줘서 참가하게 됐다. 이전에 사용했던 소스에서 추가 기능을 덧붙여서 디벨롭시켰다. 우리는 디파이 프로토콜 부문에 지원했는데, 해당 부문에는 정말 잘 갖춰진 프로젝트들이 쟁쟁하게 지원했고 우리 프로젝트는 그에 비해 부족한 점이 많이 보였다 그래서 아쉽게도 수상은 하지 못했지만 좋은 경험이었고 좀 더 프로젝트를 디벨롭해 볼 수 있어서 좋았다. 나중에 회사에서 지원해 준다면 사이드 프로젝트로 이어나가고 싶은 마음도 크다!

7. Notion 200% 활용하기

회사에서 업무 협업툴로 노션을 사용하고 있다. 프로젝트 관리, 문서 아카이브 등 다양한 용도로 활용하고 있는데, 나는 회사에서 제공하는 템플릿 외에 개인적으로도 다양하게 사용하고 있다.

7-1. To Do List

나는 항상 월요일에 할 일 목록을 쭉 적고 일주일을 시작하는 편이다. MBTI는 ESFP로 나왔지만 일할 때만큼은 J가 되는 나..

팀 스페이스에 각자 할 일 목록을 적는 공간이 있어서 나는 늘 그곳에 나의 업무 리스트를 늘 작성해 둔다. 템플릿은 각자 편한 대로 유연하게 하면 돼서, 나는 테이블 리스트에 이름은 통일하고 보기 편하도록 기간을 설정하고 최신 순으로 정렬을 해뒀다. 그리고 문서를 열면 현재 진행 중인 프로젝트마다 할 일 목록을 구분해서 체크리스트로 작성하고, 퇴근 전 마친 일들을 체크해 둔다.

원래는 프로젝트마다 보드를 만들고 to do, doing, done 그리고 기간 이렇게 썼는데 한눈에 보기에 칸반 보드는 불편한 것 같아서, 그냥 개인적으로는 주 단위로 할 일 목록을 작성하고, 프로젝트 별 WBS는 회사에서 작성하는 것으로 파악하고 있다.

아무튼 이렇게 할 일 목록을 작성하다 보면 WBS를 작성할 때 나의 개발 일정 산출이 조금 수월해지는 것 같다. 입사 초반에 개발 일정을 산출해 달라는 요청을 받았는데, 해당 업무에 내가 얼마나 시간이 소요될지 측정이 어려웠다. 하지만 할 일 목록을 작성하고 그것이 얼마나 걸렸는지 대략 파악하다 보니 이제는 개발 일정을 산출하는데 나름 요령이 생긴 것 같다.

7-2. Study & Issues

일하면서 스터디가 필요한 부분이 많아서 공부했던 내용들을 정리하기 위해 Study 페이지를 만들었다. 공부한 내용이 동료 개발자들에게 도움이 될 것 같으면 보기 좋게 한 번 더 정리해서 노션 링크를 공유하기도 했다. 노션에 공부한 내용을 정리한 것을 바탕으로 블로그에 포스팅하기도 편해서 정리만 잘해두면 좋은 글감이 되기도 한다.

그리고 가장 유용하게 사용하고 있는 페이지는 Issues 페이지이다. 개발을 하다 보면 꼭 하루에 하나 이상 이슈를 접하게 된다. 해당 이슈를 바로 해결하더라도 다음에 또 똑같은 이슈를 마주할 확률은 꽤나 높다. 사람은 똑같은 실수를 반복하기 마련이기 때문에 이슈를 해결했더라도 해결 방안을 정확히 기억하기는 쉽지 않다. 그래서 나는 겪었던 이슈들과 해결방안을 정리해 두는 습관을 들여놨다. 물론 접했던 모든 에러나 이슈를 적는 것은 아니다. 나만의 기준에서 적어야 할 것만 필터링해서 작성하는 편이다.

Issues 페이지에는 React,TypeScript,HTML,CSS 등 큰 카테고리로 분류를 해놓았다. 그리고 이슈에 해당하는 대략적인 내용을 제목으로 알아보기 쉽게 작성한다. 그리고 블럭 안 내용에는 발생한 이슈, 해결 방법과 참고했던 링크를 작성한다.

이렇게 하면 나중에 다시 같은 이슈를 만났을 때 적었다는 사실만 기억해 내면 여기서 찾아볼 수도 있고, 블로그에도 좋은 글감으로 활용할 수 있다.

8. 통계로 보는 나의 1년

(좌) 회사 깃랩 (우) 개인 깃헙

회사 깃랩은 아주 파랑 파랑한 반면에! 나의 깃헙 잔디는 시멘트 바닥...

그만큼 회사에 집중을 했다고 보면 되지 않을까...ㅎㅎ 사이드 프로젝트로 혼자 뭔가 디벨롭해보기엔 시간이 없었다...

하지만 이제 집도 회사 근처로 옮겼으니 개인 시간이 거의 두 시간이 늘어났다!

이 시간을 잘 활용해서 자기 계발에 좀 더 집중해 봐야겠다.

나의 깃헙 시멘트 바닥을 영양가 가득한 잔디로 채우는 그날까지!

티스토리 블로그 방문자 통계

입사 후에도 시간이 날 때마다 블로그를 열심히 했다. 더 나은 양질의 정보를 공유하기 위해, 사람들에게 도움이 되는 글을 작성하기 위해 고민만 하다가 결국 글을 쓰지 못한 글감들도 많아서 아쉬움이 남기는 한다.

물론 내가 작성하는 글들이 다 정답이 아닐 수도 있고, 누군가에게 큰 도움이 되지는 못할 수도 있지만 나는 글을 쓰며 내 생각을 공유하는 것을 오랫동안 좋아했다. 개발자가 되기 이전에도 네이버 블로그로 정보 공유하는 것을 즐겨했고 나름 파워 블로거(?) 였던 시절이 있었다ㅋㅋ

어쨌든 앞으로도 내가 겪었던 일들과 다양한 정보들을 열심히 공유하는 개발자가 되고 싶다.

개발자로서 첫 회고를 마치며.
입사하고 1년 동안 내 나름대로 치열하게 살았지만,
2023년에는 더 치열하게 살아보자!

개발 블로그를 제대로 시작하고 나서, 내 블로그 타이틀을 "자라는 것을 잘하는 개발자"라고 명명했다.

이 타이틀에 걸맞게 나는 계속해서 자라나고 싶고, 더 나은 개발자가 되고 싶다.

이를 실현하기 위해 올해 목표는 다음과 같다.

다양한 개발 컨텐츠 접하기
강의도 듣고, IT 아티클도 읽고, 책도 읽어서 최대한 다양한 지식을 접해보고 싶다. 지금은 너무 회사에 갇힌 우물 안의 개구리처럼 느껴진다. 물론 회사에서도 얻는 게 정말 많지만, 개발자로서 시야를 넓히는 노력을 하고자 한다. 그래서 일단 YES24 북클럽 정기결제를 했고, 한 달에 한 번 개발 서적 읽기를 도전해보고자 한다
체력 증진하기
입사 이후 나름 운동을 꾸준히 했다. 복싱도 하고, PT도 하고, 수영도 했다. 하지만 인바디 결과를 보거나 내가 느끼는 나의 체력 상태를 봤을 때 아직 한참 부족한 상태이다. 올해 운동은 수영과 헬스장 웨이트 2가지에 집중해보려고 한다. 웨이트 운동을 정말 싫어하는 나지만... 근육량이 남들보다 현저히 낮기 때문에 무조건 해야 한다.. 체력은 내가 개발자로서 오래오래가기 위한 초석을 다지는 중요한 요소 중 하나이기 때문에 소홀히 하지 않을 것이다.
대외 활동 시작하기
취업 준비할 때는 정말 활발하게 대외 활동을 했던 것 같은데, 입사하고 나서부터 대외 활동에 시간을 투자하지를 못했다. 속해있는 커뮤니티도 간간히 눈팅만 하고 대외 활동을 통해 다양한 사람들을 만나고 그들과 함께 소통하면서 시너지를 낼 수 있다는 게 얼마나 소중한 것인지 알고 있기 때문에, 올해는 조금 적극적으로 활동해보고 싶다.

2023년에도 자라는 것을 잘하는 개발자가 되자!

애플처럼 화려한 Parallax Scroll 랜딩 페이지 개발해보기

xiubin — Fri, 13 Jan 2023 15:15:28 +0900

Parallax scrolling is a web site trend where the background content (i.e. an image) is moved at a different speed than the foreground content while scrolling.

패럴랙스 스크롤링 기법을 간단히 말하면 스크롤에 따른 애니메이션 효과라고 할 수 있다. 패럴랙스 스크롤링 기법을 적용한 대표적인 웹사이트는 애플 제품 소개 페이지이다. 볼 때마다 감탄사가 나왔었는데, 회사에서 이와 같은 인터랙션 사이트를 구현할 기회가 생겼다!
"나도 애플처럼 화려한 인터랙션을 넣을 거야 "라고 속으로 호기롭게 외치며 스터디를 시작했다.

회사에서 인프런 바우처를 지원해 줬기 때문에 강의 1, 강의 2를 들으며 패럴랙스 스크롤링 원리를 익혔다. 정말 많은 도움이 됐던 강의다.
패럴랙스 스크롤링 기법의 핵심은 스크롤 높이와 움직일 객체의 포지션을 동적으로 계산하고, css 중 transform 속성에서 translate, scale 등을 이용하는 게 핵심이다. 그리고 transition에서 easing을 조절해서 스크롤에 따른 애니메이션의 가속도를 자연스레 설정하는 것이 중요하다. 그리고 requestAnimationFrame을 활용해서 부드럽게 화면에 그려주는 것이 중요하다.

하지만 실무에 바로 적용하기에는 스터디 시간이 약간 부족했고, 결국 라이브러리를 활용하기로 했다.
패럴랙스 스크롤링을 구현하기에 가장 적합한 라이브러리로 GSAP의 Scroll Trigger 라이브러리를 택했고, 빠른 시일 내에 구현할 수 있었다. 스크롤 트리거는 말 그대로 스크롤 기반으로 애니메이션을 구현하는 건데, 트리거 엘리먼트를 지정하고 뷰포트에 트리거 엘리먼트가 등장하면 지정한 엘리먼트의 애니메이션이 작동된다. 사용법도 익히기 쉽고 성능도 좋아서 처음 시도한 것 치고 금방 구현할 수 있었다.

패럴랙스 스크롤 데모 구경하기

Parallax Scroll Site

parallax-scroll-site.netlify.app

GSAP 홈페이지에 가보면 문서가 잘 돼있어서 굳이 사용법은 적지 않아도 될 것 같고, 겪었던 문제점과 해결법을 공유해보려고 한다.

GSAP 스크롤 트리거 트러블 슈팅

어려웠던 점은 회사 측에서 요청했던 패럴랙스 스크롤링은 애플 사이트와는 조금 다르게 정말 한 편의 애니메이션을 제작하는 것과 같았다.
다양한 scene이 존재했고, 스크롤링하면서 여러 리소스들이 뷰포트 안으로 들어와서 움직여야 했다.

1. 스크롤 높이는 최대한 넉넉하게 잡기

스크롤에 따라 리소스가 움직이기 때문에 트리거를 애니메이션에 필요한 총 스크롤 높이의 엘리먼트로 고정해 놓고, 정해진 높이 안에서 움직임을 계산하는 게 편리했다. 그리고 최대한 스크롤 높이는 넉넉하게 잡는 것이 좋다. 처음에 너무 작게 잡았다가 여러 기기로 테스트해 보면서 부족함을 느껴서 다시 재조정하며 굉장한 노가다를 반복했다..

2. 뷰포트 사이즈 대응하기

반응형으로 제작하기 위해 뷰포트 사이즈에 맞게 움직이는 속도를 조절해야 해서, resize 이벤트가 일어나거나 뷰포트 사이즈에 따라 스크롤 속도를 유동적으로 계산하도록 했다.

3. 뷰포트 바깥에 리소스 배치하기

각 scene마다 뷰포트 안으로 들어오는 리소스의 위치가 제각각이기 때문에 position: fixed 로 뷰포트 바깥에 리소스를 배치한 후 움직이는 게 좋다. 그리고 반응형으로 제작할 경우 scene을 기획할 때 최대한 화면 가운데서 인터랙션 일어나는 것이 보여야 하는 것이 관건이다.

4. 다양한 스크롤 기기 대응하기

스크롤 기기(트랙패드, 마우스 휠, 모바일 터치 기기 등)에 따라 속도가 다 다르기 때문에 우선은 기기마다 디폴트 설정값을 기본으로 테스트해 보고 속도를 계산하는 것이 최선인 것 같다. 그리고 스크롤 트리거의 scrub 속성을 활용해서 적절히 속도를 조절할 수도 있다.

5. 크로스 브라우징 테스트하기

사파리, 크롬, 파이어폭스, 엣지, 네이버 인앱 브라우저까지 크로스 브라우징 테스트로 잘 돌아가는 것을 확인했는데, 이상하게 유독 ios 기기의 카카오톡 인앱 브라우저에서만 버그가 발생했다. 디버깅을 하고 싶었으나 카카오톡 인앱 브라우저는 디버깅조차 할 수 없어서 정말 애먹었다. 디버깅을 위해 원인을 예측해 보고 수정하고 배포해서 인앱 브라우저에서 열어서 확인하는 동작을 수없이 반복했다. 결국 디버깅엔 실패했고, 구글링을 통해 발견한 블로그 글을 보고 ios 기기의 인앱브라우저에서는 이미지를 대체해서 보여주는 방식으로 해결할 수밖에 없었다. 지금 개인적으로 올린 데모에서는 location.href="x-web-search://?" 코드를 사용하여 사파리 앱 URL Scheme을 활용해 인앱 브라우저에서를 사파리를 열어주는 방법으로 인앱 브라우저에서 탈출시키도록 했다.

️ 이미지 성능 최적화

패럴랙스 스크롤링 랜딩 페이지는 원래 예정에 없었다. 그냥 애니메이션 제작하고 그 영상을 랜딩 페이지 최상단에서 플레이하기로 했는데, 계획이 바뀌면서 패럴랙스 스크롤링 기법을 적용해야 했다. 그래서 기존에 아트 팀에서 애니메이션을 위해 모든 아트 작업을 포토샵으로 작업했기 때문에 이미지 파일을 모두 PNG 파일로 변환해야 했다. 만약 벡터 기반 아트였으면 성능 이슈가 크지 않았을 텐데 PNG 포맷이었기 때문에 좀 더 성능에 큰 영향을 미쳤다. 이미지 용량이 큰 게 많이 들어가다 보니까 특히 모바일에서 스크롤하면 버벅거리는 경우가 많았다. 그래서 이미지를 최적화하는데 집중해야 했다.

1. 이미지 용량 줄이기

이미지 최적화에서 사진 용량 줄이기를 빼놓을 수 없다. 올바른 이미지 최적화를 위해서는, 사진 퀄리티는 그대로 유지하면서 용량은 최대한 줄여야 한다. 구글은 사진 용량줄이기를 위해 파일크기를 줄이는 도구 중 ImageOptim을 사용할 것을 권장하는데, ImageOptim 은 맥용 무료 도구이며 이를 사용하면 실제로 JPEG 파일은 69 %, PNG 파일은 40 % 의 용량이 감소된다.
그 결과 이미지 리소스 사이즈를 총 18.5mb에서 13.2mb 까지 줄이는 데 성공했다.

2. WebP 이미지 포맷 사용하기

WebP는 무손실 및 손실 압축을 전부 지원하고, JPEG, PNG 및 GIF 이미지 포맷을 대체할 수 있는 웹에 최적화된 포맷이다. 이 글에 따르면 WebP 이미지는 JPEG, PNG 보다 파일 크기가 일반적으로 25~35% 작아서 성능 향상에 중요한 역할을 할 수 있다고 한다. WebP 이미지 포맷은 현재 기준 IE를 제외한 브라우저에서 모두 지원하는 것으로 알려져 있다.
기존에 사용하던 PNG 파일 중에 크기가 큰 파일을 모두 WebP 포맷으로 변환하고, WebP 파일을 지원하지 않는 경우에는 PNG파일을 사용하고 그 외에는 WebP 파일을 사용했다. 이를 구현하기 위해 다음과 같이 picture 태그와 source태그, img태그를 이용해야한다.

<picture> 태그는 <img> 태그의 다중 이미지 리소스를 위한 컨테이너를 정의할 때 사용한다. <picture> 태그는 0개 이상의 <source> 태그와 하나의 <img> 태그로 구성된다.
<source> 태그는 미디어 리소스를 지정한다. 브라우저가 지원하는 형식으로 나열된 첫 번째 소스를 사용하고, <source> 태그에 나열된 형식 또는 <picture> 태그를 브라우저가 지원하지 않으면 <img> 태그에 지정된 이미지를 로드하는 것으로 대체된다. 따라서 <img> 태그는 항상 가장 마지막에 나열해야 하고 보편적으로 지원하는 미디어 형식의 리소스여야 한다.
예시 코드는 아래와 같다.

<picture>
  <source type="image/webp" srcset="flower.webp">
  <source type="image/png" srcset="flower.png">
  <img src="flower.png" alt="flower">
</picture>

그 결과 이미지 리소스 사이즈를 총 13.2mb에서 3.5mb까지 줄이는 데 성공했다.

️ CSS 애니메이션 성능 최적화

이미지 최적화 이후 피시에서 애니메이션 테스트를 마치고 모바일 테스트를 진행하는데, 굉장한 버벅거림 현상을 마주했다.
그래서 이미지 최적화뿐만 아니라 애니메이션 성능에도 문제가 있다는 것을 알게 됐고, 애니메이션 최적화를 시작했다.
애니메이션을 최적화하기 위해서는 우선 브라우저에서 렌더링이 어떻게 일어나는지를 먼저 파악해야 했다.

출처: https://developer.chrome.com/blog/inside-browser-part1/

크롬 기준으로 브라우저 아키텍처를 살펴보면 브라우저 프로세스, 렌더러 프로세스, 플러그인 프로세스, GPU 프로세스 등으로 구성되어 있다. 이 중에서 렌더러 프로세스가 브라우저 탭 안에서 일어나는 모든 일을 담당하게 된다. 렌더러 프로세스 안에서도 메인 스레드, 컴포지터 스레드, 래스터 스레드로 나뉘는데, 메인 스레드가 대부분의 스크립트 코드를 처리하고, 컴포지터/래스터 스레드는 화면을 부드럽게 렌더링 하는 것을 처리한다.

출처: https://web.dev/howbrowserswork/

일반적으로 메인 스레드에서 Recalculate Style, Layout, Paint 과정이 실행되고 CSS 기반 애니메이션을 컴포지터 스레드에서 실행한다. 위에서 언급했듯이 자바스크립트 코드는 메인 스레드에서 실행되기 때문에 자바스크립트로 애니메이션을 구현할 경우 애니메이션의 우선순위가 밀릴 수 있다. 하지만 CSS 기반 애니메이션을 구현한다면 컴포지터 스레드에서 처리되기 때문에 애니메이션 성능을 최적화할 수 있다.
그리고 부드러운 애니메이션을 위해서는 렌더링 과정 중 Composite Layers에 영향을 주는 속성만 사용하는 것이 적합하다.
웹 브라우저 렌더링 과정과 그 과정에 해당하는 CSS 속성을 간단히 살펴보면 다음과 같다.

1. Recalculate Style : 요소에 적용할 스타일을 계산한다.

2. Layout : 요소의 모양과 위치를 생성한다.

position	display	overflow	overflow-y
width	height	min-width	min-height
padding	margin	border	border-width
top	bottom	left	right
font	font-family	font-size	font-weight
white-space	line-height	vertical-align	float
clear

3. Paint : 생성된 모든 레이아웃에 픽셀을 추가한다.

color	background	visibility	text-deocration
background-image	background-position	background-repeat	background-size
outline	outline-color	outline-style	outline-width
border-radius	border-style	box-shadow

4. Composite Layers : 레이어(z-index) 순서대로 레이어를 합성하고 화면에 그린다.

transform

opacity

위 순서에 따르면 Layout 관련 속성을 바꾸면 Paint, Composite Layers 순서를 거치기 때문에 성능 저하가 일어난다. 이를 Reflow라고 한다.
또한 Paint 관련 속성을 바꾸면 Composite Layers 순서를 거치기 때문에 성능 저하가 일어난다. 이를 Repaint라고 한다.
따라서 CSS 애니메이션 성능을 최대로 발휘하려면 Composite Layers 관련 속성(transform, opacity)만 바꾸는 것이 가장 좋다.

패럴랙스 스크롤 랜딩페이지를 만들어보면서 패럴랙스 스크롤링의 원리를 익힘과 동시에 이미지와 애니메이션 최적화에 대해 많이 배울 수 있었다. 다음에 기회가 된다면 라이브러리를 사용하지 않고 순수 CSS, JS로만 패럴랙스 스크롤링을 구현해보고 싶다!

참고 문헌
https://developer.chrome.com/blog/inside-browser-part1/
https://developer.chrome.com/blog/inside-browser-part3/#style-calculation
https://greensock.com/react/
https://greensock.com/react-advanced
https://edidiongasikpo.com/using-gsap-scrolltrigger-plugin-in-react
https://wit.nts-corp.com/2020/06/05/6134

[컨퍼런스 리뷰 / Google I/O 2022] What's new for the web platform

xiubin — Thu, 19 May 2022 12:17:25 +0900

제일 재밌었던 스피커 :)

구글이 개최하는 연례 개발자 컨퍼런스인 Goolge I/O 를 듣고 발표 내용 및 추가적으로 서칭하고 정리한 내용을 공유하려고 한다.

What's new for the web platform 세션은 프론트엔드 개발자라면 꼭 봐야 하는 세션이다.

새로운 기능들을 많이 접해볼 수 있고, 발표 내용을 바로 실무에 적용해본 기능들도 있어서 굉장히 유용했다.

Google I/O 2022

CSS accent-color

<input type="checkbox">
<input type="radio">
<input type="range">
<progress>

accent-color는 위 요소들에서 생성된 사용자 인터페이스 컨트롤의 강조 색상을 설정해주는 속성이다.

이 속성은 color-scheme 속성과도 함께 작동하므로 light 모드와 dark 모드에 각각 색상을 설정해줄 수 있다.

See the Pen HTML elements with accent-color by web.dev (@web-dot-dev) on CodePen.

dialog

<dialog> 요소는 닫을 수 있는 경고, 창 등 대화 상자 및 기타 다른 상호작용 가능한 컴포넌트를 나타낸다.

open 속성을 통해 활성 여부를 컨트롤 할 수 있고, method="dialog" 특성을 사용한 form 요소는 제출 시 dialog를 닫는다.

dialog를 닫을 때, dialog의 returnValue 속성은 양식을 제출할 때 사용한 버튼의 value로 설정되며, returnValue에 따라 콜백 함수 내에서 조건문을 사용하여 다른 기능들을 처리할 수 있다.

<dialog id="MiniDialog" modal-mode="mini">
  <form method="dialog">
    <article>
      <p>Are you sure you want to remove this user?</p>
    </article>
    <footer>
      <menu>
        <button autofocus type="reset" value="cancle">Cancel</button>
        <button type="submit" value="confirm">Confirm</button>
      </menu>
    </footer>
  </form>
</dialog>

const MiniDialog = document.getElementById('MiniDialog');

MiniDialog.addEventListener('close', function onClose() {
	console.log(MiniDialog.returnValue)
});

input datetime-local

input 태그의 type 속성의 datetime-local을 사용하면, 유저가 날짜와 시간을 쉽게 입력할 수 있도록 하는 입력 컨트롤을 만들어준다.

<label>
	Start date &amp; time:
	<input type='datetime-local' />
</label>

Back/forward cache

bfcahce(Back-Forward Cache)란 말 그대로 뒤로/앞으로 캐시라고 할 수 있다.

페이지 로드 성능 개선을 위해 브라우저에서 잠시 동안 캐시를 보유하고 있다가, 뒤로 또는 앞으로 탐색을 할 때 즉각적으로 페이지를 로드할 수 있다.

이 기능을 제대로 활용하기 위해서는 bfcahce에 맞게 페이지를 최적화를 진행해줘야한다.

unload 이벤트 사용 금지
window.opener 참조 피하기
사용자가 다른 곳으로 이동하기 전에 항상 열려 있는 연결 닫기
bfcache 복원 후 오래되거나 민감한 데이터 업데이트

bfcahce는 chrome 개발자 도구의 application-cache 부분에서 확인할 수 있다.

img loading="lazy”

JavaScript 라이브러리를 사용할 필요 없이 img 태그의 loading=lazy 속성을 사용하여 이미지를 지연 로딩할 수 있다. lazy는 뷰포트로부터 계산된 거리에 도달할 때까지 리소스 로딩을 지연시킨다. 이 속성은 img 요소뿐만 아니라 iframe 역시 가지고 있다.

<img src="image.jpg" alt="..." loading="lazy">
<iframe src="video-player.html" title="..." loading="lazy"></iframe>

layout shift를 방지하려면 모든 <img> 태그에 width 및 height 속성이 모두 포함되는 것이 좋다.
처음 뷰포트에 표시되는 이미지는 지연 로딩을 하지 않아야 한다.

CSS aspect-ratio

aspect-ratio 속성은 요소의 크기를 비율대로 조정할 수 있도록 종횡비를 설정할 수 있다.

반응형 디자인의 출현으로 웹 개발자에게 종횡비를 유지하는 것이 점점 더 중요해졌다.

특히 이미지 크기가 다르고 사용 가능한 공간에 따라 요소 크기가 변하기 때문이다.

.container {
  width: 100%;
  aspect-ratio: 16 / 9;
}

예전에는 이미지 요소의 종횡비를 세팅하기 위해서 padding-top을 계산해서 넣어주곤 했는데, 이제 그렇게 할 필요가 없어졌다!

단순히 요소에 aspect-ratio 속성만 넣어주면 반응형에 따라서도 종횡비를 잘 유지할 수가 있다.

Priority hints

Priority Hints를 통해 리소스 로딩을 최적화할 수 있다. link, img, script 및 iframe 태그에 fetchpriority 속성을 사용하면 된다.

이 속성을 사용하면 리소스 로드의 우선순위를 지정할 수 있다.

high: 리소스를 높은 우선순위로 간주한다.
low: 리소스를 낮은 우선 순위로 간주한다.
auto: 브라우저가 적절한 우선순위를 결정하도록 하는 기본값이다.

<img fetchpriority='high' src='test.png' alt='...' />
<img fetchpriority='low' src='test2.png' alt='...' />

<script fetchpriority='high' src='test.js' async></script>
<script fetchpriority='low' src='test2.js' async></script>

<iframe fetchpriority='high' src='/test'></iframe>
<iframe fetchpriority='low' src='/test2'></iframe>

대용량 이미지일 경우 우선 순위를 높였을 때 시간 차이가 발생한다. script의 경우 async를 추가해 주면 우선 순위를 더욱 높일 수 있다.

CSS size-adjust

size-adjust 속성을 사용하면 웹 폰트가 로드되면 크기를 조정하여 폰트 크기를 표준화하고 폰트 간에 전환할 때 레이아웃 이동을 방지할 수 있다.

@font-face {
  font-family: "Adjusted Regular Arial For Brand";
  src: local(Arial);
  size-adjust: 90%;
}

CHIPS

쿠키(Cookie)는 사용자가 어떤 웹사이트를 방문할 경우 사용자의 정보를 저장하기 위해서 사용자의 디바이스(컴퓨터, 스마트폰 등)에 저장하는 파일을 의미한다. 쿠키 종류 중에 서드파티 쿠키(Third-Party Cookie)라는 것이 있다. 서드파티 쿠키는 방문한 웹사이트에서 심는 쿠키인데, 서로 다른 사이트를 넘나들면서 사용자 정보를 추적할 수 있어서 개인 정보 문제가 화두가 됐다.

구글은 서드파티 쿠키로 인한 사이트 간 추적을 중단하여 사용자의 개인 정보를 개선하고자 CHIPS라는 것을 제안했다.

“Cookies Having Independent Partitioned State (CHIPS) is a Privacy Sandbox proposal that will allow developers to opt a cookie into "partitioned" storage, with separate cookie jars per top-level site.”

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

사용자가 사이트 A를 방문하고 임베디드 된 사이트 C가 Partitioned 속성으로 쿠키를 설정하면, 브라우저는 최상위 사이트가 A인 경우에만 해당 쿠키를 보낸다.

사용자가 사이트 B와 같은 새 사이트를 방문하면 사이트 A에 방문할 때 설정된 쿠키를 공유하지 않고, 새로운 쿠키가 생성된다.

즉, 특정 임베디드 콘텐츠가 A 사이트에 임베드될 때 쿠키가 설정되어 있으면, 사이트가 A에 임베드된 경우에만 쿠키를 사용할 수 있다.

이로 인해 여러 사이트에서 사용자를 추적하는 데 쿠키를 사용할 수 없지만, 쿠키로 세션은 계속 유지할 수 있다.

structuredClone

const myOriginal = {
  someProp: "with a string value",
  anotherProp: {
    withAnotherProp: 1,
    andAnotherProp: true
  }
};

const myDeepCopy = JSON.parse(JSON.stringify(myOriginal));

기존에는 deep-copy를 하기 위해서 Lodash의 cloneDeep과 같은 함수를 사용하거나, 위와 같이 JSON기반으로 파싱을 해서 사용했다. 하지만 JSON 기반의 방법은 재귀 데이터 구조를 처리하지 못하고, 함수를 버리는 등 문제점이 있었다.

const clone = structuredClone(myOriginal);

기존 JSON 기반 방법의 문제점을 해결하고 deep-copy를 쉽게 할 수 있도록 structuredClone 함수가 생겼다.

이렇게 간단하게 깊은 복사를 진행할 수 있다.

다만 아직 한계는 있다고 한다. 객체에 함수가 포함되어 있으면 복사를 진행할 때 함수는 버리게 된다. 또한, 객체의 값이 직렬화할 수 없다면 에러를 뱉는다.

array.at

at 메서드는 정수 값을 받아, 배열에서 해당 값에 해당하는 인덱스의 요소를 반환한다. 양수와 음수 모두 지정할 수 있고, 음수 값의 경우 배열의 뒤에서부터 인덱스를 세서 반환한다.

const cart = ['사과', '바나나', '배'];

function returnLast(arr) {
  return arr.at(-1);
} 
// 마지막 요소인 '배'를 반환

배열의 맨 마지막 요소를 가져오고 싶을 때 배열의 length 속성을 사용해 array[array.length - 1]을 하는 대신, 짧게 array.at(-1)을 사용할 수 있다.

CSS cascade layers

CSS 속성의 우선순위를 결정하는 요인들이 몇 가지 있다. 나중에 선언할수록, 선택자가 더 구체적으로 명시되어있을수록 우선순위가 높은 것 등이 있다. cascade layers는 @layer를 사용해서 layer 단위로 우선순위를 지정해줄 수 있다.

@import 'theme.css' layer(utilities);

@layer base {
  .link {
    color: blue; /* ignored */
  }
}

@layer typography {
  a {
    color: green; /* styles *all* links */
  }
}

CSS 파일 자체를 레이어로 import 할 수도 있고, 나중에 선언될수록 우선순위가 높다.

Interop 2022 - New viewport units : dvh, lvh, svh

Interop 2022 프로젝트의 목표는 이러한 표준을 기반으로 하는 웹 애플리케이션이 작동하고, 서로 다른 기기, 플랫폼, 운영체제로 구성된 전 세계 생태계에서 동일하게 보이도록 하는 것이다.

현재 여러 가지 기능을 각각의 플랫폼에서 테스트하고 개발하는 중인데, 그중 눈에 띄는 기능 중 하나가 새로운 viewport 단위였다.

위와 같이 dynamic, largest, smallest 세 가지 크기로 viewport 단위를 추가하여, 주소 표시줄을 고려하면서 모바일 기기에서 보이는 뷰포트 레이아웃을 세밀하게 다룰 수 있을 것이다.

ESLint를 자동화해보자 (feat. husky & lint-staged)

xiubin — Thu, 14 Apr 2022 13:23:09 +0900

Lint

코드의 오류나 버그, 스타일 등을 점검하는 것을 lint라고 부른다. 린트는 코드의 가독성을 높이는 것뿐만 아니라 자바스크립트와 같은 동적 언어의 특성인 런타임 버그를 예방하는 역할도 한다.

ESLint는 ECMAScript 코드에서 문제점을 검사하고 더 나은 코드로 고쳐주는 lint tool이다. ESLint를 사용해서 개발을 하면 잠재적인 오류와 버그를 제거할 수 있다.

협업을 하는 프로젝트에서 lint를 적용하는 것은 필수라고 할 수 있다. 왜냐하면 모든 개발자들이 같은 규칙 내에서 개발해야 잠재적인 오류를 방지할 수 있기 때문이다.

하지만,

아무리 ESLint를 모든 개발자들이 사용한다고 해도 warning, error 등 lint 결과를 무시하고 바로 commit 하고 push 해버릴 수도 있다.

이러한 상황을 미연에 방지하기 위해서는 lint 에러가 있는 경우 commit을 하지 못하도록 하는 것이 최선의 방법일 것이다. 이를 구현하기 위해서는 git hook이라는 것을 사용하면 된다.

Git Hook

프로그래밍에서 hook이란 특정 이벤트 또는 함수가 호출되기 전/후에 호출이 되는 코드를 의미한다.

Git은 특정 상황에 특정 스크립트를 실행할 수 있도록 하는 Hook이라는 기능을 지원하고 있다. 별도로 설치할 것은 없고 모든 git repository에서 지원한다. git으로 관리하고 있는 폴더에서 cd .git/hooks/ 명령어를 치고 ls 명령어를 쳐보면 .sample 확장자로 되어있는 파일이 13개가 있다. 이는 git hook이 지원하는 특정 상황이 13개인 것을 알 수 있다. 해당 hook을 사용하려면 .sample 확장자만 지우면 된다.

이번에 사용해볼 git hook은 pre-commit이다.

pre-commit은 단어 뜻 그대로 commit 직전에 실행되는 hook이다.

husky

git hooks는 .git 디렉터리에 저장되기 때문에 git repository에 원격으로 저장하고 관리할 수 없다. 따라서 git hook을 공유하기 위한 방법에는 여러 가지가 있지만 그중 husky를 사용해보고자 한다.

husky란 Node.js 개발 환경에서 git hook을 편리하게 사용할 수 있게 만들어주는 도구이다. husky를 사용하면 프로젝트 별로 commit, push 등과 관련된 정책을 관리하고 공유할 수 있다.

lint-staged

git hook을 활용해서 commit 하기 전에 lint를 실행해서 코드를 검사할 수 있게 됐다. 하지만 검사해야하는 확장자에 해당하는 모든 파일을 검사하려면 굉장히 오랜 시간이 소요될 것이다. 이때 lint-staged를 함께 사용하면 변경된 파일만 검사할 수 있다. 즉 git staging area에 올라온 파일만 검사할 수 있다

지금부터 React 프로젝트에서 husky와 lint-staged를 활용해서 commit 전에 ESLint를 자동화해보도록 하겠다.

1. 모듈 설치 : npm install husky lint-staged

모듈을 설치하기 전에 ESLint, Prettier 등 도구를 설치 및 세팅해놔야 한다.

설치가 완료되면 .husky 폴더가 루트에 생긴다.

그리고 package.json 파일에 아래와 같은 코드를 추가하고 해당 스크립트를 한 번 실행한다.

"scripts": {
  "prepare": "husky install"
}

Yarn2를 사용하고 있다면 아래와 같이 코드를 추가하고 해당 스크립트를 한 번 실행한다.

"scripts": {
  "postinstall": "husky install"
}

실행 후 .husky 폴더의 pre-commit 파일을 살펴보면 npx lint-staged라는 명령어가 있는데, commit 전에 이 명령어를 실행한다는 의미이다.

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

2. package.json의 lint-staged 설정

ESLint를 실행하여 검사하고 싶은 확장자를 설정하고 원하는 옵션도 세팅해서 명령어를 작성하면 된다.

나는 아래와 같이 ESLint의 cache, fix 옵션을 설정했다.

"lint-staged": {
    "*.{ts,tsx}": "eslint --cache --fix"
}

3. git add , git commit 실행

코드를 수정하고 git add를 한 후에 git commit을 하면 우리가 세팅한 husky와 lint-staged에 의해 ESLint가 실행된다.

lint 에러가 있다면 commit에 실패하고 어떤 에러가 발생했는지 터미널에 나타난다.

lint 에러를 고치고 다시 commit을 실행하면 정상적으로 commit이 되는 것을 볼 수 있다.

ESLint를 자동화해보며..

git hook을 사용해서 ESLint를 자동화하는 과정을 알아봤다.

이처럼 lint에 사용해도 되고 master 브랜치에 직접 push 하는 것을 막을 수도 있고 git hook은 다양한 정책에 활용할 수 있다.

필요한 정책을 셋업하고 유연하게 각자 프로젝트에 적용해보자!

22년 6월 9일 추가 내용

Next.js 프로젝트 적용 방법

package.json

{
  "name": "next",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint --fix",
    "prepare": "husky install"
  },
  "dependencies": {
    "next": "12.1.6",
    "react": "18.1.0",
    "react-dom": "18.1.0"
  },
  "devDependencies": {
    "@types/node": "17.0.40",
    "@types/react": "18.0.12",
    "@types/react-dom": "18.0.5",
    "@typescript-eslint/eslint-plugin": "^5.27.1",
    "eslint": "8.17.0",
    "eslint-config-next": "12.1.6",
    "eslint-config-prettier": "^8.5.0",
    "husky": ">=6",
    "lint-staged": ">=10",
    "prettier": "^2.6.2",
    "typescript": "4.7.3"
  },
  "lint-staged": {
    "*.{ts,tsx}": "next lint --fix"
  }
}

create-next-app으로 프로젝트를 셋업 했을 때 기본적으로 eslint가 세팅되어있고, lint 실행은 next lint로 가능하다.

React 프로젝트와 비교했을 때 husky, lint-staged를 사용하는 방법은 크게 다르지 않은데, 중요한 한 가지가 있다.

바로 .lintstagedrc.js 파일을 생성해야 한다는 것이다.

Next.js 프로젝트 루트 폴더에 파일을 생성하고 공식 문서에서 제공해준 아래와 같은 코드를 작성해주면 된다.

.lintstagedrc.js

const path = require('path')

const buildEslintCommand = (filenames) =>
  `next lint --fix --file ${filenames
    .map((f) => path.relative(process.cwd(), f))
    .join(' --file ')}`

module.exports = {
  '*.{js,jsx,ts,tsx}': [buildEslintCommand],
}

.lintstagedrc.js 파일을 생성하지 않으면 에러가 나면서 린트가 실행되지 않으므로 반드시 위와 같은 작업을 진행해주자!

참고 문헌

https://github.com/okonet/lint-staged

https://typicode.github.io/husky/#/

https://library.gabia.com/contents/8492/

https://techblog.woowahan.com/2530/

https://nextjs.org/docs/basic-features/eslint#lint-staged

웹팩 성능 최적화를 통해 개발 효율성을 극대화 해보자 ✨

xiubin — Fri, 8 Apr 2022 16:25:47 +0900

이 글은 윈도우로 개발하는 동료로부터 시작되었습니다..!

사실 m1 맥북 13 프로를 쓰는 나로서는 개발하는데 성능의 문제성을 크게 느끼지 못했다. 서버 사양도 나쁘지 않아서 배포하는데도 크게 느리다는 생각을 못했다. 하지만 윈도우 환경에서 개발하는 동료의 빌드 속도를 보고 경악을 금치 못했다...

첫 순수 빌드 시간이 거의 30초에 가까웠으며, webpack dev server를 첫 구동하는 시간이 무려 90초나 걸리는 것이었다..

내 개발환경의 성능과 비교해보자면 첫 빌드는 약 3배, dev server 구동은 약 13배 차이가 났다.

그래서 동료 개발자의 웹팩 개선 시도를 기점으로, 정확하게 개발 환경의 문제점을 파악하고 고치기 위해 Webpack 공식 문서를 정독하면서 성능을 최적화해보기로 했다.

프로젝트 기술 스택

Webpack5, React, Typescript

1. 최적의 devtool 옵션을 선택하자.

웹팩으로 코드를 번들링 하게 되면 에러를 트래킹 하기 어려워진다. 하지만 source map을 사용하게 되면 번들링 된 파일의 코드를 소스 파일의 원래 위치로 다시 매핑해줘서, 어디서 에러가 발생했는지 알기 쉬워진다.

가능하면 소스 맵을 생성하는 것이 좋은데, 어떤 source mapping 스타일을 선택하는지에 따라 빌드 및 리빌드 속도에 큰 영향을 미친다.

⚠️ 최적화 이전

devtool: !isDevelopment ? 'hidden-source-map' : 'inline-source-map',

최적화 이전에는 프로덕션 모드에서는 hidden-source-map이고, 개발 모드에서는 inline-source-map이었다.

devtool 옵션 중에 빌드와 리빌드 성능이 가장 느린 두 가지를 쓰고 있었다...ㅎㅎ;; 물론 코드 품질은 original 이어서 디버깅하기에는 최적이지만 성능은 최악인 옵션들이었다. 그래서 성능은 빠르면서 품질도 좋은 옵션으로 바꿔보고자 했다.

♻️ 최적화 이후

devtool: env.development ? 'eval-cheap-module-source-map' : false,

웹팩 공식 문서 가이드를 보면 eval-cheap-module-source-map 옵션이 가장 좋다고 기재돼있다. 빌드는 느림이지만 리빌드는 빠름이고, 코드 품질이 original lines 여서 트랜스파일하기 전의 코드를 볼 수 있어 개발 모드에서 디버깅하기 좋은 옵션이라고 할 수 있다.

프로덕션 모드에서는 굳이 소스 맵이 필요하지 않다고 생각해서 소스 맵을 생성하지 않는 옵션을 줬다.

더 많은 옵션을 보고 고르고 싶다면 여기서 볼 수 있다.

2. 최적의 cache 타입을 선택하자.

cache 타입을 설정하면 생성된 웹팩 모듈 및 청크를 캐시 하여 빌드 속도를 개선할 수 있다.

cache는 개발 모드에서는 memory, 프로덕션 모드에서는 비활성화되는 것이 디폴트로 세팅되어 있다.

최적화 이전에는 디폴트 상태로 내버려두었기 때문에 프로덕션 모드로 빌드할 때 비활성화 상태로 되어 있어서 캐싱이 전혀 안된 상태였기 때문에 빌드 성능이 좋지 않았다. 그래서 최적화 이후에는 개발 모드와 프로덕션 모드에서 별개로 타입을 설정했다.

♻️ 최적화 이후

cache: { type: env.development ? 'memory' : 'filesystem' },

타입을 filesystem으로 설정하면 파일 시스템 캐시를 활성화하고 node_modules/.cache/webpack 경로에 캐싱된다.

이와 같이 캐싱을 통해 빌드 속도를 개선할 수 있고 filesystem으로 설정하면 더 많은 옵션을 설정할 수 있다.

3. output의 filename을 chunkhash로 저장하자.

웹팩으로 빌드한 결과물인 파일 내용이 변경되지 않는 한 캐싱 상태로 유지하면 브라우저에서 불필요한 네트워크 트래픽을 줄여서 웹 성능을 개선할 수 있다. 파일을 캐싱할 수 있는 방법 중에 하나는 output의 filename 옵션의 chunkhash를 사용하는 것이다.

chunkhash를 사용하게 되면 파일이 변경될 경우에만 해시 값을 생성해서 파일 이름을 저장하게 된다.

⚠️ 최적화 이전

output: {
    path: path.join(__dirname, 'build'),
    filename: '[name].js',
    publicPath: '/build/',
},

♻️ 최적화 이후

output: {
    pathinfo: false,
    path: path.join(__dirname, 'build'),
    filename: 'js/[name]-[chunkhash].js',
    assetModuleFilename: 'img/[hash][ext][query]',
    publicPath: '/',
    clean: true,
},

4. output의 pathinfo를 false로 설정하자.

웹팩은 번들에 포함된 모듈에 대한 정보를 주석으로 번들에 포함하도록 생성한다. 그러나 수천 개의 모듈을 번들로 묶는 프로젝트에서는 가비지 컬렉션에 과부하를 주므로 pathinfo를 false로 설정하는 것이 좋다.

5. 로더, 플러그인은 꼭 필요한 것만 사용하자.

굳이 사용할 필요 없는 로더나 플러그인만 제거해도 빌드 성능이 개선된다. 그리고 개발 서버를 실행할 때 필요한 플러그인과 빌드할 때만 필요한 플러그인을 나눠서 실행하는 것도 성능을 개선하는데 큰 영향을 미친다.

fork-ts-checker-webpack-plugin

기존에는 빌드할 때도 실행되도록 했는데, 굳이 빌드할 때 필요하지 않다는 생각이 들었다.

그래서 개발 모드일 때만 실행하도록 했고, async: true 옵션을 줘서 컴파일을 빠르게 하고 별도의 프로세스에서 타입 체크도 할 수 있게 했다. 개발 모드일 때 async는 디폴트 값으로 true가 들어간다. 기존에는 false로 줘서 빌드도 느리고 컴파일도 느렸던 것으로 파악된다.

eslint와 이 플러그인의 목적은 둘 다 컴파일 타임에 미리 에러를 잡아내는 것이다. 다만 eslint는 문법적으로 잘못된 부분을 잡아주고, type check 플러그인은 타입에 맞게 정확히 작성됐는지 검사해준다.

webpack-bundle-analyzer

기존에는 개발 모드일 때도 실행되도록 했는데, 굳이 개발할 때 필요하지 않다는 생각이 들었다.

그래서 빌드할 때만 실행되도록 했고, analyzerMode: 'static', openAnalyzer: false 옵션들을 줘서 html 파일로 생성되도록 하고 브라우저에서 자동으로 열리지 않도록 설정했다.

♻️ 최적화 이후

  if (env.WEBPACK_SERVE && config.plugins) {
    config.plugins.push(new ForkTsCheckerWebpackPlugin());
    config.plugins.push(new ReactRefreshWebpackPlugin());
  }

  if (!env.WEBPACK_SERVE && config.plugins) {
    config.plugins.push(new BundleAnalyzerPlugin({ analyzerMode: 'static', openAnalyzer: false }));
  }

file-loader

기존에는 애셋을 처리할 때 file-loader를 사용했는데, Webpack5에서는 Asset modules가 새로 추가되어서 로더를 추가로 구성하지 않아도 애셋 파일을 사용할 수 있게 됐다.

그래서 file-loader를 대체하기 위해 asset/resource 모듈을 새로 추가해서 에셋을 처리했다.

파일을 출력 디렉터리로 내보낼 때 디렉터리 및 파일명을 정의할 수 있다. output.assetModuleFilename 에서 수정할 수 있다. 더 자세한 방법은 여기서 확인 가능하다.

clean-webpack-plugin

기존에는 웹팩으로 번들링 했던 결과물을 지우고 다시 번들링 하기 위해 clean-webpack-plugin 을 사용했었다. 하지만 Webpack5 에서는 output에 clean이라는 옵션이 생겨서 이 플러그인을 대체할 수 있게 됐다.

clean: true 옵션을 주게 되면 번들링 해서 출력하기 전에 output 디렉터리를 정리해주고 새로 번들링 된 결과물을 내보낸다.

♻️ 최적화 이후

module: {
  rules: [
  ...
    {
      test: /\.(gif|jpg|png|webp|svg)$/,
      type: 'asset/resource',
    },
  ],
},

output: {
  ...
  assetModuleFilename: 'img/[hash][ext][query]',
  clean: true,
},

6. esbuild-loader를 사용하자.

지금은 자바스크립트 번들러의 춘추전국시대라고 해도 과언이 아니다. 원래는 한동안 webpack이 주름을 잡고 있었는데, 최근 들어 Vite, esbuild 등 다양한 번들러가 나왔고 웹팩보다 좋은 성능을 자랑하고 있다.

기존에는 webpack + babel-loader 조합으로 프로젝트를 구성했다. 하지만 이번에는 esbuild를 적용해서 성능을 높여보기로 했다.

https://esbuild.github.io/

esbuild는 Go 언어로 작성됐고, 파싱, 프린팅, 소스 맵 추출 등 과정이 동시에 진행되며 빌드에 불필요한 단계를 줄여서 다른 번들러보다 속도를 확실히 빠르게 개선했다고 한다. 자세한 내용은 공식 문서에도 나와있으니 살펴보면 좋을 것 같다.

기존 webpack 생태계를 그대로 유지하되 esbuild를 적용하기 위해서 babel-loader를 esbuild-loader로 대체해보기로 했다.

대체하는 방법은 쉽다. 원래 babel-loader를 적용하던 곳에 esbuild-loader를 적용하면 된다.

⚠️ 최적화 이전

module: {
    rules: [
      {
        test: /\.tsx?$/,
        loader: 'babel-loader',
        options: {
          presets: [
            [
              '@babel/preset-env',
              {
                targets: {
                  browsers: ['last 2 versions', 'ie >= 11'],
                },
                useBuiltIns: 'usage',
                corejs: 3,
                shippedProposals: true,
                debug: isDevelopment,
              },
            ],
            '@babel/preset-react',
            '@babel/preset-typescript',
          ],
        },
      },
      ...
    ],
  },

♻️ 최적화 이후

module: {
      rules: [
        {
          test: /\.tsx?$/,
          loader: 'esbuild-loader',
          options: {
            loader: 'tsx',
            target: 'es2015',
          },
        },
        ...
      ],
},

7. optimization.minimizer 플러그인을 사용하자.

기본적으로 프로덕션 모드로 빌드할 때 optimization.minimize 옵션은 true로 설정돼있다. 이 옵션이 true이면 minimizer에 지정된 플러그인을 사용해서 번들을 최소화한다. 웹팩 공식 문서 가이드에는 terser-webpack-plugin을 사용하는 것이 예제로 나와있다.

하지만 우리는 esbuild-loader를 사용할 것이기 때문에 이를 최대한으로 활용해보고자 한다.

esbuild-loader는 빌드 속도도 빠를 뿐만 아니라 Minification 툴도 함께 지원한다는 장점이 있다. 기존에 babel-loader를 사용했을 때는 파일 압축을 위해서 다양한 플러그인을 추가해야 했는데, esbuild-loader는 ESBuildMinifyPlugin을 포함하고 있다.

ESBuildMinifyPlugin을 사용하면 terser-webpack-plugin과 css-minimizer-plugin을 대체할 수 있다.

이 플러그인은 다른 플러그인에 비해 속도가 10배 이상 빠르고 번들 사이즈도 정말 작다고 한다.

minimizer에 플러그인을 추가하고 target, css 옵션을 설정해주면 끝이다.

♻️ 최적화 이후

optimization: {
  minimizer: [
    new ESBuildMinifyPlugin({
      target: 'es2015',
      css: true,
    }),
  ],
},

8. devServer.static에 명확한 경로를 작성하자.

webpack-dev-server는 웹팩에서 제공해주는 개발용 웹서버이다. 웹서버를 실행시키면 코드가 변경될 때 자동으로 변경된 파일만 다시 번들링 하여 서버를 다시 구동해주는 역할도 한다. webpack-dev-server는 컴파일 후 출력 파일을 작성하지 않는다. 대신 번들링 한 결과물을 메모리에 보관하고, 서버의 루트 경로에 마운트 된 실제 파일인 것처럼 제공한다.

devServer의 static 옵션은 번들링 된 정적 파일들을 담고 있는 디렉터리를 명시해준다. 즉 서버에 콘텐츠를 제공할 위치를 알려주는 역할을 하는데, devServer는 static 옵션에 설정된 디렉터리를 브라우저에 띄워주게 된다. static 옵션을 설정하지 않으면 기본적으로 현재 작업 디렉터리 전체를 사용해서 콘텐츠를 제공하게 된다. 따라서 특정 디렉터리를 명시해주는 것이 번들링 속도를 높여줄 수 있다.

♻️ 최적화 이후

devServer: {
  historyApiFallback: true,
  port: 3090,
  static: { directory: path.resolve(__dirname, 'build') },
  hot: true,
  open: true,
},

웹팩 성능 최적화 이후 동료의 개발 속도 개선 결과

순수 빌드 시간: 30초 ➡️ 6초
dev server 첫 구동 시간: 90초 ➡️ 5초

웹팩 성능 최적화를 하나하나씩 해보면서 속도가 빨라지는 것을 보며 쾌감(?)을 느껴서 기분이 좋았다 :)

맥북으로 개발해서 크게 체감하지 못했던 최적화의 필요성을 다시 한번 깨닫게 되는 좋은 경험이었다.

그리고 웹팩 공식 문서 가이드만 읽어도 최적화 가이드가 정말 잘 나와있었는데, 이 부분을 놓친 게 아쉬웠다.

이것만 제대로 읽었어도 동료 개발자의 개발 효율성을 진즉에 높여줄 수 있었을 텐데 하는 아쉬움이 들었다.

다음 프로젝트에서는 또 어떤 것을 동료와 함께 헤쳐나갈지 기대가 된다! 회사 생활이 정말 즐겁다!(진심 )

참고 문헌

https://webpack.kr/guides/build-performance/

https://webpack.kr/configuration/

https://esbuild.github.io/

https://techblog.woowahan.com/6465/

https://ui.toast.com/fe-guide/ko_BUNDLER