Kibana Dashboards API에서 이전 버전과의 호환성이 의미하는 사항

기술 미리 보기 기간에는 릴리스 간에 API 형태가 변경될 수 있었습니다.[1] 이제는 그렇지 않습니다. 정식 출시(GA)는 다음을 의미합니다.

• 완전한 이전 버전과의 호환성. 시간이 지남에 따라 새 필드와 패널 유형이 추가되지만, 기존 필드와 동작은 변경되지 않습니다. 향후 호환성이 깨지는 변경 사항은 매우 신중하게 검토되며, 새로운 주요 스택 버전에서만 도입됩니다.

• 프로덕션 준비 및 완전한 지원. API에는 Elastic의 완전한 지원 보증이 적용됩니다. 자동화된 배포, 환경 승격 및 프로그래밍 방식의 대시보드 관리에 이 API를 프로덕션 환경에서 안심하고 사용할 수 있습니다.

태그, Markdown 및 Links 패널을 위한 새로운 Kibana API 엔드포인트

Elastic 9.5에서는 대시보드를 분류하고 필터링할 수 있는 태그용 새로운 독립형 엔드포인트도 도입합니다. 이제 전용 CRUD 엔드포인트를 통해 태그를 프로그래밍 방식으로 관리할 수 있어, 여러 환경에서 대규모로 대시보드를 더 쉽게 구성할 수 있습니다.

새로운 Markdown 및 Links 패널 엔드포인트는 현재 Serverless에서 제공되며, 다음 스택 릴리스인 9.6에 추가될 예정입니다.

Kibana Dashboards API는 어떤 패널 유형을 지원하나요?

Dashboards API는 9.5의 모든 by-value 패널을 지원합니다. by-value 패널은 재사용을 위해 저장된 라이브러리 패널과 달리 대시보드에 직접 정의된 패널입니다. 지원되는 모든 패널 유형에는 타입이 지정되고 검증된 스키마가 있습니다.

패널 유형

상태

XY 차트

지원됨

메트릭

지원됨

파이

지원됨

게이지

지원됨

히트맵

지원됨

데이터 테이블

지원됨

트리맵

지원됨

Discover 세션

지원됨

컨트롤

지원됨

Markdown

지원됨

Links

지원됨

ML 패널

지원됨

Observability 패널

지원됨

Maps

출시 예정

Vega

출시 예정

Kibana 대시보드를 코드로 관리하는 방법

Dashboards API를 사용하면 코드 기반의 대시보드를 위한 전체 워크플로우를 구현할 수 있습니다. 대시보드를 차이 비교가 가능한 깔끔한 JSON으로 내보내고, 이를 단일 정보 원천으로 Git에 커밋하며, 풀 리퀘스트에서 변경 사항을 검토하고, 개발·스테이징·프로덕션 전반에 동일한 정의를 배포할 수 있습니다. 대시보드를 코드로 관리하기 시작했다면 Git을 단일 정보 원천으로 취급해야 합니다. UI에서 직접 변경한 내용은 다음 배포 시 덮어써집니다.

대시보드를 스페이스, 클러스터 또는 단계 간에 이동할 때 가장 큰 과제는 대시보드가 데이터 뷰와 라이브러리 시각화 같은 객체를 ID로 참조한다는 점입니다. 이러한 ID는 자동 생성되며 환경마다 다르므로, 한 환경에서 내보낸 대시보드가 다른 환경에는 존재하지 않는 객체를 가리킬 수 있습니다. 이를 처리하는 방법은 자동화 수준이 높은 순서부터 낮은 순서까지 다음 세 가지입니다.

• Terraform 사용. Elastic Stack Terraform provider는 각 리소스를 추적하고 환경별 ID를 자동으로 매핑하므로, 대시보드를 개발 환경에서 프로덕션으로 승격할 때 참조가 일관되게 유지됩니다.

• by-value Elasticsearch Query Language (ES|QL) 패널 정의. 가장 이식성이 높은 패널 생성 방법은 대시보드에서 ES|QL을 직접 사용해 시각화를 정의하는 것입니다. ES|QL 쿼리는 쿼리 내에 지정한 인덱스에서 읽어 오므로, 패널에는 데이터 뷰나 라이브러리 객체에 대한 외부 참조가 없습니다. 그 결과 완전히 독립적이고 이식 가능한 대시보드가 만들어집니다..

• 일치하는 ID 할당. 데이터 뷰나 라이브러리 시각화와 같은 저장된 객체를 참조하는 경우, ID를 자동 생성하는 POST 대신 PUT(업서트)을 사용하여 선택한 ID로 객체를 생성하세요. logs-prod와 같이 사람이 읽을 수 있는 ID를 사용하면 여러 환경에서 쉽게 재사용하고 식별할 수 있습니다.

이러한 이식성 패턴과 코드 기반의 대시보드를 위한 전체 워크플로우에 관한 자세한 안내는 코드 기반의 대시보드 관리 설명서를 참조하세요.

PUT을 사용하여 Dashboards API로 Kibana 대시보드 생성

다음은 POST 대신 PUT을 사용해 대시보드 이름인 service-health-overview를 사용자 지정 ID로 할당하고, 메트릭 패널을 포함한 대시보드를 생성하는 간단한 예입니다. 동일한 로직은 라이브러리에 저장되는 독립형 시각화를 만들 때도 적용됩니다.

Kibana Dashboards API 로드맵: Maps, Vega 및 독립형 엔드포인트

Elastic은 API 기능 범위를 활발히 확장하고 있습니다. 다음으로는 Maps 및 Vega 패널 지원을 추가하고, 이들 패널의 타입이 지정된 스키마를 제공합니다. 또한 기존 대시보드 패널 지원 범위를 넘어 Discover 세션용 독립형 CRUD 엔드포인트와 Vega, Maps 및 Annotations용 독립형 CRUD 엔드포인트도 구축하고 있습니다. 이 엔드포인트는 대시보드 수명 주기와 분리됩니다.

전체 스키마 정의는 Dashboards API 설명서에서 확인하세요. Terraform 사용자는 Elastic Stack Terraform provider를 통해 정식 출시된 Dashboards API를 사용할 수 있습니다.

참고

1. 핵심 엔드포인트는 기술 미리보기와 비교해 변경되지 않았습니다. 9.4를 대상으로 통합을 구축했다면 9.5에서도 작동합니다. 호환성이 깨지는 변경 사항은 대시보드 목록 표시 및 기간 단위 형식에 영향을 주는 사소한 변경 두 가지뿐이며, 여기에서 설명합니다.

오늘날에는 그 이야기가 훨씬 더 간단해졌습니다. Elastic Cloud API 키를 사용하여 Elastic Cloud Serverless에서 Elasticsearch 및 Kibana API에 대해 직접 인증할 수 있습니다. 이제 단일 자격 증명을 사용해 조직의 리소스를 관리하고, 이에 덧붙여 Elasticsearch 쿼리 언어(ES|QL) 쿼리, 데이터 수집 및 알림과 같은 데이터 작업을 실행할 수 있습니다.

이를 구축한 이유, 이를 가능하게 하기 위해 전 세계적으로 분산된 ID 계층을 설계한 방법, 프로젝트 간 검색의 토대를 마련한 방법을 살펴보세요.

비밀 관리 부담

데이터 플랫폼을 중심으로 안정적인 CI/CD 파이프라인, GitOps 워크플로우 또는 테라폼 자동화를 구축하는 데에는 숨겨진 비용, 즉 비밀스러운 확산이 따릅니다.

이전 모델에서 개발자들은 단절된 인증 방식에 직면했습니다.

• 컨트롤 플레인(Elastic Cloud API 키): Elastic Cloud API를 통해 프로젝트를 생성하고, 사용자를 초대하고, 청구를 관리하는 데 사용되는 조직 범위의 키입니다.

• 데이터 플레인(Elasticsearch API 키): 특정 서버리스 프로젝트 내부에서 생성된 프로젝트 범위 키로 Elasticsearch 및 Kibana API와 상호 작용합니다.

즉, 배포 스크립트는 Elastic Cloud에 인증하고 서버리스 프로젝트를 프로비저닝하며, 해당 프로젝트에서 새로 생성된 Elasticsearch API 키를 추출한 뒤 그 두 번째 키를 하위 애플리케이션이나 자동화 도구에 주입해야 했습니다. 이로 인해 복잡한 파이프라인, 조각화된 감사 로그, 자격 증명 유출 위험이 증가했습니다.

Elastic Cloud Serverless의 통합 인증

이번 릴리스에서는 서버리스 프로젝트의 분할이 사라졌습니다. 이제 클라우드, Elasticsearch 및 Kibana API에 대해 명시적으로 권한이 부여된 Elastic Cloud API 키를 생성할 수 있습니다.

• 이전: Elastic Cloud API 키는 컨트롤 플레인 토큰으로만 사용되었습니다. 프로젝트를 생성하고, 청구를 관리하며, 사용자를 초대할 수 있었지만 한계가 있었습니다. 해당 프로젝트 내에서 Elasticsearch나 Kibana API를 호출하는 데는 사용할 수 없었습니다. 데이터 작업을 위해서는 항상 프로젝트별로 구분된 두 번째 키가 필요했습니다.

• 현재: Elastic Cloud API 키를 생성할 때 클라우드, Elasticsearch 및 Kibana API 액세스를 선택하면 Serverless에 대한 엄격한 경계가 제거됩니다. 해당 API 키는 진정한 통합 자격 증명이 됩니다. 해당 솔루션은 조직의 인프라를 관리하는 기능을 유지하면서, 동시에 모든 권한 있는 서버리스 프로젝트에서 데이터를 쿼리, 인제스트 및 분석할 수 있는 기본 액세스 권한을 확보합니다.

