AWS Bedrock 모니터링과 로깅 완벽 가이드

CloudWatch를 활용하여 AWS Bedrock 서비스의 메트릭을 실시간으로 모니터링하고, 사용량 대시보드를 구성하며, 비용 알람까지 설정하는 방법을 초급 개발자를 위해 단계별로 안내합니다.

1. CloudWatch 기초

어느 날 김개발 씨는 회사에서 AWS Bedrock을 활용한 AI 챗봇 서비스를 운영하게 되었습니다. 서비스를 배포한 첫날, 갑자기 사용자가 몰려들었는데 시스템이 어떻게 동작하는지 전혀 알 수가 없었습니다.

선배 박시니어 씨가 다가와서 물었습니다. "CloudWatch는 설정했어요?"

CloudWatch는 AWS의 모니터링 및 관찰 서비스입니다. 마치 자동차의 계기판이 속도, 연료, 엔진 상태를 실시간으로 보여주는 것처럼, CloudWatch는 AWS 리소스의 상태를 한눈에 파악할 수 있게 해줍니다.

Bedrock을 포함한 모든 AWS 서비스의 메트릭을 수집하고, 로그를 저장하며, 알람을 설정할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
from datetime import datetime, timedelta

# CloudWatch 클라이언트 생성
cloudwatch = boto3.client('cloudwatch', region_name='us-east-1')

# 최근 1시간 동안의 메트릭 조회
end_time = datetime.utcnow()
start_time = end_time - timedelta(hours=1)

# Bedrock 호출 횟수 메트릭 가져오기
response = cloudwatch.get_metric_statistics(
    Namespace='AWS/Bedrock',  # Bedrock 네임스페이스
    MetricName='Invocations',  # 호출 횟수 메트릭
    StartTime=start_time,
    EndTime=end_time,
    Period=300,  # 5분 단위로 집계
    Statistics=['Sum']  # 합계 통계
)

print(f"총 호출 횟수: {sum([point['Sum'] for point in response['Datapoints']])}")

김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 AWS Bedrock을 활용한 고객 상담 AI 챗봇을 개발하여 배포했습니다.

런칭 첫날, 예상보다 훨씬 많은 사용자가 몰려들었고, 김개발 씨는 불안해지기 시작했습니다. "지금 몇 명이나 사용하고 있는 걸까?

시스템은 정상인가? 비용은 얼마나 나오고 있지?" 머릿속에 온갖 걱정이 떠올랐지만, 확인할 방법이 없었습니다.

바로 그때 선배 박시니어 씨가 김개발 씨의 모니터를 보더니 물었습니다. "CloudWatch 대시보드는 만들어 놨어요?

지금 서비스 상태를 어떻게 알고 계세요?" CloudWatch란 무엇일까요? 쉽게 비유하자면, CloudWatch는 자동차의 계기판과 같습니다. 운전할 때 계기판을 보면 현재 속도, 남은 연료, 엔진 온도 등을 한눈에 파악할 수 있습니다.

계기판이 없다면? 차가 얼마나 빨리 가는지, 언제 기름을 넣어야 하는지 알 수 없어 위험합니다.

이처럼 CloudWatch도 AWS 서비스의 상태를 실시간으로 보여주는 계기판입니다. CPU 사용률, 메모리 사용량, API 호출 횟수, 에러 발생 건수 등 다양한 지표를 수집하고 시각화합니다.

CloudWatch 없이는 어떤 문제가 생길까요? 과거 클라우드 초창기에는 모니터링 도구가 제대로 갖춰지지 않았습니다. 개발자들은 서버에 직접 접속해서 로그 파일을 일일이 확인해야 했습니다.

시스템에 문제가 생겨도 사용자가 먼저 불만을 제기할 때까지 알 수 없었습니다. 더 큰 문제는 예상치 못한 비용 폭탄이었습니다.

API 호출이 비정상적으로 증가해도 청구서를 받기 전까지는 알 수 없었습니다. 한 달 후 받은 청구서를 보고 경악하는 일이 비일비재했습니다.

CloudWatch로 해결하는 방법 바로 이런 문제를 해결하기 위해 AWS는 CloudWatch를 제공합니다. CloudWatch를 사용하면 실시간으로 서비스 상태를 파악할 수 있습니다.

또한 임계값을 설정하여 문제가 발생하기 전에 미리 알림을 받을 수 있습니다. 무엇보다 비용 폭탄을 방지할 수 있다는 큰 이점이 있습니다.

코드로 CloudWatch 활용하기 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 boto3 라이브러리로 CloudWatch 클라이언트를 생성합니다.

이것이 CloudWatch와 통신하는 핵심 객체입니다. 다음으로 조회할 시간 범위를 설정합니다.

최근 1시간 동안의 데이터를 가져오기 위해 현재 시각에서 1시간을 뺀 값을 계산합니다. 가장 중요한 부분은 get_metric_statistics 메서드입니다.

여기서 Namespace는 어떤 AWS 서비스의 메트릭인지 지정하고, MetricName은 구체적으로 어떤 지표를 볼 것인지 정합니다. Period는 데이터를 몇 초 단위로 집계할지 결정하며, Statistics는 합계, 평균, 최댓값 등 어떤 통계값을 볼 것인지 정합니다.

실무에서 어떻게 활용할까요? 실제 현업에서는 어떻게 활용할까요? 예를 들어 온라인 쇼핑몰에서 AI 상품 추천 서비스를 운영한다고 가정해봅시다.

블랙프라이데이 같은 대규모 이벤트 기간에는 평소보다 10배 이상 트래픽이 몰립니다. 이때 CloudWatch로 실시간 호출 횟수를 모니터링하면 시스템 확장 시점을 정확히 판단할 수 있습니다.

또한 특정 시간대에 에러율이 급증하면 즉시 알람을 받아 대응할 수 있습니다. 초보자가 흔히 하는 실수 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 너무 많은 메트릭을 한꺼번에 수집하려는 것입니다. 이렇게 하면 정작 중요한 지표를 놓치게 되고, 비용도 불필요하게 증가합니다.

따라서 처음에는 핵심 메트릭 몇 가지만 선택해서 모니터링하는 것이 좋습니다. Bedrock의 경우 호출 횟수, 응답 시간, 에러율 정도면 충분합니다.

정리하며 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 "아, 그래서 CloudWatch가 필요했군요!"라고 고개를 끄덕였습니다.

CloudWatch를 제대로 이해하면 서비스를 안정적으로 운영하고, 문제를 사전에 예방할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 처음에는 호출 횟수, 에러율, 응답 시간 등 핵심 메트릭 3-5개만 모니터링하세요

메트릭 조회 시 Period를 너무 짧게 설정하면 비용이 증가하니 주의하세요
CloudWatch 대시보드를 만들어 한 화면에서 여러 메트릭을 동시에 확인하세요

2. Bedrock 메트릭 확인

CloudWatch의 중요성을 깨달은 김개발 씨는 바로 Bedrock 메트릭을 확인하기 시작했습니다. 그런데 막상 CloudWatch 콘솔을 열어보니 수백 개의 메트릭이 나열되어 있었습니다.

"어떤 메트릭을 봐야 하는 거지?" 김개발 씨는 다시 박시니어 씨에게 물었습니다.

Bedrock 메트릭은 AI 모델 호출과 관련된 핵심 지표들입니다. 마치 병원에서 환자의 혈압, 맥박, 체온을 측정하는 것처럼, Bedrock의 건강 상태를 나타내는 바이탈 사인입니다.

주요 메트릭으로는 Invocations(호출 횟수), ModelInvocationLatency(응답 시간), InvocationClientErrors(클라이언트 에러), InvocationServerErrors(서버 에러) 등이 있습니다.

다음 코드를 살펴봅시다.

import boto3
from datetime import datetime, timedelta

cloudwatch = boto3.client('cloudwatch', region_name='us-east-1')

# 조회 시간 설정 (최근 24시간)
end_time = datetime.utcnow()
start_time = end_time - timedelta(hours=24)

# 주요 Bedrock 메트릭 리스트
metrics = [
    'Invocations',  # 총 호출 횟수
    'InvocationClientErrors',  # 클라이언트 에러 횟수
    'InvocationServerErrors',  # 서버 에러 횟수
]

# 각 메트릭별로 데이터 수집
for metric_name in metrics:
    response = cloudwatch.get_metric_statistics(
        Namespace='AWS/Bedrock',
        MetricName=metric_name,
        Dimensions=[
            {'Name': 'ModelId', 'Value': 'anthropic.claude-3-sonnet-20240229-v1:0'}
        ],
        StartTime=start_time,
        EndTime=end_time,
        Period=3600,  # 1시간 단위
        Statistics=['Sum', 'Average']
    )

    total = sum([point['Sum'] for point in response['Datapoints']])
    print(f"{metric_name}: {total}")

김개발 씨가 CloudWatch 콘솔을 열어보니 화면 가득 메트릭 이름들이 나열되어 있었습니다. "이게 다 뭐지?" 어떤 것부터 봐야 할지 막막했습니다.

박시니어 씨가 옆에 앉으며 설명을 시작했습니다. "Bedrock 메트릭은 크게 네 가지만 알면 됩니다.

호출 횟수, 응답 시간, 클라이언트 에러, 서버 에러죠." Bedrock 메트릭이란? 쉽게 비유하자면, Bedrock 메트릭은 병원에서 측정하는 바이탈 사인과 같습니다. 의사가 환자를 진찰할 때 혈압, 맥박, 체온, 호흡수를 먼저 확인하는 것처럼, Bedrock의 상태를 파악할 때도 핵심 지표 몇 가지만 보면 전체적인 건강 상태를 알 수 있습니다.

메트릭이 수백 개나 있다고 해서 모든 것을 볼 필요는 없습니다. 정말 중요한 몇 가지만 집중적으로 모니터링하면 됩니다.

메트릭을 모르면 어떤 문제가 생길까요? 메트릭을 제대로 확인하지 않으면 심각한 문제를 놓칠 수 있습니다. 예를 들어 에러율이 30%까지 치솟았는데도 모르고 있다가 고객 불만이 쏟아진 후에야 알게 되는 경우가 있습니다.

또한 응답 시간이 점점 느려지고 있다는 신호를 놓치면, 사용자 경험이 계속 나빠집니다. 사용자들은 느린 서비스를 참지 못하고 이탈하기 시작합니다.

문제를 조기에 발견했다면 간단히 해결할 수 있었을 텐데, 너무 늦게 알아차려서 대규모 장애로 번진 사례도 많습니다. 핵심 메트릭 네 가지 바로 이런 문제를 방지하기 위해 핵심 메트릭을 모니터링해야 합니다.

첫 번째는 Invocations입니다. 이것은 AI 모델이 몇 번 호출되었는지 보여줍니다.

트래픽 추세를 파악할 수 있어 용량 계획을 세울 때 필수적입니다. 두 번째는 ModelInvocationLatency입니다.

모델이 응답하는 데 걸리는 시간을 측정합니다. 응답 시간이 길어지면 사용자 경험이 나빠지므로 반드시 추적해야 합니다.

세 번째는 InvocationClientErrors입니다. 클라이언트 측에서 발생한 에러 횟수입니다.

주로 잘못된 요청 형식이나 권한 문제로 발생하며, 코드 수정이 필요한 신호입니다. 네 번째는 InvocationServerErrors입니다.

AWS Bedrock 서비스 측에서 발생한 에러입니다. 이 수치가 높으면 AWS 서비스 상태를 확인하고 지원팀에 문의해야 할 수 있습니다.

코드 상세 분석 위의 코드를 살펴보겠습니다. 먼저 조회할 시간 범위를 24시간으로 설정합니다.

하루 동안의 추세를 보면 패턴을 파악하기 좋습니다. 다음으로 확인할 메트릭 이름을 리스트로 정의합니다.

핵심은 Dimensions 파라미터입니다. 이것은 특정 모델의 메트릭만 필터링할 때 사용합니다.

예를 들어 Claude 3 Sonnet 모델의 메트릭만 보고 싶다면 ModelId를 지정하면 됩니다. 반복문을 돌면서 각 메트릭의 합계를 계산하고 출력합니다.

이렇게 하면 한눈에 전체 호출 횟수와 에러 건수를 파악할 수 있습니다. 실무 활용 사례 실제 서비스에서는 이 메트릭들을 어떻게 활용할까요?

