[일상다반사] 디벨로퍼웍스 한국어판 7월 5주 기사

중복인데, 점심으로 닭 한마리 드셨는지? 더운 여름날 냉커피 한잔으로 가뿐하게 오후를 열면서 재미있는 기사를 읽어보자.

• PHP의 미래: PHP V6에서 등장할 새로운 기능과 PHP 스크립트에서 달라질 부분을 소개하는 기사다.
  
• 유닉스 팁: 열 가지 더 좋은 유닉스 습관: 유닉스 명령행으로 작업할 때 익히면 좋은 습관 열 가지를 소개하는 기사다.
  

그러면 8월 첫주에 찾아뵈올테니 독자 여러분께서는 모두 건강 유의하시길~~~~~

[독서광] 닥터스 씽킹

소프트웨어를 개발하다보면 일정은 빡빡하고 요구 사항은 바뀐다고 투덜투덜하는 목소리가 여기저기서 메아리친다. 하지만 우물 안 개구리처럼 지내다보니 이런 현상이 소프트웨어 분야에만 국한되어 벌어지는 현상이라고 착각하는 경우가 생긴다. 다른 분야는 일사천리로 모든 일이 순조롭고 쉽게 다 해결되고 있을까?

환자 목숨을 놓고 의사의 판단을 다루는 책인 '닥터스 씽킹'을 읽어보면, 의사들은 소프트웨어 개발자는 명함도 내기 어려울 정도로 급박한 일정(물론 느릿느릿하게 결정해도 좋은 상황도 있지만 반나절도 영겁의 시간이 되어버리는 응급 상황도 많다)과 사람마다 모두 다른 요구 사항(?)을 다룬다는 사실을 깨닫게 될 것이다. 내 친한 친구 녀석도 의사라서 이런저런 황당무개한 이야기를 들어봐서 의사라는 직업이 얼마나 머리 아픈지 아주 조금은 이해하고 있었지만, 이 책을 읽다보니 더욱더 가슴에 와 닿았다.

이 책 목차 중에서 흥미로운 항목만 골라서 정리해보았다. 의학 서적이라는 선입견을 버리고 살펴보라.

• 완벽하지 않은 인간의 판단
  
• 실수에서 깨달은 뼈아픈 교훈
  
• 시간의 지배자
  
• 불확실성과의 싸움
  
• 자료 판독의 어려움
  

읽다보니 갑자기 디버깅...이 떠오르지 않는가? 뭔가 소프트웨어나 하드웨어에서 문제가 생겼을 때 해결하는 작업을 일컫는 단어 말이다. 하긴 질병을 고치는 작업도 사람을 대상으로 문제 원인을 찾아 격리한 다음에 해법을 논하니 디버깅은 디버깅이다. 이렇듯 이 책을 읽다보면 컴퓨터 분야에서 고민하는 내용을 다른 분야에서 어떤 식으로 바라보며 해결하는지 여러 가지 흥미로운 생각이 떠오를 것이다.

이 책에서 다루는 멋진 주제 중 하나가 바로 정형화된 규칙에 따른 상황 대응 vs 직관과 창의성을 발휘한 상황 대응이다. 마치 전통적인 소프트웨어 공학 vs 에자일을 생각나게 만드는 주제인데, 정형화된 규칙과 알고리즘으로 모든 질병을 파악해서 대응하기는 아주 어렵다는 이야기가 곳곳에서 나온다. 정형화된 규칙에 따르다보면 실제 환자와 의사 소통에 소흘하게 되며 결국에는 요구 사항(?) 분석과 피드백 실패로 인한 심각한 상황에 봉착할지도 모른다는 경고는 귀담아 들을만한다.

책에서 몇 가지 흥미로운 부분을 뽑아서 정리해보았다. 의사 이야기지만 소프트웨어 개발하면서도 한번씩 가슴에 새겨들을 말이다.

특히나 정신없이 돌아가는 상황에서 올바른 사고를 하려면 잠시 생각의 속도를 늦출 필요가 있다. ... 어떤 환자를 만나든 정신없이 돌아가고 때로는 아수라장을 방불케 하는 주변 환경에 정신을 빼앗기거나 위축되지 않기 위해 의식적으로 생각과 행동의 속도를 늦추면서 '신중한 여유'를 가지고 진료한다.

록 선생은 또한 많은 의사들이 모든 수치가 동일한 확실성과 타당성을 지닌다고 생각하는 것에 우려를 표시한다. "사람마다 두는 비중이 다르다"는 것이 록 선생의 말이다. 즉, 의사 결정을 할 때 모든 결과에 동일한 무게를 두어서는 안 된다는 뜻이다. 그렇기 때문에 어떤 수치에 무게를 두고 어떤 수치를 버려야 할지에 대해 배워야 한다.

컴퓨터 기술은 방대한 임상 정보를 정리하고 접근성을 높이는 데 도움이 될 수 있다. 그러나 그런 식으로 컴퓨터 기술을 이용하여 '효율성'만 진작시키다보면 의사와 환자 사이의 틈은 점점 벌어지기만 할 것이다. 뿐만 아니라 의사의 정신이 온통 템플릿 빈칸을 채우는 일에만 쏠려 인식의 오류를 범할 가능성도 높아진다.

"딱 이런 생각이 들죠. 저기 캄캄한 어둠 속에 답이 숨어 있을 것 같은데, 이제 더 이상 저 어둠 속을 뚫고 갈 길을 모르겠다, 알고 있는 모든 길을 떠올려 보지만 이미 모두 가본 길들이다. 이제 모든 길이 막 다른 골목으로 보이고, 더 이상 새로운 길이 안 보이는 것입니다."

"사람들은 대체로 의사들의 의사결정은 감정이 전혀 개입되지 않는 객관적이고 이성적인 과정일 것이라고 생각하지요."

벌써 인터넷 서점에 들어가서 바구니에 책을 담고 계신 분들도 있으리라... 특히 특정 분야에서 전문가들이 생각하는 방식에 대해 궁금증이 많은 독자에게 추천하고픈 책이다.

EOB

[일상다반사] 한국 유투브 검열 사실인가? 미안하다, 사실이다.

요즘 촛불도 잦아들었겠다, 마음만 먹으면 개헌까지 가능한 초거대 여당으로 재탄생했겠다, 몸이 근질근질한 2MB와 딴나라당이 (사실상 인터넷 검열 시스템에 가까운) 실명제 확대, 사이버 모욕죄 신설 등, 헌법에 보장된 국민의 기본권을 제한하려는 움직임을 아주 활발하게 보이고 있다. 이미 인터넷 때문에 여러번 당한지라 어떻게든 한번 복수해보려고 길길이 날뛰는 모양인데, 1980년대로 회귀하고 싶어서 환장을 하는 모습이다.

자정작용을 잃어버린 인터넷을 살리겠다고 하는 좋은(?) 취지에 공감하고 동감하시는 분들도 많으시리라. 하지만 고양이에게 생선을 맡긴다는 기분이 드니 이거 참으로 황당한 시츄에이션 되겠다. 사이버 모욕이 되고 안 되고 기준이 참으로 의심스러우니, 결국 자기들 구미에 맞는 잣대를 대어 '유전무죄', '무전유죄'로 흘러가서, (애정이 있던 악의적이든) 현 정권에 대한 비판은 모두 삭제되고 명비어천가만 인터넷에 넘치지 않을까 조심스럽게 추측해본다.

그렇다면 1984년 빅브라더 큰형님께서 포털 등에 압박을 가하면 우리는 어떻게 대응해야 하나? 최근 포털 대안으로 구글에 대해 관심이 높아지고 있고, 실제로 검열 대상 글과 비디오 클립이 구글과 유투브 등에 올라오는 경우도 있었다(조중동 숙제... 스프레드 시트가 대표적인 예다).

자, 그렇다면 우리의 대안으로 떠오른 구글이 정말로 악을 행하지 않는 차칸 기업인지 조금 깊이 생각을 해볼 시점이다. 모모씨(실명 안 밝힌다.)의 제보에 따라 유튜브 유감. 유튜브도 검열에서 자유롭지 못하다.라는 글을 읽게 되었다. 똑같이 한번 접근해봤다.

도대체 뭘 그리 숨길게 많아서 '회원님의 국가'에서 보지 못할까? 언어 설정을 영어로 바꿔서 시도했지만, 역시 접근이 거부되었다. 이럴 때 몇 가지 의심을 해볼 수 있는데, 사회 통념에 반하는 내용이거나 청소년들이 보면 쬐금 곤란한 내용, 기타 기술적인 문제점으로 인한 장애가 대표적이다. 악을 행하지 않는 구글이니 좋게 생각해야 하지 않을까? 하지만, 이 글 아래쪽 트랙백을 보니 유튜브(YouTube) - 국가 차단 동영상 보는 방법라는 글이 있어 읽어보았다. 구글이 악을 행하고 있다는 증거가 슬슬 들어오기 시작한다. 가장 그럴듯한 가정은 특정 클립에 대해 한국 IP 대역에서 들어오는 요청 모두 차단!

