Subscribe: Channy's Blog
http://channy.creation.net/blog/?feed=rss2
Added By: Feedage Forager Feedage Grade B rated
Language: Korean
Tags:
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Channy's Blog

Channy's Blog



Insights for Web 2.0, Open Source and Open Standards



 



하이브리드 웹 앱스토어 플랫폼의 종말

Mon, 22 Aug 2016 22:30:45 +0000

구글이 며칠 전 윈도우/맥/리눅스용 크롬 브라우저에서 크롬앱 지원을 단계적으로 폐지하는 계획을 발표했습니다. 크롬 브라우저에 사용하는 앱은 웹 기술을 기반으로 제작된 것으로, 2010년 구글 I/O에서 처음 소개된 후, 크롬 웹스토어 개념으로 확장되었습니다.

(image)

(좌) 크롬 웹 스토어, (우) 파이어폭스 마켓플레이스

물론 크롬앱 지원을 중단해도 현재 크롬에서 유용하게 사용되고 있는 확장 프로그램과 테마는 영향을 받지 않습니다. 향후 2016년 말 윈도우/맥/리눅스 사용자들이 크롬 웹스토어를 이용시 크롬앱이 지원 대상에서 제외되며 크롬 OS에서만 지원되고, 2017년 후반에는 크롬 웹 스토어에 노출되지 않고, 2018년 초에는 이미 설치한 크롬앱도 윈도우/맥/리눅스에서 실행되지 않는다고 합니다. (2011년 발표된 크롬 OS는 웹 브라우저 기반 데스크톱 OS로서, 지금도 이를 탑재한 크롬북은 교육 시장에서는 꽤 인기가 높습니다. 하지만, 이 계획 역시 잠정적인 것으로 보입니다.)

구글 블로그에 따르면, 실제 크롬앱 사용자가 크롬 유저 중 패키지 앱 사용자는 1%도 되지 않으며, 호스팅 앱 사용자도 네이티브 앱 수준을 대체할만한 새로운 종류의 웹 표준 API이 생겨나 ‘프로그레시브 웹 앱'(Progressive Web Apps) 개발이 가능해 진 것을 이유로 들었습니다.

데스크톱 기반 웹앱의 몰락
2010년도 초 당시 크롬 웹스토어와 크롬앱은 차세대 앱 플랫폼이 될 거라는 기대를 많이 받았습니다. HTML5를 기반으로 웹 애플리케이션 및 웹 OS에 대한 관심이 한참 높을 때였고, 구글 내에서도 안드로이드와 크롬 OS가 플랫폼 경쟁을 벌일 때였기 때문입니다.

구글은 크롬 브라우저를 기반으로 데스크톱에서 웹 기반 플랫폼을 모바일에서는 안드로이드를 미는 형국이었습니다. 그런데, 반전은 구글 내부의 크롬을 담당하던 선다 파차이가 안드로이드를 맡은 후 일어났습니다. 데스크톱 보다는 모바일에 힘이 실리면서, 안드로이드를 밀면서 어느 정도 예견되었고, 그 이후로 CEO가 되면서 완전히 정리되는 양상입니다.

크롬앱은 네이티브 앱과 웹앱의 간극을 좁힐 수 있는 다양한 API를 제공했고, PC에 설치해서 사용할 수 있는 기능을 제공했지만 하이브리드형 앱의 한계를 극복하지 못했습니다. 전형적인 데스크톱 웹 OS인 크롬 OS도 안드로이드 앱을 설치할 수 있는 방향으로 바뀌면서, 장기적으로는 안드로이드 기반으로 확장될 가능성이 높습니다. 구글이라도 역시 웹 플랫폼과 앱 플랫폼의 차이를 좁히기는 어려웠습니다.

모바일 기반 웹앱의 몰락
구글 크롬 웹 스토어와 함께 주목을 끈 또 하나의 웹 앱스토어는 Mozilla의 Firefox Marketplace입니다. 2011년 오픈 소스로 만든 모바일 웹 OS인 Firefox OS를 지원하기 위해 만든 웹 앱스토어로서, 다양한 Firefox OS 기기 뿐만 아니라 안드로이드와 PC 테스크톱에 앱 설치 기능을 제공하기도 했습니다.

지난 2월 Mozilla는 안드로이드 및 데스크톱 앱 설치 기능을 중단하기로 하였습니다. 기존 파이어폭스 OS 사용자를 위한 패키지 앱 지원은 2018년 1월까지 지원될 예정이긴 하지만, 모바일 단말기용 웹 OS 개발이 현재 중단된 상태이기 때문에 기존 사용자를 위한 웹 앱 지원 역시 잠정적으로 중단될 수 있습니다.

Mozilla의 웹앱 생태계에 대한 변화도 구글과 크게 다르지 않습니다. 외견 상으로는 웹 기술 양상이 네이티브 브라우저 기능 개선 위주로 다시 짜여지고 있지만, 기존 PC 혹은 모바일 운영 체제 플랫폼과 경쟁은 쉽지 않다는 점은 다시 한번 입증된 것이라 볼 수 있습니다.

팜이 만들고 HP가 인수했던 webOS (지금은 LG전자가 소유 중), 삼성전자의 타이젠 OS 등이 아직은 웹 OS로서 명백을 이어가고 있습니다만 여전히 성공 여부가 불투명합니다. 아직 TV 등 전자 기기, 웨어러블, 사물 인터넷 등의 영역에서 아직 가능성이 남아 있기는 합니다만…

웹은 웹으로… 앱은 앱으로…
웹 기술이 발전하면 앱 생태계를 완전히 장악할 거라는 장밋빛 희망이 있을 때가 있었습니다. 제 스스로도 Mozilla와 웹 표준 커뮤니티의 일원으로서 그런 전망을 많이 내 놓기도 하였습니다. 하지만, 소프트웨어 플랫폼이라는 것이 그리 쉽게 하나로 합쳐지기엔 너무나 많은 변수가 있습니다. 아마 크롬 웹 스토어, 파이어폭스 마켓 플레이스 등은 이러한 과도기 기술의 실패 사례가 될 것입니다.

(image)

그렇다고, 웹 개발자들이 이러한 미션을 포기한 것은 아닙니다. 2015년 6월 Alex Russel에 의해 기존 플랫폼을 활용한 하이브리드 방식을 벗어나 완전히 네이티브 환경의 앱과 같은 웹 브라우저 기반 앱으로 구현해 보자는 ‘프로그레시브 웹 앱’에 대한 개념이 시작되었기 때문이죠. 현재 구글을 주축으로 마이크로소프트, Mozilla, Opera 등이 동참을 하고 있습니다.

역사는 돌고 됩니다. 그리고, 경험을 기반으로 다시 새로운 혁신이 일어납니다. 과도기적인 웹앱스토어는 몰락했지만, 앞으로 웹 기술이 어떤 플랫폼 변화를 보여줄 지 기대됩니다. 웹 만큼 빠르고 혁신적으로 움직이기 유연한 플랫폼이 없으니까요.




카카오 맞춤법 검사 오픈 API 중단에 대한 유감

Wed, 17 Aug 2016 22:30:06 +0000

온라인 맞춤법 검사기를 개발해 오신 부산대 권혁철 교수님이 카카오가 제공하는 맞춤법 검사 서비스 및 오픈 API에 대한 공개적으로 의혹을 제기하셨는데, 이에 대해 카카오가 오픈 API를 중지하는 결정을 하였습니다. 저는 이러한 일련의 사태가 국내 소프트웨어 및 인터넷 서비스 발전에 전혀 도움이 되지 않는 우려할만한 선례를 남겼다고 생각합니다. 먼저 논란이 된 권혁철교수님의 글과 이에 대한 카카오의 답변을 읽어보시죠. 대형 포털들이 맞춤법 검사기를 공개했다, 그런데… 다음 맞춤법 검사기와 관련된 논란에 대해 설명드립니다. SW 베끼기 문제 제기 방식에 대한 유감 누구라도 본인의 소프트웨어(SW) 저작권 및 특허권이 침해됐다고 판단했다면, 이는 증거를 통해 이의를 제기하고 법적인 소송을 통해 해결해야 합니다. 장기간 SW 연구 개발을 해오신 권 교수님께서 이를 모르시지는 않으실 것입니다. 물론 처음에 개인적인 의견과 감정의 소회를 페이스북에 올리셨지만, 이를 인터넷 언론인 ‘ㅍㅍㅅㅅ’에 게재하는 것으로 책임을 져야 하는 공적인 발언이 됩니다. 많은 블로거가 인터넷 매체사로 부터 중복 게재 요청을 할 때, 내 글을 알려주는 게 고맙다는 생각에 수락하게 됩니다. 하지만, 이는 매우 유의해야 합니다. 만약 카카오의 답변글 처럼 역공학이나 참고한 내용이 없다는 것이 사실이라면, 이는 언론을 통한 명예 훼손이 될 수도 있는 사안입니다. 토론의 대상을 공적 담론의 장으로 끌어오는 것은 좋지만, 아니면 말고 식의 증거 없는 무분별한 의혹 제기는 사양합니다. 한국어 자연어 처리 기술 현실에 대한 유감 영어를 포함해 세계 각국의 맞춤법 검사기는 매우 많은 오픈 소스 라이브러리, 플러그인, 상용 소프트웨어 및 API 서비스가 나와 있습니다. 그런데, 유독 한국어 맞춤법 검사기는 권혁철 교수님이 만드신 것 외에 쓸만한 게 없었던 게 현실이었습니다. 이에 대한 공로는 누구도 부인하지 못할 것이고, 오랜 기간 연구 및 서비스로 만들어 제공하신 것에 대해서는 다시 한번 감사드립니다. 하지만, 네이버와 카카오가 자체적인 개발 방식으로 맞춤법 검사기를 만들었다면, 이에 대해 비난할게 아니라 연구자로서 오히려 기뻐하고 장려할 만한 일이라고 생각합니다. 저 또한, 카카오의 맞춤법 검사 API 공개가 향후 한글 자연어 처리 기술 발전에 큰 도움이 될 것으로 기대하고 있었습니다. 권 교수님도 자신의 기술을 사업화 하는 과정에서 경쟁사로 인지 되는 대기업과의 관계 속에서 마음이 상한 부분이 있으시더라도, 큰 틀에서 동의하실 것이라 생각합니다. 네이버와 카카오 같은 회사의 담당 개발자들도 권 교수님의 제자들이거나 아니면 자연어 처리 연구를 했던 사람들입니다. 한국어를 하는 사람들이 컴퓨터나 온라인을 통해 좀 더 쉽게 검색, 사전, 맞춤법, 번역 등의 서비스를 제공하고자 노력하고 있습니다. 각자 개발 결과물의 방식이 정당했다면, 기술 경쟁은 오히려 장려 돼야 할 사안이지 비난의 대상이 되면 안됩니다. 오픈 API에 대한 인식에 대한 유감 대형 IT 기업의 오픈 API 방식의 기술 공개가 중소 업체를 죽인다는 인식 역시 걱정스럽습니다. 카카오가 맞춤법 API를 오픈했다고 해서, 권 교수님의 개인 사업체인 나라인포테크가 영향을 받을 일은 전혀 없습니다. 대부분 API 서비스 업체의 약관에 따르면, 오픈 API의 상업적 이용을 금지하고 있습니다. 카카오 API 약관의 경우, 오픈 API 재판매, (부분) 유료화, AP[...]



픽사(Pixar)의 6가지 스토리 텔링 구조

Thu, 11 Aug 2016 23:52:19 +0000

지난 주 JetCity Improv라는 곳에서 오신 앤드류라는 분에게서 글로벌 AWS 에반젤리스트 팀 멤버들과 함께 기업 소통 및 스토리 텔링 교육(?)을 받았습니다. 이 프로그램은 시애틀에 있는 작은 극단에서 해온 배우 훈련을 기업 프로그램으로 확장한 것이었습니다. 관련해서 나중에 따로 한번 포스팅 하기로 하구요…

체험 활동을 하던 중에 픽사(Pixar)에서 주로 사용하는 이야기 구조에 대한 실습을 했었는데, 간단히 공유하고 싶어서 적어봅니다. 우리에게 익숙한 스토리 텔링을 위해 사용하는 서사 구조 중의 하나로 6가지 구조로 되어 있습니다.

Once upon a time there was ___. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally ___.

(image)

이 구조를 통해 이야기를 만드는 것인데요. 예를 들면, 아래와 같습니다.

옛날 옛적에(Once upon a time) 해리 포터라는 소년이 있었습니다. 매일(Every day) 해리는 양부모와 사촌에게 괴롭힘을 당했습니다. 어느 날(Until One day) 해리는 자신이 마법사였다는 것을 알게되었습니다. 호그와트 학교로 가게 된 이유로(Because of that), 그가 실제로 전설적인 영웅의 아들이라고 알게되었습니다. 자신의 부모를 죽인 볼드모트가 다시 살아나(Because of that), 영생의 마법사의 돌을 노리는 것을 알고 이를 지키기 위해 필사의 노력을 합니다. 마침내(Finally), 해리는 볼드모트로부터 마법의 돌과 호그와트 마법학교를 지킬수 있었습니다.

앞의 두 가지는 이야기를 처음 꺼내면서 균형을 잡고, 중간의 두 가지는 이야기의 균형을 깨고 뭔가 변화는 양상으로 이끌고 가지만, 결국 마지막 두 가지에서 균형을 잡는 Balanced – Unbalanced – Balanced 구조라는 것입니다.

이러한 서사 방법은 해외에서 어린이들의 이야기 교육에서도 많이 사용된다고 합니다. 이와 함께 픽사의 스토리 아티스트였던 에마 코츠(Emma Coats)가 픽사 재직 시 활용했던 22가지 이야기 구조의 규칙(‘story basics’) 역시 잘 알려져 있습니다.

옛날 옛적에 제프 베조스라는 기업가가 있었습니다. 매일 월스트리트의 금융 업무가 지겨웠습니다. 그러던 어느날 아마존이라는 책 쇼핑몰을 창업합니다. 저렴한 가격을 통해 사람들에게 인기를 얻은 이유로 더 많은 물건을 팔 수 있게 되었습니다. 계속해서 사람들이 트래픽이 몰리자, 더 효율적인 인프라 운영을 위해 클라우드 컴퓨팅에 투자를 시작합니다. 마침내, 클라우드 사업은 아마존의 효자 사업이 되었습니다.

이러한 서사 구조로 예를 들어 보면,  우리 주변의 모든 것을 재미있는 이야기로 만들 수 있습니다. 동료들이나 아니면 아이들에게 가르쳐 주고 한번 이야기를 만들어 보면 어떨까요? 단순하지만 의미가 있습니다.

 

 




[ZDNET 칼럼] ‘개발자’들을 위한 인공 지능(AI) 기술 시대

Fri, 15 Jul 2016 08:30:49 +0000

인공 지능이 열풍이다. 최근 정부가 주요 IT 기업과 함께 인공 지능 연구소를 만들고, AI 인력이 양성을 위해 학교마다 인공 지능 관련 교과를 늘리는 바람에 한동안 침체였던 인공 지능 연구자들은 때아닌 호황(?)을 맞이하고 있다. 하지만, 지난 칼럼 클라우드가 선사한 인공지능 기술의 자유와 기회에서 보았듯이, 작금의 인공 지능 기술의 변화는 과거의 인공 지능 기술 패러다임과 완전히 다르다. 10년전 있었던 빅데이터 열풍을 다시 생각해보자. 과거 대용량 데이터 분석은 고성능 서버에 고가의 데이터웨어 상용 소프트웨어를 구매해야만 가능했다. 일반적인 데이터웨어 하우스(DW) 구축은 DW 전문가들과 매우 길고 오랜 기간이 필요한 구축 프로젝트에 맡겨야 했고, 그 결과는 고객의 입맛에 잘 맞지 않았다. 야후!에서 일하던 더그 커팅(Doug Cutting)이 하둡(Hadoop)이라는 오픈 소스 기반의 대용량 데이터 분산 처리 소프트웨어를 내 놓고 난 뒤, 상황은 180도 달라졌다. DW 업체와 전문가의 손을 거치지 않고도, 일반 개발자들이 저가의 장비를 분산화 하여 손쉽게 빅데이터 분석을 할 수 있게 되었다. 그 이후, 하둡 생태계는 과거와 비교할 수 없을 만큼 다양해졌으며, 수 많은 오픈 소스 소프트웨어와 지원 벤더들이 비지니스 이용에 대한 간극을 메우고 있다. 특히 클라우드 서비스가 확산되면서, 페타바이트 규모의 완전 관리형 데이터 웨어하우스인 아마존 레드시프트(Redshift), 기존 비즈니스 인텔리전스(BI) 솔루션 대비 1/10의 비용으로 비데이터 전문가라도 손쉽게 분석할 수 있는 플랫폼을 내놓기도 했다. 그렇게 빅데이터 처리 및 분석 기술은 한없이 높았던 진입 장벽을 크게 낮추었다. ■ 진입 장벽이 확 낮아진 인공 지능 기술 소위 딥러닝(Deep Learning)으로 알려진 인공 지능 기술 역시, 구글, 페이스북, 바이두, 아마존 등 다양한 글로벌 인터넷 기업이 주도하고 있다. 이들은 자사의 검색, 소셜네트워크, 음성 인식 서비스에 녹일 목적으로 투자를 지속하고 있다. 특히, 딥러닝 분야에서도 많은 오픈 소스 도구들이 활발하게 나오고 있는데, 그 중에 구글에서 공개한 텐서플로(TensorFlow)가 인기다. 3월에 시작된 텐서플로 한국 커뮤니티는 3개월만에 현재 3천명이 넘는 회원을 가지고 있고, 지난 6월 첫 오프라인 모임은 신청한지 10분에 마감되고, 200여명이 참여했다고 한다. 텐서플로를 개발한 구글의 제프 딘(Jeff Dean)은 원래 인공 지능 전문가가 아니었다. Quora에 올라온 “제프딘은 어떻게 그렇게 빨리 인프라와 시스템 엔지니어링에서 딥러닝 분야 전문가가 된건가요?”라는 질문에는 한 학생이 제프 딘에게 직접 들은 답변이 올라와 있다. ​“저는 이 분야가 잠재력이 많고 흥미로운 분야라고 생각했습니다. 뉴럴 네트워크게 대해 많이 알지 못했지만 분산환경에 대해서는 잘 알고 있었죠. 그래서 주방이던 어디던 사람(전문가)들에게 다가가 그들과 대화를 했습니다. 전문가들과 대화하고 함께 일하면 여러가지 어려운 문제도 해결할 수 있고 정말 빠르게 배울 수 있을 겁니다.” 텐서플로와 같은 오픈 소스 뿐만 아니라 클라우드 역시 진입 장벽을 낮추고 있다. 머신러닝 알고리즘에 익숙하지 않은 소프트웨어 개발자들도 아마존이 제공하는 머신러닝 서비스를 이용하면 손쉽게 데이터를 통한 학습, 모델 생성 및 추론을 해 볼 수 있다. 특히, AWS에는 대용량 스토리지, 하둡 클러스터 운영, NoSQL및 데이터웨어하우[...]



