일상 - DEVIEW2018 후기

일상

:DEVIEW2018 후기

운 좋게, 데뷰 선착순 신청에 당첨되어서 데뷰 행사를 다녀오게 되었습니다! 주변에서 많은 분들이 실패를 해서,ㅠ 다른 분들과 함께갔으면 더 좋았겟지만 ㅠㅠ 그래도, 가서 열심히 듣고 왔습니다! (감사합니다 팀장님ㅎㅎ)

행사 스케쥴 링크: https://deview.kr/2018/schedule

| 11:00 ~ 11:45 

지난 1년간의 웨일 브라우저와 그 미래 (부제: 제품 매니저가 들려주는 생생한 기술/제품 이야기) - 김효님

이 세션에서는 웨일 브라우저를 매니징하면서 1년동안 어떤 목표를 세웠고, 어떻게 그 목표를 해결해 나갔는지의 과정과 앞으로의 목표에 대해서 들을 수 있는 세션이었습니다. 웨일브라우저의 강점인 한 화면에서 여러가지 작업을 할 수 있는 옴니태스킹을 살리기 위해, 어떤 과정들을 거쳤는지 생생히 들을 수 있었는데요.  

특히 웨일 모바일 브라우저에서, 웨일 브라우저의 강점인 옴니 태스킹을 살리면서, 모바일에서의 심플함을 살리기 위해 아래와 같은 무한 반복되는 사이클을 겪으면서 웨일 브라우저팀이 겪었던 고민들에 대해서, 공감하고 많은 점 들을 느낄수 있었습니다.

웨일 모바일 브라우저에서 겪은 고민과정

기능 여러개 다 넣기 vs 심플하게 가기

• 웨일 브라우저 => 옴니태스킹을 기반으로한 많은 기능
• 기능 => 버튼
• 신기능 => 추가버튼
• 추가버튼 => 복잡
• 복잡 => 심플함을 컨셉으로 잡은 모바일에 적합하지 않다!
• 모바일 => 심플
• 심플 => no 버튼

심플-복잡 cycle 무한 반복

또, 이러한 문제를 웨일 모바일 브라우저에서 어떻게 해결하는지도 생생히 들을 수 있었고, 개발 팀 스스로가 만족하는 제품을 만들어야 하고, 또 그런것들이 고객의 피드백으로 바로바로 나오기 때문에, 그러한 만족한 제품을 통한 고객의 좋은 피드백을 바탕으로 마케팅팀에서도 큰 힘이 난다는것도 새삼 느낄 수 있었습니다.

그리고, 웨일밸리라고 하는 웨일 브라우저만의 스크랩 공간의 역할을 하는 기능 개발기에 대해서 들을 수 있게 되었는데요. 이 웨일밸리라는 기능을 매니징하면서 , 기능으로 승부를 보려했지만 이름을 웨일밸리에서 스크랩북으로 교체하는등, 개발자들이 개발을 하면서 서비스에 대한 많은 기대와 꿈을 갖고 개발을 하지만 그 꿈은 여러 요소들을 고려하면서, 현실에 다가가 있어야 한다는 씁쓸함도 느낄 수 있었습니다.

또한 개발 팀 문화에 대해서도 많은것을 생각해 볼 수 있는 내용도 들을 수 있었는데요. 웨일 브라우저 팀은 애자일 프로세스 그 자체를 가져와서 개발을 진행하고 있다고 하는데요. 그러한 애자일 프로세스는 바로 적용되는것이 아니라, 

1. 프로세스 없는 빠른 변경은 서로간의 신뢰를 보장

2. 또 이러한 과정들은 커뮤니케이션의 양, 그리고 신뢰를 얻기위한 실력

3 .그리고 빠른 진행을 위해선 정확한 일의 측정

4. 개개인 커뮤니케이션 오류를 바로잡을 훌륭한 중간자가 필요하다는 점.(PM,TL)

위의 4가지 요소들이 중요하게 작용한다고 느끼게 되었습니다

| 12:00 ~ 12:45

책에서는 맛볼 수 없는 HTML5 Canvas 이야기 - 방진호님

저는 컨트리뷰톤이라는 대회에서 크로미움에 컨트리뷰트를 하는 팀에 참여하고 있는데, (많이 부족한 탓에 ㅠㅠ..잘 참여를 못해서 멘토님을 볼 면목이 없지만..) 참여하고있는 대회 멘토님의 발표라 더 귀를 쫑긋하고 들었던것 같습니다! 

