본문으로 이동

소프트웨어 배포 생명 주기

한울위키, 우리 모두의 백과사전.

소프트웨어 생명 주기[1] 또는 소프트웨어 배포 생명 주기(영어: software release life cycle)는 운영체제와 같은 소프트웨어 제품을 개발, 테스트 및 배포하는 과정이다. 이는 일반적으로 최종 버전인 "골드(gold)"가 대중에게 공개되기 전까지 프리알파, 알파, 베타, 릴리스 후보(RC)와 같은 몇 가지 단계로 구성된다.

파일:Software dev2.svg
기본적인 소프트웨어 배포 생명 주기의 예시

프리알파(Pre-alpha)는 소프트웨어가 여전히 설계 및 구축 중인 개발 초기 단계를 의미한다. 알파 테스트(Alpha testing)는 공식 테스트의 첫 번째 단계로, 화이트박스 기법을 사용하여 내부적으로 소프트웨어를 테스트한다. 베타 테스트(Beta testing)는 그 다음 단계로, 일반적으로 소프트웨어를 개발한 조직 외부의 더 큰 사용자 그룹이 소프트웨어를 테스트한다. 베타 단계는 사용자에게 미치는 영향을 줄이는 데 중점을 두며 사용성 테스트를 포함할 수 있다.

베타 테스트가 끝나면 소프트웨어는 최종 버전이 출시되기 전에 하나 이상의 릴리스 후보 단계를 거쳐 더욱 개선되고 테스트될 수 있다.

일부 소프트웨어, 특히 인터넷 및 기술 산업의 소프트웨어는 "영구적 베타(perpetual beta)" 상태로 출시되기도 한다. 이는 소프트웨어가 지속적으로 업데이트되고 개선되며 결코 완전히 완성된 제품으로 간주되지 않음을 의미한다. 이러한 접근 방식은 보다 민첩한 개발 프로세스를 가능하게 하며, 개발 주기 초기부터 사용자가 소프트웨어를 출시하고 사용할 수 있도록 한다.

개발 단계

프리알파

프리알파(Pre-alpha)는 공식 테스트 이전의 소프트웨어 프로젝트 중에 수행되는 모든 활동을 의미한다. 이러한 활동에는 요구사항 분석, 소프트웨어 설계, 소프트웨어 개발 및 유닛 테스트가 포함될 수 있다. 일반적인 오픈 소스 소프트웨어 개발에는 여러 유형의 프리알파 버전이 있다. 마일스톤 버전은 특정 기능 집합을 포함하며 해당 기능이 완료되는 즉시 릴리스된다.

알파

배포 생명 주기의 알파 단계는 소프트웨어 테스트의 첫 번째 단계이다(알파는 그리스 문자의 첫 번째 글자로, 숫자 1로 사용된다). 이 단계에서 개발자는 일반적으로 화이트박스 기법을 사용하여 소프트웨어를 테스트한다. 그런 다음 다른 테스트 팀이 블랙박스 또는 그레이박스 기법을 사용하여 추가 검증을 수행한다. 조직 내부에서 블랙박스 테스트로 넘어가는 것을 알파 릴리스라고 한다.[2][3]

알파 소프트웨어는 고객에게 출시되기 전에 개발자가 철저하게 테스트하지 않는다. 알파 소프트웨어에는 심각한 오류가 포함될 수 있으며, 그로 인한 불안정성으로 인해 충돌이나 데이터 손실이 발생할 수 있다.[4] 알파 소프트웨어에는 최종 버전에 계획된 모든 기능이 포함되어 있지 않을 수 있다.[5] 일반적으로 사유 소프트웨어의 경우 알파 소프트웨어의 외부 이용은 흔하지 않지만, 자유 소프트웨어 및 오픈 소스 소프트웨어는 공개적으로 사용 가능한 알파 버전을 제공하는 경우가 많다. 알파 단계는 일반적으로 더 이상 소프트웨어에 기능이 추가되지 않음을 나타내는 기능 동결(feature freeze)과 함께 종료된다. 이때 소프트웨어는 기능 완료(feature-complete) 상태라고 한다. 베타 테스트는 공급업체 측의 인수 검사(알파 테스트) 이후, 제품으로서 소프트웨어가 일반 릴리스되기 직전에 수행된다.[6]

