2016년 2월 21일 일요일

분석 #4 잘못된 이름으로 인한 치명적인 착각

 필자가 미국에 처음 갔을 때 한국교포 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의 다양한 실체를 보게 되겠지만 소프트웨어 개발에서 가장 정교하고 어려운 행위라는 것을 명심하기 바란다.

2016년 2월 14일 일요일

분석 #3 분할 발주의 허구와 진실

소프트웨어는 이론적인 개발 단계가 있다. 이론이라고 무시하려고 할지 모르지만 이론이 아닌 실전에서 가장 중요한 개념이다, 단계적인 개발 방식을 외부의 개발사와 계약으로 할 때 분할 발주가 된다. 이 용어는 다 이해하겠지만 제대로  따라하지는 않는다. 역량 때문일 수도 있고 의지 때문일 수도 있다. 여기서는 외주 개발사를 가정하고 분할 발주로 얘기하자. 하지만 개발단계의 핵심은 동일하다. 먼저 분할 발주의 목적을 알아야 한다. 목적도 모르고 무조건 분할 발주를 하겠다는 것은 방향도 모르고 눈 감고 길을 가는 것과 같다. 분할 발주의 목적 중의 하나는 개발 단계를 나누어서 각 단계의 발주를 다른 회사에게도 줄 수 있게 하는 것이다.

분할발주를 하려면 당연히 분할을 해야 한다. 잠깐 여기서 IEEE SWEBOK (SW 지식체계)에서 세계 최고의 실전 전문가 수백명들이 말하는 분할의 첫 단계인 분석의 목적을 몇 개만 나열해 보자.

- 개발에 드는 비용을 정확하게 산정하기 위함이다.
- 정확한 개발 일정을 알고 싶다.
- 설계를 위한 기초가 된다.

여기서 보면 분할 발주의 목적이나 분석의 목적이 같다는 것을 알 수 있다. 결국 분할 발주의 목적을 이루기 위해서는 분석을 잘해야 한다. 프로세스도 아니고 오직 분석이다. 진리는 가까운 곳에 있다. 반면에 지옥으로 가는 길은 매력적으로 포장되어 있다는 격언이 있다. 유행따라 멋있어 보이는 프로세스, 기법, 방법론들이 매력적으로 보이지만 결국은 대부분 사라지고 분석이라는 추상적인 원칙 만이 영원히 살아남는다. 대부분의 새로운 것들은 마케팅 천재들이 만들어 낸 멋진 마케팅 패션용어에 불과했다는 것을 나중에 깨닫게 된다. Big Data, IOT, Machine Learning등도 갑자기 생겨난 기적이 아니고 과거에 있었던 것들이 환경에 맞게 필요해 진 것 뿐이다. 때에 맞추어  새로운 이름을 붙이니 매력적으로 보이는 것 뿐이다.

국내에서 늦은 감이 있지만 분할 발주가 중요하다는 것을 깨달았다고 하고 법으로까지 만든다는 것은 나쁘지 않다. 하지만 법으로는 충분하지 않다. 법을 바꾸는 것은 쉽지만 사람들의 마음 속에서 편견을 없애는 것이 훨씬 어렵다. 전세계에서 인종에 대한 차별이 법으로는 거의 다 없어졌다. 하지만 사람들의 마음 속에는 아직도 뿌리 깊은 편견이 남아 있고 행동에서도 나타난다. 법은 한계가 있고 마음속으로 받아 들여야만 진정한 변화가 올 수 있다.

지금까지는 신도 얼마짜리 인지 알 수 없는 몇백억짜리 계약을 용감하게 해 왔다. 그렇게 하는 방식 외에는 본 적이 없으니 그런 방식이 인생인 줄 안다. 마치 처음 알에서 깨어난 오리새끼가 최초에 본 물체가 자기 어미인줄 알고 평생을 따라 다니는 것과 같다한국에서 벌어지고 있는 갈라파고스 신드럼 중의 하나이다. 필자가 실리콘밸리에 있었을 때 한국회사가 와서 이런 방식으로 미국회사와 계약하고 사업을 하려다 소송 당하고 철수한 적도 있었다. 필자가 아직도 의아하게 생각하는 것은 미국회사가 어떻게 애초부터 그런 계약을 했을가 하는 것이다. 정상적인 미국 회사라면 그런 비상식적인 계약을 했을 리가 없다. 아마도 한국 회사의 브랜드와 파격적인 약속을 믿고 계약했을지 모르지만 결국 두 회사 모두 피해를 입었다. 실리콘밸리에서는 한국처럼 엉터리 계약후 적당히 넘어가는 것은 문화적으로 불가능하다.

