2015년 7월 26일 일요일

SWEBOK - SW 프로세스 #3 프로세스 관리

SWEBOK 해설 SW Process #3 프로세스 관리 - 2015-07-26


(*** 필자주석) 이번 번역을 시작하기 전에 회사에서의 상황에 대해 한마디.
회사에서 프로세스를 정의하고 구체적으로 프로세스를 따라서 일을 하기 위해서는 "프로세스 다이어그램" 이라는 것을 만들게 된다. 프로세스를 관리하기 위해서는 핵심적인 문서이다. 프로세스 다이어그램은 벤처회사인 경우 10 페이지 일 수도 있고 대기업인 경우 수천 페이지 일 수도 있다. 그 만큼 회사에 따라 프로세스의 숫자와 상세도가 다양하지만 수십 명의 개발자가 일하는 회사에서 프로세스 다이어그램 하나 없이 개발을 하고 있는 경우는 아직은 프로세스의 중요성과 필요성을 인식하지 못하는 상태라고 할 수 있다. 천재라고 하더라도 프로세스 다이어그램이 필요 없다고 생각하는 것은 총 잘 쏘는 병사가 전쟁을 수행하겠다는 것과 비슷하다. 회사에서 회계관리를 머리로 하는 것과 비슷하다. 새 직원이 들어왔을 때 가르쳐 주기도 어렵다. 프로세스라는 용어에 대해 과거의 잘못된 경험에서 온 거부감을 고집하기 보다는 모든 사람이 체계적이고 편안하게 일하는 기본 규칙이라고 생각하기 바란다. 물론 더 위험한 것은 이론가들이 만들어 놓은 과도한 프로세스이다. 소크라테스가 말한 '무지한 사람이 하는 행위는 절대 선이 될 수 없다 (The only evil is ignorance)"가 잘 적용되는 경우이다. 소프트웨어 공학이라는 용어자체가 "현실" 이라는 의미를 가지고 있듯이 본질적으로 이론가들이 가이드 하기에는 매우 위험한 분야이다.


8장 Software Engineering Process (소프트웨어 공학 프로세스)
1. 소프트웨어 프로세스 정의 ( 이전 포스트)
1.1 소프트웨어 프로세스 관리 (Software Process Management)

소프트웨어 프로세스 관리의 2가지 목적은 프로세스를 새로 도입할 때나 개선을 하려고 할 때 효율성(Efficiency)과 효과(Effectiveness)를 높이기 위한 것이다. 프로세스는 개인, 프로젝트, 조직 수준에서 벌어지는 모든 프로세스를 포함한다.

통상적으로 제품을 개발하는 있어서 효율성과 효과를 증가시킨다는 기대에서 프로세스를 도입하거나 개선을 하게 된다. 최종 목표는 개발비용, 개발일정, 제품품질을 향상시키는 것이다. 그를 위한 프로세스의 도입, 조직의 변경, 그리고 인프라구조의 변경(새로운 기술 도입이나 도구의 변경 등)은 모두 밀접하게 연관되어 있다. 프로세스 변경은 소프트웨어의 제품뿐 아니라 조직의 변경도 유발한다. 프로세스 변경은 전 조직에 파급효과(Ripple Effect)를 가져온다. 예를 들면 IT의 도구나 기술의 변경은 대부분 프로세스의 변경을 요구한다.

일부 과정에서 신규 프로세스가 도입될 때 다른 기존 프로세스가 변경될 지도 모른다. 예를 들면 개발과정에 새로운 검사 프로세스를 도입하면 테스트 프로세스가 변경될 가능성이 높다. 이런 현상을 "프로세스 진화(Process Evolution)"라고 한다. 이런 진화가 대규모인 경우에는 조직의 문화와 비지니스 모델도 프로세스의 변화를 수용할 수 있도록 같이 변화해야 한다.


(*** 필자주석) 회사의 변화는 의도적인 프로세스의 변화로 일어나기도 하지만 어떤 도구를 도입할 때도 일어난다. 예를 들어 빌드 도구, 정적분석기, SVN이나 Git와 같은 소스코드관리도구의 변경 등으로 항상 벌어진다. 그럴 때 가장 많이 하는 실수가 단순한 도구의 도입으로만 생각하는 것이다. 도구의 도입은 항상 크고 작은 프로세스의 변경으로 이어진다. 그럴 때 기존 프로세스를 처음부터 끝까지 검토해보는 것이 중요하다. 이런 경우를 위해 체계적으로 작성된 프로세스 다이어그램과 같은 문서가 필수적으로 필요하다.

