책 리뷰 : 소프트웨어 스펙의 모든 것

소프트웨어 스펙의 모든 것

 

스펙이란 무엇인가? 양복을 만드는 재단사에게 치수나 어깨너비, 사이즈 등이 적힌 "스펙"이 있다면, 모두가 똑같은 양복을 만든다. 반면 소프트웨어는 어떤가? "스펙"을 적어서 개발자에게 주면, 어떻게 될까?

 

이 책은 전반적으로 스펙에 대한 이야기를 말한다. 소프트웨어를 어떻게 만드는지, 무엇을 만드는지 그러한 방법들에 대해 기술한 문서를 SRS(Software Requirements Specification)이라고 하며, 왜 SRS가 필요한 지에 대해서 책의 중후반까지 설명하고, 2부는 SRS를 작성하는 목차에 대해서 설명하는 것으로 마무리한다.

 

책 소개

이 책의 주제 및 목표는 소프트웨어를 개발할 때, 어떻게 만들 것인지 구성하는 것 "스펙"은 어떤 것인지에 대해서 아주 자세하게 상술한다. 일반적으로 개발자라면 여러 상황에서 API 스펙을 달라거나, 서버 스펙이 어떻게 되냐는 이야기를 듣거나 한 적이 있을 것이다. 이 책에서는 스펙이란 무엇인지에 대한 자세한 고찰부터, SRS라는 스펙을 적는 문서가 필요한 이유에 대해서 다룬다.

 

최근 개발자를 소프트웨어 엔지니어라고 부르는 추세인 것 같다. 소프트웨어 엔지니어와 건물을 짓는 건축가와 비슷하다는 생각을 많이 한다. 5층짜리 건물을 짓는다고 가정하자. 조립식 건물이 아닌 이상, 1층부터 쌓아 올려 5층까지 만드는 것이 건축이다. 하지만 소프트웨어는 어떨까? 미리 각자의 층을 만든 다음 한 번에 조립할 수 있다. 이 방법이 가장 좋다고 생각하는가?

 

이 책은 조립식보다도 더욱 좋은 방법은 먼저 1층과 5층까지의 골조를 만들어 서로간의 맞물리는 부분을 인터페이스로 정의하여, 병렬적으로 작업할 수 있다는 것이다. 결국 가장 중요한 것은 골조를 만드는 것이다. 골조는 곧 스펙, 이러한 스펙을 만드는 가이드라인을 제시한다.

 

이 책을 읽으면 좋은 대상

컴퓨터공학이나 소프트웨어 관련 전공자라면 학교에서 소프트웨어공학이라는 강의를 수강한 적이 있을 수 있다. 혹은 정보처리기사라는 자격증을 공부하다보면, 이론 서적을 폈을 때 첫 장부터 이야기하는 것이 방법론이다. 애자일 방법론, 나선형 모델, 프로토타입 모델 그리고 폭포수 모델 등 다양한 방법에 대해서 다룬다.

 

정보처리기사 시험에서도 애자일 방법론에 대해서 큰 비중으로 다루고, 최근 개발 방법론 중에서 애자일 방법론이 유명하다는 것은 다들 알고 있을 것이다.

• 한국어판 애자일 선언 : https://agilemanifesto.org/iso/ko/manifesto.html

애자일 선언문 번역

 

그리고 개발을 직접 하면서, 여러 번 기획이 변경되고 스펙이 바뀌면서 일정은 지연되고 결국 "소프트웨어는 한 번에 설계대로 만들 수 없다"라는 마음가짐을 갖게 된다. 하지만 이 책은 그러한 것을 꼬집으며, 정교한 스펙을 통한 철저한 설계를 통해 소프트웨어를 만드는 것이 가장 빠르며, 높은 품질의 소프트웨어를 만들 수 있다는 것을 재차 강조한다.

 

나 또한, 애자일 방법론이 트랜디하며, 소프트웨어 개발을 통해서 발생하는 많은 문제들은 애자일 방법론으로 해결할 수 있다고 믿었다. 하지만 이 책에서는 그보다 더 중요한 설계, 즉 스펙의 중요성을 강조하며 애자일 방법론으로 변화무쌍하고 주먹구구식으로 개발하는 것보다 스펙을 제대로 작성하고 개발하는 것이 더 빠르며, 품질이 좋다고 설명한다. 나는 이 부분에서 머리를 한 대 세게 맞은 듯 했다.

 

 

