[EP] HTML5 Developer Conference 후기 #2..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

2일차

Which Way Is Forward - Doug Crockford, PayPal

말로만 듣던 자바스크립트계의 요다님이신 더글라스 크록포드님의 발표였다. 실제로 봤다. 사진하고 똑같이 생겼고 키 엄청 커!!!(같이 사진이라도 찍고 싶었는데 잠시 보이다가 사라지셨;; ㅠㅠ) 제목으로는 내용을 가늠하기 어렵지만 프로그래밍 언어에 대한 얘기였다. 사실 제대로 못 알아듣기도 했고 중간에 온라인으로 할게 좀 생겨서 잘 듣지 못했다. ㅠㅠ 어쨌든 예전으로 돌아가서 goto문얘기부터 프로토타입 상속, 타입 등 언어에 대한 얘기였다.

Introduction To The Next Generation JavaScript Library for SVG - Dmitry Baranovskiy, Adobe

알만한 사람은 아는 SVG 라이브러리 Raphaël을 만든 드미트리에 발표로 이 발표에서 새로운 SVG 라이브러리를 발표한다고 미리 얘기했기 때문에 기대를 하고 있었다.(난 SVG를 쓸 일은 별로 없었지만...) 2008년에 Raphaël을 만들었는데 DOM 처리가 어려워서 Raphaël을 안쓰겠다고 불평하는 사람이 많이 있었다. 그래서 새로 만든 SVG 라이브러리가 Snap.svg이고 Raphaël이 구형 브라우저를 지원하기 위해서 SVG와 VML의 공통 부분만 다루고 있기 때문에 제한적이었다면 Snap.svg는 모던 브라우저만 지원하기에 SVG를 완전히 지원한다. 간단히 Snap.svg를 다루는 예제(Getting Started의 내용이다.)를 보여주었는데 꽤 편해보였다.(써보기전엔 모를 일!)

발표뒤에 d3.js와 어떻게 다르냐는 질문이 있었는데 d3.js는 비쥬얼라이제이션 라이브러리고 Snap.svg는 SVG 라이브러리라고 대답했고 성능문제는 어떻게 생각하냐는 질문에는 다른 기술은 다른 문제를 다루므로 성능때문에 SVG가 적합하지 않다면 Canvas를 사용했다고 했다.

React: Rethinking best practices - Pete Hunt, Instagram

• 발표자료

이 발표는 JSconf.eu와 똑같은 발표이므로 발표영상도 공개되어 있다.(영상은 안봤지만 슬라이드가 동일하니 발표도 똑같겠지) 페이스북이 공개한 React라는 자바 스크립트 프레임웍에 대한 발표였는데 이름정도는 알고 있었지만 깊게 보지는 않았는데 이 발표를 듣고 AngularJS와는 또 다르게 꽤 관심이 많아졌다. 조만간 기회가 되면 한번 사용해 볼듯 하다.
React는 템플릿 대신 컴포넌트를 만들라고 하고 있는데 템플릿은 기술은 분리하지만 관심사는 분리하지 못하므로 모델을 바꿀때 뷰가 다 깨지게 된다. 그래서 컴포넌트로 관심사를 분리할 수 있는데 이 컴포넌트는 구성할 수 있고 재사용할 수 있고 테스트할 수 있다. UI가 어려운 이유는 상태가 많기 때문인데 React는 데이터가 변경될 때마다 완전히 새로 렌더링한다. 대신 AngularJS와 다르게 양방향 바인딩(좋지만 디버깅이 어렵다.)이 없고 더티 체킹을 하지 않는다. 명시적인 DOM 작업을 전혀 하지 않고 모든걸 선언적으로 처리한다. 매번 렌더링한다고 하면 느리다고 생각하기 마련인데 React는 Virtual DOM을 사용해서 성능을 해결했다. 데이터가 변경될 때마다 Virtual DOM을 생성해서 기존 거과 다른 점을 찾아서 최소한의 변경사항만 찾아낸다. DOM이 느리기 때문에 이 방법이 아주 빠르고 DOM처리는 최소한으로만 이뤄지며 Virtual DOM이 DOM API에 의존하지 않기 때문에 SVG, Canvas도 지원함에도 DOM 없이도 테스트할 수 있고 심지어 Node.js에서도 돌아간다.

WebSocket Perspectives and Vision for the Future - Frank Greco, Kaazing

이 발표는 영 별로였다. 그냥 예전의 웹은 어땠고 웹소켓이 왜 등장했고 웹소켓 동작방식이나 패킷에 대한 설명을 한참 하다가 데모 시연으로 넘어갔다 데모는 라즈베리파이에 연결한 램프가 있고 노트북과 연결해서 웹소켓으로 램프를 키고 끄고 하는 시연이었는데 뭔가 엄청난 일이 이뤄지는 듯이 설명했지만 라즈베리파이라고 특별히 다를 것도 없고 신기할 것도 없었다.(그냥 웹소켓으로 요청왔다갔다 하는거잖아!)

AngularJS and the Single Page Application (SPA) - Joshua Woodward, Ebay

장소가 좀 작은 곳이기도 했지만 사람이 너무 많이 들어와서 앉을 자리가 없을 정도로 사람이 몰렸다. 뭐 받아적지는 못했는데 Angular.js 소개정도의 발표였다. Angular.js 설명하면 항상 나오는 양방향바인딩부터해서 서비스, 디렉티브등을 설명했는데 그냥 튜토리얼 수준이었다. 외국에서도 아직 Angular.js가 초창기인지 이번 컨퍼런스에서 고급 팁이라던가 성능향상이나 경험등을 듣기 원했는데 대부분 튜토리얼 수준이라 많이 아쉬웠다.(큰 무대에서는 규모에 맞게 퀄리티와 수준을 올리라고!)

PDF.js - Firefox's HTML5 PDF Viewer - Brendan Dahl, Mozilla

파이어폭스에 내장된 PDF 뷰어인 pdf.js에 대한 발표였다. 처음에는 PDF 포맷에 대해서 설명하고 2011년에 Firefox 4를 발표하면서 pdf.js를 만들었다. pdf.js를 만든 이유는 보안이슈가 크고 사용자 경험을 좋게하고 성능을 높이기 위함이었다. 그리고 HTML5 기술을 한계까지 써보려는 의도도 있었다. 2011년 드디어 뷰어가 완성되었는데 텍스트 처리가 상당히 어려운 부분이었다. OS마다 폰트 엔진이 다르고 언어마다 다양한 경우가 있기 때문인데 이부분이 pdf.js의 큰 부분 중 하나이다. 그리고 성능을 위해서 최대한 웹워커를 사용하고 있다.
2013년 파이어폭스 14 나이틀리 버전에 pdf.js가 내장되었고 2013년 2월에 안정버전에 포함되었다. 그 뒤에 수많은 버그를 처리하고 한번에 다 로딩하지 않고 사용자가 스크롤을 할 때 이어서 로딩하고 증분 렌더링(incremental rendering)을 적용했다. 그래서 현재는 파이어폭스 뿐만 아니라 크롬, IE 9+, 사파리, 오페라에서 모두 동작하고 주요 PDF 기능을 거의 지원하고 있다. 거의 내가 이번 컨퍼런스에서 듣고 싶은 내용의 가장 적합한 발표중 하나였다. pdf.js를 만들면서 해결한 문제들과 배운 것들을 생생하게 들을 수 있는 자리였다.

맺음말

컨퍼런스는 2일이었지만 운좋게 출장기간도 길게 잡혔고 주말도 붙혀서 갔다 왔기에 여유로운 시간을 좀 보내고 왔다. 출장 가기전에 발표다 교육이다 해서 사실 지쳐있었는데 여유로운 시간을 보내면서 적당히 회복을 하고 돌아왔다. 작년에 갔던 Nodeconf의 화기애애한 분위기와는 또 달리 사람들하고 어울릴 틈은 별로 없었지만 좋은 시간이었다. 나중에 이 다음날부터 New Relic의 {Future}Stack 컨퍼런스가 있다는 걸 알게되었는데 좀 미리 알았다면 이것까지 듣고 올 수 있게 일정을 잡았을텐데 좀 아쉽긴 하다.

[EP] HTML5 Developer Conference 후기 #1..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

HTML5 Developer Conference가 샌 프란시스코까지 출장을 간 이유였다.(d3.js 유저그룹이 아니라..) 사실 출장 그것도 해외로 출장가는 건 처음이다. 작년에 Nodeconf에 참석했을 때는 내 돈이랑 휴가를 쓰고 갔던거였는데 출장으로 가게 되니 참으로도 좋았다. 마음도 훨씬 여유롭고... 사실 출장으로 가게 된 것이기 때문에 컨퍼런스 자체는 내가 고른 컨퍼런스가 아니고 HTML5 Developer Conference도 이번에 처음 알게된 컨퍼런스다. 히스토리를 보면 2011년에 처음 열려서 작년부터는 1년에 두번씩 열리고 있다.(이전의 발표자들이 좀 더 네임밸류가 높았던 느낌은 있지만...)

