프로덕션 에이전트 배포 완벽 가이드

AI 에이전트를 실제 서비스 환경에 안전하게 배포하는 방법을 다룹니다. 에러 핸들링부터 비용 제어, 모니터링까지 실무에서 꼭 필요한 핵심 기술을 쉽게 설명합니다.

---

목차

1. 에러_핸들링
2. 타임아웃_관리
3. 비용_제어
4. 안전한_에이전트_배포
5. 모니터링_대시보드

---

1. 에러 핸들링

김개발 씨의 첫 AI 에이전트 서비스가 드디어 런칭했습니다. 그런데 런칭 다음 날 아침, 수십 개의 에러 알림이 쏟아졌습니다.

"분명히 테스트할 때는 잘 됐는데..." 박시니어 씨가 다가와 조용히 말했습니다. "프로덕션은 테스트 환경과 완전히 다른 세계야.

에러 핸들링부터 다시 봐야 해."

프로덕션 환경의 에러 핸들링은 단순히 try-except를 감싸는 것이 아닙니다. 마치 비행기 조종사가 여러 겹의 안전장치를 확인하는 것처럼, 예상치 못한 상황에서도 서비스가 우아하게 실패하도록 설계해야 합니다.

이것을 제대로 구현하면 장애 상황에서도 사용자 경험을 지키고, 문제의 원인을 빠르게 파악할 수 있습니다.

다음 코드를 살펴봅시다.

import logging
from functools import wraps
from typing import TypeVar, Callable

T = TypeVar('T')

# 재시도 데코레이터: 일시적 오류에 대응
def retry_on_failure(max_retries: int = 3, delay: float = 1.0):
    def decorator(func: Callable[..., T]) -> Callable[..., T]:
        @wraps(func)
        async def wrapper(*args, **kwargs) -> T:
            last_error = None
            for attempt in range(max_retries):
                try:
                    return await func(*args, **kwargs)
                except (ConnectionError, TimeoutError) as e:
                    last_error = e
                    logging.warning(f"시도 {attempt + 1}/{max_retries} 실패: {e}")
                    await asyncio.sleep(delay * (2 ** attempt))
            raise last_error
        return wrapper
    return decorator

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 회사의 첫 AI 챗봇 서비스를 담당하게 되어 밤낮으로 개발에 매진했습니다.

개발 환경에서 수백 번의 테스트를 거쳐 완벽하다고 생각했습니다. 그런데 런칭 후 현실은 달랐습니다.

갑자기 OpenAI API가 응답하지 않을 때가 있었고, 네트워크가 불안정한 사용자도 있었습니다. 심지어 예상치 못한 형태의 입력이 들어오기도 했습니다.

박시니어 씨가 커피 한 잔을 건네며 말했습니다. "프로덕션 환경은 마치 야생과 같아.

테스트 환경은 동물원이고." 그렇다면 에러 핸들링이란 정확히 무엇일까요? 쉽게 비유하자면, 에러 핸들링은 마치 등산할 때 가져가는 비상 장비와 같습니다.

날씨가 좋을 때는 필요 없어 보이지만, 갑자기 비가 오거나 길을 잃었을 때 생존을 결정짓습니다. 프로덕션 환경도 마찬가지입니다.

평소에는 모든 것이 순조롭게 돌아가지만, 언제 문제가 생길지 모릅니다. 에러 핸들링이 제대로 되지 않으면 어떤 일이 벌어질까요?

API 호출이 한 번 실패했다고 전체 서비스가 멈춰버립니다. 사용자는 아무런 설명 없이 에러 화면만 보게 됩니다.

더 큰 문제는 개발팀이 무엇이 잘못됐는지 파악하기 어렵다는 것입니다. 로그도 없고, 추적할 정보도 없습니다.

바로 이런 문제를 해결하기 위해 구조화된 에러 핸들링이 필요합니다. 위의 코드에서 retry_on_failure 데코레이터를 살펴보겠습니다.

