Groundcover의 CEO 겸 공동 창립자인 샤하르 아주레이

샤하르 아줄레이, Groundcover의 CEO이자 공동 창립자인 샤하르는 연구 개발 분야에서 오랜 경력을 쌓아온 리더입니다. 그는 Apple, DayTwo, Cymotive Technologies와 같은 기업에서 리더로 활동하며 사이버 보안 및 머신 러닝 분야에서 풍부한 경험을 축적했습니다. 샤하르는 이스라엘 총리실 사이버 부서에서 오랜 기간 근무했으며, 테크니온 이스라엘 공과대학교와 텔아비브 대학교에서 물리학, 전기공학, 컴퓨터 과학 학위를 취득했습니다. 그는 이러한 풍부한 경험을 바탕으로 얻은 기술적 지식을 오늘날의 클라우드 네이티브 환경에 가장 혁신적이고 날카로운 방식으로 접목하여 개발 환경을 더욱 발전시키고자 노력하고 있습니다.

그라운드 커버 클라우드 네이티브 관찰 가능성 플랫폼인 이 솔루션은 엔지니어링 팀에게 기존 모니터링 도구의 복잡성과 비용 부담 없이 시스템에 대한 완벽한 실시간 가시성을 제공하도록 설계되었습니다. eBPF 기술을 기반으로 구축된 이 플랫폼은 코드 변경 없이 클라우드 네이티브 및 Kubernetes 환경 전반에서 로그, 메트릭, 트레이스 및 이벤트를 수집하고 상호 연관시켜 더 빠른 근본 원인 분석과 명확한 시스템 인사이트를 제공합니다. 이 플랫폼은 예측 가능한 가격 책정, 고객 클라우드에 데이터를 유지하는 유연한 배포, 그리고 인프라, 애플리케이션 및 최신 AI 기반 워크로드를 아우르는 엔드투엔드 관찰 가능성을 강조합니다.

이스라엘 총리실에서 사이버 R&D 팀을 이끌었던 경험부터 애플에서 머신러닝 프로젝트를 관리했던 경험까지, 당신의 여정을 되돌아보면 어떤 경험들이 궁극적으로 당신을 그라운드커버(Groundcover) 설립으로 이끌었으며, 현대 AI 시스템의 관찰 가능성 측면에서 부족한 부분을 언제 처음 인식하게 되었습니까?

기반을 마련하려는 동기는 제가 애플과 DayTwo에서 근무했던 경험에서 비롯되었습니다. 막대한 예산이 있었음에도 불구하고, 모든 것을 로깅하는 데 엄청난 비용을 지불하거나 샘플링을 통해 데이터를 수집하는 것 사이에서 선택의 기로에 서 있었습니다. 당시 우리는 이러한 문제를 해결해 줄 기술을 찾고 있었습니다. 그러던 중 eBPF(Extended Berkeley Packet Filter)를 접하게 되었고, 이것이 모든 것을 바꿀 것이라는 확신을 갖게 되었습니다. eBPF는 애플리케이션 변경에 의존하지 않고 커널에서 일어나는 모든 일을 확인할 수 있게 해 줍니다. 저는 왜 관찰 도구들이 이 기능을 활용하지 않는지 이해할 수 없었습니다. AI 분야의 이러한 격차는 나중에 더욱 명확해졌습니다. 저희의 Kubernetes 플랫폼이 성숙해지면서, 고객들이 LLM(Learning Leadership Model)을 블랙박스처럼 취급하면서 GenAI 배포에 몰려드는 것을 목격했습니다. 모델이 반응하는 것은 알았지만, 왜 예측할 수 없는 동작을 하는지, 왜 비용이 급증하는지는 알지 못했습니다. 우리는 에이전트 기반 워크플로가 복잡하고 비결정적인 마이크로서비스이며, 우리가 이미 구축해 놓은 것과 같은 제로 터치 가시성이 필요하다는 것을 깨달았습니다.

사이버 보안, 임베디드 시스템 및 머신러닝 연구 개발 분야에서의 경험이 Groundcover의 비전에 어떤 영향을 미쳤으며, LLM 기반 및 에이전트형 애플리케이션을 위한 관찰 가능성에 중점을 둔 회사를 설립하는 과정에서 초기에 어떤 어려움을 겪었습니까?

