Expo 환경에서 @react-native-firebase 의존성 추가 후 알 수 없는 오류로 인한 빌드 실패 해결

환경

Expo SDK 54 @react-native-firebase/app@^23.8.6 @react-native-firebase/messaging@^23.8.6

문제

Expo React Native 프로젝트에서 Android, iOS Platform의 FCM Push Token을 발급받기 위해 @react-native-firebase 라이브러리를 설치한 이후,

app.config.ts에

...
plugins: [
    ...
  '@react-native-firebase/app',
  '@react-native-firebase/messaging',
    ...

추가한 이후 eas build로 빌드 시 오류 발생

로컬 expo prebuild 시에는 문제 없이 빌드 됨.

Error Log

Build failed: The "Run fastlane" step failed because of an error in the Xcode build process. We automatically detected following errors in your Xcode build logs:
- include of non-modular header inside framework module 'RNFBApp.RCTConvert_FIRApp': '/Users/expo/workingdir/build/apps/native/ios/Pods/Headers/Public/React-Core/React/RCTConvert.h' [-Werror,-Wnon-modular-include-in-framework-module]
- include of non-modular header inside framework module 'RNFBApp.RCTConvert_FIROptions': '/Users/expo/workingdir/build/apps/native/ios/Pods/Headers/Public/React-Core/React/RCTConvert.h' [-Werror,-Wnon-modular-include-in-framework-module]
- include of non-modular header inside framework module 'RNFBApp.RNFBAppModule': '/Users/expo/workingdir/build/apps/native/ios/Pods/Headers/Public/React-Core/React/RCTBridgeModule.h' [-Werror,-Wnon-modular-include-in-framework-module]
- include of non-modular header inside framework module 'RNFBApp.RNFBRCTEventEmitter': '/Users/expo/workingdir/build/apps/native/ios/Pods/Headers/Public/React-Core/React/RCTEventEmitter.h' [-Werror,-Wnon-modular-include-in-framework-module]
- include of non-modular header inside framework module 'RNFBApp.RNFBSharedUtils': '/Users/expo/workingdir/build/apps/native/ios/Pods/Headers/Public/React-Core/React/RCTBridgeModule.h' [-Werror,-Wnon-modular-include-in-framework-module]
- include of non-modular header inside framework module 'RNFBApp.RNFBUtilsModule': '/Users/expo/workingdir/build/apps/native/ios/Pods/Headers/Public/React-Core/React/RCTBridgeModule.h' [-Werror,-Wnon-modular-include-in-framework-module]

해결

AI는 buildReactNativeFromSource: true 설정이나, 커스텀 플러그인을 생성해서 ['CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES'] = 'YES'를 설정하는 해결방법을 제시하지만 이렇게는 해결되지 않습니다.

이 문제는 Git Issue에서 알려진 이슈입니다.

이슈: Solved! Build error on expo 54 / react native 0.81 (working build demonstrator script linked in comments now) #8657

해결방법: [SDK 54][iOS] Non-modular header errors when using @react-native-firebase/app + auth with useFrameworks: "static" #39607

요약

app.config.ts에 expo-build-properties 플러그인 설정에서 사용중인 모든Firebase Pod를 forceStaticLinking 배열에 추가합니다.

plugins: [
  ...
  [
    'expo-build-properties',
    {
      ios: {
        useFrameworks: 'static',
        forceStaticLinking: ['RNFBApp', 'RNFBMessaging', ... ],
      },
      ...

요구사항

GitHub Actions에서 Monorepo의 모든 App, Package의 Lint 에러 개수를 센 다음, 모든 Lint Problems의 총 합, 그리고 각 App과 Package별 Problems 개수를 Slack Bot으로 전송한다.

구현

pnpx turbo lint 명령어를 통해 Monorepo의 Lint 검사를 실행하고, 각 Task에서 출력된 결과를 합산하여 Slack Bot으로 보낼 예정이었습니다.

Lint는 오류 발생 시 로컬 환경에서 아래와 같은 메시지를 출력하며 작동이 중단되는데요,

...

app-1:lint: ✖ 3 problems (2 errors, 1 warning)
app-1:lint:   2 errors and 0 warnings potentially fixable with the `--fix` option.

...

app-2:lint: ✖ 3 problems (2 errors, 1 warning)
app-2:lint:   2 errors and 0 warnings potentially fixable with the `--fix` option.

에러가 발생할 때에도 모든 Task를 끝까지 실행하기 위해 다음과 같은 명령어를 추가할 수 있습니다.

pnpx turbo lint --continue

그러면 grep -E '✖' 커맨드로 모든 App과 Package의 Lint 검사 결과를 grep하여 어떤 Task의 결과로 몇 건의 Lint 문제가 발생했는지 알 수 있겠지요.

문제점

하지만 Git Action 환경에서 turbo 명령어를 이용해 출력되는 결과물은 자동적으로 아래와 같이 각 Task별로 그룹화 되어 출력됩니다.

▶ app-1:lint

...

 ✖ 3 problems (2 errors, 1 warning)
   2 errors and 0 warnings potentially fixable with the `--fix` option.

▶ app-2:lint

...

 ✖ 3 problems (2 errors, 1 warning)
   2 errors and 0 warnings potentially fixable with the `--fix` option.

이 내용은 Turborepo 블로그에 2024년 개재된 1.13버전 릴리즈 노트(링크)를 통해 확인할 수 있는데요, CI 로깅 개선을 통해

• Azure Pipelines
• TeamCity
• Travis CI

와 함께 GitHub Actions도 로그 출력 그룹화가 지원이 된다는 내용입니다.

따라서 로컬 환경에서처럼 해당 린트 오류의 결과가 어떤 앱의 오류 결과인지를 grep -E '✖' 만으로는 알 수 없게 되지요.

해결방법

강제로 그룹화를 해제해 출력하는 방법이 있습니다. turbo run 커맨드의 --log-order 옵션은 로그가 어떤 방식으로 정렬될 것인지를 설정할 수 있는데요,

stream 옵션은 모든 Task의 로그 출력을 그룹화 없이 출력하며,

...
app:lint: ✖ 3 problems (2 errors, 1 warning)
app:lint:   2 errors and 0 warnings potentially fixable with the `--fix` option.

grouped 옵션은 로그 출력을 각 Task별로 그룹화하여 출력합니다.

▶ app:lint

...

 ✖ 3 problems (2 errors, 1 warning)
   2 errors and 0 warnings potentially fixable with the `--fix` option.

기본값은 auto이며, CI 환경에서는 기본적으로 grouped 옵션으로 실행됩니다.

따라서 GitHub Actions에서 아래와 같은 명령어로 실행하면 로컬 환경과 동일하게 로그 출력 결과를 Task 정보와 함께 grep 할 수 있습니다.

LINT_OUTPUT=$(pnpx turbo lint --continue --log-order=stream 2>&1)
LINT_RESULTS=$(echo "$LINT_OUTPUT" | grep -E '✖')

아래 방법을 시도하기 전, 해당 오류에 대한 활발한 토론이 있었던 Github issue를 먼저 확인하고 시도해주시기 바랍니다.

링크: https://github.com/vitejs/vite/discussions/15532

Turborepo로 구성된 모노레포 환경에서 아래 명령어를 통해 Dockerfile을 빌드할 경우 정상적으로 동작하지만,

sudo docker build -f apps/{app-name}/Dockerfile .

잘 구성된 docker-compose를 이용한 빌드에서만 아래와 같은 오류가 발생했습니다.

sudo docker compose up --build

...

/app/node_modules/.pnpm/rollup@4.24.4/node_modules/rollup/dist/native.js:63
                throw new Error(
                      ^

Error: Cannot find module @rollup/rollup-linux-arm64-gnu. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.
    at requireWithFriendlyError (/app/node_modules/.pnpm/rollup@4.24.4/node_modules/rollup/dist/native.js:63:9)
    at Object.<anonymous> (/app/node_modules/.pnpm/rollup@4.24.4/node_modules/rollup/dist/native.js:72:76)
    at Module._load (node:internal/modules/cjs/loader:1023:12)
    at cjsLoader (node:internal/modules/esm/translators:356:17)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:305:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:218:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:329:24) {
  [cause]: Error: Cannot find module '@rollup/rollup-linux-arm64-gnu'
  Require stack:
  - /app/node_modules/.pnpm/rollup@4.24.4/node_modules/rollup/dist/native.js
      at Module._resolveFilename (node:internal/modules/cjs/loader:1144:15)
      at Module._load (node:internal/modules/cjs/loader:985:27)
      at Module.require (node:internal/modules/cjs/loader:1235:19)
      at require (node:internal/modules/helpers:176:18)
      at requireWithFriendlyError (/app/node_modules/.pnpm/rollup@4.24.4/node_modules/rollup/dist/native.js:45:10)
      at Object.<anonymous> (/app/node_modules/.pnpm/rollup@4.24.4/node_modules/rollup/dist/native.js:72:76)
      at Module._compile (node:internal/modules/cjs/loader:1376:14)
      at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
      at Module.load (node:internal/modules/cjs/loader:1207:32)
      at Module._load (node:internal/modules/cjs/loader:1023:12) {
    code: 'MODULE_NOT_FOUND',
    requireStack: [
      '/app/node_modules/.pnpm/rollup@4.24.4/node_modules/rollup/dist/native.js'
    ]
  }
}

해결 과정

해결을 시도하던 중 한가지 특이한 점을 발견했는데요, 바로 모든 node_modules 폴더를 삭제한 뒤 docker-compose build를 하면 빌드가 정상적으로 되는 것이었습니다.

원인 이해

원인은 모노레포의 루트 디렉토리의 node_modules 폴더를 docker-compose가 그대로 복사해가면서 발생하는 문제였습니다.

해결방법은 되지 못했지만 상세한 오류 원인에 대한 이해는 해당 글을 통해 할 수 있었는데요, 특정 rollup 플러그인 또는 패키지는 사용자 환경에 없는 플랫폼의 바이너리를 필요로 하기 때문에, 해당 플러그인을 필요로 한다는 점이었습니다.

즉 제가 Dockerfile에서 빌드용 이미지로 사용하는 node:20.11.1-alpine과 제 로컬 환경이 다르기 때문에 제 로컬 node_modules폴더를 복사해 갈 경우 문제가 발생한다는 것이었죠.

아마도, 패키지 관리자가 의존성을 설치하는 과정에서 환경에 따라 각각 다른 작업들을 해주는 것 같았고, 제 로컬 node_modules를 복사해 갈 경우 도커는 성능 최적화를 위해 특정 과정을 생략하면서 발생하는 문제 같았습니다.

해결

해결방법이 어처구니 없이 간단했는데요, 모노레포의 루트 폴더에 .dockerignore 파일을 추가해 주는 것입니다.

# .dockerignore

node_modules

이 경우 정상적으로 빌드된 이미지가 생성됩니다.

참고문서 https://github.com/vitejs/vite/discussions/15532 https://sandipdulal.medium.com/fixing-vite-build-error-on-linux-and-windows-using-docker-error-cannot-find-module-e73bb2fb479d

환경

필자의 프로젝트 환경은 Turbo와 pnpm 기반의 모노레포 개발 환경이며, React 앱을 Nginx를 이용해 제공하는 도커 컨테이너를 만들기 위해 아래와 같은 과정을 거쳤습니다.

예시 파일은 turbo의 Docker example을 기반으로 작성되었으며 필자의 환경과 일치하지는 않습니다. turbo의 예시와 다른 부분만 상세히 설명하겠습니다. 나머지 부분은 turbo의 가이드를 참고해주세요.

초기 환경 설정

FROM node:18-alpine AS base

FROM base AS builder
RUN apk add --no-cache libc6-compat
RUN apk update
WORKDIR /app

# pnpm으로 turbo를 global 설치하는게 생각대로 되지 않아 npm을 이용해 global 설치했습니다.
RUN npm install -g turbo@{version}

COPY . .

RUN turbo prune app-name --docker

pnpm 설치 및 turbo build

FROM base AS installer
ARG NODE_ENV
RUN apk add --no-cache libc6-compat
RUN apk update
WORKDIR /app

COPY --from=builder /app/out/json/ .
# pnpm-lock file을 같이 copy해줍니다.
COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml

# pnpm install시 세부적인 설정은 환경에 따라 다를 수 있습니다. 필자는 corepack을 사용했습니다.
RUN corepack enable && corepack prepare pnpm@{version} --activate
RUN pnpm install --frozen-lockfile --prod=false

COPY --from=builder /app/out/full/ .
# pnpx을 이용해 빌드가 필요한 app을 필터링해 turbo build를 실행합니다.
RUN pnpx turbo run build --filter={app-name}

Nginx 설정

FROM nginx:alpine

COPY ./apps/{app-name}/nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=installer /app/apps/{app-name}/dist /usr/share/nginx/html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

결과

FROM node:18-alpine AS base

# 빌드 단계
FROM base AS builder
RUN apk add --no-cache libc6-compat
RUN apk update
WORKDIR /app

RUN npm install -g turbo@{version}

COPY . .

RUN turbo prune app-name --docker

# 설치 단계
FROM base AS installer
ARG NODE_ENV
RUN apk add --no-cache libc6-compat
RUN apk update
WORKDIR /app

COPY --from=builder /app/out/json/ .
COPY --from=builder /app/out/pnpm-lock.yaml ./pnpm-lock.yaml

RUN corepack enable && corepack prepare pnpm@{version} --activate
RUN pnpm install --frozen-lockfile --prod=false

COPY --from=builder /app/out/full/ .

RUN pnpx turbo run build --filter={app-name}

# Nginx 설정 단계
FROM nginx:alpine
COPY ./apps/{app-name}/nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=installer /app/apps/{app-name}/dist /usr/share/nginx/html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

참고자료 https://turbo.build/repo/docs/guides/tools/docker https://github.com/vercel/turborepo/issues/5462

이적의 진중한 대화를 담은 콘텐츠를 발견하면 영상 전체를 챙겨보는 편이다. 성능 좋은 인공지능이 적절하게 정제된 단어들을 뽑아내는 것 같다고 할까, 뱉어내는 말 한 마디 한 마디가 전부 곱씹어볼 필요가 있는 이야기들이다.

얼마 전, 존박의 유튜브 '존이냐박이냐'에 이적이 나와 이야기한 내용 중 일부를 보고 든 생각이다.

~

이적은 비비의 <밤양갱>을 들으면서 가사에 'ㄴ', 'ㄹ'정도만 남겨서 '떠나는 길에 네가 내게 말했지'라는 물결처럼 지나는 벌스를 만들었다는 점에 감탄했다고 한다.

흥미로운 점은 노래가 히트한 한참 뒤에 이 이야기를 장기하에게 해줬더니, 정말 듣고싶었던 이야기였는데 이적에게 처음 들었다며 고마워 했다는 것이다.

이런 디테일까지 청중은 전혀 눈치채지 못했지만 <밤양갱>이라는 노래는 크게 히트했고, 노래가 좋은 이유는 모르지만 그저 노래가 좋다고 느끼는 거라고.

~

복잡한 기술과 최적화를 이용해 사용자 경험을 향상시키는 구체적인 내용은 사용자 입장에서 알 바 아니지만, "눈치챌까?" 싶어서, 혹은 이런 저런 핑계로 생략한 사소한 디테일들은 단 몇 픽셀, 몇 초의 화면 차이로 "구리다"고 느낀다.

구리지 않은 결과물을 만들려면, 역설적으로 사용자가 알지 못할 정도로 사소한 디테일에 집착해야 한다는 것.

그러면 사용자는 그 총체적인 결과물을 보며 "설명은 못하지만 왜인지 모르게 완성도가 높다"고 느낄 수 있지 않을까. 마치 좋은 음악을 들으면 기분이 좋아지는 것 처럼 말이다.

사진 출처: 가수 이적이 도파민 중독을 피하는 방법 - Youtube 존이냐 박이냐

혹시나 너무 복잡해서 시도조차 안하신 분들이 계실까봐 사실은 매우 간단하다는 것을 알려드리기 위해 방법을 소개드리겠습니다.

Home Assistant에 추가하려면

HA에 등록하는 목적이라면 토큰 발급 안해도 됩니다.

HA의 Xiaomi Miio에 ID와 비밀번호, 서버 위치를 입력하면 자동으로 지원되는 기기를 불러옵니다.

끝!

하지만, 자동으로 불러와지지 않는 경우 또는 다른 Home Bridge 등 사용을 위해 토큰을 얻어야 한다면 아래 방법을 이용하면 편합니다.

터미널로 토큰 얻기

Github - PiotrMachowski/Xiaomi-cloud-tokens-extractor

PiotrMachowski의 Xiaomi-cloud-tokens-extractor 리포지토리에는 샤오미 기기의 토큰을 얻는 여러 방법이 소개되어 있습니다. 그 중 가장 간단한 터미널을 이용한 방법을 소개드리겠습니다.

1. 터미널 명령어를 통해 shell script를 실행합니다.

bash <(curl -L https://github.com/PiotrMachowski/Xiaomi-cloud-tokens-extractor/raw/master/run.sh)

2. 공기청정기가 등록된 샤오미 계정의 아이디, 비밀번호를 입력합니다.

Username (email or user ID):

Password:

Server (one of: cn, de, us, ru, tw, sg, in, i2) Leave empty to check all available:

서버 정보를 입력하지 않으면 모든 서버를 탐색하므로 입력하지 않아도 됩니다.

입력한 아이디와 비밀번호를 통해 서버를 탐색하며 모든 기기의 등록 정보를 표시합니다.

Devices found for server "--" @ home "0000000000":
   ---------
   NAME:     ***
   ID:       ***
   MAC:      ***
   IP:       ***
   TOKEN:    ***
   MODEL:    ***
   ---------

끝!

macOS Sequoia에서 실행 오류

curl: (56) Failure writing output to destination, passed 63 returned 4294967295

맥os 세콰이어 업데이트 이후 이런 오류를 내며 실행이 안되는데요, 이 경우 수동으로 실행해줘야 합니다.

**1. 실행 파일 다운로드**

```bash
wget https://github.com/PiotrMachowski/Xiaomi-cloud-tokens-extractor/releases/latest/download/token_extractor.zip
unzip token_extractor.zip
cd token_extractor

*2. python 가상환경 구성 및 라이브러리 설치 *

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

*3. 파이썬 파일 실행 *

python3 token_extractor.py

이후 과정은 동일합니다.

jest@29 버전 기준으로 작성되었습니다.

단위 테스트 환경이 구성되어있다는 전제로 합니다. Vue3 + Jest@29 단위 테스트 환경 설정 - https://velog.io/@minu-j/Vue3-Jest29-unit-test

환경 구성

의존성 추가

$ yarn add -D @vue/test-utils @vue/vue3-jest jest-environment-jsdom ts-node

• @vue/test-utils: Vue 컴포넌트, 이벤트 트리거, DOM 조작 등 수행

• @vue/vue3-jest: Vue3 공식 jest 테스트 프리셋

• jest-environment-jsdom: Node.js환경에서 브라우저의 DOM 시뮬레이션하는 jsdom 환경을 jest에서 사용할 수 있도록 함

- jest@28부터 DOM 시뮬레이션 라이브러리가 기본으로 포함되지 않습니다.

• ts-node: Node.js환경에서 동작하는 TypeScript 런타임, TypeScript 파일을 실행할 수 있도록 함

Jest 설정 파일 수정

jest.config.ts

import type { Config } from 'jest';

const config: Config = {
  ...
  testEnvironment: 'jest-environment-jsdom', // jsdom 환경 구성
  testEnvironmentOptions: {
    customExportConditions: ['node', 'node-addons'],
  },
  ...
  transform: {
    ...
    '^.+\\.vue$': '@vue/vue3-jest', // .vue 파일의 트랜스파일링 옵션을 '@vue/vue3-jest'로 설정
  },
};

export default config;

테스트 파일 예시

someComponent.test.ts

import { describe, expect, it } from '@jest/globals';
import { someComponent } from '@/.../someComponent.vue';

describe('someComponent 컴포넌트테스트', () => {
  it('컴포넌트테스트의 상세 테스트 항목', () => {
    const wrapper = mount(TestVue, {
      props: {
        ...
      },
    });
    expect(wrapper.text()).toContain('Hello World!');
  });

  ...
});

테스트 실행

yarn test
# or
yarn test --watch

참고 자료

Vue 공식문서 컴포넌트 테스트 - https://ko.vuejs.org/guide/scaling-up/testing#component-testing

Vue test utils 공식문서 - https://test-utils.vuejs.org/

vue-jest 공식문서 - https://github.com/vuejs/vue-jest

jest 공식문서 - https://jestjs.io/docs/configuration

Vue@3.4, jest@29 버전 기준으로 작성되었습니다.

Vue3에서는 vitest가 더 빠르고 다양한 테스트에 대응하기 때문에 vitest의 사용을 추천합니다. 하지만 vitest를 사용하지 못하는 특수한 경우에 Jest 29버전으로 환경 설정을 하기 위한 내용입니다.

환경 구성

의존성 추가

$ yarn add -D jest @jest/global @babel/core @babel/preset-env @babel/preset-typescript babel-jest

• jest: 자바스크립트 및 TypeScript 프로젝트에서 단위 테스트를 위한 테스트 프레임워크

• @jest/global: Jest의 글로벌 API를 사용할 수 있도록 합니다.

• @babel/core: 최신 자바스크립트 문법을 구 버전 브라우저에서도 동작하게 변환해주는 Babel의 핵심 패키지

• @babel/preset-env: Babel이 특정 환경에 맞추어 자동으로 필요한 플러그인을 설정해주는 Babel 프리셋

• @babel/preset-typescript: TypeScript 코드를 Babel이 이해할 수 있는 JavaScript로 변환하기 위한 Babel 프리셋

• babel-jest: Jest와 Babel을 통합하여 Jest가 Babel을 사용해 코드를 변환할 수 있도록 합니다.

설정 파일 수정

.eslintrc.json

jest의 lint 설정을 활성화합니다.

{
  env: {
    ...
    "jest": true
  },
  ...
}

babel.config.js

module.exports = {
  ...
  presets: [
    ...
    ['@babel/preset-env', { targets: { node: 'current' } }],
    '@babel/preset-typescript',
  ],
  ...
};

tsconfig.json

TypeScript 컴파일러가 test파일을 처리할 수 있도록 합니다.

{
  "include": [
    ...
    "src/**/*.test.ts"
  ],
  ...
}

package.json

test script를 추가합니다.

{
  ...
  "scripts": {
    ...
    "test": "jest"
  },
  ...
}

Jest 설정 파일 생성

jest.config.ts

import type { Config } from 'jest';

const config: Config = {
  moduleFileExtensions: ['js', 'ts', 'json', 'vue'], // 확장자가 없는 파일의 import 우선순위를 설정
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/src/$1', // '@/*' alias 설정
  },
  modulePathIgnorePatterns: [ // jest 파일이 포함되지 않을 경로 설정
    '<rootDir>/node_modules',
    '<rootDir>/build',
    '<rootDir>/dist',
    '<rootDir>/.yarn',
  ],
  transform: { // 트랜스파일링 옵션 설정
    '^.+\\.js': 'babel-jest',
    '^.+\\.ts': 'babel-jest',
  },
};

export default config;

테스트 파일 예시

doSomething.test.ts

import { describe, expect, it } from '@jest/globals';
import { doSomething } from './doSomething.ts';

describe('doSomething 단위테스트', () => {
  it('단위테스트의 상세 테스트 항목', () => {
    expect(doSomething('say something')).toBe('Hello World!');
  });

  ...
});

실행

yarn test
# or
yarn test --watch

참고 자료

Vue 공식문서 단위 테스트 - https://ko.vuejs.org/guide/scaling-up/testing#unit-testing

Jest 공식문서 - https://jestjs.io/docs/configuration

로컬 환경에서 프론트엔드 개발을 할 때 반드시 HTTPS와 Proxy가 동시에 필요한 시점이 옵니다. 예를 들어 백엔드 개발 환경에 API 요청을 한다거나, 인증을 위해 백엔드에서 Cookie설정을 하는 경우 기본적인 로컬 개발환경에서는 한계가 있습니다.

이러한 불편을 해결하기 위해 로컬 환경에서도 개발 환경과 동일한 조건에서 테스트를 진행하기 위한 환경 구성하는 것이 필요한데요, Webpack 또는 Vite의 DevServer를 이용하는 일반적인 환경의 React나 Vue 프로젝트의 경우 위 조건을 구성하는 것이 매우 간단합니다.

하지만 Next는 풀스택 프레임워크의 특성상 지금껏 했던 것과는 약간 다른 방법으로 개발 환경을 구성해야 했습니다.

이 글에서는 Next 14를 이용한 프론트엔드 로컬 개발환경에서 HTTPS로 서버를 실행하고, Proxy middleware를 통해 서버와 통신하기 위해 제가 구성한 방법을 기록하겠습니다.

개발 환경 Next 14.2.1 macOS Sonoma 14.2

목표

• 로컬 프론트엔드 서버가 개발환경의 백엔드와 API 통신을 문제없이 할 수 있습니다.

구현

HTTPS

기존에 주로 사용한 Vite를 예로 들면 HTTPS서버를 로컬에서 실행하는 것은 아주 간단했는데요,

// ./package.json

"scripts": {
      "dev:https": "HTTPS=true SSL_CRT_FILE=localhost.pem SSL_KEY_FILE=localhost-key.pem vite",
  ...
}

HTTPS서버를 위한 인증 pem키를 발급받고, 위 스크립트만 실행하면 HTTPS 로컬 환경을 구성할 수 있었기 때문입니다.

하지만 Next 14에서는 별도의 Custom server를 이용해 프론트엔드 서버를 직접 구성해줘야 합니다.

1. SSL 키 발급

우선 SSL인증을 위해 프로젝트 root 경로에서 mkcert를 이용해 pem키를 발급받습니다.

아래 방법은 macOS를 기준으로 작성되었습니다.

$ brew install mkcert

$ mkcert -install

$ mkcert localhost

또는, 공동으로 작업하는 환경의 경우 shell script를 이용해 더 간편하게 키를 발급받을 수 있습니다.

// ./init-ssl.sh

#!/bin/bash

MKCERT_INSTALLED=$(which mkcert)

if [ -z $MKCERT_INSTALLED ];then
    brew install mkcert
fi

mkcert -install
mkcert localhost

이후 package.json에 해당 shell을 실행하는 script를 생성합니다.

// ./package.json

"script": {
  "init:ssl": "sh init-ssl.sh",
  ...
}

그럼 localhost.pem, localhost-key.pem 두 파일이 생성됩니다.

2. Custom server 구성

HTTPS 서버 환경 구성을 위해 Custom server로 프론트엔드 로컬 서버를 구축할 것입니다.

Root 경로에 server.js를 생성합니다.

node.js로 서버를 구성하는데요, 라우팅 등 프론트엔드 서버로서의 기본적인 역할은 next가 알아서 해줄테니 걱정하지 않아도 됩니다. 저희는 특정 로컬 포트로 서버를 열어주기만 할거에요.

우선 필요한 패키지들을 import해줍니다.

// ./server.js

const http = require('http');
const https = require('https');
const fs = require('fs');
const { parse } = require('url');
const next = require('next');

production환경에서는 실행되지 않도록 NODE_ENV를 확인하고, NextServer를 선언합니다.

// ./server.js

const dev = process.env.NODE_ENV !== 'production';
const app = next({ dev });
const handle = app.getRequestHandler();

NextServer가 구성되면 HTTP와 HTTPS 서버를 지정된 포트로 열어줍니다. HTTPS서버를 생성할 때에는 option에 아까 생성한 pem키를 넣어줍니다.

// ./server.js

app.prepare().then(() => {
  const HTTP_PORT = process.env.HTTP_PORT;
  const HTTPS_PORT = process.env.HTTPS_PORT;

  const httpServer = http.createServer((req, res) => {
    const parsedUrl = parse(req.url, true);
    handle(req, res, parsedUrl);
  });

  const httpsServer = https.createServer(
    {
      cert: fs.readFileSync(`${process.env.HTTPS_CERT_PATH}.pem`),
      key: fs.readFileSync(`${process.env.HTTPS_KEY_PATH}.pem`),
    },
    (req, res) => {
      const parsedUrl = parse(req.url, true);
      handle(req, res, parsedUrl);
    },
  );

  httpServer.listen(HTTP_PORT, err => {
    if (err) throw err;
    console.log(`> Ready on http://localhost:${HTTP_PORT}`);
  });

  httpsServer.listen(HTTPS_PORT, err => {
    if (err) throw err;
    console.log(`> Ready on https://localhost:${HTTPS_PORT}`);
  });
})

package.json에 next를 실행하는 대신 방금 만든 server.js를 실행하는 script를 추가합니다.

// ./package.json

"script": {
  "dev:https": "node server.js",
  ...
}

터미널에 해당 명령어를 입력하면 정상적으로 HTTPS서버가 실행됩니다.

$ npm run dev:https

> app-name@0.1.0 dev:https
> node server.js

> Ready on http://localhost:3000
> Ready on https://localhost:3001

Proxy

Custom server를 사용하지 않을 때

지금까지 HTTPS로 로컬 서버를 실행해보았는데요, Custom server를 사용하지 않을 때는 Next의 rewrites option을 활용하면 특정 요청의 origin이나 path를 변형하는 것이 매우 간단합니다.

//next.config.mjs

const nextConfig = {
  async rewrites() {
    return [
      {
        source: "/api/:path*",
        destination: `https://.../:path*`
      },
    ];
  },
};

이런식으로 nextConfig에 rewrites를 설정해주면 특정 source에서 가는 요청의 도메인을 바꿔 브라우저에서 동일한 origin의 통신으로 인식하게 해 CORS 오류가 발생하지 않습니다.

또는 로컬과 개발 환경에서 api path가 상이할 경우에도 쉽게 path를 변형해 api를 요청할 수 있습니다.

Custom server를 사용할 때

하지만 custom server를 이용해 HTTPS로 로컬 서버를 구성했을 경우, nextConfig의 Proxy 설정이 적용되지 않았습니다.

이런 경우 next에서 제공되는 middleware를 이용해 간단하게 전역 Proxy middleware를 구성할 수 있습니다.

우선 app 폴더와 동일한 최상위 경로에 middleware.ts파일을 생성해줍니다. 저는 ./src 하위에 app 폴더를 생성했으므로 ./src/middleware.ts를 생성해줬습니다.

middleware 함수를 선언해줍니다. NextResponse의 rewrite 메서드를 이용하면 전송되는 api의 path를 요청 앞단에서 변경해줍니다.

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const rewritePath = `${process.env.NEXT_PUBLIC_API_URL}/${request.nextUrl.pathname}`;

  console.log(`[Proxy]: ${request.url} => ${rewritePath}`);

  return NextResponse.rewrite(new URL(rewritePath));
}