이 데코레이터는 함수가 실패했을 때 자동으로 재시도합니다. 핵심은 지수 백오프입니다.

첫 번째 재시도는 1초 후, 두 번째는 2초 후, 세 번째는 4초 후에 시도합니다. 이렇게 하면 일시적인 네트워크 문제를 자연스럽게 극복할 수 있습니다.

또한 ConnectionError와 TimeoutError만 재시도한다는 점에 주목하세요. 모든 에러를 재시도하면 안 됩니다.

잘못된 API 키 같은 영구적인 오류는 아무리 재시도해도 성공하지 않습니다. 실제 현업에서는 어떻게 활용할까요?

대형 이커머스 회사의 AI 추천 시스템을 예로 들어보겠습니다. 초당 수천 건의 요청이 들어오는데, LLM API가 잠시 느려지면 전체 서비스에 영향을 미칩니다.

이때 재시도 로직과 함께 폴백 전략을 구현합니다. LLM이 응답하지 않으면 미리 캐시된 추천 결과를 보여주는 것입니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 모든 예외를 except Exception으로 잡아버리는 것입니다.

이렇게 하면 정말 심각한 오류도 묻혀버립니다. 예를 들어 메모리 부족이나 시스템 에러까지 삼켜버리면 나중에 디버깅이 불가능해집니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언대로 에러 핸들링을 개선한 후, 서비스는 훨씬 안정적으로 운영되기 시작했습니다.

"이제 에러가 나도 당황하지 않게 됐어요. 로그만 보면 뭐가 문제인지 바로 알 수 있거든요."

실전 팁

💡 - 재시도할 에러와 즉시 실패해야 할 에러를 명확히 구분하세요

• 구조화된 로깅으로 에러 발생 시 컨텍스트를 함께 기록하세요
• 폴백 전략을 반드시 준비해두세요

---

2. 타임아웃 관리

김개발 씨의 서비스가 어느 날 갑자기 느려졌습니다. 사용자들이 빙글빙글 도는 로딩 화면만 보다가 떠나버렸습니다.

모니터링을 확인해보니 LLM API 응답이 평소 2초에서 갑자기 30초로 늘어난 것이었습니다. "타임아웃을 설정 안 했구나..." 박시니어 씨가 한숨을 쉬었습니다.

타임아웃 관리는 외부 서비스 호출에 시간 제한을 두는 것입니다. 마치 음식점에서 주문 후 30분이 지나도 음식이 안 나오면 환불을 요청하는 것과 같습니다.

타임아웃이 없으면 하나의 느린 요청이 전체 시스템의 리소스를 잡아먹어 연쇄적인 장애를 일으킬 수 있습니다.

다음 코드를 살펴봅시다.

import asyncio
from contextlib import asynccontextmanager

class TimeoutManager:
    def __init__(self, default_timeout: float = 30.0):
        self.default_timeout = default_timeout

    @asynccontextmanager
    async def timeout_context(self, seconds: float = None):
        timeout = seconds or self.default_timeout
        try:
            # asyncio.timeout은 Python 3.11+에서 사용 가능
            async with asyncio.timeout(timeout):
                yield
        except asyncio.TimeoutError:
            raise TimeoutError(f"작업이 {timeout}초 내에 완료되지 않았습니다")

# 사용 예시
async def call_llm_with_timeout(prompt: str, timeout_manager: TimeoutManager):
    async with timeout_manager.timeout_context(seconds=10.0):
        response = await llm_client.generate(prompt)
        return response

김개발 씨는 타임아웃이라는 개념을 알고는 있었지만, 실제로 설정한 적은 없었습니다. "어차피 API가 빨리 응답하는데 뭐하러 설정해?" 이것이 큰 실수였습니다.

어느 금요일 저녁, LLM 제공사의 서버에 문제가 생겼습니다. 평소 2초 걸리던 응답이 1분 이상 걸리기 시작했습니다.

