mydeute's RSS List

브룩스 안장

Wed, 16 May 2012 18:31:39 +0900

후지스트라토스R커스텀이거의끝나간다.안장교체.

강의 자료 업데이트- 오픈 API 및 빅데이터 등

Channy Yun — Mon, 14 May 2012 12:25:01 +0900

최근에 외부 강의를 통해 많은 분들을 만나는 시간을 늘이고 있습니다. 최근에는 제가 회사에서 하는 일인 오픈 API와 연구에 집중하고 있는 Hadoop과 빅데이터 그리고 개인적인 활동인 Mozilla와 모바일 웹 플랫폼에 대한 내용을 공유하고 있답니다.

제가 해왔던 기술 강연 목록은 블로그에 강연자료에 모아두었습니다. 관심 있는 분들은 참고하시면 좋을 듯요.

오픈 API: 웹 플랫폼 생태계를 만드는 기술

2012년 5월 KAIST SW 대학원에서 학생 및 교수, 기업 재직자 대상으로 웹 2.0과 플랫폼의 변화 그리고 오픈 API를 활용한 웹 플랫폼 사례에 대한 주제 강의입니다.

김진형 교수님의 배려로 당일 강의 사진을 찍어서 바로 상패처럼 만들어 주시더군요. 몇 해동안 콜로키움을 진행하신 노하우이신듯 합니다. 매우 감명 받았다는…

스타트업을 위한 성공적인 오픈 API 만들기

2012년 3월 프라이머 엔턴쉽 창업자를 대상으로 웹 2.0과 플랫폼의 변화 그리고 오픈 API를 활용한 성공 플랫폼 활용이라는 주제 강의입니다

Daum의 내부 빅데이터 활용 사례

2012년 4월 디지털타임즈 DT 인사이트에서 Daum 내부 Hadoop 기반 Bigdata 분석 사례를 모아서 발표한 자료입니다.

Mozilla와 모바일웹의 미래

2011년 12월 개최한 조선비즈포럼 차세대 웹 비지니스를 위한 HTML5 전략이라는 행사에서 발표한 동영상입니다.

발표 자료 주제별로 보기

홈 네트워크 구성 계획…

정태영 — Sun, 13 May 2012 16:38:37 +0900

iPad2를 구매하면서 (좀 된 이야기지만) 베어본 PC를 하나 조립해서 AirVideo/AirComix 서버를 구성했다.

처음 고려했던 베어본은 Zotac Zbox이었지만, HDD를 2.5인치 밖에 지원하지 않아서 다른 제품을 찾아 헤메이다 결국 Shuttl SH61R4에 I3 processor로 낙찰…

AirVideo를 이용하려면 실시간 transcoding이 필요하기에 셀러론을 쓰기엔 조금 부담이 됐고, 하루 종일 켜놔야 하기에 I5로 가기에도 약간은 부담이 되서 I3를 선택했는데, 결과적으로 꽤 만족스러운 상황이다.

뭐 어쨌든 AirVideo 서버를 구성하고 나서 컨텐츠를 모으다보니 어느덧 2테라 하드가 가득 차버렸다. OTL … 이런 상황이 되니 하드를 하나 더 사서 붙일까 아님 그냥 NAS를 하나 구입할까 고민이 되기 시작했다. (고민 중인 NAS는 Promise SmartStor NS4600)

게다가 영상 컨텐츠를 TV로 출력하기 위해 Server <-wifi-> iPad: airvideo <-hdmi-> TV 식으로 연결해서 사용 중이었는데, 이런 식으로 사용하려니 리모콘으로 조작할 수가 없어서 조금 불편을 느끼는 중에 apple TV를 구입한 후 airplay를 활용해볼까 하는 생각도 들기 시작했다. (+windows media server?)

사실 apple TV는 자막 등을 지원하지 않는 것으로 알고 있어서 크게 매력을 못느끼고 있었는데, air video의 live conversion나 airplay를 이용하면 자막을 server 측에서 처리하기 때문에 문제가 되지 않을 것 같고, 윈도우에서 사용하기 위한 3rd party airplay plug-in for windows 등도 잘 동작한다는 것 같아서 갑자기 급 호감이 가기 시작했다. (참고로 맥용은 사제 air video client가 있음)

결국 이래저래 고민하다가 세워본 네트워크 구성 계획 -_-;;

우선 활용 계획은 아래 정도?