프로세스의 변화는 많은 비용을 초래하게 된다. 실리콘밸리와 같이 오랜 공력이 쌓인 회사에서 조차 변화는 위험하기 때문에 조심해서 수행해야 한다. 현실적으로 대규모의 급진적인 변화는 거의 없고(또 그럴 필요성도 거의 없다) 대부분은 조그만 변경을 간헐적으로 한다. 그런 조그만 변화에도 개발자들의 준법정신이 성공에 큰 역할을 차지한다. 프로세스는 모든 사람이 규칙을 따를 때 효과가 있는 것인데 독불장군이 있다면 프로세스가 제대로 정착하기는 어렵다. 특히 프로세스는 형식적인 면과 내용적인 면이 있는데 형식적인 면에서는 억지로 따라 할 지 모르지만 내용적인 면은 강제화하기도 어렵고 평가하기도 어려운 부분이다. 예를 들어 동료 검토 같은 것이 그렇다. 하는 흉내는 낼지 모르지만 시간 낭비하는 경우가 많다. 그래서 내용을 충실하게 만들 수 있는 역량이 없다면 준비된 다음에 하는 것이 좋다.


121 소프트웨어 프로세스 인프라구조 (Software Process Infrastructure)

소프트웨어 프로세스의 도입, 구현, 관리는 각 단위 프로젝트에서 시작한다. 그렇지만 프로세스는 모든 조직에서 같이 일사분란 하게 도입할 때 조직의 모든 소프트웨어에 혜택을 줄 수 있다. 소프트웨어 프로세스 인프라구조(Software Process Infrastructure)는 프로세스의 정의, 프로세스의 해석, 프로세스의 정책, 그리고 프로세스를 적용하기 위한 절차를 제공한다. 더 나아가서는 투자비용, 도구, 교육, 프로세스 도입과 유지보수에 필요한 인력을 제공한다.

소프트웨어 프로세스 인프라구조는 프로젝트의 규모와 조직의 규모에 따라 다르다. 소규모의 간단한 조직과 프로젝트는 간단한 프로세스 인프라구조가 필요하다. 반대로 크고 복잡한 규모의 조직과 프로젝트는 크고 복잡한 프로세스 인프라구조가 필요하다. 큰 규모의 경우에는 프로세스의 구현과정이나 개선활동을 가이드하는 소프트웨어공학 그룹이나 운영 위원회 같은 조직이 만들어 질 수도 있다.

가장 흔하게 벌어지는 잘못된 착각은 소프트웨어 프로세스의 도입이 소프트웨어 프로젝트에 추가적인 시간과 비용을 더한다는 생각이다. 당연히 프로세스의 도입과 개선에 들어가는 비용이 있다. 하지만 조직적인 프로세스의 개선이 높은 생산성, 비용절감, 재작업의 감소, 품질 좋은 제품의 혜택이 있다는 것을 경험이 보여주었다. 프로세스의 성능이 소프트웨어 제품의 품질에 영향을 미친다고 볼 수 있다.


(*** 필자주석) 간단하면 간단한 프로세스, 복잡하면 복잡한 프로세스가 필요하다는 너무 당연한 얘기이지만 실제로 따라 하기는 힘들다. 간단하다고 아예 안 하는 경우도 많고 큰 규모를 한 번에 하려는 경우도 많다. 변화에는 Big bang(한번에)과 Phased Approach(단계별)가 있는데 프로세스에도 Big bang이 좋은 경우도 있고 Phased Approach가 좋은 경우도 있다. 예를 들어 이슈관리시스템은 형식으로는 Big bang으로 도입하지만 내용은 Phased Approach로 서서히 향상시켜 가야 한다. 내용과 같이 경험이 쌓여야지만 제대로 수행될 수 있는 것을 Big Bang으로 수행하는 것은 불가능하다. 도구는 한 번에 준비를 해 주지만 사용은 천천히 해야 현실적이다. 골프를 하루에 다 배우겠다는 것과 같다. 단 골프채는 시작할 때 사 주어야 한다.

또 얼마나 간단한가를 판단하는 것이 중요하다. 필자가 가장 많이 본 실수는 원칙을 알고 적용하는 대신에 자신이 하고 있는 잘못된 관행을 진리로 알고 프로세스로 옮기는 것이다. 원칙을 정확히 아는 것이 중요하다. 프로세스가 다른 개발방법론이 100개가 넘게 있지만 모두 원칙은 동일하다는 것을 깨닫기 바란다. 어느 날 갑자기 획기적인 방법론을 발견했다고 도입해서 사용한다면 성공할 확률은 없다. 그런 금방망이는 존재하지 않는다. 건강식품 판매자 들의 과대선전으로 생각하면 된다. 건강식품과 같이 판단 실수와 오류를 건전한 시행착오로 미화하면 안 된다. 어떤 시행착오는 성장에 꼭 필요한 경험이기도 하지만 어떤 시행착오는 조직과 자신을 회복이 불가능한 파멸로 이끄는 경우도 있다. 모든 배움이 그렇지만 소프트웨어에서도 훌륭한 스승의 역할이 그래서 중요하다.


