지스케일러 Goldman Sachs Communacopia + Technology Conference 2026

안녕하세요, 좋은 아침입니다. Zscaler 세션에 함께해 주셔서 정말 감사합니다. 제품 총괄인 아담 겔러와 CFO인 케빈 루빈 두 분을 이 자리에서 모시게 되어 기쁩니다. 시간 내주셔서 정말 감사드립니다.

감사합니다. 아담, 제가 Zscaler IPO 초기 시절이 기억납니다.

네. 그리고 제이와 팀이 가장 근본적으로 강조했던 것 중 하나는 ‘진정한 프록시 아키텍처’라는 개념이었고, 겉으로 보기에는 프록시 아키텍처처럼 보이게 만들기 위해 지름길을 택하는 것은 진정한 프록시 아키텍처를 제공하는 것과는 같지 않다는 점이었습니다.

그래서 제 질문은 이렇습니다. 이제는 에이전트들이 프록시 아키텍처 상에서 통신해야 한다는 점에 대해 충분히 설득력 있는 논리적 주장이 가능한 시대가 되었는데요. 리더십 팀으로서, 그리고 최고 제품 책임자(CPO)로서 SASE와 제로 트러스트를 위해 구축된 비전을 어떻게 에이전트 기반 프록시 아키텍처로 확장해 나가고 계신가요?

그래서 제 생각에는요. 저는 IPO 당시에는 그 자리에 있지는 않았지만, 프록시 아키텍처 없이도 Zscaler와 경쟁하던 회사들에 몸담고 있었습니다. 그래서 이 업계를 확실히 잘 알고 있습니다. 제 생각에 제품 관점에서 이 모든 것을 논의할 때의 핵심은, 여러분이 해결하려는 문제가 무엇인지에 따라 어떤 해법이 목적에 가장 부합하는 적합한 선택인가 하는 점입니다. 그래서 결국은 거기에서 어떤 근본 원칙으로 다시 돌아가 보셔야 합니다. 특히 사이버보안에서 프록시 아키텍처가 강력한 이유는, 어떤 것의 경로 중간에 들어가게 되면 실제로 트래픽을 확인하고 검사할 수 있는 기회를 확보할 수 있기 때문입니다. 왜냐하면 사이버보안을 하는 핵심 목적 자체가 외부에서 들어오는 위협을 찾거나, 데이터가 어디로 이동하고 있는지 그리고 그 이동이 과연 이뤄져야 하는지 여부를 파악하려는 데 있기 때문입니다. 따라서 단순히 시스템들을 연결하는 것만으로도 나름의 목적이 있습니다. 그렇게 하면 지점 A에서 지점 B로 이동할 수 있습니다. 하지만 프록시라는 개념이 존재하는 근본적인 이유는 그것이 검사 지점이자, 최소한 관찰하고 확인할 수 있는 기회를 제공하기 때문입니다. 즉, 관찰하면서 기록만 남기고 아무 조치도 하지 않을 수도 있고, 정책을 집행할 수도 있는 기회가 생깁니다. 그래서 그 아키텍처는 효과가 있고 매우 강력하기 때문에 사이버보안 제품과 기술에서 반복적으로 핵심 구성 요소로 다시 떠오릅니다.

이제는 여느 보안 요소와 마찬가지입니다. 프로세스에 마찰을 일으키는 요소입니다. 그래서 프로세스에 얼마나 많은 마찰을 유발하는 요소를 추가하는지 신중하게 살펴보셔야 합니다. 그리고 에이전트의 경우, 그렇죠, 에이전트들은 사일로처럼 고립되어 운영되는 게 아닙니다. 이들은 다른 데이터 소스와 연결해 운영됩니다. 이들은 다른 에이전트들과 협업하면서 연결됩니다. 따라서 전체적인 상호연결 구조를 함께 고려해야 하고, 그 부분이 바로 ‘여기에 보안을 어떻게 적용할 수 있을까’라는 관점에서 충분히 적용 여지가 있는 영역입니다. 엣지에서는 무엇을 하시나요? 그 연결 경로에서는 무엇을 하시나요? 그래서 저희는 프록시 아키텍처가 매우 강력하다고 생각합니다. 과제의 핵심은 그것을 어떻게 적용하느냐에 있고, 그 트래픽이 에이전트 트래픽일 때와 다른 어떤 종류의 트래픽일 때 각각 무엇이 같고 무엇이 다른지 어떻게 구분하느냐에 있습니다.