Elastic Cloud API 키 하나로 이를 통합함으로써 범위를 지정하고, 감사하고, 순환하고, 하나의 단위로 취소할 수 있는 단일 ID를 얻게 됩니다. 모든 API 호출은 새 프로젝트를 프로비저닝하든 ES|QL 쿼리를 실행하든 감사 로그에서 동일한 자격 증명으로 표시되므로, 사고 조사 또는 규정 준수 검토 중에 단일 추적을 따를 수 있습니다. 자격 증명 순환이 더 이상 컨트롤 플레인 및 데이터 플레인 비밀 정보를 각각 따로 업데이트하는 방식이 아니라, 단일 단계 작업으로 처리됩니다. 또한 역할 할당은 프로젝트별로 이루어지기 때문에, 하나의 키로 여러 프로젝트에 걸쳐 통합 가시성 프로젝트에서 수집을 관리하고 보안 프로젝트에서 쿼리를 실행할 수 있으며, 각각에 대해 별도의 자격 증명을 처리하지 않아도 됩니다.

중요한 점은, '통합' 이 '전능함'을 의미하지는 않는다는 것입니다. role_assignments 페이로드를 사용하면 통합 키의 범위를 단일 프로젝트와 특정 역할(예: 읽기 전용)로 엄격하게 제한할 수 있어, 자격 증명이 노출되더라도 영향 범위가 완전히 제한되도록 보장합니다. 개발자가 퇴사하거나 애플리케이션이 폐기되는 경우, Elastic Cloud 콘솔에서 단일 키를 취소하여 컨트롤 플레인 및 연결된 모든 Elasticsearch 프로젝트 전반에 걸쳐 액세스를 즉시 종료할 수 있습니다.

(참고: Elastic Cloud Hosted/관리형 배포의 경우 클라우드 API 키는 여전히 컨트롤 플레인만 관리할 수 있습니다. 호스팅 스택 API에 대한 지원 확장은 향후 릴리스에서 제공될 예정입니다.)

워크플로우 자동화

시작 방법은 간단합니다. 이 모든 설정은 Elastic Cloud 콘솔을 통해 하거나 Elastic Cloud API를 사용해 자동화할 수 있습니다.

UI 프로세스는 동일하게 유지되지만, 이제 프로젝트 역할 할당에서 클라우드, Elasticsearch 및 Kibana API 액세스 권한을 선택할 수 있습니다.

다음은 Elastic Cloud API를 사용하여 프로그래밍 방식으로 통합 키를 생성하는 방법입니다. application_roles 배열에 주목하세요. 이 배열이 바로 키에 Elasticsearch 데이터 플레인에 대한 네이티브 액세스 권한을 부여하는 부분입니다.

생성된 후에는 이 키를 Authorization: ApiKey 헤더에 포함하여 api.elastic-cloud.com과 특정 서버리스 Elasticsearch 엔드포인트에 전달합니다.

작동 원리: 분산 ID 계층 구축

클라우드 API 키를 컨트롤 플레인과 데이터 플레인 모두에서 작동하도록 만드는 것은 단순히 토큰을 전달하는 것만큼 간단하지 않습니다. 이를 위해서는 근본적인 분산 시스템 문제를 해결해야 합니다.

과거에는 클라우드 API 키가 중앙 집중식 글로벌 보안 클러스터에 저장되었습니다. 컨트롤 플레인 작업에서는 더 높은 대기 시간이 허용되므로 잘 작동합니다. 하지만 Elasticsearch 데이터 요청은 지연 시간이 매우 짧아야 합니다. 모든 검색 쿼리나 인제스트 요청을 검증하기 위해 전 세계를 중앙 제어기로 왕복하는 비용을 감당할 수 없습니다.

이 문제를 해결하기 위해 당사는 전 세계적으로 분산된 데이터 저장소를 기반으로 하는 새로운 인증 아키텍처를 도입했습니다. 다음 시퀀스 다이어그램은 클라이언트가 Elastic Cloud API 키를 사용해 Elasticsearch 쿼리를 전송하는 것을 보여주며, 글로벌 컨트롤 플레인으로의 왕복 없이 전적으로 로컬 영역 내에서 인증이 어떻게 이루어지는지 설명합니다. Elasticsearch는 전 세계적으로 분산된 데이터베이스의 로컬 복제본에 대해 키를 검증하고 역할 할당을 확인하는 지역 IAM 서비스에 인증을 위임합니다. 인증이 완료되면 Elasticsearch는 쿼리를 실행하고 결과를 클라이언트에 반환합니다.

전 세계적으로 분산된 지속성

이제 Elastic Cloud API 키와 관련 역할 정의는 중앙 집중식 보안 클러스터에만 의존하는 대신, 전 세계적으로 분산되어 가용성이 높은 데이터베이스에 저장됩니다. 이 데이터베이스는 글로벌 컨트롤 플레인과 서버리스 프로젝트가 실제로 실행되는 지역 데이터 플레인 간에 아이덴티티 및 액세스 관리(IAM) 데이터를 동기화합니다.

지역 IAM을 통한 로컬 유효성 검사

클라이언트가 Elastic Cloud API 키를 사용하여 Elasticsearch에 요청을 보내면 해당 요청은 글로벌 제어 플레인으로 되돌아가지 않습니다. 대신 새로운 지역 IAM 서비스로 라우팅됩니다. 로컬 데이터베이스 복제본에 대해 키를 검증하여 지연 시간이 거의 없는 상태에서 인증이 이루어지고 글로벌 컨트롤 플레인 중단으로부터 완전히 격리되도록 합니다.

동적 역할 매핑

인증은 절반의 성공에 불과합니다. 시스템은 요청을 승인하는 절차도 수행해야 합니다. 지역 IAM 서비스는 클라우드 수준 역할 할당(예: application_roles)을 기본 Elasticsearch 권한으로 즉시 변환합니다. 그 후 Elasticsearch는 로컬 .security 인덱스 없이도 로컬에서 요청을 승인하고 실행할 수 있습니다.

프로젝트 간 검색의 기반

이 분산형 아이덴티티 아키텍처는 Elastic 플랫폼의 미래를 위한 기반이 되는 핵심 구성 요소입니다.

신원과 접근 권한이 통합되어 전 세계적으로 동기화되므로, 서로 다른 프로젝트 간에 안전하게 신원을 전달할 수 있는 프레임워크를 갖추게 되었습니다. 이를 통해 향후 Serverless 환경에서 구현될 프로젝트 간 검색(CPS) 기능을 사용할 수 있게 됩니다.

CPS를 사용하면 보안 및 통합 가시성 워크로드를 결합하는 것처럼 여러 원격 서버리스 프로젝트에 걸쳐 있는 데이터를 단일 데이터 세트처럼 쉽게 쿼리할 수 있습니다. 통합된 API 키를 사용함으로써 시스템은 복잡한 신뢰 관계, 인증서 또는 중복 자격 증명을 각 대상 프로젝트에 구성할 필요 없이 모든 프로젝트에 걸쳐 사용자의 권한을 자동으로 평가할 수 있습니다.

자세히 알아보기

스택을 간소화할 준비가 되셨나요?

• Elastic Cloud API 키 문서를 읽고 스택 접근 권한을 할당하는 방법을 알아보세요.

• 키 생성을 자동화하려면 API 키 생성(Elastic Cloud API) 참고 자료를 확인하세요.

• Elastic 플랫폼 전반에서 키 유형을 완전히 비교하려면 Elastic API 키를 확인하세요.

지금 바로 Elastic Cloud에서 빌드를 시작하거나 계속하세요.

안내 및 면책 조항

이 게시물에서 설명된 모든 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.

Elastic Workflows는 Kibana에 내장된 자동화 엔진입니다. 간단한 YAML 설정을 통해 여러 단계로 구성된 프로세스를 정의할 수 있습니다. 각 워크플로우는 일정 또는 이벤트에 따라 트리거될 수 있으며 Elastic Agent Builder의 도구로 활용할 수 있습니다. 또한 각 단계에서 Kibana API 호출, Elasticsearch 쿼리 실행, 데이터 변환 작업을 수행할 수 있습니다.

여기서는 대시보드 조회수를 구체적인 예로 사용하지만 Kibana saved objects API를 통해 노출되는 모든 메트릭에 동일한 패턴을 적용할 수 있습니다.

필수 구성 요소

• 9.3 버전이 실행 중인 Elastic Cloud 또는 자체 관리형 클러스터

• 워크플로우 기능 활성화(고급 설정)

1단계: Dev Tools에서 원시 데이터를 탐색하기

본격적인 구축에 앞서 우리가 활용할 데이터가 어떤 구성을 갖추고 있는지 먼저 이해해 봅시다. Kibana는 대부분의 설정 정보와 메타데이터를 전용 내부 인덱스에 Saved Objects라는 형태로 저장합니다. Kibana가 이러한 방식으로 추적하는 항목 중 하나는 대시보드 조회수입니다. 이때 'Usage Counters'라는 특수한 유형의 Saved Object를 사용하게 됩니다. 다음과 같이 Dev Tools에서 직접 쿼리할 수 있습니다.

응답은 다음과 같습니다.

counterName 필드는 대시보드의 ID를 나타내며 count는 해당 특정 날짜의 대시보드 누적 조회수입니다. Kibana는 대시보드당 하루에 하나의 카운터 객체를 생성합니다. 객체 ID의 날짜 접미사(예: ...viewed:server:20260310)를 통해 이를 확인할 수 있습니다. 조회수는 사용자가 대시보드를 열 때마다 하루 동안 계속해서 증가합니다.

인덱스에 이러한 일일 문서 모델을 그대로 복제하는 대신 워크플로우 실행당 하나의 문서를 생성해 보겠습니다. 각 문서는 캡처 시점을 기준으로 해당 대시보드의 당일 누적 조회수를 기록합니다.

2단계: 대상 인덱스 생성

