토요일, 9월 29, 2012

[독서광] 익스트림 프로그래밍

오늘은 애자일 서평 두번째로 '익스트림 프로그래밍'을 소개하겠다. XP(eXtreme Programming)이 일반에 잘 알려져 있긴 하지만 의외로 시중에 익스트림 프로그래밍 관련 서적은 별로 없는 듯이 보인다. 다행스럽게도 켄트 백이 쓴 'Extreme Programming Explained: Embrace Change(2nd Ed.)'가 한국어판으로 나와 있어 XP에 관심이 많은 분들께 도움이 된다는 생각이다.

XP는 애자일 소프트웨어 개발 방법 중 가장 널리 알려져 있는 소프트웨어 개발 기법으로 짧은 개발 주기 동안 잦은 소프트웨어 배포가 가능하므로 고객 요구 사항이 불확실한 상황에서도 소프트웨어 품질을 높이며 반응 속력을 빠르게 만들어준다. '익스트림 프로그래밍' 책은 단순히 XP의 실천 방법을 소개하는 내용을 넘어서 가치, 원칙, 실천 방법을 유기적으로 연결해 설명하고 있으며, XP 이면에 숨겨진 철학을 밝혀주기에 인터넷에 올라온 단편적인 XP 실천 방법을 넘어서 제대로 된 소프트웨어 개발이 무엇인지에 대한 근본적인 질문을 우리에게 던져준다.

많은 기업들이 '애자일' 개발을 표방하고 있지만(최근 어떤 모임(미국이 아니라 한국이다)에서 참여한 기업 열 곳 중 80% 이상이 애자일 방법으로 소프트웨어를 개발하고 있다는 이야기를 듣고 깜짝 놀란 적이 있다), 실제로는 미친듯이 만들고 미친듯이 수정하는 과거의 짜보고 고치기(code and fix)와 다름 아닌 상황은 아닌지 걱정스럽기도 하다. 겉보기에는 자유 분방한 듯이 느껴지는 애자일이 실제로는 무척 엄격한 원칙과 규칙에 따라 움직이므로 이면에 숨은 철학을 충분히 흡수해 올바른 길을 걷지 않는다면 오히려 제품 개발과 프로젝트가 통제 불능에 빠져 경영진과 개발팀 모두에게 크나큰 상처를 입힐 가능성을 늘 경계해야 한다.

다행스럽게도 '익스트림 프로그래밍'은 XP는 물론이고 다른 애자일 소프트웨어 개발 방법론(스크럼, 린 소프트웨어, TDD)에서도 동일하게 적용할 수 있도록, '사회적인 변화'를 수반한 훌륭한 코드 작성에 필요한 마음가짐과 자세를 꼼꼼하게 짚어주고 있다. 참고 문헌과 색인까지 합쳐도 250페이지에 불과한 작다면 무척 작은 책이지만 각 장마다 생각할 거리를 충분히(아니 어떤 경우에는 흘러 넘치도록) 제공하기 때문에 빠르게 읽기는 상당히 곤란한 나름 두꺼운(?) 책이다. '컴퓨터 vs 책' 애독자로서 [독서광] 컬럼에 소개한 여러 가지 다앙한 분야의 책(예: 엘리 골드랫의 ToC 관련 서적, 토요타 방식(JIT), 피플웨어와 슬랙 등 드마르코 책, 창발성에 관련된 각종 서적(부의 기원, 혼돈의 가장자리) 등등)을 접하신 분들이라면 서로 연관시켜가며 정말 흥미롭게 읽을 수 있을 것이다. 너무 극단적이지도 않고 너무 현학적이지도 않은 어조로 소프트웨어 개발 작업에서 인간성과 생산성을 조화롭게 만들어 사업에서 성공을 거두는 방법을 다루고 있기에 애자일에 관심을 보이는 모든 분들께 강력하게 추천하고 싶다(결론: 추석 특집 뽐뿌질).

토요일, 9월 22, 2012

[독서광] Make: 04

기대하고 고대하던(어린 시절 월간지 기다리는 느낌) Make: 04가 나왔기에 출퇴근 시간을 이용해 잽싸게 읽었다. 이번 달에 소개하는 내용은 책상 위 공작소라는 제목으로 (기계 분야 친구들이 좋아할만한) 3D 프린터와 CNC 등을 특집으로 다루고, 아두이노를 기반으로 하는 수공예 플랫폼(응?)인 릴리패드 아두이노를 특집으로 다루고 있다. 기계와 뜨개질이라... 두 단어가 잘 어울리지는 않지만 손으로 뭔가를 만들고자 하는 사람들에 있어서 수단과 방법이 문제랴?

그런데 이번 호에서 가장 충격을 먹은 내용은 바로 '새뮤엘 (랭혼) 클레멘스'(라고 쓰고 '마크 트웨인'이라고 읽는다)의 벤처 정신을 다룬 '마크 트웨인: 테크놀로지스트'라는 내용이었다. 창조자들을 읽어보면 마크 트웨인을 엄청난 재담군에 뛰어난 피아니스트에 미국 문학을 일으켜 세운 주인공으로 그리고 있었는데, 페이지 식자기를 만든 제임스 페이지를 만나면서 벤처 투자가(?)로 전향한 사실은 전혀 모르고 있었다.

(페이지 사진 식자기)

페이지(Paige) 식자기는 기존 수동으로 하던 활자 조합을 빠르게 자동으로 도와주는 인쇄 기계로 10배 이상 생산성을 높였기에 식자 작업의 혁명을 가져다줄만한 물건이었다. 당연히 이 멋진 기계는 출판에 관심이 많았던 클레멘스의 시선을 붙잡았다. 위키피디아 마크 트웨인의 Financial troubles 섹션을 읽어보면 마크 트웨인이 이 기계를 위해 엄청난 돈(무려 30만불! 인플레를 감안한 오늘날 화폐 가치로 환산하면 8백만불 정도다. T_T)을 퍼부었지만 18,000개나 되는 부품에 원 제작자의 완벽주의가 합쳐져 실용화 직전에 주저 앉아버렸다. 그 결과 마크 트웨인은 재정적인 어려움에 시달려 맨션을 폐쇄히고 출판업도 포기하는 등 상당한 타격을 받았다. 만일 페이지 식자기가 성공했더라면 오늘날 마크 트웨인은 재담가나 작가가 아니라 벤처 캐피탈 대부로 추앙받고 있었을지도 모른다.

(라이노타이프)

이렇게 우아하고 멋진 기계가 마땅히 차지했어야 하는 자리는 투박하고 멍청한 라이노타이프가 대신하고 말았다. 페이지 식자기보다 60% 이상 느리지만 구조의 단순함에 힘입어 유지보수도 쉬웠고 변종도 다양하게 나왔기에 인쇄 현장에서 각광을 받았다. 라이노타이프는 식자공의 UX를 고려하지 않고 기계 제작의 편의성에 초점을 맞췄기에(이 쯤에서 우리는 QWERTY 키보드를 다시 한번 생각하게 된다. 낄낄), 공학적이고 기술적인 관점에서 페이지 식자기에 발려야 마땅하지만... 우리가 늘 알고 있든 세상만사가 그렇게 원리 원칙대로 돌아가지는 않는다.

EOB

토요일, 9월 15, 2012

[독서광] 테스트 주도 개발 : 고품질 쾌속개발을 위한 TDD 실천법과 도구

지난 주에 약속한 대로 애자일 관련 서평에 돌입하겠다. 1번 타자는 '테스트 주도 개발: 고품질 쾌속개발을 위한 TDD 실천법과 도구'인데 무려 국내서(!)이다. 정말로 오래 전(2005년 1월이다)에 테스트 주도 개발 서평이라는 제목으로 켄트 벡의 '테스트 주도 개발' 독후감을 올렸는데, 거의 8년이 지난 이 시점에서 다시 한번 TDD와 관련된 서평을 쓰려니 감개가 다 무량할 지경이다. 거두절미하고 한 문장으로 느낌을 정리하자면... "기술도 발전했고 도구도 발전했고 무엇보다 개발자들도 발전했다"라고 보면 되겠다.

켄트 벡의 책이 나왔을 당시만 하더라도 TDD를 뒷받침해주는 도구, 책, 프레임워크 등이 부족해 뭔가를 제대로 해보려면 애로사항이 꽃을 피웠는데, 이번 'TDD 실천법과 도구'를 읽으면서 정말 세상 좋아졌다는 생각을 다시 한번 하게 되었다. 물론 여전히 TDD는 모든 분야에 적용 가능한 만능 도구가 아니라는 사실은 변치 않았지만 (마음만 굳게 먹는다면) 예전보다는 실제 개발에 도움을 주는 수준에 이르렀다고 봐도 틀림없겠다. 목(mock)을 만들기 어려운 상황이나 유지 보수의 일환으로 설계/개발 관점의 테스트가 아니라 테스트를 위한 테스트 자체에 집중하는 상황에서는 TDD를 도입하기는 어렵겠지만, 복잡하고 급변하는 비즈니스 논리가 주도하는 분야에서는 TDD가 짧은 호흡으로 모듈화 수준이 높은 고품질 제품 양산에 적합하리라고 본다(라고 쓰고 실제 적용은 끈기와 집념과 노력이 필요하다고 읽는다).

서론이 너무 길었나? 이 책은 초급 개발자의 학습을 고려하면서도 최근에 나온 여러 가지 TDD 관련 도구를 레퍼런스 형태로 정리해 중급 개발자에게도 도움을 줄 수 있도록 설계되어 있다는 점에서 높은 점수를 줄 수 있다. 단순히 예를 위한 예로 끝나지 않고 실제 개발 과정에서 고려해야 하는 각종 패턴을 소개하고 다양한 패턴에 맞춰 사용 가능한 라이브러리의 장단점과 한계를 비교 정리하고 있기에 자료를 찾고 검토하는 시간도 절약해주며 삼천포로 빠지는 시행 착오를 줄이는 효과도 기대할 수 있다.

목차를 보면, 1, 2, 3장까지는 예를 들어가며 TDD를 실습하는 내용이며, 4장은 TDD에 있어서 아주 중요한 Mock 객체와 프레임워크를 설명하면서 기본적인 TDD 설명을 마친다. 5장은 데이터베이스 테스트, 6장은 단위 테스트 지원을 위한 라이브러리를 소개한다. 그리고 7장은 개발 영역에 따른 TDD 작성 패턴을 다루며, 8장과 9장은 TDD에 대한 시각과 FAQ를 정리한다. 마지막으로 10장은 간단한 실습 예제를 제공하며, 11장과 부록 A는 테스트 자동화와 고급 기능 등을 정리해 나머지 공부가 가능하도록 배려하고 있다. 개인적으로는 7장이 가장 흥미로웠다. 일반적인 애플리케이션, 웹 애플리케이션, 데이터베이스라는 세 분야에 대해 TDD를 어떤 식으로 적용할지를 솔직 담백하게 풀어쓰고 있으므로 TDD를 적용할 곳과 적용하지 않을 곳을 판단하기 위한 좋은 기준을 제공한다. (비단 IT뿐만 아니라 다양한 분야에서) 인터넷에 올라온 글이나 책에서 특정 개념을 설명할 때 혼자 up 되어 장점만 마구 나열하는 경우를 종종 보게 되는데 이 책은 문제점이나 단점도 제대로 찍어주기 때문에 중립적인 시각으로 TDD를 바라볼 수 있게 해준다. TDD를 둘러싼 Context 0라는 한계를 얼른 파악하고 싶은 성질 급한 개발자라면 FAQ 부분을 먼저 읽어보면 좋을 것 같다.

이 책은 홈페이지도 구글 코드에 호스팅하고 있으므로 구입 전에 샘플 챕터를 읽어볼 수 있으며, 책을 읽는 도중에 오탈자, 예제, 보너스 내용, 링크 등을 온라인에서 확인할 수도 있다.

백문이 불여일견이라 애자일과 TDD에 관심이 많은 분들이라면 일단 지르고 보시라.

EOB

토요일, 9월 08, 2012

[독서광] 멋진 징조들

오늘은 재미있는 SF 소설 하나를 소개하려 한다. 호사가들이라면 혹시 들어봤을지도 모르는 '멋진 징조들'(영어 제목은 'Good Omens')가 바로 오늘의 주인공이다. 이 책은 주인공들 좌충우돌이랑 썰렁한 영국식 유머랑 독특한 세계관등이 마치 HHGG를 연상하게 만든다. 물론 드라마, 영화화로 인해 지명도가 하늘 꼭대기까지 올라가 열성적인 팬들을 몰고 다니는 HHGG랑 비교하기가 곤란한 점도 있지만 나름 틈새를 노리는 재미있는 소설이라는 생각이다.

이 책은 다양한 패러디(책, 영화, 음악 등 틈만나면 이리 뒤틀고 저리 뒤튼다), 썰렁한 농담, 영국 작가답게 미국을 은슨슬쩍 디스하는 풍자스러운 표현, 종교적인 표현 등등으로 인해 이해가 쉽지 않았다(여러 번 읽어도 마찬가지가 아닐까 싶기도 하다). 영미문화에 조예가 깊은 분이라면 포복절도하는 부분도 많으리라고 추측만 하는 부분이 많아(응?) 위키피디아의 Good Omens를 뒤져보기도 했지만 별다른 소득은 얻지 못했다. 오히려 영문 블로그에 이 책을 다루는 내용이 많긴 한데, 다들 오덕스러운 문장력을 자랑하기에 책만큼 어렵다는 문제가 있었다.

내용이 아주 궁금하신 분들을 위해 스포일러 없는 줄거리를 간략하게 정리하자면, 적 그리스도로 태어난 아이를 놓고 지구 생활에 동화되어버린 악마와 천사가 은근슬쩍 협력하며 중화(?)시켜 지구 멸망을 막으려는 좌충우돌 이야기다. 4부작 드라마로 만들어진다는 이야기도 있는데(이미 만들어졌나?), 나름 골수팬들 끌어모을 수 있는 화력을 발휘하리라는 생각이다. 요즘이야 워낙 기술이 발전해서 이 책에서 묘사하는 인물이나 장면 정도는 어렵지 않게 시각적으로 그릴 수 있을테니 너무 심각하게만 접근하지 않으면 나름 재미있을 것 같다.

