제프 샴페인, 크리블의 필드 CTO – 인터뷰 시리즈

제프 샴페인은 Cribl의 필드 CTO로, 관측 가능성, 엔터프라이즈 데이터, 제품 전략, 기술 아키텍처 전반에 깊은 경험을 갖고 있다. Cribl에 합류하기 전 Databricks에서 제품 관리 디렉터를 지냈고, Splunk에서는 7년 넘게 필드 제품, 아키텍처, 글로벌 시스템 엔지니어링 부문의 고위 직책을 맡았다. BNY ConvergEx에서 시스템 아키텍처를 이끌고, Premier Technology Solutions에서 선임 엔지니어로 일했으며, Assist-2-Sell에서는 초기 엔지니어링 리더십을 담당했다. 이 경력을 바탕으로 기업이 대규모 운영 데이터를 수집하고 관리하며 분석해 행동으로 옮기는 방식을 폭넓게 이해한다.

Cribl은 IT, 보안, SRE, DevOps 팀이 단일 공급업체에 종속되지 않고 관측 가능성 및 보안 데이터를 수집·처리·라우팅·저장·분석하도록 돕는 엔터프라이즈 텔레메트리 기업이다. Cribl은 스스로를 “텔레메트리를 위한 AI 플랫폼”으로 소개한다. 제품에는 실시간 텔레메트리 수집, 축소, 보강, 라우팅을 위한 Cribl Stream, 공급업체 중립적인 엔드포인트 텔레메트리 수집을 위한 Cribl Edge, 데이터를 원래 위치에서 검색하는 Cribl Search, 저장을 위한 Cribl Lake가 있다. 텔레메트리 규모가 커지고 AI 기반 운영에 더 깨끗하고 접근하기 쉬운 데이터가 필요해지는 상황에서, 기업에 더 큰 통제력과 유연성, 효율성을 제공하는 것이 회사의 더 넓은 목표다.

Splunk와 Databricks, 현재 Cribl까지 여러 기술 주기에 걸쳐 엔터프라이즈 데이터, 관측 가능성, 인프라를 살펴볼 수 있는 드문 경험을 쌓았습니다. 그런 관점에서 에이전틱 AI가 만든 관측 가능성 과제는 무엇이 근본적으로 다릅니까?

애플리케이션 관측 가능성에서는 복잡하게 분기하는 실행 경로를 다루고, 마이크로서비스를 통과하는 요청을 추적하며, 분산 시스템의 로그를 연결해 왔습니다. 보안 운영에서는 복잡하더라도 대체로 예측 가능한 방식으로 작동하는 여러 시스템에서 위협을 탐지하기 위해 대용량의 이질적인 데이터 원천을 다뤘습니다.

에이전틱 AI는 두 문제를 새로 발명하는 것이 아니라 동시에 폭발적으로 키웁니다. 에이전트는 작성 시점에 미리 정해지지 않은 방식으로 의사결정을 연결하고, 외부 도구를 호출하고, 하위 에이전트를 동적으로 만듭니다. 실행 그래프는 단지 복잡한 것이 아니라 매번 완전히 달라질 수 있고, 실제로 무슨 일이 있었는지 재구성하는 데 필요한 텔레메트리 양은 단계가 늘 때마다 기하급수적으로 증가합니다.

에이전틱 시스템을 관측 가능하게 만드는 데 필요한 모든 텔레메트리는 계측하기 쉬우면서도 대규모 운영 비용을 감당할 수 있어야 합니다. 그렇지 않으면 기업은 늘 그래 왔듯 비용을 통제하기 위해 가시성을 줄일 것이고, 그것은 눈을 감아서는 안 되는 바로 그때 눈을 감는 선택입니다.

기업이 자율 에이전트를 워크플로에 포함할 때, AI 에이전트에게 요청한 일과 실제 하위 시스템에서 일어난 일 사이의 가장 큰 가시성 공백은 어디에 있습니까?

에이전트는 겉으로 성공해 보이는 워크플로를 완료하면서도, 조용히 잘못된 도구 호출을 하거나 매개변수를 환각하거나 원래 목표에서 벗어날 수 있습니다. 그 결과는 몇 시간 뒤 다른 시스템에서 드러나기도 합니다. 단절은 보통 해석에서 시작됩니다. 원래 지시의 약간의 모호함이 에이전트가 메모리에서 가져온 정보, 그 순간 사용할 수 있는 도구, 이전 단계가 형성한 맥락에 따라 서로 다르게 해소됩니다.

