토요일, 12월 28, 2013

[일상다반사] 기술과 환경

몇 년 전, 지하철을 타고 가다 급한 프로그램 수정 요청을 받아 자리에서 노트북을 꺼내 작업을 한 적이 있었다. 프로그램에 몰입한 상태라 몰랐는데, 10분 정도 지난 다음 정신을 차리고 보니 옆에 중년 신사 한 분이 뚫어지게 내가 하는 작업을 지켜보고 있었다. 그리고 어색하게 말을 거셨다.

실례지만 혹시 무슨 일을 하십니까? 지금까지 제가 본 누구보다 _타이핑_을 빨리합니다.

프로그램을 작성하다보면 정해진 키워드, 변수, 함수, 라이브러리는 거의 한 단위로 입력 가능하므로 옆에서 보기에 엄청난(음... 열악한 노트북 키보드로 500타 이상이 나오지 않을까 싶다) 타이핑 장관이 펼쳐지는 것도 당연하지만... 프로그램 작성 = 타이핑이라는 참신한 시각에 무척 놀랐던 기억이 아직도 새롭다. 하긴 어르신들 세대에 프로그래밍은 지극히 이국적인 행위였을테니 둘 사이 구분을 하지 못하는 현상을 충분히 이해한다.

갑자기 이런 이야기를 꺼내게 된 이유는 요즘 한창 마무리 작업 중인 '피플웨어'에 기술과 환경에 대한 이야기가 나왔기 때문이다. 다음 문구를 읽고나서 거의 기절초풍했다.

디즈니 특별 연구원 앨런 케이는 기술을 '지금 있는데 옛날에 없던 것'으로 정의합니다. 케이는 한 걸음 더 나가 옛날에 있던 것은 이름이 있다고 말합니다. 바로 환경입니다. 우리 세대의 기술은 다음 세대의 환경입니다.

그런데, 이와 관련해 고백을 하나 해야겠다. 컴퓨터를 처음 접한지 수십년이 지났지만 여전히 스마트폰과 태블릿을 사용하면서 뭔가 부자연스럽다는 생각이 머리를 떠나지 않는다. 어렴풋이 이유를 알고 있었지만 피플웨어에 나온 문구를 읽어보는 순간 깨달음이 오고 말았다. 바로 스마트폰과 태블릿을 자연스런 환경이 아니라 인위적인 기술로 보기 때문이다. 요즘 젊은 친구들이 스마트폰을 사용하는 모습을 볼 때마다 스마트폰을 마치 몸의 일부처럼 활용한다는 부러움이 들었는데, 중년 신사분이 내게 느낀 감정 그대로다. 나와 달리 젊은 친구들은 환경 그 자체로 받아들이고 있음이 틀림없다.

최근 초등학교부터 프로그램을 가르치자, 10만 프로그래머를 양성하자, 빅 데이터 전문가 수 천명을 배출하자는 둥 IT 업계와 관련된 여러 담론이 사방에서 나오고 있는데, IT 기술이 더 이상 첨단 기술이 아니라 자연스런 환경이 되버린 상황에서 예전 기술 우위에 입각한 사고 방식으로 얼마나 신새대를 설득할 수 있을지 참으로 궁금하다. 피플웨어에서 뒤에 이어지는 글을 계속 살펴볼까?

20세기 말에는 가정과 학교서는 찾아보기 어려우나 회사에는 존재하는 중요한 기술이 있었습니다. 이제는 그렇지 않습니다. 젊은 프로그래머들에게 컴퓨터, 스마트폰, 웹, 프로그래밍, 해킹, 소셜 네트워킹, 블로깅은 이제 기술이 아니라 환경입니다. 젊은 친구들에게 이런 주제를 놓고 제작 기술에 대해 가르치기가 어려울뿐더러 기술 사용에 따르는 윤리에 관해 떠들어 봤자 소 귀에 경 읽기입니다.

그렇다. 이 기술이 중요하다는 둥 저 기술이 중요하다는 둥 사과 심어라 배 심어라 할 시기는 이미 오래 전에 끝난 듯이 보인다. 따라서 설레발치며 다 된 밥에 재뿌리지 말고 그냥 내버려두기를 간곡하게 희망한다. 다 큰 어른들이 알고 있던 기술 시대는 이미 저물어가니까.

EOB

금요일, 12월 27, 2013

[일상다반사] 클린 코드 복간 기념 이벤트

기쁜 소식을 독자 여러분들께 전해드리겠다. 클린 코드 복간 버전이 Yes24 컴퓨터와 인터넷 부분 'YES24의 선택'에 올라 왔다(정말 얼마만인지 기억도 안 난다. T_T). 기분이 좋은 상태에서 어제 밤 출판사에서 보내준 택배 꾸러미를 열어 복간 버전을 읽어보니 예전 버전에 비해 너무 훌륭했기에 독자 여러분을 위한 이벤트를 열지 않을 수 없었다.

혹시 클린 코드 구판을 구입했는데, 너무나 억울한 사연이 있어(또는 너무나 좋은 사연이 있어) 꼭 복간 버전을 선물로 받아야겠다고 생각하시는 분들이 계시면 2014년 1월 1일 밤 11시 30분까지 jrogue 에뜨 gmail.com으로 사연과 함께 응모해주시기 바란다. 1월 2일에 멋진/슬픈 사연을 소개해드리며 당첨자(기준은 B급 프로그래머의 심금을 울리는 정도에 따라 결정된다)를 발표하겠다.

보너스: 클린코드 애독자라면 책 내용을 정말 일목요연하게 정리한 커닝 페이퍼도 꼭 챙기시기 바란다.

EOB

토요일, 12월 21, 2013

[B급 프로그래머] 12월 3주 소식 정리

2013년 마지막 소식을 정리하겠다. 원래 2013년 한 해를 죽 둘러보려 했으나... 블로그 주인장의 컨디션 난조로 인해 아쉽지만 건너뛰도록 하겠다. 대신 오늘은 넉넉하게 다양한 소식을 정리해드린다.

  1. 웹 개발
  2. 개발/관리 도구
  3. 고성능 서버/데이터베이스
  4. 기타 읽을 거리

올 한 해 성원해주신 독자 여러분들께 감사 말씀을 드리며, 2014년도에는 더욱 좋은 소식으로 찾아뵙겠다.

EOB

수요일, 12월 18, 2013

[독서광] Make : Technology on Your Time Volume 07

2013년을 헛되이 그냥 보낼 수는 없으니, 12월은 몰아서 틈나는 대로 엄청난 독서를 하고 있다. 오늘은 이번에 새로 출간된 Make Vol 07을 독자 여러분들께 소개해드리겠다.

어릴 때, 조립식 장난감을 너무나도 좋아했다(여기 투자한 돈을 차곡차곡 모았다면 지금쯤 고사양 컴퓨터를 몇 대 사고도 남으리라...). 지금 돌이켜 생각해보니, 조립되기 전의 부품과 설계도 만으로 조립된 후의 모양을 추정하면서 상상력을 동원하는 과정이 재미있었던 것 같다. 여기에 평면에 흩어진 부품과 블록이 공간에 자리를 잡아가는 모습을 보며 생각한 내용이 현실화되는 기쁨도 한몫 거들었다. 이번 Make Vol 7.의 특집 기사는 크게 로봇과 키트 두 부문으로 나뉘어지는데, 키트 부문에 바로 하트 뿅뿅~ 목차만 봐도 가슴이 뛸 것이다. 키트와 혁명, 키트의 역사, 키트 제작자 선언, 꿈의 자동차 만들기, 힘들게 사업하기, 길버트: 키트의 아버지, 맥가이버식 의료 서비스, 오래된 키트의 혼. 어느 하나 대충 넘어가기 아까운 내용이 아닌가?

그 중에서도 키트와 혁명에 나오는 내용이 가장 가슴에 와 닿았다. 이미 해커스: 세상을 바꾼 컴퓨터 천재들을 읽은 분들이라면 알고 계시겠지만, 50년대 후반과 60낸대에 걸쳐 MIT의 TMRC의 '직접 해보라!' 강령이 해커 정신의 출발점이었고, 2세대 하드웨어 해커들이 등장하면서 알테어와 애플 I을 비롯한 개인용 컴퓨터 키트가 세상에 선을 보이게 되었다. 물론 대량 생산에 밀려 키트가 자취를 감추는 듯 했으나... 최근에 아두이노, 라즈베리 파이를 비롯해 다양한 DIY용 키트 조립 보드가 등장하고 3D 프린터와 스캐너 등이 등장하면서 다시 한번 키트 애호가들을 위한 세상이 펼쳐지고 있다. 기술의 발전은 이론과 실제가 서로 얽히고 섥혀 진행된다는 로버트 L. 글래스의 날카로운 지적처럼 키트를 활용해 원래 제작 의도와 전혀 무관한 기술적인 탐험을 하다 발견된 실증적인 지식이 네트워크를 타고 급속하게 펴저 나가면서 다시 이론적으로 정립되는 선순환 고리는 정부 기관이나 대학 주도가 아닌 소규모 개인 기업에서 먼저 싹트고 있는 기술 혁신이 뒷받침해주고 있다.

기술 혁신 이야기가 나오니 Vol 7.의 특집 기사 중 로봇과 연결시키지 않을 수 없다. 올 하반기 세간의 화제가 된 그래비티를 보면서 지금까지 본 어떤 영화보다 카메라 움직임이 심상치 않음을 느꼈는데, 나중에 알고 보니 봇 & 돌리(구글이 인수했다)에서 만든 로봇 카메라 시스템이 일등 공신이었다. 흔들리지 않는 화면을 찍어주는 스태디 캠이 나온 이후에 물리적인 카메라 이동 제어 부문에 기술 정체가 온 듯이 보였으나 로봇 기술을 총동원해 어떤 각도와 거리에서도 안정적으로 카메라를 움직일 수 있는 훌륭한 도구가 등장한 셈이다. 백문이 불여일견이니 다음 클립을 한번 보기 바란다(중간에 잠깐 그래비티 촬영 장면도 나온다).

이런 엄청난 물건(!)이 하루 아침에 만들어졌을까? 아마 엄청난 실패와 실험을 거쳐 지속적으로 개선되고 보완된 결과물이 아닐까 싶다. 멋진 영상을 얻고자 손수 제작한 작은 카메라와 원격 조정 로봇이 출발점이라 생각하면 용기가 나지 않는가?

결론: 로봇과 키트 애호가라면 이번 호를 절대 놓치지 말기 바란다!

EOB

월요일, 12월 16, 2013

[일상다반사] 클린 코드 복간 소식!

지난번 [독서광] The Clean Coder에서 로버트 C. 마틴의 '클린 코드' 복간 소식을 여러분들께 전해드린 바 있다. 원고를 처음부터 끝까지 재검토하는 바람에 이제서야 독자 여러분들께 선을 보일 수 있게 되었다. 많은 독자분들께서 과연 새 책을 구입해야 할지 말아야 할지 고민하고 계실텐데, 고민을 조금이라도 덜어드리기 위해 개선된 내용을 정리해보겠다.

  1. 코드에 최적화되게 편집 스타일을 변경했다. 이 부분은 책을 펼치자 마자 가장 크게 느낄 수 있는 변경 사항이라 볼 수 있다.
  2. 전반적으로 코드를 다시 읽으면서 잘못된 부분을 고쳤다(조판 과정에서 잘못된 부분은 물론이고 원서에서 잘못된 부분 포함). 아무래도 코드가 많이 나오는 책이다 보니 상당한 개선점으로 강조할 수 있을 것이다.
  3. 혼란을 일으킬 가능성이 있는 용어를 바꿨다. B급 프로그래머도 자바 쪽으로 주종목이 바뀌면서 다시 읽어보니... 수정이 필요한 용어가 눈에 보였다. T_T
  4. 오역을 몇 군데 잡았다. 심각하지는 않지만 의도를 잘못 전달할 가능성이 높은 부분을 수정했다. 이 과정에서 인사이트 출판사 사장님께서 직접 베타리딩을 해주셨다. 정말 감사드린다.
  5. 주석 등을 재검토해 보완했다.
  6. 부록의 교차 참조 페이지가 엉망이었는데(원서부터 잘못되어 있었다), 이 부분을 수작업으로 하나하나 올바르게 만들었다.
  7. 색인을 원서와 동일하게 다단으로 만들었다. 책을 한번 읽고 나서 다음에 찾아볼 때 무척 편리함을 느낄 것이다.
  8. 표지를 멋지게 만들었다. 물론 기존 표지가 더 마음에 드는 분들도 있겠지만... '클린'의 이미지와 딱 맞는 표지를 찾았다는 생각이다.

현재 예스 24알라딘에서 절찬리에 예약 판매 중에 있다. 참고 삼아 말씀드리자면 이 책은 '인세' 형태로 계약을 맺었으므로 날개 돋힌 듯 많이 팔려 대박이 나면 B급 프로그래머도 기분이 아주 좋아질 것 같다. 아무쪼록 독자 여러분의 많은 성원 부탁드리겠다.

EOB

토요일, 12월 14, 2013

[독서광] 코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기

2013년의 마지막 12월에 좋은 책을 독자 여러분께 연속으로 소개하게 되어 무척 기쁘다. 오늘은 지난번에 소개드린 [독서광] 코딩 호러의 이펙티브 프로그래밍에 이어 후속편이 등장했다는 소식을 접하고 출판사에서 보내준 책을 번개처럼 읽고 소감을 정리해본다. 주인공은 바로 '엉터리 개발자에서 벗어나 진정한 개발자로 거듭나라!'는 부제가 붙은 '코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기'다. 이 책 역시 전편과 마찬가지로 코딩 호러에 실린 글 중에서 재미있는 내용을 선별해 묶은 형태다. 전편을 읽고 나서 더 많은 읽을 거리를 원하는 독자에게 제공하는 보너스 팩이라고 할까?

지난번에도 언급했지만, 이 책은 첫 페이지부터 끝 페이지까지 (소프트웨어 개발에 종사하는) 독자들이 처한 환경과 상황을 다시 한번 돌아보게 만드는 좋은 주제와 소재거리가 가득하므로 읽다 보면 여러 가지 다양한 생각을 하게 만든다. 본문 중에 가장 마음에 드는 내용을 뽑으라고 하면 주저 없이 1부의 "당신은 전문가인가?"와 "하룻밤 사이의 성공: 사실은 몇 년이 걸린다"를 선택하겠다.

전문가가 된다는 것은 다른 사람에게 자기가 아는 것을 말하는 것이 아니다. 그것은 바로 어떤 질문을 할지 아는 것, 자신의 지식을 주어진 특정 상황에서 어떻게 적용할지 아는 것을 의미한다. 전문가가 된다는 것은 합리적이고 상황에 매우 적절한 방향을 제시할 수 있음을 의미한다.
하룻밤 사이에 성공을 거둔다는 개념은 상당히 왜곡된 생각이며, 심지어 위험하기까지 하다. 물론 굼뜨게 행동하는 것을 변명하려는 것은 아니다. 그와 반대로 매우 빠르게 움직여야 한다. 그렇게 하지 않으면 그것은 너무나 먼 장거리 여행이라서 목적지에 도달하지 못할 수도 있다! 근검절약 정신이 중요한 것도 같은 이유에서다. 산의 중턱에 도달했을 때 먹을 것이 다 떨어져서 굶어죽기를 바라는 사람은 아무도 없기 때문이다.

'하룻밤 사이의 성공' 따위는 없다는 조언과 맞물려, 비슷한 맥락에서 NHN 이해진 의장이 말하는 내용도 새겨들을만하다.

사업 성공도 그런 것 같다. 한 번의 천재적인 아이디어에서 나오는 게 아니라 수십, 수백 번의 시도에도 성과가 없다가 절박한 심정으로 다시 한 번 시도하는 것에서 찾아오는 것 같다.

그렇다. 소프트웨어 분야에서도 여느 분야와 마찬가지로 "자고 나니 유명해지더라", 일확천금, 로또는 존재하지 않으며 수 많은 시련과 역경과 고난을 넘어서야만 성공할 수 있다는 말이다. 하지만 어느 시점이 되어야 행운의 여신이 다가올지 모르기에 대다수 사람들이 중도에 포기하지 않나 싶다.

요약: 2013년 하반기 현재 가장 눈에 띄는 추천 개발 서적으로 평가한다!

부록: 본문 맛보기는 여기에서...

부록 2: 본문에 나오는 링크는 코딩 호러의 본문 링크를 확인하고 싶다면?에서...

EOB

화요일, 12월 10, 2013

[일상다반사] 소나: 네이버 댄스?

