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

이번에 코칭 서비스에서는 현지화 문자열(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 방지하기

_2014년 11월에 쓴 글입니다._

<img src="https://d3es8xowxikdnc.cloudfront.net/interstellar_time_b622c57ec8.jpg" width="1200" height="628" caption="영화 인터스텔라 스틸컷 - time.com" alt="영화 인터스텔라 스틸컷 - time.com" />

우주비행사가 되고 싶었던 건 아니다. 할 수만 있다면 우주로 떠나고 싶었던 이유 말이다. 왜 우리 부모님은 별거라는 극단적인 선택을 해야 했는지. 왜 인중에는 여드름이 나는지. 왜 친구들은 나를 경멸하듯이 봐야 했는지. 내 사춘기는 혼란스러운 질문으로 가득했다. 우주는 매력적인 도피처로 다가왔다. 별들은 끊임없이 정해진 궤도를 돌 뿐이다. 더 가까워지는 일 없이. 그러나 서로를 더 상처입히는 일도 없이. 중학생이었던 내가 **인터스텔라**를 봤으면 좋았을텐데. 크리스토퍼 놀란의 이번 신작은 우주라는 지극히 외로운 공간을 배경으로 가족, 우정, 사랑과 신뢰에 초점을 맞춘다. 주인공은 가족을 위해 우주로 떠나고, 또 우주에서도 사랑하는 사람과 멀어지지 않기 위해 고군분투한다. 혹성에서 마주한 미증유의 자연환경에도 굴하지 않았던 이유 또한, 사랑하는 얼굴을 다시 볼 수 있다는 믿음 하나 때문이다. 영화에는 하드코어 SF와 휴먼 드라마의 요소가 함께 섞여있다. 덕분에 저마다 엇갈린 평론을 내놓고 있는 문제적인 작품이기도 하다. 한때 온정이 필요했고, 우주덕후이기도 했던 내게는 좀 뜻깊은 영화였다.

세상은 정해진 궤도를 돈다. 나와 행복이 다시 마주할 때까지의 공전주기는 영원에 수렴할지도 모른다. 하지만 뭐 어떤가. 멀리서 보면 눈이 부실 정도로 아름답다. 마음 속에 희망을 품은 누군가에겐 꽤 모험할만한 공간이기도 하고 말이다. 내가 설령 우주비행사가 아니고, 그곳이 우주가 아니라 해도.

영화 인터스텔라(2014)를 보았다

_2014년 10월에 쓴 글입니다._

<img src="https://d3es8xowxikdnc.cloudfront.net/mubi_taking_off_ecb80b7a06.jpeg" width="1280" height="720" caption="영화 탈의 스틸컷 - MUBI" alt="영화 탈의 스틸컷 - MUBI" />

생각이 많이 서툴렀다. 금강제화 구두를 신고 도루코 전기 면도기를 쓸 나이가 되면 절로 어른이 되는 줄 알았다. 어디 어른 되기가 쉬운줄 아나. 스마트폰 없이 잠자리에 일찍 들어야되는 건 기본이다. 집세는 제손으로 내야 되고 과제가 힘든 것을 징징댈 수도 없다. 영화 **탈의**에서 어른이 된다는 것은 거의 불가능한 일이다. 명망있어 보이는 부모에게조차 녹록한 일이 아니기 때문이다. 한 부모가 오디션을 위해 가출한 딸을 찾아나서는데, 옆집 안주인의 수다와 술자리에 푹 빠져 무려 딸을 잊어버리고 만다. 어른이라는 권위는 왜소한 몸에 걸쳐놓은 엑스라지 셔츠처럼 흘러내려 버린다. 과연 체코에서 프라하의 봄을 겪은 감독 답다고나 할까.

어린왕자 이승환이 아니라도 어느 어른에게나 아이 같은 면은 있기 마련이다. 이는 "내가 왕년에~"로 시작하는 허세를 무시해도 된다는 뜻이기도 하지만, 징징대지 못하고 속으로 삭힌 어른들을 어르고 달래줄 필요가 있다는 뜻이기도 하다. 나이가 적건 많건 삶의 빡빡한 부분은 매한가지다. 이젠 좀 봐줄때가 됐다. 결국 어른은 아이의 미래니까 말이다. 내가 애어른으로 남아있어도 된다는 뜻은 물론 아닌 것 같지만.

영화 탈의(밀로스 포먼, 1971)를 보았다

_2015년 2월에 쓴 글입니다_

<img src="https://d3es8xowxikdnc.cloudfront.net/offscreen_tokyo_sonata_da25815b81.jpeg" width="1000" height="544" caption="영화 도쿄 소나타 스틸컷 - offscreen" alt="영화 도쿄 소나타 스틸컷 - offscreen" />

노래를 틀어놨다. 한 곡만 반복으로 해뒀다. 에릭 사티의 "짐노페디"였다. 시선은 곰팡이가 핀 벽지에 못박았다. 해가 질때까지 그렇게 앉아만 있었다. 할 수 있는 게 아무것도 없어서 그랬다. 나같이 엉성하고 무뚝뚝한 사람도 견디기 힘들었다. 어머니와 아버지가 모두 집에 없던 그 날을 꽤 오랜 시간이 지난 지금도 기억한다. 어린 아이에게 가정의 붕괴란 무자비한 감정의 쓰나미다.
 
**도쿄 소나타**에서도 마찬가지다. 아버지는 정리해고를 당하고, 큰형은 일자리를 갖지 못해 방황한다. 영문을 모르는 아이에게 가족들의 행동은 낯설기만하다. 아버지는 갑자기 주먹을 휘두르고, 어머니는 집에 들어오지 않는다. 경제공황이라는 포탄이 날아들고 파편만 남은 가정의 모습을 안단테의 빠르기로 그려냈다. 참 수많은 사람들이 겪었거나 겪고 있는 일이다. 볼 때마다 가슴이 저밋하지만 말이다. 위로라도 하듯 영화의 끝에 드뷔시의 소곡 하나가 나온다. 짐노페디와 비슷한 빠르기와 높낮이로. 슬픔은 새살돋는 마데카솔 대신 그렇게 천천하고 긴 시간만이 답이다. 그저 상처가 아물기를 바라면서.

영화 도쿄소나타(2008)를 보았다

_2015년 10월에 쓴 글입니다_

<img src="https://d3es8xowxikdnc.cloudfront.net/imdb_martian_resized_f5f8e7325e.jpg" width="1000" height="563" caption="영화 마션 스틸컷: IMDB" alt="영화 마션 스틸컷: IMDB" />

나 혼자 밥을 먹고. 이렇게 나 울고 불고. 벌판에 소리쳐봐도 돌아오는 소리 하나 없고. **마션**의 주인공은 처음과 끝의 몇 분을 제외하고 계속 외롭다. 드넓은 화성에 홀로 버려졌기 때문이다. 비상식으로 꾸역꾸역 버텨내면서도 인간성을 잃지 않으려 꿋꿋이 견뎌본다. 대원들이 버리고 간 낡은 레코드를 들어보고, 비디오 카메라앞에 앉아 혼자말도 해본다. 영화의 원작이 된 소설은 "자연 대 인간"이라는 구도에서 서스펜스를 느끼도록 집필되었다. 1인칭 독백에서 드러나는 고독감이 아주 걸작이다.

반면 주인공의 심리묘사를 전적으로 영상에만 의지해야되는 영화는 방점을 자연의 모습에 두었다. 영화전문지 *버라이어티*와의 인터뷰에서 제작팀은 실제 화성탐사선의 사진을 가지고 같은 각도에서는 사진과 구별이 불가능할 정도의 정확도를 가진 3d모델을 만들어 촬영했다고 언급했다. 아이맥스로 보면 화면은 더욱 광막하다. 주인공이 로버를 몰고 화성을 홀로 드라이브하는 모습이 조감도로 묘사될 때, 평원은 먹먹해질만큼 아득하다. 언젠가 구글지도에서 봤던 베두인족이 사막을 건너는 모습과 똑같다.

그러고보면 지구 위의 고독이란 건 참 신기하다. 사람에 둘러쌓여있고 얼마든 사람의 품으로 돌아갈 수 있음에도 존재한다. 무인도나 숲을 고집하는 아웃도어족도 있고, 그저 혼자가 좋아서 외딴 섬의 등대지기를 자처하는 사람도 있다. 베두인족처럼 외로움을 하나의 라이프 스타일로 여기는 부족단위의 삶도 있고 말이다. 서바이벌리스트도 유목민족도 아닌 나는 이해할 수 없는 일이다. 행성급의 외로움을 견뎌내고 그걸 또 즐기기까지하는 이 사람들이야말로 어쩌면 화성인이란 표현이 더 어울리는게 아닌가 싶다. 맷 데이먼은 그 먼 화성에서도 지구의 흔적들을 그리워했는데 말이다. 그리고 무엇보다 와이파이가 없는 삶이라니. 세상에.

영화 마션(2015)을 보았다

_2016년 2월에 쓴 글입니다_

<img src="https://d3es8xowxikdnc.cloudfront.net/beautyinside_namu_58169c6095.jpeg" width="1000" height="1411" caption="영화 뷰티인사이드 포스터 - 나무위키" alt="영화 뷰티인사이드 포스터 - 나무위키" />

하루키는 참 쓸쓸한 작가였다. 책의 아무데나 펼쳐놓아도 외로움이라는 단어가 한 번 쯤은 튀어나올 것 같았다. 등장인물들은 어렵지 않게 여자를 만나면서도 늘 고독하다고 하지않나. 가장 잘 팔린 책의 제목도 **상실의 시대**였다. 90년대만 해도 판매량이 수 백만부였다. 하루키 붐이라는 말도 있었다. 외톨이 작가가 국민작가가 된 21세기부터 그렇게 허허로운 사랑의 시대가 왔다. **뷰티 인사이드**의 속사정도 마찬가지다. 마치 우화처럼 신기하게도 주인공은 얼굴과 생김새가 매일 변한다. 배가 나오고 머리가 빠진 할아버지나 추남이 되어 자기를 알아보지도 못하는 어제의 인연을 먼 발치에서 쳐다보는 일이 다반사다.

홍두깨 같은 줄거리지만 이게 무슨 소린지 다들 알고있다. 영화는 외모가 사랑의 큰 축을 차지하는 세태를 비판한다. 이제 잡티를 없애주는 필터 카메라 앱이 없는 연인관계는 생각할 수 없다. 나만을 사랑해주기를 바라면서도, 아디다스 신발을 신지 않고 폴로 향수를 뿌리지 않은 모습으로 나만의 사람 앞에 설 자신이 없다. 사랑을 해도 차오르지 않고 허전하다. 진정성이 있는 사랑이란 어떤걸까. 이런 질문이나 하고 있는 건 내가 찐따라서 그런가.

RECENT ARTICLES