HTML5 Developer Conference

컨퍼런스는 샌프란시스코 시내에 위치한 모스콘 센터(Moscone center)였다. 모스콘센터는 Google I/O나 WWDC도 종종 열리는 큰 곳이다. 가보니 센터가 엄청 커서 한블럭가까이 차지하는 건물이 3개나 되었고 HTML5 컨퍼런스는 그 중 하나에서 열렸다. 마침 컨퍼런스가 열리는 날이(22일) 애플이 발표하기로 되어 있었는데 바로 옆에 애플 로고가 있고 사람들이 모여있는 걸 보니 저 안에서 발표를 하고 있었던 듯 하다.

바로 건너편의 모스콘센터에서는 GMIC이 같은 일정으로 열리고 있었다. 컨퍼런스 장에 들어가서 명찰을 받으려 했지만 내 명찰은 찾을 수 없었고 어떤 아가씨가 명찰에 휘갈겨 써주었다. ㅠㅠ 실제 컨퍼런스는 지하에서 열렸는데 가운데는 로비처럼 큰 공간이 있고 한쪽에는 세션을 할 수 있는 장소들이 몰려있고 반대쪽을 오픈된 공간으로 여러 부스들이 몰려 있었다. 인텔, 트위터, YELP등이 와서 자신들의 제품들을 홍보하거나 구인을 하고 있었다. 부스는 뭐 크게 볼 것은 없고 일반적인 부스였지만 이런 저런 기념품은 참 많이 주었다.

컨퍼런스 규모든 상당히 컸는데 키노트 제외하고 하루에 총 6개의 세션이 존재하고 한 세션에는 최대 12개까지의 트랙이 동시에 진행이 되었다.(행사 일정이 세로보다 가로가 훨씬 긴 경우는 처음 봤;;;) 시간에 따라서는 12개가 다 안채워지는 경우도 많았지만 어쨌든 12개 중에서 하나를 골라서 들어가려다 보니 참 고민이 많이 되었다. 영어라서 사실 막 다 알아들은건 아니라서(영어로 들으면서 화면보면서 적는건 너무 어렵다.) 대충 간략히만 정리하려고 한다.

간단히 요약하면 전에 가본 해외 컨퍼런스는 커뮤니티주도 컨퍼런스였기 때문에 이런 일반적인 해외 컨퍼런스는 처음 참석해봤는데 커뮤니티 컨퍼런스의 질이 좋은 건 해외나 국내나 비슷한 것 같다.(Google I/O나 WWDC같은 초대형 컨퍼런스는 가본적없으므로 예외) 너무 방심하고 제목만 보고 세션을 골랐더니 기술공유가 아니라 제품홍보를 위한 세션이 너무 많았다. 그래서 첫날의 경험을 교훈삼아 이틀째는 주로 오픈소스 위주로만 들으니까 좀 나았다. 아무래도 요즘은 기술이 인터넷을 통해서 전세계적으로 잘 공유하기 때문인지 해외라고 퀄리티가 무척 높게 느껴지진 않았다.(그렇다 하더라도 해외 컨퍼런스는 참석해 보기를 권한다. 세션이야 공유되면 온라인으로도 볼 수 있지만 현지에서는 다른 느낄 수 있는 것들이 많이 있다.) 발표 퀄리티 자체만 보면 국내에서도 얼마든지 이정도 퀄리티로는 컨퍼런스를 열 수 있을 것으로 보였다.(물론 12트랙이나 운영하는 규모는 힘들지만...) 해외 컨퍼런스이므로 프로젝트의 커미터들의 경험이나 설명 혹은 실제적인 규모있는 프로젝트를 하면서 고민한 내용이나 경험을 공유해 주길 기대했는데 좀 뻔한 기술가이드정도 수준의 발표들이 많아서 아쉬웠다.(내가 세션을 잘못 골랐을 수도...)

1일차

The Future of Angular - Miško Hevery, Google

• 발표자료

얼마 전에 읽은 AngularJS 기초편이라는 책에서 저자인 브래드 그린이 서문에서 구글 피드팩이라는 프로젝트를 수행하다가 6개월간 17,000라인의 프론트엔드 코드를 프로젝트 팀원이 자신이 만든 프레임워크로 2주만에 새로 작성할 수 있다고 해서 시켰는데 실제로는 3주가 걸렸지만 완성된 코드는 1,500라인으로 줄어들어서 깜짝 놀랐다는 이야기가 나오는데 이것이 Angular.js의 시작이었고 그 주인공이 이 세션의 발표자인 미스코 헤브리이다. 최근에 Angular.js에 관심이 많기 때문에 이번 컨퍼런스에서도 관심 주제중 하나였고 막 가고 싶었던 컨퍼런스는 아니지만 흥미가 생긴 이유중에 하나가 이 세션이었다.(현재 미스코는 Angular.dart쪽에 집중하고 있는 듯 하다.)

미스코의 발표를 직접 들으니까 네임밸류덕에 좋았고 Angular를 본지 얼마 안되었기 때문에 사용법 익히기에 허덕여서 프로젝트 개발상태같은 건 아직 추적하지 못하고 있는데 그런 부분에 대한 전체적인 얘기를 들을 수 있었다.

• Angular.js는 최신 브라우저만 지원한다.(구현 브라우저는 1.x 브랜치에서 지원할 것이다.)
• 최신 HTML5 표준들을 더 적극적으로 사용할 예정이고 Polymer프로젝트의 Polyfill라이브러리에 대해서 많이 언급을 했다.
• 차후 계획에 대해서도 얘기했는데(결정났다기 보다는 시도중인듯) 비동기 의존성 주입(Asynchronous DI)와 Zone기능이다. AMD가 비동기로 코드를 로딩하는 것을 관리한다면 비동기 의존성 주입은 어떤 순서로 클래스를 인스턴스화할 것인지를 다루는 것이고 Zone 기능은 영역을 나누어서 Angular.js를 사용하는 곳에서 기존의 다른 라이브러리를 사용할 수 있도록 하는 것이다. ES6와 어노테이션을 얘기하면서 마치 자바처럼 보이는(자바스크립트가 아니라) 예시코드도 보여주었는데 ES6에 어노테이션이 있는 것은 아니므로 의도는 자료를 좀 찾아봐야 이해할 수 있을듯 하다.(dart인가? ㅡㅡ;;)

Memory management for smooth infinite-scrolling - Sumit Amar, Microsoft

• 발표자료

요즘은 무한 스크롤을 많이 사용하고 최근에 개인 프로젝트를 하면서 스크롤링에 대해서 고민을 좀 많이 했던지라 선택해서 들어간 세션이었다. 무한 스크롤을 구현하면서 고민했던 내용을 공유해 주었는데 그냥 뭐 고만고만했다. 첫 접근은 스택을 사용해서 사용자가 스크롤을 하면 화면에서 사라진 DOM을 제거하고 메타데이터를 로컬스토리지를 이용해서 스택으로 쌓고 나중에 사용자가 다시 스크롤을 올리면 스택에서 가져와서 DOM을 생성한다. 하지만 이 방법은 너무 빨리 스크롤하거나 드래그를 사용하는 경우 빠지는 아이템들이 생길 수 있다. 두번째 접근은 범위에 대한 해시테이블을 사용하는 것이다. 각 아이텝의 위치를 어떤 범위로 나누고 이를 키밸류로 해시테이블에 저장하고 스크롤 할때 범위단위로 가져와서 보여주는데 이 방법은 스크롤을 적게 할때는 비효율적이다. 최종적으로는 두 방법을 섞어서 사용했다고...

Scale and performance: data visualization in modern web browsers - Gregor Aisch, Driven-By-Data.net

• 발표자료

제목대로 비쥬얼라이제이션에 대한 발표였다. 자바의 Processing으로 만들어진 Fortune 500이라는 포츈기업들에 대한 비쥬얼라이제이션을 d3.js로 다시 구현한 경험을 얘기해 주었다. 성능상으로는 d3.js + SVG 조합보다 d3.js + Canvas 조합이 좀 더 낫고 특히 파이어폭스는 DOM이 많은 경우에는 크롬에 비해서 엄청나게 느린 성능을 보여주었다. CSS3 transition이 성능이 좋아서 requestAnimationFrame()보다 낫다. 마지막으로 성능을 위해서는 저수준으로 내려가서 사용하는 라이브러리의 소스코드를 봐야하고 여러 브라우저에서 다양한 시도를 해보고 성능을 측정하라는 말은 (평이하지만)좋았다.(발표자료가 좌우뿐만 아니라 위아래로도 움직이지 잘 움직여서 봐야한다.)

