운영 비용 최적화는 왜 인프라 절감보다 구조 문제에 가깝나

운영 비용 최적화라고 하면 대부분 ‘더 작은 인스턴스를 쓰자’, ‘예약 인스턴스를 구매하자’ 같은 인프라 가격 절감을 떠올린다. 물론 이것도 유효한 방법이지만, 더 큰 비용 절감은 구조적 비효율을 해결하는 데서 온다. 필요 없는 리소스를 끄는 것, 비효율적인 배치 작업을 최적화하는 것, 데이터 복제를 줄이는 것 — 이런 구조적 변경이 인스턴스 크기 변경보다 훨씬 큰 절감 효과를 가져온다.

이 글은 Breeze 플랫폼의 운영 비용 최적화 경험을 통해, 비용 문제가 실은 시스템 아키텍처의 문제임을 주장한다. 비용 최적화를 제대로 하려면 시스템을 이해해야 하고, 시스템을 이해하면 비용 외에도 성능과 안정성이 함께 개선된다.

엔지니어가 비용에 관심을 가져야 하는 이유도 함께 기록한다. 비용은 경영진의 관심사이고 엔지니어의 관심사가 아니라는 인식은 잘못된 것이다. 비용 낭비는 대부분 기술적 결정에서 비롯되므로, 엔지니어가 비용을 이해하고 고려해야 한다.

클라우드 비용은 사용한 만큼 과금되는 구조이므로, 리소스를 효율적으로 사용하지 않으면 비용이 불필요하게 증가한다. Breeze 플랫폼도 시간이 지나면서 운영 비용이 점진적으로 증가했다. 새로운 기능이 추가될 때마다 서버가 늘어나고, 테스트를 위해 생성한 리소스가 삭제되지 않고 남아 있으며, 한때 필요했지만 더 이상 사용하지 않는 서비스가 계속 실행 중인 경우가 있었다.

비용 증가의 원인을 분석하려면 먼저 비용이 어디서 발생하는지를 파악해야 한다. AWS Cost Explorer나 유사 도구를 사용하여 서비스별, 리소스별 비용을 분류하고, 상위 비용 항목을 식별하는 것이 첫 단계였다.

비용 최적화는 단순한 절감이 아니라, 같은 서비스를 더 적은 비용으로 제공하는 효율성의 문제다. 비용을 줄이면서 성능이나 안정성이 저하되면 안 되므로, 비용과 서비스 품질 사이의 균형을 잡는 것이 핵심이다.

실행 순서

Auto-scaling 부재로 인한 과잉 프로비저닝

Breeze 플랫폼의 서버 인프라는 피크 트래픽을 기준으로 프로비저닝되어 있었다. The Draw 등 고트래픽 이벤트에 대비하여 서버 수를 넉넉하게 유지하고 있었는데, 이벤트가 없는 평상시에는 이 서버들이 유휴(idle) 상태로 비용을 소모하고 있었다.

auto-scaling이 도입되어 있었다면 트래픽에 따라 서버 수가 자동으로 조절되어 평상시 비용을 줄일 수 있었다. 당시 구조에서는 스케일링 제약과 운영 복잡도로 인해 수동 프로비저닝 비중이 컸고, 결과적으로 auto-scaling 부재가 가장 큰 구조적 비용 요인이 되었다.

미사용 리소스: 잊혀진 서버와 데이터

시간이 지나면서 더 이상 사용되지 않는 리소스가 쌓였다. 테스트 목적으로 생성된 EC2 인스턴스, 과거 기능의 데이터를 저장하던 RDS 인스턴스, 이전 버전의 AMI(Amazon Machine Image), 오래된 S3 버킷의 데이터 등. 이런 미사용 리소스는 눈에 잘 띄지 않지만 지속적으로 비용을 발생시킨다.

미사용 리소스를 식별하고 정리하는 작업은 간단해 보이지만, ‘정말 사용하지 않는 것인가?‘를 확인하는 것이 어렵다. 아무도 쓰지 않는다고 생각하고 삭제했더니 특정 배치 작업이 참조하고 있어 장애가 발생하는 경우가 있을 수 있다. 삭제 전에 의존성을 확인하는 과정이 필요했다.

비효율적 배치 작업: 피크 시간에 도는 배치

