화요일, 7월 30, 2013

[B급 프로그래머] "‘한국의 저커버그’가 양성되기 위한 조건"에 대한 불만

C|net Korea에 올라온 ‘한국의 저커버그’가 양성되기 위한 조건을 읽다보니 글쓴이는 소프트웨어 개발자를 은근슬쩍 이류 시민으로 디스하는 듯하다. 뭐 다른 내용은 그렇다치더라도 다음 내용은 전산학과 컴퓨터 공학에 대한 한국 사회의 인식을 대변한다고 볼 수 있겠다.

3. 커뮤니케이션 능력
일반 코더에게는 그렇게 높은 수준이 커뮤니케이션 능력이 요구되지 않지만 뛰어난 아키텍트가 되려면 상당히 중요한 능력이다. 대화능력, 듣기능력, 토론기술, 대인기술, 설득능력, 인내력 등이 필요하다. 이런 능력은 암기식 교육환경에서는 키워지기 어렵다. 어렸을 때부터 토론식 교육 환경이 필요하며 능력을 키우기 위해서 시간이 매우 오래 걸린다.

4. 문서 작성 능력
가독성이 뛰어난 문서를 작성하는 기술이다. 일반적인 쓰기 능력, 정보 조직화 기술 등이 필요하며 일반 코더들이 가장 부족한 능력 중 하나이다. 십 수년의 학교 교육을 통해서 기초를 다져야 하며 실전 개발을 통해서도 오랫동안 단련해야 향상되는 능력이다.

5. 컴퓨터, 소프트웨어 지식
소프트웨어 동작원리, 자료구조, 알고리즘, 개발언어 등 개발의 기초 지식이다. 대학의 소프트웨어 관련학과에서 주로 가르치는 것이고 단시간에 기초를 닦을 수 있고 독학도 가능하며 실전 개발을 통해서 꾸준히 습득하는 지식이다. 단기적이고 집중적인 학습이 가능하다.

6. 코딩 능력
누구나 아는 코딩 파워다. 일반 코더의 능력을 구분하는 기준이며 그 능력차이는 코더마다 천지차이다. 단기적인 교육이 가능하다. 우리나라 프로그래머들이 별로 떨어지지(지 않는) 능력이다.

7. 소프트웨어 공학 경험
소프트웨어를 빠르게 개발하기 위한 공학적인 지식과 경험이다. 소프트웨어 분석, 설계, 소스코드관리, 이슈관리, 테스트, 프로세스, 툴, 개발문화 등 광범위한 영역의 경험이 필요하다. 학교에서는 배우기가 거의 불가능하며 제대로 된 개발환경에서 실전 개발을 통해 배워야 하며 매우 오랜 시간이 걸린다.

위 내용에 따르면 커뮤니케이션 능력, 문서 작성 능력, 소프트웨어 공학 경험은 배우는 데 오랜 시간이 걸리고, 컴퓨터/소프트웨어 지식, 코딩 능력은 단기간에 학습이 가능하다고 했는데, 본인 생각 말고 객관적인 증거를 제시하면 어떨까 싶다. 3개월만 학습하면 아키텍처/운영체제/알고리즘 전문가가 되고 다시 3개월만 더 학습하면 C/Java 프로그램을 발로도 짤 수 있다면, 4년 동안 대학교에 다니며 학기말마다 밤새가며 프로젝트 끝낸다고 고생한 사람들은 도대체 어떻게 된거지? 열심히 일하는 프로그래머를 코더로 격하한 다음 부족한 능력을 '커뮤니케이션, 문서, 소프트웨어 공학 경험'으로 싸잡아 매도한다고 해서 과연 근본적인 문제가 해결될까? "넌(개발자) 불치병(커뮤니케이션, 문서 작성, 소프트웨어 공학 능력 부재)에 걸렸으니 이제 큰 일 났네?"라고 약올리는 경우랑 뭐가 다르지? 제발 바라건데, 메타 개발만 하지 말고 직접 훌륭한 소프트웨어 공학 도구를 개발해 오픈소스로 공개하거나 필요한 지식을 공유할 수 있게 알맹이 있는 책을 출간해 제발 불쌍한 우리 코더들 좀 구원해주시기 바란다.

다시 한번 러멜트 교수의 말을 인용하겠다. 실제 손에 쥘 수 있는 결과물을 만드는 개발자의 능력을 과소평가하지 마라. 그리고 코딩이 우습게 보일지도 모르겠는데 제대로 동작하는 깨끗한 코드를 작성하려면 엄청난 연습과 노력이 필요하다는 사실을 기억하라.

"당신이 멋진 자동차를 설계할 능력이 있다면, 내게서 전략을 배우는 데 며칠이면 충분하다. 하지만 아무리 전략으로 박사 논문을 쓴 사람이라도 자동차를 설계하려면 몇 년을 공부해도 어림 없을 것이다." - 리처드 러멜트(UCLA 전략학 교수)
EOB

