[IT-추천] 컴포즈 services 비용과 선택 기준 – 서버 운영비를 아끼는 판단법

보이지 않는 인프라 비용, 왜 청구서가 예상보다 높을까요

매달 날아오는 클라우드 서비스 청구서를 보며 고개를 갸우뚱한 적이 있으신가요? 분명히 도커 컴포즈를 이용해 필요한 서비스만 딱 맞춰 올렸다고 생각했는데, 예상치를 훌쩍 뛰어넘는 금액이 찍혀 있으면 당혹스러울 수밖에 없어요. 서비스 하나를 추가했을 뿐인데 전체 서버 비용이 요동치는 현상은 인프라 관리자라면 누구나 겪는 흔한 문제입니다.

이런 문제는 대부분 services 블록 내의 설정이 실제 물리적 자원 소모와 어떻게 연결되는지 정확히 파악하지 못했을 때 발생해요. 컨테이너 하나가 차지하는 자원은 단순히 CPU와 메모리에 그치지 않아요. 네트워크 트래픽, 스토리지 I/O, 심지어는 좀비 컨테이너가 점유하는 미세한 자원까지 모두 돈으로 환산되기 때문이에요.

지금 이 글을 읽고 계신 분들은 아마도 한정된 예산 안에서 최대한의 퍼포먼스를 내야 하는 실무 책임자일 거예요. 단순히 서비스를 띄우는 것을 넘어, 어떻게 하면 컴포즈 services 비용을 최적화하고 낭비되는 자원을 잡을 수 있을지 고민하고 계실 겁니다. 오늘 이 글을 끝까지 읽으시면, 막연하게 느껴졌던 컨테이너 운영 비용의 실체를 파악하고 즉시 적용 가능한 비용 절감 전략을 얻어 가실 수 있어요.

오늘 다룰 내용은 다음과 같아요.

• services 블록 구성이 비용에 미치는 결정적 요소 3가지
• 구성 방식에 따른 예상 비용 비교 데이터
• 클라우드 환경에서 과금을 유도하는 대표적인 함정
• 실제 운영 시 바로 적용하는 비용 최적화 설정법

비용 최적화를 위한 사전 지식과 체크리스트

무작정 설정을 바꾸기 전에 우리가 무엇을 기준으로 비용을 바라봐야 하는지 정리할 필요가 있어요. 컨테이너 운영 비용은 크게 직접 비용과 간접 비용으로 나뉘어요. 직접 비용은 우리가 눈으로 확인하는 인스턴스 크기나 스토리지 용량이고, 간접 비용은 네트워크 전송료나 디스크 I/O 작업량처럼 서비스가 돌아가면서 발생하는 부가적인 비용이에요.

효율적인 예산 관리를 위해서는 단순히 ‘저렴한 서버’를 찾는 게 아니라, ‘우리 서비스의 워크로드에 맞는 서비스 블록 구성’을 설계하는 것이 핵심이에요. 예를 들어, 메모리 사용량이 불규칙한 서비스라면 메모리 예약(Reservation) 값을 낮게 잡고 제한(Limit) 값을 넉넉히 두는 전략이 필요하죠. 반대로 트래픽이 몰리는 서비스는 네트워크 대역폭 비용을 미리 계산에 넣어야 해요.

서비스 구성을 결정하기 전, 아래 표를 통해 현재 우리 팀의 우선순위가 어디에 있는지 먼저 점검해 보세요.

준비가 되었다면, 이제 구체적으로 어떤 구성 요소들이 우리의 돈을 가져가는지 하나씩 파헤쳐 볼까요? 단순히 리소스를 많이 쓰는 것이 문제가 아니라, 잘못된 설정으로 인해 낭비되는 자원을 찾는 것이 이번 단계의 진짜 목표예요.

컴포즈 services 비용을 결정하는 5가지 핵심 설계 단계

이제 본격적으로 비용을 만드는 핵심 요소를 분석하고, 어떻게 설계해야 돈을 아낄 수 있는지 살펴볼게요. 각 단계는 실제 인프라를 구축할 때 적용할 수 있는 실무 지침이에요.

STEP 1. CPU와 메모리 자원 제한(Limits) 설정하기

가장 기본적이면서도 강력한 방법은 각 서비스가 사용할 수 있는 자원의 최대치를 정해주는 것이에요. 만약 컴포즈 파일에서 자원 제한을 설정하지 않으면, 특정 서비스에서 메모리 누수(Memory Leak)가 발생했을 때 서버 전체의 자원을 모두 점유해 버릴 수 있어요. 이는 결국 서버가 다운되거나, 이를 방지하기 위해 필요 이상으로 큰 인스턴스를 구독하게 만드는 원인이 돼요.

실무에서는 reservations와 limits를 명확히 구분해야 해요. reservations는 서비스가 최소한으로 보장받아야 하는 자원이고, limits는 서비스가 넘지 말아야 할 상한선이에요. 예를 들어, 웹 서버 서비스라면 CPU는 0.5 코어 정도로 예약하고, 메모리는 512MB로 제한하는 식이죠. 이렇게 하면 한 서비스의 폭주가 전체 인프라 비용 상승으로 이어지는 것을 막을 수 있어요.

