우리는 모두 AI 에이전트의 부상을 목격했습니다. AI는 텍스트를 요약하고, 코드 스니펫을 작성하고, 문서를 기반으로 질문에 답하는 데 탁월합니다. 하지만 DevOps 및 사이트 안정성 엔지니어링(SRE) 담당자에게는 답답한 한계가 있었습니다. 대부분의 에이전트는 콜센터 패러다임에 갇혀 있어 읽고, 생각하고, 채팅할 수는 있지만, 관리해야 할 인프라에 직접 접근하여 조작할 수는 없다는 것입니다.

최근 해커톤 프로젝트에서 Elastic은 이러한 한계를 뛰어넘기로 결정했습니다.

이에 Augmented Infrastructure를 구축했습니다. 이는 단순히 조언만 제공하는 것이 아니라 실시간 환경을 생성, 배포, 모니터링 및 수정하는 인프라 코파일럿입니다.

문제: 복사, 형식 변경, 붙여 넣기

표준 에이전트는 독립적으로 작동합니다. 앱이 다운되어 회사에 5백만 달러의 손실이 발생하면 표준 에이전트는 문제를 해결하는 방법에 대한 런북을 읽어줄 수 있습니다. 하지만 실제 작업은 여전히 사용자가 직접 해야 합니다. 코드를 복사하고, 환경에 맞게 형식을 변경한 다음, 터미널에 붙여 넣어야 합니다.

Kubernetes에 대해 이야기하는 것과 Kubernetes를 구성하는 것의 차이를 이해하는 에이전트가 필요했습니다.

엔진: Elastic Agent Builder란 무엇입니까?

이를 구축하기 위해 처음부터 모든 것을 새로 시작한 것은 아닙니다. Elastic Agent Builder를 기반으로 구축했습니다. Elastic Agent Builder는 에이전트를 신속하게 개발할 수 있도록 설계된 프레임워크로, 대규모 언어 모델(LLM)(데모에서는 Google Gemini를 사용)과 Elasticsearch에 저장된 개인 데이터 간의 연결 고리 역할을 합니다.

Agent Builder는 문서나 로그와 같은 내부 데이터를 기반으로 대화형 AI를 구현하는 데 사용할 수 있습니다. 하지만 Agent Builder의 가장 강력한 기능은 도구를 할당할 수 있다는 점입니다. 이러한 도구를 통해 LLM은 채팅 인터페이스를 벗어나 특정 작업을 수행할 수 있습니다. 이 기능을 최대한 활용하면 Agent Builder를 강력한 자동화 도구로 탈바꿈시킬 수 있다는 사실을 깨달았습니다.

작동시키기: 첫 번째 버전 구축

프로젝트를 시작할 때 에이전트가 외부 세계를 변화시킬 수 있도록 만들고 싶었습니다. 그래서 이런 아이디어를 떠올렸습니다. (에이전트가 호스트에서 생각할 수 있는 모든 명령을 실행하는) '실행기' 소프트웨어를 구축하면 어떨까? 그리고 만약 실행기, Elastic Agent Builder, 그리고 사용자가 3자 호출을 하면 어떨까?

먼저 Augmented Infrastructure 실행기라는 Python 프로젝트를 구축했는데, 이는 기본적으로 Elastic Agent Builder 대화 API를 매초마다 쿼리하고 당사가 만든 특수 구문을 확인하는 while(true) 루프였습니다.

그런 다음 새로운 도구 호출 구문에 대해 알려주도록 프롬프트를 업데이트했습니다. Bill은 Python으로 모델 컨텍스트 프로토콜(MCP) 서버를 구축하는 데 가장 많이 사용되는 프레임워크인 FastMCP의 유지 관리자입니다. Bill은 FastMCP 클라이언트와 이 새로운 실행기 소프트웨어를 사용하여 MCP 서버를 마운트하고 실행기에서 해당 도구를 사용할 수 있도록 하는 작업을 시작했습니다. 에이전트가 이를 확인하면 도구 호출을 실행하고 마치 사용자가 결과를 보낸 것처럼 결과가 대화창에 다시 POST됩니다. 이렇게 하면 LLM이 결과에 응답하게 되고, 그렇게 진행이 가능해집니다!

매우 훌륭했지만 다음과 같이 두 가지 주요 문제가 있었습니다.

1. 에이전트가 이 모든 JSON을 사용자와의 대화로 바로 내보냅니다.

