신속한 애플리케이션 개발이란 무엇인가요?

소프트웨어 개발 라이프사이클(SDLC) 전반에 걸쳐 사용자가 프로토타입과 상호작용하도록 하면 출시 기간을 단축하여 더 높은 품질의 최종 제품을 생산할 수 있다는 이점이 있습니다.

RAD는 사용자 인터페이스(UI) 요구 사항이 개발을 주도해야 하는 특정 사용 사례에 특히 유용합니다. 아직 개발 중인 인터페이스도 체험할 수 있으므로, 사용자는 개발 프로세스 초기에 더 유용한 피드백을 제공할 수 있습니다. 이를 통해 소프트웨어가 프로덕션 단계로 푸시되었는데 사용자가 제품이 자신의 요구 사항을 충족하지 못한다는 사실을 발견했을 때 발생하는 치명적인 결과를 피할 수 있습니다.

다음은 IT의 선구자 James Martin이 정의한 RAD 반복의 일반적인 네 가지 단계입니다. RAD는 80년대 중반까지 거슬러 올라갑니다. IBM의 Martin이 1991년 그의 저서 Rapid Application Development에서 RAD를 특정 방법으로 공식화했지만, 이 기간 동안 다른 사람들도 다른 RAD 접근 방식을 동시에 구상했습니다. 여기에 소개된 네 가지 단계는 Martin이 구체적으로 정의한 것이지만, 소프트웨어 개발에 대한 일반적인 접근 방식으로서의 RAD는 Martin에게만 기인한다고 볼 수 없습니다.

계획 단계의 목표는 모든 요구 사항을 미리 정의하는 것이 아닙니다. 대신 팀은 해결해야 할 문제, 의도된 사용자, 사용자에게 가장 중요할 기능, 개발의 주요 제약 조건을 정의하려고 합니다. 이러한 제약에는 예산, 일정, 광범위한 기술 스택과의 통합 및 규정 준수 문제가 포함됩니다.

이 단계에서는 방대한 요구 사항 문서 대신 사용자 스토리, 와이어프레임, 기능 목록, 아키텍처 결정, 프로젝트 목표 및 대략적인 타임라인을 생성합니다. 이는 다른 접근 방식에 비해 최소한의 계획으로, 의도적인 것입니다. 계획이 의도적으로 가볍게 유지되므로, 개발을 빠르게 프로토타입으로 시작할 수 있습니다.

사용자는 프로토타입을 보기 전까지는 자신이 무엇을 원하는지 정확히 모르는 경우가 많으므로, RAD는 요구 사항의 변화를 가정합니다. 학습 내용은 개발 중에 실시간으로 수집되어 계획을 구체화하는 데 도움이 됩니다. 이 단계는 발판에 불과합니다.

팀은 설계 단계에서 모형, 클릭 가능한 프로토타입, 초기 UI 흐름 및 기능 데모를 빠르게 제작할 수 있습니다. 이는 아이디어를 검증하고 사용성 문제를 발견하는 데 사용됩니다. 이 과정 전반에 걸쳐 이해관계자들의 동의가 이루어집니다. 프로세스를 통해 무엇이 중요하고 무엇이 중요하지 않은지를 명확히 함으로써 추상적인 요구사항이 명확해집니다. 잘못된 가정은 조기에 노출되고 제품이 달성해야 하는 목표에 대한 통합된 이해가 점차 일관성을 갖게 됩니다.

프로토타입이 '단순한 전시용'으로 여겨지지 않도록 하는 것이 중요합니다. 프로토타입을 기반으로 제품을 개발하게 되며, 이는 많은 경우 최종 제품으로 바로 발전합니다.

이 단계는 핵심적인 개발 단계입니다. 프로토타입이 공유된 비전으로 안정화되면 개발팀은 소규모 반복과 빠른 릴리스 및 통합을 통해 신속하게 기능을 구축합니다. 개발자는 짧은 주기로 병렬로 작업하며 여러 분야에 걸쳐 긴밀하게 협업합니다. 팀은 다음 구성 요소로 이동하기 전에 제품의 한 부분을 완료하는 대신 동시에 작업합니다.

예를 들어, 보다 전통적인 접근 방식에서는 한 팀이 먼저 인증 도구를 구축한 다음 다른 팀에 전달하여 보고 도구를 구축했습니다. RAD에서는 이 작업이 동시에 진행되며, 두 팀이 긴밀하게 협력합니다.

속도를 높이기 위해 신속 애플리케이션 개발 도구는 모든 것을 처음부터 구축하는 대신 로우코드 및 노코드 솔루션, 자동화, 재사용 가능한 라이브러리, 컴포넌트 프레임워크 및 기타 사전 구축된 템플릿을 포함하는 경우가 많습니다. 이는 제공 속도를 높여주지만, 때로는 완벽한 아키텍처, 장기적인 유지 관리 가능성 및 문서화를 희생하기도 합니다.

신속한 애플리케이션 개발 모델은 테스트와 피드백을 최종 단계가 아닌 전체 워크플로의 연속적인 부분으로 취급합니다. 제품 관리자, QA 테스터, 비즈니스 이해관계자 및 최종 사용자가 테스트에 조기에 자주 참여합니다.

