🏭 스마트 설비 운영 지원 플랫폼

480

시나리오: CTO가 원하는 "하나의 플랫폼"

시리즈의 마지막입니다. 대한설비(주) CTO가 전체 회의에서 발표합니다:

"지금까지 훌륭한 시스템들을 만들었습니다. 고가용 포털(1편), 점검 요청 API(2편), 이상징후 신고 서비스(3편). 하지만 이것들이 따로 놀고 있습니다.

제가 원하는 것은 하나의 통합 대시보드입니다. 설비 상태, 점검 요청, 이상징후가 한 눈에 보이고, 시스템이 알아서 모니터링하며, AI가 정비 매뉴얼을 검색해서 답변해 주는 플랫폼.

2주 뒤 경영진 보고가 있습니다. 포트폴리오로 발표할 수 있는 수준으로 만들어 주세요."

이번 프로젝트에서는 앞의 3개 프로젝트를 하나의 아키텍처로 통합하고, CloudWatch 모니터링Bedrock AI Q&A를 추가하여 완성도 높은 플랫폼을 구축합니다.

이 실습을 마치면 여러분은:

  • 여러 AWS 서비스를 조합한 통합 아키텍처를 설계할 수 있습니다
  • CloudWatch로 인프라와 애플리케이션을 통합 모니터링할 수 있습니다
  • Bedrock AI를 활용하여 자연어 Q&A 기능을 구현할 수 있습니다
  • 비용을 추정하고 발표할 수 있는 포트폴리오를 완성합니다

이 프로젝트는 스마트 설비 운영 지원 플랫폼 시리즈의 최종편입니다. 13편의 모든 리소스를 활용합니다. 13편을 모두 완료한 상태에서 진행하는 것을 권장합니다.

이 프로젝트는 8시간(480분) 분량의 종합 프로젝트입니다. 2~3일에 걸쳐 나누어 진행하는 것을 권장합니다. 리전은 ap-northeast-2 (서울) 을 사용합니다.

통합 아키텍처 개요

스마트 설비 운영 플랫폼 통합 아키텍처

전체 시스템 흐름

다이어그램 로딩 중...
스마트 설비 운영 지원 플랫폼 통합 아키텍처

비용 예측

비용 계산기

8시간
0h24h
ALB (1편 인프라)

시간

$0.1800
EC2 t3.micro x2 (1편)

시간

$0.1664
API Gateway + Lambda (3편, 프리 티어)

1,000 요청당 $3.50

$0.0320
DynamoDB (3편, 프리 티어)

쓰기 $1.25/백만, 읽기 $0.25/백만

$0.0240
Bedrock Claude Haiku (1000 요청 기준)

시간

$0.2400
CloudWatch 대시보드 (1개 무료)

메트릭당 $0.30/월

$0.0240
예상 총 비용$0.6664

* 실제 비용은 AWS 요금 정책에 따라 달라질 수 있습니다.

Step 1: 기존 리소스 확인 및 연결 점검

CloudWatch 모니터링 대시보드 — CPU, 응답시간, 에러율, 사용자 수

1~3편의 리소스가 모두 정상 동작하는지 확인합니다.

진행률 0/7
  1. 11편 확인: ALB DNS로 접속 → 점검 포털 페이지 정상 표시 확인
  2. 21편 확인: EC2 콘솔 → ASG 인스턴스 2대가 InService 상태 확인
  3. 32편 확인: http://<EC2-IP>:8000/docs → Swagger UI 정상 표시 확인
  4. 42편 확인: GET /api/v1/equipments → 설비 데이터 4건 반환 확인
  5. 53편 확인: curl로 API Gateway URL/incidents → 신고 목록 반환 확인
  6. 63편 확인: DynamoDB 콘솔 → IncidentReports 테이블 활성 상태 확인
  7. 7모든 리소스가 정상이면 다음 단계로 진행합니다

1~3편 리소스가 삭제된 경우: 각 편의 가이드를 따라 다시 생성하세요. 특히 1편의 VPC + ALB + ASG가 가장 중요합니다. 이 위에 모든 서비스가 올라갑니다.

Step 2: CloudWatch 통합 모니터링 대시보드

인프라와 애플리케이션 상태를 한 눈에 볼 수 있는 대시보드를 구성합니다.