대형 이커머스 회사에서 고객 문의 응대 AI를 운영한다고 가정해봅시다. 평소에는 시간당 1,000건 정도의 호출이 발생합니다.

그런데 갑자기 3,000건으로 급증했다면? 이것은 마케팅 이벤트가 시작되었거나, 서비스에 문제가 생겨서 사용자들이 몰려들고 있다는 신호일 수 있습니다.

또한 InvocationClientErrors가 평소보다 10배 증가했다면, 최근에 배포한 코드에 버그가 있을 가능성이 높습니다. 즉시 롤백을 고려해야 합니다.

주의해야 할 함정 초보 개발자들이 흔히 하는 실수가 있습니다. 메트릭 이름을 잘못 입력하는 것입니다.

'Invocation'과 'Invocations'는 다릅니다. 's'가 없으면 데이터가 조회되지 않습니다.

또한 Dimensions를 잘못 설정하면 원하는 데이터가 나오지 않습니다. ModelId 값은 정확한 모델 식별자를 입력해야 합니다.

AWS 콘솔에서 복사해서 사용하는 것이 안전합니다. 마무리 박시니어 씨의 설명을 들은 김개발 씨는 "네 가지만 집중하면 되는군요!"라고 안도의 한숨을 쉬었습니다.

Bedrock 메트릭을 제대로 이해하면 서비스 상태를 정확히 파악하고, 문제를 빠르게 해결할 수 있습니다. 복잡해 보이지만 핵심만 알면 쉽습니다.

실전 팁

💡 - ModelId를 Dimension으로 지정하면 특정 모델의 메트릭만 볼 수 있습니다

에러율은 (에러 횟수 / 총 호출 횟수) * 100으로 계산하여 퍼센티지로 관리하세요
메트릭 이름은 대소문자를 정확히 입력해야 하므로 AWS 문서에서 복사하세요

3. 사용량 대시보드 구성

메트릭을 확인하는 방법을 배운 김개발 씨는 매번 코드를 실행해서 숫자를 확인하는 것이 번거로웠습니다. "매번 이렇게 해야 하나요?" 박시니어 씨가 웃으며 말했습니다.

"대시보드를 만들면 클릭 한 번으로 모든 메트릭을 볼 수 있어요."

CloudWatch 대시보드는 여러 메트릭을 한 화면에 시각화하여 보여주는 도구입니다. 마치 자동차 계기판에 속도계, 연료계, 온도계가 모두 모여 있는 것처럼, 대시보드에는 중요한 메트릭들이 그래프와 숫자로 한눈에 표시됩니다.

코드를 실행할 필요 없이 브라우저에서 실시간으로 확인할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
import json

cloudwatch = boto3.client('cloudwatch', region_name='us-east-1')

# 대시보드 구성 정의
dashboard_body = {
    "widgets": [
        {
            "type": "metric",
            "properties": {
                "metrics": [
                    ["AWS/Bedrock", "Invocations", {"stat": "Sum"}]
                ],
                "period": 300,
                "stat": "Sum",
                "region": "us-east-1",
                "title": "총 호출 횟수",
                "yAxis": {"left": {"min": 0}}
            }
        },
        {
            "type": "metric",
            "properties": {
                "metrics": [
                    ["AWS/Bedrock", "ModelInvocationLatency", {"stat": "Average"}]
                ],
                "period": 300,
                "stat": "Average",
                "region": "us-east-1",
                "title": "평균 응답 시간 (ms)",
                "yAxis": {"left": {"min": 0}}
            }
        },
        {
            "type": "metric",
            "properties": {
                "metrics": [
                    ["AWS/Bedrock", "InvocationClientErrors", {"stat": "Sum"}],
                    [".", "InvocationServerErrors", {"stat": "Sum"}]
                ],
                "period": 300,
                "stat": "Sum",
                "region": "us-east-1",
                "title": "에러 발생 현황"
            }
        }
    ]
}

# 대시보드 생성
response = cloudwatch.put_dashboard(
    DashboardName='BedrockMonitoring',
    DashboardBody=json.dumps(dashboard_body)
)

print("대시보드가 생성되었습니다!")

김개발 씨는 매일 아침 출근하면 파이썬 스크립트를 실행해서 메트릭을 확인했습니다. 숫자가 콘솔에 주르륵 출력되면 엑셀에 복사해서 그래프를 그렸습니다.

30분이나 걸리는 일이었습니다. "이거 너무 불편한데..." 혼잣말을 하던 김개발 씨에게 박시니어 씨가 다가왔습니다.

"대시보드 안 만들었어요? 한 번 만들어 놓으면 브라우저에서 바로 볼 수 있는데." 대시보드란 무엇일까요? 쉽게 비유하자면, 대시보드는 자동차의 계기판과 같습니다.

운전석에 앉으면 속도계, 연료계, 엔진 온도계가 한눈에 보입니다. 운전 중에 일일이 차에서 내려서 연료통을 열어보거나 엔진룸을 확인할 필요가 없습니다.

CloudWatch 대시보드도 마찬가지입니다. 한 화면에 필요한 모든 메트릭이 실시간으로 표시됩니다.

그래프, 숫자, 게이지 등 다양한 형태로 시각화되어 직관적으로 이해할 수 있습니다. 대시보드 없이는 얼마나 불편할까요? 대시보드가 없던 시절, 개발자들은 매번 API를 호출하거나 로그 파일을 열어봐야 했습니다.

메트릭 하나를 확인하려면 여러 단계를 거쳐야 했고, 전체적인 추세를 파악하기도 어려웠습니다. 더 큰 문제는 협업이었습니다.

팀장이 "지금 서비스 상태가 어때요?"라고 물으면, 개발자는 급하게 스크립트를 돌려서 결과를 복사해서 메신저로 보내야 했습니다. 실시간 공유가 불가능했습니다.

대시보드로 모든 것이 간단해집니다 CloudWatch 대시보드를 사용하면 이런 불편함이 모두 사라집니다. 한 번 설정해 놓으면 언제든지 브라우저에서 접속하여 최신 상태를 확인할 수 있습니다.

그래프로 시각화되어 있어 추세를 한눈에 파악할 수 있습니다. 무엇보다 팀원들과 URL을 공유하면 모두가 같은 화면을 볼 수 있다는 점이 큰 장점입니다.

코드로 대시보드 만들기 위의 코드를 단계별로 살펴보겠습니다. 먼저 대시보드의 구조를 JSON 형태로 정의합니다.

widgets 배열에는 화면에 표시할 위젯들이 들어갑니다. 각 위젯은 하나의 그래프나 숫자 패널을 의미합니다.

첫 번째 위젯은 총 호출 횟수를 보여줍니다. metrics 배열에 네임스페이스와 메트릭 이름을 지정하고, title로 그래프 제목을 정합니다.

period는 데이터를 몇 초 단위로 집계할지 결정합니다. 두 번째 위젯은 평균 응답 시간입니다.

여기서는 Sum 대신 Average 통계를 사용합니다. 응답 시간은 합계보다 평균이 더 의미 있기 때문입니다.

세 번째 위젯은 에러 현황입니다. 여러 메트릭을 하나의 그래프에 표시할 수 있습니다.

클라이언트 에러와 서버 에러를 함께 보면 어느 쪽에서 문제가 발생하는지 비교할 수 있습니다. 마지막으로 put_dashboard 메서드로 대시보드를 생성합니다.

DashboardName은 대시보드의 고유 이름이며, DashboardBody는 앞서 정의한 JSON을 문자열로 변환하여 전달합니다. 실무에서의 활용 실제 서비스에서는 대시보드를 어떻게 활용할까요?

금융권에서 AI 기반 사기 탐지 시스템을 운영한다고 가정해봅시다. 보안팀은 24시간 모니터링실에서 대형 모니터에 대시보드를 띄워놓습니다.

평소에는 초록색 정상 상태를 유지하다가, 이상 징후가 감지되면 빨간색 알람이 표시됩니다. 또한 주간 회의에서 대시보드 URL을 공유하면, 모든 팀원이 같은 데이터를 보면서 토론할 수 있습니다.

"지난주 화요일 오후 3시에 트래픽이 급증했네요. 무슨 일이 있었나요?"라고 바로 확인할 수 있습니다.

초보자 주의사항 초보 개발자들이 흔히 하는 실수가 있습니다. 너무 많은 위젯을 한 대시보드에 넣는 것입니다.

화면이 복잡해져서 오히려 핵심을 놓치게 됩니다. 따라서 대시보드는 용도별로 나누는 것이 좋습니다.

운영팀용 대시보드, 개발팀용 대시보드, 경영진용 대시보드처럼 보는 사람에 따라 다르게 구성하세요. 각 대시보드에는 5~10개 정도의 위젯만 배치하는 것이 이상적입니다.

정리 박시니어 씨의 조언대로 대시보드를 만든 김개발 씨는 감탄했습니다. "와, 이제 클릭 한 번이면 모든 게 보이네요!" 대시보드를 제대로 활용하면 업무 효율이 크게 향상됩니다.

매일 반복하던 수작업이 사라지고, 팀 전체가 같은 정보를 공유할 수 있습니다.

실전 팁

💡 - 위젯은 5~10개 정도로 제한하여 화면이 복잡해지지 않도록 하세요

자주 보는 메트릭은 대시보드 상단에 배치하세요
JSON 구조가 복잡하면 AWS 콘솔에서 시각적으로 만든 후 내보내기 기능을 사용하세요

4. 로그 수집 설정

대시보드로 메트릭을 확인하던 김개발 씨는 문득 궁금해졌습니다. "메트릭은 숫자만 보여주는데, 실제 어떤 요청이 들어왔는지는 어떻게 알죠?" 박시니어 씨가 답했습니다.

"그건 로그를 봐야죠. CloudWatch Logs에 모든 요청과 응답이 기록됩니다."

CloudWatch Logs는 AWS 서비스와 애플리케이션에서 발생하는 모든 로그를 수집하고 저장하는 서비스입니다. 마치 블랙박스가 자동차의 모든 주행 기록을 남기는 것처럼, CloudWatch Logs는 Bedrock의 모든 API 호출 내역을 상세히 기록합니다.

어떤 요청이 들어왔는지, 어떤 응답이 나갔는지, 에러가 발생했다면 정확히 어디서 왜 발생했는지 확인할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
import json

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')
logs = boto3.client('logs', region_name='us-east-1')

# 로그 그룹 생성
log_group_name = '/aws/bedrock/invocations'

try:
    logs.create_log_group(logGroupName=log_group_name)
    print(f"로그 그룹 생성: {log_group_name}")
except logs.exceptions.ResourceAlreadyExistsException:
    print(f"로그 그룹이 이미 존재합니다: {log_group_name}")

# 로그 스트림 생성
log_stream_name = 'claude-invocations'
try:
    logs.create_log_stream(
        logGroupName=log_group_name,
        logStreamName=log_stream_name
    )
    print(f"로그 스트림 생성: {log_stream_name}")
except logs.exceptions.ResourceAlreadyExistsException:
    print(f"로그 스트림이 이미 존재합니다: {log_stream_name}")

# Bedrock API 호출 시 로깅
def invoke_with_logging(prompt):
    try:
        response = bedrock.invoke_model(
            modelId='anthropic.claude-3-sonnet-20240229-v1:0',
            body=json.dumps({
                "anthropic_version": "bedrock-2023-05-31",
                "max_tokens": 1024,
                "messages": [{"role": "user", "content": prompt}]
            })
        )

        # 로그 메시지 작성
        log_message = f"SUCCESS: Prompt={prompt[:50]}..."

        # CloudWatch Logs에 기록
        logs.put_log_events(
            logGroupName=log_group_name,
            logStreamName=log_stream_name,
            logEvents=[{
                'timestamp': int(datetime.now().timestamp() * 1000),
                'message': log_message
            }]
        )

        return response
    except Exception as e:
        # 에러 로그 기록
        error_message = f"ERROR: {str(e)}"
        logs.put_log_events(
            logGroupName=log_group_name,
            logStreamName=log_stream_name,
            logEvents=[{
                'timestamp': int(datetime.now().timestamp() * 1000),
                'message': error_message
            }]
        )
        raise

