소프트웨어 프로젝트는 왜 실패하는가?

우리는 주변에서 실패한 소프트웨어 프로젝트를 보는 것이 그리 어려운 일은 아니다. 프로젝트의 규모가 커지고 기간이 길어지며 많은 인원이 투입될수록 프로젝트 실패 확률은 증가한다. 

프로젝트 성공을 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패했는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

• 약속된 일정 내에 제품 또는 서비스를 출시 못했다.
• 소프트웨어가 시장에서 요구되는 품질을 충족하지 못했다. (요구사항, 성능, 안정성, 사용성 등)
• 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
• 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
• 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
• 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자. 

• 고객의 요구사항을 충분히 파악하지 못함
• 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당부분의 시간을 소모하여 개발 기간이 부족하게 됨
• 스펙/설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 함
• 작성된 스펙을 관련자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발함
• 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어짐
• 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 함
• 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작함. 나중에 잘못된 코드를 고치느라고 시간이 더 소요됨
• 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕함
• 일정관리를 대충 해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못함
• 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패함
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 함
• 프로젝트 팀원들의 팀웍에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트는 산으로 감
• 도입한 외부 필수 기술이 기대처럼 동작하지 않는다.
• 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못함
• 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해짐

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 간단히 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인을 “스펙"이라고 생각한다. 

다른 영역도 중요한 것이 사실이지만 스펙을 적는 것은 소프트웨어를 개발하는데 가장 중요하면서 가장 어렵다. 스펙을 적는 것을 “분석” 또는 “분석/설계”라고 한다. 설계가 여기에 왜 포함되었는지 의아한 사람도 있을 텐데, 분석 시에 상위 설계의 상당부분이 포함이 되는 경우가 많고 프로젝트에 따라서 다르지만 분석과 설계는 그 경계가 모호하기 때문에 같이 다루는 경우가 많다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가면서 소프트웨어가 무사히 완성을 하기도 한다. 소수의 경험이 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 개발을 잘하기도 한다. 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 테스트 문서도 전달하기도 한다.

소규모 프로젝트에서의 성공의 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사들에서는 이런 함정에 종종 빠진다. 개발은 문서대로 되지도 않을 뿐만 아니라 수시로 바뀌는 요구사항을 문서가 너무 많아서 문서에 반영도 제대로 못한다.

 

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 관련자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 말짱 공염불일 뿐이다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다.

이 방대한 얘기를 짧은 글로 어떻게 소개할 수 있을지 걱정은 되지만, 개발자가 어떻게 하면 소프트웨어 분석, 설계 역량을 가질 수 있으며 회사는 어떻게 그런 역량을 축적할 수 있는지 다음에 몇 개의 글을 통해서 조금 더 자세히 얘기를 해보고자 한다.

share with abctech.software

문서가 없으면

작은 프로젝트인 경우 문서를 거의 만들지 않고 개발을 하면 더 효율적이라고 생각할 수도 있다.

가끔은 그렇게 생각할 수도 있다. 너무 시간이 없다는 핑계를 대기도 한다.

하지만 이렇게 해서 모든 프로젝트에 문서가 거의 없으면 개선을 하려고 하는 회사에서 도움을 요청해도 막상 도와주기가 매우 어렵다.

문서가 거의 없어서 모든 것을 물어보면서 파악을 해야 한다. 있는 것이라고는 거의 쓸모 없는 문서와 소스코드인데 소스코드는 회사와 제품을 파악하는데 별 도움이 안된다.

문서가 제대로 있다면 80%는 문서를 보고 20%만 물어 보면 된다.

이때 개발을 하고 나서 나중에 만드는 문서는 그 효율성이 반으로 줄어든다.

나중에 만드므로 일단 충실도가 떨어지고 개발하기 전에 만들때 고려해야 할 요소들은 프로젝트가 이미 끝났기 때문에 다 생략된다. 사실 제대로 적기도 어렵다.

이런 문서라도 없는 것보다 낫기는 하지만 프로젝트만을 위한 것이라면 이런 문서는 별로 필요도 없다. 유지보수를 위해서라면 차라리 코드를 보는 것이 낫다. 들어간 시간에 비해서 효과가 별로 없다는 뜻이다.

이는 신입사원이 입사를 했을 때에도 똑같다. 개발팀에 합류하여 제대로 개발을 시작하려면 프로젝트를 파악해야 하는데 문서가 없으면 파악하기가 너무 어렵다.

선배들이 말로써 하나씩 설명을 해줘야 하는데 다들 바빠서 그렇게 할 수가 없다. "멘토" 또는 "사수"를 정해서 알려주라고 하는데 어디 사수들이 그렇게 한가한가?

그러다 보니 신입 개발자들은 제 능력을 발휘하려면 너무 오랜 시간이 걸린다. 거의 자수성가 식으로 소스코드를 보고 분석해서 하나씩 시행착오를 거쳐서 배워야 한다. 이 과정에서 버그도 많이 양산해내게 된다. 

몇 년이 지난 후에 이제 좀 개발을 할만하면 또 후배가 들어온다. 해 온 방식이 이 방식이라 후배들에게 똑같이 전수를 하게 된다.

즉 "악순환"인 것이다.

프로젝트를 진행하면서 프로젝트 기간을 단축하기 위해서 당연히 만드는 문서들은 다른 개발자들이 도와주기 쉽게 만든다. 

