인사이트리포트

들어가며: kubernetes 네트워킹의 현주소

kubernetes는 현재 클라우드 네이티브 컴퓨팅의 표준 플랫폼으로 확고히 자리 잡았다. 2024년 발표된 CNCF(Cloud Native Computing Foundation) 연례 조사에 따르면, 93%의 조직이 kubernetes를 사용하거나 검토 중인 것으로 나타나며 80%의 조직은 운영 환경에서 kubernetes를 사용하고 있는 것으로 조사되었다. 거대한 kubernetes 생태계에서 클러스터 외부 트래픽을 내부 서비스로 연결하는 ‘Ingress’는 클러스터의 네트워킹 인프라에서 가장 중요한 구성 요소 중 하나로, 외부 사용자가 kubernetes 기반 애플리케이션과 서비스에 접근할 수 있도록 하는 핵심 역할을 수행해왔다.

수많은 Ingress 컨트롤러 구현체 중에서, kubernetes/ingress-nginx 프로젝트는 kubernetes 프로젝트 초창기부터 존재했던 예시 구현체였다. 특정 클라우드 벤더에 종속되지 않는 유연성, 풍부한 기능, 그리고 광범위한 커뮤니티 사용률 덕분에 생태계의 ‘기본값’과 같은 위치를 차지해왔다.

이러한 배경 속에서, 2024년 11월 KubeCon North America에서 프로젝트 종료 계획이 발표되고 2025년 11월 11일 공식 지원 종료가 최종 확정된 kubernetes/ingress-nginx는, 전 세계 kubernetes 운영 환경에 즉각적인 아키텍처 재설계를 요구하는 중대한 전환점이 되었다. 이는 단순히 하나의 도구가 사라지는 차원을 넘어, 보안 구조의 근본적 취약점(스니펫 등)을 안고 있던 기존 Ingress 모델의 한계가 임계점에 달했음을 시사하며, 차세대 표준인 gateway api로의 강제적 이동을 알리는 결정적 신호탄이다.

본 글에서는 kubernetes를 도입했거나 도입하려는 조직들에게 Ingress NGINX 프로젝트의 공식적인 종료 소식과 함께, Ingress의 근본적인 한계와 차세대 표준인 Gateway API의 핵심 개념을 구체적으로 설명한다. 또한 이 변화에 대응하기 위한 실질적인 단기 및 장기 전략을 제시하여, 기술 의사결정자들이 정보에 입각한 아키텍처 로드맵을 수립하는 데 필요한 구체적 방향성을 제공한다.

Ingress NGINX의 공식 지원 종료: 배경과 영향

Kubernetes 네트워킹의 핵심 구성요소였던 kubernetes/ingress-nginx 프로젝트가 공식적으로 지원 종료를 선언했다. 이 지원 종료 결정에 이르기까지는 복잡한 과정이 있었다.

지원 종료 결정의 시간적 경과

2024년 11월 KubeCon North America: 당시 메인테이너들(James Strong, Marco Ebert)은 “Securing the Future of Ingress-Nginx” 세션에서 프로젝트 종료 계획을 발표하고, 새로운 기능 개발을 중단하며 대체 프로젝트 개발에 집중하겠다고 밝혔다. 이는 완전한 지원 종료가 아닌, 새로운 기능 개발을 중단하고 보안 패치와 버그 수정만 제공하는 유지보수 모드로의 전환이었다. 동시에 Kubernetes Gateway API를 구현하는 차세대 프로젝트 InGate (In-cluster Gateway)를 공개하며, 모든 개발 역량을 해당 프로젝트로 집중하겠다고 발표했다.

2025년 11월 현재: InGate 프로젝트가 성숙한 대체재를 만드는 데 필요한 수준에 도달하지 못하면서, Kubernetes SIG Network와 보안 대응 위원회는 kubernetes/ingress-nginx의 완전한 지원 종료를 최종 결정했다.

명확한 지원 종료 일정

현재 확정된 지원 종료 일정은 명확하게 제시되었으며, 모든 사용자는 즉각적인 대응 계획을 수립해야 한다.

