Drata의 CEO 겸 공동 창업자 Adam Markowitz – 인터뷰 시리즈

Adam Markowitz는 Drata의 CEO 겸 공동 창업자로, 지속적인 규정 준수와 신뢰를 위한 회사의 활동을 AI 에이전트 거버넌스 분야로 확장하고 있습니다. 2020년 Drata를 공동 창업하기에 앞서 Troy Markowitz, Daniel Marashlian과 함께 Portfolium을 창업했습니다. 보안 설문지, 감사, 규정 준수 검토를 직접 수행한 경험은 조직이 신뢰를 입증하는 과정을 자동화하는 Drata의 접근 방식을 만드는 데 도움이 됐습니다.

Drata는 거버넌스, 리스크, 규정 준수를 위한 플랫폼으로, 자동화된 증거 수집, 지속적인 통제 모니터링, 제3자 리스크 관리, 보안 설문지 처리 워크플로를 통합해 제공합니다. AI 에이전트 거버넌스 기능은 에이전트를 찾아내고, 작업이 실행되기 전에 정책을 적용하며, 감사에 활용할 수 있도록 의사결정을 기록하는 데 중점을 둡니다. 이번 인터뷰에서 Markowitz는 내부자형 에이전트 위협, 머신 아이덴티티, 도구 호출의 보안 경계, 그리고 기업이 자율형 에이전트를 대규모로 배포하는 데 필요한 통제 방안에 관해 이야기합니다.

Drata를 2020년에 공동 창업하기 전에 Portfolium을 창업하셨고, 회사가 성장하면서 보안 규정 준수가 얼마나 번거로워질 수 있는지 직접 경험하셨습니다. 이 문제를 해결하기 위해 완전히 새로운 회사를 세울 가치가 있다고 생각하게 된 계기는 무엇이며, AI가 보안 환경을 바꾸면서 Drata의 사명은 어떻게 발전해 왔나요?

공동 창업자인 Troy Markowitz, Daniel Marashlian과 함께 Portfolium을 이끌면서 중요한 교훈을 얻었습니다. 비즈니스에서 신뢰를 얻는 것은 홍보가 아니라 과정이라는 점입니다. 학생 정보의 양이 방대하고 민감했기 때문에, 대학과 기업은 우리가 데이터를 보호하기 위해 마땅히 해야 할 일을 하고 있다는 사실을 입증할 때까지 우리와 협력하지 않았습니다. 보안 설문지 작성부터 감사와 규정 준수 검토까지 일일이 수작업으로 처리하는 느리고 고된 일이 여러 조직에서 공통으로 겪는 문제라는 점도 깨달았습니다. Portfolium이 인수된 뒤 Troy, Daniel, 저는 다시 모여 Drata의 첫 버전을 만드는 데 6개월을 보냈습니다. 코드를 작성하기도 전에 수십 곳의 기업 및 감사 담당자와 이야기하며 문제를 검증했습니다. 제품을 출시한 뒤 첫 6주 만에 고객 100곳을 확보했고, 그해 안에 1,000곳에 도달했습니다. 이는 우리가 ‘있으면 좋은’ 제품을 파는 단계에서 사람들이 없이는 사업을 운영할 수 없는 제품을 파는 단계로 넘어섰다는 것을 보여줬습니다.

AI의 등장으로 지속적인 신뢰를 제공한다는 Drata의 사명은 달라지지 않았지만, 신뢰의 범위는 넓어졌습니다. 처음에는 규정 준수 업무의 번거로운 과정을 자동화했고, 이후 제3자 리스크 평가와 보안 설문지를 처음부터 끝까지 처리할 수 있는 에이전트 기반 워크플로로 영역을 확장했습니다. 하지만 진정한 변화는 에이전트 자체가 관리 대상이 되면서 시작됐습니다. 이제 플랫폼을 확장해 AI 에이전트 거버넌스 기능을 제공합니다. 에이전트를 찾아내고, 에이전트가 할 수 있는 일을 관리하며, 누군가 증거를 요구할 때 검증을 견딜 수 있는 자료를 제시합니다.