Develop High Performance Sites and Modern Apps with JavaScript and HTML5 - Doris Chen, Microsoft

MS에서 나온 사람이었는데 제일 별로였던 발표였다.(이래서 내가 에반젤리스트라는 직책은 안좋아한다능;;) 자바스크립트 성능 향상에 대한 얘기를 좀 들을려고 들어갔는데 자기 소개만 한 5분하더니 이 발표에서 설명할 내용은 윈도우즈 8 어플리케이션을 만드는데도 쓸 수 있다면서 윈도우즈 8 홍보도 한 5분한듯 하다. 그리고 바로 이어진 내용은 CSS는 헤더에 넣고 자바스크립트는 맨 아래 넣으라였던가?(틀린말은 아니지만 2013년에 이런 컨퍼런스에서 할 얘기는 아닌듯...) GC를 줄이는 얘기랑 메모리 초기화 비용에 대한 괜찮은 얘기도 좀 있었지만 약을 너무 팔아서 짜증나서 잘 들리지도 않았다. 성능 얘기하면서도 IE 11의 개발자도구에서 얼마나 프로파일링을 제대로 할 수 있는지를 열심히 홍보했는데 IE11은 아직 안쓰고 있지만 원래 그런거는 다른 브라우저에서는 대부분 되던거고 성능등에서 가장 문제를 많이 일으키는 7,8,9,10은 어떻하라고?라는 생각이 들며 대부분 MS에서 표준, 성능 얘기하면 짜증나는 이유와 동일하게 발표를 들으면서 짜증났다. 기술공유를 하고 싶은건지 홍보를 하고 싶은건지 알 수 없는 세션이었다.

Levelling Up in AngularJS - Alicia Liu, Lift

• 발표자료

내가 요즘 쓰고 있는 Lift서비스의 개발자였는데 이 서비스는 앱으로만 사용해서 여기서 Angular.js에 대해서 발표할 줄은 전혀 몰랐다. 나는 마구 써보면서 기본없이 AngularJS를 배웠기 때문에 정리하면서 듣기 괜찮았지만 Levelling Up이라기 보다는 Basic 정도에 가까웠다. 서비스, 프로미스 디렉티브에 대한 사용법이나 중요한 부분에 대해서 설명한 세션이었다. 디렉티브를 이용해서 만든 마리오 데모의 소스는 디렉티브 공부하면서 참고하기에 괜찮아 보인다. 디렉티브로 저렇게 간단히 데모를 만들 수 있다는 점이 AngularJS의 장점이겠지...

Optimizing HTML5 for Distribution on Mobile Devices - Russell Beattie, Amazon

이 날 최악의 세션선택이었다.(이번에도 역시 에반젤리스트) 고르고 골랐는데 이 시간대에는 마땅히 끌리는게 없었다. 제목은 저렇게 되어 있지만 한 20분 정도는 Amazon 앱스토어가 얼마나 좋은가에 대해서 설명했다. 킨들파이어를 안써서 정확히는 모르겠지만 아마존 웹스토어에서는 웹기술로 앱을 만들 수 있는 것 같다.(아마존이 그런건지 안드로이드의 하이브리드인지는 잘..) 어쨌든 웹앱으로 만든 앱들을 보여주고 자신들의 스토어가 얼마나 좋은지 홍보를 한 20분 한 뒤 다른 사람이 나와서 앱 등록하는 과정이나 이런거 좀 설명하면서 킨들파이어에서 앱이 어떤 식으로 동작하는지를 보여주었다. 뒷부분은 거의 집중력을 잃어 듣지도 않았지만 최적화얘기를 하기는 했는지도 모르겠고 그냥 아마존 앱스토어 광고였다.

[EP] 발표에 대한 생각..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

최근에 발표할 일이 많이 있었다. 한때는 블로그만 쓰고 살았지만 어느 순간부터는 종종 발표할 일이 생기면서 종종 발표를 하고 다니게 됐다. 크고 작은 것들이 있지만 발표자료라고 할만한 정도의 것을 만들었던 것을 기준으로 하면 재작년에 6번 정도, 작년에 2번, 올해는 4번을 했다.(올해 이후로 발표를 할일은 없어 보이니...) 엄청 많은 수는 아니지만 그래도 꽤 발표를 하게 되었고 3년전과 비교해 보면 발표스킬도 나름 많이 나이진 것 같다. 최근에 처음 발표하는 분들도 많이 보고 발표에 대한 생각도 다각도로 생각해 보면서 조금 정리를 해본다.

말하기

• 말하기는 정말 많이 해보는 수밖에는 없다. 그냥 해보는 것만으로는 많이 늘지는 않을테고 믿을 만한 사람들을 놀고 발표할 때마다 연습을 해보고 피드백을 받아보고 다른 사람 발표를 볼 때 어떻게 하면 좋은지 자주 생각해 보는 게 좋아 보인다. 나로 말할것 같으면 글은 오래 썼으니 어느 정도 쓰더라도 말로하는 건 어려서부터 정말 자신이 없는 사람이고 긴장감에 특히 약해서 긴장되는 자리에서는 말을 더듬거나 머리가 하얗게 되서 아무 생각도 안나는 편이다.(혹 나를 면접본 사람은 익히알것이다.) 이런 긴장감도 많이 하게 되면 많이 하게되면 괜찮아 지는것 같고 나같은 경우는 이런걸 잘 못하니까 자주 자리를 가졌던 것 같다. 연습하기 좋은 무대는 그룹스터디를 하면서 발표를 하는 거다. 적은 수로 익숙한 사람들 앞에서 발표를 하면서 스킬을 늘리고 긴장감은 많이 해서 익숙해 지는 수밖에 없다.(나랑 오래 친했던 사람들은 2년전 JCO라는 큰 무대에서 발표할 때 내가 얼마나 떨었는지 기억할 꺼라 생각한다.)
• 나는 애드립을 잘 하는 편은 아니다. 그런 쪽으로는 센스가 좋지 못하기 때문에 발표중에 예상치 못한 상황이 생기면(보통 생긴다!) 당황해서 대처를 잘 못하는 편인데 그래서 연습을 많이 하곤 한다. 시간을 재보면서 발표자료와 말할 내용을 맞춰보면서 연습을 하고 연습을 많이 해서 예기치 못한 상황을 최대한 줄이려고 했다. 그래도 예기치 못한 상황은 생기지만 연습을 많이 해두면 대처하기에 좀 나은 것 같다.

• 예상치 못한 상황에 대한 준비는 해놓는 것이 좋다. 발표에는 여러 가지 상황이 있다. 인터넷이 갑자기 안될 수도 있고 라이브 코딩이 있으면 실수가 있을 수 있다. 인터넷을 할 수 있는 백업장비를 준비한다거나 인터넷이 안될때를 대비해서 스크린샷이라도 떠놓는다던지 해서 예상할 수 있는 상황에 대한 대안을 준비해 놓는 것이 좋다. 청중입장에서는 어떤 의외의 상황이든 발표자가 어리버리하고 있는건 보기에 좋지 않다. 그리고 라이브코딩을 한다면 완성된 예제코드나 복사해서 사용할 수 있는 코드 혹은 미리 스크린캐스트를 찍어놔서 잘못되었을 때 대안으로 설명할 수 있는 걸 준비해 주는 것이 좋다. 그리고 발표자료도 혹 모르니 클라우드 스토리지 같은데 올려두면 좋다.(재작년인가 발표를 몇일 앞두고 맥북 메인보드가 나가서 수리를 맡긴 관계로 남의 노트북으로 발표를 해야했다.)
• 시간은 정확하게 맞추면 좋다. 질문이나 돌발상황이 있을 수 있고 조금 빨리 발표끝냈다고 뭐라하는 사람은 없으니 총 발표시간의 5분정도 적게 잡아서 준비해도 좋다. 다만 긴장을 하면 말이 빨라질 수 있고 연습을 많이 하다 보면 연습때는 시간을 딱 맞췄지만 실제 할때는 할말이 대사처럼 정해져 있다보니(중간에 생각하는 시간이 적어지므로) 예상시간보다 더 빨리 끝나버릴 수 있다. 소제목단위로 몇분 정도에 끝나야 하는지 기억하고 있으면 현재 내가 빨리 진행되고 있는지 아니면 너무 느려져서 좀더 빨리 해야하는지 중간중간 확인할 수 있다.
• 발표준비를 하다보면 개그 욕심이 좀 나는데 나는 왠만하면 잘 안하는 편이다. 발표에 유머가 잘 섞이면 듣는 입장에서는 정말 편하게 들을 수 있지만 나는 평소에 유머센스가 그리 좋은 편이 아니기 때문에 무리해서 웃길려고 노력하지 않는다. 그리고 몇번해보니 내가 의도했던 웃음 포인트에서는 오히려 잘 웃지 않고 웃으라고 했는데 안웃으니까 당황해서 더 안좋더라는... 그냥 이미지나 메시지 같은데서 적당히 웃겨도 좋고 안웃겨도 좋은 정도로 하는 편이고 편하게 하다보면 오히려 잘 웃어주는 경우가 많았다.

