보안 어떻게 할 것인가?

기업마다 자사의 기술 및 기밀을 유출시키지 않기 위해서 보안관련 규정을 엄격하게 재정비하고 있으며, X-ray 투시장비를 설치하거나 PC에서의 데이터 유출을 막기위한 시스템을 도입하는등 막대한 자원을 투입하고 있다. 그럼에도 불구하고 기업의 기술 유출 사고가 매년 보고되고 있으며, 그 피해 규모도 늘어나는 추세이다. 이에 따라 각 기업에서는 보안을 더욱 강화하는 악순환이 매년 되풀이 되는 듯 하다.
하지만 아무리 보안 규정이나 검열이 강화되어도 회사의 직원이 마음만 먹는다면 기밀이나 기술을 빼돌리는 것은 그리 어렵지 않다. 보안 규정 및 검열은 단지 선량하게 열심히 일하는 다수의 직원을 번거롭게 하고 업무 효율을 극도로 떨어뜨리는 "낭비"의 범주를 벗어나지 못하는 것이다.
그럼 어떻게 하면 업무 효율에 영향을 미치지 아니하고 보안을 강화할 수 있을까? 정답은 직원들의 회사에 대한 충성도를 높이는 것이다. 직원 개개인이 회사에 대해서 자부심으로 충만하고, 이런 직원을 상대로 보안 교육이 적절히 병행된다면, 더 이상의 보안 강화책은 필요하지 않을 것이다. 직원에 대한 복지를 높이고, 업무 외에 부당한 요구를 하지 않으며, 기업 및 기업주가 사회에 떳떳할 때, 이런 기업 아래에서 일하는 직원은 회사에 대한 자부심으로 회사에 충성하며, 열심히 일할 것임은 너무나 쉬운 이차라 모두가 잊은것 아닌지 모르겠다.

개발에 도움을 주는 사람 방해를 하는 사람

개발을 진행하다 보면 기술적인 측면 그 이상으로 인간 관계가 해당 프로젝트의 성패에 더 큰 영향을 미치곤 한다. 십인 십색 백인 백색... 사람은 사람마다 천차 만별이라 만나는 이마다 한명도 똑 같은 사람은 없고 이들사이에 형성되는 네트워크만큼 복잡한 시스템도 없을 것이다. 이ㅈ



모사꾼.


관리에 소질 없는 관리자.
여론을 만드는 사람.

엔지니어에게 직장 선택의 자유를...

법으로 보장된 직업선택의 자유가 유독 엔지니어에게만 제약사항이 많은 것 처럼 느껴지는 것은 내가 엔지니어이기 때문일까? 일반적으로 전자 업계에 근무중인 엔지니어가 다른 회사로 이직을 할 경우 "동종 업계" 이직이라 하여 2년간 이직을 제한 받을 수 있다. 하지만 오히려 엔지니어가 동종 업계로 이직하는 것은 당연한 것이다. 대학시절부터 줄곧 배운게 이 분야인데 당연히 "동종 업계"로 이직을 해야지 "이종 업계"로 이직하란 말인가? 공대를 졸업하고 엔지니어로 취직하고 일하다가 이직하려면 엔지니어 때려치고 보험회사 영업하란 말인가?
쉬운 예를 들어보자 만약 당신이 어떤 큰 중국집에서 주방장 보조로 10년간 내공을 길렀고 이제 다른 중국집에 주방장으로 스카웃 되어 이직을 하려는데 만일 "동종 업계" 이직 금지 조항이 있어 이직을 못한다면 어떻겠는가? 배운것이 중국요리인데 한식집이나 일식집으로 갈 수도 없고... 또한 한식이나 일식도 음식점이니 어떻게 보면 동종 업계인데.. 2년간 요식업계를 떠나라는 소리인지도 헷갈린다.
회사의 기밀 보호도 좋지만 영업사원의 영업 노하우를 회사 기밀이라고 해서 이직을 제한하지 않듯이 엔지니어의 머리속에 기억된 기술도 회사의 기밀이 될 수 없다. 만일 엔지니어의 기술이 회사의 기밀에 속하는 내용이 있을 경우, 해당 기술을 특허 신청하여 보호하여야지 엔지니어의 직장 선택의 자유를 박탈해서는 안될 것이다.
공학기술에 무지한 법학자들이 대기업들의 로비에 휘둘려 자신들도 모르는(? 의심스럽지만) 사이에 침해한 엔지니어의 권리를 돌려받아야 한다.