호랑이 담배피던 시절(2000년도 초기)에 구글 검색 엔진이 실시간으로 색인 작업을 하지 않을 때, 구글이 검색 엔진 색인을 갱신하면 사방에서 난리가 났다. 색인 알고리즘 개선으로 인해 사람이 북적거려 장사 잘 되는 목 좋은 곳에서 쫓겨나는 경험은 누구도 원하지 않았기 때문이다. (지금은 더 이상 사용하지 않지만) 이런 검색 엔진 순위 변경을 일컬어 구글 댄스라 부른다. 소상공인들은 자신의 웹 사이트가 구글 첫 페이지에 나오느냐 마냐에 따라 벌어들이는 수입이 완전 달라졌기 때문에, 키워드 광고 등에 들어가는 비용을 조금이라도 아끼기 위해 검색 엔진 최적화(SEO) 관련 꼼수를 부리곤 했는데... 검색어와 관련 없는 엉뚱한 사이트가 첫 페이지를 가득 채우는 현상이 지속될 경우 검색 결과의 신빙성이 떨어지므로 구글도 지속적으로 다양한(수 백여 가지로 추정한다) 매개변수를 조정하며 검색 순위 알고리즘을 변경하는 방식으로 대응해 오고 있다.

갑자기 구글 댄스 이야기를 왜 꺼냈냐구? 지난 주말부터 네이버에서 이 블로그로 유입되는 트래픽이 급격하게 감소되는 현상을 목격했기 때문이다. 주말이라 검색 대신 야외 활동에 집중한다고 생각했으나... 검색 엔진에 들어가 몇몇 키워드를 입력한 결과를 따져 보니 네이버 ‘검색’ 손질…“원본 문서 먼저 뜨도록” 기사에 나온 소나(SONAR, Source Navigation And Retrieval)를 실제 투입한 것으로 추정하고 있다. 뭐 '컴퓨터 vs 책'이라는 B급 블로그야 어차피 방문객 수에 연연하지 않으니(organic search 결과를 타고 오는 사람만큼이나 트위터/RSS 구독자도 많다. ㅋㅋ) 큰 문제가 없으나... 파워(?) 블로그나 홈페이지 운영자들에게는 멘붕이 올지도 모른다는 생각이 살짝 들었다.

자 그렇다면 소나의 위력이 어느 정도일까? 아주 유감스럽지만 아직 상당한 개선이 필요할 것 같다. 원본 문서를 먼저 노출한다고 했는데, 검색 결과를 보면 정말 '원본' 문서를 먼저 노출하는지 확신이 서지 않는다. B급 블로그는 나름 '원본'만 싣는다고 자부하고(응?) 있는데, 멀쩡히 잘 검색되던 색인에서 많이 지워져버렸기에 졸지에 '짝퉁(!)' 블로그가 되어버린 셈이다. 특히 기존에 잘 검색되었던 '책'과 관련된 글이 모두 순위에서 탈락해버린 신기한 현상을 발견했는데, 앞으로 블로그 글을 계속 올리며 소나가 어떤 반응을 보일지 살펴볼 계획이다.

EOB

토요일, 12월 07, 2013

[독서광] 페르시아의 왕자: 조던 메크너의 게임 개발일지 1985~1993

애플 ][ 애호가라면 분명히 '카라테카'라는 게임도 들어봤을 것이다. 공주를 찾아 악당들과 한 판 승부를 벌이는 격투기 게임의 원조인데, 혹시 모르는 분들을 위해 비디오를 첨부해봤다.

뜬금없이 8비트 게임 이야기를 왜 꺼냈는지 알만한 사람은 다 알겠지만, 오늘 소개할 책의 저자가 바로 '카라테카'를 만든 조던 메크너이기 때문이다. '페르시아의 왕자: 조던 메크너의 게임 개발일지 1985~1993'는 애플 ][와 IBM PC 격투기 게임을 한 단계 더 끌어올린 '페르시아의 왕자'를 만들면서 작성한 일기를 정리한 책이며, 부제와 같이 1985년부터 1993년까지 페르시아의 왕자와 관련된 재미있는 개발 일화, 주변 이야기, 게임 회사 분위기를 잘 드러내고 있다. 해커스를 읽다보면 1982년에서 게임 업계의 시계가 똑 멈춰버리는데, (해커스에도 나온 게임 회사인) 브로드번드를 중심으로 그 뒤에 이어지는 이야기가 궁금한 독자라면 1인칭 시점으로 기술한 이 책이 무척 마음에 들 것이다. 한국에서는 전자책으로 먼저 나왔는데, 애호가들의 입소문을 타고 이번에 종이책으로도 출간되었다.

위키피디아의 페르시아의 왕자 페이지를 보면 알겠지만 그 당시 엄청난 인기를 끌어 정말 다양한 기종에 이식되었다. 다음 비디오를 보면 여러 기종에서 돌아가는 화면을 비교할 수 있을테다. 한국에서는 IBM PC의 보급과 맞물려 게임 애호가들 사이에 퍼지기 시작했는데, 약병 색상을 구분하기 어려운 모토크롬 모니터와 암호 표(복제 방지를 위해 특정 스테이지에서 매뉴얼에서 지시하는 특정 약병을 먹어야 계속 진행되게 만들었는데... 매뉴얼 없이 수많은 시행착오로 이를 다 격파한 친구를 알고 있다. 요즘 잘 지내고 있나?)라는 방해물에도 불구하고 엔딩 화면을 볼 수 있었다(끈기의 한국인!).

이렇게 재미있는 게임을 만드는 과정을 차곡차곡 적어놓았다는 사실 하나만으로 이 책은 충분히 읽고 소장할 가치가 있다고 본다. 메크너는 2010년에 개봉한 '페르시아의 왕자: 시간의 모래'의 각본가로도 활약할만큼 글재주가 좋기에 알찬 내용을 독자들에게 선사한다. 대박 게임을 만들고 나서도 초기에 마케팅 팀의 비협조로 인한 판매 부진, 그 와중에 대본을 쓰고 영화를 만들겠다고 결심해 새로운 길을 개척하는 모험, 독자들의 호평 속에 뒤늦게 베스트셀러 게임으로 등극(+ 수 많은 기종으로 이식)하는 스토리가 서로 잘 어울려 재미도 있고 교훈도 주는 일석이조의 목표를 달성하고 있다.

기술적으로도 흥미로운 이야기가 많이 나오며, 이미지 변환, 복제 방지, 박스 패키지, 기종간 이식 등 1980년대 게임 제작 작업의 주요 흐름을 파악할 수 있다. 페르시아의 왕자를 직접 보신 분들은 느끼겠지만, 그 당시 기술 수준으로 놀랄만큼 자연스러운 사람의 움직임을 보여준다. 기술적인 비밀? 실제 사람(메크너의 동생이 주 모델이었다)이 뛰어다니는 모습을 비디오 카메라로 촬영해 이를 디지타이저로 한 프레임씩 읽어 변환한 결과를 사용했기 때문에 지금 봐도 움직임이 상당히 부드럽다. 지금이야 인물의 움직임을 따는 특수 효과 기술이 상상을 초월하므로 우스울지도 모르겠지만 그 당시 열악한 장비로 휼륭한 효과를 낼 수 있는 이면에는 메크너의 창의성이 숨어있다.

결론: 고전 게임(특히 애플과 초창기 IBM PC) 애호가라면 즐겁게 읽어보기 바란다.

뱀다리: '페르시아의 왕자' 애호가라면 애플 ][용 어셈블리 소스 코드도 놓칠 수 없겠지? ;)

EOB

화요일, 12월 03, 2013

[B급 프로그래머] 12월 1주 소식 정리

어느덧 2013년도 12월로 접어들었다. 추위 건강 조심하시고, 트위터를 중심으로 소식을 정리해드리겠다.

  1. 웹 개발
  2. 개발/관리 도구
  3. 고성능 서버/데이터베이스
  4. 기타 읽을 거리

2013년도 마지막 소식은 2013년 내맘대로 총 정리를 해볼 계획이다. 컴퓨터 기술이 어떤 방향으로 흘러왔는지 함께 살펴보기로 하자.

EOB

토요일, 11월 30, 2013

[B급 프로그래머] 루비 slf4r java_logger의 버그 하나

조금 전문적인 이야기가 될지 몰라 적을까 말까 고민하다, 혹시 jruby에서 slf4r을 사용하다 동일한 문제에 부딪힐지도 모르는 개발자분들을 위해 간략하게 팁을 정리하고 넘어가겠다. 다름이 아니라, jruby에서 Java의 slf4j와 연계해 같은 로그 파일에 기록하려면 slf4r에 속한 java_logger를 사용하면 딱인데, 사소한 버그 하나 때문에 애로 사항이 꽃핀다.