대시보드 조회 스냅샷을 저장할 인덱스가 필요합니다. 나중에 집계와 시각화가 가능하도록 명시적 매핑을 사용하여 다음과 같이 인덱스를 생성합니다. Dev Tools에서 다음 명령을 실행하세요.

ID와 이름에 keyword 매핑을 사용하면 집계를 수행할 수 있습니다. view_count에 integer 타입을 사용하는 것은 안전한 기본값입니다. Kibana는 카운터를 매일 초기화하므로 32비트 제한(하루 20억 회 이상의 조회수)에 도달하는 것은 현실적인 우려 사항이 아니기 때문입니다. 이 타입은 여전히 max, avg, min과 같은 수치 연산을 지원합니다.

3단계: 워크플로우 생성

Stack Management > Workflows > New Workflow 메뉴로 이동한 뒤 아래의 워크플로우 YAML 설정 내용을 복사하여 붙여넣으세요.

다음 섹션에서는 워크플로를 단계별로 자세히 살펴봅니다.

워크플로우 작동 방식

트리거

워크플로우는 30분 간격의 예약된 트리거에 따라 실행됩니다. 이를 통해 API에 무리를 주지 않으면서도 시계열 데이터를 확보할 수 있습니다.

fetch_dashboard_views

kibana.request를 사용하여 Kibana Saved Objects API를 호출합니다. 별도의 인증 설정은 필요하지 않습니다. 워크플로우 엔진이 실행 컨텍스트에 따라 적절한 헤더를 자동으로 첨부하기 때문입니다.

index_each_dashboard (foreach)

이전 단계에서 반환된 saved_objects 배열을 순회합니다. 각 반복에서 현재 항목은 foreach.item을 통해 접근할 수 있습니다. 루프 내부에서는 각 대시보드에 대해 두 개의 하위 단계를 실행합니다.

1. fetch_dashboard_name:

GET /api/saved_objects/dashboard/{id}를 호출하여 사용자가 읽을 수 있는 대시보드 제목을 확인합니다. on-failure: continue: true설정을 추가합니다. 이를 통해 특정 대시보드가 삭제되었더라도 조회수 카운터가 남아있는 경우 전체 실행이 실패 처리되지 않고 루프가 계속 지속됩니다.

2. index_doc:

POST /dashboard-views/_doc을 사용해 명시적 ID 없이 각 문서를 인덱싱하며 이 과정에서 Elasticsearch가 ID를 자동으로 생성합니다. 이는 실행할 때마다 새로운 문서를 생성합니다. 이전 스냅샷을 덮어쓰지 않고 시간에 따른 조회수 이력을 쌓을 수 있습니다.

주목할 만한 두 가지 사항이 있습니다:

• captured_at 필드는 날짜 필터를 사용하여 타임스탬프를 ISO 8601 형식으로 변환합니다. 이 설정이 없으면 값이 Tue Mar 10 2026 05:03:47 GMT+0000과 같은 JavaScript 날짜 문자열로 출력됩니다. 이 경우 Elasticsearch가 이를 날짜 형식으로 매핑하지 못합니다.

• view_count는 숫자 유형을 유지하기 위해 ${{ }} 구문과 | plus: 0을 사용합니다. 단순히 {{ }}를 사용하면 값이 문자열로 렌더링되어 대시보드에서 수치 연산을 수행할 수 없게 됩니다.

UI를 통해 워크플로의 각 단계를 편리하게 디버깅할 수 있습니다.

4단계: 통계 대시보드 구축

워크플로우가 몇 번 실행되어 데이터가 수집되면 dashboard-views 데이터 뷰를 사용하여 Kibana에서 새 대시보드를 만듭니다.

활용 가능한 패널 예시:

• 조회수별 주요 대시보드: X축에 dashboard_name을, Y축에 last_value(view_count)를 설정한 막대 차트를 사용하세요. 이를 통해 각 대시보드의 현재 일일 조회수를 확인할 수 있습니다.

• 시간에 따른 조회수 변화: X축에 captured_at을, Y축에 last_value(view_count)를 설정하고 dashboard_name으로 구분한 선형 차트를 사용하세요. 워크플로우를 실행할 때마다 새로운 문서가 추가되므로 중복 합산 대신 'Last value' 집계를 사용하여 시간 버킷당 최종 수치를 가져옵니다.

• 현재 스냅샷: 가장 최근의 captured_at 데이터를 사용하는 데이터 테이블을 만들어 모든 대시보드의 최신 조회수를 표시하세요.

각 워크플로우 실행 시마다 새 문서가 생성되므로 시간 범위를 필터링하여 특정 기간의 활동을 분석하거나 주간 단위로 비교할 수 있습니다. 또한 대시보드 조회수가 임계값 아래로 떨어질 때 알림을 구축할 수 있습니다.

결론

Elastic Workflows는 이러한 주기적인 데이터 수집에 매우 적합합니다. 데이터 소스(Kibana API)와 대상(Elasticsearch)이 모두 네이티브로 연결되어 있어 자격 증명을 별도로 관리할 필요가 없기 때문입니다. 워크플로우 엔진이 kibana.request 및 elasticsearch.request단계의 인증을 자동으로 처리하므로 사용자는 로직만 작성하면 됩니다.

리소스

• Elastic Workflows

• Kibana API

Elastic의 종속성 관리

Elastic에서는 비공개 및 공개를 포함하여 수백 개, 심지어 수천 개의 리포지토리를 관리해야 합니다. 중요한 CVE가 발견되면 여러 질문에 대한 즉각적인 답변과 조치가 필요합니다. '어떤 리포지토리가 취약한가?', '얼마나 빨리 패치를 적용할 수 있는가?' 등이 있습니다. 보안 문제 외에 '수작업에 너무 많은 시간을 들이지 않고 새 패키지 버전의 릴리스를 해당 패키지에 의존하는 모든 리포지토리에 신속하게 전파하는 방법은 무엇인가?'라는 생산성 관련 질문도 제기됩니다.

종속성 관리 방법을 모색하게 된 초기 계기는 CVE 감소를 위해 자동화된 업데이트와 함께 안전한 기반을 구축해야 하는 필요성 때문이었습니다. 종속성 관리 솔루션을 신중하게 검토한 후, 우선 자체 호스팅된 인프라 구축에 착수했습니다. Mend Renovate Community 셀프 호스팅 에디션을 실행하기 위해 자체 Kubernetes 클러스터를 사용하고 있었습니다. 사용자들이 셀프 서비스 방식으로 접근할 수 있는 종속성 관리 플랫폼을 제공하는 것이 아이디어의 핵심이었습니다.

초기 실험이 성공적이었기 때문에 점점 더 많은 팀이 플랫폼에 온보딩하여 일상적인 리포지토리의 수명 주기에서 업데이트 및 CVE 패치에 이를 사용하기 시작했습니다. 이 과정이 너무 빨리 진행되어 곧 자체 호스팅 설치 용량의 한계에 도달했습니다.

과제: 대규모 조직에서 수많은 리포지토리를 관리할 때, 종속성 관리 플랫폼을 어떻게 확장할 수 있을까요?

기존 종속성 관리 플랫폼은 한 번에 하나의 리포지토리만 처리할 수 있었고, 수많은 리포지토리로 인해 순차적 처리 모델로는 대처할 수 없었습니다. 우리는 종속성 관리 도구의 단일 인스턴스로 점점 커지는 리포지토리 목록을 처리할 수 있다는 생각 자체에 문제가 있다는 것을 이미 인식하고 있었습니다. 리포지토리는 대기열에서 기다렸고, 때로는 몇 시간이 걸렸습니다. 매일 50% 이상의 리포지토리가 처리되지 않았습니다. 즉, 리포지토리의 50% 이상이 되기까지 24시간 이상 대기해야 했습니다.

대규모 리포지토리는 방대한 코드베이스와 여러 개의 열린 PR로 인해 더 큰 병목 현상을 일으켰습니다. GitHub 웹훅 이벤트는 시퀀스를 중단시켰습니다. Automerge는 스캔 타이밍을 예측할 수 없기 때문에 신뢰할 수 없었습니다. 사용자들에게 스캔 빈도에 대해 약속했지만, 그 약속을 지키지 못했습니다.

자체 구축 결정: Elastic 고유의 확장성 및 보안 요구 사항 충족

Mend의 Renovate Self-Hosted Enterprise 셀프 호스팅 에디션을 포함한 상용 옵션을 고려하면서, Elastic 내부적으로는 몇 가지 주요 이니셔티브를 강화하고 있었습니다.

Elastic의 타협할 수 없는 특정한 요구 사항을 충족할 수 있는 심도 깊은 맞춤형 솔루션만이 유일한 해결책이라는 인식에 따라 자체 플랫폼을 구축하기로 결정했습니다.

1. 내부 개발자 플랫폼 투자: 당시 내부 개발자 플랫폼에 대해 이미 대규모 투자를 시작한 상태였습니다. 각 서비스를 여기에 조화시키는 방식에 대해 논의하고 설계했습니다. 즉, 자체적으로 만든 종속성 관리 플랫폼의 규칙과 관행을 시험적으로 적용해 보고자 했습니다. 게다가 새로운 가이드라인이 시행될 예정이었기 때문에, 그 전에 플랫폼을 설계하고 싶었습니다.

2. 네이티브 통합 및 워크플로우 맞춤 설정: 내부 도구 및 내부 프로세스와의 간편한 통합이 필요했습니다. 예를 들어, 서비스 카탈로그(Backstage)를 사용하여 구성을 코드로 중앙 집중화하고자 했습니다. Backstage의 사용에 관한 특정 요구 사항이 있었으며 플랫폼이 이러한 요구 사항과 호환되기를 원했습니다. 따라서 Renovate 셀프 호스팅 API를 Backstage 자동화와 함께 사용하는 것이 가능하지만, 이것으로는 내부 프로세스를 완전히 지원할 수 없습니다.

