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

화요일, 9월 03, 2013

[독서광] 그리스인 조르바

지난번 야후! 블로그 복원 프로젝트(?)를 시작한다고 말씀드렸는데, 게으름으로 인해 차일피일 미루다 오늘 드디어 2번 타자를 소개드리려 한다. 바로 동명의 영화로도 유명한 '그리스인 조르바'다! 워낙 유명한 소설이니 여기서 다시 한번 소개할 필요가 있을까 하고 잠시 고민하다가, 그래도 명작은 함께 읽어야 제맛이라는 생각이 들어 기억을 되살려본다.

그리스인 조르바는 펜 대만 굴리던 젊은 그리스 지식인이 자유로운 영혼(!)인 조르바를 만나 함께 지낸 시절을 그리고 있다. 조르바는 요즘 고귀한 지식인(조르바 표현을 빌면 '펜대 굴리는 운전사') 입장에서 보면 자기 맘대로 기분 내키는대로 행동하며, 우리를 억누르고 있는 관습, 종교, 도덕의 지배를 받지않으며, 하루하루를 자기 마음 내키는 대로 삶을 즐긴다. 하지만 그렇다고 해서 조르바는 막되먹은 망나니가 결코 아니다. 조르바는 (마약을 하지 않고서도) 모든 사물에서 매번 새로운 면을 찾을 수 있고, (개똥철학이지만) 분명히 나름대로 이 세상 돌아가는 이치를 알고 있으며, (겉으로는 막되먹은 듯이 굴지만) 사람에 대한 애정으로 가득찬, 산투리를 연주하며 춤을 추면서 자신의 내면을 거리낌없이 표현하기에 한마디로 _난_ 사람임에 틀림없다.

이 책의 백미는 바로 조르바가 '나'에게 춤을 가르쳐주는 대목이다. 모든 것을 잃은 주인공이 자포자기 상태에서 벗어나 '자유의 여신'을 영접하는 장면은 두고 두고 기억이 남을 것 같다.

조르바의 통쾌한 어록을 몇 가지 정리해보겠다.

결혼 말인가요? 공식적으로는 한 번 했지요. 비공식적으로는 천 번, 아니 3천 번쯤 될 거요. 정확하게는 몇 번인지 내가 어떻게 알아요? 수탉이 장부 가지고 다니는 거 봤어요?
두목, 당신의 그 많은 책 쌓아 놓고 불이나 싸질러 버리시구랴. 그러면 알아요? 혹 인간이 될지?
확대경으로 보면 물속에 벌레가 우굴우굴한대요. 자, 갈증을 참을 거요, 아니면 확대경 확 부숴 버리고 물을 마시겠소?
인생의 신비를 사는 사람들에게는 (책 쓸) 시간이 없고, (책 쓸) 시간이 있는 사람들은 살 줄을 몰라요.

결론: 포도주 한 잔과 정말 잘 어울리는 이 책은 기운이 빠져서 비실거릴 때마다 삶에 대한 용기를 북돋아줄 것이다.

EOB

토요일, 8월 31, 2013

[독서광] The Architecture of Open Source Applications Volume II

지난 번 [독서광] The Architecture of Open Source Applications을 소개해드렸는데, 이번에 Volume II를 독파한 기념으로 다시 한번 소개해드리겠다. 역시 HTML 버전은 무료이며, The Architecture of Open Source Applications 홈페이지에서 Volume I, II를 모두 읽을 수 있다. 지난번에는 킨들을 사용해 읽었지만 이번에는 신형 레티나 아이패드로 무척 쾌적한 환경에서 독파했다.

직전에 올려드린 [B급 프로그래머] (3) 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?에서 설명했듯이 이 책은 오픈 소스 아키텍처에 대한 문서를 이상적으로 위조해(!) 프로젝트가 흘러온 역사, 아키텍처의 선택 이유, 프로젝트에서 변경을 결정한 이유, 진행 과정에서 배운 교훈을 후대 프로그래머를 위해 멋지게 정리하고 있다. 국내에서도 인지도가 높아졌는지 심지어 Volume II의 1장인 'Scalable Web Architecture and Distributed Systems'는 확장성 있는 웹 아키텍처와 분산 시스템이라는 제목으로 번역까지 되었으므로 확장성을 고민하는 독자들께 좋은 선물이 되리라 생각한다. Volume II 서문에 나오는 이 책의 집필 목표는 이 책의 성격을 제대로 규정하고 있다.

소프트웨어 설계는 예제를 사용해 제대로 배울 수 있으며 또 그렇게 해야 한다. 전문가처럼 생각하는 방법을 배우기 위한 최선의 해법은 전문가들이 생각하는 방법을 연구하는 것이다.

Volume II에서도 Volumen I과 마찬가지로 정말 다양한 소프트웨어의 아키텍처를 소개한다. 누구나 한번쯤 들어봤음직한 GDB, Git를 비롯해, 함수형 언어 컴파일러와 프레임워크, 다양한 언어로 만들어진 네트워크 프레임워크, 웹 서버, 병렬 라이브러리, 임베디드 소프트웨어 패키징, 구성 관리 시스템, CMS에 이르기까지 분야를 가리지 않는다. 자신이 속하거나 관심이 있는 언어/분야의 내용만 집중적으로 읽어도 좋지만 여기저기 기웃거리는 과정에서 얻는 지식도 상당하므로 시간날 때마다 하나씩 읽어보면 소프트웨어 아키텍처와 설계에 대한 혜안을 얻을 수 있을 것이다.

결론: 백문이 불여일견! 소프트웨어 개발자라면 프로그래밍 언어, 개발 분야, 경험을 따지지 않고 누구에게나 강력하게 추천한다.

EOB

금요일, 8월 30, 2013

[B급 프로그래머] (3) 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?

지난번에 [B급 프로그래머] (2) 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?을 올려드리며 잠깐 한숨을 돌렸다. 마지막으로 다룰 내용은 3부작의 핵심인 이상화된 설계 문서를 _쉽고 제대로_ '위조'하는 방법이다. 파나스 큰 형님이 쓰신 논문의 'II. FAKING THE IDEAL PROCESS"를 함께 읽어보자. (이하 스크롤 압박 주의!)

