안녕하세요, 개발본부 코칭크루 프론트엔드 박성렬입니다.

이번에 코칭 서비스에서는 현지화 문자열(localized string)을 시스템을 통하여 자동화된 환경으로 관리하도록 했습니다. 이 과정에서 왜 이러한 선택을 하였고, 구체적으로 어떤 방법을 사용했는지 정리해 보았습니다.

# 문자열 관리 시스템을 구성한 이유
현재 개발팀에서 화면에 표기되는 문자열은 아래와 같은 과정으로 관리합니다.

 > 1 💭기획 과정에서 화면을 구성 
 > 2 🎨디자인 과정에서 화면에 있는 문자열을 그대로 복사 
 > 3 🖥개발 과정에서 임시로 문자열 삽입 
 > 4 🖥문자열을 개발에 용이하도록 추가 관리(key-value 형태로 관리)

이 문자열들은 모두 별도로 관리되므로 최소 3개 이상의 다른 문자열 자료들이 존재하게 됩니다.

1. 기획 문서상 문자열: atlassian confluence 문서
2. 디자인 문서상 문자열: figma, sketch 상에 표현된 문자열. 화면에서 문자열이 너무 길거나 짧을때의 심미성을 확인해야 하기 때문에 필요.
3. 개발 코드상 문자열: json 형태로 보관.

따라서 수정이 발생할 경우는 조금 더 복잡합니다. 보통 문자열 관리는 서비스의 정책과 긴밀하게 연관됩니다. 민감한 가격이나 법률적인 부분을 포함하고 있기 때문입니다. 따라서 2~4 과정을 거치며 이미 기획팀의 원안과 어느정도 차이가 있는 상태로 문자열이 관리되고 있는 상황인데, 이를 다시 기획팀에서 동기화 해야 합니다. 그리고 나서야 수정을 할 수 있고, 다시 1~3의 과정을 거쳐야 합니다.

> 수정 과정: 
> 5 디자인 화면에서의 문자열, 개발 코드상의 문자열이 정리된 형태와 현재 표시된 값을 파악하고, 기획 문서에 현재 문자열을 동기화 
> 6 💭기획 문서에 문자열을 재수정(1) 
> 7 🎨디자인 화면에 문자열을 재수정(2) 
> 8 🖥개발 코드에 문자열을 다시 반영(3) 
> 마지막: 수정된 내용 배포

따라서 문자열 수정에는 생각보다 많은 시간이 들어가게 됩니다. 또한 각 과정에서 언제든 임의로 문자열이 변경될 수 있습니다. QA과정에서 문자열의 변화가 파악되는 경우도 있지만, 그렇지 않은 경우도 있기 때문입니다. 한 두번 정도는 괜찮지만, 여러번 하기에는 굉장히 번거롭고 스트레스 받는 과정입니다.

