소프트웨어 잘 만들기

밤새지 말고 일정 안에 개발을 끝낼 방법은 없나요

소프트웨어는 사람이 만든다고 이야기한다. 우수한 인적 자원을 가진 대한민국이 전세계 소프트웨어 시장, 특히 패키지 소프트웨어 시장에서 그다지 큰역할을 담당하지 못하는 이유는 무엇일까 여러 가지 이유가 있겠지만, 미국과 같은 소프트웨어 선진국에 비해 체계적인 소프트웨어 개발 방법이 정착되지 않았기 때문이 아닐까싶다. 소프트웨어 개발 방법이라는 방대한 주제를 컬럼으로 다룬다는 것은 현실적으로 쉽지 않기 때문에, 필자는 총 5회에 걸쳐 현업에서 겪은 10년간의 삽질()을 통해 체화한 액기스() 노하우만을 추려 연재를 하려 한다.

지금까지 2회에 걸쳐 범위설정, 형상관리, 테스트, 리스크관리, 디자인 리뷰, 그리고 코드리뷰에 대한 10가지 주요 사례를 제 시하고 개발 프로세스를 제대로 갖추지 않았을 경우 어떤 문제점이 발생하는지 알아보았다.

독자들이 개발 프로세스를 갖춰야 할 필요성에 대해 공감하고 있기를 바라며, 글 솜씨 부족한 필자의 컬럼을 시간내어 읽어준 독자들에게 조금이나마 보답하고자 이번 컬럼은 실제 필자의 경험을 토대로 어떻게 하면 밤새지 않고도 고품질의 소프트웨어를 일정안에 개발할 수 있는지 필자의 경험을 독자들의 피부에 팍팍와닿게 구체적으로 적어보려고 한다.

준비 단계부터 릴리즈까지

다음 그림은 준비단계부터 릴리즈까지 일련의 과정에 대해 필자가 경험한 사이클을 단순화 하여 도식한 것이다. 기업용 소프 트웨어와 같이 규모가 비교적 큰 소프트웨어를 약 100여명의 개발인력이 릴리즈한다고 가정하였다.

1월 1일 준비단계(planning)를 시작하여 12월 24일에 릴리즈하는 약간은 빡센()일정이다. 이러한 전체 일정은 경험많은 팀 장급 관리자들이 모여서 결정하게 되는데, 이미 수차례에 걸쳐비슷한 방법으로 릴리즈를 해본 베테랑들이라, 문제없이 고품질 의 제품을 릴리즈할 수 있도록 대략적인 작업사항을 준비단계부터 릴리즈 단계까지 적절한 기간을 두고 나열한다.

<그림 1> 준비 단계부터 릴리즈까지의 과정

이 상태에서는 구체적으로 구현할 기능들이 모두 나열된 것은 아니지만, 이번 릴리즈에서 구현해야 할 가장 핵심적인 기능 정 도는 관리자간에 합의가 된 상태라고 할 수 있다.

위의 일정상 각각의 단계안에서 진행되는 일은 <표 1>과 같다.


<표 1> 준비단계부터 릴리즈까지 필요한 단계들

제일 중요한건 뭐 준비단계(planning)!

개발자라면 요구사항 분석, 설계, 구현, 테스트, 릴리즈로 이어지는 워터폴 모델에 기반한 전형적인 개발방식을 한번쯤은 들어 보았을 것이다. 이 개발방식대로 진행만 한다면 일정안에 개발을 끝낼 수 있을 것만 같다.

하지만 실제는 어떠한가 요구사항 분석이 다 되지 않은 채로 설계로 들어가거나, 구현을 하다가 미처 분석되지 않았던 요구사 항을 만나서 요구사항을 다시 취합하고 설계한 후, 구현을 진행하느라 구현 일정이 자꾸 밀리면서 테스트는 거의 되지 않은 코 드를 계속 구현만 하다가 늘어만 가는 버그를 견디지 못하고 프로젝트가 좌초되거나 릴리즈 일정이 기한 없이 연기되는 경우를 종종 봐왔을 것이다.

