[도서리뷰] 요즘 개발자를 위한 AWS 비용 최적화

이 글은 서평단으로 참여해 작성한 리뷰입니다.

그동안 프로젝트는 AWS 프리티어만 써봤었고, 다들 학생이라 무료인지가 가장 중요했다.
처음에 AWS 프리티어를 쓸 때도 예상하지 못한 비용(?)이 나올까 봐 조심스러웠다.

 

돈이 얼마나 나오는지, 뭐가 뭔지 잘 모르니까 그랬다~

 

그러다 우테코에서는 AWS 인프라를 지원받아 실제 서비스를 운영할 기회가 생겼다.
지금은 EC2, RDS, S3, CloudWatch, Bedrock 등을 쓰고 있는 중이다.

 

그런데 지원비 내에서 서비스를 운영하다 보니 이전에는 생각지 못했던 부분들이 생겼다.
(프리티어였기도 하고, 사실 뭐가 뭔지 몰라서 감도 안잡혔다)

 

우리 프로젝트에는 어떤 자원에 비용이 얼마나 나오고 있을까?

 

AWS를 사용하고는 있는데, 실제 운영 비용을 설명해 보라고 하면 선뜻 답하기 어려웠다.
그동안 프리티어만 써보다가, 지금 부딪치면서 배우고 있는데 아직도 막연하긴 하다.

《요즘 개발자를 위한 AWS 비용 최적화》는 이런 심정에서 읽게 된 책이다.

 

실제로는 유광 금색이라 흑금 조합 말안된다;;

 

AWS 비용은 어디에서 발생할까? 🤷

이 책을 읽으면서 내용만큼이나 흥미로웠던 건 저자들이었는데,
KB국민은행 클라우드 인프라를 운영해 온 엔지니어들이 쓴 책이라고 한다.

사실 금융권은 보안이나 안정성 때문에 클라우드보다 온프레미스 환경을 주로 사용할 거라고 생각했었다.

 

2026 if 카카오

그러다 얼마 전 다녀온 2026 카카오 컨퍼런스에서도 카카오뱅크의 클라우드와 오픈소스 전환 이야기를 들었는데,
그땐 ‘아~ 카카오뱅크는 금융 서비스긴 해도 IT 성격이 강하니까 가능한가 보다’ 하고 생각했었다.

 

그런데 KB국민은행에서도 클라우드로 운영하고, 비용 관리 체계까지 고민하고 있었다.
내가 상상하던 금융권 모습보다 클라우드가 훨씬 깊숙히 침투해 있었다는 게 놀라웠다.
그런 환경을 운영해 온 사람들이 안정성을 고려하면서 비용을 어떻게 관리하는지 궁금해졌다.

 

이 책은 클라우드 비용 관리 기본 개념부터 AWS 비용이 발생하는 영역을 폭넓게 다룬다.
뒷부분에서는 비용 모니터링과 AI 기반 비용 최적화도 소개한다.

 

다중 계정 관리나 조직 차원의 비용 관리처럼 지금 바로 적용하기엔 어려운 내용도 있지만,
EC2 인스턴스 사양, 로그 보관, 비용 모니터링처럼 프로젝트를 떠올리면서 읽을 수 있는 부분도 있다.

 

 

☝️ EC2 인스턴스 이름은 왜 이렇게 생겼을까?

일단 대부분 EC2나 RDS를 기본적으로 쓰니 비용도 그쪽에서 많이 나간다.
근데 뭐가 얼마나 왜 나가는 걸까?

 

이걸 이해하려면 이름부터 알아야 하는데,
EC2를 처음 만들 때 인스턴스 목록을 보고 뇌정지가 왔던 기억이 떠오른다.

 

t, m, c로 시작하는 이름들이 줄줄이 나오는데, 뒤에는 숫자와 알파벳까지 붙어 있다.
비슷해 보이는 이름인데 사양도 가격도 달라서 이게 뭔고? 싶었다.

 

하지만 그것도 다 규칙이 있었으니,

 

다~ 규칙이 있다

 

예를 들어 c6i.4xlarge는 다음처럼 나눠서 읽을 수 있다.

c       6       i       .4xlarge
패밀리   세대    프로세서    인스턴스 크기

 

c는 컴퓨팅 최적화 계열, 6은 인스턴스 세대, i는 Intel 프로세서를 뜻한다.
4xlarge는 인스턴스 크기이고, 패밀리마다 중점을 둔 자원도 다르다.

 

안그래도 최근에 크루들이 t모델과 m, c 모델에 대해 알려줘서 나도 그때 처음 알게됐다.

 

C	컴퓨팅 최적화
M	CPU와 메모리를 고르게 제공하는 범용 계열
R	메모리 최적화
T	필요할 때 CPU 성능을 더 사용할 수 있는 버스터블 계열
I	스토리지 최적화

뒤에 붙은 크기는 메모리만을 가리키는 건 아니고, 크기와 패밀리에 따라 vCPU, 메모리 등의 사양이 정해진다.

 

