커스텀 개발 프로젝트를 진행하게 될 때, 애자일 개발 방법론으로 프로젝트 진행을 하는게 가장 유리하다는 생각을 가지고 있습니다.

전통적인 방식의 Waterfall 방식일 경우, 요구 사항(Requirements) > 설계 > 개발 > 테스트 > 유지 보수 등을 순차적으로 적용하게 됩니다. 앞단계가 수행이 되어야 다음 단계로 넘어갈 수 있습니다. 그리고 다음 단계로 넘어가고 나면, 다시 앞 단계로 돌아올 수 없습니다. 그런 이유로 Waterfall 방식이란 이름이 붙여진거 같습니다. 앞 단계로 돌아올 수도 있지만 굉장히 많은 Resource 낭비를 경험하게 됩니다.

과거에는 이런식의 개발 경험이 굉장히 많았습니다. 이렇게 개발 프로젝트가 진행이 되면 최종 런칭까지 시간이 많이 걸리게 됩니다. 즉 이 많이 걸리게 되는 개발 기간때문에, 처음 기획 단계와 달리 또는 사업 환경의 변화 등 많은 요건이 변경되어 처음 의도했던 방향과 틀어질 가능성이 높고 처음 기획이 런칭 시점의 현실과 맞지 않는 문제가 발생합니다. 문제는 Waterfall 방식인 경우 중간에 추가되는 요구 사항의 반영도 힘들거나 불가능한 경우도 많습니다.

사실 이제는, Waterfall 방식의 커스텀 개발로는 사용자가 원하는 결과물을 최종적으로 얻기가 불가능합니다.

이러한 개발 방식을 개선하기 위해 나온게 애자일 개발 방법론입니다. 애자일은 Waterfall 처럼 먼 미래, 최종 완성품을 정해놓고 개발하는 것이 아닙니다. 일정한 주기를 가지고 끊임없이 동작하는 또는 작은 단위로 구분되고 쪼개진 개별적인 개발 목표를 가지고 또 중간 중간 필요한 요구들을 더하고 수정하면서 만드는 방식입니다.

이를 통해, 계획과 절차를 따르는 시간과 비용이 전체적인 개발 흐름의 발목을 잡는 문제점을 개선할 수 있고 또한 빈번하게 바뀌는 요구 사항에 대해 더 민첩하고 기민하게 대응할 수 있습니다.

문제는 고객사에서 때때로 발생을 하는데, Waterfall 방식인 경우 보통 Requirements이 작성되고 그에 따른 개발 기간과 버짓 등이 좀 더 명확하게 정해지게 됩니다. 애자일의 경우는 대략적인 개요만 나올 뿐, 단계별 런칭 목표를 가지고 전체적인 개발이 유동성있게 관리되고 진행되기 때문에 정해진 버짓(Cost) 베이스로 작업하기가 힘듭니다.

물론 경험이 많다면, 좀 더 세분화된 개발 단위 목표와 스케줄을 통해 대략적인 버짓을 뽑을 수 있을 것입니다.

그렇지만 실제로는 그렇지 않은 경우가 많습니다.

더 큰 문제는 이러한 커스텀 개발 프로세스에 대해 고객사의 이해가 적을 경우 발생하게 됩니다. 최초 러프하게 협의된 방식에 때라 개발 시간으로 청구를 하였다가, 고객사에서 개발 기간과 버짓 베이스로 바꾸겠다고 하는 경우, 결국 Waterfall 방식으로 바뀌게 됩니다.

개발사 입장에서는 고객에게 전달한 개발 범위에 따른 소요 시간을 계산하여 러프한 개발 비용에 대한 합의를 한 상태에서, 좀 더 소극적으로 바뀔수 밖에 없습니다.

몇시간 또는 몇일의 시간만을 더 투자해서 전반적인 Front UI/UX를 개선할 수 있다는 걸 알아도 그렇게 하기가 힘들어집니다. 왜냐하면 이제는 납기일이 있고, 공급가격이 정해지 있기 때문입니다.

중간에 반드시 필요한 기능 요구가 있어도, 이미 제출되어 승인된 일정과 버짓으로 인해, 불합리하게도 채택을 못하는 경우도 많습니다. 이 경우가 사실 가장 안타까운 부분입니다. 이런 의사 결정의 반복 끝에 결국 프로젝트가 망신창이가 되는 경우를 많이 목격하고 경험했습니다.