무슨 문서를 얼마나 자세히 만들어야 하는지는 프로젝트마다 다르다. 하지만 내가 경험한 수많은 프로젝트들은 문서가 그렇게 많이 필요하지 않았다. 설계문서까지도 필요 없는 경우도 매우 많다. 어떤 문서를 어떻게 적는 것이 가장 효율적인지는 경험에서 나온다. 경험없는 개발자들이 문서를 아예 적지 않거나 너무 많이 적는다.

너무 많이 적을 바에는 아예 문서를 적지 않는 것이 나은 경우도 많다.

문서는 딱 필요한 만큼만 적어야 한다.

그래야 다른 사람이 도와줄 수 있고 나는 더 가치 있는 일을 할 수 있다.

이번 프로젝트 내일 끝나?

SW개발 프로젝트가 언제 끝날지 정확하게 모르는 경우가 허다하다.

프로젝트를 진행하고 있는 개발자나 PM도 이 프로젝트가 언제 끝날지 전혀 감이 안잡히는 경우가 많다. 

하지만 분명한 것은 이 프로젝트가 예정된 종료일까지는 끝나지 않을 것이라는 것은 아주 잘 알고 있다.

이것을 알고 있다면 일정을 연기해야 하는데 언제로 연기를 해야 하는지 알 수 없으니 일정 연기를 요청하기도 어렵다. 일정을 연기 했으면 그 일정은 지켜야 하는데 연기된 일정도 전혀 근거가 없이 그냥 감으로 생각한 일정이기 때문이다. 이런 일정은 또 연기되기 마련이다.

그래서 Due date이 되어서어 끝나지 않음을 알고 일정 연기를 요청하고 한다. 이렇게 촉박하게 일정이 자주 연기가 되면 영업이나 마케팅 부서에서는 도저히 개발팀의 일정을 믿을 수 없어서 자신있게 비즈니스를 하기 어려워진다.

그럼에도 일정이 늦어지고 있는 것을 늦게 알려주는 이유는 미리 얘기를 해봤자 일찍 혼나기 밖에 더하겠냐는 생각때문이기도 하다. 일정이 촉박해지면서 매일 야근을 하면서 열심히 하는 모습을 보여주면 일정을 연기해도 큰게 혼나지 않을 것이라고 생각하곤한다. 

하지만, 경영자 입장에서는 밤새면서 일정 못지키는 프로젝트보다는 6시에 퇴근하고 약속한 일정을 지키는 프로젝트가 훨씬 낫다. 그렇다고 주먹구구로 개발하면서도 일정을 터무니없게 길게 잡으면 곤란할 것이다.

제대로된 조직, 프로세스, 시스템을 갖추고 있는 회사에서 SRS를 적절하게 썼다면 1년짜리 프로젝트에서 1주일 지연이 되는 것을 6개월전에도 알 수 있다. PM은 이런 일정 지연이 생기면 이를 복구하기 위한 다양한 기법들을 사용하게 된다. 따라서 일정에 맞춰서 프로젝트를 마칠 수 있는 가능성은 대단히 높아지게 된다.

더 이상 개발팀에게 "내일은 끝나나?"라고 물어볼 필요가 없다. 개발팀도 신뢰를 회복할 수 있을 것이다.

또한, 더 중요한 것은 6시에 퇴근을 하면서도 프로젝트를 더 일찍 끝낼 수 있다는 것이다.

심정적으로 경험적으로 이것이 믿어지지 않는 분들도 많겠지만, 필요한 만큼 적절히 체계화 된 개발을 하고 SRS와 설계를 적절하게 하면 프로젝트 일정도 지키고 개발자도 행복해진다.

여기서 중요한 것은 적절하게 하는 것이다. 적절하다는 것이 가장 어려운 것 중 하나다.

커뮤니케이션 오류

소프트웨어 프로젝트를 진행하다 보면 수많은 커뮤니케이션의 오류를 발견하게 됩니다.

문서화 되지 않은 수많은 의견과 결정들에 대한 오해와 대화를 하면서 발생하는 표현의 오류는 한 두개가 아닙니다. 이는 비단 프로젝트에서 뿐만 아니라 일상생활에서도 벌어지는 현상이지만, 일상생활에서의 커뮤니케이션 오류는 그렇게 심각하지 않을 수 있지만, 프로젝트에서의 커뮤니케이션 오류는 심각한 손실을 초래하기 때문에 조심할 필요가 있습니다.

따라서 프로젝트를 진행하면서 오가는 대화나 기록은 명확해야 합니다. 미사여구보다는 직설적인 화법으로 핵심을 정확하게 말해야 합니다. 또 하나의 문장은 사실, 의견, 추축, 가정, 결정 또는 정보일 수 있습니다. 그런데, 현재 하고 있는 말이 사실인지 의견이지 명확하게 하지 않으면 수많은 오해가 발생합니다.

특히, 의견이나 추측을 사실처럼 얘기하면 다른 사람들은 이를 바탕으로 계획을 세울 수도 있습니다. 또 경영진은 잘못된 결정을 내려서 큰 손해를 보게 될 수도 있습니다. 그리고 가정으로 이미 확인된 사실처럼 얘기하면 프로젝트는 큰 리스크를 안게 됩니다. 

