산출물 표준 양식이란 것은 없다
글쓴이 : 민상윤
이글은 필자가 여기저기 강단에 설때마다 자주 언급했던 내용입니다…혹시 필자의 강의를 들은분들은 복습하는 개념에서 읽어 주기를 바랍니다.
일반인들에게 소프트웨어 공학을 이야기하면 대뜸 나오는 반응이 산출물 문서화에 대한 오버헤드이다. 소프트웨어 공학하면 국내 대부분 개발자들은 문서화에 대한 불평부터 토를 달기 시작한다. 도데체 우리나라 왜 이런 것일까? 전세계적인 다양한 통계를 보더라도 국내 소프트웨어 공학 및 소프트웨어 개발 수준은 선진국에 비하여 짧게는 10년에서 길게는 20년까지 뒷쳐저 있다는 것이 일반적인 의견이다.
그중에서 가장 잘 안되는 것이 산출물에 대한 문서화이다. 필자는 지난 10여년간의 컨설팅을 하면서 문서화에 대한 많은 문제점들을 보아왔다. 국내 어떤 조직치고 소프트웨어 요구사항 명세서(흔희 이야기하는 SRS)나 소프트웨어 설계서(SDD)가 실제적으로 도움이되게 작성되고 활용되는 경우를 찾기란 매우 힘들다. 물론 간헐적으로 잘되는 조직을 보기도 하지만…
도대체 왜 안되는 것일까? 오늘은 이문제의 한가지 주요 원인에 대하여 논하여 보기로 한다.
그동안의 많은 케이스를 보면서, 문서화가 잘 안되거나 형식으로 오버헤드로서 작용하는 조직들에서의 그 원인에 대하여 살펴본 결과 다양한 원인들이 존재하고 있었다. 그 중 가징 치명적인 원인이 바로 “표준양식” 이라는 것이다.
문서화가 안되는 거의 대부분의 조직들은 컨설팅을 받았건, 자체적으로 정립했건간에 표준화된 개발 프로세스와 표준 산출물 양식을 가지고 있으며, 그러한 산출물 양식에 대하여 개발자들에게 작성을 하도록 유도 혹은 강요하고 있었다. 가장 대표적인 양식이 바로 소프트웨어 요구사항 명세서(Software Requirements Specification)와 소프트웨어 설계서(Software Design Document)이다. 이러한 조직이 가지고 있는 양식의 특성을 보면 다음과 같다.
1. 양식의 포맷은 Word나 아래한글이다.
2. 내용 구성이 거의 쌍둥이 같이 유사하다. 예를 들면 소프트웨어 요구사항 명세서의 경우,
________________________________________
SRS
1장 범위
2장 참고문헌
3장 요구사항
3.1 상태와 모드
3.2 소프트웨어 요구사항
3.3 인터페이스 요구사항
….
3.7 안정요구사항
….
4. 품질 시험 방법
5. 요구사항 추적성
….
___________________________________________
그러면 도데체 이러한 포맷과 양식구성은 어디서 부터 누가 만든 것일까?
대부분 그러한 조직의 프로세스 엔지니어나 품질 보증 담당자들을 만나서 이야기하여 보면 자기들의 표준 양식은 국제 표준 양식에 기반한 것이라는 변명과 같은 자랑을 늘어 놓는다.
SRS의 국제 표준양식이라는 것은 없다. SDD도 마찮가지이며 기타 모든 소프트웨어 개발 산출물 양식들도 그러하다. 이부분이 국내에 잘못 전달되어 온 큰 오류중의 하나이다.
그럼 도데체 무슨 상황인가?
국내에서, 감리나 컨설팅 업체에 소프트웨어 표준 프로세스 구축시 가장 많이 사용하는 참조 모델은 CMMI와 ISO/IEC 12207이다. CMMI는 성숙도 모델이므로 올바른 소프트웨어 개발 활동들에 대한 요건 기술서이므로 표준화 양식같은 것은 제공하고 있지 않다. 그럼 ISO/IEC 12207 은 (참고로 IEEE 12207과 동일한 표준안이며 IEEE에서 채택한 것이다) 소프트웨어 개발 라이프사이클 표준안 인데 다양한 프로세스(프로젝트 관리, 요구사항 분석 등)군을 표준적으로 제시하고 있다.
그럼 ISO/IEC 12207에 표준 양식이 있는가 ? 아니, 없다. 그럼 도데체 어디서…..
ISO/IEC 12207 국제 표준의 전신 모델이 바로 MIL-STD-498이란 미국방부 표준 모델이었고, 그 전신이 DOD-2167A라는 표준안 이었는데 둘다다 국방/방산 분야 소프트웨어 프로세스 표준안이었으므로 민간 분야보다는 형식주의가 강한 모델이다. 그럼 MIL-STD-498이나 DOD-2167A 에 표준 양식이 있었는가?
답은 아니오이다.
그럼 도데체 어디어 온 것인가? 우리가 사용하는 표준 양식들은…
그것들의 기원은 바로 MIL-STD-498이나 DOD-2167A에서 제공하고 있는 DID(Data Item Description)이란 산출물 구성 항목집이다. MIL-STD-498이나 DOD-2167A 에서는 별도의 부록으로 백페이지 넘는 DID(Data Item Description)란 부록을 제시하고 있는데 그안을 열어 보면 우리가 흔히 잘못 일컫는 SRS, SDD, OCD, 등의 양식들이 알파멧 순으로 철되어있다. 각 내용은 보면 우리가 가지고 있는 요구사항 명세서, 설계서 양식과 동일하다.
국내에 SRS나 SDD등을 도입하여 들어온 분들이 DID(Data Item Description)를 국제 표준 양식으로 잘못 이해와 해석을 한 것이다. ISO/IEC 12207의 전신 모델에서의 DID이니 12207에서도 그대로 쓴것이다. 표준 양식으로서.
DID(Data Item Description)는 표준 양식이 아니라 각 산출물(여기서 쓰는 단어로는 Data가 산출물로 해석하면 된다. 프로세스 분야에서 자주 configuration item을 data item으로 혼용하여 쓰기도 한다)의 내용 구성에 대한 권고안 같은 것이다 - DID(Data Item Description)내의 SRS라는 것은, 소프트웨어 개발 과정 중 요구사항 분석이 완료되고 난 후 정리되는 산출물의 문서군(set)인 SRS(소프트웨어 요구사항 명세, 사실이 ‘명세’가 맞다 ‘명세서’가 아니라)는 이러이러한 세부 구성 내용들(범위, 참고문헌, 상태와 모드, 인터페이스 요구사항 등)을 포함하고 있어야 한다는 것이다.
그 각각이 다른 문서와 각각 다른 포맷이건 DID에서는 상관하지 않는다. 다시 말해 SRS의 Recipe 인 것이다. 그러나 보니 DID문서 자체가 Word같은 포멧으로 기술되어있다.
SRS내의 각 구성 항목을 기술하는 방식은 회사마다 프로젝트마다 그 효과적인 방법이 다를 것이다. 어떤 것은 엑셀로, 어떤 것은 파워포인트나 비지오로, 어떤 항목은 CASE tool로, 어떤 것은 종이와 메모로 기술하는 것이 합당할 것이다. 또한 특정 항목의 추가 혹은 삭제도 그 효용성 측면에서 필요하다.
물론 제출용 버젼으로 정리하기 위하여 워드 포멧으로 각 세부 항목을 임베드시키는 것은 가능하다.
미국 사람들도 SRS DID를 ‘SRS template’이라고 약간 잘못 지칭을 하기도 하지만, 이것을 SRS 구성항목의 템플릿이라고 생각한다면 그리 잘못된 것은 아니다.
그런데 우리나라에서는 DID를 ‘양식’ 으로, template을 ‘양식’ 으로 획일적으로 번역하여 쓴다는 것이 문제이다. DID는 그 영어 어디를 보아도 ‘양식’ 이란 내용은 없으며, template 도 ‘양식’ 이 아니다. 우리가 이야기하는 양식은 영어로 ‘form’ 이다. template의 의미는 양식이 아니라 다양한 피생 인스턴스를 만들 수 있는 모체라는 의미이다. 괜히 조그만 번역실수를 트집 잡는 것이라 들릴수 있지만 이건 조금만 실수가 아니라 국내 소프트웨어 공학분야의 너무나 큰 사고였다.
획일화된, 사용하기 매우 불편한(워드 포멧의 SRS에 요구사항을 기술하여 본적이 있는가? 얼마나 원시적이고 비효율적인지…) 양식과 포맷의 산출물 작성 지침은 개발자들을 지치게하고 조직을 힘들게하며 소프트웨어 공학을 멍들게하는 것이다.
잘못된 감리나 컨설팅 업체, 프로세스 전문가 이외에 더 심각한 것은 국내외 방법론(예. 객체 지향, 컴포넌트 기반 등) 전문가들이 책을 쓸데 부족한 프로세스 지식을 가지고 쓰다보니 함부로 요구사항 명세서나 설계서에 대한 표준양식들을 책의 부록등에서 너무나 쉽게 제시하고 오류를 범하고 있다는 것이다.
다시한번 언급해도 부족하지만 선진국의 기술과 지식을 도입하여 올 때는 원래 국가의 언어와 지식으로서 먼저 정확한 해석과 이해가 선행되어야 한다. 또한 그를 위한 전문적인 기반지식을 가지고 있어야 한다. 무분별한 번역과 피상적 추측과 이해는 선진기술의 도입이 오히려 큰 해를 입힐 수 있다는 것을 명심하여야 할 것이다.