김개발 씨의 서버는 모든 요청을 기다리느라 연결 풀이 고갈되었고, 결국 새로운 요청을 전혀 처리하지 못하는 상태가 되었습니다. 박시니어 씨가 급히 달려와 서버를 재시작하며 말했습니다.

"이게 바로 연쇄 장애야. 한 곳이 느려지면 전체가 멈춰버리는 거지." 그렇다면 타임아웃이란 정확히 무엇일까요?

쉽게 비유하자면, 타임아웃은 마치 약속 시간과 같습니다. 친구와 6시에 만나기로 했는데, 6시 30분까지 안 오면 그냥 가버리는 것입니다.

무한정 기다리면 여러분의 저녁 시간 전체가 망가지기 때문입니다. 서버도 마찬가지입니다.

응답을 무한정 기다리면 다른 사용자들의 요청까지 처리하지 못합니다. 타임아웃이 없으면 어떤 일이 벌어질까요?

첫째, 서버 리소스가 고갈됩니다. 각 요청은 메모리와 연결을 차지하는데, 응답을 기다리는 동안 계속 점유합니다.

둘째, 사용자 경험이 나빠집니다. 로딩이 10초만 넘어가도 대부분의 사용자는 떠나버립니다.

셋째, 장애가 전파됩니다. 느린 외부 서비스 하나가 전체 시스템을 마비시킵니다.

바로 이런 문제를 해결하기 위해 계층적 타임아웃이 필요합니다. 위의 코드에서 TimeoutManager 클래스를 살펴보겠습니다.

asynccontextmanager를 사용해서 깔끔한 문법으로 타임아웃을 적용할 수 있습니다. async with 문법 안에서 작업이 지정된 시간 내에 완료되지 않으면 TimeoutError가 발생합니다.

핵심은 적절한 타임아웃 값을 설정하는 것입니다. 너무 짧으면 정상적인 요청도 실패하고, 너무 길면 타임아웃의 의미가 없습니다.

일반적으로 LLM API 호출은 10-30초, 데이터베이스 쿼리는 5초, 내부 서비스 호출은 3초 정도로 설정합니다. 실제 현업에서는 어떻게 활용할까요?

대형 금융 서비스에서는 Circuit Breaker 패턴과 함께 타임아웃을 사용합니다. 특정 서비스가 연속으로 타임아웃이 발생하면, 일정 시간 동안 해당 서비스 호출을 차단합니다.

이렇게 하면 이미 문제가 있는 서비스에 계속 요청을 보내지 않아 시스템 전체의 안정성이 높아집니다. 하지만 주의할 점도 있습니다.

타임아웃 시간을 모든 곳에서 동일하게 설정하면 안 됩니다. 복잡한 분석 작업은 시간이 더 필요하고, 단순 조회는 빨리 끝나야 합니다.

또한 타임아웃이 발생했을 때 사용자에게 적절한 메시지를 보여주는 것도 중요합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

타임아웃을 제대로 설정한 후, 비슷한 상황이 다시 발생했지만 이번에는 달랐습니다. 느린 요청은 10초 후에 깔끔하게 실패하고, 다른 사용자들은 정상적으로 서비스를 이용할 수 있었습니다.

실전 팁

💡 - 서비스별로 적절한 타임아웃 값을 다르게 설정하세요

• 타임아웃 발생 시 사용자에게 친절한 안내 메시지를 보여주세요
• Circuit Breaker 패턴과 함께 사용하면 효과가 배가됩니다

---

3. 비용 제어

월말이 되자 김개발 씨는 청구서를 보고 깜짝 놀랐습니다. API 비용이 예상의 5배나 나온 것입니다.

"뭐야, 이게 다 뭐야?" 로그를 분석해보니 악의적인 사용자가 자동화 스크립트로 수만 건의 요청을 보낸 것이었습니다. 박시니어 씨가 고개를 저으며 말했습니다.

"비용 제어 없이 프로덕션은 폭탄 돌리기야."

비용 제어는 API 사용량을 모니터링하고 제한하는 시스템입니다. 마치 가정의 전기 사용량을 관리하는 것처럼, 예상치 못한 과다 사용을 감지하고 차단해야 합니다.