공감이 가는 글이 있어서 링크를 겁니다.
http://www.zdnet.co.kr/itbiz/column/anchor/hjkim/0,39030302,10062738,00.htm

리눅스 문제 분석과 해결, Mark Wilding/Dan Behman, 에이콘, ****

간만에 읽을 만한 책이라 판단되어 허겁지겁 읽어내려 갔지만, 결코 만만히 읽어치울 수 없어 마음을 고쳐잡고 찬찬히 읽고 있는 책. 어떤책인지 판단할 만큼 충분히 읽지는 못했지만 남은 부분이 무척이나 기대되는 책이다. 전반적으로 John Robbins가 쓴 Microsoft의 Debugging Applications 이란 책의 리눅스 버젼이라고 생각하면 크게 틀리지 않을 것 같다. 두 책 모두 stack이나 calling convenstion, Assembly level의 디버깅등 고급 디버깅 기법을 설명하고 있다. 단지 서로의 OS환경에 좀 더 의존하고 있기는 하지만, 이런 기술은 결국 하나로 통하기 마련아닌가? 여기서 어떤 책이 더 좋은지를 논할 필요는 없을 것 같다. 두 책 모두 훌륭해 보이며 둘 중 하나를 읽었다 하더라도 여전히 남은 하나를 읽을 가치가 있어 보인다.

여러개의 프로젝트에 참여하기

개발을 하다 보면 종종 여러개의 프로젝트에 동시에 참여하게 되는 경우가 있다. 프로젝트의 진행에는 강약이 있기 마련이지만 여러 프로젝트의 중요 일정이 겹치게되면 감당할 수 없을만큼 많은 일들이 동시에 주어지기도 한다. 서로 다른 프로젝트의 리더가 중요하고 급한 일이라고 각기 다른 일을 던져주고 빠른 피드백을 원한다면 일의 우선 순위를 어떻게 잡아야 할까?

한국적인 정서에서 두 프로젝트 리더를 모아놓고 "두분이서 협의해서 우선순위를 정해주세요" 라고 요청하는 것은 거의 자살행위에 가까워 보인다. 경우에 따라 조금 가혹한 평가일 수도 있지만 적당히 일의 우선 순위를 정해서 상사가 기분나쁘지 않게 적당히 완급을 조절하며 업무를 처리하는 것도 개인의 능력이라고 할 수 밖에 없을 것 같다. 일단 현재 내가 바쁘다는 사실을 인지시킬 수 있다면 어떻게든 상사의 기분을 상하지 않게 주어진 일의 기한을 연장하거나 다른 사람에게 양보? 할 수 있을 것이다.

자신에게 마이너스인지 알면서도 일이 바뻐 눈코뜰 새 없을 때 새로 업무를 던져주는 상사를 보며 인상을 찌푸리는 것은 내가 어쩔 수 없는 까칠한 인간이기 때문일까? 싸가지가 없어서 일까?

하여간 이런 방법으로 상사에게 눈치를 주어 일을 조금 덜 배정 받는 것은 정말 세련되지 못한 방법이다.. 그러지 말자..ㅠㅠ

프로젝트 일정을 제대로 계획하였다면...

프로젝트 일정을 제대로 계획하였다면 일정상의 공휴일 및 개인 휴가와 여유 기간, 통합 기간 그리고 디버깅 기간을 합친 시간이 실제 순수히 설계 및 코딩에 들어가는 시간보다 많아야 한단다.. 이것이 황금률은 아니더라도 수긍이 가는 이야기 임에는 틀림 없는 것 같다. 이세상의 모든 프로젝트 관리자에게 소리친다. "프로젝트가 일정을 준수하고 싶은가? 그렇다면 일정을 제대로 짜자..."

임베디드 개발자를 위한 리눅스 커널 심층 분석, Robert Love, 에이콘 ****

http://www.acornpub.co.kr/book/linux-kernel

