[책리뷰] 소프트웨어 스펙을 정한다는것은 어떤 의미일까? - 소프트웨어 스펙의 모든 것

소프트웨어 스펙의 모든 것

참고 : 해당 도서는 한및미디어에서 리뷰를 위해서 제공받은 책입니다.

Yes24 도서 링크 : www.yes24.com/Product/goods/95888025?art_bl=13886022

소프트웨어 스펙의 모든 것

 

 

📖소프트웨어 스펙의 모든 것 도서를 읽어보았습니다.

 

미리 말씀드리자면 책 내용이 많이 포함되어 있지 않습니다.

 

해당 도서는 기획자 및 개발자(특히나 시니어 및 리더) 분들에게 강력하게 추천을 드립니다. 전 지금까지 리뷰했던 책들이 저 개인에게는 좋았지만 타인에게 추천해야겠다는 생각은 크게 생기지 않았었는데 이번 책은 꽤나 추천에 대한 욕구가 솟아났던 책이었습니다. 그래서 책을 읽는 중간에 이미 제가 알고 있는 기획자 및 PM분 2분에게 해당 도서를 추천해버렸습니다.

 

이 책은 SRS(Software Requirements Specification), 즉 스펙 작성에 대한 내용입니다. 책에 대한 내용은 목차 및 책을 훑어보시면 충분히 아실 수 있기에, 책을 읽으면서 느꼈던 감정 및 생각들을 공유하려고 합니다.

 

참고로, 저의 직업 및 경력 그리고 일해온 조직 등의 배경으로 인해서 무릎을 치게되고 "아!"를 외쳐가면서 읽게되었습니다. 

✔️직업 : 개발자

✔️경력 : 6년

✔️환경 : IT 스타트업 경험이 전부 (첫 회사(약 6명) -> 두번째 회사(약 20명) -> 세번째 회사(약 120명))

 

책의 내용에 왜 공감이 가는 이유를 생각해보니, 작은 규모의 회사 혹은 IT관련 스타트업에서 일한 경험이 가장 크다고 생각합니다. 모든 IT 스타트업이 그런건 아니지만 주로 소규모의 혹은 수익을 내지 못하는 회사라면 주로 공감이 갈것 같습니다.

 

회사는 이익을 창출하는 곳인데 이익을 창출하기 위해서는 여러가지 서비스를 만들어내거나 혹은 하나의 서비스에서 다양한 기능을 만들거나 수많은 전략들을 시도하게 됩니다. 그리고 자연스럽게 이거저것을 많이 시도하면서 마감기한은 짧기에 주어진 시간이 늘 부족하게 되고 어쩔 수 없이 야근을 하게됩니다. 그러다보니 자연스럽게 문서를 작성한다거나 소프트웨어 혹은 기능을 만들기 위한 사전 작업에 소홀해지고 요구사항에 부합한 결과물을 만들어내지 못하게 됩니다. 그렇기 때문에 버그도 많이 생기고 그와 함께 스펙을 상정하고 아키텍처를 만들 수 있는 경험이 부족해서 추후에 더 많은 노력을 필요로하게 됩니다. 시간이 지나면서 일은 많이 했고 경력은 높아지는데 스펙이나 아키텍처 적인 실력은 증가하지 않게 됩니다...

 

책을 읽으면서 지금까지 프로젝트를 진행하면서 부족했거나 아쉬웠던 부분들이 생각났고 이런 부분들이 제대로 수정이 된다면 더 즐겁게 일할 수 있지 않을까란 생각도 자연스럽게 하게 되었습니다.

 

책에는 소프트웨어 스펙이란 무엇이며 왜 필요한지에 대한 얘기가 자세히 설명되어 있으며 더불어서 SRS는 어떻게 작성해야하는지에 대한 도움을 받을수 있습니다. 개인적인 견해지만, 프로세스가 없거나 부족한 그리고 만들어가는 회사에서 일하고 있는 경력자인 개발자 및 PM 이라면 도움이 많이 될것이라고 생각합니다.

 

아 그리고 중요하다고 생각한 부분입니다.

해당 책은 혼자 읽으면 일하는 환경을 나아지게 만들기 어렵습니다. 최소한 팀 전체가 공감하고 실행할 수 있어야하며, 더불어서 회사 전체적으로 공감대를 형성해야지 의미가 있다고 생각합니다. 프로젝트를 진행하는 팀이 괜찮은 방법을 적용시키려고해도 C레벨에 준하는 임원들이 공감을 해주지 않고 '그건 우리에게 맞지 않아' 같은 태도로 나온다면 괜찮은 방법을 적용시킬 수 없습니다. 그럼에도 불구하고 더 나은 방법을 공유한다면 변화의 터닝포인트가 되지 않을까 생각합니다 ㅎㅎ

 

 

📌기억에 남는 내용 몇가지를 공유하고자 합니다.

👉 소프트웨어 공학이란건 소프트웨어를 최소 비용으로 최단기간에 개발하는 방법이다!!

👉 스펙이 부정확하면 일정 산출이 의미가 없다!!! (느껴봐야 합니다 ㅠ)

👉 문서 작성의 목적은 소프트웨어를 개발하는 과정이자 가장 빨리 효육적으로 해발하기 위함이다.

👉 코드 리뷰도 좋은 방법이지만, 그 보다 스펙 리뷰가 더욱 중요하다

     (스펙리뷰 > 설계리뷰 > 코드리뷰)

 

추가적으로...

직전 회사에서(현재 백수ㅋ) 제가 속한 안드로이드 팀에서 한해서는 설계 리뷰에 대한 얘기가 나왔었고 필요성도 느꼈지만, 해당 리뷰를 진행하기 어려운 팀 형태로 변경된것도 있고 서로가 각자가 진행하는 프로젝트가 바빠서 논의가 더 되지 않은 기억이 있습니다. 리뷰와 비슷한 형태로 진행했지만 그것을 당시에 저는 많이 지친 상태였고 적극성도 사라져서... 리뷰시간에 저는 그저 듣고만 있었던 기억이 있네요.....