진행률 0/3
  1. 1AWS 콘솔 → CloudWatch → 좌측 대시보드 → 대시보드 생성
  2. 2이름: SmartFacilityDashboard
  3. 3위젯 추가 → 다음 4개 위젯을 생성합니다:

위젯 1: EC2 인스턴스 CPU/네트워크

진행률 0/5
  1. 1위젯 유형: 꺾은선 그래프 선택
  2. 2지표 소스: EC2 → 인스턴스별 지표
  3. 3ASG가 관리하는 2개 인스턴스를 선택
  4. 4지표: CPUUtilization, NetworkIn, NetworkOut 선택
  5. 5기간: 5분 → 위젯 생성

위젯 2: ALB 요청 수 / 응답 시간

진행률 0/5
  1. 1위젯 추가 → 꺾은선 그래프
  2. 2지표 소스: ApplicationELB → ALB별 지표
  3. 3inspection-alb 선택
  4. 4지표: RequestCount, TargetResponseTime, HTTP_5XX_Count 선택
  5. 5기간: 1분 → 위젯 생성

위젯 3: Lambda 실행 지표

진행률 0/5
  1. 1위젯 추가 → 꺾은선 그래프
  2. 2지표 소스: Lambda → 함수별 지표
  3. 3CreateIncidentReport, ListIncidentReports 선택
  4. 4지표: Invocations, Duration, Errors 선택
  5. 5기간: 5분 → 위젯 생성

위젯 4: 비즈니스 지표 (숫자 위젯)

진행률 0/4
  1. 1위젯 추가 → 숫자 위젯
  2. 2ALB의 HealthyHostCount 지표 선택
  3. 3제목: "정상 서버 수" → 위젯 생성
  4. 4모든 위젯을 보기 좋게 배치한 후 대시보드 저장

CloudWatch 경보 설정

진행률 0/7
  1. 1CloudWatch → 경보 → 경보 생성
  2. 2지표 선택: ApplicationELB → inspection-alb → UnHealthyHostCount
  3. 3조건: UnHealthyHostCount >= 1 (비정상 인스턴스 1개 이상)
  4. 4기간: 1분, 데이터 포인트: 1/1
  5. 5알림: 새 SNS 주제 생성 → 이름: facility-alerts → 이메일 주소 입력
  6. 6경보 이름: UnhealthyHost-Alert → 경보 생성
  7. 7이메일에서 SNS 구독 확인 링크를 클릭합니다

이 경보를 설정하면, 1편의 장애 복구 데모를 다시 실행했을 때 이메일 알림이 옵니다. EC2 하나를 종료하면 UnHealthyHostCount가 1이 되어 경보가 발생하고, ASG가 새 인스턴스를 띄워 정상화되면 경보가 해제됩니다.

Step 3: Bedrock AI Q&A Lambda 구현

현장 근무자가 "컨베이어 벨트 소음 원인이 뭐야?" 같은 질문을 하면 AI가 정비 매뉴얼을 기반으로 답변하는 서비스를 만듭니다.

Bedrock 모델 액세스 요청

진행률 0/5
  1. 1AWS 콘솔 → Bedrock 검색 → 좌측 모델 액세스
  2. 2모델 액세스 관리 클릭
  3. 3Anthropic → Claude 3 Haiku 체크 (가장 저렴하고 빠름)
  4. 4변경 사항 저장 → 액세스 승인까지 1~5분 대기
  5. 5상태가 액세스가 부여됨으로 변경된 것을 확인합니다

Bedrock 모델 액세스는 리전별로 별도로 요청해야 합니다. ap-northeast-2 (서울) 리전에서 Claude 3 Haiku가 사용 가능한지 확인하세요. 서울 리전에서 사용 불가하면 us-east-1 (버지니아) 리전을 사용합니다.

AI Q&A Lambda 함수 생성

진행률 0/6
  1. 1Lambda 콘솔 → 함수 생성 → 이름: FacilityAIAssistant
  2. 2런타임: Python 3.12
  3. 3실행 역할: 기존 역할 사용 (3편에서 생성한 역할) 또는 새 역할 생성
  4. 4함수 생성 → 아래 코드 입력 → Deploy
  5. 5IAM 역할에 AmazonBedrockFullAccess 정책 추가
  6. 6Lambda 메모리: 256MB, 제한 시간: 30초로 변경 (구성 → 일반 구성 → 편집)
코드
import json
import boto3
 
