거의 다 만들었어요.

"거의 다 만들어서 2주후에 개발이 끝나요"

이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다.

개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다.

하지만 이런 대화는 여러 오해를 양산한다.

영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아 있다는 것도 알기도 한다. 하지만 정확하게 언제 고객이 쓸 수 있는 제품이 나오는지는 알 수가 없다.

그래서 우리는 좀더 전문적으로 제대로된 용어를 사용해서 커뮤니케이션을 할 필요가 있다.

우선 개발 단계별로 정확한 용어를 사용하는 것이 필요하다.

"개발"이라는 말은 너무나 모호하다. 사실 스펙을 쓰는 일부터 유지보수 까지 모두 개발이다.

그래서 분석/설계/구현/테스트 등 단계별로 세분화된 단어를 쓰는 것이 좋다.

따라서 "개발이 끝나요"보다는 "구현이 끝나요"가 좋다.

그 다음에는 개발팀에서 만들어내는 버전이 어느 정도 수준인지 표현할 필요가 있다. 내부 테스트를 진행할 수 있는 수준인지 필드테스트를 할 수 있는 수준인지 알려줘야 한다.

일반적으로 이런 수준을 표시하는 용어는 많이들 들어봤겠지만, 알파/베타/RC 등이 있다.

알파버전이란 모든 기능의 구현이 완료되었고 버그는 많지만 Show stopper가 없는 수준을 말한다. 주변에서 "개발이 다 됐어요"라고 말할 때도 자세히 살펴보면 알파 수준도 안되는 경우 많다. 기능이 99% 완료 되었으면 알파가 아닌 것이다. 예를 들어 설치 프로그램은 아직 개발을 안했다던지 간단한 기능의 일부가 미 구현상태면 알파가 아닌 것이다. 

따라서, 미국이나 인도나 어디에서도 알파버전이라고 하면 이 수준으로 이해를 하면 된다. 

그리고 알파버전 테스트에서 발견된 버그를 대폭 수정해서 버그를 많이 줄인 버전을 베타버전이라고 한다. 베타버전은 내부테스트를 하기도 하고 고객을 대상으로 외부 테스트를 하기도 한다. 베타버전은 버그는 있지만 꽤 쓸만한 버전이다.

RC버전은 Release Candidate의 약자로 테스트를 해보고 출시를 결정할 후보 버전이다. 따라서 대부분의 경우 아주 안정적이다. 출시가 결정되면 바로 고객이 사용하는 버전이다. 물론 버그가 없는 것은 아니지만 충분히 안정적이다.

따라서 알파/베타/RC등의 용어를 적절하게 사용해서 개발팀에서 만들어낸 버전이 정확하게 어느 정도 수준인지 전달을 해야 한다.

"2주후에 개발이 끝나요"보다는 "2주후에 알파버전 구현이 끝나요"가 좋다.

좀더 자세히 말하면 "2주후 금요일 오후3시 정각에 알파버전 소스코드 프리즈가 있습니다."라고 하면 좀더 정확한 의미가 전달된다.

개발자들은 3시까지 모든 소스코드를 Commit해야 하고,

빌드팀은 3시가되면 소스코드를 내려받아서 빌드를 하고

테스트팀은 3시쯤 되면 알파테스트를 시작할 준비를 하고 기다리고 있을 것이다.

관리자나 경영자는 당연히 테스트 일정을 알고 있고 언제 출시 예정인지 알고 있다.

이슈관리시스템을 보고 있으면 거의 실시간으로 발견되는 버그와 고쳐지는 버그의 현황을 볼 수 있다. 

하지만 아직도 대부분의 개발 현장에서는 이런식으로 커뮤니케이션이 이루어지지 않고 있는 것이 현실이다. 

알파/베타 등의 용어를 들어봤거나 사용하고 있어도 그 의미를 정확하게 사용하지 않고 있는 경우가 많고 개발자와 영어/관리자/경영자가 그 의미를 똑같이 공유하고 있는 않다. 서로 다르게 생각하고 있으면 커뮤니케이션에 문제가 자주 생긴다.

