내가 윈도우를 그만 사용한 이유

Posted by 大山 Mon, 09 Apr 2007 23:48:00 GMT

나의 첫번째 컴퓨터는 애플 II였지만, 당시의 운영체제는 맥 OS가 아니라 애플 DOS였다. 1990년부터는 XT 컴퓨터에서 MS-DOS를 사용했고, 미국으로 유학을 떠났던 1994년부터는 윈도우 3.1을 사용했다.

윈도우 95가 발표되었을때 열광을 했고, 마이크로소프트에서 발표하는 소프트웨어는 어디에 쓰일지 모를 라이브러리까지 안설치해본게 없었던 것 같다. Lotus 1-2-3, Word Perfect에서 MS Excel과 MS Word로 바꿔타기도 했고, 괜시리 MS Access 책을 사서 공부하기도 했으며, Visual C++ 4.0의 등장에 Borland의 몰락을 예감하기도 했다.

거의 한 10여년 동안은 MS 기술에만 파묻혔서 보낸 것 같다. 근데 한 2000년을 전후해서 스스로 컴퓨터 geek으로서 정체되어 있다는 느낌을 강하게 받았다. MS가 서서히 몰락할 것이라는 직감도 있었고. 한동안 방황했고 오픈소스와 유닉스 그리고 인터넷 문화에서 새로운 성장 곡선을 발견했던 것 같다.

이후 BeOS, 리눅스, Solaris 등을 거쳐 지난 5년여간은 맥 OS X에 정착해 있다. 맥 OS X은 일상적인 데스크탑 OS로 편리하게 사용할 수 있고, 유닉스를 내 페이스로 익힐 수 있어서 좋았던 것 같다.

Posted in  | Tags , , ,  | 8 comments | no trackbacks

인사이드 머신

Posted by 大山 Fri, 06 Apr 2007 16:57:00 GMT

내가 무척 좋아하는 웹 사이트 중에 ArsTechnica란 곳이 있다. 기술 관련 리뷰와 평론 그리고 뉴스 등을 접할 수 있는 이곳의 글은 하드코어하면서도 흥미진진하고 동시에 섬세하다는 특징을 가졌다.

ArsTechnica의 필자 중에서도 존 스토크스는 가장 하드코어한 영역인 CPU 구조와 설계에 관한 글을 주로 써왔다. 프로그래머가 왜 CPU 구조에 관심을 가지냐구? 내 관심사가 잡다한 이유가 가장 크겠지만, 사실 CPU 관련 지식은 웹 개발에 있어서도 유용한 경우가 많다.

컴퓨터 분야에서는 유사한 개념이 여러 추상 계층에서 반복적으로 나타나는 경향이 있다. 예를 들면, 멀티 코어 CPU의 병렬 처리 및 캐시 동기화 이슈가 서버 클러스터 설계에서 다시 반복되는 식이다. 또한 멀티 코어/프로세서 기반의 고성능 서버를 사용할지 클러스터를 도입할지는 Shared Tier Architecture를 사용할지 Shared Nothing Architecture를 사용할지와 밀접하게 관련되어 있는 문제이다.

존 스토크스는 CPU 구조와 같이 난해한 내용을 쉽고 명쾌하게 설명하는 흔치않은 재능을 가진 사람이다. 그런 존 스토크스가 집필한 인사이드 머신을 이번에 에이콘 출판사에서 번역하여 출간했다는 소식이다. 프로그래밍을 공부하면서 CPU 구조 및 어셈블리어 과정을 건너 뛴 개발자나 CPU 기술의 미래를 내다보고 싶은 개발자라면 꼭 읽어볼 것을 적극 추천한다.

Posted in  | Tags , ,  | 4 comments | no trackbacks

기능보다는 관례가 더 중요하다

Posted by 大山 Mon, 26 Mar 2007 12:18:00 GMT

지난번 글은 쓰다보니 주제가 조금 다른 방향으로 샜는데, 원래 쓰려던 이야기는 이거였다.

기능으로 모든 문제를 해결하려는 접근 방법은 바람직하지 않다. 기능은 최소화하고, 사용자들이 그 위에서 적절한 관례를 정착시켜 문제를 해결하게 내버려두어야 한다.

새로운 기능은 의도한 방향으로만 작용하지 않고 예상치 못한 부작용을 동반하기 때문이다. 게다가 기능의 추가는 언제나 시스템을 조금 더 복잡하게 만든다.

예를 들어가며 설명을 해볼까도 했지만, 다른 분들의 생각도 들어보고 싶어 그냥 이쯤에서 글을 마쳐본다.

PS: 물론 "기능보다는 관례가 더 중요하다"는 말은 레일스의 개발 철학 중 하나인 "설정보다는 관례가 더 편리하다"는 원칙을 패러디(?)한 것이다.

Posted in  | Tags ,  | 10 comments | no trackbacks

기능이 중요한 것이 아니다

Posted by 大山 Sat, 24 Mar 2007 17:40:00 GMT