3. Elastic에 특화된 심층 방어 보안: 엄격한 보안 규정 준수를 위해서는 에코시스템에 맞춘 맞춤형 보안 메커니즘이 필요했습니다. 우리는 "비인간 ID"의 사용을 강화하기 위해 노력하고 있었습니다. 이러한 액세스 강화 방식으로 인해 비표준적인 GitHub 인증 수단은 이 내부 구현을 지원하지 않는 기성 도구에서는 작동하지 않았습니다. 워크플로우에는 부모-자식 워크플로우 비밀 암호화 패턴 구현과 일시적인 일회성 GitHub 토큰 사용이 포함되었습니다. 자체 구축이 이러한 고유한 보안 계층을 내장하고 복잡한 멀티클라우드 환경 전반에 걸쳐 공격 표면을 최소화하는 유일한 현실적인 방법이었습니다.

해결책: 종속성 관리를 위한 워크플로우 오케스트레이션

솔루션은 이미 사용 중인 종속성 관리 도구를 대체하거나 다른 솔루션을 찾지 않고 이를 기반으로 구축한다는 데서 출발했습니다. 이는 가능성의 징후를 보였으며, 조직 전반에 걸쳐 다양한 요구에 맞추는 유연성이 중요했습니다. 다양한 솔루션을 고려했으며, 우리가 충족해야 할 중대하고 때로는 특별한 요구 사항을 토대로 결정을 내릴 수 있었습니다. 각 리포지토리가 독립적으로 처리되어 병목 현상이 발생하지 않고 성장을 위한 기반을 제공할 수 있도록 신뢰할 수 있고 확장성 있는 종속성 관리 플랫폼을 구축하기로 결정했습니다.

세 가지 핵심 원칙에 따라 플랫폼을 설계했습니다.

1. 병렬 처리

모든 리포지토리는 자체 종속성 관리 처리 환경을 갖습니다. 더 이상 대기열이 없습니다. 동시성은 사용하는 리소스의 수에 의해서만 제한됩니다. 또한 GitHub 속도 제한을 피하기 위해 스마트 분산 스케줄링을 적용했습니다.

2. 셀프 서비스 가능

서비스 카탈로그(백스테이지)를 사용하여 새로운 리포지토리를 자동으로 온보딩하고 관리합니다. 자체 리소스 정의를 사용하여 최종 사용자에게 리포지토리 처리 빈도, 스케줄에 할당할 리소스 수, 그리고 어떤 이유로든 처리를 끌지 아니면 다시 켤지 선택할 수 있는 옵션을 제공합니다. 사용자 요구 사항이 발전하고 새로운 설치 환경에 익숙해짐에 따라 이러한 방식으로 더 많은 옵션을 추가할 계획입니다.

3. 비밀 범위 축소 및 네임스페이스 격리

보안 강화를 위해, 각 워크플로우 시작 시 생성되는 임시 GitHub 토큰을 종속성 관리 포드에 제공합니다. 그뿐만 아니라, 필요한 비밀 키만 제공받을 수 있도록 워크로드를 특정 네임스페이스로 격리합니다. Kubernetes RBAC를 사용하여 각 종속성 관리 워크플로우에서 액세스할 수 있는 비밀 정보를 제어합니다. 또한 GitHub 토큰을 부모 워크플로우에서 자식 워크플로우로 전파할 때 암호화를 사용합니다.

Kubernetes를 사용하여 플랫폼을 재구축했으며, Kubernetes의 강력한 기능을 활용해 Argo Workflows는 프로세스 로직을 강화하고, Renovate CLI는 한 번에 하나의 리포지토리를 스캔하고 처리하도록 설정되었습니다.

장점: 검증된 오픈 소스 프로젝트를 독창적인 방식으로 활용하여 모든 프로젝트에 대해 새로운 작동 예제를 제공하는 동시에, 개발 속도를 높이고 팀의 CVE 감소를 강화합니다.

종속성 관리 아키텍처: 4개의 마이크로서비스

이 플랫폼은 맞춤 제작된 4가지 구성 요소로 이루어져 있습니다.

워크플로우 오퍼레이터(Go/Kubebuilder)

3가지 맞춤형 리소스 정의(CRD)를 통해 워크플로우 수명 주기를 관리하는 Kubernetes Operator:

• RepoConfig CRD: 리포지토리 구성을 위한 단일 정보 소스입니다.

다음은 오퍼레이터에서 RepoConfig가 정의되는 방식입니다.

다음은 RepoConfig 인스턴스의 모습입니다.

• 부모 CRD: 예약된 스캔을 위한 CronWorkflows를 관리합니다.

부모 컨트롤러의 조정 루프 내에서 워크플로우 설정이 생성되고 최신 상태로 유지되거나, 필요한 경우 삭제되는지 확인합니다.

먼저 워크플로우에 대한 몇 가지 전역 설정을 가져옵니다.

유사한 워크플로우가 동시에 실행되는 것을 방지하기 위해 mutex configmap이 최신 상태인지 확인합니다.

그런 다음 CronWorkflows와 워크플로우 템플릿을 생성하거나 업데이트하는 구조체인 Workflow Manager를 생성합니다.

• 자식 CRD: 리포지토리별 리소스로 워크플로우 템플릿을 관리합니다.

자식 컨트롤러는 부모와 유사한 조정 의무를 가지고 있지만, 이번에는 부모 워크플로우에 의해 트리거될 자식 네임스페이스의 워크플로우 템플릿에 대한 책임이 있습니다.

멀티 컨트롤러 패턴은 명확한 분리를 제공합니다. RepoConfig 컨트롤러는 온보딩/오프보딩을 처리하고, 부모 컨트롤러는 스케줄링을 관리하며, 자식 컨트롤러는 실행 템플릿을 처리합니다.

GitHub Events Gateway(Go)

GitHub 웹훅을 수신하고 서명을 확인하고 조직/리포지토리별로 필터링한 후 Argo Events로 라우팅하는 안전한 웹훅 프록시입니다. 종속성 대시보드 상호 작용, PR 이벤트 및 패키지 업데이트에 반응하는 10개의 서로 다른 센서를 구축했습니다.

이 게이트웨이는 다음을 통해 GitHub 앱과 통합할 수 있도록 지원합니다.

• 보안을 위해 수신되는 GitHub 웹훅 서명을 확인합니다.

• 유효한 이벤트를 모든 관련 헤더 및 인증 정보와 함께 Argo Events EventSource로 전달합니다.

• 또한 EventSource에 authSecret을 구성하고 전달된 요청의 Bearer 헤더로 이를 제공합니다.

• 로깅, 메트릭 및 재시도 로직을 제공합니다.

각 GitHub 이벤트 요청에 대해 다양한 검증을 수행합니다.

일부 HTTP 속성이 있는지 확인합니다:

또한 각 요청의 서명과 그 구성도 검증합니다.

마지막으로 이벤트 유형에 따라 Argo Events로 라우팅됩니다.

Argo Events 측에서는 10개의 센서가 새로운 이벤트를 감지하기 위해 Argo Events EventBus를 모니터링합니다.

그 후 스크립트는 각 센서의 논리를 적용합니다:

Backstage Syncer(Go)

이 작업은 서비스 카탈로그(Backstage)에서 리포지토리 실제 리소스 엔티티를 폴링하고, 이를 RepoConfig CRD로 변환하며, 플랫폼을 구성 변경 사항과 동기화된 상태로 유지합니다. 변경 사항은 3분 이내에 적용됩니다.

마지막으로 해당 데이터를 RepoConfig 인스턴스에 기록합니다.

워크플로우 베이스(혼합: JavaScript, Go, Helm)

기반 레이어에는 Helm 차트, JavaScript 구성, 암호화 지원 기능을 갖춘 Renovate CLI용 Go 래퍼, 그리고 Alpine 패키지용 맞춤형 APK 인덱서가 포함되어 있습니다.

셀프 서비스 구성

팀은 Backstage를 통해 리포지토리를 선언적으로 구성합니다.

리소스 그룹은 리포지토리 크기에 따라 CPU와 메모리를 할당합니다.

• SMALL: 500m CPU, 1Gi 메모리.

• MEDIUM: 1000m CPU, 2Gi 메모리.

• LARGE: 2000m CPU, 4Gi 메모리.

구성은 버전이 제어되고 감사 가능하며 자동으로 적용됩니다.

부모-자식 패턴

실행 모델은 부모-자식 워크플로우 패턴을 사용합니다.

• 부모 워크플로우: 예약된 시간에 실행되는 경량 CronWorkflow입니다. 비밀 정보를 암호화하고, 검사 실행 여부를 결정하며, 구성 정보를 자식 워크플로우에 전달합니다.

• 자식 워크플로우: Renovate CLI가 실행되는 임시 포드입니다. 동적으로 리소스를 할당하고, 격리된 상태에서 비밀 정보를 해독하며, 완료 후 종료합니다.

이러한 분리는 보안(부모 레벨에서 암호화된 비밀), 리소스 최적화(부모 레벨에서 최소한의 리소스 사용), 그리고 확장성(자식 레벨에서 병렬 실행)을 제공합니다.

결과

성능 변환

• 이전: 한 번에 하나의 리포지토리만 처리하고, 일부 리포지토리는 하루 이상 처리되지 않기도 했으며, 하루에 1,000건 미만의 스캔이 처리되었습니다.

• 이후: 100개 이상의 동시 스캔, 하루에 보통 8,000개 스캔, 최대 10,000개의 기록된 스캔이 이루어지며, 사용 가능한 리소스의 양과 GitHub 속도 제한을 처리하는 방법에 의해서만 제한됩니다.

비용 효율성

