검색엔진

월요일, 6월 30, 2008

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



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



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


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



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

금요일, 6월 27, 2008

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

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



네트워크 분야를 개론적으로 공부해보고 싶은데 정보가 부족해서 도움을 받을 수 있을까 하여 이렇게 매일을 보내 봅니다. 물론 인터넷에서 직접 찾아 보고 도서관에서도 책을 찾아 보고 하였지만 그 종류도 수십가지이고 특히 네트워크에서는 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월 25, 2008

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

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





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



EOB

월요일, 6월 23, 2008

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

디벨로퍼웍스 한국어판 번역을 하다가 치명적인 오역을 저질렀는데, 다행히도 독자분께서 날카로운 피드백을 주셨다. 이렇게 잘못된 부분은 분명하게 지적해주시면(잘못된 부분을 지적하는 글을 블로그에 올리신 다음에는 저에게 전자편지로 알려주시면 더욱 좋겠다. 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월 18, 2008

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

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





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


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


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



EOB

월요일, 6월 16, 2008

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



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



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



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





EOB

[독서광] 위대한 기업에 투자하라



경제/경영(?) 블로그로 등록되어 있는 jrogue 블로그에서 요즘 경제/경영 서적을 안 다뤘더니 몸이 다 근질거릴 지경이다. 책이 밀려있긴 하지만 요즘 조금 여유가 없어서 독서평을 올리지 못할 따름이니 안심하시라. 오늘 살펴볼 내용은 고전 중의 고전으로 일컬어지는 필립 피셔가 쓴 '위대한 기업에 투자하라'다.



우선 필립 피셔라는 인물에 대해 생각을 해봐야 한다. 1950년대에 이미 '성장주'라는 놀라운 개념을 세운 피셔는 투자 대상 기업을 선별하는 현대적인 방법을 제시함으로써 형님 워렌 버핏도 큰 형님이라고 치켜세우는 한마디로 주식 투자의 킹왕짱이라고 보면 틀림없겠다. 물론 워렌 버핏만큼 큰 돈은 벌지 못했지만 피셔 큰 형님의 영향력 하나는 아직도 대단하다는 생각이다.



'위대한 기업에 투자하라'는 필립 피셔가 주식 투자에 대한 자기 철학을 정리한 기본서이므로, 이해하기도 쉽지 않고 실천하기는 더욱 쉽지 않지만 21세기인 요즘도 무릎을 탁 치는 좋은 내용이 들어있는 책이므로 '투자'(아니 '투기')에 관심이 있는 독자분이라면 꼭 시간을 내어 정독하면 좋겠다.



피셔는 이 책에서 사실에 근거한 회사 분석 기법을 정리한 다음에, 이를 토대로 투자 대상 기업을 찾는 방법에 대해 15가지 포인트를 제시하면서 이런 조건을 만족하는 회사를 선택하면 장기적으로 성공할 가능성이 아주 높다고 역설한다. 그리고 주식 투자가라면 누구나 궁금해하는 주식을 사는 시점과 파는 시점에 대해 말하며, 흔히 세상에 알려져 있는 상식과 다르게 배당주가 그다지 매력이 없는 이유를 말해준다. 다음으로 투자자가 저지르지 않아야 하는 잘못을 다섯 가지 + 추가 다섯 가지로 나눠서 가슴이 뜨끔할 정도로 날카롭게 조언한다. 그리고 자신의 '성장주'(!) 선택 노하우에 대해 이야기 보따리를 풀어놓는다. 구체적인 15가지 포인트와 열 가지 잘못은 직접 책을 읽으면서 고민해보기 바란다.



목차만 보더라도 주식 투자를 하는 사람들이 밟아야 할 정도를 제대로 짚어주고 있다는 생각이 든다. 이 책은 읽을수록 내용이 새롭게 다가오므로 언제 어느 때고 투자에 대해 다시 한번 생각할 시점에서 도움을 받을 수 있다.



본문 중 아름다운 내용 몇 가지를 추려본다.



파업이 전혀 없는 기업 가운데는 마치 공처가 남편을 둔 가정과 같은 곳이 있다. 갈등이몰고 올 파장을 두려워해서 갈등을 일으키지 못하는 것은 결코 행복한 관계라고 말할 수 없다.
(기업 뿐만 아니라 사람 사는 어디에도 적용되는 원리다.)

최고 경영자가 일상적인 잡무까지 전부 간섭하고 처리하려고 하는 기업은 절대 매력적인 투자 대상이 될 수 없다.
(개인적으로 한마디 하자면 마이크로매니지먼트가 판치는 회사에 다녀봤는데(사장이 야근하며 프로그램 짠다고 혼자서 난리 법썩을 떠는 재미있는(?) 곳이였다. 낄낄), 투자 대상은 물론이고 근무 대상도 될 수 없다.)

오늘날 주식 투자와 관련있는 일을 하는 고급 인력들이 향후 경기 동향을 예측하기 위해 바치고 있는 노력의 단 얼마만이라도 더 생산적인 목적에 사용한다면 정말로 놀라운 결과를 가져올 수 있다.
(숫자놀이 그만하고 생산적인 일을 하자는 말이지?)

주식투 자의 두 가지 중요한 특징은 큰 이익을 얻기 위해서는 자신을 잘 다스려야 한다는 점과 이런 통제를 위해서는 고도의 기술과 지식, 판단력이 필요하다는 점이다.
(이건 jrogue군이 아주 중요하게 생각하는 원칙인데, 필립 피셔 큰 형님도 똑같은 이야기를 해서 너무 기뻤다.)

약세장이 임박했다는 이유만으로 빼어난 성과를 보여주고 있는 주식을 팔아서는 절대로 안되는 더욱 중요한 이유가 또 하나 있다. ... 물론 이론적으로는 주가가 충분히 다 떨어진 다음에 매수해야 한다. 그러나 이것은 주가 하락이 언제 끝날지를 투자자가 정확하게 알고 있다는 전제가 있다.
(이래서 적립식 펀드를 사용해서 장기 투자를 하면 유리하다)

주식을 매수할 때 해야 할 일을 정확히 했다면 그 주식을 팔아야 할 시점은 거의 영원히 찾아오지 않을 것이다.
(멋져!)

어떤 주식이 지난 몇 년간 올랐다거나 오르지 않았다는 사실은 현재 주가 수준을 결정하는 데 전혀 중요하지 않다. 정말로 중요한 것은 지금 시장이 결정한 주가 수준보다 주가를 결정적으로 더 높여줄 수 있는 충분한 개선이 일어나거나 일어날 가능성이 있느냐는 점이다.
(백미러 보고 운전하지 말자.)

내가 모든 투자자들에게 하고 싶은 충고는 나이가 들어 늙게 되면 어떤 식으로든 투자 결정을 하지 말라는 것이다.
(워렌 버핏 예외)

그런데 번역서에 상당한 불만이 많다. 우선 교열을 제대로 안 봐서 그런지 비문이 많이 보인다. 다음으로 가장 큰 불만인데... 아들인 케네스 L. 피셔가 쓴 '나의 아버지 필립 피셔'라는 서문을 본문 가장 마지막으로 옮겨놓은 점이다. 출판사에서 의도적으로 '한국인 정서'에 맞춰 편집 과정에서 서문을 후문으로 이동했다고 밝히는데, 이 책 텍스트를 이해하는 과정에서 엄청나게 중요한 단서를 함부로 훼손한 굿모닝북스 편집자는 정신 많이 차려야겠다. 혹시 번역판을 구입하실 분이라면 이 책 뒷부분에 나온 후문(?)을 반드시 먼저 읽고 본문으로 들어가기 바란다.



EOB

수요일, 6월 11, 2008

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

이번 주에도 어김없이 재미있는 기사로 여러분을 즐겁게 만들어드리기 위해 노력해봤다. 6월 2주 기사는 다음과 같다.





내주에도 재미있는 기사로 여러분을 찾아뵙겠다.



EOB

화요일, 6월 10, 2008

[새소식] 아이폰 3G 드뎌 출시



애플 개발자 회의(WWDC) 기조 연설에서 스티브 잡스가 이번에 새로 들고 나온 물건은 역시 루머를 뒷받침하는 아이폰 3G였다. 애플 사이트에서 전반적인 하드웨어 명세와 기능을 살펴보니 2G에 비해 여러 가지 하드웨어 개선 사항이 엿보였다.




  • 우선 가장 큰 개선 사항은 배터리 수명인 듯이 보인다. 3G로는 5시간, 2G로는 10시간 정도 통화가 가능하다고 하니 배터리 떨어질까봐 노심초사 하면서 통화할 필요는 없겠다. 이제야 좀 전화기 다워진 느낌이다.
  • 다음으로 GPS 내장 기능이 눈에 팍팍 들어왔다. 구글맵과 연계할 경우 언제 어디서나 현재 위치를 파악할 수 있으며, 응용 프로그램과 지도만 심어 놓으면 자동차 네비게이션으로 탈바꿈 가능하다(물론 국내에서 가능할지는 절대 확신할 수 없다. --> 대부분 윈도우 CE 기반이라서 이식 자체가 쉽지 않을테니까...)


아이폰 2.0으로 소프트웨어 버전이 올라가면서 몇 가지 눈에 띄는 소프트웨어 개선 사항도 있다. 다음 목록을 보면 공감하겠지만 완전히 기업용이라는 느낌이 든다.




  • 우선 공식적으로 한국어를 지원한다. 물론 사전이 빠져서 절반의 완성이긴 하지만... 아직 공식적인 발표는 나지 않았지만 (소문에 따르면 KTF를 통해) 조만간 한국에서도 서비스가 이뤄지리라는 생각이다.
  • 다음으로 RIM 블랙베리 견제를 위해 액티브 싱크 기능을 추가해서 마이크로소프트 익스체인지 연동을 강화했으며, 모바일미라는 서비스에 가입하면 편지, 주소록, 일정표, 달력 등을 Mac, PC, 아이폰 사이에서 자유롭게 공유할 수도 있다.
  • 마지막으로 공학용 계산기 기능 추가와 더불어 주소록 관리 + 첨부 파일로 날라온 파워포인트 보기와 같은 전자편지 기능 강화도 눈에 띈다.


그런데, 이 모든 장점을 한번에 무색하게 만드는 최강의 특징이 있는데... 차칸 가격이다. 놀라지 마라시라. (단돈) $199부터 시작이니까. 이제 S나 L사 큰일 났다.



EOB

목요일, 6월 05, 2008

[일상다반사] 종이 내음 나는 오프라인 신문 얼마만에 사보나?

요즘 퇴근 길에 경향 신문 한 부를 가판대에서 사서 석간처럼 읽고 다닌다. 지난 금요일은 하두 시국이 답답해서 한손에는 신문을 한손에는 안주거리랑 술을 사들고 퇴근했다.



좃쭝똥이라는 걸출(?)한 신문을 놓아두고 경향 신문을 사는 이유는 단순하다. 헤드라인부터 다르기 때문에!



하지만 거의 다윗과 골리앗 싸움이라서 경향 신문도 무척 힘든 모양이다. 미디어 오늘에도 기사화 되었지만, 경향 신문에 난 기사는 나를 슬프게 만든다.



"청와대가 국민의 혈세로 정부 광고를 집행하면서 경향신문 등 일부 신문에 대해 '덤핑 광고단가'를 제시, 사실상 정부 광고 게재를 수용하기 힘들게 하는 방식으로 '입맛에 따른 정부광고 주기'를 노골화하고 있다"


참으로 교모한 언론 탄압이 아닐 수 없다. 청와대 쪽에서는 '열독률'이라는 말도 안되는 잣대를 동원해서 많이 팔리고 많이 읽히는 신문에 당연히 광고비를 더줘야 하는 거 아닌지 변명아닌 변명을 했다고 하던데, 갱제를 살리자는 2MB를 위해 일하는 담당자니 초록이 동색이라는 생각이다.



그래서 결심했다. 앞으로 커피 한 잔 덜 마시고 남긴 600원을 퇴근 길에 매일 매일 투입해서 저녁 무렵 가판대에 안 팔린 경향 신문 한 부씩 가져가서 가판대 주인이랑 광고주가 수요와 공급이 지배하는 시장 원리와 경제 원칙에 따라 움직이도록 만들어주리라... 실제로 경향 신문이 거의 눈에 띄지 않다가 요즘에는 제법 많은 부수를 가져다 놓는 현상을 목격했기에 어느 정도 가능성은 있다고 본다. 음... 나도 이제 모 비서관이 '사탄'이라 칭했던 일부 언론을 밀어주는 배후(?) 세력으로 자리잡는가? 낄낄...



EOB

수요일, 6월 04, 2008

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

거의 장마가 되버린 6월 1주, 컴퓨터 앞에서 읽을만한 기사를 어김없이 정리해보았다.





6월 2주에는 그래디 부치 큰 형님이 쓰신 글을 비롯하여 좀더 재미있는 기사로 여러분을 찾아뵙겠다.



EOB

화요일, 6월 03, 2008

[일상다반사] IT Project Management Day

한국 썬 지식서비스 본부 주관으로 열리는 IT Project Management Day에서 "The Art of Project Management: 마음을 움직이는 프로젝트 관리" 책 소개를 오늘 3시부터 약 40분 정도에 걸쳐 생방송(?)으로 진행할 예정이다. 관심있는 분들께서는 참석해보시길... ;)



