blog.rhostem.com

[번역] 자바스크립트 프레임워크의 네 시대

rhostem — Fri, 27 May 2022 00:00:00 GMT

이 글은 Four Eras of JavaScript Frameworks를 번역한 글입니다.

개발자로 일하며 수많은 기술이 새로 등장하고 사라지는 모습을 반복적으로 보고 있으면 그런 변화와 자극에 조금씩 무심해지는 것 같습니다. 이 글은 지난 십수년간의 프론트엔드 웹 개발의 흐름을 되짚어보며 지금까지 어떤 일이 있었는지, 지금 어디에 와 있는지 진단하고 있습니다. 그런 거대한 흐름을 이해하고 나면 자신이 서 있는 위치와 함께 나 자신의 모습도 보이게 됩니다. 그리고 앞으로의 미래를 바라보며 내가 무엇을 할 수 있는지, 해야 할 일이 무엇인지 파악할 수 있게 되는 것 같습니다. 이래서 역사 공부가 필요한 것일까요? 🙂

나는 자바스크립트를 메인으로 한 개발을 지난 2012년에 시작했다. 나는 어떤 지역 사업체를 위한 웹사이트 개발에 초기부터 참여하여 PHP와 기본적인 CMS를 사용해 만들었다. 그리고 그 업체는 웹사이트를 리뉴얼하면서 많은 기능을 추가하기로 결정했다. 프로젝트 매니저는 나에게 개발에 .NET을 사용하길 원했다(왜냐하면 그가 잘 알고 있는 것이 .NET이었기 때문에). 하지만 페이지 새로고침도 없고, 액션 사이에 긴 딜레이도 없는 네이티브 어플리케이션처럼 보이길 바라기도 했다. 얼마간의 조사와 프로토타이핑 후, 나는 그가 원하는 것이 이제 막 나오기 시작한 최신의 자바스크립트 프레임워크로 웹에서 어플리케이션을 만드는 것과 같은 형태라고 확신했다.

내가 첫 번째로 선택한 프레임워크는 Angular 1이었다. 나는 FuelPHP 백엔드와 함께 클라이언트 사이드도 상당히 많은 부분을 작업했는데, 개발 중에 오픈소스로 공개된 라우터 라이브러리를 사용하던 도중 이슈에 부딪혔다. 그 라이브러리를 사용하면 서브라우트/outlet을 렌더링할 때마다 화면이 깜빡였는데, 그런 모습은 웹사이트를 처음 설계하면서 기대했던 것이 아니었다. 해결책을 찾던 중 누군가가 Ruby on Rails와 Ember 조합을 추천했는데, 한번 시도해보니 깜빡임 현상 없이 기대한 대로 무척 잘 동작했다. 나는 그 프레임워크의 철학, 커뮤니티가 모두 마음에 들었고, 당시의 다른 대안과 비교해봤을 때 전반적으로 매우 생산적인 개발이 가능했다.

그때 이후로 많은 것들이 변했다. 프레임워크들은 나타나고, 사라지고, 그리고 급격히 진화했다. 당신이 지금 자바스크립트로 브라우저에서 앱을 만드는 방식은 과거에는 어떤 주변 기술이었지만 지금은 표준 사례가 된 것이다. 그리고 우리가 사용하는 인프라는 완전히 바뀌어서 새로운 것들을 가능하게 해주고 있다.

당시에는 물론 그 방식에 대해 무척 많은 경쟁과 충돌이 있었다. 나는 프론트엔드 업계에 한동안 몸을 담아 온 대부분 사람이라면 다양한 논쟁에 참여했을 것이라 생각한다. 그 다양한 것들이란 아마도… 모든 것에 대해서다. 어떤 자바스크립트 프레임워크를 사용할 것인지, 어떻게 CSS를 작성할 것인지, 함수형 vs 객체 지향 프로그래밍, 어떻게 상태를 관리할 것인지, 어떤 빌드 시스템과 도구가 가장 유연하고 빠른 것인지 등등. 돌이켜 볼 때 우리가 얼마나 잘못된 것을 맞다고 주장하면서 더 큰 패턴을 놓치고 있었는지를 생각해보면 무척 웃기다. 물론 시간이 지나서 돌아보고 있으니 그렇게 생각할 수 있긴 하다.

그래서 나는 회고를 해 보려고 한다. 지난 몇십 년간의 자바스크립트 개발을 뒤돌아보고 우리가 어디까지 왔는지를. 지난 시간은 다음의 네 시대로 나눌 수 있을 것이다.

예전 시대
최초의 프레임워크
컴포넌트 중심 뷰 레이어
풀 스택 프레임워크(← 우리는 지금 여기)

각각의 시대는 메인 테마와 중심이 되는 대립이 있었다. 그리고 커뮤니티는 매번 중요한 것을 배웠고, 느리지만 확실히 진전해 나갔다.

오늘날 논쟁은 더 격해졌다: ‘웹은 너무 덩치가 커져 버렸나?’, ‘일반적인 웹사이트가 굳이 React로 작성될 필요가 있나?; 심지어 ‘우리는 자바스크립트를 사용해야 하나?’같은 것들이다. 나는 우리가 지금은 미래를 들여다볼 수 없지만 결국에는 다시 새로운 발견을 할 것이라 생각한다. 지금 우리는 서로 다른 이야기를 하면서 큰 그림을 놓치고 있다. 하지만 그런 과거로부터 얻은 작은 발견이 우리를 미래로 나아가게 만든다.

예전 시대 (The Before Times)

자바스크립트는 1995년 처음 릴리즈되었다. 위에서 언급했듯 나는 그로부터 20년이 지난 후인 2012년부터 자바스크립트를 사용하기 시작했고, 당시의 프레임워크에 대해 설명하려고 하고 있다. 나는 이 시대의 많은 역사에 대해서 설명하려 하겠지만, 당신이 상상할 수 있듯이 이 시대는 또 지배적으로 사용되었던 패턴과 라이브러리, 빌드 툴 등에 의해 여러 개의 하위 시대로 나뉠 수 있다.

다시 말해, 나는 내가 경험하지 않은 것들에 대해서는 얘기할 수 없다. 내가 프론트엔드 앱을 개발하기 시작한 시점에는 새로운 세대의 프레임워크들이 발전 중이었다: Angular.js, Ember.js, Backbone이 그것이었고, 이 외에도 여러 개가 있었다.

이들이 등장하기 전 첨단의 기술은 jQuery나 MooTools 같은 것이었다. 이 라이브러리들은 당시에는 무척 중요했는데, 브라우저마다 다르게 구현된 자바스크립트의 차이를 줄여주는 역할을 했기 때문이다. 예를 들어 Internet Explorer와 Netscape는 Event 구현에 완전히 다른 방식을 사용했는데, 한쪽은 이벤트 버블링이었고 다른 한쪽은 이벤트 캡쳐링을 사용했다. 그리고 그런 차이가 지금의 웹 표준이 두 방식을 모두 포함하고 있는 이유가 되었으나, 어쨌든 예전에는 두 브라우저에서 모두 동작하는 코드를 구현하려면 라이브러리를 사용해야 했다. 그 라이브러리들은 작고 독립적으로 동작하는 UI 위젯을 만드는 데 주로 사용되었다. 어플리케이션의 주된 비지니스 로직은 여전히 form과 HTTP 리퀘스트에 의해 이뤄졌고, HTML을 서버에서 렌더링하여 클라이언트에서 제공하는 방식을 사용했다.

그리고 이 시대에는 내가 아는 한 커뮤니티에서 언급되는 빌드 툴이 그렇게 많지 않았다. 자바스크립트는 아직 모듈을 가지고 있지 않았고(최소한 당시에는 표준이 아니었다), 코드를 import할 수 있는 방법도 없었다. 모든 것은 전역 공간에 존재했고, 코드를 정리하기도 쉽지 않았다.

이런 환경이었으니 자바스크립트가 장난감스러운 언어로 취급당해도 이해할 만 했다. 풀 어플리케이션을 작성하는데 사용할 만한 언어로 인식되지는 않았다. 자바스크립트로 가장 많이 하는 일은 몇 개의 UI 위젯 동작에 필요한 스크립트를 jQuery와 함께 불러온 후 호출하는 것이었다. 시간이 지나면서 XHR이 도입되었고 인기를 얻었으며, 사람들은 클라이언트와 백엔드 사이의 복잡한 플로우가 필요한 UI의 일부분을 싱글 페이지로 구현하기 시작했다. 하지만 앱의 중요한 부분은 여전히 서버에 견고히 유지되었다.

이런 모습은 모바일 앱이 시장을 강타하기 시작했을 때 큰 대비를 보여줬다. iOS와 Android 앱은 처음부터 Objective C와 Java라는 Serious Languages¹로 어플리케이션이 모두 구현되었기 때문이다. 게다가 완전히 API 기반이다. 모든 UI 로직은 디바이스 위에서 돌아가며, 서버와의 통신은 단순히 데이터 포맷만 전달하는 것으로 가능하다. 이는 더 나은 사용자 경험을 가능하게 했고, 모바일 앱의 인기는 폭발적으로 성장했다. 그리고 그 인기는 모바일 앱과 웹 앱 중에서 어느 것이 더 나은지 토론하고 있는 오늘날까지 이어지고 있다.

저런 작업을 전부 자바스크립트로 하는 건 처음에는 비웃음당할만한 일이었다. 하지만 시간이 지남에 따라 점점 더 많은 것들이 야심 차게 구현되어 나갔다. 소셜 네트워크는 채팅과 DM 등의 실시간 기능을 추가했고, Gmail과 Google Docs는 데스크탑 어플리케이션과 똑같은 기능을 브라우저에서 구현할 수 있다는 것을 보여줬다. 그리고 점점 더 많은 기업이 점점 더 많은 사용 사례를 웹 앱으로 구현하기 시작했다. 왜냐면 웹은 어디서든 동작하며 유지보수가 더 쉽기 때문이다. 이제 자바스크립트는 더 이상 사소한 앱을 만드는 언어가 아니라는 사실을 세상에 알리기 시작했다.

하지만 자바스크립트를 사용한 앱 개발은 여전히 어려운 일이긴 했다. 자바스크립트는 오늘날 그것이 가진 기능을 모두 가지고 있지 않았다. 앞서 말했듯 모듈이라는 개념이 없었으므로 모든 변수는 전역 공간에 있었고, NPM도 없었으므로 개발자는 외부 라이브러리를 직접 다운로드해서 프로젝트 소스코드에서 정적인 파일들이 있는 폴더에 옮겨둔 후 HTML 파일에 script 태그를 추가하여 불러와야 했다. 그리고 당시의 자바스크립트는 오늘날 갖고 있는 기능의 절반도 없었다. 앱의 대부분은 페이지마다 맞춤 형식으로 개발되었는데, 상태 관리와 렌더링 업데이트에 플러그인마다 다른 시스템을 사용하는 식이었다. 이런 이슈들을 해결하기 위해 최초의 프레임워크가 떠오르기 시작했다.

최초의 프레임워크

2000년대 말과 2010년대 초반 최초의 JS 프레임워크가 풀 클라이언트 어플리케이션 구현에 맞춰 설계되었고 등장하기 시작했다. 이 시대의 주목할 만한 프레임워크 중 일부분은 다음과 같았다.

물론 이 외에도 많은 프레임워크가 있다, 그리고 아마 어떤 면에서 더 큰 규모를 가진 것도 있었을 것이다. 이들은 상대적으로 인기가 좋았고 내가 프로토타이핑이나 개발에 직접 사용했기에 기억하는 것들이다.

그들은 미지의 영토에 발을 들여놓으려는 세대의 프레임워크들이었다. 달리 말하면, 그들이 하려는 것은 매우 야심적이고, 많은 사람이 결코 할 수 없을 것이라 생각했던 것이었다. 당시 단일 페이지(single-page) 자바스크립트는 근본적으로 나쁘다고 비방하는 사람들이 많았다. 그건 많은 면에서 사실이었다. 클라이언트 사이드 렌더링은 검색 엔진이 페이지를 쉽게 크롤링하지 못하도록 했고, 유저는 웹페이지가 페인팅을 시작하기 전까지 몇초 이상 기다려야 하기도 했다. 많은 앱이 웹 접근성에서 최악이었고, 심지어 브라우저에서 자바스크립트 기능을 꺼 버리면 아예 동작하지 않았다.

그러나, 우리는 자바스크립트만으로 앱을 만들었던 경험이 없었기에, 모두 단결하여, 어떤 방법이 최선일지에 대한 아이디어를 끊임없이 쏟아냈다. 대부분의 프레임워크는 다른 프레임워크에 기반한 변형품들이었다. 그래서 그들 대부분이 모델-뷰-something 패턴(Model-View-Controller, Model-View-Producer, Model-View-ViewModel, 기타 등등)의 반복이었다. 이들 중 무엇도 그 길었던 경주를 끝내지 못했다. 어떤 프레임워크도 특별히 직관적이지도 못했고, 사용하다 보면 순식간에 복잡해져 버리곤 했다.

또 이 시대는 자바스크립트를 컴파일하는 방법에 대한 제대로 된 실험이 시작된 시대이기도 하다. Node.js는 2009년에 릴리즈되었고, 이어서 2010년에 NPM이 패키지(서버 사이드)를 도입하면서 등장했다. CommonJS와 AMD는 JS 모듈을 어떻게 정의하는 것이 최선인지에 대해 경쟁했고, Grunt, Gulp, Broccoli 같은 빌드 툴은 모듈들을 어떻게 프로덕션 빌드에 묶어낼 것인지를 놓고 경쟁했다. 이들 대부분은 일반적인 태스크 러너 툴이었는데, 무엇이든 빌드할 수도 있었다. 그러다 보니 자연스럽게 웹 앱 안에 들어가는 요소인 자바스크립트, HTML, CSS/SASS/LESS, 그리고 이 외의 다양한 것들을 빌드하는 데 쓰이게 되었다.

우리는 이 시대에서 매우 중요하고 근본적인 교훈을 배웠다:

URL 기반의 라우팅은 필수적이다. 그것을 갖고 있지 않은 앱은 웹을 망가뜨린다. 이는 프레임워크의 시작부터 고려되어야 한다.
템플릿 언어로 HTML을 확장하는 것은 강력한 추상화 계층이다. 다소 투박하게 느껴질지는 몰라도, UI를 앱의 상태와 동기화시키는 것을 더 쉽게 만들어준다.
SPA에서 퍼포먼스를 높이는 것은 어렵다, 그리고 네이티브 앱에 없는 많은 제한 요소가 있다. 우리는 앱의 코드를 전부 네트워크에 실어서 전송해야 하는데, 그 전송을 가능한 빨리 끝내고 앱을 실행시켜야 한다. 반면 네이티브 앱은 이미 다운로드와 컴파일이 끝난 상태로 제공된다. 웹 앱을 시작하기 위한 그 일련의 과정들은 엄청난 작업이다.
자바스크립트는 언어로서 많은 이슈를 가지고 있었다. 그리고 개선되어야 할 부분이 정말로 많았다. 그걸 프레임워크가 혼자 할 수는 없다.
우리가 큰 규모의 앱을 구현하기 위해서는 정말로 더 좋은 빌드 툴, 모듈, 패키징이 필요했다.

전반적으로, 이 시대는 무척 생산적이었다. 여러 결점에도 불구하고 많은 경우에서 백엔드 API에서 클라이언트를 분리함에서 오는 이익이 앱의 사이즈에 비례해서 커졌고, 그에 따르는 사용자 경험이 뛰어났다. 만약 역사가 조금 달랐더라면, 이 시대가 계속되어 우리는 지금도 여전히 MV* 스타일을 가진 프레임워크를 계속 만나보고 있었을지도 모른다.

하지만 어디에선가 소행성이 하나 나타나 존재하는 패러다임을 완전히 깨부숴 버렸고, 일부 종의 멸종을 유발하며 우리를 다음 시대로 향하게 했다. 그 소행성의 이름은 React다.

컴포넌트 중심 뷰 레이어

나는 React가 컴포넌트를 발명했다고 생각하지 않는다. 하지만 솔직히 컴포넌트가 언제 처음 등장했는지는 확실히 잘 모르겠다. 최소한 닷넷의 XAML에 유사한 기술이 있었고, 웹 컴포넌트도 그 시기에 스펙 개발이 시작되고 있었다. 궁극적으로는 뭐가 처음이었는지는 상관없다. 어떤 아이디어가 등장하면, 모든 메이저 프레임워크는 그것을 재빠르게 수용한다.

컴포넌트는 모든 것이 잘되도록 만들었다. HTML을 확장하고, 전역에서 오랫동안 살아남는 상태 변수를 줄이고, 자바스크립트 비즈니스 로직이 템플릿에 확실히 연결되도록 했다(JSX, Handlebar 또는 Directives 들이 그렇게 만들었다). 컴포넌트 기반의 어플리케이션은 기존 방식에서 필요했던 추상화의 대부분을 제거했다. 그리고 코드의 라이프사이클을 현저히 단순하게 만들었다. 모든 것은 앱이 아닌 컴포넌트의 라이프사이클과 묶이게 되었고, 개발자로서는 구현 중에 고려해야 할 사항을 훨씬 적게 만들었다.

하지만, 그 시기에 또 다른 도약도 있었는데, 모든 기능을 갖춘 프레임워크가 아닌 “뷰 레이어” 프레임워크라는 말로 자신을 홍보하는 프레임워크들의 등장이었다. 그들은 프론트엔드 앱에 요구되는 모든 문제를 해결하기보다는, 오직 렌더링을 이슈를 해결하는 데 초점을 맞추고 있었다. 프론트엔드 앱의 다른 문제로는 API 통신, 상태 관리 등이 있는데 그것들은 사용자들에게 떠넘겨졌다. 이 시기의 유명한 프레임워크들은 다음과 같다.

그리고 이 외에도 많고 많은 프레임워크가 있다. 돌이켜보면 뷰 레이어에 초점을 맞춘 두 번째 세대의 프레임워크의 인기는 다음의 두 가지를 가능하게 만들었기 때문이라고 본다.

스쿠프(scope)를 엄청나게 줄여버렸다. 눈앞에 높인 모든 문제를 해결하려고 하는 대신, 프레임워크의 핵심은 렌더링에 집중하고 있다. 상태 관리 같은 다른 문제들에 대해선 개발 생태계 속에서 많은 아이디어와 방향이 탐구되었다. 그중에는 끔찍한 솔루션들도 무척 많았지만, 좋은 것들도 있어서 다음 세대가 최선의 아이디어를 선택할 수 있도록 길을 닦아 주었다.
프레임워크를 도입하기 쉽게 만들었다. 모노리스(monolith) 서버 사이드 앱에게 풀 프레임워크를 도입한다는 것은 사실 기존의 앱의 대부분을 새로 작성한다는 말과 같다. 하지만 React나 Vue같은 프레임워크는 서비스 중인 앱에도 중간에 도입해서 1개의 위젯이나 컴포넌트로부터 시작해서 기존의 코드를 점진적으로 마이그레이션 하는 것이 가능하다.

이 두 요소는 두 번째 시대의 프레임워크가 빠르게 성장하도록 하면서 첫 번째 시대가 저물도록 만들었다. 그리고 멀리서 보면 모든 것이 잘 들어맞고 논리적인 혁신을 이룬 것처럼 보인다. 하지만 저 시대를 지나는 중에는 때때로 꽤 좌절스러운 경험도 했었다.

우선 저 관점은 어떤 프레임워크를 업무에 도입할지, 또는 앱을 새로 만들어야 하는지 토론할 때 자주 만나는 것은 아니었다. 대신, “더 빠르다!” 라거나, “더 작다!”, 또는 “당신에게 필요한 모든 것!”이라는 문구를 더 자주 접하게 된다. 또 함수형 프로그래밍이냐-객체 지향 프로그래밍이냐에 대한 토론도 있었다. 그리고 공정하게 얘기하면 이것들은 모두 사실이긴 했다. 뷰 레이어 컴포넌트는 작고(처음에는) 그리고 빠르고(처음에는) 그리고 당신에게 필요한 모든 것이다(당신이 만약 다른 많은 것들을 스스로 한땀 한땀 구현한다면). 그리고 확실히 함수형 프로그래밍 패턴은 자바스크립트를 오염시킨 수많은 문제를 해결했다. 그리고 나는 평균적인 자바스크립트 코드의 품질이 그들 덕분에 좋아졌다고 생각한다.

하지만 현실은, 은제 탄환(silver bullet)따위는 없으며, 결코 있을 수 없다. 뷰 중심의 프레임워크들을 사용해도 여전히 앱은 비대해지고 복잡해진다. 상태는 여전히 관리하기 어렵고, 라우팅이나 SSR같은 근본적인 문제도 풀어야 할 문제다. 그리고 대부분의 사람은 마치 모든 것을 해결하려는 솔루션을 버리고 사용자에게 그 연습을 맡기는 프레임워크를 원하는 것 같았다. 내 경험상 이것은 새로운 제품이나 기능을 출시하려는 엔지니어링 조직에 보편적으로 존재하는 현상이다. 그리고 계획했던 그 모든 기능을 개발하는 데 시간을 충분히 투자하지 못하곤 한다.

하지만 한편으로는 기존의 첫 번째 시대 풀서비스 프레임워크도 이 문제를 제대로 풀지 못하고 있었다. 부분적으로, 이는 수많은 기술적 부채 때문이었다. 첫 번째 시대의 프레임워크는 ES6이 나오기 전, 모듈이 있기 전, Babel과 Webpack이 있기 전이었으며, 그리고 우리가 찾아낸 수많은 해법이 존재하기 전에 만들어졌었다. 그 기술들을 꾸준히 도입하며 프레임워크를 발전시키기는 것은 무척 어려운 일이다(나는 이전에 Ember 프레임워크의 코어 팀 멤버였기 때문에 이를 잘 알고 있다). 그리고 Angular 2가 그랬던 것처럼 프레임워크를 완전히 새로 개발하는 것은 커뮤니티 활동 모멘텀을 크게 낮춰버리는 일이기도 하다. 그러므로 자바스크립트 프레임워크 세계로 오는 개발자들은 바위가 있는 힘든 환경에 오는 것과 같았다. 생긴지 얼마 안 된 올인원(all-in-one) 솔루션을 선택하거나, 모든 것을 자유롭게 고르되 그 길이 최선이길 바라며 프레임워크의 절반을 DIY 해야 한다.

결과적으로(내 경험상 이런 일이 더 자주 일어났다) 이들 뷰 레이어와 함께 구성된 수제 프레임워크가 만들어지고, 그것들은 또 커지고, 복잡해지고, 작업하기가 매우 어렵게 되어버린다. 사람들이 SPA를 사용하면서 생기는 많은 문제는 파편화된 에코시스템이며, 그 문제는 SPA가 폭발적으로 성장하기 시작한 바로 그 시기에서 왔다. 나는 여전히 라우팅을 제대로 못 하거나 디테일을 챙기지 못하는 신규 웹사이트들을 자주 마주치곤 하는데, 그럴 때마다 큰 실망감을 느끼곤 한다.

내가 말했듯 이 시기는 무척 좌절스러웠지만, 결과적으로는 혁신적인 기술이 아주 많이 등장했다. 자바스크립트 생태계는 정말로 빠르게 성장했기에 이들 프레임워크는 그들에게 필요한 최선이 무엇인지 찾아냈다. 그리고 또 몇몇 핵심적인 변화가 일어났다.

Babel 같은 트랜스파일러의 사용이 일반화되어 언어를 현대화했다. 새로운 기능이 언어의 표준이 되기까지 몇 년을 기다리는 대신 오늘 당장 사용할 수 있게 되었다. 그리고 자바스크립트 언어 자체도 더 빠른 주기로 새로운 기능을 추가하기 시작했다.
ES 모듈이 표준화되어 마침내 현대적인 빌드 툴인 Rollup, Webpack, 그리고 Parcel 등이 개발될 수 있도록 했다. Import 기반의 번들링은 서서히 일반되었고, 이제 자바스크립트가 아닌 스타일시트, 이미지 파일 같은 자원들도 번들링이 가능하다. 설정이 단순해지면서 빌드 툴들은 전반적으로 더 가볍고, 더 빠른 성능을 보여준다.
점점 많은 API가 표준화되면서 Node와 웹 표준 사이의 차이가 조금씩이지만 확실히 줄어들었다. SSR은 실제로 가능성을 가지기 시작했고, 어떤 앱들은 이미 사용하고 있었다. 하지만 여전히 매번 앱마다 맞춤 설정이 필요했다.
엣지 컴퓨팅이 공개되었고, 자바스크립트 기반의 서버 앱에 배포/응답 시간 측면에서 SPA에 있는 장점을 제공해줬다(SPA는 일반적으로 사용자로부터 가까이 있는 CDN에 있는 정적인 파일들 덕분에 로딩 시작을 빨리할 수 있었다. 비록 종단의 디바이스에서는 그 로딩이 완전히 끝나 렌더링이 되기까지 조금 더 오래 걸린다고 하더라도).

이 시대의 끝에, 일부 문제는 여전히 남아 있었다. 예전보다는 더 좋은 패턴을 찾아냈음에도 상태 관리와 반응성은 여전히 어려운 문제였다(그리고 지금도 그렇다). 퍼포먼스는 여전히 어려운 문제다. 상황은 조금씩 나아지고 있긴 하지만 여전히 헤아릴 수 없이 많은 수의 비대한 SPA가 웹에 존재한다. 그리고 웹 접근성 상황은 개선되었지만, 기술 조직에서는 여전히 사후 고려 대상이었다(그리고 지금도). 하지만 이러한 변화들이 다음 시대의 프레임워크를 위한 길을 닦았으며, 이제 그들에 대해 이야기하려고 한다.

풀-스택 프레임워크

개인적으로는 프레임워크의 마지막 시대에서 무척 슬픈 감정을 느꼈다. 그건 내가 지난 4년 동안 Ember의 렌더링 레이어에 매우 깊이 참여하며 앞서 말한 첫 번째 시대의 프레임워크들이 가진 기술 부채들을 해결하려 노력하면서 시간을 보냈기 때문이라고 생각한다. 그리고 3번째 세대의 모든 프레임워크들은 훨씬 더 교묘하게, 이전 세대의 뷰 레이어 프레임워크를 기반으로 만들어졌기 때문이기도 하다. 주목할 만한 것들은 다음과 같다.

Next.js (React)
Nuxt.js (Vue)
Remix (React)
SvelteKit (Svelte)
Gatsby (React)
Astro (Any)

이들 프레임워크는 뷰 레이어의 고도화에서부터 시작했다. 이제 우리는 모두 뷰 레이어 컴포넌트는 프레임워크의 상위에 올라가는 핵심 요소이며, 앱의 다른 부분인 라우터, 빌드 시스템, 폴더 구조 등의 표준화를 시작하는 것이 합리적인 것이라고 동의한다. 느리지만 확실히, 이 메타-프레임워크들은 첫 번째 세대가 제안했던 즉시 사용할 수 있는 올인원 솔루션을 만들기 시작했다. 필요한 기능들은 오픈소스 생태계에서 최선의 패턴을 골라내어 충분히 성숙한 상태에 있다면 프레임워크에 통합하고 있다.

그러고 나서 그들은 한 발짝 더 나아갔다.

지금 시점까진 SPA는 전적으로 클라이언트에 포커스를 맞추고 있었다. SSR은 모든 프레임워크가 간절히 해결하길 바랐으나, 궁극적으로는 서버에서 렌더링 된 HTML을 메가바이트 단위의 자바스크립트 로딩이 완료된 후 교체하기 위한 최적화 수단이었다. 1세대 프레임워크 중 오직 하나, Meteor.js만이 더 크게 생각했었지만 그들의 아이디어인 동형(isomorphic) JS는 결코 뜨지 못했다.

하지만 그 아이디어는 앱의 사이즈와 복잡도가 커지면서 다시 주목받았다. 우리는 그것이 백엔드와 프론트엔드가 함께할 때 정말 유용하다는 것을 알아차렸다. 그렇게 하면 어떤 리퀘스트에 사용할 API 시크릿을 숨기거나, 페이지를 리턴할 때 헤더를 수정하거나, API 리퀘스트 프록시를 구성하는 것 같은 일이 가능하다. 그리고 Node와 Deno가 점점 더 많은 웹 표준을 구현하고, 서버 사이드 JS와 클라이언트 사이드 JS의 간격이 매년 줄어들면서, 이제는 동형 JS가 그렇게 미친 아이디어는 아니었다고 여겨지기 시작한 것 같다. 이것과 엣지 컴퓨팅, 그리고 멋진 도구들을 함께 조합하면 당신은 놀랄 만한 가능성을 얻게 된다.

이 마지막 세대의 프레임워크들은 그 가능성을 전부 활용하여 클라이언트와 서버를 끊어짐 없이 연결하는데, 나는 이것이 얼마나 놀라운지 말로 표현할 수가 없다. 내가 지난 9개월간 SvelteKit을 사용하며 작업을 했었는데, 몇 번이나 “이게 바로 우리가 해야 했던 방식이야”라고 중얼거리며 의자에 등을 기댔는지 셀 수가 없을 정도다.

다음은 최근 내가 믿을 수 없을 정도로 쉽게 했던 작업의 일부다.

어플리케이션에 서버 사이드 OAuth 인증을 추가해서 인증 토큰이 결코 서버 밖으로 나가지 않도록 했다. 우리의 API에 리퀘스트를 보낼 때마다 헤더에 토큰을 추가해주는 API 프록시도 함께 구성했다.
프록시를 사용해 앱의 특정 라우트를 우리의 CDN으로 연결되도록 하여, 어떤 프레임워크에서 만들어진 HTML 페이지든 호스팅이 가능하도록 했다. 이를 통해 유저들이 그들의 커스텀 페이지를 만들 수 있었다(우리의 고객 중 일부에게 제공되는 서비스).
시크릿 키가 필요한 외부 서비스가 필요할 때 여러 가지 1회용 API 라우트를 추가했다(우리의 API에 완전히 새로운 라우트를 추가할 필요가 없고 백엔드 개발자들과 조율할 필요도 없다).
LaunchDarkly가 사용되는 곳을 서버 사이드로 옮김으로써 더 적은 자바스크립트를 로드하여 전체적인 비용을 줄였다.
백엔드 라우트에 Sentry 리퀘스트를 위한 프록시를 추가하여 광고 차단 확장 프로그램 때문에 기록되지 않는 에러를 확인할 수 있다.

이는 빙산의 일각일 뿐이다. 이 모델에서 할 수 있는 멋진 일들은 이 외에도 아주 많이 있다. 가장 큰 일 중 하나는 점진적 향상(progressive enhancement)에 어떻게 다시 활력을 불어넣느냐다. 서버와 클라이언트가 결합한 특징을 사용하여 클라이언트 디바이스에 자바스크립트가 비활성화되었을 때 완전한 앱 대신 기본적인 HTML과 HTTP를 제공받을 수 있게 할 수 있다. 내가 SPA를 사용하기 시작했을 때, SPA가 클라이언트 개발의 미래라 생각했었기에 점진적 향상의 구현을 완전히 포기했었다. 하지만 이제 그것이 다시 돌아오기 시작한 모습을 보고 있으니 너무나 기쁘다.

지금까지 말한 내용이 이 프레임워크들을 새로운 세대로 분류하게 만든(어디까지나 실험적인 분류다) 새로운 모습들이다. 이전에는 해결이 어렵거나 불가능했던 문제들은 이제 응답 처리 로직을 조금 바꿈으로서 처리되는 사소한 문제가 되었다. 확실한 성능과 UX는 이제 별도의 설정 없이 즉시 사용하다. 새로운 서비스를 구성하고 만드는 대신 별도의 엔드포인트를 추가하거나 미들웨어를 필요한 만큼 추가할 수 있게 되었다. 그냥, 삶이 달라졌다.

나는 이 세대가 1세대 프레임워크, 2세대 프레임워크, 그리고 유저들 사이에 있는 주요 긴장 지점도 해결했다고 생각했다. 무설정(zero-config) 방식으로 옮겨가는 데서 시작했지만, 나는 그것이 궁극적으로는 2세대 프레임워크를 발전시키고 안정화하려고 노력한 오픈소스 생태계가 이끌었다고 생각한다. 그것은 문화적인 변화였다. 세 번째 세대의 프레임워크는 렌더링만이 아닌 프론트엔드 개발에서 우리가 해결해야 하는 모든 근본적인 문제를 해결하려고 하면서 이제 다시 첫 번째 세대 같은 올인원 솔루션이 되려 하고 있다.

지금 커뮤니티들은 어느 때보다 일치단결하여 SPA가 유발한 많은 문제를 해결하려고 노력하는 것처럼 보인다. 그리고 중요한 사실은, 함께 해결하고 있다는 것이다.

다음은 어디로 갈까?

전반적으로 자바스크립트 커뮤니티는 올바른 방향으로 가고 있다고 생각한다. 마침내 우리는 “오직 뷰 레이어”만이 아닌 풀 어플리케이션을 처음부터 만들어낼 수 있는 성숙한 솔루션을 개발하고 있다. 마침내 우리는 모든 도구가 처음부터 바로 제공되는 네이티브 앱의 SDK와 같은 필드에서 경쟁할 수 있게 되었다. 하지만 여전히 해야 할 일들은 많이 남아있다. SPA에서 웹 접근성은 언제나 뒷전이었다. 그리고 나는 여전히 GraphQL 외부에서 데이터 스토리가 일부 작업을 사용할 수 있을 것으로 생각한다(그걸 좋아하든 아니든, 대부분의 웹은 REST에서 동작한다). 어쨌든 지금의 흐름은 올바르다. 만약 우리가 계속 서로의 솔루션을 공유하는 방향으로 나아간다면 어느 때보다 좋은 방법으로 이 문제들을 해결할 수 있으리라 생각한다.

나는 이 발전 패턴이 더 위쪽으로, 즉 웹 플랫폼 그 자체에 적용되었을 때의 잠재성에 대해서도 무척 기대하고 있다. 웹 컴포넌트는 조용하지만, 여전히 진행되고 있고, SSR과 전역 등록 이슈 해결을 위한 작업이 진행 중이다. 그 스펙은 3세대 프레임워크들과 더 높은 호환성을 가지게 해 줄 것이다. 한편, 웹 어셈블리도 이 발전 패턴을 적용하여 놀라운 결과를 낳도록 만들 수도 있다. 어떤 언어로도 작성할 수 있는 풀-스택 프레임워크를 상상해보라. 동형 러스트, 동형 파이썬, 동형 스위프트, 동형 자바 등등은 마침내 프론트엔드와 백엔드 사이의 장벽을 시스템 끝부분에 아주 조금의 HTML 템플릿만 남겨두고 거의 사라지도록 만들어 버릴 수도 있다(역설적으로 그것은 우리에게 ‘완전함’과 더 나은 UX를 가져다준다).

지금 나에게 미래에 대한 희망이 커 보이는 이유는 우리가 파편화의 시대를 지나왔다는 사실 때문이다. 매일 매일 새로운 자바스크립트 프레임워크가 등장하는 시대는 이제 지났다. 자유와 유연성은 혁신을 낳았지만, 그것들은 지저분하고, 끊어져 있고, 종종 근본적으로 망가진 웹 경험을 낳기도 했다. 개발자들이 한정된 자원과 빡빡한 일정 속에서 수십 가지 옵션들 중에서 고른 도구들을 직접 조립해야 했으니 그럴 만도 했다. 그 결과 어떤 앱들은 놀라울 정도로 빠르고, 안정적이고, 신뢰할 수 있고 사용하기 즐겁지만, 반면 어떤 다른 앱들은 불편하고, 어렵고, 느리고, 망가져 있었다.

우리는 “처음부터 올바른 일을 해주는” 도구를 사용함으로써 개발이 더 쉬워지게 만들 수 있다. 그러면 어쩌면 웹사이트의 평균적인 품질이 조금 더 좋아질 수 있고, 평균적인 웹 경험이 더 부드러워 질 수 있다. 좋은 도구가 모든 사이트를 좋게 만들지는 못한다. 코드의 양은 나쁜 UX에 대한 해결책이 될 수 없다. 하지만 같은 기반을 제공함으로써 모든 사이트는 조금 더 나은 상태에서 시작하게 될 것이다. 그리고 모든 개발은 보다 더 중요한 일에 집중할 수 있게 될 것이다.

C 언어처럼 다양한 형태의 소프트웨어를 구현하는데 사용할 수 있는 언어. Serious란 단순히 ‘작업량이 많다’는 것을 의미한다. 같은 내용을 구현하는데 스크립팅 언어는 더 짧은 시간 안에 작성 가능하다. 기계어는 궁극의 ‘serious’ 언어라고 할 수 있다. 출처 - https://wiki.c2.com/?SeriousVersusScriptingLanguages
↩

React hook 테스트 코드에서 Recoil snapshot 참조하기

rhostem — Sun, 13 Mar 2022 00:00:00 GMT

React의 커스텀 훅 함수를 테스트하다가 아래와 같은 상황을 만나게 되었다.

커스텀 훅 C는 Recoil 상태를 업데이트하는 로직을 가지고 있다.
Recoil 상태 A는 커스텀 훅 함수 안에서 업데이트되고, 리턴된다.
Recoil 상태 B는 커스텀 훅 함수 안에서 업데이트되지만, 리턴은 되지 않는다. 즉 커스텀 훅 C를 통해서는 상태 B에 접근할 수 없다.
테스트 코드에서 커스텀 훅 C에 의한 상태 A의 변경은 물론, 상태 B의 변경도 확인하려고 한다.

구체적인 예를 들자면 이미지 목록과 선택된 이미지를 관리하는 상태가 있다고 가정한다. 커스텀 훅에서는 이미지 목록을 백엔드 서버로부터 가져온 후 목록 상태를 업데이트하고, 선택된 이미지는 초기화하는 로직을 가진다.

import { atom } from 'recoil';

// 이미지 목록
export const imageListState = atom<string[]>({
  key: 'imageListState',
  default: [],
});

// 선택된 이미지
export const selectedImageState = atom<string | null>({
  key: 'selectedImageState',
  default: null,
});

function useImageList() {
  const [images, setImages] = useRecoilState(imageListState);
  const setSelectedImage = useSetRecoilState(selectedImageState);

  useEffect(() => {
    try {
      axios.get('https://test.api.com/images').then(({ data }) => {
        setImages(data); // 이미지 목록 상태 업데이트 
        setSelectedImage(null); // 선택된 이미지 초기화
      });
    } catch (error) {
      console.error(error);
    }
  }, [setImages, setSelectedImage]);

  return {
    images,
  };
}

그러면 위의 훅 함수로 이미지를 가져온 후 상태 업데이트를 확인하는 테스트 코드는 아래와 같이 작성할 수 있다. 네트워크 리퀘스트의 mocking에는 msw를 사용하고, 커스텀 훅의 실행에는 @testing-library/react-hooks를 사용한다.

describe('useImageList', () => {
  beforeAll(() => {
    mockServer.listen(); // start msw server
  });

	afterEach(() => {
	  mockServer.resetHandlers(); // reset msw server
	});

  afterAll(() => {
    mockServer.close(); // close msw server
  });

  test('이미지 목록 fetch 후 선택된 이미지는 초기화된다.', async () => {
    mockServer.use(
      rest.get('https://test.api.com/images', (req, res, ctx) =>
        res(
          ctx.json([
            'https://cdn.images.com/collectionA/1.png',
            'https://cdn.images.com/collectionA/2.png',
          ]),
        ),
      ),
    );

    const { result } = renderHook(() => useTest(), {
      wrapper: ({ children }) => <RecoilRoot>{children}</RecoilRoot>,
    });

    await waitFor(() => {
      expect(result.current.images.length).toBe(2);

      // TODO: 그런데, selectedImageState의 확인은 어떻게?
    });
  });
});

이 테스트 코드로는 이미지를 가져오는 것은 확인할 수 있지만, selectedImageState 상태가 null 값으로 바뀌었는지는 확인할 수 없다. useImageList 훅이 그 상태 값을 리턴하지 않기 때문이다.

그럼 필요한 값을 훅에서 리턴하면 간단하지 않은가?라고 생각할 수 있다. 하지만 그 말은 실제로는 사용하지 않으면서 오직 테스트를 위해 Recoil 상태를 구독해야 한다는 의미가 된다.

function useImageList() {
	const selectedImage = useRecoilValue(selectedImageState);

	return {
	  selectedImage
	}
}

그리고 커스텀 훅을 목적에 따라 분리해서 개발하다 보면 어떤 상태 관리 도구를 쓰든 특정 상태를 여러 커스텀 훅에서 업데이트하게 되는 상황이 종종 생긴다. 그럴 때마다 테스트를 위해 위와 같은 코드를 추가해야 할까? useSelectedImage라는 목적이 분명한 커스텀 훅이 있는데도?

이 문제는 통합 테스트(Integration test)를 통해 자연스럽게 해결할 수도 있다. 테스트 코드에서 커스텀 훅을 사용하는 컴포넌트를 직접 렌더링 하여 서버에서 불러온 이미지 목록이 표시되고, 기존에 선택된 이미지는 해제되는지 확인하는 것이다. 하지만 통합 테스트는 리소스가 많이 사용되어 유닛 테스트보다 느리고, 유지 보수에 따른 디버깅이 더 어렵다는 단점이 있다. 예를 들어 이미지 목록 컴포넌트가 수정된다면 통합 테스트에서 이미지를 찾는데 사용하는 쿼리도 수정해야 할 가능성이 생기기 때문이다. 그리고 만약 유닛 테스트가 잘 작성되어 있다면 상태 관리 로직에 오류가 있는 것인지, 단순히 마크업이 변경되어서 생기는 테스트 실패인지 쉽게 파악할 수 있다.

Recoil 상태를 엿보기 위한 컴포넌트 구현

커스텀 훅 함수에서 리턴하지 않는 Recoil 상태를 확인하기 위해서는 다른 방법이 필요하다. 필요한 요구사항은 다음과 같다.

renderHook 함수가 호출된 스쿠프에서 선언된 변수에 커스텀 훅에 의한 상태 변경을 반영하는 Recoil snapshot이 할당되어야 한다.

Recoil 상태의 구독은 useRecoilSnapshot 훅을 사용해서 가능하다. Snapshot을 사용하면 RecoilRoot 컴포넌트 안에서 사용하는 모든 Recoil 상태에 접근이 가능하다.

function useSnapshot() {
  const snapshot = useRecoilSnapshot();
  console.log(snapshot.getLoadable(selectedImageState).contents)
}

renderHook 의 wrapper 옵션에서 사용할 수 있도록 PeekSnapshot 컴포넌트를 구현했다.

export type SnapshotPeekRef = {
  current?: {
    snapshot: Snapshot;
    get: (state: RecoilValue<any>) => any;
  };
};

export const PeekSnapshot: React.FC<{ peekRef: SnapshotPeekRef }> = ({
  peekRef,
}) => {
  const snapshot = useRecoilSnapshot();

  peekRef.current = {
    snapshot,
    get: (state: RecoilValue<any>) => snapshot.getLoadable(state).contents,
  };
  return null;
};

PeekSnapshot 컴포넌트의 peekRef props는 SnapshotPeekRef 타입의 객체다. 컴포넌트 안에서 Snapshot을 구독한 후 peekRef props의 current 필드에 필요한 기능을 할당한다.

사실 컴포넌트 내부에서 props 객체를 조작하는 것은 React의 안티 패턴이긴 하다. React는 위에서 아래로의 단방향 데이터 흐름을 가지며, 2-way 바인딩을 가능하게 하는 API가 없다. 하지만 저런 방식이 아니면 테스트 코드에서 전달한 props 객체에 Snapshot을 전달할 방법을 찾기가 어렵다. 그리고 Snapshot 구독만 하기 때문에 다른 컴포넌트에 영향을 주지 않으므로 상관없다.

이제 PeekSnapshot 컴포넌트를 활용하여 Recoil 상태를 확인할 수 있다.

// 이 객체를 PeekSnapshot의 props로 보낸다.
const peekRef: SnapshotPeekRef = {}; 

const { result } = renderHook(() => useImageList(), {
  wrapper: ({ children }) => (
    <RecoilRoot
			initializeState={({ set }) => {
        // 확인할 Recoil 상태의 초기값을 설정한다.
        set(selectedImageState, 'https://cdn.images.com/another.png');
      }}
		>
      {children}

			{/* Snapshot을 구독할 것이므로 RecoilRoot 아래에 추가해야 한다 */}
      <PeekSnapshot peekRef={peekRef}></PeekSnapshot>;
    </RecoilRoot>
  ),
});

await waitFor(() => 
	expect(result.current.images.length).toBe(2);

	// peekRef 객체를 통해 Recoil 상태가 null로 초기화 되었는지 확인한다.
	peekRef.current?.get(selectedImageState).toBeNull()
});

컴포넌트의 props를 조작하면 어떤 문제가 생기는가?

문제는 해결되었지만 생각해 볼 만한 주제가 있다. 부모 컴포넌트의 props를 수정했을 때 어떤 문제가 생길까?

props로 객체가 아닌 리터럴 데이터를 전달했다면 props를 조작해도 상위 컴포넌트에 영향을 미칠 수 없다. 자바스크립트에서 함수를 호출할 때 파라미터에 리터럴 값을 사용하면 변수의 값 자체가 전달될 뿐 변수의 레퍼런스가 전달되는 것이 아니기 때문이다.

test('call with value does not modify original', () => {
  let original = 1;

  function resetter(target) {
    target = 2;
  }

  resetter(original);

  // 함수 안에서 파라미터를 덮어썼지만 original 값은 변하지 않았다.
  expect(original).toEqual(1);
});

하지만 파라미터로 객체를 넘긴다면 이야기가 다르다. 파라미터로 객체를 사용하면 값이 아닌 객체를 할당한 변수의 레퍼런스가 전달되고, 함수 안에서 그 객체의 필드를 수정하면 상위 스쿠프의 변수에 영향을 미치게 된다.

test('call with reference modifies original', () => {
  let original = {
    value: 1,
  };

  function mutator(target) {
    target.value = 2;
  }

  mutator(original);

  // 함수 호출에 의해 객체의 필드가 수정되었다.
  expect(original.value).toBe(2);
});

예를 들어 부모 컴포넌트에서 상태 객체 A의 필드 value를 렌더링에 사용하고 있는데, 자식 컴포넌트에서 그 객체를 props로 받은 후 value 필드를 다른 값으로 수정해서 렌더링에 사용했다고 가정하자. 부모와 자식 모두 각은 객체의 같은 필드를 사용해서 렌더링 했는데, 화면에는 다른 값이 표시되는 상황이 벌어진다. React는 2-way 바인딩을 지원하지 않으며, 객체의 조작(mutation)은 리렌더링을 유발하지 않기 때문이다.

만약 부모의 상태 객체를 자식 컴포넌트에서 수정하고 싶다면 업데이터 함수를 작성한 후 그것도 자식 컴포넌트에 props로 전달해야 한다.

const Parent = () => {
  const [original, setOriginal] = useState({ value: 1 })

  const updateOriginal = useCallback(
    (next) => {
      setOriginal(next)
    },
    [],
  )

  return (
    <div>
      value is {original.value}
      <Child original={original} onUpdateOriginal={updateOriginal}></Child>
    </div>
  );
};

2-way 바인딩을 지원한다면 저런 추가적인 함수와 props가 필요 없어진다. 그리고 앱에서는 컴포넌트를 무식하게 큰 덩어리로 작성하지 않는 이상 부모 상태를 하위에서 수정해야 하는 케이스는 언제나 발생한다. 그러다 보면 자연스럽게 유연한 상태 관리를 위해 Redux, Mobx, Recoil 같은 라이브러리를 도입하게 된다.

단방향 데이터 흐름은 데이터의 소유, 관리 주체를 확실히 구분하게 된다는 장점은 있지만 코드에서 해야 할 말이 더 많아진다는 단점도 가지고 있다.

References

Canvas, Web Audio API를 사용한 웹 오디오 플레이어 제작기

rhostem — Sat, 08 Jan 2022 00:00:00 GMT

제작 동기 및 요구사항

오디오 파형(waveform)은 오디오, 영상 편집 툴 및 일부 오디오 플레이어에서 접할 수 있다. 업무에서 개발한 앱에서 오디오 재생 기능이 필요하여 wavesurfer.js를 사용하고 있었다. 그런데 Safari 브라우저에서 알 수 없는 버그로 인해 기능을 하지 않았고, 커스터마이징 지원을 위해 플러그인과 API 사용이 다소 복잡하다는 불편함을 느끼고 있었다. 그래서 새로운 서비스 개발을 시작할 때 기술적 도전도 할 겸 최소한의 기능을 가진 오디오 플레이어를 만들어 보기로 했다. 오디오 플레이어에 필요한 요구사항은 다음과 같다.

오디오 파일에서 만든 데이터를 기반으로 파형을 제공한다.
파형 하단에는 재생 시간을 파악할 수 있는 타임라인이 표시된다.
재생 중에는 파형 위에 현재 재생 위치를 나타내는 수직선이 표시된다.
오디오 재생, 멈춤, 탐색이 가능하다.
오디오 탐색을 위한 슬라이더 바를 제공한다.
오디오 파형 위를 클릭하면 해당하는 위치로 현재 재생 시간이 업데이트된다.
오디오 파형은 확대, 축소가 가능하다.
파형 위를 클릭 후 드래그하여 반복 재생 구간 설정이 가능하다.

확대, 축소 및 반복구간 설정은 부가 기능이라 서비스에 따라 필요하지 않을 수도 있다. 그것을 제외한 나머지가 오디오 플레이어로서의 최소 기능이라고 할 수 있다. 이런 요구사항에 기반한 오디오 플레이어를 아래 그림과 같은 형태로 개발했다.

소리의 디지털화에 대한 이야기

소리라는 것은 공기의 진동이다. 진동은 그래프로 표현이 가능하며 Y 축은 진폭으로 소리의 세기를 나타낼 수 있고 X축은 시간을 나타낸다. 그래프가 Y축 0에서 출발하여 +, -피크에 도달한 후 다시 0으로 돌아왔을 때 이를 한 파장(period)라고 하는데, 이 주기가 짧을수록 높은 소리, 길수록 낮은 소리가 된다. 1초에 1번의 파장이 발생했다면 그 소리는 1Hz(헤르츠)의 소리가 된다. 현재 국제적으로 표준 음높이로 쓰는 “라” 음은 440Hz로 1초에 440번 진동하는 소리다.

디지털 오디오는 이 그래프를 수치화한 것이다. 연속적인 값을 분산된 숫자로 저장하기 위해 1초당 몇개의 값을 기록(=샘플링)할 것인지 정해야 하는데, 그 값을 샘플링 레이트(Sampling rate)라고 한다. 인간의 가청 주파수는 대략 20Hz부터 20000hz(=20kHz)인데, 이에 기반해 사람이 자연스러운 소리로 인식할 수 있는 최소 샘플링 레이트가 40kHz라는 것을 계산해 내서 오디오 기술에 적용하고 있다. 현재 디지털 오디오에 사용하고 있는 샘플링 레이트로 44.1kHz(Compact Disc가 사용하는 수치), 48kHz, 88.2kHz, 192kHz 등이 있다.

Web Audio API를 사용한 샘플링 데이터 추출

Web Audio API는 디지털 오디오 소스로부터 샘플링된 값들을 가져오는 API를 제공한다. 오디오 파일로부터 샘플링 데이터를 가져오는 과정은 아래처럼 작성할 수 있다.

const response = await fetch('https://cdn.data.com/audio.mp3');
const arrayBuffer = await response.arrayBuffer();

const audioCtx = new AudioContext()
const audioBuffer = await audioCtx.decodeAudioData(arrayBuffer);
const rawData = audioBuffer.getChannelData(0)

AudioContext는 디지털 오디오 처리를 위한 인터페이스로서 한번 생성해서 여러 개의 오디오 소스 처리에 활용할 수 있다.

decodeAudioData는 AudioContext의 부모 인터페이스인 BaseAudioContext에 있는 메소드로서 ArrayBuffer에 저장된 오디오 파일을 디코딩하여 AudioBuffer 데이터를 만든다.

AudioBuffer의 getChannelData 메소드를 사용하면 PCM 데이터를 얻을 수 있다. 배열에는 -1(=그래프 Y축의 음수 피크)부터 1(양수 피크) 사이의 32비트 실수가 들어 있고, 오디오의 길이(초 단위)에 샘플링 레이트를 곱한 수만큼의 값이 들어 있다. 예를 들어 샘플링 레이트가 48000인 오디오의 길이가 20초일 때, 샘플링된 데이터는 총 960,000개가 된다. 위의 코드에서 rawData 값을 콘솔에 출력해 보면 아래와 같은 값들이 나온다.

[
  -0.000030517578125,
  -0.000030517578125,
  -0.000030517578125,
  -0.000030517578125,
  0.000030518509447574615,
  0.00006103701889514923,
  0.000030518509447574615,
  0,
  ...
]

음수에서 양수로 변화하는 값들이다. 소리의 진동 그래프를 디지털로 수치화했음을 확인할 수 있다.

getChannelData 함수의 호출 파라미터로 0을 사용한 것은 첫번째 채널에 저장된 데이터를 사용하겠다는 의미다. 일반적으로 사용하는 2채널 스테레오 오디오라면 전체 채널의 수는 2개, 5.1채널 오디오라면 채널이 6개가 있다. 양쪽 채널에서 나오는 소리를 모두 사용하지 않은 것은 구현의 편의를 위해서다. 실제 구현된 플레이어에서 표시된 파형을 통해 소리가 없는 부분, 소리가 큰 부분을 찾았을 때 기대했던 것과 특별히 다른 경우는 없었다.

샘플링 데이터의 리샘플링

샘플링 데이터는 가져왔지만 그 값을 그대로 쓰기에는 너무 많다. 1초당 대략 4만개의 데이터가 있으므로 1분만 되어도 240만개의 데이터를 얻게 된다. 하지만 캔버스의 넓이가 500px이라면 500개의 데이터만 있어도 1px당 1개의 점을 찍는 것으로 선을 표현할 수 있기에 그만큼 많은 데이터는 필요가 없다.

그래서 1초당 표시할 데이터의 수를 정한 후, 샘플링 데이터를 구간별로 잘라서 평균을 내는 방식을 사용해서 전체 데이터의 수를 줄인다.

본문에 실린 코드는 React로 구현한 코드에서 이 글을 읽는 데 도움이 될 정도로만 발췌하고 수정했기에 언급하지 않은 멤버 변수와 함수가 포함되어 있을 수 있다는 점 양해 바랍니다.

const samplesPerSec = 100 // 1초당 표시할 샘플의 수
const {
  duration, // 오디오 길이 (초 단위)
  sampleRate, // 샘플링 레이트. 보통 48000 또는 44100.
} = audioBuffer;

const rawData = audioBuffer.getChannelData(0); // 첫번쨰 채널의 AudioBuffer
const totalSamples = duration * samplesPerSec; // 구간 처리 후 전체 샘플 수
const blockSize = Math.floor(sampleRate / samplesPerSec); // 샘플링 구간 사이즈
const filteredData: number[] = [];

for (let i = 0; i < totalSamples; i++) {
  const blockStart = blockSize * i; // 샘플 구간 시작 포인트
  let blockSum = 0;

  for (let j = 0; j < blockSize; j++) {
    if (rawData[blockStart + j]) {
      blockSum = blockSum + Math.abs(rawData[blockStart + j]); 
    }
  }

  filteredData.push(blockSum / blockSize); // 구간 평균치를 결과 배열에 추가
}

1초당 100개의 샘플 데이터만 가져오겠다고 한다면, 1초당 48000개의 샘플링을 100으로 나눠 480개의 구간을 만든 다음, 각 구간의 평균값을 구하면 된다.

다만 평균값을 구할 때 Math.abs 메소드를 사용해 샘플링 데이터의 절대값을 사용해야 한다. 샘플링 데이터는 소리의 세기를 나타내는 값이지만 파장 그래프 표현상 음수에서 양수로 변화하기 때문이다.

샘플링 데이터 정규화(normalizing)

리샘플링한 데이터를 사용하기 전에, 정규화 과정을 거쳐야 한다. 정규화 과정을 통해 샘플링된 데이터의 최대값이 1이 되도록 만든다.

오디오 파일마다 전체적으로 소리가 클 수도 있고 작을 수도 있다. 캔버스에 파형을 그릴 때 그런 값들을 정규화없이 그대로 반영하면 어떤 오디오는 파형이 너무 작게, 어떤 것은 너무 높게 표시될 것이다. 예를 들어 캔버스 높이가 300px일 때, 어떤 오디오든 그 안에서 가장 큰 소리가 (x,0) 좌표에, 가장 작은 소리는 (x,300) 좌표에 표시되게 할 필요가 있다(캔버스는 왼쪽 위 모서리의 좌표가 (0,0) 이다).

물론 작은 소리는 작은 파형으로 표시되길 원하는 서비스도 있을 수 있으므로 선택적으로 적용하면 되는 과정이다. 만약 오디오 파형을 통해 소리가 튀는 구간, 소리가 없는 구간 같은 정보를 직관적으로 얻기 위해서는 정규화를 거치는 편이 더 좋을 것이다.

const normalizeData = (filteredData: number[]) => {
  const peak = Math.max(...filteredData);
  const multiplier = Math.pow(peak, -1);
  return filteredData.map((n) => n * multiplier);
};

샘플링 데이터에서 최대값을 peak 에 저장한 후 샘플링 데이터 배열을 샘플링 * (1 / peak) 공식으로 맵핑해주면 정규화가 완료된다.

이렇게 오디오 데이터는 모두 준비되었다. 이제 캔버스에 샘플링 데이터를 그리는 과정이 필요하다.

Canvas API를 사용한 도형 그리기

Canvas API는 HTML canvas 요소와 자바스크립트를 사용해서 그래픽을 표현할 수 있다. 애니메이션, 게임, 데이터 시각화, 사진 편집 등에 사용된다. 주로 2D 그래픽에 사용되고, 3D 그래픽 표현에는 WebGL API를 사용한다. 오디오 파형은 선, 사각형, 텍스트, 다각형에 색 칠하기 등만 가능하면 구현 가능하기에 Canvas API를 깊게 알 필요까지는 없고 기초 지식(튜토리얼의 1~4장) 정도만 공부한 후 API 레퍼런스를 찾아보며 작업을 하면 된다.

requestAnimationFrame 함수

오디오 재생이 시작되면 오디오 파형 위에 현재 재생 위치를 표시하는 수직선을 표시해줘야 한다. 그것은 재생이 진행됨에 따라 오른쪽으로 움직여야 한다.

캔버스에서 CSS의 transition, @keyframes 등으로 만드는 것 같은 애니메이션 효과를 만드는 API는 별도로 없다. 캔버스에 그리고 지우는 것을 빠르게 반복함으로써 그런 효과를 만드는 방법을 사용한다. 그리고 그 반복 작업을 할 때 사용하는 것이 requestAnimationFrame 함수다.

window.requestAnimationFrame(callback);

이 함수는 브라우저의 리페인트(repaint)가 일어나기 전에 콜백을 실행한다. setInterval 같은 함수를 사용하지 않고, 재귀 호출을 사용해 requestAnimationFrame 을 반복 호출해도 그 실행 간격은 무한 루프에 빠진 것처럼 빠르게 실행되지 않으며 브라우저에 의해 디스플레이의 주사율에 맞춰진다. 즉 디스플레이가 60Hz의 주사율을 가지고 있다면 콜백의 호출 간격은 1/60초가 되는 셈이다. CPU 리소스를 무리하게 사용하지 않으면서도 사람의 눈에는 자연스러운 애니메이션 효과를 제공할 수 있게 된다.

파형을 그리는 drawWaveForm 이라는 함수가 있을 때, 애니메이션의 시작과 종료는 아래처럼 작성할 수 있다.

class AudioPlayer {

	drawWaveForm = () = {
	   // Canvas API를 사용한 오디오 파형 그리기 구현
  }

  rafId = -1;

  startDraw = () = 
    this.drawWaveForm();
    this.rafId = requestAnimationFrame(() =>
      this.startDraw(),
    );
  }

	stopDraw = () = 
	  cancelAnimationFrame(this.rafId);
  }
}

requestAnimationFrame 함수는 정수로 된 고유한 콜백 아이디를 리턴한다. cancelAnimationFrame 함수에 그 아이디를 넣어서 호출하면 다음 리페인트 직전에 requestAnimationFrame의 콜백이 실행되지 않으면서 캔버스를 업데이트하는 drawWaveForm 메소드 더 이상 실행되지 않게 된다. 실제 구현에서는 오디오 재생 버튼을 클릭했을 때 startDraw를, 멈춤 버튼을 클릭할 때 stopDraw를 호출하게 될 것이다.

오디오 파형 그리기

샘플링된 데이터가 있고 Canvas API가 있으니 이제 파형을 그리면 된다. 그려야 하는 것들에는 다음과 같은 것들이 있다.

백그라운드 박스
샘플링 데이터에 기반한 라인 그래프(또는 막대 그래프)
타임라인
현재 재생위치 표시 바

`CanvasRenderingContext2D` 인터페이스

실제로 도형을 그리는 데는 CanvasRenderingContext2D 인스턴스를 사용한다. 이것은 canvas 표면에 2D 렌더링 컨텍스트를 제공하며, 다각형, 텍스트, 이미지 등을 그릴 수 있다. 인스턴스는 canvas 요소를 통해 만들 수 있다.

<canvas id="my-house" width="300" height="300"></canvas>

const canvas = document.getElementById('my-house');
const ctx = canvas.getContext('2d');

`devicePixelRatio` 값에 맞춰서 scale 조정하기

디스플레이에 따라 가로 1920px 사이즈의 화면을 구성하는 픽셀의 수는 1920개일 수도 있고, 3840개일 수도 있다. 후자인 경우 어플리케이션이 사용하는 논리적 픽셀은 1개인데 실제로 사용하는 물리적 픽셀 수는 2개가 된다. 과거에는 이런 구분이 필요하지 않았지만, 아이폰 4S에서 레티나 디스플레이가 등장하면서 상황이 달라졌다. 웹사이트에 들어가는 캔버스를 사용할 때 화면의 DPI(Dots per Inch)에 맞춰서 업스케일링, 다시말해 논리적 픽셀 사이즈를 실제 디바이스의 픽셀 사이즈만큼 늘려줄 필요가 생긴 것이다.

하지만 고맙게도 브라우저의 API로 코드만 잘 작성해주면 업스케일링은 브라우저가 알아서 잘 해준다. 도형을 그리기 전에 아래 코드만 넣어주면 된다.

const ctx = canvasEl.getContext('2d');
const dpr = window.devicePixelRatio || 1;

ctx.scale(dpr, dpr);

scale 함수는 캔버스에서 사용하는 픽셀 단위를 늘려주는 역할을 한다. 그리고 devicePixelRatio는 물리적 픽셀과 논리적 픽셀의 비율을 반환하는데, 저 값이 HD 모니터에서는 1, 4K(=QHD) 모니터에서는 2가 된다. devicePixelRatio 값을 사용하면 올바른 업스케일링 비율을 사용할 수 있다. 만약 업스케일링 없이 오디오 파형을 그리게 한 후 4K 모니터에서 확인하면 아래 스크린샷처럼 보이게 된다.

파형의 넓이와 높이가 캔버스의 그것에서 정확히 절반이 되어버렸다. 하지만 scale 함수로 업스케일링을 해두면 아래처럼 오디오 파형이 정상적으로 캔버스 사이즈에 맞게 표시된다.

CSS로 스타일링을 할 때는 업스케일링을 자동으로 해 주기 때문에 신경쓸 필요가 없지만 캔버스로 도형을 그릴 때는 꼭 필요한 과정이다.

배경 그리기

requestAnimationFrame을 사용해서 캔버스에 계속 그림을 그릴 것이기에 매번 clearRect 를 사용해서 캔버스 위에 그려진 것을 지워줘야 한다. 안그러면 그렸던 도형들 위에 덧칠하는 형태가 되어 버린다. 예를 들어 좌표가 왼쪽에서 오른쪽으로 바뀌는 정사각형을 그리는 함수를 작성했다고 하자. 그런데 clearRect를 빼먹었다면 canvas 위에는 오른쪽으로 움직이는 정사각형 대신 오른쪽으로 점점 늘어나는 직사각형이 보일 것이다.

아래 코드는 canvas 전체를 지우고 배경색을 입혀준다.

ctx.clearRect(0, 0, canvasWidth, canvasHeight);
ctx.fillStyle = '#ccc'; // 캔버스 배경색
ctx.fillRect(0, 0, canvasWidth, canvasHeight);

샘플링 데이터로 그래프 그리기

오디오 파형 시각화의 핵심인 샘플링 데이터로 그래프를 그리기를 구현해야 한다. 아래의 값을 계산하면 라인 그래프를 그릴 수 있다.

전체 샘플의 수
canvas의 넓이
샘플 1개가 차지할 넓이 = canvas 넓이 / 샘플의 수
샘플의 x 좌표 = 샘플의 인덱스 * 샘플 1개가 차지할 넓이
샘플의 y 좌표 = 샘플 데이터(최대값 1로 정규화된 상태) * canvas의 높이

포인터를 캔버스의 좌하단으로 이동시킨 후 샘플 데이터 배열의 루프를 돌며 라인 그래프를 그린다.

// 샘플 1개가 차지할 넓이
const sampleWidth = waveAreaWidth / this.audioSamples.length;
let lastX = 0; // x축 좌표

ctx.beginPath(); // 선을 그리기 위해 새로운 경로를 만든다.
ctx.moveTo(lastX, canvasHeight);
ctx.strokeStyle = 'blue'; // 라인 컬러 설정
ctx.fillStyle = 'gray'; // 그래프 내부를 채울 컬러 설정

this.audioSamples.forEach((sample, index) => { // 샘플 데이터 배열 루프
  const x = sampleWidth * index; // x 좌표
  ctx.lineWidth = 2; // 라인 그래프의 두께
  ctx.lineTo(
    x,
    canvasHeight - Math.abs(sample * waveAreaHeight), // y축 좌표
  );
  lastX = x;
});

// 라인 그래프의 하단을 선으로 연결해서 닫힌 형태로 만든 후, 색을 채운다
ctx.lineTo(lastX, canvasHeight;
ctx.moveTo(0, 0);
ctx.stroke();
ctx.fill();

ctx.closePath(); // 그래프가 완성되었으므로 경로를 닫는다.

위의 코드에서는 상하좌우 패딩을 반영하지 않았다. 라인 그래프의 시작과 끝이 canvas의 좌측 끝과 우측 끝에 위치하게 된다. 특히 아래쪽에 타임라인을 추가하고 포지션 바가 canvas 끝에 겹치지 않게 하려면 전후좌우 패딩을 고려해서 라인을 그려줘야 한다.

이 방식을 활용하면 일정한 넓이를 가진 막대 그래프 형태로 만들 수도 있을 것이다. 다만 막대 그래프를 위해선 샘플링 데이터의 수를 더 줄여야 할 필요가 있다. 앞서서 샘플링 데이터를 정리할 때 1초당 100개가 되도록 했는데, 캔버스에서 1초가 차지하는 넓이가 100px이라도 막대 그래프의 넓이는 1px밖에 되지 않는다. 그러면 스크린샷에서 보여준 라인 그래프와 별다른 차이가 없게 된다. 일정한 넓이의 막대 그래프를 제공하기 위해서는 앞서 구현한 것과 다른 방식으로 샘플링 데이터를 정리할 필요가 있을 것이다.

오디오 재생 기능 구현

오디오 재생을 위해서는 아래의 기능이 필수적으로 필요하다.

재생 / 멈춤
탐색 (seeking, 재생 위치 업데이트)

오디오 플레이어 시각화

오디오 소스를 audio 요소에 연결해서 재생에 활용했지만 화면에 표시하지는 않도록 했다. audio 요소에 controls 속성을 지정해서 브라우저 네이티브 오디오 컨트롤러를 표시하게 할 수도 있지만 브라우저마다 다른 형태로 제공되기에 일관적인 디자인의 플레이어를 제공하기는 어렵기 때문이다.

재생 위치 슬라이더는 range 타입의 input 요소를 활용했는데, 스타일링을 위해서는 생각보다 많은 양의 CSS 작성이 필요했다(링크 참조).

<audio id='waveAudio' src={this.props.audioUrl} loop>
  Your browser does not support the
  <code>audio</code> element.
</audio>

<input
  id='seekSlider'
  type='range'
  className={'AudioPlayer__progressInput'}
  disabled={this.isInputDisabled}
/>;

오디오 재생 / 멈춤

재생 / 멈춤 기능은 버튼에 이벤트 핸들러만 추가하면 간단히 구현 가능하다.

togglePlayAudioEl = async () => {
  if (!this.state.isPlayingAudio) {
    this.playAudioEl();
  } else {
    this.pauseAudioEl();
  }
};

playAudioEl = () => {
  if (this.audioEl) {
    this.setState({ isPlayingAudio: true });
    this.audioEl.play(); // audio 요소의 play 함수 호출
  }
};

pauseAudioEl = () => {
  if (this.audioEl) {
    this.setState({ isPlayingAudio: false });
    this.audioEl.pause(); // audio 요소의 pause 함수 호출
  }
};

<button
  onClick={this.togglePlayAudioEl}
>
  <InlineIcon 
    icon={`${ // Iconify 라이브러리의 아이콘 활용
      this.state.isPlayingAudio ? 'mdi:pause-circle' : 'mdi:play-circle'
    }`}
  ></InlineIcon>
</button>;

캔버스 파형 클릭시 오디오 탐색

캔버스 파형 위를 클릭했을 때의 오디오 탐색 위치는 로딩된 오디오의 전체 길이, 캔버스의 넓이, 마우스 클릭 지점으로 계산할 수 있다.

getTimeByPositionOfCanvas = (e: MouseEvent) => { // 클래스의 멤버 함수
	const rect = this.canvasEl.getBoundingClientRect(); // 캔버스의 포지션 정보

  // 마우스 위치와 캔버스 위치를 사용해 x축 좌표를 계산한다. 
	const x = e.clientX - rect.left;

  // (전체 시간 * x축 좌표 / 파형의 널이) 값이 이동할 위치가 된다.
	return Math.max(0, this.duration * (x / this.getWaveAreaSize().width));
}

계산한 값을 오디오 요소의 currentTime 속성에 할당해주면 재생 위치가 업데이트된다.

this.audioEl.currentTime = this.getTimeByPositionOfCanvas(e)

나머지 구현 사항

여기까지가 오디오 파형의 시각화에 필수적으로 필요한 부분이다. 스크린샷에 제공한 플레이어가 가진 기능 중 이 글에서 설명하지 않은 부분은 다음과 같다.

파형 확대, 축소
- 화면을 벗어날 정도로 커진 캔버스가 좌우 스크롤 되도록 wrapper 요소 추가
- 줌 배율에 따른 그리기 값 계산
- 현재위치 바가 화면을 벗어났을 때 스크롤 이동시키기
구간 반복 기능
- mousedown, mousemove, mouseup 이벤트로 반복구간 설정
- 반복 구간 설정 중인 구간을 박스 형태로 canvas에 그리기
- 반복 구간 재생. AudioContext 사용해서 재생하기

파형 확대, 축소 기능이 들어가게 되면 파형 그래프 포지션의 계산, 오디오 탐색을 위한 공식에 확대/축소 상태를 고려해야 한다. 그리고 확대되었을 때 캔버스 사이즈를 늘리고 좌우 스크롤이 가능하게 할 것인지, 스크롤 없이 현재 포지션 바를 항상 가운데에 두게 하고 파형을 좌우로 움직이게 할 것인지에 따라 구현 방식이 달라지게 된다.

그리고 구간 반복을 위해서는 우선 구간 설정을 할 수 있는 이벤트 핸들러를 구현해야 하고, 구간 설정 중에 위치를 파악할 수 있도록 캔버스에 반투명 사각형 영역을 그려줘야 한다. 그리고 설정된 구간은 이동 및 시작/종료 지점 수정이 가능하도록 만들어야 한다. 구간 반복 오디오는 audio를 직접 재생하는 것이 아니라 AudioContext 인스턴스로 오디오 소스를 별도로 생성해서 재생했다.

References

Recoil의 쓰기 가능한 셀렉터

rhostem — Wed, 24 Nov 2021 00:00:00 GMT

파생된 상태를 만드는 단방향 흐름의 selector

Recoil은 selector API를 제공한다. React의 useMemo, Redux의 selector 처럼 다른 상태를 기반으로 파생된 상태(derived state) 만들어내는 역할을 한다. 간단한 예를 들면 작업 목록에서 완료된 작업만 추려내고 싶을 때 사용할 수 있다.

import { atom, selector } from 'recoil';

type Job = { content: string; isDone: boolean };

const jobListState = atom<Job[]>({
  key: 'jobListState',
  default: [],
});

const completedJobsSelector = selector({
  key: 'completedJobsSelector',
  get: ({ get }) => {
    const jobList = get(jobListState);
    const completed = jobList.filter((v) => v.isDone);
    return completed;
  },
});

쓰기까지 가능한 양방향 흐름을 가진 selector

그런데 Recoil은 “쓰기 가능한 selector 상태”, writable selector라는 개념을 구현해 두었다. React를 사용해 온 사람이라면 ‘selector’라는 명사는 파생된 상태를 의미하며, 단방향 흐름을 가진 데이터라는 인식을 가지고 있어서 다소 의아하게 느껴질 수 있다. selector인데 양방향 데이터 흐름을 가진 것이라니?

예를 들어 속도 정보를 관리해야 할 때 원본 데이터는 마일(mile)/h인데 화면 상에는 킬로미터(km)/h로 표시해야 하는 경우가 있을 수 있다. 그 관계를 atom과 selector로 표현하면 다음과 같다.

const mphState = atom({
  key: 'mphState',
  default: 0,
});

const kphState = selector({
  key: 'kphState',
  get: ({ get }) => {
    const mph = get(mphState);
    return mph * 1.609; // 1마일은 약 1.609킬로부터
  },
});

이렇게 작성한 kphState 상태는 쓰기가 불가능한 상태다. 즉 useSetRecoilState 나 useRecoilState 훅의 파라미터로 넣을 수 없다. 하지만 selector에 set 속성을 추가한다면 쓰기가 가능해진다. 컴포넌트에서 useSetRecoilState 을 사용해 kphState의 setter 함수를 만들면 킬로미터/h 값을 넘겨서 mphState 상태를 업데이트할 수 있게 되는 것이다.

export const kphState = selector<number>({
  key: 'kphState',
  get: ({ get }) => {
    const mph = get(mphState);
    return mph * 1.609;
  },
  set: ({ set }, newValue) => {
    if (typeof newValue === 'number') {
      set(mphState, newValue / 1.609); // 킬로미터를 마일로 변환한다
    }
  },
});

const KPHInput: React.FC<Props> = () => {
  const setKph = useSetRecoilState(kphState);
  return (
    <input type="number" onChange={(e) => setKph(parseInt(e.target.value))} />
  );
};

쓰기 가능한 selector의 초기화 기능

kphState selector의 set 속성의 두번째 파라미터인 newValue의 타입을 확인해보면 number | DefaultValue 로 되어있음을 알 수 있다. DefaultValue 타입은 set 콜백이 setter(업데이트) 함수를 통해 호출되었는지, resetter(초기화) 함수로 호출되었는지 구분해주는 역할을 한다. 컴포넌트에서 useSetRecoilState 를 사용해서 만들었다면 setter 함수가 되고, useResetRecoilState를 사용해서 만들었다면 resetter 함수가 된다.

export const kphState = selector<number>({
  key: 'kphState',
  get: ({ get }) => {
    const mph = get(mphState);
    return mph * 1.609;
  },
  set: ({ set, reset }, newValue) => {
    // selector의 resetter를 호출하면 newValue는 DefaultValue 인스턴스가 된다.
    if (newValue instanceof DefaultValue) {
      reset(mphState);
    } else if (typeof newValue === 'number') {
      set(mphState, newValue / 1.609);
    }
  },
});

const ResetKPHButton: React.FC<Props> = () => {
  const resetKph = useResetRecoilState(kphState); // resetter 함수 생성

  return <button onClick={resetKph}>Reset KPH</button>;
};

언제 사용하면 좋은가?

쓰기 가능한 selector에 대한 개념은 파악이 되었다. 그런데 더 중요한 질문이 남았다. 그래서 왜, 언제 사용하면 좋을까이다.

위의 예제에 있는 것처럼 마일-킬로미터 같은 관계를 차치하고 생각하면 쓰기 가능한 selector는 그저 “컴포넌트 외부에 모듈 형태로 선언 가능한 Recoil 상태 업데이트 콜백 함수”라는 개념이 되긴 한다. 하지만 완전히 자유롭게 아무 일이나 할 수는 없다. selector 함수의 타입 선언을 보면 get 콜백이 필수 값이라서 set만 선언할 수는 없으며, get 콜백이 리턴하는 타입과 set 콜백에 전달되는 newValue의 타입이 일치해야 한다.

function selector<T>({
  key: string,

  get: ({
    get: GetRecoilValue,
    getCallback: GetCallback,
  }) => T | Promise<T> | RecoilValue<T>, // 타입 T에 해당하는 값, T를 리턴하는 Promise,

  set?: (
    {
      get: GetRecoilValue,
      set: SetRecoilState,
      reset: ResetRecoilState,
    },
    newValue: T | DefaultValue, // setter로 전달하는 값은 T 타입 값이어야 한다.
  ) => void,
})

Redux의 reducer 함수처럼 전달할 값과 업데이트할 상태를 자유롭게 구현하라는 용도로 제공된 기능은 아님을 알 수 있다. T 타입을 가진 파생된 상태를 만들어야 하고, 동시에 T 타입의 값을 전달해서 다른 상태를 업데이트할 필요가 있을 때 쓰기 가능한 selector를 사용할 필요가 생긴다. 또는 파생된 상태를 초기화시키고 싶을 때 유용하게 사용할 수 있다.

그런데 초기화라면 굳이 selector의 set 콜백을 사용할 필요 없이 selector의 소스가 되는 atom상태를 직접 초기화시키면 되는 것 아닌가?라는 질문이 나올 수 있다. 물론 그렇게 초기화 로직을 구현해도 상관없다. 하지만 코드의 가독성과 유지 보수성에 차이가 올 것이다. 파생된 상태는 여러 개의 atom과 selector 상태를 기반으로 복잡한 로직을 거쳐 만들어질 수도 있다. 그렇다면 초기화 시키는 로직 역시 여러 과정이 필요할 수 있다. 그런데 reset이 여러 곳에서 필요하다면 그 로직을 어떻게 모듈화할 것인가? 커스텀 훅 함수를 사용할 수도 있겠지만 selector의 set 콜백을 사용하면 더 간편하다. 상태 업데이트를 위한 기능도 제공하며 자연스럽게 모듈화도 되는 셈이니 말이다.

Redux의 reducer 역할은 쓰기 가능한 selector보다는 useRecoilTransaction과 useRecoilCallback에 커스텀 훅 함수를 조합해서 구현하는 편이 좋다.

`useRecoilTransaction`을 사용한 Recoil 상태 업데이트

useRecoilTransaction은 useCallback처럼 컴포넌트 안에서 사용할 수 있는 함수를 만드는 훅 함수다. 파라미터로 팩토리 함수를 전달하는 방식을 사용해 Recoil의 상태를 관리할 수 있는 인터페이스를 제공한다.

interface TransactionInterface {
  get: <T>(RecoilValue<T>) => T; // Recoil 상태를 가져온다
  set: <T>(RecoilState<T>,  (T => T) | T) => void; // 상태를 업데이트한다
  reset: <T>(RecoilState<T>) => void; // 상태를 초기화한다
}

// Args가 실제로 사용할 콜백의 파라미터들이 된다.
function useRecoilTransaction_UNSTABLE<Args>(
  callback: TransactionInterface => (...Args) => void,
): (...Args) => void

아래는 useRecoilTransaction을 사용하는 예제다. 만들어진 함수는 goForward(100) 같은 방식으로 호출해서 positionState 상태를 업데이트하는데 쓸 수 있다.

const goForward = useRecoilTransaction_UNSTABLE(
  ({ get, set }) =>
    (distance) => {
      const heading = get(headingState);
      const position = get(positionState);

      set(positionState, {
        x: position.x + cos(heading) * distance,
        y: position.y + sin(heading) * distance,
      });
    },
);

useRecoilCallback이 Recoil 상태에 접근하기 위해 snapshot 을 사용해야 하는 것에 비하면 비교적 간편하게 상태를 관리할 수 있다. 다만 리턴 값을 넘길 수 없으며, selector 상태와 비동기 atom은 사용할 수 없는 등의 한계가 있다. 그리고 상태 업데이트 외의 side effect를 만들고 싶다면 useRecoilTransaction이 아닌 useRecoilCallback을 사용하라는 가이드를 공식 문서에서 주고 있다.

참고 자료

React 커스텀 훅 함수의 테스트 코드 작성

rhostem — Tue, 19 Oct 2021 00:00:00 GMT

커스텀 훅은 React 함수형 컴포넌트 API를 사용하는 함수

React에서 사용하는 커스텀 훅(custom hook)은 함수 형태로 구현한다. 하지만 일반적인 함수처럼 테스트 코드를 작성할 수는 없다. 왜냐하면 훅 안에서는 React 함수형 컴포넌트에서 사용하는 API를 사용하기 때문이다. 아래는 간단한 커스텀 훅으로써 useState API를 사용한다.

import { useState } from 'react';

export default function useSample() {
  const [isOpen, setIsOpen] = useState(false);

  return {
    isOpen,
    setIsOpen,
  };
}

함수형 컴포넌트 안에서 사용하는 API를 포함하고 있기 때문에 커스텀 훅을 일반적인 함수처럼 호출하면 에러가 발생한다.

import useIsOpen from './useIsOpen';

test('isOpen의 초기값은 false다', () => {
  const result = useIsOpen();
  expect(result.isOpen).toBe(false);
});

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:

      3 | export default function useSample() {
    > 4 |   const [isOpen, setIsOpen] = useState(false);

통합 테스트를 중심으로 작성하고 있다면 커스텀 훅을 사용하고 있는 컴포넌트의 테스트를 작성하는 과정에서 자연스럽게 테스트가 이뤄지긴 할 것이다. 하지만 통합 테스트는 애초에 목적이 다르며, 커스텀 훅의 기능 하나하나를 확인하기에는 적절하지 않다. 커스텀 훅의 유닛 테스트를 위해서는 테스트 코드 안에서 간단한 래퍼 컴포넌트를 작성해줘야 한다.

import React from 'react';
import { render } from '@testing-library/react';
import useIsOpen from './useIsOpen';

test('isOpen의 초기값은 false다', () => {
  let result = {} as ReturnType<typeof useIsOpen>;

  const Wrapper = () => {
    result = useIsOpen();
    return null;
  };

  render(<Wrapper />);

  expect(result.isOpen).toBe(false);
});

result 변수를 선언한 후
Wrapper 컴포넌트를 선언한다. useIsOpen 의 리턴 값을 할당받게 했다.
render 함수로 Wrapper를 마운트한다. result에 훅 함수가 리턴한 값이 할당된 상태가 된다.
result 객체에 기대한 값이 들어있는지 확인한다.

이 기본 형태를 바탕으로 커스텀 훅 테스팅을 위한 유틸리티를 만들어서 써도 되겠지만, 언제나 먼저 앞서 나가는 사람들은 있는 법이다. 오픈소스인 react-hooks-testing-library가 있으니 활용하도록 하자.

react-hooks-testing-library를 사용한 커스텀 훅 테스팅

react-hooks-testing-library는 커스텀 훅 테스팅을 위한 렌더링 API로 renderHook 함수를 제공한다. renderHook 콜백 함수를 파라미터로 받으며, 그 함수는 1개 이상의 훅 함수의 실행을 포함하고 있어야 한다. 그리고 콜백 함수가 리턴하는 값은 renderHook 리턴 값의 result 속성을 통해 참조 가능하다.

import { renderHook } from '@testing-library/react-hooks';
import useIsOpen from './useIsOpen';

test('isOpen의 초기값은 false다', () => {
  const { result } = renderHook(() => useIsOpen());
  expect(result.current.isOpen).toBe(false);
});

result.current 필드를 통해 콜백 함수가 마지막으로 리턴한 값(여기서는 useIsOpen 훅이 마지막으로 실행되어서 리턴한 값)을 참조할 수 있다. current라는 값이 있는 이유는, 커스텀 훅은 컴포넌트 안에서 실행되는 만큼 한번 이상 호출될 수 있기 때문이다.

커스텀 훅의 상태(state) 업데이트 테스트

커스텀 훅은 여러 컴포넌트에서 재활용하기 위해 복잡한 로직을 포함하고 있는 경우가 많고, 그 로직이 잘 구현되었는지 확인하는 과정도 반드시 필요하다. useIsOpen 훅으로 예시를 들자면 setIsOpen 메소드 호출을 통해 isOpen 상태가 변경되는지 확인이 필요하다는 말이다.

import { renderHook, act } from '@testing-library/react-hooks';
import useIsOpen from './useIsOpen';

test('setIsOpen 호출을 통해 isOpen 상태를 업데이트할 수 있다.', () => {
  const { result } = renderHook(() => useIsOpen());

  act(() => {
    result.current.setIsOpen(true);
  });

  expect(result.current.isOpen).toBe(true);
});

act 함수는 react-dom/test-utils 모듈에서 제공하고 있는 그것이다. 테스트 코드 내부에서 컴포넌트 렌더링 및 상태 변경은 act 함수 내부에서 실행해야 안전하다(여기서는 컴포넌트 렌더링이 없으므로 act로 래핑하지 않아도 테스트는 성공하긴 한다).

useEffect 실행 확인 테스트

커스텀 훅 안의 useEffect 훅이 실행되는지 확인하기 위해서는 useEffect가 의존하고 있는 변수가 업데이트되도록 만들어야 한다. 테스트를 위해 props를 받아서 상태를 업데이트하는 usePage라는 간단한 커스텀 훅을 구현했다.

import { useState, useEffect } from 'react';

export default function usePage({ initialPage = 1 }: { initialPage?: number }) {
  const [page, setPage] = useState(initialPage);

  useEffect(() => {
    if (initialPage) {
      setPage(initialPage);
    }
  }, [initialPage]);

  return {
    page,
    setPage,
  };
}

renderHook 함수는 두 번째 파라미터로 커스텀 훅의 props를 제공할 수 있다. 그리고 renderHook 함수의 리턴 값이 주는 rerender 함수를 사용하면, 마운트된 컴포넌트가 한번 더 렌더링되면서 커스텀 훅도 한번 더 실행된다.

아래 테스트에서 rerender를 호출할 때 처음과 다른 initialPage 값을 전달했는데, 그 값이 커스텀 훅의 상태(page)에 제대로 반영되었음을 확인할 수 있다.

import { renderHook } from '@testing-library/react-hooks';
import usePage from './usePage';

test('initialPage의 변경은 page 상태에 반영된다.', () => {
  const { result, rerender } = renderHook((props) => usePage(props), {
    initialProps: {
      initialPage: 1,
    },
  });

  expect(result.current.page).toBe(1);

  rerender({
    initialPage: 5,
  });

  expect(result.current.page).toBe(5);
});

Context를 사용하는 커스텀 훅의 테스트

커스텀 훅이 Redux의 useDispatch 훅을 사용하거나, Recoil의 useRecoilState같은 훅을 사용한다면 테스트 코드도 거기에 맞는 Provider를 제공해야 한다. react-hooks-testing-library는 그를 위한 API를 제공한다.

import { RecoilRoot } from 'recoil';
import { useData } from './hooks'; // recoil을 사용하는 커스텀 훅

const Wrapper: React.FC = ({ children }) => {
  return (
    /** Recoil의 훅 사용을 위해 RecoilRoot로 컴포넌트를 래핑한다  */
    <RecoilRoot>{children}</RecoilRoot>
  );
};

test('some state', () => {
  const { result } = renderHook(() => useData(), {
    wrapper: Wrapper,
  });

  expect(result.current.data).toBe(null);
});

비동기 코드가 포함된 커스텀 훅의 테스트

실무에서는 백엔드 API 호출 데이터를 상태에 반영하는 커스텀 훅도 구현할 일이 많이 생긴다. 그런 커스텀 훅의 테스트는 testing-library를 사용해봤다면 익숙할 waitFor 함수로 가능하다.

그리고 react-hooks-testing-library가 제공하는 waitForNextUpdate라는 기능이 있는데, 이는 waitFor와는 다르게 콜백 함수가 없다. 말 그대로 비동기적으로 실행되는 코드에 의한 태스크가 실행될 때까지 대기하는 역할을 한다. 예제를 위해 setTimeout을 사용해 상태를 업데이트하는 훅을 살펴보자.

import { useState, useEffect } from 'react';

export default function useAsyncCounter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    setCount(1);
    setCount(2);
    setCount(3);
  }, [setCount]);

  useEffect(() => {
    setTimeout(() => {
      setCount(1000);
    }, 300);
  }, []);

  return {
    count,
  };
}

첫 번째 useEffect 안에서 setCount를 세 번 호출했지만 모두 동기적으로 업데이트된다. 그러므로 테스트 코드에서 count 는 처음부터 3으로 확인될 것이다.

expect(result.current.count).toEqual(3);

그리고 300ms 후에 count 상태가 1000이 되도록 작성했다. 이 코드의 동작을 확인하기 위해서는 테스트 코드도 상태가 업데이트될 때까지 기다려야 한다. 이런 경우에 waitForNextUpdate 를 사용한다. 달리 말하자면 waitForNextUpdate가 리턴하는 Promise는 비동기 코드에 의해 컴포넌트가 다시 렌더링된 직후에 resolve된다.

import { renderHook } from '@testing-library/react-hooks';
import useAsyncCounter from './useAsyncCounter';

test('setTimeout을 사용하면 비동기적으로 상태가 업데이트된다', async () => {
  const { result, waitForNextUpdate } = renderHook(() => useAsyncCounter());

  expect(result.current.count).toEqual(3);

  await waitForNextUpdate(); // 호출하지 않으면 테스트가 실패한다

  expect(result.current.count).toEqual(1000);
});

다만 커스텀 훅의 로직이 복잡하고 비동기 코드에 의해 업데이트되는 상태가 여러 개라면 waitFor를 사용하는 편이 더 간단하고 확실하게 테스트 결과를 확인할 수 있을 것이다.

Vue 3의 setup 기능이 제공하는 간결한 컴포넌트 문법

rhostem — Fri, 17 Sep 2021 00:00:00 GMT

Vue는 스크립트, 마크업, 스타일시트를 한 파일 안에서 작성할 수 있는 SFC(Single File Component) 문법으로 컴포넌트를 작성할 수 있는 *.vue 파일을 지원한다. SFC는 아래와 같은 방식으로 작성할 수 있다. template 태그 안은 마크업이며 script 안에서 선언한 변수를 사용할 수 있다. 마크업 안에서는 style 태그 안에서 작성한 스타일시트도 사용할 수 있다.

<template>
  <div class="example">{{ msg }}</div>
</template>

<script>
export default {
  data() {
    return {
      msg: 'Hello world!'
    }
  }
}
</script>

<style>
.example {
  color: red;
}
</style>

Vue는 기본적으로 컴포넌트 모듈을 객체 형태로 선언하며 props 정의(props), 상태 변수(data), 메소드(methods), 라이프사이클(mounted, updated, beforeUnmount, …), 계산된 값(computed), 특정 값의 업데이트 탐지(watch) 등의 기능을 객체의 속성과 메소드를 사용해서 선언한다.

속성별로 역할과 책임 소재가 분명히 나눠져 있다는 점에서 컴포넌트가 어떻게 동작하는지 이해하는 데 도움을 준다. 하지만 앱의 규모가 커지면서 컴포넌트 수가 늘어나고 코드가 길어지면 문제가 생긴다. data, methods, template, watch 등은 모두 유기적으로 동작하는데, 컴포넌트의 덩치가 크면 여기저기로 점프를 하며 코드를 읽어야 하는 일이 자주 발생하게 된다. 즉 가독성이 매우 떨어지게 된다. 그런 상태가 되면 특정 기능과 관련된 변수와 메소드는 한곳에 모여 있으면 보기 좋겠다는 생각이 자연히 들게 된다. 그래서인지 Vue 3에서는 Composition API를 제공한다.

Composition API 와 `setup` 함수의 등장

Vue 3에서는 컴포넌트 객체에 setup 함수를 사용할 수 있다. ref 를 사용해서 반응형 변수로 data를, 보통의 자바스크립트 함수로 methods를 대체한다. 라이프사이클 메소드는 onMounted, onUpdated 같은 라이프사이클 훅 함수가 대신한다. 반응형 변수의 변경 탐지 역시 watch 함수로 구현 가능하며 계산된 값을 위한 computed 함수도 제공된다. 컴포넌트 객체애서 속성으로 분리되었던 기능 대부분이 setup 함수 안에서 사용 가능하다. setup을 사용하는 컴포넌트는 아래와 같은 방식으로 작성한다.

<script>
import { ref, onMounted } from 'vue'

export default {
  props: {
    name: String
  },
  setup(props) {
    const isSubmited = ref(false);
    const onSubmit = () => {
      isSubmited.value = true;
    }

    onMouted(() => console.log('component mounted'));

    // template에 전달한다.
    return { 
      isSubmited,
      onSubmit
    }
  }
}
</script>
<template>
  <div>{{ name }} {{ isSubmited ? 'submited' : 'not yet' }}</div>
  <button @click="onSubmit">Submit</button>
</template>

중요한 차이점은 setup 함수는 컴포넌트 인스턴스가 생성되기 전에 실행된다는 점이다. 즉 컴포넌트 인스턴스에 접근이 필요한 기능은 사용할 수 없다. 즉 setup 안에서 this를 통해 컴포넌트 객체의 data, computed, methods 에서 선언한 것들에는 접근이 불가능하다. 그리고 인스턴스가 생성된 직후에 호출되는 created 메소드에 매칭되는 라이프 사이클 훅도 존재하지 않는다.

커스텀 훅을 사용한 로직 분리 및 재활용

Vue에서는 mixins를 사용해서 로직 재활용이 가능하다. 하지만 컴포넌트 속성이 병합된다는 특징을 가질 수밖에 없다. 예를 들어 컴포넌트와 믹스인에서 선언한 data 함수에서 리턴하는 변수의 이름이 같으면 의도하지 않게 덮어씌워지거나 하는 등의 충돌이 발생할 수 있기에 사용에 있어 주의가 필요하다. 하지만 setup을 사용하면 외부 함수를 호출하는 방식으로 완전한 로직의 분리가 가능하다. React를 사용한다면 함수형 컴포넌트에서 로직 공유를 위해 커스텀 훅을 구현하는 일에 익숙할텐데, Vue 3에서는 setup 함수 안에서 그와 똑같은 방법을 사용할 수 있게 되었다.

예를 들어 Select 컴포넌트를 위한 옵션을 서버에서 가져와야 하는데, 그 과정이 여러 페이지에서 필요하다고 가정하자. 그렇다면 옵션 데이터를 가져오는 과정을 훅 함수 안에서 구현한 후 setup 안에서 호출하여 결과만 가져오는 방식을 사용하면 된다.

export default function useSomeOptions() {
	const options = ref([]);

  onMounted(() => {
		axios.get('https://api.server.com').then(({ data }) => {
			options.value = data;
		})
  })

	return {
		options
	}
}

<template>
  <select>
    <option v-for="(item, index) in options" :key="index">{{ item }}</option>
  </select>
</template>

<script>
import useSomeOptions from './useSomeOptions'

export default {
  name: 'Page component',
  setup() {
		const { options } = useSomeOptions();
    return {
      options,
    };
  },
}
</script>

<style></style>

Vue의 기존 문법을 선호하는 사람이라면 setup 함수와 커스텀 훅을 볼 때 Vue를 React스럽게 쓴다고 거부감을 표현할 수도 있을 것 같다. setup 안에서는 심지어 React처럼 render 함수와 JSX까지 지원하며 template 파트가 완전히 사라지게 구현할 수도 있다(타입스크립트를 사용하는 입장이라면 더욱 선호할 것이다). 하지만 Vue 3에서도 mixins 등 기존 문법은 여전히 지원하므로 개인이 선호하는 방식으로 구현하면 된다. 대신 React를 사용하는 사람 입장에서는 친숙한 패턴으로 인해 진입 장벽이 많이 낮아졌다고 할 수 있다.

script setup 문법

컴포넌트 객체의 setup 함수는 확실히 혁신적이고 큰 변화지만 여전히 아쉬운 점이 있다. data, methods 와 마찬가지로 return 을 사용해서 템플릿으로 값을 넘기는 과정이 필요하다는 것이다. React 함수형 컴포넌트에서 상태 변수, 메소드를 선언한 후 JSX 안에서 바로 사용하는 데 익숙한 입장에서는 다소 번거롭고 버그가 많이 발생하는 부분이었다. setup은 물론 다른 옵션들도 마찬가지다. 예를 들어 template 안에서 사용할 외부 컴포넌트는 모듈 import 후에 컴포넌트의 components 속성에 추가해야 한다. import만으로 끝나지 않는다는 말은 상용구(boilerplate) 코드가 별도로 필요하다는 것, 그리고 앱의 사이즈가 커짐에 따라 반복 작업이 늘어난다는 말이 된다.

Vue 3에서는 이런 불편함을 해소할 수 있는 방법을 제공한다. script setup 문법이 그것이다.

<script setup>
// 변수 선언
const msg = 'Hello!'

// 함수 선언
function log() {
  console.log(msg)
}
</script>

<template>
  <!-- 템플릿 안에서 바로 사용 가능 -->
  <div @click="log">{{ msg }}</div>
</template>

뭔가 코드가 허전할 정도로 많이 줄었다. return을 통해서 template에 명시적으로 전달하는 과정이 생략된 덕분이다. 컴포넌트 모듈도 import만 해주면 template 안에서 사용할 수 있다. 특히 컴포넌트를 타입스크립트로 사용할 때 더 좋다. 컴포넌트 객체로 props를 선언하기 위해서는 Javascript의 Primitive 데이터의 생성자 함수(ex. String, Object, Function)와 PropType을 조합해야 했지만, script setup 안에서는 defineProps에 제네릭과 타입스크립트의 타입을 그대로 사용하면 된다.

const props = defineProps<{
  foo: string;
  bar?: {
		data: number;
    isSetup: boolean;
	}
}>()

setup 기능의 장단점

Vue 3에서 제공하는 setup의 장점과 단점은 아래와 같이 정리할 수 있다.

장점

간결한 문법으로 상용구(boilerplate)를 줄일 수 있음
타입스크립트를 사용해 props와 emmited value 선언이 가능
런타임 성능의 향상(템플릿이 setup 스크립트와 같은 스코프(scope)에 있는 render 함수로 컴파일되므로 프록시가 필요없음)
더 뛰어난 IDE 타입 추론 성능 (language 서버가 코드로부터 타입을 추론해내는 데 비용이 덜 든다)

단점

Vue 3는 정식 배포 전이므로 버그 및 API 스펙 변경 가능성 있음
아직(2021년 9월 현재) vscode의 공식 툴인 Vetur의 지원이 완벽하지 않음
- ex. import한 컴포넌트를 render 함수가 아닌 template에서 사용하면 “사용하지 않은 변수”라는 문법 오류를 표시함

타입스크립트로 Vue 3를 사용해 본 입장에서는 setup 기능을 굳이 사용하지 않을 이유가 없었다. script setup이 제공하는 간결한 문법에 Vue의 반응형 시스템, 편리한 directive들까지 생각하면 Vue 3는 예전보다 훨씬 더 매력적인 도구로 다가오고 있다.

Recoil atomFamily를 사용한 상태 관리

rhostem — Wed, 07 Jul 2021 00:00:00 GMT

Recoil에 대한 간략한 소개

Recoil은 Facebook에서 만든 React를 위한 상태 관리 라이브러리다. 아직은 버전이 0.3이며(2021년 7월 현재) Redux의 미들웨어처럼 활용할 수 있는 atomEffect의 스펙이 아직 안정화된 상태가 아니긴 하다. 하지만 API 스펙의 안정화, 성능 개선과 함께 Recoil을 기반으로 한 라이브러리가 늘어나면 Redux를 점점 대체해 나갈 것으로 기대된다.

Redux의 상태 관리는 기본적으로 상용구 코드(boilerplate code)가 많이 발생하는데다 combineReducer를 통한 reducer 분할이 가능하다 하더라도 Recoil의 atom과 같은 유연함은 결코 제공할 수 없다. 컴포넌트의 useMemo처럼 파생 데이터를 생성할 수 있는 기능은 자체적으로 가지고 있지 않아서 reselect같은 외부 라이브러리의 힘을 빌려야 한다. 그리고 atomEffect처럼 특정 상태가 업데이트 되었을 때 실행할 사이드 이펙트는 자체적으로 정의할 수 없으며 컴포넌트에서 상태를 구독한 후 useEffect 안에서 구현해야 한다. Redux 미들웨어는 상태 업데이트 후에 실행되는 것이 아니라 dispatch된 모든 액션이 거쳐가는 곳이라 성격이 다르다.

그리고 결정적으로 데이터 구조가 다르다. Redux의 상태 구조는 트리 형태지만 Recoil은 유향 그래프(directed graph) 형태로 구성된다. Recoil에서 데이터의 소스인 atom은 고유한 문자열 키를 가지는데, Recoil은 atom의 키를 구성하는 알파벳을 노드로 하여 그래프를 구성한다(Trie 참조). Recoil에서 atom의 키는 고유한 값을 가져야 하므로 그래프 상의 노드에는 언제나 1개의 atom만 존재하게 된다. 이는 곧 atom이 다른 atom의 영향을 받지 않는 독립적인 상태라는 말이기도 하다. Redux에서 그랬던 것처럼 reducer를 구현할 때 업데이트 대상이 아닌 값(=상태 객체의 다른 필드)들의 불변성을 보장하기 위해 immutable.js, immer 같은 라이브러리의 사용할 고려할 필요가 없다.

이 외에도 Recoil은 React의 동시성 모드(Concurrent Mode) 및 신규 기능과의 호환성이 제공될 수 있으며 atom, selector 앱 개발에 따라 점진적으로 추가할 수 있어서 코드 분할에 용이하다는 점, 비동기 selector를 통한 원격 데이터 구독 등 다양한 특징을 가지고 있다.

atom으로 할일 목록 관리

앱에서는 같은 타입의 상태 객체로 구성된 그룹, 배열이 필요한 경우가 생긴다. 그리고 상태 객체는 동적으로 추가, 수정, 제거될 수 있어야 한다. 예를 들면 할일 목록이 그렇다.

type Todo = {
  id: string;
	title: string;
  isDone: boolean
}

type TodoList = Todo[]

그런데 할일 항목은 동적으로 추가, 삭제되므로 atom으로 하나하나 선언하는 것은 불가능하다. 그러면 TodoList 타입을 가진 atom을 선언해서 상태를 관리하면 되지 않을까?

const todoListState = atom<TodoList>({
  key: 'todoListState',
  default: [],
})

이렇게 가능하다. 하지만 할일 목록의 업데이트를 위해서 atom이 가진 상태는 항상 새로운 배열로 교체되어야 한다.

const App = () => {
  const [todoList, setTodoList] = useRecoilState(todoListState)

  const addTodo = () => {
		setTodoList([...todoList, { id: uuid(), title: '', isDone: false }])
	} 

  const removeTodo = (id) => {
		const target = todoList.findIndex(v => v.id === id)
    const updatedList = [...todoList]
    updatedList.splice(target, 1)
    setTodoList(updatedList)
	} 

  // update todo and so on....
}

Redux로 배열을 제어할 때 많이 보던 방식이다. 그리고 atom 업데이트를 위해 배열을 완전히 교체하는 비용이 발생하므로 불변성을 제공하기 위해 immer 같은 라이브러리를 도입해야 할 것 같다. useState를 쓰는 것과 별다른 점이 없는 것 같은데, 이러면 그냥 Redux를 쓰고 싶어질 것 같다.

하지만 이렇게 atom으로 할일 목록을 관리하는 것이 아니라, 1개의 할일 객체는 1개의 atom에 대응되게 만들 수는 없을까? 그러면 할일을 렌더링하는 컴포넌트에서 1개의 atom만 직접 구독하면 될 것이다. 업데이트할 때도 배열을 교체하는 것이 아니라 구독한 atom만 업데이트해주면 된다.

const TodoComponent = () => {
	 const [todo, setTodo] = useRecoilState(동적으로 만들어진 atom)
}

이런 케이스를 위해 Recoil은 atomFamily API를 제공한다.

atomFamily

atomFamily API는 atom을 리턴하는 팩토리 함수를 만들며, 그 팩토리 함수로 독립적인 atom state를 만들 수있다. 할일 상태를 atomFamily로 작성하면 다음과 같다.

const todoItemState = atomFamily<Todo, string>({
  key: 'todoItemState',
  default: (id) => {
    return {
      id,
      title: '',
      isDone: false,
    };
  },
});

atomFamily의 default 옵션은 다양한 형태로 사용할 수 있는데, 기본적으로 함수 형태로 작성한다. 함수의 파라미터로 팩토리 함수를 호출할 때 사용한 값을 전달할 수 있기 때문이다.

팩토리 함수를 호출할 때는 atom을 구분할 수 있는 고유한 값을 사용해야 상태의 독립을 보장할 수 있다.

const TodoComponent = (id: string) => {	
  const [todo, setTodo] = useRecoilState(todoItemState(id))
	return (
		<div>{todo.title}</div>
	)
}

default 함수에 atom을 구분할 수 있는 고유한 키 값이 전달되므로 그 값을 바탕으로 기본값을 구성할 수 있다. 특히 Recoil의 데이터 그래프는 비동기적으로 동작할 수 있기 때문에 default 함수는 Promise를 리턴하는 것도 가능하다.

default: (Parameter => T | RecoilValue<T> | Promise<T>)

const todoItemState = atomFamily<
  Todo, // 리턴 데이터 타입
  string // atomFamily 팩토리 함수 호출 파라미터
>({
  key: 'todoItemState',
  default: async (id) => {
    const data = await getTodoData(id)
    return {
      id: data.id
      title: data.title,
      isDone: data.isDone,
    };
  },
});

default에 selectorFamily를 사용하면 다른 상태를 참조하는 것이 가능하다. 예를 들어 서버 데이터가 다른 상태에 저장되어 있고, 그 상태를 사용해서 기본값을 구성할 때 유용하게 사용할 수 있다.

export const todoItemState = atomFamily<Todo, String>({
  key: 'todoItemState',
  default: selectorFamily({
    key: 'todoItemState/default',
    get: (id) => ({ get }) => {
      // 아래의 serverDataState는 recoil atom 또는 selector 
      const dataList = get(serverDataState); 
			const target = serverData.find((v) => v.id === id)
	    return  {
	      id: target.id
	      title: target.title,
	      isDone: target.isDone,
	    };
    },
  }),
});

atomFamily로 할일 상태 구현

예제이므로 여기서는 할일을 서버에도, 로컬스토리지에도 저장하지 않는 형태로 구현해보고자 한다.

atomFamily를 사용하기 위해서는 atom을 구분할 수 있는 키가 필요하다는 것을 알았다. 그러면 그 키를 관리할 수 있는 상태가 필요할 것이다.

const todoIdsState = atom<string[]>({
  key: 'todoIdsState',
  default: [],
});

만약 할일이 서버에 저장된다면 todoIdsState 는 문자열의 배열 형태가 아니라 아이디를 포함한 객체의 배열 형태로 사용할 수도 있다. 중요한 것은 고유한 아이디를 가진 데이터의 배열이어야 한다는 점이다. 그래야 그 데이터를 사용해 atomFamily를 사용할 수 있기 때문이다.

할일 상태를 관리할 atomFamily는 앞서 살펴본 것과 같다. 마찬가지로 서버 데이터를 필요하다면 default 함수에 Promise를 리턴하는 비동기 쿼리를 쓰거나 selectorFamily를 사용하면 된다.

const todoItemState = atomFamily<Todo, string>({
  key: 'todoItemState',
  default: (id) => {
    return {
      id,
      title: '',
      isDone: false,
    };
  },
});

상태는 준비가 되었다. 이제 새로운 할일을 추가하기 위해 todoIdsState에 새로운 아이디를 추가하는 컴포넌트가 필요하다.

function NewTodoForm() {
  const addTodo = useRecoilCallback(
    ({ snapshot, set }) =>
      () => {
        const todoIds = snapshot.getLoadable(todoIdsState).getValue();
        set(todoIdsState, [...todoIds, uuid()]);
      },
    [],
  );

  return (
    <button type="button" onClick={addTodo}>
      Add New Item
    </button>
  );
}

export default TodoInputForm;

여기서는 useRecoilCallback을 사용했다. useRecoilState를 사용해도 되지만 저 훅을 사용하면 컴포넌트에서 todoIdsState 상태의 업데이트를 구독하지 않게 된다는 장점이 있다.

이제 할일 아이디 목록을 컴포넌트 목록으로 맵핑해준다.

function TodoList() {
  const todoIdList = useRecoilValue(todoIdsState);

  return (
    <ul>
      {todoIdList.map((id) => {
        return <TodoItem key={id} id={id} />;
      })}
    </ul>
  );
}
export default TodoList;

TodoItem에 atomFamily에 사용할 id를 props로 전달했다. 할일 컴포넌트에서 이렇게 전달된 id로 atomFamily 팩토리 함수를 호출하여 상태를 만든다. 아래의 예제 코드에서는 할일의 제목(title 필드)을 업데이트하는 기능만 작성해 두었다.

interface Props {
  id: string;
}

const TodoItem: React.FC<Props> = ({ id }) => {
  const [todo, setTodo] = useRecoilState(todoItemState(id));

  const handleChangeTodoTitle = useCallback(
    (title: string) => {
      setTodo({
        ...todo,
        title,
      });
    },
    [todo],
  );

  return (
    <li>
      <input
        type="text"
        value={todo.title}
        onChange={(e) => handleChangeTodoTitle(e.target.value)}
        placeholder={'new todo'}
      />
    </li>
  )
};

export default React.memo(TodoItem);

React.memo를 사용하여 TodoItem 을 래핑해두면 새로운 할일이 추가되어도 이미 렌더링된 컴포넌트를 다시 렌더링하지 않는다. 전달하는 props가 id 1개인데다 문자열이기 때문에 다른 할일이 삭제, 추가되어도 memoization이 적용될 것임을 쉽게 추측할 수 있다.

만약 처음 살펴본 것처럼 atomFamily를 사용하지 않고 todoListState 에 할일 객체 배열을 저장하는 방식을 사용한다면 새로운 할일이 추가될 때마다 모든 TodoItem 컴포넌트가 다시 렌더링된다. 아래와 같은 방식으로 업데이트하면 새로운 배열이 생성되며 객체의 레퍼런스도 모두 바뀌기 때문이다.

const addTodo = () => {
	setTodoList([...todoList, { id: uuid(), title: '', isDone: false }])
}

렌더링 방지를 위해서는 배열에 포함된 객체의 불변성이 보장되도록 해야 한다. 또는 객체의 데이터를 여러 props에 분할해서 제공하거나(레퍼런스 변경이 없는 literal 데이터만 전달되도록) React.memo의 두번째 파라미터에 전달할 비교 함수를 직접 구현해야 할 것이다. 이런 점을 따져보면 atomFamily를 사용한 상태 관리는 다른 atom을 신경쓸 필요가 없는 단순함이 있으며, 최적화에도 도움이 된다는 사실을 확인할 수 있다.

참고자료

Tailwind CSS의 설치와 활용

rhostem — Sat, 05 Jun 2021 00:00:00 GMT

이 글은 Tailwind CSS v2를 기준으로 작성되었습니다.

Tailwind CSS의 특징

Tailwind CSS는 유틸리티 퍼스트(Utility-first)를 지향하는 CSS 프레임워크다. CSS를 작성하는 방법론 중 하나인 BEM은 마크업을 컴포넌트 단위로 구분하고 상태에 따라 스타일을 변경하는 식으로 재활용할 수 있도록 한다.

<button className="button button--success">
	<span className="button-label">Submit</span>
</button>

.button {
	display: inline-block;
	border-radius: 3px;
}
.button-label {
	font-weight: bold;
}
.button--success {
	color: #FFF;
	border-color: #4A993E;
}
.button--danger {
	color: #900;
}

하지만 유틸리티를 우선하는 CSS 프레임워크는 클래스와 스타일을 새로 작성하지 않는다. 레이아웃, 포지션, 스페이스, 컬러, 폰트 등 스타일링에 필요한 대부분의 속성이 수많은 클래스로 사전 정의되어 있고, 사용자는 그 클래스들을 조합해서 사용한다.

.inline-block {
	display: inline-block;
}
.rounded {
	border-radius: 0.25rem;
}
.p-4 {
	padding: 1rem;
}

<button className='inline-block rounded p-4'>
	Submit
</button>

CSS를 유틸리티 클래스 기반으로 사용할 때의 장점은 다음과 같다.

컴포넌트를 작성할 때 CSS 클래스 이름을 고민할 필요가 없다.
컴포넌트의 수가 늘어나도 CSS 파일의 사이즈는 크게 늘어나지 않는다.
복잡한 구조의 클래스+태그 셀렉터를 사용하지 않기 때문에 버그 발생 가능성이 낮고 수정이 쉽다.

클래스를 여러 개 붙이는 것에서 인라인 스타일과 다를게 없다거나, className 속성이 너무 길어지지 않느냐고 말할 수도 있다. 하지만 다음과 같은 장점도 있다.

사전 정의된 디자인 시스템을 기반으로 클래스를 생성하기 때문에 컬러, 사이즈, 간격에서 디자인 일관성을 유지할 수 있다.
반응형 유틸리티 클래스(ex. md:p-4)를 사용해서 미디어 쿼리를 쉽게 적용할 수 있다.
hover, focus 등 여러가지 상태를 위한 스타일(ex. hover:font-bold)을 쉽게 추가할 수 있다. 인라인 스타일에서는 hover등의 상태 선택자를 사용할 수 없다.

그리고 Tailwind CSS는 기본 제공하는 클래스 외에도 사용자가 직접 테마를 확장하고, 유틸리티 클래스를 추가할 수 있다. 그래고 반복되는 마크업과 스타일은 새로운 클래스를 추가하는 것보다 컴포넌트 모듈로 분리하는 것을 권장한다.

클래스 자동완성을 위한 Tailwind CSS Intellisense

사용 가능한 클래스가 수백개가 넘기 때문에 처음 접하는 사람이나 조금 익숙해진 사람이나 그 많은 클래스를 모두 외운 상태로 사용하기는 어렵다. 그리고 className 속성이 길어지면 같은 속성을 설정하는 유틸리티 클래스가 중복되어(ex. display 속성을 설정하는 flex, block 클래스) 버그를 발생시킬 수도 있다. 그래서 Tailwind CSS는 Visual Studio Code의 확장 프로그램으로 Tailwind CSS IntelliSense를 제공하고 있다.

컬러 유틸리티는 좌측에 색상까지 표시해 준다 👍

확장 프로그램을 사용하면 에디터 안에서 유틸리티 클래스 자동완성을 제공하며 충돌하는 클래스도 체크해 준다. 그리고 단순히 기본 제공하는 클래스의 자동 완성만 지원하는 것이 아니라 사용자가 직접 설정한 클래스도 확장 프로그램이 인식하여 자동완성에 제공해 준다.

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      spacing: {
        xs: defaultTheme.spacing[2],
        sm: defaultTheme.spacing[3],
			}    
    }
	}
}

위와 같이 테마 확장으로 spacing 을 추가하면 p-4 같은 기본 클래스 뿐만 아니라 p-xs, p-sm 처럼 간격에 관련된 모든 유틸리티 클래스에 suffix로 형태로 추가된다.

그리고 클래스네임이 대부분 어떤 속성을 설정하는지 유추하기 쉽게 만들어져 있어서 레퍼런스를 찾아보면서 파악하면 큰 어려움은 없다. 그리고 이런 프레임워크는 사용하면 사용할수록 작업 속도가 빨라진다는 장점이 있다.

Tailwind CSS 설치

Installation - Tailwind CSS

Tailwind CSS는 PostCSS를 기반으로 한다. 유틸리티 클래스를 생성하기 위해서 필요한 사항은 다음과 같다.

npm 모듈
- TailwindCSS
- PostCSS
- Autoprefixer
- postcss-cli
설정 파일
- tailwind.config.js
- tailwind.css (postcss로 처리할 파일. 이름은 상관없음)
- postcss.config.js

여기서는 postcss-cli를 사용해서 스타일시트를 직접 생성한 후 앱의 entry 모듈에서 import하는 방식을 사용할 것이다. 만약 webpack을 사용한다면 style-loader, css-loader와 함께 postcss-loader를 사용하면 된다.

PostCSS 설정 파일

// postcss.config.js
module.exports = {
  plugins: [require('tailwindcss'), require('autoprefixer')],
};

Babel의 .babelrc 파일처럼 프로젝트 루트에 PostCSS 설정 파일이 있으면 postcss-cli, webpack postcss-loader에서 모두 활용이 가능하다.

Tailwind 설정 파일

// tailwind.config.js
module.exports = {
  purge: [],
  darkMode: false, 
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

프로젝트 루트에 추가해 준다. 더 자세한 내용은 Configuration 문서에서 확인이 가능하다.

베이스 CSS 파일

// src/tailwind.css
@tailwind base;
@tailwind components;
@tailwind utilities;

@tailwind 라는 키워드는 postcss.config.js 파일의 플러그인 설정에 require('tailwindcss')를 추가했기 때문에 사용 가능한 것이다. 위의 코드를 추가하면 PostCSS가 tailwindcss 플러그인과 tailwind.config.js 파일을 참조하여 유틸리티 클래스들을 만들어준다.

CSS 파일 변환 npm 스크립트 추가

// package.json
{
	"scripts": {
    "tw:watch": "TAILWIND_MODE=watch NODE_ENV=development postcss ./src/tailwind.css -o ./src/tailwind_out.css -w",
		"tw:build": "NODE_ENV=production postcss ./src/tailwind.css -o ./src/tailwind_out.css/"
	}
}

tw:watch 스크립트를 실행하면 postcss-cli가 tailwind.css 파일을 읽어서 tailwind_out.css 파일을 생성한다. 그리고 후술할 JIT 모드를 사용하기 위해 소스 코드에 변경이 있을 때 tailwind_out.css 파일이 업데이트되도록 watch 옵션을 함께 설정했다.

tw:build 스크립트는 앱 배포를 위해 빌드를 할 때 사용할 것이다. production 모드에서 CSS 속성에 autoprefixer 모듈을 사용해서 벤더 프리픽스(vendor prefix)를 붙여주기 위해서는 browserslist 설정 파일이 필요하다. 프로젝트 루트에 .browserslistrc 파일을 추가해도 되고, package.json에 추가해도 된다.

// package.json
{
	"browserslist": {
    "production": [">0.2%", "not dead", "not op_mini all"],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
}

개발 모드에서는 주요 브라우저의 최신 버전에만 맞추지만, production 모드에서는 거의 모든 브라우저를 지원하게 했으므로 필요한 대부분의 벤더 프리픽스가 추가된다.

앱에서 생성된 스타일시트 가져오기

// src/index.tsx
import React from 'react';
import ReactDOM from 'react-dom';
import './tailwind_out.css'; // compiled tailwind stylesheet

const Index = () => {
  return (
    <div>index</div>
  );
};

export default Index;

React 앱의 루트 컴포넌트에서 스타일시트를 불러오도록 했다. 사용하는 번들러에 따라 CSS 파일을 import하기 위해 추가적인 설정이 필요할 수 있다.

개발 서버 실행 스크립트

postcss-cli로 watch 모드를 사용한다면 개발 서버도 동시에 실행해야 하므로 concurrently를 사용한다.

// package.json
{
	"scripts": {
		"dev": "개발 서버 실행", 
    "start": "concurrently \"yarn:tw:watch\" \"yarn:dev\"",
	}
}

Storybook 설정

Storybook에서 Tailwind CSS 로 생성한 스타일시트를 사용하려면 위에서 설정한 postcss-cli를 사용해도 된다. 하지만 Storybook 서버는 Webpack 기반이므로 실행되므로 @storybook/addon-postcss 모듈을 사용하는 편이 더 간단하다.

// .storybook/main.js
module.exports = {
  stories: ['../src/**/*.stories.@(js|jsx|ts|tsx)'],
  addons: [
    '@storybook/addon-postcss', 
  ],
}

// .storybook/preview.js
import '../src/tailwind.css';

Tailwind CSS 활용

JIT(Just-in-Time Mode) 모드

Tailwind CSS 2.1 이상에서 지원하는 기능으로 스타일시트를 개발 서버가 실행되기 전 생성해두는 것이 아니라 소스 파일 변경을 탐지하면서 HTML, 컴포넌트에서 사용하는 클래스만 스타일시트에 추가하도록 한다. 이 기능을 필요한 클래스만 추가되므로 스타일시트 사이즈를 크게 줄일 수 있다.

비슷한 기능으로 사용하지 않는 유틸리티를 스타일시트에서 제거하는 purge 옵션을 제공하고 있었는데 이것은 production 모드에서만 사용 가능하다. JIT 모드는 이 기능을 개발 모드에서도 사용 가능하도록 확장한 것이라 할 수 있다.

테마 확장

앞서 잠깐 살펴봤지만 Material-UI에서도 가능한 것처럼 기본 테마를 확장할 수 있다. 기존 값을 덮어쓸 수도 있고, 새로운 속성을 추가할 수도 있다.

기본 테마 객체가 어떻게 구성되었는지는 아래 파일에서 확인 가능하다.

https://unpkg.com/browse/tailwindcss@2.1.2/stubs/defaultConfig.stub.js

Variants

hover:, focus: 등의 프리픽스는 모든 CSS 속성을 지원하지 않으며 backgroundColor, opacity 등의 일부 속성에만 사용할 수 있도록 설정되어 있다. 모든 속성을 지원하면 유틸리티 클래스 수가 너무 늘어날 것이고 자연히 스타일시트 파일의 덩치도 커질 것이기 때문이다. 기본 제공하는 속성 외의 다른 속성에 variants를 조합하려면 추가 설정이 필요하다.

// tailwind.config.js
module.exports = {
  variants: {
    fill: [],
    extend: {
      borderColor: ['focus-visible'],
      opacity: ['disabled'],
    }
  },
}

다크 모드

Tailwind CSS에서 다크 모드는 테마에서 설정하는 방식이 아니라 dark: 프리픽스가 붙은 클래스로 스타일을 직접 추가하는 방식이다. Material-UI는 ThemeProvider에 테마 객체를 전달할 수 있어서 컬러 모드에 따라 테마를 통째로 교체할 수 있는데, 그에 비하면 조금 불편한 방식이라 할 수 있다. Tailwind CSS에서 다크 모드를 사용하기 위해서는 컴포넌트 모듈화가 철저하게 이뤄져야 반복 작업을 줄일 수 있을 것이다.

<div class="bg-white dark:bg-gray-800">
  <h1 class="text-gray-900 dark:text-white">Dark mode is here!</h1>
  <p class="text-gray-600 dark:text-gray-300">
    Lorem ipsum...
  </p>
</div>

Tailwind CSS 2의 Postcss 7 호환 버전 설치

Tailwind CSS 2는 PostCSS 버전 8을 기본으로 사용한다. 하지만 PostCSS 8은 배포된지 얼마 되지 않았기 때문에 아직 반영하지 않은 라이브러리들이 많다. 특히 Webpack 4에서는 PostCSS 8을 사용할 수 없기에 Webpack 5를 설치해야 한다. 그래서 PostCSS 7로 Tailwind CSS 2 를 사용할 수 있는 방법을 제공하고 있다.

https://tailwindcss.com/docs/installation#post-css-7-compatibility-build

@storybook/react의 최신 릴리즈 버전(2021.06 기준 6.2)은 Webpack 4를 사용하기 때문에 위의 링크에 있는 방법을 적용할 필요가 있다.

Twin 라이브러리로 CSS-in-JS 스타일로 사용하기

styled-components나 emotion에 익숙한 사람이라면 선호할 만한 방법이다. css 함수를 사용하면 template literal 안에 직접 CSS를 작성하면서 Tailwind CSS의 클래스도 조합할 수 있다.

import tw, { css } from 'twin.macro'

const hoverStyles = css`
  &:hover {
    border-color: black;
    ${tw`text-black`}  }
`
const Input = ({ hasHover }) => (
  <input css={[tw`border`, hasHover && hoverStyles]} />
)

Tailwind CSS는 대부분의 스타일을 유틸리티 클래스로 추가할 수 있지만, :nth-child(n) 처럼 유틸리티 클래스로 만들기 어려운 선택자는 지원하지 않는다(:first-child, :last-child는 지원함). 이처럼 클래스로 추가하기 어려운 스타일링은 스타일시트를 직접 작성해야 하는데, 이 방법을 사용하면 Tailwind의 유틸리티 클래스도 그대로 활용할 수 있다.

Tailwind CSS 유저 커뮤니티

tailwindcomponents.com에서 Tailwind CSS를 기반으로 만든 컴포넌트를 공유하고 있다. 독립된 컴포넌트 뿐만 아니라 하나의 완성된 페이지 형태의 작업물도 공유되고 있으니 참고하면 좋을 것이다.

Tailwind CSS는 유틸리티 클래스만 제공하기 때문에 다른 CSS 프레임워크처럼 사전 정의된 스타일과 기능을 가진 컴포넌트를 바로 사용할 수는 없다. 하지만 필요한 기능만 가진 가벼운 컴포넌트를 직접 구현해서 사용하는 쪽을 선호한다면 좋은 선택이 될 것이다. 특히 테스트 케이스 작성도 그렇지만, 유틸리티 클래스를 활용하는 것도 사용할 수록 작성 속도가 빨라지는 것을 실제로 사용하면서 경험할 수 있었다.

linear-gradient 속성에 transition 적용하기

rhostem — Wed, 12 May 2021 00:00:00 GMT

블로그를 호스팅하고 있는 Vercel 서비스의 웹사이트를 방문했다가 멋진 CSS 기술을 보게 되었다. 텍스트에 linear gradient를 사용해서 컬러를 입히고, 거기에 일정한 간격을 두고 차례대로 transition 효과를 주고 있었다.

3개의 단어와, 컬러, 애니메이션 효과만으로 서비스의 핵심을 아주 효과적으로 설명해주고 있지 않은가?

개발 도구로 확인해 보니 GIF 이미지나 canvas를 사용한 효과는 아니었고 HTML span 태그로 추가한 텍스트와 CSS로 구성되어 있었다. 단순히 linear gradient를 사용한 텍스트라면 모르겠는데, 애니메이션까지 적용되어 있으니 한번 카피해 보면 좋겠다는 생각이 들었다.

Linear gradient를 사용한 텍스트

CSS linear-gradient 속성은 기본적으로 백그라운드 컬러를 지정하기 위한 속성이다. 시작점, 종료점에 지정할 2개의 색상이 기본적으로 필요하며 중간 지점에 들어갈 컬러는 더 많이 추가할 수도 있다. 색이 변화하는 각도도 지정할 수 있는데, 예를 들어 to left 값은 좌에서 우로 컬러가 변화한다.

background-image: linear-gradient(to right, red, blue); /* 왼쪽 끝은 빨강, 오른쪽 끝은 파랑 */
background-image: linear-gradient(red, blue); /* 각도가 생략되면 to bottom */
background-image: linear-gradient(to right, red, yellow, blue); /* 중간 컬러를 넣을 수 있다. */
background-image: linear-gradient(45deg, red, yellow 40%, blue) /* 각도, 컬러의 위치도 지정 가능하다. */

그리고 linear-gradient는 기본적으로 background-image 속성에 지정하는 값이다. background 속성에도 할당될 수 있지만 background 는 여러가지 백그라운드 관련 속성(background-color, background-repeat, background-position 등)을 조합해서 사용하는 값이므로 별도로 지정하는 편이 CSS 버그를 방지하는데 도움이 된다.

백그라운드 컬러, 이미지를 텍스트에 적용하기

background-clip CSS 속성을 사용하면 배경이 컨텐츠 박스 중에서 어디까지 차지할지 결정할 수 있다. box-sizing 속성에 사용하는 border-box, content-box가 아닌 text 속성을 사용하면, 백그라운드 컬러, 이미지가 텍스트 위에만 입혀진다. 그리고 텍스트 컬러는 투명으로 지정해야 한다.

background-color: linear-gradient(to right, red, blue);
-webkit-background-clip: text;
color: transparent;

이렇게 하면 텍스트에 그래디언트 컬러가 적용된 멋진 텍스트를 표현할 수 있게 된다.

linear gradient에 transition 효과 설정

CSS transition 속성으로 엘레멘트의 위치, 크기, 컬러 등이 변경될 때 부드러운 전환 효과를 넣을 수 있다. 하지만 일반적인 백그라운드 컬러와 달리, linear-gradient 를 사용한 백그라운드 컬러에는 transition 속성의 timing function(ex. linear) 값이 적용되지 않는다. 다시 말해 중간 단계 없이 색깔이 빨강에서 파랑으로 바로 바뀌어버리는 것이었다.

그래서 여기서는 트릭을 사용해야 한다.

부모 요소(ex. div, span)에 텍스트를 추가한다.
부모 요소의 의사 요소(pseudo-element, ex. ::before)에 CSS 속성들을 추가한다.
- content 속성에 부모 요소에 입력한 것과 동일한 텍스트를 입력한다.
- linear-gradient를 사용해 컬러를 입힌다.
- absolute 포지션을 사용해 부모 요소의 텍스트와 크기, 포지션이 완전히 겹치도록 만든다.
- opacity 값을 0으로 둔다.
- transition 속성에 opacity 값이 변할 때 전환 효과가 발생하도록 설정한다.
- z-index 값은 부모 요소의 값보다 커야 한다. 그래야 의사 요소의 opacity 값을 1로 변경했을 때 의사 요소가 먼저 보이게 된다.

<span class="gradientText">HTML</span>

.gradientText {
  position: relative;
  z-index: 1;
  background-image: linear-gradient(to right, #000, #000); 
  -webkit-background-clip: text;
  color: transparent;
}

.gradientText::before {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  z-index: -1;
  content: "HTML"; 
  background-image: linear-gradient(to right, #007cf0, #00dfd8); 
  transition: opacity 0.5s linear;
  opacity: 0;
  -webkit-background-clip: text;
}

/* 이 클래스를 추가하면 텍스트에 컬러가 추가된 의사 요소의 텍스트가 보이게 된다. */
.transitionOn::before {
  opacity: 1;
}

정리하면 의사 요소에 부모와 똑같은 텍스트를 지정하고 컬러를 입힌 후, opacity 값으로 전환 효과를 주는 것이다. 의사 요소의 opacity 값이 0에서 1로 바뀌는 과정에서 마치 부모 요소의 텍스트 컬러가 전환되는 것처럼 보이는 효과를 준다.

자바스크립트로 transition 실행

이제 스타일은 준비가 되었으니 마크업을 추가하고 자바스크립트로 setTimeout과 setInterval을 조합해 클래스를 일정한 주기에 맞춰 붙였다 떼었다 하는 작업만 해주면 된다.

결과물

See the Pen linear gradient text by rhostem (@rhostem) on CodePen.

References

Mock Service Worker로 만드는 모의 서버

rhostem — Sat, 20 Mar 2021 00:00:00 GMT

Mock Service Worker

MSW(=Mock Service Worker)는 API 모킹(mocking) 라이브러리로, 서버를 향한 네트워크 요청을 가로채서(intercept) 모의 응답(mocked response)을 내려주는 역할을 한다. 이 라이브러리의 장점은 사용자가 정의한 모킹 핸들러를 테스트를 위한 노드(node.js) 환경, 개발과 디버깅을 위한 브라우저 환경에서 모두 사용할 수 있다는 것이다. 이미 구현된 소스 코드를 수정할 일은 없으며, 모킹이 필요한 환경에서만 MSW 인스턴스를 실행해주기만 하면 된다.

MSW가 작동하는 방식

브라우저에 서비스 워커(Service Woker)를 등록하여 fetch 이벤트를 사용해 외부로 나가는 네트워크 리퀘스트를 감지한다. 그리고 그 요청을 실제 서버가 아닌 MSW 클라이언트 사이드 라이브러리로 보낸 후, 등록된 핸들러를 통해 모의 응답을 브라우저로 보낸다. 네트워크 요청 흐름은 아래와 같다.

Mock Service Worker 리퀘스트 흐름도 (이미지 출처: https://mswjs.io/docs/)

서비스 워커는 브라우저에서만 사용 가능하기 때문에 노드 환경에서는 node-request-interceptor로 네이티브 http, https, XMLHttpRequest 모듈을 확장(extending)해서 리퀘스트를 처리한다.

일반적인 모킹 방식

두 가지 방법을 사용한다.

실제 서버를 대체하는 모킹 서버의 제공
네트워크 요청을 가로채기 위해 네이티브 http, https, XMLHttpRequest 모듈을 스텁(stub, 바꿔치기)

모킹 서버는 실제 서버와 다른 방식으로 구현되고 동작하기 때문에 실제 서버를 완전히 대체할 수 없다. 목 서버 구현, 실행 및 관리 외에도 목 서버에서만 다르게 동작하는 버그 때문에 기존 코드를 수정해야 하는 일도 생길 수 있다.

그리고 스텁은 모킹 서버를 구동하는 것보다는 효율적이긴 하다. 하지만 네이티브 모듈을 수정하게 되면 모킹을 하지 않은 환경과 어쨌거나 차이를 만들어내기 때문에 종단간(end-to-end) 테스트에는 좋지 않다.

MSW는 모킹 서버를 사용하지 않고 네이티브 라이브러리를 스텁하지 않는다(Service Worker를 사용할 수 없는 노드 환경에서는 nock 라이브러리처럼 http같은 네트워크 모듈을 monkey patching하는 방식으로 구현한다). 그리고 다른 모킹 라이브러리와 달리 어플리케이션 레벨이 아닌 네트워크 레벨에서 리퀘스트를 가로채서 응답을 보내기 때문에 별도의 설정 없이도 axios, react-query등의 모든 종류의 네트워크 요청 라이브러리와 네이티브 fetch API를 사용할 수 있다는 장점이 있다.

사용 방법

로그인을 위해 서버의 /user 라우트에 HTTP POST 요청을 보낸다고 가정하자. MSW는 네트워크 요청을 처리하기 위해 rest[METHOD] 함수로 핸들러를 정의한다. 여기서는 POST 요청이므로 rest.post 함수를 사용한다.

// handlers.js
import { rest } from 'msw';

export const loginHandler = rest.post(
  'https://api.server.com/user',
  (req, res, ctx) => {
    return res(ctx.json({
			jwt: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c'
		));
  },
);

핸들러 함수의 첫번째 파라미터인 리퀘스트 엔드포인트에는 express 서버처럼 파라미터를 사용할 수 있다(ex. /user/:id). 상세정보 API가 라우트에 고유 아이디를 포함하고 있을 때 유용하다. 핸들러의 두번째 파라미터인 콜백 함수(=response resolver)에서 라우트 파라미터에 접근하는 것도 물론 가능하다.

정의한 핸들러로 워커 인스턴스를 생성한다.

import { setupWorker } from 'msw' // node 환경에서는 setupServer 모듈을 대신 사용
import * as handlers from './handlers'

export const worker = setupServer(...handlers)

이제 서버 인스턴스를 실행하면 된다.

worker.start()

실제 환경별 사용 방법은 아래 링크를 통해 확인할 수 있다.

https://mswjs.io/docs/getting-started/integrate

활용 사례

브라우저 서비스 워커에 등록하기

https://mswjs.io/docs/getting-started/integrate/browser

브라우저에서 사용하기 위해서는 MSW를 서비스 워커에 등록하는 과정이 필요하다. 고맙게도 그 과정은 MSW 라이브러리에서 직접 제공한다. 커맨드 라인에서 아래의 명령어를 실행하면 서비스 워커 등록을 위한 파일이 public 폴더에 추가된다.

npx msw init public/ --save

public은 웹 서버가 호스팅하는 폴더로 index.html 파일이 있는 곳을 가리킨다. 보통 build, public, dist 등의 이름을 사용하는데 create-react-app, next.js를 사용하고 있다면 프로젝트 소스 최상위에 있는 public 폴더가 그것에 해당한다.

이제 앱의 소스에 워커를 실행하는 코드를 추가한다.

// src/index.js
import React from 'react'
import ReactDOM from 'react-dom'
import App from './App'

// 개발 환경에서만 실행되도록 환경 변수를 확인하는 과정이 필요하다.
if (process.env.NODE_ENV === 'development') {
  const { worker } = require('./mocks/worker')
  worker.start()
}

ReactDOM.render(<App />, document.getElementById('root'))

이제 개발 서버에서 실행된 앱이 서버에 리퀘스트를 보낼 때 실제 서버가 아닌 MSW에서 응답을 보낼 수 있게 되었다.

Jest를 사용하는 테스트 환경에서 사용하기

https://mswjs.io/docs/getting-started/integrate/node

모든 테스트 케이스에서 msw가 동작하도록 전역에 설정하는 방법과 테스트 케이스마다 직접 설정하는 방법이 있다.

전역 설정

Jest 설정에서 setupFilesAfterEnv에 할당한 모듈의 코드는 각각의 테스트 파일을 실행하기에 앞서서 먼저 실행된다.

// jest.config.js
module.exports = {
  setupFilesAfterEnv: ['./jest.setup.js'],
}

이제 jest.setup.js 파일에 모의 서버를 설정하는 코드를 작성하면 된다. 테스트는 node 환경에서 실행할 것이므로 setupWorker 대신 setupServer 함수를 사용해야 한다.

// jest.setup.js
import { setupServer } from 'msw/node'
import * as handlers from './handlers'

const server = setupServer(...handlers)

// 테스트 시작 전에 서버를 실행한다.
beforeAll(() => server.listen())

// 테스트가 끝날 때마다 리퀘스트 핸들러를 초기화하여 서로 영향을 미치지 않도록 한다.
afterEach(() => server.resetHandlers())

// 테스트가 완료되면 서버를 종료한다.
afterAll(() => server.close())

테스트 케이스에 직접 설정

테스트 파일에서 서버 인스턴스를 만드는 것 외에 전역 설정과 큰 차이는 없다. 테스트에 필요한 핸들러만 추가하면 된다는 장점이 있다.

import { setupServer } from 'msw/node'
import { listRequestHandler, detailRequestHandler } from './handlers'

describe('sample test suite', () => {
  const server = setupServer(
		listRequestHandler,
		detailRequestHandler,
  );

	beforeAll(() => server.listen())

	afterEach(() => server.resetHandlers())

	afterAll(() => server.close())

	test('check response of mock server', () => {
     // write test
	})
})

쿼리 파라미터 가져오기

https://mswjs.io/docs/recipes/query-parameters

테스트마다 리퀘스트 파라미터에 따라 다른 리스펀스를 보내줘야 하는 경우가 있다. 핸들러에서 req 객체를 통해 파라미터에 접근 가능하다.

export const productDetailHandler = rest.get('/products', (req, res, ctx) => {
  const id = req.url.searchParams.get('id');

  return res(ctx.json({ productId: id }));
});

Response patching

https://mswjs.io/docs/recipes/response-patching

모의 응답(mocked response)를 실제 리퀘스트의 응답에 기반한 데이터로 구성할 수도 있다. 핸들러에서 실제 서버에 리퀘스트를 보낸 후 받은 데이터에 디버깅 등에 필요한 정보를 임의로 덧붙이는 방식이다.

아래는 Github API를 사용한 리스펀스 패칭 예제다.

import { setupWorker, rest } from 'msw'

const worker = setupWorker(
  rest.get('https://api.github.com/users/:username', async (req, res, ctx) => {
    // msw 핸들러에 가로챈 리퀘스트 정보로 살제 서버에 요청을 보낸다.
    // msw에서 정의한 핸들러에 매칭되는 것을 방지하기 위해 window.fetch가 아닌 ctx.fetch를 대신 사용한다.
    const originalResponse = await ctx.fetch(req)
    const originalResponseData = await originalResponse.json()

    return res(
      ctx.json({
        location: originalResponseData.location,
        firstName: 'Not the real first name', 
      }),
    )
  }),
)

worker.start()

React Query로 서버 상태 관리하기

rhostem — Mon, 01 Feb 2021 00:00:00 GMT

React Query는 서버 상태(server state)를 관리하는 라이브러리다. 서버 상태란

원격에 위치한 공간에 저장되며 앱이 소유하거나 제어하지 않는다
데이터를 가져오고 업데이트하기 위해선 비동기 API가 필요하다
다른 사람과 함께 사용하며, 내가 모르는 사이에 업데이트될 수 있다
앱에서 사용하는 데이터가 “유효 기간이 지난” 상태가 될 가능성을 가진다.

예를 들어 쇼핑몰의 상품 목록, 게시판의 댓글, 배달앱의 주문 진행 상황 등은 모두 위와 같은 특성을 가지고 있다. 그렇기에 다음과 같은 작업에 대한 필요가 생긴다.

캐싱
서버 데이터 중복 호출 제거
만료된 데이터를 백그라운드에서 제거하기
데이터가 언제 만료되는지 알고 있기
만료된 데이터는 가능한 빨리 업데이트하기
페이지네이션, 레이지 로딩 데이터의 성능 최적화
서버 상태의 메모리 관리 및 가비지 콜렉션
쿼리 결과의 구조 공유를 통한 메모이제이션

이러한 기능들이 없어도 앱을 구현할 수 있다. 하지만 높은 품질의 앱을 위해서는 필요한 작업이라 할 수 있다. React Query는 위와 같은 기능을 사용할 수 있도록 도와준다.

도입할 필요가 있는가?

위에서 제공하는 기능만 본다면 사용하면 좋을 것 같다. 하지만 새로운 라이브러리의 도입은 항상 신중히 결정해야 한다.

상태 관리 라이브러리에서 요구하는 boilerplate 코드 제거

React Query를 사용한다면 서버 데이터 처리 방식을 바꿔야 한다. React에서는 보통 redux, mobx같은 상태 관리 라이브러리를 사용하며, 그것으로 서버 상태를 관리하는 방식이 일반적이다. Redux를 사용하고 있다면 redux-thunk, redux-observable, redux-saga 등의 미들웨어를 사용해 서버 데이터 요청 액션이 들어오면 API를 호출하여 redux 상태를 업데이트하는 방식을 사용한다.

import { filter, map, mergeMap } from 'rxjs/operators';
import { ajax } from 'rxjs/ajax';

// redux-observable 예제
// SAMPLE_DATA_REQUEST 타입의 액션을 받아서 API 호출 후 리스펀스를 담은 액션으로 맵핑하는 epic
const sampleAsyncEpic = (action$) => {
	return action$.pipe(
		filter(action => action.type === 'SAMPLE_DATA_REQUEST'),
		mergeMap(action => 
			ajax.getJSON(`https://api.server.com/samples`).pipe(
		    map(response => ({ type: 'SAMPLE_DATA_RESPONSE', response }))
		  )
		)	
	)
}

하지만 React Query는 기본적으로 함수형 컴포넌트 안에서 훅 형태로 사용하며 굳이 서버 상태를 다른 장소에 저장할 필요가 없다.

import { useQuery } from 'react-query';

function Example() {
  const { isLoading, error, data, isFetching } = useQuery('repoData', () =>
    fetch(
      'https://api.github.com/repos/tannerlinsley/react-query'
    ).then((res) => res.json())
  );

  if (isLoading) return 'Loading...';

  if (error) return 'An error has occurred: ' + error.message;

  return (
    <div>{JSON.stringify(data)}<div>
  );
}

필요에 따라 서버 데이터를 현재 컴포넌트에서 멀리 떨어진 컴포넌트 트리에 전달할 필요가 생길 수도 있다. 하지만 서버 상태는 그 데이터를 가져온 컴포넌트와 1~2단계 아래의 하위 컴포넌트(ex. 목록의 아이템 컴포넌트)에서 사용하는 경우가 대부분이다. 즉, 서버 데이터 처리와 관련된 redux 액션, 리듀서, 미들웨어 코드를 작성할 필요가 없어진다. Redux는 훌륭한 상태 관리 기능을 제공하지만, 동시에 많은 양의 boilerplate 코드라는 피로감도 제공하고 있기에 주목할 필요가 있다.

하지만 상태 관리 라이브러리를 사용해서 서버 데이터를 제어하는 쪽을 더 선호한다면 React Query는 도입하지 말거나 앱에서 꼭 필요한 부분에만 사용하는 편이 좋을 것이다.

캐싱 & 리프레쉬

채팅 앱처럼 소켓 통신을 사용한다면 서버 상태가 즉시 업데이트되겠지만 그렇지 않다면 주기적으로 업데이트해주는 기능을 직접 구현해야 한다. React Query는 useQuery 훅의 파라미터를 통해 API 데이터의 만료 시간, 리프레쉬 간격, 데이터를 캐시에서 유지할 기간, 브라우저 포커스시 데이터 리프레쉬 여부, 성공 or 에러 콜백 등 다양한 기능을 제어할 수 있다.

예를 들어 앱 안에 게시판이 있다고 가정하자. 다음과 같은 시나리오가 가능하다.

게시글 필터에서 사용하는 옵션은 서버에서 변경될 가능성이 낮으므로 만료 시간을 무한(Infinity)으로 설정하여 API 추가 호출을 방지할 수 있다.
게시글 목록의 만료 시간을 1분으로 설정하여 유저가 페이지 번호를 1에서 2로 반복해서 바꾸는 등의 행동을 취하더라도 API 중복 호출을 방지할 수 있다.
게시글 목록의 만료 시간이 1분으로 설정되어 있는데 어떤 사용자는 게시글을 그 시간 안에 작성하거나 수정할 수도 있다. 그래서 게시글 작성 후에는 캐시를 강제로 무효화(invalidate)하여 목록을 새로고침한다.
사용자가 게시글의 제목을 수정한 후 목록으로 돌아갔을 때 API 호출을 통해 게시글 목록을 서버에서 다시 가져온 후에야 수정 사항이 반영되었음을 확인해줄 수 있다. 하지만 React Query에서는 수정 성공시 캐시되어 있는 게시글 제목을 임시로 변경하여 사용자에게 서버에 다시 요청한 게시글 목록의 응답이 즉시 온 것처럼 보이게 만들 수 있다.
- 게시글 수정 후 목록 새로고침에 딜레이가 전혀 없는 듯한 사용자 경험을 제공할 수 있다.
- 실제 API 호출 및 데이터 업데이트는 백그라운드에서 진행되며 에러 발생시 원래 데이터로 복구시킬 수 있다.
- Optimistic update 참조
브라우저의 다른 탭을 보다가 다시 열었을 때 게시글 목록을 자동으로 불러오게 할 수 있다.

캐싱 관련 기능은 처음 언급한대로 구현되어 있지 않아도 앱 사용하는 데는 문제가 없다. 하지만 클라이언트에서 사용하는 서버 데이터의 종류와 양이 늘어나고 서버에서 관리하고 있는 데이터의 양도 늘어난다면 양쪽 모두의 작업 처리량을 줄일 필요가 자연스럽게 생긴다. 또 더 좋은 사용자 경험을 구현하는데도 도움을 준다.

React Query 사용 방법

React Query를 통해 관리하는 쿼리 데이터는 라이프사이클에 따라 fetching, fresh, stale, inactive, delete 상태를 가진다.

fetching - 요청 중인 쿼리
fresh - 만료되지 않은 쿼리. 컴포넌트가 마운트, 업데이트되어도 데이터를 다시 요청하지 않는다
stale - 만료된 쿼리. 컴포넌트가 마운트, 업데이트되면 데이터를 다시 요청한다.
inactive - 사용하지 않는 쿼리. 일정 시간이 지나면 가비지 컬렉터가 캐시에서 제거한다
delete - 가비지 컬렉터에 의해 캐시에서 제거된 쿼리

important defaults

다음은 React Query에서 제공하는 API의 기본이 되는 설정이다.

useQuery(그리고 useInfiniteQuery)로 가져온 데이터는 기본적으로 stale 상태가 된다.
- staleTime 옵션으로 데이터가 stale 상태로 바뀌는데 걸리는 시간을 늘릴 수 있다.
stale 쿼리는 다음 경우에 백그라운드에서 다시 가져온다
- 새로운 쿼리 인스턴스가 마운트되었을 때
- 브라우저 윈도우가 다시 포커스되었을 때
- 네트워크가 다시 연결되었을 때
- refetchInterval 옵션이 있을 때
활성화된 useQuery, useInfiniteQuery 인스턴스가 없는 쿼리 결과는 “inactive” 라벨이 붙으며 다음에 사용될 때까지 남아있는다.
- inactive 쿼리는 300초(5분) 후에 메모리에서 해제된다.
백그라운드에서 3회 이상 실패한 쿼리는 에러 처리된다.
- retry 옵션으로 쿼리 함수에서 오류 발생시 재시도할 횟수, retryDelay 옵션으로 재시도 대기 시간을 설정
쿼리 결과는 memoization을 위해 structural sharing을 사용하며 데이터 reference는 변경되지 않는다
- immutable.js에서 사용하는 기술.(참고할만한 글)
- 99.9% 케이스에서는 이 옵션을 끌 필요가 없음.
- structural sharing은 JSON 호환 데이터에만 적용되며, 다른 타입의 쿼리 결과는 항상 변경되었다고 판단한다.

`QueryClientProvider` 설정

React Query는 캐시를 관리하기 위해 QueryClient 인스턴스를 사용한다. 컴포넌트가 useQuery 훅 안에서 QueryClient 인스턴스에 접근할 수 있도록 QueryClientProvider를 컴포넌트 트리 상위에 추가해줘야 한다.

import { QueryClient, QueryClientProvider } from 'react-query'

const queryClient = new QueryClient() // 인스턴스 생성

function App() {
  return <QueryClientProvider client={queryClient}>...</QueryClientProvider>
}

`useQuery`로 서버 데이터 가져오기

서버에서 데이터를 가져오고 캐싱을 하는데 사용하는 기본이며 가장 많이 사용하게 되는 훅이다.

const { data, isLoading } = useQuery(queryKey, queryFunction, options)

queryFunction에는 서버에서 데이터를 요청하고 Promise를 리턴하는 함수를 전달한다. 즉 axios.get(...), fetch(...) 등을 리턴하는 함수.

queryKey 에는 문자열과 배열을 넣을 수 있다. 쿼리 키가 가지는 유연함이 곧 캐싱을 처리를 쉽게 만들어준다. 쿼리 키가 다르면 캐싱도 별도로 관리하기 때문이다.

예를 들어 todo 라는 키는 아래와 같이 확장할 수 있다.

// 다른 키로 취급한다. 
useQuery(['todo', 1], ...)
useQuery(['todo', 2], ...)

// 객체 필드의 값이 달라도 다른 키로 취급한다
useQuery(['todo', { preview: true }], ...)
useQuery(['todo', { preview: false }], ...)

// 객체 필드의 순서가 달라도 내용이 같으면 같은 키로 취급한다
useQuery(['todo', { preview: true, status: 'done' }], ...)
useQuery(['todo', { status: 'done', preview: true }], ...)

useQuery 훅이 리턴하는 데이터와 옵션의 종류는 매우 다양하다. 주요 사항은 다음과 같다. (자세한 내용은 공식 문서 참조)

리턴 데이터
- data - 쿼리 함수가 리턴한 Promise에서 resolve된 데이터
- isLoading - 저장된 캐시가 없는 상태에서 데이터를 요청중일 때 true
- isFetching - 캐시가 있거나 없거나 데이터가 요청중일 때 true
옵션
- cacheTime - unused 또는 inactive 캐시 데이터가 메모리에서 유지될 시간. 기본값은 5분이며 설정한 시간을 초과하면 메모리에서 제거된다.
  - Infinity로 설정하면 쿼리 데이터는 캐시에서 제거되지 않는다.
- staleTime - 쿼리 데이터가 fresh 에서 stale로 전환되는데 걸리는 시간. 기본값은 0이다.
  - Infinity로 설정하면 쿼리 데이터는 직접 캐시를 무효화할 때까지 fresh 상태로 유지된다.
  - 캐시는 메모리에서 관리되므로 브라우저 새로고침 후에는 다시 가져온다.
- enabled - false 값이 전달되면 쿼리가 비활성화된다.
  - 데이터 요청에 사용할 파라미터가 유효한 값일 때만 true를 할당하는 식으로 활용할 수 있다.
- onSuccess - 쿼리 함수가 성공적으로 데이터를 가져왔을 때 호출되는 함수.
- onError - 쿼리 함수에서 오류가 발생했을 때
- onSettled - 쿼리 함수의 성공, 실패 두 경우 모두 실행된다.
- keepPreviousData - 쿼리 키(ex.페이지 번호)가 변경되어서 새로운 데이터를 요청하는 동안에도 마지막 data값을 유지한다.
  - 페이지네이션을 구현할 때 유용하다. 캐시되지 않은 페이지를 가져올 때 화면에서 목록이 사라지는 깜빡임 현상을 방지할 수 있다.
  - isPreviousData 값으로 현재의 쿼리 키에 해당하는 값인지 확인할 수 있다.
- initialData - 캐시된 데이터가 없을 때 표시할 초기값. placeholder로 전달한 데이터와 달리 캐싱이 된다. 브라우저 로컬 스토리지에 저장해 둔 값으로 데이터를 초기화할 때 사용할 수 있을 것이다.
- refetchOnWindowFocus - 윈도우가 다시 포커스되었을 때 데이터를 호출할 것인지 여부. 기본값은 true이므로 필요없다고 판단되면 끄면 된다.

`useMutation`으로 서버 데이터 업데이트

서버 데이터를 가져오는 것은 reactive하게 동작하는 useQuery를 사용하면 되겠지만, 서버 데이터 업데이트는 그런 방식으로 사용하기에는 적절하지 않다. 데이터 생성/수정/삭제에는 useMutation 훅을 사용하면 된다.

const mutation = useMutation(newTodo => axios.post('/todos', newTodo))

const handleSubmit = useCallback(
  (newTodo) => {
    mutation.mutate(newTodo)
  },
  [mutation],
)

useQuery의 옵션처럼 onSuccess, onError, onSettled 콜백을 전달할 수 있으며 거기에 더해 mutate를 호출했을 때 실행할 onMutate 콜백도 사용할 수 있다.

Redux를 사용한다면 리퀘스트 성공 액션을 미들웨어에서 확인하여 추가 액션을 실행할 것이다. useMutation을 사용한다면 onSuccess 콜백을 사용해도 되지만, 코드 가독성을 위해 mutateAsync 함수를 사용할 수 있다.

const mutation = useMutation(newTodo => axios.post('/todos', newTodo))

const handleSubmit = useCallback(
  async (newTodo) => {
    await mutation.mutateAsync(newTodo)
		setAnotherState() 
		dispatch(createAnotherAction())
  },
  [mutation],
)

쿼리 무효화(Invalidation)

쿼리 데이터가 stale 상태로 바뀌기만을 기다릴 수만은 없는 케이스가 있다. 예를 들어 게시글에 댓글을 작성한 후에는 서버에서 댓글 목록을 다시 가져올 필요가 있다. 이와 같은 경우에는 지정한 staleTime 이 지나기 전에 직접 쿼리를 무효화해서 데이터를 새로 가져오도록 해야 한다.

const queryClient = useQueryClient();

// 캐시에 있는 모든 쿼리를 무효화한다.
queryClient.invalidateQueries()

// todo로 시작하는 모든 쿼리를 무효화한다. ex) ['todos', 1], ['todos', 2], ...
queryClient.invalidateQueries('todos')

// ['todos', 1] 키를 가진 쿼리를 무효화한다.
queryClient.invalidateQueries(['todos', 1])

predicate 옵션을 사용하면 무효화할 쿼리를 더 자세하게 설정할 수 있다.

// 쿼리 키 배열의 두번째 객체의 version 필드의 값이 10 이상인 쿼리만 무효화한다.
queryClient.invalidateQueries({
  predicate: query =>
	   query.queryKey[0] === 'todos' && query.queryKey[1]?.version >= 10,
})

// 위의 코드로 무효화된다.
const todoListQuery = useQuery(['todos', { version: 20 }], fetchTodoList)

// 위의 코드로 무효화되지 않는다.
const todoListQuery = useQuery(['todos', { version: 5 }], fetchTodoList)

TypeScript에서 generic과 index type의 활용

rhostem — Wed, 20 Jan 2021 00:00:00 GMT

타입스크립트를 사용하면 타입을 직접 지정하는 것도 가능하지만 컴파일러의 추론을 통해 타입을 유연하게 지정하는 것도 가능하다.

예를 들어 아래와 같은 함수가 있다고 하자.

function omitByKey(obj, ...rest) {
  const isKeyMatches = target => rest.includes(target)

  return Object.entries(obj).reduce((result, [name, value]) => {
    return isKeyMatches(name) ? result : { ...result, [name]: value }
  }, {})
}

expect(omitByKey({ a: 1, b: 2 }, 'a')).toEqual({ b: 2 });

omitByKey는 객체에서 지정된 키를 제거하는 함수다. 파라미터 전개 연산자를 사용해서 삭제할 키를 자유롭게 추가할 수 있도록 했다.

이 함수에 타입을 추가하려고 한다면 rest 배열에 들어갈 수 있는 문자열의 집합을 obj 파라미터로 전달된 객체의 키로 한정하고 싶을 것이다. 그런데, 함수 작성 시점에서는 obj 에 어떤 키가 들어있을 지 결코 알 수가 없다.

이런 케이스를 위해 타입스크립트는 타입 추론을 위한 문법을 제공한다. 여기서는 제네릭(generic)과 인덱스 타입(index type)을 사용해서 추론이 가능하다.

제네릭

제네릭 타입은 함수 선언 시점에는 타입이 고정되어 있지 않으며 사용할 때 타입이 지정되는 형태를 말한다.

function identity<T>(arg: T): T {
  return arg;
}

identity 함수 이름 옆에 <T> 를 추가해서 이 함수에서 T라는 이름으로 제네릭을 사용하겠다고 선언했다. 그리고 파라미터가 T 타입을 가지며, 리턴 값에도 T 타입을 부여했다. 이 함수는 파라미터 arg가 어떤 타입을 가졌느냐에 따라 리턴 타입이 유연하게 달라지게 된다. 만약 제네릭이 없다면 number, string 등 다양한 타입에 대한 identity 함수를 별도로 선언해야 할 것이다.

function identityNum(arg: number): number {
  return arg;
}

function identityStr(arg: string): string {
  return arg;
}

// 그리고 다른 타입도 계속...😓

위의 omitByKey 함수도 타입이 유연하게 지정되어야 하므로 제네릭이 필요하다. 그리고 또 하나, 객체가 가지고 있는 키를 가져오기 위해 인덱스 타입이 필요하다.

인덱스 타입(index type)

객체의 키로 타입을 만들 때는 index type query 연산자 keyof를 사용한다. 아래의 코드에서 타입 K는 객체 numbers의 키로 구성된 union 타입이 된다.

const numbers = {
  one: 1,
  two: 2,
  three: 3,
}

type K = keyof typeof numbers;  // type K = 'one' | 'two' | 'three'

그럼 필요한 도구는 준비가 되었으니 omitByKey에 타입을 지정해 보자.

제네릭과 인덱스 타입을 함께 사용하기

export default function omitByKey<T, K extends keyof T, R extends Omit<T, K>>(
  obj: T,
  ...rest: K[]
): R {
  const isKeyMatches = (target: K) => rest.includes(target);

  return Object.entries(obj).reduce((result, [name, value]) => {
    return isKeyMatches(name as K) ? result : { ...result, [name]: value };
  }, {} as R);
}

이 함수에는 T, K, R이라는 3개의 제네릭 타입을 사용했다. T는 객체의 타입에 지정될 것이고 K는 위의 예제에서 본 대로 객체 T의 키로 구성된 union 타입을 상속했다. R은 함수의 리턴 타입으로 Omit 유틸리티 타입을 활용했다.

이렇게 작성하면 rest 배열에는 obj 객체의 키에 해당하는 문자열만 들어갈 수 있다. 만약 다른 키를 넣으려 한다면 아래와 같이 컴파일러가 즉시 오류를 확인시켜 줄 것이다.

const numbers = {
  one: 1,
  two: 2,
  three: 3,
}

omitByKey(numbers, 'another')
// Argument of type 'another' is not assignable to parameter of type 'one' | 'two' | 'three'

참고 자료

동적으로 import된 컴포넌트의 테스트

rhostem — Sat, 16 Jan 2021 00:00:00 GMT

앱을 개발할 때 번들 파일의 사이즈가 커지면 로딩 속도를 개선하기 위해 코드를 분할할 필요가 생긴다. React에서는 react-loadable을 사용하는 방법도 있지만, React.lazy를 사용해서 간단하게 동적 import를 사용할 수 있다.

import React from 'react';

const Login = React.lazy(() => import('page/Login'));

const App = () => {
	return (
		<React.Suspense fallback={<div>loading...</div>}>
			<Login />
    </React.Suspense>
	)
}

다만 이렇게 구현한 컴포넌트를 테스트할 때는 주의가 필요하다. 테스트 코드는 비동기적으로 가져온 컴포넌트가 완전히 렌더링된 후에 실행될 수도 있고, 아닐 수도 있기 때문이다. 비동기 컴포넌트가 렌더링되었음을 확실히 보장하지 않으면 테스트도 성공을 보장할 수 없다.

동적 import로 가져온 컴포넌트 렌더링 확인

Login 컴포넌트가 아래와 같이 구현되어 있다고 가정하자.

// Login.tsx
import React from 'react';

export default function Login(): JSX.Element {
  return (
    <div>
      <div>
        <label htmlFor="">User Id</label>
        <input type="text" />
      </div>
      <div>
        <label htmlFor="">Password</label>
        <input type="password" />
      </div>
    </div>
  );
}

그리고 Login 컴포넌트를 마운트한 App 컴포넌트 테스트 코드를 작성한다.

// App.test.tsx
import React from 'react';
import { render, screen } from '@testing-library/react';
import App from './App';

describe('App component test', () => {
  const arrangeRender = () => {
    render(
      <App/>
    );
  };

  test('아이디, 패스워드 입력을 제공한다.', () => {
    arrangeRender();
    expect(screen.getByRole('textbox', { name: /User Id/i })).toBeInTheDocument()
    expect(screen.getByRole('textbox', { name: /Password/i })).toBeInTheDocument()
  });
});

위의 테스트 코드는 잘 동작할 것 같다. 하지만 실패할 가능성이 있는 테스트 코드다. 테스트 케이스가 실행되기 전에 동적으로 가져온 컴포넌트가 렌더링되지 않았다면 /User Id/i로 찾을 수 있는 textbox 요소가 없다면서 테스트 케이스가 실패할 것이다.

비동기 컴포넌트의 렌더링은 testing-library를 사용해서 확인 가능하다.

export default function Login(): JSX.Element {
  return (
    <div data-testid="loginComponent">
				...
    </div>
  );
}

여기에서는 컴포넌트에 테스트 아이디 loginComponent를 추가해서 컴포넌트의 렌더링을 확인하도록 한다.

import { render, screen, waitFor } from '@testing-library/react';

describe('App component test', () => {
  const arrangeRender = async () => {
    render(
      <App/>
    );

		// waitFor 인스턴스는 Promise이므로 resolve될때까지 기다린다.
		await waitFor(() => {
      expect(screen.getByTestId(/loginComponent/i)).toBeInTheDocument();
    })
  };

  test('아이디, 패스워드 입력을 제공한다.', async () => {
		await arrangeRender();

    expect(screen.getByRole('textbox', { name: /User Id/i })).toBeInTheDocument()
    expect(screen.getByRole('textbox', { name: /Password/i })).toBeInTheDocument()
  });
});

waitFor 함수를 사용해서 Login 컴폰넌트 안에 있는 테스트 아이디가 확인될 때까지 기다리게 했다. 이렇게 작성하면 테스트 케이스에서 expect 메소드가 호출되기 전에 비동기 컴포넌트가 렌더링됨을 확실히 보장할 수 있다. 이렇게 테스트 아이디를 추가해서 확인해도 되고, 이미 존재하는 라벨 텍스트로 확인해도 된다.

테스트 케이스가 실패할 때는 비동기 코드를 의심하자

mokcing한 API가 제대로 동작하지 않은 케이스, intersection observer 때문에 리스트가 일부만 렌더링된 케이스, 비동기 컴포넌트 때문에 DOM 요소를 찾지 못하는 케이스, 단순한 내 실수(🙀) 등 테스트 케이스가 실패하는 원인은 무척 다양하다. 게다가 렌더링 결과를 브라우저로 바로 확인이 불가능하고 screen.debug() 같은 함수를 사용해서 텍스트로만 문제를 파악해야 하기 때문에 원인을 파악하는 것이 더 어려운 것 같다. 그래도 가장 많은 원인은 이 글에서 살펴본 것처럼 비동기적으로 실행되는 코드에 의한 것이었다.

Web Worker를 사용한 이미지 로딩

rhostem — Sun, 03 Jan 2021 00:00:00 GMT

웹 워커(Web worker)

자바스크립트는 싱글 스레드로 동작하며 작성된 코드가 순서대로 실행된다. 하지만 자바스크립트로 작성된 웹 어플리케이션도 API 호출 같은 비동기 작업이 완료될 때까지 멈춰있지 않고 빠르게 실행되는 것이 가능하다. 그 이유는 자바스크립트를 실행하는 브라우저(또는 node.js) 런타임에서 이벤트 루프, 태스크 큐 등을 통해 비동기 작업을 실행하고 관리하기 때문이다.

하지만 그런 비동기 작업이 너무 많아진다면 사용자의 입출력을 처리하는 메인 스레드의 실행 속도에 문제가 생길 가능성이 높아진다. 예를 들어 메인 스레드에서 fetch API로 수백개의 이미지를 가져오는 비동기 코드를 실행하는 동시에 사용자는 화면에서 텍스트를 입력하거나 마우스 조작 등을 통해 이벤트를 발생시킨다고 가정해 보자. 그러면 얼마 후 fetch 가 완료되었을 때 실행할 수백 개의 콜백 함수가 비슷한 시점에 브라우저의 태스크 큐에 쌓이게 될 것이다. 그리고 동시에 UI 상호작용에 의한 컴포펀트 상태 업데이트 콜백 함수도 태스크 큐에 들어올 수 있다. 그렇게 많은 작업을 한꺼번에 처리하다 보면 UI 업데이트에는 지연이 생길 것이며, 사용자는 앱이 느리게 반응한다고 느낄 것이다.

그래서 브라우저에서는 자바스크립트로 작성된 어플리케이션의 멀티스레딩을 위해 웹 워커 API를 제공한다. 웹 워커에서 실행되는 스크립트는 메인 스레드에서 분리되어 독립된 스레드에서 실행되므로 앱이 실행되는 머신의 CPU, 메모리 리소스를 더 효율적으로 활용할 수 있다.

최신 버전의 메이저 웹 브라우저는 모두 웹 워커 API를 제공하며, IE는 10버전부터 제공한다.

웹 워커 사용법

메인 스레드와 웹 워커로 생성된 스레드 사이에서는 message 이벤트를 통해 데이터를 주고받는다. 아래는 웹 워커가 메인 스레드로부터 데이터로 문자열로 구성된 데이터를 전달받은 후 postMessage 메소드를 사용해 메인 스레드로 데이터를 보내는 간단한 예제 코드다.

// sample_worker.ts
addEventListener('message', async function (e: MessageEvent<string[]>) {
  const urls = e.data; 
  postMessage(urls.map(v => v.toUpperCase());
});

웹 워커의 소스에서 사용하는 addEventListener, postMessage 모두 전역 객체(window)의 메소드다.

구현된 웹 워커는 메인 스레드에서 객체로 선언되어 사용한다.

// main.ts
const worker = new Worker('./sample_worker.js') // 웹 워커의 소스가 타입스크립트라면 자바스크립트로의 transpile 과정이 반드시 필요하다. 
worker.postMessage(['str', 'ing', 'sample'])

worker.onmessage = e => {
	// 주고받는 데이터는 모두 이벤트 객체의 data 속성을 통해 전달된다.
	console.log(e.data) // ['STR', 'ING', 'SAMPLE'] 
}

메인 스레드에서 웹 워커 스레드로의 데이터 전송은 postMessage를 사용하며, 데이터를 받을 때는 워커 객체의 onmessage 속성에 이벤트 핸들러를 할당해서 사용한다. 웹 워커의 기본적인 사용법은 이렇듯 간단하다. (더 자세한 내용은 MDN 문서 참조)

이미지 로딩 워커

예제 앱으로 이미지를 로딩하는 웹 워커를 React와 함께 구현해 볼 것이다.

웹 워커에서 fetch API로 이미지를 가져온 후 URL.createObjectURL API를 사용해 문자열 형태로 메인 스레드로 전달한다.
CPU 코어 수만큼 웹 워커 인스턴스를 만들어 작업을 분할한다.
메인 스레드에서 모든 워커의 작업이 완료되었음을 확인한 후 이미지를 표시한다.

구현된 앱은 아래 링크에서 확인할 수 있다.

https://rhostem.github.io/image-load-worker

이미지 로드 웹 워커 구현

https://picsum.photos에서 제공하는 랜덤한 이미지를 fetch API를 사용해서 가져온 후 Response 객체를 ObjectURL로 변환해서 메인 스레드로 전달한다.

// ImageLoadWorker.ts
self.addEventListener('message', async function (e: MessageEvent<string[]>) {
  const urls = e.data; // 메인 스레드로부터 전달받은 이미지 URL 배열

  const images = await Promise.all(
    urls.map(async (url) => {
      try {
        const response = await fetch(url);
        const fileBlob = await response.blob();

        if (/image\/.+/.test(fileBlob.type)) {
          return URL.createObjectURL(fileBlob);
        }
      } catch (e) {
        return null;
      }
    }),
  );

  self.postMessage(images);
});

fetch의 Response 객체는 JSON 형식으로 구성된 객체가 아니라 이진 데이터 스트림이므로 자바스크립트에서 사용할 수 있는 형태로 변환이 필요하다. Body 인터페이스를 구현한 Response 객체는 arrayBuffer, blob, json, formData 등의 메소드를 가지고 있는데, 여기서는 데이터를 Blob 객체로 변환하는 blob 메소드를 사용했다.

Blob은 파일류 객체를 표현하는 불변(immutable), 원시(raw) 데이터다. 자바스크립트 네이티브 형식에는 없는 데이터를 표현할 수 있다.

이미지 데이터를 담고 있는 Blob 객체는 DOM에 직접 연결할 수 없으므로, ObjectURL로 변환하는 과정을 한번 더 거친다.

URL.createObjectURL(fileBlob)

이미지 데이터를 ObjectURL로 변환하면 HTML img 태그의 src 속성에 할당하거나, style 속성의 background-image에 할당해서 이미지를 표시할 수 있다.

ObjectURL은 웹 페이지가 unload될 때 자동으로 할당 해제된다. 하지만 React처럼 페이지가 동적으로 업데이트 되는 앱에서는 URL.revokeObjectURL 메소드로 직접 할당 해제해줘야 메모리 누수를 막을 수 있다.

메인 스레드에서 웹 워커 인스턴스 생성 및 작업 처리

웹 워커가 백그라운드에서 동시에 작업을 진행한다고 해서 100개의 이미지를 불러오는데 워커 인스턴스도 100개를 만들어서 사용하면 오히려 더 느릴 수 있다. 앱이 실행되는 환경의 CPU 코어 수만큼 만들어서 사용하는 것이 가장 좋다. 그리고 그 값은 navigator.hardwareConcurrency를 통해 가져올 수 있다. hardwareConcurrency 값은 사용자의 컴퓨터에서 스레드를 실행하는 데 사용할 수 있는 논리 프로세서의 수를 리턴한다.

const maxWorkers = navigator.hardwareConcurrency || 2; // Safari 브라우저에서는 지원하지 않는다

프로세서 수만큼 웹 워커 인스턴스를 만들어 둔다.

const [workers, setWorkers] = useState<Worker[]>([]);

useEffect(() => {
  if (workers.length === 0) {
    setWorkers(
      new Array(maxWorkers)
        .fill(undefined)
        .map(
          () => new Worker(new URL('./ImageLoadWorker.js', import.meta.url)),
        ),
    );
  }

  return () => {
    workers.forEach((worker) => worker.terminate());
  };
}, [maxWorkers, workers]);

그리고 이미지 주소를 웹 워커에 보내고 결과를 돌려받는 함수를 구현한다.

// 1개의 웹 워커에서 가져올 이미지의 수 = (전체 이미지 개수) / (웹 워커 개수)
const chunkSizeForWorker = useMemo(
    () => Math.ceil(images.length / maxWorkers),
    [images.length, maxWorkers],
  );

const loadAllImagesAtOnce = useCallback(
  async (imageUrls) => { // fetch로 가져올 이미지 주소 배열을 파라미터로 전달받음

    if (window.Worker) {
			// ObjectURL을 저장하기 위한 배열을 미리 생성해 둔다.
      setImageBlobs(new Array(imageUrls.length).fill(undefined)); // 웹 워커에서 fetch가 실패했을 때 null을 리턴하게 했으므로, undefined 값은 이미지 로딩 중이라는 의미도 가진다.

      const imageChunks = [];

			// 웹 워커들에 할당하기 위해 이미지 배열을 분리해서 저장해 둔다.
      for (let i = 0; i < maxWorkers; i++) {
        const startIndex = i * chunkSizeForWorker;
        imageChunks.push(
          imageUrls.slice(startIndex, startIndex + chunkSizeForWorker),
        );
      }

			// 이미지 로딩 작업이 끝날 때까지 기다릴 Promise 객체 배열을 구성한다.
      const imagePromises = imageChunks.map(
        (chunk, chunkIndex) =>
          new Promise<string[]>((resolve) => {
            const chunkWorker = workers[chunkIndex];

            if (chunkWorker) {
							// 워커에 이미지 배열을 전달한다.
              chunkWorker.postMessage(chunk);

              chunkWorker.onmessage = (e) => {
								// 워커에서 ObjectURL이 전송되면 Promise를 해결한다.
                resolve(e.data);
              };
            }
          }),
      );

			// 모든 워커의 작업이 끝날 때까지 기다린다.
      const imageBlobsChunks = await Promise.all(imagePromises);

			// 2차원 배열을 1차원 배열로 변환하는 작업을 거친다
      const allImageBlobs = imageBlobsChunks.reduce(
        (result, chunk) => [...result, ...chunk],
        [],
      );

			// ObjectURL 배열로 상태를 업데이트한다.
      setImageBlobs(allImageBlobs);
    }
  },
  [chunkSizeForWorker, maxWorkers, workers],
);

여러 개의 워커를 생성하면 개발자 도구에서 메모리가 할당되고 네트워크 입출력이 발생하는 것을 확인할 수 있다.

구현이 완료된 소스는 https://github.com/rhostem/image-load-worker 에서 확인 가능하다.

결과 비교

아래 영상은 웹 워커를 통해 이미지를 가져와서 한꺼번에 렌더링하는 것과 이미지 URL을 DOM style 속성에 직접 할당해서 불러오는 것의 비교 화면이다.

웹 워커를 사용한 목록은 모든 이미지를 가져온 후 한꺼번에 업데이트되고, 직접 가져오게 한 목록에서는 이미지 로딩이 완료되는대로 표시됨을 확인할 수 있다.

웹 워커를 사용했을 때의 장점을 정리하면 다음과 같다.

화면 업데이트를 최소화하여 성능을 향상시킨다.
이미지 로딩 작업이 다른 DOM의 업데이트와 UI 상호작용에 미치는 영향을 최소화한다.
Image 객체를 생성하지 않고도 이미지 로딩 상태, 성공, 실패 여부를 UI에 동적으로 업데이트할 수 있다.

웹 워커를 사용하지 않아도 웹 개발과 성능에 큰 문제가 없는 경우가 대부분이다. 하지만 메인 스레드에서 많은 메모리를 사용하고 있고 성능에 영향을 미치는 것 같다면 백그라운드로 진행해도 되는 작업을 웹 워커에서 처리하는 방법을 고려해볼 수 있다.

create-react-app에서 snowpack으로의 마이그레이션

rhostem — Wed, 16 Dec 2020 00:00:00 GMT

최근 실무에서 Webpack 기반의 create-react-app(이하 CRA)으로 구성된 환경으로 개발을 진행하고 있다. CRA는 간편하게 앱을 부트스트랩핑해서 개발을 시작할 수 있다는 장점이 있지만 커스터마이징에 한계가 있다. 그래서 CRA 커스터마이징을 위한 react-app-rewired 같은 모듈도 존재한다. CRA로 만든 앱을 eject 했을 때 숨겨져있던 다양하고 복잡한 설정 파일을 눈으로 본 사람이라면 저런 패키지에 대한 수요가 왜 생겼는지 공감할 것이다.

커스터마이징의 자유도가 낮은 것도 있지만, Webpack은 앱의 덩치가 커지면 커질수록 빌드 속도가 느려진다. 파일을 하나만 변경해도 번들 파일을 새로 만들기 때문이다. 그래서 더 빠른 빌드 시스템으로의 마이그레이션을 계속 생각해오고 있었다.

자바스크립트 번들러에는 과거에 grunt, gulp 같은 도구도 있었지만 그 후 등장한 Webpack이 사실상 왕좌의 자리를 차지하고 있다. 다운로드 수로 보자면 경쟁자인 rollup은 절반에도 미치지 못하며 이 글에서 살펴볼 snowpack은 다운로드 수 차트에서만 보자면 바닥을 기고 있다. 차트에는 없지만 parcel도 일간 다운로드 수가 10만에 미치지 못한다.

출처 - https://www.npmtrends.com

Snowpack, 더 빠른 프론트엔드 빌드 도구

Snowpack은 Webpack처럼 복잡하고 무거운 빌드 시스템의 대안으로 만들어졌다. 자바스크립트 네이티브 모듈 시스템(ESM, Javascript Modules)을 사용해서 무거운 번들링 작업을 제거하고 프로젝트 크기와 상관없이 빠른 속도를 제공하도록 만들어졌다. 특징은 다음과 같다.

개발서버는 처음에만 의존 모듈 설치 시간을 필요로 하며, 그 다음부터는 50ms 안에 실행된다.
같은 파일을 두번 빌드하지 않는다. 브라우저 안에서 자바스크립트 네이티브 모듈(ESM) 사용으로 가능하다.
소스가 변경되어도 브라우저 새로고침이 필요하지 않다. React, Preact, Svelte에서 HMR+Fast refresh를 지원한다.
- 코드가 수정되어도 컴포넌트의 상태를 유지한다. 예를 들어 React에서 useState 등으로 설정된 값을 초기화하지 않음으로서 더 빠른 리프레쉬가 가능하다.
JSX, 타입스크립트, React, Preact, CSS 모듈을 기본 지원한다.
최적화된 빌드를 지원하며 선호하는 번들러를 사용하기 위한 플러그인을 지원한다
Babel, Sass, MDX 등 기능 확장을 위한 빌드 플러그인을 지원한다

ESM을 사용하려면 script 요소에 type="module" 속성을 추가해야 한다. 그러면 인라인 스크립트 안에서도 import 구문을 쓸 수 있게 된다.

IE는 네이티브 모듈을 지원하지 않는다. 하지만 Snowpack의 Webpack 플러그인으로 빌드된 결과에서는 네이티브 모듈을 사용하지 않으므로 상관없다. 다만 IE를 반드시 지원해야 한다면 IE에서 개발 서버를 사용할 수 없으므로 디버깅에 어려움이 있을 것이다.

어떻게 더 빠른가?

webpack, parcel같은 전통적인 빌드 도구는 파일이 하나 바뀔 때마다 어플리케이션의 모든 조각(chunks)들을 다시 번들링하는 과정을 거친다. 하지만 Snowpack은 각각의 소스를 빌드만 할 뿐 번들이 되지 않은 상태로 개발 서버에 호스팅한다. 그리고 파일이 변경되면 그것만 다시 빌드하기 때문에 수정사항이 브라우저에 매우 빠르게 반영될 수 있다.

출처 - https://www.snowpack.dev

물론 배포를 위한 빌드도 제공하며, 배포용 빌드에 webpack을 사용하기 위한 플러그인도 제공한다. 빌드를 위한 복잡한 설정도 필요하지 않다.

개발서버에서는 소스를 Babel이나 Typescript로 변환만 할 뿐 번들은 하지 않은 상태로 제공하는 것, 이것이 개발 서버에서도 번들이 된 소스를 제공하는 다른 도구와 가장 큰 차이다. 그것(unbundled development)의 장점은 다음과 같다.

파일 1개의 빌드 속도는 빠르다
파일 1개의 빌드는 결정론적(deterministic, 언제나 같은 결과를 낳으므로 예측 가능함)이다.
파일 1개의 빌드는 디버그하기 쉽다
프로젝트 사이즈가 개발 속도에 영향을 미치지 않는다
개별 파일이 캐시하기에 더 좋다

물론 빌드된 수백개의 소스 파일을 브라우저에서 처음 불러올 때는 시간이 조금 걸린다. 현재 작업 중인 프로젝트에서는 450여개의 소스 파일이 있는데, 최초 로딩시 6~7초로 아주 오랜 시간은 아니었다. 그 다음부터는 모두 웹 브라우저 캐시에서 불러오므로 로딩 속도가 훨씬 빠르다.

Snowpack에서 NPM 패키지를 사용하는 방식

NPM 패키지는 Common.js 모듈 문법을 사용해서 배포되기 때문에 빌드 프로세스를 거치지 않고서는 웹 브라우저에서 실행할 수 없다. 하지만 Snowpack에서는 패키지를 개발 서버에서 ESM 형태로 사용하기 위해 1개의 파일로 번들링한 후 호스팅한다.

node_modules/react/**/\* -> http://localhost:3000/web_modules/react.js
node_modules/react-dom/**/\* -> http://localhost:3000/web_modules/react-dom.js

React 모듈을 소스에 번들링하지 않아도 개발 서버에서 ESM 형태로 제공하면 컴포넌트 소스에서 import 문을 사용해서 직접 불러올 수 있다. NPM 패키지는 덩치가 크므로 빌드하는 데 시간이 걸리긴 하지만, 처음 1번만 빌드된 후 아래 폴더에 캐시된다.

<project root>/node_modules/.cache/snowpack/development

캐시를 삭제하지 않는 이상 더 이상 빌드하지 않기 때문에 많은 시간이 절약된다. 이렇게 NPM 패키지를 소스에 번들링하지 않고 웹 브라우저가 지원하는 ESM 문법을 사용한다는 이 특징이 Snowpack이 제공하는 번들링 없는 개발의 기반이다.

CRA에서 Snowpack으로의 마이그레이션

snowpack 설정 파일 추가

프로젝트 루트에 snowpack.config.js 파일을 추가한다.

/** @type {import("snowpack").SnowpackUserConfig } */
const path = require("path");

module.exports = {
  mount: {
    public: "/",
    src: "/_dist_",
  },
  plugins: [
    "@snowpack/plugin-react-refresh",
    "@snowpack/plugin-dotenv",
    "@snowpack/plugin-typescript",
    "@snowpack/plugin-webpack",
  ],
  installOptions: {
    polyfillNode: true,
  },
  devOptions: {
    port: 3000,
  },
  buildOptions: {
    sourceMaps: true,
  },
  proxy: {
    /* ... */
  },
  alias: {
    __mocks__: path.join(__dirname, "src/__mocks__"),
    component: path.join(__dirname, "src/component"),
    constants: path.join(__dirname, "src/constants"),
    hook: path.join(__dirname, "src/hook"),
    page: path.join(__dirname, "src/page"),
    store: path.join(__dirname, "src/store"),
    style: path.join(__dirname, "src/style"),
    types: path.join(__dirname, "src/types"),
    styles: path.join(__dirname, "src/styles"),
    utils: path.join(__dirname, "src/utils"),
    vendor: path.join(__dirname, "src/vendor"),
  },
  testOptions: {
    files: ["**/*.@(spec|test).*"],
  },
};

`mount`

빌드된 소스와 정적인 파일을 호스팅할 개발 서버의 경로를 지정한다. 위처럼 설정하면 소스 저장소의 public/index.html 파일은 개발 서버의 /index.html 경로로, src/index.tsx 파일은 빌드되어 /_dist_/index.js 경로로 접근할 수 있게 된다.

CRA를 사용했다면 index.html 파일에 엔트리 파일을 불러오는 부분이 없을 것이다. 하지만 Snowpack에서는 필요하므로 루트 컴포넌트를 연결할 요소 아래쪽에 아래 코드를 추가해준다.

<html>
  <head>
    ... (생략)
  </head>

  <body>
    <div id="root"></div>
    <script type="module" src="/_dist_/index.js"></script>
  </body>
</html>

`plugin`

Snowpack은 확장성을 위한 플러그인을 지원한다.

@snowpack/plugin-react-refresh
- HMR 사용을 위한 플러그인
@snowpack/plugin-dotenv
- .env 파일에 있는 환경 변수 파일을 import.meta.env 객체를 통해 접근할 수 있게 한다.
@snowpack/plugin-typescript
- 타입스트립트 소스를 자바스크립트로 변환해준다.
@snowpack/plugin-webpack
- Snowpack은 번들링 기능을 포함하고 있지 않다. 하지만 서비스 배포를 위해선 소스 압축이 필요하므로 플러그인을 통해 webpack의 기능을 활용한다(Webpack의 옵션을 직접 전달할 수도 있지만 기본적인 설정이 되어 있어서 별도로 필요하진 않았다). rollup 플러그인은 현재 개발 중이며, Snowpack 버전 3에는 자체적으로 번들러를 제공할 예정이라고 한다.

`installOptions`

모듈 설치와 관련된 옵션. polyfillNode 옵션은 소스에서 path같은 Node.js 모듈을 사용할 경우 필요하다.

`devOptions`

개발 서버 관련 옵션. port에 개발 서버의 포트를 지정한다.

`buildOptions`

빌드 옵션. sourceMaps을 true로 지정하면 소스맵도 함께 생성한다. 배포된 서비스에서 에러가 발생했을 때 Sentry같은 모니터링 서비스에서 에러가 발생한 부분과 원본 소스를 매칭시켜 줄 때 사용한다.

`proxy`

개발 서버의 프록시를 설정한다. 예를 들어 /api 로 접근하면 https://pokeapi.co/api/v2/로 연결시켜주는 등의 기능을 한다.

`alias`

아래처럼 소스 파일을 절대 경로로 접근하려고 할 때 필요하다.

import useTypedSelector from "hook/useTypedSelector";

`testOptions`

테스트 파일의 위치를 지정한다. 테스트 파일 관련 모듈은 개발 서버 실행에만 설치되며, 빌드 작업에는 포함되지 않는다.

환경 변수 설정

CRA에서는 환경 변수를 .env 파일에 추가하면 node.js에서 실행되는 소스와 브라우저에서 실행되는 소스 모두에서 process.env 객체를 통해 접근할 수 있도록 Webpack 설정이 되어 있다. Snowpack에서는 그 방법 대신import.meta.env 객체를 통해 환경 변수를 제공한다.

그리고 변수 이름 앞에 SNOWPACK_PUBLIC_이 붙지 않은 변수는 브라우저 실행되는 소스에서 접근할 수 없도록 되어 있다. 저렇게 구분한 이유는 환경 변수에 서버 접속 시크릿 키 같은 중요한 값이 포함되어 있을 수 있기 때문이다. 그런 값들은 실수로라도 노출되어선 안되기에 보안을 위해 사용자에게 어떤 환경변수가 브라우저에서 노출되는지 확실히 알게 하려는 목적을 가진다.

CRA로 프로젝트가 구성되어 있다면 node.js 환경에서만 사용되는 값을 제외한 모든 환경변수의 이름 앞에 REACT_APP_ 프리픽스 대신SNOWPACK_PUBLIC_을 추가해줘야 한다. 소스는 물론 배포 환경에도 영향을 미칠 수 있는 사항이기에 새로운 프리픽스가 붙은 환경변수를 먼저 추가해준 후, 마이그레이션이 완료되면 필요없는 변수를 지우는 방식을 쓰는 편이 좋을 것이다

Jest 설정

CRA는 Jest 실행 설정을 포함하고 있다. 하지만 Snowpack에는 없으므로 설정 파일을 직접 추가해줘야 한다.

// jest.config.js 파일
const snowpackJestConfig = require("@snowpack/app-scripts-react/jest.config.js")();
const { parsed: env } = require("dotenv").config();

module.exports = {
  ...snowpackJestConfig, // Snowpack에서 제공하는 설정을 가져와서 커스터마이징 하는 방식을 쓴다
  verbose: false,
  preset: "ts-jest", // 타입스트립트를 사용한다면 ts-jest 모듈이 필요하다.
  testEnvironment: "jsdom",
  setupFilesAfterEnv: ["./src/setupTests.ts"],
  testPathIgnorePatterns: [
    "/node_modules/",
    "<rootDir>/build",
    "<rootDir>/cypress",
  ],
  testMatch: ["<rootDir>/src/**/?(*.)+(spec|test).[jt]s?(x)"],
  moduleNameMapper: {
    // Snowpack 설정의 alias를 그대로 가져와서 쓸 수 없어서 jest에서 사용하는 방식으로 설정한다.
    // 키와 밸류는 String.prototype.replace 메소드의 파라미터에 차례대로 들어간다고 보면 된다.
    "^__mocks__(/?.*)$": "<rootDir>/src/__mocks__$1",
    "^component(/?.*)$": "<rootDir>/src/component$1",
    "^constants/(.*)$": "<rootDir>/src/constants/$1",
    "^hook(/?.*)$": "<rootDir>/src/hook$1",
    "^page(/?.*)$": "<rootDir>/src/page$1",
    "^store(/?.*)$": "<rootDir>/src/store$1",
    "^style(/?.*)$": "<rootDir>/src/style$1",
    "^translation(/?.*)$": "<rootDir>/src/translation$1",
    "^types/(.*)$": "<rootDir>/src/types/$1",
    "^utils(/?.*)$": "<rootDir>/src/utils$1",
    "^vendor(/?.*)$": "<rootDir>/src/vendor$1",
  },
};

Storybook 설정

Storybook은 빌드 툴로 Webpack을 내부적으로 사용한다. 실행을 위해서는 .storybook/main.js 파일에서 Webpack 설정을 확장해야 한다.

우선 소스에서 모듈을 절대 경로로 가져오기 위해 alias 설정을 추가해줘야 한다. snowpack.config.js 모듈에 있는 것을 재사용할 수 있다. 다만 snowpack.config.js 파일과 main.js 파일이 다른 디렉토리에 있기 때문에 path.join(__dirname, '경로') 형태로 설정하지 않았다면 오류가 발생할 것이다.

그리고 역시 소스에서 import.meta.env 를 사용하기 위한 설정이 필요하다. webpack.DefinePlugin 으로 __SNOWPACK_ENV__ 전역 변수를 선언한 후, importMetaLoader.js 로더를 추가해서 import.meta.env 코드를 환경 변수를 포함한 객체 형태로 변환해준다.

const path = require("path");
const webpack = require("webpack");
const snowpackConfig = require("../snowpack.config.js");

require("dotenv").config();

module.exports = {
  webpackFinal: async (config) => {
    // Assign aliases from snowpack.config.js
    config.resolve.alias = {
      ...config.resolve.alias,
      ...snowpackConfig.alias,
    };

    // Add __SNOWPACK_ENV__ global
    config.plugins.push(
      new webpack.DefinePlugin({
        __SNOWPACK_ENV__: JSON.stringify(
          // process.env 객체에서 SNOWPACK_PUBLIC_ 프리픽스가 붙은 변수만 필터링
          Object.entries(process.env).reduce(
            (filtered, [key, value]) =>
              /^SNOWPACK_PUBLIC_.+/.test(key)
                ? { ...filtered, [key]: value }
                : filtered,
            {}
          )
        ),
      })
    );

    // Add rules for supporting import.meta
    config.module.rules.push({
      test: /\.[tj]sx?$/,
      loader: [require.resolve("./importMetaLoader.js")],
    });

    return config;
  },
};

// importMetaLoader.js
const path = require("path");
const regex = /import\.meta/g;

/**
 * import.meta 코드 변환을 위한 storybook용 webpack 로더
 * 참조) https://github.com/snowpackjs/snowpack/blob/main/plugins/plugin-webpack/plugins/import-meta-fix.js
 */
module.exports = function (source) {
  let found = false;
  let rewrittenSource = source.replace(regex, () => {
    found = true;
    return `({ env: __SNOWPACK_ENV__ })`;
  });

  if (found) {
    return `${rewrittenSource}`;
  } else {
    return source;
  }
};

위의 로더는 @snowpack/plugin-webpack에 있는 것을 수정한 것이다. import.meta.url을 사용하지 않는다면 위의 간단한 버전을 사용해도 상관없다.

Snowpack 셋업 후 속도 측정

실무에서 작업 중인 프로젝트를 Snowpack으로 마이그레이션 한 후 속도를 측정해 보았다.

개발 서버 실행 속도

최초

2회차

최초에는 소스 및 NPM 모듈 빌드를 위해 시간이 40초 정도 걸리지만, 그 다음부터는 빌드 시간이 거의 필요없는 수준이다.

개발 서버 리소스 로딩 속도

최초

소스와 NPM 모듈이 캐시가 되지 않은 상태로 5초 정도가 걸렸다. 스크린샷에 보면 react, react-dom, react-redux 등의 모듈을 브라우저에서 직접 불러오고 있는 것을 확인할 수 있다.

2회차 이상

파일들이 캐시되어 로딩에 대부분 100ms를 넘기지 않음을 확인할 수 있다.

빌드 시간 비교

CRA

129초 정도가 걸렸다.

Snowpack

@snowpack/plugin-webpack 플러그인을 사용해서 73초 정도가 걸렸다. CRA에 비하면 1.7배 정도 빠르다. (Snowpack의 번들 파일 용량이 더 큰 것처럼 나오지만, Webpack 결과에는 웹 서버에서 gzip으로 압축 전송을 적용했을 때의 크기를 보여주고 있기 때문에 그렇다.)

테스트 속도 비교

CRA + Jest

Snowpack + Jest

테스트는 Snowpack에서 추천하는 esbuild 기반의 Web test runner를 사용하지 않는 이상 아주 큰 차이가 없을 것으로 보인다.

esbuild는 Go로 만들어졌으며 무거운 번들링 작업을 할때 싱글 스레드인 자바스크립트로는 불가능한 병렬 처리가 구현되어 있다. Snowpack은 v2에서도 개별 파일을 빌드할 때는 esbuild를 사용하고 있다.

결론

Snowpack은 2021년 1월에 배포 예정인 3.0 버전에서 NPM 패키지를 설치하는 대신 Skypack CDN으로 스트리밍하기, esbuild를 사용해서 webpack보다 100배 이상 빠른 번들링 지원, 라우팅등 지금보다 더 다양하고 혁신적인 기능을 선보일 것이라서 기대가 된다.

Snowpack은 많은 사람의 관심에 비해 실제 사용량이 아직은 적다. 하지만 2020년 12월 현재 아직 만 2년도 안된 프로젝트인데다(Webpack은 8년) 라이브러리가 더 성숙해지고 플러그인의 종류도 다양해지면 사용자가 앞으로 더 많아질 것으로 기대된다. 개인적으로는 신규 프로젝트를 진행한다면 빌드 시스템으로 Snowpack을 우선 고려할 것 같다. 하지만 Webpack에 비하면 성숙도가 낮은 도구라서 대규모 상용 서비스에 즉시 도입을 권하기는 애매한 상황이다. 하지만 지금 진행 중이거나, 새로 시작할 프로젝트가 Webpack이나 다른 번들러의 기능에 크게 의존하지 않는다면 사용을 고려해볼만 하다.

참고 자료

[번역] 초보자를 위한 React 어플리케이션 테스트 심층 가이드 (2)

rhostem — Thu, 15 Oct 2020 00:00:00 GMT

이 글은 ”An in-depth beginner’s guide to testing React applications“를 번역한 글입니다

React 앱 테스팅 개요
테스트에 사용할 어플리케이션
무엇을 테스트해야 하는가?
테스트 작성
어둠 속에서 찔러보지 말라
렌더링된 DOM 트리에 접근하는 방법
DOM 요소와 상호작용 하기
올바른 페이지가 렌더링 되었는지 확인하기
폼 테스팅
셋업 함수에서 중복 방지하기
폼을 변경하고 제출하기
ARIA role 없이 요소에 접근하기
데이터 기다리기
API 요청 위조하기(mocking)
Mock 함수 테스팅

폼 테스팅

훌륭하다, 우리는 헤더에 있는 링크를 위한 첫번째 테스트를 작성했다. 이제 조금 더 복잡한 것을 해 볼 차례다. 우리는 폼을 테스트할 것이다.

앞서 얘기했듯이, 우리의 테스트 시나리오는 다음 단계를 거쳐야 한다.

사용자는 폼 입력에 값을 입력하고 제출 버튼을 누른다.
데이터를 기다리는 동안 로딩 메시지가 표시된다.
API 응답이 도착하면 데이터가 렌더링된다.

테스트는 헤더에서 했던 것과 같은 방법으로 시작할 수 있다.

describe('Subreddit form', () => {
  test('loads posts that are rendered on the page', () => {
    render(
      <MemoryRouter>
        <App />
      </MemoryRouter>
    );
  });
});

셋업 함수에서 중복 방지하기

헤더 테스트에서 했던 것과 중복된 부분을 발견할 수 있다. 중복 방지를 위한 일반적인 방법은 셋업 함수를 만드는 것이다.

function setup() {
  return render(
    <MemoryRouter>
      <App />
    </MemoryRouter>
  );
}

...

describe('Subreddit form', () => {
  test('loads posts and renders them on the page', () => {
    setup();
  });
});

이제 우리가 할 일은 setup 함수를 호출하고 테스트를 시작하는 것만 남았다.

폼을 변경하고 제출하기

위에서 설명했던 세 단계 중에서 첫 번째는 “사용자는 폼 입력에 값을 입력하고 제출 버튼을 누른다.”다.

폼의 입력에 접근하기 전에 screen.debug를 사용해서 렌더링된 앱이 어떻게 생겼는지 다시 확인할 수 있다.

서브레딧 검색을 위한 r / 라벨이 붙어있는 input 요소를 확인할 수 있다. 쿼리 목록의 우선순위의 다른 부분을 살펴보면, 폼 인풋을 찾기 위한 쿼리로는 getByLabelText가 바람직한 선택임을 알 수 있다.

입력 값을 변경하기 위해서는 @testing-library/user-event의 type 함수를 사용하면 된다.

setup();

const subredditInput = screen.getByLabelText('r /');
userEvent.type(subredditInput, 'reactjs');

다음으로, 우리는 폼을 제출해야 한다. screen.debug()의 출력에서 폼 안에 버튼 요소가 있는 것을 확인할 수 있다. 그것은 getByRole의 좋은 사용 사례다.

const subredditInput = screen.getByLabelText('r /');
userEvent.type(subredditInput, 'reactjs');

const submitButton = screen.getByRole('button', { name: /search/i });
userEvent.click(submitButton);

screen.debug();

우리는 앱의 현재 상태가 어떤지 확인하기 위해 아래쪽에 또 다른 debug 구문을 추가했다. 결과는 다음과 같다.

아래 부분에서 우리는 앱이 “Is loading” 텍스트를 보여주고 있는 걸 확인할 수 있다. 그것은 우리가 제출 버튼을 클릭했을 때 기대했던 모습과 정확히 일치한다.

ARIA role 없이 요소에 접근하기

두 번째 단계는 “데이터를 기다리는 동안 로딩 메시지가 표시된다.”이다.

로딩 메시지는 div 요소 안에 있어서 접근에 사용할 ARIA role이 없다. Testing Library 문서에 의하면 이 경우에는 getByRole 대신 getByText를 사용할 수 있다.

userEvent.click(submitButton);

expect(screen.getByText(/is loading/i)).toBeInTheDocument();

여기까지 작성한 테스트도 역시 통과할 것이다.

이제 마지막 단계 - “API 응답이 도착하면 데이터가 렌더링된다”에 파고 들 단계다.

데이터 기다리기

현재 우리는 제출 버튼을 클릭했고, 로딩 메시지가 표시되고 있는 중이다. 이는 API 요청을 보냈지만 아직 응답을 받지 못했다는 의미다. 데이터가 제대로 렌더링되는 것을 테스트하기 위해서 우리는 응답을 기다릴 필요가 있다.

지금까지 우리는 getBy* 쿼리만 사용해 왔다. 하지만 처음에 언급했듯이 getBy로 시작하는 함수는 동기적이다. 그것들은 어플리케이션의 현재 상태만 확인한다. 만약 함수가 검색 타겟을 바로 찾을 수 없다면 테스트가 실패할 것이다.

그러므로 이제는 다른 타입의 쿼리를 사용할 때가 되었다. 비동기적인 findBy* 함수는 타겟 요소가 나타날 때까지 최대 5초를 기다린다.

새로운 쿼리를 사용하기 전에 비동기적으로 표시되는 요소의 식별자를 찾아야 한다. 우리는 앱이 API 요청의 응답을 받는데 성공하면 검색된 인기 포스트의 개수를 폼 아래쪽에 표시한다는 사실을 알고 있다. 표시되는 텍스트의 형식은 “Number of top posts: …” 와 같다. 그러니 여기서는 findByText 쿼리를 사용하자.

렌더링되는 결과에 들어가는 숫자는 모르기 때문에 정규표현식을 사용하면 편리하다. 기억하는가? 정규표현식은 문자열의 일부만으로 요소를 찾을 수 있게 해준다.

test('loads posts and renders them on the page', async () => {
  setup();

  const subredditInput = screen.getByLabelText('r /');
  userEvent.type(subredditInput, 'reactjs');

  const submitButton = screen.getByRole('button', { name: /search/i });
  userEvent.click(submitButton);

  const loadingMessage = screen.getByText(/is loading/i);
  expect(loadingMessage).toBeInTheDocument();

  const numberOfTopPosts = await screen.findByText(/number of top posts:/i);
  screen.debug(numberOfTopPosts);
});

findByText 가 비동기적이기 때문에 await를 사용해야 한다. 그리고 await 때문에 테스트 함수 앞에 async 키워드도 추가해야 한다.

debug 함수의 결과는 아래와 같다.

훌륭하다! 응답 데이터가 렌더링되었다. 우리가 앞서 정의했던 모든 단계를 다뤘다.

사용자는 폼 입력에 값을 입력하고 제출 버튼을 누른다.
데이터를 기다리는 동안 로딩 메시지가 표시된다.
API 응답이 도착하면 데이터가 렌더링된다.

여기서 끝났다고 생각할 수도 있다. 하지만 안타깝게도, 마지막 하나가 더 남았다.

API 요청 위조(mocking)하기

당신이 직접 테스트를 돌려 봤다면 아마도 폼 테스트에 걸리는 시간이 다른 테스트에 비해 상대적으로 길다는 사실을 깨달았을 것이다. 내 컴퓨터에서는 거의 1초가 걸린다. 그 이유는 우리가 진짜 Reddit API에 요청을 보내고 있기 때문이다.

그것은 이상적이지 않다. 통합 테스트에는 서버 요청을 실제로 보내서는 안된다. 거기에는 몇 가지 이유가 있다.

API 요청은 시간이 많이 걸린다. 통합 테스트는 보통 코드를 원격 저장소(ex. Github)에 푸시하기 전에 로컬 환경에서 자주 실행한다. 그리고 코드가 푸시되었을 때 CI 파이프라인을 통해 실행되는 케이스도 많다. 만약 테스트의 수가 아주 많고 테스트들이 보내는 요청도 많다면, 테스트는 끝도 없이 돌아갈 것이다. 그렇게 되면 개발 환경과 퍼포먼스에 영향을 미치게 된다.
우리는 API 요청을 컨트롤할 수 없다. 우리는 통합 테스트에서 앱이 가지는 다양한 상태를 테스트하고 싶어한다. 예를 들어 API 서버가 죽은 상황을 테스트하고 싶을 수도 있다. 특정 테스트가 실행되는 동안만 서버에 오류가 생기도록 만들 수는 없다. 하지만 우리가 요청을 위조한다면 어떤 타입의 응답도 쉽게 시뮬레이션할 수 있다.
우리가 작성한 테스트에 아무 문제가 없어도 API 서버가 기대한 기대로 동작하지 않는다면 테스트가 실패할 수 있다. 예를 들어 API 서버가 죽은 상태라면 그런 상황이 발생할 수 있을 것이다. 테스트가 자동으로 그런 상황들을 대응하도록 만들면 좋겠지만, 그런 것은 통합 테스트가 아닌 E2E(end-to-end) 테스트를 사용해야 한다.

좋다, 이제 이유를 알았고 우리는 API 요청을 위조하야 한다. 그런데 어떻게?

먼저, API 요청이 어떻게 보내지는지 알아야 한다. 우리가 테스트하는 앱에서 그것은 Home 페이지 컴포넌트에서 이뤄진다.

function Home() {
  const [posts, setPosts] = useState([]);
  const [status, setStatus] = useState('idle')

  const onSearch = async (subreddit) => {
    setStatus('loading');
    const url = `https://www.reddit.com/r/${subreddit}/top.json`;
    const response = await fetch(url);
    const { data } = await response.json();
    setPosts(data.children);
    setStatus('resolved');
  };

  ...

fetch로 만들어진 요청을 위조하기 위해서는 jest-fetch-mock npm 패키지를 사용할 수 있다. 우선 패키지를 설치하자.

yarn jest-fetch-mock

이제 테스트 파일 상단에서 jest-fetch-mock을 초기화해야 한다.

import fetchMock from 'jest-fetch-mock';

fetchMock.enableMocks();

여기까지 했다면 폼 테스트는 실패할 것이다. 왜냐하면 위조된 fetch에게 요청에 대한 응답을 어떻게 할지 알려주지 않았기 때문이다.

위조 응답을 만들기 위해 브라우저를 보자. 개발 도구의 네트워크 탭을 열고 폼을 제출한 후 API 응답을 복사한다.

그 다음, 새로운 파일(ex. src/__mocks__/subreddit-reactjs-response.json) 을 만들어 거기에 개발 도구에서 복사한 응답 데이터를 붙여넣는다.

그러면 jest-fetch-mock 덕분에 fetch.once를 호출하는 것만으로 위조 응답을 쉽게 만들 수 있다.

import mockResponse from './__mocks__/subreddit-reactjs-response.json';

...

test('loads posts and renders them on the page', async () => {
  fetch.once(JSON.stringify(mockResponse));
  setup();
  ...

이제 테스트가 다시 성공해야 한다. 그리고 위조 응답을 사용했기 때문에 테스트하는 요소에 어떤 값이 표시되어야 하는지 확실하게 안다. 그러므로 관련된 테스트를 조금 수정할 수 있다.

expect(await screen.findByText(/number of top posts: 25/i)).toBeInTheDocument();

노트: 당신의 테스트가 이것보다 더 많은 API 요청을 보낸다면 이 방법은 다소 번거로울 수 있다. 그런 경우에는 MSW 패키지를 살펴보길 바란다. Kent C. Dodds의 블로그 글에서 더 많은 정보를 확인할 수 있다.

Mock 함수 테스팅

마지막 단계로, 우리는 올바른 API 주소로 요청이 전달되었는지 테스트하고 싶을 수 있다. 이것으로 유저가 정확한 데이터를 보는지 보장할 수 있다.

위에서 jest-mock-fetch를 사용했으므로 현재 전역 fetch는 위조 함수로 대체된 상황이다. 덕분에 정확한 URL이 사용되었는지 여부는 Jest의 toHaveBeenCalledWith 함수로 간단히 가능하다.

expect(fetch).toHaveBeenCalledWith('https://www.reddit.com/r/reactjs/top.json');

노트: 테스트 중에는 위조 함수를 직접 써야 할 상황이 때때로 생긴다. Jest를 사용하면 새로운 위조 함수를 jest.fn() 으로 쉽게 만들 수 있다. test-mock-fetch 패키지도 내부적으로 저 함수를 활용하고 있다.

이제 되었다! 전체 테스트는 아래와 같다.

describe('Subreddit form', () => {
  test('loads posts and renders them on the page', async () => {
    fetch.once(JSON.stringify(mockResponse));
    setup();

    const subredditInput = screen.getByLabelText('r /');
    userEvent.type(subredditInput, 'reactjs');

    const submitButton = screen.getByRole('button', { name: /search/i });
    userEvent.click(submitButton);

    expect(screen.getByText(/is loading/i)).toBeInTheDocument();

    expect(await screen.findByText(/Number of top posts: 25/i)).toBeInTheDocument();
    expect(fetch).toHaveBeenCalledWith('https://www.reddit.com/r/reactjs/top.json');
  });
});

정리

여기까지 온 것을 축하한다🎉. 이제 당신의 앱에 테스트를 작성하는 일에 자신감을 얻게 되었길 바란다.

핵심 사항은 아래와 같다:

유저 관점에서의 테스트 작성.
테스트에서 뭐가 일어나고 있는지 확실하지 않을 때는 언제나 screen.debug()를 사용해라.
가능하다면 DOM 트리에서 요소에 접근할 때 getByRole, findByRole, … 함수를 사용해라.

그리고 이 블로그 포스트 링크에서는 테스트 리팩토링과 디버깅에 대해 더 심화된 내용을 확인할 수 있다.

[번역] 초보자를 위한 React 어플리케이션 테스트 심층 가이드 (1)

rhostem — Wed, 14 Oct 2020 00:00:00 GMT

이 글은 ”An in-depth beginner’s guide to testing React applications“를 번역한 글입니다

대부분의 개발자는 다음의 사실을 알고 있다: 자동화된 테스트는 중요하다. 그렇게 주장하는 데는 많은 이유가 있다.

단지 코드 몇 줄을 바꾸는 것으로 자기도 모르게 앱을 망가뜨릴 수도 있다.
코드를 수정한 후에 테스트를 수동으로 돌리는 일은 성가시다.
테스트는 edge case¹를 문서화 하는 데 도움을 준다.
이직을 원하는 개발자 입장에서 다른 지원자보다 더 높은 경쟁력을 가질 수 있다.

안타까운 얘기지만, 테스트 케이스를 작성하는 일은 처음 시도하는 사람에게 쉬운 일이 아니다. 그것은 마치 완전히 다른 환경에서 개발을 진행하는 것과 유사하다. 당신은 대체 무엇을 테스트해야 할지 모를 수도 있다. 간단한 테스트 케이스를 작성에도 에러가 계속 발생해서 많은 시간이 걸릴 수도 있다. 당신은 브라우저를 기반으로 개발하는 일에 익숙하다. 브라우저는 물론 훌륭한 도구다. 하지만 테스트는 브라우저에서 작성하는 것과 같은 방식으로 동작하지 않는다.

하지만 테스트가 그렇게 어려울 것은 없다. 올바른 접근법을 가진다면 초보자라도 확신을 가지고 테스트를 작성할 수 있다.

이 블로그 포스트의 목표는 당신의 첫 번째 테스트를 위한 가이드가 되는 것이다. 우리는 조그만 예제 앱과 함께 테스트를 작성해 나갈 것이다. 그리고 무엇을 테스트 해야 할지, 무엇을 테스트 하면 안되는지에 대해 이야기 할 것이다. 우리는 시행착오 없이 확신을 갖고 테스트를 작성할 수 있는 다양한 테크닉을 살펴보려 한다.

이 블로그 포스트는 꽤 길고 심층적인 내용을 다루고 있다. 아래의 차례를 통해 어떤 내용이 나올지 미리 확인할 수 있을 것이다.

React 앱 테스팅 개요
테스트에 사용할 어플리케이션
무엇을 테스트해야 하는가?
테스트 작성
어둠 속에서 찔러보지 말라
렌더링된 DOM 트리에 접근하는 방법
DOM 요소와 상호작용 하기
올바른 페이지가 렌더링 되었는지 확인하기
폼 테스팅
셋업 함수에서 중복 방지하기
폼을 변경하고 제출하기
ARIA role 없이 요소에 접근하기
데이터 기다리기
API 요청 위조하기(mocking)
Mock 함수 테스팅

이 포스트는 많은 정보를 담고 있다. 구체적인 내용을 기억하는데 도움을 주기 위해 나는 모든 팁과 리소스의 목록을 담은 한장의 요약본(cheatsheet)를 만들었다. 그것은 글 마지막 부분에서 얻을 수 있다. ²

테스트할 어플리케이션을 살펴보기 전에 일반적인 React 앱을 테스트하는 방법에 대해 전반적으로 살펴보자.

React 앱 테스팅 개요

큰 규모의 앱을 작업할 때 중요한 파트의 코드를 건드리는 일은 무섭게 느껴질 수 있다. 사소한 수정도 매우 중요한 기능을 망가뜨릴 수 있기 때문이다. 개발자는 이런 위험을 최소화하기 위해 테스트를 작성한다.

테스트 작성의 목적은 당신에게 그 앱이 제대로 동작한다는 확신을 주는 데 있다. 만약 모든 중요한 유즈케이스(use-case)가 테스트로 커버되어 있다면 당신이 무언가를 망가뜨렸을 때 빠르게 피드백을 얻을 수 있을 것이다.

나는 이런 테스트가 개발자와 비지니스에 설명할 수도 없을 정도로 큰 이득을 준다고 힘주어 말할 수 있다.

현재 React 앱의 자동화된 테스트에 꼭 맞는 라이브러리는 Jest 와 @testing-library/react(aka Testing Library)의 조합이다.

물론 다른 라이브러리도 있다. Jest는 Mocha, Jasmine, 또는 AVA로 대신할 수 있고, Testing Library는 많은 개발자들이 사용하고 있는 Enzyme으로 대체할 수 있다.

Testing Library는 테스트를 사용자 관점에서 접근한다. 그러므로 그것은 우리를 자연스럽게 복수의 컴포넌트가 함께 테스트되는 Integration Test³로 이끈다.

예를 들어 어떤 버튼을 생각해보자. Testing Library를 사용하면 버튼이 클릭되었을 때 onClick prop이 호출되는지는 잘 테스트하지 않는다. 그보다 특정 버튼이 특정 효과를 발동시키는지 확인한다. 예를 들어 삭제 버튼을 클릭하면 확인 모달이 열리는지 테스트한다.

테스트에 사용할 어플리케이션

이 앱은 ooloo.io에 있는 내 강의에서 개발하는 앱의 간단한 버전이다. 만약 준비가 되지 않은 것 같다면, 전문적인 팀이 어떻게 실무에서 사용하는 앱을 개발 하는지 배울 수 있다.

이 앱은 사용자에게 서브레딧(subreddit)에서 가장 인기있는 포스트를 찾을 수 있도록 한다. 이것은 매우 간단한 앱으로 제목과 몇 개의 링크, 폼을 가지고 있을 뿐이다. 하지만 당신의 첫 번째 테스트를 위해서 좋은 예제가 될 것이다.

헤더에 있는 다른 페이지를 가리키는 링크는 단지 헤드라인만 포함한 플레이스홀더 이상의 역할을 한다. 중요한 기능은 바로 다른 페이지로의 네비게이션이다.

1개의 텍스트 입력을 가진 폼에서는 사용자가 검색할 서브레딧의 제목을 입력할 수 있다.

제출(submit) 버튼을 클릭하면 Reddit API로 요청을 보낸다. 응답을 기다리는 동안 앱은 로딩 상태를 표시한다. 데이터는 응답을 받는 대로 표시되며, 단순함을 위해 상위 포스트의 개수만 표시한다.

전체 코드는 이 저장소에서 확인할 수 있다. 원한다면 저장소를 클론한 후에 이 글을 계속 읽어도 좋다.

무엇을 테스트해야 하는가?

처음으로 떠오르는 질문은 “무엇을 테스트해야 하는가”일 것이다. 예제로 앱에 있는 폼 컴포넌트를 살펴보자. 코드는 아래와 같다.

function Form({ onSearch }) {
  const [subreddit, setSubreddit] = useState('javascript');

  const onSubmit = (event) => {
    event.preventDefault();
    onSearch(subreddit);
  };

  return (
    <FormContainer onSubmit={onSubmit}>
      <Label>
        r /
        <Input
          type="text"
          name="subreddit"
          value={subreddit}
          onChange={(event) => setSubreddit(event.target.value)}
        />
      </Label>

      <Button type="submit">
        Search
      </Button>
    </FormContainer>
  );
}

폼의 입력값은 상태 변수(subreddit)와 계속 연동된다. 제출 버튼을 클릭하면 상위 컴포넌트에서 전달된 onSearch prop을 호출한다.

어떻게 데이터를 가져오는지도 궁금할 것이다. 그것은 폼 컴포넌트의 부모인 홈 페이지 컴포넌트에서 이뤄진다.

function Home() {
  const [posts, setPosts] = useState([]);
  const [status, setStatus] = useState('idle')

  const onSearch = async (subreddit) => {
    setStatus('loading');
    const url = `https://www.reddit.com/r/${subreddit}/top.json`;
    const response = await fetch(url);
    const { data } = await response.json();
    setPosts(data.children);
    setStatus('resolved');
  };

  return (
    <Container>
      <Section>
        <Headline>
          Find the best time for a subreddit
        </Headline>

        <Form onSearch={onSearch} />
      </Section>

      {
        status === 'loading' && (
          <Status>
            Is loading
          </Status>
        )
      }
      {
        status === 'resolved' && (
          <TopPosts>
            Number of top posts: {posts.length}
          </TopPosts>
        )
      }
    </Container>
  );
}

홈 페이지 컴포넌트는 API 응답 데이터를 상태 변수에 저장하며 로딩 상황을 계속 추적한다. 폼에 의해 검색이 실행되면 Reddit API로 요청이 전달된다. 데이터가 도착하면 상태 변수들(posts, status)이 모두 업데이트되며 결과가 폼 아래에 표시된다.

이제 당신은 코드에서 중요한 부분을 살펴보았고 더 진행하기 전에 스스로 다음의 질문의 답해 보기 바란다: 당신은 저 두 컴포넌트를 어떻게 테스트하겠는가?

우리는 아마도 위의 컴포넌트를 살펴보고선 유닛 테스트를 먼저 작성하려 들 것이다. 우리는 아마 상태가 제대로 저장되는지 확인하고 현재의 subreddit 값과 함께 onSearch prop이 호출되는지 확인하길 원할 것이다. 이것이 많은 개발자들이 Enzyme으로 테스트하는 방식이다.

하지만 Testing Library를 사용한다면 상태 변수에 접근하지 않는다. prop으로 전달된 함수를 테스트하긴 할 것이지만, 상태 변수가 정확한 값을 가지고 있는지는 테스트하지 않는다.

이것은 약점이 아니다. 이것은 강점이다. 상태 관리는 컴포넌트의 구현 세부사항(implementation detail)이다. 상태 변수가 지금은 컴포넌트에 있지만 부모로 옮겨질 수도 있고 그렇게 해도 앱은 똑같이 동작해야 한다⁴.

사실 React 자체도 구현 세부사항이다. 우리는 앱 전체를 유저가 모르는 사이에 Vue.js로 옮길 수도 있다.

앱의 코드와 그것의 구현 방식에 집중하는 대신, 우리는 단순히 유저의 관점을 취한다. 그리고 이 관점은 우리가 앱의 중요한 부분을 테스트하는데 집중하도록 강제로 이끈다.

우리가 이 테스팅 철학을 받아들인다면 테스팅은 더 이상 알기 어렵고 무서운 것이 아니게 된다.

노트: 사용자는 어플리케이션의 말단 사용자일 수도 있고 당신이 개발한 컴포넌트를 사용하는 개발자가 될 수도 있다. 당신이 소속된 팀의 다른 개발자들도 사용하는 이미지 갤러리를 개발했다고 가정해보자. 예를 들어 당신은 props가 변경되었을 때 앱이 제대로 동작하는지 테스트해야 한다.

좋다, 사용자 관점이다. 그러니 어플리케이션에서 저 컴포넌트에 대해서는 잠시 잊고 사용자가 직면하는 부분에 대해 집중해 보자. 사용자 입장에서 앱이 제대로 기능하기 위해서는 무엇이 중요할까?

일단 테스트할 앱을 클릭해서 사용해 보자. 앱 테스트에서 중요한 것은 그렇게 직접 사용해 본 내용들이다. 그에 대해서는 이미 위에서 설명했었다.

사용자는 폼 입력에 값을 입력하고 제출 버튼을 누른다.
데이터를 기다리는 동안 로딩 메시지가 표시된다.
API 응답이 도착하면 데이터가 렌더링된다.

사용자는 홈 페이지나 폼 컴포넌트가 입력 값을 저장하는지 아닌지는 신경쓰지 않는다. 사용자 입장에서 응답으로 받은 포스트 데이터가 상태 변수에 저장이 되는지, 데이터 구조가 어떤지는 상관할 바가 아니다. 유저에게 중요한 것은 오직 위의 세 단계다.

물론, 우리는 헤더에 있는 링크도 테스트해야 한다. 어찌됐든 깨진 링크(예. 회원 가입 페이지로 가는 링크)는 비지니스에 문제를 줄 수 있기 때문이다.

노트: 보통 우리는 엣지 케이스를 테스트해야 하고 폼에서 발생하는 에러도 처리해야 한다. 하지만 그것까지 이 블로그 포스트에서 다루기에는 너무 양이 많다.

테스트 작성

지난 섹션의 내용을 빨리 훑어보고 알게 된 것들을 기술적인 언어로 풀어 보자:

우리는 2개의 테스트 묶음(suite)를 작성할 것이다. 하나는 헤더 링크를 위한 것이며 나머지 하나는 폼을 위한 것이다. 헤더를 위해서는 링크가 정확한 대상을 가리키는지 테스트해야 한다. 그리고 폼을 위해서는 입력 값 변경, 값 제출, 로딩 상태, 그리고 결과 렌더링을 테스트해야 한다.

헤더를 위한 테스트부터 시작해 보자. 먼저, src/app.js 를 열어서 작성되어 있는 테스트를 제거한다. 그리고, 헤더 테스트 묶음을 Jest의 describe 함수를 사용해서 정의하자.

노트: 테스트를 꼭 describe로 감쌀 필요는 없지만, 이 방법은 관련 있는 테스트를 한곳에 모아 준다. 그리고 터미널 출력을 보다 읽기 쉽게 만들어 주며 반복적인 테스트 메시지 출력을 막아 준다. 만약 테스트 파일이 길어지면 에디터에서 필요없는 테스트 코드 블록을 접어서 가독성을 높일 수도 있다.

describe('Header', () => {

});

테스트 케이스는 test(...) 로 정의될 수 있다. 그리고 it(...) 으로 대체할 수도 있다. Jest는 둘 다 제공한다.

describe('Header', () => {
  test('"How it works" link points to the correct page', () => {

  });
});

우리는 헤더 컴포넌트를 분리된 상태가 아닌 어플리케이션 컨텍스트 안에서 테스트하고 싶다. 그것이 우리가 이 테스트에서 App 컴포넌트를 사용해야 하는 이유다.

App 컴포넌트는 아래와 같이 작성되어 있다.

import React from 'react';
import { Switch, Route } from 'react-router-dom';
import GlobalStyle from './GlobalStyle';
import Header from './components/Header';
import Home from './pages/Home';

function App() {
  return (
    <>
      <GlobalStyle />
      <Header />

      <main>
        <Switch>
          <Route path="/how-it-works">
            <h1>How it works</h1>
          </Route>
          <Route path="/about">
            <h1>About</h1>
          </Route>
          <Route path="/">
            <Home />
          </Route>
        </Switch>
      </main>
    </>
  );
}

이 App 컴포넌트는 실제로 운영되고 있는 많은 어플리케이션처럼 React Router를 사용한다. 그리고 헤더 컴포넌트와 홈 페이지를 포함한 몇 개의 라우트를 렌더링한다.

참고로 여기에는 Router 컴포넌트가 없다. 테스트를 위해 Router는 App 컴포넌트를 렌더링하는 index.js 파일에 있다. 테스트 중에는 App 컴포넌트를 MemoryRouter로 감쌀 것이다.

그래서 첫 번째 단계로, 우리는 앱 컴포넌트를 렌더링한다. Testing Library는 주어진 컴포넌트로 DOM을 생성하는 render 함수를 제공한다

import { render } from '@testing-library/react';
import App from './App';

describe('Header', () => {
  test('"How it works" link points to the correct page', () => {
    render(
      <MemoryRouter>
        <App />
      </MemoryRouter>
    );
  });
});

이 앱은 create-react-app으로 만들어졌기 때문에 Testing Library 사용에 필요한 모든 것은 이미 설치되어 있다.

어둠 속에서 찔러보지 말라

테스트를 작성하기 시작하면 당신은 마치 어두운 상자 안을 걷는 듯한 느낌을 받을 수 있다. 안에서 어떤 일이 일어나고 있는지 알 수가 없다. 그리고 당신은 브라우저에서 개발자 도구를 열어 DOM 트리를 직접 확인하며 작업하는 일이 익숙해져 있다.

테스트를 작성하기 시작하면 새로운 환경에 적응할 필요가 있다. 테스트 과정에서 무엇이 일어나고 있는지 이해할 방법이 필요하다. 만약 테스트가 어떤 요소를 찾을 수 없어서 실패를 했는데, 원인을 파악할 수 없다면 어떻게 할 것인가?

바로 그런 상황에서 debug 함수로 무척 편리하게 대처할 수 있다. 그것을 사용하면 원하는 실행 지점에서 DOM 트리를 출력할 수 있다. 브라우저의 개발 도구처럼 편리하고 상호작용적이지는 않지만 당신에게 무슨 일이 일어나고 있는지 확실히 파악할 수 있도록 도와준다.

당신은 이제 막 시행착오에 기대지 않는 테스트를 작성하기 시작했다. 그러므로 시간이 조금 걸리겠지만 각각의 단계마다 debug 함수를 사용하자.

import { render, screen } from '@testing-library/react';

describe('Header', () => {
  test('"How it works" link points to the correct page', () => {
    render(
      <MemoryRouter>
        <App />
      </MemoryRouter>
    );
    screen.debug();
  });
});

yarn test 명령어로 테스트를 실행하면 아래의 결과를 보게 될 것이다.

훌륭하다. 출력에서 몇개의 링크를 포함하는 헤더를 확인할 수 있고, 그것은 우리가 테스트하고 싶은 “How it works” 링크를 포함하고 있다. 이제 우리는 저것에 접근할 수 있는 방법과 조작 방법을 알아야 한다.

렌더링된 DOM 트리에 접근하는 방법

렌더링된 요소 접근에 선호되는 방법은 Testing Library에서 export된 screen 객체를 사용 하는 것이다.

screen 객체는 다양한 쿼리를 제공한다. 그 쿼리들은 DOM에 접근할 수 있는 함수들이다. 아래에 몇개의 예제가 있다.

getBy* 쿼리 (ex. getByTestId, getByText, getByRole): 이 함수들은 동기적(synchronous)이며 그 요소가 현재 DOM 안에 있는지 확인한다. 그렇지 않으면 에러를 발생시킨다.
findBy* 쿼리 (ex. findByText): 이 함수들은 비동기적(asynchronous)이다. 그 요소를 찾을 때까지 일정 시간(기본 5초)을 기다린다. 만약 그 시간이 지난 후에도 요소를 찾을 수 없으면 에러를 발생시킨다.
queryBy* 쿼리: 이 함수들은 getBy* 처럼 동기적이다. 하지만 요소를 찾을 수 없어도 에러를 발생시키지 않는다. 단지 null 값을 리턴한다.

위에서 제시한 쿼리만 해도 요소에 접근할 수 있는 많은 방법을 포함하고 있고, 심지어 Testing Library가 제공하는 함수의 전체 목록도 아니다. 그렇다면 이것들 중에서 “How it works” 링크에 접근하기 위해서는 무엇을 사용해야 할까?

우리는 헤더가 항상 존재한다는 사실을 이미 알고 있다. 표시될 때까지 기다릴 필요가 없다. 이는 우리의 옵션을 getBy* 쿼리로 좁힌다. 하지만 그 중에서 무엇을 골라야 할까?

처음 보기에는 getByTestId가 좋은 선택처럼 보인다. 우리가 해야 할 일은 확인하고 싶은 요소에 테스트 ID를 붙이는 일 뿐이다:

<div data-testid="some-content">
  Some content
</div>

이제 우리는 div 요소에 getByTestId('some-content')를 사용해서 접근할 수 있다. 간단하다, 그렇지 않은가?

하지만 이 방법은 단지 테스트에 통과하기 위해 코드를 수정해야 한다는 말이다. 그다지 이상적이지 않다. 그러니 더 좋은 방법은 없을까?

Testing Library의 문서는 훌륭하며 읽어 볼 가치가 있다. 사실 거기에는 어떤 쿼리를 사용하는 것이 적합한지를 설명하는 문서가 있다.

모든 사람에게 접근 가능한 쿼리는 높은 우선 순위를 가진다. 그 중에서, getByRole이 가장 알맞은 쿼리가 되어야 한다. getByAltText 또는 getByTestId는 오직 예외 상황에서만 사용되어야 한다. 그리고 가장 낮은 우선순위는 getByTestId다. 당신은 반드시 다른 선택의 여지가 없는 상황에서만 테스트 ID를 사용해야 한다.

좋다, 그럼 getByRole을 한번 사용해 보자. 첫번째 파라미터는 대상 요소의 ARIA role이어야 한다. 여기서는 link를 사용할 수 있다. 한 페이지에는 한 개 이상의 링크가 있기 때문에 요소를 찾기 위해name 옵션을 추가할 필요가 있다.

render(
  <MemoryRouter>
    <App />
  </MemoryRouter>
);

const link = screen.getByRole('link', { name: /how it works/i });

여기서 문자열 'How it works' 대신 정규표현식 /how it works/i를 사용했음을 확인하자. 이 방법으로 대소문자가 달라서 요소를 찾지 못하는 경우를 방지할 수 있다(예. CSS text-transformation 속성을 사용해서 대소문자가 바뀌는 경우). 그리고 정규표현식을 사용하면 문자열의 일부를 타겟으로 삼을 수도 있다. /how it/i 정규표현식으로 검색에 성공하겠지만, 'How it' 으로는 실패할 것이다.

파일을 저장하면 테스트가 자동으로 실행된 후 성공했다는 메시지가 뜰 것이다. 이는 우리가 그 링크를 찾았다는 의미다!

우리가 이제 막 시작했기 때문에 모든 것이 예상했던 대로 작동하는지 한번 더 확인하는 편이 좋다. debug 함수를 기억하는가? 많은 개발자는 그것에 파라미터를 넣어도 되는지 모른다. 파라미터에 옵션을 전달해서 콘솔에 1개의 요소만 출력할 수 있다.

const link = screen.getByRole('link', { name: /how it works/i });
screen.debug(link);

아래의 내용을 터미널에서 보게 될 것이다. 출력된 것은 “How it works” 링크. 정확히 우리가 예상했던 대로다.

DOM 요소와 상호작용 하기

이제 우리는 DOM 요소에 접근하는 방법을 알게 되었다. 구체적으로는 “How it works” 링크다. 하지만 그것으로는 충분하지 않다. 우리가 테스트하고 싶었던 것을 기억하는가?

링크는 정확한 페이지를 가리켜야 한다.

링크가 우리를 타겟으로 이끌기 위해서는 일단 그것을 클릭해야 한다. Testing Library에는 두 가지 옵션이 있다.

@testing-library/react 모듈이 export하는 fireEvent.click 함수를 사용한다.
@testing-library/user-event 모듈이 export하는 click 함수를 사용한다.

가능하다면 @testing-library/user-event를 사용하는 것이 권장된다. 그것은 실제 유저 이벤트에 가까운 더 많은 이벤트(예. 더블클릭)를 제공한다.

그리고 놀라운 사실: package.json 파일을 살펴보면 create-react-app에는 이것이 기본적으로 설치 되어 있다.

그러면 링크를 클릭 해보자.

import React from 'react';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import App from './App';

describe('Header', () => {
  test('"How it works" link points to the correct page', () => {
    render(
      <MemoryRouter>
        <App />
      </MemoryRouter>
    );
    const link = screen.getByRole('link', { name: /how it works/i });
    userEvent.click(link);
  });
});

올바른 페이지가 렌더링 되었는지 확인하기

다음은, 유저가 올바른 페이지로 보내졌는지 확인해야 한다.

그걸 확인할 수 있는 방법 중 하나는 URL을 확인하는 것이다. 그리고 react-router 문서에서 설명하고 있는 방법으로 가능하다. 하지만 유저는 사실 URL에는 신경을 안쓰지 않는가? 그리고 URL이 정확하다 해도 앱은 404 메시지를 표시할 가능성이 있다.

유저가 확인하는 부분은 정확한 페이지를 표시하는지 여부다. 아래의 영상은 브라우저에서 링크를 클릭했을 때 화면이 어떻게 바뀌는지 보여준다.

링크를 클릭하면 “How it works” 제목이 있는 페이지를 나오길 기대한다.

만약 제목이 ARIA role을 가지고 있다면 정확한 페이지가 표시되었는지 확인하기 위해 getByRole 함수를 다시 사용할 수 있다. MDN 문서에 의하면 제목 요소는 heading role을 가진다.

userEvent.click(link);

screen.getByRole('heading', { name: /how it works/i });

이 테스트는 성공한다. 이는 문서 안에 제목이 있다는 의미다. 그리고 또 우리가 정확한 페이지로 이동했다는 것을 의미한다. 아주 훌륭하다!

마지막으로 하나 더: 우리는 어떤 요소가 렌더링 되었는지 확인하는데 getBy* 를 사용하지 말아야 한다. 대신 expect(...).toBeInDocument() 로 확인해야 한다.

아래에서 전체 테스트 코드를 확인할 수 있다.

test('"How it works" link points to the correct page', () => {
  render(
    <MemoryRouter>
      <App />
    </MemoryRouter>
  );

  const link = screen.getByRole('link', { name: /how it works/i });
  userEvent.click(link);

  expect(
    screen.getByRole('heading', { name: /how it works/i })
  ).toBeInTheDocument();
});

테스트는 무척 짧지만 우리가 여기까지 오는 데 많은 시간이 걸렸다. 그리고 그것은 많은 개발자가 처음 테스트를 시작했을 때 느끼는 감정이기도 하다. 하지만 일단 익숙해지면 훨씬 쉽고 빠르게 할 수 있을 것이다.

폼 테스트를 시작하기 전에 하고 싶은 말: 우리는 단지 1개의 링크를 테스트 했을 뿐이다. 당신은 아마 헤더의 왼쪽에 홈 페이지로 이동시키는 로고와 “About” 페이지로 이동시키는 또 다른 링크가 헤더 오른편에 있다는 사실을 알고 있었을 것이다.

그들 두 링크에 대한 테스트는 당신에게 훈련으로 남겨 두려고 한다. 2가지 짧은 힌트를 주자면:

로고를 감싸고 있는 링크는 getByRole('link', { name }) 으로 테스트할 수 있다. name에 무엇을 넣어야 할지 모르겠다면, screen.debug() 의 결과를 확인해 보길 바란다.
“How it works”, “About” 링크의 테스트는 test.each 함수로 묶을 수 있다.

다음 글: [번역] 초보자를 위한 React 어플리케이션 테스트 심층 가이드 (2)

알고리즘이 처리하는 데이터의 값이 알고리즘의 특성에 따른 일정한 범위를 넘을 경우에 발생하는 문제. 예를 들어 -128~127 까지의 값을 저장할 수 있는 8비트 변수에 범위를 벗어나는 값을 할당하는 경우 등.
↩
원문 최하단에서 메일 주소 입력을 통해 받아볼 수 있음
↩
통합 테스트. 유닛 테스트의 다음 단계로 유닛/컴포넌트를 그룹으로 조합해서 테스트하는 것. 이 테스트의 목적은 컴포넌트가 연결되었을 때 발생하는 문제를 노출시키기 위함이다.
↩
요구사항 문서에 있는 스펙은 개발자마다 다른 방법을 사용해서 구현할 수 있다. 그렇게 서로 달라질 수 있는 내용을 구현 세부 사항이라고 한다. 구현 세부 사항이 다르면 테스트 방법도 서로 달라야 할 것이다. 예를 들면 배열 정렬을 구현할 때 Array.prototype.sort를 사용할 수도 있고 직접 구현한 알고리즘을 사용할 수도 있다. 중요한 것은 정렬이 제대로 되는지 여부이며, 테스트도 거기에 초점을 맞춰야 한다는 관점.
↩

Gatsby 웹사이트에 적용한 다크 모드

rhostem — Thu, 25 Jun 2020 00:00:00 GMT

몇년 전부터 Windows, macOS, iOS등의 운영체제가 다크 모드를 지원하기 시작했고 그와 더불어 다크 모드를 지원하는 웹사이트도 많아졌다. 다크 모드는 어두운 곳에서의 가독성 향상은 물론 전력 소모도 줄어들기 때문에 무척 유용하다. 개인적으로는 낮에도 다크 모드로 노트북과 휴대폰을 사용하고 있기도 하다. 그래서 직접 제작한 이 블로그에도 다크 모드를 적용하기로 했다.

요구사항

다크 모드를 개발하기 위해 정의한 요구사항은 다음과 같다.

웹사이트는 라이트, 다크 2개의 컬러 테마를 가진다.
웹사이트에 최초 방문시 운영체제의 화면 스타일로 테마를 설정한다.
웹사이트의 테마 설정은 사용자의 브라우저에 저장해서 재방문 시에도 유지한다.
테마 전환 버튼을 제공해서 사용자가 직접 바꿀 수 있도록 한다.

웹사이트에 스타일 테마 적용

styled-components를 사용했다가 실패한 경험

이 블로그 웹사이트(blog.rhostem.com)는 Gatsby로 구현되어 있다. Gatsby는 React에 기반한 프레임워크라서 styled-components를 사용해서 개발을 시작했다. styled-components에는 컴포넌트에 테마 스타일 객체를 전달할 수 있도록 ThemeProvider 컴포넌트를 제공하고 있기도 하다.

const theme = {
  colors: {
    body: '#fefefe'
  }
}

const DefaultLayout = styled.div`
  background: ${({ theme }) => theme.colors.body};
`

function Layout() {
  return (
    <ThemeProvider theme={theme}>
      <DefaultLayout>
        <App></App>
      </DefaultLayout>
    </ThemeProvider>
  )
}

ThemeProvider에 전달한 테마 객체는 styled-component의 템플릿 리터럴 안에서 인터폴레이션을 통해 접근할 수 있다.

처음에는 이 방식으로 접근해서 테마 구현을 끝냈었다. 그런데 개발 서버에서는 문제가 발생하지 않았지만, Gatsby를 빌드한 후에 띄운 서버에서는 문제가 발생한다는 사실을 뒤늦게 알게 되었다. Gatsby는 빌드 결과물에 HTML과 CSS를 모두 포함하고 있기 때문이었다.

Gatsby는 개발 모드에서 페이지에 접근하면 서버 렌더링을 하지 않는다. 일반적인 리액트 앱처럼 모든 처리를 클라이언트 사이드에서 하며 styled-components 같은 css-in-js 라이브러리로 작성한 스타일은 모두 앱이 구동된 후에 추가된다. 하지만 빌드를 한 후 페이지에 접근하면 styled-components로 작성한 스타일이 모두 style 태그에 추가된 상태의 HTML 페이지를 제공한다.

이런 특징이 테마가 분리되기 전에는 문제가 전혀 없었다. 하지만 테마가 분리된 후에는 문제가 생겼다. 왜냐하면 빌드 시점에 설정한 테마가 먼저 제공된 후 브라우저에 저장된 사용자의 테마를 적용하기 때문이다. 예를 들어 기본 테마를 “라이트”로 해서 빌드를 해서 배포를 했는데, 사용자가 “다크” 테마를 선택한 후 새로 고침을 하면 “라이트” 테마가 우선 표시된 후 “다크” 테마로 바뀌는 깜빡임 현상이 발생하게 된다.(테마 컬러 전환에 CSS transition 이펙트를 넣어뒀더니 눈이 아팠다…)

서버 사이드 렌더링 웹사이트라면 쿠키나 DB에 저장된 사용자의 테마를 가져와서 깜빡임이 없도록 할 수도 있겠지만 Gatsby는 완전히 프리 렌더링된 정적인 웹사이트라서 불가능하다. 그렇다고 브라우저 스토리지에서 테마 설정값을 가져오기 전까지 웹사이트를 표시하지 않는다? 그것도 사용자에게 웹사이트 사용을 위해 기본적으로 필요한 네트워크 딜레이에 자바스크립트 파싱 및 실행 딜레이까지 추가하는 행위라서 좋지 않다.

결국 styled-component의 ThemeProvider는 버리고, CSS 커스텀 속성을 사용하기로 했다.

CSS Custom Properties

CSS 커스텀 속성은 CSS에서 변수를 사용할 수 있도록 한다. 변수는 어디에 선언해도 상관없지만, 전역에서 사용할 수 있도록 하려면 :root 가상 선택자에 선언한 후 사용하면 된다.

:root {
  --main-bg-color: brown;
}

body {
	background: var(--main-bg-color); 
}

그리고 테마 설정을 위해서는 커스텀 속성을 아래와 같이 작성할 것이다.

body {
  &.light {
    --text: rgba(46, 46, 46, 0.95);
  }

  &.dark {
    --text: rgba(215, 215, 215, 0.9);
  }  
}

이렇게 하면 body 태그에 어떤 클래스가 붙느냐에 따라 같은 이름을 가진 변수라도 다른 값을 가지게 된다. 다음으로 필요한 작업은 웹사이트 로딩 시점에 테마를 확인해서 body 태그에 클래스를 추가하는 것이다.

시스템 컬러 설정으로 테마 초기화

아까 발생했던 문제는 테마를 변경하는 과정이 HTML을 기반으로 DOM 트리가 구성된 후 100 킬로바이트가 넘는 자바스크립트 파일을 파싱한 후에 천천히(컴퓨터 관점에서는) 이뤄졌기 때문이다. 그렇다면 깜빡임 현상을 없애기 위해서는 테마를 설정하는 시점이 스타일시트를 불러온 후, DOM 트리가 구성되기 전이어야 한다. 그러기 위해서는 body 태그의 첫번째 child element로 script 태그를 추가하고 그 안에 자바스크립트를 작성하면 된다.

Gatsby에 html.js 파일에 우선 실행될 스크립트 추가

Gatsby에서 저것을 가능하게 하려면 gatsby-ssr.js 파일에 onRenderBody 모듈을 작성해도 되고, html.js 파일을 추가해도 된다. html.js 파일은 Gatsby에서 index.html 파일 역할을 한다(Next.js의 _document.js와 유사).

html.js 파일의 구성은 아래와 같다. 다른 내용은 자세히 볼 필요 없고, body 태그 아래에 있는 script 태그의 dangerouslySetInnerHTML에 테마 설정에 필요한 스크립트를 추가할 것이라는 사실만 알면 된다.

import React from 'react'

export default class HTML extends React.Component {
  render() {
    return (
      <html {...this.props.htmlAttributes}>
        <head>
          <meta charSet="utf-8" />
          <meta httpEquiv="x-ua-compatible" content="ie=edge" />
          <meta
            name="viewport"
            content="width=device-width, initial-scale=1, shrink-to-fit=no"
          />
          {this.props.headComponents}
        </head>

				{/* 빌드 시점의 테마 설정을 위해 className에 light를 추가했다. */}
        <body {...this.props.bodyAttributes} className="light"> 
          <script
            dangerouslySetInnerHTML={{
              __html: `
								// 테마 초기화 코드가 들어갈 곳
            `,
            }}
          />
          {this.props.preBodyComponents}
          <div
            key={`body`}
            id="___gatsby"
            dangerouslySetInnerHTML={{ __html: this.props.body }}
          />
          {this.props.postBodyComponents}
        </body>
      </html>
    )
  }
}

테마 초기화 코드

소스 코드는 https://github.com/gaearon/overreacted.io/blob/master/src/html.js 파일을 참고했다.

(function() {
	window.__onThemeChange = function () {} // 컴포넌트에서 정의할 테마 변경 콜백

	var preferredTheme // 초기화에 사용할 테마
	try {
	  preferredTheme = localStorage.getItem('theme') // 로컬 스토리지에 있는 것 사용
	} catch (err) {}

	// 테마 설정 함수
	window.__setPreferredTheme = function (newTheme) {
	  window.__theme = newTheme // 테마는 전역 변수에 저장
	  preferredTheme = newTheme
	  document.body.className = newTheme // 바디에 클래스 추가
	  window.__onThemeChange(newTheme) // 콜백 실행

	  try {
	    localStorage.setItem('theme', newTheme)
	  } catch (err) {}
	}

	// 컬러모드 미디어 쿼리 객체를 가져온다
	var darkQuery = window.matchMedia('(prefers-color-scheme: dark)')

	// 컬러모드 변경 탐지 이벤트 리스너 추가
	darkQuery.addListener(function (e) {
	  window.__setPreferredTheme(e.matches ? 'dark' : 'light')
	})

	// 테마 설정. 저장된 테마가 없으면 시스템 설정을 사용한다.
	window.__setPreferredTheme(
	  preferredTheme || (darkQuery.matches ? 'dark' : 'light')
	)
})();

코드는 IIFE(즉시실행) 함수에 둘러싸여 있어 바로 실행된다. 언더바 두개(__)가 붙은 변수와 함수는 나중에 React 모듈에서 사용하기 위한 목적으로 window 객체에 추가되었다.

window.matchMedia는 주어진 미디어 쿼리를 분석한 결과를 나타내는 MediaQueryList 객체를 반환한다. prefers-color-scheme: dark 쿼리로 생성한 객체의 matches 는 boolean 값으로 현재 컬러 스타일이 다크 모드인지 아닌지를 나타내며, addListener 함수는 웹사이트에서 시스템이 컬러 스타일을 변경하는 이벤트를 탐지할 수 있도록 한다.

여기까지 하면 시스템 컬러 설정을 웹사이트의 테마에 반영할 수 있다. 남은 것은 사용자가 직접 테마를 변경할 수 있도록 하는 토글 버튼이다.

테마 토글 기능

토글 버튼 콜백에서는 html.js에 추가한 __setPreferredTheme 함수를 호출해야 한다. 그리고 시스템 컬러 변경 이벤트를 토글 버튼에도 반영하기 위해 비어있는 __onThemeChange 함수에 토글 버튼의 상태를 변경하는 함수를 재할당해주면 된다.

테마 초기화 커스텀 훅

export const useDarkMode = () => {
  const [theme, setTheme] = useState(null)

  const toggleTheme = useCallback(
    () => {
      const nextTheme =
        theme === themeNames.LIGHT ? themeNames.DARK : themeNames.LIGHT

      setTheme(nextTheme)
      window.__setPreferredTheme(nextTheme)
    },
    [theme]
  )

  useEffect(() => {
		// 클라이언트에서는 window.__theme 값으로 테마를 설정한다
    if (typeof window === 'object') {
      setTheme(window.__theme)
    }

		// 테마 변경 시점에 실행할 로직을 추가한다. 
		// __setPreferredTheme은 변경할 수 없으므로 여기에 React에서 사용할 수 있는 로직을 추가한다.
    window.__onThemeChange = newTheme => {
      setTheme(newTheme)
    }
  }, [])

  return { theme, toggleTheme }
}

나는 개인적으로 데스크탑용, 모바일용 토글 버튼이 하나씩 있어서 커스텀 훅을 구현하고 컨텍스트를 사용해서 상태와 함수를 컴포넌트에 전달했지만, 필요 없다면 토글 버튼에 상태 관리 로직을 직접 구현해도 될 것이다.

const DefaultLayout = ({ children }) => {
  const { theme, toggleTheme } = useDarkMode()

  return (
    <DarkModeContext.Provider
      value={{
        theme,
        toggleTheme,
      }}>
      <Navbar />
      <Page>
        <PageContents>{children}</PageContents>
        <Footer />
      </Page>
    </DarkModeContext.Provider>
  )
}

const DarkmodeToggleButton = () => {
  const { theme, toggleTheme } = useContext(DarkModeContext)
  return (
    theme && (
      <ToggleButton onClick={toggleTheme}>
        <ToggleTrack>
          <div className="moon" />
          <div className="sun" />
          <ToggleThumb themeName={theme} />
        </ToggleTrack>
      </ToggleButton>
    )
  )
}

특히 토글 버튼에서 theme 값이 truthy한 값이어야 렌더링 되도록 조건을 달았는데, 저렇게 하지 않으면 토글 버튼이 처음부터 브라우저에 저장된 테마가 적용되지 않는다. 대신 토글 버튼의 themeName props가 null일 때 표시되는 값에서 저장된 값으로 전환되는 깜빡임 현상이 발생한다. 저 부분은 버튼이 화면에 나타나기까지 딜레이가 조금 발생하더라도 어쩔 수 없다.

이렇게 테마 분리, 시스템 테마 반영 및 탐지, 컬러 테마 변경 UI까지 구현이 끝났다. 참고한 자료들은 다음과 같다.

참고 자료

dynamic import로 줄여본 next.js 앱의 최초 로딩 시간

rhostem — Sun, 10 May 2020 00:00:00 GMT

dynamic import

Next.js는 ES2020의 dynamic import 문법을 지원한다. dynamic import를 사용하면 모듈을 빌드 타임이 아닌 런타임에 불러오도록 한다. 이를 통해 번들 파일을 분리하고 퍼포먼스 향상을 기대할 수 있다. 앱에는 초기 로딩부터 사용하지 않는 부분이 존재할 수 있으며, 또 그 부분의 사이즈가 생각보다 클 수 있기 때문이다. 그리고 사용자 언어 등 런타임에서만 알 수 있는 정보에 기반해서 모듈을 선택해야 하는 케이스도 생길 수 있다.

dynamic import의 공식 문법에서는 import 호출이 promise를 리턴하는 것처럼 코드를 작성한다.

// this code resides in add.js file
const add = (a, b) => a + b;
export default add

// in index.js file
import('./add.js')
  .then(module => module.default(7, 4)) // returns 11
  .catch(error => // log error);

하지만 next.js에서는 dynamic이라는 모듈을 제공해서 promise resolve 과정 없이도 변수에 할당할 수 있도록 해준다.

import dynamic from 'next/dynamic'

const DynamicComponent = dynamic(() => import('../components/hello'))

next.js 프로젝트에 적용하기

작업 중인 프로젝트에서는 각각의 라우트에 매칭되는 루트 컴포넌트를 하나씩 만들었다. 라우트의 컨텐츠는 루트 컴포넌트 안에 들어간다. 따라서 특정 라우트에만 사용되는 컴포넌트가 여럿 존재하게 된다. 그리고 next.js로 작성된 앱은 서버 렌더링을 하기 때문에 라우트에 매칭되는 컴포넌트가 아닌 다른 루트 컴포넌트들을 모두 불러올 필요가 없다. 그래서 next/dynamic 모듈을 사용해서 그 루트 컴포넌트들을 불러오도록 했다.

// index.js
import React from 'react'
import dynamic from 'next/dynamic'

// index 라우트에서 사용할 루트 컴포넌트(HomePage)를 dynamic import로 불러온다.
const Home = dynamic(() => import('components/pages/HomePage')) 

class index extends React.Component {
  render() {
    return <Home></Home>
  }
}

export default index

dynamic import 적용 전의 빌드 결과

dynamic import 적용 후의 빌드 결과

모든 라우트에 dynamic import를 적용하고 빌드를 해 보니 first load 사이즈가 크게 줄었다. 페이지별 번들 파일의 사이즈가 300kb대에서 100kb 단위로 줄어든 것을 확인할 수 있다. 하지만 share by all 항목에 있는 파일의 수가 더 증가했다.

dynamic import 전후의 로딩 시간 비교

다이나믹 임포트 전의 로딩 워터폴 그래프

자바스크립트 파일의 로딩은 200ms 전후로 모두 끝이 난다.

다이나믹 임포트 후의 로딩 워터폴 그래프

번들 사이즈가 줄어들어서 200ms 훨씬 전에 로딩이 끝난다

정리

테스트에 사용한 엡은 라우트가 6개밖에 되지 않으므로 사이즈가 작은 앱이라고 할 수 있다. 만약 앱의 규모가 이보다 크다면 dynamic import로 얻을 수 있는 효과도 더 커질 것으로 보인다.

프론트엔드 면접 핸드북 - 자바스크립트(3)

rhostem — Tue, 14 Apr 2020 00:00:00 GMT

이 인터뷰 핸드북은 front-end-interview-handbook/javascript-questions을 기반으로 정리한 것입니다.

41. ES6의 클래스와 ES5의 생성자 함수의 차이점

한줄 답변: 둘 다 생성자 역할을 하지만 상속을 구현하는 방법에서 큰 차이가 있다.

간단한 생성자 함수와 클래스

// ES5 Function Constructor
function Person(name) {
  this.name = name;
}

// ES6 Class
class Person {
  constructor(name) {
    this.name = name;
  }
}

아래는 상속을 구현한 코드. ES5 문법이 훨씬 더 길고 복잡하며 클래스 문법을 사용하면 간단하다.

ES5에서는 생성자 함수를 상속받기 위해서 prototype에 새 객체를 복사하는 등 여러가지 작업이 필요하지만 클래스는 그런 과정이 필요없다. extends 키워드로 상속받을 함수를 명시하고, constructor 메소드에서 super(this) 만 추가하면 된다.

// ES5 Function Constructor
function Student(name, studentId) {
  // Call constructor of superclass to initialize superclass-derived members.
  Person.call(this, name);

  // Initialize subclass's own members.
  this.studentId = studentId;
}

Student.prototype = Object.create(Person.prototype);
Student.prototype.constructor = Student;

// ES6 Class
class Student extends Person {
  constructor(name, studentId) {
    super(name);
    this.studentId = studentId;
  }
}

42. 화살표 함수를 어떻게 사용하면 좋은지, 기존 함수와의 차이점은 무엇인지

한줄 답변: 간단한 문법, 함수 안의 this가 선언된 scope의 this를 가리키는 lexical scoping

우선 function 키워드가 필요없어서 함수 선언 문법이 훨씬 단순하다는 명백한 장점이 있다. 그리고 화살표 함수 안에서 this 는 화살표 함수를 포함한 스쿠프의 this를 가리킨다. function 으로 선언된 함수 안에서 this는 그 함수를 호출한 객체에 의해 결정된다.

이러한 lexical-scope(문법적인 스쿠프)는 더 직관적이며 React 컴포넌트에서 콜백을 호출할 때 특히 유용하다. (컴포넌트 메소드 안에서 this가 메소드가 선언된 컴포넌트 인스턴스가 아니라 다른 객체 인스턴스를 가리킬 수 있기 때문이다. 컴포넌트 메소드를 화살표 함수로 선언하면 저런 문제가 사라진다.)

43. 생성자 함수에서 메소드 선언에 화살표 함수를 선언하는 것의 장점은?

한줄 답변: this가 바뀌지 않는다. 항상 같은 객체를 가리킨다.

생성자 안에서 메소드를 화살표 함수로 선언하는 것의 가장 큰 장점은 this가 가리키는 값이 함수 생성 시점에 결정된 후에 바뀌지 않는다는 것이다. 그러므로 생성자 함수가 새 객체를 만들면 this 는 언제나 그 객체를 가리킨다.

아래의 예제에서 첫번째 메소드는 function 키워드를 사용해서, 두번째 메소드는 화살표 함수로 선언되어 있고, 둘 다 함 수 안에서 this 키워드를 참조한다.

const Person = function (firstName) {
  this.firstName = firstName;

  // 일반 함수
  this.sayName1 = function () {
    console.log(this.firstName);
  };

  // 화살표 함수
  this.sayName2 = () => {
    console.log(this.firstName);
  };
};

const john = new Person("John");
const dave = new Person("Dave");

john.sayName1(); // John

// 일반 함수의 this는 바뀔 수 있다. 하지만 화살표 함수에서는 바뀌지 않는다.
john.sayName1.call(dave); // Dave (call로 인해 this는 이제 dave 객체다)
john.sayName2.call(dave); // John (call을 사용했지만 this는 여전히 john 객체다)

// apply도 call을 사용한 예제와 마찬가지로 바뀌지 않는다
john.sayName1.apply(dave); // Dave
john.sayName2.apply(dave); // John

// bind를 사용해도 마찬가지로 바뀌지 않는다
john.sayName1.bind(dave)(); // Dave
john.sayName2.bind(dave)(); // John

var sayNameFromWindow1 = john.sayName1;
sayNameFromWindow1(); // undefined
// sayNameFromWindow1 변수는 전역 스쿠프에 속하며, 전역 스쿠프에서 this는 window 객체다.

var sayNameFromWindow2 = john.sayName2;
sayNameFromWindow2(); // John. this는 변하지 않는다.

이처럼 화살표 함수 안에서 this는 바뀌지 않는다. 그러므로 화살표 함수를 어플리케이션의 어디에 가져다 둬도 함수 안에서 컨텍스트가 바뀔 걱정을 하지 않아도 된다.

이는 React 클래스 컴포넌트에서 특히 유용하다. 만약 클릭 이벤트 핸들러로 사용할 컴포넌트 메소드를 일반 함수로 선언하고, 그 메소드를 자식 컴포넌트의 props로 전달해서 사용한다고 가정하자. 자식 컴포넌트에서 그 메소드가 실행될 때 this는 자식 컴포넌트 인스턴스 객체를 가리키게 된다. 만약 메소드 안에서 this를 사용하려 한다면 의도한 것과는 다른 결과가 발생할 것이다(Uncaught TypeError: undefined is not a function 같은 오류가 흔히 발생한다.)

이를 방지하기 위해서는 상위 컴포넌트에서 메소드에 this를 bind해줘야 한다.

render() {
   return(
     <ChildComponent onChange={ this.handleChange.bind(this) } />
   )
}

하지만 화살표 함수를 사용하면 저럴 필요가 없다. 메소드 안에서 this는 항상 그 메소드가 선언되어 있는 컴포넌트 객체를 가리킬 것이기 때문이다.

44. 고차 함수(higher-order function)란?

한줄 답변: 파라미터로 함수를 받거나, 함수를 리턴하는 함수

고차 함수는 함수를 파라미터로 받거나 함수를 리턴하는 함수를 말한다. 반복적으로 실행되는 어떤 작업을 추상화시키는 수단으로 사용한다.

고차 함수의 고전적인 예제는 Array.prototype.map 함수다. 배열을 기반으로 새로운 배열을 만들 때 사용하는데, 이런저런 과정을 생략하고 맵핑 로직만 전달하면 되기 때문에 코드가 무척 간결해진다.

배열에 문자열로 구성되어 있고, 모든 요소에 toUpperCase를 적용해서 새 배열을 만들어야 한다고 하자. map 없이 구현하려면 아래와 같지만

const names = ["irish", "daisy", "anna"];

const transformNamesToUppercase = function (names) {
  const results = [];
  for (let i = 0; i < names.length; i++) {
    results.push(names[i].toUpperCase());
  }
  return results;
};
transformNamesToUppercase(names); // ['IRISH', 'DAISY', 'ANNA']

.map(transformerFn) 함수를 사용한다면 무척 간단해진다.

const transformNamesToUppercase = function (names) {
  return names.map((name) => name.toUpperCase());
};
transformNamesToUppercase(names); // ['IRISH', 'DAISY', 'ANNA']

Array의 forEach, filter, reduce 등도 모두 고차 함수다.

45. 구조 분해 할당(destructuring) 예제를 보여줄 수 있는가?

한줄 답변: ES6에서 도입된 객체, 배열의 멤버를 간단하게 추출할 수 있는 문법

구조 분해 할당은 ES6에 도입된 문법으로 객체와 배열의 값을 추출해서 변수에 바로 할당할 수 있는 간결하고 편리한 방법이다.

배열 destructuring

// 예제 배열 선언
const foo = ["one", "two", "three"];

const [one, two, three] = foo; // 배열 내부 순서대로 변수에 할당된다.
console.log(one); // "one"
console.log(two); // "two"
console.log(three); // "three"

// 변수 교환
let a = 1;
let b = 3;

[a, b] = [b, a];
console.log(a); // 3
console.log(b); // 1

객체 destructuring

// 예제 변수 선언
const o = { p: 42, q: true };
const { p, q } = o; // 객체의 필드 이름을 그대로 사용해야 한다

console.log(p); // 42
console.log(q); // true

const { p: pValue, q: qValue } = o; // 새로운 변수명을 제공할 수도 있다.
console.log(pValue); // 42
console.log(qValue); // true

46. 문자열 생성에 있어 큰 유연성을 제공하는 템플릿 리터럴의 예제를 보여달라

한줄 답변: result is ${data}

템플릿 리터럴은 문자열 삽입, 문자열 안에 변수 넣기 등을 간단하게 할 수 있도록 한다. ES6 이전에는 아래와 같이 해야 했다.

var person = { name: "Tyler", age: 28 };
console.log(
  "Hi, my name is " + person.name + " and I am " + person.age + " years old!"
);
// 'Hi, my name is Tyler and I am 28 years old!'

하지만 템플릿 리터럴이 있으면 훨씬 간단해진다.

const person = { name: "Tyler", age: 28 };
console.log(`Hi, my name is ${person.name} and I am ${person.age} years old!`);
// 'Hi, my name is Tyler and I am 28 years old!'

템플릿 리터럴임을 명시하고 ${} 같은 표현식을 사용하기 위해서는 홑따옴표(quote)가 아니라 backtick을 사용해야 한다.

두번째로 유용한 점은 여러 줄로 구성된 문자열을 표현하기 더 쉽다는 것이다. ES6 전에는 개행 문자를 사용해서 표현해야 했다.

console.log("This is line one.\nThis is line two.");
// This is line one.
// This is line two.

그리고 화면을 넘어가는 긴 문자열을 에디터에서 보기 좋게 작성하려면 아래와 같이 문자열을 분리할 필요도 있었다.

console.log("This is line one.\n" + "This is line two.");
// This is line one.
// This is line two.

하지만 템플릿 리터럴을 사용하면 개행 문자를 사용하지 않더라도 여러 줄로 문자열을 표현할 수 있다.

console.log(`This is line one.
    This is line two.`);
// This is line one.
// This is line two.

그리고 다른 사용 방법은 문자열에 간단한 변수를 삽입해서 템플릿 라이브러리(ex. React)를 대체하는 것이다.

const person = { name: "Tyler", age: 28 };
document.body.innerHTML = `
      <div>
        <p>Name: ${person.name}</p>
        <p>Name: ${person.age}</p>
      </div>
    `;

innerHTML을 사용할 때 주의할 점은 XSS(cross site scripting 을 사용한 해킹)에 노출될 수 있다는 사실이다. 사용자로부터 제공된 데이터(ex. 자기소개, 제품 후기 등)라면 사용하기 전에 항상 문자열을 sanitize해야 한다.

47. curry 함수의 예제, 그리고 curry 함수가 제공하는 장점은?

한줄 답변: 함수 파라미터가 n개라면, 총 n번 호출해야 실제로 실행되는 함수를 만든다. 함수형 프로그래밍에 유용하다

커링(curryin)은 파라미터가 1개 이상은 함수를 여러개로 분리하고, 연속으로 호출하면서 파라미터를 누적시킨 후 필요한 파라미터가 모두 제공되면 실제 함수를 호출하는 패턴이다.

이 방법은 함수형으로 작성된 코드를 더 읽기 쉽고 조합하기 쉽도록 하는데 유용하다. 함수를 커링할 때 처음에 1개의 함수를 제공해야 하고, 파라미터를 1개씩 제공받는 함수로 쪼개진다. 예를 들어 어떤 함수의 파라미터가 3개라면, 커링된 함수는 총 3번 호출해야 처음에 제공된 함수가 호출된다.

function curry(fn) {
  // 커링에는 재귀 패턴을 사용한다.
  if (fn.length === 0) {
    // Function.prototype.length는 파라미터의 수
    return fn;
  }

  // 커링 로직 재귀 함수
  // depth = 분리할 갯수(최대 재귀 호출 횟수), args = 현재까지 누적된 파라미터 배열
  function _curried(depth, args) {
    return function (newArgument) {
      if (depth - 1 === 0) {
        // 필요한 파라미터가 모두 쌓였다면 처음 제공된 함수 호출
        return fn(...args, newArgument);
      }

      // 파라미터가 전부 쌓이지 않았다면, 커링 로직을 다시 호출한다.
      return _curried(depth - 1, [...args, newArgument]);
    };
  }

  return _curried(fn.length, []); //
}

function add(a, b) {
  // add는 2개의 파라미터가 필요하다.
  return a + b;
}

var curriedAdd = curry(add); // add 함수를 커링시킨다.
var addFive = curriedAdd(5); // 첫번째 파라미터에 5가 들어간 새로운 함수를 만든다.

var result = [0, 1, 2, 3, 4, 5].map(addFive); // [5, 6, 7, 8, 9, 10]

48. spread 문법과 장점과 rest 문법과의 차이점은?

한줄 답변: spread ⇒ 데이터를 풀어놓는다, rest ⇒ 전달받은 데이터를 배열, 객체 안에 채워넣는다

ES6의 전개(spread) 문법은 함수형 패러다임으로 코드를 작성할 때 매우 유용하다. 배열이나 객체의 복제본을 Object.create 나 Array.prototype.slice , 또는 라이브러리 함수를 사용하지 않고도 간단하게 만들 수 있기 때문이다. 이 문법은 Redux나 RxJS 를 사용하는 프로젝트에서 자주 사용된다.

function putDookieInAnyArray(arr) {
  return [...arr, "dookie"];
}

const result = putDookieInAnyArray(["I", "really", "don't", "like"]); // ["I", "really", "don't", "like", "dookie"]

const person = {
  name: "Todd",
  age: 29,
};

const copyOfTodd = { ...person };

ES6의 rest 문법은 함수에 전달된 파라미터를 배열로 만들 수 있는 간단한 문법이다. 이것은 마치 spread 문법을 반대로 해놓은 것 같다. spread가 배열 안에 있는 데이터를 펼쳐놓는다면, rest 문법은 데이터를 받아서 배열에 채워넣기 때문이다.

이 문법은 함수 파라미터, 배열와 객체 destructuring에도 사용할 수 있다. destructuring에서 배열 데이터는 새로운 배열로, 객체 데이터는 새로운 객체로 만들어진다.

function addFiveToABunchOfNumbers(...numbers) {
  return numbers.map((x) => x + 5);
}

const result = addFiveToABunchOfNumbers(4, 5, 6, 7, 8, 9, 10); // [9, 10, 11, 12, 13, 14, 15]

const [a, b, ...rest] = [1, 2, 3, 4]; // a: 1, b: 2, rest: [3, 4]

const { e, f, ...others } = {
  e: 1,
  f: 2,
  g: 3,
  h: 4,
}; // e: 1, f: 2, others: { g: 3, h: 4 }

49. 파일 사이에서 코드를 어떻게 공유하는가?

한줄 답변: CommonJS, AMD, ES modules 를 사용한다

자바스크립트 환경에 따라 다르다

클라이언트(브라우저 환경)에서는 변수, 함수가 global 스쿠프에 선언되기 때문에 모든 스크립트에서 서로 참조할 수 있다. 또는 RequireJS로 AMD(Asynchronous Module Definition)를 사용해서 모듈화시킬 수도 있다.

서버(node.js)에서는 CommonJS를 사용한다. 각각의 파일은 모듈로 취급되며 module.exports 문법을 사용해서 변수, 함수를 내보낼 수 있다.

ES2015는 AMD와 CommonJS를 대체할 수 있는 모듈 문법을 정의했다. 이것은 브라우저와 Node 환경에서 모두 사용할 수 있다. (import, export)

50. static 클래스 멤버를 사용하는 이유는?

한줄 답변: 객체 인스턴스의 영향 없음. 설정 값, 유틸리티 함수로 활용

static 클래스 멤버(속성, 메소드)는 특정한 클래스 인스턴스에 구속되지 않으며 어떤 인스턴스에서 참조하더라도 같은 값을 가진다. static 속성은 주로 설정값으로 사용하며, 메소드는 인스턴스의 상태값에 영향을 받지 않는 순수한 유틸리티 함수로 사용한다.

51. `let`, `var`, `const` 를 사용해 선언된 변수의 차이점

한줄 답변: var는 함수 레벨 스쿠프. let, const는 블럭 레벨 스쿠프.

var 키워드로 선언한 변수는 그 변수를 포함한 함수 스쿠프에 속한다. 만약 변수를 선언한 곳이 어떤 함수 안도 아니라면 전역 스쿠프에 속한다.

let, const 는 함수 스쿠프가 아닌 블럭 스쿠프(함수, if~else, for 루프 등)에 속한다. 이는 가장 가까운 중괄호({} )로 둘러싸인 영역 안에서만 접근 가능하다는 의미다.

function foo() {
  // 모든 변수는 이 함수 안에서만 접근 가능하다.
  var bar = "bar";
  let baz = "baz";
  const qux = "qux";

  console.log(bar); // bar
  console.log(baz); // baz
  console.log(qux); // qux
}

console.log(bar); // ReferenceError: bar is not defined
console.log(baz); // ReferenceError: baz is not defined
console.log(qux); // ReferenceError: qux is not defined

if (true) {
  var bar = "bar";
  let baz = "baz";
  const qux = "qux";
}

// var 키워드로 선언된 변수는 함수 스쿠프 어디에서든 접근 가능하다.
console.log(bar); // bar

// let, const 키워드로 선언된 변수를 중괄호 바깥에서는 접근 불가능하다.
console.log(baz); // ReferenceError: baz is not defined
console.log(qux); // ReferenceError: qux is not defined

호이스팅

var는 호이스팅(hoisting)되지만 let, const는 그렇지 않다. let, const로 선언된 변수를 선언되기 전에 참조하려 한다면 오류를 발생시킬 것이다. 대신 호이스팅된 변수는 undefined로 나온다.

console.log(foo); // undefined
var foo = "foo";

console.log(baz); // ReferenceError: can't access lexical declaration 'baz' before initialization
let baz = "baz";

console.log(bar); // ReferenceError: can't access lexical declaration 'bar' before initialization
const bar = "bar";

재선언

var 키워드로 같은 이름의 변수를 다시 선언하는 것은 가능하지만, let, const는 에러를 발생시킨다.

var foo = "foo";
var foo = "bar";
console.log(foo); // "bar"

let baz = "baz";
let baz = "qux"; // Uncaught SyntaxError: Identifier 'baz' has already been declared

재할당

let은 변수에 값을 재할당하는 것이 가능하지만, const는 불가능하다.

let foo = "foo";
foo = "bar";

// 아래 코드는 오류를 발생시킨다.
const baz = "baz";
baz = "qux";

프론트엔드 면접 핸드북 - 자바스크립트(2)

rhostem — Mon, 13 Apr 2020 00:00:00 GMT

이 인터뷰 핸드북은 front-end-interview-handbook/javascript-questions을 기반으로 정리한 것입니다.

21. 이벤트 버블링에 대해서 설명하라

한줄 답변: DOM 이벤트가 상위 요소(element)로 전파되는 현상

DOM 요소에서 이벤트가 발생했을 때, 거기에 등록된 이벤트 리스너 함수가 있으면 실행을 시도한다. 그리고 이벤트는 부모 요소를 통해 DOM 트리 위쪽으로 전파(bubbled up)되며 거쳐가는 DOM 요소마다 같은 일(이벤트 리스너 확인 및 실행)이 반복된다. 이 버블링은 최상위 요소인 document까지 진행된다. 이벤트 버블링은 이벤트 위임(delegation) 메카니즘 안에 있다.

22. attribute와 property의 차이점이 무엇인가?

한줄 답변: attribute도 DOM property 중 하나다

attribute는 HTML 마크업에 정의되어 있지만 property는 DOM 객체에 정의되어 있다. 차이점을 설명하기 위해, HTML 안에 다음의 텍스트 필드가 있다고 가정해보자

<input type="text" value="Hello" />

DOM 트리에 HTMLInputElement 객체가 생성된다. 이 객체는 수많은 property를 가지고 있다. (accept, accessKey, align, alt, attributes, autofocus, baseURI, checked, childElementCount, childNodes, children, classList, className, clientHeight, etc.) attribute는 DOM 객체의 attributes property가 가진 요소들이다.

DOM node가 생성되면 많은 수의 property가 attributes에 있는 요소와 같거나, 비슷한 이름을 가지고 있다. 하지만 모두 1대1 대응을 하지는 않는다.

<input id="the-input" type="text" value="Name:" />

id property는 id attribute 값을 반영한다. id property를 바꾸면 id attribute도 변경을 반영한다.

하지만, value property는 그렇지 않다. value는 input 엘레멘트의 현재 입력값을 반영한다. 사용자가 입력하면 value property는 바뀌지만, value attribute는 초기값을 그대로 유지한다. 만약 사용자가 input 필드가 John을 입력했다면 아래와 같은 결과를 얻을 수 있다.

var theInput = document.getElementById("the-input");
theInput.value; // returns "John"
theInput.getAttribute("value"); // returns "Name:"

value property는 바뀌었지만 value attribute는 초기값인 Name: 그대로다. attribute와 property의 관계는 몇 가지로 나뉠 수 있다.

attribute를 바로 반영하고 이름까지 같은
- rel,id 등
attribute 변경 반영하지만 이름이 조금 다른
- htmlFor(property) - for(attribute) , className - class 등
attribute 값을 반영하지만 수정에는 영향이 없는
- src, href, disabled, multiple 등

관련 상세 스펙은 아래 링크에서 확인할 수 있다.

https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflect

23. Javascript 내장 객체를 확장하는 것이 왜 좋은 방법이 아닌가?

한줄 답변: 나만 확장한 것이 아니라 다른 사람도 확장했다면? 충돌은?

내장(built-in) 객체를 확장하는 것은 property/function을 prototype에 추가한다는 말이다. 처음에는 좋은 아이디어처럼 보일 지 몰라도, 실제로는 위험한 방법이다. 당신이 코드에서 2개의 라이브러리를 사용하는데, 둘 다 Array.prototype을 확장해 contain이라는 메소드를 추가해서 구현한 것이라고 가정해 보자. 두 라이브러리를 모두 불러오면, 마지막에 불러온 코드가 다른 라이브러리의 contain 메소드를 덮어쓰게 된다. 두 라이브러리가 contain을 같은 결과를 만들도록 구현했다면 문제가 없겠지만, 아니라면 어느 한 라이브러리는 문제를 일으킬 것이다.

기본 객체를 확장해야 하는 경우는 대체 코드(polyfill)을 만들어야 할 때 뿐이다. 예를 들어 IE 브라우저가 지원하지 않는 Array.prototype.includes를 사용하려 할때, Array.prototype에 includes 메소드를 추가해야 할 필요가 생긴다.

24. document의 load 이벤트와 DOMContentLoaded의 차이점은?

한줄 답변: 실행 시점이 페이지에 포함된 리소스가 모두 로딩된 후인지 아닌지의 차이

DOMContentLoaded 이벤트는 HTML 도큐멘트가 최초로 로딩되고 파싱되었을 때 발생한다. 스타일시트, 이미지, 서브프레임의 완전한 로딩은 기다리지 않는다. 그에 비해 window의 load 이벤트는 DOM과 페이지가 포함한 모든 리소스가 로딩되었을 때 발생한다.

25. === 과 == 연산자의 차이는?

한줄 답변: loose, strict equality

== 추상적인 등가 연산자, ===는 엄격한(strict) 등가 연산자다.

==는 필요하다면 타입 변환을 하면서 비교를 하고, ===는 있는 그대로 비교한다. 그래서 몇몇 케이스에서 두 연산자가 리턴하는 값이 다를 수 있다. ==는 loose equality 연산자라고도 한다.

1 == "1"; // true
1 == [1]; // true
1 == true; // true
0 == ""; // true
0 == "0"; // true
0 == false; // true

==는 사용하지 말아야 한다. 예외가 있다면 null과 undefined를 비교할 때는 편리한 측면도 있다. 물론 두 값이 가진 의미는 다르다. null은 명시적으로 이 값이 없음을, undefined는 변수에 아직 값이 할당되지 않았음을 의미한다.

26. 자바스크립트와 관련한 same-origin 정책에 대해 설명

한줄 답변: 다른 도메인의 스크립트를 사용한 해킹 방지

동일 출처 원칙(same-origin policy)는 자바스크립트가 서로 다른 도메인 사이에 리퀘스트를 날리는 것을 방지한다. origin은 URI 스키마, 호스트네임, 그리고 포트 번호로 정의된다. 이 정책은 다른 도메인의 악의적인 스크립트가 타겟 웹페이지에서 DOM을 통해 민감한 정보를 가져가는 것을 방지한다.

27. 다음의 함수를 구현하기

한줄 답변: Array.prototype.concat VS spread oprator

duplicate([1, 2, 3, 4, 5]); // [1,2,3,4,5,1,2,3,4,5]

// concat 사용
function duplicate(arr) {
  return arr.concat(arr);
}

// ES6 문법 활용:
const duplicate = (arr) => [...arr, ...arr];

28. 왜 Ternary 표현식이라 불리며 “Ternary”이라는 단어가 가리키는 것은?

한줄 답변: 삼항 연산자 표현식. condition ? then : else

“Ternary”라는 단어는 “셋”을 의미한다. 그리고 Ternary 표현식은 3개의 연산자를 가진다.

첫째로 조건문, 두번째로 then 표현식, 세번째로 else 표현식을 가진다. 삼항 표현식은 자바스크립트에서만 사용되는 것은 아니며 다른 언어에도 존재한다.

condition ? exprIfTrue : exprIfFalse;

29. “use strict”가 무엇인가? 이것을 사용하는것의 장점과 단점은?

한줄 답변: 일부 기능을 제한한다는 의미. 오류 방지 목적을 가지며 단점보다는 장점이 많음

전체 코드나 함수에 strict mode를 적용하기 위해 사용한다. strict 모드의 선언은 자바스크립트 변형의 제한에 동의한다는 것이다.

장점

의도하지 않은 전역 변수가 선언되지 못하도록 한다
삭제할 수 없는 속성(property)를 삭제하려고 시도하면 오류를 발생시킨다
함수의 파라미터 이름은 서로 달라야 한다
this 는 전역 컨텍스트에서 undefined다
몇몇 일반적인 코딩 실수를 잡아서 예외 처리(throw exception)시킨다 (예를 들어 전역 객체에 접근하려고 하는 것)
자바스크립트에서 개발자에게 혼란을 주거나, 잘못 만든 것으로 보이는 여러 기능의 사용을 금지한다

단점

못쓰게 되는 많은 기능들이 어떤 개발자에게는 필요한 기능일 수 있다
function.caller 그리고 function.arguments 에 접근할 수 없다
서로 다른 strict mode로 작성된 코드를 연결했을 때 오류가 발생할 수 있다.

전체적으로, 단점보다는 장점이 더 많은 것으로 보인다. 그리고 나는 strict 모드에서 사용하지 못하게 하는 기능이 그렇게 필요했던 적이 없다. 나는 strict 모드를 사용할 것을 추천한다.

30. 웹사이트의 전역 scope를 건드리지 않고 그대로 두는 것이 좋은 이유는?

한줄 답변: 변수와 함수 이름의 충돌을 방지하기 위해

모든 스크립트는 전역 스쿠프에 접근할 수 있다. 만약 모든 사람이 변수 선언에 전역 네임스페이스를 사용한다면 충돌이 매우 많이 발생할 것이다.

모듈 패턴(IIFE 등)으로 직접 선언한 변수는 로컬 네임스페이스에 포함되도록 해야 한다.

31. SPA 앱이 무엇인지, 그리고 SEO는 어떻게 해야 하는지

한줄 답변: 클라이언트 사이드 렌더링 웹사이트

최근 웹 개발자들은 그들의 제품을 웹 사이트보다는 “웹 앱”으로 부른다. 저 두 용어에 엄격한 차이는 없지만, 웹 앱은 더 상호작용성이 뛰어나고 동적이다. 유저들은 동작을 입력하는 즉시 반응을 얻을 수 있다. 전통적으로 웹사이트는 브라우저를 통해 서버에서 HTML을 받아서 렌더링하는 방식이었다. 사용자가 다른 URL로 이동하면 페이지 전체가 새로고침되고 서버가 이동할 URL에 맞는 새 HTML을 전달해준다. 이것을 서버 사이드 렌더링이라고 부른다.

하지만 최신의 SPA에서는 클라이언트 사이드 렌더링을 사용한다. 브라우저는 서버에서 초기 페이지와 함께 앱에 필요한 스크립트(프레임워크, 라이브러리, 앱 코드 등을 포함), 스타일시트를 내려받는다. 사용자가 다른 페이지로 이동하면 페이지 새로고침은 발생하지 않는다. 페이지의 URL은 HTML5 History API를 통해 기록된다. 새 페이지에 필요한 새 데이터는 브라우저에서 AJAX 리퀘스트를 통해 서버에서 보통 JSON 포맷으로 가져온다. SPA는초기 로딩때 가져온 자바스크립트를 사용해 데이터와 페이지를 동적으로 업데이트한다. 이 모델은 모바일 네이티브 앱이 동작하는 방식과 유사하다.

장점

사용자에게 앱이 보다 반응성있게 느껴지고 페이지 전환 사이에 화면 깜빡임과 새로고침 딜레이를 보지 않아도 된다.
서버에 더 적은 수의 HTTP 리퀘스트가 간다. 이미지같은 요소가 페이지마다 로딩될 필요가 없기 때문
서버와 클라이언트 사이의 확실한 역할 구분이 이뤄진다. 그렇기에 서버 코드의 수정 없이 다른 플랫폼(모바일, 챗봇, 스마트 시계 등)의 새로운 클라이언트를 쉽게 만들 수 있다. 또 API 스펙을 변경하지 않으면서 클라이언트와 서버의 기술 스택을 서로 독립적으로 변경할 수 있다.

단점

스크립트, 스타일시트 등 필요한 리소스가 많아서 초기 로딩이 더 무거워진다.
서버에서 모든 라우트로의 요청을 1개의 시작 라우트로 리다이렉트 되도록 설정해야 하고, 클라이언트 사이드에서도 라우팅을 직접 처리해야 한다.
SPA는 컨텐츠의 렌더링을 자바스크립트에 의존한다. 하지만 모든 검색 엔진이 크롤링 중에 자바스크립트를 실행하지는 않는다. 이것은 검색 엔진 최적화(SEO)에 장애물이 된다. 하지만 대부분의 경우 앱을 만들 때 SEO는 가장 중요한 요소가 아니다. 그리고 모든 컨텐츠가 검색 엔진에 의해 인덱싱될 필요도 없다. SEO가 필요하다면 서버사이드 렌더링을 사용하거나 Prerender같은 서비스를 사용해 “자바스크립트로 브라우저에서 렌더링하고, HTML을 저장하고, 크롤러에게 제공”하도록 할 수도 있다.

32. Promise와 그것의 polyfill에 대해서는 얼만큼의 경험을 가지고 있는가?

한줄 답변: Promise는 비동기적으로 값을 리턴하는 객체다

Promise(프로미스)는 지금이 아닌 나중에, 비동기적으로 값을 리턴할 수 있는 객체다. resolve된 값이나, 또는 reject된 이유(예를 들어 네트워크 오류가 발생했다던가)를 받을 수 있다.

프로미스는 fulfilled, rejected, pending 3가지의 중 하나의 상태를 가진다. 프로미스를 사용할 때 fulfilled, reject 상태로 변경될 때 콜백을 전달 할 수 있다.

잘 알려진 polyfill로는 jquery $.deferred , Q, Bluebird가 있지만 전부 표준 스펙을 만족시키진 못한다. ES2015는 프로미스를 지원하며 이제 polyfill은 필요하지 않다.

33. 콜백대신 프로미스를 사용하는 것의 장점과 단점은?

한줄 답변: 비동기 작업을 더 쉽게 구현할 수 있다는 장점. 단점은 딱히..?

장점

가독성 떨어지는 콜백 지옥에서의 탈출
.then()을 사용해서 순차적인 비동기 작업을 가독성 있게 작성할 수 있다
Promise.all()을 사용해서 병렬로 실행되는 비동기 작업을 쉽게 작성할 수 있다
프로미스가 있으면 콜백만 사용하는 코딩에서 발생하는 아래와 같은 일들이 발생하지 않는다
- 콜백을 너무 빨리 실행
- 콜백을 너무 늦게 실행(또는 실행하지 않음)
- 콜백을 너무 적게, 또는 너무 많이 실행
- 필요한 환경변수/파라미터의 전달 실패
- 확인해야 하는 에러, 예외가 숨어버린다

단점

조금 더 복잡한 코드
ES2015를 지원하지 않는 구형 브라우저에서는 사용할 수 없으며 폴리필이나 Babel을 통한 컴파일이 필요하다.

34. 자바스크립트로 컴파일되는 언어를 사용하는 것의 장/단점

한줄 답변: 정적 타입 지원 등 자바스크립트의 한계를 보완해준다. 하지만 자바스크립트도 ES2015 이후 무척 좋아짐

CoffeeScript, Elm, ClojureScript, PureScript, and TypeScript 등의 언어를 사용하는 것을 말한다.

장점

자바스크립트가 가지고 있는 오랜 문제점의 해결, 자바스크립트가 가진 안티 패턴(anti-patterns, 객체 확장, 전역 스쿠프 사용, 적절하지 않은 방법의 truthy, falsey 값 확인 등)을 사용하지 않도록 만드는 것.
더 짧은 코드의 사용, 자바스크립트에 기반한 편리한 문법(syntactic sugar) 제공. (ES2015에서 많이 개선됨)
(typescript를 사용하면) 오랜 기간 유지될 프로젝트에 정적 타입을 사용할 수 있어서 무척 좋다.

단점

브라우저만 자바스크립트만 지원하기 때문에 작성한 코드가 자바스크립트로 컴파일하는 과정이 추가로 필요하다
소스 맵이 pre-compile된 소스에 제대로 매핑되지 않아서 디버깅이 무척 힘들 수 있다
대부분의 개발자가 저들 언어에 익숙하지 않으며 학습이 필요하다. 결과적으로 당신의 프로젝트 관리를 위한 비용이 증가할 수 있다.
관련 커뮤니티가 작은 언어는 그만큼 관련 리소스, 튜토리얼, 라이브러리, 툴이 부족한다.
IDE/editor 지원이 빈약할 수 있다(TypeScript 는 VSCode가 제대로 지원함. Flow 페이스북의 Nuclide 프로젝트가 있었지만 현재 retire함)
이들 언어는 항상 최신 자바스크립트 표준보다 뒤쳐져 있다.
개발자들은 자기가 작성한 코드가 무엇으로 컴파일되는지 알아야 한다 - 왜냐면 실제로 동작하는 것은 그 컴파일 코드고, 결국에는 그것이 중요한 것이다.

ES2015는 대단한 개선이 이뤄져서 코드를 작성하기에 무척 좋다. 요즘에는 CoffeeScript에 대한 수요를 거의 보지 못했다.

35. 자바스크립트 개발에 어떤 디버깅 툴을 사용하는지?

한줄 답변: Chrome devtools, debugger, console.log, React, Redux Devtools

36. 객체 속성, 배열 항목 반복(iterate)에 어떤 방법을 사용하는가?

한줄 답변: 객체 - for-in + hasOwnProperty, Object.keys, 베열 - for-of

1. 객체

for-in 루프
- for (var property in obj) { console.log(property); }
- 하지만 상속받은 속성도 포함한다. 그래서 obj.hasOwnproperty(property) 를 사용해서 검사해야 한다.
Object.keys(obj).forEach(property ⇒ { ... })
- Object.keys 는 static 메서드이며 객체가 가진 열거 가능한(enumerable) 모든 속성을 배열로 만들어서 리턴한다.
Object.getOwnPropertyNames()
- Object.getOwnPropertyNames(obj).forEach(property => { ... })
- getOwnPropertyNames는 객체가 가진 모든 열거 가능한, 열거 불가능한(non-enumerable) 값을 배열에 담아 리턴한다.

참조) enumarable, non-enumerable의 차이

enumerable 속성이란 내부적으로 enumerable 플래그가 true 값으로 지정되어 있는 속성이다. 그 값은 Object.getOwnPropertyDescriptor 메소드로 확인할 수 있다.

> var v = { a: 1 }
> Object.getOwnPropertyDescriptor(v, 'a')
{ value: 1, writable: true, enumerable: true, configurable: true }

enumerable 속성은 for ... in 루프를 실행했을 때 나타난다.

2. 배열

for 루프
- for (var i = 0; i < arr.length; i++)
- ES2015에서는 변수명 충돌을 방지하기 위해 var 대신 블럭 스쿠프 변수 키워드 let 을 사용하는 것을 추천한다.
forEach
- arr.forEach(function (el, index) { ... })
- 이 방법은 index 변수가 필요없다면 굳이 선언하지 않아도, 코드에서 생략해도 되기 때문에 더 편리하다.
for - of 루프
- for (let elem of arr) { ... }
- ES6는 새로운 반복문을 제공한다. for - of 문법은 Iteration protocols을 따르는 객체 (String, Array, Map, Set 등)로 반복문을 만들 수 있다. for 루프와 forEach 메소드의 장점을 조합한 것이라 할 수 있다. for 루프는 반복문을 중간에 멈추게 할 수 있고, forEach는 index 값이 필요없기 때문에 for 루프보다 더 간결한 문법을 가진다. for - of 문법은 둘의 장점을모두 가지고 있다.

for 루프보다는 forEach 메소드를 더 많이 사용한다. 하지만 이제 ES6를 사용할 수 있으므로, for - of 문법을 더 많이 활용한다.

만약 for - of 루프를 사용하면서 배열의 값과 인덱스가 모두 필요하다면, Array.prototype.entries 메소드와 구조분해할당(destructuring)을 사용하면 된다.

const arr = ["a", "b", "c"];

for (let [index, elem] of arr.entries()) {
  console.log(index, ": ", elem);
}

37. mutable, immutable 객체의 차이점

한줄 답변: 이미 선언된 값의 수정 가능, 불가능 여부

mutability = 가변성, immutability = 불변성
mutable = 가변의, immutable = 불변의

불변성은 함수형 프로그래밍에서 핵심 개념이다. 그리고 객체 지향 프로그래밍에도 많은 것을 제공한다. 가변(mutable) 객체는 만들어진 후에 그 값이 변경될 수 있는 객체다. 불변(immutable) 객체는 만들어진 후 변경될 수 없다.

자바스크립트에서 불변 객체의 예제

자바스크립트에서 몇몇 내장 타입(숫자, 문자열)은 불변이다. 하지만 커스텀 객체는 일반적으로 가변적이다. 불변 객체로는 Math, Date 가 있다.

객체 상수 속성

writable: false 와 configurable: false를 조합해서 객체 속성을 상수(변경, 삭제, 재할당이 불가능함)로 만들 수 있다.

let myObject = {};
Object.defineProperty(myObject, "number", {
  value: 42,
  writable: false,
  configurable: false,
});
console.log(myObject.number); // 42
myObject.number = 43;
console.log(myObject.number); // 42

객체 확장 방지

객체에 새로운 속성이 추가되는 것을 방지하려면, Object.preventExtensions 메소드를 사용하면 된다.

var myObject = {
  a: 2,
};

Object.preventExtensions(myObject);

myObject.b = 3;
myObject.b; // undefined

strict 모드에서는 속성 b를 할당하는 과정에서 TypeError 오류가 발생한다.

Seal

Object.seal 메소드는 봉인된(sealed) 객체를 만든다. 새로운 속성을 추가할 수 없고, 속성을 제거하지도 새로운 값을 할당하지도 못한다. Object.preventExtension 메소드에 모든 속성의 configurable 값을 false로 만드는 기능을 더한 것이다.

configurable 이 속성의 값을 변경할 수 있고, 대상 객체에서 삭제할 수도 있다면 true. 기본값은 false.

Freeze

Object.freeze 메소드는 동결된(freezed) 객체를 만든다. 동결된 객체는 속성의 추가, 제거, 값 변경이 불가능하다. 그리고 동결된 객체는 프로토타입이 변경되는 것도 방지한다. 이 메소드는 자바스크립트 객체에 불병성을 부여할 수 있는 방법 중 가장 강력한 것이다.

var immutable = Object.freeze({});

Object.freeze는 동결된 버전의 새 객체를 만드는 것이 아니라, 파라미터에 전달된 객체를 동결된 상태로 만들어서 그대로 반환한다.

장점

변경 탐지를 더 쉽게 할 수 있다. 객체 등가 비교가 레퍼런스 비교를 통해서 쉽고 빠르게 가능하다. 이는 React와 Redux에서 객체 변경을 확인하는 데 유용하다.
불변 객체를 사용한 프로그램은 파악하는데 덜 복잡하다. 왜냐하면 객체가 시간이 지나면서 바뀌는 상황을 고려할 필요가 없기 때문이다.
함수에 불변 객체를 파라미터로 전달하거나, 리턴값으로 받는다면 객체의 방어적 복사본(defensive copy)은 더 이상 필요하지 않다. 왜냐하면 전달한 객체가 함수 안에서 변경될 걱정이 없기 때문이다.

defensive copy. 원본과 동일한 복사본을 만드는 것. 함수에 원본의 레퍼런스를 전달하는 대신, 복사본의 레퍼런스를 전달한다. 함수를 실행 후에도 원본 값에는 영향을 주지 않기 위한 목적으로 만든다.

객체를 캐싱해서 여러 번 재사용할 수 있다.
스레드에서의 안전성 - 여러 스레드가 동시에 실행되는 환경에서도 값이 변경될 위험이 없으므로 안전하다.
ImmutableJS 같은 라이브러리를 사용하면 여러 객체가 비슷한 구조를 공유하기 때문에 메모리를 더 적게 사용한다.

단점

매번 새로운 객체를 만드는 식으로 불변 데이터 구조를 가볍게 구현하면 퍼포먼스가 무척 나빠진다. 효율적인 불변 데이터 활용을 위해서는 라이브러리를 사용하는 것이 추천된다.
이미 있는 객체의 일부를 수정하지 않고 많은 작은 객체를 할당(allocation), 그리고 할당 해제(deallocation)한다면 성능에 문제를 야기할 수 있다. 할당자(allocator)와 가비지 컬렉터(garbage collector)의 복잡성은 보통 heap 메모리 영역에 있는 객체의 수에 따라 다르다.
그래프 같은 순환 데이터 구조는 만들기 어렵다. 만약 수정, 초기화도 될 수 없는 두 객체가 있다고 한다면 두 객체가 어떻게 서로를 참조하도록 할 것인가?

38. 코드를 작성할 때 불변성을 어떻게 구현하는지

한줄 답변: const, spread opeartor, Object.assign, Array.prototype.concat

우선 immutable.js, mori, immer같은 라이브러리를 사용하는 방법이 있다.

대안으로는 const 를 사용한 변수의 선언과 객체 생성에 앞서 언급한 방법들을 조합하는 방법이 있다. 객체를 수정(mutation)을 위해서는 전개 연산자(spread operator), Object.assign, Array.prototype.concat 등의 메소드를 사용해서 원본 객체를 수정하는 대신 새 객체를 만든다.

// Array Example
const arr = [1, 2, 3];
const newArr = [...arr, 4]; // [1, 2, 3, 4]

// Object Example
const human = Object.freeze({ race: "human" });
const john = { ...human, name: "John" }; // {race: "human", name: "John"}
const alienJohn = { ...john, race: "alien" }; // {race: "alien", name: "John"}

39. 동기, 비동기 함수의 차이점

한줄 답변: 코드의 순차적인 실행 vs 콜백에 전달된 코드를 나중에 실행

동기 함수는 블로킹(blocking)이 발생하지만, 비동기 함수는 그렇지 않다.

동기 함수는 앞에 있는 코드의 실행이 완료되어야 다음으로 넘어간다. 실행 순서가 보장되지만, 어떤 코드의 실행 시간이 길어진다면 프로그램이 멈춘 것처럼 보이게 될 것이다.

비동기 함수는 보통 콜백 함수를 파라미터로 받고 실행 즉시 다음 라인에 있는 코드로 넘어간다. 콜백은 비동기 작업이 완료되고 콜 스택이 비었을 때 실행된다. 웹 서버로부터 데이터를 불러오거나 데이터베이스 쿼리를 실행하는 것 같은 무거운 작업은 비동기적으로 실행되어야 한다. 그래야 메인 스레드가 그 긴 작업 시간동안 멈추지 않고 진행될 수 있다. 브라우저에서 저런 작업을 비동기로 하지 않는다면 UI가 사용자의 입력에 반응하지 않고 멈춰버릴 것이다.

40. 이벤트 루프란 무엇인가? 콜 스택과 태스크 큐의 차이점은?

한줄 답변: 동기 함수는 스택에 즉시 추가, 비동기 콜백은 태스크 큐에 대기하고 있다가 이벤트 루프가 스택에 추가

이벤트 루프는 싱글 스레드 루프(loop)로 콜 스택을 모니터링하면서 태스크 큐에 실행해야 할 작업이 있는지 확인한다. 만약 콜 스택이 비어있고 태스크 큐에 콜백 함수가 있다면, 함수는 큐에서 제거되고 실행을 위해 콜 스택에 추가(push)된다.

이벤트 루프에 대해서 더 자세한 내용은 유튜브에서 많은 조회수를 기록한 What the heck is the event loop anyway? 동영상을 보길 권한다.

동영상 스크린샷

console.log 같은 동기 함수는 스택에 바로 들어가고 실행된다. 하지만 비동기 web api인 setTimeout은 스택에 들어간 후 바로 지워지고, 대신 웹브라우저에서 타이머를 실행시킨다. 타이머가 끝나면, 콜백(cb)을 태스크 큐에 추가하고, 모니터링하고 있던 이벤트 루프가 콜백을 스택에 추가해서 실행한다. 콜백 안에 비동기 함수가 있다면 비슷한 과정이 반복될 것이다.

프론트엔드 면접 핸드북 - 자바스크립트(1)

rhostem — Sun, 12 Apr 2020 00:00:00 GMT

이 인터뷰 핸드북은 front-end-interview-handbook/javascript-questions을 기반으로 정리한 것입니다.

1. 이벤트 위임(event delegation)에 대해서 설명하라

한줄 답변: 부모 요소에 이벤트 리스너를 붙이는 것

이벤트 위임이란 이벤트 리스너를 부모 요소(element)에 붙이는 것을 말한다. 하위 요소에 이벤트가 발생하면 이벤트 버블링 때문에 부모 요소에 연결된 리스너가 실행된다. 이 테크닉의 장점은

사용하는 메모리의 양(memory footprint)이 감소한다. 이벤트가 발생하는 모든 요소마다 리스너를 추가할 필요가 없고 부모에 하나만 추가하면 되기 때문이다.
이벤트 발생하는 요소가 추가되고 제거될때마다 리스너를 추가하고 제거할 필요가 없다.

2. this 키워드는 어떻게 동작하는지 설명하라

한줄 답변: this가 가리키는 것은 코드의 실행 위치, 실행 방법에 따라 달라진다

this에 대한 간단한 설명은 없다. 자바스크립트에서 가장 헷갈리는 개념 중 하나라고 할 수 있다. 그래도 설명하자면 this의 값은 함수가 어떻게 실행되느냐에 따라 달라진다. 그리고 가장 깔끔하다고 생각하는 Arnav Aggrawal의 글에 의하면 다음의 규칙들로 정리할 수 있다.

함수 실행에 new 키워드를 사용하면, 그 함수 안에서 this 키워드는 새로운 객체를 가리킨다.
apply, call, bind를 사용해 함수를 호출/생성 했다면, 함수 안에서 this 키워드는 apply, call, bind 호출시 전달된 객체를 가리킨다.
함수가 객체의 메소드로서 호출되었다면, this는 그 함수를 속성(property)으로 추가한 객체를 가리킨다.
함수가 단순히 실행되었다면, 다시말해 위의 3가지 사례를 제외한 방식으로 호출되었다면, this는 전역 객체를 가리킨다. 브라우저에서는 window, node에서는 global이 된다. 만약 strict 모드(‘use strict’)에서는 this는 전역 객체 대신 undefined가 된다.
만약 위의 4가지 조건이 중첩된다면, 먼저 제시한 규칙이 적용된다. (1번 규칙부터 우선함)
함수가 ES2015의 화살표 함수라면, 위의 규칙을 모두 무시하고, 함수가 만들어진 시점에서 그 함수를 둘러싼 scope의 this를 가리킨다.

3. 프로토타입 상속이 어떻게 동작하는지 설명하라

한줄 답변: 어떤 속성이 내 객체에 있으면 사용하고, 없으면 프로토타입 객체에 있는 것을 사용한다

자바스크립트 인터뷰에서 무척 자주 나오는 질문이다. 모든 자바스크립트 객체는 __proto__라는 속성을 가지고 있다. 그것은 다른 객체를 가리키는 레퍼런스며, 객체의 “prototype”이라고 불린다. 객체에서 어떤 속성(property)을 사용하려 하는데 그 객체에 없다면 자바스크립트 엔진은 __proto__ 객체에 그 속성이 있는지 확인한다. 만약 거기에도 없다면 다시 __proto__ 의 __proto__ 객체에 있는지 확인하는 식으로 반복 확인하면서 프로토타입 체인의 끝까지 탐색한다. 이 동작은 전통적인 상속(inheritance)처럼 보이지만 상속 보다는 위임에 더 가깝다.

예제

Object.create(지정된 프로토타입 객체 및 속성을 갖는 새 객체를 생성)의 polyfill 코드.

if (typeof Object.create !== "function") {
  Object.create = function (parent) {
    function Tmp() {}
    Tmp.prototype = parent;
    return new Tmp();
  };
}

const Parent = function () {
  this.name = "Parent";
};

Parent.prototype.greet = function () {
  console.log("hello from Parent");
};

const child = Object.create(Parent.prototype);

child.cry = function () {
  console.log("waaaaaahhhh!");
};

child.cry();
// Outputs: waaaaaahhhh!

child.greet();
// Outputs: hello from Parent

4. AMD vs CommonJS에 대해 어떻게 생각하는가?

한줄 답변: 비동기 vs 동기 모듈. 이제는 Javascript module에 의해 대통합.

둘다 모듈 시스템을 구현하는 방식이다. ES2015 전까지 자바스크립트는 모듈 시스템을 직접 지원하지 않았다. CommonJS는 동기적인데 비해 AMD는 이름 그대로(Asynchronous Module Definition) 비동기적이다. CommonJS는 서버사이드 개발에 맞춰 디자인되었지만 AMD는 비동기적인 모듈 로딩을 지원하므로 보다 브라우저를 위한 시스템이라고 할 수 있다.

나는 AMD의 문법이 다소 장황하며 CommonJS의 문법이 다른 언어에서 사용하는 import 문법과 비슷하다고 본다. 현재 사용하고 있는 개발 시스템에서 나는 AMD가 필요없어 보인다. 왜냐면 모든 소스가 babel로 컴파일되고 하나의 파일로 번들링된 후 앱이 시작하기 때문이다. 여기서는 비동기 로딩이라는 AMD의 장점을 취할 수 없다. 그리고 CommonJS는 Node의 모듈 작성 방식과 비슷하기 때문에 클라이언트 사이드와 서버 사이드 개발 사이에 모듈 작성 방식의 차이에서 발생하는 비용이 크지 않다.

나는 ES2015의 모듈이 만족스럽다. 동기적, 비동기적 모듈 로딩을 모두 지원한다. 물론 ES2015가 브라우저와 노드에 완전히 탑재되지는 않았다. 하지만 Babel이라는 트랜스파일러가 있으므로 우리는 드디어 하나의 방법만 사용할 수 있게 되었다.

5. 다음의 코드 `function foo(){ }();`는 왜 IIFE처럼 실행되지 않는가? IIFE가 되게 하려면 어떤 부분을 수정해야 하나?

한줄 답변: 함수 선언부를 소괄호로 둘러싸야 즉시 호출이 가능하다

IIFE 는 Immediately Invoked Function Expressions 의 약자다.

자바스트립트 엔진은 function foo(){ }(); 을 function foo(){} 와 ();으로 읽는다. 첫번째는 함수 선언이고, 두번째는 함수 호출이다. 하지만 호출하려는 함수 이름이 없어서 Uncaught SyntaxError: Unexpected token ) 에러가 발생한다.

IIFE처럼 작동하게 하려면 아래처럼 작성해야 한다.

(function foo() {})();

function 키워드로 시작하면 함수 선언으로 인식하기 때문이다. 하지만 소괄호로 둘러싸면 함수 표현식으로 인식하고 뒤따르는 ()로 실행할 수 있다. 저렇게 실행한 함수는 전역 스쿠프에 노출되지 않으며 필요하지 않다면 함수 이름도 생략해서 작성할 수 있다.

> (function () {console.log(1)})();
1

소괄호로 둘러싸는 대신 void 키워드를 사용할 수도 있다. 하지만 리턴값을 받을 수는 없다. void 키워드는 항상 undefined를 리턴하기 때문이다.

> const foo = void function bar() { console.log(1); return 'foo'; }();
> console.log(foo)
undefined

6. `null`, `undefined`, 그리고 선언되지 않은 변수에는 어떤 차이가 있는가?

한줄 답변: null은 명시적인 값, undefined는 문자 그대로의 의미, 그리고 선언하지 않은 변수는 쓰지 말아야 한다.

선언되지 않은 변수(undeclared variable)

var, let, const를 붙여서 선언하지 않은 변수를 코드에서 사용하는 것을 말한다. strict 모드에서는 레퍼렌스 에러가 발생한다. strict 모드가 아니면 전역에 자동으로 추가된다. 사용하지 말아야 한다.

`undefined` 변수

선언은 되었지만 값이 할당되지 않은 상태. 함수가 값을 리턴하지 않는다면 undefined를 반환한다. falsy한 값이기 때문에 확실히 undefined인지 확인하기 위해서는 strict equality 연산자(===)를 사용해야 한다. loose equality(==)를 사용하면 undefined와 null 이 같다고 할 수 있으니 주의.

// 값 할당 안함
var foo;
console.log(foo); // undefined
console.log(foo === undefined); // true

// 리턴값 없음
function bar() {}
var baz = bar();
console.log(baz); // undefined

// strict equality
console.log(undefined == null); // true
console.log(undefined === null); // false

나는 변수를 undeclared 또는 unassigned 상태로 두지 않으려 한다. 당분간 사용하지 않을 변수라면 null 값을 명시적으로 할당해 둔다.

7. 클로져(closure)란 무엇이며 어떻게/왜 사용하는가?

한줄 답변: 접근 불가능한 영역에 통로를 만드는 것

클로져는 함수의 실행이 끝난 뒤에도 함수에 선언된 변수의 값을 접근할 수 있도록 만든 함수를 말한다.

함수는 블럭으로 둘러싸여 있고 하나의 스쿠프를 형성한다. 함수 안에 선언된 변수는 함수 바깥에서 참조할 수 없으며, 함수가 실행된 후에는 더 이상 사용할 수 없다.

하지만 자바스크립트에서는 함수 리턴값을 통해 함수 안에 선언된 변수를 노출시킴으로서 클로져를 형성할 수 있다.

자바스크립트에서 스쿠프(Scope)는 현재 코드 특정 변수에 대한 접근 가능 여부를 결정하는 환경(context)를 가리킨다.

스쿠프는 두가지 타입이 있다. 지역(local)과 전역(global)이다. 전역 변수는 어떤 블럭에도 속하지 않은 위치에서 선언된 것이며, 로컬 변수는 블럭 안에서 선언된 것이다.

사용하는 이유

데이터 프라이버시 / 모듈 패턴에서 private 메소드를 구현하기 위해 사용됨.
함수형 프로그래밍에서 partial application, currying 구현

예제

함수 안의 변수 업데이트

function counter() {
  let num = 0;
  function increase() {
    num += 1;
    return num;
  }
  return increase;
}

const c = counter();
console.log(c()); // 1
console.log(c()); // 2
console.log(c()); // 3

간단한 curry

function curry(fn, a) {
  return function (b) {
    return fn(a, b);
  };
}

var add3 = curry((num1, num2) => num1 + num2, 3);

add3(4); // 7

8. forEach와 map의 차이점이 무엇이며, 어떤 메소드를 사용해야 하는가?

한줄 답변: 콜백 리턴값으로 맵핑을 하느냐, 하지 않느냐

`Array.prototype.forEach`

배열의 요소을 순환한다
각각의 요소를 파라미터로 전달받는 콜백 함수가 실행된다.
값을 리턴하지 않는다.

`Array.prototype.map`

배열의 요소을 순환한다
새로운 배열을 리턴한다. 그리고 각각의 요소마다 콜백함수를 실행시키며, 콜백의 리턴값을 새로운 배열의 요소로 mapping(사상)한다.

차이점과 선택

두 메소드 모두 원본 배열의 값을 바꾸지 않는다. 차이점은 forEach는 값을 리턴하지 않고, map은 값을 리턴한다는 것이다. 결과가 필요하다면 map을, 아니라면 forEach를 사용하면 된다.

9. 익명 함수를 사용하는 사례에는 어떤 것들이 있나?

한줄 답변: IIFE, callback ⇒ 다른 곳에서 참조할 일이 없는 것들

IIFE

코드를 둘러싸서 실행 코드와 변수를 전역 스쿠프에 노출하지 않을 목적으로 사용한다. 다른 곳에서 사용하지 않을 것이므로 IIFE 패턴에 사용할 함수는 이름이 필요 없다.

(function () {
  // 실행할 코드 작성
})();

콜백 함수

콜백으로서의 함수는 재사용하지 않는 경우가 대부분이다. 콜백이 사용되는 위치에 직접 선언하는 편이 더 가독성이 높다.

setTimeout(function () {
  console.log(new Date().getSeconds());
}, 1000);

// vs

function onEveryTick() {
  console.log(new Date().getSeconds());
}

setTimeout(onEveryTick);

10. 호스트 객체와 네이티브 객체의 차이점

한줄 답변: 표준 객체와 런타임 환경 객체

네이티브 객체는 자바스크립트 언어의 일부로서 ECMAScript 표준에 정의된 것이다. 예를 들면 String, Math, RegExp, Object, Function 등이다.

호스트(Host) 객체는 런타임 환경(브라우저, Node)에서 제공하는 객체로서 window, XMLHTTPRequest 등이 있다.

11. `function Person(){}`이 있을 때, `var person = Person()`과 `var person = new Person()`의 차이점은?

한줄 답변: 함수를 생성자로 사용하느냐, 일반 호출로 사용하느냐의 차이.

이 질문은 다소 모호하다. 내 생각에 이 질문의 의도는 생성자(constructor)에 대해서 묻고 있는 것으로 보인다. 기술적으로 말해서 function Person(){}은 그냥 일반적인 함수 선언이다. 함수의 이름으로 파스칼 케이스(PascalCase)를 사용하는 것은 이 함수가 생성자 함수임을 나타내기 위한 규칙(convention)이다.

var person = Person()은 Person을 생성자가 아닌 함수로서 호출한다. 생성자 역할을 해야 하는 함수를 저렇게 호출하는 것은 흔히 볼 수 있는 실수 중 하나다. 일반적으로 생성자는 아무것도 리턴하지 않는다. 인스턴스를 리턴받으려는 의도였겠지만 실제로는 undefined 값이 할당될 뿐이다.

var person = new Person() 은 new 연산자를 사용해 Person 객체의 인스턴스를 만든다. 그 인스턴스는 Person.prototype을 상속한다. 프로토타입을 상속하는 다른 방법에는 Object.create가 있다.

var person = Object.create(Person.prototype);

정리하면 아래와 같다.

// 생성자 함수
function Person(name) {
  this.name = name;
}

var person = Person("John");
console.log(person); // undefined
console.log(person.name); // Uncaught TypeError: Cannot read property 'name' of undefined

var person = new Person("John");
console.log(person); // Person { name: "John" }
console.log(person.name); // "john"

12. `Function.prototype.call`과 `Function.prototype.apply` 의 차이점은?

한줄 답변: this 객체를 지정한다는 것은 같지만, 함수 파라미터 전달방식에 차이가 있다.

call, apply 모두 함수를 호출하는데 사용하며, 첫번째 파라미터는 함수 안에서 this 값으로 사용된다. 두 번째 파라미터부터는 함수의 파라미터로 전달된다.

call 은 콤마로 구분된 파라미터를 사용하지만, apply는 배열을 사용한다.

call의 c ⇒ comma separated arguments
apply의 a ⇒ array of arguments

function add(a, b) {
  return a + b;
}

console.log(add.call(null, 1, 2)); // 3
console.log(add.apply(null, [1, 2])); // 3

13. `Function.prototype.bind`에 대해 설명하라

한줄 답변: this 키워드가 지정된 새 함수를 만든다.

bind 메소드는 새로운 함수를 만든다. 새로 만들어진 함수 안에서 this 키워드의 값은 bind를 호출할 때 첫 번째로 전달된 값이 된다. Function.prototype.call처럼 두번째 파라미터부터 차례대로 원래 함수의 파라미터로 전달된다. (Taken word-for-word from MDN)

React에서 컴포넌트 클래스의 메소드에 this를 바인딩하는 것이 유용한 사용 방법 중 하나다.

클래스의 메소드가 비동기적으로 실행되거나, DOM의 이벤트 핸들러(ex. onClick)로 할당되면 this가 유지되지 않고 사라진다. bind를 사용해서 this를 명시적으로 바인딩하거나 화살표 함수를 사용해야 한다.

`bind`를 사용하는 예제

setTimeout 은 비동기적으로 실행되므로 함수가 호출될 때 this를 유지하지 않는다. 그래서 this를 바인딩하지 않으면 this가 클래스 인스턴스가 아닌 다른 값(전역 객체)을 가리키게 된다.

function debounce(fn, to) {
  setTimeout(fn);
}

class Foo {
  constructor() {
    this.fullName = "Bar";
  }

  speak() {
    console.log("My name is", this.fullName);
  }

  test() {
    debounce(this.speak, 1000);
    debounce(this.speak.bind(this), 2000);
  }
}

let foo = new Foo();

foo.test();
// My name is undefined
// My name is Bar

메소드를 선언할 때 화살표 함수를 사용하면 this를 바인딩하지 않아도 된다. 화살표 함수는 자신의 this를 바인딩하지 않으며, this를 lexical하게 바인딩하기 때문이다. 즉 다른 규칙 다 무시하고, 화살표 함수 코드가 작성된 곳의 this를 사용한다. 개인적으로는 이것이 화살표 함수의 탄생 목적 중 하나로 보이기도 한다.

class Foo {
  constructor() {
    this.fullName = "Bar";
  }

  speak = () => {
    console.log("My name is", this.fullName);
  };
}

14. `document.write`를 사용하겠는가?

한줄 답변: 아니오. 기존의 html, body 모두 날아감

document.write는 문자열을 document stream으로 작성한다. 웹페이지가 로딩된 후에 document.write가 호출되면 그것은 document.open을 호출하고, 로딩된 페이지가 모두 지워진다. (head, body 태그가 제거된다!) 그리고 컨텐츠를 전달된 파라미터로 교체한다.

<html>
  <head>
    <title>write example</title>
    <script>
      function newContent() {
        document.open();
        document.write("<h1>Out with the old - in with the new!</h1>");
        document.close();
      }
    </script>
  </head>

  <body onload="newContent();">
    <p>Some original document content.</p>
  </body>
</html>

위의 코드를 실행하면 html이 아래처럼 바뀐다.

document.write가 애널리틱스 코드에서 사용되거나, 자바스크립트가 허용된 환경에서만 스타일을 추가하고 싶을때 사용된다는 설명이 웹상에 존재한다. 심지어 HTML5 bolilerplate 코드에서 스크립트를 병렬적으로 로딩하고 실행 순서를 유지하는데 사용된다고 하기도 한다.

하지만, 나는 저런 테크닉들이 요즘에 와서는 다소 철이 지난 오래된 것들이라 생각한다. 그리고 document.write 를 사용하지 않아도 구현할 수 있다.

15. feature detection, feature inference, 그리고 UA 문자열에 대해서 설명하라

한줄 답변: 브라우저가 어떤 기능을 지원하는지 확인하기 위한 테크닉들이다.

Feature Detection

기능 탐지(feature detection)는 브라우저에서 어떤 기능을 포함한 코드 블럭을 사용할 수 있는지 확인하는 것, 그리고 지원 여부에 따라 다른 코드를 실행해서 오류를 발생하지 않게 하여 일관적인 사용자 경험을 제공하는 것을 포함한다.

if ("geolocation" in navigator) {
  // Can use navigator.geolocation
} else {
  // Handle lack of feature
}

Modernizr 는 feature detection을 처리하는데 사용할 수 있는 훌륭한 라이브러리다.

Feature inference

기능 추론(Feature inference)은 feature detection처럼 기능을 확인하지만, 그 기능은 사용하지 않고 다른 기능을 사용한다. 탐지한 기능이 있으면 관련된 다른 기능도 있을 것이라 추정하는 것이다.

if (document.getElementsByTagName) {
  element = document.getElementById(id);
}

하지만 이런 코드는 별로 권장하지 않는다. Feature detection이 더 확실한 방법이다.

UA 문자열

브라우저가 제공하는 문자열. UA를 통해 네트워크 프로토콜이 리퀘스트하는 대상의 어플리케이션 타입, 운영체제, 소프트웨어 벤더(vendor), 소프트웨어 버전을 확인할 수 있다. 브라우저에서 navigator.userAgent 로 가져올 수 있다. 하지만 이 문자열은 파싱하기가 까다롭고 잘못되었을 수도 있다. 예를 들어 macOS에서 실행한 Chrome 브라우저는 “Chrome”과 “Safari”라는 문자열을 모두 포함한다.

// chrome에서 확인한 userAgent.
// 뒤쪽에 보면 Safari도 포함하고 있다.
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36";

그래서 Safari임을 확인하려면 Safari 문자열이 있는지, 그리고 Chrome 문자열이 없는지도 확인해야 한다. 이 방법은 사용하지 말아야 한다.

16. Ajax에 대해 가능한 자세하게 설명하라

한줄 답변: 비동기 데이터 통신, 동적인 웹 컨텐츠 제공을 위한 기술

Ajax(asynchronous JavaScript and XML)는 비동기적인 웹 어플리케이션을 만들기 위해 클라이언트 사이드에서 사용하는 웹 개발 기술의 모음이다.

Ajax를 사용하면 웹 어플리케이션은 현재 표시중인 있는 화면에 영향을 주지 않고 서버에 비동기적으로(백그라운드에서) 데이터를 보내고 받을 수 있다. 데이터 교환 계층과 프레젠테이션 레이어를 분리함으로 Ajax는 웹 어플리케이션이 화면 새로고침 없이도 동적으로 컨텐츠를 변경하는 것이 가능하도록 만들었다.

실제로는 XML을 JSON으로 대체해서 구현하고 있다. 왜냐하면 자바스크립트 엔진에 JSON 처리 기능이 탑재되어 있어 데이터를 바로 사용할 수 있다는 이점이 때문이다.

XMLHttpRequest API는 비동기 통신에 많이 사용되는데, 최근에는 fetch API를 많이 사용한다.

17. Ajax의 장점과 단점은 무엇인가?

한줄 답변: SPA의 그것과 거의 같다. 동적인 웹 구현을 가능하게 하지만 그만큼 댓가도 따른다.

장점

개선된 상호작용. 서버에서 가져온 컨텐츠를 페이지 새로고침 없이 보여줄 수 있다.
어플리케이션 스크립트와 스타일시트를 한번만 가져와도 된다.
페이지에서 상태를 유지할 수 있다. 페이지 새로고침이 되지 않을 것이기 때문에 자바스크립트 변수와 DOM 상태가 초기화되지 않는다.
기본적으로 SPA(single page application)가 가지는 대부분의 장점과 일치한다.

단점

동적인 웹페이지는 북마크하기 더 어렵다.
자바스크립트가 허용되지 않은 페이지에서는 동작하지 않는다.
어떤 웹 크롤러는 자바스크립트를 실행하지 않기 때문에 동적으로 로딩되는 컨텐츠가 표시되지 않을 수 있다.
Ajax를 이용해 데이터 가져오는 웹페이지는 클라이언트 사이드에서 템플릿과 원격 데이터를 조합해 DOM을 업데이트해야 한다. 이를 위해선 자바스크립트가 클라이언트 사이드에서 파싱되고 실행되어야 한다. 느린 접속 속도와 낮은 스펙을 가진 모바일 기기에서는 페이지 표시에 어려움을 겪을 수 있다.
기본적으로 SPA가 가지는 대부분의 단점과 일치한다.

18. JSONP가 어떻게 동작하는지 설명

한줄 답변: 다른 도메인에 있는 서버에서 클라이언트의 전역 함수를 호출하는 테크닉이다.

JSONP(JSON with Padding)는 크로스 도메인 정책을 우회하기 위해서 주로 사용된다. 웹 브라우저는 Ajax 리퀘스트를 다른 도메인에 요청하는 것을 허용하지 않기 때문이다.

JSONP는 script 태그로 리퀘스트를 보내며 보통 쿼리 파라미터에 callback 을 붙인다.

https://example.com?callback=printData

서버에서는 데이터를 callback 파라미터로 전달된 printData 라는 함수에 담아서 실행한다.

<!-- https://mydomain.com -->
<script>
  function printData(data) {
    console.log(`My name is ${data.name}!`);
  }
</script>

<script src="https://example.com?callback=printData"></script>

// File loaded from https://example.com?callback=printData
printData({ name: "user name" });

클라이언트에는 printData라는 함수가 전역 scope에 선언되어 있어야 한다. 다른 도메인의 스크립트가 클라이언트에서 실행되면서 클라이언트의 함수를 실행하고, 파라미터까지 전달할 수 있다.

JSONP 구현을 위해서는 클라이언트와 서버가 printData 라는 이름을 가진 함수를 사용할 것이고 어떻게 데이터를 보낼지 사전에 조율되어야 한다.

JSONP는 안전하지 않으며 보안에 문제를 가져올 수 있다. JSONP는 자바스크립트이기에 자바스크립트로 할 수 있는 다른 모든 것들을 할 수 있다. 그렇기에 JSONP를 통해 데이터를 제공하는 상대를 신뢰해야만 사용할 수 있다.

이제 JSONP는 해킹으로 간주되며, CORS를 사용한 구현이 더 권장된다.

19. 자바스크립트 templating을 사용해 본 적이 있는가? 어떤 라이브러리로?

한줄 답변: Angular, React, template literal(XSS에 유의)

Angular, React를 사용한다. Lodash도 _.template 메소드로 템플릿 작업을 할 수 있지만 거의 사용하지 않았다.

React로 JSX를 가장 많이 사용했으며 좋아한다. 자바스크립트에 가깝고 JSX를 위해 별도로 공부할 것이 거의 없기 때문이다. 주의해야 할 점이라면 DOM attribute 키 값을 JSX에서는 모두 camel 케이스로 사용해야 한다는 것 정도가 있다.

최근에는 ES2015에서 표준이 된 template literal을 사용해 라이브러리 도움 없이도 템플릿을 만들 수 있다.

const template = `<div>My name is: ${name}</div>`;

하지만 템플릿 라이브러리의 도움 없이 template literal을 사용할 때는 XSS(cross site scripting) 공격을 염두에 두고 필요하면 문자열을 모두 이스케이프 처리해야 한다.

React에서는 동적으로 HTML을 추가하기 위한 attribute로 dangerouslySetInnerHTML 을 제공한다. 그 이름에서 HTML을 직접 추가할 때는 XSS에 주의해야 한다는 사실을 상기시키고 있다.

20. hoisting에 대해서 설명하라

한줄 답변: 같은 스쿠프라면 아래쪽 줄에 있는 변수를 윗줄에서 참조 가능하도록 하는 자바스크립트의 특징. 하지만 변수에 할당된 값은 알려주지 않는다.

Hoisting(이하 호이스팅)은 자바스크립트 변수 선언의 동작 방식을 설명하기 위한 용어다.

var 키워드로 선언되거나 초기화된 변수는 그 선언이 자바스크립트 엔진에 의해 모듈/함수 스쿠프의 최상단으로 옮겨진다. 이것을 호이스팅이라고 부른다. 하지만 선언(declaration)만 호이스팅될 뿐 값 할당(assignment)은 여전히 거기에 머무른다. 다시말해 값이 할당된 변수라도 호이스팅을 통 통해 접근하면 undefined 값을 얻게 된다.

console.log(foo); // undefined
var foo = 1;
console.log(foo); // 1

선언이 실제로 옮겨진것이 아니라는 것임을 주지해야 한다. 자바스크립트 엔진은 컴파일 과정에서 코드를 파싱해서 변수 선언을 인지하고 어느 스쿠프에 속하는지 알게 된다. 스쿠프 맨 위로 호이스팅되는 것은 시각화를 통해 더 쉽게 이해할 수 있다.

본체(body)가 있는 함수 선언은 호이스팅되지만 함수 표현식(변수에 할당하는 식으로 선언한 함수)은 호이스팅되지 않는다.

// 함수 선언
console.log(foo); // [Function: foo]
foo(); // 'FOOOOO'
function foo() {
  console.log("FOOOOO");
}
console.log(foo); // [Function: foo]

// 함수 표현식
console.log(bar); // undefined
bar(); // Uncaught TypeError: bar is not a function
var bar = function () {
  var a = 1;
  console.log("BARRRR");
};
console.log(bar); // [Function: bar]

let, const 로 선언된 변수도 호이스팅된다. 하지만 코드에서 선언한 부분 위에서 접근하면 var와는 다르게 값이 할당되어 있지 않으면 undefined가 출력되는 것이 아니라, ReferenceError exception 오류를 발생시킨다. 그런 변수는 코드 시작점부터 변수 선언부까지 ”temporal dead zone(TDZ)“을 가진다.

// -- 변수 y의 TDZ 시작
x; // undefined.
y; // Reference error: y is not defined

var x = "local";
let y = "local";
// -- 변수 y의 TDZ 종료

Redux Toolkit을 활용한 React 상태 관리

rhostem — Wed, 04 Mar 2020 00:00:00 GMT

Redux Toolkit의 특징

Redux Toolkit은 Redux의 공식 개발 도구다. Redux의 액션 생성자, 리듀서 자체는 단순한 함수인 데다 미들웨어를 추가할 수 있어서 관련 라이브러리와 도구가 매우 많고 그만큼 개발 방식이 다양하다. 처음 접하는 사람들은 어떤 방식을 실무 개발에 적용하면 좋을지 시간을 들여서 조사해 봐야 한다. 하지만 그만큼 시행착오가 많이 발생하며, 사용하다 보면 Redux가 좋긴 한데 액션 및 리듀서를 관리하기 위한 코드의 양이 너무 늘어난다는 불만도 자연스레 생긴다. 그러면서 자연스레 더 간단한 코드로 상태 관리를 할 수 있는 mobx같은 다른 라이브러리로 눈이 돌아가기도 한다.

그래서 Redux에서 직접 개발 도구를 만들어서 공개한 모양이다. 그들은 이 도구는 결코 표준이 아니며, 그들이 생각하기에 효율적인 개발 방법이라고 말하고 있다. 하지만 직접 API를 살펴보고 코드를 작성해 본 결과 나름 코드의 양을 줄일 수 있는 데다 생각의 전환까지 가져올 수 있었다. Redux를 사용하고 있고 뭔가 아쉬움을 느끼고 있는 사람이라면 한 번 살펴봐도 좋을 것 같다.

외부 라이브러리의 도입

먼저 알려 둘 사실은 Redux Toolkit에서는 이름있는 Redux 관련 라이브러리를 내부적으로 도입해서 사용하고 있다는 점이다. 리듀서 생성 API에는 immer를, 셀렉터 생성 API에는 reselect를 사용하고 있다. 저 라이브러리에 익숙한 사람이라면 Redux Toolkit에서 제안하는 상태 관리 방식을 더 자연스럽게 받아들일 수 있을 것이다.

action

createAction API를 사용해서 액션 생성자 함수를 만든다.

const increment = createAction("counter/increment");

let action = increment(); // returns { type: 'counter/increment' }

action = increment(3); // returns { type: 'counter/increment', payload: 3 }

위의 코드에서 볼 수 있듯이 createAction에는 기본적으로 타입 문자열만 제공하면 된다. 그리고 만들어진 액션 생성자의 파라미터는 그대로 payload 필드에 들어간다.

만약 리턴되는 액션 객체에 더 손을 보고 싶다면, 콜백 함수를 createAction의 두 번째 파라미터로 전달하면 된다.

const addTodo = createAction("todos/add", function prepare(text) {
  return {
    payload: {
      text,
      createdAt: new Date().toISOString()
    }
  };
});

addTodo("Write more docs"); // 아래의 객체를 리턴한다.
/**
 * {
 *   type: 'todos/add',
 *   payload: {
 *     text: 'Write more docs',
 *     createdAt: '2019-10-03T07:53:36.581Z'
 *   }
 * }
 **/

콜백 함수 안에서는 액션 생성자 함수의 파라미터로 전달받지 않은 데이터를 추가할 수 있다. 이때 리턴되는 객체는 반드시 FSA 형태를 따라야 한다.

Flux Standard Action

Redux Toolkit에서는 액션 객체의 형태로 FSA(Flux Standard Action)를 강제한다.

{
  type: 'number/increment',
  payload: {
    amount: 1
  }
}

객체는 액션을 구분할 고유한 문자열을 가진 type 필드가 반드시 있으며, payload 필드에 데이터를 담아 전달한다. 그 외에 meta, error 필드를 가질 수도 있다. (더 자세한 사항은 Flux 홈페이지 참조)

reducer

createAction만 보면 조금 심드렁할 수도 있다. 하지만 reducer부터 조금씩 차이가 드러나기 시작한다. Redux Toolkit에서 리듀서 작성은 createReducer API를 사용한다. 그리고 앞서 소개한 createAction으로 만든 액션 생성자도 함께 사용할 수 있다.

const increment = createAction("increment");
const decrement = createAction("decrement");

const counterReducer = createReducer(0, {
  [increment]: (state, action) => state + action.payload,
  [decrement.type]: (state, action) => state - action.payload
});

코드에서도 확인할 수 있겠지만, reducer 함수에서 흔히 보이던 switch 문이 사라졌다! 이제 더는 쓸데없는 default 케이스를 작성할 필요가 없다.

createReducer 함수는 첫 번째 파라미터로 초기 상태 값 객체(initialState)를, 두 번째 파라미터로 리듀서 맵 객체를 요구한다. switch 문의 case 문자열이 리듀서 맵의 필드 값이 된 형태다. 리듀서 함수를 구현할 때 사용하는 switch 문법에 대해서 논쟁이 있었는데, 이 라이브러리에서는 완전히 없애버렸다.

그리고 리듀서 맵의 필드에 액션 생성자에 전달한 문자열을 넣어도 되지만, 액션 생성자 함수를 직접 넣어도 된다. 이것이 가능한 이유는 createAction이 리턴하는 액션 생성자 함수의 toString(Object.prototype.toString) 메소드를 오버라이딩했기 때문이다.

`${increment}`; // 'increment'

이 방식 덕분에 액션의 타입 문자열을 할당한 변수를 별도로 관리할 필요가 없다. 타입 문자열을 전달할 필요 없이 액션 생성자를 직접 전달하면 되기 때문이다. createReducer 함수는 리듀서 맵으로 코드의 양을 줄였고, 타입 변수를 관리할 필요를 없애서 또 코드의 양을 줄인 셈이다.

immer를 도입한 Redux Toolkit

리듀서 함수는 내부적으로 immer의 produce를 사용한다. 그래서 리듀서 함수에서 새로운 상태(state) 객체를 리턴할 필요가 없다. 대신 상태 값을 직접 변경하는 방식으로 코드를 작성하면 된다.

const todoReducer = createReducer([], {
  ["addTodo"]: (state, action) => {
    state.push(action.payload);
  }
});

불변성을 유지하기 위해 Object.assign 으로 새 객체를 만들거나, Array.prototype.map 등으로 새 배열을 만들거나, 심지어 immutable.js 같은 라이브러리로 상태 객체를 래핑하는 등의 작업을 할 필요가 없다. 저 함수 안에서만 저런 문법이 가능하다는 사실을 항상 인지하고 있기만 하면 된다.

action + reducer → slice

Redux Toolkit은 액션이나 리듀서 외에도 다른 방식으로 상태를 관리할 수 있는 도구를 제공한다. 그것은 createSlice API로 액션, 리듀서를 한 번에 만드는 것이다.

let todoId = 0;

const todosSlice = createSlice({
  // 액션 타입 문자열의 prefix로 들어간다. ex) "todos/addTodo"
  name: "todos",

  // 초기값
  initialState: [],

  // 리듀서 맵
  reducers: {
    // 리듀서와 액션 생성자가 분리되어 있다.
    addTodo: {
      // 리듀서 함수
      reducer: (state, action) => {
        state.push(action.payload);
      },

      // createAction 함수의 두번째 파라미터인 콜백 함수에 해당한다.
      prepare: (text: string) => ({
        payload: {
          id: todoId++,
          text
        }
      })
    },

    // 리듀서와 액션 생성자 함수가 분리되어 있지 않다.
    // removeTodo 액션은 파라미터가 payload에 바로 할당된다.
    removeTodo: (state, action) => {
      state.splice(
        state.findIndex(item => item.id === action.payload.id),
        1
      );
    }
  }
});

createSlice는 초기값, 리듀서, 액션을 하나의 객체에 담아 전달받는다. 그렇게 만든 슬라이스 객체에서 액션과 리듀서는 아래와 같이 가져올 수 있다.

const { addTodo, removeTodo } = todosSlice.actions;
const { reducer } = todosSlice;

createSlice를 사용하면 액션을 생성하고, 그 액션을 리듀서 맵에 전달할 필요도 없이 한 번에 만들 수 있다. 별도로 작성하는 것보다 가독성은 조금 떨어지긴 하지만 코드의 양을 더 줄이면서 간단하게 리덕스 상태 관리를 구현할 수 있다.

create “slice”?

slice는 상태(state) 트리 구조에서 리듀서 함수 1개를 가리킨다고 한다. 그런데 왜 slice, ‘얇은 조각’이라는 이름을 붙였을까?

앱의 규모가 커지면 리듀서 액션의 덩치도 자연스럽게 커지고 리듀서 함수 1개의 길이가 수백 라인을 넘어가 버린다. 코드의 복잡도가 높아져 테스트 코드가 없으면 건드리기 불안할 정도가 되곤 한다. 소프트웨어 개발에 있어 사실 그런 일은 불가피하긴 하다. slice라는 단어를 사용한 이유는 그래도 앱의 로직을 최대한 분리하고 작은 덩치로 유지하자는 철학을 담으려는 목적이 아닌가 한다.

보통 아래에 있는 트리 구조와 같이 유형별로 소스를 구분하는 방법을 많이 사용할 것이다. 컴포넌트는 components 폴더 아래에, 리덕스 관련 코드는 모두 store 폴더에 아래에 두는 식이다.

.
├── api (API 모듈)
├── components (일반 켬포넌트)
├── constant (상수)
├── models (데이터 모델 변수, 타입)
├── pages (페이지 컴포넌트)
├── store  (Redux 관련 코드)
├── styles (스타일시트)
└── utils (유틸리티 모듈)

그런데 Redux Toolkit 개발팀에서 공개한 공식 템플릿(cra-template-redux)에서는 독특한 방식의 폴더 구조를 제안하고 있다. features 라는 폴더 안에 기능별로 폴더를 만든 후 그 안에 React 컴포넌트와 스타일시트, Redux 구현 등 관련 소스를 모두 같은 곳에 위치시키는 방법이다.

.
├── api
│   └── githubAPI.js
├── components
│   └── Heading.js
├── features
│   ├── counter
│   │   ├── Counter.css
│   │   ├── Counter.js
│   │   └── counterReducer.js
│   ├── github
│   │   ├── RepoDetail.js
│   │   └── repoDetailSlice.js
│   └── todos
│       ├── Todos.js
│       └── todosSlice.js
...

components, styles 폴더에는 공용 컴포넌트, 글로벌 스타일, 믹스인처럼 유틸리티 성격을 가진 모듈을 두고, 실제 기능과 관련된 소스는 모두 features 폴더 아래에 주제별로 모으는 식이다. 이를 보면 slice라는 단어는 리듀서 뿐만 아니라 기능 또한 작은 덩치로 가볍게 유지하자는 의미를 담고 있을 수 있겠다는 생각이 든다.

좋은 방식으로 보이지만, 앱의 규모가 커졌을 때 무엇이 더 좋은 방식일지는 역시 직접 경험해 봐야 알 것 같다. 리듀서의 수가 너무 많아져서 더 복잡하게 느껴질 것 같기도 하고, 관심사 분리 원칙을 더 확실하게 지켜서 사이드 이펙트가 덜 발생하고 레거시 코드 분석이 그나마 더 쉬워질 수도 있을 것 같기도 하다. 역시 코드 관리 방식은 팀과 개인의 선택 문제다.

selector

셀렉터는 리덕스에서 state를 기반으로 새로운 값을 리턴하는 함수를 말한다. 예를 들어 할 일 목록에서 현재 상태가 ‘완료’로 표시된 데이터만 필터링해서 리턴하는 것을 말한다.

Redux Toolkit의 createSelector API는 reselect 라이브러리의 그것과 같다. 이 API는 새로운 상태 추출에 사용하는 값이 변경되지 않으면 다시 실행되지 않는다. 즉 메모이제이션(memoization¹)을 지원한다.

아래의 코드는 현재 활성화된 탭에 맞는 데이터 배열을 리턴하는 셀렉터 코드다.

const activeListSelector = createSelector(
  state => state.events.live, // 상태 1 리턴 함수
  state => state.events.closed, // 상태 2 리턴 함수
  state => state.events.tab, // 상태 3 리턴 함수

  // 상태 1, 2, 3이 차례로 들어간다
  (liveEvents, closedEvents, tab) => {
    switch (tab) {
      case "LIVE":
        return liveEvents;

      case "CLOSED":
        return closedEvents;

      default:
        return [];
    }
  }
);

createSelector를 호출할 때 파라미터의 수에는 제한이 없지만, 마지막에는 상태 객체를 리턴할 콜백 함수가 있어야 한다. 마지막 콜백 함수의 파라미터에는 앞선 파라미터에서 리턴한 객체가 차례대로 위치한다. activeListSelector는 state.events.live, state.events.closed, state.events.tab 중 어느 하나의 값이 바뀌어야 다시 실행되어서 새로운 값이 적용되며, 그렇지 않으면 다시 실행되지 않는다. 이렇게 만든 셀렉터는 React 컴포넌트에서 아래와 같은 방식으로 사용한다.

import React from "react";
import { useSelector } from "react-redux";

export default function EventList() {
  const activeTabEvents = useSelector(activeTabEventsSelector);

  return activeTabEvents.map((eventData, i) => (
    <span key={i}>{eventData.title}</span>
  ));
}

store

액션, 리듀서를 만들었으니 이제 스토어 객체를 만들어서 React 컴포넌트 트리에 제공해야 한다. Redux Toolkit은 Redux의 createStore를 활용한 configureStore API를 제공한다.

import {
  configureStore,
  combineReducers, // redux의 그것과 같다.
  getDefaultMiddleware
} from "@reduxjs/toolkit";
import todosSlices from "src/features/todos/todosSlice";
import counter from "src/features/counter/counterReducer";

const rootReducer = combineReducers({
  counter, // createReducer로 만든 리듀서 객체
  todos: todosSlices.reducer // createSlice로 만든 slice 객체가 가진 reducer
});

const store = configureStore({
  reducer: rootReducer
});

combineReducers는 Redux에서 사용하고 있는 것과 같다. configureStore 함수에 필수적으로 필요한 값은 reducer필드다. middleware, preloadedState, enhancers 등의 사용 방법은 문서를 참조하면 될 것이다.

그리고 configureStore에 middleware 필드를 전달하지 않으면 기본적으로 제공되는 미들웨어가 있다. 그 미들웨어들을 가져오는 API가 getDefaultMiddleware다.

const middleware = getDefaultMiddleware();
expect(middleware).toEqual([
  thunk,
  immutableStateInvariant, // development 모드에서만 사용됨
  serializableStateInvariant // development 모드에서만 사용됨
]);

기본 미들웨어로는 redux-thunk를 사용하며 개발 모드에서만 redux-immutable-state-invariant, serializable-state-invariant-middleware 미들웨어가 추가된다. 만약 비동기 액션 처리에 redux-thunk를 사용하지 않거나 redux-saga 등의 다른 미들웨어가 필요하다면 아래와 같이 설정을 수정해야 한다.

import logger from "redux-logger";

const store = configureStore({
  reducer: rootReducer,
  middleware: [...getDefaultMiddleware(), logger]
});

TypeScript 설정

Redux Toolkit은 타입스크립트를 지원한다. 그리고 타입을 사용하면 액션을 호출하고 상태를 가져올 때 버그를 발생할 가능성을 줄여준다.

slice

initialState에 타이핑을 추가한다.

interface ITodo {
  id: number,
  text: string,
  isDone: boolean,
}

const initialState: ITodo[] = []

const todosSlice = createSlice({
  initialState: [],
	// ...
})

슬라이스에서는 리듀서의 리턴 타입으로 payload에 어떤 데이터를 넣어야 하는지 지정할 수 있다. redux-toolkit에서 제공하는 PayloadAction 타입을 사용하면 된다.

const todosSlice = createSlice({
	reducers: {
    removeTodo: (state, { payload }: PayloadAction<{ id: number }>) => {
      // ...
    },
	}
	// ... 
})

root reducer

선언한 슬라이스를 기반으로 전체 상태 트리 타입을 가져올 수 있다. 타입스트립트의 유틸리티 타입인 ReturnType을 사용한다.

import todosSlices from 'features/todo/todoSlice'

const rootReducer = combineReducers({
  todo: todosSlices.reducer,
})

declare global {
  type IRootState = ReturnType<typeof rootReducer>
}

export default rootReducer

더미 스토어 인스턴스로 스토어 관련 타입 선언

스토어 인스턴스, dispatch, getState 함수의 타입을 만들기 위해서 Provider 에 전달하는 인스턴스 대신 더미 인스턴스를 만들어서 타입을 선언했다. createStore 모듈이 별도로 있어서 사용한 트릭인데, 다른 방법을 사용해도 상관없다.

// 타이핑을 위한 더미 스토어 객체. 실제로 사용하지는 않는다.
const dummyStore = configureStore({
  reducer: rootReducer,
})

declare global {
  type IStore = typeof dummyStore
  type IAppDispatch = typeof dummyStore.dispatch
  type IGetState = typeof dummyStore.getState
}

export const sampleSelector = createSelector(
  (state: IRootState, getState: IGetState) => state.todo,
  (todo) => {
    // ...
  }
)

`useSelector` 훅을 대신할 `useTypedSelector`

함수형 컴포넌트 안에서 Redux state 객체를 가져오는 useSelector 훅의 파라미터는 root state다. 거기에 아래처럼 일일이 IRootState로 파라미터를 붙여도 되지만, 그렇게 하지 않아도 되도록 react-redux 에서 헬퍼 타입을 제공한다.

import { TypedUseSelectorHook, useSelector } from 'react-redux'

// useSelector hook 대신 사용. useSelector 함수의 파라미터에 타입을 지정하지 않아도 된다.
export const useTypedSelector: TypedUseSelectorHook<IRootState> = useSelector

예제 프로젝트

startkits/next-redux-ts-starter at master · rhostem/startkits

참고 자료

메모이제이션은 컴퓨터 프로그램이 같은 계산을 반복해야 할 때, 이전에 계산한 값을 메모리에 저장함으로써 같은 계산의 반복 수행을 제거하여 프로그램 실행 속도를 빠르게 하는 기술이다. 동적 계획법의 핵심이 되는 기술이다. 메모아이제이션이라고도 한다.(출처 - 위키백과)
↩

Git subtree를 활용한 코드 공유

rhostem — Fri, 03 Jan 2020 00:00:00 GMT

서비스를 개발하다 보면 코드를 공유해야 하는 일이 생긴다. 백엔드를 마이크로 서비스 구조로 개발하면 API 리스펀스, 각종 데이터 모델에 같은 타입을 사용해서 일관성을 유지해야 한다. 그리고 프론트엔드 웹을 데스크탑, 모바일로 분리해서 개발한다면 데이터 모델뿐만 아니라 컴포넌트 및 다양한 유틸리티 모듈을 함께 사용할 필요가 생긴다. 만약 백엔드가 node.js로 만들어져 프론트엔드 웹과 Javascript라는 같은 언어를 사용한다면 코드 공유의 필요성은 더욱 클 것이다.

코드 공유를 위한 방법은 여러 가지가 있다. NPM private 레지스트리, Bit, Git submodule, 그리고 전통적이고 간단한 “복붙”(copy and paste)같은 방법이 있다. 이 글에서는 Git subtree로 코드를 공유하는 방법을 소개한다.

Git Submodule의 단점

Git Submodule(이하 서브모듈)은 Git 저장소에 다른 Git 저장소를 추가하는 방법이다. 서브모듈로 추가된 저장소(repository)는 상위 저장소에서 1개의 폴더로 취급되며 일반적인 파일처럼 접근해서 사용할 수 있다.

그런데 문제가 있다. 상위 저장소는 서브모듈의 정보 중에서 체크아웃한 커밋의 SHA 값만 기록한다. 그런데 만약 서브모듈의 원격에 새로운 내용이 푸시되어서 서브모듈을 업데이트해야 하는 상황이 생긴다면 어떻게 될까? 아래와 같은 시나리오를 가정해보자.

서브모듈 B를 추가한 저장소 A에서 서브모듈을 직접 수정한 후 커밋을 했다.
서브모듈 B의 원격에 새로운 내용이 푸시되었다.
1. 저장소 A에 있는 서브모듈의 내용과 원격에 있는 서브모듈의 내용은 서로 다르다. 충돌이 발생할 수 있다.
서브모듈의 업데이트를 해야 한다. git submodule update 명령어로 사용한다.

위와 같은 시나리오에서 서브모듈의 병합의 제대로 이뤄질까? 대답은 “아니오”다. 왜냐면 상위 저장소에서 서브모듈을 SHA 값, 하나의 바이너리처럼 취급하기 때문이다. SHA 값이 다르므로 그냥 최신 커밋의 내용으로 교체해 버린다. 저장소 A에서 작업한 중요한 변경사항은 그냥 사라져 버릴 것이다. 만약 병합을 제대로 하고 싶다면 사용자가 직접 서브모듈에 새로운 브랜치를 만들어서 커밋하고. 서브모듈 업데이트를 한 후 직접 병합하고 충돌을 해결한 후 푸시해야 한다.

그러면 서브모듈로 추가한 소스는 건드리지 않는다는 원칙을 세우고 작업을 하면 되지 않나? 라고 생각할 수도 있다. 하지만 작업을 하다 보면 이것이 서브모듈인지 상위 저장소의 소스인지 헷갈릴 수 있어서 실수로 수정하고 커밋을 할 가능성은 얼마든지 있다.

Git Subtree

Git Subtree(이하 서브트리)는 SHA 값만 저장하는 서브모듈과 달리 상위 저장소에 파일을 직접 추가하고 트래킹한다. 자연히 서브트리의 파일 및 변경사항도 상위 저장소에 기록된다. 그리고 서브트리의 원격에 있는 소스와 서브트리를 추가한 저장소의 소스가 서로 달라도 “subtree merge” 기능을 사용해서 양쪽의 변경사항을 모두 반영할 수 있다.

이처럼 상위 저장소에서 서브트리를 직접 수정하고 원격에 푸시할 수 있다는 것이 서브모듈과 큰 차이점이다. 예를 들어 서브트리의 컴포넌트를 상위 저장소의 프로젝트에서 사용할 때 버그를 발견했다면, 즉시 수정해서 커밋한 후 버그를 해결한 상태로 서브트리의 원격에 반영할 수 있다는 편리함이 있다.

물론 단점도 있다. 서브트리를 추가한 모든 사용자가 서브트리의 내용을 자유롭게 변경해서 원격에 푸시할 수도 있다는 점이다. 프로젝트를 공동으로 진행할 때 어떤 사람이 작업한 feature A 브랜치에서 작동하는 서브트리의 소스를 푸시했는데, 그것을 내려받은 다른 사람의 feature B 브랜치에서는 오류가 발생할 수도 있다. 소규모 팀에서 작업할 때는 쉽게 대응이 가능하겠지만, 만약 수십 명이 프로젝트에 참여하는 상황이라면 위와 같은 문제가 발생할 가능성이 더 커지고 커뮤니케이션도 원활히 되지 않을 수 있다. 대규모 팀이라면 자유도가 높은 서브트리의 사용보다 프라이빗 NPM 레지스트리를 사용하면서 공용 소스 코드의 수정에 엄격한 기준을 세우는 등 다른 방법을 사용하는 편이 나을 수도 있다.

Git 서브트리 사용법

이번 글을 위해 예제를 위한 샘플 저장소를 생성한 후 진행했다.

서브트리를 사용할 상위 저장소: rhostem/gitsubtree-consumer
서브트리로 추가될 저장소: rhostem/gitsubtree-lib

1. 서브트리로 사용할 원격 저장소 추가

다른 저장소를 서브트리로 바로 추가할 수도 있다. 하지만 서브트리를 fetch, pull, push도 할 것이므로 서브트리로 사용할 Git 저장소를 상위 저장소의 새로운 원격 저장소로서 추가한다.

git remote add gitsubtree-lib git@github.com:rhostem/gitsubtree-lib.git
git remote add <원격 저장소의 이름> <원격 저장소의 주소>

원격 저장소의 이름으로 subtree를 사용했다. 기본 저장소 외에 하나가 더 추가되었음을 확인할 수 있다.

git remote ⮐
origin
gitsubtree-lib

2. 새로운 원격 저장소의 브랜치를 서브트리로 추가.

git subtree add --prefix lib gitsubtree-lib master
git subtree add --prefix <클론할 폴더> <원격 저장소의 이름> <브랜치 이름>

--prefix 옵션으로 서브트리를 클론할 폴더를 지정한다. 그리고 원격 저장소의 이름, 체크아웃할 브랜치 이름을 지정하면 서브트리로 gitsubtree-lib 저장소가 추가된다. 브랜치는 master 를 사용하도록 했다.

서브트리로 추가한 직후 폴더 구조는 아래와 같다.

.
├── README.md (gitsubtree-consumer의 파일)
└── lib
    └── README.md (gitsubtree-lib의 파일)

3. 서브트리를 원격에서 내려받기(pull)

서브트리의 원격에 올라온 커밋을 내려받는다. 서브트리를 추가하는 명령어와 큰 차이가 없으며, 자동으로 병합(merge)이 진행된다.

git subtree pull --prefix lib gitsubtree-lib master

커맨드라인에서 실행 후 병합이 완료되면 에디터가 열리면서 커밋 메시지의 저장을 요구할 수도 있다.

4. 서브트리를 원격에 올리기(push)

상위 저장소에서 서브트리의 소스를 직접 수정 후 변경사항을 커밋하고 원격에 푸시할 수 있다. 역시 명령어는 내려받기와 큰 차이가 없다.

git subtree push --prefix lib gitsubtree-lib master

명령어가 짧지 않으므로 쉘 스크립트나 NPM 스크립트로 작성해서 사용하는 편이 좋다. 그리고 서브트리 명령어는 항상 상위 저장소의 최상위 폴더에서 실행해야 한다. 서브트리의 소스가 있는 폴더에서 git subtree명령어를 사용하면 동작하지 않는다.

참고 자료

PM2로 Node.js 앱이 무중단 상태가 되도록 관리하기

rhostem — Wed, 23 Oct 2019 00:00:00 GMT

PM2의 클러스터 모드를 통한 로드 밸런싱

PM2를 클러스터 모드로 사용하면 Node.js 서버 앱을 동시에 여러 개 실행하면서 1개의 포트를 공유할 수 있다. 굳이 똑같은 앱을 많은 메모리를 사용해가며 실행해야 하는 이유는 Node.js가 싱글 스레드여서 1개의 CPU만 사용하기 때문이다. PM2는 Node.js의 클러스터 모듈을 사용해서 원하는 수 만큼 프로세스를 쉽게 늘리고 줄일 수 있도록 도와준다. 그리고 자연히 1개의 프로세스만 실행할 때보다 성능과 안정성을 높일 수 있다.

하지만 PM2는 무중단 재시작(graceful reload)를 무조건 보장하지 않는다. PM2로 관리 중이던 앱을 재시작하면 예전 프로세스를 새 프로세스로 교체하는 과정이 발생하는데, 거기서 이슈가 발생할 수 있다. 예를 들면

새 프로세스가 시작은 되었지만 앱이 완전히 준비되지 않은 상태에서(=server.listen 메소드의 콜백이 실행되지 않은 상태에서)
- PM2가 네트워크 요청을 새 프로세스로 보낼 때
예전 프로세스가 네트워크 요청을 처리중인데도
- PM2가 무시하고 프로세스를 강제로 죽여버렸을 때

위의 두 가지 모두 서비스가 일시적으로 죽은 것처럼 보이게 만들 수 있다.

PM2는 프로세스를 교체할 때 앱의 구동과 종료에 필요한 시간에 여유를 주고 있다. 다만 그 여유 시간이 지나면 앱이 준비가 되었든 말았든 프로세스가 강제로 교체된다.

PM2는 재시작 명령어(pm2 reload)를 받아서 새 프로세스를 생성한 후 Node.js 앱이 준비될때까지(listen_timeout) 8초, 예전 프로세스가 종료될때까지(kill_timeout) 1.6초 동안 대기한다. 그 설정에 따라

새 프로세스를 시작한 후 8초가 지나면
- PM2는 예전 프로세스에 새 프로세스가 준비되었다는 신호(SIGINT)를 보낸다.
예전 프로세스가 새 프로세스가 시작되었다는 신호(SIGINT)를 받은 후 1.6초가 지나면
- PM2는 예전 프로세스를 강제로 종료시키고 새 프로세스로 교체한다.

하지만 문제는 모든 앱이 PM2가 기본 설정한 그 시간 안에 시작되고, 종료되지는 않는다는 점이다. 그렇다고 해서 대기 시간을 어림짐작으로 30초, 1분 이런 식으로 늘려주는 방법은 현명하지 못하다. 예외라는 것은 언제든지 발생 할 수 있기 때문이다. 무중단 재시작 보장을 위해서는 Node.js 앱 코드에서 PM2와 신호를 주고받아야 한다.

PM2와 Node.js 사이의 신호 교환

PM2 설정 파일

module.exports = {
  apps: [
    {
      name: 'app',
      script: 'server.js',
      instances: 4,
      exec_mode: 'cluster', // 실행 모드. cluster로 명시하지 않으면 기본 fork 모드가 된다.      wait_ready: true, // Node.js 앱으로부터 앱이 실행되었다는 신호를 직접 받겠다는 의미      listen_timeout: 50000, // 앱 실행 신호까지 기다릴 최대 시간. ms 단위.      kill_timeout: 5000, // 새로운 프로세스 실행이 완료된 후 예전 프로세스를 교체하기까지 기다릴 시간      max_memory_restart: '500M',
      env: {
        NODE_ENV: 'development',
      },
      env_production: {
        NODE_ENV: 'production',
        PORT: '8081',
      },
    },
  ],
}

PM2 Ecosystem File Reference

서버 앱의 실행 준비가 완료되었다는 신호를 전달

설정에서 wait_ready 옵션을 true로 설정했으므로 Node.js 앱에서 구동이 완료되었다는 신호를 PM2에게 직접 전달해야 한다. express.js를 서버로 사용한다면 listen 메소드의 콜백에서 시작 신호를 보내면 된다.

const server = express()

const listeningServer = server.listen(port, err => {
  console.log(`> Ready on http://localhost:${port}`)

  // PM2가 스크립트를 실행하지 않았다면 process.send 메소드가 undefined일 수 있다.
  if (process.send) {
    // PM2에게 앱 구동이 완료되었음을 전달한다
    process.send('ready')  }
})

실제로 구현된 앱이 실행되기까지 평균적으로 얼마나 걸리는지 확인을 해보고, 그보다 더 여유있는 시간을 listen_timeout에 설정하면 된다.

새로운 프로세스가 준비되었다는 신호 수신

PM2는 listen_timeout에 설정된 시간이 경과하거나 process.send('ready') 호출을 통해 시작 신호를 수신받으면 예전 프로세스에게 새 앱이 준비되었으니 앱을 종료시키라는 의미로 SIGINT 시그널을 보낸다. Node.js 앱은 이 신호를 받아서 앱을 종료시키면 된다.

let isAppGoingToBeClosed = false // HTTP 연결을 종료시킬 미들웨어에서 사용할 변수

process.on('SIGINT', function() { // SIGINT 신호가 수신되었을 때  console.log('> received SIGNIT signal')

  isAppGoingToBeClosed = true

  // pm2 재시작 신호가 들어오면 서버를 종료시킨다.
  // listeningServer: server.listen 메소드가 리턴하는 서버 인스턴스를 할당한 변수
  listeningServer.close(function(err) {    console.log('server closed')
    process.exit(err ? 1 : 0)
  })
})

위의 예제 코드에서는 로그를 출력하는 정도의 작업만 했지만 서버 앱이 사용중인 데이터베이스같은 다른 서비스의 종료도 처리할 수 있을 것이다. 그리고 앱의 완전한 종료까지 시간이 많이 걸릴 것 같다면 kill_timeout을 더 여유 있게 설정해줘야 한다.

그리고 SIGINT 수신 후에 HTTP 연결을 종료시키기 위해 네트워크 응답에 Connection 헤더를 close로 설정하는 미들웨어를 작성할 수 있다.

server.use(function(req, res, next) {
  // 프로세스 종료 예정이라면 연결을 종료한다
  if (isAppGoingToBeClosed) {
    res.set('Connection', 'close')  }

  next()
})

이렇게 하면 프로세스가 교체되기 전에 Node.js 서버 앱이 먼저 종료되고, 네트워크 요청도 더이상 처리하지 않을 수 있다.

본문에 있는 코드는 글 작성을 위해 만든 예제 앱에서 부분적으로 발췌한 것이며, 완전한 소스는 아래 링크에서 확인할 수 있다.

https://github.com/rhostem/nextjs-pm2-cd

참고

React Final Form을 사용한 폼 제어

rhostem — Mon, 14 Oct 2019 00:00:00 GMT

React Final Form은 Final Form을 React 컴포넌트로 래핑한 라이브러리다. 다른 라이브러리에 대한 의존성 없이 최소 2개의 컴포넌트와 render props 패턴을 가지고 간단히 폼을 제어할 수 있다.

최소한의 기능을 구현하기 위해 form 요소, 텍스트 입력을 위한 input 요소 하나, 그리고 form 요소의 onSubmit 이벤트를 호출하기 위한 button 요소만 있는 예제를 작성한다면 아래와 같다.

React Final Form - Only 1 field - CodeSandbox

import React from "react";
import { render } from "react-dom";
import { Form, Field } from "react-final-form";

const App = () => {
  const onSubmit = values => {
    window.alert(JSON.stringify(values, 0, 2));
  };

  return (
    <Form
      onSubmit={onSubmit}
      initialValues={{ name: "" }}
      render={({ handleSubmit }) => (
        <form onSubmit={handleSubmit}>
          <div>
            <label>Name</label>
            <Field name="name" type="text">
              {({ input }) => (
                <input value={input.value} onChange={input.onChange} />
              )}
            </Field>
          </div>

          <div>
            <button type="submit">Submit</button>
          </div>
        </form>
      )}
    />
  );
};

render(<App />, document.getElementById("root"));

무척 간단하다. Final Form이 내부적으로 옵저버 패턴을 사용하고 있어서 입력값이 변경되면 그 값을 사용하는 모든 내부 상태값과 동작에 즉시 반영된다. 예를 들면 어떤 필드의 값이 변경되면 초기값과 현재 값이 달라졌는지 여부가 업데이트되며, 그 필드의 유효성 검사도 다시 실행되는 식이다. 라이브러리를 사용하는 개발자 입장에서는 최소한의 정보만 제공하면 되어 무척 편리하다. 폼을 직접 구현하기 위해 필드의 값을 직접 컴포넌트에 state에 할당하고, 업데이트하는 함수를 선언하고, 유효성 검사 이벤트를 연결하고… 이런 반복 작업이 모두 사라진다.

물론 Form, Field, 그리고 render props에는 위의 예제에서 작성한 것보다 훨씬 많은 값들이 제공된다. 그리고 위의 예제에서는 폼 데이터 제어에서 필수 요소인 유효성 검사도 빠져 있다.

React Final Form API

Form

폼 제어를 위한 최상위 컴포넌트. Field는 Form 컴포넌트의 render props에 전달한 컴포넌트 안에 있어야 기능한다. Form 컴포넌트는 마운팅될 때 Final Form 인스턴스를 생성하며 Form 상태와 내부 Field들의 상태를 관리한다. 그리고 상태가 업데이트되면 Form 안에 있는 모든 Field에 변경 사항을 알려준다(publish). Field 컴포넌트는 Form으로부터 상태값을 전달받는다(subscribe).

`onSubmit` 함수

Form 컴포넌트에는 onSubmit props를 꼭 전달해야 한다. onSubmit은 폼이 제출(=form 요소의 onSubmit 이벤트가 발생)되고 모든 유효성 검사에 문제가 없을 때 호출되며 모든 필드의 데이터를 포함한 객체를 첫번째 파라미터로 받는다. 객체의 필드들의 이름은 Field 컴포넌트의 name props로 전달된 문자열과 일치한다. 예를 들어 첫번째 예제 코드의 onSubmit 함수의 파라미터는 아래와 같은 형태가 될 것이다.

const onSubmit = (formValues: { name: string }) => {
  // do something
}

폼 초기값 설정

Form 안에 있는 Field들의 초기값은 Field 컴포넌트에 1개씩 할당해도 되지만, 필드의 수가 많으면 Form 컴포넌트의 initialValues props에 1개의 객체로 한꺼번에 전달하는 편이 더 간편하다. initialValues가 받는 데이터는 객체이며, 객체의 필드는 Field 컴포넌트의 name props와 일치해야 한다. 다만 initialValues에는 모든 필드의 초기값을 전달하지 않아도 된다.

<Form
  initialValues={{ userId: '이름' }}
  render={() => {
    return (
      <Field name="userId">
        {props => <input {...props.input} />}  {/* userId 초기값이 적용된다. */}
      </Field>
    )
  }}
>
</Form>

Field

Form 컴포넌트 내부에 위치하며 render props 패턴을 통해 Form 컴포넌트로부터 Field의 상태를 전달받는다. Field의 props로 필드의 이름, 렌더링할 컴포넌트를 전달한다. Field 안에 들어갈 컴포넌트 렌더링에는 입력을 받을 input 같은 요소 외의 다른 어떤 요소가 들어가도 상관없다. 단 Form 컴포넌트에 입력값을 연결하기 위해 props.input.onChange 콜백을 반드시 사용해야 한다.

<Field name="userId">
  {props => (
    <div>
      <label>User Id</label>
      <input
        {/* props로 전달된 input.onChange를 사용해서 데이터를 Form 컴포넌트에 연결한다. */}
        onChange={props.input.onChange}
        value={props.input.value}
      />
    </div>
  )}
</Field>

필드 유효성 검사

Final Form에서 유효성 검사는 단순 함수로 가능하다. 필드의 유효성 검사 함수에는 현재 필드의 값이 전달되고, 함수가 문자열을 리턴하면 필드에 오류가 있음을 의미하며, undefined가 리턴되면 필드에 문제가 없음을 의미한다.

// undefined, null, 빈 문자열이면 오류
const required = v => !v ? '이 값은 필수입니다' : undefined;

// 값이 반드시 숫자
const mustBeNumber = v => typeof v !== 'number' ? '이 값은 숫자여야 합니다' : undefined;

그리고 복수의 유효성 검사를 조합해서 사용하는 것이 가능하다.

export const composeValidators = (...validators) => value =>
  validators.reduce((error, validator) => error || validator(value), undefined);

위의 조합 함수는 팩토리 함수 패턴과 Array.prototype.reduce 함수를 사용했다. reduce 함수에서는 초기값을 undefined(=오류 없음)로 두고 error(현재 값)에 유효한 값이 없으면 유효성 검사를 호출하고, 아니면 더 이상 실행하지 않는 방식이다. 아래와 같은 방식으로 사용할 수 있다.

<Field
  {/* 예를 들어 나이를 입력받는 필드 */}
  name="age"
  {/* 이 필드는 undefined, null이 아니며 값이 숫자여야 한다. 그렇지 않으면 onSubmit이 호출되지 않는다.*/}
  validate={composeValidators(required, mustBeNumber)}
>
  {props => (
    <Field name="age">
      {props => <input {...props.input} />}
    </Field>
  )}
</Field>

유효성 검사 함수가 리턴한 문자열은 Field의 render props에서 meta.error 필드로 전달되어 오류 메시지로 사용한다. 그리고 다른 메타데이터와 조합하면 오류 메시지를 표시할 조건을 구체적으로 결정할 수 있다.

<Field
  name="age"
  validate={composeValidators(required, mustBeNumber)}
>
  {({ input, meta }) =>
    <div>
      <input {...input} />
      {/* 에러는 meta props가 가지고 있다. */}
      {/* 폼 제출에 실패했고 에러 메시지가 있을 때 메시지를 표시하도록 한다 */}
      {meta.submitFailed && meta.error && <span>{meta.error}</span>}
    </div>
  }
</Field>

보다 상세한 필드 유효성 검사 예제는 아래에서 확인할 수 있다.

Final Form Docs – Field-Level Validation

Elastic Beanstalk로 Next.js 앱 배포하기

rhostem — Sun, 01 Sep 2019 00:00:00 GMT

AWS Elastic Beanstalk는 웹 애플리케이션을 배포할 수 있는 클라우드 플랫폼으로 인스턴스 성능 조절, 로드 밸런싱, 상태 모니터링, 버전 관리 등이 가능하다. 사용자에게 웹 애플리케이션 배포를 위한 AWS의 여러 서비스를 통합 제공하는 서비스라고 볼 수 있다. 특히 변화하는 네트워크 트래픽에 대응할 수 있도록 자동 스케일링을 지원한다. 그리고 복수의 환경을 구성해서 스테이징 버전을 충분히 테스트한 후 프로덕션 버전을 서비스 중단 없이 교체하는 등 서비스 안정성 보장을 위한 다양한 기능이 있다.

공식 문서에는 Node.js 플랫폼에서 express 애플리케이션을 배포하는 방법을 제공한다. 이 글에서는 별도의 빌드 과정이 필요한 Next 앱을 배포하는 과정을 정리했다.

Elastic Beanstalk 용어

애플리케이션
- 복수의 환경으로 구성된 작업 공간.
환경
- 앱이 실행되는 배포 환경. 각각의 환경은 서로 다른 ID와 접속 URL을 가진다. 개발, 릴리즈, 프로덕션 등 목적에 맞게 추가해서 사용할 수 있다.
인스턴스
- 1개의 환경은 복수의 AWS EC2 인스턴스를 가질 수 있다. 인스턴스 유형은 필요한 성능에 맞춰 선택할 수 있다.
플랫폼
- 운영체제, 웹 서버, 애플리케이션 서버 등 웹 애플리케이션 실행을 위한 구성 요소를 포함한다.
용량
- 환경의 인스턴스가 1개 이상이면 자동으로 로드 밸런싱이 작동한다. 환경은 최소 1개에서 최대 10000개의 인스턴스를 가질 수 있다. 실제로 사용되는 인스턴스의 수는 사용자가 설정한 최소, 최대 인스턴스 수와 트리거에 기반을 둬서 자동으로 조절된다.
롤링 업데이트
- 배포를 하면 기본적으로 모든 인스턴스를 한 번에 업데이트한다. 그런데 Elastic Beanstalk는 드롭인(drop-in) 업그레이드 프로세스를 사용하기 때문에 애플리케이션이 몇 초 정도 가동이 중지될 수 있다. 그래서 프로덕션 환경에서는 인스턴스를 나눠서 업데이트하는 방법이 권장된다. 한 번에 업데이트할 인스턴스의 수와 비율을 사용자가 직접 지정할 수 있다.

배포 과정

아래의 배포 과정은 macOS에서 진행할 수 있다.

1. EB CLI 설치

설치 스크립트가 있는 Git repository를 클론한 후 실행한다.

git clone https://github.com/aws/aws-elastic-beanstalk-cli-setup.git

./aws-elastic-beanstalk-cli-setup/scripts/bundled_installer

시스템에 파이썬이 설치되어 있지 않다면 bundled_installer 실행 중에 오류가 발생한다. 그럴 때는 scripts 폴더에 있는 python_installer로 파이썬을 설치한 후 진행하면 된다. 설치 성공 후에는 CLI 실행 파일을 PATH에 추가하는 명령어가 제공되므로 그것도 실행해준다.

2. Git 저장소 초기화

Elastic Beanstalk는 Git 저장소에서 마지막으로 커밋된 버전을 압축해서 S3에 올린다. 소스를 수정했더라도 커밋을 하지 않았다면 해당 내용은 배포되지 않으니 주의해야 한다.

그리고 현재 브랜치의 커밋이 원격에 푸시되지 않아도 배포할 수 있다. 그래서 공동 작업을 한다면 CI 도구를 사용해서 원격에 올라간 작업 내용만 Elastic Beastalk에 배포되게 보장해야 할 것이다.

3. Next.js 앱 설치

Next.js 문서에 있는 설치 과정을 참조해서 빌드와 실행이 가능하도록 프로젝트를 소스를 구성한다.

4. `eb init`

Elastic Beanstalk 애플리케이션을 생성하거나 선택할 수 있도록 초기 설정을 진행한다. 자기에게 맞는 리전, 플랫폼 등을 선택한다.

5. `eb create`

배포할 환경을 만든다. 이름을 입력하고 로드 밸런서 타입을 선택한다. 로드 밸런서는 보통 기본 타입인 application을 선택한다.

init, create 과정을 거치면 프로젝트 폴더에 .elasticbeanstalk/config.yml 파일이 만들어진다.

branch-defaults:
  develop:
    environment: eb-next-app-dev # develop 브랜치에서 배포할 환경. eb use 명령어로 수정 가능하다. environment-defaults:
  eb-next-app-dev:
    branch: null
    repository: null
global:
  application_name: eb-next-app # 애플리케이션 이름  default_ec2_keyname: key-name # 배포에 ssh를 사용하려면 AWS IAM에서 엑세스 키를 만들어야 한다.  default_platform: arn:aws:elasticbeanstalk:ap-northeast-2::platform/Node.js running on 64bit Amazon Linux/4.10.1 # 선택한 플랫폼
  default_region: ap-northeast-2 # Seoul 리전
  include_git_submodules: true
  instance_profile: null
  platform_name: null
  platform_version: null
  profile: eb-cli
  sc: git
  workspace_type: Application

이 글에서 진행하는 배포 과정에서는 config.yml 파일을 직접 수정해야 할 필요가 없다.

6. .ebignore 파일 추가

배포는 Git 저장소 전체를 S3에 업로드하는 방식이다. .gitignore 설정 파일이 있다면 등록된 파일을 제외하고 배포를 한다. 그런데 .gitignore에는 보통 .next, node_modules처럼 앱 실행에 필요한 파일과 폴더가 지정되어 있다. 그런 상태에서 배포를 해서 앱을 실행하면 자연히 필요한 파일을 찾지 못하는 오류가 생긴다. 그래서 .ebignore 파일에 배포를 할 때 제외시킬 파일을 지정해야 한다. .ebignore에는 아래와 같은 내용이 들어갈 수 있다.

.git
.gitignore

Git 저장소 관련 파일만 제외하고 모두 배포하도록 했다. EB CLI는 .ebignore가 있으면 .gitignore를 무시한다.

7. Next.js 앱의 실행 포트를 8081로 변경

Elastic Beanstalk의 node.js 플랫폼은 기본적으로 웹 서버로 Nginx를 사용하며 리버스 프록시 설정을 통해 외부 접근을 8081 포트로 보낸다. 그런데 Next 앱은 기본적으로 서버 포트로 3000을 사용한다. 리버스 프록시 설정을 직접 수정할 수도 있지만 Next 앱이 프로덕션 모드로 실행할 때 8081 포트를 사용하도록 package.json 파일을 수정하는 편이 더 간단하다.

{
  "scripts": {
    "start": "next start -p 8081",
  }
}

8. .npmrc 설정 (생략 가능)

Elastic Beanstalk에서 node.js 앱을 실행하기 위한 기본 명령어는 npm start로 지정되어 있다(콘솔에서 수정 가능). 만약 저 스크립트에 npm install이 포함되어 있다면 배포 과정에서 오류가 발생할 수 있다.

npm install은 root 계정으로 실행되지만 node-gyp 프로세스가 일부 패키지를 기본 계정인 ec2-user로 실행한다. 그 결과 node-gyp 프로세스가 root 계정이 만든 파일에 접근할 수 없는 오류를 만든다. 이를 방지하기 위해서는 npm이 node-gyp 프로세스를 강제로 root 계정을 통해 실행하도록 .npmrc 파일을 추가해야 한다.

unsafe-perm=true

9. `eb deploy`

터미널에서 eb deploy <환경 이름>을 실행하면 해당 환경으로 브랜치의 최근 커밋이 배포된다.

빌드 후 배포가 진행되도록 npm script를 수정한다.

{
  "scripts": {
    "dev": "next dev",
    "start": "next start -p 8081",
    "build": "npm run clean && next build",
    "clean": "rm -rf .next",
    "deploy-dev": "npm install && npm run build && eb deploy eb-next-app-dev"  }
}

npm run deploy-dev

10. `eb open`

배포에 성공했다면 eb open 명령어를 사용해서 기본 브라우저에 배포된 웹페이지를 열어본다. 접속 주소는 콘솔에서도 확인할 수 있다.

참고 문서

샘플 앱 저장소

rhostem/eb-next-app: deploy next app with elastic beanstalk

React Hooks API가 도입된 이유

rhostem — Sun, 18 Aug 2019 00:00:00 GMT

React Hooks(이하 리액트 훅)은 함수형 컴포넌트로 클래스 컴포넌트를 대체하기 위한 목적으로 도입되었다. 훅이 있기 전의 함수형 컴포넌트는 자체 state(상태)를 가질 수 없었고 상위 컴포넌트로부터 props(값)을 전달받아 표현하는 컴포넌트(presentational or dumb component)로 사용되고 있었다. 구분하자면 클래스 컴포넌트는 컨트롤러, 함수형 컴포넌트는 유닛이었다.

하지만 React 16.8 이후 리액트 훅이 도입되면서 그런 구분이 사라졌다. 새로운 API를 통해 함수형 컴포넌트도 자체 상태를 가질 수 있으며 라이프사이클 메소드를 대체할 수 있는 방법이 생겼다.

React가 등장한 후 5년여 동안 많은 변화가 있었지만 컴포넌트를 작성하는 API에는 큰 변화가 없었다. 그런데 왜 갑자기 기존의 방법론을 뒤엎는 새로운 길을 제시한 것일까?

컴포넌트 로직 공유의 복잡함

리액트에서 컴포넌트 상태 관리 로직을 공유하기 위한 방법으로는 hoc(Higher-Order Components)와 render props가 있다. 하지만 두 패턴 모두 처음보면 다소 이해하기 어려우며 실무 활용을 위해서는 여러가지 예제 코드를 분석하고 직접 만들어보는 학습 과정이 필요하다. 특히 자바스크립트에서는 함수가 일급 객체여서 함수(리액트 컴포넌트)를 함수의 파라미터로 전달해서 활용하는 패턴이 익숙하지 않을 수 있다. 그리고 타입스크립트로 리액트를 사용한 사람이라면 hoc의 리턴 타입을 선언하는 일이 무척 까다로워서 고생했던 경험을 가진 사람이 많을 것이다.

하지만 이제 함수형 컴포넌트에서 커스텀 훅을 사용하면 hoc와 render props을 대체할 수 있다. 그리고 커스텀 훅은 특별한 것이 아니라 그냥 ‘함수’다. 예를 들어 input 요소의 상태를 관리하는 기능을 커스텀 훅으로 분리하면 아래와 같다.

import React, { useState, useEffect } from 'react';

function useChangeInput({ initialValue, onChange = () => {} }) {
  const [value, setValue] = useState('');

  const handleChange = value => {
    setValue(value);
    onChange(value);
  };

  useEffect(() => {
    setValue(initialValue);
    return () => {
      setValue('');
    };
  }, [initialValue]);
  
   
  return {    value,     handleChange,   };}

// 커스텀 훅을 사용할 컴포넌트
function SampleInput() {
  const {
    value,
    handleChange,
  } = useChangeInput({  // custom hook을 호출해서 상태 관리에 필요한 값을 가져온다    initialValue: '',
  });

  return (
    <input
      type="text"
      value={value}
      onChange={handleChange}
    />
  );
}

useChangeInput 커스텀 훅은 일반적인 함수면서 내부에 useEffect같은 훅 API를 사용하고 있다. 커스텀 훅을 사용할 때는 hoc처럼 컴포넌트를 함수로 래핑하는 과정이 필요없고 단순히 호출을 통해 필요한 상태와 액션을 컴포넌트에 연결(hook)만 하면 된다.

커스텀 훅이 Redux를 대체할 수 있다?

커스텀 훅의 사용 방식은 마치 Redux로 앱 상태 관리자를 따로 두면서 필요한 컴포넌트에 action과 state를 연결하는 방식과(connect hoc와 mapStateToProps, mapDispatchToProps) 유사하다. 게다가 리액트에서 useReducer API를 제공하고 있으니 리액트가 Redux가 제공하는 기능을 대체하려는 의도가 있는 것인가? 라고 생각할 수도 있다. 하지만 커스텀 훅은 싱글 인스턴스를 만들지 않으며 클로져처럼 동작한다. 커스텀 훅을 사용하는 컴포넌트마다 서로 다른 상태 값을 참조하게 되는 것이다. 여러 컴포넌트에서 상태를 공유하기 위해서는 Redux나 Context API, 컴포넌트 트리를 통해 props 전달하기 같은 방식을 여전히 사용해야 한다.

그리고 Redux는 관련 라이브러리 생태계가 오랜 기간 유지되어 왔으며 미들웨어를 통해 확장할 수 있는 기능이 많다. 또 react-redux는 최신 버전에서 useSelector같은 함수형 컴포넌트를 위한 API도 제공하고 있다. 역할을 구분하자면 커스텀 훅은 UI 상호작용과 관련된 로컬 컴포넌트 상태 관리에, Redux는 앱의 핵심 상태를 관리하는 비지니스 로직을 관리하는 일로 나눌 수 있다.

훅을 사용할 케이스
- UI의 상태를 네트워크 또는 로컬 스토리지 등을 통해서 별도로 저장하거나 가져오지 않음
- child가 아닌 다른 컴포넌트와 상태를 공유하지 않음
- 계속 유지되지 않고, 일시적으로 존재할 상태(ex. input 필드의 입력)
redux를 사용할 케이스
- 네트워크나 디바이스 API를 사용한 I/O
- 상태의 저장, 불러오기
- child가 아닌 컴포넌트와 상태 공유
- 앱의 다른 파트와 공유해야 하는 비즈니스 로직, 데이터 처리

사이드 이펙트와 버그를 유발할 수 있는 라이프사이클 메소드

클래스 컴포넌트에는 라이프사이클 메소드가 제공된다. 대표적으로 componentDidMount, render, componentDidUpdate 메소드가 있으며 각각 서로 다른 시점에 호출되며 서로 다른 목적을 가진다.

http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram

라이프사이클 메소드는 러닝 커브를 높이는 역할을 함은 물론 의도하지 않은 사이드 이펙트와 버그를 발생할 가능성도 함께 높인다. 예를 들어 렌더링 여부를 결정하는 shouldComponentUpdate 라이프사이클은 최적화를 위해서 많이 사용되지만, 데이터 업데이트에 제대로 반응하지 않는 먹통 컴포넌트를 종종 만들어내는 원인이 되기도 된다.

  shouldComponentUpdate(prevProps, prevState) {
    if (isDeepEqual(this.props.data, prevProps.data)) {
      return false
    } else {
      return true
    }
  }

위의 예제에서는 업데이트된 data props의 내용이 같다면 렌더링을 추가로 실행하지 않는다. 의도하지 않은 버그를 방지하기 위해서는 저 컴포넌트의 복잡도를 낮춰서 컴포넌트가 업데이트되는 경우의 수를 가능한 한 적게 유지해야 할 것이다.

그리고 props를 기반으로 컴포넌트를 업데이트하려면 componentDidUpdate 라이프사이클을 사용하게 된다. 컴포넌트 사이즈가 조금만 커지면 저 라이프사이클 메소드에 props를 확인하는 if 문과 로직이 계속 추가되고 클래스의 메소드도 계속해서 추가된다.

  componentDidUpdate(prevProps, prevState) {
    if (this.props.id !== prevProps.id) {
      this.fetchData(id)
    }

    if (this.props.initialDate !== prevProps.initialDate) {
      this.setState({
        date: initialDate
      })
    }

    // 또 다른 사이드 이펙트 ...
  }

사이드 이펙트가 많아지면 자연스럽게 컴포넌트의 덩치가 커지고, render 메소드만으로는 이 컴포넌트가 어떻게 동작하는지 파악하기 어려워진다. 하지만 componentDidUpdate 들어갈 사이드 이펙트를 커스텀 훅으로 분리하면 컴포넌트의 복잡도를 낮출 수 있다. 그리고 라이프사이클을 사용하는 컴포넌트에 비해서 테스트코드 작성도 더 쉬워진다.

props와 state가 바뀌면 다시 렌더링 된다는 1개의 규칙

함수형 컴포넌트에서는 라이프사이클 메소드가 없으니 렌더링 규칙은 명확하다. 상위 컴포넌트에서 전달받는 props가 달라지거나 컴포넌트 안에서 useState로 관리하는 상태 값이 업데이트되면 컴포넌트가 다시 렌더링 된다. 그리고 특정 값이 변경되었을 때 사이드 이펙트를 발생시키는 useEffect, 캐싱을 지원하는 useMemo, 함수의 레퍼런스를 유지시켜주는 useCallback 등의 API를 사용해서 컴포넌트 렌더링을 제어 할 수 있다.

처음 사용하면 생각지 못하게 무한 렌더링에 빠지는 등 클래스 컴포넌트와는 다른 구현 방식에 익숙해지는 데 시간이 걸릴 수 있다. 하지만 어느 정도 적응이 되면 클래스 컴포넌트보다 간단한 문법, 값이 바뀌고 레퍼런스가 바뀌면 컴포넌트가 다시 렌더링 된다는 일관적인 규칙의 단순함이 좋아서 굳이 클래스 컴포넌트로 돌아가고 싶은 마음이 들지 않게 될 것이다.

참고 문서

mobx-react와 React Hooks API 함께 사용하기

rhostem — Mon, 22 Jul 2019 00:00:00 GMT

React hooks와 mobx-react v4

React 16.8에서 도입된 React Hooks는 함수형 컴포넌트에서 상태를 관리할 수 있는 새로운 방법을 제공한다. Hooks API를 사용하면 함수형 컴포넌트에서도 자체 상태값을 가질 수 있으며, 클래스 컴포넌트의 라이프사이클 메소드도 대체할 수 있다. 물론 클래스 컴포넌트가 더 좋은지 함수형이 더 좋은지는 논쟁의 여지가 있다. 그리고 컴포넌트가 커지면 복잡도가 높아지는 것은 클래스나 함수형이나 마찬가지다. 하지만 개인적으로는 적절한 크기의 컴포넌트라면 확실히 Hooks를 사용했을 때 코드가 더 간결하고 직관적이라는 인상을 받았다.

그런데 mobx-react가 제공하는 observer로 래핑된 함수형 컴포넌트에서 useState같은 훅 API를 사용하려고 하면 React는 “훅은 함수형 컴포넌트에서만 사용할 수 있다”는 메시지와 함께 오류를 발생시킨다. mobx-react v4의 observer API는 클래스 컴포넌트를 리턴하는 hoc(higher order component)이기 때문이다. 훅을 사용하면서 mobx-react의 store에서 데이터를 가져오려면 mobx-react v6 또는 mobx-react-lite를 사용해야 한다.

mobx-react v6

mobx-react-lite는 React 16.8과 훅을 지원하기 위해 함수형 컴포넌트에서만 사용할 수 있는 API만 제공하고 있다. 특히 mobx-react-lite는 React legacy Context API를 사용하는 Provider, inject API를 제공하지 않는다. 대신 React.createContext API를 사용해서 store를 가져오는 방법을 제안한다.

mobx-react v4, v5를 사용해서 앱을 개발하고 있었다면 mobx-react-lite의 React Hooks를 위한 API를 포함하고 있는 mobx-react v6로 마이그레이션 하면 된다. 마이그레이션이라 해도 이미 구현되어 있는 클래스 컴포넌트는 수정할 필요가 없어서 크게 부담이 없다. 물론 공식 문서에서는 store를 새로운 API(=useLocalStore)로 구현하는 방법을 권하고 있다. 하지만 Hook API가 제공된다고 해서 클래스 컴포넌트를 버려야 할 이유는 없으므로 어떻게 사용할지는 이 도구를 사용하는 사람의 선택에 달렸다고 할 수 있다.

함수형 컴포넌트에서 `inject` 를 대체할 `useStore` 함수

앞서 언급했듯이 마이그레이션을 위해서 기존의 코드를 수정해야 할 필요는 없다. 다만 훅을 사용하는 함수형 컴포넌트를 위한 inject hoc는 별도로 제공하지 않으므로 store를 가져오기 위한 헬퍼 함수를 만들어야 한다. 간단하게 구현 가능하다.

import React from 'react';
import { MobXProviderContext } from 'mobx-react';

/**
 * React hooks를 사용하는 컴포넌트에서 store를 가져올 때 사용한다.
 * 참조) https://mobx-react.js.org/recipes-migration#hooks-for-the-rescue
 */
function useStores() {
  return React.useContext(MobXProviderContext);
}

export default useStores;

React.useContext API는 파라미터로 전달된 Context의 현재 값을 반환한다. 거기에 MobXProviderContext 를 사용하면 mobx-react의 Provider 가 제공하는 store 객체를 가져올 수 있다.

import { observer } from 'mobx-react'
import { useStores } from '../useStores'

const UserInfo = observer(() => {
  const { user } = useStores()
  return (
    <div>
      name: {user.name}
    </div>
  )
})

컴포넌트를 observer hoc로 래핑하는 과정은 동일하다. 대신 클래스 컴포넌트의 inject hoc를 사용하는 대신 useStores 헬퍼 함수를 사용해서 store 객체를 가져올 수 있다.

개발을 진행하면서 특정 데이터를 사용하는 패턴이 보인다면 커스텀 훅을 만드는 것처럼 커스텀 useStores 함수를 만들 수도 있을 것이다.

import { useObserver } from 'mobx-react'

function useUserData() {
  const { user, login } = useStores()
  return useObserver(() => ({ // useObserver를 사용해서 리턴하는 값의 업데이트를 계속 반영한다
    userName: user.name,
    isLoggedIn: login.isLoggedIn,
  }))
}

const UserInfo = () => { 
  const { username, isLoggedIn } = useUserData()
  return (
    <div>
      {username} is {isLoggedIn ? 'on' : 'off'}
    </div>
  )
}

useUserData가 리턴하는 객체가 useObserver로 래핑되어 있기에 컴포넌트를 observer로 래핑하지 않아도 동작한다. 하지만 컴포넌트에 다른 observable을 사용한다면 래핑이 필요하다.

함수형 컴포넌트를 위한 injector hoc

함수형 컴포넌트에서는 useStores를 사용하면 된다. 하지만 클래스 컴포넌트에서 사용하던 스타일로 inject hoc를 사용하고 싶다면 직접 구현할 수 있다. 공식 문서에서도 간단한 구현을 제공하고 있다. 하지만 개인적으로는 useStores를 사용하는 편이 더 간단하고 훅 API에도 어울려 보인다.

import { observer } from 'mobx-react'
import { useStores } from '../useStores'

function inject(selector, baseComponent) {
  const component = ownProps => {
    const store = useStores()
    return useObserver(() => baseComponent(selector(store, ownProps)))
  }
  component.displayName = baseComponent.name
  return component
}

[번역] 탄력적인 컴포넌트 작성하기

rhostem — Sun, 14 Jul 2019 00:00:00 GMT

(이 글은 React의 코어 컨트리뷰터인 Dan Abramov 의 Writing Resilient Components를 번역한 글입니다.)

React를 배우기 시작하는 사람들은 보통 스타일 가이드를 찾아본다. 프로젝트 전반에 적용되는 일관적인 규칙을 가지려는 자세는 좋으나 대부분은 각자가 정한 임의의 규칙에 따르게 된다. 그래서 React는 어떤 규칙을 지키라고 특별히 강요하지 않고 있다.

사람마다 다른 타입 시스템을 사용할 수 있고, 함수 선언 또는 화살표 함수 중 하나를 더 선호할 수 있으며, 나중에 찾기 쉬우려고 props를 알파벳 순으로 정렬해 둘 수도 있다.

이런 유연함은 React를 이미 규칙(convention)이 존재하고 있는 프로젝트에 도입해서 사용하는 일을 가능하게 한다. 하지만 끝없는 논쟁도 불러일으키기도 한다.

React에는 모든 컴포넌트가 지키기 위해 노력해야 할 중요한 디자인 원칙들이 있다. 그런데 내 생각엔 스타일 가이드들이 이 원칙들을 잘 받아들여서 만들어져 있지 않은 것 같다. 먼저 스타일 가이드에 대해 살펴보고, 그 후에 정말로 유용한 원칙들에 대해 얘기하려고 한다.

상상 속의 문제에 주의를 빼앗기지 마라

컴포넌트 디자인 원칙을 이야기하기 전에, 나는 스타일 가이드에 대해 몇 마디를 하고 싶다. 이건 사람들이 좋아할 만한 얘기는 아니지만, 누군가는 해야 한다!

자바스크립트 커뮤니티에서는 린터¹가 강요하는 매우 편항적인 스타일이 몇몇 존재한다. 내가 보기에는 어떤 이들은 그 스타일을 가지고 필요 이상으로 다른 사람들과 마찰을 일으키곤 한다. 나는 아무런 문제가 없는 코드를 내게 보여주면서 “React가 이 코드에 문제가 있다고 하네요?”라고 말하는 사람을 도대체 몇 명이나 봤는지 셀 수가 없을 정도다. React가 아니라 그들이 사용하고 있는 린터의 규칙이 그렇게 말하고 있는 것이란 말이다! 이는 세 가지 이슈로 이어진다.

사람들은 린터가 개발에 유용한 도구 역할을 하기보다 지나치게 시끄러운 감시인 역할을 하는 것에 익숙해져 있다. 코딩 스타일의 깔끔함을 유지하기 위해 검사기가 발생시키는 너무나 많은 메시지 때문에 유용한 경고문들은 다 묻혀버린다. 결과적으로 사람들은 디버깅할 때 린터의 메시지를 살펴보지 않게 되며 유용한 팁도 놓치게 된다. 게다가 자바스크립트 작성에 익숙하지 않은 사람들(예를 들어 디자이너)은 코드를 작성하는데 더 어려운 시간을 보내게 된다.
사람들은 특정 패턴이 맞는 것인지 틀린 것인지 구분할 수 없게 된다. 예를 들어 인기 있는 규칙 중에 setState를 componentDidMount에서는 호출하지 말라는 것(react/no-did-mount-set-state)이 있다. 하지만 만약 저것이 항상 “나쁜” 패턴이었다면 React는 애초에 그런 코드를 작성할 수 있게 만들지도 않았을 것이다! 저 패턴의 적법한 사용 사례에는 DOM 노드의 레이아웃을 확인하는 것 – 예를 들면 툴팁의 위치 결정 – 이 있다. 나는 저 규칙에 걸리지 않으려고 setTimeout을 추가하는 사례를 많이 봤다. 완전히 요점을 놓쳐버린 것이다.
결국 사람들은 린터 덕분에 “강압적인 마인드”를 가지게 되고 별다른 차이도 없으면서 코드에서 확인하기 쉬운 규칙을 지키려 하게 된다. “당신은 함수 선언에 익숙하다고 했지만, 우리 프로젝트에서는 화살표 함수를 사용할 것입니다.” 나는 저런 규칙을 강요한다는 느낌이 들 때마다 내가 감정적인 소모를 한다는 것을 알게 되어서, 이제는 그냥 놓아버리려고 노력한다. 그것들은 내 코드의 품질을 높여주지는 않고 단지 스타일을 지키면서 잘못된 성취감을 느껴보라고 어르고 있는 것 같다.

그렇다고 내가 린터를 사용하지 말라고 하는 건가? 전혀 그렇지 않다!

좋은 규칙과 함께라면 린터는 버그가 일어나기 전에 잡아줄 수 있는 아주 훌륭한 도구다. 하지만 스타일에 너무 치중해서 개발에 오히려 방해되고 있다는 말이다.

필요한 문법 규칙만 남기고 정리하자

당장 다음 주 월요일에 할 수 있는 일을 제안하려고 한다. 팀원들과 함께 30분만 투자해서 프로젝트에 설정된 문법 규칙을 하나씩 살펴보기 바란다. “이 규칙이 정말로 우리가 버그를 잡는 데 도움이 줬던가?”라고 물어보자. 만약 아니라면 그냥 꺼 버려라.(또는 스타일 규칙이 없는 깔끔한 eslint-config-react-app에서 시작해도 된다)

최소한 저런 규칙 때문에 팀 내부에서 생길 수 있는 잡음을 일찌감치 제거하는 과정이 필요하다. 당신이나 누군가가 수년 전에 린터에 추가해 둔 어떤 규칙도 “모범 사례”라고 여기지 않았으면 한다. 사용 중인 규칙에 대한 의구심을 가지고 정답을 찾아보자. 그 누구도 당신이 린터 규칙을 결정할 정도로 똑똑하지 않다고 말할 순 없다.

그런데 코드 포매팅은 어떻게 할까? Prettier를 사용하고 “스타일의 깔끔함”에 대해서는 잊어버리자. 코드에서 빠진 세미콜론이나 빈칸을 알아서 추가해 줄 수 있는 도구(=Prettier)를 이미 사용하고 있는데도 다른 도구가 잘못된 곳이 있다고 소리치도록 둘 필요는 없다. 린터는 버그를 찾기 위해서 사용해야지, 우리에게 코드의 심미성을 강요하게 만들어선 안 된다.

물론 포매팅과 직접적인 관계는 없지만, 프로젝트 전반에 일관적으로 적용되지 않으면 신경을 거슬리게 하는 코딩 스타일이 있긴 하다.

그러나, 그런 것들은 대부분 린터의 규칙으로 잡아내기에는 너무나 미묘하다. 그래서 동료들 간에 신뢰를 구축하는 일과 본인이 공부한 내용을 위키 형식이나 짧은 디자인 가이드 형태로 공유하는 일이 중요하다.

모든 것을 자동화할 필요는 없다! 동료가 시간을 들여 작성한 가이드를 읽으며 얻는 통찰은 그저 단순히 “규칙”을 따르는 것보다 훨씬 더 가치 있는 일이다.

그런데 엄격한 스타일 가이드를 따르는 것이 방해된다면, 무엇이 정말로 중요한가?

그것이 이 포스트의 주제다.

탄력적인 컴포넌트 작성하기

들여쓰기를 맞추는 일이나 모듈 import를 알파벳 순으로 정리하는 일이 잘못된 컴포넌트 디자인을 바로잡아 주지 않는다. 그래서 코드가 어떻게 보이는지에 초점을 맞추는 대신 나는 어떻게 동작하는지에 초점을 맞추려고 한다. 내가 도움된다고 여기는 몇 개의 컴포넌트 디자인 원칙들이 있다.

데이터 흐름을 멈추지 마라
언제라도 렌더링을 할 준비가 되어 있게 하라
싱글턴(singletone)인 컴포넌트는 없다.
로컬 state를 독립된 상태로 유지하라

만약 당신이 React를 사용하지 않는다고 하더라도, 단방향(unidirectional) 데이터 흐름 모델을 사용하는 UI 라이브러리를 사용하다 보면 이와 같은 규칙을 찾아내게 될 것이다.

원칙 1: 데이터 흐름을 멈추지 마라

렌더링에서 데이터 흐름을 멈추지 마라

다른 사람이 당신이 만든 컴포넌트를 사용할 때, 그들은 다른 값을 가진 props를 계속 전달할 수 있고 컴포넌트에 그 변화가 반영될 것이라 기대한다.

// isOk 는 상태 값에 기반을 두며 언제든지 변경될 수 있다
<Button color={isOk ? `blue` : `red`} />

일반적으로 이것이 React가 기본적으로 동작하는 방식이다. 당신이 color prop을 Button 컴포넌트에 전달한다면 위의 렌더링 과정에서 전달된 값을 확인할 수 있다.

function Button({ color, children }) {
  return (
    // ✅ `color` 값은 언제나 신선!
    <button className={'Button-' + color}>
      {children}
    </button>
  );
}

하지만 React를 배우면서 하게 되는 흔한 실수는 props를 state로 복사하는 것이다.

class Button extends React.Component {
  state = {
    color: this.props.color
  };
  render() {
    const { color } = this.state; // 🔴 `color`는 오래됨!
    return (
      <button className={'Button-' + color}>
        {this.props.children}
      </button>
    );
  }
}

이는 클래스를 React 밖에서 사용한 경험이 있다면 더 직관적이었을 것이다. 하지만 어떤 props를 state에 복사한다면 당신은 Button에 오는 모든 업데이트를 무시하게 된다.

// 🔴 color를 state에 복사한 구현으로는 더는 제대로 작동하지 않는다.
<Button color={isOk ? `blue` : `red`} />

이런 구현을 의도적으로 하는 경우가 아주 드물게 있긴 하다. initialColor또는 defaultColor 값을 받아서 그 값들의 업데이트를 무시하겠다고 확실히 하는 것이다.

하지만 일반적으로 당신은 props를 컴포넌트에서 직접 읽을 수 있길 바랄 것이며 props(그리고 props로부터 계산된 어떤 값이라도)를 state에 복사하는 일은 피하고 싶을 것이다.

function Button({ color, children }) {
  return (
    // ✅ `color` 값은 언제나 최신!
    <button className={'Button-' + color}>
      {children}
    </button>
  );
}

계산된 값²은 사람들이 이따금 props를 state로 복사하게 되는 원인 중 하나다. 예를 들어 버튼 텍스트 컬러를 결정하는데 color를 파라미터로 받으면서 결과를 얻는데 시간과 자원이 많이 소모되는 함수를 사용한다고 생각해보자.

class Button extends React.Component {
  state = {
    textColor: slowlyCalculateTextColor(this.props.color)
  };
  render() {
    return (
      <button className={
        'Button-' + this.props.color +
        ' Button-text-' + this.state.textColor // 🔴 `color` prop 업데이트를 반영하지 않는다
      }>
        {this.props.children}
      </button>
    );
  }
}

이 컴포넌트는 color prop이 변경되었을 때 this.state.textColor를 다시 계산하지 않으므로 버그가 있다고 할 수 있다. 가장 쉬운 해법은 textColor 계산을 render 메소드 안에서 하고 PureComponent를 사용하는 방법이다.

class Button extends React.PureComponent {
  render() {
    const textColor = slowlyCalculateTextColor(this.props.color);
    return (
      <button className={
        'Button-' + this.props.color +
        ' Button-text-' + textColor // ✅ 언제나 최신 
      }>
        {this.props.children}
      </button>
    );
  }
}

문제가 해결되었다! 이제 props가 변경되면 textColor를 다시 계산한다.PureComponent를 사용했으니 같은 prop이 넘어오면 무시하므로 비싼 계산을 다시 하지도 않는다.

하지만 우리는 더 최적화를 하고 싶다. 만약 children prop이 바뀐다면 어떻게 되나? 렌더링을 할 때마다 그 textColor를 계산하는 무거운 함수(slowlyCalculateTextColor)를 다시 실행하게 될 것이다. 이를 해결하기 위한 솔루션은 아마도 componentDidUpdate에서 textColor를 계산하는 방법이 될 것이다.

class Button extends React.Component {
  state = {
    textColor: slowlyCalculateTextColor(this.props.color)
  };
  componentDidUpdate(prevProps) {
    if (prevProps.color !== this.props.color) {
      // 😔 color가 업데이트 될 때마다 추가적인 렌더링이 들어간다.
      this.setState({
        textColor: slowlyCalculateTextColor(this.props.color),
      });
    }
  }
  render() {
    return (
      <button className={
        'Button-' + this.props.color +
        ' Button-text-' + this.state.textColor // ✅ 최종 렌더링에서는 prop 업데이트를 반영한다
      }>
        {this.props.children}
      </button>
    );
  }
}

하지만 이는 우리의 컴포넌트가 prop이 바뀔때마다 한 번 더 렌더링하게 될 것을 의미한다. 우리가 최적화를 시도한 상황이라면 이건 이상적인 방법이 아니다.

이제는 레거시가 된 componentWillReceiveProps 라이프사이클 메소드를 사용할 수도 있다. 하지만 사람들은 보통 거기에 사이드 이펙트도 함께 집어넣는다. 그리고 그것은 앞으로 React에서 구현될 동시 렌더링(Concurrent Rendering) 기능과 관련된 시분할과 지연(Time slicing and Suspense) 문제를 야기한다. 그리고 “안전한” getDerivedStateFromProps 라이프사이클 메소드는 이제 좀 구식이다.

두 번째로 돌아가 보자. 사실 우리는 메모이제이션(memoization)을 원한다. 어떤 입력값이 있고, 우리는 그 입력값이 바뀌지 않는 한 다시 계산하지 않길 바란다.

클래스를 사용한다면 메모이제이션을 위한 헬퍼를 사용할 수도 있다. 하지만 한 단계 더 나가서 비싼 계산을 메모이제이션 할 수 있는 기능을 제공하는 React의 Hooks를 사용해보자.

function Button({ color, children }) {
  const textColor = useMemo(
    () => slowlyCalculateTextColor(color),
    [color] // ✅ `color`가 바뀔 때만 실행하라는 의미
  );

  return (
    <button className={'Button-' + color + ' Button-text-' + textColor}>
      {children}
    </button>
  );
}

이게 당신이 필요한 코드 전부다!

클래스 컴포넌트에서는 memoize-one 같은 헬퍼를 사용할 수 있다. 함수형 컴포넌트에서는 useMemo 훅(Hook)이 비슷한 기능을 제공한다.

이제 우리는 비싼 계산을 최적화하는 과정에서도 props를 state에 복사하는 것은 좋은 방법이 아니라는 사실을 확인했다. 우리의 렌더링 결과는 props의 변경을 계속 반영해야 한다.

사이드 이펙트 안에서 데이터 흐름을 멈추게 하지 말라

지금까지 얘기한 내용은 prop 변경이 있을 때 렌더링 결과를 일관적으로 유지하는 방법에 관한 것이다. props를 state에 복사하지 않는 것이 거기에 포함된다. 그런데 한편으로는, 사이드 이펙트 또한 데이터 흐름의 일부라는 것도 중요하다.

아래의 React 컴포넌트를 살펴보자.

class SearchResults extends React.Component {
  state = {
    data: null
  };
  componentDidMount() {
    this.fetchResults();
  }
  fetchResults() {
    const url = this.getFetchUrl();
    // 원격에서 데이터 가져오기 ...
  }
  getFetchUrl() {
    return 'http://myapi/results?query' + this.props.query;
  }
  render() {
    // ...
  }
}

아주 많은 React 컴포넌트가 이와 비슷한 형태다. 하지만 조금만 더 가까이서 보면, 우리는 버그를 발견할 수 있다. fetchResults 메소드는 데이터를 가져올 때 query prop을 사용한다.

  getFetchUrl() {
    return 'http://myapi/results?query' + this.props.query;
  }

그런데 query prop이 바뀐다면? 위의 컴포넌트에서는 아무런 일도 일어나지 않는다. 즉 우리가 작성한 컴포넌트의 사이드 이펙트가 props의 변경을 고려하지 않고 있다는 말이다. 이런 코드는 React 앱에서 발생하는 아주 흔한 버그 중 하나다.

이 컴포넌트를 고치기 위해서 해야 할 일은 다음과 같다.:

componentDidMount 안에서 호출되는 모든 메소드를 살펴본다.
- 예제에서는 fetchResults 와 getFetchUrl이다.
그 메소드들이 사용하고 있는 모든 props와 state를 정리한다.
- 예제에서는 this.props.query 하나다.
그 props들이 변경될 때마다 사이드 이펙트가 확실하게 실행되도록 만들어야 한다.
- componentDidUpdate 메소드를 추가함으로써 구현할 수 있다.

class SearchResults extends React.Component {
  state = {
    data: null
  };
  componentDidMount() {
    this.fetchResults();
  }
  componentDidUpdate(prevProps) {
    if (prevProps.query !== this.props.query) { // ✅ query가  변경되었을 때 fetchResults 실행
      this.fetchResults();
    }
  }
  fetchResults() {
    const url = this.getFetchUrl();
    // 원격에서 데이터 가져오기 ... 
  }
  getFetchUrl() {
    return 'http://myapi/results?query' + this.props.query; // ✅ 업데이트가 반영됨
  }
  render() {
    // ...
  }
}

만약 이런 실수를 자동으로 잡아줄 수 있다면 더 좋지 않을까? 린터 같은 도구가 우리를 도와줄 수 있진 있을까?

안타깝게도 클래스 컴포넌트의 일관성을 자동으로 검사하는 것은 몹시 어려운 일이다. 모든 메소드는 다른 모든 메소드 안에서 호출될 수 있다. componentDidMount 와 componentDidUpdate 에서의 함수 호출을 정적으로 분석하는 것은 잘못된 긍정(false positives)이 있어서 곤란하다.

하지만, React에 일관성을 확인하기 위해 정적으로 분석될 수 있는 API를 설계할 수 있었다. React useEffect Hook이 그런 API다.

function SearchResults({ query }) {
  const [data, setData] = useState(null);
  const [currentPage, setCurrentPage] = useState(0);

  useEffect(() => {
    function fetchResults() {
      const url = getFetchUrl();
      // 원격에서 데이터 가져오기 ... 
    }

    function getFetchUrl() {
      return (
        'http://myapi/results?query' + query +
        '&page=' + currentPage
      );
    }

    fetchResults();
  }, [currentPage, query]); // ✅ 변경되었을 때 데이터를 다시 가져오기
  // ...
}

우리는 effect 안에 로직을 넣어뒀기에, React 데이터 흐름에서 어떤 값들에 의존하고 있는지 더 쉽게 확인할 수 있다. 이 예제에서는 [currentPage, query]다.

이 “effect 의존성(dependencies)” 배열이 새로운 개념이 아니라는 사실에 유의해야 한다. 클래스에서는 함수가 호출될 때마다 매번 이 “의존성”을 확인했었다. useEffect API는 단지 같은 개념을 더 명시적으로 만들었을 뿐이다.

그리고 이 API를 사용하면 린터가 자동으로 의존성 검사를 할 수 있다.

(새로운 추천 규칙인 exhaustive-deps을 사용하는 예제다. 이 규칙은 eslint-plugin-react-hooks에 포함되어 있다. 그리고 곧 Create React App에 포함될 것이다)

당신이 컴포넌트 작성에 클래스를 사용하든 함수를 사용하든, 사이드 이펙트에는 모든 prop과 state의 변경을 고려해야 한다는 점이 중요하다는 것을 꼭 알아야 한다.

만약 클래스 API를 사용한다면 당신은 렌더링 일관성에 대해 스스로 생각해야 하며 componentDidUpdate 메소드 안에서 관련된 모든 prop또는 state의 변경을 직접 확인해야 한다. 그러지 않으면 당신의 컴포넌트는 prop과 state의 변경에 탄력적일 수 없다. 이것은 단지 React에 국한된 문제는 아니다. 컴포넌트의 “생성”과 “업데이트”를 분리해서 제어할 수 있는 모든 UI 라이브러리에 적용된다.

useEffect API는 일관성에 중심을 두고 기존의 구현을 뒤집었다. 이건 처음에는 익숙하지 않아서 어색하게 느껴질 수도 있다. 하지만 결국에는 당신의 컴포넌트가 로직 안의 데이터 변경에 더 탄력성이 있도록 만든다. 그리고 “의존성”이 이제는 명시적이기 때문에, 린터의 규칙을 사용해서 effect가 일관성이 있고 문제가 없는지 검증할 수 있다. 우리가 사용하는 린터가 버그를 찾아주는 것이다!

최적화 과정에서 데이터 흐름이 멈추게 하지 마라

의도치 않게 props의 변경을 무시하게 되는 사례가 하나 더 있다. 이것은 컴포넌트를 최적화를 직접 시도할 때 발생할 수 있다.

PureComponent와 React.memo를 사용한 얕은(shallow) 동등성(equality) 검사를 사용하는 기본적인 비교에 기반을 둔 최적화 시도는 안전하다는 사실을 기억해 두자.

하지만 만약 당신이 비교 구문을 직접 작성해서 “최적화”를 시도한다면, 함수 props의 완벽한 검사를 실수로 놓치게 될 가능성이 있다.

class Button extends React.Component {
  shouldComponentUpdate(prevProps) {
    // 🔴 this.props.onClick은 비교하지 않는다
    return this.props.color !== prevProps.color;
  }
  render() {
    const onClick = this.props.onClick; // 🔴 업데이트를 반영하지 않는다
    const textColor = slowlyCalculateTextColor(this.props.color);
    return (
      <button
        onClick={onClick}
        className={'Button-' + this.props.color + ' Button-text-' + textColor}>
        {this.props.children}
      </button>
    );
  }
}

클래스를 사용하면 이런 실수를 하기 쉽다. Button 컴포넌트에 onClick prop으로 메소드를 내려보내면, 그 메소드는 어찌 되었던 동일성(identity)을 가지게 될 것이다.

class MyForm extends React.Component {
  handleClick = () => { // ✅ 처음부터 끝까지 항상 같은 함수
    // Do something
  }
  render() {
    return (
      <>
        <h1>Hello!</h1>
        <Button color='green' onClick={this.handleClick}>
          Press me
        </Button>
      </>
    )
  }
}

우리의 최적화는 바로 망가지진 않는다. 하지만, Button 컴포넌트는 전달되는 값이 변경되더라도 오래된 onClick 값을 계속 “바라보고” 있게 될 것이다.

class MyForm extends React.Component {
  state = {
    isEnabled: true
  };
  handleClick = () => {
    this.setState({ isEnabled: false });
    // Do something
  }
  render() {
    return (
      <>
        <h1>Hello!</h1>
        <Button color='green' onClick={
          // 🔴 onClick이 null로 바뀌더라도 Button 컴포넌트는 무시한다. 
          // 🔴 shouldComponentUpdate에서 비교를 안하기 때문이다.
          this.state.isEnabled ? this.handleClick : null
        }>
          Press me
        </Button>
      </>
    )
  }
}

이 예제에서는 버튼을 한 번 클릭한 후에 버튼이 더 이상 동작하지 않아야 한다(onClick prop이 null로 바뀌어야 하므로). 하지만 버튼은 onClick prop의 모든 업데이트를 무시하기에 기대했던 대로 동작하지 않는다.

이것은 함수의 동일성이 계속해서 바뀔 수 있는 값에 의존하고 있으면 더욱 혼란스러워진다. 아래 코드의 draft.content가 그러하다.

drafts.map(draft =>
    <Button
      color='blue'
      key={draft.id}
      onClick={
        // 🔴 버튼은 onClick props의 업데이트를 무시한다
        this.handlePublish.bind(this, draft.content)
      }>
      Publish
    </Button>
  )

draft.content는 값이 계속 바뀔 가능성이 있지만, 우리의 Button 컴포넌트는 onClick prop의 변화를 무시하게 되어 있어서 최초의 draft.content가 바인딩된 “첫번째 버전”의 onClick 메소드를 계속 바라보게 된다.

그러면, 어떻게 하면 이 문제를 피할 수 있을까?

나는 shouldComponentUpdate 메소드를 직접 작성하지 않는 것을 권장하고 싶으며, React.memo에 커스텀 비교 구문을 전달하는 것도 피하라고 하고 싶다. React.memo에 구현된 비교는 함수 동일성(identity)의 변화를 감지할 수 있다.

function Button({ onClick, color, children }) {
  const textColor = slowlyCalculateTextColor(this.props.color);
  return (
    <button
      onClick={onClick}
      className={'Button-' + color + ' Button-text-' + textColor}>
      {children}
    </button>
  );
}
export default React.memo(Button); // ✅ 얕은(shallow) 비교를 사용한다

클래스에서는, PureComponent가 같은 역할을 한다.

이는 다른 함수를 prop으로 보내면 항상 업데이트가 반영됨을 보장한다.

만약 당신이 커스텀 비교를 하고 싶다면, 함수를 빠뜨리지 않도록 확실하게 구현해야 한다.

  shouldComponentUpdate(prevProps) {
    // ✅ this.props.onClick을 비교한다
    return (
      this.props.color !== prevProps.color ||
      this.props.onClick !== prevProps.onClick
    );
  }

앞서 언급한 것처럼, 클래스 컴포넌트에서는 이 문제를 놓치기 쉽다. 왜냐하면, 메소드의 동일성은 보통 안정적이기 때문이다(하지만 항상 그렇지는 않다 - 그렇기에 이 문제로 인한 버그는 고치기 어렵다). Hooks를 사용한다면, 얘기는 조금 다르다.

함수를 렌더링 할 때마다 달라지기 때문에 이 문제를 바로 찾아낼 수 있다
useCallback과 useContext를 사용하면, 함수를 컴포넌트 트리 깊은 곳에 전달하는 문제를 전부 해결할 수 있다.

이 섹션을 한마디로 요약한다면, 데이터 흐름을 멈추지 마라!라고 할 수 있겠다.

props와 state를 사용할 때마다, 그 값들이 바뀌면 어떤 일이 일어나야 하는지 생각해보자. 거의 모든 사례에서 컴포넌트는 최초의 렌더링에 머무르지 말고 계속 업데이트되어야 한다. 그것이 로직의 변화에 탄력을 준다.

클래스를 사용하면 라이프사이클 메소드 안에서 props와 state를 사용할 때 업데이트에 대해 잊어버리기 쉽다. Hooks는 당신이 제대로 된 방법을 사용할 수 있도록 유도해준다. 하지만 지금 사용하고 있지 않다면, 컴포넌트를 사고하는 방식의 조정 기간이 조금 필요하다.

원칙 2: 언제라도 렌더링할 준비가 되어 있게 하라.

React를 사용하면 컴포넌트 렌더링에 걸리는 시간은 크게 신경 쓰지 않고 코드를 작성할 수 있다. 당신은 컴포넌트가 어떤 시점에 어떻게 보일지 묘사해야 하며, React는 그것이 가능하게 한다. 이 모델의 장점을 최대한 활용하자!

컴포넌트가 어떤 타이밍에 어떻게 동작할지 추측을 하지 말아야 한다. 당신이 작성한 컴포넌트는 어떤 순간에도 다시 렌더링(re-render)될 준비가 되어 있어야 한다.

이 원칙을 어떻게 어기게 될까? React는 쉽게 어길 수 없게 하지만 – 만약 레거시 라이프사이클 메소드 componentWillReceiveProps를 사용한다면 그럴 수 있다.

class TextInput extends React.Component {
  state = {
    value: ``
  };
  // 🔴 부모 컴포넌트로부터 props를 받을 때마다 로컬 state `value`를 재설정한다 
  componentWillReceiveProps(nextProps) {
    this.setState({ value: nextProps.value });
  }
  handleChange = (e) => {
    this.setState({ value: e.target.value });
  };
  render() {
    return (
      <input
        value={this.state.value}
        onChange={this.handleChange}
      />
    );
  }
}

이 예제에서 우리는 value를 로컬 state에 보관한다. 그런데 value를 props를 통해 받기도 한다. “새로운 값을 받을 때마다” 컴포넌트는 value를 state에 재설정한다.

이 패턴의 문제는 업데이트를 완전히 제어할 수 없는 타이밍에 의존하고 있다는 점이다.

오늘은 이 컴포넌트의 부모가 업데이트를 거의 안할 수도 있어서 TextInput 컴포넌트가 어떤 중요한 상황에서만 props를 전달받을 수도 있다. 예를 들면 폼 데이터를 저장하는 것과 같은 상황에서 말이다.

하지만 내일은 TextInput의 부모 컴포넌트에 어떤 애니메이션 효과를 추가할 수도 있다. 만약 그 부모 컴포넌트가 더 자주 렌더링을 한다면 계속해서 자식 컴포넌트의 state를 “날려버리게” 될 것이다!³ 이 문제에 대해서는 “당신은 아마 Derived State가 필요없을 것이다”에서 더 자세하게 읽어볼 수 있다.

그러면 어떻게 이 문제를 고칠 수 있을까?

무엇보다도, 우리는 머릿속의 디자인 모델을 바로잡아야 한다. “props를 전달받는 것”을 “렌더링”과 다른 별개의 이벤트라고 생각하는 걸 그만둬야 한다. 부모 컴포넌트의 리렌더링에 의해 일어나는 자식 컴포넌트의 리렌더링은 자식 컴포넌트가 가진 로컬 state의 업데이트로 발생하는 리렌더링과 다르게 동작해서는 안 된다. 컴포넌트는 많고 적을 수 있는 렌더링 횟수에 탄력적이어야 한다. 그렇지 않으면 그 컴포넌트는 특정 부모 컴포넌트에 너무 강하게 연결된 것이기 때문이다.⁴

(이 데모는 부모의 리렌더링이 어떻게 자식 컴포넌트의 state를 망가뜨리는지 보여준다.)

당신이 정말로 props를 통해 생성된 state(derived state)의 사용이 필요할 때 쓸 수 있는 다른 솔루션들이 있긴 하지만, 보통은 부모 컴포넌트가 완전히 제어하는 컴포넌트(controlled component)를 사용해야 한다.

// 옵션 1: 로컬 state가 없는 완전히 제어되는 컴포넌트. 
function TextInput({ value, onChange }) {
  return (
    <input
      value={value}
      onChange={onChange}
    />
  );
}

아니면 제어되지 않는 컴포넌트(uncontrolled component)를 사용하면서 부모에서 필요할 때 자식 컴포넌트를 렌더링할 수 있도록 키를 부여할 수도 있다.

// 옵션 2: 로컬 state를 가진 제어되지 않는 컴포넌트
function TextInput() {
  const [value, setValue] = useState('');
  return (
    <input
      value={value}
      onChange={e => setValue(e.target.value)}
    />
  );
}

// key 값을 바꿈으로써 내부 state를 리셋할 수 있다.
<TextInput key={formId} />

이 섹션의 요점은 당신의 컴포넌트가 상태가 부모 컴포넌트가 더 자주 리렌더링 된다고 해도 망가지지 않아야 한다는 것이다. React API 디자인은 레거시 componentWillReceiveProps 라이프사이클 메소드를 사용하지 않는다면 그것을 매우 쉽게 구현할 수 있도록 해 두었다.

컴포넌트 스트레스 테스트를 위해서는 임의로 아래의 코드를 부모 컴포넌트에 추가해볼 수 있다.

componentDidMount() {
  // 테스트 후에는 바로 제거해야 한다!
  setInterval(() => this.forceUpdate(), 100);
}

테스트를 위한 것이므로 이 코드를 남겨둬서는 안 된다. 이 코드를 부모 컴포넌트가 예상한 것보다 자주 렌더링이 일어날 때 어떤 일이 발생하는지 확인할 수 있는 빠른 방법이다. 저렇게 해도 자식 컴포넌트를 망가뜨려선 안 된다!

당신은 이렇게 생각할 수도 있다: “나는 props가 변경될 때 state를 계속 다시 설정할 것이다. 하지만 불필요한 리렌더링은 PureComponent를 사용해서 피할 것이다.”

그렇다면 아래의 코드는 제대로 동작해야 한다. 맞을까?

// 🤔 불필요한 리렌더링을 방지해야 하는데... 그렇게 될까?
class TextInput extends React.PureComponent {
  state = {
    value: ''
  };
  // 🔴 부모 컴포넌트가 렌더링 할때마다 state를 설정한다
  componentWillReceiveProps(nextProps) {
    this.setState({ value: nextProps.value });
  }
  handleChange = (e) => {
    this.setState({ value: e.target.value });
  };
  render() {
    return (
      <input
        value={this.state.value}
        onChange={this.handleChange}
      />
    );
  }
}

처음에는 부모 컴포넌트의 리렌더링이 state를 “날려버리는” 문제를 해결할 것처럼 보일 수 있다. 어쨌든, props가 같다면 업데이트를 건너뛴다 – 그리고 componentWillReceiveProps도 호출되지 않는다.

하지만 이는 우리에게 보안에 관한 잘못된 인상을 부여한다. 이 컴포넌트는 여전히 prop의 변경에 탄력적이지 않다. 예를 들어, 만약 컴포넌트에 자주 변경되는 또 다른 값(애니메이션이 적용된 스타일 같은 것)을 prop으로 전달한다면, 컴포넌트의 로컬 state를 여전히 “잃어버리게” 될 것이다.

<TextInput
  style={{opacity: someValueFromState}}
  value={
    // 🔴 TextInput 컴포넌트의 componentWillReceiveProps는
    // style이 바뀔 때마다 value를 재설정하게 될 것이다.
    value
  }
/>

그러므로 이 접근법에도 문제가 있다. PureComponent, shouldComponentUpdate, and React.memo같은 다양한 최적화 방법을 컴포넌트의 반응을 제어하는 데 사용해서는 안 된다. 대신 최적화에 도움이 될 때만 사용해야 한다. 최적화를 제거했다고 컴포넌트가 제대로 동작하지 않는다면, 그건 애초에 쓰기도 어려운 것이다.

이 해결책은 우리가 앞서 살펴본 것과 같다. “props를 받는 것”을 특별한 일로 여기지 말아야 한다. props와 state의 “동기화”를 하지 말자. 대부분은 모든 값은 완전히 제어되거나(props를 통해서만 업데이트) 그 반대여야 한다(로컬 state만 사용). 그리고 할 수만 있다면 파생된 state(derived state)의 사용은 피해야 한다. 그리고 언제나 렌더링할 준비를 해두자!

원칙 3: 싱글턴인 컴포넌트는 없다.

가끔 우리는 어떤 컴포넌트가 딱 한 번만 표시된다고 생각된다. 예를 들면 내비게이션 바 같은 것이다. 어떤 경우에는 맞는 말일 수 있다. 하지만 이 가정은 한참 후에야 마주치게 되는 디자인 문제를 종종 일으킨다.

예를 들어, 라우트가 변경될 때 2개의 Page 컴포넌트 – 이전 Page와 다음 Page – 사이에 전환 효과를 주는 애니메이션을 구현할 필요가 생겼다고 가정해보자. 두 페이지 모두 애니메이션이 진행될 때 마운팅 된 상태여야 한다. 하지만 당신은 각각의 컴포넌트가 화면에 마운팅되는 오직 1개의 Page 컴포넌트로 생각하고 만들어졌다는 사실을 뒤늦게 발견하게 된다.

이 문제를 확인하는 방법은 매우 간단하다. 재미삼아 당신의 앱을 동시에 2개 렌더링해 보자.

ReactDOM.render(
  <>
    // 앱의 루트 컴포넌트를 2번 렌더링
    <MyApp /> 
    <MyApp />
  </>,
  document.getElementById(`root`)
);

여기저기 클릭해보자. (아마 이 실험을 위해서 CSS를 조금 조작해야 할 수도 있다)

당신의 앱이 여전히 기대했던 대로 동작하는가? 아니면 이상하게 깨지거나 오류 메시지가 발생하는가? 복잡한 컴포넌트에 이런 스트레스 테스트를 한 번씩 해보는 것은 좋은 아이디어다. 그리고 같은 컴포넌트를 여러 개 동시에 렌더링해도 서로에게 영향을 미치지 말아야 한다.

내가 직접 작성했던 컴포넌트에서 가끔 문제가 되었던 패턴은 componentWillUnmount에서 전역 state를 “초기화” 시키는 것이었다.

componentWillUnmount() {
  // Redux 스토어에 있는 어떤 값을 초기화
  this.props.resetForm();
}

당연하겠지만 페이지에 저런 컴포넌트가 2개 있는 상태에서 하나를 없애면 다른 하나에 문제를 일으키게 된다. “전역” state를 컴포넌트 마운팅 시점에 초기화하는 것도 마찬가지다.

componentDidMount() {
  // Redux 스토어에 있는 어떤 값을 초기화
  this.props.resetForm();
}

두 번째로 마운팅되는 컴포넌트가 첫번째 컴포넌트가 사용하고 있던 Redux 스토어의 값을 초기화시켜버리게 될 것이다(입력된 폼 데이터를 날려버린다든지).

이러한 패턴들은 우리가 작성한 컴포넌트가 오류가 발생하기 쉬운지 아닌지를 판단할 수 있는 좋은 지표가 된다. 컴포넌트 트리를 보여주고 숨기는 과정이 다른 트리에 있는 컴포넌트를 망가뜨려서는 안 된다.

컴포넌트를 두 번 렌더링할 계획이 있든 없든, 이런 문제를 해결하는 것은 장기적으로 이득이 된다. 그리고 당신을 더욱 탄력적인 컴포넌트 디자인으로 이끌어줄 것이다.

원칙 4: 로컬 State를 독립된 상태로 유지하라

소셜 미디어의 Post 컴포넌트를 생각해보자. 그것은 Comment 스레드(확장될 수 있는)를 가지고 있으며 NewComment 입력을 가지고 있다.

React 컴포넌트는 로컬 state를 가질 수 있다. 하지만 어떤 state가 정말로 ‘로컬’이라고 할 수 있는가? 포스트 콘텐츠 자체는 로컬인가 아닌가? 코멘트 목록은? 어떤 코멘트의 스레드가 열려 있었는지에 관한 기록은? 코멘트 입력은?

당신이 만약 모든 것을 “상태 관리자”⁵에 집어넣는 일에 익숙하다면 다소 대답하기 어려운 질문이 될 수 있다. 여기에 경계를 나누기 위한 간단한 방법이 있다.

만약 어떤 state가 로컬이어야 하는지 아닌지 확실치 않다면, 이렇게 자문해보라: “만약 이 컴포넌트가 두 번 렌더링된다면, 이런 값들의 변경이 다른 카피에 반영되어야 하는가?” 대답이 “아니다”라면 로컬 state가 맞다.

예를 들며, 어떤 Post 컴포넌트를 두 번 렌더링했다고 가정하자. 그리고 이 컴포넌트 안에서 바뀔 수 있는 값들을 생각해보자.

포스트 내용. 포스트를 수정한 후에 다른 위치에 있는 컴포넌트에서 업데이트하고 싶을 수 있다. 그러므로 수정된 포스트 내용은 아마도 Post 컴포넌트의 로컬 state에 있어서는 안될 것이다.(그러는 대신, 포스트 내용은 Apollo, Relay, 또는 Redux같은 저장소에서 유지될 것이다)
코멘트 목록. 이것은 포스트 컨텐츠와 비슷하다. 코멘트를 추가하면 다른 곳에도 반영되어야 한다. 그래서 이상적으로는 코멘트 목록을 위한 저장소를 사용해야 할 것이고 Post 컴포넌트의 로컬 state에 있어서는 안된다.
어떤 코멘트 스레드가 확장되어 있는지. 어떤 코멘트의 스레드를 클릭해서 열었는데 다른 곳에서도 열린다면 뭔가 잘못된 것처럼 보일 것이다. 이 경우에서 우리는 추상적인 “코멘트 개체”를 다루는 것이 아니라 특정 Comment UI를 조작하고 있다고 봐야 한다. 그러므로 “열림” 플래그는 Comment 컴포넌트의 로컬 state에 있어야 한다.
새로운 코멘트 입력값. 코멘트를 입력하고 있는데 다른 코멘트 입력창에 추가된다면 역시 이상하게 보일 것이다. 복수의 입력창이 명확하게 같은 값이라고 라벨이 붙어있지 않다면, 사람들은 보통 각각의 입력을 독립된 값으로 여긴다. 그러므로 입력값은 NewComment 컴포넌트의 로컬 state에 있어야 한다.

나는 지금 제안하고 있는 이 규칙들을 무조건 지켜야 한다고 말하는 것이 아니다. 물론, 간단한 앱에서 당신은 저 “저장소”를 포함한 모든 것을 로컬 state에서 관리하고 싶을 수도 있다. 나는 단지 첫번째 원칙 에 있는 이상적인 사용자 경험에 관해서 이야기하고 있을 뿐이다.

확실히 로컬한 state를 전역 값으로 만드는 것은 피해라. 이것은 우리가 얘기하고 있는 “탄력성” 구현에 도움을 준다: 컴포넌트 사이의 놀라운 동기화는 많이 없다. 보너스로, 이것은 또 아주 넓은 범주의 성능 이슈를 해결하기도 한다. “과다 렌더링”은 당신의 state가 알맞은 위치에 있다면 그렇게 큰 이슈가 되지 않는다.

정리

지금까지 얘기한 원칙들을 정리하자면:

데이터 흐름을 멈추지 마라. Props와 state는 바뀔 수 있다. 그리고 컴포넌트는 그 변화를 계속해서 처리할 수 있어야 한다.
언제라도 렌더링할 준비가 되어 있게 하라. 컴포넌트는 렌더링 빈도에 상관없이 제대로 동작해야 한다.
싱글턴인 컴포넌트는 없다. 컴포넌트가 한 번만 렌더링 된다 하더라도, 두 번 렌더링 되었을 때 문제가 없게 한다면 당신의 디자인은 더 좋아질 것이다.
로컬 state를 독립된 상태로 유지하라. 각각의 UI에 어떤 state가 로컬이어야 할지 생각해보라 – 그리고 필요 이상으로 state를 높은 곳으로 끌어올리지 마라.

이 원칙들은 변화에 최적화된 컴포넌트를 작성하는 데 도움을 준다. 그런 컴포넌트는 컴포넌트 트리에 추가하기 쉽고, 바꾸기 쉽고, 삭제하기 쉽다.

그리고 가장 중요한 점으로, 작성하는 컴포넌트가 탄력적이게 되면, props가 알파벳 순으로 정렬되어야 하는지 아닌지를 고민하는 것과 같은 어려운 딜레마로 돌아갈 수 있다.

린터(linter) 또는 린트(lint). 소스 코드를 분석하여 프로그램 오류, 버그, 스타일 오류에 표지(flag)를 달아놓기 위한 도구. 자바스크립트 린터에는 eslint, tslint가 있다
↩
computed values. 이미 존재하는 값으로부터 유래된 값. React 컴포넌트에서 어떤 계산된 값을 state를 사용해서 만들었다면, state가 업데이트 되면 그 계산된 값도 업데이트를 반영한다.
↩
사용자가 직접 입력한 값을 this.state.value에 업데이트하고 있다. 그런데 부모 컴포넌트로부터 새로운 value 값이나 다른 prop이 전달된다면 사용자가 지금까지 입력했던 값은 날아가버리게 될 것이다.
↩
특정 컴포넌트가 부모일 때만 제대로 동작한다면 재사용성이 떨어질 것이다.
↩
Redux, Mobx, etc
↩

UMD(Universal Module Definition) 패턴

rhostem — Sun, 23 Jun 2019 00:00:00 GMT

모듈이란 1개 이상의 값(객체, 함수, 변수 등)을 내보내는 자바스크립트 파일을 말한다. 모던 웹 개발에서는 자바스크립트가 차지하는 비중이 무척 높아졌기 때문에 모듈을 통한 기능과 관심사의 분리는 필수적이다. 자바스크립트 모듈 선언 포맷에는 AMD와 CommonJS 가 있다.

AMD

AMD(Asynchronous Module Definition)는 코드 모듈을 선언하면서 그것이 의존하고 있는 모듈도 함께 명시한다. 그리고 필요에 따라 비동기적으로 의존 모듈을 불러온다. AMD는 아래와 같은 형식으로 모듈을 선언한다.

define(['jquery'], function ($) { // 의존 모듈로 jQuery를 선언
	// 함수 선언	
	function withjQuery(){};
	
  // 외부에 함수를 노출시켜 사용할 수 있도록 한다.
  return withjQuery; 
});

AMD를 사용하면 실행할 코드가 필요한 파일만 가져오기 때문에 성능 향상을 기대할 수 있다. 그리고 의존하고 있는 모듈을 확실히 가져온 다음에 코드를 실행할 수 있기 때문에 오류도 줄어든다. AMD 포맷을 구현한 대표적인 라이브러리에는 Require.js, Dojo Toolkit 등이 있다.

CommonJS

CommonJS는 웹 브라우저가 아닌 환경에서의 자바스크립트 모듈 포맷을 확립하기 위한 프로젝트다. 이 프로젝트가 시작된 가장 큰 이유는 서로 다른 개발 환경(웹 서버, 네이티브 데스크탑 앱 등)에서 만들어진 자바스크립트 코드를 공유하기 위한 포맷이 없었기 때문이었다. 2009년 ServerJS라는 이름의 프로젝트로 시작되었고 이후 CommonJS로 이름이 바뀌게 된다. 자바스크립트의 표준이 되는 ECMAScript를 정의하는 ECMA 국제 그룹 TC39와 직접적인 관계는 없지만, TC39의 멤버 중 일부는 CommonJS 프로젝트에 참여하기도 했다.

CommonJS 포맷은 Node.js에서 구현해 뒀기 때문에 AMD보다 접해본 사람이 더 많을 것이다. 앞서 작성한 withJquery 모듈을 CommonJS 형식으로 작성하면 아래와 같다.

// 의존 모듈 선언 
var $ = require('jquery');

// 함수 선언	
function withjQuery(){};

// 외부에 함수를 노출시킨다.
module.exports = withjQuery;

UMD

앞에서 제시한 예제 코드를 통해 AMD와 CommonJS 포맷 모두 ‘의존 모듈을 정의하고 새로운 모듈을 내보낸다’는 같은 목적을 가지고 있다는 것을 알 수 있다. 다만 그 방식이 다를 뿐이다.

그런데 자바스크립트로 개발을 하다 보면 두 방식을 모두 지원해야 하는 상황이 생긴다. 대표적으로 오픈소스 라이브러리 모듈은 다양한 환경을 지원해야 할 필요가 있을 것이다. 그럴 때는 UMD(Universal Module Definition)를 사용해서 모듈을 선언할 수 있다.

UMD는 CommonJS처럼 스펙이 아닌 코드 작성 패턴이라고 보면 되며, 다양한 패턴이 존재한다. 아래의 패턴은 모듈을 AMD, CommonJS, 또는 브라우저 전역 변수로 할당해서 사용할 수 있도록 하는 returnExports.js 패턴이다.

// 모듈 선언을 위해 IIFE 패턴을 사용하고 있다.
// 이 예제에서는 의존 모듈을 표현하기 위해 임의로 모듈 'b'를 사용한다
// root 파라미터는 실행 환경에 따라 브라우저의 window 또는 node.js의 global을 가리킨다.
// factory 파라미터는 모듈 코드를 감싸고 있는 함수를 가리킨다.
(function (root, factory) {
	
 	// AMD에서 사용하는 define 함수를 사용할 수 있는지 확인한다.
  if (typeof define === 'function' && define.amd) {
    // AMD 포맷에 따라 모듈을 선언한다. 의존 모듈은 b가 된다.
    define(['b'], factory);
    
    // 의존 모듈이 없다면 아래와 같이 작성한다
    // define([], factory);
    
	// AMD를 지원하지 않는다면 CommonJS 모듈을 사용할 수 있는지 확인한다.
  } else if (typeof module === 'object' && module.exports) {
		// CommonJS 포맷에 따라 모듈을 선언한다. 
		// 의존 모듈을 factory 함수의 파라미터로 전달해준다.
    module.exports = factory(require('b'));
    
    // 의존 모듈이 없다면 아래와 같이 작성한다
    // module.exports = factory();
  } else {
    // AMD도 CommonJS도 아니라면 브라우저라고 판단한다.
    // 여기서 root는 window가 된다. returnExports는 전역에서 모듈의 이름이다.
    root.returnExports = factory(root.b);
    
    // 의존 모듈이 없다면 아래와 같이 작성한다
    // root.returnExports = factory();
  }
  
// 함수를 즉시 실행한다. 
// 첫번째 파라미터는 전역 변수. 
// (여기서는 Web Worker 지원을 위해 self 변수를 확인하지만 그럴 필요가 없다면 this만 전달해도 된다)
// 두번째 파라미터는 factory에 해당한다.
}(typeof self !== 'undefined' ? self : this, function (b) { // 의존 모듈 b
	// return하는 값이 이 모듈이 내보내는 값이 된다(이 예제에서는 객체).
  return {};
}));

코멘트를 제거하고 정리한 간략한 버전은 아래와 같다.

아래의 샘플은 현재 실행 환경을 확인하기위해 NODE_ENV 환경변수가 development 라면 true, 아니면 false를 반환하는 기능을 한다.

(function(root, factory) {
  if (typeof define === 'function' && define.amd) {
    // AMD
    define([], factory);
  } else if (typeof module === 'object' && module.exports) {
    // CommonJS
    module.exports = factory();
  } else {
    // browser
    root.isDev = factory();
  }
})(this, function() {
  return process.env.NODE_ENV === 'development';
});

Github umdjs/umd 저장소에는 이 외에도 몇가지 패턴들을 더 제공하고 있으니 필요한 패턴을 참조해서 사용하면 될 것이다. 그리고 소스 파일을 UMD 패턴으로 변환시켜주는 도구(ex. gulp-umd)도 존재한다.

Gatsby + Contentful + CircleCI로 블로그 마이그레이션

rhostem — Sat, 12 Jan 2019 00:00:00 GMT

자동 빌드가 안되는 현재의 블로그

블로그는 Gatsby로 만들었고 콘텐츠는 소스 폴더와 함께 git 저장소에 포함되어 있었다. 배포를 위해서는 로컬에서 직접 빌드를 한 후 서버에 업로드하는 방식을 사용했다.

하지만 콘텐츠가 소스에 포함되어 있으니 사소한 오타 수정도 커밋 로그에 남겨야 하고, 터미널을 띄워서 배포 명령어를 직접 입력해야 한다. 자동화가 전혀 되어있지 않는 데다 아무리 텍스트 에디터가 마크다운 문법을 잘 지원한다 하더라도 콘텐츠 관리 측면에서 좋은 점수를 줄 수 없었다.

그래서 이번 기회에 콘텐츠도 소스에서 분리해서 CMS로 따리 관리하고, 코드 커밋과 콘텐츠 업데이트 시점에 사이트를 자동으로 재배포되도록 블로그 시스템을 업그레이드하기로 했다.

웹사이트 개발/관리 도구

시스템 마이그레이션을 위해서는 도구가 필요하다.

정적 웹사이트 프레임워크
콘텐츠 관리 시스템
CI/CD 도구
웹 서버

정적 웹사이트 프레임워크

사용하고 있던 Gatsby를 그대로 사용하기로 했다. 프레임워크의 메이저 버전이 v2로 올라간지 몇달이 지난 상태였기에 이번 참에 함께 업데이트 하기로 했다. v2로 올려야 React 16, Babel 7, Webpack 4를 사용할 수 있고 빌드 시간 단축, 번들 사이즈 감소 등의 혜택을 누릴 수 있다. 하지만 긴 마이그레이션 가이드 문서가 보여주듯 플러그인 버전도 모두 변경해야 하고 수정된 스펙도 제법 있다. 그래서 시간은 제법 걸리겠지만, 최대 2년이 넘은 기존 코드도 리뷰도 할 겸 Gatsby v2로 새 프로젝트를 만든 후 기존 코드를 옮기는 방식을 사용하기로 했다.

콘텐츠 관리 시스템(CMS)

유명한 CMS로는 Wordpress가 있다. CMS를 사용하면 웹사이트를 쉽게 만들고 배포할 수 있지만 ‘사용하기 편리하다 == 커스터마이징이 어렵다’는 공식이 성립하기 때문에 마음대로 만들고 싶은 나 같은 개발자에게는 별로 선호되는 도구는 아니다. 그럴 바에는 더 편하게 블로그 전용 웹서비스를 사용하는 편이 낫지 않을까 하는 생각을 하고 있다.

그래서 Gatsby 같은 도구와 사용하기에는 Wordpress처럼 프론트엔드 레이어까지 제공하는 것이 아니라 데이터의 관리만 제공하는 Headless CMS가 적합하다. 그리고 Gatsby는 플러그인을 통해 다양한 CMS에서 콘텐츠를 가져올 수 있도록 도와준다. 오픈 소스 CMS인 Drupal을 포함해서 Wordpress, Contentful, ButterCMS 같은 CMS는 물론 MongoDB, MySQL같은 데이터베이스, 그리고 서드 파티 API를 통해서도 콘텐츠를 가져올 수 있다.

Gatsby에서 플러그인을 제공하는 몇 가지 CMS를 둘러본 후 Contentful을 사용하기로 했다. 무료 플랜은 콘텐츠와 미디어를 합해서 5000개까지 업로드할 수 있다. 지난 근 2년간 작성한 글의 수와 이미지의 수를 합치면 200개가 되지 않으니 개인 블로그로 사용하기에는 충분해 보였다. 인터페이스도 깔끔하며 웹훅 설정 등도 간편하게 제공하는 등 다양한 기능이 잘 준비되어 있다. 다만 해외 서비스라서 웹사이트 속도는 조금 느린 편이다. 관리 도구에서 콘텐츠를 불러올 때 0.5초~1.5초 정도 걸려서 국내 웹사이트와 비교하면 상대적으로 느리게 느껴질 수 있다. 하지만 실제 배포된 웹사이트는 콘텐츠를 모두 포함하고 있으니 CMS API 호출 속도는 큰 문제가 되지 않는다.

CI/CD 도구

웹사이트는 아래 상황에서 자동 배포가 되어야 한다.

master 브랜치에 커밋이 푸시되었을 때
콘텐츠가 생성, 수정, 삭제되었을 때

자동 빌드 도구는 CircleCI를 사용하기로 했다. 다른 사이드 프로젝트를 하면서 사용해 봤는데 무료 플랜의 빌드 성능도 괜찮고 1달에 1000분까지의 빌드 시간을 제공하므로 역시 개인이 사용하기에는 문제가 없을 것이다.

CircleCI는 Github 계정으로 로그인 후 사용할 저장소를 선택하면 기본적인 웹훅¹ 설정은 자동으로 해준다. 사용자는 설정 파일에 원하는 명령어를 추가하면 된다. CircleCI 설정 파일에 배포 프로세스를 추가하면 1번의 조건은 만족하게 된다.

그리고 2번을 만족하기 위해서는 CMS인 Contentful에서 웹훅 설정을 해야 한다. Contenful은 고맙게도 웹훅을 위한 전용 메뉴까지 제공하며 다양한 서비스를 위한 템플릿도 제공한다. CircleCI는 물론 Netlify, Heroku, TravisCI, Gitlab 등의 서비스를 쉽게 사용할 수 있다.

Contentful에서 CircleCI에 설정된 빌드를 실행하기 위해서는 웹훅 템플릿을 선택한 후 Git 저장소 이름, 서비스 접속 키 등 꼭 필요한 정보만 입력하면 된다. 이렇게 하면 콘텐츠 업데이트 시 웹사이트 자동 배포가 가능하다.

웹 서버

처음에는 Github Pages를 사용하다가 지금은 AWS Lightsail의 우분투 인스턴스에 nginx 웹 서버를 설치해서 배포하고 있다. 이번 마이그레이션 과정에서 Netlify로 옮기는 것도 고려하고 있어서 테스트해 봤는데, 엄청나게 간편해서 놀랬다. Github 저장소를 선택한 후 브랜치, 빌드 스크립트, Public 폴더, 빌드에 필요한 환경 변수 등만 저장하면 끝이다. CircleCI 처럼 docker 기반의 빌드 도구를 가지고 있어서 사용자가 별도로 할 일은 없다.

Netlify의 간단함에 배포가 되는 순간 옮길까? 라는 마음이 들긴 했지만 AWS보다는 역시 느린 속도²가 조금 걸렸다. 그리고 CircleCI에서 빌드 프로세스를 모두 관리하고 싶어서 CircleCI에서 AWS의 nginx 웹 서버에 직접 배포하는 방식을 사용하기로 했다.

정리

이렇게 웹 서버까지 시스템 마이그레이션 위한 도구가 모두 정해졌다.

정적 웹사이트 빌드 도구: Gatsby
콘텐츠 관리 시스템: Contentful
CI/CD 도구: CircleCI
웹 서버: nginx

현재 이 블로그는 위의 도구들을 사용한 마이그레이션이 완료된 상태다. 비용은 AWS Lightsail 인스턴스에 들어가는 월 5천원 정도가 된다. Netlify나 Google Firebase 호스팅 등의 서비스를 사용한다면 그 비용도 0이 된다.

Contentful에서 글을 작성한 후 ‘published’ 상태로 전환만 하면 사이트가 다시 빌드되어서 배포되니 무척 편리하다. Gatsby에서 Contentful의 소스를 가져와서 콘텐츠별로 페이지를 만들기, CircleCI 설정 등 마이그레이션에 대한 자세한 내용은 다른 글에서 다룰 예정이다.

webhook, 제 3자가 웹서비스의 콘텐츠를 수정할 수 있도록 하는 것. 오픈 API를 호출해서 채팅방에 알림을 보내거나, 서버에서 빌드를 실행시키거나 하는 작업이 가능하다
↩
1.5MB 정도 되는 페이지의 최초 로드 시간이 1~2초정도 차이가 난다. 웹 폰트처럼 용량이 큰 파일은 CDN을 사용하지 않는다면 더 큰 차이가 난다.
↩

[번역] 개발자를 위한 면접 지침

rhostem — Sat, 05 Jan 2019 00:00:00 GMT

이 글은 A developer’s guide to interviewing의 번역입니다. 기본적으로 구직자로서 면접관을 대상으로 할 수 있는 질문들을 정리한 글입니다. 글쓴이가 거주하고 있는 것으로 보이는 미국과 한국의 기업 환경에는 차이가 있기에 조심스럽게 해야 할 질문도 있겠습니다. 하지만 경력이 쌓이면 자연스럽게 면접관의 역할을 하게 될 것이므로 개발자로서, 관리자로서, 그리고 경영진으로서 가져야 할 업무 능력, 지식, 가치관에 대한 조언이라 생각하고 읽어도 좋을 것 같습니다.

구직을 위해 면접을 본 적이 있다면, 면접관으로부터 테이블 너머에서 “더 궁금한 것이 있으신가요?”라는 질문을 받은 적이 있을 것이다. 당신이 만약 “음, 아니오. 없습니다”라고 대답했다면 면접은 단방향이라는 관점을 가지고 있을 가능성이 크다.

구직자로서의 당신은 결과를 만드는 일에 집중하는 것이 당연하다. 하지만 면접은 단방향이 아니다. 회사가 당신을 면접하는 일에 집중하는 것처럼 당신도 회사를 면접하는 일에 집중해야 한다.

그런데 무슨 질문을 해야 하나?

이직을 준비하는 많은 개발자는 나에게 이 질문을 한다. 나는 지난 15년간 7개의 회사에서 일했고(2번의 인턴쉽과 스타트업에서의 6개월 포함) 그동안 많은 사람과 면접을 진행했다. 그리고 다른 이들에게 도움이 되길 바라는 마음에 지금까지 면접에서 했던 질문들을 정리하기로 했다.

나는 이 글이 계속 업데이트되길 바란다. 만약 당신이 제안하고 싶은 내용이 있다면 트위터를 통해 알려주길 바란다. 모두에게 도움이 되기 위해 기꺼이 함께할 것이다.

누구와 얘기를 하게 될까?

면접을 보는 동안 만나게 되는 사람들의 역할은 보통 세 종류로 나뉜다. 회사의 규모에 따라 한 사람이 세 가지 역할을 모두 할 수도 있고, 많은 사람이 그 역할을 나눠 맡을 수도 있다.

개발자
관리자 (기술 책임, 중간 관리자, 기술 감독)
경영진 (VP, CTO, CEO, 부서장)

나는 저들에게 할 수 있는 서로 다른 질문이 있으며, 이 글에서 하나씩 언급할 것이다. 그리고 답변들을 비교하기 위해 때로는 서로 다른 대상에게 같은 질문을 하기도 한다는 사실을 알고 있었으면 한다.

이 글은 제법 길다. 쭉 읽어낼 수 있는 글이라기보다는 참고서에 가깝다. 만약 내가 오늘 면접이 있다면 이 글을 가져가서 조심스럽게 면접을 진행하는 동안 (조심스럽게) 참조할 것이다.

질문 대부분은 “옳고” “그른” 대답이 없다. 질문들은 당신이 회사의 문화, 업무 프로세스, 그리고 조직에 대해 파악할 수 있도록 도와줄 것이다. 그리고 면접을 보는 동안 당신의 머리가 멍해졌을 때 대화를 이어나가기 위한 도구로서도 요긴하게 쓰일 수 있다.

예를 들어, 나는 면접을 시작할 때 면접관들에게 몇 가지 질문을 해도 되느냐고 물어보곤 한다. 이는 면접관들이 일정에 맞게 면접을 진행하는 데 도움을 줄 것이다. 보통은 면접이 끝날 때 질문을 할 기회를 주기 때문에 질문을 하고 싶다는 당신의 의도를 면접관들에게 일찍 전달해야 한다. 하나의 질문이 끝나고 나면 멈춘 후 다른 질문을 계속해도 되는지, 그들이 시간을 얼마나 더 가졌는지 물어봐야 한다.

개발자를 위한 질문

1. 오늘 해야 할 일을 어떻게 파악하십니까?

이 질문의 목적은 업무 프로세스가 제대로 구축되어 있는지 확인하기 위한 것이다. 나는 2~3명의 개발자에게 질문의 답변을 들었으면 한다. 운영진들이 특정 프로세스를 따른다고 말하더라도 개발자들이 아무런 얘기를 하지 않는다면 그건 부정적인 신호다. 개발자들이 서로 다른 얘기를 한다면, 그 또한 부정적인 신호로 볼 수 있다.

높은 수준의 팀에서는 이 질문에 대해 일관적인 대답을 들을 수 있다. 그것은 모든 개발자가 업무 프로세스를 잘 알고 있으며, 프로세스가 단순해서 개발자들에게 부담되지 않고 도움이 되고 있음을 의미한다.

좋은 대답의 예: “우리는 새로운 기능과 버그를 고치기 위한 (몇) 주 단위의 스프린트를 진행하며 매일 서로에게 했던 일을 공유합니다. 우리와 함께 일하는 제품 관리자는 고객 대응에 임하면서 개발자들에게 새 기능과 버그 수정의 우선순위를 잘 조정해줍니다.”

나쁜 대답의 예: “회사에 오면 어떤 문제가 터졌는지 살펴봅니다. 거의 매일 비상사태입니다.”

내가 “스크럼”이나 다른 특정한 방법론을 언급한 것이 아님을 분명히 했으면 좋겠다. 나는 회사가 사용하는 개발 프로세스의 이름에는 관심이 없으며 그들이 매일매일 “어떻게 업무를 진행하는지”를 더 중요하게 본다.

2. 버전 관리 도구로는 무엇을 사용합니까?

좋은 도구의 사용은 좋은 팀의 지표가 된다. 어떤 팀이 구시대적인 버전 관리 도구를 사용하고 있다면, 아마 그것 말고도 철 지난 도구를 많이 사용하고 있을 것이다. 게다가 그들은 좋은 도구를 사용함으로써 얻는 효율을 그다지 중요하게 여기지 않을 것이다.

이 질문 다음으로는 업무 진행 방식에 대해 질문을 하면 좋다. “분기점(branch)을 사용하나요?” “재배치(rebase)와 병합(merge) 중 무엇을 선호하십니까?” 이런 질문은 그들이 사용하는 도구에 얼마나 전문적인 지식을 가졌는지, 그리고 그들에게 무엇을 기대할 수 있는지를 알 수 있다. 예를 들어 그 회사에 가면 리누스 토르발즈¹처럼 뛰어난 사람을 만날 수 있다는 확신을 얻을 수도 있지만, 오히려 내가 “지역 Git 전문가” 역할을 하게 될 것 같다는 예감을 하게 될 수도 있다.

이 질문은 개발 도구에 대한 전반적인 토론을 시작할 수 있도록 있도록 하며, 종종 당신에게 좋은 통찰을 가져다줄 것이다.

3. 여기서 일하면 어떤 점이 좋습니까?

확신에 찬 대답: 내가 하는 일에서 아주 큰 만족감을 느낍니다.
확신에 찬 대답: 우리는 일에서 아주 큰 재미를 느끼고 있습니다.
확신에 찬 대답: 나는 똑똑하고 친절한 우리 동료들과 일하는 것이 무척 좋습니다.
확신에 찬 대답: 관리 부서는 개발자들을 존중합니다.

긍정적 대답은 많을수록 좋다. 면접을 보는 회사에 좋은 점수를 주기 위해 위에 있는 모든 대답을 들어야 할 필요는 없다. 어떤 사람들은 선천적으로 자랑을 잘하지 못한다는 사실을 염두에 둬야 한다. 그러니 이 질문에서 아주 긍정적인 대답을 듣지 못하더라도 괜찮다.

하지만 다음에 오는 대답을 들으면서 확신에 찬 대답을 조금밖에 듣지 못한다면, 고민이 될 것이다.

확신 없는 대답: 월급은 잘 줍니다.
확신 없는 대답: 열심히 일할 필요가 없습니다.
확신 없는 대답: 배포를 위한 압박감이 그리 크지 않습니다.
확신 없는 대답: 내가 큰 실수를 해도 별문제가 되지 않습니다.
확신 없는 대답: … (침묵)

꾸며낸 말이 결코 아니다. 나는 실제 면접에서 저런 대답을 들었던 경험이 있다.

확신 없는 대답을 하나 들었다고 해서 바로 그 회사가 나쁘다고 판단하지는 않는다. 하지만 세 번째 질문에 대한 답이 모두 저런 식이라면, 나는 보통 다른 곳을 알아본다.

4. 유닛 테스트를 작성하십니까?

어떤 팀을 유닛 테스트 활용 사례를 바탕으로 평가할 때는 신중해야 한다. 유닛 테스팅에 대한 질문을 했을 때 기분이 좋아 보인다면 그것은 일반적으로 좋은 신호다. 그에 반해 왜 유닛 테스트를 작성해야 하는지, 유닛 테스트의 결점은 무엇인지에 대해 설명하지 못한다면 눈먼 양 도그마²에 빠져 있다는 징후로 볼 수 있다. “시간이 없다”는 등의 변명을 들며 테스트를 작성하지 않는다고 말한다면, 나는 좋지 않은 신호로 받아들인다.

5. 지속적 통합(CI) 프로세스를 갖추고 있습니까?

내가 아는 최고의 개발팀은 Jenkins, Travis, 그리고 BuildBot 같은 도구를 사용한다. 그 팀이 CI 도구를 사용하고 있지 않다면 관련 개념을 알고 있는지 알아본다. 만약 모른다면 이건 내 경험상 좋지 않은 신호다. CI 시스템을 갖추고 있다는 것은 그 팀이 자동화에 대한 믿음을 가지고 있다는 의미이며, 이는 매우 좋은 신호가 될 수 있다.

어떤 팀에게 이 질문은 지속적 배포(CD)에 대한 토론으로 이어지게 한다. 지속적 배포는 지속적 통합과 관련은 있지만 다른 개념이다. 웹 개발자 직군이라면 나는 적어도 CD에 대해 들어봤길 기대한다. 그리고 건강한 개발팀은 CD를 시스템에 부분적으로라도 적용하려고 시도한다.

이어질 수 있는 질문:

당신의 팀은 CI가 실패했다는 알림을 받으면 오류를 수정하기까지 보통 얼마나 걸립니까?
구축된 CI 시스템에서 좋은 점 / 안 좋은 점은 무엇입니까?
CI가 실행되는 데 시간이 얼마나 걸립니까? 더 빠르게 만들 수 있습니까?

6. 어떤 지표를 측정합니까?

이 질문은 정답이 없으며, 그 팀이 소프트웨어의 성능을 측정하기 위한 노력을 하고 있는지 파악하기 위한 것이다. 웹 개발팀은 보통 서버 응답 시간이나 요청 처리량, 사용자 수, 클라이언트 사이드의 반응성 등의 성능 지수에 대한 답변에 치중하는 경향이 있다. 하지만 이와 관련된 토론은 서로 다른 언어를 사용하는 사용자의 수, 브라우저 오류, 캐시 히트/미스 비율, 그리고 무수히 많은 다른 주제들로 이어질 수 있다. 만약 팀이 지표 측정에 시간을 들이고 있지 않다면, 이는 그들이 데이터에 기반을 둔 결정을 내리지 않음을 가리킨다. 나는 실제로 측정된 진짜 데이터를 기반으로 성능을 판단하는 팀에 좋은 점수를 매긴다. 하지만 이는 성능 측정뿐 아니라 다른 많은 것들에도 적용될 수 있다.

만약 면접관이 이 질문과 관련된 많은 대답을 할 수 있다면 그 팀은 높은 수준을 가지고 있다는 좋은 신호로 볼 수 있다. 만약 그들이 왜 굳이 그런 지표를 측정해야 하는지 모르겠다고 말한다면, 부정적인 신호로 보면 된다.

다시 도그마에 대한 법칙이 여기에서 적용된다. 그 팀이 굳이 가치 있고 활용 가능한 정보를 제공하지 않는 데이터를 측정하고 있으면서도 당신에게 만족할 만한 대답을 주지 못한다면, 그것은 경고 신호일 수 있다.

이어질 수 있는 질문:

제품의 가장 중요한 지표는 무엇입니까?
성능 측정 시스템으로 무엇을 사용합니까? (예, MixPanel, statsd, 기타)

7. 어떻게 버그를 찾고 수정합니까?

좋은 팀은 보통 전용 테스터를 가지고 있으며 개발자는 서비스의 품질에 공을 들인다. 진짜로 수준 높은 팀은 놀랄 만한 테스트 자동화를 갖추고 있다. 어떤 팀은 전용 테스터나 테스트 자동화를 갖추기에는 너무 작지만 그게 나쁜 팀이라는 의미는 아니다. 나는 그 팀이 가진 프로세스가 어떤지 확인하기 위해 이 질문을 한다. 개발자들이 너무 바빠서 다른 일을 할 수 없을 정도인가? 버그를 찾고 우선순위를 매기기 위한 제대로 된 프로세스를 가지고 있는가? 사용자에게 버그를 찾게 놔두고 있는 건 아닌가? 라는 질문에 답을 얻기 위해서다.

이어질 수 있는 질문:

버그 수정 우선순위를 어떻게 매깁니까?
어떤 버그 트래킹 도구를 사용합니까? (그 도구는 어떤 점에서 마음에 들지 않습니까?)
버그 트래킹에 Excel을 사용합니까? (Nooooo~~!)
현재 버그 트래킹 도구에는 몇 개의 버그가 있습니까?
버그 수정에 얼마나 걸립니까? (최소/최대/일반적으로)

8. 협업 도구로 무엇을 사용합니까?

내 경험상 높은 효율은 가진 팀은 다양한 협업 도구를 사용한다. 그들은 주로 협업을 위해 채팅 서비스(Slack, IRC, HipChat, Jabber)와 코드 리뷰 서비스(Gerrit, GitHub, GitLab, Review Board)를 사용한다. 물론, 유서 깊은 서비스라고 할 수 있는 Email도 사용한다. 나는 이 질문을 통해 개발자들이 서로 하는 일을 알고 있는지 알아보려 한다. 물론 내가 여기서 말하는 ‘안다’의 기준은 일반적인 의미의 ‘안다’이며 서로를 아주 자세하게 속속들이 알고 있다는 의미는 아니다. 또 협업 도구를 잘 활용하고 있는지도 확인한다. 가장 간단한 예는 자동 빌드 시스템에서 실패가 발생했을 때의 이메일 자동 발송 여부 같은 것이다. 그리고 웹 개발팀이라면 시스템에서 심각한 오류가 발생했을 때, 일정 수준 이상의 네트워크 처리량이 발생했을 때 채팅방에 자동으로 알림이 오는 것 같은 사례가 있을 수 있다.

9. 어떤 프레임워크를 사용합니까?

프레임워크에 대한 나의 취향은 2가지로 나뉜다:

나는 현대적인 것을 좋아한다.
나는 새로운 것을 좋아한다.

어떤 팀이 Motif로 AIX 데스크톱 앱을 만들고 있다면 나는 거기에 흥미를 느끼지 못할 것이다. 하지만 당신은 아닐 수 있다. 이건 무척 개인적인 차이라서 이 주제에는 당신이 가진 취향에 대한 확실한 이해를 바탕으로 접근해야 한다.

당신이 가진 프레임워크에 대한 취향에는 상관없이, 그 팀이 왜 그 프레임워크를 선택했는지 이해하는 것이 중요하다. 시대를 너무 앞서간 기술을 사용하고 있는가? 그들은 프레임워크를 마치 속옷을 갈아입듯이 바꾸지는 않는가? 그들의 코드가 매달 바뀌는 프레임워크로 인해 산산조각이 나 있지는 않은가? 너무 오래된 프레임워크를 버리지 못하고 있는 건 아닌가?

왜라는 관점에서, 나는 얼마나 많은 개발자가 그들이 사용할 기술을 결정하는 데 관여하고 있는지를 이해하려 한다. 관리자들이 기술 결정 권한을 독점하고 있는가? 관리자들이 개발자들에게 결정을 양보하고 있는가? 이 주제에 대한 답을 확실히 이끌어내기 위해 나는 보통 이런 질문을 한다. “프레임워크 X를 어떻게 도입하게 되었나요?“. 만약 개발자들이 답을 하지 못한다면 나쁜 신호이거나, 아니면 그들이 그 회사에 온 지 얼마 되지 않아서 잘 모르는 것일 수도 있다.

나는 개발팀이 그들이 사용하는 오픈소스에 직접 참여(contribute)하는 것을 좋아한다. 이는 그들이 그저 단순히 코드를 사용하기만 하는 것이 아니라 참여를 할 수 있을 만큼 충분히 잘 알고 있다는 말이기 때문이다. 이런 활동을 하는 사람들이 내가 함께 일하고 싶은 사람들이다. 만약 그 회사가 개발자들의 오픈소스 활동을 적극적으로 지원한다면 더욱 좋다. 왜냐하면, 그 회사는 오픈소스 진영의 일부가 된다는 것의 의미를 잘 이해하고 있다는 말이기 때문이다.

만약 그 팀이 개발에 도움을 줄 수 있는 도구가 이미 있는데도 새로운 도구를 처음부터 새로 만들고 있다면, 나는 걱정을 할 것이다. 물론 여기에는 예외가 있긴 하다. 예를 들어 Facebook은 도구를 직접 만들어서 사용해오고 있었다. 나는 거기에는 토를 달지 않았으며, 앞으로도 그럴 것이다.

10. 함께 작업해볼 수 있습니까?

만약 그 팀과 일하는 형태가 어떤 것인지 확실히 알고 싶다면, 실제로 함께 일해보길 바란다. 개인적으로 나는 이런 시도를 해 본 적은 없지만, 내 친구는 해 본 적이 있다. 나는 이게 아주 멋진 아이디어라고 본다. 만약 그 팀에 대한 모든 것을 알 수 있길 원한다면, 그 회사에 가서 반나절만 함께 일해보길 바란다. 함께 일해보기 위해 기밀유지 서약서에 사인해야 할 수도 있다. 만약 그 팀이 당신의 제안을 기꺼이 수용한다면 매우 좋은 신호로 볼 수 있다고 생각한다.

아마 이런 시도를 위해서는 관리자나 경영진의 누군가와 약속을 잡아야 할 것이다. 그래서 이 질문은 개발자들의 반응을 얻어내는 데 더 초점이 맞춰져 있다. 그들은 아마 이 아이디어를 들으면 관리자와 함께해야 한다는 생각에 진저리를 칠 것이다.

11. 다음 작업 마감은 언제입니까?

이 질문은 그 회사가 실제로 적용하고 있는 개발 프로세스에 대해 당신에게 더 많은 것을 알려주기 위해 고안되었다. 이 질문 자체로서는 그렇게 많은 정보를 얻을 수 없지만, 여기에 아래의 질문들을 추가한다면 많은 흥미로운 사실을 알 수 있게 된다.

누가 마감 기한을 결정합니까?
저번 마감 기한은 지켰습니까? 만약 그러지 못했다면, 이유는 무엇입니까?

높은 수준의 팀은 마감 시간을 지키는 것에 모두 동의한다. 제대로 지켜지지 않는 마감 기한은 그 팀이 제대로 굴러가고 있지 않다는 신호다. 또는 최소한 그 개발자는 일정을 결정하는 회의에 참석하지도 않았다는 의미다

12. 새로운 개발 환경을 세팅하는데 얼마나 걸립니까?

이 질문은 그 회사가 개발자 경험을 위해 얼마나 많은 노력을 하고 있는지를 측정할 수 있게 도와준다. 개발자가 컴퓨터를 세팅해서 코딩을 시작하기까지 몇 시간, 며칠, 몇 주가 걸리는가? 그 과정은 자동화가 되어 있는가 아니면 수동으로 직접 해야 하는가? 이는 그 팀이 소프트웨어 개발에 직접 관련되어 있지는 않지만 도움을 주는 “보조 활동”에 얼마나 능숙한지를 당신에게 말해줄 것이다. 그리고 그런 활동에 얼마나 큰 가치를 두고 있는지도 알려줄 것이다.

어떤 회사들은 개발 환경 설정 프로세스가 너무나 빨라서 개발자들이 입사 첫날에 코딩을 시작할 수 있다는 사실에 자부심을 가지고 있기도 하다. 이는 그 회사가 개발자들에게 깔끔한 개발 경험을 제공한다는 사실을 무척 중요하게 여기고 있다는 말이다.

관리자를 위한 질문

1. 언제 마지막으로 코드를 작성해 보셨습니까?

나는 관리자가 탄탄한 기술 기반이 있길 바란다. MBA 학위를 가진 내 친구들을 나무라는 것은 아니지만, 내가 정말로 좋아하는 관리자들은 내가 하는 일을 해 본 경험이 있는 사람들이라는 사실을 알 수 있었다.

2. 어떻게 관리자가 되었습니까?

나는 억지로 관리자가 된 사람보다는 그 일을 좋아하고 잘해서 관리자가 되기로 스스로 선택한 사람을 더 좋아한다. 또 그들의 팀을 지원하는 일에 집중하는 관리자를 더 좋아한다. 내가 가장 좋아하는 관리자는 팀원들의 삶이 더 나아지기 위해 노력하는 사람이지 관리 그 자체에만 신경을 쓰는 사람이 아니다. 내가 좋아하는 관리자는 자신이 팀의 조력자이며 보호자라고 생각한다. 그들은 봉사하는 태도를 보이고 있으며 자신의 가장 중요한 일은 팀원들이 하는 일이 더 나아지게 만드는 것으로 생각한다.

3. 팀원들은 자신이 오늘 무엇을 해야 하는지 어떻게 확인합니까?

이 질문을 개발자에게 했기 때문에 관리자에게도 같은 질문을 해서 답을 비교해 본다. 서로의 답이 일치하지 않는다면 뭔가 잘못된 것이 있다는 의미다. 나는 이런 종류의 불일치를 바로잡는 것은 관리자의 역할이라고 믿는다.

4. 지금 당신의 팀이 가지고 있는 가장 큰 과제는 무엇입니까?

관리자들은 보통 인원 부족이 가장 큰 문제라고들 한다. 이는 흔하고 뻔한 대답(결국에는 부족한 사람을 다 고용하게 된다)이기 때문에, 그럼 나는 두 번째로 가장 큰 과제는 무엇이냐고 물어본다. 이 질문을 통해 일정이 지연되고 있거나, 품질 관리에 문제가 있거나, 팀원들 사이의 인간관계에 문제가 있다거나 하는 경고 신호를 찾는다. 어떤 팀이든 문제를 가지고 있다. 그러기에 당신이 받게 될 답변은 다음과 같은 여러 가지 정황에 영향을 받는다:

관리자의 문제에 대한 인지 여부
관리자가 당신에게 솔직히 대하려는 의지 정도의 차이
그 팀의 문제의 심각성의 정도

5. 개인 성과 측정은 어떻게 합니까?

뛰어난 매니저는 이를 위한 좋은 기술을 가지고 있다. 가장 훌륭한 매니저는 팀원들의 개인 성과를 측정할 때, 팀 전체로부터 조심스럽게 피드백을 수집한다. 나쁜 매니저는 팀원들의 얘기는 듣지 않고 개인적인 관점에서 판단을 내린다.

6. 공식적인 성과 리뷰를 가집니까?

나는 팀원들이 성장할 수 있도록 피드백을 주는 일을 중요하게 생각하는 매니저와 함께 일하는 것을 좋아한다. 성과 리뷰는 고통스러울 수도 있고 긍정적인 경험이 될 수도 있다. 내 개인적인 경험에 의하면, 사람 대부분은 그것을 끔찍한 일로 여긴다. 정말로 훌륭한 관리자는 이 점을 잘 알고 있다. 그리고 좋은 방법을 사용해서 개인 성과 리뷰가 팀원에게 좋은 인상을 남길 수 있도록 하며, 자신과 함께 일하고 싶어지게 만들 것이다.

이어질 수 있는 질문:

개인 성과 향상을 위해 도움을 줬던 일에 관해서 얘기해 주실 수 있을까요?
리뷰를 하는 동안 사람들에게 어떤 식으로 조언합니까?

7. 해마다 연봉을 올려주고 있습니까?

나는 내가 회사에 이바지를 한 만큼 보상을 받을 수 있는지 알고 싶다. 이 질문에 긍정적인 답을 주는 회사라면, 나는 형평성에 대해 질문한다. 나에게 스톡옵션을 줄 것입니까? 매년 스톡옵션을 더 지급해 줄 것입니까?

어떤 개발자들은 이런 금전적인 질문을 하는 것을 불편해한다. 그러지 마라. 일반적으로 개발자들은 이 주제에 대한 생각을 너무 적게 한다. 하지만 관리자들은 이런 종류의 대화를 일하는 내내 한다. 이런 질문들은 관리자에게는 불편한 것이 아니어야 한다.

임금 인상을 위한 예산은 어떻게 잡습니까?
지난해 당신의 팀의 연봉 인상 금액의 중간값은 얼마입니까? (또는 인상 비율)
1년 후 저는 얼만큼의 연봉 인상을 기대할 수 있습니까? 최고와 최악의 경우는 어떻게 됩니까?

나는 이 질문을 연봉 인상에 대한 확실한 보장을 받기 위해서 하는 것이 아니다. 대신 그 회사가 어떻게 연봉을 관리하는지를 이해하기 위해서 한다. 이 회사에서는 연봉 인상을 위해 내 방식대로 밀고 나가야 할 것인가? 아니면 이미 표준화된 프로세스가 정립되어 있는가?

8. 회사의 복지를 설명해주는 자료를 가져갈 수 있을까요?

나는 사람 대부분이 이 질문은 알고 있다고 생각하지만 완벽함을 위해 언급할 가치가 있을 것 같다. 회사 대부분은 그들의 복지를 소개해주는 한 뭉치의 서류를 건네주거나 웹 사이트를 소개해 줄 것이다. 복지 혜택에 대해 알고 있는 것은 중요하다. 왜냐하면, 당신이 얻는 보상에서 무척 큰 부분을 차지하기 때문이다. 이 질문은 미국에서만 해당하는 사항일지도 모른다. 나는 다른 나라에서는 기업에서 제공되는 의료보험이 어떻게 작동하는지 잘 모른다.³

9. 당신은 직원들의 순위를 매깁니까?

어떤 회사들은 급여 인상과 보너스를 직원들의 순위를 매겨서 결정한다. 직원들의 순위로 정렬된 긴 목록을 일정 비율로 “좋음”, “평균”, “나쁨”으로 잘라버린 후 결정하는 식이다.

나는 저런 방식을 좋아하는 개발자를 만나 본 적이 없다. 큰 회사에서는 이런 방식을 일반적으로 사용한다. 저 방법은 당신에게 함께 일하는 동료가 언젠가는 보수를 위해 경쟁해야 할 상대라는 인식을 심어줘서 직원 사이의 소통에 문제가 생기게 만들 수 있다.

면접을 보는 회사가 저런 정책을 시행하고 있다고 해서 그 회사가 일하기에 끔찍한 곳이라고 판단해야 한다는 의미는 아니다. 저런 회사에서는 다른 생각을 하는 멋진 사람들이 조금씩 있게 마련이다. 면접관들에게 저런 정책을 어떻게 생각하느냐고 물어보라. 어떤 관리자는 꽤 솔직하게 회사의 시스템에 대한 비호감을 드러내기도 할 것이다. 그리고 몇몇은 자신의 팀을 위해 어떻게 시스템을 잘 활용하는지 알려주기도 한다. 만약 그런 관리자를 만난다면 직원들의 순위를 매기는 시스템은 눈감아 줄 수도 있을 것이다.

그리고 모든 사람이 저런 시스템을 싫어하지 않는다는 사실을 명심해야 한다. 내가 어떤 종류의 사람들을 만나지 못했다고 해서 아예 그런 사람이 없는 것은 아니기 때문이다.

이어질 수 있는 질문:

당신은 정말로 “X%“의 직원들이 “나쁨”이라고 생각합니까? 그들은 당신의 채용 프로세스에 대해서 뭐라고 얘기하나요? (이는 다소 대담한 질문이다. 신중히 하길 바란다)
성과가 높은 사람을 가려내기 위해 상대적인 평가를 진행합니까?
직원들의 순위를 매기기 위해 어떤 지표를 측정합니까?
측정한 지표들의 정확도는 어떻게 판단합니까?
이 지표들로 실제로 성과가 높은 직원들을 파악했는지는 어떻게 보장합니까?

10. 주기적인 팀 회고를 진행합니까?

만약 한다면, 어떤 방식입니까? 팀원들에게 얼마나 자주 피드백을 받습니까? 언제 마지막으로 직원들의 피드백을 바탕으로 당신의 관리 방식을 조정했습니까?

이런 질문들은 관리자가 직원들에게 얼마나 민감하게 반응하는지, 그리고 직원들은 얼마나 피드백을 잘 전달하면서 관리자와 소통하는지를 알 수 있도록 해준다.

회고가 이루어지지 않는다면 팀에게 있는 문제를 파악하기 어려우며 문제 해결을 위해 홀로 노력해야 한다. 그리고 만약 관리자가 팀의 발전을 위해 피드백을 받는 것을 좋아하지 않는다면, 그 팀은 아마도 문제가 있어도 모른 척하거나 피드백을 주는 것에 부담을 느끼는 분위기가 조성되어 있을 것이다.

경영진을 위한 질문

면접을 볼 때 항상 회사의 고위층과 얘기를 나눌 수 있는 것은 아니지만, 특히 큰 회사라면 더욱, 그래도 만약 그런 기회가 주어진다면 나는 그것을 그 회사의 재정적 생존력을 판단할 기회로 삼는다. 나는 그런 판단을 할 자격이 있는 사람은 아니지만, 면접을 통해 파악할 수도 있는 명백한 문제들이 있다. 그리고 나는 회사의 수직 문화가 어떠한지 알고 싶어한다. 왜냐하면, 그 정보는 회사가 개발자를 어떻게 평가하는지 알 수 있기 때문이다. 그것이 긍정적인 방향이든, 부정적인 방향이든 말이다.

1. 어떻게 투자를 받았습니까?

나는 회사를 지탱하는 자금의 실체를 파악하려고 한다. 자금을 조달한 곳이 벤처캐피털인지, 사모펀드인지, 주식인지, 회사의 이윤에 의한 것인지 알고 싶기 때문이다. 인터뷰 전에 쉽게 찾아볼 수 있는 내용이기도 하지만, 회사 고위층은 내가 구글이나 CrunchBase를 통해서는 알 수 없는 내용을 알려줄 수 있다.

2. 수익이 나고 있습니까?

만약 그렇다면, 문제없다! 만약 아니라면, “수익을 내기 위한 어떤 계획을 하고 있습니까?”라는 질문을 할 수 있을 것이다. 어떤 스타트업들은 수익을 내기 위한 계획을 하는 반면, 어떤 곳은 합병이나 IPO를 할 방법을 찾고 있기도 하다.

이어질 수 있는 주제:

지난 몇 분기/년 동안의 수익 증가 추이
수익에 위험이 될 수 있는 경쟁자, 가격, 적자
추가 자금을 조달하기 전까지 회사가 운영될 수 있는 기간

3. 외주에 대해서는 어떻게 생각합니까?

나는 내가 지원하는 직무가 장차 외주화될 수 있는지, 또는 외주 개발자를 관리하는 직무로 변경될 가능성이 있는지 알고 싶다. 여기서 말하는 것은 해외 외주만이 아니며 계약자도 포함한다.

4. 기업 문화에 대해서 알려주십시오.

이 질문은 경영진의 관점과 개발자의 관점의 차이를 조정하기 위해 사용하는 또 다른 방법이다. 관점의 차이는 문제의 신호가 될 수 있기 때문이다. 만약 경영진과 개발자가 같은 대답을 한다면 상하 소통이 잘 되고 있다고 볼 수 있다. 나는 고위층과 말단 직원들 사이에 접점이 있는지 알고 싶다. 그리고 경영진이 미래에 대한 비전을 잘 공유하고 있는지도 알고 싶다. 내가 가장 일하고 싶은 회사는 경영진과 직원들이 뚜렷한 비전을 공유하고 있는 곳이다.

5. 이 회사의 성공에 대해 어떤 확신이 있습니까?

이 질문을 통해서는 영업을 위한 수사가 아닌 진짜 근거를 얻으려 한다. 만약 경영진이 수익, 시장 규모, 자본과 관련된 실제 수치를 들려준다면 이는 좋은 신호다. 또 이 수치를 다른 소스를 통해 검증할 수 있다면 훨씬 더 좋은 신호다. 하지만 그 수치들이 매우 좋지 못할 수도 있다.

6. 보고 구조에 대해서 알려주십시오.

나에게 가장 좋은 대답은 단순한 형태다. 간단한 조직도를 그리면서 보고 구조를 설명할 수 있다면 나는 만족한다. 개인적으로 선호하는 업무 형태는 구조적인 소통에 드는 비용이 적은 작고 민첩한 회사에서 일하는 것이다. 당신이 선호하는 형태는 다를 수 있다. 그것은 그대로 괜찮으며, 이 질문은 회사에 대해 정보에 기반을 둔 판단을 내리는 데 필요한 정보를 얻는 데 도움을 주기 위해서 고안되었다.

결론

면접은 양방향이다. 합격이라는 좋은 결과가 있을 수 있으니 면접을 볼 때 회사에 대한 제대로 된 판단을 내리기 위한 모든 정보를 얻도록 하자. 행운을 빈다!

Linus Torvalz, 리눅스와 Git을 만든 개발자
↩
dogma, 독단적인 신념 또는 가치관
↩
미국은 높은 의료비로 유명하며 의료보험비도 연간 수만 달러에 이른다
↩

구글 애널리틱스 API를 사용한 Flask 앱을 uWSGI와 nginx로 배포한 과정

rhostem — Tue, 20 Nov 2018 00:00:00 GMT

이미지 출처: Link

포스트 통계 기능을 위해 사용한 Google Analytics 서비스 API

이 블로그는 CMS 서비스나 별도의 백엔드 서비스가 연결되어 있지 않은 웹사이트라서 따로 관리하고 있는 통계 데이터가 없다. 대신 구글 애널리틱스는 처음부터 연결해 뒀기 때문에 페이지뷰를 확인하는 것은 가능하다. 저번에 블로그 검색 기능을 추가했으니, 이번에는 인기 포스트를 보여주는 기능을 추가하고 싶어서 구글 애널리틱스 Reporting API의 힘을 빌리기로 했다. 그런데… 서비스 애플리케이션으로 지원하는 언어로 Java, Python, PHP를 지원하고 자바스크립트는 없는 게 아닌가? 자바스크립트가 백엔드 언어로 활용되기 시작한 역사가 오래되지 않긴 했지만 그래도 node.js를 만든 구글에서 지원하지 않는다는 건 조금 아쉬웠다. 그래서 공부도 할겸 파이썬으로 개발을 진행하기로 했다.

서비스 애플리케이션을 위한 인증 시나리오

구글 API를 사용하기 위한 OAuth 2.0 인증 시나리오에는 서비스 애플리케이션, 설치형 앱, 웹 애플리케이션이 있다.

서비스 애플리케이션은 백엔드(내가 구현한 앱)와 백엔드(구글 애널리틱스 API) 사이에서 인증을 진행한다. 따라서 웹사이트를 사용하는 엔드 유저는 인증을 하지 않아도 된다. 이 블로그에서는 비인증 유저에게 통계 데이터를 제공해야 하므로 나는 서비스 애플리케이션에 해당하는 시나리오로 인증을 구현했다.

서비스 애플리케이션 인증 시나리오

웹 애플리케이션은 엔드 유저에게 로그인을 요구한다. 이 시나리오는 소셜 로그인이나 SNS 공유를 하려고 할 때 해당 서비스에 로그인을 요구하는 사례에 해당한다.

웹 애플리케이션 인증 시나리오

그리고 나머지 하나는 설치형 애플리케이션을 위한 시나리오인데, 안드로이드, iOS 앱 및 기타 설치형 애플리케이션에 해당하는 시나리오다.

Flask 프레임워크

인기 있는 파이썬 프레임워크로는 Django, Flask가 있는데 Django는 지원하는 기능이 무척 많고 덩치가 크다. 나는 최소한의 기능만 있으면 되기에 가벼움 그 자체인 Flask를 선택했다. Flask 홈페이지에도 “Flask is a microframework for Python”이라고 소개되어 있을 정도다.

처음 시도한 프레임워크였기에 환경 설정, 에디터 설정, 패키지 관리 등 개발 외적인 작업에 들어간 시간이 많았지만 필요한 기능 자체는 시작일, 종료일과 컨텐츠 경로를 기준으로 한 페이지뷰 카운트 데이터를 가져오는 것 하나여서 아주 오랜 시간이 걸리지는 않았다. 그리고 개발을 진행하다 보니, 파이썬은 문법이 무척 간결해서 익숙해지기만 한다면 무척 사용하기 즐거울 것 같았다. 언젠가 파이썬으로 더 많은 것을 해 보고 싶어졌다.

uWSGI로 파이썬 앱 배포하기

WSGI는 Web Server Gateway Inerface의 약자로서, 웹 서버(etc. nginx)와 파이썬 웹 애플리케이션 사이의 통신을 위한 프로토콜이다. 과거에는 파이썬 앱이 웹 서버와 통신하기 위한 선택지에 제한이 있었기에 보다 다양한 방법으로 통신하기 위해 만들어졌다고 한다.

Flask로 만든 앱은 WSGI 스펙을 기반으로 한 앱이 된다. 그런데 nginx 웹 서버는 WSGI 스펙을 구현해두지 않았기 때문에 Flask 앱과 직접 통신할 수가 없다. 그래서 uWSGI 서버를 중간에 둔다. uWSGI는 WSGI 스펙을 구현한 서버인 동시에 프로토콜이며, nginx와도 통신할 수 있다. uWSGI가 nginx와 Flask 앱 중간에서 미들웨어 역할을 하게 되는 것이다.

uWSGI 엔트리 포인트 작성

기존의 앱 메인 파일 외에 uWSGI 서버 실행을 위한 엔트리 포인트 역할을 할 모듈을 별도로 추가한다.

# wsgi.py
from app import app

if __name__ == "__main__":
    app.run()

uWSGI 서버 실행

uwsgi를 설치한 후 엔트리 포인트로 서버를 구동한다.

uwsgi --socket 0.0.0.0:5000 --protocol=http -w wsgi:app

커맨드라인으로 실행도 가능하지만 역시 설정파일을 따로 두는 것이 좋다.

# myproject.ini
[uwsgi]
module = wsgi:app

master = true
processes = 5

socket = blogapi.sock # uWSGI가 만드는 socket 파일의 이름. nginx와 연결할 때 사용된다.
chmod-socket = 660
vacuum = true

설정파일을 만든 후에는 아래와 같은 방식으로 실행한다.

uwsgi —ini blogapi.ini

실행하면 앱을 실행한 위치에 blogapi.sock라는 이름의 소켓 파일이 만들어질 것이다.

nginx 서버에 uWSGI 소켓 연결

nginx에 가상 호스트를 추가하고 uWSGI 소켓을 연결한다.

# /etc/nginx/sites-enabled/blogapi
server {
    listen 80;
    server_name blogapi.rhostem.com;

    location / {
        # uWSGI가 만든 소켓 파일을 연결한다.
        uwsgi_pass unix:/home/ubuntu/www/blogapi/blogapi.sock;
        include uwsgi_params;
    }
}

nginx 서버를 재시작하면 이제 http://blogapi.rhostem.com을 통해 앱에 접속할 수 있다.

Flask 앱 자동 시작을 위한 시스템 서비스 등록

서버가 재시작될 때 Flask 앱도 자동으로 시작하도록 시스템 서비스 파일을 만들어서 등록하면 앱 관리가 더욱 편해진다. ubuntu의 시스템 서비스 파일은 /etc/systemd/system 폴더에 만든다.

# /etc/systemd/system/blogapi.service

[Unit]
Description=uWSGI instance to serve flask app blog-api
After=network.target

[Service]
User=ubuntu # 로그인 사용자
Group=www-data
WorkingDirectory=/home/ubuntu/www/blogapi # 실행 디렉토리
Environment="PATH=/home/ubuntu/www/blogapi/venv/bin" # 환경 변수
ExecStart=/home/ubuntu/www/blogapi/venv/bin/uwsgi --ini blogapi.ini # 실행 명령어

[Install]
WantedBy=multi-user.target # 자동 실행

서비스 실행 명령어는 아래와 같다.

sudo systemctl start blogapi
sudo systemctl enable blogapi

그 외의 작업들

이 외에도 파이썬 프로젝트를 위한 virtualenv 설정, pip로 패키지 관리하기, CORS 설정, blog.rhostem.com이 https 프로토콜을 사용하기 때문에 Certbot으로 무료 인증서 설치하기 등의 작업이 필요했다. 이번에 구현한 파이썬 서버는 아래 링크된 저장소에서 확인할 수 있다.

rhostem/blog-api: api service for blog

참고 자료

자바스크립트 정규표현식의 capturing group

rhostem — Sun, 11 Nov 2018 00:00:00 GMT

정규표현식

정규표현식은 문자열을 표현할 수 있는 패턴이다. 이메일, 전화번호 등의 유효성을 검증하거나, 문자열에서 원하는 부분을 추출하기 위한 용도로 사용된다. 예를 a로 시작하는 영어 단어의 패턴은 아래와 같다.

/^a[a-z]*$/i

정규표현식은 자바스크립트 객체이며 test, exec 등 정규표현식을 활용하기 위한 여러 가지 메소드를 가지고 있다. 객체(Object)를 new 키워드 없이 중괄호({}, brace)만으로 선언 가능한 것처럼, 정규표현식도 위에서 제시한 것처럼 슬래쉬(/) 사이에 패턴을 입력하는 것으로 만들 수도 있고 new 키워드를 사용해서 만들 수도 있다.

const startWithA = new Regexp('^a[a-z]*$', 'i')

정규표현식은 특수한 의미가 있는 기호들을 잘 활용해야 한다. 사실 그게 전부라고도 할 수 있다. 하지만 그런 기호들은 실제 의미와 어떠한 관계도 없어 보이는 것들이 대부분이라 정규표현식을 처음 접하면 그저 이해할 수 없는 암호처럼 보이곤 한다. 계속 사용하면서 익숙해지거나 외우는 수밖에 없는 부분이다.

캡쳐링 그룹(capturing group)

정규표현식에서 캡쳐링 그룹은 괄호로 둘러싼 영역이다. 캡쳐링 그룹이 있으나 없으나 패턴의 유효성을 검증하는 test 메소드의 결과는 같다. 하지만 문자열(String) 객체가 가지고 있는 match 메소드의 결과는 달라진다. 예를 들어 ‘github.com’ 사이트가 복수의 서브도메인을 가진다고 할 때, 서브도메인을 포함한 주소를 표현하는 패턴은 다음과 같다.

var url = 'https://rhostem.github.com'
var domain = /https?:\/\/\w+\.github.com/
url.search(domain) // 0
url.match(domain) // ["https://rhostem.github.com", index: 0, ...]

서브도메인 영역을 괄호로 둘러싸서 캡쳐링 그룹을 만들면, match 메소드의 결과는 달라진다.

var url = 'https://rhostem.github.com'
var domain = /https?:\/\/(\w+)\.github.com/
url.search(domain) // 0
url.match(domain) // ["https://rhostem.github.com", "rhostem", index: 0, ...]

search 메소드는 문자열 내부에서 정규표현식이 매칭이 시작되는 지점을 반환한다. 위의 예제에서는 문자열 처음부터 매칭되기 때문에 결과가 0이다.

match 메소드의 결과 배열에서 첫 번째 항목은 전체 매칭 문자열이며, 두 번째부터는 캡쳐링 그룹 안에 있는 문자열이 차례대로 들어간다. 캡쳐링 그룹을 사용하면 패턴 안의 원하는 부분을 보다 편리하게 분리해낼 수 있다.

그리고 String 객체의 replace 메소드도 정규표현식을 활용하는데, 캡쳐링 그룹을 사용하면 패턴 확인과 함께 원하는 부분만 교체하는 기능을 구현할 수 있다. 위의 정규표현식을 조금 수정해서 서브도메인 영역을 www문자열로 바꿔보자.

'rhostem.github.com'.replace(/^\w+(\.github\.com)$/, 'www$1')
// www.github.com

서브도메인 영역을 제외한 부분을 캡쳐링 그룹으로 둘러쌌고, replace 메소드의 두번째 인자에는 대체할 문자열을 패턴을 전달했다. 여기서 $1은 첫 번째 캡쳐링 그룹으로 둘러싼 영역에해당한다. 만약 두 번째 캡쳐링 그룹이 있다면 해당 문자열은 $2가 될 것이다. 자세한 사항은 링크를 참조하기 바란다.

코드 에디터에서의 정규표현식과 캡쳐링 그룹의 활용

코드 에디터에서 검색을 할 때 정규표현식을 지원하는 경우가 많다. 그리고 캡쳐링 그룹과 $1같은 파라미터 문자열도 지원한다. 이를 사용하면 여러 파일을 한꺼번에 쉽게 수정하는 것이 가능하다.

예를 들어 styled-components 라이브러리를 사용하고 있는데, v3에서 v4로 업그레이드하려고 할 때 모듈 사용 방법이 달라져서 수정할 사항이 많이 생긴다. 대표적으로 extend 메소드의 사용방식이 달라진다.

// v3
const ExtendedComponent = Component.extend`
 color: green;
`

// v4
const ExtendedComponent = styled(Component)`
 color: green;
`

extend 메소드를 많이 사용했다면 하나하나 고치는데 제법 많은 시간이 걸릴 것이다. 이럴 때 정규표현식과 Visual Studio Code의 ‘파일에서 바꾸기’ 기능을 사용하면 한 번에 모두 바꿀 수 있다.

이처럼 정규표현식은 에디터에서도 검색과 수정에 유용하게 활용할 수 있다.

논-캡쳐링 그룹(non-capturing group)

그룹 시작 부분에 ?: 기호를 추가하면 non-capturing 그룹이 된다. 캡쳐링 그룹이 결과 배열에 추가되는 것과는 달리 non-capturing 그룹은 결과 배열에 추가되지 않는다. 아래는 두 개의 캡쳐링 그룹을 사용해서 단어의 위치를 변경하는 예제다.

'javascript'.replace(/(java)(script)/, `$2-$1`) // script-java

java와 script를 캡쳐링 그룹으로 지정했기에 패턴을 사용해서 위치를 바꿀 수 있었다. 하지만 캡쳐링 그룹의 시작 부분에 ?:을 추가하면 non-capturing 그룹이 되어 결과 배열에 추가되지 않으며, 결과적으로 $2에 해당하는 패턴을 찾을 수 없어 다른 결과가 나온다.

'javascript'.replace(/(java)(?:script)/, `$2-$1`) // "$2-java"

그럼 이런 생각이 들 것이다. 저건 결국 괄호로 둘러싸지 않은 것과 같은데, 왜 굳이 non-capturing 그룹이라는 패턴을 지원할까? 라고 말이다. non-capturing 문법이 있는 이유는 그룹이 다른 역할로도 사용되기 때문이다. 예를 들어 앞서 서브도메인을 추출한 예제에서, http 프로토콜이 포함된 것과 포함되지 않은 문자열을 모두 매칭시키면서 서브도메인만 캡쳐링 그룹에 포함하고 싶을 때가 있을 것이다. 그러면 아래와 같이 작성할 수 있다.

/(?:https?:\/\/)?(\w+)\.github.com/.exec('rhostem.github.com')
// ["rhostem.github.com", "rhostem", index: 0, ...]

/(?:https?:\/\/)?(\w+)\.github.com/.exec('https://rhostem.github.com')
// ["https://rhostem.github.com", "rhostem", index: 0, ...]

http 프로토콜 패턴 부분을 그룹으로 만들고, 바로 다음에 조건부 매칭을 의미하는 ? 기호를 붙여서 프로토콜에 해당하는 문자열 전체가 조건부 패턴이 되었다. 하지만 매칭 결과 배열에는 포함하고 싶지 않기 때문에 ?: 기호를 사용해서 non-capturing 그룹으로 지정했다. non-capturing 그룹을 사용하지 않았다면 아래처럼 프로토콜 영역도 결과에 포함된다.

["https://rhostem.github.com", "https://", "rhostem", index: 0, ...]

non-capturing 그룹 덕분에 항상 결과 배열의 2번째 아이템이 서브도메인이 될 것이므로, 다음과 같은 함수를 작성해서 서브도메인을 추출할 수 있게 된다.

const getSubDomain = (url = '') => {
  const matches = /(?:https?:\/\/)?(\w+)\.github.com/.exec(url)
  return matches && matches[1] // 첫 번째 캡쳐링 그룹
}

Lookahead

Lookahead도 그룹 패턴으로, Lookahead 그룹 안에 있는 패턴이 뒤에 올 때만 매칭이 된다. 캡쳐링 그룹과 다른 점은 전체 매칭 결과에 Lookahead 그룹 안에 있는 패턴이 포함되지 않는다는 것이다. lookahead(앞쪽을 보다)라는 이름이 가지는 의미 그대로 관찰자 역할을 할 뿐 전체 패턴에서는 제외되어 있다고 여기면 될 것 같다

// capturing group
/java(script)/.exec('javascript') // ["javascript", "script", index: 0, ...]

// positive lookahead
/java(?=script)/.exec('javascript') // ["java", index: 0, ...]

Lookahead에는 positive와 negative가 있는데, 앞서 제시한 ?= 기호는 positive lookahead로서 그룹 안의 패턴이 뒤에 와야 함을 의미하며, negative lookahead를 나타내는 ?! 기호는 그룹 안의 패턴이 뒤에 오지 말아야 함을 의미한다. Negative lookahead 패턴을 사용한 아래의 정규표현식을 사용하면 ‘java’ 뒤에 ‘script’라는 문자열이 오지 않는 모든 문자열을 매칭시킬 수 있다

/java(?!script)/.exec('java coffee') // ["java", index: 0, ... ]

Lookbehind

Lookahead와 정반대의 역할을 하며 그룹 안의 패턴이 앞에 나올 때 매칭이 된다. 하지만 ECMAScript 2018 스펙이라서 글을 쓰는 시점에서는 Chrome 브라우저에서만 사용 가능하며 Safari, FireFox는 브라우저는 지원하지 않는 문법이다.

Lookbehind도 positive, negative가 있으며, positive lookbehind는 ?<=, negative lookbehind는 ?<! 기호로 표현한다.

// java 다음에 script가 와야 한다.
/(?<=java)script/.exec('javascript') // ["script", index: 6, ...]

// java가 아닌 문자열 다음에 script가 와야 한다.
/(?<!java)script/.exec('purescript') // ["script", index: 4, ...]

Nuxt, Vue, Express로 프론트엔드와 백엔드를 하나의 서버 앱에서 사용하기

rhostem — Sun, 28 Oct 2018 00:00:00 GMT

SPA(Single Page Application)의 서버 렌더링

웹사이트의 내용을 페이지가 바뀔 때마다 완전히 새로 구성하지 않고 필요한 부분만 동적으로 변경하는 방식의 앱을 SPA라고 한다. 서버는 클라이언트에게 웹사이트에 필요한 필수적인 자원만 넘겨준 후 그 다음은 모두 브라우저가 처리하도록 한다. WWW가 생긴 후 오랜 기간동안 일반적인 웹사이트는 페이지가 변경될 때마다 서버에서 모든 컨텐츠를 다시 내려받는 방식이었다. 하지만 SPA는 그 전통적인 방식을 벗어난 것이며, 예전과는 비교할 수 없을 정도의 빠르고 쾌적한 사용자 경험을 제공할 수 있게 되었다.

그런데 SPA에게는 사용자에게는 보이지 않는 문제가 있다. 검색엔진같은 소프트웨어에게는 SPA로 만들어진 웹사이트는 아마 아무런 내용이 없는 빈 페이지로 보일 것이며, 심지어 모든 페이지의 head 태그 안에는 같은 내용이 들어가 있을 것이기 때문에 페이지의 구분도 불가능하다. 즉 검색 엔진 최적화(SEO, Search Engine Optimization)가 어려우며 검색 엔진에 웹사이트가 가지고 있는 다양한 컨텐츠가 노출되지 않는다. 더 많은 사용자 유입을 위해 검색 엔진의 힘을 빌려야 하는 언론, 쇼핑몰, 블로그 같은 웹사이트라면 SPA를 도입하기 망설여질 것이다.

그래서 개발자들은 이를 극복하기 위해 서버 기반 웹앱과 SPA를 결합하는 방법을 고안했다. 서버가 브라우저에 아무것도 없는 HTML 페이지를 전달하는 대신, 최초에 표시될 내용만큼은 모두 서버에서 확실히 구성한 후 브라우저에 보내자는 것이다. 그리고 그 이후부터는 SPA처럼 동작하게 한다. 그러면 검색 엔진에게도 제대로 된 웹페이지가 보여질 것이고, 사용자에게도 여전히 빠른 웹사이트를 제공할 수 있을 것이다. 이 방식을 서버 사이드 렌더링, 또는 Universal Web App이라고 부른다. 서버 사이드 렌더링 아이디어가 없었다면 SPA의 활용 범위는 지금보다 훨씬 더 좁았을 것이다.

Vue의 서버 사이드 렌더링을 쉽게 만드는 Nuxt 프레임워크

Nuxt는 Vue.js를 프론트엔드 레이어로 하는 서버 사이드 렌더링 프레임워크다. React 서버 사이드 렌더링 프레임워크인 Next.js와 이름이 유사하다는 점에서 추측할 수 있겠지만, 둘 다 Zeit팀에서 시작한 오픈소스 프레임워크다.

서버 사이드 렌더링 아이디어 자체는 간단하지만, 그걸 구현하는 것은 그리 녹록치 않은 일이다. 앱의 시작 지점이 서버니까 일단 서버 앱이 있어야 하며, 클라이언트 스크립트도 이 페이지가 서버에서 시작하는지, 웹브라우저에서 시작하는지를 구분해서 처리해야 하고, 라우트별로 다른 API를 호출해서 HTML의 head와 body를 구성해야 하는 등 할 일이 많다. Vue가 등장하기 전이며 React는 0.1x였던 시기에는 프로젝트 초기 구성 자체가 큰 허들이었던 걸로 기억한다.

하지만 이제는 Next.js, Nuxt.js라는 멋진 프레임워크가 있기에 처음부터 끝까지 모든 것을 제어하고 싶은 사람이 아니라면, 아주 간단히 서버 사이드 렌더링을 구현할 수 있다. 특히 프레임워크 차원에서 개발자에게 필요한 각종 유용한 기능을 제공하기 때문에 더욱 좋다.

그런데 문득 이런 생각이 들었다. 프론트엔드 앱의 시작 지점이 서버라면, 굳이 API 서버 앱을 별도로 둘 필요 없이 예전처럼 하나의 앱으로 개발하면 되지 않을까? Express.js라는 훌륭한 자바스크립트 서버 프레임워크도 있고 말이다. 하지만 자바스크립트가 아닌 다른 언어를 사용하는 백엔드 개발자가 더 많은데다, SPA 프레임워크를 사용하면서 서버 개발자가 마크업을 건드릴 일이 사라졌으니 반드시 같이 있어야 할 필요가 없기도 하다. 최근에는 서버리스 컴퓨팅이나 마이크로 서비스 아키텍쳐까지 트렌드를 타고 있어서 더욱 그렇다. 하지만 공부나 사이드 프로젝트를 위해 혼자 앱을 개발할 때는 안성맞춤일 것 같고, 풀 스택 개발자들이 함께 앱을 만들어 나갈때도 좋을 것 같다.

Nuxt로 만든 앱에 API 라우트를 연결하는 과정

Nuxt.js 앱 설치

Nuxt는 간편한 설치 과정을 제공한다. 설치 과정에서 여러가지 옵션을 선택할 수 있는데, Custom Server 옵션으로 express를 선택하도록 하자.

nuxt.config.js에서 미들웨어 설정

설치가 완료되고 npm run dev 명령어를 실행하면 앱이 잘 실행되는 것을 확인할 수 있다. 옵션 선택 과정에서 prettier나 eslint를 선택했으면 문법 오류 때문에 빌드가 안될 수 있는데, 그럴 땐 일단 webpack에서 관련 설정을 임시로 제거하도록 하자.

// nuxt.config.js
...

  build: {
    /*
    ** You can extend webpack config here
    */
    extend(config, ctx) {
      // Run ESLint on save
      if (ctx.isDev && ctx.isClient) {
        // 이 부분을 주석 처리하고 코드는 나중에 정리하자
        config.module.rules.push({
          enforce: 'pre',
          test: /\.(js|vue)$/,
          loader: 'eslint-loader',
          exclude: /(node_modules)/
        })
      }
    },
  },

...

그리고 nuxt.config.js 파일에서 serverMiddleware 속성에 새로운 값을 할당한다.

// nuxt.config.js
...

  serverMiddleware: [
    // <project root>/api/index.js 모듈을 미들웨어로 추가
    '~/api/index.js',
  ],

...

그리고 미들웨어로 사용할 express 앱을 모듈로 추가한다.

// <project root>/api/index.js
const express = require('express')

// express 인스턴스 생성
const app = express()

// 실제로는 /api 라우트를 처리하는 메소드가 된다.
app.get('/', function(req, res) {
  res.send('API root')
})

// 모듈로 사용할 수 있도록 export
// 앱의 /api/* 라우트로 접근하는 모든 요청은 모두 app 인스턴스에게 전달된다.
module.exports = {
  path: '/api',
  handler: app
}

이렇게 설정과 파일을 구성하면 Nuxt는 자동으로 api/index.js 파일을 불러와서 미들웨어로 사용한다. 브라우저에서 /api 라우트에 접근하면 res.send 메소드로 전달한 문자열이 출력되는 것을 확인할 수 있다.

이제 express가 미들웨어로 연결되었으니 여기서부터는 일반적인 express 앱 개발을 진행하면 된다. 앱에 라우트를 추가하고, 미들웨어를 추가하고, 데이터베이스를 연결하면 API 서버가 되는 것이다. 조금 더 상세한 예제는 템플릿 프로젝트를 참조하도록 하자.

프론트엔드에서 API 호출

이제 Vue 페이지에서 API 라우트를 호출해서 컴포너트에 데이터를 연결하도록 하자. Nuxt는 Vue 컴포넌트에서 페이지 로딩 전에 비동기 데이터를 호출하기 위한 메소드, head 태그를 커스터마이징하기 위한 메소드를 제공하기 때문에 무척 편리하다. 아래 예제 코드는 /api/user/:id 라우트가 name 속성을 가진 JSON 데이터를 제공한다고 가정하고 작성한 컴포넌트다.

// pages/user.vue

<template>
  <div>
    <!-- asyncData 메소드에서 전달한 데이터를 마크업에 연결 -->
    이름 : {{user.name}}
  </div>
</template>

<script>
export default {
  // Nuxt.js에서 제공하는 페이지 로딩 전에 비동기 데이터를 호출하기 위한 메소드
  // Vue.js의 data 메소드와 유사한 역할을 한다
  async asyncData({ app, query }) {
    // 설치 과정에서 axios 플러그인을 선택했다면 axios를 아래와 같은 형태로 사용 가능하다.
    const user = await app.$axios.$get(`/api/user/${query.id}`)
    return { user }
  },

  // Nuxt.js에서 제공하는 head 태그 수정용 메소드
  head() {
    return {
      title: `User | ${this.user.name}`, // asyncData에서 리턴한 user 데이터를 사용할 수 있다.
    }
  },
}
</script>

이렇게 Nuxt 프레임워크의 도움으로 간단하게 프론트, 백엔드가 합쳐진 서버 사이드 렌더링 SPA 앱이 만들어졌다.

참고 자료

[번역] 자바스크립트 반응성(Reactivity)에 대한 가장 좋은 설명

rhostem — Wed, 12 Sep 2018 00:00:00 GMT

Gregg Pollack의 The Best Explanation of JavaScript Reactivity 🎆를 번역한 글이다.

SPA 프레임워크에서 컴포넌트의 상태가 변경되면 렌더링이 다시 실행되는 것처럼, 객체의 속성이 변경될 때 어떤 코드가 자동으로 실행되게 한다면 그 애플리케이션은 반응적이라고 할 수 있다. 이를 구현하기 위해서 Object.defineProperty 함수를 사용해 getter, setter 함수를 다시 할당하는 방법을 설명하는 글이다.

많은 프론트엔드 자바스크립트 프레임워크(Angular, React, Vue, etc)는 자신만의 반응성(Reactivity) 엔진을 가지고 있다. 반응성이 무엇인지, 어떻게 동작하는지를 이해함으로써 당신의 개발 기술을 향상할 수 있고 자바스크립트 프레임워크를 보다 효율적으로 사용할 수 있다. 아래의 영상과 비디오를 통해 우리는 Vue 소스 코드에서 확인할 수 있는 것과 같은 종류의 Reactivity를 구현할 것이다.

글을 읽는 대신 비디오를 시청하고 싶다면 이 시리즈의 다음 영상을 보면서 Vue를 만든 Evan You와 함께 반응성과 프록시에 대해 토론하는 내용을 확인하길 바란다.

반응성 시스템

Vue의 반응성 시스템을 처음 보면 마치 마법처럼 느껴질 수 있다. 간단한 Vue 앱을 확인해보자.

Vue가 만약 price 값이 변했다는 사실을 알게 된다면 아래 3가지 일을 할 것이다.

웹페이지의 price 값을 업데이트한다.
price * quantity 를 다시 계산하고 페이지를 업데이트한다.
totalPriceWithTax 함수를 다시 호출하고 페이지를 업데이트한다.

하지만 잠깐, 당신은 이런 의문을 가지게 될 것이다. Vue는 price가 변경되면 무엇을 업데이트해야 하는지 어떻게 알며, 어떻게 모든 것을 추적하고 있는가?

Vue가 하는 일은 자바스크립트가 일반적으로 동작하는 방식이 아니다.

다시 말해, 우리가 의문을 가지고 있는 문제는 일반적인 프로그램 동작 방식이 아니라는 말이다. 예를 들어 만약 아래의 코드를 실행한다면:

무엇이 출력될 것으로 생각하는가? 보통의 자바스크립트 코드라서 10을 출력할 것이다.

Vue에서는 우리는 price나 quantity가 업데이트되면 total도 업데이트되길 바란다. 바로 다음과 같이 출력되길 원한다:

하지만 불행히도 자바스크립트는 반응형이 아니라 절차적(procedural) 언어라서 우리가 기대하는 기능을 바로 제공하지 않는다. total 변수가 반응적이 되도록 만들기 위해서는 자바스크립트를 다른 접근 방식이 필요하다.

⚠️ 문제

total 값을 계산하는 코드를 저장해 둘 필요가 있고, price나 quantity 값이 바뀔 때마다 그 코드를 다시 실행해야 한다.

✅ 해결책

우선 우리의 애플리케이션에게 다음의 메시지를 전달할 방법이 필요하다, “내가 실행하려는 코드가 하나 있는데, 이걸 저장해 둬. 나중에 네가 다시 실행할 필요가 생길거야”. 그런 일이 가능하다면 우리는 코드를 한번 실행한 후에, price나 quantity 값이 바뀔 때 앞서 저장된 코드를 다시 실행하면 된다.

이는 함수를 기록하는 방법을 통해 구현할 수 있다.

target 변수에 익명 함수를 할당해서 재실행할 코드를 저장하고, record 함수를 호출했다. ES6 화살표 함수를 사용하면 아래처럼 작성할 수 있다.

함수 record는 간단히 아래처럼 정의한다.

storage 배열에 target 함수를 저장한다.

target (코드에서는 { total = price * quantity })을 저장했으니 나중에 다시 실행할 수 있다. 저장한 모든 함수를 실행할 replay 함수가 필요할 것이다.

replay 함수를 실행하면 storage 배열에 저장한 모든 익명 함수를 실행한다.

이제 간단히 다음처럼 하면 된다.

간단하지 않은가? 아래의 코드를 통해 전체 흐름을 다시 한 번 살펴보기 바란다.

⚠️ 문제

필요한 만큼 target을 기록해 둘 수 있지만, 앱의 확장성을 위해 보다 강력한 솔루션을 만드는 편이 좋을 것이다. target 목록을 유지하면서 우리가 필요할 때 재실행할 수 있도록 알려주는 클래스 같은 것 말이다.

✅ 해결책: 의존 클래스

이 문제를 해결할 수 있는 방법 하나는 위의 동작을 표준 프로그래밍 옵저버(observer) 패턴을 구현하는 의존 클래스로 캡슐화(encapsulation)하는 것이다.

그래서, target 같은 종속물(dependencies)을 관리하기 위해 자바스크립트 클래스를 만든다면 아래와 같은 형태가 될 것이다.

class Dep { // dependency의 약자
  constructor() {
    this.subscribers = []
    // subscribers는 클래스에 종속되어 있는 target 함수들을 저장하는 배열.
    // notify() 메소드가 호출되면 배열에 저장된 함수들이 실행되어야 한다.
  }

  depend() { // 앞서 작성한 record 함수를 대체한다.
    if (target && !this.subscribers.includes(target)) {
    // target이 subscribers에 저장되어 있지 않아야 한다.
      this.subscribers.push(target)
    }
  }

  notify() { // 앞서 작성한 replay 함수를 대체한다.
    this.subscribers.forEach(sub => sub()) // target 또는 observer를 실행한다.
  }
}

이제 storage 대신 subscribers에 익명 함수를 저장하며, record 함수 대신 depend 함수를 사용한다. 그리고 replay 함수 대신 notify 함수를 사용한다. 이 클래스를 작동시켜 보자.

const dep = new Dep() // 인스턴스 생성

let price = 5
let quantity = 2
let total = 0
let target = () => { target = price * quantity }

dep.depend() // subscribers에 target 함수를 추가한다.
target()     // target 함수를 실행한다.

console.log(total) // => 10 .. 원하는 결과가 맞다.
price = 20
console.log(total) // => 10 .. total이 자동으로 업데이트 되지 않았다.
dep.notify()       // subscribers에 등록된 함수들을 실행한다.
console.log(total) // => 40 .. 제대로 된 결과를 얻었다.

잘 작동한다. 이제 우리의 코드를 재사용할 수 있을 것 같다. 여전히 이상하게 느껴지는 건 target을 등록하고 실행하는 방식이다.

⚠️ 문제

개발이 진행되면 변수마다 Dep 클래스를 생성하게 될 것이다. 그리고 업데이트를 감지하는 역할을 하는 익명 함수(target)를 생성하는 과정을 캡슐화하면 좋을 것 같다. watcher 함수가 이런 역할을 할 수 있다.

그러면 아래의 코드를 실행하는 대신:

아래처럼 실행할 수 있다:

✅ 해결책: Watcher 함수

Watcher 함수 내부에서 몇가지 간단한 작업을 할 수 있다.

function watcher(myFunc) {
  target = myFunc  // 현재 처리하고 있는 target으로 myFunc을 설정한다.
  dep.depend()     // target을 종속물(=종속된 코드)로 추가한다.
  target()         // target을 실행한다.
  target = null    // target을 초기화한다.
}

확인할 수 있는 것처럼 watcher 함수는 myFunc를 인자로 전달받고, 전역 변수인 target으로 할당하고, dep.depend()를 호출해서 subscriber에 추가하고, target을 호출한다. 그리고 target를 초기화한다.

당신은 아마 왜 target을 함수에 직접 전달하지 않고 전역 변수로 설정했는지 궁금할 것이다. 이렇게 구현한 데에는 이유가 있으며, 이 글의 다 읽으면 그 이유가 명확해지고 좋은 방법이었다는 것을 알게 될 것이다.

⚠️ 문제

우리는 하나의 Dep 클래스를 가지고 있다. 하지만 우리가 정말로 원하는 것은 변수마다 그만의 Dep 클래스를 가지는 것이다. 더 진행하기 전에 값들을 객체의 속성으로 옮기도록 하자.

각각의 속성(price와 quantity)이 각각 Dep 클래스를 가지고 있다고 잠시동안 가정해보자.

이제는 아래의 코드를 실행한다.

watcher에 전달된 익명 함수(target) 내부에서 data.price 값이 사용되었다. 재실행할 코드에서 data.price 값이 사용되고 있으니 price 속성에 연결된 Dep 클래스의 subscriber 배열(저장소)에 이 익명 함수를 추가(dep.depend())하고 싶다. 익명 함수 내부에서 data.quantity 값도 사용되었으니 data.quantity에 연결된 Dep 클래스에도 같은 작업을 하고 싶다.

만약 data.price를 참조하는 또 다른 익명 함수를 가지고 있다면, 그 함수는 price 속성의 Dep 클래스에만 추가하고 싶다.

추가되는 watcher는 속성들 중 하나에만 적용될 것이다

어느 시점에 price의 subscriber에 연결된 dep.notify()가 호출되어야 할까? 나는 그 순간이 price 속성에 값이 할당되었을 때가 되길 바란다. 모든 것이 구현되면 콘솔에서 아래와 같은 출력을 보고 싶다.

우리는 data 속성(price나 quantity)에 원하는 동작을 연결할(hook into) 어떤 방법이 필요하다. 그러면 target 함수 내부에서 어떤 속성이 참조되면 그 속성의 subscriber 배열에 target을 저장할 수 있고, 속성이 변경되면 subscribers 배열에 저장된 함수를 실행하도록 만들 수 있다.

✅ 해결책: Object.defineProperty()

ES5에서 제공하는 Object.defineProperty 함수에 대해 공부할 필요가 있다. 이 함수는 우리에게 객체 속성의 getter와 setter 함수를 정의할 수 있도록 한다. 이 함수를 Dep 클래스에 적용하기 전에 기본적인 사용법을 살펴보자.

let data = { price: 5, quantity: 2 }

Object.defineProperty(data, 'price', { // data의 price 속성에 대해서만 정의한다.
  get() { // get 함수 생성. price의 값을 참조하는 역할
    console.log('I was accessed')
  }

  set(newValue) { // set 함수 생성. price에 새로운 값을 할당하는 역할
    console.log('I was changed')
  }
})

보이는 바와 같이 단지 2줄이 로그에 표시된다. 하지만 실제로는 어떤 값도 가져오거나(get) 할당하지(set) 않는다. 우리가 get, set 함수를 새로 덮어씌웠기 때문이다. 그러니 다시 필요한 코드를 추가하도록 하자. get() 함수는 값을 반환해야 하고, set() 함수는 값을 갱신해야 한다. 그를 위해 intervalValue라는 변수에 현재 price값을 저장한다.

internalValue에서 실제 값을 관리한다.

이제 우리의 get, set 함수는 제대로 동작한다. 콘솔에는 무엇이 출력될까?

이렇게 값을 가져오고(get) 할당할 때(set) 알림을 받을 수 있게 되었다. 그리고 재귀(recursion)를 조금 사용하면 모든 속성에서 이 기능이 작동하도록 할 수 있을 것이다.

Object.keys 함수를 사용해서 data 객체에 존재하는 모든 속성에 같은 기능을 적용했다

이제 모든 속성이 getter와 setter 함수를 가지게 된 것을 콘솔에서 확인할 수 있다.

🛠 지금까지의 아이디어를 합치기

위의 코드처럼 price의 값을 사용(get)한다면, 위의 코드(target)가 price 값에 의존하고 있다는 사실을 기록해두고 싶다. 그렇게 해 둔다면 price 값의 변경이나 새로운 값의 할당이 저장해둔 코드를 재실행할 수 있는 계기(trigger)가 되도록 만들 수 있다. 우리의 애플리케이션은 어떤 코드가 price에 의존하고 있는지 알고 있기 때문이다. 따라서 getter와 setter를 아래처럼 동작하도록 생각할 수 있다.

Get => 이 익명 함수를 기억해라, 값이 변경될 때 다시 실행할 것이다.

Set => 저장된 익명 함수를 실행해라. 값은 방금 변경되었다.

Dep Class의 경우에는

Price가 사용되었다 (get) => dep.depend() 함수를 호출해서 현재 target을 저장해라.

Price가 할당되었다 (set) => price의 dep.notify()를 해서 모든 targets를 재실행해라.

이 두가지 아이디어를 조합한 최종 코드를 살펴보자.

let data = { price: 5, quantity: 2 }
let target = null

// 앞에서 선언한 Dep 클래스와 동일하다.
class Dep {
  constructor() {
    this.subscribers = []
  }

  depend() {
    if (target && !this.subscribers.includes(target)) {
      // target이 존재하며 subscribers에 포함되어 있지 않을 때만 추가한다.
      this.subscribers.push(target)
    }
  }

  notify() {
    this.subscribers.forEach(sub => sub())
  }
}

// data 객체가 가지고 있는 모든 속성에 적용한다
Object.keys(data).forEach(key => {
  let internalValue = data[key]

  // 각각의 속성은 자기만의 Dep 클래스 인스턴스를 가진다.
  const dep = new Dep()

  // data 객체 속성의 getter, setter를 재설정한다.
  Object.defineProperty(data, key, {
    get() {
      // getter가 호출된 시점의 target을 기억하도록 한다.
      dep.depend()
      return internalValue
    },
    set(newVal) {
      internalValue = newVal
      dep.notify() // 저장된 함수(target)를 재실행
    }
  })
})

// watcher는 더 이상 dep.depend를 호출하지 않는다.
// 왜냐하면 get 메소드 안에서 자동으로 호출되기 때문이다.
function watcher(myFunc) {
  target = myFunc
  target() // 할당된 코드는 무조건 1번은 실행되어야 한다.
  target = null
}

// watcher에 전달된 이 익명함수에서 price와 quantity의 getter 함수가 실행된다.
// watcher가 실행된 시점에서 전역 변수 target에는 watcher의 인자로 전달된 익명 함수가 할당된다
watcher(() => {
  data.total = data.price * data.quantity
})

이제 코드를 실행하면 콘솔에 무엇이 출력되는지 확인해보자.

우리가 하고 싶었던 것과 정확히 일치한다! price와 quantity 모두 확실히 반응한다! watcher 함수에 전달한 익명 함수는 price 또는 quantity 값이 변경될 때마다 재실행되고 있다.

Vue 문서에서 가져온 이 그림은 이제 이해가 될 것이다.

Data와 getter, setter를 가지고 있는 아름다운 보라색 동그라미가 보이는가? 아마 익숙하게 보일 것이다! 모든 컴포넌트 인스턴스는 getter를 통해 종속물을 수집하는(붉은 점선) watcher 인스턴스(파란색)를 가지고 있다. setter가 호출되면 Data는 watcher에게 알림(Notify)을 보내서 컴포넌트 re-render로 이어지게 한다. 아래는 내가 주석을 추가한 그림이다.

어떤가, 이쪽이 우리가 지금까지 살펴본 코드를 떠올리게 하면서 더 잘 와닿지 않는가??

사실 Vue의 반응성 엔진은 이것보다 훨씬 더 복잡하다. 하지만 당신은 이제 기초를 알게 되었다.

⏪ 지금까지 학습한 내용

종속물(종속된 코드, dependencies)를 수집하는(depend) Dep class를 어떻게 선언하고, 어떻게 의존 코드를 재실행하는지(notify)
종속물로 추가될 수 있는 실행 코드(target)를 관리하기 위해 watcher를 어떻게 생성하는지.
getter와 setter를 생성하기 위해 Object.defineProperty()를 어떻게 사용하는지

이 다음은?

이 글을 통해 배운 내용에 흥미를 느꼈다면 다음 단계는 Reactivity with Proxies다. 그리고 내가 Vue 개발자인 Evan You와 함께 이 주제에 대해서 이야기하는 무료 동영상도 VueMastery.com에서 꼭 확인해 보길 바란다.

MongoDB 원격 접속 설정

rhostem — Thu, 30 Aug 2018 00:00:00 GMT

Amazon Lightsail

Amazon Lightsail은 저렴한 가격으로 클라우드 서버를 사용할 수 있다. 메모리 512MB의 최소 사양 인스턴스는 3.5달러밖에 하지 않기 때문에 테스트나 학습용으로 사용하기 좋다. 운영체제는 Ubuntu 16.04 버전을 선택해서 사용했다.

MongoDB 설치

공식 홈페이지의 설치 가이드를 단계별로 따라가면 쉽게 설치할 수 있다. 나는 .deb 패키지를 사용하는 방법으로 진행했다. 설치한 MongoDB 버전은 4.0.2였다.

데이터베이스 폴더 설정

데이터베이스 사용을 위해서는 데몬 프로세스 mongod를 실행해야 하는데, 그 전에 데이터를 저장할 폴더를 만들어야 한다. MongoDB의 기본 데이터베이스 폴더는 /data/db로 지정되어 있으니 루트 권한으로 폴더를 만들어야 한다. 폴더가 만들어지면 MongoDB를 설치하면서 등록된 시스템 서비스를 실행한다.

sudo mkdir /data/db
sudo service mongod start

서비스 실행 후 mongo 쉘을 실행할 수 있으면 로컬에서 데이터베이스를 사용할 준비가 된 것이다.

mongo

원격 접속 설정

설치 직후의 데이터베이스는 인증 없이 사용할 수 있고, 설치된 기기에서만 접속 가능하다. 원격 접속이 가능하도록 하려면 사용자를 추가하고 네트워크 관련 설정을 수정해야 한다.

사용자 생성

사용자 생성은 mongo 쉘에 접속해서 한다. mongo 쉘은 MongoDB의 자바스크립트 인터페이스로서 명령어 실행과 함수 호출을 통해 데이터베이스를 수정할 수 있는 기능을 제공한다.

사용자 정보는 기본적으로 admin 데이터베이스에 저장한다. MongoDB는 사용자 정보가 저장된 데이터베이스가 아닌 다른 데이터베이스에 대한 권한을 부여할 수도 있다. 이를 Role-Based Access Control이라고 한다.

데이터베이스를 선택하고, 사용자를 생성하는 함수를 호출하도록 하자.

use admin # admin 데이터베이스 선택

db.createUser({
  user: "dbadmin",  # 계정 이름
  pwd: "password",  # 비밀번호
  roles: [          # 사용자에게 주어진 권한 목록. 여러 데이터베이스에 대한 권한을 할당할 수 있다.
    {
      role: "root", # built-in 권한인 root. 문자 그대로 모든 데이터베이스를 관리할 수 있다.
      db: "admin"   # 어떤 데이터베이스에 대한 권한인지 명시
    }
  ]}
)

그리고 관리자가 아닌 사용자를 생성해서 실제 작업에 사용하도록 한다.

db.createUser({
  user: "rhostem",
  pwd: "password",
  roles: [
    {
      role: "readWrite", # 읽기, 쓰기 권한
      db: "test"         # 위의 권한을 부여할 데이터베이스로 test를 지정
    }
  ]}
)

`mongod.conf` 파일 설정

사용자를 생성했으니 데이터베이스에 접속할 때 인증이 필요하도록 수정해야 한다. 서비스가 사용하고 있는 설정 파일은 아래의 명령어로 확인할 수 있다. 아래 로그에서 확인할 수 있듯이 Ubuntu에서는 /etc/mongod.conf 파일을 수정하면 된다.

service mongod status

● mongod.service - MongoDB Database Server
   Loaded: loaded (/lib/systemd/system/mongod.service; disabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-08-30 00:00:00 UTC; 2s ago
     Docs: https://docs.mongodb.org/manual
 Main PID: 4376 (mongod)
    Tasks: 26
   Memory: 138.1M
      CPU: 1.053s
   CGroup: /system.slice/mongod.service
           └─4376 /usr/bin/mongod --config /etc/mongod.conf
           # MongoDB 데몬 프로세스의 옵션 파일을 지정하는 --config가 사용되어 있다.

데이터베이스 접속이 인증이 필요하도록 하려면 security 섹션을 아래처럼 수정한다.

security:
  authorization: enabled

그리고 net 섹션의 bind_ip 항목도 수정해야 한다. 기본 설정은 로컬에서만 접속할 수 있도록 127.0.0.1로 되어 있는데, 모든 아이피에서 접속할 수 있도록 0.0.0.0으로 변경한다.

net:
  port: 27017
  bindIp: 0.0.0.0

TCP 포트 개방

설정에서도 확인할 수 있지만 MongoDB는 기본적으로 27107번 포트를 사용한다. 따라서 외부에서 접속할 수 있도록 방화벽 설정을 통해 27017번 포트를 개방해야 한다. 나는 Amazon Lightsail 인스턴스를 사용했기에 웹에서 간편하게 설정할 수 있었다. 인스턴스의 네트워킹 탭에 항목을 추가하면 된다.

TCP 프로토콜 27017 포트를 개방했다

접속 명령어

우선 사용자가 설정되었는지 확인하기 위해 서버에서 mongo 쉘에 접속을 시도해본다. -p 옵션 다음에는 비밀번호를 입력해야 하지만 비워두면 입력을 위한 프롬프트가 뜬다.

authenticationDatabase 옵션은 사용자의 정보가 저장된 데이터이스를 가리키기 위한 것이다. 앞서 사용자를 추가할 때 사용한 admin 데이터베이스를 입력한다.

sudo mongo -u dbadmin -p --authenticationDatabase admin

MongoDB shell version v4.0.2
Enter password: <패스워드 입력>

접속에 성공했다면 이제 서버에서 로그아웃한 후 원격 접속이 가능한지 시도해보자. 앞의 명령어에 host 옵션만 추가하면 된다. host에는 서버의 IP 주소 또는 도메인을 입력하면 된다.

mongo -u dbadmin -p --host <아이피 또는 도메인> --authenticationDatabase admin

접속이 성공했다면 원격으로 데이터베이스를 사용할 준비가 된 것이다. 이제 node.js 서버 앱에서 Mongoose 같은 모듈을 사용해 데이터베이스를 사용할 수 있다.

(Mac 또는 Windows의 커맨드라인에서 데이터베이스에 원격 접속하기 위해서는 MongoDB가 설치되어 있어야 한다. 그렇지 않다면 MongoDB를 위한 GUI 도구를 사용하면 된다.)

기타 설정

시스템 재시작 시 MongoDB를 자동으로 실행하도록 설정

서버를 재시작하면 실행 중인 mongod 프로세스도 종료된다. 시스템 시작과 함께 서비스가 실행되도록 crontab을 사용해서 작업을 등록할 수 있다. crontab은 Linux 운영체제가 특정 시점에 특정 명령어를 실행하도록 할 수 있는 기능이다. 아래의 명령어로 crontab 파일을 연다.

crontab -e

맨 아래쪽에 재부팅 시점에 실행할 명령어를 추가한다.

@reboot sudo service mongod start

파일을 저장하고 나왔을 때 아래의 메시지가 표시되면 등록된 것이다.

crontab: installing new crontab

데이터베이스 접속을 위한 쉘 스크립트 작성

git 저장소에서 작업하고 있다면 쉘 스크립트에 비밀번호가 노출되면 안 되므로 별도의 파일에 저장해서 관리하는 편이 보안상 좋다. 예를 들어 비밀번호를 .dbpasswd 파일에 저장했다면 해당 파일은 .gitignore 파일에 등록하고 쉘 스크립트를 아래와 같이 작성한다.

# connect-db.sh

passwd=$(<.dbpasswd) # 변수 passwd에 .dbpasswd 파일의 내용을 할당.
mongo -u rhostem -p $passwd --host db.host.name --authenticationDatabase admin

참고자료

블로그 검색 기능 개발 과정

rhostem — Thu, 23 Aug 2018 00:00:00 GMT

블로그를 만든 지 거의 2년이 다 되어가고 작성한 포스트도 어느덧 20개를 넘었다. 콘텐츠가 쌓이니 자연스럽게 ‘검색’ 기능을 붙이고 싶은 욕심이 들었다. Gatsby를 사용해서 만든 블로그라서 플러그인을 검색해 보니 역시 검색 기능을 구현한 것이 있었다. 자바스크립트 기반의 검색 엔진인 Elasticlunr.js를 사용한 플러그인이었는데, 테스트해 보니 안타깝게도 한글 문장은 인덱싱되지 않았다. 그래서 공부도 할 겸 직접 구현하기로 했다.

자체 검색 엔진 구현

우선 검색 기능에 대한 요구 사항을 정리해 보았다.

Github pages에 호스팅 된 정적인(static) 사이트라서 검색은 브라우저에서 진행되어야 한다.
클라이언트 사이드 검색이므로 인덱싱 파일은 크기가 가능한 한 작아야 한다.
영어 및 한글도 검색 가능해야 한다.
검색 결과에는 매칭된 포스트 제목과 태그를 표시해야 한다.

node.js에서 검색을 위한 콘텐츠 인덱싱 진행

콘텐츠를 단어를 추출한 후 단어와 그 단어를 포함한 페이지를 매칭시킨 역색인을 구성하는 방법을 사용했다. 처음에는 문장 검색을 위해 글자를 하나하나 분리하고 인접한 단어 정보를 저장해서 검색 결과와 함께 문장을 다시 구성할 수 있도록 하려고 했었다. 그런데 그 과정에서 인덱싱 파일의 크기가 너무 커져 버렸고 효율도 좋지 않았다. 결국, 단어 단위의 역 인덱스로 내가 할 수 있는 구현을 하자는 쪽으로 방향을 틀었다.

인덱싱 데이터 구성은 node.js 환경에서 아래의 과정을 통해 진행된다.

콘텐츠가 포함된 모든 마크다운(md) 파일을 가져온다.
마크다운에서 YAML 형식으로 작성된 front matter 영역과 본문을 분리한다.
remark 라이브러리로 콘텐츠 본문을 텍스트로 변환한다.
본문 텍스트에서 단어를 분리하고 포스트 경로로 매핑하는 단어 맵을 만든다.
front matter에서는 제목, 태그 정보를 추출한다.
검색에 필요한 데이터를 JSON 파일로 저장한다.

인덱싱 파일을 생성하면 아래과 같은 형태가 된다.

{
  "wordList": [
    "[번역]",
    "자바스크립트",
    "피로감을",
    ...
  ],
  "wordMap": {
    "@_[번역]": { "r": [1, 4, 5, 9, 10, 11, 15, 18, 20, 24, 26] },
    "@_자바스크립트": { "r": [1, 2, 4, 8, 15, 18, 20, 24, 26, 27] },
    "@_피로감을": { "r": [1] },
    ...
  },
  "routeMap": {
    "1": {
      "route": "/posts/2016-12-19-A-Study-Plan-To-Cure-JavaScript-Fatigue",
      "title": "[번역] 자바스크립트 피로감을 줄여주기 위한 학습 계획",
      "tags": ["번역", "JavaScript", "React", "Redux", "Gatsby", "ES"]
    },
    ...
  },
  "tagList": [
    "번역",
    "JavaScript",
    "React",
    ...
  ]
}

사용자의 검색어를 입력받으면 wordList와 tagList에서 매칭되는 단어를 찾은 후 routeMap에 저장된 정보를 활용해서 결과를 보여주는 방식이다. 실제 검색 로직에서는 결과 정렬을 위한 랭킹 점수 부여 등의 과정이 추가된다.

콘텐츠의 총글자 수가 약 35만 자인 상태에서 인덱싱 파일을 생성하니 그 크기가 350KB 정도로 브라우저에서 충분히 감당할 수 있을 정도였다. gzip으로 인코딩하면 100KB까지 줄어든다. 하지만 그 크기는 점점 커질 테니, 인덱싱 데이터를 서비스 워커를 사용해서 미리 불러오도록 했다.

서비스 워커(Service Worker)를 사용한 검색 데이터 캐싱

서비스 워커는 브라우저의 백그라운드에서 동작하면서 웹앱과 브라우저, 네트워크 사이의 프락시 역할을 한다. 원격 데이터를 호출하는 fetch 이벤트를 감지해서 특정 네트워크 요청에 대한 응답을 캐싱하는 등의 작업이 가능하다. 그리고 웹앱에 필요한 리소스를 내려받아서 CacheStorage에 저장해서 재방문 시 빠르게 가져올 수 있도록 한다. (서비스 워커를 사용하면 백그라운드 동기화도 가능하지만 아직은 크롬 브라우저에서만 가능한 기술이다) 이를 바탕으로 네트워크가 불안하거나 오프라인인 상태에서도 앱이 구동할 수 있도록 할 수 있다. 네트워크 요청을 하지 않는 앱이라면 네이티브 앱과 다를 바가 없게 되는 것이다.

검색 기능을 구현하면서 서비스 워커를 사용해서 덩치가 큰 인덱싱 파일을 CacheStorage에 저장했다. 이런 기능을 간편히 사용하기 위한 라이브러리에는 sw-precache가 있다. Gatsby에는 이를 바탕으로 한 플러그인이 이미 존재하고 있으며, 나도 사용하고 있었다. gatsby-plugin-offline이 그것인데, 기본 옵션만 사용해도 웹사이트 데이터를 잘 캐싱해준다. 이 플러그인의 추가 옵션을 살짝 수정해서 덩치가 큰 인덱싱 파일도 저장하도록 했다.

const rootDir = 'public'

...

{
  resolve: 'gatsby-plugin-offline',
  options: {
    staticFileGlobs: [
      `${rootDir}/search/*.json`, // 검색 인덱싱 파일 추가
      `${rootDir}/**/*.{woff2}`,
      `${rootDir}/commons-*js`,
      `${rootDir}/app-*js`,
      `${rootDir}/index.html`,
      `${rootDir}/manifest.json`,
      `${rootDir}/manifest.webmanifest`,
      `${rootDir}/offline-plugin-app-shell-fallback/index.html`,
    ],
  },
},

...

최초 방문

재방문

스크린 샷을 살펴보면 searchIndex.json 파일을 가져오는 데 걸리는 시간이 처음에는 118ms지만 재방문했을 때는 서비스 워커를 통해 10ms가 걸렸다. 1/10 정도로 많이 줄어들었다는 사실을 확인할 수 있다.

웹 워커(Web Worker)를 사용한 검색

자바스크립트는 싱글 스레드라고 알고 있는 사람들이 많지만, 웹 워커(Web Workers)를 사용하면 멀티 스레드 프로그래밍이 가능하다. 그리고 서비스 워커보다는 브라우저 지원 폭이 넓어서 인터넷 익스플로러 9를 반드시 지원해야 하는 웹사이트가 아니라면 사용해도 된다. 웹 워커를 사용하면 좋은 사례에는 다음과 같은 것들이 있다.

Ray tracing(이미지 렌더링 기술)
암호화
데이터 prefetching
Progressive Web App
문법 검사
타이머

상대적으로 큰 데이터를 처리해야 해서 검색 로직 구현에도 웹 워커를 사용하기로 했다. 하지만 웹 워커와 메인 스레드 사이의 통신을 위해서는 postMessage를 사용해서 데이터를 보내고, onmessage 이벤트 핸들러에서 데이터를 받아서 처리해야 한다. 워커에 의미 있는 이름을 가진 메소드를 추가해서 보다 가독성 있는 방법으로 통신할 방법은 아직은 없다. 이를 개선하기 위한 comlink라는 라이브러리가 있긴 하다. 하지만 나는 redux에서 하는 것처럼 정형화된 데이터를 주고받는 방식으로 구현했다.

// 메인 스레드 소스 코드
let searchWorker
if (window.Worker && !searchWorker) {
  // 웹 워커 등록
  searchWorker = new Worker('/js/search-worker.js')
}

const searchService = {
  // 검색
  find: (searchInput = '') => {
    searchWorker.postMessage({
      action: 'SEARCH_REQUEST',
      payload: {
        searchInput,
      },
    })
  },
}

// 웹 워커 소스 코드
onmessage = function(e) {
  var action = e.data.action
  var payload = e.data.payload

  switch (action) {
    case 'SEARCH_REQUEST':
      search(payload.searchInput)
      break

    default:
      break
  }
}

function search(input) {
  ...
}

이런 식으로 스레드 간에 데이터를 주고받을 수 있다. 위의 코드에서는 메인 스레드에서 메시지를 보내고, 웹 워커에서 메시지를 받는 과정이 표현되어 있지만 당연히 반대로도 가능하다.

웹 워커를 사용해서 350KB 크기의 데이터를 검색하는 데 보통 0.15~0.2초가 걸렸다.

Node.js, 브라우저, 웹 워커에서 함께 사용할 모듈 작성

검색 기능을 구현하는 과정에서 node.js, 브라우저, 웹 워커에서 공통으로 사용해야 하는 로직이 발견되었다. 인덱싱과 검색 과정에서 문장과 단어의 불필요한 문자를 제거하는 기능이 대표적이다. 그리고 웹 워커를 사용하니 스레드 간의 메시지를 구분할 때 사용하는 enum 역할을 하는 문자열도 일치시킬 필요가 생겼다.

하지만 세 환경에서는 모듈을 사용하는 방식이 서로 다르다. node.js에서는 모듈을 사용하기 위해 자체 모듈인 module, require를 사용하지만, 브라우저와 웹 워커에서는 사용할 수 없다. 브라우저에서는 Webpack과 ES6의 export, import를 사용한다. 그리고 웹 워커에서는 importScripts 함수를 통해 외부 스크립트 내부에서 할당한 전역 객체를 사용해야 한다.

이 3가지 환경에서 모두 사용할 수 있는 모듈 선언 방식이 UMD (Universal Module Definition) 패턴이다. 링크된 Github 저장소의 templates 폴더에는 여러 사례에 대한 예제 코드가 작성되어 있다. 검색 엔진을 위한 모듈 작성에는 returnExports.js 예제를 활용했다.

// searchUtil.js
// 즉시 실행 함수(IIFE) 형태로 선언한다. factory는 모듈 객체를 반환하는 함수다.
;(function(root, factory) {

  // webpack을 위한 AMD 모듈 선언 방식,
  // webpack은 AMD, CommonJS 방식 둘 다 지원한다.
  if (typeof define === 'function' && define.amd) {
    define(null, factory)

  // node.js에 해당하는 케이스
  } else if (typeof module === 'object' && module.exports) {
    module.exports = factory()

  // 모듈 객체를 전역 컨텍스트에 할당. 웹 워커와 브라우저에서 사용할 수 있다.
  } else {
    root.searchUtil = factory()
  }
})(this, function() {
  // 모듈 객체
  return {
    actions: {
      SEARCH_REQUEST: 'SEARCH_REQUEST',
    },
    trimText: function(str) {
      ...
    },
  }
})

이렇게 선언된 모듈은 각각의 환경에 맞는 방식으로 불러와서 사용할 수 있다.

// node.js에서 사용
const { actions } = require('../static/js/searchUtil')

// ES6 모듈에서 사용
import { actions } from '../static/js/searchUtil'

// 웹 워커에서 사용
importScripts('./searchUtil.js')

console.log(searchUtil.actions.SEARCH_REQUEST)

향후 개선 방향

검색 기능을 구현하긴 했지만 말 그대로 동작할 정도로만 만들어 두었을 뿐이다. 검색어가 입력되면 단어 목록 전체를 살펴보기 때문에 현재 O(n)의 검색 시간이 걸리는 상태다. 이를 개선하기 위해서는 당장 생각하는 방법으로는 단어를 초성이나 글자별로 그룹화해서 일부만 찾아보는 방식이 있겠다. 검색 결과 캐싱, 랭킹 부여 방식도 개선 등 고칠 점이 많으니 천천히 시도해 볼 생각이다.

[번역] 웹 아키텍쳐 입문

rhostem — Sat, 28 Jul 2018 00:00:00 GMT

이 글은 Jonathan Fulton의 Web Architecture 101을 번역한 글입니다.

모던 웹 애플리케이션 아키텍쳐 개요

위의 다이어그램은 우리 Storyblocks의 아키텍쳐를 꽤 잘 나타낸다. 당신이 경험 많은 웹 개발자가 아니라면 아마도 꽤 복잡하다고 생각할 것이다. 각각의 컴포넌트를 자세히 살펴보기 전에 아래의 글을 살펴보면 조금 더 다가서기 쉬워질 것이다.

사용자가 구글에서 “짙고 아름다운 안개와 숲 속의 햇살”을 검색한다. 첫 번째 결과는 Storyblocks, 우리의 메인 사진 저장 및 벡터 사이트에서 나온다. 사용자는 결과를 클릭하고 브라우저는 사진 상세 페이지로 이동한다. 보이지 않지만, 브라우저 내부에서는 DNS 서버에 Storyblocks에 어떻게 접속할 수 있는지 물어본 후 Storyblocks에 접근을 시도한다.

브라우저의 요청은 우리의 로드 밸런서에 도착하고, 서비스를 운영하기 위해 동작 중인 10여 개의 서버 중 하나를 랜덤하게 선택해서 요청을 처리한다. 웹 서버는 캐싱 서비스에서 필요한 이미지 정보를 가져온 후 더 필요한 정보는 데이터베이스에 요청한다. 사용자에게 전달한 이미지의 컬러 프로필이 아직 만들어지지 않았음을 인지한 후 “컬러 프로필” 잡(job)을 잡 큐에 보낸다. 잡 서버는 큐에 추가된 것들을 비동기적으로 처리한 후 데이터베이스에 결과를 적절히 업데이트한다.

다음, 우리는 전체 텍스트(full-text) 검색 서비스에 사진의 제목을 전달해서 비슷한 사진들을 찾으려고 한다. 사용자가 Storyblocks의 멤버로 로그인했다면 그의 계정 정보를 계정 서비스에서 가져온다. 일련의 작업들이 끝난 후, 데이터 firehose에 페이지 뷰 이벤트를 발생시켜서 우리의 클라우드 스토리지 시스템에 기록하고, 그 정보는 분석가들이 비즈니스와 관련된 질의에 답하는 데 사용할 수 있도록 데이터 저장소(warehouse)에서 사용된다.

서버는 이제 HTML로 화면을 렌더링한 후 로드 밸런서를 통해서 사용자의 브라우저로 보낸다. 페이지는 CDN에 연결된 우리의 클라우드 스토리지 시스템에서 가져오는 자바스크립트와 CSS 파일을 포함하고 있다. 그래서 브라우저는 그 콘텐츠를 가져오기 위해 CDN에 접속한다. 마지막으로, 브라우저는 사용자가 볼 수 있는 콘텐츠를 렌더링한다.

이제 나는 각각의 컴포넌트들을 하나씩 소개할 것이다. 이는 당신이 앞으로 웹 아키텍쳐에 대해 생각해 볼 때 도움이 될 수 있는 좋은 심리 모델을 선사할 것이다. 나중에는 다른 시리즈의 글을 통해서 Storyblocks에서 얻은 경험을 바탕으로 추천하는 구체적인 구현 방법을 제공할 생각이다.

1. DNS

DNS는 “Domain Name Server”의 약자며 월드 와이드 웹(WWW)이 가능하도록 만드는 기반 기술이다. 가장 기본적인 레벨의 DNS는 도메인 이름(예. google.com)에서 IP 주소(예. 85.129.83.120)로의 키/값 조회를 제공한다. 이는 당신의 컴퓨터가 알맞은 서버에 요청을 보낼 수 있는 경로를 찾는 데 필요하다. 전화번호에 비유하자면 도메인 이름과 IP 주소의 차이는 “Jone Does에게 전화하기”와 “201-867–5309에 전화하기”의 차이다. Jone의 전화번호를 찾기 위해 전화번호부가 필요한 것처럼 도메인에서 IP 주소를 찾기 위해서는 DNS가 필요하다. DNS를 인터넷의 전화번호부라고 생각하면 된다.

여기서 더 깊게 들어갈 수 있는 많은 내용이 있지만, 입문 수준의 소개에는 크게 중요하지 않기 때문에 이쯤에서 다음으로 넘어가도록 하자.

2. 로드 밸런서

로드 밸런싱에 대해 자세히 알아보기 전에, 한발 뒤로 물러나서 수평적 vs 수직적 애플리케이션 확장(scaling)에 관해서 얘기해보자. 이들은 어떤 의미이며 어떤 차이가 있는가? 간단히 StackOverflow의 답변에 따르면 수평적 확장은 더 많은 장치를 새로 추가하는 것이고, 수직적 확장은 이미 사용하고 있던 장치의 성능(예. CPU, RAM)을 높이는 것이다.

웹 개발을 한다면 당신은 아마 언제나 수평적 확장을 원하게 될 텐데, 그 이유는 간단히 말해 서비스 중단을 막기 위해서다. 서버는 언제든지 고장이 날 수 있다. 네트워크는 속도가 느려질 수 있다. 데이터 센터에 정전이 발생할 수도 있다. 1대 이상의 서버를 가짐으로써 이러한 상황에 대비할 수 있으며 서비스는 멈추지 않고 계속 제공된다. 달리 말하면 ‘오류 내성’이 생긴다. 두 번째로, 수평적 확장은 애플리케이션 백엔드(웹 서버, 데이터베이스, 서비스 X, 기타 등등)들을 각각 다른 서버에서 돌림으로서 서로가 최소한으로 결합할 수 있도록 한다. 마지막으로, 수직적 확장은 언젠가 한계에 부딪힌다. 세상에는 당신의 앱이 하는 일을 모두 처리할 수 있을 만큼 강력한 성능을 가진 컴퓨터는 없다. 전형적인 사례로 구글의 검색 플랫폼을 생각하면 된다. 물론 구글 검색은 매우 큰 규모지만 수직적 확장의 한계는 작은 회사에도 적용될 수 있다. Storyblocks를 예로 들자면 서비스를 위해 150에서 400개의 AWS EC2 인스턴스를 동시에 구동하고 있다. 이 정도 규모를 수직적 확장으로 가능하게 하려 한다면 무척 힘든 일이 될 것이다.

좋다, 이제 로드 밸런서로 돌아가자. 그들은 수평적 확장이 가능하도록 만드는 마술이다. 그들은 들어오는 요청을 복제/미러링 된 수많은 애플리케이션 서버 중의 하나로 연결하고 서버의 응답을 다시 클라이언트로 보낸다. 모든 서버는 특정 요청을 같은 방식으로 처리해야 하며, 로드 밸런서는 이들 서버에 과부하가 걸리지 않도록 들어오는 요청을 적절히 분배해주는 일을 한다.

그게 전부다. 개념적으로 로드 밸런서는 꽤 직관적이다. 그 이면은 확실히 복잡하지만 입문에서는 거기까지 들어갈 필요는 없다.

3. 웹 애플리케이션 서버

고수준의 웹 애플리케이션 서버는 상대적으로 설명하기 간단하다. 그들은 사용자의 요청이 들어오면 핵심 비즈니스 로직을 실행하고 그 결과를 HTML에 담아 브라우저로 보낸다. 이 일을 하기 위해서는 보통 데이터베이스, 캐싱 계층, 잡 큐, 검색 서비스, 기타 마이크로 서비스, 데이터/로그 큐(queue) 등 무척 다양한 백엔드 인프라와 데이터를 주고받아야 한다. 앞서 언급했듯 당신은 사용자의 요청을 처리하기 위해 최소 2번, 보통 그보다 많은 횟수로 로드 밸런서에 연결될 것이다.

앱 서버 구현은 특정 언어(Node.js, Ruby, PHP, Scala, Java, C# .NET, …)를 선택하고 그에 맞는 웹 MVC 프레임워크(Express for Node.js, Ruby on Rails, Play for Scala, Laravel for PHP, …).를 선택해야 한다는 사실을 알아야 한다. 하지만 이들 언어와 프레임워크에 대해 깊이 알아보는 것은 이 글의 범위를 뛰어넘는다.

4. 데이터베이스 서버

모든 모던 웹 애플리케이션은 정보를 저장하기 위해 한 개 이상의 데이터베이스를 사용한다. 데이터베이스는 데이터 구조를 정의하고, 새로운 데이터를 삽입하고, 데이터를 찾고, 데이터를 수정하거나 삭제하고, 데이터로 연산을 수행하는 등의 일을 한다. 대부분은 웹 앱 서버는 잡 서버의 역할을 하는 데이터베이스 서버와 직접 통신한다. 거기에 더해서 각각의 백엔드 서비스는 애플리케이션의 다른 영역과 분리된 자신만의 데이터베이스를 가지고 있을 수 있다.

나는 이 글에서 각각의 아키텍쳐 요소와 관련된 기술을 깊이 살펴보는 일을 가능한 삼가려 하지만, 데이터베이스의 다음 단계 주제를 얘기하지 않으면 당신에게 해가 될 것 같다. 그것은 SQL과 NoSQL이다.

SQL은 “Structured Query Language”의 약자이며, 1970년대에 더 많은 사람들이 사용할 수 있도록 관계형 데이터 세트 질의(query)의 표준으로 만들어졌다. SQL 데이터베이스는 공통 ID(보통 숫자를 사용)로 연결된 테이블에 데이터를 저장한다. 간단한 예제로 사용자의 과거 주소 정보를 저장하는 과정을 살펴보자. 아마 사용자의 아이디로 연결된 user와 useraddress라는 2개의 테이블을 사용할 것이다. 아래의 이미지를 보자. 두 테이블은 useradress 의 user_id 컬럼이 user의 id 컬럼을 참조하고 있는 외래 키(foreign key)이기에 연결된 것이다.

만약 SQL에 대해서 잘 알지 못한다면 나는 Khan Academy에서 찾을 수 있는 것같은 같은 튜토리얼을 공부하길 강력히 권한다. SQL은 모든 웹 개발에서 사용되기 때문에 애플리케이션을 제대로 설계하기 위해서는 최소한 기본은 알아야 한다.

NoSQL, “Non-SQL”의 약자인 이것은 대규모 웹 애플리케이션에 의해 생성되는 많은 양의 데이터를 처리하기 위해 등장한 최신 데이터베이스 기술의 집합이다(SQL에서 파생된 기술 대부분은 수평적 확장이 어려우며 특정 지점에 도달하면 수직적 확장만이 가능하다). NoSQL에 대해서 전혀 알지 못한다면 다음과 같은 고수준의 안내서와 함께 시작하길 추천한다.

나는 당신이 SQL은 반드시 공부해야 한다는 사실을 명심하고 있었으면 한다. 왜냐하면, 이 소프트웨어 업계는 NoSQL 데이터베이스조차도 SQL 인터페이스로 데이터를 조정하고 있기 때문이다. 아직은 SQL의 지배에서 벗어날 방법은 없다.

5. 캐싱 서비스

캐싱 서비스는 정보를 거의 O(1) 시간 안에 찾을 수 있는 단순한 키/값 데이터 저장소를 제공한다. 애플리케이션은 캐싱 서비스를 통해 자원이 많이 소모되는 연산의 결과를 다시 계산하지 않고 캐시에서 가져옴으로써 효율을 높인다. 애플리케이션은 데이터베이스의 쿼리 결과, 외부 서비스 호출 결과, 주어진 URL의 HTML 등을 캐시에 저장한다. 다음은 실무에서 사용되는 몇몇 예제다.

구글은 일반적인 검색어인 ‘dog’나 ‘Taylor Swift’를 사용한 검색을 매번 실행하기보다는 결과를 캐시 한다.
페이스북은 당신이 로그인할 때 포스트 데이터, 친구 목록 등 많은 데이터를 캐시 한다. 페이스북의 자세한 캐시 기술은 여기에서 읽어볼 수 있다.
Storyblocks는 React 서버 사이드 렌더링으로 생성된 HTML, 검색 결과, 검색어 입력 자동완성 결과 등을 캐시 한다.

가장 널리 사용되는 캐싱 서버 기술 2개는 Redis와 Memcache다. 나는 다른 포스트에서 이들에 대해 더 자세히 다룰 예정이다.

6. 잡 큐(job queue) & 서버

거의 모든 웹 애플리케이션은 사용자의 요청에 대한 응답과는 직접적인 관련이 없는 작업을 백그라운드에서 비동기적으로 실행할 필요가 있다. 예를 들어 구글은 검색 결과를 얻기 위해 인터넷에서 데이터를 크롤링하고 인덱싱할 필요가 있다. 이는 당신이 검색을 요청할 때마다 실행되지 않으며 구글의 검색 엔진은 비동기적으로 웹을 크롤링하고 있다.

비동기적인 작업을 가능하게 하는 여러 가지 아키텍쳐가 있지만 가장 널리 사용되는 것은 “잡 큐” 아키텍처다. 이는 2개의 컴포넌트로 구성된다. “잡”으로 이루어진 큐, 그리고 큐에 들어있는 잡을 실행하는 1개 이상의 잡 서버가 그것이다.

잡 큐는 비동기적으로 실행될 잡 목록을 저장하고 있다. 대부분 애플리케이션이 결국에는 우선순위가 적용된 큐가 필요하게 되지만 가장 단순한 것은 first-in-first-out(FIFO) 큐다. 앱이 정기적인 일정이나 사용자에 의해 발생한 잡을 실행할 필요가 생기면, 그에 알맞은 잡을 큐에 추가하기만 하면 된다.

Storyblocks를 예로 들자면, 우리의 마켓플레이스를 지원하는 데 필요한 내부 작업에 잡 큐를 사용해서 힘을 실어주고 있다. 잡 큐를 통해 영상과 사진을 인코딩하고, 메타데이터 태그를 붙이기 위해 CSV를 처리하고, 사용자 통계를 취합하고, 비밀번호 재설정을 위한 이메일을 전송하는 등의 일을 한다. 우리는 간단한 FIFO 큐로부터 시작했지만 빠른 처리 속도가 중요한 민감한 비밀번호 재설정과 같은 작업을 위해 우선순위 큐로 업그레이드하게 되었다.

잡 서버는 잡을 처리 한다. 그들은 잡 큐를 가져와서 할 일이 있는지 확인하고, 있다면 큐에서 잡을 뽑아내서 실행한다. 잡 서버로 사용할 수 있는 언어와 프레임워크는 너무나 다양해서 이 글에서는 자세히 다루지 않겠다.

7. 전체 텍스트 검색 서비스

대부분은 아니지만 많은 웹 앱이 사용자가 텍스트 입력(보통 ‘쿼리’라고 불리는)을 입력을 하면 검색을 하고 가장 ‘관련 있는’ 결과를 보여주는 기능을 제공한다. 이 기능을 가능하게 하는 것은 보통 “전체 텍스트 검색”이라고 불린다. 전체 텍스트 검색은 쿼리 키워드를 포함하는 문서를 빠르게 찾기 위해 역 인덱스(inverted index)를 활용한다.

3개의 문서의 제목이 어떻게 역 인덱스로 변환되어서 특정 키워드를 포함한 제목을 가진 문서를 찾을 수 있도록 활용하는지를 보여주는 예제다. 보통 ‘in’, ‘the’, ‘with’ 같은 일반적인 단어(stop 단어라고 불린다)는 역 인덱스에 포함되지 않음을 주의 깊게 보라.

어떤 데이터베이스에서는 전체 텍스트 검색을 바로 사용할 수 있지만(MySQL은 전체 텍스트 검색을 지원한다), 보통 역 인덱스를 연산하고 쿼리 인터페이스를 제공하는 “검색 서비스”를 분리해서 운영하는 사례가 많다. 오늘날 가장 인기 있는 전체 텍스트 검색 플랫폼은 Elasticsearch지만 Sphinx 또는 Apache Solr 같은 다른 선택지도 있다.

8. 서비스

앱이 특정 규모에 도달하면 별도의 애플리케이션으로 분리해서 운영하기 위핸 ‘서비스’가 생기게 된다. 외부에는 노출되지 않지만, 앱과 다른 서비스와는 연동된다. Storyblocks을 예로 들자면 몇 개의 운영, 계획 서비스를 하고 있다.

계정 서비스는 우리의 모든 사이트의 사용자 정보를 저장해서 교차 판매 기회를 더 쉽게 제공하고, 더 일관적인 사용자 경험을 가능하게 한다.
컨텐츠 서비스는 우리의 모든 비디오, 오디오, 이미지의 메타데이터를 저장한다. 또 콘텐츠 다운로드 인터페이스와 다운로드 이력을 보여주는 기능을 제공한다.
결제 서비스는 고객이 카드로 결제할 수 있는 인터페이스를 제공한다.
HTML → PDF 서비스는 HTML을 PDF로 변환하는 간단한 인터페이스를 제공한다.

9. 데이터

오늘날, 기업은 데이터를 어떻게 다루느냐에 따라 살고 죽는다. 최근 거의 모든 앱은 특정 규모에 도달하면 데이터를 제어, 저장, 분석하기 위해 데이터 파이프라인을 사용한다. 전형적인 파이프라인은 3개의 주요 단계를 가진다.

앱은 보통 사용자 상호작용으로 발생한 데이터를 데이터 ‘firehose’라 불리는 곳으로 전달한다. 그것은 데이터를 받아들이고 처리할 수 있는 스트리밍 인터페이스를 제공한다. 가공되지 않은 원시 데이터는 변형되거나(transformed) 추가 정보와 함께(augmented) 다른 firehose로 전달된다. AWS Kinesis와 Kafka는 이러한 작업을 위한 대표적인 기술이다.
원시 데이터와 최종 데이터는 모두 클라우드 스토리지에 저장된다. AWS Kinesis는 원시 데이터를 AWS의 클라우드 스토리지(S3)에 저장할 수 있도록 매우 쉽게 사용할 수 있는 ‘firehose’로 불리는 설정을 제공한다.
변형/추가된 데이터는 종종 분석을 위해 데이터 웨어하우스(DW)에서 로드된다. 우리는 AWS Redshift를 사용한다. 큰 기업에서는 Oracle이나 기타 독점적인 웨어하우스 기술을 사용하고 있지만, 스타트업 업계에서는 RedShift를 많이 사용하고 있으며 점유율도 계속 오르고 있다. 만약 데이터가 충분히 축적되었다면 Hadoop같은 NoSQL MapReduce 기술이 분석을 위해 필요하게 될 것이다.

처음에 제시한 아키텍쳐 다이어그램에서는 빠진 단계가 있다. 데이터 웨어하우스에서 앱과 서비스에서 사용중인 데이터베이스에서 데이터를 불러오는 과정이다. 예를 들어 Storyblocks에서 우리는 VideoBlocks, AudioBlocks, Storyblocks, 계정 서비스, 그리고 컨트리뷰터 포털 데이터베이스를 매일 밤 Redshift로 불러온다. 이는 사용자 상호작용 이벤트 데이터와 핵심 비즈니스 데이터를 함께 둠으로써 우리의 분석가에게 총체적인 데이터 집합을 제공한다.

10. 클라우드 스토리지

AWS에 의하면 “클라우드 스토리지는 인터넷을 통해 데이터를 저장, 접근, 공유할 수 있는 단순하고 확장성 있는 방법”이다. 당신은 로컬 파일 시스템에 저장할 수 있는 거의 모든 것을 RESTful API를 사용해서 HTTP를 통해 클라우드에 저장하고 접근할 수 있다. 아마존의 S3는 현재로써는 가장 인기 있는 클라우드 스토리지이며 Storyblocks에서는 비디오, 사진, 오디오 데이터, CSS, 자바스크립트, 사용자 데이터 등을 저장하기 위해 S3에 크게 의존하고 있다.

11. CDN

CDN은 ‘Content Delivery Network’의 약자며 HTML, CSS, 자바스크립트, 이미지 같은 정적인 데이터를 웹을 통해 1개의 원본(origin) 서버를 사용하는 것보다 더 빠르게 제공하기 위한 기술이다. 이는 콘텐츠를 전 세계의 많은 ‘엣지(edge)’ 서버에 분산시킴으로써 동작한다. 그리고 사용자는 데이터를 원본 서버 대신 가장 가까운 엣지 서버에서 다운로드한다. 예를 들어 아래의 이미지처럼 스페인에 있는 사용자가 뉴욕에 있는 원본 서버의 웹페이지에 접근하면 정적인 데이터는 대서양을 가로지르는 매우 느린 HTTP 요청을 하는 대신 영국에 있는 CDN ‘엣지’ 서버에서 빠르게 가져오는 것이다.

출처

CDN에 대한 더 자세한 안내는 이 글을 살펴보길 바란다. 일반적인 웹 앱은 CSS, 자바스크립트, 이미지, 비디오 및 다른 정적인 데이터를 제공하기 위해 항상 CDN을 사용해야 한다. 어떤 앱은 정적인 HTML 페이지를 제공할 때도 CDN을 사용하기도 한다.

맺음말

웹 아키텍쳐 입문은 여기서 끝이다. 이 글이 도움되었으면 좋겠다. 나는 강의를 통해 웹 아키텍쳐의 몇몇 컴포넌트를 깊이 있게 살펴보는 시리즈를 내후년 안에 제공하려 한다.

자바스크립트의 this가 가리키는 것

rhostem — Fri, 20 Jul 2018 00:00:00 GMT

자바스크립트에서 컨텍스트(context)는 곧 객체 인스턴스다. 그리고 컨텍스트는 this라는 키워드를 통해 참조할 수 있다. 자바스크립트에서 this는 처음 접했을 때 많은 혼란을 주는 존재다, 이 키워드는 사용되는 위치에 따라 서로 다른 객체를 가리키기 때문이다. this 키워드를 파악하기 위해서는 this를 사용하고 있는 함수의 객체 생성 여부와 함수와 객체 사이의 관계를 잘 살펴봐야 한다.

이 글에서 언급하는 ‘객체’란 인스턴스를 의미한다. 즉 new 키워드를 통해 실체화 된 객체를 말한다.

함수

먼저 함수 내부에서의 this를 살펴보자. 함수는 선언한 후, 호출해서 사용한다.

function foo() {
  console.log('this is', this)
}

foo() // this is undefined

위의 코드를 실행하면 콘솔 창에는 undefined가 출력된다. 단순히 선언만 한 함수는 컨텍스트가 없기 때문이다. 호출을 통해 내부 프로세스를 사용할 수는 있지만 함수라는 틀만 있고 객체 인스턴스로는 만들어지지 않은 상태다. 실체가 없으므로 함수 내부에서 this는 undefined가 된다.

이 글의 모든 예제는 전역 공간(브라우저의 콘솔 커맨드라인에서 실행하는 것과 같다.)에서 Strict 모드로 실행했다. Strict 모드를 사용하면 this 객체가 null 또는 undefined일 때 전역 객체로 자동 변환되지 않는다. 만약 Strict 모드를 사용하지 않았다면 위의 예제에서는 undefined 대신 Window가 출력되었을 것이다.

함수로 객체를 생성한다는 개념이 약간 어색하게 느껴질 수 있지만, 자바스크립트에는 가능한 일이다. 자바스크립트에서는 객체 리터럴 표기법(ex. var a = { prop: 'value' })뿐만 아니라 new 키워드와 함수를 사용해서 객체를 만들 수 있다.

앞서 선언한 foo 함수로 객체를 만들어 보자. 그러면 콘솔 로그에는 함수를 직접 호출했을 때와 다른 결과가 나타난다.

var f = new foo() // this is foo {}

앞에서는 this가 undefined라고 했지만 여기서는 foo라고 한다. this가 가리키는 대상이 바뀐 이유는 함수 foo를 바탕으로 한 객체가 만들어졌기 때문이다. 따라서 console.log 함수에서 참조한 this가 가리키는 대상은 이제 foo가 된다.

메소드(method)

객체의 속성에 할당된 함수를 메소드라고 한다. 메소드 내부에서 this가 무엇을 가리키는지 확인해보자.

function foo() {
  this.check = function() {
    console.log('this is', this)
  }
}

var f = new foo()
f.check() // this is foo {check: ƒ}

check 메소드 내부의 this는 foo로 나온다. 메소드도 앞서 언급한 것처럼 함수 선언만 하고 객체가 생성되지는 않은 상태다. 하지만 함수 선언과 달리 메소드는 foo 함수의 컨텍스트(this)에 직접 연결되어 있다. foo 함수로 객체가 만들어지면 메소드도 그 객체에 포함된다. 서로 동일한 컨텍스트를 공유하는 개념이라고 볼 수 있다.

클래스 문법으로 프로토타입 메소드를 선언하거나 리터럴 문법으로 선언한 객체에도 같은 법칙이 적용된다.

class Bar {
  check() { // === Bar.prototype.check
    console.log('this is', this)
  }
}

var b = new Bar()
b.check() // this is Bar {}

var obj = {
  checkAtObj: function() {
    console.log('this is', this)
  }
}
obj.checkAtObj() // this is {checkAtObj: ƒ}

컨텍스트를 가지지 않는 화살표 함수

ES6에는 화살표 함수 문법이 추가되었다. 화살표 함수로 생성된 함수는 컨텍스트를 가지지 않으며 객체 생성을 위한 constructor도 없어서 new 키워드로 객체를 생성할 수도 없다.

화살표 함수는 일반적인 함수 선언과 다르게 작동한다. 화살표 함수 내부에서 this는 그 함수를 포함하고 있는 객체 인스턴스를 가리킨다. 함수처럼 사용할 수 있지만 화살표 함수 내부의 코드는 중괄호로 둘러싸이지 않은 영역에서 실행된다고 생각하면 이해하기 쉽다.

function test() {
  function normalFunc() {
    console.log('this in normalFunc is', this) // this in normalFunc is undefined
  }
  normalFunc()

  var arrowFunc = () => {
    console.log('this in arrowFunc is', this) // this in arrowFunc is test {}
  }
  arrowFunc()

  console.log('this', this) // this test {}
}

var testInstance = new test()

컨텍스트를 직접 지정하기

지금까지는 살펴본 것들은 자연스러운 상황이었다. 하지만 자바스크립트는 컨텍스트, 즉 this가 가리키는 객체를 조작할 수 있는 방법을 제공한다. Function 함수의 프로토타입에 선언되어 있는 call, apply, bind가 그것이다. 이 3가지 메소드는 사용 방식이 조금씩 다를 뿐 목적은 모두 동일하다.

call은 컨텍스트를 지정하는 동시에 호출한다.

function test() {
  this.check = function () {
    console.log(this)
  }
}
var testInstance = new test()

testInstance.check() // test {check: ƒ}
testInstance.check.call(window) // Window {}

자바스크립트의 모든 함수는 기본 객체인 Function으로 만들어진 객체이기에 사용자가 만들지 않은 속성을 프로토타입으로 가지고 있다. call 메소드에 객체를 파라미터로 전달하면 함수가 즉시 실행되면서 this만 바뀐다. apply는 call과 같지만, 원본 함수에 전달할 파라미터를 배열에 담아서 전달한다는 것만 다르다.

testInstance.check.call(window, 'arg1', 'args2')
testInstance.check.apply(window, ['arg1', 'args2'])

앞의 두 메소드와 달리 bind는 즉시 실행되지 않는다. 대신 고차 함수가 하는 것처럼 새로운 함수를 만든다.

const calc = {
  base: 10,
  sum: function (num) {
    return this.base + num
  }
}
const hundred = {
  base: 100
}

console.log(calc.sum(1)) // 11

// sum 메소드의 컨텍스트를 교체해서 this.base가 100이 되도록 한다.
const sumBindToHundred = calc.sum.bind(hundred)

console.log(sumBindToHundred(1))  // 101

컨텍스트? this? 결국 모두 객체다.

자바스크립트는 모든 것이 객체로 구성되어 있으며 this도 결국 객체를 가리키는 키워드다. 하지만 몇 가지 변형이 있어서 모든 사례에 적용되는 규칙을 정의하기는 어렵다. 그래도 this를 관통하는 추상적인 원칙을 하나 들자면 this는 실체가 있는 대상을 가리켜야 한다가 아닐까 한다. 단순 함수 선언은 컨텍스트가 없고, 객체가 만들어진 함수만 컨텍스트가 있기 때문이다. 그리고 메소드로 지정된 함수는 객체로 만들어지진 않았지만 다른 객체에 포함되어 있으니 실체가 있다고 간주할 수도 있지 않을까? 개인적으로는 this를 단순 암기식으로 외우는 것보다 이런 식으로 원칙을 세우는 편이 이해하기에 좋았다.

[번역] JavaScript vs. TypeScript vs. ReasonML

rhostem — Sun, 24 Jun 2018 00:00:00 GMT

이 글은 Dr. Axel Rauschmayer의 JavaScript vs. TypeScript vs. ReasonML을 번역한 글입니다.

이 포스트에서는 세 가지 프로그래밍 언어/방언인 자바스크립트(JavaScript), 타입스크립트(TypeScript)와 ReasonML의 장점과 단점을 평가한다. 이 글은 최근에 타입스크립트와 ReasonML로 진행된 작은 규모의 실제(real-world) 프로젝트 참여 경험과 다년간의 자바스크립트 사용 경험을 기반으로 서술했다.

1. 정적 타입의 장단점

장점:

문서화: 거의 모든 코드에서 파라미터의 타입이 문서로 만들어 져 있다면 무척 큰 도움이 된다는 사실을 알았다. 그러면 나는 caller와 callee로서 어떤 값을 기대해야 하는지 알 수 있다.
- 하지만 이 장점은 거기서 더 나아간다. 오래된 자바스크립트 코드를 열어 타입을 추가하려고 하면, 그 코드가 어떻게 동작했는지 기억이 잘 나지 않곤 한다. 하지만 타입이 있으면 어떻게 동작하는지 훨씬 쉽게 파악할 수 있다. 예를 들어 “이 함수는 어떻게 사용되는가”에 대한 정보를 얻기 위해서는 보통 호출 지점으로 가 본다. 만약 함수 파라미터에 타입 주석(annotation)이 추가되어 있다면 그 정보를 더 쉽게 얻을 수 있을 것이다.
- 나는 “더 나은 문서화” 역할을 하는 에디터의 자동완성 기능도 고려할 것이다. 자동완성은 API를 사용할 때 문서를 찾아볼 일이 줄어들게 한다(좋은 주석 또한 도움이 된다). 예를 들어, 내가 DOM 프로그래밍을 많이 하기 시작했던 2006년에는 GWT(자바 기반이며, 당시에는 여러 가지 이유로 매력적인 솔루션이었다)를 사용했다. Eclipse의 자동완성 덕분에 DOM API를 찾아보면서 공부하는 일이 즐거웠다.
함수 파라미터의 타입을 확인할 수 있는 빠른 방법이다. 나는 여러 함수에 프로그래밍적인 방법으로 타입을 붙이려고 할 때, 그리고 그 코드들이 불필요한 상용구처럼 느껴졌을 때, 자바스크립트에 정적 타입을 사용할 때가 되었음을 안다.
리팩토링에 도움이 된다(열거형에 케이스를 붙이는 것 등).

단점:

배우는 데 시간이 걸린다.
추가적인 단계의 복잡도를 추가한다. 정적 타입의 사용은 기본적으로 다른 계층에서 코드를 작성하는 일이다.
표현의 자유를 제한한다. 제네릭(generic), 공변성과 반공변성(covariance and contravariance, 예: 문자열 타입의 배열은 객체 타입 배열의 부분집합이 아니다), 기타 등등에 들어가면 복잡해진다.
에러를 막지 못한다. 적어도 이는 최근의 연구가 말해준다. 내 경험으로는, 몇 가지 종류의 에러는 잡을 수 있다(예를 들면 null 체크 누락). 하지만 그 에러는 타입 선언 대신 단위 테스트를 작성했다면 더 빨리 발견했을 것이다. 더 심각한 문제를 막기 위해서는 테스트가 필요하다.
얼마간의 상호 작용을 잃게 되며 컴파일에 시간이 걸린다. 하지만 자바스크립트 생태계(ecosystem)에서 컴파일은 피할 수 없기도 하다. (역주: 2018년 현재 ES6+를 사용하기 위해서는 Babel 같은 도구로 자바스크립트 소스를 ES5 형태로 변환하는 과정이 필수적이다)

2. ReasonML

만약 정적 타입이 제공할 수 있는 최선을 경험하고 싶다면, ReasonML(또는 ReasonML의 기반이 되는 OCaml)을 사용해라. 예를 들면, 언어의 거의 모든 기능이 설계되어 있어서 최소한의 타입 주석만 작성하면 된다(타입 추론에 의해 가능하다).
이미 모든 것이 준비되어 있다는 점이 놀랍다(특히 에디터 지원). 하지만 몇가지 중요한 기능-더 나은 Promise, 반복과 비동기 반복 지원; 표준 라이브러리 Belt; 향상된 자바스크립트 호환(이미 꽤 괜찮은 수준이지만 내가 기대했던 것보다는 더 복잡하다); 더 나은 유니코드 문자열 지원-은 아직 작업 중이다.
ReasonML은 빌드 시간이 무척 짧다. 타입스크립트보다 상당히 빠르며 이는 사용성 면에서 확실한 장점이다.
자바스크립트 라이브러리 바인딩(binding)이 제공되고 있으나 여전히 제한적이다. Reason Package Index를 살펴보길 바란다.
네이티브로 갈 기회가 있다. 예를 들자면, Jared Forsyth는 the game Gravitron을 ReasonML로 구현했으며 Android, iOS, 웹, 그리고 macOS에서 네이티브로 실행할 수 있다.

ReasonML에 대한 더 많은 정보는 내가 쓴 책 Exploring ReasonML and functional programming(온라인에서 무료로 읽을 수 있다)을 참고하길 바란다.

3. 타입스크립트

타입스크립트의 타입 시스템은 내가 기대했던 것보다는 더 가볍다. 자바(Java)보다는 함수형 언어(FP)를 사용한다는 느낌이 더 난다. 예를 들면 타입은 이름 기반(nominal)이 아니라 구조 기반으로 작동한다. 예를 들어 인터페이스(interface)를 선언해서 사용할 때, 이름만 다르고 구조가 같은 인터페이스를 자바에서는 다른 타입으로 보지만 타입스크립트에서는 동일한 타입으로 본다.
타입 시스템이 무척 강력하고 직관적이다. union 타입, intersection 타입, discriminated union type을 사용해서 자바스크립트의 많은 관용적인 표현에 타입을 정의할 수 있다.
에디터 지원(Visual Studio Code, WebStorm, etc)이 무척 뛰어나다.
많은 npm 패키지가 자체적으로 타입 선언을 포함하고 있거나, 타입 선언 파일을 매우 쉬운 방법으로 설치할 수 있다. 자세한 정보는 DefinitelyTyped를 참고하길 바란다.
당연히, 자바스크립트와의 호환성이 훌륭하다. 하지만 하나의 예외가 있다. 객체 리터럴을 사용해서 named parameter를 흉내냈을 때 파라미터에 타입을 붙이는 일이 필요없이 복잡하다. (추가 정보).

결론: 타입스크립트는 자바스크립트와 ReasonML의 중간 지점을 잘 차지하고 있다. 나는 대규모 프로젝트에서 얼마나 효과가 있었는지 이야기를 들어보고 싶다.

4. 자바스크립트

개발 생태계 전부가 끊임없는 혁신과 실험의 원천이다.
npm을 통해 폭넓은 라이브러리 선택권을 가진다
시스템을 가능한 유동적인 상태로 두면서 원하는 방향으로 빠르게 전환할 수 있다.
컴파일 단계 없이 소스를 작성하고, 실험할 수 있다.

자바스크립트에 대한 더 많은 특징에 대해서는 온라인에서 무료로 읽을 수 있는 나의 책 Exploring JS 시리즈를 참고하길 바란다.

5. 결론: 자바스크립트 생태계는 그 어느 때보다 강력하다

정적 타입을 사용할지 말지는 감정적인 화제다. 나의 조언은:

당신을 더 행복하고 생산적으로 만들어주는 것을 선택해라.
당신이 사용하고 있는 것의 강점과 약점을 인지하고 있어라.

개인적으로는 프로젝트가 일정 규모 이상으로 커지면(또는 결국에는 그렇게 될 것이라 예상되는 프로젝트에) 정적 타입을 사용한다.

현재 자바스크립트 생태계의 힘과 다양성은 놀라울 정도다. 당신은 필요에 따라(또, 업무가 변화하는 정도에 따라) 자바스크립트, 타입스크립트, ReasonML을 서로 바꿀 수 있다. 그들은 몇몇 도구, 많은 수의 라이브러리, 많은 문법을 공유한다. 예를 들어 ReasonML을 사용하면서 템플릿 솔루션이 빨리 필요할 때 나는 npm을 통해 자바스크립트 기반의 EJS 라이브러리를 사용했다.

마지막으로, 정적 타입에는 많은 다른 좋은 선택지(정적 타입 검사기 Flow, 함수형 프로그래밍 언어 elm 등)가 존재한다는 사실을 알고 있길 바란다.

Git 커밋 상태를 확인하기 위한 쉘 스크립트

rhostem — Tue, 12 Jun 2018 00:00:00 GMT

photo by Ashim D’Silva (https://unsplash.com/@randomlies)

Git으로 버전 관리를 하고 있지만 CI 도구를 사용하고 있지 않다면, 최소한 앱을 배포하기 전에 커밋을 하고 원격 저장소에 푸시를 해야 한다. 그래야 개발 서버든 운영 서버든 간에 현재 배포된 앱이 어떤 버전인지 일 수 있고 버그 수정도 원만하게 할 수 있기 때문이다. 이런 과정을 추가하면 아무리 버그를 급하게 수정해야 하는 상황이라도 자신의 코드를 한번은 돌아보게 만드는 만드는 효과를 줄 수 있다고 본다. 버전 관리를 하면서도 아무런 의미없는 커밋을 남발해도 된다는 마음을 가진 사람은 드물 테니까 말이다.

쉘 스크립트

쉘(Shell)은 유닉스 및 유닉스 계열 운영체제의 커맨드라인 인터페이스를 의미하며 리눅스, 맥 OS의 기본 쉘로는 bash가 제공된다. 개인적으로는 더 다양한 기능을 제공하는 zsh과 Oh My Zsh의 조합을 사용하고 있다.

그리고 쉘에서는 웹 브라우저의 콘솔에서 자바스크립트 코드를 사용할 수 있는 것처럼 쉘 스크립트 코드를 실행할 수 있다. 쉘 스크립트를 사용하면 파일 입출력, 연속적인 명령어 실행, 사용자 인터페이스 구현 등이 가능해진다. Git 저장소의 커밋 및 푸시 여부도 쉘 스크립트 안에서 Git 명령어의 실행을 조합하는 방식으로 구현할 수 있다.

쉘 스크립트를 사용해서 현재 브랜치 정보 확인하기

쉘 스크립트에도 프로그래밍 언어인 만큼 변수를 사용할 수 있다. Git 명령어를 이용해 현재 브랜치의 이름, 현재 작업중인 로컬 브랜치(HEAD)의 커밋 해시 스트링, 그리고 원격 저장소의 커밋 해시 스트링을 저장한다.

# 현재 브랜치 이름을 변수에 할당
BRANCH=$(git rev-parse --abbrev-ref HEAD)

# 현재 브랜치의 최종 커밋의 해시값
HASH=$(git rev-parse HEAD)

# 원격에 업로드된 현재 브랜치의 커밋 해시
REMOTE_HASH=$(git rev-parse --verify origin/$BRANCH)

BRANCH에 현재 브랜치의 이름을 할당한 후 원격 저장소의 커밋 해시를 가져온 후 사용했다. 변수를 사용할 때는 선언할 때와 달리 달러($) 사인을 붙여서 사용해야 한다.

필요한 값을 가져왔으니 이제 조건문을 사용해 배포가 가능한 상황인지 확인하면 된다. 조건문은 if ~ fi로 블록을 형성할 수 있고 then 키워드 후에 조건문을 만족했을 때 실행할 코드를 입력한다. 아래 코드에서는 현재 브랜치가 master 브랜치인지 확인한다.

if [ "$BRANCH" != "master" ]; then
  echo 'master 브랜치에서만 배포 가능합니다.'; # 메시지 출력
  exit; # 스트립트 종료
fi

다음으로는 커밋되지 않은 변경 사항이 있는지 확인해야 한다. 역시 Git 명령어를 사용해야 한다. git status --porcelain 명령어는 저장소의 변경 사항을 아래와 같은 방식으로 간단히 출력한다.

# ?? 기호는 Git index에 추가되지 않은 파일이라는 의미다
?? src/pages/posts/2018-06-12-shellscript-to-check-commit/

만약 변경 사항이 없다면 아무것도 출력되지 않는다. 그래서 문자열이 null이 아니라면 true를 반환하는 -n 키워드를 사용해서 커밋되지 않은 파일이 있는지 확인할 수 있다.

if [ -n "$(git status --porcelain)" ]; then
  echo "배포 전 모든 변경 사항을 커밋해야 합니다.";
  exit;
fi

그리고 마지막으로 현재 브랜치의 커밋과 원격 브랜치의 커밋이 일치하는지 확인한다.

if [ $HASH != $REMOTE_HASH ]; then
  echo "배포 전 모든 커밋을 원격에 푸시해야 합니다."
  exit;
fi

이렇게 확인 과정이 끝났으므로 스크립트의 나머지 부분에서는 실제 배포를 수행하는 npm run deploy 같은 명령어를 실행할 수 있다.

참고자료

PM2로 Node.js 앱 프로세스 배포하기

rhostem — Sun, 27 May 2018 00:00:00 GMT

PM2는 Node.js 프로세스 관리 도구로서 IBM, Microsoft, Paypal 등의 유명 기업에서도 사용하고 있다. 다양한 기능을 지원하지만 가장 큰 특징으로는 역시 Cluster 모드일 것이다. 자바스크립트는 싱글 스레드로 앱을 실행하지만 PM2는 Node.js의 Cluster 모듈을 사용해서 서버 앱에 복수의 인스턴스가 같은 포트를 사용하게 할 수 있도록 해준다. 이를 통해 사용량에 따라 CPU 점유율 늘리고 줄이면서 앱의 안정성을 높일 수 있다.

이 포스트에서는 Node.js 앱을 PM2를 이용해서 Nginx 서버에 배포하는 과정을 간략히 정리해보고자 한다.

PM2 ecosystem 파일 생성

PM2의 커맨드라인 명령어로 앱 프로세스를 생성하고 관리할 수 있지만 배포를 위해서는 설정 파일을 만들어야 한다. 설정 파일에는 프로세스의 정보와 배포에 필요한 정보가 포함된다. 설정 파일은 JSON 형식으로 만들 수도 있고 Node.js 모듈 형식으로 만들 수도 있다.

module.exports = {
  /**
   * 앱 설정
   */
  apps: [
    {
      name: 'app_name',
      script: './server.js', // 앱 실행 스크립트
      instances: 4, // 앱 인스턴스의 수
      exec_mode: 'cluster', // 실행 모드.
      env: { // 환경변수. 모든 배포 환경에서 공통으로 사용한다.
        NODE_ENV: 'production',
      },
      env_staging: { // staging 배포 환경에서만 사용할 환경 변수
        API_ROOT: 'http://api.server.name'
      }
    },
  ],

  /**
   * 배포 설정
   */
  deploy: {
    staging: {
      user: 'root', // 접속할 계정. SSH를 사용해서 서버에 접속할 수 있어야 한다.
      host: 'appstaging.server.name', // 서버 도메인 또는 IP
      ref: 'origin/develop', // 서버에서 clone할 브랜치
      repo: 'git@github.com:user/reponame.git', // Git 저장소 URL
      ssh_options: 'StrictHostKeyChecking=no', // SSH 접속 옵션.
      path: '/home/www/project_root', // 앱을 설치할 폴더 위치
      'post-deploy': // PM2가 배포(git clone)한 후 실행할 명령어
        'npm install && npm run build && pm2 reload ecosystem.config.js'
    },
  },
}

`apps`

앱 설정 영역이다.

`name`

앱의 이름을 할당한다.

`script`

앱을 실행할 수 있는 소스 파일의 경로를 할당한다.

`instances`

script로 실행하는 앱이 몇개의 인스턴스를 생성할 것인지를 결정한다. 특히 이 옵션은 exec_mode 옵션이 cluster일때만 의미가 있다.

`exec_mode`

실행 모드로 fork, cluster를 선택할 수 있다. 이는 PM2가 Node.js 의 cluster API를 사용할지, child_process.fork를 사용할지를 결정한다.

`env`

환경변수. deploy 섹션에서는 여러 개의 배포 환경을 설정할 수 있는데, env에 할당된 값은 모든 환경에서 공통으로 적용된다. 특정 환경에서만 사용하려면 env_이름에 값을 설정해야 하며, 앱을 시작할 때 --env 이름 옵션을 추가해야 한다.

하지만 next.js를 사용햐서 만든 React 서버 렌더링 앱에서는 환경변수를 제대로 사용할 수 없었다. 서버 렌더링시에는 환경 변수가 제대로 적용되었지만 브라우저에서는 process.env를 참조하지 못하기 때문이었다. 그래서 빌드할 때 환경 변수를 포함할 수 있도록 babel의 inline-dotenv 플러그인을 사용했다.

`deploy`

배포 환경과 관련된 설정 영역이다. 배포 환경은 원하는 만큼 만들 수 있다.

PM2는 서버에 접속해서 지정된 위치에 Git 저장소를 복제한 후 사용자가 지정한 명령어를 사용해 앱을 실행하는 방식을 사용한다. 그래서 서버 접속과 Git 저장소와 관련된 정보가 필요하다.

`user`

서버 접속에 사용할 계정이다. 접속에는 SSH를 사용한다.

`host`

서버 도메인, 또는 IP에 해당하는 값이다.

`ref`

서버에서 clone할 Git 저장소의 브랜치 이름이다. origin/master 처럼 remote 이름과 브랜치 이름을 함께 입력한다.

`repo`

SSH를 사용해서 Git clone을 가능하게 하려면 PM2에서 제시하는 방법을 사용하거나 서버의 SSH 공개 키가 Git 서비스에 등록되어 있어야 한다. 만약 Github를 사용한다면 https://github.com/settings/keys에서 추가 가능하다.

`ssh_options`

SSH 접속에 사용할 옵션이다.

`path`

Git 저장소를 clone할 서버상의 경로에 해당한다. 웹서버에서 설정한 경로로 지정해준다.

Nginx Virtual Host 설정

배포를 하기 전에는 웹서버 설정이 필요하다. 서버로 들어오는 외부 요청을 특정 프로세스에 연결하기 위해서는 리버스 프록시 설정을 해야 한다. 처음에는 Apache를 사용했지만 PM2의 reload 명령어로 프로세스를 재시작할 때 자꾸 서버 오류가 발생해서 Nginx로 바꾸었더니 문제가 발생하지 않았던 경험이 있다.

Nginx HTTP 프록시 설정은 PM2 홈페이지에서도 문서로 제공한다.

upstream my_nodejs_upstream {
    # 서버 locahost IP와 앱의 포트 번호를 입력한다.
    server 127.0.0.1:3001;
    keepalive 64;
}

server {
    # 포트번호 없이 접속 가능하도록 80번 사용
    listen 80;
    # 외부에서 접속 가능한 도메인 네임을 입력한다.
    server_name myapp.yourhost.com;
    # 앞서 언급한 PM2의 ecosystem 파일의 deploy.env_name.path에 해당하는 값이다
    root /home/www/project_root;

    location / {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host;
      proxy_set_header X-NginX-Proxy true;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_max_temp_file_size 0;
      # 앱의 localhost URL을 입력한다.
      proxy_pass http://localhost:3001/;
      proxy_redirect off;
      proxy_read_timeout 240s;
    }
}

위의 설정은 Nginx의 가상 호스트 설정 블록으로 /etc/nginx/sites-available 폴더에서 생성한 후 sites-enabled 폴더에는 원본 파일에 연결된 symbolic 링크를 생성해둔다. sites-enabled 폴더에 직접 만들어도 되지만 가상 호스트를 여러개 관리할 때 좋기에 권장되는 방법이다. 그리고 Nginx의 기본 설정은 sites-enabled 폴더에 있는 파일을 불러오도록 되어 있지만, 다른 사용자에 의해 변경되어 있을 수 있으니 nginx.conf 파일에 include /etc/nginx/sites-enabled/*; 설정이 있는지 확인해야 한다.

PM2 프로세스 관리 명령어

PM2는 소스 파일명과 인라인 옵션을 이용해서 프로세스를 실행할 수도 있고, 설정 파일을 이용해서 프로세스를 실행할 수도 있다. 앞서 설정한 ecosystem 파일을 사용한다면 아래의 두 명령어는 같은 내용이다. 프로세스 이름을 app_name으로 하고 인스턴스를 4개 생성한다.

pm2 start ecosystem.config.js

pm2 start server.js --name "app_name" -i 4

앱 재시작에는 restart 대신 reload를 사용하는 편이 낫다. 전자는 프로세스를 즉시 종료시키고 재시작하기에 접속이 불가능한 시간이 발생할 수 있다. 하지만 후자는 그런 간격이 생기지 않도록 해준다. reload 명령어는 앱 프로세스와 관련된 프로세스를 정리한 후 준비된 상태에서 다시 시작하는 gracefulReload에 해당된다. 그리고 reload 명령어를 사용할 때 현재 실행중인 프로세스가 없다면 자동으로 start 명령어로 대체한다.

배포

앱을 배포할 준비는 모두 되었다. 배포를 하기 위해서는 변경 사항을 모두 commit 한 후 원격 저장소에 push한 후에 가능하다. PM2가 기본적으로 해주는 일은 원격 서버에 저장소를 복제해주는 일까지만이며 그 후의 작업은 사용자가 직접 설정해줘야 한다.

배포 환경 설정 파일의 deploy 영역에는 환경마다 pre-setup, post-deploy 등 특정 시점에서 실행할 수 있는 명령어를 지정할 수 있다. 하지만 가장 중요한 건 PM2에 의한 배포가 끝난 후 실행되는 post-deploy다.

{
  deploy: {
    staging: {
      'post-deploy': 'npm install && npm run build && pm2 reload ecosystem.config.js'
    }
  }
}

위의 설정에서는 저장소를 내려받는 배포가 과정이 끝난 후 NPM 패키지를 인스톨하고 빌드를 한 후 프로세스를 재시작하도록 했다. 최초 배포를 하기 전에 배포할 환경의 setup을 실행하고 배포한다.

pm2 deploy staging setup

pm2 deploy ecosystem.config.js staging

작업이 끝나면 현재 실행중인 프로세스의 목록을 보여준다. 여기에서는 프로세스의 이름, 실행 모드, CPU 및 메모리 사용률 등을 확인할 수 있다.

항상 오류가 발생하는 첫 배포 시도

새롭게 배포 환경을 구성할 때는 항상 오류에 부딪히는 것 같다. 호스트 서버 접속 오류, Git clone 오류, 웹서버 설정 오류 등 아무리 문서를 보고 따라 해도 작업 중인 환경에서만 생기는 문제가 발생하곤 한다. 하지만 처음 한 번만 고생하면 그다음이 편해지니까 시도할 가치는 충분하다.

특히 PM2처럼 배포된 앱이 어떤 commit에 해당하는지를 확실히 명시하는 것은 무척 중요하다고 생각한다. 소수가 작업할 때나 많은 인원이 작업 할 때나 운영 중인 시스템에 문제가 발생했을 때 무엇이 문제인지 추적하는 데 큰 도움이 되기 때문이다.

Gulp로 구성한 퍼블리싱 개발 환경

rhostem — Sun, 20 May 2018 00:00:00 GMT

본 포스트에서 사용된 전체 소스 파일은 아래 링크에서 확인할 수 있다.

startkits/gulp-static-site

최근 만들어지는 웹사이트는 싱글 페이지 형식으로 개발하는 형태가 일반적이다. 하지만 퍼블리싱이라고도 불리는 정적인 페이지 개발 작업에 대한 수요는 여전히 많다. 작업을 할때는 Gulp를 기반으로 개발 프로세스를 구성하는데, 새로운 일을 시작할 때 편하게 clone해서 사용할 수 있도록 별도로 저장소를 만들어 보았다.

퍼블리싱을 위한 언어

개인적으로는 마크업에는 Pug를 사용하고 스타일시트 작성에는 Sass를 선호한다.

Pug를 사용하면 html보다 태그를 훨씬 간편하게 작성할 수 있어서 좋다. 무엇보다 block으로 템플릿(Template Inheritance – Pug)을 작성해두면 중복된 부분을 컴포넌트화 시킬 수 있음과 동시에 여러 페이지를 빠르게 만들 수 있어서 무척 편리하다.

Sass는 partial 파일을 사용한 컴포넌트화, nesting, mixin, 변수, CSS에서 지원하지 않는 연산자, 조건문, 반복문 등의 기능을 사용할 수 있다. Sass를 한 번이라도 사용해 본다면 CSS를 직접 작성하던 시절로는 돌아가고 싶지 않을 것이다.

Gulp

Gulp는 Node.js 기반으로 개발 프로세스를 자동화시킬 수 있는 툴이다. Node.js의 Stream 인터페이스를 이용해서 특정 소스 파일에 대한 작업을 단계적으로 진행할 수 있다. 간단히 풀어내자면

Sass 소스 파일을 불러와서
CSS 파일로 변환한 후
원하는 위치에 저장한다.

이런 식으로 순차적으로 작업을 진행할 수 있다. 그리고 이어서

소스 파일에 새로운 내용이 저장되면
앞선 1~3의 과정을 반복한다.
브라우저를 새로고침시켜서 변경된 사항을 확인할 수 있도록 만든다.

이런 식의 작업이 가능하다. webpack 으로도 정적인 사이트 작업의 가능하지만(rhostem/webpack-static-site), 기본 목적이 분리된 모듈을 하나로 만드는데 있기 때문에 작업 결과물로 여러 개의 마크업 파일을 만들어내기에는 다소 불편하다. 그에 비교해 Gulp는 간단하게 소스 파일을 결과 파일로 변환할 수 있기 때문에 퍼블리싱 작업에 더 적합하다고 할 수 있다.

Pug 소스파일 처리

Gulp는 task를 선언해서 사용하며, Pug 파일을 처리하기 위한 task는 아래와 같이 작성할 수 있다.

gulp.task('pug', [], function buildHTML() {
  const pugErrHandler = conf.errorHandler('pug')
  return gulp
    .src(conf.paths.pug.src) // 소스 파일 불러오기
    .pipe(pug({ pretty: true }).on('error', pugErrHandler)) // HTML로 변환
    .pipe(gulp.dest(conf.paths.pug.dist)) // 원하는 위치에 저장
    .pipe(browserSync.reload({ stream: true })) // 브라우저 새로고침
})

pipe 메소드 덕분에 작업 과정이 무척 직관적이다. 사용자가 신경 써야하는 부분은 pug 모듈을 실행할 때 전달해야 하는 옵션, 소스와 아웃풋 파일의 위치 정도다.

Sass 소스파일 처리

gulp.task('sass', [], function() {
  const sassErrHandler = conf.errorHandler('sass')
  gulp
    .src(conf.paths.sass.src) // 소스 파일 불러오기
    .pipe(sourcemaps.init()) // 소스맵 초기화
    .pipe(sass(conf.sass.process).on('error', sassErrHandler)) // CSS로 변환
    .pipe(autoprefixer(conf.sass.autoprefixer)) // 자동으로 vendor prefix 붙이기
    .pipe(sourcemaps.write('./map')) // 소스맵 파일 생성
    .pipe(gulp.dest(conf.paths.sass.dist))
    .pipe(browserSync.reload({ stream: true }))
})

Pug와 거의 유사하다. Sass에서는 소스맵(관련 문서: Using source maps with Sass 3.3)을 생성하는 과정이 필요하다. 브라우저가 실제로 불러오는 것은 CSS 파일이기에 스타일이 Sass 소스 파일의 어느 부분에서 작성된 것인지 연결할 필요가 있기 때문이다.

아래와 같이 개발자 도구에서 특정 요소의 스타일을 검사하면 CSS 파일이 아닌 Sass 파일을 가리키는 것을 확인할 수 있다.

로컬 서버 생성

정적인 페이지는 서버를 실행하지 않고 작성해도 상관없지만 그렇게 할 경우 리소스를 불러올 때 무조건 현재 소스 파일의 위치를 기준으로 참조해야 한다는 문제가 생긴다. 웹에서 흔하게 사용하는 루트(/) 기호를 사용할 수 없다는 의미이다. 서버에 올라가지 않은 HTML 파일에서 저 루트 기호는 운영체제 파일 시스템의 루트를 가리킬 테니 말이다. 이런 문제도 있고 뒤에서 작성할 브라우저 자동 새로 고침을 위해서도 로컬 서버를 사용하는 편이 좋다.

로컬 서버로는 Browsersync를 사용한다. Browsersync는 Gulp, Grunt 같은 빌드 도구와 호환성이 좋아서 많이 사용된다. 몇 개의 옵션만 할당해주면 간단히 서버를 생성할 수 있다.

gulp.task('serve', function() {
  browserSync.instance = browserSync.init({
    startPath: '/',
    server: {
      baseDir: `${conf.paths.dist}`, // 루트 폴더 위치
      directory: true, // 디렉터리 구조를 기반으로 라우트를 구성한다
    },
    port: 4000, // 포트
    open: true, // 서버 시작시 웹페이지를 기본 브라우저에서 자동으로 열 것인지
  })
})

앞서 Pug, Sass 태스크에서 등장했듯이 browserSync 모듈은 다른 태스크에서 소스 파일 변경 시 브라우저 새로 고침에 사용된다. 그러기 위해서는 같은 서버를 사용해야 하므로 browserSync 모듈의 instance 속성에 serve 태스크 내부에서 생성한 인스턴스를 할당해서 다른 태스크의 콜백 함수 내부에서도 사용할 수 있도록 한다.

그리고 인스턴스를 생성할 때 directory 옵션을 사용하면 디렉터리 내부의 파일을 탐색할 수 있는 UI를 제공한다. 웹 브라우저에서 마치 파일 탐색기를 사용하는 것과 같으며 간단한 검색 기능도 제공하기에 작업이 진행됨에 따라 파일 개수가 늘어나면 무척 유용할 것이다.

파일 변경 탐지

Gulp에서 제공하는 watch 메소드를 사용하면 파일이 변경되었을 때 특정 태스크를 실행하도록 구성할 수 있다. 이를 통해 파일이 변경될 때마다 새로운 HTML, CSS 파일이 생성되도록 한다.

gulp.watch(소스 파일 경로, [태스크 목록])

// 파일 변경을 감지해서 pug, sass,태스크를 실행하도록 한다.
gulp.task('watch', function() {
  gulp.watch(path.join(conf.paths.src, '/**/*.pug'), ['pug'])
  gulp.watch(
    [path.join(conf.paths.src, '/**/*.scss'), path.join(conf.paths.src, '/**/*.sass')],
    ['sass']
  )
})

다양한 Gulp 플러그인의 활용

글에서는 Gulp로 가능한 최소한의 작업만 소개했을 뿐이다. Gulp는 수많은 개발자의 참여를 통해 만들어진 다양한 플러그인을 통해 더 많은 일이 가능하다. 글을 작성하는 시점에 3500여 개가 넘는 플러그인이 등록되어 있으니 만약 사용하고 싶은 기능이 있다면 이미 구현되어 있을 가능성이 매우 높다. 그리고 Gulp를 잘 활용하려면 Javascript는 물론 Node.js의 파일 시스템과 스트림에 대한 이해가 조금 필요하긴 하지만 학습에 투자할 가치는 충분하다고 생각한다.

blog.rhostem.com

[번역] 자바스크립트 프레임워크의 네 시대

예전 시대 (The Before Times)

최초의 프레임워크

컴포넌트 중심 뷰 레이어

풀-스택 프레임워크

다음은 어디로 갈까?

React hook 테스트 코드에서 Recoil snapshot 참조하기

Recoil 상태를 엿보기 위한 컴포넌트 구현

컴포넌트의 props를 조작하면 어떤 문제가 생기는가?

References

Canvas, Web Audio API를 사용한 웹 오디오 플레이어 제작기

제작 동기 및 요구사항

소리의 디지털화에 대한 이야기

Web Audio API를 사용한 샘플링 데이터 추출

샘플링 데이터의 리샘플링

샘플링 데이터 정규화(normalizing)

Canvas API를 사용한 도형 그리기

requestAnimationFrame 함수

오디오 파형 그리기

CanvasRenderingContext2D 인터페이스

devicePixelRatio 값에 맞춰서 scale 조정하기

배경 그리기

샘플링 데이터로 그래프 그리기

오디오 재생 기능 구현

오디오 플레이어 시각화

오디오 재생 / 멈춤

캔버스 파형 클릭시 오디오 탐색

나머지 구현 사항

References

Recoil의 쓰기 가능한 셀렉터

파생된 상태를 만드는 단방향 흐름의 selector

쓰기까지 가능한 양방향 흐름을 가진 selector

쓰기 가능한 selector의 초기화 기능

언제 사용하면 좋은가?

useRecoilTransaction을 사용한 Recoil 상태 업데이트

참고 자료

React 커스텀 훅 함수의 테스트 코드 작성

커스텀 훅은 React 함수형 컴포넌트 API를 사용하는 함수

react-hooks-testing-library를 사용한 커스텀 훅 테스팅

커스텀 훅의 상태(state) 업데이트 테스트

useEffect 실행 확인 테스트

Context를 사용하는 커스텀 훅의 테스트

비동기 코드가 포함된 커스텀 훅의 테스트

관련 자료

Vue 3의 setup 기능이 제공하는 간결한 컴포넌트 문법

Composition API 와 setup 함수의 등장

커스텀 훅을 사용한 로직 분리 및 재활용

script setup 문법

setup 기능의 장단점

장점

단점

Recoil atomFamily를 사용한 상태 관리

Recoil에 대한 간략한 소개

atom으로 할일 목록 관리

atomFamily

atomFamily로 할일 상태 구현

참고자료

Tailwind CSS의 설치와 활용

Tailwind CSS의 특징

클래스 자동완성을 위한 Tailwind CSS Intellisense

Tailwind CSS 설치

PostCSS 설정 파일

Tailwind 설정 파일

베이스 CSS 파일

CSS 파일 변환 npm 스크립트 추가

앱에서 생성된 스타일시트 가져오기

개발 서버 실행 스크립트

Storybook 설정

Tailwind CSS 활용

JIT(Just-in-Time Mode) 모드

테마 확장

Variants

다크 모드

Tailwind CSS 2의 Postcss 7 호환 버전 설치

Twin 라이브러리로 CSS-in-JS 스타일로 사용하기

Tailwind CSS 유저 커뮤니티

관련 자료

linear-gradient 속성에 transition 적용하기

Linear gradient를 사용한 텍스트

`CanvasRenderingContext2D` 인터페이스

`devicePixelRatio` 값에 맞춰서 scale 조정하기

`useRecoilTransaction`을 사용한 Recoil 상태 업데이트

Composition API 와 `setup` 함수의 등장

`QueryClientProvider` 설정

`useQuery`로 서버 데이터 가져오기

`useMutation`으로 서버 데이터 업데이트

`mount`

`plugin`

`installOptions`

`devOptions`

`buildOptions`

`proxy`

`alias`

`testOptions`