공유하되 노출하지 않기: 테스트 클라우드의 새로운 정의

디바이스 클라우드의 진화: 퍼블릭에서 프라이빗, 그리고 공유로

제품 관리자로서 저는 관리 기능을 제공하는 책임을 맡고 있습니다. Digital.ai 테스트 플랫폼에서 저는 인프라를 특정 관점, 즉 가용성과 제어 사이의 균형이라는 관점에서 바라봅니다. 제 역할인 클라우드 관리자는 마치 문지기와 같습니다. 관리자는 리소스를 할당하고, 사용자 권한을 관리하며, 무엇보다 테스트 팀이 필요로 할 때 리소스를 사용할 수 있도록 보장합니다.

지난 몇 년 동안 우리 업계는 많은 변화를 겪었습니다. 물리적 하드웨어에 대한 완벽한 통제에서 퍼블릭 클라우드의 엄청난 유연성으로 옮겨갔죠. 하지만 어느 극단적인 방식도 근본적인 문제를 해결하지는 못했습니다. 오늘 우리는 업계가 오랫동안 받아들여 온 잘못된 이분법에 도전하는 새로운 방향을 모색하고 있습니다.

미래는 "봉쇄"와 "모두에게 개방" 사이에서 선택하는 문제가 아닙니다. 미래는 제3의 상태에 관한 것입니다. 공유 인스턴스

우리가 어떻게 여기까지 오게 되었는지, 그리고 왜 이러한 차이점이 대부분의 판매자들이 인정하고 싶어하는 것보다 훨씬 더 중요한지 보여드리겠습니다.

1단계: "하드웨어 밀착형" 시대 (사내 구축 및 온프레미스 구축)

우리 모두 전통적인 모델을 기억합니다. 사내 기기 연구실, 책상 위를 어지럽히는 USB 케이블, 6개월마다 교체해야 하는 부풀어 오른 모바일 기기 배터리, 오후 내내 걸리던 수동 OS 업데이트, 그리고 다른 모든 기기가 고장 났을 때도 어떻게든 작동하는 아이폰 6까지.

문제를 일으키는 장치를 직접 손으로 잡을 수 있다는 점에서 실질적인 제어력이 만족스러웠다. 하지만 운영 부담은 엄청났다.

특히 금융 및 방위 산업 분야와 같이 보안을 중시하는 고객을 위해 온프레미스 및 에어갭 솔루션이 정식으로 개발되었습니다. 이러한 구성에서는 인프라가 완전히 격리되어 데이터에 대한 완벽한 통제가 유지됩니다.

기기는 공용 인터넷에 절대 연결되지 않습니다. 테스트 데이터는 건물 밖으로 절대 유출되지 않습니다.

이것이 나타난 이유는 무엇일까요?

금융 데이터를 처리하는 은행 앱, 환자 기록을 관리하는 의료 앱, 기밀 정보를 다루는 정부 앱. 이러한 앱들은 다른 회사의 테스트가 몇 시간 전에 동일한 기기를 사용했을 가능성이 있는 인프라에서는 실행될 수 없습니다.

업계의 답변은 간단했습니다. "이 장치들은 오직 당신만의 소유이며, 당신의 환경에 격리되어 있습니다. 다른 누구도 만지지 않습니다."

이것은 실제적인 필요를 해결했습니다.

• 규제 대상 또는 기밀 정보를 처리하는 애플리케이션의 장치 및 데이터의 완벽한 격리
• 내부 보안, 네트워크 및 규정 준수 요구 사항에 맞춘 맞춤형 인프라 구성
• 공유 공공 자원에 의존하지 않고 데이터의 상주성과 주권을 보장합니다.
• 공용 인터넷에 전혀 연결할 수 없는 환경을 위한 에어갭 구축

이로 인해 발생한 문제

하지만 제가 이러한 환경을 관리하면서 관찰한 바는 다음과 같습니다. 이는 보안 문제를 해결했지만 새로운 문제, 즉 경제적인 문제를 야기했습니다.

• 높은 총 비용조직들은 인프라 유지 관리에 상당한 시간, 자원 및 비용을 투자하고 있었습니다.
• 새로운 기기에 대한 접근 속도가 느립니다.저는 고객들이 아이폰 15 출시 후 3개월 동안 테스트를 기다려야 하는 것을 지켜봤습니다. 구매는 경영진의 승인을 받아야 했고, 구매 부서에서 주문해야 했으며, IT 담당자는 기기를 설정하고 연구실에 추가해야 했습니다. 그동안 고객들의 앱 사용자들은 이미 최신 아이폰에 앱을 다운로드하고 있었습니다.

