Shannon McWilliams, Orca Security 글로벌 유통 총괄 – 인터뷰 시리즈

Shannon McWilliams는 Orca Security에서 글로벌 유통 총괄을 맡고 있으며, 파트너 생태계와 이를 뒷받침하는 도구 전반을 담당하고 있습니다. 과거 소프트웨어 개발 회사를 창업한 경험을 바탕으로 비즈니스 요구를 애플리케이션으로 구현하는 데 필요한 역량을 갖추고 있습니다. 최근에는 AI 개발 도구를 활용해 Orca의 Partner Success Platform 초기 버전을 만들고, 보안팀과 협력해 주말 동안 만든 시제품을 실제 운영 환경에 배포할 수 있는 시스템으로 발전시켰습니다.

Orca Security는 조직이 자산을 발견하고, 위험을 파악해 우선순위를 정하며, 클라우드 환경을 보호하도록 지원하는 클라우드 보안 플랫폼을 제공합니다. 취약점, 잘못된 구성, ID 및 권한, 민감 데이터, AI 보안 등 다양한 영역을 다룹니다. 이번 인터뷰에서 McWilliams는 AI가 비즈니스 사용자의 소프트웨어 개발을 어떻게 가능하게 하는지, 실제로 작동하는 애플리케이션에도 독립적인 보안 검토가 필요한 이유, 그리고 지속적인 탐색, 최소 권한 원칙, 사람의 감독이 기업의 새로운 개발 모델 관리에 어떻게 도움이 되는지 이야기합니다.

Orca Security에 글로벌 유통 총괄로 합류한 지 몇 달 만에 AI를 활용해 직접 새로운 파트너 플랫폼을 구축하게 됐습니다. 처음에 해결하려던 문제는 무엇이었으며, 이 프로젝트는 언제 단순한 실험에서 Orca가 실제 운영 환경에 배포할 수 있는 단계로 발전했나요?

Orca에 합류했을 때 파트너 경험 전반을 살펴보라는 요청을 받았습니다. 당시에는 타사 플랫폼을 사용하고 있었지만, 파트너를 위해 더 현대적이고 간결한 솔루션을 만들 기회가 있다고 생각했습니다. 애플리케이션 개발 경험은 조금 있었지만, 개발자로 일한 것은 아니었습니다. 그해 여름 초에 타사 앱 생성 플랫폼 제공업체의 플랫폼으로 소비자용 애플리케이션을 작업한 적이 있어, AI를 활용해 제가 직접 무엇을 만들 수 있을지 실험해 보기로 했습니다.

주말 동안 Partner Success Platform의 기초가 된 첫 번째 버전을 만들 수 있었습니다. 여기에는 이상적인 고객 매칭과 딜 코칭처럼 기존 파트너 포털에서 보지 못했던 기능도 포함됐습니다. 플랫폼에 인증 추적, AI 생성 퀴즈 등 여러 애플리케이션을 추가하고 파트너를 위한 인증 절차 전체를 게임화한 뒤, Salesforce 플랫폼과 데이터 동기화를 시작했습니다. CEO가 초기 버전을 보고 그 잠재력을 알아본 것이 전환점이었습니다. 그때부터 실험을 넘어 이런 시스템을 안전하게 구축해 실제 운영 환경에 배포하려면 무엇이 필요한지 고민하기 시작했습니다. 보안팀이 참여했고, 외부 업체의 독립적인 검증을 받기 전에 Dudi Peretz와 긴밀히 협력해 환경을 안전하게 보호하기 시작했습니다.

과거 소프트웨어 개발 회사를 창업하셨으니, 전통적인 방식으로 애플리케이션을 구축하는 과정을 잘 아실 텐데요. 자연어 기반 AI를 통해 소프트웨어를 만드는 일은 개발자들을 관리하는 방식과 어떻게 달랐으며, 이 과정에서 본인의 도메인 전문성이 가장 중요했던 부분은 어디였나요?

