앱의 중력이 네트워크를 포크시키고 있다

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

네트워크가 갈라지고 있습니다. 분기하고, 분산되고 있습니다. 기업 네트워크라는 조용한 교외에서 데이터 센터 네트워크의 애플리케이션 측이라는 분주하고 시끄러운 도심으로 네트워크 서비스가 이전하는 현상을 어떤 용어로 표현하든 상관없습니다. 오늘 논의의 핵심은 용어가 아니라, 이러한 현상이 일어나는 이유를 깊이 고찰하는 것입니다.

어떤 사람들은 이렇게 말할지도 모릅니다. “글쎄요, 로리. 기업 네트워크가 하드웨어에 크게 의존하고 있다는 건 분명하고, 하드웨어는 개발 및 운영 부문의 더 세련되고 민첩한 환경에 어울리는 데 필요한 유연성과 기민성을 갖추지 못했잖아요.”

글쎄요, 그렇지는 않습니다. 하드웨어냐 소프트웨어냐의 문제라기보다는 사실 무엇을 하든 하드웨어는 반드시 필요하기 때문입니다(RAM, 컴퓨팅 성능, 네트워크 액세스 같은 리소스가 저절로 생겨나는 것은 아니니까요). 핵심은 두 네트워크 각각을 지배하는 운영 문화와 현실이며, 이로 인해 일부 서비스가 한쪽에서 다른 쪽으로 이동하고 있습니다.

사실 지금 실제로 일어나고 있는 일은 애플리케이션이 새로운 무게중심이 되어, 달이 지구에 끌리듯 애플리케이션과 밀접한 모든 서비스를 끌어당기고 있는 것이라고 할 수 있습니다.

문제는 부하 분산, 캐싱, 가속, 웹 애플리케이션 보안과 같은 애플리케이션 종속형 서비스가 특정 애플리케이션에 매우 특화되어 있다는 점입니다. 이러한 서비스는 모든 경우에 두루 적용되는 ‘만능형’ 서비스가 아닙니다. 오히려 하나의 애플리케이션을 제공하고 보호하며 최적화하도록 정책이 설계된, 고도로 전문화된 애플리케이션 중심 서비스입니다.

전부가 아닙니다. 같은 종류라고 해서 모두 해당되는 것도 아닙니다. 단 하나뿐입니다. 바로 저기 있는 저 애플리케이션 말입니다.

이는 예를 들어, 작동 방식이 특정 애플리케이션에 크게 종속되지 않는 네트워크 방화벽이나 IPS/IDS와는 매우 다릅니다. 웹 앱은 80번 포트를 통해 실행되므로 해당 포트를 열어 방화벽을 통과할 수 있도록 합니다. 동일한 프로토콜(HTTP)을 사용하고 동일한 포트에서 실행된다는 점 외에는 ‘애플리케이션’에 특화된 부분이 거의 없습니다.

반대로, 단일 URI(/login.x)에 연결된 하나의 입력 필드(사용자 이름? 이메일? 댓글?)에 어떤 종류의 데이터(문자열? 정수? 영숫자?)를 얼마나 많이(15자? 12자? 100자?) 입력할 수 있는지를 규정하는 보안 정책은 지극히 애플리케이션에 특화되어 있습니다. 축소화, 스타일시트 연결, 그리고 부하 분산 서비스에서 애플리케이션과 관련된 상태 모니터링을 관리하는 정책도 마찬가지입니다.

어피니티가 중요한 이유

현재 일반적인 기업은 약 508개의 애플리케이션을 관리하는 것으로 알려져 있습니다. 당사의 조사에 따르면 실제로 조직의 31%가 500개 이상의 애플리케이션을 보유하고 있지만, 이 역시 핵심은 아니며 단지 기준점일 뿐입니다. 많은 조직이 훨씬 더 많은 애플리케이션을 구축할 계획이기 때문에 이를 기준점으로 삼은 것입니다. 또한 마이크로서비스 아키텍처를 도입하는 조직 중에는 애플리케이션 수 자체는 반드시 바꾸지 않더라도, 앞서 언급한 애플리케이션 친화형 서비스가 필요한 ‘시스템’의 수를 늘리는 곳도 있습니다.

자, 한 조직이 관리 중인 애플리케이션 수를 두 배로 늘리려 한다고 가정해 보겠습니다. 처음에는 500개였는데 갑자기 1,000개로 늘어난다고 해보죠. 모든 정책을 하나하나 프로비저닝하고 구성하며 관리해야 합니다. 계산을 간단히 하기 위해 각 앱에는 확장용 정책 하나와 보안용 정책 하나, 이렇게 단 2개만 필요하다고 가정해 보겠습니다. 그렇다면 처리해야 할 정책이 2,000개입니다. 준비됐나요? 시작하시죠.

그렇습니다. 문제는 기업 네트워크의 ‘하드웨어’가 이를 감당하지 못한다는 데 있지 않습니다. 오히려 이를 감당할 수 있는 이유는 바로 그것이 특수 목적용 하드웨어이기 때문이며, 따라서 범용 서버보다 훨씬 뛰어난 처리 용량을 갖추고 있습니다. 문제는 이 모든 작업을 수행하는 데 필요한 프로세스와 인력입니다. 필요한 장치의 수뿐만 아니라 배포해야 하는 고유한(애플리케이션별) 정책의 수도 문제입니다.

그리고 배포만이 아니라 업데이트도 해야 합니다. 애플리케이션 종속 정책은 특정 애플리케이션에 맞게 구성되므로, 앱이 업그레이드되거나 수정 사항이 적용될 때 관련 앱 서비스 정책도 업데이트해야 할 가능성이 더 큽니다. 게다가 조직들이 더 자주 배포하려고 하니... 기업 네트워크 담당자들이 완전히 감당하기 어려운 상황에 놓일 것이라는 점은 쉽게 상상할 수 있습니다.

반면 애플리케이션 네트워크에서는 개발팀과 운영팀이 의욕에 차 있습니다. 애플리케이션을 제공하고 배포하는 데 열의를 보이고 있습니다. 이들은 자동화와 오케스트레이션에 관한 새로운 기술을 활용해 그 프로세스의 속도를 높일 준비가 되어 있습니다.

실제로 운영자들은 애플리케이션과 밀접하게 연계된 서비스를 점점 더 많이 책임지고, 이를 배포 아키텍처와 프로세스에 통합하고 있습니다. DevOps에 대한 인식이 높아지고 SDN을 통해 업계의 지원도 어느 정도 이루어지면서, 이제 거의 모든 네트워크 서비스에서 API를 사용할 수 있습니다. 그 밖의 많은 서비스도 애플리케이션 지원에 필요한 인프라를 관리하고 배포할 때 ‘코드형 인프라’ 접근 방식을 사용하는 운영자에게 꼭 맞는 템플릿을 제공합니다.

이러한 이유로 점점 더 많은 ‘애플리케이션 서비스’가 애플리케이션 네트워크에 등장하면서 엔터프라이즈 IT의 무게중심이 애플리케이션 쪽으로 이동하고 있습니다.

이는 비즈니스 및 운영 확장을 위한 전략입니다. 애플리케이션 포트폴리오의 급속한 성장에 대응하기 위해 네트워크 또는 애플리케이션 인력을 무작정 늘렸다가 브룩스의 법칙에 위배되는 상황을 피할 수 있는 방법입니다. 또한 네트워크 운영자가 현재보다 두세 배 이상 많은 정책을 갑자기 관리해야 하는 데서 발생하는 혼란 없이, IT 부서가 애플리케이션을 더 빠르고 더 자주 시장에 출시할 수 있도록 하는 방법입니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물