앞서 우리가 따르고 싶은 이상적인 프로세스와 이 프로세스를 따르는 동안 만들어야 하는 문서를 설명했습니다. 우리는 마치 이상적인 방식에 따라 뭔가를 작업했다는 듯이 문서를 작성하는 방식으로 이런 프로세스를 "위조"합니다. 앞서 설명한 순서에 따라 문서를 만들어내려 노력합니다. 정보의 일부가 존재하지 않는다면, 이런 사실을 해당 정보가 등장해야 마땅한 문서의 일부로 기술하며 마치 정보가 변경되리라는 사실을 기대하듯 설계를 계속 진행해야 합니다. 오류를 찾으면, 반드시 수정하고 문서에 관련된 변경을 가해야 합니다. 문서는 설계를 담은 매체이며, 문서에 통합되기 전까지는 해당 설계 결정이 내려지지 않은 것처럼 취급해야 합니다. 중간에 얼마나 발이 걸려 넘어졌는지 무관하게, 최종 문서는 이상적이면서 정확해야 합니다. 심지어 우리가 가장 이성적이라 여기는 수학 분야조차도 이런 절차를 따릅니다. 수학자들은 근면성실하게 증명을 다듬어, 처음과는 완전히 다른 증명을 내놓습니다. 첫 증명은 종종 지극히 고통스런 발견 프로세스의 결과입니다. 수학자들이 증명을 해나감에 따라 이해도가 높아지며 단순화할 방법을 찾아냅니다. 궁극적으로, 몇몇 수학자들은 이론의 진실을 좀더 명백하게 밝혀줄 더 단순한 증명을 찾아냅니다. 더 단순한 증명을 논문으로 출간하는 이유는 독자들은 이론의 진실에 관심이 있지, 이론을 찾아나서는 프로세스에 관심이 있지 않기 때문입니다. 소프트웨어에도 이와 유사한 추론을 적용할 수 있습니다. 소프트웨어 문서를 읽기를 원하는 독자들은 프로그램을 이해하기를 원하지, 프로그램 제작 과정을 다시 경험하기를 원하지는 않습니다. 이상적인 문서를 제공하는 방법으로, 실제 독자들이 필요한 내용을 제공할 수 있습니다. 우리가 만든 문서를 이상적인 문서와 비교하면 한 가지 중요한 차이점이 있습니다. 우리에게는 수용하고 거부했던 설계 대안을 모두 기록하는 정책이 있습니다. 각 대안에 대해 왜 수용했으며, 왜 마지막으로 거부했는지를 설명합니다. 여러 달, 여러 주, 심지어 여러 시간이 지난 다음 우리가 무엇을 어떻게 했는지 궁금하게 여길 때, 문서에서 찾을 수 있습니다. 지금부터 여러 해가 흘러, 유지 보수 인력이 동일한 질문에 부딪혔을 때, 대답을 문서에서 찾을 것입니다. 이런 프로세스가 성과를 거두는 실례는 이상적인 프로세스를 보여주는 일부로 몇 년 전에 작성된 소프트웨어 요구 사항 문서를 들 수 있습니다. 일반적으로 요구 사항 문서는 코딩을 시작하기 전에 만들어지며, 결코 다시 사용되지 않습니다. 해당 요구 사항 문서를 만족하는 현재 소프트웨어의 운영 버전은 여전히 변경이 가해지고 있습니다. 소프트웨어를 테스트해야 하는 조직은 테스트를 광범위하게 선택하기 위해 이런 요구 사항 문서를 활용합니다. 새로운 변경이 필요지면 어떤 변경이 가해져야 하며 어떤 변경이 가해지면 안 되는지 기술하는 문서를 참조해야 합니다. 여기서 우리는 이상적인 프로세스의 시작 시점에 만든 (위조된) 문서가 소프트웨어를 실제 환경에 투입하고 나서 여러 해가 지난 다음에도 여전히 사용되고 있음을 볼 수 있습니다. 메시지는 명확합니다. 만일 문서를 주의 깊게 작성한다면 오랜 기간 동안 유용할 것입니다. 그리고 반대로, 이렇게 만든 문서가 광범위하게 쓰인다면, 올바로 작성할 가치도 있을 것입니다.

원문이 한 문단으로 되어 있어 중간에 일부러 끊지 않았으므로, 한 번만 더 읽어보자. 두 번 읽었다면 지금부터는 실제로 이상적인 문서를 '위조'하는 방법에 대해 고민할 차례다. 본문을 읽다보면 밑줄을 그어야 하는 부분이 여러 곳 존재하는 데 그 중에서도 특히 "소프트웨어 문서를 읽기를 원하는 독자들은 프로그램을 이해하기를 원하지, 프로그램 제작 과정을 다시 경험하기를 원하지는 않습니다."라는 부분에 주목할 필요가 있다. 문서를 작성하는 과정에서 부딪히는 가장 큰 어려움은 바로 '우리가 앞으로 실제로 진행해야할 작업을 이상적인 형태가 아니라 전지적 관점에서 시시콜콜 기술하라'라는 말도 안 되는 요구다(말이 안 되는 이유는 시리즈 (1)번을 다시 읽어본다). 이런 말도 안 되는 요구에 따라 만든 문서로 최종 결과물을 검수하려니 여기저기서 삐걱거린다. 요구 사항을 낸 쪽에서는 미리 요구 사항을 제대로 수집하지 않았다고 난리며, 개발한 쪽에서는 애초부터 구현이 불가능한 설계 명세라고 난리다. 최종 사용자는 자신들의 의견이 반영되지 않았다고 난리며, 유지보수하는 인력들은 실제 개발 과정에서 일어난 변경 사항이 하나도 반영 안 된 죽은 문서라고 난리다. 어차피 책장 속에 들어가 다시는 꺼내보지 않을 운명에 처한 문서가 이 난리를 칠만큼 가치 있는지는 정말 잘 모르겠다.

