[리뷰/책] 소프트웨어 스펙의 모든 것

한 줄 요약 : 초보 개발자부터 프로그램 관리자까지 프로그램에 대한 시야를 넓히는 데 도움을 받을 수 있는 책

---

소프트웨어를 개발할 때 개발 결과물이 될 소프트웨어로(What) 문제점을 개선하기 위해(Why) 어떻게 만들 것인가(How)를 결정하고, 담당자, 실무자들의 협의를 거쳐 일정(When)을 결정하게 된다. 실제로 일을 할 때는 '최소한의 설계만 하고 일단 개발을 시작한다'와 같은 이야기를 많이 듣는다. 그 이유를 생각해보면 프로그램 개발을 요청한 사람의 요구사항은 변하는 게 당연하고, 변경된 요구사항이 전달될 때마다 스펙을 다시 정의하는 게 번거로운 일로 여겨지기 때문인 것 같다. 하지만 경험이 많은 경력 개발자(프로젝트 담당자)는 이런 점까지 고려해서 개발을 진행한다. 이들은 스펙을 따로 정의하지는 않지만 다양한 경험을 통해 돌발상황까지 머릿속에서 계산하면서 진행한다.

 

나는 프로젝트 경험이 많지 않을수록 스펙 분석에 더 큰 노력을 해야 한다고 생각한다. 스펙을 분석하면서 프로젝트에 대한 이해도도 높이고, 돌발상황을 미리 생각해볼 수 있기 때문이다. 처음부터 이런 생각을 했던 것은 아니다. 처음엔 프로그램의 일부분만 보고 소스 코드부터 작성했다. 하지만 얼마 지나지 않아 수정 요청을 하거나, 생각하지 않았던 부분도 '당연히 생각했어야 했지 않느냐?'라는 이야기를 들을 때마다 답답함을 느꼈다.

 

근본적인 이유는 내가 무엇을 프로그램으로 만들려고 하는지, 왜 만들어야 하는지에 대한 이해가 업무 요청자와 달랐기 때문이다. 작업을 요청한 사람은 숲을 보고 있는데 난 나무 한 그루만 보고 달려든 것이다.

---

소프트웨어 스펙의 모든 것

 

이번에 읽은 <소프트웨어 스펙의 모든 것>은 이런 답답함을 줄여나가는 데에 큰 도움이 되었다. 저자는 시스템 개발 전 설계와 스펙을 SRS(Software Requirements Specification)라는 용어로 스펙을 왜, 어떻게 정리해야 하는지를  실제 사례를 들어 풀어내고 있다. 책은 크게 소프트웨어 스펙이 무엇인지 설명하는 부분과 SRS 작성법을 설명하는 두 부분으로 나뉘어 있다.

 

소프트웨어 스펙인지 무엇인지 설명하는 부분에서는 에세이를 읽는 느낌을 받았다. 저자가 스펙의 필요성과 스펙 정의를 내릴 때 생각해봐야 할 것들에 관해 이야기해준다. 스펙은 상황에 따라 더 적절한 방법이 있을 뿐이다. 그렇기 때문에 경험이 부족한 나에겐 폭넓은 시야를 간접 경험할 수 있어서 도움이 되었다. 스펙을 설계할 때 생각해봐야 하는 것들을 독자에게 질문하고 답변하거나, 실제 스펙 설계를 할 때의 사례, 좋은 방법들을 알려주고 있기 때문이다. 내가 혼자 고민할 때는 생각하지 못했던 부분이 많아서 생각하며 읽어야 했다.

 

생각해 볼 것들

SRS 작성법을 설명하는 부분에서는 수많은 SRS 문서의 종류와 템플릿 예시를 설명해주고 있다. 스펙을 문서로 정리하는 것은 프로젝트의 규모, 당사자의 상황에 따라 형식이 다를 수밖에 없다. 나는 구글 문서를 이용해서 내가 보기 편한 대로 작성하곤 했다. 책에 포함된 템플릿 예시를 보면서 나의 부족한 부분들을 알게 되어서 큰 도움이 되었다.

소프트웨어 스펙 정의가 이렇게나 많다

책을 읽으며 가장 기억에 남았던 한 구절은 머리말이었다.

"소프트웨어 개발에 있어서 가장 어려운 일은 개발 자체가 아니라 무엇을 개발할지 결정하는 일이다"

나는 경험이 부족한 개발자라서 프로그램을 개발할 때 다른 사람들과 커뮤니케이션하는 것이 가장 어렵게 느껴진다. 이 책은 나처럼 경험이 부족한 초보 개발자부터 프로그램 관리자까지 프로그램에 대한 시야를 넓히는 데 도움을 받을 수 있는 책이라고 생각한다.

 

---

 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

리뷰를 위해 한빛미디어에서 책을 제공받았지만 주관적인 생각을 그대로 적었습니다.