가장 큰 차이는 속도였습니다. 전통적인 소프트웨어 개발에서는 아이디어를 떠올린 뒤 이를 기술 요구사항으로 구체화하고, 개발자가 구현한 다음 결과물을 반복해서 개선하기까지 보통 여러 단계가 필요합니다. AI를 이용하면 원하는 것을 설명하고, 구현되는 모습을 확인한 뒤 거의 즉시 계속 다듬을 수 있었습니다. 원하는 UI와 기능 구현을 위한 데이터베이스 매핑을 정의하려고 개발자들과 며칠씩 회의하던 반복 작업이 이제는 몇 분이면 끝납니다. AI 개발에서는 이틀간의 회의 대신 두 문장짜리 프롬프트만으로 가능합니다.

하지만 전문성이 더는 필요하지 않다는 뜻은 아닙니다. 전문성이 필요한 지점이 달라지는 것입니다. AI는 애플리케이션 구축의 기술적 장벽을 크게 낮출 수 있지만, AI를 이끄는 사람은 여전히 해결하려는 문제가 무엇인지, 유용한 사용자 경험이 어떤 모습인지, 애플리케이션이 궁극적으로 비즈니스에서 어떤 역할을 해야 하는지 이해해야 합니다. 가장 놀라웠던 점은 아이디어에서 실제로 작동하는 결과물까지 이르는 시간이 얼마나 짧아졌는지였습니다. 예전에는 몇 주가 걸릴 수도 있었던 데이터 분석 같은 작업도 이제는 잠재적으로 하루 만에 끝낼 수 있습니다.

Orca는 파트너 플랫폼의 첫 작동 버전을 주말 한 번 동안 구축했다고 설명했습니다. AI를 활용하면 어떤 작업을 크게 앞당길 수 있었으며, 실제 운영 환경에 배포할 수 있는 애플리케이션을 구축하는 과정에서 처음 생각했던 것보다 여전히 어려웠던 부분은 무엇이었나요?

AI 덕분에 아이디어가 실제 작동하는 애플리케이션으로 이어지는 과정이 크게 단축됐습니다. 전통적인 방식이라면 훨씬 더 긴 개발 과정이 필요했을 기능을 주말 동안 만들 수 있었고, 기능을 계속 추가하고 변경하는 일도 매우 빠르게 진행할 수 있었습니다. 그 속도는 놀랍기도 하고 조금은 두렵기도 합니다.

AI가 없애 주지 않은 것은 애플리케이션을 안전하게 실제 운영 환경에 배포하는 데 필요한 모든 과정이었습니다. 이를 실제 서비스로 만들 수 있다고 판단한 뒤에는 보안팀이 환경을 평가하고, 보안 문제를 해결하며, 애플리케이션이 적절히 보호되는지 확인해야 했습니다. 검증을 한층 강화하기 위해 외부 업체도 참여시켰습니다. 따라서 AI 덕분에 구축 속도는 믿기 어려울 만큼 빨라졌지만, “작동한다”는 것과 “기업 환경에서 안전하게 운영할 준비가 됐다”는 것은 여전히 서로 다른 기준입니다.

AI 개발 플랫폼 자체의 보안 도구는 애플리케이션이 안전하다고 판단했지만, 이후 Orca의 검토에서 권한 및 데이터 액세스와 관련된 문제가 드러났습니다. 이 경험을 통해 비즈니스 사용자가 AI 개발 플랫폼이 제공하는 보안 보장을 얼마나 신뢰해야 하는지에 대해 무엇을 배우셨나요?