에이전트가 의존하는 하위 시스템도 계측해야 합니다. 에이전트가 완벽한 형식의 데이터베이스 호출을 하더라도, 업스트림의 ETL 작업이 조용히 실패해 기본 테이블이 갱신되지 않았다면 잘못된 답을 돌려줄 수 있습니다. 에이전트는 지시받은 일을 정확히 했지만, 신뢰한 데이터가 오래됐던 것입니다.

전통적인 관측 가능성 도구가 에이전틱 AI 시스템을 모니터링하는 데 부족한 경우가 많은 이유는 무엇입니까?

첫째, 기존 도구는 경직된 독점 스키마와 예측 가능한 데이터 형태를 중심으로 만들어졌습니다. 에이전틱 트레이스는 그런 기대에 맞지 않습니다. 양이 많고 구조가 매우 다양하며, 프롬프트 전문, 모델의 추론 사슬, 도구 호출 페이로드처럼 기존 도구가 상당한 변환 작업 없이 수집하도록 설계되지 않은 데이터 유형을 포함합니다. OpenTelemetry의 생성형 AI 의미 규약 같은 개방형 표준이 등장하고 있지만, 많은 레거시 플랫폼은 이를 활용하도록 만들어지지 않았습니다.

둘째, 규모와 비용의 계산이 빠르게 무너집니다. 프로덕션 워크로드를 처리하는 단일 에이전트가 한 시간에 생성하는 텔레메트리가 전체 애플리케이션 스택이 하루에 만든 양보다 많을 수 있습니다. 전통적인 플랫폼 대부분은 수집·저장한 양에 따라 요금을 부과합니다. 모든 것을 계측해 감당할 수 없는 비용을 내거나, 가시성이 가장 필요한 시스템에서 관측 범위를 줄이는 선택을 강요받습니다.

AI 에이전트가 실패했을 때, 조직은 근본 원인이 모델, 검색 계층, API 종속성, 권한 문제, 하위 인프라 중 무엇인지 어떻게 판별할 수 있습니까?

에이전틱 실패의 근본 원인을 분리하는 일은 여러 계층을 하나씩 배제하는 과정이며, 텔레메트리가 모든 계층을 일관되게 포괄할 때만 가능합니다. 모델 스팬의 지연 시간과 오류 신호는 LLM 자체를 가리킵니다. 검색 스팬은 반환된 맥락이 관련성 있었는지 또는 오래됐는지 보여줍니다. 도구 호출 스팬은 실패한 API 종속성이나 권한 오류를 드러냅니다.

앞서 말했듯 에이전트가 의존하는 하위 시스템의 텔레메트리도 필요합니다. 호출 형식은 완벽해도 신뢰한 데이터가 갱신되지 않았다면 에이전트는 잘못된 답을 낼 수 있습니다. 하나의 신호만으로는 전체 이야기를 알 수 없습니다. 모든 계층을 한곳에서 연결해 보는 능력이, 에이전틱 실패를 빠르게 디버깅하는 팀과 여전히 추측하는 팀을 가릅니다.

기업이 대규모로 에이전트 행동을 이해하려 할 때 가장 중요한 텔레메트리 데이터는 무엇입니까?

기반은 여전히 MELT, 즉 메트릭, 이벤트, 로그, 트레이스지만 에이전틱 시스템에서는 중요도의 무게중심이 크게 달라집니다. 메트릭은 문제가 있다는 사실을 알려주고 로그는 일어난 일의 원시 기록을 제공하지만, 에이전트가 잘못된 답에 이르기까지 어떤 추론 사슬을 따랐는지는 재구성하지 못합니다. 그래서 트레이스가 가장 중요한 신호가 됩니다.

전통적인 분산 시스템의 트레이스는 요청이 서비스를 어떻게 통과했는지 보여줍니다. 에이전틱 시스템에서는 모델이 문제를 어떻게 추론했는지, 어떤 도구를 호출했는지, 어떤 맥락을 검색했는지, 어디에서 분기했고 각 단계에서 어떤 결정을 내렸는지 보여줍니다. 트레이스가 없으면 결과만 볼 뿐, 어떻게 그 결과에 도달했는지 설명할 방법이 없습니다.

