이것은 가상화할 수 없다!

IT 분야에서 이런 말을 자주 듣습니다. 벤더가 특정 시스템은 가상화할 수 없다고 말하는 것입니다. 그 이유는 다양합니다. IT 전문가 입장에서는 벤더가 이런 터무니없는 주장을 한다는 것 자체가 충격이고, 고객(또는 관리자)이 그 말을 믿는다는 사실도 마찬가지로 충격적입니다. 벤더들은 수년에 걸쳐 이 영업 전략을 완벽하게 다듬어 왔으며, 이를 면밀히 분석하는 것이 중요하다고 생각합니다.

문제의 근본 원인은 벤더들이 거의 항상 자신들의 비용은 낮추면서 고객으로부터의 수익은 높이는 방법을 찾는다는 데 있습니다. 이것이 겉보기에 이상해 보이는 많은 행동들을 이끌어 냅니다.

많은 벤더들이 시도하는 한 가지 방법은 자사 제품이 지원될 시나리오를 제한하는 것입니다. 이를 통해 그들은 지원을 단순히 제공하지 않을 준비를 갖추게 됩니다. 지원은 비용이 많이 들고 불안정하기 때문입니다. 이는 흔한 전략입니다. 어떤 경우에는 이 전략이 너무 공격적이어서 수용 가능한 프로덕션 배포 시나리오 자체가 존재하지 않게 됩니다.

이를 위한 매우 흔한 방법 중 하나는 지원되는 운영 체제를 지원하지 않는 것입니다. 이는 사실상 벤더 자신의 소프트웨어를 폐기시키는 것입니다(예를 들어, 오늘날 이는 Windows XP 이하 버전만 지원한다는 의미가 됩니다). 또 다른 예는 해당 사용 사례에 라이선스가 허용되지 않는 제품만 지원하는 것입니다(예: Windows 10을 서버로 사용하도록 요구하는 경우). 그리고 가장 흔한 사례 중 하나가 바로 가상화를 금지하는 것입니다.

이러한 시나리오들은 고객을 어려운 상황에 처하게 합니다. 한편으로는 업계 모범 사례, 표준 배포 지침, 내부 도구 및 정책을 따라야 하고, 다른 한편으로는 벤더들이 종종 적절한 시스템 설계, 계획 및 관리를 금지하기 때문입니다. 이 두 가지 필요성은 서로 충돌합니다.

물론 모든 벤더가 모든 잠재적 시나리오를 지원하기를 기대하는 사람은 없습니다. 제한은 필요합니다. 그러나 합리적이고 잘 배포된 시스템을 지원하는 것과 허용할 수 없을 만큼 나쁜 배포를 적극적으로 요구하는 것 사이에는 엄청난 간극이 있습니다. 우리는 벤더가 비즈니스 파트너로서 행동하고, 우리의 성공 또는 최소한 그들의 제품 성공에 공통된 관심을 가지기를 바랍니다. 적어도 최소한으로는, 합리적인 배포 시나리오에 대해 최선을 다한 지원이 제공되고, 적절하게 설계된 모범 사례 시나리오에 대해서는 보장된 지원이 제공되기를 바랍니다.

제한 속도로 운전하고 안전벨트를 착용하면 자동차 보증이 무효가 되고, 무모하고 보호 장구 없이 운전할 때만 지원을 받을 수 있는 세상을 상상해 보십시오!

가상화에 대해 이해해야 할 중요한 사항들이 있습니다. 첫째, 가상화는 오랜 업계 모범 사례이며 서비스를 위한 모든 프로덕션 배포 시나리오에서 사용될 것으로 기대됩니다. 가상화는 결코 새로운 것이 아닙니다. 중소기업 시장에서도 이미 10년 이상 모범 사례 범주에 속해 있었고, 엔터프라이즈 영역에서는 수십 년이 지났습니다. 우리는 이미 오래전에 비가상화 시스템 운영이 허용 가능한 것으로 간주되던 시점을 넘었습니다. 오랫동안 유지되어 온 레거시 배포도 마찬가지입니다.

물론 거의 모든 규칙에는 항상 드문 예외가 있습니다. 일부 시스템은 매우 특수한 하드웨어에 접근해야 하므로 가상화가 불가능할 수 있습니다. 하지만 현대의 하드웨어 패스스루 기술로 인해 이런 경우는 오늘날 거의 들을 수 없게 되었습니다. 또한 일부 초저지연 시스템은 가상화할 수 없지만, 이는 일반적으로 가장 큰 국제 투자 은행과 가장 공격적인 헤지펀드에만 한정됩니다. 심지어 이러한 전통적인 사용 사례의 대부분도 가상화 기술의 발전으로 제거되어 그런 상황은 드물어졌습니다. 하지만 핵심은 가상화할 수 없다면 그것은 안타까운 일이며, 여러분의 상황에서 왜 불가능한지 명확히 알고 있어야 한다는 것입니다. 그 외의 모든 경우, 여러분의 서버는 가상화되어야 합니다.