지난 며칠간 미투데이와 플레이톡 이야기로 블로고스피어가 뜨거웠다. 대강 지금까지 일어난 일들을 요약하자면..

  1. 미투데이란 이름의 심플한 미니 블로그 서비스가 비공개 베타서비스를 시작했다.
  2. 미투데이 기획자와 같은 모임에 속해있던 어느 개발자가 미투데이에 대한 사전 정보를 입수한 후, 동일 컨셉의 서비스를 재빨리 개발하여 정식으로 오픈해버렸다.
  3. 미투데이가 블로거들의 주목을 받고 있는 점, 비공개 베타서비스인점 그리고 한정된 초대장을 통해서만 가입이 가능하다는 점을 역이용한 플레이톡에 가입자가 몰렸다.
  4. 미투데이 사용자를 중심으로 플레이톡을 성토하는 목소리가 나오기 시작했다.
  5. 갑자기 비난의 대상이된 플레이톡의 사용자들도 감정적으로 대응하기 시작했다.
  6. 플레이톡은 연이어 미투데이의 기능을 표절하며 논란을 이어가고 있다.

여기까지는 단순한 팩트의 나열이다. 뭐 플레이톡의 도덕성을 비난하는 글을 쓸 수도 있겠지만, 그건 그냥 화면 낭비일 것 같다. 그 문제는 읽는 분들께서 알아서 판단하시도록.

미투데이는 사실 무척 심플한 서비스다. 물론 기획안이 만들어지는 과정에서 치열한 고민과 많은 시행착오가 있었겠지만, 아무튼 기획/디자인 다 끝난 상태에서 개발만 한다고 치면 레일스로 한 일주일이면 만들 수 있겠다는 생각이다. 플레이톡이 카피 서비스면 어떻게 몇 주만에 개발할 수 있었겠냐고 묻는 분들도 있는데, 이게 이유다. 미투데이도 플레이톡도 개발 하나만 놓고 보면 초고속으로 구현할 수 있는 간단한 사이트다.

하지만 작품은 더 추가할 기능이 없을 때 완성된 것이 아니라, 더 뺄 기능이 없을 때 비로소 완성된 것이라는 말도 있지 않는가. 미투데이는 더이상 뺄 기능이 없는 단계에 근접한 서비스다. 미투데이의 기능이 어느 정도로 절제되어 있냐하면, 예를 들어 글을 올리고나면 수정/삭제가 아예 불가능하다. (관리자에게 따로 메일을 보내 사정하면 가끔 예외는 둔다고 한다.)

흥미로운 점은 처음에는 수정/삭제 기능을 요구하던 사용자들 중 상당수는 조금 시간이 지나면, 수정/삭제 기능이 없다는 것에 오히려 열광한다는 것이다. 이는 이러한 기능상의 제약이 사용자들이 미투데이를 사용하는 패턴을 근본적으로 변화시키고 있기 때문이다. 그리고 그러한 변화의 방향은 내가 보기에도 무척 긍정적이다.

하지만 생각해보라. 수정/삭제 기능을 뺀다는 전례가 없는 결정을 내리기 위해 미투데이를 만든 사람들은 얼마나 많은 고민의 시간을 보냈을 지를. 이렇게 구상해낸 기획 요소 하나하나를 누가 하루아침에 가져다 베끼면, 화가 치솟는건 인지상정이지 않을까? 여기에서 플레이톡 사용자분들께 한말씀 드리자면..

플레이톡 사용자 여러분, 미투데이 사용자들이 플레이톡을 비판할때 기분 상하시는건 충분히 공감합니다. 누구라고 자신이 사용하는 사이트 흉보는데 마음이 편하겠습니까.

하지만 그래도 한번 입장을 바꾸어서 생각해 주시기 바랍니다. 미투데이가 세상에 나와 첫 걸음을 내딪을 때부터 지켜보던 사람들의 마음은 어떤 기분일 지를요..

암튼 그건 그렇고, 미투데이나 플레이톡처럼 심플한 서비스의 경우에는 사실 기능이 같다는게 그다지 중요한 포인트는 아니다. 기능이라 부를만한 것이 몇개 없는 것도 사실이고. 기능이 단순할수록 핵심은 서비스 그 자체가 아니라 사용자들이 그 위에서 어떤 문화를 만들어 가느냐에 있다. 그런 면에서 미투데이는 고무적인 성과를 거두고 있다는 생각이다.

가까운 지인을 통해서만 회원가입이 가능하기 때문에 우선 미투데이 사용자들 간에는 강한 유대감이 존재한다. (Open ID란 생소한 서비스를 사용하게 만드는건 사실 웬만큼 가까운 지인이 아니면 어려운 면이 있다.) 게다가 미투데이를 만든 이들 부터가 잘 알려진 블로거인 관계로 미투데이의 베타 사용자 중에는 글재주와 재치가 넘치는 분들이 많다. 이들이 쏟아내는 소소한 이야기와 소통 및 놀이의 방식은 다른 사용자들의 동참을 이끌어내는 중요한 역할을 하고 있다.