온프레미스 방식은 기업에 필요한 보안을 제공했지만, 시장 세분화 속도에 맞춰 디바이스 커버리지를 확장하기에는 비용이 너무 많이 들었습니다.

하지만 정말 민감한 워크로드의 경우, 이러한 원칙은 여전히 ​​유효합니다. 에어갭 방식과 온프레미스 솔루션은 사라지지 않을 것이며, 기밀 데이터나 법적으로 제한된 시나리오에는 필수적입니다. 그러나 모든 테스트 요구 사항에 대한 기본 해결책이 되어서는 안 됩니다.

2단계: SaaS 포크(퍼블릭 클라우드 vs. 전용 클라우드)

시장이 SaaS로 전환되면서 두 가지 양자택일의 양상이 나타났습니다. 하지만 이 두 가지 방식 모두 보안, 서비스 범위, 비용의 균형을 맞추려는 현대 기업 클라우드 관리자의 요구를 완벽하게 충족시키지는 못합니다.

옵션 1: 퍼블릭 클라우드

공용 기기 클라우드는 개발자들이 사용자들이 소유한 모든 기기를 구매할 여력이 없어 경제적으로 불가능해지는 문제에 대한 최초의 해결책으로 등장했습니다.

기기는 선착순으로 동적으로 할당되며, 제어 권한은 제한적이고 플랫폼의 모든 고객이 공유합니다.

이것이 나타난 이유는 무엇일까요?

2010년대 초반, 모바일 시장의 파편화가 극심해졌습니다. 안드로이드는 분기마다 수십 개의 새로운 기기를 출시했고, iOS는 매년 새로운 모델을 추가했습니다. 대기업을 제외한 대부분의 기업에게는 물리적 기기에서 앱을 수동으로 테스트하는 것이 경제적으로 불가능해졌습니다.

공용 클라우드는 획기적인 변화를 가져왔습니다. 하드웨어를 구매하지 않고도 수백 대의 기기에 즉시 접근할 수 있게 된 것입니다.

사용한 만큼만 지불하세요. 설정이 필요 없습니다. 클릭하고 바로 테스트하세요.

스타트업과 빠르게 성장하는 개발팀에게 이는 혁신적인 변화였습니다.

이것은 실제적인 필요를 해결했습니다.

• 물리적 장치 실험실을 구매하고 유지 관리할 필요성을 없앴습니다.
• 설정이나 인프라 계획 없이 신속하고 온디맨드 방식의 검증이 가능합니다.
• 예산이 제한적인 경우에도 다양한 기기를 경제적으로 이용할 수 있도록 했습니다.

드러난 한계점

하지만 기업들이 이러한 플랫폼을 도입하면서 고객과의 대화에서 반복적으로 들었던 문제점들이 드러났습니다.

• 제한된 통제"저희 애플리케이션은 내부 환경에 연결하기 위해 특정 VPN 및 네트워크 구성이 필요합니다. 공용 클라우드 장치는 이러한 구성을 지원하지 않는 표준 네트워크 설정을 사용합니다."
• 가용성 문제"애플이 새로운 아이폰을 출시하면 수요가 순식간에 급증합니다. 중요한 테스트 기간 동안에는 대기줄에 서서 기다려야 하는 상황이 발생하죠."
• 규정 준수 격차"저희 보안팀에서 아키텍처를 검토한 결과 거부했습니다. 민감한 금융 데이터를 처리하는 애플리케이션에는 다중 테넌트 공용 인프라가 적합하지 않습니다."

퍼블릭 클라우드는 모바일 테스트를 보편화했지만, 기업의 보안 및 제어 요구 사항을 충족하도록 설계된 것은 아닙니다.

옵션 2: 전용 클라우드

보안상의 허점을 해결하기 위해 업계는 전용(프라이빗) 클라우드 서비스를 표준화했습니다. 이는 디바이스가 한 고객만을 위해 예약되는 단일 테넌트 환경입니다.

단일 고객 전용으로 예약된 장비로, 실험실 인프라를 관리할 필요 없이 완벽한 제어 기능을 제공합니다.

이것은 실제적인 필요를 해결했습니다.

• 귀사 전용의 프라이빗 단일 테넌트 클라우드 환경에 액세스할 수 있습니다.
• 완벽한 격리를 통해 보안 및 규제 요건을 충족하십시오.
• 장치 및 구성에 대한 완벽한 제어 권한을 유지하여 테스트 시나리오를 최적화하십시오.
• 실험실 유지 관리, 업그레이드 및 IT 관리와 관련된 운영 비용을 절감하십시오.
• 이로써 기업은 필요한 보안 태세를 갖추게 되었지만, 온프레미스 솔루션의 경제적 문제점 일부를 그대로 물려받게 되었습니다.