그렇다면 문서를 어떻게 위조해야 할까? 개인적인 경험에 따르면, 미션 크리티컬한 프로젝트가 아니라면(음... 국방, 금융 말이지...) 처음 요구 사항 명세, 상위 아키텍처 설계, 상세 설계 문서 범위와 양을 최소로 줄이기를 권장한다. 그리고 문서를 작성할 경우 항상 타임머신을 타고 미래로 간 다음에 미래 시점에서 과거를 기술하는 방법으로 위조하는 방법을 권장한다. 이렇게 두 가지 기본 원칙을 제안한 이유를 조금 자세히 설명할 필요가 있겠다. 일단 범위와 양을 줄여야 하는 가장 큰 이유는 불확실성 때문이다. 어차피 문서 작업도 작업이므로 많은 시간이 들어가는데, 나중에 변경이 일어날 경우 문서를 작성하느라 날려버린 기회 비용을 상실하는 동시에 문서 수정 작업이라는 이중 난관에 부딪힌다. 어차피 처음부터 완벽한 문서를 만들지 못하는 상황에서 분량도 늘이고 완성도도 높이려 애를 써봐야 모든 사람이 괴로을 뿐이다. 게다가 내용 채워넣기 식으로 만든 문서는 본질을 흐리게 만들어 나중에 투입되거나 유지보수하는 인력에게 있어 혼란을 일으킨다. 로버트 C. 마틴 큰 형님께서 '가장 좋은 주석은 주석을 달지 않을 방법을 찾은 주석'이라고 표현했듯이, 어떻게 보면 소프트웨어 소스 코드와 최종 매뉴얼만으로 설명이 가능한 경우가 최선이다. 다음으로 미래 시점에서 과거를 기술하는 방법을 제안하는 이유는 사람의 사고 특성상 기한이 많이 남은 일일수록 추상적으로 생각하고 기한이 짧은 일일수록 구체적으로 생각하기 때문이다. 사람들은 사후분석에 능하다. 어떤 일이 터지고 나서 현실화된 다음에는 어떻게든 이를 합리화하고 이해하려는 노력을 기울이게 되므로, 미래 관점에서 과거를 서술하는 방식이 훨씬 쉽다. 하지만 프로젝트를 발주한 내/외부 '고객'에게 이런 요청을 할 경우에는 반드시 반대 급부를 제시해야 한다. 공동 설계 참여를 요청하거나(그렇게 되면 설계 문서가 이상화되어야 하는 이유에 대해 인정할 수 밖에 없는 상황에 놓이게 된다. 변경이 일상다반사인 상황에서 고정된 최종 형태를 고집할 수 있을까? 고집부린 사람이 나중에 다 뒤집어 쓰게 되는 판국인데?) 중간 검수 과정을 둬서 요구 사항 문서와 아키텍처/설계 문서를 깔끔하게 정리해(즉 위조해서!) 다시 제공하겠다는 (즉 처음 프로젝트 시작 시점에서 만든 문서는 큰 범위와 목표만 기술한다) 약속을 하는 방법이 대표적인 해법이다. 프로젝트가 중간 정도 지났으면 이미 상당한 밑그림과 세부 사항이 파악되었으므로 이상적인 최종 형태에 가까워지기에 작성하기도 읽기도 쉬운 문서 작성에 한 걸음 다가간 상태기 때문이다.

지금까지 일반적인 내용을 설명했는데, 위조된 문서의 구체적인 예가 없을까? 다행스럽게도 로버트 C. 마틴 큰 횽아가 작성한 '클린 코드'의 14장 '점진적인 개선'은 지금껏 B급 프로그래머가 봐 왔던 위조 문서 중에서 백미를 자랑한다. 일단 최종 형상을 보여준 다음에 원래 엉망인 코드로 돌아와 설계 관점에서 차근차근 개선하는 과정을 위조해서(!) 보여주는데, (앞서 피해야 한다고 말했던) '프로그램 제작 과정'을 따르면서도 (최종 목적인) '프로그램 이해를 도와주는' 놀라운 업적을 달성했다. 이렇게 된 이유를 생각해보니 설계 결정이 어떤 식으로 일어났고 그 결과 코드가 어떻게 변경되었는지를 유기적으로 설명하기 때문이다. 물론 일반적인 프로젝트 진행 과정에서 (감히?) 이런 파격적인 방식으로는 문서 작성이 힘들겠지만, 디자인 관련 결정을 이상적인 방식으로 기술하는 좋은 본보기가 되므로 꼭 읽어보기 바란다. 다음으로 소개할 예는 The Architecture of Open Source Applications Vol I, II(AOSA라 약칭하겠다)다. 오픈 소스 아키텍처를 설명하는 내용으로 이미 많은 분들께서 알고 계신 이 책은 프로젝트가 흘러온 역사, 아키텍처의 선택 이유, 프로젝트에서 변경을 결정한 이유, 진행 과정에서 배운 교훈을 비교적 이상적인 프로세스에 가깝게 기술한 훌륭한 사례 연구를 담고 있다. 물론 프로젝트가 어느 정도 진행된 다음 기술된 사후해석으로 취급해 가치를 인정하지 않는 분들도 계시겠지만, 소프트웨어 큰 그림을 이해하기 위해 필요한 구성 요소가 무엇인지를 잘 드러내고 있으므로 아키텍처 문서가 어떻게 되어야 하는지 궁금하신 분들께서는 반드시 읽어보시기 바란다(실제로 오픈소스 프로젝트 문서에서도 점점 AOSA의 해당 내용을 언급하는 경우가 많아지고 있다. 그만큼 도움이 된다는 말이다).

결론: 개발자들이 합심해 죄책감없이 _뻔뻔_하게 문서를 이상적인 형태로 위조(!)함으로써 우리 시대 가장 골치 아픈 문제 중 하나인 문서화 작업을 즐겁고 생산적으로 바꿔놓을 수 있다면 얼마나 좋을까? 이와 관련해 다른 좋은 방법이나 의견 있으면 언제든지 알려주시기 바란다. 정말 바라건데, 좋은 아이디어는 함께 공유합시다.

EOB

토요일, 8월 24, 2013

[독서광] 마이바티스 프로그래밍

지난번에 소개드린 [독서광] 데이터 접근 패턴과 같은 부류의 책 말고 실제 현장에 바로 적용 가능한 책을 원하는 독자분들이 분명히 존재한다. 오늘은 바로 이런 목적에 부합하는 마이바티스 관련 국내서(번역서가 아니다)인 '마이바티스 프로그래밍'을 소개해드리겠다.

