일상 - FE CONF 2018 후기

일상

:FE CONF 2018 후기

fe conf는 작년 처음 진행되었고, "프론트엔드를 개발하며 마주했던 치열한 고민과 깊은 인사이트를 공유하며 함께 성장하자"는 모토를 가지고 진행되는 컨퍼런스입니다. 세션은 track1과 track2로 분리되어 진행 되었는데요. 각자 장소를 옮겨가며 듣고 싶은 세션을 들을 수 있게 다채롭게 구성되었었습니다.

https://2018.feconf.kr/

| 세션별 후기

11:10 - 11:50

> 미국 개발자 vs 한국 개발자 - 켄님

일단 이 세션에서는 미국 개발자 들과 한국 개발자들의 다른점 그리고, 이러한 개발자들이 어떠한 환경에서 개발을 하고 있는지에 대한 여러 차이점들에서 발표를 해주셨습니다.

먼저, 개발능력에 관해서 설명을 해주셨는데요. 구글 코드 잼 사례를 들어, 코드잼에 한국인들도 상위에 랭크되기도 하지만, 미국인들이 훨씬 더 많이 랭크 된다고 합니다. 그런데 그렇다고 해서, 미국인들이 한국인들보다 더 뛰어난 개발자다? 라는 생각은 성급한 일반 화라고 말씀해주셨습니다. 발표자 분은 미국에서도 많은 개발자 커리어를 가지고 계셨는데요. 미국과 한국의 개발자들의 논리력은 사실 비슷비슷하다고 하였습니다.

하지만  기술의 트렌드를 따라가기에는 영어로 되어있는 docs나, 글들이 많기 때문에 이러한 면에서는 미국 개발자들이 더 유리한점은 있다고는 말씀해 주셨습니다.

그리고는 협업이라는 키워드에 대해서 설명해주셨습니다. 이는 미국쪽이 더 뛰어나다고 말씀 해주셨었는데요. 협업은 어떤것인지 생각해보면 어떤 툴을 쓰는가, 또는 이슈 트래킹 잘하는가로는 모두 판단하기는 어렵다고 말씀해주셨습니다. 그리고, 많은 한국 회사들에서 내세우고 있는 영어이름을 씀으로써 수평적 관계를 유지하여 좋은 협업을 만들어 낸다고 하는 사례를 들면서, 과연 그런가라는 의문을 제시해주시기도 했습니다 ㅋㅋ 

그럼, 어떠한 점들에서 미국이 더 뛰어나다고 말할 수 있냐고 질문을 던지면 다음으로 시스템을 생각해볼수도 있다고 해주셨는데요. 물론 미국의 업무 시스템은 꽤 체계적이라고 합니다. 실수같은 것도 시스템으로 많이 보완해주기도 한다고도 합니다.

그리고 프론트 개발자와 협업이라는 키워드에 빗대서 발표를 이어나가셨습니다. 프론트 개발자들은 절묘한 위치에 있다고 말씀해주셨습니다. PM팀, 그리고 디자인팀, 백엔드팀과 많은 커뮤니케이션이 있기 때문이죠.

그리고 한 사례를 들며 미국의 협업에 대해 설명을 이어나가 주셨습니다.

발표자 분이 한 팀에 합류 하게되어 아마존에서 3달만에 개발 부터 배포 (스케일링, qa) 한 사람이 있는 사람을 필두로 한 시니어만 있는 팀에 합류를 했는데 대부분 아래와 같은 특징을 가진 사람들이었다고 합니다.

• 해야할 업무에 대한 확실한 정의.
• 자신이 하는일에 대해서 긴밀히 커뮤니케이션.
• 상대방의 업무 영역을 존중.
• 하나의 유기체 같이 행동.

위의 요소들을 생각하며, 프로그래밍 실력이 다가 아니고, 이런 요소들이 협업에서 매우 크게  중요하다고 생각하였습니다. 또한 설명을 덧붙여, 시스템을 갖춰놓는다고 다 잘되는 것은 아니고, 소통할때의 제스처, 행동들 등등 사람이 협업에서 가장 중요한 요소들이 중요하다고 말해주셨습니다. 그리고 이러한 경험들을 미국에서 많이 가지셨었구요.

다음은 Individual mindset에 대해서 말씀해 주셨습니다. ux를 프론트 개발자라면 항상 생각하게 되는데, 내가 지금 만드는 화면이 사용자에게 어떤 영향을 끼칠것인가라는mindset 을 항상 가지는 것을 중요하게 말씀해주셨습니다.