최근에도 이런 일들이 있었습니다. 저 역시 해당 프로젝트를 임하는 태도가 달라질 수 밖에 없었습니다. Minimum Requirements에 해당되는 기능 구현만을 목표로 시간을 들이게 되면서 충분히 고민하고 개발할 수가 없게 되는거 같습니다.

개인적으로 참 안타까운 현실이라는 생각을 합니다.

합리적인 다른식의 접근 방법은 없을까?라는 생각을 다시금 해봅니다. 커스텀 개발 프로젝트의 성격에 따라 다른 좋은 방법들이 많을 수 있지만, 실제 가장 많은 개발 비용이 들어가는 코딩(구현) 부분을 일단 분리하는게 가장 손쉬운 방법 중 하나라고 생각합니다.

예를 들면, 소스 코드로 실제 구현하기 이전에 세분화된 디자인을 통해 디테일한 개발 요건들을 뽑아볼 수도 있습니다.(이게 안된다면, 파워포인트로 디테일한 와이어프레임을 만들어도 됩니다.) 실제로 이렇게 일을 하는 경우도 많은데, 코딩에 들어가기 전에 화면 디자인으로 이루어진 프로토 타입으로 실제 검증을 미리 해볼 수 있다는 장점이 있습니다. 충분히 해당 화면(기능)에 대한 검증이 실무자들과 함께 다각도로 이루어진 후 제품의 백로그를 정의할 수 있고 이를 통해 실제 시행착오를 줄일 수 있는 개발 요구 목록을 자세하게 작성할 수 있게 됩니다.

이런 방식을 User Story 개발이라고 하는데, 이 과정을 거쳐 어떤 개발자가 보더라도 궁금한 사항이 없을 정도로 구체적으로 개발 정의를 내리게 됩니다. 또 이 User Story를 통해 실제 이용할 고객이 얻을 수 있는 경험과 가치를 기술하게 됩니다. 이런식으로 개발 요건을 자세하게 명시할 수 있고 각 화면 단위로 개발 범위를 구분할 수 있게 만들수도 있습니다. 어떤 화면이 주어졌을 때 사용자가 어떤 이벤트를 발생하느냐에 따라 어떤 결과가 나온다는 것을 보여줄 수 있습니다.

이러한 조건들은 개발자가 TDD(테스트 주도 개발) 기반의 테스트 케이스 작성을 할 때 소스 코드에 그대로 포함되게 됩니다. 그렇기 때문에 최초 기획의 의도를 벗어나는 것을 최소화할 수 있게 됩니다.

이미 디자인 된 프로토타입으로 UX 검증이 끝났기 때문에 구현이 완료된 모습도 디자인과 다르지 않게 됩니다.

올바른 커스텀 개발 방법과 방식에 대한 고민이 많은 요즘입니다. 고객에게 어떻게 더 많은 가치와 완성도 있는 결과물을 전달해줄 수 있을지와 비용과 시간이라는 저울질을 하게 됩니다.

다만, 확실한 건 싼게 비지떡이라는 옛말이 있듯이 러쉬와 너무 낮은 개발 비용은 결국 퀄러티 저하로 이어질수 밖에 없습니다. 그리고 결국 더 많은 비용을 들여 유지 보수를 하거나 프로젝트 자체를 원점부터 다시 개발하는 경우도 많다는 점입니다.

마지막으로 대부분의 프로젝트가 실패하는 이유는 Waterfall 방식의 개발 프로젝트 + 고객의 요구 사항 변경 이라는 점입니다. 사실 이 “고객의 요구 사항 변경”으로 인한 프로젝트 실패를 해결하고자 소프트웨어 개발 세계의 존경 받는 개발자들이 모여서 선언문을 작성하게 되고 이것이 바로 2001년에 선언된 “애자일 소프트웨어 개발 선언” 입니다. (애자일 선언문: http://agilemanifesto.org/iso/ko/manifesto.html)

소프트웨어의 모든 것은 변한다. 요구 사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다.

– 자바 테스트 프레임워크 JUnit의 Kent Beck ‘익스트림 프로그래밍’ 36p

0 Comments

Cancel

My2Days Categories