다음 포스트의 순서는 다음과 같다.
2. 소프트웨어 생명주기 (SW Life Cycles)
2.1 소프트웨어 프로세스의 분류 (Categories)
2.2 소프트웨어 생명주기 모델 (Life Cycle Models)
2.3 소프트웨어 프로세스 적용 (Adaptation)
2.4 현실적인 고려 (Practical Considerations)

3. 소프트웨어 프로세스 평가와 개선( SW Process Assessment and Improvement)
3.1 소프트웨어 프로세스 평가 모델 (Assessment Models)
3.2 소프트웨어 프로세스 평가 방법 (Assessment Method)
3.3 소프트웨어 프로세스 개선 모델 (Improvement Models)
3.4 연속적, 단계적 소프트웨어 프로세스 등급 (Continuous and Staged SW Process Ratings)

4. 소프트웨어 측정 (SW Measurement)
4.1 소프트웨어 프로세스와 제품 측정 (Process and Product Measurement)
4.2 평가결과의 품질 (Quality of Measurement Results)
4.3 소프트웨어 정보 모델 (SW Information Models)
4.4 소프트웨어 프로세스 측정 기술 (Measurement Techniques)

5 소프트웨어 공학 프로세스 도구들 (SW Engineering Process Tools)

2015년 7월 12일 일요일

SWEBOK - SW 프로세스 #2 정의

8장 Software Engineering Process (소프트웨어 공학 프로세스)

1. 소프트웨어 프로세스 정의


(*** 필자주석) 프로세스의 정의는 매우 중요한 주제이다. 잘못 이해함으로써 소프트웨어 회사에 막대한 피해를 끼칠 수 있다. 실제 국내 소프트웨어 회사에서 많은 비용과 시간을 낭비하는 것을 보아 왔다. 프로세스라는 용어는 매우 추상적인 단어이다. 이 정의는 아무리 잘 한다고 해도 역시 추상적이다. 결과적으로 모든 사람이 "프로세스" 라는 용어를 다르게 해석한다. 혹은 다르게 느낀다. 각자 자신이 경험한 범위 내에서만 이해가 가능하다. 경험하지 않은 것을 정확하게 이해할 수 있는 최고의 통찰력은 극히 소수의 사람만이 가지고 있는 역량이다. 여기 SWEBOK에서도 정확한 정의를 주기 위해 많은 노력을 한 흔적이 보인다. 하지만 글자가 현실을 설명할 수 있는 한계가 있다. 필자는 많은 개발 경험으로 프로세스라는 용어에 대한 거부감도 전혀 없고 1인 회사를 해도 프로세스를 적용한다. 반면에 잘못된 프로세스를 경험한 대부분의 국내 개발자들은 프로세스 혹은 더 나아가 소프트웨어 공학에 대한 느낌이 부정적으로 되었다. 이런 감정을 바꾸기에는 많은 시간이 필요할 것이다.

국내 대부분의 개발자들은 자수성가하거나 이론가들로부터 프로세스를 이론적으로 접하게 된다. 미국회사가 프로세스가 잘되어 있거나 소프트웨어 공학에서 중요하다고 하는 등 이런 저런 단편적인 사실을 잘못 이해하고 결과적으로 잘못된 프로세스를 경험하게 된다. 여기서 조심해야 할 것은 옳은 프로세스도 없지만 틀린 프로세스도 없다. 잘못된 프로세스는 잘못 적용된 프로세스이다. 즉 아무리 잘 만들어진 미국 국방부의 프로세스라고 해도 대부분의 회사에게는 나쁜 프로세스이다. 필자는 실리콘밸리의 2개 회사에서 거대한 프로세스를 경험했다. 그 프로세스가 그 회사들에는 적합하다고 생각하지만 나는 그런 회사에서 일하기를 선호하지는 않는다. 다행히도 실리콘밸리의 99% 회사와 국내 회사들은 그런 거대한 프로세스를 따라 할 필요가 없다. 그런데 이론적으로 접근하다 보면 자연적으로 거대한 프로세스가 만들어지기 쉽다. 그 것이 가장 그럴듯하게 보이기 때문이다. 그래서 필자가 말하기를 한국 소프트웨어에 독약으로 작용할 수 있는 것이 바로 프로세스이다. 적당히 사용한다는 것도 가장 추상적인 단어이기 때문에 구체적인 케이스는 불가능하다. 이런 경험의 영역이야 말로 진정한 소프트웨어 공학의 영역이며 건강식품과 같이 사기꾼들이 성행하는 분야이라는 것을 항상 주지하여야 한다.

