[190903] JSConf Korea 2019를 다녀와서...

구글 검색을 통해 얻은 JSConf 이미지

JSConf Korea는 세계 각국에서 열리는 JSConf의 일환으로 2019년에 한국에서 처음으로 열리는 행사다. 이러한 행사에 운좋게 양도티켓을 얻어서 참가할 수 있었던 것은 정말 행운이었다. (그것도 얼리버드 티켓으로...ㅎㅎ)

 

사실 예전부터 로망이었는데 이렇게 규모가 있는 컨퍼런스에 꼭 참여해보고 싶었다. 그러나 규모가 큰 행사는 대부분 평일에 열리기 때문에 회사 다니면서는 연차내고 겨우 NAVER TECH CONCERT: FRONT END 2019 에 한 번 참여했었다. 이것도 운좋게 당첨이 되서 갈 수 있었는데 당시 회사에서는 컨퍼런스에 간다고 하니 지원은 커녕 '뭐 다녀와도 상관은 없지만 큰 도움은 안될거다' 라는 식으로 말하고 그냥 내 연차를 하루 써서 다녀와야 했다.

 

그렇게 발전없는 회사를 나오고 나서 백수가 된 이후로는 유럽 여행 다녀오고 놀다보니 또 크고 작은 컨퍼런스 정보를 놓쳤었다. if kakao 개발자 컨퍼런스 2019 가 그 중 하나인데 어차피 이건 당첨 안되면 못간다고 하니 진즉에 포기했다. 그러나 JSConf는 티켓 구매 형식이라서 양도해주는 사람이 있다면 갈 수 있었다. 내가 속한 웹 개발 오픈채팅방 중 한 군데서 누군가 양도를 원한다길래 냉큼 내가 받겠다고 했고, 워낙 순식간에 양도를 받게 된 터라 얼떨떨했지만 갑자기 얻은 기회에 학구열이 불타올랐다. 얼리버드 티켓은 69,000원이었는데 다녀와서 보니 그 금액 이상으로 얻은게 많았다. 점심 10,000원 쿠폰에 각종 굿즈, 그리고 훌륭한 강의들까지...

 

그 날의 전리품들

내 지식이 미천하여 모든 발표 내용을 이해하지는 못했다. 그래도 일단 그 날 필기한 것들과 내 기억력을 총동원해서 정리해 보기로 했다.

이번 컨퍼런스는 라이트닝 토크의 경우 자리이동이나 정신없는 분위기 속에서 진행된 점, 또 외국인 강연의 경우 내가 통역본으로만 알아들을 수 있다는 점 등등 네이버 컨퍼런스 때와는 다르게 발표 시간과 주기도 짧고 여러 행사들을 동시에 여러 공간에서 진행하기 때문에 자기가 발로 뛰고 노력한만큼 얻을 수 있는 치열한 행사였다. 그래도 나름 열심히 듣고 적었기에 새로운 영감과 정보를 많이 얻을 수 있었던 시간이었다.

 

주의 : 아래 목록이 모든 일정을 포함하고 있지 않으며 주관적인 생각과 잘못된 정보가 포함되어 있을 수 있습니다. 공식 시간표를 보시려면 여기를 참고하세요.

 

10:10 ~ 10:40 [메인발표] 다마고치로 배우는 제너레이터

발표자는 어릴적 가지고 놀던 다마고치 게임을 JavaScript로 만들어 보면서 겪은 다양한 시행착오들을 설명해 주었다.

다마고치 게임의 캐릭터가 살아숨쉬는 것처럼 보이도록 위아래로 바운스하는 모션을 만들기 위해서는 위로 올라가는 모션이 끝난 시점을 알아야 다시 내려가는 모션을 넣을 수 있다.

그걸 가능하게 하기 위해 Generator함수와 yeild를 사용했는데, 이 키워드들을 나는 처음 접했기 때문에 MDN 문서를 보고 조금이나마 이해했다. 이 키워드는 이 후 다른 발표에서도 언급되었는데, 앞으로 공부해야할 필수 키워드인것 같다.

해당 발표는 여기까지 듣다가 굿즈받으러 나가서 강제 생략.

 

11:10 ~ 11:30 [라이트닝토크] NPM Package를 활용한 사내 공용 라이브러리와 컴포넌트 관리

사내에서 반복적으로 쓰는 코드를 npm으로 배포하여 팀원들간에 공유하는 것에 대한 발표였다.

자주 사용하는 UI 컴포넌트를 작성하고 npm으로 배포하고 각 팀원이 npm install로 가져다 쓰면 된다.

