<div id="readability-page-1" class="page"><div>타입스크립트에서 enum은 사용하지 않는게 좋다는 말이 있다. 실제로 근거가 있는 내용이며, (특정 조건에서) 의미가 있는 최적화라는 점에 동의한다.
<blockquote>
TypeScript에서 enum을 사용하면 Tree-shaking이 되지 않습니다
<a href="https://engineering.linecorp.com/ko/blog/typescript-enum-tree-shaking/">https://engineering.linecorp.com/ko/blog/typescript-enum-tree-shaking/</a>
</blockquote>
하지만 이 내용은 한편으론 너무 과도하게 받아들여지는 부분이 있다고 생각된다.
enum 키워드 없이 enum 처럼 작동하는 변수를 만드는 방법은 사람이 수작업으로 작업해야 하는 코드의 양을 늘린다. 그렇지만 그에 비해 얻는 효과는 미미하거나 없을 수도 있다.
<pre><code>enum LoLRiftPosition {
 TOP = 'TOP',
 JUNGLE = 'JUNGLE',
 MIDDLE = 'MIDDLE',
 BOTTOM = 'BOTTOM',
 SUPPORT = 'SUPPORT',
}</code></pre>
enum 으로 이렇게 쓰면 될 코드가
<pre><code>const LoLRiftPosition = {
 TOP: 'TOP',
 JUNGLE: 'JUNGLE',
 MIDDLE: 'MIDDLE',
 BOTTOM: 'BOTTOM',
 SUPPORT: 'SUPPORT',
} as const;