이상하게 들릴지 모르지만, 하루에 8,000개의 포드를 실행하는 것이 동일한 결과를 달성하기 위해 하나의 장기 실행 포드를 사용하는 것보다 훨씬 저렴할 수 있습니다.

이전 설정에서는 단일 인스턴스를 운영했고, 양호한 날에는 500~600번의 스캔을 수행했습니다. 또한, 서로 다른 종류의 리포지토리가 같은 포드에서 실행되기 때문에 가장 큰 리포지토리에 맞게 포드 크기를 조절해야 했습니다. 이는 포드용 CPU 8개와 16G 메모리를 사용하는 현재보다 훨씬 규모가 커질 수 있습니다.

현재의 일일 출력을 충족하려면 단일 포드는 12일 동안 실행되어야 합니다. 12일 동안 실행되는 단일 포드의 비용을 매일 실행되는 8,000개의 “MEDIUM” 크기 포드와 비교하면, 동일한 스캔 출력에서 새로운 설계가 훨씬 더 효율적입니다.

메트릭

시나리오 A(워크플로우)

시나리오 B(장기 실행 단일 포드)

설정

포드 8,000개(1 vCPU/2GB)

포드 1개(8 vCPU/ 16GB)*

기간

각각 10분

12일 연속

총 작업 시간

1,333 컴퓨팅 시간

288 컴퓨팅 시간

총 비용

$65.83

$113.75

이제 워크로드 기본값이 "SMALL"로 설정되어 있으며, 대다수가 0.5 CPU와 1G RAM으로 성공적으로 실행되고 소수만 중간, 대형으로 변경해야 하는 경우를 생각해 보겠습니다. 작업 부하의 60%가 "SMALL", 30%가 "MEDIUM", 그리고 10%가 "LARGE"에서 실행된다면 어떻게 되는지 살펴봅시다. 이는 실제 상황에 더 가깝습니다.

메트릭

시나리오 A(혼합 군집)

시나리오 B(장기 실행)

전략

포드 8,000개(혼합 크기)

포드 1개(8 vCPU/ 16GB)*

기간

각각 10분

12일 연속

총 비용

$52.66

$113.75

비용 절감

$61.09 (54% 더 저렴합니다)

—

동일한 출력을 얻을 때 현재 설정이 훨씬 더 비용 효율적이라는 것을 알 수 있습니다.

보안 강화

• 일시적인 GitHub 토큰(노출 시간이 일 단위가 아닌 분 단위)

• 역할 기반 액세스 제어(RBAC) 경계를 사용한 네임스페이스 격리

• 부모 워크플로우에서 저장 데이터 비밀 암호화

• 직접 볼트 액세스 제거

예측 가능한 성능

스캔 빈도가 보장되어 마침내 서비스 수준 목표(SLO)를 설정할 수 있습니다. Automerge는 안정적으로 작동합니다. 팀은 플랫폼이 약속대로 실행될 것이라고 신뢰합니다.

주요 설계 결정 사항

다음은 플랫폼의 모습을 형성하는 데 중요한 역할을 한 몇 가지 주요 설계 결정 사항입니다.

• 부모-자식 워크플로우를 사용하는 이유는 무엇인가요?

심층 방어 전략을 실행하기 위해 이 패턴을 채택했습니다. 중요한 자격 증명(예: GitHub 앱 비밀)을 잠긴 전용 네임스페이스로 제한함으로써 임시 실행 포드가 민감한 데이터에 임의로 액세스할 수 없도록 하기 위해 RBAC를 사용합니다. 최근의 공급망 취약성(예: "Shai Hulud" 지속적 통합/지속적 배포[CI/CD] 공격)은 자격 증명 저장소에서 동적 스크립트를 실행하는 런타임 환경을 격리하는 것이 얼마나 중요한지를 보여주었습니다.

동시에 이러한 분리를 통해 세분화된 리소스 최적화가 가능합니다. "부모" 워크플로우는 최소한의 풋프린트로 가벼운 오케스트레이터 역할을 하는 반면, "자식" 워크플로우는 컴퓨팅 집약적인 종속성 스캐닝을 처리합니다. 이러한 분리는 수명 주기 관리를 단순화하여 각 계층에 별개의 조정 로직을 적용할 수 있게 하므로, 사용자는 실행 매개 변수(자식)에 대한 제어권을 갖는 반면 관리자는 스케줄링 및 보안 인프라(부모)에 대한 관리 제어권을 유지할 수 있습니다.

• 셀프 서비스를 사용하는 이유는 무엇인가요?

팀이 리포지토리 구성의 병목 현상이 되지 않도록 하는 것은 중요한 요구 사항이었습니다. 다양한 사용 사례를 지원할 수 있는 확장 가능한 셀프 서비스 플랫폼을 구축하는 것이 목표였습니다. 우리는 엄청난 양의 리포지토리를 고려할 때, 모든 구성 변경에 대해 게이트키퍼 역할을 하는 것은 지속 불가능하다는 것을 인식했습니다. 대신, 사용자가 "열차"를 운전할 수 있도록(실행 및 맞춤화) "레일"(인프라 및 가드레일)을 제공한다는 지원 철학을 채택했습니다. 이와 같이 팀 자율성으로 전환하여 사용자가 시스템을 특정 운영 요구 사항에 맞게 조정할 수 있도록 하면 생산성이 크게 향상된다고 믿습니다.

• Kubernetes Operator 패턴을 사용하는 이유는 무엇인가요?

위에서 언급했듯이, 기본적인 설계 원칙은 플랫폼이 완전히 셀프 서비스 가능하도록 하는 것이었습니다. 사용자 의도(스캔 전환, 일정 주기 조정, 런타임 리소스 제한 조정 등)를 파악하고 변경 사항을 기본 워크플로우에 즉시 전파하려면 자동화된 메커니즘이 필요했습니다. 또한 향후 요구 사항을 예상하여 시스템은 쉽게 확장 가능해야 했습니다.

이를 위해 맞춤형 종속성 관리 Kubernetes Operator를 개발했습니다. CRD를 구성 인터페이스로 사용함으로써, Kubernetes 네이티브 조정 루프를 구축했습니다. 이 오퍼레이터는 사용자가 정의한 원하는 상태를 지속적으로 모니터링하고, 워크플로우 인프라에 필요한 업데이트를 자동으로 오케스트레이션합니다. 이를 통해 플랫폼 로직이 모든 복잡한 작업을 백그라운드에서 처리하므로 이벤트 기반의 원활한 작동이 보장됩니다.

• GitHub Events Gateway를 설계하는 이유는 무엇인가요?

플랫폼의 응답성을 위해 이벤트 기반 아키텍처 (EDA) 채택이 필수적이었습니다. CronWorkflows는 신뢰할 수 있는 기준 일정을 제공했지만, 사용자가 대시보드를 통해 수동으로 스캔을 트리거하는 등 임시 실행을 처리할 수 있는 민첩성이 필요했습니다. 이를 위해서는 페이로드 무결성을 검증하고 요청을 지능적으로 라우팅할 전용 수집 게이트웨이가 필요했습니다.

우리는 Argo용 기본 GitHub EventSource를 포함한 기존 솔루션을 평가했지만, 운영 오버헤드 및 엄격한 GitHub API 할당량(예: 리포지토리당 웹훅 제한)과 관련하여 상당한 위험이 있음을 확인했습니다. 결과적으로 이러한 제한으로부터 인프라를 분리하기 위해 맞춤형 게이트웨이를 구축했습니다.

무엇보다도, 이 게이트웨이는 마이그레이션 중에 전략적인 트래픽 제어 지점 역할을 했습니다. 이는 기존 시스템에서 새로운 인프라로 점진적이고 세분화된 배포(트래픽 전환)를 수행할 수 있도록 스위치 역할을 했습니다. 이를 통해 수천 개의 리포지토리를 온보딩하는 과정이 "빅뱅" 전환 방식이 아닌 통제되고 위험 없는 프로세스로 수행되었습니다.

얻은 교훈

우리가 얻은 몇 가지 교훈은 Elastic 소스 코드와 밀접한 관련이 있습니다.

1. 고객 우선: 플랫폼은 사용자를 위해 구축됩니다. 따라서 사용자의 요구를 최우선으로 고려하는 것이 중요합니다. 이를 통해 플랫폼을 효율적으로 설계된 인프라와 애플리케이션으로 형성하여 사용자와의 마찰을 줄이고, 플랫의 확장을 단순화하며 원활한 도입일 촉진할 수 있습니다.

2. 공간, 시간: 저항이 가장 적은 경로는 때때로 불안정한 상황으로 이어지곤 합니다. 처음에는 기존의 순차적 처리 모델을 최적화하려고 했지만, 이것으로 문제를 해결할 수 없었습니다. 오히려 더 많은 복잡성과 미해결 문제를 초래했습니다. 병렬 처리로 플랫폼을 재설계하기로 한 과감한 결정은 상당한 사전 노력을 필요로 했습니다. 하지만 결과적으로 플랫폼의 지속 가능한 성장을 위한 길을 열었고, 지루한 일상적인 관리 업무를 사실상 제거했습니다.

3. IT, 종속성: 플랫폼은 단독으로 운영될 수 없습니다. 플랫폼의 성공은 더 넓은 에코시스템과 얼마나 잘 통합되는지에 달려 있습니다. 이 사례에서는 Backstage와의 통합이 매우 중요했습니다. 원활한 서비스 온보딩을 위한 정보 소스 역할을 하기 때문입니다. 마찬가지로 Artifactory에 연결하여 개인 패키지 업데이트를 효율적으로 관리할 수 있게 되었습니다. 그 외에도 필수 통합 목록은 계속 이어집니다.

4. 발전, 단순한 완벽함: 구현 과정 전반에 걸쳐 초기 가정에 대해 지속적으로 엄격한 테스트를 수행하고 새로운 장벽이 나타나면 이에 맞게 조정했습니다. 완벽주의에 빠지기보다는 반복 접근 방식을 채택하여 과제를 하나씩 해결하고 실제 환경에 맞게 마이그레이션 전략을 조정했습니다.