이 주제는 소프트웨어 프로세스, 소프트웨어 프로세스 관리와 소프트웨어 프로세스 기반시스템과 관련되어 있다.

소프트웨어 프로세스는 입력되는 산출물을 다른 출력되는 산출물로 변형시키는 일련의 행위와 업무이다. 최소한도의 경우에도 필수 입력물, 변화시키는 행위, 생성되는 산출물이 있다. 약간 복잡해 지면 entry와 exit criteria, 그리고 행위(Activity)를 잘게 쪼갠 task 로 나눈다. Task는 관리의 대상이 되는 가장 작은 단위이다. 프로세스는 Event에 의해서 시작될 수도 있고 다른 프로세스의 Output이 이 프로세스의 Input이 될 수도 있다. 프로세스가 시작하기 위해서는 초기 전제조건(Input Criteria)이 만족되어야 한다. Output 산출물의 완수조건을 포함한 모든 조건이 만족되어야지만 프로세스가 완료되었다고 말할 수 있다.

프로세스는 하위프로세스(Sub-Process)를 포함하기도 한다. 예를 들면 Requirement Validation(검증)은 소프트웨어 개발을 시작하기 위해 충분한 정보가 있는지를 검증하는 프로세스인데 이는 Requirement Analysis의 하위 프로세스이다. Requirement Validation 프로세스의 Input은 Software Requirement Specification(SRS) 와 validation을 수행하기 위한 인력과 시간, Validation을 위해 사용할 도구이다. Requirement Validation 활동은 SRS의 검토, 프로토타이핑, 모델 검증 등을 포함할 수 있다. 이런 활동은 개인이나 팀 같이 행위의 주체에게 업무가 할당될 것이다. Validation 프로세스의 Output은 검증된 SRS이며 이런 SRS는 다음 프로세스인 설계와 테스트 단계에 사용된다.

(*** 필자주석) 마지막 문장 중에 눈치 채기는 어렵지만 매우 중요한 내용이 들어 있다. "검증된 SRS가 설계와 테스트 단계에 사용된다" 라는 말에서 보면 테스트 단계가 설계단계와 함께 진행된다는 것을 인식해야 한다. 나중에 테스트 chapter에서 부가적으로 설명하겠지만 V-Model에서 보면 가장 위쪽에 SRS와 같은 수준에 Acceptance Test Plan이 위치해 있다. 결론만 간단히 얘기하자면 SRS (1page건 1000page이건 어떤 형태가 되었던 상관없다)가 있으면 테스트계획과 테스트 케이스를 만들 수 있어야 한다. SRS가 부실하면 필연적으로 테스트도 부실해 진다. 여기서 인과의 법칙에 예외를 적용하는 실수를 하지 않기 바란다.

Requirement Analysis의 하위프로세스인 Requirement Validation이나 다른 하위 프로세스들은 흔히 겹치기도 하고 반복되기도 한다. 즉 하위 프로세스들은 입구와 출구를 드나들면서 몇 번 씩 되풀이 되기도 한다.


(*** 필자주석) 이 한 문장이 바로 Iterative 개발 방법론 또는 Agile 개발방법론과 같은 의미를 얘기한다. 실리콘밸리의 99%의 프로젝트는 Water Fall 방법론을 사용하지 않는다. 즉 완벽하게 SRS를 적고 한 번의 프로세스 만에 개발하려는 환상적인 생각은 용과 같이 거의 전설 속에서만 존재하는 것이다. 그런 면에서 혹시라도 미국 소프트웨어 회사는 거대한 프로세스를 사용하고 있다는 근거 없는 착각은 하지 말기 바란다. 가장 실용적인 방법으로 개발하고 있는 실리콘밸리가 상식적으로 Water Fall 방법론을 사용할 리가 없다. 실리콘밸리가 Agile 방법을 가장 잘하고 있는 것이다. 또 관련 주제가 나왔을 때 자세히 설명하겠지만 빨리 개발하겠다고 Agile 방법론이라는 이름으로 엉터리로 개발하는 것을 합리화하지 말기 바란다. "프로세스" 와 마찬가지로 "Agile 방법론", "Lean 개발"도 매우 조심해야 적용해야 할 단어이다.