또한, 이렇게 진부하게 교과서에서 나올 법한 폭포수 모델에 대해서 설명하지는 않는다. 이 책의 중점은 폭포수 모델이 아니라, 스펙이란 무엇인가에 대한 것으로, 과감하게 1970년대에 제안된 폭포수 모델에 대해서 설명하기보다는 현대 방식에 맞춘 Jira나 Redmine 등을 사용하여 어떻게 스펙을 작성할 수 있는가에 대해서 이야기한다.

 

또한, 스펙에 대한 이야기가 끝나갈 무렵에는 문서 작성의 중요성을 재차 강요하며, 글을 잘 쓰는 개발자가 중요하다는 것을 강조한다. 이 책이 쓰일 시점에는 ChatGPT같은 LLM이 없던 시절이지만, 최근에 대부분의 반복적인 작업은 AI가 대체하기 때문에, 소프트웨어 엔지니어라면 스펙을 작성하는 것에 좀 더 중점을 둬야 한다. 이 책은 이러한 설계나 스펙에 대해 얼마나 중요한 지 모르는 사람에게 권하고 싶다.

 

 

책의 장점과 아쉬운 점

개인적으로 가장 좋아하는 서술 방식으로 책이 쓰여있다. 무언가에 대해서 설명할 때, 두괄식으로 볼드체로 포인트를 준 후에 그 및에 한 문단으로 부연 설명으로 깔끔하게 정리를 해둔다. 두괄식 표현으로 깔끔하게 쓰여있기 때문에 맥락을 보다 쉽게 파악할 수 있다.

 

뿐만 아니라, 네거티브 방식으로 스펙의 장점을 말하는데, 단순히 '스펙을 쓰는게 좋다'라고 말하지 않는다. '스펙을 쓰지 않으면 이렇게 된다'라는 내용이 책에 전반적으로 쓰여있기 때문에 책을 읽고 나면 더욱 기억 속에 남는다. 나는 이러한 네거티브 방식으로 쓴 책을 좋아하는 편이며 기억에도 많이 남는다.

SRS의 목차 예시

 

아쉬운 점은 한 가지 정도 떠오르는데, 스펙 문서가 정확하게 어떻게 생겼는 지 볼 수 없어서 내용의 흡수력이 조금 떨어진다는 생각이다. 추상적인 내용을 최대한 구체적으로 썼기 때문에 사실 여러 번 SRS를 접해본 나로서는 이해가 어렵지는 않았다. 하지만 추상적인 내용을 90%에 가깝게 구체적으로 쓴 것과 100%의 실물은 다르기 때문에, 직접 어떠한 프로젝트 하나를 들고서 설명했다면 좋지 않았을까? 하는 생각이다. 

 

물론 두괄식을 철저하게 지키는 구조로 책이 전반적으로 짜임새가 좋기 때문에, 뒷 부분인 2부에서 SRS의 챕터를 설명하면서 어떻게 작성되어 있는지 다루지만, 하나의 프로젝트를 그대로 SRS로 옮긴 것은 아니고 여러 프로젝트에서 핵심적인 부분을 가져오기 때문에 전반적인 흐름을 한 번에 이해하는 것은 어려울 수도 있을 것 같다. 사실 이 부분은 직접 경험해보지 않으면 느끼기 어려운 소프트웨어공학의 한계라고 생각하며, 경험이 꽤 있는 소프트웨어 엔지니어라면 무슨 소리를 하는지 100% 이해할 수 있을 것 같다.

 

총평 및 추천 여부

모든 개발자들이 애자일 방법론을 따를 수 밖에 없다고 말할 때, 이 책은 반대로 폭포수 모델을 따라야 한다고 주장한다. 따라서 본인이 애자일 방법론이 단연 최고라고 생각한다면, 꼭 이 책을 읽어보길 권한다.

 

물론 이 책에서도 미국과는 다른 한국의 문화나 분위기로 인해서 이러한 폭포수 방법론이 어려울 수 있다고 이야기한다. 하지만 어떤 기술을 쓸 때에도 장점과 단점을 알아야 하듯이, 이 책을 통해서 소프트웨어의 스펙이 뭔지 알고 애자일을 논하는 것과 그냥 애자일을 논하는 것은 다르다고 생각한다.