왜 당신의 다음 AI 에이전트는 마이크로서비스여야 하는가 (그리고 C#와 Docker로 구축하는 방법)

Source: Dev.to

단 한 명의 셰프가 미슐랭 스타 주방을 혼자 운영한다면 어떨까요? 그는 압도당하고, 작업 속도가 느려지며, 작은 병 한 번으로 전체 레스토랑이 문을 닫을 위험에 처하게 됩니다.
이제 그 주방에 전문화된 스테이션—그릴, 제과 코너, 샐러드 준비 구역—이 있다고 상상해 보세요. 훨씬 빠르고, 더 탄력적이며, 각 스테이션을 독립적으로 확장할 수 있습니다.

이것이 모놀리식 AI에서 컨테이너화된 AI 에이전트를 마이크로서비스로 전환하는 근본적인 변화입니다.

이것은 단순한 운영상의 편리함이 아니라, 생성형 AI 워크로드의 예측 불가능하고 급증하는 특성을 감당할 수 있는 견고한 다중 에이전트 시스템을 구축하기 위한 아키텍처적 필수 조건입니다.

The Core Philosophy: Stateless, Immutable, and Scalable

그 핵심에서, AI 에이전트—복잡한 추론 엔진이든 간단한 챗봇이든—는 무상태 함수이다.
에이전트는 컨텍스트(프롬프트, 히스토리, 도구)를 받아서 응답을 반환한다. 핵심은 무상태성이다. 대화 자체는 상태를 가지고 있지만, 에이전트의 처리 로직은 요청 사이에 지속적인 상태를 유지해서는 안 된다.

Source: …

컨테이너화: 불변 아티팩트

컨테이너화는 에이전트의 로직, 종속성(예: .NET 런타임, ONNX Runtime, CUDA 드라이버) 및 설정을 하나의 불변 단위로 패키징합니다. 이는 세 가지 핵심 AI 문제를 해결합니다:

오케스트레이션: 항공 교통 관제

컨테이너화된 후에는 라이프사이클을 관리할 방법이 필요합니다. Kubernetes는 항공 교통 관제와 같이 작동하여 다음을 보장합니다:

• 셀프 힐링 – 충돌된 컨테이너가 자동으로 교체됩니다.
• 서비스 디스커버리 – 에이전트가 하드코딩된 IP 없이 서로를 찾습니다.
• 스케일링 – 피크 부하 시 더 많은 인스턴스가 추가됩니다.

Source: …

복원력: 서비스 메시

여러 에이전트가 상호 작용할 때(예: 라우터 에이전트, 검색 에이전트, 생성 에이전트) 분산 시스템을 형성합니다. 서비스 메시(예: Istio)는 신경계 역할을 하며, 지수 백오프와 회로 차단기를 이용한 재시도를 처리합니다. 이는 AI 에이전트가 매우 불안정하기 때문에 중요합니다—LLM은 환각을 일으키고, 네트워크는 시간 초과가 발생하며, GPU는 과부하될 수 있습니다.

“Hello World” AI 에이전트 마이크로서비스 구축

아래는 전자상거래 챗봇용 GreetingAgent의 최소한이면서도 프로덕션에 적합한 예시입니다. 의존성 주입, 컨테이너화, 무상태 설계라는 핵심 패턴을 보여줍니다.

1️⃣ C# 애플리케이션 (ASP.NET Core)

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;

var builder = WebApplication.CreateBuilder(args);

// Register the service for dependency injection
builder.Services.AddSingleton<IGreetingService, GreetingService>();

var app = builder.Build();

// Define the agent endpoint
app.MapGet("/api/greet/{userName}", (string userName, IGreetingService greetingService) =>
{
    var greeting = greetingService.GenerateGreeting(userName);
    return Results.Ok(new { Message = greeting, Timestamp = DateTime.UtcNow });
});

app.Run();

/// <summary>
/// Service contract – enables swapping implementations (e.g., for testing or a real LLM).
/// </summary>
public interface IGreetingService
{
    string GenerateGreeting(string userName);
}

/// <summary>
/// Simple, stateless implementation.
/// </summary>
public class GreetingService : IGreetingService
{
    private static readonly List<string> GreetingTemplates = new()
    {
        "Hello, {0}! Welcome to our AI‑powered platform.",
        "Hi {0}, great to see you today!",
        "Greetings, {0}! How can our AI assist you?"
    };

    public string GenerateGreeting(string userName)
    {
        if (string.IsNullOrWhiteSpace(userName))
            throw new ArgumentException("User name cannot be empty.", nameof(userName));

        var random = Random.Shared;
        var template = GreetingTemplates[random.Next(GreetingTemplates.Count)];
        return string.Format(template, userName);
    }
}

코드의 핵심 개념

• IGreetingService 인터페이스 – 의존성 역전을 가능하게 하며, 나중에 실제 LLM 구현으로 교체할 수 있습니다.
• 무상태성 – 서비스는 호출 간에 사용자별 데이터를 보관하지 않습니다.
• 비동기 준비 – 실제 프로덕션에서는 GenerateGreeting이 async가 되어 외부 서비스를 호출하게 될 것입니다.

2️⃣ Dockerfile (컨테이너화)

# -------------------------------------------------
# Build Stage
# -------------------------------------------------
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

# Copy csproj and restore as distinct layers
COPY ["GreetingAgentMicroservice.csproj", "./"]
RUN dotnet restore "GreetingAgentMicroservice.csproj"

# Copy everything else and build
COPY . .
RUN dotnet publish "GreetingAgentMicroservice.csproj" \
    -c Release \
    -o /app/publish \
    --no-restore

# -------------------------------------------------
# Runtime Stage
# -------------------------------------------------
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .

# Expose the default ASP.NET Core port
EXPOSE 80
ENV ASPNETCORE_URLS=http://+:80

ENTRYPOINT ["dotnet", "GreetingAgentMicroservice.dll"]

Dockerfile이 수행하는 작업

1. 멀티‑스테이지 빌드 – SDK 이미지에서 앱을 컴파일하고, 게시된 출력물만 가벼운 ASP.NET 런타임 이미지에 복사합니다.
2. 불변성 – 최종 이미지 하나가 버전 관리된 아티팩트가 되어 어디서든 배포할 수 있습니다.
3. 포트 노출 – EXPOSE 80은 오케스트레이터(Kubernetes, Docker Swarm)에게 서비스가 수신 대기하는 포트를 알려줍니다.

3️⃣ Kubernetes에 배포 (고수준 개요)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: greeting-agent
spec:
  replicas: 3               # Horizontal scaling
  selector:
    matchLabels:
      app: greeting-agent
  template:
    metadata:
      labels:
        app: greeting-agent
    spec:
      containers:
      - name: greeting-agent
        image: your-registry/greeting-agent:1.0.0
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: greeting-agent-svc
spec:
  selector:

app: greeting-agent
ports:
- protocol: TCP
  port: 80
  targetPort: 80
type: ClusterIP

kubectl apply -f deployment.yaml 명령으로 매니페스트를 배포합니다. Kubernetes는 포드 라이프사이클, 자체 복구, 그리고 세 개의 복제본에 걸친 로드 밸런싱을 처리합니다.

Recap

각 AI 기능을 컨테이너화된 마이크로서비스로 다루면, 진화하고 확장하며 장애 복구를 할 수 있는 유연성을 얻을 수 있습니다—이는 현대 생성 AI 워크로드가 요구하는 바로 그 것입니다. 🚀

Dockerfile (멀티‑스테이지 빌드)

# --- Build Stage ---
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

# Copy csproj and restore dependencies
COPY ["GreetingAgentMicroservice.csproj", "./"]
RUN dotnet restore "GreetingAgentMicroservice.csproj"

# Copy the rest of the source code and build
COPY . .
RUN dotnet publish "GreetingAgentMicroservice.csproj" -c Release -o /app/publish

# --- Final Runtime Stage ---
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "GreetingAgentMicroservice.dll"]