토요일, 7월 27, 2013

[독서광] The Clean Coder

3년 전에 클린 코드: 애자일 소프트웨어 장인 정신이라는 아주 놀라운 책을 번역해서 선을 보였으나... 흥행에 참패한 기억이 아직도 새롭다. 오늘은 클린 코드 저자인 로버트 C. 마틴 큰 형님께서 자신을 재물로 삼아 후배들에게 큰 가르침을 주려 집필한 'The Clean Coder'를 소개해 올리겠다. 현재 한국어 판이 번역 중이라는 소식이 있는데, 더 이상 기다리지 못하고 그냥 영어로 읽어버렸다.

책 제목만 놓고 보면 클린 코드의 후속작처럼 보이는 이 책은 깨끗한 코드를 작성하는 _사람_에 초점을 맞춘다. 솔직히 클린 코드를 읽으며 "뭐 이렇게 독단적이고 자기 중심적인 똥고집이 있나!"라고 버럭했을 독자분들도 있을텐데, 여기에 대한 이유가 바로 'The Clean Coder'에 잘 설명되어 있다. 클린 코드를 집필한 다음 제작 과정과 배경 사상을 설명하는 감독판 보충 책으로 보면 틀림없다. '클린 코드'와는 달리 코드가 전혀 나오지 않기에 프로그래밍 관련 서적으로 착각하고 구입하면 바로 멘붕이 온다는 사실도 미리 알면 좋겠다.

아주 특이하게, 이 책은 목차에 'Pre-Requisite Introduction'라는 제목이 붙은 장이 존재한다. 로버트 C. 마틴 큰 형님이 지금까지 산전수전 공중전에 잠수함전까지 겪은 과정에서 망가진 경험을 초반부터 그야말로 격하게 풀어쓰기 때문에 마음이 여리신 분이라면 읽다가 덮어버릴지도 모르겠다. 하지만 이 부분은 뒤에 나오는 내용의 맥락을 제공하기 때문에 절대로 건너뛰어서는 안 된다. 일단 이렇게 철저하게 망가진 다음에 여기서 얻은 교훈을 소프트웨어 프로페셔널 관점에서 하나씩 풀어쓴 내용이 바로 본문이 된다. 서문에도 나오지만 이 책은 크게 다음과 같은 내용을 다루고 있다.

  • 소프트웨어 프로페셔널이란?
  • 프로페셔널은 어떻게 행동해야 할까?
  • 프로페셔널은 충돌, 빠듯한 일정, 비이성적인 관리자를 어떻게 다룰까?
  • 언제, 어떻게 프로페셔널은 '아니오'라고 단호하게 거절해야 하나?
  • 프로페셔널은 압력을 어떻게 다룰까?

그렇다. 이 책은 그냥 단순 샐러리맨이 아니라 자기 소신이 뚜렸하고 전문 지식을 갖춘 프로페셔널 소프트웨어 개발자의 행동강령을 정의한 책이다. 상사의 압력이나 주변의 동료 압력에 굴하지 않고 '아니오'라고 말할 때와 '예'라고 말할 때를 구분하고, 깔끔한 솜씨로 설계하고 코드를 작성하고, 업무가 아닌 자기 계발 관점에서 별도 시간을 확보해 기량을 갈고 닦고, 확실한 일 마무리 시점을 정하기 위한 수락 테스트를 진행하고, 습관처럼 테스트 주도 개발을 진행하고, 시간을 잘 관리하고, 예측을 확률로 다루고, 압력을 이겨내며, 동료 사이에 짝 프로그래밍 등 협업을 장려하면서도 자기 맡은 몫은 멋지게 해내는 '프로페셔널' 개발자가 될 수 있도록 마틴 횽아는 실용적인 조언을 아끼지 않는다.

안타깝게도 한국에서는 이 책이 흥행하기 어려워 보인다. 아파야 청춘이 된다는 둥 개인의 희생을 미화하고 약을 파는 힐링 서적이 판치는 상황에서 상사에게 감히 '아니오'라는 말을 누가 함부로 할 수 있을까? 특히 개발자의 프로페서녈한 특성을 인정해주지 않는 사회에서 이 책은 금서(자세한 이유는 직접 읽어보면 알게 된다)가 될 가능성이 아주 높다는 생각에 고개를 들어 하늘을 보니 먹구름이 가득하다. T_T 그럼에도 불구하고, 프로페셔널을 향한 집념으로 불타오르는 개발자라면 이 책에서 다양한 교훈을 얻을 것이다. 특히 개발자로서 어떻게 올바르게 살지 고민하는 분들께 강력 추천한다.