2. 대화 API를 통해 메시지를 볼 수 있는 가장 빠른 시점이 대화 라운드가 완료된 시점(즉, LLM이 응답한 시점)입니다.

그래서 이를 백그라운드로 옮기는 방법을 파악하기 위해 노력했습니다.

그다음, 에이전트에 call_external_tool이라는 도구를 제공하고 tool_name과 문자열화된 JSON 도구 인수라는 두 개의 인수를 전달하도록 변경했습니다. 이 외부 도구 호출은 아무것도 반환하지 않지만, 중요한 것은 대화 API에 대한 GET 요청에서 확인할 수 있다는 점입니다. 그런 다음 실행기에 Elasticsearch에 직접 문서를 작성할 수 있는 권한을 부여했고, Elastic Agent Builder 에이전트는 필요에 따라 해당 문서를 검색할 수 있습니다. 에이전트는 항상 사용자 메시지에 응답하여 작동하므로, 에이전트가 결과를 찾고 처리를 계속할 수 있도록 사용자 메시지로 에이전트를 시작해야 합니다. 그래서 다음과 같이 에이전트가 채팅에 간단한 메시지를 삽입하여 대화를 재개하도록 했습니다.

이제 외부 도구 호출이 가능해졌습니다. 하지만 위에서 언급한 두 번째 문제 때문에 마지막 시작 단계를 없애야 했습니다. 그렇지 않으면 외부 도구를 호출할 때마다 결과를 얻기 위해 전체 대화 라운드를 거쳐야 했기 때문입니다.

효율적으로 만들기: 워크플로우 소개

Agent Builder 에이전트는 Elasticsearch 쿼리 언어(ES|QL) 및 인덱스 검색 도구 호출 외에도 Elastic 워크플로우 기반 도구를 호출할 수 있습니다. Elastic 워크플로우는 임의의 작업 순서와 로직을 실행할 수 있는 유연하고 관리하기 쉬운 방법을 제공합니다. 본 예시에서는 워크플로우가 외부 도구에 대한 Elasticsearch 요청을 저장하고 결과를 폴링할 ID를 반환하기만 하면 됩니다. 따라서 다음과 같은 간단한 워크플로우 정의가 생성됩니다.

이를 통해 도구 호출 요청이 대화에 기록되는 것에 의존하는 대신, 실행기는 새로운 외부 도구 요청에 대해 Elasticsearch distributed-tool-requests 인덱스를 폴링하고 제공된 execution.id를 사용하여 결과를 다른 Elasticsearch 인덱스에 보고할 수 있습니다.

이는 다음과 같이 위에서 언급한 두 가지 주요 문제를 해결합니다.

1. 대화 기록이 더 이상 외부 도구 호출에 위한 페이로드로 인해 복잡해지지 않습니다.

2. 실행기는 대화 기록 대신 Elasticsearch 인덱스를 폴링하므로, 외부 도구 요청을 표시하기 위해 대화 라운드가 완료될 때까지 차단되지 않습니다.

두 번째는 외부 도구 호출 처리가 대화 라운드가 완료된 시점이 아니라 에이전트의 사고 단계 내에서 시작된다는 큰 장점이 있습니다. 이를 통해 시스템 프롬프트에서 LLM에 외부 도구 결과가 나올 때까지 지속적으로 폴링하도록 지시할 수 있으며, 시작 메시지를 표시할 필요가 없습니다. 전반적으로 이러한 방식은 대화 흐름을 더욱 자연스럽게 만들어 줍니다. LLM은 단일 대화 라운드 내에서 여러 외부 도구 요청을 처리할 수 있으므로(도구 요청당 별도의 대화 라운드가 필요하지 않음), 더 복잡한 사용자 요청을 한 번에 처리할 수 있습니다.

한곳에 모으기

LLM과 서버 랙 간의 격차를 해소하기 위해 다음과 같이 Agent Builder의 도구 기능을 사용하여 특정 아키텍처를 개발했습니다.

1. Augmented Infrastructure 실행기: 대상 환경(서버, Kubernetes 클러스터, 클라우드 계정) 내부에 경량 실행기를 배포했습니다. 이러한 실행기는 각 실행기만 접근 가능한 보안 엔드포인트와 보안 정보를 사용하여 Elastic에 직접 연결됩니다.

2. ES|QL 검색: 코파일럿은 Elastic의 ES|QL을 사용하여 하이브리드 검색을 수행합니다. 단순히 지식을 검색하는 것이 아니라 기능을 검색합니다. 연결된 실행기에 쿼리하여 사용 가능한 도구(예: list_ec2_instances, install_helm_chart)를 확인합니다.