배포시에는 주로 '@회사명/패키지명' 이런식으로 패키지명을 정한다.

React에서 Hook을 사용하면 컴포넌트에서 공통된 로직을 쉽게 분리할 수 있다.

기존에 사용했던 HoC(하이오더컴포넌트)나 render props보다 간편하다. (특히 디버깅 측면에서)

기본 Hook으로 먼저 작성한 뒤 커스텀 Hook으로 분리해보면 된다.

또한 Hook으로 작성하면 컴포넌트 단위의 개발환경 지원 도구인 Storybook에서 확인하기 편하다.

 

12:00 ~ 12:30 [메인발표] 오픈소스 프로젝트 mocha에서 배운 것들

변정훈님의 발표로 mocha 메인테이너로서 1년간 활동하면서 겪은 일들을 말씀해주셨다. 이 분은 '아웃사이더 블로그'로도 유명한 분인데 그동안 내가 구글 검색을 통해 굉장히 많이 방문했었던 블로그이기에 글쓴이가 궁금했었는데 마침 이번 컨퍼런스에 발표자로 나오셨다. 해당 블로그에 방문해보니 이미 JSConf 발표자료를 올려주셨다.

 

발표자는 회사를 그만두고 쉬는 동안 다양한 오픈소스에 기여했었는데, 그 중 마침 mocha 프로젝트에서 메인테이너를 구했고 짧은 기간동안 비교적 많은 풀리퀘스트를 올렸던 발표자에게 메인테이너로 활동하자고 제안이 왔다. 거기에 승낙을 하면 메인테이너로 활동을 하게 되는데 생각보다 많은 일들을 처리해야 한다.

먼저, 메인테이너들에게는 해당 오픈소스에 이슈가 올라오면 알람이 울리는데 이것들을 지속적으로 처리해야한다. 유명한 오픈소스일수록 알람이 쉴 새 없이 온다고 한다. 해당 이슈를 확인하고 해결할 수 있는 이슈는 댓글을 달고 바로 클로즈 해버린다. 그러나 각 이슈는 최소한 직접 실행해보고 테스트해봐야하기 때문에 소요되는 시간이 꽤 길다.

또한 테스트 하기 위한 정보가 부족하다싶으면 메인테이너가 MCVE를 요청한다. (MCVE: minimal, complete an verifiable example의 약자로 해당 에러가 발생한 환경이나 최소한의 코드)

만약 이슈에 대해 안건이 생기면 컨트리뷰터들끼리 채팅하면서 이슈에 대한 논의도 한다. 발표자는 영어로 자신의 의사를 표현하는것이 가장 힘들었다고 한다.

페이스북이나 기타 대기업에서 만든 오픈소스들은 해당 라이브러리를 발전시키고 유지하기 위해 풀타임으로 투입되는 사람들이 있을테지만, mocha와 같이 개별 컨트리뷰터로 유지되는 오픈소스는 메인테이너들이 대부분 각자 자신의 생업이 있고 오픈소스 기여는 부업으로 하는것이기 때문에 굉장히 바쁘고 힘들다고 한다. 퇴근 후 2-3시간씩 투자해야 겨우 이슈를 놓치지 않고 따라가는 수준이라고...

그래서 메인테이너가 장기적으로 오래 활동할 수 있도록 모임에 강제로 참여시키거나 하는 압박을 주지 않는다고 한다.

그리고 혹여나 메인테이너가 잘못된 PR을 했을 경우 롤백 처리된다.

 

또 이슈를 처리할 때 고충 중에 하나로 오래된 이슈를 꼽았는데, 클로즈된 이슈임에도 불구하고 같은 오류가 발생하는 사람들이 계속해서 댓글을 단다고 한다. 그러나 클로즈된 이슈에 댓글 달아봤자 재오픈 안되니까 차라리 링크를 걸어서 새로운 이슈를 올리라고 했다. 그래야 처리해줄 확률이 높다고.

그리고 node.js LTS 정책은 메인테이너들에게도 좋다고 했다. 왜냐하면 node 자체에서 지원을 종료했기 때문에 레거시 코드를 계속 안고가지 않아도 되고 지원되는 기능 안에서만 처리하면 되기 때문이다.

마지막으로 누군가 한 좋은 말이라면서 한 트윗을 보여주었다. "오픈소스를 상품처럼 다루지 말고 자기가 속한 팀의 제품처럼 다뤄달라."

 

14:10 ~ 14:40 [메인발표] 생명을 살리는 자바스크립트와 인공지능

