수 많은 선택을 강요하는 소프트웨어 설계 스타일은 마이크로소프트와 오픈소스 진영이 거의 유일하게 의견을 일치한 부분입니다. 둘 다 모든 사람들 의견을 다 받아들여서 모든 사람을 행복하게 만들겠다는 열망에 사로잡혔으니까요. 하지만 이런 방식은 많아질수록 행복해진다는 옳지 못한 생각에 뿌리를 두고 있습니다. 정말이지 다시 생각해볼 문제 입니다.

온라인 커뮤니티의 제일 공리(公理, axiom)을 얻습니다. 아무리 사소한 소프트웨어 동작 방식이라도 커뮤니티가 발전하고, 행동하고, 느껴지는 방식에 큰 영향을 미친다.

여러분이 고객이라고 생각해 봅시다. 여러분은 프로그램 X,Y,Z를 샀습니다. 그러고 나서 윈도우XP로 업그레이드 했습니다. 어라, 종잡을 수 없이 컴퓨터가 가끔 죽습니다. 이런, 프로그램 Z는 아예 실행도 안 됩니다. 친구에게 달려가 이야기 합니다. “윈도우 XP로 절대 업그레이드 하지 마라. 시도 때도 없이 죽고, Z는 아예 돌지도 않아.” 과연, 여러분이 직접 시스템을 죽이는 원흉이 프로그램 X이고, 문서에도 나오지 않은 윈도우 메시지를 섰기 때문에 프로그램 Z는 실행도 되지 않는다고 사실을 밝히려고 디버깅을 시작할까요? 천만에요. 당장 윈도우 XP를 들고 가서 환불을 받겠지요.(X,Y,Z는 몇 달 전에 산 거라, 30일 환불 기간을 넘어가 버렸거든요. 여러분이 할 수 있는 일은…, XP를 환불받는 일 뿐이죠). 흠…. 자, 이 이야기를 비스타가 나온 지금 시점에 맞게 고쳐 볼까요?

천지창조 이후, 흠, 그러니까 약 1989년까지, 프로그래머는 효율성에 목숨 걸어야 했습니다. 메모리는 코딱지 만했고, CPU는 굼벵이 같았습니다. 1990년 후반, 마이크로소프트와 애플이라는 새로운 세력이 등장합니다. 이들은 무어의 법칙이 지배하는 세상에서 성능과 메모리 효율성에 목숨거는 미련한 짓은 그만두기로 합니다. 무어를 믿고 뭔가 쿨한 제품을 일단 만든 다음 하드웨어 성능이 뒷받침해줄 때까지 기다리고 결정합니다.

대부분 코딩 표준은 다음과 같은 규칙을 포함합니다. 함수를 짧게 유지하라. 변수는 쓰기 직전에 정의하라. 매크로를 남발하여 자기만 아는 프로그래밍 언어를 만들지 마라. goto를 쓰지 마라. 중괄호로 묶이는 블록은 한 화면에 다 보이게 하라. 이 규칙들의 밑바탕에는 코드 한 줄 한 줄이 정말로 무엇을 하는지 알려주는 정보는 가능하면 가깝게 모여 있어야 한다는 사상이 깔려 있습니다. 가까이 붙어 있을수록 여러분 눈이 뭐가 어떻게 굴러가는지 좀 더 쉽게 파악합니다.

왜, 어째서 이런 일이 일어났는지 모르겠습니다. 언제였던가 윈도우 팀 문서 작성자들이 무심코 시스템 헝가리언이라고 알려진 마물을 만들어냈습니다.

시모니가 발표한 글에서 ‘타입’이란 단어를 발견한 사악한 세력이 이 타입을 클래스, 타입 시스템, 컴파일러 타입 확인에 등장하는 진짜 타입이라고 착각했습니다. 아니, 일부러 둔갑시켰는지도 모릅니다. 어쨌거나 시모니는 의도와는 전혀 다른 방향으로 흘러갔습니다. 시모니는 자신이 무엇을 ‘타입’이라고 지칭했는지 아주 조심스럽고도 정확하게 써 놓았습니다. 하지만 별 소용이 없었죠. 이미 헝가리안 표기법은 피로 검붉게 물들어버렸으니까요.

여러분 팀 개발자가 svn commit 명령을 날리는 순간, 이 모든 것들은 이미 다 갖춰진 상태로 개발자에게 완벽하게 추상화되어 제공되어야 합니다. 관리자가 존재하는 이유가 뭐라고 생각하십니까?

크리에이티브 젠 팀이 아이팟 대항마라고 내놓은 못생긴 제품을 아무리 갈고 닦아도 아이팟에 필적할 만큼 아름답고 만족스럽고 우아한 제품을 만들어내지 못할 겁니다. 마술 같은 디자인 재능이 없기 때문에 아이팟 시장 점유율을 손톱만큼도 갉아먹지 못할 겁니다. 크리에이티브는 하늘이 두 쪽 나도 못합니다.

세계 최고 제품은 단지 ‘생산성 10배’ 문제가 압니다. ‘그럭저럭 생산성을 내는’ 개발자는 결코 위대한 소프트웨어를 만들어내는 높은 음을 내지 못합니다.