한국에서는 싸이 때문에 여러 기업이 차단한다 어쩐다 난리가 났듯이, 미국내 대다수 회사와 학교에서 유투브나 페이스 어쩌구 하는 서비스를 금지하고 있다. 하지만 보고 싶을 때가, 아니 봐야 할 때가 있다. 바로 어청수 비디오도 여기에 속한다는 생각이다. 그래서 어제 밤에는 구글 도움을 받아 아주 손쉽게(참 모순이다 모순) 우회책을 찾아내어 한국 국민들에게 막혀버린 클립을 살펴볼 수 있었다.

하지만, 블로그 집필을 위해 오늘 아침에 다시 접속해보니 유투브에서는 한술 더떠 아예 한국이고 해외고 간에 비디오 클립 자체를 보지 못하도록 차단하고 있다. 자, 따끈따끈한 인증샷 날아간다.

자, 그렇다면 차단을 놓고 뒤에서는 어떤 일이 벌어졌을까? 다음 두 가지 가능성이 있다.

• 정부가 요청, 구글이 차단: 둘 다 나쁘다
  
• 정부는 가만히 있고, 구글이 알아서 차단: 구글이(아니 _도_) 나쁘다
  

뭐가 되었던 '악을 행하지 말자'라는 구글 모토랑 영 안 어울리는 진짜로 웃긴 상황이 되어버렸다. 속보로 조인스에 올라온 유튜브에 어청장 관련 영상, 검열로 삭제?를 보니 역시 경찰청-구글(유투브) 작품이다. 명예훼손이라는 이유로 걸고 넘어져서 임시로 차단했다고 하던데, _임시_가 영원이 되어버렸네?

하지만 그리 놀랍지도, 분개할만한 사실도 아니다. 초난감 기업의 조건(8장을 봐라)에 따르면 구글은 이미 중국에서 언론 검열에 참여한 화려한 과거가 있는 회사다. 중국 정부가 천안문, 파륜궁과 같은 핵심 키워드에 대한 차단을 요청했고, 구글은 해당 키워드를 입력하면 아주 황당한 결과가 나오도록 조작해줬다. 탱크 그림은 어디로 사라지고 천안문에서 관광하고 있는 관광객 사진만 펑펑 뜨기 시작했으니, 이야 말로 정말로 초난감한 상황이 아닌가?

릭 채프먼은 다음과 같이 말한다.

어떤 사람들은 미성년자 포르노 애호가들을 대변해 투쟁까지 했던 구글이 잔인한 독재 정권에 굴복했다는 사실을 이상하게 여긴다. 사람들은 부모가 정치적 자유와 종교적 자유를 무자비하게 억누르고, 반대자들을 고문하고 구속하며, 언론을 검열하고 감금하던 나라로부터(B급 프로그래머 한마디: 갑자기 요즘 한창 화제가 되고 있는 어느 나라가 생각났다) 도망쳐 왔던 세르게이 브린이 정치적 자유와 종교적 자유를 무자비하게 억누르고 반대자들을 고문하고 구속하며, 언론을 검열하고 감금하던 나라(B급 프로그래머 한마디: 다시 한번 요즘 한창 화제가 되고 있는 어느 나라가 생각났다)를 위해 자신의 검색엔진을 검열하고 있다는 사실에 모순을 느낀다.

뱀다리: 이제 이 블로그도 감시 대상에 들어서 언제 닫힐지 모르겠다. 낄낄... 미리 경고하는데, _4가지 없는 알바_들은 이 블로그 글에 대해 댓글 달지 마라. 열받으면 당신들이 전가의 보도로 여기는 사이버 모욕죄로 뜨거운 맛을 보여줄테니.

EOB

[일상다반사] 디벨로퍼웍스 한국어판 7월 4주 기사

벌써 7월도 막바지로 접어들고 있다. 휴가 계획 모두 잘 세우고 계신지? 이번 주에 나갈 기사는 세 개다.

• IBM Rational Purify의 향상된 기능: Purify를 소프트웨어 개발과 테스트 과정에 통합하기: 지난번 소개했던 purify 기사 후속편이다. 개발 환경과 통합 과정에 초점을 맞춘다.
  
• 전사적 아키텍처의 핵심, Part 3: 전사적 아키텍처 설계와 구현: 전사적 아키텍처 시리즈 3탄이며, 아키텍처 시작 방법을 논한다.
  
• ext4로 이주하기: 리눅스 차세대 파일 시스템인 ext4를 소개한다.
  

디벨로퍼웍스와 무관한 금주 공지 사항 한가지: Archmond님께 드릴 선물(?)이 있으니 여기 댓글을 읽어보시기 바란다. :)

EOB

[독서광] 꽂히는 글쓰기(X)

원숭이도 나무에서 떨어질 때가 있다고 한다. 나름 책 고르는 선구안을 길렀다고 좋아했는데, 이번에 꽂히는 글쓰기라는 책을 구입하고 첫 50페이지를 읽다읽다 도저히 안 되어 포기하고 바로 쓰레기 통으로 슛 골인~~ 제목이랑 목차를 정교하게 조작해놓았기 때문에 마치 SEO(Search Engine Optimization)에 걸려든 검색 엔진처럼 꼼짝 못하고 낚인 셈인데 역시 마케팅 전문가 답게 조 비테일은 이 책에 자기 이론을 제대로 활용한 모양이다. 아, 정말 훌륭하다 훌륭해.

책에 나오는 잘못된 마케팅 광고 예를 읽다보면 너무나 끔찍해서 온몸에 소름이 돋는데, 조 비테일이 고쳐서 새로 쓴 예 역시 도토리 키재기 만큼이나 형편 없기 때문에 이건 완전히 똥차 피하려다 쓰레기차에 받치는 상황이라고 보면 딱 맞다.

이 책을 사려고 마음먹었다면 반드시 서점에 가서 진짜 이 책의 정체가 무엇인지 파악하기 바란다. 글 잘 쓰는 법이랑 _전혀 _관계가 없다(이 책이 글 잘쓰는 법을 다룬다고 주장하면, 나는 우리집 화장지 두루마리가 팔만 대장경이라고 주장할 수 있다). 책 소개 글에서 최면술 어쩌구 하는 이야기가 나왔을 때 미리 눈치채야 하는데 나이먹어 사라진 총기가 원망스러울 뿐이다. T_T 만 원이면 맥주가 몇 병이야?

조 비테일이라는 사기꾼과 웅진윙스라는 국내 출판사는 바로 블랙 리스트 등재되겠다. 짝짝짝.

EOB

[독서광] 블로그 히어로즈

종종 다른 불로거는 어떤 생각으로 블로그를 운영하고 다른 사람 블로그를 읽는지 궁금한 경우가 생긴다. 물론 블로거도 사람이라서 크게 상식을 벗어나지 않은 선에서 자신과 유사하게 움직이라는 사실을 알고는 있지만, 사람이 원래 인간 관계에 최적화된 두뇌 구조를 타고난 관계상 남의 이야기를 듣고 싶어하는 충동은 인지상정이다.

이번에 에이콘 출판사에서 출간한 블로그 히어로즈는 블로그 세상에서 이름을 날리는 블로거에 대한 이야기를 싣고 있기에 남의 이야기를 좋아하는 우리 호기심을 어느 정도 충족시켜주리라는 생각이다.

블로그 히어로즈가 다루는 소위 파워 블로거는 아쉽게도 모두 외국 사람인데(딱 여섯 사례만 기존에 들어본 블로그였다. 나머지 블로그는 머리털나고 처음 보고 듣는 사례), 불행 중 다행으로 (몇 명 안되어 아쉽긴 하지만) 한국 블로그에 대한 인터뷰 기사가 부록으로 따라나와서 한국 블로거 생각도 비교해볼 수 있게 만들어준다. 아무래도 외국 사례를 많이 들다보니 검색 엔진 최적화(SEO), 광고, 수익 모델, 트래픽 유입 등 상당히 상업적인 측면을 강조한 질문과 대답이 많이 나와서 비교적 아마추어리즘을 간직하고 있는 국내 블로그 상황과 조금 동떨어져있다는 생각도 들지만 블로그만으로 밥 벌어먹고 살아야 하는 그들만의 고충(?)이 있기에 어느 정도 이해를 해줘야 겠다.