특히 LLM API는 토큰 단위로 과금되기 때문에 한 번의 실수가 큰 비용으로 이어질 수 있습니다.

다음 코드를 살펴봅시다.

from dataclasses import dataclass
from datetime import datetime, timedelta
import asyncio

@dataclass
class UsageLimit:
    daily_token_limit: int = 1_000_000
    hourly_request_limit: int = 1000
    per_user_daily_limit: int = 10000

class CostController:
    def __init__(self, limits: UsageLimit):
        self.limits = limits
        self.usage = {}  # user_id -> usage_data

    async def check_and_record(self, user_id: str, tokens: int) -> bool:
        user_usage = self.usage.setdefault(user_id, {"tokens": 0, "requests": 0})

        # 한도 초과 체크
        if user_usage["tokens"] + tokens > self.limits.per_user_daily_limit:
            raise RateLimitError(f"일일 토큰 한도 초과: {user_id}")

        user_usage["tokens"] += tokens
        user_usage["requests"] += 1
        return True

김개발 씨는 처음에 비용 걱정을 하지 않았습니다. 테스트 환경에서는 하루에 몇천 원밖에 안 나왔으니까요.

"사용자가 좀 늘어도 괜찮겠지" 하고 생각했습니다. 하지만 현실은 잔인했습니다.

서비스가 인기를 얻자 일부 사용자들이 API를 남용하기 시작했습니다. 자동화 봇을 돌리거나, 프롬프트에 불필요하게 긴 텍스트를 넣는 사람들이 있었습니다.

심지어 경쟁사에서 의도적으로 비용을 발생시키려는 공격도 있었습니다. 박시니어 씨가 말했습니다.

"LLM API는 돈 먹는 하마야. 제어하지 않으면 회사가 위험해질 수도 있어." 그렇다면 비용 제어란 정확히 무엇일까요?

쉽게 비유하자면, 비용 제어는 마치 수도 요금을 관리하는 것과 같습니다. 물이 콸콸 새는 수도꼭지를 그냥 두면 다음 달 요금 폭탄을 맞습니다.

누수를 감지하고, 사용량을 모니터링하고, 이상하면 알림을 받아야 합니다. LLM API도 마찬가지입니다.

비용 제어가 없으면 어떤 일이 벌어질까요? 첫째, 예산을 초과합니다.

스타트업에서는 이것이 치명적일 수 있습니다. 둘째, 악의적인 사용을 막을 수 없습니다.

경쟁사나 해커가 의도적으로 비용을 발생시킬 수 있습니다. 셋째, 비즈니스 모델이 무너집니다.

무료 사용자가 유료 사용자보다 더 많은 비용을 발생시키면 사업이 지속될 수 없습니다. 바로 이런 문제를 해결하기 위해 다층적 비용 제어가 필요합니다.

위의 코드에서 CostController 클래스를 살펴보겠습니다. UsageLimit 데이터클래스로 다양한 한도를 정의합니다.

일일 전체 토큰 한도, 시간당 요청 수, 사용자별 일일 한도 등을 설정할 수 있습니다. check_and_record 메서드는 모든 요청 전에 호출되어 한도를 체크하고 사용량을 기록합니다.

핵심은 사용자별 제한입니다. 전체 한도만 있으면 한 명의 악성 사용자가 모든 한도를 소진해버릴 수 있습니다.

사용자별로 제한을 두면 이런 문제를 방지할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

유명 AI 서비스들은 티어별 요금제를 운영합니다. 무료 사용자는 하루 1만 토큰, 유료 사용자는 100만 토큰 같은 식입니다.

또한 예산 알림 시스템을 구축합니다. 일일 예산의 80%를 넘으면 슬랙으로 알림이 오고, 100%를 넘으면 서비스가 일시 중단됩니다.

하지만 주의할 점도 있습니다. 너무 엄격한 제한은 사용자 경험을 해칩니다.

