배포를 위한 소프트웨어 버전 선택하기

IT 업계에서 자주 논의되는 주제 중 하나는 “어떤 버전의 소프트웨어를 설치해야 하는가”입니다. 이는 데이터베이스, 애플리케이션, 펌웨어 또는 가장 빈번하게는 운영 체제에 적용될 수 있으며, Windows XP의 임박한 지원 종료로 인해 이 주제가 뜨거운 감자로 부상했습니다.

이 논의에는 사실상 두 가지 입장이 있습니다. 한쪽은 항상 최신이고 최고의 소프트웨어를 사용해야 한다고 믿습니다. 다른 쪽은 소프트웨어가 성숙해질 필요가 있다고 보고 “관망” 접근법을 취하거나 심지어 각 버전을 연속적인 개발이 아닌 별개의 제품으로 간주합니다.

두 접근법 모두 장점이 있으며, 어느 쪽도 완전히 단독으로 존재해서는 안 됩니다. 소프트웨어를 무분별하게 업데이트하는 것은 현명하지 않으며, 이유 없이 패치와 업데이트를 피하는 것도 현명하지 않습니다. 이러한 결정을 내릴 때 요소들을 신중하게 고려하고 소프트웨어 개발 프로세스에 대한 공감을 갖는 것이 중요합니다.

먼저 완전히 다른 두 가지 시나리오를 고려해야 합니다. 하나는 현재 기존 소프트웨어의 업데이트입니다. 현재 상태가 “작동 중”이라는 가정 하에, “작동 중”에는 발견되어 해결이 필요한 보안 취약점이 포함될 수 있다는 점을 감안합니다. 다른 시나리오는 현재 아무것도 없는 상태에서 처음부터 시작하는 새로운 배포입니다.

두 번째 경우부터 시작하겠습니다. 이 경우가 지침을 제공하기 훨씬 더 쉽기 때문입니다.

새로운 소프트웨어 배포(또는 새로운 운영 체제)의 경우, 알려진 버그나 소프트웨어 비호환성 같은 명확하게 알려진 기술적 제한이 없는 한 항상 현재의 가장 최신 버전을 사용하십시오.

소프트웨어는 다른 종류의 제품과 다릅니다. 특히 오늘날의 온라인 패치 릴리스 및 업데이트 세계에서는 더욱 그렇습니다. 구버전 소프트웨어가 최신 버전보다 더 좋을 수 있다는 사고방식은 특정 연도나 모델이 여러 이유로 최신 모델보다 우수할 수 있는 물리적 제품(시계, 자동차, 식기, 가구, 와인)과, 완성된 소프트웨어 제품이 그냥 “출시”되어 최종 상태가 업데이트, 패치 또는 수정의 합리적인 기회 없이 단순히 최종 상태였던 레거시 소프트웨어 배포 방식의 조합에서 비롯된 것으로 추정됩니다. 이러한 경우 중 어느 것도 현대 비즈니스 소프트웨어에는 적용되지 않습니다(극히 드문 예외를 제외하고).

소프트웨어 개발은 대략적으로 연속체입니다. 일반적인 개발 프로세스에서는 새 소프트웨어가 기존 소프트웨어 위에 구축됩니다. 직접적으로(기존 코드베이스에 업데이트를 만들어서) 또는 간접적으로(이전 버전 소프트웨어를 개발하면서 얻은 지식을 바탕으로 재구축하여). 각각의 후속 소프트웨어 버전은 이전 버전보다 우수하다는 아이디어입니다. 물론 이것이 보장되지는 않습니다. 회귀 오류나 단순히 나쁜 개발 같은 개념도 있지만, 대체로 소프트웨어는 시간이 지남에 따라 개선됩니다 – 특히 비즈니스에서 사용하고 활발히 개발 중인 엔터프라이즈급 소프트웨어에 대해서는 더욱 그렇습니다. 새 소프트웨어는 단지 구 소프트웨어의 다음 단계가 아니라, 거의 모든 경우에 패치, 버그 수정, 업데이트의 현재 상태와 필요한 경우 접근 방식이나 기술의 변화를 나타냅니다. 품질 있는 개발사에서 나오는 새 소프트웨어는 거의 독점적으로 구 소프트웨어보다 낫습니다. 소프트웨어는 진화하고 성숙합니다.