따라서 프로젝트에서는 구체적으로 가정과 종속관계를 파악하는 활동을 하게 됩니다. 프로젝트를 진행하면서 확인되지 않은 사실이나 결정해야 할 것들 및 종속되어 있는 항목을 찾아서 리스크관리를 해야 하기 때문입니다. 이러한 하나하나가 프로젝트의 리스크라는 것을 생각하지 못하면 지뢰밭을 걷는 것과 같습니다.

이러한 커뮤니케이션 오류를 제거하려면 이 문장이 사실인지 의견인지를 정확하게 구분하여 적는 것이 좋습니다. 특히 누구의 의견이라고 적을 수도 있고, 누구의 결정이라고 표현할 수도 있습니다. 그리고 가정은 언제 확인하고 해결이 될지 계획까지 적는다면 누구나 해당 내용이 확인이 필요한 가정사항이고 상황에 따라서 프로젝트의 위험 요소라는 것을 쉽게 파악할 수 있습니다. 이렇게 직설적이고 확실한 표현이 삭막하게 들릴 수는 있지만, 프로젝트를 진행하는데 있어서는 더 좋은 표현법입니다.

연인에게 이러한 표현법은 안되겠지요? 

당신을 사랑하는데 이 표현이 사실, 의견, 추측, 가정 또는 결정일까요? 이를 구분해서 말한다면 따귀맞기 십상이겠네요.

프로젝트 시작부터 개발자가 바글바글

소프트웨어 개발 프로젝트가 시작되면 바로 개발팀이 구성되어서 개발자들이 바글바글 한가요?

그렇다면 뭔가 개발 체계에 잘못된 것이 없는지 검토를 해봐야 합니다.

개발을 단계(Stage)구분 없이 마구잡이로 하고 있지 않은지?

개발 업무(분석, 설계, 구현)의 구분 없이 섞여서 하고 있지 않은지?

개발자가 별도의 전문성 없이 모든 업무(분석, 설계, 구현, 빌드, 테스트)를 다 하고 있지 않은지?

프로젝트의 각 단계에 따라서 투입되는 인력이 달라집니다. 

소프트웨어 개발 프로젝트에서 흔히 저지르는 실수 중 하나가 프로젝트가 시작되자마자 모든 프로젝트 인력을 한꺼번에 투입해 놓고 프로젝트 끝날 때까지 그 인원으로 계속 진행하는 경우입니다. 

각 단계 별로 필요한 인력과 인원 수가 달라지는데 프로젝트 초기부터 많은 인원이 투입되면, 개발자들이 별로 할 일이 없게 됩니다. 그렇게 되면 요구분석이 완료되지도 않은 시점에 특별한 계획도 없이 코딩도 해보고 설계도 해보고 이것저것을 개발하기 시작하기도 합니다.

위 그래프의 핵심은 초기부터 많은 개발자를 투입하지 않는다는 것입니다. 요구분석 단계에 투입되는 개발자는 SRS 작성에 필요한 정보를 제공하는 개발자들입니다. 요구사항의 타당성을 점검하고, 필요 시 프로토타입을 만들어 볼 수도 있습니다. 그런 다음, 설계 단계에서는 설계에 참여하는 인원만 추가로 투입하면 됩니다.

 

테스터가 프로젝트 초기부터 테스트에 참여하는 점을 눈 여겨 봅시다. 테스터 역시 SRS작성에 참여하고, 테스트 요구사항을 제시하고, 각 요구사항이 테스트 가능한지 검토합니다. 요구분석단계에 테스터는 실제로 테스트 계획서를 작성하기도 하고 이를 준비만 하기도 합니다. 

이렇듯 각 단계 별로 인원을 효과적으로 투입해야만 비용을 절감할 수 있으며, 성급하게 프로젝트 후반부에 해야 할 일들을 앞에서 미리 함으로써 발생하는 수많은 문제를 방지할 수 있다. 미리 작성해 놓은 코드가 아까워서 어떻게 하든 프로젝트에 사용해보려고 하지 않겠습니까?

그 외에도 고참 개발자나 신입 개발자나 특별한 구분 없이 모두 모여서 서로 비슷한 일들을 나눠서 일을 하고 있다면 개발 조직의 효율성 및 생산성이 떨어지는 경우라고 볼 수 있습니다. 아직 주먹구구 단계를 벗어나지 못한 상태입니다. 이런 경우에도 프로젝트를 시작하면 모두 모여서 그냥 개발을 시작하죠.

이렇게 개발자들이 프로젝트 초기부터 모두 투입되는 경우는 비용이나 개발 인력 활용 면에서 대단히 불리합니다. 프로젝트가 진행되는 단계에 따라서 인원을 적절하게 투입해야 합니다. 물론 그렇게 하기 위해서는 각 기능조직의 전문성이 갖춰져야 하고, 개발에 필요한 시스템과 프로세스가 필요하며, 개발자들이  문서 작성 능력을 필수적으로 갖추고 있어야 합니다.

프로젝트는 연습이 아니다.

필자는 수많은 소프트웨어를 개발해왔고, 주위에서 여러 프로젝트를 봐왔습니다.

그러면서 성공한 프로젝트와 실패한 프로젝트도 많이 봐 오면서 그 차이에 대해서도 많이 생각해 왔습니다.

물론, 성공한 프로젝트는 모두들 알고 있는 요소들이 있습니다. 

상세하고 꼼꼼한 일정관리, 꾸준한 리스크관리, 인력관리, 품질관리 등등 이미 알려진 것들입니다. 비단 S/W 프로젝트가 아니더라도, 빌딩을 만들 때도 당연히 필요한 프로젝트 관리의 요소들입니다.

