TIL - 20261008

juni·약 13시간 전

목록 보기

474/474

1008 운영 자동화/AI 워크플로우 심화 (32/N): Cost Optimization, AWS Right Sizing과 FinOps 실전

✅ 1. 비용 최적화의 목표는 ‘가장 싼 인프라’가 아니다

비용 최적화를 잘못 이해하면:

EC2 가장 작은 사양

RDS 최소 사양

로그 최소화

백업 최소화

처럼 접근하기 쉽다.

하지만 이건 최적화가 아니라 단순한 비용 절감이다.

운영 시스템에서 진짜 목표는:

필요한 성능

+

필요한 안정성

+

필요한 복구 가능성

을 만족하면서

불필요한 비용 제거

다.

✅ 2. 즉 Cost Optimization은 성능·안정성과 함께 봐야 한다

예를 들어:

RDS 비용
월 10만 원

을 줄이려고:

사양 절반

으로 낮췄는데,

결과:

관리자 주문조회 느림

Connection Pool 대기

사전예약 Traffic 때 장애

가 발생한다면 좋은 최적화가 아니다.

✅ 3. FinOps란?

FinOps를 아주 간단하게 보면:

클라우드 비용을 개발·운영·비즈니스 관점에서 함께 측정하고, 필요한 곳에는 쓰고 낭비되는 곳은 줄이는 운영 방식

이다.

중요한 것은:

비용을 줄이는 팀

이 아니라:

비용을 이해하고
의도적으로 사용하는 문화

에 가깝다.

✅ 4. 1인 개발자에게도 FinOps가 필요한 이유

대규모 회사처럼:

FinOps Team

Cloud Architect

SRE

가 없어도,

혼자 다음 결정을 해야 할 수 있다.

EC2 사양 올릴까?

RDS 늘릴까?

Redis 추가할까?

로그 보관 기간 줄일까?

CloudFront를 더 활용할까?

AI API를 계속 쓸까?

결국 비용 판단도 개발자의 일이다.

✅ 5. 비용을 먼저 분류한다

현재 같은 AWS 기반 서비스라면 대략:

Compute

Database

Storage

Network

Observability

External API

AI

로 나눌 수 있다.

✅ 6. Compute 비용

예:

EC2

Worker Instance

Batch Server

등이다.

✅ 7. Database 비용

예:

RDS Instance

Storage

IOPS

Backup

Snapshot

등이다.

✅ 8. Storage 비용

예:

S3

Snapshot

Backup

Export File

Log Archive

다.

✅ 9. Network 비용

예:

Data Transfer

CloudFront

Cross-AZ Traffic

외부 전송

등이다.

✅ 10. Observability 비용

예:

CloudWatch Logs

Metrics

Trace

APM

이다.

이 부분은 생각보다 빠르게 커질 수 있다.

✅ 11. External API 비용

예:

알림톡

문자

Notion API는 비용보다 Rate 제약

기타 SaaS

등이다.

✅ 12. AI 비용

예:

LLM API Token

Embedding

Vector DB

AI SaaS

로컬 LLM 전력/하드웨어

까지 볼 수 있다.

✅ 13. 첫 단계는 ‘얼마가 나가는지 아는 것’이다

최적화 전에:

월 총 비용

만 보는 것으로는 부족하다.

최소한:

EC2

RDS

S3

CloudFront

CloudWatch

기타 API

별로 나눠봐야 한다.

✅ 14. 가장 큰 비용부터 본다

예:

RDS
45%

EC2
30%

CloudWatch
15%

S3
5%

기타
5%

라면 S3를 10% 줄여도 전체 비용 절감 효과는 작다.

✅ 15. Pareto 관점

대부분은:

몇 개 Resource가
전체 비용 대부분

을 차지한다.

그래서 큰 항목부터 본다.

✅ 16. Cost Optimization 우선순위

대략:

1. 사용하지 않는 Resource 제거

2. 과하게 큰 Resource 축소

3. Architecture 낭비 제거

4. Traffic/Storage 최적화

5. Pricing Option 검토

순서가 좋다.

✅ 17. 가장 먼저 할 일: Idle Resource 찾기

예:

안 쓰는 EC2

오래된 Elastic IP

Unused Volume

Old Snapshot

Unused Load Balancer

Old S3 Artifact

등이다.

✅ 18. 사용하지 않는 Resource를 없애는 것이 가장 안전한 절감

성능 영향 없이:

100% 비용 감소

가 가능하기 때문이다.

✅ 19. 하지만 정말 안 쓰는지 확인해야 한다

예:

트래픽 없음

이라고:

백업 서버 삭제

하면 안 된다.

✅ 20. Idle과 Standby는 다르다

Idle

더 이상 필요 없음

Standby

장애 대응을 위해
의도적으로 대기

다.

✅ 21. Resource Owner와 Purpose

Resource마다:

이게 왜 존재하지?

를 설명할 수 있어야 한다.

예:

prod-api-01
Purpose
Production API

old-test-server
Purpose
Unknown

이면 후자는 정리 후보가 된다.

✅ 22. Tagging

최소한:

Environment

Service

Owner

Purpose

정도 Tag를 두면 좋다.

✅ 23. 예

Environment=production
Service=togethermall
Owner=backend
Purpose=api

정도다.

✅ 24. 비용 분석도 Tag 기반으로 쉬워진다

예:

투게더몰

폰투몰

Automation

별로 비용을 나눠볼 수 있다.

✅ 25. 환경별 비용 분리

Production

Staging

Development

를 구분한다.

✅ 26. Staging이 Production만큼 비쌀 필요는 없다

예:

Production
24시간 운영

Staging
필요한 시간만

일 수 있다.

✅ 27. Development Resource는 꺼둘 수 있는가?

예:

개발용 EC2

개발용 Worker

는 밤/주말에 중지할 수 있다.

✅ 28. 하지만 RDS는 Stop 정책이 다를 수 있다

자동 재시작 조건 등이 있을 수 있으므로 단순:

밤마다 Stop

정책은 실제 서비스 특성을 확인해야 한다.

✅ 29. 지금은 ‘자동 껐다 켜기’보다 먼저 사용 여부 확인

자동화부터 만들지 않는다.

✅ 30. Right Sizing

Resource가 실제 사용량보다 과하게 큰지 보는 것이다.

예:

EC2
8 vCPU

Peak CPU
12%

이면 과한 사양일 수 있다.

✅ 31. 하지만 CPU 하나만 보고 줄이면 안 된다

Memory가:

80%

일 수도 있다.

또 순간 Peak가 있을 수도 있다.

✅ 32. Right Sizing Metric

최소:

CPU

Memory

Network

Disk

Peak

p95 usage

를 본다.

✅ 33. 평균 Usage보다 Peak를 본다

예:

평균 CPU
15%

Peak
85%

라면 무조건 축소하면 안 된다.

✅ 34. 일정 기간을 본다

하루만 보고 판단하지 않는다.

예:

2~4주

정도 실제 업무 주기를 관찰할 수 있다.

✅ 35. 사전예약/행사 Traffic도 포함

평소에는 낮아도 특정 시즌에 급증할 수 있다.

✅ 36. EC2 Right Sizing