소프트웨어 프로세스를 더 자세히 부연해서 설명하자면 IT 지원조직의 유무, 소프트웨어공학 기법과 도구, 업무 환경, 프로세스 수행의 효율성을 측정하기 위한 평가지수(KPI) 등과 같이 보조 역할과 역량까지도 포함된다. 더 나아가 여기저기 기술적 역량이 필요하기도 하고 다른 부서와 협력해야 하기도 하고 관리하기 위한 활동도 포함될 수 있다. 표기법은 자연어 텍스트의 형태로 설명한 활동들의 목록, Data Flow Diagram, State Charts, BPMN, IDEF0, Petri nets and UML activity 다이어그램 등으로 표현된다.

프로세스내의 변환(Transforming) 업무는 Checklist와 같이 순서적으로 정의된 Procedure의 집합으로 정의된다.

항상 강조해야 할 점은 "가장 좋은 프로세스"는 없다는 것이다. 소프트웨어 프로세스는 선택되어야 하고 조정되어야 하고 각 프로젝트와 조직의 목적에 맞게 적절히 응용되어야 한다. 이상적인 프로세스는 존재하지 않는다.


(*** 필자주석) 추상적이긴 하지만 위에서 열심히 정의해 놓고 여기 와서 이상적인 프로세스는 없고 적절히 사용해야 한다는 말을 한다. 결국 따라 해야 할 수 있는 구체적인 방법은 얘기하지 못한다. 그게 현실이고 본질이다. 결국 경험한 만큼만 이해한다는 지식의 저주와 비슷하다.


다음 포스트에서는 아래 1.1.과 1.2.를 적는다.

1.1 소프트웨어 프로세스 관리 (Management)
1.2 소프트웨어 프로세스 구조 (Infrastructure)

2. 소프트웨어 생명주기 (SW Life Cycles)
2.1 소프트웨어 프로세스의 분류 (Categories)
2.2 소프트웨어 생명주기 모델 (Life Cycle Models)
2.3 소프트웨어 프로세스 적용 (Adaptation)
2.4 현실적인 고려 (Practical Considerations)

3. 소프트웨어 프로세스 평가와 개선( SW Process Assessment and Improvement)
3.1 소프트웨어 프로세스 평가 모델 (Assessment Models)
3.2 소프트웨어 프로세스 평가 방법 (Assessment Method)
3.3 소프트웨어 프로세스 개선 모델 (Improvement Models)
3.4 연속적, 단계적 소프트웨어 프로세스 등급 (Continuous and Staged SW Process Ratings)

4. 소프트웨어 측정 (SW Measurement)
4.1 소프트웨어 프로세스와 제품 측정 (Process and Product Measurement)
4.2 평가결과의 품질 (Quality of Measurement Results)
4.3 소프트웨어 정보 모델 (SW Information Models)
4.4 소프트웨어 프로세스 측정 기술 (Measurement Techniques)

5 소프트웨어 공학 프로세스 도구들 (SW Engineering Process Tools)

2015년 1월 18일 일요일

소프트웨어 분할발주를 위해 선행해야 할 일





요새 정부에서 분할발주를 하겠다는 정책이 있다. 정책의 방향은 100% 찬성한다. 하지만 방법이 문제다. 정책의 자세한 내용을 가지고 왈가왈부해 봐야 탁상공론식으로 찬성, 반대, 우려, 상황론에 의한 합리화등 너무 많은 이슈가 얽혀 있어 쉽게 결론이 나지 않는다. 진실의 이슈가 아니라 이 이슈도 정치적인 이슈가 되어 버렸기 때문이다. 정치적인 이슈의 특징은 아무리 오랜 세월이 지나도 모양만 변형될 뿐 노블리스 오블리제는 없이 각자 이득을 취하기 위한 본질은 변하지 않는다. 일단 올바른 정책을 펴기 위해서는 먼저 본질을 정확히 파악하고 있어야 한다. 또 역량도 없이 증상만을 치료하기 위해 인기영합적인 정책을 수립한다면 필연적으로 다른 문제가 생긴다.

아래에 필자의 저서인 "글로벌 소프트웨어를 말하다, 지혜 (2014/06)"에서 쓴 "인도에 개발 외주 주는 방법" 이 있다. 이 글이 분할발주에 대한 실리콘밸리 소프트웨어 회사에서의 기본적인 원칙과 방법론을 말해준다. 원칙에 어긋나는 정책은 시행착오를 일으키며 또 몇 년의 세월을 낭비할 것이다. 또 역량이 없으면 방법이 원칙에 맞더라도 실패할 수 밖에 없다. 불행이도 국내에는 개발 앞 단계의 분석을 등한시 하는 문화가 오랫동안 진행되어 왔기 때문에 먼저 분석역량의 제고에 신경써야 할 것이다. 또 분석과 설계를 한 덩어리로 묶어서 얘기하는 경우가 있는데 이 둘은 완전히 다른 역량을 필요로 한다. IEEE SWEBOK의 분석부분을 번역해 놓은 것이 이 블로그의 SWEBOK 카테고리의 Post에 있으니 참고하기 바란다.