3. 워크플로우 실행: 에이전트가 작업 과정을 결정하면 구조화된 워크플로우를 생성합니다.

4. 피드백 루프: 실행기는 로컬에서 명령을 실행하고 그 결과를 다시 Elasticsearch에 보고합니다. 코파일럿은 인덱스에서 결과를 읽고 다음 단계를 결정합니다.

데모: 중단에서 통합 가시성으로

이 동영상에서는 이 아키텍처의 강력한 성능을 보여주는 두 가지 서로 다른 시나리오를 소개했습니다.

시나리오 1: DevOps 지원

Kubernetes 클러스터의 사각지대 때문에 5백만 달러 규모의 장애가 발생하여 패닉 상태에 빠진 사용자의 이야기로 시작했습니다.

• 요청: "이런 일이 다시 발생하지 않도록 하려면 어떻게 해야 하나요?"

• 작업: 에이전트는 단순히 튜토리얼만 제공하지 않았습니다. 클러스터 식별, 필요한 네임스페이스 생성, Kubernetes 보안 정보 생성, OpenTelemetry Operator 설치, 실시간 APM 대시보드에 대한 링크 즉시 제공을 수행했습니다.

• 결과: 사용자가 단 한 줄의 YAML도 작성하지 않고도 완전한 Kubernetes 통합 가시성과 애플리케이션 인사이트를 얻을 수 있습니다.

시나리오 2: 보안 인계

인프라 보안의 기본 원칙은 보이지 않는 것은 보호할 수 없다는 것입니다. DevOps 복구 작업을 수행하는 동안 에이전트는 환경의 보안을 개선할 기회를 포착합니다.

이전 Elastic Observability 관련 조사에서 발생한 경보를 통해 보안 담당자가 인프라와 직접 소통하는 방법을 시연합니다. 첫째, 클라우드 환경의 자산과 리소스를 열거하고, 둘째, 환경 보안을 보장하는 데 필요한 도구를 배포하는 방법을 보여줍니다.

• 탐색: 코파일럿은 보안 담당자를 위해 AWS 리소스를 열거하고 중요한 문제점을 발견했습니다. 해당 문제점은 엔드포인트 보호가 누락된 공용 엔드포인트가 있는 Amazon Elastic Compute Cloud(EC2) 인스턴스와 Amazon Elastic Kubernetes Service(EKS) 클러스터입니다.

• 조치: 간단한 승인으로 코파일럿은 Elastic Security 확장 탐지 및 응답(XDR), 클라우드 탐지 및 응답(CDR)을 취약한 자산에 배포하여 환경을 실시간으로 보호했습니다.

• 결과: 완벽한 런타임 보안을 통해 배포된 AWS 자산 및 리소스를 보호합니다.

미래: 모든 것이 증강되는 세상

이 프로젝트는 Elastic Agent Builder가 분산 운영의 핵심 역할을 할 수 있음을 입증합니다. 이는 인프라에만 국한되지 않습니다. 실행기 기술은 다음과 같은 분야에서도 활용될 수 있습니다.

• 증강 합성: 글로벌 실행기 전반의 TLS 오류 진단.

• 증강 개발: 풀 리퀘스트 생성 및 프론트엔드 서비스에서 CAPTCHA 구현.

• 증강 운영: 중단 발생 시 DNS 리졸버 자동 재구성.

직접 사용해 보기

AI의 미래는 단순히 채팅 지원에 그치는 것이 아니라, Augmented Infrastructure에 관한 것이라고 생각합니다. 즉, 고객과 함께 배포, 수정, 관찰, 보호할 수 있는 파트너를 확보하는 것입니다.

지금 바로 코드를 확인하고 분산 실행기(GitHub)와 Elastic Agent Builder를 Elastic Cloud Serverless 에서 직접 사용해 보세요!

• Elastic Cloud에서 서버리스 프로젝트를 생성하세요.

• 실행기에 코드를 배포하세요.

• 실행기를 설정하세요.

• mcp.json을 구성하세요.

• 실행기를 시작하면 에이전트와 그 도구가 자동으로 생성됩니다.

• 분산 실행기에 대한 추론, 계획 및 실행을 수행할 수 있는 에이전트와 채팅하세요!

팀: 알렉스, 빌, 길, 그레이엄, 노리