한빛출판네트워크



먼저 약간의 과거이야기를 해보자면, 소프트웨어 스펙 관련된 내용 및 출판 도서들을 볼 때 마다 전규현님이라는 분의 이름을 보게 된다.

내가 처음 이 분을 알게 된 것은 입사 초년생 때 회사에서 개발문화 정착을 위하여 SRS 관련하여 컨설팅 및 교육을 받게 되면서 처음 알게 되었다.

그 당시 막 입문한 신입인 나에게는 모든 용어들이 생소했고 어려웠었다.

지금은 시간이 많이 흐른 후 이 책을 통하여 다시금 접하게되니 그 때와는 다르게 생소하기보다는 반가움이 먼저 들었다.

물론 지금도 SRS 자체를 작성하는것은 어렵다고 생각한다..

그래도 책의 내용은 재미있게 읽혀져서 다행이었다.

내가 생각하는 공감 포인트!

이 책의 내용 중 연차가 조금 있으신분들 또는 SRS가 무엇인지 아시는 분들이라면 "1.2 스펙에 대한 오해"라는 목차의 내용들을 매우 공감하게 될 것 같다.

- 스펙을 적는 것이 좋은 줄 몰라서 안 적는게 아니다.

- 나도 작성해봤는데 우리 경우는 달라서 적기 어렵다.

- 폭포수 모델과 달리 우리는 애자일이라서 잘 적을 필요가 없다.

이 부분이 공감간다면 이 책을 읽는데 기대감을 가지고 보게 될 것이라 생각한다.

이런 기대감을 가지고 보다보니 공감가는 내용들이 있어 3가지 정도만 써본다.

"5.1.1 공유문화" 내용 중

- 공유하려면 말로 하는 것보다 글로 적는 것에 더 익숙해져야 한다.

- 공유를 위한 과도한 프로세스는 오히려 독이다.

확실히 공유를 할 때는 말 보다는 글로 적는 것이 좋지만 그 만큼 글로 적는다는 것은 어렵다. 말은 뱉어놓으면 누군가는 듣고 새길 수 도 있고 누군가는 흘러버릴 수 도 있지만, 글은 오래두고 모두가 볼 수 있기에 그렇다.

그리고 공유도 그렇지만 다른 것을 할 때도 주객이 전도되는 과도한 프로세스를 적용하는 것 또한 독이다. 라는 것을 일하면서 느낀적이 많다.

"6.7 코드 리뷰 보다는 설계 리뷰, 설계 리뷰보다는 스펙 리뷰" 내용중

- 코드 리뷰를 통해 문제점을 발견하고 더 효율적인 방법을 찾기도 한다. 다만 이 모든 이야기는 스펙, 설계가 잘 됐을 경우로 국한된다.

이건 내가 실무에서도 아직도 경험하고 있는 내용들이라 더더욱 공감이 되었다.

코드를 작성하기 전에 설계 또는 스펙, 요구사항 등의 정의가 잘 정의되었는지 확인하는 것이 더 큰 부분임을 알게 해준 내용으로 정말 그렇다..

"7.4 소프트웨어 개발자는 글을 잘 써야 한다" 내용중

- 감동을 주는 글을 써야 한다는 것이 아니라 생각하는 바를 정확하게 표현할 수 있는 것을 말한다.

앞에 공유 문화에서도 글로 적는게 좋다고 했듯이 개발자는 글을 잘 써야 한다는 말에 공간한다. 그리고 감동을 주는 글이 아닌 논리적인 글을 써야 한다는 내용도 말이다. 현업에서는 바쁘다. 이슈에 대한 해결 방안을 적든지 의견을 적든지 핵심만 간단히 적는 것이 필요하다. 그리고 있는 사실을 논리적으로 정리하는게 꼭 필요하다.

이렇듯 이 책을 읽으면서 꼭 SRS 문서 작성에 대한 내용뿐만 아니라 개발 전반적인 부분에 대하여 생각해보게 되는 것 같다.

누군가에는 SRS 작성에 가이드가 될 것이고, 누군가에는 개발 문화에 대한 가이드, 또 누군가에는 개발 정석에 대한 가이드가 되는 책이라는 생각으로 리뷰를 마친다.



이제 곧 현업에 나가는 학생 개발자이다 보니 정해진 스펙대로 개발하기보다는 하나의 아이디어를 내고 그 프로덕트를 만들기 위한 기능을 대략 나누어 각자 개발해서 합치는 경우가 일반적이었다. 실제 대규모로 서비스하는 것이 아니다보니 이러한 방식으로도 큰 문제는 없었지만 소프트웨어의 규모가 커질수록 이러한 방법은 한계가 있을거라는 것을 은연중에 느끼고 있었고 마침 11월 리뷰 서적에 이러한 갈증을 해소시켜줄 것 같은 제목의 책이 있어 신청을 하게 되었다. 소프트웨어 요구사항을 분석하고 작성하는 것은 수십가지의 방법이 존재하지만 이 책은 IEEE830과 DoD에 정의된 Sofware Requirements Specification을 중심으로 스펙 문서 작성을 설명한다.

소프트웨어 개발은 1층부터 차례대로 짓는 건물과 달리 동시다발적으로 컴포넌트와 인터페이스를 정의하고 이를 기반으로 병렬적으로 작업이 진행되는 것이 일반적이다. 따라서 초기에 정한 이러한 스펙이 차후 많이 변경된다면 이를 동기화하기 위한 공수도 상당히 많이 들어가게 된다. 실제 대학교 2학년 때 처음 동기들과 프로젝트를 하면서 처음 예상했던 인터페이스에서 너무 많이 달라져서 이후 코드를 머지하는데 큰 어려움을 겪었던 기억이 있다. 이 책에서는 이러한 문제의 솔루션으로 지속적인 통합을 강조하는데 이를 위해서는 유닛 테스트 및 테스트 자동화가 필수불가결하다. 또한, 하나의 컴포넌트를 전부 완성시키고 커밋하는 것이 아닌 컴포넌트 안의 특정 기능을 완성할 때마다 커밋 후 빌드 테스트를 하는 것을 추천한다. 빌드의 경우 환경에 따라 데일리 빌드, 나이틀리 빌드 등으로 변경할 수 있다.

이 책의 좋았던 점은 내가 처한 개발 환경에 따라 다양한 스펙 문서의 유형을 알려주고 이것이 실제 어떻게 사례로 연결되는지 보여준다는 점이다. 또한, 2부에서 실제 SRS의 구성을 따라가며 상세히 작성하는 방법을 알려주는 부분은 실제 현업에 들어가서 바로 적용할 수 있겠다는 생각을 했다.

​

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

책의 제목은 소프트웨어 스펙의 모든 것. 소 제목으로는 프로젝트를 성공으로 이끄는 소프트웨어 스펙 작성법이다. 이 책에서 말하는 소프트웨어 스펙이란 소프트웨어를 만들 때 시작점이자 기준점이 되는 스펙. 즉 SRS, SRS의 뜻은 소프트웨어 스펙 문서로 포함되는 내용으로는 비전, 비즈니스 요구 사항, 품질 특성, 기능 요구 사항, 외부 인터페이스, 시스템 요구 사항, 제약조건 등 그리고 각각에 대한 용어 설명도 친절하게 되어 있다.

문서, MRD, MRS, PRD, SOW, SRS, 사람 또는 팀, 제품 기획자, 기획자, 아키텍트, 개발자, 소프트웨어 엔지니어 

행위, 분석, 설계, 상위 설계, 하위 설계, 

그리고 일반적인 업무 환경에서 SRS를 잘 작성하지 않는 이유도 적나라하게 적혀 있고 그에 따른 부연 설명도 있다. ​

스펙에 대한 오해 

스펙을 적는 것이 좋은 줄 몰라서 안 적는 게 아니다. 

소프트웨어를 만들어보기 전에는 천재도 그 내용을 다 알 수 없다. 

나도 작성할 줄 아는데 쓸 시간이 없다. 

나도 작성해 봤는데 우리 경우는 달라서 적기 어렵다. 

기획팀에서 주는 문서로는 스펙을 적을 수가 없다. 

폭포수 모델과 달리 우리는 애자일이라서 잘 적을 필요가 없다. 

잘 된 샘플을 보고 싶다. 

실리콘밸리에서는 한번 적으면 스펙이 변경되지 않는가?​

책은 SRS 없이 프로젝트를 진행했을 때 발생하는 문제점과 SRS를 잘 작성하고 프로젝트를 진행했을 때는 장점 등을 잘 설명하고 있다.

​약간의 단점으로는 용어나 내용 설명의 순서가 약간 친절하지 못한 부분이 있는데, 책이 두껍지 않기 때문에 왔다 갔다 하며 읽어도 충분하다. 다양한 그림들과 샘플 문서 설명 등이 포함되어 있어서 한 번쯤 읽어보면 프로젝트를 진행하거나 팀에 소속되어 일을 할 때도 많은 도움이 될 것 같다. 

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

1. 처음 게임기획자로 일을 하게 되면서 가장 어려웠던 것은 문서를 작성하는 것이었습니다. 무엇을 해야겠다는 생각은 있었지만 그것을 글로 옮겨 문서를 만들어내는 것은 전혀 다른 얘기였죠. 최대한 원하는 것을 상세하게 적어야하는 것은 알았지만 상세하다는 것조차 무엇을 의미하는지 모르던 시절이었습니다. 다행히 지금은 다양한 프로젝트를 거치고 프로그래머와 일을 하면서 기획서 비스무리한 것을 그럭저럭 작업하는 단계에 도달했습니다. 

책 <소프트웨어 스펙의 모든 것>은 프로그래머가 소프트웨어 스펙을 작성하는 단계에 대해 이야기합니다. 기획자가 작성한 기획서가 What과 Why에 집중한다면 이 책에서 말하는 SRS(Software Requirements Specification)는 표현 그대로 What과 How에 비중을 둔 문서입니다. 기획자보단 프로그래머들을 위한 책이긴 하지만, 기획서를 작성하는 입장에서 SRS를 이해해둔다면 좀 더 그들에게 도움이 되는 기획서를 작성할 수 있으리라는 생각에 책을 읽어보게 되었습니다.

2. <소프트웨어 스펙의 모든 것>은 2개 챕터로 구성되어 있습니다.

- 1부. 소프트웨어 스펙이란

소프트웨어 스펙에 대한 이해를 돕고 SRS가 왜 필요한지 필요성에 대해 대해 전반적인 이야기를 하고, SRS를 도입하게 되면 어떤 프로세스로 개발이 진행되어야 하고, 누가 담당해야 하는지, 그리고 어떤 내용들이 담기게 되는지에 대한 개론을 담고 있습니다.

- 2부. SRS 작성법

실제 분량은 전체 책 내용의 30%에 불과하지만, 실제 업무에 활용할 수 있는 SRS 템플릿을 별도의 파일로 제공하고 책에선 이에 대한 첨언과 같은 역할을 합니다. 별도 제공하는 문서 파일을 열어보면 필요한 내용들이 단락별로 다 구성되어 있고, 책은 숙지해야 할 부분에 대해서 노하우를 담아두어 책의 내용을 최소화하고자 한 것으로 보입니다.

책은 1부에서 70%의 내용을 할애하며 소프트웨어 스펙의 중요성과 SRS의 필요성에 대해 다룹니다. 자칫 개론과 실무에 대한 비중이 역전된 것이 아닌가 싶은 생각이 들 수도 있겠지만, SRS를 작성하기 위해선 주위의 설득, 공감, 노력과 시간이 필요하기 때문에 타당하다 느꼈습니다. 실무에 대한 내용은 저자가 별도로 제공하고 있는 템플릿이 있고, 해당 문서에 설명들이 잘 기재되어 있기 때문에 SRS에 대한 필요성만 느낀다면 2부에서 제공하는 작성법을 참고하여 충분히 실무에 활용할 수 있으리란 생각이 듭니다.

3. 아래는 제가 책을 읽어보고 인상 깊었던 구절들을 정리한 것입니다.

실제 SRS를 활용하는 포지션은 아니지만 기획자에게도 도움될 만한 부분이 많았습니다.

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

- 소프트웨어 개발에서는 '적절히'가 매우 중요하다. '적절히'를 제대로 이해하는데 10년 20년이 걸리는 만큼 처음부터 완벽하게 이해하려는 것은 욕심이다. 시행착오를 거치면서 원리를 하나씩 깨우칠 때 '적절히'하는 노하우를 하나씩 터득하게 된다.

- 스펙 관점으로 보면 모든 소프트웨어는 같다. 모든 소프트웨어에는 스펙이 있고 스펙을 제대로 작성하는 것은 소프트웨어 프로젝트의 성패를 가를 만큼 중요하다.

- 프로젝트 모든 이해관계자가 스펙을 참조하거나 작성에 참여하고, 스펙은 다시 여러 이해관계자들에게 전달되어 본연의 역할을 수행한다.

- 스펙이 부정확하면 일정을 산정하는 의미가 없기 때문이다. (중략) 개발 문서는 일정을 단축하기 위해 작성하는 것이므로 이 목적에 위배되는 문서는 작성하지 않는 것이 좋다.

- 말로 하는 대화는 가장 값비싼 커뮤니케이션 수단이다. 또한 휘발성이 강해서 금새 사라진다.

