2009년 2월 6일 금요일

Waterfall과 Agile

주변에서 Waterfall이 좋다 Agile이 좋다 등의 논쟁을 가끔 보게 됩니다.
하지만 Waterfall을 비교 대상으로 삼기에는 적당하지 못한 것 같습니다.
즉, 너무 극과 극의 비교입니다.

이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다. 하지만 Waterfall 방식은 소프트웨어 개발의 기본 원리를 이해하는데 가장 중요한 모델이고 다른 모든 개발 모델들은 Waterfall에서 파생해 나온 것들이기 때문에 Waterfall 방식을 이해하는 것은 소프트웨어 개발 기본 원리를 이해하는 것처럼 중요합니다.




순수한 Waterfall 모델은 다음 단계로 진행하기 위해 전 단계가 완벽하게 끝나야 하고 모든 결과가 문서로 작성되어야 합니다. 폭포를 거슬러 올라가는 것이 원칙적으로 불가능하므로 Waterfall 모델에서는 이전 단계로 거슬러 가는 것이 불가능하거나 비용이 아주 많이 들게 됩니다.

현실에서는 이를 제대로 적용하기가 어려운 이유는 대부분의 소프트웨어 프로젝트는 요구사항을 초기에 완벽하게 파악하여 고정하는 것이 불가능하기 때문입니다. 더 많은 시간을 들여서 요구사항을 완벽하게 해도 시간이 흐르면서 주위 환경이 바뀌고 경쟁자들이 새로운 제품을 내놓는 등의 이슈로 인해서 이미 만들어 놓은 요구사항은 쓸모 없어 집니다. 그리고 너무 많은 문서를 요구하기 때문에 문서 작성과 관리에 너무 많은 시간을 쏟아 부어야 합니다. 그리고 프로젝트가 끝날 때까지 진행과정을 거의 볼 수가 없어서 사용자의 요구사항이 만족스러운지를 프로젝트가 끝날 때까지는 알 수가 없습니다. 이 또한 큰 리스크입니다.

만약에 Waterfall 모델을 따라서 개발하고 있다고 말할 수 있는 회사가 있다면 제대로 적용하고 있지 않거나 화성탐사선을 만드는 회사일 것입니다.

모든 종류의 프로젝트에 딱 적합한 방법이 있는 것은 아니니까 어느 한 라이프사이클 모델을 엄격하게 따를 필요는 없습니다. 원리만 알고 있고 경험이 있다면 응용이 가능하니까요. 

달콤한 유혹에 중독되어 있는 고객들 (SW 저가수주)

5throck님의 "프로젝트 저가수주의 폐해"라는 글을 읽고 의견을 적어봅니다.

그리고 "이 문제를 해결할 좋은 방법은 정말 존재하지 않는 것일까요? "라는 질문에 대한 나름 답변을 해볼까 합니다.

우리나라 소프트웨어 산업구조는 정말 기형적이라고 하지 않을 수 없습니다. 대형 SI업체가 시장을 지배하고 있고, 성공한 팩키지, 솔루션 회사는 거의 찾아보기 힘들고 과거에 성공했던 회사들도 그리 오래가지 못하고 쓰러져왔습니다. 그 이유야 여러가지가 있겠지만, 그 많은 이유 중에서 대형 SI업체가 지배하고 있는 시장구조에 대해서 의견을 적어보고자 합니다.

외국에서 유래를 찾아보기 힘든 대형 SI업체 구조는 우리나라 고객들에 입맛에는 맞는 것 같습니다. 대충의 요구사항만 가지고 있으면 대형SI업체에서 모든 것을 다 알아서 해줍니다. 심지어는 고객의 제시해야할 요구사항도 업체에서 달 알아서 해주기 때문에 고객은 신경쓸 일이 적은 대형 SI업체를 선호하게 됩니다. 그러다보니 불확실한 요구사항으로 프로젝트를 시작하는 것은 일반적이고, 프로젝트 비용이 얼마나 들어갈지 알수도 없는 상황에서 입찰과 수주과 이루어지며, 이또한 저가 낙찰은 너무 흔합니다. 그 손실은 당연히 하청 업체들에게 전가가 되기 일쑤입니다. 이러한 구조하에서 많은 하청업체들은 기술개발보다 저가 용역에만 매달리게 되곤합니다.

이러한 현상은 무지한 대부분의 고객이 초래한 면이 있지만, 결국 그 피해는 프로젝트 품질의 저하로 고스란히 고객에게 다시 돌아가는 악순환이 벌어집니다. 여기서 손해를 보는 회사들은 대형SI회사들이 아니고 수많은 하청 업체와 솔루션 개발 업체들이 됩니다. 이런 업체들이 우리나라에서 장사 못해먹겠다고 외국으로 나갈려고도 해보지만 뾰족한 수가 없는 것이 대부분이죠.