34장 인도에 개발 외주 주는 방법



실리콘밸리를 미국이라고 하니까 백인들이 많을 것이라고 생각한다. 실리콘밸리에는 동양인들이 백인들보다 많다. 버클리 대학에도 인종으로는 동양인이 가장 많다. 특히 실리콘밸리같이 IT 분야에는 중국 개발자와 인도 개발자가 전체 개발자의 반 정도 된다. 중국이야 원래 인구가 많아 캘리포니아에 많이 살고 있었고 따라서 중국인 회사도 많았다. 필자가 1980년도에 실리콘밸리에 도착했을 때도 중국 식당이 가장 많았었다. 그러면서 미국의 전문인력 이민(H1B) 정책으로 전세계 인재들이 몰려들면서 중국과 인도의 개발자들이 대거 채용되어 왔다. 이것도 연쇄작용이라 그렇게 온 이민자들이 또 동료들을 불러오고 하니까 점점 더 많아진 것이다. 인도는 또 영어권이라는 장점 때문에 미국 회사의 외주 프로젝트를 많이 수행하면서 소프트웨어 산업이 발전하고 강국이 되었다. 그렇게 된 원인은 단 두가지이다. 싼 임금과 영어권이라는 것이다. 특별히 머리가 좋아서도 아니고 원래 소프트웨어에 적당한 문화라서도 아니다. 솔직히 정직성이나 책임감은 인도나 중국보다는 상대적으로 한국 개발자들이 더 좋다고 생각한다. 성공의 원인은 미국에서 배운 개발방식이다.

미국 회사는 영어가 잘 통하고 임금이 싸다는 장점으로 인도에 많은 소프트웨어 프로젝트를 주었다. 그래서 TCS, Infosys, Wipro, Sapient 같은 세계적인 거대 시스템통합업체가 발전했다. 그러면서 미국의 소프트웨어 개발방식을 배워 강국이 되었다. 소프트웨어 개발을 맡길때 정직성을 믿고 시스템 없이 맡기는 것과 모든 개발자를 믿을 수 없는 인간이라고 가정하고 시스템을 믿고 개발하는 것과 어느 것이 좋을까? 즉 사회를 통치할 때 성선설로 보는 것과 성악설로 보는 것 중 어떤 방법이 사회를 더 평화롭게 만들 수 있을 까? 미국은 근본적으로 소프트웨어 개발은 성악설에 기반한 개발 문화이다. 누가 무슨 일을 하는 지 명확하게 정의하고 진행하는 과정에 대해서도 투명하게 돌아간다. 투명 그 자체이다. 비밀스럽게 일하는 사람들에게는 무척 거북한 시스템이다. 이런 방식은 인도와의 관계 때문이 아니고 미국 회사 내부에서도 똑같은 방식이 사용된다. 일년 365일 내가 어느날 몇 줄의 소스코드를 고쳤는지를 누구나 항상 알 수 있다. 즉 인도 때문에 개발방식이 바뀐 것은 없다. 그러면서도 창조성이 필요한 곳은 허용해 준다. 창조도 투명하게 하는 것이지 창조성이 몰래 하라고 내버려두는 무정부상태가 아니다. 법과 질서를 잘 지키는 것이 창조성과는 아무런 관계가 없다. 참견하지 않는 것은 창조성이 아니라 무책임한 것이다.

국내 소프트웨어 회사에서 내부 프로젝트를 수행할 때나 외주를 줄 때나 상대가 인도라고 가정해보자. 과연 계약서에 서명을 하고 인도에 프로젝트를 줄 수 있는가? 물론 영어는 문제가 아니라는 가정하에서다. 필자가 보기에 인도에 프로젝트를 줄 수 있는 회사는 거의 없다. 국내 소프트웨어 회사는 대충 개발하는데 너무 익숙해져 있어서 그렇게 사는 게 인생인 줄 안다. 그리고 합리화를 할 수 있는 무기는 많이 있다. 대충 몇 개만 나열해 보면 다음과 같다.

? 계약시에는 그렇게 자세한 내용은 알 수가 없어서 진행하면서 정해가야 합니다.
? 새로운 제품이라서 먼저 대충 화면이 나오고 사용자 평가를 받아보면서 조정해야 합니다.
? 시간이 없어서 대충 계약하고 일단 시작해야 합니다.

