함께 자라기: 함께(1)

본 포스팅은 함께자라기 책을 읽고 작성하였습니다.
함께 파트에서 감명깊게 본 부분, 다시 찾아봐야 할 것 같은 부분들 위주로 정리하였습니다.

함께 파트에서는 협력 방법을 배우고 수련합니다.

 

개선 우선순위

조엘 스폴스키가 만든 개발팀 평가 테스트라는 것이 있습니다.

1. 소스 컨트롤을 사용하는가?
2. 한 번에 빌드를 만들어낼 수 있는가?
3. 일일 빌드를 만드는가?
4. 버그 데이터베이스를 가지고 있는가?
5. 새로운 코드를 작성하기 전에 버그를 고치는가?
6. 최신 업데이트된 스케줄이 있는가?
7. 스펙이 있는가?
8. 프로그래머가 조용한 작업환경에서 일하는가?
9. 돈이 되는 한 최고의 툴을 사용하는가?
10. 테스터가 있는가?
11. 채용 면접 때 후보가 코드를 짜게 해보는가?
12. 복도 사용성 테스트를 하는가?

이 테스트는 한 때 많은 인기와 비판을 받았다고 합니다. (저는 처음 보는 거 보니 제가 개발자로 활동하기 전에 유행했었나 봅니다.) 조엘은 이 12가지 항목에 대해 예라고 대답해야만 완벽하다고 하면서 이것만 제대로 지속한다면 좋은 결과를 내는 잘 훈련된 팀이라고까지 호언장담하였습니다.

 

책에서는 이 테스트를 부정하고 전면 반박하고 있습니다.

 

일례로 8번 같은 경우 조용한 사무실보다 시끄러운 사무실(팀 전체가 의사소통하는)이 더 나을 수 있고, 9번 같은 경우도 비싼 툴보다 자신에게 익숙한 툴이 더 나을 수 있을 것입니다.

 

이 테스트가 유행하면서 관리자들은 '몇 번, 몇 번을 해결하면 되겠구나' 하는 안일한 생각을 가지게 됩니다. 이클립스를 사용하던 곳에선 인텔리제이 라이선스를 사주는 등 쉽게 해결할 수 있는 것부터 하려고 하겠죠.

 

QSM (Quality Software Management)라는 책은 총 4권으로 구성되어 있는데, 그 중 마지막 권에 소프트웨어 개발 비용에 대한 내용이 있습니다. 개발 비용을 결정하는 네 가지 요소를 소개하는데 각각 아래와 같습니다.

• 도구: 소프트웨어 개발에 사용하는 모든 종류의 도구
• 사람: 사람들의 능력과 경험
• 시스템: 제품 자체의 복잡도, 요구되는 신뢰성, DB 크기, 타깃의 변화 가능성, 스케줄 제약 등
• 관리: 사람을 배정하고 작업 분배를 조정하고 위임하는 것, 작업 모니터링, 동기 고취, 작업 조건/환경 개선, 자원 준비, 리스크 관리 등

이 중 영향을 많이 주는 요소에서 적게 주는 요소로 나열하면 순서가 어떻게 될까요? 대기업 200여명에게 설문조사 했을 때 나온 순서는 관리 -> 시스템 -> 사람 -> 도구 순이라고 합니다. 하지만 실제 개선 시도가 가장 빈번히 일어나는 곳은 바로 '도구'였습니다. 하지만 실질적으로 개선되는 부분은 도구가 3배, 관리가 64배의 효과가 있다고 합니다.

 

이 연구가 주는 교훈은 관리자들이 자기가 스스로 바뀌는 것보다 가장 쉬운 방법으로 도구를 바꾸는 것을 채택한다는 것인데요, 위에서 언급했던 조엘 테스트를 도구, 사람, 시스템, 관리 네 가지로 나눴을 때도 도구에 해당하는 부분이 가장 많으므로 좋은 평가 테스트로는 보기 어려울 거 같습니다. 그리고 관리자들도 도구보다는 스스로 관리 방식에 문제가 없는지 살펴보고 개선하는 것이 개선을 위한 첫 걸음이 되어야 합니다.

 

