Shahar Azulay, groundcover의 CEO이자 공동 창업자

Shahar Azulay, groundcover의 CEO이자 공동 창업자는 연속적인 R&D 리더입니다. Shahar는 Apple, DayTwo, Cymotive Technologies와 같은 회사에서 리더로 근무하며 사이버 보안 및 머신 러닝 분야의 경험을 가지고 있습니다. Shahar는 이스라엘 총리실 사이버 부서에서 오랜 시간 근무했으며, Technion 이스라엘 공과대학과 텔아비브 대학교에서 물리학, 전기 공학 및 컴퓨터 과학 분야의 세 가지 학위를 보유하고 있습니다. Shahar는 이 풍부한 배경에서 얻은 기술적 학습을 활용하여 오늘날의 클라우드 네이티브 환경에 가장 날카롭고 혁신적인 형태로 가져와 개발자 세계를 더 나은 곳으로 만들고자 노력합니다.

groundcover는 엔지니어링 팀이 전통적인 모니터링 도구의 복잡성이나 비용 없이 시스템에 대한 완전한 실시간 가시성을 확보할 수 있도록 설계된 클라우드 네이티브 가시성 플랫폼입니다. eBPF 기술을 기반으로 구축된 이 플랫폼은 코드 변경 없이 클라우드 네이티브 및 Kubernetes 환경 전반에 걸쳐 로그, 메트릭, 트레이스 및 이벤트를 수집하고 상관 관계를 파악하여 더 빠른 근본 원인 분석과 명확한 시스템 인사이트를 제공합니다. 이 플랫폼은 예측 가능한 가격 책정, 데이터를 고객의 클라우드에 유지하는 유연한 배포, 그리고 인프라, 애플리케이션 및 현대적인 AI 기반 워크로드를 아우르는 엔드투엔드 가시성을 강조합니다.

이스라엘 총리실에서 사이버 R&D 팀을 이끌었던 시절부터 Apple에서 ML 이니셔티브를 관리하기까지의 여정을 돌아보면, 어떤 경험들이 결국 groundcover 창업으로 이끌었으며, 현대 AI 시스템을 위한 가시성의 격차를 언제 처음 인식하게 되었나요?

groundcover를 창업하게 된 계기는 Apple과 DayTwo에서의 시간에서 비롯되었습니다. 막대한 예산이 있었음에도 불구하고, 우리는 모든 것을 기록하기 위해 엄청난 비용을 지불하거나 샘플링을 통해 맹목적으로 진행하는 사이에서 갈팡질팡해야 했습니다. 당시 우리는 그 문제를 해결할 기술을 찾고 있었습니다. Extended Berkeley Packet Filter(eBPF)를 접한 후, 그것이 모든 것을 바꿀 것임이 분명해졌습니다. eBPF는 애플리케이션 변경에 의존하지 않고 커널에서 발생하는 모든 것을 볼 수 있게 해줍니다. 왜 가시성 도구들이 이를 활용하지 않는지 이해할 수 없었습니다. AI 격차는 나중에 분명해졌습니다. 우리의 Kubernetes 플랫폼이 성숙해지자, 고객들이 GenAI 배포에 뛰어들면서 LLM을 블랙박스처럼 취급하는 것을 보았습니다. 그들은 모델이 응답한다는 것은 알았지만, 왜 예측 불가능하게 행동하거나 비용이 급증하는지는 알지 못했습니다. 우리는 에이전트 기반 워크플로우가 단순히 복잡하고 비결정적인 마이크로서비스이며, 우리가 이미 구축한 제로 터치 가시성이 동일하게 필요하다는 것을 깨달았습니다.

사이버 보안, 임베디드 시스템, 머신 러닝 R&D에 대한 배경이 groundcover의 비전에 어떤 영향을 미쳤으며, LLM 기반 및 에이전트 애플리케이션을 위한 가시성을 중심으로 회사를 구축하는 데 어떤 초기 도전 과제에 직면했나요?