필자가 귀가 따갑도록 들은 앵무새 같은 소리들이다. 한국에 처음 왔을 때는 신기했지만 이제는 그런 소리를 들으면 안타까울 뿐이다. 새로운 혁신적인 프로젝트는 한국보다는 미국이 훨씬 더 많다. 그리고 자세한 것을 모르는 상태나 시간이 없는 상태는 전 세계 모든 소프트웨어 회사의 공통점이다. 이제는 착각에서 깨어날 때도 되었다.

인도와 외주 계약을 한다고 가정하면 계약금액이 있고 일정이 있고 사양이 있어야 한다. 계약이 성립하려면 발주자나 수주자나 개발종료에 대한 확실한 기준이 있어야 한다. 대부분의 소프트웨어 방법론에서는 인수테스트(Acceptance Test Plan)라고 한다. 한국의 방식에서는 수주자가 개발이 종료했다고 선언한 다음에 발주자가 인수를 위한 검증을 수행한다는 희안한 과정이 들어 있다. 전혀 잘못이 없어 보이는 이 과정은 발주자인 갑의 무소불휘의 권리이자 최후의 방어선이기도 하다. 이 인수 검증이 바로 모든 문제의 원인이다. 이런 식의 발주자의 주관적인 검증은 미국이나 인도 회사가 도저히 받아들일 수 없는 계약조건이다. 프로젝트 계약이 성립할 수 없는 근본 원인이다.

인도의 수주한 개발자도 스스로 제품에 하자가 있다 없다는 것을 개발이 끝나기 전에 알고 있어야 한다. 개발자도 모르는 상태에서 발주자의 주관적인 판단에 맡긴다는 것은 엄청난 리스크이다. 그런 상태에서라면 계약을 하지 않는다. 대부분의 국내 발주자 같은 진상고객을 만나면 낭패다. 추가 비용만이 문제가 아니라 다음 프로젝트 일정도 망가지고 회사 계획이 엉망이 된다. 즉 결론은 납품할 제품이 검증을 통과할지 안할지를 개발자가 명확히 알 수 있는 내용이 있어야지만 계약이 성립된다. 그렇기 때문에 구체적으로 적힌 인수테스트를 통과하면 그냥 개발종료된 것이다. 발주자가 이의를 제기할 수가 없는 것이다. 발주자의 검증은 개발자가 자체적으로 인수 테스트를 수행할 때 옆에서 지켜보는 것으로 끝나기도 한다. 발주자가 인수테스트를 수행한다는 것은 똑같은 테스트를 두 번 하는 것으로 시간낭비이다.

그래서 개발자들은 발주자와는 대화 한번 없이도 약속한 날자에 인수테스트를 통과한 제품을 납품함으로써 끝난다. 발주자가 강심장이라면 납품일자까지 가만히 있다가 인수테스트를 통과했으면 끝난 것이고 아니면 소송해서 위약금을 받아내면 된다. 통상적으로는 리스크를 줄이기 위해 중간에 점검을 하지만 계약서가 바뀌는 것은 아니다. 이런 시나리오가 성립되려면 무엇이 필요할까 하는 것은 방법의 문제이다. 이 책의 이 부분 저 부분을 다 엮으면 방법이 나올 것이다. 이것이 바로 실리콘밸리 회사에서 개발이 진행되는 기본 원리이다. 먼저 이 원리를 확실히 이해하고 그 다음에 방법을 찾아가기 바란다. 방법까지 찾고 실행까지 할 수 있다면 개발역량 만큼은 글로벌 회사 수준이다. 생각을 도와주기 위한 시나리오를 준다면 다음과 같다.

1. 계약서에 사인을 하고는 나중에 결과물을 인수받을 때까지 서로 간에 얘기할 필요가 없다.
2. 그러려면 계약시에 납품 통과 기준을 인수테스트 목록으로 명확히 알려주어야 한다.
3. 인수테스트 목록만 패스하면 그 외에 아무리 오류가 많아도 그대로 제품을 인수 받아야 한다.
4. 개발자는 스스로 모든 인수테스트 목록이 통과할 때 까지 개발을 계속한다.
5. 약속한 날자에 제품과 인수테스트 결과보고서를 첨부해서 납품하면 끝이다.
6. 발주자가 검증한다는 것은 인수여부를 위해서가 아니라 자기들이 미처 생각하지 못한 것이 있나를 검증하는 것이다. 있다면 자기 잘못이다. 미리 계약때 포함시켰어야 한다.
7. 납품받으면 끝이다. 그 때 필요한 추가 기능이 생각나서 인간적으로 해주세요 빌어도 안 해준다. 잔금으로 협박하지 말고 깨끗이 추가 계약을 하는 수 밖에 없다. 한국식으로는 했다가는 소송걸려서 이자와 재판비용까지 물어야 한다.
8. 그럼 인수테스트를 그렇게 잘 적으려면 무엇이 필요할까? SRS가 필요하다.
9. SRS에는 인수테스트를 위한 기능목록은 기본이고 성능사양, 비기능 사양등 원하는 모든 것이 포함되어 있어야 한다.
10. 결국 SRS를 잘 적어야 한다. 보통 국내회사에서 생각하는 것과는 상상을 초월할 만큼 양이 많다.
11. SRS를 잘 적기 위해서 누가 적으며 어떻게 해야 잘 적을까? 이게 문제이다. 또 다시 제1원인에 도달했다.