제 사이버 보안 배경은 회사 DNA를 형성하는 데 큰 영향을 미쳤습니다. 정보 분야에서는 애플리케이션을 완전히 제어할 수 없다는 전제가 깔려 있습니다. 이러한 접근 방식 덕분에 Groundcover는 계측이 필요하지 않습니다. 개발자에게 코드 수정을 요청하는 것은 도입을 막는 가장 빠른 방법이라는 것을 경험을 통해 알고 있습니다. LLM 모니터링의 초기 가장 큰 과제는 개인정보 보호였습니다. AI 관찰 가능성은 민감한 개인 식별 정보(PII)나 지적 재산권(IP)이 포함될 수 있는 프롬프트를 캡처합니다. 제 배경을 통해 기업들이 이러한 데이터가 자사 환경 외부로 유출되는 것을 원하지 않을 것이라는 점을 명확히 알 수 있었습니다. 그래서 우리는 클라우드 기반 아키텍처를 구축하여 모든 데이터를 고객 환경 내에 유지하면서 에이전트 동작에 대한 심층적인 가시성을 제공할 수 있도록 했습니다.

LLM 관찰 가능성을 어떻게 정의하시나요? 그리고 기존 모니터링이나 머신러닝 모니터링과 어떤 차이점이 있나요?

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

LLM 기반 애플리케이션은 어떤 문제점을 야기하여 기존 관측 도구로는 충분하지 않은가?

LLM 기반 시스템은 기존 도구의 한계를 드러내는 몇 가지 과제를 제시합니다.

• 복잡하고 여러 단계로 구성된 워크플로 우리는 단순한 "모델 호출, 응답 수신" 흐름에서 다중 턴 에이전트, 다단계 파이프라인, 증강 생성 기능을 갖춘 검색 및 도구 사용으로 전환했습니다. 검색, 보강, 임베딩, 도구 호출 또는 모델 호출과 같은 이러한 단계 중 어느 하나라도 조용히 오류가 발생하면 전체 경험이 중단될 수 있습니다. 기존 모니터링 방식은 일반적으로 프롬프트와 응답을 포함한 이러한 체인의 전체 추적 수준 보기를 제공하지 않습니다.
• 빠르게 진화하는 AI 스택 팀들은 전례 없는 속도로 새로운 모델, 도구, 공급업체를 추가하고 있습니다. 많은 회사에서 특정 시점에 어떤 모델이 실제로 운영 중인지 정확히 파악하기 어렵습니다. 기존의 관찰 가능성 확보 방식은 SDK를 계측하고, 재배포하고, 측정 대상을 신중하게 선별하는 데 필요한 시간을 전제로 합니다. 하지만 이러한 방식으로는 AI 도입 속도를 따라잡을 수 없습니다.
• 토큰 기반 경제와 할당량 가격 및 사용량 제한은 토큰과 컨텍스트 길이에 따라 결정되는데, 이는 중앙 운영팀이 아닌 개발자, 프롬프트 또는 사용자 행동에 의해 제어되는 경우가 많습니다. 기존 도구는 "어떤 모델에서 어떤 워크플로를 어떤 지연 시간으로 누가 얼마나 많은 토큰을 사용했는지"를 보여주도록 설계되지 않았습니다.
• 이분법적 성공 대신 의미론적 정확성 LLM은 200 응답을 반환하더라도 오류를 범하거나, 프롬프트에서 벗어나거나, 정책을 위반할 수 있습니다. 기존 도구들은 이를 성공으로 간주합니다. 프롬프트와 응답을 파악하고 동작을 분석하는 데 필요한 충분한 맥락을 제공하는 관찰 가능성이 필요하며, 시간이 지남에 따라 자동화된 품질 검사를 추가할 수 있어야 합니다.
• 민감한 입력 데이터가 제3자에게 유출됨 LLM(Long-Term Management)은 사용자가 채팅 스타일 인터페이스를 통해 매우 민감한 정보를 공유하도록 유도합니다. 이제 사용자는 해당 데이터의 저장 위치와 접근 권한을 관리해야 합니다. 모든 원격 측정 데이터를 제3자에게 전송하는 기존 SaaS 기반 관찰 기능은 이러한 워크로드에 적합하지 않은 경우가 많습니다.

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

지연 시간, 토큰 사용량, 응답/프롬프트 동작 등 LLM 시스템의 성능과 품질을 이해하는 데 가장 중요한 신호 또는 지표는 무엇입니까?