세계적으로 표준으로 사용하는 용어들이니 표준에 맞게 사용하고 모든 직원이 똑같이 공유를 해야 한다.

그래야 좀더 합리적인 일정으로 개발이 진행된다. 

고쳤으니 테스트 해주세요.

여기 두가지 테스트 방법이 있다. 우리 회사는 어떤 방법을 사용하고 있나 생각해보자.

첫째, 테스트 도중에 버그를 고쳐서 좀더 안정된 버전을 테스트팀에 계속 전달하는 방식이다.

테스트 한사이클을 도는데 2주일이 걸린다고 생각해보자. 테스트 기간내내 테스트 팀은 버그를 지속적으로 발견하여 보고를 할 것이다. 개발팀은 동시에 버그를 수정한다. 그리고 다음날 개발팀은 테스트팀이 보고한 버그를 많이 수정한 새버전을 테스트팀에 전달한다. 

테스트 팀은 새버전을 가지고 어제 테스트한 시점의 다음 단계부터 또 테스트를 진행한다. 이렇게 테스트 기간 내내 여러번 새버전을 받는다.

두번째 방법은 다음과 같다. 테스트가 2주가 걸리면 2주 동안 테스트 팀은 새버전을 절대로 받지 않고 한 버전을 가지고 테스트를 완전히 종료한다. 개발팀은 버그를 계속 고치지만 새 버전을 테스트 팀에 전달하지 않는다.

어느 방법이 더 효율적으로 보이는가? 많은 회사들이 첫번째 방법을 사용하고 있다. 믿기 어렵겠지만 사실이다. 첫번째 방법은 큰 문제가 있다. 테스트 기간 도중에 테스트 팀이 새로운 버전을 받으면 이전에 테스트 한 내용이 무효가 된다. 여기서는 그걸 무시하고 계속 테스트를 했기 때문에 테스트가 끝나도 끝난 것이 아니다.

그럼에도 첫번째 방법을 사용하는 이유는 있다. 도저히 테스트 할 수 없을 만큼 불안정한 제품을 테스트 해달라고 전달한 경우이다. 그래서 테스트 팀과 적당히 테스트를 하면서 차츰 안정화를 시켜가는 것이다. 이런 품질의 제품은 테스트를 할 필요가 없다. 이 경우는 테스트 팀을 개발팀의 딱까리로 생각하는 것이다. 

원래 테스트를 진행할 수 없을 정도의 제품을 테스트팀이 받으면 테스트를 중단하고 개발팀으로 다시 돌려보내야 한다.

이렇게 비효율적인 테스트가 우리 주변에서 흔히 벌어지는 이유의 원인 따지고 들어가면 앞단계인 분석과 설계가 엉망이거나 없기 때문인 경우가 많다. 

제품의 품질을 유지하기 위해서는 분석/설계도 중요하고 전문적인 테스트를 해야 한다. 대충 개발하고 테스트팀이 개발팀을 도와주는 형태로는 평생 주먹구구식 개발에서 못벗어나고 비용과 시간도 많이 들뿐만 아니라 개발팀은 잦은 야근에서 벗어나기도 어렵다.

앞으로 테스트에 관한 얘기를 좀더 쉽게 풀어서 써보도록 하겠다.

인해전술이 오히려 프로젝트를 망친다.

일정이 촉박하다고 프로젝트를 빨리 끝내고 싶은 마음에 프로젝트 초기부터 대거 인력을 투입하면 오히려 프로젝트를 망칠 가능성이 더 높아진다.

프로젝트 초기에 분석/설계 단계에는 그렇게 많은 인력이 필요하지 않다.

많은 인력을 분석도 안된 프로젝트에 투입을 하면 놀 수 없는 개발자들이 인터페이스도 정의가 안된 모듈이나 라이브러리를 만들기 시작한다. 이것들 중 대부분은 나중에 다시 만들어야 하고, 이것들을 버리기 아까워서 어떻게든 활용하려고 버티다보면 소프트웨어의 아키텍처가 점점 이상하게 된다.

