Short Release와 회귀 테스트, Itertive and iteration 방법론의 사례

요즘 모회사의 차세대 시스템의 오픈을 막바지에 두고, 성능 향상 컨설팅에 나와 있습니다.
주로 하는 작업이 Code Inspection을 통하여 구조 개선 및 성능 개선을 하는 작업입니다.

그런데, 코드를 보면서 이해가 안되는 아키텍쳐가 종종 있습니다. 이런 의도가 아닐텐데 라던지.. 아키텍쳐 구성이 잘못되었다던지. 그런데 이미 구현이 끝나가는 단계에서 이런 아키텍쳐를 변경하기는 거의 불가능합니다. 알면서도 당하는 케이스라고나 할까요? 이미 여러 코드들이 동일 패턴으로 구현이 되어 있기 때문에, 공통부라면 어떻게 변경을 시도해보겠지만, 아키텍쳐적인 문제나, 통신 전문 같은 경우는 변경이 불가능합니다.
결국 울며 겨자 먹기로 CPU를 늘리거나, 다른 부분의 코드를 튜닝해서 목표 성능치를 내야 겠지요.

그런데, 만약에 Short Release를 통해서 매번 회귀 테스트를 진행했더라면 어땠을까 하는 생각이 문득 집에 도착한후에 들더군요. 그러한 문제는 아주 조기에 발견이 되었을 것이고, 초반에 아키텍쳐 수정이 가해졌을 것이며, 이렇게 비용을 들여서 Code Inspection을 하거나 추가 비용을 들여서 하드웨어를 증설할 일도 없겠지요...

그리고 여러개의 시스템이 연결된 시스템이기 때문에, 이제서야 통합 작업을 수행합니다. 마찬가지로 Interative and ieration 전략을 사용했더라면 초반부터 통합을 해왔기 때문에 통합때문에 드는 작업이 거의 없었겠지요.

특히 통합이 일정대로 원할하지 못한 경우, 이번에 튜닝을 위해서 거의 5명의 벤더 엔지니어를 불러다 놓고 하루종일 거래 개통도 되지 않아 엔지니어들이 대기하다가 돌아갔습니다. 보통 벤더 엔지니어의 하루 몸값은 Charging을 하는 경우에는 100~120만원선이 됩니다. 5명이니 대략 아무것도 안하고 600만원을 날린셈이 되는 것입니다.

회귀 테스트나 Iteration 방법론, Short Release 를 실제 프로젝트에서는 시간이 없다. 예산이 없다는 이유로 잘 사용하지 않습니다. 기능 구현에 쫓겨서 일단 구현만 해놓고 보자는 건데, 그 안에 있는 Defect 에 대한 검증이 이루어지지 않은 폭탄 코드를 양산해 내는 거지요.

결국은 위의 사례와 같이 오픈 연기, 하드웨어 추가 구매, 튜닝 컨설팅등의 추가 비용이 발생하고, 끊임없는 야근과 누더기 코드로 이어집니다.

반대로 지난번 프로젝트를 진행했던 S사의 경우 제가 진행했던 파트는 2주 주기의 Short Release를 사용했고, Short Release 마다 어떤 형태로든 비기능 테스트를 통해서 끊임없이 아키텍쳐를 검증했기 때문에, 지금 프로젝트에서는 통합에 대한 이슈나 아키텍쳐를 통째로 흔드는 일이 없습니다.

항상 자연계 열역학 제 1의 법칙을 이야기 하지만, "에너지 불변의 법칙"은 사람이 일할때도 통하나 봅니다. 개발과정에 생략한 테스트와 검증은 프로젝트 말에 그만한 부담으로 다시 돌아옵니다. 아니 에너지 불변의 법칙이 아니라, Defect 증폭의 법칙이라고 해야할까요?