안녕하세요 키노코더입니다.
얼마전 Unity 5의 마지막 버전인 Unity 5.6이 릴리즈되었습니다. 몇 가지 주요 기능에 업데이트가 있었는데요. 기능의 업데이트보다 중요한 것은 5.6을 이후로 Unity의 업데이트 방식이 {Major Version}.{Minor Version}으로 운용되던 Unity의 버전이 Unity 2017.x 식으로 변경된다는 점입니다. 단순히 Versioning이 바뀌는 것이 아니라 라이센스의 방식과 업데이트 주기 등에 큰 변화가 오는데요. 이에 대해 다뤄보겠습니다.
우선 전체적인 내용은 아래 유니티 공식 홈페이지의 블로그와 유니티 홈페이지의 내용을 참고했습니다. 참고로 아래 공식 블로그는 2016/12/13에 게시된 게시글이기에 최근 업데이트된 내용과는 조금 다른 부분들이 있습니다. (내용 중 Unity 2017이 4월부터 예정되어 있다고 하는데요. 현재기준 2017/6 출시를 목표로하고 있으며, 현재는 1.0베타가 출시되었습니다.)
Unity 5 마지막 버전 Unity 5.6 안내 및 Unity 2017 소개
Unity 2017.x로 바뀌는 Version scheme
기존에 유니티는 앞서 말씀드린 것처럼, Sequence-based Version Scheme인 {Major Version}.{Minor Version} 형식을 따랐으며, 대규모 기능의 업데이트와 함께 아키텍쳐 전반의 변화가 있는 경우에는 Major Version을 올리고, 그 외의 소규모 기능 업데이트에서는 Minor Version을 올리는 방식이었습니다. 별 문제 없어 보이는 Version을 왜 굳이 2017.x와 같은 형식으로 바꾸는 것일까요?
사실 위와같이 버전을 {Released Year}.{Released #}을 표시하는 방식은 최근 몇 년간 구독 방식으로 라이센스를 판매하는 소프트웨어들 전반에 걸처 유행하는 (?) Versioning 방식입니다. 물론 Windows 95, Ubuntu 8.04 등 처럼 이미 익숙한 SW들도 이름에서부터 Release Date 기반의 Version Scheme을 사용하는 경우도 있었습니다. (Windows 95는 95년에 출시하였고, Ubuntu 8.04는 2008년 4월 출시되었습니다.)
기존의 Sequence-based Version Scheme에서는 사용자가 현재 버전이 최신 버전대비 얼마나 뒤처진 버전인지 파악하기 쉽지 않습니다. (물론 이게 사용자를 위해서라기 보다 마케팅효과를 노렸다는 생각이 더 강력하게 듭니다.) 그렇기때문에 대부분 Sequence-based Version Scheme에서는 Major Version과 Minor Version을 변경 사항의 중요도나 호환성 등을 고려하여 결정합니다. 이러한 Version Scheme은 사전 지식을 가진 사람들끼리는 매우 쉽게 의도가 파악되지만, 그렇지 않은 사람들에게는 그저 순서대로 올라가는 숫자로 인식될 뿐이기 때문에 그리 유용하지는 않습니다. 반대로 말하면 Version Scheme만 알고 있다면 현재 내가 사용중인 버전과 최신 버전과의 호환성이나 중요업데이트가 발생한것인지 아닌지 쉽게 파악이 가능합니다. 이러한 Version Scheme을 잘 모른다면 Release Date를 이용한 Version Scheme은 비전문가에게 정말 쉽습니다. 한 예로 Microsoft Office 2015가 Microsoft Office 2007에 비해 월등히 앞선 버전이라는 것은 누가봐도 압니다. 버전만 봐도 무려 8년이라는 제품 발매 시기 차이가 보이기 때문입니다.
또한 SW가 어느 정도 안정이되면 Major Version을 바꿀만큼 아키텍처의 변화가 생기거나 호환성 문제가 발생하는 경우가 적습니다. 그럼에도 기능은 계속해서 업데이트되지만 사람들의 인식은 Major Version이 그대로이면 '아, 이 SW는 몇 년째 메이저 업데이트가 없네? 업데이트가 잘 안되는 SW구나'라고 생각하게 됩니다. 하지만 Release Date를 사용하면 앞서 예로든 Microsoft Office 같이 버전의 차이를 기능의 차이보다는 출시 시기로 비교하게 되어 업데이트 필요성에 대해 좀 더 어필할 수가 있죠. 이러한 점 때문에 저는 Release Date Version Scheme 자체는 사용자를 위한다기보다는 개발사의 마케팅이라고 생각합니다.
물론 유니티의 경우 단순히 Release Date Version Scheme을 따르는 것만이 아니라, 릴리즈 플랜도 구체적으로 제시했습니다. 기존처럼 Major Version의 목표를 설정해두고 해당 버전의 모든 기능을 한번에 릴리즈하는 전통방식이 아닌 매주 업데이트가 제공되고, 소규모 기능 업데이트는 매달, 그리고 새로운 기능 추가는 분기마다 추가되는 방식으로 릴리즈가 진행됩니다.
이렇게 잦은 업데이트가 진행될 경우 Sequence-based Version Scheme에서는 버전이 복잡해지고 숫자가 너무 커질 수 있습니다. Release Date Version Scheme을 따르는 최근 SW 대부분은 유니티가 제시하는 새로운 릴리즈 계획과 유사하게 월단위로 소규모 업데이트를 내놓고, 분기나 1년 단위 등으로 대규모 업데이트를 내놓는 방식을 많이 취합니다. 이러한 방법은 전통적인 릴리즈 방식에서 발생할 수 있는 리스크를 분산시키는 효과와 사용자들의 피드백을 빠르게 반영할 수 있다는 장점이 있습니다.
Version Scheme과 릴리즈 방식이 섞이면서 이야기가 조금 복잡해진 것 같지만, 이야기를 종합해보면 다음과 같습니다.
"Version Scheme의 변화는 릴리즈 방식의 변화에 따른 산출물이기도 하지만, 기존 Scheme에서도 못할 것은 아니다. 하지만 사용자에게 버전 차이에 대한 인식을 각인시키기에는 좋은 마케팅 효과를 가졌다."
구독 라이선스는 무엇?
앞서 Version Scheme을 바꾼 것은 상술의 일환이다! 라고 말할 수 있었던 것은 라이선스를 영구 라이선스 방식에서 구독 형태로 변경했기 때문입니다. 기존에 유니티는 일정 금액을 내고 라이선스를 구매하면 해당 라이선스에 대한 영구적인 소유권을 가질 수 있었고, 해당 Major Version에 대해서는 업데이트가 무제한 가능했습니다. 하지만, 이번에 구독 방식으로 변경되면서 특정 Major Version에 대한 소유가 아닌, 구독 기간동안만 소유권을 갖고 해당 기간 안에만 업데이트가 무제한 가능하게 됩니다. 어떻게 보면 이게 무슨 말도안되는 변경이냐고 생각할 수도 있는데, 이미 많은 SW들이 이러한 라이선스로 판매되고 있고 장점 역시 있습니다.
구독 라이선스의 장점은 특정 Major Version에 구속되느냐 안되느냐의 차이에서 옵니다. 영구 라이선스의 경우 특정 Major Version에 한해서만 소유권이 인정되고 업데이트가 가능하기 때문에 만약 새로운 Major Version이 나오면 새로운 기능을 위해 다시 라이선스를 구매해야한다는 문제가 있습니다. 대부분의 경우엔 정해진 예산으로 개발에 착수하기 때문에 이러한 추가 비용은 감당하기 어렵습니다. 하지만 구독 라이선스의 경우 예산 측정이 쉽고, 해당 기간동안은 무제한 업데이트가 가능하기 때문에 새로운 기능에 대해서도 개발 중 즉각 적용이 가능합니다. (물론 개발 진도와 기술적용 난이도에 따라 적용 여부가 결정되겠지만..)
그럼에도 비용적인면에서 영구 라이선스가 유리할 수도 있기때문에 영구 라이선스를 여전히 원하는 개발팀도 있을 텐데요. 그렇다면 이제 영구 라이선스는 영영 못보는 것인가? 다행히도 아예 없어지는 것은 아닌 것 같습니다. 24개월 이상 구독을 완료한 후 추가 결제를 통해 구독 중단 시의 해당 버전을 영구 소유할 수 있다고 합니다. 단, 업데이트는 구독 중지시점부터 3회까지만 가능하며 다시 구독을 하기전까지는 추가 업데이트는 이용하지 못한다고 하네요. 보다 자세한 내용은 아래 유니티 공식 홈페이지의 QnA를 참고하시기 바랍니다.
Unity Pro 영구 라이선스는 계속해서 판매하나요?
2017.x 미리보기
마지막으로 유니티 공식 홈페이지의 로드맵을 보면 앞으로 개발될 기능들에 대한 현재 진행상황을 한화면에서 볼 수 있도록 대쉬보드가 잘 구성되어 있습니다. 현재 1.0베타가 출시된 2017.1에 대해서도 구현된 기능들이나 앞으로 개발될 기능들에 궁금하신 분들은 해당 페이지를 참고하시면 좋을 것 같습니다.
유니티 로드맵 바로가기
유니티 로드맵 2017.1.0 (beta)