많은 인력이 투입되는 단계는 구현단계이며 핵심 구현 인력들이 분석/설계 단계에 리뷰어로 참석할 수는 있다.  일정이 촉박하면 분석/설계를 최대한 빨리 끝내고 할일의 범위와 아키텍처를 명확히 한 후에 인력을 투입해야 한다.

필요한 라이브러리를 개발하지 말고 상용라이브러리를 구매하는 것도 일정을 단축하는데 도움이 된다.

가장 안좋은 방법이 프로젝트 초기에 시장통처럼 개발자를 잔뜩 투입하는 것이다. 소프트웨어 개발을 잘 모르는 경영자들이 이런 실수를 종종 하곤 한다.

우리 주변에서 1년짜리 프로젝트인데 10명의 개발자가 투입되면 10명이 12달동안 계속 같이 일하는 경우를 흔히 볼 수 있다. 이렇게 일정 투입 계획이나 현황만 보아도 개발이 얼마나 주먹구구식으로 진행되고 있는지 알 수 있다. 10명의 개발자가 투입되는 프로젝트도 초기 2,3개월 또는 3,4개월동안은 분석/설계를 담당하는 1,2명만 필요하다. 이 프로젝트에서 분석/설계를 담당한 엔지니어는 많은 개발자가 투입되는 구현기간에 같이 구현에 참여할 수도 있고 다른 프로젝트에서 또다시 분석이나 설계를 담당할 수 있다.

이렇게 인력이 효율적으로 순환이 되면 훨씬 적은 인력과 비용으로 많은 프로젝트를 효과적으로 진행할 수 있게 된다.

인해전술로 많은 인력을 투입하는 방법은 해당 프로젝트를 망치는 방법일 뿐만아니라 회사 전체적으로 효율적인 인력운영을 할 수 없게 만든다. 

1:10:100 rule

소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 "1:10:100 rule"이다.

성숙한 개발문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 대부분의 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다.

소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다.

그 1:10:100 rule을 설명한 그래프가 아래에 있다.

요구사항이 스펙을 작성하면서 바뀌면 "1"이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 "368"배의 비용이 들어간다.

요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 시간이 흐를수록 비용은 기하급수로 증가를 한다.

따라서 기획이 제대로 되어야 하고 분석 설계가 적절하게 잘되어야 하며 한창 개발중에 기획이 바뀌거나 요구사항이 바뀌면 그 수정 비용은 엄청나다는 것을 알야 한다.

말은 쉽지만 이를 진정으로 꺠닫고 실천하는 회사나 개발자를 만나는 것은 쉬운 일이 아니다. 

사실 개발자들은 기획에서 정확한 요구사항을 주지 않는 다거나 나중에 요구사항을 바꾼다고 불평이 많다. 하지만 많은 경우 불평은 하지만 그것을 현실로 받아들이고 스스로 이를 개선하려는 노력은 별로 하지 않는다. 오히려 상황이 그러니 분석, 설계를 제대로 하지 않고 대충 개발하다가 나중에 바꿔달라고 하면 또 대충 받아들여서 개발하고 이런 악순환을 반복하곤 한다.

이런 것을 극복하기 위해서 여러 방법론이 나오기도 하고 최근에는 Agile이 각광을 받고 있지만, 이런 방법론이나 기법으로는 이를 해결할 수는 없다. 정공법외에는 방법이 없다. 기획을 제대로 하고 분석 설계를 효율적이고 적절하게 하는 것이다. 또한 그 과정에서 모든 관련자가 책임을 지고 검토를 해서 문제가 없게 해야 하면 나중에 딴소리를 하거나 바꿔달라고 하면 안된다. 정말 중요한 변경 요청이 아니면 다음 버전으로 미루는 것이 좋은 전략이다.

전 임직원이 1:10:100 rule을 진정으로 깨닫고 있다면 글로벌 소프트웨어 회사가 될 수 있는 잠재력이 충분히 있다고 할 수 있다.