30명이라는 많은 사람과 인터뷰한 내용을 싣다 보니 다양한 분야에 종사하는 별의별 사람 이야기가 다 나오는데, 그럼에도 불구하고 유유상종이라고 사고 방식이나 생활 패턴들이 비슷하다 보니까 조금 지루하다는 느낌도 들지만 그 만큼 성공한 블로거에는 공통점이 많다는 사실로 받아들여도 좋을 듯 하다. 독자 여러분을 위해 성공적인 블로거들의 공통점을 정리해보면

• 열정
  
• 근면 성실
  
• 독자 위주
  
• 전문성
  
• 사실 검증, 진실과 정직
  
• 스스로 즐김
  
• 독자적인 가치관과 자기 목소리
  

정도로 요약할 수 있겠다.

최근에 한국 내 블로그 세상을 돌아다니다보면 낚시성 제목과 한쪽으로 치우친 자극적인 내용으로 어떻게든 트래픽 한번 높여볼거라고 열심히 노력(!)하는 분들을 볼 수 있는데, '블로그 히어로즈' 읽어보시고 조금 진정하시는 편이 좋겠다고 간접 조언(나도 이런 말 할 자격이 있는지는 잘 모르겠지만. ㅎㅎ)을 해본다. 트래픽 자체는 목적이 아니라 성공적인 블로그로 가는 도중에 얻는 부산물일 뿐이기에...

EOB

[일상다반사] 디벨로퍼웍스 한국어판 7월 3주 기사

금주에도 어김없이 디벨로퍼웍스에 기사가 올라갔다.

• PHP 프레임워크, Part 1: 많이 사용하는 프레임워크 세 개: 많이 사용하는 PHP 프레임워크 소개 기사다.
  
• Ajax에서 XML 처리하기, Part 3: JSON을 사용하고 프록시 피하기: Ajax에서 XML 처리하기 마지막 기사인 JSON 활용법이다.
  
• XUL(XML User Interface Language) 개발: 파이어폭스 3.0이 자랑하는 개발 언어인 XUL로 블로그 편집기를 개발해보는 튜토리얼이다.
  

그리고 6월 한달 동안 많이 읽은 top 10 인기 자료가 떴는데, vi 입문 -- 컨닝 페이퍼 이용하기가 당당히 1위로 등극했다. 독자 여러분의 관심과 성원에 감사드린다.

EOB

[새소식] dropbox: 새롭게 등장한 파일 백업과 공유 서비스

지난번 마이크로소프트 사가 발표한 파일 저장/공유 서비스인 SkyDrive를 소개한 바 있다. SkyDrive도 제법 쓸만한 서비스지만 몇 가지 단점이 있었다. 우선 웹 인터페이스를 사용하므로 액티브 X 컨트롤이 설치되지 않는 환경(예: 맥OS X, 파이어폭스)에서는 파일 하나 올리려면 대략 난감한 상황이 벌어진다. 파일을 일일이 선택한 다음에 하나씩 올리다가 지쳐서 그냥 압축해서 올리는 편법을 쓰게 되는데, 이렇게 되면 개별 파일을 내려받기 위해서 무거운 압축 파일 전체를 내려받아야 하는 문제점이 있다. 다음으로 올릴 수 있는 파일 크기가 50MB 정도로 제약이 있다는 문제점이 있다. SkyDrive는 간단하게 파일을 올리고 내리는 목적으로 사용하기에는 충분하지만 조금만 복잡한 작업을 하려면 머리가 아파지는 어중간한 서비스라고 볼 수 있겠다.

하지만 이런 문제점을 해소한 새로운 파일 백업과 공유 서비스인 dropbox가 등장해서 우리를 즐겁게 해주고 있다. 아직 베타 상태라서 기능이나 성능 측면에서 조금 미비한 부분도 보이지만 SkyDrive와 비교하면 가려운 곳을 긁어주는 멋진(!) 기능이 여기저기 돋보인다. 반나절에 걸친 사용기를 정리해보았다.

• 파인더(맥OS X)나 탐색기(윈도우)와 연계해서 동작하므로 네트워크 폴더 연결처럼 자연스럽게 파일을 다룰 수 있다. --> SkyDrvie와 비교할 때 가장 멋진 점이다. 비록 실시간은 아니더라도 동기화가 이뤄지며, 맥에서는 growl, 윈도우에서는 윈도우 파일 통지 매커니즘을 사용해서 파일 추가/삭제와 같은 사건이 일어났을 때 사용자에게 피드백을 주게 되었다.
  
• 폴더/파일 관련 작업 이력 추적이 가능하다. 어떤 폴더를 만들고 이름을 바꾸고 파일을 올리고 삭제했는지 웹 페이지에서 전반적인 작업 이력 상황을 상세히 알려준다. 맥과 윈도우 환경에서 한글 파일 이름 지원도 잘 된다.
  
• 개별 파일마다 변경 이력이 남는다(폴더에서 파일을 선택한 다음에 오른쪽 마우스 클릭을 하면 Dropbox 드롭 다운 메뉴 아래에 Revisions...라는 항목이 나온다.). 파일 편집 과정에서 리비전 기록이 남으면 좋겠다는 생각이 들 경우가 많은데, 명시적으로 CVS와 같은 원시 코드 관리 시스템을 사용하지 않는 이상 이런 사치를 누리기는 어렵다. 하지만 dropbox에서는 이력 추적 기능이 개별 파일마다 붙어 있으며 과거 버전으로 복구까지 가능하다. --> 현재 시간차가 많이 나는지 이력 추적 기능은 실시간으로 동작하지 않고 있다.
  
• 웹 인터페이스만으로도 파일 공유가 가능하다. 다른 사람 컴퓨터를 자주 이용해야 하는 사람을 위해서 별도 클라이언트 응용 프로그램을 설치하지 않고서도 웹 인터페이스만으로도 파일을 올리고 내리는 작업이 가능하도록 지원한다.
  
• 다른 사람과 파일 공유가 가능하다. 원하는 파일을 Public 폴더에 넣은 다음 공개 URL을 확인해서(폴더에서 파일을 선택한 다음에 오른쪽 마우스 클릭을 하면 Dropbox 드롭 다운 메뉴 아래에 Copt public link라는 항목이 나온다.) 친구들에게 알려주면 된다. 아니면 폴더 단위로 친구를 초대해서 파일을 공유할 수도 있다(폴더를 선택한 다음에 오른쪽 마우스 클릭을 하면 Dropbox 드롭 다운 메뉴 아래에 Share...라는 항목이 나온다).
  

여기서 주의 사항을 한 가지 짚고 넘어가야겠다. 이 서비스는 아직 베타 상태이므로, 몇 가지 문제점을 내포하고 있다.

• 현재 맥과 윈도우 양쪽에서 폴더 동기화 테스트를 해봤는데, 동기화 속력이 많이 느리다. 올리면 바로 몇 분 내에 나와야 하는데, 경우에 따라서 1시간 정도 걸리는 경우도 있다. 파일 크기와 무관한 듯이 보인다.
  
• 정밀한 테스트를 해보지는 않았지만, 파일 이력을 실시간으로 추적하지 못하는 듯이 보인다. CDP(Continuous Data Protection) 수준까지는 바라지 않아야 할 듯이 보인다.
  
• 거북이 SVN처럼 100% 클라이언트 단에서 작업이 불가능하며, 로그인이나 파일 이력 보기와 같은 작업은 웹 브라우저 도움을 빌어야 한다. 앞으로도 개선되기는 어렵지 않을까 싶다.
  
• 파일 공간이 2G 정도(dropbox 서비스 아이콘을 누르면 전체 사용량과 현재 사용량이 나온다)로 제약이 있다. 개별 파일은 50MB 한계를 가볍게 넘어가는 듯이 보인다(70MB짜리를 올려봤는데, 잘 된다. 더 큰 파일은 테스트해보지 않았다.).
  
• 맥에서 특정 파일을 dropbox 공유 폴더로 옮기면 복사가 아니라 원래 매킨토시 관례대로 이동이 되어버리는 문제점(?!)이 있다. 반드시 명시적으로 파인더에서 복사를 한 다음 붙여넣기를 해야 한다.
  

아직 베타 단계이므로 조금 불편한 점이 눈에 들어오지만 발전 가능성이 높아보이는 서비스라고 보면 틀림 없겠다. 향후 가격 정책이나 기능 개선과 안정화 작업이 정상적으로 이뤄진다면 유료 서비스로 바뀔 가능성이 높다는 점이 조금 가슴(?) 아프다. 선택의 폭은 넓으면 넓을수록 좋기에 지금 시장을 선점하고 있는 유사 경쟁 서비스와 전투를 벌여 승리할 수 있을지 지켜보기로 하자.