김개발 씨는 대시보드를 보다가 갑자기 에러율이 급증한 것을 발견했습니다. 그런데 메트릭만으로는 왜 에러가 발생했는지 알 수 없었습니다.

"어떤 요청이 에러를 일으켰을까?" 박시니어 씨가 말했습니다. "로그를 확인해 봐야 해요.

메트릭은 '무엇'이 일어났는지 보여주지만, 로그는 '왜' 일어났는지 알려줍니다." CloudWatch Logs란 무엇일까요? 쉽게 비유하자면, CloudWatch Logs는 자동차의 블랙박스와 같습니다. 사고가 났을 때 블랙박스 영상을 보면 정확히 무슨 일이 있었는지 알 수 있습니다.

누가 신호를 위반했는지, 어느 차가 먼저 진입했는지 모든 것이 기록되어 있습니다. CloudWatch Logs도 마찬가지입니다.

Bedrock에 어떤 프롬프트가 입력되었고, 모델이 어떻게 응답했으며, 에러가 발생했다면 정확한 에러 메시지가 무엇인지 모두 기록됩니다. 로그가 없으면 어떤 일이 벌어질까요? 로그 없이 서비스를 운영하는 것은 눈을 감고 운전하는 것과 같습니다.

문제가 발생해도 원인을 파악할 방법이 없습니다. 예를 들어 고객이 "AI 챗봇이 이상한 답변을 했어요"라고 신고했다고 가정해봅시다.

로그가 없다면 고객이 정확히 무엇을 물었고, 챗봇이 무엇을 답했는지 확인할 방법이 없습니다. 재현하려고 해도 같은 상황을 만들기 어렵습니다.

더 심각한 문제는 보안 사고입니다. 누군가 악의적인 프롬프트를 입력했거나, 민감한 정보를 유출하려는 시도가 있었다면 로그에서 추적할 수 있습니다.

하지만 로그가 없다면 사고가 발생한 사실조차 알 수 없습니다. 로그로 모든 것을 추적합니다 CloudWatch Logs를 설정하면 이런 문제가 모두 해결됩니다.

모든 API 호출이 자동으로 기록되므로 나중에 언제든지 검색하여 확인할 수 있습니다. 특정 시간대의 로그만 필터링하거나, 특정 키워드가 포함된 로그만 찾을 수도 있습니다.

무엇보다 장기간 보관할 수 있어 과거 데이터를 분석하는 데도 유용합니다. 코드로 로그 설정하기 위의 코드를 차근차근 살펴보겠습니다.

먼저 로그 그룹을 생성합니다. 로그 그룹은 관련된 로그들을 묶어주는 컨테이너입니다.

Bedrock 관련 로그는 모두 이 그룹에 저장됩니다. 이미 존재하는 경우 예외가 발생하므로 try-except로 처리합니다.

다음으로 로그 스트림을 생성합니다. 로그 스트림은 시간순으로 정렬된 로그 이벤트의 시퀀스입니다.

하나의 로그 그룹 안에 여러 개의 로그 스트림을 만들 수 있습니다. 예를 들어 모델별로 다른 스트림을 사용할 수 있습니다.

가장 중요한 부분은 invoke_with_logging 함수입니다. 이 함수는 Bedrock API를 호출하면서 동시에 로그를 기록합니다.

성공하면 요청 내용을 로그에 남기고, 실패하면 에러 메시지를 기록합니다. put_log_events 메서드로 실제 로그를 전송합니다.

타임스탬프와 메시지를 포함한 로그 이벤트를 배열로 전달합니다. 타임스탬프는 밀리초 단위의 Unix 시간이어야 합니다.

실무 활용 시나리오 실제 서비스에서는 로그를 어떻게 활용할까요? 의료 AI 서비스에서 환자 상담 챗봇을 운영한다고 가정해봅시다.

환자가 "약 부작용이 있어요"라고 입력했는데 챗봇이 엉뚱한 답변을 했다는 신고가 들어왔습니다. 개발자는 CloudWatch Logs에서 해당 환자의 사용자 ID로 검색합니다.

정확한 대화 내용이 모두 기록되어 있어, 어떤 프롬프트가 문제를 일으켰는지 즉시 파악할 수 있습니다. 버그를 수정하고, 유사한 케이스가 또 발생하는지 로그를 계속 모니터링합니다.

주의사항 초보 개발자들이 흔히 하는 실수가 있습니다. 개인정보나 민감한 데이터를 로그에 그대로 남기는 것입니다.

이렇게 하면 정보 유출의 위험이 있습니다. 따라서 로그에 기록하기 전에 마스킹 처리를 해야 합니다.

이메일, 전화번호, 신용카드 번호 같은 민감한 정보는 일부를 가리거나 해시 처리하여 저장하세요. 또한 로그가 너무 많이 쌓이면 비용이 증가합니다.

로그 보존 기간을 설정하여 오래된 로그는 자동으로 삭제되도록 하는 것이 좋습니다. 보통 30일~90일 정도가 적절합니다.

마무리 로그 설정을 마친 김개발 씨는 이제 문제가 발생해도 당황하지 않게 되었습니다. "로그만 보면 무슨 일이 있었는지 다 알 수 있네요!" 로그는 개발자에게 투명한 가시성을 제공합니다.

시스템 내부에서 무슨 일이 일어나는지 모두 볼 수 있게 해줍니다.

실전 팁

💡 - 민감한 정보는 로그에 기록하기 전에 마스킹 처리하세요

로그 보존 기간을 30~90일로 설정하여 비용을 관리하세요
로그 그룹은 서비스별로 분리하여 검색하기 쉽게 만드세요

5. 알람 설정하기

어느 날 새벽 3시, 김개발 씨의 핸드폰이 울렸습니다. 회사 서버에 장애가 발생했다는 긴급 연락이었습니다.

"에러율이 50%를 넘었어요!" 잠에서 깬 김개발 씨는 부랴부랴 노트북을 켰습니다. 다음 날 박시니어 씨가 물었습니다.

"알람 설정 안 했어요? 에러율이 올라가면 자동으로 알려주게 해야죠."

CloudWatch 알람은 메트릭이 설정한 임계값을 넘어섰을 때 자동으로 알림을 보내는 기능입니다. 마치 자동차의 연료 경고등이 기름이 부족하면 켜지는 것처럼, 알람도 문제가 발생하기 전에 미리 경고해줍니다.

이메일, SMS, SNS 토픽 등 다양한 채널로 알림을 받을 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

cloudwatch = boto3.client('cloudwatch', region_name='us-east-1')
sns = boto3.client('sns', region_name='us-east-1')

# SNS 토픽 생성 (알림 채널)
topic_response = sns.create_topic(Name='BedrockAlerts')
topic_arn = topic_response['TopicArn']

# 이메일 구독 설정
sns.subscribe(
    TopicArn=topic_arn,
    Protocol='email',
    Endpoint='devteam@company.com'
)

# 에러율 알람 설정
cloudwatch.put_metric_alarm(
    AlarmName='BedrockHighErrorRate',
    ComparisonOperator='GreaterThanThreshold',
    EvaluationPeriods=2,  # 2회 연속 임계값 초과 시
    MetricName='InvocationClientErrors',
    Namespace='AWS/Bedrock',
    Period=300,  # 5분 단위
    Statistic='Sum',
    Threshold=10,  # 5분간 10건 이상 에러 발생 시
    ActionsEnabled=True,
    AlarmActions=[topic_arn],  # SNS로 알림 전송
    AlarmDescription='Bedrock 클라이언트 에러가 임계값을 초과했습니다',
    Dimensions=[
        {'Name': 'ModelId', 'Value': 'anthropic.claude-3-sonnet-20240229-v1:0'}
    ]
)

# 응답 시간 알람 설정
cloudwatch.put_metric_alarm(
    AlarmName='BedrockSlowResponse',
    ComparisonOperator='GreaterThanThreshold',
    EvaluationPeriods=3,
    MetricName='ModelInvocationLatency',
    Namespace='AWS/Bedrock',
    Period=300,
    Statistic='Average',
    Threshold=5000,  # 평균 5초 이상이면 알람
    ActionsEnabled=True,
    AlarmActions=[topic_arn],
    AlarmDescription='Bedrock 응답 시간이 느려졌습니다'
)

print("알람 설정이 완료되었습니다!")

김개발 씨는 평소처럼 퇴근하여 편안한 저녁 시간을 보내고 있었습니다. 그런데 새벽 3시에 갑자기 전화가 울렸습니다.

팀장이었습니다. "지금 서비스에 장애가 발생했어요.

빨리 확인해 주세요!" 잠에서 깬 김개발 씨는 급하게 노트북을 켜서 대시보드를 확인했습니다. 에러율이 50%를 넘고 있었습니다.

무려 2시간 전부터 시작된 문제였습니다. "왜 진작에 몰랐지?" 다음 날 출근한 김개발 씨에게 박시니어 씨가 물었습니다.

"알람 설정은 안 했어요? 문제가 생기면 자동으로 알려주게 해야죠." CloudWatch 알람이란? 쉽게 비유하자면, CloudWatch 알람은 자동차의 경고등과 같습니다.

연료가 부족하면 주황색 경고등이 켜지고, 엔진 과열이 감지되면 빨간색 경고등이 깜빡입니다. 운전자가 계기판을 계속 쳐다보지 않아도, 문제가 생기면 경고등이 알아서 알려줍니다.

CloudWatch 알람도 마찬가지입니다. 메트릭을 24시간 감시하다가, 설정한 임계값을 넘으면 자동으로 알림을 보냅니다.

개발자가 대시보드를 계속 지켜볼 필요가 없습니다. 알람 없이는 어떤 일이 벌어질까요? 알람 설정을 하지 않으면 심각한 문제를 놓칠 수 있습니다.

김개발 씨처럼 장애가 발생한 지 몇 시간이 지나서야 알게 되는 경우가 많습니다. 고객들은 이미 불편을 겪고 있고, SNS에는 불만이 쏟아집니다.

문제를 빨리 발견했다면 5분 만에 해결할 수 있었는데, 2시간 동안 방치되면서 피해가 눈덩이처럼 커집니다. 더 큰 문제는 비용입니다.

API 호출이 비정상적으로 증가해도 모르고 있다가, 한 달 후 청구서를 보고 경악하는 경우도 있습니다. 알람을 설정했다면 즉시 알고 조치할 수 있었을 것입니다.

알람으로 문제를 미리 예방합니다 CloudWatch 알람을 설정하면 이런 상황을 방지할 수 있습니다. 문제가 발생하는 즉시 알림을 받을 수 있습니다.

이메일, SMS, Slack 등 원하는 채널로 알림을 받도록 설정할 수 있습니다. 심지어 자동으로 복구 작업을 실행하도록 Lambda 함수를 연결할 수도 있습니다.

코드로 알람 설정하기 위의 코드를 단계별로 살펴보겠습니다. 먼저 SNS 토픽을 생성합니다.

SNS는 Simple Notification Service의 약자로, 알림을 전송하는 채널입니다. 토픽을 만들면 고유한 ARN(Amazon Resource Name)이 발급됩니다.

다음으로 이메일 구독을 설정합니다. subscribe 메서드로 특정 이메일 주소가 알림을 받도록 등록합니다.

Protocol을 'email'로 지정하면 이메일로, 'sms'로 지정하면 SMS로 알림이 갑니다. 핵심은 put_metric_alarm 메서드입니다.

여기서 알람의 모든 조건을 정의합니다. ComparisonOperator는 비교 연산자로, 'GreaterThanThreshold'는 임계값보다 크면 알람이 발생한다는 뜻입니다.

EvaluationPeriods는 몇 번 연속으로 임계값을 초과해야 알람을 발생시킬지 정합니다. 1로 설정하면 일시적인 스파이크에도 알람이 울려서 false positive가 많아집니다.

2~3 정도가 적절합니다. Threshold는 실제 임계값입니다.

예를 들어 5분간 에러가 10건 이상 발생하면 알람이 울리도록 설정할 수 있습니다. AlarmActions에는 알람이 발생했을 때 실행할 작업을 지정합니다.

SNS 토픽 ARN을 넣으면 해당 토픽으로 알림이 전송됩니다. 두 번째 알람은 응답 시간을 모니터링합니다.

