다차원 검색을 수행하는 데이터베이스 (2) Rust gRPC 엔진

설정 파일

우선 Rust 프로젝트를 생성한다.

~/workspace/community-board-log$ cargo new rust-engine
~/workspace/community-board-log$ tree
.
├── compose.yaml
├── proto
│   └── emotion_search.proto
├── rust-engine
│   ├── Cargo.toml
│   └── src
│       └── main.rs
└── scripts
    └── database
        ├── 01_init_extensions.sql
        └── 02_create_tables.sql

6 directories, 6 files

Cargo.toml

의존성 파일을 작성한다.

rust-engine/Cargo.toml

[package]
name = "rust-engine"
version = "0.1.0"
edition = "2024"
default-run = "rust-engine"

[dependencies]
# 비동기 런타임
tokio = { version = "1.52", features = ["full"] }

# gRPC (Tonic 0.14+)
tonic = "0.14"
prost = "0.14"
tonic-prost = "0.14"

# Database
sqlx = { version = "0.8", features = ["postgres", "uuid", "runtime-tokio-rustls"] }

# pgvector의 Rust 타입 지원 (DB의 vector 타입을 Rust 구조체로 자동 매핑)
pgvector = { version = "0.4", features = ["sqlx"] }

# 유틸리티 및 직렬화
uuid = { version = "1.23", features = ["v7"] }
serde = { version = "1.0", features = ["derive"] }
dotenvy = "0.15"

# 구조화된 로깅 (Tracing)
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }

[build-dependencies]
# gRPC proto 파일 컴파일러
tonic-prost-build = "0.14"

build.rs

proto/emotion_search.proto 파일에 정의한 gRPC 서비스 명세를
Rust 코드로 자동 변환하는 코드를 작성한다.

rust-engine/build.rs

use std::env;
use std::path::PathBuf;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let proto_file = "../proto/emotion_search.proto";

    println!("cargo:rerun-if-changed={}", proto_file);

    let out_dir = PathBuf::from(env::var("OUT_DIR").unwrap());

    tonic_prost_build::configure()
        // 실무적 요구사항: Serde 역/직렬화 매크로를 자동 생성된 코드에 주입
        .type_attribute(".", "#[derive(serde::Serialize, serde::Deserialize)]")
        .file_descriptor_set_path(out_dir.join("emotion_descriptor.bin"))
        .compile_protos(&[proto_file], &["../proto"])?;

    Ok(())
}

환경변수 OUT_DIR 는 Rust의 빌드 시스템인 Cargo가
컴파일 과정에서 임시로 주입하는 내부 환경 변수이므로
임의로 생성할 필요 없다.

🤖 AI AGENT | tonic build

Tonic이 0.14 버전으로 넘어오면서 코드 생성 아키텍처에 큰 구조적 변화가 있었습니다.

1. 컴파일 방식의 차이점

과거에는 tonic-build 하나가 Protobuf 파싱(Prost)과 gRPC 코드 생성(Tonic)을 모두 담당했습니다. 하지만 Tonic이 특정 직렬화 포맷(Protobuf)에 종속되지 않고 범용적인 gRPC 코드 생성기로 발전하면서, Prost(Protobuf) 기반의 컴파일 기능을 tonic-prost-build라는 별도의 크레이트로 분리했습니다.

① tonic_build::configure()

• 상태: Deprecated (Protobuf 사용 시)
• 설명: 기존에 사용되던 방식입니다. 현재 버전에서는 Protobuf 컴파일을 위해 이 모듈을 직접 호출하면 use of deprecated method 경고가 발생합니다. 이제 tonic-build는 내부적인 범용 코드 생성 인프라로만 남고, 실제 유저가 사용하는 접점은 아닙니다.

② tonic_prost_build::compile_protos("경로")

• 상태: 사용 가능 (단순 컴파일용)
• 설명: 가장 간편한 방식입니다. 별도의 설정 없이 지정한 .proto 파일을 읽어 기본값으로 Rust 코드를 생성합니다. 옵션이 전혀 필요 없는 소규모 프로젝트나 튜토리얼에서 유용합니다.