EOB

[일상다반사] 청와대 vs 안철수 연구소

초난감 기업의 조건이 나온 다음에 독자 여러분의 평가는 극과 극으로 갈렸다. 유쾌통쾌한 책이라는 의견과 이해하기 어려운 미국식 유머가 섞인 따분하고 재미없는 책이라는 의견으로... 하지만 재미있거나 재미없거나 이 책에서 제시하는 교훈을 한쪽 귀로 흘려넘기면 대략 난감한 상황이 벌어진다. 이번 시스템 파일을 홀라당 날려먹은 V3 사건과 국회 연설 후 민간인이 금강산 여행 도중 사망한 사건 + 독도 일본 땅 명기 관련 소식은 초난감 기업의 조건에서 경고한 브랜드 이미지 날려먹기의 좋은 예라고 볼 수 있겠다.

안철수 연구소의 초기 대응은 초난감 기업의 조건에서 이야기하는 회복 절차를 그대로 차근차근 밟고 있다(페이지 270에서 그대로 발췌).

• 굽실거린다: 문제 파악 후 즉각 잘못인정
  
• 솔직하고 사과하며 비굴하게 설설긴다: 대표이사 사과문 전 일간지 도배!
  
• 상황을 바로 잡겠다고 즉각 약속한다: 직원들 날밤새서 만든 복구 CD 수천 장 퀵으로 배송! 전무후무한 기록이다. T_T
  
• 필요하다면, 중간 관리자 몇 명을 희생양으로 해고한다: 일단 사태 수습 먼저. 어떻게 될지 보자.
  
• 반드시 필요하다면, CEO까지 포함해 경영진 몇 명을 희생양으로 해고한다(엔론 사태를 생각해보자): 낄낄... 고객에 대한 손해배상 절차를 봐가면서 어떻게 될지 보자.
  

안철수 연구소는 이번 사고로 인해 상당한 매출 감소와 브랜드 이미지 타격이 크겠지만, 그나마 초기에 진화했기에 다시 한번 일어설 기회는 존재한다고 보면 틀림없다. 잘못은 잘못이고 잘못에 대한 대응은 대응이니까. 자 그렇다면 2MB는 이번 사고에 어떻게 대응하고 있을까? 신문 기사를 읽어 보면, 또 남탓이다. 위기 대응 시스템에 문제가 있다는 둥 어쩌구 저쩌구 엉뚱한 소리만 잔뜩 늘어놓고 끝난다. 이런 논리대로라면 미국 쇠고기 수입 건이나 일본 독도 문제도 시스템 탓이지? 아랫사람들이 눈치보기 바빠서 정보망이 꽉꽉 막혀버린 현 상황을 책임질 사람이 수장 아니었던가? 여기서 더 크고 위력적인 폭탄은 일본에서 들어온 '독도 일본 땅 명기'다. 축구 경기에서 일본에게 지고 들어오면 감독 교체부터 시작해서 전국이 난리 법썩인데, 멀쩡한 땅이 졸지에 일본 영토로 변하면 이건 축구 경기 정도와 비교하기 대략 곤란한 상황이 되어버린다. 물론 미국과 일본을 섬기는(?) 꼴통 집단이야 여기에 대해 쌍수를 들고 환영할지 모르겠지만(미국 한 주로 편입되거나 일본 식민지 바라고 있을지도 모르니 뭐...), 일반 국민 정서로는 용납이 불가능한 상황에 이른다.

자, 이제 2MB가 꺼낼 카드는 무엇일까? 촛불 집회에 대응하는 모습을 봐서는 '장고 끝에 악수'가 나오지 않을까 벌써부터 걱정이다. 누구를 탓하겠냐? 정치, 경제, 사회 어느 분야 하나 제대로 돌보지 못하는 대한민국 CEO(?)를 뽑은 우리를 탓해야지. 에휴...

EOB

[B급 프로그래머] 불여우 3 이스터 에그

불여우 3에 숨겨진 이스터 에그에 대한 이야기가 이미 한국 블로거들 사이에 좍 퍼져 있다. 일례로 about:mozilla는 이미 잘 알려져 있고, 3.0에 새로 추가된 about:robots도 쏠쏠한 재미를 준다. 뭐 여기까지야 모질라 팬이라면 이미 다 알고 있는 사실이니 그렇다고 치고...

불여우 3에서 URL 입력창에 about:mozilla를 입력한 다음에 나타나는 이스터 에그인 모질라 서 11장 9절 내부에 숨겨진 뭔가(?)가 있다. 여러분이 직접 한번 찾아보시라. (힌트: 링크 두 개) :P

EOB

[일상다반사] 디벨로퍼웍스 한국어판 7월 2주 기사

요즘 날씨 정말 덥다. 아침부터 시원한 냉커피 한 잔 마시며 글을 정리하니 이제 좀 정신이 든다. 금주 기사는 다음과 같다.

• "누수되는" 보트에서 "C" 탐험이라? Purify를 써보자: 메모리 오류 유형을 유심히 살펴보자. 어디서(?) 자주 보던 패턴 일테니. :P
  
• 유닉스와 리눅스를 함께 어울리게 만들기: NIS, NFS, automounter 사용법 정리
  

LAMP 시스템 조율 기획 기사 모음도 한번 살펴보기 바란다. 과거 기사를 묶어 놓았으므로 참고하면 좋겠다.

EOB

[독서광] 도서구입비 年100만원까지 소득공제 추진

황당무개한 2MB표 쑈를 보고 있으려니 열불이 날 지경인데, 간만에 좋은 소식이 들어와서 급히 정리해본다.

바로... 도서구입비 年100만원까지 소득공제 추진!!! 독서광들에게 얼마나 좋은 소식인가?

개정안에는 근로자 본인 및 기본공제대상자가 지출한 도서구입비를 연말정산시 특별공제 대상에 포함시키고, 그 한도액은 연간 100만원으로 규정한다는 내용이 담겨 있다.

이 법안은 국회 상임위원회 및 본회의 등을 통과할 경우 내년부터 본격 시행될 예정이다.

최구식(무소속) 의원 킹왕짱! 기업에 대한 문화 접대비 세액 공제와 궤를 같이 하는 이번 법안 발의로 인해 한국 출판 업계에 한 줄기 햇살이 들었으면 좋겠다. 이 법안이 상임위원회와 본회의 통과 못하면 반대한 국회의원들 정말 재미 없을거야!

EOB

[독서광] 작지만 강한 기업에 투자하라

재치와 위트가 넘치면 돈이 도망가기라도 하는지 $에 관련되면 누구나 진지해지려고 노력한다. 책도 마찬가지라서 대다수 투자(아니 투기) 관련 서적 중에 낄낄거리면서 읽을 수 있는 책은 찾기가 아주 어렵다. 또한 자기 실패를 진솔하게 드러내는 책은 더더욱 찾기 어렵다. 투기 관련 서적 집필한 사람들은 책 내용대로라면 실수도 한번 안 해본 미다스의 손인가?

오늘은 책을 잃어버리는 바람에(이런 경우도 참 드물지만, 여튼 잃어버렸다. 술이 원수다.), 두 번이나 구입해서 끝까지 읽었고 틈나면 또 읽으려는 책을 소개하겠다. 도토리 펀드(에이콘 펀드)로 유명한 랄프 웬저가 쓴 '작지만 강한 기업에 투자하라'가 바로 주인공이다.

원서 제목을 보면 'A Zebra in Lion Country'다. '사자 나라에 사는 얼룩말'인데, 여기서 사자와 얼룩말이 무엇을 의미하는지는 한국어판 책 뒷면에 아주 잘 나온다.

펀드매너지와 얼룩말은 똑같은 문제를 안고 있다. 우선 둘 다 아주 특별한, 하지만 성취하기 어려운 목표를 갖고 있다. 펀드 매너지는 시장 평균보다 높은 수익률을 올리려 하고, 얼룩말은 신선한 풀을 먹으려 한다. 둘째, 둘 다 리스크를 싫어한다. 펀드매니저는 잘못하면 "잘릴" 위험이있기 때문이고, 얼룩말은 사자에게 잡아 먹히기 때문이다. 셋째, 둘 다 무리를 지어 움직인다. 이들은 생긴 것도 비슷하고, 생각하는 것도 비슷하며, 서로 긴밀한 관계를 맺으며 살아간다.

우왕, 제목이랑 소개글부터 심상치 않다. 내용 역시 범상하지 않아서, 투자서중에 '삼미 슈퍼스타즈의 마지막 팬클럽'이라고 불러도 무방할 듯 하다. 지하철 안에서 읽다가 웃겨서 죽는줄 알았으니, 요 간만에 스트레스를 많이 해소했다.