평균 응답 시간이 5초를 넘으면 알람이 발생합니다. 사용자 경험이 나빠지기 전에 미리 알 수 있습니다.

실무 활용 사례 실제 서비스에서는 알람을 어떻게 활용할까요? 대형 뉴스 포털에서 AI 기사 요약 서비스를 운영한다고 가정해봅시다.

평소에는 분당 100건 정도의 요청이 들어오는데, 갑자기 속보가 터지면 분당 1,000건으로 급증합니다. 알람을 설정해 두면 트래픽 급증을 즉시 감지할 수 있습니다.

온콜 엔지니어에게 자동으로 SMS가 발송되고, 엔지니어는 서버를 스케일 아웃하여 대응합니다. 사용자는 끊김 없는 서비스를 경험합니다.

또한 비용 알람도 중요합니다. 월 예산을 100달러로 설정했는데 80달러에 도달하면 경고 알람을, 95달러에 도달하면 긴급 알람을 발송하도록 설정합니다.

예산 초과를 방지할 수 있습니다. 주의사항 초보 개발자들이 흔히 하는 실수가 있습니다.

너무 민감한 임계값을 설정하는 것입니다. 작은 변동에도 알람이 울리면 알람 피로가 발생합니다.

중요한 알람을 무시하게 되는 위험한 상황입니다. 따라서 임계값은 실제 데이터를 분석하여 적절하게 설정해야 합니다.

평소 에러가 시간당 5건 정도 발생한다면, 임계값을 10건 정도로 설정하는 것이 합리적입니다. 또한 알람 우선순위를 정해야 합니다.

모든 알람을 같은 긴급도로 처리하면 안 됩니다. Critical, High, Medium, Low로 나누고, Critical만 SMS로, 나머지는 이메일로 받는 식으로 구분하세요.

마무리 알람 설정을 마친 김개발 씨는 이제 밤에도 편히 잘 수 있게 되었습니다. "문제가 생기면 바로 알림이 오니까 안심이에요." 알람은 개발자에게 마음의 평화를 줍니다.

24시간 모니터링을 하지 않아도, 알람이 대신 지켜줍니다.

실전 팁

💡 - EvaluationPeriods를 2~3으로 설정하여 false positive를 줄이세요

Critical 알람은 SMS로, 일반 알람은 이메일로 받도록 채널을 분리하세요
임계값은 평소 메트릭의 2배 정도로 설정하는 것이 적절합니다

6. 비용 알람 구성

서비스가 안정화되고 한 달이 지났습니다. 김개발 씨는 AWS 청구서를 확인하다가 깜짝 놀랐습니다.

"왜 이렇게 비용이 많이 나왔지?" 예상했던 금액의 3배가 청구되었습니다. 박시니어 씨가 한숨을 쉬며 말했습니다.

"비용 알람도 설정해야죠. 예산을 넘기 전에 미리 알아야 대응할 수 있어요."

비용 알람은 AWS 사용 비용이 설정한 예산을 초과하면 알림을 보내는 기능입니다. 마치 신용카드의 한도 알림처럼, 지출이 계획을 벗어나면 즉시 경고해줍니다.

AWS Budgets 서비스를 사용하여 월별, 일별 예산을 설정하고, 특정 비율에 도달하면 단계별로 알림을 받을 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

budgets = boto3.client('budgets', region_name='us-east-1')
account_id = boto3.client('sts').get_caller_identity()['Account']

# 월별 예산 설정
budget_response = budgets.create_budget(
    AccountId=account_id,
    Budget={
        'BudgetName': 'BedrockMonthlyBudget',
        'BudgetLimit': {
            'Amount': '100',  # 월 100달러
            'Unit': 'USD'
        },
        'TimeUnit': 'MONTHLY',
        'BudgetType': 'COST',  # 비용 기반 예산
        'CostFilters': {
            'Service': ['Amazon Bedrock']  # Bedrock만 필터링
        }
    },
    NotificationsWithSubscribers=[
        {
            'Notification': {
                'NotificationType': 'ACTUAL',  # 실제 비용 기준
                'ComparisonOperator': 'GREATER_THAN',
                'Threshold': 80,  # 80% 도달 시 알림
                'ThresholdType': 'PERCENTAGE'
            },
            'Subscribers': [
                {
                    'SubscriptionType': 'EMAIL',
                    'Address': 'finance@company.com'
                }
            ]
        },
        {
            'Notification': {
                'NotificationType': 'ACTUAL',
                'ComparisonOperator': 'GREATER_THAN',
                'Threshold': 100,  # 100% 초과 시 긴급 알림
                'ThresholdType': 'PERCENTAGE'
            },
            'Subscribers': [
                {
                    'SubscriptionType': 'EMAIL',
                    'Address': 'devteam@company.com'
                },
                {
                    'SubscriptionType': 'EMAIL',
                    'Address': 'cto@company.com'
                }
            ]
        }
    ]
)

# 예측 기반 알람 추가
budgets.create_budget(
    AccountId=account_id,
    Budget={
        'BudgetName': 'BedrockForecastBudget',
        'BudgetLimit': {
            'Amount': '100',
            'Unit': 'USD'
        },
        'TimeUnit': 'MONTHLY',
        'BudgetType': 'COST'
    },
    NotificationsWithSubscribers=[
        {
            'Notification': {
                'NotificationType': 'FORECASTED',  # 예측 비용 기준
                'ComparisonOperator': 'GREATER_THAN',
                'Threshold': 100,
                'ThresholdType': 'PERCENTAGE'
            },
            'Subscribers': [
                {
                    'SubscriptionType': 'EMAIL',
                    'Address': 'devteam@company.com'
                }
            ]
        }
    ]
)

print("비용 알람이 설정되었습니다!")

김개발 씨는 한 달 동안 열심히 서비스를 운영했습니다. 사용자도 늘어나고, AI 챗봇의 응답 품질도 좋아졌습니다.

모든 것이 순조로웠습니다. 그런데 월말이 되어 AWS 청구서를 확인하는 순간, 김개발 씨의 얼굴이 새하얗게 변했습니다.

"300달러?!" 예상했던 100달러의 3배가 청구되었습니다. 급하게 사용 내역을 확인해 보니, Bedrock API 호출 횟수가 예상보다 훨씬 많았습니다.

어떤 사용자가 봇을 이용해 무한 반복 호출을 한 것이었습니다. 진작에 알았다면 차단했을 텐데, 한 달 후에야 알게 되었습니다.

박시니어 씨가 고개를 저으며 말했습니다. "비용 알람을 꼭 설정해야 해요.

예산의 80%에 도달하면 경고를 받고, 100%를 넘으면 긴급 알림을 받도록 설정하는 거죠." 비용 알람이란? 쉽게 비유하자면, 비용 알람은 신용카드의 한도 알림과 같습니다. 신용카드로 쇼핑하다 보면 한도의 80%를 넘으면 문자가 옵니다.

"사용 한도의 80%를 초과했습니다." 이 알림 덕분에 한도를 넘기 전에 멈출 수 있습니다. AWS Budgets도 마찬가지입니다.

월 예산을 100달러로 설정하면, 80달러에 도달했을 때 경고 알림을, 100달러를 넘으면 긴급 알림을 보냅니다. 심지어 예측 기능도 있어서, 현재 추세로 가면 예산을 초과할 것으로 예상되면 미리 알려줍니다.

비용 알람 없이는 어떤 일이 벌어질까요? 비용 알람을 설정하지 않으면 김개발 씨처럼 청구서 폭탄을 맞을 수 있습니다. 클라우드 서비스는 사용한 만큼 과금되므로, 비정상적인 사용이 발생해도 모르고 지나갑니다.

실제로 많은 스타트업이 이런 문제로 어려움을 겪습니다. 개발자가 테스트하면서 대용량 데이터를 실수로 무한 루프로 처리했는데, 몇 시간 만에 수천 달러가 청구된 사례도 있습니다.

더 큰 문제는 회사의 재무 계획이 틀어진다는 것입니다. 월 예산을 100달러로 잡았는데 300달러가 청구되면, 다른 곳에 쓸 예산이 줄어듭니다.

심한 경우 서비스를 중단해야 할 수도 있습니다. 비용 알람으로 예산을 지킵니다 AWS Budgets를 설정하면 이런 위험을 막을 수 있습니다.

실시간으로 비용을 추적하며, 설정한 임계값에 도달하면 즉시 알림을 보냅니다. 단계별 알림을 설정할 수 있어서, 80%에서는 "주의하세요", 100%에서는 "즉시 조치 필요" 같은 메시지를 구분하여 받을 수 있습니다.

코드로 비용 알람 설정하기 위의 코드를 자세히 살펴보겠습니다. 먼저 AWS Budgets 클라이언트를 생성합니다.

그리고 현재 AWS 계정 ID를 가져옵니다. Budgets는 계정 단위로 관리되므로 계정 ID가 필요합니다.

create_budget 메서드로 예산을 생성합니다. BudgetName은 예산의 이름이고, BudgetLimit에 금액과 통화 단위를 지정합니다.

TimeUnit을 'MONTHLY'로 설정하면 월별 예산이 됩니다. CostFilters는 특정 서비스만 필터링할 때 사용합니다.

여기서는 Bedrock만 모니터링하도록 설정했습니다. 이렇게 하면 다른 AWS 서비스 비용은 제외되고 Bedrock 비용만 추적됩니다.

NotificationsWithSubscribers에서 알림 조건을 정의합니다. 첫 번째 알림은 Threshold가 80입니다.

즉, 예산의 80%에 도달하면 알림이 발송됩니다. ThresholdType을 'PERCENTAGE'로 설정하여 퍼센티지 기준으로 계산합니다.

두 번째 알림은 100%를 초과했을 때 발송됩니다. 이때는 개발팀뿐만 아니라 CTO에게도 알림이 가도록 여러 명의 구독자를 추가했습니다.

FORECASTED 알림은 특히 유용합니다. 현재 사용 추세를 분석하여, 이대로 가면 월말에 예산을 초과할 것으로 예측되면 미리 알려줍니다.

아직 100%에 도달하지 않았어도 예방 조치를 취할 수 있습니다. 실무 시나리오 실제 서비스에서는 어떻게 활용할까요?

스타트업에서 AI 기반 번역 서비스를 운영한다고 가정해봅시다. 투자 유치 전이라 예산이 빠듯합니다.

월 예산을 200달러로 정하고, 80%(160달러)에 도달하면 개발팀에 알림이 갑니다. 개발팀은 알림을 받고 즉시 대응합니다.

캐싱을 적극 활용하고, 불필요한 API 호출을 줄이는 최적화를 진행합니다. 덕분에 예산 내에서 서비스를 운영할 수 있습니다.

만약 알람이 없었다면? 월말에 400달러 청구서를 받고 회사 운영에 타격을 입었을 것입니다.

주의사항 초보 개발자들이 흔히 하는 실수가 있습니다. 예산을 너무 빡빡하게 잡는 것입니다.

예를 들어 평소 90달러가 나오는데 예산을 100달러로 설정하면, 조금만 사용량이 늘어도 매번 알람이 울립니다. 따라서 예산은 평소 사용량의 150% 정도로 설정하는 것이 좋습니다.

여유를 두어야 정상적인 성장과 비정상적인 스파이크를 구분할 수 있습니다. 또한 여러 단계의 알람을 설정하세요.

80%, 90%, 100%, 120% 같은 식으로 단계를 나누면, 심각도에 따라 다르게 대응할 수 있습니다. 정리하며 비용 알람을 설정한 김개발 씨는 이제 청구서를 두려워하지 않게 되었습니다.

"80% 알림이 오면 바로 최적화하면 되니까 안심이에요." 비용 알람은 재무 안정성을 보장합니다. 클라우드를 안심하고 사용할 수 있게 해주는 안전장치입니다.

실전 팁

💡 - 예산은 평소 사용량의 150% 정도로 여유 있게 설정하세요

80%, 100%, 120% 같은 여러 단계의 알람을 설정하여 단계별 대응하세요
FORECASTED 알림을 활용하여 예산 초과를 사전에 예방하세요

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

#AWS#CloudWatch#Bedrock#Monitoring#Logging

AWS Bedrock 모니터링과 로깅 완벽 가이드