- 기획 단계 없이 곧바로 스펙 작성을 시작하기도 하는데, 이 경우 기획 단계에서 했어야 할 일이 고스란히 스펙 작성에 전가되기 때문에 소비되는 시간과 자원은 똑같거나 더 많다.

- 문서작성 요령 중 : 읽는 사람의 눈높이에 맞춘다 / 주제를 직접적으로 명시한다

- 문장을 바르게 쓰는 방법에 대한 요령

1) ~해야 한다

2) 수동태보다는 능동태

3) 간결한 문장

4) 부정문보다는 긍정문

5) 이유도 적기

6) 서술식으로 적는 것이 좋다

7) 주어를 생략하지 않는다

8) 정량적으로 적는다

9) 애매한 표현은 삼간다

10) 문장표현의 한계 (그림, 다이어그램, 그래프 등을 활용한다)

4. 앞에서 이야기한 것처럼 이 책은 소프트웨어 스펙과 SRS의 필요성에 대해서 많은 비중을 할애하고 있습니다. 덕분에 이에 대해 문외한인 사람이보더라도 그 필요성에 대해 쉽게 공감할 수 있습니다. 물론 책만 읽는다고해서 SRS를 완벽하게 잘 작성해낼 순 없으나 모든 기술이 그러하듯 필요에 의해 사용하다보면 익숙하게 스펙을 작성해낼 수 있으리라 생각합니다. 제가 기획서를 쓰는 것도 그랬으니까요. 다만 제가 많은 회사를 다녀본 것은 아니지만 소프트웨어 스펙에 소홀한 경우가 대부분이라 개인이 잘 해낼 수 있을까란 생각은 듭니다.

5. 책 <소프트웨어 스펙의 모든 것>은 프로그래머를 대상으로 쓰여진 책이지만 관련 업종에 종사하는 사람이라면 프로그래머들에게 업무를 요청하거나, 공유 받는 입장에서 읽어보면 도움이 될 책입니다. 소프트웨어 스펙 작성이란건 결국 무엇을 만들겠다고 정의하는 것인데 그 방식을 이해한다면 의사소통에 좀 더 도움이 될테니까요.

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

https://www.hanbit.co.kr/store/books/look.php?p_code=B5030061985 

보통 이러한 소프트웨어 개발에 필요한 내용을 기술하는 책은 원칙적인 얘기를 많이 하며 지루하기 때문에 중간에 포기하는 경우가 많다.

하지만 이 책은 지루하지 않고 간단 명료하게 작성하여 매우 잘 읽힌다. 

그렇기 때문에 관련 전공자 외에도 소프트웨어를 도입하려는 현업등 도 읽으면 많은 도움이 될듯 하다.

나는 개발자이고 최근에 SRS 이외에도 문서의 중요성에 대해 느낀점 이 있었다.

혼자서 모든 것을 개발할 것이 아니라면 상황에 맞는 SRS문서 작성은 매우 중요한 요소이다. 

< 소프트웨어 스펙의 모든 것 | 김익환, 전규현 지음 | 한빛미디어

많은 소프웨어 개발 프로젝트가 다양한 이유로 실패한다는 것은 이미 알려진 사실이다. 프로젝트를 시작할 때 인원과 일정과 비용을 항상 산정해서 시작하지만 대부분 일정과 비용이 예상과 많이 달라지게 되어 예상했던 일정을 넘기거나 추가적인 인원이 프로젝트에 투입되게 된다(물론 프로젝트 막바지에 개발자가 추가된다고 하더라도 일정 단축이 된다는 보장은 하기 어렵다). 어떤 이유때문에 개발 프로젝트가 실패하게 될까?

문제가 발생하는 많은 프로젝트는 제대로 된 스펙이 작성되지 않은 채 프로젝트가 시작되는 경우가 많다. 일반적으로 소프트웨어라고 표현하는 개발 프로젝트는 그 성격상 언제나 변경 가능하다고 생각하기 때문에 스펙 작성을 소홀히 하는 경향이 있다. 그 결과 뒤늦은 스펙 변경으로 인해 전체 프로젝트에 심각한 영향을 끼치는 경우가 종종 눈에 띈다.

스펙을 제대로 작성하는 역량은 소프트웨어 개발에서 가장 어려운 능력이며 소질있는 개발자도 오랜 경험과 노력으로 터득해야 하는 기술이다. 하지만 많은 사람들이 스펙의 중요성에 대해 무시하는 경향이 있다. 대부분은 스펙에 대한 오해에서 비롯된다. 스펙을 적는 것이 좋다는 것은 알지만 어러 사정으로 못 적는다던지 소프트웨어를 만들어보기 전까지는 천재도 그 내용을 다 알 수 없다는 등이다. 특히 스펙을 작성할 시간이 없다는 얘기를 종종하곤 한다. 하지만 이미 언급했던이 대부분 오해에서 비롯한 사항이며 도리어 제대로 된 스펙없이 소프웨어 개발을 시작하는 것이 프로젝트를 위험에 빠뜨린다는 것을 알아야 한다.

소프트웨어 스펙을 개발자만을 위한 문서가 아니다. 소프트웨어 스펙은 모든 프로젝트 이해관계자를 연결하는 프로젝트의 중심이 되어야 한다. 고객, 마케팅, 영업팀에게는 어떤 제품이 만들어질지 미리 알 수 있도록 하며, 프로젝트 관리자에게는 스펙이 관리를 위한 기준이 된다. 개발팀은 스펙을 통해 개발해야 할 제품이 무엇인지를 정확히 안다. 이 외의 모든 인원이 이 스펙을 통해 미리 필요한 준비를 수행하고 처리할 수 있는 기준이 된다.

소프트웨어 개발에서 스펙이 중요한 만큼 제대로된 스펙 작성이 필요하다. 이 책에서는 SRS(Software Requirement Specification) 관점에서 스펙 작성을 설명한다. 종종 스펙과 요구사항을 혼동하는 것을 보게 된다. 요구사항은 일반적으로 고객이나 이해관계자가 요구하는 것이다. 하지만 스펙은 쓰는 사람에 따라 의미가 조금씩 다르다. 따라서 요구사항은 몇줄에 불과할 수 있지만 그 요구상에 매핑되는 스펙은 수 페이지 또는 수십 페이지가 될 수도 있다.

스펙의 중요성은 이 책의 분량만 봐도 알 수 있다. 총 2부로 구성되어 있는데 1부 "소프트웨어 스펙이란?" 부분이 전체의 2/3를 차지한다. 그만큼 스펙의 개념을 이해하는 것이 중요하다는 것을 보여준다. 2부 "SRS 작성법"은 1/3 정도를 차지하는데 실제 SRS 예제를 기반으로 작성해야 하는 항목에 대해 자세히 설명하고 있다.

소프트웨어 스펙의 중요성은 아무리 강조해도 지나치지 않는 것 같다. 그만큼 중요하지만 많은 사람들이 소홀하게  생각하는 것도 사실이다. 프로젝트의 성공을 위해서라도 제대로 된 스펙 작성에 대한 중요성과 작성법을 익힐 필요가 있다고 생각한다. 프로젝트 관리자뿐만 아니라 개발자, 그리고 회사의 구성원 모두 스펙의 중요성을 인식하고 프로젝트의 출발점으로 삼는 인식 전환이 필요한 것 같다. 많은 회사의 구성원들이 이 책을 읽고 스펙에 대한 중요성을 다시 인식하고 개발자는 제대로 된 스펙을 작성할 수 있는 개념과 기술을 터득하면 좋을 것 같다.

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

아이디어만으로 서비스의 MVP 개발을 막 시작하는 스타트업의 프로젝트부터 수많은 문서들로 이루어진 SI 프로젝트까지 여러 유형의 프로젝트에서 성공적인 프로젝트를 위한 적절한 스펙작성은 쉽지 않은 고민 중 하나다. 

어디까지 스펙의 범주에 포함할지, 얼마나 상세히 작성해야 할지, 그리고 변경사항들은 어떻게 관리할지 등 경험해 보지 않으면 판단하기 힘든 것들이다. 저자들은 이런 소프트웨어 스펙에 대한 궁금증들과 그 작성 방법에 대해 1, 2부로 나누어 설명하고 있다. 1부는 스펙의 정의와 많은 프로젝트에서 마주치는 부실한 스펙들과 이를 부추기는 여러 관행들을 사례를 통해 얘기하며, 기업 문화, 프로세스, Who, What, How등 스펙에 대한 설명과 프로젝트진행 전반을 함께 살펴본다. 2부는 스펙작성에 직접적인 내용들로 채워져 있다.

효율적인 도구들과 다양한 개발방법론등이 소프트웨어의 개발에 도움이 되고 있지만, 본질은 요구사항을 명확히 파악하고 이를 제대로 설계, 구현하는 것이 아닐까 한다. 소프트웨어 스펙의 모든 것은 스펙의 작성방법에 대해서도 설명하지만 잘 작성된 스펙이 그런 본질을 가장 잘 뒷바침해 줄 수 있는 핵심임을 깨닫게 한다.

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



간만에 정리하기가 쉽지 않은 책을 만났습니다. 두 분 저자들의 내공이 워낙에 심오하다 보니, 가벼운 마음으로 읽기 시작했으나 그 내공을 쉽사리 전수 받지는 못 한 것 같습니다. 아예 모르면 겸손한 자세로 지식을 전달 받는데 집중했을텐데 어줍잖게 알고 있다고 생각하고 있어서인지 더 그랬던 것 같기도 하구요. 그래서 ... 솔직히 쉽게 읽히는 책은 아니었던 것 같습니다. 모든 내용을 이해하려고 하기보다는 생각날 때마다 필요한 부분을 찾아서 읽어 보는 것으로 도움을 얻을 수 있는 책이라 생각합니다.

소프트웨어 요구사항을 분석하고 이를 정리해 작성하는 스펙 문서는 개발사의 숫자만큼이나 다양할 것입니다. 그 중에서 이 책에서 주로 다룰 "문서"는 SRS (Software Requirements Specification) 입니다. 줄여서 Specification 혹은 spec(스펙) 이라고 하며, IEEE830에 문서를 작성하는 가이드가 정의되어 있고, DoD(미국 국방부) 문서이기도 하답니다. 쉽게말해 이 책은 "무엇을 개발할지 결정하는 일"을 공식화 해 놓은 문서를 작성하는 법에 대해 설명해 놓은 책라고 보면 될 것 같습니다.

다양한 개발 방법론에 따라 제시하는 문서 종류도 다르고 그 개수도 다양합니다만, SRS에는 스펙을 작성할 때 생각하는 방법, 작성하는 프로세스, 기록해야 할 내용, 각 내용의 작성 가이드가 모두 수록되어 있어서 SRS를 작성하는 원리를 깨우친다면 어떠한 방법론에서도 스펙을 잘 작성할 수 있다고 합니다. SRS가 전 세계 표준이라고 보면 되는 것이죠.

SRS에 대한 체계적인 이해를 위해 이 책은

1부 소프트웨어 스펙이란?

소프트웨어 스펙의 원리를 이해하고 이를 잘 작성하는 역량을 확보하는 방법을 설명

2부 SRS 작성법

실제 SRS 템플릿을 기준으로 각 챕터에 작성할 내용을 설명하고 구체적인 작성 예를 설명

하는 것으로 구성되어 있습니다. '스펙을 잘 작성하는 방법은 가르칠 수 있는데 배울 수는 없다'고 한 저자의 말처럼, 프로젝트에 제대로 된 스펙 작성 과정을 도입하는 것은 쉽지 않은 일입니다. 실제로 프로젝트를 구현해 나가는데 있어서 프로젝트의 성패를 좌우하는 변수는 너무나도 다양하고 많거든요.

현업에서 이 어려움을 누구보다 실감했을 저자들이어서 그런지, 이 책은 2/3가량이 1부 소프트웨어 스펙이란에 분량이 할애 되어 있습니다. 프로젝트를 성공적으로 이끌어 나가는데 있어서 제대로 된 스펙 작성의 중요성과 개발의 성패를 좌지우지할 수 있는 변수들을 스펙을 통해 제어하는 방법들을 경험 및 사례를 통해 설명하고 있습니다.

따라서, 고객과 개발자 사이를 조율하고 협의해야 하는 팀장, PM, 아키텍트들에게 실무적으로 도움이 될 만한 내용들을 다루고 있으며, 뻑하면 '안 된다'부터 외치는 실무 개발자들의 입장에서도 팀장, PM, 아키텍트들의 노고를 이해하는데 도움이 될 만한 내용들로 구성되어 있다고 생각합니다.

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



소프트웨어 스펙의 모든것

어느정도 개발 경력이 쌓이다 보니

좋든 싫든 관리자의 영역에 들어서게 된다.

난 머리가 백발이 될때까지 개발을 하고 싶지만

이제 어느 프로젝트를 가든지 많든 적든 어느 정도 관리자급의 업무를 요청 받는다.

현재 진행중인 이 프로젝트도 마찬가지다.

(계약은 개발자로 했는데....)

내 의지와는 상관없이 년차와 등급 때문에 은근슬쩍 관리 업무를 떠앉게 된다.

그중에서 내가 가장 힘들어 하는 부분이 문서작성/관리 부분이다.