• 최선 노력 유지보수 종료: 2026년 3월부로 모든 최선 노력 기반의 유지보수가 중단된다.
• 지원 중단: 이 시점 이후, 어떠한 추가 릴리스, 버그 수정, 그리고 새롭게 발견되는 보안 취약점에 대한 패치도 제공되지 않는다.
• 영향: 기존에 배포된 ingress-nginx가 2026년 3월에 즉각 중단되는 것은 아니다. Helm 차트나 컨테이너 이미지 같은 기존 아티팩트는 계속 사용 가능하다. 하지만 이는 사실상 보안 위협에 무방비로 노출되는 ‘시한부’ 상태가 되었음을 의미하며, 프로덕션 환경에서는 용납하기 어려운 심각한 리스크를 안게 된다.

지원 종료의 공식적 사유

이번 지원 종료 결정은 단일한 원인이 아닌, 복합적인 문제들이 누적된 결과다. 공식 발표에 따르면, 주요 사유는 다음과 같다.

1. 지속 불가능한 유지보수 구조: ingress-nginx는 Kubernetes 생태계에서 가장 인기 있는 프로젝트 중 하나였지만, 그 인기는 ‘사용’에만 집중되었을 뿐 ‘기여’로 이어지지 못했다. 수년 동안 이 프로젝트는 단 한두 명의 핵심 개발자가 개인 시간을 할애하여 유지보수하는 불안정한 구조에 의존해왔다. 이는 오픈소스 생태계가 직면한 ‘공유지의 비극’ 문제를 여실히 보여준다.

2. 극복 불가능한 기술 부채: ingress-nginx의 가장 강력한 기능이자 가장 치명적인 약점은 ‘스니펫(snippets)’ 어노테이션이었다. 이 기능은 사용자가 임의의 NGINX 설정을 컨트롤러에 직접 주입할 수 있게 하여 상당한 유연성을 제공했다. 하지만 바로 이 ‘유연성’이 컨트롤러의 유효성 검사 로직을 우회하여 심각한 보안 결함을 유발할 수 있는 통로가 되었다. 이 기능은 프로젝트가 더 이상 책임질 수 없는 기술 부채로 간주되었으며, 이는 표준 API가 얼마나 중요한지를 보여준다.

3. 대체 프로젝트의 실패: 2024년 KubeCon NA에서 차세대 컨트롤러로 기획되었던 ‘InGate’ 프로젝트가 성숙한 대체재를 만드는 데 충분한 진척을 보이지 못하고 중단되면서, 원래 계획했던 점진적 전환이 불가능해졌다. 이로 인해 ingress-nginx는 대안 없이 완전한 지원 종료의 길을 걷게 되었다.

결과적으로 SIG Network와 보안 대응 위원회는 생태계 전체의 안전과 사용자 보호를 최우선으로 고려하여, 더 이상 지속 가능하지 않은 이 프로젝트의 공식적인 지원 종료를 결정했다. 이는 2024년 당시의 점진적 전환 계획이 실패한 후 내린 최종 결정으로, 사용자들에게 대안 솔루션으로의 마이그레이션을 강력히 권고하고 있다.

Ingress의 개념적 한계와 Gateway API의 대두

ingress-nginx의 지원 종료는 개별 프로젝트의 문제를 넘어, Ingress API 자체가 태생적으로 가진 근본적인 한계에서 비롯되었다. Ingress API는 Kubernetes 네트워킹의 표준을 제시했지만, 현대적인 클라우드 네이티브 환경의 복잡성을 감당하기에는 역부족이었다.

Ingress API의 본질과 한계

Ingress API는 L7 HTTP/HTTPS 트래픽을 Kubernetes 서비스로 라우팅하기 위한 표준 리소스다.
그러나 이 표준은 너무 단순했다. 현업에서 필수적으로 요구되는 고급 기능들을 지원하지 않았고, 이는 Ingress API의 치명적인 한계로 작용했다.

1. 기능의 빈곤함과 ‘어노테이션 과부하’: Ingress API 표준 사양은 호스트명, 경로, TLS 인증서 기반의 기본 라우팅만 지원한다. 현업에서 필수적으로 요구되는 트래픽 분할, URL 재작성, 인증, 속도 제한 등의 고급 기능들은 표준에 존재하지 않았다. 예를 들어, 기본적인 Ingress 리소스는 다음과 같이 단순한 구조만 지원한다:

하지만 실제 운영 환경에서는 다음과 같은 복잡한 요구 사항이 필요하다:

2. 이식성의 상실: 이 공백을 메우기 위해 각 Ingress 컨트롤러 벤더(NGINX, Kong, Traefik 등)는 자사 제품의 고유한 ‘어노테이션’을 통해 이 기능들을 구현했다. 그 결과, NGINX에서 사용하던 수십 개의 어노테이션은 Kong으로 마이그레이션할 때 작동하지 않았으며, 이는 벤더 종속성을 피하고 이식성을 확보하려는 Kubernetes의 핵심 가치를 훼손했다.

3. 단일 페르소나와 거버넌스 부재: Ingress API는 ‘사용자’라는 단일 페르소나 모델을 가진다. 즉, 하나의 Ingress 리소스 안에 인프라 관리 영역(도메인, TLS 인증서)과 애플리케이션 개발 영역(경로, 백엔드 서비스)의 설정이 혼재되어 있다. 이는 여러 팀이 하나의 클러스터를 공유하는 멀티테넌트 환경에서 심각한 보안 및 거버넌스 문제를 야기한다.

Gateway API의 필요성 및 등장 배경

Gateway API는 Ingress의 이러한 모든 한계를 극복하고 Kubernetes 네트워킹을 ‘차세대’로 이끌기 위해 설계된 새로운 표준 API다. SIG Network는 ingress-nginx 지원 종료 공지에서 모든 사용자에게 Gateway API로의 마이그레이션을 강력히 권고하고 있다.

Gateway API가 Ingress 문제점을 해결한 핵심 개선사항들:

1. 1. 일관된 고급 기능: Gateway API는 트래픽 가중치, 헤더 기반 라우팅, 미러링 등 어노테이션으로 처리하던 기능들을 API 표준 사양의 핵심 필드로 포함시켰다. 예를 들어:
   2. 구조화된 확장성: 벤더들이 고유 기능을 확장할 수 있도록 API 구조 내에 명확하고 일관된 ‘연결 지점’을 제공하여, 어노테이션의 무질서를 해결했다.
   3. 역할 기반 설계: 가장 중요한 혁신으로, 네트워킹 설정을 단일 리소스가 아닌 조직의 역할에 따라 명확하게 분리했다.

Gateway API 핵심 개념: 역할 기반 아키텍처

Ingress의 실패가 기술적 한계 이전에 ‘조직’의 복잡성을 담아내지 못한 ‘설계’의 한계였음을 인식한 Gateway API는, 기술이 아닌 ‘조직’을 모델링하는 데 집중했다. 기업의 ‘플랫폼 엔지니어’와 ‘애플리케이션 개발자’는 원하는 것과 책임지는 영역이 다르다. Gateway API는 이 ‘관심사의 분리’를
API 리소스 모델에 직접 투영했다.

Gateway API는 기존의 단일 Ingress 리소스를 3개의 역할에 맞춘 새로운 리소스 유형으로 분리한다.

1. GatewayClass (인프라 제공자): 클러스터 전체에 어떤 종류의 게이트웨이 구현체(컨트롤러)를 사용할지 정의하는 클러스터 범위의 리소스다.

2. Gateway (클러스터 운영자): 실제 로드 밸런서 인스턴스를 프로비저닝하고, 인프라 영역을 담당한다. 리스너를 통해 어떤 포트와 프로토콜(HTTP, HTTPS, TCP)을 허용할지, 어떤 도메인과 TLS 인증서를 사용할지를 정의한다.

3. Route 리소스 (애플리케이션 개발자): 특정 Gateway에 연결되어, 애플리케이션 서비스로의 상세 라우팅 규칙을 정의한다.

이 구조를 통해 플랫폼팀은 Gateway 리소스를 통해 인프라와 보안 정책을 중앙에서 통제하는 동시에, 애플리케이션 개발팀은 자신의 네임스페이스 내에서 HTTPRoute 리소스를 생성하여 필요한 라우팅 규칙을 자율적으로 관리할 수 있게 된다.

Ingress NGINX 지원 종료에 따른 전략적 대응 방안

ingress-nginx 지원 종료 공지는 모든 사용자에게 “즉시 마이그레이션을 시작할 것”을 권고하고 있다. 현 상황을 진단하고, 조직의 기술 성숙도와 비즈니스 목표에 따라 두 가지 전략 중 하나를 선택해야 한다.

전략 1: Ingress 컨트롤러 교체 (단기 대응 및 현상 유지)