그럼 이제 무엇을 해야 할까요?

플랫폼 제공은 더 의미 있는 작업을 가능하게 하여 플랫폼의 UX와 효율성을 향상시키는 데 도움이 됩니다. 몇 가지 예는 다음과 같습니다.

• 자동 병합 도입을 늘리고 가드레일 구축

자동 병합 기능은 지루한 수동 작업을 없애 팀의 작업 속도를 크게 향상시킵니다. 하지만 속도 향상으로 인해 보안이 훼손되지 않도록 엄격한 가드레일을 마련해야 합니다.

• 최종 사용자 경험에 대한 통합 가시성 향상

로드맵의 중요한 우선순위는 플랫폼 수준뿐만 아니라 특히 최종 사용자의 관점에서 통합 가시성을 강화하는 것입니다. 인프라 메트릭을 파악하는 것은 간단하지만, 실제 사용자 경험을 이해하려면 더 심층적인 인사이트가 필요합니다. 우리는 사용자 불만으로 이어지기 전에 원격 측정 데이터를 통해 문제점과 성능 문제를 탐지할 수 있도록 사용자 중심의 핵심 성과 지표(KPI)를 정의하고 있습니다.

• 장벽을 제거하여 도입 촉진

앞으로 최우선 과제는 플랫폼 도입을 방해하는 모든 장벽을 파악하고 제거하는 것입니다. 새로운 통합 기능을 개발하든 특정 기능 세트를 배포하든, 데이터 기반 계획 수립에 전념합니다. 확장성을 고려하여 설계된 플랫폼을 성공적으로 구축했으며, 이제 그 잠재력을 극대화하는 데 집중하고 있습니다.

더 큰 그림

종속성 관리 워크플로우 프로젝트는 더 광범위한 원칙을 제시합니다. 오픈 소스 도구를 기본 배포 모델 이상으로 확장해야 할 때 Kubernetes 네이티브 패턴이 해결책을 제시한다는 것입니다.

수용함으로써:

• 구성용 CRD

• 수명 주기 관리를 위한 오퍼레이터

• 응답성을 위한 이벤트 중심 아키텍처

• 배포용 GitOps

관리하는 리포지토리 수와 관계없이 확장 가능한 오케스트레이션을 구축했습니다. 하나의 리포지토리를 스캔하는 성능은 100개를 관리하든 1,000개를 관리하든 동일합니다.

중요한 CVE가 발표되면 이제 몇 시간이 아니라 몇 분 만에 답변을 받을 수 있습니다. 이것이 병목 현상과 경쟁 우위의 차이입니다.

감사의 말씀

이 플랫폼은 뛰어난 오픈 소스 도구를 기반으로 구축되었습니다.

• Kubebuilder: 워크플로우를 부트스트랩하고 오케스트레이션하는 Kubernetes Operator를 시작하는 데 사용한 오픈 소스 프레임워크입니다. [1][2]

• Backstage: 서비스 카탈로그를 구축하는 데 신뢰할 수 있는 정보 소스로 사용한 오픈 소스 프레임워크입니다. [1][2]

• Argo Workflows 및 Argo Events: 복잡한 프로세스를 오케스트레이션하고 이벤트에 기반한 동적 처리를 추가하는 데 사용한 오픈 소스 제품군입니다. [1][2][3][4]

• Renovate CLI: 리포지토리를 처리하는 오픈 소스 종속성 관리 도구입니다. [1][2]

* AWS Fargate 가격 모델이 단일 포드의 비용을 참조하는 데 사용되었지만, 워크로드가 반드시 AWS에서 실행되는 것은 아니며 완전한 Kubernetes 클러스터에서 실행되고 있습니다.

또한 이러한 사용 사례는 일반적으로 시간에 민감하며 일반적인 개발 단계(코드 브랜치를 생성한 다음 새 릴리스를 기다리는 과정)를 거치는 것은 시간이 많이 소요되는 프로세스입니다.

그렇다면 이 모든 프로세스를 API 호출만으로, 더 나아가 Kibana에서 클릭 몇 번으로 수행할 수 있다면 어떨까요?

쿼리 규칙 UI

Elasticsearch 8.10에는 쿼리 규칙과 규칙 검색기가 도입되었습니다. 규칙에 따라 자연 검색 결과의 순위에 영향을 주지 않고 고정된 결과를 쿼리에 삽입하기 위해 고안된 도구입니다. 선언적이고 단순한 방식으로 결과 위에 비즈니스 로직을 추가할 뿐입니다.

쿼리 규칙의 몇 가지 일반적인 사용 사례는 다음과 같습니다:

• 프로모션 목록 또는 판매 강조 표시: 세일 중이거나 스폰서된 품목을 상단에 표시합니다.

• 문맥 또는 지리적 위치에 따라 제외: 현지 규정으로 인해 특정 항목을 표시할 수 없는 경우 숨기기.

• 주요 결과의 우선순위 지정: 자연 검색 순위와 관계없이 인기 검색어 또는 고정 검색어가 항상 상단에 표시되도록 합니다.

인터페이스에 액세스하고 이러한 도구와 상호 작용하려면 Kibana 사이드 메뉴를 클릭하고 관련성아래의 쿼리 규칙으로 이동해야 합니다:

쿼리 규칙 메뉴가 나타나면 첫 번째 규칙 집합 만들기를 클릭합니다:

다음으로 규칙 집합의 이름을 지정해야 합니다.

각 규칙을 정의하는 양식에는 세 가지 주요 구성 요소가 있습니다:

• 기준: 조건: 규칙을 적용하기 위해 충족해야 하는 조건입니다. 예를 들어, "쿼리 문자열 필드에 크리스마스값이 포함된 경우" 또는 "국가 필드가 CO인경우"와 같은 예입니다.

• 액션: 조건이 충족될 때 수행하려는 작업입니다. 고정(문서를 최상위 결과에 고정)하거나 제외(문서를 숨김)할 수 있습니다.

• 메타데이터: 쿼리가 실행될 때 쿼리와 함께 제공되는 필드입니다. 여기에는 위치나 언어와 같은 사용자 정보뿐만 아니라 검색 데이터(쿼리 문자열)도 포함될 수 있습니다. 규칙 적용 여부를 결정하기 위해 기준에서 사용하는 값입니다.

예: 인기 품목

다양한 품목이 있는 이커머스 사이트가 있다고 가정해 보겠습니다. 지표를 살펴보면 콘솔 카테고리에서 가장 많이 판매된 상품 중 하나는 '듀얼쇼크 4 무선 컨트롤러'로, 특히 사용자가 'PS4' 또는 'PlayStation 4' 키워드를 검색할 때 가장 많이 판매되는 상품임을 확인할 수 있습니다. 따라서 사용자가 해당 키워드를 검색할 때마다 이 제품을 결과 상단에 표시하기로 결정했습니다.

먼저 대량 API 요청을 사용하여 각 항목에 대한 문서를 색인해 보겠습니다:

쿼리에 개입하지 않으면 해당 항목은 일반적으로 네 번째 위치에 표시됩니다. 쿼리는 다음과 같습니다:

결과는 다음과 같습니다.

이를 변경하는 쿼리 규칙을 만들어 보겠습니다. 먼저 다음과 같이 규칙 집합에 추가해 보겠습니다:

또는 이에 상응하는 API 요청:

쿼리에서 규칙 집합을 사용하려면 쿼리 규칙 유형을 사용해야 합니다. 이러한 종류의 쿼리는 크게 두 부분으로 구성됩니다:

• match_criteria: 사용자의 쿼리와 비교하는 데 사용되는 메타데이터입니다. 이 예에서는 쿼리 문자열 필드에 "PlayStation 4" 값이 있을 때 규칙 집합이 활성화됩니다.

• 쿼리: 검색 및 자연 검색 결과를 얻는 데 사용되는 실제 쿼리입니다.

이렇게 하면 먼저 오가닉 쿼리를 실행한 다음 Elasticsearch가 규칙 세트의 규칙을 적용합니다:

예: 사용자 기반 메타데이터

쿼리 규칙의 또 다른 흥미로운 적용 사례는 메타데이터를 사용하여 사용자 또는 웹페이지의 문맥 정보를 기반으로 특정 문서를 표시하는 것입니다.

예를 들어, 사용자의 충성도 수준에 따라 숫자 값으로 표시되는 아이템이나 맞춤형 판매를 강조하고 싶다고 가정해 보겠습니다.

이 메타데이터를 쿼리에 직접 수집하여 해당 값이 특정 기준을 충족할 때 규칙이 활성화되도록 할 수 있습니다.

먼저, 충성도 수준이 높은 사용자만 볼 수 있는 문서를 색인화합니다:

이제 동일한 규칙 집합 내에 새 규칙을 만들어 loyalty_level이 80 이상일 때 해당 항목이 결과 상단에 표시되도록 해 보겠습니다.

규칙과 규칙 집합을 저장합니다.

다음은 이에 상응하는 REST 요청입니다:

이제 쿼리를 실행할 때 메타데이터에 새 매개변수 loyalty_level을 포함시켜야 합니다. 규칙의 조건이 충족되면 새 문서가 결과 위에 표시됩니다.

예를 들어 충성도_레벨이 80인 쿼리를 전송하는 경우입니다:

결과 위에 로열티 문서가 표시됩니다:

아래의 경우 충성도 레벨이 70이므로 규칙이 충족되지 않으므로 해당 아이템이 상단에 표시되지 않아야 합니다:

결과는 다음과 같습니다:

예: 즉시 제외