소프트웨어 자체의 품질을 넘어서 미래에 투자한다는 개념이 있습니다. 소프트웨어는 영원히 선반에 놓아둘 수 없습니다. 실행되는 플랫폼이 변하거나, 새로운 아티팩트가 발견되거나, 보안 취약점이 발견되거나, 요구사항이 변경되기 때문에 어느 정도 최신 상태를 유지해야 합니다. 구 소프트웨어를 설치하는 것은 과거에 투자하는 것으로, 구 기술을 설치, 학습, 사용 및 지원하는 데 투자하는 것입니다. 이를 “기술 부채”라고 합니다. 이 구 기술은 수년 또는 수십 년 동안 지속될 수 있지만, 구 소프트웨어는 시간이 지남에 따라 가치가 감소하고 벤더가 계속 지원하더라도 지원 비용이 증가합니다.

기술 부채의 동일한 개념이 해당 소프트웨어 벤더에게도 적용됩니다. 소프트웨어를 만들고 특히 여러 버전의 소프트웨어를 유지하는 데는 매우 큰 비용이 듭니다. 소프트웨어 벤더는 현재 소프트웨어 릴리스에 자원을 집중하기 위해 구버전 지원을 줄일 강력한 유인책이 있습니다(이것이 SaaS 배포가 인기 있는 주요 이유 중 하나로, 벤더가 사용 가능한 버전을 제어하고 업데이트를 통해 레거시 버전을 제거할 수 있습니다). 고객이 구버전 지원을 요구하면 비용은 어딘가에서 흡수되어야 하며, 종종 모든 고객에 대한 금전적 영향과 새 제품에 대한 집중도 감소 모두에서 흡수됩니다.

이미 말한 것의 맥락 안에서 코드 성숙도에 대해 이야기하는 것이 중요합니다. 코드 성숙도는 종종 “구 코드”를 배포하는 이유로 제시되지만, 저는 이것이 소프트웨어 개발 프로세스에 대한 IT의 오해라고 생각합니다. 릴리스된 코드 라인에 대해 생각해보면, 릴리스되어 사용 중이라고 해서 그것이 더 성숙해지는 것은 아닙니다. 코드는 실환경에서 변하지 않고 그냥 거기 있을 뿐입니다. 그 성숙도는 릴리스된 날에 “잠겨” 있습니다. 패치가 된다면 릴리스 후에 “성숙”할 것입니다. 동일한 코드베이스를 기반으로 하지만 더 최신 버전의 동일한 소프트웨어는 진정으로 더 “성숙한” 코드입니다. 동일한 코드의 초기 릴리스보다 더 많은 정도로 검토, 업데이트, 테스트 등이 이루어졌기 때문입니다.

이는 각 릴리스가 새로운 기계적 문제의 기회가 있는 신선한 것이고 다른 신뢰성 문제가 있는 자동차와 반직관적입니다. 소프트웨어는 이런 식이 아닙니다. 따라서 더 성숙한 소프트웨어를 원한다는 개념은 “시도하고 검증된” 것보다 “최신 최고”를 배포하도록 유도합니다.

소프트웨어 버전 번호를 나이처럼 생각한다면 이것이 명확해집니다. Linux 3.1은 소프트웨어 성숙도 면에서 Linux 2.4보다 훨씬 오래되었습니다. 10년의 추가 개발이 있습니다.

오늘날 매우 관련성 높은 실제 예를 들어보겠습니다. 처음으로 서버를 설치하려는 업체가 있습니다. Windows Server 2012 R2가 방금 출시되었습니다. Windows Server 2008, 2008 R2(2010), Server 2012 또는 Server 2012 R2(2013년 말)를 설치해야 할까요?