배치 작업(batch job)은 주기적으로 대량의 데이터를 처리하는 작업이다. 상품 데이터 동기화, 재고 업데이트, 리포트 생성 등의 배치 작업이 있었다. 이 배치 작업 중 일부가 서비스 피크 시간대(낮 12시~오후 6시)에 실행되고 있어, 서비스 트래픽과 배치 부하가 동시에 인프라에 가해지는 상황이 발생했다.

배치 작업을 오프피크 시간대(새벽 2시~6시)로 이동시키는 것만으로도 비용 절감 효과가 있었다. 피크 시간에 배치가 돌지 않으면 그 시간의 서버 부하가 줄어들고, 필요한 서버 수가 줄어든다. 또한 배치 작업 자체의 성능도 개선되었다 — 서비스 트래픽과 리소스를 경쟁하지 않으므로 배치 처리 시간이 단축되었다.

데이터 중복 저장의 비용

같은 데이터가 여러 곳에 복사되어 저장되는 경우가 있었다. 예를 들어, 상품 데이터가 RDS, Solr, 캐시, S3 등 여러 저장소에 중복으로 존재했다. 각 저장소에는 나름의 목적이 있었지만(검색 최적화, 캐시 성능 등), 데이터 동기화 비용과 저장 비용이 중복으로 발생했다.

데이터 중복 자체가 나쁜 것은 아니다 — 성능을 위해 의도적으로 중복하는 것은 정당한 trade-off다. 문제는 더 이상 필요하지 않은 중복, 또는 비효율적인 동기화 방식이다. 예를 들어, 전체 데이터를 매번 복사(full sync)하는 대신 변경분만 동기화(incremental sync)하면 처리량과 저장 비용 모두 줄일 수 있다.

비용 가시성(Cost Visibility)의 중요성

비용 최적화의 첫 단계는 비용의 가시성(visibility)을 확보하는 것이다. 전체 클라우드 비용이 얼마인지만 아는 것이 아니라, 어떤 서비스가 얼마를 쓰고 있는지, 지난 달 대비 어떤 항목이 증가했는지를 파악할 수 있어야 한다.

비용 가시성이 없으면 최적화 대상을 식별할 수 없다. AWS Cost Explorer의 태그(tag) 기반 비용 분류를 도입하여, 각 서비스와 환경(prod, staging, dev)의 비용을 분리하여 추적했다. 이를 통해 staging 환경이 prod만큼 비용을 쓰고 있다는 사실을 발견하고, staging의 리소스를 축소하는 등의 조치를 취할 수 있었다.

엔지니어가 비용에 관심을 가져야 하는 이유

비용 최적화는 인프라팀이나 FinOps 팀의 일이라고 생각하기 쉽지만, 비용의 대부분은 엔지니어의 기술적 결정에서 발생한다. 어떤 DB를 선택하는지, 데이터를 어떻게 저장하는지, 캐시를 어디에 두는지, 배치를 어떻게 설계하는지 — 이런 결정이 비용을 결정한다. 비용을 이해하는 엔지니어는 같은 기능을 더 효율적으로 구현할 수 있다.

운영 안정성과 보안은 개별 도구의 문제가 아니라 개발 흐름과 운영 기준을 바꾸는 구조적 작업이었다.

비용 최적화 아키텍처의 장단점

구조 기반 비용 최적화의 장점은 일회성 절감이 아니라 지속 가능한 절감을 만든다는 점이다. 배치 스케줄, 데이터 동기화 방식, 환경 분리 기준을 손보면 동일 기능을 더 낮은 비용으로 유지할 수 있다.

단점은 단기 효과가 늦게 보일 수 있다는 점이다. 인스턴스 즉시 축소처럼 빠른 절감보다, 설계 변경은 검증 기간이 필요하다. 하지만 장기 운영 관점에서는 후자가 재발 비용을 줄이고 총비용을 안정화한다.

비용 최적화 구조 점검표

• 고비용 경로를 요청 유형/시간대/의존 서비스 기준으로 분해한다.
• 인프라 절감 전, 재시도/중복 호출/불필요한 동기 처리부터 제거한다.
• 비용 절감 효과는 월간 절감액과 장애 재발률을 함께 본다.

절감 접근 비교