실제 상황에서 매우 중요한 신호에는 몇 가지 범주가 있습니다.

지연 시간과 처리량

• 모델 시간 및 주변 애플리케이션 시간을 포함한 요청별 종단 간 지연 시간.
• 모델별 및 워크플로우별 테일 지연 시간(P90, P95, P99).
• 모델, 경로 및 서비스별 처리량을 통해 실제 부하가 어디로 향하는지 파악할 수 있습니다.

토큰 사용량 및 비용 발생 요인

• 모델별 요청당 입력 및 출력 토큰 수.
• 모델, 팀, 사용자 및 워크플로별 시간 경과에 따른 토큰 사용량 집계.
• 검색량이 많은 파이프라인의 컨텍스트 크기를 확인하여 프롬프트가 폭증하는 시점을 파악할 수 있습니다.
• 이를 통해 "실제로 누가 AI 예산을 어디에 쓰고 있는가?"라는 질문에 답할 수 있습니다.

프롬프트 및 응답 행동

• 대표적인 추적 과정에서 실제로 나타나는 프롬프트 및 응답 페이로드에는 도구 호출 및 추론 경로가 포함됩니다.
• LLM이 어떤 도구를 어떤 순서로 호출했는지.
• 유사한 질문에 대한 응답의 변동성을 통해 행동의 안정성을 파악할 수 있습니다.

신뢰성과 오류

• 모델별 오류 발생률 및 유형(공급자 오류, 시간 초과, 인증 문제, 할당량 오류).
• 도구 시간 초과 또는 검색 오류와 같은 주변 워크플로의 오류가 LLM 호출과 상관관계가 있었습니다.

클래식 인프라 컨텍스트

• LLM 호출을 오케스트레이션하는 서비스의 컨테이너 CPU, 메모리 및 네트워크 메트릭입니다.
• 애플리케이션이 시도했던 작업을 설명하는 상관 관계가 있는 로그입니다.

이 모든 정보를 한 곳에서 확인할 수 있게 되면, LLM 관찰 가능성은 "무언가가 느리거나 비용이 많이 든다는 것을 알고 있다"에서 "어떤 모델, 프롬프트 패턴, 서비스가 그 원인인지 정확히 알고 있다"로 발전합니다.

관찰 가능성은 팀이 즉각적인 변화, 착시 현상 또는 출력 품질의 점진적 저하와 같은 숨겨진 오류를 감지하는 데 어떻게 도움이 될 수 있을까요?

LLM 시스템에서 발생하는 조용한 오류는 일반적으로 인프라 수준에서는 모든 것이 "정상"으로 보이지만 실제 동작은 불안정해질 때 발생합니다. 관찰 가능성은 다음과 같은 몇 가지 방식으로 도움이 됩니다.

• 모델 호출뿐 아니라 전체 워크플로우를 추적합니다. 클라이언트가 서비스를 거쳐 검색, 모델, 도구에 이르기까지 요청하는 전체 경로를 캡처하면 동작이 변경된 지점을 확인할 수 있습니다. 예를 들어, 검색에서 반환되는 문서 수가 줄었거나, 도구 호출이 간헐적으로 실패하여 모델이 임시방편으로 처리하는 경우를 생각해 볼 수 있습니다.
• 질문, 맥락 및 응답을 항상 염두에 두십시오. 프롬프트와 응답을 추적 정보와 함께 검사할 수 있으면 지연 시간과 오류율은 동일하게 유지되었더라도 새로운 프롬프트 버전, 새로운 시스템 명령 또는 새로운 컨텍스트 소스로 인해 동작이 변경된 경우를 훨씬 쉽게 찾아낼 수 있습니다.
• 의미 조건에 따른 필터링 및 슬라이싱 - 풍부한 LLM 원격 측정 데이터를 확보한 후에는 "1초 이상 소요되는 기본 호출", "이 모델 제품군을 사용하는 요청", 또는 "이 특정 경로와 관련된 추적"과 같은 기준으로 필터링하여 프롬프트와 응답을 분석하고 특정 시나리오에서 모델이 오작동하거나 잘못된 정보를 표시하는지 확인할 수 있습니다.
• 비즈니스 수준 SLO에 대한 알림 – "LLM 호출 시간이 1초를 초과하면 사용자에게 제공되는 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의 아키텍처는 바로 그러한 우려 사항들을 해결하도록 설계되었습니다.

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

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