리눅스커널을 설명한 책들이 많이 나와 있지만 대부분의 책들이 소스코드를 설명하려 하다가 방대한 커널 소스 코드의 일부만을 다루고 흐지부지 끝을 맺는 경우가 대부분 이었다. 소스 코드 때문에 책의 두께는 두껍지만 별로 읽을 만한 내용도 없고 그렇다고 소스 코드에 대한 설명이 자세한 것도 아니다. 하지만 이 책에는 소스코드가 거의 없이 커널의 구현이 깔끔 단백하게 설명되어 있다. 다행이 좋은 내용의 책이 믿을 만한 출판사에서 번역되어 한글 번역도 훌륭하다. 시중에 나와 있는 리눅스 커널 설명서 중에서는 단연 추천하고 픈 책이다. 책 제목에 "임베디드 개발자를 위한" 이란 말이 들어 있는데 이것은 원저에는 없는 사족이며 출판사에서 임의로 붙인듯 하다. 사실 이 책은 임베디드 개발과 큰 관련은 없으며 실제로 같은 출판사에서 번역된 이 책의 개정판에는 "임베디드 개발자를 위한"이란 표현이 없는 것으로 알고 있다. OS 커널을 공부하거나 리눅스 커널에 관심있는 사람이라면 필독, 강추. (이 책 구매 후 개정판이 원서로 출간되었길래 개정판을 원서로 구매하였는데 얼마되지 않아서 개정판에 대한 번역서가 또 출판되었다. 아직 개정판 원서는 모두 읽지 못하였는데... 읽을때 마다 가슴이 쓰리다.)

Programming Applications for Microsoft Windows 4th ed., Jeffrey Richer, Microsoft *****

기술서적을 읽으면서 눈물을 흘려본적이 있는가? 기술서적이 재미있어 다음장에 나올 내용이 궁금해 본 적이 있는가? 이 책은 꽤 두꺼운 책이지만 책 두께가 더 두꺼웠으면 좋을 정도로 중요하고 흥미로운 내용으로 꽉 차있다. 개인적으로 이 책을 읽어보지 않은 사람들은 상용 윈도우즈 프로그램을 만들지 않았으면 하는 생각이 들 정도로 윈도우즈 개발자들이 꼭 알아야 하는 내용으로 가득 차 있다. 전산 전공이 아니라 개인적인 흥미로 프로그래밍을 시작한 나에게는 이 책을 통해서 단지 윈도우즈 환경에서의 프로그래밍 뿐만 아니라 부족했던 전산관련 지식을 업그레이드 할 수 있었고, 이 책에서 배운 내용들은 더이상 윈도우즈용 풀그림이 아닌 임베디드 환경에서의 풀그림을 작성하는데도 많은 도움이 되고 있다. 아직 이 책을 읽지 않은 개발자라면 무조건 강추. (내공이 한갑자 이상이라면 pass)

"... 그럼에도 불구하고, 사람들은 직무 재조정을 전혀 거치지 않은 상태에서 상급 코딩 기술자를 관리자로 밀어붙이는 작업이 가능하다고 받아들입니다."-조엘 온 소프트웨어

현재 근무하는 회사에서 이러한 현실을 바꿀 수 없는 경우, 관리자로 밀어붙여진 개발자가 선택할 수 있는 길은 무엇일까?

임베디드 시스템 펌웨어 분석, Ed Sutter, 에이콘 ***

http://www.acornpub.co.kr/book/firmware

임베디드 시스템의 펌웨어 개발자가 알아야 하는 내용을 깔끔하게 설명한 책. (너무 깔끔해서 가끔은 좀 불친절해 보임) 이책은 간단한 기능의 디버그 모니터의 소스 코드 전부를 CD로 제공하고 이 디버그 모니터의 구현을 설명하였다.

최초에 H/W팀으로 부터 받은 H/W를 어떻게 동작시키는지부터 시작하여 target보드에 기본적인 개발 환경을 어떻게 만드는지를 설명한다.

디버그 모니터 소스 코드를 통째로 지원하므로 자신의 h/w에 책에서 제공하는 디버그 모니터를 올려서 테스트 해 볼 수 도 있다. (단 당신의 target board가 책에서 지원하지 않는 CPU를 사용하여 구성되었다면 해당 CPU의 assembler를 사용하여 초기화 루틴을 직접 작성해야 한다.)