많은 업체에게 이것은 각각 다른 선택 이유가 있는 두 개에서 네 개의 완전히 다른 제품에 대해 이야기하는 것처럼 들립니다. 이것은 대체로 사실이 아닙니다. 각각의 새 버전은 이전 버전의 업그레이드, 업데이트, 패치 및 기능 증가입니다. 각각의 새 버전은 이전 버전보다 더 발전하고 성숙합니다. 각각의 새 버전은 이전 릴리스의 원본에서 수행된 작업과 원본 릴리스와 후속 릴리스 사이의 버그 수정, 패치 및 기능 추가로부터 이익을 얻습니다. 각각의 새 릴리스는 실제로 이전 버전의 “마이너 릴리스”입니다. 마케팅 이름 대신 커널 리비전 번호를 보면 더 이해가 될 것입니다.

Windows Server 2008은 Windows NT 6.0이었습니다. Windows Server 2008 R2는 Windows NT 6.1이었는데, 명백히 이전 릴리스의 마이너 리비전 또는 심지어 “패치”입니다. Windows Server 2012는 Windows NT 6.2였고 현재 Windows Server 2012 R2는 Windows NT 6.3입니다. 마케팅 이름 대신 리비전 번호를 사용한다면, 의도적으로 구버전의 덜 성숙하고 덜 업데이트되고 덜 패치된 버전을 설치하는 것이 거의 미친 것처럼 들릴 것입니다. 우리는 최신 업데이트, 최신 버그 수정 및 최신 보안 문제가 해결된 것을 원합니다.

새로운 소프트웨어 배포의 경우, 설치되는 소프트웨어가 새로울수록 최신 기능을 활용할 더 좋은 기회가 생기고 불가피한 구식화가 영향을 미치기 전까지 더 많은 시간이 주어집니다. 모든 소프트웨어는 노후화되므로 새 소프트웨어를 설치하면 그 소프트웨어가 가장 오래 지속될 가능성이 높아집니다. 알 수 없는 미래를 위한 최선의 유연성을 제공합니다.

이 생각의 흐름을 따르면 프리릴리스 또는 심지어 베타 소프트웨어를 배포하는 것도 의미가 있다고 느낄 수 있습니다. 그리고 회사 전체에 릴리스하기 전에 소프트웨어를 확인하기 위한 “테스트 그룹”에서와 같이 이것이 의미가 있는 특정 경우가 있을 수 있지만, 일반적으로는 그렇지 않습니다. 프리릴리스 소프트웨어의 특성상 지원되지 않으며 결코 지원되지 않을 코드를 포함할 수 있습니다. 이러한 코드를 격리된 환경에서 사용하는 것은 유익할 수 있지만, 일반 사용에는 권장되지 않습니다. 전체 제품의 성숙도 수준에 관계없이 미리보기 또는 베타 릴리스와 최종 릴리스 사이에는 따라야 할 중요한 프로세스가 있습니다.

이제 다른 상황, 즉 기존 소프트웨어를 업데이트하는 경우에 대해 이야기하겠습니다. 이것은 물론 새로운 설치와는 완전히 다른 시나리오이며 훨씬 더 많은 요소들이 관련됩니다.

대부분의 상황에서 가장 큰 요소 중 하나는 라이선싱입니다. 소프트웨어를 정기적으로 업데이트하면 이점과 비용 방정식에서 고려해야 하는 라이선싱 비용이 발생할 수 있습니다. 대부분의 오픈 소스 소프트웨어와 같은 일부 제품은 이 비용이 없으며 새 버전이 출시되는 즉시 업데이트할 수 있습니다.

소프트웨어 업데이트의 또 다른 큰 요소는 업데이트하는 데 드는 인적 노력 비용입니다. 구 소프트웨어와 새 소프트웨어 사이에 설치 노력이 사실상 손익분기점인 새로운 설치와 달리, 실제로 새 소프트웨어는 개선과 발전으로 인해 구 소프트웨어보다 설치하기 더 쉬운 경향이 있습니다. 10년 동안 단일 버전의 소프트웨어를 유지하는 것은 그 시간 동안 업그레이드 프로세스에 자원이 투입되지 않았음을 의미합니다. 그 기간 동안 매년 업그레이드하는 것은 별도의 업그레이드를 실행하기 위해 자원이 10번 사용되었음을 의미합니다. 이것은 업데이트 비용 정당화를 훨씬 더 어렵게 만듭니다. 그러나 업데이트 프로세스 자체의 노력만이 아니라, 지속적인 업그레이드를 통해 더 많은 변화를 더 자주 경험하게 될 최종 사용자들에게 필요한 지속적인 교육도 있습니다.