java_logger.rb에서 문제가 되는 코드 일부를 가져와봤다. 눈썰미 있는 독자라면 숨겨진 폭탄을 하나 찾을 수 있을테다. 5분을 줄테니 코드를 검토해 벌레를 잡아보자.

    def #{level}(msg = nil, exception = nil)
      if(@logger.is_#{level}_enabled)
        msg, exception = yield if block_given?
        if(exception.type == NativeException)
          @logger.#{level}(msg, exception.cause)
        else
          @logger.#{level}("\#{msg}\#{format(exception)}")
        end
      end
    end

이미 짐작하는 바와 같이, 위 코드는 exception이 nil이 아닌 경우에만 정상 동작한다. 만일 exception이 nil일 경우 nil에서 type을 찾으므로 런타임 오류가 발생한다. 그렇다면 어떻게 수정하면 문제가 해결될까? 다음과 같이 단순하게 exception.nil?을 사용하는 nil 점검 루틴을 넣어보았다.

    def #{level}(msg = nil, exception = nil)
      if(@logger.is_#{level}_enabled)
        msg, exception = yield if block_given?
        if exception.nil?
          @logger.#{level}(msg)
        else
          if(exception.type == NativeException)
            @logger.#{level}(msg, exception.cause)
          else
            @logger.#{level}("\#{msg}\#{format(exception)}")
          end
        end
      end
    end

연이은 null 연재물로 인해 지금쯤이면 B급 프로그래머를 null 애호가로 부르고 싶을지도 모르겠다. 이렇게 null로 이미지를 굳힌 김에... 다음 시간에 또 다른 null 관련 이야기 보따리를 풀어보겠다. 기대하시라~

EOB

화요일, 11월 26, 2013

[독서광] 실패하는 사람들의 10가지 습관

오늘 소개드릴 책은 빌게이츠가 추천했다는 말을 듣고 호기심이 급상승해 바로 질러버린 '실패하는 사람들의 10가지 습관'이다. 원래 유명인사가 추천하는 책은 조심스럽게 접근하는데, 까다로운 워렌 버핏이 추천 서문을 썼다는 사실을 알고 두 번 고민없이 바로 구매했다. 일단 제목에서 주목해야 하는 단어는 '실패'다. '실패'라는 용어 자체가 금칙어인 한국에서는 흥행 여부는 뭐 안 봐도 DVD라고 볼 수 있겠다(초판 _2_쇄라 적혀있는 판권지를 보며 눈물이... T_T). 이 책은 코카콜라의 전설적인 경영인인 도널드 키오가 자신을 우스갯거리로 만들 각오를 단단히 하고 쓴 아주 특이한 책이다. 보통 유명 CEO가 쓴 책을 읽어보면 결함이라고는 찾아보기 어려우며 모든 역경과 곤란을 극복하며 운 따위는 믿지 않는 인물이 등장하기 마련인데, 이 책은 전혀 그렇지 않다. 코카콜라에서 발생한 각종 실수와 실패를 중심으로 어떻게 이를 인정하고 (약간의 행운까지 활용해) 해결해나가는지 자신의 경험담을 위트있게 기술한 책이라 보면 되겠다.

책을 펼치자 마자 성공하는 방법 따위는 없다는 말로 독자들을 맞이한다. 그리고 자기 조언만 따르면 무조건 실패한다는 주장과 함께 좀더 빨리 실패하는 방법에 대해 단계별로 설명하는 내용이 이어진다. 요즘 나오는 경영/경제서의 특징인 빠른 전개, 풍부한 사례 연구, 화려한 미사여구에 익숙한 독자라면 구석기 시대에 나온 책으로 간주하고 읽다 포기할 가능성도 있지만 의외의 상황에서 깨알 같이 재미를 주는 부분이 나오므로 (독자의 내공에 따라) 교훈과 웃음을 동시에 얻을 가능성도 존재한다. 이 책의 목차가 아주 중요하므로 여기에 한번 더 옮겨보기로 하자.

  1. 모험은 하지마라
  2. 입장을 절대 바꾸지 마라
  3. 자기 자신을 격리 시켜라
  4. 한 치의 오류도 없는 사람인 척 하라
  5. 법은 정도껏 지켜라
  6. 생각할 시간을 갖지 마라
  7. 전문가와 외부 컨설런트를 무조건 믿어라
  8. 관료주의를 사랑하라
  9. 헷갈리는 메시지를 전달하라
  10. 미래를 두려워 하라
  11. 완벽한 실패를 위한 마지막 습관: 일에 대한 열정을 상실하라, 영원히

본문을 읽다보면 나오는 사례나 조언이 기업을 이끄는 아주 높으신 분에게 해당하는 내용이므로 나랑 무슨 상관이 있는지 어리둥절한 느낌이 들지도 모르겠는데, '자신'의 삶을 경영하는 개인에게도 그대로 적용되는 부분이 상당히 많으므로 글자 그대로 읽기 보다는 자신의 습관과 태도와 관련시켜 읽어보면 색다른 깨달음을 얻게 되리라는 생각이다. 개인적으로 대미를 장식하는 "완벽한 실패를 위한 마지막 습관: 일에 대한 열정을 상실하라, 영원히"가 가장 마음에 들었다. 지금까지 지치고 피곤하고 힘들 때 내가 무슨 부귀 영화를 누리겠다고 이 난리를 쳐야하는지 의심이 들며 열정을 상실하는 상황을 여러 차례 접했는데, 그러면 완벽하게 실패한다는 조언을 듣고(완벽하게 실패한 과거 사례가 주마등처럼 스쳐지나가며...) 화들짝 놀라고 말았다. 로버트 C. 마틴 큰 형님께서 언급한, 들어올 때보다 나갈 때 더 깨끗하게(좋게) 만들고 나가야 한다는, '보이스카우트 정신'을 이 책 역시 마지막에서 다음과 같은 교훈으로 정리하고 있다.

처음에 그 일을 맡을 때보다 마무리 지을 때의 상태가 더 나아야 한다고 마음먹고 최선을 다하라.

결론: 이 책을 구입하든 구입하지 않든 위에 정리한 10가지 실패 습관 + 완벽한 실패 습관 목록은 잘 보이는 곳에 두고 힘들 때마다 읽어보면 많은 도움이 되리라는 생각이다. 실패의 비밀을 알고 싶은 분들께 추천!

EOB

토요일, 11월 23, 2013

[B급 프로그래머] 11월 3주 소식 정리

11월 3주도 어느덧 끝나가고 있다. 트위터를 중심으로 들어온 새소식을 정리해드리겠다.

  1. 웹 개발
  2. 개발/관리 도구
  3. 고성능 서버/데이터베이스
  4. 기타 읽을 거리

11월 마무리 잘 하시기 바라며, 12월 1주에 찾아뵙겠다.

정보: 트위터에서 @jrogue를 follow/list하시면 실시간으로 새소식(물론 개발과 전혀 무관한(응?) 다른 정보도 뒤섞이긴 합니다만...)을 보실 수 있습니다.

EOB

토요일, 11월 16, 2013

[일상다반사] 독일에서 생활하면 어떨까?

"규제없는 독일로 오라"…獨, 한국게임업체 '러브콜'이라는 기사에도 나오지만 노르트라인 베스트팔렌(NRW) 주에서 한국 게임 업체에 전폭적인 지원을 아끼지 않겠다는 소식이 트위터를 뜨겁게 달궜다. 게임 개발자여, 독일로 가자!라는 글에서는 일곱 가지 조언을 곁들여 독일에서 주의할 사항도 친절하게 짚어주고 있다. NRW 주에 속한 주요 도시(뒤셀도르프, 도르트문트, 에센)를 왔다갔다한 경험을 토대로 과연 어떤 명과 암이 있을지 한번 생각해봤다.

  1. 맛있는 치맥은 꿈도 꾸지 마라. 독일에서 작은 슈퍼마켓에도 다양한 맥주가 진열장을 꽉 채우고 있다. 맥주뿐만 아니라 와인 역시 애주가들을 반기고 있다. 여기까지는 좋다. 맥주에는 당연히 치킨이 떠오르지만, 독일에서 야식 통닭 배달은 꿈도 꾸지 않는 편이 좋다. 배달 음식이라는 개념 자체가 없으니까. T_T 그리고 일반적인 식재료는 아주 저렴하지만(우유, 치즈, 계란, 빵 가격은 아주 낮게 책정되어 있다), 식당에서 뭘 먹으려면 가격표 앞에서 상당한 용기가 필요하다. 커피도 테이크아웃이 아니라 편안한 의자에 앉아서 먹을 경우 한국의 프렌차이즈 가격을 바로 넘어가버린다(물론 할아버지 할머니들이 자리를 다 차지하고 있으므로 젊은 친구들이 끼어들 분위기가 아니긴 하지만 말이다).
  2. 온돌은 꿈도 꾸지 마라. 독일의 겨울 장마는 악명 높다. 겨울 내내 영하를 조금 내려간 상태에서 가랑비가 오락가락하고(물론 독일 사람들은 어지간한 가랑비에는 우산을 잘 안 쓰는 듯이 보였다) 밤에는 체감 온도가 장난 아니게 떨어진다. 문제는 난방 시설인데, 한국의 온돌 문화에 익숙해있다면 바로 멘붕이 올만큼 형편없다. 뜨거운 물로 공기를 사알짝 데우는 히터가 전부이므로 바닥에 카페트를 깔며, 침대에서 자고, 실내에서도 두툼한 실내화를 신고 돌아다녀야 한다. 현지 필수 품목 중 1위 2위를 다투는 품목이 바로 전기 장판이라는 사실을 알고 있으면 되겠다. 건강하게 지내려면 (남쪽 따뜻한 지방으로 가는) 휴가가 필수라는 이야기가 그래서 나온다.
  3. 빨리 빨리는 잊어먹어라. 운전 면허증 발급부터 시작해 전화/인터넷 설치까지 그야말로 무한한 끈기와 인내가 필요하다. 게다가 담당자가 휴가라도 갔다면, 휴가에서 돌아올 때까지 모든 관련 업무는 중지된다고 보는 편이 정신 건강에 이롭다. 융통성이라고는 찾아볼 수 없기에 맡은 자기 업무 이외 다른 업무는 해주지 않는다.
  4. 에누리를 기대하지 마라. 한국처럼 이리재고 저리재고 목소리가 크면 저렴하게 구입할 수 있는 물건이 별로 없어보인다(시장가서 잘 흥정하면 또 모를까...). 하지만 이게 단점이자 장점이다. 온/오프라인 가격이 일정하므로 어떤 물건을 살지만 결정하면 어디서 구입하나 손해를 보지 않고 살 수 있다. 물건 가격은 한국에 비해 대체로 비싸고 A/S 관련 워런티를 별도로 붙여야 하는 경우가 많고 배송/설치비도 제법 든다. 저렴한 가구 집기의 대명사 이케아가 있잖아? 하지만 배송/설치비가 물건값보다 더 든다는 사실을 알고 가기 바란다(적재함이 넉넉한 자동차가 없으면 가구도 못 산다).
  5. 영어가 100% 통하지는 않는다. (어차피 NRW 주에는 서울/부산처럼 큰 도시도 없지만...) 도심에서 벗어나기 시작하면 영어로 의사 소통이 불가능한 경우가 생긴다. 작은 우체국에 간 적이 있는데, 영어를 아는 직원이 한 명도 없었다. 다행히 독일어 숫자 정도는 읽고 쓸줄 아니까 잘 넘겼다. 하지만 택시를 탔는데 터키 운전사가 독일어로 말을 거는 경우라면? 은행에 갔는데 독일어로 서류를 작성해야 한다면? 기차가 조금 연착되어(독일도 종종 기차 연착이 일어난다. ㅋㅋ) 플랫폼이 바뀌고 있는데, 안내 방송을 유창한 독일어로 한다면? 잠시 방문이 아니라 계속 살아야 한다면 독일어를 모르면 큰 낭패다(바로 뒤에 아주 좋은 예가 나온다). 그리고 영화는 기본적으로 독일어로 더빙되어 나온다. ㅋㅋㅋ
  6. 계약은 문서로 한다. 전화 한통화로 모든 것이 처리되는 한국과는 달리 독일은 문서가 아주 중요하다. 전기/가스요금부터 자동차 보험 계약서 등 모든 계약은 명확하게 문서로 주고받아야 나중에 골치 아픈 일이 안 생긴다. 법정에 출두하더라도 관련 레터만 잘 보관하고 있으면 문제가 없는데, 한국처럼 좋은게 좋을거라고 대충 넘어갔다가는 금전/시간 손실을 감수해야 한다. 그런데... 이걸 독일어로 형식에 맞춰 써야 하는 경우가 생긴다.
  7. 독일 사람들이 모두 다 법을 잘 지키고 남들에게 친절할까? 이건 복불복이라... 각자 상상에 맡긴다. 거기서도 무임승차할 사람은 무임승차하고 사기칠 사람들은 사기치고 도둑질할 사람들은 도둑질한다. 따라서 한국처럼 커피숍에 어서 가져갑쇼~ 하듯 노트북을 내려놓고 화장실가는 우를 범하지 말기 바란다.

이렇게 설명하고 나니 독일에 가지마라는 듯이 들리는데, 독일의 절차에 익숙해지기까지가 힘들어서 그렇지 그 이후부터는 정말 규칙대로 움직이므로 복잡하고 번잡한 것을 싫어하는 사람들에게는 딱 좋은 나라다. 하지만 끊임없이 정치/경제/사회/문화 뉴스거리를 제공하는 역동적인 한국 상황에 익숙하고 그걸 즐기는 사람들이라면 권태/지겨움으로 인해 버티기 어려울지도 모르겠다. 다행스럽게도 규칙을 좋아하는 개발자들에게는 독일이 그렇게 나쁜 선택은 아닌 듯이 보인다.

지금까지 _잡생각_을 늘어놓아봤다. 개인의 주관적인 경험이니 사실과 다른 부분이 존재할 수 있으므로, 잘못된 부분은 댓글로 알려주시기 바란다.

EOB

[독서광] 과학자의 관찰 노트

트위터를 열심히 하다보면 종종 좋은 책을 소개받을 경우가 있다. 오늘은 트위터 뽐뿌질에 넘어가 덥썩 구입해버린 '과학자의 관찰 노트'라는 책을 여러분께 소개해드리겠다. 책 제목보다 조금 작게 쓰여진 '자연을 관찰하고 기록하는 12가지 방법'이라는 부제가 무척 중요한데, 자연사학자, 박물학자, 현장과학자, 자연과학자들이 현장 탐사 과정에서 작성하는 '관찰 노트(Field Note)'를 집중적으로 다룬다.

책을 구입하기 전에 떠올린 이 책에 대한 이미지는 필기의 달인이 작성했을 법한 예쁜 동식물 그림(동식물 도감?), 깔끔하고 깨끗하고 가지런히 정리된 텍스트였다. 하지만 실제 책을 배송받고 펼쳤을 때 예상과 다른 내용이 등장했기에 순간 당황했다. 필기체로 급히 갈겨 써 해독하려면 상당히 노력이 필요한 노트 내용을 보고 공책 정리의 달인이 되는 법 따위는 잊어버리기로 했다(물론 본문 중 몇몇 노트는 그림까지 곁들여 깔끔하게 정리되었기에 귀감이 될만하다). 이 책은 개성이 가득한 총천연색 관찰 노트를 곳곳에 배치하긴 했지만 이는 어디까지나 참고 자료이며, 사실상 자연 탐사 과정의 현장에서 일어나는 다양한 이야기를 '관찰 노트' 작성이라는 주제와 연결해 풀어나가고 있다. 사무실에서 벌어지는 따분한 공책 정리 이야기가 아닌 현장 탐사 장면이 대부분이므로 미국 HBO 미니시리즈인 '지구에서 달까지'의 10편 "갈릴레오가 옳았다'에서 지질학 공부를 위한 현장 학습 장면을 연상하게 만들기도 했다.

이 책은 15명의 현장 전문가들이 각자 자신의 주특기(대상은 아주 다양하다. 동물, 식물, 곤충, 사람, ...)에 맞춰 '관찰 노트'를 어떻게 작성하는지를 설명한다. 아름다운 동식물이나 자연 경관에 대한 화려한 볼거리는 없지만 관찰 결과를 자신, 동료, 후대에 전파하기 위해 쏟아붓는 엄청난 노력이 이 책의 미덕이다. 어릴 때 제법 많은 시간을 야외에서 메뚜기랑 매미도 잡고, 풀도 관찰하고 놀았지만 방학 숙제로 곤충 채집할 때를 제외하고는 어떤 정리나 기록도 하지 않았기에 이 책을 읽고 나서 아쉬움이 많이 들었다. 만일 그 때 기록하는 습관이 들었더라면 지금 완전 다른 모습으로 살고 있을지도 모르겠다. 이 책을 읽으면서 무엇을 얻었냐구? 책 날개 표지에 잘 정리된 자연 탐사와 관찰 노트 작성과 관련한 지은이의 10가지 교훈을 옮겨보겠다.

  1. 관찰을 즐겨라. 그러면 많은 것을 배우게 될 것이다.
  2. 어디라도 상관없다. 흥미로운 것이 있다면 그 즉시 적어라.
  3. 동물을 가까이에서 관찰하고 기록하려면 컴퓨터보다는 수첩이 좋다.
  4. 가능한 한 모든 것을 기록하라. 어디에서 아이디어가 나올지 모른다.
  5. 문장으로 자세하게 기록하는 능력을 길러라.
  6. 관찰한 것을 그림으로 그려라. 잘 그릴 필요는 없다.
  7. 그림을 그리면 관찰 대상을 더욱 자세히 보게 된다.
  8. 관찰 노트를 사진과 파일 등 모든 정보를 하나로 묶는 총사령관으로 이용하라.
  9. 식물 표본의 이름표에는 꼭 들어가야 하는 정보가 정해져 있다.
  10. 컴퓨터를 이용하면 기록 과정을 매우 단순화할 수 있다.
  11. 다른 사람이 쓴 노트를 보고 좋은 점을 취하라.
  12. 관찰 노트를 작성하는 목적에 맞게 자신만의 방식을 설계하라.

이 책의 다른 내용도 아주 좋았지만, 개인적으로는 8장 '왜 스케치를 해야 할까?: 과학 일러스트레이터의 그림 도구'가 가장 마음에 들었다(아니 충격적이었다). 개인적으로 손재주가 없어 그림이라면 질색을 하는 바람에 더욱 그림을 못그리게 되고 파워포인트 등으로 발표 자료 등을 만들 때도 엄청난 곤란을 겪고 있다. 그런데 8장에서 기본 구도를 잡고 간단하게 스케치 하는 방법, 색상을 선택하는 방법, 간단한 도구를 활용하는 방법을 전문가가 아닌 과학자를 위해 설명하는 내용을 보고 무릎을 탁 쳤다. 아니 지금까지 초보자를 배려하는 책이 왜 그렇게 나오지 않았는지 그게 더 궁금한 지경이었다(그래서 강남 교보문고 예술 코너를 돌며 나름 신경을 써서 '초보자'용 스케치/그림 입문서를 찾으려 했으나... 만족할만한 성과를 얻지 못했다). 12장 '나만의 관찰 노트를 만들자'가 그 다음으로 마음에 들었다. 11장까지 나오는 내용을 총정리하는 동시에 다시 한번 자연 탐험과 관찰 노트 작성의 즐거움을 배가하는 각종 팁을 제시하고 있기에 마무리로서 아주 좋은 선택이었다는 생각이다.

결론: 어릴 때 과학자가 되고 싶었던 분들이라면 이 책을 읽으면서 옛날 생각이 많이 날 것이다. 오늘도 현장에서 열심히 뛰어다니는 과학자들의 생동감을 느끼고 싶은 분들께 이 책을 강력하게 추천한다.

EOB

수요일, 11월 13, 2013

[B급 프로그래머] 프로그래머와 NULL, 그리고 Optional

지난번에 올려드렸던 [B급 프로그래머] SQL에서 UNIQUE와 NULL 제약 조건을 많은 분들께서 재미있게 읽어주셨기에, 오늘은 신이 난 김에... 프로그래머 관점에서 NULL을 살펴보기로 하자.

데이터베이스 뿐만 아니라 프로그래밍 과정에서도 NULL은 아주 골치 아픈 존재다. NULL은 실패를 의미하기도 하며, 성공을 의미하기도 하며, 둘 다를 의미하기도 할뿐더러... Map과 같은 자료 구조에서 반환된 NULL은 Map에 키로 조회한 결과 값이 NULL인지 아니면 없는지 구분하기 어렵게 만들기에 주의 깊게 사용하지 않으면 대박 버그를 양산할 가능성을 높인다. 특히 C/C++에 익숙한 개발자라면 습관적으로 NULL을 반환하는 함수를 작성해왔기에 NULL 사용을 특히 조심할 필요가 있다.

자 그렇다면 NULL의 대안이 무엇일까? C++ 프로그래머라면 boost에서 제공하는 Optional을 사용하면 되며, 자바 프로그래머라면 구글이 만든 Guava 라이브러리에서 제공하는 Optional을 사용하면 된다. C++나 자바나 기본 사상은 비슷하므로 실제 자바 코드를 보면서 특성을 파악해보자. 아주 간단한 예부터 살펴보자.

package jrogue
import com.google.common.base.Optional;

public class BasicTest {
    @Test
    public void optionalTest() throws Exception {
        Optional possible = Optional.of(5);
        System.out.println("Is possible present? " + possible.isPresent());
        System.out.println("possible is " + possible.get());
    }
}

Optional은 null이 아닌 값을 포함하거나 아무것도 포함하지 않는다. 위 예에서는 Optional.of() 메소드에 인수로 5를 넘겼기에 isPresent() 메소드가 'true'를 돌려주며, get() 메소드는 값인 5를 돌려줄 것이다. 그렇다면 비어있다는 의미에서 null(응?)은 어떻게 표현할까? 다음 예를 살펴보자.

package jrogue
import com.google.common.base.Optional;

public class BasicTest {
    @Test
    public void optionalAbsentTest() throws Exception {
        Optional absent = Optional.absent();
        System.out.println("Is absent present? " + absent.isPresent());
        System.out.println("absent is " + absent.get());
    }
}

Optional.absent() 메소드는 아무것도 포함하지 않는 상태로 만들어준다. 따라서 isPresent() 메소드가 'false'를 돌려주며, get() 메소드는... "java.lang.IllegalStateException: Optional.get() cannot be called on an absent value"라는 예외를 던진다. 음... try catch로 예외를 잡아도 좋지만 뭔가 다른 처리 방법은 없을까? 다음 예를 살펴보자.

package jrogue
import com.google.common.base.Optional;

public class BasicTest {
    @Test
    public void optionalAbsentOrTest() throws Exception {
        Optional absent = Optional.absent();
        System.out.println("absent or " + absent.or(0));
        System.out.println("absent orNull " + absent.orNull());       
    }
}

or 메소드는 만일 null이 아닌 값을 포함할 경우 해당 값을, 아무것도 포함하지 않을 경우 인수로 넘긴 값을 기본값으로 돌려준다(여기서는 Integer 0을 반환하겠지? 기본값을 잘 활용하면 실행 중 null을 참조함으로써 발생하는 끔찍한 NullPointerException을 쉽게 요리할 수 있을 것이다). 그리고 orNull 메소드는 만일 null이 아닌 값을 포함할 경우 해당 값을, 아무것도 포함하지 않을 경우 'null'을 돌려준다. 자 그렇다면 Optional.of()에 인수로 null을 넘기면 어떻게 될까?

package jrogue
import com.google.common.base.Optional;

public class BasicTest {
    @Test
    public void optionalAbsentAssignTest() throws Exception {
        Optional impossible = Optional.of(null);
        System.out.println("Is impossible present? " + impossible.isPresent());
        System.out.println("impossible is " + impossible.get());
    }
}

지금쯤이면 이미 결과를 예상하고 있겠지만 "java.lang.NullPointerException" 예외를 던진다. of() 메소드는 null을 인수로 받아들이지 않으며, 비어 있는 의미에서 null을 지정하려면 absent() 메소드를 사용해야 한다. 그렇다면 null인지 아닌지 모르는 값을 Optional에 대입할 때 매번 번거롭게 orNull로 점검을 해야할까? 다음 예를 살펴보자.

package jrogue
import com.google.common.base.Optional;

public class BasicTest {
    @Test
    public void optionalAssignTest() throws Exception {
        Integer value_five = 5;
        Integer value_null = null;
        Optional possible = Optional.fromNullable(value_five);
        Optional absent = Optional.fromNullable(value_null);
        System.out.println("Is possible present? " + possible.isPresent());
        System.out.println("Is absent present? " + absent.isPresent());
    }
}

결과는 여러분들이 예상한 그대로다. Optional.fromNullable() 메소드에 Nullable Reference를 넘기면 알아서 처리해준다.

지금까지 Guava의 Optional을 신나게 살펴봤다. null을 넘기는 방식에 비해 번거롭다는 생각이 들지도 모르겠는데, 이게 바로 Guava Optional 설계자의 의도다. 원문을 그대로 가져와볼까?

Besides the increase in readability that comes from giving null a name, the biggest advantage of Optional is its idiot-proof-ness. It forces you to actively think about the absent case if you want your program to compile at all, since you have to actively unwrap the Optional and address that case. Null makes it disturbingly easy to simply forget things, and though FindBugs helps, we don't think it addresses the issue nearly as well.

Optional이 있으면 프로그래밍 과정에서 한번 더 생각해야 하므로 null로 인해 흔히 발생하는 오류를 잡을 수 있게 된다. 하지만 Optional이 절대 null을 완전히 없애버릴 만병통치약은 아니므로, 필요한 상황에서 적절히 활용하면 되겠다.

EOB

토요일, 11월 09, 2013

[독서광] Resonate: 공감으로 소통하라

경제/경영 블로그답지 않게 계속해서 '개발' 책만 소개했는데, 독서의 계절을 맞이하여 본연의 자세로 돌아와 보겠다. 오늘은 'slide:ology 슬라이드올로지 - 위대한 프리젠테이션을 만드는 예술과 과학'에 이은 낸시 두아르테의 신작인 'Resonate: 공감으로 소통하라'를 소개해드리겠다. 이미 슬라이드올로지를 읽어보신 분들이라면 잘 알고 계시겠지만, 이 책 역시 단순히 파워포인트를 사용한 예쁜 발표자료 만들기에 대한 책이 아니다. 차라리 세상을 바꾸기 위해 사람들을 설득하고 공감하게 만드는 방법을 설명하는 책으로 보는 편이 타당하다. 이미 짐작했겠지만, 이 책은 발표 자료 형식이나 구성에 대한 내용은 거의 없기에 기대했던 바와 다른 내용에 당황할지도 모르겠다. 하지만, 프리젠테이션의 목적이 단순 정보 전달을 넘어선 동기 부여와 참여라는 사실을 미뤄볼 때, 프리젠테이션의 가장 기본을 다루는 이런 유형의 책이 형식이나 기교를 다루는 책보다 먼저 나왔으면 더 좋을뻔 했다는 생각이 들었다. 만일 좋은 프리젠테이션의 원리/원칙만 소개하는 선에서 끝났다면 구체성이 결여되어 "So what?"이라는 반응이 바로 나왔을텐데, 이 책 자체도 좋은 프리젠테이션의 형태를 그대로 반영하고 있기에 이 책을 정독하고 나면 분명히 과거와는 달리 프리젠테이션을 바라보는 시각이 바뀌어 있을 것이다.

이 책은 신화, 영화, 예술 분야를 오가며 사람들에게 감동을 주고 변화를 일으킨 여러 요인을 분석해 이를 프리젠테이션에 접목하는 방법을 다룬 학제간 연구서라고 봐도 좋겠다. 특히 후반부에 나오는 모차르트(음악), 히치콕(영화), 커밍스(시), 마사 그레이엄(무용), 레너드 번스타인(지휘)의 사례를 보고 있으면 장인들의 눈물겨운 노력을 느낄 수 있다. 인구에 두고두고 회자되는 뛰어난 작품은 천재들이 그냥 잠깐 생각해 나온 결과가 아니라 끊임없는 연습, 개선, 고민의 결과라는 사실은 한방에 뜨거나 또는 일확천금을 노리는 일반 사람들에게 시사하는 바가 크다. 프리젠테이션 역시 다른 모든 위대한 공연/예술/작품과 마찬가지로 치밀한 기획, 연습, 개선, 피드백이 필요함을 의미한다.

이 책의 가장 중요한 특징을 하나만 꼽으라고 하면, 바로 스파크라인(Sparkline)을 사용한 프리젠테이션 분석이다. 스파크라인은 현실과 이상 사이의 대비, 감정과 전달 방식의 변화를 시간의 흐름에 맞춰 패턴화하는 좋은 도구이므로 다른 발표자의 의도를 객관적으로 분석하는 동시에 한 걸음 더 나가 자신의 스토리텔링을 구축하는 과정에 적합하다. 본문에서는 리차드 파인만, 존 오트버그, 스티브 잡스, 마틴 루터 킹 주니어의 발표 예를 분석해 관중들을 어떻게 들었다 놓았다 울렸다 웃겼다 하는지 시간의 흐름에 따라 주의 깊게 설명하고 있다. Resonate by Nancy Duarte에 가보면 관련된 여러 관련 비디오와 이미지가 나오므로 책(원서 또는 번역서)과 함께 참조하면 좋겠다.

본문에 나오는 몇 가지 좋은 이야기를 정리해보겠다(정말 간만이다. ㅎㅎ)

위대한 발표는 청중을 변화시킨다.
건강한 조직을 유지하려면 변화와 개선이 지속되어야 한다.
설득의 최대의 적은 모호함이다.
감정요소를 배제하고 전문용어로 무장하는 것이 편하긴 하다. 하지만 편한 것이 항상 최선은 아니다.
악당을 물리치는 이야기든 대단한 사업 성취를 이뤄내는 이야기든 누구나 자신이 이야기의 주인공이라 느낄 수 있어야 한다고 했다.
발표자가 겸손한 자세를 취할 때에만 청중은 통찰력을 얻게 되며 공감대가 형성될 수 있다.
"어설픈 시작은 어설픈 결말로 이어지기 마련이다." - 유리피데스
"인간은 웃고 울 수 있는 유일한 동물이다. 오직 인간만이 주어진 현실과 실현 가능한 이상 사이의 차이를 놓고 경악할 수 있기 때문이다." - 윌리엄 해즐릿
모든 청중은 반드시 변해야만 하는 이유가 분명해지기 전까지는 꼼짝도 안 하고 자신의 현재 위치에 안주할 것이다.
편집은 청중을 위한 것이다. 그들은 뭐든 다 들어줄 생각은 갖고 있지 않다.
"특출나게 훌륭한 글에 가위질을 하고 싶은 충동이 느껴진다면 그 충동에 따르라. 전심으로 말이다. 그 글이 공개되기 전에 삭제해버려라. 아끼는 부분을 없애버려라." - 아더 퀼러-카우치 경
"청중은 구조가 확실한 발표를 원한다." - 헨리 M. 뵈팅거
"무엇이든 초안은 형편없기 마련이다." - 어니스트 헤밍웨이
규칙을 아는 것이 중요하다. 그래야만 유연하게 그 규칙을 깨뜨리면서 새로운 의미를 창조할 수 있다.

보너스: 이 책을 간략하게 소개하는 발표 자료를 공유해드리겠다.

결론: 단순 지식 전달을 넘어 프리젠테이션을 공감과 소통의 장으로 만들어 사람들과 세상을 바꾸고 싶은 분들께 적극 추천한다.

EOB

수요일, 11월 06, 2013

[B급 프로그래머] 11월 1주 소식 정리

벌써 11월이니 2013년 한 해도 얼마 남지 않았다. 남은 기간 알차게 보내기 위해 오늘도 새소식을 정리해드리겠다.

  1. 웹 개발
  2. 개발/관리 도구
  3. 고성능 서버/데이터베이스
  4. 기타 읽을 거리

그러면 알찬 내용으로 3주에 다시 찾아뵙겠다.

EOB

토요일, 11월 02, 2013

[독서광] 안드로이드 하드웨어 서비스

최근에 올라오는 글을 보면, 자바만 편애(응?)하고 나머지는 찬밥으로 취급한다는 생각이 들지도 모르겠다. 그래서 잠시 분위기 전환을 위해 오늘은 아주 간만에 임베디드 관련(물론 자바가 들어있긴 하다. ㅎㅎㅎ) 책을 하나 소개해드리려 한다. 안드로이드 프로그래밍 관련 서적이 아니라 기반 동작 원리를 코드로 다루는 '안드로이드 하드웨어 서비스'가 오늘의 주인공이다. 이 책은 안드로이드 관련 기술 중에 전화기로서 동작하는 부분을 수직(vertical)으로 파고들고 있기에 일반적인 안드로이드 앱 개발자가 아닌 안드로이드 핵심 서비스를 대상으로 뭔가를 하려는 개발자에게 적합하다. 책을 읽기 위해 선행 지식이 필요한데, 리눅스 기초 지식(부팅 과정, 커널 기초), C/C++, 자바를 알고 있어야 애로사항이 꽃피지 않을 것 같다.

'전화기로서 동작하는'이라는 표현을 썼는데, 이 책 목차를 살펴보면 왜 이런 표현이 나왔는지 이해가 갈 것이다. 2장 RIL(Radio Interface Layer), 3장 텔레포티 프레임워크, 4장 USIM, 5장 안드로이드 파워 매니지먼트, 6장 안드로이드 커널 파워 매니지먼트라는 각 목차 제목만 봐도 이 책의 집필 의도와 목적이 확실하게 드러난다. 그런데, 단순히 이론적인 원론이 아니라, 실제 코드(자바와 C/C++)를 중심으로 각 계층 사이의 상호 연관성, 자료 흐름, 제어 흐름 등을 설명하고 있으므로 관련 코드 분석에 앞서 조감할 목적으로 적합하다는 생각이다. 다이어그램과 흐름도를 사용한 구조 소개에 이어 각 부분별로 계층적인 코드 파고 들기(drill down) 예제를 제시하는 이 책은 큰 그림을 그린 다음 함수나 이벤트 호출에 따라 대응하는 코드를 각개 격파하는 방식으로 설명을 진행하므로 나무를 보느라 숲 속에서 길을 잃어버리지 않게 세심하게 배려하고 있다. Yes24 책 페이지에 가서 상세 이미지를 살펴보면 감이 오겠다(예제 이미지가 코드와 연결된 부분이 아니므로 코드와 연결된 부분이 나왔으면 더 좋을 뻔 했다. 실제 본문을 넘기다보면 프로그래머 관점에서 기술되어 있다는 느낌이 들 것이다). 각 장이 유기적으로 수직 연결되어 있으므로 차근차근 읽는 방식을 권장한다.

개인적으로는 전화기의 기본 기능과 관련된 설명이 무척 흥미로웠고, 특히 기존에 전혀 감을 잡고 있지 못했던 USIM 부분이 많은 도움을 줬다. 이제 어디 가서 USIM 관련 기술 토론이 벌어지더라도 주고받는 용어를 이해할 기본 소양을 갖춘 것 같다. 또한 전화기 특성에 맞춘 전원 관리 기법과 임베디드 관점에서 자바와 C 코드 사이에서 연동을 위한 설계 부분을 좀더 신경써서 살펴볼 수 있었다는 점도 좋았다.

결론: 일반적인 전화 통신 규약에 안드로이드 특성에 변경된 리눅스 특성까지 고려해 전반적인 소프트웨어 아키텍처의 흐름을 짚어주므로 안드로이드로 스마트폰을 개발하는 분들이라면 꼭 한번 읽어보시기 바란다. 추천!

수요일, 10월 30, 2013

[일상다반사] 호프스태터와 인공지능

평상시에 늘 좋은 글을 소개해주시는 R님(@rhea813)께서 '<괴델, 에셔, 바흐>의 더글러스 호프스태터가 생각하는 AI'라는 트윗을 올려주셨기에 (거짓말 조금 보태) 숨도 쉬지 않고 The Man Who Would Teach Machines to Think를 읽어봤다. 오늘은 여기에 대한 감상문을 정리해보겠다.

아마 이 블로그 애독자라면 더글러스 호프스태터라는 이름은 한번 쯤 들어봤을테다. 1979견에 출간되어 퓰리처상을 수상한 Gödel, Escher, Bach: An Eternal Golden Braid는 '생각'과 '인지'에 대한 관점을 완전히 바꿔버린 명서이며, 유명한 과학저술가인 마틴 가드너는 이 책을 다음과 같이 평가하기도 했다.

Every few decades, an unknown author brings out a book of such depth, clarity, range, wit, beauty and originality that it is recognized at once as a major literary event.

퓰리처상이 언론, 문학, 음악과 관련해 수여되는 상임에도 불구하고, 호프스태터는 GEB를 수학, 미술, 음악에 대한 책이 아니라 신경과 두뇌, 사고와 인지에 대한 책으로 강조한다. 하지만 GEB에서 아주 살짝(!) 드러난 호프스태터의 문학, 수학, 예술, 언어, 철학에 대한 뛰어난 식견과 안목을 놓고 생각해보면... 인문학이 뭔지도 모르면서 인문학이라는 주제로 신나게 약파는 일부 몰지각한 사람들은(공학도들이 인문적인 소양이 부족하다는 둥... 좋은 제품을 만들려면 인문학적 특성을 가미해야 한다는 둥, 공자왈 맹자왈 ... 말은 청산유수다...) 호프스태터 앞에 일렬로 무릎꿇고 반성해도 시원치 않다. 빅 마우스 10명 아니 20명이 합세해도 엄청나게 무서운(진짜 말 걸기조차 무섭다고 한다) 호프스태터 앞에서는 특급 프로 체스 선수 앞의 동네 아마추어 모양으로 떡실신하리라 확신한다(지금 이 대목에서 웃으면 GEB의 '바흐' 부분을 읽은 사람이다. ㅋㅋㅋ).

자 그러면 도대체 GEB와 같은 역작을 내고 많은 사람들을 인공지능 연구로 끌어들인 호프스태터는 그 이후 무엇을 하고 있을까? 대학교 학창시절 인공지능 과목을 들을 때도 호프스태터의 이름은 수업시간에 언급되지 않았고, 요즘 엄청나게 쏟아지는 각종 연구 결과와 제품에도 그림자조차 비치지 않고 있다. 35살의 나이에 GEB로 당대 최고의 지식인이 될만큼 대단했던 호프스태터는 요즘 어디서 무엇을 하고 있을까? 일상에 찌들려 호프스태터라는 이름(다행스럽게 책장에 GEB와 The Mind's I가 꽃혀 있어 앞을 지날 때마다 종종 기억을 되살려주곤 하지만...)도 흐릿해질 시점에서 더 아틀랜틱에 실린 기사는 가뭄에 단비와도 같았다.

잠시 숨을 돌리기 위해 요즘 인공지능 추세를 살펴보자. 과거 '전문가 시스템'과 '기계 학습'으로 불렸던 이론을 토대로 IBM이 체스 기계를 만들고 구글이 번역 기계를 만들면서 내새운 구호는 간단하다. "더 많은 자료를!" 손에 들고 다니는 스마트폰의 성능이 초창기 슈퍼 컴퓨터(응?)에 맞먹을 수준에 이르렀고, 클러스터나 초병렬 컴퓨터 개념을 넘어 클라우드/가상화에 저렴한 컴퓨팅 파워와 스토리지를 갖추게 됨으로써 방대한 정보(심지어 '빅 데이터'라는 약 파는 용어도 등장했다!)를 잘 처리하면 저절로 컴퓨터에 지능이 생길 것으로 희망하고 있다(뉴턴 시절의 낙관주의를 떠올리게 만든다). 엄청나게 긁어모은 문서를 토대로 구글 번역기 수준은 초창기에 비해 일취월장했으며(특히 과거부터 번역에 목숨을 건 일본어를 중심으로 하는 번역 품질은 기절초풍할 수준이다), 체스에서 모든 사람을 놀라게 만든 IBM의 슈퍼 컴퓨팅 기술은 일반적인 산업 분야에도 기계 학습과 인공지능(?)을 전파하고 있으며, 대중의 사랑을 받는 애플의 시리 역시 사용자들의 질문과 대응을 누적하며 점점 더 강력해지고 있다. 하지만 이렇게 수 많은 자료를 긁어모아 처리한다고 해서 과연 컴퓨터가 '생각'을 하고 '인지'를 갖추게 될 것인가? 태풍에 휩쓸린 자동차 폐차장의 부품들이 이리저리 결합되어 신형 스포츠카가 탄생할 확률보다는 높지만 여전히 갈길은 멀어 보인다.

일흔이 다 된 호프스태터는 아직도 미련을 버리지 못하고 '무지막지한 자료'를 토대로 무지막지하게(brute force) 인공지능을 달성하는 방법 대신 사람이 생각하는 방식 그대로를 컴퓨터에게 가르치려 시도하고 있다. 여러 대학과 연구소에서 인공지능 관련 프로젝트를 제안했을테지만 (상업적으로 컴퓨터를 길들이는(응?) 주제로는) 성이 안 찼을테니, 외부(특히 인공지능 학회나 관계자)와 인연을 끊고 인디애나 대학교에서 자신의 꿈을 이루기 위해 소규모 팀을 운영하면서, 자신의 내면에서 일어나는 사고와 사고로 인한 행동을 직접 탐험하는 방식('현상학'이라고도 한다)으로 사실상 '컴퓨터'와는 무관하게 보이는 연구를 진행하고 있었다. 강직한 호프스태터는 잘 알면서도 실제 '지능'과 무관한 '인공지능'을 '지능'으로 포장해 파는 사기꾼 대열에 합류하기 싫었기 때문이었다. 다음 호프스태터의 말이 이를 뒷받침한다.

To me, as a fledgling AI person, it was self-evident that I did not want to get involved in that trickery. It was obvious: I don't want to be involved in passing off some fancy program’s behavior for intelligence when I know that it has nothing to do with intelligence. And I don't know why more people aren't that way.”

해커스에도 나오지만 ARPA가 DARPA로 변하면서 군과 무관한 기초적인 학술 연구에 투자를 끊으면서부터 MIT에서 싹을 틔운 1세대 해커들이 사분오열되며 급격히 상업적인 영역으로 넘어갔듯이, 순수한 '인공지능' 연구도 자금줄이 말라갔다. 호프스태터가 주장한 '인간의 지능을 이해하는 방법'에 대한 기초 연구가 결실을 맺지 못했기에 '인간 문제를 지능적으로 해결하는 방법'에 대한 응용 연구가 주도권을 잡으며 이미지 인식(군사 목표에 대한)과 전문가 시스템(복잡한 의사 결정을 도와주는) 분야가 급격하게 부상했다. 그리고 호프스태터는 사람들의 기억에서 급속히 잊혀지기 시작했다.

호프스태터는 마치 자신의 운명을 예언하기라도 한 듯, 인공지능 분야의 상황을 다음과 같이 요약했었다. "인공지능 분야의 모든 활동은 근본적으로 컴퓨터의 경직성을 타파하기 위한 전투다." 개인적인 생각(B급 프로그래머가 주절주절 늘어놓는 말은 너무 심각하게 받아들이지 말기 바란다. B급인데...)을 피력해보자면, 인공지능(한 걸음 더 나가 컴퓨터 분야)에서 최근 20년 동안 부분적인 전투에서 상당한 승리를 거두었고 일부는 훌륭한 해법을 찾기도 했지만 여전히 큰 그림(즉 전쟁)을 놓고 보면 획기적이고 판도를 완전히 뒤집을만한 성과를 거두지 못한 것으로 보인다. 사람들은 근본을 파고들 생각은 잘 하지 않기에 컴퓨터의 경직성도 문제였지만 사람들의 경직성이 풀어야할 더 큰 문제가 아닐까 싶다. 이런 상황에서 인간의 사고라는 본질을 놓고 벌이는 호프스태터의 고군분투는 놀랍고 대단하고 존경스럽기까지 하다. 아무쪼록 호프스태터의 건투를 빈다!

EOB

토요일, 10월 26, 2013

[독서광] 자바 병렬 프로그래밍

일단 프로그래밍 문제 하나 풀어보자. 다음 예제에서 숨겨진 Iteration을 찾을 수 있겠는가?

package net.jcip.examples;

import java.util.*;

import net.jcip.annotations.*;

/**
 * HiddenIterator
 * 
 * Iteration hidden within string concatenation
 *
 * @author Brian Goetz and Tim Peierls
 */
public class HiddenIterator {
    @GuardedBy("this") private final Set set = new HashSet();

    public synchronized void add(Integer i) {
        set.add(i);
    }

    public synchronized void remove(Integer i) {
        set.remove(i);
    }

    public void addTenThings() {
        Random r = new Random();
        for (int i = 0; i < 10; i++)
            add(r.nextInt());
        System.out.println("DEBUG: added ten elements to " + set);
    }
}

안 그래도 머리 아픈 독자 여러분들께 처음부터 코드를 불쑥 내밀어 대단히 죄송하다. 정답은 가장 마지막에 보여주기로 약속드리며 본론으로 들어가보자. 자바 프로그래머에게 권장할 책 세 권을 뽑으라면 두 번 생각하지 않고, 밥 아저씨의 'Clean Code(번역서: 클린 코드)', 조슈아 블로치의 'Effective Java(번역서: 이펙티브 자바)', 그리고 브라이언 게츠, 더그 리, 조슈아 블로치 등 막강한 저자들이 연합한 'Java Concurrency in Practice(번역서: 자바 병렬 프로그래밍)'을 고르겠다. 세 책 모두 깊이와 재미와 정확성을 모두 갖춘 보기 드문 특성을 제공하며 자바 뿐만 아니라 다른 프로그래밍 언어를 배우는 사람들에게도 많은 도움을 주는 내용을 담고 있다. 색인 작업까지 완료되었기에 조만간 복간판이 나올 '클린 코드'는 이미 이 블로그에서 몇 번 소개했므로 오늘은 넘어가고, '이펙티브 자바'는 조만간 소개해드리기로 하고, 오늘은 처음부터 끝까지 병렬에 목숨을 거는 '자바 병렬 프로그래밍'을 소개하겠다. '클린 코드'와 '이펙티브 자바'에서도 병렬 프로그램에 대한 내용이 일부 나오기는 하지만 병렬 프로그래밍 자체가 방대하고 복잡하다 보니 아무래도 다루지 않는 부분이 더 많기 마련이다.

자 그렇다면 오늘 소개할 '자바 병렬 프로그래밍'의 특징은 무엇일까? 이 책의 최대 장점은 바로 단순 API 설명을 넘어 병렬 프로그래밍의 기본 이론(_기본_이라 얕보면 절대 안 된다. 원래 기본이 제일 어려운 법이니...), API의 설계 사상과 동작 방식, 나쁜 프로그래밍 방법과 좋은 프로그래밍 방법, 아키텍처와 설계 방법, 성능과 확장성을 위한 프로그래밍 방법, 병렬 프로그래밍 테스트 방법, JVM의 내부 동작 방식과 메모리 모델 등을 빠짐없이 다룬다는 데 있다. 처음 이 책을 접하고 500페이지가 넘어가는 두꺼운 분량에 압도될 수도 있겠지만, 좋은 영화는 상영시간도 짧다고 느끼듯 다 읽고 나서 되돌아보면 엄청난 내용을 다루는 이 책이 결코 두껍지 않다는 사실을 느끼게 될 것이다. 자바는 처음부터 스레드와 동기화가 프로그래밍 언어에 속한 1등급 시민이므로 많은 내부/외부 라이브러리가 스레드에 안전하게(또는 특정 상황에서만 스레드에 안전하게) 작성되어 있으므로 API만 적당히 잘 사용하면 되지 않겠느냐는 생각이 들지 모르겠지만, 이 책을 읽다보면 지금까지 저지른 악행(응?)에 등골이 오싹해지고 소름이 끼치는 순간이 몇 번 온다고 장담해드리겠다.

개인적으로 이 책에서 가장 마음에 들었던 부분은 '3부 활동성, 성능, 테스트'다. 물론 다른 부분도 좋지만 특히 3부는 '락'을 중심으로 활동성, 성능, 확장성을 설명하고 있으므로, 단순히 동기화 모델로서 '락'을 넘어 새로운 시각으로 '락'을 바라보게 도와준다. 이 책을 읽고 나면 소스 코드에서 암시적인 락을 잡는 synchronized나 명시적인 락을 잡는 각종 키워드/API 함수를 볼 때마다 다양한 각도에서 이리 뜯고 저리 뜯어보는 좋은 습관이 들지도 모르겠다. 3부 후반에 설명하는 테스트 방법 역시 실전에 도움을 주는 구체적이고도 좋은 내용으로 채워져 있으므로 성능 문제로 고민하는 개발자분들께 많은 도움이 될 것이다.

마지막으로 번역 상태를 살펴보자. 인터넷 서평을 보니 번역이 나쁘다고 말하시는 분이 많았는데... 까칠한 B급 프로그래머 입장에서 보면 특별한 문제 없이 잘 읽혔다. 십중팔구 번역서가 어려우면 원서를 읽어도 어려울테니 굳이 진땀 흘려가며 두꺼운 원서를 독파하려 애쓸 필요는 없어 보인다.

보너스: 신형 홈페이지는 아직 작업을 진행하고 있지만, 옛날 홈페이지는 살아있으므로 소스 코드 등을 살펴보기 바란다. 참고로 에이콘 출판사 번역서 페이지에서도 전체 소스 코드를 내려받을 수 있다.

결론: 중급 이상 자바 프로그래머에게 강력하게 추천한다!

뱀다리: 처음 제시한 문제의 정답은 'System.out.println("DEBUG: added ten elements to " + set);'에 숨어 있으며, set을 출력하기 위해 Iterator를 돌린다. 아무리 간단한 프로그래밍이라 해도 병렬 특성이 들어가면 복잡해지므로 주의에 주의를 거듭해야 한다. T_T

EOB

화요일, 10월 22, 2013

[B급 프로그래머] SQL에서 UNIQUE와 NULL 제약 조건

NoSQL과 같은 최신(응?) 기술이 판을 치는 상황에서 갑자기 구닥다리 SQL을 꺼내 설명하려드니 독자 여러분들께서는 당황 아니 황당하다는 생각이 들지도 모르겠다. 하지만 프로그램을 작성하다보면 아주 기초적인 내용임에도 불구하고 알쏭 달쏭한 경우가 있기 마련이고, 궁금증이 생겼으면 뿌리부터 뽑아버려야 나중에 고생을 덜한다. 오늘 다룰 내용은 UNIQUE와 NULL이다. MySQL이라는 특정 데이터베이스를 기준으로 실험을 할 계획이니 혹시 진짜 여기 나오는 내용을 따라하고 싶은 독자라면 mysql 클라이언트를 하나 띄워놓기 바란다.

자 그러면 시작해보자. 가장 먼저 테이블을 생성하는 과정에서 PRIMARY 키에 대해 NULL 제약 조건을 허용하면 어떤 일이 벌어질까? PRIMARY인데 NULL이 가능한가? 원칙적으로는 모순되는 조건이다.

mysql> create table person (name varchar(64) null, age int, primary key(name)) ENGINE=InnoDB;

다음 명령 결과를 보면 알겠지만, MySQL은 내부적으로 (명시적인) null 지정을 가볍게 무시한다. PRIMARY 키로 지정한 name 필드의 Null을 보면 NO로 설정되어 있다.

mysql> desc person;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| name  | varchar(64) | NO   | PRI |         |       |
| age   | int(11)     | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+

자 그렇다면 난이도를 높여 약간 어려운 질문을 해보자. 위에서 정의한 person 테이블에 insert할 때 다음과 같이 name 값을 주지 않으면 어떤 일이 벌어질까? NOT NULL 조건이라는 사실을 염두에 두고 생각하면 오류가 발생할 것 같기도 하다.

mysql> insert into person (age) values (11);

하지만, 흥미롭게도 결과는 오류가 발생하지 않는다. select로 확인해보면 다음과 같다.

mysql> select * from person;
+------+------+
| name | age  |
+------+------+
|      |   11 |
+------+------+

이런! 화들짝 놀라는 분들도 분명히 계실 것이다. NOT NULL로 지정한 name 필드가 비어 있어! 물론 놀랄 필요가 전혀 없다. 다음 실행 예를 보면 이해가 갈테니까.

mysql> select * from person where name = NULL;
Empty set (0.00 sec)
mysql> select * from person where name = "";
+------+------+
| name | age  |
+------+------+
|      |   11 |
+------+------+
1 row in set (0.00 sec)

예전 수학 시험 문제 중 답이 없는 문제가 하나 있었는데, 답안을 쓰지 않은 학생이 선생님을 찾아가 "답이 없어 안 썼어요!"라 말했다가 혼난 기억이 새롭다. 선생님의 대답은 "답이 없으면 "답 없음"이라 써야지 안 그러면 자네가 모르는지 아니면 정말 답이 없는지 내가 어떻게 구분하나?"였다. NULL은 비어있는 상태를 의미하는 반면 ""는 빈값(즉 비어있는 문자열)을 의미한다(여기에 대해 나중에 블로그 글을 하나 더 올려드릴 계획이다). 여기서 Default가 NULL이 아니라(만일 NULL이라면 앞서 지정한 NOT NULL 조건에 위배된다) ""이라는 사실을 이해하면 이 모든 궁금증이 해소될 것이다.


NULL, NOT NULL로 충분히 장난을 쳤으니 이제 UNIQUE로 넘어가보자. 아까 테이블 그 상태 그대로 다시 다음과 같이 insert 문을 수행해보자. 어떤 결과가 나올까?

mysql> insert into person (age) values (12);

지금쯤이면 독자 여러분들도 속지 않으리라 믿는다. 다음 select 문 결과를 예측하고 있어야 한다.

mysql> insert into person (age) values (12);
ERROR 1062 (23000): Duplicate entry '' for key 'PRIMARY'

간단한 결론: PRIMARY는 NOT NULL이자 UNIQUE 속성이 자동으로 붙는다.


이제 UNIQUE에 집중해보자. 만일 PRIMARY가 아니라 다른 복합 색인을 생성하면 어떻게 될까? person 테이블을 조금 변경해보자.

mysql> drop table person;
mysql> create table person (name varchar(64), age int, money int, primary key(name), index myindex (age ASC, money ASC)) ENGINE=InnoDB;

myindex라는 age와 money를 포함하는 색인을 명시적으로 생성했다. 이제 다음과 같이 age, money 쌍이 동일한 값을 두번 insert 한다. scott/tiger를 보고 웃으면 당신은 옛날 사람이다. ㅋㅋㅋ

mysql> insert into person values ('scott', 100, 100);
mysql> insert into person values ('tiger', 100, 100);

앞서 PRIMARY와는 달리 중복되었다고 투덜거리지 않고 자료가 입력된다. 그러면 중복을 막으려면? myindex에 UNIQUE 조건을 걸어보자.

mysql> drop table person;
mysql> create table person (name varchar(64), age int, money int, primary key(name), unique index myindex (age ASC, money ASC)) ENGINE=InnoDB;

다시 한번 중복해 자료를 입력한다.

mysql> insert into person values ('scott', 100, 100);
mysql> insert into person values ('tiger', 100, 100);
ERROR 1062 (23000): Duplicate entry '100-100' for key 'myindex'

당연히 중복 오류가 발생한다. 자 그렇다면... age와 money를 둘 다 넣지 않으면 어떻게 될까?

mysql> delete from person;
mysql> insert into person (name) values ('scott');
mysql> insert into person (name) values ('tiger');

NULL-NULL이 중복될 경우 UNIQUE 조건을 위배하는지를 묻는 질문인데 주사위를 던져 정상/오류를 답하고 싶을지도 모르겠다. 중복되었다고 투덜거리지 않고 자료가 입력된다!

mysql> select * from person;
+-------+------+-------+
| name  | age  | money |
+-------+------+-------+
| scott | NULL |  NULL |
| tiger | NULL |  NULL |
+-------+------+-------+

앞서 설명했지만 NULL은 값이 아니라 비어있는 상태를 의미하므로 중복되었다고 볼 수 없다. 이미 예상하고 있겠지만, 단일 필드를 대상으로 unique를 지정해도 마찬가지로 NULL 중복(?)이 일어나지 않는다.


독자 여러분의 총정리를 위해 마지막으로 정말 쉬운 문제를 내며 이 글을 마무리하겠다. 만일 PRIMARY가 앞서 살펴본 단일키가 아니라 복합키로 구성되어 있을 경우 1) 중복을 허용하지 않게 하려면 UNIQUE를 붙여야 할까 붙이지 않아도 자동으로 될까? 2) 만일 PRIMARY 복합키는 중복되지 않더라도 복합키를 구성하는 개별 키가 중복되면(주의 기본값!) 어떤 일이 벌어질까? 다음 테이블로 직접 테스트해보시라!

mysql> drop table person;
mysql> create table person (name varchar(64), age int, money int, house int, primary key(name, house), unique index myindex (age ASC, money ASC)) ENGINE=InnoDB;
EOB

토요일, 10월 19, 2013

[독서광] 프로 Git : 그림으로 이해하는 Git의 작동 원리와 사용법

지난 번 [B급 프로그래머] hg/git 클라이언트인 SourceTree에서 git 책 한 권을 소개하겠다고 약속했는데, 까마귀 고기를 먹은게 아니라 책을 늦게 읽는 바람에 이제서야 독후감을 올려드릴 수 있게 되었다. 오늘 소개할 책은 git 책 중에 딱 한 권만 골라라고 요청이 들어올 경우 두 번 생각하지 않고 선택할 "프로 Git: 그림으로 이해하는 Git의 작동 원리와 사용법"이다.

오픈 소스의 활성화와 맞물려 국내에서도 이미 DVCS가 상당히 많이 보급되었기에 이미 git에 대한 이야기는 많이 들어봤을 것으로 생각한다. 깃허브는 이미 명실상부 오픈소스 저장소의 대명사로 자리잡고 있고, 한 때는 전문가의 전유물로 알려진 git는 이제 좋든싫든 기초 지식 정도는 알고 있어야 원활한 오픈소스 프로젝트 진행이 가능한 상황으로 가고 있다. 하지만 git의 진입 장벽은 높기로 악명이 자자하다. 이런 난국을 어떻게 돌파해야 할까? 정답은 바로 '프로 Git'다. 설명을 위한 다이어그램이 아주 다채롭고 풍부한 이 책은 깃허브에 근무하면서 git 전도사로 유명한 스캇 샤콘이 집필했기에 간결하면서도 쉬우면서도 정확하다는 특징이 있다(보통 이 모든 특징을 책 한 권에서 찾아보기가 쉽지 않다). git의 명령 체계는 고수준(Porcelain)과 저수준(Plumbing)으로 나뉘어져 있는데, 이 책은 둘을 절묘하게 잘 나눠 설명한다. 고수준 명령만 사용해도 대다수 작업에 어려움을 느끼지 않지만, 살다보면 저수준 명령을 사용해야 할 경우가 생기기 마련이다. 또한 git의 이해를 넓히려면 저수준 명령으로 눈을 돌려야 한다. 따라서 스캇 샤콘은 본문에서 꼭 필요한 경우에만 저수준 명령을 제시하고, 실제 저수준 명령의 동작 원리는 9장 'Git의 내부'에서 집중적으로 설명한다. 하드코어한 개발자라면 바로 9장부터 읽으며 "어라? git 코어는 일반적인 키-값 저장소에 포인터 개념을 결합해놓은 물건이잖아!"라고 외치며 낄낄거릴지도 모르겠다.

바쁜 독자를 위해 간략하게 이 책의 활용 방안을 소개하자면, 우선 2장 'Git의 기초'와 3장 'Git의 브랜치'를 읽는다. 그리고 나서 조금 써본 다음에 다시 5장 '분산환경에서의 Git'와 6장 'Git 도구'를 읽어본다. 그리고 실제 내부 동작 방식이 궁금한 독자라면 적절한 시점(응?)에서 9장 'Git의 내부'를 읽으면 git를 프로젝트에 적용할 준비가 완료되는 셈이다. 기존 cvs/svn과 같은 버전 관리 시스템에 익숙한 독자라면 아마 git의 파격적인 개념과 접근 방법을 접하면 거의 기절 초풍할지도 모르겠다는 생각을 해본다(이게 바로 git를 처음 접할 때 멍해지는 이유다). cvs/svn을 알고 있기 때문에 유리한 면도 있지만 불리한 면(특히 브랜치와 태그 관리 방법에 들어가면 완전 신세계가 펼쳐진다)도 있으므로 고정 관념을 버리도록 최선을 다하면 좋은 결과를 얻지 않을까 싶다.

독자 여러분을 위해 보너스 힌트를 드리려 한다. 이미 알고 계신분들도 있겠지만, 프로 Git는 원래 PDF 형태로 한국어 번역판이 공개되어 있었다. 자세한 내용은 '프로 Git', 이미 공개된 내용을 왜 책으로 만들었냐고요?를 살펴보기 바란다. 공개된 문서를 다듬어 정리된 번역서 품질이 아주 좋기 때문에 굳이 원서를 읽을 필요가 없다는 생각이다. 그리고 혹시 Hg(Mercurial)에서 git로 넘어갈 필요가 있다면 Mercurial for Git users를 읽어보기 바란다. 원래는 Git 사용자를 위해 만들었으나, Hg 사용자라면 반대 방향에서 접근하면 이해가 손쉬울 것이다.

결론: 고민할 필요없다! 'clone'만 간신히 할줄아는 초급 git 사용자는 물론이고 'branch를 따고 합칠줄도 아는' 중급 git 사용자 모두에게 강력하게 추천한다.

EOB

화요일, 10월 15, 2013

[B급 프로그래머] 10월 3주 소식 정리

시간이 참 빨리 가니 벌써 10월 3주가 되었다. 이번 주부터는 조금 형태를 바꿔 시간별이 아닌 분류별로 정리해 가독성을 높이겠다.

  1. 웹 개발
  2. 개발/관리 도구
  3. 고성능 서버/데이터베이스
  4. 기타 읽을 거리

그러면 기간이 조금 길긴 하지만... 11월 1주에 좋은 소식을 담아 독자 여러분을 찾아뵙도록 하겠다.

EOB

토요일, 10월 12, 2013

[B급 프로그래머] 블로거에 소스 코드 예쁘게 올리기

종종 블로그에 글을 쓰다 보면 소스 코드를 올려야 할 경우가 있다. 지금까지는 <pre> 태그를 사용해 밋밋하고 재미없는 소스 코드를 보여드렸는데, 앞으로는 Javascript code prettifier를 사용해 예쁜 소스 코드를 올려드리려 한다.

유명한 'hello, world'를 예로 들어보자. 지금까지 아래처럼 코드를 보여드렸다면...

/* hello, world! */
#include <stdio.h>

int main(int argc, char** argv) {
printf("hello, world!\n");
return 0;
}

앞으로는 다음과 같이 코드를 보여드릴 계획이다.

/* hello, world! */
#include <stdio.h>

int main(int argc, char** argv) {
printf("hello, world!\n");
return 0;
}

물론 C 코드 이외 다른 코드(HTML, 자바, 루비, 파이썬 등등)도 Javascript code prettifier에서 지원하므로 칙칙했던 B급 프로그래머 블로그가 조금 더 밝아지리라 기대한다.

# Ruby knows what you
# mean, even if you
# want to do math on
# an entire Array
cities  = %w[ London
              Oslo
              Paris
              Amsterdam
              Berlin ]
visited = %w[Berlin Oslo]

puts "I still need " +
     "to visit the " +
     "following cities:",
     cities - visited

그러면 어떻게 이런 마법을 부렸는지 독자 여러분을 위해 간단히 핵심만 설명드리겠다.

  1. 블로거 관리도구를 열어 좌측 메뉴에서 템플릿 항목을 선택하고 [HTML 편집] 버튼을 눌러 HTML 편집 화면으로 들어간다. 편집 화면에서 </head>를 찾아 바로 위에 다음과 같은 코드를 넣는다.
    <link href='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.css' rel='stylesheet' type='text/css'/>
    <script src='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.js' type='text/javascript'/>
    
  2. 아직 편집이 덜 끝났다. 자바스크립트 코드를 구동하기 위해 <body>를 찾아 다음과 같이 가장 끝 부분에 onload 메소드를 추가한다.
    <body ... onload='prettyPrint()'>
    
  3. [템플릿 저장] 버튼을 눌러 변경 내용을 저장한다. 혹시 모르니 [템플릿 미리보기] 버튼을 눌러 화면이 깨지지는 않는지 확인한다.
  4. 이제 준비가 끝났으므로 블로거 관리도구에서 새 글을 작성해 다음과 같이 간단한 코드를 추가해본다. 알록달록 예쁘게 나와야 한다.
    <pre class=prettyprint>
    int x = foo(); /* foo */
    int y = bar(); /* bar */
    </pre>
    
  5. 코드에 행 번호를 보여주고 테마를 바꾸는 등 추가 정보는 Javascript code prettifier README를 참고하기 바란다.

한 가지 주의 사항을 덧붙이겠다. 이런 부류의 스크립트는 대부분 코드를 있는(!) 그대로 출력하므로 코드 내부에 <와 >등이 들어 있을 경우 웹 브라우저가 내부 문자열을 태그로 인식해 잡아 먹어버린다. 코드량이 적을 경우에는 문제가 되는 부분을 일일이 손으로 수정해도 되지만 그렇지 않은 경우 실수할 가능성이 높다. 다행히도 인터넷에 HTML 코드를 이스케이프하는 도구가 많이 올라와 있으므로(예: Replace special characters with HTML Entities - Online tool), 번거롭지만 이를 사용해 문제가 되는 문자를 치환하기 바란다.

EOB

화요일, 10월 08, 2013

[일상다반사] '해커스' 애독자분들을 위한 이벤트!

해님께서 올려주신 Peopleware 번역을 시작합니다를 이미 읽으신 분들은 알고 계시겠지만, Peopleware의 개정 3판의 번역을 한창 진행하고 있다. 피플웨어 : 정말로 일하고 싶어지는 직장 만들기라는 제목으로 국내에도 이미 2판 번역서가 나와있지만, 절판되었으므로 새로 구입하려는 독자분들께서는 중고책 대신 조금 기다리셨다 새로 번역된 책이 나오기를 기대하시면 좋겠다.

어쩌다보니 이야기가 옆으로 새버렸는데, 오늘 글을 쓴 목적은 피플웨어 소개가 아니라 여러분들께서 열렬히 성원해주신 해커스 애독자를 위한 이벤트 소개다. 이미 짐작하셨겠지만, 이벤트 상품으로 '피플웨어' 번역서를 골랐다. 그렇다면 이벤트 미션이 무엇일까? 2013년 10월 31일까지(시간은 아아주우 넉넉하게 드렸고 그 전에 응모하셔도 무방하다) 다음 중 하나를 골라 진행하시면 된다.

  • 오탈자와 이해 안 가는 곳 정리: (독자 여러분들께 무척 죄송하지만...) 해커스 책이 워낙 두껍다 보니 1쇄에 오탈자가 존재한다. 꼼꼼하신 분들이라면 책을 읽으시다 틈틈히 정리해 최종 결과물을 이메일(노파심에서 주소를 알려드리자면: jrogue 엣뜨 gmail.com)로 보내주시면 된다.
  • 독후감: 그냥 독후감이 아니라, 왜 하필 제목 옆에 '무삭제' 판이라 수식어를 붙였을까? 이를 중심으로 독자 여러분의 생각을 정리해 온라인 서점 서평이나 블로그에 올려주시고 이메일로 확인 편지를 보내주시면 된다.
  • 80년대 경험담: 한국의 개인용 컴퓨터 태동기인 1980년대에 직접 해킹한(좋은 의미로) 경험담을 재미있게 작성해 블로그에 올려주시고 이메일로 확인 편지를 보내주시면 된다. 만일 블로그를 운영하지 않을 경우에는 이메일로 사연을 보내주셔도 된다.

각 미션별로 가장 멋지게 목표를 달성하신 한두분을 뽑아 '피플웨어' 번역서 출간 직후 바로 보내드리기로 약속하겠다. 모든 '해커스' 독자 여러분들의 행운을 빈다!

EOB

토요일, 10월 05, 2013

[독서광] 어떻게 원하는 것을 얻는가

40대 직장인을 위한 조언: 과거 언급은 금물이라는 월스트리트 저널 기사를 읽다보니 다음과 같은 문구가 눈에 띄었다.

"사람들은 타인의 특정한 행동과 관련해 타협을 하거나 관대해야 한다고 생각하지만 그러기보다는 타인의 행동을 이해해야 한다. 타인의 행동 동기가 무엇인지를 인지하는 것이 더 중요하다. 사람들이 왜 어떤 행동을 하는지를 이해해야 한다”고 랑거 교수는 말한다."

그렇다면 타인의 행동을 이해하기 위해 우리는 어떤 노력을 해야할까? 오늘 소개한 '어떻게 원하는 것을 얻는가'라는 책을 읽다보니 다른 주제임에도 불구하고 동일한 해법을 사용한다는 사실에 깜짝 놀랐다. 이 책 저자인 스튜어트 다이아몬드 교수와 인터뷰를 한 기사('어떻게 원하는 것을 얻는가' 저자 스튜어트 다이아몬드 美와튼스쿨 교수)를 읽다보면 다음과 같은 문구가 나온다.

"협상의 가장 중요한 과제는 무엇보다 상대방 입장이 돼 그의 머릿속에 들어가봐야 한다는 것이다. 협상은 그들의 생각과 감성·니즈(needs·원하는 것들)를 파악하는 작업이다. 상대방이 예전에 했던 말도 찾아내 곱씹어야 상대방이 지금 원하는 걸 알 수 있다. 내가 볼 때는 별 의미 없는 것인데, 상대방이 이를 절실히 원한다면 비용 부담 없이 들어줄 수 있다. 그러면 내가 원하는 것을 상대방으로부터 얻을 수 있다."

표현은 다르지만 맥락은 비슷하다. 바로 '남의 입장이 되어 머리속을 그리고 무슨 생각을 하는지 파악하라'로 줄여 말할 수 있다. '어떻게 원하는 것을 얻는가'는 일반적인 자기 계발서나 대인 관계 테크닉 서적으로 읽힐 가능성도 있지만 의외로 우리가 너무나도 간과하는 기본적인 사실을 짚어주기 때문에 그냥 재미로 읽고 끝낼 책이 아니라는 생각이 들었다. 이 책에서 주장하는 가장 핵심적인 내용은 바로 '사람'이다. 다이아몬드 교수는 우리가 협상할 상대는 게임 이론에 나오는 이성적인 인간(스폭)이 아니라 감정적인 인간(커크)이며, 협상을 성공으로 이끌기 위해 전문 지식이나 협상 절차가 아니라 '사람'에 대한 이해가 가장 앞서야 한다고 강력하게 주장한다. 그리고 일상 생활에서 꾸준한 연습에 의해 이런 능력이 배양되므로 평상시에도 물건을 할인 받고 서비스를 추가로 받고 차별 대우를 받았을 때는 정당한 대우를 받도록 노력하라는 조언을 아끼지 않는다. 이 책의 대다수 내용이 (어떻게 보면) 정말 시시콜콜한 사례로 가득차 있는 이유는 이런 사례를 하나씩 따라하라는 것이 아니라 정말 다양한 상황에서 협상이 가능하다는 교훈을 줄 목적이 아닌가 싶은 생각도 들었다. 하긴 시시콜콜한 사소한 협상도 못하는 데 큰 협상이 가능할리 없지. T_T

이 책에서 주장하는 몇 가지 협상의 교훈을 정리해드리겠다.

  • 상대의 머리속을 파악하라: 항상 질문과 대답을 반복하며 상대방의 입장이 되어 구체적으로 상대가 진짜 무엇을 바라며 어떤 생각을 하고 있는지 지도를 그려야 한다. 그러면 협상의 폭이 자연스럽게 넓어진다.
  • 감정이 중요하다: 물리적인 지불을 하지 않고서 감정적인 지불만 하더라도 협상에 유리한 환경을 조성할 수 있다.
  • 동일한 상황은 없다: 전문적인 지식, 협상 절차를 갖추고 충분히 준비하더라도 그 때 그 때 상황은 바뀌기 마련이다. 사람이 동일하고 협상 건이 동일하더라도 매번 달라질 수 있다는 사실을 기억해야 한다.
  • 서로 중요하다고 생각하는 가치를 교환한다: 사람마다 원하는 가치가 다르므로, 돈의 관점이 아니라 요구의 관점에서 교환할 가치를 찾아야 한다. ((어른에 비해) '돈'이 없는 어린이들은 여기에 있어 거의 최고의 능력을 발휘한다)
  • 상대방이 따르는 표준을 활용한다: 사람들은 자신이 내건 표준과 모순되는 상태에 있기를 대단히 거북스러워한다. 협상 과정에서 혹시 상대편이 자신이 내세운 표준과 다른 형태로 계약을 맺으려 든다면 여기에 대해 짚고 넘어가자.
  • 위협과 비난은 해법이 아니다: 보통 목소리 큰 사람이 이긴다는 편견이 만연하다. 하지만, 이런 전략은 한 번은 통할지 몰라도 두 번은 힘들다.
  • 신뢰가 중요하다: 거짓말은 신뢰를 갉아먹는 적이다. 밝혀도 되는 안건에 대해서는 무슨 생각을 하고 무엇을 얻고 싶은지 미리 상대편에게 진실되게 알려주는 편이 협상의 성공 가능성을 높인다.
  • 제 3자를 활용하라: 상대편이 협상에 있어 실질적인 권력이 없는 경우가 있다. 이럴 때는 누구를 움직여야 하는지 이해 당사자를 찾아나서야 한다.
  • 걸림돌을 없애라: 협상 과정에서 나타나는 걸림돌을 차근차근 없애야 한다. 영화와는 달리 협상은 한 방에 화끈하게 끝나는 이벤트가 아니므로 상대방 입장에서 차근차근 문제점을 파악해 제거한다. 걸림돌 때문에 교착 상태에 빠지지 않으려면 처음에 손쉬운 안건부터 처리하는 방법이 유리하다.
  • 논리보다 공감: 단 '공감'이 진실되지 않으면 역풍을 맞을 것이다.

여기까지 읽고 와닿는 뭔가가 있으면 책에 나오는 다양한 교훈과 사례를 읽어보기 바란다. 매번 대인 관계에서 손해를 본다는 느낌이 드는 분들께 특히 추천한다.

뱀다리: 며칠 전 지방 출장이 있어 택시를 타서 기사분과 이런 저런 이야기를 나누던 도중 근무일에 평균 12시간 이상 운전하신다는 이야기를 듣고서 나도 모르게 '감정 지불'(응?)을 해버렸다. 결과는? 공사로 인해 길이 엄청 막혔음에도 불구하고 최대로 빠른 길로 우회해 평상시보다 더 빨리 도착했고 요금까지 할인 받았다. (평상시 에누리라고는 꿈도 못꾸던 상황에서 자신감이 조금 붙었기에) 앞으로도 계속 연습해볼 생각이다.

EOB

수요일, 10월 02, 2013

[B급 프로그래머] 2013년 10월 1주 소식 정리

10월 1주 소식을 정리해드린다.

그러면 따끈한 소식을 정리해 10월 3주에 찾아뵙도록 하겠다.

EOB

토요일, 9월 28, 2013

[일상다반사] (유명 인사들로부터 배우는) 창의력이란 무엇일까?

What Is Creativity? Cultural Icons on What Ideation Is and How It Works라는 글을 읽으며 대가들의 창의력에 대해 다시 한번 되짚어봤다. 독자 여러분을 위해 흥미로운 몇 가지 내용을 번역해봤다.

모리스 센닥이 편집자에게 보낸 편지에 적힌 내용:

지식은 창의적인 열정을 동작하게 만드는 원동력이다.

빌 모이어즈의 의견:

창의력은 일상을 날카롭께 꿰뚫어 거짓말 같은 사건을 찾아낸다.

알버트 아인슈타인의 생각:

구어든 문어든 말이나 언어는 내 생각의 메커니즘에 큰 몫을 하지 못하는 듯이 보인다. 생각의 구성 요소를 이루는 듯이 보이는 물리적인 개념을 출발점으로 점점 명확한 상이 생성되며 합쳐진다.
물론 이런 구성 요소와 관련 논리 개념 사이에는 연관 관계가 존재한다. 논리적으로 연결된 개념에 도달하려는 욕구는 위에 언급한 구성 요소로 이리저리 놀아보는 감정적인 기초라는 사실도 명확하다. 하지만 심리학적인 관점에서 보면, 이런 결합 놀이는 생산적인 사고에 있어 핵심적인 특징인 듯이 보인다.

스티븐 제이 굴드와 인터뷰 내용 중:

무관하게 보이는 대상 사이에 연결점을 파악하는 특이한 굴드의 능력은 창의력의 본질에 경종을 울린다. 의심할 바 없이, 굴드는 창의력에 대한 가장 인기 있는 다방면의 정의를 원점으로 되돌렸다. 무관한 둘 사이를 효과적으로 연결한다는 아이디어가 출발점이다. 이런 연결 관계에셔 경험한 놀라움은 발걸음을 멈춰 생각하게 만든다. 이게 바로 창의력이다.

스티브 잡스의 의견:

창의력은 단순히 사물의 연결이다. 창의적인 사람들에게 어떻게 그런 일을 했느냐고 물어볼 때, 이들이 죄의식을 조금 느끼는 이유는 실제로 그런 일을 한 게 아니라 뭔가를 보았을 따름이기 때문이다. 조금 시간이 흐르면 창의적인 사람들에게는 (자신이 한 일이) 당연한 듯 느껴진다. 창의적인 사람들이 겪은 경험을 연결해 새로운 뭔가를 합성해낼 능력이 있기 때문이다. 그리고 다른 사람보다 경험에 대해 더 많이 생각했거나 더 많은 경험을 했기에 창의적인 작업을 할 수 있다. 불행히도 이는 주변에서 찾기에 아주 드문 특성이다. 우리 업계에 있는 많은 사람들은 엄청나게 다양한 경험을 하지 못했다. 따라서 연결 가능한 충분한 점이 없으며, 문제에 대해 넓은 시각이 없이 아주 선형적인 해법만 내고 끝난다. 사람의 경험에 대한 이해가 더 넓어질수록 더 좋은 디자인이 나온다.

조지 루이스의 의견:

창의력은 거의 어떤 문제도 풀 수 있다. 창의적인 행동, 타고난 버릇의 타파는 모든 것을 극복한다.

말콤 그레드웰의 의견:

창의력은 항상 우리에게 놀라움으로 다가온다. 따라서 절대로 창의력에 의존할 수 없으며, 실제로 창의력이 발현될 때까지는 감히 믿을 엄두도 내지 못한다. 다시 말해, 우리는 창의력이 발현될 필요가 확실한 성공적인 과업에 의식적으로 관여하지 못한다. 따라서, 창의적인 자원을 완벽하게 활용하려면 해당 과업의 특성을 완전히 오판해 좀더 반복적이고 단순하고 창의력을 요구하지 않는 형태로 받아들이는 방법이 필요하다. 나중에야 해당 과업에서 창의력이 필요하다고 밝혀질 것이다.

존 클리즈의 의견:

창의력은 재능이 아니다. 운영 방식이다.

자 그렇다면 여러분이 생각하는 창의력은?

EOB

화요일, 9월 24, 2013

[B급 프로그래머] git를 위한 공개 키 인증 해법 정리

윈도와 각종 *nix 환경에서 산전수전 공중전에 잠수함전까지 다 겪은 B급 프로그래머지만, 제대로 사용하기 위해 git 만큼 머리를 써야하는 환경을 아직 보지 못했다. git는 사용법도 아주 복잡하지만 설정 자체도 (과거에 비해 쉬워졌다고는 하나...) 사용법에 못지 않게 상당히 복잡하다. 오늘은 그 중에서 특히 공개 키 인증 해법을 애독자 여러분 뿐만 아니라 B급 프로그래머 본인을 위해(!) 총정리하겠다(지금 키 설정하다 잠시 길을 잃은 상황...).

가장 먼저 공개 키 인증이 무엇인지부터 간단하게 설명할 필요가 있다. 대다수 무따기(약어처럼 무작정 따라할 수 있으면 좋겠지만 SSH 관련 무따기 문서들은 잘되면 다행이지만 혹시라도 문제가 생겼을 경우 지옥으로 가는 급행 티켓이다. T_T)에서는 독자들이 여기에 대해 충분히 안다고 가정하고 넘어가는 경향이 있는데... 나중에 뒷목 잡지 않기 위해 우분투의 공식 문서인 SSH/OpenSSH/Keys를 읽어보는 편이 바람직하다. 공개 키 인증 방식은 텍스트 암호 입력을 사용한 인증 방식에 비해 훨씬 더 보안이 강화되고 편의성도 높다는 장점이 있다. 이 글에서 암호학을 설명할 의도는 없으므로 문서 중에 가장 중요한 내용만 요약해 함께 읽어보자.

With public key authentication, every computer has a public and a private "key" (a large number with particular mathematical properties). The private key is kept on the computer you log in from, while the public key is stored on the .ssh/authorized_keys file on all the computers you want to log in to.

한글로 정리하면 다음과 같다. 공개 키 인증을 위해, 컴퓨터마다 공개 키와 개인 키를 설치해야 하는데, 개인 키는 여러분이 다른 곳으로 접속할 출발지 컴퓨터에 보관해야 하고, 공개 키는 여러분이 실제 접속할 목표 컴퓨터에 보관해야 한다. 이제 한 가지 사실은 명확해졌다. git 중앙 저장소(좋은 예: github.org나 bitbucket.com)에는 반드시 여러분의 공개 키를 올려야 한다(하긴 개인 키를 만인에게 공개한다는 생각 자체가 우습긴 하지만 실수는 누구나 한다. T_T). 참고로 깃허브나 비트버킷 사이트로는 원격 셸 접속이 가능하지 않으므로 .ssh/authroized_keys에 공개 키를 저장하는 대신 관리 도구를 사용해야 한다. 잠시 후에 살펴보기로 하고... 우선 음식 재료인 공개 키와 개인 키를 만드는 방법에 집중하자.

공개 키와 개인 키는 쌍(pair)으로 존재한다. 따라서 하나를 잃어버리면... 재앙이 닥친다 새로 만들어 항상 쌍을 유지해야 한다. 공개 키와 개인 키를 만드는 방법을 간단히 설명하겠다. 리눅스를 사용하는 분들이라면 OpenSSH 패키지에 들어 있는 ssh-keygen 명령을 사용해 다음과 같이 한 방에 키 쌍을 생성할 수 있다(보안 강화를 위해 DSA 대신 RSA를 사용하자. '-t rsa' 옵션을 붙이면 된다).

$ ssh-keygen -t rsa

윈도를 사용하시는 분들이라면 putty에 들어있는 PuTTYgen(Putty Key Generator)을 떠올리실지도 모르겠는데, Msys기반 Git for Windows를 설치했다면 ssh-keygen.exe가 따라오므로 리눅스와 동일한 방식으로 공개 키와 개인 키를 생성하면 된다. ssh-keygen이 기본으로 키를 생성하는 위치는 (리눅스와 윈도 모두) 사용자 홈의 .ssh 디렉터리 아래다. id_rsa가 개인 키이며 id_rsa.pub가 공개 키라는 사실을 기억하자. 보안을 높이려면 passphrase를 입력해 개인 키 자체에 암호를 거는 방법도 있다(물론 이렇게 암호를 걸어놓으면 SSH로 접속할 때마다 암호를 물어볼 것이다. 물론 나중에 설명하겠지만 한번만 암호를 입력하면 되는 방법도 있다!). 이제 재료를 구했으니 본격적으로 요리를 시작하자.

앞서 만든 공개 키($HOME/.ssh/id_rsa.pub 또는 %HOME%\.ssh\id_rsa.pub)를 깃허브와 비트버킷에 올리자. 로컬 컴퓨터에서 적당한 편집기로 id_rsa.pub를 열어 텍스트 내용을 복사한 다음 웹 브라우저의 Key textarea 영역에 붙여넣고 저장하면 된다. 백문이 불여일견이라는 충고에 따라 그림으로 정리해봤다.


(깃허브: Title과 Key 예는 비트버킷 내용을 참조한다)

(비트버킷: 여기 나온 키는 가짜 공개 키이므로 생긴 모양새만 확인하기 바란다.)

그리고 나서... 정말 제대로 동작하는지 시험해보자. 가장 손쉬운 방법은 ssh를 사용해 직접 접속해보면 된다. 리눅스나 Msys 기반 Git for Windows가 설치된 환경이라면 다음과 같이 확인하면 된다. (주의: 직관에 반하는 이야기처럼 들리겠지만... git라는 계정을 개인 계정으로 바꾸면 안 된다.)

$ ssh -vT git@github.com
$ ssh -vT git@bitbucket.org

처음 접속할 경우 'The authenticity of host 'bitbucket.org (131.103.20.167)' can't be established." 또는 "The authenticity of host 'github.com (192.30.252.130)' can't be established."와 유사한 경고 메시지가 뜨며 RSA key fingerprint를 보여주며 접속할지 말지를 물어본다. 'yes'라 답하면 로컬 컴퓨터의 $HOME/.ssh/known_hosts나 %HOME%\.ssh\known_hosts에 공개 키가 영구적으로 등록되어 자동으로 해당 호스트를 신뢰하게 된다. 가장 마지막 부분에 주목하자. 혹시라도 다음과 같은 메시지가 나오면 키 쌍에 문제가 생긴 상황이다.

debug1: Next authentication method: publickey
debug1: Trying private key: $HOME/.ssh/identity
debug1: Offering public key: $HOME/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: $HOME/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

제대로 키 쌍을 맞췄는지 다시 한번 확인하고 로그를 확인하며 디버깅을 반복하자.

자 여기까지 읽었으면 기초 지식은 습득한 셈이다. '해법'이라 부르기에 너무 싱겁다고? 그렇다면... 두 가지 고급 지식을 전수해드리겠다. 만일 개인 키-공개 키 쌍이 여러 개인 경우에는 어떻게 될까? 예를 들어, 사내 리눅스 운영체제에 셸 접속을 위한 개인 키 - 공개 키 쌍과 비트버킷 접속을 위한 개인 키 - 공개 키 쌍이 다르다면? 그럴 경우에는 ssh 설정 파일을 활용하면 된다. $HOME/.ssh/config 또는 %HOME%\.ssh\config 파일을 만들고 다음 내용을 채우자. 여기서 id_rsa_bitbucket은 구분을 위해 이름을 변경한 비트버킷용 개인 키다.

Host bitbucket.org
  IdentityFile ~/.ssh/id_rsa_bitbucket

이렇게 하고 나서 ssh -vT 명령을 사용해 비트버킷 사이트에 테스트 접속하면 중간 디버깅 로그에 id_rsa_bitbucket을 사용한다는 메시지(debug1: Trying private key: $HOME/.ssh/id_rsa_bitbucket)가 나올 것이다.

마지막으로 앞서 언급했던 개인 키에 passphrase를 걸어놓아 매번 git 명령을 내릴 때마다 암호를 입력해야 하는 번거로운 상황을 피하려면 어떻게 해야 할까? 리눅스나 맥OS X이라면 OpenSSH 패키지에 들어 있는 인증 에이전트를 사용하면 된다. '$ ssh-agent /bin/bash; ssh-add ~/.ssh/id_rsa/id_rsa_bitbucket'라는 명령을 내리면 ssh-agent가 id_rsa_bitbucket 개인 키에 대한 암호를 기억해 클라이언트에 (사람) 대신 자동으로 입력해준다. 그렇다면 윈도는? 다행히 누군가 이미 해법을 만들어 놓았다. $HOME/.bashrc라는 파일을 만들고(눈치 빠른 독자들이라면 bashrc 셸 초기화 스크립트는 윈도 명령 프롬프트에서 동작하지 않는다는 사실을 지적할 것이다. 잠시 뒤에 이에 대한 다른 해법을 소개할테니 조금만 참고 기다리자) 다음 내용을 입력하자. 앞서 나온 id_rsa_bitbucket 개인 키에 passphrase를 걸어놓았다면 다음 내용 중간에 나오듯 '/usr/bin/ssh-add ~/.ssh/id_rsa_bitbucket'처럼 명시적으로 개인 키 이름을 설정해야 한다.

SSH_ENV=$HOME/.ssh/environment

# start the ssh-agent
function start_agent {
    echo "Initializing new SSH agent..."
    # spawn ssh-agent
    /usr/bin/ssh-agent | sed 's/^echo/#echo/' > ${SSH_ENV}
    echo succeeded
    chmod 600 ${SSH_ENV}
    . ${SSH_ENV} > /dev/null
    /usr/bin/ssh-add ~/.ssh/id_rsa_bitbucket
}

if [ -f "${SSH_ENV}" ]; then
     . ${SSH_ENV} > /dev/null
     ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
        start_agent;
    }
