소프트웨어 개발방법론의 한계

(출처 : http://www.buggymind.com/366 )

소프트웨어 개발 방법론 중 가장 널리 쓰이고 있는 것은, 아마 아직도 폭포수(waterfall) 방법론일 것 같습니다. 요구사항 분석 - 설계 - 개발 - 검증으로 이어지는 이 단순한 방법론은 그 단순성과 명료함 때문에 '그다지 심각한 고민 없이도' 현업에 도입되어 쓰이고 있습니다. 그런데 폭포수 방법론에는 대관절 무슨 문제점이 있길래 그토록 많은 비난의 대상이 되고 있는 걸까요?

이미 많은 증거들이 있어서 사실 제가 또 언급할 필요까지는 없는건데, 집으로 돌아오는 비행기 안에서 이런 저런 생각하다보니 이런 결론에 이르게 되더군요. '단순성'

폭포수 방법론은 사실 프로젝트 진행중에 벌어지는 다양한 상황을 처리하기에는 좀 지나치게 단순합니다. 일단 요구사항 분석이 끝났다고 치죠. 그러면 설계 단계가 진행되는데, 이 와중에 새로운 요구사항이 등장한다면? 제품을 개발하는 사람들이 어떻게 대응할 것이냐와는 별개로, 방법론 자체는 그런 상황을 처리하기에 그다지 걸맞지 않습니다. 사람들이 유연하게 대처하면 괜찮습니다만, 사실 그런 지경에 이르면 '방법론'이라고 부르기 껄끄러워지죠. 지키지 않는 방법론을 과연 방법론이라고 부를 수 있을까요?

사실 폭포수 방법론은 그 단순성을 커버하기 위해 굉장히 많은 문서들을 요구합니다. (아마 해 보신분들은 아실 듯.) 가능한한 모든 시나리오를 문서에 적어두고, 그 틀을 벗어나는 상황이 벌어지지 않기를 기대하죠. 유스케이스 문서에 장황하게 적혀있는 개발 시나리오는 그 중 한 예입니다. 하지만 예외 상황(exceptional case)이 한 가지만 새로 생기더라도, 유스케이스 문서는 고쳐져야 합니다. 유스케이스 문서의 양이 너무 많아서, 대체 어디를 고쳤는지 추적하기가 좀 난감하다는 점도 문제죠.

폭포수 방법론의 대척점에 서 있는 개발 방법론들은, 그래서 가능하면 프로젝트 개발의 각 단계를 '제어 가능한' 작은 단계들로 쪼개려고 합니다. 스프린트(sprint) 같은 것은 그 좋은 예로, 한두주 단위로 쪼개진 기간 안에 설계-개발-검증을 완료하고 또 그 다음 구간에 설계-개발-검증을 반복합니다.

각각의 구간이 굉장히 짧기 때문에, 그 구간이 진행되는 만큼은 불확실성(uncertainty)을 적절히 통제할 수 있습니다. 그 구간이 끝나야만 새롭게 등장한 요구사항들을 검토할 수 있죠. (애자일 개발 방법론도 그 중 한가지입니다.)

그런데 단순히 하나의 방법론에서 다른 방법론으로 이행한다고 해서 크게 나아지지 않는 것이 있습니다. 그건 프로젝트에 참여하는 사람 사이에 발생하는 역학관계죠. 그런 역학관계때문에 발생하는 문제를 해결하려면, 누군가는 프로젝트에 참여하는 사람에게 긍정적인 영향을 끼칠 수 있도록 수직적 관리방식에 영향력을 행사하거나, 아니면 팀원들간의 소통방식을 개선해야 합니다.

이 문제는 사실 개발 방법론의 한 부분일수도 있고 아닐 수도 있습니다만, 적어도 프로젝트의 성공을 위해서는 반드시 고려해야 하는 부분입니다. 방법론이 달라진다고 해서 프로젝트에 대한 압박이 사라지지는 않겠습니다만, 그런 스트레스에 대응하는 내적 능력은 달라질 수 있습니다. 프로젝트를 수행하는 데 필요한 방법론을 개선하는 데 있어서 가장 크게 고려해야 하는 부분은 그런 내적 능력을 증진시켜 팀원 모두가 적절한 수준의 항상성을 유지할 수 있도록 만드는 것이 되어야 할 겁니다.

보통 스트레스가 적절한 수준 이상으로 늘어나면 그런 항상성을 유지하는 것이 불가능하기 때문에, 결국 프로젝트를 성공으로 이끄는 것은 (적절한 능력을 가진 팀원들이 모여있다는 가정 하에서) 결국 스트레스를 어떻게 관리할 것이냐 하는 부분으로 귀결되는 일이 많죠. )

