Ycombinator의 트윗 Why don’t software development methodologies work?을 보고 더 효율적인 개발에 대한 생각을 정리하고 고민하는 차원에서 번역해 정리해 둔 것을 공유한다.
방법론이 제대로 작동하는지를 어떻게 알 수 있나?
방법론이 잘 작동하는지 여부는 팀 생산성, 행복, 관계 유지, 예측 가능성, 책임, 의사소통, 일별 코드량, 맨먼스, 코드 품질, 만들어진 산출물 등 이런 기준에 따라 달라진다. 물론, 어떤 방법론도 올바른 지표를 사용해 측정한다면 잘 작동한다. 하지만, 측정 관점에서의 현실적인 문제 즉, 주어진 시간과 예산 범위 내에 요구사항을 만족시키는 그런 일관된 결과를 제공하는 방법론은 보지 못했다.
어림짐작이지만, 내가 알고 있는 대부분의 프로그래머는 같은 일을 경험하고 있다. 이 부분에서 말할 수 있는 것은 소프트웨어 개발의 모든 요소를 컨트롤할 수 없기 때문에 소프트웨어 개발 방법론에 대한 정확한 연구는 존재하지 않는다.
이런 생각에 대해 실험을 해 보자. 2개의 프로그래머 팀이 있다고 생각하자. 모두 동일한 요구사항, 일정, 예산, 그리고 동일한 개발 환경, 프로그래밍 언어 및 개발 도구를 사용한다. 한 팀은 워터폴/BDUF(big design up front) 방법을 사용한다. 다른 팀은 agile 기술을 사용한다. 이 사고 실험은 분명 좋은 실험은 아니다. 개개인의 스킬이나 팀원의 성격, 그들의 커뮤니케이션 방법이 개발 방법론보다 더 큰 영향을 미치는 것은 분명하기 때문이다.
2003년 People and methodologies in Software Development라는 논문에서 Alistair Cockburn이 정리했는데, 사람과 사람 사이에서, 더 나아가 순간순간의 경과 시간 속에서 변하는 사람들의 특성은 팀의 행동과 결과에 영향을 주는 첫 번째 요인이다. 그리고 서로 어떻게 잘 지내는지에 관한 문제와 직무에 관한 개인 특성의 적합도(비적합도)는 방법론에서 중요하고 프로젝트별로 제약 사항을 만든다. 이 결과, 사람들의 개인적인 특성은 일반적으로 방법론의 효과에 제한을 가하고 있다는 것을 의미한다.
우리 자신 최대의 적
내가 프로그래밍을 시작한 1970년대의 소프트웨어 개발 체계는 프로젝트 매니저, 비즈니스 분석가, 수석 프로그래머의 계층 구조로 아주 타이트하게 관리되었다. 개발 언어나 도구를 선택하는 것은 허용되지 않았다. 나는 몇 개의 크고 복잡한 프로젝트에 참여하고 있었지만, 대개 위에 말한 작업 방식과 크게 다르지 않았다. 성공한 프로젝트도 있었고 그렇지 않은 프로젝트들도 있었다. 지금은 개발 언어나 도구에 따라 개발 방법론이나 일하는 방식을 프로그래머가 선택하는 것이 일반화되고 있다. 분석가는 대부분 프로그래머 경험의 한 부분이 되지 못하고 있고, 프로젝트 매니저는 “팀 리더”나 “스크럼 마스터”의 형태로 왜소화되었고 관리자의 권한은 무력화된 채 팀의 의견을 정리하는 것 외에는 관리할 수 있는 것들이 없어졌다.
Gantt 차트, 일정, 문서를 활용한 엄격한 관리는 이해 관계자나 고객의 참여를 줄이면서 사용자 스토리를 도출했다. 지금 나에게는 괜찮은 선배들이 감독하고 있다고 생각되는 프로젝트는 거의 없다. 놀랍게도 프로그래머들은 카우보이 스타일의 코딩(카우보이처럼 내가 룰북이라고 생각하고 개인이 좋다고 생각하는 방법으로 개인기에 의존하는 코딩)으로 되돌아가지 않으려 하고 있고, 그들은 또 엄격한 방법론을 만들거나 채택했고 내가 경험한 1980년대보다 더 의식적이다. 사실 오늘날의 프로그래머는 1970년대 COBOL 현장보다 방법론 측면에서 더 엄격하고 맹신하고 있다. 실제로 나의 최근 프로젝트는 실제 아무런 가치를 만들어내지 못하는 모범 사례나 한두 명의 멤버가 많은 프로세스를 짊어지고 가는 그런 일상적인 프로젝트에 참여를 하고 있다.
대개 팀의 몇 명이 결정하거나, 혹은 한 명의 독재자가 결정하지만, 한번 프로그래밍 팀이 방법론을 채택하면 엄격하게 따르도록 강요받기 시작하고 곧 종교(맹신)가 된다. 그 결과 소극적 공격(passive-aggressive: 누구나 알고 있지만 뼈저리게 실감하지 못해 실천에 옮기지 못하는 것)으로 인해 그 어떤 방법론이나 기술 결정보다도 생산성을 빨리 죽여버린다.
어떻게 하면 잘할 수 있는가?
내 경험상 Cockburn의 논문이나 Frederick Brooks의 “No Silver Bullet - 은탄환은 없다”에서 “개념의 일관성(Conceptual Integrity)“에 대해 언급한것처럼 소프트웨어 개발 프로젝트는 팀 구성원 중에서 키맨 한 명이 구성원들에게 공통된 비전을 공유하는 것이 성공의 열쇠라는 것을 알려주고 있다. 이것은 특히 무언가의 방법론을 지칭하는 것도 아니고 유사한 프로세스가 없는 경우에도 일어날 수 있다. 일을 완료하면 모든 사람들이 프로젝트 도구에 완료라고 클릭하면 되는 그런 팀에서 일하는 느낌을 잘 알 것이다. 아직도 내가 이해하기 힘든 부분은 지금보다 BDUF나 비즈니스 분석가가 있던 예전이 더 나쁜 감정을 가지고 있다는 것이다.
나는 프로그래머는 의식이나 도구보다는 동료의 말에 귀를 기울이고 동료와 함께 일하는 것에 더 관심을 가져야 한다고 생각한다. 또한, 많은 프로세스나 방법론을 회의적인 시각으로 바라봐야 한다고 생각한다. 이렇게 되면 모든 사람들의 생산성 은 마법처럼 올라갈 것이다. 아마 프로그래머에게 사교적인 스킬은 다른 사람들보다 더 어려운 것은 인지 사실이다.(반드시 그렇다고는 생각하지 않지만) 하지만, 사교적 스킬은 다른 개발 방법론을 시도하는 것보다 훨씬 더 성과를 올릴 수 있다.
개발 방법론의 맹신보다는 구성원들의 특성과 역할을 잘 조율하고, 서로 커뮤니케이션을 통해 비전을 공감하며, 전체의 흐름이 올바른 방향으로 가고 있는지 상호 이해하면서 진행시키는 것이 중요하다.
정리해 보면
- 개발 방법론의 맹신보다는 구성원의 조합 및 개성을 잘 파악하는 것이 중요.
- 도구에 의한 진행 방식보다는 상호 소통을 통해 비전을 공감하는 부분이 중요.
- 개념의 일관성(Conceptual Integrity)이 의미하는 것처럼, 누군가 한 명이 키메이커가 되어 전체의 혼란을 야기하는 요소를 조율해주는 역할이 필요.