③ tonic_prost_build::configure().compile_protos()

• 상태: 사용 권장 (실무 및 커스텀 설정용)
• 설명: 빌더(Builder) 패턴을 사용하여 코드 생성 옵션을 미세 조정할 수 있습니다. 예를 들어, 생성된 구조체에 #[derive(Serialize, Deserialize)] 같은 속성을 주입하거나, out_dir을 변경하거나, gRPC Server 코드는 빼고 Client 코드만 생성하게 제어할 수 있습니다.

---

2. 최적의 선택 및 적용

우리는 생성된 gRPC 메시지(구조체)를 단순 통신뿐만 아니라 로깅이나 향후 JSON 변환에 활용하기 위해 Serde 속성을 주입(type_attribute)해야 합니다. 따라서 ③ `tonic_prost_build::configure().compile_protos()` 방식을 사용하는 것이 가장 올바른 선택입니다.

그동안 2번 방식도 해보고 3번 방식도 해보았는데 앞으로는 3번 방식으로 이어 나가면 될 것 같다.

코드 작성

pb.rs

자동 생성된 코드를 메인 로직에 직접 우겨넣기보다는
별도의 모듈로 깔끔하게 분리하는 것이 낫다.

rust-engine/src/pb.rs

pub mod emotion {
    include!(concat!(env!("OUT_DIR"), "/emotion.rs"));
}

service.rs

DB 커넥션 풀을 활용하여 검색을 처리하는 핵심 서비스 모듈을 작성한다.

rust-engine/src/service.rs

use pgvector::Vector;
use sqlx::PgPool;
use tonic::{Request, Response, Status};

use crate::pb::emotion::emotion_search_service_server::EmotionSearchService;
use crate::pb::emotion::{
    Emotion,
    SearchResponse,
    TaxonomySearchRequest,
    TextSearchRequest,
    VectorSearchRequest
};

/// gRPC 서비스를 구현할 구조체
pub struct MyEmotionSearchService {
    pool: PgPool,
}

impl MyEmotionSearchService {
    pub fn new(pool: PgPool) -> Self {
        Self { pool }
    }
}

#[tonic::async_trait]
impl EmotionSearchService for MyEmotionSearchService {
    /// 다차원 벡터 (VA) 기반 유사도 검색 (K-NN)
    async fn search_by_vector(
        &self,
        request: Request<VectorSearchRequest>,
    ) -> Result<Response<SearchResponse>, Status> {
        let req = request.into_inner();
        let target = req.target_vector;

        if target.len() != 2 {
            return Err(Status::invalid_argument("VA 벡터는 반드시 2차원이어야 합니다."));
        }

        // pgvector의 Vector 타입으로 변환
        let query_vector = Vector::from(target.clone());
        // DB 부하 방지를 위한 건수 제한
        let limit = req.limit.clamp(1, 500) as i64;

        tracing::info!("벡터 검색 요청: VA = {:?}, Limit = {}", target, limit);

        let records = sqlx::query!(
            r#"
            SELECT id, word, definition, taxonomy_path::text as taxonomy_path, va_vector::text as va_vector
            FROM emotions
            ORDER BY va_vector <=> $1
            LIMIT $2
            "#,
            query_vector as Vector,
            limit,
        )
        .fetch_all(&self.pool)
        .await
        .map_err(|e| {
            tracing::error!("벡터 검색 쿼리 실패: {:?}", e);
            Status::internal("DB 검색 중 오류가 발생했습니다.")
        })?;

        // DB 쿼리 결과를 Protobuf 모델로 변환
        let emotions = records.into_iter().map(|rec| Emotion {
            id: rec.id.to_string(),
            word: rec.word,
            definition: rec.definition,
            taxonomy_path: rec.taxonomy_path.unwrap_or_default(),
            va_vector: parse_vector_string(&rec.va_vector.unwrap_or_default()),
        }).collect();

        Ok(Response::new(SearchResponse {
            emotions
        }))
    }

