All of Software: SRS에 대한 인식의 변화

2009년 11월 13일 금요일

SRS에 대한 인식의 변화

그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다.

지금까지는 SRS라는 용어조차 한번도 들어본 적이 없는 소프트웨어 개발자나 관련자들이 많았었습니다. 하지만 이제는 조금씩 SRS라는 용어에 대해서 알기 시작하는 것 같습니다. 또 소프트웨어 개발에서 있어서 요구분석이 왜 중요한지에 대해서 조금씩 인식해가는 것 같습니다.

그 예로 최근에는 정부에서도 소프트웨어 기업들의 경쟁력 강화, 특히 해외 시장 진출 시 경쟁력 확보를 위해서SRS 작성을 중요한 요소로 보고 정부 지원 과제에 포함을 하고 있습니다.

이러한 과제에 평가위원으로 참석을 해보니 아직은 많은 소프트웨어 회사들이 분석능력을 제대로 갖추고 있고, SRS를 잘 쓸 수 있는 역량을 갖췄다고 보기는 어렵습니다. 하지만 제대로 된 소프트웨어를 짧은 시간에 개발하기 위해서는 분석을 제대로 하여 SRS를 작성하고 SDP를 만들어야 한다는 것을 인지한 것만으로도 큰 변화라고 볼 수 있습니다. 필요성을 인식하는 것이야 말로 변화가 가능하게 하는 원동력입니다.

다만, 문제는 분석을 잘해야 한다는 것, 즉 SRS를 잘 써야 한다는 것을 인식하고도 SRS를 잘 적는 방법을 배울 곳이 없다는 것입니다. Software 선진국에서는 수십년 간 개발자들이 SRS를 써 왔기 때문에 서로 Template는 조금씩 달라도 개발자로서 일을 하는 동안에 계속 접해 왔고, 써왔기 때문에 따로 배우고 말 것도 없이 SRS를 쓸 줄 알게 되었습니다. 물론 모든 개발자가 SRS를 다 제대로 쓸 줄 아는 것도 아니고 그럴 필요도 없지만, 소프트웨어 프로젝트를 시작할 때 누군가가 SRS를 작성하고 관련자들과 리뷰를 하는데 전혀 문제가 없습니다.

하지만 이제 시작인 우리나라는 배울 곳도 없고, 스스로 연구하고 공부해서 작성하기에는 요구분석이라는 분야 자체가 너무 어렵습니다. 그 동안 여러 회사에서 스스로 작성했다고 하는 SRS를 분석해보면 합격점을 줄 수 있는 것은 거의 전무했다고 해도 과언이 아닙니다. 그렇다고 미국 회사에 가서 몇 년 배우고 오기도 어려운 실정입니다. 또, 국내에서는 학교나 학원에서 배울 수 있는 환경도 되지 않습니다. 그렇게 배운다고 해도 몇몇 기법만 배우고 핵심은 파악하지도 못하게 됩니다. 그 이유가 대부분의 교수나 강사가 소프트웨어 프로젝트에서 실제로 SRS를 써본적이 거의 없이 이론적으로 배운 정도이기 때문입니다. 실제 프로젝트에서 SRS를 제대로 써본 경험을 많이 가지고 있는 경험자와 같이 SRS를 써보면서 꾸준히 배워 나가는 것이 가장 적절한 방법입니다.

물론 몇몇 개발 방법론에서는 SRS를 작성하지 않습니다. 하지만 이러한 방법론에서도 스펙이 필요 없다고 하는 것은 아닙니다. 다만 스펙을 바라보는 관점과 적는 방법이 다를 뿐입니다. 따라서 스펙의 개념을 정확하게 알고 SRS를 잘 작성할 줄 아는 개발자들이라면 스펙의 형태가 테스트케이스가 되든 어떤 다른 형태가 되든 문제는 없습니다. 즉, 소프트웨어 분석역량이 문제입니다.

분석역량의 부족은 부실한 스펙문서를 만들게 되고 이는 설계, 구현 기간에 많은 혼란과 재작업을 초래하고 출시 후에도 유지보수 비용을 크게 증가시킵니다. 그 동안 우물 안 개구리처럼 내수시장에서 소수의 개발자를 데리고 고객이 원하는 대로 뚝딱 만들어서 장사를 했는데, 소프트웨어 볼륨이 커지고 해외 시장에 진출을 하려니까 딱 벽에 부딪히는 겁니다. 이 과정에서 무리하게 해외 진출을 추진하다가 유명을 달리한 회사들이 상당히 많습니다. 그렇다고 세계 시장의 1%밖에 안되는 국내 SW시장에서만 놀기에는 국내 시장은 너무나 작습니다. 왠만큼 성장한 회사라면 해외 시장 진출의 유혹을 떨처버리기 어렵습니다.

