OpenSearch 3.8: Base64 벡터 수집·Radial Search 재설계·MCP Flow Agent로 k-NN 운영 비용을 줄이는 방법

왜 이번 릴리스를 봐야 하나

2026년 8월 5일 공개된 OpenSearch 3.8.0은 세 가지 독립된 개선을 하나의 릴리스에 묶었다. 각각은 별개의 운영 문제를 해결한다.

1. Base64 벡터 수집: knn_vector 필드에 JSON 배열 대신 Base64 인코딩 문자열로 벡터를 전달하면, 네트워크 페이로드가 74% 줄고 대량 수집 처리량이 4.16배 높아진다. 기존 인덱스를 재구축할 필요 없이 수집 클라이언트 코드만 바꾸면 된다.

1. Radial Search 그래프 탐색 재설계: "거리 임계값 d 이내의 모든 벡터 찾기"를 HNSW 그래프에서 수행하는 경로가 새로 작성됐다. 처리량 2.1배, 중간값 지연 45% 감소, 평균 재현율 0.85 → 0.97 향상.

1. MCP Flow Agent 지원: Flow Agent와 Conversational Flow Agent 두 아키텍처가 MCP 호환 도구 서버와 연결할 수 있게 됐다. 모든 에이전트 아키텍처가 동일한 커넥터 설정을 공유한다.

이 외에 Amazon Linux 2 지원 종료 사전 안내가 포함됐다. AL2는 2026년 6월 30일 공식 EOL에 도달했으며, OpenSearch는 향후 버전에서 AL2 빌드를 제거할 예정이다.

배경: 벡터 수집이 왜 병목이 되었나

JSON 배열 직렬화 오버헤드

float32 벡터를 JSON으로 표현하면 각 원소는 최소 10바이트 이상이 된다. 1536차원 임베딩(OpenAI text-embedding-3-small 기본 크기)을 예로 들면:

# JSON 배열 형식 (기존)
"embedding": [0.01234567, -0.09876543, 0.15432765, ...]
# 1536개 × 평균 12바이트 ≈ 18,432 바이트

# Base64 형식 (신규)
"embedding_b64": "AAAAAP......" 
# 1536 × 4바이트 × (4/3) ≈ 8,192 바이트

숫자 텍스트 표현이 4바이트 이진 float를 6~10배 부풀린다. 문서당 10~20KB 페이로드 차이가 초당 수천 건 벌크 수집 환경에서 네트워크 포화와 가비지 컬렉션 압력으로 이어진다.

Radial Search의 기존 구현 한계

HNSW(Hierarchical Navigable Small World) 알고리즘은 본래 top-k 근사 최근접 이웃(ANN) 탐색을 위해 설계됐다. "k개를 찾으면 멈춘다"는 단순한 종료 조건이 있다.

Radial Search — "거리 임계값 d 이내의 모든 벡터를 찾아라" — 는 종료 조건이 다르다. 몇 개가 나올지 모른다. 기존 HNSW 구현은 이 차이를 k를 크게 설정하거나 재스캔으로 임시방편으로 처리했다. 탐색 경계가 비효율적으로 넓어져 불필요한 계산이 발생했다.

기법 1: Base64 벡터 수집

동작 방식

OpenSearch 3.8은 knn_vector 필드 타입에서 두 가지 입력 형식을 모두 수락한다.

// 기존: JSON 배열 (계속 지원됨)
{
  "embedding": [0.01234, -0.09876, 0.15432, ...]
}

// 신규: Base64 인코딩 문자열
{
  "embedding_b64": "AABEQ..."
}

인코딩 규칙은 단순하다: 각 float32 값을 리틀엔디안 4바이트로 변환한 후 표준 Base64로 인코딩한다. Python 클라이언트 예시:

import numpy as np
import base64

def encode_vector(vec: list[float]) -> str:
    return base64.b64encode(
        np.array(vec, dtype=np.float32).tobytes()
    ).decode("utf-8")

서버 쪽에서는 KNNVectorFieldMapper가 Base64 입력을 감지하면 자동으로 디코딩한다. 이미 운영 중인 인덱스의 매핑을 바꿀 필요 없고, 기존 JSON 배열 방식도 계속 동작한다.

수집 성능 변화

처리량 향상이 페이로드 감소(74%)보다 훨씬 크다(416%). 이유는 JSON 파싱 비용이 제거되기 때문이다. JSON 배열을 파싱해 float[]로 변환하는 작업은 CPU 집약적이며, 고처리량 수집 환경에서 JVM 힙 압력을 높인다. Base64는 단순한 디코딩만 필요하다.

기법 2: Radial Search 그래프 탐색 재설계

Radial Search란

ANN 벡터 검색에는 두 가지 기본 쿼리 형태가 있다.

• Top-k ANN: "가장 유사한 k개 벡터를 찾아라" — 항상 정확히 k개를 반환
• Radial Search: "거리 임계값 d 이내의 모든 벡터를 찾아라" — 반환 개수를 미리 알 수 없음

Radial Search는 다음 시나리오에서 중요하다.

기존 구현의 문제

HNSW는 top-k 탐색에 최적화됐다. 탐색 경계는 "k개를 찾으면 종료"로 단순하다. Radial Search를 HNSW에서 구현하려면 탐색 경계가 달라야 한다: "현재 발견된 후보 중 가장 가까운 것의 거리가 이미 d보다 크면 해당 방향 탐색 중단."

3.8 이전의 구현은 이 경계를 정확하게 관리하지 않아 불필요한 그래프 노드를 방문했다. 결과적으로:

• 실제 결과보다 훨씬 넓은 탐색 범위
• 높은 재현율을 내려면 느린 탐색

재설계 후