STEP 2. 스토리지 볼륨과 I/O 최적화 전략

컨테이너는 기본적으로 휘발성이에요. 데이터를 보존하기 위해 volumes를 사용하는데, 여기서 많은 비용이 새어나가요. 클라우드 환경에서는 스토리지의 용량뿐만 아니라 IOPS(초당 입출력 횟수)에 따라 비용이 기하급수적으로 늘어날 수 있어요.

데이터베이스처럼 읽기/쓰기가 빈번한 서비스는 고성능 SSD 볼륨을 할당해야 하지만, 단순히 로그를 쌓거나 정적 파일을 저장하는 서비스에까지 비싼 스토리지를 할당할 필요는 없어요. 로그 데이터는 별도의 로그 수집 시스템으로 빼거나, 주기적으로 압축하여 저렴한 오브젝트 스토리지(예: AWS S3)로 옮기는 것이 훨씬 경제적이에요. 볼륨 크기를 처음부터 너무 크게 잡지 말고, 모니터링을 통해 필요할 때마다 늘려가는 방식을 추천해요.

STEP 3. 네트워크 트래픽과 데이터 전송료 관리

많은 운영자가 간과하는 부분이 바로 네트워크 이그레스(Egress) 비용이에요. 컨테이너 간의 통신은 내부 네트워크를 통해 이루어지므로 비용이 거의 들지 않지만, 서비스가 외부 인터넷과 통신하거나 다른 지역(Region)에 있는 자원과 데이터를 주고받을 때는 막대한 비용이 발생해요.

컴포즈 구성 시, 서비스들이 가능한 한 같은 가상 네트워크 안에 묶이도록 설계해야 해요. 또한, 외부로 나가는 데이터 양을 줄이기 위해 CDN(Content Delivery Network)을 적극적으로 활용하거나, API 응답 데이터를 압축해서 전송하는 설정을 추가하는 것이 좋아요. 데이터 전송량이 많은 서비스라면 네트워크 대역폭 비용이 서버 인스턴스 비용보다 커지는 배보다 배꼽이 더 큰 상황을 주의해야 해요.

STEP 4. 서비스 복제본(Replica)과 스케일링의 균형

가용성을 위해 서비스를 여러 개 띄우는 것은 당연하지만, 무조건 많은 복제본이 정답은 아니에요. Scale-out 전략을 사용할 때는 트래픽 패턴을 먼저 분석해야 해요. 트래픽이 일정하다면 적은 수의 큰 인스턴스로 운영하는 것이 유리하고, 트래픽 변동이 심하다다면 작은 인스턴스를 여러 개 띄워 필요할 때만 늘리는 방식이 효율적이에요.

특히 컴포즈를 이용한 단일 서버 운영 환경에서는 복제본을 늘리는 것이 서버 자원을 빠르게 고갈시킨다는 점을 명심하세요. 만약 여러 대의 서버를 사용하는 환경이라면, 특정 시간대에만 서비스를 늘리는 오토스케일링(Auto-scaling) 정책을 반드시 결합해야 예산 낭비를 막을 수 있어요.

STEP 5. 환경별(Dev/Prod) 구성 분리

개발(Dev) 환경과 운영(Prod) 환경에 동일한 컴포즈 설정을 사용하는 것은 돈을 버리는 행위와 같아요. 개발 환경에서는 고성능 스토리지나 다중 복제본이 필요하지 않은 경우가 많죠.

따라서 docker-compose.override.yml 파일을 활용하여 환경별로 다른 설정을 적용하는 것이 필수예요. 개발 환경에서는 자원 제한을 거의 두지 않거나 아주 낮게 설정하여 테스트에 집중하고, 운영 환경에서는 앞서 언급한 모든 제약 조건을 엄격하게 적용하여 안정성과 비용을 동시에 잡는 이원화 전략을 사용하세요.

이 모든 단계를 종합하여 하나의 시나리오로 구성해 볼게요. 만약 여러분이 중소규모의 이커머스 서비스를 운영한다면, API 서버는 CPU 0.5/메모리 1GB로 제한하고, 데이터베이스는 고성능 볼륨을 사용하되 백업본은 저렴한 스토리지로 자동 전송되도록 설정하는 것이 가장 현실적인 비용 효율 모델이에요.

자주 하는 실수와 해결법

운영 과정에서 무심코 저지르는 실수들은 생각보다 큰 비용 폭탄으로 돌아와요. 대표적인 사례들을 정리했으니 우리 팀의 설정은 괜찮은지 점검해 보세요.

• ❌ 자원 제한(Limits) 없이 서비스 실행 → 특정 컨테이너가 메모리를 모두 점유하여 서버 전체가 다운되거나, 이를 막기 위해 과도하게 큰 인스턴스를 구매하게 돼요.
  ✅ 해결법: 반드시 deploy.resources.limits를 설정하여 상한선을 두세요.
