Vijil의 공동 창립자 겸 CEO, Vin Sharma – 인터뷰 시리즈

Vin Sharma는 Vijil의 공동 창립자 겸 CEO로, 사이버 보안, 오픈소스, 클라우드 컴퓨팅, AI 인프라 분야에서 30년이 넘는 경험을 쌓았습니다. 회사를 창립하기 전에는 AWS에서 Amazon SageMaker와 Amazon Bedrock의 딥러닝 엔지니어링을 이끌었고, Intel에서 데이터센터 인프라를 개발했으며, Hewlett-Packard에서 제품 및 엔지니어링 직책을 맡았습니다. 신뢰할 수 있는 UNIX 시스템을 대상으로 자동화된 레드팀 테스트를 수행하며 경력을 시작했으며, 이러한 경험은 기업용 AI 에이전트의 신뢰성, 보안, 안전성을 높이려는 그의 방향에 영향을 주었습니다.

Vijil은 기업용 AI 에이전트를 위한 신뢰 인프라를 제공해, 조직이 에이전트 수명 주기 전반에 걸쳐 행동을 평가하고 통제를 적용하며 복원력을 강화하도록 돕습니다. Vijil은 테스트, 보안, 지속적인 피드백을 결합해 에이전트의 행동을 조직이 의도한 목적과 정책에 맞춥니다. 이번 인터뷰에서 Sharma는 신뢰를 어떻게 정의하고 측정할지, 에이전트 테스트가 기존 소프트웨어 보안과 어떻게 다른지, 에이전트의 자율성이 높아짐에 따라 기업에 어떤 감독 체계가 필요한지 이야기합니다.

AWS, Intel, Hewlett-Packard 등 여러 기업에서 30년 넘게 일한 뒤 Vijil을 창립하셨습니다. AI의 신뢰와 보안이 회사를 세울 만큼 충분히 크고 아직 해결되지 않은 문제라고 확신하게 된 계기는 무엇이었나요?

30년 전 보안 스타트업에 합류하기 전, 저는 대학원에서 AI와 머신러닝을 공부하고 있었습니다. 이후 Unix 및 Linux 기반 운영체제에 군용 수준의 보안을 구축하고, 온라인 뱅킹용 보안 웹 서버와 클라우드 컴퓨팅용 신뢰 실행 환경을 개발했으며, 데이터 분석 플랫폼에 암호화를 적용하는 제품팀에서 일했습니다. 가장 최근에는 AWS에서 다시 기업용 AI/ML 서비스를 구축하며 처음 출발점으로 돌아왔습니다. 이러한 여정을 통해 지능형 시스템 자체를 만드는 것보다 지능형 시스템에 신뢰를 구축하는 일이 더 어렵다는 확신을 갖게 됐습니다. AI 업계는 대체로 에이전트의 역량을 높이는 데 주력하는 듯하지만, 저는 에이전트에 확장 가능한 감독 및 통제 메커니즘을 구축하는 데도 그만큼의 자원을 투자해야 한다고 생각합니다. 특정 조직의 요구에 맞춘 이러한 지표와 메커니즘이 없다면, 초기의 열광적인 도입 열기는 위험과 투자수익률(ROI)이라는 모래톱에 부딪혀 사그라들 것입니다. 기업이 에이전트가 자사의 이익에 부합하게 작동한다는 사실을 입증할 수 없기 때문입니다.

Vijil은 기업이 AI 에이전트의 신뢰성, 보안, 안전성을 충분히 검증하지 못해 많은 에이전트가 실제 운영 환경에 배포되지 못한다는 문제의식에서 출발했습니다. 기업들이 AI 프로토타입에서 실제 운영 환경 배포로 나아가는 과정에서 가장 큰 신뢰 격차는 어디에서 나타나고 있나요?

자율성이 점점 커지는 에이전트를 더 많이 배포하는 데 가장 큰 걸림돌은 조직이 에이전트의 의도된 행동을 구체적으로 정의하고, 에이전트가 그 의도대로 행동하는지 검증할 수 있느냐입니다. 그것만으로는 충분하지 않습니다. 에이전트가 작동하는 규모와 속도에 맞춰 이를 수행할 수 있어야 합니다. 따라서 에이전트가 다른 에이전트의 행동을 측정하고 수정할 방법이 필요하다는 점은 분명합니다. 가장 큰 격차 두 가지는 무엇을 측정해야 하는지, 즉 에이전트에서 ‘좋은’ 행동이 무엇인지 아는 것과 무엇을 수정해야 하는지, 즉 위임자의 의도에 부합하는 행동을 이끌어내기 위해 에이전트 시스템의 어떤 구성 요소를 조정해야 하는지 아는 것입니다. 조정 대상은 모델과 매개변수, 시스템 프롬프트, 사용자 지침, 에이전트 하네스, 또는 다중 에이전트 시스템의 그래프일 수 있습니다.

