버전의 의미

|
자기 손으로 무언가 작은 거라도 프로그램을 만들고 약간이라도 버전 업을 해 보신 분들은 '버전 번호를 어떻게 매겨야 되지?'에 대해 고민해 보신 적이 있을 줄로 압니다.
아니더라도 '도대체 이 프로그램의 버전 번호는 무슨 기준으로 매기는 거지?'라고 생각해 보신 분들도 있을테고요.

정답은 '개발 회사(혹은 개발자) 맘대로'입니다.
저도 예전에는 잘 몰랐습니다. 아니, 어렴풋이 짐작하면서도 내심으로는 '내가 모르는 무언가 관례적인 기준이 있지 않을까' 생각했더랬지요.
관례적인 기준이란게 없지는 않지만 그 관례적이라는 말조차 사실 통하지 않는 것이 문제입니다. 프로그램마다 소스는 천차만별로 틀리니까요.
그리고 버전을 매기는 방식마저 천차만별입니다.

윈도우는 1.0, 2.0~3.1로 나가다가 갑자기 95, 98, 2000으로 나가더니 이제는 XP, VISTA등의 의미적인 이름을 아예 붙이고 있지요.
대표적인 방식은 x.y나 x.y.z 식의 형태이지만 오픈 소스의 경우 릴리즈 날짜를 버전 대신 쓰는 경우도 있습니다. 그리고 버전 번호로는 모자라서 리비전 번호를 추가하는 경우도 있지요. 2.6.20-r3 같은 식입니다.

x.y(.z)-rN 방식의 경우 관례적으로 r은 긴급한 버그 패치나 마이너한 업그레이드가 이루어졌을 경우이며 z는 약간 더 메이저한 버그 패치나 보완(이 표현 자체가 애매하긴 합니다), y는 중요한 기능의 추가 혹은 변경, x는 아키텍처나 인터페이스의 중요한 변화가 이루어졌을 경우 버전 번호가 올라갑니다.
점(.)을 쓰지만 소수가 아니므로 0.9다음은 0.10이 되는 식입니다.
그리고 최초의 쓸만한 기능을 갖춘 릴리즈는 1.0을 부여하지요. 그래서 1.0은 의미가 꽤 큽니다(수많은 곳에서 쓰고 있는 trac은 아직도 0.x 지요).

말 그대로 관례적인 방식이므로 별로 큰 의미를 둘 필요는 없습니다.
예를 들면 리눅스 커널의 경우 2.4를 주로 쓰다가 2.6이 릴리즈 되었는데 이는 리눅스 커널의 두번째 버전 번호는 홀수 버전이 개발 버전이며 짝수 버전이 정식 버전이기 때문입니다.
2.4가 정식 버전이므로 배포판들은 2.4를 기반으로 만들어지며 2.5 커널에는 새로운 기능을 추가하고 실험하고 테스트 하게 되는 것입니다. 이 동안 2.4 버전은 버그 수정이 이루어지지요. 그리고 어느 정도 안정화가 되면 2.4와 2.5를 머지하여 2.6을 릴리즈합니다.

하지만 어디까지나 위의 경우는 '정상적인' 경우입니다. 오픈 소스이고 일정은 물론 존재하지만 상업 제품만큼 압박을 받지는 않기 때문에 저런 버전 넘버링이 착실하게 이루어질 수가 있다고 봐야겠지요.
아주 유명한 소프트웨어 회사가 아닌 경우, 특히 우리 나라의 IT 중소기업이라면 버전 번호는 정치적인 도구로 전락하는 경우가 많습니다. 어차피 소스는 공개되지 않으니 버전 번호를 큰 의미없이 올리는 경우가 많다고 봐야 되겠지요.

그리고 그런 버전 번호 자체가 의미 없어지는 경우도 많습니다. 고객사에 따라 커스터마이징된 버전들이 따로 존재하는 경우인데 물론 고객마다 요구하는게 다르니까 그렇겠지요. 얼핏 듣기에는 괜찮아 보이지만 이런 경우는 개발자가 매우 피곤해집니다. 비슷하면서도 다른 소스들을 관리해야 되고 버그 하나를 수정할 경우 같은 작업을 여러 번 반복해야 되는 경우도 생깁니다.
컴파일 옵션이나 설치 옵션, 실행 옵션을 통해서라도 소스를 통합하는 것이 낫습니다.

어쨌든 버전의 의미는 때로는 사용자들한테 기대를 가져다 줄 수도 있지만, 반대로 악몽을 알리게 되는 경우도 있습니다.
어쩔 수 없이 새로운 버전이 나오면 써야 되는 경우(?)가 해당이 될텐데 저는 군대에서 겪었습니다. 인사관리 시스템인가 뭔가 파워빌더로 만든 것이었는데 새 버전이 출시되면 군사령부에서 설명회를 갖는데 '무슨무슨 버그가 있으므로 이 기능은 사용하지 마세요'라는 말도 하더군요 -_-;