앞서 잠깐 언급했지만 이 책을 읽다보면 종종 내용이 너무 깔끔해 설명이 충분치 못하다고 느껴지는 부분이 많다. 사실 이런 부분을 모두 제대로 설명하려면 책 분량이 엄청나게 커질 것이기 때문에 저자를 비난하기는 힘들것 같다. 하지만 CD에 첨부된 PDF 문서들을 열심히 읽으면 대부분의 궁금증을 해결할 수 있을 것이다. 물론 이해하려면 약간의 내공이 필요한 문서들이지만 모두 읽고나면 뿌듯히 충만한 공력이 단전에서 느껴질 것이다.

게임 개발자를 위한 C++, 서진택, 민커뮤니케이션 ***

도대체 왜 이 책의 제목에 굳이 "게임 개발자를 위한" 이라는 말이 들어갔는지 이해하기 힘들다. 차라리 이 책은 C++에 처음 입문하여 아직 C++에 완전히 적응하지 못한 개발자들에게 저자가 자신이 맨땅에 헤딩하며 얻은 C++관련 지식을 친절하게 알려주는 그런 책이다.

이 책의 저자는 자신이 C++에 대해서 모든 것을 아는것처럼 이 책을 기술하지 않았다. 오히려 저자는 자신도 모르고 있던 C++의 기능/정의 등이 왜? 그렇게 되었는지 끊임없이 탐구하면서 자신이 찾아낸 결과를 독자들에게 전달하여 주고 있다.

만일 C++ 문법책 한두권을 읽고 C++ 문법을 안다고 생각하는 C++ 초보 프로그래머라면 (설령 C언어의 고수라고 할지라도...) 일반적인 C++ 설명서가 놓친 부분들을 이 책의 저자와 함께 고민해보기를 권하고 싶다.

아직도 나는 헷갈리는 C++문법이 나오면(계속 C만 사용하다 보니, 때론 C++ 문법이 가물가물해진다.) 베게같은 C++ 문법책 대신에 이 책을 먼저 찾는다. 나보다 먼저 고민하고 나름대로의 모범답안을 적어놓은 선배의 족보같은 느낌... (마치 족보처럼 편집이나 구성은 별로 뛰어나지 않다. 하지만 내용은 쪽집게라는거~~ )

C만 사용하다 갑자기 10년전 대학시절에 배우고 쓰지않던 C++로 프로젝트를 수행해야 한다면 강추. 자신이 C++ 고수라고 생각한다면 통과.

P.S. 사실 C++ 문법은 평균적인 IQ의 인간이 익히기에는 너무 복잡하다. 자신이 C++의 고수라고 생각한다면 Effective C++ 과 More Effective C++을 읽어보기 바란다. 내용이 이해가 잘되신다면 당신을 고수로 인정합니다. 나는 아직도 이 두 책의 많은 부분이 이해되질 않는다. ㅠㅠ

Inside Windows 2000, Solomon/Russinovich, Microsoft ****

수 많은 리눅스 커널 분석 책들이 있지만 의외로 Windows의 커널 동작에 대해서 설명한 서적은 찾기 힘들다. Windows가 소스 코드가 공개되지 않은 OS라는 점을 생각하면 별로 의외도 아니지만...

Windows 환경에서의 개발자 뿐만 아니라 다른 환경에서 개발을 해야 하는 개발자이더라도 OS의 동작 원리를 아는 것은 일반적으로 개발자의 내공을 높이는데 결정적인 계기를 만들어 준다. OS 마다 최종적으로 제공하는 기능은 비슷 비슷 하지만 이를 구현하기 위한 디자인은 서로 조금씩 다르기 마련이며, 이러한 디자인의 차이점을 공부하는 것은 그야말로 엄청난 내공을 쑥쑥 키우는 영양제가 될 듯하다.

기존에 OS나 전신이론에 대한 기초 지식이 없이 바로 읽기에는 약간 부담되는 내용이므로 내용이 절반 이상 이해되지 않는다면 다른 공부를 좀 더 하고 다시 도전하기 바란다.

내가 읽을 것은 Windows2000용이었으나 Windows XP나 Vista용이 나왔을지도 모르겠다. 하지만 기본 내용이 많이 바뀌었을 것 같지는 않다.