"한도 초과" 메시지만 보여주면 사용자는 떠나버립니다. 한도에 가까워지면 미리 알려주고, 업그레이드 옵션을 제시하는 것이 좋습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 비용 제어 시스템을 구축한 후, 다음 달 청구서는 예산 범위 내에 있었습니다.

"이제 마음 편히 잘 수 있어요." 김개발 씨가 안도의 한숨을 쉬었습니다.

실전 팁

💡 - 사용자별, 시간별로 다층적 제한을 설정하세요

• 한도의 80% 도달 시 사전 경고를 보내세요
• 토큰 사용량을 실시간으로 모니터링하는 대시보드를 만드세요

---

4. 안전한 에이전트 배포

드디어 김개발 씨의 에이전트가 프로덕션에 배포될 날이 왔습니다. 하지만 박시니어 씨가 배포 버튼 앞에서 멈춰 섰습니다.

"잠깐, 이거 그냥 배포하면 안 돼. 롤백 계획은 있어?

헬스체크는? 점진적 배포는?" 김개발 씨는 멍한 표정을 지었습니다.

"그게... 뭔가요?"

안전한 배포는 새 버전을 프로덕션에 내보내면서도 문제 발생 시 빠르게 복구할 수 있는 전략입니다. 마치 낙하산을 메고 비행기에서 뛰어내리는 것처럼, 안전장치 없이 배포하는 것은 무모한 모험입니다.

블루-그린 배포, 카나리아 배포, 헬스체크 등의 기법을 조합해야 합니다.

다음 코드를 살펴봅시다.

from enum import Enum
from typing import Optional
import httpx

class DeploymentStatus(Enum):
    HEALTHY = "healthy"
    DEGRADED = "degraded"
    UNHEALTHY = "unhealthy"

class SafeDeployer:
    def __init__(self, app_name: str):
        self.app_name = app_name
        self.current_version: Optional[str] = None
        self.previous_version: Optional[str] = None

    async def health_check(self, endpoint: str) -> DeploymentStatus:
        try:
            async with httpx.AsyncClient(timeout=5.0) as client:
                response = await client.get(f"{endpoint}/health")
                if response.status_code == 200:
                    return DeploymentStatus.HEALTHY
                return DeploymentStatus.DEGRADED
        except Exception:
            return DeploymentStatus.UNHEALTHY

    async def rollback(self) -> bool:
        if self.previous_version:
            # 이전 버전으로 즉시 복구
            self.current_version = self.previous_version
            return True
        return False

김개발 씨는 지금까지 배포를 단순하게 생각했습니다. 코드를 푸시하고, 서버를 재시작하면 끝이라고 생각했습니다.

개발 환경에서는 그래도 됐습니다. 문제가 생기면 본인만 불편하니까요.

하지만 프로덕션은 다릅니다. 수천 명의 사용자가 서비스를 이용하고 있습니다.

배포 중에 5분만 서비스가 중단되어도 수백 명이 불편을 겪습니다. 버그가 있는 버전이 배포되면 회사의 신뢰도가 떨어집니다.

박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다. "배포는 전쟁 작전과 같아.

치밀한 계획과 백업 플랜이 필요해." 그렇다면 안전한 배포란 정확히 무엇일까요? 쉽게 비유하자면, 안전한 배포는 마치 다리를 건너는 것과 같습니다.

한 발을 내딛기 전에 다리가 튼튼한지 확인합니다. 만약 다리가 흔들리면 바로 뒤로 물러날 수 있어야 합니다.

프로덕션 배포도 마찬가지입니다. 새 버전이 문제가 있으면 즉시 이전 버전으로 돌아갈 수 있어야 합니다.

안전한 배포 전략이 없으면 어떤 일이 벌어질까요? 첫째, 배포할 때마다 두려움에 떱니다.

"이번에도 문제없이 되겠지?"라고 기도하게 됩니다. 둘째, 문제가 생기면 복구에 시간이 오래 걸립니다.