# Bedrock 클라이언트 (리전 확인)
bedrock = boto3.client("bedrock-runtime", region_name="ap-northeast-2")
 
# 설비 정비 컨텍스트 (실제로는 S3/DB에서 로드)
MAINTENANCE_CONTEXT = """
당신은 대한설비(주)의 AI 설비 정비 도우미입니다.
아래 정비 매뉴얼을 참고하여 현장 근무자의 질문에 답변하세요.
 
[정비 매뉴얼 요약]
 
1. 컨베이어 벨트 이상 소음:
   - 원인: 롤러 베어링 마모, 벨트 장력 불균형, 이물질 끼임
   - 조치: 베어링 교체 주기 확인(6개월), 벨트 장력 조절, 이물질 제거
   - 긴급도: 소음 크기에 따라 LOW~HIGH
 
2. 프레스기 진동 과다:
   - 원인: 볼트 풀림, 기초 불량, 금형 마모
   - 조치: 볼트 재조임(토크 확인), 기초 재시공, 금형 교체
   - 긴급도: 진동값 2mm/s 이상이면 CRITICAL
 
3. 냉각 시스템 온도 이상:
   - 원인: 냉각수 부족, 펌프 고장, 필터 막힘, 열교환기 스케일
   - 조치: 냉각수 보충, 펌프 점검, 필터 교체(월 1회), 열교환기 세척(분기 1회)
   - 긴급도: 40도 이상이면 CRITICAL, 즉시 가동 중단
 
4. 용접 로봇 정밀도 저하:
   - 원인: 서보 모터 마모, 케이블 손상, 캘리브레이션 틀어짐
   - 조치: 모터 교체, 케이블 교체, 재캘리브레이션(월 1회)
   - 긴급도: 불량률 1% 이상이면 HIGH
 
답변 시 아래 규칙을 따르세요:
- 한국어로 답변합니다
- 200자 이내로 간결하게 답변합니다
- 가능한 원인, 권장 조치, 긴급도를 포함합니다
- 매뉴얼에 없는 내용은 "매뉴얼에서 확인되지 않은 항목입니다. 설비팀에 문의하세요."로 답합니다
"""
 
def lambda_handler(event, context):
    try:
        body = json.loads(event.get("body", "{}"))
        question = body.get("question", "")
 
        if not question:
            return {
                "statusCode": 400,
                "headers": {"Content-Type": "application/json", "Access-Control-Allow-Origin": "*"},
                "body": json.dumps({"error": "질문을 입력해 주세요"})
            }
 
        # Bedrock Claude 호출
        response = bedrock.invoke_model(
            modelId="anthropic.claude-3-haiku-20240307-v1:0",
            contentType="application/json",
            accept="application/json",
            body=json.dumps({
                "anthropic_version": "bedrock-2023-05-31",
                "max_tokens": 500,
                "system": MAINTENANCE_CONTEXT,
                "messages": [
                    {"role": "user", "content": question}
                ]
            })
        )
 
        result = json.loads(response["body"].read())
        answer = result["content"][0]["text"]
 
        return {
            "statusCode": 200,
            "headers": {"Content-Type": "application/json", "Access-Control-Allow-Origin": "*"},
            "body": json.dumps({
                "question": question,
                "answer": answer,
                "model": "Claude 3 Haiku"
            })
        }
 
    except Exception as e:
        return {
            "statusCode": 500,
            "headers": {"Content-Type": "application/json", "Access-Control-Allow-Origin": "*"},
            "body": json.dumps({"error": f"AI 응답 오류: {str(e)}"})
        }

API Gateway에 AI 엔드포인트 추가

진행률 0/5
  1. 1API Gateway 콘솔 → IncidentReportAPI (3편에서 생성) 선택
  2. 2경로 → 경로 생성
  3. 3메서드: POST, 경로: /ai/ask
  4. 4통합 대상: FacilityAIAssistant Lambda 선택
  5. 5생성 완료

AI Q&A 테스트

코드
API_URL="https://xxxxxxxxxx.execute-api.ap-northeast-2.amazonaws.com"
 
# 질문 1: 컨베이어 관련
curl -X POST "$API_URL/ai/ask" \
  -H "Content-Type: application/json" \
  -d '{"question": "1라인 컨베이어에서 이상한 소리가 나는데 원인이 뭘까요?"}'
 