    /// 계층(Taxonomy) 구조 기반 검색
    async fn search_by_taxonomy(
        &self,
        request: Request<TaxonomySearchRequest>,
    ) -> Result<Response<SearchResponse>, Status> {
        let req = request.into_inner();

        // DB 부하 방지를 위한 건수 제한
        let limit = req.limit.clamp(1, 500) as i64;

        tracing::info!("Taxonomy 검색 요청: Path = {:?}, Limit = {}", req.path_query, limit);

        let records = sqlx::query!(
            r#"
            SELECT id, word, definition, taxonomy_path::text as taxonomy_path, va_vector::text as va_vector
            FROM emotions
            WHERE taxonomy_path ~ CAST($1::text AS lquery)
            LIMIT $2
            "#,
            req.path_query,
            limit,
        )
        .fetch_all(&self.pool)
        .await
        .map_err(|e| {
            tracing::error!("Taxonomy 검색 실패: {:?}", e);
            Status::internal("분류 검색 중 오류가 발생했습니다.")
        })?;

        // DB 쿼리 결과를 Protobuf 모델로 변환
        let emotions = records.into_iter().map(|rec| Emotion {
            id: rec.id.to_string(),
            word: rec.word,
            definition: rec.definition,
            taxonomy_path: rec.taxonomy_path.unwrap_or_default(),
            va_vector: parse_vector_string(&rec.va_vector.unwrap_or_default()),
        }).collect();

        Ok(Response::new(SearchResponse {
            emotions
        }))
    }

    /// Full-Text Search (텍스트 기반 검색)
    async fn search_by_text(
        &self,
        request: Request<TextSearchRequest>,
    ) -> Result<Response<SearchResponse>, Status> {
        let req = request.into_inner();

        // DB 부하 방지를 위한 건수 제한
        let limit = req.limit.clamp(1, 500) as i64;

        tracing::info!("텍스트 검색 요청: Query = {:?}, Limit = {}", req.query, limit);

        let records = sqlx::query!(
            r#"
            SELECT id, word, definition, taxonomy_path::text as taxonomy_path, va_vector::text as va_vector
            FROM emotions
            WHERE search_vector @@ plainto_tsquery('simple', $1)
            LIMIT $2
            "#,
            req.query,
            limit,
        )
        .fetch_all(&self.pool)
        .await
        .map_err(|e| {
            tracing::error!("텍스트 검색 실패: {:?}", e);
            Status::internal("분류 검색 중 오류가 발생했습니다.")
        })?;

        // DB 쿼리 결과를 Protobuf 모델로 변환
        let emotions = records.into_iter().map(|rec| Emotion {
            id: rec.id.to_string(),
            word: rec.word,
            definition: rec.definition,
            taxonomy_path: rec.taxonomy_path.unwrap_or_default(),
            va_vector: parse_vector_string(&rec.va_vector.unwrap_or_default()),
        }).collect();

        Ok(Response::new(SearchResponse {
            emotions
        }))

    }
}

/// DB에서 반환된 문자열 형태의 배열을 파싱하는 유틸리티 함수
fn parse_vector_string(vec_str: &str) -> Vec<f32> {
    let clean_str = vec_str.trim_matches(|c| c == '[' || c == ']');
    clean_str.split(',')
        .filter_map(|s| s.trim().parse::<f32>().ok())
        .collect()
}

🤖 AI AGENT | PostgreSQL의 고급 기능들

1. HNSW 인덱스와 코사인 거리 연산자 (<=>)

다차원 벡터 공간에서 두 벡터(감정)가 얼마나 유사한지 찾기 위해 사용하는 기술입니다.

• 동작 원리:
  pgvector 확장에서는 <=> 연산자를 제공하여 두 벡터 간의 코사인 거리(Cosine Distance)를 계산합니다. 공식은 다음과 같습니다.

$\text{Cosine Distance} = 1 - \cos(\theta)$

거리가 짧을수록(0에 가까울수록) 두 감정 벡터가 유사하다는 것을 의미합니다. ORDER BY vad_vector <=> $1 구문은 질의 벡터와의 거리를 계산하여 가장 가까운 순서대로 정렬(K-NN, K-Nearest Neighbors)합니다.

