DokumentePreiseBlog
Kontaktieren Sie uns
AnmeldenKOSTENLOS anmelden
Back to Tech Articles

Rust 웹 서비스에서 트레잇 객체를 활용한 동적 디스패치 및 의존성 주입

Nov. 01, 2025
# Misc

Lukas Schneider

DevOps Engineer · Leapcell

Dieser Beitrag ist auch in English, 日本語 und Deutsch verfügbar
Cover of "Rust 웹 서비스에서 트레잇 객체를 활용한 동적 디스패치 및 의존성 주입"

소개

어떤 언어에서든 견고하고 유지보수 가능한 웹 서비스를 구축하는 것은 종종 의존성 관리, 유연한 아키텍처 구현, 테스트 용이성과 같은 일반적인 문제를 제시합니다. 성능과 메모리 안전성이 가장 중요한 Rust 생태계에서는 이러한 목표를 달성하기 위해 고유한 타입 시스템 기능을 활용하는 경우가 많습니다. 이러한 강력한 기능 중 하나인 트레잇 객체는 동적 디스패치를 위한 메커니즘을 제공합니다. 이 글에서는 Rust 웹 서비스 내에서 트레잇 객체가 동적 디스패치를 달성하고, 이를 통해 의존성 주입을 촉진하기 위해 어떻게 효과적으로 활용될 수 있는지 자세히 살펴봅니다. 이 접근 방식은 애플리케이션의 모듈성, 테스트 용이성 및 전반적인 유연성을 향상시키며, 복잡성이 이를 요구할 때 순수한 정적 디스패치를 넘어서는 수준을 제공합니다.

핵심 개념 이해

실제 적용 사례로 들어가기 전에 논의의 기반이 되는 주요 개념을 간략하게 정의해 보겠습니다.

  • 트레잇 (Traits): Rust에서 트레잇은 컴파일러에게 타입이 어떤 기능을 가지고 있으며 다른 타입과 공유할 수 있는지 알려주는 언어 기능입니다. 본질적으로 공유된 동작을 정의하는 인터페이스입니다. 예를 들어, Logger 트레잇은 log 메서드를 정의할 수 있습니다.
  • 정적 디스패치 (Static Dispatch): 이것이 Rust가 메서드 호출을 처리하는 기본적이고 가장 성능이 좋은 방법입니다. 컴파일러는 구체적인 타입에 따라 어떤 메서드 구현을 호출해야 하는지 컴파일 시점에 정확하게 알고 있습니다. 여기에는 런타임 오버헤드가 없습니다.
  • 동적 디스패치 (Dynamic Dispatch): 정적 디스패치와 달리 동적 디스패치는 런타임에 메서드 호출을 해결합니다. 이는 프로그램이 실행될 때까지 객체의 정확한 타입을 알 수 없지만 특정 트레잇을 구현한다는 것을 알 때 필요합니다. Rust는 주로 트레잇 객체를 통해 이를 달성합니다.
  • 트레잇 객체 (Trait Objects): 트레잇 객체는 특정 트레잇을 구현하는 어떤 타입이 있음을 명시하는 포인터(&dyn Trait 또는 Box<dyn Trait>)입니다. 컴파일 시점에는 구체적인 타입을 "잊어버리지만" 해당 트레잇을 구현한다는 사실은 기억합니다. 이를 통해 모든 항목이 동일한 트레잇을 구현하는 한, 서로 다른 구체적인 타입을 동일한 컬렉션에 저장하거나 매개변수로 전달할 수 있습니다. 트레잇 객체는 호출할 특정 메서드 구현이 런타임에 vtable(가상 테이블)에서 조회되기 때문에 동적 디스패치를 가능하게 합니다.
  • 의존성 주입 (Dependency Injection, DI): 이것은 주로 컴포넌트가 종속성을 얻는 방법을 다루는 소프트웨어 디자인 패턴입니다. 컴포넌트가 자신의 종속성을 생성하는 대신, 컴포넌트에게 제공됩니다(주입됨). 이는 느슨한 결합을 촉진하여 컴포넌트를 더 독립적이고 테스트하기 쉬우며 재사용 가능하게 만듭니다.

의존성 주입을 위한 트레잇 객체를 사용한 동적 디스패치