맨처음에는 브라우저에서 화면이 나올떄, 렌더링 엔진, 자바스크립트 엔진, 그리고 그래픽 라이브러리의 도움을 받아 어떻게 그려지는지 그 일련의 과정들에 대해서 설명을 듣고, 일반 태그들은 렌더링 엔진이 어떻게 그릴지 알고 있으나, canvas 같은경우는 랜더링이 자바스크립트로 작동하고, 내부를 어떻게 그릴지는 개발자의 js 코드에 달려있다는 것에 대해서 설명을 듣기도 했습니다.

또한 v-sync 타임라인에 맞춰서 그림을 그려내야 하는데 메인 쓰레드가 하는일이 너무 많아 16.7ms라는 규격시간동안 그림을 그리기가 힘들다고 하였습니다. 이러한 캔버스 애니메이션의  문제점들을 해결할 여러 개선안들에 대해서 설명을 들을 수 있었습니다.

1. 브라우저 관점에서의 개선

2. 웹개발자 관점에서의 개선

1) Full screen Canvas로 렌더링하기

2) WEB GL로 렌더링하기

3) background canvas

background canvas

위와 같은 개선 방안들이 있었지만, 새로운 api인 offscreen canvas에 대해서 들을 수 있었습니다.

앞에서 소개한 개선방안들은 자바스크립트 엔진과 렌더링 엔진 사이의 binding overhead가 발생하고 dom 렌더링을 처리하기에도 메인 쓰레드가 벅차서 worker thread 에서 캔버스 랜더링을 해주는 방안을 찾았다고 합니다. offscreen canvas라는것을 통해서 dom에서 분리해서 워커 thread에서 수행이 되게하는 새로운 api라고 합니다.

worker thread를 도입해서 기존 메인 쓰레드에서 겪은 문제들을 해결한점이 인상 깊었고, 앞으로도 위와 같이 웹개발을 할때, 다른 쓰레드를 도입해 많은 문제들을 해결해 나갈것 같은 생각도 들었던 것 같습니다

| 14:00 ~ 14:45

Javscript 배틀 그라운드로부터 살아남기 - 박재성님

위 세션에서는 자바스크립트의 발전해온 양상, 그리고 각 영역에서의 자바스크립트의 2018년 동향, 자바스크립트 생태계 환경에서 살아남는 방법 등등 js 프레임워크인 리액트로 프론트개발을 진행하고 있는 저로써는 흥미가 갈 수 밖에 없는 세션이었습니다. 

오늘날은 vanila로 개발하는게 일반적이지 않고, framework와 개발 도구들의 도움을 받아 js 개발을 진행하고, 또한 Evergreen browser ( 자동으로 사용자에게 알리지 않소 자동으로 업데이트) 와 바벨이 최신 스펙 사용이슈들을 해결해주면서 트랜스파일링의 시대라고도 부를수 있다고 했습니다.

2018년 동향으로는 아래와 같은 키워드로 동향을 설명해 주셨습니다.

• 버전 구분 중요성 감소
1. annual 릴리즈
2. 버저닝에 큰 변화가 아닌 feature 단위
3. evergreen 브라우저는 스펙 빠르게 구현
4. es10까지 나옴

• 웹 어셈블리
1. 프로그래밍 언어(c,c++)를 컴파일해 어느 브라우저에서 빠르게 실행

• 정적타입시스템
1. 타입스크립트- 언어적 측면
2. FLOW - 도구적 측면

• Web components, Polymer
1. Web components: 모든 브라우저에서 지원
2. Polymer : jsx와 비슷, dom 렌더링 집중, 리액트가 인기 얻은 이유 중 하나가 재사용 가능한 ui인데 이러한 장점을 가지고 있음

Polymer에 대해선 매우 흥미로웠고 한번 알아봐야 할것 같습니다 ㅎㅎ

• npm, yarn
1. 초기 yarn의 장점 (빠른 속도)이 점점 퇴색되고 있다.
2. yarn 사용률은 npm의 0.03% 밖에 안됨

• 웹팩 v4
1. 웹팩 빌드시간 60~98%감소
2. mode property

• OCJS (zero configuration js)
1. parcel : 무설정 번들링 지향, config 필요 x (항상 써봐야지 생각만 하고있는데, 꼭 한번 써봐야 겠습니다 ㅎㅎ..)
2. 웹팩: config pack이라 불릴정도 ㅎㅎ..

자바스크립트 생태계 환경에서 살아남기

• 깃헙 트렌딩 사이트
• fe tech mailing

매몰비용에 조심하라!

