Joel on Software   조엘 온 소프트웨어

한글로된 다른 "Joel on Software" 글들

영어로된 다른 "Joel on Software" 글들

필자 메일주소(영어만 사용)

1982년에 우리 가족은 이스라엘에서 최초로 IBM-PC를 손에 넣게 되었다. 사실 우리는 보세 창고에 가서 PC가 도착하는 것을 지켜보았다. 나는 아버지에게 우리 컴퓨터가 플로피 디스크 2대에, 128 K 메모리, 도트 매트릭스 프린터 (신속한 기안 작성용), 브라더 활자 품질의 데이지휠 프린터를 갖춘 완전 장착형 버전이라고 단언했다. 이 중에서 브라더 프린터는 출력할 때의 소음이 기관총 소리처럼 들린다. 사실 그보다 더 크다. 지금 생각해보면 사용할 만한 부가 장치는 거의 다 갖추고 있었다. PC-DOS 1.0에, BIOS, 매크로 어셈블러, 깜짝 놀랄 만한 전체 80 칼럼 IBM 모노크롬 디스플레이가 목록에 포함되어 있고 완벽한 소스 코드를 포함한 75 달러 상당 기술 참조 매뉴얼, 거기다가 소문자까지! 그 당시 이스라엘의 말도 안 되는 수입 관세까지 포함해서 비용은 모두 10,000 달러라는 엄청난 가격이었다!

그 때 “우리 모두는” BASIC은 아이들이나 쓰는 언어이며, 스파게티 코드를 쓰기하려면 뇌가 카망베르 치즈처럼 흐물흐물하게 변해버릴 거라는 점을 알고 있었다. 그래서 600 달러를 들여 IBM 파스칼을 구입했는데 이 프로그램은 플로피 디스켓 석 장에 들어간다. 컴파일러를 사용하려면 먼저 첫 번째 디스켓을 거쳐 다시 두 번째 디스켓을 삽입해야 했고, 링커(linker)는 세 번째 디스켓에 있었다. 나는 간단하게 “다들 안녕”을 쓰고 이 말을 컴파일했다. 전체 소요 시간: 8분.

음, 오래 걸린다. 나는 배치 파일을 쓰기하여 프로세스를 자동화했고 시간은 7.5분으로 줄어들었다. 나아졌다. 그렇지만 긴 프로그램을 쓰기해보려 할 때, 특히 오델로처럼 항상 애먹이는 버전에서는 컴파일하는 시간 대부분을 기다리면서 보내야 했다. “당연하지.” 한 전문 프로그래머가 해준 말이다. “사무실에서는 헬스 장비가 있어서 컴파일하는 도중에 사용하곤 했거든. 몇 달 프로그래밍 작업을 하고 났더니 배에 왕 (王)자가 새겨지더라니까.”

하루는 컴파스 파스칼이라는 멋진 프로그램이 덴마크에서 출시되었는데 이 프로그램을 Philippe Kahn이 사들여서 볼란드 터보 파스칼이라고 제품명을 바꾸었다. 이 프로그램은 일종의 충격이었다. 기본적으로 IBM 파스칼에서 시행할 수 있는 모든 작업이 가능한 데다가 메모리 크기는 텍스트 에디터를 포함하고도 겨우 33K에 불과하다니. 너무나 놀라운 제품이었다. 더 놀라운 건 작은 프로그램 하나를 컴파일하는 시간이 1초도 채 걸리지 않는다는 점이었다. 마치 어떤 무명 회사에서 Buick LeSabre를 꼭 빼닮은 자동차를 소개하는 것 같았다. 이 기종은 최대 시속이 백만 마일이나 될 뿐 아니라 전 세계를 주행해도 소모되는 가솔린이 겨우 새모이 정도 밖에는 들지 않는다.

갑자기 나는 보다 더 생산적으로 사고하게 되었다.

바로 이 무렵 나는 REP 루프의 개념을 알게 되었다. REP란 "읽고 (R), 평가하고(E), 인쇄하라 (P)”의 약어로, 이 말을 통해 리스프 해석 프로그램에서 시행하는 작업을 파악할 수 있다. 이 프로그램은 사용자의 입력 내용을 “읽어들이고” 이를 평가하여 결과를 인쇄한다. REP 루프의 예를 들면, 내가 무언가를 입력하면 리스프 해석 프로그램이 내용을 읽어들이고 이를 평가하여 결과를 인쇄해준다.

좀더 큰 범위로 설명하자면, 사용자가 코드를 쓰기하면 에디트-컴파일-테스트 루프라 하는 REP 루프의 매크로 버전이 실행된다. 사용자는 코드를 에디트하고 이를 컴파일한 후에 시험을 거쳐 작업이 적절하게 이루어지는지 파악한다.

여기서 한 가지, 사용자가 프로그램을 쓰기하려면 루프를 반복, 또 반복 실행해야 한다. 따라서 이 경우 에디트-컴파일-테스트 루프 속도가 증가할수록, 생산성도 높아져서 동시 컴파일에 대한 자연 한계값에 도달하게 된다. 이로써 컴퓨터 프로그래머는 정말로 속도가 빠른 하드웨어를 필요로 하며 또한 컴파일러 개발자는 속도가 뛰어난 에디트-컴파일-테스트 루프를 실현하기 위해서라면 못할 것이 없을 거라는 컴퓨터 과학 이론 같은 진부한 말이 왜 나왔는지 알 수 있다. 비주얼 베이직이라면 이 문제가 가능하여 사용자가 입력하는 각 라인의 구문을 해석하여 이를 렉스 분석하므로 이로 인해 최종 컴파일 속도가 엄청나게 빨라진다. 비주얼 C++에서는 이를 위해 컴파일을 증가하고, 헤더를 사전 컴파일하며 링크를 증가시킨다.

그러나 여러 개발자와 테스터로 구성된 대규모 팀으로 작업을 시작하면 곧바로 동일한 루프에 마주치게 된다. 규모만 커진다. (이거, 프랙탈이잖아!) 테스터가 코드에서 버그를 발견하면 해당 버그를 보고한다. 프로그래머는 이러한 버그를 수정한다. 테스터가 수정된 코드 버전에 접근하기까지 어느 정도 시간이 소요될까? 일부 개발업체에서 이러한 보고/수정-테스트 재시도 루프는 몇 주가 소요되기도 하며 이는 곧 전사적으로 생산성이 하락함을 의미한다. 전체 개발 프로세스를 원활하게 진행하려면 보고/수정-테스트 재시도 루프를 엄밀하게 진행하는 데에 비중을 두어야 한다.