이러한 문자열간의 차이를 좁히기 위해 **문자열 관리를 시스템화 하게 됩니다.** 보통은 LaaS(Localization as a Service) 관리 도구를 이용하여 관리하게 되는 경우가 많습니다. 이 내용을 이전에 [개인 문서](https://www.notion.so/sungryeolp/Tech-cf996483004843ca879a093743320909)에 정리해 두었으니 궁금하신 분은 참조하셔도 좋을 것 같습니다.

문자열 관리를 시스템화할 경우 항상 모든 과정에서 같은 문자열을 사용하게 됩니다. 기획이 관리하는 하나의 문자열 자료를, 자동화 시스템을 통하여 모든 팀에 자동으로 업데이트합니다. 따라서 수정 과정이 일어나더라도 6~8과정이 필요 없고, 배포 또는 스크립트 실행만 하면 됩니다.

이번에도 개인 프로젝트의 경험을 살려 LaaS 도입을 목표로 하고 있으나, 현지화에 당장 많은 리소스를 투입하기는 팀에게 매우 부담스러울 것 같았습니다.

따라서 **최대한 작은 분량의 작업을 통해** 문자열 관리를 시스템화 하기로 했습니다. 

# Google Spreadsheet + Github Flat Data
[Github Flat Data깃헙 플랫 데이터](https://next.github.com/projects/flat-data/)란 Github Action(이하 깃헙 액션) 서비스의 일부로, 데이터사이언스를 위해 주기적으로 데이터 마이닝 작업을 하여 정규화된 자료(normalized data 혹은 flat data)를 자동으로 가져오는 기능입니다. 쉽게 말하면 POSIX의 스케줄러인 [cron](https://en.wikipedia.org/wiki/Cron) 형태로 돌릴 수 있는 깃헙 액션입니다. 인스턴스를 직접 운용하지 않기 때문에 서비스 개발을 위한 부담이 매우 적습니다. 또한 깃헙 액션을 이용하므로 비용이 무료입니다. 가격도 저렴하고 작업 분량도 적기 때문에 알맞다고 생각하여, 플랫 데이터를 활용하여 현지화 파일을 가져오도록 구성해 보았습니다.

또한 문자열을 관리하는 GUI도구로는 현재 기획팀에서 사용하는 구글 스프레드시트를 그대로 사용하도록 하여, 불필요한 UI 작업을 없앴습니다.

## 구글 스프레드시트 관리하기

우선 구글 스프레드시트에서 문자열을 아래와 같이 정리합니다.

<img src="https://d3es8xowxikdnc.cloudfront.net/Screen_Shot_2022_03_02_at_16_21_55_acb6279a26.png" width="1096" height="220" caption="구글 스프레드시트에 문자열을 관리하는 모습" alt="구글 스프레드시트에 문자열을 관리하는 모습" />


왼쪽에는 `.json` 파일에 들어갈 키값을 nested 형태로 적어주고, 오른쪽에는 i18n문자열을 정리합니다. 왼쪽에 key, 오른쪽에 value 형태로 관리합니다.

작업이 완료되면 `파일>공유>웹에 게시` 를 선택하여 `.tsv`형태로 내보냅니다. `.csv`를 사용해도 되지만, 쉼표는 현지화 과정에서도 자주 사용되기 때문에 탭 여백(tab)을 구분자(delimiter)로 사용합니다. 웹에 게시를 선택하면 나오는 URL을 가지고 `GET` 요청을 하면 `.tsv` 파일을 그대로 받아올 수 있습니다.

## Github Workflow에 Flat Data 추가하기

코드에 아래와 같이 github workflow깃헙 워크플로우를 추가합니다.

```yaml
# $WORKSPACE/.github/workflows/flat.yml
# github flat data를 위한 github workflow 파일
 
name: data
on:
 schedule:
 - cron: "*/30 * * * *" # 30분에 한 번씩 요청합니다.
 workflow_dispatch: {}
 push:
 branches:
 - main
 paths:
 - .github/workflows/flat.yml
 - ./postprocessing.ts # deno 타입스크립트를 통해 후처리합니다.
jobs:
 scheduled:
 runs-on: ubuntu-latest
 steps:
 - name: Setup deno
 uses: denoland/setup-deno@main
 with:
 deno-version: v1.10.x
 - name: Check out repo
 uses: actions/checkout@v2
 - name: Fetch data
 uses: githubocto/flat@v3
 with:
 http_url: https://docs.google.com/spreadsheets/d/e/$REDACTED_URL/pub?output=tsv # 구글 스프레드시트 url입니다
 downloaded_filename: raw_data.tsv # raw_data.tsv로 저장합니다
 postprocess: ./postprocessing.ts # deno 타입스크립트를 통해 후처리합니다.
```

후처리를 할 deno 타입스크립트 파일을 만들어줍니다. 
```typescript
import {
 readCSV,
 writeJSON,
} from "https://deno.land/x/flat@0.0.14/mod.ts";
import lodash from "https://cdn.skypack.dev/lodash";

// 빠른 코드 관리를 위해 자료 타입을 미리 선언해줍니다.
interface ISpreadSheetRow {
 'key_2': string;
 'ko_KR_2': string;
}
// tsv를 사용하므로 탭을 구분자 옵션으로 제공합니다.
const rows = await readCSV(filename, { separator: "\t" });
// 해당 github action이 제대로 돌아갔는지 파악하기 위해 최초1열만 표기합니다.
// 자료의 정합성을 판단하기 위해 tail 또는 head로 자료의 일부만 출력하는 것은 데이터 사이언스의 기본입니다.
console.log(rows[0]);
const koKR = {}
rows.forEach((row) => {
 const r = (row as unknown) as ISpreadSheetRow;
 // lodash를 통해서 nested된 key값을 생성하고 값을 넣어줍니다.
 lodash.set(koKR, r["key_2"], r["ko_KR_2"])
})

// 마지막에 파일을 저장합니다
const newFilename = `i18n-data.json`;
await writeJSON(newFilename, koKR);
console.log("Wrote a post process file");
```

작업이 완료되면 깃헙 워크플로우를 깃헙 리파지토리의 액션 탭에서 수동으로 트리거하여 잘 작동하는지 테스트합니다.

<img src="https://d3es8xowxikdnc.cloudfront.net/Screen_Shot_2022_03_02_at_16_37_41_83840d11ff.png" width="1872" height="254" caption="github workflow를 강제로 트리거한다." alt="github workflow를 강제로 트리거한다." />

이상 없이 작업이 완료된 것을 확인할 수 있습니다.

<img src="https://d3es8xowxikdnc.cloudfront.net/github_workflow_success_40412f8c9f.png" width="1234" height="1038" caption="github workflow가 정상적으로 가동된 것을 확인했다." alt="github workflow가 정상적으로 가동된 것을 확인했다." />

플랫 데이터는 기본적으로 코드 베이스가 바뀌었을 때에만 새롭게 `git commit` 을 하도록 되어 있으므로, 임의로 시트를 수정하고 결과물을 확인해봅니다.

```json
// 생성된 현지화 문자열 json 파일
{
 "time": {
 "relativeTime": {
 "second": "방금",
 "minute": "{0}분 전"
 /* ... */
 }
 }
 /* ... */
}
```

이상 없이 기능이 구현되어서 마무리 되는 줄 알았는데, 예상하지 못한 이슈가 있었습니다. 깃헙 액션 횟수에 월별 rate limit이 존재한다는 것입니다. 팀에서 워낙 많은 기능을 깃헙 액션에 넣어두고 있다보니, 생각보다 빠르게 rate limit에 도달한 것 같았습니다. 따라서 깃헙 액션이 아닌 다른 환경에서 현지화 문자열을 시스템화 하기로 했습니다.

# Jenkins + Docker + Node + Google Spreadsheet
개발팀은 현재 CI-CD 대부분을 젠킨스 환경에서 구현합니다. 따라서 깃헙 액션 대신 젠킨스 환경을 활용하기로 하고 기존 개발 내역을 버리고 새롭게 작업했습니다.

```sh
# 프로젝트 초기화
# axios: tsv파일을 가져오기 위한 get 요청
# d3-dsv: tsv파일을 parse하기 위한 용도
# dayjs: 날짜를 commit명에 human readable 한 상태로 포함하기 위한 용도
# simple-git: 현지화 문자열이 적용될 프로젝트의 git에 접근하기 위한 용도
# ts-node, typescript : 타입스크립트
yarn add axios d3-dsv dayjs lodash simple-git ts-node typescript
```

문제가 생길 경우 빠른 디버깅을 위하여 타입스크립트를 적용했습니다. 다만 이 과정에서 `d3-dsv`가 타입스크립트의 `import` 구문을 지원하지 않아 아래와 같이 브릿지 모듈을 추가습니다.

```javascript
// $WORKSPACE/module-bridge.cjs
// https://stackoverflow.com/questions/70810061/cant-import-d3-geo-package-into-node-js-typescript-project

module.exports = {
 d3_dsv: async function () {
 return import('d3-dsv');
 },
};
```

젠킨스에서 언제든 옵션을 수정할 수 있도록 인자를 환경 변수로 받도록 했습니다.

```typescript
// env.d.ts
declare global {
 namespace NodeJS {
 interface ProcessEnv {
 TSV_URL: string;
 GIT_URL: string;
 GIT_TOKEN: string;
 DEST_FILE: string; // 읽고 변경할 파일명
 GIT_BRANCH: string;
 USER_NAME: string; // git에 사용할 유저명
 USER_EMAIL: string; // git에 사용할 email
 }
 }
}

export {};
```

후처리를 담당할 worker는 아래와 같이 작성했습니다. deno코드를 일반 타입스크립트로 바꾸고, 좀더 상세한 로그를 추가했습니다. 이 코드에서는 주석 대신 로그를 보면 대충 어떻게 작동하는지 알 수 있습니다.

```typescript
import axios from 'axios';
import { DSVParsedArray } from 'd3-dsv';
import { d3_dsv as raw_d3_dsv } from './module-bridge.cjs';
const {
 GIT_TOKEN,
 GIT_URL,
 TSV_URL,
 DEST_FILE,
 GIT_BRANCH,
 USER_NAME,
 USER_EMAIL,
} = process.env;
import _set from 'lodash/set';
import _isEqual from 'lodash/isEqual';
import fs from 'fs';
import simpleGit from 'simple-git';
import dayjs from 'dayjs';

const log = (...arg: any[]) => console.log(...arg);

interface ISpreadSheetRow {
 'key_2': string;
 'ko_KR_2': string;
}

type ISpreadSheetData = DSVParsedArray<ISpreadSheetRow>;
const proc = async () => {
 log('worker up and running...');
 const res = await axios(TSV_URL);
 if (res.status !== 200) {
 log('failed to download google sheet');
 return;
 }
 log('tsv downloaded');
 const d3_dsv = await raw_d3_dsv();
 const rows = d3_dsv.tsvParse(res.data) as ISpreadSheetData;
 log(rows.slice(0, 1));
 log('total rows: ', rows.length);
 const koKR = {};
 rows.forEach((row) => {
 const r = row as unknown as ISpreadSheetRow;
 _set(koKR, r['key_2'], r['ko_KR_2']);
 });
 log('data all processed...');
 log('deleting previous git');
 fs.rmSync('./lvup-fe', { recursive: true, force: true });
 log('cloning git');
 // clone to ./lvup-fe directory
 await simpleGit().clone(`https://${GIT_TOKEN}@${GIT_URL}`, 'lvup-fe');
 log('clone finished');
 const git = simpleGit('lvup-fe');
 await git.checkout(GIT_BRANCH);
 const strDate = dayjs().format('YYYY-MM-DD--HH-mm-ss');
 const newBranch = `${GIT_BRANCH}-i18n-${strDate}`;
 log('branched out to new branch');
 await git.checkoutBranch(newBranch, `origin/${GIT_BRANCH}`);
 let prevFile: any = '{}';
 try {
 prevFile = fs.readFileSync(DEST_FILE, 'utf8');
 } catch (err) {
 log('error while reading previous file', err);
 }
 const prevData = JSON.parse(prevFile);
 const newData = JSON.stringify(koKR, null, 2);
 fs.writeFileSync('./i18n-temp.json', newData);
 const isEqual = _isEqual(prevData, newData);
 if (!isEqual) {
 log('diff found, updating...');
 fs.writeFileSync(DEST_FILE, newData);
 await git.add('.');
 await git
 .addConfig('user.name', USER_NAME)
 .addConfig('user.email', USER_EMAIL);
 await git.commit(`i18n updated to branch: ${newBranch} (${strDate})`);
 await git.push('origin', newBranch);
 } else {
 log('diff not found. file not updated');
 }

 log('finished');
};

proc();
```

## 도커 구성

작업이 완료되면 아래의 코드로 환경 변수가 잘 작동하는지 확인해봅니다.

```sh
# 중요 정보는 모두 숨김처리(REDACTED) 했습니다.

TSV_URL=https://docs.google.com/spreadsheets/d/e/$REDACTED_URL/pub?output=tsv \
	DEST_FILE=./lvup-fe/$REDACTED_FOLDERS/i18n/data/coaching.json \
	GIT_URL=github.com/$REDACTED_REPO/lvup-fe \
	GIT_TOKEN=$REDACTED \
	GIT_BRANCH=$REDACTED \
	USER_NAME=$REDACTED \
	USER_EMAIL=$REDACTED \
	yarn start
```

이상 없이 작동하는 것을 확인하였으면 도커 파일을 작성합니다.

```yaml
FROM node:lts-alpine3.14
RUN mkdir -p /home/node/app
COPY ./package.json ./package.json
COPY ./yarn.lock ./yarn.lock
RUN yarn install
RUN apk add git
COPY ./index.ts ./index.ts
COPY ./env.d.ts ./env.d.ts
COPY ./module-bridge.cjs ./module-bridge.cjs
COPY ./tsconfig.json ./tsconfig.json
CMD yarn start
```

도커 컴포즈 파일을 작성하여 환경 변수를 일괄적으로 제공하도록 합니다.
```yaml
version: '3.0'
services:
 worker:
 build:
 context: .
 dockerfile: ./dockerfile
 environment:
 - TSV_URL=$REDACTED_URL
 - DEST_FILE=./lvup-fe/$REDACTED/i18n/data/coaching.json
 - GIT_URL=$REDACTED
 - GIT_TOKEN=$REDACTED
 - GIT_BRANCH=$REDACTED
 - USER_NAME=$REDACTED
 - USER_EMAIL=$REDACTED
 volumes:
 - ./lvup-fe:/home/node/app/lvup-fe
```

아래의 커맨드를 입력해서 잘 작동하는지 확인합니다.

```
docker-compose up
```

이상 없이 작동하는 것을 확인했고, Jenkins Pipeline Script젠킨스 파이프라인 스크립트를 작성해서 파일이 구동되도록 합니다. 도커는 작성해 두었으므로, 도커를 사용해도 됩니다.

## 젠킨스 설정

우선 환경 변수에 1:1로 대응하는 젠킨스 string parameter를 만들고, 코드를 모르는 사람도 직관적으로 접근할 수 있도록 설명을 추가했습니다.

<img src="https://d3es8xowxikdnc.cloudfront.net/string_parameter_a9585b6717.png" width="1640" height="624" caption="젠킨스에 string parameter를 추가하고 설명을 달았다." alt="젠킨스에 string parameter를 추가하고 설명을 달았다." />

파이프라인 스크립트는 아래와 같이 구성했습니다.
```groovy
node {
 try {
 // 여기에 작업 시작 알림 등 처리
 stage('git checkout') {
 git(
 url: 'https://github.com/$REDACTED/lvup-fe-i18n', // 워커 깃헙 리파지토리
 credentialsId: $JENKINS_CREDENTIAL, // 워커 리파지토리를 git clone할 계정(젠킨스로 관리)
 branch: "${branch}" // 워커 브랜치
 )
 script {
 // 워커 내의 환경 변수와 1:1로 대응한다
 env.TSV_URL = "${TSV_URL}"
 env.DEST_FILE = "${DEST_FILE}"
 env.GIT_URL = "${GIT_URL}"
 env.GIT_TOKEN = "${GIT_TOKEN}"
 env.GIT_BRANCH = "${GIT_BRANCH}"
 env.USER_NAME = "${USER_NAME}"
 env.USER_EMAIL = "${USER_EMAIL}"
 }
 }

 stage('yarn install') {
 script {
 sh '''yarn install'''
 }
 }
 
 stage('Run script on lvup-fe') {
 script {
 sh '''yarn start'''
 }
 }

 } catch (e) {
 // 에러처리
 throw e
 } finally {
 // 슬랙 알림 등 처리
 }
}
```

젠킨스에서 해당 파이프라인을 강제로 트리거하여 깃 브랜치가 생성된 것을 확인했습니다.

<img src="https://d3es8xowxikdnc.cloudfront.net/i18n_commit_branch_sample_c0058ba0f9.png" width="1186" height="132" caption="워커를 통해 젠킨스에서 생성한 브랜치" alt="워커를 통해 젠킨스에서 생성한 브랜치" />

# 남은 작업
진행하면서 일부 작업을 건너 뛰었습니다.

- **젠킨스에서 바로 도커 실행**
팀에서 이미 도커 운용을 하며 용량(메모리, 물리적 저장공간)을 많이 사용하고 있으므로, 최대한 적은 용량으로 운용하기 위해 노드만 사용했습니다. 도커를 사용할 경우 로컬과 같은 환경에서 테스트가 가능하므로 안정성은 보장됩니다. 그러나 이미지를 빌드하는 과정에서 별도의 빌드서버를 사용하지 않고 젠킨스 내부에서 빌드하기 때문에 빌드 과정에서 용량이 두 배로 나가게 됩니다.
- **젠킨스 내부에서의 스케줄러 실행**
팀에서 불필요한 `git commit` 발생을 우려하여 스케줄러는 세팅하지 않았습니다.
- **현지화 문자열 수정을 배포 과정까지 연결**
팀에서 현지화 문자열이 잘못 작성될 경우 리얼 서비스가 망가지는 것을 우려하여, 배포는 수동으로 진행하기로 했습니다.
- **피그마에 바로 현지화 동기화**
일부 유료 LaaS 서비스에서는 피그마 플러그인을 제공해 바로 피그마에도 같은 환경을 설정할 수 있습니다. 외부 서비스를 사용하지 않았기 때문에 플러그인 사용은 다루지 않았습니다.

이러한 세팅 과정은 팀에 따라 약간씩 바뀔 수 있을 것 같습니다.

구글시트를 활용하여 현지화 자동화하기

- [사용을 자제하면 좋은 타입스크립트 기능들(원문: 영어)](https://www.executeprogram.com/blog/typescript-features-to-avoid) 에서 핵심적인 내용만 간추려 보았습니다.

# enum 사용을 자제하자

```typescript
// 🚫 사용을 자제해야할 방식
enum MyValues {
 A = 'A',
 B = 'B'
}
type MyValue = MyValues | string;
// ✅ 권장하는 방식
type MyValues = 'A' | 'B' | string;
```

- 위의 코드에서 알 수 있듯이 `enum` 외에 여러 타입이 혼재(union)되어있을 경우 사용하지 않고 일반 타입선언을 하는 편이 훨씬 간단하다.
- `enum`을 사용한다고 해서 더 유지보수 편의성이 딱히 더 개선되지 않는다.
- `enum`은 각종 트랜스파일러(i.g. 바벨) 및 관련 플러그인과 충돌할 확률이 크다:
 일반적인 타입스크립트의 트랜스파일링은 아래와 같은 방식으로 이루어진다. 즉 중간에 타입스크립트 코드를 걷어내고(strip) 자바스크립트 코드만 남겨놓은 상태로 트랜스파일링을 하게된다.
 원래 자바스크립트 코드에 다른 코드를 더하는 것이 타입스크립트의 일반적인 방식이라면, `enum`을 사용하는 방식은 일반적인 자바스크립트의 변수를 사용하는 방법과 완전히 똑같기 때문에 여러 트랜스파일러 또는 플러그인을 거치다 보면 에러가 발생할 확률이 크다.
 
<callout>타입스크립트 코드 > TS:타입 체크 > TS:타입스크립트 코드 벗겨내기(strip) > 써드파티 트랜스파일러 통과</callout>

```typescript
// 일반적인 자바스크립트 변수 사용
const MyValues = { a: 'a' }
const myVal = MyValues.a;
// 타입스크립트의 enum 사용
const myVal = MyValues.a;
```

# namespace사용을 자제하자

- `enum`과 유사한 케이스. `namespace`는 자바스크립트에서 기본적으로 전역 범위 함수가 된다. 따라서 같은 이름의 함수나 namespace가 있으면 충돌할 수 있다. 만약 사용하고 있는 두 개 이상의 라이브러리에서 같은 namespace를 사용할 경우 에러를 피할 수 없다. 직접 우회를 선언하면 되지만 매우 번거롭다.
- 실제 `react-three-fiber` 와 `chakra-ui` 및 `material-ui`가 [충돌한 사례](https://stackoverflow.com/questions/68692230/ts-expression-produces-a-union-type-that-is-too-complex-to-represent-with-materi) 가 있다.
```typescript
// 아래와 같이 다른 라이브러리의 namespace가 일치할 경우 충돌할 수 있다.
// node_modules/lib-a
namespace MyGlobal {
 // ...
}

// node_modules/lib-b
namespace MyGlobal {
 // ...
}
```

# decorator 및 private 사용을 자제하자
- 둘 모두 `enum`과 유사한 케이스로, 해당 기능들이 ECMAscript 혹은 최신버전의 자바스크립트에서 자바스크립트에 구현될 예정이거나 이미 구현되었기 때문에 문제가 되고 있다.
- `@` decorator의 경우 자바스크립트 기능에 추가가 예정된 반면 아직 [건의](https://github.com/tc39/proposal-decorators) 단계를 통과하지 못했다. 나중에 자바스크립트에서 형태가 바뀔 가능성이 있다고 봐야 한다. 언젠가 이에 맞추어 타입스크립트 코드를 수정해야 트랜스파일러의 오동작을 막을 수 있다. 번거로운 작업이 될 확률이 높다.
- `private`의 경우 자바스크립트에 같은 기능을 하는 `#` [접근자가 추가되었다](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields). 따라서 굳이 타입스크립트에서만 지원하는 `private`를 쓰는 것 보다는 `#`를 쓰는 편이 나중에 불필요한 코드 수정을 막을 수 있다.

```typescript
class MyClass {
 // 🚫 사용을 자제해야할 방식
 private myProperty: MyType;
 // ✅ 권장하는 방식
 #myProperty: myType;
}
```

사용을 자제하면 좋은 타입스크립트 기능들

브라우저에서 **레이아웃 변형layout shift** 이 일어났다고 하면 단순히 화면상의 배치가 바뀌었다는 것만을 뜻하지 않습니다. 실제로 변형된 것은 단 하나의 객체만 바뀌었다고 하더라도, 전체적인 화면상의 위치를 재계산해야할 필요가 있을 때 **레이아웃 변형**이 일어났다고 표현합니다. 따라서 레이아웃 변형이 일어났다고 하면, 일반적으로 사용자 입장에서는 전체 화면이 한꺼번에 움직이므로 깜박거리는 화면이나 느려진 인터페이스를 경험하게 됩니다.

코드나 알고리즘상의 퍼포먼스 하락은 빠르게 탐지할 수 있습니다. 그러나 **레이아웃 변형**의 경우 스타일이나 HTML 태그 배치의 문제로 인해서 발생하는 경우가 많기 때문에 해당 내용을 놓치기 쉽습니다. 마침 해커뉴스에 레이아웃 변형의 가장 흔한 유형 중 하나인 폰트로 인한 레이아웃 변형을 막는 법에 대해 블로그 포스팅이 올라왔기에 간단히 요약하여 공유드립니다. 아이콘 폰트 및 시스템 폰트 활용에 대한 이야기는 디자이너분들도 알아두시면 좋을 내용인 것 같습니다.

[폰트로 인한 레이아웃 변형(layout shift)을 방지하는 법 본문 링크(영문)](https://simonhearne.com/2021/layout-shifts-webfonts/)

- 레이아웃 변형을 탐지하는 법: 크롬 개발자 도구 내부에서 `Performance`탭에 들어가서 시간을 두고 스냅샷을 찍으면 워터폴 차트에서 `layout shift`로 표현해준다.
- CSS에서 `font-display:optional` 을 사용하면 폰트 바뀜(font swap) 현상을 막고 폰트가 있을 때만 렌더하기 때문에 레이아웃 변형을 막을 수 있다.
> 역주: 이 경우는 FCP(First Contentful Paint)는 느려질 수 있기 때문에 논의를 거쳐 사용해야할 것 같습니다.
- 폰트 자체의 볼드, 이탤릭체도 하나의 폰트로 간주되어 그만큼 자원을 소모한다. 따라서 브라우저에서 자체 제공하는 즉시 생성된 볼드, 이탤릭체(faux bold, faux italic)를 이용하여 불필요한 폰트 불러오기를 막을 수 있다.
> 역주: 이 경우는 원본과 비교했을 때 자체 생성된 볼드와 이탤릭체의 심미성을 고려하여 적용해야 할 것 같습니다.
- 가변형 폰트(variable font)를 이용하자
- 아이콘 폰트는 불필요한 리소스를 모두 가져와서 사용하는데다가, 용량 자체도 크기 때문에 사용을 자제하고 svg를 사용하자
가능한 부분에서는 최대한 OS에 기본 탑재되어 있는 폰트(system font)를 이용하자. 물론 그대로 사용하지 않고 자간 및 폭을 조정하여 완전히 다른 글자처럼 만들 수 있다.
- 폰트를 외부에서 가져올 경우(i.g. 구글폰트) 불필요한 특수문자를 subset 옵션을 설정하여 제거하고 필요한 문자만 가져올 수 있다.
woff, woff2는 기본적으로 압축(gzip 및 brotli)이 적용되어 있다. 따라서 ttf 및 otf 사용을 자제하고 가능하면 최대한 woff, woff2를 사용하자.
> 역주: 이 경우는 수동으로 압축을 적용하면 되고, 간혹 브라우저 및 기기에 따라 woff, woff2를 지원하지 않는 경우도 있어서 상황에 맞게 사용해야할 것 같습니다.
- 최대한 CDN을 사용하자
- `<link rel="preload" />` 옵션을 이용하여 통신 대역폭이 확보된 상황에서는 빠르게 폰트를 가져올 수 있도록 하자.

그 외에도 현재 [크롬에서 최근 도입된 CSS속성 모음인 f-mods](https://docs.google.com/document/d/1PW-5ML5hOZw7GczOargelPo6_8Zkuk2DXtgfOtJ59Eo/edit)를 이용하여 폰트를 최적화하는 방법도 소개하고 있습니다. 이 경우 [사파리와 IE에서는 아직 사용이 불가능](https://caniuse.com/?search=FontFace%20API%20override)합니다. 그러나 PWA를 비롯해 대부분의 크롬 자체 기술이 다른 브라우저에서도 채용된 것을 보았을 때 기대해봐도 좋을 것 같습니다.

폰트로 인한 layout shift 방지하기

<img src="https://d3es8xowxikdnc.cloudfront.net/nginx_over_apache_rank_2022_fe42f1b311.jpg" width="1546" height="1374" caption="2021년부터 지금까지 shodan에서 집계된 내용" alt="2021년부터 지금까지 shodan에서 집계된 내용" />

[해커뉴스](https://www.nginx.com/blog/do-svidaniya-igor-thank-you-for-nginx/)의 답글란을 읽다가 얻어온 소식입니다. [shodan](https://www.shodan.io/)에 따르면 2021년 1월에 nginx가 apache(이하 아파치)를 제치고 전세계에서 가장 인기있는 웹서버 어플리케이션 1위로 집계되었고 이 대세가 올해도 이어지고 있다고 하네요.

- [shodan 쿼리 페이지:아이디 및 구독 필요](https://trends.shodan.io/search?query=http+port%3A443#facet/product)

말이 좋아서 웹서버지 사실은 내부 네트워크에서 리버스 프록시 용도로 더 많이 쓰고 있는데, 이러한 프록시 용도로 전문화된 웹 서버중에서 nginx가 상당히 빠른 속도로 1위를 탈환한 것에 대해서 여러가지 썰이 오가고 있습니다.

- 아파치가 설정 파일이 복잡하다 -> 옵션이 복잡해서 잘 건드리지 않게 된다 -> 성능 튜닝에 대한 노하우가 적어진다 -> 퍼포먼스가 떨어져서 잘 안쓰게 된다
- [아파치가 쓰레드 기반(thread-based)인데 반해서 nginx가 이벤트 기반(event-based)이기 때문](https://aosabook.org/en/nginx.html)에 고가용성(High Availability)에 더욱 유리하기 때문

RECENT ARTICLES