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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

share with abctech.software

코더(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화를 이뤄냈다고는 생각해본적 없으신가요?

개발자 100명을 더 투입한다면?

소프트웨어 회사에서 프로젝트를 진행할 때 흔히 벌어지는 문제가 "개발자가 부족해서 프로젝트가 늦어진다"는 것이다.

그럼 거꾸로 애플에서 날고 기는 개발자 100명을 투입시켜 줄테니 프로젝트를 제대로 끝낼 수 있냐고 물어보면 대부분 대답은 "글쎄요"다.

벽돌을 쌓거나 땅을 팔때는 사람을 2배 투입하면 대부분 시간이 반으로 줄어든다.

그런데 소프트웨어를 개발하는 프로젝트에서는 왜 그렇게 잘 안될까?

그 이유는 "스펙과 설계"에 있다.
빌딩을 세울 때는 설계가 명확하게 있다. 이 세상에 설계 없이 만드는 빌딩은 없을 것이다. 그리고 협업이 가능하도록 일이 세분화 되어 있고 전문화 되어 있다.

그런데 유독 소프트웨어(특히 우리나라)에서는 스펙과 설계가 땅파고 벽돌 쌓는 것보다 시원찮다. 그런 상태에서 개발을 하다보니 건설현장에서 빌딩 올라가듯이 개발이 되는 것이 아니고 뒤죽박죽이 된다. 이런 환경에 익숙해진 개발자는 뭐가 문제인지 인지하지 못하는 경우가 대부분이다.

스펙과 설계가 제대로 작성되어야 협업이 가능하다. 

여기서 핵심은 컴포넌트다. 컴포넌트가 일을 깔끔하게 나눠서 일할 수 있을 만큼 깨끗하게 나눠져 있어야 한다. 그래서 부서별, 개발자별로 일을 나눠서 할 수 있고 서로 인터페이스 맞추느라고 시간을 허비하지 않는다. 


스펙과 설계가 제대로 되지 않은 상태에서 개발을 하면 컴포넌트 단위로 일을 나눠서 할 수 없기 때문에 "화면"단위로 일을 나눠서 하기도 하고, 적당히 일을 나눠서 하다가 서로 겹치기도 하고 나중에 통합에 엄청난 시간이 걸리게 된다. 또한 어떻게 소프트웨어가 동작은 한다고 하더라도 그 아키텍처는 뒤죽박죽이 되어서 나중에 유지보수도 엄청나게 어렵게 된다.

그럼 스펙/설계 단계에서 어느 정도까지 설계가 이루어져야 할까?

대답은 의외로 간단하다.  스펙/설계의 결과를 가지고 소프트웨어 개발자들이 충분히 구현을 할 수 있을 정도면 된다. 여기서 "충분히"라는 단어는 몹시 애매하다.

문서만 보고 서로 전혀 대화를 하지 않고도 구현을 할 수 있으면 너무 자세히 적은 것이다. 이렇게 자세히 적으면 시간 낭비이고, 개발자에게 너무 자유도를 없앤 것이다. 

그럼 "충분히"는 어느 정도 일까?  개발자가 설계대로 구현을 하면서 약 5% 정도의 내용은 설계자나 관련된 컴포넌트 개발자와 서로 의논하면서 개발할 수 있을 정도면 적당하다고 할 수 있다. 너무 많은 내용을 의논하면서 구현시 결정해야 한다면 적은 내용이 너무 부족한 것이다. 따라서 "충분히"는 상황에 따라 다른 것이다.

설계가 부족하다면 프로젝트리더(테크니컬리더)는 여러 개발자에게 설명하느라고 시간을 보내고 자신이 담당한 개발을 할 시간이 부족해지고, 개발자들에게 설명을 소홀히 하면 개발자들이 제 멋대로 개발을 해와서 문제가 생기곤 한다. 나중에 이를 고치느라고 시간이 몇배로 낭비된다.

설계는 스펙을 작성할 때부터 시작이 되고 설계 단계에서는 컴포넌트가 다 구분되고 인터페이스가 정의가 되어서 소스코드 상에 모두 적히고 컴파일이 가능하도록 해야 한다.

그러기 위해서는 파일이름, Class이름, Public 함수 이름과 parameter, return값이 모두 정해져야 한다. 그리고 그 설명을 문서에 다는 것은 중복이기 때문에 Doxygen이나 Javadoc을 이용해서 소스코드에 주석으로 설명을 하면 효율적으로 설계 정보를 관리할 수 있다.

이렇게 설계가 완료되면 바로 Daily Build가 가능하며 구현 첫날부터 개발자들은 빌드가 가능한 소스코드에 자신이 맡은 컴포넌트의 내용을 채워나가면 되는 것이다. 즉, 첫날부터 이미 통합이 된 상태에서 개발을 하는 것이다.

이렇게 스펙과 설계를 작성하면 일정 산정의 정확도도 훨씬 올라가고 개발자를 더 투입하더라도 도움이 된다. 또한 외주로 개발하는 것도 가능하다.

물론 외주를 줄 경우에는 "설계"도 외주를 주는 경우가 많으므로 이런 경우는 "스펙"까지를 제대로 작성하면 된다.

이렇게 일을 효과적으로 나눠서 할 수 없다면 스펙/설계를 제대로 작성한 것이 아니다. 개발 시간과 비용도 줄일 수 있다. 가장 중요한 것은 프로젝트가 관리 가능한 상태가 된다는 것이다. 일정과 비용이 상당히 정확하게 예측 가능해지고 일정이 지연 상태를 빠르게 파악할 수 있고 대처를 할 수 있다.  스펙과 설계를 제대로 작성할 수 없다면 온갖 프로젝트 관리 기법은 다 소용없다. 결국 야근 밖에 남지 않는다.

"일을 나눠서 할 수 있다."는 것은 결국 개발자가 행복하게 일할 수 있도록 해준다.

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다.

그래서 설계에 대해서도 깔끔하게 정의를 해보자.
흔히 설계에 관한 다음과 같은 궁금증을 가지고 있다.
 

1. SW를 개발하는데 설계는 과연 필요할까?
2. 설계서는 작성할 필요가 있을까? SW는 설계서 없이 개발하는 것이 더 빠르지 않나?
3. 설계는 어떤 기법을 이용하는 것이 좋을까?
4. 설계툴은 UML을 꼭 이용해야 하나? 

일단, 설계를 하는 행위와 설계서를 작성하는 행위를 분리해서 생각하는 것이 좋다.

첫째, 우리는 설계서를 작성하든 하지 않든 "Hello world"를 제외하고는 설계 없이 개발하기 어렵다. 단지 단순한 것은 설계를 머리 속으로 할 뿐이다.

복잡하거나 여러 사람들이 서로 나눠서 개발을 해야 하는 경우는 머리 속으로만 설계를 하기란 거의 불가능하다. 천재라도 복잡한 시스템을 머리로 설계를 할 수 있지만 두뇌를 꺼내서 다른 사람에게 보여줄 수는 없는 일이다. 그래서 설계서를 작성하게 된다.

설계서 없이 개발이 가능한 경우는 극소수일 뿐이다. 

그럼 주변에서 보는 설계서 없이 개발하는 수많은 프로젝트는 무엇인가? 

대충 머리 속으로 설계를 해서 코딩을 하면서 서로 맞춰가는 것이다. 이런 식으로라면 재작업하는 일이 여러번 발생하게 되어서 오히려 시간이 더 많이 걸린다. 재작업 문제만 있는 것이 아니다.

설계는 필요한 만큼 해야 하고 거의 대부분은 문서화를 해야 한다.

즉, "Hello world"보다 복잡하거나 다른 사람과 나눠서 일을 하거나 다른 시스템과 인터페이스가 있을 경우는 설계를 적어야 한다.

설계 없이 만들어보려고 하는 것은 Software밖에 없을 것이다. 집, 빌딩, 전자부품, 애들 장난감 모두 설계가 있다. 

둘째, 설계는 어디에 적히는 것일까?

많은 설계는 소스코드와 중복이 되게 된다. 소프트웨어를 개발하는데 있어서 중복은 2배가 아니라 10배의 문제를 야기한다.  따라서 최대한 중복은 피해야 한다.

일단, 설계의 시작 부분은 스펙(SRS)에 적히게 된다. 시스템의 조망과 구조는 스펙의 가장 중요한 부분 중 하나이다. 이렇게 스펙에 설계를 적기 시작하면 스펙과 설계의 경계가 모호해지게 된다. 스펙과 설계의 경계는 따로 정해져 있는 것이 아니고 상황에 맞게 판단하면 된다.

라이브러리를 개발하는냐,  웹서비스를 개발하느냐,  게임을 개발하느냐에 따라서 그 경계는 달라질 수 있다.

보통의 경의 스펙에는 상위 설계 언저리 까지 적히는데 많은 프로젝트에서 설계는 이 정도만 적혀도 충분하다.

설계가 충분하지 아닌지 판단은 이 설계를 가지고 다른 개발자들이 나눠서 각자 개발을 할 수 있는지 생각해보면 된다. 그렇다면 스펙에도 어느 정도로 적히는지를 상상할 수 있을 것이다.

따라서 시스템의 크다고 하더라도 설계서가 별도로 없이 UI만 있어도 개발이 가능한 Web 등의 시스템은 스펙에 적히는 정도만 가지고도 개발이 가능하다.

이것으로도 부족하면 별도의 설계 문서를 만들기도 한다. 개발자가 수십명이상 참여하는 프로젝트에서는 대부분 별도의 설계서가 따로 있어야 할 만큼 시스템이 크다.  그런 경우는 설계서를 따로 만드는 것이 좋다.

셋째, 설계는 어떻게 해야 하는가? 무엇을 고려해야 하고 무엇을 적어야 하는가?

설계를 하는 방법에 대해서 고민을 하는 개발자는 매우 많다. 막상 회사에서 설계서를 만들라고 하면 막막하고 많은 경우 코딩을 다 하고 형식적으로 만드는 경우가 많다.

이런 경우는 설계도 제대로 한 것이 아니고 설계서도 엉망이다. 거의 쓸모 없는 문서를 시간을 더 들여서 만든 것이다. 나중에 유지보수에 필요하다고 하는데 유지보수에서 가장 많이 필요한 것은 소스코드와 스펙이다.

설계는 해당 프로젝트를 제대로 짧은 시간 안에 끝내기 위해서 하는 것이다. 또한 잘 된 설계는 미래에 발생할 여러가지 환경을 반영해야 한다. 이렇게 작성된 설계서라야 시스템과 일치를 하며 유지보수 시에도 유용하다.

설계의 기준이 되는 것은 스펙이다. 즉, 스펙이 제대로 적히지 않으면 좋은 설계가 나올 수 없다.

스펙이 없거나 기껏해야 기능명세만 적었다면, 설계는 아무리 잘해도 현재의 요구 기능이 동작하는 것에만 머물 것이다.

이 부분이 가장 중요하다. 수많은 회사들이 여기서 다 망쳐서 지금 그 고생들을 하고 있는 것이다.
스펙에 기능명세 뿐만 아니라 미래의 비즈니스 전략과 비기능 요구사항들이 모두 적혀야 있고 이를 설계에 반영해야 한다.

스펙이 이러한 내용들이 누락이 되어 있으면 설계가 어떻게 될지 상상해보라.

• 지금은 고객이 10개 회사인데 5년 안에 1,000개의 고객사를 확보할 것이다.
• 지금은 국내 판매를 대상으로 하는데 1년 후 부터는 세계 200개 회사를 대상으로 마케팅을 할 것이다.
• 현재의 시스템은 내년에 회사의 다른 시스템들과 통합하는 작업이 진행 될 것이다.
• 현재는 C/S 구조인데 2년 안에 Web을 지원해야 한다.
• 현재는 Windows만 지원하는데 1년 안에 MacOS, 2년 안에 iPhone과 Android 폰을 지원해야 한다.
• 지금은 모델이 3개지만 내년까지 100개의 모델이 5년 안에 5,000개의 모델이 생산될 것으로 예상된다. (사업이 잘 될 경우)
• 지금은 카메라 모듈을 한 가지만 지원하지만 5년 안에 100개 이상의 카메라 모듈을 지원해야 할 가능성이 80%이다.
• 현재 만든 Framework로 2년 안에 사내의 모든 TV의 Firmware를 교체할 예정이다.

위 예는 실제 현장에서 발생할 수 있는 수백만개 경우 중 몇 개일 뿐이다.

이러한 내용들이 설계에 적절히 고려되지 않는다면 미래에 큰 댓가를 치루게 된다. 이러한 것을 SW에 잘 반영하도록 설계를 하는 사람들을 Architect라고 부른다.

이런 것을 고려하지 않고 마구 어질러 놓고 인력만 많이 투입해서 엄청 비효율적으로 일을 하고 있으면 그 원인과 방법도 모른체 계속 똑같은 시행착오를 계속 반복할 가능성이 99%이다.

넷째, 특별한 툴을 이용하는 것이 좋은가?

 나는 설계를 위해서 특별한 툴이나 방법론을 선호하지 않는다. 하지만 툴가 방법론을 팔아먹는 사람들이 만병통치약처럼 선전을 한다.

좋은 워드프로세스를 쓴다고 좋은 소설이 안나오고 비싼 붓 쓴다고 그림 잘 그리는 것이 아니듯이 설계를 가장 잘 표현할 수 있는 툴을 알아서 쓰면 된다. 혼자만 이상한 것을 써서 다른 동료들이 편집하지 못하게 해서도 안된다.

설계의 핵심은 컴포넌트와 인터페이스를 적절히 나누고 표현하는 것이기 때문에 이것을 그릴 수 있으면 된다. 그냥 워드프로세서로 정리를 하는 경우가 많다.

하지만 설계를 하는 중간 과정에는 툴을 가지고 깔끔하게 정리를 하는 것은 시간 낭비이다. 설계가 끝날 때까지 설계는 전체를 뒤엎는 과정을 수차례 겪으므로 정리를 해 놓은 낭비이다.  큰 종이나 칠판에 적고 지우고를 반복하는 것이 좋다. 그렇게 거의 완성이 되면 옮겨 적으면 된다. 

심지어는 사진을 찍어서 이미지를 문서에 첨부하기도 한다. 이런 경우는 나중에 편집이 안되므로 적절히 사용해야 한다. 그래서 나는 조그만한 화이트보드에 설계를 하고 지우지 않고 관리를 하다가 나중에서 조금씩 수정하기도 한다.

그 외에 필요한 것은 설계자가 적절히 판단해서 시스템을 표현할 수 있는 그림이나 다이어그램을 그리거나 글로 적기도 한다. 여기서 창의성을 발휘해야지 규칙을 정해 놓고 따라하면 오히려 비효율적으로 변하게 된다.

디자인패턴 하나 배워서 모든 곳에 써먹는 것은 태권도 정권지르기 하나 배워서 그걸로만 싸우는 격이다. 분명히 도움은 되지만 상황에 맞게 적절한 방법을 창의적으로 생각해 내는 것이 가장 좋다. 그러기 위해서는 먼저 많이 알아야 하고 경험도 많아야 한다.

하위 설계는 소스코드와 중복이 되므로 그냥 소스코드로 작성하는 것이 좋다. Doxygen이나 JavaDoc을 이용하면 소스코드에서 필요한 설계 문서를 거꾸로 만들어 낼 수 있다.

결론

설계는 필요한 만큼 적절하게 꼭 해야 한다.

하지만 흔히들 문서화의 부담 때문에 아예 안하거나 적는 방법을 몰라서 너무 많이 적는다.
설계문서는 꼭 필요한 만큼만 적절하게 적어야 한다. 가장 어려운 말이지만 이 이상으로 표현하기는 어렵다.

설계서는 한 페이지가 될 수도 있고 수천 페이지가 될 수도 있다. 스펙이 이를 결정한다.

만약 제대로 된 스펙이 없다면 차라리 스펙을 제대로 적는데 먼저 신경을 써야 한다. 설계는 스펙 다음이다.

완벽한 WBS 체크리스트: 프로젝트 유형별 맞춤 가이드

"WBS 작성할 때 뭘 빼먹었는지 어떻게 알죠?"

이 질문을 하는 PM이라면, 아마 체크리스트가 없었을 겁니다.

프로젝트가 진행되면서 "아, 이것도 해야 했구나"라는 순간이 반복됩니다.
처음엔 간단해 보였던 프로젝트인데, 막상 진행하니 놓친 작업들이 줄줄이 나타납니다.
팀원들의 눈빛에서 당황이 보이고, 일정은 계속 밀립니다.

이 질문에 대한 답이 여기 있습니다.
수백 개의 프로젝트를 분석해 만든 프로젝트 유형별 완벽한 체크리스트입니다.

더 이상 "이것도 해야 했구나"라고 나중에 깨닫지 마세요.
처음부터 완벽하게 시작하세요.

웹 애플리케이션 프로젝트

기획/분석 단계 (15%)

□ 요구사항 수집 및 분석
  □ 이해관계자 인터뷰
  □ 사용자 스토리 작성
  □ 기능 명세서 작성
  □ 비기능 요구사항 정의

□ 기술 스택 선정
  □ 프론트엔드 프레임워크
  □ 백엔드 프레임워크
  □ 데이터베이스 선택
  □ 클라우드 서비스 결정

□ 프로토타이핑
  □ 와이어프레임 작성
  □ 목업 디자인
  □ 프로토타입 개발
  □ 사용자 피드백 수집

설계 단계 (20%)

□ 아키텍처 설계
  □ 시스템 아키텍처 다이어그램
  □ 데이터베이스 ERD
  □ API 설계 문서
  □ 시퀀스 다이어그램

□ UI/UX 설계
  □ 디자인 시스템 구축
  □ 컴포넌트 라이브러리
  □ 반응형 디자인 가이드
  □ 접근성 가이드라인

□ 보안 설계
  □ 인증/인가 전략
  □ 데이터 암호화 계획
  □ OWASP Top 10 대응
  □ 보안 감사 계획

개발 단계 (35%)

□ 환경 구축
  □ 개발 환경 설정
  □ Git 저장소 생성
  □ CI/CD 파이프라인
  □ 도커 컨테이너화

□ 프론트엔드 개발
  □ 라우팅 설정
  □ 상태 관리 구현
  □ 컴포넌트 개발
  □ API 연동
  □ 에러 핸들링

□ 백엔드 개발
  □ 데이터베이스 구축
  □ API 엔드포인트 개발
  □ 비즈니스 로직 구현
  □ 미들웨어 설정
  □ 로깅 시스템

□ 통합 작업
  □ 프론트-백 연동
  □ 외부 서비스 연동
  □ 결제 시스템 통합
  □ 알림 시스템 구현

테스트 단계 (15%)

□ 테스트 계획
  □ 테스트 케이스 작성
  □ 테스트 데이터 준비
  □ 테스트 환경 구축

□ 테스트 실행
  □ 단위 테스트
  □ 통합 테스트
  □ E2E 테스트
  □ 성능 테스트
  □ 보안 테스트
  □ 접근성 테스트

□ 버그 관리
  □ 버그 리포팅
  □ 버그 수정
  □ 회귀 테스트

배포 단계 (10%)

□ 배포 준비
  □ 프로덕션 환경 구축
  □ 도메인/SSL 설정
  □ 환경 변수 설정
  □ 백업 전략 수립

□ 배포 실행
  □ 데이터 마이그레이션
  □ 무중단 배포
  □ 롤백 계획
  □ 모니터링 설정

□ 배포 후
  □ 스모크 테스트
  □ 성능 모니터링
  □ 에러 추적
  □ 사용자 피드백 수집

운영/유지보수 (5%)

□ 문서화
  □ 사용자 매뉴얼
  □ API 문서
  □ 운영 가이드
  □ 트러블슈팅 가이드

□ 교육
  □ 사용자 교육
  □ 운영팀 교육
  □ 인수인계 문서

모바일 앱 프로젝트

추가 고려사항

□ 플랫폼별 개발
  □ iOS 개발
  □ Android 개발
  □ 크로스 플랫폼 고려

□ 앱스토어 준비
  □ 앱 아이콘/스크린샷
  □ 스토어 설명 작성
  □ 심사 준비
  □ 버전 관리

□ 디바이스 대응
  □ 다양한 화면 크기
  □ OS 버전 호환성
  □ 오프라인 모드
  □ 푸시 알림

AI/ML 프로젝트

특별 체크리스트

□ 데이터 준비
  □ 데이터 수집
  □ 데이터 정제
  □ 레이블링
  □ 데이터 증강

□ 모델 개발
  □ 모델 선택
  □ 학습 환경 구축
  □ 하이퍼파라미터 튜닝
  □ 모델 평가

□ MLOps
  □ 모델 버저닝
  □ A/B 테스트
  □ 모델 모니터링
  □ 재학습 파이프라인

레거시 마이그레이션 프로젝트

특수 작업

□ 현황 분석
  □ 레거시 시스템 분석
  □ 데이터 구조 파악
  □ 비즈니스 로직 문서화
  □ 의존성 맵핑

□ 마이그레이션 전략
  □ 빅뱅 vs 단계적
  □ 병렬 운영 계획
  □ 데이터 이관 전략
  □ 롤백 시나리오

□ 전환 작업
  □ 데이터 마이그레이션
  □ 기능 매핑
  □ 성능 비교
  □ 사용자 전환

공통 누락 작업 TOP 20

가장 자주 빼먹는 작업들:

1. 환경별 설정 관리
2. 에러 핸들링 및 로깅
3. 성능 최적화
4. 보안 검토
5. 브라우저/디바이스 호환성
6. 다국어 지원
7. 접근성 대응
8. 백업 및 복구
9. 모니터링 설정
10. 문서화
11. 코드 리뷰
12. 데이터 마이그레이션
13. 외부 서비스 연동 테스트
14. 부하 테스트
15. 라이선스 검토
16. GDPR 등 규정 준수
17. SEO 최적화
18. 캐싱 전략
19. 롤백 계획
20. 인수인계 및 교육

이 작업들을 미리 체크하면 프로젝트 중반에 당황하지 않습니다.

프로젝트 규모별 조정 가이드

소규모 (1-2개월)

건너뛸 수 있는 작업:

• 프로토타이핑
• 부하 테스트
• A/B 테스트

간소화할 작업:

• 문서화 (핵심만)
• 테스트 (주요 경로만)

반드시 포함할 작업:

• 기본 보안
• 에러 핸들링
• 백업

중규모 (3-6개월)

전체 구현:

• 모든 기본 체크리스트
• 자동화 테스트
• CI/CD

고려할 작업:

• 성능 최적화
• 모니터링

대규모 (6개월 이상)

추가 작업:

• 아키텍처 리뷰 보드
• 보안 감사
• 성능 벤치마킹
• 재해 복구 계획
• 컴플라이언스 인증

체크리스트 활용법

Step 1: 프로젝트 유형 선택

웹앱, 모바일, AI/ML, 마이그레이션 중 선택하세요.
복합 프로젝트의 경우 여러 유형을 조합할 수 있습니다.

Step 2: 규모 조정

프로젝트 규모(소규모/중규모/대규모)에 맞게 체크리스트를 조정하세요.
기간과 팀 규모도 고려해야 합니다.

Step 3: 커스터마이징

클라이언트 요구사항(GDPR, ISO27001 등), 기술 스택, 특수 요구사항(실시간 처리, 다국어 등)에 맞게 커스터마이징하세요.

디지털 체크리스트 템플릿

체크리스트를 디지털로 관리하면 더 효율적입니다.

템플릿 구조:

• 프로젝트 정보: 이름, 유형, 규모
• 단계별 작업: 기획, 설계, 개발, 테스트, 배포, 운영
• 각 작업: 이름, 상태, 담당자, 소요 시간

이런 구조로 관리하면 누락 없이 프로젝트를 진행할 수 있습니다.

핵심 정리

완벽한 체크리스트는 없습니다.
하지만 계속 진화하는 체크리스트는 있습니다.

체크리스트 진화 프로세스:

1. 이 체크리스트로 시작
2. 프로젝트 중 발견한 작업 추가
3. 회고에서 놓친 작업 기록
4. 다음 프로젝트에 반영

이렇게 당신만의 완벽한 체크리스트가 만들어집니다.

다음 프로젝트부터 이 체크리스트를 활용해보세요.
작은 노력이 큰 차이를 만듭니다.

---

프로젝트 유형별 맞춤 WBS와 체크리스트가 필요하신가요? Plexo를 확인해보세요.