기술과 그 작동 방식에 대한 우리의 이해는 여러 측면에서 근본적인 변화를 겪고 있습니다. 조직들이 이러한 변화에 어떻게 대응하고 있는지 알아보기 위해 F5는 기술 분야를 선도하는 시장 조사 기업인 SlashData와 협력하여 다양한 산업과 전 세계 여러 지역의 IT, 보안 및 소프트웨어 개발 분야 리더와 실무자 수백 명을 대상으로 설문조사를 실시했습니다.
참가자에는 NGINX 오픈 소스 프로젝트, NGINX Open Source 및 F5 NGINX 상용 제품 사용자가 포함되었습니다. 조사 결과, 컨테이너화, 보안, 개발자 플랫폼 및 AI 분야에서 즉각적인 변화를 추진하려는 조직들이 느끼는 긴박감이 타당한 것으로 확인되었습니다. 다음은 2025년 NGINX 연례 설문조사의 주요 결과입니다.
새롭게 떠오르는 트렌드: 에이전틱 AI와 비CPU 중심의 미래
F5 NGINX는 AI 인프라를 위한 사실상의 표준 관문으로 자리 잡았으며, 주요 AI 하드웨어 및 소프트웨어 공급업체들은 이를 AI 애플리케이션용 기본 또는 권장 리버스 프록시 및 전송 컨트롤러로 채택하고 있습니다. 설문조사 결과, NGINX 사용자와 더 광범위한 애플리케이션 전송 커뮤니티에서 AI가 주도하는 미래를 수용하려는 움직임이 강하게 나타났습니다.
AI 에이전트 활용: 에이전트형 AI 작업의 활용 현황에 대해 질문한 결과(그림 1 참조), 응답자들은 현재 도입률이 가장 높은 작업으로 25%를 기록한 ‘NGINX 구성’을 꼽았으며, ‘네트워크 트래픽 최적화 및 부하 분산’이 24%로 그 뒤를 이었습니다. ‘인프라 배포 및 확장’과 ‘보안 취약점 해결’은 현재 응답자의 23%가 사용하고 있습니다.
통합 참여율: 에이전틱 AI를 현재 사용 중인 응답자와 실험 중인 응답자의 답변을 합산하면, ‘로그 분석 및 선제적 문제 해결’이 48%로 가장 높았습니다. ‘NGINX 구성’과 ‘인프라 배포 및 확장’은 각각 46%로 공동 2위를 차지했으며, ‘네트워크 트래픽 최적화’가 45%로 그 뒤를 이었습니다.
향후 가장 높은 관심 분야: “드리프트 감지 및 수정”이 33%로 향후 가장 높은 관심을 받았으며, “NGINX 배포 모니터링”이 32%, “인시던트 알림 및 분류”가 31%로 뒤를 이었습니다.
특수 하드웨어: 설문 응답자의 25%가 GPU, TPU 또는 FPGA에서 워크로드를 실행하고 있습니다. 이는 전통적으로 범용 컴퓨팅에 중점을 두어 온 인프라에서 주목할 만한 수치입니다(그림 2 참조). 소형 AI 모델의 성능 향상, Docker 및 대형 클라우드 서비스 제공업체와 같은 클라우드 네이티브 인프라에서 소형 AI 모델을 손쉽게 실행할 수 있게 된 점, 애플리케이션 제공 프로세스의 오프로딩(예: 암호화 및 SSL 처리를 NPU와 FPGA로 오프로딩하거나 AI 추론을 GPU와 TPU에 배포하는 것 등)을 비롯한 몇 가지 주요 요인으로 인해 이러한 추세가 계속 확대될 것으로 예상합니다.
주요 장벽: 설문 응답자들은 AI 통합의 주요 장벽으로 보안 우려(26%)와 정확성에 대한 신뢰 부족(24%)을 꼽았습니다. 통합의 복잡성, 규정 준수 및 규제상의 제약, 에이전트 기능에 대한 이해 부족은 모두 17%로 나타났습니다.
클라우드 네이티브는 보편화되었지만 여전히 발전 중입니다
컨테이너와 Kubernetes로 시작된 지 10년이 훌쩍 지난 지금도 클라우드 네이티브 혁명은 계속해서 탄력을 받고 있습니다. 클라우드 네이티브의 핵심 요소는 거의 보편적으로 도입되고 있지만, 완전히 확산되기까지는 아직 갈 길이 멉니다(그림 3 참조).
구체적으로, 설문조사 결과는 다음과 같습니다:
- 멀티 환경의 현실은 진정으로 우리 곁에 와 있습니다: 조직의 66%가 하나 이상의 클라우드 옵션을 사용하고 있지만, 배포 위치로는 온프레미스가 39%로 여전히 가장 높은 비중을 차지하며, 퍼블릭 클라우드는 38%, 하이브리드는 36%입니다. 이는 단순한 "클라우드 마이그레이션" 사례라기보다 현대 인프라의 복잡하고 분산된 특성을 보여줍니다.
- 컨테이너 도입은 아직 확대될 여지가 있습니다: 응답자의 42%만이 컨테이너에서 워크로드를 실행하고 있으며, 마이크로서비스 도입률은 31%에 불과합니다. 가상 머신이 60%로 가장 큰 비중을 차지한다는 점은 많은 조직이 아직 클라우드 네이티브 전환의 초기 단계에 있음을 시사합니다.
- Kubernetes 파편화: 자체 관리형 Kubernetes가 24%로 컨테이너 오케스트레이션 분야에서 선두를 달리는 가운데, Red Hat OpenShift는 자체 관리형과 완전 관리형을 합쳐 21%를 차지하며, Amazon Web Services(21%), Microsoft Azure(17%), Google Cloud Platform(17%)의 관리형 서비스도 상당한 도입세를 보이고 있습니다.
API 및 마이크로서비스 보안 관리의 격차는 매우 큽니다
지난 10년 동안 많은 기술 조직이 내부 및 외부 운영을 연결하는 핵심 메커니즘으로 API를 도입해 왔습니다. 클라우드 네이티브 아키텍처에서는 API 우선 접근 방식이 핵심 설계 원칙입니다. 이에 따라 응답자의 86%가 API 인프라를 관리하기 위해 API 게이트웨이를 배포하고 있습니다(그림 4 참조).
API로의 전환이 광범위하게 이루어지고 API 게이트웨이가 널리 사용되고 있음에도 불구하고, 대다수 조직의 API 보안 관행은 여전히 미성숙한 수준입니다(그림 5 참조). 조직의 86%가 API를 사용하지만, API 보안을 구현한 조직은 34%에 불과합니다. 이는 현대적인 애플리케이션 인프라를 심각한 위험에 노출시키는 요인입니다.
응답자의 절반 미만만이 API 보안의 또 다른 핵심 요소인 API 트래픽 분석(43%)과 관측 가능성(38%)에 주력하고 있습니다. 이러한 격차는 전반적으로 API를 관찰하고 관리하는 데 어려움이 있음을 시사합니다. 실제로 응답자의 23%는 팀마다 서로 다른 API 관리 방식을 사용하고 있으며, 이러한 파편화는 조직 전체가 전통적인 API 관리의 ‘골든 패스’를 따르도록 하는 데 따르는 어려움에서 비롯된 것으로 보입니다.
플랫폼 엔지니어링은 발전했지만, 여전히 성숙하지 못한 단계입니다
플랫폼 엔지니어링은 유행어의 단계를 넘어 주류로 자리 잡았습니다. 실제로 응답자의 65%가 플랫폼 엔지니어링 역량과 책임을 도입하기 시작했습니다(그림 6 참조). 여기에는 전담 플랫폼 팀을 둔 대규모 조직부터 팀원 한 명이 플랫폼 엔지니어링 책임자 역할을 맡는 경우까지 포함됩니다. 약 27%는 소규모 전담 플랫폼 엔지니어링 팀을 운영하고 있으며, 조직의 21%는 개발/운영 팀 내에 플랫폼 엔지니어링 담당자를 두고 있습니다. 또 다른 13%의 조직은 대규모 전담 플랫폼 엔지니어링 팀을 운영하고 있습니다. 이처럼 플랫폼 엔지니어링의 가치 제안은 분명 널리 확산되어 뿌리내렸습니다.
하지만 모든 규모의 팀에서 플랫폼 관련 과제에 대한 설문 응답을 살펴보면, 초기 단계에서 어려움을 겪고 있는 것으로 나타났습니다. 중대한 과제가 없다고 답한 응답자는 20%에 불과했습니다. 나머지 응답자들은 보안 및 규정 준수 문제(18%), 문서 유지 관리(16%), 최신 기술 유지(16%), 리소스 제약(14%) 등 다양한 플랫폼 엔지니어링 과제가 조직에 실질적인 영향을 미치고 있다고 답했습니다.
설문조사에서는 서비스 제공 및 가치 제안의 우선순위와 관련해 대규모 팀과 소규모 팀 사이에 뚜렷한 차이가 있는 것으로 나타났습니다. 예상대로 대규모 팀은 보다 고도화된 영역에 집중한 반면, 소규모 팀은 전통적인 DevOps와 유사한 영역에 초점을 맞췄습니다. 규모가 크고 전담 인력으로 구성된 플랫폼 엔지니어링 팀은 Database as a Service(54%), 관측 가능성(52%), API 관리(51%), 방화벽 구성 및 관리(54%), CI/CD 파이프라인 도구(50%)와 같은 고도화된 서비스를 제공할 가능성이 더 높습니다.
클라우드, AI, API를 따라잡기란 쉽지 않다
기업들은 관리 역량이 따라가지 못할 정도로 빠르게 기술을 도입하고 있습니다. 설문조사에 따르면 조직들은 컨테이너, API, 플랫폼 엔지니어링을 적극적으로 도입하려 하지만, 현재 구축 중인 시스템을 안전하게 보호하고 운영할 준비는 되어 있지 않습니다. 가장 심각한 문제는 API 보안입니다. 거의 모든 조직이 API를 운영하고 있지만, 그중 3분의 2는 기본적인 보호조차 갖추지 못했습니다. 이는 미래의 위험이 아니라 지금 이 순간 프로덕션 환경에 존재하는 실제 취약점입니다.
한편, 특정 영역에서는 실질적인 진전이 이루어지고 있습니다. AI 에이전트는 단순한 데모를 넘어 실제 인프라 작업을 대규모로 처리하기 직전 단계에 와 있습니다. GPU와 특수 목적 프로세서가 표준으로 자리 잡고 있습니다. 플랫폼 엔지니어링 팀은 대부분의 조직에 존재하지만, 아직도 자신들의 역할을 구체화하는 중입니다.
지금 중요한 것은 철저한 실행입니다. 저희가 권고하는 바는 다음과 같습니다. 현재 보유한 역량을 충분히 관리할 수 있을 때까지 새로운 역량을 추가하지 마세요. API 보안 및 관리 방식을 표준화하세요. 시스템을 파악하는 데 필요한 관측 가능성을 확보하세요. 플랫폼 팀에 명확한 책임과 성과를 내는 데 필요한 리소스를 제공하세요.
현대적이고 효율적인 인프라를 구축할 기술은 이미 갖춰져 있습니다. 이제는 이를 안전하고 지속 가능하게 만드는 데 필요한, 화려하지는 않지만 반드시 해야 할 작업에 착수할 때입니다.
F5 NGINX 제품에 대해 자세히 알아보려면 웹페이지를 방문하세요.
작성자 소개

관련 블로그 게시물
시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.
F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.
Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.
진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.
NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.
Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.