결론부터 이야기 하면 요구사항 분석단계에서는 무엇을 할 것인가를 빠짐없이 찾아내고 결정한 후, 정해진 인력으로 미리 정 한 릴리즈 날짜까지 고품질로 결과물을 낼 수 있는지 검증할 수있어야 한다. 만약 기한안에 완료가 불가능한 경우, 실제 완료할 수 있을 만큼으로 요구사항을 줄여나가는 작업이 반드시 선행되어야 한다.

요구사항을 줄이려면, 각각의 요구사항에 대한 우선순위가 결정되어야 하며, 일정 안에 모든 요구사항을 다 만족시키기 어렵 다면, 우선순위가 뒤로 밀리는 요구사항은 과감히 릴리즈에서 제외해야 주요 기능만으로 릴리즈를 완수할 수 있다.
쉽게 말해, 온갖 잡다한 기능까지 다 들어간 버그 많은 소프트웨어 보다는 꼭 필요한 기능만을 구현한 고품질의 소프트웨어가 고객들에게 사랑을 받는다.

그러면 꼭 필요한 기능이 무엇인지, 어떤 기능이 더 중요하고 어떤 기능이 덜 중요한지는 어떻게 파악할까 필자가 일했던 마 이크로소프트에서는 프로그램 매니저(program manager)라는 독특한 롤이 있는데, 이 롤은 사람은 전혀 관리하지 않는다. 단, 릴리즈 될 프로그램이 무엇을 구현해야 하는지를 정의한다. 그것을 어떻게 구현할지는 결정하지 않는다.
경쟁사 제품을 분석하거나, 지난번 릴리즈를 사용하고 있는 고객을 찾아가서 애로사항(pain point)은 없는지, 중요한 기능인데 빠진 기능은 없는지 파악하고 이번 릴리즈에서 추가할 기능들을 나열한 후, 각각의 기능에 대해 우선순위를 매긴다.
개발자와 테스트 개발자들은 프로그램 매니저가 제공한 기능명세 문서안의 각각의 기능에 대해 구현하고 테스트하는데 필요 한 시간을 예측한다.
여기에서‘예측’이라는 단어를 보고는 그걸 어떻게 예측하지 하고 의아해 하는 독자도 있을 것이다. 이 부분이 바로 키포 인트다. 각각의 기능에 대해 비교적 정확한 필요시간을 예측하는것이 쉽지 않아 보일 수도 있지만, 이 부분을 정확하게 예측하기 위해 준비단계(planning)에서 다양한 작업들을 수행하게 되는것이다.
우선 프로그램 매니저가 나열한 기능들이 각각의 개발자에게 할당되고, 개발자들은 우선순위가 높은 기능부터 사전조사 (investigation)를 실시한다. 이 사전조사 과정에서 개발자는 해당 기능을 구현하기 위해 필요한 기반 기술을 습득하거나, 프로 토타이핑을 실시해서 실제 구현에 들어갔을 때 봉착할만한 문제점들을 조기에 포착하고 완화하거나 해결할 수 있는 방법까지 모 색한다.

이렇게 기능 구현을 위해 필요한 기반 기술을 손에 익히고, 추가할 기능의 주요 부분을 미리 프로토 타입으로 구현해 보는 것 을 통해, 새로 추가할 기능에 대한 비교적 정확한 필요시간을 예측할 수 있다.
일부 독자들은 정확한 일정 산출을 위해서는 설계문서까지 나와야 하는 것이 아니냐고 반문할 수 있다. 사실 그렇다. 가장 정 확한 구현 일정은 설계 문서가 나와야 알 수 있는 것이 사실이지만, 준비단계에서 구현할 기능의 범위를 결정하는데 모든 기능에 대한 설계를 하게 된다면, 준비단계 만으로 프로젝트가 끝나버릴지도 모른다. 따라서 준비단계에서는 설계 문서는 나오지 않지 만, 개발자간에 브레인스토밍을 거쳐서 새로운 기능을 가장 간단하게 구현할 방법을 찾고, 이를 통해 비교적 정확한 일정을 산출 하게