이전 버전이 어디 있는지 찾고, 수동으로 배포해야 합니다. 셋째, 작은 문제가 큰 장애로 번집니다.

빠르게 대응하지 못하면 피해가 커집니다. 바로 이런 문제를 해결하기 위해 체계적인 배포 전략이 필요합니다.

위의 코드에서 SafeDeployer 클래스를 살펴보겠습니다. health_check 메서드는 새 버전이 정상적으로 동작하는지 확인합니다.

HEALTHY, DEGRADED, UNHEALTHY 세 가지 상태를 구분합니다. rollback 메서드는 문제 발생 시 이전 버전으로 즉시 복구합니다.

핵심은 자동화입니다. 헬스체크가 실패하면 자동으로 롤백이 실행되어야 합니다.

새벽 3시에 배포했는데 문제가 생겨도, 시스템이 알아서 복구하면 개발자는 푹 잘 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

대형 서비스들은 카나리아 배포를 사용합니다. 새 버전을 전체 사용자에게 한 번에 배포하지 않고, 먼저 1%의 사용자에게만 배포합니다.

문제가 없으면 10%, 50%, 100%로 점진적으로 확대합니다. 이렇게 하면 문제가 있어도 소수의 사용자만 영향을 받습니다.

하지만 주의할 점도 있습니다. 헬스체크가 너무 단순하면 진짜 문제를 놓칠 수 있습니다.

서버가 응답한다고 해서 모든 기능이 정상인 것은 아닙니다. 핵심 기능별로 세부적인 헬스체크를 구현해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 안전한 배포 시스템을 구축한 후, 김개발 씨는 금요일 오후에도 자신 있게 배포할 수 있게 되었습니다.

"예전에는 금요일 배포가 무서웠는데, 이제는 롤백 버튼만 누르면 되니까 안심이 돼요."

실전 팁

💡 - 헬스체크 엔드포인트에 핵심 의존성(DB, API 등) 상태도 포함하세요

• 롤백은 30초 이내에 완료될 수 있도록 준비하세요
• 배포 전 체크리스트를 만들고 매번 확인하세요

---

5. 모니터링 대시보드

서비스가 안정적으로 운영되던 어느 날, 갑자기 고객 문의가 폭주했습니다. "응답이 이상해요", "오류가 나요" 김개발 씨는 당황했습니다.

로그를 뒤져봐도 뭐가 문제인지 알 수가 없었습니다. 박시니어 씨가 모니터를 가리키며 말했습니다.

"보이지 않으면 고칠 수 없어. 모니터링이 필요해."

모니터링 대시보드는 서비스의 상태를 실시간으로 시각화하는 시스템입니다. 마치 자동차의 계기판처럼, 속도, 연료, 엔진 상태를 한눈에 볼 수 있어야 합니다.

응답 시간, 에러율, 토큰 사용량 등 핵심 지표를 추적하면 문제를 조기에 발견하고 빠르게 대응할 수 있습니다.

다음 코드를 살펴봅시다.

from dataclasses import dataclass, field
from datetime import datetime
from collections import deque
from typing import Dict, List

@dataclass
class Metrics:
    timestamp: datetime
    latency_ms: float
    tokens_used: int
    success: bool
    error_type: str = None

class MonitoringDashboard:
    def __init__(self, window_size: int = 1000):
        self.metrics: deque = deque(maxlen=window_size)
        self.alerts: List[str] = []

    def record(self, metric: Metrics):
        self.metrics.append(metric)
        self._check_alerts(metric)

    def get_summary(self) -> Dict:
        if not self.metrics:
            return {}
        recent = list(self.metrics)[-100:]
        return {
            "avg_latency_ms": sum(m.latency_ms for m in recent) / len(recent),
            "error_rate": sum(1 for m in recent if not m.success) / len(recent),
            "total_tokens": sum(m.tokens_used for m in recent),
        }

    def _check_alerts(self, metric: Metrics):
        if metric.latency_ms > 5000:
            self.alerts.append(f"고지연 감지: {metric.latency_ms}ms")