자바스크립트로 인공지능 기능을 도입해서 서버를 거치지 않고 웹브라우저 위에서 데이터를 도출할 수 있는 방법에 대한 발표.

 

패혈증 - 급성질환 중 사망 비중이 높은 질환. 해당 질환을 사전에 파악할 수 있도록 다양한 데이터를 학습시킨다. 그러나 AI는 언제나 맞는 결과를 주지는 못한다. 강아지와 고양이 사진들을 학습시키고 갑자기 호랑이 사진을 보여주면 AI는 제대로 된 답을 주지 못할 것이다. 사람의 목숨이 달린 상황에서는 1%의 예외가 굉장히 크리티컬 할 수 있다.

 

TensorFlow.js를 이용해서 웹브라우저 위에 인공지능을 디플로이하는게 가능해졌다. 1분 1초가 급박한 상황에서는 백엔드까지 갔다오는데 시간이 걸리기 때문에 브라우저 위에서 텐서플로를 돌린다.

자바스크립트로 AI모델 학습 테스트 - 라이브러리 : jsverify, fast-check

redis로 모니터링

 

인공지능의 가장 중요한 부분은 프론트엔드다. 머신러닝을 통해 얻은 데이터를 의사들이 식별 가능한 아웃풋으로 보여줘야 하기 때문이다. 그런 의미에서 비주얼라이징에 수월한 자바스크립트를 사용하는것에 큰 장점이 있다.

 

14:40 ~ 15:10 [메인발표] 백 투 더 퓨처 오브 자바스크립트 II: 미래를 넘어

자바스크립트의 미래에 대한 발표로서 해당 발표 내용은 공식적으로 확정된 것이 아니고 나중에 충분히 바뀔 수 있는 부분이기 때문에 그 점을 유념해서 들으라고 했다. 해당 정리는 발표 내용을 깊이 이해하지 못하여 키워드 나열 식으로 정리했음에 유의하길 바란다.

 

1. 패턴 매칭

2. 파이프라인 연산자

3. 바이너리 AST

3가지와 몇가지 견해가 발표의 순서였다.

 

1. 패턴 매칭

원래 조건문은 3가지 : if/else, switch, 3항 연산자

if/else문은 두세가지 선택지일 경우, 또한 수행해야 할 코드량이 많은 경우에 적합하다.

switch는 선택지가 많은 경우 적합.

여기서 조건문 한가지가 추가 된다면? 그것이 바로 패턴 매칭!

 

2. 파이프라인 연산자

함수 합성이란? 함수 여러개를 체이닝으로 연결하는것.

파이프라인 연산자는 함수 매개변수에 함수 또 그 함수 매개변수에 함수를 넣는 과정을 편리하게 만들어준다.

 

JS cold start

에디오스만 표현을 빌려온것 : 스크립트 태그를 발견하면 텍스트 내용 다운하고 자바스크립트 파싱 -> 그 내용 바탕으로 추상구문을 하게 됩니다. 이것을 넘어가면 브라우저로 가고 그리고 여기 나머지 단계는 브라우저 최적화와 관련된 얘기입니다.

자바스크립트 라이프싸이클 - 실행 최적화, 역최적화

 

압축되지 않은 자바스크립트 1MB 같은 경우 파싱에만 1초정도 걸림

이 문제를 해결하기 위한 것이 바이너리 AST

자스 작성  -> 바벨 등 컴파일러를 통해 컴파일 -> 그리고 여기에 추가적으로 바이너리 AST를 통해 프리파싱된 것을 얻을 수 있다.

파싱은 대부분 빌드 타임에 이루어진다.

스파이더 몽키의 내부 AST 형식을 기반으로 하고 있다.

 

15:10 ~ 15:30 [라이트닝토크] 우아한형제들의 개발팀 이야기

프론트엔드 개발자 25년차 김민태님.

배민닷컴 웹페이지 존재하긴하지만 서비스는 안함. 앱에 집중하기 위해 있었는데 없앰.

네이버 플레이스와 제휴맺어서 웹으로 주문이 들어오긴 함.

 

배민에서 운영하는 웹 서비스는?

배민 사장님광장 서비스 - 모두 모바일, 데스크탑버전 웹으로만 제공. 이미지 에디터를 만들거나 라이브러리도 오픈소스화 하려고 함.

배민상회 - 가게 식자재 쇼핑몰같은느낌

배민장부 - 가게 매출 확인.

만화경 - 최근 새로운 웹툰 서비스 오픈

 

배민 사용자는 주로 배고픈 상태에서 트래픽을 발생시키는데 여기서 문제가 생기면 더 화가남.(ㅋㅋㅋ)