else
    start_agent;
fi

git 패키지에 들어있는 git bash를 수행하면 다음과 같은 문구가 나오며 passphrase 입력을 1회 요청한다.

Initializing new SSH agent...
succeeded
Enter passphrase for $HOME/.ssh/id_rsa_bitbucket:
Identity added: $HOME/.ssh/id_rsa_bitbucket ($HOME/.ssh/id_rsa_bitbucket)

입력을 끝내고 나면 identity가 추가되었다는 문구가 출력된다. 다음 명령을 내려 제대로 인증 정보가 들어갔는지 확인하자.

$ ssh-add -l

git bash에서 ssh 명령을 내리면 passphrase가 걸려 있는 개인 키인 경우에도 암호 입력 없이 접속에 성공할 것이다.

$ ssh -vT git@bitbucket.org

혹시 윈도 환경에서 Source Tree 등을 사용하거나 git bash 이외 윈도 명령 프롬프트나 명령 프롬프트 대체품인 ckw을 사용한다면 PuTTY 패키지의 Pageant를 활용하는 방법도 생각해봐야 한다. Pageant는 ppk 형식의 키만 사용 가능하므로, 먼저 PuTTY 패키지의 Puttygen을 사용해 RSA 개인 키를 ppk로 변환하고 나서('Conversions' 메뉴에서 'Import key'를 선택하고 파일 선택 대화 상자가 나오면 개인 키인 id_rsa_bitbucket 파일을 선택하고 passphrase를 입력하면 키를 로드한다. 화면 상단에서 개인 키가 맞는지 확인한 다음 'Save the generated key' 항목의 [Save private key] 버튼을 눌러 적당한 이름을 붙인 ppk 개인 키로 저장하면 된다) Pageant를 띄운 다음 변환된 개인 키를 등록하면 된다.