제 사이버 보안 배경은 회사의 DNA를 형성했습니다. 정보 세계에서는 애플리케이션을 통제하지 못한다고 가정합니다. 그 접근 방식이 groundcover가 계측을 요구하지 않는 이유입니다. 개발자에게 코드 수정을 요청하는 것이 채택을 막는 가장 빠른 길이라는 것을 경험을 통해 알고 있습니다. LLM 모니터링에서 가장 어려웠던 초기 도전 과제는 개인정보 보호였습니다. AI를 위한 가시성은 민감한 PII나 IP를 포함할 수 있는 프롬프트를 캡처합니다. 제 배경은 기업들이 그 데이터가 자신들의 환경을 떠나기를 원하지 않을 것임을 명백하게 했습니다. 그래서 우리는 인-클라우드 아키텍처를 구축하여 모든 데이터를 고객 자신의 환경 내에 유지하면서 에이전트 행동에 대한 깊은 가시성을 제공할 수 있게 했습니다.

LLM 가시성을 어떻게 정의하시며, 기존 모니터링이나 ML 모니터링과 무엇이 다른가요?

LLM 가시성은 대규모 언어 모델을 사용하는 프로덕션 시스템을 계측하고 모니터링하여 모든 추론의 전체 컨텍스트를 캡처하는 실천입니다: 프롬프트, 컨텍스트, 완성, 토큰 사용량, 지연 시간, 오류, 모델 메타데이터, 그리고 이상적으로는 다운스트림 피드백이나 품질 신호까지 포함합니다. “서비스가 가동 중이고 빠른가?” 또는 “이 요청이 오류가 발생했는가?”와 같은 질문만 하는 대신, LLM 가시성은 “왜 이 특정 요청이 성공하거나 실패했는가?”, “이 다단계 워크플로우 내에서 실제로 무슨 일이 일어났는가?”, “프롬프트, 컨텍스트 또는 모델 버전의 변경이 비용, 지연 시간 및 출력 품질에 어떤 영향을 미치는가?”와 같은 질문에 답하는 데 도움을 줍니다. 이는 전통적인 모니터링이나 심지어 고전적인 ML 모니터링과 매우 다릅니다. 레거시 접근 방식은 결정론적 시스템, 인프라 메트릭 및 정적 임계값에 맞춰져 있습니다. LLM 애플리케이션은 비결정론적이고 개방적이며 컨텍스트에 크게 의존합니다. 성공은 종종 의미론적이고 주관적이며, 단순히 200 대 500 상태 코드가 아닙니다. 이는 입력과 출력을 추적하고, 도구 호출 및 검색 단계를 이해하며, 환각이나 정책 위반과 같은 것들에 대한 응답을 평가하고, 토큰 수준의 비용과 지연을 주변 애플리케이션 및 인프라와 연결해야 함을 의미합니다.

LLM 기반 애플리케이션이 도입하는 도전 과제들로 인해 전통적인 가시성 도구들이 왜 불충분해지나요?

LLM 기반 시스템은 전통적인 도구들의 한계를 드러내는 여러 도전 과제를 도입합니다:

• 복잡한 다단계 워크플로우 – 우리는 단순한 “모델 호출, 응답 수신” 흐름에서 다중 턴 에이전트, 다단계 파이프라인, 검색 증강 생성 및 도구 사용으로 이동했습니다. 검색, 강화, 임베딩, 도구 호출 또는 모델 호출과 같은 단계 중 어느 하나에서 침묵하는 실패는 전체 경험을 무너뜨릴 수 있습니다. 전통적인 모니터링은 일반적으로 프롬프트와 응답이 포함된 이러한 체인에 대한 완전한 트레이스 수준의 뷰를 제공하지 않습니다.
• 급속히 진화하는 AI 스택 – 팀들은 이전에 본 적 없는 속도로 새로운 모델, 도구 및 벤더를 추가하고 있습니다. 많은 회사에서 어느 모델이 특정 시점에 프로덕션에 배포되어 있는지 자신 있게 나열할 수 있는 사람이 없습니다. 고전적인 가시성은 일반적으로 SDK를 계측하고, 재배포하고, 측정할 항목을 신중하게 선별할 시간이 있다고 가정합니다. 이는 AI가 채택되는 속도를 따라잡지 못합니다.
• 토큰 기반 경제성 및 할당량 – 가격 책정과 속도 제한은 토큰 및 컨텍스트 길이와 연결되어 있으며, 이는 종종 중앙 운영팀이 아닌 개발자, 프롬프트 또는 사용자 행동에 의해 제어됩니다. 전통적인 도구들은 “누가 어떤 워크플로우를 위해 어떤 모델에서 얼마나 많은 토큰을 소모했는지, 어떤 지연 시간으로” 보여주도록 구축되지 않았습니다.
• 이진적 성공 대신 의미적 정확성 – LLM은 200을 반환하면서도 환각을 일으키거나, 프롬프트에서 벗어나거나, 정책을 위반할 수 있습니다. 전통적인 도구들은 이를 성공으로 봅니다. 프롬프트와 응답을 표면화하고 행동을 검사할 수 있는 충분한 컨텍스트를 제공하며, 시간이 지남에 따라 자동화된 품질 검사를 연결할 수 있는 가시성이 필요합니다.
• 제3자로 유입되는 민감한 입력 데이터 – LLM은 사용자가 채팅 스타일 인터페이스를 통해 매우 민감한 정보를 공유하도록 유도합니다. 이제 여러분은 그 데이터, 그 데이터가 저장된 위치, 그리고 어떤 벤더가 그 데이터를 보는지에 대한 책임이 있습니다. 모든 원격 측정 데이터를 제3자에게 전송하는 기존의 SaaS 기반 가시성은 이러한 워크로드에 대해 종종 받아들일 수 없습니다.

이 모든 것은 LLM 시스템이 AI를 인식하고, 컨텍스트가 풍부하며, 오늘날 대부분의 팀이 사용하는 도구들보다 수동 계측에 훨씬 덜 의존하는 가시성을 필요로 함을 의미합니다.

지연 시간, 토큰 사용량 및 프롬프트/응답 행동을 포함하여 LLM 시스템의 성능과 품질을 이해하는 데 가장 중요한 신호 또는 메트릭은 무엇인가요?

실제로 중요한 신호들은 몇 가지 범주로 나뉩니다:

지연 시간 및 처리량

• 요청당 엔드투엔드 지연 시간(모델 시간 및 주변 애플리케이션 시간 포함).
• 모델 및 워크플로우별 꼬리 지연 시간(P90, P95, P99).
• 모델, 경로 및 서비스별 처리량으로, 부하가 실제로 어디로 가는지 알 수 있습니다.

토큰 사용량 및 비용 동인

• 요청당 입력 및 출력 토큰 수(모델별 분류).
• 시간 경과에 따른 모델, 팀, 사용자 및 워크플로우별 집계 토큰 사용량.
• 검색 중심 파이프라인의 컨텍스트 크기로, 프롬프트가 폭발적으로 증가하는 시점을 확인할 수 있습니다.
• 이를 통해 “누가 실제로 우리의 AI 예산을 무엇에 지출하고 있는가?”에 답할 수 있습니다.

프롬프트 및 응답 행동

• 대표적인 트레이스 상의 실제 프롬프트 및 응답 페이로드(도구 호출 및 추론 경로 포함).
• LLM이 어떤 도구를 호출하기로 선택했는지 및 어떤 순서로 호출했는지.
• 유사한 프롬프트에 대한 응답의 변동성으로, 행동이 얼마나 안정적인지 알 수 있습니다.

신뢰성 및 오류

• 모델별 오류율 및 유형(공급자 오류, 시간 초과, 인증 문제, 할당량 오류).
• 도구 시간 초과 또는 검색 오류와 같은 주변 워크플로우의 실패를 LLM 호출과 상관 관계 있게 파악.