이 책은 에이콘 펀드에 투자한 투자자를 위한 보고서를 작성해온 짬밥을 바탕으로 여러 가지 재미있는 일화와 비유 흥미로운 역발상등을 많이 싣고 있기 때문에 기존 투자서나 경제 신문(주의: 우리 나라 경제 신문들은 대부분 조중동과 어깨를 겨누는 찌라시성 기사가 많다. 차분하게 읽되 절대로 잘못된 내용에 속지마라!)에 나오지 않는 (아니면 나오더라도 거꾸로 설명하는) 멋진 조언과 통찰력을 즐겁게 획득할 수 있다. 백문이 불여일견이라고 재미있는 내용을 몇 가지 정리해보았다.

몇 해 전 일이다. 새해를 시작하면서 우리 직원들과 함께 근사한 점심식사를 한 뒤 다우존스 산업평균 주가가 그 해 말 얼마가 될지 예상해봤다. 당시 다우 주가는 2190이었는데, 나는 2316을 썼다. 우리 모두 각자 예측치를 적어서 제출했는데, 우연의 일치였는지 나의 아내이자 파트너인 리 젤에게 물어보니 그녀 역시 2316을 예상했다.

"당신 어떻게 해서 그런 주가를 예상했어? 내가 물었다.

"그러니까, 내 생일이 23일이잖아요, 그리고 우리 딸아이 생일이 16일이고, 그래서..." 그녀의 대답이었다.

"말도 안 돼! 세상에 그런 미신이나 믿다니!"

"좋아요, 그런데 당신도 2316을 적었다면서요. 경제예측을 잘 하시는 당신께서는 왜 그렇게 예상했지요?"

"그야 간단하지. 내가 다니는 헬스클럽의 회원번호가 2316번이잖아."

좋은 뮤추얼펀드는 어떻게 고를까? 내가 늘 하는 말이 있다.:
알파벳 순서대로 골라보세요.

내가 관심을 갖고 있는 주식을 평가할 때 가장 잘 쓰는 방법은 "그러면 사직서를 쓸까?"라고 나 자신에게 물어보는 것이다.

이런 식이다. 누가 나에게 전화를 걸어 씨티뱅크에서 내가 눈 여겨보고 있는 어느 회사의 주식을 현재 시작 가격으로 전부 매수할만큼의 돈을 빌려주기로 했다고 말해준다. 그렇다면 나는 과연 지금의 뮤추얼펀드 사업을 접고, 이 회사를 인수해서 경영할 자신이 있는가?

... "그래 이거야, 기 회사라면 내 전부를 바칠 만하지." 이런 기업이 바로 내가 확신을 갖고서, 신이나 서 매수하는 주식이다.

재미있는 이야기도 많이 나오지만 눈물 나는 경험담도 나온다. 1987년 주식 시장 대 폭락 과정에서 망가진 일화를 솔직하게 기술하는 부분을 읽다보면 가슴이 찡해진다.

목요일 점심을 먹으러 가는 길에 나는 우리 회사 직원들에게 이렇게 물어봤다. "자네들은 하늘에서 가장 크고 밝게 빛나는 게 뭐라고 생각하나?" 이들은 어리둥절해하며 당연히 태양이라고 대답했다. "하늘에 떠 있는 태양은 지난주와 똑같지?" 내가 다시 묻자 이들은 고개를 끄덕였다. "그럼 됐어. 주식 시장이 좀 큰 폭으로 떨어졌다고 해서 세상이 바뀌지는 않았을 거야." 나는 이렇게 결론지었다.

직접 투자를 하든 간접 투자를 하든 이 흥미로운 책은 꼭 읽어보기 바란다. 강력 추천!

[일상다반사] 디벨로퍼웍스 한국어판 7월 1주 기사

드디어 2008년도가 절반이 꺾이는 시점이다. 애독자 여러분께서 연초에 계획한 모든 일이 순조롭게 되어가시는지? 다들 초심을 잃어버리지 않도록 신발끈 다시 한번 동여매면 좋겠다. 오늘은 7월 1주 기사를 소개하겠다.

• 파이어폭스 3.0 제자리에!: 불여우 3.0에서는 오프라인에서도 작업을 계속할 수 있는 기능이 추가되었다. 구글 docs도 이런 기능을 쉽분 발휘한다면 진짜 오프라인 오피스 시스템이 가능해지지 않을까 조심스럽게 추측해본다.
  
• 프로젝트 이해 관계자의 권리와 책임: 프로젝트 이해 관계자의 권리와 책임에 대해 간략하게 정리한 기사다.
  

디벨로퍼웍스 번역도 벌써 4개월째로 접어들고 있는데, 여러 독자분들께서 좋은 피드백을 많이 주셨다. 리눅스/유닉스와 웹/XML 쪽으로는 하던 짬밥이 있어서 큰 무리없이 진행 중이지만, 아키텍처나 애자일 부분에는 여전히 부족한 점이 많다. 따라서 앞으로도 독자 여러분께서 많이 도와주시면 감사하겠다.

EOB

[일상다반사] 아이폰에서 웹 브라우저 개발이 가능할까?

아이폰에 파어어폭스가 없는 이유는?이라는 기사가 떠서 읽어봤는데 다음과 같은 문구가 눈에 들어왔다.

"애플의 라이선스 요건을 읽었더니 코드를 해석하는 소프트웨어는 받아들이지 않는다고 명시돼 있었다. 자바도, 플래시도, 코드를 해석하는 브라우저도 받아들이지 않는다는 것이다. 애플은 광범위하게 타사를 배제하고 있다"

잽싸게 아이폰 개발자 센터로 들어가서 라이선스를 확인하려고 했더니 로그인이 필요하단다. 그래서 기존 애플 개발자 아이디로 로그인했더니 아이폰 개발자 등록을 해야 한다고 이런 저런 질문을 한다. 발톱 감추고 입력을 마친 다음에 로그인해서 라이선스 문서를 내려받아 읽어보니... 음냐...

No interpreted code may be downloaded and used in Application except for code that is interpreted and run by Apple's Published API and built-in interpreter(s).

무슨 말인고 하니 인터프리터 방식 코드는 여러분이 만든 응용 프로그램에서 내려받아서 사용할 수 없다는 말이다. 즉, 자바, 플래시 이런 코드는 당근 안 되고... HTML/CSS도 경우에 따라서는 치열한 법리 논쟁이 필요하지 않을까 하는 생각이 든다. 당근 파이어폭스는 HTML을 동적으로 해석(!)해야 하니 애플이 만든 아이폰 SDK를 사용해서 컴파일할 경우 라이선스 위반에 걸릴 가능성이 높은 셈이다. 결론적으로 말하면 애플이 아이폰 SDK를 공개했지만 여전히 절반에 그친다는 생각이다. 하지만 휴대폰 업계에서 또 다른 선수인 심비안이나 안드로이드 진영은 오픈 소스 라이선스를 택하기 때문에 향후 애플을 압박할 가능성도 있다(애플이 이런 압박에 넘어갈지는 예측 불허니 인생이 재미있는거다. ㅎㅎ).

여러분들도 (공명심에) 아이폰 SDK로 (심지어 여러분이 독자적으로 인터프리터 언어를 개발했을지라도) 인터프리터 언어를 이식해서 공개하면 라이선스 위반에 걸린다는 사실을 꼭 기억하고 비싼 장난감을 조심스럽게 갖고 놀기 바란다.

EOB

[일상다반사] 여름방학에 네트워크 공부를 어떻게 할까?

어제 학생 블로그 애독자분께서 질문을 하나 해주셨다. 질문 핵심만 발췌하면 다음과 같다.

네트워크 분야를 개론적으로 공부해보고 싶은데 정보가 부족해서 도움을 받을 수 있을까 하여 이렇게 매일을 보내 봅니다. 물론 인터넷에서 직접 찾아 보고 도서관에서도 책을 찾아 보고 하였지만 그 종류도 수십가지이고 특히 네트워크에서는 TCP/IP분야를 집중적으로 다루고 있는 듯 하여 선택이 쉽지 않았습니다.

그래서 선생님께서 혹시라도 저같은 학생들(입문자, 컴퓨터 공학도?)들이 숲을 볼수 있을 추천할 만한 책을 알고 계실까 해서 이렇게 매일을 보내 봅니다.(원서도 상관없고 국내서면 더욱 좋겠습니다 :)

그래서 어제 오늘 오가는 지하철 안에서 어떤 조언을 해줄까 고민했는데, 일단 네트워크 학습 분야에 대한 지도를 그리는게 우선이라는 생각이 들었다. 100% 정확하지는 않지만 우선 방향을 제시하는 큰 그림을 그려보자.

