[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

레이블이 EP인 게시물을 표시합니다. 모든 게시물 표시
레이블이 EP인 게시물을 표시합니다. 모든 게시물 표시

2017년 3월 23일 목요일

[EP] Inspire 자바스크립트 컨퍼런스의 Firejune님 발표에 대해..


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

지난주 금요일(28일)에 열린 Inspire 자바스크립트 컨퍼런스에서 Firejune님의 발표를 보고 SNS에 감탄을 쏟아내면서 의도치 않게 사람들에게 궁금증은 유발하면서 뭔지 알려주지는 않는 낚시가 되어 버렸다. 뭔가 설명을 하고 싶기도 했지만 글로 설명하기도 어려워서 그랬던 것인데 결과적으로는 낚시가 되어버렸고 이에 대한 책임감(?)이 좀 느껴져서 정리한다.(글로 제대로 전달될지 불안할 따름이다.)

Mobizen 화면
사진 출처: https://play.google.com/store/apps/details?id=com.rsupport.mvagent

Firejune님의 발표에서 놀랐던 것은 발표내용보다는 데모에서였는데 위의 화면에 보이는 웹 애플리케이션이다. 초반에 "좀 다르게 개발하기"에 대해서 웹소켓 등의 얘기를 하면서 듣고 있다가 약간의 집중력이 흐트러질 무렵 위의 데모를 보여주셨다. 처음에 데모를 보면서 "저게 무슨 화면인가?"하고 쳐다보면서 이해하는데 약간의 시간이 걸렸다. 사실 처음에는 웹 애플리케이션이 있고 안드로이드가 잘 안 보이니까 에뮬레이터 같은 프로그램을 그 위에 띄워놓은 줄 알았다.
  • 위 PC의 화면(iMac안에 있는)은 웹페이지이다.(이런저런 검색해보면 비슷하게 생긴 앱도 있는듯한데 내가 본 건 웹이었고 기존의 것을 웹으로 포팅한 것인지 등에 대한 자세한 내용은 잘 모르겠다.)
  • PC화면에 나타난 안드로이드 기기는 자신의 안드로이드 기기와 연결되어서 상호 간 원격 조종을 할 수 있다.
    • 안드로이드에서 스크롤을 하면 PC의 화면도 스크롤이 되고 그 반대로도 된다.
    • 안드로이드 기기를 가로로 눕히면 PC의 안드로이드 기기도 자동으로 옆으로 돌아간다.
    • 안드로이드에서 YouTube 앱 같은 것을 실행시켜서 동영상을 재생하면 거의 실시간으로 PC에서도 동영상이 재생되고 앱이 변경되는 애니메이션까지 모두 재현된다.
  • PC 화면에서 스냅샷이나 동영상 녹화를 하면 화면을 이미지로 저장하거나 녹화할 수 있고 이는 기기에도(아마도...) 저장된다.
  • PC 화면에 나와 있는 아이콘들은 안드로이드의 관리 애플리케이션이다.
    • 음악 아이콘을 클릭하면 아이튠스 같은 UI의 화면이 나오면서 안드로이드 기기에 있는 음악목록을 가져오고 바로 재생할 수 있다.
    • PC에 있는 음악을 바로 안드로이드에 넣을 수도 있다.
    • 사진, 동영상도 마찬가지로 안드로이드 기기의 내용을 그대로 읽어와서 화면에 보여준다.
글로 써서 무미건조해 보이지만 위의 내용이 데모의 주된 내용이다. 여기까지 보면 "이거 가지고 그렇게 낚시한 거야?"라고 반응할 수도 있는데 SNS에서도 제대로 설명하지 못한 것도 내가 본 걸 글로 얼마나 전할 수 있을지 몰랐기 때문이다.
내가 이해한 차원에서(그러므로 실제 구현과 약간 다를 수도 있다.) 동작 방식을 좀 더 보자.
  1. 안드로이드와 웹페이지는 웹소켓으로 연결되어 있다.
    • 중간에 웹서버가 하나 있지만, 이는 회원의 로그인 후 안드로이드 기기와 웹페이지를 연결해 주는 역할만 하고 빠지는 걸로 보인다. 그래서 실제 동작할 때는 웹페이지와 안드로이드 기기만 서로 연결되어 있다.
    • 안드로이드에 어떤 앱 같은 게 돌고 있고 여기에 웹소켓 서버가 떠 있고 이 웹소켓 서버랑 웹페이지가 연결된다.
    • 이 앱에서 웹소켓으로 안드로이드의 변화를 웹페이지에 보내고 받는데 내가 안드로이드 개발자가 아니라 이쪽은 정확한 메커니즘은 모르겠다.
    • 원격 제어 부분은 Rsupport의 전문 분야이므로 이에 대해 기본에 갖추고 있는 기술력을 사용했을 거라고 보인다.
  2. 이미지, 음악, 동영상들도 모두 웹 소켓을 이용해서 데이터를 주고받는다.
    • 최초에 연결하면 안드로이드의 내용을 인덱싱하느라 약간의 시간이 걸리지만, 그 결과를 로컬 스토리지에 저장하므로 그 이후부터는 빠르게 목록을 불러온다.
    • 실제 미디어(사진, 음악, 동영상 등)는 로컬에 저장하는 것이 아니라 사용자가 재생할 때 안드로이드에서 웹소켓으로 가져온다.
    • 데모 상의 체감속도로는 거의 데스크톱 수준의 속도였다.(물론 데모에서는 USB로 연결되어 있었고 네트워크면 네크웍의 속도에 따라 다를 것이고 상황에 따라 가장 빠른 속도를 알아서 찾아서 접속한다.)
    • 이미지뿐만 아니라 동영상 등도 거의 딜레이없이 PC에서 재생해 볼 수 있다.
    • 이미지나 음악을 안드로이드기기로 업로드하는 경우에 웹페이지에 올리는 것이 아니라 로컬의 파일을 웹소켓으로 바로 안드로이드로 쏜다.
  3. UI
    • UI는 위 스크린 샷처럼 블러가 먹은듯한 배경 이미지가 깔렸고 그 위에 투명 혹은 반투명의 화면들이 동적으로(축소되거나 페이드인/아웃되는 등) 변화한다.
    • 크롬에서 시연했는데 HTML5와 CSS3를 사용한 것으로 보여서 다른 브라우저에서는 어떤지 모르겠다.(최소한 같은 퍼포먼스나 효과는 나오지 않을 것이다.)
    • 거의 데스크톱앱 수준의(좀 구린 데스크톱앱이라면 그 이상) 메뉴 전환속도와 화려한 애니메이션 효과를 보여준다.
내가(나를 포함한 주위 사람의 상당수) 머리를 한 대 맞은 듯 멍해진 것은 위의 3번 부분이다. 안드로이드에서 데이터를 보내는 건 내가 모르는 분야이므로 궁금하긴 하지만 신기한 정도까진 아니고 웹 소켓이 제공하는 속도가 있으므로 이를 이용해서 데이터를 보내면 만들어 낼 수는 있을 것 같다.(먼저 이렇게 할 생각까진 못했겠지만...)

충격받은 건 UI와 그 성능이다. 웹에서 WebGL이나 SVG 등을 사용한 효과 등을 제외하고 상상할 수 있는 거의 모든 애니메이션 효과가 그 사이트에 들어가 있었지만 하나도 느리지 않았다. 눈으로 보기에 당연히 저런 효과가 들어갔으면 대충 어떤 기술을 사용했을지 머릿속에 그려지고 그거에 대한 퍼포먼스가 생각나서(물론 아주 하드코어 하게 튜닝을 해본 적까진 없지만...) 분명히 딜레이가 있어야 하는데 그런 게 하나도 없이 아주 자연스럽게 돌아갔다.(말도 안 돼!)

이번 파이어준 님의 발표는 생각지 못한 놀라운 기술을 보여줘서 놀랜 것이 아니라 나도 아는 기술인데 그걸 이용해서 엄청난 퀄리티로 만들어냈기 때문이다.** 개별 이펙트를 데모로 만들어 낸다고 생각하면 불가능한 일은 아니지만 이를 하나의 앱으로 만들고 비즈니스 로직까지 섞인 곳에서 전혀 딜레이없는 웹 애플리케이션을 만들어 내는 것은 완전히 다른 차원의 얘기다. 내가 그동안 HTML5나 CSS3에 대해서 뭐 자신감을 느끼고 있거나 그런 것은 아니었음에도 그냥 머리를 한 대 맞은 것 같았다. 파이어준 님은 보여주면 "우와~~"하는 반응을 기대하셨던 것 같은데 눈앞에 보이는 데모를 믿을 수가 없어서 아무런 반응을 할 수 없었다. 트위터에 낚시처럼(고의는 아닙니다.) 쓴 대로 "이게 뭐야?", "이게 말이 돼?"가 내 머릿속에 전부였다.(당시에는 지금 어떻게 데이터를 주고받고 돌아가는 것인가에 대한 고민도 같이 하고 있었지만...) 아마 이 데모는 HTML5/CSS3를 많이 만져봤을수록 충격을 받을 만한 내용이라고 생각하고 뒤풀이에서 얘기가 나온 대로 해보지 않았다면 "요즘 CSS3도 많이 좋아졌네!"정도로 대수롭지 않게 생각할지도 모르겠다.(파이어준 님이 워낙 아무렇지 않게 설명하기도 했고...)

난 웹을 좋아한다. 그래서 웹이라는 플랫폼의 미래에 대해서 가치를 많이 두는 편이지만 현시점에서의 내 생각은 "네이티브와 비교할 때 UI 등에서 어느 정도 타협을 본다면 지금도 해볼 만 하다"였는데 그런 타협이 없이 네이티브 이상의 웹애플리케이션을 봤기 때문에 생각이 완전히 달라졌다.(물론 전혀 타협이 없을 린 없고 그런 느낌이 들 정도로 만들어 낸 것도 엄청난 기획력이라고 본다.) 아래 이미지는 나랑 같은 기분을 느낀 지인이 SNS에 올린 짤방인데 공감이 가서....

겸손해지려 하지마. 넌 그만큼 대단하지 않아.

2017년 3월 7일 화요일

[EP] SSAG 2nd Seminar 후기..


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

페이스북의 Server Side Architecture Group(이하 SSAG)에서 2차 세미나를 해서 오랜만에 평일 저녁에 세미나에 참가했다. 나는 트위터를 위주로 사용하는 편이고 페이스북은 그 틈틈이 사용하는 편이라 여러 그룹에 가입되어 있지만, 그룹에 잘 들어가진 않는다. 사실 여러 그룹을 돌아보기 좋은 인터페이스도 아니긴 하지만 난 보통 글을 퍼블릭하게 쓰는 경향이 있어서 특정 그룹에 글은 잘 안 올리게 된다.(다른 사람은 반대인듯하다.) 어쨌든 SSAG는 꽤 큰 규모로 발전했고 얼마 전부터 세미나도 하기 시작했는데 이번이 그 2번째이다.

SSAG 시간표

MongoDB, 이렇게 쓰세요 - 한대희

온라인 데이팅 서비스인 이음에서 글로벌 데이팅 서비스로 만든 hey를 만들면서 MongDB를 적용했던 경험을 공유한 시간이었다. 내용은 발표자료에 잘 나와있으므로 굳이 따로 정리하지는 않겠다.(SSAG에서 동영상도 공유 예정인 걸로 알고 있다.)

나는 NoSQL 류에 관대한 입장을 가진 편이고 개인 프로젝트에서 MongoDB를 많이 쓰는 편인데 사실 이는 성능보다는(개인 프로젝트에서 스케일아웃 할 일이 있을 리가...) 개발 편의성 때문이다. 치밀한 계획하에 개발하지 않는 개인 프로젝트에서 MongoDB같은 스키마 없는 데이터베이스를 사용할 때의 편리함은 이루 말할 수 없다. 하지만 서비스로 나간다고 생각하면 글쎄... 쓰던 거니 고민은 하겠지만 덥석 쓰지는 않을 것 같다. 사실 이번 발표도 아주 깊은 내용이라기보다는 MongoDB는 사용 안 해봤지만 사용을 고려하는 입장에서는 미리 알면 도움될 부분이 상당히 많이 있다고 생각한다. 처음 발표한다고 하신 것 치고는 발표자료도 괜찮고 잘하신 듯...(나 처음 할 때 생각하면 덜덜덜)

이 발표의 결과에도 비슷한 얘기가 나오지만 조금 생각을 더하자면 난 기술을 좀 트랜디하게 쫓는 편이지만 새로운 기술을 사용할 때도 사람들이 너무 익숙한 기술의 결과와 수준을 비교한다고 생각하는 편이다. 오랫동안 잘 쓴 기술이 아무래도 더 잘 튜닝해서 쓰게 되어 있고 새로운 기술은 그러한 노하우가 없으므로 문서나 공유된 수준의 내용만 가지고 사용할 수밖에 없으므로 내부에 경험이 쌓이기 전까지는 아무래도 성능, 생산성 등의 저하를 경험할 수밖에 없는데 사람들은 종종 그런 단계를 한 번에 뛰어넘고 싶어하는 것 같다.(발표자분이 그렇다는 의미는 아니다.) 그리고 자주 나오듯이 NoSQL은 RDBMS를 대체하기 위해서 나온 것이 아니라 RDBMS가 커버하지 않는 부분을 커버하기 위해서 나온 것이다. 그럼에도 RDBMS의 대체재로 너무 1:1 비교개념으로 다가가면 자칫 망하기 쉽다.(DB에 대해 잘 아는 것이 아니므로 여기까지...)

발표 후 질답시간에 몇몇 질문에 대해서 청중에서 대신 답변을 하게 되면서 청중끼리 반박, 재반박이 이어지는 재미있는 토론이 있었다. 발표자 입장에서는 약간 곤혹스러운 상황일 수도 있겠지만 이렇게 자유로운 분위기(다양한 질문을 하고 그에 대해서 의견 있으면 서로 얘기하는...) 아주 좋다. 난 사실 발표 중에도 궁금한 게 있으면 손들고 묻고 그런 스터디스러운 발표를 더 좋아하는 편이다.

모바일 서비스 AWS 구축 경험 공유 - 김민태

NC Soft에서 소규모 팀으로 Chekit이라는 글로벌 서비스를 AWS에 구축한 경험을 공유한 발표로 AWS 기반 백앤드 구축에서 공유한 내용의 확장판이라고 볼 수 있다. 전에도 김민태님의 발표를 들은 적이 있는데 이번 발표도 세련된 발표자료에 능숙한 발표를 보여주셨다.(발표 중 여유로운 자세로 자연스러운 개그가 참 좋다.) 사용하는 개인 서버도 있고 AWS같은 확장성이나 유연성이 필요한 서비스를 만들어 본 적이없어서(혹은 AWS를 쓸 수 있는 환경이 아니거나) 주로 가상서버를 사용하고 있다. 그래서 AWS의 서비스들을 사용해 본적은 한 번도 없다. AWS의 인기가 워낙 좋으므로 관심은 상당히 있었지만 쓸 일이 없었던 탓에 관련 세미나도 별로 참여해보지 못했고 자세히 알지 못한다.

그런 면에서 나같이 AWS의 경험이 없는 사람에게는 아주 유용한 발표였다. AWS를 사용해 보지 않은 입장에서 서비스까지 구축하면서 고민한 부분과 삽질한 내용을 그대로 공유 받을 수 있었기 때문이다. 특히 AWS 서비스들의 가격(아무래도 가장 신경 쓰일 부분이니...)을 계산에 볼 수 있는 CloudMix의 서비스나 AWS에 구축할 때 사용할 수 있는 아키텍처 레퍼런스를 볼수 있는 페이지를 포함해서 Checkit이 어떤 아키텍처로 구성했는가 하는 내용은 나중에 AWS를 사용할 때 많이 도움이 될 것 같다.

AWS Cost Optimization: A journey to AWS cost optimization - 정유진

마지막에 미니 세션 비슷하게 AWS의 엔지니어분이 오셔서 AWS를 쓸 때 비용을 최적화해서 쓰려면 어떻게 해야 하는 가에 대해서 공유를 해주셨다. 나중에 AWS도 이제 한국에 들어와서 작년부터 세미나나 커뮤니티 등에서 이런 홍보를 많이 하는 듯한데 처음 듣는 나에겐 꽤 유용한 내용이었다. AWS를 사용할 때 가장 많이 하는 실수 중에 하나가 기존에 사내에서 사용하던 물리 서버와 같은 스펙으로 AWS를 같게 구축하는 것이다. 예시로 로드밸런서 1대, 웹서버 10대, 데이터베이스 서버 2대로 구성하면 한 달에 17,000불 정도가 나올 수 있다. 이렇게 구성한 경우 서버 대부분이 Idle 상태가 되는데 AWS의 비용은 "사용한 만큼 과금한다"는 개념이므로 이렇게 쓰는 것은 AWS를 제대로 쓰는 것이 아니다. EC2에는 "change instance type"라는 것이 있는데 이를 사용하면 5-10분 내에 원하는 대로 서버의 성능을 변경할 수 있다.

그래서 AWS를 사용할 때는 불필요하게 좋은 성능을 사용하지 않아야 한다. m3.xlarge를 m1.small로 바꾸고 db.m2.xlarge를 db.m1.small로 바꾸면 월 8,000불 정도로 줄일 수 있다. 여기에 EBS를 PIOPS에서 Standard 50GB로 바꾸고 RDS 볼륨을 1TB PIOPS에서 Standard 50GB로 바꾸면 월 700불까지로 내릴 수 있다. 보통의 서비스는 인바운드보다 아웃바운드 트래픽이 더 많은데 아마존은 아웃바운드 트래픽에 대해서만 과금을 하므로 AWS의 서비스를 적절히 이용하면 비용을 줄일 수 있다. 그리고 트래픽에 맞춰서 서버사양을 늘리는 오토 스케일링을 될 수 있으면 사용해라. 서비스 대부분은 시간별로 트래픽이 다른데 계속 좋은 사양을 유지하지 않고 트래픽 증가에 따라 자동으로 변경되게 설정하면 비용을 월 450불 정도까지 낮출 수 있다. 마지막으로 Reserved Instances를 사용하는 것이 좋다. Reserved Instances는 장기간(1년, 3년 등)의 비용을 미리 내면 할인을 해주는 과금체계인데 3개월 이상 쓰게 되면 웬만하면 Reserved Instances를 사용하는 것이 더 낮다. 서버의 최소 트래픽에 맞춘 사양 정도를 Reserved Instances로 사용하고 나머지는 오토스케일링으로 확장해서 쓰면 비용을 더 낮출 수 있다.

맺음말

오랜만에 평일날 참가한 세미나였는데 관심 주제이기도 했지만 발표도 괜찮고 사람들 호응도 좋은 즐거운 세미나였다. 더군다나 쟁쟁한 분들이 엄청나게 모여든.... 너무 인기가 좋아서 장소가 좀 협소하게 느껴진 게 아쉬웠다면 약간 아쉬웠고 평일날 저녁 8시에 시작한 세미나라 사람들과 교류를 나눌 시간이 좀 부족했지만 이건 뭐 어쩔 수 없는 부분이니..

2016년 12월 27일 화요일

[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분 한 뒤 다른 사람이 나와서 앱 등록하는 과정이나 이런거 좀 설명하면서 킨들파이어에서 앱이 어떤 식으로 동작하는지를 보여주었다. 뒷부분은 거의 집중력을 잃어 듣지도 않았지만 최적화얘기를 하기는 했는지도 모르겠고 그냥 아마존 앱스토어 광고였다.

2016년 12월 22일 목요일

[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발표자료도 그냥 화려한 애니메이션만 마구 넣었을 뿐이었다.)
  • 발표끝나고 공유는 여러 가지 방법이 있는데 웹으로 만든 발표자료가 아니라면 대표적으로 slideshareSpeaker Deck이 있다. 드랍박스나 다른 파일공유서비스로 공유할 수도 있지만 장기적으로 사람들이 볼려면 이런 서비스가 제일 좋다. 키노트로 사용한 경우에는 한글같은 폰트가 깨지는 경우가 많으므로 PDF로 내보내기를 한 뒤에 업로드를 하며 깨지지 않는다. 사실 발표자료는 이런 서비스에서 좋은 발표자료를 많이 보는 것도 꽤 많은 도움이 된다.

주의사항

  • 폰트 사이즈에 신경써야 한다. 의외로 발표자료를 보면 폰트사이즈가 작은 경우가 너무 많다. 발표장소에 따라 다르지만 큰 장소라면 뒤에서도 잘 보이는지 신경을 많이 써야 한다. 난 절대 작아서 안보인다는 말이 나오지 않게 대빵만하게 70~90 포인트의 폰트를 선호하는 편이다. 발표 준강에 잘 안보여요라고 사람들이 말해주면 좋지만 청중들은 잘 그러지 않으므로 발표자가 미리 신경써야 한다. 특히 라이브 코딩이나 콘솔로 데모하는 경우에도 폰트크기를 뒤에서도 잘 보이도록 키워주어야 한다.
  • 하단 10%정도는 사용하지 않는다. 발표하는 곳이 청중들보다 높은 곳에 있다면 좋겠지만 그렇지 않은 곳이 대부분이다. 뒤에 앉은 사람은 앞의 사람 들 때문에 발표자료의 하단부분은 잘 보이지 않으므로 하단부는 중요한 내용들을 넣지 않는 것이 좋다. 밑부분은 약간 공백을 두어도 좋다.
  • 글씨나 배경이 명도/채도가 비슷하지 않도록 주의해야 한다. 사실 요즘은 모니터들이 다 좋아서 약간만 명도/채도가 달라도 비슷해 보이지만 대부분의 발표는 빔 프로젝터를 이용해서 한다. 좋은 빔 프로젝트라면 아주 잘 나오지만 대부분은 그렇게 고급 빔 프로젝터가 아니므로 내 모니터에서는 잘 보였지만 막상 발표하러 가보니 색이 흐려서 구분이 잘 안되는 경우가 많다. 그래서 명도/채도가 많이 차이나게 배색해야 발표당일날 이런 문제를 줄일 수 있다.
  • 질문 : Q&A 시간에 질문을 받으면 질문을 다시 얘기해주는 것이 좋아보인다.(이건 나도 잘 안되는데...) 보통 질문자는 마이크가 없는 경우가 더 많기 때문에 발표자만 질문을 듣고 대답하면 사람들은 질문내용이 뭔지 모르는 경우가 많다.
마지막으로 내가 맨 처음 공개적으로 발표를 할 때 "어차피 발표끝나도 아무도 말을 안해줘서 잘 했는지 안했는지 모르니까 맘 편히해"라는 말을 들었는데 사실이다. 세미나 많이 가본 사람은 알겠지만 보통 청중이 큰 반응이 없고 끝나고 피드백을 주는 경우도 없다. 누가 후기라도 올려주면 욕이든 칭찬이든 감사할 따름이다. 발표자가 피드백을 받을 수 있는 다양한 방법을 연구해서 피드백을 받도록 하는 것도 다음 발표에 도움이 된다.
그리고 내가 세미나의 주최측의 일원이 될 경우에는 대부분 발표 리허설을 진행했었다. 발표 리허설의 경우는 커뮤니티내의 사람들이나 준비하는 사람들 위주로 진행했는데 경험상 발표준비가 어느 정도 수준이든간에(아주 부족하거나 상당한 퀄리티로 준비했거나) 무조건 리허설 전보다 수준이 올라간다. 일단 듣는 사람들이 친분이 있는 경우가 많고 리허설의 목표도 부족한 부분에 대한 의견제시이므로(모두 받아들일 필요는 없다) 꽤 양질의 피드백을 받을 수 있고 듣는 입장에서 어떻게 들리고 어떤 생각 혹은 궁금증이 생기는지 들을 수 있다. 이런 자리를 활용하면 발표 수준을 높힐 수 있고 여러 트랙이 아닌 한 트랙으로 진행하는 경우에는 다른 발표자가 어떤 내용을 설명하는지 알게 되는 것도 발표내용을 조정하는데 상당히 도움이 된다.

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

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

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

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



2016년 12월 21일 수요일

[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..


2016년 12월 14일 수요일

[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-pluginsd3-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 QuigleyUniversity of California System Campuses라는 캘리포니아 대학의 예산관련 비쥬얼라이제이션을 보여주었는데 그래프와 인터렉션을 깔끔하게 잘 만들었다. 이 인터렉션을 위해서 사용자가 어떤 값을 선택할 때 인터렉션을 보여주는 전략에 대해서 Strategic DilemmasStrategy Spaces를 소개해 줬는데 잘 모르는 분야라 흥미로웠다.

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

2016년 12월 2일 금요일

[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차로 나누어서 좀 이른 일정으로 공유해 주기를 원하기도 했고...

최근에는 이전에 만들던 발표자료보다 좀 더 퀄리티를 높이고 싶어서 여러 모로 신경을 쓴 발표자료다. 개인 프로젝트의 경험에서 어떤 부분을 전달해 주어야 듣는 사람들에게 의미가 있을지도 참 많이 고민했었는데 마지막까지 이 부분은 명확치는 않았다. 너무 억지로 메시지를 담으면 뭔가 가르치려는 것 같고 자연스러울 것 같지도 않아서 프로젝트를 진행하면서 각 단계별로 내가 고민했던 부분이나 의도했던 부분을 공유하는 쪽으로 해서 발표흐름을 잡았지만 듣는 사람한테 의미가 있을지는 마지막까지 신경이 쓰였다. 사실 스프링캠프쪽은 리뷰를 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와 라 스칼라 코딩단의 자원봉사자분들과 리뷰하는데 도움을 주신 라스칼라 코딩단 분들때 감사를 드린다.

2016년 10월 31일 월요일

[EP] 개발자를 위한 ‘共感(공감)’ 세미나 12회 발표자료 : 혼자서 프로젝트 수행하기..

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

지난 7일 교보타워에서 공감 세미나가 있었다. 오랜만에 참석하는 공감세미나이긴 하는데 이번에는 KSUG쪽 세션을 맡아서 발표자로 참석을 하게 되었다. 처음에는 첫 세션을 맡았지만 낮에 갔다와야 할 곳이 생겨서 마지막 세션으로 바꾸었지만...

이번 세션은 그냥 사석에서 얘기를 나누다가 프로젝트 할때 아이콘 폰트는 뭐 쓰고 프레임웍은 뭐 쓰고 이런 얘기를 나누다가 fupfin님이 그걸 발표해도 괜찮겠다고 해서 시작되었다.(그때는 농담인줄 알았지만...) 잉여력을 발휘해서 학습 겸 개인 프로젝트를 많이 하는 편인데 그럴때 사용할만한 도구들을 소개하는 발표였다.


혼자서 프로젝트 수행하기 from Outsider

나는 네이밍을 잘 못하는 편인데 특히 이런 발표나 글 같은 경우 내용은 채우겠는데 제목짓는 건 참 어렵다. 나름 고민해서 지은 제목이긴 하지만 개인 프로젝트를 하면서 도움이 될만한 도구들의 소개가 위주인데 제목에서는 잘 안타난것 같아서 아쉽다. 처음에 발표하기로 하고 이런 저런 유용한 도구를 소개하는 것도 괜찮겠다고 생각은 했지만 막상 발표준비를 하다보니 발표시간만큼의 분량이 잘 생각나지 않았다. 상황별로 누가 물어보면 뭐 쓰면 좋겠다 라고 대답해 줄 수 있겠지만 막상 처음부터 생각하니까 "내가 무슨 도구를 쓰더라", "이 도구는 다들 알고 있는 것 아닌가?"하는 생각이 많았다. 그래서 처음부터 기획하고 디자인하고 서비스하는 과정에서 내가 사용하거나 참고할 만한 도구를 위주로 자료를 만들었다. 이런 도구를 설명하는 발표는 해당 도구나 서비스를 아느냐 모르냐의 차이일뿐 어떤 사전지식이나 내공(?)이 필요한건 아니라서 꽤 유용하다고 생각하지만 자칫하면 다들 하는 너무 쉬운 것만 말할 수도 있어서 조심스럽기도 하다. 다행히 끝나고 몰랐던게 많았다고 해주신 분들이 계셔서 다행이었다.

추가적으로 기존에는 발표자료를 만들때 그림을 많이 넣는 편이다. 이전에는 거의 전 페이지에 이미지를 넣어서 만들었는데(이미지 찾는데 시간이 엄청 걸린다.) 최근에는 발표내용을 전달하는데 얼마나 유효한가에 대해서 좀 의문이 들었다. 발표자료 만드는 스킬을 좀 더 올리고 싶은데 적절한 상황에서 이미지를 활용하는 것은 전달에 도움이 되지만 그냥 습관적으로 이미지를 넣어서 만드는 경우도 많은 것 같아서 이번에는 이미지를 좀 자제하고(스샷이 많았지만) 텍스트를 넣으려고 했다.(발표자료 만드는건 역시 어렵;;;)

2016년 9월 6일 화요일

[EP] FRENDS meetup에서 발표한 "초급 개발자 탈출"..

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

지난 6일(토) FRENDS에서 올해는 내부 모임만 계속하다가 오랜만에 meetup을 열었다. 올해 해보기로 한 것중에 하나이기도 하고 이런 행사에 대한 경험도 쌓기 위해서 작은 규모로 진행을 했고 여기서 발표를 하나 맡게 되었다. 발표를 많이 하는 편은 아니지만 그동안은 기술세션만 발표했기 때문에 이번에는 좀 다른 얘기를 할 수 있지 않을까 해서 초심자들에게 혹 도움이 될만한 얘기를 해볼까 해서 "초급 개발자 탈출"이라는 제목을 선택했다. 준비하면서 주제선정을 잘못했나 싶을 정도로 스토리라인을 잡기 어려웠고 기술 세션이 아니다 보니 어떤 얘기를 할지 참 고민을 많이 했는데 그냥 내가 해온걸 중심으로 얘기하자는 생각으로 발표자료를 만들었고 그럭저럭 나쁘지 않았던 듯 하다.



이 발표자료는 슬라이드쉐어에도 올라가있다. 이번 meetup은 처음 기획할 때부터 프로그래밍을 많이 했고 잘하는 사람들 보다는 초심자들을 대상으로 하기로 했었다. 원래는 대학생들을 대상으로 하자는 얘기를 했었지만 대학생들과의 어떤 연결점을 가질 수 없었고 그러다보니 대학생들의 관심사를 추정하기도 어려웠기에 그냥 초심자들을 모았다. 장소는 NHN의 후원을 받았지만 큰 장소를 구할수 없어서(Toz에 의외로 큰 장소가 없더라는...) 30명까지만 신청받았다. 하지만 우리 인원수는 세지 않았기 때문에 우리는 계속 서있어야 했다. ㅠㅠ 장소가 협소하기도 하고 의도하고 있는 타게팅이 있었기 때문에 이번에는 역필터링(?)을 시도했다. 그러니까 이미 잘하는 사람은 왠만하면 받지 않으려는 의도였고 이 생각은 내가 낸 의견이었지만 막상 하고보니 그냥 아는 사람 필터링이 되어버려서 좋은 시도였는지는 애매하다. 다음번에 하게되면 고민이 좀 될듯...



아무튼 무료세미나이긴 하지만 너무 신청이 막 들어오고 당일날 안오면 주최하는 입장에서는 곤란하기 때문에 전에 KSUG에서도 한번 한적이 있었던 만원을 선입금받고 왔을 경우 돌려주는 방식을 취했다. 이는 무료세미나에서 일반적으로 발생하는 갈지 안갈지 모르지만 일단 신청해놓고 당일날 고민하는 것을 좀 막고 곰곰히 생각해보고 신청하길 바라는 의도였는데 생각외로 3일정도만에 30석이 다 찼다..(오오~~) 이렇게 신청하신 분중에 28명이나 오시는(2분은 미리 연락도 주신...) 높은 참여율에 여성개발자도 5분이나 오셨다. 이건 정말 흔치않은... 보통 여성개발자들이 가고싶어도 가면 혼자만 여자일까봐 잘 안온다는 얘기를 들었는데 5명이나 오신건 꽤 흥미로운 점이었다. 간만에 처음 시도하는 방식으로 진행한 것 치고는 큰 사건사고 없이 잘 진행된것 같다.

My Comment..
햄이 오래전에 발표한 내용들이다.. 위에 언급된 것처럼 초보 개발자 또는 개발자를 시작하려는 사람들을 대상으로 한 발표다..

하지만 내가 보기엔 나처럼 개발을 오래했거나 개발자라는 이름으로 오래 지난 사람도 참석했어도 좋았을 발표였다고 생각한다.. 비록 엄청 오래전이긴 하지만 말이지.. ㅎㅎㅎ 이유는 전체적인 내용이 개발을 어떻게 접근해야될지.. 개발을 위해서 어떻게 하는게 좋을지 등등의 개발자로써 살아가면서 취했으면 하는 행동들과 방법론 등에 대한 내용들이 많기 때문이다..

항상 발표내용처럼 할 순 없을 것이다.. 저마다 입장과 상황 차이가 있을테니 말이다.. 그렇지만 해당 내용을 보고 한 번 쯤은 고민해보고 내가 하고 있는 것들과 비교를 하면서 조금더 덧붙여볼만한 것은 덧붙여서 발전해나가는 것도 좋다고 생각한다.. 나 또한, 그렇게 해서 무엇인가를 하려고 노력하였으니 말이다.. ㅎㅎ


2016년 8월 22일 월요일

[EP] "오픈소스 제대로 활동하기" 세미나 후기..

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

몇 주전 페이스북 "OSS 개발자포럼" 그룹의 주최로 이희승님오픈소스 제대로 활동하기를 주제로 발표하신다는 걸 알고는 냅다 신청해서 지난 토요일(25일)에 갔다가 왔다. 이희승님은 Mina, Infinispan, Netty 프로젝트를 만드신 분으로 현재는 트위터에서 일하고 계시고 국내에서 오픈소스쪽 활동으로는 가장 활발하다고 할 수 있다. 이희승님은 이름 정도만 알고 있다가 지난번 Deview에서 Netty 발표를 발표도 참 잘하신다는 것을 알게 되어서 이번에는 망설일 이유가 없었다. 오픈소스에 최근 관심도 더 커지기도 했고...

오픈소스 활용 vs. 활동
처음에는 가볍게 오픈소스의 활용과 활동에 대해서 얘기하셨다. 가장 간단한 것은 오픈소스를 단순히 이용하는 것이고 내부적으로 수정해야 할 부분이 있어서 수정해서 사용(internal fork)하기도 하는데 이런 경우 점점 원 프로젝트와 달라지는 부분이 커지기 마련이라 관리가 쉽지 않다. 수정한 내용을 단순히 공개하기도 하는데(external fork) 다른 사람이 사용할 수 있으므로 좀 더 나은 방법이기는 하지만 원 프로젝트에 적용된다는 보장이 없으므로 해당 프로젝트에서 직접 활동하는 것이 더 낫다.

블로그나 강연을 통해서 오픈소스에 대한 경험을 공유할 수 있다. 상용 소프트웨어의 경우 동작하는 부분은 그대로 놔두는 경향이 있지만 오픈소스에서는 디자인등을 적극적으로 변경해 나가므로 문서에 제때 반영되지 못하는 경우가 많은데 실 사례를 많이 공유함으로써 사람들이 더 쉽게 사용할 수 있게 된다. 이는 오픈소스 프로젝트와 느슨하게 연결되어 있지만 중요한 부분이고 그 외에 버그리포팅이나 기능추가 요청, 토론참여 등이 있다.

오픈소스 활동의 목적
그럼 오픈소스 활동을 왜 해야하는것인가? 활동하기 전에 목적을 확실히 할 필요가 있다. 가장 많이 사용하는 웹서버를 만드는 것을 가정했을 때 (물론 재미난 과정이겠지만) 스펙 준수나 호환성 테스트를 다 하는 것은 무척 시간이 많이 들기 때문에 이러한 부분 오픈소스를 사용하고 핵심 역량에 집중해서 개발할 수 있다. 그리고 오픈소스에 직접 참여하면 사용하는 오픈소스에 변경해야 할 부분이 생겼을 때 직접 참여해서 적극적으로 변경할 수 있다. 그렇지 않으면 기다리거나 내부적으로만 수정하게 되서 관리가 어려워진다. 적극적으로 참여해서 오픈소스 로드맵에 직접 참여할 수 있고 설사 의견이 반영되지 않는다고 하더라도 그 토론에서 얻을 수 있는 것이 많다.

그리고 활동 자체에도 큰 의미를 둘 수 있다. 보통 오픈소스 프로젝트는 다양한 나라에서 다양한 사람들이 참여를 하게 되므로 사람의 성품이나 치적에 대한 편견없이 코드에만 집중해서 커뮤니케이션할 수 있는 능력을 기를 수 있다. 많은 사람이 온라인으로 협업하는 법을 배우게 되므로 얼굴보고 협업하는 것도 한결 쉬워진다. 사람에 대한 비난 보다는 코드가 중요하다는 것을 많이 배울 수 있다. 최근에 많아지고 있는데 오픈소스 활동을 채용절차의 일부로 활용하기도 한다. 물론 이는 좋은 코드를 작성했을 때의 이야기이지만 오픈소스 활동 자체가 좋은 코드로 발전하는 하나의 과정이라고 할 수 있다.

오픈소스 제대로 활동하기
주의할 점
자주 있는 경우는 아니지만 초기에 소위 찍히면 그 뒤에는 여러가지로 열심히 해도 잘 안되는 경우가 있으므로 처음부터 잘 해야 한다. 버그리포팅을 하는 입장에서는 하나의 이슈이지만 커미터들 입장에서는 수십, 수백개의 이슈가 올라오므로 단순 리포팅 자체는 큰 의미가 없다. 이해하기 어려운 영어나 불충분한 설명으로 버그리포팅을 하게 되면 우선순위가 낮아져서 처리되지 않으므로 최대한 자세하고 명확하게 리포팅해야 하고 서로의 시간을 소중하게 생각할 수 있어야 한다. 특히 "언제 해결되냐는 식"의 재촉은 찍히는 지름길이고 공식 채널이 아닌 비공식 채널(메일링, IRC, 이슈트래커가 아닌 개인 메일이나 전화)로 연락하면 무조건 공식채널로 연락하라고 하기 마련이다. IRC도 공식 채널이기는 하지만 기록으로 남고 누군가 다시 검색해 볼 수 있는 메일링이나 Stackoverflow를 이용하는 것도 좋은 방법이다.

버그 리포트
버그리포팅은 jira나 github 이슈등의 공식 이슈 트랙커를 사용한다. 버그 리포트를 올리기 전에 유사한 이슈가 있는지 필히 확인해야 하고 이미 존재한다면 기존 이슈에 보충할 내용만 추가하고 vote나 watch 등으로 관심을 표현하는 것이 좋다. 그리고 리포팅을 할 때는 사용 버전, OS나 VM등의 환경, 재현방법등을 자세하면서 깔끔하게 적는 것이 좋고 좀더 나아간다면 왜 이런 문제가 발생했다고 생각하는지를 찾아서 같이 올리거나 의심가는 부분의 소스코드를 알려준다면 처리되는 우선순위를 높힐 수 있다.
기능 제안
기능제안도 버그리포팅과 유사하게 이슈트래커를 사용한다. 마찬가지로 중복 등록이 되지 않도록 기존 이슈들을 검색해봐야 하고 기능을 요청하게 된 배경이나 어떤 효과가 있는지, 잠재적으로 예상되는 위험성, 구체적인 구현방법등을 함께 제안하면 좋다.

패치 보내기
이슈에 패치를 첨부하면 커미터들이 리뷰를 하게 된다. 코드가 너무 맘에 들어서 한번에 적용되는 경우는 흔치 않다. 보통은 관례를 맞춰달라거나 자세한 내용을 물어보거나 일부를 바꿔 달라고 하는 경우가 많다.(물론 때로는 칭찬도 듣는다.) 이러한 리뷰에 따라 패치를 다시 첨부하면 되고 해당 프로젝트에 개발자 가이드가 존재한다면 미리 숙지해 두는 것이 빨리 적용되는데 도움이 된다. 이렇게 리뷰하는 과정에서 포기하면 참여할 수 있는 좋은 기회를 놓치는 것이므로 끈기있게 해야 하고 커미터의 의견이라고 너무 끌려다니지만 말고 자신의 의견을 개진하는 것이 좋다.

Pull Request
Github가 사실상 오픈소스 코드 저장소의 표준이 되었기 때문에 요즘은 패치를 보내는 일은 많지 않고 대부분 Github의 Pull Request를 이용한다. DVCS의 장점을 이용해서 각 저장소의 변경사항을 자동으로 보여주고 개발자가 리뷰하면 원 저장소에 적용되는 방식으로 모두에게 편리해 졌다.

일원이 되기
프로젝트의 일원이 되는 경우는 패치를 하는 과정에서 커미터가 얘기가 잘 통한다고 느끼거나 좋은 코드를 항상 작성해서 굳이 매번 리뷰를 하지 않아도 되겠다고 느껴서 믿을 만한 수준이 되면 일원이 될 수 있다.

새로운 오픈소스 프로젝트 시작하기
새로운 오픈소스 프로젝트를 시작하기 전에 "기업과 개인의 이익을 넘어설 수 있는지" 고민해 볼 필요가 있다. 자신이 다른 사람에게 "믿을만한 개발자"라고 말할 수 있는 자격이 있는지 먼저 봐야 하고 내가 하고 싶어서 또는 회사가 원해서가 아니라 실제로 추구하는 가치가 무엇인지를 고민해 볼 필요가 있고 이는 생색내기가 아닌 진짜 오픈소스를 하고 싶다면 고민해 볼만한 일이다. 그리고 이러한 가치가 있다면 장기간 유지해야하고 회사외부로 오픈할 때도 편협하게 외부사람이라고 권한은 안주는 등의 결정에 영향을 줄 수 있고 진정으로 열린 프로젝트인지도 고민해 봐야 한다.

사례 소개 : open source @ twitter
많이 알려졌다 시피 오픈소스에 적극적인 트위터를 사례로 소개해 주셨다. 트위터는 현재 내부에서 개발한 프로젝트를 오픈소스로 공개해서 지속적으로 유지하고 대표적으로는 Bootstrap, finagle, ostrich, zipkin, twemproxy, mysql fork 등이 있다. 그리고 블로그를 통해서 기술을 공유하고 있고 내부에서 많이 사용하는 스칼라의 전파를 위해 Scala School이나 Effective Scala등의 문서도 공개하고 있다. 그 외에도 netty, apache hedwig, mesos, pig등의 오픈소스에 적극적으로 참여하고 개발자를 직접 고용해서 오픈소스개발을 하게 하고 있으며 Apache Software Foundation, Linux Foundation, Travis-CI등에 재정적인 지원을 하고 있다.

Epilogue
아주 긴 시간은 아니었지만 여러 오픈소스를 진행하면서 쌓인 실 경험에 바탕해서 얘기해 주셨기 때문에 알고 있던 내용이라고 하더라도 그 무게가 달랐고 시스템 적인것 외에 실제적인 부분은 잘 몰랐기에 느끼는 부분도 많고 오픈소스에 대한 꿈을 더 크게 품을 수 있었다.(올해 어느정도 발이라도 걸쳐보려는게 목표이긴 한데 ㅠ) Github 덕분에 오픈소스에 참여할 수 있는 기회는 무한하게 열린 상황이지만 가끔 간단한 거라도 리포팅이나 패치를 보내다가 무시당하거나 하면 맘이 상하는 경우가 많았는데 커미터의 입장에서의 이야기를 들어보면서 그런거에 일일이 맘상하면 안되겠다는 생각이 들었다.(뭐 대단한거 보낸것도 아니고...) 질문시간에도 여러 질문이 오갔는데 굳이 여기에 정리하진 않겠다. (궁금한 사람은 Insane님이 정리한 오픈소스 제대로 활동하기 멘토링 후기 참고)

마지막으로 원래도 그런 생각을 좀 하고 있어서 인지는 몰라도 이번 세미나를 들으면서도 사람들이 뭔가 과정을 뛰어넘어서 결과만 바라는 것 같은 느낌이 들었다. 직접적으로 말하면 오픈소스를 개발하고 사람들과 의견을 나누고 실력을 쌓는 과정을 생략하고 유명프로젝트의 커미터를 좀 더 쉽게 될 수 있는 방법이 없나? 하는 생각을 하고 있는 듯하게 느껴졌다.(편견일지도...) 내가 생각하기에 오픈소스에서 가장 중요한 것은 결국 실력이고 사실 실력만 있으면 그외에것은 다 무시할만한 수준이라고 생각한다. 이희승님이 나누어 주신 얘기도 실력은 제외하고 초기에 모를 수 있는 팁을 알려 주신 것이지 저런걸 다 지킨다고 커미터가 되는게 아니라 일단 해당 프로젝트를 직접 개발하고 멋진 코드를 작성할 수 있는 능력이 되야 하는데 그런 과정은 쉽게 넘어가고 싶은게 아닐까 하는 느낌이 들었다.(물론 나도 그런 능력이 아직 안되는데 잘하시는 분들을 얘기한건 아니다.)

이희승님이 얘기하셨듯이 오픈소스에 참여하는 과정은 아주 다양하다. 내가 아직 코드를 막 짤 수준이 아니라면 버그 리포팅을 할 수도 있고 질문에 답변을 열심히 달아줄 수도 있고 가이드 같은걸 만들어서 제공할 수도 있다. 몰론 패치를 보낼 수 있다면 더욱 좋겠지만... netty에 올라오는 이슈나 패치에 한국사람이 거의 없다는 이희승님의 얘기에 약간의 안타까움을 느끼면서 어떻게 커미터가 되느냐 마느냐 보다는 그냥 자신이 할 수 있는 부분에서 오픈소스 활동을 다양하게 하는 사람들이 많아졌으면 좋겠다. 그런 가운데서 커미터들도 더 나오고 그러겠지. 내 생각에는 오픈소스는 그게 더 좋은 방법이고 즐거운 방법이기에 그렇게 개발하면서 명예가 따라오는 것이지 명예를 얻기 위해서 오픈소스를 하는건 아니라고 생각한다. 국내 회사들의 오픈소스들을 개발자들이 거의 신경도 안쓰는 이유도 질답중에 이희승님이 비슷한 얘기하셨듯이 오픈만 했다고 다 오픈소스가 아니기 때문이 아닐지...



2016년 2월 19일 금요일

[Info]Tags categorized posts and contents patterns..


  • [AJAX] Ajax Code Examples..
  • [Book] About the book..
  • [CSS] CSS Code Examples..
  • [DB] Sql Code Examples..
  • [DEV] All development story..
  • [EP] Epilogue..
  • [HTML] Html Code Examples..
  • [JAVA] Java Code Examples..
  • [jQuery] jQuery Code Examples..
  • [JS] JavaScript Code Examples..
  • [JSP] Jsp Code Examples..
  • [Talk] Free Talk..
  • [Tool] About tools..
  • [.NET] .Net Code Examples..
  • [NEWS] IT News..
  • [Hobby] All My hobbies..
  • [Linux] Linux Instruction word..
  • [UFC] Ultimate Fighting Championship News..

  • 태그 작성시 글의 성격에 따른 카테고리 기본적으로 추가..
  • [Book] 내용에 대한 내 생각은 [블라블라..] 로 문장 뒤에 작성..
  • 내용 중 취소를 해야될 내용은 취소선 표시 후 [취소이유..] 로 문장 뒤에 취소 이유 작성..
  • 내용에 추가 작성시 맨 하단에 2016.01.01 수정 & 추가.. [굵게/먼저한 순서대로 작성..]
  • 한 해 마지막 및 시작은 매년 1월1일에 "Started in 2017 & Terminated in 2016" 의 제목으로 작성..