마지막으로, 부품 으로써의 한명이 아닌, 조직내에서 유기체 처럼 행동 하는 것, 또한 나만의 생각을 가지고 본인의 목소리를 내고있는가 역시도 강조해주시며 발표를 마치셨습니다.

12:00 - 12:40

> Redux - saga, 제너레이터, 사이드이펙트, 채널 - 이민규님

리덕스와, 리덕스 saga를 사용해본 입장으로써, 관심있게 들었던 세션입니다. 세션은 왜 리덕스 사가를 쓰는지, 그리고 이러한 리덕스 사가의 여러 요소들을 토대로한 개념 설명, 어떻게 더 유용하게 쓸수 있는지의 순서로 진행해주셨습니다. Why redux saga 챕터에서는 비동기 문제를 해결할때 redux-thunk 말고, 왜 리덕스 사가를 쓰는지에 대해서는 아래와 같이 설명해주셨습니다.

• thunk는 추적이 힘들고

• 테스트가 어렵고 

• 패턴을 직접 만들어야 하고 지켜야 한다

• action 생성함수 반환이 action object x.

한번 사용을 해보고 세션을 들었던 터라, 크게 공감이 가는 요소들이였습니다. thunk를 짧게 써보고, saga를 적용했을 때 들었던 생각은, 사가 함수 flow를 따라가며 디버깅하기가 thunk를 쓸때 보다 훨씬 더 수월했고, redux thunk를 사용할때는 직관적으로 flow를 만들어내기가 어려웠으며 이렇게 액션생성함수에 action object만 return 하는게 아니라, 자신만의 패턴으로 오염시키다 보니, 직관적으로 비동기 문제를 해결하지 못했었습니다. 그리고 아래와 같이 saga의 장점에 대해서 설명해주셨습니다.

• 관리하기 쉬움
• 테스트 쉬움
• 적당한 패턴으로 서비스 로직 쉽게만듬
• 비동기적인 것들은 사가에게 위임, 액션 생성자 와 리듀서는 순수하게 놔두는 기본 철학을 지킴

위의 요소들 역시 크게 공감하였습니다. 처음 러닝커브가 높아서 그렇지, 액션을 take하고, 그안에서 api call해서 받아오고 그렇게 가공한 데이터를 액션생성함수를 거쳐 리듀서에 전달하는등의 여러 패턴들이 나름 정형화 되어있어 한번 saga를 사용해서 flow를 처리해보면, 다른 작업들 역시 비슷한 패턴으로 코드를 복붙해서 조금 변경하여 로직을 쉽게 만들 수 있었습니다. 그리고 액션 생성함수와 리듀서 역시 순수하게 그 역할만 수행하므로, 디버깅 할때도 사가함수만 디버깅 하면 되니 위에서 말했던 장점들 역시 그대로 체감했었습니다.

다음은 saga의 Concept에 대해서 설명해주셨습니다. 먼저 Side effect (부수 효과라고 해석, 자바스크립트 관점에서는 외부 세계에 영향을 주거나 받는것) 는 아래요소들로 설명할 수 있다고 하였습니다.

• 비동기 요청
• 브라우저 캐시
• 로컬 스토리지

그리고 아래 사진을 보면 알 수 있듯이, 이러한 사이드이펙트를 해결하기 위해 saga의 컨셉이 도입된 것이구요.

다음은 Generator에 대해서 아래와 같이 두 요소로 나뉠수 있다고 설명해주셨습니다.

• Callee (generator function)
• Caller (Runner)

그리고, saga readme 에도 나와 있지만, 사가에 대해서 아래와 같이 설명하고도 있다고 말씀해주셨습니다. 즉, 애플리케이션의 thread 같은 역할을 사가가 해주고 있다는 점이죠.

“The mental model is that a saga is like a separate thread in your application that’s solely responsible for side effects.”

그리고, 사가에 대해서 설명할때 빼 놓을 수 없는 effect에 대해서는 아래와 같이 명료하게 설명해주셨습니다.

• Effect
• 작업을 해달라고 표현하는 방식
• 이펙트는 미들웨어에 의해 수행되는 명령을 담음
• 모든 이펙트는 처리가 끝날때까지 기다려야 하는건 x blocking event 와 non blocking event 존재
• Blocking event, non blocking event
• Take, call, join (blocking), put, fork,cancel( not-blocking)

그리고 외부이벤트 (ex web socket) 와 saga를 연결하는 방식에 대해서도 설명을 해주셨습니다. push와 pull의 개념으로 이를 설명해 주셨는데요. socket은 push 방식, 그리고 saga는 pull 방식으로 빗댈수 있다고 하였는데, 이러한 push 방식을 pull 방식으로 바꿔주는 패턴을 제시해주셨습니다.