예고) 벌써 9월도 중순으로 접어드는데, 가을을 맞이해 '테마 있는' 독서광이라는 캐치프레이즈를 내걸고 내주부터 애자일 특집 서평을 연속으로 3회에 걸쳐 올려드리겠다. 꾸벅.

EOB

토요일, 8월 25, 2012

[독서광] 창조자들

한 동안 경제/경영 블로그 카테고리에 거미줄이 쳐진 상태라 대단히 죄송한 마음에 오늘은 제목부터 있어 보이는 '창조자들'이라는 아주 재미있는 책을 여러분들께 소개하려 한다. 간략하게 요약하자면, 이 책은 역사상 아주 유명한 인물 17명을 골라내어 창조적인 작품(글, 그림, 음악, 건축, 옷, 영화, 등등)을 만들어내기 위한 이들의 내/외적인 투쟁을 다루고 있다. 일반적인 책과는 달리 어두운 이면을 적나라하게 드러내므로 어릴적 위인전을 읽고 이미지가 굳혀진 위대한 사람들에 대한 환상을 아직도 동경하는 분들이라면 독서 과정에서 대단히 곤란한 느낌을 받을지도 모르겠다.

이 책에서 다루는 사람들이 누군지부터 살펴보자. 제프리 초서(영문학), 알브레히트 뒤러(인쇄술), 윌리엄 세익스피어(영문학), 요한 제바스티안 바흐(음악), 조지프 밀러드 윌리엄 터너/가쓰시카 호쿠사이(풍경화), 제인오스틴(영문학), 오거스트 웰비 노스모아 퓨진/외젠 비올레르뒤크(고딕식 건축), 빅토르 위고(영문학), 마크 트웨인(영문학), 루이스 컴퍼트 티퍼니(유리 공예), 토머스 스턴스 엘리엇(영문학), 크리스토발 발렌시아가, 크리스티앙 디오르(패션), 파블로 피카소/월트 디즈니(미술). 일단 등장하는 주인공을 놓고 봐도 만화 영웅들을 왕창 모아 히트친 어벤저스는 저리 가라 수준이다. 하지만 이들의 숨겨진 이야기를 읽다보면 정말로 기도 안 찰 상황이 된다.

예를 들어, 피카소 편에 나오는 일화를 볼까?

그는 자신에게 여자라는 존재는 "여신 아니면 현관 깔개"라 했고, 자신의 목적은 여신을 현관 깔개로 만드는 것이라고도 했다. 그와 오랫동안 함께 지낸 정부 한 사람은 그를 이렇게 평가했다. "그는 우선 여자를 겁탈하고 ...... 일을 시작한다. 나에게든 다른 여자에게든 항상 똑같다."

빅토르 위고는 또 어떻구... T_T

"이걸 잡아 보렴, 꼬마야. 이 나이치고는 흔치 않은 물건이지. 나중에 네 손자에게 말해줄 수 있을 게다. 네 작은 손으로 시인 빅토르 위고의 물건을 만졌다고!" 그러더니 잠옷을 내리고 복도를 따라 먹이를 찾아 성큼성큼 걸어갔다.

T.S 엘리엇도 (위고나 피카소의 반대편에서) 결코 만만치 않은 삶을 살았다. T_T

엘리엇은 자기보다 나이가 약간 많고 글쓰기와 그림 그리기를 소원하는 영국 숙녀 비비언 헤이 헤이우드와 결혼했다. 어떤 면에서는 개인적 불행이었고, 또 다른 면에서는 생산 활동의 자극제이자 앞으로 남은 삶을 규정하는 사건이었다. 비비언은 못생긴 여자는 아니었지만 육체적으로나 정신적으로나 허약한 사람이었다. 늘 어딘가가 아프기 시작하거나 실제로 아프거나 병에서 회복 중이거나 셋 중 하나였다. 엘리엇도 건강했던 때가 한번도 없었으며, 탈장 방지대는 성생활뿐만 아니라 일상 생활에도 늘 장애가 되었다. 결혼 초부터 두 사람은 경쟁하듯 우울증에 시달렸다.

뭐 이런 눈물나는 내용도 있지만, '바흐'편은 "괴델, 에셔 바흐"나 바흐 이전의 침묵에서 밝혀지지 않은 또 다른 흥미로운 이야기를 전달해준다. 바흐는 실내악에서 새로운 분야를 개척해 하프시코드와 첼로를 독주가 가능한 악기로 승격시켰고, 살아 생전에 발표한 아홉 편 이외에 현존하는 1200 편과 소실되었을 것으로 추정하는 400~500 편의 음악을 작곡한 사실은 알려져 있지만, 이 책을 읽다보면 자신이 오르간 전문가(연주자 뿐만 아니라 제작자)라는 장점을 살려 당대 최고 수준의 오르간 음악을 작곡할 수 있었고, 오르간을 연주하기 위한 레지스터레이션 방법을 평생 연구하며 이를 토대로 학생들을 훈련시켰고, 음악적인 완성도를 추구했지만 당대에는 현학적인 작곡가로 치부되고, 그 결과 유족들에게 남겨진 재산은 거의 없다는 사실도 알 수 있다. 하지만 '바흐 이전의 침묵'에도 나오지만 나중에 멘델스존이 고모할머니 이야기를 듣고 찾아낸 '마태 수난곡'이 대박을 치면서 업적이 완전히 재평가되는 계기가 마련되고 아직까지도 영원 불멸의 작곡가로 남아 있는 모습을 보면 사람 일은 알 수 없다. 바흐가 얼마나 대단한지는 이 책에 나오는 다음 문장으로 설명이 가능한 듯 싶다.

바흐의 작품에서는 시류에 편승하는 반복이나 적당히 손쉽게 넘어간 부분, 하다못해 비속한 낌새조차도 찾을 수 없다. 공연을 할 때도 작곡을 할 때도, 날이 바뀌고 해가 바뀌어도, 심지어 고용주가 흔히 그렇듯 좋고 나쁜 것도 구별하지 못하는 이류라 할지라도 그는 최고의 음악을 선보였다.

실존 인물인지 아닌지 아직도 논쟁이 분분한 세익스피어 이야기도 재미있다. 뛰어난 문학 작품은 말할 나위 없고, 영어 표현력을 몇 배로 높이고 혼자서 새로운 단어를 3000~6000개 창조한 세익스피어가 얼마나 대단한지는 이 책에 나오는 다음 표현을 보면 고개가 끄덕일 테다.

우리는 세익스피어의 보석 상자에 있는 말들을 의식적으로 인용하기보다는 기억해 두었다가 본능적으로 꺼내 쓴다. 우리는 마치 숨을 쉬듯 '햄릿'을 인용한다.

bandit, rubbish, charmingly, tightly, uncomfortable, unaware, undressed, unpolished, uneducated, unpruned, untrained, affecting, anchovy, weather-bitten, well-ordered, wormhole, well-read, widen, cerements, silverly와 같은 단어가 모두 세익스피어가 새로 만들었다는 이야기를 듣고 깜짝 놀랐다. 세익스피어는 16세기 사람이니, 국어 시간에 배운 고어 수준인 단어가 이리도 세련되어 있다는 사실이 믿겨지지 않은 정도다. 단어도 단어지만 세익스피어가 쓴 희곡에 나온 세련된 표현은 더욱 놀랍다. 본문에 나오는 햄릿의 예를 잠시 살펴 볼까?

"제가 설치한 폭탄에 제가 당한다." "신은 왕의 주변에 울타리를 치는 법.", "준비가 전부지", "누더기를 걸친 왕", "시대의 추상적이고 짧은 연대기", "죽음이라는 잔인한 병사가 틈을 주지 않고 붙잡아 가다.", "냄새가 하늘을 찌르는군"

한국어로 번역한 문구만 봐도 진짜 대단한데, 영어로 그것도 16세기 공연장에서 이런 표현이 나왔을 때 마치 코카콜라 이미지 광고가 처음 등장했을 때만큼이나 센세이션을 불러일으켰을 것 같다. 언제 세익스피어 희곡을 차분히 다시 살펴봐야겠다는 생각이 들었다.

결론: 주변 상황을 벗어나거나 이용하거나 극복하거나 ... 어찌되었든 새로운 분야를 개척하는 위대한 사람들의 이야기를 좋아하는 분들이라면 이 책을 놓치지 마시길...

EOB

일요일, 8월 19, 2012

[독서광] Mercurial: The Definitive Guide

소시적에 RCS(Revision Control System)부터 시작해 CVS를 찍고 SVN(Subversion)을 거쳐 요즘에는 분산 버전 관리 시스템인 Hg(라고 쓰고 mercurial이라 읽는다)를 사용하고 있다. 전사(응?)적으로 사용하기 시작한지 6개월이 넘었기에 회사 내부에서는 어느 정도 사용이 정착되었다고 보지만 단순한 중앙집중식 버전 관리 시스템에 비해 여전히 배우고 익혀야할 내용이 많다는 생각이다. 오늘은 오라일리에서 나온 Mercurial 서적인 'Mercurial: The Definitive Guide'를 읽고 느낀 점을 정리해보겠다.

요즘 들어 아주 좋은 컴퓨터 관련 도구와 기술이 적극적으로 공개되고 있는데, 그 만큼 보고 듣고 읽고 익혀야할 내용도 많아져서 인지적인 과부하가 걸리는 상황이다. 개발자에게 있어 가장 중요한 무기인 코드 관리 시스템 역시 발전에 발전을 거듭해 요즘에는 git가 견고한 SVN의 벽을 허물고 주류로 등장하는 상황이다. 특히 소셜 코딩을 기치로 내걸고 등장한 긱스런 회사인 github가 뜨면서 git에 대한 관심이 무척 높아지고 있다. 하지만 git 사용법은 절대로 쉽지 않다. 원래 리눅스 커널 관리를 위해 만든 시스템이다보니 메인테이너의 편의성을 극대화한 측면이 많기 때문이다. 복잡한 명령 구조와 시나리오에 따른 활용법을 익히지 않고서는 git도 또 하나의 백업 시스템으로 전락할 가능성이 높아보인다. 그렇다면 RCS와 git라는 양 스펙트럼 사이에 적절한 타협점은 없을까? B급 프로그래머 생각으로는 hg가 어느 정도 해법을 제시한다고 본다. git보다 자유도와 기능이 떨어지지만 꼭 필요한 기능은 빠짐없이 제공하며, svn보다 배우기는 어렵지만 유연성이 아주 높고 다양한 버전과 브랜치를 손쉽게 관리할 수 있다는 특징으로 인해 일단 DVCS를 적용하려는 조직에 적용하기 좋다는 장점이 있다. 게다가 git와는 달리 Hg는 유닉스/맥은 물론이고 윈도우와도 아주 친하다(이게 무슨 소리인지는 git를 윈도우에서 직접 사용해보면 바로 알게 된다. ㅋㅋ)

기존 SVN 사용자를 위해 Hg의 특징을 간략하게 정리해보자면, 가장 큰 차이점은 모든 개발자 PC(클라이언트)가 서버가 될 수 있다는 점이다. 중앙 집중식 아키텍처로 설계된 SVN과는 달리 Hg는 모든 이력을 클라이언트마다 다 들고 있고, 필요에 따라 밀고(push), 당기는(pull) 방법으로 중앙 저장소로 지정한(OnDemand로 bitbucket.org와 같은 온라인 서비스에 호스팅을 해도 되고, 내부에 직접 서버를 꾸려도 무방하다) 서버에(서) 변경된 이력을 가져오고/내보낸다. 이렇다보니 SVN과는 달리 커밋을 하더라도 중앙 서버에 반영되는 대신 지역 클라이언트 쪽에만 반영되기 때문에 개발자가 소스 코드를 지역적으로 관리하는 책임과 의무가 커진다. 물론 책임과 의무가 있는 대신 자유도가 높아지므로, 개발자는 자기 페이스에 맞춰 여러 커밋을 한 단위로 묶어 중앙 서버에 반영시킬 수 있으므로 여러 명이 동시에 작업하는 과정에서 빌드를 깨먹거나 버전이 이리저리 뒤엉켜 관리하느라 난리가 날 확률이 줄어든다. 개발자가 1~2명이라면 SVN으로 충분하지면 3~4명만 되더라도 Hg와 같은 DVCS를 사용하는 편이 생산성을 급격하게 높일 수 있으므로, 어느 정도 규모가 되는 프로젝트를 진행하기 앞서 버전 관리 시스템을 선택할 때 반드시 git나 hg도 고려 대상에 넣으면 좋겠다.

서론이 너무 길었다. 상용 Hg 서버인 Kiln을 만든 조엘 스폴스키가 작성한 튜토리얼인 Hg Init: a Mercurial tutorial를 읽었다면 그 다음 차례가 바로 Mercurial: The Definitive Guide가 아닌가 싶다. 오라일리에서 책을 구입할 수도 있고 앞서 소개한 홈페이지에서 전자책 형태로도 읽을 수 있으므로, 아이패드나 킨들이 있는 분들에게는 멋진 선물이 될 것 같다. 이 책은 Hg에서 가장 중요한 기능을 중심으로 실제 예를 들면서 설명을 전개해 나가므로 바로 적용할 수 있다는 장점이 있다. 물론 기존 CVS나 SVN을 제대로 활용하고 있던 사용자일지라도 새로운 설계 사상과 개념으로 인해 직접 해보지 않고서는 도저히 감을 잡기 어려운 난관이 있으므로 책과 실습을 병행하는 방식을 강력하게 추천한다. 목차를 보면 알겠지만, Hg의 튜토리얼은 2장과 3장에서 끝나고 4장부터는 본격적인 설명으로 들어가기에 DVCS 개념이 안 잡힌 독자라면 조엘이 작성한 튜토리얼을 먼저 읽는 편이 정신 건강에 이롭다는 생각이다.

