내가 타이틀에 제시한 DDD는 Domain Driven Developement도 아니고, 지금 근무하고 있는 N사에서 반점개 리로디드를 얘기하면서 나온 Developer Driven Developement도 아니다.
또 다른 새로운(?) 방법론에 대해서 얘기를 하고 싶다.
사실 인터넷서비스가 10년이 넘어가면서 대부분의 서비스S/W는 기능도 많고 복잡하다. 하나의 feature를 구현하려면 엄청난 리소스가 소요되고 이 feautre는 후에 서스테이닝 비용도 증가를 시킨다. 물론 잘 만들면 되지 않냐라고 반문할 수 있겠지만 이거 또한 어려운 것 다 알고 있을 것이다. 일정은 항상 지연이 되고 생산의 최전방에 있는 개발자들은 몸을 혹사하며 고생을 하면서 Time to Market을 실천하고 있다.
순발력이란 무엇인가? 고객이 만족할 시점에 릴리즈를 하는 것이다. 순발력을 요구하는 것 자체는 어떤 수치적인 속도라기 보다는 고객의 만족도로 볼수 있고 경영진 입장에서는 열심히 해달라는 당부와 같은 것이다. 합리적인 출시일은 언제일까? 아무도 모른다. 사업적으로 중요하다면 우선순위를 높여서 열심히 하면 되는 것이지만 1주일/1달/6개월 출시가 지연되면 늦어지면 경쟁사에서 어떤 현상이 일어나는지 매출이 어떻게 바뀌는지 확인하기도 알기도 어렵다.
단지 출시일은 마케팅적인 요소가 많다. 그 때 출시를 하면 분위기를 바꾼다던가 새로움을 주면서 사용자 방문을 늘리도록 하는 것이다. 빅백형태로 한번 꽝터트리는 방법도 필요할 때가 있지만, 점진적으로 출시를 하면서 고객의 만족도를 높여가는 것도 좋은 선택이다.
다시 본론으로 돌아가서 내가 말하고 싶은 DDD는 Deadline Driven Developement이다. 개발자들 아우성이 들린다. 데드라인을 지키기 위해서 초과근무를 하라는 이야기냐라고 물어볼 수도 있다. 아니다 정반대의 이야기를 하고 싶다. 사업적인 목표나 고객의 바램으로 출시가 중요한 과제라면 일단 데드라인을 정하고 기획/개발/QA/출시를 하자는 것이다. 날짜를 정하면 자연스럽게 개발공정상의 일정이 나온다. 이 일정 안에 출시를 하려면 리소스와 스펙을 조정을 할 수 밖에 없는 것이다. 리소스가 정해져 있다고 하면 스펙만을 조정하는 것이다. 사업적인 순발력도 맞추고 무리한개발을 하지 않아도 된다.
내가 생각하기에 프로젝트는 보통 3개월 이내에 끝내는 것이 좋다. 설계, 테스트를 제외하면 순수 개발기간은 한달반정도을 일것이다. 프로젝트 인원도 많으면 속도가 느려진다. 프로젝트 성격에 따라서 다르지만 일반적으로 3명정도였을 때 가장 퍼포먼스가 좋았던것 같다. 그러면 3개월*3명 => 9m/m라는 결론이 나온다. 여기서 스펙은 개발자들이 한달반만에 구현이 가능한 수준이어야 한다.
Deadline Driven Developement은 스펙을 잘 조절을 하면서 가야하기때문에 고객과의 커뮤니케이션이 무척 중요하다. 이 부분에 자신감이 있을 때만 적합한 방법이다. 대부분의 실패한 프로젝트들의 특징은 기술적인 문제보다는 커뮤니케이션의 과다 발생으로 프로젝트가 지연되고 그러면서 품질이 떨어지는 경우를 많이 봤다. Deadline Driven Developement으로 진행할 때 가장 주의해야할 사항이다.