먼저 마이바티스가 뭔지부터 잠깐 설명하고 넘어갈 필요가 있다. 마이바티스는 객체지향 애플리케이션을 작성할 때 관계형 데이터베이스를 손쉽게 사용하게 만드는 자료 매퍼 프레임워크라고 보면 된다. 하지만 프로그래밍에 앞서 관계형 테이블을 설계하고 SQL 구문을 작성한다는 측면에서 마이바티스는 단순히 하단 데이터베이스를 영속적인 객체 저장소로 보는 전통적인 ORM과 차이를 보인다. 실수를 유발하기 딱 좋은 엄청난 중복/반복 코딩으로 악명 높은 JDBC를 쉽게 사용하게 만들어주는 도구라 볼 수도 있겠다. 마이바티스는 SQL을 기반으로 출발하다보니 개발자들이 쉽고 빨리 기술을 배우고 적용할 수 있는 장점이 존재한다. 또한 관계형 자료를 객체로 인출하고 객체를 관계형 자료 형태로 저장할 수 있으므로, 도메인에 밀접한 프로그래밍 논리를 구현하기가 수월하다는 장점도 있다. 비즈니스 논리와 질의를 분리해서 얻는 장점은 여기서 다시 한번 설명하지는 않겠다.

자 이제 본격적으로 책 내용을 살펴보자. 이 책은 초중급자를 대상으로 필요한 개발 환경 구축부터 마이바티스의 기본 동작 방식과 활용법을 차근차근 단계적으로 설명한다. 실습이 가능하게 이클립스에서 바로 사용 가능한 예제 코드까지 홈 페이지에서 제공하고 있기에 테스트용 MySQL만 설정하면 바로 동작 과정을 확인할 수 있다. JDBC에 익숙한 개발자들이 마이바티스로 쉽게 넘어가게 CRUD 관련 코드를 JDBC 버전과 마이바티스 버전 양쪽으로 구현해놓았으므로 비교하면서 읽어보면 빠르게 부트스트래핑이 가능하다. 이렇게 감을 잡게 만든 다음, 웹 애플리케이션과 스프링 웹 애플리케이션 작성 방법을 설명해 마이바티스를 웹 애플리케이션 기반 프레임워크로 활용하도록 도와준다. 마지막으로 중급자를 위해 마이바티스 설정 파일, 매퍼 XML/인터페이스, 동적 SQL, 제네레이터를 참조 가능한 형태로 정리한다. 또한 (여러 가지 이유로) 기존 아이바티스에서 아직 벗어나지 못하는 개발자를 위해 아이바티스와 마이바티스의 차이점과 이주 방식에 대해 본문과 부록에서 설명하고 있으므로, 아직도 아이바티스를 사용하는 분들이 계시다면, 이 책을 읽고 마이바티스로 넘어가면 좋겠다는 생각을 해봤다. 마이바티스의 완성도가 상당히 높으므로 정말 불가피한 상황이 아닌 이상 굳이 레거시의 저주에 발목 잡힐 이유는 없다는 생각이다.

책을 읽다보니 아쉬운 점이 하나 있는데, 스프링 연동 설명이 생각보다 약했다. 물론 스프링이 워낙 복잡하니 정말 제대로 하려면 토비의 스프링과 같은 책을 읽어야 하는 상황이 정상이긴 하지만, 국내 개발자들이 스프링과 마이바티스를 하나로 묶어 개발을 진행하는 경우가 많으므로 혹시 후속 작품을 기획한다면 아예 제목부터 '마이바티스와 스프링 프로그래밍'으로 근사하게 하나 뽑은 다음에 핵심만 파고들면 더할 나위가 없겠다.

결론: 이미 눈치챘겠지만 책 목차와 전개 방식이 (늘 바쁘고, 핵심을 원하고, 바로 감을 잡게 만들어주는 뭔가를 요구하는...) 전형적인 한국 개발자를 위해 최적화되어 있으므로 국내서의 장점을 아주 잘 살렸다고 칭찬해주고 싶다. 마이바티스 책 한 권만 골라라고 하면 주저없이 이 책을 선택하겠다.

EOB

금요일, 8월 23, 2013

[B급 프로그래머] (2) 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?

지난번 올려드린 [B급 프로그래머] 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?라는 글에 많은 독자분들께서 관심을 보여주셨다. 따라서, 원래 2회로 예정했던 계획을 변경해 3회로 늘이기로 마음 먹었다(쪽대본 아니에요!). 오늘은 지난번 심각한 문제점에도 불구하고 이상적인 프로세스를 기술해야 하는 이유에 대해 파나스 형님께서 쓴 글의 III번 항목을 번역해봤다.