• HNSW (Hierarchical Navigable Small World) 인덱스 활용:
  과거에는 모든 데이터와 거리를 일일이 계산하는 Exact Search(순차 탐색, $O(N)$)나, 공간을 쪼개는 IVFFlat 알고리즘을 썼습니다. 하지만 최신 pgvector가 지원하는 HNSW는 데이터를 다층적인 그래프 구조로 만듭니다. 최상위 층은 성긴(Sparse) 노드들로 이루어져 넓은 공간을 빠르게 건너뛰고, 하위 층으로 갈수록 촘촘한(Dense) 이웃을 탐색합니다.
• 설계 근거:
  이 연산자와 HNSW 인덱스가 결합하면 $O(\log N)$의 시간 복잡도로 수백만 건의 벡터 중 가장 유사한 감정을 1밀리초(ms) 내외로 찾아냅니다. 감정 단어 간의 미묘한 차이(각성가와 정서가의 방향성)를 검색하는 데 있어 코사인 거리가 유클리디안 거리(<->)보다 각도(패턴)의 유사성을 더 잘 반영하므로 <=>를 채택했습니다. (출처: pgvector 공식 문서 - Indexing)

2. ltree 계층 매칭 연산자 (<@, ~)와 lquery 문법

감정의 계층 구조(Taxonomy)를 효율적으로 탐색하기 위한 트리 전용 연산자입니다.

• <@ (Is descendant of):
  'positive.joy.ecstasy' <@ 'positive' 와 같이 사용되며, 좌측 노드가 우측 노드의 하위(자손)인지 확인합니다. 직관적이고 빠르지만, 특정 깊이나 복잡한 패턴을 묘사할 수는 없습니다.
• ~ (lquery 매칭) 연산자:
  정규 표현식(Regex)과 유사하지만 계층형 라벨에 최적화된 문법을 제공합니다. 예를 들어 path ~ '*.high_arousal.*' 이라고 질의하면, 최상위 분류가 무엇이든 경로 중간에 high_arousal이 포함된 모든 감정을 검색합니다.
• 설계 근거:
  실무에서 카테고리 검색은 단순히 "특정 부모의 자식"을 찾는 것을 넘어, "분류 깊이가 정확히 2단계인 노드(positive.*{1})만 줘"와 같은 요구사항으로 발전합니다. lquery(~)는 이러한 유연성을 제공하면서도 GiST (Generalized Search Tree) 인덱스를 완벽하게 타기 때문에, 풀 스캔 없이 해당 분기(Branch)만 쏙 뽑아오는 고성능 검색이 가능합니다. (출처: PostgreSQL 공식 문서 - ltree)

3. Full-Text Search 연산자 (@@)와 tsvector / plainto_tsquery

단순 문자열 매칭(LIKE '%기쁨%')의 성능 및 정확도 한계를 극복하기 위한 형태소/어휘 기반 검색입니다.

• tsvector (Text Search Vector):
  텍스트를 파싱하고 정규화하여 중복을 제거한 어휘소(Lexeme)들의 정렬된 배열입니다. (예: "슬픔과 기쁨이 교차한다" -> '교차':3, '기쁨':2, '슬픔':1).
• plainto_tsquery:
  사용자가 입력한 일반 텍스트 검색어(예: "기쁘고 행복한")를 데이터베이스가 이해할 수 있는 엄격한 논리 검색어(예: '기쁘' & '행복')로 안전하게 변환해 주는 내장 함수입니다.
• @@ (Match) 연산자:
  tsvector 데이터 안에 tsquery 조건이 만족하는지(true / false) 검사합니다.
• 설계 근거:
  @@ 연산자는 우리가 search_vector 컬럼에 생성해 둔 GIN (Generalized Inverted Index) 인덱스를 활용합니다. 이는 책 맨 뒤의 '찾아보기(색인)'와 같은 원리입니다. 단어가 포함된 row ID를 역으로 매핑해 두었기 때문에, 전체 텍스트를 읽지 않고도 단어 존재 여부를 즉시 판단할 수 있어 성능이 압도적입니다. (출처: PostgreSQL 공식 문서 - Full Text Search)

