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)

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)