홈서버는 torrent/air video server/air comix server/dropbox sync 용…
음악 파일들은 NAS에 넣어놓고, iTunes home sharing service로…
동영상 파일들은 NAS에 넣어놓고, SMB/CIFS로…
미디어 컨텐츠 TV 출력은 airplay를 이용해서 wifi로…
미디어 컨텐츠 <-> iPad/iPhone은 AirVideo/AirComix로…

이 계획대로 하려면 NAS랑 Apple TV만 구입하면 되는데 (그 외엔 다 있단 이야기 ㅎㅎ) 하드 가격이 무시무시하다. 흑;;

이제 슬슬 집에서도 독립하고 가정도 꾸리고 해야할 거 같은데, 그 때 맞춰서 욜케 업그레이드 해버릴테다 ㅎㅎ

아뵤!

8/19/2010 -- iPad 사용기… (5)
11/18/2009 -- iPhone에서 me2day로 MMS 발송시 me2photo가 등록되질 않는 문제… (5)
10/31/2009 -- iPhone 사용기… (7)
8/24/2009 -- iPhone 기다려야 하나 말아야 하나… (6)
3/21/2008 -- 내 방 파노라마 사진… (2)

html5shiv를 그냥 googlecode에서 불러올 때의 문제점

miname — Sat, 12 May 2012 13:48:11 +0900

IE6,7,8에게 새 HTML5 elements를 인식시켜주는 html5shiv를 문서에 추가하는 방법으로 보통 head에서 다음과 같이 불러온다.

<!--[if lt IE 9]>
<script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

문젠 그냥 이렇게 html5shiv를 googlecode에서 불러오면 성능상 별로 안 좋다는 얘기.
이렇게 추가된 script는 HTTP compression 되지도 않았거니와 CDN을 사용하면 당연히 얻겠거니 하는 cache 적용도 되어있지 않다. (현재 겨우 180초뿐이다.)

더군다나, 현재 공식 배포 채널로 사용되긴 하지만, 버그도 잡고 성능이 향상된 최신 버전으로의 적용도 더뎌서 github에서 활발히 개발되고 있는 html5shiv의 최신 버전(현재 Tag 3.5)을 내려받아 compress(minified)한 후 직접 호스팅하는 편이 여러모로 더 이롭다는 얘기.

참고로, Modernizr를 쓴다면 이미 core에 포함되어 있기 때문에 따로 추가할 필요는 없으며, 최신 버전도 곧 적용될 예정이란다. 끝으로 "절대 다른 사람의 source code repository에 있는 리소스에 직접 링크를 걸지는 마라"는 경고로 말을 맺고 있음.

꼬리표:

tabindex=”1″? tabindex=”0″? tabindex=”-1″?

정찬명 — Thu, 10 May 2012 23:59:53 +0900

요 며칠 사이 tabindex 속성이 저를 좀 당황스럽게 했습니다. 일반적으로 tabindex 속성은 키보드 접근성을 훼손할 우려가 있기 때문에 평소에 거들떠 보지도 않던 속성인데요. 해외 오픈소스 위지윅 에디터를 벤치마킹 하다가 tabindex=”-1″ 이라는 코드를 발견한 겁니다. 제가 알기로 소시적에 이런 코드는 표준이 아니었거든요.

HTML4 명세는 tabindex를 다음과 같이 설명합니다. 이 설명은 XHTML 문서에도 동일하게 적용됩니다.

이 속성은 문서의 탭 순서 안에서 현재 요소의 순번을 결정한다. 값은 0부터 32767 사이의 숫자여야 한다. 브라우저는 값 앞에 0이 붙어있으면 무시해야 한다.
탭 순서는 사용자가 키보드를 통해 탐색할 때 어떤 요소가 초점을 받는 순서가 되는지를 결정한다.
초점을 받을 요소는 브라우저에서 다음과 같은 규칙에 따라 탐색되어야 한다.

요소가 tabindex 속성을 지원하고 양의 값이 할당되어 있으면 먼저 탐색되어야 한다. 탐색은 tabindex 값의 가장 작은 수에서 시작하여 가장 큰 값으로 향한다. 값은 연속되는 일련의 숫자가 아니어도 상관이 없고 어떤 수로 시작해도 무방하다. 요소에 동일한 tabindex 값이 지정되어 있다면 코드 안에서 먼저 등장하는 순서대로 탐색되어야 한다.
tabindex 속성 지원 여부에 관계 없이 “0″의 값이 할당된 요소는 그 다음으로 탐색된다. 이 요소들은 코드 안에서 등장하는 순서대로 탐색된다.
disabled 속성이 사용된 요소는 탭 순서에 관여하지 않는다.