이와 같은 방법으로 프로그램 매니저가 작성한 기능 명세 문서안에 나열된 각각의 기능에 대해 필요시간이 예측되면, 기능들을 구현할 순서를 결정하고 각각의 기능에 대해 여러 마일스톤(milestone)중 어떤 마일스톤에서 구현할 것인지 기능의 우선순 위와 기능간의 의존도(dependency)를 파악해 결정한다.
그 다음으로 하는 일은, 각각의 마일스톤안에 포함된 기능들에대한 예측시간을 전부 합산해 개발에 투입된 인력으로 나열된 모 든 기능들을 구현할 수 있는지 검증해야 한다.
만약 시간이 부족한 것으로 판명되면, 구현할 기능의 우선순위에 근거해서 우선순위에서 밀리는 기능은 다음 마일스톤으로 옮 기거나 이번 릴리즈에서 제외한다.

프로토타이핑은 왜, 그리고 어떻게 하나요

프로토타이핑은 추가할 기능 중에서도 줄기가 되는 주요 부분만을 짧은시간 안에 먼저 구현해보는 작업이다. 여기서 가장 중 요한 것은‘주요 부분만’구현한다는 것이다. 바꾸어 말하자면,부수적인 부분은 구현하지은시간 안에’구현한다는 것이다. 이를 위해서는 실제구현할 방법과 조금 다르더라도 전체 아키텍처만 유지할 수 있다 면 조금이라도 빨리 구현할 수 있는 방법을 찾아서 구현하고자하는 방법에 문제가 없는지 검증을 하게 된다.

대부분 독자들은 프로토타이핑을 실제구현 전에 한번 미리 구현해보고 설계나 아키텍처에 문제점은 없는지 조기에 검증을 해 보는 정도로 생각을 할 것 같다. 이보다 더 중요한 프로토타이핑의 효과가 있으니, 그것은 바로 해당 기능과 관련된 개발자의 기 술숙련도가 증가한다는 것이다. 개발자의 기술 숙련도가 증가하면, 그 개발자는 좀 더 정확한 일정을 산출해 낼 수 있다. 즉, 프 로토타이핑이 정확한 일정 산출에도 도움을 준다는 사실이다.

간혹 프로토타이핑이 오랫동안 진행되어 실제 구현단계에서 개발해야 할 사항들이 거의 대부분 들어가는 경우를 볼 수 있는 데, 최악의 프로토타이핑이 바로 이 경우이다. 짧게 끝내야 한다는 프로토타이핑의 특징을 잊지 말자. 프로토타이핑은 주로 준비 단계에서 진행되는데, 전체 일정에서 구현할 모든 기능을 프로토타이핑 할 수 없기 때문에, 일반적으로는 핵심 기능에 대해서만 프로토타이핑을 진행하게 된다. 만약 한 가지 핵심기능의 프로토타이핑에 너무 많은 시간이 투입되어 다른 핵심기능의 프로토타이핑을 해보지 못한 채로 마일스톤이 시작되면, 구현 도중에 예상치 못한 문제점들을 맞이하면서 일정이 연기될 가능성이 높아 지게 된다. 때문에 모든 핵심기능에 대해 준비단계에서 프로토타이핑을 다 마치려면 짧은 시간안에 이를 완료해야 한다.

설계 회의 & 브레인스토밍. 좀 더 효율적으로 할 수는 없나요

어떤 회사에서는 설계안을 찾기 위한 브레인스토밍이라고 하며 팀원들이 전부 모여서 장시간 회의를 하는 것을 볼 수 있는데, 필자가 개인적인 생각을 조금 이야기 하자면, 이는 최적의 설계안을 찾아나가는 가장 비효율적인 방법이 아닐까 한다.