기능 완료

기능 완료(Feature-complete, FC) 버전의 소프트웨어는 계획된 주요 기능이 모두 구현되었지만, 버그, 성능 또는 안정성 문제로 인해 아직 최종 버전이 아닌 상태이다.[7] 이는 소프트웨어 개발 과정의 알파 테스트 끝 무렵에 발생한다.

일반적으로 기능 완료 소프트웨어는 릴리스 후보 및 최종 골드 상태로 이동하기 전에 베타 테스트 및 버그 수정, 성능 또는 안정성 향상 과정을 거쳐야 한다.

베타

 소프트웨어 테스트 § 베타 테스트 문서를 참고하십시오.

그리스 문자의 두 번째 글자의 이름을 딴 베타(Beta)는 알파 이후의 소프트웨어 개발 단계이다. 베타 단계는 일반적으로 소프트웨어가 기능 완료 상태이지만 알려지거나 알려지지 않은 버그가 여러 개 포함되어 있을 가능성이 높을 때 시작된다.[8] 베타 단계의 소프트웨어는 일반적으로 완성된 소프트웨어보다 버그가 훨씬 더 많고 속도나 성능 문제가 있으며, 여전히 충돌이나 데이터 손실을 유발할 수 있다. 베타 테스트의 초점은 사용자에게 미치는 영향을 줄이는 것이며, 종종 사용성 테스트를 결합한다. 사용자에게 베타 버전을 전달하는 과정을 베타 릴리스라고 하며, 일반적으로 개발 조직 외부에서 소프트웨어를 사용할 수 있는 첫 번째 시기이다. 소프트웨어 베타 릴리스는 공개 여부에 따라 공개 또는 비공개로 나뉠 수 있다. 베타 버전 소프트웨어는 종종 조직 내부나 잠재 고객을 위한 시연 및 미리 보기에 유용하다. 일부 개발자는 이 단계를 프리뷰, 프리뷰 릴리스, 프로토타입, 테크니컬 프리뷰 또는 기술 프리뷰(TP),[9] 또는 앞서 해보기(early access)라고 부르기도 한다.

베타 테스터는 베타 소프트웨어의 문제를 적극적으로 보고하는 사람들이다. 이들은 일반적으로 소프트웨어를 개발하는 조직의 고객이거나 잠재 고객의 대리인이다. 베타 테스터는 무상으로 서비스를 제공하는 경향이 있지만, 테스트하는 제품의 버전, 출시 버전의 할인 또는 기타 혜택을 받는 경우가 많다.[10][11]

영구적 베타

일부 소프트웨어는 최종 "안정" 릴리스를 확정하지 않고 지속적으로 새로운 기능이 추가되는 이른바 "영구적 베타(perpetual beta)" 상태로 유지된다. 인터넷이 소프트웨어의 빠르고 저렴한 배포를 촉진함에 따라, 기업들은 베타라는 용어의 사용에 대해 더 느슨한 접근 방식을 취하기 시작했다.[12]

공개 및 비공개 베타

개발자는 비공개 베타(closed beta) 또는 공개 베타(open beta)를 릴리스할 수 있다. 비공개 베타 버전은 초대를 통해 사용자 테스트를 위한 제한된 개인 그룹에게 릴리스되는 반면, 공개 베타 테스터는 더 큰 그룹이거나 관심이 있는 사람 누구나 참여할 수 있다. 프라이빗 베타(Private beta)는 가치를 제공할 수 있지만 확장성 문제, 문서 부족 또는 여전히 중요한 기능 누락으로 인해 모든 사람이 사용할 준비가 되지 않은 소프트웨어에 적합할 수 있다. 테스터는 발견한 버그를 보고하고 때로는 최종 버전에 있어야 한다고 생각하는 추가 기능을 제안하기도 한다.

공개 베타는 잠재적 소비자에게 제품을 시연하는 목적과 광범위한 사용자 기반에서 테스트하여 소규모 테스트 팀이 찾지 못할 수 있는 불분명한 오류를 밝혀낼 가능성을 높이는 이중 목적을 수행한다.