미투데이도 이제 곧 정식 서비스를 시작할 예정이니, 내가 더 구구절절이 설명할 필요도 없을 것 같다. 사실 이번 글이 내가 제 삼자 입장에서 미투데이에 관해 쓰는 처음이자 마지막 글이다. 다음주부터는 미투데이 개발팀의 파트타임 팀원으로서 종종 개발과 관련한 비하인드 스토리를 공개하겠으니 기대해 주시길. ;)

PS: 제 블로그의 독자 분들께는 앞으로 미투데이에 많은 관심을 가지고 지켜봐 주실 것을 부탁드립니다!

Posted in  | Tags , , ,  | 11 comments | no trackbacks

미투데이 초청장

Posted by 大山 Tue, 13 Mar 2007 11:40:00 GMT

요즘 장안의 화제가 되고 있는 미투데이 초청장을 3장 나눠드립니다. 모 유사 사이트와는 다르게 루비 온 레일스로 개발되었다고 하지요. :)

댓글로 이름(닉네임), 이메일 주소, 오픈아이디를 적어주시면 선착순으로 드리겠습니다. 열심히 사용하실분만 신청해주세요~

Posted in  | Tags ,  | 16 comments | no trackbacks

맥을 써야하는 또 하나의 이유

Posted by 大山 Tue, 07 Nov 2006 03:48:00 GMT

맥 OS X 최초의 바이러스가 유포되기 시작했다고 한다. 바이러스가 유포되기 시작했는데 왜 맥을 써야 하느냐구? 바이러스는 바이러스인데 지난 일주일간 이 바이러스에 전염된 맥은 채 50대가 안된다는.. 앞으로도 몇대 더 전염시키지 못하고 박멸될 것으로 예상된다고 한다.

그리고 바이러스의 소스코드가 공개되었는데 주석중에는 이 바이러스를 작성하기가 얼마나 어려웠는지를 개발자가 한탄하는 내용이 적여 있었다고 한다. 이 바이러스는 퍼지기만 할뿐 컴퓨터에 어떤 해도 끼치지는 못한다고.

윈도우 바이러스에 상처받은 그대 이제 맥으로 오라. ;)

업데이트(10시간 후): 음, 맥 OS X용 바이러스가 이전에도 있지 않았냐는 이야기가 있는데요..

한때 최초의 맥 OS X용 바이러스로 알려졌던 OSX/Leap-A는 과연 이걸 바이러스라고 부를 수 있느냐의 논란이 많았던 프로그램입니다. 이 프로그램(?)은 해당 파일을 다운로드 받아 압축을 풀고, 더블클릭을 해서 프로그램을 실행을 한 후, 관리자 암호 요청에 암호까지 입력해 주어야 비로소 컴퓨터에 설치가 되었습니다.

그런 다음에는 iChat을 통해서 다른 사람의 컴퓨터로 파일을 전송하기는 합니다. (이 경우에도 인터넷을 통해서 전송될 수는 없고, Bonjour 로컬 네트워크 상의 유저에게만 보내집니다.) 상대방의 컴퓨터에 온전히 전염이 되기 위해서는, 상대방이 파일 전송을 수락하여 파일을 다운로드 받고, 압축을 풀고, 더블클릭하여 실행을 한 후, 관리자 암호 요청에 암호까지 입력해 주어야만 합니다.

다시 말하면, 운영체제 상의 보안 헛점을 이용한 프로그램도 아니었고, 스스로 퍼질 수 있는 프로그램도 아니었으며, 로컬 네트워크 상의 모든 컴퓨터 유저가 협조를 해서 퍼지게 만드는 경우에도 전염이 로컬 네트워크에서만 이루어질 수 있고, 인터넷을 통한 전염은 애초에 불가능한 프로그램이었습니다. 거기에다가 버그 마저 있어 전염된 경우에도 아무런 해를 끼치지 못했다고 합니다. 당시에도 참 불쌍한 바이러스라며 많은 맥 사용자의 동정(?)을 샀었는데요.. 여기에서 오늘의 퀴즈 나갑니다. 과연 OSX/Leap-A는 바이러스였을까요? ;)

Posted in  | Tags ,  | 6 comments | 1 trackback

Ultimatum Game

Posted by 大山 Thu, 21 Sep 2006 10:26:00 GMT

EuroOSCON 2006기조연설에서 Tor Nørretranders가 재미있는 게임을 가르쳐 주었다. Ultimatum Game이란 것이데 다음과 같은 게임이다.

두명의 플레이어가 게임을 한다. 첫번째 플레이어는 10만원을 받는다. 돈을 받은 플레이어는 그 일부를 두번째 플레이어에게 나누어 주어야 한다. (얼마를 주는지는 자유이다.) 두번째 플레이어는 돈을 받거나 거부할 수 있다. 두번째 플레이어가 돈을 받으면, 두 플레이어는 각자 돈을 챙기게 된다. 두번째 플레이어가 돈을 거부하면, 둘 다 돈을 잃게 된다.

첫번째 플레이어는 과연 어떻게 할까? 첫번째 플레이어가 인간성이 좋다면, 5만원을 두번째 플레이어에게 나눠 줄 것이다. 두번째 플레이어는 아마도 수락할 것이고, 둘 다 5만원씩 챙기는 해피 엔딩이다.