왜 이런 구조인가?

• 멀티‑스테이지: 최종 이미지에는 컴파일된 애플리케이션과 런타임만 포함되고 SDK나 소스 코드는 포함되지 않습니다. 이렇게 하면 공격 표면과 이미지 크기가 크게 줄어듭니다.
• 불변성: 이미지는 자체 포함된 아티팩트로, 어디서 실행해도 정확히 동일하게 동작합니다.

3. 스케일링 및 고급 패턴

Kubernetes 클러스터에 배포된 후, 앞서 논의한 고급 패턴을 적용할 수 있습니다.

Horizontal Pod Autoscaling (HPA)

CPU 사용량이나 요청 대기열 길이와 같은 사용자 정의 메트릭을 기준으로 GreetingAgent 파드 수를 자동으로 확장하도록 Kubernetes를 구성합니다.

사이드카 패턴

모든 추론 요청을 Prometheus에 로깅하고 싶다면, 파드에 사이드카 컨테이너를 연결합니다. 사이드카는 에이전트와 함께 실행되며 비즈니스 로직에 영향을 주지 않고 메트릭을 수집합니다.

Init Container 패턴

에이전트가 실행되기 위해 2 GB 크기의 모델 파일이 필요하다고 가정해 보겠습니다. Init Container가 메인 에이전트 컨테이너가 시작되기 전에 Azure Blob Storage에서 해당 파일을 다운로드하도록 하면, 에이전트는 완전히 준비된 상태에서만 시작됩니다.