이런 이유로 버전 번호 뒤에 b(beta)가 붙는 경우가 생깁니다. 베타 버전이란 말인데 좋게 해석하면 정식 릴리즈 이전에 테스트를 목적으로 배포하는 버전입니다.
그런데 이게 악용되어서 '베타 버전은 버그가 있어도 된다'라고 개발사측에서는 생각하는 경우도 많다는게 문제입니다(배포되는 상용 소프트웨어는 이런 경우가 잘 없지요, 버그가 있어도 베타 버전을 쓰지 누가 돈 주고 사서 쓰겠습니까? 불법복제의 굴레도 벗어날 수 있고 얼마나 좋습니까 -_- 대표적인 것이 아래아 한글 3.0b였습니다.). 알집의 도움말의 '알집은..' 메뉴에도 베타 버전 얘기가 나오지요.



베타 이야기...

베타테스트를 했더랍니다.
처음엔 그런거 안했었는데...
언젠가부터 말들이 많아집디다.
알집... 띠리리 하다고...
가슴이 아팠습니다.
눈물이 났습니다.
개중엔 버그 적은 버전도 간혹 있는데...
흑흑흑...
울다 지쳐 핑계꺼리를 찾았습니다.
이름하여 베타버전...
버그 많아 띠리리 하다고 하면...
베타버전이라고 친절히 답변해 드렸습니다.
크크크...
그렇게 우린 베타7 까지 갔습니다.
함 베타100 까지 가볼라구랬습니다.
근데... 한번은 이런 멘트를 합디다...
"이잭기들... 장냔하냐~"고...
쪼발린 가슴을 부여잡고...
베타를 띠기로 했습니다.
인자 버그가 없어야 합니다.
흐흐흐...
베타이야기 끝~


베타이고 아니고를 떠나 '사용자가 테스트해 줄거야'라는 마인드 자체는 문제가 있습니다.
베타이든 아니든 외부에 릴리즈 되기 전에는 충분한 테스트와 버그 수정이 이루어져야 합니다. 그렇지 않으면 베타이고 자시고 제품 이미지는 점점 나빠지게 되고 이는 쉽게 되돌릴 수 없습니다.

베타든 버전 뻥튀기는 다시 말하자면 이는 버전 번호를 가벼이 생각하고 정치적으로 이용한다는 것이 문제입니다.
제가 생각하는 버전 넘버링은 신성...까지는 아니더라도 개발자나 사용자 모두에게 기능상의 지표가 되는 구실을 해 주어야 합니다. 버전 관리가 엄격히 잘 된다는 것은 소스의 형상 관리와 문서화가 잘 되어야 가능한 일이기 때문입니다.
이는 제품 매뉴얼만을 보아도 드러납니다(매뉴얼이 아니라도 어느 정도의 ChangeLog 관리는 필요하지요). 대충 개발하는 회사는 매뉴얼도 대충 만들게 되겠지요. 하지만 관리가 잘 되는 회사는 매뉴얼도 어느 정도 수준이 있는 개발자나 이해할만한 디테일한 사항까지 세세하게 적혀 있습니다.

예를 들면 MySQL 매뉴얼의 CHAR 타입 챕터에는 다음과 같은 내용이 있습니다.

"문자열 길이는 5.0.3 이전 버전에서는 0부터 255까지 지정할 수 있으며 5.0.3부터는 65,535까지 가능하다."

간단한 예라고 생각 되지만 만약에 매뉴얼에 저런 부분이 없었다가 추가해야 될 경우 어떤 버전부터 반영되었는지 쉽게 찾을 수 있을까요? 소스와 버전 관리가 제대로 되지 않았다면 아마 개발자가 기억하는 히스토리에 의존해야 될 것입니다.
핵심 개발자가 회사를 나가면 구멍이 생기는 이유가 다 저런 데에 있지요. 물론 히스토리 관리가 잘 되어 있어도 좋은 개발자가 회사를 나가는 것은 피해이긴 합니다만...

제가 다니는 회사도 좀 주먹구구식이라(나름 노력하고는 있지만) 답답한 맘에 한 번 쓴 글이었습니다...-_-;

'Programming Story' 카테고리의 다른 글

DB Isolation Level  (0) 2007.04.18
버전의 의미  (0) 2007.03.21
엔트로피  (0) 2007.02.27
UTF-8 이야기  (3) 2007.01.30
Trackback 1 And Comment 0