중요하지 않은 것인가?

벤더가 건강한 배포를 위한 표준 모범 사례를 따를 수 없게 한다면, 이것은 벤더 자신의 제품에 대한 그들의 견해를 무엇을 말해주는 것일까요? 다른 배포에 대해 이야기한다면, 우리가 의존할 계획인 시스템을 왜 이렇게 나쁘게 배포하는지 즉시 의문을 품을 것입니다. 벤더가 우리를 이런 식으로 행동하게 강요한다면, 우리는 동일한 방식으로 반응해야 합니다. 벤더가 제품을 우리가 가장 덜 중요한 IT 서비스를 취급하는 것과 같은 수준으로 취급하지 않는다면, 우리는 왜 그렇게 해야 할까요?

이것은 엔지니어링 분야에서 말하는 "임피던스 불일치"입니다. 우리의 필요(프로덕션 시스템)와 그 시스템을 만드는 벤더가 그것을 취급하는 방식(취미 또는 엔터테인먼트 시스템) 사이의 불일치입니다. 비즈니스를 위해 이 제품에 의존해야 한다면, 비즈니스 요구를 이해하는 벤더가 필요합니다. 즉, 프로덕션 마인드셋이 필요합니다. 제품이 비즈니스를 대상으로 하지 않거나 비즈니스 준비가 되어 있지 않다면, 우리는 그 사실을 인식해야 합니다. 우리는 왜 우리가 의존하고 지원이 필요한 서비스를 그 방식으로 사용하기 위해 의도되지 않은 프로덕션 환경에서 사용해야 한다고 생각하는지 의문을 가져야 합니다.

지원이 되는가? 테스트되고 있는가?

고객 관점에서 종종 간과되는 것은 제품에 필요한 지원 리소스가 갖추어져 있는지 여부입니다. 제품을 지원하는 팀이 축소되거나 사라지는 것은 드문 일이 아닙니다. 하지만 회사는 제품을 최대한 많은 이익을 취하려는 희망으로 계속 판매하면서, 문제가 생기면 어떻게든 해결하거나, 지원이 불가능한 상황에 처하면 고객에게 환불해 주는 방식에 기대기도 합니다.

대부분의 소프트웨어 계약에는 벤더로부터 추출할 수 있는 최대 손해 배상액이 제품 비용 또는 구매에 지출된 금액으로 제한되어 있다고 명시되어 있습니다. 이런 상황에서 벤더는 지원할 수 없는 제품을 제공하는 것에 대한 위험이 없습니다. 지원에 프리미엄을 청구하더라도 마찬가지입니다. 고객이 제품을 사용할 수 있다면 그들은 돈을 받습니다. 고객이 사용할 수 없고 벤더도 지원할 수 없다면, 어차피 받을 수 없었던 돈만 잃는 것입니다. 고객이 모든 위험을 감수하는 것이지, 벤더가 아닙니다.

이것은 물론 제품의 지속적인 테스트도 거의 없거나 전혀 없음을 시사하며, 이것은 추가적인 우려 사항이 되어야 합니다. 제품이 실행된다고 해서 계속 실행될 것이라는 의미는 아닙니다. 지원되지 않거나, 더 나쁜 경우 지원 불가능한 제품을 가동하고 실행한다는 것은 잠재적 지원 수준이 줄어들 가능성이 있는 제품에 시간이 갈수록 더 많이 의존한다는 것을 의미합니다. 소프트웨어에 대한 지원 필요성과 의존도가 증가함에 따라 시스템은 서서히 악화됩니다.

독점 제품이 프로덕션에 배포되고, 지원 요구를 수용하기 위해 모범 사례 배포를 포기하기로 결정한다면, 이것이 의사 결정 매트릭스에 어떻게 맞을 수 있을까요? 이것이 적절한 지원이 존재하지 않는다는 것을 의미해야 할까요? 다시 한번, 이전과 마찬가지로, 이것은 우리의 필요와의 불일치를 의미합니다.

 

아직도 개발 중인가?

소프트웨어의 배포 요구 사항이 오래되고 시대에 뒤진 관행을 따르거나, 시대에 뒤진(또는 합리적으로 현재적이지 않은) 소프트웨어나 설계를 요구한다면, 제품이 현재 개발 중일 가능성을 의심해야 합니다. 경우에 따라 일정 기간 동안 소프트웨어 릴리즈 주기를 모니터링하여 이를 파악할 수 있지만, 항상 그런 것은 아닙니다. 제품이 이미 개발팀 없이 사실상 폐기된 상태일 수 있다는 합리적인 우려가 있습니다. 코드는 단순히 오래된 기술적 부채일 수 있으며, 버려진 오래된 코드베이스에서 마지막 몇 달러를 벌어보려는 희망으로 판매되고 있는 것입니다. 이 과정은 흔히 생각하는 것보다 훨씬 더 일반적입니다.

