software

우리는 람다로 시작했습니다. 여기서 무슨 문제가 발생했는지.

발행: (2026년 3월 3일 오후 03:10 GMT+9)
15 분 소요
원문: Dev.to

I’m ready to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line, formatting, markdown, and any code blocks exactly as they are.

Lambdas는 AI 워크로드에 완벽해 보였다

단일 목적 함수, 자동 스케일링, 사용한 만큼만 비용을 지불합니다. 우리는 7개의 Lambda를 만들고 나서야 우리의 실수를 깨달았습니다.

첫 번째 Lambda – 문서 요약기

import { APIGatewayProxyHandler } from 'aws-lambda';
import OpenAI from 'openai';

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

export const handler: APIGatewayProxyHandler = async (event) => {
  try {
    const { document } = JSON.parse(event.body || '{}');

    const response = await openai.chat.completions.create({
      model: 'gpt-4',
      messages: [
        {
          role: 'system',
          content: 'Summarize the following document in 2-3 sentences.'
        },
        {
          role: 'user',
          content: document
        }
      ],
      max_tokens: 150
    });

    return {
      statusCode: 200,
      body: JSON.stringify({
        summary: response.choices[0].message.content
      })
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ error: error.message })
    };
  }
};

깨끗하고 간단했습니다. 잘 작동했지만… 결국 그렇지 않았습니다.

Source: …

29‑초 장벽

우리의 첫 번째 주요 문제는 복잡한 문서를 분석할 수 있는 에이전트를 만들었을 때 발생했습니다. 에이전트는 다음을 수행해야 했습니다:

  • 문서에서 텍스트 추출
  • 핵심 주제 분석
  • 태그 생성
  • 요약 작성
  • 관련 자산 제안

각 단계마다 3–7초가 소요되었습니다. 총 실행 시간: ~25초. Lambda의 15분 제한 안이겠죠?

틀렸습니다.

2024-02-15 14:32:18 START RequestId: abc-123-def
2024-02-15 14:32:18 Calling OpenAI for document analysis...
2024-02-15 14:32:25 Analysis complete, generating tags...
2024-02-15 14:32:32 OpenAI inference still running...
2024-02-15 14:32:47 ERROR Task timed out after 29.00 seconds

API Gateway에는 29초 타임아웃이 설정되어 있습니다 – Lambda가 아니라요. 함수를 API Gateway를 통해 노출한다면(아마도 그렇게 할 겁니다), 29초에서 벽에 부딪히게 됩니다.

이 타임아웃이 발생하면:

  • 클라이언트는 504 Gateway Timeout을 받음
  • Lambda는 계속 실행되어 비용이 발생함
  • OpenAI/Bedrock 호출은 완료되지만 결과가 사라짐
  • 사용자는 요청 실패를 경험함
  • 전체 Lambda 실행 시간에 대해 비용이 청구됨

우리는 복합 에이전트 요청의 **30 %**를 타임아웃으로 잃었습니다. 사용자들은 우리 AI가 고장났다고 생각했지만, 실제로는 단지 느렸을 뿐이었습니다.

스트리밍? Lambda에서는 불가능

우리 사용자들은 ChatGPT의 스트리밍 인터페이스처럼 실시간 채팅 응답을 원했습니다. 우리는 스트리밍을 구현해 보았습니다:

export const handler: APIGatewayProxyHandler = async (event) => {
  const stream = await openai.chat.completions.create({
    model: 'gpt-4',
    messages: [/* ... */],
    stream: true
  });

  // This is where it breaks
  for await (const chunk of stream) {
    // How do you stream through API Gateway?
    // You can't.
  }
};

API Gateway Lambda 응답 전체를 버퍼링한 뒤 클라이언트에 전송합니다. 부분 데이터를 스트리밍할 방법이 없으며, Lambda가 끝날 때까지 클라이언트는 아무것도 보지 못합니다.

우회 방법: WebSockets, 하지만 이는 다음을 의미합니다:

  • 별도의 WebSocket API Gateway
  • 연결 관리
  • 메시지 라우팅
  • 상태 추적
  • 훨씬 더 복잡해짐

우리는 시도해 보았고, 간단한 스트리밍 응답을 위해 코드 크기가 **3×**로 늘어났습니다.

Cold Starts from Hell

AI SDK는 무겁습니다. 우리가 가져온 내용은 다음과 같습니다:

import OpenAI from 'openai';                                   // 2.1 MB
import { BedrockRuntimeClient } from '@aws-sdk/client-bedrock-runtime'; // 1.8 MB
import Anthropic from '@anthropic-ai/sdk';                    // 1.9 MB
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';    // 1.2 MB
import PDFParse from 'pdf-parse';                             // 0.9 MB