단, 이 방법으로 middleware를 구성할 경우 모든 api요청, next의 정적 리소스를 포함하여 모든 요청들이 이 middleware를 타면서 path가 rewrite됩니다.

그러므로 특정 uri path에서만 middleware가 작동하도록 설정을 해주어야 합니다.

export const config = {
  matcher: ['/api/:path*'],
};

또는, 여러 path에 대해 조건부로 middleware의 동작이 필요할 경우 함수 내부에 조건문으로 분기해줄 수 있습니다.

export function middleware(request: NextRequest) {
  if (request.nextUrl.pathname.startsWith('/api')) {
    const rewritePath = `${process.env.NEXT_PUBLIC_API_URL}${request.nextUrl.pathname}`;

    console.log(`> [Proxy] ${request.url} => ${rewritePath}`);
    return NextResponse.rewrite(new URL(rewritePath, request.url));
  }

  return NextResponse.next();
}

이렇게 설정하면 /api/... 로 시작하는 모든 endpoint의 요청은 특정 origin의 요청 헤더를 가지고 요청되므로 브라우저의 CORS정책에 위배되지 않습니다.

...
 ✓ Compiled /src/middleware in 217ms (71 modules)

[Proxy]: https://localhost:3000/api/v1/game/cnt => https://.../api/v1/game/cnt

 GET /favicon.ico 200 in 5ms