준비가 끝나면 GIT_SSH 환경 변수를 설정하자. 참고로 Putty 다운로드 페이지에서 Windows Installer 버전을 받으면 Putty, Puttygen, Plink, Pageant를 한번에 설치할 수 있다. 다음과 같이 명령 프롬프트에서 plink 설치 경로를 GIT_SSH 환경 변수에 설정하기 바라며, 윈도 고급 시스템 설정에도 해당 환경 변수를 추가하면 더욱 간편하게 사용할 수 있다.

C:\> set GIT_SSH=C:\Program Files (x86)\PuTTY\plink.exe

아쉽게도 git 패키지에 들어있는 ssh 명령은 GIT_SSH 환경 변수를 인지해 passphrase를 자동으로 입력받지 못하므로 ssh 명령 자동화가 필요한 경우 git bash를 사용하기 바란다.

이 정도 내용이면 윈도/리눅스/맥OS X 환경에서 git 공개 키 인증 설정에 별다른 무리가 없으리라 본다. 혹시 빠진 내용이 있으면 댓글에 달아주면 감사하겠다.

EOB

토요일, 9월 21, 2013

[B급 프로그래머] 2013년 9월 3주 소식 정리

격주(1, 3주)로 프로그래머들에게 도움이 될만한 소식을 간단하게 정리하는 컬럼을 연재하기로 마음 먹었다. 컬럼 반응이 좋으면 기획/관리자들에게 도움이 될만한 각종 소식도 정리해볼 예정이다.

  • libPhenom: 페이스북에서 사용하는 C 라이브러리로 고성능/고확장성을 위한 이벤트 프레임워크를 제공한다. 요즘 주로 자바나 루비와 같은 프로그래밍 언어를 위한 프레임워크 공개가 유행처럼 되어 있는데, 간만에 C로 나온 버전을 보니 무척 반가웠다. 리눅스와 MacOS를 지원하며, 카운터를 사용한 메모리 관리, 스케줄러, 스트리밍 I/O, 유용한 자료 구조(해시 테이블, 리스트, 큐), JSON 파서 등을 포함한다. 라이선스는 아파치 2.0이다.
  • The MySQL Ecosystem at Scale: 최근 구글이 MySQL을 MariaDB로 이전한다는 소식이 화제가 되었는데, 이와 관련한 발표 자료다. MySQL 에코 시스템을 간략하게 정리하고 있다.
  • PostgreSQL 9.3 released!: PostgreSQL 버전 9.3이 발표되었다는 소식이다. MySQL에 비해 열세였던 복제 기능이 'carrier grade' 수준으로 강화되었다고 하는데, 분석해봐야겠다.
  • Infinitest: 이클립스와 IntellJ를 위한 지속적인 테스팅 플러그인이다. 소스 코드에 변경이 가해지면 자동으로 테스트를 돌려준다(일일이 수동으로 테스트를 수행할 필요가 없다!).
  • TOP GITHUB LANGUAGES FOR 2013(8월말 기준): 2013년도에 github에서 가장 인기 있는 프로그래밍 언어를 조사한 결과인데, #1은 자바스크립트, #2는 루비, #3는 자바, #4는 PHP, #5는 파이썬, #6는 C, #7은 C++, #8은 오브젝티브 C, #9은 C#, #10은 무려 셸이다.
  • AWS Console for iOS/Android Now Supports ELB, RDS: AWS 콘솔 앱이 iOS와 안드로이드 버전으로 출시되었다. 아쉽게도 아이패드(HD)용으로는 출시되지 않았다. 참고로 AWS 명령행 인터페이스도 최근 GA 버전으로 업그레이드 되었다. Announcing AWS Command Line Interface - General Availability를 참고하기 바란다. 아마존에서 정식 버전이 나오기 훨씬 전에 루비로 AWS 콘솔 기능을 개발괴발 구현한 적이 있는데 기회가 되면 API 동작 방식 등을 설명해드리겠다.