위에서 언급한 내용(이상적인 프로세스의 비현실성)은 아주 명백하며, 주의 깊은 사고가에게 잘 알려져 있으며, 정직한 사람들이라면 수긍할 것입니다. 그럼에도 불구하고 소프트웨어 설계 프로세스, 소프트웨어 설계 방법론을 다루는 워킹 그룹, 소프트웨어 설계를 논리적인 방법으로 기술하는 (이윤이 많이 남는) 각종 교육 과정에서는 늘 이상화된 프로세스를 주제로 삼습니다. 이런 사람들이 성취하려는 목표가 무엇일까요? 이상적이긴 하지만 완전히 달성할 수 없는 프로세스를 파악했다면, 최대한 비슷하게 이상적인 프로세스를 따를 수 있으며 그 결과 이상적인 프로세스를 따를 경우 만들 수 있어야 했던 문서를 작성할 수 있습니다. 이런 활동을 '이상적인 설계 프로세스를 위조(fake)하기'라 부릅니다. 이런 위조 기법이 필요한 이유를 정리하면 다음과 같습니다.
  1. 설계자들은 지침이 필요합니다. 큰 프로젝트를 맡았다면, 엄청난 작업 분량에 쉽게 압도 당합니다. 무엇을 먼저해야 할지 확실하지 않습니다. 이상적인 프로세스를 제대로 이해하면, 프로젝트 진행 방식을 알 수 있습니다.
  2. 주먹구구식 임시 변통 대신 프로세스를 따르려 노력할 경우 이상적인 설계에 좀더 가까이 다가갈 것입니다. 예를 들어, 심지어 이상적인 시스템을 설계하기에 필요한 모든 사실을 모를 경우에도, 코딩에 앞서 이런 사실을 찾으려는 노력은 설계를 더 좋게 만들고 재작업을 줄일 것입니다.
  3. 조직이 여러 소프트웨어 프로젝트를 수행할 때, 표준화된 절차는 큰 장점입니다. 여러 프로젝트 사이에서 좋은 설계 검토를 비롯해, 사람, 아이디어, 소프트웨어 공유를 원활하게 만듭니다. 표준화된 프로세스를 명세할 경우, 이상적이어야 한다는 사실은 합리적으로 보입니다.
  4. 이상적인 프로세스에 동의했다면, 프로젝트를 만들어가는 프로세스를 측정하기가 더 쉬워집니다. 이상적인 프로세스가 요청하는 내용과 비교해 프로세스의 산출물을 비교할 수 있습니다. 어느 부분에서 뒤쳐졌는지 앞섰는지 알 수 있습니다.
  5. 외부에서 프로젝트 진행을 주기적으로 검토하는 관례는 좋은 관리에 있어 핵심입니다. 프로젝트가 표준 프로세스를 따르려 시도한다면, 검토도 쉬워집니다.

지난번 글을 읽고 나서 이번 글을 읽으면 갑자기 멘붕이 올 것이다. 분명히 이상화된 프로세스는 현실적이지 않다고 말했는데, 그래도 이상적인 프로세스를 추구해야 한다는 모순된 이야기가 나온다. 너무 고민하지 마시라. 여기서 핵심은 바로 '위조(fake)'니까. 위조를 사전에서 찾아보면 '어떤 물건을 속일 목적으로 꾸며 진짜처럼 만듦.'이라 나온다. 코드 작성 과정에서 초롱초롱한 눈망울로 모니터 속에 들어갈 기세로 집중하는 개발자들이 문서를 작성하기만 하면 동공이 풀리고 어깨가 축 늘어지고 줄담배를 피고 웹 서핑을 하며 머리카락을 쥐어 뜯는 이유는 늘 진실되게 대화하는 컴퓨터 프로그래밍 언어와 달리 능숙한 위조를 요구하는 사람 언어로 뭔가를 작성해야 하기 때문이다. 레지스터 값 하나에 목숨을 거는 개발자들에게 위조는 고문 그 자체다. T_T 하지만, 문서를 보는 주체는 컴퓨터가 아니라 사람이므로 당연히 사람에 맞춰야 하며(빌어먹을 인문학!!!!!), 이 과정에서 이상과 현실 사이에 심각한 괴리가 생기기 마련이다.

자 그렇다면 우리가 위조해야 하는 이상화된 형태의 소프트웨어 설계 "프로세스"가 무엇일까? 파나스 큰 형님이 초지 일관 주장하는 모듈화와 관련이 깊다. 요약하자면 요구 사항 명세, 모듈 구조 설계와 문서화, 모듈 인터페이스 설계와 문서화, 'uses' 계층 설계와 문서화, 모듈 내부 구조 설계와 문서화, 프로그램 작성, 유지 보수 순을 따른다. 세부 사항을 여기서 설명할 경우 큰 주제를 흐릴 가능성이 높으므로 다음에 기회가 닿으면 하나씩 소개하기로 하겠다.

여기까지 글을 적고 허무하게 끝내버리면 "사람 약 올리냐!"라고 민원이 빗발칠게 뻔하므로, 다음에 올려드릴 마지막 글에서는 불쌍한 개발자들을 위해 이상화된 설계 문서를 _쉽고 제대로_ '위조'하는 방법을 (지금까지 경험을 곁들여) 정리하겠다.

EOB

토요일, 8월 17, 2013

[일상다반사] 파워포인트 협업 도구인 Kivo

(이미지는 Kivo (YC S13) uses git to make collaborating on documents easier, starting with PowerPoint에서 가져왔습니다)

지난번 [일상다반사] Schemer: 소셜 TO-DO 리스트를 소개드리면서 아이디어를 떠올리기만 하고 실행에 옮기지 못했던 사례를 들었는데, 독자 여러분들께서 많은 관심을 보여주셨기에 오늘도 이야기 보따리를 하나 풀어놓으려 한다. 역시 작년 초에 회사에서 브레인스토밍을 하다 완전 엉뚱한 서비스를 하나 제안한 적이 있었다. 간략하게 소개하자면, 사람들이 만들어내는 문서의 유사도를 계산해 관련된 문서를 클러스터링하고 차이점 등을 보여주는 서비스였다. 예를 들어, 사내 컴퓨터 여러 대에 'Super프로젝트_제안서_2013_08_15.pptx", 'Super프로젝트_제안서_2013_08_16.pptx", 'Super프로젝트_제안서_2013_08_17.pptx"라는 문서가 흩어져 있으면 이를 자동으로 감지해 "Super프로젝트_제안서"라는 범주를 만들고 여기에 파일 세 개를 집어넣어 연관된 문서나 관련된 문서를 쉽게 찾고 버전을 추적하게 지원하는 도우미라 보면 되겠다. 여기서는 파일 이름의 첫부분이 모두 유사하므로 수동으로도 관리할 수 있다고 생각할지 모르겠지만, 그냥 "프로젝트_제안서.pptx"라고 이름을 붙이거나 앞에 작성자 명을 추가해 "jrogue_프로젝트_제안서_2013_08_15.pptx"라 붙일 경우에도 자동으로 파일들을 연관지을 수 있다면 대박이 아닐까 생각했다. 이번에는 진전이 있어 메타 정보를 뽑아내어 데이터베이스화하고, subversion을 사용해 버전 관리를 하는 아이디어까지 도출되었으나 역시... 상품화의 길은 멀고도 험난하다는 진리만 깨닫고 말았다.