설계라는 것은 결국은 특정한 구현 방법에 대해 모든 문제점을 도출하고, 각각에 대한 해결방안을 모색하는 방법을 통해 좀 더 짧은 시간에 간단하게 구현할 수 있는 설계안을 찾아가는 과정이라고 할 수 있다. 그런데 문제점을 파악하고 그 문제점에 대한 해 결 방안을 도출해 내는데 걸리는 시간이 사람마다 전부 다르기때문에 회의에 참여한 모든 사람에게 문제점이나 해결책을 이해 시키느라 이미 문제점을 이해한 사람도 자리를 지키고 앉아 있어야 하거나, 아니면 이해하지 못한 문제점을 그냥 지나치게 되어 이후 회의에 깊이 관여하지 못하는 사람이 생길 수 있고, 장시간회의로 인해 피곤해진 상태에서 아이디어는 나오지 않는 비효율 적인 악순환이 반복될 가능성이 높다. 구현방법을 찾기 위해 팀원 전체가 회의실에서 머리를 맞댈 필요는 없다. 필자는 구현하 고자 하는 기능과 관련된 개발자들을 찾아가며 1:1로 대화하고 문제점을 충분히 이해시킨 후, 해결 방안에 대해 그들의 의견을 들어보고 이를 모두 취합한 후 짧게 모여서 회의하는 방법을 사용했다. 똑같은 문제점을 반복해서 여러 사람에게 설명하는 추가 적인 비용이 들기는 하지만, 그래도 이야기를 하다 보면 문제점들이 차차 해결 되어 결국 가장 적절한 구현 방법이 수면 위로 떠 오르게 되는 것을 여러 차례 경험하였다.

마일스톤 - 설계, 구현, 테스트

하나의 마일스톤 안에서는 설계부터 구현, 테스트까지 실제 기능추가를 위한 개발을 진행하게 된다. 추가할 각각의 기능은 개 발자들이 추정한 소요시간과 함께 시스템에 등록되어 시간단위로 스케줄 체크를 할 수 있다.
하루 근무시간이 8시간이니까 반나절에 끝낼 일이라면 4시간으로 등록되고, 일주일에 끝낼 일이라면 40시간(8시간×5일)으 로 등록된다. 그리고 개발자는 실제 소요된 시간과 남은 시간을시스템에 기록하지만, 처음에 추정한 시간은 변경할 수 없다.
관리자는 소요시간과 남은 시간을 합한 시간이 최초 추정시간보다 긴 경우를 일정이 연기될 것으로 보이는 기능으로 간주하고 개발자에게 지속적인 푸시를 가하기 때문에, 개발자는 일정을 연기하지 않으려 최선을 다 한다. 레드마인이나 트랙과 같은 일정 관리 툴을 사용해본 독자라면 쉽게 이해할 수 있을 것이다.
각각의 기능에 대해 개발자는 구현을 마친 후 테스트를 거쳐SVN과 같은 버젼 컨트롤 시스템에 소스코드를 전송한다. 이 때, 코드의 품질을 높이기 위해 다양한 방법이 동원되는데, 유닛 테스트 코드를 작성하여 라인 테스트 커버리지를 측정하거나, 별도 의 테스트 인력이 붙어서 추가된 기능을 테스트하고 문제가 없다고 검증된 후에 SVN에 전송한다.

이렇게 하나의 마일스톤에서 추가할 기능을 온전히 구현하고테스트했을 때, 코드 컴플릿(code complete)를 달성했다 라고 이 야기한다. 버그가 하나도 없다면 좋겠지만, 사람이 하는 일이다보니 사소한 버그 한두개 쯤은 발견될 수 있다. 이 경우 대부분의 버그는 즉시 잡힌다. 하지만, 설계상의 오류가 발견된다거나 해서 기능을 다시 구현하는 일도 발생하는데, 이 경우에는 코드 컴 플릿을 달성했다고 말할 수 없다.
그러면 코드 컴플릿의 달성 여부가 왜 중요한지 궁금할 것이다. 구현일정이 끝난 후 코드 수정을 허용하지 않는 코드 프리즈 시점이 오는데, 코드 컴플릿이 달성되지 않았다면 코드 프리즈를할 수 없게 되어 테스트 일정이 연기되는 문제가 발생한다. 그래 서 개발자들은 이번 마일스톤에서 추가할 기능에 대해 코드 컴플릿을 미리 정한 일정 안에 달성하기 위해 최선의 노력을 다한다.
나 때문에 팀의 코드 프리즈 일정이 연기되어 테스트 일정이 연기되지 않으려면 일정안에 코드 컴플릿을 달성하는 수 밖에 없다. 이렇게 코드 컴플릿이 달성되면, 테스트 개발자들은 구현된 모든 기능에 대해 수동및 자동 테스트를 수행하게 된다. 테스트 개발 자는 일반 개발자보다 테스트에 대한 전문지식과 경험을 보유한개발자로, 더욱 효율적으로 테스트를 계획하고 진행할 수 있다.