하지만 첫번째 플레이어가 학교에서 게임이론을 배웠다면, 얘기가 조금 달라진다. 두번째 플레이어가 이성적인 사람이라면, 스스로에게 손해가 되는 일은 하지 않을 것이다. 따라서 첫번째 플레이어는 두번째 플레이어에게 단 천원만을 주어도 충분하다. 두번째 플레이어는 이것을 거부하면 아무 것도 챙기지 못하기 때문에 수락할 것이 분명하다. (하지만 두번째 플레이어가 거부를 한다면, 첫번째 플레이어와 두번째 플레이어 둘 다 돈을 잃게 된다.)

실제로 이 게임을 해보면 과연 어떤 결과가 나올까? 평균적으로는 첫번째 플레이어가 두번째 플레이어에게 주는 돈의 액수가 2만원 미만일 때, 두번째 플레이어는 돈을 거부한다고 한다. 즉 두번째 플레이어는 자신이 손해를 보는 것 보다는 상대방의 부당함을 처벌하는 것을 더 중요시 여긴다는 것이다.

수학적인 사고에 익숙하며 사람보다는 컴퓨터와 더 많은 시간을 보내는 우리 개발자들에게 시사점을 던져주는 이야기라는 생각. 결국 사람이 사용하는 소프트웨어도 논리적인 당위성 보다는 인간의 이런 비이성적인 면을 잘 고려해서 만들어야 할테니 말이다.

참고로 첫번째 플레이어가 컴퓨터이고 두번째 플레이어가 사람이라면, 결과는 전혀 달라진다고 한다. 컴퓨터의 경우에는 천원만 나눠 주어도, 두번째 플레이어는 그것을 고맙게 받아들인다. 아둔한 컴퓨터는 처벌을 해도 바뀔 줄 모르기 때문이라나.

Posted in  | Tags , ,  | 10 comments | no trackbacks

대안언어축제 2006 후기

Posted by 大山 Mon, 04 Sep 2006 22:49:00 GMT

주말에 대안언어축제에 다녀왔다. 대안언어축제를 어떻게 설명해야 할까. 기본적으로는 각종 비주류 언어에 익숙한 사람들이 튜토리얼 발표 세션을 진행하고, 이들 언어에 관심을 가진 사람들이 참석하는 컨퍼런스라고 할 수 있을 것 같다. 이번에 다뤄진 언어는 루비, Haskell, Mathematica, Lisp, Smalltalk, Objective-C, J, 자바, Io, OCaml, Curl, Lua 등. 200여명의 사람들이 모여 2박3일간의 합숙 형태로 진행되었고, 정규 세션 외에도 BOF(끼리끼리 모임), 언어교환 등의 활동이 활발하게 이루어진 행사였다.

나는 Wookay님의 루비 튜토리얼, 승범님의 Squeak 세션에 참석하고, 레일스 세션을 진행하게 되었다. Squeak은 매번 설치만 해 놓고 더 나아가질 못했었는데 승범님의 튜토리얼 덕분에 드디어 한발짝 들여놓게 된듯. Squeak은 딱 꼬집어 설명하기 어려운 부분이 있지만, Smalltalk로 모든 것을 제어할 수 있는 GUI 운영체제라 할 수 있을까? 예를 들면, 그림판에서 그림을 하나 만들어 객체로 변환하고 거기에 코드를 추가해서 화면에서 움직이게 할 수 있다. 무언가 끌리는 분은 Alan Kay의 Etech 2003 기조연설인 Daddy, Are We There Yet?을 참고할 것.

첫날 밤에는 재명님으로부터 Haskell을 배웠는데, C 만큼이나 아름다운 언어라는 생각. Haskell은 진정한 함수형 프로그래밍이란 무엇인가를 명확하게 보여주는 언어였다. Lisp이나 수학을 좋아하는 생각하는 사람이라면 꼭 Haskell을 익혀보라고 권하고 싶다.

둘째날에는 deepblue님, 철호님과 루비, 프로그래밍, 웹 등에 관한 여러 생각을 나눌 수 있어서 좋았고, Wookay님과의 맥북 네트워킹 실험(?)도 기억에 남는다. 루비도 맥도 저변이 점차 확대되고 있는 것을 느낄 수 있었다. 루비 전문 개발 회사를 차리신 분도 만나 뵈었고, 내년 행사에는 꼭 맥북을 들고 오겠다는 포부(?)를 밝혀주신 분도 계셨다.

셋째날에는 브라이언님과 Lisp에 관한 많은 이야기를 나눌 수 있었는데, 특히 Common Lisp 표준의 성과와 문제점 등 막연하게 짐작만 하고 있던 내용에 대해 구체적인 설명을 들을 수 있어서 좋았다.

돌아오는 버스에서는 혜식님과 이야기를 나누면서 왔는데, 유니코드의 한글 호환 자모의 존재 이유와 다국어 도메인 이슈에 관한 정확한 기술적 설명을 들을 수 있었다. 오래된 기억을 더듬어 어찌어찌 한 것이라고 밖에 표현하지 못하던 나와는 대조적으로 모든 용어를 정확히 기억하고 구사하시는 것이 인상적이었다. 개인적으로 오랬동안 궁금해하던 이슈를 명쾌히 설명해 주셔서 무척 감사!