이 부분을 해결하기 위해 다양한 챌린저를 경험하게 됨. 특히 백엔드. 해결하면서 성장 가능.

 

WoowahanJS - 당시 적정기술로서 오픈소스 프레임워크 만들었었음. 

지금은 사용안하고 대부분 React + TS

 

코드리뷰 - 젯브레인 UP소스? , 페어코딩

 

개발 문화

-다른 회사보다 기술선택의 자유도가 엔지니어한테 많이 주어진다.

-9시 1분은 9시가 아니다 : 현재는 없어진 카피지만 플렉서블한 출퇴근은 아니다.

 

15:30 ~ 16:00 [메인발표] 함수형, Redux와 Canvas에 적용하면서 배워나가기

Redux, mobX 등등… 상태 관리 도구

 

함수형 프로그래밍

-단순한 순수 함수 연결이기 때문에 안정적이고, 작은 단위 함수라서 재사용성 높고 상위 로직 파악이 쉽다.

 

함수에 인자 넘기는 걸 최소화 하면서 각 Reducer 코드 분리

미들웨어에는 부수적인 코드만 작성

 

Ramda.js - 커링(currying)과 합성이 주특기인 함수형 라이브러리

pipe - 함수들을 순차적으로 합성해주는 기능. / compose도 합성기능이지만 순서가 반대로 작동되서 읽기 불편함.

 

자료구조는 적게, 실행은 많이.

 

curry - 어떤 함수를 curry로 감싸면 차례대로, 한꺼번에 실행 할 수 있게 해줌.

실행 순서가 반대로 될 때는 "function_name(__, 10)" 이런식으로 인자에 플레이스홀더(__)라는 것을 넣어줌.

 

 

16:00 ~ 16:30 [메인발표] Typescript로 디자인 시스템에 날개 달기

디자인 시스템이란? 하나의 교과서라고 할 수 있다. 디자인에 필요한 모든 것을 모아놓은 것.

디자인 시스템에는 규칙이 포함되어있다. UI와 제품 코드와 관련해서 엄격한 규칙을 제공한다. 따라서 디자인 시스템을 사용하면 모든 팀 동료가 같은 환경에서 작업하고 디자인 코드를 실행 할 수 있다.

이러한 디자인 시스템은 사내 디자이너와 개발자를 고객으로 볼 수 있다.

소프트웨어부터 다큐멘테이션 매니징과 관련한 모든것을 다 포함한다.

컴포넌트 개발에 초점을 맞춘다. 작게는 하나의 버튼 크게는 하나의 모듈을 다룬다.

 

react와 typescript를 사용해서 컴포넌트를 사용의 명확성을 높인다.

 

디자인 시스템 내의 타입스크립트는 디자이너에겐 자신의 디자인이 명확하게 구현된다는 신뢰를 주고 개발자에겐 사용의 유용성과 명확성을 제공함.

또한 인터페이스를 노출시키면서 개발하게 해준다. 타입스크립트는 개발자들이 공개된 api에 집중하게 해준다. 그 안에 코드는 알 필요 없이.

타입스크립트를 사용하면 버그가 15% 줄어든다.

 

의도는 효과를 따라간다(?)

오픈소스 라이브러리 사용은 좋지만 메인테이너에게 어떤 영향을 미칠지, 또 해당 소스의 안정성 등을 확인해봐야한다.

 

16:30 ~ 16:50 [라이트닝토크] JS Bundle 사이즈 최적화를 통한 성능개선

'하이퍼커넥트'라는 기업에서 자신들의 테스팅하는 방식과 번들링 방식을 소개하고 최적화를 통해 성능을 높인 사례를 소개하였다.

 

Testing Tool

 유닛 테스트 - jest

 e2e 테스트 - cypress

 

CI

(지속적 통합 - 여러 개발자가 개발한 소스코드를 모아서 한번에 빌드하는 통합 과정을 주기적으로 수행하는것 / 블로그 참고)

Buddyworks 사용

PR 생성시 유닛 테스트

5분에 한번씩 실서버 e2e test - cypress

배포시에 calibre로 성능 지표 기록

 

번들러

webpack을 사용하는데 해당 서비스를 번들링하면 크게 3가지로 나눌 수 있다.

static 한뭉태기, translations 한뭉태기, react-into 한뭉태기

 

번들링 사이즈를 줄이기 위해 시도한 방법들

1. react-intl => react-i18next로 대체 

빌드 후 사이즈가 더 작았고 문서화가 더 잘되어 있어서 리팩토링 시도.

 