발표자료

• 자기소개: 난 이력에 거창하게 자랑같은 얘기를 막 적는걸 별로 안좋아하는 편이라 그동안은 발표자료에 자기소개를 잘 안넣었다. 하지만 발표자료에 신뢰성을 높히기 위해서 혹은 어떤 배경을 가진 사람인지 약간 아는 것이 발표내용을 듣는데도 좋을 꺼라는 생각에 최근에는 자기소개를 넣기 시작했다. 여전히 누군지 보다는 어떤 내용을 어떻게 설명하냐가 더 중요하다기 보기에 자기소개에 많은 시간을 할애하진 않는다.
• 목차: 목차는 넣는 것이 좋아 보인다. 나도 잘 안넣다가 최근에는 넣으려고 하는 편인데 청중들이 미리 어떤 얘기를 할지 예상하고 현재 어느 부분을 설명하고 있는지 예상할 수 있다는 장점이 있다. 어떤 발표자료는 장표마다 현재 전체 발표목차에서 어느 부분인지를 보여주는 인덱스를 추가한 것도 본적이 있는데 발표자료를 보는데 거슬리지 않는 정도에서 괜찮다 보인다.
• 나는 키노트를 사용한다. 발표를 시작했을 무렵에는 맥을 쓰기 시작했으므로 처음부터 키노트를 썼는데 키노트를 써보고 파워포인트가 얼마나 형편없는지 알게되었다. 파워포인트로도 발표자료를 못 만드는 것은 당연히 아니겠지만 라인 맞추기 등 키노트가 나은 점들이 있다고 본다. 하지만 파워포인트를 써본지가 너무 오래됐기 때문에 객관적인 비교는 아니므로 자기가 쓰기 편한 도구를 쓰면 된다.
  • 참고로 HTML5 슬라이드(reveal.js같은)는 거의 쓰지 않는다. 처음에 구글에서 HTML5 슬라이드를 공개했을 때는 너무 인상적이라 몇번 시도했지만 몇번 써본 결과 발표자료를 만드는데 불필요한 HTML 불필요한 HTML등을 다루는데 너무 시간이 많이 들어서 사용하지 않는다. 지금은 좋은 도구들이 많이 나오긴 했지만 여전히 슬라이드 전용도구에 비해서는 너무 간단하거나 손이 많이 간다. 발표자료는 원하는 내용을 보기 편하게 제공해야한다고 생각하기에 HTML5 슬라이드는 사용하지 않는다.(구글 Docs류도 마찬가지다.) 이쁘게 꾸밀 필요는 없고 간단하게 발표할 때는 종종 쓰기는 한다.
  • 내가 HTML5 슬라이드를 고려하는 경우라면 웹 프론트앤드쪽 발표를 하게 되서 발표자료안에 예제를 바로 시연할 수 있도록 구성할 수 있는 경우에만 고려할 것이다. 사실 키노트로 발표하다가 시연을 위해서 창을 바꿨다 돌아왔다 하는 것이 보기는 좋지 않으므로 예제를 발표자료와 잘 섞을 수 있는 경우가 HTML5 슬라이드의 장점이 가장 잘 부각되는 경우라고 생각한다.
• 영문은 최대한 쓰지 않는다.: IT쪽이나 기술발표를 위주로 많이 하다보니 영문이 많이 있고 발표자료를 만들다 보면 솔직히 영문으로 쓰는게 훨씬 이쁘게 꾸밀 수 있는 경우가 많다.(이는 영어라서 이쁘게 보인다는 착각을 얘기하는게 아니라 타이포그라피자체가 한글보다 영어가 훨씬 발달했기 때문이다.) 예전에는 영어를 많이 쓰기도 했지만(문법에 오류있으면 창피하기도 하고) 지금은 거의 안쓴다. 발표를 듣는 사람이 대부분 한국 사람이므로 아무리 쉬운 영어라고 하더라도 읽고 받아들이는데 무조건 한글이 좋다. 메서드 이름이나 꼭 영어로 써야 하는 경우가 아니면 무조건 한글로 바꾼다. 개인적으로는 한국사람도 한번에 읽을 수 있는 2단어 혹은 좀 익숙한 말이면 3단어 정도까지가 한계라고 생각하고 그 이상이 되면 모두 한글로 변환한다. 인용하는 경우에도 한글로 보여주고 원문 링크등을 넣는 것이 차라리 낫다.

• 나는 발표자료에 중요 메시지만 넣는걸 선호한다. 그래서 내 발표자료는 나중에 발표자료만 보면 무슨 내용인지 알기가 좀 어려운 편이다. 내 발표 스타일은 가르 레이놀즈의 프리젠테이션 젠 시리즈(프리젠테이션 젠, 프리젠테이션 젠 디자인)의 영향을 많이 받았는데 이 책중에 발표자료는 발표자의 내용과 함께 있을때 완성되어야 하고 발표자료만 보고 무슨 내용인지 알 수 있다면 그냥 발표자료를 배포하면 되지 머하러 발표를 하느냐?라는 얘기가 나오는데 여기에 무척 공감을 하기 때문이다. 발표와 블로그에 글을 올리는 것은 다르다. 기술발표를 하면 기술등을 나중에 참고할 수 있게 발표자료에 넣기는 하지만(링크같은 경우는 나중에 참고할 수 있게 작게 넣는다. 발표중에 URL을 자세히 볼필요는 없으므로...) 발표자료 자체는 발표를 돕기 위한 도구일 뿐이다. 정 필요하다면 나중에 따로 글을 올리거나 설명을 해서 읽어 볼 수 있게 하는 것이 최고일 것이다.(그런 면에서 과거 KTH의 H3컨퍼런스에서 발표주제에 대한 설명을 묶어서 책으로 배포한 경우가 아주 좋은 예라고 생각한다.)
• 주로 이미지를 전체 배경으로 넣는다. 발표자료는 당연히 내용이 가장 중요하지만 디자인도 중요하다. 보기좋은 떡이 먹기도 좋다. 이쁘기만 하고 내용이 빈약하면 필요없겠지만 내용이 좋다면 보기 좋은 것이 더 좋다. 배경이미지를 넣는 것도 프리젠테이션 젠 시리즈에서 배운 것인데 이미지를 처음에 넣으면 이미지의 테두리가 다 보이게 화면에 작게 넣는 경우가 많게 되면데 전체 배경으로 깔거나 테두리 없는 이미지를 넣으면 보기가 훨씬 좋다. 전에는 성공이라는 메시지를 얘기한다면 Success라는 이미지를 찾아서 배경으로 깔았는데 최근에는 이렇게 하면 보기에 좀 이쁜 것 말고는 무슨 의미가 있겠는가 싶어서 이미지가 메시지를 상징할 수 있는 것으로 찾으려고 노력하고 있다. 배경이미지도 메시지를 쉽게 이해하고 받아들일 수 있도록 돕는 역할을 하는 것이므로...
  • 이미지를 찾을 때는 메시지를 잘 표현하는 이미지를 찾으면서 동시에 글씨를 넣을 수 있는 경우도 고려해서 찾는 편이다. 그래서 발표자료를 만들때 이미지를 찾는데 시간이 엄청나게 걸린다.
  • 이미지는 맘에 들었는데 글씨가 눈에 잘 안띈다면 흰색 혹은 검은색 배경을 글씨뒤에 살짝 넣어서 글씨가 잘 보이도록 한다. 이미지 배경에 겹쳐서 글자가 잘 안보이는 것은 정말 좋지 않으므로 그림을 가리더라도 배경을 살짝 깔면 좋고 약간 50~70%정도 투명도를 줘도 상당히 괜찮다.
  • 이미지는 iStock같은 곳이 퀄리티는 좋지만 유료이므로(발표자체가 무료인 경우가 많으므로 ㅠㅠ) 나는 주로 Flickr를 사용한다.
  • 이미지를 찾을때는 저작권을 많이 신경쓰는 편이다. 남의 작품을 맘대로 갔다 쓸 수는 없으므로 주로 검색 옵션에 CCL을 걸어서 조건에 맞는 저작권내에서만 사용하는 편이다. 간혹 안될때는 그냥 쓰는 경우도 있는데 대부분은 절대 저작권이 없거나 저작권을 확인할 수 없을것 같은 짤방일 경우뿐이다. 저작권자가 확실한 경우에는 메일을 보내서 허락을 득하는 것도 좋은 방법이다. 구글 이미지검색에도 라이센스 옵션을 걸어서 검색할 수 있는데 한글로 검색하는 경우에는 별로 믿지 않는 것이 좋다. 여러 사이트에서 CCL 이미지만 검색하는 CC Search같은 사이트도 있다.
  • CCL을 사용한 경우 보통 저작권자 표시는 기본적으로 포함되는데 (라이센스는 항상 어렵기에) 어떻게 표시해야 하는가?에 대해서는 나도 고민이 참 많다. 전에는 마지막 장에 리소스라고 넣어서 발표자료에 사용한 이미지의 원본 URL을 목차처럼 넣고는 했는데 이럴 경우 이미지 변경하고 할 때 관리가 너무 쉽지 않아서 요즘은 각 장표의 하단에 작게 원본 URL을 넣어서 출처를 밝히는 편이다.
