한빛출판네트워크

✅정말 설계가 필요한가

최근 시스템 개발에서 설계가 불필요하다는 의견이 많아지고 있습니다. 특히 스크럼 개발이나 XP를 비롯한 애자일 개발 방법론이 주목받기 시작하면서 이러한 의견이 두드러지게 나타나고 있습니다. 

제 주변에는 설계가 불필요하다고 생각하는 사람도 있고 필요하다고 생각하는 사람도 있습니다. 다만 두 진영 모두 설계가 필요한지를 깊이 고민하기보다는 각자의 과거 경험을 바탕으로 판단하는 경우가 많은 것 같습니다.

설계를 생략할 수 있는 조건의 개발 프로젝트를 많이 경험한 사람은 설계가 불필요하다고 말합니다. 반면 워터폴로 개발을 많이 해본 사람은 설계를 하지 않는 것은 상상도 할 수 없다고 말합니다. 

여기서 중요한 것은 여러 종류의 애자일 개발 방법론이 있지만 ‘문서를 전혀 작성하지 않는다’는 방법론은 거의 없다는 점입니다. 어디까지 문서를 작성할 것인가는 상황에 따라 다릅니다. 커뮤니케이션을 활발하게 하면서 소스 코드나 테스트 프로그램도 중요한 설계서 중 하나로 취급하기도 합니다. 

애자일 개발 방법론에 대해 아직도 많은 오해가 남아 있지만 찬반을 논할 생각은 없습니다. 애자일 개발 방법론에는 배워야 할 것이 많으니 조건이 맞는다면 애자일 개발을 하는 것도 좋습니다. 

맹목적으로 설계를 하던 과거에서 현대로 넘어오는 문을 애자일 개발 방법론이 열어줬다고 생각합니다. 이번 장에서는 애자일 개발 방법론이든 다른 방법론이든 시스템 개발이라는 동일한 목적을 달성하기 위해 설계가 필요한지, 필요하지 않은지를 살펴보겠습니다.

✅설계는 불필요하다는 주장 

그렇다면 설계가 불필요하다고 주장하는 이유는 무엇일까요? 대표적인 의견을 정리하면 다음과 같습니다.

이 의견들 중에는 수긍이 가는 것도 있고 미심쩍은 내용도 있을 것입니다. 다만 쓸데없는 설계를 하고 있는 개발 프로젝트는 실제로 존재합니다. 또한 문서가 없어져 엉망진창이 되어버린 개발 프로젝트도 있습니다. 필요한 것은 낭만적이고 단순한 논의가 아닙니다.

설계는 필요한가, 필요하지 않은가. 결론을 말하자면 설계는 필요하기도 하고 필요하지 않기도 합니다. 그렇다면 필요하지 않은 쪽이 더 좋을 것입니다(일이 하나 줄어드니까요). 

설계의 필요 여부는 개발 프로젝트에 따라 다릅니다. 이어서 설계가 필요한 이유와 설계가 필요 없는 이유를 알아보고 설계가 필요 없는 조건을 정리해보겠습니다

✅설계가 필요한 이유 

설계의 필요 여부는 설계를 당연하게 생각하는 사람 입장에서는 논할 가치가 없는 것일 수도 있습니다. 소프트웨어 공학처럼 시스템을 만드는 기술을 대상으로 하는 학문이 있을 정도니 ‘설계 없이 소프트웨어 공학이 성립할 수 있을까?’라는 의문이 드는 것은 당연합니다. 공학이라는 이름을 가진 분야에서 설계가 불필요하다는 논의가 있다는 것 자체가 놀라울 수도 있습니다.

공학에서 설계는 대상물을 만들기 위한 방법이자 기술입니다. 소프트웨어 공학 역시 소프트웨어 시스템을 개발하는 방법을 연구합니다. 이러한 관점에서 보면 설계가 필요하다고 생각하는 것이 자연스럽습니다. 어떤 대상 시스템을 만들기 위한 노하우가 바로 설계입니다. 설계를 재사용하면 동일한 결과물을 다시 만들 수 있습니다.