번역서도 있으나, 절.대. 추천하지 않는다. (최소한 내가 본 초판 번역서는 정말 엉망이었다.) 중급이상 개발자라고 생각한다면 강추.

What not to do list as a manager

항상 객관적으로 자기 자신을 평가하기는 어려운 일이다. 지금 개발자로써 내가 관리자에게 느끼는 점을 모아 적어 놓는다면, 나중에 반면교사의 교재로 사용할 수 있을 것이다.
이 게시물은 생각이 날때마다 update할 계획이며, 혹시 누군가 댓글에 좋은 내용을 추가하여 준다면 이 또한 게시자의 id와 함께 추가하도록 하겠다.

1. 책임을 개발자에게 떠넘기기
한두가지 문제에 대한 책임을 개발자에게 떠넘긴다고 프로젝트 실패의 책임이 개발자에게 넘어가는 것은 아니다. 이런 행동은 최악의 경우 개발자의 사보타지를 부추길지도 모른다. 당신의 프로젝트는 실패하고 당신은 신망을 잃고 앞으로 누구도 당신 밑에서 일하려 하지 않을 것이다.

2. 개발자에게 자신의 방법을 강요하기
개발자가 어려운 디버깅 문제에 봉착하였을 때 이에 대해 적절한 코멘트를 통하여 디버깅을 도와줄 수 있다면 정말 훌륭한 관리자가 아닐 수 없다.(물론 이것은 개발에 대한 경험이 있는 관리자의 경우에만 해당된다) 하지만 개발자가 아주 초짜라 별도의 코칭이 필요한 경우가 아니라면 디버깅을 위한 의견 제시나 방향만 제시하여 주는 것이 좋다. 사사건건 간섭하여 이거 해 봐라 저거 해 봐라 하는것은 별로 좋은 방법이 아닌것 같다. 당신은 (한국사람이라면 특히나 더 ) 개발자로써 화려하게 성공하여 관리자로 진급하였는지도 모른다. 이 경우 당신은 자신만의 화려한 개발 실력을 무기로 삼아 문제를 빨리 해결할 수 있는 수만가지 방법을 알고 있겠지만, 문제 해결을 위하여 이러한 무기를 사용하고자 한다면 자신의 손으로 직접 행하기 바란다. 이것은 당신의 손에서 사용된다면 문제 해결을 위한 훌륭한 무기이지만, 당신의 입에서 사용된다면 개발자의 마음을 찟는 무기로 돌변 할 것이다. 괜시리 개발자의 마음들 다치게 하여서는 문제 해결에 도움이 되지 못한다. 사람에게는 자신만의 무기가 있는 법이다. 다른 사람에게 자신의 무기를 강요할 필요는 없다. 특히나 이것 저것 시켜보고 안되면 은근슬쩍 발을 빼려 한다면 당신은 좋은 매니져가 아니다. 해당 문제를 자신의 책임하에 끝까지 해결할 마음의 자세가 되지 않았다면 개발자에게 자신의 방법을 강요하지 않는 것이 좋다.

악몽의 순간에 발생하는 일들

프로젝트가 막바지에 이르면 개발자와 관리자 모두 패닉상태가 되기 쉽다. 이미 code freeze일정이 지나 validation team에게 이미지가 전달되었지만, 잇달아 발생하는 개발자의 sanity test failure report는 별다른 위기조차 되지 않는다. 왜냐면 곧이어 validation team에서 "진짜" 문제들을 쏟아낼 것이기 때문이다. 이쯤되면 이미 validation team으로 부터 몇번의 양해를 구해서 이미지를 다시 build하였기 쉽상이지만 아직 절망에 이를 단계는 아니다.

- (사실 validation team이 그나마 "진짜"문제를 쏟아내주면 그것만으로도 고마운 일이다. 최근에 투입된 "초짜" tester가 등록하는 수많은 "가짜"문제들의 홍수에 질식해 본 적이 있다면 "진짜"문제들은 차라리 고맙기까지 하다)