조직이 하나의 LLM 통합에서 여러 AI 기반 서비스로 확장함에 따라 가시성, 신뢰성 및 비용 측면에서 어떤 운영상의 어려움이 발생하는 경향이 있습니까?

첫 번째 통합은 일반적으로 단일 워크플로 내의 단일 모델로 이루어집니다. 이 단계에서는 관리가 수월해 보입니다. 하지만 팀이 가치를 인식하는 순간 사용량이 폭발적으로 증가하고 여러 가지 문제점이 나타납니다.

• 모델 및 공급업체의 확산 팀들은 끊임없이 새로운 모델을 테스트합니다. 그러다 보니 어떤 모델이 실제로 사용되고 있는지, 어떻게 활용되고 있는지가 금방 불분명해집니다.
• 토큰 사용으로 인한 예상치 못한 비용 발생 - 토큰 소비량은 컨텍스트 길이와 워크플로 복잡성이 증가함에 따라 늘어납니다. 모델 및 워크플로별 토큰 사용량을 파악하지 못하면 비용 관리가 매우 어렵습니다.
• 외부 공급업체에 대한 신뢰성 의존성 - 사용자에게 제공되는 API는 모델 지연 시간이나 오류에 민감해지며, 이는 핵심 인프라가 정상적일지라도 서비스 수준 계약(SLA)을 저해할 수 있습니다.
• 계측 장비 부채 증가 – 기존의 관찰 가능성 확보 방식은 필요할 때 계측 도구를 추가할 수 있다고 가정합니다. 하지만 빠르게 변화하는 AI 스택 환경에서는 개발자들이 그럴 시간을 내기 어렵습니다.

Groundcover는 AI 트래픽을 자동으로 감지하여 다음과 같은 기능을 제공함으로써 이러한 문제를 해결합니다.

• 어떤 모델과 공급업체가 사용되는지 중앙에서 파악할 수 있습니다.
• 시간 경과에 따른 지연 시간, 처리량 및 토큰 사용량을 보여주는 대시보드.
• LLM 행동과 그에 의존하는 서비스 간의 상관관계
• AI 기반 SLO 위반에 대한 알림.

이를 통해 "하나의 멋진 AI 기능"에서 "AI가 수십 개의 핵심 서비스에 통합된" 단계로 확장하더라도 제어권을 잃지 않고 훨씬 쉽게 확장할 수 있습니다.

향후 5년간 에이전트형 AI, 멀티모델 오케스트레이션, 규제 압력이 가속화됨에 따라 LLM 관찰 가능성은 어떻게 발전할 것으로 예상하십니까?

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

• 요청 수준부터 상담원 수준까지의 이해 – 관찰 가능성은 모델 호출뿐만 아니라 도구 사용 순서, 추론 경로 및 재시도 로직까지 포착하도록 확장될 것입니다.
• 더욱 풍부한 의미론적 및 정책적 신호 – 환각 현상, 안전 문제 및 브랜드 일관성에 대한 자동화된 품질 검사가 표준 지표가 될 것입니다.
• 거버넌스 및 개인정보보호와의 더욱 긴밀한 연계 규제가 강화됨에 따라, 관찰 가능성은 데이터 상주, 보존 및 승인된 모델 사용에 대한 집행 및 감사 계층으로서의 역할도 수행할 것입니다.
• 크로스 모델, 멀티 벤더 최적화 팀은 실시간 관찰 가능 데이터에 따라 성능 및 비용을 기준으로 모델 간 트래픽을 동적으로 라우팅합니다.
• 수동 계측 감소 – eBPF 기반 데이터 수집 및 자동 검색과 같은 기술이 기본값으로 자리 잡게 되어 팀은 속도 저하 없이 혁신을 이룰 수 있습니다.

요컨대, LLM 관찰 가능성은 "AI를 위한 있으면 좋은 대시보드"에서 벗어나 조직이 AI를 활용하여 수행하는 모든 활동 전반에 걸쳐 신뢰성, 비용 관리, 데이터 거버넌스 및 제품 품질을 연결하는 핵심 시스템으로 발전할 것입니다.

훌륭한 인터뷰 감사합니다. 자세한 내용을 알고 싶은 독자는 방문하세요. 그라운드 커버.