...

NODE ENV가 'development'인 경우에만 middleware를 동작하게 하기 위해 함수의 첫줄에 조건문을 하나 적어줍니다.

if (process.env.NODE_ENV !== 'development') return NextResponse.next();

끝

정상적으로 구현이 된다면,

• Next는 로컬에서 server.js의 custom server를 통해 실행되고, 발급받은 pem키를 이용한 SSL인증으로 HTTPS로 서버를 실행합니다.

• Proxy를 이용해 개발환경의 백엔드 서버와 CORS문제 없이 JSON을 주고 받습니다.

• Google 등 SSO를 이용해 OAuth2로 로그인 할 때 로컬에서도 문제 없이 로그인 할 수 있습니다.

• Origin이 다른 백엔드 서버와 API통신을 할 때에도 브라우저가 CORS 오류를 발생시키지 않습니다.

• Refresh token 등 사용자 인증을 위해 백엔드에서 httpOnly, sameSite 등 보안 설정이 된 Set-Cookie 헤더의 데이터가 문제없이 쿠키에 저장됩니다.

즉, 로컬 서버의 프론트엔드를 개발환경에 배포된 프론트엔드처럼 동일한 동작을 테스트해볼 수 있습니다.

Vue Query란?

Vue Query는 Tanstack에서 개발한 server state management 라이브러리입니다. 공식적으로 React, Vue, Solid, Svelte 4가지의 프론트엔드 프레임워크를 지원하며, TanStack Query에서 각 프레임워크 별 이름을 따 Vue에서 작동하는 라이브러리의 경우 Vue Query라고 부릅니다.

개요

TanStack Query (FKA Vue Query) is often described as the missing data-fetching library for web applications, but in more technical terms, it makes fetching, caching, synchronizing and updating server state in your web applications a breeze.

Vue Query는

• 서버로부터 데이터 가져오기

• 캐싱

• 서버 데이터를 서버와 동기화하고 업데이트하기

주로 세 가지 기능을 수행하기 위해 만들어졌다고 설명합니다.

왜 사용해야 할까?

React, Vue 등 유명 웹 프레임워크에는 서버 데이터를 fetching, caching, synchronizing, updating하는 “일반적인” 또는 “공통화 된” 방식을 제공하지 않는 것을 문제로 제시합니다.

때문에 데이터를 가져오고, 관리하는 방법을 고민하고, 개발자마다 매우 다른 방식으로 개발되는 것에 대한 문제점을 이야기합니다.

또한 기존 상태 관리 라이브러리로 서버 데이터를 관리하는것도 적합하지 않다고 말합니다. Server state와 client state는 전혀 다르기 때문입니다.

Server state의 차이점 (Client state와 비교하여)

• 프론트엔드 개발자가 통제할 수 없는 위치에 데이터가 저장되어 있다.

• 가져오거나 업데이트를 하기 위해 비동기적으로 API를 이용해야 한다.

• 다른 사람과 데이터를 공유하며, 본인이 모르게 다른 사람이 데이터를 변경할 수 있다.

• 자칫 데이터가 “오래된” 데이터가 될 수 있다.