훌륭한 개발 문화의 이면(3) – 다른 팀 소스 코드를 볼 수 있는가?

Wed, 06 Jul 2016 22:30:39 +0000

조엘 스폴스키는 더 나은 소프트웨어를 만들기 위한 12 단계에서 첫번째 “Source Control(소스 컨트롤)을 사용하십니까?”을 화두로 던졌습니다. 이 12가지 질문은 진정한 소프트웨어 개발 회사 인지를 검증하는 잣대로 유명합니다. 만약 취업 중인 개발자라면 인터뷰 시 꼭 던져야 하는 중요한 질문입니다. 대부분 SW 개발 회사라면 당연히 소스 콘트롤을 사용하고 있을 것이고, 저는 좀 더 나아가 다른 질문을 던지고 싶습니다. 여러분의 회사에서는 내부의 다른 개발팀이 만드는 소스 코드를 보실 수 있나요? 아니면 보안이라는 명분으로 서로 꽁꽁 감춰 놓고 있으신가요? 개발자들은 소스 코드를 읽고, 리뷰하고 수정해 주는 일련의 과정을 거쳐 성장합니다. 따라서, 외부 오픈 소스로 공개해서 개발하는 것 까지는 아니어도 회사 내부 소스를 공유하는 것은 매우 중요한 개발 문화입니다. 개발 문화의 이면에 대한 세번째는 바로 “사내 소스 공유 문화”에 대한 것입니다. 기업내 오픈소스 개발 방식 도입記에서 밝힌 대로, 2004년 Daum에 입사 했을 때 회사 개발 프로세스 상 몇 가지 문제점이 있었습니다. 가장 대표적인 것이 소스 코드를 개별 팀이 각각 관리하고 있었을 뿐 아니라 각자 CVS, 서브버전, 소스세이프 등 다양한 소스 콘트롤을 사용하고 있었습니다. ■ 소스 코드, 우선 통합하라! 각 팀이 테스트 서버나 팀내 로컬 서버에 소스 코드를 모아 두니, 가끔 팀 별로 코드 배포 안정성에 문제가 되더군요. 뿐만 아니라, 특정 서비스가 중단되었는데 조직 개편으로 팀이 분리된 경우, 중간에 소스 코드들이 사라지는 경우가 있었습니다. 당시 소스 코드는 연구 개발 결과물로 취급하고 있어서, 이게 사라지면 회계 감사가 나왔을 때 매우 난처한 경우가 생기게 됩니다. (과거 다음은 시도 때도 없이 국세청 감사를 받았던 것으로 유명하죠.) ​ 그래서, 2005년 말에 ‘전사 소스 콘트롤 통합 및 저장소 일원화’라는 프로젝트를 맡아 하게 되었습니다. 당시 막 인기를 끌고 있던 서브버전을 선택하고, 이를 전사 인증 연동, 권한 및 리비전 관리 등의 관리 시스템을 구축하였습니다. 개별 개발팀 입장에서는 잘 쓰고 있는데, 소스 코드 이전이라는 귀찮은 일이 생기니 많은 반대에 부딪혔습니다. 2005년 Daum 전사 소스 코드 통합 저장소- 무료 10년간 운영했던 레거시(?) 시스템 특히, 당시 서브버전이 이클립스 플러그인과 연동 시 안정성 등 많은 이슈가 있어서 어려움이 많았습니다. 직접 찾아가서 문제를 해결해 주는 방법으로 다행히 수백 개나 되는 전사 소스 코드가 한 자리로 모일 수 있었습니다. 만약 아직도 회사 내 소스 코드가 한 군데 모여있지 않고, 이를 관리하는 팀이 없다면 회계 감사를 위한 산출물 관리라는 명분을 내세워서라도 꼭 해야 합니다. ■ 진정한 개발 문화는 작은 것에서 시작된다 제가 그 프로젝트에서 진정 원했던 것은 회사 내 오픈 소스 문화가 자연스럽게 정착되는 것이었습니다. 그래서 모든 개발자들이 전체 개별 레포지터리에 읽기 권한을 주는 정책을 시행하려고 했습니다. 이 역시 반대에 부딪혔죠. 명분은 중요 소스 코드가 유출된 다는 게 이유였는데, 그 이면에는 우리 팀 코드를 남들이 보게 하고 싶지 않다는 측면이 강했습니다. 유출이 우려되는 소스(검색 엔진, 광고 서버 등)는 몇 개 정해서 제외하면 될 것인데도 말이죠. 결국, 사내 공통 라이브러리에 해[...]



훌륭한 개발 문화의 이면(2) – 자율적 개발 환경을 선택하라

Mon, 04 Jul 2016 23:00:52 +0000

연재를 통해 개발 의욕을 고취할 수 있는 다양한 개발자 문화와 이를 잘 가꿀 수 있는 방법들을 살펴보고 있는데, 코딩 테스트에 이어 두 번째로 개발 환경의 자율성에 대한 문제를 이야기해 볼까 합니다. …개발자들의 노트북은 회사 규정에 따른 일괄 지급이 아니라 개발자가 정해진 예산 범위 내에서 자신의 장비를 선택할 수 있는가? 개발 장비 구매에 대한 예산은 충분한가?… 물론 다른 장비도 좋지만 맥북 프로 최고 사양이라는 의미에는 그 조직이 정말로 Core 기술 개발에 투자할 의지가 있는지에 대한 지표 였다. 임형준, 삼성의 반성…”SW인력 절반이 기초수준 실력”을 읽고 개발자에게 자신의 컴퓨터나 소모품, 개발 환경을 직접 선택할 수 있는 자유를 주는 건 개발 생산성에 지대한 영향을 미칩니다. (참고: 개발자의 생산성에 좌우하는 것들) 2006년 Daum 개발자 추천 하드웨어!라는 글에서 보시다시피 “Daum의 개발자 지원 제도 중에는 자산 포인트(일명, 개발자 마일리지) 제도가 있습니다. 매년 일정 포인트(200만원)를 지급하여 자신이 원하는 개발 환경을 만들어 사용하도록 회사에서 지급해 주는 것이죠. 사내에 있는 자산 포인트 관리 시스템으로 구매도 하고, 자산 교환으로 포인트 교환을 하기도 합니다.” 역시 제가 직접 입안하고 시행했던 제도였습니다. 당시 업계 최초이기도 하고, 10여년간 지속되어서 카카오와 합병 당시 카카오 개발자조차도 감동했던(?) 제도입니다. 2006년 당시 자산 포인트로 구매한 랩탑, 모니터, PC를 쓰는 Daum 개발자들 ■ 개발자가 진정 원하는 것은 무엇? 그 시초는 이렇습니다. 2005년에 Daum 개발자들이 진정 원하는 게 무엇인지 사내에서 심층 인터뷰를 진행했습니다. 대부분 SW나 책을 사 달라, 교육을 보내 달라, 이런 것이라고 생각을 했습니다. 그런데, 놀랍게도 대부분 메모리를 올려 달라, CPU를 바꿔 달라, 키보드가 안 맞는다 등이 대부분이었습니다. 물론 개발자용 PC 사양은 일반 직원 보다 훨씬 높을 뿐만 아니라, 필요하다면 언제든지 결제를 올려서 업그레이드가 가능했는데도 말입니다. 하지만, 개발자들은 그러한 프로세스가 있어도 특유의 귀차니즘(?)으로 인해 결제를 올리길 꺼리거나 그런 프로세스의 존재 자체로 선택권을 침해 받고 있다고 생각하고 있더군요. 그래서 구매 부서에 매년 개발 직군이 인당 얼마만큼 자산 구매 예산을 쓰는지 확인을 해보았더니, 감가상각(3년간) 추가 예산을 포함해서 인당 매년 100만원 정도가 되는 겁니다. 그렇다면, 개발자들에게 매년 200만원어치의 자산을 원하는 만큼 구매하도록 자율권을 주자는 파격적인 제안을 하였고, 당시 Daum 경영진들은 수용을 해주게 됩니다. 이 제도 덕분에 당시 네이버로 몰리던 개발자들이 Daum으로 입사 지원하는 경우도 많았습니다. 물론 초기에 큰 투자가 수반되지만 여러 가지 이점을 예상했습니다. 첫째, 구매 부서가 아무리 좋은 제품을 저가로 일괄 구매를 해 준다 하더라도, 자신의 개발 환경과 차이가 있게 마련입니다. 개발자 자신이 직접 개발 환경에 맞는 장비를 선택하는 만큼 자산 포인트 내에서 최대의 가성비 높은 장비를 선택할 것이라는 점입니다. 둘째, 이렇게 구매된 장비는 각자의 자산 포인트 안에서 (감가상각 연한에 따른 포인트 재계산을 거쳐) 서로 거래가 가능하므로, 첫 해 년도 초기 투자가 진행된 이후부터는 유휴 자산의[...]



훌륭한 개발 문화의 이면(1) – 코딩 테스트 인터뷰 제대로 하기

Sun, 03 Jul 2016 23:00:55 +0000

지난 주에 모 대기업의 자사 소프트웨어 역량에 대한 자기 반성에 대한 사내 방송 이야기가 기사화된 후, IT 업계 많은 분들이 좋은 의견을 많이 내어 주셨습니다. …개발자들이 알고리즘 문제풀이집 10권을 열심히 공부해서 구글 코딩 인터뷰 문제를 척척 풀어낸다고 하자. 팔란티어 문제도 다 풀어낸다. 그래서 뭐? 문화와 개방으로 표상되는 진짜 혁신이 없으면 그런 문제 좀 푼다고 해서 달라질 것이 정말이지, 아무 것도 없다. 임백준, 삼성전자의 소프트웨어 개발자 역량 중 …개발자들의 능력이 떨어진다고 생각하지 않는다. 아주 뛰어난 개발자도 많이 있을 것이다. 개발자 면면을 보면 아주 뛰어난 개발자가 많음에도 불구하고 SW 능력이 떨어진다는 의미는 조직, 문화의 문제가 많다고 생각한다. 임형준, 삼성의 반성…”SW인력 절반이 기초수준 실력”을 읽고 위의 두 가지 의견 이외에도 공통적으로 소프트웨어 개발자 역량에 대한 문제 보다는 사내 개발 조직의 유연한 문화를 주문하는 목소리가 훨씬 많았습니다. 이건 대기업이 아니더라도 소프트웨어 개발자로 일하시는 분들은 누구나 느끼시는 점일 것입니다. 하지만, 아무리 좋은 개발 문화라고 해도 이것을 어떻게 운용하느냐에 따라 그 결과는 달라져서 결국 맞지 않는 옷을 입듯 실패하게 됩니다. 앞으로 제 경험을 토대로 몇 가지 이러한 개발 문화를 운용해 봤던 사례를 이야기해 보려고 합니다. 그 첫번째로 이번에 이슈가 된 ‘코딩 테스트’입니다. 잘 아시다시피 글로벌 IT 기업에서는 하루 종일 4-5명이 시간을 투자해서 돌아가며 코딩 테스트 면접을 봅니다. 인터뷰에 이렇게 많은 자원을 투여하는 게 쉽지 않지만, 국내 웬만한 IT 기업에도 어느 정도 정착이 되어 있기는 합니다. ■ 결과가 아닌 과정을 보라 이전 직장이었던 Daum에서는 2004년에 처음 경력 채용 시 코딩 테스트를 (아마 업계 최초로)도입했습니다. 당시에 ‘서류 전형 – 실무 기술 – 임원/HR’의 3단계 인터뷰 과정 중 개발자 채용에만 한 단계를 더 넣게 되었죠. 목적은 단순했습니다. 실무 면접 전에 적어도 소프트웨어 개발에 대한 기초적인 사고를 하는지를 검증하는 절차를 만들어 오프라인 실무 면접의 부담을 줄여주자는 것이었습니다. (당시 마이크로소프트나 야후 등 글로벌 기업의 코딩 테스트 면접을 벤치마킹 하기도 했습니다.) 처음 시행이다 보니 아무래도 문제 출제나 평가 방법 등을 현업 개발팀에게 떠 맡기면 면접 절차가 하나 더 늘어나고, 평가 공정성도 그렇고 하니, CTO 직속팀에서 이 일을 맡아서 부담을 줄여주자는 형태로 결정을 하게 되었습니다. 당시 제가 개발자 채용, 교육, 경력 개발에 대한 스탭 업무를 담당하다보니 전사 개발자 채용 상향 평준화를 위해 코딩 테스트를 입안 했던 저에게 다시 일이 떨어지더군요. 당시 제가 목표로 했던 것은 개발자들이 코드를 짜면서 문제 해결의 과정에서 기초적 소양이 있는지 검증하는 것이었기 때문에, 매주 화요일 수요일 저녁 시간에 매번 노트북 5대씩 세팅을 하고 직접 와서 자신이 무작위로 고른 문제를 직접 푸는 방식을 택했습니다. (덕분에 매주 이틀은 항상 야근을 할 수 밖에 없었죠.) 직접 코딩 실습을 참관한 제가 문제 푸는 과정에 대한 의견을 내고, 코딩 결과물은 다른 시니어 개발자 몇 명이 교차 검증하여 종합적인 평[...]



[사족] 정부 “한국지도 쓰려면 위성영상 손봐야” 구글 “NO”

Wed, 22 Jun 2016 07:23:48 +0000

본 이슈는 최근에 ZDNet 임민철 기자님이 쓰신 정부 “한국지도 쓰려면 위성영상 손봐야” 구글 “NO” 에서 자세하게 다루기도 했고, 저도 이와 관련해서 무려 10년전에 구글과 정부의 어설픈 지도 서비스 협상법에서 의견을 낸 적이 있습니다만…

최근 구글이 다시 국내 수치 지도의 해외 반출을 요청하면서, 뜨거운 감자가 되었습니다. 10년이 넘게 끌고 온 문제인데다,  모바일 시대에 안드로이드의 기세가 드세다 보니 구글의 끊임없는 요청에 대해 우리가 대하는 태도가 마치 쇄국 정책처럼 보일 수도 있습니다.

(image)

저는 지질학 및 GIS 전공을 했고, 다음에서 지도 API를 외부에 제공하는 일을 했던 사람으로서…  최근 이슈에 대한 제 소견은 아래와 같습니다.

1.
구글이 원하는 국가 수치 지도는 수 십년간 국가 GIS 사업을 통해 수 백억의 국민 세금이 들어간 결과물입니다. 따라서, 저작권을 가지고 있는 정부 입장에서는 단순히 경제 논리로 접근할 수 없고, 안보나 국민 편익 모두를 고려해야 하는 입장입니다.

데이터 공개는 느리지만 꾸준히 계속되었습니다.  10년전에는 1:20만 이상 지도 데이터 원천 반출이 불가능했지만, 계속적으로 (1:5만까지) 대축적 지도에 대해 단계적으로 오픈을 했고, 현재 구글도 이를 가공한 SKT Tmap의 지도 데이터 및 위치 정보(POI) DB를 이미 사용하고 있습니다. 현재 구글은 좀 더 자세한 1:1000, 1:5000 정도의 (길찾기를 위한) 소축적 지도를 달라는 요청입니다.

하지만, 이러한 상세 지도가 한번 해외 반출되기 시작하면, 다양한 업체로 부터 반출 요구가 나오기 때문에 첫 사례에 신중할 수 밖에 없겠죠. 계속 해외 반출 사례가 나오다 보면, 수치 지도 데이터가 어떤 경로로 북한으로 유입될 수도 있구요. 뭔가 특별한 예외를 위한 반출 조건이 필요합니다.

2.
그러한 반출 조건 중 하나가 (국가 안보를 위한) 구글맵 및 위성 사진 변경 요청일 수 있습니다. 우리 나라 뿐만 아니라 안보 상황이 남다른 인도를 비롯해서, 태국이나 러시아에서도 제기된 문제입니다. 현재 인도 같은 경우, 위성 지도 뿐만 아니라 테러 위험에 따른 구글 스트릿뷰에 대한 촬영도 거부하고 있는 중입니다. (한국은 스트릿뷰 촬영 중 개인 정보 수집 이슈로 중단됐지만요…)

또한, 그런 요청을 하는 나라는 유독 우리 나라 뿐만 아니라 이미 언급한 다른 나라들도 많고, 이스라엘 같이 미국 우방으로서 외교적으로 해결한 사안도 있습니다. 따라서, 국가 마다 법이 다르고, 생각이 다르지만 불가능하지는 않습니다. 만약, 글로벌 위성 지도에 대한 보안 시설 위성 처리에 대한 협상이 성공하는 경우, (전 세계 유일하게 분단 국가에 휴전 중인 한반도에서) 확실히 안보에는 큰 도움이 될 것입니다. 그 지렛대를 미리 포기할 필요는 없다고 봅니다.

3.
구글이 정말 길 찾기 서비스가 필요했다면, 이미 국내에 서버를 두고 서비스를 했을 겁니다. 2007년에도 (국내 법인이 있었던) 야후!코리아가 이런 방식으로 서비스를 했었구요. 그만큼 구글 입장에서 국내 지도 서비스가 가치나 우선 순위가 높지 않았음을 반증합니다.