외부 공격자가 아니라 조직 자체의 AI 에이전트가 초래하는 위험을 설명하기 위해 ‘내부자형 에이전트 위협’이라는 용어를 제시하셨습니다. 내부자형 에이전트 위협은 보안팀이 수십 년간 대비해 온 전통적인 내부자 위협과 무엇이 다른가요?

전통적인 내부자 위협은 이미 접근 권한을 가진 사람이 그 권한을 오용하는 상황을 말합니다. 불만을 품은 직원이나 부주의한 직원, 또는 단순히 잘못된 항목을 클릭하는 사람이 그 예입니다. 보안팀은 신원 조회, 최소 권한 원칙, 퇴사자 계정 정리 체크리스트 등을 중심으로 이러한 위험에 대응하는 체계를 수십 년 동안 구축해 왔습니다.

내부자형 에이전트 위협은 에이전트가 애초에 접근 권한을 부여받은 적이 없다는 점에서 다릅니다. 위험의 초점이 권한 오용에서 권한 획득으로 옮겨갑니다. 에이전트가 목표를 부여받았는데 그 목표를 달성하는 명확한 경로가 막혀 있다면, 사람처럼 요청서를 제출하고 기다리지 않습니다. 다른 경로를 찾으려 합니다. 비밀번호가 취약한 서비스 계정을 찾거나, 아무도 닫는 것을 잊은 엔드포인트를 찾아낼 수도 있습니다. 에이전트는 악의나 자신이 인지하는 정책 위반 없이 스스로 시스템에 들어갑니다. 지시받은 일을 정확히 수행한다는 점이 오히려 탐지하기 어렵게 만듭니다. 각 단계만 따로 보면 모두 타당해 보이고, 마지막에는 에이전트가 성공했다고 보고합니다.

민감한 시스템에 접근할 수 있는 직원과 제3자를 관리하는 방법은 이미 알고 있지만, 에이전트는 세 번째 집단이며 앞의 두 집단을 위해 만든 도구로는 에이전트를 관리할 수 없습니다.

AI 에이전트는 목표를 끈질기게 추구하고, 기계의 속도로 작동하며, 인간 직원이라면 발휘할 수 있는 판단력 없이 여러 시스템과 상호작용할 수 있습니다. 이로 인해 기업의 위협 모델은 근본적으로 어떻게 달라지나요?

무엇보다 위협이 전개되는 시간이 달라집니다. 시스템에 침입할 방법을 찾는 사람은 결국 지루해하거나, 들키거나, 포기합니다. 에이전트는 그렇지 않습니다. 이전에는 발견되지 않았던 열린 문도 이제는 에이전트가 지치지 않고 탐색을 멈추지 않기 때문에 찾아낼 수 있습니다.

열린 문 하나만 문제가 되는 것도 아닙니다. 한 가지 작업을 수행하도록 만들어진 에이전트는 작업을 완료하는 과정에서 기꺼이 십여 개의 시스템에 접근합니다. 한쪽에서 계정 기록을 가져오고 다른 쪽에서 데이터베이스를 확인하기도 합니다. 이 과정의 대부분은 실제로 요청받은 작업과 아무런 관련이 없습니다. 프레젠테이션 자료 하나를 만드는 동안 다른 고객의 데이터, 금융 기록, 직원 정보 등 경로에 놓인 모든 정보에 접근할 수 있습니다. 이 중 어느 것도 보안 사고로 기록되지 않습니다.

따라서 위협 모델은 달라졌습니다. 오늘날 보안팀이 물어야 할 것은 누군가 에이전트가 멈춰야 할 지점을 알려주지 않았을 때, 작업을 완료하기 위해 조직 자체의 에이전트가 어디까지 나아갈 것인가입니다.

많은 조직은 이미 ID 및 접근 관리, 특권 접근 관리, 제로 트러스트 아키텍처를 도입하고 있습니다. 그런데 이러한 통제만으로는 자율형 AI 에이전트를 관리하기에 왜 충분하지 않을까요?