만일 최종 이미지가 빌드 후 제품 양산을 위해서 공장에서 라인이 기다리고 있는 상황이면 관리자들은 똥 마려운 강아지처럼 안절 부절 하면서 눈을 희번득거린다. 이들은 곧잘 개발자들의 경제 관념을 운운 하며 새로운 이미지를 제때에 만들지 못할 경우 생산 라인당 몇명의 작업자가 몇시간 동안 작업한 것이 날아가며, 이때 발생하는 손실 및 고객신뢰 실추등을 읊어대기 시작할 것이다. (이 단계에 이르면 관리자는 이미 패닉 상태에 있다고 보면 정확하다.)

이쯤 되면 개발 경력이 짧거나 소심한 개발자들은 서서히 관리자들과 함께 미쳐가기 시작하며 이때 누군가 중심을 잡아주지 않을 경우 개발팀 전체의 패닉으로 프로젝트가 산으로 가기 시작한다. ( 정말 최악의 시나리오군..)

어느정도 경력이 있는 개발자들은 이럴 때 빛을 발한다. 그들은 평정심을 유지하며 설령 마지막 순간에 발생한 문제의 모든 증상이 자신을 지목한다고 하더라도 최대한 객관적으로 문제를 살펴 정확한 원인을 찾아낸다. 일단 문제의 원인이 밝혀지면 (설명 문제의 원인이 자신이 짠 코드라고 하더라도) 현 상황에서 최대한 빨리 문제를 수습 가능한 대안을 찾고 제시한다. (나는 이런걸 알고 있으면서 왜 이렇게 못할까? 왜 나는 늘 전전긍긍하며 내 문제가 아니기만을 기도할까? 신앙심도 전혀 없으면서... ㅋ)

사실 이시점에서 개발자들이 할 수 있는 일은 별로 많지 않다. 다만 문제가 자신의 문제가 아니라 밝혀졌을 때 가슴을 쓸어내리며 문제를 만든 다른 개발자를 욕하는 대신에(이건 정말 최악이다 이런 개발자라면 짐싸라), 함께 다른 대안을 찾을 수 있도록 도와줄수 있을 따름이다.

그럼 이 시점에서 관리자는? 관리자는 이미 이 시점에서 문제를 만든 개발자보다 더 큰 원죄를 가지고 있다. 이를 인식하고 반성한다면 앞으로 훌륭한 관리자가 될 자질이 있는 사람이라고 생각한다. 만일 당신이 관리자인데, 문제 발생의 이유를 개발자에게서 찾고 있는 당신을 발견한다면 제발 프로젝트를 위해서 관리자 자리를 포기하여 주기 바란다. 어짜피 최종 프로젝트가 성공하고 못하고에 대한 평가는 팀원 모두가 나누어서 짊어지게 된다. 당신 혼자 욕 먹지도 당신 혼자 칭찬 받을 수도 없다는걸 항상 기억하라.

또한 만일 당신이 누구 한명에게 죄를 뒤집어씌워 당장의 비난을 피한다면 다음에 누가 당신이 돌격 앞으로를 외칠때 앞서서 뛰쳐나가려 할지 생각해 보기 바란다. 어짜피 당신의 관리자로서의 생명은 절단났다고 봐도 될 것 이다.

구글? 그게 뭔데?

세계 소프트웨어 시장의 패권을 차지한 마이크로소프트사가 가장 두려워하는 회사는 구글이 아닐까? 이미 구글은 마이크로소프트로부터 자유를 획득하였는지도 모른다. 이들은 자신뿐만이 아니라 일반 대중까지 마이크로소프트로부터 독립시키기 위한 매우 치밀하고 주도면밀한 쿠테타를 준비하는것럼 보여진다.

사실 구글이 아직 알려지기 이전에는 리눅스 정도가 마이크로소프트가 두려워하는 대상이었을지도 모른다. 비록 리눅스가 시장에서 자신만의 장점으로 깊은 뿌리를 내리는데 성공하였다고 말할 수 있겠지만, 윈도우를 이겼다고 말할 수는 없다. (꼭 윈도우를 이기는 것 자체가 가치있는 일이라고 말하고자 하는 것은 아니다. 여기서 말하고 싶은 것은 대중을 독점의 피해로부터 구해냈는가 그렇지 못했는가이다.)

많은 사람들이 지적하였듯이, 대부분의 사람들은 업무상 사용하는 주요 s/w(개발자라면 편집기나 개발툴등)이외의 어플리케이션이 제공하 대부분의 기능을 사용하지 아니한다. 이러한 사람들이 불필요하게 비용을 지불하며 값비싼 어플리케이션을 구매하는 이유는 다른 사람들과 함께 일할때 발생하는 데이터 호환성 문제를 피하고 싶기 때문일 것이다.