• 코드는 신텍스 하일라이트를 준다. 개발관련 주제가 많으므로 코드가 들어가는 경우가 많이 있는데 보통 신텍스 하일라이트를 주는 편이다. 대부분의 개발자가 에디터에서 이렇게 사용하므로 그냥 코드를 넣은 것보다 훨씬 보기도 좋고 이쁘다. 경험상 맥에서는 이클립스에서 특정 테마를 적용한 뒤에 키노트로 복사하면 그 스타일을 그대로 입힐 수 있다. 하지만 난 이렇게 하지 않고 보통 하나하나 선택해서 일일이 색깍을 입힌다. 사실 무척 귀찮고 피곤한 일이긴 하지만 보는 사람이 훨씬 보기 좋고 신텍스 하일라이트는 보통 색이 아주 다양하게 적용되는데 발표자료에서는 코드의 일부만 보여주는 경우가 많으므로 색이 너무 다양하게 적용되면 오히려 보기가 좋지 않아보여서 IDE에서 적당한 테마를 고른뒤에 일부 색상만 적용해서 하일라이트를 입힌다. 코드를 보여주면 어쩔 수 없이 대량의 코드가 필요한 경우가 있는데 너무 많으면 어차피 보는 사람이 이해하기가 어려우므로 최대한 핵심부분만 보여주고 따로 예제코드를 나중에 볼 수 있게 제공하는 것이 낫다.(물론 이렇게 할 수 없는 경우도 당연히 있다.)
• 애니메이션은 거의 쓰지 않는다. 애니메이션을 쓰지 않는 이유는 이게 고난이도 기술이기 때문에 아주 잘 쓰지 않으면 오히려 안좋다고 생각하기 때문이다. 애니메이션이 자연스럽게 잘 쓰지 않으면 오히려 거추장스럽게 느껴지고 청중들이 애니메이션에 시선을 빼앗긴다고 생각하는 편이고 이는 발표내용을 전달하는데 그다지 도움이 안된다고 생각한다.(화려함에 신기해 할 수 있지만 뭐 그뿐이다.) 애니메이션이 이야기 전달에 도움이 되도록 해야 하는데 난 아직 그정도 스킬이 없으므로 쓰지 않는다. 그래서 동일한 이유로 Prezi를 좋아하지 않는다. 취향에 따라 다르겠지만 글자사이에 오가면서 화면이 회전되고 줌인/아웃이 되는게 발표를 듣는데 무슨 도움이 되는지 잘 모르겠다.(물론 Prezi를 잘 살려서 애니메이션 자체가 이야기의 흐름을 잘 타도록 만든 경우도 본 적이 있지만 난 그정도 스킬이 없고 내가 본 대부분의 Prezi발표자료도 그냥 화려한 애니메이션만 마구 넣었을 뿐이었다.)
• 발표끝나고 공유는 여러 가지 방법이 있는데 웹으로 만든 발표자료가 아니라면 대표적으로 slideshare와 Speaker Deck이 있다. 드랍박스나 다른 파일공유서비스로 공유할 수도 있지만 장기적으로 사람들이 볼려면 이런 서비스가 제일 좋다. 키노트로 사용한 경우에는 한글같은 폰트가 깨지는 경우가 많으므로 PDF로 내보내기를 한 뒤에 업로드를 하며 깨지지 않는다. 사실 발표자료는 이런 서비스에서 좋은 발표자료를 많이 보는 것도 꽤 많은 도움이 된다.

주의사항

• 폰트 사이즈에 신경써야 한다. 의외로 발표자료를 보면 폰트사이즈가 작은 경우가 너무 많다. 발표장소에 따라 다르지만 큰 장소라면 뒤에서도 잘 보이는지 신경을 많이 써야 한다. 난 절대 작아서 안보인다는 말이 나오지 않게 대빵만하게 70~90 포인트의 폰트를 선호하는 편이다. 발표 준강에 잘 안보여요라고 사람들이 말해주면 좋지만 청중들은 잘 그러지 않으므로 발표자가 미리 신경써야 한다. 특히 라이브 코딩이나 콘솔로 데모하는 경우에도 폰트크기를 뒤에서도 잘 보이도록 키워주어야 한다.
• 하단 10%정도는 사용하지 않는다. 발표하는 곳이 청중들보다 높은 곳에 있다면 좋겠지만 그렇지 않은 곳이 대부분이다. 뒤에 앉은 사람은 앞의 사람 들 때문에 발표자료의 하단부분은 잘 보이지 않으므로 하단부는 중요한 내용들을 넣지 않는 것이 좋다. 밑부분은 약간 공백을 두어도 좋다.
• 글씨나 배경이 명도/채도가 비슷하지 않도록 주의해야 한다. 사실 요즘은 모니터들이 다 좋아서 약간만 명도/채도가 달라도 비슷해 보이지만 대부분의 발표는 빔 프로젝터를 이용해서 한다. 좋은 빔 프로젝트라면 아주 잘 나오지만 대부분은 그렇게 고급 빔 프로젝터가 아니므로 내 모니터에서는 잘 보였지만 막상 발표하러 가보니 색이 흐려서 구분이 잘 안되는 경우가 많다. 그래서 명도/채도가 많이 차이나게 배색해야 발표당일날 이런 문제를 줄일 수 있다.
• 질문 : Q&A 시간에 질문을 받으면 질문을 다시 얘기해주는 것이 좋아보인다.(이건 나도 잘 안되는데...) 보통 질문자는 마이크가 없는 경우가 더 많기 때문에 발표자만 질문을 듣고 대답하면 사람들은 질문내용이 뭔지 모르는 경우가 많다.

마지막으로 내가 맨 처음 공개적으로 발표를 할 때 "어차피 발표끝나도 아무도 말을 안해줘서 잘 했는지 안했는지 모르니까 맘 편히해"라는 말을 들었는데 사실이다. 세미나 많이 가본 사람은 알겠지만 보통 청중이 큰 반응이 없고 끝나고 피드백을 주는 경우도 없다. 누가 후기라도 올려주면 욕이든 칭찬이든 감사할 따름이다. 발표자가 피드백을 받을 수 있는 다양한 방법을 연구해서 피드백을 받도록 하는 것도 다음 발표에 도움이 된다.
그리고 내가 세미나의 주최측의 일원이 될 경우에는 대부분 발표 리허설을 진행했었다. 발표 리허설의 경우는 커뮤니티내의 사람들이나 준비하는 사람들 위주로 진행했는데 경험상 발표준비가 어느 정도 수준이든간에(아주 부족하거나 상당한 퀄리티로 준비했거나) 무조건 리허설 전보다 수준이 올라간다. 일단 듣는 사람들이 친분이 있는 경우가 많고 리허설의 목표도 부족한 부분에 대한 의견제시이므로(모두 받아들일 필요는 없다) 꽤 양질의 피드백을 받을 수 있고 듣는 입장에서 어떻게 들리고 어떤 생각 혹은 궁금증이 생기는지 들을 수 있다. 이런 자리를 활용하면 발표 수준을 높힐 수 있고 여러 트랙이 아닌 한 트랙으로 진행하는 경우에는 다른 발표자가 어떤 내용을 설명하는지 알게 되는 것도 발표내용을 조정하는데 상당히 도움이 된다.

My Comment..
현재는 아니지만 과거에는 발표에 나름 관심이 좀 있었고, 발표를 하기도 했었다.. 제안 발표도 해보고 말이지.. 그런데 햄의 말처럼 역시나 많이 해보는 것이 중요한듯하다.. 물론 발표에만 해당되는 것은 아니라고 본다.. 어떤 일이건 많이 하면 그만큼의 실력이 붙고 노하우가 생기지만, 손을 놓고 있으면 그 시대에 떨어지기 때문에 당연히 실력은 줄어들 수 밖에 없다.. 정확히 말하면 실력이 떨어지기보단 시대에 뒤쳐지면서 본인의 실력은 제자리 걸음이다라는 말이 더 맞긴 할 것이다..