a, area, button, input, object, select, textarea 요소가 tabindex 속성을 지원하는 요소이다.

어쨌거나 표준에 따르면 tabindex 속성에는 음수 값을 사용할 수 없습니다. 그러나 현존하는 브라우저들은 tabindex=”-1″ 속성이 부여된 요소에 대해 키보드가 접근하지 않는 방식으로 구현을 해놨더라구요. 결국 이 방식이 사실상 표준이거나 또는 공식 표준이 아닐까 하는 생각이 들어 HTML5 명세를 찾아 봤습니다.

HTML5 명세는 tabindex 속성의 음수 값을 다음과 같이 설명합니다.

tabindex 값이 음의 정수라면 요소에 초점이 도달하지 않도록 해야 한다.

결국 tabindex 속성에서 음수 값을 사용하여 초점을 받을 수 없도록 하는 스펙을 추가한 것입니다. 그리고 현존하는 웹 브라우저들은 문서의 DTD에 관계 없이 이런 새로운 스펙을 낡은 문서에서도 사용할 수 있도록 구현해 둔 것입니다.

지구인들이 가장 많이 사용하고 있는 위지윅 에디터 TinyMCE와 CKEditor는 이런 코드를 도구모음 버튼에 적용하여 키보드 사용자들이 도구모음 블럭을 아예 건너 뛰도록 해 놨더라구요. 이런 구현방식에 대해 어떤 분들은 키보드 사용자를 고려하지 않았다고 주장할 수 있는데요. 제가 보기에는 이 친구들 센스있게 잘 처리한 것으로 봅니다. 키보드만으로 위지윅 에디터를 사용해 본 분들은 이런 처리를 이해할 수 있습니다.

네이버 스마트에디터와 다음 에디터는 도구모음 블럭에 키보드가 접근할 수 있도록 처리해 놨지만 실제로는 키보드만으로는 절대로 사용할 수가 없습니다. 일단 본문 영역에 초점이 들어가면 빠져나올 방법이 없기 때문에 문제가 시작됩니다. 편집 영역에 초점이 들어가면 Tab 키를 눌러서 빠져 나와야 하는데 Tab 키에 들여쓰기 기능을 맵핑해 놓았기 때문에 편집 영역에서 빠져나올 수 없습니다. 결국 키보드만 사용하는 시각 장애인 또는 상지 장애인(팔이 없거나 불편한)은 글쓰기 과업을 수행할 수 없었습니다.

tabindex=”1″

문서 안에서 가장 먼저 초점을 받을 수 있습니다. 그러나 자연스러운 마크업 순서를 거스르기 때문에 주의해서 사용해야 합니다. 검색엔진 사이트에서 검색창에 사용하면 적합하지만(이 대신 autofocus=”autofocus” 속성이 더 적절할 듯 해요) 그 외 적합한 경우는 잘 떠오르지 않는군요.

tabindex=”0″

키보드 초점을 받을 수 없는 div, span과 같은 요소도 초점을 받을 수 있도록 만들어 줍니다. 초점을 받되 초점을 받는 순서는 자연스러운 마크업 순서를 따릅니다.

tabindex=”-1″

키보드 초점을 받을 수 있는 요소도 초점을 받을 수 없도록 만들어 줍니다. 초점을 받을 수 없기 때문에 “-1″ 이외의 다른 음의 정수 값은 사실상 의미가 없습니다.

input type=”search” in Webkit Browser.

정찬명 — Thu, 10 May 2012 22:27:27 +0900

SNS를 사용하다 보니 왠만한 글은 짧게 압축해서 간단하게 쓰는 버릇이 생겼습니다. 대신 블로깅은 뒷전이 됐구요. 오늘은 놀고 있는 블로그에 미안한 생각이 들어서 앞으로 가급적 짧은 내용이라도 블로그에 적어야겠다는 생각을 했습니다.

웹킷 엔진을 사용하는 크롬과 사파리 브라우저는 <input type=”search” /> 요소를 다른 브라우저와 다르게 표시하는 특징(또는 버그)이 있습니다. search 타입은 HTML5 문서에서 새로 등장한 속성입니다.

보통의 경우 input 요소에 적용되어 있는 브라우저의 기본 CSS는 웹 제작자의 CSS 코드를 이용하여 덮어 쓸 수 있는데요. 크롬과 사파리 브라우저는 유독 <input type=”search” /> 요소에 border 속성을 덮어쓰지 않도록 처리를 해 놨습니다. 원인을 찾다가 보니 크롬 브라우저에서 다음과 같은 코드가 UA(User Agent) 스타일시트 안에 포함되어 있더라구요.

