BlaCk_Log

font-range가 빠르게 서브셋하는 방법

BlaCk_Void — Tue, 31 Dec 2024 21:15:34 +0900

본 글은 2023년 12월 30일에 작성되었으며 옮겨진 글입니다.

백업해두었다가 귀찮던 나머지 계속 미루다 공개합니다.

font-range란?

저는 fontRange라는 라이브러리의 저자이며, 폰트 서브셋을 효율적이고 쉽게 할 수 있는 API를 제공합니다.

폰트 파일에서 필요한 문자 집합만을 선택하여 추출한 폰트 파일을 만드는 작업입니다.
일부 문자들만을 가지고 있으니 파일 사이즈가 작아지고, 웹사이트 성능 최적화에 도움이 됩니다.

웹환경에서 서브셋은 Adobe-KR-0를 따라 2780자(자모 포함 2831자)를 사용하거나,
노민지, 윤민구 - KS 코드 완성형 한글의 추가 글자 제안(2574자, 리스트)도 참고해볼 수 있습니다.

하지만 이는 자주 사용하는 글꼴만을 로딩할 수 있는 방법입니다.
그렇다면 모든 문자을 사용하면서 필요한 부분만을 로드할 수 있을까요?

unicode-range가 바로 그에 대한 대답입니다.
알파벳처럼 문자 셋이 간단할 경우, Noto Sans와 같이 키릴문자(cyrillic), 그리스문자(greek), 라틴문자(latin) 등의 범위를 수동으로 지정하면 충분합니다.

/* cyrillic-ext */
@font-face {
  font-family: 'Noto Sans';
  font-style: normal;
  font-weight: 400;
  font-stretch: 100%;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosans/v35/o-0mIpQlx3QUlC5A4PNB6Ryti20_6n1iPHjcz6L1SoM-jCpoiyD9A-9X6VLKzA.woff2) format('woff2');
  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
}
/* cyrillic */
@font-face {
  font-family: 'Noto Sans';
  font-style: normal;
  font-weight: 400;
  font-stretch: 100%;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosans/v35/o-0mIpQlx3QUlC5A4PNB6Ryti20_6n1iPHjcz6L1SoM-jCpoiyD9A-9e6VLKzA.woff2) format('woff2');
  unicode-range: U+0301, U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
}
/* devanagari */
@font-face {
  font-family: 'Noto Sans';
  font-style: normal;
  font-weight: 400;
  font-stretch: 100%;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosans/v35/o-0mIpQlx3QUlC5A4PNB6Ryti20_6n1iPHjcz6L1SoM-jCpoiyD9A-9b6VLKzA.woff2) format('woff2');
  unicode-range: U+0900-097F, U+1CD0-1CF9, U+200C-200D, U+20A8, U+20B9, U+25CC, U+A830-A839, U+A8E0-A8FF;
}
/* greek-ext */
@font-face {
  font-family: 'Noto Sans';
  font-style: normal;
  font-weight: 400;
  font-stretch: 100%;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosans/v35/o-0mIpQlx3QUlC5A4PNB6Ryti20_6n1iPHjcz6L1SoM-jCpoiyD9A-9W6VLKzA.woff2) format('woff2');
  unicode-range: U+1F00-1FFF;
}
/* greek */
@font-face {
  font-family: 'Noto Sans';
  font-style: normal;
  font-weight: 400;
  font-stretch: 100%;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosans/v35/o-0mIpQlx3QUlC5A4PNB6Ryti20_6n1iPHjcz6L1SoM-jCpoiyD9A-9Z6VLKzA.woff2) format('woff2');
  unicode-range: U+0370-03FF;
}
/* vietnamese */
@font-face {
  font-family: 'Noto Sans';
  font-style: normal;
  font-weight: 400;
  font-stretch: 100%;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosans/v35/o-0mIpQlx3QUlC5A4PNB6Ryti20_6n1iPHjcz6L1SoM-jCpoiyD9A-9V6VLKzA.woff2) format('woff2');
  unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+0300-0301, U+0303-0304, U+0308-0309, U+0323, U+0329, U+1EA0-1EF9, U+20AB;
}
/* latin-ext */
@font-face {
  font-family: 'Noto Sans';
  font-style: normal;
  font-weight: 400;
  font-stretch: 100%;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosans/v35/o-0mIpQlx3QUlC5A4PNB6Ryti20_6n1iPHjcz6L1SoM-jCpoiyD9A-9U6VLKzA.woff2) format('woff2');
  unicode-range: U+0100-02AF, U+0304, U+0308, U+0329, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* latin */
@font-face {
  font-family: 'Noto Sans';
  font-style: normal;
  font-weight: 400;
  font-stretch: 100%;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosans/v35/o-0mIpQlx3QUlC5A4PNB6Ryti20_6n1iPHjcz6L1SoM-jCpoiyD9A-9a6VI.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

그러나 CJK(Chinese, Japanese, Korean) 문자의 경우 일본어의 히라가나와 가타카나를 제외하면 명확한 범위를 나누기가 어렵습니다.
우선 한자를 생각해봅시다. 모든 뜻마다 하나의 문자가 존재하죠.
게다가 한중일 한자는 모두 조금씩 차이가 있습니다.

한중일 한자 차이

한글은 자음과 모음으로 이루어져 간단하지 않냐고요?
그렇지 않습니다.

한글의 표현방식은 모든 글자를 각각의 코드에 대응시키는 완성형과 창제 원리대로 초중종성을 합쳐 표현하는 조합형이 있습니다.
유니코드에서는 둘 다 지원하지만, Windows나 Linux는 완성형을 주로 쓰며 MacOS는 조합형을 사용합니다.
MacOS에서 다른 운영체제로 파일을 보내면 ㅍㅏㅇㅣㄹ.txt처럼 깨지는 원인이지요.

완성형 코드

완성형과 조합형의 논쟁에 대해서는 조합형/완성형/유니코드의 모든 것과 표준이 된 세벌식? - (4) 옛한글을 나타내는 표준 방안이 된 첫가끝 조합형을 보시면 되겠습니다.

아무튼, 완성형 코드를 모두 넣기에는 폰트의 크기가 지나치게 커지게 됩니다.
따라서 앞에서 언급한 Adobe-KR-0처럼 자주 쓰이는 글자들(2780자)만 포함하도록 만들어졌던 겁니다.

그렇다면 구글은 이 문제를 어떻게 풀었을까요?
그 방식이 아주 구글 답습니다. 바로 머신러닝!!

한국어, 일본어, 중국어를 사용 패턴에 따라 서브셋을 자동으로 수행하여 제공합니다.

/* [0] */
@font-face {
  font-family: 'Noto Sans KR';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosanskr/v36/PbyxFmXiEBPT4ITbgNA5Cgms3VYcOA-vvnIzzuoyeLGC5nwuDo-KBTUm6CryotyJROlrnQ.0.woff2) format('woff2');
  unicode-range: U+f9ca-fa0b, U+ff03-ff05, U+ff07, U+ff0a-ff0b, U+ff0d-ff19, U+ff1b, U+ff1d, U+ff20-ff5b, U+ff5d, U+ffe0-ffe3, U+ffe5-ffe6;
}
/* [1] */
@font-face {
  font-family: 'Noto Sans KR';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosanskr/v36/PbyxFmXiEBPT4ITbgNA5Cgms3VYcOA-vvnIzzuoyeLGC5nwuDo-KBTUm6CryotyJROlrnQ.1.woff2) format('woff2');
  unicode-range: U+f92f-f980, U+f982-f9c9;
}
/* [2] */
@font-face {
  font-family: 'Noto Sans KR';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosanskr/v36/PbyxFmXiEBPT4ITbgNA5Cgms3VYcOA-vvnIzzuoyeLGC5nwuDo-KBTUm6CryotyJROlrnQ.2.woff2) format('woff2');
  unicode-range: U+d723-d728, U+d72a-d733, U+d735-d748, U+d74a-d74f, U+d752-d753, U+d755-d757, U+d75a-d75f, U+d762-d764, U+d766-d768, U+d76a-d76b, U+d76d-d76f, U+d771-d787, U+d789-d78b, U+d78d-d78f, U+d791-d797, U+d79a, U+d79c, U+d79e-d7a3, U+f900-f909, U+f90b-f92e;
}
/* ... */
/* [117] */
@font-face {
  font-family: 'Noto Sans KR';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosanskr/v36/PbyxFmXiEBPT4ITbgNA5Cgms3VYcOA-vvnIzzuoyeLGC5nwuDo-KBTUm6CryotyJROlrnQ.117.woff2) format('woff2');
  unicode-range: U+d, U+48, U+7c, U+ac10, U+ac15, U+ac74, U+ac80, U+ac83, U+acc4, U+ad11, U+ad50, U+ad6d, U+adfc, U+ae00, U+ae08, U+ae4c, U+b0a8, U+b124, U+b144, U+b178, U+b274, U+b2a5, U+b2e8, U+b2f9, U+b354, U+b370, U+b418, U+b41c, U+b4f1, U+b514, U+b798, U+b808, U+b824-b825, U+b8cc, U+b978, U+b9d0, U+b9e4, U+baa9, U+bb3c, U+bc18, U+bc1c, U+bc30, U+bc84, U+bcf5, U+bcf8, U+bd84, U+be0c, U+be14, U+c0b0, U+c0c9, U+c0dd, U+c124, U+c2dd, U+c2e4, U+c2ec, U+c54c, U+c57c-c57d, U+c591, U+c5c5-c5c6, U+c5ed, U+c608, U+c640, U+c6b8, U+c6d4, U+c784, U+c7ac, U+c800-c801, U+c9c1, U+c9d1, U+cc28, U+cc98, U+cc9c, U+ccad, U+cd5c, U+cd94, U+cd9c, U+cde8, U+ce68, U+cf54, U+d0dc, U+d14c, U+d1a0, U+d1b5, U+d2f0, U+d30c, U+d310, U+d398, U+d45c, U+d50c, U+d53c, U+d560, U+d568, U+d589, U+d604, U+d6c4, U+d788;
}
/* [118] */
@font-face {
  font-family: 'Noto Sans KR';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosanskr/v36/PbyxFmXiEBPT4ITbgNA5Cgms3VYcOA-vvnIzzuoyeLGC5nwuDo-KBTUm6CryotyJROlrnQ.118.woff2) format('woff2');
  unicode-range: U+39, U+49, U+4d-4e, U+a0, U+ac04, U+ac1c, U+ac70, U+ac8c, U+acbd, U+acf5, U+acfc, U+ad00, U+ad6c, U+adf8, U+b098, U+b0b4, U+b294, U+b2c8, U+b300, U+b3c4, U+b3d9, U+b4dc, U+b4e4, U+b77c, U+b7ec, U+b85d, U+b97c, U+b9c8, U+b9cc, U+ba54, U+ba74, U+ba85, U+baa8, U+bb34, U+bb38, U+bbf8, U+bc14, U+bc29, U+bc88, U+bcf4, U+bd80, U+be44, U+c0c1, U+c11c, U+c120, U+c131, U+c138, U+c18c, U+c218, U+c2b5, U+c2e0, U+c544, U+c548, U+c5b4, U+c5d0, U+c5ec, U+c5f0, U+c601, U+c624, U+c694, U+c6a9, U+c6b0, U+c6b4, U+c6d0, U+c704, U+c720, U+c73c, U+c740, U+c744, U+c74c, U+c758, U+c77c, U+c785, U+c788, U+c790-c791, U+c7a5, U+c804, U+c815, U+c81c, U+c870, U+c8fc, U+c911, U+c9c4, U+ccb4, U+ce58, U+ce74, U+d06c, U+d0c0, U+d130, U+d2b8, U+d3ec, U+d504, U+d55c, U+d569, U+d574, U+d638, U+d654, U+d68c;
}
/* [119] */
@font-face {
  font-family: 'Noto Sans KR';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosanskr/v36/PbyxFmXiEBPT4ITbgNA5Cgms3VYcOA-vvnIzzuoyeLGC5nwuDo-KBTUm6CryotyJROlrnQ.119.woff2) format('woff2');
  unicode-range: U+20-22, U+27-2a, U+2c-38, U+3a-3b, U+3f, U+41-47, U+4a-4c, U+4f-5d, U+61-7b, U+7d, U+a1, U+ab, U+ae, U+b7, U+bb, U+bf, U+2013-2014, U+201c-201d, U+2122, U+ac00, U+ace0, U+ae30, U+b2e4, U+b85c, U+b9ac, U+c0ac, U+c2a4, U+c2dc, U+c774, U+c778, U+c9c0, U+d558;
}

저는 구글의 머신러닝 결과를 날먹(?)하여 블로그에 적용할 폰트에 사용하고 싶었습니다.
따라서 CSS의 unicode-range 부분만을 파싱하여 서브셋해주는 라이브러리를 만들었죠.
font-range의 탄생배경입니다.

CSS 파일 경로나 URL을 입력하면 알아서 다운로드 받아 unicode-range에 따라 서브셋 해줍니다.

fontRange(font_path, css_url_or_path);
fontRange(font_path, css_url_or_path, save_dir);       // Option1
fontRange(font_path, css_url_or_path, { ...options }); // Option2

물론 텍스트를 이용한 서브셋까지 모두 지원합니다.

fontSubset(font_path);
fontSubset(font_path, save_dir);       // Option1
fontSubset(font_path, { ...options }); // Option2

그리고, 매번 호출할 필요 없이 한번에 효율적인 서브셋을 할 필요가 생겨서 만들어진 API가 있으니 fontPipe입니다.

fontPipe([
  { font_path },                                      // As `fontSubset(font_path)`
  { font_path, option: { text: "abc" } },             // As `fontSubset(font_path, { text: "abc" })`
  { font_path, option: { textFile: file_path } },     // As `fontSubset(font_path, { textFile: file_path })`
  { font_path, option: { cssFile: css_url_or_path } } // As `fontRange(font_path, css_url_or_path)`
]);
fontPipe([{ font_path1 }, { font_path2 }], "<index>/<total>"); // Sharding option use like `1/2`

효율적인 서브셋하기

font-range의 fontPipe()는 얼마나 효율적일까요?

제가 구현한 프리텐다드의 고성능 서브셋 시스템을 보면 그 위력을 알 수 있습니다.

기존 서브셋

고성능 서브셋

한시간 동안 걸리던 작업이 겨우 5분으로 줄어들었습니다!!!
수치상 11.14배가 빨라진거죠.

대체 어떻게 이런 일이 가능했을까요?
그 비밀을 파고들어봅시다.

쉘 생성 제거

먼저 서브셋 작업을 어떻게 하나 알아봅시다.
저는 이미 만들어진 서브셋 유틸리티를 사용했습니다.

파이썬의 폰트툴즈(fonttools) 패키지를 설치하면 제공되는 pyftsubset입니다.
보통 이렇게 Shell 명령어로 사용합니다.

pyftsubset "NotoSansCJKkr-Regular.otf" \
  --flavor="woff2" \
  --output-file="./subset-fonts/NotoSansR.subset.5.woff2" \
  --text-file="glyphs.txt" \
  --layout-features='*' \
  --glyph-names \
  --symbol-cmap \
  --legacy-cmap \
  --notdef-glyph \
  --notdef-outline \
  --recommended-glyphs \
  --name-legacy \
  --drop-tables= \
  --name-IDs='*' \
  --name-languages='*'

Node.JS에는 명령어를 실행하기 위한 방법으로 exec나 spawn이 있습니다.
exec는 bash와 같은 쉘을 이용해 실행하므로 자동적으로 이스케이프 처리가 되어, spawn 보다 편리합니다.
복잡한 옵션 명령어들을 다루어야 했던 제게 exec가 가진 이점이 컸습니다.

서브셋 해야할 폰트가 적었던 초반에는 엄청나게 커다란 문제가 되지 않았지만, pretendard-jp와 pretendard-std처럼 새로운 폰트들이 추가되고 가변폰트의 다이나믹 서브셋까지 지원하면서 엄청난 양의 서브셋이 만들어지게 됩니다.
용량이 너무 커서 NPM에 올라가지 못해 반쯤 강제로 패키지를 나누어 관리하는 모노레포 작업까지 했었어야 했죠.

서브셋이 생성되는 조건을 몇가지 적어보도록 하겠습니다.

폰트 패밀리: pretendard, pretenard-std, pretendard-jp와 최근 추가된 pretendard-gov처럼 다양한 폰트 바리에이션들
굵기: 프리텐다드는 9개의 weight를 지원합니다. 모든 굵기가 합쳐져 옵션으로 조정하는 가변폰트도 있습니다.
포맷: woff와 woff2 형식으로 나뉩니다.
서브셋 범위: 전체, Adobe-KR-0, unicode-range를 이용한 다이나믹 서브셋

특히 다이나믹 서브셋은 각 폰트파일당 90개가 넘게 나뉘어집니다.
단순히 곱해서 계산을 해보면 수천개의 서브셋이 만들어져야 합니다.

때문에 Pretendard 스케일에서는 쉘 생성 제거는 효용을 가지게 될만하다 판단해 쉘 생성을 제거해보기로 결정했습니다.
대신 이스케이프처리와 같이 편리함은 포기하기 싫었어요.

그래서 execa라는 라이브러리를 사용하였습니다.
execa 자체는 esm 모듈을 사용하고 있어 esm2cjs/execa로 설치했고요.

지금 벤치마크 결과는 없지만 당시 기억으로 8%정도의 개선이 있었습니다.

워커 풀

이번에는 변환 작업 자체의 속성을 생각해보도록 합시다.
작업의 속성에 따라 개선 방향이 달라지기 때문이지요.

작업의 속성을 크게 2가지로 나누자면 CPU와 I/O 작업이 있습니다.

CPU bound vs I/O bound

만약 CPU 중심 작업이라면 병렬성(parallel), I/O 중심 작업이라면 동시성(concurrent)에 신경을 써야하겠지요.

동시성 vs 병렬성

서브셋 작업은 어디에 속할까요?
파일을 읽고 쓰기는 분명 I/O겠지만, 명령이 실행되는 동안 오랫동안 기다려야 하는 변환작업은 CPU를 계속 점유해야 가능합니다.
CPU Bound 작업이라는거죠.

하지만 자바스크립트는 싱글 스레드 언어이며, Node.JS도 마찬가지의 한계를 가지고 있습니다.

싱글쓰레드

JS의 await는 I/O에는 뛰어나지만, CPU Bound일때는 다른작업들이 차단(block)되어 실행되지 않습니다.
다행히도 당시 코드를 사용해보면 여러 Promise가 반환되어 Promise.all()로 처리할 수 있었습니다.
완전히 멈춰있는 최악의 상황은 아니었지요.

  return ranges.then(eachRanges => eachRanges.map((unicodes, i) => {
    const saveOption = "--output-file='" +
      join(dirPath, getName(nameFormat, fontName, i, fontExt)) + "' ";
    const unicodeRanges = unicodes.split(', ').join(',');
    const unicodeOption = "--unicodes='" + unicodeRanges + "' ";

    const options = " '" + fontPath + "' " + saveOption + unicodeOption
      + convertOption + defaultOption + etcOption;
    return execSync("pyftsubset" + options);
  }));

하지만 수십개의 프로세스가 동시에 나타납니다.
OS는 모든 프로세스를 공평하게 실행시켜줘야 하기 때문에 작업을 전환시킵니다.

그러면 이른바 컨텍스트 스위칭이 일어나게 되며, 성능이 저하됩니다.
여러가지 일을 번갈아가며 하느라 집중이 자꾸 깨지는 상태인 거죠.

컨텍스트 스위칭

그럼 어떻게 하는게 좋을까요?
해결할 수 있는 방법 중 하나는 CPU 코어 갯수대로만 쓰레드를 만들고 큐 형태로 관리하여 일을 배분해주는 겁니다.
점유가 끝나야 다음 작업을 시작하므로 컨텍스트 스위칭이 최소화됩니다.

쓰레드 풀

Piscina라는 워커 풀을 사용하였습니다.
자바스크립트 세계에서 CPU 바운드 작업은 Worker를 사용하면 됩니다.

Worker

워커 풀을 사용 시 몇가지 실수하거나 헷갈릴만한 것들이 존재합니다.
첫번째로 워커는 일반적으로 다른 script 파일이어야 하므로 worker.ts에서 명령이 실행되어야 하죠.

두번째, 명령 실행을 동기적으로 해야합니다.

export default function subset({options, log = ""}: SubsetI) {
  if(log !== "") {
    console.log(log);
  }
  return execaSync("pyftsubset", options);
}

왜 그럴까요?
바로 자바스크립트 언어 특성 때문입니다.

만약 비동기로 실행하게 되면 async를 만나는 순간 프로미스로 반환해버리고, 작업이 끝난 취급을 받아 다음 작업으로 넘어가게 되어 워커풀을 도입하기 전과 동일하게 수많은 프로세스가 생기게 됩니다.

await 실행

마지막으로 싱글턴 패턴을 사용하여 워커풀이 처음 한번만 초기화되도록 보장했습니다.

type WorkerRT = ReturnType<typeof WorkerFn>;

class Worker {
  private static instance: Piscina;
  private constructor() { }

  public static getInstance(): Piscina {
    if(!Worker.instance) {
      Worker.instance = new Piscina({
        filename: join(__dirname, "../", "build", "worker.js")
      });
    }
    return Worker.instance;
  }
}

워커 풀은 약 20%의 성능 개선을 가져왔던 걸로 기억합니다.

샤딩

샤딩(Sharding)은 주로 DB쪽에서 사용되는 용어로 분산하여 저장하는 프로세스입니다.

구현은 정말 간단합니다.
예를 들어 10개의 작업이 있을 때 2/5와 같은 옵션을 주면 2/5의 양만큼만 처리하므로 3과 4만 실행되는 방식입니다.

그렇다면 사용시 고려해야하는 점은 있을까요?
당연히 몇가지 있습니다.

첫번째, "1/5"~"5/5"까지 처리한 작업물들을 모아서 합쳐야 합니다.
저는 커밋을 만들어 push하고 rebase하는 형식으로 처리했습니다.

runs:
  using: "composite"
  steps:
    - name: Commit Build File
      shell: bash
      run: |
        git config user.name "$(git log -n 1 --pretty=format:%an)"
        git config user.email "$(git log -n 1 --pretty=format:%ae)"
        if [[ "$(git branch -r --contains ${{ inputs.branch }} 2>/dev/null)" ]]; then
          git checkout ${{ inputs.branch }}
        else
          git checkout -b ${{ inputs.branch }}
        fi
        git add --ignore-removal ${{ inputs.file_pattern }}
        if [[ "$(git diff --staged)" != "" ]]; then
          git commit -m "${{ inputs.message }}"
          if [[ "$(git branch -r --contains ${{ inputs.branch }} 2>/dev/null)" ]]; then
            git push origin ${{ inputs.branch }}
          else
            git push -u origin ${{ inputs.branch }}
          fi
        fi

, 분산할 수 있는 시스템에는 한계가 있을 수 있습니다.
깃허브의 경우 동시에 실행가능한 작업은 20개이며, MacOS는 5개입니다.
Linux는 2코어이지만 MacOS는 현재 3코어, 4코어도 지원하므로 성능 측정을 해야합니다.

당시에는 3코어짜리 MacOS만 존재했는데, 3코어 MacOS 5개 대신 2코어 Linux 8개를 사용하는 성능 특성이 좋아 모두 리눅스 머신을 기준으로 해서 처리하였습니다.

  pretendard-jp:
    runs-on: ubuntu-latest
    if: contains(github.event.head_commit.message, 'release:')
    strategy:
      matrix:
        shard: ["1/8", "2/8", "3/8", "4/8", "5/8", "6/8", "7/8", "8/8"]
        include:
          - shard: "1/8"
            branch: "jp-1"
          - shard: "2/8"
            branch: "jp-2"
          - shard: "3/8"
            branch: "jp-3"
          - shard: "4/8"
            branch: "jp-4"
          - shard: "5/8"
            branch: "jp-5"
          - shard: "6/8"
            branch: "jp-6"
          - shard: "7/8"
            branch: "jp-7"
          - shard: "8/8"
            branch: "jp-8"
    steps:
    - uses: actions/checkout@v3
      with:
        fetch-depth: '0'
    - uses: ./.github/actions/setup-pip
    - uses: ./.github/actions/setup-yarn
    - uses: ./.github/actions/subset-push
      with:
        workspace: pretendard-jp
        shard: ${{ matrix.shard }}
        branch: ${{ matrix.branch }}

세번째, 불균일한 작업시간입니다.
모든 문자를 woff2로 변환해야하는 static 작업은 문자 집합의 일부분만 변환하면 되는 다이나믹 서브셋의 각 작업보다 느립니다.

font-range 내부에서는 dynamic의 unicode-range들을 각각 작업으로 처리하고 있습니다.

그래서 전 오래걸리는 static 작업끼리 모아놓기보다는 순서를 적당히 섞는 간단한 휴리스틱으로 Normalizing을 했습니다.

// 전
subsets(
  // Pretendard
  ["static",    "woff",  fontList],
  ["static",    "woff2", fontList],
  ["glyph",     "woff",  fontList],
  ["glyph",     "woff2", fontList],
  ["dynamic",   "woff",  fontList],
  ["dynamic",   "woff2", fontList],
  // Pretendard Variable
  ["static",    "woff2", variable],
  ["dynamic",   "woff2", variable]
);

// 후
subsets(
  // Pretendard woff
  ["static",    "woff",  fontList],
  ["glyph",     "woff",  fontList],
  ["dynamic",   "woff",  fontList],

  // Pretendard woff2
  ["static",    "woff2", fontList],
  ["glyph",     "woff2", fontList],
  ["dynamic",   "woff2", fontList],

  // Pretendard Variable
  ["static",    "woff2", variable],
  ["dynamic",   "woff2", variable]
);

물론 Shuffle하는 방식도 생각해보았지만, 결정적이어야하는 Sharding 시스템 특성상 어울리지 않았습니다.
그래서 seed 값을 사용하는 방안(seedrandom, seed-shuffle)도 생각해보았으나 너무 오버엔지니어링에 테스팅도 까다로워질 것 같아 시도해보지 않았어요.

대신 나중에 필요하면 한번즈음 시도는 해볼 것 같네요.

좋습니다. 그래서 성능은 어떨까요?
10배가 넘는 성능을 만든 1등공신입니다!!

끝

이렇게 훌륭한 일을 하지만, 놀랍게도 font-range의 소스코드는 500라인에 불과합니다.
가독성도 좋은 편이니 시간이 있으신 분들은 한번쯤 읽어보시는 것도.

위가 원래 내용으로 주말에 작성하여 다른 팀의 직원의 문서변환 작업에 우선적으로 도움을 주기 위한 용도 였습니다.

그러나...ㅠㅠ 변환과 성능 최적화를 제가 맡게 되면서 여러가지 작업을 하게 되었는데요.

20만건이 넘는 데이터를 PDF로 변환하기: 제가 참여하기 전보다 200% 이상의 성능개선!!
- 위의 쉘 생성 제거와 워커풀 활용
- Puppeteer 또는 Selenium 대신 성능/안정화를 위해 패치한 JSDOM
- 역시 성능/안정화를 위해 프로미스 풀
- 파일 건너뛰기와 로컬 이미지 사용
- Stream I/O
일부 엑셀 파일을 PDF로 변환하기
- 헤드리스 모드의 LibreOffice에서 출력용 VBA를 적용 후, PDF 생성
- CUPS와 같은 패키지가 추가로 필요할 수도 있음
웹사이트에서 PDF 뷰어 제공하기
- PDF.JS는 생각보다 커스텀하기 까다롭게 되어 있다
- 서버의 헤더를 요구하거나 .mjs등의 확장자 때문에 추가적인 리소스 허용등의 설정이 필요할 수도.

사실 생각나는대로 위보다 자세하게 추가적인 메모는 해두었는데..

이 정도가 NDA에서 어긋나지 않는 선에서 공개할 수 있는 내용인듯.

리스프에서 멋진 3가지.

BlaCk_Void — Sun, 3 Nov 2024 13:32:20 +0900

이 글을 쓰게 된 계기는 Racket 공식 계정의 좋아요 때문.

그리고 plwiki에 조금 기여해볼까 생각 중.

여러분은 방금 Racket 언어 사용법의 90%를 익혔습니다.

리스프라 하면 고전언어라고만 생각할지도 모르겠으나,

선진적으로 구현된 부분들도 많다.

이 중 Code as data, data as code 혹은 Homoiconicity처럼 식상한 것을 제외하고, 알아보도록 합시다.

Racket - 매크로: 본디 리스프에서 매크로는 유명하다. 그 중에서도 Racket의 매크로는 조금 특별하다.
Racket - parameterize: Thread와 함께 사용할 수 있는 동적 바인딩.
Common Lisp - CLOS: 매우 동적이고 유연한 객체지향 시스템.

이 글을 보게되면 제가 가끔씩 Racket 기습찬양하는 이유를 알게될지도 모르겠네요.

1. Racket - 가장 강력하고 안전한 매크로

매크로는 코드를 생성하거나 변환할 때 사용하는 강력한 도구입니다.

하지만 위험하고, 작성하기 어렵기로 유명합니다.

1.1 안전한 매크로

1.1.1 C vs Racket: 매크로가 구문이어야 하는 이유

먼저 안전한 매크로란 무엇인가에 대해 알아봅시다.

C와 Racket의 매크로를 간단히 만들어 비교해보면 다음과 같습니다.

#include <stdio.h>

#define MAX(a, b) (a > b ? a : b)
#define DEBUG_PRINT(x) printf("%s = %d", #x, x)

// 사용 예
int main() {
    int x = 5, y = 10;
    int max = MAX(x, y);
    DEBUG_PRINT(max);
    return 0;
}

Racket의 방식이 전위식이라서 익숙하지 않은 것을 제외하고는 어렵지 않을 것이다.

#lang racket

(define-syntax-rule (max-of a b)
  (if (> a b) a b))

(define-syntax-rule (debug-print x)
  (printf "~a = ~a" 'x x))

;; 사용 예
(let ([x 5] [y 10])
  (let ([max (max-of x y)])
    (debug-print max)))

결과는 max = 10이라는 출력.

max라는 심볼과 10이라는 값을 잘 활용했음을 볼 수 있습니다.

여기까지는 별 차이가 없어보인다.

그러나 C의 매크로와 Racket의 매크로에는 근본적인 차이가 있습니다.

C 매크로는 단순한 텍스트 치환에 가까운 반면,

Racket의 매크로는 함수를 정의할 때처럼 구문처럼 취급합니다.

이를 확인하기 위해 변수의 값을 바꿔주는 swap 매크로를 구현해보았다.

#define SWAP(a, b) \
    typeof(a) temp = a; \
    a = b; \
    b = temp;

// 사용 예
int main() {
    int x = 1, y = 2;
    SWAP(x, y);

    DEBUG_PRINT(x);
    DEBUG_PRINT(y);
    return 0;
}

(define-syntax-rule (swap a b)
  (let ([temp a])
    (set! a b)
    (set! b temp)))

(let ([x 1] [y 2])
  (swap x y)
  (debug-print x)
  (debug-print y))

실행해보면

x = 2이고, y = 1로 잘 변환됨을 알 수 있습니다.

그렇다면 temp = 3이라고 추가적인 변수를 미리 선언해놓고 실행해보면 어떨까요?

int main() {
    int x = 1, y = 2, temp = 3;
    SWAP(x, y);

    DEBUG_PRINT(x);
    DEBUG_PRINT(y);
    return 0;
}

(let ([x 1] [y 2] [temp 3])
  (swap x y)
  (debug-print x)
  (debug-print y))

Racket과 달리 C에서는 temp가 이미 선언되었다며 에러가 났음을 확인할 수 있다.

C는 매크로를 확장할 때 문자열의 치환이므로, 변수 캡쳐나 문법등을 고려하여 조심히 구현해야 합니다.

#define swap(a, b) do { \
    typeof(a) temp = a; \
    a = b; \
    b = temp; \
} while(0)

왜 일반 블록 뿐만이 아니라 do ~ while(0)을 넣었느냐.

일반 블록을 넣게 되면 다음과 같은 경우에 if (x > y) { swap 내용 }; else 내용으로 해석되게 되므로, main.c:24:5: error: ‘else’ without a previous ‘if’와 같은 에러가 나오게 되기 때문입니다.

#define SWAP(a, b) { \
    typeof(a) temp = a; \
    a = b; \
    b = temp; \
}

int main() {
    int x = 1, y = 2, temp = 3;

    if (x > y)
        SWAP(x, y);
    else
       printf("not SWAP!!\n");

    DEBUG_PRINT(x);
    DEBUG_PRINT(y);
    return 0;
}

C 매크로의 이상한 예를 하나 더 들어봅시다.

다음은 10을 곱하는 매크로 정의입니다.

그러나 문자열 치환과 연산자 우선순위에 의해서 각각의 결과가 모두 다릅니다.

#include <stdio.h>

#define MULTIPLY1(x) x * 10
#define MULTIPLY2(x) (x * 10)
#define MULTIPLY3(x) ((x) * 10)

// 사용 예
int main() {
    printf("1: %d\n", MULTIPLY1(1 + 2) * 3); // 1 + 2 * 10 * 3 = 61
    printf("2: %d\n", MULTIPLY2(1 + 2) * 3); // (1 + 2 * 10) * 3 = 63
    printf("3: %d\n", MULTIPLY3(1 + 2) * 3); // ((1 + 2) * 10) * 3 = 90
    return 0;
}

C에서 매크로를 안전하게 사용하기 위해서는 인자 참조시 괄호를 넣어줘야 합니다.

(위에 있는 버전에서는 가독성을 위해 의도적으로 넣지 않았다)

이외에도 많은 예상치 못한 에러들이 쏟아질 수도 있죠.

반면 Rakcet의 매크로는 구문이며, 위생적 매크로이기 때문에 문법에러나 변수캡쳐등을 고려할 필요가 없이 안전하게 매크로를 작성할 수 있습니다.

음.. 그렇다면 다른 Lisp의 매크로와는 어떻게 비교될까요?

1.1.2 Common Lisp vs Racket: 위생적 매크로여야 하는 이유

Common Lisp의 매크로는 구문이지만 '위생적(Hygienic)'이라고 하지 않습니다.

위생적 매크로는 의도하지 않은 변수 캡쳐나 이름 충돌을 방지합니다.

바로 예를 들어보죠.

다음 Common Lisp 매크로의 결과는 6입니다.

의도치 않게 사용 예의 temp가 캡쳐되어 (+ temp 1)의 값으로 setf 된겁니다.

(defmacro without-gensym (num &body body)
  `(let ((temp ,num))
     (setf temp (+ temp 1))
     ,@body))

;; 사용 예
(let ((temp 5))
  (without-gensym temp
    (print temp))) ;; 결과: 6

의도치 않은 변수 캡쳐를 방지하려면 어떻게 해야 할까?

gensym(generate symbol)을 사용해 고유한 심볼을 생성하도록 해야합니다.

이렇게 하면 매크로 내부의 temp와 외부의 temp가 서로 다른 변수로 취급되어 충돌을 방지할 수 있습니다.

(defmacro with-gensym (num &body body)
  (let ((temp (gensym)))
    `(let ((,temp ,num))
       (setf ,temp (+ ,temp 1))
       ,@body)))

;; 사용 예
(let ((temp 5))
  (with-gensym temp
    (print temp))) ;; 결과: 5

규칙 자체는 간단하지만, 조심해야 한다는 점은 여전합니다.

반면 Racket은 위생적인 매크로이기 때문에 일반적인 lexical scope처럼 사용할 수 있습니다.

(define-syntax-rule (without-gensym num body ...)
  (let ([temp num])
    (set! temp (+ temp 1))
    body ...))

;; 사용 예
(let ([temp 5])
  (without-gensym temp
    (print temp))) ;; 결과: 5

반대로 Racket에서 Common Lisp처럼 영향을 미치려면 어떻게 해야 할까요?

다음과 같이 param에 대입을 해주면 되겠습니다.

(define-syntax-rule (without-gensym num body ...)
  (let ([num (+ num 1)])
    body ...))
 
 ;; 사용 예
(let ([temp 5])
  (without-gensym temp
    (print temp))) ;; 결과: 6

Racket의 매크로가 확실히 쉽고 명확한 편이죠?

두려움에 떨지 않고 매크로를 만들기 위해서 매크로는 구문이어야 하며, 위생적이어야 합니다.

1.2 강력한 매크로

define-syntax-rule을 써보았을때 안전한 매크로구나!!

라는 생각은 들었지만 그렇다고 저것만으로 강력한 DSL을 정의할 수 있다는 생각이 들지는 않습니다.

어쩌면 당연한 것이 define-syntax에서 제약된 형태 중 일부인데다, 활용법을 모르기 때문입니다.

1.2.1 바닥부터 톺아보기

앞서 매크로는 코드를 생성하거나 변환하는 용도라고 했습니다.

그리고 이와 비슷한 용도로 빌드나 컴파일 레벨에서 동작하는 도구가 있습니다.

Babel, SWC와 같은 transform이 예시죠.

Babel 플러그인을 만들때처럼, AST 대신 Syntax Object가 존재하며 input-output 값으로 사용됩니다.

define-syntax에서 transformer-expression에는 syntax 객체가 input으로 들어오는 callback이며, syntax 객체로 return 해야합니다.

(define-syntax macro-name
  transformer-expression)

먼저 들어오는 syntax 객체는 신경쓰지 않고, 항상 "Hello, world!!"를 출력하는 매크로를 만들어봅시다.

hello-macro는 확장되어, 컴파일타임에 "Hello, world!!" 문자열로 대체됩니다.

(define-syntax hello-macro
  (lambda (stx)
    (syntax "Hello, world!!")))

(hello-macro)로 실행해보면 "Hello, world!!"가 출력되었을 것입니다.

람다 콜백은 함수정의와 마찬가지로 lambda는 짧게 줄여서 할당해 간결히 만들어봅시다.

syntax 함수는 #'로 줄일수 있다. #'는 Lisp계열에서 함수 심볼이라고 표시하는 용도로 많이 쓰이나, Racket에서는 syntax 객체를 나타내기 위해 사용된다.

(define-syntax (hello-macro stx)
  #'"Hello, world!!")

Racket에서 Macro stepper를 활용해 확장된 모습을 보거나,

expand를 이용해 확장된 모습과 정보를 확인해볼 수 있다.

(expand #'hello-macro)

정의된 라인이나 컬럼등 메타 정보들도 눈에 띕니다.

1.2.2 Syntax 객체와 리스트 다루기

다만 syntax는 뒤에 값들을 아예 평가하지 않고, syntax 객체로 만들기 때문에 의도와 달라질 수도 있습니다.

예를 들어 (syntax (+ 1 2))는 '(+ 1 2)' 자체가 syntax 객체가 되며, 미리 계산이 되지 않지요.

변수도 마찬가지로 (syntax (+ 1 num))을 하게되면 변수가 바인딩되지 않고, 평가될때 비로소 바인딩 됩니다.

(define num 2)
(define my-syntax (syntax (+ 1 num)))

;; 사용
(expand my-syntax) ;; (#%app + '1 num) 로 확장됨
(eval my-syntax) ;; 이때 바인딩 및 평가

따라서 미리 함수를 평가하고 싶거나, 현재 컨텍스트의 값을 바인딩하고 싶다면 다음과 같이 사용해야 합니다.

(quasisyntax (unsyntax (+ 1 2))) ;; 3으로 평가됨
(quasisyntax (+ 1 (unsyntax num))) ;; (+ 1 2)로 num이 바인딩 됨

역시 길다면 quasisyntax는 #`으로, unsyntax는 #,으로 줄여서 쓸 수 있습니다.

#`#,(+ 1 2)
#`(+ 1 #,num)

Syntax 객체를 데이터로 바꾸는 것도 가능합니다.

데이터로의 변환이 아니라 메타 데이터를 가져오고 싶다면 syntax-line이나 syntax-column과 같은 연산자를 활용하면 된다.

데이터로의 변환이 아니라 syntax를 분해하여 syntax list로 만들고 싶다면 syntax->list를 활용하자.

(syntax->datum #'(+ 1 2))

위 결과는 '(+ 1 2)라는 리스트다.

여기서 Lisp의 리스트와 조작법에 대해 잠시 알아봅시다.

Lisp가 LISt Processor의 준말임을 생각하면 리스트와 조작에 대한 이해가 없다면 어려움이 생길 수 있습니다.

안다면 바로 다음으로 넘어가고, 모른다면 설명을 읽어보면 도움이 될 것이다.

Lisp의 리스트는 Cons cell라는 2개의 포인터를 이용한 링크드 리스트로 되어 있습니다.

예를 들어 아래 이미지는 중첩리스트인 (list a (r t) b)를 나타낸 것이다.

마지막의 nil 혹은 '()는 null을 나타낸다. 리스프에서는 비어있는 리스트와 null이 동치인 표현입니다.

중첩리스트인 '(a (r t) b)

물론 cons cell이 꼭 null로 끝날 필요는 없습니다.

(cons 1 2)를 해보면 1과 2를 가르키는 pair 구조를 만들어 낼 수 있죠.

여기서도 앞에서 그랬듯이 축약 표현이 있습니다.

(cons 1 2)는 '(1 . 2)
(cons 1 (cons 2 (cons 3 '())))은 (list 1 2 3)
(list 1 2 3)은 '(1 2 3)

으로 나타내는 식입니다.

그럼 '(1 2 3)을 어떻게 조작해야 할까요?

가장 간단한 것은 car과 cdr입니다.

(car '(1 2 3)): 첫번째 참조값인 1을 리턴
(cdr '(1 2 3)): 두번째 참조값인 2를 리턴
(car (cdr '(1 2 3))): 2를 리턴.
- 축약하여 (cadr '(1 2 3))처럼 사용할 수 있음
- caar, cddr, cddar과 같은 방식

이름이 car, cdr인게 이상해 보일 수 있으나. 나름의 역사적인 이유가 존재합니다.

많이 쓰일만한 함수로는 다음이 있습니다.

(length '(1 2 3)): 길이인 3
(list-ref '(1 2 3) 2): index에 따른 접근
(append '(1 2 3) '(4 5)): 두 리스트를 이어 '(1 2 3 4 5)를 만듦
(reverse '(1 2 3)): 뒤집어 '(3 2 1)을 출력

함수형 언어답게 고차함수도 있으니 문서를 확인해보자.

https://black7375.tistory.com/38

내 맘대로 프로그램 설계 5. - 리스트와 재귀.

내 맘대로 하는 프로그램 설계 시리즈.Chapter1 - 간단한 데이터 처리(4섹션) 2017/12/27 - [프로그래밍/설계] - 내 맘대로 프로그램 설계 1. - 이유와 준비.2018/01/11 - [프로그래밍/설계] - 내 맘대로 프로

black7375.tistory.com

추가적으로 보고 싶으시다면 예전에 써놨던 글을 참고해보셔도 좋을 것 같습니다.

이제 준비되었다.

본격적으로 매크로를 다루어봅시다.

1.2.3 define-syntax 사용해보기

그럼 아주 간단하게 컴파일 타임에 리스트의 갯수를 반환해주는 매크로를 만들어볼까요?

#`로 평가가 가능한 Syntax 객체로 만들고 #,로 평가를 진행했습니다.

(define-syntax (length-of stx)
  #`#,(length (syntax->datum stx)))

(legth-of '(1 2 3)) ;; 결과는?

결과가 3을 예상하지만..!

실제로 나온 결과는 2입니다.

왜 일까요?

일단 input으로 들어온 syntax 객체를 프린트 해봅니다.

(define-syntax (length-of stx)
  (println (syntax->datum stx))
  #`#,(length (syntax->datum stx)))

'(length-of '(1 2 3)) 가 출력됩니다.

그러니까 다음과 같은 상태인 겁니다.

함수 이름부터 포함해서 변환에 필요한 정보가 모두 들어온다고 생각할 수 있습니다.

그림을 보고 침착하게 '(1 2 3)만 나오도록 추출을 해봅시다.

(car (cdr (car (cdr '(length-of '(1 2 3))))))

줄이면 cadadr이 되겠죠?

(define-syntax (length-of stx)
  #`#,(length (cadadr (syntax->datum stx))))
  
 (legth-of '(1 2 3)) ;; 결과: 3

좋습니다.

방금전에는 컴파일 타임 계산이었지만, 리스프 매크로 특유의 강력함과 명성을 표현하기에는 약해보입니다.

그래서 두가지 정도의 예를 더 들어보도록 하겠습니다.

다른 패러다임 문법 구현
함수/변수 자동 생성

다른 도구 없이 Syntax 객체만 조작하여 만들기 때문에 다소 어렵게 느껴질 수도 있습니다.

단, 전자는 이 파트에서 다루며, 후자는 매크로가 복잡해지기 때문에 다음 파트에서 구현해보겠습니다.

다른 패러다임 문법 구현으로는 명령형 패러다임의 대표적인 문법인 while문을 만들어봅시다.

(while 조건 ...본문) 이어야 하므로 최소 3개 이상으로 이루어져 있어야 함
조건과 본문 부분을 뽑아냄
본문은 여러개의 표현식으로 이루어 질 수 있으므로 javascript에서 spread 연산자를 쓰듯, @을 추가로 붙여줘야 한다.
조건이 true일 경우 반복하는 재귀함수

(define-syntax (while stx)
  (let ([parts (syntax->datum stx)])
    (if (< (length parts) 3)
        (raise-syntax-error 'while "올바른 형식이 아닙니다: (while condition body ...)" stx)
        (let ([condition (cadr parts)]
              [body (cddr parts)])
          #`(let loop ()
              (when #,condition
                #,@body
                (loop)))))))

;; 사용
(define counter 0)
(while (< counter 5)
  (println counter)
  (set! counter (+ counter 1)))

0, 1, 2, 3, 4가 순서대로 잘 실행됩니다.

그러나 버그가 있습니다.

syntax->datum은 모든 syntax 메타 정보를 날려버리기 때문에 글로벌 변수가 아니라 지역변수인 let을 사용하면 작동하지 않습니다.

따라서 syntax 정보를 보존하는 syntax->list로 변환하여 사용할 필요가 있다.

(define-syntax (while stx)
  (let ([parts (syntax->list stx)])
    (if (< (length parts) 3)
        (raise-syntax-error 'while "올바른 형식이 아닙니다: (while condition body ...)" stx)
        (let ([condition (cadr parts)]
              [body (cddr parts)])
          #`(let loop ()
              (when #,condition
                #,@body
                (loop)))))))

;; 사용
(let ([counter 0])
  (while (< counter 5)
    (println counter)
    (set! counter (+ counter 1))))

확실히 수동적으로 조작하려니 힘들지요?

갯수를 세거나, cadr, cddr 따위로 각 파트를 분리해내는 것, 바인딩이 말입니다.

바인딩은 with-syntax를 이용해 보다 간단히 만들 수 있습니다.

(define-syntax (while stx)
  (let ([parts (syntax->list stx)])
    (if (< (length parts) 3)
        (raise-syntax-error 'while "올바른 형식이 아닙니다: (while condition body ...)" stx)
        (let ([condition (cadr parts)]
              [body (cddr parts)])
          (with-syntax ([condition condition]
                        [(body ...) body])
            #'(let loop ()
                (when condition
                  body ...
                  (loop))))))))

...는 body를 rest parameter로 인식하도록 합니다.

사용할 때는 함께 써야 해요.

1.2.4 매턴매칭 매크로: 선언적으로 작성하기

그렇다면 어떻게 만드는게 좋을까요?

제목에 있듯, 패턴 매칭을 해봅시다. syntax-case를 이용해서요.

(define-syntax (while stx)
  (syntax-case stx ()
    [(_ condition body ...)
     #'(let loop ()
         (when condition
           body ...
           (loop)))]
    [_ (raise-syntax-error 'while "올바른 형식이 아닙니다: (while condition body ...)" stx)]))

훨씬 간단해졌죠?

사실 with-syntax도 패턴 매칭을 할 수 있으므로 사용해도 상관없습니다만, syntax-case가 더 선언적일거에요.

단, rest parameter는 0개일때도 작동하므로, 반드시 1개이상의 표현식을 가지도록 body와 body-rest를 만들어줍시다.

그리고 패턴 매칭에 실패하면 알아서 에러를 띄우므로 굳이 에러처리를 해야할 필요도 없습니다.

(define-syntax (while stx)
  (syntax-case stx ()
    [(_ condition body1 body-others ...)
     #'(let loop ()
         (when condition
            body1 body-others ...
           (loop)))]))

#'도 조금 거슬리지요?

syntax-rules를 사용하여 해결해봅시다.

단, syntax-rules는 콜백을 리턴해주니 변수에 정의하도록 바꿉니다.

(define-syntax while
  (syntax-rules ()
    [(_ condition body1 body-others ...)
     (let loop ()
       (when condition
         body1 body-others ...
         (loop)))]))

여기에서는 패턴이 단 하나이니, 처음에 나왔던 define-syntax-rule로 줄여서 사용할 수도 있겠죠?

처음과 비교해보면 말도 안되게 편리해집니다 ㅋㅋㅋㅋ

(define-syntax-rule (while condition body1 body-others ...)
  (let loop ()
    (when condition
      body1 body-others ...
      (loop))))

Rust를 이끌던 Dave Herman이 매크로 애호가이며, Rust의 매크로 설계에 Racket이 큰 영향을 끼치기도 했습니다.

실제로 Rust 매크로에서 macro_rules!는 syntax-rules와 비슷하고, proc_macro는 define-syntax와 비슷합니다.

또한 set! 처럼 사이드이펙트가 있는 경우 Racket에서는 !를 마지막에 붙이는 관습이 있는데, Rust에서는 선언적 매크로에 !를 붙이도록 하는 작은 변형도...

// 선언적 매크로
#[macro_export]
macro_rules! vec {
    ( $( $x:expr ),* ) => {
        {
            let mut temp_vec = Vec::new();
            $(
                temp_vec.push($x);
            )*
            temp_vec
        }
    };
}

// 절차적 매크로
use proc_macro;

#[some_attribute]
pub fn some_name(input: TokenStream) -> TokenStream {
}

물론 Rust는 중위식이라 전위식 기반인 Racket보다 훨씬 복잡한데다가 타입등의 이유로 매크로 자체를 짜는 난이도가 높을수밖에 없습니다.

Lisp는 사실상 그 자체로 AST나 다름없다보니... 훨씬 쉬운편이지요.

1.2.5 syntax-case vs syntax-rules: 컴파일타임과 런타임

아직은 syntax-case와 syntax-rules가 헷갈릴겁니다.

앞서 본 차이로는 syntax-case에서 있던 Syntax 객체 생성 문법인 #'가 사라진 것, syntax-rules에는 stx 매개변수가 없다는 거죠.

syntax-case는 기본적으로 컴파일 타임에 실행되고 #' 내부에 있는 요소들이 런타임에 실행되는 반면,

syntax-rules는 컴파일 타임(phase 1)에 변환만 일어나고 런타임(phase 0)때 실행됩니다.

즉, syntax-case는 컴파일 타임에 Syntax 객체의 메타데이터 활용, 입력값 검증이나 조건부처리, 각종 계산 평가들을 할 수 있는 능력을 갖춘 반면, syntax-rules는 런타임에 처리해야 하는거죠.

syntax-case를 잘 활용할 수 있는 예를 하나 더 봅시다.

다음은 입력값 유효성을 컴파일타임에 검증하여 에러를 발생시킵니다.

(define-syntax (simple-op stx)
  (syntax-case stx ()
    [(_ op a b)
     (and (number? (syntax->datum #'a)) (number? (syntax->datum #'b)))
     (case (syntax->datum #'op)
       [(add) #'(+ a b)]
       [(sub) #'(- a b)]
       [(mul) #'(* a b)]
       [(div) (if (= 0 (syntax->datum #'b))
                  (raise-syntax-error 'simple-op "0으로 나눌 수 없습니다" #'b)
                  #'(/ a b))]
       [else (raise-syntax-error  'simple-op "지원하지 않는 연산자" #'op)])]
    [(_ op a b) (raise-syntax-error 'simple-op "숫자만 연산이 가능합니다" stx)]))

;; 사용
(simple-op add 1 2) ;; 결과: 3
(simple-op sub 1 2) ;; 결과: -1
(simple-op mul 1 2) ;; 결과: 2
(simple-op div 1 2) ;; 결과: 0.5
(simple-op div 1 0) ;; 에러: 0으로 나눌 수 없음
(simple-op div 1 "abc") ;; 에러: 숫자만 연산이 가능
(simple-op other 1 2) ;; 에러: 지원하지 않는 연산자

역시 번잡해 보인다는 생각을 지울 수 없습니다.

바로 add, sub를 다루거나 타입을 검증하는 등 더 복잡한 패턴매칭이 가능할까요?

다행히 syntax/parse라는 내장 라이브러리를 이용하면 가능합니다.

;; syntax/parse라는 라이브러리 사용 - 매크로를 import할 경우 for-syntax를 붙여줘야 한다
(require (for-syntax syntax/parse))

(define-syntax (simple-op stx)
  (syntax-parse stx
    [(_ (~literal add) a:number b:number) #'(+ a b)]
    [(_ (~literal sub) a:number b:number) #'(- a b)]
    [(_ (~literal mul) a:number b:number) #'(* a b)]
    [(_ (~literal div) a:number b:number)
     (when (= (syntax->datum #'b) 0)
       (raise-syntax-error 'simple-op "0으로 나눌 수 없습니다" #'b))
     #'(/ a b)]
    [(_ op:id a:number b:number)
     (raise-syntax-error 'simple-op "지원하지 않는 연산자입니다" #'op)]))

한층 Rust의 macro_rules!와 더 가까워졌죠?

body:expr 과 같이 익숙한 패턴도 쓸 수 있습니다.

1.2.6 함수와 변수를 정의하는 매크로

지금까지 Racket 매크로의 강점을 알아보고, 튜토리얼을 해보았습니다.

마지막으로 더 많은 활용을 위해 매크로에서 함수를 정의해봅시다.

저희가 만들어볼 것은 define-struct라 하여 구조체 관련 함수를 만들어주는 매크로입니다.

(define-struct posn (x y))

;; 사용
(define p1 (make-posn 1 2))
(posn? p1)
(posn-y p1)

define-struct를 이용하여 구조체 모양을 정의하면 3가지 종류의 함수를 자동으로 생성합니다.

make-[이름]: 구조체 생성자
[이름]?: 구조체의 인스턴스인지 확인
[이름]-[필드]: 인스턴스의 필드값을 반환

구현한 매크로는 조금 어려워 보이겠지만ㅠㅠ 다음과 같습니다.

여기에서 format-id는 컴파일 타임에 실행되어야 하는 함수이기 때문에 begin-for-syntax로 컴파일 타임에 실행 가능하도록 만들어두었어요.

구조체의 구조는 심플하게 '(구조체_이름 arg1 arg2) 와 같은 리스트로 생성 (실제 Racket struct와는 다르겠지만요)
술어 함수는 car로 구조체 이름이 같은지 체크
접근자 함수는 arg이름과 index에 따라 list-ref로 참조함

(require (for-syntax syntax/parse))

(begin-for-syntax
  (define (format-id stx format-str . base-ids)
    (datum->syntax stx
      (string->symbol
        (apply format format-str
          (map syntax->datum base-ids))))))

(define-syntax (my-define-struct stx)
  (syntax-parse stx
    [(_ name:id (field:id ...))
     #`(begin
         ; 생성자 함수 정의
         (define (#,(format-id stx "make-~a" #'name) field ...)
           (cons 'name (list field ...)))
 
         ; 술어 함수 정의
         (define (#,(format-id stx "~a?" #'name) x)
           (and (list? x) 
                (not (empty? x)) 
                (eq? (car x) 'name)))

         ; 접근자 함수들 정의
         #,@(for/list ([f (syntax->list #'(field ...))]
                       [i (in-naturals)])
             #`(define (#,(format-id stx "~a-~a" #'name f) x)
                 (list-ref (cdr x) #,i))))]))

;; 사용
(my-define-struct person (name age))
(define p1 (make-person "이름" 20)) ; '(person "이름" 20) 처럼 저장
(person? p1)         ; #true
(person-name p1)     ; "이름"
(person-age p1)      ; 20

성공적으로 만들어진것을 확인했습니다.

본문에 직접 바인딩 되는게 불만이라면 앞서 나오는 with-syntax를 활용하면 되요.

(define-syntax (my-define-struct stx)
  (syntax-parse stx
    [(_ name:id (field:id ...))
     (with-syntax ([fields (syntax->list #'(field ...))]
                   [constructor (format-id stx "make-~a" #'name)]
                   [predicate (format-id stx "~a?" #'name)]
                   [(accessor ...) (for/list ([f (syntax->list #'(field ...))])
                                   (format-id stx "~a-~a" #'name f))]
                   [(index ...) (for/list ([i (in-range (length (syntax->list #'(field ...))))])
                                #`#,i)])
       #'(begin
           ; 생성자 함수 정의
           (define (constructor field ...)
             (cons 'name (list field ...)))
           
           ; 술어 함수 정의
           (define (predicate x)
             (and (list? x)
                  (not (empty? x))
                  (eq? (car x) 'name)))
           
           ; 접근자 함수들 정의
           (define (accessor x)
             (list-ref (cdr x) index)) ...))]))

또는 syntax-parse에서 제공하는 #:with 를 사용해 블럭을 한단계 줄이는 것도 방법입니다.

(define-syntax (my-define-struct stx)
  (syntax-parse stx
    [(_ name:id (field:id ...))
     #:with constructor (format-id stx "make-~a" #'name)
     #:with predicate (format-id stx "~a?" #'name)

     #:with fields (syntax->list #'(field ...))
     #:with (accessor ...) (for/list ([f (attribute fields)])
                            (format-id stx "~a-~a" #'name f))
     #:with (index ...) (for/list ([i (in-range (length (attribute fields)))])
                         #`#,i)
     #'(begin
         ; 생성자 함수 정의
         (define (constructor field ...)
           (cons 'name (list field ...)))
         
         ; 술어 함수 정의
         (define (predicate x)
           (and (list? x)
                (not (empty? x))
                (eq? (car x) 'name)))
         
         ; 접근자 함수들 정의
         (define (accessor x)
           (list-ref (cdr x) index)) ...)]))

마지막에는 난이도가 좀 있었지만, 접근자처럼 복잡한 대상을 구현해서 그렇습니다. 일반적인 경우는 쉽게 만들 수 있죠.

이제 강력하고 안전한 Racket 매크로의 멋짐을 다들 알아주셨으면 하면서 매크로 파트를 마치겠습니다 ㅎㅎ

2. Racket - Thread와 함께하는 동적바인딩

2.1 동적 바인딩이란?

일전에 lexical scope에서 다루었지만, 다시 한번 살펴봅시다.

https://black7375.tistory.com/62

내 맘대로 프로그램 설계 7. - 함수형 프로그래밍.

내 맘대로 하는 프로그램 설계 시리즈. Chapter1 - 간단한 데이터 처리(4섹션) 2017/12/27 - [프로그래밍/설계] - 내 맘대로 프로그램 설계 1. - 이유와 준비. 2018/01/11 - [프로그래밍/설계] - 내 맘대로 프로

black7375.tistory.com

다음은 Emacs Lisp의 코드입니다.

setq는 전역변수, defun은 함수정의, let은 앞서 보았던 지역변수라고 할때 최종적으로 출력되는 값은 무엇일까요?

(setq sample-var 5)
(defun sample-print ()
  (print sample-var))
(let ((sample-var 8))
  (sample-print))

정답은 환경에 따라 다르다..이다.

lexical scope: 컴파일 타임에 결정이 나므로, 5가 출력
dynamic scope: 런타임에 결정이 나므로, 8이 출력

물론 정답을 굳이 고르자면, Emacs Lisp는 dynamic scope를 기본적으로 사용하므로 8이 출력됩니다.

경험을 해보고 싶다면 lexical-binding에 대한 기본값을 조절할 수 있으므로 쉽게 테스트할 수 있을 것 입니다.

(setq lexical-binding t) ;; 활성화
(setq lexical-binding nil) ;; 비활성화

이맥스에서는 보통은 파일단위로 lexical scope를 활성화해서 사용하는 편입니다.

다음을 첫번째 라인에 두면 해당 파일은 lexical binding을 사용하는 식.

;;; -*- lexical-binding: t -*-

실제로 Doom Emacs라던가 다양한 설정파일, 그리고 패키지들을 보면 lexical binding을 사용하기 위해 첫 라인에 두는 것을 볼 수 있어요.

2.2 왜 동적 바인딩인가?

동적 바인딩 나쁜거 아닌가요?

라고 물을 수 있습니다.

실제로 알려진것처럼 기본값으로 동적바인딩이 안좋습니다.

그렇다면 왜 고전적인 Lisp들은 동적 바인딩을 사용하고 있을까요?

말 그대로 역사적인 이유 때문입니다.

실제로 John McCarthy가 50년대에 Alonzo Church의 람다 계산을 이해하지 못했기 때문에 어휘 범위 대신 동적 범위를 구현했다는 것입니다. 그리고 elisp가 만들어지고 나서야 어휘 범위가 Lisp 세계의 표준이 되었습니다. . GNU Emacs가 개발되면서 동적 범위에는 Emacs와 같은 프로그램에 대한 몇 가지 유용한 속성이 있다는 것이 밝혀졌습니다. 비록 대부분의 경우 그것이 잘못된 것이기 때문에 멈춰 있었습니다.

그래도 몇가지 경우에는 동적바인딩이 유용하게 문제를 해결할 수 있습니다.

기본값으로 나쁠뿐이지, 의도적으로 특정 케이스들을 위해서는 유용합니다.

2.2.1 전역변수: 불필요한 전역 오염을 방지

전역 변수는 모든 코드에서 접근 가능해 예측하지 못한 수정 위험이 존재합니다.

따라서 여러 모듈이 동일한 전역 변수를 사용하면 충돌 가능성이 높으며, 비슷한 이유로 싱글톤 패턴이 안티패턴으로 분류되곤 하지요.

하지만 동적 바인딩을 사용하면,

변수의 생명주기가 실행 컨텍스트에 한정
명시적인 범위 내에서만 변수 접근 가능
실행 종료 후 자동으로 정리됨

특성을 가지기 때문에 보다 명시적이고, 안전하게 사용할 수 있습니다.

예를 들어 Javascript라 할때, 다음과 같이 전역 변수를 활용하는 테스트코드는 복원등의 실수를 유발하기 쉽습니다.

let baseUrl = "https://api.production.com";

async function getUser(id) {
  const result = await fetch(`${baseUrl}/user/${id}`);
  return await result.json();
}

describe("테스트", () => {
  const bakupUrl = baseUrl;
  beforeEach(() => {
    baseUrl = "https://api.test.com";
  });
  afterEach(() => {
    baseUrl = backupUrl;
  });

  test("테스트유져 확인", async () => {
    const user1 = await getUser(1);
    expect(user1.name).toBe("test 유저1");
  });
  // ...
});

만약 let 키워드가 블럭 단위의 동적 바인딩을 제공한다고 가정해봅시다.

그렇다면 beforeEach나 afterEach와 같은 것을 사용하지 않아도 자동적으로 복원이 가능합니다.

let baseUrl = "https://api.production.com";

async function getUser(id) {
  const result = await fetch(`${baseUrl}/user/${id}`);
  return await result.json();
}

describe("테스트", () => {
  let baseUrl = "https://api.test.com";

  test("테스트유져 확인", async () => {
    const user1 = await getUser(1);
    expect(user1.name).toBe("test 유저1");
  });
  // ...
});

let이 거부감이 느껴진다면 with문과 해당 블럭이 동적 바인딩을 제공한다고 가정해보자. (키워드가 겹침은 무시합시다)

let baseUrl = "https://api.production.com";

async function getUser(id) {
  const result = await fetch(`${baseUrl}/user/${id}`);
  return await result.json();
}

describe("테스트", () => {
  with(baseUrl as "https://api.test.com") {
    test("테스트유져 확인", async () => {
      const user1 = await getUser(1);
      expect(user1.name).toBe("test 유저1");
    });
    // ...
  }
});

또 다른 예로 로깅의 컨텍스트에 DEBUG, INFO, WARNING, ERROR, CRITICAL과 같은 로그 레벨을 제공해주는 것도 좋은 생각아닐까.

결론적으로 동적 바인딩은 전역변수의 오염을 방지해주는 좋은 방법입니다.

2.2.2 컨텍스트: 불필요한 매개변수 제거

동적 바인딩이 유용한 두번째 경우는 불필요한 context 매개변수를 계속 전해줘야하거나, 이를 극복하기 위한 라이브러리 차원의 노력이 있습니다.

아마 프론트 개발자들에게는 익숙한 개념일 것 입니다.

Context를 사용해 데이터를 깊게 전달하기

하위 컴포넌트까지 전달하려면?

여기서는 리엑트의 예제를 변형하여, 예외처리 없이 최대한 간단하게 만들어진 코드를 이해해보도록 합시다.

목표는 다음 코드를 간단하게 만들어보기.

function Page() {
  return (
    <Section>
      <Heading level={1}>Title</Heading>
      <Section>
        <Heading level={2}>Heading</Heading>
        <Heading level={2}>Heading</Heading>
        <Heading level={2}>Heading</Heading>
        <Section>
          <Heading level={3}>Sub-heading</Heading>
          <Heading level={3}>Sub-heading</Heading>
          <Heading level={3}>Sub-heading</Heading>
          <Section>
            <Heading level={4}>Sub-sub-heading</Heading>
            <Heading level={4}>Sub-sub-heading</Heading>
            <Heading level={4}>Sub-sub-heading</Heading>
          </Section>
        </Section>
      </Section>
    </Section>
  );
}

function Section({ children }) {
  return (
    <section className="section">
      {children}
    </section>
  );
}

function Heading({ level, children }) {
  const SizedHeader = `h${ level }`;
  return <SizedHeader>{children}</SizedHeader>;
}

Heading에 넘겨주는 level 값에 따라 크기가 달라지며, 섹션이 한단계 증가할 수록 level의 값이 커지는 것을 확인할 수 있습니다.

어떻게 하면 깔끔하게 만들 수 있을까요?

리엑트에서 정답은 createContext와 useContext를 사용하는 것입니다.

import { createContext, useContext } from "react";

function Page() {
  return (
    <Section>
      <Heading>Title</Heading>
      <Section>
        <Heading>Heading</Heading>
        <Heading>Heading</Heading>
        <Heading>Heading</Heading>
        <Section>
          <Heading>Sub-heading</Heading>
          <Heading>Sub-heading</Heading>
          <Heading>Sub-heading</Heading>
          <Section>
            <Heading>Sub-sub-heading</Heading>
            <Heading>Sub-sub-heading</Heading>
            <Heading>Sub-sub-heading</Heading>
          </Section>
        </Section>
      </Section>
    </Section>
  );
}

const LevelContext = createContext(0);

function Section({ children }) {
  const level = useContext(LevelContext);
  return (
    <section className="section">
      <LevelContext.Provider value={level + 1}>
        {children}
      </LevelContext.Provider>
    </section>
  );
}

function Heading({ children }) {
  const level = useContext(LevelContext);
  const SizedHeader = `h${ level }`;
  return <SizedHeader>{children}</SizedHeader>;
}

context 덕분에 매우 깔끔하게 구현해집니다.

앞서 보았던 동적 바인딩의 속성과 매우 유사하죠?

변수의 생명주기가 실행 컨텍스트에 한정
명시적인 범위 내에서만 변수 접근 가능
실행 종료 후 자동으로 정리됨

Context 변화에 따른 re-render를 요구하는 것 빼고는 사실상 동적 스코프와 거의 같다시피 합니다.

언어 차원에서 동적 스코프를 제공했다면, React 팀이나 기타 프레임워크들에서 해야할 일이 많이 줄어들어들 겁니다.

한가지 유용한 예제를 더 살펴봅시다.

방금전에는 최상위에 flat하게 정의되어 있기 좋은 예제를 사용했지만,

테마처럼 때에 따라서 특정한 값을 계속 하위 컴포넌트로 넘겨주어야 할 수도 있습니다.

import { useState } from "react";

const themes = {
  light: {
    background: "#ffffff",
    text: "#000000",
    primary: "#007bff"
  },
  dark: {
    background: "#222222",
    text: "#ffffff",
    primary: "#0056b3"
  }
};

function App() {
  const [currentTheme, setCurrentTheme] = useState("light");

  const toggleTheme = () => {
    setCurrentTheme(prevTheme => prevTheme === "light" ? "dark" : "light");
  };

  return (
    <div>
      <h1>테마 예제</h1>
      <ParentComponent
        theme={themes[currentTheme]}
        toggleTheme={toggleTheme}
        currentTheme={currentTheme}
      />
    </div>
  );
}

function ParentComponent({ theme, toggleTheme, currentTheme }) {
  return (
    <div>
      <ChildComponent
        theme={theme}
        toggleTheme={toggleTheme}
        currentTheme={currentTheme}
      />
      <AnotherChildComponent
        theme={theme}
        toggleTheme={toggleTheme}
        currentTheme={currentTheme}
      />
    </div>
  );
}

function ChildComponent({ theme, toggleTheme, currentTheme }) {
  return (
    <div style={{
      background: theme.background,
      color: theme.text,
      padding: "20px",
      transition: "all 0.3s ease"
    }}>
      <h2>현재 테마: {currentTheme}</h2>
      <button 
        onClick={toggleTheme}
        style={{
          background: theme.primary,
          color: theme.text,
          padding: "10px 20px",
          borderRadius: "5px"
        }}
      >
        테마 변경
      </button>
      <p>이것은 테마가 적용된 컴포넌트입니다.</p>
    </div>
  );
}

function AnotherChildComponent({ theme }) {
  return (
    <div style={{
      background: theme.background,
      color: theme.text,
      padding: "20px",
      marginTop: "10px"
    }}>
      <p>다른 자식 컴포넌트</p>
    </div>
  );
}

이럴때 context를 사용하면 자연스럽게 개선을 할 수 있습니다.

// == 테마 제공 ===================================================================
import { createContext, useState, useContext } from "react";

// 테마 정의
const themes = {
  light: {
    background: "#ffffff",
    text: "#000000",
    primary: "#007bff"
  },
  dark: {
    background: "#222222",
    text: "#ffffff",
    primary: "#0056b3"
  }
};

// Context 생성
const ThemeContext = createContext();

// Provider 컴포넌트
function ThemeProvider({ children }) {
  const [theme, setTheme] = useState("light");

  const toggleTheme = () => {
    setTheme(prevTheme => prevTheme === "light" ? "dark" : "light");
  };

  const value = {
    theme: themes[theme],
    toggleTheme,
    currentTheme: theme
  };

  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

// 커스텀 훅
function useTheme() {
  const context = useContext(ThemeContext);
  if (context === undefined) {
    throw new Error("useTheme must be used within a ThemeProvider");
  }
  return context;
}

// == 테마 사용 ===================================================================
function App() {
  return (
    <ThemeProvider>
      <div>
        <h1>테마 예제</h1>
        <ParentComponent />
      </div>
    </ThemeProvider>
  );
}

function ParentComponent() {
  return (
    <ChildComponent />
    <AnotherChildComponent />
  );
}

function ChildComponent() {
  const { theme, toggleTheme, currentTheme } = useTheme();

  return (
    <div style={{
      background: theme.background,
      color: theme.text,
      padding: "20px",
      transition: "all 0.3s ease"
    }}>
      <h2>현재 테마: {currentTheme}</h2>
      <button 
        onClick={toggleTheme}
        style={{
          background: theme.primary,
          color: theme.text,
          padding: "10px 20px",
          borderRadius: "5px"
        }}
      >
        테마 변경
      </button>
      <p>이것은 테마가 적용된 컴포넌트입니다.</p>
    </div>
  );
}

function AnotherChildComponent() {
  const { theme } = useTheme();

  return (
    <div style={{
      background: theme.background,
      color: theme.text,
      padding: "20px",
      marginTop: "10px"
    }}>
      <p>다른 자식 컴포넌트</p>
    </div>
  );
}

자, 그렇다면 프론트에만 유용할까요?

첫번째 View 함수 인자로 HttpRequest를 전달하는 Django와 달리 Flask는 Request Context를 통해 각 요청을 처리하며,

옛날에는 자체적으로 구현되어 있었으나 최신에는 Python 3.7에 도입된 contextvars를 이용해 구현되어 있습니다.

from flask import Flask, request, g
from flask import current_app

app = Flask(__name__)

# 요청 전에 실행되는 before_request 함수
@app.before_request
def before_request_func():
    g.user = None  # g 객체에 사용자 정보 저장
    if "user_id" in request.headers:
        g.user = request.headers["user_id"]

# 기본 라우트
@app.route("/")
def index():
    # request 객체 사용
    user_agent = request.headers.get("User-Agent")
    # g 객체 사용
    current_user = g.user or "Anonymous"
    return f"Hello {current_user}! Your browser is: {user_agent}"

# request context를 수동으로 사용하는 예제
def process_request_outside_context():
    with app.test_request_context("/hello", method="POST"):
        # 이제 request context 내부입니다
        assert request.path == "/hello"
        assert request.method == "POST"
        
        # current_app 접근 가능
        assert current_app.name == "app"

contextvars는 저도 FastAPI와 SQLModel 환경 구축을 위해 transactional을 구현하는 도중 사용한 경험이 있는데,

NDA 때문에 직접적인 코드를 보여주지는 못하지만, How to implement a transactional decorator in FastAPI + SQLAlchemy라는 글과 유사하게 구현했었고 비동기시 상태공유에서 무척 좋은 방법이었습니다.

전통적인 언어에서는 그럼 어떻게 처리했느냐.

위의 Django처럼 첫번째 인자로 context를 넘기는 방향으로 처리해왔습니다.

// SQLite
// https://www.sqlite.org/c3ref/prepare.html
int sqlite3_prepare_v2(
    sqlite3 *db,            /* Database handle */
    const char *zSql,       /* SQL statement, UTF-8 encoded */
    int nByte,              /* Maximum length of zSql in bytes. */
    sqlite3_stmt **ppStmt,  /* OUT: Statement handle */
    const char **pzTail     /* OUT: Pointer to unused portion of zSql */
);

// libcurl
// https://curl.se/libcurl/c/curl_easy_setopt.html
CURLcode curl_easy_setopt(
  CURL *handle, // context
  CURLoption option,
  parameter
);

// FFmpeg
// https://ffmpeg.org/doxygen/6.1/group__lavc__decoding.html
int avcodec_default_get_buffer2(
  AVCodecContext *s,
  AVFrame *frame,
  int flags
);

이 전통에 따라 Go도 context를 사용할때 첫번째 인자는 항상 context를 넘기도록 되어있습니다.

Go Concurrency Patterns: Context

Go는 에러처리에서도 명시적으로 처리하기 좋아하는 언어라서 그렇다쳐도

일반적인 언어들은 다이나믹 바인딩을 구현하는게 더 좋지 않을까요?

불필요한 매개변수를 제거하고, 비동기 처리시 상태공유를 하기 좋은 방법이다.

2.2.3 의존성 주입: 보일러 플레이트 제거

의존성 주입은 보일러 플레이트가 많기로 유명합니다.

그러나 개념 자체는 생각보다 간단하며, DI 프레임워크들 그리고 언어 자체가 장황한 Java의 문제가 크지 않을까..

예를 들어 Android의 DI예제를 살펴보면 Kotlin과 Java의 차이는 상당합니다.

모두 합쳐 코틀린이 43라인인 반면 자바는 59라인입니다(약 1.4배).

DI 전과 후: 결합도가 줄어들었다

코틀린:

// DI 적용 전
class Car {
    private val engine = Engine()

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.start()
}


// 생성자 삽입 DI
class Car(private val engine: Engine) {
    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val engine = Engine()
    val car = Car(engine)
    car.start()
}


// 필드 삽입 DI
class Car {
    lateinit var engine: Engine

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.engine = Engine()
    car.start()
}

자바:

// DI 적용 전
class Car {
    private Engine engine = new Engine();

    public void start() {
        engine.start();
    }
}

class MyApp {
    public static void main(String[] args) {
        Car car = new Car();
        car.start();
    }
}


// 생성자 삽입 DI
class Car {
    private final Engine engine;

    public Car(Engine engine) {
        this.engine = engine;
    }

    public void start() {
        engine.start();
    }
}

class MyApp {
    public static void main(String[] args) {
        Engine engine = new Engine();
        Car car = new Car(engine);
        car.start();
    }
}


// 필드 삽입 DI
class Car {
    private Engine engine;

    public void setEngine(Engine engine) {
        this.engine = engine;
    }

    public void start() {
        engine.start();
    }
}

class MyApp {
    public static void main(String[] args) {
        Car car = new Car();
        car.setEngine(new Engine());
        car.start();
    }
}

예제로 본 DI 개념 자체는 무척이나 간단한게, 외부에서 생성자나 필드로 값을 주입해 제어를 역전하기 입니다.

그러나 프레임워크를 거치며 처음본 사람이라면 다소 어려워집니다.

여기서는 Dagger라는 프레임워크를 기준으로 설명하고자 합니다.

import javax.inject.Inject
import dagger.Component
import dagger.Module
import dagger.Provides

// 생성자 주입
// 1. 의존성이 필요한 클래스 (@Inject)
class Car @Inject constructor(private val engine: Engine) {
    fun start() {
        engine.start()
    }
}

// 2. 의존성을 제공하는 모듈 (@Module)
@Module
class EngineModule {
    @Provides
    fun provideEngine() = Engine()
}

// 3. 둘을 연결하는 컴포넌트 (@Component)
@Component(modules = [EngineModule::class])
interface CarComponent {
    fun getCar(): Car
}

// 실제 사용
// @Component 사용으로, 앞에 Dagger가 붙은 DaggerCarComponent가 자동생성됨
fun main() {
    val carComponent = DaggerCarComponent.create()
    val car = carComponent.getCar()
    car.start()
}

눈에 띄는 것은 의존성을 제공하고 연결하는 @Module, @Component이며

이로인해 사용하는 곳에서는 별다른 인자없이,

DaggerCarComponent.create()로 의존성 주입 관리자 생성
carComponent.getCar()로 객체 생성과 의존성 주입

로 사용가능하다는 것입니다.

필드 삽입 DI의 예까지만 보고 DI 프레임워크를 사용했을때 장점을 알아봅시다.

// 필드 주입
// 1. 의존성이 필요한 클래스 (@Inject)
class Car {
    @Inject
    lateinit var engine: Engine

    fun start() {
        engine.start()
    }
}

// 2. 의존성을 제공하는 모듈 (@Module)
@Module
class CarModule {
    @Provides
    fun provideEngine() = Engine()
}

// 3. 둘을 연결하는 컴포넌트 (@Component)
@Component(modules = [CarModule::class])
interface CarComponent {
    fun inject(car: Car)
}

// 실제 사용
// @Component 사용으로, 앞에 Dagger가 붙은 DaggerCarComponent가 자동생성됨
fun main() {
    val car = Car()
    val carComponent = DaggerCarComponent.create()
    carComponent.inject(car)
    car.start()
}

만약 의존성 구성이 복잡하다고 가정해봅시다.

예를 들어 엔진을 구성할때 FuelInjector, EngineSensor, EngineLogger가 필요할테다.

그리고 바퀴는 4개가 있어야 하며 역시 센서가 있을수도 있습니다.

이런 하위의존성은 어떻게 처리할 수 있을까요?

// 1. 센서 및 모니터링 인터페이스 구현
interface EngineSensor {
    fun getCurrentStatus(): EngineStatus
    fun getTemperature(): Float
}

class EngineTemperatureSensor @Inject constructor() : EngineSensor {
    override fun getCurrentStatus(): EngineStatus = EngineStatus.RUNNING
    override fun getTemperature(): Float = 90.0f
}

interface TirePressureSensor {
    fun getCurrentPressure(): Float
}

class StandardTirePressureSensor @Inject constructor() : TirePressureSensor {
    override fun getCurrentPressure(): Float = 32.0f
}

interface EngineLogger {
    fun log(message: String)
}

class ConsoleEngineLogger @Inject constructor() : EngineLogger {
    override fun log(message: String) {
        println("Engine: $message")
    }
}

interface CarMonitor {
    fun logEvent(event: CarEvent)
}

class ConsoleCarMonitor @Inject constructor() : CarMonitor {
    override fun logEvent(event: CarEvent) {
        println("Car Event: $event")
    }
}

// 2. FuelInjector 구현
class FuelInjector @Inject constructor() {
    fun inject() {
        println("Fuel injected")
    }
    
    fun stop() {
        println("Fuel injection stopped")
    }
}

// 3. 핵심 컴포넌트 구현
interface Engine {
    fun start()
    fun stop()
    fun getStatus(): EngineStatus
    fun getTemperature(): Float
}

class GasolineEngine @Inject constructor(
    private val fuelInjector: FuelInjector,
    private val engineSensor: EngineSensor,
    private val engineLogger: EngineLogger
) : Engine {
    override fun start() {
        fuelInjector.inject()
        engineLogger.log("Engine started")
    }
    
    override fun stop() {
        fuelInjector.stop()
        engineLogger.log("Engine stopped")
    }
    
    override fun getStatus(): EngineStatus = engineSensor.getCurrentStatus()
    override fun getTemperature(): Float = engineSensor.getTemperature()
}

interface Wheel {
    fun getPressure(): Float
    fun checkCondition(): WheelCondition
}

class StandardWheel @Inject constructor(
    private val tirePressureSensor: TirePressureSensor
) : Wheel {

    override fun getPressure(): Float = tirePressureSensor.getCurrentPressure()
    override fun checkCondition(): WheelCondition = WheelCondition.GOOD
}

// 4. Car 구현
interface Car {
    fun start()
    fun stop()
    fun drive()
    fun getStatus(): CarStatus
}

class StandardCar @Inject constructor(
    private val engine: Engine,
    @Named("wheels") private val wheels: List<Wheel>,
    private val carMonitor: CarMonitor
) : Car {
    override fun start() {
        engine.start()
        carMonitor.logEvent(CarEvent.START)
    }
    
    override fun stop() {
        engine.stop()
        carMonitor.logEvent(CarEvent.STOP)
    }
    
    override fun drive() {
        if (engine.getStatus() == EngineStatus.RUNNING) {
            wheels.forEach { it.rotate() }
            carMonitor.logEvent(CarEvent.DRIVING)
        }
    }
    
    override fun getStatus(): CarStatus = CarStatus(
        engineStatus = engine.getStatus(),
        engineTemperature = engine.getTemperature(),
        wheelsPressure = wheels.map { it.getPressure() }
    )
}

// 5. 데이터 클래스 및 열거형
data class CarStatus(
    val engineStatus: EngineStatus,
    val engineTemperature: Float,
    val wheelsPressure: List<Float>
)

enum class EngineStatus {
    STOPPED, RUNNING, ERROR
}

enum class WheelCondition {
    GOOD, WORN, CRITICAL
}

enum class CarEvent {
    START, STOP, DRIVING
}

// 6. Dagger 모듈 및 컴포넌트
@Module
class CarModule {
    @Provides
    fun provideEngineSensor(sensor: EngineTemperatureSensor): EngineSensor = sensor

    @Provides
    fun provideTirePressureSensor(sensor: StandardTirePressureSensor): TirePressureSensor = sensor

    @Provides
    fun provideEngineLogger(logger: ConsoleEngineLogger): EngineLogger = logger

    @Provides
    fun provideCarMonitor(monitor: ConsoleCarMonitor): CarMonitor = monitor

    @Provides
    fun provideEngine(engine: GasolineEngine): Engine = engine

    @Provides
    @Named("wheels")
    fun provideWheels(
        tirePressureSensor: Provider<TirePressureSensor>,
    ): List<Wheel> = List(4) { 
        StandardWheel(tirePressureSensor.get())
    }

    @Provides
    fun provideCar(car: StandardCar): Car = car
}

@Component(modules = [CarModule::class])
interface CarComponent {
    fun getCar(): Car
}

// 7. 실제 사용
fun main() {
    val carComponent = DaggerCarComponent.create()
    val car = carComponent.getCar()
    
    car.start()
    car.drive()
    println(car.getStatus())
    car.stop()
}

@Module에서 의존성 제공을 모두 처리해주니 확실히 깔끔해보입니다.

dagger는 명시적인 의존성 그래프로 컴파일타임에 빠진 의존성에 대한 체크를 하고, 자동화된 의존성 주입을 가능하게 만들어줍니다.

방금은 의존하는 양이 많고 구조화가 필요할 때의 이야기였다면,

이번에는 더 많은 조건과 복잡성이 들어가면 어떻게 될까요?

예를 들어 가솔린 엔진, 전기 모터, 하이브리드를 골라서 사용이 필요하고 네트워크나 보안 모듈이 필요하다면 말입니다.

enum class EngineType {
    GASOLINE,
    ELECTRIC,
    HYBRID
}

@Module
class NetworkModule {
    @Provides
    @Singleton
    fun provideNetworkClient(): NetworkClient {
        return NetworkClientImpl()
    }
}

@Module
class CarModule(private val engineType: EngineType) {
    @Provides
    fun provideEngineSensor(sensor: EngineTemperatureSensor): EngineSensor = sensor

    @Provides
    fun provideTirePressureSensor(sensor: StandardTirePressureSensor): TirePressureSensor = sensor

    @Provides
    fun provideEngineLogger(logger: ConsoleEngineLogger): EngineLogger = logger

    @Provides
    fun provideCarMonitor(monitor: ConsoleCarMonitor): CarMonitor = monitor

    @Provides
    fun provideEngine(
        gasolineEngine: Provider<GasolineEngine>,
        electricEngine: Provider<ElectricEngine>,
        hybridEngine: Provider<HybridEngine>
    ): Engine {
        return when (engineType) {
            EngineType.GASOLINE -> gasolineEngine.get()
            EngineType.ELECTRIC -> electricEngine.get()
            EngineType.HYBRID -> hybridEngine.get()
        }
    }

    @Provides
    @Named("wheels")
    fun provideWheels(
        tirePressureSensor: Provider<TirePressureSensor>,
    ): List<Wheel> = List(4) { 
        StandardWheel(tirePressureSensor.get())
    }

    @Provides
    fun provideCar(car: StandardCar): Car = car
}

@Component(modules = [
    CarModule::class,
    NetworkModule::class,
    SecureModule::class
])
interface CarComponent {
    fun getCar(): Car

    @Component.Builder
    interface Builder {
        @BindsInstance
        fun carModule(carModule: CarModule): Builder
        fun networkModule(networkModule: NetworkModule): Builder
        fun build(): CarComponent
    }
}

fun main() {
    val carComponent = DaggerCarComponent.builder()
        .carModule(CarModule(EngineType.HYBRID))
        .networkModule(NetworkModule(baseUrl = "https://car-api.example.com"))
        .build()

    val car = carComponent.getCar()
    
    car.start()
    car.drive()
    println(car.getStatus())
    car.stop()
}

살짝 더 복잡해 보이긴 하지만..

의존성이 복잡하게 얽혀있고, 이런저런 커스텀이 필요할때 DI 프레임워크를 사용하면 도움이 되리란 것을 체감할 수 있습니다.

이 글을 읽는 여러분은 지금쯤 "그래서 동적 바인딩과는 대체 무슨 상관이지?" 라는 생각이 스물스물 올라오고 있을테지요.

DI 프레임워크의 필요성만 설파할 뿐이지, 동적 바인딩에 대해서는 언급하지 않았으니까 말입니다.

하지만 동적 바인딩의 대체가능성을 탐색하기 위해 어떠한 기능이 필요한가를 탐색하기 위해 중요한 과정이었습니다.

본격적으로 들어가기 앞서 코틀린에 동적 바인딩이 들어간다면 어떤 모습일지에 대해 가정하고 넘어갑시다.

DynamicParameter로 초기값을 산정
currentLogLevel로 참조
withDynamicScope로 블록 내부에서 얻어지는 값이 바뀌게끔함

val currentLogLevel = DynamicParameter<LogLevel>(LogLevel.INFO)

fun log(level: LogLevel, msg: String) {
    if (level.priority >= currentLogLevel.priority) {
        println("[$level] $msg")
    }
}

fun main() {
    log(LogLevel.DEBUG, "Debug message") // 출력 안됨
    
    withDynamicScope(currentLogLevel to LogLevel.DEBUG) {
        log(LogLevel.DEBUG, "Debug message") // 출력됨
    }
}

동적 바인딩을 사용하자는게 이상하다 느껴질 수도 있겠지만 다행히 다른 사람도 주장한 흔적들이 있다.

앞선 Context도 일종의 의존성 주입이었죠.

Dynamic scoping is the simplest form of dependency injection

그럼 동적 바인딩을 사용할때로 포팅을 해봅시다.

단, 의존성 제공에만 집중해보자.

CarContext: @Module CarModule처럼 사용될 동적 변수들 모음
createCar: 의존성을 주입하여 제공

// 1. 사용될 Context 정의
object CarContext {
    val currentEngineSensor = DynamicParameter<EngineSensor>()
    val currentTirePressureSensor = DynamicParameter<TirePressureSensor>()
    val currentEngineLogger = DynamicParameter<EngineLogger>()
    val currentCarMonitor = DynamicParameter<CarMonitor>()
    val currentEngine = DynamicParameter<Engine>()
    val currentWheels = DynamicParameter<List<Wheel>>()
    val currentCar = DynamicParameter<Car>()
}

// 2. Context 사용
class GasolineEngine: Engine {
    private val fuelInjector: FuelInjector = FuelInjector()
    private val engineSensor: EngineSensor get() = CarContext.currentEngineSensor
    private val engineLogger: EngineLogger get() = CarContext.currentEngineLogger

    override fun start() {
        fuelInjector.inject()
        engineLogger.log("Engine started")
    }
    
    override fun stop() {
        fuelInjector.stop()
        engineLogger.log("Engine stopped")
    }
    
    override fun getStatus(): EngineStatus = engineSensor.getCurrentStatus()
    override fun getTemperature(): Float = engineSensor.getTemperature()
}

class StandardWheel: Wheel {
    private val tirePressureSensor: TirePressureSensor get() = CarContext.currentTirePressureSensor

    override fun getPressure(): Float = tirePressureSensor.getCurrentPressure()
    override fun checkCondition(): WheelCondition = WheelCondition.GOOD
}

class StandardCar : Car {
    private val engine: Engine  get() = CarContext.currentEngine
    private val wheels: List<Wheel>  get() = CarContext.currentWheels
    private val carMonitor: CarMonitor  get() = CarContext.currentCarMonitor

    override fun start() {
        engine.start()
        carMonitor.logEvent(CarEvent.START)
    }
    
    override fun stop() {
        engine.stop()
        carMonitor.logEvent(CarEvent.STOP)
    }
    
    override fun drive() {
        if (engine.getStatus() == EngineStatus.RUNNING) {
            wheels.forEach { it.rotate() }
            carMonitor.logEvent(CarEvent.DRIVING)
        }
    }
    
    override fun getStatus(): CarStatus = CarStatus(
        engineStatus = engine.getStatus(),
        engineTemperature = engine.getTemperature(),
        wheelsPressure = wheels.map { it.getPressure() }
    )
}

// 3. Context 제공
fun createEngine(engineType: EngineType) {
    withDynamicScope(
        CarContext.currentEngineSensor to EngineTemperatureSensor(),
        CarContext.currentEngineLogger to ConsoleEngineLogger(),
        CarContext.currentEngine to when (engineType) {
            EngineType.GASOLINE -> GasolineEngine()
            EngineType.ELECTRIC -> ElectricEngine()
            EngineType.HYBRID -> HybridEngine()
        }
    ) {
        return CarContext.currentEngine
    }
}

fun createCar(
    engineType: EngineType,
    networkModule: NetworkModule,
) {
    withDynamicScope(
        CarContext.currentTirePressureSensor to StandardTirePressureSensor,
        CarContext.currentWheels to List(4) { StandardWheel() },
        CarContext.currentEngine to createEngine(engineType),
        CarContext.currentCar to StandardCar()
        NetworkContext.currentNetworkModule to networkModule,
        SecureContext.currentSecureModule to createSecure()
    ) {
        return CarContext.currentCar
    }
}

// 4. 실제 사용
fun main() {
    val car = createCar(
        engineType=EngineType.HYBRID,
        networkModule=createNetwork(baseUrl = "https://car-api.example.com")
    )

    car.start()
    car.drive()
    println(car.getStatus())
    car.stop()

    withDynamicScope(
        CarComponents.currentEngineSensor to MockEngineSensor(),
        CarComponents.currentCarMonitor to MockCarMonitor()
    ) {
        car.start()
        car.drive()
        println(car.getStatus())
        car.stop()
    }
}

분명 처음보는 문법임에도, Dagger를 사용했을때보다 간결해보입니다.

하지만 의심되는 부분이 있습니다. Dagger처럼 의존성이 제공이 컴파일 타임에 체크가 가능한가입니다.

컴파일타임에 의존성 체크만 성공적으로 이루어진다면 의존성을 제공하는 부분은 간결하게 createCar과 같은 함수만 만들면 되기 때문에 무척 쉬워지죠.

저에게 의존성이 제공되었음을 보장하는 두가지 방안이 있습니다.

첫번째.

컴파일러의 Null Safety의 확장으로서 생각하기.

함수를 호출하거나, 생성자를 호출하는 곳 기준 Null 안전성을 갖춰야 한다
- 함수 본문이나 클래스 정의에서는 의존성을 갖추었는지를 알 방법이 없으므로, 호출하는 곳이 기준점이어야 함
초기값을 모두 가지고 있다면 안전하게 함수나 생성자 호출 가능
withDynamicScope로 모든 동적 바인딩 변수나 프로퍼티가 제공되었다면 함수나 생성자 호출 가능

fun useCar() {
    // 동적 바인딩을 사용하는 함수 본문이나 클래스 프로퍼티에서는 알 수 없고,
    // 호출지점에서 Scope가 있는지 결정나므로 생성자가 실행되는 지점에서 에러체크
    val car1 = StandardCar() // 에러: currentEngine, currentWheels, currentCarMonitor의 초기값이 없음
 
    withDynamicScope(
        CarContext.currentTirePressureSensor to StandardTirePressureSensor,
        CarContext.currentEngineLogger to ConsoleEngineLogger(),
        CarContext.currentCarMonitor to ConsoleCarMonitor(),
        CarContext.currentEngine to GasolineEngine(),
        CarContext.currentWheels to List(4) { StandardWheel() },
    ) {
        val car2 = StandardCar() // 에러: GasolineEngine에서 사용되는 currentEngineSensor가 제공되지 않음
    }

    withDynamicScope(
        CarContext.currentEngineSensor to EngineTemperatureSensor(),
        CarContext.currentTirePressureSensor to StandardTirePressureSensor,
        CarContext.currentEngineLogger to ConsoleEngineLogger(),
        CarContext.currentCarMonitor to ConsoleCarMonitor(),
        CarContext.currentEngine to GasolineEngine(),
        CarContext.currentWheels to List(4) { StandardWheel() },
    ) {
        val car3 = StandardCar() // 성공
    }
}

두번째.

함께 제공하는 Context 묶음에 대해 Dagger처럼 의존성 그래프가 만족하는지 체크할 수 있습니다.

// 마치 Dagger의 @Module처럼 의존성이 모두 만족하는지 체크
@Context
object CarContext {
    val currentEngineSensor = DynamicParameter<EngineSensor>()
    val currentTirePressureSensor = DynamicParameter<TirePressureSensor>()
    val currentEngineLogger = DynamicParameter<EngineLogger>()
    val currentCarMonitor = DynamicParameter<CarMonitor>()
    val currentEngine = DynamicParameter<Engine>()
    val currentWheels = DynamicParameter<List<Wheel>>()
    val currentCar = DynamicParameter<Car>()
}

물론 복잡한 케이스에서 Bunshi나 Bunja와 같은 Scope관리는 추가로 필요할수도 있습니다.

2.3 Thread 안전한 동적 바인딩

Racket에는 fluid-let과 parameterize 두가지의 구현이 존재합니다.

fluid-let: 일반 변수를 동적 스코프처럼 쓸 수 있게 해줌
parameterize: make-parameter와 쌍으로 쓰이며, 쓰레드 안전함

;; fluid-let 예제
(define x 10)
(fluid-let ([x 20])
  (print x))  ; 20 출력
(print x)     ; 10 출력

;; parameterize 예제
(define current-x (make-parameter 10))
(parameterize ([current-x 20])
  (print (current-x)))  ; 20 출력
(print (current-x))     ; 10 출력

당연히(?) parameterize가 현재 Racket의 표준입니다.

저도 동적 스코프는 명시적으로 관리하는 것이 좋으며, 쓰레드 안전함을 위해서 동의하는 바 입니다.

좋다. 그럼 어떤 방식으로 만들어진걸까요?

Racket의 문서를 읽어보면 짐작할 수 있습니다.

쓰레드 및 컨티뉴에이션 친화적인 방식으로 코드를 매개변수화하려면 parameterize를 사용하세요. parameterize 형식은 본문 표현의 동적 범위를 위해 새로운 쓰레드 셀을 도입합니다.
새로운 쓰레드가 생성될 때, 새 쓰레드의 초기 컨티뉴에이션에 대한 매개변수화는 생성자 쓰레드의 매개변수화를 따릅니다. 각 매개변수의 쓰레드 셀이 보존되므로, 새 쓰레드는 이를 생성한 스레드의 매개변수 값들을 "상속"받게 됩니다. 컨티뉴에이션이 한 쓰레드에서 다른 쓰레드로 이동할 때, parameterize를 통해 도입된 설정들은 쓰레드과 함께 효과적으로 이동합니다.

Racket에는 Thread local storage의 프리미티브 형태인 쓰레드 셀(Thread cell)이 있음
새로운 쓰레드가 생기면 현재 매개변수 값들(make-parameter 값들)을 상속받음
컨티뉴에이션이 다른 쓰레드로 이동할때도 현재 매개변수 값들이 이동

보다 자세한 설명을 보고싶다면 다음 글들이 도움이 될 것이다.

언어적으로 다이나믹 바인딩을 지원하면 전역변수, 컨텍스트, DI등 다양한 방면에서 커다란 도움이 되는 해법이라 생각합니다.

사람들의 편견하에 지나치게 기피되고 있는 기능이 아닐까..

저는 명시적으로 다이나믹 바인딩을 위한 명시적인 플레이스홀더를 정의하고, Thread safe, 컴파일타임 의존성 체크가 가능하다면 분명 유용하게 쓰일수 있을거라 봅니다.

모든것을 함수의 인수로 명시적으로 넘기자는 주장도 있을 수 있지만, 더 이상 리엑트 hooks와 context처럼 쓰이는게 안티패턴은 아니잖아요?

3. Common Lisp - 유연하고 확장가능한 객체지향 시스템

* Common Lisp의 구현체는 다양하나, 이 글은 SBCL을 기준으로 하고 있습니다.

3.1 다양한 객체지향 구현

객체지향을 구현하는 방법에는 여러가지 방식들이 있습니다.

대표적인게 예전에도 언급했던 클래스와 프로토타입.

https://black7375.tistory.com/86

객체지향 시스템과 패러다임 그리고 철학

자바스크립트는 왜 프로토타입을 선택했을까 라는 글을 읽고 떠오르는 내용들을 덧붙이거나 정리 해보았습니다. 원글과는 접근법이 좀 다르며, 기획이 아닌 급하게 쓴 글이라 의식의 흐름 사이

black7375.tistory.com

이외에도 interface, trait, protocol, mixin 등의 개념이 객체지향 구현을 위해 쓰입니다.

각각의 미세한 차이는 이 글이 지나치게 길어질테니 간략한 차이만을 다루고, 추후 따로 다룰 수 있도록 하겠습니다. (언젠가?)

Interface: 구현해야 하는 메서드들의 명세
Trait: 메서드를 재사용할 수 있게 해주는 수평적 재사용 매커니즘 (메서드 명세와 메서드 기본 구현)
Protocol: 객체가 따라야하는 메서드와 프로퍼티를 정의하는 규약(프로퍼티와 메서드 명세, 메서드 기본 구현)
Mixin: 재사용 가능한 메서드와 프로퍼티을 정의하는 수평적 재사용(프로퍼티와 메서드 구현)
Class: 객체를 생성하기 위한 템플릿으로, 프로퍼티와 메서드를 캡슐화(Mixin과 달리 수직적 재사용인 상속 가능)
Prototype: 객체를 복제하여 새로운 객체를 생성하는 방식의 상속 방식
CLOS: 다중 디스패치와 메서드 조합을 지원하는 동적 객체 시스템

위에서 아래로 올수록 구체적이고, 동적인 객체지향 구현방법입니다.

그럼 CLOS(Common Lisp Object System)을 함께 살펴보도록 합시다.

3.2 유연한 메서드 시스템

3.2.1 확장 가능한 메서드: 클래스 정의를 수정하지 않고 추가

먼저 간단한 클래스를 만들어 봅시다.

;; 클래스 구조
(defclass 클래스명 (부모클래스들)
  ((슬롯명1
    :옵션키워드1 값1
    :옵션키워드2 값2
    ...)
   (슬롯명2
    :옵션키워드1 값1
    ...))
 
;; 옵션 키워드
:initarg      ; 초기화 시 사용할 키워드
:accessor     ; getter/setter 함수 자동 생성
:reader       ; getter 함수만 생성
:writer       ; setter 함수만 생성
:initform     ; 초기값 설정
:type         ; 타입 지정
:allocation   ; :class(클래스 변수) 또는 :instance(인스턴스 변수)

;; 메서드 구조
(defmethod 메소드이름 ((변수명 클래스명)) 
  ; 메서드 본문
)

실제로 써보면 그리 어렵지 않아요.

;; 클래스 정의
(defclass person ()
  ((name
    :initarg :name
    :accessor person-name)
   (age
    :initarg :age
    :accessor person-age)))

;; 메서드 정의 - 포맷 방식
;; ~A: (Aesthetic) 읽기 좋은 형태로 출력
;; ~D: (Decimal) 십진수로 출력
;; ~%: 줄바꿈
(defmethod display-info ((p person))
  (format t "이름: ~A, 나이: ~D~%" 
          (person-name p) 
          (person-age p)))

;; 사용
(let ((person1 (make-instance 'person :name "John" :age 20)))
  (display-info person1))

살펴보면 클래스가 정의된 이후에 메서드들을 계속 추가할 수 있는 형태죠?

저 이후에도 메서드를 추가할 수 있습니다.

(defmethod increase-age ((p person))
  (setf (person-age p) (+ 1 (person-age p))))

;; 다시 사용해보기
(let ((person1 (make-instance 'person :name "John" :age 20)))
  (display-info person1)
  (increase-age person1)
  (display-info person1))

클래스를 정의할 때만 메서드를 정의할 수 있는 Java, C++과 달리 그 이후 자유롭게 확장에 열려있다는 점은 큰 매력입니다.

3.2.2 다중 디스패치: 런타임 객체 타입에 따른 함수 사용

이번에는 다중 디스패치를 해봅시다.

;; 클래스 (Person 상속)
(defclass student (person)
  ((grade :initarg :grade :accessor student-grade)))

(defclass teacher (person)
  ((subject :initarg :subject :accessor teacher-subject)))

;; 제네릭 메서드
(defgeneric greet (person1 person2))

;; 다중 디스패치
(defmethod greet ((person1 person) (person2 person))
  (format t "person이 person에게 인사"))
 
(defmethod greet ((person1 teacher) (person2 student))
  (format t "teacher가 student에게 인사"))

 ;; 사용
 (let ((p1 (make-instance 'teacher :name "John" :age 20 :subject "math"))
       (p2 (make-instance 'student :name "Jane" :age 21 :grade 100)))
   (greet p1 p2)) ;; "teacher가 student에게 인사"

네. 여러분이 상상하는 그대로 동작하죠?

메서드 오버로딩과 비슷해 보이지만 약간의 차이가 있습니다.

public class Main {
	public static void greet(Person a, Person b) {
        System.out.println("Person이 Person에게 인사");
    }
    public static void greet(Teacher a, Student b) {
        System.out.println("Teacher가 Student에게 인사");
    }

    public static void main(String[] args) {
        Person teacher = new Teacher();
        Person student = new Student();
        greet(teacher, student); // Person이 Person에게 인사
    }
}

class Person {}
class Student extends Person {}
class Teacher extends Person {}

다중 디스패치: 런타임의 객체 타입에 따라 결정
오버로딩: 컴파일 타임의 객체 타입에 따라 결정

어떨때 다중 디스패치가 유용할까요?

예를 들어 student와 teacher가 랜덤으로 섞인 리스트에서 각각의 정보들을 앞서 정의한 display-info로 출력해줄때

student는 grade도 출력을 해주고, teacher는 subject를 추가로 출력해주는 것은 어떨까요?

이처럼 컴파일 타임에 각 객체의 타입을 정확히 알 수 없는 경우들이 있습니다.

정말 간단한 예로, 다중 디스패치를 지원한다면 런타임에서 임의의 Shape 객체에 대한 구역 구하기가 쉬워지겠죠?

특히 수치해석쪽은 정수/부동소수이냐, SparseVector/DenseVector이냐등 타입을 판별하는데 드는 시간보다 수행하는 최적화가 크기 때문에 Julia와 같은 언어는 다중 디스패치를 사용한다고 알려져있습니다.

;; 클래스 정의
(defclass circle ()
  ((radius :initarg :radius :accessor circle-radius)))

(defclass rectangle ()
  ((width :initarg :width :accessor rectangle-width)
   (height :initarg :height :accessor rectangle-height)))

(defclass triangle ()
  ((base :initarg :base :accessor triangle-base)
   (height :initarg :height :accessor triangle-height)))

;; 다중 디스패치가 없을경우 (일반함수 조건문)
(defun calculate-area (shape)
  (cond
    ((typep shape 'circle)
     (* pi (expt (circle-radius shape) 2)))
    
    ((typep shape 'rectangle)
     (* (rectangle-width shape)
        (rectangle-height shape)))
    
    ((typep shape 'triangle)
     (/ (* (triangle-base shape)
           (triangle-height shape))
        2))
    
    (t (error "지원하지 않는 도형입니다."))))


;; 다중 디스패치가 있을경우
(defgeneric calculate-area (shape)
  (:documentation "도형의 면적을 계산합니다."))

; 각 도형별 메소드 구현
(defmethod calculate-area ((shape circle))
  (* pi (expt (circle-radius shape) 2)))

(defmethod calculate-area ((shape rectangle))
  (* (rectangle-width shape)
     (rectangle-height shape)))

(defmethod calculate-area ((shape triangle))
  (/ (* (triangle-base shape)
        (triangle-height shape))
     2))


;;; 사용 예제
(defun print-areas (shapes)
  (format t "도형 면적 계산 결과:~%")
  (format t "==================~%")
  (loop for shape in shapes
        for i from 1
        do (format t "~A. ~A의 면적: ~,2f~%" 
                   i
                   (class-name (class-of shape))
                   (calculate-area shape)))
  (format t "==================~%"))

(print-areas(list
             (make-instance 'circle :radius 5)
             (make-instance 'rectangle :width 4 :height 6)
             (make-instance 'triangle :base 3 :height 4)
             (make-instance 'circle :radius 3)
             (make-instance 'rectangle :width 2 :height 8)))
;;; 결과
; 도형 면적 계산 결과:
; ==================
; 1. CIRCLE의 면적: 78.54
; 2. RECTANGLE의 면적: 24.00
; 3. TRIANGLE의 면적: 6.00
; 4. CIRCLE의 면적: 28.27
; 5. RECTANGLE의 면적: 16.00
; ==================

혹시 리스프 코드라 눈에 안들어오나요?

다음 형태라 생각해보세요.

// 다중 디스패치가 없을경우
type Shape = 
  | { kind: "circle"; radius: number }
  | { kind: "rectangle"; width: number; height: number }
  | { kind: "triangle"; base: number; height: number };

function calculateArea(shape: Shape): number {
  switch (shape.kind) {
    case "circle":
      return Math.PI * shape.radius ** 2;
    case "rectangle":
      return shape.width * shape.height;
    case "triangle":
      return (shape.base * shape.height) / 2;
  }
}

// 다중 디스패치가 있을경우
type Shape = Circle | Rectange | Triangle;
type Circle = { radius: number };
type Rectangle = { width: number; height: number };
type Triangle = { base: number; height: number };

function calculateArea(shape: Circle): number {
  return Math.PI * shape.radius ** 2;
}
function calculateArea(shape: Rectange): number {
  return shape.width * shape.height;
}
function calculateArea(shape: Triangle): number {
  return (shape.base * shape.height) / 2;
}

혼동이 올수도 있으므로 가능하다면 Switch나 패턴매칭을 우선적으로 사용하는게 좋을테지만,

강력한 패턴임은 분명해 보이네요.

3.2.3 메서드 조합: 횡단 관심사 제어

메서드 조합(Method combination)은 AOP(Aspect-oriented programing)에서 쓰이던 before, after, around가 메서드에 적용되는 것이다.

예를 들어 다음 코드는 "계산 중..."의 앞 뒤로 시작과 완료 메세지가 뜨게 된다.

;; 메소드 결합
(defmethod calculate-area :before ((shape t))
  (format t "면적 계산을 시작합니다.~%"))

(defmethod calculate-area :after ((shape t))
  (format t "면적 계산이 완료되었습니다.~%"))

;; 메소드 재정의
(defmethod calculate-area ((shape circle))
  (format t "계산 중...~%")
  (* pi (expt (circle-radius shape) 2)))

;; 사용
(calculate-area (make-instance 'circle :radius 5))

AOP와 마찬가지로 횡단 관심사(Cross-cutting concerns)인 로깅, 트랜잭션, 유효성 검증등에 유용합니다.

3.3 동적인 객체

이건 장점이라 보기에는 힘들지만, 프로토타입과 마찬가지로 인터프리터 언어의 특성이라고도 생각할 수 있습니다.

예를 들어 프로토타입 언어도 메서드를 CLOS처럼 동적으로 추가가능하며, 프로퍼티나 생성자 역시 동적으로 추가/변경할 수 있죠.

// 1. 프로토타입 생성자
function Person(name, age) {
  this.name = name;
  this.age = age;
}

// 프로토타입에 메서드 추가
Person.prototype.greet = function() {
  console.log(`Hello, ${this.name}!`);
};

// 인스턴스 생성
const person1 = new Person("John", 30);
const person2 = new Person("Jane", 25);

// 2. 동적 속성 추가 방법들
// 2.1 특정 인스턴스에만 속성 추가
person1.address = "Seoul";
console.log(person1.address); // "Seoul"
console.log(person2.address); // undefined

// 2.2 프로토타입에 속성 추가 (모든 인스턴스에 영향)
Person.prototype.address = "Default Address";
const person3 = new Person("Bob", 35);
console.log(person2.address); // "Default Address"
console.log(person3.address); // "Default Address"

// 2.3 생성자 함수 수정
function Person(name, age, address) {
  this.name = name;
  this.age = age;
  this.address = address;
}

// 새로운 인스턴스는 수정된 생성자 사용
const person4 = new Person("Alice", 28, "Busan");

CLOS 역시 앞선 Javascript처럼 프로퍼티(슬롯)을 추가 가능합니다.

다만, 엄연히 객체에 기반한 프로토타입 체인을 수정하는 자바스크립트에 비해 정의 자체를 재정의할 수 있다.

(defvar person1 (make-instance 'person :name "John" :age 20))

;; 클래스 재정의
(defclass person ()
  ((name :initarg :name
         :accessor person-name)
   (age :initarg :age
        :accessor person-age)
   (address :initarg :address
            :accessor person-address
            :initform "Default Address")))

;; 메서드 재정의
(defmethod display-info ((p person))
  (format t "이름: ~A, 나이: ~D, 주소: ~A~%" 
          (person-name p) 
          (person-age p)
          (person-address p)))

(person-address person1) ;; Default Address
(display-info person1)

그렇다면 address의 기본값을 바꿀 수 있을까요?

여기에서 프로토타입 객체지향과는 다른 면이 드러납니다.

어찌되었건 CLOS는 클래스의 확장이기 때문에, 이미 인스턴스의 프로퍼티가 초기화되어 이전에 있던 값을 반환합니다.

;; address의 기본 값을 변경
(defclass person ()
  ((name :initarg :name
         :accessor person-name)
   (age :initarg :age
        :accessor person-age)
   (address :initarg :address
            :accessor person-address
            :initform "Other Default Address")))

(person-address person1) ;; 하지만 "Default Address"

그렇다면 기존 인스턴스들을 명시적으로 마이그레이션을 해야 합니다.

기존에 사용하던 "Default Address"만 새로운 것으로 변경해봅시다.

;; 인스턴스 마이그레이션
(defmethod update-instance-for-redefined-class :after
    ((instance person) 
     added-slots 
     discarded-slots 
     property-list
     &rest initargs)
  (when (equal (person-address instance) "Default Address")
    (setf (person-address instance) "Other Default Address")))

(make-instances-obsolete 'person)

;; 체크해보기
(person-address person1)
(display-info person1)

그렇다면 혹시 특정 메서드를 제거하는 것이 가능할까요?

fmakunbound를 통해 일괄적으로 제거할 수도 있고, remove-method를 통해 특정 메서드만 선택해 제거할 수도 있습니다.

;; 모든 메서드 일괄 삭제
(fmakunbound 'display-info)

;; calculate-area의 :after로 나오는 로그 메서드 제거
(remove-method #'calculate-area
              (find-method #'calculate-area '(:after) (list (find-class 't))))

;; calculate-area의 circle 메서드 제거
(remove-method #'calculate-area
              (find-method #'calculate-area '() (list (find-class 'circle))))

3.4 MOP(Meta-Object Protocol)

MOP는 객체 지향 시스템의 구현을 사용자가 확장할 수 있게 해주는 인터페이스입니다.

Python의 metaclass와 비슷하지만 더 강력합니다.

파이썬의 metaclass가 생성 시점의 동작에 대해서 제어를 한다면

MOP는 클래스 정의, 슬롯 접근, 메소드 디스패치 등 거의 모든 부분에서 확장 가능합니다.

먼저 표준 메타 클래스는 standard-class 입니다.

(class-of person1) ;; #<STANDARD-CLASS #:PERSON>

이제 메타 클래스를 사용해보겠습니다.

몇가지 유용한 예를 만들어봤습니다.

3.4.1 인스턴스 카운터: 생성시 상태제어

인스턴스가 생길때 counter가 증가하도록 만들어봤어요.

이런 기능은 로그를 남길때 딱이겠죠?

;; 1. 에러를 피하기 위해서..
;; MOP 관련 패키지를 import함 - 추후 sb-mop:validate-superclass 와 같이 네임스페이스를 지정하지 않기위해
; https://koji-kojiro.github.io/sb-docs/build/html/sb-mop/
(use-package :sb-mop)

;; Meta class를 변경하기 위한 class의 symbol 제거
; https://stackoverflow.com/questions/38811931/how-to-change-classs-metaclass#38812140
(unintern 'person)

;; 2. 메타 클래스 정의
(defclass counted-class (standard-class)
  ((counter :initform 0)))

(defmethod make-instance :after ((class counted-class) &rest initargs)
  (declare (ignore initargs))
  (incf (slot-value class 'counter)))

(defmethod get-instance-count ((class counted-class))
  (slot-value class 'counter))

; 메타 클래스끼리 호환이 되는지 여부 - 필수로 구현요구
; true면 상속, false면 상속 금지
(defmethod validate-superclass ((class counted-class)
                                (superclass standard-class))
  t)

;; 3. 클래스 재정의
(defclass person ()
  ((name :initarg :name
         :accessor person-name)
   (age :initarg :age
        :accessor person-age)
   (address :initarg :address
            :accessor person-address
            :initform "Default Address"))
  (:metaclass counted-class))

;; 4. 사용
(get-instance-count (find-class 'person)) ;; 0
(make-instance 'person :name "Jane" :age 21)
(get-instance-count (find-class 'person)) ;; 1

3.4.2 타입 검사기: 기존 기능 확장

Common Lisp에는 분명 타입 선언을 할 수 있지만,

파이썬의 타입힌트처럼 런타임에서 무시하고 실행됩니다.

;; 재정의
(unintern 'person)

(defclass person ()
  ((name :type string
         :initarg :name
         :accessor person-name)
   (age :type integer
        :initarg :age
        :accessor person-age)))

;; 실행
(make-instance 'person :name 1 :age "John") ;; 잘못된 타입이지만 성공적으로 실행됨

Common Lisp의 타입명시는 최적화를 위해서 존재하기 때문이다. (Python은 IDE와 문서화 역할이 더 큼)

그럼 어떻게 하면 될까요?

메타 클래스를 이용해서 set 하기 전에 검사를 하면 됩니다.

;; 메타 클래스 정의
(defclass type-checking-class (standard-class)
  ())

(defmethod validate-superclass ((class type-checking-class)
                              (superclass standard-class))
  t)

(defmethod (setf slot-value-using-class) :before
           (new-value
            (class type-checking-class)
            instance
            slot)
  (let ((type (slot-definition-type slot)))
    (when type  ; type이 지정된 경우에만 검증
      (unless (typep new-value type)
        (error "Value ~S is not of type ~S" new-value type)))))


;; 클래스 재정의
(unintern 'person)
(defclass person ()
  ((name :type string
         :initarg :name
         :accessor person-name)
   (age :type integer
        :initarg :age
        :accessor person-age))
  (:metaclass type-checking-class))

;; 실행
(make-instance 'person :name 1 :age "John") ;; 에러!!
(defvar person1 (make-instance 'person :name "John" :age 20)) ;; 성공
(setf (person-age person1) 21) ;; 성공
(setf (person-age person1) "22") ;; 에러!!

결과는 이런식으로 나와요.

확실히 자바스크립트의 Proxy처럼 쓰일 수 있겠죠?

3.4.3 값 검증하기: 클래스 정의시 키워드 추가

이번에는 타입을 넘어 defclass를 할때 검증하는 함수를 넣어봅시다.

:validator 에 함수를 사용해 검증할 수 있도록 할거에요.

슬롯의 검증에는 직접 쓸때와 상속해서 쓸때 두 경우를 모두 다루어야 해요.

직접 사용하는 슬롯을 direct-slot이라 부르고요,

(defclass person ()
  ((name :initarg :name)    ; 직접 슬롯
   (age :initarg :age)))    ; 직접 슬롯

상속까지 고려했을때 유효한 슬롯을 effective-slot이라 불러요.

(defclass animal ()
  ((name :initarg :name)))

(defclass dog (animal)
  ((breed :initarg :breed)))

;; dog 클래스의 유효 슬롯:
;; - name (animal로부터 상속)
;; - breed (직접 정의)

이걸 감안해도 조금 어렵습니다만, 구현을 한번 살펴보도록 합시다!!

난이도는 흑마법이라 어쩔수가 없어요 ㅠㅠ

;; 클래스 정의
(defclass validated-class (standard-class)
  ())

(defclass validated-slot-definition (standard-slot-definition)
  ((validator :initarg :validator :initform nil 
              :accessor slot-validator)))

(defclass validated-direct-slot-definition 
  (validated-slot-definition standard-direct-slot-definition) ())

(defclass validated-effective-slot-definition 
  (validated-slot-definition standard-effective-slot-definition) ())

;; 검증 함수
(defun validate-slot (value validator slot-name)
  (when (and validator 
             (not (funcall (if (functionp validator)
                               validator
                               (coerce validator 'function))
                           value)))
    (error "Validation failed for slot ~A with value ~A" slot-name value)))

;; 메타클래스 메소드들
(defmethod validate-superclass ((class validated-class)
                                (superclass standard-class))
  t)

(defmethod direct-slot-definition-class ((class validated-class) &rest initargs)
  (declare (ignore initargs))
  (find-class 'validated-direct-slot-definition))

(defmethod effective-slot-definition-class ((class validated-class) &rest args)
  (declare (ignore args))
  (find-class 'validated-effective-slot-definition))

(defmethod compute-effective-slot-definition ((class validated-class) name direct-slots)
  (let* ((effective-slot (call-next-method))
         (validator (and (first direct-slots)
                         (slot-validator (first direct-slots)))))
    (when validator
      (setf (slot-validator effective-slot) validator))
    effective-slot))

(defmethod (setf slot-value-using-class) :before
  (new-value (class validated-class) object (slot validated-effective-slot-definition))
  (validate-slot new-value 
                 (slot-validator slot)
                 (slot-definition-name slot)))

(defmethod shared-initialize :after ((instance standard-object) slot-names &rest args)
  (declare (ignore args slot-names))
  (when (typep (class-of instance) 'validated-class)
    (dolist (slot (class-slots (class-of instance)))
            (when (slot-boundp instance (slot-definition-name slot))
              (validate-slot (slot-value instance (slot-definition-name slot))
                             (slot-validator slot)
                             (slot-definition-name slot))))))

;; 클래스 재정의
(unintern 'person)
(defclass person ()
  ((name :initarg :name
         :accessor person-name
         :validator (lambda (x) (and (stringp x) (> (length x) 5))))
   (age :initarg :age
        :accessor person-age
        :validator (lambda (x) (and (numberp x) (> x 5)))))
  (:metaclass validated-class))

;; 실행
(make-instance 'person :name "John Doe" :age 20) ;; 성공
(make-instance 'person :name "John" :age 20) ;; 실패
(make-instance 'person :name "John Doe" :age 3) ;; 실패

그럼 앞서했던 타입 검증과 검증을 차례대로 진행할 수 있다면 어떨까요?

현재 :validator에 있는 검증 로직이 줄어들 것 같네요.

구현은 간단하게 다중 상속을 하면 해결됩니다?!

;; 결합된 메타클래스 정의
(defclass type-and-validated-class (type-checking-class validated-class)
  ())

;; 상위클래스 검증
(defmethod validate-superclass ((class type-and-validated-class)
                              (superclass standard-class))
  t)

;; 클래스 재정의
(unintern 'person)
(defclass person ()
  ((name :type string
         :initarg :name
         :accessor person-name
         :validator (lambda (x) (> (length x) 5)))
   (age :type integer
        :initarg :age
        :accessor person-age
        :validator (lambda (x) (> x 5))))
  (:metaclass type-and-validated-class))

이외에도 MOP를 잘 활용하면 각종 로깅, 캐싱은 물론 완전한 AOP 구현에도 쓰일수 있겠죠?

MOP는 단순한 리플렉션을 넘어 객체지향 시스템 자체를 확장할 수 있다는 점에서 커다란 유연성을 제공합니다.

3.5 다중상속

다중 상속.. 말만 들어도 문제가 생길 것 같습니다.

사실 이런 문제들 때문에 저는 Trait이나 Protocol 방식을 좋아하나,

그래도 만약 Java나 C++과 같은 Class 방식을 써야 한다면 차라리 CLOS방식이 낫지 않나..

3.5.1 C++의 다중상속 문제

C++의 다중상속은 엉망이기로 유명합니다.

예를 들어 유명한 다이아몬드 상속을 생각해봅시다.

class A {};
class B: public A {};
class C: public A {};
class D: public B, public C {};

int main()
{
    D d{};
    return 0;
}

우리는 다이어몬드 모양으로 상속이 될거라 생각하지만, 실제모양은 오른쪽과 같습니다. [그림출처]

안믿긴다면 생성자를 사용해보세요.

#include <iostream>

class A {
public:
    A() { std::cout << "A constructor" << std::endl; }
};

class B : public A {
public:
    B() { std::cout << "B constructor" << std::endl; }
};

class C : public A {
public:
    C() { std::cout << "C constructor" << std::endl; }
};

class D : public B, public C {
public:
    D() { std::cout << "D constructor" << std::endl; }
};

int main() {
    D d{};
    return 0;
}

/* 결과
A constructor
B constructor
A constructor
C constructor
D constructor
*/

그래서 앞선 코드는 컴파일이 되었겠지만 실제로 메서드를 사용해보면,

보다 쉽게 문제를 확인할 수 있습니다.

#include <iostream>

class A {
public:
    void foo() { std::cout << "Message" << std::endl; }
};
class B: public A {};
class C: public A {};
class D: public B, public C {};

int main()
{
    D d{};
    d.foo(); // 에러: request for member ‘foo’ is ambiguous
    d.A::foo(); // 에러: ‘A’ is an ambiguous base of ‘D’
    d.B::foo(); // 가능
    d.C::foo(); // 가능
    return 0;
}

이는 A의 인스턴스를 하나만 쓰게 하면 해결됩니다.

B와 C에서 A를 가상 상속하게 되면 말이지요.

class A {
public:
    void foo() { std::cout << "Message" << std::endl; }
};
class B: virtual public A {};
class C: virtual public A {};
class D: public B, public C {};


int main()
{
    D d{};
    d.foo();
    d.A::foo();
    d.B::foo();
    d.C::foo();
    return 0;
}

생성자 예제에 virtual을 붙여 테스트해보세요.

A 클래스가 한번만 생성될 겁니다.

이게 끝이었다면 말을 꺼내지 않았을 겁니다.

이름 충돌 문제가 그대로 존재하기 때문에 다음은 에러가 생기게 됩니다.

class A {
public:
    void foo() { std::cout << "Message1" << std::endl; }
};
class B: virtual public A {
public:
    void foo() { std::cout << "Message2" << std::endl; }
};
class C: virtual public A {
public:
    void foo() { std::cout << "Message3" << std::endl; }
};
class D: public B, public C {};


int main()
{
    D d{};
    d.foo(); // 에러!!
    d.A::foo(); // Message1 출력
    d.B::foo(); // Message2 출력
    d.C::foo(); // Message3 출력
    return 0;
}

이를 해결하기 위해서는 명시적으로 해결해줘야 하지요.

class D: public B, public C {
public:
    void foo() { B::foo(); }
};

이외에도 C++에서 다중상속은 초기화 및 생성자/소멸자 순서 같은 관리의 모호함과 메모리 레이아웃, 가상상속 오버헤드등의 성능 문제들이 일어나기로 유명합니다.

3.5.2 CPL(Class Precedence List) 규칙

다행히도 Common Lisp에서는 CPL(Class Precedence List)이란 규칙을 사용해 결정적으로 적용됩니다.

참고로 다중 상속시 메타클래스와 일반 클래스는 동작이 다른데, 메타클래스는 결합되어 둘 다 실행되는 반면, 일반 클래스는 하나의 결정적인 메서드만 실행됩니다.

그래서 MOP에서는 타입과 검증을 함께 적용할 수 있었죠.

적용되었던 순서를 살펴봅시다.

type-and-validated-class -> type-checking-class -> validated-class ...순으로 적용된 것을 볼 수 있지요.

(compute-class-precedence-list (find-class 'type-and-validated-class))

;; 결과
(#<STANDARD-CLASS COMMON-LISP-USER::TYPE-AND-VALIDATED-CLASS>
 #<STANDARD-CLASS COMMON-LISP-USER::TYPE-CHECKING-CLASS>
 #<STANDARD-CLASS COMMON-LISP-USER::VALIDATED-CLASS>
 #<STANDARD-CLASS COMMON-LISP:STANDARD-CLASS>
 #<STANDARD-CLASS SB-PCL::STD-CLASS> #<STANDARD-CLASS SB-PCL::SLOT-CLASS>
 #<STANDARD-CLASS SB-PCL::PCL-CLASS> #<STANDARD-CLASS COMMON-LISP:CLASS>
 #<STANDARD-CLASS SB-PCL::DEPENDENT-UPDATE-MIXIN>
 #<STANDARD-CLASS SB-PCL::PLIST-MIXIN>
 #<STANDARD-CLASS SB-PCL::DEFINITION-SOURCE-MIXIN>
 #<STANDARD-CLASS SB-PCL::STANDARD-SPECIALIZER> ...)

CPL 규칙은 C3 선형화 알고리즘이므로 파이썬의 MRO(Method Resolution Order)와 거의 동일합니다.

클래스 자신이 가장 먼저
왼쪽에서 오른쪽으로 선언된 부모 순서
공통 조상은 한 번만 나타남 [위상 정렬(Topological Sorting)을 사용함]
standard-object와 t는 항상 마지막 [메타 클래스가 아닌 일반 클래스 기준]

그래서 다이아몬드 상속에서는 우선 순위가 어떻게 될까요?

;; 리스트대로 보여주기
(defun print-cpl (class-name)
  (format t "CPL for ~A: ~A~%" 
          class-name 
          (mapcar #'class-name 
                  (compute-class-precedence-list
                   (find-class class-name)))))

;; 다이아몬드 상속
(defclass A () ())
(defclass B (A) ())
(defclass C (A) ())
(defclass D (B C) ())

;; 결과
(print-cpl 'D)
; CPL for D: (D B C A STANDARD-OBJECT SLOT-OBJECT T)

CPL 대로라면 메서드를 선언했을때 D에 없을 경우 B의 메서드가 실행될테죠.

한번 실험해봅시다!!

;; 메소드 선언
(defgeneric foo (obj))

(defmethod foo ((obj A))
  (format t "Message1~%"))
(defmethod foo ((obj B))
  (format t "Message2~%"))
(defmethod foo ((obj C))
  (format t "Message3~%"))

;; 예시
(let ((d1 (make-instance 'D)))
  (foo d1)                    ; Message2
  (foo (change-class d1 'A))  ; Message1
  (foo (change-class d1 'B))  ; Message2
  (foo (change-class d1 'C))) ; Message3

다행히 잘 되는 모습을 볼 수 있네요.

그리고 CPL로 더 복잡한 경우도 잘 다루는 모습도 확인 가능합니다.

(defclass A () ())
(defclass B () ())
(defclass C () ())
(defclass D (A B) ())
(defclass E (B C) ())
(defclass F (D E) ())

; 결과
(print-cpl 'F)
; CPL for F: (F D A E B C STANDARD-OBJECT SLOT-OBJECT T)

단, 교차 상속에서는 문제가 생기지요.

;; 교차 상속
(defclass A () ())
(defclass B () ())
(defclass C (A B) ()) ; C는 A > B 순서를 요구
(defclass D (B A) ()) ; D는 B > A 순서를 요구
(defclass E (C D) ()) ; 모순 발생!


;; 에러
;  While computing the class precedence list of the class named COMMON-LISP-USER::E.
; It is not possible to compute the class precedence list because
; there is a circularity in the local precedence relations.
; This arises because:
;   The class named COMMON-LISP-USER::A follows the class named COMMON-LISP-USER::B in the supers of the class named COMMON-LISP-USER::D.
;   The class named COMMON-LISP-USER::B follows the class named COMMON-LISP-USER::A in the supers of the class named COMMON-LISP-USER::C..


;; 시각화
; E
; ├─ C
; │  ├─ A ──┐
; │  └─ B <─┤
; └─ D      │
;    ├─ B ──┤
;    └─ A <─┘
;
; 순환 발생: A > B > A

CLOS의 상속 시스템이 완전히 마음에 드는 것은 아니지만,

다중 상속이 필요하다면 적어도 C++의 다중 상속방식보다 나은 것으로 보입니다.

이제 Lisp가 강력하다는 의미를 체감했으리라 믿는다.

Homoiconicity말고도 안전하면서 쉬운 패턴매칭 매크로, 다양한 용도를 제공하는 동적 스코프, 객체지향 시스템 자체를 확장하는 CLOS 모두 메타적이고, 동적이고, 유연하게 만들어주는 리스프 특징을 잘 보여준다고 생각한다.

조심히 사용해야할 고오급 사용법 측면에선 꽤나 발전되어있다.

CLOS는 상당히 호불호가 갈릴수 있겠지만 나머지는 안전하면서도 다양한 활용법을 제공해주기 때문에 다른 언어들에서도 많이 참고했으면.

프롬프트, 프로그래밍처럼 생각하기

BlaCk_Void — Sat, 10 Feb 2024 00:32:15 +0900

제 블로그는 프로그래밍이 대부분의 주제를 다루고 있고, 이 글을 읽을 독자 또한 대부분 개발자라고 추측된다.

최근 2주간 프롬프트 엔지니어링을 하면서 얻은 인사이트를 공유해보자 한다.
당연히(?) 프롬프트만 만진건 아니긴 했지만..

내 결론은 프롬프트 엔지니어링은 프로그래밍처럼 접근 가능하다이다.

1. 언어

LLM은 자연어를 기반으로 한다.

따라서 장점과 단점이 공존한다.

직관적이고 풍부한 표현과 어휘를 모두 활용할 수 있지만, 상대적으로 모호한 편.

모호함을 줄이기 위해서는 마치 프로그래밍을 하는 것처럼 구조적으로 작성하고,
동음이의어일 경우 영어나 한문을 병기 표시함으로서 더 정확하게 뜻을 전달할 수 있다.

나중에 로지반 같은 AI 전용 언어가 등장해도 재밌지 않을까 싶긴하다 ㅋㅋ

2. 컴퓨터 구조 / OS

수많은 언어를 알아들으며 마치 Babel Fish 같은 LLM!!

Babel Fish

각종 하이퍼파라미터나 파인튜닝을 다룰려면 LLM이나 Transformer 구조에 대해 기본적인 이해를 하고 있으면 좋다.

트랜스포머는 어떻게 동작하나요? / 챗GPT는 어떻게 사람이 쓴 듯한 글을 자동으로 생성해낼까요?

예를 들어 Temperature는 출력 분포에 대한 것이며, TopP나 TopK는 조건을 만족하는 상위 N개에서 고르는 식으로 작동한다.

How to generate text: using different decoding methods for language generation with Transformers

프롬프트를 작성할 때도 그렇다.

컴퓨터에서 1 Word가 데이터 처리의 크기라면, LLM은 토큰 단위이며, 과금도 input과 output 토큰 단위로 이루어진다.

트랜스포머 구조

RAM과 같이 작업 메모리에 한계가 존재하며, 보통 컨텍스트 윈도우(Context Window)라고 부른다.

컨텍스트 윈도우는 모델마다 다르므로, 잘 살펴보고 사용하자.

Context Window Size and Language Model Performance: Balancing Act

만약 컨텍스트 윈도우 크기를 넘어선 크기의 작업을 하고 싶다면 작업성격에 따라 대화요약, RAG, 파인튜닝등을 고려해야 한다.

마지막으로 리눅스와 윈도우 같은 OS들이 C로 짜여져 C API가 기본이듯, 학습데이터에서 양과 질이 가장 좋은 언어인 영어를 기본으로 사용하면 좋다.
토큰도 아껴지는 것은 덤.

3. 프롬프트 엔지니어링

여기서 보여주는 코드는 이해를 돕기위한 임의의 슈도코드이다.
단수/복수등을 아주 엄밀하게 처리하지 않고, 의미가 통할 만큼만 사용하니 양해바란다.

일반적인 가이드는 이 4가지 공식 가이드에서 대부분 얻을 수 있다.

그냥 쭉 한페이지로 정리된 버전을 보고 싶다면 다음 페이지들을 참고하자.

이 외의 자료들은 Awesome Prompt Engineering을 보거나 마이크로소프트 리서치라던가 이곳저곳 돌아다니면서 읽어보는 수밖에 없는 것 같다.

3.1 Input - Output

대부분의 프로그래밍의 기초는 함수다.

input -> ouput

LLM도 다르지 않다.

자연어 -> 자연어

차이가 있다면

자연어이므로 다소 비결정적
input의 다음에 나타날 내용을 예측한 것이 output
이라는 점이다.

구조적인 output을 만들 수는 있으나 자연어 생성기라 생각하는 것이 낫다.
사람이 리스트나 JSON을 만든다고 하는 것처럼 말이다.

input 값으로 제대로 된 예측을 시키거나, 일을 시키려면 어떻게 해야 할까?
지시(Instruction)를 내려야 한다. 그리고 지시는 콜백함수로 생각할 수 있다.

(callback) -> ouput

함수는 모종의 알고리즘 구현체로 생각할 수 있다.
그렇다면 입력 데이터도 있지 않을까?
프로그램은 데이터와 알고리즘으로 이루어지므로 매우 당연한 생각이다.

(callback, data) -> output

시스템 프롬프트(callback), 유저입력(data), AI출력(output)으로 치환해보아도 말이 된다.

이게 바로, Zero-shot 프롬프트다.

입력:

텍스트를 중립, 부정 또는 긍정으로 분류합니다.
텍스트: 휴가는 괜찮을 것 같아요.

출력:

중립

3.2 복잡한 Input - Output

복잡한 지시는 대개 정책(규칙)과 작업(Task)으로 나눌 수 있다.
이를 정할 때는 leaked-system-prompts가 도움이 될 것이다.

보다 명확하게 생각하기 위해 타입을 붙여서 표현해보자.

InputCallbacks: (Rules, Tasks)
(callback: InputCallbacks, data: AnyStr) -> output

규칙:

역할을 전문가로 설정하면 보다 정확한 대답을 생성해준다고 알려져 있다.
(예: 프론트엔드 엔지니어로서 답변하세요, 당신은 심리학자 입니다.)

반대로 초등학생에게 설명하듯처럼 유저의 역할을 정할 수도 있다.
물론 다음 것들이 가능하다.

어조: 명확하게, 유머러스하게, 따뜻하게
제약: 한문장으로, 100자 정도로
포맷: 리스트로, JSON으로
보안: 내부 규칙은 공개하지 않습니다

작업:

목표나 ReAct(Reason-Act)처럼 구체적인 추론과 행동등이 있을 수 있다.
추론은 jmp, if와 같은 제어요소이고, 행동은 syscall, function과 같은 호출이다.

이때 작업을 단계별로 구성하는 CoT(Chain of Thought)는 커다란 도움이 된다.

Role: AIRole & UserRole
Rule: Role & Tone & OutputFormator & Security
Task: Goal & Inference & Action
InputCallbacks: (Rule[], Tasks[])

(callback: InputCallbacks, data: AnyStr) -> output

Thought는 위의 Inference로 취급함

중간의 태스크를 세분화된 방식으로 생각하면 다음과 같은 것이다.

input
-(Thought1)-(Action1)-(Observe1)
-(Thought2)-(Action2)-(Observe2)
-(Thought3)-(Action3)-
-> output

이렇게 생각해보면 OutputFormator는 Rule보다는 마지막에 실행하는 Action에 가까우니 Task로 취급해도 될 것 같다.

Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Inference & Action
InputCallbacks: (Rule[], Tasks[])

(callback: InputCallbacks, data: AnyStr) -> output

3.3 Sub-function

면밀히 생각해보면 Subtask, 즉 sub-function은 자체적인 규칙과 추론단계를 포함할 수 있다.
그리고 Subtask도 가지고 있을수도 있으리라.

예를 들어 Task인 OutputFormator는 리스트나 JSON Schema와 같은 규칙을 가지고 있다.

Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Rule & Inference & Action & Task
InputCallbacks: (Rule[], Tasks[])

(callback: InputCallbacks, data: AnyStr) -> output

다만 프롬프트를 만들때 중첩을 많이 가지는 것은 좋지 않은 생각이다.

나는 subtask 대신 한단계의 Task 정의로 끝내고 필요하면 Thought-Act 로 표현하는 방식을 사용한다.

작업이 이어지는 프롬프트 체이닝 경우, 커링으로 생각할 수 있다.

input -> ouput1 -> ouput2 -> output3

중간의 태스크를 세분화해 ReAct(Reason-Act) 방식으로 생각하면 다음과 같은 것이다.

input -(Thought1)-(Action1)> Observe1
-(Thought2)-(Action2)> Observe2
-(Thought3)-(Action3)> output

3.4 Context / Dependency Injection

복잡한 프로그램을 할 때 단순히 input 데이터만 사용하지 않는다.
의존성을 주입하거나, 중간에 I/O등으로 인한 Effect가 존재하기도 한다.

먼저 의존성 주입을 생각해보자.
참고할 만한 문맥(Context)나 정보(Knowledge)를 넣을 수 있다.

아래 문맥을 고려해서 질문에 답변해 줘. 답변은 짧고 간결하게 해 줘. 답변이 정확하지 않다면, 「확실치 않은 대답」이라고 응답해 줘.

문맥: Teplizumab은 Ortho Pharmaceutical이라는 뉴저지의 제약 회사에서 유래했다. 그곳에서, 과학자들은 OKT3라는 항체의 초기 버전을 만들어 냈다. 원래 쥐에서 유래된 이 분자는 T 세포의 표면에 결합하여 세포를 죽이는 잠재력을 제한할 수 있다. 1986년, 신장 이식 후 장기 거부 반응 예방을 위해 승인되어 인간이 사용할 수 있는 최초의 치료용 항체가 되었다.
질문: OKT3는 어디서 유래했는가?
답변:

슈도코드로는 이렇게 될 것이다.

Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Rule & Inference & Action & Task
InputCallbacks: (Rule[], Tasks[])
InputData: (Knowledge, Data | Question)

(callback: InputCallbacks, data: InputData) -> output

앞선 프롬프트를 풀어보면 다음과 같다.

Tasks: 아래 문맥을 고려해서 질문에 답변해 줘.
Rules: 답변은 짧고 간결하게 해 줘. 답변이 정확하지 않다면, 「확실치 않은 대답」이라고 응답해 줘.
Knowledge: 문맥
Data: 질문

Directional Stimulus Prompting 처럼 힌트를 추가해도 도움이 될 것이다.
특히 요약같은 경우 WordRank나 기존 NLP등을 보조로 사용할 수 있다.

Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Rule & Inference & Action & Task
Context: Knowledge & Hints

InputCallbacks: (Rule[], Tasks[])
InputData: (Contexts[], data: Data | Question)

(callback: InputCallbacks, data: InputData) -> output

3.5 Effect

LLM이 자체적으로 중간에 외부 툴링과 상호작용할 수도 있다.

예를 들어 코드 인터프리터(Program-Aided Language Models), RAG(Retrieval Augmented Generation)이 해당 개념이다.
PAL은 프로그램을 실행해주며, RAG는 지식을 주입받을 수 있다.

Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Rule & Inference & Action & Task
Context: Knowledge & Hints

InputCallbacks: (Rule[], Tasks[])
InputData: (Context[], Data | Question)
Effects: PAL | RAG

(callback: InputCallbacks, data: InputData) -[ Effects ]-> output

그런데.. LLM은 항상 같은 결과를 내는가?
아니다. 따라서 내부에서 사용되는 Inference, Action이든 Function call이든 모두 Effect를 가졌다고 생각해도 무방하다.

즉, PAL, RAG등은 모두 Action 개념으로 통일해버리자.

3.6 Tests

일반적인 프로그래밍에서는 Test를 작성하여 안정성을 높힐 수 있다.
그러나 단지, 잘 동작하나 테스트를 할 뿐이지 자동적으로 런타임에서 품질을 높혀주지는 않는다.

하지만 머신러닝 세계에서는 input - Output 예를 Input으로 집어넣어 성능을 향상 시킬 수 있다.
이는 일반적인 프로그램에서 가질 수 없는 특성이며, 알파이자 오메가다.
재귀함수를 Loop unrolling된 형태로 최적화해주는 컴파일러가 생각나기도 하다.

Few-shot: Zero-shot의 예를 사용
Self-Consistency: CoT의 예를 사용
ReAct: 프롬프트 체이닝을 예로 사용

타입으로 생각해보면 다음과 비슷할 것이다.

Role: AIRole & UserRole
Rule: Role & Tone & Security
Task: Goal & Rule & Inference & Action & Task
Context: Knowledge & Hints

InputCallbacks: (Rule[], Tasks[])
InputData: (Context[], Data | Question, (Example<Prompt>)[])

Prompt: (callback: InputCallbacks, data: InputData) -> output

TDD는 LLM을 이용시 오히려 특화된 개발 방법론 아닐까?

LLM 특성상 편향을 가질 수 있기 때문에 되도록 다양한 예를 넣어주는 것을 추천한다.

4. 템플릿

나는 다음과 같은 구조로 작성하게 되는 것 같다.

먼저, 창의적이기보다는 일정한 규칙을 꼭 지켜야하는 빡빡한 Output이 나와야 하는 환경에 맞추어 작성하였음을 알았으면 한다.
또한 세부적인 프롬프트를 공개하기에는 보안상 조금 어려움이 있으니 양해바란다.

Rules: 전반적으로 지켜야 하는 것들
Tasks: 액션 리스트와 설명, 여기에 FunctionCall(코드 인터프리터, RAG등)과 OutputFormator도 포함된다
Task Steps: 메인함수처럼 각 태스크를 ReAct 방식으로 표현. 복잡하지 않으면 리스트로만 작성해도 상관없다
Examples: input-output 예시들, 정말 명시적으로 하고 싶을 때는 CoT나 ReAct방식대로 추론과정을 펼쳐서 작성한다.
Start: 유저나 API가 입력하기 직전에 넣을 내용들

### Rules ###
Description
1. Rule 1..
2. Rule 2..
3. ...


### Tasks ###
Description

(1) Task1[input]: Description
- Task rule 1
- Task rule 2
- ...

(2) Task2[input]: Description
- Task rule 1
- Task rule 2
- ...


### Task Steps ###
Description

Question: [User message]
Thought1: infer description
Act1: Task1[1nput]
Obs: {result1}
Thought2: infer description
Act2: Task2[1nput]


### Examples ###
Description

- Context: Data
Input: example1 input
Ouput: example1 output
Input: example2 input
Ouput: example2 ouput

- Context: Data
Input: example1 input
Ouput: ...

### Start ###
Description

어찌보면 코볼과 파스칼과 굉장히 유사하게 만들어졌다.
코볼이 identification, environment, data, procedure DIVISION으로 나뉘거나 Pascal/Delphi가 program, uses, label, const 등으로 섹션을 나누는 것과 비슷하다.

Cobol Structural Hierarchy / Cobol Program Structure / The structure of a Pascal program in the Delphi and Lazarus programming systems. Console application

요즘 관심있는 걸로는 의사결정 기법으로,

최대한 선형적이며 분기없으면서 안정적으로 작업을 시키려 Task Step에 적용해보려고 시도하고 있다.

The Effect of Locus of Control on Organizational Learning, Situation Awareness and Safety Culture

LogiCoT만으로 애매한 부분들을 채워줄 수 있을 것으로 보인다.

5. IDE

복잡해져서 전용 IDE로 관리하면 좋겠다는 생각이 스물스물 들고 있다.

정도를 고려해보고 있는데 독자 여러분 중 사용해보신 적 있으시면 후기를 댓글로 남겨주시면 감사하겠습니다. ㅎㅎㅎ

나중에는 Oberon이나 Archy처럼 텍스트가 곧 명령처럼 사용할 수 있는 UI도 만들어지지 않을까.

Oberon(에뮬레이터)

형태는 조금 다르겠지만 말이다.

상품과 기호: 들뢰즈-가타리를 중심으로

BlaCk_Void — Sun, 25 Jun 2023 07:40:36 +0900

개발자분들이 의외로 철학쪽 내용을 좋아하셔서 독후감 과제를 하다 나온 내용을 옮겨보았습니다.

원 글은 3페이지라는 제약 내에서 쓰여져서 짧긴하나, 압축적이라 기본적으로 요구하는 지식이 있으며 평소에 제가 쓰는 다른 글과 달리 조금.. 어려울 수도 있습니다.

아래에 추가로 작성한 글도 기초적인 내용이긴 한데, 익숙하지 않다면 어렵게 느껴질 수 있는 글 입니다.

난이도 조절을 실패한 듯.

1. 상품과 제품

이 책에서 가장 인상 깊은 점은 역시 제목인 "소비자는 좋은 제품을 선택하지 않는다"이다.

책의 "제품이 부품의 결합체지만 상품은 상징적 의미의 더미"라는 표현이 이를 설명하는 가장 간단한 명제라 할 수 있다.

상품은 제품/서비스란 실체를 가르키는 일종의 기호다. 그렇다면 "기호와 지시대상은 과연 다르게 받아들여질 수 있는가?", "그리고 그 관계와 영향이란 무엇인가?"라는 의문이 떠오를 수 있다.

금성은 태양계의 2 번째 내행성이다. 그러나 샛별[새벽 동쪽하늘에서의 금성]과 개밥바라기[저녁 서쪽하늘에서의 금성]라는 이름 또한 가지고 있으며 의미를 다르게 받아들인다.
이는 기호와 지시대상이 1:1 관계를 가지지 않는다는 반례이다.

또한 샛별은 "샛별"이라는 문자임과 동시에 /ˈsʰɛ̝ːt̚p͈jʌ̹ɭ/ ~ /ˈsʰɛ̝ːp͈jʌ̹ɭ/ɭ 샏:뼐/새:뼐]^[각주:1]로 발음하는 표현이다. 그러나 샛별이라는 기호 자체의 표현과 의미도 1:1 관계를 가지지 않는다. 영어로는 Evening star 라고 불리는 표현의 반례 때문이다. 방금의 예와 같이 기표와 기의는 우연성에 의해 중계되지만 샛별이란 표현에서 대부분의 한국인들이 '새벽 동쪽하늘에서의 금성'을 떠올리는 것은 한국어-한글이란 체계 속에서 규약적 필연^[각주:2]을 띄기 때문이다.

이러한 관계 속에서 우리는 기호체제간에 따라 기호의 해석이 달라짐을 발견할 수 있다.^[각주:3]

태양계 2 번째 행성에서 나온 새로운 정보[발생적 성분]로서의 "금성"은 다른 기호체제인 영어로는 Venus 로 번역 가능한데[변형적 성분], 한국어는 오행(五行)의 금(金)을 영어는 그리스신화의 미의 여신인 아프로디테로 세부적인 차이가 있다.

예를 확장해 변환 중 의미소실 사례를 알아보자. 금성사는 한자인 金星으로 변형 후 다시 영어인 GoldStar 로 번역되어 금성(Venus)이라는 발생적 성분이 없어졌기에 두 문화권에서 금성사를 대해 느끼는 상징적 의미와 해석이 다소 달라질 수 밖에 없게된다.
들뢰즈-가타리에 따르면 기호계는 '발생적 성분', '변형적 성분', '다이어그램적 성분', '기계적 성분'을 가지고 있으나 본 보고서가 3 페이지란 공간의 제약으로 자세한 설명은 생략한다.

이렇듯 순수 생산물로서의 제품이 상품으로 편입되는 순간 기존 기호적 체제와의 상호작용에 의해 해석이 달라질 수 있다. 의미가 축소/확장되거나 때로는 바코드 번호처럼 반기표적 기호의 성질을 띄기도 한다. 하지만 무엇보다 중요한 점은 상대적으로 달라진다는 점이다. 상품을 만들 때는 표현과 내용에 있어 다양한 차이를 고려하고 어떠한 의미로 받아들여질지 고려해야 할 것이다.

2. 상품과 상품

상품과 제품에서 이야기했듯이 기호는 그 자체로 다의성을 띌 수 있다.
사과(Apple)라고 하면 먹는 사과를 떠올릴 수 있겠지만 뉴턴의 만유인력, 세잔의 정물화, 잡스의 Apple Inc. 등을 떠올리기도 한다는 것 이다.

위처럼 다의성을 띄지만 시대나 사용하는 사례에 따라 인식하는 강도는 물론 의미까지 달라진다.
비트겐슈타인이 "언어를 말하는 일이 어떤 활동의 일부, 또는 삶의 형식의 일부"^[각주:4]라고 했던 것처럼 말이다. 똑같이 먹는 사과에서 비롯되었지만, 이제 IT 산업에서 사과를 이야기하면 Apple Inc.만 떠올리지 먹는 사과로서의 인식은 한입 베어먹은 로고를 제외하면 남아있지 않다. 더 극적인 예를 들어보자면 '혜자스럽다'와 '창렬스럽다'^[각주:5]가 있다. 두 개 모두 연예인의 이름에서 따왔지만 지금은 본래 뜻보다는 '식품의 맛과 양이 만족스러움', '가격 대비 적은 양의 식품을 부정적으로 일컫는 말'로 널리 쓰이고 있다.

이제는 그들의 이미지에 의해 역으로 현실이 지배받아 기업들은 해당 이미지를 사용하며 본인들도 어느새 휘둘리게 된다.^[각주:6] ^[각주:7] 보드리야르^[각주:8]식으로는 파생실재를 모델을 가지고 산출하는 작업이다.
원래 'Apple'에는 회사의 이미지가 없으며 '혜자'와 '창렬' 역시 식품의 가성비와 관련된 이미지가 없다는 점에서 'Apple Inc.', '혜자스럽다', '창렬스럽다'의 이미지는 모두 "실제로는 존재하지 않는 대상을 존재하는 것처럼 만들어놓은" 원본 없는 이미지인 시뮬라크르였지만 실제보다 실제가 되어버린 것이다

본디 존재하지 않던 것이 원본을 대체한다니, 과연 나쁜 것일까?
'창렬스럽다'처럼 '김창렬'이라는 개인 내지는 가족에게 불이익을 준 사례^[각주:9]가 있으므로 안 좋게 볼 수도 있겠지만, 'Apple'과 '혜자스럽다'는 그렇다고 단언하기 힘들다. 오히려 원본으로 대체 불가능한 독특한 가치를 가지고 있다. 만약 시뮬라크르가 나쁜 것이라면 'Apple Inc.'가 이루어낸 많은 혁신들이 부정되며, 이제는 초코파이의 대명사가 되버린 오리온 초코파이 정(情) 또한 안 좋은 것이 되고야 만다. 그리고 이에 대해 들뢰즈는 "존재는 생성을 통해, 동일성은 차이 나는 것을 통해, 일자는 다자를 통해 자신을 언명한다"^[각주:10]고 말한다. 쉽게 설명하면 각각의 시뮬라크르라는 존재는 차이가 있기에 가치가 있으며 원본회귀와 재현하려는 시도는 일종의 억압이라는 뜻이다.

즉, 상품의 이미지는 현실보다 현실 같은 독자적 존재가 되었으며 원본이 무엇인지 중요치 않다. 예컨대 '내가 먹는 사과', '세잔 그림의 사과'의 원본은 사과열매지만 차이에 의해 각자 가지는 이미지가 달라진다. 똑같이 현존하는 사과라도 '생산자에게의 사과', '판매자게에의 사과', '소비자에게의 사과'는 각각에게 이미지가 다를 것이다. 상품의 원본 자체에 대해 고민하기보다 어떠한 고유한 가치를 생산할 지 고민하자.

3. 상품과 욕망

이 책에서 가장 아쉬웠던 점은 소비행동을 단순히 "소비자 자신의 욕구를 충족하기 위한 수단"으로 정의했다는 점 이다. "제품의 가치를 소진하는 과정"보다 발전된 것은 분명하지만 여전히 결핍 혹은 결여를 채우려는 부정적인 시각으로 바라보고 있다. 이러한 결핍으로의 환원은 결국 프로이트의 리비도에서 벗어나지 못한 것에 가깝다고 할 수 있다.

자, 이제 생각을 해보자. 우리가 떠오르는 생각과 느껴지는 것들을 글, 그림, 사진등으로 남기기는 망각에 대비 뿐이며, 스타트업을 만들어 독특한 상품을 만들고자 노력하는 창업가에 대해서 자본의 결핍 내지는 사회적 인정의 결핍만이라고 설명할 수 있는가?

이를 단지 결핍되었다고 설명하기란 어렵다. 매슬로우의 단계 욕구이론에서도 자아실현은 특별히 따로 구분하고 있으며, 말년의 매슬로우는 자신의 욕구이론을 비판^[각주:11] ^[각주:12]하고 초월의 욕구등 다양한 욕구를 추가하기도 했다.

앞서 단순 결핍의 반례로 설명한 사례는 자아실현을 위한 시도[자기초월의 과정]로 니체적 힘(Kraft)에의 의지에 가깝다고 할 수 있다. 이제 욕구와는 구분되는 단어, 욕망(Desire)이 필요하다. 들뢰즈-가타리는 욕망을 무의식의 자기생산이라 이야기한다. 여기서 생산이란 구성, 조립, 배치등을 통한 유물론적 변형으로 여겨지며 욕망은 마르크스적 의미의 하부구조, 기계들로서 작동한다.^[각주:13]

이 책에서도 상품 소비의 충분조건을 설명할 때 디자인, 촉감/질감 같은 감각, 분위기 등의 모든 자극, 사용하며 떠올리는 모든 연상이 포함다는 점에서 하나의 배치체, 하나의 집합체 구성에 긍정한다고 볼 수 있다. 또한 이 연상을 촉발하는 것은 마주침의 우연성이며, 연상 과정은 결핍이라기보다는 흐름들을 절단-결합하는 생산작용에 가깝다는 것을 알 수 있다.

그렇다면 결핍은 어찌하여 생기고 작동하는 걸까?
들뢰즈-가타리는 억압적 재현작용과 억압된 대표, 욕망이 억압된 대표에 사로잡혔다고 여기게 되는 위조된 이미지를 주는 재현내용으로 구성되며, 억압이 작용하려면 "기꺼이 벌 받으려는 후속욕망"이 억압의 대상인 선행욕망을 대신 해야한다고 말한다.^[각주:14]

이를테면 거식증^[각주:15]은 체중에 대한 반복적 사회적 압박[재현작용], 음식 섭취[억압된 대표], '멋져보이는' 모델/연예인들과의 비교[위조된 이미지의 재현내용]에 의해 일어나며 체중 감소라는 후속욕망이 음식 섭취라는 선행욕망을 대신하기 때문일테며, 처음 언급한 프로이트의 핵심인 오이디푸스콤플렉스는 제국주의가 사회적 욕망을 가족 내의 욕망으로 이전시킨 관점에서 이해할 수 있다.

정리한 바와 같이 결핍은 욕망적 생산에 의한 표상일 뿐이며, 선행하지 않는다. 억압작용도 후속욕망이 본질적으로 유목적인 욕망적 생산의 연결을 고정하려는 '욕망'이라는 점에서 이 설명은 꽤 타당해보인다. 욕망의 특성을 잘 이용한 예로 젤다 야숨의 동기부여 방식^[각주:16]이 있다. 억압이 없는 한 계속하여 흐르게하고 흐르고 절단하는 욕망이 자연스레 각 유저별로 차이를 생산하게 구성되어 특별하게 만든다는 점에서 좋은 서비스다.

이제 억압보다 차이를 긍정하며, 사회에 내적 동기의 중요성^[각주:17]에 대한 보편이 형성되었으면 한다.

최근에 Claude 3.5를 이용해 4번 파트를 생성시켰는데 생각보다 마음에 들게 나오네요.

추가로 덧붙여봅니다.

사용한 프롬프트는 다음과 같습니다.
1. 다음 글의 내용을 이해하고, 요약하시오. (위 글 내용 첨부)
2. 푸코의 담론 이야기까지 쭉 전개해 "상품과 권력"을 작성하여, "좋은 제품"에 대한 수미상관으로 마무리하시오.
원본 글의 전개방식, 논리구조, 어조등을 그대로 유지해야 합니다.

4. 상품과 권력

앞서 우리는 상품이 기호로서 작동하며, 그 의미가 맥락에 따라 변화하고 때로는 실재를 대체하는 시뮬라크르가 될 수 있음을 살펴보았다. 이제 우리는 한 걸음 더 나아가 상품과 권력의 관계를 살펴보고자 한다. 과연 "좋은 제품"이란 무엇인가? 이는 단순히 기능적 우수성만을 의미하는가, 아니면 그 이상의 무언가를 내포하고 있는가?

푸코의 관점에서 보면, "좋은 제품"이라는 개념은 하나의 담론(discourse)으로 볼 수 있다. 담론이란 특정 주제에 대한 진술들의 집합이며, 이는 단순한 언어적 표현을 넘어 사회적 실천과 권력 관계를 포함한다. 푸코에 따르면, 담론은 지식과 권력이 결합하여 형성되며, 이는 다시 현실을 구성하는 힘으로 작용한다.

"좋은 제품"이라는 담론은 어떻게 형성되고 작동하는가? 이는 기업, 소비자, 미디어, 전문가 등 다양한 주체들의 상호작용을 통해 구성된다. 예를 들어, 애플의 아이폰이 "좋은 제품"으로 인식되는 것은 단순히 그 기술적 우수성 때문만은 아니다. 애플의 마케팅 전략, 소비자들의 열광적인 반응, 기술 전문가들의 평가, 그리고 이를 보도하는 미디어의 역할이 복합적으로 작용한 결과이다.

이러한 담론의 형성 과정에서 권력 관계가 작동한다. 대기업은 막대한 자본력과 영향력을 바탕으로 "좋은 제품"에 대한 담론을 주도할 수 있다. 반면, 소규모 기업이나 신생 기업은 이러한 담론 형성 과정에서 상대적으로 불리한 위치에 놓이게 된다. 이는 마치 푸코가 말한 "규율 권력"과 유사하게 작동한다. 소비자들은 "좋은 제품"이라는 담론에 의해 자신의 소비 행위를 규율하게 되는 것이다.

그러나 담론의 형성이 일방적인 것은 아니다. 소비자들 역시 SNS나 리뷰 플랫폼을 통해 제품에 대한 자신의 의견을 표현하고, 이는 다시 "좋은 제품"에 대한 담론을 재구성하는 데 영향을 미친다. 이는 푸코가 말한 "권력의 미시물리학"과 연결된다. 권력은 중앙집중적이지 않고, 사회 전반에 퍼져 있으며 다양한 관계 속에서 작동한다는 것이다.

더 나아가, "좋은 제품"이라는 담론은 단순히 제품의 품질에 대한 것만이 아니라, 우리 사회의 가치관과 라이프스타일까지 규정하는 힘을 갖는다. 예를 들어, 친환경 제품이 "좋은 제품"으로 인식되면서, 이는 환경 보호라는 사회적 가치를 강화하고 소비자들의 행동 변화를 유도한다. 이는 푸코가 말한 "생명정치(biopolitics)"의 한 형태로 볼 수 있다. 권력이 개인의 삶과 행동을 미시적으로 관리하고 조절하는 것이다.

그렇다면 우리는 이러한 담론과 권력 관계를 어떻게 바라보아야 할까? 단순히 부정적으로만 볼 것이 아니라, 이를 통해 새로운 가능성을 모색할 수 있다. "좋은 제품"에 대한 담론을 재구성함으로써, 우리는 더 나은 사회를 만들어갈 수 있는 기회를 얻을 수 있다. 예를 들어, 사회적 가치를 창출하는 제품, 노동자의 권리를 존중하는 기업의 제품을 "좋은 제품"으로 인식하게 된다면, 이는 기업의 행동 변화를 유도하고 궁극적으로 사회 전반의 변화를 이끌어낼 수 있다.

이제 다시 처음의 질문으로 돌아가 보자. "소비자는 좋은 제품을 선택하지 않는다"는 명제는 어떤 의미를 갖는가? 이는 단순히 소비자의 비합리성을 지적하는 것이 아니라, "좋은 제품"이라는 개념 자체가 복잡한 담론과 권력 관계 속에서 구성된다는 것을 의미한다. 소비자는 이러한 담론에 영향을 받으면서도 동시에 그것을 재구성하는 주체이다. 따라서 "좋은 제품"의 선택은 단순한 개인의 취향이나 합리적 판단의 문제가 아니라, 사회적, 문화적, 정치적 맥락 속에서 이루어지는 복잡한 과정인 것이다.

결국, "좋은 제품"이란 무엇인가에 대한 질문은 우리 사회가 어떤 가치를 추구하고, 어떤 방향으로 나아가야 하는가에 대한 질문과 맞닿아 있다. 이는 단순히 기업의 마케팅 전략이나 소비자의 선택의 문제를 넘어, 우리 사회의 미래를 결정짓는 중요한 담론이 된다. 따라서 우리는 "좋은 제품"에 대한 담론을 비판적으로 성찰하고, 이를 통해 더 나은 사회를 만들어가는 데 기여할 수 있어야 할 것이다.

Citations:
18. Michel Foucault, The Archaeology of Knowledge, Routledge, 2002
19. Michel Foucault, Discipline and Punish: The Birth of the Prison, Vintage Books, 1995
20. Michel Foucault, The History of Sexuality: An Introduction, Volume I, Vintage Books, 1990

5. 배경지식

그렇습니다.

초반에 차근차근 설명하다가 후반으로 갈수록 3페이지 제한 내에 쓸만한 주제가 아니라 설명에 실패했어요.

원래 계획은 푸코의 담론 이야기까지 쭉 전개해 "상품과 권력"까지도 쓸려고 했으나 쳐내고, "좋은 제품"에 대한 수미상관으로 마무리만 했습니다만, 그럼에도 요하는 배경지식이 너무 많습니다.

(권력에 대한 이론은 마케팅으로 접목할 수 있겠죠 :D)

들뢰즈-가타리의 철학을 위해서는 크게 세가지의 계파를 이해하면 좋습니다.

의심의 대가들

스피노자-니체
헤겔-마르크스
프로이트-라캉

니체적 힘에의 의지는 극복하려는 의지로 이데아를 위해 욕망을 부정하는 플라톤주의나 정신분석학에서 결핍으로보는 프로이트-라캉과는 다르게 욕망 자체의 긍정적인 면을 설명하기 위해 사용됩니다. 유물론적인 욕망하는 생산은 역시 마르크스의 욕구가 새로운 사회관계들을 만들고 증가된 인구가 새로운 욕구를 만드는 연쇄를 통해 욕망-생산 관계를 도입하며, 상대적 빈곤으로 인한 욕구와 억압을 설명하기 위해 사용합니다. 들뢰즈-가타리는 위의 이론을 일부 차용하고 있습니다. 그러나 니체가 개인을 강조하는 것과 달리 사회를 강조하며, 마르크스가 사용하는 변증법과 필연성 대신 우연성을 사용합니다.

마지막으로 기호론의 경우, 소쉬르보다는 옐름슬레우의 방법을 택하고 있습니다.

제가 썼던 글도 마찬가지 입니다.

또 다른 진입장벽은 용어 입니다.

기계의 의미부터 다르고 탈영토화, 탈코드화니 일반인 입장에서 알수없는 해괴한 용어들을 사용합니다.

들뢰즈 개념어 사전이라 아예 책으로 출판될 정도입니다.

들뢰즈 가타리 용어 설명

이라는 글을 보도록 합시다.

철학쪽은 오마주가 참 많아요.

이를 알면 또 보는 재미가 있을겁니다. ㅋㅋ

니체의 『도덕의 계보학 』 - 들뢰즈의 『도덕의 지질학』- 푸코의 『지식의 고고학』처럼 이론을 계승해 이름을 치환하거나 비슷한 형식을 취한 수준부터, 프루동의 『빈곤의 철학』을 저격해 순서를 뒤바꾼 마르크스의 『철학의 빈곤』과 마르크스를 따라 들뢰즈(「 기관 없는 신체」)를 뒤집는 지젝의 『신체 없는 기관』처럼요.

이제 진짜 본문같은 내용들.

옐름슬레우 관련은 연결이 됩니다만, 아예 다른 내용이라 생각해도 좋습니다. ~~그냥 글 나누기가 귀찮아서 그래요..~~

6. 기호론과 LLM

아무튼, 이 글에 들어오신 분들이 기대한 글은 위의 내용이 아닐겁니다. ㅠㅠ

여기서 제가 쓰려는 주제는 트윗에 있듯 "왜 언어(기호)의 해석에 비용이 많이 드는가" 입니다.

옐름슬레우에 관해 제가 주로 참조했던 내용은 다음과 같습니다.

소쉬르니, 퍼스니 아무 전제나 이해없이 설명하기가 버거워지네요.

키포인트만이라도 한번 정리하고 가는게 좋을 것 같습니다.

소쉬르의 기호학

소쉬르에 대해 설명하기 위해서는 랑그(Langue)와 파롤(Parole)를 우선 알아야 합니다.

랑그: 사회적이고 체계적 측면
파롤: 개인적이고 구체화된 발화 행위

김슬옹 교수, “세종과 들뢰즈의 언어관” 발표 주목받아

소쉬르는 사회적인 측면인 "랑그"에만 집중하였습니다.

앞서 배운 기표(Signifiant), 기의(signifié), 지시대상(Référent)이 나오게 되죠.

기표와 기의는 사회계약에 의한, 자의성을 띈다고 생각하였습니다.

La linguisterie inventée par Lacan

문장을 엮을때 방식은 결합과 계열로 분류하였습니다.

결합관계(Syntagme): 연관되어 결합 할 수 있는 관계 (And)
계열관계(Paradigme): 대체되어도 결합관계가 성립되는 관계 (Or)

[철학사40] 소쉬르(Saussure)

후에 나올 옐름슬레우는 관계와 상관이라 불렀습니다.

퍼스의 기호학

퍼스의 기호학은 표현체(Representamen), 해석체(Interpretant), 대상(Object)으로 이루어져 있습니다.

Sign Object Interpretant Symbol Reference ( Signifier ) Referent ( Signified ) “ Apple ”

(원본 이미지에서 Signifiant, signifié를 자른 이유는 소쉬르의 signifié는 Interpretant에 더 가깝기 때문에 그렇습니다)

또한 기호는 도상(Icon), 지표(Index), 상징(Symbol)로 구분되죠.

아이콘, 지표 그리고 심볼.

표현, 대상, 해석에 의해 기호작용(Semiosis, 세미오시스)이 일어나는 방법은 다음과 같구요,

보다시피 해석이 가장 중요합니다.

시각 도상의 언어적 속성에 대한 연구

연쇄적으로 일어날 경우 다음과 같은 양상을 띄게 됩니다.

서사적 상호작용 공간에서의 모달리티

아이콘, 인덱스, 심볼은 각각 이렇게 생각하시면 됩니다.

모양을 닮은 아이콘: 사과 아이콘은 사과 모양을 띄고 있다

모양을 기반으로 한 아이콘

인과를 가진 인덱스: 연기는 불, 기침은 감기와 같은 인과 관계를 떠올린다

인접/인과를 기반으로 한 인덱스

* 손가락으로 사물을 가르킬때처럼 인과 관계가 없을 경우, 퇴행적 지표라 한다.

관습에 의한 심볼: 알파벳은 유사성과 인과관계보다는 약속이나 관습에 기반한다

관습/자의성을 기반으로 한 심볼

물론 알파벳 자체는 이집트의 상형문자, 수메르의 설형문자처럼 모양을 기반으로 했다가 페니키아대에서 표의문자로 거듭난 사례이긴 합니다.

내용과 표현

위 글에서 소쉬르의 기표(signifiant)와 기의(signifié)를 차용해 설명한 이유는 쉽기 때문입니다. (단, 1:1 관계가 아니다를 설명하기 위해서와 기호체계 마다 다르다에 한정하여 사용했습니다)

옐름슬레우의 경우 명시적으로 표현(Expression)-내용(Content)을 정의하지 않았기 때문도 있죠.

그는 대신 기호함수(Sign function)을 중요시 여겼습니다.

소쉬르와 옐름슬레우의 기호

기호함수는 나중에 알아보고, 그렇다면 표현과 내용은 무엇이냐?

다행히 우리가 알고 있는 의미와 유사합니다.

'말'과 '글'은 표현이고, '설득'과 '사과' 는 내용입니다.

굳이 표현과 내용으로 나눈 이유는 자연어의 '의미'가 각 체계마다 달라질 수도 있기 때문입니다.

언어마다 포함하는 의미가 다른 예

그런데 중요한 점은 아주 명시적으로 둘을 구분하기 어렵다는 점입니다.

'표현 없는 내용'과 '내용 없는 표현'은 존재할 수 없다는 거죠. (상호의존성)

함수적 정의에 따르면, 둘 중 어느 하나를 반드시 표현이라고 부르고다른 하나를 반드시 내용이라고 불러야 할 이유는 없다.

HTML-CSS-Javascript는 각자 담고자 하는 내용에 따라 표현이 정해진 예입니다.

HTML을 Javacript에서 적절히 표혀하기 위해 JSX처럼 확장하기도 하고요.

저수준/컴파일 언어인 C, Rust의 표현과 고수준/인터프린터 언어인 Javascript, Python의 표현도 달라질 수밖에 없습니다.

이러한 측면에서 DSL의 부상도 이해할 수 있습니다.

그는 또한 함축적 기호학과 메타 기호학으로 분류합니다.

함축적 기호학은 단순히 표현-내용 배열인 소쉬르 지시기호학(외연, 기호 체계에 해당)과 차별화되며, 내연이 추가적으로 존재합니다. 내연에 관해 보다 집중한 사람은 퍼스입니다. [외연: 표현-내용 포함 + 내연]

메타적 기호학은 언어를 기호 체계로 취급합니다. 언어를 기호 체계로 취급함은 용어가 표현이고, 내용이 언어 자체에 대한 기호 체계를 가짐을 말합니다. [외연 + 내연: 표현-내용 포함]

함축적/메타적 기호학, 외연(외시, Denotation)/내연(공시, Connotation)

함축적 기호학의 내용 측면은 다음과 같은 것을 다룹니다.

함축적 기호학의 내용

어째서 'speech', 'writing'처럼 표현으로 보이는 것이 내용에 나오냐고요?

후에 등장할 '형식-실체-요지'에서 설명할 예정입니다.

롤랑바르트는 함축적 기호학을 1차적 의미, 2차적 의미로 말합니다.

신화의 경우, 이데올로기를 포함하구요. (여기서 또 마르크스가..)

롤랑 바르트

다음은 실제로 의미를 적용한 사례입니다.

늠름하게 경례하는 프랑스 흑인 청년에서 확장되어 피부색 차별없이 프랑스 국기 하에서 봉사하며, 이는 제국주의와 식민주의를 옹호하기 위해 사용됩니다. (+1950년대 임을 상기합시다)

번외_'롤랑 바르트'는 누구인가 / 롤랑바르트 '의미작용'

형식-실체-요지

잠시 샛길로 갔습니다만 다시 돌아와봅시다.

바로 위 롤랑바르트 이론에서 외연[2차적 기표]은 형식(Form), 내연[2차적 기의]은 개념(Concept)으로 사용되고 있습니다.

그렇다면 옐름슬레우와의 차이점은 무엇일까요?

롤랑바르트가 다양한 상황에서 2차적 의미와의 관계에서 기호에 초점을 맞추는 반면, 옐름슬레우는 언어이론과 형식에 관심을 가졌다.

또한 롤랑바르트의 2차적 의미는 상황과 특수성이 중요한 역할을 하는데, 옐름슬레우는 상황을 따로 구분하여 처리합니다.

어떻게 하는가?

이 챕터의 형식(Form)-실체(Substance)-요지(Purport)입니다.

또한 그에 따르면 기호함수(Sign function)에 의해 표현-내용에 대해 동형적으로 동작합니다.

형식: 함수의 값이 정해지는 표명(manifestation)에서 상수적 역할을 함, (Schema)
실체: 형식에 의해서만 존재할 수 있으며, 표명에서 변수적 역할을 함
요지: 공통된 요인(factor)이나 함수에 의해서만 정의되고 형식화되지 않은 무형의 사고 덩어리 (질료)

쉬이 말하면, 잠재적 사고에 형식이 투영되며 실체가 생겨난다(실현)는 것입니다.

객체지향 시스템과 패러다임 그리고 철학에서 "없다면 실체를 생각할 수 없는 것"의 연장선상인 말입니다.

프로그래밍에 적용해도 비슷하겠습니다.

내용-요지: 만들고자 하는 프로그램에 대한 잠재적 사고
표현-요지: 형식화 되지 않은 잠재적 프로그래밍 언어
내용-형식: 적절한 형식의 내용인 자료구조와 알고리즘
표현-형식: 표현방식인 프로그래밍 언어의 문법
내용-실체: 해당되는 로직구현
표현-실체: 프로그래밍 언어로의 표현

여기서 혼동이 될 수 있는 점은 기호함수에 따라 표현과 내용의 자리가 바뀔 수 있다는 것이죠.

만약 프로그래밍 언어 개발자라면 내용이 프로그래밍 언어이고, 표현은 로직이 됩니다.

좋다. 그렇다면 2차적 의미가 어떠한 식으로 적용되는가?

각각의 측면에 모두 작동하는 방식입니다.

위와 같다고 한다

프로그래밍으로 동작하는 서비스도 2차적 의미를 가지고 있겠죠?

‘기쁨 강박증’ 스트레스…SNS에선 모두가 행복?

마지막으로 그의 기호학 계층에 대한 시각화..?를 보고갑시다. ~~무서워요~~

The Semiotic Hierarchy

음성/음운, 의미론/통사론등 언어를 본격적으로 다루지 않았음에도 기호란 이렇게 복잡합니다.

그래도 살짝만 보자면 바로 저희가 배웠던 모양이 등장함을 알 수 있어요.

언어의 구성 요소 (feat. 음운론, 형태론, 통사론, 의미론, 화용론), 바람직한 언어 교육, 화용론이란 무엇인가

또한 들뢰즈 가타리의 철학과도 연결시킬 수 있는데 이는 ‘도덕의 지질학’에 수용된 과정에 잘 설명되어있으니 생략합니다.

왜 언어(기호)의 해석에 비용이 많이 드는가

현재 언어해석과 생성에서 최첨단을 달리는 LLM(Large Language Model)은 엄청난 크기와 비용을 필요로 합니다.

2018년에 거대한 사이즈였던 BERT(3억 4천만), GPT(1억 1천만)도 지금은 피라미에 불과합니다.

2023년 기준 PaLM-e(5600억), 작아도 LLaMA(65억 파라미터) 스케일이기 때문입니다.

슬슬 원리가 나오고 있다지만 일정크기의 파라미터를 넘어서면 어째서 새로운 기능이 나오는지는 아직 모릅니다.

물론 반쯤 당연하게도..? 상식은 네트워크 넓이, 추론은 네트워크 깊이의 영향을 받는다하고 좋은 품질의 데이터를 사용하면 적은 파라미터로도 좋은 결과를 낸다고는 합니다.

1000억 파라미터를 전후하여 무엇인가가 일어났다. 모델의 구조와는 상관없이, 1천억 파라미터를 넘기는 어떤 시점부터 언어 모델은 말을 이어 지어내는 것을 넘어 기대하지 않았던 일을 하기 시작했다. 충분히 큰 모델들은 컨텍스트를 유지한채로 복잡한 일들을 처리할 수 있었다. 컨텍스트 내 학습 (in-context learning)이라고 부르는 현상은 모델 훈련 없이도 여러 지식을 즉석에서 학습하고, 논리적인 결론을 유도할 수 있었다.

적은 파라미터라고는 하지만 BERT 급만해도 모바일이나 노트북에서 돌리기 어렵습니다.

그렇다면 다른 방식의 인공지능 방식들은 없나 싶지만 당연하게도 있습니다.

The Many Tribes of Artificial Intelligence (AI)

마스터 알고리즘

이 중에서 가장 대표적인 2개가 고전적인 기호주의와 현 LLM 모델의 철학적 기반인 연결주의입니다.

Symbolism vs. Connectionism: A Closing Gap in Artificial Intelligence

기호주의는 계산주의(Computationalism)라고도 불리는데 저는 계산주의라는 용어를 선호합니다.

왜냐하면 관계를 나타내기 위한 명시적인 룰을 기반으로 하기 때문에 그렇습니다.

Existential Graph와 시맨틱 네트워크

그러나 앞서 기호론을 살펴보았을때 명시적인 룰을 기반으로 동작하던가요?

그렇지 않습니다. 때문에 기호주의라기보다는 계산주의라 부르는게 합당하다는 거죠.

오히려 확률을 기반으로 예측하는 연결주의가 언어와 기호의 표현에서 낫습니다.

앞서 나왔던 내용을 정리해볼까요?

뉴럴 네트워크

지시대상 - 표현 - 내용은 각각 다대다 관계임
표현과 내용은 상호의존성을 가지고 있으며 서로 치환이 가능
표현과 내용이 실체화 될때 요지에 형식이 투영되며, 동시적으로 생성
기호를 해석할 때, 외연(1차적)-내연(2차적)이 합쳐져 의미가 작용할 수 있음
함축적 기호학과 메타적 기호학으로 나뉠 수 있음

비트겐슈타인 언어게임이나 들뢰즈의 기계 개념처럼 각 컨텍스트에 따라 다르게 구성될 수 있으며, 이는 룰 베이스보다는 확률에 따른 생성에 가깝다는 말입니다.

GPT 언어 모델, 에이닷에 적용된 거대언어모델 GPT-3가 무엇일까?

엄청난 양의 도메인 지식에 대한 적절한 탐색 속도는 물론, "요지"와 같이 비형식적 부분, 각종 중의적/은유적 표현과 말장난, 농담까지 모두 룰베이스로 처리하기 어렵다고 생각합니다. 제게는 마치 컴파일 타임에 모든 것을 해결하려는 것처럼 보입니다.

보다 네이티브하게 다룰 수 있을 비결정론적 튜링머신이 만들어지면 모를까요.

몇가지 잡생각들

계산비용

그렇다고 LLM이 모든 것을 잘 해줄거야는 또 이치에 맞지 않습니다.

스마트폰보다도 느린 프로세서에 1GB램도 안달린 공학용 계산기의 solve() 기능을 현재 LLM이 더 빠르게/정확하게/전력 효율적이게 처리해줄 수 있을까요?

아니죠.

인간의 의사결정과정에서도 비슷한 고민이 있어 나온 듀얼 프로세싱 모델로 ELM(Elaboration likelihood model)과 HSM(Heuristic-systematic model of information processing)이 있습니다.

ELM은 관여도에 따른 중심-주변경로, HSM은 휴리스틱에 따른 시스템1-시스템2로 나뉘어집니다.

이 중 구글은 HSM에 영감을 받아 수학/코딩/논리/추론이 더 좋아졌다고 합니다.

2가지의 사고 모드 (시스템 1, 시스템 2)

근데 이상하죠?

"추론"과 "계산" 과정은 비용이 더 들어가야 하는데, 계산기는 추론시 비용이 적습니다.

빠르고 무의식적인 시스템1, 제어적이고 규칙기반인 시스템2가 섞여 있는듯이 보이네요?

대규모 언어 모델(LLM)은 예측 엔진과 같습니다. 프롬프트가 주어지면 다음에 나올 단어를 예측하여 응답을 생성합니다. 결과적으로 그들은 언어와 창의적인 작업에 매우 능숙했지만 추론과 수학 같은 영역에서는 약했습니다. 고급 추론 및 논리 기능으로 더 복잡한 문제를 해결하는 데 도움이 되기 위해서는 LLM 출력에만 의존하는 것만으로는 충분하지 않습니다.

이 비유에서 LLM은 순전히 시스템 1에서 작동하는 것으로 생각할 수 있습니다. 텍스트를 빠르게 생성하지만 깊은 생각은 하지 않습니다. 이것은 몇 가지 놀라운 기능으로 이어지지만 몇 가지 놀라운 면에서 부족할 수 있습니다. (시스템 1만 사용하여 수학 문제를 풀려고 한다고 상상해 보십시오. 중단하고 산술을 할 수 없습니다. 마음에 떠오르는 첫 번째 답을 뱉어내면 됩니다.) 전통적인 계산은 시스템 2 사고와 밀접하게 일치합니다. 융통성이 없지만 올바른 단계의 순서는 긴 나눗셈에 대한 솔루션과 같은 인상적인 결과를 생성할 수 있습니다.

이 최신 업데이트에서는 LLM(시스템 1)과 기존 코드(시스템 2)의 기능을 결합하여 Bard 응답의 정확성을 개선했습니다. 암시적 코드 실행을 통해 Bard는 논리적 코드의 이점을 얻을 수 있는 프롬프트를 식별하고 "내부적으로" 작성하고 실행한 후 그 결과를 사용하여 보다 정확한 응답을 생성합니다. 지금까지 우리는 이 방법이 내부 챌린지 데이터 세트의 계산 기반 단어 및 수학 문제에 대한 Bard의 응답 정확도를 약 30% 향상시키는 것을 확인했습니다.

우리가 구구단이나 공식을 외우고서는 계산이 빨라지듯, 기계 입장에서도 규칙적 -> 자동적으로 시스템1 영역인 것 입니다.

그치만 단순한 계산이나 코드 실행처럼 딱 정해진 도메인에 대한 판단은 기존 LLM의 영역보다 더 빠르며 다른 특성을 가지고 있습니다.

무언가 달리 표현할 말이 필요하겠네요.

제가 생각한 것은 "경험적 종합 판단"영역에서 "선험적 종합 판단"영역으로 Pre-Training한 무언가 일 겁니다.

https://forum.owlofsogang.com/t/topic/1617/4

"직관들에 의한 선험적 종합 인식" 이 무엇인지 모르겠습니다

제가 비전공자라 확실하게 이해하고 있는지는 모르겠습니다만, 백종현님이 작성하셨던 다른책을 읽어본 경험을 말미암아 이해할때 다음과 같았습니다. 틀린 부분이나 보충할 내용이 있다면 해

forum.owlofsogang.com

System2를 기반한 추론으로 선험적 계산 엔진 생성
System1의 프롬프트를 학습시킬 때, 계산 엔진을 Literal로 이용할 수 있도록 함
System1에서 추가적으로 추론이 필요한 경우 System2를 이용하도록 함

외적탐색

지금까지 우리는 내적탐색을 위주로 생각해보았습니다.

선험적: 미리 정의되어 사용할 수 있는 최적화된 기능들 (프리미티브로 사용)
경험적(System 1): 직관적 언어 사용
경험적(System 2): 추론적인 사고

하지만 내적탐색으로 정보가 안나오거나 실시간 정보를 반영하려면 BingChat처럼 외적탐색이 필요하겠죠.

소비자행동론. 핵심은 관여도와 준거집단

BingChat 레퍼런스 기능은 정말 좋은데 현재 아쉬운 점은 검색된 정보에 너무 의존한다 느껴진다는 것입니다.

현재 페이지나 PDF를 기반으로 알려주는 내용들은 요약 정도
검색해서 알려주는 내용도 검색에 대한 요약 느낌
ChatGPT와 비교해 전반적으로 스스로 생각하여 정보를 준다는 느낌이 적음

아무튼 ChatGPT도 오픈 도메인 엑세스를 잘 하던 Watson을 본받았으면 합니다. [IBM Watson 작동방식에 대한 이해 및 사례 소개]

Watson은 검색엔진말고도 다양한 분야의 지식에 접근하여 활용가능 했었거든요.

Wolfram|Alpha as the Way to Bring Computational Knowledge Superpowers to ChatGPT, Jeopardy, IBM, and Wolfram|Alpha

그래서 정리해보면 근미래에 출연할 LLM 서비스의 모습은 다음과 같이 구성되지 않을까 싶습니다.

System 1: 시스템이 이용할 선험적 기능들
System 1: 직관적 언어모델
System 2: 추론적 사고 모델
System 2: 외적 탐색 모델

아마 그 후에는 메타인지 문제가 다루어지지 않을까.

논어 위정편

아래 글이 상대적으로...쉬웠..죠?

혹시 이해가 안됐다면 "아~ 완벽히 이해했어!"라고 하는걸로. ~~사실 저도 아무 생각이 없습니다~~

샛별, 위키낱말사전, 2020 [본문으로]
페르디낭 드 소쉬르, 일반언어학 강의, 김현권 역, 철학의 정원, 2022 [본문으로]
질 드뢰즈 & 펠릭스 가타리, 천개의 고원, 김재인 역, 새물결, 2003 [본문으로]
루트비히 비트겐슈타인, 철학적 탐구, 이승종 역, 아카넷, 2020 [본문으로]
정순영, 김창렬 H푸드’에 손배소 “'창렬스럽다'는 '혜자스럽다'의 반대 뜻?”, 아주경제, 2015 [본문으로]
이승아, 잎사귀만 봐도 거품 무는 '애플'... 세상 사과가 다 제 것인가?, 조선일보, 2021 [본문으로]
김가영, ‘혜자롭다’X‘창렬하다’ 뭉쳤다… 누리꾼 “신선한 조합”, 동아일보, 2017 [본문으로]
장 보드리야르, 시뮬라시옹, 하태환 역, 민음사, 2001 [본문으로]
김소정, 아무렇지 않게 쓴 ‘창렬하다’…김창열 가족들은 13년째 ‘속앓이’, 조선일보, 2022 [본문으로]
질 들뢰즈, 차이와 반복, 김상환 역, 민음사, 2004 [본문으로]
Maslow, Abraham H, Critique of self-actualization theory, Thousand Oaks, 1996 [본문으로]
Maslow, Abraham H, The farther reaches of human nature, New York: The Viking Press, 1971 [본문으로]
김재인, 들뢰즈의 비인간주의 존재론, 서울대학교 대학원, 2013 [본문으로]
질 드뢰즈 & 펠릭스 가타리, 안티 오이디푸스, 김재인 역, 민음사, 2014 [본문으로]
보건복지부 국립정신건강센터 & 대한신경정신의학회, 거식증, 국가정신건강정보포털, 2021 [본문으로]
西川善司, 「ゼルダの伝説BotW」の完璧なゲーム世界は，任天堂の開発スタイルが変わったからこそ生まれた, 4Gamer.net, 2017 [본문으로]
김경일, “조언해달라”는 말로 회의 시작해 보라 평범했던 직원의 잠재력이 터진다, 동아비지니스리뷰, 2019 [본문으로]

대략적인 금융 계획.

BlaCk_Void — Mon, 30 Jan 2023 11:34:31 +0900

내년 이 맘때 쯤에는 시간이 없을 듯 하여 미리 적어 놓은 내용을 다른분들께 도움이 될지는 모르겠지만.. 몇글자 적어봅니다.

개개인의 자산, 소비패턴등은 다르기 때문에 권장할 수는 없겠지만 필요하신분은 참고하십셔.

대부분 널리 알려진 아주 기초적인 정보입니다.

* 본 글은 투자권유가 아니며, 각 개인의 투자 판단에 대한 책임을 지지 않습니다.

0. 포인트

쓸 내용이 없어서 먼저 쓴다.

당연한 소리겠지만 정형화된 소비 패턴이 있거나 많이 소비하는 경우 해당 업체의 포인트/마일리지를 적립하면 도움이 된다.

관련 어플을 깔면 쿠폰등의 할인등도 있을 수 있으니 소비패턴에 맞춰 알아서..

간헐적인 소비를 한다면 그다지 의미있는 행동은 아니다.

간편 결제를 사용해 추가적인 포인트를 얻을 수 있겠다.

1. 카드

신용 vs 체크

카드 사용에서 첫번째 관건은 신용카드냐 체크카드냐의 선택의 기로다.

내년 취업을 예상하고 쓰는 글이라 근로소득이 있어 발급이 가능하다 가정하며, 저는 과잉소비는 거의 하지 않는 성향이므로 연체에 대한 가정 또한 하지 않는다.

그렇다면 관건은 다음과 같을 것이다.

체크카드

총 급여 25%가 넘을 시 소득공제 비율이 높음
(체크카드와 현금영수증: 30%, 신용카드: 15%)
연회비 없음

신용카드

각종 혜택
할부 가능

보통 사회초년생이 비싼 연회비가 있는 카드를 사용하지는 않을 것이므로,

총 급여 25%가 넘어 소득 공제를 받을 수 있는가와 카드 혜택이 주요 쟁점이다.

이건 일단 취업후 소득과 변경된 소비패턴에 맞춰 다시 계산해봐야 하겠지만 소비를 많이 한다면 체크카드, 적게 한다면 신용카드가 유리할 것으로 보인다.

또한 혜택의 경우 보통 전월실적을 따지므로, 이 역시도 고려가 필요.

할부에 대해서도 여러 의견이 있겠지만 소비습관 통제와 절제가 가능하다면 나쁘지 않다고 생각한다. (현금흐름을 조절할 능력이 있다면 잉여자본으로 레버리지도 가능하니)

카드 혜택

역시 본인의 소비 패턴에 맞추어 발급 받기가 첫번째.

또 다른 고려사항으로는 할인형인지, 적립형인지 고르기다.
기본적으로 적립식의 혜택이 크나, 소액결제가 많으면 절삭이 있는 할인식이 좋을수도 있다.
또한 포인트 유효기간은 보통 5년이며 사용할 수 있는 곳도 제한되는걸로 알려져 있다.

2. 세금

연말정산

먼저 용어부터 알아봅시다.

홈텍스의 용어사전에 잘나와있다.

연말정산: 연간 종합소득산출세액에서 세액공제, 면제세액 및 이미 납부한 원 천징수세액을 차감하여 그 차액을 추가로 원천징수하거나 환급하는 절차
공제: 과세에 있어서 중복과세 등의 부담이나 부담의 불공평을 피하기 위하여 중복부분 등을 계산하여 차액을 빼는 것

연말정산의 계산은 다음과 같이 이루어진다.

연말정산은 세금을 부과하는 총급여액을 기준으로 계산하므로, 비과세 근로소득을 제외 [비과세 급여에는 어떤 것이 있고, 소득자에게 어떤 영향을 주나요?]
총급여액에서 근로소득공제를 차감
근로소득금액에서 종합소득공제를 차감 [소득공제 기초]
과세표준에서 세액공제를 차감 [세액공제 기초, 세액공제, 특별세액공제]

자동적으로 계산되는 금액을 제외하고, 우리가 신경써볼만한 요소들을 알아보자.

비과세 근로소득

자기차량 운전보조금, 출장비/숙직비, 국외근로, 생산직, 식대, 보육수당, 학자금 등이 있다.

난 식대 월 20만원 정도만 혜택받을 수 있을 듯.

종합소득공제

크게 인적공제, 주택자금공제, 사용금액 공제, 기타소득공제로 나뉘어있다.

우선 가정을 꾸리지 않았으므로 인적공제는 크게 의미가 없을듯 하다.

대신 다음 항목들은 눈여겨 볼만하다.

주택자금공제의 주택청약종합저축
사용금액 공제의 모든 항목들
기타소득공제의 개인연금저축

투자에 가까운 주택청약종합저축, 개인연금저축은 뒤에서 다룰 예정이고, 카드사용에서 살짝 언급되었던 사용금액 공제에 대해 집중적으로 살펴보도록 하자. [신용카드 등사 용액 소득공제]

공제금액: (전통시장사용분+대중교통이용분+현금영수증, 직불ㆍ선불카드등사용분+신용카드사용분) - 최저사용금액
공제순서 : 신용카드사용분 → 현금영수증, 직불ㆍ선불카드사용분 → 도서·공연·박물관·미술관 사용분(총급여 7천만원 이하자만 해당) → 전통시장사용분, 대중교통이용분 → 소비증가분

만약 부양가족이 있다면 인적 공제와 의료비 공제도 체크해보도록 합시다. [꼭 알아야 할 연말정산 절세 꿀팁 7가지]

세액공제

세액공제에는 자녀세액공제, 연금계좌세액공제, 보험료, 의료비, 교육비, 기부금, 월세액정도로 나뉠수 있다.

자녀가 없으니 자녀세액공제, 학교를 다니지 않을테니 교육비는 고려하지 않아도 될 것이다.

연금계좌와 월세액은 소득공제때처럼 추후에 따로 다루기로 한다.

보험료: 12% (한도: 연 100만원)
의료비: 15% (총급여액의 3% 초과시)
기부금

청년정책

찾아보면 청년 어쩌고 정책이 참 많다.

활용할 수 있다면 최대한 활용하자.

찾아보니 대표적인 지원은 다음과 같은 듯.

내일배움카움카드는 직무관련 교육을 들을때 할인받을 수 있는데 내게는 딱히 의미가 없어보인다.

취업지원제도의 경우 취업장려금 50만원을 6개월에 걸쳐주며, 취업성공시 최대 150만원을 추가로 주므로 가능하다면 해보는 것도 좋을듯하다.

구청에서도 취업장려금을 주는 경우가 있으므로 한번쯤 검색해보기 바란다.

꿀 사업으로는 내일채움공제 시리즈가 있다.

보면 알겠지만 적은 리스크에 비해 수익성이 매우 좋은 편이다.

내일채움공제와 청년내일채움공제 간단 비교

단, 올해부터 청년내일채움공제의 대상이 줄어서ㅠㅠㅠ

청년재직자 내일채움공제를 노려야 할 것 같다.

2023년 달라지는 청년내일채움공제

혜택이 다소 적지만 청년도약계좌는 월 70만원씩 5년간 납입하여 4200만원을 만들면 정부가 최대 6% 매칭지원금을 주고, 이자와 배당에 대한 소득을 과세하지 않는다. [청년도약계좌, 소득 7천500만원 이하면 이자·배당 비과세]

아직 출시가 되지 않아서 변경의 여지는 있지만 추후에 나올 ISA(개인종합자산관리) 계좌의 상위호환에 가깝다.

희망두배 청년통장 / 청년저축계좌 / 청년희망키움통장등도 있지만 기본적으로 저소득층이 대상이라 가입조건이 매우 까다롭다. [2021년 희망키움통장1,2,내일키움통장,청년 희망키움통장,청년 저축계좌 비교]

3. 주택

한국에서 부동산은 투자의 대상으로 인식되고 있다.

실제로 2022 한국 부자보고서에 따르면 부동산으로 수익을 얻은 10이상의 금융자산가들이 많다.

개인적으로 토지공개념을 적용해 부동산으로 이익을 최대한 제한하고 주식/채권등으로 사회적 부가가치 창출을 유도하는게 맞다고 생각하나, 정보의 비대칭성과 일부 대주주에 의해 주주민주주의가 훼손되는 사례가 많은 국장환경이 개선되지 않는 이상 계속 매력적인 투자대상으로 인식되라 예상한다.

개인적 합리성에 의해 사회적 비합리성이 나타나는 안타까운 현실.

월세액 & 대출

어쨌든 무주택자를 위한 정책이 몇가지 존재한다.

먼저 월세액 세액공제. ['월세액 세액공제'의 모든 것]

12% (최대 90만원)

청년전용 버팀목전세자금은 싼 이자로 대출 받을 수 있다.

최근 금리를 고려했을때 엄청난 이득.

연 1.5~2.1% (최대 2억원)

구매하려는 사람은 내집마련디딤돌대출을 사용할 수 있다. [버팀목대출과 디딤돌대출 100% 활용 방법]

포인트는 고정금리와 변동금리 선택이다.

연 2.15~3% (일반 2.5억원)

주택청약

집을 구매할때 이용할 제도는 모두가 아는 주택청약이다. [[주택청약 길라잡이]① '주택청약 1순위' 되기 위한 기본 조건은? , 주택청약, 매 달 얼마씩 넣어야할까?]

시기, 지역, 인프라 등등이 모두 중요하겠지만 당장은 예측하기 힘들테구, 정해지기 전까지는 주택청약종합 저축을 하는게 좋다.

여기서도 청년우대형 주택청약종합저축이 있다.

최대 연 3.6%에 소득공제(연 240만원 한도)가 주어진다.

지금은 고금리 시대라 청약 순위를 위해서 넣겠지만, 0.5~1%밖에 안되었던 때는 매우 매력적이었다.

4. 예적금

계속 한 말이지만 기준금리가 높으므로, 예적금 또한 매력적인 투자대상이 되었다.

이때 미세팁.

세금우대종합저축을 활용해 3000만원까지는 농어촌특별세 1.4%만 내자. [예금절세가이드, 올해가 마지막 기회…돈 넣어만 두면 年 7% 이자 준다는데]

일반적인 경우 2000만원 이하 금액에는 15.4%(지방소득세 포함), 초과분은 최대 49.5%까지도 세율이 적용된다.

단, 상호금융 기관에서만 가능하다는 점 알아두길 바란다.

5. 연금저축 vs IRP vs ISA

정석대로라면 연금저축 -> IRP -> ISA순으로 투자하라는 말이 있다.

그러나 연금저축, IRP는 만 55세까지 유지해야만 한다는 엄청난 단점이 있다.

주택, 차등 때문에 몫돈이 필요할 수 있는 상황에서 4~5년도 아니라 20년 넘게 기다리기에는 현금 유동성에서 손해가 크다.

앞에서 나온 공제, 도약계좌등에 넣기만으로도 벅찬 상황에 추가적으로 운용하기에는 부담이 갈 수 있다.

따라서 나는 ISA를 우선시하는게 낫다고 생각한다.

주식매매차익 5000만원 이상일때 비과세며, 배당/이자도 200만원 초과시에 9.9%로 엄청난 절세효과가 있다. (보통의 경우 넘기기 쉽지 않다)

또한 만기후 IRP 계좌로 이체하더라도 10%(300만원 한도)를 세액공제받을 수 있다.

투자가능한 상품에도 미묘한 차이가 존재하는데 꼭 숙지해두도록 하자.

연금저축: 투자가능상품이 제한되나 운용제한이 없음
IRP: 투자가능상품이 비교적 자유로우나 70%까지만 위험자산에 투자가능
ISA: 투자가능상품이 해외주식을 제외하면 대부분 가능

6. 주식, 채권

용어

대부분은 아시겠지만 이 정도는 참고하시라 적어둔다.

주식 vs 채권

직관적인 예적금을 제외하고 보통 투자라함은 주식과 채권을 의미하는 경우가 많다.

주식: 구매한 사람은 의결권을 가진 주주가 되며, 시세차익과 배당수익을 가짐 [회사입장: 자본금]
채권: 구매한 사람은 채권자가 되며, 시세차익과 이자수익을 가짐 [회사입장: 부채]

소액투자가 입장에서 주식과 채권에서 가장 중요한 차이는 안정성이다.

채권을 구매한 사람은 말그대로 채권자가 되기 때문에 부도가 나지 않는한 이자수익과 만기시 액면가가 보장된다.

또한 회사의 해산시 우선하여 원리금을 받을 수 있는 상대적 안전자산이다.

파생상품

뭉그러뜨렸을때 유명한 파생상품으로는 ETF(상장지수펀드, Exchange Traded Fund)와 ETN(상장지수증권, Exchange Traded Note)일 것이다.

ETF: 일종의 상장된 펀드로, 포트폴리오대로 지수추종을 가능하게 만들어준다. [추적오차: 고객 부담]
ETN: 일종의 상장된 채권으로, 기초지수의 수익률을 그대로 지급하는 것을 약속한다. [추적오차: 증권사가 부담]

자동적 분산투자와 공매도에 상대적으로 제한적인 개인의 입장에서 가격이 떨어짐에 배팅할 수 있는 인버스가 있다는 점에서 꽤 매력적이다. (기관은 상환기간 무제한에다가 2023년임에도 공매도를 수기로 관리하는 곳이 있다는게 참 ㅋㅋ...)

위험적 특성으로는 레버리지, 괴리율, 롤오버 효과가 있다.

예전 마이너스 원유 사태때 위 특성을 모르고 샀다가 손해본 사람들이 굉장히 많았던 걸로 기억한다.

ELS(주가연계증권, Equity Linked Securities)과 DLS(파생결합증권, Derivative Linked Securities)도 주목할만한 하다.

ELS: 개별 주식이나 주가 지수에 따라서 수익률이 결정되는 유가증권
DLS: 이자율, 통화, 실물자산(금, 원유 등), 금리 등 주가 지수가 아닌 다른 걸 기초자산으로 수익률이 결정되는 유가증권

ELS가 ETF와 비슷해보이지만 다른 점은 장외 거래 상품이며, ETN과 같이 만기가 있다.

보통 채권에 투자해 안정성을 유지하며, 동시에 주식/옵션에 투자해 수익성을 추구한다.

검색해보면 이름이 많이 나와서 헷갈리죠? [ELS, ELB, DLS, DLB]

주식/주가지수와 연계(Linked)가 되면 E(Equity), 나머지(이자율, 통화, 실물자산등)와 연계되면 D(Derivate)가 앞에 붙는다.

원금이 보장되지 않으면 S(Securities), 보장되면 B(Bond)가 끝에 붙는다.

원금 보장형(ELB/DLB)은 채권으로 약정 수준의 원금을 확보후 주식과 파생상품에 투자해 초과이익을 얻는 형태다.

상승 낙아웃과 하이파이브 형이 있다.

상승 낙아웃 형, 하이파이브형

상승 낙아웃
- 만기에 주가가 하락해도 원금보존추구(A)
- 최초기준가격과 만기평가가격을 비교하여 참여율에 따라 지급금액 결정(B)
- 단, 투자기간 동안 배리어 가격을 초과한 적이 있는 경우, 만기에 주가 수준과 상관없이 리베이트 수익률로 확정(C)
하이파이브(오토콜)
- 만기 3년, 매 6개월마다 기초자산이 배리어가격 이상이면 원금과 수익을 지급하고 조기상환(A)
- 만기평가일까지 상환 조건 미달성 시, 투자기간 동안 한계가격 미만으로 하락한 적이 없으면 원금과 수익지급(B)
- 투자기간 동안 한계가격 미만으로 하락 한 적이 있고 만기상환 조건 미 충족 시 만기에 원금 지급(C)

원금 비보장형은 원금보장형과 반대로 일정부분을 기초자산/파생상품에 직접 투자하고 나머지를 채권에 투자하는 방식이다.

스텝다운형:
- 만기 3년, 매 6개월마다 기초자산이 배리어가격 이상이면 원금과 수익을 지급하고 조기상환(A)
- 만기평가일까지 상환 조건 미달성 시, 투자기간 동안 한계가격 미만으로 하락한 적이 없으면 원금과 수익지급(B)
- 투자기간 동안 한계가격 미만으로 하락 한 적이 있고 만기상환 조건 미 충족 시 만기 손실(C)

일일손익 원금비보장형
- 투자기간 동안 기초자산 주가를 매일 관찰해 주가가 배리어 가격 이상의 날에 대해 절대수익률을 제공하고 배리어 미만 구간의 손익에 대해서는 기초자산의 실물을 직접 상환해 향후 주가 회복에 따른 손실만회 기회를 제공
- 손익이 일 단위로 계산되고 매 분기에 이를 합산한 금액을 투자자들에게 지급함으로써 안정적인 수익 추구와 재투자 기회 제공
일일손익 원금부분보장형
- 투자기간 동안 기초자산 주가를 매일 관찰해 주가가 배리어 가격 이상의 날에 대해 절대수익률을 제공하고 배리어 미만 구간에 대해서도 만기 주가에 따라 최대손실률은 제한하면서 주가 상승 이익을 100% 향유함으로써 수익성을 제고시킨 상품

기타 용어 참고.

마지막으로 잘못 투자하면 계좌가 녹기로 악명높은 선물과 옵션..

선물: 현재 시점에서 약정한 가격으로 미래의 일정 시점에 특정자산을 사거나 팔기로 약정하는 거래
옵션: 미래의 특정 시점 또는 특정 기간 동안에 정해진 가격으로 기초자산을 매매할 수 있는 권리를 사거나 파는 거래

주식과 달리 예수금 이상으로 -가 될 수 있으므로 조심해야 한다.

투자비율과 사이클

투자하는 사람의 많은 고민은 포트폴리오와 투자비율일 것이다.

보통 나이가 젊을수록 투자, 많으면 안전자산의 비율을 늘리길 권한다.

여기 좋은 시리즈가 있어 링크를 모아봤다.

포트폴리오의 구성도 중요한데, 경기의 사이클에 따라 수익이 달라지니 비중을 달리할 수 있겠다.

안전하게 장기투자를 할 예정이라면 레이달리오의 포트폴리오를 확인해보아도 좋다.

코스톨라니 달걀모형으로 보는 거시경제, 레이달리오처럼 투자하기, ETF로 하는 법

주식거래의 경우 일반적으로 매입/매도시 분할로 하며, 여러 종목에 분산투자를 하는게 기본이다.

또한 안정성을 높히기 위해서는 하나의 업종/테마에 집중이 아닌 여러개로 분산이 바람직하다 할 수 있겠다.

WICS(Wise Industry Classification Standard)가 업종을 구분하는 보편적 방법으로 알려져 있으니 확인해보길 바란다.

미국의 섹터별 유명 기업은 finviz에서 한눈에 볼 수 있다.

인베스팅이나 Financial Juice도 소식 보기 좋은 곳이니 참고하기 바란다.

주식에서도 반도체(삼성전자/하이닉스)는 특히 사이클의 영향을 크게 받으니 주의가 필요할 듯 하다.

금리

거시경제에서 중요한 요소 중 하나는 바로 금리이다.

'돈의 가격' 금리…올리면 정말 물가·집값이 잡힐까

보통 금리가 올라가면 환율이 내려가고, 금리가 내려가면 환율이 올라가는 형태를 보인다.

그러나 나라마다 상대적으로 매겨지기 때문에 절대적이지 않다.

마찬가지로 원론적으로 따지자면 금리가 내려갈 시 대출 부담이 줄어들어 투자와 소비가 늘어나 주가가 올라가야 하지만

경기가 안좋다면 주가가 상승하지 않을 수도 있다.

업종으로 생각하면 금리가 올라갈 때 은행과 보험은 대출이자와 채권으로 이득을 보는 한편, 부채 비율이 높은편인 조선업, 건설업에 불리한 편이다.

환율로도 생각해보자.

환율이 올라가면 수출업종에게 유리해지고, 수입이나 원자재, 항공주는 악재일 가능성이 높다.

외인들의 경우 역시 올라갈거라 예측되면 주식을 팔고, 내려갈거라 예측되면 한국 주식을 매입하는 편입니다.

재무재표와 지수

거시적 지표

주식시장이 과열인지 저평가인지를 확인하는 주된 방법들입니다.

버핏지수: 시가총액 / GDP로 7~80%면 저평가이며 100~125%면 적절하다고 판단 [버핏지수 확인]
CAPE(쉴러 PE): 아래 나올 PER과 비슷하며 미국의 경우 20~30 정도가 적절한 값으로 판단 [CAPE 지수 확인]
VIX 지수: 시카고 옵션거래소 변동성 지수로 20 미만이면 안정적, 30이상이면 공포로 인한 변동성이 크다 판단 [VIX 지수 확인]
Fear&Greed 지수: VIX + a로 만들었으며 공포와 탐욕이 직관적으로 표시되어 있음 [Fear&Greed 지수 확인]

재무제표

몇가지 지수

PER, PBR, ROE를 통해 가치가 과장되었는가를 생각해볼 수 있다.

PER: 주가 수익 비율로, 1주당 수익이 몇 배가 되는지 [낮다면 저평가]
PBR: 주가 순자산비율로, 자산 대비 1주당 주가가 몇 배인지 [낮다면 장부가치보다 주가가 낮음]
ROE: 자기 자본 이익룰로, 자본 대비 얼마나 이익을 냈는지 [높다면 마진을 많이 남김]

기술적 지표

상대적으로 중요성이 낮지만 이 정도는 알아가는게 좋다.

기술적 지표는 인베스팅이 보기좋게 나온 듯 하다.

해외주식

해외주식 250만원 넘게 벌었다면…'손실 종목' 팔고 다시 사라

개인적으로 국장보다 미장을 선호한다.

경험적으로든 데이터든 수익률 차이가 크기 때문이다. ["코스피, 장투할 이유가 없다"…10년 수익률 글로벌 '꼴찌' ]

해외장에서 고려해야할 게 있다면 환율과 해외주식 양도세다.

환율은 위에서 설명했으니, 해외주식 양도세를 다루어보자면,

해외주식 양도세 기준은 연간 250만원이상의 순수익을 얻었을때다.

지방소득세까지 합해 22%나되는 세금이 붙는데, 만약 마이너스인 종목을 매도해 250만원 이하로 내려가도록 상쇄할 수 있다면 양도세를 안낼 수 있다.

또한 국장이든 해외장이든 금투세도 고려하도록 합시다.

배당주

매달 200만원 따박따박 받으려면…배당금 종잣돈 얼마

최근 배당주들을 원하는 사람들이 늘어나고 있다.

보통 은행, 통신주, 소비재가 대표적인 배당주고 지수추종에는 SCHD, JEPI, JEPQ, SPHD정도가 유명한 것 같다.

배당주를 사기이전에 배당주도 주식이므로, 운용비용등으로 주식 자체가 떨어질 것인지 고려하고 사는게 좋다.

7. 보험

생명보험 vs 손해보험 vs 제 3보험

보험의 종류라 하면 보통 세가지로 나뉜다.

생명보험
- 범위: 사망하거나 질병에 걸렸을 때
- 보장: 약속된 목돈
- 예: 암, 종신, 건강보험
손해보험
- 범위: 신체 또는 재물 손해가 생겼을때 손해를 보상
- 예: 상해, 의료, 자동차, 화재, 해상, 배상책임, 여행
제 3보험
- 범위: 생명과 손해보험의 겹치는 부분 (질병)
- 예: 상해, 질병, 간병

참고로 실비보험(실손의료보험, 실손보험)은 모두 같은 의미.

비용

보통 다음과 같다.

생명보험 > 손해보험
종합실비 > 단독실비
저축형 > 보장형

특정한 질병을 걸릴지 안걸릴지 모르지만 사람의 생명은 무조건 한번 꺼지므로..

생명보험이 손해보험보다 비쌀 수 밖에 없다.

만약 손해보험을 들었는데 매달 10만원 가까이 나간다면 종합실비이다.

종합실비는 암진단, 기타 질환의 진환, 수술비등이 종합적으로 구성된 상품이라 그렇다.

단독실비는 만원 정도로 저렴하며, 보험사가 유일하게 손해본다는 말이 있을 정도로 가성비이니 하나쯤 들어두는게 좋다.

저축형은 만기가 되면 돌려주는데 중간에 보험사가 운용을 하고 이자를 추가로 넣어 돌려준다.
개인적으로 이자 몇 푼 받으려 보험료를 더 내기보다는 컴팩트한게 좋다.
"투자"를 하려면 주식, 채권, 예금, 적금을 하는게..

더 나은 Git 워크플로우를 향해서

BlaCk_Void — Sun, 15 Jan 2023 20:43:42 +0900

최근 몇개월간 Git 활용이 일진보한듯 하여 몇글자 적어본다.

0. 레포구조

깃은 분산 버전 관리 시스템(Distributed Version Control Systems)이기 때문에 각 컴퓨터마다 레포지토리를 가질 수 있다.

로컬, 중앙집중형, 분산형

개발자 각자가 로컬 커밋을 가지고 원하는 때에 서버에 반영할 수 있는 것은 물론, (시간)

레포지토리 연결구조도 원하는대로 가져갈 수 있다. (공간)

중앙집중형, 깃허브/깃랩 방식, 계층형

위에서 가장 복잡해보이는 계층형은 리눅스처럼 거대한 프로젝트가 운영되는 방법이다.

메인테이너 밑의 관리자가 각자 분야의 기여를 받고, 최종적으로 메인테이너가 관리자 레포를 merge하는 식으로 운용한다.

이렇게 다양한 방식으로 구성할 수 있다는 점은 DVCS의 커다란 매력이다.

Git이 가지고 있는 다른 장점들을 보고 싶다면 다음 사이트를 참고해보자.

Why Git is Better than X

1. 브랜치 구조

브랜치(분기) 전략은 Git의 처음과 끝이다.

그 중 브랜치 구조부터 뜯어보자.

Hello Serverless, Goodbye Git Flow

추후 나올 Master, Main, Mainline, Trunk는 모두 동일하게 쓰인다.

GitHub Flow

먼저 개발자들이 가장 쉽게 익힐만한 방식, Github flow.

Introduction to Git Version Control Workflow

기능이나 버그 브랜치 만들기
풀리퀘스트 생성
피드백 받아 고치기
병합

단순하고 이해하기 쉬운 방식이다.

Git Workflows

버그든 기능이든 브랜치를 만들어 병합하기만 하면 알아서 배포가 되거나 릴리즈 태그를 달아 배포하는 형태.

Git Flow

많은 사람들이 들어봤을 Git flow다. [A successful Git branching model]

배포를 마구마구 하는 웹이 아닌 어플리케이션이나 보다 전통적인 개발에 초점이 맞춰져 있다.

Feature 브랜치에서 개발해 Develop 브랜치에 병합
Develope 브랜치가 충분히 성숙하면 Release(Stage) 생성
Release 브랜치에서는 버그 수정만
Release가 준비되면 Master에 병합하고, 릴리즈!!
릴리즈 후, 핫픽스가 생기면 다시 릴리즈하고 Develope 브랜치에도 적용

꽤나 체계적이다.

그러나 너무 복잡하다. 개선해보자.

Gitlab Flow와 Perforce Stream

GUI에서 MVC -> Flux 아키텍쳐처럼 선형적으로 넘어가는 것처럼 흐름을 보다 단순히 만들어보자.

Develop, Stage, Master는 장기적으로 유지되고, Feature, Bug, Hotfix는 단기적으로 유지하는 건 어떨까?

더 나아보인다.

조금만 더 바꾸어보자.

보통 Gitlab flow라고 부른다.

Gitlab flow

Hotfix를 Develop, Stage, Master에 모두 병합하는 대신 양옆의 2개에만 하기
Github Flow처럼 Develop을 Master로 하기 (경우에 따라 Staging을 Master로 할 수 도?)

Github 워크플로우에 한층 가깝게 만든다면 Perforce의 Stream도 좋은 예다. [What Is Perforce Streams?, Codelines and Streams]

Github 워크플로우와 차이라면 명확한 역할이 정해져 있다.

Release, Main(master), Develop으로 구성
Release에서는 버그를 고쳐 Main 방향으로 전파 (Merge Down)
Main도 Develop으로 전파, 기능이 만들어지면 충돌을 없애고 Main에 반영

Trunk 기반

Trunk 기반 개발은 Main(Master)를 보다 효율적으로 사용하기위한 방법이다. [Git Branching Strategies vs. Trunk-Based Development, Trunk Based Development]

Main 브랜치만 오래 유지해 충돌이 줄이는데, 구글과 페이스북 규모에서 많이 사용한다.

Main만 장기유지 Branch로 사용
다른 Branch들은 짧게 유지
기능은 플래그를 사용해 Off 상태로 병합해 항상 최신 코드 유지
CI/CD를 적극적으로 활용

정리

Staging 과정이 필요하면 Gitlab flow, 아니라면 Trunk 기반이 합리적으로 보인다.

2. 커밋

컨벤션

비교적 커밋 메세지 컨벤션(규약)에 관해서는 공감대가 있다고 생각한다.

기본적으로 타입에 fix:[버그수정]와 feat:[기능추가]을 사용하며, 앵귤러 컨벤션을 따라 docs:[문서수정] style:[포매팅] refactor:[리펙토링] perf:[성능향상] test:[테스트] chore:[툴링], bump:[패키지 버전업] 등을 사용하는 경우가 일반적이다.

타입: 설명

본문(선택)

꼬리말(선택)

물론 합의와 일관성만 지켜진다면 선호도에 따라 조정할 수 있다고 생각한다.

타입에 이모지 사용: 개인적으로 터미널에서 입력하기 까다로워 불호이나 gitmoji 툴을 써볼 수 있다
개인적으로 "feat(api): send email to the customer"보다 "Feat: API - Send email to the customer"처럼 대문자로 위계를 주고, 적용범위는 대시를 사용하는 방식를 좋아한다

전 커스텀을 해서 반강제적으로 고르도록 하는 편.

당연하겠지만 추적할 이슈를 넣을 수 있다면 넣는게 좋다.

커밋을 하게된 배경등 히스토리와 문서 측면에서 상당한 장점이다.

단위

보통 커밋은 최소 단위별로 되어야 한다. [깃(Git) 커밋 가이드]

그러나 최소단위에 대해서는 각자의 생각이 다를수 밖에 없고 논란이 될 수 밖에 없다.

사실 이 글을 적게된 원인..

일단 나는 가능한 최대한 자주하고, 나중에 필요하다면 합치는 방향으로 한다.

커밋을 rebase로 합치기는 쉽지만, 나누기는 어려움
패키지 Bump, 오타수정처럼 사소한 커밋도 이미 존재

이때 전체가 아닌 필요한 변경사항 단위로 커밋할 수 있다면 좋다. [Git에서 변경사항 단위(Hunk)로 스테이징하기]

또한 툴에서 delta 단위로 변경사항을 비교할 수 있는지도 체크해보자.

변경단위별로 스테이징, 변경 Delta 추적

투기적 커밋과 선형적 기록

자, 그럼 얼마나 자주할 것인가?

나는 나중에 PR을 열기 전이든, 병합하기 전이든 추후 적절히 보이기만 하면 상관없다는 마인드라 저장이 필요하다 싶을 때마다 한다.

심지어 컴파일이나 린트를 안되는 상태에서도.

Stash 후 바로 pop할 상황이 아니라면 일단 스냅샷으로 만듦
작업 중 다른 방법이 생각나 테스트 해볼 때
다음 작업하기 전 Save가 필요할 때
그냥 Remote에 백업이 필요할 때

이를 투기적 커밋이라 부른다.

깃은 DVCS라 바로 main에 반영되지 않게 또는 본인 레포의 리모트에 푸시가 가능하며, 앞서 말했듯 "잘 정리하면" 된다.

그래서 추가적인 도구를 사용한다. (써보면 후회하지 않습니다)

Git-Branchless - 브랜치를 사용하지 않는 Git 워크플로우 지원 도구 모음

git-branchless라는 CLI 툴.

Branchless라는 이름답게 마구마구 분기를 양산해도 선형적으로 유지할 수 있다

git sl 또는 git smartlog를 사용하면 직관적인 그래프로 추적가능
git prev와 git next로 쉬운 checkout
git sync를 통한 자동적인 rebase, git move를 통한 커밋 옮기기
prev 커밋에서 리베이스로 재작성 후 git next로 움직이고 싶다면 git restack으로 고쳐주기
git undo로 언제든지 되돌리기!!
git revision보다 강력한 revset

글로는 와 닿지 않죠?

한번 스크린샷을 통해 확인 해보도록 합시다.

초기화

우선 초기화를 하고 일반적인 분기를 생성 해볼겁니다.

git init과 git branchless init으로 초기화
commit0 ~ commit2 이후에 featA라는 분기를 만들어 commit3, commit4 진행
main으로 돌아오기

git init --initial-branch=main
git branchless init --main-branch=main

touch commit0
git add commit0
git commit -m "Add: commit0"

touch commit1
git add commit1
git commit -m "Add: commit1"

touch commit2
git add commit2
git commit -m "Add: commit2"

git switch -c featA
touch commit3
git add commit3
git commit -m "Add: commit3"

touch commit4
git add commit4
git commit -m "Add: commit4"

git switch main

로그를 보면 알겠지만 git hook을 통해 구동된다.

로그는 다음과 같이 보여지겠죠.

git log --graph --oneline --all --decorate --color --topo-order --branches -10 | tac

git sl(git smartlog)로도 확인을 해봅시다.

간단한 명령어로 정보를 더 보기 편하게 보여준다.

git sl

기본 사용법

이번에는 익명분기도 만들어봅시다.

둘 다 잘 추적해주고 있는 모습을 볼 수 있다.

touch commit5
git add commit5
git commit -m "Add: commit5"

git switch --detach

touch commit6
git add commit6
git commit -m "Add: commit6"

이제 바로 전 커밋인 main으로 다시 돌아가고 싶다고 해보자. 어떻게 해야 할까?

일반 git이었다면 git swith main이라 했겠지만 여기서는 전 커밋으로 전환하는 git prev 명령어로 충분하다.

git prev

반대로 다음 커밋으로 이동할 때도 next로 전환하기만 하면 된다.

숫자를 넣어 prev 3 하면 3 커밋전으로 전환하는 식이라 간편하다.

git next
git prev 3

커밋 옮기기

지금은 main 다음이 commit6이다.

그런데 commit 3과 4가 main 이후에 오도록 유지하고 싶을 수도 있다.

선형적으로 기록을 유지하려면 필요할 작업이죠.

git-branchless 툴을 사용하면 commit3으로 이동한뒤 git sync라고 하면 main을 기준으로 리베이스가 된다.

git next 2 -o # 오래된 커밋쪽으로 이동, 새로운 커밋쪽은 -n
git sync

이렇게 해버렸다가 후회하면 어떻게 하냐고요?

마법의 무기 git undo로 되돌려버릴 수 있다.

git undo

여기서 git sl의 장점이 하나 더 나온다.

바로 의미있는 익명분기만 똑똑하게 추적해 준다는 점!!

사실 스크린샷 찍기를 깜박해서 이미 한번 git undo로 되돌린 상태인데요, git log 그래프를 보면 상당히 더럽습니다. (commit3과 4가 3번이나 표시)

이번에는 commit6을 commit4 뒤로 옮겨봅시다.

git move -s 7de4f31 -d d4b489a

undo후 featA 브랜치인 commit3과 commit4를 commit6 뒤로 옮겨볼 수도 있다.

git undo
git move -b featA -d 7de4f31 # 같은 분기에 속한 -b 413c2f2 또는 -b d4b489a 를 해도 상관없음

이렇게 모든 커밋 기록을 꼭 선형으로 유지해야 할 필요는 없다.

하지만 Feature 브랜치를 병합하기 전이라던가 제한적으로 쓸때도 편하다고 생각한다.

분기 없이 유지하기

짜잔~ 커밋 그래프를 선형적으로 유지하기가 이렇게나 쉽습니다?

그런데 생각해보니 commit6과 commit3을 rebase하고 싶어졌습니다.

git rebase -i HEAD~2

..? 새로운 커밋이 생성되기 때문에 분기가 생겨버렸네요.

다행히 안내가 뜨는대로 git restack 명령어로 깔끔히 해결되니 걱정마십시오.

git restack

이를 이용하면 처음 언급했던대로 투기적 커밋 후 리베이스하는 방식으로 할 수 있다.

코드를 작성한 컨텍스트는 보존되고 뒷감당은 툴이 해줍니다.

이에 관심있다면 git record와 git amend도 읽어보십시오.

또한 git restack은 rebase뿐만 아니라 git commit --amend 일 때도 모두 적용이 가능하다!!

sync나 move시 conflict가 생길 경우 명시적으로 --merge 옵션을 추가하도록 실패하며, 설사 merge를 시도하다 안되겠다 싶으면 언제든지 git undo로 되돌릴 수 있다.

이제부터 더 간단해보이는 커밋 그래프와 두려움 없는 git 명령어들을 누려보세요.

참고로 HEAD~같이 단순한 revision보다 강력하고 쉬운 revset이 있으니 선택자가 필요하다면 확인해보길 바란다.

익명분기 추적, revset 모두 Mercurial(hg)의 훌륭한 자산이었던 것들이다.

git branchless 개발자가 메타 출신 엔지니어라서 그런지 메타의 VCS인 Sapling과 굉장히 유사하다.

3. 병합

단위

메인 분기에 병합하기 전에 가장 걸리는 것은 바로 코드 리뷰다.

4~5000라인? 아니 1000라인 정도만 되도 "다른사람이 작성한" 코드를 보기란 쉽지 않다.

패치 스택(Patch Stack)

이를 해결하기 위해 나온 방식이 바로 Patch stack이다.

기능[1/3], 기능[2/3], 기능[3/3]처럼 쪼개서 리뷰 후 병합하면 체크해야할 양이 현저히 줄기 때문에 좋다.

리뷰할 때는 기능[1/3], 기능[2/3], 기능[3/3] 순으로 하여 커밋이 필요하면 추가하고, 병합할 때는 기능[3/3], 기능[2/3], 기능[1/3] 순으로 병합하기 때문에 Patch Stack이라 불린다.

일반 분기 vs 패치 스택

git-branchless의 경우 git submit이라는 명령어를 통해 branch들을 push하는 형태이고,

본격적인 툴로 Graphite가 존재한다. (Phabricator나 gerrit도 참고해볼만하나 phabricator는 메타가 버렸고, gerrit은 구글 전용 느낌이다.)

찾아보니 메타의 경우 ReviewStack이라는 깃허브와 연동되는 도구를 새로 만들어서 쓰는 것 같다.

패치 스택과 관련된 글을 보면 알겠지만, 여기서도 선형적 커밋 그래프 관리가 빛을 발한다.

병합 커밋 vs 선형적

이렇게 선형적으로 관리를 하면 보기 좋은 것은 물론 git bisect를 이용해 문제있는 커밋 식별하기도 쉬워진다.

무언가 자동적으로 식별한 후 고치고 싶다면 git-branchless의 git test을 사용해보자.

병합 큐(Merge Queue)

병합에 있어 또 다른 문제는 다양한 이슈에서 생기는 풀리퀘스트를 병합할 때 문제가 생길 수 있다는 것이다.

앞선 Patch stack이 한 문제를 잘개 쪼개는 방법론이라면, 병합큐는 여러 이슈에서 생기는 병합 요청을 통합하여 해결하자는 방법이다. (개념적으로는 비슷하나 병합 큐는 전역적이다)

예를 들어, 잘 작동하는 feature1과 feature2라는 풀리퀘스트가 있다고 가정해보자.

각각 병합할때는 괜찮지만, 두개가 모두 병합될때는 충돌이 생길수도 있다.

Merge queues: An intro for mobile engineers

때문에 바로 병합하는 대신 git의 stage 영역의 개념처럼 Merge ready 상태를 도입한다.

풀리퀘스트를 바로 병합하는 대신 Merge queue에 추가함
Merge queue에 존재하는 분기의 상태로 풀리퀘스트를 업데이트
다시 CI 검사를 실행함

내가 아는한 Shopify가 도입한 기능으로,

깃랩은 merge train, 깃허브에서는 merge queue라 부른다.

이슈 관리에 있어서도 종속성을 다룰 수 있었으면 한다. [about:Mozilla's blockers and needinfos, QA/Bugzilla/Fields/Status]

버그질라에는 blocker와 needinfos라는 이슈 종속성 시스템이 존재한다.

blocker: A이슈로 인해 B이슈가 해결될 수 없다면, A이슈는 B의 blocker이다.
needinfo: 더 많은 정보가 제공될 때까지 재현 및 수정될 수 없는 버그

충돌 - 일급 충돌 및 3 Way diff

Git에 없어서 아쉽지만, Jujutsu, Pijul에는 일급충돌이란 개념이 있어서 충돌을 기록할 수 있다.

이렇게되면 한번 해결한 충돌이 나중에 또 일어나는 일이 적다.

Jujutsu는 깃과도 호환되니 사용해 볼 수 있음.

git note에 메타데이터를 저장하는 방법을 제안했으나 많이 느려서 써먹기가 어렵다는 모양이다 ㅠㅠ

그리고 Jujutsu의 3-way diff방식은 매우 보기 편하다.

# Git 방식
  <<<<<<< left
  apple
  grapefruit
  orange
  ======= base
  apple
  grape
  orange
  ||||||| right
  APPLE
  GRAPE
  ORANGE
  >>>>>>>

# Jujutsu 방식
  <<<<<<<
  %%%%%%%
   apple
  -grape
  +grapefruit
   orange
  +++++++
  APPLE
  GRAPE
  ORANGE
  >>>>>>>

Jujutsu의 3way diff 방식은 깃에도 들어갔으면 하는 바램이다.

단, 위 방식이 기존 IDE, 에디터의 문법강조와 호환이 안될 가능성이 높고, 2개의 Diff등을 원할 수 있기 때문에 Better conflict marker 제안을 해보는 중.

아마 Jujutsu쪽에 다시 글을 올리게 될 것 같다.

충돌 - 바이너리

Git이 충돌날때 고질적인 단점 중에 하나는 바이너리의 처리다.

매번 충돌이 생겼으니 알아서 하라는 방종이 마음에 안들었다.

일단 충돌이 생겼다는데 어떻게 하라는 건지..

학교에 돌아가면 PDF라던가 바이너리 파일을 다룰일이 많으므로 러스트로 간단히 바이너리 충돌동작 개선안을 만들어봤다.

Binary conflict

보다시피 3개의 파일을 볼 수 있다.

base: 분기의 시작인 파일
그냥: 충돌 나기 전에 병합된 현재 보여지는 파일
their: 병합을 시도하는 새로운 파일

이렇게 3개의 파일을 동시에 보여주게 되면 필요한 파일이면 추가, 필요없으면 제거를 함은 물론 워드나 프리젠테이션 파일이면 열어서 직접 비교한 후 병합할 수 있다.

패치와 메일

제가 사용하지는 않지만 필요한 사람을 위해 남겨놓는다.

최근 깃 사용에서 다른 사람의 변경사항을 반영하는 방법은 Pull Request를 생성 후 병합(Merge)하는 방식일 것이다.

왜 Pull request인가 하면 옛날에 깃허브에서 프로젝트에 기여를 하기 위해 요청하면 기여자의 리포트 레포에서 git pull을 하라는 메일이 갔기 때문이며 git request-pull 이라는 명령도 존재한다. [Better Pull Request Emails]

지금은 버튼만 누르면 깃허브나 깃랩등 서버에서 대신 해준다.

pull 요청 메일

다른 방식이라면 나처럼 젊은 개발자들은 익숙하지 않겠지만 패치 파일을 생성하고 이메일 처리하는 방식이 있다.

리눅스나 org mode같은 전통있는 오픈소스들이 애용하는걸로 알려져 있다.

다음은 Free desktop에서 제공하는 예제이다.

# == 설정 ==
# 본인 정보
git config --global user.name "My Name"
git config --global user.email "myemail@example.com"

# 본인의 메일 서버 연동
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpserver mail.messagingengine.com
git config --global sendemail.smtpuser tanuk@fastmail.fm
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtppass hackme

# 메일 받을 대상 설정
git config sendemail.to pulseaudio-discuss@lists.freedesktop.org

# == 보내기 ==
# 패치 전송
git send-email HEAD^

# 패치 버전2 전송
git send-email -v2 HEAD^

# 패치 생성 후 보내기
git format-path origin/master # 이메일용 패치 생성
git send-mail *.patch

# == 적용하기 ==
# 패치 적용
git am filename.mbox

# 리눅스의 경우
b4 am -o- <url> | git am

최근에는 SourceHut이라고 git send-email과 메일링 리스트(예시)를 최대한 사용하는 서비스도 있는 듯 하다.

리눅스의 경우 b4라는 툴을 직접 만들어 사용하는 모양이다.

만약 이 방식을 사용할 것이라면 이메일과 관련된 git 명령어들 모음도 확인 바란다.

4. 기타 관리 방법

기능개발과 버그 수정을 동시에 - Worktree

git worktree 기능을 사용하면 git history는 공유된 채로 작업파일들만 여러곳에 체크아웃하여 작업들을 동시에 진행할 수 있다.

나같은 경우는 기능개발과 버그수정을 동시에 할 필요가 있을 때 사용한다.

stash나 커밋 후 branch 전환후 작업하거나 clone을 새로 받을 필요가 없다.

주요 명령어는 다음과 같다.

git worktree add [path]        # 워크트리 추가
git worktree remove [worktree] # 워크트리 제거
git worktree list              # 등록된 워크트리들을 보여줌

위 설명을 들으면 마치 SVN의 분기를 떠오르게 하는 방식이다.

SVN 브랜치(branch)와 merge

대용량 파일 - Git LFS

이제부터 나오는 내용들은 예전 CI/CD 성능 관련해 적었을 때 소개한 적이 있을 것 이다.

그 중 첫번째는 대용량 파일로 깃허브의 경우, 50MB 파일은 경고 100MB 이상 파일은 차단하고 있다.

대부분의 경우 Git LFS로 해결할 수 있지만 여전히 최대 파일 크기가 제약되어 있다.

Git LFS

아니면 다음 솔루션들을 고려해볼만 하다

DVC: Git Annex와 비슷하나 머신러닝 데이터처럼 더 커다란 파일과 클라우드에서 공유 #211
- 비슷하게 Git과 호환되는 xetdata, diversion이 있는 것 같다
Snowtrack: 2D/3D 디자인 리소스들 관리에 최적화, 관심있다면 SnowFS도 확인하자
elfshaker: 바이너리 압축이 고도로 가능
JamSync: Rsync에 기반하여 항상 최신으로 유지

모노레포 - 부분복제

모노레포는 분리된 다양한 관심사가 한데 모여있어 쓰지도 않은데 괜히 차지하는 용량이 크다.

예전에 나왔던 내용의 동어반복이겠지만, 핵심은 2가지다.

.git(bare git)의 내용을 부분복제(Partial clone)하기와 작업파일 부분 체크아웃(Sparse checkout)하기.

먼저 부분복제로 다운로드하는 시간을 줄여보면 clone시 파일(--filter=blob:none), 디렉토리(--filter=tree:0), 커밋기록(--depth=1) 등을 제한 시킬 수 있다.

파일, 디렉토리, 커밋 기록 제외

git이 clone되고 나면 실제 작업파일들을 보여줘야 한다.

이때 시간이 오래 걸리므로 필요한 작업파일들만 사용할 수도 있다.

사용하는 작업 디렉토리만 보여주기!!

그렇다면 리눅스 소스코드를 다운로드 받아보자.

20분이나 걸리던 작업이..

겨우 1분만에 다운로드 받아진 것을 볼 수 있다.

git clone --depth=1 --sparse https://github.com/torvalds/linux

나 같은 경우 sparse-checkout은 github action이나 문서처럼 의존성이 적은 작업의 커밋이 필요할때 유용하게 쓰고 있다.

특정한 폴더만 받는 기능도 SVN의 킬러 기능이었으나 모두 대체 가능해지면서,

깃허브는 2024년 1월 8일에 SVN 지원을 제거하게 된다.

모노레포 - 스칼라!!!!!!

이 기능에는 마소의 눈물겨운 노력이 깃들어있다..ㅠㅠ

윈도우 소스코드가 너무 커서 다운로드에 12시간, 체크아웃에 3시간이나 걸려 개선하기 위한 형태의 종착역이다.

sparse checkout이 기본은 물론, GVFS라는 프로토콜로 빠르게 다운로드가 가능하다고 한다(Azure devops만 현재 지원).

그리고 관리를 위해 여러 커스터마이징이 된 부분들이 존재한다.

빌드 결과물을 소스와 분리하기 위해 clone시<project_name>/src에 소스코드가 위치
인덱스와 수정된 크기 추적 및 압축
백그라운드에서 fetch, 커밋그래프 작성, 팩 파일 정리 및 색인 생성 작업을 실행

앞서 depth=1을 하면 커밋기록이 사라지는 것과 달리 기록이 보존되면서 파일들이 필요하게 되면 적절히 다운로드를 해준다.

대형 레포를 가지고 있는 곳이라면 시도해볼만 하겠다.

HTML과 CSS 전처리, 템플릿의 표현력

BlaCk_Void — Sun, 11 Sep 2022 01:55:20 +0900

별다른건 아니고, 예전에 찾았었던 자료들 정리나 하려고 쓰는 글.

그래도 굳이 쓰게된 동기를 찾는다면 JSX와 CSS In JS의 표현력에 관해 발전할 여지가 있는지이다.

PHP를 사용하던 페이스북이 XHP(xhp-php5-extension, XHP: Introduction)를 만들고, 대체할 제품으로 React와 JSX, CSS-In-JS(슬라이드)를 소개하더니, 종국에는 서버 컴포넌트까지 만들어 내면서 PHP를 대체 가능하게 만들어버렸다.

ReactJS 둘러보기 - XHP부터 React Native까지

난 이러한 과정에서 과연 표현력의 손실이 있는가가 궁금했다.

우리가 보지 못한 다른 가능성이 있는가도 말이다.

전처리, 템플릿 엔진

전처리기는 입력 데이터를 처리해 다른 프로그램에 대한 입력으로 사용되는 출력물을 만들어내는 프로그램이다.

템플릿 엔진은 결과 문서를 생성하기 위해 데이터 모델과 템플릿을 결합하는 프로그램이다.

템플릿 엔진이란?

전처리기는 정적, 템플릿 엔진은 보다 동적인 형태라 할 수 있겠다.

전처리기와 달리 외부의 데이터를 가공해서 사용한다는게 특징이라면 특징.

HTML

HTML 템플릿 엔진들

템플릿 엔진 비교

먼저 HTML부터 시작하자.

Markdown 및 마크업 종류

마크다운은 문서 작성용으로 최고다.

일부 문법은 아쉽지만 Org Mode, 모니위키, 미디어위키, AsciiDoc과 함께 읽기좋은 마크업 언어중 하나.

단점으로 뽑자면 Includes와 같은 전처리기의 필수 기능이 없다.

Pug 류

Pug, Haml, Slim류는 XML 문법의 흔적을 제거하고 파이썬 내지는 Emmet과 비슷하게 만든다.

코드를 칠때는 좋으나, 인덴트만으로 구분하므로 명확한 블럭이 없어 읽을때가 괴로운 것 같다.

PHP, ERB 류

반면 ERB, Liquid, Nunjucks등은 HTML에 상대적으로 가깝게 만들어져 있다.

Handlebars나 Mustache의 {{# start}}{{/ end}}보다 {% start %}{% end %}가 보기 좋은 것 같다.

전반적인 문법은 Nunjucks가 가장 깔끔해보이는 듯.

그러고보니 Nunjucks도 모질라 작품이네;;

아무래도 나랑 모질라가 취향이 잘 맞나보다.

Thymeleaf, Jinja2, Velocity, Freemarker등도 모두 이쪽에 가깝다.

JSX와의 비교

난 SFC도 매력적이지만 Ryan Carniato와 동일한 이유로 JSX 방식을 선호한다.

JSX는 자바스크립트 스펙을 사용하기 때문에 Local variables, Filters, Math에서는 완벽한 우위라 할 수 있다.

Templating과 Includes는 {변수} 혹은 {JSX.Element}처럼 Curly brace로 사용이 가능하고, Slot쪽은 Props와 HOC 패턴으로 그럭저럭 대체 가능하다. [RadixUI Slot, Vue Slots in React, React Slot]

<head>쪽도 JSX의 특성상 사용하지는 못하지만 react-helmet-async로 구현이 가능하다.

JSX의 가장 커다란 아쉬움은 Logic과 Loops라 할 수 있겠다.

삼항/비트 연산자와 map()으로 가능하긴 하나 중첩된 삼항 연산자가 나타나는등 복잡한 조건이라면, 읽기 쉽지 않은 것이 사실이다.

SolidJS는 Control Flow라 하여 지원하고 있으며, 컴포넌트이기 때문에 리엑트도 하려면 React If처럼 가능하긴 하다.

SolidJS의 제어 컴포넌트들을 보면 상당히 직관적이고 유연하다.

// 일반적인 If-Else 조건
<Show when={state.count > 0} fallback={<div>Loading...</div>}>
  <div>My Content</div>
</Show>

// state.user 값이 변경될때만 실행하며, state.user 값을 받아서 사용할 수 있음
<Show when={state.user} fallback={<div>Loading...</div>}>
  {(user) => <div>{user.firstName}</div>}
</Show>

// 여러가지 조건이 필요할 때
<Switch fallback={<div>Not Found</div>}>
  <Match when={state.route === "home"}>
    <Home />
  </Match>
  <Match when={state.route === "settings"}>
    <Settings />
  </Match>
</Switch

// 변경된 항목만 효율적으로 업데이트하는 참조 키 루프
<For each={state.list} fallback={<div>Loading...</div>}>
  {(item, index) => (
    <div>
      #{index()} {item}
    </div>
  )}
</For>

이는 앵귤러JS에서 ng-if와 ng-repeat이라 하여 디렉티브(Directive)라는 이름으로 더 간결하게 제공하고 있었다.

후속제품인 앵귤러와 Vue에서도 제공하는 기능으로 리엑트로 오면서 손실된 기능이라 할 수 있다.

다음 케이스의 대부분은 Control Flow 컴포넌트와 겹치는 것 같지만, 라인수가 줄어들어서 선호하는 사람이 있을 수도.

역시 SolidJS의 방식이 꽤 좋은데, 리엑트에 익숙할 독자들을 위해 리엑트가 디렉티브를 지원한다 가정해 약간 변형해보았다.

function model(el, value) {
  const [field, setField] = value;
  useEffect(() => el.value = field, [el, field]);
  el.addEventListener("input", (e) => setField(e.target.value));
}

function Input() {
  const [name, setName] = setState("");
  return <input type="text" use:model={[name, setName]} />;
}

디렉티브에서 주목할 것은 useRef(null)을 쓸일이 줄어들 수 있다는 점. (디렉티브는 ref에 대한 문법 설탕에 가깝다)

전역 디렉티브는 JSX 네임스페이스에 추가해야할 필요가 있으므로, 익명 디렉티브도 보고싶다.

function Input() {
  const focus = (el) => {
    el.focus();
  }

  return <input type="text" use={focus} />;
}

기타 언급해볼만한 것들

XSLT와 Xquery

XSLT(Extensible Stylesheet Language Transformations)는 XML을 다른 형식으로 변환할 수 있도록 만든 포맷이다.

XSLT 문서를 보면 알겠지만 템플릿 엔진들과 비슷한 면과 문법들이 존재한다.

XQuery는 이거.. JSX아냐? 라는 생각이 들만큼 비슷하며,

문법의 하위집합인 XPATH는 XML 노드들을 참조하는 방법으로 우리에게 익숙한 파일 경로방식을 사용한다.

 <html><body>
 {
   for $act in doc("hamlet.xml")//ACT
   let $speakers := distinct-values($act//SPEAKER)
   return
     <div>
       <h1>{ string($act/TITLE) }</h1>
       <ul>
       {
         for $speaker in $speakers
         return <li>{ $speaker }</li>
       }
       </ul>
     </div>
 }
 </body></html>

SaonicaJS가 XSLT와 XPATH를 지원하는 대표적인 라이브러리다.

JSP

JSP는 PHP와 거의 유사한데 Scriptlet, Declaration, Expression으로 나뉘어 있다.

복잡한 스크립팅이나 정의는 Return 보다는 함수 본문에 있는게 맞다고 생각하기에 Scriptlet이나 Declatation이 굳이 JSX에 필요하다 생각하지는 않는다.

JSP의 문제 중 하나는 WAS를 사용해 서블렛으로 변환하는 과정이 필요하다.

Web Server와 WAS의 차이와 웹 서비스 구조

Marko

Marko는 HTML 확장의 끝판왕인 템플릿 엔진이다.

앞서나온 Pug, PHP 종류 문법의 장점만을 가져왔으며, 자바스크립트와의 연동이 충분히 고려되어있다.

인수 타입은 컴파일 시간에 검사할 수 있으니 크게 문제될 것은 없어보인다.

// Emmet과 비슷
<div.count/> // <div class="count"/>
<span#my-id/> // <span id="my-id"/>

// 자바스크립트의 값들을 바로 사용가능
<div class=myClassName/>
<input type="checkbox" checked=isChecked />
<custom-tag string="Hello"/>
<custom-tag number=1/>
<custom-tag template-string=`Hello ${name}`/>
<custom-tag boolean=true/>
<custom-tag array=[1, 2, 3]/>
<custom-tag object={ hello: "world" }/>
<custom-tag variable=name/>
<custom-tag function-call=user.getName()/>

이번에는 제어구문을 보자.

if문은 default argmument, for문은 children callback을 네이티브하게 지원해주고 있다.

{% start %}{% end %}보다도 깔끔하게 설계 되었고, For문에 있어 Fallback기능이 없어 아쉬울뿐 자바스크립트의 문법을 모두 가능하다.

${}의 보간방식도 자바스크립트의 Template literal과 일관성이 있어 호감.

Vue의 명명된 슬롯과 비슷한 attribute tag도 제공한다.

// 조건문
<if(user.loggedOut)>
  <a href="/login">Log in</a>
</if>
<else-if(!user.trappedForever)>
  <a href="/logout">Log out</a>
</else-if>
<else>
  Hey ${user.name}!
</else>

// For 문
// 배열: <for|item, index, array| of=array>
// 객체: <for|key, value| in=object>
// for문: <for|value| from=first to=last step=increment>
<ul>
  <for|color, index| of=colors>
    <li>${index}: ${color}</li>
  </for>
</ul>

// @는 attribute 태그
<my-select>
  <@option>A</@option>
  <@option>B</@option>
</my-select>
// 사용법
<my-select
  option=[
    { renderBody: "A" },
    { renderBody: "B" }
  ]
/>

이벤트, 컨텍스트, 비동기 문등을 보아도 더 없이 깔끔해보인다.

// 이벤트
<button on-click(() => alert("Clicked!  "))>
  Celebrate click
</button>

// 컨텍스트
<context coupon=input.coupon on-buy(handleBuy)>
  <!-- Somewhere nested in the container will be the buy button -->
  <fancy-container/>
</context>
<context|{ coupon }, emit| from="fancy-form">
  Coupon: ${coupon}.
  <button on-click(emit, "buy")>Buy</button>
</context>

// 비동기
<await(searchResultsPromise)>
  <@then|person|>
    Hello ${person.name}!
  </@then>
  <@catch|err|>
    The error was: ${err.message}.
  </@catch>
</await>

// 태그 이름 보간
<${input.renderBody} number=1337 />

// 재사용
<macro|{ name }| name="welcome-message">
  <h1>Hello ${name}!</h1>
</macro>
<welcome-message name="Patrick"/>
<welcome-message name="Austin"/>

이는 XML과 거의 흡사한 JSX 스펙보다는 HTML에 가깝고 유연하게 만들어져서 가능했다.

깔끔한 제어구문들은 2021년에 소개된 Marko Tags API라는 새로운 설계의 결과다.

HTMX

HTMX는 HTML 속성들을 확장해 AJAX, CSS Transition, Websocket등을 사용가능하게 만든다.

일종의 디렉티브라 생각해도 되겠다.

다음과 같이 작동할 수 있다면 멋지지 않을까?

HTMX기준 인코딩은 application/x-www-form-urlencoded를 사용하는 것 같다.

function MyComponent() {
  return (
    <div>
      <div id="response-div" />
      <button
        use:post="/register"
        use:target="#response-div" // 또는 useRef 값
        use:swap={<CancleButton />}
      >
          Register!
      </button>
    </div>
  );
}

HLisp와 Hiccup

컴포넌트가 함수라면 tag들도 함수로 나타낼 수 있지 않을까?

그리고 속성들은 키워드 인수를 사용한다면 모두 함수처럼 나타낼 수 있지 않을까?

Hoplon이라는 클로져 스크립트 라이브러리가 HLisp문법을 사용해 이 방식으로 동작한다.

function Counter() {
  const [count, setCount] = useState(0);
  return div([
    h1(count, class="header", style={ fontSize: "12px" }),
    button("+1", onClick=(() => setCount(count + 1))),
    button("-1", onClick=(() => setCount(count - 1)))
  ]);
}

리스프 특유의 매크로까지 동원한다면 가능한 표현력은 극도로 상승한다.

물론 리엑트에서 위와 같이 작성한다면 매번 호출되며 Hooks가 작동하지 않는 사소한(?) 단점이 있다.

그렇다면 보다 정적인 구조로 바꾸어주어야 한다.

클로저의 세계에서는 키워드가 벡터에 들어갈 수 있으므로 각 태그들은 키워드를 사용하고, 컴포넌트 함수들도 벡터에 넣음으로서 정적인 구조를 만들 수 있다.

속성들이야 Map을 사용하면 되고.

Reagent의 Hiccup이 이 방식으로 작동한다.

정리

JSX 자체는 충분히 훌륭하다.

XML에 가까운 적은 문법의 추가만으로 직관적인 HTML 표현을 해주었다.

그러나 Marko의 구문이 더 깔끔하며, 가지 않은 길임에는 틀림없어 보인다.

Marko 구문을 쓸 수 있다면 Best이겠지만 Babel, 에디터 지원등 전체적인 생태계를 갈아엎어야 하기 때문에 현실적으로 힘들다고 생각한다.

대신 Control Flow 컴포넌트들을 제공하고, 디렉티브를 지원하게 된다면 어떨까.

예를 들어 다음과 같은 카운터 예가 있다고 해보자.

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <button onClick={() => setCount(count + 1)}>+1</button>
      <button onClick={() => setCount(count - 1)}>-1</button>
      <Header count={count} />
      <Lists count={count}>
        {
          (i) => <li key={i}>{i}</li>
        }
      </Lists>
    </div>
  );
}

function Header({ count }) {
  if(count > 5) {
    return <p>{count}</p>;
  }
  const SizedHeader = `h${ count > 0 ? count : 1 }`;
  return <SizedHeader>{count}</SizedHeader>;
}

function Lists({ count, children }) {
  const list = Array.from(
    {length: count },
    (_, i) => children(i)
  );
  return (
    <ul>
      {list}
    </ul>
  );
}

Control Flow 컴포넌트들을 제공하고, 디렉티브를 지원하면 이렇게 만들 수 있다.

Array.from( { length: count }, () => {})같은 이상한 구문을 생각해야하는 오버헤드가 줄어들고 코드는 선언적으로 변한다.

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <button onClick={() => setCount(count + 1)}>+1</button>
      <button onClick={() => setCount(count - 1)}>-1</button>
      <Header count={count} />
      <Lists count={count}>
        {
          (i) => <li key={i}>{i}</li>
        }
      </Lists>
    </div>
  );
}

function Header({ count }) {
  const SizedHeader = `h${ count > 0 ? count : 1 }`;
  return (
    <If condition={count > 5}>
      <Then>
        <p>{count}</p>
      </Then>
      <Else>
        <SizedHeader>{count}</SizedHeader>
      </Else>
    </If>
  );
}

function Lists({ count, children }) {
  return (
    <ul use:each={count}>
      {
        (_, i) => children(i)
      }
    </ul>
  );
}

그리고 JSX를 더욱 확장해 Marko 방식과 결합하면 더욱 간결하게 만들 수 있을 것이다.

Marko Tags API 레퍼런스와 비교했을때 엄밀하게는 차이가 있는데, JSX와 보다유사하게 만든 의사코드일 뿐이므로 양해바란다.

그래도 몇가지 원칙하에 작성했으니 적당한(?) 트랜스파일러가 있다면 변환 가능하지 않을까

JSX의 슈퍼셋
태그 선언 내에서 보간은 ${}로 함
Marko와 비슷하지만, JSX처럼 {}를 사용하므로 태그내에서 Object는 ({ key: value })처럼 사용해야 함

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <button onClick() { setCount(count + 1); }>+1</button>
      <button onClick() { setCount(count - 1); }>-1</button>
      <Header(count) />
      <Lists|i| count={count}>
        <li key={i}>{i}</li>
      </Lists>
    </div>
  );
}

function Header(_, count) {
  return (
    <If(count > 5)>
      <p>{count}</p>;
    </If>
    <Else>
      <h${count > 0 ? count : 1}>{count}</>
    </Else>
  );
}

function Lists({ count, children }) {
  return (
    <ul use:for|i| use:in(count)>
      {children(i)}
    </ul>
  );
}

CSS

CSS 관리와 표현의 문제들

CSS의 표현력에 관해서는 트위터와 깃허브갤에 이미 작성한 적이 있다.

그리고 다음 글은 반드시 읽어보기 바란다.

위 글에서 나오는 문제의식들이 있다.

Global namespace: 모든 스타일이 전역적으로 선언되어 중복되지 않는 class 이름을 적용해야 하는 문제
Dependencies: CSS와 JS간의 의존관계를 관리하기 힘든 문제
Dead Code Elimination: 기능 추가, 변경, 삭제 과정에서 불필요한 CSS를 제거하기 어려운 문제
Minification: 클래스 이름의 최소화 문제
Sharing Constants: JS 코드와 상태 값을 공유할 수 없는 문제
Non-deterministic Resolution: CSS 로드 순서에 따라 스타일 우선 순위가 달라지는 문제
Breaking Isolation: CSS의 외부 수정을 관리하기 어려운 문제(캡슐화)

그리고 트위터에서 지적되었던 문제들도 있다.

조합적 폭발: 고대비, 다크모드, 모바일-태블릿-데스크톱-TV를 다루려면 16가지에 대응이 되야하며 OS, RTL등등을 지원하려면 더 많은 조합들이 $2^n$으로 발생한다
다차원적 위계: CSS의 시각적 위계와 HTML의 정보구조 위계
디자인 일관성: 디자인적 규칙을 일관적으로 관리할 수 있어야 함

위에서는 조합적 폭발이 별개 아닌 것처럼 보이지만, 실제로 "올바르게" 구성하기에는 많은 어려움이 따른다.

내가 유지관리하고 있는 프로젝트의 탭 바의 레이아웃 구성을 만드는 코드(정의, 컴파일 결과)를 보고와보자 ㅋㅋㅋㅋㅋ

브라우저 버전, OS, 활성화 가능한 창 버튼, 전체화면 여부, One liner나 숨기기와 같은 레이아웃 종류등등 많은 것을 모두 고려해야 했다.

해결하기 쉬운 문제들

위의 문제들의 순서에는 일관성 없으니 그룹핑부터 해도록 하자.

CSS와 JS 통신

먼저 CSS In JS를 사용함으로서 매우 쉽게 해결이 가능한 문제들이다.

JS 만으로 CSS를 관리하면 상태 값 공유는 JS에 있는 값을 사용하면 되고, 의존 관계 역시 JS의 값이 우선되므로 해결이 가능하다.

Sharing Constants: JS 코드와 상태 값을 공유
Dependencies: CSS와 JS간의 의존관계를 관리

라이브러리 구현에 있어서는 CSS var가 큰 역할을 해주지 않았나 싶다.

Class 이름

Class 이름의 많은 것은 CSS module이 해결해 줄 수 있다.

여기서 핵심은 쉐도잉 지원으로, Scoped CSS의 긍정적인 면이라 할 수 있다.

What are CSS Modules? A visual introduction

Global namespace: 해시값을 추가적으로 적용하면 전역적으로 고유해짐
Minification: 해시값만 남기면 클래스 이름을 축소하기가 쉬움
Non-deterministic Resolution(일부): BEM 방법론처럼 Specificity를 하나로 관리하도록 만들어 일부 해결
Breaking Isolation(일부): 이름이 겹치지 않으므로(무책임하지만ㅠㅠ) Scoped class를 하나 더 만들어 확장하기

트위터 불평글에서 Scoped CSS에 관해 내가 공감한다는 부분이 바로 Non-deterministic Resolution과 Breaking Isolation이다.

이는 복잡도 부채를 뭉게거나 땜빵처리함으로서 달성하고 있으며 완전한 해결책이라고는 볼 수 없다.

논리와 반복적 표현

그리고 일부 해결이 가능한 문제가 더 있다.

조합적 폭발(일부): 전처리기나 CSS In JS에서 논리와 반복적 표현이 가능해짐으로 인해 "잘 작성하면" 해결 가능

역시 트위터 글에서 지적하듯, 각 위계에 따른 표현을 해결해야 적절한 관리가 가능해진다.

해결하기 어려운 문제들

컴파일러 인프라

Dead Code Elimination: AST를 만들고 번들러를 이용해 추적해야 하며, Split된 CSS는 런타임시 어떻게 불러와야 할지에 대한 문제가 생긴다.

디자인 표현

조합적 폭발: 조합을 쉽고 버그없이 할 수 있어야 한다
다차원적 위계: 시각적 위계와 의미론적 위계를 결국 모두 다룰 수 있어야 한다

관리 문제

Non-deterministic Resolution: 스타일 우선 순위를 개발자가 쉽게 정할 수 있도록 해야 한다
Breaking Isolation: 확장 대상의 CSS를 명시적으로 알 수 있으며, Override와 Emit이 쉬워야 한다
디자인 일관성: 중앙에서 관리할 필요가 있다

전처리기와 CSS In JS: 리터럴 구문

아직도 해결해야 할 문제들이 많지만, 도화지가 될 매체의 장점과 한계는 분명히 알고 있어야 도움이 된다.

또한 우리가 찾지못했던 문제의 공백이 있을지도 모른다.

다양한 CSS In JS를 먼저 살펴보지 않은 이유는 전처리기가 일반 CSS와 비슷하기 때문이다.

이 파트 부터는 표현력이 좋은 임의의 CSS In JS 라이브러리가 있다는 가정하에 진행한다.

새로운 CSS In JS 라이브러리에 대한 제안이 될 수도 있겠다.

~~올해 말쯤에 프로젝트들이 정리되면 만들어보고 싶긴한데...~~

제작하려는 목적으로 설계하는 것처럼 진행하느라 조금 늘어짐은 감안바란다. (일종의 RFC 느낌)

또한 정적 CSS 추출등의 최적화를 감안하지 않은 API들이 있다.

Template String vs Object Style

Template Strings vs. Objects in CSSinJS

CSS In JS 세계에서 CSS를 표현할 때는 두가지 방법이 있다.

Template string과 Object style이다.

그냥 사용하기에는 템플릿 문자열이 좋아보인다.

CSS 속성과 문법을 그대로 사용가능하기 때문이다.

템플릿 문자열 vs 객체 스타일

그러나 오브젝트 스타일은 CSSOM과 동일한 표현방식이고 많은 보간이 필요할 때 나은 방식이다.

타입스크립트를 사용하면 타입을 지원한다는 장점 또한 존재한다.

CSS In JS를 사용하는 이유는 기본적으로 많은 규칙을 다루고, JS와의 상호작용을 위해 있다.

때문에 CSS In JS을 사용한다면 Object 스타일을 기본으로 두어야 한다.

디자인 규칙이 적고 JS와의 상호작용이 불필요하다면 CSS 전처리기를 사용함이 더 낫다.

CSS In JS의 근본적 한계

이제 Object Style을 기본적으로 사용한다 가정하고 단점들을 파보도록 하자.

CSS In JS의 근본적 한계라 하면, CSS 문법이 리터럴이 아니라는 것이다.

때문에 컬러코드는 기본적으로 에디터에서 picker등이 동작하지 않으며, CSS 유닛("px", "rem", "vw"등)과 값들("visible", "space-between" 등)을 String으로 취급하지 않고는 사용할 수가 없다.

// 이하 css()를 클래스이름을 생성하는 임의의 CSS In JS 함수로 취급한다
const sample = css({
  // 색상
  color: "red",
  background: "#EEEEEE",

  // 단위
  fontSize: "16px",
  fontSize: "1rem",

  // 값
  visibility: "visible",
  justifyContent: "space-between"
});

우선, 이 중에서 컬러코드는 확장기능(VS Code, Emacs) 덕분에 어느정도 해결이 가능하다.

단위 기능을 CSS가 아닌 범용 언어에서 구현이 가능하냐고 묻는다면 러스트글에도 적었지만 F#은 구현해두었다.

타입시스템과 언어 구문의 지원이 필요하지만 진지하게 UI와 스타일링을 다루려면 필요한 기능이라 생각된다.

let dpiValue = 150.0<dpi>
let inchValue = 8.0<inch>
let pxValue = 1200.0<px>

CSS의 각 단위에 대한 변환은 내가 포크해서 작성해둔 라이브러리를 참고하면 된다.

이 대신 잇몸으로..

px과 같이 일반적인 값을 받는 속성이라면, JSS의 default-unit이나 Vanilla Extract의 unitless property처럼 정의 할 수는 있겠다.

const sample = css({
  // cast to pixels
  padding: 10,
  marginTop: 25,

  // unitless properties
  flexGrow: 1,
  opacity: 0.5
});

속성의 이름을 지을때도 한계가 있다.

파싱 문제로 인해 특수기호 중 '$'와 '_'만이 사용가능하고 "::before"이나 ".my-selector"처럼 다른 특수기호가 들어갈 경우에는 "로 감싸줘야 동작한다.

const sample = {
  $name$: "$ is literal",
  _name_: "_ is literal",
  "::before": "is not literal",
  ".my-selector": "is not literal"
};

SCSS와 중첩구문

SCSS가 선도한 부분은 중첩구문이다.

길다란 font-size, font-weight 속성을 중첩 가능하도록 만들고, &를 이용해 직관적인 셀렉터 중첩도 지원한다.

.sample {
  width: 200px;
  font: {
    /* 속성중첩 */
    size: 10px;
    weight: bold;
  }

  /* 셀렉터 중첩 */
  p {
    color: red;
  }
  &:hover p {
    background: blue;
  }
  a & {
    background: grey;
  }
}

다음은 컴파일된 결과.

.sample {
  width: 200px;
  font-size: 10px;
  font-weight: bold;
}
.sample p {
  color: red;
}
.sample:hover p {
  background: blue;
}
a .sample {
  background: grey;
}

CSS In JS에서는 다음과 같이 할 수 있을 것 이다.

단일 값은 속성의 값으로 취급
값이 객체 형식일때, 속성에 "&"이 포함되면 셀렉터로 취급
Emotion의 방식이며, Vanilla Extract의 complex selector 방식은 중첩을 강요해 별로라고 생각한다
값이 객체 형식일때, 속성에 "&"이 포함되지 않으면 중첩 프로퍼티로 취급

const sample = css({
  width: 200,
  font: {
    size: 10,
    weight: "bold"
  },

  "& p": {
    color: "red"
  },
  "&:hover p": {
    background: "blue"
  },
  "a &": {
    background: "grey"
  }
});

Default unit의 예처럼 무언가 간단하게 만들 수 있지 않을까?

Vanilla Extract에서는 Simple pseudo selectors라 하여 Pseudo-classes와 Pseudo-elements는 "&" 표시가 없어도 되게 만들었다. (자식 선택자 ">"나 "[attribute]"에도 적용될 수 있다)

:hover나 ::before는 대부분의 경우 부모요소를 사용하므로 더 나은 기본값이라 할 수 있다.

그러나 파싱 문제 때문에 "로 감싸는 구문을 강요한다는 문제가 있다.

const sample = css({
  ":hover": {
    background: "blue"
  },
  "::before": {
    background: "grey"
  }
});

Panda CSS는 _로 시작하는 Conditional Styles을 가지고 있다. ('_'과 '$'만이 속성이름으로 자유롭게 사용할 수 있다)

또한 조건 스타일때 base 속성은 원본에 적용되도록 하여 관심사를 모을 수 있는 Property based condition 중첩구문을 지원한다.

Panda CSS 접근법의 문제라면 _dark가 &.dark, .dark &를 의미하는 것처럼 임의의 클래스를 삽입하는 Adhoc스러움이다.

이는 프레임워크를 위한 프리셋이면 모를까 리터럴 구문으로 적용하기에는 맞지 않다.

대신 _가 :으로 치환되는 방식을 사용함이 낫다.

추가된 규칙을 정리해보자.

값이 객체 형식일때, 속성의 시작이 "_"과 "__"일 경우 각각 ":"과 "::"로 대체
값이 객체 형식일때, 속성의 시작이 ":"일 경우 "&:"로 컴파일
값이 객체 형식일때, base나 presudo 셀렉터를 적용가능

const sample = css({
  background: "#EEEEEE",
  _hover: {
    background: "blue"
  },
  __before: {
    background: "grey"
  },

  // 또는
  background: {
    base: "#EEEEEE",
    _hover: "blue",
    __before: "grey"
  }
});

감이 좋은 사람이라면, 무언가 이상하다는 점을 알아차렸을 것이다.

속성 중첩과 조건 중첩이 충돌할 수 있다는 점이다.

다행히 "base"와 동일한 이름을 가지는 속성이 없으므로 충돌하지 않는다.

const sample = css({
  width: 200,
  margin: {
    // 속성 중첩
    base: "5% 0",
    block: "0.5rem",
    inline: "3%",

    // 조건 중첩
    _hover: "6% 0",
    __before: {
      base: "2rem 3rem",
      block: "2rem",
      inline: "3rem"
    }
  },
});

비교적 사용이 적을 프로퍼티 중첩의 이름 마지막에 $가 있으면 명시적으로 사용하는 방식도 생각해보았지만, 오히려 어색했다.

const sample = css({
  width: 200,
  margin$: {
    block: "0.5rem",
    inline: "3%",
    __before: {
      block: "2rem",
      inline: "3rem"
    }
  },

  margin: {
    base: "5% 0",
    _hover: "6% 0",
    __before: base: "2rem 3rem"
  }
});

여러가지 셀렉터를 함께 사용할 때는 속성에 ","가 있을 때를 감지해 split하면 된다.

값이 객체 형식일때, 속성에 ","이 포함되어 있으면 여러 셀렉터가 있음

const sample = css({
  "_hover, _active": {
    color: "red"
  }
});

Less와 속성 병합

Less의 가장 큰 특징은 lazy하다는 점이다.

그러나 자바스크립트는 strict함이 기본이기에 좋지 않은 방식이라 CSS In JS에 적용하기에는 좋지 않은 방식이라 생각한다.

import하는 방식도 재미있지만, 자바스크립트 세계에서는 번들러가 해줘야 할 일이라고 생각한다.

변수 이름 기반 참조도 마찬가지다.

window["VAR_NAME"] 또는 this["VAR_NAME"]처럼 참조할 수는 있지만, 너무 비직관적이고 실수를 조장한다고 생각한다.

C언어의 포인터에서 헷갈리는 사람들이 많음을 감안해보자.

/* 일관성을 위해 SCSS 구문처럼 사용 */
$primary: green;
.section {
  $color: primary;

  .element {
    color: $$color; /* green */
  }
}

하지만 Merge properties은 꽤 유용해보인다.

box-shadow나 transform처럼 길다란 속성들은 한줄로 작성하기가 어려웠기 때문이다.

.sample {
  /* Merge with Comma */
  box-shadow+: inset 0 0 10px #555;
  box-shadow+: 0 0 20px black;

  /* Merge with Space */
  transform+_: scale(2);
  transform+_: rotate(15deg);
}

.sample {
  box-shadow: inset 0 0 10px #555, 0 0 20px black;
  transform: scale(2) rotate(15deg);
}

자바스크립트에서 특수문자는 앞서 언급했듯이 _와 $만 사용가능하다.

스페이스는 _과 비슷하므로 콤마에는 $을 붙이는게 좋을듯 하다.

속성 이름의 마지막에 '$'가 있으면 이어지는 속성을 콤마로 합치고, '_'가 있으면 스페이스로 합친다

const sample = css({
  /* Merge with Comma */
  boxShadow$: "inset 0 0 10px #555",
  boxShadow$: "0 0 20px black",

  /* Merge with Space */
  transform_: "scale(2)",
  transform_: "rotate(15deg)"
});

CSS In JS 세계(Emotion, Vanilla Extract)에서는 속성 값의 Fallback을 위한 고유한 접근법도 있다.

const sample = css({
  // In Firefox and IE the "overflow: overlay" will be
  // ignored and the "overflow: auto" will be applied
  overflow: ['auto', 'overlay']
});

.sample {
  overflow: auto;
  overflow: overlay;
}

위의 구문들도 배열을 사용해버리면 어떨까?

값이 배열일 때 일반적인 경우면 Fallback으로 취급
$로 끝나면 ','로 이으며, _으로 끝나면 공백으로 이음

const sample = css({
  overflow: ["auto", "overlay"],
  boxShadow$: ["inset 0 0 10px #555", "0 0 20px black"],
  transform_: ["scale(2)", "rotate(15deg)"]
});

또는 griffel의 shorthands처럼 함수를 제공할 수도 있다.

Stylus와 참조

Stylus는 참조에 대한 아이디어가 재미있다.

/* 역시 SCSS 구문처럼 수정됨 */
.sample {
  &_level1 {
    &_level2 {
      /* 루트 */
      ^[0]:hover {
        width: 0px;
      }

      /* 정방향 */
      ^[1]:hover {
        width: 1px;
      }
      ^[2]:hover {
        width: 2px;
      }
      

      /* 역방향 */
      ^[-1]:hover {
        width: -1px;
      }
      ^[-2]:hover {
        width: -1px;
      }
    }
  }
}

그러나 깊이를 숫자로 표현하면 Less의 변수 이름기반 참조처럼 혼동이 올 여지가 커보인다.

.sample:hover {
  width: 0px;
}

.sample_level1:hover {
  width: 1px;
}
.sample_level1_level2:hover {
  width: 2px;
}

.sample_level1:hover {
  width: -1px;
}
.sample:hover {
  width: -2px;
}

대신 XPath와 비슷한 경로 기반 참조는 사용하기 좋아보인다. (CSS In JS에 적합하지 않다고 생각하지만..)

.sample
  &_level1 {
    &_level2 {
      /* 항상 루트 참조 */
      /:hover {
        width: 0px;
      }

      /* 항상 첫번째 참조 */
      ~/:hover {
        width: 1px;
      }

      /* 상대 참조 */
      ../:hover {
        width: 2px;
      }
    }
  }
}

:hover {
  width: 0px;
}
.sample:hover {
  width: 1px;
}
.sample_level1:hover {
  width: 2px;
}

다른 라이브러리중에서는 JSS의 셀렉터 참조의 아이디어도 좋아보인다.

const styles = {
  container: {
    // Reference the local rule "button".
    '& $button': {
      padding: '10px'
    },
  },
  button: {
    color: 'grey'
  }
}

.container-0:focus .button-1 {
  color: blue;
}
.button-1 {
  color: grey;
}

문제는 앞서 속성에 "&"이 포함되야 셀렉터로 취급한다고 정의했기 때문이다.

그렇다면 어떻게 해결할 수 있을까?

답은 Vanilla Extract의 셀렉터 참조 방식이다.

const parent = css({
  width: "1px"
});

const child = css({
  [`${parent} &`]: {
    width: "2px"
  }
});

.parent {
  width: 1px;
}
.parent .child {
  width: 2px;
}

이 방법은 시스템적으로 중첩을 줄이는 설계를 권장하므로 좋다.

문제는 Vanilla Extract가 그렇듯 상호 참조가 일어날때는 접근자를 사용해야 할 필요가 있다.

const parent = css({
  [`&:hover ${child}`]: {
    width: "1px"
  }
});
const child = css({
  get [`${parent} &`]() {
    return {
      width: "2px"
    }
  }
});

.parent:hover .child {
  width: 1px;
}
.parent .child {
  width: 2px;
}

이럴때는 JSS의 방식으로 돌아가보자.

클래스가 첫번째 레벨에만 있다고 가정한다면 (Vanilla extract의 styleVariants, Griffel의 makeStyles)

JSS와 같이 로컬 규칙에서 명시적으로 참조할 수 있지 않을까?

이를 다루어주는 함수를 하나 추가하자.

const classes = cssVariants({
  parent: {
    ":hover $child": {
      width: "1px"
    }
  },
  child: {
    "$parent &": {
      width: "2px"
    }
  }
});

selector 참조기능에 대한 탐색을 충분히 한 것 같다.

속성값 참조는 어떨까? stylus에서 완성도 있게 제공하고 있다.

.sample {
  width: 100px;
  margin-left: @width;
  margin-top: -(@width / 2);
}

.sample {
  width: 100px;
  margin-left: 100px;
  margin-top: -50px;
}

CSS In JS에서는 어떻게 기능을 제공할 수 있을까?

그냥 참조할 때는 Stylus와 똑같이 해도 되겠지만, 계산이 필요한 경우에는 명시적인 계산을 하도록 해야 한다.

const sample = css({
  width: 100,
  marginLeft: "@width",
  marginTop: "calc(-(@width / 2))"
});

컴파일 되기 전 중간 형식은 역시 접근자를 활용하면 쉽게 구현할 수 있다.

const sample = css({
  width: 100,
  get marginLeft() {
    return this.width;
  }
  get marginTop() {
    return -(this.width / 2);
  }
});

PostCSS와 CSS 확장

3대 CSS 전처리기를 살펴보았는데, 뒤따라 항상 언급되는 존재가 있다.

바로 CSS계의 Babel인 PostCSS.

그 중에서도 postcss-preset-env는 기본값으로 다양한 문법을 확장해준다.

예를 들어 간편한 미디어쿼리 범위가 있다.

@media (480px <= width < 768px) {
  .sample {
    font-family: system-ui;
  }
}

@media (min-width: 480px) and (max-width: 767.98px) {
  .sample {
      font-family: system-ui, -apple-system, Segoe UI, Roboto, Ubuntu, Cantarell, Noto Sans, sans-serif;
  }
}

벤더 prefix도 적절히 잘 해주니, 기본값으로 설정 후 세부적인 룰은 유저들에게 맡기면 될 것 같다.

정리

좋다. 이제 (가상)CSS In JS의 리터럴 구문이 탄생했다.

이해를 돕기위한 예일 뿐이므로, 보통은 다음처럼 길게 중첩될일이 없을 것이다.

const sample = cssVariants({
  parent: {
    width: 200, // Unitless
    margin: {
      // 속성 중첩
      base: "5% 0",
      block: "0.5rem",
      inline: {
        base: "3%",
        "h1 &, & div": "4%" // 셀렉터 중첩
      },

      // 조건 중첩
      _hover: "6% 0",
      __before: {
        block: "2rem",
        inline: "calc(@block / 2)" // 속성 참조
      }
    }
  },
  child: {
    // 셀렉터 참조
    "$parent &": {
        overflow: ["auto", "overlay"],  // Fallback
        boxShadow$: ["inset 0 0 10px #555", "0 0 20px black"], // 콤마로 속성 병합
        transform_: ["scale(2)", "rotate(15deg)"]  // 공백으로 속성 병합
    },
    // PostCSS 연계
    "@media": {
      "width < 480px": {
        font-family: system-ui
      },
      "480px <= width < 768px": {
        color: color-mix(in lch, purple 50%, plum 50%)
      }
    }
  }
});

.parent {
  width: 200px;
  margin: 5% 0;
  margin-block: 0.5rem;
  margin-inline: 3%;
}
h1 .parent,
.parent div {
  margin-inline: 4%;
}

.parent:hover {
  margin: 6% 0;
}
.parent::before {
  margin-block: 2rem;
  margin-inline: 1rem;
}

.parent .child {
  overflow: auto;
  overflow: overlay;
  box-shadow: inset 0 0 10px #555, 0 0 20px black;
  transform: scale(2) rotate(15deg);
}

@media (max-width: 479.98px) {
  .child {
    font-family: system-ui, -apple-system, Segoe UI, Roboto, Ubuntu, Cantarell, Noto Sans, sans-serif;
  }
}
@media (min-width: 480px) and (max-width: 767.98px) {
  .child {
    color: rgb(175, 92, 174);
  }
}

설계가 꽤 합리적이지 않은가?

CSS-to-vanilla-extract처럼 변환해주는 툴링이 있으면 더욱 편히 사용할 수 있을 것이다.

스타일 합성: 동적 케이스

합성(Composition)

방금 전 리터럴 구문은 사실상 CSS 클래스 1개일때를 위한 문법이다.

function Sample() {
  return <div className={css({ color: "red", padding: 3 })}>내용</div>;
}

현실적으로는 여러가지 클래스가 사용되기 마련이다.

function Sample() {
  const activate = useState(true);
  return <div className={`class1 class2 ${activate && "class3"}`}>내용</div>;
}

이럴때 필요한 방식이 합성이다.

Emotion, Vanilla Extract등에서 사용되어 검증된 방법.

function Sample() {
  const activate = useState(true);
  return <div className={css(["class1", "class2", activate && "class3"])}>내용</div>;
}

API Wrapper로만 만들면 상관없겠지만..

모든 부분을 직접 구현하려면, Vanilla Extract가 언급하듯 단일 클래스로 컴파일 되어야 특이도 문제가 생기지 않는다.

The Shorthand-Longhand Problem in Atomic CSS라는 글도 읽어봄직하다.

const base = css({ padding: 12 });
const primary = css([base, { background: "blue", "p &": { color: "red" } }]);

.base {
  padding: 12px;
}
.primary {
  background: blue;
}
p .primary {
  color: red;
}

UI = f( State )

리엑트와 Flutter가 주장하듯 UI는 함수라고 생각할 수 있다.

플루터

그렇다면 Style이 함수가 아닐 이유가 있는가?

Fela의 접근법과 동일하며, 이 철학에 따라 Flutter는 Padding도 위젯으로 구현한다.

const sample = css((props) => ({
  color: "red",
  background: props.bgColor
}));

function Sample() {
  return <div className={sample({ bgColor: "blue" })}>내용</div>;
}

평가된 CSS는 다음과 같아야 할 것이다.

.sample {
  color: red;
}
.sample_background_wnefh {
  background: blue;
}

이렇게 만들어두면 다양한 케이스에 대응 가능할 것이다.

sample({ bgColor: "#fff" })처럼 다른 색상이 사용되면 새로운 클래스 생성
sample()처럼 값이 들어있지 않은 경우에 .sample만 평가되어 사용

리엑트의 컨텍스트를 활용하는 Lucid도 재미있지만 이 방식이 더 깔끔하다고 생각한다.

대신 property가 함수일때는 함수를 평가하는 방식을 지원하는 방법은 좋을 수도?

const sample = css({
  color: "red",
  background: (props) => props.bgColor
});

function Sample() {
  return <div className={sample({ bgColor: "blue" })}>내용</div>;
}

한가지 문제는 return 타입 추론이 어려워진다는 점이다.

때문에 이렇게 다이나믹한 경우는 항상 함수로 return하는 함수로 분리를 할 수도 있다.

// 함수가 인수이므로 타입추론 가능
const sample1 = css(({ color }) => ({
  color
}));

// 속성이 함수면???
const sample2 = css({
  color: ({color}) => color
});

대략 이렇게 해보자는 이야기입니다.

// string(class이름) 반환
const static = css({
  color: "red",
});

// function 반환
const dynamic = rules(({ color }) => ({
  color,
  background: ({ bg } = { bg: "blue" }) => bg
}));

function Sample() {
  return <>
    <div className={
  // 항상 sting 반환
  css([
    static,
    dynamic,  // background: blue로 자동평가
    dynamic({ // background: #222로 class 생성
      bg: "#222"
    }),
    dynamic({ // color: white, background: blue
      color: "white"
    })
  ])
  }>내용</div></>;
}

이제 Mixin이 하는 일의 상당부분도 커버할 수 있게 되었다!!

인라인 CSS: 시각적 위계

인라인과 AtomicCSS의 장단점

시대를 거슬러 올라가 인라인 스타일을 사용하던 시대를 상상해보자.

<p>일반 텍스트<span style="color: red; text-decoration: underline">빨간색과 밑줄</span></p>

인라인하는 방식이 작성하기는 쉬웠으나 여러 단점들이 있었다.

미디어 쿼리, 선택자, 의사요소, 애니메이션등의 기능제한
반복적으로 작성해야 하며, 문서의 사이즈도 커짐
컨텐츠와 서식의 분리가 불가능
길어져서 읽기가 힘듦
의미의 구분이 어려움

다행히 1번과 2번 문제는 Atomic CSS(또는 Utility first)기반의 프레임워크들(Tailwind, Windi CSS, Uno CSS, )이 나오면서 해결되었다.

첫번째는 문법을 클래스로 만들어 버리는 것이다.

게다가 Atomic CSS 고유의 장점이 생겼으니, 클래스이기 때문에 다음에서 "text-red-600"처럼 동일한 시각적인 요소를 가질경우 한번만 정의가 된다.

<p>일반 텍스트<span class="text-red-600 decoration-solid">빨간색과 밑줄</span></p>
<div class="text-red-600 bg-white">요소 1</div>

때문에 장기적으로 CSS 파일의 크기가 줄어들 수 있다.

위의 이미지에 있는 것처럼 타이핑 줄이기와 편리한 문법도 장점이며,

CSS 자체와는 디커플링이 되므로 text-red-600이 머터리얼 컬러시스템의 빨간색에서 부트스트랩 컬러시스템의 빨간색으로 바뀐다고 하여도 변경하지 않아도 된다.

또한 TailwindCSS처럼 체계적으로 스타일들을 미리 만들어두면 개발자는 값을 가져다가 쓰기만 하면 그만이다.

반복되는 표현? tailwind의 @apply 같은게 있다면 해결할 수 있으며, 의미론적인 표현도 어느정도 달성할 수 있다.

.select2-dropdown {
  @apply rounded-b-lg shadow-md;
}
.select2-search {
  @apply border border-gray-300 rounded;
}
.select2-results__group {
  @apply text-lg font-bold text-gray-900;
}

이로서 인라인 기능제한과 반복적 표현 문제를 어느정도 피하고 편리한 유틸들이 생겨나는등 장점이 있지만,

한편으로는 Atomic CSS 고유의 단점들도 생긴다.

미리 만들어두는 스타일들을 사용하게 되면 커스텀이 어려워지고, 프레임워크의 독단적인 문법을 사용하므로 기존 CSS 지식을 사용하기 어려워진다.

독단적인 문법이므로 타입시스템 활용이나 코드 하이라이팅도 상대적으로 어렵다.

이제 한번 정리해두고 가자.

장점

다양한 CSS 기능 사용 가능
타이핑을 줄이고, 편리한 문법 사용 가능
CSS의 시각적 값들을 중앙에서 조정 가능
체계적으로 만들어졌을 때 값을 가져다가 쓰기만 하면 됨
특정한 크기 이상 부터는 컴파일 결과가 완만히 증가

단점

커스텀과 임의의 CSS 작성이 어려움
CSS에서 알던 속성들과 지식 활용이 어려운 독단적 문법
타입시스템과 하이라이팅 활용이 어려움
여전히 반복적으로 작성 (기존)
컨텐츠와 서식의 분리가 불가능 (기존)
의미의 구분이 어려움 (기존)

AtomicCSS 개념분해와 역할

여기서 여러가지 이슈가 혼재함을 알 수 있다.

자체적 문법
- 장점: 다양한 CSS 기능을 사용 가능하게 하고, 구문을 짧게 줄여 편리
- 단점: CSS에서 알던 문법과 다르고, 타입시스템과 하이라이팅 활용이 어려움
속성의 이름과 값
- 장점: 타이핑을 줄이며, CSS의 시각적 값들을 중앙에서 조정 가능
- 단점: CSS에서 알던 속성과 값을 활용하기 어려움
프레임워크
- 장점: 체계적으로 만들어졌을 때 값을 가져다가 쓰기만 하면 됨
- 단점: 커스텀이 어려움

먼저 자체적 문법에 대해 생각해보자.

리터럴 문법과 비교했을때 "다양한 CSS 기능을 사용 가능"이 장점이 될 수 있는가?

아니다.

그렇다면 구문을 짧게 줄여주기 정도만 장점이 되고,

오히려 기존 문법과 다르다거나, 타입시스템과 하이라이팅 활용의 어려움처럼 해결하기 어려운 근본적인 문제가 생겨난다.

자체문법은 아쉽지만... 버려야만 한다.

!important -> !처럼 간단한 문법은 CSS In JS 컴파일 과정이나 PostCSS Plugin으로 제공해 충분히 해줄수 있다.

이제 2가지만이 남았다.

프레임워크와 메타-프레임워크 구성을 위한 속성과 값 매핑 도구.

결국 AtomicCSS가 존재하는 목적은 인라인 CSS와 같은 시각적인 매핑이다.

앞서 @apply를 통해 의미론적으로 만들수는 있다고 했지만,

의미론적인 방법을 제대로 사용하려면 daisyUI처럼 프레임워크를 새로 재창조하는 수준을 거쳐야 한다.

<button class="bg-indigo-600 px-4 py-3 text-center text-sm font-semibold inline-block text-white cursor-pointer uppercase transition duration-200 ease-in-out rounded-md hover:bg-indigo-700 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-indigo-600 focus-visible:ring-offset-2 active:scale-95">
  Tailwind Button
</button>

<button class="btn btn-primary">
  daisyUI Button
</button>

따라서 AtomicCSS에서 @apply같은 합성구문은 시각적 요소를 결합되는 용도로 사용해야지,

어중간하게 의미론을 따지려하지 말아야 한다.

프레임워크와 메타-프레임워크 구성을 위한 디자인 토큰 생성과 속성과 값 매핑 도구만으로 사용하자는 것 이다.

시각적 요소의 결합으로 설명할 수 있는 대표적인 예는 텍스트 색과 배경색을 들 수 있다.

라이트모드와 다크모드까지 고려했을 때 4가지의 클래스를 하나로 묶어취급함은 괜찮지 않은가?

text-black bg-white
dark:text-white dark:bg-gray-900

어찌되었건 위계가 다르다면 배중률이 적용되며, 다른 레이어에서 전문적으로 다루도록 하자.

AtomicCSS 프레임워크와 테마

시각적 표현을 위한 좋은 프레임워크의 조건은 무엇이 있을까?

색, 폰트, 간격, 레이아웃, 반응형등 다양한 시각적 요소를 다룸
시각적 요소들의 구성이 체계적이어야 함
특정 까다롭거나 반복적인 패턴들은 묶어서 제공
관용적인 프리셋 값들

시각적 요소와 구성

이 중에서 1번과 2번은 기본적으로 스타일가이드 이야기에 가까우므로 프로그래머 관점에서 다루는 글의 범위를 넘어선다. ~~하고픈 이야기는 있지만..~~

대신 알아두어야 할 점은 구성에 있어 각종 스펙과 룰을 정한다는 것은 기본적으로 top-down 형태의 일이라는 점이다.

대표적인 스펙으로는 W3C 디자인토큰, Styeld System과 ThemeUI를 들 수 있다.

예를 들어 다음과 같은 스펙이 있다고 가정해보자.

const theme = {
  spaces: [0, 4, 8, 16, 32, 64],
  colors: {
    text: "#000",
    background: "#fff",
    primary: "#07c"
  }
};

space와 colors는 Theme key라 할 수 있다.

그리고 각 테마키의 값들은 특정한 CSS 프로퍼티들에서 사용될 수 있다.

Styled System 기준으로 사용되는 프로퍼티 규약을 적용했을 때 다음과 같다.

space는 margin, padding, gird-gap 등에 사용
colors는 color, background-color, border-color에 사용

예컨대 background-color: "primary"와 border-color: "primary"는 "#07c"라는 색상을 사용하게 되는 것이다.

사실 테마쪽은 Vanilla Extract가 너무나도 작업을 잘해놓았기 때문에 소소한 개선만 필요할뿐, 특별한 불만이 없다.

하지만 단일값, 배열, 중첩등을 테마가 충분히 다룰 수 있기 때문에 우선 확장했다.

그리고 직접 값을 다루기 위해 values를 추가했다.

const { className: themeClass, vars, values } = theme({
  // 단일
  rootSize: "10px",

  // 배열
  spaces: [0, 4, 8],

  // 중첩
  colors: {
    text: "#000",
    background: "#fff",
    indigo: {
      600: "#4f46e5",
      700: "#4338ca"
    }
  }
});

const { className: otherThemeClass } = theme(vars, {
  rootSize: "1rem",
  spaces: [0, 2, 4],
  colors: {
    // text는 그대로 활용
    background: "blue",
    indigo: {
      600: "#5a46e5",
      700: "#4338ca"
    }
  }
});

위의 JS와 CSS는 각각 다음 모습과 같을 것이다.

const themeClass = "themeClass";
const otherThemeClass = "otherThemeClass";

const themeClassValues = {
  rootSize: "var(--rootSize)",
  spaces: ["var(--spaces-0)", "var(--spaces-1)", "var(--spaces-2)"],
  colors: {
    text: "var(--colors-text)",
    background: "var(--colors-background)",
    indigo: {
      600: "var(--colors-indigo-600)",
      700: "var(--colors-indigo-700)"
    }
  }
};

const themeClassValues = {
  rootSize: "10px",
  spaces: [0, 4, 8],
  colors: {
    text: "#000",
    background: "#fff",
    indigo: {
      600: "#4f46e5",
      700: "#4338ca"
    }
  }
};

const otherThemeClassValues = {
  rootSize: "1rem",
  spaces: [0, 2, 4],
  colors: {
    text: "#000",
    background: "blue",
    indigo: {
      600: "#5a46e5",
      700: "#4338ca"
    }
  }
};

.themeClass {
  --rootSize: 10px;

  /* 자동적 변환이 안됨!! */
  --spaces-0: 0;
  --spaces-1: 4;
  --spaces-2: 8;

  /* 중첩은 속성이 이어써짐 */
  --colors-text: #000;
  --colors-background: #fff;
  --colors-indigo-600: "#4f46e5";
  --colors-indigo-700: "#4338ca";
}

.otherThemeClass {
  --rootSize: 1rem;

  --spaces-0: 0;
  --spaces-1: 2;
  --spaces-2: 4;

  --colors-text: #000; /* 재활용된 text */
  --colors-background: blue;
  --colors-indigo-600: "#5a46e5";
  --colors-indigo-700: "#4338ca";
}

CSS 결과물을 상상해보는 과정에서 한가지 문제를 발견했다.

자동 변환이 작동하지 않는다.

어쩌면 당연한게 현재 상태로 적용될 property를 알 수 없기 때문이다.

대신 언급했던 W3C 스펙을 가지고 계약에 의한 토큰 설계를 할 수 있을 것이다.

const { className: themeClass, contracts } = theme({
  spaces: tokenConstract({
    $type: "dimension",
    $value: [0, 4, 8]
  }),
  colors: tokenConstract({
    $type: "color",
    $value: {
      text: "#000"
    }
  })
});

const myContracted = themeContract({
  spaces: {
    $type: "dimension"
  },
  colors: {
    text: {
      $type: "color"
    }
  }
})

// contracts나 myContracted 사용, 이제 자동 변환이 수행된다
const { className: newThemeClass } = theme(contracts, {
  spaces: [3, 6, 9],
  colors: {
    text: "#888"
  }
});

이제 테마의 마지막이다.

하지만 설계를 크게 바꾸어야 할 문제다.

참조를 하고 싶을 때는 어떻게 해야 하지?

const { vars } = theme({
  rootSize: "10px",
  get newSize() { return this.rootSize },

  spaces: [0, 4, 8],
  spaces: {
    small: &spaces[0],
    medium: &spaces[1],
    large: &spaces[2]
  },
});

newSize는 rootSize와 똑같은 기본값을 가지는 새로운 값을 만들고 있고,

두번째 space는 답이 없어보인다.

물론 다음과 같이 할 수 있긴 하다 ㅋㅋ

const { vars } = theme({
  spaces: defineProperty([0, 4, 8], {
    small: (arr) => arr[0],
    medium: (arr) => arr[1],
    large: (arr) => arr[2]
  }),
});

function defineProperty(arr, properties) {
  const customProperties = Object.keys(properties).reduce((acc, key) => {
    acc[key] = {
      get: function () {
        return properties[key](this);
      }
    };
    return acc;
  }, {});

  return Object.defineProperties(arr, customProperties);
}

다만 유저가 원하는 방식은 아닐 것이다.

따라서 라이브러리가 자동적으로 수행하도록 theme()를 변경해야 할 필요가 있다.

다음은 내가 새로 제안하는 Theme 함수 제안이다.

consts: 규약되고 JS에서 값은 존재하나, var()로 사용되지 않는 값들
values: 규약되고, var()로 나타나는 값들
alias: 새로운 var가 생기지 않고, 자바스크립트 상에서만 참조함
fallbacks: values에 있는 값들을 참조할 때
clones: values와 기본값만 같고, 런타임에 상호변경 여지가 있을 때

const { vars } = theme({
  // 상수
  consts: {
    constSize: "50%"
  },

  // 메인 값들
  values: {
    rootSize: "10px",
    spaces: tokenConstract({
      $type: "dimension",
      $value: [0, 4, 8]
    })
  },

  // 기존 var()를 사용하고 자바스크립트 상에서만 참조
  alias: ({ spaces }) => ({
    spaces: {
      // 구조는 동일해야 vars.spaces.small 처럼 사용가능
      small: spaces[0],
      medium: spaces[1],
      large: ({ spaces }) => spaces[2] // 각 속성마다 할 수도
    }
  }),

  // 새로운 var을 생성하지만 참조함
  fallbacks: ({ rootSize }) => ({
    sameSize: rootSize,
    otherSize: [rootSize, "1rem"]
  }),

  // 기본 값만 같은 하드포크
  clones: ({ rootSize }) => ({
    newSize: rootSize
  })
});

.themeClass {
  /* Consts는 자바스크립트에서만 접근 가능 */

  --rootSize: 10px;

  /* tokenConstract에 의한 기본값 변환!! */
  --spaces-0: 0px;
  --spaces-1: 4px;
  --spaces-2: 8px;

  /* Alias는 자바스크립트에서만 접근 가능 */

  /* Fallback */
  --sameSize: var(--rootSize);
  --otherSize: var(--rootSize, 1rem);

  /* 기본값만 같음 */
  --newSize: 10px;
}

css var() 값을 런타임 중에 바꾸는 가장 쉬운 방법 중 하나는 Vanilla Extract의 Dynamic이라는 패키지를 사용하는 것이다.

다른 플랫폼으로 export가 필요할 경우는 아마존의 style-dictionary를 참고할 만하다.

까다롭거나 반복적인 패턴

SASS, Less, Stylus 같은 전처리들이 가지고 있는 각종 빌트인 함수들이 맨땅의 JS에게는 존재치 아니한다.

대신 우리에게 polished라는 매우 준수한 라이브러리가 있다.

이외에 AdorableCSS는 까다로운 Flexbox를 대체하기 위해 Autolayout와 Hbox, 까다로운 포지션 문제를 다루기 위해 PinLayout과 비슷한 Position Layer를 가지고 있다.

PandaCSS 마찬가지로 Container, Stack, Wrap, Aspect Ratio등을 위한 많은 패턴들을 가지고 있다.

미디어쿼리의 경우 css-in-js-media, vanilla-syrup, Sass MQ등처럼 편리하게 다룰 수 있는 것들이 있다.

Keyframe도 마찬가지(Vanilla Extract, Fela)

패턴뿐만 아니라 Box처럼 반복적인 패턴의 컴포넌트나 sanitize.css같은 reset 글로벌 스타일도 제공할 수 있다.

관용적인 프리셋 값들

관용적인 값들이란 무엇을 뜻할까?

첫째, 다음처럼 원본을 변형해도 알아볼만한 값들이다.

w = width h = height m = margin p = padding b = border r = border-radius
z = z-index bg = background c = color mt = margin-top pr = padding-right

둘째, mastercss의 반응형 디자인 기준처럼 다양한 상황을 다룰 수 있어야 한다.

@3xs = 360px, iPhone 6, 7, 8, X, 11, 12 / Galaxy S8 / HTC One…
@2xs = 480px, Blackberry Passport / Amazon Kindle Fire HD 7 …
@xs = 600px, LG G Pad 8.3 / Amazon Kindle Fire …
@sm = 768px, Microsoft Surface / iPad Pro 9.7 / iPad Mini …
@md = 1024px, iPad Pro 12.9 / Microsoft Surface Pro 3 …
@lg = 1280px, Google Chromebook Pixel / Samsung Chromebook …
@xl = 1440px, Macbook Air 2020 M1 / MacBook Pro 15 …
@2xl = 1600px, Dell Inspiron 14 series …
@3xl = 1920px, Dell UltraSharp U2412M / Dell S2340M / Apple iMac 21.5-inch …
@4xl = 2560px, Dell UltraSharp U2711 / Apple iMac 27-inch …

마지막으로 normalize.css에 reset.css의 더 나은 값을 사용하는 sanitize.css처럼 합리적이고 기본적인 값의 커버리지가 넓어야한다.

이제 AtomicCSS 메타-프레임워크 툴링을 구상해볼 차례다.

AtomicCSS 문법 쪼개기

갑자기 시각적 요소 프레임워크를 위한 툴을 만들자고 하니 어찌 접근해야 할지 감이 잡히지 않을 수도 있다.

그렇다면 어찌해야할까?

AtomicCSS 프레임워크가 제공하는 문법과 기능들을 보고 구현이 가능하도록 만들어주면 된다.

자체문법은 포기한다고 하지 않았나요?라고 묻는다면, AtomicCSS 프레임워크들이 제공하는 class 문법을 포기하자는 말이었지,

Javacript 문법을 기반으로 하여 재구성하지 않겠다는 의미는 아니었다.

AtomicCSS 프레임워크의 문법을 살펴보자.

다음은 위에서 나왔던Tailwind 버튼의 예시다.

<button class="bg-indigo-600 px-4 py-3 text-center text-sm font-semibold inline-block text-white cursor-pointer uppercase transition duration-200 ease-in-out rounded-md hover:bg-indigo-700 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-indigo-600 focus-visible:ring-offset-2 active:scale-95">
  Tailwind Button
</button>

총 4가지의 종류가 있음을 알 수 있다.

hover:bg-indigo-700
bg-indigo-600
px-4
uppercase

이를 제외하면 임의의 값과 mastercss의 그룹 정도가 있으며, 나머지 구문들은 모두 위의 파생일 뿐이다.

간단한 값부터 복잡하거나 예외적인 문법 순으로 거슬러 올라가보자.

먼저 가장 간단한 uppercase는 "uppercase" 혹은 { uppercase: true }정도로 사용할 수 있으면 될 것이다.

px-4는 { px: 4 }로 사용할 수 있다.

그럼 bg-indigo-600은?

우선 속성인 bg와 값인 indigo-600으로 나누어 { bg: "indigo-600" }가 된다.

이때 indigo-600은 위에서 언급했던 테마의 색상으로 생각할 수 있으며, 타입시스템이 작용하도록 수정해야 할 필요가 있다.

{ bg: indigo[600] }이나 { bg: { indigo: 600 }}처럼 나타낼 수 있겠다.

hover:bg-indigo-700에서 특이점은 hover일텐데, 우리가 앞서 정의했던 리터럴 구문을 활용하면 쉽게 정의할 수 있다.

{ _hover: { bg: indigo[700] } }

임의의 값은 리터럴 CSS 값과의 합성을 하거나 Fallback을 할 수 있다.

그룹은 리터럴 구문의 중첩 기능을 사용하면 구현할 수 있다.

일단 합성을 고려하지 않고, 정리된 버전이다.

// 리터럴과 같은 이름 - 사용법도 같음
const { css } = defineRules({
  // 무언가 규칙정의
  // Value의 fallback 허용 활성화 가정
});
const sample = css({
  uppercase: true,
  px: 4,
  bg: indigo[600],
  _hover: {
    bg: indigo[700]
  },

  color: "#000", // Fallback 될 임의의 값
  "_hover, _active": {
    color: "red" // 중첩되어 그룹화된 값
  }
});

겉보기로는 간단해 보이긴 하나, 합성이 없어 아쉽고 indigo는 대체 어디서 생겨난 값인지 알 수 가 없다.

이는 숨겨진 복잡성이 예상외로 커 twind, twin.macro, sprinkles등 수많은 Atomic CSS in JS들이 있음에도 무엇하나 시원하게 해결하지 못했던 이유이다.

다행히 우리는 합성 파트의 통찰력을 따라갈 수 있다.

const { css } = defineRules({
  // ...
});
const sample = css([
  "uppercase",
  ({ indigo }) => ({
    px: 4,
    bg: indigo[600],
    _hover: {
      bg: indigo[700]
    },

    color: "#000",
    "_hover, _active": {
      color: "red"
    }
  })
]);

한가지 이상한 점이라면 함수를 사용하는데, css라는 이름이라는 점 때문이다.

하지만..아까 테마를 사용하기로 했죠?

직접 context를 노출해 주었다면 어떨까요?

const { vars: themeVars } = theme({
  // ...
  colors: {
    indigo: {
      600: "#4f46e5",
      700: "#4338ca"
    }
  }
});

const { css } = defineRules({
  contexts: {
    indigo: themeVars.colors.indigo
  }
  // ...
});

rules가 첫번째에 context, 두번째에 유저 인수를 받는 구조라면 말이 된다!!

const { css, rules } = defineRules({ /* ... */ });

// 정적
const static1 = css([
  "uppercase",
  {
    px: 4,
  }
]);

// 여전히 정적임
const sample2 = css([
  "uppercase",
  ({ indigo }) => ({
    bg: indigo[600],
    border: ({ indigo }) => indigo[700]
  })
]);

// 동적
const dynamic = rules([
  "uppercase",
  ({ indigo }, ({ size })) => {
    px: size,
    bg: (_, { bgColor }) => bgColor,
    
    color: indigo[600]
  }
]);

function Sample() {
  return (
    <div
      className={css([
        static1,
        static2,
        dynamic, // color: indigo[600]으로 자동평가
        dynamic({
          // color: indigo[600], px: 6
          size: 6
        }),

        // 함수 - indigo[600], bg: indigo[700]
        dynamic(({ indigo }) => {
          bgColor: indigo[700];
        })
      ])}
    >
      내용
    </div>
  );
}

디자인 토큰 매핑

본격적으로 구상해볼 차례이다.

지금까지 살펴본 옵션은 2가지였다.

fallback을 가능하게 해서 color: "#000"처럼 기본 CSS 값들을 쓸 수 있게 만들지(Strict mode 여부)와 context 제공.

// css, rules, variants등 함수 제공
const { css } = defineRules({
  strict: false, // 기본 CSS 문법들을 쓸 수 있게 strict 모드 해제
  contexts: {
    spaces: themeVars.spaces,
    indigo: themeVars.colors.indigo
  }
});

그런데 핵심적인 사안을 빼먹었다.

바로 padding-inline인 px와 background인 bg로 매핑하는 능력이다.

const { css } = defineRules({
  // rules에서 쓰였던 기능은 모두 사용 가능
  rules: {
    px: (value) => ({ paddingInline: theme.spaces[value] }),
    bg: {
      background: (value) => value
    },

    // 두번째 인수는 context
    px: (value, { spaces }) => ({ paddingInline: spaces[value] })
  }
});

px의 경우 theme.spaces에서만 가능한 값으로 제한이 되어있는 모습을 볼 수 있다.

원본 css값에도 할 수 있을까? 이는 Vanilla Extract의 sprinkles가 잘 해주고 있다.

const { css } = defineRules({
  // CSS에서 사용가능한 기능 제약
  properties: {
    // 배열에 있는 값만 허용
    display: ["none", "inline"],
    paddingLeft: theme.spaces,

    // 속성 전체
    color: true,   // strict: true 일때도 속성이 허용됨
    border: false, // strict: false 일때도 속성이 거부됨
  }
});

하나 더 찾아보자.

px는 padding-left, padding-right라고 생각할 수도 있다.

일전에 나온 griffel의 shorthands 상황처럼 제약이 있을 경우 paddingLeft, paddingRight 값을 연결해주어야 할 것이다.

const { css } = defineRules({
  shortcuts: {
    pl: "paddingLeft",
    pr: "paddingRight",
    px: ["paddingLeft", "paddingRight"],
  }
});

shortcuts에서 매핑한 속성을 활용하고 싶을수도 있다.

그리고 활용시 동적인 요소가 필요할 수 도 있다.

const { css } = defineRules({
  shortcuts: {
    px: ["paddingLeft", "paddingRight"],
    py: ["paddingTop", "paddingBottom"],

    p: ["px", "py"], // 생성되며 계산
    get p() { return [this.px, this.py]; }, // 순수 문법 활용

    p: (useY) => ["px", useY && "py"] // 함수
  }
});

이제 지나치게 정적인 Vanilla Extract나 무서운 규식이를 쓰는 uno보다 작성하기 편해보이지만,

무심코 빼먹은게 2개나 된다ㅠㅠ

단일 값: 계속 쓰여왔던 uppercase등 AdorableCSS에서 언급했던 유니크한 값들
조건부 스타일: Vanilla Extract sprinkles에 있는 그것, PandaCSS에서 리터럴로 있기에는 Ad-Hoc 하다며 비판했던 물건

조금 전까지 하던 작업들과 비슷한 단일 값부터 생각해봅시다.

기본적으로 원래 css 리터럴과 비슷하되, rules처럼 context 정도는 받아서 작업할 수 있다면 좋겠죠?

const { css } = defineRules({
  values: {
    uppercase: {
      textTransform: "uppercase"
    },
    indigoBG: ({ indigo }) => ({
      background: indigo[600]
    })
  }
});

마지막 조건부 스타일이다.

단일 셀렉터부터 Mixin과 비슷한 스타일까지 모두 가능하도록 구성했다.

const { css } = defineRules({
  defaultCondition: "light",
  conditions: {
    // 단일
    light: "",
    dark: "&.dark, .dark &",
    
    // 여럿
    dark: ["&.dark", ".dark &"],

    // 중첩
    osLight: {},
    osDark: { "@media": "(prefers-color-scheme: dark)" },

    // 함수
    hovAct: (children) => ({
      _hover: {
        base: {
          ...children
        },
        _active: {
          ...children
        }
      }
    })
  }
});

기존보다 확연히 나아졌지만, API의 설계가 일부 잘못된게 있다.

conditions를 그룹으로 묶었을 때, 3가지로 나타난다.

light-dark
osLight-osDark
hovAct

이때 light와 osLight가 동시에 기본값이 될 수는 없는 걸까?

그냥 배열로 표시하면 된다.

const { css } = defineRules({
  defaultCondition: ["light", "osLight"],
  conditions: { /* ... */ }
});

이제 편리한 방법으로 토큰들을 기존 속성들에 매핑할 수 있게 되었다.

하지만 관리의 문제는 아직 해결하지 못한다.

위의 방식대로라면 One big rules 파일이 되어 제어가 어렵기 때문이다.

Vanilla extract는 여기서 좋은 아이디어를 가지고 있다.

바로 여러 룰을 만든 후 합성이다.

Theme 정의를 할때처럼 규약들을 export하고 합치는 방법은 어떨까?

const { contracts: responsiveContracts } = defineRules({ /* ... */ });
const { contracts: colorContracts } = defineRules({ /* ... */ });

const { css, rules } = combineRules(responsiveContracts, colorContracts);

이제 상당히 쓸만해 보인다!!

다른 세부적인 유틸과 기능이 필요할 수도 있겠지만, 이 글은 큰 그림을 위주로 다루기에 이만 끝을 내도록 하자.

정리

AtomicCSS는 인라인 스타일에서 비롯된 방법이므로, 시각적 위계에 최적화 되어 있음을 알 수 있었다.

대표적으로 color: rgb(220 38 38);라는 값을 tailwind에서는 text-red-600만으로 표현해준다.

이는 시각적 위계의 결합도가 줄어드는 추상화라 할 수 있다.

지금은 .text-red-600가 rgb(220 38 38)일 수 있겠지만,

디자이너의 필요에 의해 rgb(250, 40, 40)과 같은 값으로 조정하면 전체 시스템에 바로 적용된다는 것이다.

이렇게 타이핑을 줄이고 한번의 추상화로 시각적요소들을 중앙 집중형으로 만들 수 있기도 하였지만 여러 문제가 파생하였다.

독단적인 문법이라 기존의 지식을 활용할 수 없이 배움을 강요하고, 타입시스템과 하이라이팅 활용이 어려웠다.

또한 이미 만들어진 시스템에 가까워 커스텀과 임의의 CSS 작성이 상대적으로 어려웠다.

마지막으로 중앙 집중형 시스템이지만, 효과적으로 제어해주는 시스템이 부실했다.

독단적 문법 문제는 타입스크립트를 활용하는 CSS In JS로 해결할 수 있다.

defineRuels는 기존의 커스텀이 어려웠던 시스템에서 벗어나, 도메인마다 bottom-up으로 정의하여 개별의 팀들이 사용할 수 있는 Meta Atomic Util이다.

대신 커다란 규칙을 만들때는 어려움이 있으므로, combineRules를 통해 결합할 수 있도록 했다.

하지만, 라이트모드와 다크모드 시스템의 전환이나 Accent 색의 변경을 한번에 수행하려면 어떻게 할까?

여기서 필요한게 중앙화된 규약의 존재며, Theme 정의가 빛을 발하는 지점이다.

쉽게 말해 일반적으로 defineRules는 key 수준에서 동작하며, Theme는 Value 수준에서 동작한다.

자, 새로운 Theme API를 정의했고, 디자인 토큰 매핑과 사용까지 총 3가지에 대한 재정의를 했다.

Variants - 의미론적 위계

들어서기

Tailwind와 daisyUI의 사용을 다시 한번 보자.

<button class="bg-indigo-600 px-4 py-3 text-center text-sm font-semibold inline-block text-white cursor-pointer uppercase transition duration-200 ease-in-out rounded-md hover:bg-indigo-700 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-indigo-600 focus-visible:ring-offset-2 active:scale-95">
  Tailwind Button
</button>

<button class="btn btn-primary">
  daisyUI Button
</button>

Tailwind 문법을 우리가 정의한 가상의 AtomicCSS 라이브러리로 순진하게 옮기면 대략 다음과 같이 표현할 수 있다.

const { css } = defineRules({ /* ... */ });
const buttonStyle = css([
  "uppercase",
  "transition",

  ({ indigo }) => ({
    bg: indigo[600],
    px: 4,
    py: 3,
    text: ["center", "sm"],
    font: "semibold",
    inline: "block",
    text: "white",
    cursor: "pointer",
    duration: 200,
    ease: "in-out",
    rounded: "md",
    _hover: {
      bg: indigo[700]
    },
    _focusVisible: {
      outline: "none",
      ring: {
        base: 2,
        color: indigo[600],
        offset: 2
      }
    },
    _active: {
      scale: 95
    }
  })
]);

그렇다면 daisyUI는 이렇게 표현할 수 없는걸까?

const button = Something({ /* ... */ });
const buttonStyle = button("primary");

또한 BEM의 Element와 Modifier를 이렇게 표현할 수는 없는걸까?

<form class="form form--theme-xmas form--simple">
  <input class="form__input" type="text" />
  <input
    class="form__submit form__submit--disabled"
    type="submit" />
</form>

<form class={ form(["base", "simple", { theme: "xmas" }]) }>
  <input class={ form("input") } type="text" />
  <input
    class={ form({ sumit: "disabled" }) }
    type="submit" />
</form>

클래스가 1개와 매핑되던 의미론을 넘어서, 응집력을 갖추게 된다.

게다가 "simple"과 theme: "xmas"가 동시에 존재해야 활성화하는 조건도 알아서 적용해준다고 상상 해봅시다.

이제부터 우리가 하려는 일이다.

기본기능

앞에서 약간은 동적으로 보일 수 있는 Variants라는 기능을 만든적이 있었다.

const classes = cssVariants({
  parent: {
    ":hover $child": {
      width: "1px"
    }
  },
  child: {
    "$parent &": {
      width: "2px"
    }
  }
});

가장 기본적인 사용법은 다음과 같을 것이다.

function Sample() {
  return (
    <div className={classes.parent}>
      <div> className={classes["child"]}></div>
    </div>
  );
}

합성과 함수를 사용하는 모습도 보일 수 있다.

const base = css({ padding: 12 });
const classes = variants({
  parent: [base, {
    width: "1px"
  }],
  child: ({width}) => ({
    width
  })
});

function Sample() {
  return (
    <div className={classes.parent}>
      <div> className={classes.child(5)}></div>
    </div>
  );
}

게다가 Vanilla Extract는 mapping하여 여러 Variants를 찍어내는 기능을 제공한다.

다음은 classes["small"]과 classes["large"]를 만들어낸다.

const base = css({ padding: 12 });
const classes = cssVariants(
  {
    small: "1rem",
    large: "10rem"
  },
  (size) => [base, { width: size }]
);

같은 네임스페이스를 가져 보기 응집력이 강화 되었고 함수를 사용할 수는 있지만,

앞선 작업들을 하려면 로직을 하나씩 작업해줘야 할 것 같다.

동적 Variants

Variants로 유명한 stitches는 일반 룰 정의하는 함수 내부에서 variants를 설정할 수 있다.

우리의 가상 라이브러리는 함수를 반환하는 rules에서 수행할 수 있다.

const sample = rules({
  color: "red",
  variants: {
    color: {
      white: {
        color: "white",
        background: {
          base: "black",
          _hover: "gray"
        }
      }
    },
    outlined: {
      true: {
        borderColor: "blue"
      }
    }
  }
});

function Sample() {
  return (
    <div className={sample({ color: "white", outlined: true })}>
      내용
    </div>
  );
}

그러나 사용법이 우리가 정의했던 방법에 비해서 약간 아쉽다. 개선해보자.

outlined의 경우 defineRules의 values처럼 toggleVariants블럭으로 옮긴 후, 호출시 배열을 활용해 직관적으로 만들 수 있다.

const sample = rules({
  color: "red",
  toggleVariants: {
    outlined: {
      borderColor: "blue"
    }
  },
  variants: { /* ... */ }
});

function Sample() {
  return (
    <div className={sample(["outlined", { color: "white" }])}>
      내용
    </div>
  );
}

variants 구현에 있어 기존 함수형 프로퍼티를 사용해보는건 어떨까?

앞서 말했듯 안타깝게도 variant 자체는 이미 switch-match 조건이 포함된 것과 다름 없기에 개선되기가 어렵다.

대신 함수형 프로퍼티를 사용하면 컨텍스트의 값을 받아서 처리할 수 있어서 서로 보완적이다.

// 똑같은 동작
const sample1 = rules((props) => {
  if("color" in props) {
    if(props.color == "white") {
      return ({
        color: "white",
        background: props.bgColor
      });
    }
  }
});

const sample2 = rules({
  variants: {
    color: {
      white: {
        color: "white",
        background: ({ bgColor }) => bgColor
      }
    }
  }
});

Stitches에 있는 Variant는 이게 끝이 아니다.

기본 Variants를 설정할 수 있음은 당연하고,

const sample = rules({
  // 기본값
  defaultsVariants: ["outlined", {
    color: "white",
  }],

  // Variants 들
  toggleVariants: {
    outlined: { /* ... */ }
  },
  variants: {
    color: {
      white: { /*... */ },
      gray: { /*... */ },
    }
    size: {
      small: { /* ... */ },
      big: { /* ... */ }
    }
  }
});

무려 조건에 따른 패턴 매칭이 들어가 스타일 적용로직을 선언적으로 만든다.

그리고 호출하면 컴파일 타임에 정적으로 클래스 이름이 생성된다.

const sample = rules({
  /* 위와 같음 */

  // 패턴 패칭 후 적용
  compoundVariants: [
    ["outlined", { color: "white", css: { /* YOUR_STYLE */ } ],
    {
      color: gray,
      size: small,
      css: { /* YOUR_STYLE */ }
    }
  ]
});

간단한 케이스는 기본 Variants의 이름 참조를 통해서도 가능할 것이다.

const sample = rules({
  variants: {
    color: {
      white: { /*... */ },
      gray: { /*... */ },
    }
    size: {
      small: { /* ... */ },
      big: {
        $white: {
          // CSS
        }
      }
    }
  }
});

아까 AtomicCSS에서도 적용 가능하지 않을까?

const { css } = defineRules({
  defaultCondition: "light",
  conditions: {
    light: "",
    dark: ["&.dark", ".dark &"],
    osLight: {},
    osDark: { "@media": "(prefers-color-scheme: dark)" },
    hovAct: (children) => ({
      _hover: {
        base: {
          ...children
        },
        _active: {
          ...children
        }
      }
    })
  },
  compoundConditions: [
    {
      when: ["light", "osLight"],
      condition: "&.pureLight"
    },
    {
      when: ["light", "hovAct"],
      condition: (children) => ({ /* Something */ })
    }
  ]
});

가지 않은 길

Stylable라는 CSS 전처리기의 Pseudo class를 보면 st-state라는 이름으로 흥미로운 기능을 제공한다.

Boolean 타입, Enum 타입, String과 Number 타입으로 나뉨
Enum은 특정한 문자열 인수만 가능하며, 기본값 정의 가능
String/Number 타입은 각각의 타입 인수에 관한 validation 함수들을 설정 가능

.sample {
  -st-states:
    /* Boolean 타입 */
    toggled,
    loading,

    /* Enum 타입 */
    size(enum(small, medium, large)),
    color(enum(red, green, blue)) green, /* green이 기본값 */

    /* String - Number 타입 */
    category(string),
    ranking(number),
    category(string(regex('^user'), minLength(5))), /* 유효성 검사들 */
    x(number(min(2), max(6), multipleOf(2)));
}

/* 상태 1개 */
.sample:toggled {}

/* 상태 2개 */
.sample:toggled:loading {}

/* size에 medium이 포함되어 있음 */
.sample:size(medium) {}

/* size에 huge가 없음 */
.sample:size(huge) {}

/* green이 기본값으로 사용 */
.sample:color {}

/* 유효성 검사를 거친 Stirng과 Number */
.sample:category(kitchen) {}
.sample:x(4) {}

1, 2번은 boolean과 일반 Variant이며, 3번은 함수형 프로퍼티와도 같다.

런타임에서 사용법도 비슷하다.

import { st, classes } from './sheet.st.css'; 

// active states
st(classes.part, {
  isOn: true,      // boolean
  size: 'small'    // string or enum
  place: 1         // number state
});

// un-active states - only 'part' class
st(classes.part, {
  isFirst: false,  // boolean
  size: undefined  // string or enum
  place: undefined // number
});

정리

Stitches의 놀라운 작업 덕분에 API 일관성을 갖추기 빼고는 할 일이 없었다.

AtomicCSS의 토큰을 Variants에서 쓰기 또한 그저 defineRules의 리턴값에서 함수를 할당받기 외에는 할 일이 없다.

const { cssVariants, rules } = defineRules({ /* ... */ });

const sample1 = cssVariants({
  parent: {
    ":hover $child": {
      w: "1rem"
    }
  },
  child: {
    "$parent &": {
      w: 2
    }
  }
});

// 함수의 첫번째는 입력 값, 두번째는 Context이다.
const sample2 = ruels({
  c: "red",
  bg: "primary",
  variants: {
    color: {
      indigo: {
        bg: (_, {indigo}) => indigo[600]
      },
      custom: ({ color }) => ({
        bg: color.custom
      })
    }
  }
});

HTML & CSS & JS

Styled Component

지금까지 HTML + JS 그리고 CSS + JS를 다루었다.

그렇다면 HTML과 CSS 조합을 인간친화적으로 만들면 어떨까?

그게 바로 그 유명한 Styled Components 되시겠다.

function Sample() {
  return <div>
    <Button>Normal Button</Button>
    <Button primary>Primary Button</Button>
  </div>;
}

WindiCSS의 Attributify Mode도 살펴보라.

이 얼마나 훌륭한 생각인가?

<button 
  bg="blue-400 hover:blue-500 dark:blue-500 dark:hover:blue-600"
  text="sm white"
  font="mono light"
  p="y-2 x-4"
  border="2 rounded blue-200"
>
  Button
</button>

컴포넌트에 대한 attributify mode까지 작동되면 처음부터 끝까지

구문의 동형성을 달성할 수 있다.

// 리터럴 구문
const base = css({ color: "#444" });
const smaple1 = rules({ color }) => ({ background: color }));
const sample2 = css(["pure-class-name", base, sample1({ color: "red" }), { width: 10 }]);

// Atomic 구문
const { css: atomic } = defineRules({
  // ...
});
const sample3 = atomic(["uppercase", { px: 4, _hover: { bg: "red" } }]);

// variants 구문
const variants = rules({
  variants: {
    // ...
  }
});
const sample4 = variants(["outlined", { accent: "pink" }]);

// styled 구문
const Sample5 = styled("button", { /* Something like rules() */ });
const element1 = <Sample5 outlined accent="pink">Button</Sample5>;

// Atomic Styled 구문
const { styled: atomicStyled } = defineRules({
  // ...
});
const Sample6 = atomicStyled("div", { /* Something like atomic rules() */ });
const element2 = <Sample6 px={4} bg={({ indigo }) => indigo[600]} />;

이 글에서 제안한 함수는 10개도 되지 않지만 꽤나 강력합니다.

핵심: css(), rules(), defineRules(), styled()
테마: theme() tokenConstract(), themeConstract()
기타: cssVariants(), combineRules()

컴파일과 빌드 인프라

빌드 인프라의 핵심은 편의성과 성능이라 할 수 있다.

Marko like JSX구문이 아니라 스타일을 다루는데도 컴파일러 인프라는 편의성을 제공해준다.

Vanilla Extract의 경우 스타일과 컴포넌트 코드를 함께 둘 수(co-location) 없고,

Stylelint도 지원하지 않는데 모두 빌드 인프라의 문제다.

이걸 어느정도 해결한게 Linaria와 macaron이다.

개인적으로 최적화에 대한 아이디어는 CSS Blocks를 좋아한다.

로직과 분리

Headless UI Library란?

뷰와 로직, 그리고 뷰와 스타일은 분리가 가능한가?

완전히는 아니지만 '격리'될 수는 있다.

원래 HTML - CSS - JS가 그러했고,

Literal - Theme - Atomic - Variants - Styled Component 순으로 쌓아 올린 가상의 CSS In JS 라이브러리 또한 CSS 관리를 각단계로 훌륭히 나눌 수 있음을 보여줬다.

뷰 동작과 스타일의 분리의 예시로,

어도비의 React Spectrum Libraries는 상태 - 동작 - 컴포넌트의 분리를 수행한다.

아키텍처

State: 뷰에 대한 가정없이 상태만 관리
Behavior: 플랫폼에 따른 이벤트, 접근성, 국제화를 고려한 동작
Component: State와 Behavior를 사용하고, 디자인 시스템과 함께 제공

요즘 Headless UI, Radix Primitives, Ark-UI, Zag처럼 좋은 State, Behavior Components들을 제공하는 라이브러리가 늘어나고 있다.

스타일에서도 Kuma UI처럼 스타일에 관한 Headless UI도 나오고 있다.

또한 shadcn/ui처럼 좋은 가이드가 있어 적용하기에 좋지 않을까.

각종 디자인 시스템에 대한 비교는 OpenUI가 잘 되어 있다.

정리

선언적이고 작성 / 관리하기 쉬운 구문과 라이브러리 API를 가상이지만 만들어보았다.

개인적으로 그 결과가 깔끔하고 마음에 드는데 배경에는 몇가지 원칙이 있다.

로직을 나열하기보다는 선언적일 것
각 레이어의 API는 동형적으로 만들어져야 함
표현과 내용은 서로를 전제하므로 고려해야함
위계가(관점이) 다르면 배중률이 적용

개선 가능한 부분들을 다시 한번 정리해보았습니다.

HTML

JSX의 제어와 참조는 컴포넌트와 디렉티브를 만들어 개선할 수 있다
class와 ID는 emmet 구문을 사용해 직관적으로 표현할 수 있다
프로퍼티에서 자바스크립트 구문을 그대로 사용할 수 있다
Default argmument과 Children callback관련 문법을 제공할 수 있다
태그 이름을 직접 보간할 수도 있다

CSS

타입 안전해야 하며, 단위를 위해서는 언어적 지원이 필요
리터럴 구문은 중첩, 속성 병합, 참조, 합성, 함수를 다룰수 있어야 함
Atomic CSS는 시각적인 위계를 다루고 디자인 토큰을 매핑하기 쉬워야 함
Atomic CSS를 잘 쓰기 위해서는 Theme에 대한 지원이 필요
Theme는 규약을 정할 수 있으며, CSS 컴파일 결과와 JS에서 사용을 고려해야 함
중앙화된 프레임워크는 충분한 유틸리티와 관용적인 프리셋을 가져야 함
Variants는 의미론적 위계를 다루며, Atomic CSS의 활용도 충분히 가능
리터럴부터 Styled 컴포넌트까지 거의 동일한 문법으로 사용가능

끝.

동시성, 병렬, 비동기, 논블럭킹과 컨셉들

BlaCk_Void — Fri, 3 Jun 2022 11:44:12 +0900

위 용어들은 모두 빠르게 실행하거나, 빠르게 느끼도록 만들때 주로 사용하는 용어들이다.

많은 사람들이 이미 적어놨으나 저도 한번 동참해보겠습니다.

차이가 있다면 되도록 이미지를 많이 사용하여 직관적으로 이해하기 쉽게 만들어보는게 목표.

좋은 이미지를 찾는데는 항상 많은 시간이 소요된다.

또한 풍부한 레퍼런스와 넓은 범위를 다루려 노력했다.

1. 용어

동시성 / 병렬

동시성: 동시에 작업이 실행된 것처럼 보이면 되며(논리적)
병렬: 실제로 동시에 작업이 실행되어야 한다(물리적)

따라서 싱글코어에서 시분할로 나누어 일을 처리하더라도 동시성을 지원한다고 말 할 수 있다.

반대로 싱글코어에서 SIMD를 이용하면 병렬로 작업을 실행할 수 있다. [SIMD (Single Instruction Multiple Data)에 대한 집중탐구!]

비동기 / 논블로킹

어떤 함수가 작업완료와 제어권을 결정하느냐의 차이라 생각하면 쉽다.

동기와 비동기는 작업완료를 누가 확인하는가
블로킹과 논블로킹은 제어권한이 있는가

위 그림으로 애매한가요?

그럼 이렇게 생각해봅시다.

먼저 동기와 비동기 회로.

동기회로는 타이밍을 위해 클럭을 이용하고, 비동기는 이벤트나 다른 입력에 의해 트리거되는 방식이다.

Synchronous and Asynchronous Circuits

소프트웨어 API에서 비동기는 콜백등에 의해 트리거되는 형태라 생각하자. [Synchronous and asynchronous requests]

언뜻 비동기가 동기보다 좋아보이지만 각자 유리한 방향이 다르다.

동기: 파이프라인을 활용시 효율적
비동기: 독립적이거나 지연이 클 때 효율적
(약간의 오버헤드가 있으며 순서를 보장하지 않음)

블럭킹/논블럭킹은 작업이 완료될 때까지 기다려야 하는가의 여부로 생각하면 적절하다. [Overview of Blocking vs Non-Blocking]

선점형 / 비선점형

선점형과 비선점형

선점형: 스케쥴러가 중간에 다른 작업으로 전환할 수 있음
비선점형: 작업이 스위칭 해줘야 다른 작업으로 전환할 수 있음

선점형은 Non-Blocking, 비선점형은 Bloking의 일종이라 볼 수 있다.

2. 운영체제와 프로세서

운영체제

프로세스는 실행중인 프로그램의 인스턴스로 고유한 주소공간을 가지며 서로 격리되어있다.

다른 프로세스에는 직접 엑세스할 수 없으므로 데이터를 주고 받으려면 IPC등을 이용해야 한다.

위에서 보이는 코드, 데이터, 스택, 힙은 메모리 레이아웃이라 배우는 그것이라 생각해도 좋다.

OS나 언어등의 환경마다 조금씩 다를 수 있지만.

Memory Layout of C Programs

스레드는 프로세스 내에서 실행되는 여러 흐름의 단위다.

데이터와 코드를 공유하고 별도의 카운터, 레지스터, 스택을 가진다.

프로세스와 달리 Heap, Data 영역을 공유하여 IPC가 필요없고

컨텍스트 스위치 비용도 적다.

UNIX Threads

Unix Processes

윈도우쪽 프로세스, 스레드 이야기는 Processes, Threads, and Jobs in the Windows Operating System에 잘 정리되어 있다.

프로세서

물리: CPU에 들어간 실제 코어
논리: 작업부하를 공유하며 동시에 스케쥴링

일명 하이퍼 스레딩이라는 기술을 이용해 컨텍스트 스위칭과 유휴시간을 줄일수 있다

정리해보자면 다음과 같다

Multi Core vs. Hyper-threading

보통 최대한 성능을 뽑기위해 쓰레드 풀에서 논리 코어 갯수대로 생성하는 것으로 알려져있다.

SMP와 NUMA

여러 프로세서가 공유된 메모리를 사용하는 SMP(Symmetric Multi Processing, 대칭형 다중 처리)와 로컬메모리와 외부 메모리를 분리해 사용하는 NUMA(Non-uniform Memory Access, 불균일 기억장치 접근)에 대해서도 알아보길 바란다.

커널과 사용자 공간

운영체제는 일반적으로 메모리와 하드웨어를 보호하기 위해 사용자 공간(User space)과 커널 공간(Kernel space)을 나눈다.

유저 공간과 커널 공간

모든 사용자 프로세스는 사용자 공간에서 실행되며, 시스템 콜을 통해 커널에 요청을 할 수 있다.

커널에서는 모든 시스템 기능(VFS, IPC, 스케쥴링, 드라이버 등)을 커널 공간에서 실행하는 모놀리식, 최소한만 실행하는 마이크로, 중간 방식인 하이브리드로 나뉠수 있다.

모놀리식은 한번의 시스템콜로 여러 시스템 컴포넌트를 호출 할 수 있으므로 성능이 낫고, 마이크로는 서비스가 오류나도 커널 전체가 패닉이 생기지 않으므로 안정성이 좋은 편이다.

시스템콜과 커널의 유형

리눅스(모놀리식), 푸크시아(마이크로), 윈도우 NT(하이브리드)가 대표적인 예.

커널 공간은 분리가 되어 있으므로 시스템콜은 컨텍스트 스위칭 비용이 크다. (복사가 필요함)

Context switch-Everything you need to Know

또한 커널은 커널 모듈을 사용하더라도 재빌드가 필요하거나, 문제가 있을 시 패닉이 생기는 한계가 있었다.

최근에는 eBPF를 통해 안전하면서도 커널공간에서 프로그램을 실행하는 방법이 생겼다!!

eBPF를 사용한 예로 XDP(eXpress Data Path)가 있으며, 반대로 유저스페이스를 최대한 활용하려는 시도인 DPDK(Data Plane Development Kit)도 주목할만 하다. [XDP(eXpress Data Path), K8s 에서의 eBPF/XDP 기반 고성능 & 고가용성 NAT 시스템, What is DPDK?, DPDK+eBPF]

3. 코루틴과 파이버

파이버

쓰레드가 경량 프로세스라면, 파이버는 경량 쓰레드다.

파이버는 쓰레드와 달리 자발적으로 실행을 중지해야 양보할 수 있으며 커널이 아닌 사용자 공간에서 이루어진다. (비선점형, 협력적 멀티 태스킹)

예외적인 케이스로 DragonFly BSD의 LWKT(Light Weight Kernel Threads)가 커널 공간의 선점형 시스템이긴하나.. 일반적인 경우는 아니다.

따라서 같은 쓰레드의 파이버끼리의 전환은 컨텍스트 스위칭 비용은 매우 적다.

코루틴

코루틴은 일시중단(suspend)했다가 재개(resume)할 수 있는 제어요소다.

파이버와 코루틴은 쓰레드/함수 관계와 비슷하며, 유저수준에서 가장 큰 차이는 코루틴은 서브 루틴처럼 Caller-Callee 사이에서 전환되지만, 파이버는 스케쥴러에 의해 순서가 정해질 수 있다.

코루틴에서 주목할만한 것은 Stackful, Stackless 코루틴이다.

프로토 쓰레드(Protothread)라 불리는 것도 스택리스 코루틴의 일종이라 할 수 있다.

Stackful 코루틴

Stackless 코루틴은 피호출자(Callee) 중지(suspend)가 되면 호출자(Caller)로 돌아오지만,

Stackful 코루틴은 sub function에서도 호출자로 돌아올 수 있다.

대신 Stack 정보를 저장해야 하므로 메모리를 더 소모한다.

4. 제네레이터, Async/Await, 컨티뉴에이션

제네레이터

코루틴 링크에 설명되어 있듯 제네레이터는 코루틴의 한 종류이다.

제네레이터

Generator 코루틴은 suspend(즉 yield)할 때 제어권을 따로 지정하지 않으며, 자동으로 Caller에게 넘어간다. 이러한 코루틴을 Semi-coroutine 혹은 Asymmetric 코루틴이라고 한다.

반대의 개념, Symmetric 코루틴도 있다. Caller/Callee의 관계가 성립하지 않으며 A 코루틴이 B 코루틴으로 제어권을 넘겨서 B가 resume되면(A는 제어권을 넘기면서 suspend), B는 그 제어권을 꼭 A에게 넘길 필요가 없다. 또다른 코루틴 C에게 제어권을 전달하면서 suspend할 수 있다. 따라서 Symmetric 코루틴은 suspend할 때 제어권을 넘겨받을 코루틴을 지정하여야 한다.

Async / Await

일반적인 Async/Await, 결과를 반환하는 Async/Awiait

Async/Await는 언어나 런타임에 따라 동작이 상이할 수 있으나 자바스크립트의 경우 await가 생기면 비동기 함수의 실행을 일시적으로 중단하고, 메인 프로세스를 진행한다.

이러한 동작 때문에 프론트엔드의 단골 문제 중 하나.

다른 쓰레드(일반적으로 I/O)가 프로미스의 동작을 실행하고 완료되면, 중단(await)지점으로 재개되어 실행한다.

프로미스는 아래에서 추가적으로 다룰 예정이다.

만약 반환 값이 있다면 어떻게 처리되어야 하는가?

Return을 하는 Async/Await

정답은 async 함수를 프로미스로 취급한다.

타입스크립트를 해본 사람이라면 다들 알고 있겠죠.

컨티뉴에이션

컨티뉴에이션(Continuation)은 Coroutine처럼 제어흐름(Control flow)의 일종이다.

call-with-current-continuation(call/cc)를 이용하면 다음 이미지와 같이 마치 GOTO문처럼 사용할 수도 있다.

많은 설명글이 있지만 직관적이지 않다.

스텝 디버거를 개발하면서 나온 What’s in a Continuation와 F#을 이용한 Understanding continuations라는 글이 그나마 쉽게 설명되어 있다.

컨티뉴에이션의 컨셉 자체는 아주 쉽다.

~~대신 모든 함수형 프로그래밍이 으레 그렇듯 초반에는 쉽다가 급격히 러닝커브가 올라가는?~~

일반 / 컨티뉴에이션 방식

에러처리나 반환, 분기처리처리가 필요하면 함수를 실행함으로서 제어의 역전을 노리는 것이다.

그럼 처음 나왔던 call/cc 함수를 이용하는 예제를 살펴보자.

call/cc

다음 코드를 실행시키면 첫번째 console.log가 실행된 후, cont(5)에서 x의 값이 5로 할당되며 두번째 console.log는 실행되지 않는다.

분기문의 예가 될 수 있겠죠?

마찬가지로 다음의 예제에서도 두번째 배열 값에서 cont(true)가 실행되어 멈추고 x에 true가 할당된다.

그렇다면 GOTO는 어떤 방식으로 나타나는가를 살펴보자.

주요 아이디어는 내부가 아닌 외부에서 컨티뉴에이션 사용이다.

value에 callCC의 컨티뉴에이션을 할당 [GOTO의 Label과 같은 역할]
value는 함수니 "got a continuation!"이 출력
value(x * 2) 실행 [GOTO 실행!!]
value로 다시 돌아감, value에는 5 * 2로 10이 할당되어 있음
value는 일반 값이므로 "computation finished 10"을 출력

마치 마법 같습니다.

GOTO문의 일종으로 취급될 수 있기 때문에 각종 제어흐름을 구현하는게 가능하다.

컨티뉴에이션을 활용하는 방법 중 하나인 Continuation Passing Style에 대해 알아보자.

Continuation Passing Style은 코틀린의 코루틴 구현 방식.

이번에는 Continuation Passing Style (CPS) 를 알아보자라는 글이 잘 설명되어 있다.

CPS는 꼬리재귀와 상당히 유사하다.

꼬리재귀에 관련 내용은 다음 글을 보시면 되겠습니다.

https://black7375.tistory.com/62

내 맘대로 프로그램 설계 7. - 함수형 프로그래밍.

내 맘대로 하는 프로그램 설계 시리즈. Chapter1 - 간단한 데이터 처리(4섹션) 2017/12/27 - [프로그래밍/설계] - 내 맘대로 프로그램 설계 1. - 이유와 준비. 2018/01/11 - [프로그래밍/설계] - 내 맘대로 프로

black7375.tistory.com

다만, 1, 2, 6, 24처럼 누산값(accumulator)을 전달하는 대신 컨티뉴에이션을 전달한다.

pow(제곱)함수를 컨티뉴에이션으로 반환하면 다음과 같다.

그래서 만약 다음 메인함수를 CPS 스타일로 변환한다면?

pow를 분리하여 순서를 맞추고, CPS로 변환하면 끝.

일반 유저가 사용하기에 콜백 헬이 생기기 때문에 코틀린의 예처럼 중간과정으로서 많이들 사용한다.

다음 자료에 앞선 그림자료와 예제코드까지 잘 설명되어있으니 참고바란다.

5. Promise와 Future, 스트림, 메세징

Promise / Future

Promise(약속)과 Future(미래, 선물)는 비동기 프로그래밍에서 항상 등장한다.

둘은 생산자-소비자 관계라고 생각하면 쉽다.

이른바, 미래에 어떠한 데이터를 돌려주겠다는 약속.

퓨처: 읽기 전용으로 아직 계산되지 않은 값이다
프로미스: 퓨처가 참조하는 한번 결과를 할당 가능한 가능한 값이며, CompletableFuture나 Completer로도 불리기도 한다.

사용하게 된다면 다음과 같이 표현할 수 있다.

참고로 MPSC(Multi-producer, single-consumer)와 같은 용어를 본 적이 있을 것이다.

M은 멀티, S는 Single
P는 생산자, C는 소비자

관계이다.

Stream / Buffer

Async Streams in C# 8

이번에는 커다랗거나 연속된 데이터를 다룬다고 생각해보자.

통으로 처리하거나 전달하기보다 덩어리(Chunk) 단위로 다루기를 원할 것이다.

스트림(Stream)은 연속적인 데이터 흐름이다.

Introduction to NodeJS Streams

시간 효율적: 모든 데이터를 사용가능할 때까지 기다릴 필요가 없음
공간 효율적: 모든 데이터를 사용하지 않기 때문에 필요한 메모리가 적음

그럼 임시적으로 데이터를 담아놓는 버퍼(Buffer)가 왜 필요할까?

전달이 빠름: 데이터를 바로 처리할 수 없기 때문에 저장
(비디오 다운로드가 보는 속도보다 빠를때 미리 저장해둠)
전달이 느림: 처리할 크기가 될 때까지 저장
(연결이 느릴때 0.1초 단위로 비디오를 보여주기보다 1~2초단위로 보여주기 위해 저장)

버퍼는 일종의 큐이며, 보통 지정된 크기/길이를 가진다.

혹시 동기/비동기와 헷갈린다면 다음 그림을 참고해보자.

Stream은 전체 데이터를 나눠서 처리할 수 있음

한마디로 단일값과 벡터의 차이다.

Push / Pull

스트림처럼 연속된 데이터를 주고 받을때 필요한 개념이다.

Pull과 Push는 생산자와 소비자의 통신방식이다.

pull / push

Pull: 소비자가 요청하면 데이터를 줌
Push: 생산자가 데이터를 주면 받아서 씀

Pull은 동기, Push는 비동기에 가깝다고 보면 된다.

역시 서로 유리한 지점이 다르다.

Pull/ Push

Pull: 요청이 들어오면 바로 데이터를 제공해야 하므로 빠른 생산자가 있을 때 유리
Push: 데이터를 주면 바로 소비할 수 있는 빠른 소비자가 있을 때 유리

Push의 대표적인 예는 Promise와 Observable가 있다. [반응형 프로그래밍과 RxJS, The ultimate guide to Observables and/vs Promises (+RxJS7)]

Observable은 여러 값의 지연 푸시 컬렉션

앞서 스트림에 나온 Asynchronous Sequence Data Pull은 Async Iterator의 동작방식이나 다름없다.

Sub / Pub

그럼 생산자나 소비자가 여러개일 때 직접이 아닌 간접적으로 연결하고 싶다면 어떻게 될까?

ZeroMQ의 문서가 아주 잘 되어 있다.

Pub / Sub

직접 연결인 Observer 패턴과 비교해보자.

Observer vs Publisher-Subscriber Pattern, Observer vs. Pub-Sub Pattern: What is the Difference

ZeroMQ의 특이한점은 메세지 브로커 대신 소켓의 Wrapper로 해결하려 한다는 점.

큐 / 버스 / 브로커

중간의 역할에 있어서 여러 구분에 혼동이 올 수도 있다.

이렇게 정리해보자. [Event Queues, Event Bus Implementation(s), Event Driven Architecture – The Basics, EventBroker: a notification component for synchronous and asynchronous, loosly coupled event handling, The Engineers Guide to Event-Driven Architectures: Benefits and Challenges]

큐: 선입선출(FIFO)이 보장됨
버스: 여러 생산자가 있을 경우, 모든 내용은 공유됨, FIFO를 보장하지 않을 수도 있음
브로커: 일종의 허브로서 라우터 역할을 함

메세지 / 이벤트

이쪽은 헷갈리는 개념이 참 많다.

Azure에 따르면

메세지: 다른 곳에서 사용하거나 저장하기 위해 서비스에서 생성한 원시 데이터
이벤트: 조건 또는 상태 변경에 대한 간단한 알림

이라고 한다.

일반적으로 메세지 중심의 경우 메세지가 중간에 사라지지 않고 처리하기를 기대하기 때문에 Pull에 가깝고,

이벤트 중심은 알림을 보낸 후 처리를 신경쓰지 않으므로 Push에 가깝다.

반응형 프로그래밍쪽에서는 세분화해 4~5가지 유형으로 나누기도 한다. [Types of Messages in Message-Driven Systems, Message Driven vs Event Driven]

이벤트: 상태가 변경되었을때 내보내는 메세지
문서: 데이터를 처리하기 위해 제공하는 메세지 [문서는 이벤트와 다르게 타이밍의 중요성이 떨어지며 안전하게 전달함에 집중]
명령: 상태를 변경하기 위해 보내는 메세지
쿼리: 정보를 얻기 위해 보내는 메세지
회신: 명령 혹은 쿼리의 응답 메세지 [엄격하게 해석하면 쿼리에 대한 응답만 치는 경우도]

이외 궁금한 점이 있다면 Messaging Patterns 사이트를 참고해보자.

메세징 프로덕션 제품들

프로덕션 제품들은 여러가지 개념들을 섞거나 보완하기 마련이다.

종류가 많지만 유명한건 Kafka, RabbitMQ, ActiveMQ, ZeroMQ일 것이다. [Kafka vs ActiveMQ vs RabbitMQ vs ZeroMQ]

Kafka

Kafka에는 토픽으로 나뉘어 저장된다. [Kafka, Part 1: Apache Kafka for beginners - What is Apache Kafka? ]

로그의 압축이 가능하다는 것도 특징

RabbitMQ

RabbitMQ의 브로커는 교환과 큐로 이루어져 있다. [Part 1: RabbitMQ for beginners - What is RabbitMQ?]

ZeroMQ

아까 나왔듯, ZeroMQ는 Socket의 Wrapper로 작동한다. [ZeroMQ vs Kafka]

6. I/O 멀티플렉싱

멀티플렉싱

multiplexing

멀티플렉싱(Multiplexing, 다중화)는 여러 신호를 하나로 묶어서 전달하는 기법이다.

시분할

한정된 채널을 효율적으로 사용할 수 있게된다.

일반적인 통신에서 주파수 분할이나 시분할 기법등이 쓰이며, 컴퓨터 통신에서는 HTTP2.0이 대표적인 예.

What is the HTTP/2 Protocol? Overview and Examples

멀티 플렉싱 기법은 채널을 효율적으로 사용하기 위해 여러신호를 묶는 기법이기 때문에 데이터 용량이 많거나 연속적일때 적합하지 않을 수도 있다.

클라이언트와 서버간의 송수신 데이터 용량이 작은 경우 적합
송수신이 연속적이지 않은 경우에 적합
멀티 프로세스 기반에 비해 많은 수의 클라이언트 처리에 적합

여러 커넥션 생성시 비용은 멀티프로세스 > 멀티쓰레드 > 멀티플렉싱 순이다.

멀티 프로세스, 멀티 쓰레드, 멀티플렉싱

소켓

소켓은 프로그램간 양방향 통신의 엔드포인트다.

소켓에 데이터를 적으면, 데이터 전송은 소켓이 수행해준다. (낮은 레이어의 통신에 대한 일종의 추상화)

유닉스 도메인 소켓 시작하기

인터넷 접속 시 사용되는 네트워크 소켓과 프로세스간 IPC를 위한 유닉스 도메인 소켓으로 나눌 수 있다.

JEP-380: Unix domain socket channels

당연하겠지만 유닉스 도메인 소켓이 더 가벼운 편.

서버와 클라이언트 소켓은 다음과 같은 생명주기를 가진다.

유닉스는 파일과 소켓 조작을 동일하게 간주하며, fd(File Descriptor)로 표현한다.

(윈도우는 소켓 API가 따로 존재)

UNIX File Descriptors An Introduction

파일 디스크립터는 0(임력), 1(출력), 2(에러)로 정해져 있으므로 3번부터 실제 파일이 시작된다.

I/O 모델들

IO Multiplexing (IO 멀티플렉싱) 기본 개념부터 심화까지와 I/O Model이라는 글이 잘 설명해주고 있다

동기-블럭킹 / 동기-논블럭킹 / 비동기-블럭킹 / 비동기-논블럭킹

커널이 메세지를 반환해야지만 처리할 수 있는 동기 블럭킹 I/O
system call을 통해 반복적으로 확인(폴링)해야해 컨텍스트 스위칭 오버헤드가 있는 동기 논블럭킹 I/O
한번에 많은 fd를 처리할 수 있지만 select와 read로 두번의 시스템 콜이 발생하고 비동기 블럭킹 I/O
결과를 마치 이벤트처럼 전달받을 수 있는 비동기 논블럭킹 I/O
그러나 리눅스에서는 동기 I/O가 충분히 빠르고 AIO시 지연 때문에 Epoll을 주로 사용

select가 대표적인 멀티플렉싱 I/O 모델로 3번째인 비동기 블럭킹 I/O다.

체크할 파일 디스크립터 목록을 배열로 만들어놓고, select에서 반환되면 순회하여 데이터를 처리한다.

멀티플렉싱 기반의 다중 접속 서버로 가기까지

Epoll(리눅스), Kqueue(BSD), IOCP(Windows)가 더 발전된 방법이다.

Epoll은 유저 스페이스 단이 아닌 커널 단에서 멀티플렉싱을 지원하고 변경된 목록을 반환한다.

따라서 상태가 변경되었는지 매번 디스크립터 목록을 순회할 필요가 없으며, 커널에서 상태 정보를 유지하므로 관찰할 파일의 정보를 매번 전달할 필요가 없다.

The method to epoll’s madness

Kqueue는 FreeBSD에서 사용되며 kevent를 담은 kqueue를 사용한다. [Kqueue: A generic and scalable event notification facility, kqueue和FSEvents, HN, Scalable Event Multiplexing: epoll vs. kqueue]

Epoll과 비교하자면 소켓과 파이프I/O만 지원하는 Epoll과 달리 signal, timer등 다양한 타입들을 지원한다.

또한 kevent()는 단일 시스템 콜로 여러개의 업데이트를 한번에 수행할 수 있다.(Epoll은 매번 epoll_ctl()을 사용해야 함)

윈도우의 IOCP(I/O Completion Ports)는 멀티쓰레드로 동작하며 4번 비동기-논블럭킹 모델이다. [Iocp 기본 구조 이해, Windows IOCP vs Linux EPOLL Performance Comparison, Windows Registered I/O (RIO) vs IOCP]

IOCP

윈도우 RIO(Registered I/O)는 한번 더 나아가, 고정 크기의 버퍼를 등록해 컨텍스트 스위칭을 낮출 수 있다.

물론 코딩은 어려워짐을 감안해야 한다.

등록과 동작

7. 링버퍼, 최신 I/O 모델, LMAX Distruptor

링버퍼

링버퍼는 성능 저하없이 배열을 dequeue처럼 사용할 수 있다.

링버퍼

LMAX Disruptor

LMAX Disruptor는 데이터를 전달 시 큐를 이용할때 지연시간을 줄이기 위해서 만들어졌다.

왼쪽에서 오른쪽 처럼

그러기 위해 링버퍼를 택했다.

전반적인 아이디어는 IO Uring과 일치한다.

각 필드는 캐시라인을 고려해 64byte, 링버퍼의 크기는 2의 n 제곱, 배치 프로세싱등의 세부적인 최적화 사항이 있지만 더 자세한 내용들은 다음을 참고해보기 바란다.

8. 동기화 프리미티브

필요성

쓰레드가 공유 변수에 접근하게 되면 경쟁조건(Race Condition)이 생기게 된다. [바로 위의 링버퍼를 사용하면 효율적으로 접근을 할 수가 있었다.]

예를 들어 다음처럼 동시에 값을 수정할 때가 있겠다.

Race Condition and Deadlock

이를 막는 간단한 방법은 동시에 접근하지 못하게 막는것(잠금, Lock)이다.

그래서 다음과 같이 임계구역(Critical section)을 설정해 쓰레드간 동기화를 할 수있다.

Critical Section | Critical Section Problem, Mutex lock과 condition을 사용한 생산자 소비자 문제의 구현

그러나 락을 잘못 사용하게되면 서로가 서로를 기다리는 교착상태(Deadlock)이 생길 수도 있으니 조심해야한다. [Deadlock, Livelock and Starvation]

반대로 서로 넘겨주느라 일을 못하는 Livelock 상태도 있다.

데드락

스레드 안전

여러 스레드가 동시 실행될 때 코드가 올바르게 작동하면 스레드 안전(Thread safe)하다고 할 수 있다.

보통 다음과 같은 경우를 알아보면 된다.

전역변수, 힙, 파일등 전역범위에 동시에 접근
핸들/콜백 또는 포인터로 간접적으로 접근
전역범위의 리소스 할당, 재할당, 해제 (사이드 이펙트)

스레드 안전을 달성하기 위해서는 다음과 같은 방법을 사용한다.

우선 공유상태를 피하는 방법.

재진입성: 어떤 함수가 한 스레드에 의해 호출되어 실행 중일 때, 다른 스레드가 그 함수를 호출하더라도 각 결과가 올바르게 반환되어야 함
스레드 지역 저장소: 변수를 각 스레드가 고유한 복사본을 갖도록 복사
불변객체: 만들어지고 변경할 수 없기 때문에 동시에 읽기만 가능, 변경이 필요할 경우 새로운 객체를 만드는 형식

공유상태를 피할 수 없다면 다음과 같은 방법을 사용할 수 있다.

상호배제: 항상 하나의 스레드만 공유 데이터를 읽거나 쓸수 있도록 직렬화
원자 연산: 다른 스레드에 의해 중단될 수 없는 원자성 작업을 이용하여 다른 스레드가 접근하는 방식과 상관없이 유효함을 달성

스레드 안전의 또 다른 고려사항은 컴파일러로, 최적화 때문에 명령의 순서가 바뀔 수 있다.

메모리 장벽(Memory Barriers)은 임계구역의 일종으로 메모리의 작업이 올바른 순서대로 일어나도록 보장한다. [Memory Barriers in .NET, User-space RCU: Memory-barrier menagerie]

메모리 장벽

이 파트에서는 공유상태를 피할 수 없을 경우를 가정하고 동기화 프리미티브를 소개한다.

앞서 나온 Future/Promise와 후에 나올 메세지 전달도 동기화 프리미티브의 한 종류며 공유를 피하는 방식의 구현이다.

예를 들어 메세지 전달의 채널 방식은 값을 복사하거나 옮겨 스레드 지역 저장소의 방식의 일종이다.

스핀락

스핀락(Spin lock)은 가장 간단한 동기화 방법이다.

Lock 상태에 접근하면 Lock이 풀릴 때까지 반복적으로 뺑뺑이돌며(Spin) 확인하다가 풀리면 접근하는 방식이다.

spinlock, The Linux Kernel Locking API and Shared Objects

유저스페이스에서만 동작하기 때문에 컨텍스트 스위칭 비용이 없다.

그렇기에 다른 프로세스와 공유, 오래 대기하는 경우에는 문제가 생긴다.

뮤텍스

뮤텍스(Mutex)는 운영체제를 통해 락을 걸어준다.

다른 락이 풀릴 때까지 계속 확인하는게 아닌 대기하는 상태가 된다.

RTOS: Mutex and Semaphore Basics, Mutex lock for Linux Thread Synchronization

앞서 말했듯 커널을 거치기에 컨텍스트 스위칭 비용은 있다.

세마포어

세마포어(Semaphore)는 배열처럼 여러 값에 접근할 때 사용한다.

뮤텍스와 비교하자면 다음같은 양상.

Mutex vs Semaphore, Java Thread Interview Questions & Answers (All About Java Semaphore and Mutex)

STM

잠금/잠금해제 작업이 상당히 머리 아프기에 변수가 알아서(?) 관리해주면 좋겠다고 생각한적이 있다면, 그 답은 소프트웨어 트랜잭션 메모리(STM, Software Transaction Memory)다.

상호배제가 아니라 원자연산을 활용했다.

트랜잭션? 어디서 많이 들어봤죠?

바로 DB에서 사용하는 방법이다.

Transaction States in DBMS

락 대신 버전을 체크하고 커밋을 하는 형태이다.

Clojure STM - What? Why? How?, A Qualitative Survey of Modern Software Transactional Memory Systems

각 작업을 조금 더 자세히 들여보면 다음과 비슷할 것이다.

Software Transactional Memory Should Not Be Obstruction-Free

GIL

까다로운 동기화 문제 때문에 파이썬의 경우 GIL(Global Interpreter Lock, 전역 인터프리터 잠금)로 해결을 한다.

좋은 방법은 아니라 생각하지만..

각설하고 파이썬이 GIL을 사용하게 된 계기를 알아보자.

파이썬은 마크&스윕 방식이 아닌 레퍼런스 카운팅 방식으로 메모리 관리를 한다.

여러 쓰레드가 동시에 레퍼런스 카운트에 접근한다면 문제가 생긴다.

단순히 생각하면 객체들에 락을 걸면되겠지만 매우 느렸다.

The Python Global Interpreter Lock

따라서 쓰레드에 락을 걸어 코루틴처럼 만들어버린다.

Python Global Interpreter Lock Tutorial Python Global Interpreter Lock Tutorial

쓰레드를 코루틴처럼 만들어 버리다니 I/O에서는 괜찮을 수 있겠지만 CPU 바운드 작업에서는 상당한 문제가 생긴다.

때문에 파이썬은 C라이브러리들과의 바인딩을 통해 해결하며, 다음 챕터에서 다른 스크립트 언어의 접근법을, 그 다음 챕터에서 더 나은 모델을 알아보자.

9. 다른 스크립트 언어의 접근법과 Reactor/Proactor 패턴

Ractor (루비)

루비에는 한때 Guild라고 불렸던 Ractor가 있다.

루비에 있던 GIL에서 벗어나면서도 호환성이 있는 동작을 목표로 했다.

길드는 파이버를 하나 이상 가진 쓰레드로 구성되며, 한 길드에서는 GGL(Giant Guild Lock)로 다른 쓰레드가 실행될 수 없게 보장된다.

Concurrency in Ruby 3 with Guilds

길드간에는 채널을 통해 복사 또는 이동을 하여 데이터를 전송하는 형태.

Ractor에 관심이 있다면 다음 글들도 읽어보기를 바란다.

No GIL (파이썬)

파이썬도 가만히 있지 않고 성능 개선 작업을 진행 중에 있다.

그렇다면 파이썬의 GIL에 대한 해결책은 무엇인가하면 두가지 방식이 경쟁중인 상황!!

바로 No GIL과 Sub-interpreter.

Sub-interpreter의 접근방식은 LWN에 나오듯 후에 나올 자바스크립트의 Worker와 비슷하다.

여기서는 No Gil의 방법을 살펴보자.

다음은 현재 GIL 동작, GIL이 없을때 생기는 문제를 보여준다.

GIL이 없을 경우 동기화 프리미티브 소개에 경쟁조건이라 나왔던 현상이 나타난다.

GIL을 없애려는 시도는 총 3가지로 나타나는데, 첫번째는 앞서 스레딩을 하려 했으나 느렸다는 것(1999년).

두번째 2015년의 시도는 STM처럼 atomic하게 만들자 아이디어로 일명 Gilectomy라 부른다..

하지만 캐시 일관성의 파괴와 버스에서의 통신 오버헤드를 해결하기가 쉽지 않았다고 한다.

그리고 마지막, 현재 No GIL.

스레드 안전한 메모리 할당자 사용
항상 참조횟수가 0 이상을 유지되는 True, False, None등은 recount 매크로가 작동하지 않도록해 경쟁조건 회피
다른 쓰레드가 접근할때만 Atomic하게 업데이트
대부분의 객체 엑세스는 소유 스레드의 로컬일때 일어나므로 효율적임
컬렉션의 lock을 위한 효율적인 알고리즘

Worker (자바스크립트)

자바스크립트는 기본적으로 싱글 쓰레드 언어다.

이유는 동기화에서 안전하지 않기 때문이다. [Understanding Worker Threads in Node.js]

대표적인 예로 부동소수점 연산 관련이 있다.

그럼 싱글 쓰레드를 유지하며 멀티코어를 이용할 방법은 없을까?

여기 쉬운 방법이 있다. 바로 shell scirpt에서 sub shell 만들 듯 띄워버리면 그만이다 ㅋㅋ

Basic Shell Programming, ./ ,bash ,bash -c "", source, subshell vs childprocess

이게 서브 인터프린터의 기본 개념이다.

워커 자체는 여전히 싱글 스레드로 실행되며, shell과는 달리 sleep 없이 동시에 실행가능해야 한다.

그래서 postMessage()를 통해 데이터를 주고 받는 형태를 띄고 있다.

The JavaScript Event Loop: Explained, The Ultimate Guide to Web Workers

물론 오버헤드와 API 제한은 있다. [How JavaScript works: The building blocks of Web Workers + 5 cases when you should use them]

ArrayBuffer를 사용하지 않는 이상 직렬화-복사-역직렬화 과정이 일어나며, window나 documnet 등의 객체에는 접근할 수가 없다.

Is postMessage slow?

Node.js (Reactor 패턴)

지금까지 자바 스크립트 언어자체에는 스레드가 없다고 하였다.

즉, 멀티쓰레드는 없고 앞서 나온 멀티플렉싱 기법과 같이 이벤트를 처리한다.

싱글 쓰레드가 라운드 로빈식으로 동작한다는 말.

Node.js 아키텍처와 I/O 루프

그럼에도 불구하고 최대한 성능을 내기 위해 Node.js의 백그라운드에서 멀티 쓰레드로 일부 동작한다. (Reactor 패턴)

기본적으로 4개인걸로 알려져있으며 동작은 상당히 제약적이다.

libuv -Design overview

단일 스레드지만 운영체제의 Epoll, kqueue 등을 활용: 네트워크(TCP/UDP), TTY, 파이프
쓰레드 풀에서 실행: 파일 I/O, DNS, 사용자 지정 코드

그렇다면 자바스크립트의 비동기는 어떻게 동작하길래 실행순서가 다른가?

답은 큐가 여러개다.

Understanding the Node.js Event Loop

다음 애니메이션을 보면 이해가 더 쉬울 것이다.

JavaScript Visualized: Promises & Async/Await

위의 Worker와 함께 실행되는 모습을 상상해보면 다음과 같다.

각 워커도 한개의 이벤트 루프를 가지고 있는 싱글 스레드로 동작한다 - 트위터

Proactor 패턴

앞선 노드 JS는 Reactor 패턴이다.

Reactor, Proactor 패턴은 이벤트 핸들러의 논블럭킹을 지원한다.

Reactor는 동기적, Proactor는 비동기적이다.

The Proactor and Reactor Design Patterns

다음 Reactor 패턴 그림을 보면 동기적이며, Node.js 이벤트 루프와 비슷하다는 것을 단번에 알아챌 수 있을 것이다.

기본, 멀티 쓰레드 핸들러, 멀티 리엑터 - 멀티 쓰레드 핸들러

노드 JS는 첫번째 싱글 쓰레드 방식이다.

가장 복잡한 형태인 멀티 리엑터 - 멀티 쓰레드의 예는 Vert.x가 있다.

What is Vert.x

Vert.x에서는 한 쓰레드당 2개의 이벤트 루프를 가진다.

Proactor는 비동기답게 통지해주는 방식이다.

Proactor가 비동기라고 무조건 좋은것은 아니라 구현의 복잡도와 오버헤드가 존재하기 때문에 적절한 상황에서 쓰는게 좋다. (앞서 리눅스 AIO도 오버헤드 때문에 느렸다)

부스트 Asio와 Quarkus가 대표적인 Proactor 패턴의 예이다.

신기하게 영문 자료보다 중국쪽 자료가 많은 것 같다.

화웨이쪽 글 빼면 이미지 이해에 지장없으니 번역기 사용해서 보세요.

10. CSP와 액터

동시성을 위해 이런저런 방식이 있지만 최근 가장 인기있는것은 CSP(순차 프로세스 통신, Communication Sequential Process)와 액터(Actor)다.

두 방식 모두 메모리를 공유하는 대신 통신을 한다.

CSP

CSP vs Actor model for concurrency

CSP는 채널을 통해서 통신한다.

Communicating Sequential Processes (CSP) An alternative to the actor model

마치 변수를 계산하는 것처럼.

Communicating Sequential Processes

액터

액터 모델은 채널 대신 메세지 박스(메일 박스)를 이용한다.

[OS] Synchronization (2)

내용만 보면 상당히 비슷하다만 보통 다음과 같은 차이를 가지고 있다고 설명한다.

CSP의 프로세스는 익명, 액터는 ID를 가지고 있음
CSP의 메세지는 동기화된 입출력으로 보낸 순서대로 도착한다
액터의 메세지는 단방향이며 비동기적이다
액터는 메세지에는 액터의 주소가 포함될 수 있다
CSP는 경계 비결정론적이지만, 액터는 무한 비결정론적이다.

11. 그린 쓰레드, 고루틴 그리고 최신 비동기 런타임 기술들

그린 쓰레드

그린 쓰레드는 커널이 아닌 유저 스페이스에서 관리하는 쓰레드다. [Are go-langs goroutine pools just green threads?]

JVM에서 시도해서 실패했지만(1:N 모델로 Stackful 코루틴과 차이가 크지 않았음) 최근 여러 구현체가 나오고 있다.

대표적인게 OpenJDK의 프로젝트 룸(Project Loom)이다.

그린 쓰레드 vs 프로젝트 룸

프로젝트 룸은 어차피 다음에 나오는 런타임 기술들과 겹치는게 많으니 궁금하면 링크들을 읽어보기 바란다.

12. 병렬

SIMD와 파이프라이닝

SIMD(Single Instruction Multiple Data)는 SISD(Single Instruction Single Data)와 달리 1번의 명령어로 여러 개의 값을 동시에 계산할 수 있다.

SIMD (Single Instruction Multiple Data)에 대한 집중탐구!

보다시피 벡터/행렬 관련 연산을 할 때 유리한 편이다.

CPU에 있는 파이프라인과 분기예측을 최대한 이용할 수도 있다.

Instruction-Level Parallelism and Superscalar Processors

이를 최대한 이용한 라이브러리 Polars의 I wrote one of the fastest DataFrame libraries를 읽어보자.

OpenMP & MPI

동기화 프리미티브의 임계구역처럼 멀티 쓰레드/프로세스가 필요할 때는 구역을 만들수가 있다.

OpenMP가 대표적인 예이며 for 루프의 부하를 map-reduce 방식으로 적절히 계산해준다고 생각하면 된다.

Introduction to Parallel Programming with MPI and OpenMP

반대로 메세지 패싱 스타일인 MPI도 존재한다.

Message Passing Interface

공유메모리인 OpenMP, 분산된 스타일인 MPI 둘의 장점을 모두 이용하기 위해 다음과 같이 하이브리드 방식으로 사용하기도 한다. (NUMA의 관점에서도 생각해볼 수 있을 듯)

hyPACK-2013 Mode-1 : Mixed Mode of Programming MPI- OpenMP, Parallel multibody separation simulation using MPI and OpenMP with communication optimization

람다 아키텍처

조금 더 넓은 범위, 아키텍처 레벨에서 병렬에 특화된 구조도 존재한다.

람다(Lambda) 아키텍처

람다, 카파 아키텍처

배치 레이어: 변하지 않는, 실시간 작업이 불필요한 데이터를 미리 작업해 저장
스피드 레이어: 실시간 조회 및 정보를 계산한다
서빙 레이어: 배치와 스피드 레이어의 정보를 조합한다.

카파(Kappa) 아키텍처는 보다 단순하게 스피드 레이어를 통과해 배치 계층에 저장되는 형태다.

제트브레인의 Big Data World, Part 4: Architecture나 마이크로소프트의 빅 데이터 아키텍처에 잘 설명되어있다.

13. GPU

파이프라인과 쉐이더

데이터 처리의 또 다른 핫한 분야는 GPU일 것이다.

일반적인 그래픽 파이프라인은 다음과 같다.

The Graphics Pipeline

Mesh Shaders Release the Intrinsic Power of a GPU

Vulkan 튜토리얼, OpenGL 위키나 Direct3D(11, 12) 문서에 보다 자세히 나와있다.

입력 어셈블러(Input Assembler): 인덱스 버퍼를 통해 중복되는 꼭지점(Vertex)를 제거
꼭지점 쉐이더(Vertex Shader): 모든 정점(Vertex)에 대해 실행되며, 변환(Transformation)이나 모핑(Morphing) 같은 작업을 한다
테셀레이션(Tessellation): 특정 규칙에 따라 표면 세부 정보(subdivide geometry)를 그려 메시 품질을 높힘
기하 도형 쉐이더(Geometry Shader): 모든 프리미티브(삼각형, 선, 점)에서 실행되며, 이를 버리거나 더 많은 프리미티브를 출력할 수 있음.
래스터화(Rasterization): 프리미티브의 벡터 정보를 래스터 이미지(픽셀)로 만듦
조각(Fragment)으로 구성되고 화면 밖 조각들은 모두 버려지며, 꼭지점 쉐이더가 출력한 속성들은 보간됨
다른 조각의 뒤(z-index, depth)에 있는 조각들 또한 버려질 수 있음
프레그먼트 쉐이더(Fragment Shader): 살아남은 모든 조각들에 대해 호출되며, 기록될 프레임 버퍼와 색상 및 깊이 값을 결정함
텍스쳐(Texture) 좌표나 조명의 법선(normals for lighting)등도 포함될 수 있음
컬러 블렌딩(Color Blending): 프레임 버퍼의 동일한 픽셀에 매핑되는 다른 조각을 혼합함
투명도에 따라 덮어쓰거나 추가, 혼합될 수 있음
프레임 버퍼(Frame Buffer): 다음 화면에 그려질 정보를 담는 메모리로 출력의 목적지

입력 어셈블러/레스터화/컬러 블랜딩은 작업방식이 정해져 있으나 쉐이더를 활용할 수 있는 Vertex, Tessellation, Geometry, Fragment 단계는 코드를 GPU에 업로드해 프로그래머가 원하는 작업 방식을 정의할 수 있다.

위와 같이 쉐이더는 각 단계에서 존재하는 모든 대상에서 돌아가므로, 분기예측에 실패하면 손해라는 이야기를 한번쯤 들어봤을 것이다.

최근 자주 이야기가 나오는 컴퓨트 쉐이더는 그래픽 파이프라인에서 벗어나 GPGPU로 활용할 수 있게 만들어준다.

Nvidia의 Mesh 쉐이더가 활용 예. [AMD는 프리미티브 쉐이더[소개, 분석]를 밀었는데 최근 소식이 없다].

OpenGL 4.6 API Reference Guide

Vulkan 1.1 Reference Guide

모바일 GPU의 경우 타일 기반의 렌더링을 가지고 있기도 하다. [GPU architecture types explained, Performance Tuning for Tile-Based Architectures, A look at the PowerVR graphics architecture: Tile-based rendering, PowerVR Series 5 SGX Architecture Guide for Developers]

타일 렌더링, 지연 렌더링

타일 기반 지연 렌더링(TBDR, Tile-Based Deffered Rendering)은 바로 그려주는 즉시모드 렌더링(IMR, Immediate-Mode Rendering)과 달리 타일로 만들어 저장/로드한다. (2 path)

IMR vs TBDR

장점

중복되는 타일은 건너 뛸 수 있음
프레임 전체를 다루는 IMR에 비해 대역폭을 적게 소모(4K 모니터를 쓴다고 생각해보자)
타일의 크기가 적으므로 제약되는 SRAM만으로도 복잡한 렌더링을 수행할 수 있음
지연 렌더링을 사용할 경우, 뒤에 있는 물체는 그리지 않음

단점

지연 렌더링에서 Geometry와 Fragement 사이에서 타일을 저장하기 위해 DRAM을 접근하여 캐시에서 손해

위와같이 여러 장점을 가지고 있기에 최신 PC GPU들도 타일기반 렌더링을 도입하고 있다. (지연 렌더링은 아님)

Ndivia의 방식

이러한 흐름속에 최근에는 타일링과 컴퓨트 쉐이더를 활용해 벡터 그래픽까지 GPU에서 실행하려는 프로젝트들도 생기고 있다.

컴퓨트 쉐이더에 관심이 있을 경우 SIMT(Single Instruction MultiThread)에 대해서도 알아보기 바란다.

Warp-synchronous programming with Cooperative Groups

벡터 데이터에 동일한 작업을 병렬로 실행하는 SIMD와 달리 여러 스레드가 임의 데이터에 공통적인 명령을 실행하므로 분기명령등에서 차이가 있다.

Using CUDA Warp-Level Primitives

모니터

LCD 모니터를 사용한다면 다음과 같이 보여진다.

수직동기화(V-Sync): 프레임 시작
수평동기화(H-Sync): 라인 시작

수직 동기화에 의해 프레임이 시작되 위에서 아래쪽으로 출력되며, 이는 전자빔을 이동하며 쏘는 CRT 모니터의 호환성을 위한 것이다.

CRT 모니터의 표현방식

보통의 모니터는 초당 60프레임을 표시할 수 있다. (60Hz)

16.66ms당 1장씩 보여주어야 한다는 뜻.

60Hz 모니터

여기서 조심해야할 점은 모니터 주사율(Display refresh rate)과 GPU의 프레임 레이트(Frame rate)를 구분하자는 것이다.

Nvidia: High frame rates could lead to significantly better K/D ratios in competitive titles

버퍼링

GPU가 프레임버퍼를 갱신하면, (최신 그래픽 시스템에서는 프레임버퍼가 비디오 메모리에 존재)

디스플레이 컨트롤러가 프레임 버퍼를 읽어 디스플레이에 출력한다.

싱글 버퍼

그러나 문제가 있다.

프레임 버퍼에 쓰는 속도가 읽는 속도보다 느리기 때문에 깜박임(Flickering)이나 티어링(Tearing) 발생하는 것.

보통 60FPS를 달성해야 깜박임이 없다고들 설명한다.

이를 해결하기 위해 더블 버퍼링이 탄생했다.

버퍼를 하나를 추가해 미리 정보를 써놓고 복사를 하거나 교환(Swap)을 하자는 말이다.

복사 vs 교환

복사: 변경된 부분만을 업데이트하는 방식
여전히 쓰기가 읽기보다 느리므로 변경이 많은 경우 적합하지 않다
교환: 프론트와 백버퍼를 완전히 바꾸는 방식
기본적으로 소모하는 리소스가 많으므로 변경이 적은 경우 불리

맞바꾸는 작업을 플리핑(Flipping), 변경가능한 버퍼 컬렉션을 스왑체인(Swap Chain)이라고 부른다.

플리핑(Flipping)

플립하는 방식을 보통 더블 버퍼링이라 표현하며, 역시 만능은 아니다.

Frontbuffer에서 데이터를 출력하는 동안 Backbuffer의 내용으로 바뀐다면?

중간에 출력되면?

찢어지는 현상(Tearing)이 일어나게 된다.

티어링

이를 해결하는 간단한 방법은 수직동기화(v-sync)와 타이밍을 맞추는 것이다.

모니터가 갱신되는 타이밍에 맞추기 때문에 추가적인 오버헤드와 레이턴시가 존재한다.

성능 충분, 성능 부족

성능 충분: 모니터 주사율보다 빠르게 그릴 수 있어야 하지만 기다려야 하므로 레이턴시가 발생하며, 성능을 활용할 수 없음
성능 부족: 동기화 타이밍이 지나버리면 다음 동기화 타이밍까지 지연이 생김 (화면끊김, Stuttering)

위와 같은 문제로 수직동기화를 끄면 대기시간이 줄어들지만, 다시 찢어지는 현상을 감안해야 한다.

때문에 나온 해결책은 트리플 버퍼링이며 크게 두가지 방식이 존재한다.

직렬화 vs 병렬화

직렬화: 백버퍼를 미리 그려놨다면 세번째 버퍼까지 준비해두었다가 수직동기화 타이밍에 맞춰 업데이트
병렬화:
백버퍼1를 미리 그려놓으면 프론트버퍼와 교체하는 동시에 다음 프레임을 백버퍼2에 그림
백버퍼2에 미리 그려놓으면 프론트버퍼와 교체하는 동시에 다음 프레임을 백버퍼1에 그림

직렬화 방식은 수직동기화를 이용해 교체하기 때문에 성능이 좋은 GPU일 경우 GPU의 성능을 최대한 이용하지 못하고 지연이 생긴다.

직렬화 - 지연문제

반대로 병렬화 방식은 GPU의 성능을 최대한 이용해 준비되면 바로바로 교체하는 방식이기 때문에 지연은 적지만 전력소모 문제가 있을 수 있으며 발열에 의해 오히려 성능제한이 생길 수도 있다.

역시 보통 트리플 버퍼라고 하면, 후자인 병렬화 방식을 지칭한다.

정리 버전

수직동기화

방금 전에는 버퍼의 관점으로 살펴보았다면, 이번에는 수직동기화의 관점으로 살펴보자.

성능 충분: 모니터 주사율보다 빠르게 그리면 티어링 문제가 생기기에 문제가 없으며, 전력과 발열문제가 있음
지연시간동안 계산하지 않으면 다음 프레임을 그릴시간 부족해질 수도 있음
성능 부족: 동기화 타이밍이 지나버리면 다음 동기화 타이밍까지 지연이 생김

모니터보다 프레임이 잘 나온다면 수직동기화에 맞추는 것도 나쁘지 않다.

그러나 프레임이 안나오는 상황이라면 다음 동기화 타이밍에 맞추기보다 즉시 교체를 해 지연을 줄일 수 있다.

Nvidia의 적응형 수직동기화(Adaptive V-Sync)/AMD의 동적 수직 컨트롤(Dynamic V-sync Control)라 불리는 기술로 일정 이상의 프레임일때만 수직동기화를 사용한다.

V-Sync를 통한 프레임 제한

프레임이 안나오는 상황에서 개선했으니, 프레임이 잘 나오는 상황에서 문제를 보다 명확하게 정의하고 개선법을 확인해보자.

첫번째는 앞서 idle시간 동안 계산을 못해 다음에 계산이 많이 필요하면 프레임을 만들때 문제가 생길 수 있다는 점.

두번째는 입력 지연이다.

V-Sync 입력지연 vs 티어링

Nvidia의 Fast Sync/AMD의 향상된 동기화(Enhanced Sync)는 V-Sync를 사용할때 삼중버퍼링을 이용해 미리 다음 프레임을 만들어 계산이 많이 필요한 상황에서도 프레임을 유지하게 만들어주며 입력을 반영한 프레임을 미리 준비해 지연을 줄여준다.

향상된 지연시간

그런데!! 여기서 의문, 디스플레이의 주사율(V-Sync 타이밍)를 변경해릴수는 없을까?

Nvidia의 G-Sync/AMD의 Free Sync는 가변 주사율를 지원하게 만들어 지연 문제 해결에 도움을 준다. (때문에 지원하는 모니터를 가림)

가변 주사율

가변 주사율이 있다지만 주사율의 상하한 폭은 여전히 존재한다. (예: 60~120Hz)

만약 24FPS가 지속적으로 나오고 있다고 가정할 때 60Hz가 최저 주사율인 모니터인 경우는 2장, 3장이 반복적으로 표시되며(2:3 pull-down), 끊기거나 부자연스러워 보인다(Judder).

Our TV Motion Tests, 가상현실을 위한 디스플레이 구동 기술

'끊김'이 발생하면 실제로는 제 시간에 맞추어 렌더링이 되고 있음에도 보는 사람 입장에서는 성능에 문제가 있다 느낄 수 밖에 없다.

그래서 나온방식이 LFC(Low Framerate Compensation).

정수배(예: $24 \times 3 = 72$, $24 \times 5 = 120$)로 표현해주면 끊기지 않는 듯 한 움직임으로 느끼게 된다.

FreeSync 2 Explained

잠시 정리를 해보자.

FPS >= 최대 주사율: V-sync + 트리플 버퍼링
최대주사율 > FPS >= 최소 주사율: 가변 주사율
최소 주사율 > FPS: 정수배 가변 주사율

정도가 되겠다.

참고로 보통 게이밍 모니터는 48~144Hz의 가변 주사율를 가진다.

프레임 페이싱과 빔 레이싱

한발자국만 더 가보자.

하드웨어가 아닌 소프트웨어 중점을 둔 방식으로 말이다.

프레임 레이트가 왔다갔다하면 문제가 없을까?

게이밍 모니터처럼 하드웨어 솔루션이 없는 사람이라면 지연과 끊김문제까지 겹쳐서 큰일이 아닐 수가 없다.

균일 vs 랜덤

프레임 페이싱(Frame pacing) 관련 라이브러리는 로직을 디스플레이와 맞추어준다.

가변 주사율(Free Sync, G-Sync)와 달리 소프트웨어적으로 처리보자는 뜻이다.

안드로이드의 Swappy(프레임 페이싱, Frame Pacing Library)가 좋은 예이니 살펴보자.

짧은 프레임(성능 충분): 프레임을 빠르게 보여주는 대신 버퍼링해 정시에 보여줌

긴 프레임(성능 부족): 다음 프레임이 늦음을 감지하고, 대기하여 일관적이게 만들어줌

CPU와 GPU의 워크로드 타이밍도 정하는 기능을 파이프라인이라는 이름으로 제공해주기도 한다.

파이프라인 vs 비 파이프라인

파이프라인: V-Sync 타이밍을 기준으로 CPU와 GPU 워크로드를 분리
비 파이프라인: 모든 워크로드가 단일 스왑 간격을 가짐 (지연시간이 더 낮음)

또한 안드로이드의 Swappy는 스왑 간격을 자동적으로 선택(예: 30Hz/60Hz), 자동 파이프라이닝 선택, 가변 주파수 지원등 여러 기능을 제공해준다.

유니티도 비슷한 고민을 가지고 접근한적 있으니 확인해보기 바란다. (Fixing Time.deltaTime in Unity 2020.2 for smoother gameplay: What did it take?)

AMD의 경우 멀티 GPU일 경우 번갈아 프레임을 생성해 일관된 프레임을 얻기도 했다.

AMD Doubles Down On mGPU Frame Pacing

반대로 엔디비아는 일관된 프레임 자체보다는 지연 문제에 커다란 관심을 가지고 있으며,[How To Reduce Lag - A Guide To Better System Latency]

Understanding and Measuring PC Latency

비파이프라인 방식에 중점을 둔 Reflex라는 SDK를 제공해주고 있다. [Introducing NVIDIA Reflex: Optimize and Measure Latency in Competitive Games]

적용 전 / 후

마치 CPU 중심 파이프라인과 비슷하게 만들어졌다고 한다.

마지막으로 수직동기화 없이도 레이턴시를 줄이고 티어링까지 없는 방법이 존재한다!!(심지어 프레임버퍼도 없어도 됨) [Blur Busters Lagless VSYNC ON Algorithm For Emulators: True Beam Racing, Reducing latency in mobile VR by using single buffered strip rendering, 옛날 게임의 최적화 기법]

beam racing

한 화면을 한번에 업데이트 하는 대신 실시간으로 렌더링
처음으로 다시 올라가는 타이밍이 곧 수직동기화 타이밍이나 다름 없으므로 v-sync를 사용하지 않아도 됨
동기적이므로 티어링 현상이 일어나지 않음

단점은 구현이 상당히 까다로우며 짧은 시간안에 작업을 완료해야 한다.

예륻 들어 OpenGL의 렌더링은 비동기적으로 실행되므로 GPU와 동기화 타이밍 맞추기가 어렵다.

또한 수직동기화가 없기 때문에 매번 가로 프레임이 렌더링 되면 업데이트해 병렬화된 삼중버퍼링처럼 상당한 자원이 소모될 수 있다.

옛날 게임기들은 요구 그래픽이 낮았기에 적시에 처리가 가능했으며, 프레임버퍼도 존재하지 않던 시대에 고육지책으로 만든 트릭이다.

실시간 렌더링의 어려움을 개선하려면 구역을 나누어 처리 해버릴 수 있다.

Beam chasing strip rendering

스캔라인 구역별로 나누어지기 때문에 타일 렌더링과 결합하여 병렬적으로 만들 수 있을 것으로 보인다. [Bitmap Data, Efficient GPU Path Rendering Using Scanline Rasterization]

단, 각 스트립 간 지터(jitter)가 문제가 있으므로 현대적인 방식으로 사용하려면 프레임 페이싱등을 이용해 보완해야 할 듯하다.

그럼에도 불구하고 스캔라인 스트립 아이디어는 소프트웨어만으로 수직동기화와 티어링 문제 해결 가능성을 열어주기 때문에 여전히 매력적인 아이디어다.

스트립 단위로 렌더링을 하게 되면 절전 모드시에는 인터레이스도 활용이 가능할 것이다.

1080i vs 1080p? 인터레이스드와 프로그레시브 방식이란?

바로 전 글의 링크에도 나왔지만 게임보이에서 하드웨어 제약과 단일 스캔라인의 문제로 2개의 스캔라인을 사용한 경우도... [GameBoy emulation in Javascript: GPU Timings, Crab, Nitty Gritty Gameboy Cycle Timing]

컴포지터

The whole web at maximum FPS: How WebRender gets rid of jank

컴포지터란 대체 무엇을 하는 물건일까?

웹에서 transform, opacity와 같은 CSS 속성들은 컴포지터 레이어에서 실행되므로 하드웨어 가속이 된다정도 들어봤을 것이다.

컴포지팅(compositing, 합성)은 개별 소스의 시각적 요소를 단일 이미지로 결합하는 프로세스다.

최신 브라우저의 내부 살펴보기 3 - 렌더러 프로세스의 내부 동작

그래픽 기준, 컴포지터는 개별의 레이어를 하나의 레이어로 만들어 보여준다.

그럼 어떠한 기능을 제공할 수 있는가? 윈도우 매니저에 좋은 예시들이 나와있다. [Compositors in Linux]

투명도/블러
블랜딩
확대/축소
회전/복제
전환 애니메이션

위에서 놓친 유용한 활용 예는 스크롤 기능이 있다.

스크롤

물론 컴포지터의 여러 한계 또한 존재한다.

지연을 추가
레이어가 많아질 때 GPU 대역폭과 메모리 비용
텍스트처럼 컴포지터로 다룰 수 없는 요소들

컴포지터로 중간 작업이 늘었기 때문에 회피(바이패스)하는 경우도 생긴다.

대표적인게 비디오 처리이며, KDE에는 윈도우 합성이 의미 없는 전체화면에서 끄는 확장도 있다. [GPU-Based Content Protection with D3D11 Video, What does keying mean ?, Autocomposer]

비디오 처리

아예 GPU를 벗어나 디스플레이 컨트롤러 레벨에서 합성을 할 수도 있다. [Multiplane Overlay (MPO), 안드로이드, Wayland, 윈도우]

옛날 게임기들이 하드웨어 스프라이트(Hardware sprite)를 가졌둣, 하드웨어 오버레이를 사용해 바이패스 함으로서 CPU와 GPU의 자원을 아끼고 각 프레임버퍼는 독립적인 타이밍을 가질 수 있다.

하드웨어 오버레이

디스플레이 컨트롤러에서 컴포지팅을 수행한다니 뭔가 어색한가?

게이밍 모니터에서 조준점 기능을 오버레이로 제공하는걸 본적이 있다면 이상하지 않다.

게이밍 모니터

보통 모니터들도 마우스 커서를 하드웨어 오버레이를 이용해 사용하고 있을 것이다.

하드웨어 오버레이는 2~4개정도로 제약되고 쉐이더가 없기에 변환등을 사용할 수 없는 제약이 존재한다.

안드로이드는 상태 표시줄, 시스템 표시줄, 앱, 배경화면으로 나누어 하드웨어 오버레이를 사용하고,

윈도우의 경우 프로그램에서 자동적으로 하드웨어 오버레이를 사용하기 위해 휴리스틱을 사용하기도 한다. [For best performance, use DXGI flip model, DXGI DirectFlip]

그래픽 API / 라이브러리

다양한 그래픽 API와 라이브러리가 혼재하며 많은 사람들이 헷갈려한다.

먼저 API.

고수준: GPU 구조와 독립적이며, 아래의 Vulkan등과 비교할 때 비교적 고수준이다.
예: OpenGL(임베디드 장치를 위한 OpenGL ES), DirectX11
저수준: GPU에 명시적 제어를 할 수 있다.
예: Vulkan, DirectX12, Metal

저수준 제어는 만들기가 어려운대신 잘 만든다면, CPU 사용을 줄이고, 명시적 제어로 인해 일관적인 프레임과 확장성을 유지할 수 있다.

쉐이더 언어에서도 변화가 커서 사람이 읽을 수 있었던 GLSL(OpenGL Shading Language) / HLSL(High-Level Shader Language) 대신 바이트코드인 SPIR-V(Standard Portable Intermediate Representation)가 쓰인다.

SPIR-V

플랫폼에 따라 지원하는 그래픽 API가 다양하다는 것을 알 수 있다.

그래서 ANGLE(OpenGL ES 기준)이나 WGPU(Web GPU 기준)와 같은 프로젝트가 만들어졌다. [Point of WebGPU on native]

ANGLE: Running OpenGL ES 2.0 Graphics Code on Windows

윈도우 시스템에서도 API가 있다.

대표적인게 EGL(Wayland), GLX(X-Window), WGL(윈도우)이 있으며, 리눅스에서는 DAMBUF를 통한 제로카피, 부분적 손상지원, 적은 버그등 때문에 GLX에서 EGL로 넘어오는 추세라고 한다. [Switching the Linux graphics stack from GLX to EGL, Adventures in graphics APIs, GTK 4.4]

GLX와 EGL

그래픽 라이브러리인 Cairo나 Skia는 위와 같은 그래픽 API나 CPU를 사용해 다양한 기능을 제공하는 라이브러리다. (CPU 기반 로우레벨 라이브러리는 Pixman이 유명)

안티얼라이싱에 대해서도 다룰려 했는데, 위키에 이미 보기좋게 정리가 되어있는 듯 하다.

14. 기타 칩

개요

GPU를 다룬김에 다른 co-processor들도 간략히 다루어보기로 했다.

간단한 비교

애플 M1칩을 필두로 점점 중요해지고 있는 추세다.

대상은 DSP, FPGA, ASIC의 일종인 TPU.

한눈에 보기

본격적으로 들어가기 전에 CPU와 GPU의 구조를 비교해보자.

CPU vs GPU

CPU

직렬 프로그램(순차코드)에 명령 수준 병렬처리(파이프라인과 슈퍼 스칼라)
병렬의 경우 SIMD를 사용
정확한 분기예측
많은 명령어 (CISC의 경우)
오프로드할 필요가 없어 낮은 대기시간

GPU

백터 데이터와 처리량에 최적화
DRAM 대역폭이 높음
계산에 중점을 두어 캐시와 제어 요소가 적음
개별 스레드의 대기시간과 성능에 중점두지 않음

DSP

DSP(Digital Signal Processor)는 기본적인 신호처리 알고리즘을 내장하고 있다.

TI의 DRA78x Infotainment Applications Processor (Rev. H), 다양한 기능을 내장함

주목할 점이라면 VLIW 명령어셋을 사용하는 경우가 많다.

따라서 한 클럭당 많은 일을 할 수 있는 편이다. (저지연, 전력)

퀄컴에 따르면 RISC에서 29개의 명령어로 이루어진 고속 푸리에 변환 작업을 1클럭만으로 실행시키는 경우도 있다.

낮은 클럭에서도 높은 성능을 보여줌

말이 나온겸 VLIW에 대해서도 알아보자. [Very-Long Instruction Word (VLIW) Computer Architecture, Advanced Out-of-Order Superscalars and IntroducBon to VLIW]

종속성이 없는 명령어 여러개를 한번에 처리(Execute)하는 명령어 처리기법이다.

VLIW architecture, VLIW Pipeline

장점: 병렬처리가 가능하고, CPU에서 스케쥴링(슈퍼스칼라와 비순차적 실행)이 없어 회로가 간단해짐
단점: 의존성이 강한 연속적인 명령어(병렬불가)는 비효율적, 컴파일러의 제작 난이도가 높음, 분기예측과 캐시미스에 취약함

한마디로 말해서 CPU에서 하던 스케쥴링 작업을 컴파일 타임에 해버리고 하드웨어에서는 그냥 실행만 하는 구조로 효율적 클럭사용, 작은 유닛 크기를 얻겠다는 전략인데..

컴파일 타임에서 메모리 접근을 결정적으로 만들기가 상당히 어렵다.

그러나 DSP의 경우 데이터 처리자체가 스트리밍에 가깝기에 캐시미스가 중요하지 않고 신호처리는 병렬처리를 요구하므로 VLIW와 잘 맞아떨어졌다.

또한 캐시관련 특수성 때문에 폰노이만이 아닌, 하버드 아키텍처를 사용하는 여러모로 특이한 케이스다.

VLIW 설명겸 인텔과 HP가 심취했다 타격받았던 불운의 설계, EPIC도 알아보자. [EPIC Architecture (Explicitly Parallel Instruction Computing), The IA-64 architecture and Itanium processors Explicitly Parallel Instruction Computing, Historical background for EPIC instruction set architectures, IA-64, Understanding EPIC Architectures and Implementations, IA-64 Architecture Overview]

대체 무엇이 매력적이었던걸까?

간단히 말하면 슈퍼스칼라와 비순차적 실행을 VLIW에 접목해 보다 효율적이고 범용적으로 만들었다.

우선 놀고있는 CPU를 컴파일러단에서 병렬적으로 만들어 최대한 일하게 만들기 위한게 목적.

지금은 비슷한 목적으로 하이퍼 스레드가 사용되나 설계의 관점으로만 보면 컴파일러만로 장기적인 성능개선이 가능한 EPIC이 좋아보이기는 한다.

컴파일러를 활용

먼저 전반적인 명령어 구조는 VLIW와 비슷하다.

그러나 전부 다 컴파일러가 감당해야 해서 비결정적 메모리 접근등의 문제를 해결하기 어려웠던 VLIW와 달리 작업그룹 종속성에 대한 표현을 위주로 하도록 만들어져 슈퍼스칼라와 가까워진 방향으로 설계되었다.

Dynamic VLIW는 트랜스메타의 크루소 방식으로 알려져 있다.

명령어와 작업그룹 종속성

병렬을 활용하므로, 분기를 줄일 수 있었다.

분기를 효과적으로 줄임

제어와 데이터에 대한 투기적 실행은 메모리 베리어 문제를 개선해 비순차적인 실행이 가능하도록 만들었다.

이로 인해 메모리 접속 지연, 캐싱, 스케쥴링의 유연성등에 도움을 주었다.

제어와 데이터

ALAT(Advancded Load Address Table)이 특이한데, 다음과 같이 이루어진다.

로드한 메모리(ld.a)의 레지스터(r1)를 엔트리에 추가
추가를 시도시 충돌이 나면 엔트리에서 제거
추후 체크(chk.a)할 때 엔트리에 존재하면 성공, 없으면 실패를 의미하므로 분기함

RRB(Register Rotation Base)는 루프 언롤링 대신 하위집합에 대한 엑세스 이름을 바꾸어 준다.

GR(General Register), FP(Floating Point Resisters)가 대표적인 예였다.

예를 들어 RRB의 값이 10일때, GR[35] 참조는 GR[45]의 값을 사용한다.

파이프라이닝

이렇게 이론적인 아키텍처 설명만 들어보면 혹할만도 하다싶다. ㅋㅋㅋ

이와 반대로 하드웨어 레벨 JIT을 최대한 활용해버리는 방식이 블로그에서 몇번 언급했었던 The Reduceon이라는 함수형 아키텍쳐다. [Reduceron, an efficient processor for functional programs, The Reduceron: Widening the von Neumann Bottleneck for Graph Reduction Using an FPGA]

91.5MHz FPGA에서 2.8GHz Pentium급 성능을 냈다나.

이쪽에 관심이 많다면 HVM이라는 함수형 런타임도 살펴보라.

FPGA

FPGA는 프로그래밍 가능한 반도체다.

자일링스와 알테라 FPGA 아키텍처

FPGA는 Switch의 연결에 따라 라우팅되며, 핵심인 CLB를 자세히 들여다보면 LUT(Lookup Table), 플립플롭(Flip Floop), 멀티플렉서(Multiplexer)로 이루어졌다. [Performance Analysis of Nanoelectromechanical Relay-Based Field-Programmable Gate Arrays]

스위치와 CLB 구조

LUT: 논리기능
Flip Floop: 순차논리
Mux: 조합논리와 순차논리 중 데이터 출력을 선택

멀티플렉서는 알다시피 선택하는 회로다.

멀티플렉서

LUT는 멀티플렉서와 S램을 사용해 논리 연산을 구현한다.

예를 들어 3비트 LUT는 8비트 SRAM과 트리형태의 7개 멀티플렉서로 구성되어 3비트에서 가능한 모든 논리연산을 수행할 수 있다.

LUT 구조와 동작

플립플롭으로는 D플립플롭을 사용하며, 회로와 진리표는 다음과 같다. [D Flip Flop]

다음 활성 클럭마다 값이 바뀜

최신 FPGA는 연산속도를 올리고 라우팅을 줄이기 위해 6입력 LUT와 산술 연산을 위한 Carry chain를 CLB에 통합하고, 곱셈 계산을 위한 DSP등을 사용해 LUT를 보완하고 있다.

CLB와 6입력 LUT

어째서 설정이 가능한지와 작동방식은 대략적으로 이해했을것이다.

그럼 계산방식을 비교해 보자.

동기적이고 조합을 이용함
임의적 동시성
명시적으로 시간을 표현
메모리 계층이 유연

작업 파이프라인으로 보면 다음과 같다.

각 작업이 연결되어 매 클럭마다 실행된다.

FPGA 파이프라인

소프트웨어로 하드웨어를 설정해 작업 파이프라인이 일치하기 때문에 성능과 전성비 모두 좋다.

그러나 가격이 비싸고, 무엇보다 회로 설계 난이도가 매우 높다는 트레이드 오프가 있다.

TPU

TPU(Tensor Processing Unit)는 대표적인 ASIC(주문형 반도체, Application-Specific Integrated Circuit)의 예이다.

TPU v4 아키텍처

대체 어떠한 이유로 TPU를 만들었는가에 대해 알아보자.

다음은 신경망의 작동방식이다. (GIF 크기가 크므로 새탭에서 열어 확인해보세요)

784개(28x28)의 벡터로 변환 [입력데이터]
숫자 "8"을 인식하는 뉴런은 입력값 매개변수 값(가중치, 빨간선)을 곱함
(매개변수는 이미지와 "8" 모양의 유사성을 알려주는 특징을 데이터에서 추출하는 필터 역할)
곱한 값은 신호강도를 뜻하며, 모두 더하여 가장 높은 결과가 정답일 가능성이 높음

따라서 많은 행렬의 곱셈과 덧셈이 발생한다.

계산을 어떻게 처리하는가 보자.

TPU의 MXU(Matrix Multiplication Unit)이 바로 곱셈과 가산기의 배열인데, 128x128 곱셉/가산기다.

CPU, GPU, TPU

CPU: 순서대로 처리하며, 계산결과는 매번 내부 메모리(레지스터, 캐시)에 저장
GPU: 대규모로 병렬연산을 수행함, 그러나 역시 중간 계산 결과를 읽고 저장하기 위해 내부 메모리에 접근해야함
TPU: 모든 계산 단계를 알고 있으므로, 수천개의 곱셈/가산기를 배치하고 서로 직접 연결해 Systolic Array구조를 만들어 중간단계에는 메모리에 접근할 필요가 없음

아키텍쳐상 두개의 장점이 있다는 것을 알 수 있다.

SIMD나 GPU의 벡터처리에서 확장해 행렬단위를 단일 클럭에서 처리할 수 있으며, Systolic Array 구조로 중간에 메모리에 접근하지 않는 다는 것.

계산 단위

계산 과정

TPU는 커다란 부동소수점 연산(99번째 백분위수), 캐시, 분기예측, 비순차적 실행, 멀티프로세싱, 투기적 프리페칭, 주소병합, 멀티스레딩과 컨텍스트 전환등 범용 연산이 전혀 필요없는 결정론적 설계로 유닛을 효율적으로 쓸 수 있었다.

TPU v1 - 2%에 불과한 컨트롤 유닛

최근에는 TelaMalloc이라고 할당을 효율적으로 하는 방식도 나와 할당을 효율적으로 해준다. [구글, 기계 학습 가속 위한 메모리 할당 기법 개발...최대 2배 속도 향상]

텔라말록

이 뿐만이 아니다.

모든 곱셈은 bfloat16을 사용하고, 덧셈은 Float32를 사용한다. [BFloat16: The secret to high performance on Cloud TPUs]

bfloat16

16bit이므로 32bit에 비해 적은 메모리를 사용하고 칩 크기도 줄일 수 있음
신경망은 지수부(Exponent)가 가수부(Mantissa)보다 중요하므로 비율을 조정
조정한 지수부의 크기는 Float32와 같으므로 Float32로의 변환이 쉬움

비슷하게 부동소수점을 계산에 적합하게 만들자는 시도로 Posits가 있다. [Posits, AI의 수학을 향상시키는 새로운 종류의 숫자]

이러한 효율적 설계로 전성비가 매우 좋다.

CPU보다 83배, GPU보다 29배

마지막으로 TPU는 클러스터링인 TPU Pods을 구성해 부하를 분산할 수 있다.

TPU Pod

15. 참고

첫 목표와 달리 본의 아니게 아래로 올수록 길어져버린 것 같다..ㅋㅋ

그래도 재미는 있었으니 됐지..

전반적으로 참고한 글 목록입니다.

Pure CSS + SVG 애니메이션 적용 실패기

BlaCk_Void — Wed, 13 Apr 2022 14:58:24 +0900

때는 2022년 2월 21일.

비디오 플레이어 디자인을 고민할 때였다.

기본, 1줄 프로토타입, 2줄 프로토타입

이왕 만드는 것, 재생-일시정지 버튼에 무언가 포인트를 넣고 싶었다.

아이디어 원천은 LG 음악앱.

폰은 구렸지만 음악앱 하나는 기똥차게 좋았던 LG..ㅠ

처음 써봤을때 재생, 리플레이 인터렉션보고 감동받았다. (투박한 유튜브 따위와 비교가 안됨)

대략 이런 느낌 [Dribble: Play -> Pause, Micro Interactions]

먼저 움직이는 SVG를 만들어봤다.

일시정지 사각형 두개가 중앙에서 만나 깔끔하게 옆으로 솟아나는 재생버튼을 만들기란 어지간히 어려운 일이 아니었다.

똥손이라 단순한 크기조정과 이동 정도를 구현하면 몰라도, 자체적으로 그래픽 리소스를 만들 자신은 없었다.

Pure CSS + SVG 조합으로 가장 좋은 방법은 SVG 필름스트립(개념, 구현, 툴링, lottie-web issue)이지만 애프터 이펙트를 쓸 줄 모르니ㅠㅠ

필름스트립 기법 자체는 리소스가 부족하던 고전 게임에서도 많이 사용되었다.

대신 간단한 조정으로 깔끔해 보이면서도 대안이 될만한 애니메이션을 만들어냈다.

우측 사각형이 작아지며 왼쪽으로 이동
좌측 사각형에 닿게 되면 사다리꼴 모양이 만들어짐
좌측 사각형은 작아지며 우측으로 조금 이동하다 사라짐
이때 모양을 연속적으로 관측하면 크기가 작기 때문에 재생버튼과 상당히 유사해짐
우측 사각형은 작은 재생 버튼으로 교체 후 원래 크기로 복원
자연스러운 모핑과 눈에띄는 강조 표현..ㅎ

실제 SVG 파일 (눌러보세요)

원래 존재하던 파일 2개 속의 요소만을 이용한것을 볼 수 있다. (왼쪽 사각형, 오른쪽 사각형, 재생버튼)

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" width="16" height="16" fill="context-fill" fill-opacity="context-fill-opacity">
  <style type="text/css">
    #pauseBar {
      animation: hideBar 2s ease infinite;
      transform-origin: center;
      opacity: 0;
    }
    @keyframes hideBar {
      0% {
        opacity: 1;
        transform: translate(0px);
      }
      75% {
        opacity: 1;
        transform: translate(0px) scale(1);
      }
      80% {
        opacity: 1;
        transform: translate(1px) scale(0.9);
      }
      100% {
        transform: scale(0.8);
      }
    }

    #pauseMove {
      animation: move 1s ease-in-out alternate infinite;
      transform-origin: center;
    }
    @keyframes move {
      from {
        transform: translate(-1px) scale(0.95);
      }
      25% {
        transform: translate(-1px) scale(0.8);
      }
      35% {
        d: path("m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z");
        transform: translate(-1px) scale(0.6);
      }

      36% {
        d: path("m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z");
        transform: scale(0.75);
      }
      50% {
        transform: scale(0.8);
      }
      to {
        d: path("m11.5 14-1 0A1.5 1.5 0 0 1 9 12.5l0-9A1.5 1.5 0 0 1 10.5 2l1 0A1.5 1.5 0 0 1 13 3.5l0 9a1.5 1.5 0 0 1-1.5 1.5z");
        transform: scale(1);
      }
    }
  </style>
  <path d="m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z" id="pauseBar" />
  <path d="m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z" id="pauseMove"/>
</svg>

아ㅋㅋ 이제

일시정지 -> 재생: 순방향
재생 -> 일시정지: 역방향

으로만 만들면 되니 간단하겠네~

싶었으나.. 간과한것.

DOM 수정은 일체 불가하며, 단 한줄의 Javascript도 사용할 수 없는 상황이었다.

유일하게 동적인건 [paused]라는 어트리뷰트를 사용할 수 있다는 점..

갑자기 생각난 꼼수로 정방향/역방향으로 계속 움직이는 이미지를 상태가 보였을때만 끊어서 보여주면 어떻게든 되지 않을까 싶었으나 ㅋ

과연 엄밀하게 틱이 맞아질거란 걱정은 있었다.

(참고로 animation이 infinite가 아니면 최초 한번밖에 실행이 안되기에 계속 움직이지 않는 의미가 없었다)

.playButton {
  background-image: url(chrome://global/skin/media/pause-fill.svg);
}
.playButton:not([paused]){
  animation: playPlay 1s;
}
.playButton[paused] {
  background-image: url(chrome://global/skin/media/play-fill.svg);
  animation: playPaused 1s;
}

@keyframes playPlay {
  from {
    background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16' width='16' height='16' fill='context-fill' fill-opacity='context-fill-opacity'%3E%3Cstyle type='text/css'%3E %23pauseBar %7B animation: hideBar 1s ease reverse infinite; transform-origin: center; opacity: 0; %7D @keyframes hideBar %7B 0%25 %7B opacity: 1; transform: translate(0px); %7D 50%25 %7B opacity: 1; transform: translate(0px) scale(1); %7D 60%25 %7B opacity: 1; transform: translate(1px) scale(0.9); %7D 100%25 %7B transform: scale(0.8); %7D %7D %23pauseMove %7B animation: move 1s ease-in-out infinite; transform-origin: center; %7D @keyframes move %7B from %7B transform: translate(-1px) scale(0.95); %7D 25%25 %7B transform: translate(-1px) scale(0.8); %7D 35%25 %7B d: path('m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z'); transform: translate(-1px) scale(0.6); %7D 36%25 %7B d: path('m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z'); transform: scale(0.75); %7D 50%25 %7B transform: scale(0.8); %7D to %7B d: path('m11.5 14-1 0A1.5 1.5 0 0 1 9 12.5l0-9A1.5 1.5 0 0 1 10.5 2l1 0A1.5 1.5 0 0 1 13 3.5l0 9a1.5 1.5 0 0 1-1.5 1.5z'); transform: scale(1); %7D %7D %3C/style%3E%3Cpath d='m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z' id='pauseBar' /%3E%3Cpath d='m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z' id='pauseMove'/%3E%3C/svg%3E");
  }
  to {
    background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16' width='16' height='16' fill='context-fill' fill-opacity='context-fill-opacity'%3E%3Cstyle type='text/css'%3E %23pauseBar %7B animation: hideBar 1s ease reverse infinite; transform-origin: center; opacity: 0; %7D @keyframes hideBar %7B 0%25 %7B opacity: 1; transform: translate(0px); %7D 50%25 %7B opacity: 1; transform: translate(0px) scale(1); %7D 60%25 %7B opacity: 1; transform: translate(1px) scale(0.9); %7D 100%25 %7B transform: scale(0.8); %7D %7D %23pauseMove %7B animation: move 1s ease-in-out infinite; transform-origin: center; %7D @keyframes move %7B from %7B transform: translate(-1px) scale(0.95); %7D 25%25 %7B transform: translate(-1px) scale(0.8); %7D 35%25 %7B d: path('m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z'); transform: translate(-1px) scale(0.6); %7D 36%25 %7B d: path('m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z'); transform: scale(0.75); %7D 50%25 %7B transform: scale(0.8); %7D to %7B d: path('m11.5 14-1 0A1.5 1.5 0 0 1 9 12.5l0-9A1.5 1.5 0 0 1 10.5 2l1 0A1.5 1.5 0 0 1 13 3.5l0 9a1.5 1.5 0 0 1-1.5 1.5z'); transform: scale(1); %7D %7D %3C/style%3E%3Cpath d='m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z' id='pauseBar' /%3E%3Cpath d='m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z' id='pauseMove'/%3E%3C/svg%3E");
  }
}
@keyframes playPaused {
  from {
    background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16' width='16' height='16' fill='context-fill' fill-opacity='context-fill-opacity'%3E%3Cstyle type='text/css'%3E %23pauseBar %7B animation: hideBar 1s ease infinite; transform-origin: center; opacity: 0; %7D @keyframes hideBar %7B 0%25 %7B opacity: 1; transform: translate(0px); %7D 50%25 %7B opacity: 1; transform: translate(0px) scale(1); %7D 60%25 %7B opacity: 1; transform: translate(1px) scale(0.9); %7D 100%25 %7B transform: scale(0.8); %7D %7D %23pauseMove %7B animation: move 1s ease-in-out reverse infinite; transform-origin: center; %7D @keyframes move %7B from %7B transform: translate(-1px) scale(0.95); %7D 25%25 %7B transform: translate(-1px) scale(0.8); %7D 35%25 %7B d: path('m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z'); transform: translate(-1px) scale(0.6); %7D 36%25 %7B d: path('m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z'); transform: scale(0.75); %7D 50%25 %7B transform: scale(0.8); %7D to %7B d: path('m11.5 14-1 0A1.5 1.5 0 0 1 9 12.5l0-9A1.5 1.5 0 0 1 10.5 2l1 0A1.5 1.5 0 0 1 13 3.5l0 9a1.5 1.5 0 0 1-1.5 1.5z'); transform: scale(1); %7D %7D %3C/style%3E%3Cpath d='m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z' id='pauseBar' /%3E%3Cpath d='m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z' id='pauseMove'/%3E%3C/svg%3E");
  }
  to {
    background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16' width='16' height='16' fill='context-fill' fill-opacity='context-fill-opacity'%3E%3Cstyle type='text/css'%3E %23pauseBar %7B animation: hideBar 1s ease infinite; transform-origin: center; opacity: 0; %7D @keyframes hideBar %7B 0%25 %7B opacity: 1; transform: translate(0px); %7D 50%25 %7B opacity: 1; transform: translate(0px) scale(1); %7D 60%25 %7B opacity: 1; transform: translate(1px) scale(0.9); %7D 100%25 %7B transform: scale(0.8); %7D %7D %23pauseMove %7B animation: move 1s ease-in-out reverse infinite; transform-origin: center; %7D @keyframes move %7B from %7B transform: translate(-1px) scale(0.95); %7D 25%25 %7B transform: translate(-1px) scale(0.8); %7D 35%25 %7B d: path('m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z'); transform: translate(-1px) scale(0.6); %7D 36%25 %7B d: path('m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z'); transform: scale(0.75); %7D 50%25 %7B transform: scale(0.8); %7D to %7B d: path('m11.5 14-1 0A1.5 1.5 0 0 1 9 12.5l0-9A1.5 1.5 0 0 1 10.5 2l1 0A1.5 1.5 0 0 1 13 3.5l0 9a1.5 1.5 0 0 1-1.5 1.5z'); transform: scale(1); %7D %7D %3C/style%3E%3Cpath d='m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z' id='pauseBar' /%3E%3Cpath d='m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z' id='pauseMove'/%3E%3C/svg%3E");
  }
}

역시 불안한 예상은 벗어나지 않구, 처음과 고장난 시계처럼만 맞아떨어졌다.

뒤틀리는 싱크 ㅠㅠㅠ

다음 시도는 약간 더 복잡해질수 밖에.

재생->일시정지까지만
일시정지->재생까지만

으로 딱 정해진 일만 하게하자라는 아이디어였다.

그런데 아까 구현을 보았다시피 진행속도는 ease를 따른다.

cubic-bezier(.25, .1, .25, 1)

전체가 2초라지만 1초가 절반이 아니며, 가속이 그대로 이어가도록 나누기가 어렵다는 의미다.

베지어 곡선을 나눠서 진행하기 위해 스택오버플로우 답변을 바탕으로 간단하게 코딩해봤다.

SplitCubicalBezier

GitHub - black7375/SplitCubicalBezier

Contribute to black7375/SplitCubicalBezier development by creating an account on GitHub.

github.com

다음처럼 나눠진 값이 출력된다.

import { presets, createCubicBezier, getSplitCubicBezier } from "splitCubicalBezier";

const linear1 = presets.linear;                    // Same as linear2
const linear2 = createCubicBezier(x1, y1, x2, y2); // { xs: [ 0, 0, 1, 1 ], ys: [ 0, 0, 1, 1 ] }
const results = getSplitCubicBezier(linear2, 0.5); // { left: [ 0, 0, 0.5, 0.5 ], right: [ 0.5, 0.5, 1, 1 ] }

우리가 나눌 구간은 @keyframe hidebar 75%로 먼저 키프레임 각 구간의 시간을 정해주고,

각각에 해당하는 가속곡선을 구해줬다.

위와 같은 식? (예제라 실제값이랑 다를수도? 당시에 기록용으로 남겨놓기 위한 짤)

pause 애니메이션,

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" width="16" height="16" fill="context-fill" fill-opacity="context-fill-opacity">
  <style type="text/css">
    #pauseBar {
      animation: hideBar 0.65s cubic-bezier(0, 0, 0.51, 0.74) alternate;
      transform-origin: center;
    }
    @keyframes hideBar {
      from {
        transform: translate(0.97px) scale(0.85);
      }
      10% {
        transform: translate(0px) scale(1);
      }
      to {
        transform: translate(0px);
      }
    }

    #pauseMove {
      animation: move 0.65s cubic-bezier(0.31, 0.41, 0.57, 1) alternate;
      transform-origin: center;
    }
    @keyframes move {
      from {
        d: path("m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z");
        transform: scale(0.75);
      }
      23% {
        transform: scale(0.8);
      }
      to {
        d: path("m11.5 14-1 0A1.5 1.5 0 0 1 9 12.5l0-9A1.5 1.5 0 0 1 10.5 2l1 0A1.5 1.5 0 0 1 13 3.5l0 9a1.5 1.5 0 0 1-1.5 1.5z");
        transform: scale(1);
      }
    }
  </style>
  <path d="m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z" id="pauseBar" />
  <path d="m11.5 14-1 0A1.5 1.5 0 0 1 9 12.5l0-9A1.5 1.5 0 0 1 10.5 2l1 0A1.5 1.5 0 0 1 13 3.5l0 9a1.5 1.5 0 0 1-1.5 1.5z" id="pauseMove" />
</svg>

play 애니메이션

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" width="16" height="16" fill="context-fill" fill-opacity="context-fill-opacity">
  <style type="text/css">
    #pauseBar {
      animation: hideBar 0.35s cubic-bezier(0.34, 0.62, 0.68, 1) alternate;
      transform-origin: center;
      opacity: 0;
    }
    @keyframes hideBar {
      33% {
        opacity: 1;
        transform: translate(0.97px) scale(0.85);
      }
      47% {
        opacity: 1;
        transform: translate(0.97px) scale(0.85);
      }
      to {
        transform: scale(0.8);
      }
    }

    #playMove {
      animation: move 0.35s cubic-bezier(0.43, 0, 0.67, 0.66) alternate;
      transform-origin: center;
    }
    @keyframes move {
      from {
        d: path("m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z");
        transform: translate(-1px) scale(0.6);
      }
      29% {
        transform: translate(-1px) scale(0.8);
      }
      to {
        transform: translate(-1px) scale(0.95);
      }
    }
  </style>
  <path d="m4.5 14-1 0A1.5 1.5 0 0 1 2 12.5l0-9A1.5 1.5 0 0 1 3.5 2l1 0A1.5 1.5 0 0 1 6 3.5l0 9A1.5 1.5 0 0 1 4.5 14z" id="pauseBar" />
  <path d="m2.992 13.498 0-10.996a1.5 1.5 0 0 1 2.245-1.303l9.621 5.498a1.5 1.5 0 0 1 0 2.605L5.237 14.8a1.5 1.5 0 0 1-2.245-1.302z" id="playMove"/>
</svg>

근데 역시 적용해보니 마음처럼 안되드란.

이렇게 뻘짓을 하다가 구현 실패는 하고 시간도 날라갔다..ㅠㅠㅠ

좋은 아이디어 있으면 댓글 주세요.

한줄요약: 예능은 예능으로.

지금보니 키프레임 구간을 나누는 코드가 깃허브에 반영 안되어 있네요.

집에가서 있나 찾아보겠습니다.

객체지향 시스템과 패러다임 그리고 철학

BlaCk_Void — Tue, 14 Dec 2021 00:31:21 +0900

자바스크립트는 왜 프로토타입을 선택했을까

라는 글을 읽고 떠오르는 내용들을 덧붙이거나 정리 해보았습니다.

원글과는 접근법이 좀 다르며, 기획이 아닌 급하게 쓴 글이라 의식의 흐름 사이에서 표류합니다 ㅠㅠㅠ

빠른요약

클래스와 프로토타입의 가장 커다란 차이는 객체 생성 방식 [클래스 -> 인스턴스 vs 객체 -> 복사된 객체].
가장 큰 공통점은 객체지향이며, 프로그램을 객체라는 단위로 나누고 상호작용하게 하는 것.
객체지향의 핵심인 캡슐화를 잘하기 위한 가장 간단한 방법은 추상화를 잘 하는 것.
- 추상화는 데이터 위주의 성질(고전적 OOP), 형태(타입), 상태(데이터 주도 설계)와 관계 중심인 시간(절차지향), 행동(함수형), 정의(논리형), 상황(도메인 주도 설계, AOP) 등으로 나누어 생각할 수 있음.
- 잘 분류하고 설계하기 위해서 사고의 형식을 인식하게 만드는 다양한 범주의 이해가 있다면 좋음 [예) 칸트의 4강 12목].
철학과 패러다임
- 절차형: 시간은 대부분의 추상화에 영향을 미치며, Goto처럼 컨텍스트가 섞이게 만드는 문법은 좋지 않음.
- 함수형: 행동의 형태로 나타내려 하기 때문에 타입(형태)와 깊은 연관관계.
- 논리형: 사실과 규칙으로 논리를 구성하고, 질의를 함으로서 술어논리의 결과를 얻을 수 있음.
- 전통적 OOP: 직관적. 하지만 완벽한 속성을 알아내기는 불가능함.
- 데이터 주도 설계: 로직의 상태를 다루려는 함수형과 달리 컴퓨터 자체에서의 상태를 줄이려 시도. 캐시 히트를 높혀서 성능향상을 가져옴.
- 도메인 주도 설계: 전통적 OOP와 달리 도메인과 맥락에 따라 다르게 설계를 함(그림이론-용도의미론과 비슷), 서브도메인의 의존성 주입을 하는 AOP를 사용하면 구현이 편해짐.
MVP
- 프로토타입 제작: 중요한 기능이 포함되어야 하며 디자이너, 개발자, 재무등의 관점에 따라 달라질 수 있음. 많은 사람들이 중요하다고 생각하는 제품의 유사도에 따라 전형적인 요건.
- MVP: 최소한의 완성도가 보장된 사용이 가능하고, 최종단계로 생각하는 제품과 유사하게 설계해야함.
객체지향과 존재
- 플라톤: 보편적 성질이 불변하며 실재하고, 개별적 존재들은 보편적 특성이 결여된 채로 존재한다 주장.
- 아리스토텔레스: 개별적 개체만이 근본적 실체이며, 보편자는 상하/포함 관계에서 나타나는 표상이라 주장.
- 클래스-인스턴스는 플라톤의 이데아론을, 프로토타입-복제된 객체는 아리스토텔레스 실체론과 유사.

0. 객체지향 들어서기

객체지향의 주요구현 형태라 하면 Java, C++등에서 주로 사용하는 클래스와 Javascript, Io등에서 사용하는 프로토타입으로 나눌수 있다.

커먼 리스프의 CLOS, 스칼라와 러스트의 Trait, 루비의 Mixin등도 있다고 하지만 가장 대표적이고 극적인 객체지향 형태는 저 둘이죠.

클래스와 프로토타입 시스템의 가장 큰 차이는 무엇일까?

새로운 객체로 분기하기 위해, 클래스는 new, 프로토타입은 clone으로 이루어진다는 것이다.

Object object =  new Object();

anObject := Object clone

Java와 Io [작고 아름다운 언어 Io]

둘은 대략 다음 표같이 생각해볼 수 있다.

프로토타입 기반은 클래스와 인스턴스 구분이 없으므로, 당연히 static 메서드와 instance 메서드를 따로 나눌수 없다.

반대로 공통점은 무엇일까?

당연하겠지만 객체지향이라는 점이다.

그럼 객체지향은?

프로그램을 객체라는 단위로 나누고
상호작용하게 하는 것이다.

가장 간단한 정의라 할 수 있다.

보통 객체지향을 설명하면 특징이 따라오며 특징이라 함은

캡슐화: 변수와 함수를 단위로 묶음
은닉화: 세부 구현이 외부로 드러나지 않게함
상속성: 자식은 부모의 속성과 기능을 물려받음
다형성: 상황에 따라 여러가지 형태를 가질 수 있음

을 뜻한다.

캡슐화는 어떻게 나누어야 할까를 고민한 결과이며, 상속은 이미 분류해 놓은 것을 재사용하기 위한 일종의 패턴이다.

은닉화는 객체끼리 상호작용에 있어 노출을 줄여 의미있는 인터페이스만 노출하거나 보안을 유지할 수 있게한다.

다형성은 상호작용이 이루어짐에 따라 특정한 기준을 만족할때 다른 동작을 하는 특성이다.

많이 알려진 SOLID 원칙은 상호작용이 어떻게 일어나야 하는가에 대한 패턴이다.

1. 추상화와 패러다임

앞선 추론으로 객체지향에서 가장 핵심은 캡슐화임을 알 수 있으며, 묶기위해 어떻게 나눌(분류, classing)것인가에 대해 논의해볼 필요가 있다.

분류하기 위해 간단히 생각해낼 수 있는 일반적인 방법중 하나는 추상화(Abstraction)이다.

추상화 과정의 핵심은 특징을 뽑아내는 것이며, 유사도 또한 한가지 예라고 할 수 있다.

지금 읽어보니 부끄부끄하지만 추상화 자체는 예전 썼놨던 글을 참고해보자.

https://black7375.tistory.com/6

프로그래밍과 추상화에 대하여.

HtDP를 읽는 중인데 오늘도 뻘 생각이 나서 그냥 필이 꽃힌 김에 적어봤다. (내 성격의 최대 장점이자 단점. 잡생각이 너무 많음. 글 중간에도 의식의 흐름대로 빠지는 것이 보인다.) 내 맘대로 하

black7375.tistory.com

1.1 분류

보통 추상화는 다음과 같이 나눌 수 있을테며, 각종 패러다임은 추상화 방식이라 생각할 수 있다.

모든 패러다임은 아니지만, 유명하거나 최근 떠오르는 패러다임은 기술하려 노력했습니다.

(더 나은 정리나 정의가 떠오른다면 댓글 주세요!!)

데이터 위주

성질: 행동을 통해 나타나는 장기적인 특성
- 예) 굵기, 색상
- 패러다임) 우리가 보통 생각하는 OOP
형태: 없다면 실체를 생각할 수 없는 것 (타입)
- 예) 정수, 유리수, 문자열
- 패러다임) 제네릭 프로그래밍과 타입 추론 시스템
상태: 특정한 기준을 만족시키는 여러 구성 중 하나
- 예) On/Off, 교착, 평형
- 패러다임) 데이터 주도 설계(Data Oriented Design)

관계 위주

시간: 행위가 일어나는 시간
- 예) 로딩, 렌더링
- 패러다임) 구조적 프로그래밍(편의상 절차지향이라 표기하겠음)
행동: 행동의 형태로 기술
- 예) 사상(map), 필터, 리듀스
- 패러다임) 함수형
정의: 행동의 성질을 규정(사실 + 규칙, 제어)
- 예) A와 B는 C관계가 있다, A가 존재하는가?
- 패러다임) 논리형
상황: 정보와 활동 영역을 규정
- 예) (대기업의) 배포, (스타트업의) 배포, (의료용 AI) 개발, (블로그 테마) 개발
- 패러다임) 도메인 주도 개발

분류를 위해 우리가 잘 설계해야 하는 것은 사고의 형식을 인식하게 만드는 다양한 "범주"라해도 과언이 아니다.

철학에서 유명한 범주로는 칸트의 4강 12목과 헤겔의 범주론이 존재하며 칸트의 범주론은 아랫글의 초반에 나온 파트를 참고해볼 수 있다.

아래 서술에서 사용되는 일부 단어가 이해되지 않는게 있어도 읽어볼 만하다. (정언판단 등)

https://black7375.tistory.com/36

내 맘대로 프로그램 설계 4. - 고정 크기 데이터.

이번 섹션에서는 섹션2,3 정리와 고정 크기 데이터에 대하여 배우도록 하겠습니다. 다시 연재 시작했어요. 내 맘대로 하는 프로그램 설계 시리즈. Chapter1 - 간단한 데이터 처리(4섹션) 2017/12/27 - [

black7375.tistory.com

칸트의 경우 한눈에 들어오게 정리해볼만 하나 헤겔의 범주론은 꽤나 복잡하다.

헤겔은 내제된 모순성에서 준동되는 필연성을 이용해 절대정신을 설명하려 했던 사람이다.

아무래도 모든 시스템을 하나로 설명하려다 보니 규모가 큰데다 특유의 논법으로 처음보는 사람은 이해가 쉽지 않을 것이다.

https://ko.wikipedia.org/wiki/%EB%8C%80%EB%85%BC%EB%A6%AC%ED%95%99

대논리학 - 위키백과, 우리 모두의 백과사전

대논리학(『철학강요』-『Enzyklopädie der Philosophischen Wissenschaften Im Grundriss』-에 나오는 축약 형태의 논리학을 소논리학이라고 부르며, 이와 구별하여 단독 저작으로서의 논리학을 대논리학이라

ko.wikipedia.org

그는 변증법적으로 접근하기로 유명한데, 스텐포드 철학백과에 잘 나와있다.

https://plato.stanford.edu/entries/hegel-dialectics/

Hegel’s Dialectics (Stanford Encyclopedia of Philosophy)

“Dialectics” is a term used to describe a method of philosophical argument that involves some sort of contradictory process between opposing sides. In what is perhaps the most classic version of “dialectics”, the ancient Greek philosopher, Plato (s

plato.stanford.edu

말이 나온김에 헤갤의 방식으로 수량(Quantity)은 어떻게 표시되나 한번 알아보자.

정량(Quantum): "여럿"이 들어있는 밖 경계의 "하나"
수(Number): 모든 측면에서의 "하나"
크기(Extensive, 외연)와 세기(Intensive, 내연)양: 바깥 경계에 있는 "여럿"과 내부의 각각 "하나"
도(Degree): 모든 측면에서의 "여럿"

꽤나 합리적인 설명이지 않은가? ~~해설의 해설이 필요한 시점이다.~~

특이해보이는 그림을 자세히 들여다보면 알 수 있을 것이다.

정량: 정량한계란 단어를 바탕으로 이해하면 쉽다.
정량한계는 바람직한 확실성을 가지고 정량할 수 있는 최저농도(수치상 유효한 의미)를 뜻한다.
예를 들어 자는 1mm란 단위를 기준으로 "하나"라고 테두리에서 생각하지만, 1mm안에는 "여럿" µm, nm등이 모여있다.
수: 내부의 "하나들", 겉의 "하나"들이든 모두 "하나"라는 것이다.
예를 들어 1mm는 1µm 1000개로 구성되지만 둘 다 1이라 부르며, 책 하나나 비행기 하나나 모두 "하나"라 부른다.
크기와 세기: 세기 성질과 크기 성질을 참고하면 쉽다.
우선 세기는 변화가 가능하고 계의 크기와 무관한 성질이다. 계의 내부에서 각각 "하나"씩 존재한다.
크기는 계의 크기에 비례하는 양이다. 따라서 각 세기들이 모여 만들어져 "여럿" 크기들을 규정한다.
도: 각은 두 반직선이 이루는 도형을 말하는데, 도는 각의 단위이다.
안밖의 "여럿" 각도에서 본다고 생각해보자. 내각이든 외각이든 모두 "여럿" 도들로 이루어져 있다.

2단원 각도('각'과 '각도'의 의미)

이처럼 시스템의 안과 밖에서 "하나"와 "여럿"이 동시에 존재하는 것은 모순적이지만, 모순 덕분에 모든 시스템을 절대적으로 규정할 수 있었다.

사각형 안과 밖/하나와 여럿의 모든 경우 $2^n = 2^2$개를 다루었기 때문이다.

그럼 이 시스템에서 다룰수 없는 모순은 없을까?

대표적인 것이 비례(Ratio)이다. 비례는 $1:2 = 3:6$처럼 수를 사용하지만 "하나"와 "여럿"만으로 정의하기 힘들다.

이럴 때 필요한 것은 외부의 다른 개념!!

비례는 양에 대한 보편 개념으로 자신의 내용 속에서 "여럿" 집합적인 성질을 가지고 있다.

1:2와 3:6은 사상하므로 일대일 집합이라 할 수 있죠? 또한 2:4, 4:8.. 등등은 자신과 대등한 진부분 집합이라 할 수있어 무한집합 개념(둥근 사각형 전체)을 띄고 있다 말할 수 있습니다.

집합과 무한에 대해 다룬적이 있으니 궁금하신분은 읽어보십셔.

https://black7375.tistory.com/43

무한, 집합, 그리고 수에 대해서.

무한($\infty$)의 성질들을 집합과 수를 통해 간단하게라도 알아보도록 하자. M.C. Escher - Möbius Strip II(1963)[from Wallup] 1. 집합(Set)과 무한(Infinity). 무한의 성질을 알려면 집합에 대하여 아는 것이..

black7375.tistory.com

지금까지 나온 헤겔의 방식을 정리해보자면

자기 자신(즉자적 존재)이 있다면, 모순이 내재하기 때문에 대자적인 존재는 필연이다. [하나와 여럿, 안과 밖, 수량과 비례 등]
어떤 것과 다른 것 사이에서 왔다갔다하며 지양하게 되고 소거가 되는 동시에 보존된다.
왔다갔다한 덕분에 포괄하게 되는 것이다. ("하나"와 "여럿"을 이용해 수량을 정의한 것을 생각하자)
그렇지만 역시 또 모순이 존재하고 앞의 과정들을 반복하며 포괄적이고 보편적인 형태로 나아간다.

라고 표현할 수 있다.

한편 양과 항상 비교당하는 질(Quality)은 헤겔철학에서 대자 존재(자신과 대립하고 있는 것)의 보편적인 개념이다.

이제 어느정도 감이 잡혔을것이라 생각한다.

그렇다. 그의 세계는 모순에 의해 끊임없이 확장되는 세계다.

여전히 쉽지는 않겠지만 헤겔의 범주론을 이해/이용하고 싶다면 위의 예를 상기해보기 바란다.

1.2 설명

진짜로 그러한지 알아보기 앞서 각종 패러다임을 소개하는 순서부터 정리해야 할 것 같다.

전통적 객체지향 - 타입 - 데이터 주도 - 절차지향 - 함수형 - 논리형 - 관점 지향, 도메인 주도 설계 순서는 너무 뜬금없지 않은가?

내가 생각한 순서는

절차지향 - 함수형과 타입 - 논리형 - 전통적 객체지향 - 데이터 주도 - 도메인 주도와 AOP 순이다.

말로 단번에 설명하기 어렵지만 한결 나아졌다는 느낌이다.

어떻게 순서를 정했는가는 읽다보면 깨닫게 될 것이다.

우선 이렇게 쪼개보았다.

[절차지향] - [ 함수형과 타입, 논리형] - [전통적 객체지향 - 데이터 주도 - 도메인 주도와 AOP]

집합끼리의 유사성이 느껴지는가?

이번에는 주요기준을 적어봤다.

 시간         선언형                    객체지향 및 대체
[절차지향] - [함수형과 타입, 논리형] - [전통적 객체지향 - 데이터 주도 - 도메인 주도와 AOP]

절차지향, 시간

시간이란 나누기 좋은 기준이다.

다른 시간대에 존재하게 되면 확실성과 정합성이 깨질 확률이 높기 때문이다.

보통 철학(논리학)에서는 올바른 사고를 위해 확실성(섞이지 않았는가), 정합성[충분한 근거를 가지고 있는가, 동일률, 비모순율, 배중률]을 꼽는다.

예전 글 중간 쯤에 간단하게 정리해놓은적 있으니 역시 궁금하신 분들은 읽어보시기 바랍니다.

https://black7375.tistory.com/34

내 맘대로 프로그램 설계 3. - 함수와 변수.

원래 합쳐져서 Section2 였던 '기초'에서 '간단한 데이터 처리'와 '함수'로 나뉘어 구성하게 되었습니다. 너무 길어서 로딩도 오래걸리고, 읽는 사람도 힘들겠더군요. 내 맘대로 하는 프로그램 설계

black7375.tistory.com

온갖 사이드 이펙트가 펼쳐지는 복잡계 시간의 흐름은 상호작용이 일어나는 것을 의미하고, 상태가 변하며 규약과 행동양식 또한 변한다.

예를 들어 빅뱅, 공룡이 살던 시대, 산업혁명 전, 근대 모두 상태와 상황이 극심하게 바뀌었고 우리가 다루는 방식도 완전히 다르다.

컴퓨터의 빠른 발전 및 등장한 시기를 고려할 때 가장 먼저 나타나 상당한 시간적 단절이 있으며, 다른 방법들에도 이미 적용되었다고 가정될만큼 기초적인 패러다임(공통된 성질), 이 글을 읽는 대부분이 알만한(공통된 상태)인 절차지향은 먼저 소개하기에 적절하다.

절차지향이 나오기 전에는 Goto(jmp)문을 이용해 만들었다.

Goto vs 절차지향[프로그래밍 모델]

그러나 goto의 단점은 컨텍스트와 흐름이 섞여 나중에 알아보기가 매우 힘들다는 점이다.

시간이 뒤바뀐다면? [백투더퓨쳐1 (Back to the Future 1 : 1985)]

물론 Goto가 무조건 나쁘다는 것은 아니다.

중첩된 for문을 탈출하기에는 괜찮은 방법이며, FSM 구현이나 VM 구현때에도 유용하게(주로 성능 문제) 쓰이는 등 한정적인 용도로는 쓰이고 있다.

Goto로 제어문을 만드는 방법이 궁금하면 어셈블리 게임 해보는 것도 ㅎㅎ

https://store.steampowered.com/app/375820/Human_Resource_Machine/

Human Resource Machine on Steam

Program little office workers to solve puzzles. Be a good employee! The machines are coming... for your job. From the creators of World of Goo and Little Inferno.

store.steampowered.com

그러나 일반적인 용도로 사용하기에 적합하지 않다.

앞서 말했듯이 컨텍스트가 섞이게 되면 의도치 않은 부작용이 크고 디버깅하기가 매우 힘들어지며 나머지 추상화를 거의 포기하는 것과 같다.

일반적으로 for, while, switch와 같은 제어문, 함수들을 이용해 개발하며 Goto는 컨텍스트의 이동이라는 명확한 가치가 있을때만 사용하는 것을 추천.

러스트에서는 중첩된 loop용으로 블록을 만들어 부작용을 최소화한다.

https://doc.rust-lang.org/rust-by-example/flow_control/loop/nested.html

Nesting and labels - Rust By Example

It's possible to break or continue outer loops when dealing with nested loops. In these cases, the loops must be annotated with some 'label, and the label must be passed to the break/continue statement. #![allow(unreachable_code)] fn main() { 'outer: loop

doc.rust-lang.org

선언형

최근 UI 부분에서 Flutter, Swift UI, Jetpack compose등 선언형 방식을 채택하는 경우가 늘어나고 있다.

[Imperative vs. Declarative Kubernetes Management: A DigitalOcean Comic]

선언형은 어떻게(How) 해야 하는지보다 무엇(What)을 강조한다.

우리가 무엇을 해야할지 서술하면 구체적인 절차는 프로그램이 만들어주는 형태이다.

장점이라하면 읽기 쉽고, 작성하기 쉽다는 것이다.

단점으로는 돌아가는 모든 플로우를 제어하기 어려울 수 있어서 임베디드등 시스템 레벨에서는 맞지 않을 수 있겠죠.

함수형과 타입

[Programming Paradigm]

앞서 함수형은 행동의 형태로 나타나기 위한 패러다임이라 하였다.

그런데 형태를 기준으로 사고하는 방식이 있었다.

바로 타입(자료형).

[What is Purity?, Exploring Clojure (and FP vs OOP)]

만약 함수가 행하려는 형태(input/output)를 표현하기 어렵다면 함수형 프로그래밍을 하기 어려워진다.

정적 타입인 함수형 언어들에서 정교하게 타입 시스템을 구축하려 노력하는 이유일 것이다.

반대로 생각하면

자료형들에 따라 할 수 있는 행동이 달라지거나 제약된다.

예를 들어 숫자와 문자는 1 + 1 = 2, "가" + "나" = "가나"처럼 달라질 수 있고, "가" / "나"할 수 없듯이 자료형에 따라 제약되는 경우가 생긴다.

일반적으로 생각할때 하나로 묶을수 있는 자료형들이라 할지라도, "없다면 실체를 생각할 수 없는 것"이기 때문에 비슷한 행동을 하지만 다른 자료형들로 분리되어 존재한다.

같은 숫자지만 컴퓨터라는 한계(일반적인 정수/실수와 다르게 크기와 정확도등의 제한됨)에 의해 int, double등과 같이 형태를 정의해야만 실체가 생길 수 있는 것이다.

일정한 제한 내에서 같은 연산자나 함수를 가지더라도 다른 형태이므로 또 서술해야 하는 상황을 막기 위해 제네릭(Generic)으로 추상하여 표현하기도 한다.

다시 함수형으로 돌아와서, 함수형은 행동을 형태로 기술해야 하는데 중간에 만약 형태가 바뀐다면??(상태가 있음)

함수형을 지향함에 있어 문제가 생기는 것이다.

따라서 Stateless와 순수함수를 지향하며, 불변자료구조를 사용하고 모나드와 같은 것을 사용해 어쩔수 없는 상태(I/O 같은것)를 감싸 해결을 하려 시도한다.

느긋한 평가(Lazy eval)의 경우 순수함수라서 생길 수 있는 특징이며 커링(Curring, 인자를 하나씩만 받음)등을 이용한다.

모든 인자값을 더해야 하는 함수를 커링화했다고 생각하면 이러합니다.

add(2)(3)(5)(6) // ...

계산을 미루므로 리소스를 절약이 가능하며, 무한을 다루기에도 효과적이다.

함수형과 관련된 글들은 많이 써두었으니 이 이상은 여기에서는 설명하지 않겠다.

https://black7375.tistory.com/62

내 맘대로 프로그램 설계 7. - 함수형 프로그래밍.

내 맘대로 하는 프로그램 설계 시리즈. Chapter1 - 간단한 데이터 처리(4섹션) 2017/12/27 - [프로그래밍/설계] - 내 맘대로 프로그램 설계 1. - 이유와 준비. 2018/01/11 - [프로그래밍/설계] - 내 맘대로 프로

black7375.tistory.com

https://black7375.tistory.com/69

간단한 모나드 설명과 예제

리엑트 네이티브 스터디 때문에 시작한 글이었는데 생각보다 길어져서 분리하게 되었다. 자바스크립트 관련 코드는 해당 스터디쪽 문서에 올릴 예정. 역시 모나드를 이해할때는 Haskell이 가장

black7375.tistory.com

https://black7375.tistory.com/71

자바스크립트와 함수형 프로그래밍.

React Native에서 사용하는 React는 함수형 프로그래밍의 철학을 받아들여 만들어졌습니다. React를 처음 접하는 이들을 위한 문서에서도 함수형 프로그래밍의 특징중 하나라는 불변성을 강조하고 있

black7375.tistory.com

불변 자료구조 예시

https://timbaumann.info/pfds-visualizations/

Purely Functional Queues

timbaumann.info

함수형과 철학에 재밌는 점을 꼽아보자면 함수형에서 형태로 나타나기 위해 자주 사용되는 기법 중에 하나인 재귀가 변증법적이라는 것이다.

설명이 너무 길어질까봐 못하겠지만, 재귀함수와 비슷하지 않은가?

비록 설명은 아니지만 관련성에 대해 간단히 서술한적은 있었다.

관심 있는 사람은 앞서 나온 설명과 비교하며 읽어보자.

https://black7375.tumblr.com/post/175291125910

재귀가 아름다운 이유.

재귀가 아름다운 이유. 결론적으로 말하자면 내재적 정합성과 필연성을 가지기 때문이다. 재귀가 왜 아름다운지를 알기하기 위해서 우선 재귀의 과정을 파악할 필요가 있다. 재귀의 과정. 잘 만

black7375.tumblr.com

논리형

논리형이 재미있는 까닭은 로직과 컨트롤을 분리시켜 놨다는 것이다.

논리형에서 말하는 논리(Fact + Rules)는 철학에서 말하는 논리와 거의 동일하다.

[Prolog - Introduction]

이성론자들이 말하는 사고는 선험적(내재적)이며, 언표(apophansis)로서 표현한다.

간단히 언표는 "말로 나타낸 바"라 할 수 있으며, 문장에서 핵심이 되는 주어와 설명하는 술어로 이루어진다.

주어와 술어가 말이 되게 만들어주는게 바로 논리라 할 수 있다.

술어논리를 기술할 수 있게 만들어진 프롤로그의 코드를 보여주며 말하자면 [인공지능언어 PROLOG, Prolog 논리 프로그래밍 언어]

Fact는 일종의 정언판단이다. (실체와 속성을 의미하며, 정언명령과는 다름)

일반적인 주어-술어 관계라 생각하면 이해가 쉽다.

존은 사람이다.
메리는 사람이다.
존은 와인을 좋아한다.
메리는 와인을 좋아한다.

% Facts
human(john).
human(mary).
likes(john, wine).
likes(mary, wine).

를 기술했다.

Rule은 가언판단(원인과 결과)등을 기술할 수 있다.

사람은 죽는다.
존은 와인을 좋아하는 사람을 좋아한다.

% Rules
likes(john, X):-likes(X,wine).
die(X):-human(X).

룰을 기술함으로서 삼단논법과 같은 추론이 가능해진다.

존은 죽는가? - 참
존은 메리를 좋아하는가? - 참
누가(X)가 죽는가? - 존, 메리

% Query
?-die(john).
?-likes(john, mary).
?-die(X).

고전논리에서는 술어논리라는 개념이 없었기 때문에 추론이 불가능했지만, 수리논리를 주로 연구하던 프레게 덕분에 가능해졌다고 알려져있다.

이러한 면에서 논리형은 상당히 철학과 밀접한 패러다임이라 볼 수 있다.

객체지향 및 대체

바로 설명에 들어가볼까요?

전통적 객체지향

객체지향은 프로그램 패러다임을 나눌때 항상 같이 등장하는 공통된 성질을 가지고 있다.

사이드 이펙트가 적고 단순한 형태라는 가정하에 성질을 기반으로 나뉘어 있다면 구분하기 쉬우며 직관적이다.

직관에서 오는 생산성은 전통적인 OOP가 오랫동안 지배해왔던 이유이기도 하다.

OOPs Vs Procedural Programming

심지어 GTK와 리눅스 커널은 OOP를 지원하지 않는 C언어를 쓰면서도 OOP적인 방법을 지원한다.

성질이 존재하는지, 또 어떻게 인식되는지는 철학에서 다룰수 있는 주제다.

이는 추후 클래스와 프로토타입을 철학과 연결할 때 다시 언급하도록 하자.

여기에서는 어떠한 존재의 완벽한 속성을 알아내고 인식하는 것은 불가능하다고만 알아두면 된다.

데이터주도 설계

난 데이터 주도 설계를 상태변화를 최소화하기 위한 설계라고 생각한다.

상태와 시간에 대해서 조금 더 생각해보자.

시간의 변화를 물리학에서는 다음과 같이 정의하고 있다.

시간 변화(時間變化, time evolution)는 시간의 흐름에 따라 계의 상태가 바뀌는 과정이다.
위키백과(시간 변화)

위 내용을 설명하려면 긴 내용이 필요하므로 생략하고 우리에게 필요한 의미를 뽑아보자.

Stateless하면 시간이 흐르지 않았다는 말이다.
상태변화가 적으면 시간이 적게 흘렀을 가능성이 높다. [시간적 지역성, 미래에서 참조하기 쉬움]
상태변화가 적은 것끼리 모아두면 참조하기 편하다. [공간적 지역성]
상태변화를 순차적으로 일어나게 하면 자연스럽다. [순차적 지역성]

상태를 기준으로 추상화를 하면 성능이 올라갈 수 있다는 말이다.

이는 컴퓨터뿐만 아니라 인간의 뇌 또한 좋아하고 직관적이라 느낀다.

여러가지 주제가 섞인 이 파트, 글의 순서 또한 이를 고려한 방식으로 설계되어 있다는 것을 알 수 있을 것이다.

클래스/프로토타입[차이, 유사성] - 추상화와 패러다임[분류, 설명(절차지향..객체지향)] - 객체지향과 존재

OOP vs DOD [twitter] - DOD는 상태가 줄어들고 비슷한 값끼리 묶여 지역성이 늘어난다.

어?? 아까 상태 변화를 제거하기 위해 노력하던 패러다임이 있었죠?

바로 함수형.

그러나 함수형 자체로는 대규모가 아니면 성능에 한계가 있다고 알려져 있다.

현재로선 함수형이 시도하는 방법은 로직자체의 상태변화를 낮추려는데 의미가 크다.

리스프 머신이나 The Reduceron(HN)같이 함수형에 특화된 아키텍처가 보급된 상황이 아니기 때문이다.

컴퓨터 자체(튜링머신)의 상태와는 다른 기준이라는 것.

반면 데이터 주도 설계는 현재 컴퓨터 설계를 기준으로 상태 변화를 낮추려고 시도한다. [Introduction to Data-Oriented Programming, Data Oriented Design Resources]

아주 간단한 예를 들고 와봤다. [An introduction to Data Oriented Design with Rust]

구조체를 사용하는 예제이지만 클래스나 기타 OOP 구현에서도 충분히 사용할 수 있는 기법이다.

걸리는 시간 차이

구조체 각 속성을 넣어두고 계산하는 방식보다

pub struct Player {
    name: String,
    health: f64,
    location: (f64, f64),
    velocity: (f64, f64),
    acceleration: (f64, f64),
}

pub fn run_oop(players: &mut Vec<Player>) {
    for player in players.iter_mut() {
        player.location = (
            player.location.0 + player.velocity.0,
            player.location.1 + player.velocity.1,
        );
        player.velocity = (
            player.velocity.0 + player.acceleration.0,
            player.velocity.1 + player.acceleration.1,
        );
    }
}

배열이나 백터와 같이 연속적인 자료구조를 만들어놓고 관리하는 방식이 성능이 훨씬 낫다.

pub struct DOPlayers {
    names: Vec<String>,
    health: Vec<f64>,
    locations: Vec<(f64, f64)>,
    velocities: Vec<(f64, f64)>,
    acceleration: Vec<(f64, f64)>,
}

pub fn run_dop(world: &mut DOPlayers) {
    for (pos, (vel, acc)) in world
        .locations
        .iter_mut()
        .zip(world.velocities.iter_mut().zip(world.acceleration.iter()))
    {
        *pos = (pos.0 + vel.0, pos.1 + vel.1);
        *vel = (vel.0 + acc.0, vel.1 + acc.1);
    }
}

개발자에게 직관적인 방식으로 이해할 수 있는 그림을 들고오자면

Data-Oriented vs Object-Oriented Design

위와 같다.

캐싱과 자동 벡터화, 분기예측등 각종 최적화 혜택을 받기에 좋아보인다.

그리고 DOD를 적극적으로 활용하기 위해 나온 패턴이 있는데 ECS(Entity Component System)이라 한다.

전통직인 OOP와는 다소차이가 있지만 유니티에서 DOTS라는 이름으로 도입했으니 관심있는 분은 확인해보길 바란다.

도메인 주도와 AOP

도메인 주도와 AOP에 대해 이야기 앞서 비트겐슈타인의 그림이론과 용도의미론에 대해 설명할 필요가 있다.

그림이론은 그의 전기이론[논리-철학 논고], 용도의미론은 후기이론[철학적 탐구]의 대표적인 개념이다.

비교적 쉽게 설명해 놓은 글이 있다. [비트겐슈타인(2)-전기 사상 : 언어그림이론-모사설, 비트겐슈타인(8)-후기 사상 : 용도의미론(the use theory of meaning)]

우선 이름이나 각종 개념들은 어떻게 생겨나는 것일까?

호랑이, 사자와 같은 대상, 사냥하다나 잠자다와 같은 술어등 모두 "공통된 요소들을 추상하여 합친 관념"이거나, "공통된 요소들을 참조하여 나타난 표현"이라 할 수 있다.

각종 개념들은

호랑이, 사자와 같이 경험적일수도
유니콘과 해태처럼 상상일 수도
철학, 객체지향처럼 파생적일 수도 [임의적인 이름과 정의]

있다.

전기 비트겐슈타인은 기존 철학의 문제가 말할 수 없는 것을 말하려 하기에 문제가 일어난다고 생각했다.

플라톤의 이데아를 떠올려보자.

이데아를 가장 잘 설명하는 것은 동굴의 우화이다.

동굴의 우화

구속되어 있는 사람(우측)의 사람은 그림자만 볼 수 있고, 그림자가 "실체"라 생각한다.

우리가 현실에서 볼 수 있는 것 또한 이데아(실체, 참된 세계)의 그림자 뿐이다.

왜냐하면 우리가 인식할 수 있는 것은 한계가 있기 때문이다.

인간의 오감만으로 세계의 모든것을 관측할 수 있는가?

절대적으로 그렇지 않다.

모사설은 이러한 주장에서 나온다.

우리의 지식/인식은 이데아를 모방하는 것 뿐이며, 진리는 이데아와 일치할때 발생하는 것이라는 것이다.

"언어는 세계의 그림이다"라는 그림이론도 비슷하다.

언어로 세계를 표현하며(그리며), 표현이 맞다면 진리이며, 아니라면 올바른 지식이 아니라는 것이다.

따라서 말할 수 없는 것(표현할 수 없는 것)에 대해서 침묵해야 한다고 생각했다.

올바르지 않기 때문이다.

그림이론에서

언어는 세계를
명제는 사실을 [요소명제-원자사실, 복합명제-복합사실]
이름은 대상을

지칭한다.

앞서 우리는 프롤로그라는 언어로 세계를 표현한 적이 있다.

% Facts
human(john).
human(mary).
likes(john, wine).
likes(mary, wine).

"존은 사람이다"라는 복합사실은
"존"과 "사람"이라는 원자사실의 결합이다. (더 이상 나뉠수 없고 독립적임)
"존"과 "사람"은 존과 사람 각각의 공통된 요소들을 추상한 "대상"을 지칭하는 "이름"이었다.

그러나 위의 세계(그림이론)에는 치명적인 문제들이 존재한다.

우선 존이 사람이라는 요소명제는 증명이 불가능하기 때문이다.

만약 캐스트어웨이의 윌리같은 존재라면..? [톰행크스의 무인도표류기 캐스트어웨이]

반드시 사람이라는 것이 맞다는 필연판단[진리]이 아니라 존이 사람이든 아니든 일단 사람으로 가정하는 실연판단이라는 양상이라는거죠.

사람이 아니더라도 세계의 "판단 자체"에는 영향을 끼치지 않습니다.

판단이 맞다면 가치가 있는 것이고, 아니라면 가치가 없을 뿐이다.

만약 올바른 판단을 할 수 없다면?

전기 비트겐슈타인에 따르면 침묵하는 것이 맞습니다.

이렇게 되면 많은 것을 침묵해야 한다는 결과가 도출됩니다.

두번째. 일대일 대응이 가능한 가이다.

이 글을 쓰게된 자바스크립트는 왜 프로토타입을 선택했을까에서도 "벽돌!!"로 설명했습니다.

상황마다 언어의 의미는 달라졌음을 다시한번 떠올려보자.

초보 제자에게: 벽돌!!
성숙해진 제자에게: 벽돌!!
벽돌이 떨어지는 곳에 있는 제자에게: 벽돌!!

제자는 각 상황에 따라 게임을 하듯이 정답을 맞추어야 했다.

벽돌을 달라.
벽돌을 채우라
벽돌을 피하라

그래서 후기 비트겐슈타인은 이를 언어놀이라 불렀다.

또 다른 예시들[맥락적 사고의 중요성]

그렇다. 텍스트가 같다 하더라도 상황과 맥락에 따라 다르게 해석된다는 것이다.

절차지향 파트의 링크에 제가 요약해놨던 동일률의 설명과 상동한다. (관점에 따라 동일하게 보는게 다름)

전통적인 OOP와 도메인 주도 설계는 그림이론-용도의미론의 관계와 유사하다.

전통적인 OOP에서는 속성관계를 완벽하게 정의하려 했지만, 도메인 주도 설계는 컨텍스트에 따라 정의한다.

도메인 주도 설계에 대한 글은 SK C&C에서 체계적으로 소개하고 있습니다.

도메인 전략 설계를 적용하는 모습을 보려면 다음 블로그도 괜찮습니다. (지식을 가지고 있다고 가정)

우선 도메인은 실세계에서 사건이 발생하는 집합이며 정보와 활동 영역을 규정한다. [용어들 설명, 용어들 설명2]

도메인 분석을 사용하여 마이크로 서비스 모델링

이때 컨텍스트에 따라 도메인이 달라진다.

예를 들어 개발과 배포가 있다면 개발에서 생각하는 서버(실행될 대상)와 배포에서 생각하는 서버(배포를 계획할 대상)가 같을까요?

또한 배포라고 할지라도 대기업급의 스케일링이 필요한 배포와 스타트업의 배포, AI 서비스와 블로그 서비스의 배포가 같을까요?

모두 컨텍스트에 따라 개발할 도메인이 달라지게 되는 겁니다.

각 도메인은 모두 같은 유비쿼터스 언어로 통일하여 사용해야 합니다.

같은 개념을 다른 용어로 사용하거나 다른 개념을 같은 용어로 사용하는 일을 막기 위해서이다.

각 도메인을 설계할 때는 의존성에 따라 레이어를 나누어 설계를 하는게 좋다. [The Clean Architecture, Implementing Domain Driven Design, Domain-Driven Hexagon]

구현을 해서 고전적인 아키텍쳐 표현방식으로 시각화한다면 이런식이 되겠죠.

Domain Driven Design–Structuring your applications, Great Diagram about our DDD NLayered .NET 4.0 Architecture

자, DDD를 러프하게 정리하자면 이렇습니다.

사용/개발자에 따라 도메인과 컨텍스트를 나눈다.
같은 컨텍스트 내에서는 동일한 언어를 사용한다.
도메인을 설계할 때는 의존성에 따라 레이어를 나누어라.

이렇게 DDD를 이용한 설계를 적용하게 되면 다음과 같이 변화하게 되겠죠.

OOP vs DDD [Domain-Driven Design vs. anemic model. How do they differ?]

DDD의 실제 구현에 있어 도움이 될만한 패러다임이 있다.

각 도메인에 따라 구현을 하게 될텐데, 다음과 같이 겹치는 영역이 생겨나게 된다.

AOP 입문자를 위한 개념 이해하기

이때 AOP는 관심사 분리를 하여 공통되는 기능을 모으고 DI(Dependeny Injection)을 통해 사용할 수 있게 만들어줄수 있는 패러다임이자 도구이다.

원글에서 나왔던 Rosch 의 프로토타입 이론은 만들어지는 제품 산출물은 어떠한 형태를 갖추어야 하는가에도 적합한 이론이라고 생각한다. [MVP와 PoC, Prototype, Pilot 차이, Top 5 Biggest Challenges when Building an MVP and how to Avoid Them]

Proof of Concept vs. Prototype vs. MVP: Journey to Product Market Fit

개념증명: 아이디어가 실현 가능성이 있는지 확인
프로토타입: 미완성 버전이나 중요한 기능들이 포함되어 있어야 함
MVP: 최소 실행제품으로 생존하기 위한 최소한의 노력과 완성도가 있어야 함

프로토타입을 제작함에 있어 중요한 기능은 디자이너, 개발자, 재무담당등 다양한 사람들의 관점에서 모두 달라질 수 있다.

많은 사람들이 중요하다고 생각되는 제품의 유사도에 따라 전형적인 제품을 만드는 것이 프로토타입의 요건이라 생각합니다.

Class 8: Semantics & Prototype theory

모두 공유하는 속성이 없을수도 있다
다른 구성원과 공유하는 속성이 많다면 유사도가 높다

그렇지만 제작할 때 모두가 공유하면 좋을만한 컨텍스트가 있다.

서로 생각하는 프로토타입이나 MVP가 다르다면 유사도가 제대로 측정되지 않을 것이기 때문이다.

사용가능하고, 최종적인 형태와 유사하게 만들어져야 한다

사용가능하고 최종적인 형태와 유사해야 한다는 것.

사용 가능하지 않다면 MVP에서 핵심인 "생존가능" 자체가 불가하며, 최종적인 형태와 다르다면 "설계변경" 비용이 클 것이기 때문이다.

객체지향과 존재

지금까지 주제를 확장해 다양한 추상화와 철학적 탐색, 좋은 설계와 철학이란 어떤것인가를 주로 다루었다.

다시 본론으로 돌아올 차례이다. [보편자 실재론의 존재론, 아리스토텔레스의 존재론, 아리스토텔레스의 보편자 이해와 개별주의 실체관]

시작했을 때를 리마인드 해보자.

클래스와 프로토타입의 가장 큰 차이는 인스턴스 이전에 존재하였는가 이다.

비슷한 점은 객체지향으로서 어떠한 존재(무엇)을 설명하기 위해 본질을 찾으려 한다는 점이다.

존재론에서 탐구하려는 것은 어떠한 것이 있다면 무엇이며, 어떻게 존재할 수 있는가이다.

여기 2개의 존재가 있다.

소크라테스는 사람이고 철학자, 나는 사람이고 개발자다.

소크라테스와 나는 개별자[개별적 존재]이며, 사람은 보편자[보편적 존재]라 할 수 있다.

그렇다면 개별자와 보편자는 어떤 관계일까?

우선 각 개별자는 나타났다가 사라지는 존재임이 분명하다.

그러나 보편자는 다소 모호한 점이 있다.

사람은 어떠한 일로 멸종할 수도 있다.

사람이란 보편자는 단지 실재하기 때문에 존재하는 것일까? 아니면 근본적인 성질이라 할 수 있는가?

수라는 보편적인 개념은 단순히 지운다고 사라지는 것일까? 사라지는게 아니라면 절대적으로 존재하는 걸까, 아니면 실재 값들이 있기에 존재하는 것일까?

(보통 존재하지 않는 수라고 오해하는 허수도 $i^2 = -1$ 를 보듯 실재적인 값이 존재함이 명확하다.)

플라톤의 이데아론 아리스토텔레스의 실체론이 갈리는 부분이다.

Plato and Aristotle: How Do They Differ?

플라톤은

보편적 성질은 불변하며 실재함 [이데아]
보편자는 개별자로 나타난적 없지만 존재가능
개별자는 보편성을 일부 결여된채로 존재 [이데아가 아니므로]
개별자는 결여는 되었지만 닮았고, 생성/소멸이 일어남

아리스토텔레스는

개별자란 개체만이 근본적인 실재이며 실체임 [실재는 현존, 실체는 근본이라 이해하면 됩니다]
개체들은 불변이 아니며, 질료와 현상의 결합임 [질료는 대리석이고 형상은 조각모양]
보편자는 유종관계(상하/포함관계)에서 나타나는 표상임 [보편자가 제1 실체라면 개별적 차이성이 없어지며 모순]

라 주장하였다.

Aristotle's theory of universals

이쯤되면 무언가 떠오른게 있는가?

그렇다 클래스(이데아)와 프로토타입(실체론)이다.

한번 비교를 해볼까요?

클래스

클래스 자체의 성질은 불변하고 실재한다.
클래스는 객체로 나타난적이 없어도 존재가능
인스턴스 객체는 값이 존재함으로서 보편성을 일부 잃는다
객체는 결여되었지만 닳았고, 생성/소멸이 일어남

프로토타입

객체만이 근본적인 실재이며 실체임
객체들은 불변이 아니며, 값과 타입의 결합임.
프로토타입은 유종관계에서 나타나는 표상임.

나는 이러한 관점에서 클래스와 프로토타입은 각각 이데아론과 실체론에 가깝다고 생각한다.

플라톤과 아리스토텔레스의 시대가 끝나고 파생된 떡밥으로는

보편자가 실체로 존재하는가, 단지 이름일 뿐인가로 싸우게 된 보편논쟁이 있다. [보편 논쟁, 보편과 특수]

신의 존재와 직결되는 문제라 한참을 싸웠다고..

지금도 관념/실재론등으로 완전한 결론이 났다고 말하기 어려우니 여러분의 선택에 맡기겠다.

어떤 세계관이 마음에 드십니까?

~~피곤해서 빨리 끝~~

의식의 흐름대로 작성해서 그런지 계기의 글과는 완전히 다른 주제의 글이 된 것 같다.

원본 글은 스코프 문제가 가장 흥미로웠는데..

비슷한 이유에서인지 다른 프로토타입 기반 언어들도 self를 쓰면 다이나믹 스코프가 기본인 모양이다.

// io
someValue := "hello"
outerFunc := method(self someValue)
obj := Object clone do (
  someValue ::= "world"
  outerFunc ::= outerFunc
)

outerFunc     // hello
obj outerFunc // world

# Perl
$someValue = "hello";
sub outerFunc {
  return $someValue;
}
sub dynamicScope {
  local $someValue = "world";
  return outerFunc();
}

print outerFunc();    # hello
print dynamicScope(); # world

개인적으로는 Lexical scope가 Dynamic scope보다 이해하기 쉽고, 버그도 적을거라 생각하여 선호한다.

자바스크립트 화살표 함수나 io의 block 등을 생각하면 이제 스코프는 선택문제 아닐까 ㅎㅎ

음..... 쉽게 설명하려 쓸려했더니 괜히 어려운 소리만 늘어놨는지 모르겠다....

이 글을 읽고 프로그래밍 지식이 늘었거나, 철학적 주제를 알게 되었거나 무언가 도움이 되었으면 하는 바램이다.

나중에 시간이 난다면 인식론/존재론을 기반으로 약간 더 보충해보고 싶기도.

2021 출판사 대표들이 뽑은 올해의 책, 소쉬르의 일반언어학 강의도 읽어보고 싶다아~~~~

비교적 최근에 나온 이론 같은 객체지향 철학도 한번쯤 알아보면 좋을것 같구.

Lepton 2.0 정보 및 이후계획

BlaCk_Void — Thu, 1 Jul 2021 00:50:58 +0900

지난 3주간 여러가지 피드백을 받으며 진행했다.

2.0 정보

1. 컨텍스트 메뉴 아이콘

가장 공을 들인 것은 컨텍스트 메뉴의 아이콘들!!

패널에 아이콘들을 꽉 채운것의 연장선상의 작업이었다.

다만 패널과 다르게 컨텍스트 메뉴는 플랫폼마다 생김새가 다르고, 종류가 너무 많아서 애좀 먹었다.

아마 100개는 넘을듯..

맥은 Native, None Native 둘 다 대응했어야 해서 좀 귀찮았다.

맥이 고장나 있는 상태이기 때문에 원래라면 테스트가 불가했겠지만 Docker OSX 덕에 가능했다.

KVM과 Docker OSX 개발자들 감사합니다.

부족한 아이콘들은 Fluent UI System Icons로 때웠다.

고퀄 아이콘들을 MIT 라이센스로 풀다니 고맙다.

근데 마소가 윈도 컨텍스트 메뉴 좀 고쳐주면 좋겠다.

넘 끔직..

2. 일러스트 복원

길잃은 용용이와 친구들 일러스트를 에러표시에 보이도록 복원.

귀여운 일러스트들이 브라우저를 조금 더 친근하게 만들어준다.

3. 윈도우 7 및 테마 호환성

윈도우7에서 다크 테마가 이상하게 적용된다는 이슈가 있었다. #53

보다시피 창 전체에 다크모드가 적용되는게 아니라 탭에만 적용되는 걸 볼 수 있다.

다음과 같은 목표를 가지고 만들어졌다.

시스템 기본: 에어로 글래스 배경 사용
색 테마: 색으로 채움
이미지: 이미지로 채움

꽤나 자연스럽다.

배경이미지가 툴바까지만 적용되는 현상을 발견해서 수정했다.

4. 탭 상태

선택된 고정탭의 닫기버튼

저번에 상당히 신경써서 만들었지만 고정탭의 닫기버튼은 반응이 너무 안좋았다.

사실 호불호 갈릴거라 생각은 했지만 생각보다 심하게 나뻐서 롤백.

새 탭 버튼

컨텍스트 메뉴 다음으로 신경을 쓴 새 탭 버튼.

기존에는 일반 버튼처럼 만들어져 너무나도 거대해서 터치인터페이스 같았다.

따라서 2가지 방향으로 개선을 했는데

오리지널: 탭 모양처럼.
Photon 스타일: 버튼처럼 작게.

새탭 버튼은 말그대로 "새탭"을 생성시키는 역할을 한다.

즉 잠재적인 탭(Potential tab)이라 취급할 수 있으며 탭모양의 연장선 상으로 만들어도 어울린다.

대표적인 예가 바로 파이어폭스 오스트랄리스 버전.

반면 Photon Style은 버튼의 크기를 상단 컨텍스트 라인까지 맞추어 확실히 버튼 느낌을 주도록 했다.

마우스 호버시 닫기버튼 노출

파이어폭스는 탭을 잘 보여주기 위한 3단계가 있다.

공간이 충분할 때: 닫기버튼을 보여줌
첫번째로 끝에 도달했을 때: 탭 크기가 줄어들며 닫기버튼은 선택이 되었을때만 노출
최소 탭 크기까지 줄었을 때: 오버스크롤 효과

닫기버튼을 감출때의 장점은 탭의 타이틀을 조금이라도 더 보여준다는 점이다.

따라서 2~3단계에서 닫기버튼을 감추는 것은 좋은 UX라 생각할 수있다.

그러나 선택을 해야만 닫아야한다는 건 불편하므로,

호버시 닫을 수 있도록 정책을 살짝 변경했다.

5. 인스톨 스크립트

아직 실험적이고, 업데이트 UX도 부족하지만 인스톨 스크립트가 만들어졌다!!

bash -c "$(curl -fsSL https://raw.githubusercontent.com/black7375/Firefox-UI-Fix/master/install.sh)"

Lepton 프로젝트의 전반적인 계획

사실 프로젝트 초반부터 마음속으로 세워두었던 계획이 있었다.

최근 문서화하며 전반적인 틀만 공개해본다.

시장의 파이를 충분히 확보해 성장가능성이 낮아진다면,

제품의 포지션을 변경해가며 수혈해야한다고 생각한다.

프로젝트 커다란 방향이 바뀔 3가지 이정표가 있다.

모두 경입자의 이름을 따서 만들어졌다.

Stage1 - Project Neutrino

첫 단계는 정말 가볍고 상호작용도 적은 중성미자(Neutrino)이다.

목표

전반적인 디자인을 확립하며 Proton에서 생겨난 각종 불만들을 해결하여, 사용자가 브라우저와 상호작용 시 마찰이 없도록 만들어야 한다.

일반적인 브라우저에서 기대하거나 그보다 나은 자연스러운 UI/UX를 구축하는 CSS 세팅의 결과물.

요소

색
- 대비를 주어 인식하기 쉽게
- 전반적인 다크모드, 일부 컴포넌트는 테마와 완전한 연동된 컬러스킴 제공
- 윈도우/GTK 기본 테마 지원
- 윈도우7 호환성
아이콘: 패널, 콘텍스트 메뉴, 글로벌 메뉴등에 세심하고 꼼꼼하게 적용
포인터: 각종 메뉴에 포인터를 올렸을때 상황에 맞도록 표시
간격(패딩)
- 탭, 패널, 메뉴, 팝업등 다양한 컴포넌트들을 지원
- 컴팩트-일반-터치모드에 맞게 조정
탭
- 탭 모양, 구분선, 텍스트 잘림등 일반적인 불만의 해결
- 각종 상호작용에 일관성 있는 대응
홈: 아이콘 크기, 포커싱시 컬러, 검색 시 위치 등
에러 페이지: 일러스트를 복원하여 인간적으로 만들기
스크롤링: 부드러운 스크롤의 값 조정
인스톨러: Bash와 Powershell로 만들어진 인스톨러로 쉬운 설치와 업데이트 지원

Stage2 - Project Muon

두번째는 중성미자는 물론 전자보다 훨씬 질량이 큰 뮤 입자(Muon)에서 따왔으며, 파이어폭스 자체의 기능을 넘어 Lepton 고유의 UI/UX를 만들어가는 과정.

JS를 도입해 동적인 기능들이 들어가며, CSS나 일반 애드온으로는 할 수 없는 UI/UX, 기능들을 구현한다.

목표

일반적인 사용자가 원하는 대부분의 기능들을 커버하며, 파이어폭스 유저라면 꼭 설치하거나 다른 브라우저에서 전환까지 고려할만큼의 킬링 포인트들이 들어간다.

JS가 도입되어도, 성능저하는 거의 없어야 합니다.

설정 UI를 제공한 후에는 TS 및 Noder기반의 완전한 모던 웹 개발 환경을 구축한다.

그 전까지는 사용자가 각각의 기능을 추가/제거하기 쉽도록 맹글링/압축등이 있어서는 안됨.

요소

완전한 테마: CSS만으로는 Shadow Dom의 한계로 완전한 색 커스텀이 불가능 했던 점을 극복
쉬우면서 방대한 UI 커스텀: 사용자가 원하는 UI를 간단하게 선택할 수 있도록 설정 UI를 제작
부드러운 애니메이션: 북마크 애니메이션 복원, 플루언트 효과, 웨일 사운드 웨이브등을 도입
컴포넌트: 페이지액션 복원, 상태표시줄, 사이드바, 수직 탭등의 기타 UI 요소들
제어: 블록 팝업 메뉴, 단축키 조정, 마우스 제스쳐, 기록 트리
설정: TOC 표시로 빠른 전환, Lepton UI 조정, 고급모드
강화/추가: 이미지 보기 및 수정
통합: FirefoxPWA, Translate Web Pages등과 완전한 통합
기타 기능: 절전모드, 스피드 리더, 탭 미리보기, 탭그룹, 탭스택, 모바일 탭등

Stage3 - Project Tau

마지막 세번째는 Muon보다도 10배는 무거운 Tau로서 더 이상 가벼운 테마 레이어로 보기 힘든 파워유저들이나 특수한 유저들을 위한 기능들이 추가된다.

목표

Stage2를 거쳐 일반적인 사용자의 요구는 거의 다 맞추었다고 할 수 있다.

이제는 각종 파워유저들을 생각하거나 고급 기능을 구현하는데 초점을 맞춘다.

요소

각종 전용 프로그램: Epub 뷰어, 강력한 다운로드 관리자, 내장 비디오 플레이어 대체
터치모드: 터치에 적합하게 이벤트 전달, 커서 변형, 각종 UI 수정
Vim 키맵 및 키보드 브라우징
미니버퍼: Fuzzy 검색을 하여 Heading, 탭, 기록, 명령어들을 빠르게 찾고 전환/실행
타일링: 타일링으로 같은 페이지, 연결된 탭, 다른 탭 등을 쉽게 탐색
스마트 북마크 마법사: 북마크 쿼리를 쉽게 만들 수 있는 가이드
매크로 지원: 각종 반복작업을 간단하게
커스텀 설정 코드 지원: userChorme.js란 파일이름으로 사용자 커스텀 코드를 지원하려고 생각중이다.

러스트 찍먹 후 느낀점?

BlaCk_Void — Sun, 13 Jun 2021 00:36:43 +0900

면책사항) 튜토리얼을 끝낸 후 첫인상일 뿐이므로, 정확하지 않을수도 있다.

귀여운 >.< Ferris

좋았던 점.

1. 툴체인!!

누구도 부정할 수 없다.

Cargo, rustup, Rustfmt, Clippy, Rust Analyzer등의 공식툴!!

빌드 툴부터 생각해보자.

네이티브 계열에서 생각나는건 Make!!

어느정도 규모가 있는 프로젝트는 크로스 플랫폼 대응이나 각종 설정을 적용하기 위해 Meta Make 시스템을 사용하는게 일반적이다.

대표적인게 GNU Autotools(Autoconf, Automake, Libtools). [Introduction to GNU Autotools, The Basics of Autotools]

M4와 Make 두개의 작은 언어를 더 알아야만 한다..ㅋㅋㅋ

각 파일을 열어볼 생각만 해도 어질어질하다

나중에 CMake가 나왔지만 역시 그리 쉽지만은 않다ㅠㅠ

이외에도 GN, Meson과 같은 빌드 툴이 나와있다.

이건 단순히 빌드툴에 한정지었을 때 뿐만이다.

라이브러리 버전이 안맞거나 헤더가 없다고 빌드가 안된적이 많지 않던가?

이래서 필요한게 vcpkg나 conan같은 패키지 매니저.

이외에도 모노레포나 조건부 컴파일/ 선택적 종속성은 물론 테스트, 벤치마크, 문서화 등이 필요한데, Cargo는 모두 지원한다.

게다가 그냥 지원하는게 아니라 소스코드 파일 안에서 테스트, 문서화 등을 모조리 지원해버린다.

그야 말로 만능 툴이다.

러스트 자체의 버전을 관리하는 rustup, 포매팅의 Rustfmt, 린트의 clippy, IDE 지원용인 Analyzer 모두 공식적으로 지원하기 때문에 코드 자체에만 집중할 수 있는 환경을 만들어준다.

기존의 개발환경이 얼마나 별로였는지 역체감이 너무 심하다ㅠㅠㅠ

엉망인 파이썬, 난잡한 자바스크립트의 툴들과 비교해도 확실한 우위라 할 수 있다.

2. 메모리 안전

메모리 관련 오류는 성능에 앞서 보안에 치명적이다. [Microsoft: 70 percent of all security bugs are memory safety issues, Chrome: 70% of all security bugs are memory safety issues]

다행히 GC(Garbage Collection) 언어는 일반적으로 메모리 안전하다.

그러나 GC를 위한 런타임이 필요하거나 Stop the world가 발생하는 등 성능 오버헤드가 존재하기 때문에 성능을 중시하면 메모리를 직접 할당/해제하는 언어들을 사용할 수 밖에 없다.

물론 Valgrind로 메모리 누수를 잡거나, Go의 defer처럼 실수를 줄여주기 위한 문법이 있을수 있다.

Swift처럼 ARC(Automatic Reference Counting)로 메모리를 관리하기도 하지만 메모리 안전을 보장하지 않는다.

게다가 ARC의 경우 할당/해제 시 참조 카운터 또한 증감하기 때문에 오버헤드가 존재한다.

C/C++처럼 Zero Cost를 지향하는 경우는 사용하기 힘들다는 말이다.

D언어가 메모리 안전한 스펙을 어느정도 정해 놓았기 때문에 어느정도 메모리 안전함을 보장한다. [DIP1000 Scoped Pointers]

그러나 D언어는 기본적으로 GC를 사용하는 언어라 Zero overhead를 달성했다기에 애매한 점이 있는데다 No GC일때 러스트 수준으로 잡아주지는 않는다.

러스트는 소유권과 차용 시스템으로 Zero overhead 메모리 안전, 데이터 경합이 없는 동시성을 달성한다. [Fearless Concurrency with Rust]

Encore나 Pony가 러스트와 비슷하게 메모리 안전을 보장한다. [A Comparison of the Capability Systems of Encore, Pony and Rust]

권한을 사용하는 Pony의 아이디어가 꽤 재미있다. [Reference Capabilites in Pony for everybody, Reference Capabilities, Consume and Recover in Pony]

마치 리눅스 chmod 파일 권한을 보는 느낌

RC의 경우, 요즘 재밌는 기술이 몇가지 나오는 것 같다.

Vale의 레퍼런스 카운팅을 대체하기 위한 세대 참조가 특이하다. 러스트에는 genref 라이브러리가 있다.

Koka도 레퍼런스 카운팅의 성능을 향상하기 위해 Perceus라고 적극적인 재사용을 한다.

Nim은 소유참조라는것을 사용한다.

3. 성능

C++은 잘쓰면 빠르다.

그러나 함정이 많다.

그 중 많은 것은 Class 기반의 OOP 때문이며, 각 명령어가 5~8개의 어셈블리로 변환되던 C와 다르게 생성/소멸자가 있어 예상이 어렵고 클래스의 가상함수 등은 인라인을 어렵게 만들기도 한다.

때문에 온갖 복잡한 규칙들이 생겨났다.

생성자의 초기화 때는 멤버 초기화 리스트를 사용해야 함 [PVS Studio]
복사 생성자를 정의하여 RVO, NRVO가 가능하도록 해야 함 [Copy elision]
EBO를 사용해 빈 클래스의 크기를 1바이트만 사용하게 만들 수 있음
CRTP를 사용해 정적 다형성을 달성할 수 있다.
가상 메소드의 경우, 컴파일 타임에 정보를 알게 하면 인라인이 가능하며, final 키워드를 사용할 수 있다면 쓰는게 좋다. [Can Virtual Functions be Inlined in C++?, The Performance Benefits of Final Classes]

러스트는 보다 간단하게 최적화가 가능하다.

RVO를 지원하는걸로 알려져 있으며(Returning pointers), EBO도 달성하기가 보다 수월하다 (Zero sized types).
상속, virtual이 없는 러스트의 특성상 성능을 예측하기 쉽다. [Abstraction without overhead: traits in Rust]
Try-Catch 또한 익셉션이 발생할때 느려지기로 유명한데 Result 타입을 사용하면 문제가 없을 뿐만 아니라 같은 컨텍스트에서 처리할 수 있다는 장점이 있다. [C++ 이야기 서른두번째: 예외가 성능에 미치는 영향, CppCon 2017: Dave Watson “C++ Exceptions and Stack Unwinding”]
극도로 최적화된 반복자를 사용하여 일반 반복문보다 빠르기도 하다.
constexpr 대신 const fn, const generics를 사용
rvalue, std::move는 알 필요가 없다!! [C++ Move Semantics Considered Harmful (Rust is better)]

라이브러리 면에서도 흥미로운데, C++의 STL은 논쟁의 대상이었다.

특히 게임관련 계통은 디버깅 모드의 성능, 메모리 할당 관련 때문에 바퀴의 재발명을 자주하기로 유명했다.

러스트 컬렉션의 경우, pcwalton의 댓글에 따르면 EASTL(문서)을 참고하여 allocator_api를 만들었다고 알려져 있다.

정규식 엔진이 훌륭하여 최악의 경우 선형 시간이며, PCRE2 JIT과 비교해도 느리지 않다. [A comparison of regex engines]

신세대 언어답게 많은 부분이 신중하게 결정되었다.

그럼 보다 전통적인 C와 비교하면 어떨까?

다음 문서에서 잘 설명해주고 있다.

Speed of Rust vs C

앞서 설명한 데이터 경합 없는 동시성으로 인해 과감한 쓰레드 사용도 가능하여 고성능을 만들기 좋다.

최근에 또 떠오르는 Zig와 비교한다면

4. 간결함

모든 블럭은 일종의 표현문이라 값을 반환할 수 있고, 블럭의 마지막에 세미콜론을 넣지 않으면 return으로 처리할 수 있다.

처음에 return을 쓰지 않는 방식에 거부감을 느꼈지만 계속 보다보니 뇌이징이 되서 좋아보인다..

이러한 문법은 처음에 Rust를 구현할 때 썼던 OCaml에서 자주보이던 구문들.

let big_n = if n < 10 && n > -10 {
    println!(", and is a small number, increase ten-fold");
    10 * n
} else {
    println!(", and is a big number, reduce by two");
    n / 2
};

구조체와 Enum의 유닛, 튜플, 레코드 값 방식은 단순, 독특, 유용하면서도 강력하다. ~~역시 OCaml 만세~~

enum Message {
    Quit,                    // 유닛
    Write(String),           // 튜플
    Move { x: i32, y: i32 }, // 레코드
}

struct QuitMessage;          // 유닛 구조체
struct WriteMessage(String); // 튜플 구조체
struct MoveMessage {         // 레코드 구조체
    x: i32,
    y: i32,
}

흔히 객체지향에서 말하는 정적, 일반 메소드 기능은 &self 파라미터가 들어가느냐로 쉽게 구분해놨다.

impl MoveMessage {
    // 연관함수
    fn linear(size: i32) -> MoveMessage {
        MoveMessage { x: size, y: size }
    }

    // 메소드
    fn area(&self) -> i32 {
        self.x * self.y
    }
}

패턴매칭은 심플하면서도 스위치문 따위와는 비교도 안되게 강력하다.

let x = 1;

match x {
    1       => println!("one"),
    2 | 3   => println!("two or three"),
    4 ... 6 => println!("four to six"),
    _       => println!("anything"),
}

구조체나 Enum 까지도 모두 커버가 가능하다.

let msg = Message::Move(0, 50);

match msg {
    Message::Quit => {
        println!("The Quit variant has no data to destructure.")
    },
    Message::Write(text) => println!("Text message: {}", text),
    Message::Move { x: 0, y } => {
        println!(
            "Move in the y direction {}",
            y
        );
    }
    Message::Move { x, y } => {
        println!(
            "Move in the x direction {} and in the y direction {}",
            x,
            y
        );
    }
}

if-let과 while-let은 강력한 패턴매칭을 조건문에서도 쓸수 있게 만들었다.

이후에 나올 let-else, let-chains도 기대해도 좋겠다.

let number = Some(7);
let letter: Option<i32> = None;
let emoticon: Option<i32> = None;
let i_like_letters = false;

if let Some(i) = number {
    println!("Matched {:?}!", i);
}

if let Some(i) = letter {
    println!("Matched {:?}!", i);
} else {
    println!("Didn't match a number. Let's go with a letter!");
};

if let Some(i) = emoticon {
    println!("Matched {:?}!", i);
} else if i_like_letters {
    println!("Didn't match a number. Let's go with a letter!");
} else {
    println!("I don't like letters. Let's go with an emoticon :)!");
}

파이썬에서 쓰던것과 유사한 범위 구문도 가능하며, 슬라이스 개념은 재밌다.

let arr = [0, 1, 2, 3, 4];
assert_eq!(arr[ ..  ], [0, 1, 2, 3, 4]);
assert_eq!(arr[ .. 3], [0, 1, 2      ]);
assert_eq!(arr[ ..=3], [0, 1, 2, 3   ]);
assert_eq!(arr[1..  ], [   1, 2, 3, 4]);
assert_eq!(arr[1.. 3], [   1, 2      ]); // This is a `Range`
assert_eq!(arr[1..=3], [   1, 2, 3   ]);

러스트 1.58에서는 fstring도 들어갔다고 한다!!

let x = "world";
println!("Hello {x}!")

let items = vec![10, 20, 30];
println!("{items:?}")

C와 비교해서 편한 기능은 Deref라 불리는 자동 역참조 기능이다.

구조체에서 메서드도 (*object).method()를 object->method()라고 썼던 것과 달리 Deref가 자동으로 참조해준다.

fn hello(name: &str) {
    println!("Hello, {}!", name);
}

fn main() {
    let m = MyBox::new(String::from("Rust"));

    // Deref가 없을 때
    hello(&(*m)[..]);
    
    // Deref가 있을 때
    hello(&m);
}

5. 매크로

매크로 한정 리스프가 더 쉬워보이지만, 전위식이라는 점과 괄호가 무조건 있어야 하는 언어 특성이 크게 작동한다고 생각한다.

Evolution of macros

러스트의 매크로는 일반 문법과 똑같고(Syntactic) 확장 시 실수로 식별자가 캡처되지 않도록 보장한다(Hygenic).

문제는 만드는게 너무 어렵다...ㅠㅠㅠ [Rust 로 복잡한 매크로를 작성하기: 역폴란드 표기법]

Hygienic macro에 대한 글들

6. 기타

chalk라는 라이브러리가 특이했는데, 러스트의 trait 시스템에 프롤로그의 논리 솔버를 도입한 것이다.

rust analyzer가 사용하는 걸로 알고 있다.

아쉬웠던 점.

아쉬운점의 대부분은 함수형 / 타입관련 지원이다.

1. 함수형

꼬리재귀

관련 RFC:

하스켈과 같은 함수형의 특징 중 하나는 Lazy하다는 것이다.

Lazy 함은 일반적으로 느리지만 다루어야할 리소스 양이 많거나 무한을 다루어야 할 때 효과적이다.

std::sync::Lazy처럼 RFC가 제안되어 있다.

(비슷한 느낌으로 Immutable 자료구조 또한 표준으로 있었으면.. ㅎㅎ)

HVM같은 경우, Lazy clone 프리미티브를 이용해 공짜에 가깝게 복제하고, 람다 함수의 계산을 공유하여 성능 면에서 이점이 존재한다.

커링(Currying)

2. 타입

고차타입(Higher Kinded Types)

관련 RFC: Higher kinded polymorphism #324

고차타입은 컨테이너 유형등을 다룰때 유용하다.

다음 글들을 보면 컨셉에 대해 이해할 수 있을 것이다.

선형타입(Linear type)

관련 RFC: Add linear type facility #814

러스트의 차용 시스템은 훌륭하지만 완벽하지는 않다. [The Pain Of Real Linear Types in Rust]

일반적으로 사용할 수 있는 횟수에 따라 4가지로 나뉘는데,

여러번 사용해도 됨: 기본
한번 이상 쓸 수 없음: Affine 타입
한번은 사용해야 함: Relevant 타입
정확히 한번만 사용해야 함: Linear 타입

러스트는 사용하면 moving이 일어나기 때문에 기본적으로 Affine 타입이며, 사용하지 않았을 때 컴파일러가 경고해주는게 Relevant 타입이라 할 수 있다.

Linear(선형) 타입은 한번만 실행하기 때문에 file 사용 후 close가 적절히 실행되지 않는 것을 보완할 수 있다.

또한 최대 한번만 값을 사용하도록 강제하기 때문에 free가 여러번 일어나 메모리 버그가 일어나는 일을 방지하고, 인라인 관련 최적화를 수행할 수도 있다.[Linear types make performance more predictable]

Idris 2의 Quantitative Type Theory (QTT)는 컴파일 타임에만 존재하는 변수에 대한 타입을 제공하기도 한다.

가변 제네릭

관련 RFC:

숫자에서 0~100까지만 사용할 수 있다면 어떨까?

타입을 제약할 수 있다면 보다 안전한 프로그램을 만들 수 있을 것이다.

자동완성도 좋아진다!!

종속 타입(Dependent type)은 일반적으로 런타임에 검증하며, 정제 타입은 컴파일 타임에 검증한다.

타입스크립트의 literal type도 이 범위라 생각할 수 있을 것이다.

Enum 강화

관련 RFC:

타입스크립트를 한 사람은 알겠지만, Enum은 type으로 표현할 수도 있다.

GADT도 있었으면..

3. 컴파일

컴파일 타임 혹은 빌드타임에 할 수 있는 것들이 몇가지 있으면 한다.

제네레이터와 코루틴

코틀린의 코루틴은 정말 잘 만들어져 있다.

Rust의 async 설계가 잘되어 있다고는 하나 명시적인 await를 해줘야하는 지연된 값으로 좀 다른 것 같다.

Stackless 코루틴의 경우 컴파일러가 가능한 영역.

계약에 의한 설계와 증명관련 기능

관련 RFC:

Design By Contract #1077

일부는 어쩌면 종속과 정제타입의 연장선상일 수도 있지만..

D언어의 계약에 의한 프로그래밍(Design By Contract)은 멋진 기능이다.

in source test와 함께 쓰면 편할 듯.

ATS(Applied Type System) 언어의 예처럼 증명을 구현과 통합하게 만들 수 있다.

TDD의 단점은 엣지 케이스를 빠트릴 수 있기 때문이다.

물론 일반적으로 증명을 사용해야 할 경우는 많지 않겠지만, 코어단에서는 유용할 수있다.

증명용 언어에서는 Agda나 F*가 눈에 띄는 것 같다.

컴파일 타임 평가

Zig의 comptime은 꽤 멋진기능이며, 러스트의 const는 아직 C++의 constexpr나 D의 static if등은 간단하게 컴파일 타임에 평가를 진행한다.

러스트에도 라이브러리가 있는 것 같긴 하다.

아마 리플렉션이 필요할지도.

4. 편의성을 위한 다양한 기능들

측정 단위

F#의 단위에 대한 구문은 깔끔하다. [ F# Basic Units of Measure]

개인적으로 GUI를 다룰려면 이 기능이 꼭 있어야 한다고 생각

let dpiValue = 150.0<dpi>
let inchValue = 8.0<inch>
let pxValue = 1200.0<px>

다이나믹 스코프

다이나믹 스코프는 Dependency injection을 매우 쉽게 만들어준다.

스킴의 구현이 좋은편이며, rust에도 fluid-let이라는 라이브러리가 있는 것 같다.

Effect 다루기

대수적 효과나 잘 설계된 이펙트 핸들러를 보고 싶다.

Koka, 스칼라의 ZIO Direct, Ocaml의 EIO가 잘 만들어진 예시들.

5. 몇가지 구문설탕

구문 설탕이므로 있었으면 편하지 않을까~ 정도로만 봐주면 좋겠다.

기본 자료구조 매크로

경험상 풍부한 기본 자료구조는 생산성에 커다란 도움이 된다.

velcro정도의 문법이 적당해 보인다.

컴프리핸션(comprehension)은 보통 파이썬 또는 하스켈 버전 중 하나일텐데 보통은 파이썬 버전을 좋아하지 않을까.

cute나 mapcomp 정도면 좋아 보인다.

삼항연산자

일반적인 알골 기반 언어를 자주 쓴 사람이라면 그리워할 그 것.

이상한 삼항연산자가 있던 파이썬 쓸 때 너무 아쉬웠었다.

구조체 기본 필드

관련 RFC:

struct에 기본 값이 있다면 어떨까?

위의 lazy 제안과 맞물려 좋은 시너지가 될 것이다.

트레잇 한번에 구현

6. REPL과 핫 리로드

러스트의 풍부한 툴 인프라 중 유일한 불만은 REPL과 핫 리로드 기능이다.

스크립트 언어 계열을 써봤다면 REPL을, 웹 개발이나 Flutter관련 개발을 해봤다면 핫 리로드가 익숙할 텐데 저 둘의 생산성 증가는 상당하다.

REPL의 경우 프로토타입이나 간단한 함수나 로직을 테스트하기 좋고, 핫 리로드는 실제 어플리케이션의 상태가 유지되며 실시간으로 반영되기 때문에 불필요한 컴파일 시간과 테스트에 걸리는 시간을 줄일 수 있다.

다행히 공식 툴은 아니지만 구글에서 evcxr라는 REPL을 개발 중이라 한다.

그러나 핫 리로드는 관련글들이 있지만 아직...

C++의 경우 마이크로소프트는 비주얼 스튜디오 2022에서!! 선보였다 [Write and debug running code with Hot Reload in Visual Studio (C#, Visual Basic, C++), Hot Reload for C++]

마소가 요즘 밀어주려고 하던데 비주얼 스튜디오에서 지원해주면서 어떻게 안될까..?

분류 짤

몇가지 재밌는 분류짤을 올리며 마치도록 하겠다.

Models of Generics and Metaprogramming: Go, Rust, Swift, D and More

Google Docs

Rust Memory Container Cheat-sheet

Lepton - 얼마나 파이어폭스 UX를 개선할 수 있을까?

BlaCk_Void — Tue, 25 May 2021 09:15:06 +0900

앞으로 Lepton이라 불릴 파이어폭스의 UX를 개선하는 플젝을 진행 중이다.

https://github.com/black7375/Firefox-UI-Fix

black7375/Firefox-UI-Fix

I respect proton UI and aim to fix it. Contribute to black7375/Firefox-UI-Fix development by creating an account on GitHub.

github.com

0. 계기

이 작업을 하게된 계기는 브라우저 업뎃(디벨로퍼 버전을 사용 중) 후 갑자기 엄청난 변화에 깜짝 놀랐기 때문이다.

대략 이렇게?

Photon 디자인

Proton 디자인

확실히 훨씬 이뻐졌다

정말 깔끔하고, 군더더기가 적다.

사용하는데 불편한 점이 없다면 그냥 쓰려고 했다.

흠.. 그런데 심하게 넓직넓직했다.

메뉴를 누른 후 찾아 가는데 한세월 걸리드란;;

패딩만 아니었다면 그럭저럭 만족하고 썼을텐데 감춰뒀던 커스텀 욕망이 스물스물 올라왔다.

ZSH 설정과 Doom같은 배포판 없이 직접 만들어 쓰는 이맥스 사용자라는 점만 고려해도.. (이하 생략)

밀도(좁게, 보통, 터치)를 좁게 설정하려고 해도 숨겨놔서

about:config에서 browser.compactmode.show를 활성화 시켜야지만 접근이 가능하다.

물론 공식적으로 비지원으로 이번에 바뀌었기 때문에 완성도가 떨어지는 점도 단점.

예를 들어 탭 공간은 줄어들어도 패널공간은 줄어들지가 않는다..

놀랍게도 패널은 밀도가 달라져도 크기가 항상 같다는 말.

밀도에 따른 패널크기 차이. (없다)

크기가 커지면 클릭하기 쉬워지니 문제없지 않으냐고 반문할 수도 있다.

그러나 성능과 UX 트릭에서 소개했던 피츠의 법칙에서 목표지점으로 빠르게 이동하는데 시간의 기본적인 비율은 $\frac{2 \times D}{W}$ 이다.

D가 거리, W는 크기(너비)

1. 기존 디자인들과 포크들

파이어폭스는 유독 디자인 변화가 심한 편이다.

그래서인지 UI 업데이트마다 사용자의 반발로 아류들이 생기고는 한다.

디자인들에서 중요한 변화라 생각하는 것들은 볼드체를 칠해봤다.

1.1 초기

넷스케이프의 유지를 이어 불사조가 되어 돌아온 Phoenix가 있다. [Firefox early version history]

v0.1

완전 초기 버전. 주황색의 버튼들이 인상깊다.

v1~3

버전 1부터 3까지의 UI이다.

인터넷 익스플로러와 비슷한 느낌적인 느낌.

SeaMonkey란 포크가 가장 비스무레하다.

1.2 Classic (v4, 2006.10)

4에서 도입된 UI로 가장 장수했다. [Firefox/Projects/3.7 and 4.0 Theme and UI Revamp/Direction and Feedback, Firefox/4.0 Windows Theme Mockups]

Classic이라 칭하면 보통 이걸 말한다.

버튼 모양과 컬러

전반적으로 깔끔하며 아직도 좋아하는 완성도 있는 디자인

상징과 같은 좌 상단의 주황 메뉴 버튼
차분해진 톤
Win7의 에어로 글래스 대응
Stop / Reload / Go를 한개의 버튼으로
상단으로 이동한 탭

단점으로는

당시에 익숙하지 않은 인터페이스 정도?

Pale Moon이란 브라우저가 잘 간직하고 있다.

Palemoon 메뉴, 두터운 상태표시줄도 간직하고 있다

드디어 Stop / Reload / Go를 한개로 합쳐버리는 등의 함축적 변화가 시작되었다.

게다가 쭉 나열만 되어있던 아이콘과 툴바를 상단패널에 정리한 것은 상당히 영리한 행동이었다.

상단 패널 버튼은 파이어폭스의 아이덴티디 역할까지 했으니, 브랜딩에서도 좋았다.

1.3 Australis (v29, 2014.04)

29 버전에 도입되었다. [Firefox and Flux: A New, Beautiful Browser is Coming, Restore the classic Firefox theme in Firefox 29]

드래그앤 드롭 커스터마이징
커브탭
애니메이션

Australis

메뉴 커스텀 기능 - 가장 고무적인 변화라고 생각한다.

크롬 탭 모양의 영향을

단점은

태블릿용처럼 생긴 패널 UI: 써보면 찾기가 힘들다.
상태표시줄 제거: 그래도 선택사항으로 남겨두는게 좋지 않았을까?

탭모양은 호불호라 생각하지만, 터치 버튼 같은 패널 UI 구성은 커다란 반발을 불렀던 걸로 기억한다.

일단..난 별로였다.

특히 커다란 아이콘 패널은 다시는 PC에서 만나고 싶지 않은 경험.

그래도 소소한 애니메이션은 좋았던걸로..

Basilisk가 가장 비슷하다.

Basilisk

보다시피 드래그엔드롭 커스텀에 신경을 써놨음을 알 수 있다.

현재까지도 이어지는 중요한 변화.

1.4 Photon (v57, 2017)

포톤은 Australis와 다르게 상당한 환영을 받았다.

리스트 형태 패널
애니메이션
페이지 액션
탭모양

터치용같이 생긴 패널이 사라지고, 본연의 모습(?)으로 돌아왔기 때문이리라.

하지만, 내가 주목하는 부분은 바로 애니메이션이다. [https://dolske.wordpress.com/]

포톤에서 애니메이션에 기울인 노력은 놀랍다.

애니메이션 이미지가 끊긴다면 한번 눌러서 원본 이미지를 재생해보자.

북마크와 포켓, 라이브러리

스포티파이의 하트 버튼 생각이 나기도 한다. [These Weeks in Firefox: Issue 21]

북마크 별과 스포티파이 애니메이션

다운로드

오버플로우 메뉴

새로고침 / 취소

탭로딩 인디케이터

위의 새로고침에 있는 로딩과 비교해보라

로딩 인디케이터 동기화 (출시에 가까워졌을때 동기화되도록 바뀜)

다른 브라우저와 비교해보자.

Photon

Chrome, Edge, Basilisk, Whale

전체화면

전체화면 애니메이션

개인적으로 파이어폭스의 전체화면 애니메이션을 참 좋아한다.

명쾌하고도 부드럽다.

크롬, 엣지, 페일문, 바실리스크

애니메이션 파트가 끝났고, 페이지 액션을 소개할 차례.

주소창을 깔끔하게 유지 및 커스텀 할 수 있어서 좋았다.

마지막으로 직각직각해진 탭바.

갠취라 좋았음.

파란색 불빛은 타이틀이 바뀌었을때 알림 기능

Waterfox는 Australis 탭모양에 Photon의 패널 모양을 가지고 있다.

Waterfox

단점은

더 이상 확장기능으로 XUL 커스텀을 지원하지 않음. (Tab Mix Plus, Tab Scope 등 유수의 애드온이 쓸려나갔다. ㅠㅠㅠㅠ)

전반적으로 만족한 업데이트였다.

1.5 Proton (v89, 2021.06)

지금까지 봐왔던대로이다.

아까는 안보여줬던 화이트 테마

깔끔히 정리된 메뉴(중복이 많이 사라짐)
엣지를 떠올릴만큼 이뻐지는 아이콘
마음에 드는 일부 애니메이션
스켈레톤 스크린
훠어ㅓ얼씬 쎄련된 색
적당히 만족스러운 라운딩
꼼꼼한 구현

전반적 컨셉 자체는 공감하고, 각종 메뉴들의 꼼꼼한 구현까지 마음에 들었다.

컨텍스트 메뉴는 몰론, 모달창과 툴팁까지 꼼꼼하게

그러나, 단점도 너무 많으니 ㅋㅋ

간격들이 장난아니라 우주도 아니고 웬 급팽창인지?
메뉴의 아이콘들은 어디?
탭이 아니라 버튼 같드아..
헷갈리게 만드는 탭 인디케이터들
주소창의 페이지 액션 버튼(3점)이 사라짐 + 스크린샷은 일반 툴바로 옮겨버림
북마크와 라이브러리 애니메이션 삭제
새 탭 메뉴의 아이콘이 넘넘 작음

아이콘과 애니메이션의 차이, 탭 인디케이터는 지금까지 나온 스크린샷으로 확인할 수 없으니 약간 더 비교해보자.

먼저 아이콘. 동기화된 부가기능에서 튀어나온 부분 하나가 사라지고, 탭 아이콘이 비직관적으로 바뀌어서 아쉽긴하나 전반적인 스타일은 좋다.

아직 업데이트가 덜 된 부분도 보이지만, 나중에는 되겠지.

얇상해진게 엣지 같다

그리고 달라진 재로딩과 다운로드 애니메이션

재로딩 애니메이션은 깔끔해서 이보다 좋은게 나올수 있을까 싶을 정도이다.

반면 다운로드는 호불호가 갈릴 듯. 처음 다운로드 시작시 눈에 띄는 효과가 적다.

아직 윈도우에만 도입된 스켈레톤 스크린도 좋다.

파비콘 정보가 없을 때의 기본 아이콘도 정말 이쁘다고 생각한다. (사진출처: 레딧)

파비콘 정보가 없을때

예전에는 그냥 비어있다가 사이트의 화면이 노출되었다.

참고로

파이어폭스의 로딩 애니메이션은 필름 스트립 기법을 사용하기 때문에 svg 파일이 있다.

예를 들어 다음 링크에 들어가서 확인 가능: resource:///chrome/browser/skin/classic/browser/reload-to-stop.svg

Photon의 로딩 애니메이션

Proton의 로딩 애니메이션

기타 단점들은 이따 테마를 소개하며 비교용으로 신나게 까일테니 좀 기다리도록 하자.

2. Lepton (Proton Fix) 소개

프로톤 디자인의 장점을 유지하면서 실수라 생각하는 부분들을 고치고 개선해보기로 했다.

주요 수정사항은 다음과 같다.

간격
아이콘
탭모양
탭 상태
새 탭 컨텐츠

주소창의 페이지 액션 버튼과 북마크/라이브러리 애니메이션은 JS가 필요한 부분이 있고,

설정이 복잡한 편이라서 아직 개선 대상에 포함되지 않았다.

나중에 고급 사용자를 타겟으로 하거나 인스톨 스크립트가 만들어진 다음에야 들어갈 예정.

아참, 이름이 Lepton(경입자)인 이유는 Proton(양성자)의 얇은 레이어라서 + -ton과의 네이밍 맞추기 말장난.

간격

우선 가장 마음에 안들었던 간격들을 합리적인 수준으로 조정했다.

탭

보여주는 탭 갯수가 더 많다

높이도 조정됨

패널

컨텍스트 메뉴

아이콘

각종 아이콘을 패널에 싹 집어넣고, 밀도모드별 대응까지 끝냈다.

꽉꽉 채워 넣었다

꽉꽉 채운게 마음에 안든다면 Photon Style을 사용할 수 있다.

듬성듬성 넣은 아이콘

탭모양

이 어이없는 버튼식 탭모양을

툴바에 연결해 보편적이고 상식적인 모양을 만들었다.

그냥 높이를 조정하면 끝인 별거 없는 모양 같아 보이지만 생각보다 구현이 어려웠다.

선택된 탭을 강조하기 위한 그림자, 거의 포기할뻔 했던 하단의 라운딩 덕에 쉽게 눈에 띄면서도 자연스러운 모양이 가능했다.

실제로 아주 살짝 들어간 하단 라운딩이 없으면 딱딱한 느낌이 든다.

라운딩이 없는 탭

전후 비교

만약 Photon 같은 효과를 사용하고 싶다면 역시 Photon Style을 사용하면 된다.

탭 상태

일단 아주 간단한 인터페이스를 비교 해보도록 하자.

프로톤에서 탭구분자가 없는게 아쉽다.

그러나 탭 상태는 고려할 요인이 매우 많으며 복잡하므로 한가지 기준만으로 제단하기는 어렵다.

예를 들어

선택
호버 (마우스 올림)
텍스트 잘림 (오버플로우)
탭 오버플로우 (탭 스크롤 모드)
소리
PIP (Picture In Picture)
고정
컨테이너
이미지(파비콘) 없음
제목 바뀜
로딩 중
깨짐
테마
밀도
기타 등등

36px~240px의 좁은 공간에서 이렇게나 많은 조건들을 따져가며 상호작용이 되고,

모두 적절한 방식으로 표현이 되어야만 한다.

이제부터 보여주는 다양한 상호작용들을 보면 머리가 어질어질 해질 예정이다.

실제 상황입니다. 정신 꽉 붙잡읍시다.

1. 선택된 탭과 컨테이너

Photon, Proton 둘 다 넓직한 막대 때문에 약간씩 헷갈릴 수 있다.

다행히 Photon은 탭과 툴바가 연결되어서 구분이 가능하나 Proton은 혼동이 온다.

그러나 파비콘 밑에 선을 그어주는 방식이라면 컨테이너 탭이라는 점을 알 수 있으면서도 구분 가능하다.

2. 선택된 탭, 다중 선택 된 탭, 호버 탭, 아무것도 선택되지 않은 탭

Photon, Lepton은 확실한 구분이 가능하나, Proton은 색이 거의 같다.

3. 선택 + 컨테이너 + 음소거

Photon은 닫기 버튼 옆에 음소거 아이콘이 존재하여 나름 일관성이 있다.

그러나 컨테이너까지 합해 너무 많은 강조표시가..

Proton은 파비콘을 대체해버린다. ㅋㅋㅋ

솔직히 이건 UI팀이 무슨 생각을 한건지 모르겠다.

선택이 되어있든, 안되어있든 무조건 사운드 아이콘을 보여주드라.

Lepton은 일관성있게 파비콘쪽에 정보들을 몰아서 보여준다.

4. 선택 + 호버 + 컨테이너 + 음소거

Photon, Proton은 투명도를 살짝 제거해주는 수준이지만,

Lepton은 색상을 반전과 투명도 제거가 동반되며 배경 범위도 살짝 넓어져 확실한 강조표시를 해준다.

5. 선택 + 컨테이너 + 음소거 + PIP

Photon, Lepton은 PIP 표시가 있지만, Proton은 없다.

6. 선택 + 호버 + 컨테이너 + 음소거 + PIP

Photon은 PIP 표시기의 투명도가 그대로이지만, Lepton은 투명도 제거가 존재.

7. 음소거 + 로딩

Proton은 로딩 인디케이터를 감춘다.

성능과 UX 트릭글에 작성했지만 1초 이상이라면 스피너가 작동하는게 좋다.

그렇지 않으면 사용자는 인터넷과 사이트가 아니라 브라우저에 문제가 있다고 판단할 수도 있다.

8. 컨테이너 + 음소거 + 이미지 없음

Photon, Proton은 지금까지 봐왔던 방식 그대로이다.

Lepton은 이미지가 존재하지 않을때만 소리 아이콘으로 파비콘 자리를 대신한다.

9. 컨테이너 + 음소거 + PIP + 이미지 없음

Photon은 사운드와 PIP 표시기가 동시에 필요한 경우 강제로 대체 파비콘이 나타난다.

Proton은 여전히 컨테이너와 소리정보만 표시한다.

Lepton은 파비콘 대신 사운드 표시기로 대체되며, PIP도 봐왔던 대로 표시된다.

10. 호버 + 컨테이너 + 음소거 + 이미지 없음

Lepton은 호버동작을 강조해주기 위해 컨테이너 표시를 잠시 감춘다.

11. 선택 + 컨테이너 + 음소거 + 고정

Photon은 PIP가 있을때와 비슷한 방식이다.

Proton은 지금까지 꾿꾿히 지켜왔던 일관성을 져버리고, Photon 방식과 유사하게 표시된다.

Lepton은 Chromium의 작은 탭 선택 때 닫기버튼에서 영감을 얻어 닫기 버튼을 표시해준다.

어차피 현재 방문중인 페이지 정보는 충분히 인지할 수 있으니, 닫기버튼을 노출하는게 낫다고 생각한다.

12. 선택 + 호버 + 컨테이너 + 음소거 + 고정

Photon은 투명도만 제거해주던게 색반전까지 시켜준다.

Proton은 투명도 제거에 배경이 살짝 넓어진다.

Lepton은 역시 Hover 동작에 컨테이너 표시가 사라져 집중하는데 도움을 주며, 사운드 아이콘과 닫기 버튼은 원래 방식대로 이용가능하다.

13. 선택 + 컨테이너 + 음소거 + 고정 + 로딩

Hover와 마찬가지로 작업 중이란 표시를 해주기 위해 잠시 컨테이너 표시가 사라진다.

이건 표시하는게 낫나.. 계속 고민 중.

14. 호버 + 컨테이너 + 음소거 + 제목 변경

개인적으로 Photon 방식을 선호한다.

Proton도 나쁘지 않게 보여준다.

Lepton은 제목 변경 표시인 점과 컨테이너 선의 표시를 결합하여 점선을 보여준다.

15. 컨테이너 + 아이콘 없음 + 제목이 길 때

Photon과 Proton에서 ced가 잘 안보이는 반면,

Lepton에서는 d도 c수준까지 보여준다.

요약

전반적 성향을 요약하자면,

Photon: 최대한 많은 정보를 노출함
Proton: 간단하여 생략되는 정보가 많음
Lepton: 간단하면서도 많은 정보를 일관적으로 보여줌

내가 만든 테마가 얼마나 신경을 썼는지를 알 수 있는 부분이다.

대신 각종 동적기능(파비콘이 없을 때 사운드 아이콘의 대체, 컨테이너 표시가 사라짐)과 예외 사항이 많아져 탭 크기와 아이콘 위치 변화등을 억제등 때문에 구현이 무척 짜증난다.

새 탭 컨텐츠

왜 인지는 모르지만 새 탭 컨텐츠의 아이콘들에도 지나치게 많은 공간을 남겨뒀다.

공간 낭비를 제거해 눈에 띄도록 했다.

새 탭 컨텐츠 전, 후

다크모드 검색창 포커스 시에 나타나는 눈뽕도 제거완료.

Proton 다크모드의 강조색으로 바꿨다.

소감

처음에는 단순히 간격이랑 탭 디자인 정도만 수정하려고 했는데

정신차리고 보니 새로운 버전업 수준 같다.

갠취에 맞춰서인지 크롬, 파폭(Photon, Proton)보다 훨씬 이쁘다고 느낌.

희망사항을 좀 끼얹어 엣지랑 비슷하거나 낫다고 느낄 수준?

아이콘의 일관성만 조금 더 갖춰지면 가능하지 않을까, 바래본다.

첨언하자면 엣지는 일관성은 좋으나 아이콘들의 메타포가 아쉽다.

솔직히 새탭-새창-새로운 사생활 창은 모양들이 비슷해 지금도 헷갈린다.

특히 사생활 창은 확대를 해보고 나서야 사람모양이라는 점을 알아챘다.

처음에는 바람인줄 알았..

페이지 저장, 웹 캡처, 페이지에서 찾기는 쓸데없는 모양들이 너무 많다.

그냥 디스크, 카메라, 돋보기로 끝내도 될 아이콘들이다.

페이지에서 찾기는 페이지 소스 보기랑 혼동되서 Proton Fix에 아예 소스 보기용 아이콘 아이콘으로 넣어버렸다.

스타일의 일관성을 추구한다고 모양의 반복까지 생기면 안된다고 생각한다.

스캐닝 가능성이 떨어지기 때문이다.

앞으로 실험적으로 JS도 도입(대신 설치과정이 복잡해짐)하면 없어진 북마크 애니메이션과

아무 반응도 없다 ㅠㅠ

페이지 액션 작업을 복원해보고 싶다.

3. 제언

정식 Proton 디자인은 6월 1일에 출시 예정이다.

https://blog.mozilla.org/firefox/new-firefox-coming-june-1/

Behind the design of the fresh new Firefox coming June 1 – The Firefox Frontier

A fresh new Firefox is coming your way on June 1. Worry less, get more done and feel good about what’s on the horizon. That’s the energy we all need in 2021.

blog.mozilla.org

이 글이 마음에 들었다면,

테마를 다운로드 받아서 써보자.

아!! 그리고

숨겨진 기능으로 레거시 엣지처럼 반응하는 기능이 들어있다.

https://github.com/black7375/Firefox-UI-Fix/tree/interactive-js/JS

실험적이고 적용법이 상대적으로 복잡한 편.

아직 정식 기능이 아니라 이슈를 통한 지원은 없습니다.

[스압/데이터주의] 웹 최적화 방식 모음 - 5. 빌드

BlaCk_Void — Fri, 5 Mar 2021 12:32:45 +0900

5. 빌드

빌드 성능 최적화를 앞서, 우리가 사용하고 있는 툴들의 종류가 무엇이 있는지 생각해보자.

로컬에서 자바스크립트 코드 자체를 실행하기 위한 Node.js
패키지 설치와 의존성 관리를 위한 NPM
모노레포 관리를 위한 Lerna
자바스크립트를 정적으로 만들기 위한 Typescript
트랜스파일링이나 컴파일을 위한 Babel
코드 퀄리티를 위한 ESLint
코드 스타일을 위한 Prettier
모듈 번들링을 위한 Webpack
모듈 테스트를 위한 Jest
E2E 테스트를 위한 Cypress
컴포넌트 개발과 문서화를 위한 Storybook
CI/CD를 위한 Github Action

등등등..

그야말로 툴들의 전성시대라 말해도 과언이 아니다.

이 글에서는 툴들의 필요성과 역사, 최신 툴들의 이점에 대해 탐색해보도록 한다.

특히 규모가 클수록 빌드 타임을 줄여 생산성 측면에서 많은 이득을 얻을 수 있다.

cargo로 패키지, 워크스페이스, 빌드. 테스트 다해먹고 rustfmt와 rust-clippy만 써도되는 러스트 생태계가 부럽다..

5.1 패키지 설치와 의존성

개요

초반에 Npm이 만들어진 이유는 글로벌이 아닌 로컬 패키지를 사용, 패키지 버전관리, 중첩된 패키지 관리등을 위해서였다.

전역(글로벌) 패키지를 사용할 경우 일반적으로 한가지 버전만 설치가 가능하며, 이에 비롯되는 문제들이 많다.

예를 들어 여러 패키지가 한 공통 패키지를 참조할 때 공통패키지에서 브레이킹 체인지가 발생한다면 어떻게 할 것인가?

아치 리눅스의 경우 항상 최신의 버전을 유지하도록 한다.

그럼 업데이트가 안되는 패키지는 깨지고, 사용이 불가능해진다.

또한 최신 패키지에 버그가 있거나 동작 불가, 악의적 동작이 삽입될 경우 문제가 생길 수 있다. [Colors.js / Faker.js 개발자가 무한루프 코드를 삽입하고, Repo의 코드를 모두 지움, colors.js와 faker.js 사태가 준 교훈]

때문에 core, extra, community, aur등으로 품질요구와 신뢰성에 따라 레포지토리를 나누어놓았지만 완벽한 해결책은 아니다.

이를 해결하는 가장 간단한 방법은 각 버전의 패키지를 모두 설치하는 것이다.

순수함수형 패키지 매니저인 nix가 작동하는 방식으로 /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/처럼 패키지 고유 식별자를 부여하여 여러가지 버전과 변형을 각각 설치하도록 격리하며 재현성을 가지도록 만들수 있다.

단점은 아주 작은 패치가 있어도 각각의 빌드를 모두 설치해야 하므로 디스크 공간의 낭비가 심하다.

Setting Up Automated Semantic Versioning For Your NodeJS Project, What's the difference between tilde(~) and caret(^) in package.json?

Npm은 몇가지 제한으로 꽤 현명하게 동작한다.

로컬 패키지
프로젝트 별로 필요한 버전의 패키지를 달리 설치할 수 있으며, ./node_modules에 위치하므로 제거도 간편하다.
중첩된 종속성구조
서로 다른 버전의 하위 종속성을 가지고 있을시 중첩적으로 존재하여 여러가지 버전을 가짐
SemVer와 업데이트
SemVer(Semantic Versioning)을 사용함으로서 브레이킹 체인지, 기능 추가, 버그수정를 나눌 수 있게 되었고, 업데이트할 패키지 버전범위를 제어할 수 있게되었다.
특히 틸트(~)와 캐럿(^)을 이용한 방식은 아이디어가 좋다. [npm package.json에서 틸드(~) 대신 캐럿(^) 사용하기]

중첩된 종속성 구조의 경우, 윈도우의 파일 경로 길이 제한등 때문에 호이스팅을 통해 종속성 트리를 평평하게 만들었다.

종속성 트리를 평면화하면 똑같은 버전의 패키지는 여러번 설치할 필요가 없었으므로 디스크공간과 설치 시간 절약에 도움이 되었다.

yarn(v1)은 성능과 정확한 버전이 명시된 의존성 파일로 주목을 받았으며, Npm v5에도 비슷한 기능이 적용되었다.

다운로드한 패키지를 캐시에 저장후 복사
yarn.lock이란 락파일 제공

그러나 node_modules와 관련된 문제는 많았다.

유령종속성

특히 호이스팅과 관련된 문제가 많았는데

직접 설치하지 않은 패키지에 접근이 가능
종속성 트리 병합 알고리즘이 복잡
일부 패키지는 여전히 flatten 되지 않고 중첩적으로 존재

Pnpm은 심볼릭 링크와 하드 링크를 이용해 동작한다. [Why should we use pnpm?]

하드 링크와 심볼릭 링크

링크를 사용하므로, 캐시로부터 복사하는 yarn(v1)보다 빠르며 디스크 공간이 절약
각 패키지는 고유한 종속성을 가지지만, 평평하게 유지된 패키지로 링크하여 경로 길이 해결
node_modules에 유령 종속성이 없도록 깔끔하게 유지

Motivation

그러나 링크를 사용하면 호환성 관련 문제가 있을수도 있다. [1, 2]

운영체제와 파일시스템에 따라 다름
watching의 동작
재귀 관련 오류
다른 툴들과의 호환성

yarn (v2, berry)는 node_modules의 호이스팅 문제를 해결하고, 의존성 탐색과 용량문제를 해결하기 위해

pnp(Plug'n'Play)와 ZipFS(Zip Filesystem)을 도입했다.

.pnp.cjs 파일에 의존성 관련 모든 정보를 기술하여 node_modules 탐색을 하지 않고 직접 접근할 수 있다.

의존성 검색을 따로하지 않기에 빠름
node_moudules에서 찾지못하면 상위 디렉토리의 node_modules에서 검색하여 의존성을 찾는 일이 없기 때문에 동일한 재현성을 보장

역시 단점이 존재하며 대부분의 문제는 호환성.

yarn node라는 명령어를 사용해야 하며, 아래에서 나올 nx나 turborepo 같은 경우 동작하지 않는 등의 문제
각 에디터에는 SDK가 필요하다.
eslint의 사용이나 쉘 스크립트로 된 bin등의 호환성 문제

ZipFS는 설치 용량을 획기적으로 줄여주며(400MB -> 120MB) 구성파일이 적어 변경 감지와 의존성 제거 작업이 빠르다.

때문에 모든 설치 파일을 git에 포함하는 zero install 전략을 사용할 수 있게 되었다.

해결방안

개인적으로 yarn이 마음에 든다.

ZipFS로 Zero-Install, v3.1에서 Pnpm 같은 설치모드 지원과 Conditional Package, 추후 적을 Workspace 등등의 기능들을 잘 묶어서 전달한다.

아직 pnp를 그대로 사용하기에는 호환성 문제가 많아서, zero-install + pnpm 모드로 사용해보는게 어떨까 싶다.

Migrating a monorepo from Lerna to Yarn 3 with PnP and Zero Install

라는 글이 비교적 마음에 들게 써졌다.

5.2 모노레포

개요

거대한 앱이 있다고 생각해보자.

모놀리딕하게 모두 하나의 프로젝트로 구성된다면 설계, 배포 등을 커다란 단위로 처리해야 해서 비효율적이다.

따라서 거대한 프로그램은 모듈화를 하게된다.

자, 그럼 모듈의 위치를 어디에 두어야할지 생각해봐야한다.

각 모듈 당 레포를 하나씩 만들게되면 멀티레포(또는 폴리레포) 구조가 된다.

레포를 여러개 만들게되면 독립성은 생기지만, 각각 테스트와 배포등을 모두 설정해줘야 하고 다른 패키지의 변경사항이 생기면 매번 업데이트 해줘야한다.

따라서 모노레포를 이용해 각 모듈을 한꺼번에 관리하는 개념이 나오기도 했다.

응집도를 높일 필요가 있는 프로젝트일 경우 사용하는게 좋다.

요약해서

모듈화 <-> 모놀리딕
모노레포 <-> 멀티레포(또는 polyrepo)

의 개념으로 생각합시다.

해결방안

Lerna는 Nrwl(Nx 팀)이 인수한 상태이며 기능과 성능은 Nx, Turborepo가 좋은 편이다.

Nx는 기능이 많고 통합이 잘되어 있지만 상대적으로 설정이 까다로운 편이다.

약간 더 설정이 간단한 Vercel의 Turborepo과 비교하여 필요한 것을 도입하자.

앞서 말했지만 아직 모노레포 툴들이 yarn pnp를 제대로 지원하지 않고 있다.

5.3 트랜스파일링과 컴파일

개요

자바스크립트는 크로스플랫폼에서 동작하는 가장 간단한 언어 중 하나라 타겟으로하는 언어들이 많다.

역시 컴파일러가 필요하다.

가 대표적인 예라 볼 수 있다.

그러나 구형 브라우저를 타겟으로 최신 ESNext 문법을 사용하거나 JSX같은 언어적 확장을 사용하기 위해서도 트랜스파일링(또는 컴파일)과정이 필요하다.

그래서 보통 사용되는 것이 바벨(Babel).

해결방안

그렇지만 컴파일 시 느리다는 말들이 정말 많다.

첫번째 방안은, 타입스크립트나 flow를 사용한다면 컴파일시 타입정보들을 모두 제거하고 한번에 처리하는 것이다.

타입체크는 tsc를 이용해 따로 진행하도록 하자.

그리고 babel보다 빠르게 컴파일되는게 있으니, 바로 swc다.

러스트로 만들어졌고, 멀티코어를 활용하며 타입스크립트의 경우 babel처럼 타입정보를 제거하며 동작한다.

아직 플러그인이 적지만, 고려해볼만 하다.

타입체커의 경우 stc라는 이름인데 아직 준비중이라는 듯.

5.4 번들링과 태스크 러너

개요

Webpack같은 모듈 번들러가 왜 필요할까?

이외에도 css, image같은 각종 리소스 관리, HMR(Hot Module Replacement) 개발서버 등도 지원하기도 한다.

JavaScript 번들러로 본 조선시대 붕당의 이해

우선 모듈은 무엇이고 번들링과 태스크 러너란 무엇인가.

모듈은 웹 애플리케이션을 구성하는 모든 자원을 의미한다.

단순히 Javascript만을 뜻하는게 아니라 HTML, CSS, Javascript, 이미지, 폰트등 모든 파일들 각각은 모두 모듈이다.

What is Bundling?

그러나 매번 각각의 모듈을 호출하는 것은 비효율적이다.

특히 HTTP/1에서 호출 제한이 있었으며, HTTP/2에서도 이미지 스프라이트 이점이 있던 점을 떠올려보자.

따라서 우리는 단순히 컴파일을 넘어 번들링까지 필요하다.

번들러는 각각의 모듈들을 조합해서 병합된 하나의 결과물을 만드는 도구를 의미한다.

이때 태스크 러너와 많이 비교되기도 한다.

왜냐. 대표적인 태스크 러너는 Make인데 우리는 빌드를 할 때 사용한다는 점을 알고 있다.

웹 생태계에서는 Grunt, Gulp가 대표적인 태스크러너이며 역시 빌드용으로 많이 사용되었다.

이제 슬슬 혼동이 오기 시작한다.

Webpack에서 webpack --mode=production로 프로덕션용 빌드를 하고, webpack --mode=development로 개발용 빌드를 하지 않던가?

태스크 러너는 모든 작업을 우리가 순차적으로 지정해줘야 하지만, 번들러는 엔트리와 플러그인을 지정해주면 종속성을 파악해 한번에 실행된다는 점에서 차이가 있다.

웹팩(Webpack) 이란, 웹팩 간단 정리 및 리액트(React) 기본 개발환경 세팅., Webpack or Browserify & Gulp: Which Is Better?

게다가 종속성 분석이 가능해짐으로서 단순히 파일을 merge하는 것보다 빠르고 Tree Shaking, Code Splitting, Dynamic Import(Lazy loading)등을 처리하며 심지어 Dev server와 연동하여 HMR(Hot Module Replacement)까지 제공한다.

성능차이

Using Webpack for API development!

이쯤되면 "아~ 번들러가 태스크러너의 상위의 존재?구나"라는 생각이 들 수도 있다.

그러나 Webpack의 Integrations 문서에도 나오듯 잘하는 일이 다른 것 뿐이며 태스크러너는 packages.json의 scripts에 가깝다.

앞서 태스크러너의 예로 나온 makefile이 install과 clean은 수행해도 lint나 test 명령이 쓰이기도 하나 싶지만 실제로 오라클 가이드에서도 소개되며 린트, 테스팅등을 하는 용도로 쓰이는 한다.

물론 린트와 테스팅 도구들이 번들러와 통합하여 쓰이는 경우들이 잦아져 쓸 필요가 줄어들고 있다.

그치만 복잡한 publishing등의 작업들이 필요하다면 태스크러너를 사용하는게 유용할 수도 있다.

단, 모노레포에서 태스크 러너는 위에 나온 모노레포 관리 도구들에 의해 상당히 대체 가능하다고 생각한다.

아직도 혼동이 오나요?

번들러는 Gulp 기준 src()~dest()를 효율적으로 실행해주는 프로그램입니다.

웹팩에서 src()는 Entry, dest()는 Output이죠.

로더, 플러그인, 모드는 뭐냐고요?

Where can I learn webpack?, Webpack loaders vs plugins; what's the difference?

로더는 로드할 각각의 파일 수준에서 작동합니다.

플러그인은 번들링 수준에서 작동합니다.

How to set up WebPack based TypeScript Electron React Build Process (with VSTS CI!)

모드는 설정을 하기위한 매개변수이라 단순히 생각합시다.

여기서!! 번들러가 자바스크립트의 모듈을 분석한다고 했었죠.

그런데 자바스크립트의 모듈 시스템은 통일성이 없고 매우 다양하다.

본디 브라우저에서 script 태그로 로드를 하는 형식이었지만, 전역 컨텍스트에서 로드하여 이름이 겹쳐 재정의되는등의 문제가 있었다.

<html>
  <script src="/src/foo.js"></script>
  <script src="/src/bar.js"></script>
  <script src="/src/baz.js"></script>
  <script src="/src/qux.js"></script>
  <script src="/src/quux.js"></script>
</html>

그래서 나온것들이 자바스크립트의 모듈들이다.

Common.JS는 서버 사이드에서 사용하기 위해 나타났으며 Node.JS의 기본 모듈 시스템이기도 하다.

한계로는 동적이라서 트리쉐이킹에 취약했으며 비동기적으로 사용이 어려웠다. [CommonJS가 번들을 더 크게 만드는 방법]

밑에 나올 Rollup은 CommonJS가 아닌 ESM을 사용하여 빌드하므로, 트리쉐이킹에 강점이 있다.

// == Default 모듈 ================================
// Default 모듈 정의, foo.js
const foo = () => console.log(0);
module.exports = foo;

// Default 모듈 사용
const foo = require("./foo");
foo();


// == 모듈 ========================================
// 모듈 정의, bar.js
const baz = () => console.log(1);
module.exports = {
  baz
};

// 모듈 사용
const barModule = require("./bar");
barModule.baz();

const { baz } = require("./bar");
baz();

AMD(Asynchronous Module Definition)은 비동기적으로 모듈을 로드하기 위한 시스템이다.

브라우저에서 모듈을 로드할때 스크립트 태그로 로드하면 로딩이 완료될 때까지 브라우저가 프리징 되었기 때문에 비동기적으로 로드하려는 노력이었다.

AMD 로더 중 가장 유명한게 require.js.

// 모듈 정의, foo.js
define({
  foo: () => console.log(0)
});

// 모듈 정의, qux.js
define(['foo', 'bar', // 의존 모듈들을 배열로 나열
], function (foo, bar) { // 의존 모듈들은 순서대로 매개변수에 담김
  return {
    // 외부에 노출할 함수들만 반환
    foo,
    barModule: bar
  };
});

// 모듈 사용
require(['qux.js', // 사용할 모듈 배열로 나열
], function (quxModule) { // 사용할 모듈들이 순서대로 매개변수에 담김
  quxModule.foo();
  quxModule.barModule.baz();
});

UMD(Universal Module Definition)은 CommonJS와 AMD를 모두 지원하기 위해 나온 디자인 패턴이다.

Webpack이나 Rollup같은 번들러에서 ESM을 지원하지 않는 브라우저라면 fallback 용으로 사용하기도 한다.

(function (root, factory) {
  if (typeof define === 'function' && define.amd) {
    // AMD 방식
    define(['exports', 'foo'], factory);
  } else if (typeof exports === 'object') {
    // CommonJS 방식
    module.exports = factory(require('foo'));
  } else {
    // Browser globals
    root.foo = factory(root.foo);
  }
}(this, function (foo) {
  //use foo in some fashion.
   // 모듈 정의
  const foo = () => console.log(0);

  return foo;
}));

그리고 마침내 ESM이 나왔다!!

드디어 언어자체에서 모듈시스템을 지원한다.

동기/비동기를 모두 지원하고, 순환참조 문제가 없으며 정적분석까지도 가능하다.

// == Default 모듈 ================================
// Default 모듈 정의, foo.js
const foo = () => console.log(0);
export default foo;

// Default 모듈 사용
import foo from "foo";
foo();


// == 모듈 ========================================
// 모듈 정의, bar.js
export const baz = () => console.log(1);

// 모듈 사용
import { baz } from "bar";
baz();

이외 사양으로 Javascript Code Module이라고 파이어폭스 내부에서 사용하는 모듈 시스템이 있다.

권한이 있는 다른 범위의 자바스크립트에서 코드를 공유하기 위해 만들어졌다.

// == JSM 모듈 ===================================
// Default 모듈 정의, foo.jsm
var EXPORTED_SYMBOLS = ["foo"];

const foo = () => console.log(0);

// Default 모듈 사용
Components.utils.import("resource://app/foo.jsm");
foo();

// == CommonJS ===================================
// 모듈 사용
const { require } = Cu.import("resource://gre/modules/commonjs/toolkit/require.js", {});
const { baz } = require("./bar");
baz();

해결방안

Browserify를 누르고 올라온 Webpack이 한동안 Defacto Standandard였지만 춘추전국시대로 난립중이다.

기존에 주로 쓰이던 것은 Webpack, Rollup, Parcel이며, 빠른 빌드로 유명한 esbuild도 주목할만 하다.

Webpack은 이 글을 쓰는 시점 기준, 널리 쓰이다보니 안정적이며 로더와 플러그인들이 많다.

Rollup은 ESM을 기준으로 빌드하여 트리쉐이킹에 강점이 있다. 단, dev sever등의 기능들이 부족.

Parcel은 제로 config를 지향하여 세팅이 쉽다. 대신 커스텀 설정이 어려울 수 있다.

Esbuild는 Go 언어로 짜여졌으며, 병렬처리를 사용하여 빠른 빌드를 자랑한다.

그리고 차세대 도구로 부상하는 Snowpack, Vite, wmr.

이들은 번들링 자체보다는 개발서버의 역할과 빠른 개발 빌드로 주목받는다.

How Snowpack Works

브라우저에서도 ESM을 지원함에 따라 매번 번들링을 수행할 필요가 없어졌다.

CommonJS는 브라우저에서 지원하지 않아 번들링이 필요했었죠?

게다가 Snowpack은 NPM의 CommonJS 패키지들을 개별 JS 파일로 변환 후, 브라우저에서 ESM Import를 사용하여 가져오게 한다. (사전 번들링)

Vite의 접근도 비슷하다.

소스코드는 Native ESM을 사용하고, NPM 패키지들은 Esbuild로 사전 번들링을 수행한다.

Vite를 사용해야 하는 이유

Snowpack이 개발용에만 신경썼던 한편, Vite는 프로덕션 빌드에는 Rollup을 사용해 최적화했고 전반적인 통합을 높혔다.

독단적인 결정일 수 있지만 나는 꽤나 합리적인 기본값이라 생각하며, 그 결과 Multi-Page App이나 라이브러리 모드등의 다양한 기능들을 제공한다.

단, Vite는 Snowpack과 wmr의 Streaming Import를 아직 지원하지 않는다.

Streaming Import는 Native ESM을 최대한 활용하기 위해 Skypack같이 ESM 패키지를 제공하는 CDN에서 직접 로드하여 성능을 높힐 수 있다.(사전 번들링 불필요)

wmr은 preact에 중점을 둔 작은 번들러로, 프로덕션 빌드 최적화나 Streaming Import를 지원한다.

또한 HTM을 사용해 소스맵에 의존하지 않고도 디버그 정보를 잘 표현해준다.

암튼 최근 경향은 Vite가 대세로

를 읽어보자.

아, 그리고 직접 모노레포를 yarn & vite & typescript로 구축하며 생겼던 몇가지 문제.

vite.config.js는 괜찮지만, vite.config.ts는 트랜스파일링에서 문제가 생김: builder 패턴으로 해결
yarn PnP 모드를 사용시 tsconfig의 extends가 작동하지 않음: pnpm모드 사용

Vite와 통합되어 Storybook과 Jest를 대체하는 프로젝트들도 나오게 되었다.

역시 성능에 초점을 맞추고 있다.

Storybook - Ladle [Introducing Ladle]
Jest - Vitest [From Jest to Vitest - Migration and Benchmark]

그냥 생으로 rollup + esbuild 세팅에 관심있다면 rollup-typescript라는 gist를 참고해봅시다.

에어비엔비에서는 React Native에서 사용하는 Metro를 사용해 속도를 올렸다.

특이한점은 다계층 캐시가 있다는 것.

태스크 러너의 경우 앞서 말했듯 Grunt와 Gulp가 유명하구(taskr이라고 코루틴을 사용한 플젝도 있다는 모양)

윗 글들만 읽어보면 충분할거라 생각한다.

단순히 npm scripts를 효율적으로 실행시키고 싶은거라면 wireit이란 프로젝트도 참고해보자.

지금, 멀티레포 관리 툴과 wireit을 보면 태스크 러너 바퀴의 재발명이라는 생각이 든다.

Git 명령어에 따른 태스크를 실행시키는 husky는 현재도 많이 쓰인다.

5.5 린트와 포매팅

개요

보통은 eslint, prettier를 각각 구현방식, 코드 포맷 검증용으로 사용한다

Using Prettier and ESLint to automate formatting and fixing JavaScript

린터는 코드의 안티패턴과 에러를 찾아서 검출하려는 목적이며,

포매터는 2 space, 4 space처럼 코드의 스타일을 통일하려는 목적이다.

여러 케이스가 합쳐지면 까다로우니 다음 글들을 확인 부탁드린다.

개인적으로 잘가, 클린 코드란 글의 의견처럼 빡빡하게 린트와 포매팅하는 것을 좋아하지는 않는다.

보기좋은 코드를 만들기 위해 스페이스를 많이 활용하는 편인데 많은 포매팅 규칙들이 멀티 스페이스를 삭제시켜버린다.

때문에 React의 코드만 봐도 강제적인 포맷팅에서 회피하기 위해 주석으로 공간을 만들어주는걸 볼 수 있다.

약간만 유연하게 한다면 내가 작성했던 SplitCubicalBezier처럼 나름 깔끔하게 나온다.

해결방안

Eslint와 Prettier 대체제는 음..

나중에 Rome로 어떻게든 될 수 있지 않을까..

그렇지만 지금은 툴 자체가 성숙하지 않았기 때문에 다른 대안을 찾아보자.

quick-lint-js도 빠르지만 아직 타입스크립트를 지원하지 않는다.

아직 eslint + esprint나 eslint_d 조합이 최선이라 생각한다.

포매팅의 경우

Switching deno fmt from prettier to dprint, performance increase 10+ times

위의 eslint_d와 같은 계열인 prettierd 또는 dprint를 사용해볼 수 있다.

lint-staged, pretty-quick은 staging된 파일에만 적용하여 빠르게 체크가 가능하다.

CSS의 경우 stylelint_d를 확인해보는 것도 좋다.

5.6 테스트

개요

Why I think Jest is better than Mocha & Chai

이 파트도 Toast UI가 잘 정리해줬다.

너무 깔끔해서 여기서 설명을 안해도 될 듯 싶다.

아 그리고, Enzyme를 사용하고 있다면 React Testing Library를 사용하도록 하자. [Enzyme is dead. Now what?, React Testing Library 사용법]

테스트에 관심있다면 Property based testing도 시도해보는건 어떨까?

하스켈의 QuickCheck로 유명하며, 자바스크립트쪽에는 fast-check를 쓰면 된다.

테스트 입력값을 테스팅 도구가 자동 생성해서 확인할 수 있다.

만들기는 까다롭겠지만 엣지케이스 버그를 찾기가 더 좋다.

해결방안

현재로선, Jest가 가장 많이 쓰이고 있는 것 같다.

다만, Jest가 병렬로 실행됨에도 느리다는 말이 좀 있다..

가장 큰 병목 중 하나는 import를 매번 다시 하기 때문인듯하다.

또 다른 성능 향상 방법으로 샤딩을 사용하면 깃허브 액션에서 매트릭스를 이용해 테스트를 나눌 수 있다.

앞서 언급한 vitest는 vite의 resolver를 사용하고 esm first등의 이점이 있어 성능면에서 나은 점도 있다.

게다가 러스트처럼!!! 소스내부에서 유닛테스트가 가능하다는게 가장 큰 장점.

~~벤치마크의 경우 논의 중에 있다.~~(이제 지원됨)

~~단, 아직 캐싱과 샤딩(이슈)을 지원하지 않아서 아쉽다.~~(이제 지원됨)

또한 Jest의 커스텀 러너를 허용하게 되면 일렉트론 환경에서도 테스트가 가능하고, 린트/타입체크 모두 테스트 러너를 통해 효율적으로 실행할 수 있다.

이건 아직은 지원안하는 중.

5.7 CI/CD

개요

예전에 Emacs-NG에 CI 성능관련 PR을 만들었을때 몇가지 인사이트를 얻을 수 있었다. [깃허브 워크플로우 최적화]

autoconf로 빌드하는데다가 C, Rust, Elisp 컴파일등 상당히 복잡한 구조를 가졌기에 여러가지를 고려하기 좋은 프로젝트였다.

핫빌드 기준 무려 278%의 성능향상을 했었다.

우분투: 26m 5s => 11m 53s
맥OS: 39m 7s => 14m 8s

의외로 CI/CD 시간 단축 작업은 쉽지 않은데, 다운로드/업로드와 빌드, 빌드 후 동작등 모든 것을 고려해야 한다.

해결방안

- CI/CD 건너뛰기/분리

가장 좋은 것은 CI/CD 자체를 실행하지 않는 것이다.

README만 바뀌었는데 매번 빌드와 테스트까지 모두 할 필요는 없지 않은가.

만약 문서 퍼블리싱을 해야한다면, 퍼블리싱만 수행하면 된다.

깃허브의 경우 다양한 필터링을 할 수 있다.

이 뿐만이 아니다.

병합 후처럼 굳이 실행할 필요가 없는 중복된 경우에도 건너뛸수 있고, 테스트 코드만 고쳤을 경우에는 이전 빌드 결과를 사용해볼 수도 있다.

서로 의존하지 않는 CI/CD를 분리할 수 있다.

예를들어 코드 포매팅 확인, 문서 배포 등은 빌드와 함께할 필요가 없다.

Jest나 Vitest등은 샤딩(shard) 옵션을 제공하므로 병렬 job으로 나누어 실행할 수도 있다.

- 다운로드 및 CI/CD 환경

CI/CD를 실행하려면 의존하는 패키지가 설치되어 있어야하고, 레포의 코드 또한 다운로드 받아야 한다.

일단 의존하는 패키지들이 설치되어 있어야 한다.

일반적인 경우, 깃허브 액션 캐시로 node_modules나 .yarn등만 캐시하면 충분하다.

그러나 가끔은 의존하는 네이티브 패키지를 컴파일 해야하는 경우처럼 시간이 많이드는 작업이 있을 수도 있다.

이럴때는 미리 도커로 의존성 빌드 후, 배포하는 것이 좋다.

도커빌드 시간 줄이는 방법

Caching Docker builds in GitHub Actions: Which approach is the fastest? A research.
buildx, buildkit 사용 [Docker buildx, Build images with BuildKit, Docker Buildkit 으로 빌드 시간 단축하기]
도커 빌드 캐싱

도커빌드시 Nix를 이용해 캐싱하기 (이때 tmpfs를 사용할 수도?)

빠르게 다운로드 받기

도커 이미지 크기 줄이기 [Docker - image 크기 줄이기, Go 프로젝트 Docker 이미지 크기 99.2% 줄이기 (부제: 이미지 크기 12921% 떡상 시키기)]
깃허브 레지스트리: 깃허브 액션에서 깃허브 레지스트리가 더 빠르다는 듯

다음은 레포지토리관련 최적화이다.

일단 레포지토리 자체의 크기를 줄이는 것을 생각해볼 수 있다.

Git LFS, Git submodule 활용하기, Introducing Scalar: Git at scale for everyone

파일과 커밋기록 영구제거: 보통은 패스워드처럼 민감한 파일을 제거하는데 사용하지만 커다란 파일을 삭제하거나 레포지토리를 나눌때도 활용할 수 있다. [깃 레포 분리하기/합치기, Removing sensitive data from a repository, Remove a Large File from Commit History in Git, How (and why!) to keep your Git commit history clean]
Git LFS 사용: 커다란 파일은 텍스트 해시로 만들고 따로 다운로드하여 가볍게 만들 수 있다
서브모듈 사용: 역시 원본 레포를 가볍게 만들며, git clone --jobs로 여러 서브모듈을 한번에 다운로드 받을 수 있다
레포지토리 GC: 복잡한 레포지토리의 경우 object/pack등을 관리해볼수도 있다 [레포지토리를 가볍게, Git 저장소의 성능을 유지하는 방법, Scaling monorepo maintenance]

git remote prune orign
git reflog expire --expire=now --all
git gc --aggressive --prune=now
git repack -abdk --window=1000 --depth=500
git repack -fF --write-midx --write-bitmap-index -d --geometric=2

다운로드시 타겟을 줄이는 방안도 있다.

Git 2.18에서 도입되어 2.26에 기본값으로 채택된 Git prtocol2가 큰 도움이 되었다.

예를 들어 CI/CD에서 테스트 하는데 모든 정보를 다운로드 받을 필요는 없지 않겠는가?

오래된/거대한 프로젝트는 수많은 커밋, 디렉토리, 브랜치들이 있을수도 있다.

모든 커밋 - 원: 커밋, 삼각형: 디렉토리, 사각형: 파일(blob)

부분 복제(Partical clone)은 --filter 옵션을 통해 기존 파일(--filter=blob:none), 더 나아가 디렉토리(--filter=tree:0)를 제외하고 다운로드 받을 수 있게 지원한다.

[Get up to speed with partial clone and shallow clone, How to Use Git Shallow Clone to Improve Performance, Gitlab partial clone]

기존 파일을 빼고, 기존 디렉토리를 빼고

clone시 --depth=1로 1개의 커밋으로 제한시키고, --single-branch --branch=<branch>로 브랜치를 제한할 수 있다.

기존 커밋기록까지 빼고

다운로드가 되고 나면 체크아웃 되는 과정도 있다.

이때 Git 2.25에서 도입된 sparse-checkout을 사용하면 원하는 부분만 체크아웃할 수 있어 시간과 디스크 용량을 절약할 수 있다. [Bring your monorepo down to size with sparse-checkout]

모노레포를 사용할 때도 유용하게 사용할 수 있다.

정리해보자면

clone --filter : 옛 커밋에서 복제할 내용을 필터링 가능 (particial clone)
clone --depth: 가져올 커밋 히스토리양을 제한
clone --single-branch: 한 브랜치만 클론 할 수 있음
sparse-checkout: 특정 디렉토리나 파일만 사용

[업데이트] 최신 Git 2.38에는 scalar라는 기능이 들어가서 sparse를 기본으로 lazy하게 쓸 수 있다.

- 빠른 빌드 및 테스트

기본적으로 빠른 도구들을 사용하자.

여기서 말할 것은 웹이 아니라 네이티브 프로그램을 위한 팁에 가깝다.

바로 프로덕션 모드와 디버그 모드의 트레이드 오프이다.

일반적으로 프로덕션 모드에는 최적화가 들어가므로 더 느리다.

그러나 빌드후 오래 걸리거나 계산집약적 통합 테스트등의 작업을 수행할 경우에는 프로덕션 모드로 최적화하는 것을 고려해볼 수 있다.

- 기타

소스파일 빌드관련 캐시처럼 매번 캐시업로드가 필요한 경우가 있을 수도 있다.

그러나 매번 캐시 업로드는 좋은 전략이 아니다.

10메가, 20메가 수준이라면 괜찮겠지만 기가 단위처럼 커다란 경우라면 캐시가 깨져 빌드가 조금 느리더라도 일주일에 한번씩처럼 주기적으로 갱신하는게 좋을 수 있다.

게다가 다운로드/업로드 회선이 비대칭인 경우가 많아서 느리다.

또한 캐시의 크기를 줄이려면 디버그 정보를 줄이고, 증분빌드를 비활성화해야 할 수도 있다.

[스압/데이터주의] 웹 최적화 방식 모음 - 4. 로드 후

BlaCk_Void — Sun, 14 Feb 2021 18:25:57 +0900

4. 로드 후

동일한 페이지, 다른 페이지

4.1 요청줄이기

다른 페이지로 넘어갈 때 요청량을 줄일 수 있는 여러 기법들이 존재한다. [Offline First]

4.1.1 클라이언트 저장소들 비교와 활용

개요

로드 후, 브라우저에 정보를 저장하는 것은 캐시로 사용해 서버에 요청을 줄이거나 낙관적 UI(Optimistic UI)를 구현할 때 커다란 도움이 될 수 있기 때문에 중요하다.

크로미움의 어플리케이션 탭에 들어가면 스토리지 항목 5개, 캐시 2개가 등장한다.

이를 Storage, DB, Cookie, Cache로 나누어 간단히 정리해보았다. [클라이언트 측의 저장소 살펴보기, 쿠키 vs 로컬스토리지: 차이점은 무엇일까?, 브라우저 쿠키(Cookie), 세션스토리지(Session Storage), 로컬스토리지(Local Storage), Working with quota on mobile browsers]

Storage

Web Storage는 클라이언트에 데이터를 저장하기 위해 만들어진 HTML5의 새로운 기능이다.

Key-Value 방식으로 이루어진다.

Session Storage: 5MB, 같은 탭, 브라우저 종료 시 삭제
Local Storage: 10MB, 모든 탭, 만료기간 없음

웹어플리케이션을 만들도록 도와주는 브라우저 내부에서 사용할 수 있는 DB다. [Beyond HTML5: Database APIs and the Road to IndexedDB, IndexedDB 간단 정리하기]

IndexdDB: Key-Value 방식(JSON), 50MB, 모든 탭, 만료기간 없음

Web SQL(Deprecated): SQLite Wrapper, 50MB, 모든 탭, 만료기간 없음

Web SQL은 표준화를 시키기 어려워서 Deprecated 되었다.

This document was on the W3C Recommendation track but specification work has stopped. The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.

Cookie

Cookie[HTTP Cookie, Document.cookie, Javascript cookies]에는 저장 유형, 연결 유형에 따라 여러가지로 나뉘기도 하나 여기에서는 Session Cookie와 Persistent Cookie만 다룬다. [HTTP Cookie - Terminlogy, A JavaScript developer’s guide to browser cookies]

Key-Value 방식이지만 사용하기는 Storage보다 불편하다.

setCookie나 getCookie 함수를 만들어 사용하는 것이 좋다고 생각한다. [쿠키(Cookie) 저장 및 삭제 예제보기]

가장 큰 특징으로는 서버에 전송되어 저장될 수 있다.

Session Cookie: 4KB, 모든 탭, 브라우저 종료 시 삭제

Persistent Cookie: 4KB, 모든 탭, 만료시기가 되면 삭제

Cache

둘다 리소스를 캐싱하여 속도를 빠르게 만들고, 서버의 로드비용을 아껴준다. [Browser Cache vs HTML5 Application Cache, Browser Cache Vs HTML5 Application Cache]

Cache Storage: 실제로 방문한 페이지만
Application Cache(Deprecated): Manifest 사용, 100MB, 오프라인 브라우징

그러나 Application Cache는 Deprecated가 되었기 때문에 서비스워커 + 캐시 API로 마이그레이션을 해야 한다. [Application Cache를 사용하지 않는 사이트]

해결방안

일단 Deprecated된 Web SQL과 Application Cache는 사용하지 않는 것이 좋다.

Storage와 Application Cache는 메인 스레드를 차단하는 동기 API이므로, 대규모 데이터를 사용하려면 비동기적이고 웹워커에서 접근 가능한 IndexedDB를 사용하는 것이 좋다. [Progressive Web App용 오프라인 저장소]

또한 The structured clone algorithm을 사용하여 파일에서 JSON을 저장하거나 검색하는 것보다 낫다.

단, IndexedDB의 API가 상당히 복잡한편 이라는 것.

Basket.js를 사용하면 localStorage에 저장(캐싱)하는 것이 가능하다.

단, 요즘은 그냥 서비스워커 + 캐시로 사용하는 것이 좋다고 생각.

서비스 워커 사용법은 앞서 언급했으니 참고바란다.

4.1.2 쿠키 사용 줄이기

개요

HTTP 쿠키들(cookies)은 인증 및 개인화와 같은 다양한 이유로 사용된다.

쿠키들에 대한 정보는 서버에 전송되며 교환되므로 성능과 보안에 문제가 생길 수 있다.

쿠키들의 크기를 가능한 한 작게 유지하는 것은 사용자의 응답시간에 미치는 영향을 최소화하기 위해 매우 중요하다. [When the Cookie Crumbles]

해결방안

링크의 내용을 정리하면 다음과 같다.

불필요한 쿠키들을 제거
사용자의 응답시간에 미치는 영향을 최소화하기 위해 쿠키들의 크기를 가능한 한 작게 유지
다른 서브도메인들이 영향을 받지 않도록 적절한 도메인 수준(level)에서 쿠키설정을 주의
적절한 만료(Expires) 날짜를 설정
이른 만료날짜를 설정하거나 설정하지 않으면, 사용자의 응답시간 개선을 위해 쿠키를 즉시 제거
클라이언트에 정보를 저장해야 하는 경우 Storage나 IndexedDB 고려

3번째 항목을 조금 더 설명하자면 쿠키 free 도메인을 사용하자는 뜻이다.

정적 이미지와 같은 컨텐츠를 요청하며 쿠키를 함께 보내는 것은 서버에 아무런 영향을 끼치지 않는다.

쓸데없는 트래픽만 유발하는 행위.

만약 도메인이 www.example.org이라면, static.example.org에 정적 구성요소들을 호스팅 할 수 있다.

그러나 www.example.org가 아니라 최상위 도메인 example.org에 쿠키들을 설정했다면, static.example.org로의 모든 요청은 쿠키들을 포함한다.

이 경우, 완전히 새로운 도메인을 구입할 수 있고, 거기에 정적 구성요소들을 호스트 할 수 있다.

또한 이 도메인은 cookie-free 상태로 유지될 수 있다.

Yahoo는 yimg.com을 사용, YouTube는 ytimg.com을 사용하고 Amazon은 images-amazon.com 등을 사용한다.

Cookie-free 도메인에서 적정 구성요소들을 호스팅 하는 것의 또 다른 이점은 일부 proxies가 쿠키들과 함께 요청된 구성요소들을 cache하는 것을 거부할 수도 있다는 것이다.

같은 맥락으로, 홈페이지에 example.org 또는 www.example.org의 사용을 망설이고 있는 중이라면, 쿠키에 미치는 영향을 고려해야한다.

www를 생략하는 경우는 *.example.org의 쿠키들을 작성하는 것 밖에 할 수 없지만, 성능을 위해 www 서브도메인을 사용하고 그 서브도메인에 대한 쿠키들을 작성하는 것이 최선의 방법이다.

4.1.3 캐시 제어문 헤더 추가

개요

분류: server

이 규칙에는 두 가지 측면이 있다.

정적 components: 미래 설정 시점까지의 “Never expire” 정책 수행
동적 components: 조건적 요청의 브라우저를 수행하기 위한 적절한 Cache-Control 헤더의 사용

페이지를 처음 방문한 사용자는 여러 개의 HTTP 요청을해야 할 수도 있지만 캐시 제어문 헤더를 사용하면 해당 구성 요소를 캐시 가능하게 만들 수 있다.

이는 후속 페이지 로딩 시에서 불필요한 HTTP 요청 수 및 크기를 피하고 로딩속도를 빠르게 만든다.

이미지와 함께 가장 많이 사용하지만 스크립트, 스타일 시트를 포함한 모든 구성 요소 에 사용해야한다 .

캐시는 프록시나 CDN등에서 하는 Shared Cache, 브라우저에서 하는 Local Cache로 나눌수 있다.

웹 서버에서 Cache-Control, Expires, Pragma로 제어할 수 있는데 Cache-Control이나 Expires를 사용하는 것을 권장한다. [캐싱 작동 방식]

- Cache-Control

요청(Request), 응답(Response)
후에 설명할 Expires 헤더의 제한 사항 해결을 위해 HTTP 1.1에 도입됨
따라서 Expires와 충돌 시 우선한다.
헤더 종류
- no-store: 캐시하지 않고, 항상 다시 다운로드
- no-cache: 캐시하지만, 재검증을 위한 요청
- must-revalidate: 만료된 캐시만 재검증
- public | private: public은 프록시에 저장을 허용하고, private는 브라우저에만 저장을 허용
- max-age=<second>: 리소스가 유효하다고 판단하는 최대시간을 명시, 0이면 no-cache와 같음

예시

      Cache-Control:public, max-age=31536000

- 만료(Expires)

응답(Response)
HTTP 1.0에 도입
<http-date> 값을 사용하며 max-age와 비슷하다.

예시

2020년 4월 15일까지 유효한 브라우저를 알리는 미래 시점의 Expires header이다.

      Expires: Wed, 15 Apr 2020 20:00:00 GMT

- Pragma

요청(Request)
HTTP 응답에서 명시되지 않았던 헤더라 Cache-Control의 신뢰할 만한 대체제가 아니며, 지원하지 않는 곳들도 많다.
no-cache: Cache-Control의 no-cache와 같다.

예시

      Pragma: no-cache

미래시점에 만료되는 헤더를 사용하면 사용자가 이미 사이트를 방문한 후에만 페이지뷰에 영향을 준다.

사용자가 처음으로 사이트를 방문하고 브라우저 캐시가 비어있는 경우 HTTP 요청 수에는 영향을 미치지 않는다는 말.

따라서 이 성능 개선의 영향은 사용자가 캐시된 페이지를 방문하는 빈도에 따라 다르다.

Yahoo!의 측정결과 캐시되어 있는 페이지 조회수는 75-85 %이었다.

미래시점의 헤더를 사용하면 사용자의 인터넷 연결을 통해 단일 바이트를 보내지 않고도 브라우저에서 캐시하고 후속 페이지뷰에서 재사용되는 구성 요소의 수를 늘릴 수 있다.

Ajax나 SPA에서도 캐싱을 적극적으로 활용하자.

해결방안

- 웹서버

aphache는 .htaccess 파일을 이용해 설정할 수 있다.[Caching Guide, mod_expires, Speed Up Sites with htaccess Caching]

<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 month" # years | months | weeks | days | hours | minutes | seconds
ExpiresByType image/gif "access 3 minutes"
ExpiresByType image/png "access 3 minutes"
ExpiresByType image/jpg "access 3 minutes"
ExpiresByType text/css "access 3 minutes"
</ifModule>

<ifModule mod_headers.c>
# YEAR
<FilesMatch "\.(ico|gif|jpg|jpeg|png|flv|pdf)$">
  Header set Cache-Control "public, max-age=29030400"
</FilesMatch>
# WEEK
<FilesMatch "\.(js|css|swf)$">
  Header set Cache-Control "public, max-age=604800"
</FilesMatch>
# 45 MIN
<FilesMatch "\.(html|htm|txt)$">
  Header set Cache-Control "max-age=2700"
</FilesMatch>
</ifModule>

nginx.conf를 다음처럼 설정해볼 수 있다 [A Guide to Caching with NGINX and NGINX Plus, Nginx 캐시 설정 및 캐시 만료일 기간 설정, Nginx Caching]

# cache.appcache, your document html and data
location ~* \.(?:manifest|appcache|html?|xml|json)$ {
    expires -1;
    # access_log logs/static.log; # I don't usually include a static log
}

# Media: images, icons, video, audio, HTC
location ~* \.(?:jpg|jpeg|png|gif|ico|gz|svg|svgz|ogg|mp4|webm|ogv|htc|cur)$ {
    expires 3M;
    access_log off;
    add_header Cache-Control "public", max-age=31536000;
}

# Source File
location ~* \.(?:css|js)$ {
    expires 1M; 
    access_log off;
    add_header Cache-Control "public";
}

# Favicon
location = /favicon.ico {
    expires max;
    access_log off;
    log_not_found off;
}

# Feed
location ~* \.(?:rss|atom)$ {
    expires 1h;
    add_header Cache-Control "public";
}

sane-caching.nginx.conf(gist)에도 잘 나와있다.

php의 경우 다음과 같이 해볼 수 있는 모양이다. [header]

<?php
  header("Cache-Control: public, max-age=31536000");
  //or
  header("Expires: Wed, 15 Apr 2020 20:00:00 GMT");
?>

expressjs를 사용할 경우 web.dev의 문서를 참고할 수 있다.

- meta 태그 사용

과거 브라우저에서 사용하고, 현재는 잘 사용하지 않는 방식.

다음과 같이 사용할 수 있다. [A Dictionary of HTML META Tags]

<meta http-equiv="Cache-control" content="public, max-age=31536000">
<meta http-equiv="expires" content="Wed, 15 Apr 2020 20:00:00 GMT">

- 기한

구글이 제공하는 HTTP Caching 문서에서는 다음과 같이 되어 있다.

HTML: no-cache
CSS: public, max-age=31536000(1년)
JS: private, max-age=315360000
Image: max-age: 86400

JS파일에 개인정보가 없다면 public으로 해도 상관은 없다.

즉, 다음을 고려하여 설정해야 한다.

각 리소스별 최적의 캐시 수명
프록시 캐시 허용 여부

- 기타 주의사항

미래에 만료되는 헤더를 사용하는 경우 구성 요소가 변경 될 때마다 구성 요소의 파일 이름을 변경해야 한다.

이 단계를 빌드 프로세스의 일부로 만들 수 있다.

예를들어 EXAMPLE_2.0.6.js처럼 버전 번호, EXAMPLE_20200402.js처럼 날짜등을 파일 이름에 포함할 수 있다.

webpack의 경우 Caching 문서를 확인해보면 자동으로 생성해준다.[Hash vs chunkhash vs ContentHash]

4.1.4 유효성 검사

개요

분류: server

캐시가 유효하지 않으면(또는 만료되었으면) 다시 서버에 요청을 해야하는 것은 분명하다.

그런데 매번 새로운 파일을 다운받는 것은 비효율적이므로 서버의 파일이 동일한 것인지 유효성 검사를 하면 다운로드를 줄일 수 있다.

Cache-Control: must-revalidate이 명시되어 있거나 만료시간이 가까워도 검증은 필요하다.

유효성 검사 결과 수정되지 않았다면 요청한 리소스 본문대신 304 Not Modified를 보내며, 수정되었다면 200 OK와 함께 새로운 리소스 본문과 새롭게 대체할 유효성 값을 보낸다.

- ETag

ETag (Entity 태그)는 특정 버전의 구성 요소를 고유하게 식별하는 문자열으로 일종의 해시값이라 생각하면 쉽다.

"Entity"는 이미지, 스크립트, 스타일 시트 등 "Component(구성 요소)"라는 또 다른 단어.

ETag는 후에 설명할 Last-Modified(마지막 수정 일자)보다 유연한 엔터티를 검증하는 메커니즘을 제공한다.

유일한 형식 제한은 문자열을 이용하는 것이다.

Etag는 강한 검증, 약한 검증이 존재한다. [HTTP 조건부 요청]

강한 검증은 바이트 대 바이트로 동일한지 보장하는 것으로 MD5같은 해시를 이용한다.

반면 약한 검증은 유사한 경우 버전이 동일하다고 간주하는 것으로 캐시 성능 최적화에 유용하다.

약한 검증으로 쓸만한 것은 날짜 혹은 광고만 다른 페이지.

약한 검증을 하고 싶으면 W/를 앞에 붙이면 된다.

      ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
      ETag: W/"0815"

응답 받았을 때 Etag 값은 If-None-Match 헤더에 포함시켜 전송 후 유효성을 판단한다.

- Last-Modified

Last-Modified는 말 그대로 마지막으로 수정된 날짜를 말하며 Expires의 형식과 같다.

엄밀하지 않기 때문에 약한 검증용으로 사용할 수 있다.(강한 검증은 불가)

응답 받았을 때 Last-Modified 값은 If-Modified-Since 헤더에 포함시켜 전송 후 유효성을 판단한다.

Last-Modified와 Etags의 관계는 Expires와 Cache-Control과 비슷해서 동시에 존재하면 Etags를 우선한다.

- 정리

자, 그러면 처음부터 유효성을 검증하는 과정을 생각해봅시다.

먼저 Etag나 Last-Modified와 함께 온다.

      HTTP/1.1 200 OK
      Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
      ETag: "10c24bc-4ab-457e1c1f"
      Content-Length: 12195

나중에 브라우저가 구성 요소의 유효성을 검사해야하는 경우 If-None-Match나 If-Modified-Since 헤더를 사용하여 ETag나 Last-Modified 값을 원래 서버로 다시 전달한다.

일치하면 304 예제 코드가 리턴되어 이 예제의 응답을 12195 바이트만큼 줄인다.

      GET /i/yahoo.gif HTTP/1.1
      Host: us.yimg.com
      If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
      If-None-Match: "10c24bc-4ab-457e1c1f"
      HTTP/1.1 304 Not Modified

요청과 응답의 관점으로 보자면 [더 빠른 웹을 위하여 - 웹 캐쉬(WEB CACHE)]

요청

유효성(Validation): If-Modified-Since(1.0), If-None-Match
신선도(Freshness): Pragma(1.0), Cache-Control(1.1)

응답

유효성(Validation): Last-Modified(1.0), Entity Tag(1.1)
신선도(Freshness): Expires(1.0), Cache-Control(1.1)

요청과 관련된 추가적인 내용은 강/약한 검증에서 소개했던 HTTP conditional requests에 잘 나와있다.

해결방법

아파치는 FileETag를, Nginx는 etag 지시어를 이용해 조절 가능하다.

단, 서버를 여러대 사용할 경우, etag 값은 달라질 수도 있는데 이 경우 Etag를 제거하거나 inode 값을 빼야 한다.

그렇다면 전체적인 캐싱/유효성 검증은 어떠한 방식으로 결정해야 하는가?

구글에서는 다음 그림을 소개한다.

페이스북의 This browser tweak saved 60% of requests to Facebook를 읽어보아도 좋다.

4.1.5 AJAX/Websocket이나 SPA사용

개요

분류: Content

AJAX는 필요한 내용만 웹서버에 요청해 처리할 수 있다. [Ajax, 데이터전송]

따라서 AJAX를 사용하면 동일한 도메인 내의 페이지를 이동할 때 불필요한 부분을 다운받지 않아 성능에 유리하다.

axios

가 라이브러리로 유명하다.

Websocket

이때 Websocket을 사용한다면 데이터 통신을 더 줄일 수 있다. [HTML5 WebSocket(웹 소켓) 기본 예제 및 설명, Moving Data over the Web: AJAX vs. WebSockets vs. Webhooks]

말그대로 소켓의 역할을 해서 실시간 업데이트에 유리하다.

위 그림에 보이다시피 매번 HTTP 헤더가 필요한 AJAX와 달리 한번만 설정하면 바로바로 통신할 수 있다.

웹소켓의 라이브러리는

socket.io

가 유명하다.

그런데 항상 빠른 것은 아니다. [Speed dilemma of Node.js: Which do AJAX and Socket.IO choose?, HTTP vs Websockets: A performance comparison]

웹소켓은 연결을 설정하는데 약 190ms정도의 시간이 필요하기 때문.

즉,

적은 수의 데이터를 가끔씩 업데이트: AJAX
많은 수의 데이터를 빈번히 업데이트: 웹소켓

이 좋은 방안이라 할 수 있다.

Server-Sent Event도 고려해볼법만 하다. [WebSockets 대신 Server-Sent Events 사용하기]

웹 소켓은 압축, 멀티플렉싱등을 지원하지 않는다는 문제가 있다.

해결방안

AJAX의 문제와 해결

AJAX를 사용시 가장 큰 문제는 주소가 업데이트되지 않아 뒤로가기가 되지 않는다는 점이다. [Ajax를 사용할 때 웹브라우저 "뒤로 가기"의 구현, page-back-example]

일반 링크 vs AJAX

링크
AJAX

이때 해결할 수 있는 방법은 HTML5 History의 pushState()를 사용하는 것이다.

AJAX + pushState

SPA와 렌더링

이러한 AJAX의 장점을 이용해 페이지를 빠르고 부드럽게 렌더링하는 패러다임이 등장했으니 React, Vue, Angular등으로 유명한 SPA다. [Single Page Application vs Multi Page Application, SPA와 SPA 라우팅 원리, Single Page Application & Routing, 서버사이드 랜더링과 SPA 라우팅의 동작원리]

보다시피 AJAX의 통신방법을 잘 써먹고 있다.

그러나 웹페이지 렌더링을 자바스크립트를 이용해 처리해 초기속도가 느리다는 점, AJAX의 특징등 때문에 다양한 렌더링 방식이 등장하게 되었다. [웹에서의 렌더링, 웹렌더링]

가급적 링크의 내용을 참고바람. 절대 시간이 아까운 내용은 없다.

순서대로 Server Rendering, Static Rendering, Client-Side Rendering, SSR+hydration

Server Rendering: 요청한 페이지의 전체 HTML을 서버에서 생성해 로드
Static Rendering: 빌드시 HTML을 생성하여 배포
Client-Side Rendering: 브라우저에서 자바스크립트로 페이지를 렌더링
SSR + Rehydration: 캐시성이 높은 컨텐츠에만 SSR을 적용

정리된 이미지.

장점은 대부분 이해갈테니 간단히 설명해보자.

Full CSR: 서버에서 JS와 CSS를 뿌리면, SPA이 자동으로 만들어진다. 따라서 처음에 HTML과 컨텐츠는 포함이 되어있지 않고, FCP(최초 컨텐츠 포함된 페인트)가 느려지게 된다.
CSR with Prerendering: 나아지긴 했지만, 여전히 FCP에서 문제가 있다
SSR with hydration: 밑에 나오는 SSR의 단점에 이벤트 핸들러가 붙는 시간까지 합쳐야 해서 TTI(상호작용까지의 시간)까지 추가된다.
Static SSR: 빌드 타임에 생성하므로 매우 빠르다. 그러나 동적이지 않다.
Server Rendering: 서버에서 생성하는 과정이 필요하므로, TTFB(최초 바이트까지 시간)에서 문제가 있다.

보다시피 매우 다양한 트레이드오프가 있는 것을 알 수 있다.

일단 Static SSR이 성능만 놓고 보면 최적으로 보인다.

그러나 모두 알다시피 페이지들을 미리 만들어야 하는데 구글의 검색정보 페이지처럼 동적인 요소(구현 문제)가 많거나 사이트의 규모가 매우 큰(서버측 리소스 낭비) 경우는 문제가 있을수있다.

첫번째는 Headless CMS로 어느정도 극복가능하구 [CMS의 새로운 형태, Headless CMS, 헤드리스 CMS]

두번째는 Gatsby의 Deferred Static Generation, Next.js의 Incremental Static Regeneration으로 해결가능하다.

어쨌든 성능측면에서 장점이 많은지 최근 정적인 방법인 JAM Stack!! 이 각광을 받고 있다. [조금만 신경써서 초기 렌더링 빠르게 하기 (feat. JAM Stack)]

그러나 서버 사이드 CMS, 백엔드와 분리되지 않은 서비스, isomorphic rendering으로 운영되는 서비스에서는 사용하기 어렵다고 한다.

물론 가장 좋은 방법은 프로그래시브 렌더링이 되도록 만드는 것.

리엑트 18이 이를 가능하게 만든다. [New Suspense SSR Architecture in React 18, React 18 변경점]

이른바 Selective Hydration라 부르는 물건.

모든 자바스크립트가 로드될 때까지 기다리지 않고 각각의 컴포넌트를 수화할 수 있을뿐만 아니라, 사용자가 상호작용 하는 컴포넌트를 우선적으로 조기에 수화한다!!

렌더링 개선법

CSR의 효율을 최대한 높히기 위해 PRPL(Push Render Pre-Cache Lazy-load) 패턴이 생겼고(물론 우리가 위에서 다루었던 최적화 방법들),

서비스 워커를 사용하면 초기화와 자바스크립트를 사용하지 않은 Navigation에서 스트리밍을 할 수 있다.

아참, MPA의 경우 Streaming Composite Response를 통해 정적 헤더와 푸터등을 캐싱할 수 있다.

MPA에서 SPA처럼

MPA도 AJAX를 사용하면 SPA처럼 렌더링할 수 있지 않을까 싶어 찾아보게 되었다.

그러다 굉장히 흥미로운 구현체들을 보게되었는데 전체 페이지로드를 발생시키지 않고, AJAX를 이용해 페이지의 바뀐부분만 업데이트시키는 방법이었다. [pjax를 이용한 극적인 웹페이지 속도 향상, How We Migrated To Turbolinks Without Breaking Javascript]

쉽게 설명하면

head: 병합
body: 교체

와 같은 원리로 사용된다.

대표적인 라이브러리로는

jquery-pjax

가 있으며 성능향상이 충분하다.

다음은 PJAX 아이디어를 기반한 라이브러리들.

turbolinks

얼마나 효과가 있을지 모르겠으나 기존 SPA와 함께 사용할 수도 있는듯 하다.

재미난 프로젝트를 발견했다.

Hotwire : HTML Over The Wire(긱뉴스)

pjax를 활용했는지 확실치 않지만..

유튜브에서 만든 SPF(Structured Page Fragments)라는 프레임워크도 재미있어 보인다.

4.1.6 AJAX 요청에 GET 사용

개요

분류: server
야후! 메일팀은 XMLHttpRequest의 POST를 사용할 때 브라우저에서 헤더를 먼저 보낸 다음 데이터를 보내는 2 단계 프로세스로 구현 한다는 것을 알게되었다 .

따라서 쿠키가 많지 않은 경우 하나의 TCP 패킷 만 보내면 POST보다 GET을 사용하는 것이 가장 좋다.

IE 기준 최대 URL 길이는 2K이므로 2K 이상의 데이터를 보내면 GET을 사용하지 못할 수 있다.

다음은 일반적으로 말하는 GET과 POST의 장단점. [GET vs. POST]

- GET

장점

고정적인 주소 및 링크를 사용하기 때문에 캐싱 가능
Content-Type이 필요 없으므로(body가 없음) 가벼움, 야후 메일팀이 말한것

단점

길이 제한
주소창에 쿼리 스트링이 보여짐

- POST

장점

객체를 보낼 수 있음

단점

서버로 보내기 전에 인코딩, 전송 후 디코딩 작업
캐싱이 힘들고, 데이터를 2단계에 걸쳐 보냄

- 기타

흥미로운 부작용은 포스팅된 데이터가 없는 POST는 GET처럼 동작한다는 것이다.

HTTP 사양을 기반으로 살펴보면 GET은 fetch(요청)할 때 사용, POST는 수행할 때 사용한다.

CRUD(Create, Read, Update, Delete) 중 Read할 때만 fetch를 하는 개념이므로 GET을 사용하는 것이 맞다는 것이다.

그런데 개발자들이 구분하지 않고 사용하여 미리 링크를 클릭해(GET) 성능 향상을 하려 시도했던 구글 Accelerator(전버전)가 실패한 적이 있다나.

4.2 기타

4.2.1 로드 전 구성 요소

개요

분류: content

프리로드는 포스트로드와 반대되는 것처럼 보이지만 실제로는 다른 목표가 있다. [The Case for Auto-Preloading: The Anatomy of Battle-Tested WPO Treatment, How To Make Users Think Your App Loa보다 ds Faster, Faster Loading Times with Prefetch, Preload and Prerender, Best-ish Practices for Dynamically Prefetching & Prerendering Pages with JavaScript]

컴포넌트를 사전로드하면 브라우저가 유휴 상태 인 시간을 활용하고 나중에 필요한 컴포넌트, 이미지, 스타일 및 스크립트를 요청할 수 있다.

이렇게 하면 사용자가 다음 페이지를 방문 할 때 이미 캐시에 대부분의 구성 요소가있을 수 있으며, 페이지가 사용자에게 훨씬 빠르게 로드된다.

반대로 업로드도 가능하다.

해결방법

- 유형

몇 가지 유형의 사전로드가 있다.

무조건

onload가 발생하자마자 추가 구성 요소를 가져온다.
스프라이트 이미지가 onload후 요청되는 방법에 대한 예는 google.com이 있다.

다운받은 스프라이트 이미지는 google.com 홈페이지에는 필요하지 않지만 연속 검색 결과 페이지에는 필요하다.

조건부

사용자 조치를 기반으로 사용자가 다음으로 향하는 위치를 정교하게 추측하고 그에 따라 사전로드한다.

search.yahoo.com의 검색창에 입력을 시작 후 몇 가지 추가 구성 요소를 요청하는 방법을 볼 수 있다.

업로드도 가능하다는 예를 보이기 위해 설명하자면,

인스타그램은 사용자가 공유할 사진을 고르면 미리 업로드를 백그라운드로 진행하기도 한다.

인스타그램 공유하기

예상

redesign을 시작하기 전에 미리로드한다는 아이디어.

"새 사이트는 멋지지만 이전보다 느리다."라는 말은 redesign 후 흔히 들을 수 있다.

문제는 사용자가 전체 캐시를 사용하여 이전 사이트를 방문하고 있었지만, 새 사이트는 항상 빈 캐시 환경이라는 것이다.

redesign을 시작하기 전에 일부 구성 요소를 사전로드하여 이 부작용을 완화 할 수 있다.

기존 사이트는 브라우저가 유휴 상태인 시간을 사용하고 새 사이트에서 사용될 이미지 및 스크립트를 요청할 수 있다.

인스타그램의 경우 컨텐츠를 순서대로가 아니라 중요도로 예측하여 다운받는다.

SNS이므로 많은 사용자가 좋아하는 컨텐츠에 들어갈 확률이 관심을 적게 받는 컨텐츠보다 높기 때문.

사실 무조건, 조건부, 예상이든 모두 사용자가 사용할 것이라 '예측'하기 때문에 로드한다.

- 기술

리소스 힌트를 사용하면 미리 캐싱을 할 수 있다. [Prefetching, preloading, prebrowsing, Prebrowsing, Best-ish Practices for Dynamically Prefetching & Prerendering Pages with JavaScript, Resource Hint, Web Developer's Guide to Prerendering in Chrome]

Prerender(실험적)

이 중 아직 언급하지 않았던 prerender를 다루어보려 한다.

prefetch와 같이 다음탐색에 요구될 수 있는 자원에 대해 더 빠른 응답에 대한 준비, 실행을 하도록 만든다.

차이점이라면 브라우저가 백그라운드에서 URL을 가져오고 렌더링하여 즉각적으로 보여줄 수 있다. [Document.visibilityState]

문제는 페이지를 통째로 다운받기 때문에 리소스 사용량이 많다는 것.

따라서 거의 무조건 넘어갈 것이라 예상할 때만 이 힌트를 사용해야 한다.

정리

예측되는 도메인: dns-prefetch, preconnect
예측되는 리소스: prefetch
예측되는 페이지: prerender

- 또 다른 활용방법

위에서 나온 예시들 말고 한가지 흥미로운 예측방법을 소개하려한다. [Prerender on hover?]

화면에 링크가 보이거나 마우스를 링크에 올리면 들어갈 확률이 높기 때문에 미리로드를 하자는 것이다.

이를 도와주는 라이브러리가 존재한다. [Quicklink vs Instant.page vs Flying Pages – Why I built Flying Pages]

Quicklink: Viewport 기반
Instant.page: Hover 기반
Flying Pages: Viewport, Hover 둘다
Guess.js: 구글 애널리틱스등의 분석기를 통해 예측

Hover 기반에서 문제는 호버 후 서버응답시간(약 300ms)가 누르는 시간보다 짧을 수 있다는 것이다.

이럴 때는

Premonish

처럼 마우스 움직임을 예측하도록 도와주는 라이브러리를 쓸 수 있다.

한편, 지금까지와 반대로 hoverintent(jQuery plugin)처럼 너무 민감하지 않게 만드는 방법이 필요할 수도 있다. [Faking Hover Intent with JavaScript]

사전에 로드하는 것은 리소스를 소모하는 작업이기 때문.

빠른 페이지 렌더링과 관련된 기술과 융합해 사용할 수도 있다.

[스압/데이터주의] 웹 최적화 방식 모음 - 3.3 UX 트릭

BlaCk_Void — Sun, 14 Feb 2021 18:25:37 +0900

3.3 UX 트릭

객관적인 성능이 올라가는 것이 아니라 사용자가 빠르다고 느낄 수 있게 만드는 트릭들.

UX는 글로만 설명하기 힘든 부분이 많기 때문에 가급적 GIF나 사진자료 통해 직관적으로 이해할 수 있도록 힘을 썼다.

초반에 나오는 것들은 많이들 접해봤겠지만, 후반에 나오는 낙관적 UI(Optimistic UI)와 피츠의 법칙 활용은 일반 개발자에게 상당히 생소한 존재며 흥미로운 방법론들이 많다.

UX에 관심이 있는 사람이 아닐지라도 인사이트를 얻어갈 수 있을 것이다.

3.3.1 웹폰트 로드

개요

분류: Font

앞선 폰트 압축과 서브셋에 이어 로드 최적화를 다루어본다. [웹 폰트 사용과 최적화의 최근 동향, 웹폰트 최적화, 웹폰트 사용하기 (웹폰트 101), A Comprehensive Guide to Font Loading Strategies, Faster Font Loading with Font Events, FOUT, FOIT, FOFT, Optimizing Web Font Rendering Performance, 웹폰트 최적화 기법에 관한 몇가지 이야기]

- 렌더링 차단방식

폰트 렌더링 방식은

FOIT(Flash Of Invisible Text): 텍스트가 보이지 않은 상태(invisible)에서 지정된 폰트로 바뀌며 번쩍임 (크롬, 파이어폭스)
FOUT(Flash Of Unstyled Text): Fallback 폰트(unstyled)에서 지정된 폰트로 바뀌며 번쩍임 (IE)

으로 나뉘어져 있다.

이중 컨텐츠를 먼저 보여는 FOUT 방식이 UX에 좋다.

그러나 글꼴의 자간, 높이 등 서식 때문에 레이아웃이 변경될 수 있다.

- FOUT 사용

font-display 속성

요즘 브라우저들은 font-display를 적용하여 FOUT처럼 사용할 수도 있다.

auto: block과 비슷
block: FOIT처럼 작동, 로딩되지 않을 때는 텍스트를 렌더링하지 않으며(최대 3초) 웹폰트가 로딩되면 적용
swap: FOUT처럼 작동, 우선 Fallback으로 렌더링하고 웹폰트가 로딩되면 적용
fallback: 100ms 동안 렌더링하지 않다가 Fallback으로 렌더링, 3초안에 로딩이 완료되면 완료된 폰트로 아니라면 Fallback 폰트 유지
optional: 100ms 동안 렌더링 하지 않다가 Fallback으로 렌더링, 브라우저가 네트워크 상태를 파악해 웹폰트로 전환여부를 결정

@font-face {
  font-family: 'Awesome Font';
  font-display: swap; /* or auto, block, fallback, optional */
  src: local('Awesome Font'),
    url('/fonts/awesome-l.woff2') format('woff2');
}

@font-face의 font-display를 swap으로 설정하면 된다.

자바스크립트 라이브러리

FOUT 방식으로 로드하도록 도와주는 라이브러리가 역시 존재한다.

이 중에서는 Font Face Observer가 가볍고 성능에서도 낫다고 알려져 있다.

현재 메인테이너가 참여를 안하는 중인데..

풀리퀘스트를 날린 사람이 만든 Font Face Observer ES를 사용하면 트리 쉐이킹을 사용할 수 있으니 요것을 쓰는게 좋을 듯 하다.

Font Face Observer의 사용방법은 간단하다.

Font Loading API

최근에는 아예 Font Loding API가 나왔는데 Font Face Observer와 비슷하다. [Getting started with CSS Font Loading, CSS Font Loading API's FontFaceSet Sample]

대략 다음같이 사용할 수 있다.

var font = new FontFace("Awesome Font", "url(/fonts/awesome.woff2)", {
  style: 'normal', unicodeRange: 'U+000-5FF', weight: '400'
});

// don't wait for the render tree, initiate an immediate fetch!
font.load().then(function() {
  document.fonts.add(font); // add font to document
  document.body.classList.add('fonts-loaded'); // enable font with CSS class
});

- 부작용 보완

그러나 FOUT도 부작용이 존재한다고 하였다.

대표적인 것이 서식에 의한 레이아웃 변경, 그리고 번쩍임이다.

비슷하게 만들기

Font style matcher를 사용해 비슷하게 보이도록 맞추어보자.

그 후, 스타일을 지정해주면 끝.

FOUT 최소화

FOUT이 UX에 좋기는 하나 깜박이는 것은 좋지 않다.

따라서 작은 시간내에 로드가 된다면 깜박이지 않게 만드는 것을 고려할만 하다.

400ms 이내에 전송이 되면 깜빡임 없이 바로 보이게 할 수도 있다.

.fonts-loaded body {
     font-family: 'Nanum Gothic', sans-serif, Lucida Sans Unicode, arial;
}

.blocking-time {
    opacity: 0;
}

.fonts-loaded.blocking-time {
    opacity: 1;
}

document.documentElement.classList.add('blocking-time');
setTimeout(function() {
    document.documentElement.classList.remove('blocking-time');
}, 400)
var font = new FontFaceObserver('Nanum Gothic');
font.load(null, 3000).then(function() {
  document.documentElement.classList.add('fonts-loaded');
});

FOFT(Flash of Faux Text)

모든 웹폰트가 다 다운로드 받은 후, 로드 할 필요는 없다.

만약 관련된 폰트가 먼저 다운로드 받아졌을 경우, 먼저 적용해보는 것도 좋은 방식

예: 시스템 폰트 - 웹폰트 Regular - 웹폰트 Bold/Italic

시스템 폰트(FOUT)

먼저 다운로드된 폰트 적용(FOFT)

모든 폰트 적용

3.3.2 스켈레톤 스크린

개요

분류: Content, CSS

스켈레톤 스크린(Skeleton Screen) 또는 스켈레톤 UI라 부르는 것은 로딩이 조금 더 빠르다고 느끼게 한다. [How to Speed Up Your UX with Skeleton Screens, Improve UX in React apps by showing skeleton UI, Everything you need to know about skeleton screens]

컨텐츠가 로딩될 때까지 둘 중 어느 것처럼 보이는 것이 나을지 생각해보자.

유튜브나 인스타그램 등에서 빈번히 쓰여서 알겠지만 빠르다는 느낌을 준다.

그러나 항상 좋은 선택인 것은 아니다. [The effect of skeleton screens: Users' perception of speed and ease of navigation]

연구에 따르면 스켈레톤 스크린이 인지 속도와 탐색 용이성을 개선하지만, 스피너를 이용하면 처음 사이트에 들어갈 때 기사를 찾는 속도가 빨랐다고 한다.

해결방법

CSS로 제작 할 수 있는 가이드.

CSS로 만들 때 참고할만한 라이브러리, 생성기

리엑트를 사용한다면 아주 좋은 라이브러리들이 존재한다.

특히 React Content Loader는 Create React Content Loader에서 50가지가 넘는 예제와 다양한 옵션으로 스켈레톤 스크린 코드를 만들어낼 수 있다!!

UI 참고용으로 다음 것도 한번 볼만 하다.

ngx skeleton loader(Angular 용)

3.3.3 이미지 자리 표시자

개요

분류: Content

이미지 Lazy Load시 생기는 빈공간에 쓸 방법이 몇가지 있다.[How to use SVG as a Placeholder, and Other Image Loading Techniques(medium), How to create a kick-ass image preview with LQIP]

빈공간: 자리를 채우지 않고, 그대로 나둠
자리 표시자: 빈자리를 채울 때 사용할 만한 아이콘
색 채우기: 이미지를 대표하는 색을 이용해 채우기
가벼운 이미지: 가볍게 만들어진 이미지로 채우기

빈공간은 UX에서 나쁘며, 매번 레이아웃 계산을 해야 하기 때문에 성능에 악영향을 끼친다.

이하 다른 것들의 장단점과 몇가지 변형을 다루어보고자 한다.

- 자리 표시자(Place Holder)

자리표시자라는 이미지 요청을 실패했거나, 기본 아이콘으로도 사용할 수 있어 데이터가 더 필요하지 않으면서 UX를 향상시킬 수 있다.

자리 표시자로 사용할 만한 것은

Placeholder Image & Icons Image

자리표시자 이미지
해당 자리를 나타내는 기본 이미지

자리표시자를 자동적으로 생성해주는 서비스도 있다.[21 of Best Placeholder Image Generator]

이 서비스들 중 하나를 골라 사용하면, 자리표시자 이미지를 동적으로 생성해서 사용하는 것이 가능하다.

예를 들어

<img src="https://dummyimage.com/300x200/000/fff.png">

는 다음 이미지다.

- 색 채우기

상징하는 색(Dominant Color)을 채운 후, 전환하는 예도 있다.[Dominant Colors for Lazy-Loading Images, How Medium does progressive image loading]

전환이 부드럽고, 직관적이며 작기 때문에 트래픽 비용도 크지 않다.

단색

그라디언트

색은

단색
그라디언트

로 나뉠 수 있는데, 아무래도 그라디언트에서 용량이 살짝 커지는 편.

단점이라면 이미지 프로세싱을 통해 색을 뽑아내야 한다는 것.

인공지능 시간에 보던 k-means clustering을 사용하거나, 색상 양자화를 하면 이미지를 대표하는 색을 만들 수 있다.

그 후 base 인코딩으로 내장하면 끝

<img src="data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs="
     data-src="https://s-media-cache-ak0.pinimg.com/474x/50/1b/74/501b74902935b063816ea8e14f460ca0.jpg"
     alt="Ghost In The Shell">

CSS로 그라디언트를 만드는 것은 Gradify(깃허브)에서 확인 가능.

- 가벼운 이미지

역시 전환이 자연스럽기 때문에 사람들은 빠르다고 느낄 수 있다.

실루엣

손실된 저용량 이미지

실루엣을 그리기 위해서는 contour나 node-potrace을 참고하면 된다. [Drawing images using edge detection and SVG animation]

LQIP(Low Quality Images Placeholder)와 SQIP(SVG-based LQIP)를 사용해 블러, 모자이크, 폴리곤 형태의 이미지를 만들 수 있다.

SQIP의 art는 마치 인상파와 야수파를 섞은 종이소재 작품 같다. ㅎㅎ

웹팩의 경우, 다음을 사용해 편히 사용할 수 있다.

CSSConf나 Render Conf처럼 들로네 삼각 분할 (Delaunay Triangulation)을 이용해 삼각 폴리곤처럼 만든 polyserver도 있다.

- 비디오

비디오의 경우 poster 속성을 사용해 재생 전까지 이미지를 보여줄 수 있다.

3.3.4 로딩 인디케이터와 인터렉션

개요

분류: Content

적절한 로딩 인디케이터와 인터렉션은 사용자에게 빠르다고 느끼게 만들 수 있다.[XD 필수 항목: 애니메이션 진행률 표시기의 모범 사례, Everything you need to know about Loading Animations, Improving the UX of Progress Indicators and Feedback Notifications, 모바일 앱에서의 대표적인 애니메이션 활용 방법]

시스템 상태의 가시성은 유저 인터페이스 디자인에서 가장 중요한 원칙 중 하나입니다. 사용자는 사용 중인 시스템에 대해 알고 싶어하는데, 특히 시스템이 한창 가동 중일 때 언제든지 현재 상황을 파악하여 시스템 상태를 파악하길 원합니다. 대기 상태의 애니메이션 진행률 표시기는 작업이 진행 중이거나 로딩되고 있을 때 사용자에게 시스템 상태를 알리는 가장 일반적인 방법입니다.

현재 웹에서 애니메이션이 빈번히 사용되는 것은 아니나 점점 APP화가 되어가는 추세이기 때문에(PWA, SPA등) 나중에는 인터렉션의 중요성이 부각될 것이라 생각한다.

로딩 인디케이터

로딩 인디케이터는 다음의 장점을 가진다.

시스템이 충돌하지 않고, 계속 처리시킴을 알려 안심시킴
사용자가 얼마나 기다려야 하는지 예상가능
사용자가 볼 수 있도록 시각적인 것을 제공

로딩 인디케이터에는 크게 프로그레스 바와 스피너가 있는데 다음과 같이 써야 한다. [Progress Bars vs. Spinners: When to Use Which]

4초이상일 때: 프로그레스바, 아니라면 스피너
1초 미만일 때: 아무것도 사용하지 말기
멈추어 있으면 않됨

프로그레스 바와 스피너

애니메이션과 인터렉션

다음글에서 설명이 매우 잘 나와있어 따로 안해도 될 듯. [[번역]UX에서 적절한 애니메이션효과를 위한 가이드 (2편), 모션으로 사용성 만들기 : 모션 선언문의 UX (2편), ease-out, in; ease-in, out, The ultimate guide to proper use of animation in UX]

해결방법

로딩 인디케이터

로딩 인디케이터는 오래 걸리는 작업에만(약 5초 이상) 사용해야한다. [Stop Using A Loading Spinner, There’s Something Better, Mobile Design Details: Avoid The Spinner]

성능이 좋을 때 로딩 인디케이터를 사용하면, 잠깐 비쳤다 사라져 불안감을 느끼게 하고 기다려야 한다는 사실을 인식하여 느리다고 느낀다.

시계가 똑딱 거리는 것을 보는 것과 마찬가지.

성능을 향상 시키는 것이 가장 좋은 방법
화면에 잠깐 나오는 것은 좋지 않음
전환 애니메이션이나 스켈레톤 스크린을 사용하여 감추는 것을 고려

로딩 인디케이터는 사용자에게 충분한 정보를 직접적/간접적으로 제공해야 한다.

왜 로딩 인디케이터가 표시되고 있는지
오래 걸린다면 얼마나 걸리는지
- 이때, 인식되는 값을 대기 시간과 일치 시켜야 한다.
어떤 작업을 하고 있는지

재밌거나 창의적인 로딩 인디케이터는 사용자의 인식을 분산시킬 수 있다.

눈에 띄는 색상 조합
흥미롭거나 귀여운 아이디어
브랜드 이미지 부여
각종 팁이나 정보 보여주기

정보를 보여주는 것은 게임에서 자주 쓰이는 방식. [pull to refresh airbnb, Case study #01 배달의 민족, 배민키친 로딩, Any one else stuck on creative loading screen?]

네이티브나 간단한 로딩 인디케이터를 사용하는 것도 좋다.

개발 시간 단축(개발자, 디자이너 모두)
처리 리소스를 아낌
사용자는 앱 성능 대신 인터넷 연결 또는 장치 속도에 대해 불평 할 가능성이 높음

네이티브 로딩 스피너 느낌[Mobile Loading Spinners Sketch Resource, SVProgressHUD, Native iOS and Android loading spinner (progress bar indicator) overlay]

개인적으로는 2번째 로딩 스피너를 좋아한다.

ios, android, 웹에 다 적합한 느낌.

마지막으로 로드 인디케이터 동작에 대한 이야기. [Faster Progress Bars: Manipulating Perceived Duration with Visual Augmentations, Does Progress Bars’ Behavior Influence the User Experience in Human-Computer Interaction?, 진행바 속도가 빠르다고 느끼게 만드는 방법, '로딩바 - 프로그레스바'의 비밀]

프로그래스바의 강조를 자주, 스피너라면 회전수를 늘림
세로무늬가 거꾸로 진행하는 것이 더 빠르다 느낌
진행 마지막에 가속화(처음에 느리게, 마지막에 빠르게)

마지막의 가운데 두개가 가장 빠르다고 느낌

애니메이션과 인터렉션

동작 속도

100~350ms 정도
리스트 아이템은 250ms 이하로
이동 시간 때문에 화면이 작은 기기에서는 빠르고, 큰 기기에서는 느리게
작은 요소는 빠르고, 큰 요소는 느리게

동작 가속 [비대칭 애니메이션 타이밍, 사용자설정 easing]

바운스 효과는 제거
명확하고 날카롭게
이징은 항상 사용(선형 동작 보다 가속을 붙혀서)
Ease-in(가속)은 사라질때, Ease-out(감속)은 나타날 때
Ease-in-out(표준곡선, 가속 후 감속) 시 비대칭으로

Ease-in-out 효과를 사용시 애니메이션 곡선도구를 활용해보자.

애니메이션 곡선도구

연출

같은 컨테이너의 요소는 동일한 방향으로
- 표의 경우 대각선으로
같은 컨테이너에서 가능한 적은 요소에만 적용
같은 컨테이너의 요소는 Offset(상쇄, 원래 상태로), Separateness(분리) 되도록
크기 변화가 균일하면 직선, 불균일하면 커브로 이동
- 커브로 동작시, 스크롤 인터페이스 주축(보통 Virtical out)과 일치해야 함
계층화 되었을 시 공간적인 관계를 가짐
- 움직이는 물체끼리는 통과하지 않도록
- 떠오르게 만들시에는 가능
상호작용시 공간적/시간적 계층관계 만들기
사용성이 변경 될 때는 내러티브(이야기, 맥락, 서술)에 맞는 연속적인 상태로
- 문자와 숫자 값은 동적으로 변경
- 보이거나 숨겨질 때 연속적으로
- 현재화면에서 새로운 오브젝트가 생성시 Cloning
- 새로운 오브젝트 생성시 차원 이용
- 모호한 동작시 정적인 상태에서 일시적으로 움직임
- 스크롤 시 2차원적인 공간에 계층구조
- 오브젝트, 공간을 탐색시 연속적이고 공간적이게

여기 이쁘고, 좋은 예들이 존재한다. [다음웹툰의 UX 개편 이야기, UX Design: How to Use Animations in Mobile Apps]

홈 화면 로딩, 탭전환, 리스트 로딩, 페이지 전환

3.3.5 낙관적 UI

개요

분류: Content

낙관적 UI(Optimistic UI)는 작동하는 척 일종의 사기(?, 그냥 블러핑이라 해두자)를 치는 것 이다. [옵티미스틱 UI의 계산된 거짓말, Optimistic UIs in under 1000 words, Being optimistic in UI, The 3 White Lies Behind Instagram’s Lightning Speed, Secrets to Lightning Fast Mobile Design, 3 Tips To Make Your Application Feel Faster]

먼저 작동완료 된 것처럼 표시하고, 나중에 업데이트를 하자는 뜻인데, 절차는 다음과 같다.

기존 방식과 낙관적 UI

이벤트 발생
성공한 것처럼 상태(로컬) 업데이트
요청 시작
오류가 생겼는지 파악, 생겼다면 전 상태로 롤백[기준은 보통 2초]

바로 전에 나왔던 애니메이션 효과를 이용한 방법도 동작하고 있는 것처럼 시간(약 100~350ms)원리이니 일종의 Optimistic UI라 할 수 있겠다.

더 전의 스켈레톤 스크린도 그렇고.

해결방법

예시 및 장점

우선 얼마나 유용한지 예제를 보자.

일반 vs Optismitic UI

간단한 데모예제로는 이런 느낌 정도?

Optimistic UI Comparison

특히 메세징에 유용하다.

먼저 보낸척 표시하고 작은 로딩바가 표시되는 것을 확인가능하다.

맥 iMessage와 인스타그램

인스타그램의 좋아요 표시, Audible의 다운로드 받으며 듣기(스트리밍)도 비슷한 예제.

마지막으로 트렐로 예인데, 웹에서 일반앱급 느낌을 내게 만들어준다.

UI와 서버상태를 비동기로 운영한다고 봐도 무방.

페이스북이나 인스타그램에서 잘 써먹고 있는 기법이라 그런지 잘 짜여진 코드 예제들도 많다.

그리고

react-optimistic-ui-hook

이 정말 편해보인다.

단점 보완

단점은 업데이트중인가, 오류가 났는가를 파악하기 힘들다는 것이다.

따라서 이것역시 UI상으로 표시를 해줘야 한다.

업데이트시에는 로딩 인디케이터나 상태 아이콘을 표시해주고

오류시에는 모달창으로 띄우거나 실패했다는 메세지를 띄울 수 있다. (UX상 후자가 좋음)

사용자가 앱을 꺼서 파악을 못할 경우엔

아이콘에 경고표시를 해주면 된다.

3.3.6 피츠의 법칙과 UI/UX 개선

개요

분류: Content, JS

우선 알아두어야 할 것은 피츠의 법칙(Fitts's Law)이다. [The Glossary of Human Computer Interaction, 피츠의 법칙]

아주 건단하게 설명하자면, 목표지점으로 빠르게 이동하는데 시간이 거리와 목표 폭 사이의 비율에 관한 것이다.

목표B에서 허용하는 너비 W와 거리 D

당연하게 느껴질 수도 있겠지만

너비 W는 크게
거리 D는 작게

만드는 것이 좋다.

해결방법

피츠의 법칙에 대한 이해를 돕기위한 퀴즈가 존재한다. [A Quiz Designed to Give You Fitts(번역)]

이건 정말 원문을 보기 권한다.

오래된 글이라 PC위주의 팁이지만, 잘 사용한다면 웹에서도 충분히 활용가능하다.

적어도 내눈에는 그리 보인다.

- 레이블과 툴바

레이블은 버튼의 일부가 되어 너비가 커지므로 더 빠르게 접근 가능하다.

레이블이 없으면 버튼이 모이게 되는데, 원치않는 버튼을 누르는 것을 막기위해 다가갈 때 속도를 늦추게된다.

Windows32 Toolbars

MacOS Toolbars

- 줄배열과 가장자리 배치

배열을 여러줄이 아니라 한줄이고, 가장자리와 맞닿아 있아면 빠른 접근 가능하다.

한줄로 만들면 방금 언급했던 것처럼 원치않는 버튼을 누르는 것을 막기위해 속도를 늦추는 행위가 사라진다.

여러줄은 한줄로[10 ESSENTIAL TOOLS & TIPS ALL PHOTOSHOP BEGINNERS SHOULD LEARN]

가장자리에 배치하게되면 속도를 늦출이유가 없어 빠르게 누를 수 있다.

가장자리와 맞닿아있게[Reattaching The Toolbar, Perspective Crop Tool Missing]

- 가장 빨리 접근 가능한 위치

오른손잡이 기준, 현재위치, 우측하단, 좌측상단, 우측상단, 좌측하단으로 접근이 빠르다.

어찌보면 당연하겠지만, 현재자리에서 바로 누를 수 있는 것에 접근이 빠르다.

현재자리에서 바로 부를수 있는 대표적인 메뉴가 바로 컨텍스트 메뉴.

현재 위치의 컨텍스트 메뉴(오른쪽 클릭)

사람의 팔 구조상 호를 그리며 움직이게 되는데, 때문에 아무렇게나 움직이다보면 네 귀퉁이에 닿게된다.

이를 이용한 것이 바로 윈도우 시작버튼과 KDE의 화면경계 기능.

윈도우 시작버튼과 KDE 화면경계 기능

역시 구조상의 이유로 우측하단과 좌측상단, 우측상단과 좌측하단순으로 접근성이 높다.

잘만들어졌다고 칭찬받는 삼성 One UI도 이 원칙하에 있다.

패블릿이라 불릴정도로 크기가 커진 스마트폰은 상단에 손이 닿기가 어렵고, 좌우로 접히는 폴더블과 원형태의 스마트워치는 가운데를 터치하기가 어렵다.

때문에 아래 사진들을 보면 하단과 가장자리 위주로 UI가 구성되어있음을 알 수 있다.

삼성 One UI [One UI 2]

- 작업표시줄의 자동숨김

작업표시줄 자동숨김은 비효율적이다.

계속 말해왔지만 화면 가장자리는 접근성이 매우 좋다.

고정된 작업표시줄을 사용하면 수많은 아이콘에 접근할 수 있지만, 자동숨김처리된 작업표시줄을 사용하면 작업표시줄 하나를 접근하기위해 시간을 낭비해야 한다.

또한, 화면 가장자리에 있는 요소를 선택하려할 때 작업표시줄이 나타나 원하는 작업을 못하는 경우가 생긴다.

작업표시줄 헤멤 [How To Hide Windows 10 Taskbar Using A Hotkey]

- 프로그램 드롭다운 메뉴위치

프로그램창 내부보다 디스플레이 상단에 메뉴를 배치한 것이 더 빠른 접근 가능하다.

이유는 역시 화면 가장자리라 접근이 빠르기 때문.

항상 같은 자리에 있을 것이라는 것을 알며, 화면크기가 작을때도 접근하기 좋다.

프로그램 창의 메뉴와 디스플레이 상단 메뉴

- 드롭다운과 탈출각도

메뉴를 누르려고 할 때 각도가 좁으면 실수로 다른 항목을 누르기 쉽다.[Making Menus Escapable]

각도가 좁으면 객체의 너비가 줄어들기 때문.

OS X: 65도, Ubuntu: 50도

또한, 사용자는 텍스트를 대상으로 생각하고 움직일 것이기 때문에 탈출각도와 완전히 틀어진 우분투의 텍스트배치는 실수를 유발한다.

으아.. 화가난다..[Ubuntu Volume Indicator Applet - Maverick (Terrible Design!)]

이를 보완할 몇 가지 방법을 소개한다.

크기 조절

메뉴의 크기를 넓게 만들면 탈출각도가 넓어진다.

하지만, 실제로 메뉴를 탈출하기는 어려울 수도 있다는 점은 고려대상.

시간과 공간의 여유

윈도우는 메뉴가 사라져버리는 것을 10~100ms처럼 여유시간을 두는 방식으로 해결한다. [Hysteresis]

그러나 애플은 탈출각도란 개념을 이용해 직선으로 갈 수 있게 만든다.

무려 80년대(정확히 1986년)에 구현했었다고. [Mac OS X DP2, Hierarchical Menus]

그 후, NeXT와 OS X 초기 팀이 복제에 실패해 잊혀졌다가 더 나은 방식으로 왕귀했다.

무조건 오른쪽의 부채꼴을 유지하는 것이 아니라, 메뉴의 크기를 고려하는 것이다.

추후에 등장할 파트에서 이를 이용해 응답성을 극도로 높힌 흑마법을 선보일텐데 이론적 기반없이 처음 접했다면 감탄을 연발할 것이다.

클릭할 때까지 활성화

메뉴나 다른 공간을 클릭할 때까지 계속 활성화 시키는 방법도 있는데, 이 경우 갈수있는 모든 각도가 탈출각도가 된다.

하지만 어딘가를 무조건 클릭해야 한다는 것은 커다란 단점.

- 원형메뉴

원형 팝업 메뉴는 선형 팝업메뉴보다 접근하기 쉬움

원 주변 조각으로 움직이기 위해 조그만 움직여도 되며, 방향정보를 기억할 수 있기 때문이다.

선형 메뉴 vs 원형 메뉴[New in Drawboard PDF: The Advanced Tools Drawer]

- 선형 팝업 메뉴의 모든 옵션에 접근시간 균일화

옵션의 크기 가속화

포인터에서 멀수록 옵션의 크기를 강하게 주면 된다.

예를 들어 포인터를 멀리 이동시킬수록 더욱 많은 양을 움직이는 식.

모바일에서도 비슷한 방식이 관성 스크롤이란 방식으로 적용되어있다.

쎄게(짧고 빠르게) 스크롤하면 약하게(길고 느리게) 스크롤하는 것보다 훨씬 멀리 움직이지 않은가?

관성 스크롤

ios의 경우 overflow-scrolling을 쓰면 조절이 가능하다.

.scroll-touch {
  -webkit-overflow-scrolling: touch; /* Lets it scroll lazy */
}

.scroll-auto {
  -webkit-overflow-scrolling: auto; /* Stops scrolling immediately */
}

ios에서 지원하는거라 변태 개발자들이 포팅이나 폴리필을 만들었을까봐 안드로이드나 기타 환경에서도 가능한지 여러가지를 찾아봤는데 아직 딱히 마음에 드는 것을 찾지 못했지만, 다음글은 참고할만 하다.[Recreating native iOS scroll and momentum, [번역]iOS10의 프리-패칭 API로 부드러운 스크롤 증진하기, [번역] 미래를 향한 스크롤 (Scroll to the future), Scrolling personality improvements in Microsoft Edge]

빨아들이기

객체에 일종의 중력장이 만들어지면 빨려들어가게 만들면 빨리 움직이더라도(부정확하더라도) 멀리있는 버튼에 접근하기 쉽다.

마치 에임핵처럼(Aim hack?)

모바일에서 비슷한 것을 찾으라면 패스트 스크롤(Fast Scroll)이나 사이드 인덱스바(Side Index Bar)라 불리는 물건.

각 인덱스의 위치가 중력처럼 작용하여 빠르게 이동할 수 있다.

Fast Scroll [Contacts XT - Address Book]

가운데로 위치

하위메뉴들의 중간부분이 계층에서 이동할 수 있게 만든다면, 비교적 균일하게 접근이 가능하다.

중앙에 중요한 메뉴가 위치한다면 팝업이나 컨텍스트 메뉴에 좋은 방법.

평행하게 vs 중앙으로

3.3.7 기타 응답성 개선

개요

분류: Content

이 파트에서는 기타 응답성(Respose time) 개선하는 방법들을 서술한다. [How to create the illusion of faster web pages (while also creating actual happier users)]

앞서 나왔던 애니메이션이 일어날 것이라는 예정을 알려주는 CSS의 will-change 속성, 터치나 포인터 이벤트로 300ms 지연속도를 없애는 것은 대표적인 응답성 개선 방법이다.

여기에서는 기타 응답성 개선 방안들을 다룬다.

- 터치 응답성

우선 중복된 부분으로는 이벤트와 API에서 다루었던 버튼에 터치 상태를 추가하여 300ms의 지연속도를 없애버리는 게 있다. [사이트에 터치 추가]

- 스크롤링 응답성

최근 브라우저들은 파이어폭스의 Async Pan/Zoom(APZ)처럼 Off-thread 스크롤링을 지원해 메인 쓰레드가 막히더라도 스크롤링을 지원한다. [Async Pan/Zoom (APZ) lands in Firefox Quantum, Scrolling on the web: A primer]

apz

원리를 대충 설명하자면, 입력을 받는 쓰레드를 따로 분리해 컴포지터 쓰레드로 전달이 되도록 하여 병목이 일어나더라도 비동기적으로 스크롤을 할 수 있는 것.

이 기술의 파워를 알 수 있는 데모를 2가지 있다.

Demo of page janking(버튼을 누르면 메인쓰레드를 5초간 차단)
Scroll-Behavior(500ms 간격으로 차단)

Off-thread 스크롤링을 지원하는 브라우저라면

첫번째 페이지의 "Junk me!"를 누르고 스크롤링을 하거나 두번째 페이지에서 그냥 스크롤링을 할 때 부드러움을 느낄 수 있다.

그러나 Off-thread 스크롤링을 지원하지 않은 키보드 입력의 방향기를 사용하면 작동이 안되거나(1번째), 끊김이 심함(2번째)을 알수 있다.

이 항목에서는 메인 쓰레드를 막지 않으면서 스크롤이 가능한 방법을 알아보자.

CSS 활용

계속 강조해오는 것이지만, 애니메이션이나 레이아웃들과 관련해서 CSS를 우선적으로 사용하는 것이 좋다.

여기서는 모질라에서 공개한 문서에서 알려주는 예제를 기반으로 살펴도록 하자. [Scroll-linked effects, Asynchronous scrolling in Firefox, 5 things you don't need Javascript for]

scroll-behavior를 smooth로 설정하면 항목끼리 부드럽게 움직일 수 있다.

앞서 Scroll-Behavior의 Scroll up과 Scroll down 버튼을 눌러보면 알겠지만, 위아래로 부드럽게 움직인다.

두번째는 posion을 어느 상한선에서 고정시키는 sticky.

밑의 예제에서 스크롤시 Javascipt로 제작한 것은 깜박이고, 버벅이고 난리를 치나 CSS는 고고하게 자리를 지킨다.

position-sticky(역시 500ms 간격으로 차단)

CSS Scroll Snap을 이용하면 CSS만으로 한화면씩 전환하는 테크닉을 만들 수 있다. [Practical CSS Scroll Snapping, Well-Controlled Scrolling with CSS Scroll Snap]

Snap (Javascript, Pure CSS)
The scroll-snap-* Properties.

마지막으로 시차(parallax)를 두고 스크롤링을 하는 것인데 화려한 사이트에서 곧잘 볼 수 있다. [Practical CSS Parallax, CSS 로만 구현한 Parallax Scroll 원리 메모]

구현이 살짝 복잡해지기 때문에 위 사이트들을 확인바란다.

CSS mix-blend-mode & Awesome parallax scrolling, Landscape parallax using CSS

A grouped pure CSS parallax demo by Keith Clark

링크의 코드들이나 리스트에 있는 링크의 Debug 버튼을 눌러보면 원리를 이해하는데 커다란 도움이 되리라 확신한다.

이벤트 위임

이벤트를 위임하여 처리할 때 event.preventDefault와 같은 패턴이 들어갈 수 있다. [event.preventDefault()를 활용한 이벤트 취소 방법, JavaScript에서 이벤트 전파를 중단하는 네가지 방법]

그러나 body 영역 모두에서 이벤트가 취소가 되버리는 불상사가 일어날 수 있다.

document.body.addEventListener('touchstart', event => {  
    if (event.target === area) {
        event.preventDefault();
    }
});

Scroll jank due to touch/wheel handlers demo

이는 passive 속성을 true로 바꾸면 preventDefault를 호출하지 않아 성능개선이 가능하다. [Improving scrolling performance with passive listeners, 스크롤 성능 개선을 위해 패시브 이벤트 리스너를 사용하는 사이트, { passive:true } 의 진정한 의미]

이벤트 핸들러의 실행이 완료될 때까지 기다리지 않고 계속 스크롤을 할 수 있는 것이다.

document.body.addEventListener('touchstart', event => {  
    if (event.target === area) {
        event.preventDefault()
    }
 }, {passive: true});

응답성이 나아진 것을 확인 가능하다.

만약 preventDefault를 쓰고 싶다면 event.cancelable로 취소가 가능한지 확인해보거나

document.body.addEventListener('pointermove', event => {  
    if (event.cancelable) {
        event.preventDefault(); // block the native scroll
        /*
        *  do what you want the application to do here
        */
    }
}, {passive: true});

아예 touch-action, pointer-events와 같은 CSS로 이벤트 핸들러를 제한할 수 있다.

#area {
  touch-action: pan-x;
}

아예 다른 방법도 있다.

MDN의 Pointer Events를 읽다보면 스크롤 차단을 피할 수 있게 만들어졌다고 나온다!! [Using Pointer Events, Building a great touchpad experience for the web with Pointer Events]

Pointer capture allows events for a particular pointer event to be re-targeted to a particular element instead of the normal hit test at a pointer's location. This can be used to ensure that an element continues to receive pointer events even if the pointer device's contact moves off the element (for example by scrolling).

Comparison of Pointer and Touch Event Scroll Initiation GIF

여러모로 포인터 이벤트는 정말 좋으니 잘 써먹도록 하자.

requestAnimationFrame 활용

입력 핸들러는 request AnimationFrame 콜백 직전에 실행되며, 이때 스타일을 변경하면 강제동기 레이아웃이 발생한다.

만약 디바운스처리를 할 수 있다면 스크롤시 응답성이 향상되겠죠. [JS 지연처리: 디바운스와 스로틀, 스로틀(throttle)과 디바운스(debounce)]

function onScroll (evt) {

  // Store the scroll value for laterz.
  lastScrollY = window.scrollY;

  // Prevent multiple rAF callbacks.
  if (scheduledAnimationFrame)
    return;

  scheduledAnimationFrame = true;
  requestAnimationFrame(readAndUpdatePage);
}

window.addEventListener('scroll', onScroll);

- 메뉴 응답성 높이기

앞서 흑마법이라며 칭송했던 것이 드디어 나왔다!! [아마존의 메가 드롭다운 메뉴 분석]

더보고 말것도 없다. 일단 보자.

정말 레이턴시가 없고 미친듯이 빠르지 않은가??

처음봤을 때 솔직히 감동 받았다. ㅠㅠㅠ

원리는 당연하게도?

파란 삼각형 내부로 움직이면 유지, 밖이면 탈출하여 다른 메뉴를 보여주는 것.

지금까지 본 UX 트릭중 가장 감동받은 것.

몇년전 이 글 때문에 UX에 관심을 가지게 되었다.

jQuery-menu-aim(Demo)이 원조고 이를 기반 혹은 비슷한 라이브러리들이 만들어졌다.

menu-aim(port to vanilla): Demo
ReactMenuAim(port to react): Demo
React Aim: Demo
Amazon-like Multi Level Responsive Dropdown Menu
typescript-menu-aim

빠른 것들을 쓰다가 이제 보편적인 메뉴(라고 쓰고 전투력 측정기라고 읽는 것)들과 비교해보자.

CSS로만 멀티레벨 메뉴를 구현해도 빠르긴 하지만

범위를 벗어나면 꺼져버리니 느린것만 못한 UX.

유명한 이커머스 업체인 쿠팡에서도 이를 적용하고 있는듯 하다.

쿠팡

최근에는 KDE에도 적용되었다. [Implement a triangle menu filter for Kickoff's categories sidebar, Introduce TriangleMouseFilter]

응답성에 관련된 글을 찾다보니 재귀적인 setTimeout을 이용한 기법이 나오는데 현대 브라우저 기준으론 비효율적인 아이디어라 생각한다. [응답없는 페이지가 되지 않게 하는 법 (feat. setTimeout), 스케쥴링: setTimeout and setInterval]

let i = 1;
setTimeout(function run() {
  func(i);
  setTimeout(run, 100);
}, 100);

오래 걸리는 작업은 워커 쓰레드를 이용해처리하고 메인쓰레드에서 꼭 유지시킬 필요가 있다면 requestIdleCallback을 사용하는게 낫다고 본다.

그래도 +로 적었으니 팁을 적자면

Timer Resolution이 윈도우(15ms), 리눅스(10ms)정도가 되며, 브라우저에서 setTimeout(4ms)와 setInterval(10ms)의 각지연이 더 필요하다. [Windows Timer Resolution: Megawatts Wasted, High Resolution Timers, Timer resolution in browsers]

따라서 약 25(15 + 10)ms보다 짧은 간격을 사용하는 것은 권장하지 않는다.

그런데 25ms만에 끝날작업은 애초에 응답성 향상을 위해 재귀적 setTimeout을 이용한 기법을 사용할 이유가 없으며, 커다란 작업을 하기에는 타이머가 너무 빈번히 일어난다고 생각한다.

250ms나 500ms 정도로 넉넉하게 간격을 두고 처리하고, 타이머를 여러개 설정해버려서 경쟁하지 않도록 하는 것이 좋을 듯.

[스압/데이터주의] 웹 최적화 방식 모음 - 3. Layout 및 렌더링

BlaCk_Void — Sun, 14 Feb 2021 18:25:29 +0900

3. Layout 및 렌더링

Layout 발생 빈도 최소화 및 비용 최소화와 CPU 처리 효율화, UX 트릭으로 나뉜다.

레이아웃에 영향을 미치는 것들에 대한 정리는 What forces layout/reflow란 글이 잘 설명해준다.

3.1 발생 빈도 최소화

3.1.1 CSS 속성

개요

분류: CSS

이야기가 나온김에 리플로우에 영향을 미치는 유명한 CSS 요소들을 뽑아보자면 [CSS Triggers, 20 Tips for Optimizing CSS Performance]

창 크기 조정
폰트 변경
CSS 추가와 삭제
input 에 입력시 내용 변경
CSS 가상 클래스 활성화
클래스 속성, 스타일 속성과 DOM 조작
offsetWidth, offsetHeight 계산

이 있다.

그리고 재계산을 유발하기로 유명한 속성은 다음이 있으며 불필요하게 값을 수정하지 않는게 좋다.

border-radius
box-shadow
opacity
transform
filter
position: fixed

보통 JS-리플로우(Layout)-페인트-컴포지터의 과정으로 렌더링이 되기 때문에 동일한 동작을 수행시

컴포지터를 업데이트하는 것이 페인트가 필요한 것보다 낫다.

또한 비용이 크다고 알려진

background-repeat
각종 그라디언트

들도 사용하지 않는게 원칙적으로는 좋다.

성능을 위한 엄격한 하위집합들은 AMP나 Cobalt의 예에서 볼 수 있다.

++.

CSS를 동적으로 수정해야 할 일이 있다면 직접 CSS 속성을 제어하기보다는

클래스의 추가/제거하는 것이 좋다.

+++.

CSS 이미지 교체 관련 기술 [Nine Techniques for CSS Image Replacement]

3.1.2 DOM 액세스 최소화

선행지식

DOM 모델에 대한 글들을 읽어보자

개요

분류: Javascript

JavaScript로 DOM 요소에 액세스하는 속도가 느리다.

DOM과 관련된 영향을 고려하며 프로그래밍 해야한다.

부모-자식 관계: 부모 엘리먼트가 가변적인 크기를 가질 때 자식 엘리먼트의 크기를 수정하면 부모에게 영향
같은 위치: 여러 엘리먼트가 인라인일때 첫 번째 엘리먼트의 크기 수정으로 나머지 엘리먼트에 영향
숨겨진 엘리먼트: 숨겨진(display: none) 스타일이면 돔 조작이나 스타일 변경시에도 레이아웃, 리페인트가 생기지 않음
visibility: hidden일 경우 리페인트는 발생하지 않아도 레이아웃은 계산

그리고 다음 같은 원칙을 생각해볼 수 있다. [DOM access optimization, 무한 DOM 렌더링 최적화 경험기, html5 성능최적화 방법들, DOM creation and manipulation tips and tricks, Javascript DOM Manipulation to improve performance, Taming huge collections of DOM nodes, DHTML 속도 향상을 위한 몇 가지 팁]

DOM 연산 결과 캐싱
접근했던 요소(element)에 대한 참조를 캐시
DOM 변경 시 개별 노드단위 반복변경보다는 배칭 작업
DOM 노드 변환은 오프라인에서 수행
노드(node)는 오프라인으로 업데이트 한 다음 트리에 추가(변경노드 떼기 -> 연산 -> 붙이기)
JavaScript로 레이아웃을 고정하지 않기

- 강제 동기 레이아웃 및 스래싱 피하기

레이아웃은 원래 비동기적이지만, 특정 속성을 읽을 때 최신 값을 계산하는 등 레이아웃이 동기적으로 발생할 때가 있다. [크고 복잡한 레이아웃 및 레이아웃 스래싱 피하기, Preventing 'layout thrashing]

스타일 변경 후 offsetHeight나 offsetTop처럼 계산된 값을 속성으로 읽을 때가 대표적인 예.

연속적인 강제 동기 레이아웃이 발생해 레이아웃 스래싱[한글]까지 발생하면 성능은 더욱 저하된다.

DOM 트리 상위노드를 변경시 하위 노드에 영향

이므로 변경범위를 최소화 한다는 것을 고려하도록 하자.

해결방법

- DOM 연산 결과 캐싱

DOM에 접근하는 것을 매번 이용하는 것은 좋은 선택이 아니다.

document.getElementById('box').style.top = "10px";
document.getElementById('box').style.left = "10px";
document.getElementById('box').style.color = "lightgrey";

어찌보면 당연하겠지만, 변수로 만들어놓으면 된다.

const boxSty = document.getElementById('box').style;
boxSty.top = "10px";
boxSty.left = "20px";
boxSty.color = "lightgrey";

HTMLCollection처럼 실시간 업데이트되는 것도 마찬가지.

HTMLCollection의 여러값들에 지속적으로 접근해야 하는 경우 Array로 바꾸는 것도 고려할만 하다. [Most efficient way to convert an HTMLCollection to an Array]

lodash의 template()같은 것도 캐싱이 가능하다. [JavaScript Performance: Pre-Compiling And Caching HTML Templates]

- 개별노드 변경보다 배칭 작업

개별 노드를 반복변경하기보다 배칭(Batching, 일괄처리)을 하는 것이 좋다.

유니티 같은 엔진에서 잘 사용하고 있는 기법. [드로우 콜 배칭, Dynamic Batching이 효율적인가]

이때도 중간에 너무 많은 계산을 하지 않는 것이 좋긴하다.

Main UI thread를 막을 수 있기 때문.

CSS 활용

앞선 예제는 CSS를 사용해 한번에 업데이트가 가능하다.

const boxSty = document.getElementById('box').style;
boxSty.classList.add('boxstyles')

.boxstyles {
  top: 10px;
  left: 20px;
  color: lightgrey;
}

DocumentFragment 활용

다음코드에서 appendChild(쓰기)와 getBoundingClientRect(읽기)의 최적화가 목표.

function noBatch(elements) {
  elements.forEach(el => {
    // This is alternating write and read
    this.parentElement.appendChild(el);
    el.getBoundingClientRect();
  });
}

DocumentFragment를 사용하면 리플로우를 일으키지 않으며 처리가 가능하다. [JavaScript DocumentFragment]

function batch(elements) {
  // First write
  const fragment = document.createFragment();
  elements.forEach(el => {
    fragment.appendChild(el);
  });
  this.parentElement.appendChild(fragment);
  
  // Then read
  elements.forEach(el => {
    el.getBoundingClientRect();
  });
}

DOM 노드 변경은 오프라인으로

많은 수의 DOM을 조작해야 한다면 DocumentFragment와 마찬가지로 직접적인 돔 조작을 줄여야 한다.

이때 생각해볼 만한 것은

DOM에서 때어냄
연산
다시 붙임

의 과정을 수행하는 것이다.

jQuery의 detach()가 대표적인 예.[제이쿼리 성능 향상하기(performance), 다른 삭제와 비교]

바닐라의 경우 ba-detach.js를 참고하면 될 듯.

뭐 사실, GTK의 Pixmap(페인트가 필요 없음)과 Pixbuf(X11 서버에 접근 불필요) 같은 것을 보면 새로운 개념은 아닌듯 하다.

- 강제 동기 레이아웃 및 스래싱 피하기

offsetWidth처럼 강제 동기 레이아웃 속성들은 되도록 사용하지 않는 것이 좋다.

하지만 써먹어야 하는 경우가 있기에.. 몇가지 예를 들어본다.

순서변경

다음 코드는 box의 너비(Width)를 기록하기 위한 코드이다.

// Schedule our function to run at the start of the frame.
requestAnimationFrame(logBoxWidth);

function logBoxWidth() {
  box.classList.add('super-big');

  // Gets the width of the box in pixels
  // and logs it out.
  console.log(box.offsetWidth);
}

코드를 보면 높이를 요청하기 전에 box의 클래스를 바꾸었기 때문에 스타일 변경이 적용되어 있어야 하는 상황.

스타일 변경후의 결과를 위해 강제적으로 레이아웃이 동기화가 되어야 한다는 것을 알 수 있다.

만약 다음처럼 순서를 바꾼다면, 전 프레임의 레이아웃 값을 사용할 수 있어 비용을 아낄 수 있다.

function logBoxWidth() {
  // Gets the width of the box in pixels
  // and logs it out.
  console.log(box.offsetWidth);

  box.classList.add('super-big');
}

변수로 선언

매번 offsetWidth를 호출하면 스래싱이 생겨서 성능이 확 줄어든다.

function resizeAllParagraphs() {
  for (let i = 0; i < paragraphs.length; i += 1) {
    paragraphs[i].style.width = box.offsetWidth + 'px';
  }
}

역시, 변수처리를 하면 해결되는 부분.

function resizeAllParagraphs() {
  const width = box.offsetWidth;

  for (let i = 0; i < paragraphs.length; i += 1) {
    paragraphs[i].style.width = width + 'px';
  }
}

추가 및 innerHTML

innerHTML과 성능에 관한 글들이다.

오래된 글들이 좀 있기 때문에 최근 소프트웨어들에서 벤치마크가 필요할 수도 있다.

전반적으로 insertAdjacentHTML이 빠른듯

삭제

요소 삭제 관련이며 유의점은 위와 같다.

탐색

DOM 탐색 관련 글. 역시 유의점은 같음.

TreeWalker는 처음 들어봐서 약간 찾아봤다.

히든 탭일때

Document.hidden 여부에 따라 비용이 많이드는 로직은 실행하지 않을 수 있다. [Speed up your ClojureScript Webapp]

생각치 못한 트릭.

- 라이브러리

레이아웃 스레싱

레이아웃 스레싱 문제를 해결하기 위해 DOM을 자동으로 읽고 써주는 [Preventing 'layout thrashing']

FastDOM

을 사용할 수 있다.

AMP의 Vsync 클래스도 비슷한 원리인듯. [AMP는 어떻게 웹 페이지의 성능을 높일 수 있나]

리엑트18은 각종 상태, 이벤트등을 모두 Automatic Batching 한다!!

DOM 조작

jQuery 독점기를 깨고 나오는 각종 라이브러리들은 돔조작을 간편하고 효율적으로 만드려고 눈물나는 노력들의 산물이다. [Change And Its Detection In JavaScript Frameworks, React Virtual DOM vs Incremental DOM vs Ember’s Glimmer: Fight, JavaScript vs JavaScript. Fight!, Die Rendering-Engines von React, Angular und Ember im Vergleich]

Backbone.js, Ext JS, Dojo는 데이터 모델의 상태를 변경하여 반영하려했는데, 변경의 이벤트의 대해 다시 렌더링을 해야할지 결정하고 해결해야하는 것은 프로그래머가 해야 한다.

Ember.js는 데이터 바인딩을 통해 이벤트가 수행할 리스너를 등록하여 동기화를 편하게 만들었다.

AngularJS는 더티체크를 수행하여 마지막 순간에서 변경되었는지를 체크한다.

그러나 매번 참조한 값이 변경되었는지 확인하는 것은 빈번히 재렌더링이 발생할 시 비용이 크다.

Angular는 Zone을 이용한다.

thoughtram란 블로그에 Angular 구조 및 성능과 관련된 좋은 글들이 많다.

Taking advantage of Observables in Angular[part1, part2]

React는 매우 가벼운 Virtual DOM을 매번 생성 후, 비교후 실제 돔조작을 하는 방식이다.

장점은 변경사항을 추적할 필요가 없다는 것.

만약 리엑트와 앵귤러 렌더링 방식의 차이점을 알고 싶다면 다음 링크들을 참고할만 하다. [2020년과 이후 JavaScript의 동향 - 라이브러리와 프레임워크 1, 프론트엔드 개발자가 알아야 하는 Angular와 React의 Change Detection(영문), Angular vs. React: Change Detection]

기타 리엑트 스타일의 가벼운 라이브러리들. (보통 Diff 알고리즘을 개선했다고 알려져있다. #10703 A faster diff algorithm)

Preact: 이 중 가장 유명한 걸로 안다.
Inferno: 메모이즈, 노멀라이징, 마이크로레벨 최적화
Ivi: Directed Graph와 Observable을 사용해 더티체킹
Fre: 리엑트처럼 Concurrent 모드를 지원
Nerv: 빠른 결정적 Diff
Crank: 제네레이터와 비동기함수(프로미스)를 JSX에서 지원

Ember의 Glimmer 엔진에는 Virtual DOM에서 영감을 받은 Stream Tree를 이용해 변경점을 업데이트하고, Incremental DOM는 실제 DOM과 메모리상 DOM을 비교하여 업데이트 한다.[Incremental DOM 101: What is it and why I should care?]

Om이나 Reagent는 변경이 안된 것들을 Persistent 데이터구조를 이용해 파악하여 재사용하여 성능에 이점이 있다.[Understanding Clojure's Persistent Vectors, pt. 1, Persistent Data Structures and Managed References]

단점은 사람들이 익숙하지 않은 LISP 계열의 Closurescript를 이용한다는 것.

이 아이디어는 불변성을 관리하는 라이브러리인 Immutable JS, Immer를 탄생시켰고, Angular에도 적용되고 있다. [Change Detection in Angular 2]

자료들을 읽다보면 알겠지만 Reactive한 Signal-Graph를 만들어 성능 개선을 할 수도 있다. [Why React & re-frame are fast in 8 Performance Hacks(영상), Re frame]

Reactive하기 때문에 즉시 업데이트가 필요한지 알 수 있으며(예를 들어 Angular는 주기적으로 CD를 한다),

Signal-Graph로 이루어져 즉시 전파가 된다. (상태 전파를 파악하고 중복되는 변화등을 막음, Reactive 자체로는 성능 향상이 크지 않고 Signal-Graph가 핵심)

이 아이디어는 비교적 최근에 나온 페이스북의 상태관리 라이브러리인 Recoil에도 적용된듯 하다. [Recoil - 또 다른 React 상태 관리 라이브러리?(다른 번역 버전), Recoil: 왕위를 계승하는 중입니다 (새로운 React 상태 관리 라이브러리)(PDF), Recoil: A New State Management Library Moving Beyond Redux and the Context API]

세분화된 반응형 프로그래밍에 대한 좋은 글들

자료를 찾다가 벤치마크 자료를 보게 되었는데 몇가지 흥미로운 프레임워크가 존재한다.[A RealWorld Comparison of Front-End Frameworks 2020]

Elm과 최근에 뜨고 있는 Svelte가 그 대상이다. [Blazing Fast HTML(Round 1, Round 2), Elm — 웹 앱 전문 함수형 프로그래밍 언어]

이중 Elm의 아키텍처는 언어적으로 상태관리를 하도록 만들어 Hyperapp등에도 영향을 주었다. [Subscriptions, The Elm Architecture (TEA) animation, Everything You Need To Know About Hyperapp JS]

개인적으로 Elm의 아키텍처를 가장 쉽게 풀어낸 것이 Apprun이나 re-frame인 듯하다. [AppRun - Architecture, Re-frame - A Data Loop]

React에서는 elm-ts란 라이브러리나 react-use-elmish 훅을 이용해 elm을 흉내낼 수 있다.

사이드 이펙트 관리가 좋아지는 듯?

이와 다른 접근법으로 게임개발에서 쓰이는 ECS(Entity Component System) 패턴이라는 것이 존재한다. [DOTS 기술 소개: 엔티티 컴포넌트 시스템, Entity Component System, Data Oriented vs Object Oriented Design, Introduction to Data-Oriented Programming, Introduction to Data-Oriented Programming(FrostBite)]

ECS Pattern

데이터가 모여있어 캐싱(지역성)이 유리하고, 병렬로 처리하기도 좋은 편이다.

물론 웹에서 사용해보려는 시도가 존재한다. [Entity Component Systems For The Web, TodoMVC implemented using a game architecture — ECS]

ECS 패턴을 구현한 라이브러리에서는 WolfECS가 가장 빠른 듯

상태머신으로 상태들를 다루려면 Xstate도 한번쯤 살펴보는 것도 좋다. [Finite state machine & statecharts – XState, Boost your React application’s performance by Xstate, Welcom to the world of Statecharts]

컴포넌트/템플릿의 최적화와 관련 있는 프로젝트들도 존재한다.

Svelte의 목표는 컴포넌트들을 컴파일하여 매우 효율적인 코드로 변환해 Virtual DOM의 오버헤드를 제거하자는 것이다.[Frameworks without the framework: why didn't we think of this sooner?, Virtual Dom is pure overhead, Svelte 3: Rethinking reactivity, svelte가 빠른 이유, Svelte CheetSheet, The Svelte Compiler Handbook]

최근 malina라고 svelte와 비슷한 프로젝트, vdom의 컴파일인 million도 있다.

Svelte

사실 Ember의 Glimmer 엔진은 비슷하지만 완전 다른 접근법을 가지고 있다.[Glimmer: Blazing Fast Rendering for Ember.js(part1, part2), The Glimmer VM: Boots Fast and Stays Fast, The Glimmer Binary Experience]

컴파일? 과정

Ember의 템플릿 형식인 Handlerbar를 이용해 AST를 만든뒤, OP코드 형태와 같이 스트림 목록으로 만들고 최적화를 수행한다.

우리는 효과적으로 프로그래밍 언어와 기본 런타임을 설계하고 있기 때문에 JIT 컴파일러와 바이트코드 인터프리터와 같이 언어 구현을 프로그래밍할 때 잘 확립된 원칙을 사용하여 그것을 설계해야 한다. VM 아키텍처를 구축하면 constant folding, 인라이닝, 매크로 확장 등과 같은 잘 알려진 최적화를 보다 쉽게 구현할 수 있을 것이다.

정적, 동적인 템플릿을 구분하여 최적화가 수행된다.

Virtual Dom과 Svelete 방식의 사이 느낌이랄까?

Svelte부터 시작해 좋은 성능을 내는 라이브러리들 중 Virtual Dom을 사용하지 않는 경우가 많아지고 있는 듯 하다. [Virtual DOM is pure overhead, The Fastest Way to Render the DOM]

앞서 이야기한 Reactive Signal-Graph 방식으로만 업데이트하는 경우도 있고,

Solid: Fine-Grained Reactive Graph 사용
Surplus: 컴파일하며, S.js를 이용해 돔을 업데이트
Sinuous: Surplus와 비슷한데 역시 더 빠르다. Reactive/Observable 기반
Domc: Top-Down 방식으로 Diff
Stage0: Domc의 아이디어 바탕이라는데 더 빠르다는 듯
blockdom: Element 단위가 아니라 Block 단위로 비교

Domc처럼 diff 관련 라이브러리도 있는데 diff쪽은 udomdiff(관련글), nanomorph, x-tree-diff-plus(논문), A* Tree Diff, 스택오버플로우, 네이버 list-differ도 흥미로운 듯.

앵귤러나 리액트도 최적화를 시키려는 움직임이 있다. [Angular {{AOT vs JIT}} vs React compiler: Part — I, Ahead-of-Time Compilation in Angular, Angular vs. React: Compilers]

앵귤러는 AOT 컴파일을 도입하며, 리엑트는 Prepack을 이용하거나 Svelte처럼 직접 변환하는 식(rawact, ecmacomp)

추가적으로 Solid의 저자가 쓴 컴파일과 컴포넌트 관련 글들이 인상깊다.

A Look at Compilation in JavaScript Frameworks
The Real Cost of UI Components
Components are Pure Overhead [Svelte의 Virtual DOM is pure overhead 따라하기인듯 ㅋㅋ]

lit-html, hyperHtml처럼 템플릿 리터럴을 이용하기도 한다. [lit-html vs hyperHTML vs lighterhtml]

일반 Virtual DOM에 비해 주된 성능 향상 원리는 템플릿 리터럴을 사용하기 때문에 정적, 동적인지 판별하기 쉬워 변화가 생기는 문자열만 업데이트하고 innerHTML로 렌더링을 하는 것이다. [HTML templating with ES6 template strings, lit-html, JavaScript templating from the Polymer team at Google, A night experimenting with Lit-HTML…, A bit about lit-html rendering]

lit-html의 방식

h1, h3태그가 새로 생성되는 Preact와 달리 수정만 되는 모습을 볼 수 있다.

Mikado라는 템플릿 엔진의 성능도 주목할만 했다. [JS Framework Benchmark]

Recycle, Reuse를 극대화하며 독자적인 Diff 알고리즘을 사용했다나.

아무튼 팩토리 풀, 템플릿 풀, 키 풀, 라이브 풀로 이어지는 풀링 시스템이 특이하다.

Neo라 하여 추후 나올 워커의 사용을 극대화한 프레임워크 또한 존재한다. [Create Blazing Fast Multi-Threading User Interfaces Outside Node.js]

일반 프론트엔드 아키텍쳐

일반 워커와 Shared 워커 아키텍처

마지막으로 또 다른 특이한 프레임워크인 Qwik.

재개가 가능하며, 세분화된 lazy loading이 가능하다고 한다.

Hydration is Pure Overhead (또 다른 Pure Overhead 시리즈, HN 토론)

3.1.3 이벤트 핸들러를 잘 개발하기 with API

개요

분류: Javascript
DOM 트리의 다른 요소에 너무 많은 이벤트 핸들러가 첨부되어 너무 자주 실행되거나 실행 간격이 크기 때문에 페이지의 응답성이 떨어지는 경우가 있다.

이벤트를 사용하지 않으면 해제시켜주고, Observable을 subscribe했으면 unsubscribe를 해줘야한다.

해결방법

- 이벤트 위임

이벤트 위임(event delegation)을 사용 하는 것이 좋은 방법. [왜 이벤트 위임(delegation)을 해야 하는가?, 이벤트 버블링, 이벤트 캡처 그리고 이벤트 위임까지, Event Delegation, Event Bubbling and Event Catching in JavaScript and React – A Beginner's Guide]

안에 10 개의 버튼이있는 div경우 각 버튼마다 하나의 핸들러 대신 하나의 이벤트 핸들러만 div 래퍼에 연결하는 방식을 쓰자.

이벤트 핸들러가 너무 많으면 반응속도가 느려진다.

이벤트가 버블업되어 이벤트를 포착하고 이벤트가 시작된 버튼을 파악할 수 있다.

리엑트에서는 합성 이벤트(SyntheticEvent)에서 자동적으로 위임을 하여 수동으로 하지 않아도 된다. [Should I use event delegation in React?, React에서 이벤트 위임을 통한 이벤트 리스너 최적화]

또한 이벤트 풀링(Pooling)을 하여 최적화를 하였는데 모던 브라우저에서 이득이 없어 v17부터 제거 되었다. [Remove event pooling in the modern system, 리액트를 처음부터 배워보자. — 06. 합성 이벤트와 Event Pooling]

stopPropagation()과 preventDefault()로 위임을 제어할 수 있다.

- onload vs DOMContentLoad
DOM 트리로 무언가를 시작하기 위해 onload 이벤트를 기다릴 필요가 없다.

트리에서 사용할 수 있도록 액세스하려는 요소만 있으면 된다.

모든 이미지가 다운로드 될 때까지 기다릴 필요도 없다.

Web Page Load Time

DOMContentLoaded는 onload 대신에 사용할 수 있다. [문서의 로드시점 - onload, DOMContentLoaded, DOMContentLoaded vs load]

자세한 정보는 Julien Lecomte이 작성한 "High Performance Ajax Applications"를 참고.

- requestAnimationFrame(), requestIdleCallback() 사용

requestAnimationFrame과 requestIdleCallback을 사용하면 작업을 작은 조각으로 나누어 처리할 수 있다. [시각적 변화에 requestAnimationFrame 사용, Using requestIdleCallback, 브라우저는 vsync를 어떻게 활용하고 있을까]

따라서 장기 실행중인 자바스크립트가 메인 스레드를 차단하여 반응성을 낮추는 일을 막을 수 있다.

이 둘은 setTimeout, setInterval을 대체해 사용하는데 성능 향상폭이 상당하다.[남다른 개선방법을 다시 보여준 페이스북의 React Fiber, 100,000개의 아이템도 거뜬한 셀렉트박스 만들기]

jQuery requestAnimationFrame은 requestAnimationFrame을 사용해 jQuery의 animate 반응성을 높이는 대표적인 라이브러리.

리엑트에서 requestAnimationFrame을 사용하려면 다음글이 유용할 것이다. [Using requestAnimationFrame with React Hooks]

- IntersectionObserver 사용

Lazy 로딩시 scroll 이벤트나 resize 이벤트를 받아서 getBoundingClientRect()같은 DOM API를 사용하여 뷰포트 위치를 계산하는 것이 일반적이지만 IntersectionObserver를 사용하는 것이 효율적.[IntersectionObserver's Coming into View, Intersection Observer 간단 정리하기, Now You See Me: How To Defer, Lazy-Load And Act With IntersectionObserver]

구형 브라우저를 위한 폴리필이 존재한다. [IntersectionObserver polyfill]

- pointer 이벤트나 touch 이벤트 사용

모바일에서는 더블탭이 될수도 있고, 제스쳐와 같은 동작을 위해 클릭 이벤트는 300ms를 대기 시간으로 둔다.

touchstart - touchmove - touchend - mouseover - mousemove - mousedown - mouseup - click

의 순으로 이벤트가 일어난다는 점을 고려하면 [Supporting both TouchEvent and MouseEvent, Handling Gesture Events, 사이트에 터치추가]

보다시피 훨씬 빠르다.

click보다는 touchstart, touchend를 이용하는 것이 좋다.

다음처럼 터치이벤트를 지원하는지 확인하거나

const clickEvent = (() => {
  if ('ontouchstart' in document.documentElement === true) return 'touchstart';
  else return 'click';
})

구형 브라우저는 fastclick과 같은 라이브러리를 사용해 응답성을 개선할 수 있다. [300ms tap delay, gone away]

그리고 Pointer Event란 터치이벤트보다 좋은 것이 나왔다. [포인터 이벤트, getting touchy, Pointer Events, iOS 13의 Pointer 이벤트, Pointer Events in React — The Why, How, and What, Enabling Cross-Platform Touch Interactions: Pointer vs. Touch Events]

마우스, 터치 뿐만아니라 팬까지 모두 사용할 수 있도록 만든 이벤트라는데 Touch/pointer tests and demos(이벤트 리스너)로 테스트 해보자.

비교표와 순서

둘을 대체 가능할 뿐만아니라 클릭 이벤트의 300ms 지연도 막을 수 있다.(우선순위가 가장 높음)

역시 PEP(Pointer Events Polyfill)처럼 폴리필이 존재.

3.1.4 로드 후(Post-load) 구성 요소

개요

분류: content
페이지를 곰곰히 살피다보면 "처음에 페이지를 렌더링하기 위해 반드시 필요한 것은 무엇인가?"에 대한 고민을 할 수 있다.

나머지 내용과 구성 요소는 기다리게 만들어도 된다.

해결방법

JavaScript는 onload 이벤트 전후에 분할하기에 이상적인 후보이다.

function afterPageLoad(){
   console.log('after page load');
}
 
window.onload = function afterPageLoad();

예를 들어, 드래그 앤 드롭 및 애니메이션을 수행하는 JavaScript 코드 및 라이브러리가 있는 경우 초기 렌더링 후 페이지 드래깅 요소가 오기 때문에 대기 할 수 있다.

Post load의 후보를 찾을만한 다른 장소로는 fold 아래에 숨겨진 콘텐츠 (사용자 작업 후에 표시되는 콘텐츠)와 이미지가 있다.

(이미 언급했죠?)

그런데 성능 목표는 다른 웹 개발 모범 사례와 일치 할 때 이상적이란 사실은 염두해야 한다.

이 경우 점진적 향상이라는 아이디어는 JavaScript를 사용하여 UX을 향상시킬 수 있지만, JavaScript 없이도 페이지가 작동하는지 확인해야한다는 것을 뜻한다.

따라서 페이지가 제대로 작동하는지 확인한 후 드래그 앤 드롭 및 애니메이션과 같은 부가기능을 제공하는 Post Load 스크립트로 페이지를 향상시킬 수 있다.

3.1.5 Flexbox, Grid 활용

개요

분류: CSS

옛날에는 CSS로 레이아웃을 구성하는 방법은 [CSS 레이아웃 입문서, 레거시 조판 메서드]

를 이용하였다. (더 옛날은 Table...)

그러나 최신 CSS의 방식을 사용하면 훨씬 빠르다. [이전 레이아웃 모델 대신 Flexbox 사용]

다음은 1300개의 상자들의 레이아웃을 짠 것.

3.544ms로 14.289 ms보다 훨씬 빠름

레거시한 방법은 더 많은 DOM을 요구하거나, 더 많은 마진/패딩을 요구하기 때문이다.

3.1.6 Contain 속성 활용하기

개요

분류: CSS

contain은 웹페이지에서 선택된 하위 트리를 문서의 나머지 영역과 분리하는 기능을 가지고 있다. [CSS Containment Module, CSS Containment in Chrome 52, Helping Browsers Optimize With The CSS Contain Property, How I made Google's data grid scroll 10x faster with one line of CSS]

분리되면 너무나 당연하게도 성능 향상이 된다!!

첫번째 참조 링크에 따르면 3~6ms에서 0.3~1.9ms로 약 2~10배까지 차이가 난다.

텍스트 요소를 바꿔 리플로우 발생[코드펜]

두번째 링크의 결과는 차이가 더 많이 난다. ㅎㅎ

대략적으로만 속성을 알아보자면

strict: size + layout + paint
content: size + paint
size: 상위요소는 하위요소의 크기와 독립적임
layout: 하위요소는 상위요소 안에서만 움직임
style: 요소와 해당 요소에 영향을 끼치지만, 그 이상 벗어나진 않음(서로 영향을 끼치지 않음, 독립적)
paint: 하위요소는 상위요소 안에서만 보임

처럼 이루어져 있다.

쉐도우 돔을 사용해도 효과가 이리 나타나야 할텐데..

3.1.7 content-visibility 속성 활용하기

개요

분류: CSS

화면 밖 컨텐츠의 렌더링을 생략하여 초기 로드 속도를 개선 하는 content-visibility 속성이 Chrome 85에 적용되었다. [랜더링 성능을 향상 시키는 새로운 CSS 속성 css-visibility(번역), CSS Tricks content-visibility]

화면밖의 박스는 스타일과 레이아웃만 처리하고 다른 렌더링 작업은 생략하기 때문에 퍼포먼스가 올라갈 수 있다.

.story {
  content-visibility: auto;
  contain-intrinsic-size: 1000px; /* Explained in the next section. */
}

232ms에서 30ms

문제가 있다면 크기가 0으로 측정된다는 것이다.

따라서 contain-intrinsic-size를 사용하여 공간을 차지하도록 만들어 레이아웃 시프트를 억제할 수 있다.

hidden 속성 잘 이용하면 성능향상에 도움을 줄 수 있다.

display: none: 숨기며 렌더링 상태를 제거. 나중에 다시 표시하면 새 요소를 렌더링 하는 것만큼 비용이 듦
visibility: hidden: 숨기며 렌더링 상태는 유지. 요소를 실제로 제거하지는 않기 때문에 공간을 차지하고 클릭할 수 있으며, 렌더링 상태가 업데이트 됨
content-visibility: hidden: 숨기며 렌더링 상태는 유지. 상태를 변경할 일이 생기면 화면에 표시될 때만 변경

content-visibility: hidden은 바로 다음에 나올 대형 리스트 최적화에 사용하면 좋을 것으로 보인다.

3.1.8 대형/연속적 리스트 최적화

개요

분류: Content

구글 검색시 인피니티 스크롤, 페이스북이나 인스타그램의 타임라인, 핀터레스트의 Masonry 레이아웃은 끝없는 데이터를 연속적으로 보여주는 예다. [Virtualize large lists with react-window, How GitHub Actions renders large-scale logs]

이를 어떻게하면 효율적으로 구현할 수 있을까?

해결방법

대형인 데이터를 최적화하여 보여주는 방법은 고전적인 텍스트 에디터에서도 많이 고민해왔던 문제이다.

프로그래밍 경력이 짧은 본인의 경험만 생각해도 머신러닝용 데이터나 로그파일을 보아야 할 때 성능 때문에 문제가 생긴적이 있었으니까.

이맥스의 VLF(VLFI)가 대표적인 예인데 OS에서 가상 메모리의 페이징 기법처럼 사용하여 커다란 데이터를 필요한 만큼만(Lazy하게) 다룰 수 있다.

Virtual Memory(한글 설명)

약간 더 직관적으로 바라보고, UX를 생각해보자.

위의 작업을 페이지와 프레임단위로 사용자가 사용할 페이지들만 메모리에 올려놓고, 보여주는 것은 뷰에서 현재 사용할(Visible Window, Viewport) 또는 곧 사용할 리스트(Realization Window)만 보여주자는 이야기다.

Realization Window처럼 리스트 여백을 남겨두는 이유는 사용자가 스크롤할 때 곧장 보여줄 수 있기 때문.

ListView basics and virtualization concepts

어차피 Realized View까지 한정된 갯수의 아이템만 사용할 것이라면, 각 Item을 매번 재생성하는 것은 비효율적이지 않을까?

안드로이드의 ReycylerView나 IOS의 UICollectionView는 Item을 재사용(recyler, reuse)한다. [RecyclerView(리사이클러뷰)의 원리와 사용법(feat. Kotlin), 안드로이드 리사이클러뷰 기본 사용법. (Android RecyclerView), Kotlin & RecyclerView for High Performance Lists in Android, RecyclerView로 목록 만들기]

ListView vs RecyclerView

보여지는 각 Item을 View Holder 객체에 저장해두고, View Holder 내부에서 바꿔야 할 데이터들만 바인딩하여 바꿔치기만하면, 매번 Item을 제거하고 다시 생성할 필요가 없다.

Using the ViewHolder Pattern

관련 코드설명을 함께 사용하고 싶다면 다음 설명이 깔끔하다. [Tips & Tricks for Highly Performing Android ListViews]

여기에 스크롤 성능을 더 향상시키위해 재사용하기전에 약간의 텀을 두고, 재사용 했을시 캐싱, 새로운 아이템에 대한 프리페칭등을 적용할 수도 있다. [iOS10의 프리-패칭 API로 부드러운 스크롤 증진하기, UICollectionView Tutorial: Prefetching APIs, UICollectionViewCell의 LifeCycle과 PreFetching, Texture - Intelligent Preloading(한글)]

자 다음 사진으로 정리해보자.

Data List: 물리적 메모리
Adapter: 메모리 맵
ViewHolder: 페이지

가 보이는가??

React의 경우 다음을 사용가능하다. [Windowing wars: React-virtualized vs. react-window]

React-Window: 보이는 것들만 로딩
React-Virtualized: React-Window보다 살짝 더 무거움
Recylerlistview: 재사용 가능, ReactNative 기반이지만 웹에서도 사용가능

다른 플랫폼의 경우 Facebook의 Litho관련 글도 흥미롭다.

3.1.9 React 최적화

개요

분류: Javascript

여기에서는 리엑트의 렌더링성능을 최적화시키는 방법들에 대해 다루려한다. [How to greatly improve your React app performance, React 렌더링 이해 및 최적화 (With Hook)]

우선 리엑트의 구조에 대해 아는게 좋겠죠.

대략적인 리엑트의 동작과 주의할 점은 다음 글들에서 알 수 있다.

리엑트 Core 팀 개발자인 Dan Abramov의 글이니 신뢰할만하다.

기타 리엑트 구조에 대해 궁금하다면

Under the hood ReactJS

를 읽어볼 수 있다.

이외에 리엑트 동작의 시각화한 글들 목록.

를 보도록 하자.

리엑트는 클래스 컴포넌트나 함수형 컴포넌트를 사용하며 둘의 사용방법이 다르기 때문에 비교가 필요하다.

보통 클래스 컴포넌트에 존재하는 라이프 사이클이 함수형 컴포넌트에는 없기 때문에 Hooks를 사용한다.

라이프사이클과 Hooks의 관계는 대략 다음과 같다.

https://black7375.tumblr.com/post/616396328590786560/

라이프사이클과 클래스 컴포넌트

티스토리 글을 적을 때 아무래도 따로 분리해 적는게 나을 듯하여 작성하게 되었다. 라이프사이클과 클래스 컴포넌트 react-lifecycle-methods-diagram - Mount 순서 constructor(props): 컴포넌트를 새로 만들때

black7375.tumblr.com

중요한점: 함수형 컴포넌트는 "라이프사이클" 개념이 전혀 아니다.

해결방법

- 컴포넌트와 State 구조

가장 간단한 방법으로 메모이즈가 떠오르겠지만, 만능은 아니다.

우리는 항상 처음에 설계를 올바르게 했는가를 생각해볼 필요가 있다.

깊이 있는 컴포넌트까지 너무 많은 Props를 전달하는 것은 쓸데없이 재렌더링이 일어날 수 있으며 성능에 영향을 미칠수도 있다. [Crafting a high-performance TV user interface using React, Avoiding unnecessary renders with React context, React Context 알아보기]

넷플릭스의 벤치마크 결과

아 그럼, Context를 사용하면 state를 바로 전달할 수 있어 쓸데없이 렌더링이 이루어지는 것을 막을 수 있겠구나고 생각 할 수 있다.

그러나 Context API는 Context 값에 의존 할 경우, 다른 값이 변경되도 리렌더링이 발생한다. [리덕스 잘 쓰고 계시나요?]

따라서 관련이 없는 상태라면 Context를 따로 분리해줘야 하며, 위 글과 같이 상태를 위한 Context와 상태 업데이트를 위한 Context를 분리해야하기도 한다.

솔직히 상태 업데이트를 분리하도록 만들어야 하는게 올바른 패턴이라는 점에서 약간의 설계미스가 있는게 아닌가 싶다.

Context API 내부의 state들이 리엑트 state로 관리되어 깔끔하긴 하다만 컴포넌트 트리에서 분리되는게 좋지않나..

정적인 값들 위주로 사용할경우 쓰는게 맞을 듯.

따라서 윗글대로 리덕스나 리코일등을 사용하면 좋다고 생각한다.

하지만 여기서도 여전히 구조적으로 설계를 잘하면 성능상 이득은 여전히 얻을수있다. [Refactoring Components for Redux Performance, Redux isn't slow, you're just doing it wrong - An optimization guide, memo()를 하기 전에]

리팩토링 전, 후

파생된 상태의 경우 reselect같은 라이브러리를 사용하여 메모이징을 할 수 있다.

정리하자면

상태를 데이터베이스처럼 생각하고, 정규화를 하자. [Redux에서 Normalize 다루기, 정규화와 성능, 반정규화와 성능]
관심사 분리가 자연적으로 되며, 평평하게(Flatten)하게 유지됨
단, 너무 심한 정규화는 읽기 성능에 지장을 줄 수도 있으며, 데이터가 크다면 파티셔닝도 고려하자.
컴포넌트의 상태구독 계층을 분리한다.
모든 값이 공유되지 않도록 하며, 상태는 아래로 내리고 내용물은 위로 끌어올린다.
상태 업데이트는 최소한만 하며, 파생된 상태의 경우 reselector등으로 메모이징을 활용한다.

위 링크들에서 나왔던 예제코드들.

// Bad
const state = {
  articles: [{
    comments: [{
      users: [{
      }]
    }]
  }],
  ...
};

// Good
const state = {
  articles: [{
    ...
  }],
  comments: [{
    articleId: ..,
    userId: ...,
    ...
  }],
  users: [{
    ...
  }]
}

상태는 정규화되고 평평하게.

// Bad
const BigComponent = ({ a, b, c, d }) => (
  <div>
    <CompA a={a} />
    <CompB b={b} />
    <CompC c={c} />
  </div>
);

const ConnectedBigComponent = connect(
  ({ a, b, c }) => ({ a, b, c })
);

// Good
const ConnectedA = connect(CompA, ({ a }) => ({ a }));
const ConnectedB = connect(CompB, ({ b }) => ({ b }));
const ConnectedC = connect(CompC, ({ c }) => ({ c }));

const BigComponent = () => (
  <div>
    <ConnectedA />
    <ConnectedB />
    <ConnectedC />
  </div>
);

상태분할

방금전의 상태분할과 상동하는 면도 있다.

// Bad
export default function App() {
  let [color, setColor] = useState('red');
  return (
    <div style={{ color }}>
      <input value={color} onChange={(e) => setColor(e.target.value)} />
      <p style={{ color }}>Hello, world!</p>
      <ExpensiveTree />
    </div>
  );
}


// Good
export default function App() {
  return (
    <ColorPicker>
      <p>Hello, world!</p>
      <ExpensiveTree />
    </ColorPicker>
  );
}

function ColorPicker({ children }) {
  let [color, setColor] = useState("red"); // 1. 상태를 내리기
  return (
    <div style={{ color }}>
      <input value={color} onChange={(e) => setColor(e.target.value)} />
      {children}                           // 2. 내용물은 끌어올리기
    </div>
  );
}

상태는 내리고, 내용물은 끌어올리기

// Bad
const ListItem = connect(
  ({ selectedItem }) => ({ selectedItem })
)(SimpleListItem);

// Good
const ListItem = connect(
  ({ selectedItem }, { itemId }) => ({ isSelected: selectedItem === itemId })
)(SimpleListItem);

상태 변경은 최소한으로

리스트 데이터 관리는 React Children And Iteration Methods를 읽어보자.

- 불변성과 상태 업데이트 조금 더 잘하기

위에서는 구조를 위주로만 설명했다.

여기서는 기타방법을 다룹니다. [리액트를 다루는 기술]

데이터 불변성 유지하기
함수형 업데이트 활용하기
useState 대신 useReducer 활용하기

데이터 불변성 유지하기

ES6의 Spread Syntax나 바벨의 Object Spread Syntax를 이용하면 쉽게 데이터 불변성을 유지하면서 값을 업데이트할 수 있다.

// spread syntax
handleClick() {
  this.setState(state => ({
    words: [...state.words, 'marklar'],
  }));
};

// object spread syntax
function updateColorMap(colormap) {
  return {...colormap, right: 'blue'};
}

불변성을 유지하기 위해 앞서 이야기했던 immutable.js, immer를 사용해볼 수도 있다.

함수형을 좋아한다면 하스켈 optics와 비슷한 monocle-ts를 써보자.

함수형 업데이트 활용하기

함수형 업데이트는 몇가지 장점이 있다.

우선 업데이트 함수가 현재 상태와 같은 값을 반환하면 렌더링을 건너뛰며, 의존성을 줄이기 때문에 최적화에 도움이 된다.

마지막으로 초기 state의 경우 지연되게 만들 수 있다.

useState 대신 useReducer 활용하기

useReducer는 콜백 대신 dispatch를 전달한다. [How to avoid passing callbacks down?, How to use useReducer in React Hooks for performance optimization]

다수의 하윗값을 포함하는 복잡한 정적 로직을 만드는 경우나 다음 state가 이전 state에 의존적인 경우에 보통 useState보다 useReducer를 선호합니다. 또한 useReducer는 자세한 업데이트를 트리거 하는 컴포넌트의 성능을 최적화할 수 있게 하는데, 이것은 콜백 대신 dispatch를 전달 할 수 있기 때문입니다.

이때 dispatch는 렌더시 변화하지 않고 같다는 것을 보장하며 역시 의존성을 제거하여 필요시보다 자주 업데이트 되는 것을 방지한다.

Flux의 Dispatcher 문서에서는 다음과 같이 차이를 정의한다.

콜백은 이벤트를 개별적으로 구독하지 않는다. 모든 데이터 변동은 등록된 모든 콜백에 전달된다.
콜백이 실행될 때 콜백의 전체나 일부를 중단할 수 있다.

Redux에는 combineReducers()도 있으니 확인바란다.

- 컴포넌트 라이프사이클 / 메모이제이션

shouldComponentUpdate(): 클래스

shouldCompontnentUpdate는 현재 props와 state와 다음 props, state를 비교후, 렌더링할 것인지 말것이지 결정한다. [재조정을 피하세요]

true는 렌더링. false면 렌더링을 하지 않는다.

C2에서 false를 반환하여 렌더링을 하지 않음

트위터에서는 deffering rendering을 하기도 했다. [Twitter Lite and High Performance React Progressive Web Apps at Scale]

React.PureComponent: 클래스

Purecomponent는 Shallow Compare(얕은 비교)를 이용하는 것과 같다.

export class SampleComponent extends React.Component {
  shouldComponentUpdate(nextProps, nextState) {
    return shallowCompare(this, nextProps, nextState);
  }

  render() {
    return <div className={this.props.className}>foo</div>;
  }
}

그렇다면 얕은 비교는 어떻게 이루어질까?

자바스크립트를 처음 배울 때 객체와 레퍼런스들을 다루는 것과 같다.

Are javascript object variables just reference type?

s2는 s1의 포인터를 사용하는 것과 같아 같은 레퍼런스를 가르치므로 같으며,

s3는 값은 같으나 전혀 다른 객체이므로 달랐던 것처럼.

const s1 = {text: "first"};
const s2 = s1;
const s3 = {text: "first"};

s1 === s2; // true
s1 === s3; // false

PureComponent는 props와 state에 대해 얕은 비교를 수행한다.

만약 깊은 비교가 필요하면 react-fast-compare나 fast-deep-equal를 이용해보자.

React.memo: 함수형

React.memo는 PureComponent와 shouldComponentUpdate의 일부를 사용하도록 만들어졌다. [React.memo() 현명하게 사용하기]

첫번째 인수로 PureComponent로 사용할 컴포넌트, 두번째 인수로 같은 컴포넌트인지 확인하기 위한 비교할 콜백 함수를 넣을 수 있다.

차이라면, props에 대해서만 얕은 비교를 수행하며, shouldComponentUpdate와 정반대로

true: 같으므로 렌더링 하지 않음
false: 다르므로 렌더링

이다.

다음은 React.PureComponent나 React.memo를 사용하면 좋은 상황들.

순수 컴포넌트(Pure Component): props의 값이 같으면 렌더링이 같을 때.
렌더링이 빈번히 일어날 때.
얕은 비교를 할 필요가 있을 경우.

반대로 매 렌더링마다 달라지는 경우는 불필요한 비교과정만 늘어난다.

메모이제이션을 모든 곳에 사용하는 것은 나쁜 생각이지만,[Death by a thousand useCallbacks]
참조/ID의 재사용 때문에 선제적으로 최적화하자는 말도 있다. [Preemptive memoization in React is probably not Evil (yet)]

- 이벤트 리스너와 값 메모이제이션

컴포넌트 밖에서 정의: 공통

React.PureComponent나 React.memo를 사용시 해당 컴포넌트에 의존하지 않는다면 컴포넌트 밖에 정의하면 참조 값이 같으므로 새로운 함수나 값이 생성되지 않는다. [이벤트 리스너 캐시를 이용한 React 성능 향상]

this로 바인딩: 클래스

리엑트의 클래스형 컴포넌트에서 콜백을 올바르게 사용하는 방법은 유독 까다롭다. [이벤트 처리하기, React Binding Patterns: 5 Approaches for Handling `this`, 당신이 몰랐을수도 있는 React Binding 에 관한 사실]

의외로 화살표 함수에서도 오버헤드가 발생하며, 가장 나은 방법은 데코레이터로 바인딩 표시를 해주는게 가독성에서 나은 방법이라고.. [Arrow Functions in Class Properties Might Not Be As Great As We Think]

import {boundMethod} from 'autobind-decorator'

class BindMethod extends React.Compnent {
  constructor(props) {
    super(props);
    this.state = {
      isChecked: false
    };
  }

  @boundMethod
  handleClick(e) {
    this.setState({ isChecked: true });
  }
  
  render() {
    return <button onClick={this.handleClick}>바인딩</button>;
  }
}

useCallback/useMemo: 함수형

useCallback은 이벤트 리스너를 useMemo는 값을 메모이제이션한다. [Optimize Your React Functional Components with useCallback and useMemo]

class때처럼 인라인 콜백은 매번 새로운 함수객체를 생성하므로 좋은 습관이 아니다.

useCallback을 적극 활용하자.

// Bad
function fnComponent() {
  const [state, setState] = useState({ isChecked: false });

  return return <button onClick={(e) => setState({ isChecked: true })}>인라인</button>;
}

// Good
function fnComponent() {
  const [state, setState] = useState({ isChecked: false });
  const handleClick = useCallback((e) => {
    setState({ isChecked: true });
  }, [state]);
  return return <button onClick={handleClick}>인라인</button>;
}

- 올바른 Key 사용

배열에서 올바르게 키를 지정해주는 것도 쉬운듯, 쉽지 않은 일이다. [Optimize React Performance, 아이디에 고유 값 주기]

보통의 경우, DB에서 불러올 ID 정보값을 사용하여 설정해주는게 좋다.

의외로 많이 하는 실수인 Math.random()은 성능이 나뻐지고 안전한 난수를 생성하지 않는다.

- React.lazy/React.Suspense 사용 및 동시성 모드

React.lazy를 사용하면 컴포넌트를 동적으로 불러올 함수를 등록할 수 있다.

React.Suspense로 렌더링이 준비되지 않은 컴포넌트를 불러오고, fallback으로 스피너를 사용할 수 있다.

또한 리엑트는 동시성모드로 트랜지션, 자동 배칭, 협력적 멀티태스킹 등등 많은 혁신을 도입한다.

- Ref와 비제어 컴포넌트

리엑트의 경우 기본적으로 제어 컴포넌트로 동작하여 입력을 하면 렌더링이 일어난다. [입력을 다루는 다양한 방법, Uncontrolled form validation with React]

(onChange와 state를 연결한다는 가정하에)

Dom에 빈번한 접근 또한 성능에 안좋지 않던가?

게다가 Form은 기본적으로 Dom에서 상태를 저장할 수 있기 때문에, 꼭 자바스크립트를 통해 상태를 업데이트할 필요가 없다.

Dom에 상태를 저장하고, ref를 이용하면 비제어 컴포넌트로 사용할 수 있다.

라이브러리를 원한다면 unform나 react-hook-form을 이용해보자.

한마디로 변경 가능한 값을 유지해야할 때는 ref 사용을 고려해볼 수 있다는 말이다. [A Thoughtful Way To Use React’s useRef() Hook, userStateWithRef()]

데이터 그리드를 userRef로 최적화한 사례인 How to Optimize React Performace by Using useRef Hooks을 참고해보는 것도 좋다.

- 기타 실용적 예제

토스트 UI와 체커의 데이터 그리드 시스템[반응형 시스템 개선하기(feat. TOAST UI Grid), React datagrid component 제작기 (with ES6, TypeScript)]

앞서 나왔던 넷플릭스 예제에는 인라이닝, 스타일의 static-dynamic 요소 분리와 정적 diff&apply처럼 흥미로운 예가 있지만, 컴파일타임에 처리해주는 플러그인이 있어야 하기 때문에 일반적이지는 않다.

3.2 처리 효율화

3.2.1 워커나 워클릿 활용하기

개요

분류: Javascript

웹워커는 무거운 연산들을 메인 쓰레드와 분리시켜 백그라운드에서 처리할 수 있도록 도와준다. [멀티스레드를 위한 자바스크립트 프로그래밍 웹 워커(요약), Web Worker 간단 정리하기, Web workers vs Service workers vs Worklets, The main thread is a bad place to run your code, Html5 web workers]

처리 집약적 수학 계산
대용량 데이터 세트 정렬
데이터 작업(압축, 인코딩/디코딩, 오디오 분석, 이미지 픽셀 변환)
트래픽 높은 네트워크 통신(네트워크 데이터 처리, 캐싱과 프리페칭)
백그라운드 I/O, 웹사이트 폴링(Polling)

등이 대표적인 예. [JavaScript 프로그램 성능 향상 ]

워커의 종류를 나누어 보자면 다음과 같다.

전용 워커(Dedicated Woker): 처음 생성한 스크립트에서만 사용 가능, 보통 웹워커라 함은 전용 워커를 뜻함
공유 워커(Shared Worker): 워커간 데이터를 공유하는 목적, 동일한 도메인 내의 여러 스크립트나 컨텍스트(tab, iframe, worker)에서 접근 가능
서비스 워커(Service Worker): 프록시의 역할을 하며, 네트워크 요청과 캐싱, 푸시알람, 백그라운드 동기화등에 사용[서비스 워커: 소개, 오프라인 설명서]
크롬 워커(Chrome Worker): 파이어폭스 독점 API로 확장기능에서 사용하고, js-ctype에 접근할 때 사용, 신경쓰지 않아도 좋다.

웹워커나 서비스 워커를 사용하면 계산이 많이 필요한 것이나 캐싱이 필요한 것들에서 큰 폭으로 성능을 높힐 수 있다.

웹 워커 성능 향상 예[Web Workers with the Angular CLI, Optimizing JavaScript Application Performance with Web Workers]

서비스 워커 성능 향상 예[Progressive Web App Libaries in Production, 앱 셸 모델, Service workers in Depth, Strategies for service worker caching]

하지만 메인(UI) 쓰레드가 아니기 때문에

Window Object
Document Object
Parent Object

를 사용하지 못한다는 점은 알고 있어야 한다.

워커의 오버헤드 비용 또한 고려해야 한다. [How fast are web workers?]

워커랑 비슷하지만, 가볍고 렌더링시에도 사용할 수 있는 Worklet도 있다.

Worklets: Worker의 초기 비용이 큰 문제를 해결하기 위한 경량버전, 저수준 렌더링 파이프 라인에 접근가능[worklet, CSS Paint API, CSS Houdini, Houdini: Demystifying CSS, Awesome CSS Houdini]
- PaintWorklet[CSS Paint API]
- AudioWorklet[Enter Audio Worklet, Audio Worklet Design Pattern]
- AnimationWorklet[Houdini's Animation Worklet]
- LayoutWorklet 로 구성

가장 큰 단점은 아직 지원하는 브라우저가 많지 않다.

한가지 주의할 점은 3D 렌더링을 WebGL과 같이 사용할 수 없으며 WebGL의 GLSL 코드를 사용해야 한다.

정리하자면

전용 워커: CPU 중심의 작업을 메인 스레드에서 오프로드 할 때 사용
공유 워커: 워커간 공유가 필요할 때 사용
서비스 워커: 네트워크 요청을 캐싱하거나 오프라인 작업을 위해 사용
워크렛: 브라우저 렌더링 파이프 라인에 연결되어, 스타일이나 레이아웃등 렌더링 프로세스에 저수준 접근이 가능

와 같다.

예전에 병렬 연산을 위해 WebCL이란 표준이 있었는데 지원하는 브라우저가 없는 모양.[WebCL]

해결방법

- 기초 사용방법

가장 보편적인 전용 워커, 서비스 워커, 페인트 워크렛의 예제를 들어본다.

전용 워커

new Worker를 이용해 생성하며, postMessage와 onmessage로 통신한다. [“Off The Main Thread”]

확장기능을 만들어본 사람은 background와 content의 통신방식과 유사해 적응이 쉬울것이다.

/* main.js */

// Create worker
const myWorker = new Worker('worker.js');

// Send message to worker
myWorker.postMessage('Hello!');

// Receive message from worker
myWorker.onmessage = function(e) {
  console.log(e.data);
}

worker에서도 사용방법은 같다.

/* worker.js */

// Receive message from main file
self.onmessage = function(e) {
  console.log(e.data);

  // Send message to main file
  self.postMessage(workerResult);
}

특히 Offscreen Canvas가 주목받을만 하다.[크로미움 엔진과 오프스크린 캔버스 기술, OffscreenCanvas — Speed up Your Canvas Operations with a Web Worker, Web Worker-Postable 라이브러리 작성기]

서비스 워커

방금전 워커 예제처럼 서비스 워커파일을 참조해서 등록해야 한다. [How to Make your React App a Progressive Web App (PWA)]

/* main.js */

navigator.serviceWorker.register('/service-worker.js');

서비스 워커는 프록시의 역할을 하기 때문에 모든 네트워크 요청을 가로챌 수 있다.

/* service-worker.js */

// Install 
self.addEventListener('install', function(event) {
    // ...
});

// Activate 
self.addEventListener('activate', function(event) {
    // ...
});

// Listen for network requests from the main document
self.addEventListener('fetch', function(event) {
    // ...
});

예를 들어 캐시에서 문서를 반환하도록 만들어 오프라인 상태로 작동시킬 수도 있다.

PWA에 필수적인 요소니 꼭 알아두었으면 한다.[고성능 서비스 워커 로딩, Lazy load your images with Service Worker]

/* service-worker.js */

const cacheName = 'shell-content';
const filesToCache = [
  '/css/styles.css',
  '/js/scripts.js',
  '/images/logo.svg',

  '/offline.html’,

  '/’,
];

self.addEventListener('install', function(e) {
  console.log('[ServiceWorker] Install');
  e.waitUntil(
    caches.open(cacheName).then(function(cache) {
      console.log('[ServiceWorker] Caching app shell');
      return cache.addAll(filesToCache);
    })
  );
});

또는 이런식으로.

/* service-worker.js */

self.addEventListener('fetch', function(event) {
    // Return data from cache
    event.respondWith(
        caches.match(event.request);
    );
});

페인트 워크렛

역시나 JS 파일을 등록한다.

/* main.js */

CSS.paintWorklet.addModule('myWorklet.js');

그 후, 사용자 정의 이미지를 만드는 예. Canvas API와 유사하다.

/* myWorklet.js */

registerPaint('myGradient', class {
  paint(ctx, size, properties) {
    var gradient = ctx.createLinearGradient(0, 0, 0, size.height / 3);

    gradient.addColorStop(0, "black");
    gradient.addColorStop(0.7, "rgb(210, 210, 210)");
    gradient.addColorStop(0.8, "rgb(230, 230, 230)");
    gradient.addColorStop(1, "white");

    ctx.fillStyle = gradient;
    ctx.fillRect(0, 0, size.width, size.height / 3);
  }
});

만든 사용자 정의 이미지는 CSS에서 적용하면 끝!!

div {
    background-image: paint(myGradient);
}

- 라이브러리

워커들이나 워크렛을 그냥 사용하기에는 불편한 점들이 많다.

대표적인 라이브러리들을 소개해본다.

웹 워커

웹 워커를 이용하기 쉽게 만든 라이브러리

Comlink: 구글이 만든 것으로 잘 추상화 시켜놨다. [comlink-loader]
Greenlet: async 함수를 웹워커로 처리
Workerize: 모듈을 웹워커로 처리
Workly: 역시 함수나 클래스를 워커로 처리도록 만든 것
Operative: 콜백 형식으로 처리하도록 만듦

동시성이나 병렬 처리시 좋은 라이브러리.

리엑트에서 사용하기 좋은, 또는 아이디어가 재미있는 것

useWorker
react-worker-image
partytown: 제 3자 스크립트를 웹워커에서

서비스 워커

Workbox: 구글이 PWA에 쓰라고 잘 만든 라이브러리. (sw-toolbox + sw-precache + sw-offline-google-analytics)
UpUp: 한줄의 명령으로 오프라인 기능 제공
offline-plugin: 서비스 워커와 앱캐시를 웹팩에서 쓰기 편하게
StreamSaver.js: 스트리밍 받아 파일로 저장
Manifest Generator: 푸시 알림 또는 PWA에 필요한 웹 앱 매니페스트 생성기

워크렛

extra css: 웹사이트 꾸미기에 좋은 Paint API 라이러리

3.2.2 그래픽 최적화

개요

분류: Content, CSS, Javascript

그래픽 최적화의 핵심은 GPU를 어떻게 써먹는가이다. [하드웨어 가속에 대한 이해와 적용, Animation performance and frame rate]

하드웨어 가속은 Graphics Layer 단위로 처리되며, GPU를 이용해 이미지로 합성(Composition)해 화면에 출력한다.

다음은 하드웨어 가속 대상이다.

CSS 3D Transform(translate3d, preserve-3d 등)이나 perspective 속성이 적용된 경우
<video> 또는 <canvas> 요소
CSS3 애니메이션 함수나 CSS 필터 함수
자식 요소가 레이어로 구성
z-index값이 낮은 형제 요소가 레이어로 구성된 경우

그러나 하드웨어 가속은 조심히 사용해야 하는데 5가지만 뽑아보았다.

메모리: 많은 텍스처를 로드하면 메모리 문제가 발생할 수 있다.
특히, 모바일 장치에서 문제가 생길 수 있으며, 모든 요소에 하드웨어 가속을 적용하면 안된다.
깜박임: 영역이 크면 화면이 깜박일 수도 있다.
변경: 컨텐츠 내용이 변경되면 GPU 메모리에 다시 업로드 해야한다.
글씨 렌더링: CPU와 CPU의 렌더링 방식으로 인해 안티얼라이싱에 영향을 주어 흐리게 표시될 수 있다. [GPU text rendering in webkit]
기기: 가속을 지원하지 않는 기기에서는 성능저하가 생길 수 있다.

또한 애니메이션 레이어의 컨텐츠 내용을 변경하지 않는 것이 좋다.

해결방법

웹에서 그래픽을 표현할 때 여러가지 방법이 존재한다. [A Comparison of Animation Technologies, Compare the options for Animations on the Web]

CSS: 앞서 언급한 것. [An Introduction to Hardware Acceleration with CSS Animations, CSS GPU Animation: Doing It Right(번역), CSS 애니메이션 성능 개선 방법(reflow 최소화, will-change 사용), Why Moving Elements With Translate() Is Better Than Pos:abs Top/left, CSS 애니메이션의 성능 아는 만큼 좋아져요!]
Canvas: javascript와 <canvas>를 이용해 그래픽을 그릴 수 있는 API.
SMIL: SVG 애니메이션, deprecated 됨.
WebAnimation API: 애니메이션을 만들 수 있는 자바스크립트 API
WebGL: OpenGL(1.0: ES 2.0, 2.0: ES 3.0) 기반 API를 이용해 HTML canvas에 렌더링하는 것[WebGL 기초], 최근 WebGL 2.0이 메이져 브라우저에서 지원된다.
WebGPU : WebGL의 뒤를 이을 표준, 아직 만들어지고 있는 중 (Apple에서는 WebGPU 라는 이름으로 사용하다가 WebMetal로 이름이 바뀜) [WebGPU, WebGPU and WSL in Safari, GPU Web]
애플의 사례를 볼때 WebGL보다 성능에서 유리한듯.

CSS와 자바스크립트의 애니메이션에 대해 다음 문서에서 간략히 다루고 있다.[CSS와 자바스크립트 애니메이션, CSS and JavaScript animation performance]

정리하자면,

간단한 애니메이션은 CSS를 사용
복잡한 것은 WebAnimation API 사용 [Animating like you just don’t care with Element.animate]
3D나 더욱 세밀한 제어, VR등에서 필요시 WebGL 사용
간단할 때 CSS의 성능이 SVG보다 낫고, deprecated 되어 사용하지 않는게 좋음 [Weighing SVG Animation Techniques(with Benchmarks)]

CSS

GPU 가속이 되도독 작성해야 한다.

현재는 opacity와 transform 정도만 지원. [AMP - 지원하는 CSS, Stick to Compositor-Only Properties and Manage Layer Count, Highperformacne Animations]

다음과 같이 대체하여 사용할 수 있다.

Motion One에 따르면 filter, background-color, clip-path, SVG도 많은 브라우저에서 지원한다고 한다.

element {
  /* Box shadow Accelerate */
  box-shadow: 10px 10px black;
  filter: drop-shadow(10px 10px black);
 
  /* Border radius Accelerate */
  border-radius: 50px;
  clip-path: inset(0 round 50px);
}

position을 absolute나 fixed로 설정하면 주변 영역에 영향을 주지 않는다.

약간의 꼼수로 컴포지터 쓰레드로 레이어를 분리시켜 성능을 높일 수 있다.

will-change를 사용하면 애니메이션이 곧 일어날 것이라고 알려줘 응답성을 개선할 수 있다.

하지만, 레스터화 시키고 우선순위를 변경하는 것이기 때문에 신중히 사용하고 해제해야 한다. [CSS will-change 프로퍼티에 관해 알아둬야 할 것]

.moving-element {
  will-change: transform;
}

will-change가 먹히지 않는 브라우저라면, 강제로 적용 가능하다.

.moving-element {
  transform: translateZ(0);
}

물론 CPU와 GPU의 대역폭, GPU의 메모리, 모바일의 하드웨어 가속여부 및 리소스 크기를 따져가며 작업해야 한다.

몇가지 괜찮은 라이브러리들

Motion One: Web Animations API로 구축되었으며 하드웨어 가속을 적극 활용
shifty: GSAP(GreenSock Animation Platform)보다 메모리를 적게 사용
PixiJS: 2D 라이브러리
Three.js: 3D 라이브러리

나중에 시간이 나면 더 서술할 예정.

3.2.3 웹 어셈블리

개요

분류: wasm

웹 어셈블리는 네이티브에 가까운 성능으로 동작하는 바이너리 포맷을 제공하는 프로젝트로 C/C++, Rust 등의 컴파일 타겟으로 사용될 수 있다.

나오게 된 계기는 WebAssembly, 브라우저에 올리는 네이티브 코드를 살펴보면 재미있게 읽을 수 있다.

A cartoon intro to WebAssembly(번역)도 읽을만한 하구.

웹브라우저에서 웹 어셈블리를 위한 컴파일러를 제공하는 것도 주목할만 하다.

파이어폭스의 스트리밍 + 계층형 컴파일러(계층형 컴파일러가 궁금하면 닷넷문서 참고)
웹킷의 BBQBuild Bytecode Quickly)와 OMG(Optimized Machine-code Generator) 계층형 컴파일러
블링크의 Litoff 컴파일러

유니티에 따르면 상당히 성능이 좋다. [WebAssembly LoadTimes and Performance]

메인 스크린에 보이는 총시간(낮은 것이 좋음)

총점수(높은 것이 좋음)

그렇다면, 웹 어셈블리의 성능은 왜 좋을까?

웹 어셈블리 코드의 크기가 작음
웹 어셈블리의 디코딩 시간이 자바스크립트 파싱 시간보다 적음
이미 컴파일 되어 있는 상태라 최적화가 잘되어 있음
타입이나 기타 정보가 있어 최적화에 유리
명령어셋을 사용할 수 있음
직접 메모리를 관리해 GC가 필요 없음

써보려면 MDN 문서를 정독해보는 것이 좋다.

물론 DOM에 접근할 수 없기 때문에 자바스크립트를 완전 대체하기보다 CPU 성능 집약적인 작업이나 기존 C/C++ 코드를 포팅해서 사용할 때 유용할 것이다.

Dodrio나 asm-dom처럼 Virtual DOM을 웹 어셈블리로 하는 사례도 있는 듯.

현재로서 가장 좋은 성능을 내고 싶다면 WebGL + WASM(쉐이더) + Worker 조합인듯

web-sys라는 러스트 라이브러리가 잘 되어 있는 듯 하다.

언젠가는 PWA로 그래픽좋은 게임을 설치해서 플레이 할 수 있지 않을까

3.2.4 전용 페이지

개요

분류: Content

컨텐츠를 전용 페이지로 만들어 제공하면 빠르고 로드 할 수 있다.[Instant loading on mobile: should you AMP-ify / MIP-ify your website in 2018?, Facebook Instant Articles vs. Google AMP, AMP and Turbo Pages: Pros, Cons, and Implementation Results, What do Facebook Instant Articles, Apple News & Google AMP mean for publishers?]

처음에는 컨텐츠를 일정한 UI로 만들어 통일성을 만들고, 광고 수익을 챙기고, 접속율을 늘리려는 과정에서 다음과 같은 것들이 등장하였다.

페이스북: Instant Article [Why Is Facebook Instant Articles Faster?, Instant Articles Now Open to All Publishers, Facebooks's instant articles arrive to speed up the News Feed]
애플: Apple News [Apple News Document]
텐센트(위챗): Mini Program [Wechat Mini Program: an epic guide]

이 중 유의미한 성능과 관련된 결과를 보여주는 인스턴트 아티클을 살펴보자면

사이트의 CSS, Javascript, 광고 및 분석 등을 아낄 수 있음
복잡한 레이아웃, 인터페이스 렌더링 필요 없음
페이스북에서 사진, 비디오를 빠르게 로드하는 것과 동일한 기술
스토리에 접근할 때 스토리를 미리로드 시작

애플의 경우, 이미지 캐싱과 JSON 포맷이라 가벼워 성능에서 유리한 편.

폐쇄적인 플랫폼에서만 쓰였던 컨셉이 열려있는 플랫폼(검색엔진)에도 적용되기 시작했다.

AMP와 MIP는 동일한 기술.

AMP는 Yahoo Japan과 Sogou에서도 지원한다고 한다. [Accelerated Mobile Pages rolling out to a billion Yahoo Japan, Baidu, & Sogou users in Asia]

AMP가 성능을 높힐 수 있었던 주요 이유는 다음과 같다. [AMP는 어떻게 웹 페이지의 성능을 높일 수 있나, AMP 작동 원리]

AMP HTML: 커스텀 엘리먼트를 사용하여 레이아웃 계산 최소화
AMP JS: 리소스 로딩 관리(비동기, 느린 것 차단) 및 커스텀 엘리먼트 제어.
AMP Cache: 프록시 기반 CDN으로 캐시를 이용, 모든 스크립트와 이미지를 같은 출처(Origin)에서 다운 가능
제한: 서드파티 CSS, JS 미허용 및 용량 제한, GPU 가속 애니메이션만 허용, 상태 및 이벤트 관리

이 페이지에서 나오는 것들이 빡시게 적용되었다는 것을 알 수 있다.

Turbo Pages의 컨셉을 살펴보면 AMP와 Instant Page 사이.

3.2.5 자바스크립트 코딩 스타일

개요

분류: Javascript

코딩 스타일을 변경하는 것만으로도 성능을 향상 시킬 수 있다.[자바스크립트는 어떻게 작동하는가: V8 엔진의 내부 + 최적화된 코드를 작성을 위한 다섯 가지 팁, 성능을 높이는 코드 스타일(다른 버전1, 다른버전2, 다른버전3), How To Write Fast, Memory-Efficient JavaScript, Let’s get those Javascript Arrays to work fast, Optimizing dynamic JavaScript with inline caches, JavaScript Garden, React-Cliff, 당신이 모르는 자바스크립트의 메모리 누수의 비밀, amark/gun - Performance, Optimiztion-killers, JS의 객체는 hash table이 아닙니다!, JavaScript's Memory Management Explained, 자바스크립트 성능 최적화(1, 2, 3, 4, 6, 7, 8)]

이를 위해 미리 알아두어야 할 지식이 있다.

- 스코프 체인(Scope Chain)

크게 함수 내부에서 접근 가능한 활성화 객체와 전역 객체로 나눌수 있다. [Js Principles Scope Chain Readme, How do JavaScript closures work under the hood]

함수에서 지역변수나 this, arguments등은 활성화 객체, 전역변수, document 등은 전역 객체다.

Scope Chain

식별자를 찾을 때, 자신이 속한 스코프에서 찾은 후 식별자가 없으면 상위 스코프에서 찾는다.

상위 스코프로 어떻게 접근할까?

답은 바로 스코프 체인이다.

각 객체에 접근하기 위한 객체의 참조가 특정한 공간에 저장되어 있으며 이를 스코프 체인이라 한다.

실행 문맥 -> 스코프 체인 -> 활성화 객체 -> 스코프 체인 -> 전역 객체

와 같이 접근하게 된다.

- 객체 초기화와 인라인 캐싱

자바스크립트의 객체 접근은 느리다.

해시 함수를 이용해 객체 속성 값의 위치를 메모리에 저장하기 때문이다.

이는 동적으로 할당 가능해야 하는 자바스크립트의 특성 때문.

이를 보완하기 위해 자바스크립트 인터프린터는 고정적인 객체 레이아웃인 히든 클래스를 만든다.

히든 클래스

function Point(x, y) {
  this.x = x; // New Hidden Class based C0 - C1
  this.y = y; // New Hidden Class based C1 - C2
}

const p1 = new Point(1, 2); // Initcial Hidden Class - C0

또한 두번 이상의 속성 호출에 성공하면 변하지 않았다고 가정하고, 직접 점프를 수행한다. (인라인 캐싱)

컴파일 과정을 배워본 사람, 또는 C로 코딩을 조금이라도 해본 사람이라면 인라인닝을 들어본적이 있을 것이다.

인라인

만약 다른 히든 클래스라면 인라인 캐싱이 깨지는 일이 벌어지게 된다.

내가 알기로 인라인 캐싱을 가장 잘 사용하는 라이브러리 중 하나가 most.js [Improving performance, How comes it so much faster than LoDash?]

V8엔진에서 --trace_inlining 옵션을 켰을때 다음과 같이 나온다고.

Inlined sum called from AccumulateSink.event.
Inlined noop called from Observer.event.
Inlined Observer.event called from AccumulateSink.event.
Inlined even called from FilterMapSink.event.
Inlined add1 called from FilterMapSink.event.
Inlined sum called from AccumulateSink.event.
Inlined noop called from Observer.event.
Inlined Observer.event called from AccumulateSink.event.
Inlined AccumulateSink.event called from FilterMapSink.event.
Inlined even called from FilterMapSink.event.
Inlined add1 called from FilterMapSink.event.
Inlined sum called from AccumulateSink.event.
Inlined noop called from Observer.event.
Inlined Observer.event called from AccumulateSink.event.
Inlined AccumulateSink.event called from FilterMapSink.event.
Inlined FilterMapSink.event called from produce.
250000000000

해결방법

마이크로 최적화가 될 수 있지만..

위 지식을 기반으로 최적화된 코드 스타일을 도출 할 수 있다.

- 가비지 컬렉션

글로벌 변수는 가비지 컬렉션 대상이 아니다.

페이지를 새로 고치거나 다른 페이지로 이동하거나 탭을 닫거나 브라우저를 종료할 때 전역이 정리된다.

반면 함수 범위 변수는 변수가 범위를 벗어나면 정리된다.

함수가 종료되고 함수에 대한 참조가 더 이상 없으면 변수가 정리된다.

const globalVar = {}; // Bad

// Good
fucntion fn() {
  const localVar = {};
}

- 리터럴 할당

리터럴로 할당하는게 좋다.

배열은 리터럴로 할당하는게 빠르며,

객체는 리터럴로 할당하는게 아주 살짝 느리지만 코드의 양이 늘어나 다운로드 받는 시간과 일관성을 생각하면 리터럴이 낫다.

스트링도 리터럴이 살짝 빠르다.

const arr1 = new Array()  // Bad
const arr2 = []           // Good

const obj1 = new Object() // Bad
const obj2 = {}           // Good

const str1 = new String('ABCDEFGHIJKLMNOPQRSTUVWXYZ') // Bad
const str2 = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'             // Good

단, Object의 경우 JSON.parse()를 사용하는게 더 빠름. [Faster apps with JSON.parse(Chrome Dev Summit 2019), 왜 JSON.parse로 객체를 선언하는 방법이 더 빠를까?]

- 31비트 값

V8은 객체와 숫자를 32비트로 표현한다.

객체와 숫자여부를 판단하기 위해 SMI(Small Integer, 각각 1, 0) 비트를 쓰기 때문에 31비트가 남는다.

만약 31비트를 넘는다면 double 타입으로 전환 후 새로운 객체를 생성하여 성능을 깎아먹는다.

따라서 31비트 안(2,147,483,647)에서 사용하는게 좋다.

- 문자열

짧을때는 +=, 길때는 join함수를 사용하는게 좋다.

// Short
let str1 = "";
str1 += "short"

// long
const arr = [];
arr.push("long");
const str2 = arr.join('');

- 배열

희소 배열(sparse array)은 피하는게 좋다.

값이 꽉 채워지지 않은 배열은 해시 테이블과 같으며 접근 비용이 크다.

// Bad
const arr = new Array(5);
const arr[2] = 3;
const arr[5] = 1;

// Good
const arr = [];
const arr.push(3);
const arr.push(1);

배열의 요소를 삭제도 마찬가지.

배열의 키가 띄엄띄엄 배치되어 좋지 않다.

차라리 null로 할당하는게 낫다.

const arr = [3, 1];
delete arr[1]; // Bad
arr[1] = null; // Good

배열 인덱스는 정수에 최적화 되어 있다.

const arr = [];
const arr["1"] = 3; // Bad
const arr[0] = 1;   // Good

또한 커다란 배열을 미리 할당하지 않는게 좋다.

오히려 사용하면서 크기가 커지도록 하는 게 낫다.

상식적(?)으로 이게 말이 되냐 싶었는데.. 벤치마크 결과가 그런다니..

사파리만 예외

const let = new Array(1000000); // Bad
const arr = [];                 // Good

push보다 접근자로 할당하는게 더 빠르다.

const arr = [];

arr.push(3); // Bad
arr[1] = 5;  // Good

객체가 존재하는지 확인하려면 hasOwnProperty가 IndexOf보다 낫다. [Performance comparison between hasOwnProperty and IndexOf]

arr.indexOf(1000000)        // Bad
arr.hasOwnProperty(1000000) // Good

- 객체 접근

차이는 거의 없으나 .이 []로 접근하는 것보다 살짝 빠르다.[Javascript performance consideration. Is dot operator faster than subscript notation?]

개인적으로 IDE 지원면에서 .을 사용하는게 마음에 들더라.

const obj = {a: "test"};

obj['a']; // Bad
obj.a     // Good

스코프 체인 때문에 지역변수로 참조하는게 좋다. [JavaScript Prototype Chains, Scope Chains, and Performance: What You Need to Know(번역)]

// Bad
const arr = [];
function addFn () {
  arr.push("test");
}

// Good
const arr = [];
function addFn () {
  const localArr = arr;
  localArr.push("test");
}

객체도 배열과 마찬가지로 직접 삭제는 나쁜 생각이다.

delete를 한다고 가비지 컬렉션이 일어나지 않으며, 히든클래스만 변경시켜 악영향을 끼친다.

const o = { x: 1 };
delete o.x; // Bad
o.x = null; // Good

역시 히든 클래스 글을 읽으며 알아챘겠지만,

객체를 생성하고 할당할 때, 일정한 순서대로 하는게 좋다.

// Bad
const p1 = new Point(1, 2);
p1.a = 5;
p1.b = 6;

const p2 = new Point(3, 4);
p2.b = 7;
p2.a = 8;

// Good
const p3 = new Point(1, 2);
p3.a = 5;
p3.b = 6;

const p4 = new Point(3, 4);
p4.a = 7;
p4.b = 8;

순서대로 할당하는게 가독성 측면에서도 바람직하기도 하다.

- 동적 속성보단 생성자 사용

객체 생성 후에 속성을 추가하면 히든 클래스가 변경되며, 최적화가 되었던 것들이 해제된다.

따라서 처음에 생성자로부터 할당하는게 좋다.

// Bad
function Point(x, y) {
  this.x = x;
  this.y = y;
}

const p1 = new Point(1, 2);
p1.a = 5;
p1.b = 6;

// Good
function Point(x, y, a, b) {
  this.x = x;
  this.y = y;
  this.a = a;
  this.b = b;
}
const p1 = new Point(1, 2, 5, 6);

- 병합하기

작을때는 스프레드, 클때는 concat이 유리하다. [How to Efficiently Merge Arrays in JavaScript]

- 복제하기

Deepcopy의 경우, 아직 공식명세에는 없지만 주요 브라우저들에 구현된 structuredClone()을 사용해볼 수 있다. [structuredClone(): deeply copying objects in JavaScript]

- 상속 활용

상속을 활용하면 메모리를 아낄 수 있다. [Prototype's real world usage: optimizing memory usage, Creating Memory-Optimized Instances with Constructor Functions and Prototypes]

많은 객체를 생성해야 할 경우 메소드까지 매번 생성 시키는 것은 메모리 관리에서 비효율적이다.

실제로 이러한 이유로 fabric.js는 상속을 활용한다.

// Bad
function Point(x, y) {
  this.x = x;
  this.y = y;
  
  this.add = function() {
    return this.x + this.y;
  }
}
const p1 = new Point(1, 2);

// Good - Protype
function Point(x, y) {
  this.x = x;
  this.y = y;
}
Point.prototype.add = function() {
  return this.x + this.y;
}
const p2 = new Point(1, 2);

// Good - ES6 Classes
class Point{
  constructor(x, y) {
    this.x = x;
    this.y = y;
  }
  
  add () {
    return this.x + this.y;
  }
}
const p3 = new Point(1, 2);

객체 생성관련 내용 이 글들을 참고바란다. [JavaScript Best Practices — Object Creation, Details of the object model, Javascript prototype inheritance, JavaScript 다양한 상속 방법]

Protype과 Class에서 성능차가 나긴 하는데, 서로 빠르다는 말이 있어서..ㅋㅋ

그러나 중요한점!! [The performance hazards of [[Prototype]] mutation]

[[prototype]]은 수정하지 않는 걸 전제로 최적화 되어있다.

성능을 중요시 한다면 수정을 해서는 안된다.

- 객체 할당 최소화

옛날에 Promise가 구현이 안되거나 느렸을때 아주 효율적인 구현을 보여준 Bluebird 제작자의 조언이다. [Three JavaScript performance fundamentals that make Bluebird fast]

함수 내부에 함수 선언 X
객체 크기 최소화
계산이 아닌 함수는 일단 적용하고, lazy하게 덮어쓰며 선택적 기능을 구현

- 동일한 함수

동일한 함수를 반복적으로 사용하는 방식이 인라인 캐싱에 유리하다.

// Bad
function add1(a, b) {
  return a + b;
}
function add2(a, b) {
  return a + b;
}

const a = add1(1, 2);
const b = add2(3, 5);


// Good
function add(a, b) {
  return a + b;
}

const a = add(1, 2);
const b = add(3, 5);

- 동일한 타입

여러 타입을 섞어서 쓰면 최적화에 나쁘다.

// Funciton
function add(x, y) {
   return x+y;
}

add(1, 2);
add('a','b');
add(my_custom_object, undefined);

// Array
const arr = [1, “1”, undefined, true, “true”]);

최근 자바스크립트에서는 TypedArray(형식화배열)를 지원하니 살펴보자.

TypedArray를 사용한 String의 경우 StringView를 참고하라.

- 배열 반복

이번에는 반복이다 [About JavaScript Loop Performance(forEach, for, while, etc…), Which Is the Fastest: While, For, forEach(), For…of?, How to optimize your JavaScript apps using Loops]

while >= for > for of > forEach(native) > forEach(loadsh) > each(underscore)

순이다.

Native가 빠르며, 우리가 C/C++, Java등에서도 배웠듯 더 빠른 것을 알 수 있다.

성능 특성은 반복해야 할 갯수에 따라서도 달라질 수 있다.

milliseconds

작은 곳에서는 For of가, 클때는 While이 유리하며

For은 평균, ForEach는 항상 느리다는 듯 하다.

그럼 map, filter, reduce 성능과 비교하면 어떨까?? [Performance-Analysis JS, for, foreach, filter, map, reduce 기능 및 성능 비교]

for이 빠르다!!

For이 Native 고차함수들 보다 빠름을 알 수 있다.

참고로 객체를 순환할 때 쓰는 For in문은 확연히 느린 편이며 가능하다면, 다른 구분을 사용하는게 좋다.

배열이 아니라 일반 객체로 취급하며, 반복 때마다 property에 접근해야 하기 때문이다.

요약

클 때: While
작을 때: For of
네이티브가 빠름
For in은 상당히 느림

일반적으로 루프 성능이 중요한 프로그램을 짤 일이 있을까 싶으니 For in이 느리다는 점만은 기억해두는것을 추천.

참고로 길이를 지역변수에 할당하면 매번 크기를 체크할 필요가 없고, 역순으로 순회하면 변수가 아닌 상수 0과 비교하므로 약간의 이득이 있다. [실시간 서비스 경험기(배달운영시스템), Are loops really faster in reverse?]

// length를 지역 변수에, 루프 순서를 역으로 
for (let i = (array.length - 1); i >= 0; i--) {
  // for문 내부에 배열을 지역변수에 할당
  const item = array[i];
  //...
};

중첩된 for문 같은 경우, 큰 반복이 안쪽에 있는게 효율적이다. [Does for-loop Nesting Order Affect Performance?]

- 객체 반복

객체를 반복할 필요가 있다면 Map을 사용하는게 좋다. [JavaScript ES6 Map vs Object Performance 비교, Restoring for..in peak performance]

그러나 API로부터 받아오는 정보가 객체 타입이라던지, 일반적인 객체를 이용해야 하는 상황이 있을 수도 있다.

보통의 상황에서는 Object.keys > for in > Object.getOwnPropertyNames, Object.values, Object.entries 순이다. [How to Iterate Over JavaScript Object Entries]

그치만 더 트릭이 필요한 사람이 있을 수도 있다.

그런 분을 위해 이터레이터를 미리 컴파일 하는 트릭을 찾았다. [What's the fastest way to iterate over an object's properties in Javascript?, Faster Collection Iterators]

훨씬 빠르다

요약

보통의 경우 Map
객체 사용이 꼭 필요한 경우 Object.keys + for 루프
더 나은 성능이 필요하다면 Pre-Compiled 이터레이터 기법을 써보는게 어떨까

- 비동기/병렬 루프

비동기나 병렬로 빠르게 반복하는 방법도 존재한다. [JavaScript loops - how to handle async/await, map, reduce 함수에서 async/await 쓰기, ]

Async Loop, Lower is better

거의 차이가 안나며 오히려 확연히 느려지는 경우가 발생합니다.

map과 Promise.all의 오버헤드 때문.

프로미스나 Async는 오버헤드가 존재합니다. [The Performance Overhead of JavaScript Promises and Async Await]

그렇다면 워커를 이용해 멀티 쓰레드로 실행한다면?

훨씬 나아지는 것을 확인 할 수 있다.

요약

네트워크 연결같이 비동기가 꼭 필요한 경우가 아니라면 굳이 비동기적으로 반복할 필요가 없음
빠르게 만들고 싶다면 멀티 쓰레드로.

- 조건문

삼항연산자가 if문보다 성능이 좋다. [Is ternary operator, if-else or logical OR faster in javascript?]

최근에 JS Perf에 들어가서 측정했다.

신기한 점은 ===를 사용할 때가 가장 빨랐으며, ==를 사용할때는 확연히 느렸다는 점이다.

const a = true;
let b;

// 1st: 590,142,828 Ops/sec
b = (a === true) ? true : false;

// 2nd: 589,956,625 Ops/sec
if (a === true) {
  b = true;
} else {
  b = false
}

// 3rd: 574,265,651 Ops/sec
b = (a) ? true : false;

// 4th: 570,864,623 Ops/sec
if (a) {
  b = true;
} else {
  b = false;
}

// 5th: 33,590,726 Ops/sec
// 94% slower
b = (a == true) ? true : false;

// 6th: 33,215,602 Ops/sec
if (a == true) {
  b = true;
} else {
  b = false;
}

또한, 조건문이 많아질 때는 switch가 if보다 유리하다. [Chapter 4. Algorithms and Flow Control]

이는 고전적인 언어와 똑같은 듯.

- 느긋한 계산

지연 평가를 사용하여 성능 개선을 할 수 있다. [지연 평가(Lazy evaluation) 를 이용한 성능 개선, How to Speed Up Lo-Dash ×100? Introducing Lazy Evaluation(번역)]

보다시피 필요한 계산만 하는 것.

결과

- 정규식

정규식은 컴파일 - 시작위치 결정 - 토큰 대조 - 결과(성공, 실패) 순으로 이루어진다. [High Performance JavaScript - Chapter 5. Strings and Regular Expressions]

정규식 컴파일 시에는 매번 에러가 있는지 검사하게 되므로, 한번만 컴파일되게 하는것이 좋다.

// Bad
for (let i = 0; i < 100; i++) {
  str.replace(/^\s+/, '').replace(/\s+$/, '');
}
 
// Good
const reg1 = /^\s+/;
const reg2 = /\s+$/;
for (let i = 0; i < 100; i++) {
  str.replace(reg1, '').replace(reg2, '');
}

정규식 작성에 있어 가장 쉬운 최적화는 보다 간단하게 만드는 것이다.

간단한 예는 각종 그룹을 하나로 만드는 것이다. [예제들]

const re = /[a-zA-Z_0-9][A-Z_\da-z]*\e{1,}/; // Bad
const re = /\w+e+/; // Good

eslint-plugin-optimize-regex

정규식을 분리시켜 불필요한 탐색이 반복되지 않도록 할 수 있다. (탐색 대상 축소)

아래 동작은 Trim을 하는데, 정규표현식은 문자열 마지막으로 건너뛰는 동작이 불가능하므로 첫번째 코드는 비효율적이다.

trim12의 경우 Faster JavaScript Trim의 최적화가 적용된 코드.

// Bad
str.replace(/^\s+|\s+$/g, "");

// Good
str.replace(/^\s+/, '').replace(/\s+$/, '');

// Trick
function trim12 (input) {
  const	str = input.replace(/^\s\s*/, '');
  const ws = /\s/;
  let i = str.length;

  while (ws.test(str.charAt(--i)));
  return str.slice(0, i + 1);
}

정규식 매칭 시 느려지는 주요 이유는 "일치하는 것을 찾는데" 걸리는 것이 아니라 "일치하지 않는다고 판단"하는데 시간이 소모되기 때문이다.

- 비트 다루기

전통적인 트릭이다.

좋은 에디터란?

BlaCk_Void — Fri, 12 Feb 2021 23:00:51 +0900

좋은 에디터는 어떤걸까...?

지금 구현해야 한다면 어떻게 할까?

를 고민한 내용이다.

직접 만들기엔 시간과 복잡도가 내게 너무 크지만..

3월 업데이트!! 3/19에 Emacs NG에 합류했다.

github.com/emacs-ng

Emacs NG

Emacs New Generation. Emacs NG has 2 repositories available. Follow their code on GitHub.

github.com

우연히 emacs-ng(이슈)라고 Emacs + Deno란 끔직한 혼종(?)을 발견했다.

저 끔직한 혼종은 Remacs에 풀리퀘스트로 날라왔던 Webrender까지도 지원하고 있었다.

Emacs X Deno??

덕분에 Remacs 프로젝트가 잘 돌아가나 확인하니 2020년 들어 업데이트가 안되고 있었다.

Still Alive/Lost Momentum?란 이슈에서

For the most part, the stuff that's left to do is hard. The garbage collector, the bytecode interpreter, anything like that. If we were all getting paid to work on it I'm sure we could figure it out, but as things are now, it's quite a challenge.

It's important to keep some perspective though. If we look at Remacs as a serious attempt to replace the C core of Emacs with Rust, then we can safely call it a failure, because that isn't going to happen any time soon, maybe ever. BUT, if we look at Remacs as a proof-of-concept to show that it would be possible to do such a replacement, then I would call it a wild success.
- 콜라보레이터

Although I'm glad there have been more upstream changes than I expected, I think it would have been possible if there wouldn't be that much new code we have to deal with. It's work that doesn't really pay off.

Maybe we can see this as a decision of the emacs community to stick with things how they are. It's not realistic that such an ambitious project can be handled by a few people since we have to update remacs for code by many more people that lands in upstream.
- 멤버

(대충 너무 복잡해서 못해먹겠다는 소리)

란 코멘트를 보게 되었다.

이맥스의 구조가 얼마나 복잡하냐. ㅋㅋ

이맥스 GUI의 뿌리인 xdisp.c로 알 수 있다.

   /*
   +--------------+   redisplay     +----------------+
   | Lisp machine |---------------->| Redisplay code |<--+
   +--------------+   (xdisp.c)     +----------------+   |
	  ^				     |		 |
	  +----------------------------------+           |
	    Block input to prevent this when             |
	    called asynchronously!			 |
							 |
		    note_mouse_highlight (asynchronous)	 |
							 |
				    X mouse events  -----+
							 |
			    expose_frame (asynchronous)	 |
							 |
				   X expose events  -----+
*/

GNU Emacs is an old-school C program emulating a 1980s Symbolics Lisp Machine emulating an old-fashioned Motif-style Xt toolkit emulating a 1970s text terminal emulating a 1960s teletype. Compiling Emacs is a challenge. Adding modern rendering features to the redisplay engine is a miracle.
- Buttery Smooth Emacs

인용글의 링크를 읽어보라.

그저 웃음만 나올 것이 틀림없다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

구조도 문제지만 1.1mb의 코드는 더하고 ㅋㅋㅋㅋㅋㅋ

반면 lisp.h, eval.c, bytecode.c처럼 Elisp VM쪽 코드는 각종 C 트릭이 있다고 하지만 사정은 나은 편이다.

여기서 확 든 생각.

웹브라우저를 따라서 모듈화나 아키텍쳐 구성하면 되는거 아냐?? (comment)

Emacs VM(JS VM) + Xi-Editor(Web APIS) 조합으로

Understanding Event Loop, Call Stack, Event & Job Queue in Javascript, 움짤로 보는 자바스크립트 동작 원리(1) - Event Loop

사실 Dart의 이벤트 루프가 마음에 더 든다. [Flutter Threading: Isolates, Future, Async And Await]

여기서 촉발되어 내가 생각하는 이상적인 에디터와 관련된 글을 쓰게 되었다.

기본적인 생각은 Swiboe의 접근(The Ideal Text Editor, Design for the ideal text editor)과 비슷하다.

무료: 무료가 아니면 요즘 누가 쓸까?
실현 가능성: 실현 가능해야 한다. 기존의 시스템을 최대한 활용하자.
크로스 플랫폼: 어디서든 실행 가능해야 한다.
성능: 당연하지만 빨라야 한다.
확장 가능성: 간단한 모듈이나 스크립트, 매크로 형태는 물론 플러그인을 지원하고 UI의 수정까지 가능해야 한다.
협업: 실시간으로 협업이 가능해야 한다.

이맥스의

를 읽어도 기본적인 생각은 비슷한 듯.

그리고 OSI 7 Layer처럼 추상화가 이루어져

Lv1 코어: 에디터 엔진, 스크립트 VM, I/O 기능 등이 들어간다.
Lv2 프론트: 각종 기본 UI 컴포넌트와 API 구현에 집중.
Lv3 스타터 키트: VS Code처럼 기본적으로 사용하는데 무리가 없을정도로 제공.
Lv4 IDE: 디버깅, 프로파일링등 다양한 부가기능이 통합적으로 제공된다.

와 같은 기능이 될 수 있다.

Lv1 코어

핵심 가치

코어의 핵심가치는 앞서 제시한

크로스 플랫폼: 이식 가능성을 고려해야함.
성능: 백엔드다. 절대적으로 빨라야 할 필요가 있다.
확장 가능성: 백엔드단 부터 고려되어야 함.
협업: 네트워킹 및 동시 편집도 백엔드단 부터 고려될 필요가 있음.

참고할 만한 프로젝트

Neovim과 libvim, Xray, xi-editor는 에디터의 벡엔드 가능성을 충분히 실험 해주었다.

Neovim · Delft Students on Software Architecture: DESOSA 2017

Onivim 2 - Update #3: A re-architecture...

Xray

Xi: an editor for the next 20 years

특히 xi-editor의 텍스트에 대한 연구와 집착은 놀라운 수준이다.

공식문서의 CRDT(Conflict-free Replicated Data Type)와 Rope에 대한 글을 읽어보자..

디자인

Emacs: The Editor for the Next Forty Years에서도 그렇듯 새로운 프로젝트는 Rust를 적극적으로 활용하는 듯한 모습을 보인다.

위에서 소개한 Swiboe, Xray, xi-editor말고도

등이 있다.

그럼 Rust로 코어를 구성한다고 가정하고, 필요한 기능은 무엇이 있을까?

그리고 어떻게 구성해야 될까.

Chrome, Firefox Safari Architecture(How Web Browsers Work — Behind the scene Architecture, Technologies, and Internal Working)

Chorme's Multipress

앞선 에디터 아키텍처와 브라우저 아키텍처를 참고했을때 난

Editor
- Editor Engine: 텍스트 편집, 협업 등을 위한 기능
- Rendering Engine: 말그대로 렌더링과 관련된 기능
External Process Manager
- VM: JS, Elisp, Guile처럼 확장을 위한 언어
- Parser
- LSP(Language Server Protocol) & DAP(Debugging Adapter Protocol)
- Shell
I/O

정도로 요약할 수 있다고 생각한다.

여기서 몇가지 결정은 많은 궁금증을 자아낼 수도 있다고 생각한다.

아마 뒤이은 설명들을 읽다보면 해소되기를 바란다.

Editor Engine

앞서 소개한 Xi-Editor가 가장 적합하다고 생각한다.

Xi-Editor는

비동기 디자인
다중 프로세스 아키텍처
텍스트 저장을 위한 Rope 구조
동시 수정을 위한 CRDT

처럼 기본기가 매우 뛰어나다.

Rope 데이터구조는 최악의 경우에서 성능문제가 적으며, [Data Structures used in Text Editors]

CRDT를 이용해 중앙서버가 없이도 협업 편집이 가능하다.

(Gapbuffer, Zipper(JS 구현), Piece table도 흥미로운 데이터구조다)

CRDT의 모델이 상당히 복잡해서 적합하냐는 말들도 있다.

다음 글은 이에 대한 의문을 해소시켜준다.

Are CRDTs suitable for shared editing?

VM이 있다지만, 에디터 엔진도 확장 가능하게 만드는게 맞다.

예를 들어 프로젝트 단위에서 코드를 검색하기 위해 ripgrep을 활용하려 한다면? (스타터킷에서 활용할 수 있다)

러스트의 터미널 유틸리티 관련 생태계는 상당히 발전해서 참고할만한 것들이 꽤나 있다.

몇몇은 에디터 엔진에 통합하여 사용해도 좋을 듯 하다.

Text Processing

대규모 텍스트에 대한 대응도 이루어져야 한다.

klogg처럼 디스크에서 읽어온다던가.

여기에 추가될 것 하나.

키맵 관련이다.

Beyond Vim and Emacs: A Scalable UI Paradigm(rigpa)

위 링크는 키맵에 대한 일반적인 형태를 제안한다.

Mode Tower

키맵 자체는 관리하고, 프론트단에서 세부적인 사항(예: Vim 키맵, Nano 키맵 등)을 구현하면 된다.

Rendering Engine

모듈화된 코어라 하면 Front 코드가 없는게 맞지 않을까 생각할 수 있다.

하지만

와 같은 기능을 구현하기 위해서는 백엔드부터 고려되어야 한다.

또한, 프론트단의 파편화와 수고를 줄이기 위해 렌더링 엔진을 통합하는 것도 나쁘지 않은 결정이라 생각한다.

신규 플젝에서 파편화가 많이 생긴다면 더더욱 퍼지기 힘들다.

아마 가장 좋은 것은 WebRender + Pathfinder 조합이 아닐까.

둘 다 상당히 낮은 레벨의 구현이므로 GUI 툴킷과는 구분될 수 있다.

텍스트 렌더링 관련 좋은 시리즈를 발견했다.

Modern text rendering with Linux: Overview
Modern text rendering with Linux: Part 1
Modern text rendering with Linux: Antialiasing
State of Text Rendering(다른 시리즈. 그러나 좋은 글이다.)

Pathfinder가 Freetype을 대체할 수 있다고 한다.

가장 먼저 고려할 만한 것은 자바스크립트다.

방대한 NPM의 라이브러리를 모두 사용할 수 있으며, 프론트/스타터 킷 레벨에서 Visual Studio Code 호환 API를 제공하면 Market Place의 확장기능들을 사용할 길이 열린다.

아마 Deno를 통합하면 간단할 것이다.

Elisp나 Vim Script를 쓰고 싶다고??

Elisp는 앞서 말한 Emacs 소스를 사용하거나 Emacs 유저들의 꿈 중 하나인 Guile(소스) Emacs를 구현할 수 있겠고,

Vimscript는 NeoVim의 Eval을 떼어내던가 해야지..

내가 Emacs 사용자에 Vim 키맵도 좋아하지만, Deno가 최선의 선택지 아닐까.

Parser

LSP를 지원함에도 대체 왜!!

파싱과 관련된 모듈이 지원되어야 하는가 의문이 들 수 있다.

그렇다면 다음 글들이 답이 될 수 있다.

LSP도 구문강조를 할 수 있다.

그러나 실시간 문법 강조나 점진적 분석(Incremental Parsing)이 힘들다.

베스트라 하면 Lezer의 Rust 버전이겠지만, Tree-Sitter도 충분히 좋다고 생각한다.

마크다운 파서에 관련된 글을 찾다보니

란 글도 잼나네. ㅎㅎ

LSP(Language Sever Protocol) & DAP(Debugging Adapter Protocol)

자동완성에서 company-mode/auto-complete, 디버깅에서 GUD/RealGUD처럼 바로 인터페이스를 구현 후 하나하나 대응하는 것보단 LSP, DAP를 구현만 하는게 낫지 않겠는가?

최근에 만들어지는 에디터라면 LSP/DAP를 지원하지 않을 이유가 없다.

비록 C/C++ 전용이지만 rtags같은 인덱서도 꽤나 매력적이다.

Shell

유닉스의 강점 중 하나는 강력한 커맨드 라인이다.

기존에 있던 걸 잘 쓰면 당연히 좋은거 아니겠는가?

Shell을 적극적으로 활용하던 에디터가 있다.

Shell Commands — TextMate 1.x Manual (macromates.com)

그때그때 명령하거나 저장된 것을 활용하거나.

맥에서 Notepad++(윈도우), Kate(리눅스)처럼 사용하던 TextMate의 텍스트 필터 기능이다.

I/O

검증된 라이브러리인 Tokio를 베이스로.

여긴 무슨 할말이 더 있을까.

다만 커다란 크기의 파일을 위한 모드가 있어야 한다.

Em Editor
Atom과 VS Code의 이슈

에디터 성능과 관련된 벤치마크 두개

Lv2 프론트

핵심 가치

코어의 핵심가치는 앞서 제시한

크로스 플랫폼: 각 플랫폼 특화 기능 제공.
성능: GPU를 이용한 프로세싱, 최소 60fps를 지원하며 낮은 키입력 레이턴시, 부드러운 스크롤.
확장 가능성: UI 커스텀이 쉬워야 한다.

처음에 Vim을 생으로 사용해본적 있는가?

리눅스를 처음 다루었을 때였는데 명성에 비해 실망을 했었던 기억이 난다.

아무리 확장 가능하다지만 너무한 수준으로 기능이 없어보였다.

사실 기초가 되는 프론트 단은 그래도 상관없다.

대신 쓸만한 수준으로 확장가능하고 커스텀이 가능한게 좋지 않을까.

Vim/Gvim 정도가 딱 좋다.

참고할 만한 프로젝트

Flutter vs React Native — Comparing the Features of Each Framework | by Vitaly Kuprenko | Level Up Coding (gitconnected.com)

플러터의 아키텍처는 확실히 참고해볼만 하지 않을까.

Servo WebRenderer for Xi front-end · Issue #140 · xi-editor/xi-editor · GitHub

Servo WebRenderer for Xi front-end · Issue #140 · xi-editor/xi-editor

I like the way you think, first goal: performances. But I think about something else: performances, multi-OS and customization. That's just something I think about and I believe I'm not the...

github.com

TUI

Rust로 TUI 구현은 문제 없다고 생각한다.

tui-rs란 검증된 라이브러리가 존재하기 때문.

Rust and TUI: Building a command-line interface in Rust

하지만 터미널과 관련된 이슈를 몇가지 적다면

색상: Turbo Vision처럼 BIOS 4bit, Xterm 256(8bit), True Color(24bit), 터미널 기본 색상지원
이벤트: 단축키와 마우스 지원
클립보드: 상호작용 가능해야 한다.
위젯: 2D 셀 형식 말고, 팝업형태도 지원 가능, 반응형(터미널의 크기는 바뀔 수 있다)
이미지 표시: libsixel이나 chafa를 이용한 이미지 표현 | viu란 러스트 이미지 라이브러리도 있다.
성능: TTY로의 빈번한 정보 업뎃은 느리게 만들며, 리페인트되는 영역이 많으면 플리커링이 생기기 때문에 상태관리가 되어야 한다. (버퍼링, 이벤트 루프, 반복된 시퀸스 방지, 동일한 셀 유지등의 기법이 가능하며 심지어 가상터미널을 구현할 수도 있다. ImTUI, Vty도 흥미롭다)
기타: Terminfo, 유니코드 지원등

기타 TUI 라이브러리들

Other TUI libraries of note

검색하다 Oberon이란 신기한 물건 발견 ㅋㅋ

BearLibTerminal도 재밌음.

GUI

사실 러스트의 GUI는 매우

Rust GUI: Introduction, a.k.a. the state of Rust GUI libraries (As of January 2021)에서 잘 소개해주고 있다.

가 흥미로워보이긴 한다.

텍스트 레이아웃에 대한 좋은 글.

진정 텍스트에 대한 고민이 느껴진다. (로드맵, 설명, 결과물)

https://raphlinus.github.io/text/2020/10/26/text-layout.html

Text layout is a loose hierarchy of segmentation

I love text layout, and have been working with it in one form or other for over 35 years. Yet, knowledge about it is quite arcane. I don’t believe there is a single place where it’s all properly written down. I have some explanation for that: while bas

raphlinus.github.io

GUI는 이슈가 너무 많아서 터미널과 달리 나열하기가 힘들지 않나.

대신 최근에 알게된 설계 패턴이나 기억하는 용도로.

기타 인텔리J 개발자의 다양한 고민

키맵

개인적으로 사용하는 키맵은 엄청난 혼종이다.

대충 서술하자면

Emacs: 이맥스 유저니 당연하다.
이맥스의 키맵은 구린걸로 유명하며 수많은 키맵들을 양산 시켰다.
나도 이맥스 유저지만 Ctrl+n(next, 다음 줄로 이동), Ctrl+p(prev, 전 줄로 이동) 같은 구린 키맵은 RSI를 유발한다고 믿는다.
그러나 Ctrl+h(도움말), Ctrl+c(모드 관련), Ctrl+x(기타)같은 프리픽스 키 시스템이나 Ctrl+g(취소), Alt+x(명령)는 잘 만들어졌다.

프리픽스 키 시스템이 왜 좋냐?
수많은 경우의 수를 창출 가능하며 프리픽스키를 통해 보다 직관적인 모달 에디터에 가까워질 수 있다.
예를 들어 한글 워드프로세서 사용자라면 알 수 있다.
<Ctrl+k h>(하이퍼링크), <Ctrl+k o>(개요)처럼 비슷한 기능끼리 직관적으로 모아놓는게 가능하며 능숙한 사람이라면 키보드만으로도 사용이 가능하지 않은가?
Evil: 최고의 Vim 키맵 에뮬레이터. 기존 키맵과 완전히 통합된 것은 Evil-Mode 밖에 없다고 생각한다.
IdeaVim/ViEmu도 나쁘지 않지만.. 기존 키맵과 통합이 뭔가 부족함.
Terminal Based Common: Ctrl+c, Ctrl+v는 이맥스 키맵과 겹친다.
이를 해결하기 위해 내장된 CUA(Common User Access) 키바인딩도 충돌 해결이 안되서 섞어쓰기 어렵다.
원래 이맥스 키맵과 충돌을 피하기 위해 같은 Ctrl+c/Ctrl+x라도 블럭 지정시 복사/잘라내기(이맥스 프리픽스키는 Ctrl+Shift+c/Ctrl+Shift+x), 안했을때는 이맥스의 프리픽스로 지정이 되나 추가되는 기능인 Whole Line or Region 개념, Vim의 Ctrl+v등과 충돌, 일부 이맥스 키맵의 변경등 때문에 사용성에 문제가 생긴다.

그러나 Ctrl+Shift+c, Ctrl+Shift+v 형태로 일반적인 키맵들을 설정하면 충돌 위험이 없다.
Ctrl+Shift+x(잘라내기), Ctrl+Shift+z(undo), Ctrl+Shift+r(redo), Ctrl+Shift+n(새 파일), Ctrl+Shift+o(파일 찾기등등처럼 하면 되며 CUA모드처럼 쓰고 싶으면 Capslock을 사용한다.

Cua 모드 전용 기능 중 Cua-Rect 하나만큼은 발군으로 Rectangle Selection Mode를 대체해서 사용 중. [More Batteries Included with Emacs]
일부 Brief : Emacs의 Brief-Mode/Brf-Mode, Brief Keyboard Layout, Cheet Sheet 문서들을 읽어보면 알겠지만 Home/End 키 연타(라인-윈도우-파일 순으로 이동)처럼 번뜩이는 아이디어가 참 좋다.
Emacs도 의미 기반으로 이루어졌지만, Brief 키맵이 훨씬 설득력 있는 듯.

추가적으로 고려중이었던 것 몇가지..

Emacs 키맵의 확장/변형: Epsilon이란 에디터(공식, RAD Studio, SlickEdit), Boon, Fingers 참고
Vim 키맵의 통합/확장/변형: Vile의 통합, Vis의 sam에디터 구조적 정규표현식 및 명령 언어를 이용한 확장, Kakoune의 변형
Common 키맵: Visual Studio/Viusal Studio Code등의 키맵을 겹치지 않는 선에서 도입해볼 수 있다.

물론 확장과 변형은 정답이 아닐수도 있지만 sam 에디터 구조적 정규표현식은 흥미로운듯.

좋은 에디터라면 다음의 키맵을 기본적으로 선택가능해야 한다.

Common

Atom, Vistual Studio, Visual Studio Code, IntelliJ, Sublime등처럼 일반적인 키맵을 베이스로 한다.

다만, 앞서 소개한 Brief, Emacs, Emacs Others(Boon, Fingers)의 장단점을 잘 분석하여 인체공학/의미기반/호환성등을 염두하여 Global Keymap을 만들 필요가 있다.

Vim

Vim 에뮬레이션에 충실

Emacs

Emacs 에뮬레이션에 충실

Vim+

내가 쓰고 있는 키맵과 같은 혼종. 그러나 재설계가 포함되어 있다.

Global Keymap
수정된 Vim 키맵 포함

기타 UI 요소

툴바, 상단메뉴, 콘텍스트 메뉴(우클릭 메뉴), 팝업, 스플릿 등의 기본적인 UI 요소들은 모두 제공되어야만 한다.

Lv3 스타터 킷

핵심 가치

즉시 사용: 잘 설정되서 바로 쓰기 편한 상태여야 한다. VS Code나 Doom Emacs가 예시로 쓰일 수 있음.
UX: 일관성있고 자동화된 사용자 경험을 제시 해줘야한다.
다양한 기능: Git, 프로젝트 단위로 열기 등은 이제 필수 기능이다.
가벼움: 그럼에도 불구하고 가벼워야..

VS 코드와 둠 이맥스가 가장 적절한 예.

원래 IDE에 들어갈만한 기능이라지만,

요즘은 다음 정도 부가기능은 기본으로 들어가야 하지 않을까.

버전관리/배포
원격접속/협업
파일/터미널/워크스페이스

Lv4 IDE

다양한 부가기능: 리소스 에디터, DB/HTTP 클라이언트, 노코드 블럭 기능?(예1, 예2)

통합: 문서(dash 같은?), 프레임워크(SwiftUI, RAD Studio, XAML Designer), 빌드/컴파일/커버리지/에뮬레이터,
디버깅/프로파일링/디컴파일러

쿠팡 마케팅 전략 보고서 공개

BlaCk_Void — Fri, 30 Oct 2020 13:17:32 +0900

최근 쿠팡이 중고거래 시장에 진출한다는 뉴스를 보게 되었다.

news.v.daum.net/v/20201028030208951

'고객 2000만명' 쿠팡, 중고거래 시장 진출 채비

쿠팡이 중고거래 시장에 뛰어드는 것으로 알려졌다. 2300만 명에 육박하는 사용자 규모와 거대한 자체 물류 인프라를 보유한 이커머스 공룡 쿠팡이 뛰어들면서 당근마켓을 비롯한 스타트업들이

news.v.daum.net

문득 작년에 만들었던 보고서가 생각나서 올려본다.

경영정보시스템 시간(이라 쓰고 인터넷 마케팅)에 만들었는데,

문서와 보고서는 물론 전반적인 컨셉, 구조, 아이디어를 거의 다 만들거나 손봤기 때문에 밥을 많이 얻어먹었던 기억이 ㅎㅎㅎ

발표까지 담당했기 때문에 설사 공개 후, 옛팀원이 봐도 뭐라 안하겠지..

분할 압축된 보고서입니다.

경영쪽은 오픈된 보고서들이 적은데 참고하세요.

오픈 서베이 자료들이 정말 유용했었다.

마케팅이나 전략 관련 보고서를 짜려는 분들은 오픈 서베이 꼭 들어가보길 권합니다.

인터넷마케팅전략사례_01조_Anonymous.7z.001

10.00MB

인터넷마케팅전략사례_01조_Anonymous.7z.002

9.97MB

마케팅을 배우며 고민했던 것은 각종 분석 방법을 어떻게 통합해서 솔루션을 낼 수 있을지 였다.

여러방안을 생각했었는데 결국 채택한 것은

분석

3C: 고객(Customers), 경쟁(Competitors), 자사(Company)

또는

5 Forece: 전통적 경쟁자(Traditional Competitors), 새로운 시장 진입자(New Market Entrants), 대체 제품과 서비스(Substitute Products and Services), 고객(Customers), 공급자(Suppliers)

를 살펴 전반적인 상황을 파악한다.

그 후 조사할 기업을 더욱 자세히 파악하기 위해, 현재 펼치고 있는 마케팅 전략을 분석해본다.

STP: 세분화(Segmentation), 표적 시장(Targeting), 위상 정립(Positioning)
5C: 4P의 업데이트된 방안. 협업(Collaboration), 컨텐츠웨어(Contentware, Product와 비슷), 가치(Commitment, Price와 비슷), 소통(Communication, Promotion과 비슷), 채널(Channel, Place와 비슷)로 이루어져 있다.

해결방안

얻은 정보들을 토대로 분석을 해야한다.

이때 썼던게

SWOT: 강점(Strength), 약점(Weakness), 기회(Opportunity), 위협(Threat)

본디 SWOT는

SO전략 : 강점을 가지고, 기회를 살리는 전략
ST전략 : 강점을 가지고, 위협을 최소화하는 전략
WO전략 : 약점을 보완하며, 기회를 살리는 전략
WT전략 : 약점을 보완하며, 위협을 최소화하는 전략

을 세우는 것이 맞지만, 근시안적인 대책위주로 나올 가능성이 높기 때문에(약간 Local Optimum 느낌),

마치 재귀적으로 STP와 5C를 사용해 새로운 전략을 세우기로 했다. (시간 문제도 있었다)

해결방안에는 전략의 실행을 위해 계획, 예산, 절차를 염두해둘수도 있다.

아래 그림파일들인 PPT입니다.

자세한 내용은 보고서 보세요.

인터넷마케팅전략사례_01조_발표_Anonymous.pdf

3.53MB

대신 당시 중간고사 기간과 겹쳐서 죽을뻔 했었던 기억이 ㅋㅋㅋ

발표날 아침까지 보고서와 파워포인트를 잡고 싸웠다.

소개

팀에 외국인도 있었는데 이름이 긴점을 이용해, 마치 로켓모양처럼 만들려고 했었다.

분석 부분의 STP는 겹치므로 제외시켜 깔끔하게 만들었다.

마치 코딩에서 줄을 띄워 컨텍스트를 구분하는 것처럼 직관적으로 구분할 수 있도록 했다.

인터넷 마케팅과 유명한 쇼핑몰을 생각하다보니 핫한 기업인 쿠팡 해보는게 어떨까??

라는 말이 나와 선정하게 되었다.

마침 당시 손정의와 투자에 관련한 여러 뉴스들이 쏟아져서 적기라 판단했다.

기업 소개는 간단히 CEO, 투자받은 내역, 쿠팡의 서비스.

분석

분석의 시작. 3C.

시장과 미래 예측, 그리고 쪼그라드는 오프라인.

코로나 때문에 가속화 될 듯?

비교대상은 워낙 많아서 자원의 한계로

유통 대기업 E마트, 오픈마켓 왕 이베이의 대표 옥션, 똑같이 소셜커머스로 시작한 티몬을 골랐다.

쿠팡의 특징이라면,

직매입에서 나오는 적자.
소프트뱅크의 매각설과 동시에 비전펀드 투자.
사업 확장(물류, 오프라인, 해외, 할인)

다음은 5C 차례.

중소기업과 상생을 위한 여러가지 지원과 월정산 시스템으로 높은 성장률을 보여준다.

컨텐츠웨어에서 처음 분석한 것은 메인 메뉴다.

쿠팡: 배송, 직구, 프레시, 정기배송 등 배달 관련 메뉴를 잘보이도록 배치해놓은 걸 알 수 있다.
이마트: 신세계, 이마트, 트레이더스, 까사미아 등 상이한 느낌의 브랜드를 함께 서비스하기 어려웠는지 들어가는 탭으로 만들어놓았다.
옥션: 지마켓 등과 같이 쓸 수 있는 스마일배송, 스마일 클럽이 있다.
티몬: 무료배송데이, 1212타임, 특가, 10분어택 등 각종 이벤트가 눈에 띈다.

로딩속도가 1초 빨라지면 아마존의 판매량이 1% 증가, 월마트의 전환율은 2% 증가한다는 것처럼 성능은 매출에 직결된다.

첫로딩(캐시가 꺼진 상태)와 재방문(캐시가 켜진 상태(를 비교해보았다.

쿠팡이 가장 빨랐다.

UI/UX는 레이아웃의 일관성, 가독성 그리고 특색들을 비교했다.

쿠팡: 일관성 있는 레이아웃과 호버 인터렉션 구성, 메가드롭다운으로 3단계 메뉴를 빠르게 볼 수 있음
이마트: 상단은 눈에 띄게 구성되어 있으나 레이아웃이 무려 6번이나 변화하며 간혹 그리드가 심하게 깨진 경우가 존재, 상품에 마우스를 올리면 뒷면과 메뉴를 보여주는 인터렉션이 인상깊었음.
옥션: 간결하고 명확하나 일관성이 떨어지고 보여주는 상품의 양이 적다.
티몬: 일관적인 레이아웃, 상품이미지가 큼직큼직하며 이벤트-인기-신규 상품의 카테고리 접근이 직관적

쿠팡-티몬-이마트-옥션 순이었다.

쿠런티는 최저가 보장제도이다.

쿠런티 인증 상품이 배송비를 포함해 더 저렴한 상품이 다른 사이트에 존재한다면 차액을 쿠팡캐시로 보상받을 수 있다.

쿠페이는 간편결제 시스템으로 번거로운 결제 과정을 거치지 않도록 하며, 로켓와우클럽과 쿠팡이츠 등 핵심 서비스의 기반이 되었다.

촉진요소 중 하나로는 멤버쉽 시스템이 있다.

쿠팡: 로켓배송 무료, 당일배송, 신선식품, 무료 반품처럼 배송에 초점이 맞춰져 있다.
옥션: 연장시 할인, 캐시백, 첫가입캐시, 적립과 할인처럼 할인위주의 정책이다.
티몬: 비싸지만 소셜커머스로 시작한 업체답게 멤버쉽 전용 특가, 전용딜 무료배송과 균일가격에 혜택이 컸다.

옥션을 가장 많이 사용했고, 쿠팡의 만족도가 높았다.

여기선 4개를 기준으로 정렬했다.

쿠팡
- 아마존처럼 카테고리별로 모아 배치하지 않고, 입출고 시점을 예측해 상품의 크기와 동선을 고려해 배치하는 렌덤스토
- 쿠팡 직원인 쿠팡맨 이외에 일반인 배송파트너인 쿠팡 플렉스. 물류 물량을 유동적으로 대응가능하다.
이마트
- Ne.O란 물류센터는 상품 픽업 오류 방지, 완충재 포장, 콜드체인(영상 10도 이하의 일정 온도를 유지), 검수 시스템이 존재
- 매장 후방에 P.P(Picking & Packing) 센터를 만들고 온라인 주문이 들어오면 매장 직원이 포장해 배송. 그러나 최대 출고량 문제가 존재.
옥션
- CJ대한통운과 협력해 스마트배송 전담택배 서비스를 만들었다.
- 1회 배송비로 여러 상품을 묶음배송 받을 수 있다. (예: 인천 해외 물류센터는 소량의 여러 베품을 구매할 경우 묶어 배송하는 합배송을 지원해 세금을 아낄 수 있다.)
티몬: 제2 물류센터 건립이 좌초되어 물류면에서 부족한 점이 많다.

해결

앞서 이야기했듯, 이 보고서의 SWOT는 정리를 하는 역할을 하여 전반적인 경향을 살피는 역할만 담당한다.

쿠팡은 상당한 강점과 기회가 존재하는 회사지만, 적자와 경쟁심화 문제가 가장 심각했으며 풀어야될 목표로 정했다.

고객을 세분화하는 과정이다.

먼저 인구통계.

행동성향을 찾았다.

스마트폰 이용이 많음
오프라인 구매의 요인: 직접 확인하기 위함과 배송이 편리
온라인 구매의 요인: 편의성과 가격

과 장바구니 사용 습관을 알 수 있었다.

최우선 타겟 고객은 여전히 IT기술에 익숙하고 구매력이 높은 2-30대다.

그러나 현재의 싼 가격을 강조하는 정책보다 가치를 강조해야 한다고 생각했다.

적자를 해결하고, 경쟁이 심화될때 차별화를 위해서는 가치를 강조하는게 가장 현명하다고 봤다.

CEO의 말은 가격/프로모션보다 가치에 중시하자는 의견을 뒷받침해준다.

그래서 최종적으로 정한 포지션은

싸고 빠른 배송을 지원하는 쇼핑몰에서 배송, 커뮤니케이션을 잘하는 IT 기업으로 인식을 바꿔야 한다는 것이다.

현재 쿠팡은 쇼핑몰이라 생각하는 사람이 많은 반면, 아마존은 IT기업이라 생각하는 사람이 많지 않은가?

아마존은 AWS, 킨들 등으로 테크회사란 인식이 있지만 쿠팡은 IT회사로서 내세울게 마땅치 않다.

나는 키워드 강조를 매우 중시하는 편.

명확하게 생각을 전달하는데 도움이 된다.

기술은 고부가가치 산업이다.

쿠팡도 물류센터의 회전율을 높이기 위해 IT기술을 적극적으로 활용하고 있으며 좋은 UI/UX를 제공하기 위해 노력을 많이한다.

IT회사라고 주장하지만 아직 허울뿐으로만 외침을 실체화할 필요가 있다.

현재 쿠팡의 지위를 만든 것은 배송이라 해도 과언이 아니다.

강점을 포기할 필요는 없으며 계속 강화, 이용해야 한다.

커뮤니케이션.

어찌되었건 쿠팡은 소셜 커머스라는 예전과 다른 형태로 시장에 진입했지만, 현재는 특색을 잃어버렸다.

다시 기존 쇼핑몰의 형태와는 다르다는 것을 보여줘야 한다.

IT 회사라는 차가움과 거리감을 보완하기 위해서 커뮤니케이션의 강화를 신경써볼만 하다.

결론

배송시스템은 유지된 채 IT 회사로 인식되는 것이 가장 중요하다.

일반적으로 기술은 기법(Mechanism)에 가깝고, 커뮤니케이션은 정책(Policy)에 가깝다.

기법은 ‘어떻게’, 정책은 ‘무엇’을 할지를 결정하는데 정책은 장소나 시간이 흐름에 따라 변경될 수 있다. 정책의 변경에 민감하지 않은 일반적인 기법이 회사를 대표하기 바람직하다. (OS 이론)

아이디어는 총 6개를 세웠으며, 각각 해당되는 카테고리를 할당하였다.

로켓TV, 로켓중고, UI/UX 개선은 온전히 내 아이디어였고, 나머지는 다른 팀원들의 아이디어를 가공했던걸로 기억한다.

이름부터, 실현가능성, 세부계획은 많이 고치긴 했지만.

제목 밑에 서비스의 지향점을 적어 청중들에게 서비스의 정체성을 인식 가능하도록 했다.

공급자와 소비자의 직접 소통을 위한 방송 플랫폼이다.

까다로운 실시간 영상처리 기술과 트래픽 관리등은 IT개발자가 많은 기업에게 유리하다.

IT 기업으로의 인식, 공급자와 구매자 교섭력 증가, 즐기러오는 공간으로 만들어 접속율과 트래픽을 증가를 기대한다.

PD, 영상제작자로 자연스러운 앵글과 스토리를 만들고,

쇼호스트, MC, 인플루언서 등을 지원하여 자연스럽게 진행하도록 만든다.

한정된 수의 채널만 열경우(예: 베타 서비스) 순위를 매겨 활발하게 경쟁하게 하며, 예능적 요소를 도입할 수도 있다.

방송은 진행자와 기업관계자가 함께 판매하며, 쿠팡의 배송시스템을 적극적으로 활용한다.

하루만에 배송을 완료하고, 하루뒤에 바로 피드백 방송을 열어 협력업체와 소비자의 니즈를 모두 충족할 수 있도록 만들 수 있다.

예전 소셜 커머스적인 면도 놓치지 않기 위해 특가상품을 게릴라로 파는 방송을 할 수도.

신뢰성 있는 중앙 집중형 중고거래 시스템.

중고 시장은 알라딘으로 검증된 수익모델이며, 당근마켓등이 빠르게 성장하는 걸보아 아직 블루오션이다.

쿠팡이 중고시장에 진출한다면 가격문제를 제외하면(직거래가 아니라 마진이 필요) 대부분의 문제를 해결 할 수 있다.

쿠페이 시스템을 활용하면 공급자에게 즉시 돈을 지급하며, 로켓배송을 활용해 소비자에게는 빠른 배송 또한 가능하다.

여기에 고가의 제품은 3D 스캔을 제공한다면, 신뢰성과 IT 기업 이미지를 줄 수도 있다.

예비 - 리소스를 아끼기 위한 과정

사용자가 예상 물건 등급을 책정 후 정보를 전달하면, 머신러닝을 활용해 적절한 가격을 책정해 알려준다.

실거래 - 물건 매입

예상 가격을 보고 판매를 원한다면 쿠팡으로 배송하며, 쿠팡이 물건의 등급을 재측정하여 최종가격을 결정한다.

판매를 원한다면 즉시 매수하며, 아니라면 반송할 수 있다.

개인간의 거래라면 결코 할 수 없는 일이며 비동기적인 거래를 보장한다.

구매 - 빠른 배송

쿠팡에서 적절한 각도로 찍은 사진과 기타 결점 사유정보등을 포함한 상품을 게시하면,

소비자는 로켓배송이 가능한 지역이라면 빠르게 받아볼 수 있다.

고관여 제품은 3D 스캔을 고려할 수도 있다.

AI & IOT 플랫폼 연동 전략이다.

IOT와 AI 스피커 연계를 원하는 팀원이 낸 아이디어.

이미 출시한 회사들은 제휴기업들이 존재했으며, 당시 삼성은 갤럭시 홈을 베타테스트 중이었으므로 협업대상 회사로 적절하다 생각했다.

음성, 이미지 쇼핑은 물론 각종 배송 제안을 할 수 있다.

예를 들어

수명주기가 있는 부품의 교체제안 및 정기배송
냉장고와 헬스 분석을 통해 식료품 보충/새벽/정기 배송
세탁기, 건조기, 스타일러로 취향과 기후등을 분석해 옷을 제안

를 들 수 있다.

그리고 기타 개발자를 위해 API를 제공을 고려할 수 있다.

쇼핑몰의 커뮤니티화.

다른 팀원이 낸 아이디어였는데, 실현 가능성/효용성이 없다고 판단해서 가위질을 많이했다.

음.. 아마 게임처럼 만들거나 옛 싸이월드마냥 아바타를 도입하자는 걸로 기억한다..

게임화, 크라우드 펀딩등등은 까다로운 레벨 디자인과 유저, 모금 성공률을 들어 기각했고,

대신 현재 있는 후기를 발전 시켜보는게 어떨까 싶었다.

단순 후기 뿐만 아니라 제품을 사용하는 팁 등으로 사용자들이 소통과 유용한 정보를 생산하기 때문에,

트래픽의 증가와 광고 수입의 증가도 노려볼 수 있다.

현재 쿠팡의 후기에는 서식이 없어 온갖 특수문자로 구분하도록 만든 후기들이 많다.

기본적인 서식 기능, 메인화면 노출, 좋은 후기는 추가 포인트, 단순 후기를 넘어 강좌/팁 정보도 노려볼 수 있다.

사람끼리 부대끼며, 상업화 요소가 들어가면 당연히 바이럴과 스팸등의 문제가 생긴다.

이는 AI를 이용해 바이럴과 스팸 방지 시스템을 만들어 최대한 잡아볼 수 있다고 생각한다.

메인화면은 트래픽이 집중되는 곳으로, 모든 사이트에 중요하며 신중한 접근이 필요하다.

내가 생각한 자리는 전면광고와 오늘의 발견(추천상품) 사이이며, 텍스트로 노출해야 한다.

텍스트는 많은 양의 글을 노출할 수 있게 만들 수 있으며, 일반인이 찍은 사진은 일관성, 구도, 화이트밸런스등 때문에 사이트 디자인을 해치는 요소가 될 수 있기 때문이다.

또한 사진을 넣을경우, 밑에 나오는 오늘의 발견에 대한 시각적 집중 효과를 잃게 만들 수도 있다.

온가족 멤버쉽 공유.

내가 스트리밍 서비스 이야기를 하자 AI 스피커 아이디어를 냈던 팀원이 제안한 아이디어였던 것 같다.

넷플릭스는 계정 공유를 문제삼지 않으며 앱스토어나 플레이스토어의 경우 가족끼리 앱공유를 할 수도 있게 만든 점등을 고려할 때, 비교적 가격에 민감한 높은 연령대와 경쟁사로부터 끌여들일때 유효성이 상당하다고 판단했다.

경험상 회원등급이 높은 가족의 계정으로 물건을 구매하는 경우(쿠폰 등 혜택)가 종종 일어나는데, 개인정보의 문제가 발생한다. (상품 주문 목록, 비밀번호 공유 등)

그렇다면, 주소지가 같은 4인까지는 100원씩만 추가하는 선에서 가족 요금제를 신청하는게 어떨까라고 생각했다.

무작정 주는 혜택은 재정파탄을 일으킬 수도 있기 때문.

쿠팡의 사이트를 돌아봤을때, 깔끔하지만 개성이 없다는 느낌이 었다.

베스트프랙티스들을 준수하는데 열중해서 고유성이 없달까? (쿠팡 UX BIBLE & Complex란 블로그 글을 읽으면 왜 그런지 알 것도 같다.)

고유성은 BX에서 중요하다.

이외 전환과 이탈을 막고, 구매 결정을 돕기 위한 UI/UX 보완이 가능하다.

타이포그패피에 관심있다보니 폰트 이야기가 등장한다.

로켓은 거대한 물체가 중력을 벗어나기 위해 강력한 화력을 내뿜는 이미지가 강하므로,

두껍고 역동적인 느낌이었으면 했다.

예를 들어 Rix 자유로에 기울임을 준 정도?

임의로 만든 이미지가 훨씬 낫지 않나 싶다. ㅎㅎ

지금보니 오른쪽 사진 배치가 위로 치우쳐저 있는 듯 하다.

그때 시간이 워낙 없어서...

쿠팡은 호버 인터렉션이 잘되어 있었다.

여기에 이마트처럼 상품의 뒷면과 메뉴를 보여주는 인터렉션이 들어가면 금상첨화다.

많은 사용자들이 장바구니를 관심목록과 가격비교용으로 사용하므로,

직관적으로 가격을 비교할 수 있는 시스템 도입도 좋다.

다시 마케팅 방안과 포지션을 적어, 수미상관처럼 배치.

다시금 해결해야할 목표를 떠올리게 만들어 신뢰성을 높혔다.

출처들.

Q&A를 배달 온 모양처럼 만들었다.

끝.

React + RxJS Todo App (with 오버엔지니어링?)

BlaCk_Void — Sun, 3 May 2020 09:01:19 +0900

처음에는 React에 RxJS를 섞어보는 것을 목표로 하는 플젝이었는데

재미로 이것저것 넣다보니 산으로 갔다ㅋㅋ

아직 만드는 중이지만 벌써 5월이 되서 일단 소개해본다.

~~회사 지원해야뎌..~~

https://github.com/black7375/React-RxJS-Todo

black7375/React-RxJS-Todo

Contribute to black7375/React-RxJS-Todo development by creating an account on GitHub.

github.com

목표는

성능
코드의 간결함
나중에 다른 플젝에서도 우려먹을 디자인 컨셉
반응형 | 유동적 디자인
시간나면 PWA, Web Component까지도 도입
등등 각종 개념 증명용 또는 오버엔지니어링 수행

우선 생긴건 대충 이런식.

다양한 기술이나 개념을 조화롭게 접목시키는 것이 목적인 프로젝트다보니 기능은 최소한으로 유지했다.

성능에 신경을 어느정도 써서 프로덕션이 아닌 개발용 모드 ,캐시 비활성화, CPU 쓰로틀링(6배)에도 쓸만한 수치를 보여준다.

초기 리스트 갯수는 2500개.

로드 시간: 773ms

체크박스를 On/Off시 렌더싱 시간은 6.4ms

아직 많은 최적화 기법을 적용하지 않아서 개선 여지가 많은데도 쓸만하다.

특이한 점으로 App과 TodoTemplate, TodoInsert는 렌더링에서 제외된 것을 볼 수 있다.

(버블링이 일어나지 않음)

간단한 설명들

기술/라이브러리

아직까지 사용한 주요 기술/라이브러리는 다음과 같다.

메인: ReactJS(with @types), RxJS, Typescript, Node SASS(with @types)
서브: ImmutableJS(with @types), RecyclerListView
기타: Normalize.css, React Icons, Classnames, Postinstall-Postinstall, TS-Object-Utils

사용목적과 고른 이유들을 설명하자면

메인

ReactJS : 아무래도 사용하는 사람이 많고, 나도 프론트엔드 3대장중 가장 관심이 가는 녀석
RxJS: 앵귤러쪽에서 주로 사용되기는 하지만, 내 포스트들을 보면 Rx나 함수형 패러다임쪽을 선호하는 편이라.
Typescript: 동적/인터프린터 언어인 JS를 생으로 쓰기는 좀,, 싶기도 하고 자동완성, 에러체크등 때문에 정적인 언어를 좋아하기 때문에
SCSS: CSS-in-JS를 몇개 살펴보긴 했으나 PostCSS에 있는 CSSNext 및 각종 기능들과 섞어쓰기에 SCSS가 나을 듯하여(SASS는 중괄호 블럭이 없어서 싫다. 불명확하며 인공지능 코딩할 때가 생각나기도 해서;;)

서브

ImmutableJS: Immer도 충분히 매력적이지만, 함수형 자료구조들을 파워풀하게 사용할 수 있고 성능도 더 나아서
RecyclerListView: 안드로이드에서 RecyclerView와 ViewPager2를 잘 쓰던 기억과 React-Window/Virtualized와 다르게 뷰를 재활용한다는 점 때문에 매력적이여서 선택했으나.. 커다란 고비가. 애증의 라이브러리.

기타

Normalize.css: CSS 초기화
React Icons: 다양한 SVG 아이콘을 쓸 수 있어서.
Classnames: props로 클래스를 적용/해제시 간단하게 할 수 있다
Postinstall-Postinstall: yarn에서 add를 할 때만 postinstall이벤트가 작동하나, 이 패키지를 설치하면 remove시에도 작동
TS-Object-Utils: 다른건 아니고, 라이브러리 커스텀을 할 때 필요해서 사용했다.

고민했던 것

이것저것 기술을 적용해보자는 플젝이라 리덕스나 MobX를 넣어볼까 하다가 RxJS 위주로 사용하기 위해 브런치로 분리하여 구현만해두고, 합치지 않았다.

TSTL(타입스크립트 STL) + Immer VS ImmutableJS를 써볼까하다 데이터구조 + 불변성을 한꺼번에 지원하는 Immutable로 결정.

폴더 구조

최상위

patches 폴더가 추가된 것 빼고는 별다를 것 없다.

ITCSS 철학을 기반으로 만들어졌다.

Settings: 전역적인 변수들 (Color, Font 등)
Tools: 자주 쓰여질 만한 유틸이나 믹스인
Generic: 프로젝트 첫번째 레이어(모델, Nomalize 등)
Layouts: 꾸미는 것, 컨텐츠들보다 정렬 또는 컨테이너
Components: 컴포넌트들
Service: RxJS를 이용한 이벤트 관리

디자인 컨셉

지난학기 내가 디자인했던 플젝에서 따왔다.

종이처럼 스큐어모피즘스러운 편안한 느낌과 플랫/타이포그래피 위주의 디자인.

상충하는 스큐어모피즘과 플랫이 만날수 있는 지점, 개인적으로 좋아하는 타이포그래피를 이용하기 위한 디자인, 눈이 편안한 색감을 찾다보니 이런 결과가 나올 수 밖에 없더란.

어느때나 블로그에 예전자료를 개시해도 상관없도록 매달 산돌과 폰트릭스에게 상납하고 있다. 흒흒

포인트 컬러는 옥색이라 해야 하나, 민트초코색이라 해야 하나.

예전에 넷스케이프를 쓸때 감명받아 좋아하게된 색인데 만자로를 쓰면서 primary 색으로 사용해도 좋겠다는 생각이 들어 적용했다.

단, Todo App에서는 홈버튼처럼 확 띄어야하거나, 오밀조밀한 UI에 섞여 구분하기 어려운 상황이 아니기 때문에 자연스래 섞이게 만들기 위해 채도를 낮췄다.

주요 코드 소개

아직은 별것 없지만 어떻게 설계했는지 볼 수 있다.

Generic/TodoModel.tsx

인터페이스로 기본 아이템 값을 만들어준뒤, ImmutableJS로 데이터 모델을 생성하여 사용한다.

interface TodoItemI {
  id:      number;
  text:    string;
  checked: boolean;
}

export const TodoItem: Record.Factory<TodoItemI> = Record({
  id:      0,
  text:    "",
  checked: false,
} as TodoItemI);
export type TodoItemT = Record<TodoItemI> & Readonly<TodoItemI>;

export type TodoItemsT = List<TodoItemT>;

App.tsx

이렇게 내용이 없어도 될 정도인가 싶을정도로 간단하다.

App.tsx에서 필요한 글로벌 이벤트 관련 로직은 TodoService로 분리하여 Rx를 이용해 관리하기 때문.

function App() {
  return (
    <TodoTemplate>
      <TodoInsert />
      <TodoList />
    </TodoTemplate>
  );
}

export default App;

Services/TodoService.tsx

App.tsx에 있어야 할 것들이 모여있어 상당히 긴편이다.

하지만 역할 구분이 잘 되어있어 어렵지 않다.

Large Size Sample: 초기 로딩할 데이터
Core Event: 업데이트, 생성, 삭제, 토글 이벤트 타입정의 및 생성
Data: 아직 리덕스나 MobX를 적용하지 않아 글로벌 상태는 여기에서 관리한다. todo$는 각 이벤트 발생시 todos => todos인 함수를 적용
Event Implementation: 각 이벤트가 일어날 때 처리방법 구현 및 업데이트 처리
Interface: TodoService를 사용해 외부에서 Observable이나 이벤트 발생을 받아들이기 위한 인터페이스

// == Large Size Sample ========================================================
const largeItemSize = 2500;
const largeInitItems = List((() => {
  const array = [];
  for (let i = 0; i < largeItemSize; i++) {
    array.push(new TodoItem({
      id: i,
      text: `Task ${i}`,
      checked: false
    }));
  }
  return array;
})());


// == Core Events ==============================================================
const update$ = new BehaviorSubject((todos: TodoItemsT) => todos);
const insert$ = new Subject<TodoItemT>();
const remove$ = new Subject<TodoItemT['id']>();
const toggle$ = new Subject<TodoItemT['id']>();


// == Data =====================================================================
let nextId = largeItemSize + 1;
const todos$ = update$.pipe(
  scan((todos, operation) => operation(todos), largeInitItems),

  // cache
  publishReplay(1),
  refCount()
);


// == Events Implementation ====================================================
insert$.pipe(
  map((todo) => (todos: TodoItemsT) => todos.push(todo))
).subscribe(update$);

remove$.pipe(
  map((id)   => (todos: TodoItemsT) => todos.filter(todo => todo.id !== id))
).subscribe(update$);

toggle$.pipe(
  map((id)   => (todos: TodoItemsT) => todos.map(todo => todo.id === id
    ? todo.set("checked", !todo.checked)
    : todo
  ))
).subscribe(update$);


// == Interface ================================================================
const TodoService = {
  initData: largeInitItems,
  todos$: todos$,

  onInsert: (text: TodoItemT['text']) => {
    insert$.next(new TodoItem({
      id:      nextId,
      text:    text,
      checked: false
    }));
    nextId++;
  },
  onRemove: (id: TodoItemT['id']) => remove$.next(id),
  onToggle: (id: TodoItemT['id']) => toggle$.next(id)
};

export default TodoService;

Components/TodoListItem.tsx

그럼 필요한 props와 콜백은 어떻게 전달될까?

꼭 필요한 props만 의존하고, 글로벌 이벤트는 TodoServcie로부터 불러와 사용한다.

TodoService가 이벤트를 관리하기 때문에 App까지 이벤트 버블링이 필요없고, 상태변화 후 렌더링시에도 영향이 제한된다.

const cx = stylesBind(styles);

interface TodoListItemProps {
  todo: TodoItemT;
  key: TodoItemT['id'];
}

const TodoListItem = ({ todo }: TodoListItemProps) => {
  const { id, text, checked } = todo;
  const onRemoveDown = useCallback(() => TodoService.onRemove(id), [id]);
  const onToggleDown = useCallback(() => TodoService.onToggle(id), [id]);

  return (
    <div className={cx('TodoListItem')}>
      <div className={cx('checkbox', { checked })} onPointerDown={onToggleDown} >
        {checked ? <IoMdCheckmarkCircleOutline /> : <IoIosRadioButtonOff /> }
        <div className={cx('text')}>{text}</div>
      </div>
      <div className={cx('remove')} onPointerDown={onRemoveDown} >
        <BsTrash />
      </div>
    </div>
  );
};

export default React.memo(TodoListItem);

Components/TodoList.tsx

로딩과 렌더링 시 성능향상의 핵심인 RecyclerListView를 사용한다.

처음 초기화시를 제외하고, Observable로 상태를 바로 업그레이드 하도록 만들었다.

const cx = stylesBind(styles);

const ListViewType = {
  TODOLISTITEMS: 0
}

const TodoList = () => {
  const width = window.innerWidth;
  const renderData = new ListDataProvider(
    (r1: TodoItemT, r2: TodoItemT) => r1 !== r2
  ).cloneWithRows(TodoService.initData);

  const [dataProvider, setDataProvider] = useState(renderData);
  useEffect(() => {
    const sub = TodoService.todos$.subscribe((todos) => {
      setDataProvider((dataProvider) => dataProvider.cloneWithRows(todos));
      }
    );
    return () => { sub.unsubscribe(); };
  }, []);

  const layoutProvider = new LayoutProvider(
    (index) => { return ListViewType.TODOLISTITEMS },
    (type, dim) => {
      switch(type) {
        case ListViewType.TODOLISTITEMS: {
          dim.width  = width; // 630.4 584
          dim.height = 55;    // 55.2  54.4
          break;
        }
        default:
          dim.width  = 0;
          dim.height = 0;
      }
    }
  );

  const rowRenderer = (viewType: React.ReactText, todo: TodoItemT) => {
    switch (viewType) {
      case ListViewType.TODOLISTITEMS: {
        return (<TodoListItem todo={todo} key={todo.id} />);
      }
      default:
        return null;
    }
  }

  return (
    <div className={cx('TodoList')}>
      <RecyclerListView dataProvider={dataProvider} layoutProvider={layoutProvider}
                        rowRenderer={rowRenderer} />
    </div>
  );
};

export default React.memo(TodoList);

Tools/RecyclerProvider.ts

빠르게 만들려고 도입했던 RecyclerListView.

처음에 도입하려했더니 ImmutableJS의 List는 사용할 수 없고, 오직 기본 []만 쓸 수 있었다.

그래서 데이터 주입 및 관리하는 부분을 까보면서 인터페이스의 내부 부분을 싹 재설계한 결과.

물론 여기서도 성능향상이 있었다.

커다란 List를 toArray나 toJS로 바꾸는데 드는 비용이 상당히 큰데 이를 최소화(이게 크다)
데이터 구조의 특성을 이용한 빠른 비교

타입을 지원하기 위해 아래 코드창에는 없는 제네릭 클래스 부분부터 다 만들었지만, 타입변환이 필요없는 것에서 오는 최적화는 이해하기 쉬우니 두번째 항목인 빠른 비교 위주로 설명하려 한다.

그 중 핵심은 처음 바뀐 인덱스를 반환해주는 getFirstIndexChange.

원래의 DataProvider에서

배열 크기 비교 후 작은 배열에 맞춤
크기가 작은 배열의 크기까지 각 인덱스별 데이터가 바뀌었는지 반복하며 확인

이었던 구조를

Immutable 컬렉션의 equal을 사용해 같다면 현재 크기 사용
크기 비교 후 작은 List에 맞춘 후
조건을 만족하는 첫번째 인덱스를 반환하는 .findIndex를 사용하여 .get으로 접근 횟수를 줄이며 최적화 가능성을 최대한 활용

로 바꾸었다.

// == RecyclerListView Dataprovider with IMMUTABLE.JS ==========================
export abstract class ListBaseDataProvider<T> extends GenericDataProvider<T, List<T>> {
  public abstract newInstance(
    rowHasChanged: (r1: T, r2: T)  => boolean,
    getStableId?:  (index: number) => string  ): ListBaseDataProvider<T>;

  public getDataForIndex(index: number): T | undefined {
    return this.m_data.get(index);
  }

  // Fast Matching Lists
  private getFirstIndexChange(newData: List<T>, newSize: number): number {
    if(this.m_data.equals(newData)) {
      return this.m_size;
    }

    if(this.m_size > newSize) {
      const sizeData = newData.setSize(this.m_size);
      return (this.m_data as List<T>)
        .findIndex((value, index) => this.rowHasChanged(value, sizeData.get(index)));
    } else {
      const sizeData = this.m_data.setSize(newSize);
      return (sizeData as List<T>)
        .findIndex((value, index) => this.rowHasChanged(value, newData.get(index)));
    }
  }

  //No need to override this one
  //If you already know the first row where rowHasChanged will be false pass it upfront to avoid loop
  public cloneWithRows(newData: List<T>, firstModifiedIndex?: number): DataProvider {
    const dp        = this.newInstance(this.rowHasChanged, this.getStableId);
    const newSize   = newData.size;

    dp.m_firstIndexToProcess = ObjectUtil.isNullOrUndefined(firstModifiedIndex)
                            ? this.getFirstIndexChange(newData, newSize)
                            : Math.max(Math.min(firstModifiedIndex, this.m_data.size), 0);

    if (dp.m_firstIndexToProcess !== this.m_data.size) {
      dp.m_requiresDataChangeHandling = true;
    }
    dp.m_data = newData;
    dp.m_size = newSize;
    return dp;
  }
}

../patches/의 patch 삼총사와 yarn 라이프사이클

방금 RecyclerListView에서 List<>를 사용할 수 없게 되었다고 하였다.

데이터 프로바인더 내부 말고, props의 타입 정의 또한 any와 any[]로 이루어져있기 때문에 패치해주었다.

patch_list.sh는 타겟 위치, 패치된 파일 위치, 패치를 생성할 위치를 정의한다.

# Patch Path
## TargetPath, PatchPatch, CreatedPatchPath
PATCH_PATH=(../node_modules/recyclerlistview/dist/web/core/RecyclerListView.d.ts
            ./recyclerlistview/RecyclerListView.d.ts
            ./created/recyclerlistview-recyclerlistview.patch

            ../node_modules/recyclerlistview/dist/web/core/dependencies/DataProvider.d.ts
            ./recyclerlistview/dependencies/DataProvider.d.ts
            ./created/recyclerlistview-dataprovider.patch
           )

create_patch를 사용하면 두파일을 비교해 생성할 위치에 패치를 생성한다.

DIR는 현재 파일의 절대경로를 생성해주는 트릭.

10년 넘는 리눅스 생활 덕. ㅎㅎ

DIR=$( cd "$(dirname "$0")" ; pwd )

# Source Patch List
source ${DIR}/patch_list.sh

# Create Patch File
create_patch() {
  local target=$1
  local patched=$2
  local patch=$3
  diff -Naur ${DIR}/${target} ${DIR}/${patched} > ${DIR}/${patch}
}

for (( i = 0; i<${#PATCH_PATH[@]}; i++ )); do
  create_patch ${PATCH_PATH[i]} ${PATCH_PATH[i+1]} ${PATCH_PATH[i+2]}
  ((i+=2))
done

마지막으로 apply_patch는 node_modules에 패치를 적용한다.

DIR=$( cd "$(dirname "$0")" ; pwd )

# Source Patch List
source ${DIR}/patch_list.sh

# apply patch
apply_patch() {
  local target=$1
  local patch=$2
  patch --forward ${DIR}/${target} < ${DIR}/${patch}
}

for (( i = 0; i<${#PATCH_PATH[@]}; i++)); do
   apply_patch ${PATCH_PATH[i]} ${PATCH_PATH[i+2]}
   ((i+=2))
done

그 후, package.json의 postinstall에 bash로 실행해주라는 명령만 날리면 매 패키지 설치마다 실행이 된다.

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "postinstall": "bash ./patches/apply_patch.sh"
  },

하지만 패키지 삭제시에는 안됐는데 Postinstall-Postinstall 패키지로 해결.

이렇게 RecyclerListView를 사용하려는 노오력이 있었다.

이외에도 3일동안 해매서 아이템 상태변화 시 스크롤 위치 초기화 문제를 겨우 잡았기 때문에 애증의 라이브러리라 할만하다. ㅠㅠㅠㅠ

재랜더링시 가까운 아이템 요소 크기로 움직이는 문제도 있었는데 깃헙의 도움으로 해결되었다.

Layouts/TodoTemplate.module.scss

클래스들이 BEM 네이밍 스타일로 만들어도록 하기위해 CSS Module을 이용하고 있다.

이 프로젝트는 개념 증명용으로 만들었기 때문에 변수와 믹스인을 최대한 활용하도록 코드를 짜보기도 했다.

Atomic CSS에서 영감을 받아서 이리 구성해봤는데 처음 네이밍에 익숙해지는 것만 넘으면 의외로 쓸 만한듯.

뷰포트가 작을 때 레이아웃이 깨지는 것을 보고 도입한 반응형 레이아웃이 적용되어 있다.

@import '~include-media-or/dist/include-media';
@import '../Settings/Colors.scss';
@import '../Settings/Fonts.scss';
@import '../Settings/Layouts.scss';
@import '../Tools/Tools.scss';

.TodoTemplate {
  @include flex-container-start-top;
  @include flex-container-alignY-center;
  @include font-legibility;
  font-family:      $notoSans;
  font-weight:      $medium;
  height:           $full-height;
  color:            $black;
  background-color: $white;

  .app-title {
    @include container-all;
    @include flex-item-alignY-fill;
    @include font-size($header-font-size, $header-font-max-size);
    font-family: $notoSerif;
    font-weight: $heavy;
    text-align:  center;
    padding:     $default-padding * 2;
    max-height:  $half-height;
  }
  .content {
    @include container;
    @include font-size($default-font-size, $default-font-max-size);
    @include media(">=laptop") {
      width: 40rem;
    }
    @include media(">=tablet") {
      margin-left:  30%;
      margin-right: 30%;
    }
    width: 80%;
  }
}

Tools/Tools.scss

반응형 웹에 대한 글들을 보면

반응형 웹 디자인 패턴

처럼 레이아웃에 대한 것들이 대부분이다.

타이포그래피에 나름 관심이 많은 나는 크기에 대하여 찾아봤는데

그냥 대략적인 수치정도만 나올 뿐이었다.

레이아웃은 %나 뷰포트 관련값으로 실시간 크기 조정이 되지만,

폰트는 뷰포트나 % 값을 사용한 유동적 조정을 하기가 매우 어려웠기에 자료를 찾아보았다.

다행히

Scale Typography For Any Screen Size

란 글을 통해

글씨 최소/최대크기와 화면 최소/최대 크기가 있으면

고정값 + 뷰포트 비율

를 산출하여 뷰포트 크기에 따라 자동으로 크기가 조정할 수 있는 방법을 알아냈다.

여기서 2차 멘붕이 몰려왔다.

모바일~데스크톱 크기 그리고 HD~4K 해상도등을 고려해 글씨의 최소/최대 크기를 지정해야 하는 것이다.

내가 디자이너였다면 감(?)이나 시각 디자인 이론에 따라 각 장치에 맞는 크기를 얻어낼 수 있겠지.

그치만 나는 공돌이인 걸..

다양한 장치에서 일관된 크기를 결정할 방법을 찾기 시작했다.

처음에는 IOS의 pt, 안드로이드의 dp/sp 단위처럼 ppi 기반으로 사용해볼까 생각했다.

하지만

pt와 px단위를 혼용하지 맙시다

란 글을 보고 난 후 생각을 접었고...

장치와 사용자와의 거리를 포함하지 않는 단위라는 점도 매력적이지 않았다.

(예를들어 같은 크기라도 가까이서 보는 모바일에서 느껴지는 체감크기가 PC 모니터의 크기보다 클 수밖에 없다)

하루동안 열쇠를 찾기위해 고심했고.

한때 장래희망이어서 열심히 공부했던 천문학에서 핵심 아이디어를 가져왔다.

연주시차(각도)로 거리를 재는 것처럼 각도와 약간의 삼각함수를 쓰면 일관된 크기를 보여줄 수 있지 않겠냐는 것이었다.

이는

눈과 기기와의 거리
기기의 크기
해상도

를 모두 포함하여 필요한 크기를 계산할 수 있는 단위이며 시력검사를 하는 원리이기도 했다.

세부적인 이론과 자료는

를 참고하면 됩니다.

임의적으로 각도로 산출해낸 크기를 '적합 크기(Fit Size)'라고 부르는 중인데

고해상도 > 폰 > 데스크탑 > 랩탑 > 태블릿 순이란 결과를 얻을 수 있었으며 합리적으로 변환을 해주었다.

각 장치에 맞는 크기 생성

하지만 사람이 매번 수동적으로 기기와의 거리, 기기의 크기, 가로 해상도, 세로 해상도를 입력해 각 장치에 맞는 크기를 구하기는 복잡했고, 인터페이스를 만들었다.

그냥 폰트 지정하듯

@include font-size($size, $max-size: 옵션);

만 지정해주면

크기 입력
가장 작게 보일 장치에서의 각도 계산 (또는 기준이 될 장치를 지정해볼 수 있겠죠?)
각도를 기반으로 각 장치별 적합 크기 생성
장치 사이의 유동성 제공

란 과정을 통해 각장치 맞는 크기를 생성하고 유동적으로 크기가 조절된다.

나중에 라이브러리로 따로 뺄 예정.

// ** Responsive ***************************************************************
// == Size =====================================================================
$DEFAULT-BREAK: default !default;
$DEFAULT-SIZE:  16px    !default;

@function zip-responsive() {
  @return zip(
    map-values($screen-distances), map-values($screen-sizes      ),
    map-values($breakpoints     ), map-values($breakpoints-height)
  );
}

@function calc-ppi($screen-width, $screen-height, $screen-size) {
  @return sqrt(pow($screen-width, 2) + pow($screen-height, 2)) / $screen-size;
}

@function calc-angle($size) {
  $size:     num(px($size));
  $values:   zip-responsive();
  $smallest: null;

  @each $value in $values {
    $screen-distance: nth($value, 1) * 100;
    $screen-size:     nth($value, 2);
    $screen-width:    num(nth($value, 3));
    $screen-height:   num(nth($value, 4));

    $ppi: calc-ppi($screen-width, $screen-height, $screen-size);
    $independent-value: $screen-distance * $ppi;
    @if (($smallest == null) or ($smallest > $independent-value)) {
      $smallest: $independent-value;
    }
  }

  $angle: $size * 54 / $smallest;
  $visual-angle: atan($angle) * (10800 / pi());
  @return count-round($visual-angle, 2);
}

@function calc-size($visual-angle) {
  $values:      zip-responsive();
  $break-sizes: ();

  @each $value in $values {
    $screen-distance: nth($value, 1) * 100;
    $screen-size:     nth($value, 2);
    $screen-width:    num(nth($value, 3));
    $screen-height:   num(nth($value, 4));

    $ppi: calc-ppi($screen-width, $screen-height, $screen-size);
    $angle: tan(pi() * $visual-angle / 10800);
    $size: $screen-distance * $angle * $ppi / 54;

    $break-sizes: append($break-sizes, ($size));
  }

  @return $break-sizes;
}

// https://gist.github.com/eduardoboucas/84144cd85cbd2ad4db1ca8b902585ca0
@function im-to-em($breakpoints, $base-value: 16px) {
  $new-breakpoints: ();

  @each $key, $value in $breakpoints {
    $em-value: ($value / $base-value) * 1em;
    $new-breakpoints: map-merge($new-breakpoints, ($key: $em-value));
  }

  @return $new-breakpoints;
}

// https://www.madebymike.com.au/writing/fluid-type-calc-examples/
@function fluid-rate($start-size, $end-size, $min-screen, $max-screen) {
  @return ($end-size - $start-size) / ($max-screen - $min-screen);
}
@function fluid-basic-size($start-size, $min-screen, $rate) {
  @return $start-size - $rate * $min-screen;
}

@function fluid-size($start-size, $end-size, $min-screen, $max-screen) {
  $start-size: em($start-size);
  $end-size:   em($end-size);
  $min-screen: em($min-screen);
  $max-screen: em($max-screen);

  $rate: fluid-rate($start-size, $end-size, $min-screen, $max-screen);
  $basic-size: fluid-basic-size($start-size, $min-screen, $rate);

  $sign: "+";
  @if ($basic-size < 0) {
    $sign: "-";
    $basic-size: abs($basic-size);
  }
  @return calc(#{$rate*100}vw #{$sign} #{$basic-size});
}
@function fluid-limit-break($start-size, $end-size, $max-size,
                            $min-screen, $max-screen) {
  $start-size: px($start-size);
  $end-size:   px($end-size);
  $max-size:   px($max-size);
  $min-screen: px($min-screen);
  $max-screen: px($max-screen);

  $rate: fluid-rate($start-size, $end-size, $min-screen, $max-screen);
  $basic-size: fluid-basic-size($start-size, $min-screen, $rate);

  @return ($max-size - $basic-size) / $rate;
}

@mixin fluid-media($property, $sizes, $max-size: null) {
  $fluid-sizes: to-unit-map($sizes, px);
  $fluid-breakpoints: map-merge(($DEFAULT-BREAK: 0px), to-unit-map($breakpoints, px));
  @if not map-has-key($fluid-sizes, $DEFAULT-BREAK) {
    $default-map: ($DEFAULT-BREAK: $DEAFULT-SIZE);
    $fluid-sizes: map-merge($default-map, $fluid-sizes);
  }
  $limit-break: null;

  $last-size: length($fluid-breakpoints) - 1;
  @each $i in range($last-size) {
    $now-key:  map-nth($fluid-breakpoints, $i);
    $next-key: map-nth($fluid-breakpoints, $i + 1);

    $now-size:   map-get($fluid-sizes, $now-key );
    $next-size:  map-get($fluid-sizes, $next-key);
    $now-break:  map-get($fluid-breakpoints, $now-key );
    $next-break: map-get($fluid-breakpoints, $next-key);

    @if ($max-size != null) {
      $limit-break: fluid-limit-break($now-size,  $next-size, $max-size,
                                      $now-break, $next-break);

      $max-size:  px($max-size);
      $now-size:  if($now-size  > $max-size, $max-size, $now-size );
      $next-size: if($next-size > $max-size, $max-size, $next-size);
    }

    $fluid-size: fluid-size($now-size, $next-size, $now-break, $next-break);
    @if $now-key == $DEFAULT-BREAK {
      #{$property}: $fluid-size;
    }
    @else if($max-size != null) and ($i == $last-size) {
      @include media(">=#{$limit-break}") {
        #{$property}: $max-size;
      }
    }
    @else {
      @include media(">=#{$now-key}") {
        #{$property}: $fluid-size;
      }
    }
  }
}

@mixin fluid($property, $size, $max-size: null) {
  $scaled-size: calc-size(calc-angle($size));

  $keys:   join($DEFAULT-BREAK, map-keys($breakpoints));
  $values: join($size, $scaled-size);

  @include fluid-media($property, to-map($keys, $values), $max-size);
}

// -- Interface ----------------------------------------------------------------
// Font
@mixin font-size($size, $max-size: null) {
  @include fluid(font-size, $size, $max-size);
}

[스압/데이터주의] 웹 최적화 방식 모음 - 2. 파싱 및 렌더링 트리

BlaCk_Void — Sun, 19 Apr 2020 15:54:31 +0900

2. 파싱 및 렌더링 트리

이 파트의 핵심은 파싱의 병렬성과 렌더링에 미치는 영향이다.

크게 배치순서를 바꾸는 것과 제한, 기타 효율적 활용하는 방안으로 나눌 수 있다.

2.1 배치순서

2.1.1 CSS를 상단에 배치

개요

분류: CSS

HEAD에 스타일 시트를 넣으면 페이지가 점진적으로 렌더링 될 수 있어 좋다.

CSSOM 트리는 CSS를 모두 해석해야 구성되고, 구성되지 않으면 렌더링이 차단되기 때문이다.

반면 DOM 트리는 순차적으로 구성될 수 있어 점진적 렌더링이 가능하다.

성능에 관심이 있는 프론트엔드 엔지니어들은 점진적으로 페이지를 읽어오길 원한다.

즉, 브라우저에 가능하면 빨리 어떠한 컨텐츠 표시할 수 있기를 원한다.

이것은 컨텐츠가 많은 페이지와 느린 인터넷 접속 사용자에게 특히 중요한데, 사용자에게 진행률 표시기(progress indicator)와 같은 시각적 피드백 제공의 중요성은 잘 연구되고 문서화 되어있다.

브라우저가 페이지를 점진적으로 읽어올 때, 상단의 헤더(header), 메뉴바(navigation bar), 로고 등은 페이지를 기다리는 사용자에게 시각적 피드백을 제공하는 역할을 하고 이것은 전반적인 사용자경험(UX)을 향상시킨다.

반면, 문서하단에 CSS를 배치한다면 많은 브라우저에서 점진적으로 렌더링되는 것에 악영향을 끼친다.

스타일 시트가 변경될 때 페이지 구성요소를 다시 그리는 것을 피하기 위해 렌더링을 차단하여 빈페이지를 보게된다는 것.

빈 흰색 화면이나 스타일이 지정되지 않은 콘텐츠의 깜박임 중 어느 것도 위험을 감수할만한 가치가 없다.

다시 말하지만, 최적의 솔루션은 HTML 사양을 따르고 스타일 시트를 문서 HEAD에 로드하는 것이다.

HTML 스펙은 명확하게 스타일이 페이지의 HEAD에 포함시킬 것을 기술한다

Unlike A, [LINK] may only appear in the HEAD section of a document, although it may appear any number of times.
a태그가 여러 번 나타날 수 있는 것과 달리, [LINK]는 오직 문서의 HEAD 섹션에 표시 될 수 있습니다.

해결방법

아래와 같이 배치

<head>
  ...
  <link href="STYLE.css" rel="stylesheet" />
  ...
</head>

2.1.2 Script를 하단에 배치

개요

분류: Javascript

스크립트로 인해 발생하는 첫번째 문제는 병렬 다운로드를 차단한다.(스크립트의 순서를 지키기 위해)

HTTP / 1.1 규격은 각 브라우저 호스트가 두 개의 구성요소 이상(병렬로) 다운로드 할 것을 제안한다.

여러 호스트 이름에서 이미지를 제공하면 동시에 두 번 이상 다운로드 할 수 있지만, 스크립트를 다운로드하는 동안 브라우저는 다른 호스트 이름에서도 다른 다운로드를 시작하지 않는다.

하지만 무엇보다 중요한 것은 자바스크립트는 DOM과 CSSOM 트리를 변경할 수 있기 때문에 파싱을 차단하는 리소스라는 것이다.

외부에서 가져오는 스크립트도 모두 다운로드되고 실행될 때까지 DOM 트리 생성를 중단한다.

head에 위치시: 스크립트를 실행한 후 body를 렌더링
body에 위치시: DOM 랜더링 도중 스크립트를 만나면 처리완료시까지 랜더링이 중단

따라서 /body의 직전에 두는 것이 가장 현명한 방법.

자바스크립트와 렌더링은 자바스크립로 상호작용 추가라는 글을 읽어보면 좋다.

해결방법

아래와 같이 배치

<body>
  ...
  <script src="SCRIPT.js" type="text/javascript"></script>
</body>

하지만, 어떤 상황에서는 스크립트를 맨 아래로 옮기기가 쉽지 않다.

예를 들어 스크립트가 페이지 내용의 일부를 삽입하기 위해 document.write를 사용하는 경우 페이지에서 하단 이동할 수 없으며 Scope 문제가 있을 수도 있다.

대부분의 경우 이러한 상황을 해결하는 방법이 있다.

바로 비동기(async)나 지연된(deferred) 스크립트를 사용하는 것이다.[<script> 요소]

스크립트에 document.write가 포함되어 있지 않으며(지정된 순서대로 실행된다는 보장이 없기 때문) 브라우저에서 렌더링을 계속할 수 있는 단서다. [async vs defer attributes]

둘다 다운로드 받는 동시에 렌더링을 할 수 있지만 다음과 같은 특성이 있다.

async: 다운이 완료되면 실행
defer: HTML 파싱이 끝나면 실행

2.1.3 우선순위에 대한 힌트 제공

개요

분류: Content

우선순위에 대한 힌트를 브라우저에 제공하여 로드를 할 수 있다.

바로 전에 언급했던 async, defer와 같은 예도 속한다.

일단 preload와 prefetch에 대해서만 다루어보도록 하자.

자세한 것은 MDN의 link항목와 참조 링크들을 참조. [Preload, Prefetch And Priorities in Chrome, 리소스 우선순위 - preload, preconnect, prefetch, How to improve web performance By using(Preload, Preconnect, Prefetch), Link prefetching FAQ]

- Preload

브라우저에게 페이지에서 필요한 자원을 일찍이 fetch하라는 속성이다.
현재 페이지에서 빠르게 가져와야 하는 리소스에 사용되는 속성이며 반드시 해야하는 작업이라고 알려준다.

- Prefetch

미래에 필요할 수 있는 리소스를 가져와야 할 때 사용되는 속성이다.

현재 페이지 로딩이 마치고 사용 가능한 대역폭(bandwidth)이 있을 때(다운 받을 여유가 생겼을 때) 가장 낮은 우선순위로 리소스를 가져온다는 뜻.

이번에는 dns-prefetch와 preconnect 차례.

이 둘은 현재 페이지에서 외부 도메인의 리소스를 참고하는 것을 브라우저에게 알려 미리 외부 도메인과 연결을 설정할 수 있게 하는 것이 목표.

- DNS-Prefetch

다른 출처의 DNS 조회를 처리해 놓는다.

- Preconnect

DNS 조회 뿐만 아니라 TCP 핸드 쉐이킹까지 해결한다.

preconnect를 사용하면 브라우저가 사이트에 필요한 연결을 미리 예상 할 수 있게 된다.

따라서 브라우저는 필요한 소켓을 미리 설정할 수 있기 때문에 DNS, TCP, TLS 왕복에 필요한 시간을 절약 할 수 있게 된다.

해결방법

- Preload

<link rel="preload" as="script" href="super-important.js">
<link rel="preload" as="style" href="critical.css">

as 속성을 사용하여 리소스의 유형을 알려줘야 한다.

브라우저는 올바른 유형이 설정되어 있지 않으면 미리 가져온 리소스를 사용하지 않는다.

리소스를 두 번 가져오게 하거나, 필요하지 않는 것을 가져오지 하지 않도록 주의해야 한다.

웹폰트에 많이 사용한다.

브라우저에서 글꼴을 요청이 바로 일어나는 것이 아니라 CSSOM이 생성되고 렌더링 트리를 생성할 때서야 비로소 요청이 발생하기 때문이다.

<link rel="preload" as="font" crossorigin="crossorigin" type="font/woff2" href="myfont.woff2">

단, 폰트는 다른 호스트에 있는 경우가 대부분이므로 crossorigin을 표시해주는 것이 좋다.

- Prefetch

받아온 요청이나 자원이 유저의 앞으로도 navigation(예를 들어 다른 뷰나 페이지 사이) 지속되어야 한다면 쓸 수 있다.

만약 Page 1이 Page 2에 꼭 필요한 자원을 prefetch하는 요청을 날리는 경우라면, 중요한 자원과 navigation requests는 병행으로 수행될 수 있다.

만약에 이 경우에 preload를 사용한다면 즉시 Page A의 unload가 취소될 것이다.

<link rel="prefetch" href="page-2.html">

역시 재정의하여 사용할 수 없다는 점은 명심해야 한다.(두번 로드됨)

- importance(실험적)

preload와 prefetch시에만 쓸 수 있는 속성이다.

auto: 브라우저의 휴리스틱에 의해 우선순위가 자동적으로 결정된다.
how: 높은 우선순위라는 것을 알려줌
low: 낮은 우선순위라는 것을 알려줌

- DNS-Prefetch

<link  rel="dns-prefetch"  href = "//example.com">

DNS Prefetch나 Preconnect는 정확한 경로를 알 수 없을 때나 미디어 스트리밍시 유용하다.

정확한 경로를 알 수 없을 때

주어진 CDN으로 부터 리소스를 가져와야 한다는 것은 알지만 정확한 경로를 모르는 상황이 발생 할 수 있다.

예를 들면 브라우저 별로 가져와야 하는 라이브러리 등의 버전이 다를 때, CDN 주소는 알지만 정확한 경로는 알지 못하는 상황을 들 수 있다.

브라우저는 파일이 필요하기 전에는 리소스를 가져오지 않지만 적어도 연결은 먼저 처리해서 리소스를 요청하고 가져오는 여러번의 왕복을 가다리지 않아도 된다.

미디어 스트리밍

스크립트가 로드되고 스트리밍 데이터를 처리할 준비가 될 때 까지 스트리밍을 기다리고 싶을 수 있다.

미리 연결을 하기 때문에 리소스를 가져올 준비가 되면 연결을 설정하는 것이 아니라 미리 연결된 설정에 따라 리소스를 가져와 연결을 설정하는 대기 시간을 줄 일 수 있다.

- Preconnect

<link rel="preconnect" href="https://example.com">

href 속성에 의해 URL을 해석, URL이 유효한 URL인지 아닌지 해석하여 아닐경우 error처리, HTTP/HTTPS인지 판단
유효할 경우 이 url을 origin으로 판단
cors에 대한 상태를 대상 엘리먼트의 crossOrigin 속성에 할당
cors의 속성의 값이 anonymous 이거나 credentials이 false가 아닐경우 연결을 시도
http의 경우 (DNS+TCP), https의 경우 (DNS+TCP+TLS)를 수행, 이러한 커넥션을 열어두게 되며, 얼마나 많은 연결을 하게 될지는 user agent가 결정

구글 폰트를 다운받을 때 글꼴을 바로 다운받기 위해 쓰는 트릭이기도 했다. [Make your Google Fonts render faster]

주의사항

Preconnect는 외부 도메인과 연결을 구축하기 때문에 많은 CPU 시간을 차지할 수 있으며 보안 연결의 경우 더 많은 시간을 차지 할 수 있다.

Preconnect는 10초 이내에 해당 서버에게 요청할 자원이 없으면 끊어진다는 것을 명심하자.

2.1.4 스크롤 없이 볼 수 있는 영역 우선

개요

분류: content

스크롤 없이 볼 수 있는 영역(ATF, Above The Fold)을 먼저 로드하도록 구성해야 한다. [Authoring Critical Above-the-Fold CSS]

스크롤 없이 보이는 부분에 우선순위 부여[from stackoverflow]

해결방법

- 레이아웃 구성

시각적으로는 동일하지만 서로 다른 레이아웃으로 나누어 만든다면 가능하다. [Prioritize visible content]

이렇게 만들면 ATF의 CSS를 위한 부분과 나머지로 분할할 수도 있다.

- 주요 컨텐츠 우선

또한 페이지의 주요 컨텐츠를 먼저 로드하는 것이 좋다.

서버의 초기 응답에서 페이지의 중요한 부분을 렌더링하는 데 필요한 데이터를 즉시 보내고 나머지를 지연하도록 페이지를 구성해야한다는 것이다.

사이드바, footer영역, 기타 제3자 위젯(SNS 공유 위젯 등)등은 메인 컨텐츠보다 중요치 않다.

따라서 컨텐츠가 점진적으로 렌더링 되도록 만든다.

<html>
<body>
  <content>
  </content>
  <sidebar>
  </sidebar>
</body>
</html>

- CSS 분리 및 비동기 로드

중요한 CSS 결정 도구를 사용하면 첫화면에 사용되는 CSS만 따로 뽑아 인라인으로 사용할 수 있다. [Extract critical CSS, Critical-path (Above-the-fold) CSS Tools, How to speed up the initial rendering of a web page]

가장 간단히 비동기적으로 로드할 수 있는 방법은 다음처럼 설정하는 것이다. [The Simplest Way to Load CSS Asynchronously, The Simplest Way to Load CSS Asynchronously, Loading CSS without blocking render]

<link rel="stylesheet" href="/path/to/my.css" media="none" onload="if(media!='all')media='all'">

media를 none으로 설정하면 화면의 렌더링을 막지 않기 때문에 일단 다운로드 후, onload 이벤트가 일어날때까지 미룬후 all로 바꾸어 로딩하자는 일종의 꼼수.

라이브러리 중에서 loadCSS를 사용하면 나머지 CSS를 비동기적으로 로드할 수 있다.[Authoring Critical Above-the-Fold CSS]

또는 다음처럼 하여 첫 번째 페인트 후 로드되도록 하는 것이 가능. (역시 렌더링을 차단하지 않는다) [차이: Google deferred CSS vs loadCSS]

<html>
  <head>
    <style>
      .blue{color:blue;}
    </style>
    </head>
  <body>
    <div class="blue">
      Hello, world!
    </div>
    <noscript id="deferred-styles">
      <link rel="stylesheet" type="text/css" href="small.css"/>
    </noscript>
    <script>
      var loadDeferredStyles = function() {
        var addStylesNode = document.getElementById("deferred-styles");
        var replacement = document.createElement("div");
        replacement.innerHTML = addStylesNode.textContent;
        document.body.appendChild(replacement)
        addStylesNode.parentElement.removeChild(addStylesNode);
      };
      var raf = window.requestAnimationFrame || window.mozRequestAnimationFrame ||
          window.webkitRequestAnimationFrame || window.msRequestAnimationFrame;
      if (raf) raf(function() { window.setTimeout(loadDeferredStyles, 0); });
      else window.addEventListener('load', loadDeferredStyles);
    </script>
  </body>
</html>

유용한 웹팩 플러그인을 찾았다.

Critters

나중에는 웹컴포넌트의 HTML Import를 사용할 수 있다면, 렌더링을 차단하지 않고도 CSS를 로드할 수도?? [HTML Rocks: HTML Import]

HTML Import가 표준으로 안들어 갈 것 같은 분위기가 문제일것 같긴 하다만.

2.1.5 사이트 빌더

개요

분류: Conent

자바스크립트로 클라이언트 렌더링을 하는 것보다 HTML과 CSS를 생성 시킨채 배포한다면 동적인 작업이 줄어들고 봇이 해석하기 편하므로 성능/SEO에 모두 유리하다. [Is 0kb of JavaScript in your Future?]

해결방법

사이트 빌더들을 사용해보자.

Astro: React, Preact, Vue, Svelte, Solid등 가능, Partical hydration 지원
Elder.js: Svelte용, Partical hydration 지원, 사용자 지정 라우팅
Gatsby: React용, 정적 사이트 생성(SSG, Static Site Generation), 지연된 정적생성(DSG, Deferred Static Generation), 서버 사이드 렌더링(SSR, Server Side Rendering) 처럼 다양한 렌더링 옵션 제공
Eleventy: 정적 사이트 생성기로, 마크다운, 11ty.js, Liquid(또 다른 문서), Nunjucks, Handlebars, EJS, Pug와 같은 HTML 템플릿 지원. JS 사용을 최대한 피하도록 구성

기타 차이점은 Astro vs X에서 잘 정리해둔편.

react-snap같은 프리렌더러, react static같이 SSG에 최적화된 프레임워크도 살펴볼만하다.

2.1.6 Lazy load

개요

분류: Conent, Image

느긋하게(Lazy) 로딩을 하면 시간을 아낄 수 있다. [이미지 및 동영상의 지연 로딩, Lazy loading, Lazy Loading Images – The Complete Guide, Image Lazy Loading 기법 그리고 Google I/O 에서의 새로운 방법, Lazy Loading 이란?]

하지만 주의해야 할 것이 존재한다.

처음 보이는 화면은 하지 않는 것이 나음
스크롤을 내려야 이미지 로드를 시작해 느려보일수도 있음
자리 표시자가 없으면 레이아웃 변경이 생길 수 있음
JS로 대형 이미지를 로딩시 잠시 반응하지 않을 수 있음
로드가 실패할 수 있음
JS를 사용하지 못할 수도 있음

해결방법

- Intersection Observer

IntersectionObserver를 사용하면 간단하게 lazy 로드를 할 수 있다.

<img class="lazy" src="placeholder-image.jpg" data-src="image-to-lazy-load-1x.jpg" data-srcset="image-to-lazy-load-2x.jpg 2x, image-to-lazy-load-1x.jpg 1x" alt="저는 이미지입니다!">

lazy란 클래스 속성으로 선택할 요소 지정
src에는 자리 표시자 이미지
data-src와 data-srcset으로 로드할 이미지의 URL을 담음

이때 Intersection Observer를 사용하면

document.addEventListener("DOMContentLoaded", function() {
  var lazyImages = [].slice.call(document.querySelectorAll("img.lazy"));

  if ("IntersectionObserver" in window) {
    let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          let lazyImage = entry.target;
          lazyImage.src = lazyImage.dataset.src;
          lazyImage.srcset = lazyImage.dataset.srcset;
          lazyImage.classList.remove("lazy");
          lazyImageObserver.unobserve(lazyImage);
        }
      });
    });

    lazyImages.forEach(function(lazyImage) {
      lazyImageObserver.observe(lazyImage);
    });
  } else {
    // Possibly fall back to a more compatible method here
  }
});

DOMContentLoaded 시, lazy 클래스의 모든 이미지에 대한 DOM을 조회해 lazy load 대상 이미지 영역에 진입시 콜백을 실행하는 옵저버를 생성한다.

- 이벤트 핸들러 사용

scroll 이벤트, resize 이벤트를 받아서 getBoundingClientRect()같은 DOM API를 사용해도 뷰포트 위치를 계산할 수 있다.

(호환성이 좋다.)

아래 코드를 사용하면 위와 같은 방식으로 로드할 수 있다.

document.addEventListener("DOMContentLoaded", function() {
  let lazyImages = [].slice.call(document.querySelectorAll("img.lazy"));
  let active = false;

  const lazyLoad = function() {
    if (active === false) {
      active = true;

      setTimeout(function() {
        lazyImages.forEach(function(lazyImage) {
          if ((lazyImage.getBoundingClientRect().top <= window.innerHeight && lazyImage.getBoundingClientRect().bottom >= 0) && getComputedStyle(lazyImage).display !== "none") {
            lazyImage.src = lazyImage.dataset.src;
            lazyImage.srcset = lazyImage.dataset.srcset;
            lazyImage.classList.remove("lazy");

            lazyImages = lazyImages.filter(function(image) {
              return image !== lazyImage;
            });

            if (lazyImages.length === 0) {
              document.removeEventListener("scroll", lazyLoad);
              window.removeEventListener("resize", lazyLoad);
              window.removeEventListener("orientationchange", lazyLoad);
            }
          }
        });

        active = false;
      }, 200);
    }
  };

  document.addEventListener("scroll", lazyLoad);
  window.addEventListener("resize", lazyLoad);
  window.addEventListener("orientationchange", lazyLoad);
});

- Loading 속성

<img>나 <iframe>같은 경우 loading 속성을 이용해 사용이 가능하다.

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

- 비디오 Lazy Load

이미지처럼 동영상도 Lazy Load 할 수 있다.

일반적으로 <video>로 사용하지만, 제한적으로는 <img> 를 사용하는 것도 쓸만한 모양

자동 재생하지 않는 경우

자동 재생(Autoplay)을 하지 않는 경우 preload를 할 필요가 없다.

<video controls preload="none" poster="one-does-not-simply-placeholder.jpg">
  <source src="one-does-not-simply.webm" type="video/webm">
  <source src="one-does-not-simply.mp4" type="video/mp4">
</video>

자동 재생을 해야할 때 프리로드하지 않으면, 느려질 수도 있기 때문에 사용하지 않는 것이 좋다. [Fast Playback with Video Preload]

GIF

GIF는 자동 재생이 되어야 한다는 것이 가장 큰 차이다.

<video autoplay muted loop playsinline class="lazy" width="610" height="254" poster="one-does-not-simply.jpg">
  <source data-src="one-does-not-simply.webm" type="video/webm">
  <source data-src="one-does-not-simply.mp4" type="video/mp4">
</video>

역시 data-src를 src로 바꿔주면 끝.

document.addEventListener("DOMContentLoaded", function() {
  var lazyVideos = [].slice.call(document.querySelectorAll("video.lazy"));

  if ("IntersectionObserver" in window) {
    var lazyVideoObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(video) {
        if (video.isIntersecting) {
          for (var source in video.target.children) {
            var videoSource = video.target.children[source];
            if (typeof videoSource.tagName === "string" && videoSource.tagName === "SOURCE") {
              videoSource.src = videoSource.dataset.src;
            }
          }

          video.target.load();
          video.target.classList.remove("lazy");
          lazyVideoObserver.unobserve(video.target);
        }
      });
    });

    lazyVideos.forEach(function(lazyVideo) {
      lazyVideoObserver.observe(lazyVideo);
    });
  }
});

- 주의사항

처음 보이는 화면

메뉴나 헤더등에는 적용하지 말고, 메인 컨텐츠에서도 처음나오는 3~4개까지는 적용을 하지 않으면 보완할 수 있다.

스크롤을 내려야 로드 시작

마진을 주면 스크롤 전에 로드를 시작하여 로드가 느려보이는 점을 보완할 수 있다.

let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
  // Lazy loading image code goes here
}, {
  rootMargin: "0px 0px 256px 0px"
});

처럼.

자리 표시자

설명할 수 있는 옵션이 많아 렌더링의 UX 파트에서 따로 다루도록 한다.

JS로 대형 이미지 로드

곧 나올 Streams를 이용해 청크 단위로 다운을 받거나 Image()를 이용한다. [Image loading with image.decode()]

const newImage = new Image();
newImage.src = "my-awesome-image.jpg";

if ("decode" in newImage) {
  // Fancy decoding logic
  newImage.decode().then(function() {
    imageContainer.appendChild(newImage);
  });
} else {
  // Regular image load
  imageContainer.appendChild(newImage);
}

단, Lazy 로드 알고리즘을 복잡하게 만들수도 있다.

로드 실패시

다음처럼 예외처리를 하고, 다시로드 버튼이나 오류 메세지를 표시할 수 있다.

const newImage = new Image();
newImage.src = "my-awesome-image.jpg";

newImage.onerror = function(){
  // Decide what to do on error
};
newImage.onload = function(){
  // Load the image
};

JS 미사용

<!-- An image that eventually gets lazy loaded by JavaScript -->
<img class="lazy" src="placeholder-image.jpg" data-src="image-to-lazy-load.jpg" alt="저는 이미지입니다!">
<!-- An image that is shown if JavaScript is turned off -->
<noscript>
  <img src="image-to-lazy-load.jpg" alt="저는 이미지입니다!">
</noscript>

자세한 것은 자바스크립트 가용성을 참고.

- 라이브러리

lazysizes: 이미지와 iframe을 lazy load하는 라이브러리로 다양한 기능을 가지고 있다. 여러가지 확장이 있다.
lozad.js: Intersection Observer를 이용하는 경량 라이브러리
yall.js: Intersection Observer를 이용하는 경량 라이브러리2
blazy: IE7+를 지원하는 가벼운 라이브러리
react-lazyload: 리엑트 개발자에게 익숙한 방식을 제공

기타 이미지 로딩 최적화는 The Humble <img> Element And Core Web Vitals에서 잘 설명하고 있다. (트윗)

2.1.7 버퍼를 일찍 비우기(Flush)

개요

분류: Server

사용자가 페이지를 요청하면 백엔드 서버가 HTML 페이지를 함께 연결하는 데 200 ~ 500ms가 소요될 수 있다.

이 시간 동안 데이터가 도착할 때까지 브라우저는 유휴 상태이다.

이를 보완할 만한 대책은 flush() 함수(PHP 기준)다.

부분적으로 준비된 HTML 응답을 브라우저로 보내는것을 허용함으로써 백엔드가 나머지 HTML 페이지로 바쁠때 브라우저는 구성요소를 가져오는 것(fetching)을 시작할 수 있다.

이 이점은 주로 바쁜 백엔드 또는 가벼운 프론트엔드에서 볼 수 있다.

Flushing

head에 대한 HTML은 일반적으로 생성하기 쉬우며 백엔드가 동작하는 동안 브라우저가 CSS나 JavaScript 파일들을 병렬적으로 가져오도록 포함 할 수 있다.

따라서 </head> 바로 다음이 플러시를 고려하기 좋은 위치이다.

해결방안

PHP, ASP, JSP와 같은 템플릿 엔진들은 다음처럼 플러싱을 할 수 있다. [HTTP Archive: adding flush, Progressive rendering via multiple flushes, Speeding Up Page Load with Early Flush, Async Fragments: Rediscovering Progressive HTML Rendering with Marko]

 ... <!-- css, js -->
</head>
<?php flush(); ?>         <!-- PHP -->
<% Response.Flush(); %>   <!-- ASP.NET -->
<% out.flush() %>         <!-- JSP -->
<body>
... <!-- content -->

파이썬 Flask의 경우 스택오버플로우를 참고해볼 수 있다.

Marko라는 템플릿 엔진은 플러싱의 이점을 극대화 하여 비동기 프레그먼트를 비순차적으로 플러싱 할 수 있다.

Out-of-order flushing of Async Fragments

Async Fragment는 리엑트의 React.lazy와 비슷하다.

페이스북의 빅파이프(BigPipe)로 유명하다. [BigPipe: Pipelining web pages for high performance(번역), Faster Web Page Loading with Facebook BigPipe, Facebook Bigpipe Technique Algorithm]

여기 몇가지 괜찮은 구현체/샘플이 있다.

웹소켓을 이용해 파이프라이닝을 해보려는 시도도 있다. [SPADOCK: Adaptive Pipeline Technology for Web System using WebSocket]

기타 흥미로울 만한 것은 처음에만 정적 페이지, 이후에는 동적으로 로드하는 유튜브의 SPF(Structured Page Fragments)와 세분화된 Lazy loading을 제공하는 Qwik 정도?

2.2 제한

2.2.1 유효성

개요

분류: Content, CSS

유효성(Validation)을 지키지 않으면 파싱시 느려질 수도 있다.

다음 성능과 관계된 몇가지 예시이다.

- 닫힌 태그

HTML의 frame, img, li, p등을 닫힌태그(</태그>) 없이 암시적으로 사용해도 페이지는 잘 렌더링 된다.[Building High Performance HTML Pages]

<p>The following is a list of ingredients.
<ul>
<li>flour
<li>sugar
<li>butter
</ul>

실제로 렌더링 가능

하지만 끝나는 위치를 미리 결정할 필요 없기 때문에 닫혀있는 상태 파싱이 더 빠르다.

- 크기 지정

이미지의 width와 height 속성을 생략시 크기를 정확히 모르기 때문에 Placeholder를 할당하고, 리플로우시 레이아웃이 업데이트 되어야 하기 때문에 성능에 영향을 미친다.

테이블도 역시 width와 height 속성을 생략하면 리플로시 업데이트가 필요하다.

또한

  table-layout: fixed;

를 사용하고, <col>과 <colgroup>에 width를 지정하는 것이 좋다.

- 빈문자열 src 이미지

빈 문자열 src 속성을 가진 이미지가 하나 이상 발생할 것으로 예상되고 두 가지 형태로 나타난다.

1. straight HTML

<img src="">

2. JavaScript

var img = new Image();
img.src = "";

왜 이런 동작은 좋지 않을까?

특히 하루에 수백만 페이지를 보는 페이지에 대해 대량의 예기치 않은 트래픽을 보내 서버를 손상시킨다.
서버는 절대 보여지지 않을 페이지를 생성하는 사이클(cycles)을 컴퓨팅 하는 것으로 낭비된다.
사용자 데이터는 오류가 생길 가능성이 있다.
만약 요청이 추적상태에 있다면, 쿠키 또는 다른 방식으로 데이터를 파괴할 가능성이 있다.
비록 이미지 요청이 이미지를 반환하지 않더라도, 모든 쿠키들을 포함하는 브라우저에 의해 모든 header들은 읽고 수락될 수 있다. 응답의 나머지가 버려지는 동안, 이미 손상 되었을지도 모른다.

이 작동의 근본 원인은 URI 해상도가 browser에서 실행되는 방식 때문이다.

이것은 RFC 3986- Uniform Resource Identifiers에 정의되어 있다.

빈 문자열이 URI로 발생되면, 그것은 상대적인 URI로 간주되며, 5.2 섹션에 정의된 알고리즘에 따라 해결된다.

구체적인 예를 들자면, 5.4 섹션에 등록된 빈 문자열이다.

Internet Explorer가 부정확하게 실행되는 동안, 명백히 RFC 2396 - Uniform Resource Identifiers 사양(이것은 RFC 3986에 의해 더 이상 사용되지 않음)의 초기버전과 일맥상통하는 Firefox, Safari, 그리고 Chrome 섹션은 모두 사양마다 정확하게 빈 문자열을 해결할 것이다.

그래서 기술적으로, browsers는 상대적 URIs를 해결하기 위한 것들을 수행 중이다.

이 문맥에서의 문제는, 빈 문자열은 명확히 의도적이지 않다는 것이다.

HTML 5는 섹션 4.8.2에서 추가요청을 하지 않는 browsers를 지시하기 위해 태그의 src 속성의 설명을 추가한다:
src 속성은 반드시 존재해야 하고, 페이지 및 script되지 않으며 쌍방향이 아니고(non-interactive), 선택적으로 애니메이션(optionally animated)된 이미지 자원(image resource)을 참조하는 유효한 URL을 반드시 포함해야 한다. 만약 요소(element)의 기본 URI가 문서의 주소와 동일한 경우, src 속성값은 빈 문자열이어서는 안 된다.

다행히 앞으로 브라우저에는 이 문제가 없을 것이다.

하지만 불행히도 <script src=""> 및 <link herf="">에는 해당 조항이 없으니 브라우저가 실수로 이 동작을 구현하지 않도록 조정해야 할 때가 있다.

이 규칙은 Yahoo!의 JavaScript 전문가 인 Nicolas C. Zakas에서 영감을 받았으며 자세한 내용은 "Empty image src can destroy your site "라는 기사를 확인하면 된다.

- 기타

기타 파싱시 문제가 생기면 오류 수정과정이 필요하니 유효성이 지켜지는 것이 좋다.

다음은 파서의 에러핸들링과 처리 방식이다.

An introduction to error handling and strange cases in the parser

측정방법

src="" 를 가진 img 갯수는 중복 스크립트를 찾을 때의 코드를 조금만 수정하면 된다.

const imgs = document.getElementsByTagName("img");
[...imgs].map(img => img.src)
  .filter(src => src === "")

2.2.2 @import보다 <link> 사용

개요

분류: CSS
이전 모범 사례 중 하나는 점진적 렌더링을 허용하기 위해 CSS가 최상위에 있어야 한다는 것이 있었다.

@import를 사용하면 CSS를 병렬로 다운로드할 수 없으며,

IE에서는 페이지 하단에서 @import사용하는 것과 동일하게 작동 하므로 사용하지 않는 것이 가장 좋다.

해결방안

이러한 @import보다

/* at CSS file */
@import url("EXAMPLE.css")

<!-- at HTML file -->
<link href="EXAMPLE.css" rel="stylesheet" />

2.2.3 미디어 쿼리 사용하기

개요

분류: CSS

특정 조건에서만 필요한 CSS가 있을 때 미디어 쿼리를 사용하면 불필요한 블로킹을 막을 수 있다.

즉, 해당 스타일이 참일 때만 적용된다는 것.

미디어 쿼리 구분은 미디어 유형(media-type), 미디어 특성(media-feature-rule), 논리연산자로 이루어져 있다.

미디어 유형

all: 모든, 기본값
print: 인쇄 결과물이나 미리보기시 사용
screen: 화면
speech: 음성 합성장치

주요 미디어 특성

width/height: 뷰포트 너비/높이
aspect-ratio: 뷰포트 가로세로비
orientation: 뷰포트 방향
resolution: 출력장치의 해상도
scan: 출력장치의 스캔 방법(초당 60회, 30회 등)
color: 출력장치의 색상 채널별 비트 수, 흑백은 0

이외에 고대비, 다크모드등 선호도를 조절할 수 있으므로, 잘 써보도록 하자.

논리연산자

,: 논리합, 흔히 생각하는 or과 같다.
and: 논리곱
not: 부정, 개별의 쿼리가 아니라 전체에만 적용된다.
only: 미디어 쿼리를 미지원하는 낡은 브라우저에 대응하여 특정 스타일 적용

해결방법

미디어 쿼리를 사용하는 방법은 CSS 내부와 외부 2가지 방법으로 나눌 수 있다.

내부

/* 형식 */
@media 미디어타입 논리연산자 (미디어특성) { ... }

/* 샘플 */
@meida all { ... }
@media print { ... }
@media (orientation: portrait) { ... }
@media (min-width: 30em) and (max-width: 50em) { ... }

외부

<!-- 형식 -->
<link rel="stylesheet" type="text/css" href="EXAMPLE.css" media="미디어타입 논리연산자 (미디어특성)"/>

<!-- 샘플 -->
<link rel="stylesheet" type="text/css" href="style.css"/>
<link rel="stylesheet" type="text/css" href="print.css" media="print" />
<link rel="stylesheet" type="text/css" href="portrait.css" media="orientation:portrait" />
<link rel="stylesheet" type="text/css" href="min_max.css" media="(min-width: 30em) and (max-width: 50em)" />

이중 어떤 것을 사용하면 좋을까?

만약 외부분기를 사용할 때 조건에 따라 다운로드한다면 상당히 유용할 것이다.

그러나 불행히도 <link>의 미디어 쿼리의 조건이 거짓일지라도 CSS는 다운된다.

따라서 CSS 파일은 병합하고, CSS 코드 내부에서 분기하는 것이 좋다.

2.2.4 리다이렉션 방지

개요

분류: content

리디렉션(재전송)은 301이나 302 상태 코드를 사용하여 수행한다.

다음은 301 응답의 HTTP 헤더 예이다.

      HTTP/1.1 301 Moved Permanently
      Location: https://example.com/newuri
      Content-Type: text/html

브라우저가 자동으로 사용자를 Location 필드에 지정된 URL로 이동시킨다 .

리디렉션에 필요한 모든 정보는 헤더에 있으며, 응답한 본문은 일반적으로 비어 있다.

Expires또는 Cache-Control과 같은 추가 헤더를 제외하고 301도 302 응답 어느 쪽도 실제로 캐시되지 않는다.

다음의 메타 리프레시 태그나 자바스크립트는 사용자를 리다이렉션 할 수 있지만..

<meta http-equiv="Refresh" content="0; URL=https://example.com/newuri/">

window.location = "https://example.com/newuri/";

반드시 리다이렉션을 해야 한다면, 뒤로가기 버튼이 올바르게 작동하도록 표준 3xx HTTP 상태 코드를 사용하는 것이 좋다.

기억해야 할 것은 리다이렉션이 사용자 경험을 느리게 한다는 것.

사용자와 HTML 문서 사이에 리다이렉션을 삽입하면 페이지의 아무것도 렌더링 할 수없고, HTML 문서가 도착할 때까지 구성 요소를 다운로드 할 수 없으므로 페이지의 모든 항목이 지연된다.

문제는 낭비적인 리다이렉션이 자주 일어나지만 일반적인 개발자는 인식하지 못하는 경우다.
예를들어 URL에서 trailing slash (/)가 누락 된 경우 발생한다.

쉽게 설명하면 http://example.com의 요청시 http://example.com/ (trailing slash 포함)의 리디렉션을 포함하는 301 응답 결과가 전송된다.

예전 사이트를 새로운 사이트에 연결하는 것도 리다이렉션의 또 다른 일반적인 용도다.

웹 사이트의 다른 부분을 연결하고 특정 조건 (기기와 브라우저 유형, 사용자 계정 유형 등)에 따라 사용자를 안내하는 것도 있다.

리다이렉션을 사용하여 두 웹 사이트를 연결하는 것은 간단하며 추가 코딩이 거의 필요하지 않다.

하지만 개발자의 복잡성이 줄어드는 반면 사용자 환경이 저하된다는 점은 반드시 염두해두어야 한다.

해결방법

- trailing slash

이것은 Alias, mod_rewrite, DirectorySlash 지시어를 사용함으로써 Apache에서 해결된다.

- 리다이렉션 성능 개선

Redirects 사용에 대한 다른 대안은 두 code 경로가 같은 서버에 host되는 경우, Alias와 mod-rewrite를 사용하는 것이다. 도메인 이름변경을 위해 redirects를 사용한다면 Alias 또는 mod_write를 결합하여 CNAME(DNS record: 하나의 도메인 이름을 다른 것으로 가리키는 별칭도메인을 생성)를 생성하면 된다.

- 반응형 디자인

적응형 디자인을 적용하기 위해 리다이렉트 하는 경우가 있다.

모바일 사이트를 분리하는 경우가 대표적이다.

example.com
example.com -> m.example.com

만약 반응형 디자인을 도입한다면 리다이렉트 없이 데스크탑, 모바일에 맞는 사이트를 만드는 것이 가능하다.

이와 별도로 적응형 웹은 별도 URL, 반응형 웹은 반응형 웹 디자인 기본 사항이 입문에 좋은 문서같다. [적응형 웹 디자인 VS 반응형 웹 디자인, 반응형 웹을 위한 레이아웃 설계 방법(1편, 2편)]

2.2.5 iframe 수를 최소화

개요

분류: content
Iframe을 사용하면 HTML 문서를 부모 문서에 삽입 할 수 있다.

Iframe이 효과적으로 사용되도록 작동하는 방식을 이해하는 것이 중요하다.

iframe의 단점은 다음과 같다.

비어있더라도 비쌈[Using Iframes Sparingly]
page onload를 차단함
대역폭을 메인 페이지와 경쟁
Non-semantic (비의미론적이다)
기타 보안 사항에 취약

해결방법

- Ajax 활용

Ajax를 이용해 데이터를 로드해서 div에 결합할 수 있다.[Best approach to replace iframes]

- 대체 태그 사용??

다른 방식으로 삽입을 하는 것을 생각해보자면 object와 embed란 태그가 있다.

그러나 From object to iframe — other embedding technologies, difference between iframe, embed and object elements, What is the difference between <iframe>, <object> and <embed>?, <iframe> vs <object> vs <embed>와 같은 글을 읽어보면 딱히 대체품이 될 수 없을 듯 하다.

HTML5의 audio, video, web components 가 대안이 될 수 있겠다.

구글은 iframe 대신 potal이란 태그를 발표하기도 했지만 이제 막 논의될랑 말랑 하기 때문에 무시해도 좋다.

[Google launches Portals, a new web page navigation system for Chrome, Hands-on with Portals: seamless navigation on the Web]

2.2.6 document.write() 사용하지 않기

개요

분류: Javascript

document.write()는 사이트를 느리게 만들 수 있다. [Intervening against document.write(), Why you should avoid using document.write, specifically for scripts injection, Don't docwrite scripts]

특히 document.write()를 통해 동적으로 스크립트를 삽입한다면 매우 느려질 수 있다.

document.write('<script src="https://paul.kinlan.me/ad-inject.js"></script>');

HTML 파싱을 중단하고, 리소스가 로드되어 실행 될때까지 기다려야 하기 때문인데, 크롬의 경우 차단하기 까지도 한다.

DOM 트리가 만들어진 후, document.write가 사용되면 다시 빌드를 해야하므로 역시 성능에 좋지 않다.

해결방안

스크립트 로드는 앞서 나온 defer, async로 하며, 굳이 자바스크립트로 해야 하다면 DOM 조작을 통해서 하면 된다.

const sNew = document.createElement ( "script"); 
sNew.async = true; 
sNew.src = "https://example.com/script.min.js"; 
const s0 = document.getElementsByTagName ( 'script') [0]; 
s0.parentNode.insertBefore (sNew, s0);

2.2.7 textContent 사용

개요

분류: Javascript

자바스크립트에서 텍스트를 다룰때 textContent, innerText, innerHTML 3가지를 생각해볼 수 있다. [당신이 innerHTML을 쓰면 안되는 이유]

이 중 textContent의 성능이 가장 좋은 편이다.

innerText: CSS를 고려하기 때문에 innerText값을 읽으면 최신 계산값을 반영하기 위해 리플로우가 발생
innerHTML: HTML로 분석하는 과정 필요

특히, innerHTML은 성능이 나쁘고, XSS(Cross-Site Scripting)에 취약해 사용하지 않는 것이 좋다.

2.2.8 CSS 선택자

개요

분류: CSS

CSS 작성을 효율적으로 하면 스타일 계산을 줄일 수 있다. [스타일 계산의 범위와 복잡성 줄이기]

특히 스타일 계산시 50%는 선택자를 매칭하는데 사용하기 때문에 크게 줄일 수 있다. [Blink에서 스타일 무효화]

CSS 셀렉터는 오른쪽부터 읽으며, 실패하는게 좋다. (중복 최소화)

선택자별 성능차

셀렉터별로 성능차가 존재한다. [CSS Selectors: Should You Optimize Them To Perform Better?, Efficiently Rendering CSS, Writing Efficient CSS for use in the Mozilla UI]

id가 가장 빠르고, 가상 클래스가 가장 느리다.

id (#myid)
class (.myclass)
tag (div, h1, p)
adjacent sibling (h1 + p)
child (ul > li)
descendent (li a)
universal (*)
attribute (a[rel=”external”])
pseudo-class and pseudo element (a:hover, li:first)

선택자 복잡성

예를 들어 다음은 box의 마지막의 $-n+1$번째를 상위요소로 둔 .title 클래스를 고르는 것이다.

.box:nth-last-child(-n+1) .title {
  /* styles */
}

만약 다음처럼 하면 계산이 줄어든다.

.final-box-title {
  /* styles */
}

규칙

구조적으로 CSS를 작성하면 선택의 복잡성이 줄어들 수 있다.

예를 들어 BEM은 단일 클래스 계층을 가지기 때문.

.list { }
.list__list-item { }

BEM 형식의 코드

다음은 CSS 방법론들 [[번역] 공룡을 위한 모던 CSS, [번역] CSS개선을 위한 SEM과 BIO의 결합, Happy with your CSS files in your big app?, CSS 방법론, Atomic Design System architecture with ITCSS, BEM, SASS, Journey to Enjoyable, Maintainable Styling with React, ITCSS, and CSS-in-JS, Methods to Organize CSS]

일단 JSS 계열에서 Styled Components/Emotion, Aphrodite와 Styletron이 눈에 띄는 것 같다.

일반 CSS in JS vs Styletron

특히 Styletron의 atomic 방식은 크기를 줄여줄 수 있어 특이한 듯(대신 셀렉터가 늘어나 렌더링 성능과 트레이드오프)

JS를 이용해 CSS를 생성하는 방식은 런타임시에 영향을 미칠 수 있는데 [The unseen performance costs of modern CSS-in-JS libraries in React apps, Styling? with Linaria!, How is Linaria different from Emotion and Styled Components, The tradeoffs of CSS-in-JS]

Linaria(장점)를 사용하면 정적으로 생성할 수 있든 듯 하다.

SASS와 PostCSS도 사용가능한 것 같고.

최근에 css-blocks란 프로젝트를 찾았다.

CSS 모듈, BEM, Atomic CSS의 장점을 모두 활용하려는 듯.

마이크로소프트에서 만든 Griffel 또한 CSS-In-JS, AOT Compile, Atomic CSS를 지원하는 강력한 라이브러리다.

2.2.9 IE 독점 CSS

개요

분류: CSS

다음은 IE 독점 CSS 최적화에 관련된 내용이다.

- CSS 표현식 피하기

CSS 표현식은 CSS 속성을 동적으로 설정하는 강력하고 위험한 방법이다.

버전 5부터 Internet Explorer에서 지원되었지만 IE8부터는 더 이상 사용되지 않으므로 신경 쓸 필요는 없다.

예를 들어 CSS 표현식을 사용하여 매시간마다 배경색을 번갈아 설정할 수 있는데

background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

expression은 JavaScript 표현식을 사용하며 CSS 속성은 JavaScript 표현식을 평가 한 결과로 설정된다.

이 expression방법은 다른 브라우저에서 무시되므로 Internet Explorer에서 속성을 설정하여 브라우저간에 일관된 환경을 만드는 데 유용했다.

expression의 문제점은 대부분의 사람들이 기대하는 것보다 더 자주 평가된다는 것.

페이지가 렌더링되고 크기가 조정될 때뿐만 아니라 페이지가 스크롤 될 때와 사용자가 페이지 위로 마우스를 움직일 때도 평가된다.

CSS 표현식에 카운터를 추가하면 CSS 표현식이 언제 그리고 얼마나 자주 평가되는지 추적 할 수 있다.

페이지 주위로 마우스를 이동하면 10,000 개가 넘는 평가를 쉽게 생성 할 수 있다.

- AlphaImageLoader 필터 피하기

AlphaImageLoader필터는 IE 버전 7이하에서 반투명 트루 컬러 PNG의 문제를 해결하는 것을 목표로 한다.

모던 브라우저에서 신경 쓸 필요 없다는 뜻.

이 필터의 문제점은 이미지를 다운로드하는 동안 렌더링을 차단하고 브라우저를 정지시키는 것이다.

또한 메모리 소비가 증가하고 이미지가 아닌 요소별(element)로 적용되므로 문제가 배가 된다.

해결방법

- CSS 표현식 피하기

CSS 표현식의 평가 횟수를 줄이는 한 가지 방법은 일회성 표현식을 사용하는 것이다.

여기서 표현식을 처음 평가할 때 스타일 특성을 명시 적 값으로 설정하여 CSS 표현식을 대체한다.

스타일 속성을 페이지 수명 동안 동적으로 설정해야하는 경우 CSS 표현식 대신 이벤트 핸들러를 사용하는 것이 대안이다.

CSS 표현식을 사용해야하는 경우 수천 번 평가 될 수 있으며 페이지 성능에 영향을 줄 수 있다는 것을 명심해야 한다.

- AlphaImageLoader 필터 피하기

가장 좋은 방법은 AlphaImageLoader를 완전히 사용하지 말고, PNG8을 사용하는 것.

꼭 필요한 경우 hack_filter를 사용하여 IE7 + 사용자에게 불이익을 주지 않도록 해야한다.

2.3 효율적 활용

2.3.1 Streams

개요

분류: Javascript

Streams를 이용하면 성능 향상의 여지가 있다. [2016년은 웹 스트림(web stream)의 해다., A Guide to Faster Web App I/O and Data Operations with Streams]

특히 커다란 요소를 점진적으로 렌더링을 하거나, 가져와서(fetch) 변환해야 할 때 유용하다.

해결방법

MDN의 stream 예제는 이미지를 그레이스케일로 바꾸거나, 커다란 이미지를 청크로 나누어 전송하는 것을 보여준다.

오프라인 위키피디아 데모(깃허브)에 적용되었다고 하는데 후술할 서비스 워커와 함께 사용해 상당히 좋은 성능을 보여준다. [Stream Your Way to Immediate Responses]

관심이 간다면 깃허브 소스를 확인해 볼 수 있다.

streaming-css처럼 점진적으로 CSS를 적용하도록 만들 수도 있긴한데, 전체를 로드하는 시간이 더 빨라 좋은 방법이 아니다.

React는 ReactDOMServer에서 스트림을 지원하는 듯. 조금 오래된 react-dom-stream도 있다.

2.3.2 iframe 활용

개요

분류: Content

iframe은 단점이 많지만 iframe도 장점이 있다.

배지(badges)나 광고와 같이 느린 third-party content를 원활하게 함
Security sandbox (보안 sandbox)
scripts를 병렬로 다운로드 함

해결방법

- Non-Blocking 로드

앞서 iframe의 단점의 주요 원인은 다음과 같다.

onload 이벤트가 발생하기 전에 iframe 로드
src 속성은 다운로드 받아야 하는 리소스

따라서 onload 전에 iframe이 오는 것를 막거나(onload 이벤트 이후 비동기적 로드), src 속성없이 iframe을 사용한다면 성능상 불이익은 없다. [Using Iframes to Address Third-Party Script Issues and Boost Performance(번역)]

리소스 힌트가 먹히지 않는 구형 브라우저를 사용한다면 iframe을 이용해 로드를 시도해보자.[A CSP Compliant non-blocking script loader, Non-Blocking Loader Snippet, Loading Third-Party JavaScript]

<script id="nb-loader-script">
(function(url) {

  // document.currentScript works on most browsers, but not all
  var where = document.currentScript || document.getElementById("nb-loader-script"),
      promoted = false,
      LOADER_TIMEOUT = 3000,
      IDPREFIX = "__nb-script";

  // function to promote a preload link node to an async script node
  function promote() {
    var s;
    s = document.createElement("script");
    s.id = IDPREFIX + "-async";
    
    s.src = url;

    where.parentNode.appendChild(s);
    promoted = true;
  }

  // function to load script in an iframe on browsers that don't support preload hints
  function iframe_loader() {
    promoted = true;
    var win, doc, dom, s, bootstrap, iframe = document.createElement("iframe");

    // IE6, which does not support CSP, treats about:blank as insecure content, so we'd have to use javascript:void(0) there
    // In browsers that do support CSP, javascript:void(0) is considered unsafe inline JavaScript, so we prefer about:blank
    iframe.src = "about:blank";
    
    // We set title and role appropriately to play nicely with screen readers and other assistive technologies
    iframe.title = "";
    iframe.role = "presentation";
    
    s = (iframe.frameElement || iframe).style;
    s.width = 0; s.height = 0; s.border = 0; s.display = "none";
    
    where.parentNode.insertBefore(iframe, where);
    try {
      win = iframe.contentWindow;
      doc = win.document.open();
    }
    catch (e) {
      // document.domain has been changed and we're on an old version of IE, so we got an access denied.
      // Note: the only browsers that have this problem also do not have CSP support.
      
      // Get document.domain of the parent window
      dom = document.domain;
      
      // Set the src of the iframe to a JavaScript URL that will immediately set its document.domain to match the parent.
      // This lets us access the iframe document long enough to inject our script.
      // Our script may need to do more domain massaging later.
      iframe.src = "javascript:var d=document.open();d.domain='" + dom + "';void(0);";
      win = iframe.contentWindow;
      doc = win.document.open();
    }

    bootstrap = function() {
      // This code runs inside the iframe
      var js = doc.createElement("script");
      js.id = IDPREFIX + "-iframe-async";
      js.src = url;
      doc.body.appendChild(js);
    };
    
    try {
      win._l = bootstrap

      if (win.addEventListener) {
        win.addEventListener("load", win._l, false);
      }
      else if (win.attachEvent) {
        win.attachEvent("onload", win._l);
      }
    }
    catch (f) {
      // unsafe version for IE8 compatability
      // If document.domain has changed, we can't use win, but we can use doc
      doc._l = function() {
        if (dom) {
          this.domain = dom;
        }
        bootstrap();
      }
      doc.write('<bo' + 'dy onload="document._l();">');
    }
    doc.close();
  }

  // We first check to see if the browser supports preload hints via a link element
  var l = document.createElement("link");

  if (l.relList && typeof l.relList.supports === "function" && l.relList.supports("preload") && ("as" in l)) {
    l.href = url;
    l.rel  = "preload";
    l.as   = "script";
    
    // If the link successfully preloads our script, we'll promote it to a script node.
    l.addEventListener("load", promote);
    
    // If the preload fails or times out, we'll fallback to the iframe loader
    l.addEventListener("error", iframe_loader);
    setTimeout(function() {
        if (!promoted) {
            iframe_loader();
        }
    }, LOADER_TIMEOUT);
    
    where.parentNode.appendChild(l);
  }
  else {
    // If preload hints aren't supported, then fallback to the iframe loader
    iframe_loader();
  }

})("https://your.script.url/goes/here.js");
</script>

- Iframe + document.write()을 이용한 스트리밍

역시 구 브라우저를 위한 트릭.[웹 페이지에서 컨텐츠를 빠르게 보여주기 위한 트릭]

최신 브라우저의 서비스 워커를 사용하면 좋다. [streaming-html (github)]

서비스워커는 알아야 할 내용이 많아서 따로 다루기로 한다.

모든 내용을 다 받고 나서 보여주기보다는 점진적으로 보여주는 것이 좋다.

하지만 아래 코드는 page-data.inc의 내용을 다운로드 받을 때까지 기다려야 한다.

// ... 브라우저 네비게이션을 구현하기 위한 많은 코드들
const response = await fetch('page-data.inc');
const html = await response.text();
document.querytSelector('.content').innerHTML = html;
// ... 브라우저 네비게이션을 구현하기 위한 많은 코드들

iframe과 document.write() 사용하면 다운로드 받는 내용들을 바로 보여줄 수 있다.

// iframe을 만든다
const iframe = document.createElement('iframe');

// 문서에 숨겨진 형태로 추가한다.
iframe.style.display = 'none';
document.body.appendChild(iframe);

// iframe이 준비될 때 까지 기다린다
iframe.onload = () => {
  // 앞으로의 load 이벤트를 무시한다
  iframe.onload = null;

  // 더미 태그를 만든다
  iframe.contentDocument.write('<streaming-element>');

  // 엘리먼트에 대한 참조를 얻는다
  content streamingElement = iframe.contentDocument.querySelector('streaming-element');

  // 해당 엘리먼트를 iframe문서에서 빼고 부모 문서에 추가한다.
  document.body.appendChild(streamingElement);

  // 컨텐츠를 추가한다 (비동기로 작동한다)
  iframe.contentDocument.write('<p>Hello!</p>');

  // 아래와 같이 컨텐츠를 추가한다. 그러면 끝
  iframe.contentDocument.write('</streaming-element>');
  iframe.contentDocument.close();
};

// iframe을 초기화한다
iframe.src = '';

그러나 document.write()는 성능에 나쁜 요소가 될 수 있다.

따라서 생각해볼만한 것은 JSON 형식으로 가져오는 것인데 보통 우리가 생각하는 JSON은 다음과 같이 생겼다.

{
  "Comments": [
    {"author":"Alex","body":"..."},
    {"author":"Jake","body":"..."}
  ]
}

하지만 스트리밍에 친화적인 포맷이 아니라 스트리밍 JSON 파서를 필요하고 사용법도 까다롭다.

하지만 newline-delimited JSON이라 하여 개행으로 이루어진 JSON을 이용하면 파싱이 훨씬 간단해진다.

{"author":"Alex","body":"..."}
{"author":"Jake","body":"..."}

splitStream과 parseJSON은 재사용 가능한 변화되는 스트림이며, xhr을 사용할 수도 있다. [parse-json.js, xhr-ndjson]

// Sometime in 2017

const response = await fetch('comments.ndjson');
const comments = response.body
  .pipeThrough(new TextDecoder())
  .pipeThrough(splitStream('\n'))
  .pipeThrough(parseJSON());

for await (const comment of comments) {
  addCommentToPage(comment);
}

벤치마크 결과를 보면 안티패턴으로 알려진 iframe + document.write()가 의외로 빠르다는 것을 알 수 있다.

가독성이 나쁘고, 고려할 요소가 많은 것이 문제지만, 신중히만 사용하면 쓸모가 있을지도.

물론, 되도록 사용하지 않는 것이 우선이다.

그낭 서비스 워커 + 스트리밍을 쓰자.

2.3.3 웹 컴포넌트의 최적화 가능성?

개요

분류: Content

웹 컴포넌트는 3개(Import까지 포함했다면 4가지)로 이루어져 있다. [웹 컴포넌트, TOAST UI - 웹 컴포넌트 연재, An Introduction to Web Components]

Custom elements: HTML 요소 및 해당 동작을 정의 및 확장 [Custom Elements]
Shadow DOM: 컴포넌트의 스코프를 분리 [Shadow DOM 101]
HTML Templete: 렌더링된 페이지에 나타나지 않은 마크업으로, 커스텀 엘리먼트 구조를 기반으로 재사용 가능 [HTML's New Template Tag]
HTML Import: 다른 HTML 파일에서 템플릿을 가져올 수 있음 [HTML Imports, Stackoverflow]
단, 현재 분위기상 HTML Import는 제외되는 것 같다.

그럼 웹 컴포넌트에서 어디가 최적화 가능성이 있을까?

Custom elements: React나 Vue 보다 다운받아야 할 양이 적음
HTML Templete: 재사용에 특화가 되었고 바로 렌더링되지 않기 때문에 최적화 가능성이 있을 듯.
파싱이 한번만 일어나며 lit-html에 따르면, 비활성화된 HTML 콘텐츠로 스크립트가 실행되지 않고 스타일이 적용되지 않으며 Custom elements가 업그레이드 되지 않는다.
Shadow DOM: 스코프를 분리하기 때문에 CSS 규칙이 간단해져 최적화 가능성이 있음 [Does shadow DOM improve style performance?, Make Your StencilJS Web Components Faster by Using Shadow DOM(한글)]
1.1.1.1 warp처럼 느려지지 않기 위해 사용한다고 생각하면 좋다.
HTML Import: async 속성을 통해 비동기적으로 가져올 수 있으며, 파싱을 차단하지 않음 [HTML Imports, Stackoverflow]

안타깝게도 현재는 Native에 비해 느린 편이지만 [Styling Web Components Using A Shared Style Sheet]

앵귤러보다 빠르고 [Simplifying Performance with Web Components]

비교적 최신기술이라 최적화가 덜 이루졌을 것이란 점을 고려하면 기대중이다.

웹 컴포넌트를 잘 쓰도록 만들어진 라이브러리에는 [7 Tools for Developing Web Components in 2019]

Stencil
lit-html & LitElement(최근에는 lit으로 통합관리 되는 듯)
Vue.JS
Lighting Web Components
깃허브 [도입 이유]
Fast

등이 있는데 Vue.JS는 최적화가 부족한 모양. [Stencil.js vs lit-element vs Vanilla vs Shadow DOM vs Vue.js What is the best solution for Web component]

Constructable Stylesheet Objects

Constructable Stylesheet Objects는 최초 한번 파싱 후, 공유하는 규칙들을 Shadow DOM을 이용해 적용(Attach)하는 방식으로 재사용이 가능해 성능에 도움을 줄 수 있다. [Constructable Stylesheets: seamless reusable styles, Adopt a Design System inside your Web Components with Constructable Stylesheets, Getting Adoption for Design Systems — A Practical Guide, A Quick Look at Constructable Stylesheets]