왜 대부분의 AWS 튜토리얼은 핵심을 놓치는가

"AWS 배우기"를 검색하면 40시간 이상의 영상에 걸쳐 50개 이상의 서비스를 다루는 강의들을 찾을 수 있습니다. 강의를 마치고 나면 Route 53이 무엇인지, Glacier가 무엇을 하는지, 왜 Lightsail을 사용할 수 있는지 알게 되지만, 정작 AI 제품은 구축할 수 없습니다. 왜냐하면 몇 달 동안은 필요하지도 않을 서비스들에 대부분의 시간을 소비했기 때문입니다.

솔직한 진실은 이렇습니다. 2026년에 AWS에서 실제 운영 가능한(production-ready) AI 제품을 구축하려면, 기본적으로 다섯 가지 서비스가 필요합니다. 이 다섯 가지 서비스는 여러분이 접하게 될 거의 모든 AI 아키텍처(architecture)에 등장합니다. 이들은 다양한 사용 사례에 걸쳐 반복되는 패턴으로 함께 작동합니다. 이 서비스들을 이해하고 나면, 기업용 AI 팀에서 구축되고 있는 대부분의 것들을 직접 만들 수 있습니다.

다섯 가지 서비스는 다음과 같습니다:

Amazon Bedrock: AI 두뇌
AWS Lambda: 서버리스 (serverless) 실행 엔진
Amazon API Gateway: 프런트 도어 (front door)
Amazon DynamoDB: 빠르고 유연한 데이터베이스 (database)
Amazon CloudWatch: 관찰성 (observability) 레이어

이 가이드는 각 서비스를 기초부터 설명하고, AI 아키텍처에서 어디에 위치하는지 보여주며, 다섯 가지를 모두 함께 사용하는 완전한 프로젝트로 마무리합니다. 끝날 때쯤이면 여러분은 실제 작동하는 무언가를 구축하게 될 것입니다.

서비스 1: Amazon Bedrock, AI 두뇌

정의

Amazon Bedrock은 간단한 API를 통해 Claude (Anthropic 제공), Llama (Meta 제공), Mistral, 그리고 Amazon 자체의 Titan 모델과 같은 대규모 AI 모델에 대한 액세스를 제공하는 AWS 서비스입니다.

Bedrock 이전에는 운영 환경에서 AI 모델을 사용하는 것이 다음 중 하나를 의미했습니다:

• OpenAI의 API 비용을 지불하고 AWS 외부에서 별도의 API 키를 관리
• EC2 GPU 인스턴스에서 오픈 소스 모델을 실행 (비용이 많이 들고 유지 관리가 복잡함)
• SageMaker 사용 (강력하지만 복잡하며, 커스텀 모델을 훈련하는 데이터 과학자들을 위해 설계됨)

Bedrock은 이 점을 변화시킵니다. 기존에 사용하던 AWS 자격 증명(AWS credentials), 이미 이해하고 있는 동일한 IAM 권한을 사용하여 다른 AWS 서비스를 호출하는 것과 동일한 방식으로 모델을 호출할 수 있으며, 비용 또한 AWS 계정으로 직접 청구됩니다. 별도의 가입, 별도의 API 키, 별도의 결제 수단이 필요 없습니다.

비용 (What It Costs)

이는 계획 수립에 있어 매우 중요합니다. Bedrock의 가격 책정은 토큰(token)당 과금됩니다:

토큰은 대략 텍스트 4글자에 해당합니다. 1,000단어 분량의 기사는 약 1,300 토큰입니다. Claude 3 Haiku 가격을 기준으로 해당 기사를 처리하는 비용은 $0.0004로, 1센트의 10분의 1도 되지 않습니다.

참고를 위해 설명하자면: 요청당 평균 500 토큰을 사용하는 엔터프라이즈 애플리케이션이 하루에 10,000번의 요청을 보낼 경우, Claude 3 Haiku 사용 시 하루에 약 $0.625를 지출하게 됩니다. 이는 연간 $228로, 무료는 아니지만 매우 저렴한 수준입니다.

AI 아키텍처에서의 위치 (Where It Fits in AI Architecture)

사용자 요청 (User request)
↓
Lambda (비즈니스 로직)
...

Bedrock은 항상 중간에 위치합니다. 인터넷에 직접 노출되지 않습니다. Lambda가 사용자를 대신하여 Bedrock을 호출합니다.

Bedrock 활성화 및 첫 호출 수행하기 (Enable Bedrock and Make Your First Call)

bash

# 1단계: AWS 콘솔에서 모델 액세스 활성화
# 경로: AWS Console → Amazon Bedrock → Model access → Manage model access
# 활성화: Anthropic Claude 3 Haiku
...