뱀다리: 본문 중 마틴 횽아가 기운이 빠지고 힘이 없을 때 짝 프로그래밍을 하면 힘이 샘솟는다는 재미있는 이야기가 나온다. 심지어 협업 장에서는 "Programming is all about working with people."이라는 결론을 내리기까지 한다. 이성 친구가 없어 혼자 '퍼시픽 림'을 본 개발자들이라도 컴퓨터 세상에서는 동료 프로그래머와 드리프트 신공을 펼쳐 짝 프로그래밍으로 4등급 하이젠버그를 때려 잡을 수 있으니(응?) 모두 기운냅시다! (T_T)

따끈한 새소식: 기존 출판사에서 절판 예정인 '클린 코드'를 인사이트 출판사에서 복간하기로 결정이 났다. 'The Clean Coder'를 읽고 나서 어떻게(how)가 궁금한 분들께서 편한 마음으로 읽어보실 수 있게, 현재 전반적인 검토 작업을 진행하는 중이다. 많은 성원 부탁드리겠다!

EOB

화요일, 7월 23, 2013

[독서광] 게임 독립 만세

원래 책을 다 읽기 전에는 서평을 올리지 않지만 아주 흥미로워보이는 책이 나와서 간략하게라도 소개하지 않을 수 없다. 오늘 주인공은 게임 독립 만세라는 제목이 붙은 '인디 게임 개발자 삽질 방지서'라는 부제가 붙으면 더욱 좋았을 책이다(실제 부제는 '그 전에 알아둬야 할 아주 많은 것들'이다).

맛보기로 3장까지 포함된 샘플을 내려받을 수 있는데, 큰 기대를 하지 않고 내려받아 읽어본 결과 3장까지만 봐도 아주 좋은 내용이 많이 나오므로 인디 게임 개발자가 되고 싶은 분들은 3만원을 투자해 삽질을 줄이면 정말 좋겠다는 생각이 들었다. 전자책은 DRM-free로 제공되므로 '(게임 세상과 마찬가지로) 불법 복제라는 강력한 적'으로 인해 살짝 걱정이 되긴 하지만 독립 출판이라는 측면과 더불어 새로운 지식 공유 채널을 정립한다는 시도 자체를 높이 평가할만하다.

저자의 주의 사항인 '내용의 신빙성은 거의 정확하지만, 그 방향성에 대해 편항적이거나 과격하다고 여기실 수 있습니다.'라는 문구는 이 책의 성격을 가장 잘 드러낸다고 볼 수 있다. 샘플을 읽어보니 바로 이런 주의 사항 때문에 책이 오히려 더 살아 있다는 느낌이 들었으니까 말이다. 피랴나가 득실거리는 현실에서 고리타분하게 추상적인 이야기나 말도 안 되는 이론 전개보다는 차라리 그냥 진흙탕을 그대로 보여주는 방식이 훨씬 더 가슴에 와닿기 때문이리라. 시작부터 '자영업은 항상 망한다'라는 주제를 다루니 뭐 이어지는 내용이 얼마나 현실을 잘 반영했는지는 굳이 여기서 중언부언할 필요가 없겠다. 그렇다고 암울한 현실만 나열하지는 않는다. 궁극의 해결책인 '뜨면 다 해결된다'를 읽으며 한참 웃었다. 하지만 "유명해지려면 유명하면 된다"는 유명한 교훈을 떠올리게 만드는 제목과는 달리 '뜨기 위해 장기간 퇴적물이 필요하다'는 정확한 지적에 뜨끔하긴 했지만 말이다.

인디 게임 개발자가 되고 싶은가? 그렇다면 아무런 장비 없이 정글에 바로 뛰어들지 말고 일단 이 책에서도 소개한 '자영업자 2명 중 1명 3년 내 망한다' 표를 100번 되새겨보고 오늘 소개한 이 책을 비롯해 지난번 소개드린 여러 좋은 책(예: 위대한 게임의 탄생)을 읽으며 철저한 준비와 함께 마음가짐을 다잡은 다음에 한 번 더 생각해보고 시작하기 바란다.

개인적인 바람 한 가지: 여러 가지 의미에서 이 책이 대박까지는 아니더라도 중박이 났으면 좋겠다.

EOB

토요일, 7월 20, 2013

[일상다반사] 3333 이벤트 당첨자 발표

기대하시고 고대하시던 3333 이벤트 당첨자를 발표해드리겠다. 아날로그 제비뽑기 방식으로 진행했으므로, 컴퓨터를 사용한 부정이 개입되었을리는 만무하고... 여튼 블로그 주인장을 믿어주시라!

응모하신 분은 총 24분이며, 그 중에서 영광의 당첨자 명단은 다음과 같다.

  • yon*msh@gm*.com님
  • book*kr@gm*.com님
  • chan*@gm*.com님
  • *aru@gm*.com님
  • jun*jin@gm*.com님