예:

현재
4 vCPU / 16GB

Peak
CPU 35%
Memory 45%

라면 한 단계 낮출 후보일 수 있다.

✅ 37. 하지만 Worker와 API가 같은 서버라면

평소 Web CPU는 낮아도:

Export

AI

Batch

작업이 시작될 때 Resource가 급증할 수 있다.

✅ 38. Process별 Resource 사용을 알아야 한다

예:

API
CPU 20%

AI Worker
CPU 80%

이면 서버 전체 평균만 보면 원인을 놓친다.

✅ 39. AI Worker 때문에 Web 서버 사양이 커졌다면

아예:

AI Worker 분리

가 더 경제적일 수도 있다.

✅ 40. 예

현재:

Web + AI
고사양 EC2 24시간

대신:

Web
작은 EC2 24시간

AI
필요할 때만 별도 환경

이 더 효율적일 수 있다.

✅ 41. 하지만 분리에는 운영 복잡도가 생긴다

1007에서 다뤘듯:

복잡도 비용

도 계산한다.

✅ 42. Vertical Scale 비용 판단

예:

한 단계 큰 EC2
월 +5만원

으로 문제가 해결된다면,

분산 구조를 만드는 개발 시간보다 쌀 수 있다.

✅ 43. RDS 비용은 특히 중요하다

작은 서비스에서도 RDS가 전체 AWS 비용의 큰 비중을 차지할 수 있다.

✅ 44. RDS Right Sizing

확인:

CPU

Freeable Memory

Connections

Read/Write IOPS

Storage

Query Latency

이다.

✅ 45. RDS가 낮은 CPU라고 무조건 축소하지 않는다

Memory 부족으로:

Cache Hit 감소

Disk I/O 증가

가 생길 수 있다.

✅ 46. DB Memory는 성능에 중요

PostgreSQL은 자주 사용하는 데이터를 Memory에 유지하면서 성능을 낸다.

RAM을 줄이면 Disk 접근이 늘 수 있다.

✅ 47. 그래서 축소 전 Load Test

1007과 연결한다.

예:

Staging 또는 검증 환경에서
작은 사양 테스트

를 수행한다.

✅ 48. RDS Storage

예:

Allocated
500GB

Actual
50GB

라고 해도 단순히 즉시 줄일 수 없는 Storage 특성이 있을 수 있다.

✅ 49. DB Storage는 애초에 과도하게 크게 잡지 않는다

성장률을 보고 계획한다.

✅ 50. Storage Growth Rate

예:

현재
50GB

월 증가
2GB

라면:

6개월 후
약 62GB

정도를 예상할 수 있다.

✅ 51. 1003 Retention과 연결

오래된:

Outbox

Logs

Export Metadata

Workflow Detail

을 정리하면 DB Growth가 줄어든다.

✅ 52. Data Retention은 비용 최적화이기도 하다

다만 비용 때문에 Business Data를 임의 삭제하면 안 된다.

✅ 53. S3 비용 구조

단순:

파일 용량

만이 아니다.

보통:

Storage

Request

Data Transfer

등을 함께 본다.

✅ 54. S3의 가장 큰 낭비 중 하나는 오래된 Artifact

예:

Export Excel

Temporary Image

Old Build Artifact

Backup Copy

가 계속 쌓이는 것이다.

✅ 55. Lifecycle Policy

1003과 연결해서:

30일 후 삭제

90일 후 다른 Storage Class

같은 정책을 둘 수 있다.

✅ 56. 하지만 모든 파일을 Glacier 같은 Cold Storage로 보내면 안 된다

복구/조회 비용과 지연이 생길 수 있다.

✅ 57. Access Pattern을 본다

예:

최근 30일
자주 다운로드

1년 전
거의 접근 없음

이면 Storage Tiering 후보가 된다.

✅ 58. Export File은 삭제가 더 적합할 수 있다

다시 생성 가능한 파일이라면:

Archive

보다:

Delete

가 낫다.

✅ 59. Reproducible Artifact인지 확인

예:

주문 Excel

을 언제든 DB에서 다시 만들 수 있다면 영구 보관 가치가 낮다.

✅ 60. 하지만 당시 기준 Snapshot이 필요한 Report면 다르다

그때 생성한 결과 자체가 기록일 수 있다.

✅ 61. CloudFront 비용

CloudFront는 비용이 들지만 Origin 부하와 Data Transfer를 줄여줄 수 있다.

✅ 62. CDN 비용만 보고 제거하면 안 된다

CloudFront를 없애:

S3/EC2 Origin 직접 요청 증가

하면 총 비용/성능이 나빠질 수 있다.

✅ 63. CDN Cache Hit Rate를 본다

정적 Asset이:

Cache Hit 95%

라면 Origin Traffic이 크게 줄어든다.

✅ 64. 이미지 최적화도 비용 절감

예:

5MB PNG

대신:

300KB WebP

를 제공하면:

Data Transfer

Storage

사용자 로딩

모두 줄어든다.

✅ 65. 이미지 최적화는 성능과 비용이 같이 좋아지는 대표 사례

✅ 66. 하지만 이미지를 너무 압축해 품질을 망치지 않는다

상품몰에서는 이미지 품질도 중요하다.

✅ 67. Responsive Image

모바일에서:

3000px 원본

을 그대로 내려보낼 필요가 없다.

✅ 68. 기기 크기에 맞는 이미지 전달

mobile

tablet

desktop

버전을 활용하면 Traffic을 줄일 수 있다.

✅ 69. CloudWatch Logs 비용

로그를 많이 남기면:

Ingestion

Storage

Query

비용이 늘 수 있다.

✅ 70. 가장 나쁜 패턴

logger.info(JSON.stringify(req.body));

를 모든 Request에 남기는 것이다.

✅ 71. 비용뿐 아니라 PII 문제도 있다

1003과 연결된다.

✅ 72. 로그는 필요한 것만 남긴다

예:

event

requestId

correlationId

status

duration

errorCode

정도다.

✅ 73. Log Level 정책

예:

ERROR
문제 발생

WARN
운영상 주의

INFO
핵심 상태 변화

DEBUG
개발/일시적 진단

이다.

✅ 74. Production DEBUG 상시 활성화 금지

Log Volume이 급증할 수 있다.

✅ 75. Debug Logging은 임시 Flag로 켤 수 있다

예:

특정 Module만
30분

처럼 제한한다.

✅ 76. Debug Flag에는 Expiry

0928의 Emergency Override와 같다.

✅ 77. Log Retention

예:

Application Log
30일

Security/Audit
별도

처럼 데이터 성격에 따라 다르게 한다.

✅ 78. 모든 로그를 영구 보관하지 않는다

✅ 79. Audit Log는 Application Log와 다르다

비용 때문에 Audit까지 같이 지우면 안 된다.

✅ 80. Metric Cardinality도 비용 문제다

예:

userId

orderId

requestId

를 Metric Label로 넣으면 Series 수가 폭발할 수 있다.

✅ 81. High Cardinality 정보는 Trace/Log로

Metric은:

endpoint

status

service

errorCode

같은 제한된 Dimension을 사용한다.

✅ 82. Trace Sampling

