필자가
미국에 처음 갔을 때 한국교포 2세와 얘기를 하다가 "잘못보았다" 란 말을 영어로 해야 하는데 도저히 생각이 나지 않아서 영어로 뭐라고
하느냐고 물어보니까 그 교포도 고개를 갸우뚱하더니 똑같은 말이 없다고 한다. 즉 "자동차로 잘못 보았다" 는 말은 "I
thought it was a car" 라고
하는 표현으로 대체 된다. 즉 한 언어에서 다른 언어로 직역할 수 없는 것들이 많다. 그래서 외국어를 배울 때 분석하지 말고 그냥 외우는게 가장 빨리 배운다는 격언이 있다.
인간이
어떤 행위를 하면 결과물이 나온다. "분석" 이라는 행위를 하면 "SRS"라는 산출물이 나온다. 행위를 했는데 산출물이 나오지 않으면 다른 사람에게는 행위를 하지 않은 것으로 간주된다. 미국의 소프트웨어 회사에서 통상적으로 SRS 라고 하는 것이 "Software Requirements
Specification" 의 줄인 말이다. 한국에서는 당연히 한글로 번역을 한다. 그런데 이 잘못된 번역 때문에 한국 소프트웨어 업계가 시작부터 잘못된 원인이 되었다. 직역할 수 없는 단어 하나 때문에 소프트웨어 개발에 대한 문화가 갈라파고스 섬으로 가버렸다. 일단 문자를 풀어서 해석하자면 "Software의 Requirements"를
"Specify" 한 것이라고 할 수 있다. 당연히
"Requirements" 와 "Specification"이 다르다는 것을 의미한다. 여기서 언어가 문제가 된다. Requirement와 Specification을 둘
다 "사양" 이라고 번역한다. 완전히 다른 것을 이름을 같이 붙여 놓으니 문제가 없을 수가 없다.
이런 번역의
오류가 생기는 예로 특허 문서에 사용하는 용어 중에 영어로는 Compise와 Consist가 있는데 완전히 다른 의미로 사용된다. 그런데 한글로 번역을 하면 둘 다 "구성하다"라는 똑같은 용어로 해석된다. 그래서 한국에서 특허를 내고 나중에 외국에서 특허를 내려고 할 때 문제가 된다. 중국어도 한글로 번역되지 않는 경우가 많이 있다. "해도 된다" 혹은 "할 수 있다"는 조동사가 "neng", "hui",
"yinggai", "dei" 등과 같이 한글로는 다 똑같이 번역되지만 중국어에서는 다르게 사용되는 단어들이 있다.
한국에서는 SRS를 나름대로 추측해서 어떻게 부르는지 몇 개만 나열해 보자. "요구사항", "요구사항
명세서", "기능 명세서", "고객요구사항" 등이 있다. 이 모두 완전히 잘못된 번역이다. 지금 나열한 문서의 제목은 "Requirements" 에 가깝다. 즉 기능명세서를 적어 놓고
SRS를 작성했다고 주장하는 것은 착각이다. "요구사항 명세서"가 그래도 비슷한 편인데 요구사항을 적는 것이라고 생각한다면 잘못된 것이다. 정확하게 말하면 첫째로 요구사항을 적고 그 다음에 "Specify" 라는
행위를 하고 나서 그 결과물인 Specification
문서를 적는 것이다. Requirements 가 있고 나서 그것을 기반으로 Specify 해야 비롯 SRS가 작성되는 것인데
Requirements만 적었지 아직 Specify하는 행위는 시작하지도 않았다. 그런 이유로 SRS를 간단히 "Specification" 혹은 "Spec" 이라고 부른다.
그러면
그게 그거지 뭐 이렇게 문서를 많이 적어야 하는 지 짜증이 들지도 모르겠지만 그 것도 착각이다. 고객의 요구사항을 가져 오는 것은 개발자의 업무가 아니다. 즉 개발자들이 전문성도 없고 자기 업무도 아닌 엉뚱한 일을 하고 있었던 것이다. 고객의
Requirements를 정리하고 가져오는 것은
마케팅부서의 핵심 업무이다. 보통 마케팅부서의 업무를 "4P"라고 표현한다. Product, Price, Placement, Promotion 이라는 4개의 용어가 모두 P로 시작하기 때문에 붙여진 이름이다. 그 중의 Product이 바로 제품을 정의하는
업무이다. 즉 Requirements를 작성하는 것이다. 마지막에
Promotion이 "홍보" 인데 한국에서는 "마케팅" 이라고 하면 "홍보"를 의미할 정도로 완전히
잘못 사용하고 있는 용어이다. 미국에서는 Promotion을 담당하는 분서는 마케팅부서 중에서 "Marketing Communication"이라고 한다.
결국 개발자들이
"요구사항 명세서" 라는 것을 작성하는데 자기 일도 아닌 마케팅부서의 일을 하고 있는 것이고 그 것을 SRS 를 적었다고 착각하는 2가지 오류를 범하고 있는 것이다. 왜 그런 상황이 되었는지는 이유가 있지만 나중에 얘기하기로 하자. 그나마 개발방법론을 조금 안다고 주장하는 사람들이 뭔가를 적지만 아예 Requirements도 없이 추상적인 기획이나 비전만 가지고 코딩으로 뛰어드는 용감무쌍한 개발자들도 많이
있다.
그래도
거대방법론을 도입한 회사(주로 대기업)들은 방법론이 요구하는 문서를 보고 적다 보면 그 와중에 형식적으로는 Specify 라는 행위의 결과물을 적는 흉내를 내게 된다. 하지만 본질을 모르는 상태에서 템플릿에 적는 방식으로는 한계가 있다. 제대로 충실한 내용이 적힐 수가 없다. 어떤 방법론을 사용해도 마찬가지이다. 나중에 설명하겠지만 "일체성(Integrity)"이라는
핵심 특성이 있다. 진정한 SRS가 완성되기 위해 꼭 고려되어야 하는 특성이다.
도대체
SRS가 무엇인지 궁금증을 약간 해소하기 위해 여기서는 매우 간단히 SRS에 적어야 하는 대표적이고 핵심적인 일부 항목들만 나열해 보자. IEEE에서 SRS에 대해 전세계 전문가들이
만들어 놓은 바이블과 같은 Template에서 가져온 것이다. 혼란을 피하기 위해 영어를 같이 사용한다.
- Purpose (목적)
- Prodcut Scope (범위)
- Product Perspective (제품조망)
- Overall System Onfiguration (전체 시스템 구성)
- Overall Operation (전체 동작방식)
- Product Functions (제품주요기능)
- Assumptions and Dependencies (가정과 종속관계)
- Apportioning Requirements (단계별 요구사항)
- Backwards Compatibility (하위호환성)
- Operating Environment (운영환경)
- Development Environment (개발환경)
- Test Environment (테스트 환경)
- Configuration Management (형상관리)
- External Interface (외부 인터페이스)
- User Interface (유저 인터페이스)
- Peformance Requirements (성능요구사항)
- Non-functional Requirements (비기능요구사항)
- Functional Requirements (기능요구사항)
- Change Management Process (변경관리 프로세스)
어떤 방법론을
사용하든 이와 비슷한 용어들은 많이 들어 보게 된다. 모든 방법론이 나온 근원이고
여기에 포장만 입혀 놓은 것이기 때문에 너무 당연하다. 이것을 다 작성한다고 생각하면
기겁을 할 수도 있다. 실리콘밸리나 한국이나 개발자의 성향은 같다. 재미없는 일을 하는 것은 인간이면 다 싫어한다. 그런데 재미를 모르는 것이지 재미 없는 것은 아니다. 분석을 하고 이런 문서를 적는 것이 코딩보다 더 재미있는 일이라는 것을 인식하게 될
때 바로 훌륭한 개발자가 되었다고 자부해도 된다. 이렇게 많은 문서를 다 적는
것이 아니다. 그렇게 해왔다면 SRS의 본질을 이해하지 못하고 있다는 것을 증명한다. SRS의 본질은 가장 빠르게
개발하는 것이 목적이다. 그레서 SRS가 적히는 방법은 모든 프로젝트가 다 다르다. 학교숙제를 할 때도 이 모든
문서를 일단 다 생각해 본다. 생각하는 시간은 1분이면 충분하다. 그 1분 동안 무슨 문서를 얼마나 작성할 것인가를 직감적으로 결정한다. 별로 작성할 문서가 많지 않다는 것을 알게 된다. 학교숙제의 경우 이 중에서 한두개만
작성할 수도 있다. 학교숙제가 아니고 한 달 짜리 프로젝트라고 해 보자. 그러면 어떤 문서를 얼마나 작성할 지를 결정하는데 역시 1분 이면 충분하다. 문서 2-3개 쯤 될 것이다. 필자가 일했던
General Electiric의 원자력 발전소
소프트웨어를 개발한다고 해 보자. 그러면 모든 문서를 작성해야 한다는 것을 1분 안에 직감으로 결정할 수 있다. 단 어떤 문서를 얼마나 적어야 할지는 모든 프로젝트마다 다르다. 필자가 해 본 수백개의 프로젝트도 다 달랐다. 즉 어떤 규칙으로서 적용할 수
없는 예술적인 판단이다. 그래서 소프트웨어가 극단적인 지적산업인 것이다. 주어진 템플릿보고 채워나가는 일을 하고 있다면 "개발 노동"을 하고 있는 것이다.
위에 나열한
것 중에서 전체 작성하는 문서의 양 중에서 어떤 경우는 'Functional Requirements'가 90%를 차지하기도 하고 " User Interface (유저 인터페이스)"가 90%를 차지하기도 하고, External Interface (외부 인터페이스)가 90%를 차지하기도 한다. 그를 조절하는 것 역시 어려운 판단이며 예술의 영역이다. 다시 한 번 강조하지만 어렵기 때문에 연봉을 많이 받는 것이다. 템플릿이나 채우고 있는 개발 노동자들에게 높은 연봉을 주는 바보 경영진은 없다.
다시 정리하자면 Requirements와 Specification은 완전히
다른 영역이며 Requirements는 마케팅의 업무이고 개발자의 업무가 아니다. 통상적으로 개발자가 수행해왔는데 비효율적인 것은 말할 것도 없거니와 그것을 SRS를 적었다고 착각하는 것도 큰 착각이다. 결론적으로 한국에서 벌어지는 거의 모든 프로젝트는 SRS가 제대로 적히지 않은 상태에서
개발을 해 왔다. 주먹구구식이거나 혹은 대형 방법론의 경우 형식적으로 적힌 가치가 없는
문서가 대부분이었다. 경험자들은 이런 사실을 잘 알고 있다. 애자일 방법론은 미국에서는 이미 유행이 지나갔지만 그냥 방법론의 하나일 뿐이지 개발의
원칙을 벗어난 예외가 될 수는 없다.
또 다른 관점에서 볼 때 가치있는 문서를 적었다면 오래동안 생존해야 한다. 나중에 보지 않는 문서라면 당연히 가치가 없는 문서이다. SRS는 제품이 단종이 될 때까지 살아남는 문서이다. 앞으로 진행하면서 SRS의 다양한 실체를 보게 되겠지만 소프트웨어 개발에서 가장 정교하고 어려운 행위라는 것을 명심하기 바란다.
댓글 없음:
댓글 쓰기