프로젝트을 진행해 본 개발자라면 누구나 아래와 상황을 접하게 됩니다.
고객왈 : “이 필드 좀 하나 추가해 주시고요, 이건 이렇게 변경하셔야 됩니다”
개발자왈 : “이건 없었던 거잖아요 진작에 말씀해 주셨어야죠, 이렇게 하게 되면 전체를 다 바꿔야 돼서 안됩니다. 이렇게 수정할려면 전체를 다시 손봐야 돼서 새로 만드는 거나 다름 없습니다.”
코딩 마무리나 테스트 단계에서 종종 볼 수 있는 사무실의 풍경입니다.^^(이런 경우가 없으셨다구요? 여기 한국인데요…^^)
프로젝트의 마무리 단계에서 고객의 요청사항이 변경되어 고전을 하는 경우가 종종있습니다. 이 때 대부분은 “원래 그렇지뭐!” 하며 “고객이 요구하는데 어떻하겠어!”라며, 지금까지 수행했던 작업을 번벅하던지 심한 경우 전체를 뒤집어 업는 사태까지 발생합니다.
개발프로세스의 단계중 (요구분석->설계->코딩->테스트) 테스트단계에서 이런일이 대체적으로 벌어지지만, 근본문제는 이전단계에서 벌써 내재된 경우입니다.
요구분석단계에서 한줄로 요약되는 요구사항이 설계시에는 10으로 코딩시에는 100 또는 1000줄의 코딩으로 구현됩니다. 즉 요구분석단계에서 명확치 못한 정의가 설계단계를 거쳐 코딩시에는 원래의도와는 확연히 다른 결과물을 만들수 있습니다. 예를 들어 DB 다이어그램을 그리면서 엔티티와 필드를 정확히 정의하지 못하는 경우가 있습니다. 그런데 코딩이 한창일 때 필드 추가가 필요한 것을 요청받았다던지, 쿼리에 다른 방법이 없어서 마구잡이로 조인(JOIN)이나 서브쿼리(Sub Query)를 많이 사용해서 속도가 느려진다던지 하면 참 난감한 상황을 맞게 됩니다.
사실 이것은 개발자만의 문제가 아닙니다. 요구분석단계에서 현업사람들과 인터뷰를 할라치면 다른 업무 핑계로 잘 응대을 안해주는 경우가 있습니다. 또는 시스템에 대해서 잘 모르기 때문에 답변을 제대로 못하는 경우도 종종 있습니다. 그러다가 눈에 보이는 산출물을 가지고 “앞으로 이 시스템으로 업무를 해야 합니다”라면 이것 저것 요구사항과 수정사항이 봇물을 이룹니다.
그리고 요구분석과 설계를 등한시 여기는 풍토도 일조를 합니다.
또한, 개발이라고 하면 일단 UI 디자인부터 시작하는 다분히 개발자 적인 생각이 어울어져 만들어내는 경우입니다.
다른 나라에서는 어떻게 할까요? 특히 서양적 사고방식에서는 이런경우 고객의 추가요청사항을 잘 수렴해서 차기 프로젝트에서 반영하겠다고 업무의 선을 긋습니다.(이러면 한국에서는 힘들죠^^)
즉 분석설계시 제대로 대응하지 못한 것을 바로 잡는데는 1이라는 비용이 필요한데, 이것을 코딩으로 해결하려면 10이라는 비용이, 테스트시에 발견했다면 100이라는 비용이 필요하다는 것입니다. 그러므로 시간과 프로세스가 진행됨에 따라 열배, 백배의 추가비용이 소요됨을 말합니다.