이 경험에서 얻은 가장 큰 교훈 중 하나였을 겁니다. 플랫폼에는 자체 보안 검사 기능이 있었고, 애플리케이션을 개발하는 동안 유용한 기준점이 되어 주었습니다. 하지만 보안팀과 검토 절차를 거치면서 권한 및 데이터 액세스 같은 영역을 특히 면밀히 살펴볼 수 있도록 검토를 한층 강화하는 것이 얼마나 중요한지 알게 됐습니다. 이 경험을 통해 기본 탑재된 보안 도구는 개발 과정에서 중요한 역할을 하지만, 전담 보안팀이 제공할 수 있는 더 깊은 맥락과 전문성을 함께 활용할 때 가장 효과적이라는 점을 다시금 확인했습니다.

이 점은 특히 중요합니다. 이제 AI로 애플리케이션을 만들 수 있는 사람들 가운데 보안 전문가가 아닌 경우가 많기 때문입니다. 어떤 질문을 해야 하는지, 권한 범위가 지나치게 넓은지, 어떤 설정이 데이터를 노출할 수 있는지 모를 수도 있습니다. 개발 플랫폼이 애플리케이션이 안전하다고 알려주는 것으로 절차가 끝나서는 안 됩니다. 애플리케이션을 게시하거나 민감한 엔터프라이즈 시스템에 연결하기 전에, 플랫폼 자체 검사에 통과했는지만 확인하는 데 그치지 않는 종합적인 보안 검토를 거쳐야 합니다.

보안팀이 취약점을 발견했을 때, 그 결과를 AI 개발 환경에 다시 입력해 몇 분 만에 수정 사항을 생성할 수 있는 경우가 많았습니다. AI가 보안 문제 해결을 긴 개발 주기에서 벗어나 개발자와 보안팀 간의 지속적인 대화로 근본적으로 바꿀 수 있을까요?

이는 가장 기대되는 가능성 중 하나입니다. Dudi와 보안팀이 문제를 찾아내면, 그 피드백을 AI 개발 환경에 바로 입력해 매우 빠르게 수정 사항을 생성할 수 있었습니다. 이를 통해 애플리케이션을 만드는 사람과 애플리케이션의 보안을 책임지는 팀 사이에 훨씬 더 긴밀한 피드백 순환 구조를 만들 수 있습니다.

과거에는 소프트웨어를 개발하고 출시하는 데 훨씬 더 오랜 시간이 걸리곤 했습니다. 이제는 누군가 매일 변경 사항을 적용하고 게시할 수 있습니다. 보안도 그와 같은 속도로 움직여야 합니다. 지속적인 보안 평가를 개발 과정에 포함하면 문제를 파악하고, 개발자에게 알리고, 문제를 해결한 뒤, 애플리케이션을 훨씬 더 빠르게 재평가할 수 있습니다.

하지만 문제를 빠르게 해결한다고 해서 검증 기준을 낮춰도 된다는 뜻은 아닙니다. AI가 빠르게 수정 사항을 생성할 수는 있지만, 보안팀은 그 수정 사항이 실제로 위험을 해결했으며 또 다른 위험을 초래하지 않았는지 확인할 방법이 여전히 필요합니다.

그 결과 탄생한 Partner Success Platform에는 AI 어시스턴트, 파이프라인 인텔리전스, 캠페인 생성 기능, 거래 코칭 기능이 포함되어 있습니다. AI가 직접 처리해야 할 활동과 파트너 또는 영업 담당자가 직접 결정해야 할 사안을 어떻게 구분하셨나요?

저는 파트너 업무나 영업 과정에서 사람을 배제하는 것이 목표가 아니었습니다. AI를 활용해 사람들이 더 빠르게 일하고 이미 이용할 수 있는 정보를 더 효과적으로 활용하도록 돕는 것이 목표였습니다. 거래 코칭이 좋은 예입니다. AI는 파이프라인에 오래 머물러 있는 영업 기회를 진전시킬 방법을 찾고, 추가적인 맥락이나 권장되는 다음 단계를 제공하는 데 도움을 줄 수 있습니다.