다음과 같은 응답을 확인할 수 있습니다:

json

{
"content": [{"text": "Amazon Bedrock은 개발자가 간단한 API를 통해 여러 회사의 강력한 AI 모델에 쉽게 접근할 수 있도록 지원하는 AWS 서비스입니다. Bedrock은 모든 인프라의 복잡성을 처리하므로, 사용자는 AI 모델 배포를 관리하는 대신 애플리케이션 구축에 집중할 수 있습니다."}],
"usage": {"input_tokens": 25, "output_tokens": 47}
...
}

첫 번째 Bedrock 프로젝트: AI 텍스트 분석기 (Your First Bedrock Project: AI Text Analyser)

python

bedrock_demo.py

import boto3
import json
...
json', '').replace('', '').strip()
return {
'analysis': json.loads(content),
'tokensUsed': result['usage']['input_tokens'] + result['usage']['output_tokens'],
...

실행 방법:

bash

pip install boto3
python3 bedrock_demo.py

**이 코드가 알려주는 것:** Bedrock의 작동 방식, JSON 출력을 위한 프롬프트 (Prompt) 구조화 방법, 그리고 비용 계산 방법입니다. 이러한 패턴은 여러분이 구축할 모든 AI 애플리케이션에 등장합니다.

## 서비스 2: AWS Lambda, 서버리스 실행 엔진 (The Serverless Execution Engine)

### 정의

AWS Lambda는 서버를 직접 관리할 필요 없이 코드를 실행합니다. 함수를 작성하면, 트리거 (Trigger)가 발생할 때 AWS가 이를 실행합니다. 여러분은 코드가 실제로 실행되는 밀리초 (ms) 단위에 대해서만 비용을 지불합니다.

서버리스 (Serverless) 이전의 백엔드 코드 배포는 다음과 같은 작업을 의미했습니다:

- EC2 인스턴스 프로비저닝 (Provisioning)
- 런타임 (Runtime) 설치
- 보안 그룹 (Security groups) 설정
- 오토스케일링 (Auto-scaling) 설정
- 운영 체제 (OS) 패치 관리
- 아무도 사용하지 않을 때도 24시간 내내 서버 비용 지불

Lambda는 이 모든 것을 제거합니다. 함수를 작성하고 배포하기만 하면, Lambda가 나머지 모든 것을 처리합니다. 별도의 설정 변경 없이도 요청이 0개에서 100만 개까지 자동으로 확장 (Scale)됩니다.

### 모든 개발자가 알아야 할 Lambda 핵심 개념

**핸들러 함수 (The Handler Function)**

모든 Lambda 함수에는 이벤트 (Event)를 수신하고 응답 (Response)을 반환하는 진입점인 핸들러 (Handler)가 있습니다:

python

```python
def lambda_handler(event, context):
# event: 입력값 (API Gateway, S3 이벤트, 스케줄 등으로부터 전달됨)
# context: 호출에 대한 메타데이터 (요청 ID, 남은 시간 등)
...

콜드 스타트 (Cold Starts) vs 웜 스타트 (Warm Starts)

Lambda가 최근에 호출되지 않은 경우, AWS가 실행 환경 (Execution environment)을 초기화하는 동안 첫 번째 호출은 더 오래 걸립니다 (100ms~1s 추가 소요). 이를 콜드 스타트 (Cold start)라고 합니다. 동일한 실행 환경에서의 후속 호출은 웜 (Warm) 상태이며 빠르게 실행됩니다.

AI 애플리케이션의 경우, AWS 클라이언트 초기화(boto3 클라이언트, 데이터베이스 연결 등)를 핸들러 (Handler) 함수 외부에 배치하세요. 이렇게 하면 웜 (Warm) 호출 시에도 상태가 유지됩니다:

python

# 올바른 방법 — 한 번 초기화되어 웜 호출 시 재사용됨
import boto3
bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')
...

메모리 및 타임아웃 설정 (Memory and Timeout Settings)

Lambda 메모리(128MB–10GB)는 CPU 할당량도 제어합니다. 메모리가 많을수록 CPU가 많아지며, 실행 속도가 빨라집니다. Bedrock을 호출하는 AI 애플리케이션의 경우:

메모리: 512MB를 시작점으로 권장합니다.
타임아웃: 30초 (Bedrock은 복잡한 프롬프트에 대해 10~20초가 소요될 수 있음)

Lambda 비용 (What Lambda Costs)

Lambda 가격 책정은 두 가지 구성 요소로 이루어집니다:

요청 (Requests): 호출 100만 건당 $0.20 (매월 첫 100만 건은 무료)
기간 (Duration): GB-초당 $0.0000166667

512MB 메모리를 사용하는 Lambda가 1,000ms(1초) 동안 실행될 경우, 호출당 비용은 $0.0000083입니다. 월 100,000회 호출 시 비용은 $0.83입니다. 대부분의 애플리케이션에서는 사실상 무료인 수준입니다.

첫 번째 Lambda 배포하기 (Deploy Your First Lambda)

bash

REGION="eu-west-1"
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
# 실행 역할(execution role) 생성
...

이 과정에서 배우는 것: Lambda 라이프사이클 (lifecycle), 콜드 스타트 (cold start) 최적화, 핸들러 패턴 (handler pattern), 그리고 함수를 배포하고 테스트하는 방법입니다. 여러분이 구축할 모든 AI 애플리케이션은 이 패턴을 따르는 Lambda 함수를 포함하게 될 것입니다.

서비스 3: Amazon API Gateway, 프런트 도어 (The Front Door)

정의 (What It Is)

API Gateway는 Lambda 함수를 트리거하는 HTTP 엔드포인트 (endpoints)를 생성합니다. API Gateway가 없다면 Lambda 함수는 URL을 가질 수 없으며, 웹 브라우저, 모바일 앱 또는 다른 서비스가 인터넷을 통해 이를 호출할 방법이 없습니다.

API Gateway는 Lambda 앞단에 위치하여 다음과 같은 역할을 수행합니다:

• HTTPS URL 제공
• 인증 처리 (API 키, JWT 토큰)
• 속도 제한 (rate limits, 초당 요청 수) 적용
• 모든 요청 로깅 (logging)
• CORS (Cross-Origin Resource Sharing, 웹 브라우저에 필수적) 처리

HTTP API vs REST API

AWS는 두 가지 유형의 API Gateway를 제공합니다. 대부분의 AI 애플리케이션에는 더 단순하고, 빠르며, 저렴한 HTTP API를 사용하세요:

경험 법칙 (Rule of thumb): HTTP API로 시작하세요. 내장된 API 키 관리가 필요한 경우에만 REST API로 전환하세요.

Lambda를 위한 API Gateway 생성하기

bash

# HTTP API 생성
API_ID=$(aws apigatewayv2 create-api \
--name "my-ai-api" \
...

요청 흐름 (Request Flow) 이해하기

사용자가 API를 호출할 때, 단계별로 정확히 다음과 같은 일이 일어납니다:

1. 사용자가 다음으로 POST 요청을 보냄:

2. API Gateway가 요청을 수신함
...

이 과정이 알려주는 것: 모든 웹 기반 AI 애플리케이션의 근간이 되는 요청/응답 흐름입니다. 이 흐름을 이해하는 것은 문제가 발생했을 때 디버깅(debugging)을 하는 데 필수적입니다.

서비스 4: Amazon DynamoDB, 빠르고 유연한 데이터베이스

정의

DynamoDB는 AWS의 관리형 NoSQL 데이터베이스입니다. 다음과 같은 기능이 필요한 애플리케이션을 위해 설계되었습니다:

• 어떤 규모에서도 한 자릿수 밀리초(millisecond) 단위의 응답 시간 보장
• 관리할 서버가 없음
• 사용량 기반 요금제 (유휴 상태인 용량이 아닌, 읽기 및 쓰기에 대해 비용 지불)

AI 애플리케이션에서 DynamoDB는 다음과 같은 용도로 사용됩니다:

대화 기록 (Conversation history): 멀티턴(multi-turn) 채팅 컨텍스트 저장
사용량 추적 (Usage tracking): 속도 제한 (rate limiting)을 위해 사용자당 토큰 수 계산
캐싱 (Caching): 동일한 입력에 대해 Bedrock을 다시 호출하는 것을 방지하기 위해 이전 AI 응답 저장
결과 저장 (Results storage): 나중에 검색할 수 있도록 AI 분석 결과 저장

주요 DynamoDB 개념

테이블 (Tables), 아이템 (Items), 속성 (Attributes)

DynamoDB는 SQL 데이터베이스와 다르게 데이터를 구성합니다:

SQL 데이터베이스:
TABLE: users
COLUMNS: id, name, email, created_at
...

기본 키 (Primary Key): 가장 중요한 개념

모든 DynamoDB 테이블에는 기본 키 (Primary Key)가 있습니다. 아이템(Items)은 이 키를 통해 저장되고 검색됩니다. 이를 올바르게 설정하는 것이 DynamoDB 설계에서 가장 중요한 단일 결정 사항입니다.

파티션 키 전용 (Partition key only, 단순형): 항상 하나의 속성으로 아이템을 조회할 때 유용합니다. 예: userId로 사용자 조회

파티션 키 + 정렬 키 (Partition key + Sort key, 복합형): 관련된 여러 아이템을 저장하고 함께 쿼리(Query)해야 할 때 유용합니다. 예: sessionId에 대한 모든 메시지를 timestamp 순으로 정렬하여 조회

AI 대화 기록의 경우: sessionId (파티션) + timestamp (정렬) 조합이 표준 패턴입니다.

온디맨드 (On-Demand) vs 프로비저닝된 용량 (Provisioned Capacity)

예측 가능하고 대량의 트래픽이 발생하는 경우가 아니라면 온디맨드 (On-Demand) (읽기/쓰기당 비용 지불)를 사용하세요. 온디맨드는 작업당 비용은 더 높지만, 용량 계획 (Capacity planning)이 전혀 필요하지 않으며 예상치 못한 스로틀링 (Throttling)이 발생하지 않습니다.

대화 기록 테이블 생성하기

bash

# AI 대화 기록 저장을 위한 테이블
# 파티션 키 (Partition key): sessionId (대화 내의 모든 메시지를 그룹화)
# 정렬 키 (Sort key): timestamp (세션 내 메시지를 시간순으로 정렬)
...

Lambda에서 대화 메모리를 위한 DynamoDB 사용하기

python

# conversation_lambda.py
# 세션 초기에 말했던 내용을 기억하는 대화형 AI
import boto3
...

멀티 턴 (Multi-turn) 대화 테스트:

bash

# Turn 1
curl -X POST $API_URL/production/chat \
-H "Content-Type: application/json" \
...

AI가 당신의 이름을 기억하는 이유는 DynamoDB가 대화 기록을 저장하고, 이 기록이 이후의 모든 요청에 포함되기 때문입니다. DynamoDB가 없다면 AI는 매번 새로 시작하여 모든 것을 잊어버릴 것입니다.

이 과정에서 배우는 것: DynamoDB를 사용하여 AI에게 메모리를 부여하는 방법, 대화 컨텍스트 (Conversation context) 패턴, 그리고 AI 애플리케이션에서 끊임없이 사용하게 될 파티션 키 기반 쿼리 (Query-by-partition-key) 패턴입니다.

서비스 5: Amazon CloudWatch, 관측성 계층 (The Observability Layer)

정의

CloudWatch는 AWS의 모니터링, 로깅 및 알림 (Alerting) 서비스입니다. AI 애플리케이션이 프로덕션 환경에서 실행될 때, CloudWatch는 다음과 같은 정보를 제공합니다:

• 현재 무슨 일이 일어나고 있는가 (지표 (Metrics))
• 과거에 무슨 일이 있었는가 (로그 (Logs))
• 무언가 잘못되었을 때 (알람 (Alarms))

CloudWatch가 없다면, 여러분의 AI 애플리케이션은 블랙박스 (Black box)와 같습니다. 사용자가 불만을 제기할 때까지 문제가 발생했다는 사실조차 알 수 없을 것입니다. 하지만 CloudWatch가 있다면, 사용자가 알아차리기 전에 문제를 파악할 수 있습니다.

여러분에게 필요한 세 가지 CloudWatch 개념

1. 로그 (Logs): 무슨 일이 일어났는가

모든 Lambda 함수는 출력 내용을 CloudWatch Logs로 자동 전송합니다. Lambda 내의 모든 print() 문이 CloudWatch에 나타납니다. 모든 에러, 모든 예외 스택 트레이스 (Exception stack trace)가 포함됩니다.

python

# Lambda 함수 내부
import logging
logger = logging.getLogger()
...

전문가 팁: 구조화된 JSON 로깅 (Structured JSON logging)을 사용하세요. 이를 통해 CloudWatch Logs Insights 쿼리가 가능해집니다.

python

import json
def log(level: str, event: str, **kwargs):
    """구조화된 JSON 로그 항목을 작성합니다"""
    ...

이제 로그를 데이터베이스처럼 쿼리할 수 있습니다:

sql

-- 비용이 $0.01 이상인 모든 요청 찾기
fields @timestamp, cost_usd, tokens
| filter event = "bedrock_call_complete" and cost_usd > 0.01
...

2. 지표 (Metrics): 성능이 어떠한가

CloudWatch Metrics는 시간에 따른 수치 데이터 포인트입니다. Lambda는 호출 횟수 (Invocation count), 에러 횟수 (Error count), 실행 시간 (Duration), 스로틀링 (Throttles)에 대한 지표를 자동으로 생성합니다.