그리고 이 부분 때문에 프로젝트 진행 시 가장 많은 스트레스를 받고 있고, 어려워 하고 있는 부분이다.

그때 눈에 띄 책이 "소프트웨어 스펙의 모든것" 이었다.

지금 상황과 너무 딱 들어 맞는 내용!

현재 상황 때문인지 책을 집중에서 읽을 수 있었던거 같다.

문서가 중요하다는 말을 많이 들어봐 왔겠지만

개발 경력이 얼마 되지 않은 개발자들에는 아직 그 중요성이 와 닿지 않을 수도 있다.

따라서 이 책의 구독 대상은 관리자급을 바라보고 있는 개발자와 그 이상의 관리자 직급들이라 할 수 있겠다.

또는 개발직과 관련 없는 영업직 이라던지, IT 회사나 부서와 직간접적으로 협업을 하는 담당자들도 읽어 보면 좋을것 같다.

(사실 프로젝트와 관련 있는 사람들에게는 프로젝트 시작 전 강제로라도 읽히고 싶고,

제대로 이해하며 읽었는지 확인하고 싶을 정도다!)

다시 이 글의 주제로 돌아와 

이 책의 주제에 대해 이야기 해보자면, 이 첵은 SRS 문서 작성 방법이다.

SRS문서란 쉽게 말해 프로젝트의 "요구사항"과 관련된 잘 정리된 "문서"라고 이해하면 될 것 같다.

그렇다고 이것이 "요구사항명세서"를 의미하는 것은 아니다.

보통의 프로젝트를 다음과 같은 5단계로 나눴을때

분석 -> 설계 -> 개발 -> 테스트 -> 배포

이 책은 "분석"과 "설계" 과정에 작성해 할 문서들에 대해 이야기 하고 있다.

그리고 이 "분석/설계" 과정에 투입되어 문서를 작성하고 만들어 나가는 사람은

대부분 시니어 개발자 이상급 이다.

우리가 "아키텍트" 라고 부르는 사람들이며, 보통 PM/PL 역을 맡고 있다.

이런 문서를 시간과 공을 들여 작성 하는 이유는 프로젝트를 빠르게 진행하고, 성공적으로 이끌기 위해서다.

따라서 프로젝트가 빠른 시간안에 제대로 수행되기 위해서는

분석과 설계 과정이 매우 중요하고, 그 과정에서 만들어지는 산출물이 매우 중요하다는 의미이다.

산출물을 잘 작성하기 위해 가장 좋은 방법은 직접 써보는 것이다.

많은 보면 글을 쓰는데 도움이 될 수 있겠지만, 여러번 글을 써보는 것은 좋은 글을 더 잘 쓸 수 있게 해준다.

SRS도 결국은 글로 된 문서 이기에, 여러번 쓰다보면 잘 쓸 수 있다.

(이제는 개발자도 글을 잘 써야 하는 시대가 되었다...)

SRS를 쓰는 것은 막막하다.

어떤 내용을 어떻게 써야 할지도 너무 막막하다.

하지만, 이 책의 2부에서 어떤 내용을 어떻게 적어야 할지 잘 안내해 주고 있다.

양식이 필요 하다면 이 책에서 제공해준 링크를 통해서 다운로드 받을 수 있다.

(참 친절하다.)

마지막으로 개발자라는 직업은 끊임없이 무언가를 습득하고, 알아가야 한다.

기술의 발전 속도는 우리가 생각하는 이상으로 빠르기 때문에,

내가 주니어 개발자 시절에 공부하고 학습했던 내용이, 시니어급 개발자가 된 지금에 와서는 더이상 사용하지 않는 방식이 된것들이 더 많다.

따라서 주니어 개발자들과 효율적으로 업무를 진행하기 위해서는 현재에 안주해서는 안된다.

그러기 위해서는 책을 읽던, 누군가에게 부탁해 배우던, 인터넷 강좌를 듣던 부단히 노력을 해야만 한다.

관리자가 되었다고 해서 아래 직원에게 시키면 된다는 생각은 버려야 한다.

그럴 수록 부하직원들과의 반목은 심해질 수 밖에 없고, 결국에는 낙오될 수 밖에 없다.

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

출처: https://freehoon.tistory.com/192 [훈잇 블로그]

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

​

거의 SRS (Software Requirements Specification)만을 다루는 책이다.

1부는 스펙의 중요성, 작성 지침등에 대해서 다룬다면,

2부는 SRS의 템플릿을 어떻게 작성하는지 다룬다.

​

저자들은 문서 작성 자체의 기법, 기술보다는

저자가 경험으로써 느낀 소프트웨어 개발의 어려움과 그 해결책에 대해 많은 부분을 이야기하고 있다.

실제 스펙을 작성해야 하는 역할이 아니더라도 소프트웨어 개발에 몸 담았다면 한 번씩 읽어보는게 좋을 것 같다.

​

이 책을 보면 모든 소프트웨어 개발의 모든 문제는 스펙에서 발생하고, 스펙만 잘 작성하면 모든 문제가 해결될 것처럼 기술되어 있기는 하다.

프로젝트의 앞 단계에서의 문제가 생기면 뒤로 갈수록 눈덩이처럼 커진다는 것은 익히 경험한 것이고,

그 첫 단계가 SRS 작성이니 모든 문제의 시발점이라는 말에는 공감한다.

하지만, 스펙 문서의 템플릿을 봤을 때 느껴지는 거대함은 난감하게 느껴진다.

​

​

​

책 내용에도 샘플 제공의 위험을 말하기는 하지만,

그대로 잘 작성된 샘플이 있었으면 하는 아쉬움은 있다.

'소프트웨어 스펙의 모든 것' 도서는 PM, 5년 이상의 실무자들은 꼭 한 번쯤 읽어보았으면 하는 추천도서이다.

내가 현재 개발 능력은 있지만 과연 잘 하고 있는지와 소프트웨어 프로젝트를 거시적인 관점에서 바라볼 수 있게 해주는 유용한 도서임에는 틀림없다.

소프트웨어 스펙의 모든 것은 SRS(Software Requirements Specification)이라고 하는 문서를 아주 심도있게 다룬다. SRS란 무엇인지, 왜 작성해야 하는지, 어떻게 작성하면 되는지 등 여러 예제를 통해 보여준다. 또한 성공한 프로젝트와 실패한 프로젝트에서 소프트웨어 스펙이 어떤 영향을 주었는지는 아주 흥미롭다.

아마 기획문서, 설계문서, 아키텍처, 메뉴얼 등 여러가지 이름으로 어쩌면 개발자 주변에 항상 있었을지 모른다. 하지만 SRS는 이것들과 분명히 다르고 별개의 문서로 취급되어야 한다. 책의 서미에 용어에 대한 정리를 보여준다. MDR(Market Requirements Document), MRS(Market Requirements Specification), PRD(Product Requirements Document), SOW(Statement Of Work), SDS(Software Design Specification), IRS(Interface Requirements Specification)과 구분해서 SRS를 공부하면 좋다. 그동안 추상적인 개념으로만 이해하고 있던 SRS를 이 책을 통해 확실히 정리하자. 그리고 현재 프로젝트를 진행하고 있다면 어떻게 적용할 수 있을지, 혹은 이미 적용하고 있다면 책에서 다루는 SRS와 어떻게 다른지 비교해보자. 아주 흥미로운 시간이 될 것이다.

SRS가 제대로 작성되지 않았을 때 프로젝트가 뒤로갈수록 얼마나 처참해질 수 있는지 아주 잘 보여주는 그래프다. 이걸 "스펙 1:10:100 규칙 그래프"라고 부른다. 비유하자면 개발 막바지에 기획이 바껴서 아키텍처를 통째로 수정해야 하는, 즉 근간을 흔드는 요청사항이 뒤늦게 들어왔던 경험은 개발자라면 누구나 한번쯤 있을거다.

한편, 이 책은 다양한 예제와 함께 SRS를 설명하지만 마냥 모든 부분에서 좋은 책은 아니다. 개인적인 의견이지만 어딘가 모르게 설명에 단호한 어조가 부족한게 유일한 단점이다. 번역서가 아닌 한국에서 태어난 책이라 조금 기대가 컸는지도 모르겠다. 하지만 분명한건 개발팀 이외의 프로젝트 이해관계자와 소통하기 위해 우리는 반드시 소프트웨어 스펙을 준수해야 하며 교감할 수 있어야겠다. 이 책을 통해 SRS 배경지식을 쌓아두는건 어떨까? :) 

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

<이 리뷰는 한빛미디어로부터 도서를 지원받아 작성되었습니다.>

책소개

프로젝트가 실패하지 않는 답은 소프트웨어 스펙 작성에 있다 

소프트웨어 스펙(SRS)은 시작이고 기준이다. 스펙을 제대로 작성하는 것은 프로젝트의 성패를 가를 만큼 중요하다. 스펙을 잘 작성하기 위해서는 개발 문화, 관행, 습관, 프로세스, 원리, 원칙을 알고 접근해야 하며 실전을 통한 노하우 축적이 필요하다. 이 책은 저자들의 수많은 경험을 토대로 여러 유관 분야 이론을 망라하고 스펙 작성 요령을 제시한다. ‘스펙  작성’의 진짜 의미가 무엇인지 이 책을 통해 알아보길 바란다. 

출판사 리뷰

프로젝트의 불확실성을 줄이는 소프트웨어 스펙, 제대로 작성하고 있었을까?

프로젝트의 가장 많은 실패 원인은 스펙과 관련 있다. 소프트웨어 버그의 절반 이상이 부실하거나 잘못 작성된 스펙 때문에 발생한다. 프로젝트 성공률을 높이는 가장 좋은 방법은 스펙을 제대로 작성하는 것이다. 여기서 ‘제대로’는 ‘자세히’가 아니다. 어려움과 미지수까지 사실을 그대로 보고, 스펙을 작성하면서 검증해 불확실성을 줄여가는 것이다. 누구나 알고 싶어 하지만 쉽게 알 수 없는 소프트웨어 스펙 작성의 거의 모든 것을 정리했다. 훌륭한 소프트웨어를 만드는 데 힌트가 되기를 바란다. 

https://www.hanbit.co.kr/store/books/look.php?p_code=B5030061985 

느낌과 목차

처음 책을 받았을 때에는 책이 들고 다니면서 읽을 수 있을 정도로 작아서 좋았다. 카페에서나 이동하면서 읽을 수 있었기 때문이었다. 책을 읽으면서 느낀 점은 이 책을 기획부서에서 읽으면 참 좋을 것 같다는 느낌이 들었다ㅎㅎ. 책을 읽다보니 이 책은 개발자도 읽으면 좋겠지만 개발자보다 기획자에게 더욱 어울리지 않을까 라는 생각을 하게 되었다. 이런 스펙들이 책처럼 잘 정의된다면 개발 하는 입장에서도 엄청 편하고 알기 쉬울 것 같다는 생각이 내내 들었기 때문이다. 프로젝트의 일정을 못 맞추는 부분이 개발자에게만 문제가 있는 것이 아니라 스펙 자체를 돌아볼 필요도 있다는 생각이 들기도 했다.

목차는 크게 2부로 구성되어 있다.

- 소프트웨어 스펙이란?

스펙에 대한 개요 및 사례 그리고 다양한 기업 문화와 프로세스에 대한 내용을 다루고 있고, 스펙을 누가 다루는지 누가 쓰는지 등에 대한 내용을 설명하고 있다.

- SRS 작성법

Software Requirements Specification 소프트웨어 스펙문서를 작성하는 법에 설명하고 있다.

좋았던 부분

책이 가독성이 참 좋게 되어있다. 중간중간 작은 제목이 내용을 대표해서 설명하고 있기 때문에 소제목만 보더라도 어떤 내용을 담고 있을지 알 수 있었다. 소주제로 정리 된 내용은 눈에 한번에 들어올 뿐 아니라 본문을 요약하는 역할도 하기 때문에서 인지 머리 속에 더욱 쉽게 들어왔다.

또한 책에서는 많은 고민들이 담겨있다. 스펙에 대한 내용 뿐아니라 TDD(테스트 주도 개발)에 대한 고민들도 나오게 된다. 개발을 하다보면 한번 쯤은 해볼 수 있는 고민들에 대해서 적어두고 있는 것을 보고 책을 작성 할 때 애정을 많이 쏟았구나 하는 생각이 들었던 책이었다.

하지만 실제로 SRS를 정의하거나 기존에 있는 스펙에서 다시 SRS를 정의하는데에는 시간이 조금 걸리는 부분이라는 생각도 들었다. 기존 스펙에 적용하는 시간이 더 걸리지 않을까... 그래도 해놓으면 좋을 것 같기는 하고

총평

괜찮은 점

> 가독성

소제목이 본문을 잘 요약해주고 있어서 읽기 편하다.

> 다양한 고민이 녹아 있다.

스펙을 정의하고 개발을 하는 시점에서 고민해 볼 수 있는 많은 상황들을 책에 담았다. 인사이트를 많이 주는 책이고 신규 스펙이나 기존 스펙이 변경될 때 책의 내용을 실천해보면 좋을 것 같다는 생각이 들었다.

아쉬운 점

> 책 이미지 아이콘