제가 중요하다고 생각하는 구분은 AI가 여러 시스템에서 정보를 빠르게 가져와 관련성을 분석한 다음, 사용자가 이를 바탕으로 행동할 수 있는 형태로 제공하는 능력과 관련이 있습니다. 플랫폼은 파트너나 영업 담당자의 업무 효율을 높여야 하지만, 비즈니스 판단이 필요한 의사결정에 대한 책임은 사람에게 남아 있어야 합니다. 목표는 플랫폼을 활용해 거래 발굴부터 계약 성사까지 걸리는 시간을 단축하는 것입니다.

AI 덕분에 영업, 마케팅, 재무 등 여러 부서의 직원이 엔지니어링팀을 거치지 않고도 직접 애플리케이션을 만들 수 있게 됐습니다. 이러한 애플리케이션이 고객 데이터, 내부 시스템 또는 클라우드 인프라에 연결되도록 허용하기 전에 어떤 최소한의 보안 및 거버넌스 통제 조치를 마련해야 할까요?

첫 번째 요건은 가시성입니다. 조직의 정책은 이러한 탐구와 혁신을 장려해야 하지만, 존재 자체를 모르는 애플리케이션은 보호할 수 없습니다. 따라서 혁신을 장려하면 직원들이 프로젝트를 숨기기보다 공개적으로 내놓을 가능성이 커집니다. 그다음 조직은 애플리케이션이 어떤 ID와 권한을 보유하는지, 어떤 데이터에 액세스할 수 있는지, 어떤 타사 시스템과 통신하는지, 그리고 그러한 권한이 실제로 필요한지를 파악해야 합니다. 혁신이 싹틀 수 있는 기반을 마련하되, 혁신을 추진하는 사람들을 지원하고 보안 요건도 충족하는 절차를 갖춰야 합니다.

최소 권한 원칙은 특히 중요합니다. 우리가 목격하는 위험 중 하나는 애플리케이션이 실제로 필요한 범위보다 더 광범위한 액세스 권한을 받는다는 점입니다. 또한 보안 검토는 출시 전에 한 번만 하고 끝낼 수 없습니다. 애플리케이션이 지속적으로 변경될 수 있다면 조직도 이를 지속적으로 재평가할 수 있어야 합니다.

전통적인 소프트웨어 거버넌스는 엔지니어링 팀, 풀 리퀘스트, 릴리스 주기, 그리고 비교적 통제된 배포 파이프라인을 중심으로 설계됐습니다. 이제 비즈니스 사용자가 애플리케이션을 지속적으로 수정하고 배포할 수 있다면, 기업의 소프트웨어 개발 수명 주기는 어떻게 달라져야 할까요?

근본적인 문제는 개발 속도가 달라졌다는 점입니다. 전통적으로 소프트웨어는 비교적 정립된 절차를 거쳐 일정 기간에 걸쳐 개발하고 출시했습니다. 하지만 AI 개발 도구를 이용하면 누구나 매일 새로운 것을 만들어 공개할 수도 있습니다. 이런 환경에서는 정기적인 점검 시점을 중심으로 마련된 보안 및 거버넌스 절차만으로는 충분하지 않습니다.

이제는 개발 주기에 발맞춰 지속적으로 작동하는 보안 체계로 나아가야 합니다. 그러려면 무엇이 개발되고 있는지 파악하고, 어떻게 구성되고 연결돼 있는지 이해하며, 변경 사항을 지속적으로 점검하고, 개발자가 빠르게 반영할 수 있는 실질적인 피드백을 제공해야 합니다. 직원들이 이런 도구를 사용하지 못하게 막는 것은 해법이 될 수 없습니다. 생산성 향상의 기회가 너무 크기 때문입니다. 혁신이 안전하게 이뤄지도록 보호 장치를 마련하는 것이 과제입니다.

AI로 만든 애플리케이션의 확산을 한층 더 까다로운 형태의 ‘섀도 IT’에 비유하셨습니다. 이 세대의 섀도 소프트웨어가 더 큰 과제가 될 수 있는 이유는 무엇이며, 보안팀이나 IT팀조차 존재를 모를 수 있는 애플리케이션을 조직은 어떻게 찾아낼 수 있을까요?