그리고, defferd 개념을 추가해서 설명해 주셨는데요. 아래와 같이 promise를 활용해 단계가 추가된것입니다.

그래서 saga의 call effect와 활용하면 아래와 같은 패턴으로 사용할수 있게 되는거죠.

그리고 이러한 과정 역시도 일반적인 프로세스를 saga에서 만들었다고 합니다.이에 대한 자세한설명은  링크를 참조하면, actionChannel에 대해서 자세히 설명히 나와있으니 참고 바랍니다. 그리고, 리덕스의 action 역시도 saga 내부의 channel을 사용해 전달한다는 흥미로운 사실 역시도 알게 되었습니다.

다음은 saga를 잘 사용하는 활용방안에 대해서 설명을 들을 수 있었습니다. 중복되는 액션을 받을때는 takeLatest effect를 활용하면 제일 마지막 액션을 받을 수 있다고 설명해 주셨습니다. 이는 처음 saga 학습할때 docs 문서에서 봤었던 기록이 새록새록 났습니다 ㅎㅎ 이러한 이펙트를 사용하는 경우는 카테고리를 여러번 반복해서 클릭할때 리스트를 fetch하는 경우를빗대어 설명해 주셨습니다. 

그리고, 파일 업로드를 하여 progress 보여줄때는 채널로 해결할 수 있다고 아래와 같이 설명해주셨습니다.

마지막으로는, redux-saga의 테스트를 쉽게 도와주는 redux-saga-test-plan에 대해서 소개하며, 또한 테스트 코드를 작성하다보면 테스트코드와 구현 코드 커플링을 겪을수있다는 당부의 말씀과 함께 발표를 마쳐주셨습니다. 그리고, 처음 배우기는 어렵지만 조금 익숙해지면 정말 편한 side effect layer가 될것이라는 점에 대해 사용해 본 입장으로 크게 공감하였습니다.

14:00 - 14:40

> React component와 D3 Object를 유기적으로 연결하는 전략 - 박승현님

이 세션에서는 react와 d3를 어떻게 유기적으로 연결했는지 설명해주는 세션이었습니다. d3를 활용해본 경험이 없고, 또 아직은 미흡한 개발실력 때문에 ㅠㅠ.. 크게 공감하고 이해는 하지 못했지만 여러 과정에 대해 설명을 흥미롭게 들을 수 있었습니다. 

먼저 다른 html요소 처럼 dom element로 취급되는 svg에 대해서 간략히 설명을 해주셨고, 이를 활용한 여러 차트 라이브러리에 대해서 설명해주시고, 어떠한 장단점들이 있는지 설명해주셨습니다.

chart.js 는 확장성 문제가 있었고 rechart.js 는 react와 d3.js를 바인딩 했지만 확장이 어렵고 d3코드 건드리기 어려운 단점이 있었다고 하셨습니다.

그렇게 해서 결론에 도달한 d3.js에 대해서 아래와 같이 특징을 설명해주셨습니다.

• 데이터를 바인딩 하는 라이브러리 ,차트라이브러리 x
• 차트 뿐 아니라, 지도, 불특정 도형에도 쓰임

다음으로는 먼저, d3.js와 리액트를 합치는 과정에서, 아래와 같은 점들때문에 어려움을 겪으셨다고 하였습니다.

• d3도 나름의 돔 조작을 해서 react와 conflict
• 리액트의 dom tree 안에서 performance 저하

그리고,  react 와 integration하는 과정에서 어떻게 최적화 해 나갔는지 두가지 사례를 통해 설명해주셨습니다. 

• 해결책 1
• 리액트에게 svg의 모든 control 권한을 주었음
• 리액트가 모든 역할
• d3는 계산의 역할
• Data flow가 자연스러움
• 바인딩이 심해짐

• 해결책 2
• React, d3 모두 각자의 역할을 하게함
• d3 코드를 순수하게 유지
• 디버깅이 쉬움
• 리액트없이도 사용가능

발표자분은 해결책 2를 선택했다고 하는데요, 그 이유는 d3 코드를 pure하게 유지 시켜주기 때문이라고 하였습니다.

• d3 와 react의 로직이 합쳐지면 디버그 하기가 어려움
• 이렇게 하면 추후에 d3 코드가 리액트 없이도 쉽게 다른 쪽에서도 사용할 수 있음.

그리고, d3는 외부에서 받은 event handler 들때문에 d3를 오염시킬 수 있는데, 이는 d3에서 이벤트를 커스터마이징해서 synthetic event를 리액트에게 전달하고, 이를 리액트에서 subscribe 하는 방식으로 해결하셨다고 하였습니다. 

