All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. RSS Feed



프로젝트가 끝난 후에 산출물을 만드는 일은 SI회사나 용역으로 일을 하고 있는 회사에서 종종 보게 됩니다. 또, 자사 Solution이나 Product를 만드는 회사에서도 이런 일들이 벌어지곤 하죠.

이런 회사에서 그렇게밖에 할 수 없는 이유에 대해서 다음과 같이 말을 하곤 합니다.

• 우린 프로젝트 일정이 너무 짧아서 프로젝트 기간에는 산출물을 만들 시간이 없어요.
• 어차피 산출물은 프로젝트에 별 도움이 안돼요.
• 우리도 시간만 충분히 있으면 산출물을 잘 만들 수 있어요.
• 고객이 나중에 요구사항을 바꾸기 때문에 산출물을 잘 만들어 놓아도 또 바꿔야 해요. 코드만 바꾸기도 벅찬데 언제 산출물을 바꿔요.
• 산출물이란 프로젝트가 끝나고 더 이상 바뀔게 없을 때 한꺼번에 만드는 것이 제일 효율적이예요.
• 문서를 너무 많이 만들어야 해요.

여러분도 위 이유에 고개가 끄덕여지시나요?

그렇다면 여러분도 그 동안의 소프트웨어 개발 관행에 익숙해져 있는 것이고, 제대로 된 소프트웨어 개발방법을 익힐 기회를 접한 적이 없었을 겁니다.

위에서 언급한 각 이유(핑계)에 대해서 설명을 해보죠.

• 우린 프로젝트 일정이 너무 짧아서 프로젝트 기간에는 산출물을 만들 시간이 없어요.
• 거의 모든 프로젝트는 일정이 넉넉하게 주어지지 않습니다. 따라서 프로젝트 일정이 짧다는 것은 이유가 되지 않습니다.
• 일정이 짧다는 것은 상대적인 것으로 기존에 개발하던 방식으로 개발을 할 생각을 하니 기간이 짧다고 할 수도 있습니다.
• 소프트웨어 공학이라는 것은 짧은 시간에 적은 비용으로 소프트웨어를 개발하기 위한 것이 목적입니다.
• 소프트웨어 공학은 기계적으로 적용해서는 안되고, 일정이 절대적으로 짧다면 그에 따라서 효율적으로 적용하여 일정을 단축할 수 있도록 해야 합니다.

• 어차피 산출물은 프로젝트에 별 도움이 안돼요.
• 가장 안좋은 이유입니다.
• 프로젝트 팀원간 또는 관련자들과의 커뮤니케이션은 문서(산출물)로 하는 것입니다. 문서는 종이로 되어 있을 수 있고, DB에 저장되어 있어서 Web을 통해서 볼 수도 있을 겁니다. 그런데 문서가 아닌 구두로 대부분의 커뮤니케이션을 하고 있다면 휘발성인 말들이 사라져 버려서 대단히 비효율적으로 프로젝트를 진행하고 있는 겁니다.

• 우리도 시간만 충분히 있으면 산출물을 잘 만들 수 있어요.
• 이는 대단한 착각입니다.
• 산출물을 제대로 만들었다면 그 산출물을 보고 멀리 떨어져 있는 사람이라도 설계도 하고 구현도 할 수 있어야 합니다. 하지만 대부분 그 정도 수준의 산출물을 만들어 낼 수 없죠. 이는 시간이 없어서 산출물을 못 만든다는 핑계로 자신을 방어하는 것입니다.
• 문서를 제대로 만들어본 적도 없이 어느날 갑자기 잘만들어 낼 수는 없습니다. 이는 제대로 된 교육과 훈련이 필요합니다.