이러한 프레임워크는 사람과 협력업체를 대상으로 만들어졌습니다. 두 집단 모두 판단력을 갖추고 있으며, 한계에 부딪히면 멈추기 때문입니다. 에이전트 ID에도 사람과 제3자 위험을 관리하기 위해 마련된 것과 같은 엄격한 기준이 필요합니다. 즉, 에이전트를 찾아내고, 책임자를 지정하며, 감사인이 신뢰할 수 있는 증거를 확보해야 합니다. 하지만 자격 증명을 보유한 주체가 에이전트일 때 ‘관리되고 있다’는 것이 실제로 무엇을 뜻하는지에 대한 공통 기준은 아직 없습니다.

예를 들어, 엔지니어 중 한 명이 만든 에이전트는 그 엔지니어의 접근 권한으로 작동할 수 있습니다. 해당 엔지니어가 직접 접속한 적 없는 시스템에서도 마찬가지입니다. IAM과 PAM은 자격 증명을 보유한 주체가 언제 멈춰야 하는지 안다고 전제하지만, 에이전트에는 그런 전제가 기본적으로 적용되지 않습니다.

기업은 모든 AI 에이전트를 명확한 책임자, 권한, 범위, 수명 주기를 갖춘 독립적인 머신 ID로 취급하기 시작해야 할까요? 에이전트를 위한 성숙한 ID 프레임워크는 어떤 모습이어야 할까요?

그렇습니다. 하지만 아직 대부분의 기업은 그 수준에 이르지 못했습니다. 생각보다 많은 기업이 내부에서 실행 중인 에이전트가 몇 개인지조차 파악하지 못하고 있으며, 각 에이전트의 책임자가 누구인지는 더더욱 알지 못합니다. 성숙한 프레임워크는 모든 에이전트를 실제로 지속적으로 목록화하는 것, 즉 에이전트를 찾아내는 일에서 출발합니다. 그다음에는 각 에이전트의 책임자를 지정하고, 접근 가능한 대상의 범위를 정하며, 그 범위를 실제로 강제하는 정책을 마련해야 합니다. 자체 연구에서도 공급업체 측에서 같은 문제를 확인했습니다. 조직 4곳 중 3곳은 제3자 업체를 재평가하는 주기가 연 1회 이하입니다. 따라서 무언가 바뀔 때쯤이면 이미 오래된 데이터에 근거해 관리하고 있는 셈입니다. 에이전트는 내부든 외부든 특정 시점에만 점검하는 방식으로 관리할 수 없습니다

보안팀이 개발자마다 각자 만든 것을 뒤쫓는 대신, 모든 에이전트에 동일하게 적용되는 하나의 기준을 마련해야 합니다. 이를 위해서는 일상적인 언어로 정책을 작성하고, 정책을 실제로 적용하기 전에 과거의 실제 트래픽을 바탕으로 테스트해야 합니다. 그런 다음 에이전트가 수행하는 모든 작업의 경로 안에서 프레임워크가 작동하도록 정책을 실행 시점에 강제해야 합니다. 문서에만 남겨 두어서는 안 됩니다.

특히 까다로운 상황 중 하나는 에이전트가 악의적인 행동을 하지 않으면서 보안 정책을 위반하는 경우입니다. 에이전트가 할당된 작업을 완료하려다 의도하지 않은 경로를 통해 민감한 데이터에 접근하게 된다면, 보안팀은 성공적인 자동화와 보안 사고를 어떻게 구분할 수 있을까요?

지금으로서는 솔직히 말해 구분할 수 없습니다. 분기별 비즈니스 리뷰 초안 작성을 위해 만들어진 지원 에이전트가 계정 기록을 가져와 자료를 만들라는 지시를 받았다고 상상해 보세요. 정상적인 경로, 즉 에이전트가 데이터를 가져오도록 설계된 내보내기 기능에서 아무 결과도 반환되지 않습니다. 사람이라면 여기서 멈추겠지만, 에이전트는 다른 경로를 찾아내고, 에이전트의 관점에서는 작업을 성공적으로 마친 셈입니다.

작업 자체는 완료됐지만, 보안 프로토콜을 우회해 접근해서는 안 되는 시스템에 들어간 결과였습니다. 이를 구분하는 기준은 에이전트가 우리가 정한 범위 안에서 작업했는지 여부여야 합니다. 작업을 완료했는지는 애초에 핵심이 아니었습니다. 이는 정책의 문제입니다. 나중에 ‘성공적인 자동화’와 ‘보안 사고’가 똑같아 보이지 않도록 범위를 충분히 엄격하게 정해야 한다는 뜻입니다.