고전적인 인프라 컨텍스트

• LLM 호출을 조정하는 서비스들의 컨테이너 CPU, 메모리 및 네트워크 메트릭.
• 애플리케이션이 무엇을 하려고 했는지 설명하는 상관 관계 있는 로그.

이 모든 것을 한 곳에서 볼 수 있을 때, LLM 가시성은 “뭔가 느리거나 비싸다는 것을 안다”에서 “정확히 어떤 모델, 프롬프트 패턴 및 서비스가 책임이 있고 그 이유는 무엇인지 안다”로 이동합니다.

가시성은 프롬프트 드리프트, 환각 또는 출력 품질의 점진적 저하와 같은 침묵하는 실패를 팀이 감지하는 데 어떻게 도움이 될 수 있나요?

LLM 시스템에서 침묵하는 실패는 일반적으로 인프라 수준에서는 모든 것이 “녹색”으로 보이지만 실제 행동이 표류할 때 발생합니다. 가시성은 몇 가지 방식으로 도움이 됩니다:

• 모델 호출뿐만 아니라 전체 워크플로우 추적 – 클라이언트에서 서비스, 검색, 모델, 도구에 이르는 요청의 전체 경로를 캡처함으로써 행동이 변경된 위치를 확인할 수 있습니다. 예를 들어, 검색이 더 적은 문서를 반환하기 시작했거나, 도구 호출이 간헐적으로 실패하여 모델이 즉흥적으로 대응하고 있을 수 있습니다.
• 프롬프트, 컨텍스트 및 응답을 시야에 유지 – 트레이스와 함께 프롬프트와 응답을 검사할 수 있게 되면, 지연 시간과 오류율은 동일하게 유지되었더라도 새로운 프롬프트 버전, 새로운 시스템 지시 또는 새로운 컨텍스트 소스가 행동을 변경한 사례를 훨씬 쉽게 발견할 수 있습니다.
• 의미적 조건에 따른 필터링 및 분할 – 풍부한 LLM 원격 측정 데이터가 있으면, “1초 이상 걸린 bedrock 호출”, “이 모델 패밀리를 사용하는 요청” 또는 “이 특정 경로와 관련된 트레이스”와 같은 항목으로 필터링한 다음 프롬프트와 응답을 읽어 모델이 특정 시나리오에서 표류하거나 환각을 일으키는지 확인할 수 있습니다.
• 비즈니스 수준 SLO에 대한 경고 – “1초 이상 걸리는 모든 LLM 호출은 사용자 대면 SLA를 위반한다”와 같은 SLO를 정의하고 해당 조건이 충족될 때 경고를 트리거할 수 있습니다. 시간이 지남에 따라 유사한 SLO가 품질 점수나 정책 검사와 연결되어 인프라가 실패할 때뿐만 아니라 품질이 저하될 때도 경고를 받을 수 있습니다.

가시성 계층이 AI 특화 신호와 고전적인 로그, 메트릭, 트레이스 모두에 접근할 수 있기 때문에, 그렇지 않으면 사용자 경험을 조용히 저하시킬 문제들을 포착하는 자연스러운 장소가 됩니다.

groundcover의 접근 방식은 다단계 에이전트 워크플로우 및 도구 호출 내에서 예측 불가능한 지연 시간이나 예상치 못한 행동을 진단하는 데 어떻게 지원하나요?

groundcover는 현대 AI 시스템을 위해 설계된 접근 방식을 취합니다. 우리는 커널 수준에서 eBPF 기반 센서를 사용하여 코드 변경이나 재배포 없이 마이크로서비스 간 트래픽을 관찰합니다. LLM 워크플로우를 도입하는 즉시, 우리는 해당 호출을 자동으로 발견할 수 있습니다. 내일 Anthropic, OpenAI 또는 Bedrock과 같은 새로운 모델을 사용하기 시작하면 groundcover는 해당 트래픽을 자동으로 캡처합니다. 이는 다음과 같은 것을 제공합니다:

• 다중 홉 워크플로우의 엔드투엔드 트레이스 – 서비스 전반에 걸친 요청의 전체 경로를 볼 수 있으며, LLM이나 도구가 사용된 위치를 포함합니다.
• 각 LLM 호출에 대한 깊은 컨텍스트 – 모든 호출에는 사용된 모델, 지연 시간, 토큰 사용량, 프롬프트, 응답 및 상관 관계 있는 로그와 인프라 메트릭이 포함됩니다.
• 지연 시간 및 조건에 따른 강력한 필터링 – 예를 들어, 1초 이상 걸린 모든 Claude 3.5 호출을 필터링하고 SLA를 위반한 트레이스를 즉시 검사할 수 있습니다.
• LLM 행동과 연결된 경고 및 대시보드 – 데이터가 사용 가능해지면 SLA 위반에 대한 경고를 생성하거나 지연 시간, 처리량, 토큰 사용량 및 오류를 추적하는 대시보드를 구축할 수 있습니다.

모든 것이 eBPF에 의해 에지에서 수집되고 고객 자신의 클라우드에 저장되기 때문에, 모든 에이전트나 도구 호출 내부에 계측을 추가하지 않고도 이 고해상도 뷰를 얻을 수 있습니다.

LLM 배포에서 발생하는 데이터 보안 및 규정 준수 위험은 무엇이며, 가시성이 이러한 위험을 줄이는 데 어떻게 도움이 될 수 있나요?

LLM 배포는 몇 가지 고유한 데이터 위험을 가져옵니다:

• 무제한 사용자 입력 – 사용자는 채팅봇 및 AI 기반 인터페이스에 극도로 민감한 정보를 입력할 수 있습니다. 여기에는 개인 데이터, 고객 데이터 또는 수집할 의도가 없었던 규제 정보가 포함될 수 있습니다.
• 제3자 모델 공급자 – 해당 데이터를 외부 LLM 공급자에게 보내면, 그 데이터가 어디로 갔는지, 어떻게 저장되는지, 어떤 하청 처리자가 관련되어 있는지에 대한 책임이 있습니다. 이는 GDPR, 데이터 거주지 및 고객 신뢰에 중대한 영향을 미칩니다.
• 민감한 데이터의 두 번째 복사본으로서의 원격 측정 – 가시성 스택이 전체 페이로드를 SaaS 벤더에게 전송하면, 이제 민감한 정보의 또 다른 복사본이 여러분의 환경 외부에 존재하게 됩니다.

groundcover의 아키텍처는 정확히 이러한 우려를 해결하도록 설계되었습니다:

• 우리는 Bring Your Own Cloud 모델을 사용하여 전체 가시성 백엔드가 완전 관리형 데이터 플레인으로서 하위 계정 내 여러분의 클라우드 계정에서 실행됩니다. 이를 확장하고 관리하는 컨트롤 플레인은 우리가 운영하지만, 우리는 여러분의 원격 측정 데이터에 접근하거나 저장하거나 처리하지 않습니다.
• 우리는 여러분의 환경 내에서 안전하게 페이로드를 캡처할 수 있기 때문에, 데이터가 여러분의 클라우드를 떠나지 않고도 프롬프트, 응답 및 워크플로우를 관찰할 수 있습니다. 여러분의 LLM 트레이스에 대한 제3자 저장소가 없으며, 추가적인 데이터 유출에 대해 걱정할 필요가 없습니다.
• 이러한 가시성을 통해 누가 무엇을 업로드하는지, 어디로 흐르는지 확인하고, 민감한 데이터의 예상치 못한 사용을 감지하며, 허용되는 모델 및 지역에 대한 정책을 시행할 수 있습니다.

즉, 가시성은 신뢰성 및 비용 도구일 뿐만 아니라 개인정보 보호, 데이터 거주지 및 규정 준수를 위한 핵심 통제 지점이 됩니다.

