SaaS/No-Code 기반 시스템의 구현(Implementation) 프로젝트를 위한 방법론 (1)

◈ 들어가는 말

소프트웨어 또는 시스템 개발 프로젝트라고 하면 대부분 그 절차와 프로세스가 정의된 구조화된 방법론을 가지고 진행이 된다. 가장 일반적으로 사용되고 잘 알려진 방법론 하면 워터폴 (Waterfall) 모델을 생각하게 된다. ‘요구 사항 분석 → 디자인 설계 → 개발 → 테스트 → 배포 → 운영' 의 순서로 진행되는 방식은 대부분의 프로젝트에서 무리 없이 적용되고 사용되어 왔다. 하지만 개발 도구나 플랫폼의 다양화로 워터폴 모델을 사용하는 것이 비효율적인 경우가 생겨나기 시작하였으며 이를 보완하기 위한 다양한 방법론들이 대두되어 왔다. 

 

애자일(Agile), 칸반(Kanban), 린(Lean), 식스 시그마, PRINCE2 를 비롯한 여러가지 방법론들이 등장하였으며, 각 프로젝트의 성격 또는 목적에 따라 적절한 방법론이 사용되거나 나름대로의 변형을 거쳐 적용되고 있는 것이 현실이다. 그중에서 SaaS 기반 또는 노코드 기반의 플랫폼의 경우 애자일 모델/방법론이 적절하다고 보는 견해도 증가하고 있다.

 

그렇다면 노코드 기반의 SaaS 플랫폼의 경우는 어떤 방법론을 적용하는 것이 좋을까? 이 질문에 대한 답도 프로젝트에서 사용하는 개발 도구나 사용되는 플랫폼 및 목적에 따라 다를 수는 있다. 하지만, 그동안 수행해온 프로젝트에서 얻은 경험을 바탕으로 노코드 플랫폼을 사용하는 프로젝트를 위한 적절한 방법론에 대하여 생각해 보고자 한다.

 

◈ 워터폴(Waterfall) 모델

앞에서 언급 하였듯이 워터폴 모델은 가장 보편적 형태로 아래와 같은 순서로 진행이 된다.

 

[그림1. 일반적인 워터폴(Waterfall) 모델의 형태]

 

워터폴이라는 이름에서 알 수 있듯이 각 단계들은 이전 단계가 완료되고 나서 진행될 수 있으며, 이 단계를 거슬러 올라 가는 과정이 쉽지 않다. 즉, 테스트를 하면서 에러가 발행하는 경우 요구 분석 혹은 디자인/설계 단계에서 부터 다시 같은 과정을 반복해야 할 수도 있다. 따라서, 프로젝트의 초기, 즉 요구 분석 단계와 디자인/설계 단계에서의 과정이 매우 중요하다.

 

하지만, 현실의 상황으로 돌아 보면, 요구 분석 단계에서 사용자가 원하는 것을 100% 완벽하게 기술하는 것은 불가능하기 때문에 디자인/설계 단계에 사용자가 참여하지 않는 이상, 테스트 단계에서 보게 되는 결과물은 사용자가 애초에 기대한 것과는 다를 확률이 높다. 사용자의 요구 사항에 대한 정확하지 않은 분석으로 인해 테스트 단계에서 역전하는 경우도 있지만, 비지니스의 상황이 변하여 다시 디자인/설계를 해야 하는 경우도 있다. 특히 프로젝트 기간이 길 경우 요구 사항을 도출하던 시점의 환경과 상황이 달라지는 경우 재개발은 불가피 하게 된다.

 

전통적인 개발 프로젝트에서 이러한 현상이 발생하게 되는 근본적인 원인을 생각해보면, 가장 큰 이유는 사용자가 요구 사항을 개발자에게 설명해 준 후 몇 개월이 지난 시점에서 개발 완료 단계나 테스트 단계에서 그 결과물을 처음 볼 수 있기 때문인 경우가 대부분이다. 

 

◈ 애자일(Agile) 모델

이러한 문제에 대한 대응책으로 흔히 애자일 모델을 생각한다. 전체 프로젝트를 작은 단위로 쪼개서 각각의 모듈을 개발하는데, 매일 또는 짧은 주기로 스크럼 미팅을 진행하여 발생하는 변경 요구(Backlog)를 빠르게 대처해 나감으로서 전체적인 개발 기간도 단축할 수 있을 뿐만 아니라, 개발 과정에도 사용자들을 주기적으로 참가시키고 피드백을 받음으로서 워터폴 모델에서 발생하던 프로젝트 단계를 역전하여 다시 반복하는 오류를 상당수 제거할 수 있다.

 

대부분의 SaaS 기반의 노코드 플랫폼은 설정하는 방식으로 사용자 인터페이스를 구성하므로 사용자의 요구 사항들이 정리가 되는 시점에서 사용자에게 그 결과를 공유하여 피드백을 받는 것이 가능하므로 앞 단락에서 설명한 애자일 어프로치를 적용하기가 쉽다. 또한 이로 인한 부수적인 효과는 사용자들로 하여금 새로운 시스템으로 전환(Transition) 과정에서도 사용자들의 거부감이나 적응 시간(Learning Curve)을 줄이는 것이 가능하다.

 

하지만 이러한 애자일 모델도 만병통치약은 될 수 없다. 특별히, 업무용 애플리케이션을 개발하는 케이스를 한정하는 것으로 가정할 때, 애자일 모델을 따르기 위한 작은 단위로 쪼개는 것이 쉽지 않으며, 설령 그렇게 쪼갠다 할지라도, 프로젝트 예산에 비추어 볼 때 단위별 리소스를 배정하는 것이 수월하지 않다.

 

그렇다면 해결책은 무엇일까? 그에 대한 해답의 하나로서 다음 글에서 제시하고자 한다,