type LoLRiftPosition = typeof LoLRiftPosition[keyof typeof LoLRiftPosition];</code></pre>
이렇게 늘어난다. 게다가 어떻게 코드 재활용이 가능하도록 만드는 방법도 없어서 enum을 만들어야 할 때마다 이렇게 생긴 코드를 일일이 써줘야 한다.
단순히 "작성해야 하는 코드가 길어진다" 도 있지만, 선언하는 객체와 타입의 "이름"이 네임스페이스 내에서 완전히 같아야 한다는 조건이 붙는다. 즉 이름에 오타가 나면 제대로 작동을 안하며, 자동으로 작성되는것도 아니므로, 저렇게 enum을 만들고나서 오타는 없는지, 잘 작동은 하는지 꼭 확인해줘야 한다.
과연 위와 같은 길고 복잡한 "union string type" 방법으로 enum 을 대체하는게 내 프로덕트에 유의미한 차이를 줄 수 있을지 내 프로덕트의 상황을 생각해보자.
<h2 id="프론트엔드에서-사용할-코드인가">프론트엔드에서 사용할 코드인가?</h2>
enum 을 사용하지 말아야 한다는 내용의 이유는, 번들링된 코드의 용량이 기대하는것보다 조금 더 클 수 있다는 점이다. 프론트엔드용 자바스크립트는 브라우저의 페이지로드마다 브라우저가 자바스크립트 파일을 다운로드 받는다 (js파일이 캐싱되면 매번 다운로드받지 않아도 될 수도 있다는 부분은 일단 무시하자). js 파일을 다운로드 받는 시간이 짧아질수록 사용자 입장에서 최초 페이지 진입시 로딩 시간이 줄어드는 효과를 가지는 것이다.
하지만 nodejs 서버는 어떤가? nodejs 에서 번들링된 파일을 다운로드하고 읽어오는 시점은, nodejs 서버가 배포될 때 말곤 없다. 한번 켜진 nodejs 서버는 모든 js코드가 해당 서버의 메모리에 올라가 있고, 다시 자바스크립트 파일을 읽을 일이 없다.
그래도 파일 크기가 작아지면 배포속도가 빨라지는거 아닌가 하는 생각이 들 수도 있겠지만, 어짜피 빌드된 nodejs 이미지 크기는 수십~수백 메가바이트다. enum 이 수천 수만개쯤 있는 프로젝트면 모르겠는데, 보통 그렇진 않을테니 의미 없다.
그리고 놓치기 쉬운 또다른 부분은, 보통 nodejs 서버사이드 프로젝트를 번들링해서 쓰지 않는다는 점이다. ts-node나 tsc는 타입스크립트에 1:1 대응하는 자바스크립트와 소스맵을 뽑아줄 뿐, 애초에 트리쉐이킹을 해주지도 않는다. 열심히 트리쉐이킹 최적화를 해봤자 아무도 트리쉐이킹을 해주지 않는다는 슬픈 이야기...
<h2 id="만들어놓고-사용안하는-enum이-많은가">만들어놓고 사용안하는 enum이 많은가?</h2>
트리쉐이킹은, 만들어놓고 아무데에서도 쓰지 않는 변수를 찾아서 코드에서 아예 삭제해주는 기능이다. 그리고 enum 키워드를 통한 enum 은 그게 잘 안돼서 문제라는 거고.
바꿔서 말하면, 내가 enum을 작성한 다음, 그걸 어딘가에서 사용한다면, 그 enum은 내가 어떤 식으로 구현했는지 상관없이 애초에 트리쉐이킹 대상조차 아니라는 것이다.
삭제될 일이 없는 코드가 잘 삭제되도록 구현해야 한다니... 뭔가 이상하지 않은가?
<h2 id="3g-이하의-모바일-네트워크-환경-또는-저사양-휴대폰컴퓨터에서-사용하는-유저층을-고려해서-개발중인가">3G 이하의 모바일 네트워크 환경, 또는 저사양 휴대폰/컴퓨터에서 사용하는 유저층을 고려해서 개발중인가?</h2>
enum 트리쉐이킹으로 줄일수 있는 자바스크립트 파일의 크기는 그리 엄청난 수준이 아니다. 
내가 글의 앞부분에서 써두었던 enum 코드의 트랜스파일 결과물은 다음과 같다.
<pre><code>var LoLRiftPosition;
(function (LoLRiftPosition) {
 LoLRiftPosition["TOP"] = "TOP";
 LoLRiftPosition["JUNGLE"] = "JUNGLE";
 LoLRiftPosition["MIDDLE"] = "MIDDLE";
 LoLRiftPosition["BOTTOM"] = "BOTTOM";
 LoLRiftPosition["SUPPORT"] = "SUPPORT";
})(LoLRiftPosition || (LoLRiftPosition = {}));</code></pre>
아주 긴 코드로 변환되었다고 생각되겠지만, 303자 짜리 문자열이므로 대충 300바이트쯤 되는 것이다.
아무 사이트나 켜보고 개발자도구 네트워크 탭을 보자. 다운로드 되는 css/js 파일들, 작아봤자 보통 10Kb정도 된다. 리액트 번들 사이즈는 200Kb 짜리 여러개로 되어있는 경우도 흔할 것이다. 최적화 해봐야 실제로 지워질 일이 있을지 없을지 모르는 코드 0.3Kb 만큼을 줄이기 위해 이미 주어져 있는 문법을 거부하고 훨씬 더 불편한 방식으로 코드를 작성할 가치가 있는가?
어떤 회사 어떤 팀에서는 극한의 수준까지 퍼포먼스 최적화를 고려하며 개발을 하고 있을테고, 이 enum 트리쉐이킹 최적화 방법도 그중 한가지이다. 글의 도입부에서 소개했던 블로그는 라인 개발자가 쓴 글이다. 라인은 일본, 동남아를 포함한 아주 많은 국가에서 국민앱 취급을 받는 인기 앱이고, 당연히 그중에는 3G 이하의 저품질 네트워크에서 라인을 이용해야 하는 고객들도, 우리나라에서 7~8년 전쯤에나 썼을법한 저사양 스마트폰을 사용하는 고객들도 많을 거라고 생각된다. 국내 사용자를 타겟으로 하는 서비스보다, 라인은 미세한 퍼포먼스 차이에도 영향을 받는 사용자 수가 많을 것 이라고 어렵지 않게 유추해볼 수 있다. 그런 사용자들을 위해 라인의 프론트엔드/앱 개발자들은 정말 수많은 퍼포먼스 최적화 작업을 하고 있을테고, 타입스크립트의 enum을 쓰지 않는 건 그 수많은 최적화 방법중 하나 아닐까.
사실 모바일 환경 성능최적화중 가장 효과가 큰 부분은 enum을 쓰고 안쓰고의 문제보단, 이미지나 영상 관련된게 아닐까 생각된다. 사용자가 업로드하는 이미지를 비롯해서 수많은 이미지들을 업로드 직후 여러 해상도로 변환해서 저장하고, 사용자 환경이나 선택에 맞게 원본화질이 아닌 적당한 화질로 보여주고, 그조차도 lazy-loading 되게 처리하는 것 말이다.
물론 이미지 퍼포먼스 최적화는 말은 쉽지만 아주 힘든 작업이다. 프론트엔드 개발자 단독으로 진행하기도 어렵고 전사 차원에서 저사양 환경 사용자를 고려한 제품 개발을 위해 회사의 리소스가 추가적으로 소모될 것을 감수해야 한다. 라인 앱의 코드를 본 적은 없지만, 이미 그들은 이미지에 대한 최적화 작업도 해두었을거라고 조심스럽게 예상해본다. 적용했을 때 큰 효과를 보는 최적화들은 이미 처리하고, 아주 조금이라도 최적화 될 수 있는 모든 경우들을 찾아서 하나하나 적용해가다보니, 잘 사용하고 있던 언어의 특정 문법을 사용하지 않겠다고 결정하는 단계까지 온게 아닐까.
하지만 우리 대부분은 라인 개발자는 아니고, 우리가 다니고 있는 회사 우리가 속한 팀이 라인같은 곳은 아니다. 당장 개발해야 하는 기능이 쌓여있고, 나와 팀의 시간적, 금전적 리소스는 한정되어 있다. enum 대신 union type 을 쓴다는건 미세한 정적파일 크기 변화와, 저걸 작성해서 생기는 코드의 복잡성, 오타가능성 등의 개발리소스를 서로 맞바꾸겠다는 뜻이다.
브라우저가 받는 정적 파일 중 가장 비중이 큰건 이미지 파일, 폰트파일이며 이것만 잘 최적화되도록 해놔도 얻게 되는 퍼포먼스적 효과는 매우 크다. 업로드 되는 이미지에 대해 사이즈 변환 처리까진 아니더라도, 자주 사용되는 메인페이지 내 이미지에 대해 <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">srcset</a> 을 적용하고 고용량의 png 대신 jpg 나 <a href="https://developers.google.com/speed/webp/faq">webp</a>를 사용해 볼 수도 있다. 폰트의 글리프를 제한한 서브셋으로 빌드해 첨부하고, 웹폰트 파일이 ttf 나 eot 로만 되어있다면 woff로도 첨부하고 eot,ttf는 fallback 으로 사용하도록 설정하는 것도 효과가 크다. <a href="https://d2.naver.com/helloworld/4969726">#</a>
작은 최적화에 연연하기보다, 그것보다 훨씬 효과가 큰 일에 집중하자. 문법을 포기해가며 해야 하는 극한의 최적화는 내 프로젝트가 글로벌 서비스가 되었을 때 고민해도 늦지 않다.</div></div>