B급 프로그래머 생각에 이 책에서 가장 중요한 부분은 4장이다. Hg를 사용하다보면 (심지어 복잡하게 브랜치나 릴리스 관리를 하지 않더라도) 내부 동작 방식을 반드시 알아야 하는 사태가 발생하기 마련이다. 예를 들어, 열심히 코드를 고친 다음 커밋을 하고 중앙 서버에 push를 하려 했는데, 갑자기 중앙 서버가 거부를 하는 상황에서 pull을 해서 다른 사람이 변경한 내용을 가져온 다음 이를 하나로 합쳐야 하는데, 완전히 orthogonal한 작업(예: A는 a.c를 고쳤고 B는 b.c만 고친 경우)에도 merge를 해야 한다는 사실이 처음에는 도저히 이해가 가지 않을지도 모른다(물론 rebase라는 확장(이라고 쓰고 야매라고 읽어야지)을 사용하면 지역 클라이언트에서 일어난 변경 내용을 잠시 분리해 중앙 서버의 내용을 선 반영한 다음에 그 위에 변경 내용을 반영하므로 merge를 회피할 수 있다). 게다가 update 명령이 클라이언트 코드 저장소와 현재 작업 디렉터리를 동기화한다는 사실을 모르고 pull만 해놓은 다음에 tip이 과거 parent를 가리킨다는 사실을 인지하지 못한 상태로 실컷 코드를 고친 다음 commit할 때 발생하는 거부 상황(해법은? update하고 나서 펑펑 터져 나오는 충돌 상황을 적절히 풀면 된다.), -F 옵션을 사용해 강제로 push해 새로운 head를 만들고 나서 동료들이 어떤 head가 작업 대상인지 몰라 우왕좌왕하는 모습(해법은? head 둘을 merge하면 된다. 참 쉽죠?) ... SVN 세계에서는 찾아보기 어려운 멘탈 붕괴 상태에서 잘 빠져나오려면 4장에 나오는 그림과 시나리오를 여러 번 읽어 충분히 숙지한 다음에 실전으로 뛰어드는 편이 좋겠다. 그리고 처음 Hg를 접하는 분들께는 9장도 많은 도움이 될 것 같다. 사용하다보면 분명히 문제는 생기기 마련인데, 9장은 자주 일어나는 현상(이라고 쓰고 문제점이라고 읽어야지...)과 해법을 제시하고 있으므로 평상시에 잘 숙지해두면 나중에 실수를 적게하고 설령 실수를 하더라도 정석대로 빠져나올 수 있게 된다.

책을 한 번 읽고서는 감이 _전혀_ 오지 않을 수도 있으므로, 일단 실제 작은 프로젝트(테스트용)에 적용한 다음에 다시 한번 책을 읽어보면 그 때 아하!하고 깨닫는 바가 클 것이다. 이렇게 말하는 B급 프로그래머도 다시 한번 천천히 본문을 정독해봐야겠다. 낄낄...

EOB

토요일, 8월 11, 2012

[독서광] 위대한 게임의 탄생 2

오늘은 지난번에 소개드린 위대한 게임의 탄생의 후속편인 위대한 게임의 탄생 2편을 읽고 느낀 점을 정리해보겠다. 1편은 외국 게임 회사들의 포스트모르템을 다루고 있는데, 2편은 동일한 구성과 전개 방식으로 한국 게임 회사들의 포스트모르템을 다루고 있으므로 현실성이 더욱 높다는 장점이 있다. 아무래도 잉여력이 충만한 외국 회사들에 비해 모든 것이 부족한 한국 회사들 이야기가 이 분야의 현실을 더욱 정확하게 반영하기 때문이리라...

본문 내용을 살펴보면 1부에서는 국내에서 출시된 게임 개발 후기를 정리하고(총 18개), 2부에서는 위대한 게임 개발팀의 공통점을 다룬다. 3부는 '위대한 소프트웨어의 탄생'이라는 제목을 붙여 게임이 아닌 일반 소프트웨어의 포스트모르템을 다루고 있다. 1편과 마찬가지로 직군별 인터뷰가 실려 있어 게임 업계(특히 국내)의 분위기를 파악할 수 있도록 도와준다. 요즘 국내 게임 업계가 큰 어려움을 겪고 있는데(실적 부진, 시장을 이끌만한 새로운 게임 부재, 외산 게임의 약진 등등) 이럴 때일수록 개발 분위기가 망가지지 않도록 개발 문화를 튼튼히 다질 필요가 있다. 이 책이 이런 분위기 쇄신에 조금이라도 도움이 되지 않을까 하는 생각이다.

1편에서 편집이 엉망이라고 투덜거렸는데, 2판에서는 3부가 불만스러웠다. 3부에서 건질 내용은 사실상 게임과 관련이 있는 "게임 엔진 프라우드넷"(이 부분은 앞서 나온 게임과 연결이 되어 있어 무척 재미있게 읽었다)뿐이며 나머지는 모두 사족이다(글이 엉망이거나 내용이 틀렸다는 이야기 절대 아니다!). 차라리 3부에서도 게임 관련 내용만 다뤘으면 훨씬 좋을뻔 했다는 생각이 든다. 왜 이런 현상이 생겼는지를 생각해봤는데, i) 게임과는 달리 일반 소프트웨어 개발은 컨텐츠나 시각화보다는 요구 사항과 업무 논리 중심으로 돌아가므로 1부와 큰 격차를 보이며, ii) 게임에서 사용하던 구성과 전개 방식이 일반 소프트웨어에서 제대로 먹혀 들어가지 않기 때문이라고 추정해본다. 만일 출판사에서 '위대한 소프트웨어의 탄생'이라는 책을 기획하고 있다면 '위대한 게임의 탄생'과는 완전히 다른 접근 방법을 사용해야 하지 않을까 하는 생각이다(이렇게 말을 하지만 소프트웨어 분야가 워낙 다양하고 제각각이라 딱히 일반적인 해법은 없어보인다).

이 책을 읽다보니 한국 개발 문화의 고질병은 게임 업계에서도 일상다반사로 등장한다는 사실(아마 다른 개발 부문에 비해 더했으면 더했지 결코 덜하지 않을 것이다)을 알 수 있었다. 끝없는 야근에 특근이 따라다니는 크런치 모드야 만국 공통 현상이니 뭐 그렇다고 치더라도, 자본과 경험 부족으로 인해 망가지는 이야기가 (순화되어) 본문에 자주 등장하는 모습을 보고 있으니 가슴이 아팠다. 현실은 현실이니 냉정하게 인정하고 넘어가야겠지만, 경쟁력 악화라는 경고등이 켜진 듯이 보여(그리고 일부는 이미 현실화되고 있다) 눈앞이 캄캄해진다.

어려운 현실에서도 묵묵하게 사람들이 좋아하는 게임을 만드는 우리 게임 개발자들 모두 힘냅시다!

EOB

토요일, 8월 04, 2012

[일상다반사] 재즈를 좋아하는 당신께...

재즈를 좋아하는 독자분들께 좋은 소식이 한 가지 있다. 오는 17일부터 19일까지 포항 칠포 해수욕장에서 국제 재즈 페스티벌이 열린다고 한다. 수도권이면 아주 좋겠지만, 그래도 프로그램 내용을 보면 구미가 당기리라는 생각이다(참고로, 재즈에 엄청 조예가 깊으신 예술 감독님이 B급 관리자 대학교 시절 룸메이트라는 사실... ㅋㅋ).

저렴한 입장료(눈물날만큼 저렴하다)에 막강한 뮤지션들의 조합이니 (특히 포항에 계신 분들... 누구라고 특정 안 해도 다들 잘 아시겠죠?) 무덥고 짜증나는 더위를 시원하게 날려버리시기 바란다.

EOB

토요일, 7월 28, 2012

[독서광] 위대한 게임의 탄생

고맙게도 박일님께서 책을 보내주셨기에 정독을 기념해 블로그에 소감을 정리해보겠다. '좋은 게임을 넘어 위대한 게임으로'라는 부제가 붙은 이 책은 성공적인 게임 제작 완료 이후에 진행한 사후분석(postmortem) 내용을 담고 있으며, 잘된 점과 잘못된 점을 실제 사례를 들어 소개한다. post mortem의 원래 뜻은 after death지만, 엔지니어링 분야에서는 특정 프로젝트가 끝나고 나서 수행하는 과정으로 성공한 부분과 실패한 부분을 파악해 다음 번 프로젝트에 도움이 되도록 정리하는 행위를 일컫는다. 이 책은 물론 게임 분야에서 사후 분석을 수행하기 때문에 여기서 얻은 교훈을 게임이 아닌 다른 IT 프로젝트에 100% 적용하기는 어렵지만 그럼에도 불구하고 건질 내용이 많다는 생각이다.

이 책은 게임에 문외한인 사람조차도 한번 쯤 들어본 유명한 게임(설마 WoW, 하프-라이프 2, 팜빌 등을 모르는 분이 계실까? ㅋㅋ)을 만든 핵심 개발자들의 목소리를 싣는 1부, 성공적인 게임 프로젝트에서 볼 수 있는 원칙을 분석한 2부, 국내 사례를 정리한 3부로 나뉘어진다. 또한 책 중간 중간에는 게임 제작 과정에서 직군 별로 인터뷰한 내용을 담고 있으므로 게임 산업에 뛰어들고 싶어하는 지망생이나 도대체 내가 뭘하고 있지라고 멘탈 붕괴 상태에 빠진 현업들에게 자극제를 투입하므로 또 다른 재미를 준다. 기획과 내용에 비해 책 편집 상태는 난감한데, i) 회사와 사람 이름을 영어로 그대로 두고, ii) 직군별 인터뷰에 사용한 폰트 가독성이 바닥을 기고 있기에 독서 과정에서 애로사항이 꽃폈다. 다행스럽게도 후속편인 '위대한 게임의 탄생 2'를 펼쳐보니 두 가지 문제점이 모두 해결되었는데, 이 책 역시 증쇄 과정에서 문제점이 수정되면 좋겠다는 생각을 잠시 해본다. 3부 국내 사례는 손발이 조금 오그라 붙는 내용(특히 스페셜 포스 2 T_T)도 들어 있기에 1, 2부를 읽고나서 급격히 상승한 기대치에는 미지치 못했다. 아쉬움을 달래기 위해 한국 회사들만 다루는 후속편을 읽고 독후감을 올려보겠다.

자 그러면 본문 중에서 재미있는 내용을 정리해볼까?

소수의 사람들이 끊임없이 기술을 연마하면서 다른 것을 시도해볼 수 있는 멋진 스튜디오를 만들고 싶었습니다. 물론 제품을 출시해야 하고 마일스톤을 지켜야 합니다. 안 그러면 그냥 신나기만 할 뿐 엉망진창이 될 겁니다.
야망이 있는 용삼한 사람은 결코 만족하지 않습니다.
일관성과 실험정신, 이 두 가지는 흥미롭기는 해도 서로 잘 맞진 않았습니다.
어려운 것을 먼저 하세요. 진전을 보여 달라는 압박을 심하게 받다 보면 양은 많고 쉬우면서 근사해보이는 일부터 먼저 하고 싶은 유혹을 받지요. 하지만 이러면 백발백중 문제가 터집니다. 좀 더 복잡한 문제를 먼저 달려들어 해결하려고 노력해야 합니다.
프로그래머들 관리하기가 '수십 마리 고양이 떼를 몰고 다니기'만큼 어렵다고 했습니다.
디자인을 할 수록 먼저 디자인한 것 위에 디자인하게 된다. 디자인을 구현해 사람들에게 보여줌으로써 검증할 수 없다면, 이런 검증 안 된 디자인에 기반해서 나온 모든 디자인에 문제가 될 수 있다.
핵심 기능 이외에는 전부 잘라내는 것이 게임의 품질을 극대화하는 최고의 방법입니다.
사람들이 서로를 믿고, 기회를 주는 문화를 만들어 왔고, 앞으로도 만들어 가려고 합니다. 이게 사실 굉장히 어렵습니다. 사람들이 서로를 신뢰하여 위험을 무릅쓸 수 있고, 뒤통수 맞지 않을 거라는 확신이 서야만 이런 문화가 가능합니다.
많은 문제가 결국 의사소통의 실패에서 비롯되는데, 팀의 규모가 작으면 훨씬 효율적으로 의사소통할 수 있기 때문에 당연한 결과라고 할 수 있다.
특별한 결과물을 원한다면 자신의 일을 절대적으로 사랑하는 사람들과 함께 일해야 합니다.
요즘 같은 경쟁 사회에서 다른 모든 조건이 같다면 다른 사람들보다 더 열심히 일하는 개발팀이 길게 놓고 봤을 때 더 유리할 것입니다.
보통 사람들과 달리 예술가는 예술을 보면서 무엇을 훔쳐 배울 수 있을까를 생각한다.
꽤나 당연하면서도, 규모에 상관없이 첫 번째 게임을 개발하는 모든 개발사에서 공통적으로 하는 실수는 실제 작업량을 과소평가한다는 것이다. 창조에 드는 노력에는 시간이 들고, 보통 생각하는 것보다 훨씬 많은 시간이 필요하다.
타협은 하지 마라. 하지만 가고자 하는 곳에 더 빨리 갈 수 있는 지름길이 있는지 살펴보자.
게임의 첫 1분은 가장 많은 사람들이 경험하는 부분이기 때문에 무엇보다 중요하다.
솔직히 너무 심하게 테스트를 많이 하는 경우는 없다.
변경을 위한 변경을 하지 마라. 하지만 꼭 필요하다면 바로 바꿔야 한다.
유능하고 창조적인 개발팀의 특징은 솔직함과 자기반성이다.
세상 일이 다 그렇듯, 고정 불변의 법칙은 없다. 어떤 팀에서 잘 되던 것이 다른 팀에서는 잘 안 될 수도 있다. 사실 이전에 잘 되던 것을 다음 프로젝트에서 똑같이 적용해도 잘 안 될 수 있다. 환경적 요인이나 경제적 요인, 사적 문제 같은 모든 요소가 프로젝트 결과에 큰 영향을 미친다.
분명하고 잘 공유되며, 측정 가능한 목표는 유능한 개발팀의 특징 중 하나다.
당장 문제가 있더라도 유능한 팀을 최대한 그대로 유지하는 편이 좋다.
너무 안 듣는 것보다는 차라리 너무 많이 듣는 것이 낫다.
열정을 따라라, 위험을 무릅쓰고 대박을 위해 뛰어들어라, 이게 유능한 개발팀이 하는 방법이다. 어차피 한 번 사는 인생 아닌가?
게임 프로젝트가 결혼이면, 컨셉 단계는 연애 기간이라고 볼 수 있다.