물론 SRS, 스펙, 분석능력이 이 모든 것을 해결해주지는 않습니다. 하지만, 가장 중요하고 핵심적인 요소라 확신합니다. 이는 저만의 주장이 아니고 제가 존경하는 수많은 실전 소프트웨어 전문가들의 주장이기도 합니다. 그러한 맥락으로 앞으로 SRS, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

이와 관련된 궁금증, 의견, 경험, 고민거리, 정보, 아이디어 등 어떤 것이라도 같이 교환하고 싶습니다. 댓글이나 방명록, 메일로 얼마든지 보내주세요. 제가 해결해드릴 수 있는 것은 해결해드리죠.

그리고 교육을 받고 싶으신 개발자나 회사라면 연락 주시기 바랍니다. 제가 여건이 되는 한도내에서는 많은 소프트웨어 개발자들에게 전달하고 싶습니다.

댓글 12개:

Peter2009년 11월 14일 오전 6:59
최근 프로젝트 진행하면서, 요건정의서 / 주요화면 정의서만 가지고 프로젝트를 수행했었습니다. 유사 경험이 있으니 잘 되겠지라구 약간은 자만하면서요..

하지만 관련 분야 업무를 처음 해보는 사람들과의 협업/구현하면서 문제가 하나둘씩 생겨나기 시작하고, 주기능 보다는 당연히 될거라고 생각했던 부기능에서의 생각의 차가 너무 컸고, 결국 Rework을 하게 되더군요.
확실히 일은 정석대로 해야한다고 SRS 로 시작했으면 좋았겠다는 후회가 나중에 들더라구요...

좀 부끄러운 경험담이지만.. SRS 중요성/초기 설계의 중요성을 깨닿게 했던 중요한 교훈이었던 것 같습니다.
전규현 수석님.. 블로그글 잘 공감하고 있습니다. 감사합니다.
답글삭제
답글
구차니2009년 11월 14일 오후 1:26
개발자들도 이러한 개발의 효율을 위한 절차를 받아 들여야 하지만
그에 못지 않게 개발을 위탁하는 사람도 개발에 대한 이해가 널리 퍼졌으면 좋겠다는 생각이 듭니다.