다른 MELT 신호가 사라지는 것은 아닙니다. 토큰 사용량과 지연 시간 메트릭은 비용과 성능에 중요하고, 하위 시스템 로그도 계속 필수입니다. 다만 대규모로 에이전트 행동을 이해할 수 있게 만드는 것은 트레이스입니다.

AI 논의는 여전히 환각에 크게 집중합니다. 기업이 잘못된 검색, 끊어진 통합, 지연 급증, 누락된 맥락 같은 운영 실패를 과소평가하고 있습니까?

프로덕션에서 나타나는 환각 대부분은 사실 운영 실패가 모습을 바꾼 것입니다. 잘못된 검색이 오래됐거나 불완전한 맥락을 반환하면 모델은 빈틈을 그럴듯한 말로 채웁니다. 통합이 깨지면 에이전트는 올바른 추론에 필요한 데이터를 애초에 받지 못합니다. 실패한 ETL 작업 때문에 맥락이 누락된 현상은 환각처럼 보이지만 실제로는 인프라 문제입니다.

팀이 차이를 볼 수 없으면 보통 자신들이 통제할 수 있는 모델 자체에 손을 댑니다. 시스템 프롬프트를 반복 수정하고, 가드레일을 더하고, 평가 프레임워크를 다듬습니다. 이런 기법에도 가치가 있지만 원인이 아니라 증상을 치료하는 셈입니다. 내 경험상 가장 효과가 큰 투자는 거의 항상 검색 계층의 데이터 품질과 최신성입니다. 깨끗하고 최신인 데이터에 제대로 기반을 둔 에이전트는, 오래되거나 불완전한 맥락을 쓰며 프롬프트만 정교하게 다듬은 에이전트보다 언제나 낫습니다.

에이전트가 더 자율적으로 변할수록, 조직은 소음에 압도되지 않으면서 책임성을 유지하기 위해 무엇을 기록하고 추적하며 모니터링해야 합니까?

기반은 여전히 MELT지만, 에이전틱 시스템의 책임성을 확보하려면 전통적 텔레메트리 위에 평가 프레임워크를 얹어야 합니다. 메트릭, 이벤트, 로그는 모델이 답하기 전에 행동을 오염시킬 수 있는 인프라 실패와 통합 장애를 보여주고, 트레이스는 특정 답에 도달한 추론 사슬을 제공합니다. 그러나 어느 쪽도 그 답이 실제로 옳았는지는 말해주지 못합니다. 그 공백을 LLM-as-judge 평가가 채웁니다.

에이전트를 구동하는 AI 역량을 에이전트 평가에도 사용할 수 있습니다. 사람이 검토하는 방식으로는 불가능한 규모에서 정확성, 근거성, 작업 완료도를 채점합니다. 프로덕션 전에는 품질 관문으로 작동해 사용자에게 도달하기 전 회귀를 잡아냅니다. 프로덕션에서는 실시간 트래픽을 표본으로 뽑고 허용 기준을 벗어난 응답을 표시하는 지속적 모니터가 됩니다.

소음을 피하는 핵심은 모든 에이전트 워크플로의 위험이 같지 않다는 사실을 인식하는 것입니다. 획일적 모니터링에서 벗어나 업계가 ‘human-on-the-loop’ 거버넌스라 부르기 시작한 방식으로 옮겨야 합니다. 행동 기준선과 신뢰도 임계값을 미리 정하고, 에이전트가 그 범위에서 작동하게 하며, 예외에만 사람이 개입합니다.

보안, SRE, 데이터, AI 팀이 에이전트 행동을 하나의 공통된 관점에서 보도록 만드는 데 텔레메트리 파이프라인은 어떤 역할을 할 수 있습니까?

보안팀, SRE, 데이터 엔지니어, AI팀은 서로 다른 도구로 같은 문제의 다른 단면을 보며, 어느 팀도 혼자서는 전체 그림을 갖지 못합니다. 텔레메트리 파이프라인이 현대 엔터프라이즈 데이터 아키텍처의 표준 구성 요소가 된 이유는 바로 이 문제를 해결하기 때문입니다. 모든 도구 앞에 단일하고 잘 관리된 파이프라인을 두면 팀마다 별도의 에이전트와 수집기를 배포하지 않아도 모두가 정규화되고 보강된 동일한 데이터를 사용할 수 있습니다.