솔직히 국내에 대안언어축제와 같은 컨퍼런스가 있다는 것에 조금 놀랐고, 개인적으로도 많은 의미가 있었던 행사였다. 배운 것도 많았지만, 많은 분들을 만날 수 있어서 특히 좋았다. 창준님을 비롯하여 이처럼 뜻깊은 행사를 기획하고 준비하신 모든 분들께 감사의 말씀을 전하고 싶다. 국내에 참석할만한 프로그래밍 컨퍼런스가 없다고 아쉬워한 분이 있다면, 대안언어축제를 꼭 권하고 싶다.

Posted in  | Tags ,  | 13 comments | no trackbacks

맥 사용을 옹호하며

Posted by 大山 Thu, 03 Aug 2006 05:23:00 GMT

한달쯤 전에 개발자는 왜 맥을 써야 하는가라는 글을 쓴 적이 있다. 글을 쓴 동기야 여러가지가 있겠지만, 외국에서는 상당히 많은 개발자, 오피니언 리더들이 이미 맥으로 옮겨가 버렸는데 반해, 국내는 아직도 마이크로소프트에 발목을 잡혀 있는 현실이 안타까웠던 이유가 가장 컸던 것 같다.

오늘 우연히 왜 개발자는 맥을 쓰지 말아야 하는가라는 글을 읽었다. 블로그를 통한 토론도 시도해 볼겸해서 한 번 조목조목 항목별로 반박해 볼까 한다.

1. 겉만 아름다운 UI?

맥 OS X은 분명 꽤나 잘 다듬어진 UI를 가지고 있기는 하다. 하지만 나는 결코 맥 OS X의 UI를 아름답다고 말하지는 않을 것 같다. 디자인의 목적은 아름다움이 아니다. 디자인에 있어 아름다움이란 적합한 디자인에 필연적으로 뒤따라오는 하나의 부산물에 불과하다. 화려하기만한 디자인은 단지 천박할 뿐이며, 애플은 이 사실을 누구보다 잘 이해하는 회사이다.

맥 OS의 UI에 대해 이해하려면 우선 John Siracusa의 파인더에 관하여와 John Gruber의 블로그에 있는 맥 OS의 UI에 관한 주옥같은 글들을 먼저 읽어 보도록 하자. (두 사람 모두 맥 OS X의 UI에 대한 가장 신랄한 비평가이다.) 이 정도의 사전지식 없이 맥 OS의 UI에 대한 비판을 하는 것은 무모하다.

글쓴이는 또한 맥 OS에서의 개발이 개방적이지 못하다고 비판한다. 물론 맥에서 윈도우용 GUI 애플리케이션을 개발하지는 못한다. 하지만 대부분의 오픈소스 개발과 웹 개발을 두고 보았을때 맥 OS는 완전히 개방적이다. 게다가 맥 OS X는 X Window 기반 개발, 자바 개발, 그리고 Cocoa 개발까지가 모두 가능한 플랫폼이다. 글쓴이는 윈도우 GUI 애플리케이션 개발이 불가능하다고 맥을 폐쇄적인 운영체제라고 부르는 건지. 그렇다면 윈도우 기반의 개발 외에는 어떤 개발도 불가능하거나 애매한 윈도우는 개방적인 플랫폼이란 말인가.

개인적으로 맥에서 5년 가까이 개발해 왔지만, 맥 GUI 애플리케이션을 개발하지는 않는다. 게다가 GUI 애플리케이션 시장은 이미 틈새 시장이라고 말하기도 어려울 정도로 축소되어 버리지 않았는가.

BSD의 유혹?

이전 글에서도 말했듯이 맥 OS X의 기반이 유닉스라는 것은 커다란 매력이다. 이 부분에서 글쓴이는 다소 엉뚱하게 Mail이나 키노트 같은 프로그램 때문에 맥 OS에 갖혀 버릴지도 모른다고 주장하고 있다. 이메일이야 프로그램간에 자유로운 이동이 가능하니 애플의 Mail 때문에 맥 OS에 갖힌다는 얘기는 어불성설이고, 키노트 역시 파워포인트로 파일저장이 가능하니, 키노트 때문에 맥 OS에 갖힐 일도 없을 것이다. (게다가 키노트의 파일 포맷은 XML로 완전히 공개되어 있다.) 여기에 가장 인기있는 맥 애플리케이션인 아이튠스는 윈도우 버전이 이미 오래전부터 나와 있다. 이토록 개방적인 맥 OS X이 폐쇄적이라고 비판하는 글쓴이는 오히려 자신이 윈도우에 완전히 갖혀 있어서 중립적인 시각을 갖기 어려운 것은 아닌지 되묻고 싶다.

3. 애플 제품의 높은 고장 빈도?