책 이미지에 있는 아이콘이 조금 이쁘지 않은 경우들이 보인다. 그림을 대충 많은 느낌이 들때가 조금 있다.

스펙이라는 사전적 정의는 설명서, 사양(Specfication)이다. 일반적으로 직장을 구하는 구인인력이 필요한 학력, 학점, 토임 점수 따위를 합해서 말하는 경우가 더 익숙하다.

이 책에서 스펙은 '프로젝트의 모든 요구사항을 취합해 프로젝트의 중심이 되는 문서'로 정의하고 있으며(p.33), SRS(software requirements specification)와 거의 동의어로 사용한다. 2.4절에서는 흔히 혼용해서 사용하고 있는 스펙(specification)과 요구사항(equirement(s))를 명확히 해준다.

다년간의 개발경험과 프로젝트를 경험한 두 베테랑에게 책을 통해 듣는 스펙의 중요성과 각종 프로젝트 경험들. 구구절절 옳은 말과 가슴에 남는 메세지들이다.

특히, 1.2절의 '스펙에 대한 오해'편의 내용이 특히 가슴에 와 닿는다.

-스펙을 적는 것이 좋은 줄 몰라서 안 적는게 아니다

-소프트웨어를 만들어보기 전에는 천재도 그 내용을 다 알 수 없다

-나도 작성할 줄 아는데 쓸 시간이 없다

-나도 작성해봤는데 우리 경우는 달라서 적기 어렵다

-기획팀에서 주는 문서로는 스펙을 적을 수가 없다

-폭포수 모델과 달리 우리는 애자일이라서 잘 적을 필요가 없다

-잘된 샘플을 보고 싶다

-실리콘밸리에서는 한번 적으면 스펙이 변경되지 않는가?

위의 내용중 절반이상 언급해 본적이 있다면, 이 책은 소프트웨어/프로젝트와 연관된 당신에게 큰 도움을 줄 수 있다.

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

4장의 '사례 연구'편은 skip해도 좋고, 가볍게 읽어 보기 좋다. 스펙의 중요성을 일깨우는 계기가 될 수 있었으면 좋겠다.

경험이 적은 엔지니어에게는 좋은 안내서가 될것이며, 이미 개발, 프로젝트 많은 이들에게도 책 여러곳에서 도움될만한 내용들이 하나 가득들어 있다. 책에서 여러차례 설명하고 있듯이 바쁘다는 핑계로 스펙을 기재하는데 투자하는 시간을 아까워하지 말고, 오늘 당장 스펙을 남겨보는 것이 어떨까 싶다. 내가 읽을 글이 아닌 남이 읽을 글이자 내가 다시 필요해 의해 찾아 볼 수 있는 글 말이다.

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

제목만 보고 지루할 것을 각오하였다. 

그런데 너무 잘 읽혔다. 

꼭 이렇게 해야 한다고 가두는 책이 아니라서 좋았다. 

최근 IT업계의 비전공자 비율이 높아지고 있는데,

개인적으로 전공자와 비전공자의 큰 차이는 전공 지식 뿐만 아니라, 소프트웨어 공학 지식이라고 생각합니다.

이 책은 비전공자 뿐만 아니라 전공자에게도 학교의 소프트웨어 공학 과목에서 다루지 않는 실무환경에서의 소프트웨어 공학을 알려줍니다. :)

'소프트웨어를 만들 때 시작점이자 기준점이 되는 것은 소프트웨어 스펙이다'

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

모두 소프트웨어 스펙을 강조하는 말인데요.

소프트웨어 스펙(Sofeware Spec)이란 프로젝트의 모든 요구사항을 취합해 프로젝트의 중심이 되는 문서입니다.

소프트웨에 실무에서 다년간 경험을 가진 두 저자의 책이라 스펙을 작성하는 노하우를 배울 수 있는 책입니다.

소프트웨어 스펙에서는 그 개념과 필요성, SRS, 스펙 작성의 현주소, 사례, 개발단계, 도구 등에 대한 설명으로 되어 있고요.

SRS 작성법에서는 SRS 탬플릿 순서를 따라가며 SRS 작성법을 설명합니다.



이직 후 세 번째 프로젝트를 진행하고 있다. 그도 어느새 끝 무렵.

프로젝트를 할 때마다 피를 토하고 있어서 '일을 일답게 하는 법'에 대해 관심을 가지기 시작했다.

내가 내 일을 아무리 정리하고 단순화하려고 아등바등해도 더 상위 영역에서 일이 일답게 흘러가지 않으면 매번 이렇게 피를 토할 수밖에 없다는 결론에 이르렀다.

소프트웨어 스펙이 뭔지는 모르겠지만 책 표지 뒷면에 있는 소개말을 보고 읽어야겠다 싶어서 고르게 된 책.



"프로젝트를 망치기 전에 알았다면 좋았을 것들"

"무작정 키보드를 두드리는 개발자에서 벗어나 프로젝트 전체를 보는 진짜 실력을 키워보자."

개발자를 하든 다른 일을 하든 뭘 하든, 큰 그림 속에서 꼼꼼하게 디테일을 챙겨가는 사람이 되고 싶다.

아는 만큼 보인다고 했던가. 지금 당장 관리자가 될 수는 없겠지만 계속 안테나를 켜놓고 되도록 많은 걸 경험하고 또 느끼는 게 결국 내 자산이 될 것이라고 믿는다.

그런데 그 '큰 그림'이라는 게 소프트웨어 개발 영역에서는 정말로 크다.

수많은 이해관계자가 얽혀있고 다양한 영역에서의 인사이트가 필요하며 절대적이고 명확한 답이 정해져있지 않다.

책 머리말에서도 이렇게 이야기한다.

스펙을 잘 작성하기 위해서는 실전을 통한 노하우 축적이 필요한데 방법이 잘못되면 경험이 좋은 노하우로 이어지지 않으니 좋은 코치가 필요하고 피드백을 받아야 한다고. 그러나 우리나라 소프트웨어 업계에서는 그런 역량을 갖춘 인물을 찾아보기 힘든 것이 현실이라고. 소프트웨어 개발은 원리를 모르고 무작정 따라 해서는 성과를 낼 수 없으니 원리를 이해하는 데 도움이 되는 이야기를 하겠다고 한다.

그런 책이다.

책은 1부와 2부로 나눠져있다.

1부는 '소프트웨어 스펙이란?'이라는 제목으로 굉장히 다양한 방면의 이야기를 한다.

스펙은 뭐고, 현주소는 어떤지, 기업문화와 프로세스 측면에서도 살펴보고 who? what? how?의 흐름을 통해 자연스럽게 2부 'SRS 작성법'으로 넘어간다.

2부는 SRS 템플릿 순서를 따라가며 작성법을 설명하는데, 무엇보다 실제적인 예제가 곁들여있어서 매우 좋았다. 이런 책은 아무리 이론 설명이 친절하고 자세하다 한들 좋은 예제 하나가 그 모든 것을 뛰어넘는다고 생각하기 때문에. 책이 두꺼워져도 상관없으니 템플릿이 조금 더 다양했으면 하는 아쉬움은 있다.

이런 류의 책들은 외국 서적이 굉장히 많다. 좋은 책도 있지만 읽다 보면 내가 현재 경험하고 느끼는 현실과 너무 동떨어져있다는 생각을 하게 된다. 그래서 잘 걸러듣고 우리나라에 맞게 생각을 보정하는 과정이 꼭 필요한데 이 책은 국내 도서라 현실에 대해 적나라하게 이야기하고 있다는 점이 마음에 들었다. 내가 처한 현실, 그리고 아마도 많은 개발자들이 처해있을 현실을 짚어가며 그게 왜 합당하지 않은지를 이야기하는 부분에서는 위안까지 얻었다.

중간중간 많은 생각을 하게 하는 책이라서 열심히 밑줄 긋고 메모하며 읽었다. 외워서 모든 걸 내 것으로 만들어야겠다, 하며 읽는 책이 아니라 밭에 거름 주는 심정으로 읽는 책이다. 언제나 중요한 건 내가 지금 몸담고 있는 곳에서 나만의 방법을 찾는 것이다. 언젠가 나만의 방법을 찾을 때에 이 책의 내용들이 좋은 거름이 되길. 뭐 거창한 이유가 아니더라도 술술 재밌게 읽기 좋은 책이다. 이런 국내 도서가 많이 나왔으면 한다.



2021년 올해의 책리뷰 / 소프트웨어 스펙의 모든 것 / 한빛미디어

소프트웨어를 개발하는데 가장 중요한 것이 스펙입니다. 이 스펙을 잘 작성하는 방법은 가르칠 수는 있는데 배울 수는 없습니다. 즉, 이론은 체계적으로 잘 짜여져 있지만, 그것을 현실에 적용하기란 어렵습니다. 스펙을 잘 작성하기 위해서는 실전을 통한 노하우의 축적이 필요하며, 개발 문화, 관행, 습관, 프로세스, 원리, 원칙을 알고 접근해야 합니다. 이러한 소프트웨어 스펙의 원리를 이해하고 이를 잘 작성하는 역량을 확보하는 방법을 이 책에서 다루고, 또한 실제 SRS 템플릿을 기준으로 작성할 내용을 설명하고 작성 예를 보여주고 있습니다.

저자는 소프트웨어 프로젝트의 실패의 가장 주요 원인으로 스펙과 관계되어 있다고 합니다. 잘못된 스펙과 요구사항을 관리하는 부분에 있어서 문제가 발생하는데, 이를 해결하는 방법으로 원칙만 지킬 수 있는 최소한의 프로세스 환경에서 좋은 문화를 공유하는 것으로 보고 있고, 스펙의 역할에 대해서 알려주고 있습니다. 그러면서 스펙에 대한 오해에 대해서도 다루고 있습니다. 스펙에도 여러 종류가 있지만, 이 책에서는 SRS(Software Requirements Specification)이라는 문서를 다룹니다. 이 SRS를 통해서 소프트웨어를 어떻게 빠르게 개발할 것인가와 스펙과 프로젝트 일정의 관계를 논하고 있습니다.

스펙의 모든 것을 세세하게 다루고 있습니다. 스펙을 적용하는데 있어서 현행에서의 문제점은 무엇인지 사례를 들어서 설명하고, 스펙을 위한 기업문화는 어떻게 되는 것이 올바른 것인지, 스펙을 적용하는 프로세스는 어떻게 정립해 나가야 하는지, 누가 스펙을 쓰고, 어떻게 이용하는 것인지, 스펙에 어떠한 내용을 어떻게 기입해야 하는지, 어떠한 도구를 이용하여 SRS를 작성해야 하는지 등등을 소개하고 있습니다.

그리고 2부에서는 SRS 작성법을 세세하게 설명하고 있습니다. 시스템 구성, 동작 방식, 개발/테스트 환경, 외부 인터페이스 요구사항, 성능 요구사항, 비기능 요구사항, 기능 요구사항, 변경 관리 프로세스, 최종 승인자 등등의 정보를 어떻게 기입해야하는지에 대해서 설명하고 있고, 이는 현행에 소프트웨어 프로젝트를 진행하면서 많은 도움이 될 것으로 보입니다. 프로젝트에서 스펙에 문제점에 대한 해답을 제시하지는 못하지만, 그 해답을 찾아가는 과정을 알려주는 책이라고 보면 좋을 듯 합니다.

해마다 몇권의 소프트웨어 방법론, 개발론, 인력 관리에 대한 책을 읽어 오고 있다.

스타트업에서 일하면서 기술에 대한 습득 및 개발 방법론, 문서화, 인력에 대한 것을 고민해 왔는데 이번에는 "소프트웨어 스펙의 모든것" 을 읽게 되었다.

먼저 "소프트웨어 스펙의 모든것"은 한국인 저자가 쓴 내용이어서 그런지 막연한 이상을 이야기하지는 않았고 우리나라 현실 프로젝트 현황과 문제점을 정확히 알고 쓰여져 있었다.

문서에 대한 중요성과 그리고 어려움 그리고 현실에 대한 내용을 잘 표현하고 있고 해당 내용을 통해서 왜 스펙이 중요한지 그리고 작성해야 하는지 이유등을 알 수 있었다.

우선 "소프트웨어 스펙의 모든것"을 읽어봐야 할사람은 소프트웨어를 수행하는 모든 사람이지만 그 중에서도 특히 프로젝트 리더, 그리고 발주처d의 업무담당자가 읽어보면 좋을것 같다고 생각한다.

프로젝트 리더가 읽게 된다면 소프트웨어 스펙과 그리고 개발 방법에 대한 전반적인 어려움과 어떻게 해결해야 할지fm를 책을 통해서 체험할 수 있을것 같고 발주처 업무 담당자는 얼마나 무리한 요구및 그리고 소프트웨어가 어떻게 만들어지는지 이해하는 방법이 되지 않을까 생각한다.

최근에 자택근무를 하면서 발주처에 대한 업무 미숙과 그리고 소프트웨어를 이해하지 못하고 진행하는것에 대해서 아쉬움이 있었는데 해당책을 통해서 전반적인 환경과 어떤것이 있는지 이해를 하면 좋을것 같다는 생각이 들었다.

이책의 구성은

1. 소프트웨어 스펙이란 ?

- 10장의 주제로 구성