조직이 하나의 LLM 통합에서 많은 AI 기반 서비스로 확장함에 따라 가시성, 신뢰성 및 비용과 관련하여 어떤 운영상의 도전 과제들이 나타나는 경향이 있나요?

첫 번째 통합은 일반적으로 단일 워크플로우의 단일 모델입니다. 그 단계에서는 관리 가능하게 느껴집니다. 팀들이 가치를 보자마자 사용량이 폭발하고 몇 가지 도전 과제가 나타납니다:

• 모델 및 벤더 확산 – 팀들은 끊임없이 새로운 모델을 테스트합니다. 어떤 모델이 프로덕션에 있고 어떻게 사용되는지 빠르게 불분명해집니다.
• 토큰 사용량으로 인한 비용 급증 – 토큰 소비는 컨텍스트 길이와 워크플로우 복잡성에 따라 증가합니다. 모델 및 워크플로우별 토큰 사용량에 대한 가시성 없이는 비용 관리가 매우 어렵습니다.
• 외부 공급자에 대한 신뢰성 의존성 – 사용자 대면 API는 모델 지연 시간이나 오류에 민감해져 핵심 인프라가 정상일 때도 SLA를 방해할 수 있습니다.
• 증가하는 계측 부채 – 전통적인 가시성은 필요할 때 계측을 추가할 수 있다고 가정합니다. 빠르게 변화하는 AI 스택에서는 개발자들이 이를 위한 시간을 거의 갖지 못합니다.

groundcover는 AI 트래픽을 자동으로 발견한 다음 다음과 같은 것을 제공하여 이러한 문제를 해결합니다:

• 어떤 모델과 벤더가 사용되는지에 대한 중앙 집중식 가시성.
• 시간 경과에 따른 지연 시간, 처리량 및 토큰 사용량을 보여주는 대시보드.
• LLM 행동과 이에 의존하는 서비스 간의 상관 관계.
• AI 기반 SLO 위반에 대한 경고.

이를 통해 “하나의 멋진 AI 기능”에서 “AI가 수십 개의 중요한 서비스에 짜여져 있는” 상태로 통제력을 잃지 않고 확장하는 것이 훨씬 쉬워집니다.

앞으로 5년 동안 에이전트 AI, 다중 모델 오케스트레이션 및 규제 압력이 가속화됨에 따라 LLM 가시성이 어떻게 진화할 것으로 예상하시나요?

우리는 아직 초기 단계에 있습니다. 향후 5년 동안 몇 가지 큰 변화가 있을 것으로 예상합니다:

• 요청 수준에서 에이전트 수준 이해로 이동 – 가시성은 모델 호출뿐만 아니라 도구 시퀀스, 추론 경로 및 재시도 논리를 캡처하도록 확장될 것입니다.
• 더 풍부한 의미적 및 정책 신호 – 환각, 안전 문제 및 브랜드 정렬에 대한 자동화된 품질 검사가 표준 메트릭이 될 것입니다.
• 거버넌스 및 개인정보 보호와의 긴밀한 결합 – 규제가 강화됨에 따라 가시성은 데이터 거주지, 보존 및 승인된 모델 사용을 위한 시행 및 감사 계층 역할도 할 것입니다.
• 교차 모델, 다중 벤더 최적화 – 팀들은 실시간 가시성 데이터에 기반하여 성능과 비용에 따라 트래픽을 모델 간에 동적으로 라우팅할 것입니다.
• 더 적은 수동 계측 – eBPF 기반 수집 및 자동 발견과 같은 기술이 기본이 되어 팀들이 속도를 늦추지 않고 혁신할 수 있게 될 것입니다.

요약하면, LLM 가시성은 “AI를 위한 좋은 대시보드”에서 조직이 AI로 수행하는 모든 것에 걸쳐 신뢰성, 비용 통제, 데이터 거버넌스 및 제품 품질을 연결하는 중추 신경계로 진화할 것입니다.

훌륭한 인터뷰에 감사드립니다. 더 알아보고 싶은 독자분들은 groundcover를 방문하시기 바랍니다.