# 질문 2: 냉각 시스템 관련
curl -X POST "$API_URL/ai/ask" \
  -H "Content-Type: application/json" \
  -d '{"question": "냉각수 온도가 42도입니다. 어떻게 해야 하나요?"}'
 
# 질문 3: 매뉴얼에 없는 질문
curl -X POST "$API_URL/ai/ask" \
  -H "Content-Type: application/json" \
  -d '{"question": "엘리베이터 점검 주기가 어떻게 되나요?"}'

Step 4: 비용 추정 스프레드시트

Bedrock AI Q&A — 점검 매뉴얼 기반 지능형 답변 시스템

경영진 보고에 필수적인 월간 운영 비용 추정서를 작성합니다.

서비스
사양
월 예상 비용 (USD)
비고
EC2 (ASG 최소 2대)
t3.micro x 2
$15.00
예약 인스턴스 시 $9.50
ALB
1개
$16.20
+ LCU 비용 (트래픽 비례)
API Gateway
HTTP API, 월 10만 요청
$0.10
프리 티어 후
Lambda
월 10만 요청, 평균 200ms
$0.02
프리 티어 후
DynamoDB
온디맨드, 월 10만 R/W
$0.13
프리 티어 후
Bedrock (Claude Haiku)
월 1,000 요청
$0.50
입력/출력 토큰 기반
CloudWatch
대시보드 1개 + 경보 2개
$3.00
대시보드 무료 1개
합계 (프리 티어 적용 시)
$35 ~ $40
첫 12개월
합계 (프리 티어 종료 후)
$35 ~ $45
안정 운영 기준

비용 최적화 포인트:

  1. EC2를 예약 인스턴스(1년)로 전환하면 약 35% 절약
  2. Lambda와 DynamoDB는 프리 티어 안에서 거의 무료
  3. Bedrock은 Haiku 모델을 사용하면 1건당 약 $0.0003으로 매우 저렴
  4. NAT Gateway를 사용하지 않는 설계로 월 $33 절약

Step 5: 와이어프레임 설계

통합 대시보드의 화면 구성을 설계합니다. 실제 프론트엔드 구현은 하지 않지만, 발표에서 "이렇게 만들 예정"이라고 보여줄 수 있는 와이어프레임을 만듭니다.

다이어그램 로딩 중...
스마트 설비 운영 지원 플랫폼 대시보드 와이어프레임

와이어프레임 도구 추천: Excalidraw (무료, 웹 기반), Figma (무료 플랜), 또는 종이에 직접 그리기. 발표 자료에 포함할 때는 깔끔한 스크린샷이나 다이어그램으로 정리하세요.

Step 6: 발표 준비

경영진 보고 / 포트폴리오 발표를 위한 자료를 정리합니다.

발표 구성안 (15분)

순서
내용
시간
핵심 포인트
1
프로젝트 개요 및 문제 정의
2분
공장의 실제 문제(24시간 운영, 점검 관리, 긴급 신고)
2
통합 아키텍처 설명
3분
4개 컴포넌트가 어떻게 연결되는지, Mermaid 다이어그램 활용
3
기술적 의사결정 설명
3분
EC2 vs 서버리스 선택 이유, 각 서비스 역할
4
라이브 데모
4분
점검 요청 생성 → 신고 접수 → AI 질문 → CloudWatch 확인
5
비용 분석 및 확장 계획
2분
월 $35~40, 확장 시나리오(RDS, S3, Cognito)
6
Q&A
1분
예상 질문 준비

발표 핵심 포인트

기술적으로 강조할 점:

  • 고가용성: EC2 1대를 죽여도 서비스가 계속되는 라이브 데모
  • 하이브리드 아키텍처: EC2 기반(안정적 업무)과 서버리스(비용 효율 이벤트)를 적절히 조합
  • AI 통합: Bedrock을 활용한 도메인 특화 Q&A — RAG 패턴의 초기 버전
  • 인프라 코드화: CloudWatch 경보로 사람 개입 없이 자동 모니터링
  • 비용 최적화: NAT Gateway 미사용, 프리 티어 최대 활용, 서버리스로 유휴 비용 0원