좋습니다, 이 주제 흐름을 계속 이어가겠습니다. 그래서 저희 모두가 익숙한 전통적인 웹 프록시를 예로 들면, 제가 인터넷으로 나갈 때 골드만삭스 정책의 Zscaler 엔포서가 중간에 위치해 연결의 프록시를 오케스트레이션하게 됩니다. 에이전트와 관련해서 저희가 받는 질문은, 보시다시피 그들이 일시적(에페머럴)이라는 점과 관련된 부분입니다. 이들은 훨씬 더 빠르게 생성됐다가 종료됩니다. 그리고 근본적으로, 에이전트가 세션을 구동하는 방식 자체에 이전에 말씀드린 엔포서 지점에서 이를 제대로 엔포스하고 관측하기 어렵게 만드는 요소들이 있어서, 결과적으로는 접근 방식이 달라지게 됩니다.

네. 웹 프록시용으로 처음 만들어진 툴을 어떻게 에이전틱 프록시로 확장하는지, 일반인도 이해할 수 있는 수준으로 설명해 주실 수 있을까요?

네, 좋습니다. 그 부분을 확실히 전달하기 위해, 제가 아마도 아주 생생한 예시 하나를 들어 설명드리겠습니다. 대부분의 커뮤니케이션이나 대부분의 세션에서는, 앞서 제가 설명드린 것처럼 사람이 이를 주도하고 있다면, 어떤 행동을 허용해야 하는지 아닌지를 이해하고 판단하고 싶어집니다. 그리고 기본적으로 그 판단을 밀리초 단위로 내려야 합니다. 그보다 조금이라도 더 오래 걸리면 사용자는 뭔가 문제가 있다고 느끼고 이탈해 버리거나, IT 티켓을 접수하거나, 아예 우회 경로를 찾아버립니다. 그러니 이것이 좋은 웹사이트인지 나쁜 웹사이트인지, 또는 이 거래를 허용해야 하는지 말아야 하는지를 판단할 시간이 길게 주어지는 게 아닙니다. 그래서 예를 들어 인라인 DLP에서는 아주 빠른 패턴 매칭을 찾아냅니다. 네, 그건 민감한 콘텐츠입니다. 제 정책에 따르면 민감한 콘텐츠는 외부로 나가도록 허용되지 않습니다. 그러니까 허용되지 않는 거죠, 맞나요? 그리고 그에 따라 실제로 의사결정을 내리게 됩니다. AI에서는, 예를 들어 사람이 생성형 AI 채팅 인터페이스나 에이전트와 함께 작업하는 경우에도 마찬가지로, 반복적으로 주고받는 대화가 실제로 그 방식으로 작동합니다. 그러니까 ‘쿠키’가 언급된 한 줄짜리 요청의 의도는, 예를 들어 초콜릿 칩 쿠키 레시피를 말하는 거라고 할 수 있겠죠, 맞나요?

여섯 번에 걸쳐 여러 차례 주고받는 대화라면, 특정 거래를 위해 인증 토큰을 담고 있는 세션 쿠키에 관한 내용일 수도 있습니다. 그리고 그 경우에는 외부로 전송되는 정보가 훨씬 더 민감한 내용일 수 있습니다. 그래서 실제로는 AI 용어로 말하자면 컨텍스트 윈도우를 봐야 하고, 즉 대화의 여러 턴을 이해해야 합니다. 그러다 보니 점검하는 방식, 다시 말해 검사하는 방식이 달라집니다. 그리고 무엇을 보호하려고 하느냐에 따라 확인해야 할 대상도 달라지기 시작합니다. 보다 전통적인 환경에서는 취약점이 있는지, 악성코드인지, 익스플로잇이 유입되고 있는지, 아니면 데이터가 유출되고 있는지를 살펴봅니다. 그런데 AI 환경에서는 누군가 제 모델을 포이즈닝하려고 하는지, 즉 모델에 오염을 시도하고 있는지를 보고 있을 수도 있습니다. 누군가 이 모델이 원래 하도록 되어 있지 않은 일을 하게 만들려고 하는 건가요? 거기에는 취약점이 없습니다. 그러니까 취약점을 악용했다는 시그니처 같은 것도 없다는 뜻입니다. 사이버 분야는 대체로 그런 방식으로 작동하는 경우가 많습니다. 그리고 AI 통신을 프록시로 중계할 때는, 그 트래픽을 검사하기 위해 서로 다른 종류의 인스펙션 엔진이 필요합니다.