그런데, 유독 소프트웨어 개발 프로젝트에서 종종 벌어지는 현상이 있습니다. 이것이 프로젝트에 큰 리스크가 되고 프로젝트를 실패하게 만드는 원인이 되기도 합니다.

이것은 바로 "프로젝트를 연습처럼 생각한다"는 겁니다. 연구, 공부처럼 생각합니다.

"요즘 Python이 인기인데, A모듈에서는 Python을 써야겠다."

"이번 프로젝트는 UML로 설계를 하겠다."

"Flex로 UI를 만들면 쉽다고 하는데, Flex를 쓰자"

"A라는 DB가 빠르고 가볍다고 하는데, 그걸 써보자"

"요즘 B기술이 대세인데, 어차피 공부해야 할 거 프로젝트 하면서 배우자"

실제로 개발자들은 실제 프로젝트에서 많이 배우는 것이 사실이지만, 거의 경험이 없는 기술을 단지 "배우기 위한 목적"이나 "좋아 보여서" 사용한다면 이는 프로젝트에 큰 리스크가 될 수 있습니다.

필자는 개발자들에게 늘 강조하는 것이 "프로젝트는 연습이 아니다.", "프로젝트는 검증된 기술을 가지고 하는 것이다."입니다. 물론 검증된 기술과 아닌 것의 경계는 모호하지만 이는 경험으로 판단해야죠. 충분히 성공할 수 있는 기술의 조합으로 프로젝트를 해야죠. 그렇다고 하더라도, 프로젝트 중간에는 수많은 변수들이 있어서 성공이 보장된 것이 아닙니다. 아직 검증이 안되었지만, 프로젝트에 꼭 필요한 기술이라면, 미리 또는 요구분석 시에 Prototype을 만들어보면서 검증을 하는 것이 좋습니다. 모든 기술을 다 검증할 필요는 없지만, 검증이 필요한 기술을 프로젝트에 직접 사용할 경우 실패할 수도 있습니다.

또 개발자들이 충분히 연습이 되어 있지 않아서 능숙하게 사용하지 못한다면, 일정을 지연시키는 큰 원인이 됩니다. 이런 경우는 이미 익숙한 옛날 기술을 사용하는 것이 나은 경우가 많습니다. 

Research Project라면 얘기가 다르죠. Research Project의 목적은 연구이기 때문에 검증 안된 기술을 얼마든지 사용해도 되죠. 이 경우 요구사항의 상세도도 일반 프로젝트와 다르고 일정의 중압감도 다르기 때문에 기술에 집중할 수 있습니다. 평상 시에 크고 작은 Research Project를 자주 수행해야 실제 프로젝트에 적용할 수 있는 기술을 풍부하게 보유할 수 있습니다.

프로젝트를 연습이라고 생각한다면, 프로젝트 실패로 가는 지름길로 가고 있는 것입니다. 자신이 지금 어떤 프로젝트를 하고 있는지 잘 구분해야 합니다.

그냥 쓸 수 있겠네요.

소프트웨어를 개발하면서 가장 어려운 일은 고객의 요구사항을 파악하는 일이라고 알려져입니다.

고전적인 Waterfall 방식부터 Agile까지 요구사항에 대해서 다양한 방법으로 상당히 신경을 쓰고 있습니다.

특히나 우리나라에서는 고객이 요구사항을 잘 가르쳐 주지 않습니다. 물론 자신의 요구사항을 완벽하게 자세히 알고 말해주는 고객은 전세계 어디서도 찾아보기 어려운 것이 사실입니다. 정도의 차이가 있을 뿐이죠. 그만큼 요구사항 파악은 어려운 일입니다.

우리나라에서 요구사항 파악 시 고객이 이렇게 얘기하는 경우가 흔합니다.

"자세한 요구사항은 나중에 알려줄 테니 일단 구현을 시작해주세요."

그래서 일단 제품을 다 만들어 놓고 고객에게 시연을 하면 그 때서야 고객이 "여기는 이렇게 고쳐달라", "이 기능을 넣어달라", "저 기능은 빼달라" 주문을 하기 시작하죠. 그렇게 제품을 고치고, 시연하고 하면서 고객의 요구사항을 만족시켜 가는 방법이 우리나라에서는 그리 드문 일이 아닙니다. 심지어는 요구사항 분석에 경험이 적은 개발자들은 그냥 그렇게 하는 방법에 익숙해져 있기도 합니다.

이 방법은 대단히 비효율적이고 비용이 많이 드는 방법입니다.

고객의 말 한마디에 몇 주간 노력해서 만든 기능이 빠질 수도 있습니다. 그리고 황당한 요구사항이 갑자기 추가될 수도 있고, 도저히 초기에 일정을 예측할 수도 없죠. 

개발자들이 고객의 요구사항을 너무 잘 알고 있고, 오히려 개발자가 고객을 리드하는 경우라면 일부 효과가 있을 수 있어도, 대부분의 경우 비싼 방법입니다.