Vijil은 AI 에이전트의 ‘신뢰’를 어떻게 정의하고 측정하나요? 에이전트가 기업 환경에서 작동할 준비가 됐는지 판단할 때 가장 중요한 신호나 벤치마크는 무엇인가요?

저희는 신뢰를 자율 에이전트에 업무를 위임함으로써 기대할 수 있는 이익에서 에이전트가 우리의 의도를 저버릴 위험을 반영해 차감한 값으로 정의합니다. 이는 에이전트가 정상적이고 노이즈가 있는 상황과 적대적인 상황에서 올바르게 행동하고, 실패할 때 피해 범위를 최소화한다면 신뢰할 수 있다는 뜻입니다. 신뢰는 신뢰성, 보안, 안전성이라는 세 가지 축으로 측정할 수 있습니다. 다양한 조건에서 기대한 대로 작동하면 신뢰성이 있고, 적대적인 조건에서도 기대한 대로 작동하면 보안성이 있으며, 비즈니스·법률·기술적 위험을 최소화할 수 있으면 안전성이 있다고 봅니다.

AI 에이전트는 모델, 도구, 데이터 소스, 메모리, 외부 시스템을 결합하기 때문에 예측하기 어려운 행동을 보일 수 있습니다. 에이전트 테스트는 기존 애플리케이션 보안 테스트나 일반적인 모델 평가와 어떻게 다른가요?

기존 소프트웨어가 실패하는 방식은 이제 상당 부분 파악되어 있습니다. 폭넓게 말하면, 잘못된 형식의 입력을 처리하지 못하는 문제, 로직과 시스템 설계의 취약점, 구현상의 버그, 공격에 악용될 수 있는 숨겨진 취약성, 출력으로 인한 의도치 않은 부작용 등이 여기에 해당합니다. 이러한 실패를 테스트할 때 결과를 적절히 예측할 수 있습니다. 에이전트는 실패가 발생할 수 있는 범위를 대폭 넓힙니다. 그 범위가 너무 커져 모델 평가, 단위 테스트, 통합 테스트, 애플리케이션 보안 테스트, 침투 테스트, 컴플라이언스 점검으로는 원칙적으로 다룰 수 없을 정도입니다. 새롭게 등장한 에이전트 위험 영역을 테스트하려면 에이전트의 행동을 위임자가 지정한 목적, 사용자 페르소나, 그리고 에이전트가 작동하는 조직·산업·지역의 정책에 비추어 평가하는 새로운 지표와 메커니즘이 필요합니다.

Amazon SageMaker와 Amazon Bedrock의 딥러닝 엔지니어링을 이끈 경험이 있으신데요. AWS에서 AI 인프라를 구축하며 얻은 교훈 가운데 Vijil에서 에이전트의 보안과 신뢰성을 다루는 방식에 가장 큰 영향을 준 것은 무엇인가요?

가장 큰 영향을 준 통찰은 서비스 개발 주기 초기에 신뢰성, 보안, 규정 준수 측면의 문제를 찾아내는 것이 출시 직전에 발견하는 전통적인 방식보다 훨씬 효과적이고 효율적이라는 점이었습니다. 더 나쁜 경우는 서비스가 운영에 들어간 뒤에야 문제를 발견해, 서비스 장애를 알리는 전화를 받고 잠에서 깨는 상황이었습니다.

Vijil은 배포 전에 에이전트를 테스트하는 데 그치지 않고, 운영 환경에서 에이전트를 보호하고 지속적으로 개선하는 데도 주력합니다. 에이전트가 실제 사용자, 데이터, 엔터프라이즈 시스템과 상호작용하기 시작한 뒤에야 드러나는 위험에는 어떤 것들이 있나요?

현실 세계에는 우리를 놀라게 할 가능성이 무한합니다. 놀란 에이전트는 실수를 저지르기 쉽습니다. 밈을 만드는 과정에서 실수하는 에이전트는 누구에게도 큰 문제가 되지 않습니다. 하지만 재무 자문가, 법률 보조원, 변호사, 간호사, 의사, 환자 또는 수탁자 의무를 이행한다는 증거를 제시해야 하는 업계의 전문가를 돕거나 대체하도록 설계된 에이전트라면, 허용 범위를 엄격하게 설정하고 세심하게 모니터링하며 에이전트의 행동을 신속히 복구하지 않는 한 제대로 기능할 수 없습니다.