해결책은 2가지로 생각하고 있습니다.

첫째, 대형 SI업체의 해체입니다. 부정적이인 해체가 아니고, 대형 SI업체도 수익을 제대로 낼 수 있는 건설적인 구조로 변화해야 합니다. 프로젝트의 모든 것을 알아서 몽땅 해줘서 수익성이 낮은 자잘한 프로젝트와 일까지 매달리지 말고 큰 업체가 할만한 일들을 해야 합니다. 대형SI업체들은 작은 프로젝트와 업무로 인해서 대부분 손실을 보고 큰 프로젝트에 몇개에서 그 손실을 매꾸는 것으로 알고 있습니다. 더이상 SI라는 분야에 매달리기 보다는 IT컨설팅, IT서비스의 영역으로 포커싱이 되어야 한다고 생각합니다. 이것이 대형 SI업체도 살수 있는 길이고 이는 SI업체들이 스스로 변화해야 하는 부분입니다.

둘째, 제도적으로 더욱 보완이 되어야 합니다. 정부에서 해야 할 일이지요. 현재 분리발주법이 시행 중이지만 그 효과는 글쎄입니다. 편법이 얼마든지 가능하죠. 그리고 SW분리발주가 아닌 분석프로젝트 분할발주가 필요합니다. 현재는 대충의 요구사항을 가지고 수주를 하다보니 프로젝트를 진행하다보면 프로젝트가 2배로 커지기도 합니다. 특정 규모이상의 대형 프로젝트인 경우는 분석을 분리하여 프로젝트의 범위를 명확하게 하면, 전체 프로젝트의 비용이 합리적으로 나오게 됩니다. 여기에 저가입착을 어렵죠. 들어가는 비용이 뻔한 상태에서 저가 입찰은 품질을 포기하는 것이고, 이런 환경이라면 기술력이 낙찰의 중요한 요소가 되겠죠. 외국의 경우는 이미 분석 프로젝트를 분할하여 발주하는 것은 일반적입니다. 이를 제도적으로 더욱 보완해서 고객이나 업체 모두 상생의 길로 가야 할 것 같습니다.

악순환의 고리를 누가 먼저 끊을까요? 정부일까요? SI업체일까요? 수많은 중소기업들이 조금씩 바꿔나가기에는 너무나 머나먼 길일 겁니다.

Second System Syndrome (뭐 이따위로 만들었어?)

프레드 브룩스가 얘기한 "Second System Syndrome"은 주변에서 흔하게 접할 수 있습니다.

현재의 개발자들이 과거에 선배들이 만들어 놓은 First System의 문제 요소를 지적하며 Second System을 만들어야 한다고 주장합니다. 이러한 현상은 정말로 지겹게 봐왔습니다. 즉, 선배들이 만든 시스템을 "뭐 이따위로 만들었어? "하고 생각하면서 Second System을 만들어야 하는 온갖 이유를 대면서 경영자를 현혹시킵니다.

이렇게 주장하는 개발자들은 어리고 경험도 부족하기 때문에 First System이 얼마나 어려운 문제를 다루고 있었는지 제대로 이해하지 못합니다. 또 자신들이 문제로 지적하고 있는 요소들 외에 얼마나 많은 복잡한 이슈들을 First System에서 해결하고 있는지 알지 못합니다. 또한 과거의 문제를 근사하게 해결했다는 성과를 뽑내고 싶은 욕구도 있습니다.

이렇게 만들어진 Second System은 대부분의 경우 First System을 얕잡아 보기 때문에 예상치 못한 이슈들과 많이 부딪히게 되고 예상된 일정을 지키지 못하게 됩니다. 또 이미 First System에서 해결했던 수많은 문제들이 Second System에서는 버그로 나타나는 경우가 허다합니다.

v1.0이 허접하고 문제도 많다고, 기능을 잔뜩 붙여서 v2.0을 만들었지만, 고객들이 기능은 적어도 문제가 적은 v1.0을 다시 찾는 일을 보는 것은 그리 어렵지 않습니다. 비록 v2.0이 예상된 일정을 훨씬 넘겨서 어렵게 출시가 됐는데도 말입니다.

Third System Syndrome이란 현상이 없는 이유는 Second System Syndrome의 쓴맛을 본 경영자가 세번째는 허용을 하지 않기 때문이겠죠.

