“AI 준비”라는 표현이 요즘 거의 모든 제품 카테고리에 붙어 있습니다. 이 매력적인 라벨은 거의 구체적인 의미를 갖지 않으며, 벤더들이 “AI 네이티브”라고 주장할 때도 추가 질문이 필요합니다. 마케팅 용어를 모두 걷어내고 나면, 슬로건이 아닌 표준이 필요합니다. 그리고 그 정의는 데이터의 용도에 따라 달라집니다. 데이터 웨어하우스를 위한 AI 준비와 실시간 운영 텔레메트리를 위한 AI 준비는 같은 문제가 아닙니다.
텔레메트리 데이터는 엄청난 미개발 가치를 지니고 있으며, AI 보안을 판매하는 모든 벤더는 동일한 주장으로 시작합니다: 우리의 모델이 더 똑똑합니다. 하지만 정리되지 않은 데이터를 읽는 더 똑똑한 모델은 나쁜 날에는 더 빠르게 환각을 일으킵니다. 좋은 날에는 엄청난 양의 토큰을 소비하면서 비정형 데이터에 구조를 추가합니다. 진짜 질문은 에이전트가 얼마나 지능적인가가 아닙니다. 텔레메트리가 처음부터 에이전트가 소비하도록 구축되었는가입니다.
AI 준비 텔레메트리란 무엇입니까?
AI 준비 텔레메트리는 단일 속성으로 정의되지 않습니다. 이미 도래하고 있는 에이전틱 워크플로를 위해 텔레메트리 데이터 레이크가 준비되었는지를 정의하는 6가지 차원이 있으며, 각각이 이전 것을 기반으로 합니다. 보안 및 옵저버빌리티 스택 위에 덧붙인 기능이 아니라, 그 아래 데이터에 대한 표준입니다. 저희는 이 6가지 속성이 AI 준비 텔레메트리를 정의한다고 믿습니다:
- 통합: 데이터가 하나의 쿼리 가능한 평면에 존재합니다.
- 정규화: 데이터는 일관된 구조와 의미를 갖습니다.
- 상관관계/컨텍스트화: 신호들이 서로 연결되어 있고 이를 이해하는 데 필요한 지식으로 강화됩니다.
- 최신성: 데이터는 최근 및 과거 시간대에 걸쳐 필요할 때 사용 가능합니다.
- 조사 가능성: 플랫폼은 데이터를 유용한 답변으로 변환할 수 있으며, 단순히 원본 결과만 반환하지 않습니다.
- 책임성: AI 추론 및 조치는 사후에 이해, 관리, 추적될 수 있습니다.
운영 텔레메트리는 정지하지 않기 때문에 이 문제는 더욱 심화됩니다. 메트릭, 이벤트, 로그, 트레이스(때로는 MELT 데이터라고 함)는 AI 에이전트가 나중에 이를 읽을 수 있다는 것을 알지 못하는 시스템에 의해 지속적으로 생성되며, 기계 소비를 위해 설계되지 않은 볼륨과 형식으로 생성됩니다. 그리고 이 데이터를 읽는 AI는 점점 더 챗봇을 위한 사실을 검색하는 것이 아닙니다. 실시간 사고를 진단하고, 활성 위협을 조사하며, 점점 더 많은 배포에서 실제 결과를 초래하는 조치를 취하고 있습니다.
각 기능이 실제로 어떻게 보이는지 살펴보겠습니다.
통합: 모든 것을 지배하는 하나의 평면
첫 번째 요구사항은 가장 기본적이면서도 가장 자주 실패하는 것입니다: 로그, 메트릭, 트레이스, 보안 이벤트는 누군가 또는 어떤 에이전트가 수동으로 교차 참조해야 하는 4개의 별도 도구가 아닌 단일의 쿼리 가능한 평면에 존재해야 합니다. 페더레이션 검색, 강력한 API, MCP 지원 워크플로의 발전에도 불구하고, 중요한 데이터를 다양한 형식의 사일로에 흩어져 있게 두는 것은 이상적인 최종 상태가 아닙니다. 에이전트가 문제를 해결하기 위해 필요하다고 생각하는 데이터 조각들을 함께 모아야 할 때, 그것이 잘못될 위험은 사라지지 않습니다. 단지 포착하기가 더 어려워질 뿐입니다.
중간 규모의 핀테크 회사의 당직 엔지니어가 사고 상황에 처해 있다고 상상해 보세요. 오류율 메트릭은 한 대시보드에 있고, 로그는 두 번째 도구에 있으며, 트레이스 데이터는 세 번째에 있고, 보안 이벤트는 완전히 다른 네 번째 시스템에 있습니다. 이 시나리오에서 누구도 잘못이 없습니다. 각 도구는 자신의 역할에서 완벽할 수 있습니다. 하지만 사고 중에 엔지니어의 업무는 조사가 아니라 탭 전환과 정신적 변환이 됩니다.
동일한 단편화에 직면한 AI 에이전트는 그 엔지니어보다 마술처럼 더 똑똑해지지 않습니다. 액세스할 수 없는 시스템에 있는 그림의 일부를 볼 수 없기 때문에 더 빠르게 실패할 뿐입니다.
Open Cybersecurity Schema Framework와 AWS Security Lake와 같은 서비스는 업계가 수십 개의 벤더에 흩어진 보안 및 운영 데이터가 관리 불가능해지고 있다는 것을 인식했기 때문에 존재합니다. 현재 50개 이상의 벤더가 Security Lake와 통합되어 있으며, 각각이 조정이 필요한 하나의 형식을 더 추가합니다. 통합하려는 본능은 이제 Sumo Logic의 의견이 아닌 업계 전반의 것입니다. 기계 속도와 기계 규모로 운영하는 시대에는 협상의 여지가 없습니다.
통합은 모든 것을 위한 하나의 벤더를 의미하지 않습니다. “무슨 일이 있었는가?”라는 질문을 모든 것에 걸쳐 한 번에 할 수 있는 하나의 장소를 의미합니다. 그리고 그 통합 데이터 레이크가 통합 엔티티 모델과 통합 기관 메모리도 가지고 있다면, 에이전트는 단순히 데이터를 갖는 것이 아닙니다. 책임감 있게 추론하는 데 필요한 컨텍스트를 갖습니다.
정규화: 수동이 아닌 자동으로 적용되는 구조
위에서 이를 언급했지만, 자체 기둥으로 가치가 있습니다. 모든 것을 한 곳에 넣는 것은 문제의 절반을 해결합니다. 다른 절반은 원본 텔레메트리가 일관성 없는 형식의 혼란이라는 것입니다.
모든 애플리케이션, 모든 팀, 인프라의 모든 시대는 강제된 스키마 없이 로그를 약간씩 다르게 작성합니다. 이 문제는 새로운 것이 아닙니다. 유명한 XKCD 만화에서 포착한 것처럼, 누군가 경쟁하는 표준이 있다는 것을 깨달을 때마다, 그들은 또 다른 표준을 추가하는 훌륭한 아이디어를 얻습니다. 낙관적으로, OCSF와 ECS, 광범위한 업계 지원으로, 우리는 마침내 정규화 전투를 이기고… 심지어 전쟁도 이길 수 있습니다.
엄밀히 말하면, 파이프라인은 세 가지 뚜렷한 단계로 구성됩니다. 정규화란 새로운 데이터 소스가 나타날 때마다 맞춤형 통합 프로젝트를 수행하는 대신, 수집 시점에 파싱, 필드 추출, 스키마 매핑을 통해 자동으로 구조를 적용하는 것을 의미합니다. 다소 직관에 어긋나지만, 이는 인간보다 AI에 훨씬 더 중요합니다. 사람은 약간 형식이 맞지 않는 로그 라인을 눈으로 보고 그 의미를 추론할 수 있습니다. 하지만 동일한 데이터에 대해 추론하는 모델은 안정적으로 추론하기 위해 일관된 구조가 필요하며, 그렇지 않으면 노이즈에 대한 패턴 매칭만 수행하게 됩니다. 그리고 추론을 통해 극복할 수 있다 하더라도, 불필요한 토큰 소비가 발생합니다.
정규화는 데이터 위생 프로젝트가 아닙니다. 데이터를 정리하는 것은 문서의 오타를 교정하는 것과 같습니다. 파싱과 정규화는 다섯 가지 다른 언어로 작성된 문서를 하나의 공유 언어로 번역하는 것입니다. 필드 이름이 소스마다 다르면, AI 에이전트는 행위자와 대상을 구분할 수 있는 신뢰할 수 있는 방법이 없습니다.
한 방화벽 로그는 소스 및 대상 IP를 서로 다른 필드에 저장하며, 때로는 레이블이 없습니다. 클라우드 감사 로그는 작업을 수행한 사람을 userIdentity.arn이라고 부르고, 엔드포인트 로그는 TargetUserName이라고 부릅니다. 정규화된 스키마가 없으면, 횡적 이동 알림을 조사하는 에이전트는 공격자와 피해자를 바꿀 수 있고, 잘못된 사용자를 잘못된 자산과 연관시킬 수 있으며, 대상을 손상의 원인으로 표시할 수 있습니다.
여기서 주요 우려 사항은 AI가 실수를 바로잡지 못한다는 것입니다. 완전한 확신을 가지고 그것을 제시하고, 분석가는 그것에 따라 행동할 것입니다. 이제 “누가 무엇을 누구에게 했는가”가 다르게 표현되는 모든 로그 소스에 걸쳐 이를 곱해 보세요. 그러면 AI가 조사를 가속화하지 않는 플랫폼이 됩니다. 대신 기계 속도로 그럴듯하고 형식이 잘 맞춘 잘못된 답변을 생산하고 있습니다. 정규화는 모든 소스가 에이전트가 접근하기 전에 하나의 스키마로 매핑되도록 하므로, ‘src’는 항상 소스를 의미하고, ‘dst’는 항상 대상을 의미하며, 행위자는 항상 어느 벤더의 로그에서 나왔든 관계없이 작업을 시작한 엔티티를 의미합니다.
상관관계 및 컨텍스트화: 유형 및 시스템 전반에 걸쳐 연결된 신호
통합되고 정규화된 데이터를 보유하면 AI 에이전트가 각 요소에 액세스할 수 있습니다. 다음 과제는 이러한 요소들이 어떻게 함께 작동하는지 이해하도록 돕는 것입니다. 이를 위해서는 상관관계와 컨텍스트가 모두 필요합니다.
상관관계는 텔레메트리 전반에 걸쳐 인과관계를 공유하는 신호를 연결합니다. 추적 ID는 생성된 로그 라인에 연결되고, 이는 설명하는 메트릭 이상에 연결됩니다. 인간이든 AI든 조사자는 증상에서 근본 원인까지의 체인을 따라갈 수 있으며, 수동으로 조립할 필요가 없습니다. 상관관계는 다음 질문에 답합니다. 무슨 일이 일어났고, 그 원인은 무엇인가? 필요한 모든 것이 이미 데이터 스트림의 어딘가에 존재합니다. 문제는 이러한 요소들을 찾아 연결하는 것입니다.
컨텍스트는 데이터 스트림에 전혀 존재하지 않는 지식입니다. 이 서버가 CFO의 노트북이라는 사실입니다. IP 범위가 지난 금요일에 오프보딩된 계약업체에 속한다는 사실입니다. 서비스가 마이그레이션 중이며, 팀은 목요일까지 높은 오류율을 예상한다는 사실입니다. 알림 패턴이 지난 분기에 두 번 조사되었고 두 번 모두 알려진 오탐으로 종료되었다는 사실입니다.
과거에는 이러한 지식이 분석가의 머릿속, Slack 스레드, 아무도 업데이트하지 않는 위키 페이지, 또는 우연히 같은 시간에 커피를 마시고 있던 두 엔지니어 사이의 복도 대화에 존재했습니다. 그것은 실제였고, 중요했으며, 건물의 모든 자동화된 시스템에 완전히 보이지 않았습니다.
이 구분이 중요한 이유는 AI 에이전트가 추적 스팬을 따라 그것을 야기한 로그 오류까지 갈 수 있지만, 영향을 받는 서비스가 계획된 유지보수 기간 중이라는 것을 모르면 조사를 해결하지 못했기 때문입니다. 기술적으로는 정확하지만 운영상으로는 쓸모없는 알림을 생성했을 뿐입니다. 에이전트는 둘 다 필요하며, 이는 플랫폼이 둘 다 표시해야 함을 의미합니다. 상관관계를 위한 텔레메트리 전반의 인과 관계 링크와 에이전트가 쿼리할 수 있는 구조로 인코딩된 자산 소유권, 비즈니스 중요도, 변경 일정, 과거 조사 결과, 위협 인텔리전스 강화 등의 조직 지식이 필요합니다. 누군가의 기관 기억에 갇혀 있으면 안 됩니다.
현재: 이전에 일어난 일이 아닌 지금 일어나고 있는 일을 반영
이런 상황을 생각해 보세요. 위협 헌팅 후 중대한 보안 문제를 식별했습니다. 관련된 주요 엔티티 중 하나가 지난 6개월 동안 귀사 환경에서 발견되었습니다. 6개월 동안 있었다면, 그 이전은 어떨까요? 안타깝게도 적극적으로 비용을 지불하고 있는 보존 기간은 6개월뿐입니다. 더 오래된 데이터는 고정된 상태, 아카이브 또는 더 콜드한 데이터 계층에 갇혀 있습니다.
검색을 시작하기 전에 이 데이터를 재수화해야 하지만, 처리해야 할 볼륨이 많으면 시간이 걸립니다. 필요한 분석을 수행할 수 없기 때문에 손을 묶인 상태입니다. 이제 사건은 인간이 따라갈 수 있는 것보다 빠르게 전개됩니다. 이를 설명하는 데이터는 해동을 기다리는 콜드 스토리지에 있으면 안 되며, M.E.L.T. 빙하를 녹일 때쯤이면 공격자는 이미 움직였을 것입니다.
지연 시간은 보통 실시간 문제로 표현됩니다. 새로운 이벤트가 발생한 후 얼마나 빨리 쿼리 가능해지는가입니다. 하지만 지연 시간에는 두 가지 유형이 있습니다.
- 수집 지연 시간: 새로운 데이터가 얼마나 빨리 사용 가능해지는가입니다.
- 과거 쿼리 지연 시간: 이미 존재하는 데이터를 얼마나 빨리 검색할 수 있는가입니다.
손상된 서비스 계정을 조사하는 에이전트는 지난 1시간의 인증 로그만 필요한 것이 아닙니다. 이 계정이 지난 1년 동안 유사한 동작을 보였는지 여부를 확인하고, 동일한 IP가 6개월 전에 다른 컨텍스트에서 나타났는지 여부를 확인하며, 엔티티의 액세스 패턴이 점진적으로 변했는지 아니면 하루 밤 사이에 변했는지 확인해야 합니다. 이러한 질문에 답하기 위해 긴 재수화 작업이 필요하면, 에이전트의 조사는 과거 컨텍스트가 전환점이 되었을 정확한 지점에서 정체됩니다.
AI 에이전트가 조사 타임라인을 구축할 때, 실시간 수집 지연 시간과 과거 쿼리 지연 시간 모두 동등하게 중요합니다.
합리적인 범위 내에서 데이터는 항상 액세스 가능해야 합니다. 모든 텔레메트리 및 소스의 집계된 보기를 보유하고 있으며, 어떤 시간대에서든 액세스할 수 있다는 것은 오늘날의 환경에서 생성되는 더 많은 활동을 생성하는 에이전트, 인간 및 머신 간의 동작 패턴을 이해하는 데 필수적입니다. 이것이 클라우드 네이티브 보안 및 옵저버빌리티 데이터 레이크의 개념이 경영진 및 운영 팀 모두에게 공감을 얻고 있는 이유입니다.
AI 에이전트가 빙산의 일각만이 아닌 모든 데이터를 기반으로 권장 사항을 제시하기를 원합니다. 더 완전한 데이터, 더 정확한 답변, 더 시기적절한 수정.
조사 가능: 데이터를 저장하는 것이 아닌 답변을 생성하도록 구축됨
처음 네 가지 기둥은 데이터의 속성을 설명합니다. 통합, 정규화, 상관관계 및 현재. 플랫폼을 제공하는 것에 대해 아무것도 모르고도 데이터를 보면 각각을 확인할 수 있습니다.
조사 가능성은 다릅니다. 누군가 또는 무언가가 데이터를 사용하려고 할 때 일어나는 일에 관한 것입니다. 기둥 1부터 4까지 완벽하게 달성하면, 조사 가능성이 자연스러운 결과라고 주장할 수 있습니다. 절대 그렇지 않습니다. 완벽하게 통합되고, 정규화되고, 상관관계가 있으며, 실시간 데이터셋이 45초 동안 결과를 반환하는 쿼리 엔진, 10,000개의 순위가 없는 결과를 반환하고, 엔티티별로 범위를 지정하는 개념이 없으며, 첫 번째 답변을 기반으로 후속 질문을 할 수 있는 방법이 없는 쿼리 엔진 뒤에 있을 수 있습니다.
데이터는 완벽합니다. 조사 경험은 쓸모없습니다. 아름답게 설계된 데이터 웨어하우스와 형편없는 BI 도구를 사용해 본 사람이라면 누구나 이 정확한 문제를 경험했을 것입니다.
처음 네 개의 기둥을 레시피로, 다섯 번째 기둥을 오븐으로 생각해 보세요. 나쁜 오븐은 완벽한 레시피를 매번 망쳐 놓으며, 재료의 품질이 아무리 좋아도 이를 보상할 수 없습니다. 성숙한 고객의 경우, 오븐이 바로 AI 에이전트 배포가 실제로 실패하는 지점입니다. 모델은 추론할 수 있습니다. 데이터도 있습니다. 하지만 플랫폼이나 AI 하네스가 충분히 빠르게 올바른 데이터 조각을 제공하지 못하고, 충분히 엄격하게 범위를 지정하지 못하며, 조사가 요구하는 시간 내에 에이전트가 유용하게 활용할 수 있도록 충분한 컨텍스트를 첨부하지 못합니다.
플랫폼 수준에서 조사 가능성을 위해서는 다음이 필요합니다.
- 결과 집합이 아닌 타임라인을 반환하는 엔티티 범위 쿼리.
- 모든 답변에 사전 상관관계 컨텍스트를 첨부하여 에이전트가 두 번째 왕복 없이도 보고 있는 내용을 이해할 수 있도록 합니다.
- 첫 번째 결과가 가장 최근의 일치가 아닌 가장 가능성 높은 답변이 되도록 순위가 지정된 관련성.
- 에이전트의 추론 루프에 맞는 응답 시간으로, 사용자가 로딩 스피너를 기다리는 시간이 아닙니다.
데이터를 잘 저장하는 플랫폼과 조사 가능한 플랫폼의 차이는 도서관과 연구 보조원의 차이와 같습니다. 둘 다 같은 책에 접근할 수 있습니다. 한쪽은 열린 페이지를 건네줍니다.
책임성과 추론
AI 에이전트가 조치를 제안하는 것에서 실행하는 것으로 이동하는 순간 마지막 기둥이 중요해집니다. 또는 운영 모델의 언어로 표현하면, 휴먼 인 더 루프에서 휴먼 온 더 루프로, 그리고 완전히 휴먼 아웃 오브 더 루프로 이동하는 것입니다.
추천 엔진은 큰 결과 없이 잘못될 수 있습니다. 프로덕션 액세스 권한을 가지고 자율적으로 작동하는 에이전트는 다른 문제입니다. 그 추론과 조치는 규정 준수 사후 대응이 아닌 운영 요구 사항으로서 사후에 재구성 가능해야 합니다.
이것이 바로 업계의 관심이 집중된 지점입니다. 엔터프라이즈 기술 리더십을 연구하는 분석가들은 “AI 활성화 및 보호”를 올해 보안 리더의 최우선 과제로 지정했으며, 에이전틱 위험의 존재를 단순히 주장하기보다는 이에 대한 통제를 입증하는 데 중점을 두고 있습니다. 엔지니어링 리더십에 대한 별도의 연구에 따르면 대다수의 기술 리더들은 이미 AI 에이전트를 보안 위험이 증가하고 있는 것으로 보고 있으며, 그 이유는 이들에게 부여된 액세스 범위가 적용되는 감시에 비해 매우 광범위하기 때문입니다. 최근 Hugging Face 사건이 이의 예입니다. 일부 분석가들은 10년이 끝나갈 무렵에는 엔터프라이즈 보안 사건의 상당한 부분이 기존 공격 벡터가 아닌 AI 에이전트 오용으로 거슬러 올라갈 것으로 예측하고 있습니다.
책임성은 또한 에이전트가 수행하는 모든 작업이 남기는 흔적을 의미합니다. 관례가 아닌 플랫폼 수준에서 관리되는 액세스입니다. 모든 에이전트가 본 것, 결정한 것, 수행한 것에 대한 지속적이고 쿼리 가능한 기록으로, 조치 자체와는 별개이므로 6개월 후에 “왜 이런 일이 발생했는가?”라는 질문에 실제 답변이 있습니다. 그리고 중요하게도, 이는 피드백 루프를 의미합니다. 실수가 한 번 발생하면 그것은 AI의 책임입니다. 모델을 재학습하거나 프롬프트를 개선하지 않아서 같은 실수가 두 번 발생하면 그것은 우리의 책임입니다. 책임성은 단순히 감사 추적이 아닙니다. 그 추적이 읽혀지고 조치되도록 보장하는 시스템입니다.
기준을 실제로 충족하는 모습
이 프레임워크는 Sumo Logic 플랫폼이 설계된 기반을 설명하며, 저희는 저희 자신의 첫 번째 고객입니다. 저희 SOC는 저희 앱과 인프라를 보호하기 위해 저희 에이전트를 사용합니다. Mobot, SOC Analyst Agent, 그리고 더 광범위한 팀 오브 에이전트 아키텍처는 이 여섯 기둥에 의존합니다. 이들 없이는 작동하지 않습니다. 어떤 에이전트도 마찬가지입니다.
Mobot의 로그, 메트릭, 트레이스를 단일 대화형 흐름에서 조사할 수 있는 능력은 기본 플랫폼이 이들을 사후에 함께 붙인 세 개의 별도 제품이 아닌 하나의 통합되고 정규화된 표면으로 취급하기 때문에만 작동합니다. 메트릭 이상에서 이를 설명하는 특정 로그 라인과 트레이스 스팬으로 이동할 때, 그것은 상관관계가 작동하는 것입니다. 영향을 받는 서비스가 특정 팀에 의해 소유되고 2시간 전에 배포되었다는 것을 알 때, 그것은 컨텍스트가 작동하는 것입니다.
그리고 SOC Analyst Agent가 결과 표시에서 이에 대한 조치로 이동함에 따라, 책임성은 추상적인 원칙에서 벗어나 보안 팀, 감사자 또는 이사회 앞에서 그 자율성이 실제로 방어 가능한지를 결정하는 것이 됩니다.
AI 환경은 계속 변할 것입니다. 모델은 더 빨라지고, 저렴해지며, 더 강력해질 것입니다. 에이전트는 증가할 것입니다. 이들을 구축하는 벤더들은 왔다 갈 것입니다.
하지만 생존할 플랫폼은 데이터를 올바르게 처리한 플랫폼이 될 것입니다. 왜냐하면 데이터는 이를 기반으로 학습된 모든 모델, 이를 추론하는 모든 에이전트, 그리고 이를 더 스마트하게 만들었다고 주장하는 모든 벤더보다 오래 지속되기 때문입니다. 여섯 기둥은 경쟁사에 대한 해자가 아닙니다. 이들은 그 위에 구축된 모든 것을 신뢰할 수 있게 만드는 기초입니다. 그리고 AI를 활용한 보안 운영에서 신뢰는 현재의 전쟁터입니다.
Sumo Logic이 이를 실제로 어떻게 수행하는지 확인해 보세요. 데모를 요청하세요.