main.rs

본격적으로 Rust 애플리케이션의 엔트리포인트를 작성한다.
환경 변수 로딩, 구조화된 로깅(Tracing), DB 커넥션 풀링,
그리고 우아한 종료(Graceful Shutdown)를 고려하여 작성한다.

rust-engine/src/main.rs

pub mod pb;
pub mod service;

use sqlx::postgres::PgPoolOptions;
use std::env;
use std::net::SocketAddr;
use tracing_subscriber::FmtSubscriber;
use tonic::transport::Server;

use crate::pb::emotion::emotion_search_service_server::EmotionSearchServiceServer;
use crate::service::MyEmotionSearchService;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    if dotenvy::from_path("../.env").is_err() {
        tracing::info!("로컬 .env 파일을 찾을 수 없습니다. 시스템 환경 변수를 사용합니다.");
    }

    let subscriber = FmtSubscriber::builder()
        .with_max_level(tracing::Level::INFO)
        .finish();
    tracing::subscriber::set_global_default(subscriber)
        .expect("로깅 인프라 초기화에 실패했습니다.");

    tracing::info!("로그 엔진 서버 실행...");
   
    let db_url = env::var("DATABASE_URL").expect("DATABASE_URL이 설정되어 있지 않습니다.");
    tracing::info!("DB 연결 중...");
    let pool = PgPoolOptions::new()
        .max_connections(20)
        .connect(&db_url)
        .await
        .expect("DB 연결 실패");
    tracing::info!("DB 연결 완료");

    // gRPC 서버 설정 빛 실행
    let addr: SocketAddr = env::var("GRPC_HOST")
        .unwrap_or_else(|_| "192.127.0.1:50051".to_string())
        .parse()?;

    tracing::info!("gRPC 서버 수신 대기 중: {}", addr);

    // 서비스 인스턴스 생성 및 Tonic 서버 래핑
    let emotion_service = MyEmotionSearchService::new(pool.clone());
    let svc = EmotionSearchServiceServer::new(emotion_service);

    Server::builder()
        .add_service(svc)
        .serve_with_shutdown(addr, shutdown_signal())
        .await?;

    tracing::info!("gRPC 서버가 안전하게 종료되었습니다.");

    Ok(())
}

async fn shutdown_signal() {
    let ctrl_c = async {
        tokio::signal::ctrl_c()
            .await
            .expect("Ctrl+C 시그널 핸들러 설치 실패");
    };

    #[cfg(unix)]
    let terminate = async {
        tokio::signal::unix::signal(tokio::signal::unix::SignalKind::terminate())
            .expect("SIGTERM 신호 핸들러 생성에 실패했습니다.")
            .recv()
            .await;
    };

    #[cfg(not(unix))]
    let terminate = std::future::pending::<()>();

    // tokio::select! 를 사용하여 두 신호 중 하나라도 발생하면 즉시 반환
    tokio::select! {
        _ = ctrl_c => {
            tracing::info!("Ctrl+C (SIGINT) 수신: 서버의 우아한 종료를 시작합니다...");
        },
        _ = terminate => {
            tracing::info!("SIGTERM 수신: 서버의 우아한 종료를 시작합니다...");
        },
    }
}

테스트 코드

Rust 엔진 src 디렉토리 내에 bin 디렉토리를 생성하여
작동 확인을 위한 테스트 코드를 작성한다.

테스트코드는 AI 작성 코드를 그대로 사용하겠다.

rust-engine/src/bin/client.rs

// 서버(main.rs)와 모듈을 분리하기 위해, pb 모듈을 경로 지정으로 직접 포함합니다.
#[path = "../pb.rs"]
pub mod pb;

