API의 폭발적이고 확장적인 사용은 헤드리스 아키텍처의 부상에 기여하고 있으며, GraphQL은 이러한 신현대 애플리케이션 아키텍처에서 중요한 위치를 차지하고 있습니다.
20년 넘게 앱 아키텍처의 패러다임이 크게 바뀌면서 앱 제공 방식이 발전하는 데 직접적인 영향을 미쳤습니다. 역사적으로, 시장을 지배하고 영향을 미칠 운명의 애플리케이션 아키텍처가 5년마다 부상하여 시장을 형성하기 시작하고 그로부터 약 5년 후에 지배적인 아키텍처가 되는데, 이로 인해 앱 제공 시장이 변화하게 됩니다.
마이크로서비스(클라우드 기반)는 2015년에 시장 점유율을 늘렸지만, 서비스 메시와 유입 제어가 확산되면서 앱 제공 환경의 방향이 결정된 것은 2020년이 되어서였습니다. 우리는 이제 앱 제공의 원동력으로 마이크로서비스를 대체할 새로운 아키텍처인 헤드리스가 부상하는 조짐을 보고 있습니다.
역사적 추세에 따르면, 헤드리스 아키텍처는 2025년까지 시장 마인드셰어에 도달하고 앱 제공 시장에 변화를 주도할 것으로 예상됩니다. 이러한 사이클의 안정성은 API와 그래프 기술과 관련된 시장의 활동과 관심이 증가함에 따라 2030년까지 앱 배포에 상당한 영향을 미칠 것으로 예상됩니다.
앱 제공 방식에 있어서 다음의 큰 변화를 가져올 두 가지 기술 트렌드의 융합을 주도하는 몇 가지 외부 요인이 있습니다. API 우선 디자인 과 데이터의 민주화 .
비즈니스를 디지털화하려는 노력은 ' 디지털 기업 '이 제공하는 ' 디지털 서비스 '로 나타납니다. 디지털 서비스는 앱, 앱 전송, 앱 보안, 데이터로 구성된 일시적인 비즈니스 구성 요소로, API를 사용하여 통합, 조율, 운영됩니다. 오늘날 조직의 82%가 내부 및 외부 소비자에게 모두 디지털 서비스를 제공합니다 (SOAS 2022 ).
동시에, 주로 API를 통해 통신하는 마이크로서비스의 도입도 꾸준히 증가했습니다. 우리의 자체 조사에 따르면 "오늘날 공개 및 비공개 API의 수는 2억에 가까워지고 있으며 2031년까지 그 수는 수십억에 달할 수 있다"고 추정합니다.
추세: 결과적으로, 성숙한 앱 전송 시장에 혼란을 일으킬 정도로 API로의 전환이 일어날 것이며, 이는 2010년에서 2020년 사이에 모바일과 마이크로서비스가 앱 전송 시장을 혼란에 빠뜨린 것과 같은 방식입니다.
|
|
분산화는 원격 작업, 대규모 IoT 도입, 데이터 개인 정보 보호에 대한 우려로 인해 발생하는 분산된 디지털 활동의 결과입니다. 분산화는 종종 블록체인이나 엣지 컴퓨팅과 같은 Web3 기술과 연계되며, 특히 산업용 IoT에 적용될 때 더욱 그렇습니다. 그러나 분산화의 결과는 실제로 혼란을 야기합니다. 데이터와 애플리케이션은 모두 '분산'되므로 분산 시스템에서 예상되는 성능 및 보안 문제가 발생합니다. 여기에는 엣지에서 데이터 처리 및 디지털 프런트 엔드 워크로드를 배포하려는 조직의 77%가 포함됩니다( SOAS 2022 ).
경향: 분산화는 데이터를 분산하는 기능을 포함하기 때문에 분산된 애플리케이션에만 영향을 미치는 것이 아닙니다. 기존 접근 방식에서는 데이터를 애플리케이션 뒤의 보호된 계층으로 분류합니다. 분산화는 중개자(애플리케이션)를 필요로 하지 않고 API를 통해 데이터가 직접 노출되는 새로운 접근 방식을 강요합니다. 이러한 전환을 통해 애플리케이션 아키텍처에 대한 계층 기반 접근 방식이 사라지고 외부 파트너, 타사 개발자 및 소비자에게 데이터에 직접 접근할 수 있는 경로가 제공됩니다. 애플리케이션 아키텍처 내에서 작업 부하의 민주화가 시작된 것은 마이크로서비스 아키텍처에서 확인할 수 있습니다. 또한 우리는 역전에 의존하는 비즈니스 모델에서 데이터를 민주화하는 데 따른 현존하는 비즈니스 가치를 확인합니다. 즉, API를 통해 데이터를 공개하여 파트너와 타사 개발자에게 가치를 창출하는 것입니다.
또한 우리는 역전에 의존하는 비즈니스 모델에서 데이터를 민주화하는 것의 현존하는 비즈니스 가치를 확인합니다. 즉, API를 통해 데이터를 공개하여 파트너와 타사 개발자에게 가치를 창출하는 것입니다.
디지털화로 인해 시장에 존재하는 것보다 더 많은 엔지니어링 인재에 대한 수요가 늘어나고 있습니다. 이로 인해 기업은 디지털 비즈니스에서 생성된 방대한 양의 데이터를 활용할 수 없게 됩니다. 존재하는 인재는 과잉 공급되어 있고 종종 기업의 요구에 맞춰 빠르게 개발할 수 없습니다.
이러한 공급과 수요의 격차로 인해 로우코드/노코드 솔루션이 급증하여 더 많은 사용자가 솔루션과 서비스를 개발할 수 있게 되었습니다. 연구 에 따르면 기업의 75%가 "로우코드/노코드와 기존 혁신의 혼합"을 채택할 것으로 나타났습니다.
경향: 로코드/노코드 솔루션은 비즈니스 로직과 데이터에 대한 액세스를 필요로 하며, 둘 다 데이터의 민주화와 API 우선 설계를 통해 광범위하게 제공됩니다. 이러한 솔루션에 대한 필요성은 데이터와 API 트렌드의 성숙을 가속화하는 역할을 합니다.
API(라우터, 게이트웨이, 미들웨어)와 관련된 시장에서 사용되는 언어는 마이크로서비스, 모바일, 아키텍처 변경으로 인해 시장이 변화하기 전에 사용된 언어와 유사합니다. API 생성의 활동, 용어, 속도는 이러한 변화가 앱 제공 및 보안 시장에 상당한 영향을 미칠 것임을 시사합니다.
우리는 이미 API 관찰, 보안, 위협 인텔리전스 및 연합에 초점을 맞춘 제품과 서비스의 형태로 업계에서 API 기반 혁신이 시작되는 것을 보고 있습니다.
이러한 변화는 진공상태에서 일어나지 않습니다. 실제로, 마이크로서비스로 인한 앱 전송 방식의 변화는 주로 Kubernetes의 광범위한 채택과 앱 전송 기술에서 기존에 제공하던 기능(예: 인그레스 컨트롤러(L7 라우팅))을 직접 통합하려는 구조적 결정에 기인합니다.
API 전환도 다르지 않으며, 최근 추세는 이러한 전환이 GraphQL의 부상을 촉진할 것임을 시사합니다. GraphQL은 데이터와 더 직접적으로 상호 작용하고 REST 기반 솔루션으로 성능 문제를 해결하는 API를 설계하는 접근 방식이며, 더 중요한 것은 앱 제공 기능을 핵심 기능 세트에 통합할 것입니다.
API의 우세는 분석가들이 "헤드리스 아키텍처"라고 부르는 것을 주도하고 있습니다. 즉, 전통적인 표현 계층 없이 API로 노출되는 비즈니스 역량과 기능입니다. 이 아키텍처는 종종 시장에서 떠오르고 있는 또 다른 왁싱 기술 트렌드인 '구성 가능한 애플리케이션'의 맥락에서 논의됩니다.
API는 큰 노력 없이도 쉽게 사용자 정의가 가능한 구성 가능한 논리를 제공하는 실용적인 방법이기 때문에 헤드리스 아키텍처는 로코드/노코드 솔루션에 대한 필요성을 해결하는 데 적합합니다. 헤드리스 아키텍처는 다양한 애플리케이션, 서비스, 시스템에서 디지털 서비스를 구성해야 하는 필요성을 충족시키며, 주로 API 중심의 IoT 시장에서 이미 입증되었듯이 분산된 작업 부하를 통합하는 매우 실용적인 방법입니다.
따라서 앱 제공 및 보안 기술의 다음 변화는 API에 의해 주도될 것이며, 이를 통해 헤드리스 아키텍처가 주류로 자리 잡을 것이라고 말하는 것이 타당할 듯합니다.
가장 큰 영향은 API 전달과 보안 서비스에 미칠 것입니다. 시장에서는 오랫동안 API를 단순히 웹앱 제공 및 보안의 특수한 사용 사례로 취급해 왔습니다. 이러한 변화는 API가 기존 수단으로는 해결할 수 없는 특정 제공 및 보안 요구 사항을 지닌 별개의 개체라는 현실을 드러낼 것입니다. 이는 API를 통해 직접 노출되는 데이터 서비스의 영향을 살펴볼 때 특히 그렇습니다. 역사적으로 대부분의 데이터는 애플리케이션을 통해서만 노출되었습니다. API를 통한 직접 노출은 그 자체로 상당한 변화이지만, API가 더 이상 웹앱의 하위 집합이 아니라 그 자체로 개별적인 아키텍처 구성 요소인 이유를 완벽하게 보여줍니다.
앱 아키텍처의 이러한 변화는 역사적으로 API 접근 방식도 변화하는 시점에 발생하고 있으며, 일반적으로 API 사용 방식에 대한 대응으로 변화합니다. 모든 API는 궁극적으로 데이터를 교환하는 데 사용되지만, 시간이 지남에 따라 애플리케이션 아키텍처의 제약과 기능을 반영하여 해당 데이터의 유형과 형식이 변경됩니다. 예를 들어, 더 빈번한 데이터 교환에 대한 필요성과 모바일 플랫폼의 감소된 컴퓨팅 성능에 대한 대응으로 REST와 JSON이 인기를 얻었고, 모바일과 마이크로서비스로의 전환도 이루어졌습니다. SOAP와 XML은 광범위한 구문 분석이 필요하고 과도한 대역폭을 소모합니다. REST와 JSON은 기존 HTTP 구조를 활용하여 엔드포인트를 설명하고 JSON에서 더 간단한 데이터 형식으로 전환함으로써 부담을 줄였습니다.
SOAP/XML과 REST/JSON은 모두 전통적인 개발자 기술이 필요하지만, 개발자 기술이 거의 필요하지 않은 로코드/노코드로의 추세가 나타나고 있습니다. GraphQL은 비개발자를 대상으로 한 간단한 쿼리 언어로, 간단한 툴과 매우 밀접하게 관련되어 있어 더 광범위한 사용자가 사용할 수 있습니다. 이를 통해 API는 모든 종류의 디지털 서비스로 접근 및 구성이 가능해집니다. 이는 아키텍처가 API 전용(헤드리스)으로 이동함에 따라 REST/JSON을 완벽하게 대체하게 됩니다.
GraphQL은 API 확산 문제와 SOA(서비스 지향 아키텍처)에서 REST로의 전환을 촉진한 것과 동일한 성능 문제를 해결하는 현재 가장 선호되는 솔루션입니다. GraphQL은 사양 의 이점도 가지고 있는데, 이는 인재 부족으로 인한 문제를 해결하는 로우코드/노코드 솔루션 개발을 촉진하는 데 도움이 됩니다.
마지막으로 GraphQL은 API를 쿼리하고 오늘날 대부분의 데이터 저장소는 API를 지원하므로 GraphQL 기반 솔루션은 애플리케이션의 "중간자"를 효과적으로 제거하고 데이터 소스 자체로 직접 이동할 수 있습니다. 이 기능은 원격 위치에 있는 데이터에 빠르고 직접 액세스해야 하는 분산 애플리케이션에 특히 유용합니다.
이를 통해 GraphQL은 헤드리스 아키텍처에 대한 "게이트웨이" 역할을 할 수 있는 좋은 위치에 놓이게 되며, 이는 인그레스 컨트롤러가 마이크로서비스 아키텍처에 대한 "게이트웨이" 역할을 하게 된 것과 같은 방식입니다.
사람들은 변화만이 영원하다고 말하는데, 기술에도 이 말이 맞습니다. 누군가가 게임의 규칙을 바꾸기 전까지 우리가 몇 년 이상 가만히 있는 경우는 거의 없습니다. 앱 제공 및 보안 분야에서 이러한 규칙은 부분적으로 애플리케이션 아키텍처에 의해 정의됩니다. 따라서 앱 제공 및 보안이 진화하도록 강제하는 기능 없이는 애플리케이션 아키텍처에 큰 변화가 발생하지 않습니다.
이런 변화가 이루어지려면 아직 몇 년이 남았지만 GraphQL과 API와 같은 기술이 인프라부터 엣지, 앱 제공에 이르기까지 모든 것에 얼마나 큰 영향을 미치고 있는지 이미 알 수 있습니다.
헤드리스 아키텍처가 부상하고 있으며 GraphQL이 중요한 역할을 할 것입니다.