과거에 애플 제품이 튼튼하기로 명성이 높았던 것은 사실이다. 언제나 고가의 최고 부품만을 고집했었기 때문이다. 그래서 애플은 가격이 비싸다는 비판을 많이 받기도 했다. 이제 애플은 가격대를 낮추기 위해 고군분투하고 있으며, 예전만큼 고급 부품을 고집하지는 않는 것 같다. 이 덕분에 이제 맥은 가격대비 성능으로 보았을때 윈도우 PC 보다 훨씬 더 나은 가치를 제공한다는 평가를 받지 않는가.

글쓴이는 위의 이유로 맥의 불량율이 윈도우 PC에 비해 훨씬 높다고 지적하고 있다. 근거로는 인터넷 게시판과 개인적인 간접 경험을 제시할 뿐이다. 직접 미국 소비자 만족도 지수를 검색해 봤다. 2005년 8월 기준으로, 미국 내의 컴퓨터 제조업체 전체중에 애플이 소비자 만족도로 1등을 했다. 이와는 별도로 미국에서 소비자 만족도 조사로 공신력이 높은 Consumer Report의 조사에 따르면, 문제가 발생했을때의 기술지원 부문에 있어서도 애플이 현저한 점수차이로 1등을 했다고 한다. 정치도 아닌 분야에서 카더라 식의 주장은 더더욱 곤란하다. 근거를 인용하려면 정확하고 객관적인 자료를 사용하도록 하자.

한가지 첨언하자면, 미국의 첨단 프로그래밍 컨퍼런스(OSCON, ETech 등)에 맥 노트북을 들고 오는 참석자의 비율은 이미 70%를 넘어 섰다. 얼마 전에 직접 다녀온 RailsConf의 경우 전체 참석자의 90%가 넘는 인원이 파워북이나 맥북을 사용하고 있었다. 여기에는 그럴 만한 이유가 있다. 나중에 다른 글에서 맥이 갖는 장점을 포괄적으로 한 번 정리해 보도록 하겠다.

Posted in  | Tags , ,  | 13 comments | 1 trackback

자기 소개

Posted by 大山 Tue, 18 Jul 2006 11:11:00 GMT

새로운 것을 좋아하지만 맹목적이지는 않으려 노력합니다. 아직 서툴지만 균형의 중요성을 이해하며 균형있는 삶을 살아가려 애씁니다.

끊임없이 도전하고 실패하고 배웁니다. 실패는 때로 삶의 균형을 흐트러 뜨리지만 나중에 더 안정적인 균형의 근원이 될 것이라고 생각합니다.

아는 것이 많아지면 모르는 것은 갑절로 늘어가는 것 같습니다. 너무 많이 알아서 너무 많이 모릅니다.

Posted in  | no comments | no trackbacks

손톱깎기의 지겨움

Posted by 大山 Tue, 18 Jul 2006 00:16:00 GMT

나는 손톱깎는 것을 싫어한다.
불가피해서 한다.
안깎는 게 신성하다.
손톱깍기엔 손톱을 파괴하는 요소가 있다.

그러나 손톱이 짧아야만 키보드를 칠 수 있다.
나도 평생 키보드를 쳤다.

손톱을 깎으면 손톱이 깨진다는 거 안깎고 내버려 두어보면 안다.
나는 손톱을 매일 깎을 때도 있었고 몇주째 내버려도 보았지만
내버려 둘때 손톱이 온전해지고 길어지는 걸 느꼈다.

손톱을 보면 개발자 손톱 같고
손톱을 보면 디자이너 손톱 같고
손톱을 보면 기획자 손톱 같아 보이는 손톱은 손톱깎기 때문에 망가진 거다.
누구의 손톱인지 감이 안 와야 그 손톱이 온전한 손톱이다.

그런데 손톱 안깎는거, 그게 말이 쉽지 해보면 어렵다.
적당히만 기르는 거는 내버려 두는게 아니라 손톱깎기의 연장이다.
가끔이라도 깎지 않으면 못 참는 거는 손톱깎기에 중독되어 있는 거지 내버려 두는 게 아니다.
내버려 두는 거는 그냥 자라는 손톱을 바라만 보는 거다.

- 손톱깎기의 지겨움 中 [1]

개발자에게 게으른 것은 덕목이라고 한다. 가능한한 많은 것을 자동화해서 생산성을 높여야하기 때문이다. 그래서 경험이 쌓일수록 스크립트를 많이 짜게 된다. 루틴이 되어 버린 작업을 자동화 시킬 수 있으니까.

오늘도 손톱이 키보드에 미끄러지기 시작해서 손톱깎기를 집어들었다. 루틴도 이만한 루틴이 없는데 손톱깎기 스크립트는 짤 수가 없다.

  1. 이 글은 김훈 작가의 밥벌이의 지겨움에 나오는 글귀를 패러디한 것입니다.

Posted in  | Tags ,  | no comments | no trackbacks

윈도우 키보드 유감

Posted by 大山 Thu, 13 Jul 2006 19:47:00 GMT

요즘 어쩔 수 없이 윈도우를 써야 할 일이 생겨서 윈도우 피시 앞에서 씨름을 할 때가 많다. 나에게 윈도우를 쓴다는 것은 여러모로 답답한 일인데 첫번째 장애물은 바로 키보드다.