이와 같이 자세한 스펙을 쓰기 전에 미리 만들어서 보여주는 방법을 "Prototyping"이라고 합니다. 그 중에서 고객의 요구사항을 파악하고 요구사항을 명확하게 하기 위한 방법은 "1회용 Prototyping"이라고 합니다. 왜 "1회용"이냐 하면 이는 요구사항을 파악하기 위한 것이기 때문에 Fix된 요구사항이 아닙니다. 제품에 기능으로 추가될지 빠질지 알 수 없고, 기능이 어떤 형태로 변하게 될 수 예측할 수 없으므로 제대로 만들면 비용과 시간이 많이 들기 때문에 아주 간단하게 만들어 보는 겁니다. UI에 대한 요구사항을 명확하게 하고 싶으면 UI만 동작하도록 해서 고객과 의논할 수 있고, 특정 기능에 대해서 자세히 알고 싶으면 그 기능이 어떻게 동작하는 지만 간단히 만들어 보는 겁니다.

이때는 제대로 제품을 만들듯이 에러처리를 꼼꼼히 하지도 않고, 회사의 코딩 규칙을 지키기 위해서 주석을 제대로 달지 않아도 되며 속도를 위해서 코드를 개선하지 않고, 메모리 최적화도 필요 없습니다. "1회용 Prototyping"은 요구사항을 얻고 명확하게 하기 위한 것이 목적이므로 최단시간에 최소한의 비용으로 만들면 됩니다. 

이렇게 만들어진 "1회용 Prototype"을 고객이나 영업부에 보여주면 "다 됐네?", "그냥 쓸 수 있겠군요."라고 하는 경우가 많습니다. 이는 마치 모델하우스를 보고 거기에 들어가서 살겠다고 하는 거와 비슷합니다. 

"1회용 Prototype"은 요구사항을 명확하게 하기 위한 활동이고, 이를 통해서 요구사항이 정해졌으면, "1회용 Prototype"은 버리고 다시 만드는 겁니다. 하지만 개발자들은 이를 다시 써먹으려고 하는 경우가 많습니다. "Prototype"에 너무 많은 노력을 들였거나, 시간이 촉발할 때 그냥 쓰고 싶을 수도 있는데, 이는 나중에 제품의 품질에 영향을 주기 때문에 "1회용 Prototype"은 참조는 할 수 있지만, Copy & Paste해서 쓰면 안 됩니다.

"1회용은 1회용일 뿐"

Prototype을 만드는 도중에 Project는 중단이 되는 것이 아니고, 요구사항 분석을 계속해 나가면서 1명의 개발자나 소수의 인원이 Prototype을 만들어 보는 겁니다. 물론 Prototype을 만드는 일도 계획되어야 하며, 적절한 Prototype 작성은 프로젝트의 시간과 비용을 절약해줍니다. 또한 나중에 생길 가능성이 있는 요구사항의 변화를 줄여줘서 Risk도 감소시켜주는 효과도 있습니다. 모든 기능을 다 Prototype을 만들어야 하는 것은 아니고 꼭 필요한 부분만 Prototype을 만들어서 확인할 수 있도록 적절히 판단하는 것도 경험이 필요합니다.

코더(Coder)의 비애

블로그에서 설계에 대한 몇몇 글들을 의견을 적어보려고 합니다. 

안녕하세요. Ray입니다.

써니님이 지금 하시는 일을 코딩이라고 만 얘기할 수는 없는것 같습니다. 분석, 설계도 다 하고 계시는데, 문서화가 안되어 있거나 부족할 수는 있어도 분석, 설계는 하고 있는 거죠.

적은 인원이나 소규모 프로젝트에서는 설계가 별로 이슈가 되고 있지 않습니다.

이런 상황에서 인도에 외주를 줄만큼 설계를 하는것도 낭비죠.

하지만, 내가 설계를 해서 다른 사람이 내 설계서를 보고 약간만 물어보면서 구현(코딩)을 할 수 있느냐를 따져보면 설계 이슈는 전면으로 부각됩니다.

실제로 제대로 설계를 해서 산출물을 만들어 외부에 코딩(구현) 외주를 줄 수 있는 사람은 많지 않습니다.

하지만 이런 구현 외주는 미국과 인도에서는 흔한 일이죠. 물론 설계를 가르쳐 주는 곳도 없어서 배울 수는 있지만, 애초에 이러한 환경에서 같이 일을 했으면 잘 작성된 설계서를 보고 구현도 하고 아키텍쳐 설계회의에도 참석하고 많이 배우죠.

우리의 예를 보면 소규모 기업에서 좋은 소프트웨어를 히트쳐서 회사가 갑자기 켜지고 2,3명이서 개발하던 개발팀이 수십명으로 늘어나면서 제품은 복잡해지고 켜졌는데, 제품은 이전만 못한 경우를 많이 봤습니다.

여러 다른 이유가 있지만, 설계 방법에 대한 이슈도 그 문제에 한몫을 합니다.

밑에 Cavin님이 말씀하신 것 처럼 설계 컨설턴트는 있을 수 없습니다. 제 직업이 소프트웨어 컨설턴트이지만, 설계자체를 컨설팅 해줄 수는 없습니다.

또 설계를 가르쳐주는 것도 거의 불가능합니다.

설계의 기본 컨셉, 방법, 툴 사용법 등을 가르쳐 줄 수는 있습니다.

하지만 이것들이 설계를 할 수 있게 해주지 않습니다.

그런 것들을 모두 다 알고도 오랜 경험이 또 필요하고, 문서화를 할 수 있는 실력도 필요하죠. 알고 있는 기술 분야도 워낙 다양해서 최고의 설계 컨설턴트가 도와준다는 것도 말이 안되는 얘기고 일부 기술이나 아키텍쳐에 대해서 도움을 받는 정도 이죠.