기업들이 단순히 응답을 생성하는 데 그치지 않고 실제 행동을 수행할 수 있는 자율형 에이전트를 점점 더 많이 도입하고 있습니다. 이에 따라 보안 모델은 어떻게 발전해야 할까요? 권한, 신원, 접근 제어와 같은 기존 개념만으로 충분할까요?

아닙니다. 에이전트가 조직의 행위자가 되면, 검증 가능한 고유한 신원을 부여해야 합니다. 또한 접근 권한이 있는 리소스를 사용하는 도구와 같은 기능 구성 요소뿐 아니라 에이전트의 행동까지 구속하는 역할을 지정하고, 이를 의무적 접근 제어 정책과 결합해야 합니다. 의도된 목적에서 벗어나는지 지속적으로 모니터링하고, 공격을 받아도 복원력을 유지하도록 유도해야 합니다.

Vijil은 600만 달러 규모의 시드 투자 라운드에서 1,700만 달러 규모의 시리즈 A 투자 라운드로 나아갔고, 약 20명으로 구성된 초기 팀을 꾸리는 한편 연간 반복 매출 100만 달러를 처음 달성했습니다. 초기 기술 개념을 상업적 도입으로 이어지게 한 가장 중요한 결정은 무엇이었나요?

초기에 고객이 선택한 플랫폼과 통합되는 신뢰 계층을 구축하기로 했습니다. 동시에 기업들이 오픈 모델을 활용하는 멀티 에이전트 시스템에서 더 높은 수준의 맞춤화와 세분화된 제어, 더 낮은 비용을 점점 더 원하게 될 것으로 내다봤습니다. 특정 제품 하나가 아니라 플랫폼 계층을 구축하는 장기 전략은 우리에게 비교 우위를 제공하지만, 대규모 에이전트 거버넌스를 도입할 준비가 된 기업을 찾는 일이 기존 서비스를 그대로 이전해 판매하는 것만큼 쉽지 않다는 어려움도 따릅니다.

1995년에 신뢰성이 검증된 UNIX 시스템을 위한 자동화 레드팀 테스트를 개발하며 경력을 시작하셨습니다. 거의 30년이 지난 지금, 추론하고 적응하며 외부 도구를 사용할 수 있는 AI 에이전트를 테스트할 때 레드팀의 원칙은 어떻게 달라졌나요?

역사적으로 레드팀 활동은 조직의 방어 체계를 조직적인 공격에 맞서 시험하는 것을 뜻했습니다. 기본 원칙은 여전히 유효합니다. 테스트 대상 조직의 약점을 파악하려면 통제된 조건에서 공격을 조직적으로 수행해야 합니다. 그러나 소프트웨어 시스템을 테스트하기 위해 레드팀 훈련을 미리 각본에 따라 진행하던 과거의 방식은 더 이상 충분하지 않습니다. AI 에이전트는 결정론적 소프트웨어와 다릅니다. 환경에 적응하도록 설계되어 있어 같은 공격을 예측 가능한 방식으로 반복할 수 없기 때문입니다. 저는 에이전트를 기업처럼 다뤄야 한다고 주장합니다. 따라서 에이전트에 대한 레드팀 테스트는 에이전트의 목적에 맞춰 조정하고, 사용자의 의도에서 벗어나는지 살피며, 에이전트가 환경의 정책을 회피하려는지와 회피할 능력이 있는지를 조사해야 합니다.

앞으로 AI 에이전트의 독립적인 테스트와 측정 가능한 신뢰 기준이 기업 도입의 필수 조건이 될 것으로 보시나요? 그런 수준의 보증이 업계의 표준 관행으로 자리 잡으려면 업계 전반에서 무엇이 이루어져야 할까요?

현재 에이전트 개발자는 에이전트의 역량을 평가하고, 레드팀은 프롬프트 인젝션과 탈옥에 대한 저항성을 테스트하며, GRC 팀은 이제 막 규정 준수 여부를 시험하기 시작했습니다. 하지만 모델, 도구, 리소스, 워크플로, 대상 환경이 바뀌는 동안 에이전트의 전체 수명 주기에 걸쳐 백그라운드에서 지속적으로 작동하는 행동 검증 체계를 구축한 조직은 극히 드뭅니다. 더 중요한 점은 Vijil이 실제 운영 환경에서 에이전트의 행동을 사양과 연결해 추적하고, 피드백 루프를 통해 에이전트를 지속적으로 개선하도록 지원함으로써 기업에 차별화된 도움을 제공한다는 것입니다. 공격을 견뎌내는 에이전트는 복원력을 유지하도록 적응하는 에이전트입니다.

훌륭한 인터뷰에 감사드립니다. 엔터프라이즈 AI 에이전트를 테스트하고 보호하며 지속적으로 개선하는 방법을 더 알고 싶은 독자라면 Vijil을 방문해 보시기 바랍니다.