그리고 이벤트를 감지하는 경우는 자식 컴포넌트에서 dispatch를 사용해 이 동작을 감지하는 양방향 데이터 바인딩을 하였다고 합니다. 이 부분은 리액트에서는 단방향 바인딩을 하기때문에 조금 어색하게도 느껴졌습니다.

d3.js 와 react를 같이 사용해본 경험이 없어서, 모든 발표내용을 체득하기는 어려워 아쉬웠지만 여러 가지 어려움을 겪으면서, 가지셨던 생각이나 경험의 과정들을 볼 수 있어 재밌게 들었던 것 같습니다.

14:50 - 15:30

> 한편의 애니메이션 같은 css - 최연규님

다음은 프론트를 개발하다 보면, 항상 욕심을 가지게 되지만, 엄두를 내지는 못하고 있는 애니메이션에 대한 세션을 들을수 있었습니다. 이 세션에서는 강의주제 답게 여러 애니메이션 예제를 바탕으로 설명을 해주셨습니다.

웹에서의 애니메이션은 ux 향상, 시선집중, 이해, 용량과화질의 4가지요소로 설명할 수 있다고 말씀해주셨습니다.

그리고, 전환(화면 이동) 효과가 발생하는 시작점과 종료점을 나타내는 키프레임에 대해서 간단히 설명해주시고, 이와 관련한 성능적인 사례에 대해서도 설명해 주셨습니다. 

그리고 아래와 같은 달 애니메이션 예제 css코드를 보여주시며, 여러 요소들에 대해서 설명해주셨습니다. 그리고 transfrom요소는 행렬의 곱 연산과 같아서, 사용순서에 대해서 주의를 해주시기도 했습니다 ㅎㅎ

그리고, 애니메이션은 transform 그리고, position 과 size, color, filter, timing function 요소들로 구성된다고 하였는데 그중 , transform 과 timing function에 중점을 두고 설명해주셨습니다.

그 중, timing function은 아래와 같이 세가지로 나뉠수 있는데, linear는 일반적인것, 그리고 cubic-bezier는 튀는효과를 낼떄, steps는 단계적인 효과를 낼때 사용한다고 하였습니다.

• linear

• cubic-bezier

• steps

그리고 자연스러운 애니메이션효과를 주려면 처음사진과 같이 50% 일때 transform 효과를 주지말아야하고, 아래사진과 같이 구성을 하면 중간과정에서 잠시 멈추고 애니메이션이 진행되어서 어색하다는 말씀도 해주셨습니다.

긴 발표는 아니였지만, 실제 애니메이션과 함께 발표를 듣고나니 물론, UX를 고려하여 사용자에게 더 나은 사용자경험을 주는것도 중요하긴 하지만, 여러 재미요소를 줄수 있는 css animation을 활용해 사용자에게 흥미를 주어야 겠다는 동기부여도 많이 생겼던 것 같습니다.

15:50 - 16:30

> 자체 polyfill.io 서버 구축하여 프론트엔드 최적화하기 - 임형주님

일단 polyfill 이라는 개념에 대해서 다시한번 짚어보는 좋은 발표였던 것 같습니다. 물론 발표 중간중간의 내용들은 꽤 난이도가 있어서 모든 내용들을 습득하기에는 어려움이 있었지만, polyfill.io 에 대해 알게되고, 어떤 방식으로 polyfill 서버를 구축하고, 또 문제를 해결해 나가셨는지 내공을 느낄수 있었던 발표였던것 같습니다.

우선 폴리필은 언제 사용하는지 생각해보면,  바벨을 사용하면 새로운 문법을 구형 자바스크립트 문법으로만 바꿔줍니다. 그런데, 바벨 그 자체로는 ES2015의 새로운 객체(Promise, Map, Set 등등)과 메소드(Array.find, Object.assign 등등)을 사용할 수 없기 때문에, 그 이유는 ES2015에서 처음 생긴 feature들이라 구형 자바스크립트에는 그에 상응하는 코드가 없기 때문입니다. 이 상황에서 폴리필이 사용 되게 되는거죠.

그리고 중요한점은 바벨은 컴파일 타임에 실행되고, 폴리필은 런타임에 실행이 되는것입니다. 그리고, 폴리필은 하나의 프로젝트에 한번만 사용해야 하기 때문에 가장 먼저 로딩되는 스크립트 제일 위해 추가해주기도 합니다.

그리고 polyfill.io라는 것에 대해서 설명을 들을 수 있었는데요, 이는 사용자의 브라우저에 suitable한 폴리필들을 return해주는 것이라고 간단하게 생각하면 됩니다.