모든 Request Trace를 100% 저장할 필요가 없는 경우가 있다.

✅ 83. 예

정상 Request:

10% Sampling

Error:

100%

처럼 할 수 있다.

✅ 84. 하지만 현재 Traffic이 작으면 100% Trace도 부담이 작을 수 있다

비용 측정 후 결정한다.

✅ 85. Observability를 너무 줄이면 장애 대응 비용이 커진다

로그 비용:

월 +3만원

아끼다가 Incident 원인을 못 찾아:

몇 시간 장애

가 나면 손해가 더 크다.

✅ 86. 그래서 Observability에는 최소 안전선이 필요하다

반드시 남길 것:

Error

Deploy

Audit

Queue Failure

Provider Failure

Correlation Context

등이다.

✅ 87. Backup 비용

Backup도 비용을 만든다.

하지만 가장 위험하게 줄이면 안 되는 영역 중 하나다.

✅ 88. Backup Retention은 비용과 복구 요구를 함께 본다

예:

Daily 30일

Monthly 1년

같은 정책은 실제 업무 요구를 기준으로 한다.

✅ 89. Backup을 지우기 전에 RPO/RTO를 생각한다

RPO:

얼마나 데이터 손실을 허용?

RTO:

얼마 안에 복구해야 하나?

이다.

✅ 90. 백업을 줄이면 RPO/RTO가 나빠질 수 있다

✅ 91. Snapshot 중복

자동 Backup 외에:

수동 Snapshot

을 계속 만들어두면 불필요한 비용이 쌓일 수 있다.

✅ 92. Snapshot에도 Owner/Created Reason을 남긴다

예:

before-major-migration

같은 목적을 적는다.

✅ 93. Temporary Snapshot은 Expiry를 정한다

예:

7일 후 검토/삭제

한다.

✅ 94. Delete 자동화 전에 Dry Run

1003과 같은 원칙이다.

✅ 95. 데이터 전송 비용

클라우드 비용에서 놓치기 쉬운 부분이다.

예:

Region 간

AZ 간

Internet Egress

등이다.

✅ 96. 같은 데이터를 계속 외부로 전송하면 비용이 커질 수 있다

특히:

대용량 이미지

Export File

Backup

등이다.

✅ 97. Cache/CDN이 Network 비용도 줄일 수 있다

1004와 연결된다.

✅ 98. Cross-AZ Traffic

Multi-AZ 구조에서는 가용성이 좋아지지만 Network 비용이 늘 수 있다.

✅ 99. 이 비용은 단순 낭비라고 보면 안 된다

가용성을 위해 의도적으로 쓰는 비용일 수 있다.

✅ 100. 비용 항목을 두 종류로 나눈다

Waste

안 쓰는 서버

중복 로그

오래된 Artifact

Reliability Cost

Backup

Multi-AZ

Monitoring

Headroom

이다.

✅ 101. Reliability Cost를 Waste처럼 줄이면 안 된다

중요한 구분이다.

✅ 102. Headroom도 비용이다

예:

평소 CPU 40%

라면 나머지 60%가 낭비처럼 보일 수 있다.

하지만:

Traffic Spike

배포

Failover

를 위한 여유일 수 있다.

✅ 103. 100% 사용률은 효율적인 시스템이 아니다

항상:

CPU 95%

DB Connections 95%

인 상태는 비용 효율적이라기보다 위험하다.

✅ 104. 적절한 Headroom을 유지한다

1007의 Capacity Planning과 연결한다.

✅ 105. Right Size ≠ 최대 사용률 100%

✅ 106. Cost vs Resilience Trade-off

예:

Single AZ
저렴

Multi-AZ
비쌈

이다.

✅ 107. 어떤 서비스를 운영하는지에 따라 다르다

개인 Toy Project와:

실제 주문이 들어오는 상업 서비스

는 동일 기준으로 비용을 줄이면 안 된다.

✅ 108. Production과 Personal Project 비용 정책도 다르다

Production:

안정성 우선

Toy:

비용 우선

이 가능하다.

✅ 109. 환경별 Cost Policy

예:

Production
Always On

Staging
Business Hours

Development
On Demand

처럼 다르게 운영할 수 있다.

✅ 110. Budget

월 비용 상한을 설정한다.

예:

AWS Monthly Budget
X원

이다.

✅ 111. Budget Alert

예:

50%

80%

100%

도달 시 알림을 받을 수 있다.

✅ 112. Budget은 서비스 중단 장치가 아니다

100% 넘었다고:

Production 종료

하면 안 된다.

✅ 113. Cost Alert는 관찰/조사 Trigger

예:

이번 달 비용
예상보다 50% 증가

하면 원인을 조사한다.

✅ 114. Cost Anomaly

비용이 평소와 다르게 급증하는 상황이다.

예:

CloudWatch Logs
하루 +300%

이다.

✅ 115. 원인 예

무한 Retry

Debug Log 활성화

Bot Traffic

Export Loop

S3 Upload Bug

AI API Loop

등이다.

✅ 116. Cost Spike는 Incident 신호일 수 있다

비용 문제만이 아니라 Bug의 흔적일 수 있다.

✅ 117. Cost Observability

예:

service_cost_daily

estimated_monthly_cost

cost_change_percent

처럼 내부 Dashboard를 만들 필요까지는 없더라도 정기적으로 확인한다.

✅ 118. 최소한 월별 비교

예:

8월
120,000

9월
145,000

10월 예상
240,000

이면 이유를 찾는다.

✅ 119. 사용량 증가인지 낭비인지 구분

Traffic이 2배라 비용이 2배면 자연스러울 수 있다.

Traffic은 동일한데 비용만 2배면 문제다.

✅ 120. Unit Economics

예:

주문 1건당 Infra 비용

을 볼 수 있다.

✅ 121. 예

월 Infra
300,000원

월 주문
3,000건

Infra / Order
약 100원

이다.

✅ 122. 이 수치가 월별로 악화되는지 본다

예:

100원
→
200원

이면 효율이 떨어지고 있다.

✅ 123. 단 고정비 때문에 주문량이 적은 달은 수치가 높아질 수 있다

Context를 같이 본다.

✅ 124. Cost per API Request

대략:

월 Infra 비용
/
월 Request 수

도 가능하다.

하지만 Business Value와 직접 연결되지는 않는다.

✅ 125. Cost per Business Outcome이 더 유용

예:

주문당

Export당

AI Report당

이다.

✅ 126. AI Cost Optimization

LLM API를 쓰면 가장 빠르게 커질 수 있는 비용 중 하나다.

✅ 127. 먼저 Token Usage를 기록

예:

promptTokens

completionTokens

totalTokens

model

이다.

✅ 128. AI Run Cost Metadata

예:

runId

model

inputTokens

outputTokens

estimatedCost

를 남긴다.

✅ 129. Local LLM과 API LLM을 비교

Local:

API 비용 없음

하지만
Hardware

전력

운영시간

이 있다.

✅ 130. API:

운영 간단

사용량 기반 비용

이다.

✅ 131. 사용량이 적으면 API가 더 싸고 단순할 수 있다

반대로 반복 대량 작업이면 Local이 유리할 수 있다.