전체 번들 크기: ~8 MB
콜드‑스타트 시간: 8–12 초

Lambda가 5분 이상 실행되지 않으면 AWS가 새 컨테이너를 생성합니다. 컨테이너 시작 + 코드 초기화 = 사용자는 첫 응답을 받기 위해 10초 이상을 기다려야 합니다.

우리 AI 함수들이 간헐적으로 사용되었기 때문에 콜드 스타트가 지속적으로 발생했습니다:

  • 문서 분석: ~시간당 20 요청
  • 이미지 분류: 시간당 5–10 요청
  • 콘텐츠 생성: 시간당 1–2 요청

각 함수는 하루에 여러 번 콜드 상태가 되었습니다. 사용자는 문서를 업로드하고 ~12 초를 기다린 뒤 플랫폼이 고장난 것으로 착각했습니다.

우리는 Provisioned Concurrency를 시도했습니다. 효과는 있었지만 함수당 월 ≈ $50의 비용이 들었습니다. 7개의 함수를 운영하면 월 ≈ $350이 들었으며, 이는 단 한 번의 요청도 처리하기 전에 발생하는 비용이었습니다.

공유 상태 없음

다중 턴 대화가 불가능했습니다. 우리가 시도한 내용은 다음과 같습니다:

// Turn 1: User asks about a document
export const chatHandler: APIGatewayProxyHandler = async (event) => {
  const { message, conversationId } = JSON.parse(event.body || '{}');

  // Get conversation history from DynamoDB
  const history = await getConversationHistory(conversationId);

  const response = await openai.chat.completions.create({
    model: 'gpt-4',
    messages: [
      ...history,
      { role: 'user', content: message }
    ]
  });

  // Save new messages to DynamoDB
  await saveMessage(conversationId, 'user', message);
  await saveMessage(conversationId, 'assistant', response.choices[0].message.content);

  return {
    statusCode: 200,
    body: JSON.stringify({ response: response.choices[0].message.content })
  };
};

각 요청마다 필요했습니다:

  • 대화 기록을 가져오기 위한 DynamoDB 읽기
  • AI 추론
  • 교환을 저장하기 위한 두 번의 DynamoDB 쓰기

3턴 대화의 경우 읽기 3회 + 쓰기 6회가 발생하여 눈에 띄는 지연과 비용이 추가됩니다.

비용 급증이 초래한 문제

Lambda 요금은 밀리초 단위로 청구되지만, AI 추론은 지연 시간이 예측할 수 없습니다:

  • 간단한 질문: 2–3 초
  • 복잡한 분석: 15–25 초
  • 코드 생성: 10–30 초
  • 이미지 분석: 5–20 초

비용 내역 (비싼 한 달)

Document Summarizer:   1,200 requests × 8 s avg  = 2.7 h = $180
Image Classifier:        800 requests × 12 s avg = 2.7 h = $180
Content Generator:      400 requests × 18 s avg = 2.0 h = $135
Chat Agent:            2,000 requests × 15 s avg = 8.3 h = $560
Tag Suggester:         3,000 requests × 5 s avg  = 4.2 h = $280
PDF Analyzer:            200 requests × 22 s avg = 1.2 h = $80
Report Builder:          100 requests × 35 s avg = 1.0 h = $65
---------------------------------------------------------------
Total:                                          $1,480

우리는 AI “생각” 시간에 대한 Lambda 컴퓨팅 비용을 지불하고 있었습니다. 실제로 CPU를 50 ms만 사용하지만 20 초가 걸리는 GPT‑4 호출이라도 Lambda 실행 시간 전체인 20 초에 대해 비용을 지불해야 했습니다.

단일 AI 호출이 처리되는 동안 여러 요청을 처리할 수 있는 장기 실행 컨테이너와 비교하면 훨씬 비용 효율적입니다.

가장 안 좋은 점은? 피크 사용량이 문제를 더욱 악화시켰습니다. 업무 시간 동안 우리는 AI 응답을 기다리는 동시 Lambda 실행 50개 이상을 보유하고 있었습니다. 실제 연산은 OpenAI 서버에서 이루어지지만 각 Lambda 인스턴스가 비용을 소모했습니다. 마치 교통 체증에 갇힌 택시 요금을 내는 것과 같았습니다 – 진행이 아니라 시간에 대해 비용을 지불하는 것이었습니다.

Multi‑Turn Agent Loops

마지막 한 방은 사용자가 자산을 정리하도록 도와줄 수 있는 에이전트를 만드는 것이었습니다. 워크플로우:

  1. User: “내 제품 사진을 정리해 줘.”
  2. Agent: 사용 가능한 사진을 분석하고, 명확히 할 질문을 합니다.
  3. User: 기준을 제공합니다.
  4. Agent: 폴더 구조를 제안합니다.
  5. User: 승인하거나 변경을 요청합니다.
  6. Agent: 정리를 실행합니다.