그러면 따끈한 소식을 정리해 10월 1주에 찾아뵙도록 하겠다.

EOB

화요일, 9월 17, 2013

[일상다반사] 쑥쑥오름교실과 클래스캐스트

지난번 소개드린 우리 집 네트워크 입문&활용을 집필한 신재훈님께서 이번에 쑥쑥오름교실이라는 교육용 사이트를 만들었다는 기쁜 소식을 접했다. 그래서 여러분들께 간략하게 소개드리려 한다.

쑥쑥오름교실은 초등학교 5/6학년 과학 수업을 위한 온라인 공개 수업 웹 사이트로 클래스캐스트라는 루비온레일즈로 만들어진 오픈소스를 기반으로 구축되어있다. 신재훈님은 현직 초등학교 교사로서 직접 MOOC를 접해 프로그래밍 언어 강의를 성공적으로 수강하고 여기서 배운 루비를 사용해 국내 실정에 맞는 사이트를 개통했다고 소감을 밝히셨는데, 정말 대단하다는 생각이 든다(2013년 상반기 동안 B급 프로그래머는 뭐했지? T_T). 물론 기반 소프트웨어도 중요하지만 컨텐츠가 더욱 중요하기에 뜻있는 분들께서 클래스캐스트를 활용해 다양한 수업 교재를 만들어내면 정말 좋겠다는 생각을 해본다.