위 내용을 보면 감이 오겠지만, 이 책은 게임 업계 뿐만 아니라 전통적인 분야에서 일하는 소프트웨어 개발자들에게도 풍부한 생각 거리를 던지고 있으므로 살아 움직이는 역동적인 개발팀을 만들어 여기서 일하고 싶어하는 분들에게 필독을 권한다. 좋은 이야기만 하는 일반적인 소프트웨어 공학 서적에 지친 분들에게 이 책을 강력하게 추천한다!

토요일, 7월 21, 2012

[B급 프로그래머] What's the single most valuable lesson you've learned in your professional life?

Quora를 보다가 흥미로운 내용이 있어 소개한다. 질문은 다음과 같다.

What's the single most valuable lesson you've learned in your professional life? We all hit some walls during our careers. What's that one lesson you'll never forget?

한글로 번역하자면 다음과 같은 질문 정도가 되겠다.

전문 경력을 쌓으며 배웠던 가장 가치있는 교훈을 하나만 들면 뭐가 될까요? 경력을 쌓다보면 벽에 부딪히기 마련입니다. 절대로 잊어버리지 않을 교훈을 하나만 든다면?

이번에도 쿠오라에 근무하는 엔지니어가 좋은 대답을 했기에 간략하게 요점을 정리해보았다.

레버리지, 즉 생산성을 높이기 위한 방법은 크게 세 가지가 있습니다.

  • 특정 과업(활동)을 완료하기 위해 들이는 시간을 줄인다
  • 특정 과업이 미치는 영향력을 늘인다
  • 레버리지가 좀더 높은 과업으로 전환한다

그 중에서 레버리지를 높이기 위한 몇 가지 과업을 소개하면 다음과 같습니다.

  • 신입 직원에 대한 멘토링: 멘토링은 엄청나게 레버리지가 높은 과업입니다. 보통 직원들은 연간 1880시간에서 2820시간 동안 일합니다(47주를 가정). 매달 1시간 씩 20시간을 투자해 신입을 멘토링하거나 코치하는 방식은 시간을 많이 소모하는 듯이 보입니다. 하지만 이는 단지 신입 직원이 1년 동안 근무하는 전체 시간의 1% 정도에 불과하며, 나머지 99% 시간 동안 생산성과 효율성에 엄청난 영향을 미치게 됩니다.
  • 반복적인 작업을 자동화하는 도구 제작: 소프트웨어 공학 배경에서 바라보면, 레버리지가 높은 활동 중 하나는 지루하고 반복적인 수작업을 줄이는 도구 제작입니다. 한쪽으로 조금 치우쳤다고 생각이 들지도 모르지만, 저는 모든 사람이 코딩에 대해 조금씩 알고 있다면 이익을 얻으리라고 믿는 사람입니다. 자동화라는 마인드가 엄청난 효율을 얻는다는 신념으로 뭉친 컴퓨터 과학과 전통적으로 무관한 분야에서 특히 좋은 효과를 발휘합니다. 컴퓨터가 당신을 위해 해줄 수 없는있는(오타 지적해주신 성큼이님께 감사. :)) 일은 하지 마십시오.
  • 배우고 끊임없이 개선하는 작업에 대한 투자: 스티븐 코비가 '성공하는 사람들의 일곱가지 습관'에서 언급한 중요하지만 급하지 않은 과업에 속합니다. 학습은 급한 과업처럼 보이지 않으며, 별도로 시간을 잡아 놓지 않으면 일정을 지시하는 중요하지 않은 방해의 희생양이 됩니다. 하지만 학습은 생산성을 높이고 좋은 기회를 얻을 가능성도 높입니다. 따라서 레버리지가 큰 과업입니다.
  • 추정된 영향력에 기반한 적극적인 우선순위화: 다음에 진행할 가장 영향력이 높은 일을 결정하는 과정에서 완료할 필요가 있는 작업을 주기적으로(보통 일주일) 검토하며 의사 결정을 이끌 자료를 수집하고 방법을 사용합니다.
  • 기술 대화에 참여/새로운 직원을 이끌 지침서 작성: 쿠오라에서는 새로운 직원을 기술 대화에 참여시키고 새로운 직원들에게 일련의 코드랩를 제공합니다. 구글의 교육 방법을 따와서 만든 코드랩은 현재 사용 중인 핵심 소프트웨어 추상화와 개념을 설명하는 문서이며, 설계 근거와 활용 방안을 설명하고 코드 저장소에 들어있는 관련 코드를 탐험하며, 튼튼한 이해를 위한 연습 문제를 제공합니다. 이런 문서는 팀에 속한 수 많은 사람들이 오랜 기간 동안 작성했지만, 확장 가능하며 재사용 가능한 자원을 제공하므로, 새로운 직원들에게 동일한 개념을 가르치기 위해 멘터별로 필요한 시간을 단축하며, 새로운 직원들이 일관성 있는 토대에서 시작하도록 만들어줍니다.
  • 필요할 때마다 오픈 소스 도구 활용: 바퀴를 매번 다시 만들 필요는 없습니다. 누군가 이미 필요한 뭔가를 만들어 놓았다면 말입니다.

뱀다리) 레버리지를 높이기 위한 좋은 충고이지만, 역시 한국적인 상황(월화수목금금금)에서는 잉여력이 문제라는 생각이 든다. 독자 여러분들의 의견은 어떠신지?

EOB

토요일, 7월 14, 2012

[독서광] 구글러가 전하는 IT 취업 가이드

요즘 한쪽에서는(기업) 사람개발자가 없다고 야단법씩인 반면에 다른쪽에서는(개인) 갈만한 좋은 회사가 없다고 야단이다. 좋은(응?) 회사는 손에 꼽을만큼 얼마 되지 않으니 자연스럽게 경쟁이 치열하므로 (자신의 실력으로) 갈만한 좋은 회사가 많다면 그게 더 이상하다는 생각이다. 그렇다면 IT 분야에서 좋은 회사를 들어가는 방법은 무엇일까?

이번에 인사이트에서 새로 나온 '구글러가 전하는 IT 취업 가이드'는 나름 미국 IT 취직 관련 사이트로 유명한 Careercup.com(참고: IT 구직자들에게 이 사이트를 강력 추천한다)을 운영하는 게일 멕도웰이라는 친구가 자신의 경험(애플, 마이크로소프트, 구글)을 토대로 따끈따끈한 경험담을 후배들에게 전달한다. 이제 막 책이 풀렸는데, 언제 다 읽었느냐고? 책 나오자마자 인사이트 담당자분이 직접 배달(?)해주셨고 받자마자 이틀 동안 틈나는대로 300쪽이 넘는 두툼한 책을 정말 열심히 읽고 또 읽었다. 성질 급한 독자분을 위해 요약하자면, 이 책은 어느 정도 틀이 잡힌(즉 HR이 제대로 동작하는) 다국적 IT 기업에 취직하려고 마음먹은 독자를 대상으로 한다.

목차를 보면 알겠지만, 이 책은 이력서 작성부터 시작해 커버레터(간략한 자기 소개글이라고 보면 된다) 작성 요령까지 짚어주고, 전반적인 면접 과정과 주의 사항에 대해 알려준다. 그리고 나서 면접 대응(전화 면접 포함)과 프로그래밍 면접 요령을 자세히 설명한다. 마지막으로 (마치 한국 독자들을 위한 듯이 보이는) 게임 회사 취업 방안과 취업 제안을 받아들이고 뿌리치는 방법, 취업하는 과정에서 연봉이나 처우를 개선하는 방법, 취업 이후 처신 방법을 설명한다. 이제 막 사회에 진입하려는 독자를 대상으로 하고 있기에 시시콜콜 온갖 이야기가 다 나오므로, 실제 경력이 되는 분들 개발자 입장에서 보면 다소 지루하고(다이어트를 하면 200페이지 미만으로 만들 수 있었던 책이라는 생각) 한국 사회에 그대로 적용하기에는 (회사나 개인 모두에게) 문화적인 문제를 일으킬 가능성이 높은 부분이 눈에 띌 수도 있다. 하지만 소위 말해 요즘 잘나가고 있는 IT 업체의 HR 분위기를 생생하게 전달하므로 큰 그림에서 바라보면 개인이나 회사 양쪽 모두에게 충분히 응용 가능한 요소도 많다.

취업이야 (어차피 사람을 뽑아야 하니... 창업한 사람까지도 포함해) 모든 사람들의 관심사이므로 인터넷 교보문고에서 '취업'이라는 단어로 검색해보면 책이 무려 3630권이나 나오는 상황에서 이 책 내용이 우리에게 시사하는 바를 생각해봤는데, 구직 중인 개발자뿐만 아니라 IT 업체의 HR 담당자들이 잘 나가는 외국 IT 업계의 분위기를 파악해 전반적인 HR 수준을 높여야 대한민국의 IT 경쟁력이 한 단계 더 높아지지 않을까싶다. (실력파) 구직자들의 눈높이에 맞추지 않으면 외국 기업에 인재들을 다 빼았기고 뒤에 가서 후회할테니, HR 담당자들과 면접관들이 이 책 내용을 치밀하게 연구하고 벤치마크해 국내 사정에 적합한 좋은 모델을 만들어 대응해야 할 것이다.

힌트: 취업 지망생들은 지금이라도 늦지 않았으니 링크드인(참고: [독서광] START! 링크드인 LinkedIn도 읽어보시길...)에 반드시 가입하기 바란다. 이력서에 링크드인 주소를 넣어두면 제대로 된 HR 담당자라면 반드시 열어본다(페이스북이나 트위터에 접속해 당신의 글을 읽어볼 가능성보다는 비즈니스 마인드와 인맥을 집중적으로 추적할 수 있는 링크드인을 열어볼 가능성이 훨씬 더 높다). 또한, 링크드인 내용은 이 책 내용을 유심히 읽어보고 Careercup.com의 지침을 참고해 영어로 작성하면 더욱 좋다(국내 회사에서 영어 이력서를 무시할지도 모른다는 걱정은 절대 하지 마시라. 토익/토플 점수보다 당신 이력서를 작성한 영어 작문 솜씨에 주목할테니 말이다. 그러니 일단 영어로 칼을 뺐으면 철자/문법 등에 신경 쓰면서 제대로 써야 한다!).

EOB

토요일, 7월 07, 2012

[독서광] 세상을 뒤흔든 특허전쟁 승자는 누구인가?

작년에 출간된 특허전쟁에 이어 이번에 구글과 반 구글 빈영 사이의 특허전쟁을 다루는 후속작이 나왔다. 앞서 나온 특허전쟁이 특허에 대한 지식을 강화시켜준다면 이번에 나오는 '특허전쟁 승자는 누구인가?'는 불확실성을 해소하기 위한 수단으로 특허라는 제도를 글로벌 기업들이 어떻게 이용하는지 실제 사례를 설명하는 교양서라고 보면 틀림없겠다. 따라서 두 책을 같이 읽어보면 특허와 비즈니스 사이의 미묘한 공생 관계를 더욱 확실하게 이해할 수 있다는 생각이다.

집에서 TV로 야구 경기를 시청하다 실제 야구 경기장에 가서 경기를 볼 때 당혹스러운 느낌을 받은 분들이 많으실 것이다(사람들이 야구 경기장에 라디오를 들고 갔고 요즘은 스마트폰이 라디오를 대체하고 있다). 현장에 가면 생동감은 느껴지지만 선수도 낯설고 작전도 한 눈에 안 들어오고 양팀간의 팽팽한 균형을 보기가 어렵다. 이유는 바로 엄청난 골수 야구팬이 아니라면 관전 포인트를 찾아내기가 쉽지 않기 때문이다. 관전 포인트는 현재 경기 뿐만 아니라 직전에 벌어진 경기, 그리고 앞으로 벌어질 경기를 모두 꿰차고 있어야 더욱 풍성해지는 법이라, 아무래도 전문 해설가의 도움이 없다면 파악하기가 극히 어렵다. 이번에 소개하는 '특허전쟁 승자는 투구인가'는 구글을 대리하는 삼성과 구글과 맞서는 애플 사이에 벌어진 특허 소송의 관전 포인트를 잘 짚어주기 때문에 태극기 휘날리는 일반적인 신문이나 IT 잡지 논조와는 사뭇 다르다. 애국심만으로는 설명하기에 상당히 곤란한 부분을 시원하게 긁어주므로 책을 읽는 과정에서 나름 흥미로운 관전 포인트를 찾아낼 수 있었다.

이 책은 단순히 삼성 애플이라는 양대 회사 사이의 소송에서 벗어나 구글 진영(삼성 - HTC - 모토롤라)과 반 구글 진영(애플 - 마이크로소프트/노키아 - 오라클) 사이에 벌어지는 역사상 최대의 특허 전쟁을 다루고 있기 때문에 스케일도 크고 얽히고 섥힌 내용도 많다. 이 책은 특허 제도를 이용해 불확실성을 해소하려는 양쪽 진영의 치열한 법적 공방과 합종 연횡을 보고 있으면 삼국지가 떠오른다. 삼성이 특허 개수가 많음에도 불구하고 특허 소송에서 불리한 이유, 애플이 늘 빠져나갈 공간을 만들어 주면서 삼성을 밀어붙이는 이유, 양사가 결국 서로 싸우면서도 양보하며 자기 영역을 결정해가는 방식, 삼성이 특허 소송에서는 불리하지만 사업적으로는 잘 나가는 이유를 재미있게 설명하고 있으므로, 기업 특허 담당자 뿐만 아니라 세상 돌아가는 소리소문에 관심이 많은 개발자들도 읽어보면 (분명히) 도움이 될 것이다.

이 책을 읽은 직후에 터져 나오는 각종 뉴스(예: 미국, 갤럭시탭 판금 집행정지 요청 기각)를 보니까 확실히 과거와는 다른 시각으로 좀더 넓게 바라보는 자신을 발견했기에 스스로가 기특해지기 시작했다. 낄낄... 책 뽐뿌질이랑 자기 깔때기질은 여기까지. 여러분들도 두 책을 읽어보시고 세상 돌아가는 이치에 대해 (최소한 특허와 사업 관점에서) 혜안을 얻으면 좋겠다.