기존 접근 방식과 달리 모든 유형의 테스트(기능, 사용성, 워크플로, 성능)는 개발 이후가 아니라 개발 중에 이루어집니다. 이 반복적인 프로세스의 목표는 엄밀히 말하면 작동하기는 하지만 잘못된 문제를 해결하는 소프트웨어 제품을 생산하지 않도록 하는 것입니다. 지속적인 검증을 통해 개발자는 솔루션이 사용자 요구 사항과 비즈니스 요구 사항을 어떻게 충족하는지 더 잘 이해할 수 있습니다.

완성되고 테스트된 애플리케이션은 라이브 프로덕션 환경에 배포됩니다. 이는 보통 데이터 이전, 사용자 교육과 막판의 버그 해결을 포함합니다. 초기 단계에서 지속적인 테스트가 이루어지므로, 전환은 전통적인 방법론보다 보통 더 원활하고 빠르게 진행됩니다.

RAD는 종종 조직이 더 많은 제품을 적시에 예산 내에서 완성할 수 있도록 돕습니다. 하지만 이 접근법에는 단점도 있습니다.

아마도 가장 큰 과제는 사용자와 개발자 간의 많은 접점을 관리하는 것입니다. RAD는 다음 단계가 시작되기 전에 완료되는 순차적 단계로 정의되는 오래된 SDLC 접근 방식인 워터폴에 대한 대응으로 개발되었습니다. 워터폴 모델은 다리나 건물과 같은 물리적 기반 시설을 건설하는 전통적인 엔지니어링 방식에서 비롯되었습니다. 하지만 소프트웨어는 현실의 시스템과 다르게 작동합니다. 소프트웨어는 더 유연하며, 개발 과정에서 사용자 피드백에 따라 변경할 수 있습니다.

워터폴 방식에서는 일반적으로 사용자가 요구 사항을 정의한 후에는 개발자가 솔루션을 구축하는 동안 관여하지 않습니다. RAD 접근 방식은 전체 프로젝트에 걸쳐 사용자를 포함합니다. 즉, 조직은 이러한 이해관계자를 테스트하고 피드백할 수 있도록 해야 합니다. 좋은 피드백을 제공할 준비가 되어 있는 사람들은 많은 경우 업무 때문에 매우 바쁘지만, 이들의 참여가 없으면 프로젝트가 실패할 수 있습니다. 이로 인해 프로젝트 관리자의 스마트한 감독이 필요한 DevOps 문제가 발생합니다.

RAD 프로세스를 매우 유용하게 만드는 유연성은 종종 제어를 희생시킵니다. 워터폴은 명확한 단계가 있는 반면, RAD는 약간 혼란스러울 수 있습니다. 따라서 장애로 인해 사망이나 기타 재해가 발생할 수 있는 중요한 소프트웨어나 많은 구성 요소가 있는 대규모 시스템에는 적합하지 않을 수 있습니다.

범위 확장은 RAD의 일반적인 단점이기도 합니다. 사용자들은 계속해서 '있으면 좋은' 기능을 요청하며, 때문에 타임라인이 길어지고 예산이 늘어납니다. 사용자 요청은 핵심 기능의 우선순위를 정하는 방식으로 처리되는 것이 중요합니다.

RAD는 신속하며, 개발자들은 속도를 유지하기 위해 문서화 작업을 후순위로 미룹니다. 하지만 이러한 방식의 단점은 장기적인 유지 관리가 힘들어질 수 있으며, 시간이 지날수록 신규 개발자 확보가 더욱 어려워져서 위험이 발생할 수 있다는 것입니다.

신속한 프로토타이핑의 경우, 사용자 피드백에 대한 응답으로 너무 빠르게 움직이고 작은 점진적 조정을 너무 많이 수행하다 보니 엔지니어가 더 큰 아키텍처 문제를 간과하는 경우가 많습니다. 탄탄한 소프트웨어 엔지니어링 규율이 없다면 시스템 설계는 일관성이 없어지고, 통합은 복잡해지고, 모델은 드리프트하고, 전반적인 소프트웨어 프로젝트는 더 큰 시스템에 적용되는 방식과 분리될 수 있습니다. 대규모 시스템에는 일반적으로 신중한 아키텍처, 계획 및 공식 프로세스가 필요하기 때문에 RAD 모델에서는 확장성이 중요합니다.

속도에 중점을 둔 RAD에서는 팀이 의도치 않게 즉각적인 요청, 빠른 수정 및 단기적 집중으로 치우칠 수 있으며, 이는 시간이 지날수록 더욱 문제가 됩니다.

RAD와 애자일 개발은 모두 길고 엄격한 개발 주기를 거부하고 반복을 강조한다는 공통점이 있습니다. 그러나 RAD가 주로 애플리케이션 전송 속도를 최적화하는 반면, 애자일은 보통 적응적이고 지속 가능한 소프트웨어 개발을 위해 최적화합니다. 애자일은 예측 가능한 제공 케이던스와 스프린트에 중점을 둔 스크럼 프레임워크를 통해 장기적인 엔지니어링 상황을 위해 계획된 반복, 정의된 목표, 역할 및 프로세스를 통해 구조화되고 지속 가능한 제공을 강조합니다.