소프트웨어를 만들 때 가장 힘든 부분은 수시로 바뀌는 고객의 요구사항이다. 갑과 을이 명확한 우리나라에서는 '일단 만들어 와 봐'가 기본적으로 깔고 들어간다. 같은 국내 고객이지만 외국계 기업에게는 다른 스텐스를 취한다. 그네들은 그런 요구를 들어주지 않기 때문이다. 일대일의 종속 관계인 우리나라에서 개선이 시급한 부분이기도 하다.
꼭 고객의 탓이 아니라도 마케팅과 고객의 관계에서 발생하는 모호함이 있다. B2C와 같이 일반인을 대상으로 하는 게임과 같은 S/W의 경우에는 기획단계에서 철저하게 스펙을 만들어가면 되지만 B2B의 입장에서는 갑의 의견을 결정하는 것이 중요하다. 하지만 고객의 입장에서는 스펙을 결정하는 것은 추후 문제의 소지가 있을 때 불리하다는 생각이 있는지 우선 모호하게 얘기한다. 물론 을의 입장에서도 모호하게 얘기해서 고객이 인지 못하는 부분을 최대한 하지 않으려고 한다. 동상이몽을 꾸는 것이다.
이런 상황에서 개발자는 애매모호한 스펙 때문에 힘겨움을 겪는다. 기술에 대해 잘 알지 못하는 부서와 고객은 일을 굉장히 쉽게 생각한다. 표면상으로 별거 아닌 변화가 엄청난 수정이 필요하기 때문이다.
여러 이유가 있지만 그럼에도 소프트웨어의 스펙을 작성하는 것은 중요하다. 업무를 명확하게 할 수 있기 때문이다. 명확한 스펙은 효율적인 설계를 가능하게 하고 쓸데없는 업무를 줄여 준다. 개발자가 노파심에 추가로 개발하는 일도 없고 여러 기능을 중복적으로 개발하는 일도 줄게 한다. 더불어 명확하게 기록된 스펙은 고객을 설득하기에도 조금 더 수월할 수 있다. 그럼에도 쉬운 일이 아님은 확실하다.
책은 SRS의 필요성과 업무 진행에서 오는 어려움을 얘기하고 있다. 소프트웨어라는 것은 그 덩치가 점점 커질수록 명확한 명세서가 필요하다. 작은 프로젝트는 경험 있는 여러 개발자들이 통밥(?)으로 진행할 수 있지만 덩치가 커질수록 외주화가 많아질수록 심지어 외국 엔지니어를 고용할수록 명세가 필요하다.
바뀌지 않는 명세는 없지만 꾸준히 관리해야 하고 필요할 만큼 담백하게 작성해야 한다. 내부적으로 진행할 프로젝트인지 외주화 할 것인지에 따라서도 명세의 수준이 달라질 수 있다. 이런 여러 상황을 고려한 내용을 저자들은 설명하고 있다. 어떻게 보면 SRS에 필요성과 우리나라 IT업계의 부조리함을 얘기하는 데 더 많은 페이지를 할애하는 것 같았다. 기술적인 측면보다는 공감과 이해를 위한 책이랄까.
절반 이상이 이런 사회적 현상에 대한 설명이다. 물론 다 읽고 나면 SRS의 필요성에 대해 다시 한번 생각해 보게 된다. 그리고 필요해서 이런 책을 사서 읽은 것도 맞다. 앞으로 어떤 고난이 닥쳐올지 예상할 수 있게 되었다는 게 가장 큰 수확이라고 할 수 있다.
2부에서는 SRS에 대해 설명하는데 이 부분은 IEEE SRS 문서를 요약한 느낌이 있다. 한글로 된 예시 문장 몇 개를 제외하면 IEEE 문서를 읽는 편이 더 나을 것 같았다. 사실 샘플을 두고 실습하는 것을 기대한 것도 사실이기 때문이다.
즐겁게 읽었지만 아쉽지 않았다면 거짓말일 것 같다. SRS를 처음 해보려는 사람에 대한 배려가 조금 부족하지 않았나 싶었다. '입문서'를 따로 찾아봐야 할까 싶다.
'독서 (서평+독후감) > IT | 기술 | 공학' 카테고리의 다른 글
(서평) Release의 모든 것 (마이클 나이가드) - 한빛미디어 (1) | 2023.12.27 |
---|---|
UML 실전에서는 이것만 쓴다 (로버트 C. 마틴) - 인사이트 (1) | 2023.12.18 |
이것이 취업을 위한 코딩 테스트다 with 파이썬(나동빈) - 한빛미디어 (0) | 2023.11.29 |
파이썬을 활용한 나만의 RPA 만들기 (안정국) - 삼일인포마인 (1) | 2023.11.29 |
(서평) 플레이어를 생각하는 게임 UI 디자인 노하우 (오타가키 사야코) - 한빛미디어 (1) | 2023.11.21 |