use pb::emotion::emotion_search_service_client::EmotionSearchServiceClient;
use pb::emotion::{TaxonomySearchRequest, TextSearchRequest, VectorSearchRequest};
use std::time::Instant;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    println!("🚀 gRPC 서버에 연결 중...");
    let mut client = EmotionSearchServiceClient::connect("http://127.0.0.1:50051").await?;
    println!("✅ 연결 성공!\n");

    // ==========================================================
    // 1. 2차원 벡터(VA) 검색 테스트 (K-NN)
    // ==========================================================
    // 긍정적(0.8)이고 고각성(0.8)인 감정(예: 환희, 벅참)을 질의합니다.
    let start = Instant::now();
    let req = tonic::Request::new(VectorSearchRequest {
        target_vector: vec![0.8, 0.8],
        limit: 3,
    });
    let res = client.search_by_vector(req).await?.into_inner();
    let elapsed = start.elapsed();

    println!("=== 1. 다차원 벡터(VA) K-NN 검색 ===");
    println!("⏱️ 소요 시간: {:?}", elapsed);
    for e in res.emotions {
        println!(" - {} (V: {}, A: {}) / 경로: {}", e.word, e.va_vector[0], e.va_vector[1], e.taxonomy_path);
    }
    println!();

    // ==========================================================
    // 2. 계층 분류(Taxonomy) 검색 테스트
    // ==========================================================
    // 부정적(negative)인 상위 카테고리에 속한 모든 하위 감정을 질의합니다.
    let start = Instant::now();
    let req = tonic::Request::new(TaxonomySearchRequest {
        path_query: "negative.*".to_string(), // lquery 문법
        limit: 5,
    });
    let res = client.search_by_taxonomy(req).await?.into_inner();
    let elapsed = start.elapsed();

    println!("=== 2. 계층 분류(ltree) 트리 검색 ===");
    println!("⏱️ 소요 시간: {:?}", elapsed);
    for e in res.emotions {
        println!(" - {} [{}]", e.word, e.taxonomy_path);
    }
    println!();

    // ==========================================================
    // 3. 텍스트(FTS) 검색 테스트
    // ==========================================================
    let start = Instant::now();
    let req = tonic::Request::new(TextSearchRequest {
        query: "마음이 어둡고".to_string(),
        limit: 2,
    });
    let res = client.search_by_text(req).await?.into_inner();
    let elapsed = start.elapsed();

    println!("=== 3. 텍스트(FTS) 역인덱스 검색 ===");
    println!("⏱️ 소요 시간: {:?}", elapsed);
    for e in res.emotions {
        println!(" - {}: {}", e.word, e.definition);
    }

    Ok(())
}

🤖 AI AGENT | Rust의 테스트코드

프로젝트의 디렉토리 구조와 테스트의 격리(Isolation)는 실무에서 유지보수성과 CI/CD 파이프라인 구축을 좌우하는 핵심 요소입니다. Rust는 테스트의 '목적'에 따라 코드가 위치해야 할 디렉토리와 방식을 언어 차원에서 엄격하게 구분하고 지원합니다.

우리가 방금 작성한 src/bin/client.rs와, 실제 자동화 테스트가 어떻게 구분되는지 실무 표준을 기준으로 설명해 드리겠습니다.

---

🏛️ Rust의 3단계 테스트 아키텍처

Rust 프로젝트(rust-engine) 내부에서 테스트 코드는 크게 세 가지 형태로 배치됩니다.