결론: 모놀리식에서 분산 인텔리전스로

AI 에이전트를 무상태(state‑less)이며 컨테이너화된 마이크로서비스로 다룸으로써, 우리는 이들을 깨지기 쉬운 블랙 박스에서 회복력 있고 확장 가능한 분산 시스템의 구성 요소로 변환합니다. 이 아키텍처를 통해 다음을 실현할 수 있습니다:

• 정밀한 스케일링: 필요할 때만 고가의 GPU 자원을 할당합니다.
• 장애 격리: 추천 에이전트가 충돌해도 가격 책정 에이전트가 중단되지 않습니다.
• 빠른 혁신: 전체 애플리케이션을 재배포하지 않고도 하나의 에이전트에서 모델이나 프레임워크를 교체할 수 있습니다.

C#과 최신 .NET을 사용하면 인터페이스, async/await, 의존성 주입과 같은 강력한 언어 기능을 활용해 이러한 엔터프라이즈‑급 패턴을 깔끔하게 구현할 수 있습니다.

토론해 봅시다

• 무상태성 vs. 메모리: AI 에이전트는 유용하게 작동하려면 대화 기록이 필요합니다. 에이전트의 처리 로직은 무상태이며 확장 가능하도록 유지하면서 대화의 “상태”를 어떻게 설계하시겠습니까?
• 콜드 스타트 문제: 대형 언어 모델을 GPU 메모리에 로드하는 데 몇 분이 걸릴 수 있습니다. 사용자가 타임아웃되지 않도록 갑작스러운 트래픽 급증을 처리하기 위한 쿠버네티스 스케일링 전략을 어떻게 설계하시겠습니까?

여기서 시연된 개념과 코드는 전자책 Cloud‑Native AI & Microservices: Containerizing Agents and Scaling Inference에 제시된 포괄적인 로드맵에서 직접 가져온 것입니다.

전자책을 여기서 확인하세요: Leanpub.com.

Python, TypeScript, C#에 관한 다른 프로그래밍 전자책도 확인해 보세요: Leanpub.com – 저자 페이지.

원하신다면 거의 모든 책을 Amazon에서도 찾으실 수 있습니다.