• ❌ 불필요한 로그 데이터 방치 → 컨테이너 로그가 무한정 쌓여 스토리지 용량을 가득 채우고, 이는 스토리지 증설 비용으로 이어져요.
  ✅ 해결법: logging driver 설정을 통해 로그 파일의 최대 크기와 개수를 제한(log-rotation)하세요.
• ❌ 개발 환경과 운영 환경의 설정 동일화 → 개발용 테스트 서버에서도 운영급 고성능 자원을 할당하여 돈을 낭비하게 돼요.
  ✅ 해결법: 환경별로 별도의 docker-compose.yml 파일을 구성하거나 오버라이드 파일을 사용하세요.
• ❌ 사용하지 않는 볼륨과 이미지 방치
  ❌ 정리되지 않은 네트워크 인터페이스 → 사용하지 않는 자원도 클라우드에서는 비용을 청구할 수 있어요.
  ✅ 해결법: 정기적으로 docker system prune 명령어를 사용하여 미사용 리소스를 정리하세요.
• ❌ 데이터 전송 지역(Region) 불일치 → 서로 다른 리전의 서비스를 연결하면 막대한 네트워크 비용이 발생해요.
  ✅ 해결법: 가급적 동일한 가용 영역(AZ) 내에서 서비스를 배치하세요.

자주 묻는 질문

Q. 컴포즈 services 비용을 가장 빨리 줄이는 방법은 무엇인가요?

가장 즉각적인 효과를 보는 방법은 자원 제한(Limits)을 설정하는 거예요. 현재 실행 중인 서비스들의 실제 사용량을 docker stats로 확인한 뒤, 실제 사용량보다 약간 높은 수준으로 한계치를 설정하면 인스턴스 크기를 줄일 수 있는 여유가 생겨요.

Q. CPU 제한을 너무 타이트하게 걸면 서비스가 느려지지 않나요?

네, 맞아요. CPU를 너무 엄격하게 제한하면 트래픽이 몰릴 때 응답 속도가 급격히 떨어질 수 있어요. 그래서 reservations(최소 보장)는 적절히 유지하되, limits(최대치)를 조금 더 유연하게 설정하여 일시적인 부하를 견딜 수 있게 만드는 것이 노하우예요.

Q. 클라우드 서비스의 자동 스케일링과 컴포즈의 복제본 설정 중 무엇이 더 저렴한가요?

상황에 따라 달라요. 트래픽 변동이 아주 심하다면 클라우드의 오토스케일링이 유리하고, 트래픽이 어느 정도 예측 가능한 범위 내라면 컴포즈에서 복제본 수를 고정해서 운영하는 것이 관리 비용과 인스턴스 비용 측면에서 더 저렴할 수 있어요.

Q. 스토리지 비용을 아끼기 위해 로컬 디스크를 써도 괜찮을까요?

성능 면에서는 유리할 수 있지만, 컨테이너 환경에서는 데이터 영속성과 가용성이 매우 중요해요. 서버 자체가 장애가 나면 로컬 디스크의 데이터도 위험해지죠. 따라서 비용과 안정성 사이의 균형을 고려하여, 중요한 데이터는 클라우드 매니지드 스토리지나 별도의 볼륨 서비스를 사용하는 것을 권장해요.

Q. 로그 관리가 왜 비용에 영향을 주나요?

로그는 결국 파일 형태로 저장되는데, 이 파일이 커지면 스토리지 용량을 차지할 뿐만 아니라, 로그를 읽고 쓰는 과정에서 발생하는 I/O 작업량도 비용(IOPS)에 반영되기 때문이에요. 관리가 안 된 로그는 스토리지 비용과 성능 저하를 동시에 가져와요.

지속 가능한 인프라 운영을 위한 마지막 체크리스트

비용 최적화는 한 번의 설정으로 끝나는 숙제가 아니라, 지속적인 모니터링과 조정이 필요한 과정이에요. 오늘 배운 내용을 바탕으로 지금 바로 여러분의 인프라를 점검해 보세요. 작은 설정 차이가 다음 달 청구서의 숫자를 바꿀 수 있습니다.

자, 이제 무엇을 해야 할까요? 오늘 바로 실행할 수 있는 단계별 가이드를 드릴게요.

• 오늘 할 일: docker stats 명령어로 현재 운영 중인 서비스들의 실제 자원 점유율을 기록해 두세요.
• 이번 주 할 일: 기록된 데이터를 바탕으로 docker-compose.yml 파일의 리소스 제한 값을 현실적으로 수정해 보세요.
• 실행 직전 할 일: 설정을 변경하기 전, 반드시 스테이징 환경에서 서비스가 정상적으로 동작하는지 테스트를 완료하세요.

이번 달 서버 청구서를 다시 한번 열어 보세요. 그리고 오늘 배운 항목별로 비용이 어디서 새고 있는지 비교해 보시기 바랍니다. 효율적인 인프라 관리는 곧 회사의 수익성을 높이는 가장 직접적인 방법이니까요.

관련해서 더 깊이 있는 내용이 궁금하시다면, 도커 컴포즈 기본 개념 완벽 정리 — 개념부터 실무 활용까지 한눈에 보는 가이드 글을 함께 읽어보시는 것을 추천해요.