3.8의 재설계는 radial 쿼리를 위한 거리 기반 탐색 경계를 HNSW 그래프 레이어별로 정확하게 계산한다. 각 레이어 탐색 시 임계값 d를 초과하는 방향의 그래프 탐색을 조기에 종료한다. 이로써:

재현율이 오히려 오른 이유: 기존 구현이 경계를 잘못 관리해 실제로 d 이내인 벡터를 놓치는 경우가 있었다. 새 구현은 더 빠르면서도 더 정확하다.

기법 3: MCP Flow Agent 지원 확장

OpenSearch의 네 가지 에이전트 아키텍처

OpenSearch ML Commons는 여러 에이전트 실행 모드를 지원한다. 3.8에서 추가된 두 아키텍처는 다음과 같다.

Flow Agent는 에이전트 파이프라인을 정적으로 정의할 때 유용하다: "검색 → 요약 → 포맷" 같은 고정된 흐름. Conversational Flow Agent는 여기에 멀티턴 대화 이력을 더해 맥락을 이어나갈 수 있다.

3.8에서 추가된 MCP 기능

도구 서버 연결 이외에도 두 가지 운영 편의 기능이 추가됐다.

1. 도구 목록 조회 API: MCP 서버에 등록된 모든 도구를 프로그래밍 방식으로 조회할 수 있는 REST API(/_plugins/_ml/mcp/list-tools). 에이전트 설정 자동화에 유용하다.

1. 커넥터 레벨 도구 설명 재정의: MCP 서버의 기본 도구 설명을 외부 서버 코드를 변경하지 않고 OpenSearch 커넥터 설정에서 재정의할 수 있다. 모델에게 노출되는 도구 설명을 상황에 맞게 조정하는 데 쓴다.

1. gRPC-over-HTTP/2 전환: ML 예측 스트리밍 경로가 기존 REST 스트리밍에서 gRPC over HTTP/2로 전환됐다. 연결 유지 비용과 CPU 오버헤드가 낮아진다.

운영 체크리스트: 3.8 업그레이드 전 확인 사항

1. Base64 수집 마이그레이션

선택 사항이며 점진적으로 전환 가능하다. 기존 JSON 배열 형식은 계속 지원된다.

# 마이그레이션 전: JSON 배열 그대로 사용
doc = {"embedding": [0.012, -0.098, ...]}

# 마이그레이션 후: Base64로 전환
import numpy as np, base64

def to_base64_vec(v):
    return base64.b64encode(np.array(v, dtype=np.float32).tobytes()).decode()

doc = {"embedding": to_base64_vec([0.012, -0.098, ...])}

권장 전환 순서:

1. 새 수집 클라이언트 코드를 스테이징에 배포하고 수집 처리량 측정
2. 기존 데이터는 재인덱싱 없이 그대로 두고, 신규 문서부터 Base64 사용
3. 운영 전환 후 클라이언트 코드 완전 교체

2. Radial Search 사용 중인 경우

Radial Search를 이미 쓰고 있다면 3.8 업그레이드 후 벤치마크를 다시 측정해야 한다. 재현율이 오르고 처리량이 늘었으므로 k-NN 파라미터(ef_search 등)를 조정할 수 있는 여지가 생긴다.

GET /my-index/_search
{
  "query": {
    "knn": {
      "embedding": {
        "vector": [...],
        "min_score": 0.8   ← Radial Search: 0.8 이상 유사도 모두 반환
      }
    }
  }
}

3. Amazon Linux 2 마이그레이션 계획 수립

3.8은 AL2 지원 종료를 예고한 릴리스다. 실제 제거는 향후 버전에서 이루어진다. AL2에서 실행 중인 운영 클러스터가 있다면:

• AL2는 2026년 6월 30일 공식 EOL
• OpenSearch는 다음 메이저 또는 마이너 릴리스에서 AL2 빌드를 중단 예정
• 마이그레이션 대상: Amazon Linux 2023, Ubuntu 22.04/24.04, RHEL 8/9

# 현재 OS 확인
cat /etc/os-release

# AL2라면 지금 마이그레이션 계획 수립 필요
# Amazon Linux 2023으로 전환 권장

전체 변경 사항 요약

요점 정리

OpenSearch 3.8의 세 가지 변화는 별개의 문제를 해결하지만 공통된 방향을 가리킨다: 벡터 워크로드의 운영 비용을 줄이는 것.

Base64 수집은 인덱싱 파이프라인의 CPU와 네트워크 비용을 즉시 줄인다. 코드 한 줄을 바꾸는 것으로 4배 이상의 처리량을 얻는 드문 기회다. Radial Search 재설계는 거리 기반 쿼리 패턴에서 처리량과 재현율을 동시에 높인다. MCP 에이전트 확장은 에이전트 파이프라인을 OpenSearch 위에 구축할 때 일관된 커넥터 설정을 가능하게 한다.

세 변화 모두 기존 데이터의 재인덱싱 없이 업그레이드만으로 활용할 수 있다는 점이 실용적이다.

References

• OpenSearch 3.8.0 공식 릴리스 노트: https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-3.8.0.md
• OpenSearch k-NN 플러그인 변경 이력: https://github.com/opensearch-project/k-NN/blob/main/CHANGELOG.md
• Base64 벡터 수집 PR #3350: https://github.com/opensearch-project/k-NN/pull/3350
• MCP Flow Agent PR #4776: https://github.com/opensearch-project/ml-commons/pull/4776
• HNSW Radial Search 벤치마크 (k-NN #3322): https://github.com/opensearch-project/k-NN/issues/3322
• Amazon Linux 2 EOL 공지: https://aws.amazon.com/amazon-linux-2/faqs/
• OpenSearch 공식 블로그: https://opensearch.org/blog/