급격하게 변하는 IT 기술에서 변하지 않는 것이 단 하나 있다.

바로 모든 것은 언제나 변한다는 사실이다.

3-tier 모델, Facade 패턴, OOP 개발 등은 모두가 변화를 염두에 두고 있다.

현재 있는 것이 변하게 될 때 얼마나 효율적으로 변화를 처리할 수 있는지를 고민하는 방법들이다. 기존의 폭포수(Waterfall) 모델이 프로젝트를 성공적으로 수행하는 데 별 효용이 없음에도 불구하고, 사람들은 애자일로 넘어가는 것을 거부하고 있다. 이는 변화를 두려워하는 관성 때문이기도 하고, 애자일을 받아들이기에는 성숙하지 못한 토양 탓이기도 하다.

[ Agile Manifesto 4 Values ]

Respondng to Change Over Following a Plan

애자일은 기본적으로 계획에 따르기보다는 변화를 긍정적으로 받아들인다. (또는 변화는 불가피하기 때문에 변화에 대한 계획을 세운다는 것이 적절하겠다)

PMP에서 정의하는 프로젝트의 세 가지 특성 중 하나는, 프로젝트는 점진적으로 구체화된다는 것이다. 이는 애자일에서 아키텍처와 요구사항을 점진적으로 완성해 나간다는 것과 일치한다. 기존 폭포수 모델의 단점은 (명백한 모순) 여기에 기인한다. 분석 – 설계 – 개발 – 테스트로 이루어지는 폭포수 모델의 단점은 다음과 같다.

1. Sequential 한 단계로 인한 시간 낭비

분석이 모두 끝나고 요구사항이 확정되어야 설계를 들어갈 수 있기 때문에 요구사항을 완료하는 동안 실제 개발을 할 수 없는 비효율성이 발생한다.

2. 변화에 대한 거부감

BRD를 확인하는데 갑과 을이 모두 혈안이 되어 있다. 갑의 입장에서는 BRD에 넣지 못하면, 구현을 못한다 생각하니 최대한 시간을 끌면서 BRD에 빠진 내용이 없는지 확인한다. 빠진 내용이 있어서가 아니라 불확실하기 때문에 Sign-off를 주저한다. 을의 입장에서는 BRD가 확정되어야 추후에 일정이나 범위에 문제가 생겼을 때 BRD를 기반으로 주장을 할 수 있으므로, 최대한 빨리 BRD를 확정하려 한다. 뭔가 꺼림칙한 마음에 BRD의 Sign-off를 미루는 갑과, 최대한 빨리 Sign-off를 받으려는 을이 서로 신경전을 벌이게 된다. 이렇게 BRD를 놓고 벌이는 신경전은 고스란히 일정의 지연으로 돌아온다. 데드라인이 정해진 프로젝트라면, 대부분 을의 일정에 타격이 된다.

3. Sign-off 하면 끝인가

천신만고 끝에 갑은 BRD에 Sign-off를 하였다. 그런데 BRD로 문서화된 것은 갑이 실제로 필요로 하는 것을 정확하게 나타낼 수 없다. BRD를 해석하는데 갑과 을의 논쟁이 벌어지기 일쑤다. 또한 프로젝트 진행 중 사업 환경의 변화로 요구사항을 바꾸고 싶어도, 을은 이미 BRD가 확정되었기 때문에, 추가 요구사항을 받아들일 수 없다고 한다. 복잡한 CCB를 거치거나, 추가 비용을 통해 해결해야 한다. 일반적인 폭포수 모델을 사용하는 프로젝트에서 대부분 갑과 을 간에 생기는 문제는 변화를 하지 않으려는 기본 마인드 때문에 발생한다. 을은 변화를 최대한 꺼리며, 갑은 언제나 더 나은 것을 생각해 내어 변경을 원한다. 만약 언제든 바꿀 수 있다고 을이 전제한다면, 갑이 굳이 Sign-off에 시간을 끌 이유도, BRD의 한 줄 한 줄에 그리 신경 쓸 이유가 없다.

Working Software Over Comprehensive Documentation

BRD를 작성하고, 정제하여 Sign-off까지 하는 데는 많은 시간이 소요된다. 심지어 그렇게 작성된 BRD가 고객의 요구사항을 완벽하게 반영하고 있지도 않으며, 추후 변화에 대해서 극도로 경직되어 있다. 이런 불완전한 문서를 작성하는 데에 시간을 쓸 바에야 바로 시작하고, 차차 정말 고객이 원하는 것이 무엇인지 같이 찾아가자는 것이 애자일의 방법론이다. 불필요한 문서 작업과 갑과 을의 신경전을 벌이는 시간을 제외한다면, 얼마든지 변화에 대응하며 실제 결과물에 더 집중할 수 있을 것이다. 이렇게 나온 결과물이 고객을 더 만족시키는 결과물이 되어야 하는 것은 당연한 것이다.