2. 번역 파일 불러오는 방식 동적으로 변경

const tl = require(); -> 경로에 있는 모든 파일 불러오기

const tl = await import(‘./‘) -> 빌드타임에는 합쳐지지 않고 런타임 시에만 필요한 파일 불러옴

webpack dynamic import 방식

 

3. 스태틱 파일 불러오는 방식 변경

webpack url-loader에서 일정 크기 이하의 이미지는 base64로 인코딩하여 js 컴파일 시 코드에 넣는다.

url-loader 사용안하는걸로 옵션 변경.

 

성능측정 결과는 calibre 사용하였다. (FMP, TTI, SPEED INDEX)

처음 사이즈보다 60% 줄이는데 성공.

 

결론

적절한 패키지 선택할 때는 문서화 정도와 빌드 사이즈 등을 종합적으로 고려해야한다.

크기가 크고 갯수가 많은 파일은 dynamic import 하자.

webpack 이미지 인코딩 옵션처럼 최적화 옵션이 때로는 성능을 더 악화시킬 수 있다.

번들 사이즈 최적화를 통해 Cold Start시에 빠른 로딩 가능하다.

 

16:50 ~ 17:20 [메인발표] 적어도 캡 70개 어치는 하는 웹어셈블리 지침서

해당 발표는 거의 이해를 못했다. 발표자는 MDN에서 활동하며 모질라 테크 스피커라고 했고 굉장히 빠른 말투로 심오한 내용의 이야기를 심오한 비유와 함께 얘기해 주었다. 통역해주시는 분이 아웃사이더처럼 열심히 말해주셨지만 따라가기에는 벅찼다. 

그래도 중간 중간 겨우 이해하거나 그냥 받아적은 부분들을 혹시나 하는 마음에 남겨본다.

---

역사는 맥락이 중요하다. 역사 자체가 중요한 것이 아니라 역사를 통해 얻는 맥락이 중요하다.

웹 플랫폼의 문제를 해결하기 위해 웹어셈블리가 만들어졌다는 맥락이 굉장히 중요하다.

 

웹 어셈블리란 모든 언어로 만들어진 웹을 구동하는 실행, 보안성을 보장하면서 하위 레벨 바이너리 포맷하는 기술.

처음에 만들어졌을 때와 유사한 속도로 실행 가능하다.

2015년에 웹 어셈블리 기술이 나왔다.

2013년에 asm.js 선보였다.

 

웹 어셈블리는 핵심적인 원칙에 의해 만들어졌다.

기존의 것을 바꾸는 것이 아니라 보강하고 보충하기위해 만들어졌다.

 

17:20 ~ 17:50 [메인발표] The Man who Sold the Amp: 자바스크립트로 음악 처리하기

이 발표는 기술에 관한 것도 대단했지만 직접 기타를 연주하면서 다양한 소리와 음악을 들려주었다는 점에서 짧은 락 공연을 본 느낌도 들고 굉장히 흥미로웠다. 실제로 객석에서 박수와 휘파람이 나오기도 했다.

아래는 당시 상황을 녹화한 영상이다.

 

 

이 분은 자바스크립트로 음악을 처리하고 다양한 효과를 넣어 소리내기 위해 컨트롤한 다양한 방법들을 소개하였다. 이것도 대부분 이해하지 못하였지만 일단 당시 노트한 것들은 다 남겨두기로 했다.

 

input -> effect -> output

오디오 키보드와 악기를 연결.

Gain Node 사용

const context = new AudioContext();

오디오 컨택스트가 있어야만 데스티네이션과 연결시킬수있다.

미디어 디바이스를 사용한다.

오디오와 관련된 몇 가지 제약 조건을 고려해야한다.

대부분 브라우저에서는 기본값으로 인풋 스프림에 대해서 사후 처리를 한다.

 

볼륨값 조절은 사인 곡선 조절을 통해 이루어진다. gainNode에 밸류를 지정해주고 숫자를 변경하면서 볼륨을 조정한다.

 

디스토션 이펙트는 메탈 등에서 사용된다.

옛날에는 기계를 부셔서 내던 소리 효과인데 이제는 기계를 부시지 않고도 그 효과를 낼 수 있다.

 

사실 음향이라는 것은 프리퀀시가 하나가 아니다. 이것들의 조합을 하모닉이라고 하는데, 헤르츠에 따라 대역을 나누고 Biquead Filter Nodes객체를 사용하여 bass, mid, treble 3가지 대역의 각각 범위를 지정한다.