SWEBOK - 소프트웨어 요구사항 #9 (최종)

SWEBOK 해설 Software Requirements #9 (최종)

(***필자주석) 이번 포스트가 Software Requirements의 마지막 포스트인 도구에 관한 꼭지이다. 이제 Requirements를 끝내고 다음은 설계(Software Design)에 대한 포스트를 시작될 것이다. 이 꼭지는 양이 많지 않으니 먼저 번역을 하고 주석을 달도록 하겠다.

1장 Software Requirements (소프트웨어 요구사항)
1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
2. Requirement Process (요구사항 프로세스)
3. Requirement Elicitation (요구사항 도출)
4. Requirements Analysis (분석)
5. Requirements Specification (명시)
6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)

Software Requirements와 관련된 도구는 크게 두 가지로 나누어 진다. "모델링 도구"와 "요구사항 관리도구" 이다.

요구사항 관리도구는 문서화(Documentation), 추적(Tracing), 변경관리(Change Management) 등이 있는데 실제 개발에 큰 영향을 미친다. 사실 요구사항 추적이나 변경관리는 도구가 없이 수행하기는 비현실적이다. 요구사항 관리도구는 요구사항 관련 업무에 핵심적이기 때문에 많은 회사들이 요구사항 관리도구에 투자를 했다. 반면에 훨씬 더 많은 회사들은 만족스럽지는 않지만 스프레드시트와 같은 임시변통(Ad hoc)의 방법으로 관리한다.

(***필자주석) 국내에는 도구에 대한 맹신이 있다. 사실 SWEBOK에서도 도구에 대해서 마지막에 몇 줄로 간단히 언급했듯이 그렇게 많은 비중을 들이지 않았다. 필자는 국내 회사들이 필요 없는 도구에 대한 광적인 집착을 보이는 경우를 많이 보아왔기 때문에 주의를 주고 싶다. 괜히 필요 없는 건강식품을 믿고 먹다가 돈과 건강을 잃는 피해를 입지 않기 바란다. 거의 대부분의 국내 회사는 도구에 신경쓰기에 앞서서 도구를 이용할 내용을 잘 적는 것에 먼저 모든 노력을 하기 바란다. 지금까지 SWEBOK에서 얘기한 것이 바로 내용을 잘 적기 위한 원리를 설명한 것이다. 도구는 내용이 있을 때 마지막으로 걱정할 문제이고 또 그래야지만 자신에게 맞는 적절한 도구를 분별하고 현명하게 구입할 수 있는 능력이 생긴다.

SWEBOK에서 언급한 2가지 도구 중 모델링 도구에 관해서 많이 언급하지 않았지만 예를 들면 UML의 유스케이스 다이어그램을 만들어 주는 도구가 그 중의 하나이다. UML의 많은 다이어그램 중에 유스케이스 다이어그램은 Requirements를 명시하는 방법 중의 하나이다. 모든 프로젝트의 경우에 이용할 수 있는 방식은 아니지만 많은 경우에 사용되기는 한다.

요구사항 관리도구는 양날의 칼이다. 마치 타이거 우즈의 골프채 같은 것이다. 일반 아마추어 골퍼들이 타이거 우즈의 골프채가 좋다고 똑같은 골프채를 사서 친다면 재앙일 것이다. 비싸기만 하고 손해 본다. 그러지 않아도 요새 골프존마켓의 광고에서 고객과 골프상점 점원이 골프채를 서로 잡고 고객은 가져가려고 하고 점원은 안 뺏기려고 티격태격 한다. 고객 말은 "유소연이 이거 들고 일등 했거든요" 점원 말은 "당신은 유소연이 아니거든요. 손님한테 맞는 채를 사셔야 하거든요". 이 광고의 교훈은 비싼 도구와 나에게 맞는 좋은 도구는 다르다 이다. 물론 골프채의 경우는 비싼 채를 들고 다녀야 남들한테 졸부의 과시도 되고 하니까 전혀 가치가 없는 것은 아니다. 마찬가지로 회사의 경우에도 잘 알지는 못하니까 비싼 도구라도 사서 혹시라도 실패 시에 책임도 면하고 자기 과시도 하는 대기업 경영진들도 있다. 왜 비싸고 좋다는 도구를 샀는데 개발이 잘 안될까 하는 것을 필립 그린스펀은 유치원생이 비행기에 올라타서 이 버튼 저 버튼 눌러보면서 왜 비행기가 안 뜨지 하는 것과 같다고 말했다.