그런데... Kivo라는 서비스를 보고 나서 '아차!'하는 생각이 들었다. 역시 내가 생각하면 남들은 서비스를 한다는 진리가 다시 한번 증명되는 순간이었다. Kivo는 파워포인트 플러그인 형태로 사용자가 특정 문서에 대해 변경한 내용을 git에 올린 다음 이를 남들과 공유하게 만드는 기능을 제공한다. 어차피 협업이 가능한 구글 docs가 있지 않느냐고 반문할지도 모르겠는데, 둘은 작업 흐름이 다르다. 솔직히 제안서 등을 작성할 때, 수십 명이 달라붙어 실시간으로 문서를 편집하지는 않는다(그랬다가는 지옥문이 열릴테니까). 특정 부분을 맡은 사람이 문서를 조각 내어 작성하고, 나중에 취합한 다음에는 일부 관련자들만 공동 작업을 번갈아가며 하게 된다. 하지만 우리가 소스 코드 관리 시스템에서 늘상 목격하는 편리한 작업 이력과 변경 내용 확인 기능을 사용할 수 없으므로 여기저기서 실수/재작업/일부 내용 누락과 같은 문제가 터져나오기 마련이다. Kivo는 파워포인트 페이지 단위로 변경된 이력을 git로 관리해 일목요연하게 보여주며 필요하다면 각 페이지 별로 다른 이력을 적용해(git의 cherry picking 기능이 떠올랐다) 문서를 꾸밀 수도 있다.

물론 아직 제한점이 많다. 현재 파워포인트만 지원하며, 오피스 2007/2010 버전에서만 동작한다(2013 버전에서는 제대로 동작하지 않음을 확인했다). 또한 아직 매킨토시 버전은 출시되지 않았다(조만간 베타 버전이 나올 것 같긴 하다). 워드 버전은 개발 중이라고 하는데, 페이지 단위로 명확하게 변경 내용을 확인할 수 있는 파워포인트와는 달리 목차를 기준으로 변경 내용을 보여줘야 하는 관계상(그렇지 않으면 폰트 크기만 아주 사알짝 변경해도 재앙이 벌어진다. T_T) 구현이 그렇게 쉽지는 않아 보인다. 엑셀 같은 경우에는 보여주는 내용 뿐만 아니라 매크로 등 변경 내용이 더욱 중요하므로 구현 자체가 불가능할지도 모르겠다는 생각도 든다. 하지만 이런 여러 가지 제약에도 불구하고 Kivo의 잠재력은 충분히 커 보인다. 지금까지 DMS(Document Management System)나 KMS(Knowledge Management System)에서는 문서를 다룰 때 문서 전체를 하나의 엔티티로 취급했기에 조밀도가 떨어지고, 위키와 같은 시스템에서는 문서 내부의 변경 내역을 확인하도록 이력 관리를 해주므로 조밀도는 높으나 외부로 공개할 경우 참으로 난감한 상황(Confluence와 같은 기업용 위키조차도 PDF나 doc/docx로 export하는 기능은 낙제에 가깝다)이 벌어지므로 뭔가 다른 획기적인 해법이 필요하다는 사실은 누구나 공감하고 있기 때문이다.

사업적인 측면에서 보면, github나 bitbucket등의 대성공과 마찬가지로 외부로 유출되면 곤란한 기업의 핵심 기밀 문서가 아닌 일반적인 문서인 경우 호스팅 서비스로도 충분한 위력을 발휘할 가능성이 아주 높다. 백업, 이력 관리, 협업, 클라우드 저장소와 같은 핫한 키워드가 모두 따라다니는 데다 마이크로소프트 오피스라는 현존하는 전세계에서 가장 막강한 문서 관리 기반 구조를 등에 업고 있기 때문이다. 오히려 어떤 면에서 오피스 365보다 더 희망적이라는 생각도 해본다. 마이크로소프트가 M&A를 할지도... ㅋㅋ 아직 무료로 서비스하는 상태라 혹시 오피스 2007이나 2010를 사용하는 분들께서 한번 실험해보시기 바란다.

EOB

금요일, 8월 16, 2013

[일상다반사] '해커스' 출간 소식

여러분들께서 기대하고 고대하던 블록버스터인 Hackers: Heroes of the Computer Revolution - 25th Anniversary Edition 번역서인 '해커스'가 곧 출간된다는 기쁜 소식을 전해드리겠다. 아시는 분은 다 아시겠지만, 한국에서도 1991년 '해커'(상/하), 1996년 '해커 그 광기와 비밀의 기록'이라는 이름으로 이미 두 차례 출간된 적이 있는 이 책은 25주년을 기념해 오라일리에서 새로 출간함으로써 한국에서도 복간의 기회를 얻게 되었다. 거의 500페이지에 달하는 분량(물론 본문에 코드는 단 한 줄도 없다 T_T) 때문에 번역과 편집 시간이 오래 걸린 점을 각별히 양해 부탁드리겠다.

몇 가지 뒷 이야기를 정리해 보겠다. 1970~80년대 캘리포니아를 배경으로 하니 너무나도 당연하겠지만, 19금 수준의 자유분방한 이야기(전사적으로 술판 벌이고, 약빨고, 감옥가고, 포르노 게임 만들고, ... T_T)가 제법 나오지만... 무삭제를 원칙으로 문장 하나 시 한 줄 빼먹지 않고 꼼꼼하게 번역했다. 또한 8비트 컴퓨터는 물론이고 플로피 디스크조차 주변에서 찾기 어려운 관계상, 새로 이 책을 접하는 독자 여러분의 이해를 돕기 위해 본문 곳곳에 편집팀의 도움을 받아 사진과 그림을 추가했다. 마지막으로 옛날 이야기가 너무 옛날 이야기처럼 느껴지지 않도록 역사성과 정확성을 희생하지 않는 범위 내에서 최대한 현대적인 감각으로 번역했으므로(이를 위해 20년전과 15년전에 출간된 기존 번역서는 참고 목적으로도 들여다보지 않았다), 신세대 개발자 여러분들도 무리 없이 읽을 수 있으리라 믿는다.