이 차이점을 해결하기 위해 개발하다보면 다음과 같은 문제점을 마주치게 될 것이라고 말합니다.

• 캐싱 → 가장 어려운 일

• 동일한 여러 요청을 단일 요청으로 보내 중복 제거하기

• 백그라운드에서 “오래된” 데이터 업데이트

• 데이터가 “오래된” 시점을 파악하기

• 최대한 빠르게 데이터 업데이트를 반영하기

• Pagenation, Lazy loading 등 성능 최적화

• Server state의 메모리 관리, garbage collection

• 서버 데이터 메모이제이션

개발자는 이 모든 문제들을 해결하기 매우 어렵고, 놓치기 쉽다고 설명하며, Vue Query는 이러한 Server state의 까다로운 문제점들을 쉽게 극복하게 해준다고 설명하고 있습니다. Vue Query를 사용하면 위 문제들을 크게 신경쓸 필요 없이 기본적으로 “알아서”, “잘” 작동합니다.

주요 개념

Queries

쿼리(query)는 QueryKey라는 unique한 key에 연결된 데이터의 비동기적인 출처(asynchronous source)에 대한 선언적 종속성(declarative dependency)입니다.

쉽게 설명하면, 데이터를 가져오는 함수와 가져온 데이터, 그리고 unique한 key값의 한 단위를 이야기한다고 할 수 있습니다.

컴포넌트 또는 hook에서 쿼리를 구독(subscribe)하기 위한 방법입니다.

import { useQuery } from '@tanstack/vue-query'

const result = useQuery({ queryKey: ['todos'], queryFn: getTodoList })

Query Keys

전역적으로 쿼리를 refetch하고, caching하고, 공유하는 데 내부적으로 사용되는 key값입니다.

Query key는 기본적으로 상수값의 배열로 선언되며, 문자열, 숫자, 객체, 배열 등 다양한 값을 포함할 수 있습니다.

// 하나의 문자열도 배열로 선언해야 합니다.
useQuery({ queryKey: ['todos'], ... })

// 다양한 값들이 배열에 포함될 수 있으며, 모두 다른 key로 취급되어 각각 별도로 캐싱됩니다. 
useQuery({ queryKey: ['todos', 0 ], ... })
useQuery({ queryKey: ['todos', 1 ], ... })

// 객체 내부도 깊은 비교를 통해 다른 key로 취급합니다.
useQuery({ queryKey: ['todos', { filter: 'done' } ], ... })
useQuery({ queryKey: ['todos', { filter: 'unfinished' } ], ... })

// 배열은 순서가 다르면 다른 값으로 취급되지만,
useQuery({ queryKey: ['todos', [0, 1] ], ... })
useQuery({ queryKey: ['todos', [1, 0] ], ... })

// 객체는 순서가 달라도 같은 값으로 취급됩니다.
useQuery({ queryKey: ['todos', { filter: 'done', page: 3} ], ... })
useQuery({ queryKey: ['todos', { page: 3, filter: 'done'} ], ... })

Query Function에서 사용하는 모든 변수는 Query Key에 포함되어야 합니다. 변수에 의존하는 각각 다른 속성값(페이지, 필터 등)을 가진 데이터 배열을 별도로 캐싱할 수 있습니다.

function useTodo(page: number, filter: 'done' | 'unfinished') {
    return useQuery({ queryKey: ['todos', { page, filter } ], ... })
}

이 경우 0페이지와 1페이지는 별도로 캐싱됩니다.

만약 0페이지에서 1페이지에 방문했다가 빠르게 0페이지에 되돌아가더라도 굳이 0페이지를 다시 로드할 필요가 없어집니다.

• 불필요한 API 호출을 줄여 성능을 최적화하고,

• 빠른 데이터 표시를 통해 사용자 경험을 개선합니다.

Query Functions

해당 쿼리의 데이터 또는 error값의 Promise를 return하는 함수입니다.

쿼리 함수는 Promise를 반환하는 모든 형태의 함수입니다.

• 데이터를 반환하거나

• 오류를 발생시켜야 합니다.

발생한 오류는 error 에 저장됩니다.

const { error } = useQuery({ ... })

Query Function Variables

Query Key는 쿼리의 유니크한 구분값의 역할, 쿼리 함수가 의존하는 변수의 구분을 통한 캐싱 뿐 아니라 직접 쿼리 함수의 변수로도 사용될 수 있습니다.

const result = useQuery({
  queryKey: ['todos', { status, page }],
  queryFn: getTodoList,
})

// 쿼리 키를 매개변수로 받으면 status, page 변수에 접근할 수 있습니다.
function fetchTodoList({ queryKey }) {
  const [_key, { status, page }] = queryKey
  return new Promise()
}

Mutations

단순히 조회성 쿼리가 아닌, 데이터를 생성(POST), 업데이트(PUT), 삭제(DELETE)하는 데 사용됩니다.

import { useMutation } from '@tanstack/vue-query'

const { mutate } = useMutation({
  mutationFn: (newTodo) => postTodo(newTodo),
})

function addTodo() {
  mutate({ id: new Date(), title: '뷰쿼리 공부하기' })
}

데이터를 변형하는 API의 경우 useQuery가 아닌 useMutations를 사용해야 합니다.

Mutation Function 호출 이후 여러 상황에 대한 콜백을 지원합니다.

useMutation({
  mutationFn: addTodo,
  onMutate: (variables) => { },
  onError: (error, variables, context) => { },
  onSuccess: (data, variables, context) => { },
  onSettled: (data, error, variables, context) => { },
})

Query Invalidation

무언가 사용자의 작업으로 인해 쿼리가 변형되었다는 것이 매우 확실할 때에도 쿼리가 오래된(stale) 데이터가 되어 백그라운드에서 자동으로 refetch될 때 까지 기다리는 것은 조금 이상합니다.

Query Invalidation은 특정 Query Key를 가진 쿼리의 데이터가 더이상 유효하지 않음을 선언하고, 쿼리를 무효화하여 강제로 refetch되게 합니다.

예를 들어, todoList를 조회한 이후 특정 todo를 수정하거나, 새로운 todo를 생성해 todoList의 refetch가 필요할 경우, ‘todos’로 시작하는 Query Key를 가진 쿼리들의 데이터를 무효화합니다.

// `todos`로 시작하는 Query Key를 가진 캐시된 쿼리들을 무효화합니다.
queryClient.invalidateQueries({ queryKey: ['todos'] })

이렇게 되면 아래 Query Key를 가진 캐시된 쿼리가 있을 경우

[ 'todos', { page: 0, size: 10 } ]

[ 'todos', { page: 1, size: 10 } ]

[ 'todos', { page: 0 } ]

[ 'todos' ]

전부 refetch됩니다.

또는 모든 쿼리들이 유효하지 않아지는 일이 발생할 경우, 모든 쿼리를 무효화할 수도 있습니다.

// 모든 캐시된 쿼리를 무효화합니다.
queryClient.invalidateQueries()

invalidateQueries()가 실행될 경우 아래와 같은 일이 발생합니다.

• 데이터가 stale하다고 표시

• 쿼리가 렌더링되고 있을 경우 백그라운드에서 데이터 refetch

Vue Query가 알아서 하는 일들

Out of the box, TanStack Query is configured with aggressive but sane defaults.

Vue Query는 공격적이지만 정상적인 기본값이 설정되어 있다고 설명합니다. 즉, 서버 상태의 효과적인, 효율적인 관리를 위해 적극적으로 개입하는 라이브러리 라는 것입니다.

때문에 Vue Query를 사용하기 위해서는 어떤 부분들을 기본적으로 수행해주는지 필수적으로 알아야 당황하지 않고 Vue Query의 기능을 최대한 활용할 수 있습니다.

useQuery 또는 useInfiniteQuery를 이용해 생성한 쿼리 인스턴스는 캐시된 데이터를 오래된(stale) 데이터로 간주합니다.

오래된 데이터 → stale queries

• staleTime을 전역적으로, 또는 쿼리별로 설정할 수 있습니다.

• staleTime을 길게 설정하면 쿼리 데이터를 자주 가져오지 않습니다.

오래된 데이터(stale queries)는 다음과 같은 상황에 백그라운드에서 자동적으로 refetch됩니다.

자동적으로 refetch되는 조건

• 새로운 query가 마운트될 때 - New instances of the query mount

• 윈도우가 다시 focus될 때 - The window is refocused

• 네트워크가 재연결 되었을 때 - The network is reconnected

• Refetch 주기가 설정되어 있을 때 - The query is optionally configured with a refetch interval

위 조건들은 각각 다음과 같은 옵션으로 사용자화 할 수 있습니다.

• refetchOnMount

• refetchOnWindowFocus

• refetchOnReconnect

• refetchInterval

예상치 못한 refetch가 너무 자주 일어난다면 “윈도우가 다시 focus될 때”조건을 의심해봐야 합니다.

쿼리의 활성 인스턴스가 없을 경우 비활성(inactive) 레이블이 지정되며, 나중 사용을 대비해 캐시에 남아있습니다.

• 비활성(inactive) 쿼리들은 기본적으로 5분 이후 garbage collect됩니다.

• cacheTime설정을 변경하면 이 시간을 수정할 수 있습니다.

실패한 쿼리는 기하급수적인 백오프 지연(exponential backoff delay)을 사용해 자동으로 3번 재시도합니다.

• retry 또는 retryDelay설정값을 변경할 수 있습니다.

• 기본 시도 횟수 3 을 수정할 수 있고, 백오프 함수도 수정 가능합니다.

쿼리 결과는 구조적으로 공유되어(structurally shared) 데이터가 실제로 변경되었는지 감지합니다. 변경되지 않은 데이터는 참조된 변수값도 변경하지 않아 최적화에 도움을 줍니다.

• 낯선 개념이지만 99.9%의 상황에서 도움이 되며 비용이 들지 않고, 앱의 성능을 향상할 수 있다고 말합니다.

• JSON 형식의 데이터만 지원됩니다.

• 만약 매우 큰 응답값으로 인해 성능 문제가 발생한다면 structuralSharing 을 비활성화할 수 있습니다.

뷰쿼리를 사용해 해결된 것들

• 간단한 코드, fetch 코드의 스타일 통일화

  • 대부분의 상황에서 알아서 server state를 관리합니다.

  • 간단하고 명확한 메서드를 제공합니다.

  • fetch코드가 매우 단순하고, 가독성이 높아집니다.

  • 개발자마다 각기 다른 fetch 코드 스타일을 공통화해줍니다.

• 기본 제공되는 손쉬운 캐싱, 다양한 라이프사이클에 대한 유기적인 대응

  • 자동으로 서버 데이터를 캐싱해줍니다.

  • 다양한 메서드를 이용해 여러 상황의 라이프사이클에 대응합니다.

  • 필요한 경우 상세한 사용자 정의를 통해 쿼리를 관리할 수 있습니다.

• fetch 코드의 재사용성 증가

  • 전역적으로 관리되기때문에 굳이 캐싱을 위해 store를 거칠 필요가 없습니다.

  • 컴포저블로 useQuery를 사용하면 재사용성이 높은 코드를 작성할 수 있습니다.

읽어보면 좋을 글 공식문서가 매우 친절합니다. 공식문서에 쓰여진 대부분의 내용은 사용하는데 큰 도움이 됩니다. Overview | TanStack Query Docs

큰 프로젝트에서 Query Key를 효과적으로 관리하기 위한 전략은 필수적입니다. Query Key가 중복될 위험이 있기 때문입니다. Effective React Query Keys

공식 문서에서 중요한 개념과 내용들을 간단하게 정리해 놓은 글입니다. React Query 공식 문서 간단 정리

Tanstack Query에 대한 자세한 내용들을 한국어로 정리해 놓은 문서입니다. ssi02014/react-query-tutorial: 😃 TanStack Query(aka. react query) 에서 자주 사용되는 개념 정리

