[소프트웨어 공학] 신입사원은 문서( 50% ), 프로세스( 45% ), 선배( 5% )로부터 배운다.

---

안녕하세요 돼지왕왕돼지입니다.

오늘은 "신입사원은 문서( 50% ), 프로세스( 45% ), 선배( 5% )로부터 배운다." 를 주제로 이야기하고자 합니다.

이 글은 "글로벌 소프트웨어를 꿈꾸다" 의 내용을 요약 정리한 것입니다. 

27. 신입사원은 문서( 50% ), 프로세스( 45% ), 선배( 5% )로부터 배운다.

- 문서와 프로세스가 잘 되어 있지 않으면 신입사원은 선배 없으면 생존할 수 없는 상황이 된다. 이를 한국에서는 사수-부사수 시스템이라고 부른다. 

- 선배나 동료 등 타인에게서 배울 일은 많다. 그리고 회사는 이것을 시스템화시켜야 한다. 지식 공유가 효율적으로 이루어지려면 잘 작성된 문서와 프로세스가 필수 조건이다. 이를 구축하는 것은 어느 한 사람만 열심히 해서는 효과를 거둘 수 없고, 협업하는 문화를 정립하는 것을 통해 이루어진다. 그리고 이것은 지금 바로 당장 시작해야 하는 일이다. 

28. 프로세스의 힘, 마지막에 무리한 사양변경을 막는다.

- '사양변경' 은 잘못된 계약, 불충분한 초기 분석, 문서의 부재, 개발자의 풍부한 상상력, 프로세스의 부재, 그리고 제왕적이고 무지한 고객이나 경영자의 행태가 합작되어 나온 부작용이다.

-  프로세스가 잘 잡힌 회사에서는 어느 시점이든지 사양변경이 요청되면, 누가 요청했냐에 상관없이 그 요청이 합리적인가를 판단하는 프로세스가 있다. 대표적인 것 중 하나가 "Go-Live 회의" 인데, 최종 출시전의 회의로 결함이 있는 상태로 출시할 것인지 연기할 것인지를 정하는 회의이다. 이는 참여한 모든 부서 및 인원이 어느 정도 동의를 했을 떄 판단이 이루어진다.

- 프로세스가 잘 잡힌 회사는 애초부터 사양변경이 생기지 못하도록 수시로 이런 상황들을 예방하기 위한 점검이 프로세스로 이루어져 있다.

29. 최소비용과 최소시간.

- 정도의 차이는 있지만, 모든 소프트웨어 회사에서 일어나는 공통된 현상, 즉 문제( 적은 시간에 제품을 만들어야 하고, 만들어도 고객이 계속 요구사항을 바꾸고, 문서는 계속 변경해야 하는 등 )를 해결하기 위한 노력으로 소프트웨어 공학이 생겨났다.

- 소프트웨어 공학의 유일한 목적은 "최소의 비용으로 최소의 시간에 좋은 품질의 소프트웨어를 만드는 것". 개발을 방해하는 것으로 오해하지 말아야 한다.  

- 소프트웨어 개발에 소요되는 비용을 생명주기의 각 단계가 차지하는 비율로 보면 요구사항정의단계에 10%, 설계단계에 10%, 프로그래밍단계에 10%, 테스트 및 디버그단계에 10%, 그리고 유지보수단계에 소요되는 비용이 대략 60%를 차지한다.

- 검출되는 에러는 요구사항정의단계에서 56%, 설계단계에서 27%, 프로그래밍단꼐에서 7%가 발견된다는 통계도 있다.

- 소프트웨어 공학은 현실에서 시행착오를 거치며 배울 수 있는 것이지, 가르침을 받아서 배울 수 있는 것이 아니다. 시행착오를 덜 겪는 유일한 방법은 선각자와 같이 일하면서 최소시간에 최소비용으로 개발하는 것이다. 

30. 간단한 것의 가치가 복잡한 것보다 크다.

- 소프트웨어에서 변하지 않는 중요한 것은 극히 간단하고 상식적인 것들이다. "개발을 잘하려면 분석과 설계를 충분히 해라.", "동료검토를 하라" 등이다. 하지만 이것을 지키기는 쉽지 않다.

- 기본적인 것도 지키지 못하면서 새로운 방법론만 내세우는 사람은 그저 신기술 수집가이다. 누구나 알고 있는 몇 가지 핵심을 제대로 실행하는 것이 훨씬 더 중요하다. 

31. 급한 것과 중요한 것.

- 중요하지만 급하지 않은 일은 너무나 당연하지만, 대부분의 회사가 게을리 하고 있다. 또한 긴급한 일이 일어나지 않게 하는 것은 매우 중요한 일이다.

32. 찰떡같이 붙어 있는 분석, 설계, 코딩을 떼어내라.