게약은 외부 회사와의 계약서만 계약이 아니다. 내부에서 개발 프로젝트를 하겠다고 하는 것도 똑같은 계약이다. 내부라고 계약 없이 대충하는 것은 주먹구구식으로 일하는 회사라는 것을 증명한다. 혹시나 친구끼리 시작한 신생업체인 경우 개발 계획도 없이 열정으로 열심히 해 볼 수는 있다. 운이 좋아 한탕은 가능할 지 모르겠지만 지속적인 성장은 불가능하다. 혼자서 열심히 연습해서 세계적인 피아니스트가 되겠다는 것과 다를 바 없다.

그러면 구체적으로 정상적인 경우에 어떻게 계약이 진행되는 지를 살펴보자. 가장 먼저 확실히 인식해야 할  진리는 개발시작 당시에는 소프트웨어를 개발하는 데 드는 일정과 비용을 신도 모른다는 것이다. 전지전능한 신도 모르니 아는 척 하지 말기 바란다. 그러면 결국 단 하나 남은 선택은 얼마를 줄테니까 알아서 개발해 달라는 것이다. 그래서 소위 우선협상대상자라는 것을 선정하고 정해진 계약비용안에서 무엇을 해 줄 것인가를 협상한다. 아주 그럴듯하게 보이지만 역시 엉터리이다. 이런 방법 외에 어떤 방법도 없어 보이지만 실리콘밸리에서 계약은 그렇게 진행되지 않는다. 오리새끼처럼 처음부터 잘못된 길에 들어서 한국에 뿌리깊게 자리잡은 잘못된 방법일 뿐이다.

그러면 과연 어떻게 진행되는 지 진실을 보자. 실제 경험 없이는 지금은 이해할 수 없는 미묘한 것들이 있지만 먼저 설명할 수 밖에 없다. 1인 회사나 글로벌 대기업이나 마찬가지로 소프트웨어 개발은 (1) 비전 -> (2) 기획 -> (3) 분석 -> (4) 설계 -> (5) 구현 으로 진행된다. 아니 진행되어야 한다. 이는 폭포수 이론처럼 들릴지 모르지만 극히 현실적인 방법이다. 폭포수에 대한 이해를 잘못하고 있는 사람들이 많지만 실리콘밸리는 그렇게 한가하고 이론적인 곳이 아니다. 실리콘밸리는 경쟁이 극심한 곳이고 가장 현실적인 방법론을 사용하는 곳이다. 이 중에서 통상적으로 비전은 경영진의 역할이고 기획은 기획부서 혹은 마케팅부서의 업무이다. 여기서 첫 단추가 잘못 끼워지면 뒷 부분에서 제대로 되기는 힘들다. 한국에서 필자가 본 기획은 대부분 비전에 가까운 추상적인 문서이다. 즉 분석을 수행할 만한 충분한 정보가 없다는 이야기이다.

일단 제대로 된 기획이 있다는 가정하에서 진행해 보자. 그러면 개발팀이 "분석+설계+구현" 을 해야 한다. 외부냐 내부냐에 상관 없이 얼마에 계약을 해야 하는 문제가 생긴다. 이게 비로 불가능한 일이다. 그래서 먼저 계약후 우선협상대상자를 선정해서 개발범위를 얘기해 봐야 역시 무지에서의 토론일 뿐이다. 무지에서의 토론이니 어떤 협상도 신빙성이 없다. 그것은 절대적으로 잘못된 방법이다.

그러면 옳은 방법을 보자. 개발 일정은 전지전능한 신도 모르지만 희망하는 목표 일정은 있다. 그 목표 일정의 30% 정도를 나누어서 "분석" 업무에 관한 계약을 한다. 그러면 다음과 같은 질문이 생긴다.

- 분석에 대한 계약 금액은 얼마로 할까?
- 어떤 결과를 원할까?
- 분석의 결과물 (총칭해서 SRS라고 한다)의 내용과 품질은 어떻게 장담할 수 있을까?