릴리스 후보

파일:Microsoft windows 2000 server rc2 media.jpg
마이크로소프트 윈도우 2000 서버 릴리스 후보 2 미디어

감마 테스트(gamma testing) 또는 "실버(going silver)"라고도 불리는 릴리스 후보(release candidate, RC)는 중대한 버그가 나타나지 않는 한 안정적인 제품으로 출시될 가능성이 있는 베타 버전이다. 제품 안정화의 이 단계에서는 모든 제품 기능이 설계, 코딩 및 하나 이상의 베타 주기를 통해 테스트되었으며, 알려진 치명적인 버그가 없는 상태이다. 개발 팀이 이 릴리스에 완전히 새로운 소스 코드가 추가되지 않을 것이라고 동의하면 릴리스를 코드 완료(code complete)라고 부른다. 결함을 수정하기 위한 소스 코드 변경, 문서 및 데이터 파일의 변경, 테스트 케이스나 유틸리티를 위한 주변부 코드 변경은 여전히 있을 수 있다.

안정판

생산 릴리스(production release)라고도 불리는 안정판(stable release)은 모든 검증 및 테스트 단계를 통과한 마지막 릴리스 후보(RC)이다. 알려진 남아 있는 버그는 허용 가능한 것으로 간주된다. 이 릴리스는 실제 운영 환경으로 전개된다.

일부 소프트웨어 제품(예: 데비안과 같은 리눅스 배포판)은 이미 검증되고 테스트된 정식 릴리스를 기반으로 하며 보안 업데이트만 받는 장기 지원 버전(LTS) 릴리스를 별도로 두기도 한다.

릴리스

일단 릴리스되면 소프트웨어는 일반적으로 "안정판(stable release)"으로 알려진다. 공식 명칭은 실제 미디어, 온라인 릴리스 또는 웹 애플리케이션과 같은 릴리스 방식에 따라 달라지는 경우가 많다.[13]

일반적으로 출시된 소프트웨어에는 공식 버전 이름이나 버전 번호가 할당된다. (출시 전 소프트웨어에는 별도의 내부 프로젝트 코드명이나 내부 버전 번호가 있을 수도 있고 없을 수도 있다.)

제조 공정 인도 (RTM)

파일:Satya Nadella Gears of War 4 Gold Master.jpg
기어스 오브 워 4의 골드 마스터 디스크를 들고 있는 마이크로소프트의 사티아 나델라

"제조 공정 인도"(release to manufacturing, RTM) 또는 "골드(going gold)"라는 용어는 소프트웨어 제품이 인도될 준비가 되었을 때 사용되는 용어이다. 이 빌드는 디지털 서명이 되어 있을 수 있으며, 이를 통해 최종 사용자는 구매한 소프트웨어의 무결성과 진위 여부를 확인할 수 있다. RTM 빌드는 "골드 마스터" 또는 GM[14]으로 알려져 있으며, 해당되는 경우 대량 복제나 디스크 복제를 위해 보내진다. 이 용어는 오디오 음반 제작 산업, 특히 마스터링 과정에서 유래되었다. RTM은 제품이 대중에게 공개되는 일반 가용성(GA)보다 앞선다. 골드 마스터 빌드(GM)는 일반적으로 개발자를 위한 베타 단계의 최종 빌드이다. 일반적으로 iOS의 경우 주요 릴리스 전의 최종 빌드이지만, 몇 가지 예외가 있었다.

RTM은 일반적으로 특정 소매용 대량 생산 소프트웨어 문맥에서 사용된다(상업적 또는 정부용 전문 소프트웨어 생산 또는 프로젝트와 대조됨). 여기서 소프트웨어는 관련 컴퓨터 하드웨어 판매의 번들 일부로 판매되며, 일반적으로 소프트웨어와 관련 하드웨어가 소매점에서 대중에게 최종적으로 판매될 수 있도록 소프트웨어가 정의된 품질 수준을 충족하고 대량 소매 배포 준비가 되었음을 나타낸다. RTM은 다른 문맥에서 소프트웨어가 관련 하드웨어 최종 사용자 컴퓨터나 기기에 설치 또는 배포되도록 클라이언트나 고객에게 인도 또는 릴리스되었음을 의미할 수도 있다. 이 용어는 전달 메커니즘이나 볼륨을 정의하지 않으며, 단지 품질이 대량 배포에 충분함을 명시한다. 엔지니어링 조직의 산출물은 종종 복제나 웹용 이미지 제작에 사용되는 골드 마스터 미디어 형태이다.