그리고 특별 격려상(블로그 주인장에 대한 _격려_ 내용이 우수해서 특별히 드리는 상)을 하나 만들어 보았다(이벤트 공지에 그런 이야기 전혀 없었다구? 주인장 마음이다. :P) 당첨자는 maf*@na*.com 님이며, 본문 내용 잠시 소개해드리겠다. 격려 말씀에 기운차려 더욱 열심히 블로그를 운영하리라 다짐한다.

책을 좋아하는 프로그래머.. 스스로를 'B급'이라 과감히 말할 수 있는 용기 & 당당함... 그런면이 좋아서 평소에 RSS를 통해 좋은 글을 접하고 있습니다. 이 자리를 빌어 감사의 말씀을 드립니다.

책 배송은 늦어도 7월 24일까지는 완료할 계획이므로 조금만 참고 기다려주시라.

이벤트 참가하신 모든 분들께 감사 말씀드리며, 앞으로도 계속해서 블로그 응원을 부탁드리겠다.

EOB

[독서광] Make Vol 6

Make Vol 6권이 나왔는데, 이런저런 정신 없는 상황으로 인해 깜빡 잊어먹고 있었다. T_T Vol 6은 '장난감과 게임'이라는 특별 주제를 중심으로 여러 가지 흥미로운 물건/실험을 소개하고 있다. 그 중에서 유달리 눈에 띈 제목은 바로 '딱딱 증기선'! 딱딱거리며 가는 증기선의 원리와 조립 방법을 보고 있으려니 어릴 때 촛불로 가는 보트를 보고 엄청나게 신기했던 기억에 새록새록 나기 시작했다. 그래서... 국내 토종 메이커들도 혹시 취미삼아 증기선을 만들어보지 않았을까 구글로 검색한 결과 대박 사이트를 하나 찾았기에 여기에 공유하지 않을 수 없다. ㅎㅎㅎ

(1)번부터 (3)번까지 읽어보시면 알겠지만, 셀토님의 엄청난 필력과 꼼꼼한 디테일에 화들짝 놀라고 말았다. Make 애독자 여러분들도 꼭 한번 읽어보시기 바란다.

다음으로 흥미로웠던 내용은 지난번 블로그에서도 소개한 [독서광] 마우스드라이버 크로니클을 연상하게 만드는 내용을 담은 '좋아하는 일로 먹고살기' 기사였다. 꺼저라 TV 범용 리모컨이라는 물건을 구상해서 제조하고 판매까지 한 경험을 딱 여섯 페이지로 압축했는데, 너무 재미있어서 여러 번 읽었다. 역시 구글로 관련 내용을 검색해보니 아예 DIY 킷 디자인 설명까지 있었다. 이 물건 들고 여기저기 돌아다니며 온갖 TV를 다 끄며 장난치는 상상을 해보니 잠시 즐거웠다(물론 잽싸게 도망치도록 평상시 달리기 연습을 해야겠지만...). 이 프로젝트를 기획한 미치 알트만의 말을 잠시 인용해본다.

좋아하는 일을 한다고 해서 반드시 돈을 벌 수 있는 것도, 그걸로 먹고 살 수 있는 것도 아닙니다. 하지만 좋아하는 일을 하지 않으면 아이디어는 꿈으로 남아 있을 수 밖에 없고, 그 꿈은 서서히 사라질지도 모릅니다.

이번 호를 보고 있으려니 어릴 때 과학 잡지 부록으로 딸려오던 여러 가지 재미있는 실험 키트(바람개비로 가는 자동차부터 비닐주머니에 담긴 물을 뿌리던 스프링쿨러까지...)가 불현듯 생각났다. 그런 의미에서 올 하반기(정확하게 말하자면 8월 1일)에 출시될 강력한 뽐뿌 장난감인 레고 마인드스톰 EV3를 하나 지를까 싶다. 임베디드 개발 보드보다 훨씬 재미있을 듯... :P

EOB

화요일, 7월 16, 2013

[일상다반사] RSS 구독자 3333명 돌파 기념 이벤트

'컴퓨터 vs 책' 애독자 여러분들께서 꾸준히 RSS 구독을 해주신 덕분에 (RSS 특성상 정확한 통계는 파악하기 어렵지만) 어느 순간 구독자 수가 3333명이 넘어섰다. 올해부터 정신차리고 주 2회(현재는 화-토) 재미있고 흥미로운 소식을 전하려 노력하고 있으며, 다양한 소재 발굴에도 신경을 쓸 계획이다. 한동안 여러 가지 사정으로 인해 이벤트를 전혀 열지 못했는데, 오늘 기습적(?)으로 이벤트를 기획해봤다. 선물은 지난번 [일상다반사] MongoDB NoSQL로 구축하는 PHP 웹 애플리케이션 번역서 출간이라는 글에서 소개드렸던 MongoDB NoSQL 번역서다. 이 책 성격은 어느 독자분이 올려주신 서평을 보면 확실하게 알 수 있을 것이고, 특히 PHP와 MongoDB에 관심이 많은 분에게 적합하다.