웹 서비스의 맥락에서는 외부 시스템(데이터베이스, 외부 API, 메시지 큐) 또는 특정 비즈니스 로직의 다른 구현과 상호 작용해야 하는 상황을 자주 접하게 됩니다. 이러한 종속성을 하드코딩하면 서비스가 경직되고 테스트하기 어려워집니다. 여기서 트레잇 객체와 동적 디스패치가 결합되어 의존성 주입에 빛을 발합니다.

사용자 정보를 처리하고 환영 이메일을 보낼 수 있는 웹 서비스를 처리하는 실용적인 예를 생각해 보겠습니다.

서비스에 대한 트레잇 정의

먼저 핵심 기능에 대한 트레잇을 정의합니다.

// src/traits.rs

use async_trait::async_trait;

#[async_trait]
pub trait UserRepository {
    type Error: std::error::Error + Send + Sync + 'static; // 오류에 대한 연관 타입 정의

    async fn create_user(&self, username: &str, email: &str) -> Result<String, Self::Error>;
    async fn get_user_by_email(&self, email: &str) -> Result<Option<User>, Self::Error>;
}

pub struct User {
    pub id: String,
    pub username: String,
    pub email: String,
}

#[async_trait]
pub trait EmailSender {
    async fn send_welcome_email(&self, recipient_email: &str, username: &str) -> Result<(), String>;
}

#[async_trait]는 트레잇 내의 비동기 함수는 특별한 처리가 필요하며 이 매크로가 이를 편리하게 만들기 때문에 사용합니다.

구체적인 서비스 구현

이제 이러한 트레잇에 대한 구체적인 구현을 만들어 보겠습니다. 간단하게 하기 위해 메모리 내의 Fakes 또는 Mocks를 사용하며, 이는 테스트 또는 빠른 프로토타이핑에 완벽합니다.

// src/implementations.rs

use super::traits::{EmailSender, User, UserRepository};
use async_trait::async_trait;
use std::collections::HashMap;
use std::sync::{Arc, Mutex}; // 메모리 내 저장소의 공유된 가변 상태용
use uuid::Uuid;

// --- 메모리 내 UserRepository 구현 ---
pub struct InMemoryUserRepository {
    users: Arc<Mutex<HashMap<String, User>>>,
}

impl InMemoryUserRepository {
    pub fn new() -> Self {
        InMemoryUserRepository {
            users: Arc::new(Mutex::new(HashMap::new())),
        }
    }
}

pub enum UserRepositoryError {
    UserAlreadyExists,
    InternalError(String),
}

impl std::fmt::Display for UserRepositoryError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        match self {
            UserRepositoryError::UserAlreadyExists => write!(f, "User with this email already exists"),
            UserRepositoryError::InternalError(msg) => write!(f, "Internal repository error: {}", msg),
        }
    }
}

impl std::fmt::Debug for UserRepositoryError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        <Self as std::fmt::Display>::fmt(self, f)
    }
}

impl std::error::Error for UserRepositoryError {}


#[async_trait]
impl UserRepository for InMemoryUserRepository {
    type Error = UserRepositoryError;

    async fn create_user(&self, username: &str, email: &str) -> Result<String, Self::Error> {
        let mut users = self.users.lock().unwrap();
        if users.contains_key(email) {
            return Err(UserRepositoryError::UserAlreadyExists);
        }
        let id = Uuid::new_v4().to_string();
        let new_user = User {
            id: id.clone(),
            username: username.to_string(),
            email: email.to_string(),
        };
        users.insert(email.to_string(), new_user);
        Ok(id)
    }

    async fn get_user_by_email(&self, email: &str) -> Result<Option<User>, Self::Error> {
        let users = self.users.lock().unwrap();
        Ok(users.get(email).cloned()) // .cloned()는 User가 Clone을 구현한다고 가정합니다.
    }
}

// --- 콘솔 EmailSender 구현 ---
pub struct ConsoleEmailSender;

#[async_trait]
impl EmailSender for ConsoleEmailSender {
    async fn send_welcome_email(&self, recipient_email: &str, username: &str) -> Result<(), String> {
        println!("Sending welcome email to {} ({})", username, recipient_email);
        // 비동기 작업 시뮬레이션
        tokio::time::sleep(tokio::time::Duration::from_millis(100)).await;
        Ok(())
    }
}