최근 한국에서 IT 관련해 여러 가지 담론들(인문학, 통섭, 창의력, 조기 교육)이 튀어나오고 있지만, 이 책을 읽는 순간 하나같이 부질없는 허상이라는 사실을 깨닫게 될 것이다. IT 인력을 양성(응?)해 경제 발전(!)에 기여하자는 거창한 구호를 듣고 있으려니, 컴퓨터 세상을 직접 지배하고, 자기 손으로 뭔가를 만들고, 너무나도 재미있어 몰입하고, 남과 함께 공유하는 _자발적인_ 해커 정신이 더더욱 귀중하게 느껴진다. 요즘 너무나도 자연스럽게 세상에 침투한 오픈 소스는 결코 공짜로 얻어진 것이 아니다. 바로 다음과 같은 구호를 부르짓은 선구자 해커들의 투쟁에 의해 얻어진 것이다.

프로그램은 최대한 노출되어야 한다. 왜냐하면 정보는 자유로워야 하며 가속화된 정보의 흐름은 세상을 개선하니까!

무더운 여름, 독자 여러분들도 잠시나마 시원한 해커 세상으로 몰입할 준비가 되었는지? 이미 온라인 서점에서는 예판에 돌입했으니 그동안 절판된 책을 찾아 다니느라 고생하신 분들께서는 지금 바로 뽐뿌질 당하시기 바란다. :)

보너스: 빈꿈님께서 그려주신 삽화

업데이트: 드디어 출간되었습니다. 따끈따끈한 인증샷 추가.

EOB

화요일, 8월 13, 2013

[B급 프로그래머] 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?

그 동안 불꽃튀는 논쟁이 벌어질만한 내용은 언급을 자제했으나... 무더운 여름을 날려버리기 위해 오늘은 조금 도발적인 주제를 다뤄보도록 하겠다. 파나스 큰 형님이 쓰신 논문인 A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT 의 II번 항목을 번역해봤다.

우리는 "이성적인" 방식으로 전개되는 소프트웨어 프로젝트를 결코 보지 못할 것입니다. 몇 가지 이유를 정리하면 다음과 같습니다.

  1. 대부분 소프트웨어 시스템 제작을 의뢰하는 사람들은 정확히 무엇을 원하는지 모르며, 자신들이 알고 있는 내용을 우리에게 말해줄 능력이 부족합니다.
  2. 심지어 우리가 요구 사항을 알았다 하더라도, 소프트웨어 설계에 필요한 다른 사항이 존재합니다. 이런 세부 사항은 구현을 진행하는 과정에서만 알게 됩니다. 이렇게 알게된 몇몇 지식은 설계를 무효로 만들어버리므로 설계 단계로 거슬러 올라가야합니다. 잃어버린 작업량을 최소로 줄이려 시도하기에, 결과로 만들어진 설계는 이성적인 설계 프로세스에서 나온 결과와는 거리가 멉니다.
  3. 시작하기 전에 모든 관련 사항을 알고 있다하더라도, 경험에 따르면 우리 인간은 올바른 시스템을 설계하고 만들기 위해 반드시 고려해야 하는 엄청난 세부 사항을 완전히 이해할 수 없습니다. 소프트웨어 설계 프로세스는 고려 사항을 분리함으로써 관리 가능한 정보를 사용해 작업하는 과정입니다. 하지만 고려 사항을 분리할 때까지 우리는 필연적으로 오류를 만들어내기 마련입니다.
  4. 심지어 필요한 모든 세부 사항을 마스터할 수 있다하더라도 가장 하찮은 프로젝트조차도 외부 원인에 의해 변경될 운명에 처합니다. 몇몇 변경은 직전 설계 결정을 무효로 만듭니다. 이런 결과로 만들어진 설계는 이성적인 설계 프로세스가 생성한 설계와 거리가 멉니다.
  5. 사람의 오류는 사람이 개입되지 않아야 피할 수 있습니다. 심지어 고려 사항을 분리한 다음에도 오류가 발생합니다.
  6. 우리는 종종 사전에 형성된 설계 아이디어 때문에 부담을 느낍니다. 우리가 고안했던 아이디어, 관련된 프로젝트에서 얻은 아이디어, 수업 시간에 들은 아이디어 말입니다. 종종 좋아하는 아이디어를 사용하거나 시도하려 프로젝트를 맡기도 합니다. 이런 아이디어는 요구 사항에서 이성적인 설계 프로세스를 사용해 유도되지 않았을지도 모릅니다.
  7. 종종 경제적인 이유 때문에 다른 프로젝트를 위해 개발한 소프트웨어를 사용하도록 장려합니다. 어떤 상황에서는 진행 중인 다른 프로젝트와 소프트웨어를 공유하도록 장려하기도 합니다. 이런 결과로 만들어진 소프트웨어는 양쪽 프로젝트 어디를 봐도 이성적인 소프트웨어가 아닙니다. 즉, 요구 사항 자체를 기반으로 개발한 소프트웨어가 아니며, 노력을 줄일 목적으로 고만고만하게 만든 소프트웨어입니다.

이런 이유 때문에, 소프트웨어 설계자가 요구 사항으로부터 이성적이고 오류가 없는 방식으로 설계한 그림은 엄청나게 비현실적입니다. 어느 시스템도 이런 이성적인 방식으로 개발되지 않았으며, 아마도 앞으로도 이런 일은 생기지 않을 것입니다. 심지어 교과서나 논문에 나온 작은 프로그램 개발조차도 비현실적입니다. 교과서나 논문에 나온 프로그램은 개선되고 수정되는 과정을 거치면서 저자들이 바라는 바를 보여주지 실제 일어난 과정을 보여주지는 않습니다.