독자 여러분을 위해 총 다섯 권을 준비했고, 응모 방법과 공지 사항을 간략하게 정리한다.

  1. 응모 기한: 7월 18일(목) 23시 50분까지다.
  2. 이벤트 응모 대상: RSS로 구독한 블로그 애독자(라고 썼지만... RSS 구독 여부는 확인할 방법이 없다. ㅋㅋ)
  3. 이벤트 당첨 방식: 이번에는 아날로그 식으로 제비를 뽑아볼 생각이다.
  4. 우편물 배송 방식: 이번에도 역시 기존과 마찬가지로 일반 우편 발송을 따른다. 등기나 택배를 이용할 경우 너무 많은 비용이 들어가기 때문이다.
  5. 신청 방식: jrogue@쥐메일(gmail이라는 사실을 다들 아실거다).com로 편지를 보내주시라. 전자편지 작성 방식: 전자편지 제목은 '[3333] 이벤트 신청'으로 적어주시면 감사하겠다. 본문 내용에는 신청인 이름, 주소, 우편번호(!)를 적으면 된다.
  6. 당첨자 발표: 7월 20일(토) 오전에 간단하게 블로그 글로 결과를 올려드리겠다. 스팸 편지로부터 보호하기 위해 email 앞부분 일부 주소만 공지할 생각이다.

일일이 답장이나 댓글을 드리지 못하더라도 애독자 여러분들의 열렬한 성원(댓글, 트위터 멘션, 기타 등등)은 맘 속으로 늘 고맙게 생각하고 있다. RSS 구독자가 5000명이 넘으면(이런 날이 오기는 올까?) 화끈한 오프라인 이벤트를 선보일 예정이므로 기대하시기 바란다. :)

EOB

토요일, 7월 13, 2013

[독서광] 관찰의 힘

거의 한 달 동안 경제/경영 블로그(?)답지 않게 컴퓨터 관련 내용만 올리고 있었다. 반성하면서 오늘은 '평범한 일상 속에서 미래를 보다'라는 부제가 붙은 '관찰의 힘'을 여러분들께 소개해드리겠다. 이 책은 근래 읽은 책 중에서 표지 날개가 가장 눈길을 끄는 내용으로 꾸며져 있었다. 잠깐 살펴볼까?

  • 세계인의 가방에 공통으로 들어있는 세가지 물건은?
  • 배가 한껏 부른데도 왜 더 먹게 될까?
  • 공원에 있는 '잔디에 들어가지 마시오' 표지판을 누구를 위한 것일까?
  • 태국의 십대 소녀들이 가짜 명품백보다 가짜 치아교정기를 사는 이유는?
  • 인터넷 검색이 기억력을 쇠퇴시킬까? 그렇다면 앞으로 무엇을 기억하게 될까?
  • 누군가 연락처를 묻는다면 어떤 정보를 주겠는가? 이메일 주소? 휴대전화 번호? 페이스북 주소?
  • 안면 인식 기능의 발달로 익명성이 완전히 사라진다면, 세상은 더 좋아질까? 나빠질까?
  • 스마트폰을 택시에 두고 내렸는데 위치 수신이 된다면 그것을 잃어버렸다고 할 수 있을까?
  • 물건의 소유와 공유 중 어느 쪽이 더 편리할까?
  • 낯선 사람이 천 원만 빌려달라고 한다면, 줄 것인가 말 것인가?
  • 중국에서 글로벌 대기업 이베이가 내수 업체 타오바오에게 완패한 이유는?
  • 고속도로 휴게소의 본질은 주유일까 휴게일까?
  • 휴대 전화의 기능 중 딱 한가지만 선택할 수 있다면?

BUT... 표지 날개 내용만 보면 정말 끝내줄지 몰라도 본문에 나오는 정답은 뻔하다(최소한 '컴퓨터 vs 책' 블로그의 애독자분들 수준이면 본문에서 아주 색다르고 신기한 내용이 펼쳐지지 않으리라 믿는다). 아쉽게도 이 책은 저자가 속한 프로그 디자인에서 업무를 수행하는 동안 얻은 경험과 뒷이야기를 정리한 수준에서 흐지부지 막을 내려버린다. 다양한 방식으로 세상이 돌아가는 방식을 파악하는 방법을 일본, 한국, 중국을 포함한 여러 아시아 국가와 개발도상국을 돌아보며 일반 관광객이 느끼지 못한 여러 경험담을 곁들여 재미있게 풀어쓰려 노력했지만, 거기서 얻은 경험을 어떻게 제품에 연결시킬지에 대한 고리는 (최소한 이 블로그 주인장에게는) 보이지 않았다. 따라서, 부제에서 강조한 '일상에서 미래를 찾는 방법'이라는 상투적인 선전 문구 따위는 잊어먹고 눈 높이를 한 단계 낮춰 (조금 색다른) '디자인 연구에 대한 방법'을 본문에서 기대하는 편이 정신 건강에 이롭다는 생각이다.