카카오페이에서 React Query를 도입한 이유를 작성한 글입니다. 카카오페이 프론트엔드 개발자들이 React Query를 선택한 이유

참고 자료

https://vuejs.org/guide/scaling-up/state-management.html

https://simplevue.gitbook.io/intro/03.-state-props

https://velog.io/@peterhyun1234/Frontend-Development-What-is-State-Management

https://tanstack.com/query/v4/docs/vue/overview

서버에서 불러온 데이터(Server state)는 사용자의 데이터(Client state)와 별도로 관리하는 것이 세계적인 프론트엔드 추세이며, TanStack Query는 Server state management의 표준으로 자리잡은 라이브러리이다.

TanStack Query의 장점

1. 공통화되고, 선언적인 API 요청 관련 코드를 간편하게 작성할 수 있다.

2. QueryKey를 이용하여 서버 데이터를 전역적으로 캐싱해 불필요한 API 호출을 최소화한다.

3. 예측 가능한 적절한 타이밍에 서버 데이터를 업데이트(refetch)할 수 있다.

작성 배경

State에 대한 기본 개념 정리부터, Client state, Server state를 구분하는 프론트엔드의 추세, Server state를 효과적으로 관리하는 라이브러리인 TanStack Query에 대해 알아봤습니다.

State에 대한 관리가 고도화되는 흐름에 맞춰 각 방식의 문제점과, 해결 방안, 그리고 서버 상태 관리 라이브러리의 필요성을 중점으로 정리했습니다.

Tanstack 공식문서의 Vue Query v4 문서를 기준으로 작성했습니다.

State management

State

React: 컴포넌트 안에서 관리되며 변경되면 컴포넌트를 리렌더링하는 JavaScript 객체

Vue: 앱 구동에 필요한 기본 데이터 소스.

특정 DOM만 사용자에게 다시 보여주는 SPA에서 화면을 업데이트 하는 조건은 “사용자에게 표시할 화면의 ‘데이터’가 변화되었는가?”입니다. 사용자에게 보여줄 화면의 데이터가 바뀌면 당연히 화면을 새로 그려야 하기 때문입니다. Single page 애플리케이션은 이 필요때문에 데이터, 즉 state가 변하면 화면을 새로 그릴 수 있도록(re-render) 설계되어 있고, 변화가 필요한 특정 DOM에 데이터를 Bind해 변화되는 데이터를 페이지 새로고침 없이 사용자에게 보여줍니다.

다루는 데이터가 얼마 되지 않는 애플리케이션의 state는 물론 신경쓰지 않고 편한대로 관리할 수 있겠지만, 화면에 보여줘야 하는 데이터의 종류가 매우 다양하고, 데이터의 라이프 사이클이 제각기 다르기 때문에 state의 철저한 관리는 필수적입니다.

상태 관리

State는 화면을 렌더링한다는 특징을 제외하면, 결국 JavaScript의 객체 변수이기 때문에 제대로된 관리가 없다면 손실되거나 사라져버릴 수 있고, 컴포넌트 간 공유도 복잡하고 어렵습니다. 특히, State의 변화는 화면의 렌더링으로 이어진다는 특성상, State의 무분별한 관리는 브라우저 성능에도 큰 영향을 미칩니다. 필요한 화면의 일부만 교체하며 화면을 표시해 성능을 개선하는 가상DOM의 이점을 전혀 활용하지 못할 것입니다.

State의 철저한 관리가 필요한 이유

• 사용자에게 필요한 데이터를 적절하게 유지하고 관리해야 합니다.

• State는 화면을 렌더링하는 성능에 영향을 미칩니다.

• 민감한 데이터의 경우 보안 문제가 생길 수 있습니다.

• 코드의 유지보수를 위해서는 데이터의 흐름을 파악할 수 있어야 합니다.

Vue에서의 상태 관리

Vue에서는 데이터의 변화를 감지하기 위해 상태를 ‘반응형’ 데이터로 관리합니다. 반응형 상태 선언을 위해 권장되는 형태는 ref() 함수를 사용하는 것입니다.

const age = ref('27')

2024년으로 해가 바뀌어서 나이를 먹었다면, 다음과 같이 상태를 변경하면 화면을 리렌더링 합니다.

age.value++

state는 Vue의 <script setup /> 태그 내에서 작성되어 화면을 리렌더링 하는 조건이 됩니다.

그런데 이 경우 state는 해당 state가 선언 된 특정 .vue파일 내부 스코프에서만 유효합니다. 다른 컴포넌트에서 데이터에 접근하려면 props를 명시적으로 선언해야 하고, 외부에서 컴포넌트에 props를 넘겨 데이터를 공유합니다.

<script setup>
const { age } = defineProps<{ age: number }>()

console.log(age) // 27
</script>

문제점

그런데 문제가 있습니다. props는 무조건 컴포넌트 내부에 선언된 컴포넌트에만 데이터를 넘겨줄 수 있다는 것입니다.

출처: Passing Data Deeply with Context

만약 상하 컴포넌트 구조가 매우 복잡한 프로젝트라면 데이터를 하위 컴포넌트에 직접 넘겨주는 props로는 데이터를 전달하는 데 무리가 있습니다.

여러 컴포넌트를 건너 데이터가 전달되는 구조에서

• **데이터의 흐름이 어떻게 관리되고 있는지

• *

• **State 변경으로 인한 컴포넌트 리렌더링이 어떻게 일어나는지

• *

• **데이터가 유실되거나, 함부로 변경되지 않고 있는지

• *

개발자는 예측하기 매우 어렵습니다.

Local state와 Global state

Global state는 이런 props의 단점을 극복하기 위해 등장한 개념입니다. 기존의 state는 이제 local state(지역 상태)와 global state(전역 상태)로 구분됩니다.

• Local state: 컴포넌트 내부에서, 해당 컴포넌트를 리렌더링하는 state

• Global state: 여러 컴포넌트에서 전역적으로 호출되며, 부모-자식 관계와 상관 없이 컴포넌트를 리렌더링하는 state

그리고 일반적으로 global state는 관리의 편의를 위해 라이브러리를 이용합니다.

전역적인 상태 관리가 필요한 이유

1. 데이터 지속: 새로고침되어 자바스크립트 변수가 새로 선언되지 않는 이상, 컴포넌트와 무관하게 데이터를 유지합니다.

2. 컴포넌트 간 소통: 부모-자식 관계와 무관하게 전역적으로 컴포넌트 간 데이터 소통을 할 수 있습니다. 변경된 데이터는 의존관계를 갖지 않는 컴포넌트들을 리렌더링 하게 합니다.

3. 예측 가능성: 위에서 설명한 데이터의 흐름과 컴포넌트의 리렌더링, 데이터의 손상을 예측 가능하도록 합니다.

문제점

State에는 완전히 다른 라이프사이클을 가지는 두 종류의 데이터가 있습니다.

• 사용자가 브라우저에서 직접 만들어내거나 편집하는 데이터

• 서버에서 fetch해 가져오는 데이터

이 두 가지의 데이터를 지금처럼 혼합해 관리한다면 문제가 발생합니다.

사용자의 데이터, 서버 데이터 둘 중 하나만 변경되어도 바인딩된 컴포넌트들이 전부 리렌더링 됩니다.

계속 말씀드렸듯이 불필요한 렌더링은 성능 문제를 일으키기 때문에 항상 경계해야 합니다.

서버 데이터는 비효율적으로 여러번 호출될 수 있습니다.

일반적으로 데이터가 필요해 data fetch 함수가 동작되는 상황은 컴포넌트가 마운트될 때입니다. 따라서 다음과 같은 코드를 작성할 수 있습니다.

onMounted(async () => {
    await axios.get(...); // 컴포넌트가 마운트될 때 서버 데이터를 요청합니다.
});

하지만, 다음과 같은 경우를 생각해볼 수 있습니다.

• 데이터를 가져온지 몇 초만에, 또 다른 컴포넌트가 동일한 데이터를 요청한다면?

• 여러 자식 컴포넌트에서 동일한 데이터를 요청한다면?

• 별로 자주 변하지도 않는 데이터인데 컴포넌트 마운트가 수시로 발생한다면?

불필요한 API 요청이 자주 발생할 수 밖에 없습니다.

예를 들어 특정 Table 컴포넌트에서 페이지를 수시로 변경한다고 생각해보겠습니다.

const onChangePage = async () => {
    await axios.get(...); // Table의 page가 변경될 때 서버 데이터를 요청합니다.
};

Table의 페이지를 2페이지로 넘겼다가 1초만에 금방 다시 1페이지로 돌아왔을 때, 방금 막 불러왔던 1페이지를 또 불러와야 합니다.

불필요한 API 요청 자체도 문제이지만, 데이터를 자바스크립트에서 효율적으로 캐싱할 수 있다면 데이터를 매우 빠르게 화면에 표시할 수 있으므로 사용자 경험에 긍정적인 영향을 미칠 것입니다.

Client state와 Server state

위 같은 문제를 해결하기 위해 지금까지 local state와 global state라고만 구분되었던, 사용자가 브라우저에서 만들어낸 데이터들은 client state(클라이언트 상태)로, 서버에서 불러온 데이터는 server state(서버 상태)로 구분합니다.

• Client state: 사용자가 생성, 편집한 데이터

• Server state: 서버에 요청해 가져온 데이터

그렇다면 Global state에 서버 데이터를 분리해 저장하며, 데이터를 캐싱한다면 문제가 해결될까요?

export const useCacheStore = defineStore('cache', () => {
  // state: 필요한 데이터
    const data = ref()

    // getter: 캐시된 데이터를 가져오는 함수
    async function getCachedData() {
        // 데이터가 저장되어있지 않는 경우에만 서버에 데이터를 요청합니다.
        if (!data.value) {
            await fetchData()
        }
        return data.value
    }

    // action: API data fetch 함수
  async function fetchData() {
    data.value = await axios.get(...); // 일단 error는 고려하지 않겠습니다.
  }

  return { data, getData }
})

이렇게 되면 캐싱되어있는 데이터를 잘 불러올 수 있을 것입니다.

하지만 state에 캐싱된 data와 현재 서버의 data가 항상 일치한다는 보장이 없으므로 위 코드는 문제가 됩니다.

캐싱을 한다 하더라도, 캐시가 최신의 서버 데이터와 일치하는지 구분하기 어렵습니다. 캐시는 언제든 유효하지 않은(invalidate), 이전 버전의 데이터일 수 있습니다.

그렇다면 특정 상황에 데이터를 다시 불러오는(refetch) 상황을 구분해줘야 합니다. 하지만 다양한 API와, 복잡한 컴포넌트를 가지고 있다면 아래와 같은 상황들을 구분하며 refetch하는 로직을 개발하기엔 각각의 함수 하나 하나를 개발하는데 매우 많은 노력이 들어갑니다.

다음과 같은 상황들을 구분하며 데이터 refetch 주기를 정하기 쉽지 않습니다.

• 컴포넌트가 다시 마운트되면 데이터를 다시 불러와야 할까요?

• input이나 button 태그에 focus될 때 데이터를 다시 불러와야 할까요?

• 네트워크가 장애로 인해 끊겼다가 다시 연결되었을 때 데이터를 다시 불러와야 할까요?

• 혹은 5분마다? 10분마다? 데이터가 만료되어 다시 불러와야 하는 주기를 어느정도로 해야 할까요?

아무튼, 실력 좋은 개발자들이 API 요청에 대해 위에서 제시된 내용을 모두 만족하는 코드를 짠다고 가정해보겠습니다. 개발자들은 저마다의 방식으로 복잡한 구현방식을 만족하는 store를 생성할 것입니다.

Loading 또는 API 요청 성공, 실패를 구분하는 status 값이 필요하다면?

isLoading()? 또는 isError()? boolean값으로 status를 반환하는 코드를 만드는 개발자도 있을 것이고, status: ‘loading’ | ‘success’ | ‘error’ 상태값에 대한 string을 반환하는 코드를 만드는 개발자도 있을 것입니다. 모든 코드를 다 만드는 개발자도 물론 있을 것입니다.