드러난 한계점

• 전용 장비의 지속적인 비용으로 인해 장비 다양성이 제한되고 테스트 범위가 불완전해집니다.
• 특히 사전 출시 테스트나 기기별 디버깅과 같은 성수기 동안 기기 할당이 제한되면 테스트 유연성이 떨어지고 출시가 지연될 수 있습니다.

단절: 고객이 실제로 필요로 했던 것

그때 우리에게는 두 가지 극단적인 선택지가 있었다.

• 공공 영역저렴하고 접근성이 좋으며 다양한 기기를 지원하지만, 보안 문제와 제한적인 제어 기능이 단점입니다.
• 고객에게 기여안전하고 통제가 잘 되며 규정을 준수하지만, 비용이 많이 들고 기기 종류가 제한적입니다.

하지만 고객들과 직접 만나 실제 테스트 워크플로에 대해 물어보니, 그들이 제시하는 요구사항은 어느 극단적인 경우에도 해당하지 않았습니다.

"저희 CI/CD 파이프라인은 매시간 50개 기기에서 기능 테스트를 실행합니다. 이러한 테스트는 VPN 구성이 적용된 사설 네트워크에서 빠르게 실행되고, 테스트 스위트 전반에 걸쳐 기기 설정을 재사용할 수 있어야 합니다. 퍼블릭 클라우드는 이러한 요구 사항을 지원하지 않으며, 전용 기기는 확장성이 떨어지고 비용이 너무 많이 듭니다."

"실제 고객 데이터를 사용한 프로덕션 테스트에는 전용 기기를 사용합니다. 하지만 개발 단계에서는 팀이 다양한 기기에서 버그 수정 사항을 신속하게 검증하기만 하면 됩니다. 전용 리소스가 필요한 것이 아니라, 광범위한 기기 환경에서 테스트가 가능해야 합니다."

패턴은 분명했다. 고객들은 공공 부문과 전용 부문 사이의 무언가를 필요로 했습니다..

그들에게는 다음이 필요했습니다:

• 온디맨드 방식으로 기기에 접근할 수 있는 공유 인프라 경제성
• 퍼블릭 클라우드와 유사한 광범위한 기기 및 운영체제 지원
• 기업 수준의 보안 및 격리 기능을 제공하면서도 기기 소유권을 독점할 필요는 없습니다.
• VPN 및 사이트 간 구성을 포함한 완벽한 네트워크 제어
• 대규모 테스트 스위트를 안정적으로 실행할 수 있으며, 실행 간 설정이나 해제 과정으로 인한 중단이 없습니다.

업계는 이 문제를 양자택일의 문제로 규정해 왔습니다. 하지만 그러한 관점은 잘못되었고, 바로 그 지점에서 우리는 다른 방식을 구축하기 시작했습니다.

3단계: 프라이빗 클라우드의 공유 장치 - 제3의 방식

여기는 Digital.ai 지원 지난 몇 년간 혁신에 집중해 왔습니다. 단순히 남들과 다르기 위해서가 아니라, 고객이 실제로 필요로 하는 것에 귀 기울이고 그 필요를 충족시키고자 노력했기 때문입니다.

이게 무슨 뜻이야

기기는 선착순으로 동적으로 할당되지만 공용 기기에 비해 제어 및 유연성이 뛰어납니다. 대규모 테스트 스위트 실행, 특정 구성(예: 전용 기기와 동일한 VPN 구성 사용) 및 중단 없는 사용이 필요한 경우에 적합합니다.

공유 환경의 경제성과 개인 환경의 보안성을 동시에 누릴 수 있습니다.

이것이 나타난 이유는 무엇일까요?

이 모델이 가능하고 필수적인 이유가 된 데에는 세 가지 요인이 복합적으로 작용했습니다.

1. 클라우드 보안 기술이 성숙해졌습니다.

프라이빗 클라우드 아키텍처가 발전하여 멀티테넌트 인프라 내에서 진정한 격리를 구현할 수 있게 되었습니다. 기본 클라우드 인프라는 공유되지만, 사용자의 장치, 네트워크 구성 및 데이터는 다른 고객과 완전히 분리되어 유지됩니다.

2015년에는 이 정도의 격리 수준을 안정적으로 달성하는 것이 불가능했습니다. 하지만 이제는 기업 클라우드 아키텍처에서 표준이 되었습니다.