각 단계는 별도의 Lambda 호출이었습니다. 상태 관리는 다음과 같이 이루어졌습니다:

// Step 1: Initial request
await saveToDynamoDB(sessionId, {
  step: 'analyzing',
  photos: userPhotos,
  status: 'in_progress'
});

// Step 2: Agent response
const session = await getFromDynamoDB(sessionId);
await openai.chat.completions.create(/* ... */);
await saveToDynamoDB(sessionId, {
  ...session,
  step: 'awaiting_criteria',
  analysis: result
});

// Step 3: User provides criteria
const session = await getFromDynamoDB(sessionId);
// ... and so on

6단계에 이르렀을 때 우리는 12개 이상의 DynamoDB 작업, 6번의 Lambda 호출, 그리고 매번 로드하는 데 비용이 많이 드는 대화 컨텍스트를 가지고 있었습니다.

사용자 경험은 매 단계마다 새로운 HTTP 요청이 필요했기 때문에 어색했습니다. 지속적인 연결도 없고, 실시간 업데이트도 없으며, 스트리밍도 없었습니다—단순히 요청‑응답 사이클만 존재했으며, 이는 ChatGPT와 비교했을 때 부실하게 느껴졌습니다.

“이건 2010년식 소프트웨어 같아,” 라고 워크플로우를 한 번 시도해 본 후 제품 책임자가 말했습니다. 그는 틀리지 않았습니다.

한계점

우리의 Lambda 기반 AI 플랫폼에는 근본적인 문제가 있었습니다:

  • 29‑second timeout killed complex workflows → 29초 타임아웃이 복잡한 워크플로를 중단시켰다
  • No streaming made chat feel broken → 스트리밍 없음으로 채팅이 끊긴 느낌이었다
  • Cold starts added 10+ second delays → 콜드 스타트가 10초 이상의 지연을 초래했다
  • Cost inefficiency from paying for AI wait time → 비용 비효율성은 AI 대기 시간에 대한 비용 지불에서 비롯되었다
  • State‑management complexity made agents painful → 상태 관리 복잡성으로 에이전트가 어려워졌다
  • Integration sprawl across 7 different functions → 통합 확산이 7개의 서로 다른 기능에 걸쳐 있었다

우리는 기능을 구축하기보다 인프라와 싸우는 데 더 많은 시간을 보냈습니다. 사용자들은 응답이 느리다고 불평했으며, AWS 비용은 계속 상승했습니다.

람다: 완벽한 AI 도구, 형편없는 AI 에이전트

도구는 단일 목적이며, 무상태이고, 빠릅니다:

  • 이미지를 분류한다
  • 문서를 요약한다
  • PDF에서 텍스트를 추출한다
  • 대체 텍스트를 생성한다

에이전트는 다중 턴이며, 상태를 유지하고, 복잡합니다:

  • 사진 정리를 도와준다
  • 데이터를 분석하고 보고서를 만든다
  • 내 문서에 대해 대화한다
  • 대화를 기반으로 워크플로를 구축한다

도구의 경우 Lambda가 이상적입니다. 에이전트의 경우 지속적인 연결, 공유 상태, 스트리밍이 필요합니다—이는 Lambda가 매 단계마다 맞서 싸우는 부분입니다.

우리가 대신 만든 것

우리는 게이트웨이를 만들었습니다: 도구와 에이전트를 모두 처리할 수 있는 단일 API 엔드포인트로, 적절한 스트리밍, 상태 관리, 그리고 공급업체 유연성을 제공합니다.

아키텍처 개요

  • API Gateway → 라이트웨이트 Lambda(게이트웨이 로직)로 라우팅
  • Gateway Lambda → 실제 AI 처리를 수행하는 장기 실행 컨테이너에 요청을 프록시

이는 양쪽의 장점을 모두 제공합니다: API 계층에 대한 서버리스 스케일링과 AI 작업에 대한 지속적인 연결.

다음 기사에서는 게이트웨이 패턴을 자세히 살펴보고, 7개의 서로 다른 AI Lambda를 하나의 깔끔한 API로 통합하여 모든 모델 제공업체와 작동하도록 만든 과정을 보여드리겠습니다.

이 글은 프로덕션 AI 플랫폼 구축에 관한 8부 시리즈 중 2부입니다. 전체 코드 예시는 에서 확인할 수 있습니다.

0 조회
#software #programming #community
원문 보기
Share:
Back to Blog

관련 글

더 보기 »

일이 정신 건강 위험이 될 때

markdown !Ravi Mishrahttps://media2.dev.to/dynamic/image/width=50,height=50,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fu...