✅ 132. 무조건 Local이 싸다고 보면 안 된다

고사양 장비 비용과 유지 관리가 있다.

✅ 133. AI 작업별 모델 선택

예:

간단 요약
작은 모델

복잡 분석
큰 모델

로 나눌 수 있다.

✅ 134. Model Routing

모든 작업을 가장 비싼 모델에 보내지 않는다.

✅ 135. 하지만 너무 작은 모델로 품질이 떨어져 재작업하면 총비용이 더 커질 수 있다

✅ 136. AI Cost = Token Cost만이 아니다

실패

재시도

사람 검토

잘못된 결과 수정

비용도 있다.

✅ 137. 좋은 모델이 한 번에 성공하면 더 싸기도 하다

✅ 138. Prompt Optimization

불필요한 Context를 매번 전부 보내지 않는다.

✅ 139. 예

나쁜 방식:

Repo 전체
매 Run 전송

좋은 방식:

변경 File

관련 문서

필요한 Context만

이다.

✅ 140. Context Window가 크다고 다 채우지 않는다

Token 비용뿐 아니라 Latency도 증가한다.

✅ 141. AI Cache

1004와 연결된다.

같은:

commitSha

promptVersion

inputHash

이면 결과 재사용을 고려한다.

✅ 142. 중복 AI Run 방지

0916 Idempotency와도 연결된다.

✅ 143. 예

같은 Commit Report가 이미 생성됐다면:

LLM 재실행

하지 않는다.

✅ 144. Retry Cost

AI Request가 Timeout났다고 무조건 다시 실행하면 비용이 두 번 나갈 수 있다.

✅ 145. UNKNOWN 상태 확인

Provider가 이미 처리했는지 확인 가능한 경우 Reconciliation한다.

✅ 146. maxAttempts

예:

같이 제한한다.

✅ 147. AI Budget

예:

Run당 최대 Token

하루 최대 Cost

월 최대 Cost

를 둘 수 있다.

✅ 148. Cost Budget 초과 시

LOW Priority AI 작업
중단

할 수 있다.

✅ 149. 운영 핵심 기능과 AI Budget을 분리

AI 비용이 많다고 주문 API까지 영향을 받으면 안 된다.

✅ 150. AI Feature Kill Switch

예:

ai_insight_enabled=false

로 즉시 제한할 수 있다.

✅ 151. 개발 도구 AI 비용도 따로 봐야 한다

예:

Codex

Claude Code

IDE AI

등의 생산성 도구 비용이다.

✅ 152. 단순 사용량보다 생산성 증가와 비교

예:

월 20만원

개발 시간 20시간 절약

이라면 충분히 가치 있을 수 있다.

✅ 153. Cost Optimization은 ‘비용 삭제’보다 ROI 판단

✅ 154. Worker 비용

Background Worker를 24시간 켜둘 필요가 있는지 본다.

✅ 155. Job이 하루 몇 번 없다면

예:

하루 Export 5건

전용 Worker Instance를 24시간 두는 것은 낭비일 수 있다.

✅ 156. 같은 App Process에서 처리하거나 On-demand 방식이 더 나을 수 있다

하지만 격리 필요성과 비교한다.

✅ 157. Queue Worker를 별도 분리할 시점

예:

Job이 많아짐

Web 성능에 영향

장시간 작업 많음

일 때다.

✅ 158. 분리하면 비용은 늘지만 안정성도 좋아진다

이 역시 Reliability Cost다.

✅ 159. Serverless가 비용 절감에 도움이 될 수 있는 경우

예:

가끔 실행

짧은 작업

Burst

같은 Job이다.

✅ 160. 하지만 모든 것을 Lambda로 옮길 필요는 없다

Cold Start, 실행 제한, 복잡도 등이 있다.

✅ 161. 현재 NestJS 중심 시스템이라면 기존 구조를 유지하는 편이 더 단순할 수 있다

✅ 162. Serverless 후보

예:

작은 이미지 변환

가벼운 Scheduled Cleanup

이벤트 기반 짧은 Worker

정도다.

✅ 163. 장시간 AI/Export는 Serverless와 맞지 않을 수 있다

실행 특성을 보고 결정한다.

✅ 164. Savings Plan / Reserved Capacity 같은 할인

장기간 꾸준히 사용하는 Compute라면 할인 옵션을 검토할 수 있다.

✅ 165. 하지만 사용량이 안정화되기 전에 장기 Commit하면 위험하다

예:

3년 약정

후 Architecture가 바뀔 수 있다.

✅ 166. 먼저 Usage Pattern을 확인

예:

Production EC2
24/7

1년 이상 유지 예상

이면 검토 가치가 있다.

✅ 167. Development처럼 자주 바뀌는 Resource는 On-demand가 편할 수 있다

✅ 168. 비용 할인보다 Right Sizing이 먼저

큰 서버를 30% 할인받는 것보다 작은 적정 서버를 쓰는 것이 더 싸다.

✅ 169. 예

과대 서버
월 20만
30% 할인
14만

적정 서버
월 8만

이다.

✅ 170. 할인은 낭비를 싸게 사는 방법이 될 수도 있다

✅ 171. Scale-to-zero

완전히 사용하지 않을 때 Resource를 0으로 줄이는 전략이다.

✅ 172. Production API에는 일반적으로 적용하기 어렵다

항상 응답해야 하기 때문이다.

✅ 173. Development/Batch에는 가능

예:

AI 분석 Worker

Staging

같은 영역이다.

✅ 174. 하지만 다시 시작하는 시간도 고려

Startup 10분이면 On-demand 작업 UX가 나빠질 수 있다.

✅ 175. Idle vs Warm Cost

항상 켜두는 비용과 Startup Delay 사이의 Trade-off다.

✅ 176. Database Serverless도 같은 관점

Traffic이 매우 불규칙하면 유리할 수 있지만 실제 가격/성능 패턴을 확인해야 한다.

✅ 177. 현재 구조를 억지로 바꾸지 않는다

비용 10% 줄이려고 Architecture 전체를 바꾸는 것은 비효율적일 수 있다.

✅ 178. Cost Optimization Threshold

예:

월 절감
5,000원

구현
2일

이라면 우선순위가 낮다.

✅ 179. 개발 시간도 돈이다

✅ 180. ROI 계산

간단히:

월 절감액

×

예상 유지 기간

vs

개발/운영 비용

으로 본다.

✅ 181. 예

월 절감
50,000원

1년
600,000원

구현에 하루면 할 가치가 있을 수 있다.

✅ 182. 반대로

월 절감
3,000원

구현
3일

이면 하지 않는 편이 낫다.

✅ 183. Cost Optimization Backlog

일반 기능 Backlog와 따로:

Cost Saving

Estimated Saving

Effort

Risk

를 기록할 수 있다.

✅ 184. 예

개선	월 절감 예상	난이도	위험
Old S3 Artifact 삭제	중	낮음	낮음
RDS 다운사이징	높음	중	높음
Debug Log 축소	중	낮음	낮음
Architecture 재설계	높음	높음	높음

✅ 185. Low Risk / High Saving부터

가장 좋은 대상이다.