- 한국은 대부분의 개발자가 분석, 설계, 구현까지 다 하고 있는 상황이지만, 분석, 설계, 구현은 따로 나누어져야 전문성도 생기고, 일의 진행속도도 더 빨라진다.

-  업무를 알아야 분석이 가능하다는 믿음은 오해이며, 많은 분석가들의 분석 산출물은 보통 타인이 이해하기가 어렵게 되어 있다. 이런 문제로 한국에서는 분석, 설계, 구현을 개발자가 다 한다. 하지만, 제대로 된 분석은 업무를 모르는 사람도 가능하며, 분석 산출물은 타인이 이해할 수 있도록 작성되어야 한다.

33. 서로 배우게 하라.

- 능동적으로 나서서 미래에 생길 수 있는 문제를 발견하고, 부서 간의 협업을 유도해서 해결책을 마련하려고 하는 사람처럼 회사에 중요한 사람은 없다. 따라서 회사는 협업을 시도하는 사람에 대한 평가를 높여 주어야 합니다. 그렇지 않으면 자신의 것을 잃기 싫어 협업을 먼저 시도하지 않습니다.

-  진정한 소프트웨어 전문가가 되기 위해서 어려운 세 가지는, 좋은 개발환경을 접하기가 어렵다는 것. 좋은 스승을 만나기가 어렵다는 것. 마지막으로 자기 자신이 깨닫기가 어렵다는 것이다.

- 스승을 찾을 수 있는 상황이 안 되면 동료에게라도 배워야 하며, 그래서 동료 검토가 중요하다. 동료의 장점과 실수를 검토하고 의논함으로써 서로 많은 것을 배울 수 있다. 선배나 스승의 존재는 훨씬 더 빨리 배우고 시행착오를 줄일 수 있기 때문에 동료보다 더 중요하다. 

34. 동료검토 ( Peer Review ) 는 권장하지 마라.

- 동료검토는 매우 중요하고 필수적으로 정착되어야 할 개발문화이다. 이 동료검토는 자발적으로 이루어져야 한다.

- 동료검토는 코딩뿐만이 아니라, 설계부터 검토가 되어야 한다. 즉 개발의 첫 단계가 동료검토의 시작점과 일치되어야 한다. 동료검토의 대상은 소프트웨어 개발단계인 제품 기획, 요구사항분석, 설계, 코딩, 빌드, 테스트 등에서 나오는 모든 산출물에 해당된다. 또한 개발의 가장 앞 단계부터 수행되어 정보 공유가 계속 되어와야 가치가 있다. 이런 선행조건이 없다면 동료검토는 안 하니만 못하기 쉽다. 

35. 조삼모사, 유지보수의 늪에 빠지다.

- 소프트웨어는 하드웨어와 달리, 유지보수라는 부분이 생명주기의 60~80%를 차지한다. 따라서 신중히 기능을 결정하고, 문서화하며 개발하지 않는다면, 나중에 유지보수에서 드는 시간은 엄청나다.

- 영업부서에서 불가능한 것을 요구한다면 못한다고 해야 한다. 대신 가능한 일정이라면 제대로 해야 한다. 모든 회사와 모든 사람에게 공통된 문제를 자기만 갖고 있는 문제인 것으로 착각하면 영원히 이 유지보수의 늪 문제에서 벗어날 수 없다. 

36. 머지 데이 ( Merge Day ) 를 정해서 할 이유가 없다.

- 한번에 한 사람씩만 순서대로 고치는 개발방식을 순차적인 개발 ( Sequential Development ) 라고 하는데 이 개발방식의 가장 큰 단점은 개발이 늦다는 것이다. 여러 사람이 동시에 개발하는 것은 병행개발 ( Parallel Development )이다. 병행개발은 머지라는 현상을 필수적으로 동반한다. 

- 2-way 머지는 두 개의 수정된 코드를 가져다 놓고 합치는 행위이다. Source Compare 프로그램으로 2개의 코드를 불러다 놓고 좌우로 봐 가며 수정한 것을 적절히 배치하면서 조합하는 것이다. 프로개발자는 3-way 머지를 사용한다. 이는 수십 년 전부터 수학적인 알고리즘에 기반해서 모든 소스코드 관리도구와 소스코드 에디터가 지원해온 기능이다. 3-way 머지는 최초의 원본 파일과 2개의 수정된 파일, 총 3개의 파일을 이용하여 머지를 한다. 이 3-way 머지는 믿어도 된다.

- 두 코드가 Conflict 나는 경우가 있는데 이는 Conflict 를 초래한 사람들이 모여서 의논하면서 머지를 해야 한다. 이 Conflict case 가 인간의 두뇌를 사용하여 머지를 하는 유일한 경우이다. 다행히 충돌나는 경우는 1000명의 개발자가 수십만 개의 소스파일을 3년간 같이 병행 개발했을 때도 손가락에 꼽을 정도였다. 

도움이 되셨다면 손가락 꾸욱~

---