김개발 씨는 예전에 이런 말을 들은 적이 있습니다. "로그만 잘 남기면 되지 않나요?" 하지만 실제로 문제가 터지고 나서야 깨달았습니다.

로그는 과거의 기록일 뿐, 현재 상태를 한눈에 보여주지 않습니다. 수만 줄의 로그를 뒤지며 문제를 찾는 것은 마치 도서관에서 책 한 권을 찾는 것과 같습니다.

도서관 전체를 돌아다니며 책장을 하나씩 확인해야 합니다. 하지만 모니터링 대시보드가 있으면 사서에게 물어보는 것처럼 바로 원하는 정보를 얻을 수 있습니다.

박시니어 씨가 자신의 모니터를 보여주었습니다. 화면에는 그래프와 숫자들이 실시간으로 움직이고 있었습니다.

"이게 우리 서비스의 심전도야. 이상이 생기면 바로 알 수 있지." 그렇다면 모니터링 대시보드란 정확히 무엇일까요?

쉽게 비유하자면, 모니터링 대시보드는 마치 병원의 환자 모니터와 같습니다. 심박수, 혈압, 산소포화도를 실시간으로 보여주고, 이상이 생기면 즉시 알람이 울립니다.

서비스도 마찬가지입니다. 응답 시간, 에러율, 사용량을 실시간으로 확인하고, 문제가 생기면 바로 알림을 받아야 합니다.

모니터링이 없으면 어떤 일이 벌어질까요? 첫째, 사용자가 알려줄 때까지 문제를 모릅니다.

이미 많은 사용자가 불편을 겪은 후입니다. 둘째, 문제의 원인을 파악하기 어렵습니다.

언제부터 문제가 시작됐는지, 어떤 요청에서 문제가 생겼는지 알 수 없습니다. 셋째, 트렌드를 파악할 수 없습니다.

서서히 나빠지는 성능을 인지하지 못합니다. 바로 이런 문제를 해결하기 위해 체계적인 모니터링이 필요합니다.

위의 코드에서 MonitoringDashboard 클래스를 살펴보겠습니다. Metrics 데이터클래스로 각 요청의 정보를 기록합니다.

응답 시간, 토큰 사용량, 성공 여부, 에러 타입 등을 저장합니다. get_summary 메서드는 최근 100개 요청의 통계를 계산합니다.

핵심은 실시간 알림입니다. _check_alerts 메서드를 보면, 응답 시간이 5초를 넘으면 즉시 알림을 생성합니다.

이렇게 하면 문제가 커지기 전에 대응할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

대형 서비스들은 Grafana나 Datadog 같은 도구를 사용합니다. 여러 서버의 지표를 한 곳에 모아 시각화하고, 조건에 따라 슬랙이나 이메일로 알림을 보냅니다.

또한 **SLO(Service Level Objective)**를 정의합니다. 예를 들어 "응답 시간의 99%가 2초 이내여야 한다" 같은 목표를 세우고, 이를 충족하는지 지속적으로 모니터링합니다.

하지만 주의할 점도 있습니다. 너무 많은 알림은 오히려 해롭습니다.

하루에 수십 개의 알림이 오면 정작 중요한 알림을 놓치게 됩니다. 이것을 알림 피로라고 합니다.

정말 중요한 지표만 선별해서 알림을 설정해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

모니터링 대시보드를 구축한 후, 김개발 씨는 아침에 출근하면 가장 먼저 대시보드를 확인합니다. "어제 밤에 에러율이 좀 올라갔네.

원인을 찾아봐야겠다." 문제가 커지기 전에 선제적으로 대응할 수 있게 된 것입니다.

실전 팁

💡 - 핵심 지표 3-5개만 선정해서 집중 모니터링하세요

• 알림 임계값은 점진적으로 조정하세요 (처음부터 완벽할 필요 없습니다)
• 주간 리포트를 생성해서 트렌드를 파악하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!