그 유연성은 두 수준에서 중요합니다. 첫째는 데이터 계층화입니다. 잘 설계된 텔레메트리 파이프라인은 데이터에 맞는 저장·분석 전략을 적용해, 장기 규정 준수 보관에만 필요한 데이터에 분석 계층 가격을 지불하지 않게 합니다. 둘째는 AI 도구 환경이 빠르게 변할 때 선택권을 유지하는 것입니다. 관측 가능성 전략을 한 공급업체 생태계에 묶은 기업은 더 나은 도구가 나올 때마다 비싼 마이그레이션을 해야 합니다.

기업이 기존 모니터링 관행을 에이전틱 AI 배포에 억지로 적용할 때 어떤 실수를 가장 자주 봅니까?

가장 흔한 실수는 비용 영향을 먼저 생각하지 않고 기존 프리미엄 관측 가능성 플랫폼으로 에이전트 트레이스를 수집하는 것입니다. 에이전틱 트레이스는 전통적인 애플리케이션 텔레메트리와 달리 크고, 가변적이며, 양이 많습니다. 프리미엄 플랫폼 대부분은 수집량과 저장량을 기준으로 과금합니다. 팀이 상황을 깨닫기도 전에 비용이 심각한 문제가 되고, 전형적인 대응은 수집량을 줄이는 것입니다. 높은 비용과 불완전한 가시성이라는 최악의 조합이 됩니다.

두 번째 실수는 모니터링이 답해야 할 질문에 잘못된 사고방식을 적용하는 것입니다. 전통적 인프라 모니터링은 “시스템이 가동 중인가?”를 묻고 그렇지 않을 때 경보를 냅니다. 이 질문도 필요하지만, 인프라는 완전히 정상인데 에이전트가 조용히 나쁜 결정을 내리고, 오래된 데이터를 검색하고, 원래 목표에서 벗어날 수 있는 에이전틱 시스템에는 턱없이 부족합니다. 기존 대시보드와 경보 임계값을 에이전트 워크플로에 그대로 붙인 팀은 배관만 지켜보면서 전체를 포괄한다고 착각하기 쉽습니다.

세 번째는 계측을 사후 작업으로 취급하는 것입니다. 에이전트를 빠르게 시험하고 관측 가능성을 고려하지 않은 채 프로덕션으로 옮기면, 첫 중대한 장애 뒤에 데이터 수집 아키텍처를 다시 짓는 비싼 복구 주기에 들어갑니다. 에이전트 배포를 성공적으로 확장한 팀은 일찍 계측하고, 트래픽이 적고 행동이 예측 가능할 때 기준선을 만들며, 문제가 생긴 뒤가 아니라 필요하기 전에 평가 프레임워크를 구축합니다.

앞으로 인프라 가시성은 대규모 클라우드 이전에 클라우드 관측 가능성이 필수가 된 것처럼, 엔터프라이즈 AI 도입의 전제 조건이 될까요?

클라우드와 매우 유사합니다. 고객에게 클라우드로 인프라를 옮길 때 가장 강조하는 것은 단순한 리프트 앤 시프트가 아니라는 점입니다. 새로운 역량을 갖춘 완전히 새로운 아키텍처를 배포하는 일입니다. 기존 도구로는 준비되지 않았을 가능성이 높은 방식으로 모든 것을 계측하고 모니터링해야 합니다. 이 단계를 건너뛴 기업은 진단할 수 없는 연쇄 장애, 설명할 수 없이 치솟는 비용, 예방할 수 없는 중단을 겪었습니다.

관측 가능성은 클라우드를 대규모로 신뢰하게 만든 토대였고, 같은 양상이 지금 더 빠르고 더 큰 위험을 안은 에이전틱 AI에서 나타납니다. 에이전트가 이런 감독을 계속 필요로 하는 가장 큰 이유는 설계상 비결정론적이고, 행동이 런타임에 나타나며, 새 도구를 연결할 때마다 실질적인 역량이 커지기 때문입니다. 정적 배포 전 인증으로는 통합할 때마다 행동 범위가 바뀌는 시스템을 포괄할 수 없습니다.

에이전트는 정해진 신뢰 경계 안에서 작동하고, 관측 가능성·정책·평가 인프라가 성숙함에 따라 그 경계는 넓어질 것입니다. 경계 자체가 사라지지는 않으며, 그것은 실패가 아닙니다. 세상에서 중대한 결과를 초래할 수 있는 모든 자율 시스템이 이미 작동하는 방식입니다.

훌륭한 인터뷰에 응해 주셔서 감사합니다. 자세히 알고 싶은 독자는 Cribl을 방문해 보시기 바랍니다.