# AWS Bedrock 모니터링과 로깅 완벽 가이드 CloudWatch를 활용하여 AWS Bedrock 서비스의 메트릭을 실시간으로 모니터링하고, 사용량 대시보드를 구성하며, 비용 알람까지 설정하는 방법을 초급 개발자를 위해 단계별로 안내합니다. --- ## 목차 1. [CloudWatch_기초](#cloudwatch-기초) 2. [Bedrock_메트릭_확인](#bedrock-메트릭-확인) 3. [사용량_대시보드_구성](#사용량-대시보드-구성) 4. [로그_수집_설정](#로그-수집-설정) 5. [알람_설정하기](#알람-설정하기) 6. [비용_알람_구성](#비용-알람-구성) --- ## 1. CloudWatch_기초 어느 날 김개발 씨는 회사에서 AWS Bedrock을 활용한 AI 챗봇 서비스를 운영하게 되었습니다. 서비스를 배포한 첫날, 갑자기 사용자가 몰려들었는데 시스템이 어떻게 동작하는지 전혀 알 수가 없었습니다. 선배 박시니어 씨가 다가와서 물었습니다. "CloudWatch는 설정했어요?" **CloudWatch**는 AWS의 모니터링 및 관찰 서비스입니다. 마치 자동차의 계기판이 속도, 연료, 엔진 상태를 실시간으로 보여주는 것처럼, CloudWatch는 AWS 리소스의 상태를 한눈에 파악할 수 있게 해줍니다. Bedrock을 포함한 모든 AWS 서비스의 메트릭을 수집하고, 로그를 저장하며, 알람을 설정할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 from datetime import datetime, timedelta # CloudWatch 클라이언트 생성 cloudwatch = boto3.client('cloudwatch', region_name='us-east-1') # 최근 1시간 동안의 메트릭 조회 end_time = datetime.utcnow() start_time = end_time - timedelta(hours=1) # Bedrock 호출 횟수 메트릭 가져오기 response = cloudwatch.get_metric_statistics( Namespace='AWS/Bedrock', # Bedrock 네임스페이스 MetricName='Invocations', # 호출 횟수 메트릭 StartTime=start_time, EndTime=end_time, Period=300, # 5분 단위로 집계 Statistics=['Sum'] # 합계 통계 ) print(f"총 호출 횟수: {sum([point['Sum'] for point in response['Datapoints']])}") ``` 김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 AWS Bedrock을 활용한 고객 상담 AI 챗봇을 개발하여 배포했습니다. 런칭 첫날, 예상보다 훨씬 많은 사용자가 몰려들었고, 김개발 씨는 불안해지기 시작했습니다. "지금 몇 명이나 사용하고 있는 걸까? 시스템은 정상인가? 비용은 얼마나 나오고 있지?" 머릿속에 온갖 걱정이 떠올랐지만, 확인할 방법이 없었습니다. 바로 그때 선배 박시니어 씨가 김개발 씨의 모니터를 보더니 물었습니다. "CloudWatch 대시보드는 만들어 놨어요? 지금 서비스 상태를 어떻게 알고 계세요?" **CloudWatch란 무엇일까요?** 쉽게 비유하자면, CloudWatch는 자동차의 계기판과 같습니다. 운전할 때 계기판을 보면 현재 속도, 남은 연료, 엔진 온도 등을 한눈에 파악할 수 있습니다. 계기판이 없다면? 차가 얼마나 빨리 가는지, 언제 기름을 넣어야 하는지 알 수 없어 위험합니다. 이처럼 CloudWatch도 AWS 서비스의 상태를 실시간으로 보여주는 계기판입니다. CPU 사용률, 메모리 사용량, API 호출 횟수, 에러 발생 건수 등 다양한 지표를 수집하고 시각화합니다. **CloudWatch 없이는 어떤 문제가 생길까요?** 과거 클라우드 초창기에는 모니터링 도구가 제대로 갖춰지지 않았습니다. 개발자들은 서버에 직접 접속해서 로그 파일을 일일이 확인해야 했습니다. 시스템에 문제가 생겨도 사용자가 먼저 불만을 제기할 때까지 알 수 없었습니다. 더 큰 문제는 예상치 못한 비용 폭탄이었습니다. API 호출이 비정상적으로 증가해도 청구서를 받기 전까지는 알 수 없었습니다. 한 달 후 받은 청구서를 보고 경악하는 일이 비일비재했습니다. **CloudWatch로 해결하는 방법** 바로 이런 문제를 해결하기 위해 AWS는 CloudWatch를 제공합니다. CloudWatch를 사용하면 실시간으로 서비스 상태를 파악할 수 있습니다. 또한 임계값을 설정하여 문제가 발생하기 전에 미리 알림을 받을 수 있습니다. 무엇보다 비용 폭탄을 방지할 수 있다는 큰 이점이 있습니다. **코드로 CloudWatch 활용하기** 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 boto3 라이브러리로 CloudWatch 클라이언트를 생성합니다. 이것이 CloudWatch와 통신하는 핵심 객체입니다. 다음으로 조회할 시간 범위를 설정합니다. 최근 1시간 동안의 데이터를 가져오기 위해 현재 시각에서 1시간을 뺀 값을 계산합니다. 가장 중요한 부분은 **get_metric_statistics** 메서드입니다. 여기서 Namespace는 어떤 AWS 서비스의 메트릭인지 지정하고, MetricName은 구체적으로 어떤 지표를 볼 것인지 정합니다. Period는 데이터를 몇 초 단위로 집계할지 결정하며, Statistics는 합계, 평균, 최댓값 등 어떤 통계값을 볼 것인지 정합니다. **실무에서 어떻게 활용할까요?** 실제 현업에서는 어떻게 활용할까요? 예를 들어 온라인 쇼핑몰에서 AI 상품 추천 서비스를 운영한다고 가정해봅시다. 블랙프라이데이 같은 대규모 이벤트 기간에는 평소보다 10배 이상 트래픽이 몰립니다. 이때 CloudWatch로 실시간 호출 횟수를 모니터링하면 시스템 확장 시점을 정확히 판단할 수 있습니다. 또한 특정 시간대에 에러율이 급증하면 즉시 알람을 받아 대응할 수 있습니다. **초보자가 흔히 하는 실수** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 많은 메트릭을 한꺼번에 수집하려는 것입니다. 이렇게 하면 정작 중요한 지표를 놓치게 되고, 비용도 불필요하게 증가합니다. 따라서 처음에는 **핵심 메트릭** 몇 가지만 선택해서 모니터링하는 것이 좋습니다. Bedrock의 경우 호출 횟수, 응답 시간, 에러율 정도면 충분합니다. **정리하며** 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 "아, 그래서 CloudWatch가 필요했군요!"라고 고개를 끄덕였습니다. CloudWatch를 제대로 이해하면 서비스를 안정적으로 운영하고, 문제를 사전에 예방할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - 처음에는 호출 횟수, 에러율, 응답 시간 등 핵심 메트릭 3-5개만 모니터링하세요 - 메트릭 조회 시 Period를 너무 짧게 설정하면 비용이 증가하니 주의하세요 - CloudWatch 대시보드를 만들어 한 화면에서 여러 메트릭을 동시에 확인하세요 --- ## 2. Bedrock_메트릭_확인 CloudWatch의 중요성을 깨달은 김개발 씨는 바로 Bedrock 메트릭을 확인하기 시작했습니다. 그런데 막상 CloudWatch 콘솔을 열어보니 수백 개의 메트릭이 나열되어 있었습니다. "어떤 메트릭을 봐야 하는 거지?" 김개발 씨는 다시 박시니어 씨에게 물었습니다. **Bedrock 메트릭**은 AI 모델 호출과 관련된 핵심 지표들입니다. 마치 병원에서 환자의 혈압, 맥박, 체온을 측정하는 것처럼, Bedrock의 건강 상태를 나타내는 바이탈 사인입니다. 주요 메트릭으로는 Invocations(호출 횟수), ModelInvocationLatency(응답 시간), InvocationClientErrors(클라이언트 에러), InvocationServerErrors(서버 에러) 등이 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 from datetime import datetime, timedelta cloudwatch = boto3.client('cloudwatch', region_name='us-east-1') # 조회 시간 설정 (최근 24시간) end_time = datetime.utcnow() start_time = end_time - timedelta(hours=24) # 주요 Bedrock 메트릭 리스트 metrics = [ 'Invocations', # 총 호출 횟수 'InvocationClientErrors', # 클라이언트 에러 횟수 'InvocationServerErrors', # 서버 에러 횟수 ] # 각 메트릭별로 데이터 수집 for metric_name in metrics: response = cloudwatch.get_metric_statistics( Namespace='AWS/Bedrock', MetricName=metric_name, Dimensions=[ {'Name': 'ModelId', 'Value': 'anthropic.claude-3-sonnet-20240229-v1:0'} ], StartTime=start_time, EndTime=end_time, Period=3600, # 1시간 단위 Statistics=['Sum', 'Average'] ) total = sum([point['Sum'] for point in response['Datapoints']]) print(f"{metric_name}: {total}") ``` 김개발 씨가 CloudWatch 콘솔을 열어보니 화면 가득 메트릭 이름들이 나열되어 있었습니다. "이게 다 뭐지?" 어떤 것부터 봐야 할지 막막했습니다. 박시니어 씨가 옆에 앉으며 설명을 시작했습니다. "Bedrock 메트릭은 크게 네 가지만 알면 됩니다. 호출 횟수, 응답 시간, 클라이언트 에러, 서버 에러죠." **Bedrock 메트릭이란?** 쉽게 비유하자면, Bedrock 메트릭은 병원에서 측정하는 바이탈 사인과 같습니다. 의사가 환자를 진찰할 때 혈압, 맥박, 체온, 호흡수를 먼저 확인하는 것처럼, Bedrock의 상태를 파악할 때도 핵심 지표 몇 가지만 보면 전체적인 건강 상태를 알 수 있습니다. 메트릭이 수백 개나 있다고 해서 모든 것을 볼 필요는 없습니다. 정말 중요한 몇 가지만 집중적으로 모니터링하면 됩니다. **메트릭을 모르면 어떤 문제가 생길까요?** 메트릭을 제대로 확인하지 않으면 심각한 문제를 놓칠 수 있습니다. 예를 들어 에러율이 30%까지 치솟았는데도 모르고 있다가 고객 불만이 쏟아진 후에야 알게 되는 경우가 있습니다. 또한 응답 시간이 점점 느려지고 있다는 신호를 놓치면, 사용자 경험이 계속 나빠집니다. 사용자들은 느린 서비스를 참지 못하고 이탈하기 시작합니다. 문제를 조기에 발견했다면 간단히 해결할 수 있었을 텐데, 너무 늦게 알아차려서 대규모 장애로 번진 사례도 많습니다. **핵심 메트릭 네 가지** 바로 이런 문제를 방지하기 위해 핵심 메트릭을 모니터링해야 합니다. 첫 번째는 **Invocations**입니다. 이것은 AI 모델이 몇 번 호출되었는지 보여줍니다. 트래픽 추세를 파악할 수 있어 용량 계획을 세울 때 필수적입니다. 두 번째는 **ModelInvocationLatency**입니다. 모델이 응답하는 데 걸리는 시간을 측정합니다. 응답 시간이 길어지면 사용자 경험이 나빠지므로 반드시 추적해야 합니다. 세 번째는 **InvocationClientErrors**입니다. 클라이언트 측에서 발생한 에러 횟수입니다. 주로 잘못된 요청 형식이나 권한 문제로 발생하며, 코드 수정이 필요한 신호입니다. 네 번째는 **InvocationServerErrors**입니다. AWS Bedrock 서비스 측에서 발생한 에러입니다. 이 수치가 높으면 AWS 서비스 상태를 확인하고 지원팀에 문의해야 할 수 있습니다. **코드 상세 분석** 위의 코드를 살펴보겠습니다. 먼저 조회할 시간 범위를 24시간으로 설정합니다. 하루 동안의 추세를 보면 패턴을 파악하기 좋습니다. 다음으로 확인할 메트릭 이름을 리스트로 정의합니다. 핵심은 **Dimensions** 파라미터입니다. 이것은 특정 모델의 메트릭만 필터링할 때 사용합니다. 예를 들어 Claude 3 Sonnet 모델의 메트릭만 보고 싶다면 ModelId를 지정하면 됩니다. 반복문을 돌면서 각 메트릭의 합계를 계산하고 출력합니다. 이렇게 하면 한눈에 전체 호출 횟수와 에러 건수를 파악할 수 있습니다. **실무 활용 사례** 실제 서비스에서는 이 메트릭들을 어떻게 활용할까요? 대형 이커머스 회사에서 고객 문의 응대 AI를 운영한다고 가정해봅시다. 평소에는 시간당 1,000건 정도의 호출이 발생합니다. 그런데 갑자기 3,000건으로 급증했다면? 이것은 마케팅 이벤트가 시작되었거나, 서비스에 문제가 생겨서 사용자들이 몰려들고 있다는 신호일 수 있습니다. 또한 InvocationClientErrors가 평소보다 10배 증가했다면, 최근에 배포한 코드에 버그가 있을 가능성이 높습니다. 즉시 롤백을 고려해야 합니다. **주의해야 할 함정** 초보 개발자들이 흔히 하는 실수가 있습니다. 메트릭 이름을 잘못 입력하는 것입니다. 'Invocation'과 'Invocations'는 다릅니다. 's'가 없으면 데이터가 조회되지 않습니다. 또한 Dimensions를 잘못 설정하면 원하는 데이터가 나오지 않습니다. ModelId 값은 정확한 모델 식별자를 입력해야 합니다. AWS 콘솔에서 복사해서 사용하는 것이 안전합니다. **마무리** 박시니어 씨의 설명을 들은 김개발 씨는 "네 가지만 집중하면 되는군요!"라고 안도의 한숨을 쉬었습니다. Bedrock 메트릭을 제대로 이해하면 서비스 상태를 정확히 파악하고, 문제를 빠르게 해결할 수 있습니다. 복잡해 보이지만 핵심만 알면 쉽습니다. **실전 팁** 💡 - ModelId를 Dimension으로 지정하면 특정 모델의 메트릭만 볼 수 있습니다 - 에러율은 (에러 횟수 / 총 호출 횟수) * 100으로 계산하여 퍼센티지로 관리하세요 - 메트릭 이름은 대소문자를 정확히 입력해야 하므로 AWS 문서에서 복사하세요 --- ## 3. 사용량_대시보드_구성 메트릭을 확인하는 방법을 배운 김개발 씨는 매번 코드를 실행해서 숫자를 확인하는 것이 번거로웠습니다. "매번 이렇게 해야 하나요?" 박시니어 씨가 웃으며 말했습니다. "대시보드를 만들면 클릭 한 번으로 모든 메트릭을 볼 수 있어요." **CloudWatch 대시보드**는 여러 메트릭을 한 화면에 시각화하여 보여주는 도구입니다. 마치 자동차 계기판에 속도계, 연료계, 온도계가 모두 모여 있는 것처럼, 대시보드에는 중요한 메트릭들이 그래프와 숫자로 한눈에 표시됩니다. 코드를 실행할 필요 없이 브라우저에서 실시간으로 확인할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 import json cloudwatch = boto3.client('cloudwatch', region_name='us-east-1') # 대시보드 구성 정의 dashboard_body = { "widgets": [ { "type": "metric", "properties": { "metrics": [ ["AWS/Bedrock", "Invocations", {"stat": "Sum"}] ], "period": 300, "stat": "Sum", "region": "us-east-1", "title": "총 호출 횟수", "yAxis": {"left": {"min": 0}} } }, { "type": "metric", "properties": { "metrics": [ ["AWS/Bedrock", "ModelInvocationLatency", {"stat": "Average"}] ], "period": 300, "stat": "Average", "region": "us-east-1", "title": "평균 응답 시간 (ms)", "yAxis": {"left": {"min": 0}} } }, { "type": "metric", "properties": { "metrics": [ ["AWS/Bedrock", "InvocationClientErrors", {"stat": "Sum"}], [".", "InvocationServerErrors", {"stat": "Sum"}] ], "period": 300, "stat": "Sum", "region": "us-east-1", "title": "에러 발생 현황" } } ] } # 대시보드 생성 response = cloudwatch.put_dashboard( DashboardName='BedrockMonitoring', DashboardBody=json.dumps(dashboard_body) ) print("대시보드가 생성되었습니다!") ``` 김개발 씨는 매일 아침 출근하면 파이썬 스크립트를 실행해서 메트릭을 확인했습니다. 숫자가 콘솔에 주르륵 출력되면 엑셀에 복사해서 그래프를 그렸습니다. 30분이나 걸리는 일이었습니다. "이거 너무 불편한데..." 혼잣말을 하던 김개발 씨에게 박시니어 씨가 다가왔습니다. "대시보드 안 만들었어요? 한 번 만들어 놓으면 브라우저에서 바로 볼 수 있는데." **대시보드란 무엇일까요?** 쉽게 비유하자면, 대시보드는 자동차의 계기판과 같습니다. 운전석에 앉으면 속도계, 연료계, 엔진 온도계가 한눈에 보입니다. 운전 중에 일일이 차에서 내려서 연료통을 열어보거나 엔진룸을 확인할 필요가 없습니다. CloudWatch 대시보드도 마찬가지입니다. 한 화면에 필요한 모든 메트릭이 실시간으로 표시됩니다. 그래프, 숫자, 게이지 등 다양한 형태로 시각화되어 직관적으로 이해할 수 있습니다. **대시보드 없이는 얼마나 불편할까요?** 대시보드가 없던 시절, 개발자들은 매번 API를 호출하거나 로그 파일을 열어봐야 했습니다. 메트릭 하나를 확인하려면 여러 단계를 거쳐야 했고, 전체적인 추세를 파악하기도 어려웠습니다. 더 큰 문제는 협업이었습니다. 팀장이 "지금 서비스 상태가 어때요?"라고 물으면, 개발자는 급하게 스크립트를 돌려서 결과를 복사해서 메신저로 보내야 했습니다. 실시간 공유가 불가능했습니다. **대시보드로 모든 것이 간단해집니다** CloudWatch 대시보드를 사용하면 이런 불편함이 모두 사라집니다. 한 번 설정해 놓으면 언제든지 브라우저에서 접속하여 최신 상태를 확인할 수 있습니다. 그래프로 시각화되어 있어 추세를 한눈에 파악할 수 있습니다. 무엇보다 팀원들과 URL을 공유하면 모두가 같은 화면을 볼 수 있다는 점이 큰 장점입니다. **코드로 대시보드 만들기** 위의 코드를 단계별로 살펴보겠습니다. 먼저 대시보드의 구조를 JSON 형태로 정의합니다. **widgets** 배열에는 화면에 표시할 위젯들이 들어갑니다. 각 위젯은 하나의 그래프나 숫자 패널을 의미합니다. 첫 번째 위젯은 총 호출 횟수를 보여줍니다. **metrics** 배열에 네임스페이스와 메트릭 이름을 지정하고, **title**로 그래프 제목을 정합니다. **period**는 데이터를 몇 초 단위로 집계할지 결정합니다. 두 번째 위젯은 평균 응답 시간입니다. 여기서는 Sum 대신 Average 통계를 사용합니다. 응답 시간은 합계보다 평균이 더 의미 있기 때문입니다. 세 번째 위젯은 에러 현황입니다. 여러 메트릭을 하나의 그래프에 표시할 수 있습니다. 클라이언트 에러와 서버 에러를 함께 보면 어느 쪽에서 문제가 발생하는지 비교할 수 있습니다. 마지막으로 **put_dashboard** 메서드로 대시보드를 생성합니다. DashboardName은 대시보드의 고유 이름이며, DashboardBody는 앞서 정의한 JSON을 문자열로 변환하여 전달합니다. **실무에서의 활용** 실제 서비스에서는 대시보드를 어떻게 활용할까요? 금융권에서 AI 기반 사기 탐지 시스템을 운영한다고 가정해봅시다. 보안팀은 24시간 모니터링실에서 대형 모니터에 대시보드를 띄워놓습니다. 평소에는 초록색 정상 상태를 유지하다가, 이상 징후가 감지되면 빨간색 알람이 표시됩니다. 또한 주간 회의에서 대시보드 URL을 공유하면, 모든 팀원이 같은 데이터를 보면서 토론할 수 있습니다. "지난주 화요일 오후 3시에 트래픽이 급증했네요. 무슨 일이 있었나요?"라고 바로 확인할 수 있습니다. **초보자 주의사항** 초보 개발자들이 흔히 하는 실수가 있습니다. 너무 많은 위젯을 한 대시보드에 넣는 것입니다. 화면이 복잡해져서 오히려 핵심을 놓치게 됩니다. 따라서 대시보드는 용도별로 나누는 것이 좋습니다. 운영팀용 대시보드, 개발팀용 대시보드, 경영진용 대시보드처럼 보는 사람에 따라 다르게 구성하세요. 각 대시보드에는 5~10개 정도의 위젯만 배치하는 것이 이상적입니다. **정리** 박시니어 씨의 조언대로 대시보드를 만든 김개발 씨는 감탄했습니다. "와, 이제 클릭 한 번이면 모든 게 보이네요!" 대시보드를 제대로 활용하면 업무 효율이 크게 향상됩니다. 매일 반복하던 수작업이 사라지고, 팀 전체가 같은 정보를 공유할 수 있습니다. **실전 팁** 💡 - 위젯은 5~10개 정도로 제한하여 화면이 복잡해지지 않도록 하세요 - 자주 보는 메트릭은 대시보드 상단에 배치하세요 - JSON 구조가 복잡하면 AWS 콘솔에서 시각적으로 만든 후 내보내기 기능을 사용하세요 --- ## 4. 로그_수집_설정 대시보드로 메트릭을 확인하던 김개발 씨는 문득 궁금해졌습니다. "메트릭은 숫자만 보여주는데, 실제 어떤 요청이 들어왔는지는 어떻게 알죠?" 박시니어 씨가 답했습니다. "그건 로그를 봐야죠. CloudWatch Logs에 모든 요청과 응답이 기록됩니다." **CloudWatch Logs**는 AWS 서비스와 애플리케이션에서 발생하는 모든 로그를 수집하고 저장하는 서비스입니다. 마치 블랙박스가 자동차의 모든 주행 기록을 남기는 것처럼, CloudWatch Logs는 Bedrock의 모든 API 호출 내역을 상세히 기록합니다. 어떤 요청이 들어왔는지, 어떤 응답이 나갔는지, 에러가 발생했다면 정확히 어디서 왜 발생했는지 확인할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 import json bedrock = boto3.client('bedrock-runtime', region_name='us-east-1') logs = boto3.client('logs', region_name='us-east-1') # 로그 그룹 생성 log_group_name = '/aws/bedrock/invocations' try: logs.create_log_group(logGroupName=log_group_name) print(f"로그 그룹 생성: {log_group_name}") except logs.exceptions.ResourceAlreadyExistsException: print(f"로그 그룹이 이미 존재합니다: {log_group_name}") # 로그 스트림 생성 log_stream_name = 'claude-invocations' try: logs.create_log_stream( logGroupName=log_group_name, logStreamName=log_stream_name ) print(f"로그 스트림 생성: {log_stream_name}") except logs.exceptions.ResourceAlreadyExistsException: print(f"로그 스트림이 이미 존재합니다: {log_stream_name}") # Bedrock API 호출 시 로깅 def invoke_with_logging(prompt): try: response = bedrock.invoke_model( modelId='anthropic.claude-3-sonnet-20240229-v1:0', body=json.dumps({ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024, "messages": [{"role": "user", "content": prompt}] }) ) # 로그 메시지 작성 log_message = f"SUCCESS: Prompt={prompt[:50]}..." # CloudWatch Logs에 기록 logs.put_log_events( logGroupName=log_group_name, logStreamName=log_stream_name, logEvents=[{ 'timestamp': int(datetime.now().timestamp() * 1000), 'message': log_message }] ) return response except Exception as e: # 에러 로그 기록 error_message = f"ERROR: {str(e)}" logs.put_log_events( logGroupName=log_group_name, logStreamName=log_stream_name, logEvents=[{ 'timestamp': int(datetime.now().timestamp() * 1000), 'message': error_message }] ) raise ``` 김개발 씨는 대시보드를 보다가 갑자기 에러율이 급증한 것을 발견했습니다. 그런데 메트릭만으로는 왜 에러가 발생했는지 알 수 없었습니다. "어떤 요청이 에러를 일으켰을까?" 박시니어 씨가 말했습니다. "로그를 확인해 봐야 해요. 메트릭은 '무엇'이 일어났는지 보여주지만, 로그는 '왜' 일어났는지 알려줍니다." **CloudWatch Logs란 무엇일까요?** 쉽게 비유하자면, CloudWatch Logs는 자동차의 블랙박스와 같습니다. 사고가 났을 때 블랙박스 영상을 보면 정확히 무슨 일이 있었는지 알 수 있습니다. 누가 신호를 위반했는지, 어느 차가 먼저 진입했는지 모든 것이 기록되어 있습니다. CloudWatch Logs도 마찬가지입니다. Bedrock에 어떤 프롬프트가 입력되었고, 모델이 어떻게 응답했으며, 에러가 발생했다면 정확한 에러 메시지가 무엇인지 모두 기록됩니다. **로그가 없으면 어떤 일이 벌어질까요?** 로그 없이 서비스를 운영하는 것은 눈을 감고 운전하는 것과 같습니다. 문제가 발생해도 원인을 파악할 방법이 없습니다. 예를 들어 고객이 "AI 챗봇이 이상한 답변을 했어요"라고 신고했다고 가정해봅시다. 로그가 없다면 고객이 정확히 무엇을 물었고, 챗봇이 무엇을 답했는지 확인할 방법이 없습니다. 재현하려고 해도 같은 상황을 만들기 어렵습니다. 더 심각한 문제는 보안 사고입니다. 누군가 악의적인 프롬프트를 입력했거나, 민감한 정보를 유출하려는 시도가 있었다면 로그에서 추적할 수 있습니다. 하지만 로그가 없다면 사고가 발생한 사실조차 알 수 없습니다. **로그로 모든 것을 추적합니다** CloudWatch Logs를 설정하면 이런 문제가 모두 해결됩니다. 모든 API 호출이 자동으로 기록되므로 나중에 언제든지 검색하여 확인할 수 있습니다. 특정 시간대의 로그만 필터링하거나, 특정 키워드가 포함된 로그만 찾을 수도 있습니다. 무엇보다 장기간 보관할 수 있어 과거 데이터를 분석하는 데도 유용합니다. **코드로 로그 설정하기** 위의 코드를 차근차근 살펴보겠습니다. 먼저 **로그 그룹**을 생성합니다. 로그 그룹은 관련된 로그들을 묶어주는 컨테이너입니다. Bedrock 관련 로그는 모두 이 그룹에 저장됩니다. 이미 존재하는 경우 예외가 발생하므로 try-except로 처리합니다. 다음으로 **로그 스트림**을 생성합니다. 로그 스트림은 시간순으로 정렬된 로그 이벤트의 시퀀스입니다. 하나의 로그 그룹 안에 여러 개의 로그 스트림을 만들 수 있습니다. 예를 들어 모델별로 다른 스트림을 사용할 수 있습니다. 가장 중요한 부분은 **invoke_with_logging** 함수입니다. 이 함수는 Bedrock API를 호출하면서 동시에 로그를 기록합니다. 성공하면 요청 내용을 로그에 남기고, 실패하면 에러 메시지를 기록합니다. **put_log_events** 메서드로 실제 로그를 전송합니다. 타임스탬프와 메시지를 포함한 로그 이벤트를 배열로 전달합니다. 타임스탬프는 밀리초 단위의 Unix 시간이어야 합니다. **실무 활용 시나리오** 실제 서비스에서는 로그를 어떻게 활용할까요? 의료 AI 서비스에서 환자 상담 챗봇을 운영한다고 가정해봅시다. 환자가 "약 부작용이 있어요"라고 입력했는데 챗봇이 엉뚱한 답변을 했다는 신고가 들어왔습니다. 개발자는 CloudWatch Logs에서 해당 환자의 사용자 ID로 검색합니다. 정확한 대화 내용이 모두 기록되어 있어, 어떤 프롬프트가 문제를 일으켰는지 즉시 파악할 수 있습니다. 버그를 수정하고, 유사한 케이스가 또 발생하는지 로그를 계속 모니터링합니다. **주의사항** 초보 개발자들이 흔히 하는 실수가 있습니다. 개인정보나 민감한 데이터를 로그에 그대로 남기는 것입니다. 이렇게 하면 정보 유출의 위험이 있습니다. 따라서 로그에 기록하기 전에 **마스킹** 처리를 해야 합니다. 이메일, 전화번호, 신용카드 번호 같은 민감한 정보는 일부를 가리거나 해시 처리하여 저장하세요. 또한 로그가 너무 많이 쌓이면 비용이 증가합니다. **로그 보존 기간**을 설정하여 오래된 로그는 자동으로 삭제되도록 하는 것이 좋습니다. 보통 30일~90일 정도가 적절합니다. **마무리** 로그 설정을 마친 김개발 씨는 이제 문제가 발생해도 당황하지 않게 되었습니다. "로그만 보면 무슨 일이 있었는지 다 알 수 있네요!" 로그는 개발자에게 투명한 가시성을 제공합니다. 시스템 내부에서 무슨 일이 일어나는지 모두 볼 수 있게 해줍니다. **실전 팁** 💡 - 민감한 정보는 로그에 기록하기 전에 마스킹 처리하세요 - 로그 보존 기간을 30~90일로 설정하여 비용을 관리하세요 - 로그 그룹은 서비스별로 분리하여 검색하기 쉽게 만드세요 --- ## 5. 알람_설정하기 어느 날 새벽 3시, 김개발 씨의 핸드폰이 울렸습니다. 회사 서버에 장애가 발생했다는 긴급 연락이었습니다. "에러율이 50%를 넘었어요!" 잠에서 깬 김개발 씨는 부랴부랴 노트북을 켰습니다. 다음 날 박시니어 씨가 물었습니다. "알람 설정 안 했어요? 에러율이 올라가면 자동으로 알려주게 해야죠." **CloudWatch 알람**은 메트릭이 설정한 임계값을 넘어섰을 때 자동으로 알림을 보내는 기능입니다. 마치 자동차의 연료 경고등이 기름이 부족하면 켜지는 것처럼, 알람도 문제가 발생하기 전에 미리 경고해줍니다. 이메일, SMS, SNS 토픽 등 다양한 채널로 알림을 받을 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 cloudwatch = boto3.client('cloudwatch', region_name='us-east-1') sns = boto3.client('sns', region_name='us-east-1') # SNS 토픽 생성 (알림 채널) topic_response = sns.create_topic(Name='BedrockAlerts') topic_arn = topic_response['TopicArn'] # 이메일 구독 설정 sns.subscribe( TopicArn=topic_arn, Protocol='email', Endpoint='devteam@company.com' ) # 에러율 알람 설정 cloudwatch.put_metric_alarm( AlarmName='BedrockHighErrorRate', ComparisonOperator='GreaterThanThreshold', EvaluationPeriods=2, # 2회 연속 임계값 초과 시 MetricName='InvocationClientErrors', Namespace='AWS/Bedrock', Period=300, # 5분 단위 Statistic='Sum', Threshold=10, # 5분간 10건 이상 에러 발생 시 ActionsEnabled=True, AlarmActions=[topic_arn], # SNS로 알림 전송 AlarmDescription='Bedrock 클라이언트 에러가 임계값을 초과했습니다', Dimensions=[ {'Name': 'ModelId', 'Value': 'anthropic.claude-3-sonnet-20240229-v1:0'} ] ) # 응답 시간 알람 설정 cloudwatch.put_metric_alarm( AlarmName='BedrockSlowResponse', ComparisonOperator='GreaterThanThreshold', EvaluationPeriods=3, MetricName='ModelInvocationLatency', Namespace='AWS/Bedrock', Period=300, Statistic='Average', Threshold=5000, # 평균 5초 이상이면 알람 ActionsEnabled=True, AlarmActions=[topic_arn], AlarmDescription='Bedrock 응답 시간이 느려졌습니다' ) print("알람 설정이 완료되었습니다!") ``` 김개발 씨는 평소처럼 퇴근하여 편안한 저녁 시간을 보내고 있었습니다. 그런데 새벽 3시에 갑자기 전화가 울렸습니다. 팀장이었습니다. "지금 서비스에 장애가 발생했어요. 빨리 확인해 주세요!" 잠에서 깬 김개발 씨는 급하게 노트북을 켜서 대시보드를 확인했습니다. 에러율이 50%를 넘고 있었습니다. 무려 2시간 전부터 시작된 문제였습니다. "왜 진작에 몰랐지?" 다음 날 출근한 김개발 씨에게 박시니어 씨가 물었습니다. "알람 설정은 안 했어요? 문제가 생기면 자동으로 알려주게 해야죠." **CloudWatch 알람이란?** 쉽게 비유하자면, CloudWatch 알람은 자동차의 경고등과 같습니다. 연료가 부족하면 주황색 경고등이 켜지고, 엔진 과열이 감지되면 빨간색 경고등이 깜빡입니다. 운전자가 계기판을 계속 쳐다보지 않아도, 문제가 생기면 경고등이 알아서 알려줍니다. CloudWatch 알람도 마찬가지입니다. 메트릭을 24시간 감시하다가, 설정한 임계값을 넘으면 자동으로 알림을 보냅니다. 개발자가 대시보드를 계속 지켜볼 필요가 없습니다. **알람 없이는 어떤 일이 벌어질까요?** 알람 설정을 하지 않으면 심각한 문제를 놓칠 수 있습니다. 김개발 씨처럼 장애가 발생한 지 몇 시간이 지나서야 알게 되는 경우가 많습니다. 고객들은 이미 불편을 겪고 있고, SNS에는 불만이 쏟아집니다. 문제를 빨리 발견했다면 5분 만에 해결할 수 있었는데, 2시간 동안 방치되면서 피해가 눈덩이처럼 커집니다. 더 큰 문제는 비용입니다. API 호출이 비정상적으로 증가해도 모르고 있다가, 한 달 후 청구서를 보고 경악하는 경우도 있습니다. 알람을 설정했다면 즉시 알고 조치할 수 있었을 것입니다. **알람으로 문제를 미리 예방합니다** CloudWatch 알람을 설정하면 이런 상황을 방지할 수 있습니다. 문제가 발생하는 즉시 알림을 받을 수 있습니다. 이메일, SMS, Slack 등 원하는 채널로 알림을 받도록 설정할 수 있습니다. 심지어 자동으로 복구 작업을 실행하도록 Lambda 함수를 연결할 수도 있습니다. **코드로 알람 설정하기** 위의 코드를 단계별로 살펴보겠습니다. 먼저 **SNS 토픽**을 생성합니다. SNS는 Simple Notification Service의 약자로, 알림을 전송하는 채널입니다. 토픽을 만들면 고유한 ARN(Amazon Resource Name)이 발급됩니다. 다음으로 이메일 구독을 설정합니다. **subscribe** 메서드로 특정 이메일 주소가 알림을 받도록 등록합니다. Protocol을 'email'로 지정하면 이메일로, 'sms'로 지정하면 SMS로 알림이 갑니다. 핵심은 **put_metric_alarm** 메서드입니다. 여기서 알람의 모든 조건을 정의합니다. **ComparisonOperator**는 비교 연산자로, 'GreaterThanThreshold'는 임계값보다 크면 알람이 발생한다는 뜻입니다. **EvaluationPeriods**는 몇 번 연속으로 임계값을 초과해야 알람을 발생시킬지 정합니다. 1로 설정하면 일시적인 스파이크에도 알람이 울려서 false positive가 많아집니다. 2~3 정도가 적절합니다. **Threshold**는 실제 임계값입니다. 예를 들어 5분간 에러가 10건 이상 발생하면 알람이 울리도록 설정할 수 있습니다. **AlarmActions**에는 알람이 발생했을 때 실행할 작업을 지정합니다. SNS 토픽 ARN을 넣으면 해당 토픽으로 알림이 전송됩니다. 두 번째 알람은 응답 시간을 모니터링합니다. 평균 응답 시간이 5초를 넘으면 알람이 발생합니다. 사용자 경험이 나빠지기 전에 미리 알 수 있습니다. **실무 활용 사례** 실제 서비스에서는 알람을 어떻게 활용할까요? 대형 뉴스 포털에서 AI 기사 요약 서비스를 운영한다고 가정해봅시다. 평소에는 분당 100건 정도의 요청이 들어오는데, 갑자기 속보가 터지면 분당 1,000건으로 급증합니다. 알람을 설정해 두면 트래픽 급증을 즉시 감지할 수 있습니다. 온콜 엔지니어에게 자동으로 SMS가 발송되고, 엔지니어는 서버를 스케일 아웃하여 대응합니다. 사용자는 끊김 없는 서비스를 경험합니다. 또한 비용 알람도 중요합니다. 월 예산을 100달러로 설정했는데 80달러에 도달하면 경고 알람을, 95달러에 도달하면 긴급 알람을 발송하도록 설정합니다. 예산 초과를 방지할 수 있습니다. **주의사항** 초보 개발자들이 흔히 하는 실수가 있습니다. 너무 민감한 임계값을 설정하는 것입니다. 작은 변동에도 알람이 울리면 **알람 피로**가 발생합니다. 중요한 알람을 무시하게 되는 위험한 상황입니다. 따라서 임계값은 실제 데이터를 분석하여 적절하게 설정해야 합니다. 평소 에러가 시간당 5건 정도 발생한다면, 임계값을 10건 정도로 설정하는 것이 합리적입니다. 또한 **알람 우선순위**를 정해야 합니다. 모든 알람을 같은 긴급도로 처리하면 안 됩니다. Critical, High, Medium, Low로 나누고, Critical만 SMS로, 나머지는 이메일로 받는 식으로 구분하세요. **마무리** 알람 설정을 마친 김개발 씨는 이제 밤에도 편히 잘 수 있게 되었습니다. "문제가 생기면 바로 알림이 오니까 안심이에요." 알람은 개발자에게 마음의 평화를 줍니다. 24시간 모니터링을 하지 않아도, 알람이 대신 지켜줍니다. **실전 팁** 💡 - EvaluationPeriods를 2~3으로 설정하여 false positive를 줄이세요 - Critical 알람은 SMS로, 일반 알람은 이메일로 받도록 채널을 분리하세요 - 임계값은 평소 메트릭의 2배 정도로 설정하는 것이 적절합니다 --- ## 6. 비용_알람_구성 서비스가 안정화되고 한 달이 지났습니다. 김개발 씨는 AWS 청구서를 확인하다가 깜짝 놀랐습니다. "왜 이렇게 비용이 많이 나왔지?" 예상했던 금액의 3배가 청구되었습니다. 박시니어 씨가 한숨을 쉬며 말했습니다. "비용 알람도 설정해야죠. 예산을 넘기 전에 미리 알아야 대응할 수 있어요." **비용 알람**은 AWS 사용 비용이 설정한 예산을 초과하면 알림을 보내는 기능입니다. 마치 신용카드의 한도 알림처럼, 지출이 계획을 벗어나면 즉시 경고해줍니다. AWS Budgets 서비스를 사용하여 월별, 일별 예산을 설정하고, 특정 비율에 도달하면 단계별로 알림을 받을 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 budgets = boto3.client('budgets', region_name='us-east-1') account_id = boto3.client('sts').get_caller_identity()['Account'] # 월별 예산 설정 budget_response = budgets.create_budget( AccountId=account_id, Budget={ 'BudgetName': 'BedrockMonthlyBudget', 'BudgetLimit': { 'Amount': '100', # 월 100달러 'Unit': 'USD' }, 'TimeUnit': 'MONTHLY', 'BudgetType': 'COST', # 비용 기반 예산 'CostFilters': { 'Service': ['Amazon Bedrock'] # Bedrock만 필터링 } }, NotificationsWithSubscribers=[ { 'Notification': { 'NotificationType': 'ACTUAL', # 실제 비용 기준 'ComparisonOperator': 'GREATER_THAN', 'Threshold': 80, # 80% 도달 시 알림 'ThresholdType': 'PERCENTAGE' }, 'Subscribers': [ { 'SubscriptionType': 'EMAIL', 'Address': 'finance@company.com' } ] }, { 'Notification': { 'NotificationType': 'ACTUAL', 'ComparisonOperator': 'GREATER_THAN', 'Threshold': 100, # 100% 초과 시 긴급 알림 'ThresholdType': 'PERCENTAGE' }, 'Subscribers': [ { 'SubscriptionType': 'EMAIL', 'Address': 'devteam@company.com' }, { 'SubscriptionType': 'EMAIL', 'Address': 'cto@company.com' } ] } ] ) # 예측 기반 알람 추가 budgets.create_budget( AccountId=account_id, Budget={ 'BudgetName': 'BedrockForecastBudget', 'BudgetLimit': { 'Amount': '100', 'Unit': 'USD' }, 'TimeUnit': 'MONTHLY', 'BudgetType': 'COST' }, NotificationsWithSubscribers=[ { 'Notification': { 'NotificationType': 'FORECASTED', # 예측 비용 기준 'ComparisonOperator': 'GREATER_THAN', 'Threshold': 100, 'ThresholdType': 'PERCENTAGE' }, 'Subscribers': [ { 'SubscriptionType': 'EMAIL', 'Address': 'devteam@company.com' } ] } ] ) print("비용 알람이 설정되었습니다!") ``` 김개발 씨는 한 달 동안 열심히 서비스를 운영했습니다. 사용자도 늘어나고, AI 챗봇의 응답 품질도 좋아졌습니다. 모든 것이 순조로웠습니다. 그런데 월말이 되어 AWS 청구서를 확인하는 순간, 김개발 씨의 얼굴이 새하얗게 변했습니다. "300달러?!" 예상했던 100달러의 3배가 청구되었습니다. 급하게 사용 내역을 확인해 보니, Bedrock API 호출 횟수가 예상보다 훨씬 많았습니다. 어떤 사용자가 봇을 이용해 무한 반복 호출을 한 것이었습니다. 진작에 알았다면 차단했을 텐데, 한 달 후에야 알게 되었습니다. 박시니어 씨가 고개를 저으며 말했습니다. "비용 알람을 꼭 설정해야 해요. 예산의 80%에 도달하면 경고를 받고, 100%를 넘으면 긴급 알림을 받도록 설정하는 거죠." **비용 알람이란?** 쉽게 비유하자면, 비용 알람은 신용카드의 한도 알림과 같습니다. 신용카드로 쇼핑하다 보면 한도의 80%를 넘으면 문자가 옵니다. "사용 한도의 80%를 초과했습니다." 이 알림 덕분에 한도를 넘기 전에 멈출 수 있습니다. AWS Budgets도 마찬가지입니다. 월 예산을 100달러로 설정하면, 80달러에 도달했을 때 경고 알림을, 100달러를 넘으면 긴급 알림을 보냅니다. 심지어 예측 기능도 있어서, 현재 추세로 가면 예산을 초과할 것으로 예상되면 미리 알려줍니다. **비용 알람 없이는 어떤 일이 벌어질까요?** 비용 알람을 설정하지 않으면 김개발 씨처럼 청구서 폭탄을 맞을 수 있습니다. 클라우드 서비스는 사용한 만큼 과금되므로, 비정상적인 사용이 발생해도 모르고 지나갑니다. 실제로 많은 스타트업이 이런 문제로 어려움을 겪습니다. 개발자가 테스트하면서 대용량 데이터를 실수로 무한 루프로 처리했는데, 몇 시간 만에 수천 달러가 청구된 사례도 있습니다. 더 큰 문제는 회사의 재무 계획이 틀어진다는 것입니다. 월 예산을 100달러로 잡았는데 300달러가 청구되면, 다른 곳에 쓸 예산이 줄어듭니다. 심한 경우 서비스를 중단해야 할 수도 있습니다. **비용 알람으로 예산을 지킵니다** AWS Budgets를 설정하면 이런 위험을 막을 수 있습니다. 실시간으로 비용을 추적하며, 설정한 임계값에 도달하면 즉시 알림을 보냅니다. 단계별 알림을 설정할 수 있어서, 80%에서는 "주의하세요", 100%에서는 "즉시 조치 필요" 같은 메시지를 구분하여 받을 수 있습니다. **코드로 비용 알람 설정하기** 위의 코드를 자세히 살펴보겠습니다. 먼저 **AWS Budgets** 클라이언트를 생성합니다. 그리고 현재 AWS 계정 ID를 가져옵니다. Budgets는 계정 단위로 관리되므로 계정 ID가 필요합니다. **create_budget** 메서드로 예산을 생성합니다. **BudgetName**은 예산의 이름이고, **BudgetLimit**에 금액과 통화 단위를 지정합니다. **TimeUnit**을 'MONTHLY'로 설정하면 월별 예산이 됩니다. **CostFilters**는 특정 서비스만 필터링할 때 사용합니다. 여기서는 Bedrock만 모니터링하도록 설정했습니다. 이렇게 하면 다른 AWS 서비스 비용은 제외되고 Bedrock 비용만 추적됩니다. **NotificationsWithSubscribers**에서 알림 조건을 정의합니다. 첫 번째 알림은 **Threshold**가 80입니다. 즉, 예산의 80%에 도달하면 알림이 발송됩니다. **ThresholdType**을 'PERCENTAGE'로 설정하여 퍼센티지 기준으로 계산합니다. 두 번째 알림은 100%를 초과했을 때 발송됩니다. 이때는 개발팀뿐만 아니라 CTO에게도 알림이 가도록 여러 명의 구독자를 추가했습니다. **FORECASTED** 알림은 특히 유용합니다. 현재 사용 추세를 분석하여, 이대로 가면 월말에 예산을 초과할 것으로 예측되면 미리 알려줍니다. 아직 100%에 도달하지 않았어도 예방 조치를 취할 수 있습니다. **실무 시나리오** 실제 서비스에서는 어떻게 활용할까요? 스타트업에서 AI 기반 번역 서비스를 운영한다고 가정해봅시다. 투자 유치 전이라 예산이 빠듯합니다. 월 예산을 200달러로 정하고, 80%(160달러)에 도달하면 개발팀에 알림이 갑니다. 개발팀은 알림을 받고 즉시 대응합니다. 캐싱을 적극 활용하고, 불필요한 API 호출을 줄이는 최적화를 진행합니다. 덕분에 예산 내에서 서비스를 운영할 수 있습니다. 만약 알람이 없었다면? 월말에 400달러 청구서를 받고 회사 운영에 타격을 입었을 것입니다. **주의사항** 초보 개발자들이 흔히 하는 실수가 있습니다. 예산을 너무 빡빡하게 잡는 것입니다. 예를 들어 평소 90달러가 나오는데 예산을 100달러로 설정하면, 조금만 사용량이 늘어도 매번 알람이 울립니다. 따라서 예산은 평소 사용량의 **150% 정도**로 설정하는 것이 좋습니다. 여유를 두어야 정상적인 성장과 비정상적인 스파이크를 구분할 수 있습니다. 또한 **여러 단계의 알람**을 설정하세요. 80%, 90%, 100%, 120% 같은 식으로 단계를 나누면, 심각도에 따라 다르게 대응할 수 있습니다. **정리하며** 비용 알람을 설정한 김개발 씨는 이제 청구서를 두려워하지 않게 되었습니다. "80% 알림이 오면 바로 최적화하면 되니까 안심이에요." 비용 알람은 재무 안정성을 보장합니다. 클라우드를 안심하고 사용할 수 있게 해주는 안전장치입니다. **실전 팁** 💡 - 예산은 평소 사용량의 150% 정도로 여유 있게 설정하세요 - 80%, 100%, 120% 같은 여러 단계의 알람을 설정하여 단계별 대응하세요 - FORECASTED 알림을 활용하여 예산 초과를 사전에 예방하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: AWS, CloudWatch, Bedrock, Monitoring, Logging

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS Bedrock 모니터링과 로깅 완벽 가이드

목차

1. CloudWatch 기초

2. Bedrock 메트릭 확인

3. 사용량 대시보드 구성

4. 로그 수집 설정

5. 알람 설정하기

6. 비용 알람 구성

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

EFK 스택 로깅 완벽 가이드

Grafana 대시보드 완벽 가이드

Prometheus 메트릭 수집 완벽 가이드

보안 아키텍처 구성 완벽 가이드