소규모 소프트웨어 개발사들은 초기 소프트웨어 패키지를 개발하고 시장에 출시하여 판매할 수 있지만, 초기 릴리즈 후 개발팀을 유지하거나 재구성할 여력이 없는 경우가 많습니다. 이것은 사실 매우 일반적인 시나리오입니다. 이로 인해 고객들은 시간이 지남에 따라 점점 더 실행 불가능해지고, 배포 시나리오가 점점 더 위험해지며, 데이터 추출이 점점 더 어려워지는 제품을 갖게 됩니다.

 

플랫폼이 지원되지 않으면 어떻게 지원될 수 있는가?

더 극단적인 상황에서 나타나는 공통적인 역설은 "지원되는" 것으로 인정받기 위해 지원이 종료되었거나 의도된 사용 사례에 대해 지원된 적이 없는 다른 소프트웨어를 필요로 하는 소프트웨어입니다. 일반적인 예로는 서버 시스템을 데스크톱 운영 체제 위에서 실행해야 하거나, 더 이상 전혀 지원되지 않는 운영 체제, 데이터베이스 또는 기타 구성 요소 버전이 필요한 경우가 있습니다. 이 마지막 시나리오는 무서울 정도로 흔합니다. 이런 상황에서는 소프트웨어가 "지원되는" 것으로 간주될 수 있는 배포가 있을 수 있는지 물어봐야 합니다. 스택의 일부가 항상 지원이 종료된 상태라면, 전체 스택이 지원되지 않는 것입니다. 어떤 이유로든 지원이 거부될 수 있는 이유가 항상 존재합니다. 따라서 모범 사례를 피하도록 요구하는 바로 그 이유가 처음부터 소프트웨어 자체를 선택하지 말아야 할 이유가 됩니다.

업계 기술과 지식이 부족한가?

이런 종류의 소프트웨어 지원 문제로 우리가 직면하는 문제는 소프트웨어를 만드는 팀이 단순히 좋은 소프트웨어가 어떻게 만들어지는지 그리고/또는 좋은 시스템이 어떻게 배포되는지 모르기 때문일 수 있습니다. 이것은 우리를 이런 상황으로 몰아가는 가장 합리적이고 타당한 이유 중 하나입니다. 하지만 다른 가설들과 마찬가지로, 이는 소프트웨어의 품질과 지원이 진정으로 가능한지에 대한 우려를 남깁니다. 시스템에서 가장 눈에 잘 띄는 부분을 제대로 처리하는 것을 벤더에게 신뢰할 수 없다면, 우리가 검증할 수 없는 부분에 대해 왜 그들을 전문가로 신뢰하겠습니까?

핵심 문제

의심스러운 배포 및 유지 관리 관행을 요구하면서 그 대가로 보류된 지원을 제공하는 소프트웨어의 가장 큰 포괄적인 문제는, 우리가 일반적으로 가정하는 전반적인 소프트웨어 품질의 문제가 아니라, 실행 가능한 지원 및 개발 관행의 문제입니다. 이러한 문제들이 장기적인 지원에 대한 심각한 우려를 시사한다는 점은, 처음부터 우리가 강한 지원을 기대하면서 이러한 패키지를 선택하는 이유를 강하게 의심하게 만들어야 합니다. 시작부터 매우 가시적이고 매우 심각한 우려가 있기 때문입니다.

물론 필요를 채울 다른 소프트웨어 제품이 존재하지 않거나 더 합리적으로 실행 가능한 제품이 없는 경우가 있습니다. 이런 상황은 극히 드물어야 하며, 그런 상황이 존재한다면 특정 영역에 진입하려는 벤더에게 주요 시장 기회로 봐야 합니다.

비즈니스 관점에서, 기술 인프라 모범 사례가 다른 상황에서라면 무모하거나 비전문적인 것으로 간주될 벤더 요구 사항을 맹목적으로 또는 거의 맹목적으로 따르는 것과 교환되어 완전히 무시되어서는 안 됩니다. 우리는 왜 이런 방식으로 비즈니스가 의존하는 핵심 제품에 탁월함을 요구하는 것을 자주 소홀히 하는 걸까요? 이것은 행동 자체로부터만이 아니라, 그런 요구 사항이 존재한다는 것이 암시하는 위험으로부터도 비즈니스를 위험에 빠뜨립니다.