일반 가용성 (GA)

섬네일을 만드는 중 오류 발생:
제품 수명 주기의 마일스톤: 일반 가용성(GA), 단종 예고(EOLA), 마지막 주문일(LOD) 및 제품 수명 종료(EOL)

일반 가용성(General availability, GA)는 모든 필요한 상업화 활동이 완료되고 언어, 지역, 전자적 방식 대 물리적 미디어 가용성에 따라 소프트웨어 제품을 구매할 수 있는 마케팅 단계를 의미한다.[15] 상업화 활동에는 보안 및 규정 준수 테스트뿐만 아니라 현지화 및 전 세계 가용성이 포함될 수 있다. RTM과 GA 사이의 시간은 GA에 필요한 모든 상업화 활동을 완료하는 데 필요한 시간 때문에 며칠에서 몇 달까지 걸릴 수 있다. 이 단계에서 소프트웨어는 "정식 출시(gone live)"된 것이다.

웹 릴리스 (RTW)

웹 릴리스(Release to the Web, RTW 또는 Web release)는 배포를 위해 인터넷을 활용하는 소프트웨어 인도 방식이다. 이 유형의 릴리스 메커니즘에서는 제조업체에서 물리적 미디어를 생산하지 않는다. 인터넷 사용이 증가함에 따라 웹 릴리스가 더 일반화되었다.

지원

지원 수명 동안 소프트웨어는 때때로 서비스 릴리스, 패치 또는 서비스 팩의 대상이 되며, 이를 "중간 릴리스" 또는 "유지보수 릴리스(MR)"라고도 부른다. 예를 들어 마이크로소프트는 32비트 컴퓨팅 버전의 윈도우 XP용으로 세 개의 주요 서비스 팩을, 64비트 컴퓨팅 버전용으로 두 개의 서비스 팩을 출시했다.[16] 이러한 서비스 릴리스에는 단일 설치 가능 패키지 형태로 제공되는 업데이트, 수정 사항 및 향상된 기능의 모음이 포함되어 있다. 또한 새로운 기능을 구현할 수도 있다. 일부 소프트웨어는 정기적인 지원을 예상하고 출시된다. 일반적으로 장기 지원이 표준인 소프트웨어 부류에는 바이러스 검사 제품군과 대규모 다중 사용자 온라인 게임이 포함된다. 윈도우 XP의 예를 계속 들자면, 마이크로소프트는 연장 지원 종료 후에도 5년 동안 유료 업데이트를 제공했다. 이는 지원이 2019년 4월 8일에 종료되었음을 의미한다.[17]

수명 종료

 수명 종료 제품 및 어밴던웨어 문서를 참고하십시오.

소프트웨어가 더 이상 판매되거나 지원되지 않을 때, 해당 제품은 수명 종료(end-of-life)에 도달했거나, 중단, 은퇴, 폐지, 포기 또는 구식이 되었다고 말한다. 그러나 사용자 충성도로 인해 해당 플랫폼이 구식이 된 후에도 오랫동안 존재가 지속될 수 있다. 예를 들어 공통 데스크톱 환경[18]과 ZX 스펙트럼이 그러하다.[19]

수명 종료 날짜 이후 개발자는 일반적으로 새로운 기능을 구현하지 않으며, 기존 결함, 버그 또는 취약점(해당 날짜 이전에 알려졌든 아니든)을 수정하지 않고 제품에 대한 지원을 제공하지 않는다. 개발자가 원할 경우 자원봉사자가 플랫폼을 유지 관리할 수 있도록 소스 코드를 공개할 수도 있다.

역사