개인적으로는 프로젝트 중 전반적인 개발 관리를 맡아본 적이 엄격하게 말해 한 번 있는데, 그 때 시스템 -> 사람 -> 관리 -> 도구 순으로 신경을 썼던 거 같습니다. 결과적으로는 프로젝트를 성공적으로 이끌긴 했지만 이 책을 먼저 읽어보았더라면 관리 측면에서 더 신경쓰면서 성장할 수 있지 않았을 까 아쉬움이 남네요.

 

협력을 통한 추상화

일반적으로 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 더 뛰어나다고 자라기 파트에서 설명한 바 있습니다. 어떻게 생각하면 우리가 개발자가 되기 전에 생각했던, 또는 미디어에서 다루는 프로그래머와는 정 반대의 이미지라고 할 수 있습니다. 골방에 틀어박혀서 혼자 힘으로 짜잔! 하고 혁신적을 개발해내는 모습을 영화나 드라마에서 자주 접할 수 있고, 심지어 "사람을 대하는 게 싫어서 개발자가 되었다"라고 말하는 사람을 여럿 보았고 저도 그 중 한 사람이었습니다.

 

많은 실험에서 여러 사람들의 능력의 합은 최대 능력을 가진 사람보다 작다는 게 밝혀지면서 실력이 뛰어난 사람은 혼자 일하게 해야한다고 주장하는 사람도 많이 있었습니다. 하지만 반대 연구 결과가 점점 늘어나면서 이전 연구의 조건이 협력에 불리하게 짜여있다는 것이 밝혀졌습니다. 예를 들면 협력시에 시각화 도구만 제공해도 훨씬 더 나아진다는 것이 그 중 하나이죠.

 

스탠퍼드 대학에서 실험에 사용한 문제가 있는데 한 번 직접 풀어보세요!

다섯 개의 톱니바퀴가 가로로 길게 연결되어 있다. 가장 왼쪽에 있는 톱니바퀴를 반시계 방향으로 돌리면 가장 오른쪽의 톱니바퀴는 어느 쪽으로 돌까?

이런 문제가 톱니바퀴 개수만 각각 3, 4, 5, 6, 7, 8, 9로 바뀌면서 7개가 주어지고 마지막 8번째에서는 톱니바퀴 131개일 때 답을 구하라고 합니다. 처음엔 허공에 손을 저어가며 생각하다가 몇 번 해보다 보면 규칙을 찾아내고 더 이상 손을 사용하지 않고 131개일 때의 답을 이야기 할 수 있게 됩니다.

 

이 문제를 7번까지 풀기까지 추상화된 규칙을 찾아내는지 여부를 조사하였는데 혼자 작업한 경우는 14%, 둘이 작업한 경우 58%가 규칙을 찾아냈다고 합니다. 둘이 작업할 때 추상화 경향이 높은 이유는 서로 커뮤니케이션 하면서 혼동을 해결하기 위해 추상적인 개념을 도입하기 때문입니다. 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상적인 요소가 포함되게 됩니다. 반면 혼자 작업하는 경우 이러한 요소가 상대적으로 덜 필요하게 되겠죠.

 

참고로 답은 톱니바퀴가 홀수일 때, 짝수일 때를 생각하면 간단히 풀립니다!

 

소프트웨어를 개발할 때도 엄청 강조하는 것 중 하나가 바로 추상화죠. 특히 자바와 같은 객체지향 언어를 이용해 개발하는 경우 추상화 신경을 쓰지 않을 수가 없습니다. 책에서는 이러한 추상화를 높일 수 있는 방법으로 협력을 제시하고 있습니다. 개발자에게는 페어프로그래밍이나 몹프로그래밍이 추상화를 높일 수 있는 방법 중 선택지가 될 수 있습니다.

 

저는 현재 회사에서 페어프로그래밍과 몹프로그래밍 두 개를 모두 진행하고 있는데요, 서로 단축키와 같이 사소한 것도 공유하고, 한 줄 한 줄 코딩할 때마다 계속 커뮤니케이션을 거치기 때문에 결과물의 퀄러티가 상당히 올라가는 경험을 할 수 있었습니다. 물론 이 부분은 개발자들간 케미도 한 몫 하는 거 같습니다. 대부분 성격이 유하고 좋은 분들이 많고, 개발 실력도 크게 차이나지 않기 때문에 효율이 더 좋다고 느끼고 있습니다.