interface apiStatus {
    isLoading: boolean;
}
// or
interface apiStatus {
    status: ‘loading’ | ‘success’ | ‘error’;
}

또 error에 대한 상태값 처리를 할 때도 try-catch문을 이용하는 개발자도 있을 것이고, then-catch문을 이용하는 경우가 있을 것이고, finally문을 사용할지, 예외처리 바깥에 특정 코드를 실행할지…

구현 방법이 매우 복잡하고, 수많은 API를 위한 Pinia store들을 통일된 문법으로 관리하는 것은 너무 어렵습니다.

Server state의 관리를 간편하게 하기 위해 개발된 라이브러리가 바로 Tanstack에서 개발한 Vue Query입니다.

계속...

Kibitz bugs

https://kibitz-bugs.xyz

Kibitz bugs는 스트리밍 플랫폼 트위치의 댓글 API를 활용하여 스트리머와 시청자 집단지성 간 오목 대결을 펼치는 게임입니다. 방송을 진행하는 스트리머는 일반적인 오목 게임을 하듯 수를 두고, 시청자 모두가 댓글로 좌표를 입력해 집단지성으로 좌표를 '선택'합니다.

침착맨, 우왁굳, 우주하마, 풍월량, 우정잉 등 유명 트위치 스트리머를 포함한 약 4,300명 이상의 트위치 스트리머가 약 6,300회 이상의 오목 게임을 플레이했고,

한 방송에서는 19,000명이 동시에 접속해도 안정적으로 게임을 플레이했습니다.

방송 영상은 각 스트리머의 유튜브 채널에도 업로드되어 총합 300만 명에 가까운 조회수 또한 기록했습니다.

🔗YouTube 재생목록 링크(195개의 영상)

기획부터 개발까지

'쓸만한' 프로젝트 만들기

프로젝트는 백엔드 친구 한 명과 저, 이렇게 두 명이 진행했습니다. 프로젝트를 기획하며 가장 중요하게 생각한 목표는 '누군가 사용할 프로젝트를 만들자' 였습니다. 아무리 사이드 프로젝트의 목적이 다양하다고 해도, 사용자가 없다는 전제로 시작한다면 개발하는 과정이 매우 길고 지루할 것입니다. 반대로 기껏 만들었는데 아무도 사용하지 않는다면 그동안 들인 시간과 정성이 너무 아깝겠지요.

사이드 프로젝트를 이미 경험해 보신 분들께서는 잘 아시겠지만, 내가 만든 프로젝트를 누군가 한 명이라도 사용한다는 것은 매우 설레고 특별한 경험입니다. 아무 금전적 이익이 없더라도 누군가 내가 기획하고 개발한 서비스를 사용한다는 것 자체가 행복한 일이지요.

그런 의미에서 스트리머의 컨텐츠 전용 게임개발은 처음부터 전략적이었습니다.

수요와 공급의 기본적인 원리를 이용해 펜을 판매하는, 영화 <울프 오브 월스트리트>에서의 인상깊은 장면이 있는데요, 당연하게 프로젝트도 마찬가지로 필요에 의한 개발로 탄생한 제품은 누군가 사용할 수 밖에 없다고 생각했습니다. 물론 기존에 없는 서비스이거나, 기존에 있었어도 기존 제품보다 훨씬 좋아야 하는 것은 당연합니다. (비상한 아이디어가 아니더라도 더 나은 사용자 경험이나, 디자인으로도 가능하다고 생각하긴 합니다)

그런 의미에서 Kibitz bugs는 스트리머, 시청자 모두에게 필요한 서비스였습니다. 스트리머는 콘텐츠가 필요합니다. 하루하루 어떤 콘텐츠로 방송할지 고민을 하는 분들이기 때문입니다. 재밌어보이는 콘텐츠가 있다면 당연히 사용하는 스트리머가 있을 것이라고 생각했습니다.

시청자는 스트리머와 소통을 원합니다. 기존 오목 게임으로 시청자와 스트리머가 오목 게임을 하는 것을 유튜브에서 몇 번 본적이 있는데요, 길어야 두세 시간 하는 방송 중 많아 봤자 기껏 해야 몇 명이 참여할 수 있을까요?

여기서 Kibitz bugs의 아이디어를 얻었는데요, 채팅에 참여한 시청자 모두가 한 번에 게임에 참여한다면 어떤 일이 일어날까? 라는 생각이었습니다. 간단한 좌표를 입력해서 지루하지 않게 한 판을 끝내기에도 매우 적절했고요. 시청자 참여 콘텐츠라는 특성상 시청자에 의해 자연스럽게 홍보되고, 자연스럽게 많은 사용자를 모을 수 있었습니다.

• 스트리머, 시청자 모두의 니즈에 맞았다.
• 모두가 룰을 알고 있고, 잠깐 재밌게 할 게임으로 오목이 매우 적절했다.
• 투표로 좌표를 정하는 방식도 오목판이라는 공간이 너무 딱 맞았다.

또한 스트리밍된 영상은 트위치에서만 그치지 않습니다. 그 분야 전문가들에 의해 유튜브에도 재밌게 편집되어 올라가 프로젝트가 널리 널리 퍼질 수 있었습니다. 덕분의 프로젝트의 인지도 측면에서도 유리했습니다.

서버 비용 0원으로 게임 만들기

사이드프로젝트에서 어쩌면 개발보다 더 중요한 부분은 현실적으로 발생하는 비용에 관한 문제입니다. 사용자가 많을수록, 또는 AI처럼 서버가 하는 일이 많아질수록 비용이 만만치 않기 때문입니다.

트위치의 유명 스트리머 몇 명만 동시에 방송해도 수만 명의 동시 시청자가 들어오고, 최악의 상황을 가정하면 1초에 수만 명의 투표를 집계해야 하는 문제가 있었습니다. 과연 백수 두 명의 얇은 지갑으로, 어떻게 트래픽을 감당할 수 있었을까요?

물론 이 문제는 아이디어가 처음 떠올랐을 때 부터 예상한 문제였는데요, Kibitz bugs의 모든 게임 로직은 전부 클라이언트 브라우저에서 처리됩니다.

게임에 접속한 스트리머의 브라우저에서 트위치의 채팅 API로 받아온 채팅 메시지들을 정제하고, 좌표를 종합합니다. 종합된 좌표별 득표수는 부드러운 애니메이션을 위해 0.5초에 한번 쓰로틀링되어 브라우저 화면에 표시됩니다.

제일 많이 득표된 좌표에 마치 마우스를 올린 것 처럼 표시해 실제로 모니터 너머에 하나 지성을 가진 사람이 있는 것 같은 모습을 보여줍니다. 게임을 플레이하는 스트리머로부터 '시청자들이 마치 알파고가 계산하듯이 오목을 둔다' 라는 말을 정말 많이 들었는데요, 정확히 의도된 인상이었습니다.

게임의 주요 로직을 담당하는 코드들(특히 오목의 승패, 금수 판정 알고리즘) 또한 스트리머의 브라우저에서 전부 돌아갈 수 있도록 자바스크립트로 작성되었습니다. 서버의 비용을 줄이는 것과 동시에 스트리머 특성상 매우 좋은 PC로 게임을 플레이할 것을 가정할 때 성능면에서 부족함이 없을 것이라고 생각했기 때문입니다. 시청자 수가 많을수록 더더욱 좋은 사양의 컴퓨터로 게임을 할테니 계산상 게임 플레이에 성능상 문제가 발생할 일은 없었습니다.

서버 부담을 줄이는 데에는 이미지와 빌드 용량 최적화도 한몫 했습니다. 0.1.0-alpha버전에서 유저가 처음 접속하면 약 11.4MB의 리소스를 다운로드했는데요, 최적화 이후 1/10수준인 1.3MB로 줄였습니다.

반년동안 수십만 명의 시청자 투표를 감당한 서버는 AWS의 Free Tier, 서버 비용은 0원입니다. 게임을 운영하며 서버 비용이 전혀 들지 않았어요. 때문에 지저분한 광고를 게임 좌우에 붙이는 일도 없었고, 사용자들은 더 쾌적한 환경에서 게임을 즐길 수 있었습니다.

배포!

애초에 짧은 기간 집중해서 개발하려고 했던 프로젝트이기 때문에 기본적인 Twitch OAuth 인증과 댓글 수집, 오목 알고리즘과 주요 게임 엔진 개발이 완료되자마자 일단 빠르게 배포를 했습니다.

배포를 한 이후 트위치 시청자의 활동이 매우 활발한 침착맨 커뮤니티(침하하)에 글을 작성해 홍보했고, 좋은 반응으로 단숨에 베스트 게시물에 오르면서 세상에 알려지게 되었습니다. 특히 스트리머 방송에 참여하는 형식의 게임이다보니 시청자분들의 적극적인 홍보와 추천이 큰 힘이 되었습니다.

전혀 예상하지 못했던 것은, 배포가 된 바로 다음날 새벽, 우왁굳님이 방송에서 게임을 했다는 점입니다. 아깝게도 잠을 자느라 생방송을 시청하지 못했는데요, 아침에 일어나 보니 우왁굳 팬카페가 오목 관련 글로 뜨거웠습니다. 그 다음날 한번 더 연속으로 게임을 플레이한 덕분에 아직 정식 버전이 개발되기도 전에 게임의 접속자 수가 폭증했습니다.

예상치 못한 새벽 방송에서 약 17,000명의 동시 시청자가 플레이하며 게임의 안정성을 검증했습니다. 게임 방송을 전문으로 하는 스트리머의 피드백도 매우 긍정적이었는데요, 딜레이가 매우 적고 댓글 반영이 매우 빠릿빠릿하다, 게임을 잘 만들었다는 긍정적인 코멘트를 받았습니다.

👉우왁굳 1차 방송 유튜브 👉우왁굳 2차 방송 유튜브

구독자 약 180만 게임 전문 유튜버이자 트위치 스트리머인 우주하마님의 팬카페에도 한 번 홍보 게시글을 작성했습니다. 정말 재밌는 방송이었는데요,

특히 선(흑돌)은 육목을 하지 못하는 점을 기회로 살려 승리하는 재미있는 상황도 연출되었는데요, 렌주룰이 완벽히 적용된 오목 룰 판정 알고리즘, 그리고 우주하마님의 높은 오목에 대한 이해도가 돋보이는 장면이었습니다.

해당 영상은 유튜브 업로드 이후 뜨거운 반응으로 인기 급상승 동영상에도 올랐고, 오늘 기준 약 110만 조회수를 달성했습니다.

👉우주하마 방송 유튜브

모니터링과 피드백

스트리머가 Twitch 계정으로 로그인할 때 Telegram bot을 이용해 방송 알림을 받을 수 있도록 모니터링 시스템을 구축했습니다. Telegram bot을 통해 방송 알림이 오면, 웬만하면 거의 모든 방송을 다 챙겨봤습니다. 실시간 스트리밍으로 방송되는 게임이다 보니 스트리머와 시청자의 생생한 피드백도 얻을 수 있었습니다. 게임 기능에 대한 피드백부터 테마 변경, 다른 게임의 추가 개발 등 부가적인 피드백도 받았습니다.

또한 사용자 수 수집을 위해 Google Analytics도 사용했습니다. 아쉬운 점은 첫 배포 당시에 GA 없이 배포해서 가장 사용자가 많았던 배포 이후 약 3주 동안의 데이터가 없다는 점입니다.

프로젝트 배포 전 GA는 필수입니다.

스트리머 한 명만 접속해 플레이하는 게임 특성상 실제 사용자보다 GA에 기록되는 사용자는 매우 적지만, 사용자 추세 정도는 파악할 수 있었습니다. 특히 주목한 점은 재사용자인데요, 게임 스트리머의 방송 특성상 메인 콘텐츠로 게임을 하면 보통 다시 접속하지 않을 것으로 생각했지만 오히려 자주 방문해 주시는 스트리머분들이 꽤 많았습니다. GA에서도 확인할 수 있듯이 재방문율이 예상보다 높았습니다.