지난번 소개드린 The Architecture of Open Source Applications Volume II에서도 PHP로 만든 교육용 소프트웨어인 Moodle을 설명하고 있는데, 이미 한국에서도 한국무들사용자모임이 결성되어 여러 학교에서 시험적으로 온라인 강좌를 도입하는 상황이다. 또한 구글도 MOOC에 관심을 보여 EdX와 제휴한다는 소식도 있다. 구글이 직접 뛰어들어 온라인 교육에 필요한 여러 가지 기술을 지원해주겠다고 하니 바야흐로 온라인 교육이 서서히 주류로 자리잡고 있다는 느낌이 든다.

여전히 오프라인을 기반으로 하는 전통적인 대학교 학위가 중요시되는 대한민국에서 '사이버 대학교'를 넘어 온라인 교육 시스템의 영향력이 과연 얼마나 될지는 갸늠하기 어렵지만 세상이 바뀌고 있다는 사실 하나는 분명하다. 학생숫자가 줄어들고 점점 학교(특히 대학)에서 가르치는 내용이 사회와 괴리될 가능성이 높은 현 시점에서 온라인 교육 시스템의 기반 구조가 튼튼하게 갖춰지고 있다는 현실은 시사하는 바가 크다. 지식 전달 체계가 구술에서 텍스트로 바뀌는 만큼이나 강력한 영향력을 미칠지(아쉽게도 멀티미디어는 텍스트만큼의 영향력을 미치지 못했다. 물론 대한민국에서는 '인강'이라는 아주 특수한 형태로 상업적으로도 대박을 치긴 했지만...), 아니면 찻잔속 태풍으로 끝날지 지켜볼 필요가 있겠다. 인터넷 앞에서 전통적인 어학 사전이나 백과 사전 업체들이 무릎을 꿇었듯이 과연 기존 교육 체계가 백기를 들지 타협을 할지 아니면 계속 살아남을지 무척 궁금해진다.

