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++에서는 이를 위해 컴파일을 증가하고, 헤더를 사전 컴파일하며 링크를 증가시킨다.

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

이 경우 일별 빌드를 하면 좋다. 일별 빌드란 전체 소스 트리를 자동화하여 전체를 일일 주기로 구축하는 작업이다.

자동화-매일 지정한 시간에 코드가 컴파일되도록 설정하므로 (유닉스 상에서) cron 작업을 사용하거나 또는 (윈도우 상에서) 스케줄러 서비스를 사용한다.

일일주기 – 또는 빈도를 늘인다. 빌드를 지속적으로 시행하는 것이 적당해보이지만 소스 제어 문제로 인해 이 점이 불가능할 수도 있다. 이 문제는 잠시 후에 설명하겠다.

전체– 아마도 사용자의 코드에는 여러 버전이 포함되어 있을 것이다. (다중 언어 버전, 여러 종류의 운영 체제, 또는 하이 엔드/로우 엔드 버전) 일별 빌드에서는 이러한 버전 전체를 구축해야 한다. 또한 일별 빌드에서는 컴파일러가 재구축 기능을 불완전하게 향상시킬 경우에도 이에 상관없이 모든 파일을 처음부터 구축할 필요가 있다.

몇 가지 일별 빌드의 장점을 나열해보았다.

1. 버그가 수정되면 테스터는 신속하게 신규 버전에 접근하고 이를 다시 시험하여 버그가 실제로 수정되었는지를 확인할 수 있다.
2. 개발자는 굳이 책상 위에 시험해볼 OS/2 상자가 놓이지 않더라도 자신들이 변경한 부분으로 인해 생성되는 시스템의 1024개 버전 전체에 장애가 발생하지 않는다는 점을 더욱 확신할 수 있게 된다.
3. 예정된 일별 빌드를 시행하기에 앞서 자신의 변경 권한을 체크인한 개발자는 자신으로 인해 다른 팀원이 곤란을 겪지 않으려면 “빌드에 장애가 되는” 작업에 체크인해야 한다는 점을 알고 있다. 즉, 이 경우 아무도 컴파일 작업을 할 수 없게 된다. 이는 전체 프로그래밍 팀의 모니터에 죽음의 파란 색 화면이 나타나는 상황과 다를 바 없으며 또한 이러한 경우는 대개 프로그래머가 생성한 신규 파일을 저장소에 추가하는 작업을 잊어버린 경우 발생한다. 빌드는 개발자의 장비에서는 제대로 실행되지만 이들 외의 팀원이 체크아웃을 하게 되면 링크 오류가 발생하거나 작동이 중단되어 작업을 할 수 없게 된다.
4. 마케팅 팀, 베타 고객 사이트 등의 외부 그룹은 미완성 제품을 사용하는 그룹으로, 일정 기간 동안 안정성이 뛰어난 것으로 알려진 빌드를 선택하고 이를 지속 사용한다.
5. 일별 빌드 전체의 아카이브를 지속적으로 보관하면 실제 작업에서 새로운 이상 버그가 발견되고 이 문제의 원인을 파악할 수 없는 경우 코드에서 처음 버그를 발견했을 때 이력 아카이브 상에서 바이너리 검색을 하여 이를 정확하게 파악할 수 있다. 여기에 적절한 소스 제어를 곁들이면 문제를 유발한 체크인을 추적할 수 있을 것이다.
6. 프로그래머가 수정된 것으로 판단하는 문제를 테스터가 보고하는 경우 해당 테스터는 문제점이 발견된 빌드를 설명하게 된다. 이 경우 프로그래머는 수정본에 체크인한 시점을 살펴보고 확실히 수정이 이루어졌는지를 파악한다.

여기에 방법을 제시하였다. 일별 빌드 서버를 갖출 필요가 있는데 이러한 서버는 구비할 수 있는 컴퓨터 중 속도가 가장 빠른 것을 사용한다. 저장소에서 현재 소스 코드의 전체 복사본을 체크아웃하는 스크립트를 쓰기 작업한다. (소스 제어를 사용하고 있으리라 믿는다.) 그리고 적재한 모든 코드 버전을 처음부터 구축한다. 설치 또는 설정 프로그램을 보유한 경우 이러한 프로그램도 함께 구축한다. 고객에게 적재한 모든 프로그램은 일별 빌드 프로세스로 생성해야 한다. 프로그램 자체의 디렉토리에 각각의 빌드를 저장한다. (날짜별로 코드화됨) 매일 지정한 시간에 스크립트를 실행한다.