테스트 개발자는 개발자의 설계문서를 보고 테스트 계획서(test plan)에 테스트 시나리오와 테스트 케이스를 기술하는데,개발자가 이를 보고 누락된 테스트는 없는지 검증한 후, 테스트개발자가 테스트 계획서에 기술한 대로 테스트를 진행한다. 이렇게 팀에서 구현한 모든 기능에 대한 테스트가 완료되면 버젼 컨트롤 시스템상의 팀 브랜치(branch)에서 메인 브렌치(mainbranch)로 소스코드를 병합(merge)하는 단계를 거쳐서, 그 팀이 마일스톤안에서 구현한 기능을 다른 팀에서 가져와서 사용할수 있게 된다.

팀간 스케줄 맞추기

본 컬럼의 시작 부분에 기업용 소프트웨어를 100여명의 개발인력이 릴리즈하는 것을 가정한다고 이야기하였다. 그렇다면 100여명이 속한 여러 개의 작은 팀에서는 어떤 방식으로 개발을 진행해서 최종 릴리즈 날짜를 함께 맞추는 것일까 앞서 도식한 바와 같이 준비단계 이전에 이번 릴리즈에 대한 전체 일정이 나온다. 각 팀별로 프로그램 매니저가 최소 1명씩 존재해서 팀이 맡은 모듈에 추가할 기능들을 나열하고 우선순위를 할당한 후,전체 일정 안에서 이를 다 구현할 수 있는지 개발자들과 검증하 는 과정을 거친다고 앞서 언급한 바 있다.

이렇게 각 팀에서 일하는 프로그램 매니저들이 서로 모여서 자신의 팀에서 이번 릴리즈에 추가하려고 하는 기능을 소개하고 이 기능들이 다 추가되었을 때 이번 릴리즈가 시장에서 어떤 반응을 얻을지에 대해 고민도 해보고, 서로 다른 팀이 같은 기능을 구현 하지는 않는지, 중요한 기능인데 어떤 팀도 구현하지 않는 빠진기능은 없는지 검증하는 절차를 거친다. 이 부분은 필자가 직접 경험한 부분이 아니고, 단지 관찰한 부분이라 더 자세하게 적지못함을 독자들에게 미안하게 생각한다. 아마도 프로그램 매니저 들 뿐만 아니라 아키텍트와 같이 제품 전체의 기술을 총괄하는인력도 이 단계에서 많은 조언을 하지 않을까 하고 예상해 볼 뿐 이다.

참고로 마이크로소프트에서 일정 지연은 거의 없다. 여러가지이유가 있는데, 준비단계에서 철저한 사전준비를 하기정이 지연되는 모습을 보여주기 싫어하는 팀간의 보이지 않는 경쟁때문이기도 하다. ‘우 리팀이 구현하는 기능에 치명적인 버그가 발견되어 전체 릴리즈일정이 연기되지는 않을까’하는 생각으로 각 팀의 매니저부터 팀원들까지 정말 세세한 부분에 대해 신경을 많이 쓴다. 그래서 일정은 거의 연기되지 않는다.

우리의 릴리즈 친구들

앞서 도식한 스케줄 표(<표 1> 참조)에서는 네 번의 릴리즈를하게 되는데, 베타릴리즈, 베타리프레시, 후보릴리즈, 최종릴리즈가 바로 그것이다.
베타릴리즈는 여러 차례의 마일스톤을 통해 설계, 구현, 검증한 기능들을 고객에게 1차 전달해 제품에 대한 시장반응을 미리 살피고, 미처 발견하지 못한 문제점을 포착할 수 있는 기회를 제공한다. 베타릴리즈 또한 제품을 고객에게 배포하는 것이기 때문 에, 제품을 사용할 수 없을 정도의 치명적인 결함이 있는 상태로는 릴리즈할 수 없다. 따라서 다른 릴리즈와 마찬가지로 고품질 의 제품을 정해진 릴리즈 날짜에 내놓기 위해 체계적인 방법들을통해 성공적인 릴리즈를 준비한다.