• 네트워크 개론: 네트워크 역사, 이론, 기술 발전 방향, 구성 요소, 아키텍처
  
• 네트워크 관리: 네트워크 배선, 전용 장비, 서버 관리
  
• 네트워크 프로토콜: 다양한 물리/논리 네트워크 프로토콜 명세, 네트워크 상에서 돌아가는 응용 프로그램 사이에 주고받는 서비스 프로토콜 명세
  
• 네트워크 응용 프로그램: 네트워크 프로토콜을 구현하는 시스템 프로그래밍
  

자, 큰 지도를 그렸다면, 다음으로 할 일은 지도에서 목적지를 정하는 작업이다. 방학 두 달 동안 이 모든 영역을 탐험할 수 있다면 좋겠지만, 유감스럽게도 한 곳만 방문하기에도 힘이 드는 상황이다. 예를 들어 네트워크 관리를 공부하고 싶다면, 시스코, 주니퍼... 등등 다양한 회사에서 나오는 다양한 전용 라우터 제품에 집중할 수도 있고, 윈도우 NT 서버를 사용한 네트워크 관리나 유닉스/리눅스를 사용한 범용 네트워크 관리 방법에 집중할 수도 있다. 네트워크 프로토콜을 공부하고 싶다면 이더넷이나 토큰 링과 같은 물리적인 프로토콜 명세에 집중하거나, 물리적인 프로토콜 위에서 돌아가는 TCP/IP나 IPX와 같은 논리적인 프로토콜 명세에 집중하거나, 논리적인 프로토콜 위에서 돌아가는 HTTP, FTP, SMTP와 같은 서비스 프로토콜에 집중할 수도 있다. 세부 사항을 다루는 책은 여기저기 많이 나와있고, 리눅스와 같은 실험적인 프로토콜을 모두 키우는 동물원식(?) 운영체제를 탐험하다보면 거의 대부분 이론적인 네트워크 프로토콜이 다 들어있음을 깨닫게 된다. ㅎㅎ

숲을 이해하려면 나무를 봐야하고 나무를 보려면 숲을 조감해야 하는 딜레머에 빠지는데, 네트워크 입문서(숲) 달랑 한 권만 읽어서는 감이 안 올거구(솔직히 따분한 옛날 이야기 읽다보면 시간 낭비가 될 가능성이 높다), 그렇다고 BSD TCP/IP 스택 원시 코드(나무에 붙은 가지)만 파서도 감이 안 올거다(왜 이렇게 구현했는지 모르고 덤비면 100전 100패다). 결국 가장 좋은 방법으로... 방학동안 머리를 산뜻하게 만들고 삶의 동기를 부여해주는 재미있는 책이나 실컷 읽고, 학기 중에 열심히 성심성의껏 네트워크 과목을 수강하면 되겠다.

위에 조언은 1/2 농담이었고(:P)... 방학동안 네트워크 관련 책을 읽고 싶다면 지인이 알려준 The Switch Book을 추천한다. 아마존 별 5개(15/15)를 기록하고 있는데, 재미있고 명쾌하고 짧기 때문에 여름 방학 동안 충분히 독파가 가능하지 않을까 싶다. 아마존 서평이랑 책 설명이랑 목차(search inside)를 잘 보고 자신이 원하는 분야인지 먼저 살펴본 다음에 구입하시면 좋겠다.

EOB

[일상다반사] 디벨로퍼웍스 한국어판 6월 4주 기사

장마가 시작된 줄 알았더니 날씨가 아주 화창하다. 이번 주도 변함없이 더운 여름을 식혀주는 기사 몇 개를 소개드리겠다.

• PS3에서 리눅스 개발, Part 1: 장난감을 넘어: PS3에서 리눅스를 활용하는 방안을 소개하는 기사다. 특히 모니터 조정 방법을 다룬다.
  
• 활발한 이해 관계자 참여: AM 후속 기사다.
  
• 소프트웨어 엔지니어링 이해하기: 학생 관점에서 바라본 모습: 이 기사 읽기 전에 우선 이 글부터 읽어보시라.
  

그리고 스크린캐스트 이벤트가 떴으니 혹시 맥북이 탐나는 분들께서는 응모해보심이 어떨지? :)

EOB

[일상다반사] (번역) 소프트웨어 공학이라는 단어를 묻어버리자.

디벨로퍼웍스 한국어판 번역을 하다가 치명적인 오역을 저질렀는데, 다행히도 독자분께서 날카로운 피드백을 주셨다. 이렇게 잘못된 부분은 분명하게 지적해주시면(잘못된 부분을 지적하는 글을 블로그에 올리신 다음에는 저에게 전자편지로 알려주시면 더욱 좋겠다. RSS 피드와 구글 검색 엔진도 한계가 있으니까...), 똑같은 실수는 반복하지 않겠다(약속~~~). 다시 한번 말하지만 온라인 기사 특성상 언제든지 수정이 가능하므로, 기사를 읽다가 의문 사항이 생기면 일단 원문을 참조해서 이상한 부분을 확인한 다음에 피드백을 주시면 확인 후 바로 반영하겠다.

실수를 했으니 밧데루 하나 먹어야 겠다. 벌칙으로 이번 주에 실릴 디벨로퍼웍스 기사와 관련이 있는 흥미로운 기사를 하나 번역했다. 원문은 Let's Bury the Term Software Engineering이며, 좀 논란의 여지가 있는 내용이므로 jrogue군의 생각을 대변하지 않는다는 사실을 밝혀둔다.

이 기사를 읽고 여러분 생각은 어떤지 댓글을 달아주시면 아주 감사하겠다. 이번 주에 올라올 관련 디벨로퍼웍스 기사를 읽고 나서 여러분 생각이 어떻게 바뀔지 무척 궁금하다. :) 서두가 길었다. 자, 그러면 시작한다.

소프트웨어 공학이라는 단어를 묻어버리자

Daryl Kulak

2007년 11월 10일 토요일 작성

소프트웨어 공학은 소프트웨어 설계자와 개발자들이 하는 작업을 묘사하는 정확한 방법이 아니다. 우리는 무엇을 원하는지 조차 정확하게 모르는 비즈니스족의 기대를 충족하기 위해 끊임없이 변하는 환경에서 소프트웨어를 만든다. 소프트웨어가 공학이라는 말처럼 들리는가? 이 기사에서 토론하겠지만, 물리적인 공학도는 보편적인 물리 법칙을 다루지만 소프트웨어 설계자와 개발자들은 가차없는 변화를 다뤄야 한다. 우리 직업을 묘사하기 위해 공학이라는 단어를 사용함으로써, 우리는 스스로를 정적인 프로세스와 변화를 일상 생활에 스며들게 하는 대신 변화를 억누르려는 경향이 있는 불안정한 팀 구조에 묶어버린다. 소프트웨어, 사람, 프로세스를 공학적으로 다룬다는 관점에서 벗어나도록 우리 마음을 움직일 수만 있다면, 우리 팀은 좀더 서로에게 공명을 일으키며, 높은 생산성을 발휘하며, 변화에 기민하게 대응하는 모습을 발견할 것이다.

비교를 위해, 교량 설계와 건설을 맡은 물리 분야 공학도를 잠깐 살펴보자. 소프트웨어 개발자와 유사하게 공학도는 문제를 정의하고(강을 가로지르기 위한 길), 해법을 설계하고(청사진), 해법을 만든다(완성된 교량). 또한 프로세스 과정을 진행하기 위해 상당한 재료 실험도 들어간다.

교량 건설 vs 소프트웨어 개발

교량 건설 공학도의 주된 관심사는 미적인 측면이 아니라 교량이 얼마나 오래 버티며 무너지지 않을지를 확신하는 데 있다. 공학도는 자신이 성공했다는 사실을 입증하기 위해 여러 제약 조건과 맞붙어 싸워야 한다. 제약 조건은 고객 기대치를 포함하지만, 핵심적인 제약점은 주로 물리 과학과 관련이 있다. 빔이 위치할 장소와 볼트가 들어갈 장소는 설계를 강화하거나 파괴할지도 모르는 물리 법칙이 지배한다.

자 이제 소프트웨어 개발자 차례다. 우리 역시 특정 문제를 해결하기 위해 고용되었다. 분석하고 설계하고 만들고 테스트하고 배포한다. 여기까지는 교량 공학자의 역할과 유사하다. 하지만 제약 사항과 관련한 쟁점은 다르다. 물리학이 소프트웨어 설계자에게 큰 고려 대상이 아닌 이유는 우리가 만든 최종 제품은 만질 수 없기 때문이다. 하지만 우리에게는 다른 제약 사항이 있다. 우리 제약 사항은 비즈니스 규칙과 우리 이해 관계자의 정보 요구에서 비롯된다. 비즈니스 규칙과 이해 관계자는 개발 노력 경계/범위를 결정한다.