그러나 소프트웨어 공학과 다른 공학들 사이에는 큰 차이가 있습니다. 소프트웨어 개발은 매번 다른 것을 만들어야 한다는 점입니다. 똑같은 것이라면 복사하면 되지만 소프트웨어를 개발할 때는 (적어도 개발자는) 매번 새로운 것을 만들어야 합니다. 

기계공학의 엔진이라면 설계서가 있기 때문에 동일한 엔진을 여러 번 만들 수 있습니다. 설계서가 없으면 시제품만 만들고 끝나버립니다. 보통 엔지니어링 분야에서 설계서는 동일한 것을 만들기 위한 목적을 갖지만, 소프트웨어에서의 설계서는 단 한 번의 주문 제작을 위해 사용됩니다. 다시 말하지만 시스템을 만드는 데 본질적으로 설계가 필요하면 설계를 해야 합니다. 그러나 설계가 불필요하다면 하지 않는 것이 더 낫습니다. 

설계서에는 목적이 또 하나 있습니다. 바로 개발자 간의 정보 공유입니다. 더 나아가 개발이 끝난 후 시스템이 개발팀의 손을 떠났을 때, 유지보수 담당자에게 기능 확장이나 유지보수를 위한 정보를 제공합니다. 시스템이 개발되면 사용자 기업에 인도되어 운영이 시작됩니다. 아무런 문제가 없으면 좋겠지만 실제로 운영을 시작하면 부족한 기능이나 시스템 버그가 발견됩니다. 이는 결코 바람직한 상황은 아니지만 발생 가능성을 없앨 수는 없습니다. 

기능 확장이나 유지보수 개발이 필요할 때, 처음 시스템을 개발한 개발팀은 해체되는 경우가 많습니다. 물론 하자담보책임 같은 것도 있지만 반드시 최초 개발팀 구성원이 개발할 수 있는 것도 아닙니다. 그럴 때 설계서가 아무것도 남아 있지 않으면 시스템 분석부터 시작하게 됩니다. 설계서가 있다면 이를 단서로 삼아 개발을 시작할 수 있습니다. 

앞서 설명한 설계의 목적을 정리하면 다음과 같습니다.

이 가운데 두 번째 ‘시스템 기능을 검토’하는 것은 불필요하다고 볼 수 없습니다. 시스템 기능을 모르면 무엇을 만들어야 할지 알 수 없기 때문입니다. 설계가 불필요하다는 것은 이러한 목적이 불필요하거나 다른 수단으로 이러한 목적을 달성할 수 있다는 것을 의미합니다.

사실 애자일 개발 이외의 많은 개발 프로세스에는 설계 프로세스가 있습니다. 명칭이나 방법론에 약간의 차이는 있지만 설계를 하는 것에는 변함이 없습니다. 워터폴, RUP^{Rational Unified Process} 등이 그렇습니다. UML은 설계를 위한 표기법이기도 합니다. 객체지향은 프로그래밍 방법인 동시에 설계 방법이기도 합니다. 클래스 다이어그램이나 시퀀스 다이어그램이 유용하다는 점은 말할 필요도 없을 것입니다.

기능 구현을 넘어 전체 시스템을 조망하며 설계 역량을 강화하는 방법

설계는 구현을 위한 준비 작업입니다. 즉 기능을 구현하기 위해서는 올바른 설계가 필요합니다. 이 책은 유스케이스 분석, 개념 모델링, 시스템 아키텍처 등 소프트웨어 설계에 필요한 이론을 폭넓게 다룹니다. 부분적인 기능 개발에서 시스템 설계에 이르기까지의 과정을 구체적인 사례와 함께 설명합니다. 소프트웨어 설계 경험이 많은 고연차 개발자라면 설계에 대한 다양한 관점과 사례들을 정리하고 개발 방식을 되돌아보는 계기가 될 것입니다. 

경험이 적은 저연차 개발자라면 과거와 현재의 설계를 알아보고 설계 과정 전반을 경험하며 기본을 다질 수 있습니다. 이 책이 소프트웨어 설계 기본 원리를 익히는 데 주춧돌 역할을 할 것입니다.