이렇게 Second System Syndrome이 일어나는 결정적인 이유는 First System을 만들어 놓은 개발자들이 달랑 소스코드만 남겨 놓았기 때문인 경우가 대부분입니다. Second System을 주장하는 개발자들은 대부분이 이 First System을 유지보수하는 하는 개발자들이고 지겹도록 문제점만을 봐왔기 때문입니다. 그러면서도 본인들도 Second System을 만들면서 달랑 소스코드와 별 쓸모 없는 문서 몇 개 만들어 놓는 것이 고작입니다.

애초에 정상적인 체계를 갖추고 개발에 모든 정보가 지식화가 되어서 동료들간에 또 후배에게 전달이 되어 있었다면 이러한 First System의 무조건적인 비판은 일어나지 않을 겁니다.

만약에 현재 여러분이 문제가 많은 First System을 유지보수 하느라고 고생을 하고 있고 이를 만든 선배들은 이미 퇴사를 하였다면, 무조건적으로 Second System을 주장하지 말고 냉정한 판단을 해야 합니다. Second System이 실패하는 일은 너무나 흔하니까요. First System의 기반을 완전히 무시하는 것은 그동안 개발팀이 쌓아온 재산을 무시하는 것과 다름이 없습니다. 차라리 First System의 Refactoring이나 Rearchitecturing을 통해서 문제 해결을 시도하면서 좀더 지식과 경험을 쌓고, 

"자신의 First System을 만들 때를 대비해서 내공을 쌓아가세요."

2009년 2월 5일 목요일

깨끗한 개발 환경, 빌드 환경, 테스트 환경

개발, 빌드, 테스트 환경을 별도로 두지 않고 그냥 개발자 PC에서 수행하는 경우들이 많습니다.
이렇게 되면 자칫 빌드 시 개발 환경에 영향을 받아서 의도하지 않는 문제가 발생할 수 있습니다.
따라서 개발, 빌드, 테스트 환경은 각각 어떻게 구성을 해야 할지 미리 정하고, 그에 따라야 합니다.

일반적인 경우 빌드는 깨끗한 환경에서 항상 원하는 빌드를 만들어 낼 수 있도록 하며, 테스트는 스펙에서 요구하는 테스트 요구사항에 따라서 각각의 테스트 환경을 구축해야 합니다. 여러 플랫폼을 지원하는 경우 테스트 환경 구축이 아주 복잡하고 비용이 많이 들기도 합니다. 테스트 환경에 대한 이해는 많이들 하고 있다고 가정하고, 빌드 환경에 대해서 조금 더 얘기를 해보고자 합니다.

빌드가 무엇인지 먼저 얘기를 해보죠. 개발자 Visual Studio나 Eclipse 같은 IDE을 이용해서 빌드하는 것은 여기서 말하는 빌드는 아닙니다. 여기서 말하는 빌드는 공식 빌드입니다. 공식 빌드는 Release를 위해서 빌드하는 것을 말합니다. 개발자들이 하는 빌드는 그냥 개발의 일부이죠.

많은 개발자들이 자신의 개발 환경에서 그냥 빌드한 결과물을 묶어서 제품을 만들어 고객에게 전달하곤 합니다. 그렇게 되면 IDE의 빌드 설정에 따라서 빌드의 결과가 달라져서 예기치 못한 문제가 발생하기도 하고, 개발자가 퇴사하고 새로운 개발자가 빌드를 하려고 하니 빌드가 안되기도 합니다. 또는 개발자 PC의 환경에 영향을 받아서 개발자 PC에서는 잘 동작했으나, 고객의 환경에서는 문제가 발생하기도 합니다.




각각의 환경의 관리는 개발팀, B/R팀, 테스트 팀이 맡고 있고 함부로 건드리지 못합니다. 

지금까지 이러한 구분없이 개발을 하고 계셨다면 혹시 이로 인한 문제는 없었는지 생각해보세요. 없었다면 정말 운이 좋은 겁니다. 시스템이 점점 커지고 고객이 많아지는데도 계속 운만을 바랄 수는 없겠죠. 

2009년 2월 4일 수요일

소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?




그동안 약 2달에 걸쳐서 제 블로그에서 Poll을 실시하여 이와 같은 결과가 나왔습니다. 

이런데 이상하게 제가 현장에서 만나는 여러사람들의 의견과 다른 결과가 나왔습니다.
그래서 그 이유를 2가지 정도로 추측해보고 있습니다.

첫째, 블로그 방문자들(주로 블로거)은 비 방문자보다 소프트웨어 공학에 더 많은 지식과 경험을 을 가지고 있다.
둘째, 실제 자신의 경험에 의한 생각보다는 정답이라고 생각하는 것에 투표를 하였다.

물론 첫째 이유겠죠 ^^