보통 윈도우 컴퓨터의 키보드는 뻑뻑하기가 이루 말할 수가 없다. 윈도우 사용자는 주로 마우스를 사용하기 때문에 불편함을 못느끼는게 아닌가 싶지만 내 경우에는 타자 속도가 한 오분의 일로 줄어드는 느낌이다.

윈도우 키보드의 두번째 문제점은 '윈도우' 키다. MS는 무슨 생각으로 이런 아무 쓸짝에도 없는 키를 발명해서 귀중한 키보드 공간을 낭비하는 건지.. 특히 '윈도우' 키 때문에 밀려난 키가 Alt 키이기 때문에 더 마음이 아프다.

Alt 키는 emacs 사용자에게는 필수적인 키인데 윈도우 키보드에서는 가운데 쪽으로 위치가 밀려 들어가서 새끼 손가락으로 이를 누르는게 너무 애매하게 되었다. 아마 윈도우 개발자 중에 emacs 사용자 비율이 상대적으로 적은 이유의 한가지일 듯 싶다.

한때는 나도 윈도우 사용자였던 때가 있다. 그때도 '윈도우' 키를 의도적으로 눌러본 적은 한 번도 없었다. (가끔 실수로 눌러져 울화통이 터지던 기억은 있다..) 키보드 만드는 회사들아, 한때 키보드 상단을 장식하던 각종 애플리케이션 단축키를 정리해준 것처럼 이제는 '윈도우' 키도 제거해주면 안될까?

윈도우 키보드의 마지막 문제는 사실 한글 윈도우의 문제다. 우선 한/영 변환키의 위치가 너무 어설프다. 도대체가 키보드 위에 정렬된 손가락을 흐트러 뜨리지 않고는 변환키를 누를 수가 없다. 게다가 오른쪽의 Ctrl 키와 Alt 키는 작동조차 하지 않는다. 오른쪽 Alt 키의 경우 한/영 전환이 되어 버리는데 그럴거면 한/영 전환키는 뭐하러 만든거니.. 설정에서 드라이버 바꾸면 고칠 수 있기는 하다. 어디로 들어가 버렸을지 모르는 윈도우 CD를 찾을 수 있다면 말이다..

키보드 하나만 잘 만들어도 국가 경쟁력이 올라간다. 제발 작은 것 하나 만들 때도 고민하며 만들자.

Posted in  | Tags , ,  | 14 comments | no trackbacks

남의 컴퓨터 화면 엿보기

Posted by 大山 Tue, 11 Jul 2006 07:17:00 GMT

얼마전 RailsConf 참석차 미국에 갔다가 맥 OS X 관련 팁을 두개 배우게 되었다. 한번은 컨퍼런스 중에 내 왼편에 앉은 사람의 맥북 화면을 훔쳐보다가 였다. 헉, 언제부터 NetNewsWire가 폴더 기능을 지원한거지?

베타버젼부터 4년째 NetNewsWire를 사용해오고 있는데 대체 언제 기능이 추가된건지.. 불과 며칠전에 폴더기능이 아쉬워 기능요청을 내볼까 하는 생각을 했었기에 더 황당했다. 내 맥에서 뒤져보니 File 메뉴 아래에 'New Group'이란 이름으로 있더라. 찾기 좀 쉽게 만들어 놓을 것이지..

모르는 분을 위해 설명하면 NetNewsWire는 세계 최초의 RSS 리더기이다. RSS가 지금처럼 널리 쓰이기 이전에 개발되어 어떻게 보면 RSS가 지금의 형태로 발전하는데 커다란 공헌을 한 제품이기도 하다. NetNewsWire는 맥에서만 돌아가는데 이 애플리케이션 하나만으로도 맥으로 스위치할만한 충분한 이유가 된다고 할만큼 유용한 애플리케이션이다.

윈도우용 RSS 리더기도 있지 않냐구? 혹시, 윈도우에서 RSS 리더기 쓰는 사람을 아시는지? 내 경험상 윈도우 쓰는 사람들은 차라리 웹 RSS 리더기를 쓰더라. 반면에 난 아직까지 맥쓰면서 NetNewsWire를 안쓰는 사람은 본적이 없다.

또 한번은 애플 스토어에 가서 인터넷을 빌려 쓰다가였다. Mail.app에서 스레딩 기능이 지원되는 거였다! 헉, 이걸 모르고 있었다니.. 찾아보니 보기 메뉴 밑에 '스레드로 보기' 기능이 있었다. 이건 또 언제 추가된거야.

아무튼 오늘도 이 두가지 기능을 쓰면서 흡족해 하다가 블로그에 소개해 본다. 종종 남의 컴퓨터 화면을 엿보는 것은 유용한 일인듯. 근데 GMail 사용자 분들, 도대체 GMail은 왜 사용하는 거죠?

Posted in  | Tags , , , ,  | 5 comments | no trackbacks

미디어와 과학

Posted by 大山 Tue, 13 Jun 2006 05:34:00 GMT

오늘 한겨레 신문에서 학술적으로 쓰면 기사 안 된다?라는 컬럼을 읽었다. 내용 중엔 어느 기자의 다음과 같은 항변이 소개되어 있었다.

