미주리주 세인트루이스. 프랑스 오를레앙. 테르모필레 협곡, 그리스.
역사를 통틀어 특정 장소에는 ‘_____로 가는 관문’이라는 수식어가 붙어 왔습니다. 이러한 장소들은 왕국을 방어하는 데 전략적으로 중요한 곳—프랑스와 스파르타—이거나, 새로운 땅을 개척하려는 대대적인 노력의 출발점—세인트루이스—으로 유명합니다. 관문은 다른 곳, 대개 중요한 곳으로 이어지는 장소입니다. 관문을 장악하면 누가 또는 무엇이 들어오거나 나가는지를 통제할 수 있습니다. 관문은 출입을 통제할 수 있게 해 줄 뿐만 아니라 침략이나 공격을 더욱 효율적으로 막을 수 있는 방어 거점이기도 합니다. 현대에는 전 세계 공항에서 이러한 관문을 볼 수 있습니다. 국제공항에서 ‘세관’을 통과해야 하거나, 애초에 공항에 들어가기 위해 악명 높은 ‘보안 검색’을 거쳐야 하는 경우가 바로 그렇습니다.
따라서 기술의 역사 속에서 전략적으로 중요하다고 여겨지며 통칭하여 ‘게이트웨이’라고 불리는 장치들이 등장한 것은 놀라운 일이 아닙니다.
애플리케이션의 경우, 아키텍처에서 전략적 지점을 차지하는 이러한 장치는 신흥 기술의 보안과 확장성, 그리고 흔히 상호 운용성까지 지원합니다.
넓은 의미에서 네트워크 방화벽은 네트워크 내 애플리케이션 중심 게이트웨이의 ‘최초’ 사례라고 볼 수 있습니다. 초창기에는 방화벽이 말 그대로 문지기 역할을 했기 때문입니다. 네트워크 방화벽이 허용해야만 기업 네트워크 외부에서 애플리케이션에 접근할 수 있었습니다. 하지만 오늘날의 게이트웨이는 애플리케이션을 훨씬 더 잘 이해하며, 보안뿐 아니라 확장성, 접근성, 상호 운용성에 대한 요구까지 충족합니다.
IoT 시대로 본격 진입하면서 이 모든 것이 핵심적인 우려 사항으로 떠오르고 있습니다. 최근 Vanson Bourne이 실시한 HCL 설문조사에 따르면 응답자의 93%는 보안, 86%는 확장성, 83%는 상호 운용성을 우려하는 것으로 나타났습니다. 이는 전혀 놀라운 일이 아닙니다. 데이터를 수집하고, 명령을 주고받고, 사물을 모니터링하기 위해 앱에 접속해야 하는 기기의 수가 워낙 방대하기 때문에 어떤 네트워크든 엄청난 영향을 받을 수밖에 없습니다. 기업들이 차세대 ‘제품’을 시장에 출시하도록 압박받는 속도는 보안에 악영향을 미칩니다. 또한 상호 운용성은 언제나 어려운 과제입니다. 새로운 시장에서는 제품이 본래의 용도를 수행하는 것만큼이나 다른 사물 및 앱과의 통신에 크게 의존하기 때문입니다. 초기 시장은 빠르게 여러 갈래로 나뉘는 경향이 있으며, 다양한 표준을 중심으로 여러 진영이 형성되다가 결국 어느 날 한두 가지 표준으로 정착하게 됩니다. 하지만 초기에는 선택지가 복잡하고 혼란스러운 경우가 많습니다. 혁신가들은 상황이 정리될 때까지 기다리려 하지 않습니다. 결국 혁신가는 시장에 먼저 진입함으로써 승리하기 때문입니다.
그렇다면 신기술이 성숙하고 표준이 정립되어 가는 동안 보안, 확장성, 상호 운용성 문제를 어떻게 해결할 것인가가 관건입니다. 일반적으로 그 해답은 게이트웨이입니다.
과거에도 XML 및 SOAP 같은 다른 기술과 프로토콜을 둘러싼 동일한 과제를 해결하기 위해 게이트웨이가 등장했습니다. 웹 서비스의 ‘표준’ 자리를 놓고 RPC/ENC와 DOC/LIT가 벌였던 격렬한 다툼을 기억하며 어쩌면 몸서리치는 사람은 저뿐만이 아닐 것입니다. 비교적 최근에 벌어진 JSON과 XML 간의 경쟁을 기억하는 사람도 저뿐만이 아닙니다. 오늘날에는 IoT 분야에서 이러한 주도권 다툼이 벌어지고 있으며, MQTT와 CoAP, AMQP가 우위를 차지하기 위해 경쟁하고 있습니다.
하지만 혁신은 기다려 주지 않으며, 새로운 기술과 프로토콜에서 비롯되는 과제를 해결하기 위해 곳곳에서 게이트웨이가 등장하고 있습니다.
HTTP2 게이트웨이
HTTP2 게이트웨이는 주로 HTTP/1x와 HTTP/2 간의 상호 운용성 문제를 해결합니다. 이러한 장치는 최신 HTTP 표준을 사용할 때 더 빠르게 작동하는 모바일 및 IoT 기기를 지원하기 위해 ‘외부’에서 HTTP2 연결을 종료합니다. 이를 통해 혁신 기업은 새로운 표준을 지원하도록 앱과 네트워크 인프라를 업그레이드하는 데 따르는 대규모 중단 없이 소비자와 사물에 HTTP2 지원을 제공할 수 있습니다. 언젠가는 모두가 HTTP2를 사용하게 되기를 바라고(또 그렇게 될 것으로 예상하지만), 그때까지 HTTP2 게이트웨이는 혁신 기업이 전속력으로 나아가는 데 필요한 상호 운용성을 제공합니다.
API 게이트웨이
API 게이트웨이의 등장은 나비가 고치에서 깨어나는 과정과 비슷합니다. 애벌레(SOA 게이트웨이)였던 것이 이제 나비(API 게이트웨이)가 된 셈입니다. 물론 이 범주에 완전히 새로운 제품이 없는 것은 아닙니다. 실제로 존재하지만, 양쪽 모두 HTTP를 기반으로 하기 때문에 많은 유사점을 공유합니다. SOA 게이트웨이가 주로 XML과 SOAP을 다뤘다면, API 게이트웨이는 HTTP 엔드포인트를 사용해 구현된 JSON 및 RESTful API에 중점을 둡니다.
이러한 장치는 보안과 확장성을 제공하며, 경우에 따라 상호 운용성 서비스도 제공합니다. 또한 앱의 언어에 능숙하여 JSON과 HTTP를 모두 자유롭게 처리하고, 마이크로서비스 및 서버리스처럼 애플리케이션뿐만 아니라 여러 환경에 걸쳐 API 호출을 분산할 수 있는 새로운 앱 모델을 지원하기 위한 견고한 기반을 제공합니다. API 게이트웨이는 할당량을 적용하여 호출 속도를 제한하고 API 키 관리를 통해 액세스를 제어함으로써 확장성을 보호하는 역할도 합니다.
API 게이트웨이의 핵심 특성 중 하나가 로드 밸런싱을 통한 확장성인 것은 분명하지만, 단순한 ‘로드 밸런서’에 그치지는 않습니다. API 게이트웨이는 기존의 단순한 로드 밸런싱을 넘어 일관된 사용자 경험을 제공하는 동시에 개발자와 기업이 클라우드와 서버리스를 활용할 수 있도록 지원해야 합니다. API를 보호하고 확장하려면 API 게이트웨이가 ‘스마트’해야 합니다. 즉, 요청과 응답을 검사할 수 있어야 할 뿐만 아니라 OAuth2 및 JWT와 같은 외부 인증 제공자와도 통합할 수 있어야 합니다.
IoT 게이트웨이
IoT 게이트웨이는 오늘날의 게이트웨이 중 가장 초기 단계에 있지만 이미 실제로 사용되고 있으며, IoT 이니셔티브의 성공에 매우 중요합니다. 어쩌면 다른 게이트웨이가 각자의 시장에서 갖는 중요성보다 더 클 수도 있습니다. 이는 웹과 전혀 친화적이지 않은 프로토콜과 관련이 있습니다. 많은 소비자용 기기가 ‘웹’과 통신하기는 하지만, 사물 제조업체들은 효율성이 더 높고 기기에서 컴퓨팅 자원을 덜 소모한다는 이유로 MQTT 및 CoAP 같은 IoT 전용 프로토콜에 점점 더 의존하고 있습니다. 그러나 해당 데이터를 수신하는 앱이 반드시 MQTT를 지원하는 것은 아니며, 지원하더라도 (바라건대 폭발적일) 수요를 감당할 만큼 자체적으로 확장할 수는 없습니다.
이러한 필요에 따라 IoT 게이트웨이가 등장했습니다. IoT와 웹의 언어를 모두 이해하며, 확장성과 안전한 액세스를 동시에 제공합니다. API 게이트웨이와 마찬가지로 이러한 게이트웨이는 요청과 응답을 변환하고 라우팅할 뿐만 아니라, 악용을 방지하기 위해 이상 징후나 악의적인 동작을 감지할 수 있을 만큼 ‘스마트’해야 합니다.
아키텍처 측면에서 게이트웨이는 네트워크와 애플리케이션에 대한 액세스를 제공합니다. 요청이 게이트웨이를 통해 집중되므로, 게이트웨이는 액세스를 제어하고 변환을 수행하며 보안을 적용할 수 있는 전략적 제어 지점이 됩니다. 또한 새로운 기술이나 프로토콜이 등장할 때 자연스럽게 발생하는 전환 기간 동안 기존 비즈니스와 앱에 미치는 중단과 위험을 줄이면서 조직이 혁신할 수 있도록 지원하므로, 신기술 도입을 가능하게 하는 핵심 요소입니다.
게이트웨이는 아키텍처 구성 요소로 여겨지는 경향이 있지만, 오늘날에는 기업이 새로운 기술의 잠재력을 활용할 수 있도록 혁신을 뒷받침하는 핵심 요소로도 자주 활용됩니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.