첫 번째 전략은 Ingress API 자체는 유지하되, 지원 종료하는 kubernetes/ingress-nginx를 현재 활발하게 유지보수가 되고 기술 지원을 받을 수 있는 다른 Ingress 컨트롤러로 교체하는 방안이다. 이는 아키텍처 변경을 최소화하며 당면한 보안 리스크를 해결하는 단기 대응 전략이 될 수 있다.

< 대안 1: Istio Ingress Gateway >

Istio는 강력한 서비스 메쉬(Service Mesh) 플랫폼이다. Istio Ingress Gateway는 클러스터 외부의 트래픽을 메쉬 내부로 안전하게 연결하는 게이트웨이로, 데이터 플레인으로 NGINX가 아닌 고성능 Envoy 프록시를 사용한다.

특징:

• 강력한 트래픽 제어: Istio는istio.io API 그룹의 자체 CRD(Gateway, VirtualService)를 통해 강력하고 세밀한 트래픽 제어 기능을 제공한다.
• Gateway API 준수: Istio는Kubernetes Gateway API를 최대한 준수하는 구현체다. 즉, 사용자는 Istio의 고유 CRD인 VirtualService 대신, Kubernetes 표준 HTTPRoute 리소스를 사용하여 Istio 게이트웨이를 제어할 수 있다.
• 서비스 메쉬: Ingress 기능을 넘어, 클러스터 내부의 모든 서비스 간 통신에 대한 상호 TLS 암호화, 서킷 브레이킹, 장애 주입, 그리고 분산 추적을 포함한 완벽한 관찰 가능성을 제공한다.

고려사항: ingress-nginx에서 Istio로의 전환은 단순한 컨트롤러 교체가 아니라, 서비스 메쉬 아키텍처로의 근본적인 전환을 의미한다. 만약 조직의 목표가 단순히 L7 라우팅을 넘어, 클러스터 전체의 제로 트러스트 보안, 모든 마이크로서비스 통신의 완벽한 제어 및 관찰 가능성 확보라면, Istio는 강력하고 포괄적인 솔루션이다.

< 대안 2: Kong Kubernetes Ingress Controller >

Kong은 단순한 Ingress 컨트롤러를 넘어, 강력한 오픈소스 API 게이트웨이(Kong Gateway)를 Kubernetes 네이티브하게 통합한 솔루션이다.

특징

• Ingress 리소스 외에 KongIngress, KongPlugin 등 Kong 고유의 CRD를 통해 Kong Gateway가 제공하는 모든 기능을 Kubernetes 네이티브하고 명시적인 방식으로 관리할 수 있다.
• 인증, 속도 제한, 요청/응답 변조, 로깅 등 수백 개의 강력한 플러그인 생태계를 KongPlugin CRD를 통해 Kubernetes 환경에서 직접 활용할 수 있다.
• Kong Ingress Controller는 Ingress API와 Gateway API를 모두 지원한다. 이는 현재 Ingress를 사용하면서 향후 Gateway API로 점진적으로 전환하려는 조직에게 유연한 아키텍처 경로를 제공한다.

고려사항: 만약 기존 ingress-nginx에서 인증, 인가, 속도 제한 등을 ‘snippets’나 복잡한 어노테이션으로 구현하고 있었다면, 해당 조직은 이미 Ingress를 ‘API 게이트웨이’처럼 사용하고 있었던 것이다. Kong으로의 마이그레이션은 이러한 ‘어노테이션 지옥’을 KongPlugin이라는 명확한 CRD로 대체하고, 단순한 라우팅을 넘어 API 관리의 영역으로 아키텍처를 격상시키는 전략적 업그레이드가 될 수 있다.

< 대안 3: NGINX Inc. Ingress Controller >

이번에 지원 종료하는 것은 Kubernetes 커뮤니티가 관리하던 kubernetes/ingress-nginx이며, F5 NGINX가 직접 개발하고 상용 지원하는 nginxinc/kubernetes-ingress는 완전히 별개의 프로젝트이며 활발히 유지 보수되고 있다.

특징:

• NGINX Open Source 또는 상용 NGINX Plus를 기반으로 선택하여 배포할 수 있다.
• 어노테이션에 과도하게 의존하는 커뮤니티 버전과 달리, VirtualServer 및 VirtualServerRoute라는 자체 CRD를 제공하여 트래픽 분할, 고급 헬스체크, mTLS 등을 더 명확하고 명시적으로 구성할 수 있다.
• TCP/UDP 로드 밸런싱을 ConfigMap이 아닌 TransportServer라는 전용 CRD로 관리하여 구성이 투명하고 관리가 용이하다.
• NGINX Plus 기반 상용 버전을 선택할 경우, F5 NGINX로부터 엔터프라이즈급 기술 지원과 실시간 모니터링 대시보드, JWT 인증 등 강력한 추가 기능을 제공받을 수 있다.

고려사항: ‘NGINX’에서 ‘NGINX’로의 이동이지만, 이는 단순한 교체가 아니다. 기본 Ingress 리소스는 호환될 수 있으나, 커뮤니티 버전에서 ‘snippets’나 복잡한 어노테이션으로 구현했던 고급 기능들은 NGINX Inc.의 VirtualServer CRD, 또는 NGINX Plus 기능으로 ‘변환’하는 마이그레이션 작업이 반드시 필요하다.

표: Ingress Controller 대안 비교 분석

조직의 정보에 입각한 의사 결정을 돕기 위해, 세 가지 주요 대안의 특성을 요약 비교한다.

전략 2: Gateway API로의 아키텍처 전환 (장기 전략)

두 번째 전략은 SIG Network가 공식적으로 권장하는 근본적인 해결책으로, Kubernetes 네트워킹의 미래 표준인 Gateway API를 전면적으로 수용하는 전략적 선택이다.

“왜 Gateway API로 전환해야 하는가?”

이는 Ingress가 가졌던 근본적인 문제(어노테이션 과부하, 이식성 부재, 거버넌스 모델 부재)를 ‘표준’ API 레벨에서 해결하는 유일한 방법이다. NGINX(NGINX Gateway Fabric), Kong, Istio, GKE 등 모든 주요 벤더와 클라우드 제공업체들이 Gateway API 구현체를 제공하고 있으므로, 벤더 종속성을 제거하고 진정한 이식성을 확보할 수 있다.

이에, Gateway API는 Ingress가 어노테이션으로 복잡하게 해결했거나 아예 해결하지 못했던 시나리오들을 표준화된 방식으로 해결한다. 아래 세 가지 문제 상황과 해결 방안을 통해 Gateway API를 설명한다.

<사례 1: 안전한 멀티테넌시 및 거버넌스 구현>

Ingress의 문제점: 개발자가 Ingress를 생성할 때, 실수나 의도적으로 다른 팀의 호스트 명이나 경로를 선점할 수 있다. 이를 막으려면 복잡한 별도의 정책 엔진이 필요했다.

Gateway API의 해결책: Gateway API는 역할 분리를 통해 이 문제를 API 레벨에서 원천적으로 해결한다.

1. 운영자가platform-infra 네임스페이스에 Gateway 리소스를 생성한다
2. 운영자는 이 Gateway의allowedRoutes.namespaces 필드를 통해 “오직 team-a, team-b 네임스페이스에서 생성된 HTTPRoute만 이 게이트웨이에 연결될 수 있다”고 명시적으로 정의한다
3. 개발자는 자신의team-a 네임스페이스에서 HTTPRoute를 생성하여 platform-infra/Gateway에 연결한다

결과: team-c 네임스페이스의 개발자는 platform-infra/Gateway에 HTTPRoute를 연결하려 시도해도 컨트롤러에 의해 거부된다. team-a 개발자는 team-b의 경로를 침범할 수 없다. 복잡한 정책 엔진 없이도 API 네이티브 방식으로 완벽한 멀티테넌시 거버넌스가 강제된다.

< 사례 2: 표준화된 고급 트래픽 제어 (카나리 배포) >

Ingress의 문제점:  카나리 배포를 위한 트래픽 분할은 ingress-nginx의 경우 nginx.ingress. kubernetes.io/canary-weight 같은 벤더-종속적 어노테이션으로 구현되었다. 이는 CI/CD 파이프라인이 특정 Ingress 컨트롤러 구현에 종속되는 결과를 초래했다.

Gateway API의 해결책: HTTPRoute는 표준 API 사양 내에 가중치 기반 라우팅을 핵심 기능으로 포함한다.

예시 HTTPRoute 설정:

결과: 이제 GitOps 또는 CI/CD 도구는 벤더(Istio, Kong, NGINX Gateway Fabric 등)에 관계없이 이 표준 HTTPRoute 리소스의 weight 값만 변경하면 점진적인 카나리 배포를 수행할 수 있다. 이는 Kubernetes 생태계의 ‘이식성’을 완벽하게 회복시킨다.

< 사례 3: L4/L7 트래픽 라우팅의 통합 관리 >

Ingress의 문제점: Ingress는 태생적으로 HTTP(S) 프로토콜 전용이었다. MySQL, Kafka, gRPC 등 L4(TCP/UDP) 트래픽을 외부로 노출해야 할 때, ingress-nginx 사용자들은 tcp-services라는 별도의 ConfigMap을 수정해야 했다. 이는 명시적이지 않고, RBAC으로 권한을 제어하기도 어려우며, 실수하기 쉬운 운영 방식이었다.

Gateway API의 해결책: Gateway API는 HTTP 외의 프로토콜을 위한 TCPRoute, UDPRoute, TLSRoute, GRPCRoute 리소스를 첫 번째 표준으로 제공한다.

결과: 개발자는 웹 애플리케이션을 위해 HTTPRoute를 제출하고, 동일한 개발팀이 관리하는 데이터베이스 접근을 위해 TCPRoute를 동일한 Gateway에 연결할 수 있다. 모든 L4-L7 트래픽 노출이 동일한 ‘역할 기반’ API 모델 하에서 명시적으로 관리되어, 운영의 일관성과 안정성이 향상된다.

결론: 변화의 물결 속에서 찾는 새로운 기회

Kubernetes는 이제 클라우드 네이티브 컴퓨팅의 중추신경계로 자리잡았으며, 그 생태계는 단순한 기술적 도구를 넘어 디지털 혁신의 핵심 플랫폼으로 진화하고 있다. 93%에 달하는 높은 도입률에도 불구하고, 많은 조직들은 여전히 성숙한 활용 단계로의 전환 과정에 있으며, 이번 Ingress NGINX 지원 종료 소식은 그러한 전환 과정에서 마주하게 되는 대표적인 과제 중 하나다.

조직들은 이제 전략적 선택에 직면해 있다. 단기적으로는 Istio, Kong, 또는 NGINX Inc. 컨트롤러와 같이 안정적으로 유지보수되는 Ingress 대안으로 교체하여 당면한 리스크를 회피할 수도 있다. 혹은 장기적으로는 Gateway API라는 차세대 표준을 도입하여 Ingress의 근본적인 한계를 해결하고 미래의 이식성과 확장성을 확보하는 진화를 선택할 수도 있다. 이 선택은 조직의 현재 아키텍처, 기술 성숙도, 그리고 비즈니스 목표에 따라 달라져야 한다.

Kubernetes 도입을 고민하거나 마이그레이션이 필요한 조직을 위해, 에스코어는 Kubernetes 전문가 팀을 통해 포괄적인 기술 지원과 컨설팅 서비스를 제공한다. 에스코어는 CNCF 프로젝트의 다양한 애플리케이션에 대한 깊이 있는 기술 지원뿐만 아니라, OS, DB, 미들웨어, Tomcat에 이르기까지 전반적인 오픈소스 기술 스택을 아우르는 종합적인 지원 체계를 갖추고 있다. Kubernetes 도입을 고민하거나 기존 환경의 최적화가 필요한 기업들은 에스코어의 전문 컨설팅과 기술 지원을 통해 클라우드 네이티브 여정에서 직면할 수 있는 다양한 과제들을 효과적으로 해결할 수 있을 것이다.

결국 Kubernetes의 성공적인 도입과 활용은 기술적 측면뿐만 아니라 조직 문화, 인력 역량, 그리고 비즈니스 전략과의 긴밀한 연계를 통해 실현될 수 있다. 이번 Ingress NGINX 지원 종료와 같은 변화의 순간에서 성공하는 조직은 단순히 최신 기술을 도입하는 것이 아니라, 자사의 비즈니스 목표와 조직 역량에 맞게 Kubernetes 여정을 체계적으로 설계하고 실행하는 조직이 될 것이다. 이러한 여정에서 에스코어의 체계적인 기술 지원 서비스는 조직이 디지털 혁신의 속도와 품질을 모두 확보하는 데 중요한 역할을 할 것이다.