결론: 디자인 연구 방법을 찾는 분들에게는 살짝 추천, 이 책으로 뭔가 세상에서 통찰을 얻어 현재 만들고 있는 제품/상품/서비스에 직접 적용하려 마음먹은 분들께는 강력하게 비추천.

뱀다리: 국내에서 이 책이 인기를 끄는 이유는 '여행서'(응?) 형태를 따르기 때문일 듯이 보이는데... (여기서 경고 하나!) 멋지게 보인다고 해서 이 책에서 나오는 일련의 엉뚱한 행동을 그대로 따라하다가는 진짜 큰 코 다친다.

EOB

화요일, 7월 09, 2013

[일상다반사] 생산성의 비밀

A Harvard Economist's Surprisingly Simple Productivity Secret이라는 글을 읽으면서 전문직 종사자들이 '시간 없어요'라고 불평을 터트리는 이유에 대해 다시 한번 생각하게 되었다. 간단하게 기사 내용을 정리해보겠다.

전문가 세상에서 가장 흔한 불평은 바로 '너무 시간이 없어요'다.

주당 60시간 이상 일하는 근로자들은 창의적인 방법으로 큰 프로젝트를 해결한 생각은 고사하고.심지어 받은 편지함을 정리할 시간조차 없다고 투덜거린다.

하지만 시간이 문제가 아니라고 하버드 경제학자인 센드힐 물라이나단은 말한다. 성공을 막는 궁극적인 장애물은 정싱적인 '대역폭' 부족이다. 과업에 순간적으로 집중하는 능력 말이다.

물라이나단의 연구는 결핍과 사람들이 뭔가(예: 돈, 음식, 시간) 부족할 때 어떻게 반응하는지에 초점을 맞춘다.

결핍은 사람들로 하여금 잘못된 결정을 이끈다는 사실을 발견했다. 두뇌가 결핍에 대해 너무 많이 고민하기 때문이다.

결핍이라는 문제는 소득 수준을 가로질러 퍼져 나간다. 마치 소득이 적은 사람들이 약탈적인 부채 관리에 실패하듯, 바쁜 전문가들은 시간을 효율적으로 관리하는 데 실패한다. 사람들은 집중하지 못한다.

실제 예를 들어보자. 목이 마르다면 간절히 물을 원하게 된다. 다른 것에는 신경쓸 여력이 없다. 돈이 부족하면 재정 문제가 사고를 지배한다.

전문가 세상 역시 마찬가지다. 시간 부족이 문제가 아니라 집중력 부족이 문제다.

초과 근무를 하는 사람들은 "열심히 일할 능력뿐만 아니라 문제에 대해 심각하게 생각할 능력"이 부족하다.

전문가를 위한 교훈은 다음과 같다. 황금같은 시간이 부족하다는 사실은 문제가 되지 않는다. 어떻게 양질의 시간을 보내느냐가 문제다.

시간이 없다고? 그렇다면 시간을 최대로 활용하게 머리를 써야 하는데, 그럴 시간도 없다는 사실이 함정이네? T_T 자 그렇다면 개발자 여러분들은 이런 모순을 해결하기 위해 어떤 전략을 사용하고 계신지? 좋은 해법이 있으면 다 함께 나눠봅시다.

EOB

토요일, 7월 06, 2013

[독서광] 미래를 바꾼 아홉 가지 알고리즘

집에 있는 책꽂이를 보면 수학, 물리, 생명공학, 화학 등 여러 분야에 걸친 대중서가 보인다. 그런데 흥미롭게도 컴퓨터 관련 대중서는 손에 꼽을 정도다. 일부러 대중서를 구입하지 않았는지 아니면 대중서가 없어서 구입하지 못했는지는 모르겠지만, 온라인 서점에서 찾아보기 힘든 것도 사실이다. 오늘은 에이콘 출판사에서 일반인을 위한 컴퓨터 대중 서적을 표방한 '미래를 바꾼 아홉 가지 알고리즘'이라는 책을 소개하겠다.