여기서 "설계는 뭐다"라고 얘기할 것은 하나도 없습니다.

그래도 이렇게 끝나는 글이 되면 너무 썰렁하니 설계의 시작과 끝 정도 정의하고 그 속은 워낙 다양하니 차차 여러 가지 의견을 글로 남겨보도록 하겠습니다.

설계의 시작은 우선 인터페이스을 찾아내는 것입니다. 그래서 인터페이스와 컴포넌트들을 구분하면서 시작이 됩니다. 이 개념은 OOP에서 출발한 것도 아니고 가장 전통적인 방법입니다. 소프트웨어의 분야는 수없이 바뀌어 왔지만, 설계의 원리는 크게 변하지 않았습니다. 코볼로 만들던, 자바로 만들던 소프트웨어를 만드는 철학은 기본적으로 많이 다르지 않습다. 설계의 기본은 시스템의 단위를 좀 더 작은 단위로 분할해 가면서 아키텍처를 설계하는 것입니다. 설계는 시스템을 잘게 나눠서 컴포넌트와 모듈을 정의하고 그 인터페이스를 정하는 작업입니다. 수많은 설계 방법들이 있지만 그 기본은 바뀌지 않았습니다. 카네기-멜론 소프트웨어 엔지니어링 인스트튜트에서 주창한ADD(Attribute-Driven Design, 속성 주도 설계) 방법이든, 다른 여러 아키텍처 수립 방법론들은 결국 이 방법을 체계화 한 것입니다.

UML과 같은 도구는 설계를 하는데 일부 도움은 될 수 있지만 설계에 꼭 필요한 것은 아닙니다. 설계한 결과를 적는 하나의 도구일 뿐입니다. 설계라는 작업은 소프트웨어 개발에 있어서 가장 자유도가 높고 창의성이 요구되는 작업입니다. 설계 기간은 선임 개발자들의 실력이 가장 많이 드러날 수 있는 기회이기도 합니다. 소소의 사람만이 쓸 수 있는 능력을 가지고 있는 SRS와는 달리 설계는 모든 선임개발자가 가져야 하는 필수적인 역량입니다. 설계에 대해서 너무 많은 제약을 가한다면, 좋은 설계가 나오기는 어려울 것입니다. 

그럼 설계의 끝은 어디일까요. 적어도 어느 정도까지 설계가 되어야 구현이 진행될 수 있을 까요?

설계가 끝나면 빌드(Build)가 시작되는 것이 기본 원칙입니다.

Class나 수많은 Public함수들의 Prototype이 모두 정의 되어 있고, Build Script까지 완성이 되어서 Daily Build가 시작됩니다. 그러면 Coder는 함수들의 내용과 Sub-function을 만들게 됩니다. Coder에게 함수와 Class를 어떻게 작성해야 하는지 설계서를 작성하는 것은 여기서 설명하기는 어렵겠죠.

여기서 말하려고 하는 것은 이정도까지 설계 단계에서 진행이 되지 않으면 Coder에게 일을 시키는 것은 사실 상 어렵습니다. 

설계를 중점적으로 담당하는 선임 엔지니어들은 지루한 코딩 작업은 가능하면 하지 않을려고 하죠. 설계가 훨씬 재미고 창의적인 작업이기 때문이죠. 그래서 코딩 작업은 신입사원이나 초급 개발자를 시키는 거죠.

이글을 보고 개발자들이 설계를 하는데 일말의 도움이 될 것이라고 생각하지 않습니다.

그냥 주변에서 돌아다는 Software Engineer, Archict, Coder등의 용어들에 너무 구애 받지 말고 자신의 일을 했으면 하는 바랍입니다.

물론 설계 능력 향상을 위한 노력은 매우 중요하죠. 수많은 책을 봤다는 분도 계시는데, 분명 도움이 될 것입니다. 그동안 쌓아온 많은 경험도 필수고요.

앞으로 계속 이에 대한 글들을 써보도록 하겠습니다.

위 글중의 일부는 제 책(소프트웨어 개발의 모든것)에서 인용했습니다.

각 블로그들의 인용문입니다.

저는 여전히 코더(coder)입니다~ by 써니

하지만, 분명하게 이야기 하고 싶은 것은 제가 매일 하고 있는 일은 코딩이지 설계가 아니라는 것입니다. 그 근거로서 말씀드리지요. 저희 회사에 개발자가 저 혼자 뿐입니다. 누구에게 지시를 내리고 할 위치가 아니라는 것입니다. 또한 코더와 아키텍트, 고수와 하수를 나누고 그들 사이에 편가르기를 시도하려고 하지도 않습니다. 편가르기를 하려면 어느 한 편에 서야만 하는데 저는 양쪽 위치에 다 서 있는 입장입니다. 개발을 하면서 프로젝트 매니저의 역할을 맡은 적도 몇번 있지만 그런 상황에서도 한번도 코딩을 손에서 놓은 적이 없습니다. 그러니까 지금도 코딩을 할 수 있는 것이죠. Software Design은 결코 쉬운 일이 아닙니다. 10년 20년을 개발했다고 해도, UML을 철저히 공부했다고 해도 여전히 어려운 것이 소프트웨어 디자인입니다. 실용주의 프로그래머, GoF의 디자인 패턴, Head First 시리즈, 아무도 가르쳐주지 않는 프로그래밍 설계 기법, XP 방법론, 리팩토링, Test Driven Development... 온갖 좋은 책을 다 읽어도 구구단을 쉽게 설계하는 법은 아무 책에도 나와 있지 않습니다. 즉, 현실 문제는 책에서 다루는 이상과는 달리 그 변화와 종류가 너무나 방대하기 때문에 정답을 얻기가 어려운 것입니다. 앞서 언급한 기술들과 그 기술들을 저술한 분들은 분명히 손꼽히는 대가인데도 말입니다.

  