input[type="search"] {
-webkit-appearance:searchfield;
box-sizing:border-box;
}

다른 타입의 input은 이렇지 않은데요. 유난히 search 타입만 이렇습니다.

-webkit-appearance:searchfield; 라는 코드는 웹 제작자가 검색 input에 대한 border 속성을 덮어 쓸 수 없도록 만듭니다.
box-sizing:border-box; 속성은 다른 일반적인 박스와 다르게 패딩과 보더를 너비값에 포함시켜 버리는 방식으로 면적(너비와 높이)을 계산합니다.

결국 웹 제작자는 검색 인풋을 의도한 대로 디자인 하기 어렵고 다른 브라우저와 다른 면적 계산 방식 때문에 당황하게 됩니다. 다른 input 요소와 동일한 방법으로 검색 input에 border 속성을 제공하고 일반적인 면적 계산 방식을 가질 수 있도록 하려면 웹 제작자는 다음과 같은 코드를 사용해서 UA 스타일을 덮어쓰기 할 수 있습니다.

input[type="search"] {
-webkit-appearance:textfield;
box-sizing:content-box;
}

끝입니다. 웹킷 개발자는 어떤 의도로 이렇게 처리를 해놓은 것일까요?

후지 스트라토스R 검정 바테잎 교체

Thu, 10 May 2012 09:52:56 +0900

후지스트라토스R을변신시키는중.어젯밤에는바테잎을치넬리의검정으로바꿨다.처음감아봤는데생각보다힘써야하더라.특히브레이크부분에서신경이많이쓰임.이제휀다랑안장만바꾸면완성!

랙타임 리어 & 프런트랙

Thu, 10 May 2012 09:50:52 +0900

후지스트라토스를투어링으로꾸미는중인데.우선랙을얼마전달았다.racktime이라는회사제품.자전거랙으로유명한투부스자매회사라는데투부스의스텐레스로하고싶었으나너무비싸서대안으로선택.실버색상이라고하지만연한회색이다.크로몰리의반짝이는실버가갖고싶은데...

왜 개발자는 야근을 하는가?

Channy Yun — Wed, 02 May 2012 08:30:00 +0900

소프트웨어 개발자와 야근이라는 주제는 끊임없는 담론이다. 최근에 국내 대형 포털 기업의 CSO께서 야근이 사라진 칼퇴근 문화에 대해 사내 강의에서 언급한 것이 기사화 되어서 큰 역풍을 맞기도 했다.

나도 과거 회사에서 개발을 할때 야근을 많이 했고, 대학생 시절에는 인터넷과 웹 프로그래밍에 열중 하다가 삼일 밤낮을 꼬박 책상에 앉아 있을 때도 있었다. 그만큼 SW 개발자의 야근은 그냥 업무의 일환 처럼 당연한 것이 되었다.

물론 그에 따른 명암도 있다. 어떤 이는 벤처업계에서 신데렐라로 떠 오르기도 했고, 밤에 혼자 만든 게임이 앱스토에서 대박을 치기도 한다. SI업계에서 야근을 하다 폐를 잘라낸 개발자도 있고, 어떤 사람은 이혼을 당하기도 했다고 한다. 우리가 SW 개발자 야근을 문제로만 바라보기도 어렵고 그렇지 않다고 열정이 식었다고 보기도 어렵다.

야근은 필요악인가? 우리가 업무 시간을 늘이지 않고도 이를 해결할 방법은 없나? 한번 생각해 봤다.

우선 SW 개발자의 업(業)의 특징을 이해해야 한다. 사람이 컴퓨터가 알아먹는 방법으로 일의 순서를 만들어 주아야 한다. 이것을 전산적 사고(Comutational Thinking)이라고 하는데 프로그래밍을 하는 동안은 컴퓨터 처럼 생각하는 '사고 이입'이 필요하다. 그리고 테스트라는 반복 작업이 많은 엄청난 지식 노동 과정이 있다.

집중할 수 있는 업무 환경

프로그래밍에 몰두했다가 뭔가 외부의 요인(메일, 전화, 메신저, 회의 등등)에 의해 그 흐름이 깨어지면 다시 돌아가기에 더 많은 시간이 필요하다. 과거에 한밤중에 코딩을 많이 했던 것도 일과 시간 중에 너무 많은 프로그래밍의 방해요소가 있었기 때문이었다. 옆에 누가 와서 이야기를 하거나 이쁜 여직원이 지나가도 방해가 된다.