토요일, 6월 30, 2012

[독서광] 넥스트 S커브

지난번 소개한 엑센추어 시리즈인 기업 소셜미디어 활용 전략에 이어 오늘은 '신성장 창출의 키워드'라는 부제목이 붙은 '넥스트 S커브'를 소개해보려 한다. 에이콘 엑센추어 시리즈는 이론적인 고리타분한 이야기는 빼고 실무에 적합한 알찬 내용으로 꾸며져 있기에, 시리즈가 나올 때마다 바로 한 권씩 보내달라고 출판사에 특별히 부탁한 몇 안 되는 특이한 사례라고 보면 되겠다. 이번에 나온 책 역시 실망시키지 않았기에 기억을 위해 간략하게 정리하고 넘어가려 한다.

우선 책 제목에도 나오는 S커브에 대해 잠깐 설명을 해보자. S커브는 "열성 고객 몇 명으로 작게 사업을 시작해 대중이 신제품을 찾으며 급속도로 성장하다 결국 정점에 이르러 시장이 성숙해지며 평준화되는 흔한 패턴을 뜻하는 용어"라고 보면 된다. 하지만 아파트 재건축과 마찬가지로 S커브 자체는 1회성이라는 문제가 있다. 5층짜리 아파트를 허물고 20층을 지었다고 치자. 다음에는? 게다가 재건축과는 비교하기 힘들 정도로 기업 입장에서 더욱 심각한 문제가 생긴다. 과거의 성공을 계속해서 이어나가기 위해 자원과 역량을 기존 잘나가는 사업에 집중해 최적화와 효율성 추구 모드로 들어가므로 신성장 동력 - 새로운 S커브 -을 시작할 엄두를 내지 못한다. 시장 점유율과 수익율 측면에서 정점을 찍은 회사가 급속도로 쇠락해 역사의 뒤안길로 사라지는 광경을 우리는 얼마나 많이 목격해 왔던가?

이 책은 어느 정도 S커브를 오른 후 계속해서 새 S커브로 갈아탈 줄 아는 하이퍼포먼스 기업의 특징을 분석하고 하이퍼포먼스 기업을 본받아 새로운 S커브로 갈아타는 방법을 소개하고 있다. 물론 불타는 플랫폼(낄낄)이 되어버린 노키아를 비롯해 아이폰과 안드로이드가 사실상 휴대용 게임기로 변신하는 바람에 완전히 치명타를 입은 닌텐도가 이 책에서 소개하는 하이퍼포먼스 기업의 명단에 올라있기에, (산업계의) 미래 예측과 (잘 나가는 기업의) 성공 복제는 지극히 어렵다는 생각이 잠깐 들기는 했지만, 그렇다고 해서 100% 운에만 맡기고 감 떨어지기만 기다릴 수는 없다는 생각도 함께 들었다.

이 책에서는 S커브를 오르는 방법을 '시장 통찰', '확장 전의 기본 역량 확보', '뛰어난 인재가 일할 가치'라는 세 부분으로 나눠 소개하고, 새로운 S커브를 갈아나기 위한 방법으로 재무 성과와 규모에 매몰되 정작 중요한 S커브를 보지 못하는 문제점을 설명하는 '숨은 S커브 식별', 현장의 목소리로부터 혁신이 일어난다는 '가장자리 중심 전략', 구태의연한 자세에서 벗어나 다음 커브에서 살아남을 수 있도록 조직을 이끄는 경영진의 선별 중요성을 강조한 '커브보다 앞서 변화하는 최고 경영진', 인재를 붙잡아두고 계속해서 공급하는 방법인 '인재의 온실'이라는 네 부분으로 나눠 소개한다.

하이퍼포먼스 기업마다 기업이 위치한 맥락이 다르며, 기업 문화와 기업 전략 역시 다르지만 S커브를 연속적으로 갈아타는 방법을 확실히 알고 있다는 점에서는 공통점이 있다고 보면 틀림없다. 일반적인 회사가 페이스 조절이나 커브를 갈아타는 타이밍을 놓쳐 S커브에서 이탈하는 반면 하이퍼포먼스 기업은 기본 역량을 바탕으로 S커브를 계속해서 갈아타는 묘기를 보이며, 시장 통찰력을 바탕으로 예전 역량과 신규 역량을 결합해 차별화된 역량도 이끌어낸다. 일단 기본 역량에 도달하고 나면 하이퍼포먼스 기업은 운영의 묘를 살려 경쟁사가 영향력을 잠식해오기 전에 시장에 제품을 대규모로 깔아버린다. 또한 기대 수준이 높지만 역량과 책임감이 탁월한 직원을 계속해서 모으고 유지함으로써 기본 역량을 지속적으로 강화하고 신규 역량에 투입할 인재군을 상시 확보하고 있다는 점도 하이퍼포먼스 기업들의 공통적인 특징이라고 볼 수 있다.

이 책에서 하이퍼포먼스 기업들의 공통점과 특징을 파악한 다음에 자신이 몸담고 있는 조직이 과연 다음 S커브를 성공적으로 타서 승승장구할 수 있을지 곰곰히 생각해보자. 승승장구하기 어렵다는 생각이 든다면 하이퍼포먼스 기업에서 강조되는 특징 중에 무엇이 부족한지 분석해보면 더욱 좋을 것 같다. 240페이지 남짓한 분량에 대부분 실제 기업 사례를 토대로 진행한 연구/분석 결과를 정리한 내용이므로 기업 경영이나 흥망성쇠에 관심이 많은 분들께서는 꼭 읽어보시기 바란다.

요즘 한창 재미있게 즐기고 있는 웹툰인 미생에서 짤방하나 가져온다. "회계는... 경영의 언어니까." 보면 볼수록 대단한 문구다.

EOB

토요일, 6월 23, 2012

[독서광] 이노베이터의 조건

간만에 경제/경영 블로그 답게 피터 드러커의 21세기 비전의 마지막인 자기 혁신편 <이노베이터의 조건>을 정리해보겠다. 우선 번역서의 제목(이노베이터의 조건)과 부제목(어떻게 스스로를 혁신할 것인가)에 아연실색할 수 밖에 없었는데, 원서 제목이 이기 때문이다. 이 책은 창의성이나 혁신에 대한 실용적인 지침을 담고 있다기 보다는... 드러커가 바라보는 사회상을 철학적으로 그리고 있기 때문에 일반적인 자기 계발서 형식의 제목으로 독자를 햇갈리게 만든 출판사에 대해 옐로 카드 한 장을 주고 시작해야겠다(그렇다고 시리즈 다른 편에 비해 절대로 내용이 떨어지지 않으며, 오히려 더욱 강력한 내용을 전개한다).

책의 큰 목차를 보면, 사회(격동의 전환기), 경제(단절 이후의 시대), 정치(새로운 모색의 시대), 지식과 교육(다시 시작하는 미래)의 4부분으로 되어 있다. 목차만 봐도 예상이 가능하듯이 정치/경제/사회/문화(여기서는 지식/교육에 집중)라는 커다란 주제 4개를 모두 다루고 있기 때문에 드러커의 어느 책 보다도 지식의 밀집도가 높고 사회 과학(요즘 이런 단어를 잘못쓰면 잡혀간다는 소문이 있다. T_T)적인 특성이 강하다고 보면 틀림없다. 이 책 서문을 읽다가 한 가지 알게 된 사실인데, 드러커는 경영 관련 저술가이기도 하지만 사회와 공동체 관련 저술가이기도 하기 때문에 경영 대가가 사회에 대해 적은 책이라는 선입견은 접어도 좋다. 잠깐 해당 구절을 살펴보자.

나는 다른 무엇보다도 경영 관련 저술가로서 가장 잘 알려져 있다. 그러나 나의 저술들 가운데 절반 가량은 경영에 관한 것들이 아니라 사회와 공동체에 관한 것들이다. 또한 내가 경영에 대해 관심을 갖게 된 계기도 애초에 사회와 공동체에 대한 관심과 연구에서 비롯되었다.

(여느 때와 마찬가지로) 백문이 불여일견이라 본문 중에 눈에 들어온 몇 가지 구절을 살펴보자. 좋은 구절이 너무 많아서 일부만 정리해보았다.

우리는 경제인의 개념에 기초한 사회를 구제하기 위한 최후의 절망적인 노력으로서 경제학자를 선택했다. 마치 18세기의 사회가 합리주의 철학자들에게 왕좌를 내줬던 것처럼 말이다. 그러나 18세기 철학자들이 그랬던 것처럼 20세기 경제학자들 역시 실패했다.
사회 영역에서 인간은 처음에는 '정치적 인간'이 그리고 그 다음에는 경제인이 되었다. 사회 영역에서 자유와 평등은 경제적 자유와 경제적 평등을 의미하게 되었다.
경제 발전을 추구한 결과 공황이 발생했던 것처럼, 바로 그 전제 때문에 불가피하게 발생하는 결과를 제거함으로써 사회를 유지하려는 시도는 본질적으로 모순일 수 밖에 없다는 사실에 대한 인식이 유럽 전역에 점차 퍼져 나가고 있다.
파시즘 체제는 구질서의 실체를 무자비하게 파괴했지만, 그 외적인 형태는 매우 신중하게 유지하고 있다.
파시즘은 탈경제화를 통해 경제적으로 불평등할 수 밖에 없는 산업 사회의 생산 시스템을 유지하고 또한 타당한 것으로 만들고자 했다.
파시즘은 자본주의와 사회주의 양쪽 모두 타당하지 않은 것으로 단정하고, 두 가지 모두를 초월하는, 즉 경제적 가치에 기초하지 않는 사회를 추구한다.
제조업의 육체 노동자들과 그들의 노동 조합은 예전의 농민들과 같은 길을 갔다. 즉, 그들은 자신들의 설자리를 '기술자들'에게 내줘야했다.
이전의 농민들과 하인들이 쉽게 육체 노동자가 될 수 있었던 것과는 달리, 육체 노동자들이 지식 노동자가 되는 것은 그리 간단하지가 않다.
전문 지식 그 자체만으로는 아무 성과도 올릴 수 없다. ... 전문가가 성과를 올리고 공헌을 하기 위해서는 반드시 조직에 접근할 수 있어야 한다.
마르크스의 위대한 통찰력은 공장 노동자들은 생산 수단을 소유하지 않으며 소유할 수도 없기 때문에 '소외'될 수 밖에 없다는 점을 간파한 데 있다.
지식 사회에 있어 진정한 투자 대상은 기계도 도구도 아니다. 그것은 지식 근로자이다.
전략이란 조직의 목표를 실제적인 성과로 전환하는 수단이다.
지식 근로자들은 공동체로서 조직에 자신을 종속시키려는 어떤 시도도 거부한다.
오늘날에는 지식을 소유하고 있는 사람이 곧 생산 수단을 소유하고 있는 사람이며, 그런 사람들에게는 성과를 낼 수 있는 기회, 성취감을 느낄 수 있는 기회, 승진의 기회 등이 좀더 큰 곳을 찾아 언제라도 옮겨갈 수 있는 자유가 있기 때문이다.
'무엇을 폐기할 것인가'에 대한 결정은 가장 중요한 의사 결정인 데도 불구하고 가장 소흘히 다뤄지고 있는 의사 결정이기도 하다.
조직이 따라야할 제 1원칙은 바로 '집중'이다.
목표 달성 능력을 얻기 위한 실용적인 방법이나 기술 같은 것은 없다.
사실 모든 경영가는 사람을 고용하지 않고도 조직을 운영할 수 있으면 하고 바랄 것이다. 조직의 경영자에게 있어 사람들이란 성가신 존재다. 경영자는 사람들을 '통치'하는 것을 바라지 않는다. 그것은 직무 수행을 방해할 뿐이다.
악법은 범행을 예방하지는 못하면서 옳은 행위에 대해서는 처벌을 가한다. 악법은 이성이 아니라 감정에 기초해 제정된다.
오늘날 조직은 자신의 권한을 '피지배자들의 동의'에 의해 확보할 수가 없다.
각각의 조직은 자신의 목적을 분명하게 규정하면 할수록 더욱더 강한 조직이 될 수 있다.
혁신의 기회는 거대한 폭풍처럼 찾아오는 것이 아니라 살랑거리는 미풍처럼 소리없이 찾아온다.
계몽 사상과 프랑스 혁명은 정말이지 자유의 뿌리가 아니었다. 그것들은 진정 오늘날 이 세계(1930년대 말 ~ 1940년대 초)를 위협하고 있는 전체주의적 독재의 씨앗이었다.
(유럽의 경우를 볼 때) 자유주의에 입각한 운동이나 정당은 그 신조에 있어 모두 예외없이 전체주의적 요소를 가지고 있었다. 미국에서 자유주의 역시 처음부터 전체주의적 성향을 강하게 띠고 있었다.
미국의 수많은 개혁 운동 역시 대게는 실패로 끝나고 말았다. 미국의 모든 지방 자치 정부의 역사를 봐도, 이성주의자들이 비록 그 의도는 좋을지라도 정치적으로는 매우 무능하다는 것을 알 수 있다.
이성주의적 자유주의자는 오직 뭔가를 부정하고 반대할 수 있을 뿐, 스스로 행동하지는 못한다.
"지식인은 좌파에 서야만 한다."
지식인은 글과 지면을 통한 타당한 주장은 잘하지만, 정치적으로는 무능하다.
마르크스는 이성주의를 포기하고 비이성주의적 절대주의를 공공연하게 채택함으로써 무능한 이성주의적 자유주의를 강력한 정치적 세력으로 전환했다.
미국과 영국의 보수주의자들은 과거를 복원하지 않았을 뿐만 아니라 복원하려는 의도도 없었다.
미래를 위한 청사진이나 만병통치약을 기대해서는 안 된다. 당면한 문제에 대한 유효한 해결책 - 부분적이고 불완전한 해법일지라도 - 을 찾는 데 만족하지 않으면 안 된다.
존 F 케네디는 권력의 획득 이외에는 사회에 의한 구제를 위한 어떤 계획도 갖고 있지 않은 것으로 보이던 20세기 최초의 미국 대통령이었다.
우리는 가르치고 배우는 데 있어 단 하나의 올바른 방법이 있는 게 아니라는 사실을 잘 알고 있다.
2차 대전 이후에 모든 국가들은 정부가 지출할 수 있는 규모에 있어 경제적 한계란 없다는 사실을 확인하게 되었다.
고령의 은퇴자는 자신의 잘못으로 인해 불이익을 당하는 것이 아니다. 그렇다고 해서 다른 어떤 사람의 잘못 때문에 불이익을 당하는 것도 아니다.
파이를 똑같은 크기의 조각으로 자르는 것을 고집하면, 파이의 크기는 오히려 줄어들고 말 것이다.
우리는 지식의 탐구에 있어 물리적 한계점에 이르러 있다. 사용할 수 있는 자원에 한계가 있기 때문이다. 가장 부족한 자원은 돈이 아니라, 사람이다.
전통적 학교에서 가장 자랑스럽게 여기는 '전과목 A인 학생들'은 모든 면에서 평균적인 수준을 만족시키는 학생들이다. 하지만 그 학생들은 뭔가를 성취하는 사람들이 아니라 순응을 잘하는 사람들일 뿐이다.
모든 인간은 어느 날 갑자기, 그야말로 느닷없이 자신이 죽음에 직면해 있는 존재라는 사실을 인식하게 된다.