• 고객이 나중에 요구사항을 바꾸기 때문에 산출물을 잘 만들어 놓아도 또 바꿔야 해요. 코드만 바꾸기도 벅찬데 언제 산출물을 바꿔요.
• 이 세상의 모든 고객은 요구사항을 자꾸 바꾸려고 합니다. 고객은 소프트웨어 프로젝트에서 요구사항을 바꾸는 것이 얼마나 큰 일인지를 잘 모릅니다.
• 초기의 요구사항 분석이 충실하지 않을 경우 고객은 뒤늦게 요구사항을 바꾸려고 합니다.
• 고객이 요구사항을 바꾼다는 이유 뒤에 숨지 말고 고객이 요구사항 변경 요청을 최소화 하기 위해서 요구사항 분석에 최선을 다해야 합니다. 요구사항 분석에 대해서는 나중에 다시 언급하기로 하죠. 요구사항 분석이 끝나면 가능하면 산출물에 고객의 서명을 받는 것이 좋습니다. 설령 서명을 하지 않더라도 서명의 압박을 가하는 것이 좋고 산출물을 고객이 충분히 이해하도록 해야 합니다. 고객이 이해하기 어렵다면 UI 프로토타입을 만들어서 고객이 이해할 수 있도록 해야 합니다.
• 요구사항 변경에 따른 파급효과를 고객에게 충분히 설명해야 합니다. 그럼에도 불구하고 막무가내로 요구하는 고객도 있지만 별로 중요하지 않은 기능의 변경으로 프로젝트에 타격이 클 경우 고객이 요구사항 변경을 포기하는 경우도 많습니다.

• 산출물이란 프로젝트가 끝나고 더 이상 바뀔게 없을 때 한꺼번에 만드는 것이 제일 효율적이예요.
• 산출물을 너무 많이 만들기 때문에 이런 일이 발생합니다.
• 산출물이란 주로 프로젝트를 진행하기 위해서 필요한 것인데, 끝나고 만들면 기껏 유지보수를 위한 정보밖에 되지 않습니다.
• 위에서 언급한 것과 같이 변경을 최소화하기 위해서 노력을 해야 하고, 중복된 산출물은 가급적 없어야 합니다.
• 그리고 변경에 따른 산출물의 변경도 최소화를 해야 합니다.

• 문서를 너무 많이 만들어야 해요.
• 고객이 많은 산출물을 요구하는 경우라면 어쩔 수가 없습니다. 가능하면 불필요한 산출물을 없애도록 고객을 설득하는 것이 좋습니다. 그래도 만들어야 하는 불필요한 산출물에는 큰 노력을 들여서는 안됩니다. 이런 산출물들이야 말고 프로젝트 끝나고 기계적으로 만들어도 됩니다.
• 자체 프로젝트를 진행하는 경우라면 프로젝트 성격에 따라 다르겠지만, 산출물의 개수는 최소화 해야 합니다. 그래야 중복이 없어지고, 최신 버전으로 업데이트가 가능해지고, 커뮤니케이션 도구가 됩니다.
• 문서를 잔뜩 만들어 놓으면 정보가 어디에 있는지 알 수가 없어서 백과사전처럼 되고 맙니다. 어딘가에는 정보가 있지만 찾기가 어려워서 찾기를 포기할 수도 있습니다.
• 꼭 필요한 몇 개의 문서만 만들어야 합니다.

물론 위에서 언급한 상황이 아닌 다른 진짜 이유도 있을 수 있습니다. 그 모든 상황에 대해서 위와 같이 주장하는 것은 아니고 일반적인 경우를 설명하는 것입니다.

우리 주변에는 수많은 소프트웨어 개발 방법론이 있고 이를 기계적으로 따르다 보니 효율적으로 적용을 하지 못하고 너무 많은 문서을 만들고 프로세스를 따르는 것을 종종 보게 됩니다. 이는 방법론에 대한 오해에서 비롯된 것입니다. 프로젝트의 규모에 알맞게 방법론을 선택해야하고 꼭 필요한 문서만 만들고 절차도 간소화 할 수 있습니다. 어떤 것은 꼭 해야 하고 어느 것은 생략할 수 있는지가 어려운 문제이기는 합니다. 이를 알려면 좀더 많은 경험이 필요하겠지요.

image by Microsoft Office Online

전규현 소프트웨어이야기 산출물