방금 전 갑자기 생각난 일이다.

2007년 쯤이었던 것 같다.
어느 날 출근을 하려고 아침에 버스를 기다리는데 배가 너무 아팠다.
그래서 집으로 다시 돌아가서 시원하게 볼일을 보면서 오전반차 신청을 했다.
반차 사유로 '출근길에 똥이 마려워서 다시 집으로 돌아감' 이라고 적었던 것 같다.

그런데 곧 이어 당시 팀장님에게 사유를 좀 무난하게 적어달라는 피드백을 받았었다. 자기가 사유를 '개인 사정'이라 고쳐줬다는 말과 함께.

나는 '사유: 개인 사정' 보다는 '사유: 출근길에 똥이 마려워서 다시 집으로 돌아감' 이 더 좋은데.

아마 그 당시 조엘온소프트웨어를 재밌게 읽었던 것 같다.
스펙문서를 쓸 때는 딱딱하고 재미없게 쓰지 말고 웃기게 써라. 어이없을 정도의 말투와 웃음도 괜찮다. 유머는 진짜 중요하다. 사람들이 프로페셔널하게 보이지 않는다고 뭐라하더라도 신경쓰지 말아라. 뭐 이런 이야기였던 것으로 기억한다.(지금 다시 찾아보니 이 글인 것 같다. https://www.joelonsoftware.com/2000/10/15/painless-functional-specifications-part-4-tips/ )

저 똥 이야기가 조엘의 이야기와 일맥상통한다고 보기는 힘들지만 어느정도는 비슷한 이야기가 아닐까 싶다.
네이버라는 회사를 다닐 때도 딱딱하고 갑갑한건 마찬가지였다. 저 정도의 사유도 눈쌀 찌푸리고 잔소리 하는 회사들이 2019년인 지금도 80%는 될 것 같다.

나는 결국 저 똥 이야기를 받아줄 수 있는 회사를 찾았는데, 그 회사는 바로 카카오였다.
유머를 존중하고 격식을 따지지 않았던 회사. 그래서 내가 카카오를 그만둔 지금도 카카오를 존중하고 사랑하고 있는 것 아닐까 하는 개똥생각이 잠깐 들었다.

2008년 경의 일이다. 당시에 일하던 회사의 이사님께서,

"재호야, 혼자서 할 수 있는 일은 별로 없어."

라는 말씀을 하셨다.

어떤 프로젝트를 하기 위해서는 서버 개발자, 클라이언트 개발자, 디자이너, 기획자 등이 있어야 하고 혼자서 프로젝트를 한다고 했을 때 고를 수 있는 일이 거의 없다는 말이었고, 협업을 잘하는 능력이 중요하는 말이었기도 했다.

이 말은 오랫동안 내 귀에 남았다.

그 얼마 후에 멀리 가려면 함께 가라 라는 책을 보게 되었는데, 이 책을 또 무척 인상 깊게 읽었다. 그래서 그런지  '멀리 가려면 함께 가라' 라는 문장은 내 머리 속에 크게 자리 잡아 버렸다.

- * -

나는 지금 소개팅 앱 서비스를 '혼자서' 만들고 있다.

클라이언트, 서버 개발, 디자인, 기획, 운영, 마케팅을 다 혼자서 하고 있다.

원래부터 혼자하려던 건 아니고 친구들과 함께 만들다가 나 혼자 외롭게 남아 계속 만들게 되었는데, 혼자 일을 계속 하다보니 '멀리 가려면 함께 가라' 라는 말이 과연 진실일까 라는 생각이 가끔 들기 시작했다.

생각해보면 10년 전에는 혼자 할 수 있는 일들이 별로 없던게 맞는 것 같은데, 지금은 그렇지 않은 것 같다.

앱스토어가 생기고, Github 에 좋은 오픈소스들이 너무도 많이 올라와있고, 아마존 aws 가 자리를 잡았고, flutter 나 React Native 같은 기술이 나오고, 페이스북에 손쉽게 광고를 노출하고 구글애널리틱스로 트랙킹하고.

이런 모든 것들이 10년 전에는 없었기 때문에 혼자서 뭔가를 하기 힘들었던게 아닌가 싶다.

- * -

그 간의 경험을 떠올려보면, 처음부터 마무리까지 혼자 해냈을 때 가장 실력이 많이 늘었던 것 같다.

혼자서 일할 때 좋은 점들이 여러 개 있지만, 그 중에 가장 마음에 드는 점이다.

홀로 서비스 운영과 홍보 등 새로운 경험을 해 보면서 요즘 재미를 많이 느낀다. 다른 면으로 또 성장하고 있는 것 같다.

'멀리 가려면 함께 가라' 라는 말은 틀린 말은 아닐 것이다. 함께 일하는 것이야 말로 가장 어렵고 중요한 일이니까.

하지만 이런 생각에 갇혀서 혼자 할 수 있는 일은 없다고 단정 지을 필요는 없을 것 같다.

요즘 이야말로 혼자서 뭔가 해보기에 가장 좋은 세상 아닐까?

멀리 가려면 혼자서도 가보자.

국민연금보험료 이메일 고지서

KT 요금 고지서

현대HCN 이메일 청구서

요금 고지서로 날라 오는 이메일들 중 보안 메일이라고 보내오는 위와 같은 메일 방식은 어디에서 처음 시작된걸까?

공기업, 사기업, 정부 기관 할 것 없이 약속이나 한 듯이 비밀번호는 생년월일 혹은 사업자 번호이고, 내가 비밀번호를 설정할 수도 없다. 어떻게 보면 참 폭력적이고 무식하다. 이걸 과연 보안 메일이라고 불러야 할까.

그들도 할 말은 있는 듯 하다.

생각해보면 아주 오래 전에 그런 방식으로 보내 주던 시절이 있긴 했다. 그 메일들은 비보안메일 이라고 불리며 보안(?) 메일 들에게 자리를 내줬던 걸로 기억한다.

작년 봄에 다니던 회사를 그만두고 약 1년 째 백수로 지내고 있다.

좀 더 정확히 말하면 전업 주부라고 말할 수 있겠다.

요즘 하루의 대부분을 청소, 아이 돌보기, 요리, 책 읽기, (아기 안고) 유투브 보기를 하며 지내고 있다.

작년에 아내가 임신해있는 동안에는 같이 놀러도 많이 다니고, 커피한잔이라는 직장인 소개팅앱을 만드느라 코딩도 회사에 다닐 때 만큼 많이 했던 것 같다.

올 해 2월에 드디어 아기를 낳았는데, 내 생활이 완전히 바뀌어버렸다.

직업 프로그래머가 된 이후 처음으로 무려 세 달간 코딩은 거의 하지 못했다. 바깥 구경 나간 시간도 몇 시간 되지 않는 것 같다. 아내와 둘이 같이 붙어 애를 봐도 이렇게 힘이 드니, 육아라는 일을 너무 우습게 생각했다는 것을 인정한다.

그 동안 정신 없이 아이 울음 소리와 함께 살았는데, 100일 정도가 지나니 그래도 조금 여유가 생긴다.

이제야 가끔 밖에 나가서 사람들을 만나보면, 내가 아는 많은 친구들이 새로운 분야를 향해서 달려가고 있는 것에 놀라게 된다. 의외의 친구들 조차 이 달리기에 동참하고 있다. 블록 체인과 인공지능 이야기이다.

이 달리기 행렬을 바라 보고 있으면, 집에서 아기 돌보면서 매일을 보내고 있는 나는 세상에서 홀로 멈춰 있는 듯한 느낌을 받는다.

앞으로 1년 정도가 지나면 얼마나 차이가 벌어질까? 그 때 가서 과연 따라갈 수는 있을까? 이런 생각들이 나를 초조하게 만들기도 한다.

그러나 그런 초조함도 잠시다. 아내가 힘든 육아를 홀로 맡게 될 생각을 하고, 매일 달라지는 아이를 바라보는 기쁨을 포기해야 한다는 상상을 하면 내 마음이 곧 원래 위치로 돌아온다.

혼자 멈춰있다는 생각이 들지 않도록, 작게 나마 다시 생산적인 일을 해보려고 한다. 블로그 글쓰기가 우선은 해볼만해 보인다.

요즘엔 사람들이 페이스북같은 SNS 에서 정보를 많이 얻어가는 것 같지만, 여전히 블로그는 좋은 정보의 원천지이다.

개발자와 IT 서비스를 하는 사람들을 위해 좋은 글들이 올라오는 블로그들을 모아서 이 글들의 정보를 보여주는 간단한 안드로이드 앱을 친구와 함께 만들었다. 이름은 어썸블로그라고 지었다. (아이폰 앱은 없다.)

https://play.google.com/store/apps/details?id=org.petabytes.awesomeblogs

https://itunes.apple.com/kr/app/%EC%96%B4%EC%8D%B8-%EB%B8%94%EB%A1%9C%EA%B7%B8/id1276023809?mt=8

이런 저런 회사들을 다니면서 특출난 개발자 친구들을 많이 만났지만, 이 앱은 그런 친구들을 위한 앱은 아니다. 실력이 출중한 사람들도 물론 있지만 아직 어디서 정보를 얻어야할지 모르는 소소한 개발자들도 많이 있는 것을 알게되었고 이런 동료들에게 좋은 개발 블로그들을 소개해줌으로써 작은 길잡이가 되었으면 하는 마음이다.

소스코드는 전부 공개되어 있으며, 누구든지 기여 할 수 있다.

https://github.com/BenjaminKim/awesome-blogs (서버)

https://github.com/jungilhan/awesome-blogs-android (안드로이드)

https://github.com/tilltue/awesome-blogs-ios (아이폰)

재미있는 법률여행 1 - 한기찬 지음/김영사

살면서 경제적 혹은 실용적으로 내 삶에 도움을 줬던 고마운 책들을 고르라면, 그동안 읽었던 많은 컴퓨터 책들이 1순위이고, 늦게나마 영어 공부가 하고 싶어 샀던 영어 문법책이 두 번째로 떠오른다.

그리고 오랜 시간이 흘러 마침내 3순위라고 말할 수 있을만한 책을 찾은 것 같다.

법이라는게 이렇게 재미있는 것이었나 싶을 정도로 읽기 쉽게 쓰여졌고, 책 구성도 아주 탄탄하다.

주말 동안 열 시간 정도를 들여서 책을 즐겁게 읽었는데, 다 읽고나서는 다른 사람이 된 것 같은 느낌이 든다. 이 책의 시리즈는 총 5권인데, 나머지 4권도 모두 읽고 싶다.

에어비앤비에는 호스트와 게스트간에 상호 평가를 할 수 있는 평판 시스템이 있는데, 아주 잘 동작하고 있다.

에어비앤비 호스팅을 해오면서 쌓아온 내 점수들을 가만히 바라보다가 커뮤니케이션 부분에서 눈이 멈췄다.

별 5개를 받는 것이 참 어려운 일인데, 어떻게 커뮤니케이션은 약 40여명의 게스트들에게 단 하나도 빠짐없이 별 다섯개를 받을 수 있었을까.

게스트들의 피드백을 받으며 그 답은 빠르게 문의에 답하는 내 `응답속도` 였다는 것을 알게되었다.

커뮤니케이션의 스킬에는 여러가지가 있겠지만, 응답속도는 우리가 쉽게 간과하고 있는 요소는 아닐까.

시중에 판매되는 여러 시간관리 책들이 이메일을 너무 자주보지말라는 조언을 한다. 

메일이나 카톡, 슬랙을 수시로 뒤져보며 이런 지침과는 정반대로 에너지를 비효율적으로 사용하는 내 모습에 불안함도 느끼며 지냈는데, 오늘 이 결과를 보니 꼭 그렇지만도 않다는 기분 좋은 안도감이 든다.

내가 네이버에서 좋아하는 딱 두가지 제품(혹은 서비스)은 나눔 폰트와 네이버캐스트이다. 한 5년여 전에 처음 네이버캐스트라는 걸 알았을 때 그 아름답고 잘 쓰여진 글들을 읽으며 홀딱 반해서 더 많은 사람들이 읽었으면 좋겠다 생각했었고, 사람들이 편하게 접근할 수 있도록 네이버에서 RSS 피드를 제공해주면 좋겠다라는 생각도 했었다. 

네이버에서 피드를 제공해주지 않자(네이버는 네이버Me를 쓰라고 권유함. 하지만 누가...) 몇몇 사람들이 직접 크롤링해 피드 서비스를 제공했었는데, 모바일에서 레이아웃이 깨져서 읽기 불편한 서비스도 있고, 잘 쓰고 있다가 어느 날 갑자기 도메인이 사라져버린 서비스도 있었다.

그래서 내가 만들었다.

몇 개월동안 혼자 쓰며 즐거움을 느끼고 있다가 오늘 문득 다른 사람들과도 공유하면 좋을 것 같아서 코드와 함께 피드 주소들을 공개한다.

EDIT: 2016-06-09

새로운 카테고리가 추가되었다는 제보를 받고 리스트를 한번 갱신하였다. 갱신된 최신의 리스트는 https://github.com/BenjaminKim/navercast_rss_feed 에서 볼수 있으며, 아래 리스트에는 추가하지 않았다.

많은 사람들이 자신이 한 달에 얼마를 쓰는지 잘 모르고 있으며, 실제로 쓴 돈보다 더 적게 쓸 것이라고 추정하고 있는 것을 봐왔다.

왜 이렇게 낙관적인 생각을 갖게 되는 것인지는 잘 모르겠지만, 나 역시도 그랬었다.

우연한 기회에 별 생각없이 가계부나 써볼까 했었는데, 한 달 뒤 내가 실제로 쓰는 돈이 추정치와 꽤 많이 벗어난다는 것을 깨달아 가는 과정이(물론 내 예상보다 더 많이 돈을 쓰고 있어서) 고통스러웠던 기억이 난다.

이런 일이 어쩌면 일을 할 때도 있지 않나 하는 생각이 든다.

사람들은 자신이 (다른 사람들이 자신을 평가해주는 것보다) 일을 잘하는 편이라고 낙관적으로 생각을 하는 것 같다. 평가시기에 돌아오는 피드백에 대한 반발, 연봉에 대한 불만 등은 어쩌면 이런 낙관적인 생각들 때문에 나타나는 현상은 아닌지 모르겠다.

가계부를 쓰기로 결정한 이후로 가장 좋은 점은 내 상태를 내가 정확히 알게 되었다는 점이다.

2010년쯤에는 얼마를 벌었고 얼마를 썼는지, 그에 비해 지금은 한달에 얼마를 쓰고 있는지를 잘 파악하고 있다.(지출이 엄청나게 늘었다;;)

위에 가계부를 처음 썼을 때 고통스러웠다고 표현했는데, 그 고통이란 바로 이런 느낌이었다.

"내가 상위 10% 정도에는 들 정도로 절약 정신이 투철하고 실제로도 그렇다고 생각했는데, 뚜껑을 열어보니 그게 전혀 아니었어."

'일' 에 대한 가계부를 쓴다고 하면 아마 이런 느낌을 받을 수 있을 것 같다.

"나는 야근도 다른 사람들보다 많이 하고 회사에서 상위 10% 에는 들 정도로 많은 기여를 하고 있다고 생각했는데, 지금까지 한 일들을 쭉 펼쳐보니 실제로는 그냥 평균밖에 못하는 사람이었어.(이런, 심지어는 야근도 별로 안했네)"

어렴풋이 생각해보는 것과 사실은 다를 수 있다. 나는 이런 판단 착오가 위에서 말한 고통보다 더 무섭기 때문에, 우선 내가 회사에서 하는 모든 일들을 가계부를 쓰듯이 구체적으로 기록해보기로 했다.

오늘은 어떤 코드를 짰고, 어떤 문제에 대해서 고민을 했고 이것은 어떤 방식으로 해결했는지.

고민만 하다가 결국 문제를 못풀고 포기한 것은 아닌지. 포기했으면 포기했다고 기록.

지각을 했으면 지각을 했다고 기록하고, 낮잠 잔 날은 낮잠 잔 것도 기록한다.

가계부를 쓸 때도 수입만 적고 지출을 빼놓을 수는 없듯이, 일을 할 때도 잘한 일과 못한 일을 다 기록 하는 것이 중요하다.

이런 과정이 예전의 나보다 더 나아지게 도움을 주었는지는 확신할 수 없지만(조금은 주었다고 생각은 한다) 적어도 내 상태가 어느 수준인지는 잘 알게 해준 것은 맞는 것 같다.

최근에는 매일 하는 일의 기록 외에도, 내가 1년에 통상 몇개 정도 커밋을 하는지, 몇 권의 책을 읽는지를 관심있게 관찰하고 기록하면서 그 숫자를 외우고 있으며, 이런 것들을 나 자신을 평가할 때 쓰는 요소 중 하나로 삼기도 한다. 이런 가계부의 요소들은 자신이 어떤 일을 하고 있는지에 따라 달라질 수 있을 것 같다.

만약 일을 하면서 자신이 과소평가 받고 있다고 느끼는 사람들이 있다면, 먼저 자신만의 가계부를 한번 만들어서 기록해보면 어떨까? 어떤 식으로든 도움이 될 것이라 생각한다.

쉬는 날을 틈타 Build 2015 동영상을 다운 받아서 하나씩 보는 중이다. Async/Await 이라는 부제에 끌려서 들어갔는데, 이 제목은 낚시였고 TypeScript 에 대한 설명이 주를 이룬다.

TypeScript 자체에는 큰 관심이 없지만, 앤더스 헤일스벅이 타입이라는 것에 대해 그동안 고민해온 고찰을 들어볼 수 있었고 또 전설의 레전드가 직접 코딩하는 것을 구경하는 것만으로도 무척 즐겁게 봤다.

동영상은 아래 링크에서 볼 수 있다.

https://channel9.msdn.com/Events/Build/2015/3-644

보통 우리 나라 IT회사들의 평균 나이는 31-33세 인데 내 나이가 이제 우리 나이로 35살이니 평균 보다 조금 늙은(?) 나이인 것 같다.

그래서인지 모르겠지만 언제부터인가 회사에서 가끔씩 나를 시니어라고 부를 때가(분류할 때가) 있는데, 나는 그럴 때마다 몸에 소름이 돋는다. 소름이 돋는다는 것은 좋은 쪽이 아니라 나쁜 의미의 표현으로 사용한 것인데, 그것은 내가 시니어라는 단어에 특별한 의미를 부여하고 있기 때문인 것 같다.

내가 이전에 윈도 프로그래밍을 공부할 때 너무 좋아하고 닮고 싶던 프로그래머들이 몇 명 있었는데, 그 중 두 명은 Hans Passant 와 Raymond Chen 이라는 사람이었다.

Hans 는 스택오버플로우에서 놀면서 알게된 사람이고 스택오버플로우의 전체 랭킹 10위 안에 들 정도로 실력있는 사람이다. 레이몬드는 The Old New Thing 이란 블로그로 오래 전부터 유명했던 마이크로소프트의 해커이다.

3년 전까지만 해도 아침에 눈뜨고 저녁에 잠들기 전에는 항상 그들이 스택오버플로우와 블로그에 쓴 글들을 받아서 읽어보며 배우고 기뻐했던 기억이 난다. (둘 다 로우레벨 프로그래밍부터 하이레벨 프로그래밍 까지 분야을 막론하고 탁월함을 드러내기도 했고 시니컬 하고 톡톡 쏘아 말하는 말투까지 너무 비슷해서 나는 어쩌면 이 둘이 같은 사람이 아닐까 생각한 적도 있었다.)

어쨌든.

Software Architect 이든 Chief Technical Officer 든 온갖 멋진 수식어를 가져다 붙여도 이상할 것 같지 않은 이 두 사람들. 그 중 Hans Passant 는 LinkedIn 에 자신을 Sony 의 Senior Programmer 라고 소개해놓았다.

Raymond 는 언젠가 블로그에 자기가 Senior Engineer 라고 자랑스러워하는 어떤 얼간이를 비꼬는 글을 쓰기도 했었는데, 이런 것들을 보면서 아마 나는 저 두 사람에게 영향을 받은 것이 확실한 것 같다.

그래서 그런지 나는 시니어 프로그래머라는 단어을 보면 저 두사람이 머리 속에 탁 떠오른다. 누군가 나를 시니어 프로그래머로 부르거나 자신을 시니어 프로그래머라고 호칭하고 다니는 사람들을 보면 우리가 시니어 라는 말을 너무 함부로 사용하고 있는 것은 아닐까 하는 생각을 한다.

2014 RubyConf 에서 마츠와의 질문 답변 시간에 어떤 청중 하나가 루비에 매크로를 지원할 생각이 있냐고 질문하자,

마츠는 C언어의 매크로를 생각하고 대답한 것이 틀림없는데(나를 포함한 웃은 사람들도), 마츠의 대답을 듣고 아무말 없이 돌아서서 뒤로 나가던 그 질문자도 그런 의도였는지는 지금 다시 생각해보면 확실하지가 않다.

꽤 오랫동안 윈도 프로그래밍에서 떨어져 살다가 윈도폰은 어떨지 궁금해서 문득 윈도폰 하나를 중고로 구입해본 적이 있었다. 그게 NT 커널이 올라가있는 윈도폰 8.0 이었었고, 세컨드 폰으로 장난감 다루듯이 사용해보다가 시간이 좀 흐르고 BUILD 2014 행사에서 MS가 윈도폰 8.1을 발표했다.

그 때쯤 처음으로 윈도폰과 Windows Runtime 에 관심을 가지고 진지하게 책을 읽어보기 시작했으며, 역시 처음으로 Build 2014 에 나오는 대부분의 비디오를 다운받아서 봤는데(기존에는 키노트만 봤었다) Windows Rumtime 기반으로 한번 앱을 만들어보는 것도 좋겠다는 생각이 들었다.

마침 회사에서는 윈도폰을 위한 카카오톡을 새로 만들기로 결정을 했기 때문에, 나도 꼽사리를 껴서 같이 만들어 보기로 했다.

오래 전에는 윈도 개발에 익숙했기도 하고 이것저것 아는 것들도 조금 있었기 때문에 처음에는 재밌고 그리 오래 걸리지 않을 작업이라고 쉽게 생각했었는데 막상 Windows Runtime 과 부딪혀보고는 곧 그렇게 쉬운 일이 아니라는 것을 깨달았다. 기존에 알고 있었던 네이티브 지식들과 Win32 Api 지식들은 거의 도움이 되지 않았고, Windows Rumtime 의 새로운 프로세스, 패키지 데이터, 네비게이션 모델 등을 다 새로 공부해야만 했다. 닷넷은 책으로만 보고 작은 프로그램들 정도만 작성해봤었는데, 처음으로 정교한 프로젝트에 맞딱드려보니 UI 와 데이터를 유지보수하기 쉽게 바인딩하는게 생각처럼 쉽지 않아 고생을 많이 했었고 또 Task 기반 프로그래밍 역시 책으로 이해한 것과는 달리 실제로 적용해보면서 꽤 많이 해맸었던 것 같다. 대부분의 라이브러리들이 윈도폰용의 Windows Runtime 을 지원하지 않거나 지원 준비중이 었기 때문에 스트레스를 받기도 했다.

무엇보다 나를 괴롭혔던 것은 Windows Runtime 이라는 새로운 환경 자체였는데, 아무리 책을 보고, MSDN 을 보고 잘 이해했다고 생각을 하고 코드를 짜도 전혀 기대하지 않은 동작을 해서 미궁에 빠졌을 때가 여러번 있었다. 새로운 환경에 부딪히면서 일을 할 때 이렇게 미궁에 빠지게 되는 때의 원인은 다음과 같은 경우들이 있는 것 같다.

나는 대부분의 문제는 1번에서 발생한다고 생각하는(사실은 거의 확신) 편인데, 이번 프로젝트에서는 2번과 3번의 문제가 더 많았던 것 같다. 정보를 얻을 수 있는 곳이 없어서 정말 많은 실험과 해킹을 하면서 답을 알아낸 경우가 많이 있었고, 윈도폰 자체의 버그 때문에 Windows Phone 8.1 Update 1이 나오고 나서 자연스레 해결된 문제들도 있었다. 어떤 문제는 아직도 해결되지 않아 Windows 10 에서나 해결될 수 있을 거라는 답변도 받았다.

예전에 Win32 Api 들을 다룰 때는 MSDN 이 정말 좋은 정보들이 많은 문서시스템이라는 생각을 했었는데, 닷넷 쪽과 Windows Runtime Api 문서들을 보면서 생각이 좀 바뀌었다. 파이썬이나 루비 온 레일즈와 같은 오픈소스 언어/프레임워크 들의 문서화가 훨씬 더 잘되어 있는 것 같다. Windows Runtime 용 샘플 코드들 또한 매우 조잡한 수준이었다.

그럼에도 불구하고 (수많은 삽질로 인해 시스템에 익숙함을 갖게된 상태에서 바라보면) 기존의 Win32 프로그래밍 환경과 비교했을 때, 프로그래밍이 많이 쉬워진 것은 같다. 닷넷의 풍부한 모든 기능들을 사용할 수 있고, 레이아웃을 다루는 일과 스케일링 처리도 훨씬 쉬워졌다. 클라이언트 프로그램을 작성할 때는 UI를 멈추지 않게 작성하는 것이 아주 중요한데, C#의 Task 기반 프로그래밍과 Windows Runtime의 Api 들은 이를 쉽게 가능하게 만들어주는 것도 좋은 점 중의 하나였다.

이런 저런 고생들을 하며 지난 달에 Windows Rumtime 으로 완전히 새롭게 태어난 카카오톡을 오픈하고 애프터 서비스를 좀 하다가 얼마 전 다시 서버팀으로 돌아왔다. 이제 윈도우즈로 개발 할 일이 또 거의 없어져서 집에서 사용하던 랩탑은 Windows 10 으로 새로 설치해버리고 새 운영체제를 조금씩 알아가고 있는 중이다. API 가 어떻게 바뀌었는지는 아직 잘 모르겠지만 사용자 입장에서 봤을 때, 모던앱들이 창크기가 변경 가능하다는 점은 정말 편리한 것 같고, 이제서야 뭔가를 모던앱을 만들어보는 것도 좋겠다 하는 생각이 처음으로 든다.

두줄 요약:

1. Windows Runtime 은 조금 더 개선되고 다듬어질 필요가 있다.

2. 만약 모던앱 혹은 윈도폰 앱 개발에 흥미를 느끼고 있다면 Windows 10 Developer Preview 정도는 나온 뒤에 공부를 시작하는 것을 추천한다. 안 그러면 고생만 한다.

예전에 존 레식의 매일 매일 코딩하기라는 글을 본 기억이 문득 떠올라서 나도 내 Github 그래프를 한번 열어봤다.

8년이 되는 경력 동안 꾸준히 저 정도 그래프를 그린 것 같은데 기대만큼 실력은 늘지 않는 것 같다.

존 레식 같은 해커가 되려면 몇 년이나 이렇게 살아야 하는 걸까. 그래서 눈물나는 그래프.

Area51 이라는 곳은 스택오버플로를 만드는 사람들에게 "이런 주제의 또 다른 질문/답변 사이트를 만들어주세요!" 라고 제안을 할수 있는 공식적인 장소이다. 그리고 이러한 제안을 수락하는 방식 또한 여러 사람들의 집단 의견을 따른다. 즉, 많은 사람들이 참여하고, 재밌고 좋다고 박수쳐줘야 승인된다.

최근 몇몇 사람들이 한국어 스택오버플로우의 제안을 통과시키기 위해 노력을 하고 있는 것을 우연히 보고 나도 작은 도움이나마 주고 싶어서 글을 적어본다.

제안이 완전히 통과되기 위해서는 defined 단계와 commit 그리고 beta 단계를 거쳐야 하는데, 현재 한국어 스택오버플로는 defined 단계가 완성되기 직전이다.(현재 적혀진 질문들에 대해서 약간의 upvote 만 더 있으면 된다. 10점 이상의 upvote 를 받은 질문이 40개가 필요하다.)

현재, 영어 말고 다른언어로 스택오버플로 서비스가 제공되고 있는 것은 포르투갈어 뿐인 것으로 보이는데, 한국어도 충분히 가능성이 있다고 본다. 많이들 공유해주고 참여해주어서 좋은 한글 개발자 사이트가 생겼으면 좋겠다.

아래 링크에 도움 줄 수 있는 방법이 적혀있다. 쉽다.

https://github.com/so-in-korean/sok/wiki/How-to-Contribute

내가 좋아하는 국내 프로그래밍 블로그들에서 살짝 언급했던 방준영의 블로그가 다시 돌아왔다.

최근에는 국내 프로그래밍 블로그들이 거의 전멸 하다시피 해서 해커뉴스만 울며 겨자먹기로 보면서(왜냐면 영어를 잘 못하기 때문에) 삶을 살아가고 있었는데, 이런 좋은 블로그가 돌아와줘서 정말 기쁘다.

이번에는 중간에 잠적(?)하지 않고 꾸준히 좋은 글들을 많이 써줘서 더 많은 사람들이 그의 블로그를 찾고, 나처럼 즐거움을 느꼈으면 좋겠다.

1. 마이너스 통장의 한도를 조금 더 늘려두어야겠다는 생각이 들어 은행을 찾아갔다. 15분여를 기다리고 차례가 되어 창구에 앉았는데, 신분증을 내밀고 거의 10초만에 ‘정말 죄송하지만, 우리 지점에서는 처리할 수가 없고 원래 대출을 받으셨던 지점에 가셔야 처리가 가능합니다.’ 라는 대답이 나왔다. 이유를 가르쳐달라고 물어봤더니, 

 “같은 은행이긴 하지만 지점들 간에도 거래 실적이라는 것이 있고, 다른 지점의 실적을 뺏어오는 일이 되기 때문이니 양해를 부탁드립니다.” 라는 것이다. 얼핏 들으면 고개가 끄덕여질 지도 모르겠지만 잘 생각해보면 웃기는 소리이다. 지점간에 실적 다툼으로 고객의 편의는 전혀 고려하고 있지 않으니 말이다.

항의하거나 설득해도 나만 스트레스 받을 것 같아서 예 알겠습니다 하고는 회사 근처에 있는 원래 대출을 받았던 은행을 찾아가서 심사를 받느라 창구에 앉아 대기하고 있었는데 또 재밌는 일이 일어났다.

직원 하나가 전화통화를 끊더니 창구 뒷자리에 앉은 높은(?) 상사에게 보고를 하는 모습이 보였는데, 통화를 한 고객이 임대차 계약서를 보내주기는 싫고 딱 필요한 정보만 주고 싶다고 했다보다. 그 말을 들은 상사가 “아이고, 가지가지한다 진짜. 뭘 그리 비밀이많아. 쯧쯧.” 하면서 혀를 끌끌 차는 것이다. 창구에 앉아있던 사람들은 다 그 소리를 들을 수 있었는데 그런 모습을 보고 있자니 직원들이 고객을 도대체 어떻게 생각하고 있는지가 궁금해졌다.

2. 최근에 가족들이 아파서 병원을 몇번 왔다갔다 하게 되었다.

주말이고 재밌는 TV 프로들이 하고 있는 시간이라 병실에 있는 사람들이 다들 TV를 보고 쉬고 있었는데, 나이가 지긋해보이는 한 의사가 젊은 친구 둘과 함께 옆 침대에 있던 환자의 회진을 들어왔다.

나는 티비에 관심이 없어서 무슨 이야기를 하나 유심히 바라보고 있었는데, 마치 군대마냥 열중쉬어를 하고 있던 젊은 친구 둘 중 하나가 의사가 말하고 있는데 TV 소리가 거슬린다고 생각했는지 성큼성큼 걸어가서 사람들의 의견을 물어보지도 않고 TV를 툭 꺼버리고는 다시 돌아가 열중쉬어 자세를 취하는 것이 아닌가.

별 알맹이 없는 회진 대화가 끝나고 그 삼인방은 TV를 다시 켜주지도 않은채 그냥 나가버렸다.

한줄 요약: 병원이든 은행이든 제발 제대로된 회사가 나타나서 이런 늙어빠진 회사들은 하루 빨리 다 망해버렸으면 좋겠다.

여러분은 이게 어떤 기분인지 알 것입니다. 이는 우리 모두가 한번쯤 겪었던 일입니다. 여러분은 코드를 수십 번 읽어 보았으나 여전히 무엇이 문제인지 발견하지 못하고 있습니다. 하지만 그 코드에는 여러분이 도저히 처리할 수 없는 버그 혹은 오류가 존재하고 있습니다. 여러분은 코딩하고 있는 컴퓨터에 문제가 있거나 프로그램을 실행하는 운영체제, 혹은 사용하는 도구나 라이브러리에 문제가 있다고 생각해버립니다.

“분명히 그럴꺼야!”

하지만 아무리 좌절스럽더라도 그런 접근을 해서는 안됩니다. 우연에 맡기는 프로그래밍은 이제 그만하십시오. 그건 정말 나쁜 행동입니다. 어렵고 모호한 버그와 맞서는 것이 좌절감을 줄 수도 있지만, 그런 좌절감 때문에 잘못된 길로 들어서서는 안됩니다.

좋은 프로그래머가 되기 위한 필수 조건은 여러분이 작성한 코드에 문제가 있을 때마다 그것이 항상 자신의 잘못이라고 생각하는 일입니다. 이 내용은 실용주의 프로그래머에서 ‘select 함수는 잘못되지 않았다’ 부분에 잘 요약되어 있습니다:

대부분의 프로젝트에서 당신이 디버깅하고 있는 코드는 당신의 프로젝트 팀, 써드파티 결과물(데이터베이스, 네트워킹, 그래픽 라이브러리, 특화된 통신 방법들이나 알고리즘 등), 플랫폼 환경 상에서(운영체제, 시스템 라이브러리, 컴파일러) 당신과 다른 이들에 의해 작성된 응용 프로그램 코드의 결합물일 것이다.

운영체제나 컴파일러 혹은 써드파티 제품에 버그가 있을 수도 있다. 하지만 그것이 첫 번째로 의심하는 사항이 되어서는 안된다. 당신의 코드에 버그가 존재할 가능성이 훨씬 더 크다. 라이브러리 자체에 버그가 있다고 의심하는 것보다는 라이브러리를 호출하는 응용 프로그램의 코드가 문제가 있다고 생각하는 것이 보통 더 이득이다. 설사 써드 파티 코드에 문제가 있었다 할지라도, 어짜피 버그리포트를 제출하기 전에 자신의 코드를 제거하는 일을 해야만 한다.

우리는 한 프로젝트에서 솔라리스 운영체제에 있는 select 시스템 함수에 버그가 있다고 확신하는 한 고참 개발자와 일한 적이 있었다. 어떤 설득이나 논리도 그의 생각을 바꿀 수는 없었다. (같은 컴퓨터에서 다른 네트워크 프로그램들은 모두 잘 작동했지만 그건 그에게 별 상관이 없었다.)

그는 몇 주동안 문제를 해결하려고 이리저리 코드를 변경해보았지만, 이상하게도 그 문제는 해결이 되지 않는 것처럼 보였다. 그가 우리의 강요에 의해 억지로 자리에 앉아 select함수의 문서를 읽었을 때, 그제서야 그는 어떤 것이 문제였는지 깨달았고 그 문제를 몇 분만에 해결했다. 그 이후 우리는 누군가가 자신의 실수일 수 있는 문제를 시스템의 버그라고 탓하는 것을 볼 때마다 “select 함수의 버그” 라는 말을 사용하게 되었다.

코드 주인의식의 다른 말은 코드 책임의식입니다. 여러분의 소프트웨어의 문제가 무엇이던지 간에 -그 문제가 자신의 코드에 없었다 할지라도- 항상 자신의 코드안에 문제가 있다고 가정해야 하고 그에 따라 행동해야 합니다. 만약 여러분의 소프트웨어가 최고가 되길 원한다면 제품의 버그에 대해 전적으로 책임을 져야만 합니다. 사실 엄밀히 말하면 그럴 필요까지는 없습니다. 다만 이것이 여러분이 존경과 신뢰를 얻게 되는 방법입니다. 만약 그 문제에 대해 다른 사람들, 회사나 다른 소스로 그 잘못을 떠넘긴다면 여러분은 분명 존경과 신뢰를 얻지 못하게 될 것입니다.

여러분도 알다시피, 오류가 여러분의 잘못이 아닌 소프트웨어의 오류일 확률은 통계적으로 극히 드뭅니다. 스티브 맥코넬은 그의 책 코드 컴플리트에서 이 사실을 증명하는 두 가지 연구사례를 인용했습니다:

1973년과 1984년에 수행된 연구는 보고된 총 버그의 약 95%가 프로그래머에 의해서 발생한 것들이라는 것을 발견했다. 2%는 시스템 소프트웨어(컴파일러나 운영체제) 이고 2%는 그 외의 다른 소프트웨어들이었으며 1%는 하드웨어였다. 오늘날 시스템 소프트웨어와 개발도구들은 1970~80년대에 비해서 훨씬 많은 사람들에 의해 사용되어지고 있기 때문에 지금은 프로그래머의 오류 비율이 예전보다 더 높아졌을 것이라 추측한다.

여러분의 소프트웨어가 가지고 있는 문제가 무엇이든지간에 주인의식을 가지시기 바랍니다. 먼저 여러분의 코드에서부터 출발해서, 그 문제 원인에 대한 결정적 증거를 손에 넣을 때까지 계속해서 바깥으로 범위를 넓혀가며 살펴보십시오. 만약 그 문제가 자신이 컨트롤 할 수 없는 다른 코드에 존재한다면 문제 진단 및 디버깅 기술을 배워야 할 뿐만 아니라 자신의 주장을 뒷받침 해줄 수 있는 증거 또한 확보해 두어야 할 것입니다.

이 과정은 어깨를 한번 으쓱하며 운영체제, 개발도구, 프레임워크의 잘못으로 돌리는 것 보다는 훨씬 더 번거로운 일입니다. 그러나 이는 여러분에게 남 탓으로 돌리기나 문제 회피 등으로는 절대로 얻지 못하는 신뢰와 존경을 얻도록 할 것입니다.

만일 진심으로 좋은 프로그래머가 되고 싶다면 “그건 내 실수야. 내가 그 원인이 뭔지 찾아내고 말거야.” 라고 말하는 것을 꺼리지 마십시오.

이 글은 스택오버플로우를 개발한 제프 앳우드가 2008년 3월에 쓴 The First Rule of Programming: It’s Always Your Fault 를 원저자의 허락을 받고 번역한 글입니다.

--

2년여 전 즈음에, 카카오의 동료들하고 심심풀이로 기술 관련 좋은 글들을 구글 독스에서 소셜 번역(?) 을 하곤 했었는데, 그 중 하나였던 이 글이 최근 자꾸 생각나서 다시 읽어보다가 블로그에 올려야지 생각하게 되었다.(Jenny, Clare, Probe 감사!)

이 글은 코딩 호러의 이펙티브 프로그래밍이라는 번역서 내에도 담겨있으며, 이 책에는 다른 좋은 글들도 많으니 관심이 있는 사람들은 읽어보는 것도 좋겠다. 제프 앳우드의 다른 책으로는 코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기라는 책도 있다. 둘 다 너무 재미있고 좋은 이야기들이 많이 담겨있는 책이다.

Scott Hanselman 이라는 사람이 오래전 부터 그의 블로그에 좋은 윈도용 소프트웨어들을 소개해주어 유용하게 읽곤 했었는데, 오늘은 올린 글은 입이 떡 벌어질 만큼 특별히 잘 정리되어 있어서 소개를 하고 싶다.

나는 윈도를 떠나 산지 시간이 좀 흘러서 새로나온 (끝내줘보이는) 도구도 꽤나 보였고, 약간의 향수(?) 마저 느꼈다.

윈도우즈 프로그래머 혹은 윈도를 사용하는 프로그래머라면 꼭 읽어보고, 모르는 것들이 있었다면 하나씩 설치해서 연습해보면 세상 사는 게 좀 더 편해질 것이라 확신한다.

http://www.hanselman.com/blog/ScottHanselmans2014UltimateDeveloperAndPowerUsersToolListForWindows.aspx

코딩 호러의 이펙티브 프로그래밍 - 제프 앳우드 지음, 임백준 옮김/위키북스

내가 가장 좋아했던 프로그래밍 블로그는 단연 레이몬드 첸의 OldNewThing 이었는데, 최근에 윈도우즈와 동떨어져 사는 생활을 해서 그런지 1등 블로그가 바뀌어 버리게 되었는데 그것은 바로 스택 오버플로를 만들었던 제프 앳우드의 코딩 호러라는 블로그이다. -이전에도 두 블로그를 모두 구독했고 지금도 여전히 레이몬드의 글을 보지만 두 블로그들 중 제프 앳우드의 블로그에 새 글이 올라왔을 때 더 반가운 느낌을 받는 듯 하다.

6개월 쯤 전이었던가 이 책이 전자책으로 나온 것을 알았을 때 즉시 구입했던 기억이 난다. 아이패드에 넣어 다니며 조금씩 읽긴 했는데 영어책을 읽는 것은 시간과 에너지를 낭비하게 하고 스트레스를 가져다 줬다.

그래서 이번에 한글책이 나오자마자 기쁘게 다시 구입해서 주말 내내 폭풍처럼 읽어버렸다.(그렇지 않았으면 1년이 지나도 결국 못 읽은 책으로 남았을 것이다)

결론만 이야기 하면 이 책은 정말 재미있고 유익한 조언이 많이 담긴 책이다. 내가 지금까지 가장 즐겁고 행복하게 (몇 번씩이나) 읽었던 컴퓨터 책은 해커와 화가나 조엘 온 소프트웨어 정도가 떠오르는데 이제 이 책이 하나 더 추가될 것 같다.

프로그래밍을 사랑하고 좋은 프로그래머가 되기를 원한다면 꼭 한번 읽어보기를 권장한다.

요즘 내가 아주 만족스럽게 쓰고 있는 서비스가 두 개 있는데, 하나는 카카오 플레이스이고 다른 하나는 왓챠이다.

카카오 플레이스는 새로운 맛집을 찾으러 갈 때 주로 사용하는데, 기존의 윙버스나 맛집 블로그처럼 모르는 사람들한테 속지 않을 수 있다는게 큰 장점이다. 여유로운 시간에 내 친구들이 추천해주는 맛집을 하나씩 담아놓고 나중에 하나씩 찾아다니는 맛이 아주 좋다. 물론 속은 적은 한번도 없었고 퀄리티가 모두 내 기대를 만족시켜줬기 때문에 정말 행복하게 사용하고 있다. 뭐 속고 나더라도 그 사람이 추천해주는 맛집은 더 이상 안 믿으면 되기도 하고.ㅋ

플레이스는 아직 오픈한지 얼마 안된 따끈따끈한 서비스이다. 나는 특수관계인(?)이기 때문에 이미 많은 플레이스 친구들을 가지고 있지만 대부분의 사람들은 친구가 별로 없을 것이다. 친구가 많을 수록 그 재미를 알 수 있는 서비스인데 이것은 시간이 해결해줄 것으로 기대한다.

또 다른 서비스인 왓챠는 영화 추천 서비스인데 기존에 재밌게 봤던 작품이나 그 장르에 기반해서 자동으로 영화를 추천해주는 서비스이다. 카카오 플레이스처럼 친구 누구가 재밌게 봤다는 힌트도 건네준다. 얼마전 리뷰수 800만을 넘었는데 점점 더 빠른 속도로 성장하고 있는 것 같다.

지금 글을 쓰면서 하이퍼링크를 걸어주려고 들어가봤는데 이렇게 장애가 나있기도한 서비스이다. -_-;

내가 왓챠를 좋아하는 가장 큰 이유는 특정 연대, 장르를 지정해서 영화를 추천받을 수 있다는 것이다. 보고 싶은 영화들을 담아놓고 별점순으로 정리할 수 있다는 것도 정말 큰 매력. 최근에 나는 주말에 한번씩 왓챠에 들어가서 보고 싶은 영화들을 담아두는 동시에 한 편씩 감상하고 있는데, 끝내주는 영화를 만날 때 마다 너무 행복해진다.

나는 어디를 잘 돌아다니지 않고 거의 회사와 집에만 있는 타입이라 바깥 세상이 어떻게 돌아가는지 잘 모르는 편인데, 이런 서비스들로 인해서 문화 생활을 많이 하는 사람들과의 지식? 혹은 정보 격차를 크게 줄일 수 있는 것 같아서 참 좋게 생각한다.

마치 구글이 나와서 사람들의 지식 수준을 상향 평준화 시켰을 때의 느낌이랄까? 물론 플레이스나 왓챠는 구글만큼 크게 세상에 공헌할 수는 없겠지만 그래도 내가 생활하는데 있어서 기존보다 좀 더 나은 세상을 제공해주고 있는 것은 맞다. 그래서 사랑한다.

이미지 출처 https://code.google.com/p/corkami/wiki/PE101

엄청나게 잘 정리된 그림을 발견했다. 아름답지 아니한가.

스마트 플랫폼 전략 - 황병선 지음/한빛미디어

제목과 꼭 들어맞는 내용으로 알차게 구성되어 있는 잘 쓰여진 책이다.

첫 삼분의 일은 플랫폼이란 무엇인지 왜 중요한지에 대해서 할애하고 나머지 삼분의 이는 애플과 구글 그리고 마이크로소프트에 대해서 이야기 한다. 이 세 회사를 삼국지로 빗대서 이야기한 책들이 이전에도 몇 권 있었는데, 이 책에서는 그들의 플랫폼 전략을 바라보는 관점에서 이야기를 하기 때문에 단순히 재미뿐만 아니라 영양가도 많이 있었다. 과거의 역사를 돌아보고 왜 성공했는지 혹은 왜 실패했는지와 앞으로 각 회사들의 플랫폼 영향력이 어떤 식으로 발전할지에 대해서 저자 나름의 주장을 하는데, 기술적으로나 전략적으로나 아주 잘 분석했다는 생각이 든다.

모바일 플랫폼에 관심이 있는 사람들이 꼭 한번 읽어보기를 추천한다.

P.S 구글이 비록 모토로라를 인수했지만 저자는 이런 저런 이유를 대면서 자체 스마트폰은 아마도 제작하지 않을 것이라 예상했는데, 그 예측은 보기 좋게 빗나간 것 같다. 개인적으로는 루머가 사실이길 바라고 있으며 빨리 완성된 제품을 보고 싶다.

요즘 전자책 읽는 재미에 빠져서 살고 있다. 책이라면 당연히 종이 냄새 나는 종이책이지! 라고 생각했었는데 이 빌어먹을 디지털 세상의 편리함에 또 한가지를 굴복해 버리고 말았다.

몇몇 책들을 구입해서 실제로 읽다보니 과거에 어렴풋이 생각했던 공간 절약이나 검색 기능 말고도 다른 장점들이 있었다.

1. 구입 즉시 볼 수 있다. 이건 정말 중요하다. 충동구매가 많이 늘었다;

2. 소스 코드를 타이핑 하지 않고 원하는 만큼 복사해서 붙여넣기 할 수 있다. 타이핑 안하면 실력이 안 늘어난다고? 그런지 아닌지는 모르겠지만, 걱정되면 직접 치면 되니깐.

3. 사용자가 선호하는 폰트로 책을 볼 수도 있다. 나는 나눔폰트를 참 좋아하는데 책으로 읽을 땐 어떤 느낌일지 궁금하다. 한 번 보고 싶다.

4. 책을 보며 밑줄 긋고 낙서해도 쉽게 복원할 수 있다.

5. 하이퍼링크를 통해 참고자료나 인용 등을 바로 확인 할 수 있어서 편리하다. 물론 원래 보던 페이지로 쉽게 돌아갈 수도 있다.

6. 출판사 입장에서 책을 컬러로 만드는 것이 덜 부담스럽다. 소스코드는 Syntax 하이라이트를 해서 예쁘게 표현하기도 쉽다. 당연히 사용자한테도 좋다.

7. 책 페이지수가 종이책에 비해 중요하지 않아졌다. 출판사 입장에서는 레이아웃 구성을 좀 더 자유롭게 할 수 있다.

8. 대중 교통에서 한 손으로 들고 보기에 편리하다.

9. 그래도 종이책으로 보는 것이 무조건 좋다고? 선호하는 종이에 인쇄해서 보면 된다.

10. 종이책보다 싸다. 이전에는 전자책하고 종이책하고 차이가 별로 안나서 이렇게 비싸게 파나? 생각한 적도 있었는데, 지금은 전혀 그렇게 생각하지 않는다. 어짜피 들어있는 지식은 같고, 쓸데없는 공간 안 차지하는 것만으로도 충분히 훌륭하다.

스택오버플로우 오픈소스라는 검색어를 통해 내 블로그에 찾아오는 사람들이 있다. 아마 우리나라 사람들 중 누군가가 스택오버플로우 같은 멋진 커뮤니티를 만들고 싶은가보다. 이미 그런 시도들이 있었고 아래와 같은 사이트들이 만들어졌지만 아쉽게도 기대했던 것 만큼 장사가 잘 되고 있는 것 같지는 않다.

http://codejob.co.kr/code/

http://nullpointr.com/

아참, 그래서 스택오버플로우의 오픈소스가 있냐고?

있다.

http://askbot.com/

정확히 말하면 스택오버플로우의 오픈소스는 아니고 그냥 똑같이 따라서 만들어보려는 클론, 다시 말하면 짝퉁이다. 스택오버플로우에 비하면 부족하긴 하지만 그나마 가장 잘 따라했으며 완성도가 높다. GitHub에 가면 코드를 내려받을 수 있다.

읽기 좋은 코드가 좋은 코드다 - 더스틴 보즈웰 & 트레버 파우커 지음, 임백준 옮김/한빛미디어

한빛미디어에서 새로 나온 신간이며 국내 개발자들에게 꽤 유명한 임백준씨가 내용을 옮겼다.
원서는 The Art of Readable Code라는 책인데 아마존에서도 그럭저럭 호평을 받고 있는 것으로 보여진다.

책 제목처럼 읽기 쉬운 코드를 쓰는 방법에 대해서 구체적으로 설명한다. 책 분량도 적당하고 내용도 어렵지 않다.

아주 깔끔하게 잘 나온 책이라고 생각한다.

하지만 새로운 지식이나 멋진 뭔가를 얻으려고 생각하면 안된다. 책을 읽어가다 보면 아마 기존에 자신이 코드를 작성하면서 대부분 한번씩 고민해 봤을 내용들일 것이다. 이 책의 저자들은 보통 사람들보다 조금 더 많이 고민해 본 것이 확실해 보인다.

책을 읽어 가면서 자신이 이전에 생각했던 내용들과 비교하면서, 읽기 좋은 코드를 작성하는 방법에 대해서 다시 한번 진지하게 생각해보는 계기를 가진다면 좋을 것이다.

아참, 책 내용 중에 이런 글이 있었다.

으음, 원하지 않는다.

변수 이름을 잘 지어야 한다고 노래를 부르더니 정작 본인들은 이름을 이렇게 밖에 못 짓나? 크크크.

http://www.brianbondy.com/blog/id/140/

위 포스트를 읽고서 윈도8에 꽤 큰 변화가 생겼다는 것을 알았다.

지금까지는 UAC를 꺼둔다면 XP와 같은 환경이라고 생각해도 별 문제가 없었지만, 이제는 더 이상 아니라는 뜻.

만일 이런 이상한 얍삽이 코드를 즐겨 사용했다면, 이제 그 결정에 대해서 벌을 받을 시간이다.

마이크로소프트에서 카사블랑카라고 이름지어진 흥미로운 라이브러리를 발표했다.

여기 공식 페이지에 간략하게 소개가 있으며, 허브 셔터가 자신의 블로그에 따로 소개해주기도 하였다.

아마 Restful api를 제공하는 서비스들의 클라이언트 코드로써 가장 많이 사용되지 않을까 싶다.

얼마전 있었던 마이크로소프트의 Going Native 2012 행사에서 허브 셔터가 말하길,

C++ 언어는 다른 최신 언어들에 비해 부족한 점이 거의 없다. 부족한 것은 바로 라이브러리이다. 라는 말을 했었는데 아주 인상 깊게 들었다. 프리젠테이션 자료를 너무 인상적으로 만들어서 더욱 설득 당했는지도 모르겠다.

아래 주소에서 그 동영상을 볼 수 있다. 1시간 17분 쯤부터 보기 시작하면 된다.

http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond

어쨌거나 좋은 C++ 라이브러리들이 빨리 빨리 구현되기를 바란다. 그래야 Going Native Again 할 것 아닌가.

크롬이 4.0이 될 때 부터 어쩌면 1등 브라우저가 될 수 있을 것 같다고 생각한 적이 있다.

그 때는 그다지 확신을 가졌던 건 아니었는데 이제는 누가 봐도 1등이 되는건 시간문제라고 생각할 것 같다.

가장 맘에 드는 기능은 동기화 기능이다. 확장 플러그인과 주소 목록, 비밀번호 동기화 등 다른 컴퓨터에 앉았을 때도 쉽게 내 환경을 불러 올 수 있어 편리한데다가, 모바일에서 또한 내가 자주 가는 사이트의 주소 자동 완성과 비밀번호 자동 입력이 지원되므로 불편하게 꼬물 핸드폰 키보드로 타이핑 할 필요가 없어서 너무 좋다. - 현재는 안드로이드 4.0 이상 기기만 크롬을 설치할 수 있다.

게다가 크롬 확장 플러그인으로 SSH Client도 생겼다. 크롬북에서 특히 유용할 것 같지 않은가?

삼성에서 언젠가 크롬북을 50만원 정도에 팔았었는데 이건 거품이 심하게 끼었다고 생각한다. 가격이 20만원 대로 내려가고 무게가 조금 더 가벼워진다면 크롬북을 꼭 가지고 싶어질 것 같다.