1장. 소프트웨어 스펙의 개요

2장. SRS

3장. 스펙작성의 현주소, 현실과 관행

4장. 사례 연구

5장. 기업 문화

6장. 프로세스

7장. Who?

8장. What?

9장. How?

10장. 도구

2. SRS 작성법

- 9장의 주제로 구성

1장. Introduction (개요)

2장. Overall Description (전체설명)

3장. Environment (환경)

4장. External Interface Requirements (외부 인터페이스 요구사항)

5장. Performance Requirements (성능 요구사항)

6장. Non-functional Requirements (비기능 요구사항)

7장. Functional Requirements (기능 요구사항)

8장. Change Management Process (변경관리 프로세스)

9장. Document Approvals (최종승인자)

되어 있었다.

1장 소프트웨어 스펙이란 것에서 소프트웨어 개발의 전반적인 현주소와 그리고 SRS 중요성 , 전반적인 소프트웨어 환경에 대한 이해, 스펙에 대한 WHO?, WHAT?, HOW? ,도구등에 대한 설명 및 그림을 통해서 스펙에 대한것을 설명하고 있다. 해당 1장을 읽게되면 왜 스펙 SRS를 작성해야 하는지 충분히 알수 있고 해당문서를 통해 더 나은 소프트웨어를 만들 수 있다고 생각한다.

2장 SRS 작성법은 1장의 스펙에 대한 구체화 및 SRS 작성에 대한 여러 샘플 및 작성 요령을 설명하고 있었다.

프로젝트 관리자가 해당 내용을 통해 제대로만 학습하고 프로젝트에 적용할 수 만 있다면 멋진 스펙문서을 만들고 여러프로젝트에서 활용할 수 있다고 생각한다.

다만 아위운것은 템플릿을 다운로드 받았는데 샘플이 아닌 실제 프로젝트에 대한 예제가 있는 내용이 추가되면 어댔을까 하는 아쉬움이 남았다.

그래도 SRS 작성볍에 있는 예제나 샘플등을 프로젝트에 적용하고 스펙 문서 및 공유 문서를 만들면 멋지게 프로젝트를 완료할수 있다고 생각한다.

마지막으로

장점 : 우리나라 현실과 개발 방법론이 아닌 실제 적용할만한 문서작성법을 배울수 있음

아쉬움 : 템플릿 문서가 여러개가 있었으면 좋았을텐데.

하는 것을 학습하며 이 책을 읽게 되었다.

2000년대부터 지금까지 낮은 취업률은 항상 문제가 되어왔습니다. 더군다나 현재는 코로나때문에 경제난이 닥쳐서 가뜩이나 낮은 취업률이 이제는 매우 소수적으로 되어버렸습니다. 그래서 청년들이나 실업자들에게 취업은 엄청난 부담감과 골치것리가 되었는데요. 제가 이 책을 선택한 이유는 이제 개발자로 취업을 하고자 하시는 분들이 이 책을 보시면 보다 더 성공적으로 바라시는 기업에 취업하실 수 있는 방법을 아실 수 있을거라 생각했기 때문입니다.

이 책의 특성은 개발자로 취업을 원하시는 분들이라면 한번쯤은 해보셨을 프로젝트를 성공적으로 작성하는 방법을 제시하는 것입니다. 좋은 프로젝트일수록 개발자에게 엄청난 커리어를 안겨줄 수 있죠. 하지만 프로젝트를 자신이 생각한 그대로, 만족할 수 있게 완성한다는 것은 매우 어려운 일이라고 생각합니다. 저는 프로젝트를 진행하면서 프로그램을 만들때마다 항상 단점이 보이고 어떠한 기능을 더 추가하면 더 좋을것 같다는 느낌이 자주 들었습니다. 그래서 만족할만한 완성품을 내본 적이 별로 없었습니다. 이야기가 본의를 잠깐 지나갔네요. 아무튼 개발자로 취업을 희망하시는 분들이라면 이 책을 보시면 어떠한 준비를 해야되는지 아실 수 있으실거라 생각하여 이 책을 선택하게 되었습니다.

이제는 프로그래밍을 학습하면은 고등학생, 빠르면 초등학생때부터 프로젝트를 진행하고 프로그램을 만들게 됩니다. 그래서 개발자를 희망하는 사람이라면 기본적으로 2~3개의 프로젝트를 진행한 경험이 있고 그것은 이제 당연시되었습니다. 또 단순히 많은 프로젝트를 한것이 플러스요인이 아닌 어떤 프로젝트를 진행하였고, 어떤 성취를 이루었으며 결과로 어떤 기능을 가진 프로그램을 만들었느냐에 따라 그것이 포트폴리오상에서 플러스 되는 요인이 되었습니다. 따라서 이제는 양보다는 질이 더 중요시해서 준비해야 하는 시대입니다.

구성

1부

Chapter 1: 소프트웨어 스펙의 개요

Chapter 2: SRS

Chapter 3: 스펙 작성의 현주소, 현실과 관행

Chapter 4: 사례 연구

Chapter 5: 기업 문화

Chapter 6: 프로세스

Chapter 7: Who?

Chapter 8: What?

Chapter 9: How?

Chapter 10: 도구

2부

Chapter 1: Introduction

Chapter 2: Overall Description

Chapter 3: Environment

Chapter 4: External Interface Requirments

Chapter 5: Performance Requirments

Chapter 6: Non-functional Requirments

Chapter 7: Functional Requirments

Chapter 8: Change Management Process

Chapter 9: Document Approvals

파트별로 나누어 봤을때 책에서 나와있는 것처럼 1부에서 1~5장은 소프트웨어 스펙이 무엇이며, 그것에 대한 현 관행이나 문제점, 사례, 기업문화 등등을 설명하고 있고 6~10장은 소프트웨어 스펙을 만드는 방법을 단계별로 설명하고 있습니다.

2부에서는 1~9장까지 모두 프로젝트를 통해 개발한 소프트웨어를 스펙처럼 설명하는 법에 대해 설명하고 있습니다.

개인적인 생각으로 학습은 청년 취업자 같이 이제 막 개발자의 길로 들어서시는, 이러한 소프트웨어 스펙을 처음 작성하는 분들이라면 이 책을 2~3번 정독하시고 스펙을 작성하실때도 이 책을 보면서 참고하셨으면 좋을것 같습니다. 그리고 개발자로써 연차가 좀 되시고 스펙을 정돈하실줄 아시는 분들이라면 이 책을 정독하시면서 자신이 그동안 작성하면서 미처 발견하지 못했던 점이나 부족했던 점들은 보완하시는 것이 좋을것 같습니다. 물론 연차가 얼마나 되었든 모두 다 이 책을 자주 정독하시는 것을 추천드립니다.

그리고 개인적으로 약간의 단점이 소프트웨어로 유명한 기업들의 사례가 더 많이 나왔으면 좋았을것 같다는 생각을 들었습니다. 사례가 더 많았다면 각자 자신이 희망하는 기업이 추구하는 이상향을 더 잘알고 준비할 수 있지 않을까라는 아쉬움이 있습니다.



"프로젝트를 성공으로 이끄는 소프트웨어 스펙 작성법"이라는 내용에 알맞은 집약서하고 생각합니다.

소프트웨어 공학의 필요성과 사용법에 대하여 압축하여 잘 설명해주고 있습니다. (어렵지 않아요~!)

당장 스펙이 뭐지?! 라는 고민으로 구글링을 한다면 이책의 2부 부터 보면 됩니다. 약 100 페이지 안되는 정도로 적다면 적고 많다면 많은 내용으로 당장 필요한 정보는 획득 가능합니다.

자세한 내용은 구글링. 간편이해는 앞장으로 돌아가서 하나씩 보기를 권장합니다.

머릿말 다음에 용어 정리도 되어 있으니 이해를 위해서 읽고 외워서 넘어가는 것도 추천합니다.

당장..이미 개발이 끝난 작은 추가 개발 건에라도 적용해보아야 겠다는 생각이 물씬 물씬.

다음 작업 부터는 권장하는 방법을 따라 보기위해 일단 책내용을 정리해야겠네요.

주니어를 넘어서기 위해서, 또는 주니어 막바지?라면 한번쯤은 읽고 이해 해보고 적용해 보기를 추천 드립니다.



이 책을 통해서, 프로젝트 경험이 부족한 초보 개발자부터 이미 경력이 많이 쌓인 개발자까지 추상적으로만 갖고 있던 생각을 정리할 수 있을 것이다.

컴퓨터 공학과에서 팀 프로젝트를 진행해본 경험과 AI기반의 스타트업에서 인턴으로 근무하고 있는 경험을 바탕으로 이 책을 읽으며 공감가는 부분과 미쳐 생각치 못한 부분이 많았다. 특히 책의 앞단에 소프트웨어의 스펙에 대한 오해와 스펙과 설계의 차이점 등에 대한 설명을 읽으며, 추상적으로만 갖고 있던 개념을 조금이나마 정리할 수 있게 된 계기가 되었다.(더 확실하게 정리하기 위해서는 책을 다시 읽고 2장의 SRS작성법을 따라하며 새 프로젝트를 진행해 봐야할 것 같다.)

소프트웨어 스펙에 대한 기본적인 개념과 스펙 작성의 중요성, 잘못된 스펙 작성으로 인한 문제점과 사례 등의 순서로 내용이 진행되며 읽는 것에 대한 큰 부담감은 들지 않는다. 다만 많은 내용을 다루다 보니 조금은 지루하게 느껴질 수도 있다. 하지만 그만큼 배우는 것이 많은 게 장점인 책이다.

앞서 말했듯, 초보 개발자부터 경력자가 봐도 좋은 책이지만, 특히 곧 개발자로서 취업준비를 하는 나로서는 아주 도움이 많이 되는 책이다. 물론 실무와 어느 정도 차이가 있겠지마는, 개발자로서 알아둬야 하는 내용을 인수인계받은 느낌을 받았다. 그동안 진행한 프로젝트에서 작성한 소프트웨어 스펙에서 누락된 내용이나 프로젝트 진행과정에서 아쉬웠던 부분들을 회상하며, 앞으로 프로젝트 진행을 할 때마다 들여다 볼 책인 것 같다.

소프트웨어 스펙의 모든 것 - 김익환, 전규현 저 

## 책의 구성 및 평가 

소프트웨어 개발에 있어, 스펙 명세의 중요성과 그 방법에 대해 서술 해 놓은 책입니다.

1부에서는 소프트웨어 스펙이 어떠한 것인지, 스펙을 작성하지 않았을 때의 문제점 등 스펙이 왜 필요하고, 스펙이 어떤 것인지를 서술 하고 있으며, 2부에서는 스펙의 구체적인 작성 법에 대해 서술 하고 있습니다. 

책에서 많은 내용을 다루고 있고, 처음 들을법한 이야기도 많으나 사례 중심으로 잘 적혀 있어 이해하는데 큰 어려움이 없습니다. 또, 실질적인 스펙 작성법에 있어서도 사례 중심으로 잘 설명해주어 추상적인 내용을 구체화 하여 받아들이는데 큰 어려움은 없었습니다. 

 하지만, SRS 스펙 문서를 작성하지 않았을 시에 대한 단점, SRS를 작성하면 좋은 점이 책의 초반부에 장황하게 나열되어 있어 처음에 글을 읽는데 어려움이 있을 수 있습니다. 문서를 제대로 작성하지 않았을 시의 단점을 너무 많이 제시 해 주는 반면에, 그에 대한 해답은 책의 뒷편에 있는 편이라 그래서 어떻게 해야 하는데 ? 라는 의문이 계속해서 떠올라 답답하게 느껴지기도 했습니다. 

 이 책은, 현재 주니어 개발자인 제가 읽기에는 너무 이른 감이 없지않아 있다고 생각은 들었지만, 다양한 사례와, 넓은 시야로 회사 프로젝트를 바라보는 시야를 가질 수 있는 좋은 경험이었습니다. 

- 위 서평은 한빛미디어 '나는 리뷰어다` 서평단 자격으로 책을 무료로 제공받아 작성된 서평임을 밝힙니다.

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

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

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

✔️직업 : 개발자

✔️경력 : 6년

✔️환경 : IT 스타트업 경험이 전부

              (첫 회사(약 6명) -> 두번째 회사(약 20명) -> 세번째 회사(약 120명))

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

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

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

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

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

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

프로젝트를 하면서 느낀 것은 사람들은 시스템으로 원하는 것이 어떤 것을 원하는지 잘 모른다

요구사항은 프로젝트를 하면서 계속 변경된다.

원하는 데로 만들고 나면 그것을 보면서 자신의 생각하는 것이 아니라고 한다.

그러면 다시 재작업을 하면서 시간은 점점 소요되곤 한다.

이 책을 보면서 스펙이란 것의 중요성을 다시 한번 생각하게 되었다.

공감하는 내용이 잘된 샘플을 가지고 적용하고 싶지만,

'남들이 만들어 놓은 샘플을 보는 것보다 스스로 많이 생각하면서 직접 맨땅에 부딪혀보는 것이 더 현명하다'라는 문구였다.

프로젝트는 스펙에 대한 많이 고민하면서 나에게 많은 지침서가 될 수 있을 듯하다.