무튼 머.. 해당 글은 상당 부분 공감 되는 내용이다.. 무엇보다 나는 과거에는 발표라고 하면, 글자가 많아야 된다고 생각을 했다.. 신입시절 그런 PPT 만 작업을 했기 때문에.. 하지만 가만 보면 요새는 몇 가지의 키워드만 적어서 청취자로 하여금 부각될 수 있도록 작성하고, 그 키워드를 토대로 덧붙여서 설명을 하는게 더 좋은 듯 하다..

나도 기회가 되면 발표를 해보고 싶지만 내 성격이 쓸데없이 진지해지는 경향이 많아서.. 괜시리 진지해지기만 할까봐 발표에 대한 것은 생각해보면 은근 걱정된다.. 난 진지한것보단 좀 가볍게 느껴지는 것이 좋은데 말이지.. ㅎㅎㅎ..

But.. 우선 해보기나 하고 생각하자.. ㅋㅋㅋㅋ..

[EP] Github HQ 3.0 방문기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

d3.bayarea()의 d3 dat app 밋업에 참가한 이유는 관심기술이기도 했지만 장소가 다른 곳도 아닌 Github HQ 3.0이기 때문이었다. 정확한 히스토리는 모르지만 버전으로 봤을 때 3번째 사무실로 보인다. 그러니까 지난 번에 샌프란시스코에 왔을대 들어가진 못하고 앞에서 서성거리기만 했던 곳은 Github HQ 2.0이고 새 사무실은 올 8월정도에(추측) 새로 옮긴 사무실로 보인다. 이전 사무실은 못 들어가 봤고 검색하면 HQ 3.0 사진이 많이 나오긴 하지만 방문한 기념으로 남겨본다.

큰 건물의 3개층을 모두 쓰고 있었는데 1층은 행사하고 손님 맞이하고 식사하는 용도인듯 하고 일하는 사무실은 2,3층에 있는 듯 하다.(2,3층은 못 가봤다.) 투자를 엄청난 금액으로 받았으므로 사무실도 좋은 곳으로 크게 옮긴듯 하다. 간판이 붙었다. 전에도 스타트업 사무실들을 찾아 돌아다닌 적이 꽤 있는데 특이하게 이런 회사들은 간판자체가 아예 없는게 특징인데 드디어 간판이 붙었다. 간판은 대로변에는 없고 손님용(?) 입구인 골목쪽에 있는 입구에 달려있다. 이쁘다 옥토캣 간판... 현관에 들어가면 조금만 공간에 몇가지 기념품(?)들이 전시되어 있다.

옥토 트로피

Crunchie Awards에서 Best Overall Startup 2012, Best Bootstrapped Startup 2008로 받은 트로피다. 고릴라 캐릭터가 귀엽다.

Laptop of Ryan "Turn Up King" Tomayko라고 제목이 붙어 있었다. Ryan Tomayko, Kyle Neath, Chris Wanstrath이 Github의 풀리퀘스트를 최초로 구현할 때 사용된 노트북이란다.

Octocat Skeleto - Felis octocatus
깃헙이 익명으로 기증을 받은 옥토캣을 증명하는 가장 오래된 화석이란다. 대략 630만년정도 된 것으로 추측하고 중국해 남쪽해안 어딘가에서 발견되었고 Felis silvestris와 Felis octocatus사이로 분류된단다.(농담아니고??? 아무튼 저렇게 써있었음..)

옥토트로피... 이런거 집에 하나 있었으면 좋겠다.

현관을 지나가면 백악관의 대통령실처럼 꾸며놓은 이쁜 방이 나온다. 이 방의 정확한 용도는 잘 모르겠는데 쇼파도 있고 하는걸 보면 손님을 맞이하는 방이 아닌가 싶다.(입구에 있는거라서 회의같은 건 못할듯...) 공간의 일부를 이런식으로 꾸민 건 재미있다.

대통령 책상에 놓여있는 안내문(잔잔한 센스가...)

바닥에는 센스 좋게 United Meritocarcy of Github라고 써있는 양탄자가 깔려있다. 옥토캣이 손에 포크까지 들고 있는 센스가...

방의 일부에 놓여있던 장식물...

대통령실을 지나서 들어가면 옥토캣이 사색에 잠겨있다.(귀여워~)

그 옆으로는 식당으로 보이는 직원들이 앉아서 먹을 수 있는 공간이 있다.

한쪽에는 Github Pub이라고 해서 사내에 있는 Pub이라기에는 꽤 큰 규모의 Pub이 있다. 근무시간에도 운영하는 것인지는 잘 모르겠지만 d3 유저그룹 모임에 참석한 사람들은 그냥 가서 맥주든 뭐든 달라면 바로 준다.(근무시간에도 맥주를 주나?)

그 한쪽 편에는 세미나를 할 수 있는 공간이 준비되어 있다.

사내 세미나가 많은 것인지 이런 외부 행사를 많이 유치하는 것인지 세미나 장소는 아주 잘 완비되어 있었다. 7-80명정도 앉을 수 있는 공간인데 뭐 의자만 더 놓으면 훨씬 더 많이 앉을 수 있는 여유로운 공간이다. 빔프로젝트외에도 모니터가 사방에 준비되어 있어서 사람이 많이 왔을 때도 화면을 보는데 어렵지 않을 것으로 보이고 발표자용 모니터화면도 잘 준비되어 있어서 왠만한 세미나 시설못지 않다.

d3.bayarea() 밋업도 진행하면서 바로 실시간 중계를 인터넷으로 했는데 이 화면처럼 라이브로 발표화면과 발표자의 모습을 녹화할 수 있도록 시설이 완비되어 있다.(역시 투자를 많이 받으니 달라..)

뒤쪽에는 이렇게 녹화등을 관리하는 엔지니어실이 위치하고 있다. 이번에 샌 프란시스코를 가면서도 스타트업이나 유명한 회사들에 방문을 하고 싶었고 Github도 가보고 싶었던 곳이라서 메일 보내서 사무실 투어를 신청해 보거나 저번에 Github에서 얘기를 주고 받았던 Phil한테 부탁해서 방문해 볼까 하다가 일행이 있는게 아니고 혼자라서 약간 애매하기도 했고 또 사무실 방문은 그냥 가보고 싶은 것이지 거기서 얻을 수 있는 큰 의미는 없었기에 하지 않았는데 이런 기회로 갔다 오게 되서 참 좋다...

My Comment..
내가 가본 곳은 아니지만, 햄의 후기를 통해서 그래도 이렇게 생겼구나.. 이런 곳이구나.. 이렇게 생활을 하는 구나 하는.. 부분에 대해서 알게 되서 좋으다.. 모든 지식이나 정보란 것이 나 스스로 터득하면 좋겠지만 꼭 그게 정답은 아니니까..

특히나 IT 관련된 부분들은 항상 저 멀리 먼저 앞서나가는 햄의 정보를 토대로 공부하고 답습해도 나에게는 많은 도움이 된다라고 생각한다.. 새삼스럽게 햄.. thank u..

[NEWS] 페이스북 그룹 영상통화 기능 발표..

전문적인 IT 뉴스 페이지는 아니지만 그래도 포털 사이트에서 제공하는 IT 뉴스 페이제를 보고 지나간다.. 그런데 페이스북에서 그룹 영상통화 기능을 도입했다고 한다..

보편적인 영상통화는 많지만, 그룹으로 여러사람이 하는 것은 기능적인 부분을 떠나서 개인적으로 좀 생각을 했던 부분이다.. 여러명이 같이 모바일에서 웃고 떠들면서 영상통화를 할 수 있다면 어떨까 하고 말이다..

페이스북의 그룹 영상통화 기능은 채팅방 우측 상단의 캠코더 아이콘을 눌러 사용하면 된다고 한다.. 버튼이 활성화되면 약 3초 후 그룹내 모든 사람에게 영상통화에 대한 알림이 발송되고 각자가 수락을 하면 그룹 영상통화에 참여하고 함께 하는 것이다..

해당 기능은 최대 6개의 분할 화면을 통해 이야기를 나눌 수 있으며 최대 50명까지 대화에 참여해 실시간으로 통화 내용을 들으며 음성, 문자, 스티커, 이모티콘, GIF 이미지 등을 주고받을 수 있다고 페이스북 측은 밝혔다..

그런데 난 여기서 드는 생각이 그렇게 많아지면, 과연 버퍼링을 감당할 수 있을까 싶다.. 아무리 요새 휴대폰이 좋아졌다고는 하지만 정말 원할하게 될런지 의문이긴 하다.. 현재도 다른 메신저에서 제공하는 1:1 영상통화도 자주 끊기기 때문에 말이지.. 흠..;; 그런 문제는 차차 개선해나가겠지..??? ㅎㅎㅎ...

[UFC] 론다 로우지 드디어 돌아오다..