"알파/베타" 테스트 용어의 사용은 IBM에서 시작되었다. IBM의 소프트웨어 개발을 위한 유사한 용어는 적어도 1950년대(아마도 그 이전)부터 IBM 관계자들에 의해 사용되었다. "A" 테스트는 공개 발표 전의 신제품 검증이었다. "B" 테스트는 제품 제조 전의 검증이었다. "C" 테스트는 제품의 일반 가용성 이전의 최종 테스트였다. 소프트웨어가 IBM 제품의 중요한 부분이 됨에 따라 알파 테스트 용어는 발표 전 테스트를 나타내는 데 사용되었고, 베타 테스트는 일반 가용성을 위한 제품 준비 상태를 보여주는 데 사용되었다. 초기 IBM 소프트웨어 프로젝트의 관리자였던 마틴 벨스키(Martin Belsky)는 자신이 이 용어를 발명했다고 주장했다. IBM은 1960년대에 알파/베타 용어 사용을 중단했지만, 그때 이미 널리 알려진 상태였다. 고객이 수행하는 테스트를 지칭하기 위해 "베타 테스트"를 사용하는 방식은 IBM에서 이루어지지 않았다. 대신 IBM은 "필드 테스트(field test)"라는 용어를 사용했다.

주요 공개 베타는 이후에 개발되었는데, 초기 고객들은 IBM PC용 WordVision 워드프로세서의 "파이오니어 에디션(pioneer edition)"을 49.95달러에 구매했다. 1984년 스티븐 메인즈(Stephen Manes)는 "훌륭한 마케팅 전략을 통해 브루스 앤 제임스 프로그램 퍼블리셔스(Bruce and James Program Publishers)는 사람들이 제품을 테스트하는 특권에 대해 비용을 지불하게 만들었다"라고 썼다.[20] 2000년 9월, 애플의 맥 OS X 공개 베타 운영체제의 박스 버전이 출시되었다.[21] 2005년 9월에서 2006년 5월 사이에 마이크로소프트는 윈도우 비스타를 위한 커뮤니티 기술 프리뷰(CTP)를 릴리스했다.[22] 2009년부터 2011년까지 마인크래프트는 공개 베타 상태였다.

2005년 2월, ZDNet은 베타 버전이 종종 수년 동안 유지되면서 마치 정식 버전인 것처럼 사용되는 현상에 대한 기사를 게재했다.[23] 이 기사에서는 Gmail과 구글 뉴스가 널리 사용됨에도 불구하고 오랫동안 베타 상태였다는 점을 언급했다. 구글 뉴스는 2006년 1월에 베타를 종료했고, 이어서 Gmail을 포함한 구글 앱스(현 구글 워크스페이스)가 2009년 7월에 종료되었다.[13] 윈도우 8 출시 이후, 마이크로소프트는 출시 전 소프트웨어를 베타 대신 프리뷰라고 불렀다. 2014년에 시작된 윈도우 인사이더 프로그램을 통해 릴리스된 모든 출시 전 빌드는 "인사이더 프리뷰 빌드"라고 불린다. "베타"는 또한 릴리스 후보와 유사한 것, 또는 시간 제한 데모 형태나 마케팅 기법을 나타낼 수도 있다.[24]

같이 보기