스트레스를 관리하는 방식은 여러가지가 있겠습니다만, 최근까지 등장한 방법들은 대략

1. 업무 시간이 일정 시간 이상이 되지 않도록 하여 팀원들이 휴식할 수 있도록 하는 방법
2. 팀원들에게 프로젝트 결과후 성과에 대한 유무형의 보상을 제시하여 감내하도록 하는 방법
3. 팀원들의 의사소통 방식을 개선하여 업무와 관련한 스트레스를 줄이는 방법
4. 프로젝트 수행에 관계된 수직적 관리 오버헤드와 태스크 스위칭을 줄이는 방법
5. 프로젝트 진도와 성과를 정량적으로 추정할 수 있도록 하여 보고 오버헤드를 줄이는 방법

등등이 있겠습니다. 이 중 5는 4와 관련이 있고, 3은 1과 관련이 있습니다. 1이 되도록 하면 가장 좋겠지만, 프로젝트 말미에는 불가능한 경우가 많기 때문에 2가 반드시 있어야 합니다. 2를 흔히 우리는 비전(vision)이라고 부르는데, 비전 없는 프로젝트가 팀원의 이직을 초래하는 경우가 많기 때문에 주의해야 합니다.

비전을 제시할 때 주의해야 할 것은, 비전에 대한 착시효과입니다. 팀원들은 비전이 없다고 생각하는데, 관리자는 비전이 있다고 생각하는 경우가 그 한 예입니다. 관리자가 보는 비전과, 팀원들이 생각하는 비전은 굉장히 많이 차이가 날 수 있습니다. 따라서 2는 3과도 관련이 있습니다. 비전이 하나로 수렴되려면, 관리자와 팀원 간의 의사소통 방식이 개선될 필요가 있습니다. 비전은 이야기하지 않으면 알 수 없는 부분 중 하나이기 때문에, 관리자와 팀원은 서로를 설득하거나 비전에 대한 간격을 줄이기 위해 애쓸 필요가 있습니다.

비전을 제시하는 가장 좋은 방법은, '무엇이 어떻게 나아질 것인지'에 대한 정량화된 지표를 제시하는 것입니다. 아쉽게도, 사람들은 '심증'이라도 없으면 아무것도 믿지 않습니다. 프로젝트가 종료된 후 팀원들이 떠나는 것은, 아무도 그 부분을 어떻게 제시할 것인지 고민하지 않기 때문이기도 합니다.

그래서 떄로 프로젝트를 관리하는 것은 단순히 야근을 하지 않는 회사를 만드는 것 그 이상입니다. 성공적인 프로젝트 개발 방법론을 만들고 싶으신가요? 어쩌면 정말로 중요한 것은 그 너머 어딘가에 있을지 모릅니다. 방법론이 잘못되어 프로젝트가 실패하는 것이 아닌지 의심하고 계시다면, 여러분의 프로젝트가 팀원들에게 어떤 비전을 제시하고 있는지 자문해 보세요.

세상에는 비전 하나만으로 야근을 견뎌낼 사람들이, 아직은 많으니까요.