밤에는 조용하고 일을 프로그래밍을 더 효율적으로 해내기 매우 좋은 환경이다. (물론 기획서나 보고서를 쓴다던지 회계 마감, 디자인을하는 다른 직군도 마찬가지겠지만 유독 개발자가 야근이 많은 것은 그 영향이 더 크기 때문이다.)

마이크로소프트 같은 전통 SW기업에는 개발자는 1~2인실의 별도 방을 나눠 준다. 야후나 구글 같은 회사의 경우, 2~3인 정도의 파티션이 매우 높은 자리를 배정한다. 예전에 회사를 옮기고, 자리 배치를 하다 보면 유독 개발자들만 안쪽 구석 자리를 원하는 경우가 많다. 모니터를 막고 헤드셋을 쓰고 일하는 것이 그들이 대인 기피증이 있어서 그런건 아니다.

우리 나라는 유독 뻥뚫린 사무 공간에 100명씩 한꺼번에 배치해 놓고 업무를 시키기를 좋아한다. 회사가 크면 클 수록 그런 유혹에 빠지기 더 쉽다. 이런 공간에서 개발자들이 집중력을 발휘하기는 매우 어렵다. 개발자의 공간 배치는 그 만큼 중요하고 야근이 아니어도 평상 업무 시간에 프로그래밍 업무에 집중할 수 있는 환경을 만들어 주어야 한다.

잉여는 비용이 아니다
또 다른 관점은 바로 개발자와 잉여력이다. IT 기술은 끊임없이 변화해 왔고 "늘 배워야한다"라는 점이 SW 개발이라는 직업의 장점이자 단점이다. 그래서 가끔 주니어 팀장에게 늘 팀에 20% 정도의 버퍼를 두라고 충고한다. 즉, 팀원 중 10명 중 2명은 놀고 있어야 한다는 것이다. 여기서 논다는 것은 주어진 당장의 업무 보다 좀 더 새로운 기술을 테스트 해보고 실험해 보는 일을 하는 것이다.

프로젝트 투입을 해야 하는데 한두명을 놀린다는 것은 매우 비효율적이고 비용으로 보는 경향이 크다. 회사가 좀 크면 더더욱 그렇게 노는 꼴을 못본다. 특히, 어떤 신기술이 나왔는데 여러 팀에서 해 보고 있으면 비효율적이라고 생각하고 콘트롤 타워 부터 만들려고 한다.

개발자에게 업무로서 배우는 시간을 주고 이를 자신의 업무에 적용하는 노력을 비용이라고 부르면 안된다. 그것이 더 높은 생산성으로 나올 가능성이 크기 때문이다. 이것이 야근이 아니어도 생산력도 올리고 자발적으로 좀 더 효율높은 결과물을 만드는 동기가 된다.

가슴 진한 보상이 필요하다
어느 회사 어느 직군이든지 보상은 매우 중요한 동기 유발 요소이다. 어느 대기업 처럼 일은 고되지만 월급과 보너스를 많이 주니 회사를 탈출할 수 없도록 말이다. 아니면, 연말 시상에서 외제차를 준다던가 벤처기업에서 엄청난 스톡을 안길 수도 있을 것이다.

돈으로 하는 보상도 좋지만 SW 개발자에게는 '가슴 진한 보상'을 해 보면 어떨까? 자기가 맘대로 원하는 개발 환경을 꾸밀 수 있도록 구매의 권한을 준다던지(예를 들어, 다음의 개발자 마일리지) 외부에서 자신의 기술을 공유하고 발표할 기회를 준다던지 새로운 기술을 도입하는 프로젝트에 발탁하는 기회를 주는 것이다.

구글에는 개발자들의 20% 프로젝트 중 제일 좋은 것을 선발해 백만불을 주는 제도가 있었다고 하고 페이스북은 해커톤을 통해 개발자의 아이디어를 바로 서비스에 접목할 수 있는 기회를 준다고 한다.

때로는 돈보다 명예 보다 이러한 자아 성취를 유도해 주는 보상책이 더 큰 결실을 맺기도 한다. 눈에 보이는 사람과 그 업무 시간을 조절하는 것 배우 쉬운 일이다. 하지만, 그것이 좋은 결과를 못 얻는다.