웹 서비스 핸들러

이제 핵심 비즈니스 로직인 UserService를 정의해 보겠습니다. 이 서비스는 트레잇 객체를 의존성으로 사용합니다.

// src/services.rs

use super::traits::{EmailSender, User, UserRepository};
use std::sync::Arc;

pub struct UserService {
    user_repo: Arc<dyn UserRepository<Error = super::implementations::UserRepositoryError> + Send + Sync>,
    email_sender: Arc<dyn EmailSender + Send + Sync>,
}

impl UserService {
    pub fn new(
        user_repo: Arc<dyn UserRepository<Error = super::implementations::UserRepositoryError> + Send + Sync>,
        email_sender: Arc<dyn EmailSender + Send + Sync>,
    ) -> Self {
        UserService {
            user_repo,
            email_sender,
        }
    }

    pub async fn register_user(&self, username: &str, email: &str) -> Result<String, Box<dyn std::error::Error>> {
        if self.user_repo.get_user_by_email(email).await?.is_some() {
            return Err("User with this email already exists".into());
        }

        let user_id = self.user_repo.create_user(username, email).await?;
        self.email_sender.send_welcome_email(email, username).await?;

        Ok(user_id)
    }

    pub async fn get_user(&self, email: &str) -> Result<Option<User>, Box<dyn std::error::Error>> {
        Ok(self.user_repo.get_user_by_email(email).await?)
    }
}

user_repo 및 email_sender의 타입에 주목하십시오: Arc<dyn Trait + Send + Sync>.

  • Arc: 종속성의 여러 소유자를 허용하여 서비스가 여러 요청 핸들러 간에 공유될 때 유용합니다.
  • dyn Trait: "Trait를 구현하는 모든 타입"을 의미하는 트레잇 객체입니다.
  • Send + Sync: 이러한 자동 트레잇은 비동기 웹 서비스 컨텍스트에서 중요한 스레드 간에 안전하게 전송(Send)하고 스레드 간에 공유(Sync)하기 위해 필요합니다. 또한 UserRepositoryError에 대한 연관 타입을 지정했는데, 이는 트레잇 객체에는 모든 연관 타입이 구체적이어야 하기 때문입니다.

웹 프레임워크(예: Actix Web)와의 통합

마지막으로 간단한 Actix Web 애플리케이션에서 이것이 어떻게 통합되는지 살펴보겠습니다.

// src/main.rs (또는 lib.rs)
use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use serde::{Deserialize, Serialize};
use std::sync::Arc;

mod traits;
mod implementations;
mod services;

use traits::{UserRepository, EmailSender};
use implementations::{InMemoryUserRepository, ConsoleEmailSender, UserRepositoryError};
use services::UserService;

#[derive(Deserialize)]
struct RegisterUserRequest {
    username: String,
    email: String,
}

#[derive(Serialize)]
struct RegisterUserResponse {
    user_id: String,
    message: String,
}

#[derive(Deserialize)]
struct GetUserRequest {
    email: String,
}

async fn register_user_handler(
    req: web::Json<RegisterUserRequest>,
    service: web::Data<UserService>,
) -> impl Responder {
    match service.register_user(&req.username, &req.email).await {
        Ok(user_id) => HttpResponse::Created().json(RegisterUserResponse {
            user_id,
            message: "User registered successfully".to_string(),
        }),
        Err(e) => {
            if let Some(user_repo_err) = e.downcast_ref::<UserRepositoryError>() {
                 match user_repo_err {
                    UserRepositoryError::UserAlreadyExists => HttpResponse::Conflict().body(e.to_string()),
                    _ => HttpResponse::InternalServerError().body(e.to_string()),
                }
            } else {
                HttpResponse::InternalServerError().body(e.to_string())
            }
        },
    }
}


async fn get_user_handler(
    req: web::Query<GetUserRequest>,
    service: web::Data<UserService>,
) -> impl Responder {
    match service.get_user(&req.email).await {
        Ok(Some(user)) => HttpResponse::Ok().json(user),
        Ok(None) => HttpResponse::NotFound().body("User not found"),
        Err(e) => HttpResponse::InternalServerError().body(e.to_string()),
    }
}