전통적인 섀도 IT는 직원들이 IT 부서의 승인을 받지 않은 SaaS 애플리케이션을 도입하는 경우가 많았습니다. 이제는 직원들이 직접 애플리케이션을 만들 수 있고, 그것도 매우 빠르게 만들 수 있다는 점이 다릅니다. 누군가 개인 계정으로 애플리케이션을 구축하고, 타사 시스템과 연동한 뒤, 보안팀이 존재를 알아차리기도 전에 기업 데이터에 연결할 수도 있습니다.

바로 이 점 때문에 특히 까다롭습니다. 애플리케이션을 너무 쉽게 만들 수 있게 되면서 그 수와 변경 속도가 기존 거버넌스의 대응력을 빠르게 넘어설 수 있기 때문입니다. CISO들은 같은 근본적인 질문에 직면해 있습니다. 무엇이 만들어졌는지, 또는 어떻게 구성됐는지조차 모를 수 있는 상황에서 어떻게 보안을 확보할 수 있을까요?

따라서 보안 전략의 핵심 요소로 탐지 기능을 갖춰야 합니다. 혁신을 주도하는 사람들을 지원하고 탐구를 장려하되, 프로젝트를 등록하도록 하는 것이 탐지 역량을 확보하는 좋은 방법입니다. 조직은 코드뿐 아니라 환경 전반에서 실행 중인 애플리케이션, 그 애플리케이션에 연결된 계정과 권한, 애플리케이션이 접근하는 데이터, 그리고 통신하는 외부 시스템까지 파악할 수 있어야 합니다.

앞으로 몇 년을 내다볼 때, 대다수 지식 노동자가 AI를 활용해 어떤 형태로든 소프트웨어 개발자가 될 것으로 보시나요? 그렇다면 기업 내 전문 개발자, 보안팀, 비즈니스 리더의 역할은 어떻게 달라질까요?

우리는 ‘소프트웨어 개발자’의 정의가 훨씬 넓어지는 세상으로 나아가고 있습니다. AI 덕분에 비즈니스 문제는 잘 이해하지만 전통적인 개발자는 아닌 사람들도 아이디어를 놀라울 만큼 빠르게 작동하는 애플리케이션으로 만들 수 있게 됐습니다. 저도 직접 그런 경험을 했습니다.

그렇다고 전문 개발자나 보안팀의 중요성이 줄어드는 것은 아니라고 생각합니다. 전문성이 필요한 영역이 달라지는 것입니다. 비즈니스 사용자가 점점 더 직접 솔루션을 만들 수 있게 되면서 개발자는 더 복잡한 기술적 문제에 집중할 수 있고, 보안팀은 새로운 세대의 개발자들이 안전하게 혁신할 수 있도록 가시성과 보호 장치를 마련해야 합니다. 애플리케이션 지원과 유지보수도 새로운 관점에서 바라볼 필요가 있습니다. ‘개발자’가 언제나 가장 적합한 ‘유지보수 담당자’인 것은 아닙니다. 개발자는 비전과 비즈니스 요구를 제시하지만, 애플리케이션을 장기적으로 지원하는 일은 여전히 IT 및 애플리케이션 담당 조직에 더 적합합니다. 비즈니스 리더에게는 엄청난 기회가 열리는 동시에 새로운 책임도 생깁니다. 팀이 소프트웨어를 만들 수 있다면, 소프트웨어 위험을 엔지니어링 부서만의 문제가 아니라 비즈니스의 일부로 생각해야 합니다.

훌륭한 인터뷰 감사합니다. 클라우드 보안, AI로 만든 애플리케이션, 기업 환경 보안에 대해 더 알고 싶은 독자라면 Orca Security를 방문해 보세요.