물론 세상은 예측한 방향대로 흘러가지 않기에 피터 드러커가 설명하고 예언한 내용이 모두 맞지는 않다. 하지만, 그럼에도 불구하고 정치/경제/사회/문화를 경영 관점에서 바라보는 드러커의 시각은 여전히 유효하기 때문에 새로운 사회에 관심이 많은 분들이라면 이 책을 꼭 읽어보기 바란다. 강력 추천!

토요일, 6월 16, 2012

[B급 프로그래머] 당신이 좋은 프로그래머라는 징표

트위터를 읽다보니 Signs that you're a good programmer라는 링크가 눈에 들어왔다. 혼자 읽기 아까워(라고 쓰고 점점 나빠져가는 기억력을 돕기 위해라고 읽는다) 내용을 간략하게 정리해봤다.

좋은 프로그래머 특성

  1. 실험을 먼저하려는 본능
    • 과외 프로젝트를 몰래한다.
    • (절차형, 스택 기반, 병렬형 등) 다양한 프로그래밍 언어를 장난삼아 접해본다.
    • '아두이노'가 뭔지 안다.
    • 회의에서 익살스러우면서도 비현실적인 해법을 제시하는 경향이 있다.
    • 오덕스러운 장난감으로 큐비클이나 책상을 채운다.
  2. 코드와 설계로부터 감정을 분리한다.
    • 주석 처리된 코드를 거의 커밋하지 않는다.
    • 다른 프로그래머의 뛰어난 코드를 쓰기 위해 여러 주나 여러 달에 걸쳐 작성한 코드를 기꺼이 버린다.
    • 코드를 바라보는 동안 결함을 지적당할 때 손가락을 입술에 가져가며 눈썹을 찌푸리며 '음'이라고 말한다.
    • IDE가 자동으로 코드를 맞추는 방식이 거슬리지 않으며, '탭 vs 공백' 논쟁에 관심이 없다.
    • '내 코드'가 아니라 '이 코드'라 지칭한다.
    • 성공적인 프로젝트에서 기존에 사용했던 설계를 버린다.
    • 지난 몇 년 동안 작성해온 결과물의 대안으로 기성품을 찾아라는 상사의 명령에 방어적인 태도를 보이지 않는다.
  3. 망가지지 않는 코드도 손 본다.
    • 명세를 글자 그대로 받아들이지 않고 누가 작성했고 뭘 생각했는지 찾으려 노력한다.
    • 프로그램을 매일 사용할 사람들을 쫓아다니며 이야기를 나눈다.
    • 마틴 파울러라는 사람이 쓴 책이 책장에 있다.
    • XML, ORM, REST와 같은 인기 있는 기술에 대해 호불호가 확실하며, 과거에 이들 몇 가지 기술로 전환해본 경험이 있다.
    • 추상화 계층을 활용하기를 좋아하지만, 언어나 플랫폼에 이미 존재하는 상위에 뭔가를 추가하는 방식은 좋아하지 않는다.
    • '약한 응집력'에 대해 이야기한다.
    • 새로운 기능을 추가하지 않고서도 코드의 행수를 줄이기 위해 최소 10%의 커밋 노력을 기울인다.
    • 새로운 기능을 추가하기 앞서, 더 나은 방법으로 완전히 대체하거나 두 과업을 동시에 수행하기 위해 기존 설계를 다시 뒤집을 필요가 있는지 점검한다.
  4. 이해 못하는 뭔가에 열광한다.
    • 'Lambda The Ultimate'를 주기적으로 방문한다.
    • ATP 분석이효소가(Seo Sanghyeon님께 감사. 대학교 교양 Biology 배운지 20년이 지나 모든 용어가 다 가물가물합니다. T_T) 뭔지 안다. 부엌에 있는 바나나에서 DNA를 추출해봤다.
    • 컴파일러를 작성하지 않더라도 표지에 용이 그려진 책이 책장에 있다.
    • 근처에서 '베이지안'이라는 단어를 막 언급한 사람을 찾기 위해 파티 장에서 사람들을 밀치고 가본 적이 있다.
    • 다른 산업게에 일하는 사람들에게 맥주를 사주며 기꺼이 공장 이야기를 나눌 의향이 있다.
    • 에어버스 330의 조종실 레이아웃과 같이 일상적인 뉴스에 무관한 뭔가를 설명하는 바람에 사람들을 따분하게 만드는 버릇이 있다.
    • 아이포드에 외국 팝송을 넣고 다닌다.
    • 자신들이 모르는 뭔가에 전문적인 지식이 있는 사람들에게 화내는 대신 부러워한다.
  5. 가르치고 싶어한다.
    • 자신의 작업에 대한 내용을 블로그에 올린다.
    • 위키피디아에 활성 계정이 있다.
    • 마커를 집어들고 화이트보드에 무심코 다가선다.
    • 주석만 담겨 있는 저장소에 변경 내역을 커밋한다.
    • 100달러짜리 책을 신입에게 빌려준다.

환상적인 프로그래머 특성

  1. 불굴의 인내
    • 화재 경보음에 당황하는 대신 짜증이 난다.
    • 헤드폰이나 라디오에서 막 연주된 노래가 뭔지 구분하지 못한다
    • 옆 동료가 몇 차례 커피를 마시러 갔는지 화장실에 갔는지 병원에 갔는지 모른다.
    • 사내 정치에 무관심하다.
    • 코드가 동작하기도 전에 버그를 예측할 수 있다.
  2. 집요한 완벽 주의
    • 타협하느니 죽는 편을 택한다.
    • 출시 날짜에 개의치 않는다.
    • 데드라인 직전에도 대규모로 리팩터링한다.
    • 사리 추구를 위해 보너스, 승진, 스탁 옵션을 받으려 하지 않는다.
    • 스탠리 큐브릭 감독 작품을 좋아한다.
  3. 플랫폼을 확실히 꿰차고 있다.
    • C 표준 라이브러리의 인크루드를 모두 기억하고 있다.
    • 책장에 "OpenDoc Programmer's Guide" 사본이 있다.
    • 반지의 제왕, 스타워즈, 몬티 파이썬에서 대사가 어떻게 흘러가는지 암기하고 있다.
    • TCP의 슬라이딩 윈도우가 초래하는 동기화 버그를 잽싸게 찾아낼 수 있다.
    • 실험 중인 CPU의 마이크로코드가 초래한 버그를 인식한다.
    • Knuth 교수가 보낸 $2.56짜리 수표를 액자에 넣어뒀다.
  4. 코드로 생각한다.
    • 일상 대화에서 프로그래밍 구성 요소를 사용해 은유적인 표현을 자유자재로 한다.
    • 대다수 시간을 "빈둥거리지만", 동료들보다 매일 버그가 훨씬 적은 코드를 커밋한다.
    • 어깨 넘으로 흘깃 보며, 손가락으로 코드에 있는 버그를 지적한다.
    • 취했거나 취침 중에도 걸려온 전화를 받으며 버그를 올바르게 진단한다.
    • 샤워를 하면서도 코드를 작성한다.
    • 난감한 버그에 직면했을 때, 본능적으로 자리에서 일어나 산책하러 간다.
    • 대화 도중에 갑자기 조용해지며 허공을 응시한 다음에 자초지종도 말하지 않고 터미널로 급히 뛰어간다.
  5. 로마에 가면 로마인이 된다.
    • 교차 플랫폼 프레임워크에 관심을 보이지 않는다.
    • '언어 전쟁'을 경멸한다.
    • 여러 언어로 동일한 프로그램을 유지하기 위한 전략적인 불이익을 생각하지 않는다.
    • 컴파일러, 라이브러리, 운영체제에 앞서 자신의 코드를 문제 근원으로 가정한다.
    • 특정 플랫폼을 대상으로 하는 프로젝트를 할당받으면 큐비클에 턱스 펭귄이나 안드로이드 인형을 갖다 놓는다.
    • 휴대폰이나 테블릿 브랜드를 바꾼다.
    • 새로운 디바이스에서 double이나 decimal과 같은 자료 유형이 무엇인지 가정하기 앞서 기술 매뉴얼 더미를 뒤진다.
  6. 자신의 도구를 직접 만든다.
    • 자동화된 빌드 서버글 구축한다.
    • 전용 벤치마크나 특화된 프로파일러를 작성한다.
    • GitHub에서 오픈소스 프로젝트를 운영한다.
    • 최소한 한 번은 LISP를 새로 작성해봤다.
    • 도메인 특화 언어가 무엇인지 알며, 해석기를 설계하고 구현해봤다.
    • 전용 매크로로 IDE/편집기를 확장한다.
    • 버그 추적기에 할당된 이슈 숫자를 보여주는 7 세그먼트 디스플레이로 책상을 꾸며놓았다.

프로그래머를 넘어서는 특질에 대한 소개 내용도 있었지만, 프로그래머를 위해(응?) 여기까지만 정리했다. 각자 한번 재미삼아 체크해보기 바란다. ㅋㅋ

EOB

토요일, 6월 09, 2012

[독서광] Visualize This: 빅 데이터 시대의 데이터 시각화+인포그래픽 기법

요즘 한창 인포그래픽에 대한 관심이 늘어가는 추세다. 인포그래픽이란 정보, 자료 지식을 시각적으로 표현하는 기술을 의미하는데, 복잡하고 방대한 내용을 그림으로 표현하므로 강렬한 인상을 주는 매체라 볼 수 있다. 하지만 멋진 인포그래픽을 감상하는 수준에서 벗어나 직접 만들어 보려면 눈앞이 캄캄해진다. 수학 학원 선생님이 칠판 앞에서 날렵하게 문제를 풀이하는 과정을 보고 집에 가서 직접 문제를 풀어야 하는 학생의 처지라고 할까나? 오늘 소개할 '비주얼라이즈 디스'는 데이터를 구해 그림으로 표현하며 추가 정보를 붙여 멋진 시각화를 달성하는 방법을 설명하는 좋은 책이다.

이 책 초반에 나오는 '어디서부터 읽어야 할까?'를 보면 이 책의 성격이 그대로 드러난다.

데이터로 이야기를 전개하는 스토리 텔링과 데이터 추출/검증 작업에 이어 실제 작업에 사용할 도구를 소개한 다음 시간/분포/관계/비교/공간이라는 측면에서 효과적인 시각화 기법을 소개하며, 최종적으로 목적에 맞는 디자인 기법에 대해 지침을 제공한다. 이론적이며 딱딱한 내용이 아니라 저자가 운영하는 블로그에 올려 크게 히트를 친 사례를 중심으로 설명하기 때문에 (중간 중간 나오는 파이썬, 플래시, 자바스크립트 코드를 어느 정도 읽을 능력만 갖추고 있다면) 눈도 즐겁고 머리도 즐거워 질 것이다.

이 책은 빅데이터에 대한 내용을 다루지는 않지만(빅데이터 자체에 관심 많은 분들은 번지수를 잘못 찾았으니 다른 책을 보시라), 빅데이터 때문에 요즘 크게 뜨고 있는 R 프로그래밍 언어를 소개하고 있으므로 맛뵈기로 좋은 입문서라는 생각이다. R은 특성상 통계, 자료 분석, 시각화에 강점이 있기 때문에 단순히 프로그래밍 언어 측면에서 접근해서는 배우기도 활용하기도 곤란하므로 남들이 어떻게 사용하는지 어깨 넘어 배우며 감을 잡은 다음에 본격적으로 자신의 필요성에 맞춰 확장해나가는 방법이 바람직하다는 생각이다. R 뿐만 아니라 웹에서 시각화를 원하는 분들에게도 여러 가지 좋은 정보를 제공하므로(예: 스탠포드 대학에서 시각화를 위해 만든 훌륭한 자바스크립트 패키지인 ProtovisD3.js) 도구의 특성과 기능을 상호 비교해가며 시각화 기술을 익힐 수 있다.

이 책은 단순히 그래픽을 멋있게 꾸미는 내용에 집중하는 대신 스토리가 녹아 들어있고 사용자 관점에서 의미를 찾아낼 수 있는 훌륭한 그래픽을 꾸미는 방법을 소개하고 있으므로, 특히 인포그래픽 쪽 관련된 독자라면 건질 내용이 상당히 많을 것이다. "우리가 궁극적으로 추구해야 할 목표는 그래픽과, 그래픽으로 전하는 이야기, 그 이야기를 듣는 사람이다."라는 9장의 문구가 이 책 철학을 반영하는 핵심 문구라고 본다. 자료 수집을 제대로 했지만, 적당한 도구로 시각화하는 선에서 끝나버려 논문에 실으면 인정을 받겠지만 일반 독자들에게는 난해한 내용을 던져주는 엔지니어/연구원들이나 시간에 쫓겨 검증도 안 된 상태에서 그냥 넘어온 날 자료로 그래프를 뽑아낸 다음 일러스트레이터로 이쁘게 만드느라 스트레스가 쌓이고 있는 디자이너분들께 'Visualize This'를 강력하게 추천한다.