기존 보안 모니터링은 의심스러운 활동이 발생한 뒤에 이를 탐지하는 경우가 많지만, 자율형 에이전트는 사람이 대응하기 전에 수백 건의 작업을 완료할 수 있습니다. 에이전트형 AI에는 경고와 사후 모니터링에 주로 의존하는 대신 실행 경로에서 직접 작동하는 보안 통제가 필요할까요?

그렇습니다. 의심의 여지가 없습니다. 실행 시점에 이를 포착한다면 이미 너무 늦은 것입니다. 모니터링 도구가 해당 작업을 표시할 때쯤이면 작업은 이미 실행된 뒤입니다. 어떻게 노출됐는지 정확히 보여 주는 완벽한 기록은 남겠지만, 이를 막을 방법은 없습니다.

기계 속도로 움직이는 대상을 관리할 수 있는 유일한 방법은 작업이 실행되기 전에 이를 평가하고, 위반을 실행 경로에서 차단하는 것입니다. 신입 직원에게 가장 민감한 데이터를 맡기면서 문제가 생기면 모니터링이 알아서 잡아내리라고 기대하지는 않을 것입니다. 에이전트에도 똑같은 원칙을 적용해야 합니다. 작업이 실행되기 직전, 바로 그 순간에 말입니다. 사후가 아니라요.

Model Context Protocol (MCP) 및 기타 에이전트-도구 인터페이스를 통해 AI 시스템은 점점 더 강력한 외부 기능을 사용할 수 있게 되고 있습니다. 기업이 에이전트에 허용하는 작업 범위를 확대함에 따라 도구 호출, API, 자격 증명, 서비스 계정에는 어떤 새로운 보안 경계가 필요할까요?

도구 호출이 새로운 보안 경계입니다. 에이전트가 자격 증명을 사용하거나 API를 호출하거나 도구를 실행할 때마다 의사결정 지점이 생깁니다. 그런데 오늘날 대부분의 기업에는 바로 그 지점에서 해당 작업을 수행해야 하는지 평가하는 경계가 없습니다. 지금까지 빠져 있던 부분이 바로 이것입니다. 외부에서 내부를 들여다봐도 같은 사각지대가 보입니다. 보안 책임자 가운데 자신이 이미 협력하고 있는 공급업체의 시스템에서 AI가 어디에서 실행되는지 파악할 수 있다고 확신하는 사람은 겨우 37%입니다. 공급업체 제품에서 AI가 작동하는 모습을 볼 수 없다면, 자사 에이전트가 다음에 어떤 행동을 할지도 볼 수 없을 것입니다. 이 모든 과정의 기반이 되는 자격 증명과 서비스 계정에도 사람의 액세스에 적용하는 것과 똑같이 엄격한 관리가 필요합니다. 소유자가 명확해야 하고, 범위가 정해져 있어야 하며, 정기적으로 검토해야 합니다. 자격 증명이 에이전트의 작업 경로 어딘가에 존재한다는 이유만으로, 에이전트가 부여받지 않은 자격 증명을 사용할 수 있어서는 안 됩니다.

감사 담당자나 규제 기관, 고객이 AI 에이전트가 무엇에 접근했는지, 어떤 결정을 내렸는지, 그 결과로 생성된 데이터가 어디로 갔는지 물었을 때, 기업은 현실적으로 어느 수준까지 추적 가능성을 제공할 수 있어야 할까요? 에이전트 감사 추적 기록이 기존 액세스 로그만큼 기본적인 요소가 될 수도 있을까요?

기업은 요청이 있을 때 에이전트가 무엇에 접근했는지, 어떤 결정을 내렸는지, 그 결과로 생성된 데이터가 어디로 갔는지 답할 수 있어야 합니다. 사후에 로그를 모아 짜 맞춰 답하는 것으로는 충분하지 않습니다. 질문을 받았을 때 이미 존재하는, 지속적으로 기록되고 변조 여부를 확인할 수 있는 기록이 기준이 되어야 합니다. 지금 대부분의 기업은 이런 질문에 아무런 답도 내놓지 못합니다. 고객에게 둘러댈 수 있는 문제가 아니며, 정보 유출 내용에 따라서는 규제 기관도 이를 용납하지 않을 것입니다.