이 책의 부제인 '컴퓨터 세상을 만든 기발한 아이디어들'은 이 책의 성격을 아주 잘 나타내고 있다. 저자는 컴퓨터 과학의 기발한 아이디어를 표현하는 알고리즘 중에서 1. 일반 컴퓨터 사용자가 날마다 사용하며 2. 구체적이고 실질적인 문제를 다뤄야 하며 3. 컴퓨터 하드웨어나 인프라가 아닌 컴퓨터 과학 이론에 초점을 맞추는 세 가지 특성이 있는 알고리즘을 뽑아내어 소개한다. 하지만 여느 알고리즘이나 자료 구조 책과는 달리 코드는 없으며 적절한 비유와 알기 쉬운 사례로 트릭(다른 방식으로는 어렵거나 불가능했을 목표를 달성하는 기발한 기법)을 설명하고 있다. 이 책에서 소개하는 알고리즘과 간단한 설명은 다음과 같다.

  • 검색 엔진 인덱싱: 검색 엔진이 빠르게 특정 단어나 문구를 받아 원하는 결과를 제공하는 방법이 무엇일까?
  • 페이지랭크: 결과 우선 순위를 어떻게 매길 것인가?
  • 공개 키 암호화: 남이 뻔히 보고 있는 상황에서 어떻게 비밀스럽게 키를 교환할까?
  • 오류 정정 코드: 네트워크로 통신하고 디스크에 저장할 때 발생하는 오류를 어떻게 스스로 고칠까?
  • 패턴 인식과 인공지능: 철자를 자동으로 교정하고, 얼굴을 인식하고 카메라에 찍힌 내용이나 스캔한 내용을 글자로 바꾸는 마법은?
  • 데이터 압축: 엄청나게 큰 동영상이나 자료를 손쉽게 교환하려면 무엇이 필요할까?
  • 데이터베이스: 관계형 데이터베이스에 대한 기본 이론
  • 디지털 서명: 전자 세상에서 인감이나 서명은 무엇을 의미할까?
  • 계산 가능성과 결정 불가능성: 튜링이여 영원하라!

딱 한 문장으로 예를 들자면... 여러분이 구글에서 내용을 검색한 다음(인덱싱, 페이지랭크, 공개키 암호화), 특정 사이트에 계정과 암호로 접속해(데이터베이스) 캡차로 여러분이 사람임을 증명한 다음(패턴 인식과 인공지능, 계산 가능성과 결정 불가능성) 큰 파일을 다운로드 받아(데이터 압축, 오류 정정 코드), 진위를 확인하기 위해 검사하는(디지털 서명) 과정에서 이 모든 마법이 동원된다. 여러분이 컴퓨터를 켜서 어떤 작업을 할 때 매일 위에서 설명하는 알고리즘 덕을 보는 셈이다.

책 내용 중에 가장 마음에 들었던 부분은 공개 키 암호화를 설명하면서 페인트 혼합 트릭을 예로 든 내용이다. 공개 키에 대한 개념을 설명한 내용 중에서 가장 이해하기 쉬우면서도 정확한 예가 아닐까 하는 생각이 들었다. 다음으로 디지털 서명을 설명하면서 서명 은행이라는 개념을 예로 든 내용도 마음에 들었다(한국에서는 인감 제도가 있기 때문에 특히 이해가 더 쉬웠을지도 모르겠다). 물리 키가 아닌 논리 키를 어떻게 관리하고 교환하고 인증하는지 아주 쉽게 이해할 수 있을 것이다. 마지막으로 계산 가능성과 결정 불가능성을 설명하면서 예를 든 '다른 프로그램에서 충돌이 일어날지 알 수 있는 프로그램'은 아주 유쾌했다. 조금 어렵긴 하지만 "사람과 컴퓨터가 다를까? 아니면 기저까지 내려가면 같을까?"를 놓고 철학적인 고민을 해보기 바란다.

보너스로 이 책을 읽다가 발견한 보물 하나를 소개하겠다. 이 책 추천사를 쓴 크리스 비숍이 2008년 영국 왕립 연구소에서 강연한 내용인 Roayl Institution Christmas Lecture는 컴퓨터 과학 지식이 없는 사람을 대상으로 멋진 볼거리를 제공한다(비디오에 나오는 청중을 보면 ... 호기심 많은 아이들이다). 한글 자막이 없어 조금 아쉽기는 하지만 어려운 영어가 아닌 쉬운 영어를 사용하며 실제 예를 많이 들기 때문에 컴퓨터에 대한 대중적인 이해도를 높이기 위한 훌륭한 출발점으로 보인다. 비숍이 쓴 추천사에서 일부를 가져온다.

게다가 '컴퓨팅' 또는 '정보통신기술'이라는 과목명으로 학교에서 가르치는 내용은 대개 소프트웨어 패키지 사용법을 훈련하는 기술 정도에 불과하다. 그다지 놀라울 것도 없이, 학생들은 따분해 하고, 컴퓨터과학에는 지적 깊이가 결여됐다고 느끼게 되면서, 놀이와 소통에 컴퓨터 기술을 활용하려는 열정도 금세 사그라진다. 지난 십여 년간 컴퓨터과학을 전공하는 대학생 수가 50%나 감소한 현상의 핵심은 이와 같은 문제에서 기인한다.