EOB

일요일, 6월 01, 2008

[독서광] 딜레마 해부하기



두번 생각할 필요없이 우리 삶자체가 딜레마의 연속이므로, 어떤 식으로 딜레마에서 효과적으로 빠져나올지 늘 고민하는게 지극히 당연하다. 이렇게 하려면 우선 딜레마 유형을 알아야 하고 각 유형별로 효과적인 대응 방안을 쥐고 있어야 한다. 그런데 이 책을 읽으면서도 확실히 느꼈지만 딜레마 해법은 그 때 그 때 다르다. 즉 일반화된 해결 방안은 꿈도 꾸지 않은 편이 좋을 듯이 보인다.



유감스럽게도, 이 책 표지에 나온 내용은 완전히 우리를 낚기 위해 환장을 한 듯이 보인다. 한번 읽어볼까?



비즈니스와 정치, 사랑과 전쟁에 이르기까지 내 삶을 흔드는 37가지 일상의 딜레마, 그리고 그 해결책


볼드체는 내가 한게 아니라 출판사에서 한거다. 그나저나 우왕... 책 내용대로라면 이 책만 읽고 나면 딜레마 유형과 해결책을 모두 쥐게 되니 어떻게 구입하지 않고 배기겠는가? 하지만 요란한 잔치 먹을 게 없다는 말이 있듯이 번역은 형편없고 해결책도 일반적인 이야기에 그치니 이 얼마나 황당한가? 물론 이런 큰 기대를 하지 않고서 번역만 좀 참고 읽으면 중간중간에 재미있는 내용이 조금씩 나오니 그나마 본전치기는 했다는 생각이다.



결론적으로 정리하자면 심각한 딜레마에 빠지면 빠져나올 방법은 없고 그냥 주사위를 던지는 편이 좋을지도 모르겠다. '월스트리트의 포커페이스'에 나오듯이 전혀 예기치 못한 블러핑은 상대편에게 엄청난 압박을 주기에...



EOB