• 최종 빌드를 시행하기 위해 필요한 모든 작업은 일별 빌드 스크립트에서 실행되며 여기에는 외부에서 다운로드할 수 있도록 적절한 사이트의 웹 서버로 코드를 체크아웃하고 이러한 서버에 비트를 저장하는 작업이 포함된다. (개발 과정에서 이 서버는 물론 테스트 서버가 된다.) 이러한 작업은 단 한 사람의 머리 속에서 “문서화된” 빌드 프로세스에 아무 문제가 없음을 보장할 수 있는 유일한 방법이다 Shaniqua만이 설치 프로그램 생성 방법을 알고 있는데, 아뿔싸, 그 여자가 버스 사고를 당한 것이다. 그래서 제품을 출시한 후에야 상황을 파악하게 된다. 주노 팀의 경우, 전체 빌드를 처음부터 생성하려면 빌드 서버의 위치와 “Daily Build” 아이콘에서 더블 클릭하는 방법을 알아두기만 하면 된다.
• 코드를 적재하려고 할 경우 조그마한 버그 하나가 발생하였다면 정신 건강에 이보다 나쁠 수는 없을 것이다. 그러므로 일별 빌드 서버에서 작은 버그를 수정한 후에 이를 적재한다. 완벽한 규칙으로, 체크아웃을 완료한 후에 문제가 제거된 전체 일별 빌드를 통해 생성된 코드만을 적재한다.
• 컴파일러를 최대 경고 수준으로 설정하고 (마이크로소프트 제품인 경우 -W4, gcc인 경우 –Wall) 컴파일러에 최소한의 경고라도 발생하는 경우 이를 중지하도록 설정한다.
• 일별 빌드에 장애가 발생한 경우 전체 팀을 중단시키는 위험을 감수한다. 모든 작업을 중단하고 문제가 수정되기까지 재구축을 지속 진행한다. 일별 빌드를 여러 번 구축하게 되는 경우도 있다.
• 사용자의 일별 빌드 스크립트는 이메일을 통해 전체 개발 팀에 장애를 보고해야 한다. “오류” 또는 “경고” 관련 로그를 잡아내고 이를 이메일에 첨부하는 작업은 그다지 어렵지 않다. 또한 스크립트는 누구나 볼 수 있는 HTML 페이지에 상태 보고서를 첨부할 수 있어 프로그래머와 테스터는 빌드가 성공적으로 구축되었는지의 여부를 신속하게 결정할 수 있다.
• 마이크로소프트 엑셀 팀의 사례에서 본받았던 규칙으로, 빌드에 장애를 일으킨 팀원은 다른 팀원이 해당 빌드에 장애를 일으키기 전까지는 이 빌드에 대한 유지보수를 담당한다. 이러한 규칙은 빌드가 지속적으로 동작하도록 하는 현명한 장려책이 될 뿐 아니라 빌드마스터 작업 전반에 걸쳐 빌드가 거의 전 팀원을 거치므로 누구나 빌드 생성 방식을 습득하게 되었다.
• 팀이 1개 시간대에서 작업하는 경우 빌드를 실행하기 위한 적당한 시간은 점심 시간이다. 이 경우 모든 팀원이 점심 시간 전에 자신의 최신 코드를 체크인하고 팀원이 식사를 하는 동안 빌드가 실행되며 이들이 제자리로 돌아와서 빌드에 장애가 발생한 경우에는 모든 팀원이 이를 수정하게 된다. 빌드가 동작하면 모든 팀원은 즉시 최신 버전을 체크아웃하여 손상된 빌드로 인해 곤란을 겪지 않아도 된다
• 팀이 2개 시간대에서 작업하는 경우 일별 빌드의 일정을 수립하면 한 시간대의 팀원으로 인해 다른 시간대의 팀원이 곤란을 겪지 않도록 할 수 있다. 주노 팀의 경우, 뉴욕에서 근무하는 팀원은 7:00 .p.m. 뉴욕 시간에 작업을 확인하고 퇴근하였다. 이들 팀원이 빌드에 장애를 일으킨 경우 인도 팀인 Hyderabad는 (8:00 .p.m. 뉴욕 시간에) 작업에 착수하여 하루 종일 이 문제에 매달렸다. 우리는 각 팀이 귀가하기 1시간 전에 2개 일별 빌드 작업을 시작하여 해당 문제를 완전히 해결하였다

추가 참고 자료:

• 일별 빌드에 필요한 툴 관련 논의 사항
• 일별 빌드 구축 작업은 코드를 개선하기 위한 12 단계에 포함될 정도로 중요한 작업이다.
• G. Pascal Zachary의 저서 Showstopper에는 윈도우 NT 팀에서 (주간으로) 구축한 빌드에 대한 재미있는 내용이 많이 들어 있다.
• Steve McConnell은 여기에 일별 빌드에 관한 내용을 작성하였다.