이러한 프로세스 없이, 중간에 계속 수정을 요구하고 이에 따른 추가기간을 정산하지 않으면
개발자 역시 무상으로 계속 지치게 되니 말이죠. 물론 인간이라 처음부터 완벽하게 SRS를 만들어내서
한번에 만들수는 없기에 어느정도 변경사항이 생기겠지만, 디자인이 마음에 안들어요 이렇게 바꾸어 주세요
라고 하는건 개발 위탁하는 사람역시 이러한 개발의 과정중 하나로 넣어 교육을 시켜야 하지 않을까?
라는 생각마저 들게 합니다.
답글삭제
답글
Ray.전규현2009년 11월 15일 오전 1:06
구차니님 안녕하세요.
말씀 하신 것처럼 처음부터 스펙을 완벽하게 다 정하고 프로젝트 끝날 때 까지 절대 바꾸지 않을 수는 없습니다. 그래서 어차피 바뀌니 대충 시작하는 것은 더 문제가 크죠.
개발자나 고객이나 모두 스펙에 대한 이식의 변화가 필요하겠죠. 또한 교육, 훈련과 경험 모두가 필요하고 1,2년에 해결될 문제는 아니라고 봅니다.
답글삭제
답글
Ray.전규현2009년 11월 15일 오전 1:09
Peter님 안녕하세요.
실제로 제가 다른 개발자들이 작성한 여러 SRS를 검토해보면 비기능요구사항이 주로 부실하게 작성되어 있더군요. 하지만 비기능요구사항이 SRS에서 더 중요하다는 것을 잘 인식하지 못합니다. 기능이 하나 잘못적힌 것은 일반적으로 해당 모듈만 수정하면 되지만, 비기능요구사항 하나 누락되거나 잘못 적힌 것은 시스템 전체를 다 뜯어 고쳐야할 정도로 큰 사건일 수 있습니다. 앞으로 블로그에서 이와 관련된 다양한 내용들을 다룰 계획입니다.
답글삭제
답글
김경록2009년 11월 17일 오전 11:00
좋은 글 잘 읽고 갑니다.
^^
답글삭제
답글
Ray.전규현2009년 11월 17일 오전 11:56
김경록님 오랫만입니다.
댓글 남겨주셔서 감사합니다. 항상 건강하세요.
답글삭제
답글
yong_ho2010년 4월 20일 오후 6:40
IT 관련 무엇인가를 찾다보면 이 블로그로 들어오게 되는 듯 합니다. ^^; 새로운 프로젝트를 하는데 아무래도 불가능에 도전해보아야 할 것 같습니다. 갈수록 괜찮은 SRS가 나오겠지요. 혹시 괜찮은 Template 있으시면 하나 던져주시면 고이 잘 받아먹겠습니다. 굽신굽신~
답글삭제
답글
Ray.전규현2010년 4월 21일 오후 5:09
Google에서 Software Requirements Specification으로 검색을 하면 여러 Template를 찾을 수 있을 겁니다. 하지민 Template 만 보고 제대로 적는 다는 것은 불가능합니다. 타이거우즈 골프채만 보고 타이거우즈처럼 골프치는 것을 흉내내려는 것과 같습니다.
소프트웨어에서 가장 어렵고도 중요한 것이 바로 무엇을 개발할지(스펙)을 적는 것이지요.
답글삭제
답글
임수빈2010년 12월 9일 오후 2:10
좋은 글 잘 읽고 갑니다 ^^ 현재 컴퓨터공학 전공하는 3학년 학생입니다~
소트프웨어 공학 과목을 공부하면서 요구사항 분석 부분에 어려움이 있어
관련 자료를 찾다가 방문하게 되었네요!
종종 들러서 좋은 글 자주 읽도록 노력하겠습니다.
답글삭제
답글
Ray.전규현2010년 12월 10일 오후 8:10
안녕하세요. 임수빈님
소프트웨어 공학은 배울수 없다고들 합니다. 즉 경험을 통해서 익힐 수 밖에 없다는 뜻. 하지만 배우는 것은 나중에 경험을 할 때 큰 도움이 됩니다.
그중에서도 가장 어려운 분야가 요구사항 분석입니다.
이론적인 것 만 가지고 실제 프로젝트에서 제대로 적기는 정말 어렵습니다.
열심히 배우시고 실전에 적용하시기 바랍니다.
답글삭제
답글
이해승2012년 5월 22일 오후 5:23
안녕하세요. SI 분야에서 일한지 15년이 넘어가면서 제대로 된 SRS 작성해 본 기억이 별로 없습니다.
어디서 배워야 할지도 모르겠구요...소프트웨어 공학, 다양한 프로젝트 관리 기법 등등 안해 본 경험이
별로 없음에도 불구하고 여전히 제대로 된 SRS 작성하는 것에 목 말라 하고 있습니다.
어떻게 시작해야 좋을까요?
답글삭제
답글
전규현2012년 5월 24일 오후 1:37
이해승님 안녕하세요.

가장 어려운 질문 중 하나입니다. "어떻게하면 SRS를 잘 쓰는 법을 배울 수 있을까?" 어떻게 하면 SW를 잘 개발할 수 있을까와 거의 동격의 질문이기도 합니다.
또는 어떻게 피아노를 배울 수 있을까?와 비견되기도 합니다.
오랫동안 SW를 개발해왔던 개발자라고 하더라도 SRS를 작성하는 것, 즉 스펙을 작성하는 것은 여전히 어려운 과제입니다.

제일 좋은 것은 스펙을 잘 작성하고 있는 회사에 가서 일하면서 자연스럽게 배우는 것입니다. 우리나라에는 그런 회사가 별로 없으니 실리콘밸리로 가야합니다. 현실성은 없죠.

다른 방법으로는 전문가나 경험자에게 배우고 직접 작성을 해보고 리뷰받고 이런 과정을 반복하면서 배우는 방법입니다.

그렇지 않고 책을 보고 스스로 해보는 방법은 시행착오를 많이 겪어야 하고 영원히 제대로 작성하믄 방법은 못배울 가능성이 거의 100%입니다.

가장 좋은 방법은 회사에서 전문가를 데려와 주는 것이겠죠.

우선은 제가 쓴 "소프트웨어 개발의 모든 것"이라는 책을 먼저 보세요. 이해를 돕기 위한 설명이 좀 되어 있습니다.
답글삭제
답글

댓글 추가

suvery button

2009년 11월 13일 금요일

SRS에 대한 인식의 변화

댓글 12개: