반복적 점진적 개발

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 라이프사이클
- 2.1. 구현 및 분석 가이드라인
3. 단계
4. 역사
5. 폭포수 모델과의 비교
6. 하드웨어 및 임베디드 시스템에서의 활용
7. 분석과 측정
8. 한국 정보
참조

1. 개요

반복적 점진적 개발은 소프트웨어 시스템을 점진적으로 개발하고, 과거 개발 경험을 활용하여 사용할 수 있는 시스템을 단계적으로 릴리스하는 소프트웨어 개발 방법론이다. 초기에는 단순한 기능의 부분 집합부터 개발을 시작하여 반복마다 설계 수정과 기능 추가를 통해 최종 시스템을 구현한다. 초기 단계에서 기본 시스템을 구축하고, 반복 단계를 통해 필요한 작업을 수행하며, 사용자 피드백을 반영하여 시스템을 개선한다. 반복적 개발은 측정과 분석을 통해 효율성과 품질을 향상시키며, 폭포수 모델에 비해 사용자 참여, 유연성, 시간 효율성 측면에서 장점을 가진다. 이 방법론은 소프트웨어뿐만 아니라 하드웨어 및 임베디드 시스템 개발에도 활용되며, 특히 우주 발사 산업에서 혁신을 이끌고 있다.

더 읽어볼만한 페이지

소프트웨어 개발 철학 - 애자일 소프트웨어 개발
애자일 소프트웨어 개발은 1990년대에 등장하여 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 핵심 가치로 삼고 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구하는 소프트웨어 개발 방법론이다.
소프트웨어 개발 철학 - 유닉스 철학
유닉스 철학은 단순성, 모듈성, 재사용성을 중시하며, 한 가지 일을 잘하는 프로그램, 협력적인 프로그램, 텍스트 스트림 처리 프로그램을 지향하는 소프트웨어 설계 원칙으로, 현대 운영체제 및 소프트웨어 설계에 영향을 주지만 비판도 존재한다.
소프트웨어 프로젝트 관리 - 소프트웨어 개발
소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
소프트웨어 프로젝트 관리 - 애자일 소프트웨어 개발
애자일 소프트웨어 개발은 1990년대에 등장하여 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 핵심 가치로 삼고 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구하는 소프트웨어 개발 방법론이다.

반복적 점진적 개발
개발 방법론
정의	소프트웨어 개발에 사용되는 반복적인 소프트웨어 개발 모델
접근 방식	전체 소프트웨어를 한 번에 개발하는 대신 여러 빌드로 나누어 개발하는 방식
개발 주기	요구사항 분석 설계 구현 테스트 평가
특징	각 빌드는 이전 빌드에 기능을 점진적으로 추가하며, 최종 빌드가 제품의 초기 기능들을 모두 포함함
역사
초기 사례	1957년, IBM Service Bureau Corporation에서 Bernie Dimsdale의 지휘 하에 시작됨
Herb Jacobs	모토로라(Motorola)를 위한 대규모 시뮬레이션 개발에 참여
크레이그 라만	2003년, iterative and incremental development에 대한 간략한 역사 논문을 발표
장점
위험 관리	개발 초기 단계에서 위험을 식별하고 해결 가능
고객 피드백	각 반복 주기마다 고객 피드백을 반영하여 제품 개선 가능
유연성	요구사항 변경에 유연하게 대응 가능
조기 제품 출시	핵심 기능 먼저 개발하여 조기 제품 출시 가능
단점
복잡성 증가	반복적인 개발 과정에서 설계 및 코드 복잡성 증가 가능
관리 어려움	전체 개발 과정을 관리하기 어려울 수 있음
추가 비용	잦은 변경으로 인해 추가 비용 발생 가능
적용 분야
요구사항 변경이 잦은 프로젝트	프로젝트 진행 중 요구사항이 자주 변경되는 경우
대규모 프로젝트	복잡하고 규모가 큰 프로젝트
위험도가 높은 프로젝트	실패 위험이 높은 프로젝트
관련 방법론

2. 라이프사이클

소프트웨어 시스템을 점진적으로 개발해나가며, 소프트웨어 개발자가 과거 개발에서 얻은 교훈을 활용하여, 사용할 수 있는 시스템을 단계적으로 릴리스하는 것이 반복적 개발의 기본 개념이다. 개발자는 개발과 실제 시스템 사용을 통해 배우며, 요구 사항의 단순한 부분 집합부터 개발을 시작하여 점차 개선을 더해가며 최종적으로 완전한 시스템을 구현한다. 반복마다 설계가 수정되고 새로운 기능이 추가된다.

절차는 초기 단계와 반복 단계로 구성되며, 프로젝트 제어 목록이 따른다. 초기 단계에서는 기본 시스템을 만들고, 사용자가 사용해볼 수 있는 제품을 구현하는 것을 목표로 한다. 문제의 본질을 파악하고 간단하게 구현 가능한 해결책을 찾아 제공한다. 이를 위해 프로젝트 제어 목록을 작성하고, 필요한 작업을 모두 목록화한다. 여기에는 새로운 기능 구현이나 기존 해결책의 재설계 등이 포함된다. 제어 목록은 분석 단계의 결과를 받아 지속적으로 갱신된다.

반복 단계에서는 프로젝트 제어 목록이나 시스템 현황 분석을 통해 재설계나 구현 등 필요한 작업을 추출하여 수행한다. 반복마다의 작업량이나 복잡성은 가능한 작게 억제하고, 영향이 확산되지 않도록 모듈화도 고려하여 구현할 기능을 선택한다. 이때 코드 자체가 시스템의 소프트웨어 문서의 주요 원천이 되기도 한다. 각 반복에서의 분석은 주로 사용자 피드백에 기반하여 이루어진다. 프로그램 분석 도구도 활용 가능하며, 구조, 모듈성, 사용자 편의성, 효율, 목표 달성률 등을 분석한다. 분석 결과에 따라 프로젝트 제어 목록이 갱신된다.

구현과 분석의 가이드라인은 다음과 같다.

어떤 변경으로 인해 설계/코딩/테스트에서 문제가 발생한 경우, 재설계나 재코딩이 필요하다.
수정은 일부 독립적인 모듈 그룹에 쉽게 적용 가능해야 한다. 그렇지 않은 경우, 재설계가 필요하다.
테이블의 수정은 특히 쉽게 실행할 수 있도록 한다. 테이블 수정이 쉽지 않은 경우, 재설계가 필요하다.
수정은 반복을 거듭할수록 쉬워져야 한다. 그렇지 않은 경우, 설계 흐름에 근본적인 문제가 있으며, 패치의 증식으로 이어진다.
패치는 1, 2회의 반복 동안만 존재하는 것이 보통이다. 패치는 구현에서 재설계의 필요성이 생겼을 때 응급 처치로 사용된다.
현황 구현을 빈번히 분석함으로써 프로젝트의 목표 달성률을 측정한다.
프로그램을 분석하기 위해 프로그램 분석 도구를 가능한 한 이용한다.
현황 구현의 문제점을 명확히 하기 위해 사용자의 반응은 반드시 필요하며 분석해야 한다.

2. 1. 구현 및 분석 가이드라인

소프트웨어 구현 및 분석을 이끄는 지침은 다음과 같다.

수정 사항을 설계, 코딩 및 테스트하는 데 어려움이 있다면 재설계 또는 재코딩의 필요성을 알려야 한다.
수정 사항은 격리되고 찾기 쉬운 모듈에 쉽게 맞아야 한다. 그렇지 않은 경우, 일부 재설계가 필요할 수 있다.
테이블 수정은 특히 쉽게 이루어져야 한다. 테이블 수정이 빠르고 쉽게 이루어지지 않으면 재설계가 필요하다.
반복이 진행될수록 수정이 더 쉬워져야 한다. 그렇지 않다면 설계 결함이나 패치의 확산과 같은 근본적인 문제가 있는 것이다.
일반적으로 패치는 한두 번의 반복 동안만 존재하도록 허용해야 한다. 구현 단계에서 재설계를 피하기 위해 패치가 필요할 수 있다.
기존 구현을 자주 분석하여 프로젝트 목표에 얼마나 부합하는지 확인해야 한다.
부분 구현의 분석을 돕기 위해 가능한 경우 프로그램 분석 기능을 사용해야 한다.
현재 구현의 결함을 나타내는 지표에 대해 사용자 반응을 요청하고 분석해야 한다.

분석과 측정을 통해 개선의 지침을 얻는다는 점이, 반복적 개발과 애자일 소프트웨어 개발의 큰 차이점이다. 이를 통해, 공정의 효율을 명확히 하고, 제품의 품질을 향상시킨다. 또한, 개발팀은 분석과 측정을 통해 해당 프로젝트를 배우고, 환경에 적응해나간다. 물론, 유사한 분석과 측정을 애자일 방식에 도입하는 것도 가능하다.

실제로, 반복적 개발에서는 측정 활용에 이점이 있다. 일반적으로 측정을 하더라도, 비교 대상이 없으면 그 결과를 평가할 수 없지만, 반복적 개발에서는 반복마다의 측정 결과를 비교하는 것이 가능하며, 이를 통해 목표 달성 상황이 명확해진다. 예를 들어, 특정 시점의 제품에 대해 각종 측정을 실시하면, 해당 제품의 크기/복잡성/결합도/응집도 등이 개선되었는지 악화되었는지를 알 수 있다.

이 모델을 사용하여, 다양한 소프트웨어가 개발되어 왔다. 처음에는 단순히 작동만 하는 제품이지만, 릴리스를 거치면서 기능이 추가되고, 버그가 줄어든다. 이러한 모델의 전형적인 예시로, 야후! 메신저(Yahoo! Messenger), Azureus, 각종 보안 소프트웨어 및 P2P 소프트웨어가 있다.

3. 단계

반복적 점진적 개발은 시스템 기능을 증분(부분)으로 나누어 개발한다. 각 증분에서 기능의 일부는 다학제 작업을 통해 요구 사항부터 소프트웨어 배포까지 제공된다. 통합 프로세스는 증분/반복을 착수, 상세화, 구축, 전환 단계로 그룹화한다.

착수 단계에서는 프로젝트 범위, 요구 사항(기능적 및 비기능적) 및 위험을 높은 수준에서 식별하지만, 작업을 추정할 수 있을 정도로 충분한 세부 정보를 포함한다.
상세화 단계에서는 주요 위험을 완화하고 비기능적 요구 사항을 충족하는 작동하는 아키텍처를 제공한다.
구축 단계에서는 기능 요구 사항의 분석, 설계, 구현 및 테스트를 통해 생성된 프로덕션 준비 코드로 아키텍처를 점진적으로 채운다.
전환 단계에서는 시스템을 프로덕션 운영 환경으로 제공한다.

각 단계는 하나 이상의 반복으로 나눌 수 있으며, 이는 일반적으로 기능 단위가 아닌 시간 단위로 제한된다. 아키텍트와 분석가는 개발자 및 테스터보다 한 번의 반복 앞서 작업하여 작업 산출물 백로그를 가득 채운다.

4. 역사

크레이그 라만과 빅터 바실리의 논문 "반복적 점진적 개발: 간략한 역사"에서 초기 사용 사례가 많이 제공되었으며,^[4] 그중 가장 초기의 사례 중 하나는 1960년대 NASA의 머큐리 계획이다.

머큐리 계획의 일부 엔지니어들은 이후 IBM 내 새로운 부서를 설립했는데, 그곳에서 NASA의 우주 왕복선 소프트웨어의 핵심인 기본 항공 전자 소프트웨어 시스템은 1977년부터 1980년까지 구축되었으며 주요 IID 성공 사례가 되었다. 이들은 31개월 동안 17번의 반복을 거치면서 IID를 적용했으며, 반복당 평균 8주 정도 소요되었다. 그들이 폭포수 생명 주기를 피하려 한 동기는 왕복선 프로그램의 요구 사항이 소프트웨어 개발 과정에서 변경되었기 때문이다.^[4]

미국 국방부와 같은 일부 조직은 반복적 방법론을 선호하며, MIL-STD-498은 "진화적 획득과 IID를 명확히 권장"하는 것으로 시작한다.

2000년에 발표된 국방부 지침 5000.2는 IID에 대한 명확한 선호를 다음과 같이 명시했다.

전체 기능을 달성하기 위한 방법에는 진화적 접근 방식과 단일 단계[폭포수] 접근 방식, 두 가지가 있다. 진화적 접근 방식을 선호한다. … [이] 접근 방식에서 사용자에게 제공되는 최종 기능은 두 개 이상의 블록으로 나뉘며 기능의 증분이 증가한다... 소프트웨어 개발은 초기 개발에서 얻은 학습을 기반으로 지속적으로 확장되는 소프트웨어 버전을 만드는 반복적 나선형 개발 프로세스를 따라야 한다. 단계별로 수행할 수도 있다.

DoDI 5000.02의 최근 개정에서는 더 이상 "나선형 개발"을 언급하지 않지만, 소프트웨어 집약적 개발/조달 프로그램의 기본으로 일반적인 접근 방식을 옹호한다.^[5] 또한 미국 국제 개발처(USAID)는 국제 개발 프로젝트를 설계, 모니터링, 평가, 학습 및 적응하기 위해 반복적이고 점진적인 개발 접근 방식을 사용하며, 협업, 학습 및 적응 전략을 통합하여 프로그래밍을 반복하고 적응하는 데 중점을 둔 프로젝트 관리 접근 방식을 사용한다.^[6]

5. 폭포수 모델과의 비교

소프트웨어 개발 프로젝트 실패의 주요 원인은 모델 선택에 있으며, 따라서 신중하게 결정해야 한다.^[7]

예를 들어, 폭포수 모델 패러다임은 다음 단계로 넘어가기 전에 각 분야의 프로젝트 전체 작업 산출물을 한 단계에서 완료한다. 비즈니스 가치는 프로젝트가 완전히 끝날 때 한 번에 전달되며, 반복적 접근 방식에서는 백트래킹이 가능하다.

'''사용자 참여''': 폭포수 모델에서 사용자는 요구 사항 및 인수 테스트의 두 단계, 그리고 사용자 교육 자료 생성에 참여한다. 반면, 점진적 모델에서는 고객이 모든 단계에 참여한다.
'''변동성''': 소프트웨어는 생명 주기의 빌드 단계가 완료된 후에 사용자에게 전달되어 사용자 인수 테스트를 거친다. 반면에, 각 증분은 사용자에게 전달되며 사용자의 승인을 받은 후 개발자는 다음 모듈로 이동할 수 있다.
'''인적 자원''': 점진적 모델에서는 폭포수 모델에 비해 더 적은 수의 인력이 필요할 수 있다.
'''시간 제한''': 운영 제품은 몇 달 후에 전달되는 반면, 점진적 모델에서는 몇 주 안에 사용자에게 제품이 제공된다.
'''프로젝트 규모''': 폭포수 모델은 소규모 프로젝트에 적합하지 않지만, 점진적 모델은 소규모 및 대규모 프로젝트에 적합하다.

6. 하드웨어 및 임베디드 시스템에서의 활용

''반복적 점진적 개발''이라는 용어는 소프트웨어 업계에서 시작되었지만, 많은 하드웨어 및 임베디드 소프트웨어 개발 노력에서 반복적이고 점진적인 기술을 사용하고 있다.

이는 여러 산업에서 볼 수 있다. 최근 이러한 사고방식의 변화에 상당한 영향을 받은 한 분야는 우주 발사 산업으로, 새로운 경쟁력이 발생하여 민간 기업이 우주 발사를 추진하면서 더욱 빠르고 광범위한 기술 혁신을 가져왔다. 스페이스X(SpaceX)^[8] 및 로켓 랩(Rocket Lab)^[9]과 같은 이러한 기업은 지난 10년 동안 상업 궤도 발사 서비스를 제공하고 있으며, 이는 10년 전까지만 해도 6개 국가에서만 가능했다.^[10] 2016년부터 존재해온 이전에 비행했던 (재사용 가능한) 부스터 단을 사용하여 우주로 비행할 수 있는 능력을 포함하여 기술 개발 접근 방식, 가격 및 서비스 제공의 새로운 혁신은 우주 접근 비용을 더욱 감소시키고 있다.^[11]^[8]

스페이스X는 우주 산업에 반복적인 설계 방식을 도입하기 위한 노력을 명확히 밝혔으며, 우주선, 발사체, 전자 장치 및 항공 전자 장치, 그리고 운영 비행 하드웨어 작업에 이 기술을 사용한다.^[12]

업계가 변화하기 시작하면서 다른 발사 경쟁업체들도 정부 기관과의 장기 개발 관행을 바꾸기 시작했다. 예를 들어, 미국의 대규모 발사 서비스 제공업체인 유나이티드 런치 얼라이언스(ULA)는 2015년에 발사 사업을 재구성하기 위한 10년간의 프로젝트를 시작하여 두 대의 발사 차량을 하나의 발사 차량으로 줄였다. 이후 발사체를 사용하는 방식으로, 향후 10년 동안 부분 재사용이 가능하고 훨씬 저렴한 발사 시스템을 구축하기 위해 반복적이고 점진적인 접근 방식을 사용했다.^[13]

7. 분석과 측정

분석과 측정을 통해 개선의 지침을 얻는다는 점이, 반복적 개발과 애자일 소프트웨어 개발의 큰 차이점이다. 이를 통해, 공정의 효율을 명확히 하고, 제품의 품질을 향상시킨다. 또한, 개발팀은 분석과 측정을 통해 해당 프로젝트를 배우고, 환경에 적응해나간다. 물론, 유사한 분석과 측정을 애자일 방식에 도입하는 것도 가능하다.

실제로, 반복적 개발에서는 측정 활용에 이점이 있다. 일반적으로 측정을 하더라도, 비교 대상이 없으면 그 결과를 평가할 수 없지만, 반복적 개발에서는 반복마다의 측정 결과를 비교하는 것이 가능하며, 이를 통해 목표 달성 상황이 명확해진다. 예를 들어, 특정 시점의 제품에 대해 각종 측정을 실시하면, 해당 제품의 크기/복잡성/결합도/응집도 등이 개선되었는지 악화되었는지를 알 수 있다.

이 모델을 사용하여, 다양한 소프트웨어가 개발되어 왔다. 처음에는 단순히 작동만 하는 제품이지만, 릴리스를 거치면서 기능이 추가되고, 버그가 줄어든다. 이러한 모델의 전형적인 예시로, 야후! 메신저(Yahoo! Messenger), Azureus, 각종 보안 소프트웨어 및 P2P 소프트웨어가 있다.

8. 한국 정보

참조

_[1] 간행물 Iterative and Incremental Development: A Brief History http://www.craiglarm[...] 2003-06
_[2] 문서 DOD-STD-2167 Defense Systems Software Development http://www.everyspec[...] 1985-06-04
_[3] 웹사이트 Software Development Models: Iterative and Incremental Development https://technologyco[...] 2014-01-21
_[4] 간행물 Iterative and Incremental Development: A Brief History http://doi.ieeecompu[...] 2003-06
_[5] 웹사이트 Operation of the Defense Acquisition System http://www.esd.whs.m[...] Under Secretary of Defense for Acquisition, Technology, and Logistics 2017-02-02
_[6] 웹인용 ADS Chapter 201 Program Cycle Operational Policy https://www.usaid.go[...] USAID 2017-04-19
_[7] 웹사이트 Incremental vs Waterfall Model in Software Development https://cyfrania.com[...] 2024-02-29
_[8] 뉴스 The Rocketeer https://foreignpolic[...] 2013-12-09
_[9] 뉴스 Exclusive Inside Look at Rocket Lab's Previously-secret new Mega Factory! https://everydayastr[...] 2018-10-11
_[10] 뉴스 Sweet Success at Last for Falcon 1 Rocket http://www.spaceflig[...] 2008-09-28
_[11] 뉴스 "Russia's Proton rocket, which predates Apollo, will finally stop flying Technical problems, rise of SpaceX are contributing factors." https://arstechnica.[...] 2018-06-25
_[12] 뉴스 What it took for Elon Musk's SpaceX to disrupt Boeing, leapfrog NASA, and become a serious space company https://qz.com/28161[...] 2014-10-21
_[13] 뉴스 Evolution of a Plan : ULA Execs Spell Out Logic Behind Vulcan Design Choices http://spacenews.com[...] 2015-04-24
_[14] 저널 Iterative and Incremental Development: A Brief History http://www.craiglarm[...] 2003-06

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com