추적 관리도구 같은 경우가 어설프게 사용했다가 큰 피해를 입는 경우이다. 요구사항 내용을 적는 능력이 충분히 있고 그런 상태에서 요구 사항을 추적을 하겠다면 필수적인 도구이다. 스프레드시트를 사용하겠다는 경우는 매우 간단한 경우에 해당한다. 수십 명이 개발하는 규모 정도의 프로젝트만 해도 요구사항을 스프레드시트로 관리하기에는 어려울 수 있다. 특히 변경이 자주 일어난다면 변경관리는 거의 불가능하다. 하지만 아무리 도구가 좋다고 한들 내용이 제대로 적혀 있지 않으면 관리하는데 쓸데 없는 비용만 든다. 차라리 추적이나 변경 관리를 하지 않는 것이 좋을 수도 있다.

그럼 언제 도구가 효용성을 발휘할까? 이 답은 글을 쓰는 것과 비교해서 얘기할 수 있다. 내가 글을 쓰려고 하는 데 원고지에다 연필로 쓸까? 간단한 노트패드로 쓸까? 비싼 MS 워드로 쓸까? 하는 질문과 같다. 어떤 도구를 사용하든 먼저 글을 쓸 내용이 준비 되어 있어야 한다. 즉 생각하는 역량이 있은 다음에야 도구가 도와주는 것이다. 도구는 지원하는 도구일 뿐이지 글을 적는 데 핵심은 아니다. 뭘 적을 지도 모르는데 워드 띄워 놓고 쓰레기나 타이핑한다고 글은 나오지 않는다. 요구사항의 내용을 잘 적을 수 있을 때 편리성을 도와 주는 것이 도구인 것이다. 도구가 내용을 도출하는데는 도움이 되지 않는다. 내용을 도출하는 것은 전적으로 두뇌가 하는 행위이기 때문이다. 도구는 마지막에 기록하는데 도움이 되는 것이다.

결론을 말하자면 요구사항관리도구를 사용해서 혜택을 받을 수 있기 위해서는 어느 정도 수준에 올라야만 한다. 아직 국내의 SI 프로젝트나 회사내부 프로젝트의 경우나 다 SRS를 제대로 작성하고 개발하는 경우가 거의 없다. 앞 장에서 말한 대로 인수테스트를 적을 수 있는가 없는가 로도 그 판단을 할 수 있다. 그런 상태에서는 도구를 사용하는 것이 거추장스러운 존재가 될 가능성이 크다. 반대로 SRS를 잘 적을 수 있는 데 도구가 없다면 문제가 될까? 아마 약간의 효율성 저하가 있을 수는 있겠지만 실리콘밸리의 대부분의 벤처기업이나 중소기업들은 요구사항 관련 도구가 없이도 웬만한 규모의 프로젝트는 잘 수행하고 있다. 도구에 관한 문제는 미리 걱정할 필요도 없고 스스로 SRS 작성 역량이 늘어가면 필요한 도구를 선택할 수 있는 역량이 생긴다. 그 때까지는 도구 영업사원들의 과대광고에 현혹되어 피해를 입지 않기 바란다.

SRS를 잘 적는데 실패하는 프로젝트는 보기 어렵다. 반대로 SRS를 잘 적지 않고 성공하는 프로젝트도 보기 어렵다. 그래서 SW 프로젝트는 처음부터 이미 성공할지 실패할 지를 알 수 있다. 이렇게 SW 산업의 성공 조건은 간단하다. 하지만 "간단한 것이 더 어렵다"는 격언처럼 SW 전 생명주기에서 가장 중요하고 어려운 것이 바로 SRS이라고 SW 공학에서 강조한다.

그리고 다음부터 포스트할 설계에 관한 내용도 SRS를 잘 알고 있어야 이해가 쉽다. 필자도 읽고 이해하는 수준이 아니라 머리 속에서 이 원리를 습관적으로 이용하기 위해서 수 없이 반복해서 읽곤 한다. SWEBOK도 여러 번 숙지하면서 읽었어도 항상 새롭게 깨닫는 내용들이 있다. 독자들도 가능하다면 처음부터 다시 한 번 읽어보기를 권장한다.