비즈니스 관점에서 강조할 점:

  • 24시간 무중단 운영으로 점검 기록 유실 방지
  • 모바일 즉시 신고로 비상 대응 시간 80% 단축 (가정)
  • AI 정비 도우미로 신입 기사도 베테랑 수준 대응 가능
  • 월 $35~40으로 기존 온프레미스 대비 70% 비용 절감 (가정)
  • 자동 확장/축소로 계절적 수요 변동에 자동 대응

자주 나오는 질문과 답변:

Q: 왜 전부 서버리스로 안 만들었나요? A: 점검 요청 API는 복잡한 상태 관리와 관계형 데이터가 필요합니다. DynamoDB의 NoSQL 구조로는 JOIN과 트랜잭션 처리가 어렵습니다. EC2 + RDB가 이 요구사항에 더 적합합니다.

Q: 실제 사용자 수가 늘어나면 어떻게 되나요? A: ALB + ASG가 자동으로 EC2를 추가하고, Lambda는 요청별로 독립 실행되어 별도 설정 없이 확장됩니다. DynamoDB 온디맨드 모드도 자동 확장합니다.

Q: 데이터 보안은 어떻게 보장하나요? A: VPC로 네트워크 격리, 보안 그룹으로 접근 제어, IAM 최소 권한 원칙 적용. 확장 시 Cognito 인증, RDS 암호화, S3 서버 측 암호화를 추가합니다.

산출물 체크리스트

진행률 0/8
  1. 1통합 아키텍처 다이어그램: 4개 컴포넌트가 모두 표현된 아키텍처 그림
  2. 2CloudWatch 대시보드 스크린샷: 4개 위젯이 있는 실제 대시보드
  3. 3Swagger UI 스크린샷: FastAPI의 5개 API 엔드포인트
  4. 4AI Q&A 데모 캡처: 3개 이상의 질문-답변 스크린샷
  5. 5비용 추정서: 월간 서비스별 비용 표
  6. 6와이어프레임: 통합 대시보드 UI 설계
  7. 7API 명세서: 모든 엔드포인트의 요청/응답 형식 문서
  8. 8발표 자료: 15분 분량 슬라이드 (10~12장)

직접 설명해 보기

최종 발표 자료 구성 — 산출물 체크리스트
✏️

본인의 말로 설명해 보세요

이 플랫폼의 전체 아키텍처를 비전공 경영진에게 3분 안에 설명해 보세요.

💡 각 컴포넌트를 실제 공장의 역할에 비유하세요.

✏️

본인의 말로 설명해 보세요

이 프로젝트에서 사용한 AWS 서비스 10개를 나열하고, 각각 한 줄로 역할을 설명해 보세요.

💡 VPC, ALB, EC2, ASG, API Gateway, Lambda, DynamoDB, CloudWatch, SNS, Bedrock

완성 후 테스트 가이드

진행률 0/8
  1. 1통합 테스트: ALB → FastAPI → Swagger에서 점검 요청 생성/조회 → 정상 동작 확인
  2. 2이상징후 신고: API Gateway URL로 POST /incidents → DynamoDB에 저장 확인
  3. 3AI Q&A: POST /ai/ask로 설비 관련 질문 → AI 답변 반환 확인
  4. 4모니터링 확인: CloudWatch 대시보드에서 EC2 CPU, ALB 요청 수, Lambda 실행 횟수 확인
  5. 5경보 테스트: EC2 인스턴스 1대 종료 → CloudWatch 경보 발생 → SNS 이메일 수신 확인
  6. 6장애 복구 확인: 종료 후 ASG가 새 인스턴스 생성 → ALB Health Check 통과 → 정상화 확인
  7. 7부하 테스트: stress-ng로 CPU 부하 → Auto Scaling 동작 → CloudWatch 대시보드에서 확인
  8. 8E2E 시나리오: 현장 근무자가 이상 발견 → 신고 접수 → AI에 원인 질문 → 정식 점검 요청 생성 → 상태 업데이트 → 완료

트러블슈팅

Bedrock에서 AccessDeniedException 오류:

  1. Bedrock 콘솔에서 Claude 3 Haiku 모델 액세스가 승인됨 상태인지 확인
  2. Lambda IAM 역할에 AmazonBedrockFullAccess 정책이 연결되어 있는지 확인
  3. Lambda 코드의 리전과 Bedrock 모델이 사용 가능한 리전이 일치하는지 확인