이제 두 가지 제약 사항을 비교해보자. 교량 공학도는 물리 법칙에 따라 일한다. 우리는 이해 관계자가 품고 있는 기대에 따라 일한다. 물리 법칙은 잘 알려져 있고, 잘 문서화되어 있으며, 상황에 무관하며, 변하지 않는다. 하지만 소프트웨어 이해 관계자가 품고 있는 기대는 일반적으로 잘 알려져 있지 않으며(심지어 이해 관계자 스스로도 모른다), 제대로 문서화되어있지 않으며, 상황에 밀접하며, 휘발성이 아주 강하다. 비행기 안에서 대표이사가 읽은 잡지 기사 때문에 진행 중간에 급격하게 요구 사항이 바뀐 프로젝트를 본적도 있다. 여러분도 마찬가지 경험을 했으리라. 때로 변화는 어이 없어 보일지도 모르며 때로 명확한 비즈니스 요구 사항일지도 모르지만, 어찌되었거나 소프트웨어 개발에서 변화는 빠지지 않는다.

변화가 바로 핵심적인 차이점이다. 소프트웨어 개발자들은 교량 공학도보다 프로젝트 생명 주기 동안에 더 많은 변화를 다뤄야만 한다. 물론 공학도는 작업이 진행됨에 따라서 문제에 대해 더 많은 사실을 익힐 것이다. 공학도는 특정 지역이 기대보다 덜 단단하다는 사실을 발견하고 이런 이유로 인해 전략을 바꿔야할지도 모르지만, 원래 문제와 물리 제약은 그대로 남아있다.

여기서 한가지 짚고 넘어가겠는데, 여기서 교량 공학도 작업이 쉽다고 말하려는 의도는 없다. 교량 건설은 엄청나게 어렵고 위대한 지성, 훈련, 창의성을 요구한다. 사회가 의존하고 있는 물리적인 구조물을 건설할 책임이 있다고 생각해보라! 하지만 내가 말하는 요점은 소프트웨어 개발 작업과 교량 건설은 근본적으로 다르다는 사실이다.

사람들 역시 달라요.

변화는 단지 차이점을 구성하는 한가지 요소일 뿐이다. 교량 공학도에게서 찾아보기를 원하는 다른 특성을 생각해보자. 교량 공학에서 "전문가 정신"은 무엇을 의미하는가? 특정 직업을 분류하기란 어렵지만 교량 공학도에게 진정으로 필요한 요소가 정확성, 정밀성, 꼼꼼함이라는 사실을 엿볼 수 있다. 이런 특성은 일반적으로 제품 위주지 사람 위주는 아니다.

이제 소프트웨어 개발에서 전문가 정신을 생각해보자. 다시 한번 말하지만 여기에는 중요한 차이점이 있다. 우리 대다수는 제품 위주가 아니라 사람 위주에 가까운 특성이 있다. 내가 지금까지 만난 최고 프로그래머는 너무 꼼꼼하거나 좀스럽지 않았다. 최고 프로그래머는 종종 창의적이고, 변화를 좋아하며, 심지어 괴짜이기도 했다. 틀림없이 최고 요구 사항 분석가는 집중력이 강하고 세부 사항에 몰입하는 공학도 유형은 아닐테다. 요구 사항 분석가는 종종 딱 떨어지지 않는 기능 요구 사항을 이해해서 비즈니스 부서나 비즈니스 사람들 영역에서 일어나는 변화와 불확실성을 다뤄야만한다. 테스터는 좀더 꼼꼼할지도 모르겠지만, 테스터 역시 소프트웨어 생명 주기 동안에 필연적으로 벌어지는 변경을 감내해야만 한다. 시련을 견뎌내는 특성은 아마도 소프트웨어 개발자에 있어 가장 바람직한 개인적인 미덕이다.

하지만 "조금 괴짜"이거나 "세부사항에 목숨걸지"않는다고 고백한 공학도가 설계한 교량 위로 차를 몰고 간다고 생각하면 어떨까? 맙소사!

소프트웨어에서, 우리는 세부 지향적인 특성을 사람 지향적인 특성과 결합한 팀을 원한다. 우리는 꾸준히 우리가 실제로 잘못된 문제를 풀고 있을 가능성에 대비해서 방어책을 마련할 필요가 있다. 따라서 우리 주변에 그다시 세부적이지 못한 사람이 이런 사실을 알려주기를 원한다. 공학도가 잘못된 강을 가로지르는 교량을 만드는 경우는 극히 드물다. 따라서 공학도는 우리처럼 잘못된 문제를 풀지도 모른다는 걱정은 하지 않는다.

변화를 억누르지 않도록 격려하세요

그렇다면 몇몇 사람들은 심지어 더 이상 사용하지조차 않는 용어를 피해야 한다고 도시락 싸들고 다니며 말리는 이유가 무엇일까? 실제로 용어 자체가 문제가 아니라 용어가 우리 팀에게 의미하는 바가 문제다. 우리 스스로를 공학도라고 생각할수록 우리는 해법, 프로세스, 사람을 공학적으로 다루려고 노력할 것이다. 공학적인 모델은 정적인 물리 구조와 기계를 만들어 내기 위해 창안되었다. 이는 끊임없는 변화와 흐름을 다루도록 고안된 개념이 아니다. 수 많은 변화가 일어난다는 사실을 안다면 우리 모두는 다른 식으로 해법에 접근해야 한다. 변화가 필요한 교량을 상상해보자. 빌딩 블록 집합으로 만들어서 분리한 다음에 재빨리 다른 강으로 이동할 수 있어야 한다. 실제로 군대에서는 임시 가교 건설에 상당히 능숙하다. 하지만 대다수 교량 공학도는 변화가 일어나야 하는 뭔가를 만드는 데 익숙하지 않다.

소프트웨어 개발에서, 변화는 우리의 끊임없는 동반자가 되어야 한다. 개발 생명 주기 동안에 일어날 변화를 다룰 준비가 되어있어야 한다. 비즈니스가 변화함에 따라서 양산에 들어간 다음에도 바뀔 수 있는 소프트웨어를 창조할 필요가 있다. 객체-나 컴포넌트- 접두어가 붙은 새로운 설계와 프로그램 패러다임은 끊임없는 변화를 촉진하는 데 사용할 도구다. RUP와 같은 반복적이고 점진적인 생명주기와 여러 애자일 프로세스는 생명 주기를 통틀어 요구 사항과 기타 요인이 바뀌는 변화에 대응하는 방법을 제공한다. "변화를 다룬"다고 말할 때, 전형적인 변경 관리에 대해 이야기할 생각은 없다. 변경 관리 모델은 의미있는 방식으로 변화를 다루지 못한다. 변경 관리 모델은 변경 억제 모델이다. 이 기사에서, 나는 정말로 비즈니스에서 일어나는 변화를 수용해서 (이를 멈추는 방법을 찾는 대신) 일상에 편입하는 방법을 설명하고 있다. 진짜 공학적인 접근 방식은 당연히 그래야겠지만 변경 억제에 초점을 맞춘다.

소프트웨어 부문에서, 변화를 억누르면 실패가 생기기 마련이다. 우리에게 주어진 제약은 변화와 한묶음으로 붙어 다닌다. 우리에게 주어진 제약은 사람의 기대, 요구, 바람, 감정이다. 마이크로소프트 사에서 비즈토크 리드 프로그램 관리자를 맡은 Jeanne Baker가 말한 바에 따르면 "우리 제품 관리자는 프로젝트 시작 시점에서 원했던 해법이 아니라 프로젝트 끝 무렵에 원하는 해법을 바란다"라고 말했다. 일반적으로 두 가지 다른 점이 있다. 우리는 우리 프로세스를 비즈니스 사람들의 기대치와 일치하도록 만들어야 한다. 우리 프로세서를 너무 공학적으로 다루면, 생명 주기 끝부분에 원하는 해법을 비즈니스 사용자에게 제공하지 못한다.

창의성을 말살하지 마세요