아래 목록을 보면 각 항목의 득표 비율이 나오는데, 제 생각과 크게 다르지 않습니다. 
하지만, 유난히 유지보수에 대해서 작게 나온 것은 대부분의 방문자들이 유지보수가 그렇게 중요하지 않은 프로젝트들을 수행하고 있는 것이 아닌가 추측해 봅니다. 


다음 투표로는 SCM 사용도에 대해서 진행을 하려고 합니다. 많은 성원부탁합니다.

Daily Build를 하십니까?

Daily Build는 많은 혜택을 줍니다.
소프트웨어가 항상 빌드 가능한 상태를 유지할 수 있도록 해주며
모든 소스코드가 매일 통합되므로 통합의 혼란을 줄여주며 개발자들의 개발진척도를 피부로 느끼게 해줍니다. 또 유닛테스트를 자동으로 매번 시행하여 기본적인 테스트를 해줍니다.

요즘은 Daily가 아니고 CI툴을 이용하여 빌드 주기를 조절하고 추가적인 작업들도 하지만 개념은 Daily Build와 크게 다르지 않습니다. CI툴은 이를 좀더 편하게 UI와 몇몇 기능을 제공하고 있습니다.
여기까지는 대부분의 개발자들이 알고 있는 내용이기도 합니다.
하지만 Daily Build를 언제부터 시작하느냐에 대해서는 의견이 명확하지 않더군요.
저는 Daily Build는 설계가 끝나고 구현 첫날부터 Daily Build를 할 수 있어야 한다고 생각합니다.
기본적인 개발 Stage를 사용하던, Iteration을 쓰던 간에 설계의 결과물은 빌드가 되어야 한다는 것입니다. TDD를 사용할 경우 Test 코드를 먼저 작성을 하기 때문에 빌드가 가능합니다. 테스트는 통과를 하지 못하더라도 말입니다. 즉 껍데기, Class, Public function의 Prototype을 정해 놓고 빌드가 가능한 상태로 만들어 놓고 구현을 시작합니다.

이때 SCM에 Baseline을 한번 설정을 하고 소스코드의 내용을 채워 나가기 시작합니다. Daily Build의 혜택을 누리기 위해서는 소스코드를 빌드 가능한 상태로 만들어 놓고 시작을 해야 합니다.

2009년 2월 3일 화요일

서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System)

소프트웨어를 개발하고 있는데, 필수적인 기반시스템에 대해서는 이미 설명한 바가 있습니다.

이 기반시스템은 서로 연동이 되어서 맞물려 돌아갑니다.

만약에 이 기반시스템들을 사용하고 있지 않다면 기적적으로 개발을 하고 계시거나 정말 쓸데 없는 고생을 하고 계신 겁니다. 어떠한 방법론을 쓰더라도 이 기반시스템을 쓰는 것은 거의 다르지 않습니다. 우선적으로 시급하게 기반시스템들을 도입을 해야합니다. 기반시스템을 써보려고 하는데 어려움이 있거나 궁금한 점은 제가 도와드릴 수 있습니다.

그리고 각 기반시스템이 서로 연동되지 않고 따로 돌고 있다면 최대한 활용하고 있는 것이 아닙니다. 각 기반시스템들은 서로 연동이 되고 최대한 자동화를 해야 효율이 높아집니다. 각 기반시스템들이 기본적으로 어떤 것들을 교환하는지 간단하게 예를 들어 보겠습니다. 여기서 예라고 하는 이유는 계속 개량 발전시켜나면 연동하는 것들은 점점 늘어나고 자동화 되면서 효율은 더욱 높아지기 때문입니다.

물론 이 외에도 사용하는 기반시스템들도이 있지만, 아래 그림이 소프트웨어 회사라면 필수록 필요한 최소한만 추린 것입니다. 


  
각각의 연동 방식이나 자세한 내용은 많은 양이므로 추후 하나씩 설명하도록 하겠습니다.
그리고 하나하나의 운영 방법도 다양하고 계속 발전하고 있어서 자신의 회사에 적당한 방법을 찾아야 합니다.

이렇게 서로 연동되고 있지 않으면 자동화 될 수 있는 일에 괜히 시간과 노력을 들이고 있는 겁니다. 그렇게 된다면 개발자들은 개발을 해야 할 소중한 시간에 쓸데 없는데 시간을 허비하고 실수에 의한 사고 가능성도 높아집니다. 또 오랫동안 개발 정보가 쌓여도 그리 효율적으로 활용되지 못합니다. 

일단 이런 식으로 잘 갖추워진 기반시스템 하에서 개발을 하다보면 과거의 방식으로는 도저히 돌아갈 수 없고, 과거에 왜 그렇게 개발을 하면서 시간을 낭비했는지 안타까운 마음이 생길 겁니다.