여러분이 진행 중인 소프트웨어 개발 과정을 잠시 상상해보자. 애자일 개발 방법을 논하지 않더라도 고객 요구 사항을 수집하고, 스펙을 만들고, 아키텍처 설계를 마치고, 세부 설계에 들어간 다음 불꽃 코딩을 거치면 위대한 결과물이 톡 튀어 나온다고 생각하는 개발자는 그렇게 많지 않을 것이다. 하지만 구현에 앞서 문서(스펙, 아키텍처, 세부 설계, 뭐든 좋다)를 열과 성을 다해 제대로 작성하지 않았기에 소프트웨어가 엉망진창으로 나온다는 희한한(응?) 주장에는 딱히 반박하지 못했을 것이다. 하지만 정말 그럴까? 우리는 소프트웨어 개발에 앞서 이성적이고 완벽한 문서가 짜잔하고 만들어질 수 있느냐를 놓고 고민할 필요가 있다. 이런 고민이 필요한 이유는 간단하다. 개발자들이 처음부터 완벽한(아니 이성적인) 문서를 만들지 못했다는 죄책감에서 벗어나야 하기 때문이다. 처음부터 완벽한 소프트웨어가 없듯이 처음부터 완벽한 문서도 없다. 그렇다면 이런 상황에서 어떻게 문서를 만들어야 할까? 다음 번에 파나스 큰 형님의 조언을 정리해드리겠다. 조금만 기다리시라. :)

주의: "용감한 프로그래머에게 설계 따윈 필요없으니 코딩으로 바로 뛰어들자!"라는 주장이 아님을 노파심에서 다시 한번 강조한다.

EOB

토요일, 8월 10, 2013

[독서광] 데이터 접근 패턴

요즘 워낙 많은 책(한국어판, 원서)을 동시에 읽고 있다보니 서평이 뜸했었다. 오늘은 간만에 설계 관련 책을 하나 소개해드리려고 하는데, "데이터베이스와 효율적으로 상호작용하는 25가지 소프트웨어 디자인 패턴"이라는 긴 부제가 붙은 '데이터 접근 패턴'이 주인공이다. 주의 사항을 몇 가지 짚고 넘어가자. 이 책은 2003년도에 원서가 출간되었고 번역서가 2013년에 출간되었기에 10년이라는 공백이 존재한다. 따라서 아주 새롭고 신기한 신기술은 다루지 않는다는 사실을 반드시 인지해야 한다. 또한 요즘 나오는 마이바티스 등 각종 데이터베이스 프레임워크와 ORM과 같은 기술을 소개하지도 않으며, 순수하게 JDBC만으로 모든 예제를 설명하기에 착오없으시기 바란다. 마지막으로 철저하게 관계형 데이터베이스를 중심으로 설명이 진행되므로(일례로 5부는 트랜잭션과 잠금에 대한 내용을 중심으로 구성되어 있다) 요즘 유행하는 NoSQL 관련 내용을 기대하면 안 된다. 이 책을 읽기 위해서는 자바와 JDBC 프로그래밍 기술, 관계형 데이터베이스에 대한 기초 지식, 그리고 (필수는 아니지만) 패턴에 대한 기본적인 이해가 필요하다.

이 책 목차를 보면 1부 '분리 패턴'에서는 데이터 접근 코드와 비즈니스 논리를 구분하는 방법을 소개한다. 2부 '리소스 패턴'에서는 데이터베이스 프로그램에서 사용하는 여러 가지 리소스를 격리하는 방법을 소개한다. 3부 '입출력 패턴'에서는 관계형 데이터의 물리 형태와 도메인 객체 표현을 분리하는 방법으로 데이터 입출력 연산을 단순화하는 방법을 소개한다. 4부 '캐시 패턴'에서는 물리적인 데이터베이스 접근을 최소화하는 다양한 캐시 전략과 구성 요소를 설명한다. 마지막으로 5부 '동시 실행 패턴'에서는 동시에 데이터에 접근이 일어날 경우 발생하는 문제점을 해결하기 위해 트랜잭션과 잠금을 설명한다. 목차를 보면 알겠지만 요즘 나오는 데이터베이스 프레임워크가 여러분을 위해 뒤에서 열심히 서비스하는 내용을 어떤 이론에 기반해 어떻게 설계하고 구현할지를 다룬다고 보면 틀림없겠다. 물론 어디까지나 설명을 위한 설계와 예제이므로 실전에서는 한계가 분명히 존재하며, 이 책에 나온 코드를 그대로 사용할 수 있으리라는 기대는 접기 바란다.

그렇다면 이 책은 어떤 독자를 대상으로 할까? 우선 기본 데이터베이스 프레임워크를 분석하거나 아예 필요에 딱 맞춰 새로 만들려는 개발자들이 참고할만하다. (어차피 이런 부류의 경쟁서가 아예 없으므로) 완벽하지는 않지만 출발점으로는 좋아보인다. 다음으로 데이터베이스를 많이 다루는 엔터프라이즈 애플리케이션 설계에 관심이 있는 설계자들이 참고할만하다. 특히 캐시 패턴과 동시 실행 패턴은 기초 이론에 대한 설명과 실제 예제가 함께 등장하므로 구체적인 기반 위에서 설계를 진행할 수 있게 도와준다. 마지막으로 (어떤 사정상) 어쩔 수 없이... JDBC 만으로 프로그램을 만드는 프로그래머에게 도움을 준다. "요즘 누가 JDBC로 날 코딩을 하지?"라고 의문이 생기는 분들도 계시겠지만... 뭐 사정상 필요한 경우가 있기 마련이다(예: B급 프로그래머. T_T).

번역 상태를 보자. 이런 부류의 서적에서 필연적으로 다가오는 '용어' 문제는 누가 번역하더라도 풀지 못할 난제이므로 책의 가장 뒷편에 나오는 용어 정리 항목을 먼저 읽어 머리 속에 한글단어-영어단어-개념이라는 해시맵을 만들고 나서 시작해야 할 것이다. 만일 이런 indirection 과정을 참지 못하거나 용어에 민감해 신경질이 나는 독자라면 번역서 대신 원서를 강력하게 추천한다. 비문이 조금씩 눈에 띄고 직역이 많긴 하지만 다행스럽게도 이해하는 과정에서 큰 어려움은 없었다. 코드에 잘못된 문자가 들어가거나 띄어쓰기가 이상하거나 하는 경우가 있긴 했지만, 실시간으로 고쳐서 읽을 수 있는 수준이었다. 시간 절약을 위해 원서 대신 번역서를 읽어도 무방하다는 생각이다.

결론: 아주 새로운 내용은 없지만 기초를 잘 설명하고 있으므로 데이터베이스 애플리케이션과 관련해 설계와 구현에 관심이 있는 독자분께 추천드린다.

EOB