수요일, 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