아주 기쁜 소식을 보게 되었다.. UFC 여성 벤터급 전 챔피언 론다 로우지가 복귀를 한다는 것이다.. 물론 지난 시간에도 복귀를 한다는 얘기들은 많았고, 훈련중이다.. 머 하고 있다.. 등등 말들은 많았다..

하지만, 지금처럼 본격적으로 오피셜이 딱 뜬 것은 처음이지 싶다.. 내 기억상에는 말이지.. ㅎㅎ..
복귀시점은 바로 현지시간 기잔 오는 31일 UFC 207 에서 아만다 누네즈와 여성 밴터급 타이틀전이다.. 또한, 메인 이벤트로 말이다..

기대가 엄청되는 매치업이다.. 하지만 그 이면에는 좀 걱정이 들기도 한다.. 해당 매치에 대한 부분보다 로우지가 과거 타이틀을 뺏길 때 타격으로 처참하게 무너진 부분이 걱정이 된다.. 누네즈 역시 타격이라면 남부럽지 않다.. 또한, 파워도 워낙 좋은 선수이다.. 그런 상대로 로우지는 그라운드에 가는 것이 아니라면 타격에서 앞설것이라고는 보지 않는다..

아무리 훈련을 많이 했다 하여도 한순간에 타격 실력의 격차를 좁혔을것이라고 보지는 않는다.. 그렇다고 로우지가 복귀전까지 훈련만 한것도 아니지 않은가.. 영화도 촬영하고 나름 기타 일들로 바쁘게 지내온 그녀다..

난 로우지 팬이다.. 화끈하고, 항상 자신감 넘치고, 분위기를 선도하는 듯한 그녀가 좋다.. 하지만, 이번 경기는 상당히 걱정이 되는 마음 또한 같이 든다.. 준비를 잘해서 좋은 경기를 보여주길 바란다.. 그리고 기대를 하고 있겠다..

올해의 마지막 이벤트에서 다시 챔피언 벨트를 들고 환하게 웃는 그녀의 모습을 상상해본다.. 그 모습을 볼 수 있기를..

[EP] d3.bayarea() 유저그룹 Meetup 후기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

컨퍼런스가 있어서 샌프란시스코에 출장을 갔다왔는데 주말을 이용해서 출장일정보다 조금 더 일찍 갔다왔다. 여유시간동안 쇼핑도 하고 여기 저기 돌아다녔지만 관광이 주 목적이 아니었기에 meetup사이트에 가서 갈만한게 있는지 계속 검색해 봤다.(나중에 보니 Eventbrite도 같이 검색해 보는게 좋을듯...) 사실 혼자가서는 외국인과 대화할 일이 별로 없기 때문에 꼭 기술관련 밋업이 아니더라도 갈만한게 있으면 갈 생각이었지만 딱히 갈만한 건 눈에 띄지 않았는데 베이지역의 d3 유저그룹에서 d3 dat app이라는 밋업을 한다는 것을 알게 되어서 갔다가 왔다.

d3.js는 관심기술이기도 했으니 참가하기 딱 좋은 밋업이었다. 사실 신청할 때 대기자가 몇십명정도 있어서 기대안하고 신청버튼을 눌렀는데 내가 잘못봤는지 어땠는지 참가승인이 나서 낮에 관광을 갖다가 와서 저녁에 냉큼 다녀왔다. 뭐 관광지라서 저녁에 걸어다녀도 위험하진 않았다. 뭐 아무래도 영어로 발표하다 보니 다 이해하진 못했고 대충이나마 적고 내가 잘못 이해하거나 중요한 부분을 빠뜨렸을 가능성도 높다.

Application building with D3 - John Firebaugh

• 발표자료

이 발표는 밋업에서 봤지만 아마도 HTML5 Developer Conference에서 발표한 내용과 동일한 듯 한다. 이 발표는 오픈스트리트맵의 맵 에디터로 d3기반으로 만든 iD라는 맵 에디터에 대한 얘기였다. 일반적으로는 jQuery나 Backbone.js등으로 웹 어플리케이션을 만들고 좀 더 최신기술을 사용하는 경우에는 ember나 angular.js를 사용하지만 iD는 이런 것들이 아니라 d3.js를 기반으로 만들었다. jQuery와 d3를 비교했을 때 Dimension관련 부분은 jQuery에만 있지만 데이터 바인딩은 D3에만 있고 그 외 Ajax, CSS, 이벤트등 대부분의 기능은 양쪽 모두에 존재한다.

d3.js를 선택한 이유는 선언적인 방법이 명령형(imperative) 방법보다 좋기 때문이고 jQuery가 명령형이라면 d3.js는 선언적이다. 프레임워크는 비즈니스 로직은 프리젠테이션 로직에서 분리하기 쉽게 해주는데 backbone.js는 이부분이 개발자의 몫이고 ember나 angular.js는 스마트 템플릿을 사용하고 있다. d3에서는 3단계로 이뤄지는데 "진입(enter) -> 갱신(update) -> 종료(exit)"로 이뤄진다. 여기서 작업을 최소화 하기 위해서는 다음 규칙을 따르면 된다.

• 정적 프로퍼티는 진입 단계에서 선언한다.
• 동적 프로퍼티는 갱신 단계에서 선언한다.
• 대량 갱신은 개별적인 "instance changed" 이벤트를 사용하지 않는다.
• 실제로 변경되는 요소의 선택을 필터링한다.

iD에서 모델은 불변객체이므로 변경하지 않고 변경해야 할 경우에는 새로운 객체로 만들고 히스토리를 관리하고 있다.
그리고 d3.js의 단점 중 하나는 너무 크다는 것인데 이는 smash로 필요한 파일들만 가져와서 빌드할 수 있다.(써본적은 없지만 smash도 d3.js를 만든 Mike Bostock이 만든 도구로 이미 d3.js도 이를 사용해서 빌드하고 있다.) 앞에서도 말했듯이 dimension관련 부분이 d3.js에 없는 것도 하나의 단점인데 이는 직접 플러그인을 작성할 수 있고 d3 플러그인은 d3-plugins나 d3-bootstrap에서 찾아볼 수 있다.

Pick technology that fits your problem domain.

.append() IT TO THE LIMIT - HIGH performance d3 - Victor Powell

• 발표자료 & 데모

d3 사용할 때 퍼포펀스 향상에 대한 얘기였는데 d3를 자세히 몰라서 그런지 제대로 잘 이해해지는 못했다. 최적화를 할때는 언제 최적화를 하고 언제 최적화를 하지 않을 것인지가 중요한데 이는 대부분 개발자 시간이 CPU 시간보다 크기 때문이다.

"Premature optimization is the root of all evil" - 도널드 크누스

setInterval() 보다는 requestAnimationFrame() 를 이용한 transition() 이 낫고 크기를 변경할 때는 redraw하는 것보다 scala(X,Y) 이 낫고 transform 보다는 cx, cy 를 이용하는게 빠르다. 그리고 왠만하면 DOM은 건드리지 않는게 좋은데 특히 계산된 프로퍼티는 조작하지 않는 것이 좋다. 그리고 값을 변경할 때 변경되지 않은 요소들은 미리 필터링하는 것이 성능에 좋다.

기타...

메인 발표는 위의 두 가지였고 유저그룹이다 보니 이후부터는 공유할 거리가 있는 사람들이 5분 10분씩 나와서 자신들이 한 작업들을 공유했는데 유저그룹에서 이런 진행은 자유스럽고 좋아보였다. Sara Quigley가 University of California System Campuses라는 캘리포니아 대학의 예산관련 비쥬얼라이제이션을 보여주었는데 그래프와 인터렉션을 깔끔하게 잘 만들었다. 이 인터렉션을 위해서 사용자가 어떤 값을 선택할 때 인터렉션을 보여주는 전략에 대해서 Strategic Dilemmas와 Strategy Spaces를 소개해 줬는데 잘 모르는 분야라 흥미로웠다.

CrowdSound라는 사이트를 준비하고 있는걸 보여주었는데 컨퍼런스 같은데서 청중들이 질문들을 올리고 발표자가 여기에 피드백할 수 있는(백채널이라고 하나?) 시스템에 대해서 보여주었는데 딱히 큰 건 없었다. 이 유저그룹에서 샌프란시스코의 교통수단인 Bart에 대한 비쥬얼라이제이션 사이트 Visualizing the BART Labor Dispute를 보여주었는데 실질적인 데이터로 유저그룹에서 저런 사이트를 만든게 재미있었다.(서울데이터로도 저런걸 만들 수 있을라나?) d3-tip을 쓰냐면서 좋으니까 꼭 쓰라고 했는데 이건 차트에서 툴팁 띄워줄대 유용할듯하다.

[UFC] UFC 마감뉴스..

출처 : SPOTV NEWS

[EP] Deview 2013에서 발표한 "Popular Convention 개발기" 발표자료..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