누구나 중요하다고 생각하지만 아무도 잘 모르는 소프트웨어 스펙에 대해서 많이 고민하게 해준 책이다.

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

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

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

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

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

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

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

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

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

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

원문 블로그 : https://erinyees.tistory.com/36

리뷰어's 잡담

저는 소프트웨어 공학이라는 과목을 제 복수 전공들 과목들 중에 가장 자신있고 결과도 좋고, 재미있었던 과목이었습니다. 좋은 성적으로 해당 과목을 담당하시는 교수님으로부터 연구소 프로젝트 참여를 제안받아서 반년간 함께하게 되고, 제가 많이 성장하는 시간도 가질 수 있게 해준 기억이 있습니다. 소프트웨어 공학은 소프트웨어 프로젝트와 관련된 스펙, SRS, 설계, 테스팅, 프로세스 등등에 관한 내용을 다루는 학문으로, 현업 직무를 해보니 많은 관련이 있는 좋은 과목이었다고 생각합니다. 이번에 제가 리뷰어로서 작성해 볼 책이 이와 관련이 깊은 내용의 '소프트웨어 스펙의 모든 것'입니다. 저는 연구소에서 프로젝트를 진행하면서 SRS를 보고, 작성해보기도 했습니다. 명확한 SRS는 개발자의 혼돈을 줄이고 더 자세한 설계를 진행할 수 있습니다. 그런 점에서 이 책을 한번 읽어보면 좋을 것 같습니다.

누가 읽으면 좋을까?

여기서는 소프트웨어 스펙이라고 하지만 학사 출신으로서 가장 관련된 전공과목이라고 한다면 소프트웨어 공학 과목입니다. 컴퓨터 분야에 앞으로 종사 또는 이미 계신 분들도 읽어보기 좋은 간단한 책이며, 제 생각에 설명과 그림이 아주 심플하고 사례가 많아서 관련된 모든 분들이 잠깐잠깐 가볍게 읽으면 좋을 것 같습니다.

책의 구성

책의 구성은 크게 보면 간단하며 이론과 실전으로 구분을 해도 될 만한 내용이라고 생각합니다.

1. 소프트웨어 스펙이란?

   전체적인 개요부터 SRS, 관행과 사례 등등의 내용이 있고, 점점 더 디테일한 부분을 간단한 그림과 예제로 쉽게 설명을 해줍니다.

2. SRS 작성법

   실제의 예제들을 기준으로 간결하고 깔끔하게 설명해줍니다. 실수할 수 있는 부분에 대해서도 많은 설명이 나와있어서 그 부분이 좋았습니다.

SRS와 설계

제가 설계에 대한 개념이 없을 때 저는 소프트웨어 공학 및 설계 과목을 들었습니다. 유저의 관점, 개발자의 관점에서 다양한 설계를 해보면서 기본적인 방법을 익혔고, 연구소의 큰 프로젝트를 진행하면서 더 구체적인 SRS 작성부터 설계 및 구현까지 진행해보았습니다. SRS를 잘 작성만 해놓아도, 많은 충돌을 해결할 수 있습니다. SRS와 이를 바탕으로 진행 한 설계가 프로젝트 구현을 쉽게 만들어주고, 실수를 줄여줍니다. 어찌보면 프로젝트에서 가장 중요한 부분이고, 나중에 유지보수도 쉽고 오류가 적게 만들어줄 수 있습니다. 저도 이와 관련된 내용으로 포스팅이 존재합니다.

다양한 예제를 통해 실전 프로젝트에 SRS을 작성해보자!

2장의 SRS 작성법에는 구체적인 실제 SRS 템플릿으로 내용 설명 및 팁, 예제 등을 제공해줍니다. 이를 보면서 자신이 해보고자 하는 실제 프로젝트의 시작단계에서 간단한 SRS를 작성해보면 좋을 것 같습니다. 이를 바탕으로 설계도 해보고, 실제 구현에서 얼마나 많은 도움이 되며, 소프트웨어를 처음 보는 사람도 이해를 잘할 수 있는지에 대한 것도 한번 살펴보면 좋을 것 같습니다.

출처: https://davinci-ai.tistory.com/58 [DAVINCI - AI]

스펙이 사람의 역량으로 명명되고 있는 시대, 그래서 더 다양하게 사양되는 단어이기도 합니다.

그리고 프로젝트를 성공으로 이끄는 소프트웨어 스펙 작성법으로 소프트웨어 스펙의 모든 것이 출간되었습니다.

개인적으로는 책 뒷면에 SRS 프로젝트를 망치기 전에 알았다면 좋았을 것들이 소제목이었거나, 앞 페이지에 수식어였다면, 좀 더 명확하게 다가오지 않았을까 생각도 해 봅니다. 하지만 결국은 프로젝트 성공인 것은 마찬가지 입니다.

소프트웨어개발사라는 그리고 개발자라면 항시 고민하게 되는 소프트웨어공학적인 접근과 실제의 괴리감입니다.

프로젝트가 우선이기에 스펙없이 개발을 하다가 돌이키거나, 유지보수에서 전체 소프트웨어를 뜯어고치는 경우는 책에서만이 아니라는 것이다. 그런면에서 이 책은 실제사례를 A사, B사 이렇게 표현하면서 이야기 하고 있습니다. 진단을 위한 실제 사례들을 다루어서 좀 더 현장감이 있다는 겁니다. 

실제로 많은 책들이 실제 다양한 사례들을 현장감있게 정리하는 것조차도 어려운 작업이고, 무엇보다 그래서 어떻게 해야 하는지를 독자에게 맡기는 경우가 많다는 것이다.  문제를 공감하지만 어떻게 약하다는 것이다. 하지만 스펙에 없을 때 등한시 했을 때 사례들과 문제점을 정리하고 스펙을 통해 가져올 수 있는 이점을 정리했고, 더 나아가 스펙을 작성하는 방법은 2부에서 상세히 다루고 있다는 것입니다.

어쩌면 전사적인 활동으로 가능한 일 일수도 있고, 단순히 일회성으로는 유지가 되지 않는 것도 사실입니다. 하지만, 필요에 의하여 하게된다면 보다 체계적으로 진행해야 하는 것이다. 그런면에서 가이드가 되어 줄 책이라고 봅니다. 

소프트웨어 스펙의 모든것

SRS 프로젝트를 망치기 전에 알앗다면 좋았을 것들, 부정적인 문장이지만 그래도 공감도할 수 있는 문장이다.

한빛미디어의 미리보기를 통해서 책의 내용을 참조할 수 있어서, 책의 어떤 내용인지 맛을 볼수 있습니다.

https://preview2.hanbit.co.kr/books/gkws/#p=1

SRS

SRS

SRS, SRS하는데 SRS가 몬가요?

Software Requrements Specification 소프트웨어 스펙, spec, 소프트웨어 요구사항을 분석하고 이를 정리해 작성하는 스펙 문서이다.

그럼 요구사항아인가요. 스펙하고 요구사항은 무엇이 다른가요? 책을 읽어보니 개인적으로 스펙 > 요구사항라고 생각이 듭니다. 

스펙의 구성, 3W

비즈니스 요구사항도 함께 작성이 된다는 것이다.

프로젝트 단계별로

그렇게 모든 것을 이야기 합니다.

프로젝트 성공을 위한 발걸음입니다.

책의 구성은 2부로 구성되어 있습니다. 1부 소프트웨어 스펙이란? 2부 SRS 작성볍

스펙 작성법 중

저자의 경력을 보면 실리콘밸리에서 시작되어, 국내 회사까지 두루 두루 경력이 스펙을 정리합니다. 그래서 단순히 이론에서 끝나지 않는 것 같습니다.

전체적으로 책도 잘 읽혀집니다. 저자가 개발자의 글쓰기에 대하여서도 언급했는데, 명확하게 내용이 들어와서 구성과 내용도 대단히 만목합니다.

책은 크게 1부와 2부로 구성되며 1부에서는 소프트웨어 스펙의 전반적 개념, 2부에서는 소프트웨어 스펙 작성법 중 하나인 'SRS'을 설명한다

도서 초입에 프로젝트 성공/실패와 소프트웨어 스펙의 연관성을 설명하여 중요성을 강조하지만, 현업에서 오가는 말들을 통해 소프트웨어 스펙 정의의 현실을 보여준다 추가로 실제 프로젝트 사례를 나열하여 안타까운 현실과 스펙 정의의 중요성을 다시 한번 강조한다

중반부에는 소프트웨어 스펙 작성 외 프로젝트 성공을 위한 조건 및 자세를 설명한다 회사는 공유 문화가 만연하고, 각 팀들은 역할 분담을 정확히 하여 병렬적으로 일을 수행하면 프로젝트는 성공적으로 끝낼 수 있다고 한다 여기서 개인은 공유 문화를 위해 수평적으로 협업하고 개발, 테스트, 인증 팀들은 짧은 주기로 공유하고 협업하여 효율적인 시스템을 유지해야한다고 한다

후반부에는 위에 서술했던 'SRS' 작성을 구체적인 예시를 들어 설명하고 문서 작성 능력의 성장을 위해 꾸준히 작성할 것을 도모하며 마무리한다

이 책은 개발 프로젝트의 성공을 위해 소프트웨어 스펙의 중요성을 강조한다 

소프트웨어 스펙이 개발 기간, 개발 범위, 진행 사항, 팀원 혹은 팀 간 역할 분담, 고도화 계획 등 많은 것을 망라함을 말하는데 공감과 놀라움을 반복하며 읽었다 특히 소프트웨어가 미치는 부서의 영향 범위에 놀랐고, 여러 부서가 공동체로 움직였을 때 상상되는 파급력이 거대한 공룡처럼 느껴졌다 책의 일부에서 스펙과 스펙이 아닌 것을 정리해 준 부분을 읽을 땐 현업에서 나의 경험을 떠올리며 얼마나 형편 없게 작성했는지 부끄러움을 느꼈다

감상평에 일일이 적을 수 없을 만큼 중요한 내용이 많이 담긴 책인건 확실하다 그렇지만 몇 가지 아쉬운 점도 있다 

소프트웨어 스펙의 미치는 영향력을 설명하기 위해 A부터 Z까지 담으려고 한 의도는 알겠으나 범위가 너무 광대하여 집중하기 어려웠다 포괄적인 범위는 '이 것까지 고려해야하나..?' 싶은 의구심이 들었고 개발자라면 주니어에서 시니어로 넘어가는 개발자에게 적합하다고 느껴졌다 또한 마지막에 'SRS' 작성을 위해 구체적 예시도 설명해주며 이해하기 쉽게 쓰였지만 책에서 SRS 작성법 분량이 적지 않아 'SRS'를 작성하지 않는 사람이 읽기에는 아쉬움이 느껴질 것 같았다

책 제목을 내 마음대로 응용하여 감상평을 마무리 한다

소트트웨어 스펙의 모든 것(부제: 성공적인 개발 프로젝트를 위해 필요한 것, 그리고 SRS)

김익환 님의 책들의 특징은 편안한 문체로 담담하게 서술하지만, 개발자로서 평소에 답답해하던 부분을 예리하게 집어 준다는 데 있는 것 같습니다. 이 책도 그러했고, 재미있게 읽었습니다.

폭포수 모델과 달리 우리는 애자일이라서 잘 적을 필요가 없다.

스펙 작성은 폭포수 모델에서나 하는 것이라는 생각은 오해다. 그런데 안타깝게도 스펙 작성이 어렵다는 귀에 익은 소문을 듣고 애자일을 선택하는 회사도 있다. 이 또한 애자일을 적용하면 어렵게 스펙을 작성하지 않아도 된다는 잘못된 생각에서 비롯된 것이다. 실무에서 폭포수 모델을 사용하는 소프트웨어 회사는 거의 없다. 방법론과 상관없이 소프트웨어 스펙은 중요하다. 애자일이라 하더라도 스펙 내용은 바뀌지 않는다. 적는 방법이 달라질 뿐이다. 폭포수 모델에서 소프트웨어 스펙을 잘 작성할 수 있다면 애자일을 적용한 프로젝트에서도 효율적으로 스펙을 작성할 수 있다. 애자일을 적용한 프로젝트에서도 스펙은 잘 작성해야 한다.

1.2 스펙에 대한 오해 ( 본문 31페이지 )

이 책의 전체 내용을 모두 담은 문장이 아닌가 싶어 가져와 봤습니다.

제가 본 이 책의 내용은 크게 두가지 입니다.

첫째, 이 책은 소프트웨어 개발 중 "스펙 작성"에 대한 이야기를 하고 있습니다. 전작들에서도 스펙작성에 대해서 꽤 강조하시는 편이었는데요. 이번 책은 아예 스펙 자체에 대해서 소상하게 설명하고 있습니다. 아마 이렇게 스펙을 소상하게 그리고 쉽게 서술한 책은 없지 않을까 싶습니다. 저자들에게 정말 감사의 말씀을 전하고 싶을 정도입니다.

둘째, 몇가지 오해에 대해서 언급하는 부분들이 있습니다.애자일은 스펙을 작성하지 않는다던가, 실무에서 우리가 어떤 개발방법을 쓰고 있다는 착각에 대한 이야기 입니다.