보너스: 이 책 저자가 운영하는 FlowingData를 꼭 한번 방문해보기 바란다. 여러 가지 유용한 팁과 사례가 가득 담긴 보물 창고이므로 틈틈히 읽어보며 저자의 다양한 실전 경험을 자기 것으로 만들자.

EOB

수요일, 6월 06, 2012

[B급 관리자] What distinguishes the top 1% of PMs from the top 10%?

지난번에 올린 [B급 프로그래머] What makes a good engineering culture? 글을 독자 여러분께서 너무나도 열렬히 성원해주셨기에, 오늘은 후속타를 한번 소개해보겠다.

역시 Quora에 다음과 같은 질문이 올라왔다.

Product Management: What distinguishes the top 1% of product managers from the top 10%?

역시 한글로 번역하자면 "최상위 1% 제품 관리자를 상위 10% 제품 관리자와 구분하는 특징은 무엇인가?" 정도로 보면 되겠다. 이번에도 아마존의 제품 관리자가 직접 대답한 내용이 인상 깊어서 간략하게 요점을 정리해보았다.

  • 크게 생각한다: 1% PM의 사고는 지금 당장 투입 가능한 가용 자원이나 오늘날 시장 환경에 제약을 받지 않는다. 이들은 판을 뒤집을 큰 기회를 기술하고 이를 활용하도록 튼튼한 계획을 짠다.
  • 의사 소통한다: 1% PM은 반박하거나 무시하기 힘든 주장을 펼친다. 가용한 자료를 적절히 활용하지만 또한 이들은 인원수, 돈 기타 자원을 댈 수 있는 권력자를 설득해 장애물을 해결하도록 다른 쪽 주장, 신념, 계기에도 관심을 기울인다.
  • 단순화한다: 1% PM은 20%의 노력을 들여 기능이나 프로젝트의 80% 가치를 얻는 방법을 안다. 이런 작업을 반복적으로 수행하는 방식으로, 제품이나 사업 측면에서 복합적인 효과를 얻는다.
  • 우선 순위를 정한다: 1% PM은 프로젝트를 순차적으로 진행하는 방법을 안다. 이들은 단기적인 승리와 장기적인 플랫폼 투자의 균형을 적절히 맞춘다. 또한 적극적인 프로젝트 진행과 방어적인 프로젝트 진행의 균형도 맞춘다. 적극적인 프로젝트는 사업을 키운다. 방어적인 프로젝트는 사업 진행 과정에서 위험을 방어하며 질질 끌지 않도록 막는다(운영, 기술 빚 줄이기, 버그 수정).
  • 예측하고 측정한다: 1% PM은 프로젝트의 이익을 적절히 예측하는 능력이 있으며, 과거 경험을 적용하고 비교 가능한 벤치마크를 지렛대로 활용해 이를 아주 효율적으로 수행한다. 또한 프로젝트를 시작하고 나서 이익을 측정하고, 이런 지식을 향후 우선순위 조정과 예측에 활용한다.
  • 실행한다: 1% PM은 (뭐가 되었거나) 일단 결과를 낸다. 출시에 필요한 거라면 뭐든 한다. 이들은 임무 범위에 제약이 없다고 생각한다. 필요에 따라 사람을 모으고, 사업을 만들고, 내부 전문가와 드잡이도 벌인다.
  • 기술적인 트레이드 오프를 이해한다: 1% PM이 전산학을 전공할 필요는 없다. 하지만 기능의 기술적인 복잡성에 대해 개괄적으로 이해할 수 있어야 한다. 이들은 개발팀과 함께 올바른 기술 트레이드 오프를 결정해야 마땅하다.
  • 좋은 설계를 이해한다: 1% PM이 좋은 설계자가 될 필요는 없지만, 위대한 설계의 진가를 알아보고 훌륭한 설계를 좋은 설계와 구분해야 마땅하다. 이들은 설계 담당자에게 위대한 설계와 좋은 설계의 차이점을 명확하게 말할 수 있어야 하며, 좋은 설계에서 위대한 설계로 발전하기 위한 방향을 제기해야 마땅하다.
  • 문구를 효율적으로 쓴다: 1% PM은 작업을 마치기 위해 필요한 문구를 간결하게 작성해야 마땅하다. 이들은 장황하게 쓸 때마다 직전 단어의 가치를 희석하는 단어가 포함된다는 사실을 이해해야 한다. 단지 충분함을 넘어서 핵심 문구를 위한 완벽한 단어를 찾으려 시간과 정열을 쏟아야 한다.

좋은 PM이 되기는 어렵고 위대한 PM이 되기는 더욱 어렵다. 위에서 제시하는 1% PM의 좋은 특징을 다시 한번 생각해보면서 프로젝트를 진행하면 도움이 되지 않을까?

EOB

토요일, 6월 02, 2012

[독서광] 초이스(과학자의 생각법에서 배우는 선택의 지혜)

경제/경영 블로그로서(응?) 자리잡기 위해 요즘 계속해서 열심히 독서 중이다. 오늘은 읽은지 제법 지나 기억이 가물가물해지려는 책을 하나 정리하겠다. 주인공은 바로 '더 골'과 한계를 넘어서를 지은 골드렛의 신작인 초이스다. 골드렛 책이라니까 벌써부터 기대하시는 독자분들도 계실텐데, 이번 책은 소설식이 아니라 대화식으로 전개된다는 조금 특이한 속성이 있으므로 주의해서 읽을 필요가 있겠다.

우선 처음 이 책의 소개글을 봤을 때 "정통 물리학 개념을 ‘경영’과 ‘인생’의 문제를 해결하는 데 활용하고 있는"이라는 문구를 보고서 아주 부정적인 색안경을 끼지 않을 수 없었다. 세상에 '물리'로 '인생'의 문제를 해결하다니... 이거 말이 되는 소리야? 하지만, 장바구니에 들어간 책은 신용카드 결제를 마치고 책장에 꽃히는 데 성공했고, 시간이 오래 흘러 먼지가 쌓이다가 혹시나 하는 마음에 출퇴근 시간을 함께 했다. 애가 닳는 독자분들을 위해 간단하게 총평을 던지자면... 강력 추천! 재미있고 교훈적이다(주의: 독자 성향에 따라 호불호가 확실히 갈릴 수 있다).

이 책은 조직 심리학을 전공한 조직 경영 전문가인 딸과 제약 이론 대가인 아버지가 대화하는 방식을 따르고 있다. 아까 '물리'로 '인생'의 문제를 푸는 게 가능할까라는 의문은 독자를 대신해 딸이 충분하게 고민하고 있으므로, 독자는 딸의 시각으로 아버지를 바라보는 나름 흥미로운 경험을 할 수 있다. 물론 "아파트 대출금을 갚아야 하는데, 월급도 쥐꼬리고 이자는 높고 생활비는 오르고 그야말로 죽을 맛입니다"와 같은 '인생'의 골때리는 문제에 대해서는 절대 언급하지 않지만, 이 보다 훨씬 더 복잡한 조직 문제를 '단순함'의 무기로 풀어가는 과정에서 뭔가를 깨닫도록 만든다. 실제 현장('더 골'의 공장, '한계를 넘어서'의 소프트웨어 개발에 이어 이번에는 물류에 도전한다. ㅋㅋ)에서 벌어지는 정말 골때리는 문제를 하나씩 풀어가면서 '선택'의 어려움과 중요성에 대해 하나씩 짚어가는 식으로 현장감을 충분히 살리는 골드렛 표 서적의 특징을 그대로 계승하고 있다.

이 책은 각 장마다 '에프랏의 노트'라는 제목을 달고 해당 장에서 다룬 내용을 일목요연하게 정리하고 있으므로, 실제 현실에서 어려운 결정의 문제에 부딪힐 때마다 참고하기 딱 좋게 만들어져 있다. 궁금한 독자분들을 위해 좋은 문구를 몇 개 골라서 정리해보겠다.

기회가 있느냐 없느냐가 아니라, 기회가 올 때 그것을 기회로 인식할 수 있느냐(또는 성공의 기회로 만들 수 있느냐)를 판단하는 개인 능력에 차이가 있다.
현실은 놀랄 정도로 단순한데도 사람들은 너무 복잡하게 생각한다. 그래서 사람들은 정교한 설명과 복잡한 해결책을 찾는다.
현실이 복잡하다고 믿으면 문제, 특히 큰 문제가 발생했을 경우 당연히 복잡한 해결책을 찾을 것이다. 하지만 대부분 복잡한 해결책은 효과가 없고 계속해서 이런 문제를 해결하는 데 실패한다.
큰 문제를 위장하면서도 상황을 더 좋게 만들고 싶을 때 나는 그것들을 외면한체 작은 문제에 집중한다.
작은 문제에 집착하면 상황은 개선되지 않는다. 들인 노력에 비해 제한된 결과만을 얻을 뿐이어서, 나는 무엇을 성취할 수 있는지에 대한 기대치를 서서히 낮추게 된다.
과학자의 눈에 근본 원인이 적을수록 (즉 자유도가 적을수록) 시스템은 단순하다. 그들의 관점에서 '단순하다'는 것은 전체 시스템에 영향을 주기 위해 건드려야 할 지점의 개수가 적음을 의미한다.
갈등에 타협하는 대신 통째로 갈등을 제거할 방법을 찾아봐야 한다.
갈등이 문제의 근본 원인이고 갈등이 제거될 수 있다는 믿음에서 얻어지는 또 다른 소득은, 이런 갈등을 찾아보는 습관이 표준 절차가 된다는 사실이다.
근본적인 것들을 변화시킬수록 더 많은 결과를 기대할 수 있다.
관계에는 두 가지 모습이 존재한다. 남 탓을 하며 상대가 바꾸도록 강요하지만 관계가 더 악화되는 모습과 내재적 단순함에 따라 더 좋은 해결책으로 조화로운 관계를 추구하는 모습이 있다. 우리는 여기서 남을 탓하는 태도는 관계를 잘못된 방향으로 이끈다는 사실을 분명하게 알 수 있다.
윈-윈 해결책이 존재한다는 확신을 갖고 있다면 자신의 승리 못지않게 상대의 승리를 생각하는 해결책을 반드시 찾게 될 것이다. 서로의 갈등이 제거된 해결책이야 말로 윈-윈 해결책이다.
'잘 알고 있다'는 인식이 비약적 도약을 찾아내려는 우리의 노력을 가로막는 것으로 보인다.
우리는 모든 상황을 안다고 생각하지 않도록 계속 조심해야 하고, 모든 것을 원점에서 다시 생각해보는 자세를 가져야 한다.
성과가 있었다고 해서 이것들에 집착해서는 안 된다.
"어떤 원인을 입증하려 할 때 순환논리, 즉 'X가 Y의 원인인지 어떻게 아는가? 왜냐하면 Y가 존재하기 때문이다'로 끝나기가 쉽다. 따라서 합당한 원인을 찾고자 한다면 순환논리, 즉 같은 말 반복하기를 피해야 한다.
문제는 남 탓이 곧 내가 옳다는 것을 증명하는 수단이 된다는 데 있다. 즉 남 탓을 부정하는 예상 결과들은 모두 걸러내 버리고 결국에는 모두 남 탓을 뒷받침하는 예상 결과만 남겨둔다.
우리가 누군가에 대해 인격 모독적 용어를 쓰는 것을 자각했다면, 현재의 추상 원인을 폐기하고 다른 원인을 찾아봐야 한다.

자 이 정도면 충분히 뽐뿌질이 되었는가? 얇지만 나름 생각을 많이 하도록 만드는 책이므로 여러 번 읽어서 세상을 바라보고 판단하는 방법을 교정해보자.

EOB

일요일, 5월 27, 2012

[B급 프로그래머] What makes a good engineering culture?

Quora에 다음과 같은 질문이 올라왔다.

Quora and Facebook both have strong, well-known engineering cultures. What makes a "good" engineering culture - free time to commit to projects, a commitment to open source, or is it the leadership being technical by trade?

한글로 번역하자면... "쿠오라와 페이스북에는 강력하고 잘 알려진 공학적인 문화가 있습니다. '훌륭한' 공학적인 문화를 만드는 요인은 무엇일까요? 프로젝트에 전념하기 위한 시간? 오픈 소스에 대한 기여? 전문가가 되기 위한 리더십?"