✅ 186. 비용 절감 우선순위 Matrix

High Saving + Low Risk
→ 즉시

High Saving + High Risk
→ 검증 후

Low Saving + Low Risk
→ 여유 있을 때

Low Saving + High Risk
→ 하지 않음

이다.

✅ 187. RDS 다운사이징은 High Risk일 수 있다

그래서 Load Test가 필요하다.

✅ 188. 오래된 S3 Export 삭제는 Low Risk일 수 있다

1003 Cleanup으로 자동화 가능하다.

✅ 189. Debug Log 축소도 Low Risk

단 Incident에 필요한 로그는 남긴다.

✅ 190. Resource Scheduling

예:

Staging EC2

09:00 Start

20:00 Stop

같은 방식이 가능하다.

✅ 191. Scheduler 실패를 고려

자동 Stop은 됐는데 Start가 실패하면 다음날 개발환경이 내려가 있을 수 있다.

✅ 192. Production에는 함부로 적용하지 않는다

✅ 193. Cost Automation도 Fail-safe가 필요

예:

비용 초과
→ DB 자동 종료

같은 정책은 위험하다.

✅ 194. 비용 Automation은 기본적으로 Notify 중심

Budget 초과

Idle 후보

Storage 급증

을 알려준다.

✅ 195. Destructive Cost Action은 Approval

예:

EC2 Terminate

Snapshot Delete

RDS Downsize

는 사람 확인이 필요하다.

✅ 196. AI Cost Assistant

AI가 비용 데이터를 받아:

어디가 증가했는가?

어떤 Resource가 Idle 후보인가?

어떤 로그가 폭증했는가?

를 정리할 수 있다.

✅ 197. AI가 AWS Resource를 바로 삭제하게 하지 않는다

비용 분석과 실행 권한을 분리한다.

✅ 198. Cost Anomaly 분석

예:

CloudWatch
7일 평균 대비
+180%

이면 AI가 최근:

Release

Error Spike

Debug Flag

Traffic

과 연결해서 후보를 분석한다.

✅ 199. Deploy와 Cost를 연결

예:

Release v42
↓
DB Query 수 2배
↓
RDS CPU 증가
↓
Scale-up
↓
비용 증가

처럼 비용도 Release Regression 결과일 수 있다.

✅ 200. 비용 증가가 무조건 인프라 문제는 아니다

코드 변경이 원인일 수 있다.

✅ 201. Cost Regression

신규 기능 하나가:

외부 API를 매 요청마다 호출

해서 비용을 크게 늘릴 수 있다.

✅ 202. Feature 개발 시 Cost Question

이 기능은 요청당 어떤 Resource를 더 쓰는가?

외부 API 비용이 있는가?

Storage가 계속 쌓이는가?

Background Job이 늘어나는가?

를 본다.

✅ 203. Cost-aware Design

예:

기존:

페이지 조회마다
LLM 호출

보다는:

상품 변경 시 1회 분석
↓
결과 저장
↓
페이지에서는 결과 조회

가 훨씬 싸고 안정적이다.

✅ 204. Online Calculation vs Precomputation

실시간 계산:

매 Request 비용

Precompute:

변경 시 1회 비용

이다.

✅ 205. 데이터가 자주 안 바뀐다면 Precompute가 유리

예:

상품 AI 요약

리뷰 요약

검색용 Metadata

등이다.

✅ 206. 하지만 너무 오래된 결과를 보여주지 않게 Invalidation이 필요

1004 Cache와 연결된다.

✅ 207. Batch Processing으로 비용 줄이기

예:

리뷰 100건
LLM 100회

보다:

적절하게 묶어서
10회

가 저렴할 수 있다.

✅ 208. 단 Context가 너무 커지면 Token 비용이 다시 증가

적절한 Batch Size가 필요하다.

✅ 209. External API Call Deduplication

동일 정보 조회를 여러 Module이 각각 하지 않는다.

✅ 210. 공통 Cache

예:

Provider Product Metadata

를 한 번 가져와 공유한다.

✅ 211. Retry도 비용이다

외부 API:

1회 실패
→ 5회 Retry

면 비용도 최대 5배일 수 있다.

✅ 212. Retry Budget이 비용 제어 역할도 한다

1005와 연결된다.

✅ 213. Timeout도 비용과 연결

너무 긴 Timeout은:

Worker 점유

Connection 점유

Compute 시간

을 늘린다.

✅ 214. 빠르게 실패하고 Queue에서 Retry하는 편이 나을 수 있다

업무 특성에 따라 결정한다.

✅ 215. Overprovisioning vs Underprovisioning

Overprovisioning

너무 큰 Resource

비용 낭비.

Underprovisioning

너무 작은 Resource

장애/성능 저하.

✅ 216. 목표는 둘 사이 균형

✅ 217. Right Sizing Cycle

Measure

↓

Analyze

↓

Resize

↓

Observe

↓

Load Test

↓

Adjust

이다.

✅ 218. 한 번 Right Size했다고 끝이 아니다

Traffic과 기능은 계속 바뀐다.

✅ 219. 월별 Review

작은 서비스라도:

월 1회

정도 비용을 볼 수 있다.

✅ 220. 큰 Release 이후 추가 Review

예:

AI 도입

신규 쇼핑몰 연동

대량 분석 기능

이후 비용 변화 확인.

✅ 221. 비용 급증 Threshold

예:

전주 대비 +30%

같이 내부 기준을 둘 수 있다.

✅ 222. 정확한 %는 실제 변동성을 보고 정한다

매월 첫날 사용량 초기화 효과 같은 것도 고려한다.

✅ 223. Forecast

월 중간에:

현재 추세면
월말 예상 비용

을 보는 것이 좋다.

✅ 224. Budget 초과 전에 알 수 있다

✅ 225. Resource Unit Cost

예:

EC2
시간당

S3
GB-month

CloudWatch
Ingestion GB

LLM
Token

처럼 비용 단위를 이해하면 원인을 찾기 쉽다.

✅ 226. 사용량 × 단가

비용은 결국:

Usage
×
Unit Price

로 생각할 수 있다.

✅ 227. 비용이 늘었을 때 두 질문

Usage가 늘었나?

Unit Cost가 바뀌었나?

이다.

✅ 228. Usage 증가 원인

Traffic 증가

Bug

Log 증가

File 증가

Retry 증가

등이다.

✅ 229. Unit Cost 변화

예:

Instance Type 변경

Region 변경

Pricing Option 변경

등이다.

✅ 230. 내부 Chargeback까지는 필요 없다

작은 회사에서 팀별 청구 시스템까지 만들 필요 없다.

✅ 231. 하지만 Service별 비용은 구분 가치가 있다

예:

Customer Web

Admin

Automation

AI

정도다.

✅ 232. AI 기능이 전체 Infra 비용의 몇 %인지 알 수 있다

기능 존속 여부 판단에도 도움된다.

✅ 233. Value Metric 연결

예:

AI 기능:

월 비용 10만

업무시간 20시간 절감

이면 가치가 높다.

✅ 234. 반대로:

월 비용 30만

한 달 5번 사용

이면 구조를 다시 볼 수 있다.