이 문제들은 분할 없이 전체를 계약할 때 생기는 문제와 동일해 보인다. 하지만 큰 차이가 있다. 해법도 단순하다. 이 계약은 결과물을 정하는 것이 아니라 분석에 소비하는 시간에 대한 비용으로 계약을 한다. 이를 "Time and Material" 이라고 한다. 즉 계약한 시간 동안 일을 하는 것이다. 나중에 얘기할 다른 방식은 "Turn-key"라고 한다. 목표 일정이 완전히 엉터리가 아니라면 약 30% 정도의 시간을 들여서 분석의 목적은 이룰 수 있다. 20%를 하든 30%를 하든 40%를 하든 그 목적을 이룰 수 있게 진행하는 것이다. 목적은 다음 단계인 설계와 구현에 필요한 일정과 비용을 정하기에 충분한 정보를 명시하는 것이다. 제품 개발을 완성하는 것이 아니기 때문에 30%이건 40%이건 목적에 맞게 분석을 완성할 수 있다. 분석의 결과는 유연하게 조절이 가능하다는 것이다. 얼마나 자세하게 명시하는 가에 따라 시간을 조절할 수 있다. 분석가로서의 경험이 있다면 당연히 그 정도는 조정할 줄 알아야 한다.

이 분석의 결과물의 논리적인 이름은 총칭해서 SRS라고 한다. 물리적인 문서 이름은 천차만별이고 회사마다 다르다. 문서의 종류와 갯수도 다르다. 하지만 똑 같은 원칙에 의해서 작성된다. 필자가 몇십년동안 수행했던 크고 작은 수백개의 프로젝트가 똑같은 형식의 결과물이 나온 적은 한번도 없었다. 여기서는 아직 어떤 결과물이 나오는 지 궁금해 할 수는 있지만 나중으로 미룬다. 하여튼 분석이 완료된 이 시점에서는 "설계+구현" 단계에서 해야 할 일이 얼마나 되는지 알 수 있다. "설계+구현"을 얼마에 계약을 할 지를 비로서 아는 시점이 온 것이다. 여기에서의 계약은 Turn-key 게약이다. 몇 명의 개발자가 일을 하는 가는 전혀 신경쓰지 않는다. SRS에 명시된 대로 개발해 주는지 아닌지가 핵심이다. 이미 개발내용이 명시된 상태에서 하기 때문에 우선협상 같은 것은 당연히 필요 없다.

즉 분할 발주를 한다면 계약은 (1) "분석"(2) "설계+구현"의 두단계로 나눈다. 또 분석의 중요한 목적의 하나인 이 프로젝트를 계속할 것인다 포기할 것인가도 여기서 결정할 수 있다. 30%의 비용을 들여서 분석을 했다고 해도 과감히 매몰비용(Sunken Cost)으로 버리는 것이다. 30%의 투자가 아까와서 안해야 할 프로젝트에 남은 70%를 투자하는 것은 바보같은 직이다.

설계와 구현 단계는 계약에서는 나누지 않는다. 연속성이 훨씬 더 중요하기 때문이다. 그리고 설계와 구현의 경계선을 긋는다는 것은 거의 불가능하다. 설계에 참여하지 않은 상태에서 코딩을 할 수 있게 하려면 엄청난 양의 문서가 필요하다. 설계와 구현을 분할하겠다는 생각은 그럴듯해 보이지만 현실과는 거리가 멀고 착각에 불과하다. 단계는 나눌지 모르지만 대부분의 개발자는 연속적으로 투입된다. 설계와 구현을 나누어 계약하는 경우는 필자의 실리콘밸리 경험상 본 적도 없을 뿐더러 가능하다고 해도 엄청난 시간의 낭비이다. 설계까지 나간다는 것은 이미 개발을 포기하지는 않는다는 전제를 가지고 있다. 즉 어차피 구현까지 계속 한다는 가정인 것이다. 설계까지 했다면 거의 70%를 진행한 것인데 이제 와서 포기한다는 것은 애초부터 계획이 심각하게 잘못되었다는 것을 의미한다. 여기까지 오다 보면 마치 거대한 프로젝트를 대상으로 얘기하는 것 같지만 이 원칙은 학교숙제할 때도 적용된다. 규모에 상관 없이 가장 빨리 그리고 효율적으로 개발하기 위한 원칙은 동일하다. 단 같은 원칙하에서 프로젝트에 따라 응용법은 달라지며 이 응용역량이 높은 연봉을 받는 진정한 분석 역량인 것이다.


이제 두 단계로 계약을 하는 목적과 그 단계의 경계는 절대적으로 "분석"이 끝나는 시점이 되어야 한다는 것을 이해할 수 있을 것이다. 이런 진리를 확실히 이해했다면 그 목적에 적합한 역량을 키우는 것이 다음에 해야 할 일이다. 분석을 수행하면서도 항상 기억해야 하는 것이 분석의 목적이다.