저자들은 전작들에서도 스펙의 중요성을 이야기 하곤했습니다.  "소프트웨어 개발의 모든것"에서 "소프트웨어 프로젝트 팀의 역량 평가표"를 제시하는데요. 20개 항목중 4가지가 스펙에 대한 겁니다.

10. 프로젝트의 스펙 문서를 가지고 있다

11. 스펙문서를 모든 관련자가 충분히 리뷰한다.

12. 스펙이 바뀜에 따라 스펙문서가 업데이트되고 있다.

13. 스펙 변경이 통제 관리되고 있다

" 소프웨어 개발의 모든 것 "

​

그만큼 스펙이 소프트웨어 프로젝트 팀의 역량에 중요한 요소인 셈이죠.

물론, "글로벌 소프트웨어를 꿈꾸다"에서도 여러군데 스펙문서를 강조하는 이야기가 나옵니다.

그러나 진실은 이렇다. 모든 소프트웨어 회사는 스펙을 작성해야 하고, 변화무쌍한 고객과 스펙을 조율하며 살아야 하고, 또 빡빡한 일정은 당연한 것이고, 그 일정에 맞추어 어려운 프로젝트를 수행해야 한다. 그러기 위해서는 회사에 잘 정비된 조직, 적절한 프로세스 유연한 문서작성법, 개발을 도와주는 기반시스템, 이런 것들을 수용하는 문화 등이 정리되어야 한다. 많은 부분이 경영진의 책임임은 말할 것도 없다.

글로벌 소프트웨어를 꿈꾸다 - 22 소프트웨어 회사의 종류

그래서 아마 이 책도 나온것 아닌가 싶군요. 저자들은 책을 두 부분으로 나누어서 서술했는데요. 1부에서는 스펙에 대해서 독자들이 이해할 수 있도록 다양한 방식으로 설명했고요. 2부에서는 스펙을 작성하는 방법을 서술했습니다.

소프트웨어 개발에 대해 "체계"라는 것을 만들고 싶은 관리자들이 있다면, 이 책이 상당히 큰 도움이 될 겁니다. 특히 저자들은 컨설팅도 하시는 것으로 알고 있는데요. 컨설팅 의뢰를 하시는 것도 좋은 방법이 아닐까 싶습니다.

리뷰를 시작하기 앞서

운좋게 한빛미디어 도서 서평단에 선정이 되서 책을 리뷰할 수 있는 좋은 기회가 찾아왔다.

나는 주니어 개발자임을 앞서 알리고, 책을 읽은 시점이 주니어 개발자의 시점이라고 봐주셨으면 좋겠다.

책의 목차

이 책은 크게 두 부분으로 나뉜다. 1부에서는 소프트웨어 스펙이란? 이라는 주제를 다루고, 2부에서는 스펙이라고도 하는 SRS 작성법에 대해 다룬다.

책 소개

나는 책을 읽기 전 스펙 작성이 그렇게 중요한가? 라는 생각을 항상 갖고 있었다. 학교 프로젝트를 할 때 나는 항상 스펙을 간단히 적거나 혹은 아예 적지 않고 바로 개발에 들어가곤 했었다. 하지만 이 책을 읽고나서 그러한 생각들이 아예 싹 사라졌다. 이 책은 나의 그러한 생각을 바꿀 수 있게 스펙을 써야하는 이유와 스펙을 안쓰거나 대충 작성할 경우에 일어날 수 있는 일들을 사례를 하나하나 들어가며 친절하게 설명해준다.

또한, 스펙에 대해 Who, What, How 세가지 키워드로 분리하여 스펙은 어떻게 써야 제대로 잘 쓸 수 있는지를 알려주는 지침서가 되주기도 한다.

마지막 2부에서는 실제로 SRS 즉, 스펙 문서 작성법을 어떻게 작성하는지 목차부터 시작해 자세한 예시를 들어서 설명해 주는 책이기도 하다.

나는 이 책을 읽고나서 스펙을 왜써야 하는지, 스펙을 어떻게 써야하는지, 스펙을 쓰는 이유가 무엇인지에 알게되었고 앞으로 스펙문서를 쓰면서 항상 참고를 해볼만한 좋은 지침서가 하나 나온 것 같다.

이 책을 살지말지 고민하거나, 나처럼 위와 같은 고민들을 갖고 있다면 이 책에서 정답을 찾을 수 있을 것 같다.

주니어 개발자라면 대략적인 스펙 문서의 흐름을 터득하기에 좋을 것 같고, 시니어 개발자라면 스펙 문서의 교과서 같은 책이 아닐까 싶다.

이 책의 머리말 중 가장 멋있던 말을 하나 남기며 소개를 끝낼까 한다.

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

-프레드릭 브룩스-

마치며

책을 읽으며 소프트웨어 개발이 단순히 개발 능력이 중요한 것이 아니라 설계하는 것이 얼마나 중요한지 깨닫게 되었다.

앞으로 이 책을 참고하며 개발을 할 때 스펙을 작성하는 법을 천천히 터득해가는 것도 좋은 경험이 될 것 같다.

만약, 스펙에 관해 어떻게 써야할지를 몰라 인터넷을 돌아다니다가 이 글을 보게 된다면 과감하게 소프트웨어 스펙의 모든 것을 추천하고 싶다.

개발자로서 스펙을 많이 작성했지만 아직도 매번 어려운 게 스펙 작성이다. 여러 가지 사항을 고려해야 하고 여러 사람들과 협의를 해야 하고 작성 이후에도 배포하고 운영하는 과정에서 나오는 여러 가지 문제 등 정말 제품의 시작과 끝을 함께하는 녀석이 아닐까 싶다.

항상 해오는 것들이지만 다시한번 곰곰이 생각하게 되는 책의 내용에서 제법 많은 부분을 생각하게 되었다. 내가 기존에 정답이라 생각했던 게 그렇게 정답은 아니라는 거, 간과하고 지나쳤던 부분들이 실제로는 많이 중요하단 거. 그런 것들을 중간중간 보다 보니 책 읽는 재미가 있다.

특히나 스펙에 포함되어야 되는 부분들에서 인터페이스, 하위 호환성 부분들은 놓치고 지나치기 쉬운 부분들이라 밑줄 그어놔야 겠다. 

개발자로서 많은 시간을 보냈던 나로서는 부실한 분석의 스펙이 얼마나 차후에 큰 어려움을 다가오는지 뼈저리게 알기때문에 책의 한 줄 한 줄이 참 크게 와 닿았던 것 같다. 팀의 매니저로 선임연구원 정도에게 추천하고 싶은 책이다.

이 책은 한빛미디어에서 협찬 받았습니다.

1.책을 읽기 전에

전 소프트웨어 자문 및 개발을 하는 소프트웨어 사업자입니다.

그래서 책 제목이 아주 마음에 들었습니다. 소 제목을 소개하자면

"프로젝트를 성공으로 이끄는 소프트웨어 스펙 작성법"입니다.

저 같은 소프트웨어 사업자는 꼭 읽어야 하는 필독서처럼 보였고 설레임으로 다가왔습니다.

내 돈 주고 산 책은 아니고 한빛미디어 리뷰어로 참여해서 받은 책입니다.

여러 종류의 책 중에서 다른 책은 관심 밖이었고 이 책을 제일 먼저 선택했습니다.

왜냐하면 수 년간 이 업을 해오면서 고충사항이기도 한 스펙 작성"에 대한 내용이기 때문입니다.

제가 하는 일에 직접적으로 도움이 되겠구나 생각했습니다.

2.책을 읽고 난 후

  책을 읽기 전에도 예상했지만 다양한 프로젝트의 실패 사례를 소개하고 있습니다.

저도 실무에서 직접 겪었던 일이기에 공감되는 부분이 많았습니다.

프로젝트는 사람이 하기에 결국은 그 프로젝트를 이끄는 매니저(PM,PL이라고 많이 부름)의 역량에 따라 성공과 실패로 나뉘기도 합니다.

저는 ERP 프로젝트를 여러차례 수행한 프로젝트 매니저이기도 합니다. 

이 책에서 다루는 SRS 템플릿과도 사뭇 다른 문서이지만 스펙을 작성했었습니다.

단지 덜 체계적이고 그 핵심 포인트가 빗나갔던 것 같기는 합니다.

전산정보처리 업종에서 년수만 따지면 28년이라는 시간이 흘렀습니다.

꽤 긴 시간동안 성공적인 프로젝트를 수행하기 위한 다양한 방법론을 공부했습니다.

저자 두 분 역시 개발을 한 경험자분이기에 책의 내용 또한 충실하다고 생각하고 신뢰합니다.

  1부에서는 SRS에 대해서 이야기 하는데 전체 페이지중 25쪽부터 250쪽까지입니다. 

상당히 길게 이야기 합니다.1부는 다소 지루한 면도 있었습니다.

작성하는 방법은 언제 나오나하고 상당히 조바심도 생겼습니다.

드디어 2부는 SRS 작성법입니다. 251쪽부터 347쪽인데 1부에 비해 상대적으로 내용이 많지 않습니다. 

전부 읽고 나니까 굳이 첫 페이지부터 읽을 필요나 있었나 하고 후회가 됩니다.

예비 독자분들은 2부인 SRS 작성법부터 먼저 읽어도 좋을 것 같습니다.

그리고 1부로 넘어와도 내용 연결에는 큰 불편함이 없을 것 같습니다.

  책을 전부 읽고 난 후 느낀 점을 한 마디로 표현하자면 이렇습니다.

SRS라는 용어는 처음 접했고 그 중요성을 새삼 다시 깨닫게 되었다는 것입니다.

그리고 고민거리도 생겼습니다.스펙을 언제 작성해야 하냐는 것입니다.(외주 프로젝트의 경우를 말합니다.)

물론 이 책에서는 스펙에 대해서 긴 지면을 통해 많은 이야기를 하고 있고 작성법 또한 상세하게 적혀 있습니다.

  매번 고객들과 상담할 때 했던 이야기가 떠오릅니다.

고객들은 간단한 정보만 주고 견적서를 요구합니다.

저는 그때마다 항상 똑같은 이야기를 합니다. 대략적인 견적을 드릴 수는 있지만 추후 변경될 수 있습니다.

대략적인 견적이든 확정 견적이든 한번 견적서를 제출하면 금액이 내려 갈 수는 있지만 올리기는 어렵다고 생각합니다.

그렇다고 처음부터 변동될 것을 대비하여 높은 견적을 내기도 어렵습니다. 업체 선정 검토 대상에서 제외될 수 있기 때문입니다.

  이와같은 고민때문에 저는 상세한 요구사항을 요구하지만 이에 호응하여 대응하는 고객은 그리 많지 않습니다.

입장을 바꿔 놓고 생각해 보면 그 이유를 알 수 있습니다.

최소한의 정보만을 제공하고 대략적인 견적을 복수의 업체에게 받아서 1차 검토대상 업체를 선정할 수도 있겠다는 생각이 듭니다.

  소프트웨어 프로젝트 실패의 원인은 많지만 제가 생각하는 원인 하나는 견적 관리입니다.

프로젝트의 시작은 견적인데 첫 단추부터 제대로 처리하지 못하는 것입니다. 

두번째 실패의 원인이 부실한 스펙의 작성이라고 생각합니다.

3.스펙 작성의 중요성과 현실

  책을 읽다 보면 스펙 작성은 꼭 필요하다고 공감합니다.빠르게 그리고 품질은 좋게 만들어야 겠지요?(다 알고 있는 사실입니다)

하지만 문제가 하나 있습니다. 바로 스펙을 작성하는 시점입니다.(외주 프로젝트의 경우)

더 구체적으로 이야기하자면 계약 전에 하느냐 아니면 계약 후에 하느냐의 문제입니다.

전 이 이야기를 꼭 하고 싶습니다.

구매 발주자가 아닌 소프트웨어 사업자 입장에서는 계약 이전 단계에서 스펙을 작성하는 게 맞다고 생각합니다.

이런 이야기를 하는 이유는 종종 견적단계에서는 대략적인 내용만 파악하고 계약 후에 상세한 스펙 작성을 하는 경우가 있어서입니다.

(계약 전에 작성해야 상호 피해가 줄어 든다는 표현이 더 맞을 수도 있겠다는 생각이 듭니다.)

쉽게 말해 프로젝트의 성패가 갈릴 수도 있을거라 생각합니다.

  책에서는 요구분석 단계에서 SRS 작성을 한다고 말하고 있습니다.

물론 자사 제품을 만들 경우에는 큰 문제가 없겠지만 프로젝트를 외주업체에 맡기는 경우는 다르다고 생각합니다.

아웃소싱의 경우에는 이 단계에서 작성하면 안된다고 생각합니다. 

  프로젝트의 크기도 제대로 파악하지 못하고(스펙도 모른체) 계약을 할 수 있냐는 것입니다. 

이미 계약금은 입금되었을테고 알수 없는 리스크를 안고 프로젝트가 시작된 것이라 생각합니다.(프로젝트 중단 또는 실패로 끝날 수 있을 것입니다.)

그렇다면 요구분석을 다 끝내고 계약을 하면 되지 않느냐고 되물어 볼 것 같습니다.

이 문제는 한번 심도있게 생각해 봐야 할 것 같습니다. 

  긴 시간동안 고객(발주자)과 대면하면서 무상으로 분석을 해 줄수 있느냐,