✅ 235. Cost Optimization의 핵심은 사업 가치와 연결

✅ 236. Production Cost Review 예

RDS
필수
최적화 제한

EC2
Peak 낮음
Downsize 검토

S3 Export
Old 파일 많음
Lifecycle 적용

CloudWatch
DEBUG 폭증
정리

AI API
중복 Run 있음
Idempotency 적용

처럼 본다.

✅ 237. 현재 프로젝트 우선순위 1단계

AWS 월 비용 Breakdown 확인

이다.

✅ 238. 2단계

EC2/RDS CPU/Memory/Connection

2~4주 Trend

확인.

✅ 239. 3단계

Idle Resource 찾기.

Old Volume

Snapshot

Unused S3 Artifact

등이다.

✅ 240. 4단계

CloudWatch Log Volume/Retention 확인.

✅ 241. 5단계

S3 Lifecycle.

특히:

Export

Temporary Artifact

부터 적용.

✅ 242. 6단계

Load Test 후 EC2/RDS Right Sizing 검토.

✅ 243. 7단계

AI/외부 API Usage와 Budget 기록.

✅ 244. 8단계

월별 Cost Review 문서화.

✅ 245. 현재 당장 과한 것

복잡한 FinOps Platform

Cloud Cost Data Warehouse

자동 Resource Termination

Multi-account Chargeback

AI Auto Rightsizing

까지는 필요 없다.

✅ 246. Spreadsheet 수준으로도 충분할 수 있다

예:

Month

AWS Total

EC2

RDS

S3

Logs

AI

Reason

을 기록한다.

✅ 247. Cost Review Markdown도 가능

/docs/cost/
2026-10-cost-review.md

형태다.

✅ 248. Cost Review Template

# Monthly Cost Review

## 총 비용

## 전월 대비

## 주요 비용 Resource

## 증가한 항목

## 감소한 항목

## Traffic 변화

## Release 변화

## Idle Resource 후보

## Right Sizing 후보

## Reliability Cost

## Cost Saving Action

## 예상 절감액

## 위험도

## 다음 Review

✅ 249. 비용 변경도 기록한다

예:

2026-10-08

RDS
db.tX → db.tY

Reason
Peak utilization low

Expected Saving
월 X원

Rollback
Instance type 복구

처럼 남긴다.

✅ 250. Right Sizing도 Release처럼 생각한다

Plan

↓

Validate

↓

Apply

↓

Health Check

↓

Observe

↓

Rollback

이다.

✅ 251. RDS Downsize 후 확인

CPU

Free Memory

Connection

p95 Query

Slow Query

Error Rate

를 본다.

✅ 252. EC2 Downsize 후

CPU

Memory

Event Loop

API p95

Worker Duration

을 본다.

✅ 253. 비용 절감 성공 기준

단순:

월 비용 -20%

가 아니다.

✅ 254. 좋은 성공 기준

월 비용 -20%

SLO 유지

Error Rate 유지

Queue Lag 유지

RTO/RPO 유지

이다.

✅ 255. 성능이 악화됐다면 비용 절감 실패

✅ 256. 비용 최적화로 인한 Incident도 가능하다

예:

RDS 다운사이징

↓

메모리 부족

↓

Disk I/O 증가

↓

주문관리 API 지연

이다.

✅ 257. 이런 변경도 Postmortem 대상이 될 수 있다

✅ 258. Cost Guardrail

예:

Monthly Budget

AI Daily Budget

Log Retention Max

Artifact Retention

Resource Tag Required

정도를 둘 수 있다.

✅ 259. Cost Guardrail은 자동 삭제보다 예방 중심

✅ 260. 신규 Resource 생성 Checklist

왜 필요한가?

Production인가?

Owner는?

예상 월 비용은?

언제 삭제할 수 있는가?

Tag가 있는가?

를 확인한다.

✅ 261. Temporary Resource는 `expiresAt`

예:

Purpose
load-test

ExpiresAt
2026-10-15

같이 Tag할 수 있다.

✅ 262. Expired Resource Report

자동 삭제 대신:

삭제 후보

로 보여준다.

✅ 263. 사람이 확인 후 삭제

Production 사고 위험이 줄어든다.

✅ 264. Cost와 Security가 연결되는 영역

오래된:

Snapshot

Backup

S3 File

Log

은 비용뿐 아니라 공격 표면도 늘린다.

✅ 265. 그래서 Retention 최적화는 비용+보안 개선

✅ 266. 반대로 Security를 위해 추가 비용이 필요한 영역도 있다

예:

Backup

Audit

WAF

Monitoring

이다.

✅ 267. Security Cost를 Waste로 분류하지 않는다

✅ 268. Cost와 Reliability 우선순위

다음 순서가 안전하다.

1. Waste 제거

2. 비효율 개선

3. Right Size

4. 할인 검토

5. Architecture 변경

이다.

✅ 269. Architecture 변경은 마지막

복잡도와 장애 위험이 가장 크기 때문이다.

✅ 270. 예

비용 때문에:

RDS 없애고
직접 PostgreSQL 운영

하는 것은 관리 부담과 장애 위험이 크게 늘 수 있다.

✅ 271. Managed Service 비용에는 운영 시간도 포함돼 있다

RDS가 EC2 직접 DB보다 비싸 보여도:

Backup

Patch

Failover

Monitoring

관리 시간

가 포함된 가치가 있다.

✅ 272. 관리형 서비스 프리미엄

단순 단가만 비교하지 않는다.

✅ 273. 1인 개발자일수록 Managed Service 가치가 클 수 있다

운영 시간을 줄여준다.

✅ 274. Cost Saving 때문에 직접 운영 범위를 너무 넓히지 않는다

✅ 275. CloudFront도 비슷하다

직접 Cache Server를 만드는 비용보다 관리형 CDN이 더 경제적일 수 있다.

✅ 276. Build vs Buy

비용 최적화에서도:

직접 구축 비용

SaaS/Managed 비용

을 비교한다.

✅ 277. 개발자 시간까지 포함하면 Buy가 더 싼 경우가 많다

✅ 278. 하지만 사용량이 커지면 직접 구축이 유리해질 수도 있다

그때 다시 측정한다.

✅ 279. AI vs 자체 자동화

예:

SaaS 자동화
월 30만

직접 Worker
월 Infra 5만
+
개발 시간

을 비교한다.

✅ 280. 개발 시간이 이미 필요한 업무라면 자체 시스템 가치가 높을 수 있다

✅ 281. 비용을 코드에 연결

예:

AI Report 생성
estimatedCost

를 Run Metadata에 넣는다.

✅ 282. Workflow별 비용

예:

WorkflowRun
duration

tokens

externalCalls

estimatedCost

를 추적할 수 있다.

✅ 283. 비싼 Workflow 찾기

예:

AI_WEEKLY_REPORT
평균 1,500원/run

COMMIT_SUMMARY
평균 50원/run

처럼 볼 수 있다.

✅ 284. 사용 가치가 낮은 비싼 Workflow부터 개선

✅ 285. AI Prompt Version별 비용 비교

예:

Prompt v4
8k tokens

Prompt v5
3k tokens

인데 품질이 비슷하면 v5가 효율적이다.