1. 일회성/수동 검증 스크립트 (src/bin/*.rs)

• 우리가 방금 작성한 방식입니다.
• 목적: 개발자가 눈으로 직접 결과를 확인하거나, 운영 중에 필요한 유틸리티(예: DB 마이그레이션 트리거, 어드민 스크립트)를 만들 때 사용합니다.
• 특징: cargo test 명령어로는 실행되지 않으며, cargo run --bin client처럼 독립된 실행 파일(Binary)로 구동됩니다. 자동화된 테스트라기보다는 '내부 툴'에 가깝습니다.

2. 유닛 테스트 (Unit Tests) (src/ 내부)

• 위치: 비즈니스 로직이 있는 소스 파일(예: src/service.rs)의 맨 아래에 #[cfg(test)] 모듈을 만들어 함께 작성합니다.
• 목적: 단일 함수나 구조체의 내부 로직(예: 우리가 작성했던 parse_vector_string 파싱 로직)이 잘 동작하는지 빠르고 고립된 환경에서 검증합니다.
• 특징: 프라이빗(private) 함수에도 접근할 수 있어 화이트박스(White-box) 테스트가 가능합니다.

3. 통합 테스트 (Integration Tests) (tests/ 디렉토리)

• 위치: src 폴더 바깥, 즉 rust-engine/tests/ 라는 전용 디렉토리를 만들어 작성합니다.
• 목적: 실제 클라이언트가 우리 서버를 사용할 때처럼 외부 사용자의 시선(블랙박스)에서 gRPC 요청을 보내고 DB 연동까지 포함된 전체 흐름을 검증합니다.
• 실무 가치: CI/CD(예: GitHub Actions)에서 메인 브랜치에 병합하기 전 cargo test를 돌릴 때 이 폴더의 코드들이 자동으로 실행되어 시스템의 회귀(Regression) 결함을 막아줍니다.

빌드 및 실행

[터미널: 서버]

~/workspace/community-board-log/rust-engine$ cargo run --release

[터미널: 클라이언트]

~/workspace/community-board-log/rust-engine$ cargo run --release --bin client

[로그: 서버]

2026-05-24T03:55:42.814778Z  INFO rust_engine: 로그 엔진 서버 실행...
2026-05-24T03:55:42.814873Z  INFO rust_engine: DB 연결 중...
2026-05-24T03:55:42.828364Z  INFO rust_engine: DB 연결 완료
2026-05-24T03:55:42.828395Z  INFO rust_engine: gRPC 서버 수신 대기 중: 127.0.0.1:50051
2026-05-24T03:55:56.480004Z  INFO rust_engine::service: 벡터 검색 요청: VA = [0.8, 0.8], Limit = 3
2026-05-24T03:55:56.487726Z  INFO rust_engine::service: Taxonomy 검색 요청: Path = "negative.*", Limit = 5
2026-05-24T03:55:56.498410Z  INFO rust_engine::service: 텍스트 검색 요청: Query = "마음이 어둡고", Limit = 2

[로그: 클라이언트]

🚀 gRPC 서버에 연결 중...
✅ 연결 성공!

=== 1. 다차원 벡터(VA) K-NN 검색 ===
⏱️ 소요 시간: 8.168875ms
 - 신바람나다 (V: 0.18, A: 0.175) / 경로: positive.high_arousal
 - 신나다 (V: 0.24, A: 0.2225) / 경로: positive.high_arousal
 - 통쾌하다 (V: 0.1975, A: 0.1775) / 경로: positive.high_arousal

=== 2. 계층 분류(ltree) 트리 검색 ===
⏱️ 소요 시간: 10.488833ms
 - 가뜬하다 [negative.low_arousal]
 - 가련하다 [negative.low_arousal]
 - 가소롭다 [negative.low_arousal]
 - 가엾다 [negative.low_arousal]
 - 가증스럽다 [negative.high_arousal]

=== 3. 텍스트(FTS) 역인덱스 검색 ===
⏱️ 소요 시간: 2.066417ms

🤖 AI AGENT | 테스트 검토

🎉 축하합니다! 완벽한 성공입니다.

Rust 엔진과 PostgreSQL 18 (pgvector, ltree, FTS 인덱스) 간의 연동이 한 치의 오차도 없이 완벽하게 동작하고 있습니다.

터미널에 출력된 8~10ms의 소요 시간은 DB 연산뿐만 아니라 네트워크 루프백(Loopback) 통신, gRPC 직렬화/역직렬화, 그리고 첫 커넥션 워밍업(Warm-up) 시간까지 모두 포함된 End-to-End 수치입니다. 실제 프로덕션 환경에서 커넥션이 유지된 상태로 부하가 걸리면 DB 쿼리 자체는 1ms 내외로 수렴하게 됩니다. (마지막 텍스트 검색 결과가 생략된 것은, 제공해 주신 전체 CSV 데이터 내에 "마음이 어둡고"라는 뜻을 가진 단어가 정확히 매칭되지 않았기 때문일 수 있습니다. 이는 정상적인 검색 결과(Empty)입니다.)