아마 이 부분은 고객 여정을 조금 짚어보는 방식으로 설명드리는 게 좋을 것 같습니다. 그리고 케빈도 대화에 함께 참여해주시겠습니다. 지난 5~6개월 동안 대형 고객사들과 만나실 때, 지스케일러와 고객 간의 대화가 이런 새로운 AI 리스크를 보다 포괄적으로 다루는 방향으로 어떻게 바뀌고 있는지 조금 말씀해 주시겠습니까? 그리고 그 해답이 제로 트러스트 아키텍처일 수도 있을까요? 다만 현장에서 그런 대화가 실제로 어떤 식으로 오가는지 분위기 정도만 말씀해 주시겠습니까?

죄송합니다, 케빈이라고 하셨네요. 아, 세 번이나요. 아니요, 아니요, 괜찮습니다. 발언 차례가 고객님께 넘어가는 줄 알았습니다. 아니요, 아니요, 괜찮습니다. 보시면, 그런 대화는 분명히 속도가 붙었고 훨씬 더 강도도 세졌습니다. 특히 ‘미토스’ 측면에서도 그렇고, 아시다시피 기업들이 자신들에게 취약점과 익스포저가 존재한다는 현실에 대응하려고 애쓰면서 더더욱 그렇습니다. 대부분은 이전에는 자기들에게 그런 것들이 있는지도 몰랐던 것들이잖아요, 그렇죠? 그래서 이들 기업의 익스포저와 위협 수준은 6개월 전보다 지금이 훨씬 더 큽니다. 그리고 이제 질문은, 그걸 어떻게 대응하느냐, 그렇죠? 저는 뭘 해야 하나요? 그리고 현실적으로 패치만으로는 이 문제를 해결할 수 없다고 생각합니다. 이미 오래된 장비가 있어서, 그러니까 어떤 경우에는 더 이상 운영되지도 않을 수 있습니다. 패치로는 안 됩니다. 패치를 하기 전에 먼저 업그레이드해야 하는 오래된 운영체제를 쓰고 계실 수도 있습니다. 그러니까 이런 문제를 단순한 전통적 방식으로 해결할 수 있을 정도로 환경이 단순하지가 않아서, 점점 더 어려워지고 있습니다. 또한 공격 노출 범위가 커지고 침해가 발생하기까지의 시간은 점점 더 짧아지고 있습니다. 그래서 대화의 핵심은 ‘그럼 제가 뭘 해야 하죠?’가 됩니다. 이에 대한 저희의 답변은 아주, 아주 간단합니다.

귀사의 애플리케이션을 숨기셔야 합니다. 즉, 공격 표면을 완전히 줄이고, 잠재적 침해가 발생하더라도 내부에서 횡적 이동을 할 수 있는 가능성을 없애야 합니다. 그래서 많은 대화의 초점은 오늘날의 리스크를 어떻게 해결할 것인지, 그리고 아시다시피 모든 것이 너무 빠르게 변화하는 상황에서 앞으로도 귀사의 환경을 안전하게 보호할 수 있도록 저희가 어떻게 지원할 수 있을지에 맞춰져 있습니다.

패치 적용만으로는 문제가 해결되지 않는다는 말씀을 계기로, 프런티어 모델에 대해 여쭤보고 싶습니다. 아담, 이 질문은 아마 당신께 드리는 게 맞을 것 같습니다. 보안 분야에서 프런티어 모델이 어떤 역할을 한다고 보시나요? 결국 각 스윔레인이 어디에서 수렴하고, 어디에서는 계속 분리된 채로 남아 있을 거라고 보시나요?