각주

  1. ↑ 소프트웨어 생명 주기 - 컴퓨터인터넷IT용어대사전, 전산용어사전편찬위원회 엮음
  2. ↑ “Encyclopedia definition of alpha version”. 《PC Magazine》. 2011년 4월 27일에 원본 문서에서 보존된 문서. 2011년 1월 12일에 확인함. 
  3. ↑ “What is an alpha version of a game?”. 2022년 9월 23일에 원본 문서에서 보존된 문서. 2022년 9월 23일에 확인함. 
  4. ↑ Ince, Darrel 편집 (2013). 〈Alpha software〉 3판. 《A Dictionary of the Internet》. Oxford University Press. ISBN 978-0-19-174415-0. 2019년 7월 15일에 확인함. 
  5. ↑ “The Next Generation 1996 Lexicon A to Z”. 《Next Generation》. 15호 (Imagine Media). March 1996. 29쪽. Alpha software generally barely runs and is missing major features like gameplay and complete levels. 
  6. ↑ 《A Dictionary of Computer Science》 7판. Oxford University Press. 2016. 44쪽. ISBN 978-0-19-968897-5. 
  7. ↑ Cusumano, Michael (1998). 《Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People》. Free Press. 202–203쪽. ISBN 978-0-684-85531-8. 
  8. ↑ “The Next Generation 1996 Lexicon A to Z”. 《Next Generation》. 15호 (Imagine Media). March 1996. 30쪽. 
  9. ↑ “Technology Preview Features Support Scope”. 레드햇. 2015년 3월 18일에 확인함. 
  10. ↑ Amit Mehra; Rajib Lochan Saha (2017년 6월 19일). “Utilizing Public Betas and Free Trials to Launch a Software Product”. 《Production and Operations Management》 27 (11). 
  11. ↑ Lang, Michelle M. (2004년 5월 17일). “Beta Wars”. 《Design News》 59 (7). 
  12. ↑ “Waiting with Beta'd Breath TidBITS #328 (May 13, 1996)”. 1996년 5월 13일. 2022년 12월 6일에 원본 문서에서 보존된 문서. 
  13. ↑ 가 나 “Google Apps is out of beta (yes, really)”. 《Google Blog》. 2009년 7월 7일. 2011년 1월 21일에 원본 문서에서 보존된 문서. 2011년 1월 12일에 확인함. 
  14. ↑ “What is Golden Master (GM)? - Definition from Techopedia” (영어). 《Techopedia.com》. 2013년 8월 19일. 
  15. ↑ Luxembourg, Yvan Philippe (2013년 5월 20일). “Top 200 SAM Terms – A Glossary Of Software Asset Management Terms”. 《Operations Management Technology Consulting》. 2013년 8월 10일에 원본 문서에서 보존된 문서. 2013년 5월 21일에 확인함. 
  16. ↑ “Microsoft Update Catalog”. 《www.catalog.update.microsoft.com》. 2024년 5월 3일에 확인함. 
  17. ↑ “Microsoft Product Lifecycle Search”. 2012년 7월 20일. 2012년 7월 20일에 원본 문서에서 보존된 문서. 2024년 5월 3일에 확인함. 
  18. ↑ “[cdesktopenv-devel] CDE 2.2.1 released | CDE - Common Desktop Environment”. 《sourceforge.net》. 2024년 5월 3일에 확인함. 
  19. ↑ “ZX-Uno [ZX Spectrum Computer Clone Based on FPGA]”. 2018년 1월 5일. 2018년 1월 5일에 원본 문서에서 보존된 문서. 2024년 5월 3일에 확인함. 
  20. ↑ Manes, Stephen (1984년 4월 3일). “Taking A Gamble With Word Vision”. 《PC Magazine - The Independent Guide To IBM Personal Computers》. 3권 6호 (PC Communications Corp.). 211–221쪽. ISSN 0745-2500. 2015년 3월 17일에 원본 문서에서 보존된 문서. 2015년 2월 15일에 확인함. 
  21. ↑ “Apple Releases Mac OS X Public Beta” (보도 자료). Apple Inc. 2000년 9월 13일. 2024년 1월 28일에 확인함. 
  22. ↑ “Microsoft Windows Vista October Community Technology Preview Fact Sheet” (보도 자료). Microsoft. October 2005. 2011년 4월 30일에 원본 문서에서 보존된 문서. 2011년 2월 22일에 확인함. 
  23. ↑ Festa, Paul (2005년 2월 11일). “A long winding road out of beta”. 《ZDNet》. 2025년 9월 20일에 확인함. 
  24. ↑ Houghton, David (2010년 5월 17일). “The inconvenient truths behind betas”. 《GamesRadar》. 2011년 4월 30일에 원본 문서에서 보존된 문서. 

외부 링크

모듈:Authority_control 159번째 줄에서 Lua 오류: attempt to index field 'wikibase' (a nil value).

원본 주소 "https://www.hanul.wiki/w/index.php?title=소프트웨어_배포_생명_주기&oldid=217526"