후회하며 배우기

배포 전 기본은 지켰어야 했다.

핵심적인 게임 기능만 테스트하고 배포를 했기 때문에 첫 배포에서 빠져버린 중요한 기능들이 많았습니다. 게임 플레이에 문제가 될 정도의 문제도 있었는데요, 제한시간 초읽기나 경고가 적극적이지 않아서 시간초과로 싱겁게 게임이 끝나버린다거나, OAuth 인증 과정을 프론트에서 전부 처리해 브라우저 창을 새로고침하면 토큰이 날아가 로그아웃이 되는 등의 문제가 있었습니다. 기본적인 기능이 제대로 개발이 되지 않은 상태에서 너무 많은 사용자가 방문해 곤란해져버린 흔치 않은 경험이었습니다.

물론 이후 업데이트를 통해서 백엔드에서의 Authorization Code Grant로 OAuth 표준 인증 절차를 진행하고, JWT로 발급된 Refresh Token과 Access Token을 이용해 보안 측면에서 안전한 로그인 유지 기능을 구현했습니다.

GA를 적용하지 않아 처음부터 제대로 된 이용자 수 모니터링을 하지 못했고, 트위치 게임 카테고리에 게임 등록도 되지 않아 많은 시청자가 시청할 때 트위치 메인 화면에 게임이 노출될 기회도 여러번 놓쳤습니다.

최대한 많은 데이터를 모았어야 했다.

첫 배포 버전부터 게임 플레이 데이터를 일부 백엔드에 전송하긴 했습니다. 하지만 언제 어떻게 게임 플레이 데이터가 쓰일지 모른다는 점에서 최대한 많은 정보를 DB에 저장을 해뒀어야 했다는 아쉬움이 있습니다.(개인정보와 관련된 민감한 정보를 제외하고)

특히 현재 시청자 수가 몇 명인지, 한 게임에서 실제 채팅으로 참여하는 시청자의 수 또는 비율은 얼마나 되는지, 투표의 의견이 어떤 상황에서 얼마나 많이 갈리는지 등... 재밌게 활용될 수 있는 통계 데이터를 하나도 저장하지 않은 것을 후회하고 있습니다.

처음부터 데이터 수집에 잘 신경 썼다면 <참여형 오목 게임을 통해 알아본 집단 지성 심리 연구> 같은 논문이라도 한 편 쓸 수 있지 않았을까요? 데이터 수집과 분석의 중요성을 느꼈습니다.

나중에도 볼 수 있는 코드를 작성했어야 했다.

이건 매우 부끄러운 고해성사인데요, 짧은 프로젝트 기간, 친구인 백엔드 개발자 한 명과 저 두 명이 개발을 하다보니 큰 실수를 했습니다. 프론트엔드 개발을 혼자 진행한다는 점에서 유지보수를 고려하지 않은 코드들을 작성했기 때문입니다.

물론 덕분에 빠른 개발이 가능했다는 장점도 있긴 했습니다. 또 어차피 프론트엔드 개발을 혼자 진행했기 때문에 저만 알아볼 수 있는 코드를 작성하면 문제가 되지 않을 것이라고 생각했고요. 하지만 매우 큰 오산이었습니다. 프로젝트가 끝나고 단 몇 주가 지났는데도 제가 제 코드를 알아보기 힘들었습니다. 덕분에 리팩토링과 추가 기능 개발에서 크게 애를 먹었습니다.

특히 비즈니스 로직의 모듈화(Hook과 Util Function 등)와 구조 설계의 중요성을 느꼈습니다. 로직의 분리 없이 화면과 관련된(View) 코드와 여기저기 엉켜있다 보니 하나의 정교한 톱니바퀴 같은 코드가 되어버렸습니다. 추가 개발을 하려고 한 줄만 코드를 건드려도 모래성처럼 와르르 무너져 버릴 것 같았습니다.

단일 책임 원칙과도 결이 닿는 이야기일텐데요, 개인적으로 모든 상황에서 하나의 함수가 한 가지 동작만을 해야한다고 생각하지는 않습니다. 하지만 나중을 고려한 개발은 반드시 필요하다는 것을 느꼈습니다. 특히 추가 개발이 수시로 발생하거나, 공동 작업이 활발하게 진행되는 프로젝트라면 더욱 말이죠.

앞으로의 계획과 목표

지금도 사이드 프로젝트를 하나 하고 있는데, 이번엔 크기가 좀 커서 장기간 기획과 디자인을 하는 중입니다. 게임과 관련된 건 아닙니다.

물론 게임 관련된 아이디어도 몇 개 있습니다. 기획하다가 포기한 아이디어도 여러 개 되고요. 프로젝트를 여러 개 병행할 수 없다 보니 시간이 없어서 못한다는 핑계를 대는 중입니다.

장기적인 목표라고 한다면, 기획자, 디자이너와 말이 잘 통하는 개발자가 되는 것이 목표입니다.

개인적으로 프론트엔드 개발의 가장 큰 매력은 사용자와 아주 가깝다는 점인데요, 사용자와 가깝기 위해서는 그 어떤 분야의 개발자보다 기획과 디자인을 잘 알아야 한다고 생각합니다. 조금 오바하면 지금 당장 이직을 해도 기획자 또는 디자이너 일을 할 수 있을 정도로요. 물론 직업은 개발자이다보니 이런 분야에 전문적이진 않겠지만, 그만큼 많이 알고 관심을 가져야 한다는 뜻입니다.

그런 의미에서 사이드 프로젝트는 매우 필요합니다!

회사 일은 내 맘대로 못하지만, 내가 기획하고 내가 디자인한 사이드 프로젝트는 내 맘대로 할 수 있거든요! 사소한 것 하나에 디테일한 고민을 하는 경험을 매일매일 할 수 있습니다.

정민우 minu.j.dev@gmail.com @minu-j

교착상태 회피를 구현하는 방법 중 하나인 에츠허르 데이크스트라가 제시한 은행원 알고리즘(banker's algorithm)의 예시.

교착 상태는 프로세스가 서로 자원을 점유하려고 하는 과정에서 아래 네 가지 필요조건이 동시에 충족될 경우 발생합니다.

1. 상호 배제 : 한 프로세스가 사용하는 자원은 다른 프로세스와 공유할 수 없는 배타적인 자원입니다.
2. 비선점 : 한 프로세스가 사용하는 자원은 다른 프로세스가 빼앗을 수 없습니다.
3. 점유와 대기 : 프로세스는 어떤 자원을 할당받은 상태에서 다른 자원을 기다리는 상태입니다.
4. 원형 대기 : 점유와 대기를 하는 프로세스 간 사이클이 발생합니다.

교착상태가 발생할 경우 해결 방법은 세 가지입니다.

1. 예방
2. 회피
3. 검출과 회복

이 중 은행원 알고리즘은 교착상태 회피를 위한 알고리즘 중 하나로, 다익스트라 알고리즘으로 유명한 에츠허르 데이크스트라가 제시했습니다.

시스템 교착을 일으키지 않고 각 프로세스가 요구한 양 만큼의 자원을 할당해줄 수 있는 순서를 안전순서열이라고 하며, 안전순서열이 존재하는 상태를 안전상태, 존재하지 않는 상태를 불안전상태라고 합니다.

참고

• 쉽게 배우는 운영체제(조성호 저)
• https://jhnyang.tistory.com/102

상황

iOS 앱 빌드는 문제가 없으나 안드로이드 앱 빌드시 :app:checkDebugDuplicateClasses 오류 발생

에러 메시지

Launching lib/main.dart on Android SDK built for arm64 in debug mode...
Running Gradle task 'assembleDebug'...

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:checkDebugDuplicateClasses'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckDuplicatesRunnable
   > Duplicate class kotlin.collections.jdk8.CollectionsJDK8Kt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.internal.jdk7.JDK7PlatformImplementations found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.10)
     Duplicate class kotlin.internal.jdk7.JDK7PlatformImplementations$ReflectSdkVersion found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.10)
     Duplicate class kotlin.internal.jdk8.JDK8PlatformImplementations found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.internal.jdk8.JDK8PlatformImplementations$ReflectSdkVersion found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.io.path.ExperimentalPathApi found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.10)
     Duplicate class kotlin.io.path.PathRelativizer found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.10)
     Duplicate class kotlin.io.path.PathsKt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.10)
     Duplicate class kotlin.io.path.PathsKt__PathReadWriteKt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.10)
     Duplicate class kotlin.io.path.PathsKt__PathUtilsKt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.10)
     Duplicate class kotlin.jdk7.AutoCloseableKt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.10)
     Duplicate class kotlin.jvm.jdk8.JvmRepeatableKt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.jvm.optionals.OptionalsKt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.random.jdk8.PlatformThreadLocalRandom found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.streams.jdk8.StreamsKt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.streams.jdk8.StreamsKt$asSequence$$inlined$Sequence$1 found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.streams.jdk8.StreamsKt$asSequence$$inlined$Sequence$2 found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.streams.jdk8.StreamsKt$asSequence$$inlined$Sequence$3 found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.streams.jdk8.StreamsKt$asSequence$$inlined$Sequence$4 found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.text.jdk8.RegexExtensionsJDK8Kt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)
     Duplicate class kotlin.time.jdk8.DurationConversionsJDK8Kt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.10 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10)

     Go to the documentation to learn how to <a href="d.android.com/r/tools/classpath-sync-errors">Fix dependency resolution errors</a>.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 5s
Exception: Gradle task assembleDebug failed with exit code 1

해결방법

android/build.gradle의 kotlin version 수정

from