베타릴리즈를 하고 나면, 예상외의 상황에서 문제점들이 발견되는 것에 대해 놀라게 될 것이다. 이 때 발견되는 문제점들은 주 로 개발자가 예상하지 못한 방식으로 제품을 사용하는 상황에서발생한다.
예를 들어 개발팀은 영문 윈도우에서 테스트를 수행했는데, 고객은 독일어 윈도우에서 제품을 사용하다가 제품이 독일어 문자 열을 제대로 처리하지 못하는 문제가 발견되기도 한다.
혹은, 고객이 편리하게 사용할 것이라고 생각하고 구현한 기능에 대해 의외로 고객들이 불편해 하며 개선을 요구하기도 한다. 프로그램 매니저는 이러한 고객의 목소리에 귀를 기울여 다양한요구사항을 취합한 후, 이후의 릴리즈에서 개선해야 할 사항들을 우선순위를 할당해 정리하고, 개발자들은 베타릴리즈 이후 짧은구현기간동안 꼭 필요한 주요 개선사항을 제품에 반영하는 작업 을 수행한다.

이때, 제품의 아키텍처를 흔들거나 대량의 코드수정이 필요한기능개선은 하지 않는다. 대신 적은 양의 코드수정으로 제품을 개선할 수 있거나, 간단하게 구현할 수 있는 기능이지만 고객이더욱 편리하게 제품을 사용할 수 있도록 돕는 작은 기능들을 추 가한다.

베타릴리즈 이후에 제품을 개선하기 위한 마지막 마일스톤이라고 보아도 무방하다. 이 마일스톤 이후에는 어떠한 기능도 추 가되지 않는다. 그리고는 베타릴리즈를 했을 때와 마찬가지 과정을 거쳐 베타리프레시(beta refresh, 내부릴리즈)를 릴리즈 하는 데, 회사 안에서 운영중인 도그푸드 시스템에도 적용하고, 몇몇전략적 동반자 관계를 형상한 고객사에 전달하기도 한다. 이를 통해 베타릴리즈 이후 추가 및 개선한 기능으로 인해 발생하게된 결함들을 조기에 발견한다.

이제 남은 것은 후보릴리즈와 최종릴리즈인데, 최종릴리즈의1개월정도 전에 후보릴리즈를 한다. 후보릴리즈 이후 최종릴리 즈까지는 시간이 짧기 때문에, 대부분의 버그는 후보릴리즈이전에 발견되어야 한다. 실제로 후보릴리즈는 고객이 실제로 사용해 도 아무런 문제가 없을 정도로 높은 완성도를 보여주어야 한다.
그래서 후보릴리즈 전에는 도그푸드및 롱홀테스트에 더 집중해서 최대한 많은 결함을 찾아내고, 발견된 결함를 해결하기 위 해 팀원 개개인이 가장 힘들어 하는 시기이기도 하다.
이렇게 높은 완성도의 릴리즈후보를 내놓게 되면, 이후 최종릴리즈까지는 개발자들이 할 일이 그다지 없게 되는 기이한 현상 이 발생한다. 이 시기에도 간혹 버그가 발견되는데, 대부분 짧은시간 안에 최소한의 코드수정으로 잡을 수 있는 간단한 버그들이 대부분이다.

이 기간동안 개발자들은 하루에 정해진 시간만큼을 도그푸드를 모니터링하는데 사용하고, 또 다음 릴리즈를 위한 사전조사작 업을 실시하기도 한다. 그리고 최종 릴리즈를 위한 버전 컨트롤시스템상의 브랜치를 생성하는 방법으로, 개발자들이 작업하는 내용을 최종 릴리즈에 반영하지 않도록 브랜치를 구성하고, 다음번 릴리즈에 앞서 수행해야 할 작업들을 하기도 한다.
예를 들면, 이번 릴리즈에서 뒤늦게 발견되어 미처 잡을 수 없었던 버그를 잡는다던가, 미리 발견되긴 했지만 수정할 코드의 양이 워낙 방대해서 해결할 수 없었던 문제점을 해결한다.
디버깅이나 테스트팅을 효율적으로 할 수 있도록 리팩토링을 하는 작업도 이 단계에서 진행한다. 이러한 단계를 마이크로소프 트에서는 MQ(milestone quality)라고 부른다.