Deview에서 발표를 했다. 내 첫 발표였던 JCO이후에 컨퍼런스 규모로는 가장 큰 규모의 컨퍼런스에서 2년만에 발표를 하게 되었다.(JCO에서 발표할 때 덜덜덜 떨었던 것을 생각하면 2년 사이에 참 많은게 달라졌다.)

원래는 Deview에서 발표를 할 계획이 아니었지만 내 개인프로젝트인 Popular Convention이 Github Data Challenge에서 2등을 하고 나서 Deview측에서 지인을 통해서 발표가 가능한지 연락이 왔다. 당시에 고민했던 것은 자그만한 개인 프로젝트인데 공유할 부분이 있을까 하는 것과 당시가 7월인데 3달이나 지난 10월에 이 프로젝트를 주제로 하는 것이 괜찮을까 하는 것이었는데 고민끝에 하기로 했다.(이 프로젝트를 서비스로 바꾸려고 리펙토링을 시작한 것도 발표를 해야하는 부분도 한 몫했다.) 어쨋든 발표를 하기로 했으니 시간 지나면 잊어버릴까봐 당시에 날짜별로 진행과정이나 이런걸 모두 기록해 놓고 발표할 때 도움이 될것 같은 데이터도 모으고 스크린샷도 생각나는대로 다 찍어서 보관해 놨다.

먼저 올린 스프링캠프에서의 발표에 바로 이어서 발표를 해야했지만 이 발표는 얘기할 게 어느 정도는 정해져있었기에 이 발표자료를 먼저 만들었다. Deview측에서 진행을 원활하게 하기 위해서 발표자료를 1차, 2차로 나누어서 좀 이른 일정으로 공유해 주기를 원하기도 했고...

Popular Convention 개발기 from Outsider Byun

최근에는 이전에 만들던 발표자료보다 좀 더 퀄리티를 높이고 싶어서 여러 모로 신경을 쓴 발표자료다. 개인 프로젝트의 경험에서 어떤 부분을 전달해 주어야 듣는 사람들에게 의미가 있을지도 참 많이 고민했었는데 마지막까지 이 부분은 명확치는 않았다. 너무 억지로 메시지를 담으면 뭔가 가르치려는 것 같고 자연스러울 것 같지도 않아서 프로젝트를 진행하면서 각 단계별로 내가 고민했던 부분이나 의도했던 부분을 공유하는 쪽으로 해서 발표흐름을 잡았지만 듣는 사람한테 의미가 있을지는 마지막까지 신경이 쓰였다. 사실 스프링캠프쪽은 리뷰를 3번이나 받았지만 이 발표는 여유가 없어서 리뷰를 받지 못해서 막상 당일이 되니까 억지로라도 시간을 내서 리뷰를 받을걸 그랬나 하는 생각이 많이 들었다.

발표가 마지막 발표라서 마음에 여유가 없으니 다른 발표도 듣지 못하고 나와서 돌아다니며 사람들만나다가 스피커 대기실에서 연습한번 하고 나가서 다시 수다떨다가 들어오면서 당일날만 한 3번정도 연습해 본것 같다. 연습할때는 45분이 꽉 채워져서 시간초과할까봐 걱정을 많이 했는데 정작 실제로 할때는 7분이나 빨리 끝냈다.(역시 실전은 달라...) 예전과 다르게 조금은 발표에 여유가 생겨서 청중들도 어느 정도는 볼 수 있게 되었는데(예전엔 정말 화면밖에 안보였;;;) 마지막 시간이라서 중간에 나가시는 분들이 종종 있어서 발표가 재미없나 하는 걱정도 중간중간 많이 들었다. 흑흑... 그래도 끝내고 나니 좋았다고 잘 들었다고 해주시는 분들이 많아서 다행이라는 생각이 들었다. 개인 프로젝트로 좋은 결과도 없고 그 덕에 큰 무대에서 발표도 해보고 여러 모로 좋은 경험이었다.

한달여 내 마음을 무겁게 누르던 발표가 모두 끝나서 맘이 평안하다.... 최근 발표가 급 몰려있었는데 당분간은 발표 좀 쉬어야지. 발표준비하느라고 코딩도 한참동안 못했고.. ㅎ

[EP] SpringCamp 2013 with Scala에서 발표한 "Spring Scala : 스프링이 스칼라를 만났을 때" 발표자료..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

KSUG에서 오랫동안 스프링 컨퍼런스를 기획하고 준비했지만 이런 저런 일로 계속 미뤄지다가 올해 처음으로 SpringCamp 2013 with Scala라는 이름으로 열렸고 이번에는 라 스칼라 코딩단도 함께 했다. 난 사실 양쪽다 소속되어 있지만 KSUG 보다는 라 스칼라 코딩단에서 더 많이 활동하기에 이번에는 라 스칼라 코딩단입장에서 참석을 했다. 처음에는 일부 세션 혹은 한 트랙정도로 준비를 하려다가 진행되다보니 여력이 좀 더 되서 라 스칼라 코딩단에서 7개 세션을 진행하게 되었고 그 중에 하나의 세션을 맡아서 발표를 했다.
사실 이 다음날 Deview에서 발표가 예정되어 있었기 때문에 원래는 발표를 할 계획이 없었다가 컨퍼런스 준비를 하는 과정에서 스프링과 스칼라가 함께하는 행사이니 만큼 Spring Scala를 발표하는 것도 괜찮다는 의견이 나왔고 나도 수긍을 했다. 부담되서 고민을 좀 하다가 이 주제를 내가 맡아서 발표를 진행했다.

끝나고 나서 하는 말이지만 이번 발표는 준비하는데 정말 힘들었다. ㅠㅠ 발표는 보통 2가지로 나눌 수 있는데 잘 알고 있는 것에 대한 지식이나 경험을 공유하거나 아니면 이슈가 되는 기술을 공부해서 알려주는(?) 형식이 될 수 있다. 전자가 훨씬 좋다고는 생각하지만 상황에 따라서는 둘 다 유효하긴 하다. 이번에는 후자의 경우였다. 작년에 Dtrace에 대한 발표를 했을 때 나는 이런 접근으로는 발표하지 말아야지 했었는데 이번에 한번 더 하고는 고생을 많이했다. 공부하는 것 자체가 어려운 것보다는 공부하고나니 내 생각처럼 발표의 방향을 정하기가 쉽지 않았기 때문이다.

스프링 스칼라는 커미터들의 의도때문인지 아직 초반이기 때문인지 기능이 솔직히 좀 빈약하다. 그래서 기능소개로는 발표시간을 채우기도 어려웠고 그정도 수준에서 발표한다는 것이 청중들에게 얼마나 의미가 있을것 같지도 않았다.(스프링원 같은 대형 컨퍼런스에서 이런 주제만으로 발표했다는게 의심스러울 정도...) 그래서 고민끝에 스프링 스칼라만 설명하는 것이 아니라 스칼라로 스프링을 사용하는 과정을 전체적으로 담으면(사실 스프링 스칼라에 관심있다는 것은 최종목표가 이것이므로) 좀 낫겠다 싶어서 스프링의 Pet Clinic예제를 스칼라로 변환하기 시작했다. 이 예제를 작성하는 동안 고생도 많이하고 사실 스트레스도 엄청 받았는데 어쨌든 다음 발표자료의 흐름을 만들게 되었다.(이것도 좀처럼 쉽지는 않았지만...)

Spring Scala : 스프링이 스칼라를 만났을 때 from Outsider Byun
실제로 들으신 분들이 어떻게 들으셨는지는 정확히 모르지만 삽질기(?)를 공유하는 것도 어느 정도는 의미있다고 본다. 누군가 스칼라로 스프링을 사용해 보고자 하는 사람들에게는 의미를 줄 수 있다고 생각하고 그에 대한 고민을 하고 있는 사람들에게도 도움이 될 듯 하다.(미리 삽질을 해봤으니..) 개인적으로도 스칼라로 스프링을 사용하는 과정을 경험해 봤다는 면에서도 의미는 있었다. Deview와 날짜가 이어져서 발표준비등으로 많이 스트레스를 받았지만 큰 사고없이 발표를 마쳐서 다행이다.

추가적으로 좀 빈약했던 내용이었지만 커뮤니티를 통해서 리뷰를 3번이나 받았기 때문에 퀄리티가 꽤 올라갔다. 항상 느끼지만 좀 힘들어도 리뷰를 받으면 발표퀄리티를 확실히 높힐 수 있는것 같다. 이 자리를 빌어서 행사를 준비해 주신 KSUG와 라 스칼라 코딩단의 자원봉사자분들과 리뷰하는데 도움을 주신 라스칼라 코딩단 분들때 감사를 드린다.

[UFC] UFC 마감뉴스..

출처 : SPOTV NEWS