듀얼쇼크 4 무선 컨트롤러(ID 2) 를 일시적으로 사용할 수 없어 판매할 수 없다고 가정해 보겠습니다. 따라서 비즈니스 팀은 문서를 수동으로 삭제하거나 일부 데이터 프로세스가 시작될 때까지 기다리는 대신 그 동안 검색 결과에서 해당 문서를 제거하기로 결정합니다.

방금 인기 있는 항목에 적용한 것과 비슷한 프로세스를 사용하되 이번에는 고정됨을 선택하는 대신 제외를 선택합니다. 이 규칙은 일종의 블랙리스트 역할을 합니다. 쿼리가 실행될 때마다 제외가 작동하도록 기준을 항상으로 변경합니다.

규칙은 다음과 같이 표시되어야 합니다:

규칙과 규칙 집합을 저장하여 변경 사항을 적용합니다. 다음은 이에 상응하는 REST 요청입니다:

이제 쿼리를 다시 실행하면 이전 규칙이 항목을 고정하는 것이었음에도 불구하고 해당 항목이 더 이상 결과에 없는 것을 볼 수 있습니다. 이는 제외가 고정 결과보다 우선하기 때문입니다.

결론

쿼리 규칙을 사용하면 코드를 변경하지 않고도 관련성을 매우 쉽게 조정할 수 있습니다. 새로운 Kibana UI를 사용하면몇 초 만에 이러한 변경을 수행할 수 있으므로, 여러분과 여러분의 비즈니스 팀이 검색 결과를 더 잘 제어할 수 있습니다.

쿼리 규칙은 전자상거래 외에도 지원 포털에서 문제 해결 가이드를 강조 표시하고, 지식창고에 주요 내부 문서를 표시하고, 뉴스 사이트에서 속보를 홍보하고, 만료된 작업 또는 콘텐츠 목록을 필터링하는 등 다양한 시나리오에 활용할 수 있습니다. 사용자 역할이나 지역에 따라 제한된 자료를 숨기는 등의 규정 준수 규칙을 적용할 수도 있습니다.

이 블로그에서는 Mastra를 사용해 사용자가 말한 내용을 기억하고 나중에 관련 정보를 불러올 수 있는 지식 에이전트를 구축하는 데 Elasticsearch를 메모리 및 검색 백엔드로 사용하겠습니다. 동일한 개념을 실제 사용 사례로 쉽게 확장하여 지원 상담원이 과거의 대화와 해결 방법을 기억할 수 있어 특정 사용자에게 맞춤형 응답을 제공하거나 이전 컨텍스트를 기반으로 더 빠르게 해결책을 제시할 수 있다고 생각하면 됩니다.

여기를 따라 단계별로 구축하는 방법을 알아보세요. 길을 잃었거나 완성된 예제를 실행하고 싶다면 여기에서 리포지토리를 확인하세요.

마스트라란 무엇인가요?

Mastra는 추론, 메모리 및 도구에 대한 교체 가능한 부품으로 AI 에이전트를 구축하기 위한 오픈 소스 TypeScript 프레임워크입니다. 시맨틱 리콜 기능을 통해 상담원은 메시지를 벡터 데이터베이스에 임베딩으로 저장하여 과거 상호작용을 기억하고 검색할 수 있습니다. 이를 통해 상담원은 장기적인 대화 맥락과 연속성을 유지할 수 있습니다. Elasticsearch는 효율적인 고밀도 벡터 검색을 지원하기 때문에 이 기능을 활성화하는 데 탁월한 벡터 저장소입니다. 시맨틱 리콜이 트리거되면 에이전트는 관련 과거 메시지를 모델의 컨텍스트 창으로 가져와서 모델이 검색된 컨텍스트를 추론 및 응답의 기초로 사용할 수 있도록 합니다.

시작하기 위해 필요한 사항

• 노드 v18+

• Elasticsearch(버전 8.15 이상)

• Elasticsearch API 키

• OpenAI API 키

참고: 데모에서는 OpenAI 공급자를 사용하므로 이 공급자가 필요하지만, Mastra는 다른 AI SDK 및 커뮤니티 모델 공급자를 지원하므로 설정에 따라 쉽게 교체할 수 있습니다.

Mastra 프로젝트 구축

Mastra에 내장된 CLI를 사용하여 프로젝트의 스캐폴딩을 제공하겠습니다. 명령을 실행합니다:

다음과 같은 일련의 프롬프트가 표시됩니다:

1. 프로젝트 이름을 지정합니다.

2. 이 기본값을 그대로 사용해도 되므로 비워두셔도 됩니다.

3. 이 프로젝트에서는 OpenAI에서 제공하는 모델을 사용합니다.

4. 모든 환경 변수를 이후 단계에서 구성할 '.env' 파일에 저장하므로 '지금은 건너뛰기' 옵션을 선택합니다.

5. 이 옵션을 건너뛸 수도 있습니다.

초기화가 완료되면 다음 단계로 넘어갈 수 있습니다.

종속성 설치

다음으로 몇 가지 종속성을 설치해야 합니다:

• ai - 자바스크립트/타입스크립트에서 AI 모델, 프롬프트 및 워크플로를 관리할 수 있는 도구를 제공하는 핵심 AI SDK 패키지입니다. Mastra는 Vercel의 AI SDK를 기반으로 구축되었으므로 에이전트와의 모델 상호 작용을 활성화하려면 이 종속성이 필요합니다.

• @ai-sdk/openai - AI SDK를 OpenAI 모델(예: GPT-4, GPT-4o 등)에 연결하여 OpenAI API 키를 사용하여 API 호출을 가능하게 하는 플러그인입니다.

• @elastic/elasticsearch - Node.js용 공식 Elasticsearch 클라이언트, 인덱싱, 검색, 벡터 작업을 위해 Elastic Cloud 또는 로컬 클러스터에 연결하는 데 사용됩니다.

• dotenv - .env에서 환경 변수를 로드합니다. 파일을 process.env에 추가합니다, API 키와 Elasticsearch 엔드포인트와 같은 자격 증명을 안전하게 삽입할 수 있습니다.

환경 변수 구성

프로젝트 루트 디렉터리에 .env 파일이 없는 경우 이 파일을 만듭니다. 또는 리포지토리에 제공한 예제 .env 를 복사하여 이름을 바꿀 수 있습니다. 이 파일에서 다음 변수를 추가할 수 있습니다:

이것으로 기본 설정이 끝났습니다. 여기에서 이미 상담원 구축 및 오케스트레이션을 시작할 수 있습니다. 여기서 한 걸음 더 나아가 저장 및 벡터 검색 레이어로 Elasticsearch를 추가하겠습니다.

벡터 저장소로 Elasticsearch 추가하기

stores 이라는 새 폴더를 만들고 그 안에 이 파일을 추가합니다. Mastra와 Elastic이 공식 Elasticsearch 벡터 저장소 통합을 출시하기 전에 Abhi Aiyer(Mastra CTO)가 초기 프로토타입 클래스( ElasticVector)를 공유했습니다. 간단히 말해, Mastra의 메모리 추상화와 Elasticsearch의 고밀도 벡터 기능을 연결하여 개발자가 에이전트를 위한 벡터 데이터베이스로 Elasticsearch를 도입할 수 있습니다.

통합의 중요한 부분을 자세히 살펴보겠습니다:

Elasticsearch 클라이언트 수집

이 섹션에서는 ElasticVector 클래스를 정의하고 표준 배포와 서버리스 배포를 모두 지원하는 Elasticsearch 클라이언트 연결을 설정합니다.

• ElasticVectorConfig extends ClientOptions: 이렇게 하면 모든 Elasticsearch 클라이언트 옵션(예: node, auth, requestTimeout)을 상속하고 사용자 정의 속성을 추가하는 새로운 구성 인터페이스가 생성됩니다. 즉, 사용자는 서버리스 전용 옵션과 함께 유효한 모든 Elasticsearch 구성을 전달할 수 있습니다.

• extends MastraVector: 이를 통해 ElasticVector 은 모든 벡터 스토어 통합이 준수하는 공통 인터페이스인 Mastra의 기본 MastraVector 클래스에서 상속할 수 있습니다. 이렇게 하면 Elasticsearch가 에이전트의 관점에서 다른 모든 Mastra 벡터 백엔드처럼 작동합니다.

• private client: Client: Elasticsearch JavaScript 클라이언트의 인스턴스를 보관하는 개인 속성입니다. 이렇게 하면 클래스가 클러스터와 직접 대화할 수 있습니다.

• isServerless 및 deploymentChecked: 이러한 속성은 함께 작동하여 서버리스 또는 표준 Elasticsearch 배포에 연결되어 있는지 여부를 감지하고 캐시합니다. 이 감지는 처음 사용할 때 자동으로 수행되거나 명시적으로 구성할 수 있습니다.

• constructor(config: ClientOptions): 이 생성자는 구성 객체(Elasticsearch 자격 증명 및 선택적 서버리스 설정이 포함된)를 가져와서 this.client = new Client(config) 줄에서 클라이언트를 초기화하는 데 사용합니다.

• super(): 이것은 Mastra의 기본 생성자를 호출하므로 로깅, 유효성 검사 헬퍼 및 기타 내부 훅을 상속합니다.

이 시점에서 Mastra는 다음과 같은 새로운 벡터 스토어가 있다는 것을 알고 있습니다. ElasticVector

배포 유형 감지

인덱스를 생성하기 전에 어댑터는 표준 Elasticsearch를 사용 중인지 아니면 Elasticsearch 서버리스를 사용 중인지 자동으로 감지합니다. 서버리스 배포에서는 수동 샤드 구성을 허용하지 않기 때문에 이 점이 중요합니다.

무슨 일이 일어나고 있나요?

• 먼저 구성에서 isServerless 을 명시적으로 설정했는지 확인합니다(자동 감지 건너뛰기).

• Elasticsearch의 info() API를 호출하여 클러스터 정보를 가져옵니다.