다행스럽게 공학적인 마음가짐이 우리 프로세스를 망가뜨리는 현상을 눈으로 확인할 수 있다. 공학적인 마음가짐은 또한 우리 사람을 망가뜨린다. 고도로 공학적인 프로세스와 조직적인 구조는 일하기에 즐거운 장소가 아니다. 관리자 입장에서 만들고 관리하기가 가장 쉬운 조직 유형은 기계와 유사한 구조라는 생각이 들지도 모르겠다. 모든 사람은 제대로 정의된 작업을 수행한다. 작업 전환은 명쾌하고 똑 부러지며 혼동이 없으며 효율성만 강조될 뿐이다. 하지만 사람을 기계 톱니 바퀴로 여기면 제약이 너무 크다. 관리자로서 여러분은 효과적으로 각 개인의 창의성을 차단할 수 있다. 그리고 창의성을 차단함으로써 변화를 가능하게 만드는 조직 능력을 억누른다. Inner Edge 잡지 편집자였던 Carol Pearson은 "끊임없는 창의성은 끊임없는 변화라는 도전에 맞서 싸우도록 만든다"라고 말했다. 창의성은 "변화에 준비된" 팀을 만들어내는 유일한 방법이라고 강조하고 싶다.

모든 인간은 일을 포함해서 각자 삶을 개선하기를 원한다. 뭔가를 수행하는 더 좋은 방법이 떠오르면, 바로 시도해보기를 원한다. 하지만 아주 공학적인 기계 조직에서는 다양한 새로운 아이디어를 다루지 못한다. 항상 누군가 변화를 추구하기 시작하면, 나머지는 변화의 충격으로부터 꼼짝 달짝 하지 못하리라는 공포심이 팽배해있다. 사람들이 기계처럼 행동하기를 원하는 조직에서 아주 당연한 현상일지도 모르겠다.

사람과 프로세스를 기계처럼 다루면 안 된다는 방식에 초점을 맞출 때, 우리가 창조하는 소프트웨어가 최종적으로는 기계라는 사실에 주목할 필요가 있다. 우리가 겪는 문제는 실제 동작하는 소프트웨어 영역을 벗어난 외부인, 즉 우리 세상에서 나머지 구성 요소인 사람과 프로세스로 기계 은유를 확장할 때 일어난다. 하지만 우리가 만든 기계가 단순히 코딩 대상이며 실행 가능한 소프트웨어 자체라고 생각을 제한할 수 있다면, 과도한 공학 문제를 겪지는 않을 것이다.

사람들의 삶을 향상시키고 직원과 팀원을 행복하게 만드는 과정에 도움을 주는 아이디어를 여기에 소개했다. 또한 스스로 진행하는 작업에 좀더 많은 통제권을 부여함으로써 행복을 달성하는 방법을 설명했다. 나는 회사에서 사람들이 느끼는 행복이 파티, 보상, 축하, 더 큰 사무실, 인정과 같은 일반적인 수단으로 개선될 수 있다고 말하지 않았다. 대부분, 이런 피상적인 행복 추구 방식을 따르더라도 사람들이 회사에서 느끼는 행복은 오래 지속되지 못한다.

지금까지 시멘트를 붓거나 호텔에서 청소를 하는 등 노동을 해봤다면, 스스로 개선을 경험할 수 있을 때 직업이 좀더 즐거우며, 그렇지 못할 때 즐겁지 않다는 사실을 깨닫고 있을 것이다.

변화를 위한 공학은 불가능하다

그러면 단순히 "변화를 위한 공학은 없는가? 그렇다. 진짜로 없다. 공학적인 기계 모델을 따르는 조직에서 여러분 팀은 조직을 위해 모든 가능한 변화 유형과 공학적인 측면을 예상해야 한다. 이런 작업은 불가능하다. 기계는 주변 환경 변화에 대응해서 창의적으로 반응하지 못한다. 무엇을 해야할지 알려줘야만 한다.

여러분은 작업 대상과 수행 방법에 광범위한 책임과 유연성을 부여함으로써 팀원들이 각자 맡은 작업을 개선하도록 도울 수 있다. 이렇게 하면 "혼돈의 왕국"을 만드는 대신 이따금 창의적인 분위기를 팀 내부에 스며들게 도와준다.

우리 프로세서와 개발자는 공학에서 벗어나는 편이 좋다. 그렇다면 "소프트웨어 공학"이라는 용어를 대신할 후보는 무엇일까? 가능성이 아주 많으며, 선택은 전적으로 당신에게 달려있다. 소프트웨어 개발이라고 부르면 그리 억지스럽지는 않다. 이 용어는 우리가 이미 광범위하게 사용하고 있기 때문이다. 다른 용어 후보로 소프트웨어 창조나 소프트웨어 통합이 있는데, 정적인 구조를 중요하게 여기지 않도록 도와준다. 소프트웨어 공학을 대신할 가장 적합한 용어를 찾는 작업은 소프트웨어, 사람, 프로세스를 공학적으로 다룬다는 관점에서 멀리 떨어지도록 우리 마음을 움직이는 노력보다 절박한 상황은 아니다. 우리 마음을 다스릴 수만 있다면, 우리는 크게 발전한 셈이다.

저자 소개

Daryl Kulak은 나스닥에 상장한 IT 컨설팅 회사인 Perficient에서 방법론 코치를 맡고 있다. Daryl은 Use Cases: Requirements in Context (Addison Wesley, 2003) 공동 저자이며, 2008년 가을에 새로 나올 Agile + Rigor을 Dr. Hong Li와 함께 집필했다. Daryl은 오하이오 주 컬럼버스 시에 살고 있으며, 소프트웨어 개발 프로세스와 팀 개선을 위해 고객과 함께 일한다.

[일상다반사] 디벨로퍼웍스 한국어판 6월 3주 기사

드디어 장마가 시작된 모양이다. 계속 내리는 비를 바라보며, 컴퓨터 앞에 잠시 앉아서 기사를 읽는 여유를 즐기시기 바란다. 6월 3주 기사는 다음과 같다.

• 리눅스 시스템 호출을 활용한 커널 명령: 리눅스 시스템 호출을 추가하는 방법을 설명한다.
  
• 애자일 모델링(Agile Modeling, AM): AM에 대한 진짜 간략한 소개(1분 짜리 메모 수준)
  
• 전사적 아키텍처의 핵심, Part 2: 전사적 아키텍처 저장소 개발과 관리: 전사적 아키텍처 저장소 관련 내용을 설명한다. 조금 따분할지도. ;)
  

이번 주에는 튜토리얼도 하나 있다.

• vi 입문 -- 컨닝 페이퍼 이용하기: 제목 한번 그럴싸하지 않은가? vi 초보라라면 꼭 읽어보시라. 원래는 해님이 손수 컨닝 페이퍼를 손으로 그리려고 했는데... 시간 관계상 그림판으로 조작(?)했다. 족보 제조기로 알홈다운 이름을 날렸던 해님이 진짜 손으로 그렸으면 감동 물결쳐서 몇 명 병원에 실려갔을텐데 넘넘 아쉽다. 다음 기회를 기다리자. ㅎㅎ
  

보너스로 지난 달 인기 10 기사 목록을 살펴보기 바란다. 그러면 내주 좋은 기사로 여러분을 다시 찾아뵙겠다. 꾸벅~~

EOB

[독서광] 프리젠테이션 젠: 생각을 바꾸는 프리젠테이션 디자인

청중 앞에서 발표를 누구나 잘하고 싶어한다. 스티브 잡스처럼 멋지게 발표하면 좋겠지만 발표자료도 깔끔하게, 내용도 영향력을 발휘하기란 아주 어렵다. 발표를 해본 사람이면 누구나 다 아는 진리다.

이번에 에이콘 출판사에서 나올 신간 서적인 프리젠테이션 젠: 생각을 바꾸는 프리젠테이션 디자인은 멋진 발표를 꿈꾸는 사람을 위해 나온 책이라는 생각이다. 특히 시각적인 효과를 극대화해서 정확하게 청중을 사로잡는 꿈을 꾸는 사람이라면 저자가 주장하는 바를 유심히 관찰할 필요가 있겠다.

이 책이 아마존에서 놀라운 점수(별 다섯 47/총 평가 인원 56)를 획득한 이유는 책을 떠나서 저자가 운영하는 블로그를 살펴보면 감이 올 것이다. 아기자기한 사진, 적절한 그림, 좋은 예제와 설명이 곁들어져 한편의 발표 자료를 보는 느낌이 든다. 이런 느낌을 오프라인으로 가져오면 바로 '프리젠테이션 젠'이라는 블로그와 동명의 책이 된다고 보면 틀림없겠다. 물론 온라인과 오프라인은 성격이 다르므로 풀어나가는 표현 방식에는 차이가 있겠지만 근본 철학은 동일하다. 바로 '자제, 단순함, 자연스러움'이다. 말은 쉽지만 실천은 무척 어려운 요소이므로 이 책을 그냥 화려하고 기교를 부린 파워포인트 작성 기법을 다루는 책으로 착각하고 구입하면 큰 코 다칠지라... 자세한 독후감은 한국어판을 읽은 다음에 바로 올려드리기로 약속한다.

| View | Upload your own

EOB