여러 가지 다양한 의견이 나왔지만, 질문의 당사자(아니 해당 회사)로 쿠오라 엔지니어인 Edmond Lau가 직접 대답한 내용이 대박이다. 그냥 읽고 넘어가기에 좋은 정보이기에(라 쓰고 '나중에 참조할 목적으로'라고 읽는다. ㅋㅋ) 간략하게 요점을 정리해보았다

  1. 반복 속력을 최적화한다: 빠른 반복 속력은 작업 동기와 흥미를 유발한다. 코드 배포와 기능 출시를 방해하는 구조적이며 관료적인 장벽은 엔지니어가 회사를 떠나는 이유 중에 가장 짜증나며 공통적인 요인으로 작용한다. 조직적인 관점에서 보면, 빠른 반복 속력은 엔지니어와 디자이너에게 매일 일어나는 결정을 허가를 얻지 않고 자율적이고 유연하게 내리도록 만든다. 반복 속력은 또한 제품 개발을 시작하기 위한 잘 정의된 프로세스가 정립되어 투자가 많이 일어났을 경우에 개발 취소가 기대치 않은 방식으로 일어나지 않음을 의미한다. 팀 관점에서, 빠른 반복 속력은 팀 노력을 조율하고 이끌어내기 위한 강력한 리더십을 의미한다.
  2. 무지막지하게 자동화를 추구한다: 제품이 커저나감에 따라, 엔지니어당 운영 부하도 커져나간다. 페이스북은 엔지니어당 백만 가입자를 뒷받침하는 확장 측정 기준을 내세우는 것으로 유명하다. 자동화와 스크립트화는 개발팀이 실제 제품에 전념하도록 만들어주므로, 단기적인 땜빵이라는 유혹에서 벗어나 장기적인 수정과 테스트에 집중해야 한다.
  3. 올바른 소프트웨어 추상화를 이룬다: MIT 교수인 다니엘 잭슨은 소프트웨어 추상화의 중요성을 다음과 같이 말했다. "올바른 추상화를 고른다면, 설계부터 자연스럽게 프로그램이 흘러가도록 만들며, 모듈을 작고 단순한 인터페이스로 유지하며, 새로운 기능은 광범위한 재조직화 없이 기존 틀에 맞아 떨어지게 된다." 팀이 땜방질 해법으로 추상화를 조각내는 대신 소수의 핵심 추상화에 집중하게 되면 공통 라이브러리가 좀더 튼튼해지며, 모니터링이 지능화되며, 성능 지표를 쉽게 이해할 수 있게 되며, 포괄적인 테스트가 가능하게 된다.
  4. 코드 검토로 고품질 코드에 집중한다: 고품질 코드 기반을 유지하면 전체 엔지니어링 팀의 생산성을 높인다. 깨끗한 코드는 이해하기 쉽고, 개발하기 쉽고, 변경하기 쉽고 버그를 (미리) 노출하기 쉽다. (커밋 전이 되었든 커밋 후가 되었든) 시의 적절한 코드 검토를 위한 프로세스 수립은 코드 품질을 여러 가지 방식으로 개선한다. 누군가 코드를 검토한다는 사실이 엉망인 코드 작성에 대한 유혹을 강하게 압박하며, 코드 검토자와 코드 작성자가 더 나은 코드를 작성하는 방법을 배울 기회가 생기기 때문이다.
  5. (서로) 존중하는 작업 환경을 유지한다: 동료 사이의 존중은 열린 의사 소통의 토대를 형성한다. 서로의 생각에 도전하는 행위가 다연스러운 장소에서 건전한 아이디어가 나온다. 서로 물고 뜯는 환경에서는 제대로 된 피드백이 존재하지 않는다. 엔지니어들은 다양한 범위에서 전문가이며, 모든 사람이 각 분야마다 경험치가 다르다. 강력한 팀은 특정 분야에는 강하지만 다른 분야에는 약한 개인들로 구성되지만, 서로 존중하는 문화가 강점을 살려준다.
  6. 코드의 소유권을 공유하자: 코드 소유권을 공유할 경우, 유지 보수 담당이 자리를 비운 상황에서도 유지 보수 담당과 해당 팀원의 스트레스가 줄어든다(백업 요원이 있기 때문에). 또한 팀원들이 특정 분야에 너무 깊이 빠져들지 않기에(예: 난 이 모듈만 책임진다!) 참신한 통찰력을 제공할 수 있게 된다. 마지막으로 전략적인 목표를 빨리 끝내야 할 필요가 있는 시급한 문제를 여러 명이 함께 해결할 수 있게 된다.
  7. 자동화된 테스트에 투자하자: 단위 테스트 커버리지와 통합 테스트 커버리지는 끊임없이 빌드나 제품을 깨먹지 않고서도 대규모 개발자들이 대규모 코드 기반을 관리하도록 만드는 확장 가능한 유일한 방법이다. 자동화 테스트는 팀이 커짐에 따라 지속적인 배포 작업이 가능하도록 만드는 핵심이다.
  8. 20% 시간을 할당하자: 구글, 아틀라시안, 페이스북, 쿠오라는 모두 엔지니어들에게 20%의 시간을 줘서 일반적인 프로젝트 이외에 하고 싶은 뭔가를 하도록 유도한다. 미친 듯이 보이는 아이디어를 실행할 수 있는 시간을 주게 되면 뭔가 색다른 결과를 만들어내며, 장기적으로는 서비스나 제품에 많은 도움을 준다.
  9. 지속적인 개선과 학습 문화를 만들자: 주간 기술 회의는 엔지니어들에게 설계안과 작성 중인 코드를 공유하는 장을 만들어줘서 엔지니어들이 자신들의 작업에 긍지를 느끼고 팀이 당면한 작업 범위를 벗어나 넓게 볼 기회를 제공한다. 배우는 문화를 구축하려면 기초적인 알고리즘, 시스템, 제품 기술을 모든 직원이 보유할 수 있도록 멘터링하고 훈련하는데 집중한다. 엔지니어링 조직이 커지고 사람을 뽑는 노력이 더 들어갈 수록 멘터링과 훈련에 투자하는 노력도 커진다. 새로 뽑은 신입에 대해 매일 한 시간씩 멘터가 시간을 투자하는 행위가 부담으로 느껴질지 모르겠지만, 신입이 성공을 위한 준비를 마치는 과정에서 상당히 큰 지렛대 구실을 한다.
  10. 최고 개발자를 고용하자: 스티브 잡스는 다음과 같이 말했다. "A급은 A급을 뽑고, B급은 C급을 뽑는다" 페이스북 Yishan Wong은 "최고 개발자를 고용하는" 것과 "인터뷰한 최고 후보를 고용하는" 것 사이에는 차이가 있음을 강조한다. 쿠오라도 처음에는 엄청난 고객 요청에 압도 당해 고용 기준을 낮출뻔 했지만 그렇게 하지 않았다. 낮은 품질의 코드와 취약한 엔지니어로 기인한 기술 빚은 팀과 제품을 망가 뜨리기 때문이다.

이 정도면 아주 좋은 출발점으로 보인다. 하지만 훌륭한 문화를 만들기 위해서는 무엇보다 _실천_이 우선이다. 아무리 좋아도 이론은 이론일 뿐이니까. 그런 의미에서 바쁘다는 핑계로 차일피일 미루던 (사내 정보 공유를 위한) 수요 기술 세미나를 내주부터 다시 열어야 겠다. :)

EOB

금요일, 5월 25, 2012

[독서광] 부의 기원(3)

다른 책을 소개하느라 부의 기원을 잊어먹고 있었다. 오늘은 3부 '진화는 어떻게 부를 창출하는가'를 간략하게 정리해보겠다. 3부는 게임이론으로 많이 소개된 '죄수의 딜레마'를 다루며 시작한다. 죄수의 딜레마는 '비제로섬 게임'이라는 측면에서 무척 흥미롭다. 다시 말해 둘 이상의 사람들이 협력하면 모두에게 유리한 결과를 얻을 수 있게 된다. 하지만 현실은 어떨까? 내가 도우려고 했지만 남이 나를 속인다면? 그냥 제로섬 게임으로 흘러갈 가능성이 높다. 1970년대 후반 로버트 액설로드가 수학적인 계산 대신 실제 경연 대회를 열어 어떤 전략을 써야 가장 유리할지 알아내는 놀라운 실험을 했는데, 놀랍게도 결과는 '일단 처음 만난 상대에게는 무조건 협조하는 편을 선택하며, 그 다음부터는 상대방이 내린 결정을 보고 그대로 반복한다'는 팃포탯 전략이 최고로 좋은 결과를 얻었다. 내가 먼저 남을 '신뢰'해야 남도 나를 '신뢰'한다는 원칙이 그래도 적용된 사례다. 이를 컴퓨터 상으로 가져와서 인생(Life) 게임에 죄수의 딜레머 규칙을 적용한 방법으로 시물레이션을 진행한 결과 영원히 승리하는 전략은 없었다. 물론 시간이 아주 오래 지속된다면 팃포탯과 같은 단순한 전략이 계속해서 살아남게 되긴하지만 절대 판을 독식할 수는 없다.

단순한 시물레이션이 아닌 실제 경제에서도 승리의 규칙을 찾아내려면 어떤 사고 실험을 해야할까? 대니얼 데닛이 제안한 '바벨의 도서관'이라는 디자인 공간을 사용하면 어느 정도 힌트를 얻을 수 있을 듯이 보인다. '바벨의 도서관'은 영어로 쓰일 수 있는 500페이지 분량의 모든 책들이 소장된 초대형 도서관이다. 500쪽 분량이라면 권당 문자가 약 100만개 들어 있으며, 대소문자, 숫자, 구두점을 포함하면 영문자가 총 100자가 넘으므로, 도서관에는 100의 1,000,000승 만큼 책이 소장되어 있다. 이런 책을 뒤지다보면 별의별 책이 다 나오기 마련이다. 예를 들어, 윌리엄 세익스피어의 작품과 2042년의 베스트 셀러 작품, 심지어 여러분의 자서전까지 존재한다. 여기서 만일 이 도서관에서 특정 기업의 사업 계획서를 찾는다고 가정하자. 공격적인 내용, 보수적인 내용, 수익성이 높은 내용, 수익성이 떨어지는 내용 등 온갖 종류의 사업 계획서가 존재하지만, 현재 특정 기업의 상황에 맞는 사업 계획서가 아니라면 효용이 떨어진다. 하지만 시간이 흘러감에 따라 점진적으로 사업 계획서의 형태는 성공을 위한 공진화를 밟아왔다는 사실은 확실하다. 엄청나게 많은 경로(책) 중에서 성공적인 사업을 위한 경로(책)는 자연계의 진화와 유사한 방식으로 선택이 이뤄지게 된다.

다음으로 물리적인 기술을 설명한다. 구석기 시대 말에 이르러 다양한 도구가 등장하게 된 배경을 인간 언어 능력의 형성에 기인한다고 설명한다. 물리적 기술이 대대손손 이어져 내려오는 과정에서 정보 전달에 최소한의 신뢰성이 있어야 하는데, 언어의 출현이 복잡한 대규모 기술을 코드화하고 전달하고 정확하게 수행하는 데 돌파구를 마련했기 때문이다. 이렇게 물리적인 기술을 요소와 구조를 코드화했다고 추상화하면, 요즘 나오는 수많은 제품들에 대한 설명이 가능해진다. 자동차의 경우 엔진, 본체, 의자, 문과 같은 다양한 구성 요소와 배기량, 토크, 시트 제질, 문 개수와 같은 다양한 구조가 결합되어 나타난다. 따라서, 인텔이 새로운 마이크로프로세서를 만들 때마다 가능한 SKU(Stock Keeping Unit)이 늘어나며 물리적인 기술 공간이 늘어난다. 여기서 물리적인 기술 혁신이 일어나는 이유 역시 진화를 사용해 설명이 전개된다. 연역적인 논리적 사고, 실험으로 추론하는 방법, (연역도 아니고 귀납도 아닌) 뭔가에 열광하는 인간의 속성(임의 점프가 가능해진다)이 결합해 현존하는 디자인의 범위를 넓혀나가게 된다. 그렇다면 선택 받고 살아 남는 기술은 무엇일까? 주어진 환경에서 벅찰 정도로 많은 디자인이 출현해 경쟁이 불가피한 상태가 될 경우 선택이 일어나고, 기록이 돌에 새겨지거나 책으로 인쇄되거나 웹 페이지에 올려지며 복제되며 확산되면 살아 남은 성공한 기술이 된다. 나머지 복제가 일어나지 않는 (즉 모방되지 않는) 기술은 급격히 사라져버린다. 하지만 영원히 살아남는 기술이 없는 이유를 '파괴적 기술' 관점에서 바라볼 필요가 있다. 기존 기술로 성공할 기업일수록 기술 적합도 지형에서 새로운 기술로 갈아타기가 어렵다. 즉 정상에 있을 때는 다른 정상으로 올라가기보다 밑으로 내려가기가 훨씬 쉬울 뿐 아니라, 다른 정상으로 점프는 정말 위험하다. 새로운 시장에 진입하는 벤처 입장에서 보면 산 위로 올라갈 수 있는 새로운 길도 많고 도전할 수 있는 정상도 많지만, 계곡에서 산 위로 올라가 정상에 이르기 전에 깊은 계곡으로 빠져들거나 낮은 봉우리에 만족해 끝나는 경우도 많기에 그렇게 엄청난 성공을 거두기가 힘들다고 볼 수 있다.

물리적인 기술에 이어 사회적인 기술을 설명한다. 미국 경제의 생산성이 빠르게 증가한 이유를 물리적인 기술에서 찾으려던 학자들은 생산성을 증가시킨 요인이 회사들이 스스로를 조직화하고 관리하는 방식의 변화, 즉 사회적 기술의 혁신임을 알고 깜짝 놀랐다. 월마트의 경우 1980년대와 1990년대 초반에 경쟁 업체에 비해 40%나 더 생산적으로, 1990년대말까지 생산성을 22%나 더 향상시켜 경쟁 업체를 따돌렸다(B급 프로그래머: 지금은 아마존이 그 자리를 차지하고 있다. 낄낄). 그렇다면 사회적 기술이 무엇일까? "목표를 추구하면서 사람들을 조직하는 방법과 디자인"이라는 정의가 있다. 앞서 설명한 도서관과 유사한 사회적 도서관을 구성해 비슷한 방법으로 사고 실험을 하게 되면 역시 사회적 기술에도 진화가 개입될 수 있음을 알 수 있다. 돈이 발명되자 회계학이 만들어졌고, 이에 따라 주식 회사가 생겼고, 주식을 팔고 사는 주식 시장이 활성화되었다. 사회적 기술 공간에서도 연역적 추론과 실험적 추론이 역시 적용된다. 하지만 물리적인 기술과는 달리 사회적 기술에서는 실험적 추론이 우세하다. 시간이 지날수록 성공적인 디자인은 계속 지속되고 복제 되어 더 많은 자원을 끌어 당기고 확산되면서 증폭된다. 이렇게 물리적인 기술과 사회적인 기술이 공진화하며 농업 혁명, 산업 혁명, 정보 혁명을 이끌어 내게 되었다. 사회적인 기술에서도 앞서 설명한 협력이 아주 중요하다. 상호 협력을 기초로 하는 팃포탯과 같은 전략이 성공을 이끌어낸다는 사실은 서로 협력하는 사람들이 사기꾼을 몰아내어 건전한 사회를 만드는 과정을 설명할 수 있다. 마지막으로 경제적인 성공과 계층적인 구조가 존재하는 이유를 설명한다. 분업과 규모의 경제적 장점을 이용하려면 업무를 분할하고 실행을 조정하고 상황을 다시 결합해 결과물을 할당해야 하는데, 일단 계층 구조가 만들어지자 이런 계층 구조 내에 다시 계층 구조를 충첩해 분업과 정보 처리를 촉진하는 방법을 고안하게 되었다. 이런 계층 구조는 수렵/채집 부족부터 지역 볼링 리그와 대기업에 이르기까지 사회를 지배하는 기본적인 구조에 스며들게 되었다.

다음 주제인 '경제적 진화' 상당히 복잡하므로 오늘은 여기까지.