• build_flavor field (서버리스 배포는 serverless)를 확인합니다.

• 빌드 플레이버를 사용할 수 없는 경우 태그 라인 확인으로 돌아가기

• 반복되는 API 호출을 방지하기 위해 결과 캐시

• 탐지에 실패하면 표준 배포로 기본 설정됩니다.

사용 예시:

Elasticsearch에서 "메모리" 저장소 만들기

아래 함수는 임베딩을 저장하기 위한 Elasticsearch 인덱스를 설정합니다. 인덱스가 이미 존재하는지 확인합니다. 그렇지 않은 경우 임베딩 및 사용자 정의 유사성 메트릭을 저장할 dense_vector 필드가 포함된 아래 매핑을 사용하여 매핑을 생성합니다.

몇 가지 주의해야 할 사항:

• dimension 매개변수는 각 임베딩 벡터의 길이로, 사용 중인 임베딩 모델에 따라 달라집니다. 이 경우, 1536 크기의 벡터를 출력하는 OpenAI의 text-embedding-3-small 모델을 사용하여 임베딩을 생성하겠습니다. 이 값을 기본값으로 사용하겠습니다.

• 아래 매핑에 사용된 similarity 변수는 metric 매개변수의 값을 받아 선택한 거리 메트릭에 대해 Elasticsearch 호환 키워드로 변환하는 도우미 함수 const similarity = this.mapMetricToSimilarity(metric) 에서 정의됩니다.

  • 예를 들어: 예를 들어, Mastra는 cosine, euclidean, dotproduct 와 같은 벡터 유사성에 대한 일반적인 용어를 사용합니다. euclidean 메트릭을 Elasticsearch 매핑에 직접 전달하면, Elasticsearch는 l2_norm 키워드가 유클리드 거리를 나타낼 것으로 예상하기 때문에 오류가 발생합니다.

• 서버리스 호환성: 서버리스 배포를 위한 샤드 및 복제본 설정은 Elasticsearch 서버리스에서 자동으로 관리되므로 코드에서 자동으로 생략됩니다.

상호 작용 후 새 메모리 또는 노트 저장하기

이 함수는 각 상호 작용 후에 생성된 새 임베딩을 메타데이터와 함께 가져온 다음 Elastic의 bulk API를 사용하여 인덱스에 삽입하거나 업데이트합니다. bulk API는 여러 개의 쓰기 작업을 단일 요청으로 그룹화하여 인덱싱 성능을 개선함으로써 에이전트의 메모리가 계속 증가함에 따라 업데이트가 효율적으로 유지되도록 합니다.

시맨틱 리콜을 위해 유사한 벡터 쿼리하기

이 기능은 시맨틱 리콜 기능의 핵심입니다. 에이전트는 벡터 검색을 사용하여 인덱스 내에서 유사한 저장된 임베딩을 찾습니다.

내부를 들여다보세요:

• Elasticsearch에서 knn API를 사용하여 kNN (k-nearest neighbors) 쿼리를 실행합니다.

• 입력 쿼리 벡터와 유사한 상위 K개의 벡터를 검색합니다.

• 선택적으로 메타데이터 필터를 적용하여 결과 범위를 좁힐 수 있습니다(예: 특정 카테고리 또는 시간 범위 내에서만 검색).

• 문서 ID, 유사도 점수, 저장된 메타데이터를 포함한 구조화된 결과를 반환합니다.

지식창고 만들기

이제 ElasticVector 통합을 통해 Mastra와 Elasticsearch 간의 연결을 확인했으니, 지식 에이전트 자체를 생성해 보겠습니다.

agents 폴더 안에 knowledge-agent.ts 이라는 파일을 만듭니다. 환경 변수를 연결하고 Elasticsearch 클라이언트를 초기화하는 것으로 시작할 수 있습니다.

여기, 우리:

• dotenv 을 사용하여 .env 파일에서 변수를 로드합니다.

• Elasticsearch 자격 증명이 올바르게 주입되고 있는지 확인하면 클라이언트에 성공적으로 연결할 수 있습니다.

• ElasticVector 생성자에 Elasticsearch 엔드포인트와 API 키를 전달하여 앞서 정의한 벡터 저장소의 인스턴스를 생성합니다.

• 선택적으로 Elasticsearch 서버리스를 사용하는 경우 isServerless: true 을 지정합니다. 이렇게 하면 자동 감지 단계를 건너뛰고 시작 시간이 단축됩니다. 이 옵션을 생략하면 처음 사용할 때 어댑터가 자동으로 배포 유형을 감지합니다.

다음으로 Mastra의 Agent 클래스를 사용하여 에이전트를 정의할 수 있습니다.

정의할 수 있는 필드는 다음과 같습니다:

• name 및 instructions: 아이덴티티와 기본 기능을 부여합니다.

• model: @ai-sdk/openai 패키지를 통해 OpenAI의 gpt-4o 를 사용하고 있습니다.

• memory:

  • vector: Elasticsearch 저장소를 가리키므로 임베딩이 저장되고 거기에서 검색됩니다.

  • embedder: 임베딩 생성에 사용할 모델

  • semanticRecall 옵션은 리콜 작동 방식을 결정합니다:

    • topK: 검색할 의미적으로 유사한 메시지 수입니다.

    • messageRange: 각 경기에 포함할 대화 분량입니다.

    • scope: 메모리 경계를 정의합니다.

거의 다 끝났습니다. 새로 생성된 에이전트를 Mastra 구성에 추가하기만 하면 됩니다. index.ts 라는 파일에서 지식 에이전트를 가져와서 agents 필드에 삽입합니다.

다른 필드에는 다음이 포함됩니다:

• storage: 실행 기록, 통합 가시성 메트릭, 점수 및 캐시를 위한 Mastra의 내부 데이터 저장소입니다. Mastra 스토리지에 대한 자세한 내용은 여기를 참조하세요.

• logger: Mastra는 경량 구조화된 JSON 로거인 Pino를 사용합니다. 상담원 시작 및 중지, 도구 호출 및 결과, 오류, LLM 응답 시간 등의 이벤트를 캡처합니다.

• observability: 상담원의 AI 추적 및 실행 가시성을 제어합니다. 추적합니다:

  • 각 추론 단계의 시작/종료

  • 어떤 모델 또는 도구를 사용했는지.

  • 입력 및 출력.

  • 점수 및 평가

Mastra Studio로 에이전트 테스트

축하합니다! 여기까지 왔다면 이 에이전트를 실행하여 시맨틱 리콜 기능을 테스트할 준비가 된 것입니다. 다행히도 Mastra는 기본 제공 채팅 UI를 제공하므로 자체적으로 구축할 필요가 없습니다.

Mastra 개발 서버를 시작하려면 터미널을 열고 다음 명령을 실행합니다:

서버를 처음 번들링하고 시작하면 플레이그라운드의 주소가 제공됩니다.

이 주소를 브라우저에 붙여넣으면 마스트라 스튜디오로 이동합니다.

knowledgeAgent 옵션을 선택하고 채팅을 시작합니다.

모든 것이 올바르게 연결되었는지 간단히 테스트하려면 "팀은 10월의 판매 실적이 12% 증가했다고 발표했습니다%, 주로 기업 리뉴얼에 힘입은 것입니다."와 같은 정보를 입력합니다. 다음 단계는 미드 마켓 고객으로 범위를 넓히는 것입니다." 다음으로 새 채팅을 시작하고 "다음에 어떤 고객 세그먼트에 집중해야 한다고 했나요?"와 같은 질문을 하세요. 지식 상담원은 첫 번째 채팅에서 제공한 정보를 기억할 수 있어야 합니다. 다음과 같은 응답이 표시되어야 합니다:

이와 같은 응답을 보면 에이전트가 이전 메시지를 Elasticsearch에 임베딩으로 성공적으로 저장하고 나중에 벡터 검색을 사용하여 검색했다는 뜻입니다.

상담원의 장기 기억 저장소 검사하기

Mastra Studio의 상담원 구성에서 memory 탭으로 이동합니다. 이를 통해 상담원이 시간이 지남에 따라 학습한 내용을 확인할 수 있습니다. Elasticsearch에 포함되고 저장되는 모든 메시지, 응답, 상호 작용은 이 장기 기억의 일부가 됩니다. 과거 상호작용을 의미론적으로 검색하여 상담원이 이전에 학습한 정보나 컨텍스트를 빠르게 찾을 수 있습니다. 이는 기본적으로 에이전트가 시맨틱 리콜 중에 사용하는 것과 동일한 메커니즘이지만, 여기서 직접 검사할 수 있습니다. 아래 예시에서는 '판매'라는 용어를 검색하여 판매에 관한 내용이 포함된 모든 상호작용을 반환하고 있습니다.

결론

Mastra와 Elasticsearch를 연결하면 컨텍스트 엔지니어링의 핵심 계층인 메모리를 에이전트에게 제공할 수 있습니다. 시맨틱 리콜을 통해 상담원은 시간이 지남에 따라 컨텍스트를 구축하여 학습한 내용을 기반으로 응답할 수 있습니다. 이는 보다 정확하고 안정적이며 자연스러운 상호작용을 의미합니다.

이 초기 통합은 시작에 불과합니다. 여기서 동일한 패턴으로 과거 티켓을 기억하는 지원 상담원, 관련 문서를 검색하는 내부 봇, 대화 중에 고객 세부 정보를 기억할 수 있는 AI 어시스턴트 등을 만들 수 있습니다. 또한, 가까운 시일 내에 이 페어링이 더욱 원활하게 이루어질 수 있도록 공식적인 Mastra 통합을 위해 노력하고 있습니다.

여러분이 다음에 무엇을 만들지 기대가 됩니다. 한 번 사용해보시고 Mastra와 그 메모리 기능을 살펴보고 발견한 내용을 커뮤니티와 자유롭게 공유하세요.