#[actix_web::main]
async fn main() -> std::io::Result<()> {
    // 의존성 설정 (composition root)
    let user_repo = Arc::new(InMemoryUserRepository::new());
    let email_sender = Arc::new(ConsoleEmailSender);

    let user_service = Arc::new(UserService::new(user_repo, email_sender));

    println!("Starting server on http://127.0.0.1:8080");

    HttpServer::new(move || {
        App::new()
            .app_data(web::Data::from(Arc::clone(&user_service))) // UserService 주입
            .service(web::resource("/register").route(web::post().to(register_user_handler)))
            .service(web::resource("/user").route(web::get().to(get_user_handler)))
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

main 함수에서 InMemoryUserRepository 및 ConsoleEmailSender의 구체적인 인스턴스를 만듭니다. 그런 다음 이러한 구체적인 타입을 Arc로 래핑하고 UserService::new에 전달합니다. UserService::new가 Arc<dyn Trait>을 기대하기 때문에 구체적인 타입은 이 시점에서 "삭제"되며 UserService는 트레잇 객체와만 상호 작용합니다. 이것이 의존성 주입이 작동하는 방식입니다.

이 접근 방식의 장점:

  1. 느슨한 결합: UserService는 UserRepository 또는 EmailSender의 구체적인 구현을 알거나 신경 쓰지 않습니다. 오직 공개적으로 정의된 인터페이스(트레잇)에만 의존합니다. 이는 UserService를 매우 재사용 가능하게 만듭니다.
  2. 테스트 용이성: UserService 자체를 수정하지 않고 단위 또는 통합 테스트를 위해 InMemoryUserRepository 및 ConsoleEmailSender를 모의 구현으로 쉽게 교체할 수 있습니다. 이는 높은 수준의 테스트 커버리지를 유지하는 데 큰 이점입니다.
  3. 유연성: 메모리 내 데이터베이스에서 PostgreSQL로 또는 다른 이메일 서비스로 전환하기로 결정하면 UserRepository 또는 EmailSender의 새 구현을 만들기만 하면 main 함수(composition root)에서 인스턴스화하는 위치를 변경하면 됩니다. UserService 코드는 그대로 유지됩니다.
  4. 런타임 구성: 더 고급 시나리오에서는 런타임 구성 설정에 따라 동적으로 다른 구현을 로드할 수도 있지만, 이는 일반적인 Rust 애플리케이션에서는 덜 일반적입니다.

고려 사항 및 절충점:

  • 런타임 오버헤드: 동적 디스패치는 vtable 조회로 인해 정적 디스패치에 비해 약간의 런타임 오버헤드가 내재되어 있습니다. 대부분의 웹 서비스 시나리오에서 이러한 오버헤드는 특히 I/O 작업이 성능을 압도할 때 무시할 정도입니다.
  • 객체 안전성: 모든 트레잇을 트레잇 객체로 사용할 수 있는 것은 아닙니다. 트레잇이 "객체 안전"하려면 특정 기준(예: 모든 메서드가 self를 수신자로 가져야 하고, 메서드에 Self 외의 제네릭 매개변수가 없어야 함)을 충족해야 합니다.
  • 복잡성: 트레잇, 다중 구현 및 동적 디스패치를 도입하면 코드베이스에 복잡성이 추가될 수 있습니다. 이 패턴의 이점(모듈성, 테스트 용이성)이 추가 복잡성을 능가하는 곳에서 이 패턴을 사용하는 것이 중요합니다. 매우 간단하고 포함된 기능의 경우 정적 디스패치가 충분히 유효할 수 있습니다.

결론

동적 디스패치로 향상된 Rust의 트레잇 객체는 웹 서비스에서 의존성 주입을 달성하기 위한 우아하고 효과적인 솔루션을 제공합니다. 트레잇을 통해 서비스 로직을 구체적인 구현과 분리함으로써 더 모듈적이고 유연하며 철저하게 테스트 가능한 애플리케이션을 구축할 수 있습니다. 이는 Rust의 기본 정적 디스패치를 약간의 런타임 비용으로 포기하는 것이지만, 복잡한 시스템에서의 아키텍처적 이점은 종종 가치 있는 절충점이며, 깨끗한 코드와 탄력적인 디자인을 가능하게 합니다.

Share this article

HackerNews

More Posts from Leapcell

Popular Posts