[Software Spec Series 2] 소프트웨어 프로젝트 실패의 원인

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

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

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

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

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인은 “스펙”이다. 가장 많은 원인이 스펙과 관련이 있다. 또한 소프트웨어 버그의 절반 이상은 스펙으로부터 발생한다고 알려져 있다.

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

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

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

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

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 소프트웨어 프로젝트 성공은 어렵다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다. 꾸준히 투자하는 방법 외에 기가 막힌 방법은 없다.

share with abctech.software

[Software Spec Series 1] 머릿말

소프트웨어 프로젝트에서 가장 중요한 것은 스펙을 작성하는 일이다. 가장 어려운 것도 스펙을 작성하는 일이다.

프레드릭 브룩스는 이렇게 말했다. "소프트웨어 개발에 있어서 가장 어려운 일은 개발 자체가 아니라, 무엇을 개발할지 결정하는 일이다." 이 말은 과거에도 유효했고, 현재도 유효하고, 미래에도 유효하다.

소프트웨어 프로그래머는 인공지능으로 대체될 가능성이 매우 높은 직업이다. 하지만 소프트웨어 스펙을 작성하는 분석 아키텍트는 인공지능으로 대체될 가능성이 가장 낮은 직업 중 하나다. 아무리 인공지능이 발전을 해도 스펙을 대신 작성해주는 세상이 올 가능성은 거의 없다. 그래서 스펙을 작성하는 일은 어렵지만 더욱 가치가 있다.

스펙을 잘 쓰는 방법을 정립해 놓은 것을 요구공학(Requirement engineering)이라고 한다.

공학이라고 하면 왠지 이론적인 것으로 생각된다. 하지만 공학은 실전에 비롯되었다. 과학을 현실에 적용하면서 과학과 현실의 간극을 메꿔주는 것이 공학이며 현실에서 벌어진 문제를 해결하면서 공학은 발전을 해 나간다. 즉, 이론적인 뒷받침도 있지만 공학은 실전이 먼저다. 요구공학도 이론적인 연구가 많이 되어 있지만 실전을 기반으로 발전되어 왔다. 하지만 현대의 요구공학은 이론적인 연구도 상당히 많이 더해져서 내용이 상당히 방대해졌다.

이런 방대한 요구공학 이론을 보고 왠만한 소프트웨어 회사에서 배우고 따라한 다는 것은 거의 불가능하다. 피아노 백과사전을 보고 피아노를 배우는 것과 비슷할 것이다. 아직 소프트웨어 공학이 내재화 되지 않은 소프트웨어 회사에서 요구공학 이론을 적용하는 것은 의미 없는 몸부림이다. 그렇게 한다면 오히려 주먹구구식 개발보다 효율이 떨어지는 것은 시간 문제다. 실제 우리나라의 많은 소프트웨어 회사들이 겪고 있는 문제다.

요구공학 즉, 스펙을 잘 작성하는 방법은 가르칠 수는 있는데, 배울 수는 없다. 무슨 뚱딴지 같은 소리인가 할 것이다. 하지만 이를 다른 분야의 예를 들면 바로 이해가 된다. 피아노를 잘 치는 방법을 가르칠 수는 있어도 그렇게 배워서는 피아노를 잘 칠 수 없다. 골프를 잘 치는 방법을 가르칠 수는 있어도 그렇게 해서는 골프를 잘 칠 수 없다. 가르치는 것이 의미는 있지만 피아노를 잘 치고, 골프를 잘 치려면 훈련을 해야 한다. 1,2년이 아니고 수년 이상 훈련을 하면서 코칭을 해야 비로소 피아노를 잘 치고, 골프를 잘 칠 수 있다. 코딩을 배우는 것과는 매우 다르다.

그래서 요구공학 책은 많아도, 책을 보고 배워서 스펙을 작성해도 실력이 잘 늘지 않는다. 특히나 이론에 아주 충실한 책들은 아무리 좋은 책이라고 하더라도 현실에 적용하기는 더욱 어렵다. 회사 경영진들은 대부분 매우 조급하다. 꾸준히 투자하고 훈련하면 10년 걸릴 일을 1,2년 안에 성과를 내려고 한다. 피아노 1,2년 안에 늘 수 있는 실력에 한계가 있듯이 스펙을 작성하는 것도 그렇게 빨리 성과가 나지는 않는다. 서두르다가는 오히려 역효과만 난다. 그래서 많은 회사에서 스펙 작성 역량 확보에 실패한다. 그리고 해봤더니 안되더라. 요구공학은 엉터리라고 한다. 피아노 1,2년 연습하고 쇼팽의 곡을 못 친다고 실망하는 것과 비슷하다.

스펙을 잘 작성하기 위해서는 실전에 따른 노하우의 축적이 필요하다. 노하우 백과사전을 만들어서 봐도 배울 수는 없다. 노하우는 스스로 현실에서 익히는 것이다. 그래서 경험이 중요하다. 단, 잘못된 방법으로 시도한 경험으로는 좋은 노하우 축적이 안된다. 오히려 왜곡된 생각이 쌓인다. 그래서 좋은 코치가 필요하다. 코치와 같이 실전 프로젝트를 수행하면서 스펙을 직접 써보고, 피드백을 받아야 한다. 피아노, 골프 모두 같은 방식으로 배운다. 스펙을 작성하는데 있어서 일반적인 코치는 회사의 고참 개발자, 경력이 많은 분석 아키텍트다. 하지만 우리나라 소프트웨어 회사에서는 그런 역량이 있는 선배를 찾아보기 힘든 것이 현실이다. 그래서 코칭을 제대로 받을 수가 없다.

스펙을 작성하는 기법만 알아서는 스펙을 잘 쓸 수 없다. 개발 문화, 관행, 습관, 프로세스, 원리, 원칙을 알고 접근해야 한다. 앞으로 시리즈 글에서 스펙을 잘 작성하는데 필요한 모든 분야를 다룰 것이다.

운동은 원리를 몰라도 코치가 가르쳐주는 대로 무조건 반복 훈련을 해도 성과를 내고 경지에 오를 수도 있다. 하지만 소프트웨어 개발은 원리를 모르고 기계적으로 따라해서는 제대로 발전하기 어렵다. 오히려 엉뚱한 함정에 빠져서 고치기 힘든 나쁜 습관이 몸에 베일 수 있다. 그래서 원리를 아는 것도 배우 중요하다. 그래서 앞으로 원리를 이해하는데 도움이 되는 많은 얘기를 할 것이다.

소프트웨어 개발은 “적절히”가 매우 중요하다. “적절히”를 제대로 이해하는데 10년, 20년 걸린다. 피아노, 골프도 마찬가지다. 처음부터 완벽하게 이해하려는 것은 욕심이다. 시행착오를 거치면서 원리를 하나씩 깨우칠 때 “적절히” 하는 노하우를 하나씩 터득할 수 있다. 이 시리즈를 통해서 노하우를 터득해 나가보자.

share with abctech.software