여러 옵션들 역시 줄수 있다고 하는데요, UA(user agent)에서 받아오는 브라우저 정보들을 믿지 못할때 feature detection이라는것을 사용할수도 있고, gated 옵션이라는 것을 사용하면 polyfill 설정이 내려오더라도, 다시한번 체크를 하는 역할을 한다고 합니다.

그리고 이 polyfill.io 같은 자체 polyfill서버를 구축하고, serve 하기 위해선 아래와 같은 feature가 필요하다고 합니다. 하하... (나는 누구 여긴 어디)

• resolveAliases
• filterForUATargeting(Filter the features object to remove features not suitable for the current UA)
• resolveDependencies
• filterForUATargeting
• filterForExcludes
• topological sort(feature) 위상정렬 -> dependency 파악
• output stream

이 밖에도 정말 많은 요소들이 자체 polyfill 서버를 구축할때 필요했다고 합니다. nginx 대응을 위한 njs, unknown ua를 위한 대응 ,... etc.. ㅇㅇ..

16:40 - 17:20

> 은밀하게 신속하게 React 포팅 성공기 - 강동욱님

이 세션은 사내에서도, jquery 기반의 웹사이트를 리액트로 포팅하고 있기 때문에 더 관심있게 봤던 세션이기도 합니다. 발표를 들으며 비슷한 상황들이 많이 겹쳐 괜히 더 감정이입해서 발표를 들었던 것 같습니다 ㅎㅎ 하나의 컴포넌트가 각각의 html의 파일에 따로 정의되어 있는 상황이나, 어떠한 이슈를 해결할때 항상 백엔드 쪽 리소스가 프론트와 맞물려 있는 상황등등..

또한 스트랭글러 패턴을 소개해 주시면서 리팩토링을 진행했다고 말씀해주셨는데요, 간단히 설명하면, 기존의 레거시들을 점진적으로 제거해 나가고, 결국엔 모든 레거시들이 제거되게 되는 패턴입니다. 생각해보니 저희도 이런식으로 리팩토링을 진행하고 있었습니다 ㅎㅎ 초기의 프로젝트면 모르겠지만, 이미 프로젝트의 사이즈가 매우 커져있고, 또한 여러 디펜던시들이 각 페이지 마다 있을것이기 떄문에 전체를 한번에 마이그레이션 한다는것은 시간도 정말 오래걸릴 뿐더러, 많은 이슈가 생길것이기 때문에 당연히 이렇게 부분부분을 마이그레이션 하는 생각을 똑같이 한것 같습니다 :) 그리고 추가적으로 레거시와 최신코드를 병행할수 있다는 큰 장점도 있는 것 같습니다.

이후, 기술부채나, 큰 번들파일과 속도저하, SEO의 어려움 등등의 이슈들이 발생했는데 이를 ALL-IN-ONE으로 해결했던 방식은 역시나 서버사이드 렌더링이였습니다. 그리고, 이러한 SSR을 어떻게 해결하였는지 자세히 설명을 들을 수 있었는데요.

요즘 핫한 Next.js 기반의 서버사이드 렌더링을 활용했던 것이었습니다. 이 때 역시도 스트랭글러 패턴을 활용해 점진적으로 수정해 나갔다고 합니다. 외관 (라우팅?) 을 react-router 에서 next.js로 변경하고, 이와 관련된 코드들을 옮겨 나간것입니다. 

next.js는 아래와 같은 장점요소들이 있다고 합니다.

1. 풍부한 예제

2. next/head (react helmet 과 비슷)

3.HMR 기본 탑재

4. Code splitting 과 dynamic import 

물론, next.js로 모든 SSR을 해결한것은 아니라고 합니다. 이는 캐싱을 통해 해결했다고 하는데요. 아래 사진을 보면 알수 있듯이, 정말 확연하게 줄은 것을 확인 할 수 있었습니다.

발표를 마치고 난뒤 많은 점들을 느꼇고 토이 프로젝트에 적용해보고 있던 next.js는 다시한번 더 심도있게 살펴봐야 겠다는 생각이 들었습니다. 물론 이 세션이 많은 도움이 되었지만 각각 회사마다의 상황이나, 기술 spec들이 다르기 때문에, 이러한 발표내용을 참고하긴 하겠지만, 어떤 방식으로 사내 사이트를 리액트로 포팅해야 할지, 그리고 기술부채들을 어떻게 효과적으로 해결해 나갈지는 아직까지는 큰 미지수이고, 숙제 인것 같습니다.