최신 애플리케이션 프록시의 세 가지 핵심 특성

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

뜨거운 쪽은 뜨겁게, 차가운 쪽은 차갑게 유지하세요.

연세가 좀 있으신 분이라면(아니요, 걱정 마세요. 손을 들어 보라고 하진 않을 테니까요) 몇 년 전 맥도날드가 일부 제품의 포장이 “뜨거운 쪽은 뜨겁게, 차가운 쪽은 차갑게” 유지해 준다고 홍보했던 캠페인을 기억하실지도 모릅니다.

사실 개념은 아주 간단했습니다. 뜨거운 것과 차가운 것을 분리하되, 쉽게 운반할 수 있도록 하나의 용기에 담는 것이었죠.

동일한 ‘컨테이너’ 안에서 서로 분리한다는 개념이야말로 앱 프록시를 말 그대로 프록시답게 만드는 근간입니다. 클라이언트 측은 클라이언트로, 앱 측은… 앱으로 유지해 주죠.

좋아요, 생각해 보니 이 표현이 제가 바란 만큼 매끄럽게 전달되지는 않을 수도 있겠네요.

그럼에도 이 개념은 유효하며 앱 프록시를 이해하는 데 중요합니다.

기본적으로 프록시는 통신을 주고받는 두 참여자 사이에 논리적으로 위치하는 소프트웨어입니다. 앱 프록시는 앱과 클라이언트 사이에 위치합니다. 하지만 모든 프록시가 완전한 프록시인 것은 아닙니다. 완전한 프록시는 양측이 내부적으로 분리되어 있어야 합니다. 즉, 완전한 프록시는 하나의 장치 안에 서로 독립적인 두 개의 네트워킹 스택을 갖습니다. 하나는 클라이언트 측(핫 사이드)이고, 다른 하나는 앱 측(콜드 사이드)입니다.

알아요, 이 비유가 별로 와닿지 않죠? 그래도 좀 맞춰 주세요. 지금은 이게 최선이니까요.

이것이 애플리케이션 프록시의 필수 요건인(또는 필수 요건이어야 하는) 이유는 프록시가 클라이언트와 서버 간의 통신에 관여할 수 있게 해 주기 때문입니다. 이는 축소화(애플리케이션 성능 향상), 보안 기능(데이터 스크러빙 등), TCP 다중화(최적화)를 비롯한 광범위한 기타 서비스를 제공하는 데 필요합니다.

클라이언트 측과 앱 측 사이의 내부적인 ‘간극’에서 마법 같은 일이 일어납니다. 기본적인 부하 분산부터 고급 애플리케이션 방화벽, 애플리케이션 액세스 제어에 이르기까지 수많은 서비스가 바로 이곳에서 각자의 역할을 수행합니다. 요청은 사실상 앱 프록시의 클라이언트 측에서 종료됩니다. 그런 다음 서비스 체이닝과 매우 유사한 프로세스가 진행되지만, 이 모든 과정은 내부 버스 및 프로세서 속도(거의 항상 네트워크 속도보다 빠름)로 내부에서 이루어집니다. 검사가 진행되고, 정책이 적용되며, 변환이 수행되고, 의사 결정이 내려집니다. 이후 프록시와 앱 사이에 별도의 연결이 설정되고 요청이 전달됩니다.

해당 요청이 프록시로 돌아오면 반대 과정이 진행됩니다. 검사가 수행되고, 데이터가 정제되며, 정책이 적용됩니다. 그런 다음 클라이언트 측으로 돌아가 클라이언트에 다시 전송됩니다.

그리고 이 모든 과정은 프록시 내부에서 처리되므로 1초도 채 걸리지 않습니다.

앱 프록시의 목적은 가용성, 보안, 이동성, ID 및 액세스, 성능 등 광범위한 앱 서비스를 제공하는 것이므로 진정한 풀 프록시여야 합니다. 모든 요청과 응답에 빠짐없이 관여하도록 설계된 것은 풀 프록시뿐입니다. 단순 프록시(좀 더 깊이 들어가자면 사실상 상태 비저장 프록시)는 클라이언트와 앱 간 연결이 생성되는 초기 통신에만 관여합니다. 그 목적은 앱 인스턴스를 선택한 다음 둘 사이의 연결을 하나로 "이어 붙이는" 것입니다. 그 이후에는 프록시가 관여하지 않습니다. 프록시는 "플로우"(SDN을 논할 때 들어봤을 수도 있는 계층 4 TCP 구조로, 이 역시 다음에 따로 다룰 주제입니다)를 인식하고 패킷을 양방향으로 전달할 뿐이며, 뜨거운 것과 차가운 것을 가리지 않고 뒤섞습니다. (보셨죠? 이 비유가 결국 통할 줄 알았습니다.)

지금까지의 내용을 종합하면, 현대적이고 확장 가능한 앱 프록시는 완전한 프록시여야 하며 프로그래밍 가능성, 성능, 프로토콜이라는 세 가지 핵심 특성을 갖춰야 합니다.

프로그래밍 가능성은 현대적인 데이터 센터와 클라우드에서 자동화, 오케스트레이션 및 표준화를 지원하는 데 매우 중요합니다. 또한 데이터 경로에서 보안과 비즈니스 및 운영에 고유한 가치를 제공하는 서비스를 구현하고, 사용자 지정 프로토콜을 지원하며 기존 프로토콜을 확장하는 데도 핵심적인 역할을 합니다. 성능은 간단한 문제처럼 들리지만 실제로는 그렇지 않습니다. 앱 프록시는 모든 요청과 상호 작용하므로 단순히 빠른 수준을 넘어 압도적으로 빨라야 합니다. 앱 경험을 저해하는 지연 시간을 통신 과정에 추가하지 않으면서 필요한 작업을 신속하게 처리해야 합니다. 이는 말처럼 쉽지 않으며, 특히 배포 기반으로 범용 컴퓨팅을 사용하려는 움직임이 강한 상황에서는 더욱 그렇습니다.

마지막으로, 프로토콜도 중요합니다. “앱”이라고 하면 가장 먼저 떠오르는 것은 아마 HTTP일 것입니다. 놀랄 일도 아닙니다. HTTP는 새로운 TCP이자 인터넷의 공용어이기 때문입니다. 하지만 HTTP가 현재 사용되는 유일한 프로토콜은 아니며, 특히 인터넷 기반 통신 시대에는 더욱 그렇습니다. SIP와 UDP도 있고, SMTP(아직도 이메일을 보내시죠?)와 LDAP도 빼놓을 수 없습니다. SSL과 TLS는 또 어떻습니까? SSL Everywhere를 말 그대로 모든 곳에 구현해야 한다는 관심과 시급성이 커지면서, 앱 프록시가 SSL/TLS를 지원하는 것은 물론 매우 능숙하게 처리하는 일이 더욱 중요해졌습니다. 그렇지 않으면 성능 요구 사항을 충족하지 못할 수 있기 때문입니다.

앱 프록시는 현대적인 데이터 센터가 보안 및 성능 문제를 해결하고, 자동화와 오케스트레이션을 통해 운영 비용을 절감하며, 일반 소비자와 기업 고객 모두에게 최적의 앱 경험을 제공하는 데 필요한 플랫폼이 될 수 있습니다. 하지만 어떤 앱도 소외되지 않도록 프로그래밍 기능과 성능, 프로토콜 지원을 모두 갖춘 완전한 앱 프록시여야 합니다.

작성자 소개

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

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

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