이러한 데이터 호환성 문제는 마이크로소프트의 독점으로 인하여 발생하였고 마이크로소프트는 이를 지능적으로 이용하여 지난 20여년이 넘는 기간동안 엄청난 이익을 거두었다. 구글은 이러한 호환성 문제를 극복한 웹 어플리케이션을 사용하여 대중을 열광케 만들 준비를 진행하고 있는 듯 하다. (유료화 안하면 좋을 텐데...)


웹 어플리케이션이 일반 어플리케이션보다 뛰어난 기능을 제공하지는 못하지만 설치가 필요없고 데이터의 이동의 측면에서 더 유리하기 때문에 (USB 메모리를 가지고 다닐 필요도 없다!) 데이터 호환 문제만 해결된다면 일반 사용자를 흡수하는데 아무런 문제가 없다. 구글 이전에 오픈 오피스등이 완벽한? 데이터 호환성을 주장하며 기존 사용자 층을 흡수하려 하였지만, 오픈 오피스는 아무리 뛰어나도 마이크로소프트 오피스를 뛰어넘을 수 없는 흉내작일 수 밖에 없었다. 하지만 구글이 제공하는 서비스는 태생부터 이런 문제를 극복할 수 있는 핏줄을 타고 난것이라 생각한다.

넷스케이프가 인터넷 익스플로어에 패배당한 후 몇년간 마이크로소프트는 인터넷 익스플로어를 거의 개선시키지 않았다. 그러다 최근 FireFox가 인기를 얻자 부랴부랴 인터넷 익스플로어 7을 발표하였는데 이것은 경쟁이 있어야 발전이 가능하다는 진리를 일깨워 준다.

구글이 마이크로소프트를 긴장시킬수록 우리는 즐거워 질 것이다. 마이크로소프트도 필사적으로 뭔가를 준비할테니까...

(마이크로소프트는 OS쪽에서 늘 OS X를 모방해 왔다. OS X가 마이크로소프트를 긴장시키지는 못했지만, 윈도우가 늘 OS X의 따라장이 였다는것을 부인할수는 없을 것 이다. 하지만 제발.. 기능뿐아니라 디자인도 좀 따라하길 바란다. 최근에 나온 Vista의 디자인은 정말 최악이다.)

문을 열며

최근에 읽은 "조엘 온 소프트웨어"는 바쁘다는 핑계로 자기개발에 게을리 했던 나에게 큰 자극이 되었다. 나는 한순간 닫혀있었던 눈으로 밝은 빛이 새어 들어옴을 느낄 수 있었고, 나의 주변에서 열심히 살아가는 사람들로부터도 기존에 느끼지 못했던 배울점을 찾을 수 있게 되었다.

하지만 또다른 문제는 한순간 아주 짧게 떠올랐던 배움의 쪼가리들이 멋들어지게 다듬어져 체계적으로 정리되지 못하고 공중으로 흩어져 간다는 것이다.

나는 아직도 이렇게 불현듯이 떠올라다가 부질없이 사라져가는 생각들을 멋들어지게 정리 할 수 있는 방법을 찾지 못했다. 최근에 선물받은 값비싼 플랭크린 다이어리를 업무 용도에 한정해서 비교적 잘 활용하고 있지만, 왠지 이곳에 업무상의 사실관계 이외의 배움의 생각을 적지 못하고 있다. (그래도 플랭클린 플래너가 비싼 값 이상을 해내고 있음은 분명하다. 태생부터 컴퓨터와 친숙한 N세대는 아니지만, 아직 PDA나 노트북을 통한 업무 관리보다는 구식의 아날로그 방식이 좀 더 사용하기 쉽다고 느끼는 이유는 아직 이들이 쓸만한 h/w, s/w환경을 제공하지 못하기 때문이라고 생각한다.)

아직 아무것도 결정된 것도 확실한 것도 없지만, 나는 이 블로그를 통하여 나의 생각들의 쪼가리를 모으고, 언젠가 이것들을 짜깁기하여 멋들어진 나만의 세계를 가지고 싶다.