텍스트큐브 시절 부터 약 13년간 둥지를 틀어온 이 곳을 이제는 떠납니다.

새로 이사가는 곳의 주소는 https://jeho.page 입니다.

변경된 포스팅 주소

https://jeho.page/essay/2020/11/10/%EC%95%B1%EC%8A%A4%ED%86%A0%EC%96%B4%EB%8A%94-%EC%8A%A4%ED%8B%B0%EB%B8%8C%EC%9E%A1%EC%8A%A4%EA%B0%80-%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%93%A4%EC%97%90%EA%B2%8C-%EC%A3%BC%EA%B3%A0%EA%B0%84-%EC%84%A0%EB%AC%BC.html

변경된 포스팅 주소

https://jeho.page/essay/2019/08/13/%EC%B6%9C%EA%B7%BC%EA%B8%B8%EC%97%90-%EB%98%A5%EC%9D%B4-%EB%A7%88%EB%A0%A4%EC%9B%8C-%EC%A7%91%EC%9C%BC%EB%A1%9C-%EB%8F%8C%EC%95%84%EA%B0%84-%EC%9D%B4%EC%95%BC%EA%B8%B0.html

이전된 블로그 주소

https://jeho.page/essay/2019/07/26/%EB%A9%80%EB%A6%AC-%EA%B0%80%EB%A0%A4%EB%A9%B4-%ED%98%BC%EC%9E%90-%EA%B0%80%EB%9D%BC.html

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

KT 요금 고지서

현대HCN 이메일 청구서

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

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

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

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

변경된 포스팅 주소

https://jeho.page/essay/2018/05/08/%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%97%90%EC%84%9C-%EC%A0%84%EC%97%85%EC%A3%BC%EB%B6%80%EB%A1%9C.html

요즘엔 사람들이 페이스북같은 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 에서 볼수 있으며, 아래 리스트에는 추가하지 않았다.

변경된 포스팅 주소

https://jeho.page/essay/2016/02/11/%ED%9A%8C%EC%82%AC%EC%9B%90%EC%9D%98-%EA%B0%80%EA%B3%84%EB%B6%80.html

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

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

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

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

포스팅 이전

https://jeho.page/essay/2015/02/03/%EC%8B%9C%EB%8B%88%EC%96%B4-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8.html

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와 같은 환경이라고 생각해도 별 문제가 없었지만, 이제는 더 이상 아니라는 뜻.

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