20년 이상 개발을 해왔고 또한 소프트웨어 공학을 전공한 사람으로서 말씀 드리건대(잘난 척하려는 것이 아니라 제 의견의 신빙성을 위한 멘트임), 소프트웨어 개발의 라이프사이클에서 통용되는 일반적인 정의는 다음과 같습니다.
알파(Alpha) 버전: 모든 기능이 구현되지는 않았지만 주요 요구사항을 만족하는 버전. 기능 구현이 부족하고 불안정하며, 일반적으로 내부 테스터를 위한 버전.
베타(Beta) 버전: 초기 소프트웨어 요구사항 스펙에 있는 모든 기능을 구현한 것이나 중간에 발생한 요구사항은 반영되어 있지 않을 수 있고, 버그가 존재하며 안정적이지 않은 버전. 일반적으로 일부 고객이 프리뷰할 수 있도록 제공하는 버전. 프리뷰 또는 테크니컬 프리뷰라고도 함.
RC(Release Candidate): 치명적인 버그가 발견되지 않는다면 최종 제품으로 릴리즈를 하기 위한 버전. 일반적으로 이 단계에서 코드 완결(Code Complete)이 됨.
위의 정의에 가장 부합하는 사례로 MS의 소프트웨어 제품들을 예로 들 수 있습니다.
다만 위의 정의는, 상품으로서의 패키지 소프트웨어를 위주로 한 정의입니다. 최근에 소프트웨어가 서비스화되고 웹 사이트들이 "베타"라는 말을 유행처럼 남발하면서 전통적인 베타 버전의 정의 또한 변화를 요구 받고 있는 상황이기는 합니다.
하지만 베타 버전의 정의는 여전히 다음과 같습니다.
베타 버전은 버그가 존재하며 안정적이지 않으며 초기에 정한 요구사항은 반영되었더라도 중간에 결정된 요구사항은 반영되지 않은 버전입니다.
개발의 전체 라이프사이클에서 소프트웨어 요구사항은 계속 추가/변경/삭제됩니다. 베타 버전의 단계에서도 그것이 계속 발생하고 있는 것입니다. 참고로 MS는 제품의 완성도를 높여 가면서 베타1, 베타2, 베타3 등으로 명명을 합니다. RC가 되기 전까지 베타 버전을 계속 디버깅하고 요구사항을 구현해 나가는 것입니다.
바로 이것입니다. 그래서 업체들은 "방어적 목적으로" 베타 버전이라는 말을 사용하고 있는 것입니다. 안정적이지 않고, 버그가 있으며, 계속 변하고 있는 중이라는 뜻이죠.
제가 말씀 드린 사항은 논란의 여지가 없는 사항입니다. S/W 업계 상식적으로도, S/W 공학적으로도 통용되고 있는 내용입니다.
그러므로 소비자, 사용자들은 베타 버전을 너무 과신하지 마십시오. 실제로 업체들은, 안정적이지 않으니 그리 신뢰하지 말라는 뜻에서 “베타”라는 말을 사용하고 있는 것입니다.
물론 베타 버전을 과도하게 마케팅하는 업체는 도의상 문제가 있다고 하겠습니다.
댓글 10개:
글 잘 보았습니다.
각 버전에 따른 차이점을 굉장히 잘 정리하셨네요.
이견은 없습니다.
이견이 있을만한 부분도 아니고, 저 자신도 고개가 끄덕여지는 내용이니까요.
이래서 또 한발자국 물러서 울타리를 쳐야겠네요. 제 정의는 "주장을 뒷받침하기 위해 해당 글에서 한시적으로 정의된 것이다." 라고 ^^;
어제, 오늘 글을 쓰고 덧글에 대한 답글을 달면서 스스로도 "과연 웹서비스에서의 베타는 무엇인가?" 하는 생각을 많이 해보게 되었습니다.
쉽지 않네요. 과연 어디까지인가.
그냥 두리뭉실하게 알았는데..정확히 그런뜻이군요..:)
To mr.dust님/ 블로거닷컴에 트랙백 기능이 없어서 트랙백을 못 남겼는데, 아마도 레퍼러로 찾아오신거 같네요.
좀 까칠한 느낌의 글이어서 죄송합니다.
웹 애플리케이션에서의 베타도 마찬가지라고 봅니다. 다만 최근에는 개발이 아닌 다른 이유로 베타 용어를 남발하여서 용어의 정의가 도전받고 있는 상황입니다.
그리고 웹의 특성상 서버에서 코드 하나 고치면 바로 소비자에게 반영되므로 실시간 릴리즈가 될 수 있는 특성은 있지요. 하지만 그렇게 하는 것보다는 웹 애플리케이션도 릴리즈 버전을 관리하여 품질 확인 후 릴리즈하는 것이 좋다고 생각합니다.
업체들의 보다 책임있는 서비스 제공을 기대해 봅니다.
그리고 시원하게 인정해주셔서 참 보기가 좋습니다. 앞으로도 열정적인 글 쓰기 기대하겠습니다. 고맙습니다. ^^
S/W개발에 있어서 사전적인 정의로 베타테스트라는 것이 현재 웹2.0이라는 트렌드에 있어서는 많이 변했다고 봅니다.
본문의 내용과는 반대의 관점에서 "방어적"이라기 보다는 사용자의 요구사항을 끊임없이 받아들여 개선해 나가겠다는 "적극적"인 모습으로 베타 딱지를 붙인다고 생각합니다.
물론 마케팅의 관점에서 개나소나 다 붙이니까 나도 붙여보자~ 하는 서비스들도 있겠습니다만 말이지요.
뭐랄까, 계단형태의 업그레이드가 아니라 계속해서 조금씩 조금씩 업그레이드가 되어나가는 모습을 "베타"라는 상징적인 어휘로 표현하는 것이 아닐까 라고 생각하기도 합니다. ^^
글에 오해의 소지가 있습니다.
파이널버전에도 여전히 버그(치명적인 것을 포함해서)가 있고(많고), 안정적이지도 않으며(물론 베타보단 안정적), 과신해서도 안됩니다.
가장 부합하는 사례로 MS의 소프트웨어 제품을 들 수 있겠습니다 ;)
To justin님/ 만일 말씀하신 내용을 인정한다면, 웹 서비스에서 베타와 정식의 차이는 어떤 것일까요?
물리적인 패키지 또는 설치 파일을 최종 사용자에게 딜리버리하는 상품으로서의 S/W와는 달리, (개발이 아닌 비즈니스로서의) 웹 서비스는 그 자체의 특징이 바로 "끊임없는 개선"이 가능하다는 것입니다.
즉 말씀하신 사항은 웹 서비스 자체의 특징이 그런 것입니다.
베타 개념이 웹 서비스에서 가장 제대로 사용되는 실례를 보면,
기능 구현이 완료되고 서비스가 안정화되면 베타라는 딱지를 떼고, 추후 x.0 버전을 제작할 경우 이전 버전은 계속 서비스하면서 베타 사이트를 만들어 별도 테스트 서비스를 하는 형태를 예로 들 수 있습니다.
이것은 가장 보편타당한 베타 개념이 아닐까 싶습니다.
만일 "우리는 고객의 요구사항을 받아들여 항상 개선되고 있어요. 그래서 베타라는 용어를 사용하고 있어요"라면, 해당 서비스는 영원한 베타일 것입니다.
그런 식으로 사용하는 것이 물론 불법은 아닙니다만(당연히 아니죠!), 저와 같은 업계 관계자의 입장에서 그런 서비스는 오히려 상당히 신뢰감이 떨어진다고 생각합니다.
S/W 개발의 기본 합의조차 지키지 않는 것이니까요.
제 직종상(직업인의 책임감) 아무래도 이 부분은 엔지니어적으로 말씀드릴 수 밖에 없네요.
To sok님/ 제 글에 오해의 소지는 없습니다.
제 글을 제대로 읽어보지 않으셨군요. 저는 파이널 버전이 버그가 없고 안정적이고 신뢰할 수 있다는 내용을 전혀 적지 않았습니다.
MS 뿐만 아니라 모든 S/W 업체들은 사실, 버그가 있는 제품을 고객에게 최종 버전으로 딜리버리합니다. S/W 개발의 특성상 버그가 0인 제품은 존재하기 어렵기 때문입니다.
하지만 개발 업체의 이익을 위해서라도, 이미 발견된 치명적인 버그를 그대로 남기고서 출시하는 것은 지극히 예외적인 경우입니다. 왜냐하면 신뢰도 하락, 금전상 손실 등 사업상 큰 손해를 가져올 수 있기 때문입니다.
MS 또한 이러한 개념하에서 제품을 개발하고 출시하고 있습니다.
혹시 개발자이신가요?
MS에도 수많은 개발자들이 있습니다. 그들은 그들에게 주어진 일을 책임지고 해내려고 노력 중입니다. 그들은 일부러 치명적인 버그를 남기지는 않습니다. 그런 행동은 직업인의 자세가 아니며, 직업 윤리를 어기는 것입니다. 그들 또한 버그의 심각도에 따라 엄청난 품질 관리 노력을 기울이고 있습니다.
물론 치명적이지 않은 버그는 Known bugs라고 해서, 남겨둔 채로 출시하는 경우가 빈번합니다. 모든 버그를 0로 만드는 것은 현실상 불가능하기 때문입니다.
다만 출시 시점에서 미처 발견 못한 심각한 버그, Known bugs들은 패치/서비스팩 등의 이름으로 출시 이후에 해결을 합니다.
증대되는 S/W의 복잡성이 품질 관리를 어렵게 하고 있으며, 우리 업계의 가장 큰 도전 과제 중의 하나라고 하겠습니다.
정작 제가 오해토록 썼군요.
버그를 "숨긴 채" 제품을 출시한다는 뜻은 아닙니다.
다만 품질을 위한 그모든 노력에도 불구하고,
베타와 출시버전 사이에 어떤 결정적인 차이가 있는 것이 아니라 정도차만(벌레투성이와 무결 사이의 연속스펙트럼상의) 있을 뿐이라고 보고,
그래서 요즘같은 '베타'의 사용이 그리 잘못된 것은 아니지 않은가 하는 뜻에서 댓글을 달았습니다.
건필하십시오.
소프트웨어 엔지니어링적 관점에서 "베타"란 의미를 무시한다는 말은 아니구요, 저역시도 엄밀하게 말씀드려서 베타테스트의 의미에는 한석님의 의견에 동의합니다. 그것이 패키지 S/W이건 웹이건 엔지니어링 관점에서는 분명 동일한 것이 맞습니다.
다만, 제가 말씀드린 현재의 추세는 베타 딱지가 단지 엔지니어링적인 관점에서만 붙이는 것이 아닌 마케팅적인 관점에서이지요. 대표적인게 Gmail 아니겠습니까? 이미 완성도 있는 서비스임에도 불구하고 끊임없이 베타 딱지를 붙이고 있는 상태구요, 그러한 상황에서 계속적으로 추가적인 기능들이 들러붙지요. 말씀하신 대로라면 이 베타서비스는 신뢰도가 떨어져야 마땅할진대 사람들이 열광하는 이유는 무엇일까요?
앞서도 말씀드렸다시피 웹서비스의 특징을 바탕으로 하여 "우리는 서비스를 지속적으로 개선시켜 나가겠다"는 의지(?)를 표현하는 것이 현재 베타의 마케팅적인 의미로 쓰인다는 말이지요.
To sok님/ 네, 물론 잘못된 것은 아닙니다.
그리고 결정적인 차이가 있는 경우도 있고, 아닌 경우도 있죠. 말씀해주신, 연속스펙트럼이라는 표현은 좋은 표현으로 생각합니다.
개발 "관리"의 편의상 마일스톤으로 나누기는 하지만, S/W는 연속적인 과정으로 자연스럽게 만들어지는 제품이니까요.
피드백 고맙습니다. ^^
To justin님/ 저도 지메일을 좋아합니다. 다만 그 완성도와 안정성에 대해서는 불만이 없지는 않습니다. 구글도 좀 더 고민 중이라서 베타를 붙여놓은 것이라고 생각합니다.
아마 구글 스스로 자신감이 생기면 베타 딱지를 떼지 않을까 싶네요. 구글의 다른 서비스들을 보건대, 영원히 베타를 붙여놓지는 않을 겁니다.
그리고 현재 소위 웹 2.0 사이트들에서 "베타"가 마케팅적 용도로 쓰이는 것을 저도 인정합니다.
좋은 의견 주셔서 저도 한번 더 생각해볼 수 있었습니다. 고맙습니다. ^^
댓글 쓰기
댓글을 환영합니다.
스팸으로 인해 모든 댓글은 운영자의 승인 후 등록됩니다. 스팸, 욕설은 등록이 거부됩니다. 구글의 블로그 시스템은 트랙백을 지원하지 않습니다.