GhostOnNetwork

새 블로그 링크

Kenial — Tue, 3 Sep 2019 06:48:25 +0900

티스토리 블로그가 워낙 낡은데다 (?) Static Site Generator를 한 번 써보고 싶다는 생각이 든 김에 블로그를 옮겼습니다:

https://blog.kenial.net

여러 툴을 찾아봤지만 node 기반이 제일 만만한 것 같아서 Gatsby (https://www.gatsbyjs.org)를 사용하고 있고요. 로컬 시스템에 툴을 설치해야 블로그에 글을 쓸 수 있는 환경이라니 재미있는 경험이네요. 포스트의 markdown 포맷 문서는 Dropbox Paper를 통해서 만들고요.

이 블로그를 지금까지 들여다보고 계신 분이 얼마나 계실지는 모르겠습니다만, 여튼 뭐 그렇습니다.

최근 근황

Kenial — Mon, 29 Jun 2015 23:31:29 +0900

안녕하세요. 죽다 살아난 케냘입니다.

근 3주를 병원에 입원해 있었고, 구급차를 두 번 불렀으며, 내가 응급실과 집중치료실에서 치료받는 동안 나와 함께 있던 공간에서 세 명이 죽어갔다. 평소에 딱히 스스로를 효자라고 생각해 본 적은 없는데, 이번 기회에 까딱했으면 정말 어이없게 부모님께 큰 불효를 저지를 뻔 했다. 병상에 누워 있으면서 여러 생각이 들었다. 사람이 평소에 건강한 편이었어도 몇 가지 조건이 겹치면 간단하게 사망에 이를 수 있구나, 아 신해철이 이렇게 죽었구나, 등등.

병명은 개인정보이니 여기에 적기엔 좀 그렇고 (사실 진단이 아직 확정된 것도 아니다) 증상은 출혈 그 자체. 출혈이 너무 심해 중간중간 계속 수혈을 받아야 했고, 심지어는 급속 수혈을 해야 해서 목 혈관에 주사바늘을 고정하는 간단한 시술을 받아야 할 정도였다. 기억하기로 총 전혈 일곱 팩, 혈장 한 팩, 혈청 알부민 한 병을 맞아야 했다. 그 와중에 맞은 항생제나 진통제, 쇼크 방지용 수액은 말할 것도 없고.

병원은 감옥이었다. 병이라는 이름의, 각자의 고통은 원죄인가 싶었다. 끔찍했다.

내일이면 집에 돌아간다. 이게 다 무슨 일이었던가 싶지만, 해야 할 일은 쌓여있으니 정신챙겨야지.

미국에서 가져온 폰으로 한국에서 선불 요금제를 사용할 때의 팁

Kenial — Mon, 29 Jun 2015 22:06:28 +0900

이번에 한국에 입국해서 선불폰 가입하느라 한 번 더 삽질을 하고 나니, 미리 정리를 해 두고 나중에 참고해야겠다는 생각이 들어 끄적여 본다 (...)

- USIM 칩을 사용하는 종류의 미국 폰은 대부분 한국에서도 사용할 수 있다. 그냥 간단히, AT&T와 T-Mobile (그리고 이 두 통신사의 회선을 빌려쓰는 여러 MVNO 통신사의 폰들도) 에서 공급되는 폰은 한국에서도 쓸 수 있다고 보면 된다.

- 하지만 대부분의 폰은 unlock이 되어있지 않으므로 (심지어 No contract 폰이라 하더라도 마찬가지) 각 통신사의 carrier unlock 방법을 검색해서 unlock 후에 한국에 폰을 가져가도록 하자.

- 한국에서 제공하는 여러 선불폰이 있긴 하지만, KT가 그나마 가입하기 수월하다. (KT는 올레 대리점에서 가입 가능한데, SKT는 센터로 가야한다는 것 같기도 하고... 횡설수설한다. 그냥 KT 써라) 예전에 에버그린이라는 KT계열 MVNO 선불폰 서비스가 좋다는 얘기는 있었는데, 인천공항에서 굳이 가입을 해야할 필요가 없어서 패스.

- 요금제는 'KT 선불요금제' 같은 키워드로 검색해볼 수 있다. 비용은 http://smartblog.olleh.com/1437를 참고. 케냘의 경우에는 USIM 칩 8,800원 (이 칩은 나중에 리셋해서 재사용 가능) + Simple 충전 5,000원 (카드결제시 1만원 단위로만 가능) + Simple 충전 데이터 4G 38,500원 = 52,300원이 들었다. 외부에서 데이터를 쓸 일이 많아 이렇게 한 것이니, 일반적인 용도라면 데이터 분량을 더 줄여도 될 것이다.

- 위에서 예로 든 두 요금제는 30일만 유효하다. 통화용 요금제는 1만원의 경우 60일, 3만원의 경우 180일 뭐 이런 식이지만, 데이터 요금제의 경우 4G를 30일 내에 못 쓰면 남은 용량이 그냥 날아가 버린다 (...) 그리고 다시 결제해서 충전해야 한다 (...)

- 그리고 이렇게 데이터용 선불 요금을 결제하면 Olleh Wifi 서비스 (구 Nespot)를 사용할 수 있다. (용량은 상관없다. 5000원짜리 100MB를 결제해도 Olleh Wifi는 제공된다) 이 Olleh Wifi 서비스에는 다른 무선 네트워크 장비(아이패드나 노트북, 뭐든간에)의 MAC 주소를 등록할 수 있다. 활동 반경이 수도권이라면 Olleh Wifi가 깔려있는 곳이 꽤 되므로, Olleh Wifi를 사용하면서 테더링으로 소모될 데이터를 절약할 수 있다. KT 고객 센터로 전화해서 Olleh Wifi 서비스에 자신이 사용하는 장비의 MAC 주소를 등록하고 싶다고 하면 MAC 주소가 표시된 화면을 캡쳐해서 보내달라고 하는데 (이메일로 보내달라고 했음), 그냥 노트북에서 MAC 주소 표시되는 부분 캡쳐해서 보내주면 된다.

- 처음에 선불요금제 가입할 때에는 KT 대리점에서 해야 하지만, 일단 가입하고 난 다음에는 올레 웹페이지에서도 추가 충전이 가능하다. (물론 30일 이상 장기체류일 때 이야기지만)

근데 이렇게 적어놓고 보니 폰 많이 안 쓰고 외부에서 랩탑으로 데이터 접속할 일이 필요한 사람은, 최소한의 선불폰 요금만 지불하고 Olleh Wifi로 버티는 것도 꽤 괜찮은 방법이지 싶다. 요즘처럼 5만원 넘는 요금제가 일반적인 느낌인 상황에서는 말이지.

침몰

Kenial — Fri, 17 Apr 2015 19:10:57 +0900

세월호를 기억하기 위해 무슨 이야기를 써야할까, 이런 저런 텍스트를 썼다 지웠다를 반복하는 중.

...

사실 나는 세월호 이야기를 주변에서 듣거나 세월호 관련 뉴스를 접할 때마다, 삼풍백화점 붕괴사고가 떠오르곤 한다. 그토록 큰 사고였음에도, '이익을 위해서라면 안전은 뒤로 미룰 수 있다'는 사람들의 의식은 지워낼 수 없었다는 점에서. (그리고 결국 잊혀져 사람들이 입에 올리기조차 꺼리는 사고가 되고, 마침내는 또 다시 사람들을 이런 현실에 체념하게 만들지 않을까 하는 생각에)

한국 사회에서 평범하게 밥벌이를 하면서 살아간다는 것은, 밥벌이의 지겨움에 대해 체념하는 것이다. 자기 한 몸, 혹은 가족을 건사하며 살아간다는 일이 때로는 버겁고 지난한 일일지언정, 늦은 밤 잠자리에서 몸을 일으켜 삶의 구차함에 치를 떨게 하는 일은 아니어야 할 것인데. 사람들은 조금씩 그 감각에 익숙해지고, 조금씩 침몰해 간다. 어딘가 잘못되어 가고 있다는 것을 어렴풋이 느끼면서도, 당장 할 수 있는 것이 오늘 하루를 수습하는 것 외에 없음을 알고 있기에, 서로가 서로의 옷깃을 붙들고 같이 침몰해간다.

...

삼풍백화점 붕괴사고가 일어나고 얼마 되지 않았을 때, 어떤 친척 어른 중 한 분이 "강남에서 백화점이 무너졌담서? 백화점에서 팔자좋게 쇼핑이나 하다 무너져 죽었구만!"이라고 하는 말을 들었던 기억이 난다. (어느 분이 했던 말인지 잘 기억나지 않는게 다행이다. 아마 그랬다면 난 지금 그 분을 경멸하고 있었겠지) 사고의 심각성에도 불구하고, 기성세대에게 삼풍백화점 사고는 한국에서 일어날 수 있는, 그런 사고였다. 어떤 형태로든 사람들은 죽고 다쳤고, 그것은 개인의 운 없음에 불과했다. 권력에 의한 것이든 기업에 의한 것이든, 개인에게 닥치는 일은 개인이 알아서 잘 처신해서 피해야 할 일이었다. 그게 다였다. 6.25 전쟁 휴전 이후 60여년이 지났지만, 이곳은 여전히 사람이 죽고 다치는 일이 그저 운 없음에 속하는 일이었다. 마치 전쟁터에서 총에 맞는 일이 그렇듯이.

하지만 세월호 사건이 특별한 것은, 아마도 희생자의 대다수가 어린 학생들이라는 부분일 것이다. 단지 자기 한 몸과 가족을 건사하기 위해 때로는 구차한 일상을 감내하는 이 땅의 기성세대에게, 자신과 동류인 사람들이 어디선가 '운 없이' 희생당하는 것은 외면할 수 있어도(이것 또한 구차함에 속하는 일이다), 책임질 것도, 책임질 수도 없는 미성년자들 - 그 중의 일부는 자신의 자식일 수도 있는 - 이 희생당하는 것은 차마 외면하기 어려운 일이었을 것이다.

...

세월호는 어떻게 기억될까.

세월호 관련 뉴스를 읽다가 눈길을 끄는 기사를 하나 발견했다: 양평고 학생들이 바라보는 ‘세월호 참사’ (http://kggoodnews.co.kr/n_news/news/view.html?no=9447) 학생들을 대상으로 한 설문조사였는데, 조사 항목 중 세월호 참사에 대한 느낌에 대한 질문이 있었다. 그 응답이, 94.7%의 학생들이 내 주변에서 일어날 수 있는 일로 인식한다는 부분이었다.

세월호 사건이 남의 일이 아닌 것을 알게 된 아이들은, 과연 이 사건을 어떻게 기억하고 어떻게 살아가게 될까. 더 이상의 체념은 없었으면 하고 바래본다.

미디어 스트리밍의 역사와 온라인 TV(connected TV)의 미래

Kenial — Thu, 26 Mar 2015 13:00:36 +0900

자체 스터디 겸 최근 스트리밍 미디어 분야에서의 기술적 흐름을 설명한 글을 찾다가, 괜찮은 내용이라 생각되어 간단히 옮겨 봅니다. 원문은 가디언지에 2013년에 게재되었던 내용입니다.

원제: A history of media streaming and the future of connected TV

http://www.theguardian.com/media-network/media-network-blog/2013/mar/01/history-streaming-future-connected-tv

미디어 스트리밍의 역사와 온라인 TV(connected TV)의 미래

우리는 온라인 TV의 대규모 도입의 도화선이 될 HD 스트리밍의 보급을 눈앞에 두고 있다. Alex Zambelli가 현재까지 스트리밍 미디어 분야에서 일어났던 일을 여기 정리했다.

Alex Zambelli

2013년 3월 1일 금요일

1995년 9월 5일, ESPN SportsZone은 시애틀에 기반을 둔 Progressive Networks라는 이름의 스타트업이 개발한 최신 기술을 사용해서 시애틀 마리너즈와 뉴욕 양키즈의 야구 경기 라디오 실황을 전세계에 중계했다. 이 라디오 방송은 세계 최초의 스트리밍 방송이었다. 몇 년 후 Progressive Networks는 회사 이름을 RealNetworks로 변경하였고, 훗날 이 회사는 스트리밍 미디어라는 새로운 기술 분야에서 우위를 점하기 위해 Microsoft와 기술적 경쟁과 법적 공방을 벌이고, 결국 쓴 맛을 보게 된다. 인터넷에서의 스트리밍 미디어에 대한 전망은 언제나 IT 애호가와 CEO들을 흥분시켰지만, 초창기 스트리밍 미디어는 어떻게 하면 56k 모뎀 회선으로 볼만한 비디오를 전송할 수 있을지 같은 실용적인 문제에 부딪혀 있었다. Microsoft는 Windows Media 기술에 힘입어 RealNetworks를 물리치고 승자가 되어 전면에 나서는데 성공했지만, 그 승리를 계속 누리지는 못했다. Microsoft가 기회를 살리지 못하고 어물거리는 동안, Macromedia(후일 Adobe Systems에 의해 인수된다)는 느리지만 확실하게 Windows Media의 시장 점유율을 잠식해서 2000년대 중반 즈음에는 급속히 대중화된 Flash Player가 그 자리를 대신하게 된다. Flash는 상호작용성, Web 2.0, 스트리밍 미디어를 최초로 매끄럽게 통합함으로써 스트리밍 미디어 산업을 뒤흔들었다. 스트리밍 미디어의 새로운 시대가 도래했으나, 대역폭, 확장성, 접근성 등 오래된 문제는 여전히 해결되지 않았다.

2000년대 중반까지 대부분의 인터넷 트래픽은 HTTP 기반이었고, CDN은 대중적인 컨텐츠를 수많은 이용자에게 확실히 전달하기 위한 용도로 급속히 성장중이었다. 스트리밍 미디어 기술은 각 회사의 전용 프로토콜(대중적이던 UDP와도 대부분 거리가 먼)만으로는 요구를 충적하기 어려웠다. 2007년 Move Networks라는 이름의 회사는 스트리밍 미디어 산업을 다시 한 번 뒤바꿔 놓을 기술을 내놓았다. 그것은 HTTP 기반 적응형 스트리밍(HTTP-based adaptive streaming)이었다.

특정 회사의 전용 스트리밍 프로토콜에 의존하여 사용자들을 그때그때 인터넷 대역폭의 상황에 맡겨버리는 대신, Move Networks는 대중적인 HTTP 프로토콜을 사용해 미디어를 작은 파일 조각들로 나누어 전송하는 방식을 택했다. 플레이어 응용 프로그램에서 다운로드 속도를 측정하여 시시각각 변하는 네트워크 상황에 따라 전송할 파일 조각의 품질(즉, 파일의 크기)을 선택하도록 하는 것이다. 이 기술은 큰 반향을 일으켰다. 그도 그럴 것이, 이 기술은 스트리밍 미디어를 표준 HTTP를 사용해 광범위하게 CDN에 배포할 수 있도록 해 주었으며, 효율성을 위해 캐시를 할 수도 있었고, 사용자측에서 발생하는 짜증스러운 버퍼링과 연결 문제를 해소해 주었다. 다른 HTTP 기반의 적응형 스트리밍 솔루션들이 곧 그 뒤를 이었다: Microsoft는 2008년에 Smooth Streaming기술을 발표했고, 같은 해에 Netflix는 Watch Instantly 스트리밍 서비스를 위한 자체 기술을 개발했다. 2009년에 Apple은 iOS 기기에 비디오를 전송하기 위해 설계한 HLS(HTTP Live Streaming)를 발표했고, Adobe는 2010년에 HDS(HTTP Dynamic Streaming)으로 이 대열에 합류했다. HTTP 기반의 적응형 스트리밍은 고화질 라이브 스트리밍 이벤트(밴쿠버 , 런던 올림픽, 윔블던, Felix Baumgartner의 성층권 다이빙 등)와 고급형 on-demand 서비스(Netflix, LoveFilm, Amazon Instant Video 등)에 즐겨 쓰이는 기술로 빠르게 정착했다. 이 시기는 스트리밍 미디어에 있어서 청소년기와 같았다. 가능성은 넘쳐났지만, 혼란스럽고 다소 서툴렀다.

성숙의 단계에서 메인스트림의 단계로 진입해가는 산업 분야에서, 독점적인 스트리밍 기술들의 경쟁이 또 일어날 경우 득보다 실이 많으리라는 것은 명백했다. 그리하여, 2009년에 3GPP에서 적응형 스트리밍을 위한 산업 표준을 만들기 위한 작업이 시작되었다. 3GPP의 표준화 작업은 2010년에 ISO/IEC MPEG 워킹 그룹으로 옮겨졌고, 이곳에서 다양한 제안들은 채 2년도 못 되어 초안 상태로 정리되어 승인을 앞두게 되었다. Microsoft, Netflix, Apple을 위시한 50개 이상의 기업과 3GPP, DECE, OIPF, W3C 등의 기술 그룹이 이 작업에 참여하였다. 2012년 4월에 Dynamic Adaptive Streaming over HTTP, 통칭 MPEG-DASH라는 이름의 새로운 표준이 만들어졌다.

2011년이 되자 여러 기업들은 재빨리 MPEG-DASH에 대한 지원을 발표했지만, 검증 없이 표준이 적용되는 일이 종종 있었다. MPEG-DASH의 명세는 너무 넓은 범위를 다루려 했고, 그 결과 심히 모호한 명세가 되고 말았다. (HTML5 비디오를 도입하려 시도해 본 사람에게는 친숙한 이야기일 것이다) MPEG-DASH에 참여한 기업들은 DASH의 도입을 촉진하고 상호간의 운용에 대한 규약을 정리하고자 하는 것을 목표로 하는 DASH 산업 포럼을 재빠르게 조직했다. 2011년 초에 DASH-IF는 DASH264 구현 가이드라인의 version 0.9 초안을 내놓고, 커뮤니티 리뷰를 위해 공개했다. (피드백 기한은 2013년 3월 15일까지였다) 그 이름대로, DASH264 가이드라인은 상호운용성에 필요한 중요 사항들에 대한 내역을 제공하고 있다. 예를 들어, 이 가이드라인에는 H.264 비디오 코덱 지원에 대한 내용이 포함되어 있는데, 이 비디오 코덱은 지난 수년 간 산업 표준의 역할을 해 왔다. 그 외에도 상호운용성을 위한 기본적인 사항들 - HE-AAC v2 오디오 코덱, ISO 기반 미디어 파일 포맷, SMPTE-TT 자막 포맷, 컨텐트 보호를 위한 MPEG Common Encryptions(즉, DRM) - 이 포함되어 있다. 이 중 Common Encryption은 특히 흥미로운데, 이 기술은 사용자들이 특정한 디지털 상점에 발이 묶이지 않고도 Microsoft PlayReady, Adobe Access, Widevine과 같은 DRM 기술들이 서로 경쟁할 수 있는 발판을 마련해준다. DASH264는 스트리밍 미디어 산업에서 절실하게 요구하고 있는 세부 내용들을 제공하여, 향후 1~2년 사이 MPEG-DASH를 도입하는데 눈에 띄는 견인차 역할을 할 수 있을 것으로 기대되고 있다.

상호운용성을 제외하고, 스트리밍 미디어와 OTT 방송(over-the-top, VOD, IPTV와 같이 방송 사업자의 개입 없이 ISP에서 직접 컨텐츠를 제공하는 형태의 서비스)이 직면한 큰 장애물 중 하나는 방송 품질이다. 불과 몇 년 사이에 스트리밍 미디어 기술은 SD 비디오에서 720p HD 비디오로 도약했지만, 최고의 VOD OTT 서비스들조차도 방송 품질이 여전히 TV 방송과 블루레이 비디오의 품질에 미치지 못하고 있다. 예를 들어, 위성(DVB-S2)를 통해 송출되는 대부분의 HD 비디오는 17~37Mbps의 H.264 코덱으로 압축된 1080i 비디오인 반면, 대부분의 HD 스트리밍 비디오는 3~4Mbps에 불과한 720p 급 영상이다. TV 방송은 유럽의 경우 50Hz로 송출되고 있지만, 스트리밍 비디오는 유럽에서는 그 절반인 25Hz, 북미에서는 30Hz로 송출되고 있다. 마지막으로, 오디오 방송은 보통 오늘날 5.1 서라운드로 송출되고 있으나, 스트리밍 오디오는 여전히 대부분 스테레오로 송출되고 있다. (가끔 모노인 경우도 있다)

진정 OTT가 전통적인 미디어 전달 방식에 도전하려면 아직 극복해야 할 품질 문제가 존재하지만, 다행히 희망이 보이고 있다. 디지털 미디어의 품질은 일차적으로 대역폭에 영향을 받기 때문에 두 가지 확실한 방법으로 품질을 향상시킬 수 있다: 대역폭을 증가시키거나 압축 효율을 향상시키거나. 전자는 전반적인 인터넷 대역폭의 증가가 필요하지만, 후자는 새로운 코덱 기술을 통해 품질을 향상시킬 수 있다. 10년 전 H.264를 만들었던 ISO/IEC MPEG과 ITU는 최근 성공적인 공동 작업을 통해 최신의 코덱 기술인 H.265를 만들었다. 2013년 초에 ITU는 검증 과정을 거쳐 H.265가 기존 H.265에 비해 40~45% 향상된 압축 효율(혹은 대역폭 감소)을 보인다고 발표하였다. 이러한 압축 효율의 증가는 스트리밍 미디어 공급자가 대역폭을 더 늘리지 않고도 기존의 720p 비디오 송출에 사용되던 회선과 동일한 3~4Mbps 급 대역폭으로 1080p (Full HD) 비디오를 송출하거나, 프레임 비율을 50/60로 늘릴 수 있도록 해 준다. 사실 많은 이들이 H.265의 등장을 4K 비디오 시대의 도래로서 환영하고 있으며, 최종적으로는 스트리밍 비디오의 품질이 현재 느린 행보를 보이는 방송 표준을 추월할 날도 어쩌면 올지 모른다.

꿈꾼다고 안 될 것은 없잖은가?

Alex Zambelli은 iStreamPlanet의 principal video specialist이다.

Lumia 1020 10일 체험기

Kenial — Sat, 14 Mar 2015 17:30:51 +0900

겨우 10일 사용해 보고 사용기 같은 걸 쓴다니 나는 파워블로거지가 아니다! … 라는 생각으로 적어보는 Lumia 1020 10일 체험기.

2013년 7월에 발매한 물건을 어째서 2015년 3월에 구입하고 있는지에 대한 이유는 좀 복잡하긴 한데, 굳이 맘에 안 드는 아이폰 신규 모델을 쓸 것인가 안드로이드로 옮겨 갈 것인가 고민하다가 '에이 차라리 스마트폰 앱으로 낭비할 시간에 Lumia 1020을 사서 사진이나 열심히 찍자!'하는 같잖은 생각이 들었기 때문이었다. 뭐 생각이 그랬다는 것이고,

뭐 아무려면 어떤가. 이것은 정말 예쁘다.

사진으로는 이 느낌이 온전히 전달되기 어렵지 않나 싶은데, 마치 원색의 크레용 덩어리를 들고 다니는 듯한 느낌이다. 어디에 두어도 주변 풍경의 채도를 확 떨어뜨린달까… 실물을 보신 적이 없다면 나중에 한 번 살펴들 보시기를.

그러나 - 이쁜 건 이쁜거지만, 윈도우 폰 유저로서의 삶은 험난하다. 5년이나 묵은 구닥다리 iPhone 4를 쓰다가 Lumia 1020으로 옮겨간 이후 어떤 일이 벌어졌느냐 하면:

- 인터넷 뱅킹 불가: 앱이 없다.

- 카톡 잘 안씀: 윈폰 버전 카톡은 좀 많이 바보같다.

- 게임 안함: 원래 안했지만 이제는 앱이 없다(…)

- 테더링 불가: MS가 WP 8.1 업데이트를 통해 통신사의 설정을 강제로 적용하도록 바꿨다. jailbreak도 안된다.

- 자전거 네비게이션 못 씀: 구글맵이 없다(…) 자전거 네비 지원하는 다른 앱도 없다.

- 자전거 주행기록 안 함: ...

- 페북 잘 안 씀: 윈폰 버전 페북은 Microsoft가 개발하고 있다. 무슨 소리냐고? 사실이다:
http://www.windowsphone.com/en-us/store/app/facebook/82a23635-5bd9-df11-a844-00237de2db9e

- 에버노트로 기록 안 함: 에버노트에서 기존 노트를 편집했다가 노트 내용이 overwrite됐는데 conflicted 노트도 안 남아서 노트를 날린게 벌써 한 네 건쯤 된다.

- 메일 앱으로 메모 안 남김: Gmail의 Draft 기능이 윈도우 폰의 built-in 메일 앱과 호환되지 않는다. (이건 설명하기 좀 복잡함. 직접 써보시라고 밖에…)

- 사진도 많이 못 찍음: 나는 스냅사진을 주로 찍는데, 기동 시간이 5~6초로 살짝 긴데다 연사 기능이 별도로 분리되어 있어서 스냅으로 파바바박 막 찍어대긴 어렵다.

- 분명히 모바일용 웹 페이지인데 Lumia 1020에서는 이미지가 반쪽만 보인다던가, 뭔가 페이지 레이아웃이 와장창 깨져 있거나 해서 스트레스를 준다. 아니 이놈의 IE는 모바일 버전도 호환성이 이런거야? (…)

- No Trello, no Hangout, no Slack, no …

한 문장으로 정리하자면: 앱이 없다 or 앱이 거지같다. 사실 윈도우 폰 사면서 미리 각오를 하지 않은 것도 아니다만 이건 총체적 난국이랄까.

그나마 어떻게든 장점을 짜내보자면,

- 어두운 카페에서 그냥 대충 스마트폰 꺼내서 사진 찍으면 이런 사진이 나온다:

- 라이브 타일 기능은 무척 맘에 든다. 하지만 언젠가 애플이 비슷한 기능 내놓겠지… (안드로이드는 이미 위젯 형태로 하고 있고)

- 실제로 나의 스마트폰 사용 시간을 줄여주고 있다 (…)

- 메일 앱이 약간 독특한 방식이라, 메일 계정을 추가하면 계정마다 앱 아이콘이 생긴다. 앱 하나에 여러 메일 계정을 등록해 쓰는 것보다는 확실히 편하다.

- 앱의 특정 기능을 pin으로 꺼낼 수 있는 기능 또한 좋다. 예를 들면, 에버노트의 '새 노트 작성’을 별도의 아이콘 앱처럼 꺼내서 곧바로 새 노트를 작성하는 화면으로 넘어가도록 세팅할 수 있다. 하지만 대부분의 앱이 이 pin 기능을 제대로 활용하고 있지 않는 경우가 많아 실망스럽기도. 하지만 언젠가 애플이 비슷한 기능 내놓겠지2...

- 기본 앱은 아니지만 기본 앱 같은(?) Here 맵이 offline map navigation 기능을 제공한다. 이게 무슨 의미냐면, 인터넷 연결이 차단된 상태에서도 네비게이션 기능을 사용할 수 있다는 의미. (실제로 airplane mode를 켠 상태에서도 주소 검색이나 네비게이션 모두 잘 작동한다) 하지만 한국 지도는 다운받을 수 없으므로 혹시 한국에서 사용하시려는 분들은 이 타이밍에서 절망하시면 됩니다. 이 사안은 누굴 욕해야할지 잘 모르겠다. 교통관련 정부부처를 비난하면 될려나(…)

뭐 장점도 적어보니 장점이 아닌 것 같기도 하고… 카메라 밖에 장점이 없냐!

Tornado-test-c10m: 대규모 TCP / WebSocket 동시 연결 테스트에 대한 기록

Kenial — Thu, 20 Nov 2014 14:31:26 +0900

이 글의 내용을 요약하면, "대량의 TCP / WebSocket 동시 연결(최소 65K 이상, 가능하다면 10M)을 처리하기 위한 환경을 구성하고 Tornado를 사용해 이를 테스트하는 간단한 프로그램을 만들어 보았다”이다. 일반적으로 재미있을만한 주제가 아니므로, 관심이 없는 내용이라면 뒤로 가기 버튼을 눌러 재빨리 빠져나가도록 하자.

이 작업을 시작한 이유는, 그 동안 개인 프로젝트(Fountain)를 진행하면서 Scale-up에 대해 생겼던 궁금점을 해결하기 위함이었다. 대량의 웹 트래픽 처리에 관심이 있는 사람이라면 C10K problem(=10,000개 이상의 네트워크 동시 연결Concurrent connection을 지원하는 서버를 구축하는 문제)에 대해 들어본 적이 있겠지만, 사실 유닉스 계열 운영체제에서 이 문제는 시스템에서 사용 가능한 file descriptor 숫자만 늘려주면 된다. 예전에야 컴퓨터의 리소스가 한정되어 있어 극단의 최적화가 필요했겠지만, 어쨌든 요즘 나오는 PC라면 최대 fd 수만 늘려줌으로써 (성능이야 어떻든) 10K 이상의 소켓 연결을 처리할 수 있다.

나는 TCP / WebSocket 연결을 지원하는 리얼타임 서버를 만들어야 했었고, Tornado로 이걸 구현하기로 했다. fd 숫자를 늘리고, local port range를 조정하고, 간단한 서버 / 클라이언트 코드를 작성해서 50,000개의 연결이 제대로 생성되고, 메시지를 주고받는 것을 확인하였다. 이게 작년의 이야기. (C10K tuning에 관련된 내용은 구글에 검색해 보면 많이 있으므로 그 내용을 참고하시라)

그리고 시간은 흘러서 얼마 전 모 회사에서 인터뷰를 할 일이 있었는데, 리얼타임 서버에 대한 이야기가 나왔다. 이 시점까지 나는 리얼타임 서버가 50K 이상의 연결을 처리할 일이 있을까에 대한 생각 자체를 해보지 않았다. 예를 들어보자면, 안드로이드를 지원하는 Push notification 서버 혹은 Messaging server 같은 경우 실제 트래픽은 상대적으로 적지만 대량의 연결을 계속 유지해야 하는 경우가 있다. 이런 유형의 서버가 있을 때 Scale-up을 어떻게 할지에 대한 질문을 받은 것이었다. inbound traffic을 모니터링하면서 상대적으로 가벼운 인스턴스를 계속 spawn하면 되지 않겠느냐 했지만 그것은 올바른 대답이 아니었다(…)

계속 인터뷰는 이어져서 내 개인 프로젝트에 대한 이야기가 나왔을 때, 내 서버가 얼마나 많은 동시 연결을 처리할 수 있냐는 질문에 ’5만개 연결까지는 테스트해봤지만 아직 그 이상 scale-up에 대해서는 아직 고민해보지 않았는데요’고 대답하니 ‘5만개요? (시무룩)’이라는 반응이 돌아왔다. 여기서 좀 당황했는데, 이때까지 나는 5만 개 이상의 동시 연결을 처리하는 서버를 구현할 일이 있을까라는 생각 자체를 해 본 적이 없기 때문이었다. 아니 이제 5만 개 동시 연결을 처리하는 걸로도 부족한 시대가 되었단 말인가!

새삼 궁금해져서 집에 돌아와 관련 내용을 검색해보니 이런 아티클을 찾을 수 있었다:

Whatsapp은 어떻게 5억 명의 사용자, 11,000개의 cpu 코어, 초당 7천만개의 메시지 처리까지 성장하였나 (영문) http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html

위 글을 읽어보면 알겠지만, 해당 글이 쓰인 시점에서 Whatsapp은 150대의 챗 서버로 1억 5천만 개의 동시 연결을 처리하고 있었다. 챗 서버 한 대당 1백만 개의 동시 연결을 처리하고, peak time에는 150만개 연결을 처리하기도 했다고.

이걸 읽고 나서 처음 든 생각은, ‘그래, 그런 서버를 구현한다고 치고, 테스트는 어떻게 하지?’ 였다. OS가 개별 소켓을 식별하는 방법을 알고 있는 사람이라면 금방 이해하겠지만, 소켓은 보통 local address와 remote address 두 값의 쌍으로 식별되며 (address는 192.168.0.10:8080처럼 ip:port 형태로 표현된다), 이 두 값이 중복되는 소켓은 존재할 수가 없다. 만약 한 개의 호스트 내에서 8080 포트를 listen하는 서버를 실행하고, 클라이언트를 실행해서 여러 개의 소켓을 생성해 이 포트에 연결하면 다음과 같은 주소를 갖는 소켓들이 생성된다:

local address	remote address
192.168.0.10:20001	192.168.0.10:8080
192.168.0.10:20002	192.168.0.10:8080
192.168.0.10:20003	192.168.0.10:8080
192.168.0.10:20004	192.168.0.10:8080

이게 뭐가 문제냐면, 포트 번호는 0~65,535까지로 한정되어 있기 때문에, 이 범위의 포트 번호를 전부 사용하고 나면 더 이상 local address를 위한 포트 번호를 할당할 수 없게 된다. 그러므로 이상적인 상황을 가정할 때 로컬에서 실행한 서버에 연결할 수 있는 최대 연결 수는 65,536개라는 이야기. (물론 실제로는 이런저런 제약 때문에 그 숫자가 더 작아진다) 물론, 서버 한 대와 클라이언트 여러 대가 포함된 테스트 환경을 구축한다면 이 문제는 피할 수 있다. local address에 여러 IP를 사용할 수 있다면 그 IP 개수 만큼 전체 연결 개수를 늘릴 수 있으니까. 하지만 서버 하나 테스트 하겠다고 그런 환경을 구축한다는 건 좀 에러고...

그래서 이를 피하기 위해 이용한 꼼수는, 서버가 여러 포트를 listen하게 하는 것. 그렇게 하면 이런 식으로 소켓을 생성할 수 있다:

local address	remote address
192.168.0.10:20001	192.168.0.10:8080
192.168.0.10:20001	192.168.0.10:8081
192.168.0.10:20002	192.168.0.10:8080
192.168.0.10:20002	192.168.0.10:8081

위와 같이, local address가 같더라도 remote address가 다르면 소켓을 식별할 수 있으므로, 서버에 할당한 listen port 수 * 50K 만큼의 연결을 만들어 테스트할 수 있는 것이다. 천만 개의 소켓을 테스트하고 싶다? 서버에 listen port를 200개 할당하면 된다. 즉, 200 * 50,000 = 10,000,000 (10M). 호스트에 여러 IP를 할당하는 것도 한 가지 방법이기는 하지만, 네트워크 설정을 수동으로 변경해야 하므로 귀찮다.

어쨌든 이런 방법을 사용하면 개발 환경에서도 10M 연결을 테스트할 수 있다. 하지만 주의사항이 있는데, 어떤 이유에서인지 모르겠지만 OS X에서는 이 방법을 사용해도 65K 이상의 연결을 생성할 수 없다. netstat으로 확인한 결과 OS X에서는 remote address가 서로 다르더라도 local address가 중복되는 경우가 없으며, 무조건 local address를 사용하여 소켓을 식별하는 것으로 추정된다. (추정일 뿐이라 정확하지 않을 수 있다. 이 방식을 변경할 수 있는 설정이 어딘가 있을 것 같기도 한데, 불행하게도 찾지 못했다) Ubuntu Server 14.10에서는 확실히 동작하는 것을 확인했으므로, 삽질이 귀찮다면 Ubuntu Server 14.10를 사용하시기를 권한다. 뭔가 잘못되어도 내가 도울 수 있는 부분이 없다;

그러면 이제 OS 튜닝으로 넘어가야 하는데… 사실 이 튜닝에 대한 방법은 OS마다 서로 다르고, 어떤 종류의 서버를 구현하느냐에 따라 필요한 설정이 달라지는 관계로 스스로 검색하면서 필요한 내용을 찾아보는 수 밖에 없다. 내 경우만 해도 Ubuntu와 OS X를 같이 세팅해야 했던 상황이라 설정 내용을 공유하기도 그렇고… 이 작업을 하면서 도움이 되었던 링크 몇 개를 공유하는 것으로 대신한다 (모두 영문):

- The C10K problem

http://www.kegel.com/c10k.html

- Performance Tuning the Network Stack on Mac OS X Part 2

https://rolande.wordpress.com/2014/05/17/performance-tuning-the-network-stack-on-mac-os-x-part-2/

- Linux TCP/IP tuning for scalability

http://www.lognormal.com/blog/2012/09/27/linux-tcpip-tuning/

- RED HAT ENTERPRISE LINUX 7 PERFORMANCE TUNING GUIDE (CentOS에도 적용 가능)

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Performance_Tuning_Guide/index.html

- The C10M(!) problem

http://c10m.robertgraham.com/p/manifesto.html

그리고 이를 테스트하기 위해 급조한 코드를 여기 공유한다:

https://github.com/kenial/tornado-test-c10m

위 코드는 TCP / WebSocket을 지원하는 Echo 서버와 클라이언트로 구성되어 있는데, 클라이언트에는 대량의 소켓을 생성하거나 메시지를 전송할 수 있는 기능이 구현되어 있다. Python으로 작성되어 있고, 사용하려면 Tornado를 설치해야 한다. PyPy를 사용할 경우 성능 향상이 있기는 한데, 이 프로그램이 하는 일은 대부분 I/O에 관련된 작업이다보니 패킷 전송에는 그다지 성능 향상이 없었고, 연결 생성에는 상당한 성능 향상이 있었다.

Ubuntu Server 14.10에서 실행해 본 소감은, 메모리를 무지하게 먹는다. 위 프로그램을 실행해보면 TCP는 연결당 10.5KB, WebSocket은 연결당 15.5KB 정도가 할당된다. 이는, 만약 1백만 개의 연결을 생성하면 TCP 연결의 경우 1,000,000 * 2 * 10,500 = 21,000,000,000B = 21GiB의 메모리를 사용한다는 의미. (중간에 2를 곱한 것은 소켓이 생성될 때 서버에서 한 개, 클라이언트에서 한 개가 생성되기 때문이다) WebSocket의 경우에는 오버헤드가 더 있어서 31GiB 정도를 사용한다는 계산이 나온다. 1천만 개의 연결이라면? 각각 210GiB, 310GiB가 될 것이다. 케냘 소유의 PC 중에서는 21GB가 넘는 메모리를 가진 시스템이 없기 때문에 1백만 개의 연결 생성조차 테스트할 수가 없었고(…) EC2에 인스턴스를 생성해서야 테스트가 가능했다. 테스트에는 r3.4xlarge 타입의 인스턴스(122GiB memory)가 사용되었다.

실행 결과 화면을 첨부하는 것으로 이 글을 마무리할까 한다.

약간은 수염수염한 이야기.

Kenial — Thu, 19 Jun 2014 11:30:15 +0900

0. Conversation class에서 수염을 길러보면 어떻겠냐는 말을 들었다. 사실 수염을 길러보고 싶다는 생각은 예전부터 해왔지만 나는 머리카락을 제외하고는 몸에 털이 별로 없는 체질이라, 수염을 기르려고 시도하면 털이 듬성듬성 자라 뭔가 심각하게 더러운 몰골이 되어버린다. 그냥 수염을 길러 지저분한 남성이 오징어라면, 나의 경우에는 남미 심해에 서식하는 가문어 수준이라 할 수 있겠다. (*주: 가문어는 문어가 아니고 오징어입니다. 그것도 대따 큰 훔볼트오징어) 나라고 왜 수염을 기르고 싶지 않겠는가. 남자라면 누구 하나 관운장 수염을 꿈꿔보지 않은 이가 있겠는가(...)

어쨌든 '수염이 빨리 자라지 않아서 더러워 보일거다.'라고 웃으며 답했더니 fake mustache가 있지 않냐고(...) 긴머리 동양인 남성에게 가짜 콧수염을 권하다니 이들의 센스는 참으로 자유롭달까...

1. 내 보스는 수염을 기른다. 어디 버지니아 깡촌에서 장작을 패고 있을 나뭇꾼 같은 스타일의 풍성한 수염을 기르면서 머리는 단정하게 깎는, 약간 irregular한 스타일이라 할 수 있다. 오늘 ceo에게서 이런 메일이 왔다: '야 누가 내 수염 가지고 뭐라고 하면 이 유툽 링크를 보내버려.'

아 잡스수염 ...

동영상에 감화받은 나는 이렇게 답장을 보냈다:

'넌 여기에 낄 자격이 있다: http://www.thebolditalic.com/articles/5253-photos-beards-of-san-francisco'

2. San Mateo에 Beard Papa's가 있다고 한다. 이렇게 말해봤자 아무도 모를테니 좀 더 친절한 설명: 대충 거대한 슈같은 크림퍼프를 전문으로 파는 Beard Papa's가, 대충 우리 집에서 차 타고 20분 정도 거리에 있는 San Mateo에 매장을 두고 있다고 한다.

헉헉 수염할배 크림퍼프 헉헉

응?

구글 인터뷰 후기

Kenial — Wed, 18 Jun 2014 16:34:56 +0900

거의 1년만의 글인데, 근황에 대한 이야기를 쓸까 잠깐 생각했다가 어차피 요즘에는 페이스북에 근황 이야기는 많이 풀어놓고 있으니 별 필요가 없겠다는 생각이 들었다. 그리고 그 외의 근황을 생각해내서 적으려니 이건 뭐 오늘의 일기가 되겠다 싶어서 기각. 그럼 뭘 적을까, 하다가 벌써 반년 넘게 지나버린(...) 2013년 9월에 있었던 구글 온사이트 인터뷰 이야기라도 적어보면 어떨까 하는 생각이 들었다. 구글의 인터뷰는 어떤어떤 과정을 통해 이루어진다, 같은 이야기보다는 온사이트에 나왔던 문제와 내가 받았던 인상을 단편적으로 남겨본다. 혹시 구글에 인터뷰 볼 생각을 하고 있는 사람에게 참고가 된다면 좋겠고, 아니면 구글에서는 이런 인터뷰 질문이 나오는구나, 하고 넘어가시면 되겠다.

- 개요

온사이트 인터뷰는 (당연하지만) 구글 본사에서 이루어졌고 총 다섯 명과 인터뷰를 했으며, 각 인터뷰는 50여분 내외로 이루어졌으며 한 시간은 넘지 않았다. 나는 Python Engineer로 분류되어 인터뷰를 치러야 했다. Python에 대해 그리 깊게 알지도 못하는데!

구글에서 일하는 엔지니어 분들하고 얘기를 하면서 많이 들었던 말은, '운이 많이 작용한다'라는 것이었다. 그렇게 들었을 때에는 단순히 까다로운 알고리즘을 들고 나온다던가, 이상한(?) 사람이 인터뷰어로 등장한다던가 하는 것이라 생각했는데, 확실히 운이 많이 작용한다는 말이 맞는 듯 하다. 내 인터뷰의 경우 내가 영어도 잘 못하고(...) 무엇보다 Python 지식이 충분치 않았기 때문에 인터뷰가 잘 되기를 기대하는 것 자체가 무리이긴 했지만, 데이터 구조와 알고리즘을 잘 꿰고 있으면서 자기 분야의 지식(내 경우엔 Python)을 충실히 쌓은 상태라면 얼마든지 '잘 될 수도' 있다는 생각이 들었다. 그런 생각이 든 건 첫 라운드부터였다.

- Round 1

당연히 일반적인 알고리듬 문제가 나오리라 예상했던 첫 라운드에서는 굉장히 의외의 문제가 나왔다. 그것은 바로 Pivot Table 계산 알고리듬. 엑셀에 정통한 사람들은 당연히 Pivot Table 기능을 알겠지만, 아무리 프로그래머라고 하더라도 모든 비즈니스 어플리케이션에 정통할리가 없고 엑셀을 많이 쓰지 않는 사람의 경우에는 Pivot Table 자체를 모를 수도 있다. 인터뷰어가 스프레드시트가 그려진 종이를 들고 와서 Pivot Table을 아냐고 물어보길래 그렇다고 했더니 이거 설명할 1분을 절약했다며 좋아했다(...)

여튼 첫 질문은, 여러 컬럼이 있는 데이터가 있을 때 이를 컬럼별로 Grouping해서 count하는 로직을 어떻게 만드느냐였다. 처음에는 문제 자체에 당황해서 버벅거렸지만 이내 평정을 찾고, dictionary를 만들고 키를 컬럼명_indexnum 키 이름으로 만들어서 특정 컬럼 항목의 count를 계산하는 간단한 방법을 제시했다. 그리고 Grouping이 컬럼A, 컬럼B로 연속해서 이어질 경우, 컬럼A_0_컬럼B_0 같이 sub-level의 count를 먼저 계산한 다음 상위로 summarize 해서 계산하는 방법을 제시했다. 코딩을 요구하기에 간단한 python 코드도 구현해 보이면서, 최적화가 필요하다면 컬럼에 존재하는 값을 별도의 테이블에 인덱싱하고, 실제 count에 사용할 composite key는 테이블에 인덱싱 된 숫자값을 조합한 key를 사용하면 좀 더 효율적으로 계산할 수 있을 것이라고 대답했다.

... 이렇게까지 대답할 수 있었던 것은, 내가 다차원 데이터베이스(MDB)에 백그라운드가 있어서였다. 나는 Pivot Table이 실제로 어떻게 구현되어 있는지는 정확히 모르지만, MDB나 Pivot Table이나 aggregation을 빠르게 수행하기 위한 목적은 동일하고, 위에 적은 내용은 초창기의 MDB가 설계된 방식이기도 하다.

어쨌든 여기까지 얘기하고 보니 인터뷰어도 이런 엔지니어가 올지 예상 못한 듯(...) 다른 쪽으로 질문을 돌리기 시작했다. count가 아니라 value - sum, average, min, max 등을 구해야 할 때에는 어떻게 할거냐? : average를 제외하고는 count와 동일하지만, average의 경우 컬럼의 특성을 고려해야 한다. 예를 들어 날짜 컬럼의 경우 년-분기-월-일의 hierarchy에 따라 데이터를 조회하는 경우가 많은데, 이 경우 날짜의 각 부분요소를 별도의 컬럼으로 처리해 인덱싱하거나, 혹은 snowflake schema로 인덱싱할 수도 있다. 이 경우 processing power / storage의 tradeoff다. aggregation을 미리 해서 데이터를 저장해 두면 데이터가 마구 증가하는데 이건 어떻게 할거냐? : aggregation granularity를 적절히 지정하여, 쿼리가 빈번한 항목에 대해서 aggregation을 미리 해두면서 나머지는 cache에 맡길 수도 있겠다.

이런 식의 문답을 주고받으며 한 시간을 채우고 인터뷰가 끝났다. (바깥에 다음 인터뷰어가 와서 기다리고 있었다;;;) 인터뷰어가 딱히 준비해 온 질문에만 집중해서 인터뷰를 진행하는 것이 아니라, 지원자의 역량에 따라 유연하게 인터뷰를 진행한다는 인상을 받았다.

- Round 2

2 라운드에서는 약간 일반적인 질문이 나왔다. 트리에서 Preorder, Inorder, Postorder 방식으로 노드를 처리할 때 next node를 알아내는 알고리듬을 작성해 보라는 것이었다. 이는 그때 지겹게 풀어보던 알고리듬 책에서 이미 나왔던 문제였으므로(...) 어렵잖게 풀 수 있었다. 중간에 약간 착각한 부분이 있어 화이트보드에 작성하던 코드를 지우고 다시 작성했는데, 이 때 인터뷰어 표정이 좀 좋지 않았던 것이 기억난다. 가급적이면 한 번에 깔끔한 코드를 적어내는 것이 좋겠지만... 나는 일단 코드를 적어나가다가 뭔가 생각이 나면 기존 코드를 뒤엎고 다시 쓰는 편을 선호하는 사람이라 아직도 화이트보드 코딩에 적응을 못 하고 있다. 반성해야겠다.

코드를 neat하게 작성하는 방법에 대한 질문도 있었는데, 기억이 희미해서 이 부분은 적질 못하겠다. 전반적으로 무난하게 지나가긴 했다.

- Round 3

여기서부터 본격적으로 헤매기 시작했다. 생각나는대로 질문을 적자면:

- 자바에 비해 파이썬의 장점은? (저 파이썬도 깊게 모르고 자바는 잘 모르는데요...)

- 파이썬에서 바꾸고 싶은 부분이 있다면?

- ABCD / DCBA처럼 reverse된 string이 서로 동일한 string이라고 간주하고, 일정한 배열에 든 string의 unique count를 구하려면?

- 두 서버가 통신하면서 object를 주고 받아야 하는데, 어떻게 시스템을 설계하겠는가?

답을 어디부터 시작해야 할지 모르겠어서 헤매기 시작했다. 한국말로 얘기하라면 어떻게든 썰을 풀었겠지만, 뭔가 말을 생각해내는 것도 어려운 상황에 영어로 옮기기까지 하려니 그야말로 제 정신이 아니었다. Dynamic Language의 장점과 언어 자체의 간결함에 대해 몇 마디 주절거린 것 같긴 한데, 제대로 된 내용은 아니었다. 파이썬에서 바꾸고 싶은 부분에 대한 질문은, 문득 django model을 사용할 때 필드의 타입을 미리 체크해서 해당 객체의 프로퍼티에 값을 할당하는 시점에 잘못된 값을 넣으면 타입 예외를 일으키도록 하는 기능(말하자면 ad-hoc type checking logic)이 있었으면, 하는 생각이 퍼뜩 들어서 그걸 더듬더듬 이야기했다. 근데 나중에 생각해보니 그냥 __getattr__, __setattr__로 어떻게든 할 수 있는 부분이라는 것을 깨닫고 절망했다(...)

세 번째 질문은 갑자기 공황상태에 빠져서 뇌가 안 돌아가는 상황에 봉착. 인터뷰 끝나고 딱 나오는데 해시를 사용한 해결방법이 떠오르고 좀 있다가는 double linked list를 사용한 해결 방법이 떠올랐다. Aftermath (...)

마지막 질문 또한 대체 뭔 대답을 원하는지 모르겠어서 망함. JSON / SOAP 등을 얘기하고 https가 어쩌고 저쩌고 중언부언하다 끝나버렸다.

- Round 4

요약: 그냥 망함(...)

질문은 이거 하나였다: 영화 데이터베이스가 있는데, 이 데이터베이스에 있는 항목들에 대한 번역 작업을 하기 위한 시스템을 구축하려 한다. 어떻게 하겠는가?

그냥 열린 질문(...) 처음에는 아예 질문 자체를 잘못 이해한데다가, 이야기를 하면 할 수록 데이터 입력 시스템에 대한 기획을 이야기하라는 것인지, 데이터 흐름을 설계하라는 것인지 갈피를 잡지 못하고 헤맸다. 사실 이 라운드에서는 내가 영어에 익숙지 못한 것이 가장 아쉬웠었다. 질문의 요지를 얼른 파악했으면 이야기를 좀 더 수월하게 끌고 나갈 수 있었을 터인데...

번역 데이터 입력 시스템에 대한 이야기를 할 때 구글 스프레드시트를 활용하면 어떻겠냐는 의견을 냈는데, 이 부분에 대해서 추가 질문이 계속 이어졌다. 하지만 역시 질문을 알아듣지 못해 계속 헤매는 사태가...

- Round 5

어째서인지 망함(...)

문제가 두 개였는데 하나는 생각이 안 나고(이건 풀었음) 다른 하나는 Knapsack problem이었다. 이 날 인터뷰 끝나고 나서 LA에 가기로 했었는데, LA로 자동차를 몰고 가다가 알고리듬이 생각이 나더라(...) 여튼 그 자리에서 풀지 못 해 망했다는 결론은 동일하다.

- 총평

3 라운드부터 멘탈 관리에 실패하고 아는 문제인데 왜 풀지를 못 하니 으허헝... 상태가 반복되었다. (4라운드 제외) 물론 인터뷰어가 제시한 질문에 대한 답을 했더라도, 그것만으로 좋은 점수가 나오는 구조는 분명 아닌 듯 하다. 일단 답을 했다면, 틀린 답이든 옳은 답이든 계속해서 심화된 질문을 던지고, 그에 대한 반응을 계속해서 살펴보면서 주관적인 점수를 매기는 방식에 가깝지 않나 싶다.

또한, 내게 할당된 인터뷰어가 다들 그런 사람들이었는지는 몰라도, 커뮤니케이션에서 굉장히 인내심을 가지고 무척 친절히 대해준다는 인상을 받았다. 다른 회사의 인터뷰에서는 의사소통에서 오는 스트레스가 너무 커서 인터뷰 문제에 집중을 못 하는 사태가 자주 벌어졌는데, 구글에서만큼은 그 스트레스가 확실히 적었다. 그냥 망했다고밖에 할 수 없는 4 라운드에서조차도, 인터뷰어의 인내심에 고마움을 느낄 정도였다.

준비된 질문이 계속 나오는 것이 아니라, 뭔가 답을 내놓으면 그에 따른 질문이 계속 이어지는 방식이라 무척 힘들게 느껴지기는 했지만, 내가 겪은 여러 인터뷰 중 손에 꼽을 수 있을 정도로 재미있는 인터뷰였다. 이런 인터뷰라면 몇 번이라도 하겠다 싶을 정도로.

- 결과

결과는, 떨어졌다.

어느 정도 예상은 하고 있었지만 덕분에 몇 달간 정신적 공황 상태를 겪어야 했다(...)

이상.

스마트폰을 위한 위치 기반 미니 사이트에 대한 짧은 생각

Kenial — Fri, 26 Jul 2013 17:48:28 +0900

Mug와 Sam의 활용 방법에 대한 아이디어 중 하나.

"위치 기반 + 미니 사이트"라는 용어만으로는 개념이 너무 막연하니 좀 더 풀어서 얘기하자면, "사용자 근처에 존재하는 미니 사이트"라고 할 수 있겠다. Sam은 위치를 기반으로 파일을 공유하는 기능을 제공하는데, Sam 주변에 있는 Mug는 이 기능을 통해 Sam이 공유하고 있는 파일에 접근할 수 있다.

상점이나 요식업소 등에서 Sam을 이러한 위치 기반 미니 사이트로 활용하면 어떨까하고 생각해 봤다. 예를 들면, 카페에서 스마트폰이나 태블릿으로 접속할 수 있는 작은 사진전(누군가 이런 걸 보면 '스마트 사진전'같은 되도 않는 이름을 붙일 것 같다는 느낌이 든다만은)을 연다든지 하는 것. 예전에 어떤 카페에서 여행을 좋아하는 카페 주인이 여행에서 찍은 사진을 카페 내에 조그맣게 공간을 내어 전시하던 것을 본 적이 있었는데, Sam을 이용한다면 공간의 제약을 받지 않고도 매장에 방문한 고객(다시 말해, 그 공간에 있는)이 스마트폰을 사용해 이들 사진을 열람하도록 하는 일이 가능할 것이다.

이를테면 이런 식일 것이다. (예전에 lake louise에서 찍은 사진 몇 장을 모아봤다)

혹은 미리 선곡한 음악 앨범이나 비디오 파일을 제공할 수도 있다.

홍보 자료를 제공해야 하는 곳이나 컨퍼런스 장소라면, PDF를 제공하는 방법을 생각해 볼 수도 있겠다.

기본적으로 Mug는 미디어 파일의 공유를 목적으로 디자인되기는 했지만, 웹 리소스에 접근할 수 있도록 구성할 수도 있다. 아래 화면에서는 위키피디어에 접속되도록 했지만, 해당 상점의 웹 사이트에 접속되도록 구성하는 것도 가능하다. 이 방식의 장점이라면, 해당 상점에 방문한 고객이 URL을 브라우저에 입력하지 않고도 웹 페이지에 접속할 수 있다는 점이다.

오늘날 인터넷 서비스는 그 특성상 특정한 정보를 자신의 서비스로 집중시켜 그 정보를 바탕으로 비즈니스를 전개해나가는 형태를 취하고 있다. 검색 엔진, 쇼핑몰, 지도 서비스, 리뷰 사이트 등 다양한 서비스가 존재하고, 이들 인터넷 서비스는 로컬 비즈니스에 일방적으로 영향력을 행사하고 있는 형국이다. 어차피 가격 경쟁력이 아닌 독특한 경험이나 특별한 서비스를 무기로 삼아야 하는 로컬 비즈니스의 특성 상, 이러한 위치 기반 미니 사이트를 활용하면 그리 큰 비용 없이도 그러한 서비스가 가능하지 않을까.

그리고 그러한 서비스에 활용한다고 한다면, 어떤 기능이 더 필요할까 고민 중.

p.s: 실제로 이 프로그램 써보실 분이라든지 뭔가 아이디어 있는 분은 아이디어 제공 좀 해주시면 감사하겠습니다. (_ _) 정말 필요한 기능이다 판단되면 차차 추가해 나가겠습니다. 본문에는 안 적었지만, 현재 앱 스토어에서 배포 중인 프로그램입니다.

자세한 내용은 http://www.fountainproject.com/info?lang=ko를 참고해 주세요.