2. 비용 압박 심화

팀들은 더 나은 활용 경제성을 유지하면서도 동일한 보안 보장을 원했습니다. "보안상 필요하기 때문입니다"라는 기존의 답변은 더 이상 만족스럽지 못했습니다.

3. 테스트 요구사항의 다양화

오늘날 팀은 한 가지 유형의 테스트만 수행하는 것이 아니라, 각각 다른 요구 사항을 가진 여러 워크로드를 수행합니다.

• 실제 고객 데이터를 활용한 고보안 운영 환경 테스트 (전담 인력 필요)
• 합성 데이터를 활용한 대규모 CI/CD 기능 테스트 (독점성보다 규모와 적용 범위를 우선시)
• 수백 가지 기기 및 운영체제 조합에 걸친 광범위한 호환성 테스트 (전용 기기만으로는 경제적으로 실현 불가능함)
• 일상적인 개발 과정에서 버그 수정 사항을 검증합니다(빠른 접근과 다양한 유형의 버그 확인이 필요하며, 가용성이 보장되지는 않습니다).

공공 시설이든 전용 시설이든, 획일적인 인프라는 오늘날 실제로 검사가 이루어지는 방식을 반영하지 못합니다.

이것이 테스트 전략에 미치는 영향은 무엇일까요?

오늘날 디바이스 클라우드 옵션을 평가하고 있다면, "퍼블릭 vs. 프라이빗"이라는 틀 자체를 완전히 버리는 것이 좋을 것입니다. 이는 시대에 뒤떨어진 방식이며, 최신 테스트 방식에 부합하지 않습니다.

대신, 팀의 실제 업무 방식을 바탕으로 결정을 내리세요. 해답을 찾는 데 도움이 되도록 다음과 같은 질문들을 고려해 보세요.

1. 실제 업무량은 어느 정도입니까?

• 모든 워크로드가 민감하거나 규제 대상 데이터를 처리합니까, 아니면 일부 워크로드만 처리합니까?
• 기기 가용성이 항상 보장되어야 합니까, 아니면 특정 시간대에만 보장되어야 합니까?
• 테스트는 장치 구성이 영구적으로 유지되어야 합니까, 아니면 실행할 때마다 깨끗한 환경이 필요합니까?

대부분의 팀은 실제로 이를 파악해 보면 다양한 유형의 사람들이 섞여 있다는 것을 알게 됩니다.

2. 보안 요구 사항에 따라 워크로드를 분리할 수 있습니까?

• 높은 보안 → 전용 SaaS 또는 온프레미스(운영 데이터, 규제 또는 제한된 애플리케이션)
• 중간 보안 → 프라이빗 인스턴스 내 공유 장치 (기능 테스트, CI/CD, 호환성)
• 저보안 → 비공개 인스턴스 내의 공용 또는 공유 장치 (초기 개발, 민감하지 않은 검증)

핵심 요점: 모든 테스트 작업에 최고 수준의 보안 등급이 필요한 것은 아닙니다.

결론: 혁명이 아닌 진화

퍼블릭에서 프라이빗, 그리고 공유로의 진화는 단순히 혁신을 위한 벤더의 혁신에 의해 주도된 것이 아닙니다. 이는 업계가 무시할 수 없었던 고객의 요구와 시장의 힘에 의해 주도된 것입니다.

프라이빗 SaaS 환경 내에서 공유 디바이스가 등장하게 된 이유는 조직들이 무시할 수 없는 경제적 요소, 테스트에 필수적인 다양한 디바이스, 그리고 희생할 수 없는 보안 사이에서 균형을 맞춰야 했기 때문입니다.

At Digital.ai 테스트를 통해 우리는 디바이스 클라우드 인프라의 미래는 단일 배포 모델을 선택하는 것이 아니라, 클라우드 관리자가 실제로 관리할 수 있는 안전하고 규정을 준수하는 환경 내에서 다양한 워크로드에 적합한 계층을 매칭할 수 있을 만큼 유연한 아키텍처를 구축하는 데 있다는 것을 알게 되었습니다.

진정한 질문은 "공공이냐 민간이냐?"가 아니었습니다.

진정한 질문은 "데이터를 노출하거나 예산을 초과하지 않고 테스트 팀에 필요한 테스트 범위를 어떻게 제공할 수 있을까?"입니다.

그것이 바로 "공유하되 노출하지 않는다"는 의미입니다. 그리고 그것이 바로 우리가 만들어가는 미래입니다.