꼭 그래야만 하는 이유

사실 Coder를 거치지 않는 Programmer, Architect는 존재하지 않는다고 봐도 무방합니다. 기본적인 Code에 대한 이해를 가지지 않고 그 일을 한다는 건(현실에서 ‘종종’ 있는 일입니다만..) 배재하고 이야기 해보겠습니다. Coder와 Programmer, Architect의 차이는 뭘까요? 남들 모르는 몇가지 알고리즘을 더 아는 것? 남들 모르는 지식 몇가지를 더 알고 있는 것? 그런 사소한 차이는 같은 Coder,Programmer 사이에 비일비재한 일입니다. 그런 것들로 Coder, Programmer, Architect 는 구분되지 않습니다. 그럼 (나름)구분 할 방법은 무엇일까요? 아니 사람들은 대체!! 어떤 기준으로 너는 Coder, 나는 Programmer! 이런 이야기를 하는 걸까요? 사실 저도 잘 모르겠습니다만… 위의 컨설팅 과정 중에 나온 여러가지 이야기들과 그간의 사람들과 대화를 나누며 격어본 경험들에 비추어 (여러가지로 표현가능하지만) 문제 인식의 차이라고 표현하고 싶습니다.

  

납득할 수 있는 설계를 어디서 배울 수 있을까?

업계에 설계전문 컨설턴트란 롤은 들어보지 못했다. 예로, 최근 설계에 대한 이슈를 안고 있는 대형 프로젝트가 두 개가 있는데.. 이례적으로 아키텍처가 상세하게 분화되서 분야별 아키텍트가 컨설턴트로 투입되었고, 솔루션 기반의 implementation consulting이라는 롤도 별도로 존재하고 투입되었다. 하지만 이런 환경임에도 설계 컨설팅은 없다. 별도 롤로 구분하지 않고 기술관련된 전반적인 문제들을 아키텍처 팀이나 그룹에 위임을 하는게 일반적인 프로젝트들의 전략이기 때문. 실제로 대형 프로젝트 아키텍처 팀이나 그룹은 그러한 이유로 팀사이즈가 꽤 큰 편.   그렇다면 프로젝트에서 누가 설계를 가이드해야 할까? 설계는 다분히 전략에 대한 내용들도 많고, 영향을 미치거나 받는 부분이 많다. 시간적으로도 일정 'phase'에 국한되지 않고, 특정 'discipine'에 한정되지도 않는다. 전략들을 설계로 모으고 드라이브 하는 사람은 방법론과 아키텍트. 아키텍처 적용이전은 방법론, 적용되는 시점부터는 아키텍트. 따라서 방법론, 아키텍트 둘의 긴밀한 협조로 설계를 일궈나가야 한다. 그렇지만, 200억, 500억대 프로젝트에서 아키텍트, 방법론 둘 다 빵꾸내기도 하는 이 현실은 완전 시궁창이지만서도..(먼산~)

  

꼭 그래야만 하는 걸까요?

너희 같은 하수는 평생 그렇게 코딩만 해라 나는 아키텍트의 길로 가련다... 하는 분들도 있을것 같네요. 예, 저는 하수 입니다. 당장 MFC나 위저드의 도움 없이는 Window도 제대로 생성하지 못하는 바보일 뿐이죠. 당장 개발해야 할 당면 과제는 COM 이나 CORBA 컴포넌트 제작이 아닌 제공되는 컴포넌트와 API를 이용한 어플리케이션 제작 입니다. 그렇다고 해서 삽질이나 하는 바보 개발자로 취급 받아도 좋은 걸까요? 훌륭하신 여러분들이 그렇게 무시하는 코더들은 그야말로 코드를 생산하는 위자드 보다도 못한 그런 사람들 일까요? 저는 잘 모르겠습니다. 그렇게 자기가 정한 기준에 맞지 않는 다른 사람들을 무시하는 풍토가 IT 업종의 3D화를 이뤄냈다고는 생각해본적 없으신가요?

소프트웨어 프로젝트는 누가 진행하는가?

http://skcho.com/58  

난 자율따위는 믿지 않는다. 긁적   2008/11/12 13:17

안녕하세요. 조성경님. Ray라고 합니다.

블로그에 쓰신 글을 보고 동감을 하면서 제 의견을 몇자 덧붙여 봅니다.

소프트웨어 프로젝트를 진행하기 위해서는 여러 전문가가 필요하죠.

프로젝트관리자도 전문가여야 하고, 개발자들도 소프트웨어 전문가여야 하고, 분석/설계/테스트/빌드/UI/Techpub 등 많은 전문가가 있어야 하죠.

물론 프로젝트 규모에 따라서 혼자서 이 모든 일을 다하는 경우도 있고, 수백명이 각각의 업무를 나눠서 하는 경우도 있습니다.