✅ 286. 비용도 Experiment Metric

단순 품질만 보지 않는다.

✅ 287. Model Comparison

예:

Model A
성공률 95%
비용 100

Model B
성공률 80%
비용 30

다.

✅ 288. 재시도 포함 Expected Cost를 본다

Model B가 실패해 결국 Model A를 다시 쓰면 더 비쌀 수 있다.

✅ 289. Expected Cost

개념적으로:

1회 비용
×
평균 시도 횟수

를 본다.

✅ 290. Quality-adjusted Cost

더 현실적으로는:

비용

+

사람 수정 시간

+

재작업

까지 봐야 한다.

✅ 291. Local LLM Utilization

로컬 모델을 켜두고 전혀 안 쓰는 시간이 많다면:

RAM

전력

을 계속 사용한다.

✅ 292. 필요할 때 Ollama Model을 Load/Unload하는 것도 자원 최적화

단 실행 지연과 Trade-off다.

✅ 293. 같은 Mac에서 개발/LLM을 같이 쓰면 Resource Contention 비용도 있다

돈은 안 나가도 생산성이 떨어질 수 있다.

✅ 294. Cost는 금액만이 아니다

Time

Complexity

Performance

Cognitive Load

도 비용이다.

✅ 295. Total Cost of Ownership

TCO:

Infra

SaaS

개발

운영

장애

유지보수

를 합친 개념이다.

✅ 296. 가장 저렴한 Infra가 TCO가 가장 낮은 것은 아니다

✅ 297. 예

직접 DB 운영:

월 3만원 절약

하지만 장애 대응/백업 관리에 월 5시간 더 든다면 비효율적일 수 있다.

✅ 298. 1인 개발자의 가장 비싼 Resource는 시간일 수 있다

✅ 299. 그래서 Cost Optimization의 마지막 기준

이 절약이
내 시간을 쓸 만큼 큰가?

를 묻는다.

✅ 300. Cost Incident Runbook

# Cost Spike Incident

## 1. 증가 항목 확인

EC2
RDS
S3
CloudWatch
Data Transfer
AI

## 2. 증가 시점 확인

## 3. 최근 Release 확인

## 4. Traffic 변화 확인

## 5. Retry / Error 증가 확인

## 6. Log Volume 확인

## 7. Storage Growth 확인

## 8. AI Run 증가 확인

## 9. Idle Resource 확인

## 10. 즉시 조치

- Debug Log OFF
- 잘못된 Job Pause
- AI Low Priority Pause
- Retry Loop 중단

## 11. Destructive Action

Resource 삭제/다운사이징은
원인 확인 후 승인.

## 12. 정상화 확인

## 13. 비용 추정 갱신

## 14. Action Item

✅ 301. Cost Review용 Codex 프롬프트

현재 React + NestJS + Prisma + AWS 기반 프로젝트를
Cost Optimization 관점에서 분석해줘.

코드를 바로 수정하지 말고,
현재 구조에서 비용 증가 요인과
저위험 절감 후보를 먼저 찾는다.

실제 AWS 청구 금액이나 Metric이 제공되지 않은 영역은
비용을 숫자로 추정해서 사실처럼 말하지 않는다.

검토 대상:

1. EC2
2. RDS
3. S3
4. CloudFront
5. CloudWatch Log / Metric
6. Queue / Redis
7. Export Artifact
8. Backup / Snapshot
9. External API
10. AI / LLM
11. Background Worker
12. Staging / Development Resource

각 영역마다 다음을 정리한다.

## Resource / 기능

## 비용이 발생하는 이유

## Waste 가능성

## Reliability를 위해 필요한 비용인지

## 필요한 Metric

## 최적화 후보

## 위험도

LOW / MEDIUM / HIGH

## 예상 적용 난이도

LOW / MEDIUM / HIGH

실제 비용 정보가 없으면
절감 금액을 임의로 만들지 않는다.

특히 다음 패턴을 찾아줘.

- 사용하지 않는 Resource 후보
- 24시간 켜둘 필요가 없는 개발 Resource
- 오래된 S3 Export / Temporary Artifact
- 과도한 Log
- Production DEBUG Logging
- Retention 없는 Log
- 불필요한 Snapshot
- 대량 Data Transfer
- 반복 External API 호출
- 반복 AI Run
- 같은 Input에 중복 LLM 실행
- 대형 Prompt Context
- Worker Idle Resource
- API와 장시간 Worker가 같은 Process를 사용해
  과도한 사양이 필요한 구조

마지막에 다음 네 그룹으로 나눠줘.

1. 즉시 가능한 저위험 절감

2. Metric 확인 후 Right Sizing

3. Reliability 때문에 유지해야 하는 비용

4. 지금은 손대지 않는 것이 좋은 영역

✅ 302. AWS Right Sizing용 Codex 프롬프트

현재 AWS Resource의 Right Sizing을 위한
검증 계획을 작성해줘.

실제 AWS Instance 변경은 수행하지 않는다.

대상:

- EC2
- RDS
- Worker
- Redis가 있다면 해당 Resource

각 Resource마다:

## 확인할 Metric

## 최소 관찰 기간

## Peak 확인 방법

## Downsize 후보 조건

## Downsize 금지 조건

## 변경 전 Load Test

## 변경 후 확인 Metric

## Rollback 기준

을 작성한다.

특히 다음 원칙을 따른다.

1. 평균 CPU만 보고 Downsize하지 않는다.

2. CPU + Memory + Connection + I/O를 같이 본다.

3. Peak Event 기간을 고려한다.

4. Query/Code Regression과
   실제 Capacity 부족을 구분한다.

5. RDS는 Query Optimization을 먼저 검토한다.

6. Application 서버는
   CPU-heavy Worker가 함께 있는지 확인한다.

7. Downsize 후 SLO 악화 시 즉시 Rollback 가능하게 한다.

8. 한 번에 EC2/RDS/Redis를 모두 변경하지 않는다.

9. 변경 전/후 동일 Load Test Scenario로 비교한다.

✅ 303. AI 비용 분석용 Codex 프롬프트

현재 AI / LLM 자동화 코드를
비용 효율 관점에서 분석해줘.

코드 변경 전 분석만 수행한다.

검토 대상:

- Prompt
- Context 구성
- Model 선택
- Retry
- Cache
- Idempotency
- Workflow
- Artifact
- Local LLM / External API

찾을 항목:

1. 동일 Input의 중복 Run

2. 필요 이상으로 큰 Context

3. 같은 파일을 반복 전송

4. 불필요한 Prompt 반복

5. Retry 제한 없음

6. 실패한 요청의 무조건 재실행

7. 작은 작업에 큰 모델 사용

8. Cache 가능한 deterministic 분석

9. 오래된 AI Raw Artifact

10. 생성 후 사용되지 않는 결과

각 항목에 대해:

## 현재 구조

## 비용 낭비 가능성

## 품질 영향

## 개선 방법

## 위험도

를 정리한다.

가능하면 다음 Fingerprint를 활용할 수 있는지 확인한다.

- task
- commitSha
- promptVersion
- contextHash
- model
- policyVersion