CloudWatch 대시보드에 지표가 안 보이는 경우:

  1. 지표가 수집되려면 해당 서비스에 실제 트래픽/활동이 있어야 합니다
  2. ALB에 요청을 몇 번 보낸 후 5분 뒤에 다시 확인하세요
  3. 기간 설정이 너무 짧으면 데이터가 표시되지 않을 수 있습니다 — 1시간 또는 3시간으로 설정

SNS 이메일 알림이 안 오는 경우:

  1. SNS 구독 확인 이메일을 클릭했는지 확인합니다 (스팸함도 확인)
  2. CloudWatch 경보 상태가 실제로 ALARM인지 확인합니다
  3. 경보의 SNS 주제(topic)와 구독이 올바르게 연결되어 있는지 확인합니다

Lambda AI 응답이 너무 느린 경우 (10초 이상):

  1. Lambda 메모리를 512MB로 늘려봅니다 (CPU도 비례 증가)
  2. Lambda 제한 시간이 30초 이상인지 확인합니다 (기본값 3초는 부족)
  3. Bedrock 모델을 Haiku로 사용하고 있는지 확인합니다 (Sonnet은 더 느림)

확장 아이디어

  1. RDS 전환: SQLite를 RDS PostgreSQL로 교체하여 데이터 영속성과 멀티 인스턴스 공유를 구현합니다. ASG의 모든 EC2가 같은 DB에 접속합니다.
  2. S3 + RAG: 정비 매뉴얼 PDF를 S3에 업로드하고, Bedrock Knowledge Base로 벡터 검색 기반 RAG를 구현합니다. 수백 페이지 매뉴얼에서도 정확한 답변이 가능해집니다.
  3. Cognito 인증: 사용자 인증/인가를 추가하여 역할별(현장근무자/관리자/엔지니어) 접근 제어를 구현합니다.
  4. IoT 센서 연동: IoT Core로 설비 센서 데이터를 실시간 수집하고, 이상 임계값 초과 시 자동으로 이상징후 신고를 생성합니다.
  5. Terraform IaC: 전체 인프라를 Terraform으로 코드화하여 환경 복제(개발/스테이징/프로덕션)를 자동화합니다.

학습 정리

핵심 치트시트

이 프로젝트에서는 4개 미니 프로젝트의 모든 AWS 서비스를 하나의 통합 플랫폼으로 연결하고, CloudWatch 모니터링과 Bedrock AI Q&A를 추가했습니다. 핵심은 서비스 간 통합 설계, 모니터링/경보 자동화, AI 활용, 비용 추정, 그리고 포트폴리오급 발표 능력입니다.

시리즈 완료

축하합니다! 스마트 설비 운영 지원 플랫폼 시리즈를 모두 완료했습니다.

이 시리즈에서 여러분은:

  • 1편: 고가용 인프라를 설계하고 장애 복구를 직접 확인했습니다
  • 2편: 비즈니스 요구사항을 REST API로 설계하고 구현했습니다
  • 3편: 서버리스 아키텍처를 구축하고 EC2 기반과 비교 분석했습니다
  • 4편: 모든 것을 통합하고 AI와 모니터링을 추가하여 포트폴리오를 완성했습니다

이 경험은 실제 AWS 실무에서 요구하는 역량의 핵심을 담고 있습니다. 발표 자료를 잘 정리하여 취업 면접이나 사내 프로젝트에 활용하세요!

리소스 정리

모든 실습이 끝나면 아래 순서대로 리소스를 정리하여 과금을 방지하세요. 역순으로 삭제합니다 (가장 마지막에 만든 것부터).

4편 리소스:

  1. CloudWatch 경보 삭제
  2. CloudWatch 대시보드 삭제
  3. SNS 주제 및 구독 삭제
  4. Lambda: FacilityAIAssistant 삭제

3편 리소스: 5. API Gateway: IncidentReportAPI 삭제 6. Lambda: CreateIncidentReport, ListIncidentReports 삭제 7. DynamoDB: IncidentReports 테이블 삭제

2편 리소스: 8. EC2에서 FastAPI 서비스 중단

1편 리소스: 9. Auto Scaling Group 삭제 (EC2가 자동 종료됨) 10. 시작 템플릿 삭제 11. ALB 삭제 12. 대상 그룹 삭제 13. 보안 그룹 삭제 14. VPC 삭제

공통: 15. IAM 역할 삭제 (Lambda용) 16. CloudWatch Logs 로그 그룹 삭제