그렇게 학술적으로 쓰면 그게 학술논문이지 기삽니까?

그동안 신문에 실리는 온갖 엉터리 과학기사가 이래서 그랬구나라는 생각이 들어 씁쓸했다. 그동안은 기자들의 전문성 부족 탓이려니, 시간이 지나서 분야별 전문기자가 늘어나면 괜찮아 지려니 했었다. 근데 아닌 것 같다. 이건 언론의 속성 문제인 것 같다.

신문들은 그냥 과학 관련 기사를 취급하지 않아야 하는게 아닐까? 어짜피 이분야에 관심 있는 사람들은 다른 경로를 통해 필요한 정보를 접한다. 이분야에 크게 관심이 없는 사람들에게까지 기사꺼리가 될만한 과학소식이라면 십중팔구는 사기거나 지나친 과장일 것이다.

그건 그렇고 상관관계와 인과관계도 구분 못하는 기사는 기자 본인에 대한 신뢰도를 떨어뜨린다는걸 기자들은 아는지 모르는지.

Posted in  | Tags , ,  | 2 comments | no trackbacks

영어의 필요성

Posted by 大山 Tue, 06 Jun 2006 04:14:00 GMT

누구나 영어의 중요성을 이야기한다. 근데 알맹이가 없더라. 왜 중요한지는 모른다는 얘기다.

사람이 의사결정을 내리는 방법은 크게 두가지다. 스스로 판단하는 경우가 한가지고, 다른 사람의 판단을 대략 따라가는 경우가 나머지 한가지이다. 보통 자신이 잘 아는 분야에 대해서는 스스로 판단을 내리게 되고, 자신이 잘 모르는 분야에 대해서는 다른 사람의 판단을 따라가게 된다.

영어를 못하는 사람은 영어가 왜 중요한지 모른다. 자신이 잘 모르는 분야이다 보니, 다른 사람의 판단을 따라가는 수 밖에는 없다. 근데 문제는 주변에도 영어를 잘하는 사람이 없다는 것이다. 상대적인 전문가를 찾다 보니, 자기보다 토익 점수가 높은 사람을 따라하게 되는데, 그러다 보니 모두가 토익 준비만 열심히 하게 된다. 이것이 대한민국이 영어를 못하는 근본적인 이유이다.

영어가 필요한 진짜 이유 = 영문 자료를 접하기 위해서

영어를 사용하는 인구는 대략 5-10억명 정도로 추산된다. 이들은 대부분 선진국 국민이거나, 그렇지 않더라도 각 나라의 엘리트들이다. 중요한 것은 이들이 생산해 내는 정보다. 신문/잡지, 도서, 학계, 인터넷 등을 통해 영어 사용 인구가 생산해내는 정보는 질적으로도 양적으로도 엄청나다.

그럼 토익 점수가 900점이 넘는 실력이면, 영어로 생산된 고급 정보를 접할 수 있을까? 답은 아니요다. 토익 만점을 받아도 부족하다. 왜냐구? 우선 토익은 너무 쉬운 시험이다. 둘째로 토익은 따로 시험 준비를 하지 않고 보았을때만 영어 실력을 정확히 측정해 준다. 시험을 대상으로 준비하기 시작하는 순간, 토익 점수는 그 의미를 잃어버린다.

그러니까 제발 토익 준비에 시간 좀 그만 낭비하자. 그시간에 제대로 영어를 공부하면, 영어를 잘하는 것 불가능하지만은 않다.

Posted in  | Tags  | 1 comment | no trackbacks

영어를 잘한다는 것

Posted by 大山 Mon, 05 Jun 2006 12:21:00 GMT

흔히들 영어가 중요하다는 얘기들을 많이 한다. 거기에 왜라는 물음을 던지면, 어떤 답이 돌아올까 문득 궁금해졌다. 몇사람의 답을 들어보니, 사실 영어 그 자체가 중요한 것은 아니더라. 단지 영어 점수가 중요할 뿐이었다.

한국사회에서 영어 점수란 개인의 성실도를 측정하는 주요 잣대가 되어버린 듯. 사실 한국에서 영어를 잘하는 사람은 거의 없다. 영어를 잘하는 기준이 뭐냐고? 원서를 읽는데 걸리는 시간이 번역서를 읽는데 걸리는 시간보다 두배가 넘지 않으면 영어를 잘할다고 볼 수 있다.

여기서 중요한 사실 하나. 위에 제시한 기준으로 영어를 잘하게 되는데 걸리는 시간과 노력은 토익 900점 받는데 드는 시간과 노력보다 많이 들지 않는다. 다른 것 안하고 영어만 공부한다고 할때 일년이면 충분하다.

첨언하자면, 언어는 하루에 한시간씩 꾸준히 익히는게 아니다. 하루에 열시간씩 일년을 공부하면 어떤 언어든 필요한 만큼 잘하게 된다. 하루에 한시간씩 공부하려 하면 이삼년을 못넘기고 포기하게 된다. 실력이 안느는 건 두말할 필요도 없다.

Posted in  | Tags  | 2 comments | no trackbacks