buildscript {
    ext.kotlin_version = '1.7.10'
    ...

to

buildscript {
    ext.kotlin_version = '1.8.10'
    ...

백준 1239번 차트 https://www.acmicpc.net/problem/1239

백준 1239 차트 문제에서 테스트케이스는 전부 통과되나 2%에서 오답이 발생했다.

문제의 코드는

from itertools import permutations
from collections import deque

N = int(input())
data = list(map(int, input().split()))
ans = 0

charts= list(permutations(data, N))

visited = set()
for chart in charts:
    if chart not in visited:
        chart_q = deque(chart)
        line_count = 0
        for i in range(N):
            chart_q_copy = chart_q.copy()
            left_sum = 0
            for j in range(N):
                left_sum += chart_q_copy.popleft()
                if left_sum == 50:
                    line_count += 1
                    break
                elif left_sum > 50:
                    break
            left = chart_q.popleft()
            chart_q.append(left)
        if line_count > ans:
            ans = line_count
    visited.add(chart)

print(ans)

차트의 가능한 순열을 모두 돌면서, 그래프를 회전해보며 한쪽이 정확히 50이라면 절반을 차지하므로 그래프 상 직선이 생긴다고 판단하여 카운트를 하는 방식이다.

반례는 다음과 같다.

5
50 10 10 10 20

정답
1
출력
2

위 코드에서의 문제점은, 이중for문에서 deque로 그래프를 회전시킬 때 한바퀴를 돌기 때문에 같은 직선을 두번씩 볼 수 있다는 문제가 있었다.

아래와 같이 코드를 수정하여 문제를 해결했다.

from itertools import permutations
from collections import deque

N = int(input())
data = list(map(int, input().split()))
ans = 0

charts= list(permutations(data, N))

visited = set()
for chart in charts:
    if chart not in visited:
        chart_q = deque(chart)
        line_count = 0
        for i in range(N):
            chart_q_copy = chart_q.copy()
            left_sum = 0
            for j in range(N - i - 1): # deque가 더하는 범위를 제한
                left_sum += chart_q_copy.popleft()
                if left_sum == 50:
                    line_count += 1
                    break
                elif left_sum > 50:
                    break
            left = chart_q.popleft()
            chart_q.append(left)
        if line_count > ans:
            ans = line_count
    visited.add(chart)

print(ans)

Homebridge Tuya IR 플러그인

홈브릿지에 TuyaIR 플러그인을 설치해서 애플 홈 앱에서 에어컨 리모컨을 조작하던 중, 홈 앱에서는 에어컨이 조작이 안되는데 Tuya의 SmartHome 앱에서는 되는 것을 발견했다.

그리고 홈브릿지 로그에 아래와 같은 오류가 찍힌걸 발견했다.

[11/06/2023, 12:48:53] [TuyaIR] Failed to get remote configuration for: ebce59c69f7bd71a0aabkp
[11/06/2023, 12:48:53] [TuyaIR] Server returned error: 'No permissions. Your subscription to cloud development plan has expired.'
[11/06/2023, 12:48:53] [TuyaIR] Failed because of TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be of type string or an instance of Buffer, TypedArray, or DataView. Received undefined

작년 여름에 에어컨을 설치한 후 한달정도 쓰다가 가을이 되어서 그 후로 한번도 홈팟으로 에어컨을 켠 적이 없어, 언제부터 문제가 발생했는지 모르겠지만 아마 계정문제인가 싶어서 Tuya Projact에 앱과 디바이스를 다시 설정해보고 이것저것 만저봤지만 해결이 되지 않았다.

홈브릿지의 문제인가 싶어서 같은 라즈베리파이에 돌리고있는 홈어시스턴트에도 구성을 해보았으나 제대로 연결이 안됐고, 뭔가 라이센스 문제인가 알아보던 중..

Tuya IoT Platform에 IoT Core라는 클라우드 서비스가 활성화되어야 해당 플러그인에서 API로 Tuya 기기를 컨트롤 할 수 있다는 것을 알았다...

그리고 IoT Core 서비스는 가입시 한달 무료. 그 이후부터는 유료로 서비스 되는 것 같았다.

다행히 View Details를 눌러보니 만료기한을 연장신청하는 버튼이 있었고, 개발자 정보와 간단한 프로젝트 설명, 연장 신청 기간을 적어서 제출할 수 있었다.

정확히 어떤식으로 신청해야 먹힐지는 모르겠으나... 일단은 신청해놨다.

리뷰하고 결과를 알려주는 것 같다.

=============

글 쓴지 다음날 클라우드 서비스 콘솔을 확인해보니 정상적으로 작동하는 것을 볼수 있었다. 생각보다 후한 듯 하다.

하지만 다시 등록해봐도 똑같은 오류 발생...

권한문제가 뭔지 도대체 모르겠어서 포기하려던 찰나... 지역 설정을 바꿔주니 잘 동작합니다.

로그도 정상적으로 뜨고요.

홈에서도 정상 동작합니다.

물론 신호 전송 기록상 켜져있는거지 IR리모컨 특성상 작동이 보장되는건 아니라서 확실히 에어컨이 켜졌는지를 확인하려면 진동센서를 실외기에 부착한다거나, 도어센서를 에어컨 날개에 부착하는 등 방식으로 해결할 수 있습니다.

React + Typescript + styled-components를 이용한 컴포넌트를 찍어내던 중, 반복되는 작업에 들어가는 시간을 아끼고자 스니펫을 만들었다. 지극히 개인적인 형식이어서, 공식문서를 읽어보고 본인에게 맞는 스니펫을 만들어보도록 하자.

간략한 가이드

1. (mac 기준) Code > Preferences > Configure User Snippets

2. 기존 언어 Snippets에 추가하거나, Global 또는 프로젝트 단위 Snippets를 생성해 사용자 지정 Snippets를 입력해준다.

예시

{
  "React+Typescript+Styled-components 생성": {
    "prefix": ["사용자 단축어"],
    "body": [
      "import styled from \"styled-components\";\n",

      // props 타입 선언(camelCase)
      "type ${1:newComponent}Props = {};\n",

      // React 컴포넌트 이름(PascalCase)
      "function ${1/(.*)/${1:/pascalcase}/}({}: ${1}Props) {",
      "\treturn <Styled${1/(.*)/${1:/pascalcase}/}></Styled${1/(.*)/${1:/pascalcase}/}>;",
      "}\n",
      "export default ${1/(.*)/${1:/pascalcase}/}\n",

      // Styled-components 선언(PascalCase)
      "const Styled${1/(.*)/${1:/pascalcase}/} = styled.$2``;"
    ],
    "description": "React+Typescript+Styled-components 생성"
  }
}

결과물

import styled from "styled-components";

type newComponentProps = {};

function newComponent({}: newComponentProps) {
  return <StylednewComponent></StylednewComponent>;
}

export default newComponent

const StylednewComponent = styled.div``;

작동영상

아주 빠르게 나만의 형식을 만들어 낼 수 있다.

리액트의 함수형 컴포넌트를 사용할 때 LifeCycle을 아는 것과 모르는 것의 차이는 매우 크다.

리액트 프레임워크를 사용해서 프로젝트까지 해봤는데도 불구하고 오늘도 엄청난 실수를 하나 했는데, 다신 실수하지 않도록 기록을 남겨놓는다.

addEventListener

import { useState } from "react";

...

const [scrollLocation, setScrollLocation] = useState<number>(0);

const windowScrollListener = (e: Event) => {
  setScrollLocation(document.documentElement.scrollTop);
  console.log(scrollLocation);
};

window.addEventListener("scroll", windowScrollListener)

...

함수형 컴포넌트가 렌더링 되면 scroll의 위치를 state에 지속적으로 최신화하는 함수이다. useState는 state에 선언된 값이 바뀔 때 마다 연관된 컴포넌트들을 새로 렌더링해줘서 값을 바꿔주거나, 역동적인 화면 요소를 그릴 수 있게 해준다. window에 scroll event가 발생할 때 마다 scrollLocation state를 바꿔준다. 위 코드는 타입스크립트로 작성한거라서 타입선언이 되어있다.

그런데...

근데 이런식으로 코드를 작성하면 정말 큰일난다. 이유는 페이지를 벗어나도 event listener가 사라지지 않기 때문.

미친듯이 중복된 listener가 작동해서 스크롤 한번에 만개씩 console.log가 쌓이는 모습을 볼 수 있다....

useEffect

아, 그렇다면 addEventListener() 메서드가 최초 1회만 실행되게 하면 되겠구나.

useEffect는 React의 LifeCycle을 쉽게 이용할 수 있게 해준다. useEffect의 두번째 인자에 들어오는 리스트 안의 값이 변할 때 useEffect에 선언된 함수가 실행된다. 빈 리스트를 넣게 되면 최초 1회만 실행된다.

import { useEffect, useState } from "react";

...

const [scrollLocation, setScrollLocation] = useState<number>(0);

const windowScrollListener = (e: Event) => {
  setScrollLocation(document.documentElement.scrollTop);
  console.log(scrollLocation);
};

useEffect(() => {
  window.addEventListener("scroll", windowScrollListener);
}, []);

...

안된다. 이유는 window에 listener를 달아버린 나머지 해당 컴포넌트를 벗어나도 listener 제거가 되지 않는다. 무조건 해당 컴포넌트를 벗어날 때 listener를 제거해야 한다. 이럴때 사용하는 것이 useEffect의 return 함수

import { useEffect, useState } from "react";

...

const [scrollLocation, setScrollLocation] = useState<number>(0);

const windowScrollListener = (e: Event) => {
  setScrollLocation(document.documentElement.scrollTop);
  console.log(scrollLocation);
};

useEffect(() => {
  window.addEventListener("scroll", windowScrollListener);
  return () => {
    window.removeEventListener("scroll", windowScrollListener);
  };
}, []);

...

이게 최종 코드이다. return 뒤에 오는 함수의 값은 해당 컴포넌트가 제거될 때 실행되는 함수이다. 컴포넌트가 제거될 때 event listener를 제거해서 자원 낭비가 일어나지 않도록 한다.

편안..

반드시 한 컴포넌트에서 만든 listener는 해당 컴포넌트에서 제거하자.

해당 패키지로 구글 로그인 구현시 지문등록 완료한 후 안드로이드에서는 잘 로그인이 되지만 iOS에서만 아래와 같은 오류가 발생했다.

결국엔 공식문서를 꼼꼼하게 읽어보지 않은 탓이었는데, 공식문서 내용이 어렵기도 하고, Info.plist를 직접 건드리니까 자꾸 오류가 발생해서 조금 간단하게 해결할 수 있는 방법을 정리한다.

일단 Firebase나 Google Auth API 페이지에서 PLIST를 다운받아야 한다.

다운받은 .plist파일의 이름을 GoogleService-Info.plist로 수정한 뒤 ios > Runner폴더에 그대로 넣어준다.

그 후 ios폴더에서 Xcode에서 열기를 선택하고,

Runner > Info 하단 URL Types의 URL Schemes에 GoogleService-Info.plist의 REVERSED_CLIENT_ID를 입력해준다.

<key>REVERSED_CLIENT_ID</key>
<string>com.googleusercontent......</string> // <- 이거

끝.

Docker 컨테이너로 Openvidu 환경 세팅

$ docker run -p 4443:4443 --rm -e OPENVIDU_SECRET=MY_SECRET openvidu/openvidu-dev:2.25.0

잘 돌아간다.

Python Server 실행

1. Openvidu가 제공하는 Tutorial repo를 clone한다.

$ git clone https://github.com/OpenVidu/openvidu-tutorials.git -b v2.25.0

2. 연습을 위해 익숙한 언어로 서버환경을 셋팅하기 위해 파이썬 선택했다.

   $ cd openvidu-tutorials/openvidu-basic-python

3. 가상환경 설정 및 활성화

   $ python3 -m venv venv
   

$ . venv/bin/activate

4. Requirements 설치
```bash
$ pip install -r requirements.txt

5. 서버 실행

   $ python3 app.py

로컬 서버도 잘 실행된다.

** Mac에서 Address already in use 오류 **

 * Serving Flask app 'app' (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: on
Address already in use
Port 5000 is in use by another program. Either identify and stop that program, or start the server with a different port.
On macOS, try disabling the 'AirPlay Receiver' service from System Preferences -> Sharing.

서버가 바로 실행되지 않고 위와 같은 오류가 발생했는데, 오류 내용을 읽어보면 기본적으로 5000 port로 서버를 열려고 시도해보니 이미 다른 프로그램이 사용중이라는 뜻으로 보인다. 알고보니 macOS 몬터레이 이후 5000번 port로 Airplay 연결을 한다고... 프로세스를 종료하는 등 다른 해결방법이 있지만, Airplay를 매일 사용하는 입장에서 괜히 관련 건드리기는 싫어서 서버 포트를 임의로 8000번으로 지정해주었다.

# app.py

...

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=8000)

더 많은 해결방법 - https://algoroot.tistory.com/44

React Server 실행

1. React 서버 실행을 위해 아래 폴더로 이동한다.

$ cd openvidu-tutorials/openvidu-react

2. 패키지 설치 및 서버 실행

$ npm install

$ npm start

** error:03000086:digital envelope routines::initialization error 오류 **

...

opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

React script가 OpenSSL 3 규격이 맞지 않아서 생기는 문제로, package.json 수정으로 간단히 해결할 수 있다.

// package.json
...

  "scripts": {
    "start": "react-scripts --openssl-legacy-provider start",

...

아까 서버 포트를 8000번으로 바꿔줬으므로, 서버 URL도 수정해준다.

// App.js
...

const APPLICATION_SERVER_URL = "http://localhost:8000/";

...

잘 켜진다.

영상도 잘 들어오긴 하지만, 다중접속이 잘 안되는걸 보니 조금 문제가 있는 듯 하다. 이 부분은 차차 해결하는걸로..

출처

https://docs.openvidu.io/en/stable/tutorials/openvidu-react/