고통을 즐겨라

우리가 제품을 릴리즈하고 고객에게 전달하는 것을 영어로'delivery한다'라고 한다. 그런데 공교롭게도, 엄마가 아기를 낳을때의 출산도 delivery라는 단어를 사용한다. 그렇다. 고객에게제품을 전달하기까지는 마치 엄마가 아기를 낳을 때의 고통스러운 과정을 거쳐야 고객이 만족할 수 있는 사랑스러운 제품이 탄생하게 된다.

고객에게 사랑받는 고품질의 제품을 전달하기 위해서는 릴리즈 전에 결함을 최대한 일찍 발견할 수 있는 다양한 방법을 사용하고, 체계적인 결함관리를 통해 미리 정한 베타릴리즈 날짜에제품을 완성할 수 있도록 해야한다.

이제부터 설명할 릴리즈에 앞서 거쳐야 할 과정들은 베타/베타리프레시/후보/최종릴리즈에 모두 적용되는 사항이다.
우선 릴리즈 전에 결함을 해결하기 위해서는 결함을 조기에 발견해야 하는데, 그 방법으로는 세 가지가 있다.

첫째, 각 마일스톤에서 개발자들이 코드 컴플릿을 달성하면 팀에 속한 구성원 모두가 참여하는 버그 발견하기 콘테스트(bugbash,http://en.wikipedia.org/wiki/Bug_bash)를 실시한다.팀장, 프로그램 매니저, 개발자, 테스트 개발자까지 모두가 참여한다.

콘테스트는 다음과 같이 진행된다. 제품을 한 곳에 설치해 두고 각자 제품을 실제로 사용하면서 아주 사소한 문제부터 프로세스가 죽는 등의 치명적인 문제까지 다양한 문제점들을 찾아낸다.이렇게 발견된 결함들을 각자가 요약하여 팀 구성원 모두에게 이메일로 보낸다. 그리고는 발견된 결함들의 심각한 정도(severity)를 분류하고, 버그 데이터베이스에 이를 등록한다.
심각한 버그를 가장 많이 발견한 팀원들에게 즐거움을 선사할수 있는 작은 선물을 제공한다. 콘테스트 시작 전에 선물에 대해미리 공지해서 버그를 찾아내고 싶은 강력한 동기를 유발하도록하는 것은 당연한 것이다.

둘째, 실제 제품의 고객이 되어 회사 내에서 직접 사용해보는 도그푸드(dog food)를 시행한다
제품을 테스트하기 위해 사용해 보는 것이 아니고, 제품을 회사 내에서 실제로 사용한다. 예를 들어 웹서버를 개발하는 회사라면, 회사의 홈페이지에 사용되는 웹서버를 새로 릴리즈할 버전으로 교체하고 릴리즈하는 날짜까지 문제가 없는지 면밀히 모니터링한다.
웹서버의 경우, 웹서버 프로세스가 만들어 내는 다양한 로그를매일 확인하고, 회사의 홈페이지 링크를 하나하나 열어가며 별다른 문제가 없는지 검증한다. 제품을 개발한 개발진은 릴리즈 날짜까지 자신이 개발한 기능을 중심으로 직접 고객의 입장에서 제품을 사용해본다.

셋째, 제품에 대한 스트레스트 테스트를 장시간 수행하여 비정상적인 상황에서도 제품이 문제없이 동작한다는 것을 검증한다.예를 들어 데이터베이스 관리 시스템을 릴리즈하는 경우, 다양한쿼리를 실행하는 다수의 트랜잭션으로 대용량의 데이터를 변경하는 작업을 2~3주간 수행하여 시스템이 장시간 가동되어도 문제없이 동작한다는 것을 검증한다.
이 과정에서 메모리 누수나 프로세스/스레드간의 동시성 제어상의 문제와 같은 치명적인 결함들이 종종 발견된다. 제품이 고객에게 한번 전달되면, 고객이 제품에 얼마만큼의 부하를 얼마나 오랫동안 줄 것인지 알 수 없기 때문에, 최대한 많은 부하로 최대한 긴 시간동안 테스트를 해보는 것이 중요하다.
이러한 테스트를 롱홀(long-haul)테스트라고 하며, 릴리즈 전에 반드시 수행해야한다. 특히 디스크의 디스크의 모든 공간을 다 사용했다거나, 디스크가 메인보드로부터 갑자기 분리된다거나, 갑자기 랜선이 뽑힌다던가, OS가 패닉으로 죽는다던가, 전원이 나가는 상황과 같은 다양한 비정상적인 상황에 대해서도 테스트한다.

이렇게 결함을 발견한 후에는, 두 단계를 거쳐 체계적으로 결함을 관리한다. 첫째, 발견된 모든 버그를 분류하고, 이번 릴리즈에서 잡을지 결정한다. 버그가 발견되었으면 이번 릴리즈에서 잡는게 당연한 것이 아닌가 하고 생각할 수 있다. 하지만 릴리즈까지 남은 일정을 고려하여 버그를 잡는 것이 오히려 다른 버그를 양산할 수도 있겠다고 판단될 경우에는, 차라리 버그를 잡지 않고 피해갈 수 있는 방법을 문서화한다.

넷째, 이번 릴리즈에 앞서 버그를 다 잡을 날짜(ZBB day,zero bug bounce)를 미리 결정하고 각 팀원이 버그를 일정안에다 잡을 수 있도록 버그 갯수 그래프(bug glide path)를 그린 후,팀에 할당된 버그의 갯수가 ZBB날짜가 나가옴에 따라 0으로 수렴하는지 주기적으로 체크한다. 예를 들어, 4명의 개발자로 구성 된 팀에 80개의 버그가 할당되었고, ZBB날짜까지 4주가 남았다고 가정하면, 이 팀은 1주에 20개의 버그를 잡아야 하고, 개발자1명당 1주에 5개의 버그를 잡아야 한다는 계산이 나온다.

이렇게 주단위로 버그 갯수가 줄어드는 모양을 그린 그래프를통해 매주 버그의 갯수를 체크하여 ZBB날짜에 마쳐서 버그를 다 잡을 수 있는지 주기적으로 확인한다.
아울러 노련한 팀장은 버그 갯수 그래프를 혼자 그리지 않는다. 팀원들에게 버그를 할당하고, 버그를 잡는데 걸리는 예상시간을 요구한다. 문제의 원인이나 해결책이 밝혀지지 않는 버그에대해서는 개발자로 하여금 사전조사(investigation)작업을 수행하도록 하고 예상 시간을 산출하도록 해 실현 가능한 버그 수정계획을 수립한다. 이 부분에 대한 자세한 절차는 다음 컬럼에서다루도록 하겠다.

버그를 다 잡은 이후에도 다른 버그가 발견 될 수 있기 때문에,ZBB날짜이후에도 일정기간 테스트를 수행하여 문제가 없음을 검증하고 나서야 릴리즈를 할 수 있다.
이번 컬럼은 준비단계부터 릴리즈까지 어떤 방식으로 개발을 진행해야 하는지에 대해 알아보았다. 체계적인 개발방법을 적용하면 밤을 새지 않고도 정해진 인력으로 정해진 일정 안에 고품질의 소프트웨어를 릴리즈 할 수 있다는 것을 독자들도 공감했기를 바란다. 다음 컬럼에서는 버그를 체계적으로 관리하는 방법에 대해 구체적으로 다루어 보겠다.

이번 컬럼에서 지면 관계상 실제 예를 들지 못하는 것이 많이 아쉬울 따름이다. 대신, 이번 컬럼에 연재된 내용을 현업에 적용하고싶은데 컬럼의 내용이 뜬구름 잡는 얘기 같아서 도무지 감이 와 닿지 않는 독자가 있다면, 필자에게 문의메일을 주면 좋겠다.