vraimentres.log

Joonseok Hu

타입스크립트에서 enum은 사용하지 않는게 좋다는 말이 있다. 실제로 근거가 있는 내용이며, (특정 조건에서) 의미가 있는 최적화라는 점에 동의한다.
TypeScript에서 enum을 사용하면 Tree-shaking이 되지 않습니다
https://engineering.linecorp.com/ko/blog/typescript-enum-tree-shaking/
하지만 이 내용은 한편으론 너무 과도하게 받아들여지는 부분이 있다고 생각된다.
enum 키워드 없이 enum 처럼 작동하는 변수를 만드는 방법은 사람이 수작업으로 작업해야 하는 코드의 양을 늘린다. 그렇지만 그에 비해 얻는 효과는 미미하거나 없을 수도 있다.
enum LoLRiftPosition {
  TOP = 'TOP',
  JUNGLE = 'JUNGLE',
  MIDDLE = 'MIDDLE',
  BOTTOM = 'BOTTOM',
  SUPPORT = 'SUPPORT',
}
enum 으로 이렇게 쓰면 될 코드가
const LoLRiftPosition = {
  TOP: 'TOP',
  JUNGLE: 'JUNGLE',
  MIDDLE: 'MIDDLE',
  BOTTOM: 'BOTTOM',
  SUPPORT: 'SUPPORT',
} as const;
type LoLRiftPosition = typeof LoLRiftPosition[keyof typeof LoLRiftPosition];
이렇게 늘어난다. 게다가 어떻게 코드 재활용이 가능하도록 만드는 방법도 없어서 enum을 만들어야 할 때마다 이렇게 생긴 코드를 일일이 써줘야 한다.
단순히 "작성해야 하는 코드가 길어진다" 도 있지만, 선언하는 객체와 타입의 "이름"이 네임스페이스 내에서 완전히 같아야 한다는 조건이 붙는다. 즉 이름에 오타가 나면 제대로 작동을 안하며, 자동으로 작성되는것도 아니므로, 저렇게 enum을 만들고나서 오타는 없는지, 잘 작동은 하는지 꼭 확인해줘야 한다.
과연 위와 같은 길고 복잡한 "union string type" 방법으로 enum 을 대체하는게 내 프로덕트에 유의미한 차이를 줄 수 있을지 내 프로덕트의 상황을 생각해보자.
프론트엔드에서 사용할 코드인가?
enum 을 사용하지 말아야 한다는 내용의 이유는, 번들링된 코드의 용량이 기대하는것보다 조금 더 클 수 있다는 점이다. 프론트엔드용 자바스크립트는 브라우저의 페이지로드마다 브라우저가 자바스크립트 파일을 다운로드 받는다 (js파일이 캐싱되면 매번 다운로드받지 않아도 될 수도 있다는 부분은 일단 무시하자). js 파일을 다운로드 받는 시간이 짧아질수록 사용자 입장에서 최초 페이지 진입시 로딩 시간이 줄어드는 효과를 가지는 것이다.
하지만 nodejs 서버는 어떤가? nodejs 에서 번들링된 파일을 다운로드하고 읽어오는 시점은, nodejs 서버가 배포될 때 말곤 없다. 한번 켜진 nodejs 서버는 모든 js코드가 해당 서버의 메모리에 올라가 있고, 다시 자바스크립트 파일을 읽을 일이 없다.
그래도 파일 크기가 작아지면 배포속도가 빨라지는거 아닌가 하는 생각이 들 수도 있겠지만, 어짜피 빌드된 nodejs 이미지 크기는 수십~수백 메가바이트다. enum 이 수천 수만개쯤 있는 프로젝트면 모르겠는데, 보통 그렇진 않을테니 의미 없다.
그리고 놓치기 쉬운 또다른 부분은, 보통 nodejs 서버사이드 프로젝트를 번들링해서 쓰지 않는다는 점이다. ts-node나 tsc는 타입스크립트에 1:1 대응하는 자바스크립트와 소스맵을 뽑아줄 뿐, 애초에 트리쉐이킹을 해주지도 않는다. 열심히 트리쉐이킹 최적화를 해봤자 아무도 트리쉐이킹을 해주지 않는다는 슬픈 이야기...
만들어놓고 사용안하는 enum이 많은가?
트리쉐이킹은, 만들어놓고 아무데에서도 쓰지 않는 변수를 찾아서 코드에서 아예 삭제해주는 기능이다. 그리고 enum 키워드를 통한 enum 은 그게 잘 안돼서 문제라는 거고.
바꿔서 말하면, 내가 enum을 작성한 다음, 그걸 어딘가에서 사용한다면, 그 enum은 내가 어떤 식으로 구현했는지 상관없이 애초에 트리쉐이킹 대상조차 아니라는 것이다.
삭제될 일이 없는 코드가 잘 삭제되도록 구현해야 한다니... 뭔가 이상하지 않은가?
3G 이하의 모바일 네트워크 환경, 또는 저사양 휴대폰/컴퓨터에서 사용하는 유저층을 고려해서 개발중인가?
enum 트리쉐이킹으로 줄일수 있는 자바스크립트 파일의 크기는 그리 엄청난 수준이 아니다.
내가 글의 앞부분에서 써두었던 enum 코드의 트랜스파일 결과물은 다음과 같다.
var LoLRiftPosition;
(function (LoLRiftPosition) {
    LoLRiftPosition["TOP"] = "TOP";
    LoLRiftPosition["JUNGLE"] = "JUNGLE";
    LoLRiftPosition["MIDDLE"] = "MIDDLE";
    LoLRiftPosition["BOTTOM"] = "BOTTOM";
    LoLRiftPosition["SUPPORT"] = "SUPPORT";
})(LoLRiftPosition || (LoLRiftPosition = {}));
아주 긴 코드로 변환되었다고 생각되겠지만, 303자 짜리 문자열이므로 대충 300바이트쯤 되는 것이다.
아무 사이트나 켜보고 개발자도구 네트워크 탭을 보자. 다운로드 되는 css/js 파일들, 작아봤자 보통 10Kb정도 된다. 리액트 번들 사이즈는 200Kb 짜리 여러개로 되어있는 경우도 흔할 것이다. 최적화 해봐야 실제로 지워질 일이 있을지 없을지 모르는 코드 0.3Kb 만큼을 줄이기 위해 이미 주어져 있는 문법을 거부하고 훨씬 더 불편한 방식으로 코드를 작성할 가치가 있는가?
어떤 회사 어떤 팀에서는 극한의 수준까지 퍼포먼스 최적화를 고려하며 개발을 하고 있을테고, 이 enum 트리쉐이킹 최적화 방법도 그중 한가지이다. 글의 도입부에서 소개했던 블로그는 라인 개발자가 쓴 글이다. 라인은 일본, 동남아를 포함한 아주 많은 국가에서 국민앱 취급을 받는 인기 앱이고, 당연히 그중에는 3G 이하의 저품질 네트워크에서 라인을 이용해야 하는 고객들도, 우리나라에서 7~8년 전쯤에나 썼을법한 저사양 스마트폰을 사용하는 고객들도 많을 거라고 생각된다. 국내 사용자를 타겟으로 하는 서비스보다, 라인은 미세한 퍼포먼스 차이에도 영향을 받는 사용자 수가 많을 것 이라고 어렵지 않게 유추해볼 수 있다. 그런 사용자들을 위해 라인의 프론트엔드/앱 개발자들은 정말 수많은 퍼포먼스 최적화 작업을 하고 있을테고, 타입스크립트의 enum을 쓰지 않는 건 그 수많은 최적화 방법중 하나 아닐까.
사실 모바일 환경 성능최적화중 가장 효과가 큰 부분은 enum을 쓰고 안쓰고의 문제보단, 이미지나 영상 관련된게 아닐까 생각된다. 사용자가 업로드하는 이미지를 비롯해서 수많은 이미지들을 업로드 직후 여러 해상도로 변환해서 저장하고, 사용자 환경이나 선택에 맞게 원본화질이 아닌 적당한 화질로 보여주고, 그조차도 lazy-loading 되게 처리하는 것 말이다.
물론 이미지 퍼포먼스 최적화는 말은 쉽지만 아주 힘든 작업이다. 프론트엔드 개발자 단독으로 진행하기도 어렵고 전사 차원에서 저사양 환경 사용자를 고려한 제품 개발을 위해 회사의 리소스가 추가적으로 소모될 것을 감수해야 한다. 라인 앱의 코드를 본 적은 없지만, 이미 그들은 이미지에 대한 최적화 작업도 해두었을거라고 조심스럽게 예상해본다. 적용했을 때 큰 효과를 보는 최적화들은 이미 처리하고, 아주 조금이라도 최적화 될 수 있는 모든 경우들을 찾아서 하나하나 적용해가다보니, 잘 사용하고 있던 언어의 특정 문법을 사용하지 않겠다고 결정하는 단계까지 온게 아닐까.
하지만 우리 대부분은 라인 개발자는 아니고, 우리가 다니고 있는 회사 우리가 속한 팀이 라인같은 곳은 아니다. 당장 개발해야 하는 기능이 쌓여있고, 나와 팀의 시간적, 금전적 리소스는 한정되어 있다. enum 대신 union type 을 쓴다는건 미세한 정적파일 크기 변화와, 저걸 작성해서 생기는 코드의 복잡성, 오타가능성 등의 개발리소스를 서로 맞바꾸겠다는 뜻이다.
브라우저가 받는 정적 파일 중 가장 비중이 큰건 이미지 파일, 폰트파일이며 이것만 잘 최적화되도록 해놔도 얻게 되는 퍼포먼스적 효과는 매우 크다. 업로드 되는 이미지에 대해 사이즈 변환 처리까진 아니더라도, 자주 사용되는 메인페이지 내 이미지에 대해 srcset 을 적용하고 고용량의 png 대신 jpg 나 webp를 사용해 볼 수도 있다. 폰트의 글리프를 제한한 서브셋으로 빌드해 첨부하고, 웹폰트 파일이 ttf 나 eot 로만 되어있다면 woff로도 첨부하고 eot,ttf는 fallback 으로 사용하도록 설정하는 것도 효과가 크다. #
작은 최적화에 연연하기보다, 그것보다 훨씬 효과가 큰 일에 집중하자. 문법을 포기해가며 해야 하는 극한의 최적화는 내 프로젝트가 글로벌 서비스가 되었을 때 고민해도 늦지 않다.

'타입스크립트 enum 을 사용하지 않는 방법' 을 사용하지 않는게 좋은 이유

댓글