기업 문화라는 것은 계속 바뀌고 성장하지만 밑바탕에는 바로 업에 대한 성찰과 원칙이 필요하기 때문이다. 예전에 했던 경험만 비추어서 강제하려는 순간 그게 바로 역효과로 나타나는 일이 부지기수다. 소프트웨어 개발자를 다루는 문화도 그렇다. 무턱대고 야근이나 근로를 강요하기 보다는 동기 유발에 의한 자발적 참여를 이끌어 내는 일관성 있는 문화가 더 절실하다.

p.s. 사실 포털 뿐 아니라 SI 업체와 그 프로젝트를 하는 경우, 대부분 쫓기듯한 일정과 과도한 업무량에 의해 야근하는 분들이 있습니다. 이 글은 과연 그렇게 만들어진 생산품이 정말 그 값어치를 하는지 한번 다시 생각해 보아야 한다는 취지의 글입니다.

더 읽어 볼 글

나에게 던지는 스무가지 질문

Channy Yun — Wed, 02 May 2012 08:00:36 +0900

5월이 되었다. 올해들어 블로그에 4개월 동안 글을 두 개 밖에 쓰지 않았다. 2009년 박사 과정 가면서 글 수 가 줄어들기 시작해서 급기야 복직을 한 작년에 50여개 밖에 안 썼을 정도다. 물론 소셜웹 서비스의 영향이 없진 않겠으나 1년 동안 일에 다시 복귀하고 나서는 스스로 채우고 뱉아낼 여유가 없었다.

이제 이야기를 풀어나갈 때가 된거 같다. 얼마전 TechIt이라는 IT 다크호스 블로그에 올라온 트위터 창업자 잭 도시에게 던지는 사적인 질문 스무가지라는 글을 읽었는데, 내가 잭 도시 만큼 유명한 사람은 아니지만 새로 시작하는 마음으로 한번 해볼까 한다.

Q: 어렸을때 가장 좋아했던 TV 프로그램은?
웬만한 공상 과학 외화는 다 좋아했는데, 특별히 V라는 SF 외화를 좋아했다. 전체 줄거리를 공책에 옮겨서 적을 만큼…

Q: 사람에게서 좋아하는 자질은?
붙임성이다. 나에게 부족한 부분이기도 한데 계속 연락하고, 배우고 의견을 구하려는 사람을 당할 재간은 없다.

Q: 싫어하는 자질은?
워크홀릭과 과도한 자심감? 아예 내 인생에서 제켜 놓는다.

Q: 하지 못한다면 후회할 한가지는?
아프리카 한번 살아보기. 아주 오래된 생각인데, 와이프 때문에 오래 살기는 힘들 것 같다.

Q: 요즘 세상에서 가장 중요한 이슈는?
글쎄 많이 생각해 본적은 없는데 전 세계적으로도 ‘정치의 부재’ 아닐까?

Q: 현재 직업이 아니라면 무슨일을 하고 있을까?
아마 목사?

Q: 지금까지 이룬 최대 성과는?
행복한 가정을 꾸린 것

Q: 아이폰, 안드로이드 or 블랙베리?
이 세개가 나오기 6년 전인 2000년 부터 PDA폰을 썼다. 아이폰 거쳐 안드로이드 쓰는 중…

Q: 역사적인 인물이나 소설속의 인물을 만난다면 누구를 보고 싶나?
마틴 루터 킹과 햄릿?

Q: 일어나 먼저 확인하는 사이트나 앱은?
지메일과 트윗덱

Q: 변치 않는 마지막 한가지가 있다면?
-보이지 않는 것에 대한 믿음

Q: 첫 번째 컴퓨터는?
1985년 금성 FC-100

Q: 인생 최대 실수는?
가끔하는 우유부단한 결정들.

Q: 애완동물 키우는가?
No

Q: 운송 수단중 가장 종아하는건?
요즘 들어 비행기. 대략 400회 가량 탔다.

Q: 가장 최근에 읽는 책은?
유감스럽게도 책을 안본다.

Q: 가장 좋아하는 금지된 장난은?
영화나 미드 다운로드

Q: 뭐타고 다니나?
버스나 택시

Q: 성장하면서 가장 영향을 받은 사람은?
아버지. (라기 보다는 그 분이 사 놓으신 백과 사전. 지식의 넓이를 깨닫게 되었다.)

Q: 이상적인 하루를 설명해달라.
와이프 품에서 일어나서 회사 셔틀로 출근한 후, 회의나 방해 없이 FYI나 RFC 같은 메일과 커밋 로그 각각 서너개 날리고 퇴근하고 블로그 글하나 쓰고 와이프 품에 들어가 잠드는 것.