Joel on Software   조엘 온 소프트웨어

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

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

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

조엘의 평가 목록 (The Joel Test)을 처음 웹사이트에 공개했을 때 독자들이 가장 민감한 반응을 보였던 항목 중의 하나가 스펙 작성에 관한 것이었다. 스펙을 작성하는 것은 치실을 사용하는 것과 같아서, 그 필요성은 누구나 인정하지만 아무도 하지 않는다.

그렇다면, 왜 사람들은 스펙 작성을 기피할까? 사람들은 스펙 작성 단계를 건너뜀으로써 시간을 절약할 수 있다고 주장한다. 그들은 마치 스펙을 만드는 일을 미국항공우주국에서 우주선을 만드는 엔지니어들이나 혹은 대형 보험회사에서 근무하는 직원들에게나 어울릴만한 사치쯤으로 여기는 것 같다. 말도 안 되는 소리다. 무엇보다, 스펙을 작성하지 않는다는 것은 소프트웨어 프로젝트와 관련된 가장커다란위험을스스로자초하는 일이다. 그것은 옷가지만 달랑 등에 진 채 모하비 사막을 횡단하겠다고 나서는 것만큼이나 어리석은 행동이다. 사막을 날아오르기라도 하겠다는 건가. 스펙도 없이 코딩 작업에 뛰어드는 프로그래머나 소프트웨어 엔지니어들은 자신을 폼 나는 총잡이쯤으로 생각하는 경향이 있다. 허리춤에서 권총을 뽑자마자 바로 목표물을 명중시키는 총잡이. 하지만, 그들은 그런 명사수가 아니다. 아주 비생산적인 프로그래머일 뿐이다. 형편없는 코딩으로 조악한 소프트웨어를 만들어내고, 불필요한 위험을 자초하여 프로젝트를 위태롭게 만들 것이다.

필자는 코딩 작업에 1주일 이상이 소요되거나 2명 이상의 프로그래머가 참여하는 프로젝트의 경우, 스펙을 만들지 않으면 항상 작업 기간은 더 길어지고 코드 품질은 더 떨어진다고 믿는다. 그 이유는 다음과 같다.

스펙의 가장 중요한 기능은 프로그램을전체적으로설계하는것이다. 코딩 작업을 혼자 진행하고 오로지 자기자신만을 위해 스펙을 작성하는 경우라 해도, 스펙을 작성하다 보면 프로그램이 어떻게 작동되어야 하는가를 구체적으로 기술하게 되기 때문에 실질적으로 프로그램을 설계하게 된다.

서로 다른 회사에서 일하는 두 명의 프로그래머를 상상해보자. Hasty Bananas Software의 스피디 양은 절대 스펙을 작성하는 법이 없다. “스펙? 스펙 같은 건 필요 없어!” 한편, Well-Tempered Software Company의 로저스 씨는 스펙이 완전히 확정되기 전까지는 절대 코딩을 시작하지 않는 사람이다. 필자에게는 이들말고도 여러 명의 상상 속 친구들이 있다.

스피디와 로저스에게는 한 가지 공통점이 있다. 각자 자기 회사 제품의 2.0 버전이 기존 버전과 소급호환이 가능하도록 프로그래밍해야 한다는 점이다.

스피디는 간단하게 1.0 버전 파일을 2.0 버전 파일로 변환시켜주는 컨버터를 코딩하는 것이 소급호환을 제공하는 가장 좋은 방법이라고 결론 내린다. 그녀는 곧장 코딩을 시작한다. 쉴새 없이 자판을 두드리고 마우스를 클릭한다. 하드드라이브가 윙윙 돌아가고, 바쁘게 작업이 진행된다. 약 2주일 후, 그녀는 그럴듯한 컨버터를 만들어냈다. 하지만, 고객은 만족스럽지 않은 모양이다. 스피디가 개발한 코드대로라면 회사 내의 전직원들이 일괄적으로 2.0 버전으로 업그레이드를 해야 하기 때문이다. 스피디의 가장 큰 고객인 Nanner Splits Unlimited는 새로운 소프트웨어를 살 수 없다고 말한다. Nanner Splits사는 버전을 변환하지 않고서도 2.0 버전이 1.0 버전 파일 상에서 작동될 수 있는지를 알고 싶어했다. 스피디는 소급 컨버터를 코딩한 후, 이를 “저장” 기능에 연결하기로 결정한다. 그런데, 이 방법에는 다소 문제가 있다. 사용자가 1.0 파일 상에서 2.0 버전의 기능을 사용하는 경우, 파일을 1.0 포맷으로 저장하려고 하기 전까지는 2.0 기능이 제대로 작동되는 것처럼 보이기 때문이다. 사용자가 저장을 시도한 후에야 시스템은 사용자가 30분 동안 작업했던 기능이 1.0 파일 포맷에서는 작동되지 않는다는 메시지를 보여준다. 그래서, 컨버터를 다시 코딩하는 데 추가로 2주가 더 걸렸고, 그럼에도 불구하고 결과는 별로 신통치 않았다. 총 4주일의 시간이 경과된 것이다.

한편, Well-Tempered Software Company (간단하게 "WellTemperSoft"라고 하자)의 로저스는 스펙이 확정되기 전까지는 코딩 작업을 거부하는 원칙주의자형 프로그래머다. 그는 약 20분 동안 스피디와 같은 방식으로 소급호환 기능을 설계한 후, 다음과 같은 요지의 스펙을 들고 나타났다.

• 구버전으로 작성된 파일을 열 때, 해당 파일이 신버전으로 전환되도록 한다.

이와 같은 내용의 스펙을 고객에게 보이자, 고객은 “잠깐만! 모든 직원이 한꺼번에 버전을 업그레이드하게 되는 것은 원치 않소!” 라고 했고, 로저스는 잠시 더 생각한 후, 스펙을 다음과 같이 수정했다.

• 구버전으로 작성된 파일을 열 때, 해당 파일은 메모리 내에서 신버전으로 전환된다. 이 파일을 저장할 때, 사용자는 원래의 버전으로 다시 변환할 것인지 여부를 선택할 수 있다.

다시 20분 정도의 시간이 더 경과되었다.

로저스의 상사는 이 스펙을 들여다보더니 뭔가 탐탁치 않다고 생각한다. 그는 다른 아키텍처를 제안한다.

• 코드를 분해하여 V1과 V2의 두 가지 인터페이스를 사용하도록 한다. V1에는 1.0 버전의 모든 기능이 포함되고, V2는 여기에 신버전의 기능을 추가한다. V1의 저장 기능은 소급호환 문제를 처리할 수 있고