클라우드 시대에 기술적으로 불가능하다는 건 약간 핑계에 가깝구요. 한국만 지도 서비스 상 예외를 두는 서버나 코드를 개발한다는 건 그 만큼 예외적인 비용 투자가 동반 되어야 하는데 그건 자사 이익에 부합하지 않겠죠. 법규 아래 기업의 영리 활동을 위한 투자는 결국 기업의 선택의 몫입니다.

물론 글로벌 시대에 맞는 데이터 개방은 필수적이고, 외국인에 대한 서비스 품질도 중요하겠지만 그렇다고 안보 이슈나 데이터 주권도 순위가 낮은 게 아니니 어쨌거나 핫이슈인데 지혜롭게 풀었으면 좋겠네요.




StatCounter를 다 믿지 마세요! (2)

Wed, 22 Jun 2016 06:39:12 +0000

최근에 StatCounter를 인용해서 구글 인터넷 브라우저 ‘크롬’… 한국서도 ‘MS 익스플로러’ 추월 같은 보도가 나오고 있지요. 물론 IE 점유율이 떨어지고, 다양한 웹 브라우저가 늘어나는 건 좋은 소식이지만, 보도 기사가 여전히 통계 오류가 있는 사이트를 참고하는 건 문제가 있습니다.

StatCounter의 최근 1년간 데스크톱 웹 브라우저 점유율을 보면, 실제로 최근 구글 크롬이 IE를 추월한 것으로 나옵니다.

(image)

하지만, 같은 기간 데스크톱 검색 엔진 점유율을 보면, 구글이 네이버보다 점유율이 훨씬 높은 것으로 보입니다. 이것은 국내 어떤 데이터와도 맞지 않고, 따라서 신뢰할 만한 자료라고 생각하지 않을 것입니다.

(image)

이는 StatCounter를 다 믿지 마세요!에서도 이미 언급한 바 있습니다.

같은 날짜의 데스크톱 검색 엔진 점유율에서 네이버 50%, 구글 40%, 다음 10% 그리고 모바일 검색에서는 90%가 구글로 나오는 것으로 봐서는 로그 데이터를 제공한 곳은 구글 검색이 활발한 사이트들일 가능성이 높다고 판단됩니다.

오히려 Korea HTML5 웹 브라우저, 운영체제 이용률이 조금 더 현실에 가깝지요. 공짜 보고서는 좀 더 신뢰성을 잘 파악하고, 보도해 주었으면 좋겠습니다.




Tistory에서 워드프레스로 URL 그대로 이사하기

Wed, 15 Jun 2016 23:00:30 +0000

지금으로 부터 10년 전(2006년) Daum의 서비스형 블로그 플랫폼인 티스토리가 출범할 때, 개밥먹기(Dog Fooding)의 일환으로 티스토리 블로그 분점을 내었습니다. 티스토리는 제가 출범할 때 부터 영향을 많이 끼친 서비스이고, 2016년 5월 현재도 국내 웹 사이트 순위 3위에 점하는 대단한 트래픽을 가지고 있습니다. 과거 다음에 재직할 때, 내부의 다양한 채널로 정말 많은 제안과 쓴소리를 했지만 아쉽게도 티스토리에 대한 투자는 잘 이루어지지 못했습니다. 합병 후, 카카오에서도 모바일 대세에 밀려 티스토리를 PC 웹의 유물처럼 느끼는지 여전히 서비스 개선은 지지부진 합니다. 물론 저도 2014년 6월 이후로 더 이상 글을 쓰지 않은 블로그였지만, 600여개 가까운 글을 썼던 보금자리였던 터라 스스로 콘텐츠를 직접 제어할 수 있도록 이전을 하기로 생각했습니다. 요즘처럼 하수상한 시절에 마치 티스토리가 문을 닫을 노파심은 아니고, 제가 평소에 가지고 있는 데이터 소유에 대한 평소 철학(인디웹(IndieWeb)을 아십니까? 참고)에 따른 것임을 양지해 주시기 바랍니다. 이 글은 설치형 워드프레스를 운영하시는 방법에 대해 익숙하신 분들을 대상으로 합니다. 설치형 운영에 대한 방법 및 질의 응답은 한국워드프레스 사용자모임을 통해서 하시기 바랍니다. 우선 티스토리에서 워드프레스로의 이사는 많은 분들이 이미 해 보셨고, 관련 글도 구글 검색을 하면 많이 나옵니다.(예: 티스토리에서 워드프레스로 (WordPress) 이사하기 (TTXML)) 이 글의 목적은 기존 이사를 하시면서 생긴 문제점 중 URL이 그대로 보존 되도록 하는 방법에 초점을 맞추고 있습니다. 티스토리에서 블로깅 좀 했다하면, 아래와 같이 2차 도메인을 설정하고 (한글 URL의 경우 링크가 약간 길어지는 문제 때문에) 숫자로된 URL을 제공하는 방법으로 설정을 하셨을 겁니다. 이전 후에도 그대로 URL이 보존되고, (티스토리가 문을 닫기 까지) 리다이렉션하는 방법을 포함합니다. 1. 티스토리 블로그 데이터 백업하기 우선 티스토리의 환경 설정 ▶ 데이터 관리 에서 TTXML 파일을 백업을 받습니다. 복원을 안되도록 막았지만, 아직까지 백업을 해주는 것만으로 감사합니다. 2. TTXML Importer 수정 버전 다운로드 많은 분들이 이사에 사용하신 워드프레스 플러그인은 TTXML Importer입니다만… URL을 보존해서 사용하려면 제가 약간 수정한 버전을 다운로드 받으시면 됩니다. 제 Github 저장소에서 ZIP 파일 다운로드가 가능합니다. 3. 워드프레스로 백업 데이터 가져오기 깨끗하게 설치된 워드프레스에서 TTXML Importer 플러그인을 plugins 디렉토리에 풀고 난 후, 활성화한 후에 도구 ▶ 데이터 관리를 보시면 TTXML이 있는 것을 보실 수 있습니다. 제가 숫자로된 URL을 그대로 가져오기라는 설정을 항상 체크 박스를 해두었습니다. 해제하시면, 한글 제목 URL로 가져오게 되니까 유의하시기 바랍니다. 그런 다음 TTXML Backup XML 파일의 위치를 지정합니다. (첨부 파일까지 포함하면 기본 2MB는 넘어갈 것이기 때문에, 가급적 FTP로 올린 후 로컬 디렉토리로 지정하시는 것을 추천합니다.) 4. 워드프레스 URL 및 티스토리 리다이렉트 설정하기 이제 마지막으로 워드프레스에서 설정 ▶ 고유주소를 선택한 후, 사용자 정의를 통해 %POST_NAME%으로 지정합니다. 그렇게 되면, URL은 기존[...]



[ZDNET 칼럼] 서버리스(Serverless)가 온다!

Mon, 13 Jun 2016 18:17:19 +0000

