소프트웨어 개발이 왜 힘든지..이를 위해서 무엇이 필요한지에 대한 프로세스 배경 설명

1. 소프트웨어 개발
프로세스 배경
마크베이스

2. SWEBOK says…
From www.swebok.org

3. 소프트웨어 개발의 어려움
• 비전공자라도 누구나 개발할 수 있어 보인다.
• 개발해 보면 실제로 사람마다 차이가 엄청 크다.
• 유지보수가 점점 더 힘들어진다.
• 같은 프로세스라도 결과가 다르다.
• 개발 방법론이 수백 가지는 넘는 것 같다.
• 이것 저것 해보지 않은 게 없다.
• 언제나 품질 때문에 고통스럽다. (고객의 비명소리가
여기저기서 들린다.)
• 아예 새로 작성하고 싶지만, 엄두가 안 난다.
• 주위에 제대로 소프트웨어를 개발하는 곳도 없고, 배울
곳도 마땅치 않다.

4. 소프트웨어 개발의 어려움
• 쓸 만 하게 키워놓으면 회사를 옮긴다.
• 도대체 문서화가 되지 않는다.
• 문서화가 되어도 품질이 낮거나, 유지보수가 안 된다.
• 제대로 테스트를 할 수 없거나, 테스트를 해도 품질이
보장되지 않는다.
• 기능을 하나 추가하면, 다른 기능이 동작하지 않는다.
• 고객 마다 하나씩 버전이 존재하고, 여러 벌의
소스코드를 유지보수 해야 한다.
• 개발 일정을 예측할 수 없다.
• 코드가 점점 더 스파게티가 되어 간다.
• 개발 경험이 조직에 습득되지 않는다.

5. 소프트웨어 개발의 어려움
• 고객사에서 생긴 문제의 상당수를 수정할 수 없다.
(재현이 불가능하거나 원인을 알 수 없다)
• 개발자마다 각기 다른 스타일로 코드를 구현한다.
• 언제 고객에게 전화 올지 몰라 가슴이 두근거린다.

6. 소프트웨어 개발 프로세스의 목표

7. 지난 시간의 시행착오와 경험
• 1999년 이후 시행착오의 연속
• 매년 새로운 시도와 조직학습의 반복
• 전혀 품질을 보증할 수 없는 수만 라인의
코드로부터 수백만 라인의 코드를 일정 품질
수준으로 관리할 수 있는 수준까지 도달
소프트웨어 개발의 멘토가 있었다면 2년
만에도 가능했을 것!

8. Software Triangle
프로세스
시스템사람
Good
Software
채용, 훈련, 멘토링
경험, 협업…
Knowledge Sharing
절차, 규약, 정책, 문서화
EPG/PAL
Requirement,
Bug System,
Release System,
QA Monitoring..
Intra Net

9. Triangle : 프로세스
• 하나의 업무를 달성하기 위한 단계별 행동
지침을 기술해 놓은 단위
• 개발 프로세스, 릴리즈 프로세스, 유지보수
프로세스
• 리뷰 프로세스, 코딩 룰, 릴리즈 정책…
• 시사점
• 일련의 업무를 정량화된 단계를 통해 일정한
수준의 품질을 가지는 소프트웨어를
개발하자는 관점
• 매우 중요한 관점! But, 전부는 아님

10. Triangle : 프로세스
• Software Engineering에서 바라보는
소프트웨어의 관점
• 일정한 수준의 정량적 지표를 만족하면,
누구나 개발하더라도 일정한 수준 이상의
소프트웨어 품질이 보장된다는 공학적 접근
방식!
• 그러나, 지난 30년간 공학를 통한 소프트웨어
품질향상은 크게 괄목할 만 하지 않음.
• 전체가 아닌 부분이라는 관점에서 접근하는
것이 중요!!
• Q) CMMI가 우리 제품의 품질을 보증할 수 있나?

11. Triangle : 사람
• SE에서 설명하지 못하는 부분
• Software의 복잡도가 높아질수록 공학적
효용성이 왜 떨어지는가?
• 왜 동일할 프로세스를 통해서 개발을
하더라도 사람마다의 결과물이 다른가?
• 균일 품질을 보장할 수 있는 개발 방법론이
존재하는가?  too many methodology
• 구현 대상물의 복잡도가 증가하면 공학보다는
예술에 가까워지는 소프트웨어의 특성이
고려되어야 함

12. Triangle : 사람
• 훌륭한 멘토와 같이 일을 할 수 있는 환경
• 멘토 그룹의 feedback을 받을 수 있는 환경
• 깊게 문제를 고민할 수 있는 시간과 공간적 지지
필요
• 소프트웨어 개발은 생각의 크기와 깊이에 그
결과물이 달라진다는 철학적인 이해가 반드시
필요!
• 좋은 인력…(누가 모르나…)
• 지속적인 Training 필요

13. Triangle : 시스템
• 시스템  행동을 조직화 할 있는 환경
• 해당 조직이 우수한 인력, 탁월한 프로세스를
가지고 있다 하더라도 그것이 지속적으로
유지될 수 있는 환경이 없다면, 일정 시간
이후에 해당 경험들이 사라짐.  조직 경험이
남지 않음.
• 업무의 시작 순간부터 마치는 순간까지 특정
환경(업무 프로세스가 자동화되도록)에서 수행,
감시, Feedback 될 수 있도록 반드시 수립해야
함.

14. Triangle : 시스템
• 예) 버그의 수정
• Open->Assigned->Fixing->Reviewing-
>Feedback->Closing->Close
• 환경 수립)
1. 버그는 반드시 버그 시스템을 사용
2. 해당 단계를 거치 않고, 다음 단계로 갈 수 없도록
3. 각 단계별로 입력해야 할 정보를 미리 정리, 부족하면
진행하지 못하도록.
4. 메일을 통해 관리자가 내용을 감시 혹은 자동화
• 조직내 관련 업무의 모든 지식이 자동으로
남게 됨  조직 학습 능력의 진화

15. Process for
Process

16. PAL (Process Asset Library)
• 기 정의된 제품 프로세스를 문서로 모아 놓은
라이브러리.
• 기본적인 프로세스 정의 프로세스부터 세부 업무
프로세스를 차트화해서 관리
• EPG(Engineering Process Group)를 통한 프로세스
변경시 반영 및 유지
• 모든 조직 구성원들이 쉽게 찾아보고, 학습할 수 있는
공간으로서 활용.
• 없다면?
• 정의된 프로세스의 명문화된 저장소가 없음 
모두가 암묵지화.

17. EPG 필요
• EPG : Engineering Process Group
• 전사 프로세스를 정의하기 위한 상위 프로세스 조직
• 프로세스 Stake Holder의 대표자가 참석
• CTO, 본부장, 리더급
• 사내 프로세스 이슈에 대한 토론 및 결론
• EPG 가 없다면?
• 프로세스 개선을 통한 업무 효율화를 위한 주체가
없어짐.

18. 정책
• 특정업무의 대원칙을 기술하고, 모든 구성원들이
따라야 할 의무를 지님.
•  암묵지를 형식지로 변환
• 예)
• 릴리즈 정책
• 개발 정책
• 유지보수 정책

19. 건강한 IT 조직의 조건

20. 결론
• 프로세스 + 시스템+경험 에 집중.
• 정답이 아니라, 정답을 찾아가는 경험을 공유
• 사람  정형화하기 힘든 문화적, 정서적 이슈