한국의 현실도 이와 다르지 않다는 생각이다. 이 책을 읽고나서 컴퓨터에 대한 관심이 생기는 분들이 많아지면 더할 나위 없겠다.

EOB

화요일, 7월 02, 2013

[B급 프로그래머] JNI 함정과 우수 사례

지난번에 올려드린 [독서광] The Java Native Interface: Programmer's Guide and Specification이 대박은 아니지만 중박을 치면서 부족한 부분을 다시 한번 정리해드려야 겠다는 생각이 들었다. 그래서 오늘은 Best practices for using the Java Native Interface: Techniques and tools for averting the 10 most common JNI programming mistakes에서 개발자들이 JNI 프로그래밍 도중 흔히 저지르는 10가지 실수를 정리해봤다.

  1. Not caching method IDs, field IDs, and classes(캐시하지 않음): 메소드 ID, 필드 ID, 클래스를 캐시하지 않고 자주 native 쪽에서 참조할 경우 JVM이 클래스 계층을 오르락내리락하느라 무척 바빠진다. 그 결과 성능 저하가 생긴다.
  2. Triggering array copies(배열 복사 유도): JNI에서 배열은 값비싼 자원이다. 따라서 전체 배열에 접근하지 않고 반드시 필요한 부분만 접근하는 절약 정신이 요구된다. 예를 들어, long 담긴 배열에 접근할 경우 전체를 복사하는 GetLongArrayElements 대신 일부만 복사하는 GetLongArrayRegion을 사용할 수는 없는지 유심히 살펴볼 필요가 있다.
  3. Reaching back instead of passing parameters(매개변수 전달 대신 역참조): 사람들은 정보 은닉 관점에서 구조체나 클래스 객체에 여러 자료를 담아 전달하는 방식을 선호한다. 하지만 JNI에서 객체를 전달한 다음 객체에서 값을 얻기 위해 JNI 호출을 여러 번 하게 되면 굼벵이로 변한다. 따라서 처음부터 자료를 풀어헤쳐 개별 매개변수 형태로 전달하는 편이 훨씬 유리하다.
  4. Choosing the wrong boundary between native and Java code(잘못된 경계): 자바와 natvie 쪽 코드를 잘 분리해 자바에서 native로 native에서 자바로 호출이 최소로 일어나도록 만들어야 한다. 설계와도 관련이 있기 때문에 의외로 이 부분에 대해 실수하기 쉽다.
  5. Using many local references without informing the JVM(너무 많은 지역 참조): 지역 참조를 많이 할 경우 JVM 입장에서 무척 부담스럽다. 따라서 지역 참조를 될 수 있으면 적게 하고, 불필요한 지역 참조는 명시적으로 제거하는 편이 JVM 메모리 관리에 유리하다. 16개 이상 지역 참조가 필요할 경우 명시적으로 JVM에 이를 알려서 최적화가 가능하게 하자.
  6. Using the wrong JNIEnv(JNIEnv 오류): JNIEnv는 스레드 단위로 존재해야 한다. 스레드끼리 공유하거나 넘기면 절대 안 된다.
  7. Not checking for exceptions(예외 점검 미비): 예외를 일으킬 수 있는 JNI 함수 호출 다음에는 반드시 예외를 점검해야 한다. 이를 망각하면 나중에 (거꾸로) 대박 날지도...
  8. Not checking return values(반환값 점검 미비): JNI 함수 중에 결과를 반환하는 경우에 예외와 마찬가지로 제대로 검사해서 문제가 생겼을 경우 적절히 처리해야 한다.
  9. Using array methods incorrectly(배열 메소드 오용): 배열 메소드 쌍이 맞지 않으면 메모리 누수나 메모리 부족 현상이 생긴다.
  10. Using global references incorrectly(전역 참조 오용): 지역 참조만큼이나 전역 참조도 적절한 시점에서 잊어버리지 말고 해제해야 한다. JVM에서 메모리 누수 문제는 예상 외로 심각한 사태를 불러일으킬지도 모른다.

지난번과 중복되는 내용도 있고 새로 나온 내용도 있을 것이다. 얼마나 이런 실수가 많았으면, 아티클에서 문제 회피를 위한 표까지 정리해주었겠는가? T_T 다음 표를 참조해서 JNI 프로그래밍을 할 때마다 각성하면 좋겠다.

캐시하지 않음배열 복사 유도잘못된 경계너무 많은 역참조너무 많은 지역 참조JNIEnv 오류예외 점검 미비반환값 점검 미비배열 메소드 오용전역 참조 오용
JNI 명세 확인XXX
메소드 추적XXXXXXX
verbose:jniX
코드 검토XXXXXXXXXX
EOB