EOB

토요일, 9월 14, 2013

[독서광] 사라진 실패

한동안 경제/경영 블로그 답지 않게 컴퓨터랑 소설 이야기만 잔뜩 늘어놓았기에 더위 먹은 거 아니냐는 독자 여러분들의 걱정아닌 걱정을 불식하기 위해 오늘은 정말 간만에 '경영' 책 한 권을 소개하려 한다. 오늘 주인공은 트위터에 올라온 책 소개에 '실패'라는 단어가 보이자마자 바로 구매를 해버리고 잽싸게 읽은 '사라진 실패'다.

한국에서 정말로 금기시 되는 단어 중 하나는 '실패'다. 실패도 최종적으로는 성공으로 이어지는 스토리텔링 기법을 발휘하지 않는 이상 책이고 강연이고 나발이고 절대 언급되면 안 될 강력한 금칙어다. 누구나 '실패를 묻어버리는 바람에 '성공담'이 판을 치며 모두 성공으로 가는 열차에 한 자리를 차지하고 싶어 야단법썩이다. 얄팍한 자기타인 계발서도 알고보면 '개인의 성공'을 담보하는 티켓으로 포장된다. 하지만 성공한 기업과 사람의 특징을 그대로 분석해 자신에게 적용해봐야 성공할 가능성은 지극히 낮다. 차라리 실패한 기업과 사람의 경험을 곱씹고 이를 회피하는 편이 성공할 가능성을 높여준다는 생각까지 들곤 한다.

이 책을 손에 쥐지마자 가장 먼저 한 작업은 바로 '삼성'과 'LG'의 스마트폰 시나리오의 분석이었다. 이유는 간단하다. 내가 잘 아는 분야니까. 그런데 놀랍게도 다소 무미건조하다고 느껴질만큼 중립적인 어조에 숨어있는 분석 능력이 무릎을 탁 치게 만들었다. 이거 정말 대단한 물건인데? 계속해서 르노삼성, 한화, 웅진, 오리온, 농심, 신한금융지주, 현대그룹, 금호아시아나, NHN(!), 신세계, 하이트 순으로 각 기업들이 실패(?)한 이유를 쉬지 않고 읽어내려갔다. 물론 이 책에서 다루는 일부 기업이 실패했다고 인정하지 않는 분들도 많겠지만(신한금융지주, NHN, 삼성이 실패했다고 말하면 술자리에서 왕따 당하기 딱 쉽다. 이게 현실이다. T_T), '실패'가 무엇을 의미하느냐에 따라 사실상 실패했다고 볼 수도 있다는 생각이 들었다.

경제/경영에 나름 관심이 많아 언론에서 실패한 기업들의 분석 기사가 나올 때마다 눈여겨 봤지만, 이 책에 제시하는 내용만큼 '실패'라는 큰 맥락을 깔고 종합적으로 실패(?)한 원인과 추이를 꼼꼼한 사례를 들어 분석하는 탐사 보도는 본 적이 없다고 감히 단언할 수 있다(만일 대한민국 기업의 '실패'를 탐사하는 좋은 기사가 있다면 혼자 보지 마시고 다 같이 공유합시다). 이 책은 "대한민국을 먹여살리고 국위를 선양하는 대기업 만만세"(오른쪽)나 "재벌은 사회악이다"(왼쪽)라는 주제가 아닌 기업 경영 전략에 초점을 맞추기 때문에 살아있는 경영과 경제 교과서('교과서'라니까 최근 여기저기 인터넷에서 자료를 짜집기하다 딱 걸린 모 출판사 책이 생각났다... T_T)라 불러도 무방할 듯이 보인다.

결론: 2013년도 경제/경영 분야 #1 도서로 강력하게 추천한다. 꼼꼼하고 디테일한 스토리텔링에 그야말로 화들짝 놀랄 것이다.

뱀다리: 그러고보니 예전에 번역한 초난감 기업의 조건 : IBM에서 마이크로소프트와 구글까지, 초우량 기업을 망친 최악의 마케팅이 불현듯 생각났다. 만일 '사라진 실패'가 재미있다면 IT 분야에서 초특급 삽질을 디테일하며 웃프게(?) 분석하는 '초난감 기업의 조건'도 한번 읽어보시기 바란다.

화요일, 9월 10, 2013

[독서광] 블레이베르크 프로젝트

최근에 블로그에 어려운 이야기와 전문서만 소개하다보니 이를 안타깝게(응?) 여긴 느낌이 있는 책 편집장님께서 소설을 한 권 보내주셨다. 덕분에 머리 아픈 일상에서 잠시 벗어나 출퇴근 시간을 즐길 수 있었기에(책에 빠져 출근길 지하철 역 지나친 이야기는 너무 식상해 다시 소개하지 않겠다. T_T). 감사하다는 말씀을 전해드린다. 오늘 소개드릴 책은 블레이베르크 프로젝트라는 스릴러 소설이다.

이 책은 스파이/첩보 요원이 등장하는 전형적인 헐리우드식 전개 방식을 따르고 있다. 마치 영화 시나리오를 염두에 둔 듯 각 장면은 짧지만 매끄럽게 이어지고, 결론을 향해 조금씩 독자들에게 힌트(아니면 떡밥)을 뿌리며 현재와 과거 회상이 교차되며 다양한 인물들이 정교하게 연결된다. 그리고 그 와중에 치명적인 사고를 저질러 자포자기 상태인 우리의 주인공이 풍전등화와 같은 상태에서 정신을 차리고, 주인공과 함께 사건 해결에 나선 첩보 요원들은 보이지 않은 암흑 세력의 핵심에 한걸음씩 다가선다. 군더더기 없이(이 책에 사족이란 없다) 사건이 초고속(!)으로 전개되는 특성으로 인해 일단 책을 손에 쥐면 뒷 이야기가 궁금해 놓기가 어려울 것이다.

줄거리는 일부러 생략했으며(조금이라도 소개하려 생각했지만... 바로 스포일러로 돌변할 가능성이 너무 높아 지웠다. T_T), 뒷 이야기를 해보자면... 책이 조금 친절해서(응?) B급 프로그래머는 중반 이전까지 나오는 단서를 토대로 미리 뒷 이야기를 어느 정도 추론할 수 있었다. 물론 그렇다고 해도 정말 추론이 맞는지 확인하는 재미가 나름 쏠쏠하니 나쁘지는 않았다. (솔직히 요즘 이리저리 너무 꼬아놓고 어깨 힘주는 책과 영화가 많아서...) 일반 독자층을 배려한 저자의 의도라고 보여진다. 또한 적들을 고민하지 않고 아주 쉽게 죽이므로 너무 손쉽게 일을 풀어가는 것이 아니냐는 생각이 들긴 했지만(우리를 쫓는 하수인들은 아무 정보도 모르니 살려서 족쳐봐야 도움이 안 된다는... 변명이 나오긴 한다.), 복잡한 두뇌 싸움의 대명사인 '형사 콜롬보'의 전개 방식을 따를 생각이 없는 책이므로 용서해주기로 했다. ㅋㅋ

결론: 빠른 전개에 약간의 머리 싸움에 적절한 긴장감을 맛보며 잠시 세상만사 잊어버리고 싶은 독자들에게 가벼운 마음으로 이 책을 추천한다. 단, 인생의 비밀이나 교훈, 엄청난 감동을 얻으려는 심각한 독자에게는 추천하지 않는다.

EOB

토요일, 9월 07, 2013

[독서광] Database Programming with JDBC & Java, 2nd Edition

지난번에 [독서광] 마이바티스 프로그래밍을 소개하면서 엄청난 중복/반복 코딩으로 악명 높은 JDBC를 언급했었다. 요즘 나온 강력한 라이브러리와 프레임워크이 있는 상황에서 구닥다리 JDBC를 알아야 할 필요가 있을까? 정답은 '그렇다'. 1) 메모리 크기와 성능 문제로 인해 직접 JDBC를 사용해야 하는 경우, 2) 저수준 접근(예: 데이터베이스의 카탈로그 정보 입수)이 필요한 경우, 3) 직접 라이브러리와 프레임워크를 제작하는 경우가 대표적인 JDBC 용례로 볼 수 있겠다. 그렇다면 JDBC는 어디서부터 출발하면 좋을까? 오라클에서 제공하는 JDBC 튜토리얼부터 시작해 Getting Started with the JDBC API로 넘어가면 되지만 활자화된 책에 비해 아쉬운 점이 많다. 이럴 때 바로 오늘 소개하는 책인 Database Programming with JDBC & Java, 2nd Edition를 읽으면 된다.

이 책은 크게 세 부분으로 나뉘어진다. 첫째 부분은 JDBC 기초와 프로그래밍 방법, 둘째 부분은 JDBC를 활용한 데이터베이스 아키텍처 수립과 응용 방안, 셋째 부분은 JDBC 레퍼런스다. 대부분 개발자들은 첫째 부분을 읽고 셋째 부분은 책 대신 온라인에서 Java™ JDBC API를 찾아보면 될 것 같다. 역사적으로 어떻게 JDBC를 사용해 아키텍처를 잡고 프로그램을 작성했는지 궁금한 독자라면 둘째 부분을 선택적으로 읽으면 된다.

하지만 이 책이 나온지 조금 오래된 관계로 인해 본문에 나오는 프로그래밍 예제와 아키텍처 전개 방식이 상당히 구식(old-fashioned)으로 느껴질지도 모르겠다. 따라서, 이 책에 나온 스타일과 방식이 현대적인 개발 관례와 잦은 충돌을 일으킨다는 사실을 인지하고 읽어야 한다. 특히 코드 작성 기법(변수 작명, 프로그램 구조, 주석다는 방식, API 설계 방식 등등) 관점에서 이 책을 그대로 따르면 안 된다는 사실을 다시 한번 강조하고 넘어간다. 어떻게 보면 그 만큼 자바 프로그래밍 기법과 기술이 많이 발전했다는 사실을 반증한다는 생각이다. 그리고 옛날 JDK를 사용하므로 최신 JDK 5 이상을 사용할 경우 여러 가지 면에서 이익을 얻을 수 있다는 사실도 기억하자(참고로 이 책은 JDK 1.2를 기준으로 한다). 다행스럽게도 JDBC 자체는 획기적인 변화가 없었으므로 이 책을 읽고 나서 위에 소개한 JDBC API 문서를 읽으면 어렵지 않게 보충이 가능하다.

마지막으로 주의 사항 하나만 더 소개하겠다. 이 책은 데이터베이스로 오라클을 기준으로 설명하고 있으므로, MySQL을 사용할 경우 MySQL Connector/J Developer's Guide를 읽어 MySQL과 관련된 내용을 숙지할 필요가 있다. 특히 MySQL 드라이버 로드, MySQL과 연결 방법, MySQL과 자바 데이터 타입 연관 내용은 제대로 숙지하고 있어야 뒷탈이 없을 것이다.

결론: JDBC에 대한 기초 서적으로 가볍게 읽어보면 좋을 것 같다.

EOB