여기까지는 쉽게 제1원인을 찾아서 올 수 있었으나 여기서부터가 문제다. 요약하자면 미국 회사와 인도회사는 한 쪽은 SRS와 인수테스트를 잘 적고 한 쪽은 내용이 충분한지 검토한 다음 계약을 한다는 것이다. 이 과정에서 인도 회사들은 SRS를 읽고 개발을 해주는 역량부터 기르기 시작해서 서당개 3년이면 풍월을 읇는다고 SRS를 적을 수 있는 역량도 서서히 생겨난 것이다. 이런 SRS를 템플릿이나 샘플보고 적는다고 생각하는 것은 국내 개발자들의 망상이다. 차라리 책보고 골프배우는 것이 훨씬 쉽다. 이것이 바로 소프트웨어 개발에서 가장 어렵다는 분석역량이라는 것이고 수 많은 경험이 필요한 것이다.

지금 이 시나리오는 모든 소프트웨어 개발의 가장 기본 원리를 설명한 것이다. 방법론이나 프로젝트의 종류에 따라 응용에 차이가 있을 지는 모르나 이것은 소프트웨어 회사라면 절대적으로 가져야 하는 역량이다. 이 역량이 없는 이상 영원히 소프트웨어 선진국이 될 수 없다. 예외 중의 하나는 연구 프로젝트이다. 연구 프로젝트는 어차피 결과에 대한 약속도 없이 버리는 돈이라고 생각하고 서로 상대방과 미래의 파트너가 될 수 있을까 하는 탐색전 정도이기 때문에 이 시나리오에는 해당되지 않는다. 국내에서는 대부분 제품 프로젝트를 연구 프로젝트처럼 진행한다.

국내회사 중에 영어 문제가 없다고 했을 때 인도에 외주를 줄 수 있는 회사가 있을까? 그럴 수 있는 회사는 없다 라고 말할 수 있다. 인도와 외주계약을 할 수 있는 역량이 없다면 내부프로젝트도 제대로 할 수 없다. 문서의 양의 차이이지 생각하는 방식은 똑같아야 한다. 망쳐도 소송만 걸리지 않는다 뿐이지 혼란스럽고 일정연기, 사양변경, 품질저하는 필연적이다. 결국 국내 소프트웨어 회사는 이런 외주 역량이 없이 한국말을 한다는 편리성과 약자인 을을 잔금이라는 치졸한 무기를 동원해서 마음대로 부릴 수 있다는 생각으로 엉터리 외주 혹은 내부 프로젝트를 진행한다. 미국과 인도의 계약에서는 갑도 없고 을도 없다. 계약서 대로만 수행하면 되는 것이다.

위에서 말한 외주 방식을 Turn-Key 방식이라고 한다. 반면에 그냥 개발자 몇 명이 필요해서 임시직원처럼 사용하는 Time-and-Material (시간제 임금) 방식으로도 원격으로 인도 인력을 사용할 수는 있다. 필자가 선호하는 방식이다. 이런 경우에도 당연히 SRS도 있어야 하고 인사관리도 해야 하고 업무배분도 해야하고 프로젝트 관리능력이 있어야 한다. 인도에다 Turn-key로 모든 것을 맡기기에는 역량은 없고 불안하니 리스크를 조금 줄이는 방식이다.

앞 부분에서 말한 대로 소프트웨어 개발방식은 어떤 특정한 문화나 어떤 민족성에 상관없이 최악의 상황에서도 개발할 수 있는 방식으로 진화되어 왔다. 인도나 중국사람들이 전세계 소프트웨어 업계에 가장 많은 개발자를 가질 수 있는 것은 인종이 훌륭해서가 아니라 실리콘밸리의 개발방식때문이다. 한국과 같이 인정이 많고 인간적인 유대관계로 서로 믿고 개발하다가 소송하는 방식으로는 절대 선진국이 될 수 없다. 아는 사람한테 일을 맡긴다고 대충하려면 하지 않는 것이 현명하다. 믿는 사람과 대충하는 것보다는 시스템으로 일을 할 수 있는 모르는 상대방이 훨씬 안전하다.