동일 Fingerprint 결과가 이미 있으면
재사용 가능한지 판단한다.

단 창의적 생성처럼
매번 다른 결과가 필요한 작업까지
무조건 Cache하지 않는다.

✅ 304. Monthly Cost Review 템플릿

# Monthly Cost Review

## 1. 총 비용

이번 달:

전월:

변화율:

---

## 2. 주요 비용 항목

EC2:

RDS:

S3:

CloudFront:

CloudWatch:

External API:

AI:

---

## 3. Usage 변화

Traffic:

Orders:

Exports:

AI Runs:

Storage:

---

## 4. 비용 증가 원인

---

## 5. 비용 감소 원인

---

## 6. Idle Resource 후보

---

## 7. Right Sizing 후보

---

## 8. Reliability Cost

유지해야 하는 비용:

- Backup
- Monitoring
- Headroom
- Availability

---

## 9. Cost Saving 후보

### 후보 A

예상 효과:

위험:

구현 난이도:

### 후보 B

---

## 10. 이번 달 실행

---

## 11. 다음 달 관찰 항목

✅ 305. Cost Optimization 실무 체크리스트

Cost Visibility

월 AWS 총비용을 알고 있는가?
EC2/RDS/S3/로그 비용을 구분하는가?
전월 대비 증감을 보는가?
비용 증가 시 Traffic 증가와 비교하는가?

Resource

사용하지 않는 EC2가 없는가?
오래된 Volume/Snapshot이 없는가?
Resource Purpose가 명확한가?
Tag가 있는가?
Temporary Resource에 Expiry가 있는가?

EC2

평균뿐 아니라 Peak CPU를 보는가?
Memory를 보는가?
Worker 때문에 과한 사양을 쓰지 않는가?
Downsize 전 Load Test를 하는가?
Vertical Scale이 Architecture 변경보다 나은지 검토하는가?

RDS

CPU를 보는가?
Free Memory를 보는가?
Connection 사용량을 보는가?
Slow Query를 먼저 개선하는가?
Retention으로 DB Growth를 줄이는가?
Backup을 비용 때문에 과도하게 줄이지 않는가?

Storage

Export File에 Retention이 있는가?
Temporary Artifact가 쌓이지 않는가?
S3 Lifecycle을 검토했는가?
다시 생성 가능한 파일을 영구 보관하지 않는가?
Snapshot 목적/Expiry가 명확한가?

CDN / Network

Static Asset이 CDN을 활용하는가?
이미지가 과도하게 크지 않은가?
Responsive Image를 사용하는가?
불필요한 Data Transfer가 없는가?
CDN 비용만 보고 제거하지 않는가?

Logging

Production DEBUG가 꺼져 있는가?
Request Body 전체를 Logging하지 않는가?
Log Retention이 있는가?
Error/Warning/Info 기준이 명확한가?
High Cardinality Metric을 만들지 않는가?

AI

Token 사용량을 기록하는가?
동일 작업을 중복 실행하지 않는가?
Prompt Context를 최소화하는가?
적절한 모델을 선택하는가?
Retry Budget이 있는가?
AI Cache를 적용할 수 있는가?
Run당 비용/시간을 측정하는가?

Reliability

Backup 비용을 단순 낭비로 보지 않는가?
Headroom을 유지하는가?
Monitoring을 지나치게 줄이지 않는가?
비용 절감 후 SLO를 다시 확인하는가?
Downsize Rollback 계획이 있는가?

Process

Waste 제거를 먼저 하는가?
Right Sizing은 Metric 기반인가?
한 번에 하나씩 변경하는가?
변경 후 다시 측정하는가?
예상 절감액보다 구현 비용이 더 크지 않은가?

📌 요약

1007에서는:

우리 시스템은
어디까지 버틸 수 있고

무엇이 먼저 병목이 되는가?

를 다뤘다.

1008에서는 그다음 질문인:

그 Capacity를 유지하면서
얼마나 효율적으로 비용을 쓸 수 있는가?

를 다뤘다.

가장 중요한 원칙은:

Cost Optimization
≠
가장 싼 Infra

라는 것이다.

진짜 목표는:

Performance

+

Reliability

+

Recoverability

를 유지하면서

Waste 제거

다.

가장 먼저 해야 할 일은 복잡한 Architecture 변경이 아니다.

Unused Resource

Old Artifact

Excessive Log

Duplicate AI Run

Overprovisioned Resource

같은 명확한 낭비부터 제거한다.

그다음:

Measure
↓
Right Size
↓
Load Test
↓
Observe

순서로 간다.

EC2/RDS를 줄일 때도:

평균 CPU 낮음

하나만 봐서는 안 된다.

반드시:

Peak CPU

Memory

DB Connection

I/O

Latency

Seasonal Traffic

을 같이 본다.

그리고 중요한 것은:

Reliability Cost

와:

Waste

를 구분하는 것이다.

예를 들어:

안 쓰는 EC2
= Waste

지만:

Backup

Monitoring

Headroom

Multi-AZ

는 의도적으로 지불하는 안정성 비용일 수 있다.

이 비용을 무작정 줄이면 나중에 더 큰 장애 비용을 낼 수 있다.

AI 비용도 같은 원칙이다.

큰 모델을 덜 쓰자

만으로 끝나는 것이 아니라:

중복 Run 제거

Prompt Context 축소

Idempotency

Cache

Retry Budget

작업별 Model 선택

을 조합한다.

특히 같은:

commitSha

promptVersion

contextHash

model

로 이미 결과가 있다면 다시 LLM을 실행하지 않는 것만으로도 낭비를 크게 줄일 수 있다.

비용 판단에서는 결국:

Infra 비용

+

개발 시간

+

운영 시간

+

장애 위험

을 같이 봐야 한다.

즉 가장 싼 AWS Architecture가:

가장 싼 시스템

이라는 보장은 없다.

1인 개발 환경에서는 오히려:

관리형 서비스 사용

구조 단순화

조금 더 여유 있는 서버

가 총비용 관점에서 더 나을 수 있다.

현재 프로젝트에서는 먼저:

1. 월 AWS 비용 Breakdown

2. Idle Resource 정리

3. S3/Export Retention

4. Production Log Volume 정리

5. EC2/RDS Usage Trend 확인

6. Load Test 후 Right Sizing

7. AI Run/Token Budget 기록

순서가 현실적이다.

그리고 비용 절감 변경도:

Plan
↓
Validate
↓
Apply
↓
Health Check
↓
Observe
↓
Rollback

흐름으로 진행한다.

전체 시리즈 흐름으로 연결하면:

Capacity 측정
↓
병목 확인
↓
필요 Capacity 결정
↓
Waste 제거
↓
Right Sizing
↓
Cost Guardrail
↓
Usage/Cost 관찰
↓
재최적화

가 된다.

결국 Cost Optimization의 핵심은

“얼마나 적게 돈을 쓸 수 있는가”가 아니라, 실제 서비스 가치에 필요한 성능·안정성·복구 능력에는 기꺼이 비용을 쓰되, 아무 가치도 만들지 않는 자원·중복 처리·과도한 보관·불필요한 호출에는 돈을 쓰지 않는 것

이다.

juni

이전 포스트