지난 칼럼 ‘클라우드 기술에 대한 세가지 패러다임 변화‘ 에서 ‘서버 없는 클라우드 함수의 등장’이라는 변화를 소개했다. 이러한 새로운 패러다임은 개발자들에게 큰 수고와 비용 없이도 좀 더 빠르고 민첩하게 다양한 애플리케이션을 만들고, 서비스 운용을 위한 확장성 및 가용성에 대한 수고와 비용을 없애는 방향으로 바뀌고 있다. 이러한 변화를 가장 극적으로 보여준 것이 바로 지난 5월말 뉴욕에서 있었던 서버리스 컨퍼런스(Serverless Conference)다. 일반적으로, 회자되는 기술의 유행 방식은 선두 주자가 혁신적인 서비스를 내면, 경쟁적으로 유사한 서비스가 만들어지고, 오픈 소스로 된 관련 도구가 증가하면서 개발자들이 여기에 동조하고, 콘퍼런스에서 다 같이 만나는 패턴인데,이는 과거에도 종종 있었다. 2014년 AWS람다(Lambda)가 이러한 개념을 처음 선 보인 이후로, 많은 클라우드 업체들이 이를 벤치마킹한 서비스를 줄줄이 내놓고 있다. 많은 개발자들은 관련된 코드 예제들을 오픈 소스로 공개하고, 급기야는 Serverless FRAMEwork, CloudiaJS 같은 서버리스 오픈 소스 개발 프레임워크가 계속 나오고 있다. AWS에서 Lambda와 API Gateway 서비스 개발을 총괄하고 있는 팀 와그너(Tim Wagner)는 서버리스 콘퍼런스 키노트 발표에 앞서 물리 서버를 부숴버리는 상징적인 퍼포먼스를 보여 주기도 했다. 물리적 서버를 부수는 퍼포먼스를 하고 있는 팀 와그너 출처: @samkroon ■ Serverless != No Server 물론 서버리스(Serverless)라는 말 자체가 서버가 필요 없다는 뜻은 아니다. 클라우드에서도 서버는 존재하고 있고, 다만 고객이 스스로 관리해야 하는 서버 혹은 콘테이너가 제로(0)에 수렴한다는 의미다. 따라서, 서버리스란 오로지 이벤트에 따라 동작하는 클라우드 기반의 나노 수준 (최근 회자되는 마이크로서비스가 가진 크기를 생각해서) 서비스 단위의 프로그램 코드만을 개발하고 배포에 집중한다는 의미이다. 기존의 PaaS(Platform as a Service)는 복잡한 모놀리식(Monolithic) 애플리케이션을 지원했다는 점에서, 무상태(Stateless)는 서버리스의 특징과 대비된다. 이유는 간단하다. 더 빠르게 움직이기 위해서다. 이러한 특징은 인프라 설치, 운용, 확장성 고려, 복잡한 배포 및 모니터링 등 많은 관리 업무를 줄이고, 민첩하게 만들고 배포하려는 회사 혹은 팀에게 적합하다. 예를 들어, AWS Lambda는 가장 선두에 있는 서비스로서 Node, Java, Python 코드를 올리기만 하면, 코드가 실행될 때 마다 5분 안에 실행하면서 100ms 단위로 과금한다. 다른 AWS 서비스의 이벤트를 처리(예를 들면, Amazon S3에 이미지가 올라오면 썸네일을 만드는 기능을 동작)하거나, Amazon API Gateway로 들어오는 HTTP 요청에 대해서도 실행할 수 있다. 올려진 코드에 대한 버전 기능, 배치 작업을 위한 Cron 기능 등을 제공하고, 매월 100만 밀리세컨드에 대해 무료로 제공하기에 테스트 개발에도 적합하다. 모바일 앱을 위한 서버없는백엔드 아키텍처 사례(출처: AWS 한국 공식 블로그) 따라서, Amazon API Gateway와 AWS Lambda를 조합하고, 여기에 Amazon 기존 서비스를 연계해서 새로운 아키텍처를 구성할 수 있는데, 이것을 소위 ‘서버리스 아키텍처’라고 부르고 있다. (마치 다양한 요리를 할 때 필요한 재료가 필요한 것처럼, AWS는 최소 단위(primit[...]



[ZDNET 칼럼] JAWS 커뮤니티가 우리에게 일깨워 준 것들

Sun, 29 May 2016 18:09:41 +0000

지난 주 토요일(5월 21일)에는 클라우드 분야를 선도하는 아마존웹서비스(AWS)를 배우고, 사용하는 한국과 일본의 개발자 커뮤니티 간의 교류 모임이 서울에서 개최되었다. 2009년에 시작해 현재 50개의 지역 및 분야별 지부를 가진 세계 최대 AWS 사용자 모임인 일본 JAWS의 리더 11명이 한국을 찾아 AWSKRUG의 회원들과 만났다. JAWS는전세계적으로 56개국 270개도시에서 18만여명이참여하고있는글로벌 AWS 사용자 모임 중 가장 큰 규모다. JAWS 는 지부별 스터디 모임뿐만 아니라 매년 1천여명이 넘게 참여하는 자체 커뮤니티 행사도 진행할 정도로 인기 있는 일본 내 개발자 커뮤니티 중 하나다. 이날 행사에서 5년 전인 2011년 3월 이후 일본 동경에 AWS 리전이 구축된 이후로 클라우드 컴퓨팅이 개발자의 삶을 어떻게 바꾸어 주었는지 알려주는 선배로서의 경험담을 들려 주기도 했다. 이번 모임이 국내 개발자 커뮤니티에도 의미하는 바가 있을 것으로 생각되어 공유한다. ■ JAWS 대표 리더는 시골 개발자(?) 수천 명의 회원을 가진 JAWS UG의 올해 대표 리더는 타쿠야 타치바나(Takuya Tachibana). 그는 일본에서도 시골로 통하는 아오모리현에 있는 한 작은 회사의 개발자이다. 그는 도쿄가 아닌 시골의 작은 지부 리더이면서 알려지지 않은 회사의 개발자이다. 하지만, AWS 클라우드를 통해 어떻게 저렴한 비용과 인력으로 고객사 서버를 죽지 않고, 안전한 보안과 유연한 개발 환경을 구축할 수 있었는지에 대해 자신의 경험을 나누었다. 소도시에서 AWS 활용 사례를 발표하는 Takuya 대표 리더 그는 AWS의 EC2 t2 인스턴스 타입을 통한 서비스 효율화와 AWS 람다(Lambda)를 통한 서버가 불필요한 작은 기능에 대한 프로세스 개선 시도를 통해 클라우드에 대한 통상적인 시각을 뒤집었다. 세션에 참석한 참가자는 “우리는 클라우드라고 하면 트래픽과 데이터가 많은 대형 엔터프라이즈나 B2C, 게임 도메인을 생각하는데,시골회사의 적은 양의 트래픽, 적은 숫자의 사용자라고 할지라도 죽으면 안되는 소중한 시스템이 있다는 것을 일깨우게 해준 사례에 감사하다. 스몰 스펙 인스턴스로 심지어 서버리스 환경에서 고객의 시스템을 만든 JAWS의 대표 리더 타치바나씨의 세션은 거품이 잔뜩 낀 허세 만발의 우리의 모습을 반성하게 해 주었다.”고 세션 소감을 전하기도 했다. ■ 커뮤니티 활동은 개발자의 삶을 바꾸었다 오사카 지부의 도시유키 곤파루(Toshiyuki Konparu) 및 야마카타 지부의 세이지 아카츠카(Seiji Akatsuka) 리더는 AWS 커뮤니티 활동을 통해 많은 사람들의 삶이 바뀌었다고 강조했다. 클라우드 기술이 대세가 되면서, 본인 뿐만 아니라 커뮤니티에 참여했던 많은 사람들이 배움과 인간 관계 확대를 통해 더 좋은 직장을 얻고, 창업에 성공하고, 심지어 커뮤니티 내에서 결혼까지 한 사례도 있다고 한다. 이들은 개발자들에게 클라우드 컴퓨팅 기술은 기존 IT의 업무를 모두 새롭게 다루기 때문에, 매우 광범위하고 다양해서 혼자서 배우기가 쉽지 않고, 커뮤니티에 참여함으로서 현재 수준과 목표를 정할 수 있는 장점이 있다고 전했다. 특히, JAWS에서는 새로 참여하는 커뮤니티 멤버들에게 항상 두가지를 강조한다. 첫째, 스터디 및 모임이 끝나면 소감이나 요약을 항상 블로그나 SNS[...]



제주 도민이라면 꼭 하는 12가지 (2)

Tue, 26 Apr 2016 23:00:21 +0000

제주 도민이라면 꼭 하는 12가지 1탄에 이어 오늘은 제주 도민이라면 꼭 하게 되는 (그래서 그리운) 12가지 중 나머지 여섯 개를 소개합니다. (만약 여러분이 계절에 따라 제주로 여행을 하신다면 한번쯤 해보시길 권해 드리는 아이템이기도 합니다.) 7월 해변 수영 즐기기 제주 여행을 더 멋지게 하는 방법에서도 소개했지만, 제주는 멋진 해변이 정말 많이 있습니다. 7월은 아이들과 해변 가기에 딱 좋은 시기이고, 주말 마다 꼭 바닷가를 찾았습니다. 휴가철이 되면 유명 해수욕장에 많이 몰리게 되고 사람들이 많아져 불편합니다. 하지만 숨겨진 보석 같은 해수욕장들이 많이 있는데, 제주 서부에는 대표적으로 곽지 해수욕장이 있습니다. 이곳은 지하 용천수가 올라와서 차가운 민물과 바닷물이 만나고, 돌들이 연못처럼 만들어서 아이들이 놀기에 좋습니다. 제주 동부에는 우리가 잘 다녔던 함덕 해수욕장이 있는데, 간조때는 주변 수 km가 백사장으로 들어 나는 곳입니다. 좀 더 동쪽으로 가면 하도 해수욕장이 있습니다. 넓고 얕은 해수욕장을 원한다면, 남동부의 표선 해수욕장도 추천합니다. 특히 아이들을 데리고 물놀이 하기에 아주 적격입니다. 여름에 바닷가를 찾을 때 가장 중요한 것은 물때입니다. 간조 시에는 백사장이 넓고 훨씬 놀기 좋기 때문인데요. 만조에서 간조로 나가는 시기에 방문하면, 모래사장 위에 신발이나 짐이 떠내려가거나 하는 불상사도 막을 수 있습니다. (제주 물때 참고 사이트) 8월 해변 캠핑하기 아이들이 어릴 때는 물에서 노는 것이 즐거웠지만, 좀 크고 나니까 밖에서 하루 자면서 밤 바다고 보고 군것질도 하는 경험을 더 좋아하더군요. 8월 날씨가 맑은 날엔 해변으로 야영을 하러 갑니다. 엄청난 캠핑 장비는 아니고, 그냥 던지면 펴지는 원터치 텐트 하나랑 침낭에 베개 들고 시외 버스타고 주변 해변 갑니다. 저녁 먹고 가서, 잠만 자고 아침에 일찍 집에 와서 씻지요. 협재, 곽지, 이호, 삼양, 함덕, 김녕, 월정리, 표선 등 모든 해변을 돌아가면서 캠핑을 합니다. 어디를 가더라도 아이들과 제주 버스를 탑니다. 대화 시간도 친밀도도 늘어 납니다. 시간표에 맞추어 여유 있고, 계획적인 여행이 가능합니다. 제주에 살면서도 관광객의 느낌을 얻으면서, 친밀해 질 수 있는 건 역시 캠핑이지 않나 싶네요. 다만, 제주의 해변 밤 날씨는 매우 변덕이 심하고 (비바람이 칠수도 있음), 중고교생들이 밤새 노는 곳이 많기 때문에 (어디서나 그렇겠지만) 밤잠을 설칠 우려는 높습니다. :) 9월 회사 탐방/가을 운동회 과거 가을 운동회는 시골 동네의 가장 큰 연중 행사 중에 하나였죠. 지금은 서울에서 가을 운동회에 아빠 엄마가 다 와서 함께하는 경우는 드물것 같은데, 제주에서는 아이들과 학교에서 하는 운동회에 참여했습니다. 학교가 걸어서 5분 거리라서 쉽게 참여할 수도 있고, 맛있는 점심을 같이 먹기도 합니다. 또한, 연중 주요 일과 중 하나는 아이들을 제가 일하는 회사에 데려 오는 것입니다. 일단 다음의 제주 캠퍼스 건물의 경우, 볼것도 많고 할 것도 많기 때문에 아이들이 회사에 와도 심심하지 않습니다. 통근 셔틀 버스를 타고 와서 하루 종일 공부도 하고, 게임도 하고 아빠랑 같이 회의도, 가끔[...]



[ZDNET 칼럼] 금융권에 불어오는 클라우드 도입의 큰 흐름

Tue, 26 Apr 2016 18:04:02 +0000

금융 산업의 클라우드 도입 열기가 더욱 뜨거워지고 있다. 원래 금융 산업은 데이터 보안과 소유에 대한 규정 준수를 위해 물리적 인프라에 대해 투자해 왔지만 클라우드 도입에 적극적이지 않았다.

그러나, 전 세계적으로 소위 핀테크(FinTech)라 불리는 온라인 금융 서비스 경쟁이 치열해지면서,클라우드 도입은 더욱 탄력을 받고 있다. 좀 더 많은 기업 자원을 비즈니스 혁신에 필수적인 핵심 애플리케이션에 투입하기 위해 클라우드 도입에 적극 나서고 있는 것이다. 또한, 클라우드 컴퓨팅 서비스에서도 엔터프라이즈 기업이 요구하는 높은 보안 관리 기능을 속속 선보임에 따라 기존의 간극은 크게 줄어들고 있다.

캐피탈원, 자체 데이터 센터 8개에서 3개로 줄여
미국 대형 은행인 캐피탈원(Capital One)은 신용카드, 당좌 예금 계좌 및 보통 예금 계좌, 오토론(자동차대출), 보상금, 그리고 일반 소비자 및 기업 대상 온라인 뱅킹 서비스를 제공하고 있다. 캐피탈원의 기술 전략 핵심에는 아마존웹서비스(AWS) 클라우드가 있다. 회사는 AWS를 사용함으로써 2018년까지 데이터센터 개수를 8개에서 3개로 줄인다는 계획을 갖고 있다. 실제 캐피탈원은 새로운 주력 서비스인 모바일 뱅킹 시스템을 포함한 대부분의 핵심 시스템들을 개발하고 테스트하거나 운용하는데 AWS의 거의 모든 서비스를 활용하고 있다.

(image) 캐피탈원의 클라우드 전략에 대해 발표하는 롭 알렉산더 CIO (출처: AWS)

작년 re:Invent 2015 키노트 발표 시 롭 알렉산더(Rob Alexander) 캐피탈원 최고정보책임자(CIO)는 “현재 금융 산업은 최악의 사이버 범죄 위험에 노출돼 있다. 캐피탈원은 자체 데이터센터보다 AWS 클라우드에서 더욱 안전하게 서비스를 제공할 수 있다고 믿고 있으며, 더욱 안전한 보안 모델을 만들기 위해 AWS와 긴밀히 협력하고 있다”고 말했다.

미래에셋, 국내 금융권 최초로 ‘클라우드 퍼스트 전략’ 구사
2015년 5월 AWS 클라우드를 통해 국내 금융권 최초로 클라우드형 웹서버시스템을 도입한 미래에셋자산운용은 국내외 데이터 센터를 클라우드로 일원화 하면서 연간 관리 비용을 50% 이상 절감했다. 특히, AWS 도입 이후 고객들의 접속 속도가 상당히 개선되었으며, 자체 시뮬레이션 결과 해외 접속자의 경우 약 3배의 속도 개선 효과가 있는 것으로 나타났다.

(image) 보안에 대한 역할 분담을 설명하는 김완규 미래에셋 자산 운용 CIO (출처: AWS)

지난 AWS 클라우드 2016 키노트 발표자로 나선 미래에셋자산운용 김완규 정보기술(IT)본부 상무는 보안에 대해서도 “자체 데이터센터 보다 탄탄하고 안정감이 있다는 느낌을 받았으며, 외부의서버 분산공격에 대해서도 우리 웹 사이트는 AWS 클라우드 프론트 뒷단에 있기 때문에 매우 안전한 것으로 평가됐다”고 강조했다. 미래에셋자산운용은 앞으로 다양한 펀드 상품에 대한 위험 관리 분석, 인트라넷 시스템 및 대규모 고성능 컴퓨팅과 같은 임무 수행에 필수적인 워크로드를 위해 AWS 사용 확장을 고려하고 있다.

핀테크 스타트업 스트라이프, 핵심 결제 서비스에 집중
뿐만 아니라, 미국의 유명 핀테크스타트업인 스트라이프의 경우, 2011년부터 이미 AWS 클라우드를 기반으로 서비스를 개시했다. AWS에서는 클라우드 인프라에 대해 카드 업계 보안 규정인 PCI(Payment Card Industry)를 이미 준수하고 있을 뿐만 아니라, 글로벌 보안 인증과 감사 규정 준수를 위한 다양한 클라우드 보안 서비스 선보이고 있었다. 회사는 이를 기초로 더 빠르게 서비스를 개시할 수 있었다.

처음 시작하는 핀테크 스타트업인 스트라이프 입장에서 이러한 금융 보안 규정 준수를 위해 많은 자원을 들이는 데 어려움이 있었다. 하지만, 스트라이프는 AWS 클라우드 보안 및 규정 준수를 위한 서비스를 통해 개발자들이 결제 서비스 전용 웹 사이트 및 모바일 애플리케이션을 빠르게 만들어 제공할 수 있게 되었다. 나아가, 결제 서비스 확대에 따른 트래픽을 감당할 수 있는 확장성 이라는 혜택을 얻게 되었다. 이를 기반으로 개발 생산성 향상 및 매출 확대의 기틀을 갖출 수 있었다.

이렇듯 국내외 기존 금융권에서부터 새로운 핀테크 스타트업까지 AWS 클라우드를 통해 보안 및 규정 준수 뿐만 아니라 서비스 혁신과 빠른 변화 선도라는 두 마리 토끼를 모두 잡는 데 성공한 혁신 사례가 더욱 늘어나고 있다. 우리 나라에서도 핀테크 산업에 있어서 클라우드의 이점이 주는 장점을 빨리 취함으로써 다양한 금융 및 지불 서비스 혁신이 나오길 기대해 본다

-원문: http://www.zdnet.co.kr/column/column_view.asp?artice_id=20160427091750




제주 도민이라면 꼭 하는 12가지 (1)

Sun, 10 Apr 2016 23:00:32 +0000

제주를 떠나 서울 살이를 다시 시작한 지 1년이 지났습니다. 많은 분들이 10년이나 살았던 제주가 그립지 않나라고 물어보시는데, (아이들도 서울 생활이 새롭기 때문에) 가족들도 그렇고 현재로는 많은 점에서 만족하고 있습니다. 다만, 제주에서는 한해를 보내면서 일상적으로 매번 하던 것들이 있었는데, 서울에서는 어려운 것들이 있습니다. 오늘은 제주 도민이라면 꼭 하게 되는 (그래서 그리운) 12가지를 한번 이야기해 보려고 합니다. 만약 여러분이 계절에 따라 제주로 여행을 하신다면 한번 해보시길 권해 드리는 아이템이기도 합니다. 1월 눈썰매 타기 제주는 겨울이 따뜻하지만 의외로 눈이 많이 오는 섬입니다. 일 년에 몇 번은 폭설이 내리는데, 가끔 제주 시내에도 많이 쌓여서 교통 마비가 오기도 합니다. 특히 800m이상 고지에는 쌓인 눈이 잘 녹지 않아, 겨울 중엔 언제나 눈 쌓인 한라산을 볼 수 있습니다. 이렇게 눈이 내린 날 다음은 어김없이 제주 중산간 지역으로 아이들과 눈썰매를 타러 갑니다. 구제주 쪽에서는 대표적으로 제주대 교정이나, 제주마 방목지”(흔히 목장), 신제주쪽에서는 어승생 수원지 주변 방목지와 구릉을 이용할 수도 있습니다. 제주마방목지에서 눈썰매 타기 (2010) 이른바 자연 눈썰매장은 눈이 녹기 전에 눈썰매를 타러 온 아이들과 부모들로 입추의 여지가 없을 정도입니다. 다들 집집마다 눈썰매 한 두개씩은 가지고 있습니다. 현장에 가보면 눈썰매 대여를 해주거나, 오뎅과 떡볶기를 파는 상인들도 총집합을 합니다. 제주에 여행왔다가 폭설을 만났다면, 제주 자연 눈썰매장을 찾아 보는 것은 좋은 추억이 될 것입니다. 2월 오름 불 놓기 구경 정월 대보름 제주에서는 매년 들불 축제라는 것이 열립니다. 중문 단지로 가는 도로변에 위치한 새별 오름이라는 곳에서 개최하는데, 축제의 하이라이트는 마지막 날 산 정상에서 펼쳐지는 불꽃 놀이와 그 이후, 오름 전체를 불로 태우는 것입니다. 제주 들불축제에서 (2011) 일단 오름에 불을 놓는 것이기 때문에 규모 자체도 엄청 크고, 불꽃 놀이도 매년 더 화려해 지고 있어서 관광객들도 많이 참여합니다. 다만, 행사장에 들어가기 위해서는 렌트카와 도민 차량이 뒤엉켜 명절 귀성길을 막먹는 교통 정체를 각오해야 할 정도로 많은 사람이 오기도 합니다. 그래서, 제주도민들은 도에서 준비한 무료 셔틀 버스를 이용하는 경우가 많습니다. 축제 홈페이지에 가면, 미리 셔틀 버스가 어디에서 출발하는지 언제 다시 돌아오는지 공지를 하니까 뚜벅이 관광객들도 참고하시면 좋을 듯 합니다. 3월 왕벚꽃 구경하기 머니머니 해도 우리 나라 처음으로 왕벚꽃이 피는 시기인 3월 중순은 제주 봄의 시작이라고 할 수 있죠. 제주가 원산지인 왕벚꽃 나무가 알려지면서, 도내 곳곳에 군락지나 가로수로 조성해 두기 시작했습니다. 대표적으로 구제주 종합운동장 인근은 축제가 열리는 곳임과 동시에 많은 왕벚꽃 나무를 볼 수 있구요. 제주시 전농로 거리, 제주대 입구 부터 정문까지는 벚꽃 명소입니다. 최근에는 애월 장전리나 광령리 무수천 등에도 벚꽃 나무를 많이 심었고, 한라산 중턱의 산간도로는 4월 둘째주까지[...]



[ZDNET 칼럼] 데브옵스를 위한 지름길, 챗옵스를 아시나요

Sun, 10 Apr 2016 17:57:12 +0000

클라우드 시대에 데브옵스(DevOps)는 선택이 아니라 필수이다. 인프라 자원을 소프트웨어 코드로 관리하고, 모든 개발 영역에서 자동화를 이루며, 이를 위한 SW 도구를 사용하여 협업을 통해 개발과 운영의 간극을 메워 좀 더 빠르게 비즈니스 혁신을 이루는 것은 소프트웨어 서비스 영역에서는 최근 몇 년간 가장 중요한 베스트 프랙티스가 되었다. 이제 시스템 운영자는 개발팀의 요청에 맞추어 기존 데이터 센터에 서버를 설치하고, 고장난 서버 및 하드 디스크 교체, 복구하는 일을 할 필요가 없다. 클라우드 환경에서 API 만으로 이 모든 일을 자동화 할 수 있는 프로그램을 짜는 것이 주요 업무가 되었다. 이렇게 되면, 운영자는 몇 대의 서버나 수천대의 서버나 시스템에 대해 신경 쓸 필요가 없게 된다. 이러한 베스트 프랙티스는 본디 개발(Dev)과 운영(Ops)을 나눌 수 없는 스타트업(Startups)이나 넷플릭스 같은 클라우드 올인(All-in) 기업에서 출발했다. 따라서, 데브옵스란 하나의 조직이나 직군이라기 보다는 기업 내 전체 개발에서 부터 배포 및 운영까지의 프로세스와 문화를 일컫는 것이다. 인력과 소프트웨어, 개발 프로세스나 인프라를 의미하기도 하지만, 이것이 성공적으로 도입되기 위해서는 조직 문화나 의사 결정 체계도 바꾸어야 한다. 아마존닷컴은 일찍이 각각의 세부 서비스 기능을 잘게 쪼개, 이를 맡은 개별팀이 자율성, 주인 의식과 열정을 가지고 빠르게 개발 및 운영하도록 조직 구조를 만들었다. 또 개발의 많은 부분을 자동화 하고 시스템적 해결 도구를 제공했다. ■ 실시간 운영을 위한 챗옵스(ChatOps)의 발현 데브옵스의 문화적 동인 중 가장 중요한 것이 실시간 커뮤니케이션이다. 많은 회사들이 이미 PC 혹은 모바일 메신저를 통해 동기화된 방식의 커뮤니케이션을 해 왔다. 최근 모바일 환경이 발전하면서, 그룹 채팅이라는 비동기적 방식의 경향도 더 뚜렷해졌다. 국내 대표 인터넷 기업인 카카오의 경우, 회사 창업 초기부터 게시판과 답글 형식의 그룹웨어를 지양하고 아예 비동기식 메시지와 채팅 방식의 업무 앱을 사용해 왔다. 기존 그룹웨어에 익숙한 사람에게는 혼란스럽지만, 과거 IRC(Internet Relay Chat)을 사용해 본 경험이 있는 개발자라면 빠르게 적응할 수 있었다. 개발과 운영이 합체된 팀에서도 서비스 장애 상황이 발생했을 때, 문제를 빠르게 해결하기 위한 도구가 필요하다. 물론 VPN을 연결해서 서버에 접속하고, 문제를 파악하고 콘솔과 대시보드를 보면서 일일이 해결 하는 방법도 있다. 하지만, 실시간 채팅을 통해 상황을 파악하고 이를 빠르게 처리할 수 있도록 도와 주는 역할을 하는 도구가 절실해졌다. 2013년 깃허브(Github)의 개발팀은 원격 근무 환경에서 휴봇(Hubot)이라는 채팅봇을 통해 SW 자동 배포, 모니터링, 장애 처리를 가능하게 하는 ‘챗옵스(ChatOps)’라는 개념을 처음 소개했다. 오픈 소스로 만들어진 휴봇은 팀원들의 대화 중에 각종 정보를 제공해 주며, 문제를 빠르게 인지하고 필요한 경우 해결 할 수 있도록 하는 각종 명령어를 수행해 준다. 마치 예전 ‘심심이’를 연상하게 해 준다. 부수 효과로 새로운 개발자[...]



[ZDNET 칼럼] 클라우드가 선사한 인공지능 기술의 자유와 기회

Tue, 22 Mar 2016 17:45:55 +0000

한바탕 인공지능(Artificial Intelligence)에 대한 열풍이 지나갔다. 과연 미래에 인공지능이 인간을 능가 할 것인가에 관해 많은 사람들이 관심과 동시에 우려를 표했다. 체스, 장기 그리고 바둑 같은 복잡한 게임에서 사람을 이기는 기계가 나오고, 퀴즈 대결 같은 지식 정보에서도 사람을 능가하는 인공지능의 발전은 SF 영화에 등장하는 기계를 장악하는 빅브라더의 출현, 또는 사람들의 일자리가 없어지지 않을까 하는 막연한 우려를 만들기에 충분했다. 사실 AI 개념은 매우 고전적인 것으로,이른바 기계가 스스로 배우는 기계 학습(Machine Learning)의 개념으로 많은 알고리즘이 발전되어 왔다. 2006년 이후로 대용량 데이터를 처리할 수 있는 하드웨어의 발전과 빅데이터의 힘 그리고 소위 딥러닝(Deep Learning)이라고 불리는 인공 신경망 알고리즘의 뚜렷한 개선 기법이 나온 후 많은 글로벌 IT 기업이 인공지능을 이용한 서비스 개발에 뛰어들고 있다. ■딥러닝, 고성능 컴퓨팅과 복잡한 기술 장벽? 딥러닝의 가장 대표적인 사례들이 수많은 사진에서 ‘하늘’,’바다’ 같은 자연이나 각기 다른 ‘사람 얼굴’을 찾고 인식하는 것으로, 사람은 아주 쉽게 분별하는 작업들을 컴퓨터는 계층을 나눈 패턴을 계산해야 하는 매우 복잡한 과정을 거쳐야 사람의 추론과 직관이라는 것이 가능해진다. 이러한 딥러닝 기술은 대량 연산 능력, 즉 고성능 CPU 컴퓨팅 파워와 이를 동시에 병렬로 처리할 수 있는 가장 핵심적인 하드웨어 요소인 GPU가 필요하다. 이는 우리가 흔히 사용하는 PC 수준이 아니라 수 천장의 CPU와 수백장의 GPU 코어가 탑재된 컴퓨팅 파워를 기반으로 복잡한 계산을 하는 것으로서 지금까지는 마치 슈퍼컴퓨터를 가진 연구소나 거대 IT 기업의 전유물로 여겨져 왔다. 뿐만 아니라 딥러닝이라는 기술은 설명하기도 복잡한 과학자들이 다루는 고급 알고리즘으로서 일반인 뿐만 아니라 소프트웨어 개발자 조차도 이해하기는 매우 어려운 지식이다. 딥러닝에 적용하는 데이터 역시 대용량 빅데이터들로, 이를 적용해서 딥러닝 서비스를 만드는 것은 아무나 할 수 없는 것처럼 보인다. 하지만, 딥러닝을 위한 대용량 컴퓨팅 연산 능력과 빅데이터 그리고 전문 알고리즘 지식 같은 진입 장벽은 클라우드가 주는 자유로 인해 점점 허물어지고 있다. 지금까지 세상의 많은 성공한 기술들의 경우를 보면, 낮은 가격과 보편적인 기술이 되어 누구나 사용하여 아이디어를 실현할 수 있도록 공유되어 왔었다. ■ 클라우드 컴퓨팅이 가져다주는 기회의 자유 아마존웹서비스에서는 가상 서버 중에 g2.8xlarge라는 인스턴스 타입은 가상 CPU 32장과 GPU 4장그리고 240GB의 SSD를 탑재한 장비를 한시간에 3천원(버지니아 리전 기준 2.6달러)에 사용할 수 있는 것도 있다. 50대정도의 온디맨드 가상 서버를 구축하면 1천500여개의 가상 CPU와 200개의 GPU가 달린 슈퍼컴퓨터를 누구나 시간 당 15만원이면 사용할 수 있다. 또한, AWS에서는 스팟 인스턴스라는 개념이 있어 유휴 장비를 경매를 통해 짧은 시간에 빌릴 수 있는 가격 옵션을 제공하는데, 온디맨드 대비 90% 정도 가격이 저[...]



미디엄, 7분 이상 걸리는 글은 안 먹힌다!

Mon, 21 Mar 2016 02:45:56 +0000

가장 양질의 글이 생산되고 있는 블로그 플랫폼으로 평가 받는 Medium에서 가장 최적의 글 길이는 7분이내 읽을 수 있어야 한다는 데이터를 내놓았습니다.

물론 한국어가 아니라 영어 콘텐츠를 기반 하는 거라서 어릴 때부터 책 읽기에 익숙하신 외국 분들을 대상으로 한 결과를 국내에도 적용할 수 있을지는 모르겠습니다. 하지만, 이제 (길든 짧든) 글은 외면하고 밀어서 보기 같은 인포 그래픽을 통한 정보 인스턴스에 길들여지고 있는 상태에서 꽤 의미 있는 결과라 할 수 있습니다.

(image)

글을 간단히 요약해 보자면, 3분 정도 길이를 가진 글이 가장 조회수가 높았지만 글을 읽는데 드는 평균 시간을 살펴 보니 계속 증가하는 경향을 보였고, 7분 정도 길이를 가진 글이 가장 높은 주목을 받았다는 것입니다. 실제로 미디엄에서 나오는 글의 94%가 6분이내이고, 이들의 체류 시간이 엄청 높기 때문에 중간 값을 통해 도출 해본 결과입니다.

하지만, 7분짜리 글을 쓰고 읽히게 한다는 건 정말 어려운 일입니다. 제가 미디엄에 발행했던 글 나의 가족과 저녁이 있는 삶은 천천히 정독했을 때 약 3분 정도 걸리는 것 같습니다. 저의 예전 블로그 글이나 컬럼들도 대략 3분 정도에 읽을 수 있는 글이었구요.

미디엄에서도 나머지 6%에 해당하는 7분 이상의 긴 호흡을 가진 글이 잘 읽히려면 정말 잘 써야 하고, 그러니까 히트가 되는 게 아닌가 싶네요. 그래서, 미디엄의 데이터 분석글 말미에도 “7분이 최적은 아니다. 좋은 글이라면 길든 짧든 많은 사람이 읽는다”라고 언급하고 있습니다.

Great posts perform well regardless of length, and bad posts certainly don’t get better when you stretch them out. What it does mean is that it’s worth writing however much you really need. Don’t feel constrained by presumed short attention spans. If you put in the effort, so will your audience. It’s just math.

한 가지 중요한 사실은, 어쨌든 읽는데 드는 시간이 7분 이상 걸리는 글은 인터넷에서 잘 안 먹힌다는 점입니다. 제 경험으로는 읽는 사람 입장에서 3-5가지 중요 포인트를 가진 3-5분짜리 글이 제일 많이 읽히고, 쓰는 사람 입장에서도 맥락에 맞게 쓰기에 좋았습니다.

여러분은 어떠신지요?




아마존 웹 서비스가 10년간 배운 열 가지 – Werner Vogels

Tue, 15 Mar 2016 02:08:45 +0000

Written by Dr. Werner Vogels * Disclamar AWS의 시작은 10년 전, 3월 14일 Amazon S3 스토리지 서비스를 시작하면서 시작되었습니다. 지난 10년을 되돌아 볼 때 가장 낮은 가격 구조에서 예측 가능한 성능을 보장하면서도 안전하고 믿을 수 있는 확장 가능한 서비스를 만들고 운영하면서 배운 것은 수백 가지가 넘습니다. 개척자로서 AWS가 글로벌 서비스를 제공하면서 이런 것들은 우리 비즈니스에서 매우 중요한 경험입니다. 저희는 전에 자주 “경험에는 어떠한 압축 알고리즘도 없다”라고 말해왔습니다. 수십 억이 넘는 사용자를 갖는 백 만이 넘는 AWS 활성 고객과 함께 많은 경험을 얻을 기회를 얻었고, AWS 고객에 제공할 서비스를 지속적으로 개선하는 더 나은 환경은 없습니다. 저는 이 중에서 몇 가지 배운 점들을 뽑아서 여러분들과 공유하고자 합니다. 1. 진화 가능한 시스템을 만들어라 처음 시작한 날(Day One), 우리가 만드는 소프트웨어가 일년 후에도 돌아가는 소프트웨어가 아닐 거라는 점을 알았습니다. 확장성 문제를 해결하기 위해 아키텍처를 계속 바꾸고 변경할 필요가 있어서 수십 수백 번 바꾸었습니다. 하지만, 운영 장애를 통해 시스템 업그레이드를 하는 옛날 방식의 접근을 사용할 수 없었습니다. 왜냐하면 글로벌 인터넷 비즈니스는 24시간 가용한 우리 플랫폼에 의존하고 있기 때문입니다. 따라서, 서비스가 다운되지 않으면서도 새로운 소프트웨어 부분을 추가하는 아키텍처를 만들어야 했습니다. Marvin Theimer (아마존 핵심 개발자)는 농담 삼아 Amazon S3는 비행 중인 하나의 엔진을 가진 세스나 비행기로 시작해서 점점 시간이 지나 737기, 747기 편대 그리고 이제는 에어버스 380 편대로 진화 됐다고 이야기하기도 합니다. 그동안 이렇게 비행기를 운행 하면서 공중 주유를 하기도 하고, (알아채지는 못하셨지만) 승객들을 이 비행기에서 저 비행기로 옮기기도 하였습니다. 2. 예상치 못한 것을 기대하라 문제는 항상 발생하고, 모든 것은 시간이 지남에 따라 결국 복구 됩니다. 라우터에서 하드 디스크, 운영체제에서 TCP 패킷이 깨지는 메모리 단위, 단기적인 오류부터 영구적인 장애까지도 말입니다. 이는 비싼 장비를 사용하든 저렴한 장치를 이용하던 항상 일어납니다. 이것은 확장 측면에서 중요하게 배울 점입니다. 예를 들어, 아마존 S3는 트릴리온(Trillions, 수조)의 객체를 처리하기 때문에 아주 낮은 확률이라도 오류가 나는 것이 현실입니다. 이러한 오류 시나리오를 이미 예견되지만, 더 많은 것들은 아직 알 지 못하는 게 많습니다. 우리는 왜 생기는 건지는 몰랐다 해도 자연적으로 발생하는 이러한 고장을 기꺼이 포용하는 시스템을 만들 필요가 있었습니다. 시스템은 “집에 불이 났다”하더라도 계속 운영되어야 합니다. 전체 시스템을 다운 시킬 필요 없이 영향을 받고 있는 부분 만을 관리 할 수 있는 것이 중요합니다. 우리는 시스템의 전반적인 지속적 운영을 유지 할 수 있도록 장애의 “폭발 반경”을 관리할 수 있는 기반 방법론을 만들었습니다. 3. 프레임워크가 아닌 재료를 만들[...]



[ZDNET 칼럼] 마이크로서비스를 위한 AWS 빌딩 블록 이해하기

Wed, 09 Mar 2016 17:28:41 +0000

2006년부터 아마존닷컴은 쇼핑몰 서비스를 마이크로서비스 단위로 서비스를 분리하여 이를 API 인터페이스를 가지도록 하는 아키텍처를 도입하고 실제 서비스에 적용하였다. 아마존닷컴 CTO인 버너 보겔스(Dr. Warner Vogels)박사의 2006년 인터뷰를 인용해 보자. “아마존닷컴은 10년전 (1995년) 웹 서버와 데이터베이스 백엔드를 가지는 모놀리식(Monolithic) 애플리케이션으로 시작하였습니다. 5년전(2001년) 아마존은 주요한 아키텍쳐 변화가 있었는데 2 티어(tier)기반에서 서로 다른 애플리케이션 기능을 제공하는 분산 서비스 플랫폼으로 변화하였습니다… 여러분이 지금 Amazon.com의 첫화면에 들어온다면, 그 페이지를 생성하기 위해 100여개가 넘는 서비스를 호출하여 만들고 있습니다.” A Conversation with Werner Vogels , 2006 아마존에서는 이러한 인터페이스를 가지는 각 서비스를 재료(Primitives)라는 용어로 부른다. 어떤 애플리케이션을 완성하기 위한 원료 혹은 재료로서 이를 빌딩 블록으로 조립하여, 원하는 서비스를 만들 수 있는 구성 요소를 말한다. 마치 레고블럭을 조립하여 우리가 원하는 모양의 레고를 만들 수 있는 것과 같은 원리이다 ■마이크로 서비스를 위한 빌딩 블록 철학 아래 그림은 현재 아마존닷컴을 이루고 있는 수 천 개의 서비스들이 서로 어떤 연관 관계가 있는지 의존성에 대한 부분을 연결한 아키텍처이다. 수많은 점들이 서로 연결되어 있는 이러한 아키텍처 모양은 최근 마이크로 서비스 구조에서 자주 인용되는 모양이라고 할 수 있다. 아마존닷컴의 마이크로 서비스 간 의존성을 나타낸 아키텍처 지도 (2009) 2006년에 시작된 아마존웹서비스(AWS) 역시 이러한 아키텍처를 기반으로 서비스를 만들고 있다. AWS에서도 컴퓨팅, 데이터베이스, 스토리지를 비롯하여 모바일, 데이터 분석 등 다양한 영역에 세분화된 50여가지가 넘는 서비스를 제공하고 있으며, 그 서비스 역시 더 세분화된 서비스로 구성되어 있는데, 모든 기능은 API로서 호출이 가능하다. 즉, 사용자들이 사용하는 AWS 관리 콘솔, AWS 명령어 인터페이스(Command Line Interface), 그리고 언어별 SDK를 통해 API호출을 할 수 있다. 이제 AWS 사용자들은 필요로 하는 비즈니스 혹은 기술적 요구 사항을 AWS 서비스를 조합함으로 해결할 수 있고, 아마존닷컴과 마찬가지로 AWS 역시 원하는 애플리케이션을 만들기 위한 서비스 기반 빌딩 블록 철학이 자리 잡고 있다. 그렇다면, 이러한 아마존닷컴의 많은 개별 서비스를 어떤 개발 조직과 문화로 만들고 있을까? 여기서 그 유명한 아마존의 ‘피자 두판의 법칙'(Two Pizza Team)이 나온다. 즉, 가장 이상적인 팀의 크기는 피자 두판으로 한끼를 때울 수 있는 인원으로 다수의 인원이 참여해야 하는 프로젝트라도 소수의 팀으로 나누어 구성하여, 각각의 작은 팀이 세부 기능에 대해 책임감과 투명성, 열정을 갖고서 낮은 커뮤니케이션 비용으로 전담할 수 있게 한다. 즉, 분산된 독립적인 책임감과 주인 의식을 갖는 팀에 의해 서비스가 만들어진다는 의미이다. ■독립된 데브옵스팀을 통한 서비스 [...]



[ZDNET 칼럼] 클라우드 기술에 대한 세 가지 패러다임 변화

Wed, 24 Feb 2016 17:11:53 +0000

최근 10년 동안 클라우드 기술 혁신이 일어남에 따라 민첩한 비즈니스에 큰 영향을 미치는 애플리케이션 개발 및 서비스 배포에 대한 새로운 패러다임이 생겨나고 있다. 과거 데이터센터를 직접 운영하던 온프레미스(On-premise) 환경에서는 물리적 서버를 준비하고, 운영체제 설치 및 앱 서비스 배포를 하는데 몇 주간의 시간이 걸렸다. 그러나, 클라우드 시대에 접어 들어서는 단 몇 분안에 우리가 원하는 서버 자원을 준비하고 앱을 배포할 수 있게 되었다. 또한, 이들 자원은 사용자의 트래픽에 따라 언제든지 탄력적으로 확장 및 가용성을 가질 수 있게 되었다. 2006년 아마존웹서비스(AWS)의 아마존 EC2(Amazon Elastic Compute Cloud: Amazon EC2)라 는 서비스는 가상 서버를 실제 서비스에 사용할 수 있도록 다양한 CPU와 메모리를 가진 40여가지 인스턴스 타입(Instance Type)을 지원하여, 원할 때 마다 언제든지 준비된IT 자원을 얻을 수 있는 민첩성을 얻게 되었다. AWS 클라우드 서비스와 앱 배포 시간의 단축 ■컨테이너를 통한 수초 단위로 앱배포 단축 클 라우드 내 가상 서버 역시 서버이다. 다양한 앱을 실행하는데 있어 운영 체제와 플랫폼의 제한 사항은 그대로다. 따라서, 내부 자원을 효율적으로 사용하고, 최근에는 좀 더 빠르게 앱을배포하고자 하는 컨테이너(Container)라는 조류가 나타났다. 컨 테이너 서비스란 기존 서버를 통해 2개 이상의 애플리케이션을 배포하는 부담을 줄이기 위해, 앱을 실행하는데 필요한서비스 프레임워크,라이브러리, 소스 코드를별도의 격리된 이미지파일로 만든 후 이를 독자적으로 실행할 수 있도록 만든 것이다. 대표적으로 도커(Docker)가 이러한 컨테이너 서비스 기술을 주도하고 있다. AWS에서도 2014년 AWS 리인벤트(re:Invent)를 통해 아마존 EC2 컨테이너 서비스(Amazon EC2 Container Service: ECS)를 공개했다. 이를 사용하면 Amazon EC2 가상 서버 클러스터에서 도커 지원 애플리케이션을 손쉽게실행할 수 있다. 개발자들은 로컬PC에서 컨테이너로 패키징된 앱을 아마존 ECS가 관리하는 클러스터를 통해 단일 컨테이너에서 시작하여 수백개의 가상 서버에서 실행되는 수천개의 컨테이너까지 일반적으로 애플리케이션을 실행하는 것처럼 쉽게 확장할 수 있다. 즉, 컨테이너 서비스를 통해 기존 가상 서버 자원에 별도의 격리된 작은 마이크로 서비스를 원할 때 마다 언제든지 수 초 내에 배포할 수 있는 상태가 되었다. ■서버 없는 클라우드 함수의 등장 또 하나의 주목할 만한 서비스는 바로 AWS 람다(Lambda)이다. AWS 람다 역시2014년 AWS 리인벤트에서 발표된 서비스로 클라우드에서 확장성에 대한 고민 없이도 경량의 애플리케이션을 실행하는 새로운 클라우드 서비스 환경이다. 개 발자가 간단히 파이썬, 자바스크립트 혹은 자바 코드 스니핏을 작성하여, 특정한 클라우드서비스 이벤트에 반응하는 함수로서 실행할 수 있다. 예를 들어 아마존 심플 스토리지(Amazon Simple Storage Service: Amazon S3) 스토리지에 사진을 업로드한 후 이미지 썸네일을 만드는 기능을 생각했을 때, Ama[...]



알파 유저를 위한 AWS 스터디 자료

Wed, 26 Aug 2015 00:55:55 +0000

클라우드 컴퓨팅이라면 개발자 및 인프라 운영 엔지니어들이 주로 사용하는 것으로 알려져 있습니다. 하지만, 블로거나 웹디자이너 등 일반인들도 AWS 서비스를 쉽고 유용하게 사용할 수 있습니다.

지난 4주간 워드 프레스를 자체 서버로 이용하는는 블로거, 포트폴리오 사이트를 운영하는 웹 디자이너, 클라우드를 통한 안정적인 소규모 서비스를 운영하는 스타트업 등 클라우드 기반 웹 사이트 운영에 관심 있는 알파 유저를 위한 학습 스터디를 만들어봤습니다. 오늘 그 자료를 공유해 드리고자 합니다.

(image)

얻을 수 있는 것
1. 클라우드 컴퓨팅의 개념과 AWS 서비스에 대한 이해
2. AWS의 도메인 관리, 스토리지 및 동영상 인코등, 이메일 전송 서비스 활용 지식 습득
3. 복잡한 서버 운영 (콘솔 및 커맨드)과 DB 관리 없이도 안정적인 워드 프레스 운영 노하우 습득

주차별 스터디 내용

1. 클라우드 컴퓨팅 및 AWS 서비스 소개
2. AWS 가입 및 빌링 알람 설정(CloudWatch)
3. AWS Activate 프로그램 가입 및 사용 방법

1. S3에 파일 서버 구축하기(S3 지원 FTP 클라이언트 사용법)
2. AWS 사용자 및 크리덴셜 만들기(IAM)
3. S3에 정적 웹 사이트 운영하기
4. CloudFront로 콘텐츠 배포하기
5. 도메인 네임 관리 및 설정하기(Route53)

1. AWS 아키텍쳐 이해하기 (EC2/ELB/RDS/AutoScaling)
2. 5분만에 확장 가능한 워드프레스 구성하기(CloudFormation)
3. Elastic Beanstalk으로 워드프레스 운영하기
4. WordPress 로컬 서버 및 GIT 레포지터리 설치하기

1. Elastic Beanstalk 설정 및 배포하기
2. Elastic Transcoder를 통한 자동 동영상 인코딩 하기
3. SES를 통해 대용량 이메일 보내기

본 활동은 제가 늘 관심을 가지고 있는 인디웹(IndieWeb)의 취지에도 부합합니다. 인디웹이란 여러분 자신의 도메인을 만들어, 자신만의 콘텐츠를 그 도메인 웹 사이트에 올리고 그 링크를 다른 소셜 네트워크나 배포 사이트에 제공하자는 대안 웹 운동입니다.

1차 스터디는 이번 주 목요일로 종료합니다. 끝나게 되면, 1차 참여하신 분들이 리더가 되는 2차 스터디를 준비 중입니다. 관심 있는 분들은 댓글로 남겨 주시면 함께 참여하실 수 있도록 하겠습니다.




구글의 변신, G is for Google

Mon, 10 Aug 2015 21:55:15 +0000

어제 다음카카오가 젊은 CEO를 발탁한데 이어 오늘은 구글이 완전히 다른 조직 구조를 발표했네요.

(image)

요약하면…

  1. 알파벳(Alphabet, http://abc.xyz)이라는 새 지주 회사(?)를 만들어, 래리페이지가 CEO를 세르게이 브린이 회장을 맡는다.
  2. 구글은 (작년 10월 부터 회사를 이끈) 선다이 피차이가 CEO를 맡는다. 구글은 알파벳 소속 G회사가 된다.
  3. 비지니스 담당이던 오미드 코르드데스타니도 물러나고 알파벳의 고문직을 맡는다.
  4. 알파벳의 소속 기업들이 되는 회사 후보
    • 죽음에 대한 치료에 포커싱을 둘 ‘Calico’
    • 무인 자동차를 개발 연구할 ‘X Labs’
    • (보도자료에는 없지만) IoT 분야 ‘Nest’, ‘YouTube’, ‘Android’, ‘Google Fiber’ 등이 분사 가능성이 있음.

한마디로, 구글이 지주회사를 만들고 다양한 사업을 하는 기업들을 A 부터 Z까지 구성하며, 구글은 거기서 G 역할을 한다는 것. IT 업계의 미래에 충격을 줄만한 대단한 변화입니다~

Alphabet is about businesses prospering through strong leaders and independence. In general, our model is to have a strong CEO who runs each business, with Sergey and me in service to them as needed. We will rigorously handle capital allocation and work to make sure each business is executing well. We’ll also make sure we have a great CEO for each business, and we’ll determine their compensation. In addition, with this new structure we plan to implement segment reporting for our Q4 results, where Google financials will be provided separately than those for the rest of Alphabet businesses as a whole.

– 출처: 구글 보도자료: https://investor.google.com/releases/2015/0810.html




차니의 IT 이야기 #1- 좌충우돌 스타트업 경험기

Wed, 24 Jun 2015 01:21:13 +0000

때는 옛날 옛적 창업 열풍이 불던 닷컴 버블일때, 한 20대 젊은이의 이야기입니다.
15년전 밀레니엄이 시작되던 2000년 작은 벤처 기업에 신입 개발자로 들어간 한 젊은이는 입사 3년 후 대주주로 부터 제안을 받습니다.

회사를 맡아 보겠나? 주변에 20대 벤처기업 사장이 얼마나 많은데, 자네도 할 수 있네… 25%의 회사 지분을 주겠네!

젊은 개발자가 내건 조건은 두가지였습니다!
① 직원이 주인이 되는 회사가 되게 해주세요.
② 제가 하고 싶은 일을 하게 해주세요.

그리고 좌충우돌 모험이 시작되었습니다!

차니의 스타트업을 위한 ‘작은’ 조언

  • 남들이 안된다는 것을 하세요.
  • 남들이 못하는 것을 하세요.
  • 남들이 힘든 것을 대신 하세요.

여기에 기회가 있습니다. 하지만, 기회가 올때까지 살아남아야죠!

(image)

그리고, 기존 사회 제도 발전과 사람들의 인식 전환은 항상 기술 발전 보다 느립니다.
창업자들은 한발 앞서 크게 생각 하고 한발 느리고 작게 사업 하세요.

마지막으로… 당시 저와 함께 20대를 불살랐던 동료들에게 감사합니다!

p.s. 나인포유 추억 사이트 →




re:Invent 100% 즐기기 – Matt Wood

Thu, 11 Jun 2015 07:40:07 +0000

Written by Matt Wood * Disclamar SXSW에서 가장 좋아하는 세션이 바로 ‘How to Rawk SXSW’ 패널입니다. SXSW 인터랙티브가 열리기 하루 전 저녁에 행사를 즐기기 위한 팀과 컨퍼런스에 대한 각종 정보를 다룹니다. (클라우드 컴퓨팅 분야의 주요 컨퍼런스인) 아마존웹서비스의 Re:Invent에 대해서도 비슷한 접근을 해 보면 좋겠다고 생각했습니다. 운이 좋게도 매년 Re:Invent 콘퍼런스에 참여했고, 행사가 열리는 라스베가스 베네티안 호텔은 매년 같은 장소라서 다른 분들에게도 도움이 될 것 같습니다. 더 좋은 팁이 있으시다면 메일 부탁 드립니다. 준비하기 오랫동안 다수의 기술 컨퍼런스에 참여해 보았는데, 행사에 가기전 아무것도 할 수 있는 게 없거나 미리 준비할 게 다양했습니다. 제가 추천하는 몇 가지 방법입니다. 행사 발표 세션 주제나 시간표 미리 입수 꼭 들어야 하는 아젠다나 세션을 정하기 고르기 힘든 건 과감히 다음에 정하기 분야가 좀 다르더라도 흥미있는 주제인 것 선택하기 하루에 너무 많은 거 듣지 않기 – 빨리 달리기가 아니라 마라톤임 주로 업무용 지식을 얻는 것이 매우 도움이 되고, 새로운 것을 배우는 것은 대략적인 계획을 짜는게 좋습니다. re:Invent에는 매우 많은 세션이 동시에 진행되고 무엇인가 놓쳤다는 점에도 신경쓰지 않아야 합니다. 여러분은 최선의 선택을 했고, 어떤 선택이 좋지 않았더라도 행사 후에 따라 잡을 수 있는 기회(슬라이드나 동영상 공유)가 있으니까요. 실패 비용은 낮고 선택하는 실험은 열려 있습니다. 시간과 공간 라스베가스 호텔은 매우 큽니다. 아마 여러분이 베가스에 처음이라면 상상하기 힘들 정도로 크기 때문에 걷는데 익숙하셔야 합니다. 주변 호텔과도 꽤 거리가 있기 때문에 시간 안배를 잘해야 합니다. 컨퍼런스 장소에서 호텔방까지 20분 정도 걸릴 수도 있습니다. 컨퍼런스 발표 세션 및 전시장은 상대적으로 가깝긴 하지만, 세션 중간에 다녀오기에는 멉니다. 대부분 15분 정도의 휴식 시간이 있는데 다른 세션장으로 이동을 하는데 사용해야 합니다. (역자주: 인기있는 세션들은 줄이 길기 때문에 미리 와서 대기해야 하고, 입장 시 태그를 꼭 찍게 됩니다.) 준비물 콘퍼런스에 올 때 가져올 준비물입니다. 2014년에 제가 썼던 것들입니다: Herschel ‘Little America’ 백팩 2013 13” MacBook Pro (내 컴퓨터) 2011 15” MacBook Pro (백업용 컴퓨터, 메인 컴퓨터가 문제가 생겼을 때 사용) iPhone – 항상 사용하는 휴대폰 PowerAll 12,000 mAh Power Bank (20분이면 전체 충전이 가능함) 올해는 백팩을 메신저백으로 바꾸려고 합니다. 좀 더 이동이 쉽도록요. 복도에서의 만남 기술 세션도 중요하지만 많은 참여자들이 네트워킹을 하는 것을 매우 중요하게 생각합니다. Re:Invent는‘everybody conference’가 되고 있고 이는 클라우드 업계에서 트위터에서 팔로잉 하는 유명 인사를 직접 볼 수 있다는 장점이 있습니다. 예를 들어, Netflix OSS에서 직접 코드를 짜[...]



다음 클라우드 서비스 종료 ㅠㅠ

Mon, 01 Jun 2015 06:50:37 +0000

Daum의 대표적인 개인 파일 저장 서비스인 Daum 클라우드가 서비스를 종료한다고 합니다. 클라우드 시대에 클라우드 서비스를 접는다니 매우 아쉽습니다. 특히, 용량이나 안정성 면에서 가장 경쟁력 있고, 충성 사용자가 많아서 더 그렇네요.

  • 6월 1일(월) – 서비스 종료 공지. 파일 백업 툴 제공. 신규 가입 중단.
  • 7월 31일(금) – 백업, 파일 다운로드 기능을 제외한 모든 기능(PC싱크어플, 모바일 앱 포함) 제공 중단.
  • 12월 31일(목) – 다음 클라우드 서비스 완전 종료

아이러니하게도 구글은 지난 주 구글 I/O에서 무제한 사진 저장/백업 서비스인 구글포토를 내 놨는데, 시기적으로 매우 묘하네요. 아무튼 저도 애용하는 서비스인데 매우 섭섭하네요. ㅠㅠ (클리앙 커뮤니티 반응)

(image)

다음 클라우드 종료 전문

안녕하세요. Daum클라우드팀에서 인사 드립니다. 그동안 Daum클라우드를 이용해주신 회원님께 세상에서 가장 어렵고 힘든 말씀을 드리게 되었습니다.

빠르게 변화하는 치열한 시장환경에서 Daum클라우드는 오픈 후부터 오랜 기간 동안 서비스의 현재와 미래에 대한 깊은 논의를 계속 해왔습니다. 더욱이, 5년이라는 짧지 않은 시간을 Daum클라우드와 인연을 맺고 이용해주신 여러분이 계시기에 고민에 고민을 거듭했습니다. 하지만 지금의 모습으로 서비스를 유지하기에는 어려움이 크다는 결론에 다다르면서, 결국 서비스 종료를 안내 드리게 되었습니다. 그동안 Daum클라우드를 이용해주신 여러분께 글로 다 표현할 수 없는 감사를 드립니다. 더불어 서비스를 유지하지 못하는 점, 깊이 사과 말씀을 드립니다.

종료 공지를 보시면 “내 데이터를 어떻게 백업 받지?”라는 생각을 아마 제일 많이 하시지 않을까 싶습니다. 그래서 부족하지만, 데이터를 보다 편리하게 백업 받으실 수 있도록 전용 백업 툴을 준비했습니다. 죄송한 마음을 이것으로 다 할 수는 없지만, 종료일까지 백업 받으시는데 불편함이 없으시도록 최선을 다하겠습니다. 서비스 종료일 2015년 12월31일 후로 데이터를 백업 하실 수 없으니, 반드시 종료 전에 PC로 백업을 완료 해주시기 부탁 드립니다.
자주 묻는 질문 / 도움말(FAQ) 보기
Daum 클라우드 고객센터로 문의하기

오랜 기간, Daum 클라우드와 소중한 인연을 맺어주신 여러분들께 다시 한 번 깊은 감사를 드리고, 언젠가 또 다른 인연으로 긴 시간 함께 할 수 있도록 꿈꾸고 노력하겠습니다.
– Daum 클라우드 마지막 인사 올림




스승의 날 – 나의 잊지 못할 선생님!

Fri, 15 May 2015 05:49:53 +0000

오늘은 스승의 날이네요!

저의 인생에서 큰 전환점이 되어 주신 몇 분의 스승님이 계십니다. 찾아뵙고 감사 인사를 드려야 하나 이렇게 부족한 글로서 저의 고마움을 표해 봅니다.

(image)

사실 초중고 기간에는 그렇게 기억 나는 선생님이 없습니다. 초등 4학년때 저를 이뻐해주셨던 한 여선생님, 중학교때 글쓰기를 가르쳐 주셨던 국어 선생님, 그리고 고등학교 때 저의 처지를 고려해 입주과외 자리를 주선해주셨던 기술 선생님 등등…

하지만, 20대 이후 20년간 저의 인생 그 자체에서 엄청난 영향을 미치신 분들이 몇 분 계십니다.

윤선 교수님 대학 학부 2학년 때 부터 교수님 랩에서 학문과 연구에 대한 열정을 몸소 깨우쳐 주신 분입니다. 4학년때 제주도로 저를 처음 데리고 가주셨고, 일주일 동안 필드트립을 통해 많은 것을 가르쳐주셨죠. 석사 1년차때 제가 컴퓨터와 인터넷에 빠져 사는 것을 질책하셨지만, 제가 벤처기업으로 가도록 허락해 주시고 결국 지질학이라는 순수 학문과 크게 다른 GIS 분야의 석사 논문을 쓰도록 큰 배려를 해 주셨습니다. 아마 저의 사고와 연구하는 힘은 모두 교수님께 물려 받은 것입니다. 늘 건강 하세요~

김영섭 교수님 석사 1년차때 당돌했던 저를 학교로 불러주시고, 학생들과 다양한 경험을 쌓게 해주셨구요. 그 후, 타교 학생임에도 불구하고 제가 학위 논문을 써야 할 때 학교에 자리와 장비를 내 주시고, 논문 지도까지 해주셨지요. 제가 힘들고 어려울때 학교 연구소에서 교수님과 함께한 기도회와 신앙적 모범이 저에게 큰 힘이 되었습니다. 가끔 뵐때 마다 저에게 큰 도전을 주십니다.

제양규 교수님 저의 인생과 직장의 멘토셨죠. 저의 첫 직장 보스셨고, 당시 벤처 기업에서 다양한 일을 직접 만들어 볼 수 있도록 기회를 열어주셨습니다. 20대의 터프함을 잘 감싸 주셔서 오늘의 제가 있지 않았나 싶습니다. 제가 학교로 가있던 도중에 도와 주신 것이나 우리 가정을 위해 해 주신 많은 배려도 잊을 수 없습니다.

김홍기 교수님 직장 생활에 지쳐 있을 때, 다시 공부를 할 수 있도록 열정을 부어 주신 분입니다. 2년간의 박사 코스웍 동안 전산과 의료 분야의 사고의 폭을 확장시켜주셨을 뿐 아니라 소중한 학문적 동지들을 만날 수 있게 해주셨지요. 너무 감사합니다.

즐거운 하루 보내세요. 늘 잊지 않겠습니다~




클라우드로의 귀환 – James Hamilton

Mon, 11 May 2015 23:40:53 +0000

Written by James Hamilton * Disclamar Zynga는 유명 소셜 게임 업체로서 성공적인 게임 서비스를 제공하면서 그동안 미디어의 관심을 받았습니다. 오늘은 게임 분야가 아니라 Zynga 그 자체에 대한 다른 측면의 이야기를 해보려고 합니다. 샌프란시스코에 본사를 두고 $2.5B 가치를 가진 Zynga는 초기에 클라우드 컴퓨팅을 적용한 얼리어댑터 기업으로 AWS를 기반한 퍼블릭 클라우드를 비지니스에 적용했었습니다. 요즘 이런 이야기는 크게 이슈가 되지는 않습니다. 왜냐하면, Netflix 처럼 규모가 큰 서비스가 이미 클라우드에서만 운영하고 있기 때문입니다. KAREN BLEIER/AFP/Getty Images 이야기는 2012년 Zynga가 당시 모든 클라우드 기반 서비스를 자체 데이터 센터를 이동하는 결정으로 거슬러 올라갑니다.  Zynga Gives Amazon Cloud the Slip 및 Zynga Cloud Case Study: the Journey to a Real Private Cloud 라는 뉴스 기사를 등을 통해 널리 전해졌습니다. 징가의 이러한 의사 결정은 회사가 어느 정도 충분한 IT 투자 및 운영 환경이 되었다면, 기존 데이터 센터를 이용하는 것이 더 올바른 의사 결정이라는 사례로 많이 인용이 되었습니다. 좀 더 현실적이나 여전히 부정확한 이야기지만, 이미 안정화된 서비스 및 업무는 기존 데이터 센터에 호스팅하는게 더 경제적이라는 사례로서 인용된다는 점입니다. 요즘은 더 많은 데이터가 있고, “스케일 시스템 유지(Being at Scale)”는 적어도 10^6 서버에다가 운영체제, 네트워크, 그위에 소프트웨어 스택을 올리고 계속 규모 있게 투자를 해서 운영할 수 있는 능력을 유지해야 합니다. 저는 이러한 질문들에 대해 저의 생각을 re:Invent에서 두 번의 발표를 통해서 이야기했으며, AWS Innovation at Scale(2014년)과 Why Scale Matters and how the Cloud is Different(2013년)을 참고해 보시기 바랍니다. 수 년전 Zynga의 이러한 결정은 그냥 잊혀졌고, 그 이후 많은 기업들은 클라우드로 더 많이 이동했습니다. 하지만, 저는 그 때 경우를 아주 자세히 봤습니다. 왜냐하면 빠른 의사 결정의 스타트업 문화를 가진 회사, 그리고 동시에 높은 수준의 클라우드 경험이 있는 회사가 더 경제적이라는 목표에 근거해서 퍼블릭 클라우드의 장점을 적용한 자체의 프라이빗 인프라로 서비스를 운영하도록 결정한 흔하지 않은 경우였기 때문입니다. 그런데, 이번 주에 월스트리트 저널의 Robert McMillan이 쓴 Zynga, A Journey from Cloud to Home — and Back Again라는 글이 올라왔습니다. 이 뉴스 기사는 Zynga가 그동안 프라이빗 클라우드 인프라에 1억달러 넘게 지출을 했으며, 다시 퍼블릭 클라우드로 모든 서비스를 이전하는 결정을 할 수 밖에 없었다는 보도입니다. 이러한 결정은 예전 이동 결정 뿐만 아니라 그동안 Zynga가 수 년간 고가용성 인프라 운영을 위해  기존 데이터센터 및 퍼블릭 클라우드를 함께 운영한다고 널리 알려져 널리 있었기에 더 흥미롭습니다. 기사 중 Zynga CEO Mark Pincus[...]



MS 새 브라우저 Edge, 굿바이 액티브X!

Wed, 06 May 2015 22:30:32 +0000

지난 주 MS Build 2015 행사 이후, MS가 미쳤다(?)라는 평을 듣고 있습니다. 윈도 무료 업그레이드, 비주얼스튜디오 에디터의 맥 OS 및 리눅스용 공개, 오피스 API 공개, 안드로이드 및 iOS 앱의 윈도용 앱 포팅 제공 및 클라우드 DW 기능과 닷넷 Docker 지원 등 플랫폼 개방을 시도하는 발표들이 줄을 이었으니까요. 특히 홀로렌즈라는 3차원 가상 현실 도구는 구글 글래스나 오큘러스 보다 훨씬 멋지다는 평을 얻었습니다.

특히, MS는 웹 브라우저 시장에서 강세를 이어오다 최근에 많은 도전을 받고 있는 Internet Explorer를 해체하고 새로운 브라우저 엔진인 스파르탄을 기반으로 하는 Microsoft Edge라는 윈도10용 브라우저를 선보였습니다.

(image)

오늘 아침 발표를 보면, Edge는 과거와의 완전한 단절을 선언했습니다. 300개가 넘는 과거 API 지원을 중단하고 22만줄의 코드를 삭제했습니다. 대신 49개의 새로운 기능과 4,200개의 호환성 기능을 추가하여 30만줄의 신규 코드를 추가하는 대수술을 단행했습니다.

이번 수술로 제거된 대표적인 레거시 기능은 다음과 같습니다.

  • ActiveX: COM/OLE의 과거 유산을 완전히 청산하고, 자체 PDF 렌더링 Flash 빌트인 등 중요한 몇 가지 기능을 제외한 액티브 X 기능은 완전히 삭제됩니다. 따라서, 국내에서 돌아가는 모든 액티브X 콘트롤은 Edge에서는 무용지물입니다. (이는 크롬이나 파이어폭스의 NPAPI 지원 중단과 궤를 같이합니다. 보안이나 사용성에 모두 안좋아 MS도 안전히 포기한 액티브X는 완전히 안녕!)
  • 브라우저 헬퍼 오브젝트(BHO): 악성 프로그램이나 애드온들이 IE 도구 모음에 마구 아이콘을 박아대던 BHO도 이젠 안녕! 앞으로 뭐 설치할 때 마다 IE가 지저분해지는 것을 막을 수 있을 듯…
  • 문서 모드 및 조건 주석: x-ua-compatible이라는 해괴한 모드를 만들어, 브라우저 버전별로 체크를 해대던 문서 모드와 [if IE 7]과 같은 조건 주석문으로 HTML 코드를 어지럽히던 게 사라집니다. 탁월한 결정!
  • VBScript: 자바스크립트의 카피캣으로 액티브X와 함께 진작에 사라져야 했으나 명맥을 유지했으나 이제 완전히 안녕!
  • IE8 Quirks 모드: IE10 이상에서 지원해서 가장 오용이 심한 기능이었는데, 완전히 사라짐! (IE11 엔터프라이즈 모드로만 이용)
  • 그 밖에: attachEvent 지원 종료 -> addEventListener로 대체, currentStyle -> getComputedStyle로 대체, DirectX Filters/VML -> CSS3 및 SVG로 대체

(image) 더 이상 MS Edge 에서 지원하지 않는 API 목록을 Github에서 보다니 놀라울 따름입니다. 특히, 160여개에 달하던 -ms vendor prefix를 50개 정도 삭제해서, 90여개인 -webkit과 비슷한 수준으로 낮추었습니다.

MS Edge의 이러한 변화는 그동안 개발자와 웹 기술 시장의 변화에 대한 가장 큰 응답이라고 보여집니다. 다만 현재 웹 기술 및 모바일 시장 변화가 MS에 유리하게 작용하고 있지 않기 때문에 다소 늦은감은 있습니다.

소는 잃어도 외양간을 고쳐고 있는 마이크로소프트와 달리, 그동안 한 가지 기술에 목매다가 소도 잃고 외양간도 함께 잃어버린 한국 웹 시장은 누가 책임질건지 암담하네요. 한국 컴퓨팅 역사에서 ‘액티브X 종속 사례’가 가져온 실패를 앞으로 기술 정책을 주관하는 사람이 잊지 않아야 할 겁니다.

이 블로그에서 언제나 액티브X에 대한 글이 마지막이 될까요?

p.s. 설마 MS Edge에서 액티브X 지원 안한다고 윈도 10으로! 업그레이드를 하지 말라고 하는 말도 안되는 일이 벌어지진 않겠죠 ㅠㅠ

update: 최근에 액티브X 콘트롤 배포 방식이 object 임베딩 방식이 아닌 EXE 방식으로 변해서 크게 달라지지 않을 것이라고 이야기하시는(혹은 비꼬는) 분들에게… 엣지는 EXE로 설치된 콘트롤도 지원하지 않습니다. MS Edge에서는 모든 종류의 액티브X 콘트롤이 완벽히 차단 된다고 보시면 됩니다.(어도비 리더, 플래시, 자바 모두 포함)




새로운 시작을 위한 6개월…

Fri, 01 May 2015 00:18:28 +0000

작년 10월 말 10년간 몸 담았던 다음카카오를 떠나서 새로운 도전을 시작한 지 6개월이 지났습니다.

9년간 살았던 제주에서 서울로 거주지도 옮기면서 아이들도 서울 생활에 적응해 나가고 있고, 18년이 넘게 국내 토종 기업에만 있다가 완전히 다른 환경에서 적잖이 이직 스트레스를 받으면서 긴장하면서 보냈습니다. 글로벌 기준에 따라 완전히 다른 업무 방식에 사소한 실수도 하지만, 정말 많은 것을 배우고 있기도 합니다.

“나이가 들고 경력이 쌓였는데도 (자기 일을 해 줄) 손발이 없다고, 의사 결정 안해 준다고, 예산 없다고 일하기 힘들다는 사람들이 있다. 사소한 일이라도 처음부터 끝까지 자기가 혼자 다할 줄 알고, 직접 해결할 수 있어야 일을 제대로 하는 사람이 아닐까?”

제가 멘토로 여기고 있는 분이 이직할 때 위와 같은 조언을 해주셨습니다. 큰 조직 보다는 스타트업 같은 분위기에서 내 손으로 직접 할 수 있다는 점에서 보람을 느끼고 있습니다.

이전에 큰 조직에 몸 담았지만, 팀 관리자로 큰 조직의 오너로 나가기 보다는 작은 조직의 개발자로 남기를 바랬습니다. 실무와 가장 가까이 있어서 개발자들과 소통하기를 늘 원했고, 적어도 함께 토론하고 이야기를 나눌 수 있는 것이 즐거웠습니다. (그러기 위해서는 항상 새로운 것을 접하고, 직접 해보고 하는 것이 꼭 필요합니다.)

새로운 이 곳에서 더 그럴 수 있게 된 것 같아 기쁩니다.

For the evangelist role, we’re more flexible with respect to what you’ve done in the past… What’s most important is that elusive combination of technical experience, great communication skills, and a passion for helping developers.Evangelist and Community People

또한, 제가 하고 있는 업에 대한 이해도를 높힐 수 있는 계기가 되고 있습니다.

위의 인용구는 닷컴기업 최초 에반젤리스트 중 한 명인 Jeffrey McManus가 이베이를 떠나 야후 개발자 네트워크를 만들 때 기술 에반젤리스트를 구인하면서 적었던 내용입니다. (제가 2005년에 이 글을 읽고 꽤 감명을 받고 2006년 다음개발자네트워크(Daum DNA)를 만드는 데 동력이 되었습니다.)

제일 마지막에 a passion for helping developers라는 말을 좋아합니다. 개발자들의 경력 및 후생을 개선하는 것, 업무의 병목이 되는 문제 해결과 자신의 핵심 서비스 개발에만 집중할 수 있도록 하는 수단을 제공해 줄 수 있다면 그 보다 보람되는 일은 없을 겁니다.

과거 국내에서 웹 표준이나 Ajax 기술 도입을 통해 소위 UI개발자들 즉, 프론트엔드 개발자의 위상이 높아진 점이나 지도나 검색 오픈 API 확산을 통해 다양한 매쉬업과 API 플랫폼 기반 서비스 모델이 잘 정착되고 있는 점 역시 보람된 일이었습니다.

최근 몇 년 동안 관심을 가져왔던 클라우드 컴퓨팅이라는 새로운 분야에서 새로운 방식으로 개발자를 돕는 일을 하게 되어 기쁩니다. 이제 6개월간 준비를 끝내고 개발자들을 직접 만나서 이야기를 듣는 일에 주력하고자 합니다. 언제든지 저의 도움이 필요하시면 이메일로 연락해 주시기 바랍니다.

즐겁고 보람된 연휴 보내시길…


(image)




트위터 백업하기 – 10,000 트윗 기념

Thu, 30 Apr 2015 00:00:56 +0000

2008년 2월 트위터를 처음 시작하였습니다.

그리고, 오늘 9,999 트윗, 499 팔로잉, 35,399 팔로워, 399 관심글, 9개 리스트~ 완전 9의 향연이네요.
그동안 함께 해준 트위터 탱큐! 팔로워 분들도 감사드립니다~

(image)

트위터가 소셜 및 모바일 시대의 간편한 소통과 공유의 수단이 되기도 했지만, 온라인에서 단편적인 지식 활동 및 깊은 사고의 결핍 같은 역효과도 경험했던 것 같습니다. 아무튼 새로운 환경에서 다양한 분들과 소통할 수 있는 멋진 채널이 되었음은 부인할 수 없습니다.

앞으로 얼마나 트위터가 제 역할을 할지? 아니면 새로운 채널이 대체할 지 모르겠으나 어쨌든 제 트윗은 로컬에 모두 백업 되고 있습니다! 잘 모르시는 분을 위해 트위터 기록을 백업하는 방법을 알려드리겠습니다. 한번씩 백업해 두세요^^

1. 계정 설정 https://twitter.com/settings/account으로 갑니다
하단의 내 기록 요청하기 버튼을 클릭합니다.

(image)

2. 메일로 다운로드 링크가 날아옵니다.
(image)

3. ZIP으로 묶인 백업 파일을 다운로드합니다.
(image)

만일 매일 자동으로 백업을 하고 싶은 분은 Google Drive를 이용한 방법을 이용해 보시기 바랍니다.

최근 트위터 분위기가 안 좋은데, 새롭게 변신해서 문닫지 않고 지속되길 바래봅니다.

트위터에 대해 쓴 글 더 보기…
Twitter와 FriendFeed 이야기
트위터(Twitter)의 모든 것
Twitter의 수익 모델은?
트위터가 짜증 나는 이유
트위터의 장애 극복 이야기
회장님이 트위터 쓰는법
트위터는 죽지 않았다
사람… 트위터, 블로그
트윗팔아 돈버는 수익모델
국내 IT 분야 개인 트위터 RT 지수 v2.0




엔씽, IoT 화분 스타트업 킥스타터 가다!

Sun, 12 Apr 2015 22:30:05 +0000

2년 전 글로벌 K-Startup의 멘토링을 하고 있을 때였습니다. 저에게 멘토 지원한 스타트업 중 엔씽(nthing)이라는 곳이 있었습니다.

그 때만해도 IoT라는 커넥티드 디바이스를 만드는 아이디어를 가진 곳이 많진 않았죠. 제주에 있어서 자주는 만나지 못했지만 어쨌든 멘토링을 잘 끝냈는데, 나중에 그 팀이 최우수상을 받았더군요.

그 뒤 실제 창업을 해서 스마트폰을 이용해 외부에서도 물을 주거나 주변 조명등을 조절할 수 있는 플랜티(Planty)라는 인터넷 화분의 시제품을 만들어 냈습니다. 지난 주 금요일 이 제품을 양산 테스트하기 위해 드디어 킥스타터(Kickstarter)라는 펀딩 사이트에 올렸습니다. 정말이지 축하합니다!

(image)

실제 농학도와 화분이라는 하드웨어 개발에 집중하다가, 애그리테인먼트(Agritainment)라는 개념의 자연과 환경과 함께하는 서비스로 진화하고 있습니다. 킥스타터에 이미 150명이 넘게 주문을 했고, 이제 총 10만불을 목표로 10월까지 시제품을 만들어 배송하는 것이 목표입니다.

사실 아이디어를 낼 수는 있지만 실행에 옮기는 것이 쉽지 않다는 것을 모두 잘 압니다. 특히 그게 하드웨어 기기이고 프로토타입 수준까지 만드는 건 가능해도 양산 수준까지 가기에는 엄청난 노력이 필요합니다. 그렇기 때문에 이 단계를 넘어갈 수 있게 응원을 해야 할 것 같네요.

킥스타터에서 예약 주문하기

한국어 소개

최근 제가 하는 일과도 관련되어 IoT 분야와 실시간 데이터 분석에 대한 다양한 기술적 멘토링을 계속 해주고 싶구요!

꼭 성공하길 바랍니다~




정보 인스턴스화 – The Instance Information

Sun, 05 Apr 2015 22:50:00 +0000

요즘 콘텐츠 공유의 유행을 보면 페북이나 트위터로 보여지는 ‘밀어서 보기(Swipe to read)’ 같은 열 장 이내 그래텍스(Gratex)나 스토리텔링식 슬라이드쉐어가 인기를 끕니다. 이제 뉴스 기사나 긴 블로그 글은 읽기도 힘들고 잘 공유하지도 않습니다. 바야흐로 정보 인스턴스화 시대에 접어들었네요.

아마 “밀어서 보기”의 원조는 아마 “밀어서 잠금해제(?)”가 아닐까 싶은데요. 최초는 아마 페이스북의 포토셋 기능을 이용한 것으로 보입니다. (이를 다음의 스토리볼에서 일부 채용하기도 했었지요.)

(image)

그리고 트위터가 다중 사진 업로드 기능을 추가하면서 이 기능을 활용하는 경우가 생겨났습니다. (하지만, 트위터의 매체 파워나 인기도가 하락하는 바람에 그렇게 활성화 되지는 못했다는…)

(image)

최근에는 온라인 뉴스 미디어 사이트들도 이런 방식의 콘텐츠 전달이 일상화 되었습니다. BuzzFeed가 주로 사용하던 “OOO하는 7가지 방법”, “죽기전에 가봐야 할 20가지 여행지” 이런 식의 콘텐츠 뿐만 아니라 최근 뉴스 기사를 사진과 그래픽 그리고 간단한 텍스트로 간결하게 전달합니다. 이건 인포그래픽도 아니고 그래텍스(GraTex)라고 명명해야 할듯요.

(image)

IT쪽에서는 슬라이드쉐어에도 비슷한 풍조가 있어서, 발표 자료가 아니라 스토리텔링이 있는 콘텐츠를 많이 올립니다.

위의 자료는 링크드인의 CEO인 레이드 호프만의 Network Intelligence: Your Company Can’t Thrive Without It이라는 자신의 새 책을 요약한 자료입니다.

모바일 환경이 되면서 작은 화면에서 보다 압축적인 메시지를 전달하기 위해 이러한 콘텐츠 공유 방식이 생겨났는데, 바쁜 현대인을 위해서는 어쩔 수 없는 현상 아닌가 싶네요.
여러분은 어떻게 생각하십니까?

p.s. 한줄 영문 요약
In terms of the information sharing, recently there is a trend of the swipe-to-read type as like Facebook photos around 10 gratex format and story-telling based slideshare. Now don’t read long articles of blog or news. It’s the era of instance information.




차니블로그 역대급 만우절 글 모음!

Wed, 01 Apr 2015 00:33:29 +0000

오늘은 만우절입니다. 어제 JTBC 뉴스룸의 앵커브리핑에서 욕하지 않고선 살 수 없다면 욕을 제때 제대로 해야 하는 것처럼, 영화 ‘굿바이 레닌’을 예로 들며 거짓말도 그래야 한다고 하시더군요. 내일은 만우절입니다. 혹시 준비해둔 비장의 거짓말… 있으신지요? 그러나 내일 하실 거짓말은 제 때에 제대로 하는, 그러니까 그야말로 만우절다운 거짓말이 되어야 할 것 같습니다. 그걸 지키지 못하면 문제가 생길 수 있습니다. 공공기관에 장난전화 하면 공무집행방해죄를 적용하겠다는 엄포가 이미 나왔습니다. 어찌 보면 각박하지요? 만우절 거짓말이 점점 더 정교해지니까 이런 얘기마저 나오는 모양입니다. 손석희의 앵커 브리핑 中 저도 블로그에서 매년 만우절을 맞아 즐거운 거짓말로 즐겁게 하려고 했으나, 돌이켜 보면 물의(?)를 일으키기도 했다는 생각이 드네요. 즐겁기 보다는 너무 진지해서 깜빡 속아 넘어가서 오히려 불편했달까요? 하지만 돌이켜 보면 또 재미있는 추억꺼리입니다. 오늘은 그냥 예전의 역대급 만우절 이벤트를 한번 다시 모아보았습니다. Microsoft로 이직 합니다! (2007) 제가 블로그에서 한 첫번째 만우절 이벤트인데, 그래서 그런지 많은 분들이 낚였습니다. 게다가 당일 제가 직접 마이크로소프트 본사에서 TechSummit 행사에 참여하고 있어서 더더욱 실제와 같았지요. 문제는 너무 많은 분들이 방문해서 폭주하는 바람에 서버가 다운돼서 다음날에야 해명을 할 수 있었습니다. 2007년 부터 마이크로소프트는 오픈 소스 지원 정책을 펼치기 시작했지만, 지지부진하다가 최근에 광폭 행보를 보이고 있죠. 국내에서도 다양한 개발자 커뮤니티 지원도 시작했는데 지속적인 변화가 되길 바랍니다. OOXML, ISO 표준 통과 불확실 (2008) 당시 개발자 커뮤니티 사이에 핫이슈였던 마이크로소프트의 오피스 표준인 OOXML의 ISO 표준을 통과시키려는 로비 활동에 대한 비판으로 적은 글입니다. 많은 분들이 희망적인 글에 기대를 했는데 실망하셨다는 피드백을 주셨었죠. 오픈 웹 소송 취하! 금결원과 합의 (2009) 이 또한 당시의 핫이슈였던 오픈 웹 소송, 소위 액티브X 소송에 대한 희망 사항을 적인 글입니다. 여기서 부터 약간 이미지를 가미한 고퀄리티 낚시가 시작되었습니다. 실제로 쿠키뉴스에서 “한국 ‘액티브X 은행’ 탈피… 오픈웹―금결원 조정안 합의”라는 뉴스 기사를 쓰기도 했습니다. 기자분께는 죄송하지만 제대로 낚이셨어요. Good Bye, 차니블로그! (2011) 당시 트위터와 페이스북이 한참 뜨면서 블로그의 열풍이 사그라드는 시점에서 너무 안타까운 나머지 쓴 글입니다. 지금도 크게 다르지 않지만, 소셜네트워크 피로증으로 블로그를 조금씩 하시는 분이 생기기 시[...]



마이크로서비스 인 액션 – MicroServices In Action

Sun, 22 Mar 2015 00:00:21 +0000

어제 James Lewis와 Martin Fowler의 마이크로서비스 한국어 번역 (원문)을 소개했는데 많은 분들이 공유해 주셨더군요. 그런데, 반응 중에는 기계 번역 같다 내용이 어렵다 하는 분들이 좀 있으셨어요. 그도 그런것이 아키텍트들이 어떤 시스템을 설명할 때, 추상화(?) 시키는 버릇이 있어 쉽게 쓰면 알아 들을 수 있는 이야기도 어려운 용어를 쓰면서 더 어렵게 쓰는 것 같습니다. 마이크로서비스로 구현된 Netflix의 아키텍쳐 구조도 아무튼 개발자들이 알아먹을 수 있게 코드로 보여주거나, 아니면 그림으로 실제 사례를 소개하거나 좀 더 쉽게 잘 이야기하는 글을 소개해야 하는데 죄송합니다. 그래서 A/S로 몇 가지 더 참고 자료를 소개합니다. 국내 소개 자료 국내에서 마이크로서비스를 주도적으로 소개해 주시는 분들이 세 분이 계십니다. 바로 조대협님, 정도현님 그리고 안재우님이신데요. 아래에 대표적인 소개글이랑 슬라이드를 우선 먼저 알려드리겠습니다. 조대협, 대용량 웹서비스를 위한 마이크로 서비스 아키텍쳐의 이해 이 글은 조대협님이 마틴 파울러의 글을 좀 더 쉽게 예를 들어 구성한 것으로 실제로 어떤 프로젝트에 마이크로서비스가 구현됐을 때 모양을 개발자들이 이해하기 쉽게 쓴 글로서 일독을 추천합니다. 특히, 마이크로서비스의 단점이라고 생각 되는 부분과 팀 구성 및 개발팀 운영에 대한 방식도 잘 설명되어 있습니다. 정도현, 마이크로서비스가 가져올 미래의 개발 패러다임 이 글은 정도현님이 마이크로서비스에 대한 방대한 참고 문헌의 글을 잘 요약한 것으로 간단한 정의와 특징 구현 요소를 그리고 최근 동향까지 간략하게 잘 풀어 주었습니다. 마지막에 있는 참고 링크들은 한번씩 꼭 읽어 보아야 할 것 같습니다. 또한 정도현님이 만드신 MSA를 이용해 구현하는 고가용/고확장성 서비스 슬라이드도 참고하시면 좋습니다. 안재우, 마이크로서비스 아키텍처로 개발하기 닷넷엑스퍼트로 유명하신 안재우님이 최근 오픈테크넷서밋에서 SK플래닛에서의 직접 이러한 아키텍쳐를 적용해 봤을 때 경험을 소개한 자료로 아마 개발자들이 보면 단박에 이해할 만큼 유용한 것 같습니다. 사실 이러한 새로운 아키텍쳐를 도입하는 건 내부에 많은 반대에 부딪히게 되는데, 기술적 변화를 이끌어 가기라는 이야기를 어떻게 변화를 적용했는가 하는 점도 함께 보시면 좋을 듯 하네요. 해외 사례 자료 이제 대충 내용은 알겠는데, 도대체 어떤 해외 사례가 있길래 이렇게 마이크로서비스가 입방아에 오르는지 실체가 없다고 생각되시는 분들을 위해 몇몇 주요 공개 회사들의 사례들을 소개합니다. 넷플릭스의 사례 넷플릭스는 마이크로서비스를 언급할 때 가장 먼[...]



구글 코드의 배신… ㅠㅠ

Fri, 13 Mar 2015 01:31:15 +0000

방금 구글로 부터 메일을 하나 받았습니다. 2006년부터 시작되어 많은 오픈 소스 애호가로 부터 사랑 받았던 ‘구글 코드’ 호스팅 서비스 문을 닫는 다는 것입니다.

(image)

Earlier today, Google announced we will be turning down Google Code Project Hosting. The service started in 2006 with the goal of providing a scalable and reliable way of hosting open source projects. Since that time, millions of people have contributed to open source projects hosted on the site. Bidding farewell to Google Code

세월이 흘러서 다양한 오픈 소스 프로젝트 호스팅이 가능해졌고, 그 사명을 GitHub이나 Bitbucket에게 물려준다는 고상한 이유를 댓지만 안타깝네요. 오는 8월까지 기능 개선은 없이 제공되고, 각 프로젝트는 읽기 상태로 제공되고 내년 부터는 압축된 다운로드만 가능하다고 합니다.

개인적으로 12개의 프로젝트를 올려놓고 간간히 업데이트도 하고 있었는데, 이 중 계속 유지해야 하는 몇 개는 Github이나 Bitbucket으로 옮겨야 합니다. 구글 정도라면 영구적으로 서비스 유지 정도는 해 줄거라고 생각했는데, 전 세계 많은 오픈소스 애호가들이 오늘 아침은 멘붕일 듯…

콘텐츠 호스팅 웹 사이트가 문을 닫게 되면, 수 백만 혹은 수 십억개의 퍼머링크가 웹 상에 삭제되고, 이들 사이트에는 많은 일반 사용자의 글과 콘텐츠가 없어지는데, 이것은 대기업일 수록 서비스를 종료하는 사례가 많습니다. 인디웹에서도 이런 대형 사이트 종료를 웹에서 가장 큰 문제점으로 생각할 정도니까요.

웹 기록이 사라지는 것을 최대한으로 막기 위한 방법이 무엇일지 고민되는 하루네요.

p.s. 아무리 Git이 대세라지만, 작은 프로젝트에서는 여전히 SubVersion도 유효하고 효과적입니다. 구글 코드의 간략하고 심플한 서비스가 좋아서 많이 썼는데… 이제 SubVersion은 어디에서 ㅠㅠ




페이스북, 친구에게도 광고를 하라고?

Tue, 10 Mar 2015 23:21:57 +0000

온라인 광고, 특히 떠오르는 모바일 광고의 무게추가 페이스북으로 옮겨간지 오래입니다. 이미 사람들은 번쩍이는 배너와 꽃배달 같은 검색 후 나오는 박스의 사이트들이 이미 광고라고 인지하고 있습니다.

페이스북의 경우, 친구 관계에 기반한 추천에 대해 사람들은 정보로 인식하기 때문에 광고 효과가 높으며 이는 모바일 광고 시장, 소셜이 먹히는 이유온라인 광고의 변신은 무죄에서 설명한 적이 있습니다.

(image)

페이스북 사용자들은 타임라인에 자기가 뭔가를 올리면 내 친구들은 다 볼거라고 생각하지만 전혀 그렇지 않습니다. 사실 친구들이 올린 사진, 글, 좋아요! 등이 타임라인에 나타나야 하나 그렇지 못해서 일부만 나오게 되고 그 틈새에 광고를 넣는 기법을 사용합니다.

페이스북 타임라인 속에 “OOO가 좋아합니다”라는 메시지를 달고, “Sponsred”라고 작게 적힌 박스들을 보실 수 있는데 이들이 모두 광고들입니다.

(image)

위의 캡쳐에서 보듯이 제가 뭔가를 올리면, 그걸 아주 일부의 친구들에게 보여줍니다. 제 페이스북 페이지에는 5천명이 좋아요를 눌렀지만, 실제로 그들에게 다 보여주지 않지요. 즉, 일부에게 보여준 뒤 사람들이 반응을 하는 콘텐츠면 오히려 광고를 하라고 합니다.

위의 예제에서 도달 숫자가 높은 건 그나마 공유 혹은 좋아요로 반응해 준 몇 사람들의 친구에게도 보여 준 결과이니 실제 친구에게만 보여준 도달은 많지 않습니다.

(image)

그래서 ‘게시물 홍보하기’를 클릭해보면, 몇 가지 광고를 할 대상을 볼 수 있는데 그 첫번째가 페이지를 좋아하는 사람들 즉, 제 타임라인 업데이트를 보겠다고 좋아요를 누른 사람들이에요. 제 친구들에게도 제 글을 보여 주고 싶으면 광고를 해야 합니다.

마치 과거에 블로그 RSS 구독을 했는데, 뉴스리더가 사용자에게 선별해서 보여주고 더 보여주고 싶으면 돈을 내라는 식이지요.

온라인 광고의 흥망성쇠를 보면, 미친듯이 성장하는 페이스북 광고도 언젠가 내리막길을 걷게 될텐데, 이게 바로 아킬러스 건 아닐까요?




우버(Uber)를 응원합니다!

Sun, 08 Mar 2015 23:00:41 +0000

우버코리아가 지난 3월 6일 오후 5시부터 우버엑스 서비스를 중단한다고 발표했습니다. 여객자동차운수사업법 위반 혐위로 검찰로부터 기소 당하고, 서울시의회가 우버 불법 영업 신고 조례를 통해 집중 단속을 받았죠.

얼마 전 우버X 무료 서비스라는 초강수를 두었습니다만…

(image)

저는 얼마 전 밤 늦게 강남역에서 택시를 잡지 못하고 헤매다가 우버를 통해 편하고 쉽게 귀가할 수 있었습니다. 어느 토요일 오후에 즐겁게 아이들과 모임 장소에 갈 수 있었습니다. 친절한 우버 기사 분들과 말도 잘 통하고 즐거웠습니다.

이러한 편하고 즐거운 서비스를 왜 법적 규제로 가두어야 할까요? 택시의 경쟁력을 높일 생각은 안하고, 카풀이나 크게 다름 없는 이런 멋진 서비스를 말이죠.

전 인터넷기업협회장이자 한국 최초 인터넷 서비스 사업자인 아이네트 창업자이신 허진호 박사님의 일침 역시 곱씹어 보아야 합니다.

이와 똑같은 ‘현행법’의 잣대를 들이대면, 84년에 전길남 박사님이 국내에서 처음 연구 목적의 인터넷을 구축하신 것도, 94년에 내가 상용 인터넷 접속 서비스를 시작한 것도 모두 명백히 ‘현행법’ 상 불법이었다.

그 이후에 닷컴 시대에 등장한 대부분의 서비스 (PG, 전자 상거래, 온라인 광고 등)도 자세히 따져 보면 당시의 ‘현행법’ 상 불법이었을 가능성이 높을 것이다. 특히 PG와 같은 서비스는 더욱 더. 이 사건은 이제 새로운 기술 기반의 혁신이 우리나라에서는 가능하지 않다고 못을 박는 상징적 사건이 될 것이다.

저의 첫 회사는 인터넷에서 음악 스트리밍 서비스를 국내에서 최초로 시도했던 ‘나인포유(Nine4u)’라는 스타트업이었습니다. 제가 직접 만든 그 사업은 당시 음반사들의 인터넷 음반 홍보를 하면서 사용자에게 원하는 무료 음악 듣기를 제공하던 것인데, 당시 음악 저작권법의 저항에 부딪혔습니다.

(image)

인터넷 음악 방송에서 DJ들이 음악을 틀면 이게 방송인지 인터넷 서비스인지, 어떻게 이를 분류하고 처리해야 할지 몰랐습니다. 가장 손 쉬운 것이 ‘현행법’으로 강제하고 불법으로 규정하는 것이었습니다.

심층적인 가수 인터뷰와 장르별 전문 방송을 하고, 표절 음악을 분석하고 일본 음악을 들려 주면서 많은 이들의 관심을 끌었지만, 국내 최대 저작권 소송에 휘말려 20대의 젊은 나이에 검찰 조사를 받으면서 힘들었던 때가 기억납니다.

왜 이러한 새로운 변화가 생겨 났는지, 왜 사람들이 이에 열광하는지, 앞으로 어떤 의미가 있는지 서로 고민하고 논의해야 할 대상인데도 말입니다.

앞으로 우리 나라가 소위 창조 경제니 혁신 경제니 하는 것을 원한다면, 기술 변화에 민첩하고 유연한 나라가 되어야 합니다. 우버 뿐만 아니라 새로운 아이디어가 현행법에 안 맞더라도 뭔가 변화를 이끌고 있다면 이를 지지해야 합니다.

우버가 국내에서 새로운 법적 이해를 받고 다시 서비스를 재개할 수 있도록 여러분도 도와 주세요. “우버를 응원합니다!”라고 메시지를 올려주세요.




인디웹과 워드프레스

Mon, 02 Mar 2015 23:00:18 +0000

지난주 토요일 한국 WordPress 사용자 모임이 주최한 ‘워드프레스 미트업 2015’ 행사를 다녀왔습니다.

(image)

13년차 워드프레스 사용자로서 늘 애정을 가지고 있는 블로그 도구이자, 파이어폭스와 함께 엔드유저 오픈 소스 소프트웨어로 성공한 모범 사례로 한국 사용자 모임도 늘 성장하고 있기도 합니다.

이번 행사에도 유료 행사인데도 200여명이 등록을 했고, 워드프레스를 이용한 웹 사이트 구축, 웹 접근성 및 생태계 등에 대한 다양한 발표가 진행되었습니다.

저도 얼마전 부터 시작한 독립 웹 사이트 운영자를 위한 인디웹(IndieWeb)의 생각과 표준 기능, 워드프레스에 바로 적용 가능한 플러그인 및 테마 등을 소개하기 위해 참여했습니다.


인디웹과 워드프레스 (화면 선택 후, 좌우 이동키를 이용하세요!)

워드프레스는 인디웹을 구현할 수 있는 주요 도구이자 방법입니다.(인디웹 워드프레스 페이지 참조) 특히, 소셜 웹 사이트에 공유한 블로그 글에 대한 반응을 모아오는 백피드(Backfeed) 기능에 관심을 많이 가지시더군요. 페이스북이나 트위터는 언젠가 없어질지라도 내가 운영하는 웹 사이트의 콘텐츠와 반응들은 늘 가지고 있을 수 있으니까요.

2010년에 있었던 미트업에 강연자로 참여한 이후에 간만에 사용자 모임 운영진들과 즐거운 만남을 가질 수 있었습니다. 우리 아이들과 인디웹 커뮤니티 분들과도 조인트 식사를 하게 되었습니다. 반갑고 즐거운 자리였습니다.

(image) (image)

앞으로 워드프레스 사용자들에게 인디웹 기능을 더 많이 알려드리도록 노력해보겠습니다.




미국 FCC, 망중립성 강화 규정 통과

Thu, 26 Feb 2015 23:00:16 +0000

미국 연방통신위원회(FCC)가 인터넷 서비스의 차별을 없애는 ‘망중립성’ 강화 규정((net neutrality protections)을 확정했습니다. ( FCC Open Internet Rules)

새 규정의 핵심은 인터넷망을 전화나 전기와 비슷한 공공재로 간주해 통신 업체가 별도의 대가를 받고 특정 콘텐츠의 전송 속도를 빠르게 해 주는 이른바 ‘급행 차선’을 금지하는 것입니다. 또 서비스 종류에 따라 합법적인 콘텐츠를 차단하거나 속도를 느리게 하는 것도 허용하지 않기로 했습니다.

(image)

특히, 이번 규정에는 무선 인터넷도 포함되어 스타트업이나 소규모 업체들도 무선망 네트워크를 사용하는데 있어 장벽을 없어지게 됩니다.

버락 오바마 대통령은 지난해 11월 발표한 성명에서 “인터넷서비스공급업체(ISP)가 온라인 상거래에서 승자와 패자를 선택하도록 할 수는 없다”면서 망 중립성 강화 규정을 추진 방침을 밝힌 바 있는데요. 오늘 FCC는 망중립성 강화 규정을 표결에 부쳐 찬성 3표, 반대 2표로 통과시켰습니다. (찬성 반대는 각각 공화당, 민주당 2표이고 캐스팅보트를 쥔 휠러 위원장이 찬성!)

제가 속한 Mozilla 커뮤니티에서도 그동안 다수의 캠페인을 벌여왔는데, 이번 결정을 인터넷에서 개방성, 혁신과 기회의 보장이라는 중요한 승리로 생각하고 있습니다.

이번 결정이 국내 망중립성 보호 논의에 긍정적으로 영향을 주기를 진심으로 기대합니다!

알아두기: 망중립성
망중립성 이슈에 대해서는 오바마까지 나선 인터넷 주도권 전쟁… 美 연방통신위, 원칙 고수냐 수정이냐 26일 ‘세기의 표결’에 자세히 나와 있습니다.

(image)