예를 들어 c6i.4xlarge는 vCPU 16개와 메모리 32GiB를 제공하지만, 다른 패밀리의 4xlarge는 메모리 구성이 다를 수 있다.
자세한 이름 규칙과 사양은 AWS 인스턴스 명명 규칙과 인스턴스 사양 문서에서 확인할 수 있다.

 

 

이름을 읽을 수 있게 되니 인스턴스를 비교할 때 살펴봐야 할 것도 조금씩 보이기 시작했다.
CPU 바운드인지, 메모리를 많이 쓰는지, 특정 시간에만 사용량이 몰리는지에 따라 적합한 게 달라진다.

 

 

🤔 우리 서버도 더 작은 인스턴스를 사용할 수 있을까?

실제 사용량에 맞춰 인스턴스 사양을 선택하는 RightSizing 파트를 읽고 우리 서버도 궁금해졌다.

 

운영 서버 인스턴스를 더 작은 크기로 바꿔도 충분히 감당 가능하면 비용을 줄일 수 있겠지.
그래서 CloudWatch에서 최근 4주 CPU, 메모리, swap과 CPU 크레딧 지표를 확인해 봤다.

 

CPU 평소 사용률은 대체로 낮았고, 간헐적으로 높아지는 구간이 있었다.
사용 중인 인스턴스는 T 계열인데, CPU 크레딧도 조회 기간 동안 대부분 충분히 쌓여 있었다.

 

메모리는 조금 달랐는데, 지금 서버에서도 최근 며칠 동안 사용률이 절반 안팎이었다.
작은 인스턴스는 메모리가 절반 줄어드니, 지금 사용량을 생각하면 여유롭다고 보긴 어려웠다.
메모리 지표가 비어 있는 구간도 있어서 그래프만으로 후보 인스턴스가 충분하다고 판단하기는 어려웠다.

 

 

결국 이번에는 인스턴스를 변경하지 않았다.
CPU 그래프만 봤다면 다른 판단을 했을지도 모르겠다.
실제 메모리 사용량과 배포, 재시작 시점의 사용량을 더 확인하고, 개발 환경에서 작은 사양으로 실행해보려 한다.

 

 

Graviton 짱짱맨?

책에서는 다른 프로세서와 비교해서 Graviton의 우수한 성능을 설명했는데,
호환성 문제를 고려해 RDS나 OpenSearch, ElasticCache 등의 인스턴스에 전환해볼 걸 권장했다.

AWS Graviton 활용 가이드

 

 

👻 Kiro와 Trusted Advisor도 궁금해졌다

KIRO

 

책을 읽다가 Kiro와 Trusted Advisor에도 관심이 갔다.

Kiro는 AWS에서 만든 AI 개발 도구인데, 채팅으로 질문하거나 코드를 작성할 수 있고, 요구사항을 정리해 설계와 작업 목록으로 나누는 스펙 기반 개발도 지원한다.
IDE와 CLI 형태로 사용할 수 있고 자세한 내용은 Kiro 공식 문서

 

내가 궁금했던 건 Kiro가 앞서 확인한 CloudWatch 지표를 어떻게 해석할지였다.
CPU 사용률은 낮지만 메모리가 절반 안팎인 상황에서, 인스턴스 크기를 줄여도 되는지 물어보면 어떤 근거를 들까? 내가 놓친 확인 항목은 없을까?

 

아직 직접 실험해 보지는 않았고, 나중에 Kiro의 판단이랑 내가 내린 판단을 비교해보려 한다.

 

AWS Trusted Advisor

AWS Trusted Advisor도 궁금해서 프로젝트 계정으로 들어가 봤다.
Trusted Advisor는 AWS 환경을 점검하고 비용 최적화, 보안, 성능 등에 관한 권고를 제공하는 서비스다.

 

우리 프로젝트에는 어떤 권고가 나올지 기대했는데, 아쉽게도 크루 계정에는 접근 권한이 없어 결과를 확인하지 못했다..
나중에 접근할 기회가 생긴다면 실제 권고를 살펴보고, 우리 프로젝트에도 적용할 만한 내용인지 확인해 보고 싶다.

 

 

책을 읽고

프리티어를 쓸 때는 비용이 발생하지 않는지에만 신경썼었는데,
이젠 지원비용 내에서 서비스를 운영하면서, 어디에 비용이 발생하고 지금 사용하는 사양이 적절한지 고민하게 됐다.

 

책을 읽고 바로 비용을 줄인 건 아니지만, 우리 서버 지표를 확인하면서 인스턴스를 더 작게 바꾸려면 CPU뿐 아니라 메모리와 크레딧도 함께 봐야 한다는 걸 프로젝트를 통해 생각해 볼 수 있었다.

 

AWS로 프로젝트를 만들어 봤지만 운영 비용은 여전히 막연한 학생이나 취업 준비생이라면,
이 책에서 지금 사용 중인 서비스와 관련된 부분부터 읽어봐도 좋겠다.

 

나처럼 익숙했던 EC2부터 다시 살펴보게 될지도 모르겠다~