확실한 것은 혼자서 뚝딱뚝딱 만드는 것과는 다르다는 것이죠.

그런데, 우리는 전문적이지 못한 사람들이 모여서 프로젝트를 진행하는 경우를 허다하게 봅니다.

그런 이유는 간단합니다. 

그렇게 일을 해왔기 때문에 전문적인 지식을 배울 기회를 별로 보기 어렵고 그러다 보니 후배들에게 별로 가르칠 것이 없는 악순환이 계속 됩니다.

그래서 코딩 기술과 몇가지 Domain 지식만을 가지고 욹어 먹게 되는 경우가 많죠.

이런 기반이 잘되어 있는 회사에 들어가서 몇년 일하는 것만으로도 충분히 배울 수 있으나 그런 회사가 그렇게 많지 않는 것은 안타까운 일입니다.

조성경님이 경험했던 "소스보세요", "서버만들어" 이런 현상은 아주 흔합니다.

회사의 지식이 문서화 되어 있지 않고 소수의 머리속에 있고, 

소프트웨어 프로젝트를 진행하는데 가장 중요한 스펙의 중요성을 잘 모른 것이지요.

이 글에서 말하려고 하는 요지는 소프트웨어 엔지니어라면 단순히 코딩, 요소기술, Domain 지식에 매달리지말고, 소프트웨어 엔지니어로서 갖춰야 할 다양한 지식의 전문가가 되어야 한다는 것입니다.

제 책(소프트웨어 개발의 모든 것)에서도 이에 대한 내용을 상당히 다루고 있습니다.

앞으로 전문가로서 갖춰야 할 지식에 대해서 블로그에 계속 포스팅을 해나갈 겁니다.

감사합니다.

난 자율따위는 믿지 않는다. 긁적 10개월이 걸리는 프로젝트A가 있다고 하자. 프로젝트A를 10개월에 끝낼 수 있는 능력을 실제로 가진 10명을 모아 따로 프로젝트를 진행하게 한다. 조건은 다음과 같다. >> 어떠한 간섭도 없고 10개월 후 결과물을 보여준다. 10개월 후 제대로 프로젝트를 완료한 사람은 몇명이나 될까? 나는 많아야 한두명이 기대에 충족하는 결과를 내놓을 것이라고 본다. 실력이 모자란 사람은 없지만 자신을 관리할 수 있는 사람은 드물기 때문이다. 개인적인 경험에 의존한 결론이기는 하지만 당분간 이 생각을 바꿀것 같지는 않다. 내 경험과 다른 이들의 증언을 종합해보면 2~3개월 이상의 긴 일정을 툭 던져놓고 신경 끄는 관리자들이 있다. 이런 경우는 십중팔구 실패나 일정지연을 유발한다. 이때 실패는 작업자와 관리자중 누구의 잘못이 더 클까? 내 기준으로는 100% 관리자의 잘못이다. 만약에 이런 실패가 없다면 관리자는 존재 가치가 없다. 모든 조직에 관리자가 있다는 사실 자체가 스스로 뭔가를 알아서 하는게 쉽지 않다는 증거인데도, 이를 무시한다. 첫 회사에서 내가 받은 첫 주문은 "소스 보세요", 두번째 회사에서는 "서버 만들어"였다. 그래서 소스를 보고 고치고, 서버를 만들었다. 이 과정으로인해 나는 몇번의 큰 실수를 한다. 내가 그렇게 해왔으니까 남들도 그렇게 하면 되는 줄 알았고, 그렇게 못하는 남들을 제대로 이해하지도 못했다. 그리고 그렇게 하지 못하는 사람들을 낮게 평가했다. 지금 생각해보면 그냥 부끄러운 과거일뿐이고, 그 사람들에게 진실로 미안한 마음이 든다. 그때는 내가 미숙했다. 다시 프로젝트A를 진행하는 10명으로 돌아가보자. 프로젝트를 성공적으로 끝낼 한두명이 나머지보다 낫다는 점은 두말할 가치가 없다. 그러나 나머지 사람들이 쓸모없는 사람이냐라고 묻는다는 그건 절대 아니다. 단지 그들이 잘 못하는 부분이 들어났을 뿐이다. 좋은 관리자라면 그들을 이끌고 목표를 향해 나갈 줄 알아야하고, 경우에 따라서는 그들이 더 좋은 결과를 만들기도 한다. 왜 이런 구질구질한 얘기를 했냐면 오전에 있었던 엔진쪽 인원에 대한 평판 조회(reference check) 대답때문이다. 평가를 간단히 요약하면 엔진 연구하라고 했는데 1년이 넘도록 제대로된 결과를 만들지 못해서 해고했었다고 한다. 따져 묻고 싶은게 많았는데 그리 친한 사이도 아니라서 더 물고늘어질수는 없었고 잡다한 생각들이 들었다. 1년이 넘도록 결과물을 얻지 못했을 때 관리자는 뭘 했으며, 1년이 넘게 기다려야 했을까? 그 사람이 1년 넘는 기간동안에 진짜로 한 일은 뭘까? 이러한 생각에 대한 내 대답이 바로 이글이다. 계속 해고하면서 자기 스스로 관리가 가능한 스타 플레이어를 채용할 운을 시험해보는 것은 관리자 스스로가 무능하다는 자백과 다를게 없다. 그러니 이거 보세요, 분석하세요, 공부하세요 이런 말은 고만하자.