이것이 소프트웨어 업데이트를 부정적으로 들리게 할 수 있지만, 그렇지 않습니다. 각 측면의 무게를 측정해야 하는 방정식일 뿐입니다. 정기적인 업데이트는 종종 최종 사용자들이 더 자연스럽게 적응할 수 있도록 큰 도약 대신 작고 점진적인 변화를 의미합니다. 정기적인 업데이트는 업데이트 프로세스가 더 쉽고 예측 가능하다는 것을 의미합니다. 정기적인 업데이트는 기술 부채가 항상 관리되고 기능, 효율성 또는 보안 개선일 수 있는 새로운 버전의 이점이 더 빨리 제공되어 더 오래 활용될 수 있음을 의미합니다.

그러나 위의 두 시나리오에서 배운 것에서 또 다른 중요한 교훈이 있습니다. 업데이트를 수행하기로 결정이 내려지면, 질문은 종종 “어느 버전으로 업데이트해야 하는가?”입니다. 그러나 실제로는 표준 패치 프로세스 이상의 모든 업데이트는 미니어처 “새 소프트웨어” 구매 결정과 같으며, 새로운 설치를 할 때 “항상” 사용 가능한 최신 버전을 설치하는 이유의 논리가 여기에도 적용됩니다. 따라서 업데이트를 수행할 때는 거의 항상 최대한 먼 버전으로 업데이트해야 합니다 – 바라건대 현재 버전으로.

Microsoft 예를 다시 적용하면, 오늘날 Windows XP를 배포한 조직을 예로 들 수 있습니다. 비즈니스는 단순한 지속적 패치가 아닌 새 버전으로의 업데이트 사이클에 투자하기로 결정합니다. Microsoft의 활성 지원 하에 여전히 있는 Windows 데스크톱 플랫폼의 몇 가지 버전이 있습니다. 여기에는 Windows Vista, Windows 7, Windows 8 및 Windows 8.1이 포함됩니다. 덜 최신 버전으로 업데이트하면 그 버전의 수명 종료 전까지 시간이 줄어들어 조직적 위험이 증가하고, 이미 구식인 기술에 대한 지속적인 투자는 기술 부채 증가와 잠재적으로 유용할 수 있는 새 기능에 대한 적은 접근을 의미합니다. 이 특정 예에서 새로운 버전은 더 안전하고 하드웨어 리소스가 덜 필요한 것으로도 간주됩니다.

모든 비즈니스는 기존 소프트웨어 업데이트 사이클에서 자신에게 맞는 올바른 균형을 찾아야 합니다. 모든 비즈니스와 모든 소프트웨어 패키지는 다릅니다. Microsoft Windows, Microsoft Office 또는 Oracle Database와 같은 엔터프라이즈 소프트웨어는 이 모델을 매우 잘 따릅니다. 소규모 소프트웨어 프로젝트와 맞춤형에 가까운 것들은 더 역동적이고 예측할 수 없는 릴리스 사이클을 가질 수 있지만 일반적으로 이 규칙의 대부분을 따를 것입니다. 소프트웨어 개발 프로세스에 공감을 적용하여 귀하와 소프트웨어 벤더가 조직에 최대의 가치를 제공하기 위해 최선의 파트너 관계를 맺는 방법을 이해하고, 기술 부채를 줄이고 조직에 가장 좋은 방식으로 소프트웨어 투자를 활용해야 할 필요성과 결합하는 것을 고려하십시오.

그러나 대략적인 규칙은 비교적 간단합니다:

새로 배포하거나 업데이트할 때는 소프트웨어의 최신 합리적 버전을 목표로 하십시오. 가능한 한 기술 부채를 제거하기 위해 모든 배포 기회를 활용하십시오.

소프트웨어가 이미 존재하는 경우 인적 노력, 라이선싱 비용, 환경 일관성 및 호환성 테스트 같은 요소와 기능, 성능 및 기술 부채의 이점을 비교 검토하십시오.