PE Notes · 사업관리
RAD 개발모델
단기 프로토타입과 타임박스로 제품을 올리는 RAD를 폭포수·애자일·MVP와 가르고, 맞을 때와 모듈·참여 조건을 정리합니다.
2년을 설계만 하다 시장이 바뀌면, 그 설계는 유산이지 제품이 아닙니다. (Rapid Application Development)는 반복 과 사용자 참여, 재사용 부품으로 수십 일 안에 애플리케이션을 올리는 모델입니다. 기간을 고정하고 기능을 깎는 타임박스가 심장입니다. 의 긴 한 방향과 반대로 섭니다.
네 단계와 타임박스
요구 계획은 경영·사용자·개발이 목표와 범위를 짧게 합의합니다. 사용자 설계는 공동 워크숍을 반복하며 화면과 흐름을 같이 그립니다. 구축은 프로토타입을 실제 모듈로 올리고 다시 보여 줍니다. 전환은 시험, 인수, 교육, 구시스템 컷오버입니다.
전형적인 상자는 60~90일입니다. 시간이 부족하면 일정을 늘리기보다 기능을 줄입니다. 시각 모델링과 코드 생성 도구, 이미 있는 컴포넌트, 네댓 명의 작은 팀이 전제입니다. 사용자 설계 워크숍이 비면 구축이 추측이 됩니다.
| 단계 | 하는 일 | 산출 감각 |
|---|---|---|
| 요구 계획 | 목표·범위 합의 | 짧은 범위 |
| 사용자 설계 | 워크숍·프로토타입 검토 | 합의된 화면·흐름 |
| 구축 | 반복 구현 | 동작 모듈 |
| 전환 | 시험·인수·컷오버 | 운영 이관 |
폭포수·애자일·MVP
폭포수는 요구가 닫힌 뒤 설계·구현·시험이 한 줄입니다. 문서가 두껍고 후반 변경이 비쌉니다. RAD는 그 한 줄을 짧은 상자에 넣고, 프로토타입으로 중간 합의를 만듭니다. 애자일은 스프린트를 끝없이 이어 가고, 기술 실천(의 시험·짝 프로그래밍)을 더 분명히 적습니다. RAD는 상자 하나(또는 소수)로 제품을 올리는 쪽에 가깝습니다.
는 시장 가설을 검증할 최소 가치 제품입니다. RAD의 프로토타입은 내부 합의와 빠른 구축이 목적이고, 출시해 학습하는 루프까지를 전제하지 않을 수 있습니다. 프로토타입을 그대로 운영에 올리면 부채가 됩니다. 상자 안에서 버린 껍데기와 남긴 모듈을 가릅니다.
| 비교축 | 폭포수 | RAD | 애자일 |
|---|---|---|---|
| 기간 | 장기 한 줄 | 고정 타임박스 | 짧은 반복 |
| 사용자 | 앞부분 | 전 과정 | 지속 |
| 프로토타입 | 거의 없음 | 핵심 | MVP·증분 |
| 문서 | 상세 | 최소 | 동작 소프트웨어 |
| 규모 | 대형·규제 | 중소, 모듈형 | 소·중 |
맞을 때
모듈로 나눌 수 있고, 처리 성능보다 속도가 먼저이며, 사용자가 워크숍에 실제로 앉을 수 있어야 합니다. 고가용 코어, 복잡한 인터페이스 묶음, 참여가 형식뿐인 공공 대형에는 잘 안 맞습니다. 도구와 숙련 비용이 숨은 전제입니다. 상자가 끝나면 기능이 잘리므로, 수락 기준을 상자 앞에 적습니다.
내부 업무 화면, 짧은 PoC를 넘어 쓸 수 있는 도구, 이커머스 핵심 흐름처럼 “먼저 돌리고 다듬을” 자리에 둡니다. SDLC 유형 중에서는 진화·프로토타입 계열입니다. 답에 “빠르다”만 쓰지 말고 타임박스·참여·재사용 세 조건을 같이 적습니다.
답안은 4단계, 타임박스, 폭포수 대비 표, MVP≠RAD 프로토타입, 적용 조건을 한 장에 닫습니다.