🚀 **이 문서는 보다 쉽게 이해할 수 있도록 정리되었습니다.**
개발 방법론은 여러가지가 있다. 개발을 어떻게 할 것인가의 문제인데, 과거 전통적인 방법론은 폭포수 방법론이였다. 폭포가 떨어지듯 순차적으로 개발을 진행하는 것이다.
기획 – 분석, 설계 – 개발 – 테스트
이 순서는 전통적인 개발의 순서이다. 어떤 것을 만들지 고민하고, 인터페이스라든가 기능을 설계하고, 해당하는 기능을 만들고 테스트하는 것이다. 이 방법이 많이 변하였고, 어떤 것이 맞다기 보다는 방법론의 변화에 대한 이해가 필요하다.
방법론은 정답이라는 개념이 아니라 좋은 것을 선택하는 문제이다. 건축이라면 아마도 설계도를 그리는 것이 공정상에 가장 중요할지 모른다. 설계가 잘못되었다면 아무리 건축물을 열심히 지어도 붕괴의 위험이나 잘못을 돌이킬 수 없기 때문이다. 시스템 개발에 대해서도 기획, 분석, 설계 단이 매우 중요하다. 그리고 이 공정에서 명확하고 치밀하게 만드는 것이 나중에 오류를 줄일 수 있고, 출시 이후 잠재된 문제를 제거할 수 있다. 초기 단계에서 오류를 잡아내는 것이 나중 단계에서 오류를 잡았을 때보다 비용을 줄일수 있다. 거꾸로 말해서 나중 단계로 갈수록 비용이 그것을 조치하는 비용이 크게 올라간다. 예를 들면 초기 설계를 잘못했는데 바로 잡지 못한다면 개발을 하여 만드는 중에 또는 테스트 중에 발견을 하게 되면 시간 소요가 길어지고, 심지어는 개발을 다시 해야 하는 부분이 생길 수 있다. 그리고 심지어는 출시 이후에 오류를 발견하게 되면 회수를 해야 하거나 다시 배포를 해야 하거나 다시 설치를 해야 하기때문에 이 비용은
고객의 신뢰도를 포함해서 심각해질 수가 있다. 그러기에 최소한 테스트 단계에서라도 문제에 대해서는 모두 조치를 해야 한다 .
절차적 방법론으로 개발을 하다가 방법론이 바뀐 이유는 소프트웨어는 수정이 가능하기 때문이라는 점이다. 건축물에 대한 구축 방법로는 예나 지금이나 절차를 엄밀하게 준수할 것이다. 설계를 하고 건축 중에 다시 설계를 해서 바꾼다든가 하는 점은 심간한 결함 외에 건축물의 디자인을 바꾼다든지 내부 설계를 바꾸는 것은 굉장히 어려운 일이 될 것이다. 그런데, 소프트웨어는 사실 비용이 많이 늘어나는 것은 맞지만,
변경이 불가능한 것은 아니다. 심지어는 출시 하루 전에도 기능을 넣거나 빼기도 한다. 변경이 장점이 될 수도 있지만, 큰 리스트를 줄 수 있어서 치명적인 단점이기도 한다.
대표적인 개발 방법이 스피럴이나 프로토타입 개발 방법론이다. 스피럴은 나선형인데, 이것은 여러번 폭포수를 반복하면서 개발의 완성도나 구축을 수행하는 관점이다. 스피럴을 통해서 한번에 완벽한 설계를 해야 하는 부담을 덜고, 보완을 할 수 있는 장점이 있다. 프로토 타입은 최근 앱이나 서비스 개발시 많이 이용되고 있는데, 요구사항을 듣고, 핵심적인 기능을 위주로 개발을 한다. 요구사항을 완벽하게 다 담을 필요가 없이 어떤 모양일지 어떤 느낌일지 핵심 기능 위주로 개발을 하고, 그 이후에 방향을 추가로 잡는 것이다. 프로토타입을 만들어봄으로써 어떤 느낌일지를 더 확실하게 알고, 추가 진행함으로써 완성 후에 다시 만드는 리스크를 줄일 수 있다. 물론 명확하게 개발 기간을 얼마다라고 잡기가 힘든면이 있다. 하지만 지금과 같이 요구사항이 빠르게 변화되고, 시장에 반응이 민감할 때에는 좋은 방법이 될 수 있다.
기본적인 기능만 탑재한 앱을 시장에 배포하고, 그리고 사용자들로 하여금 댓글이라든가 반응을 보고, 방향을 정하고, 추가적인 기능을 넣는 것이다. 이렇게 하면 빠르게 사용자들의 반응도 볼 수 있고, 초기 유저들을 통해서 발전시킬 방법을 모색할 수도 있다. 그리고 긴 기간동안 개발함으로써 대응이 늦어질 수 있는 단점도 해소할 수 있다. 그래서 운영을 하면서 기능을 추가하는 방법도 있기때문에 이러한 방법로는 최근 서비스를 하고 있는 곳에서 많이 사용되어지고 있다.
소프트웨어의 개발 방법론은 정해졌다기 보다는 적절한 방법을 찾는 것이다. 테일러링이라고 해서 기존 개발 방법론 중에서 필요한 것들 위주로 발췌 해서 사용할 수도 있다. 이렇듯 현재 개발하고 있는 것과 맞는 적절