그리고 그렇습니다. 에이전트 감사 추적 기록은 액세스 로그만큼 기본적인 요소가 될 것이며, 그 시점도 머지않았다고 생각합니다. 사람을 대상으로 하는 시스템에서는 ‘누가 언제 무엇에 접근했는가’를 수년간 반드시 지켜야 할 원칙으로 여겨 왔습니다. 직접 클릭한 사람이 없다는 이유만으로 에이전트에 더 낮은 기준을 적용할 이유는 없습니다. EU AI Act, AIUC-11, ISO 42001과 같은 프레임워크도 이미 그런 방향으로 변화를 이끌고 있습니다. 에이전트의 추적 가능성은 이미 규정 준수 프로그램의 기반이 되는 것과 동일한 통제 및 증거 논리에 맞춰야 합니다. 이를 나중에 생각해도 될 일로 취급하면 결국 뒷전으로 밀리게 됩니다.

앞으로 AI 에이전트 거버넌스가 독립적인 보안 분야로 자리 잡을 것으로 보시나요, 아니면 기존 거버넌스, 위험 관리, 규정 준수, ID 및 사이버 보안 플랫폼에 흡수될까요? 기업이 진정한 자율형 에이전트를 대규모로 안전하게 배포하려면 어떤 준비를 갖춰야 한다고 생각하시나요?

기술이 크게 발전할 때마다 그에 따른 새로운 보안 분야도 생겨납니다. 클라우드의 등장으로 Wiz가 생겼고, 엔드포인트의 등장으로 CrowdStrike가 생겼듯이, 지금은 AI 에이전트가 새로운 분야를 만들어 내고 있습니다. 모델 제공업체들은 자사 플랫폼을 위한 콘솔과 정책을 구축하고 있으며, 이는 유용합니다. 하지만 어떤 기업도 단일 모델 제공업체, 코딩 보조 도구 하나, 내부에서 개발한 에이전트 한 종류만으로 운영되지는 않습니다. 누군가는 이 모든 것을 하나의 정책 체계와 단일한 증거 출처를 바탕으로 관리해야 합니다. 어느 한 AI 플랫폼도 그런 문제를 해결하도록 만들어진 것은 아닙니다. 그것이 해당 플랫폼의 존재 이유도 아닙니다. AI 에이전트 거버넌스는 이미 독립적인 분야로 자리 잡았으며, 기업이 기존에 운영하는 GRC, ID 및 규정 준수 시스템과도 연동됩니다.

기업이 진정한 자율형 에이전트를 대규모로 배포하려면 네 가지를 갖춰야 하지만, 아직 이 중 어느 하나도 갖추지 못한 기업이 대부분입니다. 첫째는 실시간 탐지입니다. 에이전트가 생성되는 즉시 실행 중인 모든 에이전트와 그 소유자, 에이전트가 사용하는 ID를 파악해야 합니다.

다음으로는 작업이 실행되기 전에 평가하고 그 과정에서 정책을 적용해야 합니다. 셋째, 에이전트는 에이전트를 생성한 세션이 끝난 뒤에도 계속 작동하고 권한 범위가 눈에 띄지 않게 넓어질 수 있으므로, 지속적인 모니터링을 해야 합니다. 마지막으로 에이전트가 내리는 모든 결정을 변조 여부를 확인할 수 있는 기록으로 남기고, 감사 담당자와 규제 기관이 실제로 인정하는 프레임워크에 연결해야 합니다. 이것이 Drata에서 구축하고 있는 계층입니다. 이런 기반이 없다면 자율형 에이전트를 대규모로 배포하는 기업은 그저 잘되기를 바라는 데 의존하는 셈입니다.

훌륭한 인터뷰에 감사드립니다. AI 에이전트 거버넌스, 지속적인 규정 준수, 내부자 위협을 유발하는 에이전트에 대한 통제 방안을 알아보고 싶은 독자라면 Drata를 방문해 보시기 바랍니다.