• 특정 도구에 대한 노력이 많아지면, 합리적이 었다는것을 설득하게 되고, 본인이 한것에 대해서 매몰될 수 있다.
• 기존에 문제 없이 사용하던 기술들을 뒤로하고 새롭고 반짝이는것들에 너무 쉽게 관심을 뺴앗긴다.

• Magpie developer

결론은 무엇을 사용하던 결국 javascript인것이고, 트랜스파일링 하는것도 결국 실행되는 js 코드 생성의 필요가 있는것이었습니다. 이미 필수적 도구들도 넘쳐나는 상황에서 무언가를 하나 추가할때마다 비례하는 도구들이 증가하는데, 이 모든것을 다알아야 할까? 에 대한 의문을 많은 사람들이 가진다고 했습니다.ㅎㅎ 저 역시도 항상 가지고 있었던것 같습니다 ㅠㅠ

이에 대해서는,  

• 현재작업에 필요한것

• 끌리는것에 집중하고 적당한 호기심, 지속적 꾸준함

을 가져야 한다고 조언해 주셨습니다. 

최근 가지고있었던 걱정이나, 생각이 막혀있었던 부분들에 대한 해답을 어느정도 얻었던 것 같고, 많은 도움이 되었던 세션이었던 것 같습니다.

| 15:00 ~ 15:45

파파고 서비스 2년의 경험 - 김준석님

이 세션에서는 어떻게 파파고 서비스가 2년동안 성장해왔고, 어떠한 일들이 있었고, UX로 기술적 이슈들을 어떻게 처리했는지 또 개편 리스크를 줄이기 위해 어떤 일련의 과정들을 거치고 상황에 맞게 어떻게 변화했는지 전체적으로 들어볼수 있었고 많은 점들을 느낄수 있었습니다.

인상 적이었던 점은, 처음 출시전 타겟 유저는 해외여행 사용자였는데, 실제로는 외국어 공부로 사용하시는 사람들이 제일 많아 개발 계획을 수정하여 학습용 기능을 추가하는 방식으로 개발이 진행되었던 점이었습니다. 어찌되었던 개발 서비스는 사용자위주로 돌아가고, 여러 상황에 맞물리다 보면 서비스를 개발함에 있어 여러가지 상황도 발생할수  있겠다라는 생각도 들었고, 이렇게 개발 프로세스를 변경한것도 팀내에서 서로를 신뢰하고, 수평적으로 많은 의사결정이 이루어지기 때문에 가능한점이 아니었을까 라는 생각도 들었습니다.

또 흥미로웠던 점은, 서비스 만들때 기술에 시간이 필요할때 ux로 응급처치를 했던 사례인데요, 일본어 ocr 인식모델은 개발을 완료했지만 한국어, 영어, 중국어 ocr인식률이 떨어졌었는데, 이를 ocr입력 오류를 보완하기 위한 수단으로 필기입력기를 ocr모드에서 제공하여 기술로 문제해결이 걸릴때는 ux로도 문제가 보완이 되구나 하는 큰 깨달음을 얻기도 했습니다.

그래서 ux라는 것은 대단한 것이 아니라 사용자의 필요에 꼭 맞는 기술로 문제를 해결해 나가는 과정이라는 점도 깨닫게 되었습니다. 그리고 파파고는, 한 회사에서 번역 웹이 두개가 있는것은 좀 아이러니하여,네이버 번역기 웹과 합치는 개편을 어쩔수 없이 하게 되었는데, ux에서 가장 중요한점은 익숙함이고 변화의 폭이 크면 사용자의 반발을 살수 있기 때문에 네이버 번역기와 파파고 웹을 스펙을 최대한 쪼개 업데이트 하고 사용자와 커뮤니케이션도 여러번 하는등, ux를 생각하며, 개편리스크를 줄여나간점을 아주 인상깊게 봤습니다.

| 16:00 ~ 16:45

웹 성능 최적화에 필요한 브라우저의 모든 것 - 이형욱님

위 세션에서는 브라우저 내부 동작 원리에 대해서 설명을 들었고, 또한 이를 기반으로한, 웹 성능 최적화에 대해서 자세한 설명을 들을 수 있었습니다.

compositer thread, raster thread의 개념에 대해서 알게 되었고, vsync에 대해서도 자세한 설명을 들을 수 있었고, pipeline stage cost에 대해 설명을 들으면서 웹 성능 최적화에 필요한 요소들에 대해서 어려웠긴 했지만 많은 생각들을 해보면서, 많은점들을 배울 수 있었던 세션이었습니다.