아니면 분석비용을 받고 요구분석을 하느냐의 선택이 필요합니다.

그리고 발주자 입장에서 프로젝트를 수행업체 선정여부도 결정하지 않은 상태에서

기업의 상세한 정보를 제공할 수 있느냐의 문제도 생길 수 있습니다.(보안상의 문제가 발생하는 것입니다.)

4.마무리

  그렇다면 프로젝트 성공을 위해 어떻게 해야 할까요? 어려운 문제입니다.

전 계약하지 않고도 간단한 핵심 데모를 만들어 시연해 주기도 했습니다.

그리고 요구 분석은 1도 하지 않고 계약서에 도장부터 먼저 찍고 프로젝트를 진행한 적도 있습니다.

그렇다고 해서 제가 기술적으로 뛰어나지도 않고 영업적인 테크닉도 전혀 없습니다.

어려운 환경속에서 어떻게 살아남을 지를 고민하고 스펙 작성의 노하우를 터득하기 위해

노력하고자 합니다.

이 책은 저 같은 소프트웨어 사업자분들께서 한번쯤 읽어 보셔도 좋을 것 같습니다.

긴 글 읽어 주셔서 감사드립니다. 대한민국에서 소프트웨어 개발을 해 본 솔직한 후기였습니다.

2021.02.16

개인적으로 프로젝트에 돌입할 때마다 스펙이라는 문서를 읽고 쓸 기회를 접하며, 덕질하는 시간에는 오픈 소스 문서 번역등에 기여해 본 경험이 있기에 언제고 기회가 되면 소프트웨어 스펙 작성법에 대해 진지하게 배우고 고민해봐야 겠다는 생각을 했는데 마침 적합한 책이 등장하여 리뷰를 남긴다.

본 책의 메인 주제인 SRS란 소프트웨어 요구 명세를 의미하며 스펙이라고도 부른다. 구체적인 실체를 알고 싶다면 아래 링크를 클릭하여 저자가 소개하는 템플릿을 다운로드 하여 확인하기 바란다.

SRS Template 다운로드

이 책은 SRS를 작성하는 방법을 다루는 책으로 Who, What, How 등 다각도에서 고민해보며 기업 문화까지 스펙에 녹이고자 노력하는 진솔함이 돋보이는 책이다.

저자는 2000년 초반에 출간된 “대한민국에는 소프트웨어가 없다.” 책의 저자이기도 하다. 당시 대한민국의 찍어내기식 사농공상 문화에 회의를 느꼈기에 책을 읽으며 많은 생각을 하였다.

S/W 중심의 대한민국의 경쟁력 향상을 위해 개발자, 정부, 기업 등에 강한 일침을 가한 내용이 인상적이었는데 20년 가까이 지나 당시의 조언에 실리콘밸리식 문화와 커리어가 가미된 본 도서를 읽게 되니 감회가 새로웠다.

컴퓨터 공학을 전공한 사람이라면 대부분 소프트웨어 공학 만큼 재미없는 전공 과목을 찾기도 어려울 것이다. 코딩을 통해 눈으로 결과를 보는 과정도 없고 실무 경험도 전무한 대학생이 사상 누각 형태로 장님이 코끼리 다리 만지듯 저 위에 떠 있는 실체없는 공학을 이해하고자 노력하는 것은 정말 답답한 노릇이 아닐 수 없다.

문제는 이 현상이 기업에 입사하여 시니어가 되어도 지속된다는 점에 있다. 하나의 프로젝트를 모두 총괄하는 사람이 되어보기 전까지는 이런 총체적인 눈을 필요로 하지 않기 때문이다. 게다가 경험 미숙으로 스펙에 대한 내용이 구체적으로 와 닿을리도 만무하다.

그런 측면에서 본 도서는 스펙을 작성하는 일이 따분함을 넘어서 왜 어려운지, SRS의 실체는 무엇인지 설명하기 위해 많은 지면을 할애한다.

스펙에 대한 회사 구성원의 오해는 어떤 것들이 있는지, 스펙과 유사한 설계 및 요구사항과의 차이점은 무엇인지, 현재 스펙과 관련된 악습과 관행은 무엇인지, 기업 문화가 스펙에 왜 반영되어야 하는지, 스펙을 제대로 작성하지 못해 발생하는 실제 사례들은 어떤 것이 있는지 살펴본다. 2부에서는 실제 사례를 중심으로 SRS를 작성하는 예시도 소개된다.

스펙이 작성하기 어렵다는 것은 저자도 충분히 공감하고 인정하기에 이를 작성하는 딱딱한 매뉴얼에서 벗어나 예시, 차이, 관점의 변화, 기업 문화, 영향 사례를 다각도로 짚어보며 스펙을 최대한 알기 쉽게 설명하고자 노력한 점이 책의 백미이다.

이 책에는 SRS의 작성법 외에 또 다른 가치가 숨어있다. PM, 아키텍트 이상의 관리자에게 필수적인 프로젝트가 실패하는 이유, SRS를 통해 소프트웨어를 최단 시간 내 개발하는 법, 기업 문화와 사람 관리에 대한 방법에도 포커싱을 맞추고 있다.

사실 이 모든 내용들이 올바른 방향으로 선행되어야 의미있는 SRS를 작성할 수 있음을 강조하고 있다. 그저 작성 요령만 갖출것이 아니라 개발문화, 관행, 습관, 프로세스, 원리, 원칙들이 모두 녹아있어야 좋은 SRS를 작성할 수 있다는 의미이다.

SRS의 중요성을 인식하기 위해 책에서 제시하는 여러 예시 중 특히 인상 깊었던 것 2개를 꼽아보려 한다. 하나는 모든 프로젝트 이해관계자를 연결하는 중심이라는 점이다. 이 덕분에 제품이 완성되지 않아도 영업팀은 사전 판매에 돌입할 수 있으며, 인증도 사전에 취득할 수 있게 된다.

다음은 1:10:100 규칙에 대한 설명이다. 스펙이 변경될 경우 요구분석 단계에서의 비용이 1이라는 가정하에 유지보수 단계로 넘어갈수록 200배에 가까운 비용이 낭비된다. 시간이 흐를수록 얼마나 큰 비용이 발생하는지 구성원 전부 명확히 인식할 필요가 있으며, 그렇기에 스펙이 정확히 작성되어야 하는 것이 얼마나 중요한지를 보여주는 사례이다.

가장 인상깊었던 파트는 6장(프로세스)과 9장(How) 파트이다. SRS를 작성하는 매우 구체적인 방안과 예시가 소개되고 있으며 코드 리뷰처럼 스펙을 리뷰하는 방법이나 협업의 방향을 다루고 있어 조직의 발전을 위한 방향을 엿볼 수 있다.

더불어 소스코드 및 유닛 테스트를 통한 스펙을 작성하는 실전법이나 인터페이스 개선 및 정의 부분은 수십년 간 경험을 축적한 저자의 내공을 느낄 수 있는 파트였다.

10장 도구 편에는 SRS를 작성하는데 도움이 되는 툴들이 소개되는데 미처 몰랐던 유용한 Tip들이 다양하게 소개되어 있어 실전에 유용하게 사용할 수 있다.

2부에서는 SRS 작성을 위한 구체적인 예시가 등장한다. 1부에서 익힌 감에 현 직장의 문화를 더해 실전처럼 적용해 볼 수 있는 구성이 마음에 들었다. 다만 한가지 아쉬운 점은 하나의 특정 개발 사례를 중심으로 일관성있게 소개되었다면 더욱 템플릿을 이해하기 쉽지 않았을까 싶다.

소프트웨어 공학에 대한 책 중 이론을 설명하거나 번역서는 그래도 자주 접할 수 있다. 하지만 국내 저자가 국내 정서를 반영하여 작성했다는 점, 지극히 실전적이고 구체적인 예시를 든다는 점, 수십년 간의 전문적인 커리어가 반영되었다는 점에서 이 책은 관련 서적 중 매우 귀중한 희소성을 띈다 할 수 있다.

PM, 아키텍트 이상의 관리자에게는 SRS 작성법은 물론 프로젝트의 성공과 올바른 기업 문화의 정착을 위해 필독서일 것이다.

그 외 구성원에게 있어서도 이론으로만 존재했던 소프트웨어 공학의 실체를 느끼고, 개발 및 조직 문화를 이해하며, 프로젝트의 일원으로서 커뮤니케이션 능력을 향상 시키는데 도움이 되므로 어느 정도의 경험이 쌓인 개발자라면 반드시 일독할 것을 권하고 싶다.

• 책소개 - 소프트웨어 스펙의 모든 것
•  

 대학원 시절 부터 글을 많이 적었었다. 제안서, 중간 보고서, 최종 보고서 등... IT 업계로 전직을 하고는 이상한 자료들을 만들었었던 기억이 있다. 그 당시에는 회사에서 시키기에 만들었지만, 지금 생각하니 SRS 등의 문서였던 것 같다. 어쨌든 그런 자료들을 만드는 게 너무 싫었다. 작성한 문서들은 작성한 이후 다시는 꺼내보지도 않았기에... 그냥 문서가 필요해서 만드는 문서, 그 이상도 이하도 아니었다. 그랬기에 반감이 더욱 컸던 것 같다. '문서 작성 = 시간을 축내는 일' 이었기 때문이다. 해당 도서에서는 스펙을 작성하는 이유는 개발 공수를 줄이기 위해 작성을 하는 것이라고 주장한다. 그럼 어떻게 해야 공수를 줄이는 글을 쓸 수 있을까? 여기서는 글을 쓰는 방법만이 아닌 기술을 공유하는 문화, 조직의 구성에 대해서도 상세히 기술하였다. 읽기 전에는 소프트웨어라는 단어 때문에 전문용어로 도배되어 있는 책일 것이라 생각이 되었지만, 개발을 잘 모르는 사람들도 읽을 수 있게 작성이 되었다. 물론, 이 책을 보는 것만으로는 좋은 글을 쓰기는 힘들다. 작은 프로젝트라도 직접 작성하는 버릇을 들여야 좋은 글을 쓸 수 있을것이라 생각한다.

보통 개발자라고 하면 코드를 개발하고 프로그램을 잘 짜는게 중요하다 생각하지만, 이에 못지 않게 중요한 부분이 문서화라고 생각을 한다. 아무리 개발을 잘하고 완성도 높은 프로그램을 만들어도 이 프로그램의 스펙이 어떻고, 어떤 구조를 이루고 있는지를 설명을 못한다면 결국 그 프로그램의 가치를 제대로 이끌어내지 못하기 때문이다. 학교 전공으로 종종 프로젝트나 공모전등을 나갈때에도 이런 스킬이 꽤나 중요하다는 게 많이 실감나는 순간이 많았다. 하지만 보통의 전공에서는 개발을 중점적으로 진행하지, 이런 스펙 작성법에는 자세히 얘기하는 것이 드물기에 이런 부분에 약하지 않을까 싶은 생각이 든다.

이번에 읽은 책은 이런 스펙 작성법을 잘 요약한 책이라고 생각한다. 이 책에서는 다양한 스펙문서 작성법중 SRS를 기반하여 작성을 하고 있다. SRS가 스펙 작성의 원리를 이해하기 쉬워서 도입했다고 하는데, 그래서 그런지 1부에는 스펙 작성의 원리를 2부에서는 이에 대한 실습으로 SRS작성법에 대해 소개하고 있었다.

​

초반부에서는 스펙 작성 현주소와 여러 사례를 통해 스펙작성의 필요성을 언급하였고, 중반부에는 스펙 작성이 그렇게 어렵지 않은 것을 얘기하면서 구체적으로 어떻게 적어야 하는지를 육하원칙에 근거하여 설명을 하고 있었다. 특히 육하원칙(5W1H)에 따라 소개하는 부분에서 소제목으로 단순명료한 문장으로 보여주고 있는게 직관적으로 이해하기 쉽게 설명해주고 있어 무척 마음에 들었다. 

2부인 SRS작성법은 하나의 템플릿을 보는듯 하였다. 1장에서 9장까지 소개된 내용은 어떠한 작성법이기 보단 이런 식의 내용이 들어간다고 소개를 하는데, 이런 소개내용이 일종의 완성된 보고서 양식같단 느낌이 들었다. 이 아홉장의 양식을 그대로 유지한채 자기가 개발한 프로젝트 내용만 여기에 맞춰 잘 정리하면 말 그대로 하나의 스펙이 완성되는 그런 잘 만들어진 모형틀이란 게 많이 느껴졌다.

사실 소프트웨어 스펙 작성법이라고 해서 엄청 난이도가 높거나 어려운 내용을 요구할줄 알았는데, 생각보다 크게 어려운 부분없이 요점만 딱 잘짚어서 설명한 책이란 생각이 든다. 물론 모든 부분을 다 이해한건 아니고, 약간의 기술적인 배경지식을 요하는 건 있지만, 그래도 이런 식의 보고서 스킬을 정리한 책도 적을 뿐더러 이 책에서 소개하는 정리방법론도 꽤나 잘 설명하고 있어 마음에 드는 부분이 무척 많았다. 보고서 작성, 스펙 작성에 대해 고민인 사람들에게는 한번쯤 고민하고 구매해 볼만한 책이란 생각이 든다.