목차
- 시작은 RunPod 영수증이 1,800달러를 찍은 날
- 견적을 비교했더니 차이가 너무 컸다
- 첫 시도 — 견적과 현실이 1.4배 차이 났다
- 운영 시작하고 깨진 가정들
- 진짜 ROI를 다시 계산했다
- 깨달은 것 — 클라우드가 파는 건 GPU가 아니라 시간이다
- 언제 사고 언제 빌릴지 — 판단 기준
처음 견적을 받았을 때 계산은 단순했다. AWS g6e.12xlarge(L40S 4장)가 온디맨드 시간당 약 $30.65이고, 24/7로 돌리면 한 달에 $21,600이 나온다. 1년이면 $259K다. 비슷한 스펙의 온프렘 서버는 $48K. 산수로는 2.2개월이면 본전이고 그 뒤로는 다 이득이다.
그래서 샀다. L40S 48GB 4장 + Xeon Gold 듀얼 + 512GB RAM + 네트워크/UPS까지 묶어서 정확히 $48,213. 14개월이 지난 지금, 실제 손익분기점이 언제였는지 다시 계산해봤더니 13.8개월이었다. 처음 예상의 6배가 걸렸다. 왜 이렇게 차이가 났는지가 이 글의 본론이다.
시작은 RunPod 영수증이 1,800달러를 찍은 날
한편, 회사 사이드 프로젝트로 한국어 임베딩 모델을 파인튜닝하고, 그걸 사내 RAG 파이프라인에 붙이는 일을 하고 있었다. 초반에는 RunPod 스팟 인스턴스로 L40S 1장을 시간당 $0.79에 빌려서 썼다. 학습 한 번에 6시간, 일주일에 2~3번이면 한 달에 $20도 안 들었다.
게다가, 문제는 추론이었다. RAG 서비스가 사내에 깔리면서 호출량이 늘었고, GPU를 24/7로 띄워둬야 했다. 그러자 청구서가 갑자기 뛰었다. 첫 달 $1,820. 두 번째 달 $2,400. 세 번째 달은 추론용 H100 한 장 더 추가해서 $4,100을 찍었다.
게다가, 이 추세대로면 연간 $50K가 넘어간다. 그 돈이면 차라리 사는 게 낫지 않나? 라는 게 출발점이었다.
견적을 비교했더니 차이가 너무 컸다
물론, 당시(2025년 1월 기준) 견적을 받은 옵션은 셋이었다.
| 옵션 | 초기비용 | 월 운영비 (24/7 가정) | 12개월 총비용 |
|---|---|---|---|
| AWS g6e.12xlarge 온디맨드 | $0 | $21,600 | $259,200 |
| AWS g6e.12xlarge 1년 RI | $0 | $13,500 | $162,000 |
| RunPod L40S x4 정액 | $0 | $3,283 | $39,400 |
| Lambda Labs H100 PCIe x2 | $0 | $4,367 | $52,400 |
| 온프렘 L40S x4 자체 구축 | $48,213 | ~$310 (전력) | $51,933 |
결국, 표만 보면 RunPod이 압도적이다. 그런데 RunPod은 한국 리전이 없다. RTT가 평균 180ms 나왔고, RAG 응답 지연이 사용자한테 그대로 꽂혔다. AWS 서울 리전은 빠르지만 비쌌다. 1년 RI를 끊자니 3년 뒤에 GPU 세대가 또 바뀔 게 뻔했다.
특히, (개인적으로 RI는 3년 약정으로 가지 않는 한 매력이 떨어진다. 1년 RI는 할인폭이 생각보다 작다.)
자체 구축은 초기비용이 크지만 12개월만 굴려도 RunPod에 가깝게 떨어진다는 계산이 나왔다. 결정을 내렸다.
첫 시도 — 견적과 현실이 1.4배 차이 났다
또한, PoC용으로 작은 워크스테이션(L40S 1장)을 먼저 받았다. 여기서부터 헛발질이 시작됐다.
전력이 문제였다
L40S 1장 TDP가 350W다. 4장이면 1.4kW. 거기에 CPU(듀얼 Xeon Gold 6448Y 각 225W), RAM, NVMe까지 합치면 시스템 전체가 풀로드에서 2.1kW를 그었다. 사무실 분전반은 한 콘센트당 16A 단상 220V, 즉 약 3.5kW가 한계다. 여기에 다른 장비까지 물리면 차단기가 내려간다.
실제로 처음 전원을 넣고 학습을 돌렸더니 30분 만에 같은 분전반에 물린 회의실 빔프로젝터가 꺼졌다. 전기 공사를 따로 받아야 했고, 전용 회로 신설 비용이 약 $1,400 추가로 들었다. 이 비용은 처음 견적엔 없었다.
냉각도 만만치 않았다
결국, 서버룸이 없는 사무실이라 PoC 단계에서는 그냥 책상 옆에 뒀다. L40S 4장이 풀로드에 들어가니 옆자리 동료가 "에어컨 켜놨는데도 더운데?"라고 했고, 본인 좌석 온도계가 31도를 찍었다. 결국 IDC 코로케이션으로 옮기기로 했는데, 1U 기준 월 임대료가 한국 평균 $180~$250 사이였다. 우리는 4U 섀시라 월 $310 정도가 든다.
전력비도 계산이 틀렸다. 사무실은 일반용 전력 단가($0.13/kWh)지만 IDC는 전력 사용량에 따라 차등으로 매기는데, 2kW급은 월 $200 정도 추가로 빠졌다.
운영 시작하고 깨진 가정들
::: stats
- 초기 자본 지출: $48,213
- 추가 인프라(전기 공사, 랙 마운트 키트): $2,100
- 월 IDC + 전력: $510
- 첫 6개월 다운타임: 누적 47시간
- 14개월 후 손익분기 도달: 누적 회피 비용 $50,820 :::
한편, 표만 보면 매끄럽지만 6개월 누적 다운타임 47시간이 가장 아팠다.
NVMe가 한 번, 메인보드 BIOS가 두 번
게다가, 설치 후 두 달째에 학습 데이터셋을 올려둔 NVMe 한 장이 죽었다. RAID0로 묶어둔 게 잘못이었다. 백업이 별도 NAS에 있었지만 복구하는 데 8시간이 걸렸다. 이 시간 동안 RAG 서비스는 RunPod 임시 인스턴스로 우회시켜야 했고, 그 비용이 $34 추가됐다.
BIOS 업데이트는 더 짜증났다. L40S가 PCIe Gen5 슬롯을 제대로 인식하지 않아서 한 장이 Gen3로 동작하고 있었던 거다. nvidia-smi -q | grep "PCIe Generation" 찍어보니 한 장만 Current: 3. 메인보드 펌웨어를 두 번 올리고서야 해결됐다. 그 사이 학습 throughput이 30% 떨어진 상태로 한 달을 굴렸다는 걸 나중에 알았다.
실제로, 이런 시행착오가 클라우드였으면 발생하지 않았을 일이다. AWS는 하드웨어 추상화를 비싸게 팔지만, 그 가격에는 이런 잡일 시간도 포함돼 있는 거였다.
활용률이 100%가 아니었다
가장 큰 착각이 이거였다. 처음 ROI 계산에서 클라우드 비용을 "24/7 100% 활용"으로 잡고 비교했는데, 실제 우리 GPU 활용률을 한 달 측정해봤더니 평균 **43%**였다. 추론 트래픽이 한국 시간 기준 9시~22시에 몰리고, 새벽에는 0에 가까웠다. 학습 잡이 새벽 시간을 어느 정도 채워주긴 했지만 그래도 평균이 절반을 못 넘었다.
또한, 이 말은 "AWS 24/7로 환산한 회피 비용"이 부풀려진 수치라는 뜻이다. 실제로 우리가 클라우드로 갔다면 오토스케일링이나 스팟을 썼을 거고, 청구서가 $21,600이 아니라 $11,000 수준이었을 가능성이 높다. 이 보정을 넣고 다시 계산하니 손익분기점이 약 14개월로 밀렸다.
진짜 ROI를 다시 계산했다
특히, 처음 계산은 너무 낙관적이었다. 14개월 운영하고 나서 모든 숨은 비용을 다 넣어서 다시 그려봤다.
| 항목 | 14개월 누적 |
|---|---|
| 초기 자본 지출 | $48,213 |
| 전기 공사·랙 부속 | $2,100 |
| IDC + 전력 (14개월) | $7,140 |
| 다운타임 우회 클라우드 비용 | $190 |
| 부품 교체(NVMe 2장) | $640 |
| 총 지출 | $58,283 |
| 회피된 클라우드 비용(실측 활용률 기준) | $58,510 |
| 누적 손익 | +$227 |
14개월 만에 겨우 본전을 넘긴 거다. 처음 계산했던 2.2개월은 환상이었다.
그래도 이 다음부터는 월 $510(전력+IDC)만 들어간다. 클라우드로 갔으면 매달 $4,000을 계속 토해냈을 거라는 점을 생각하면, 15개월차부터는 매달 $3,500씩 순이익이 쌓이는 구조다. 3년치로 펼치면 결과적으로는 잘한 선택이다. 다만 "1년 안에 본전"은 거짓말이었다.
깨달은 것 — 클라우드가 파는 건 GPU가 아니라 시간이다
처음엔 AWS가 시간당 $30을 받아가는 게 강도짓 같았다. L40S 1장 원가가 $8,000이고 3년 감가하면 시간당 $0.30밖에 안 되는데 100배를 받는다.
14개월 굴려보고 나서는 생각이 바뀌었다. 그 차액에는 이런 게 들어 있다.
- 새벽 3시에 BIOS 올리지 않아도 되는 시간
- 펌웨어 호환성 디버깅 안 해도 되는 정신적 비용
- 다운타임 났을 때 다른 가용영역으로 즉시 옮길 수 있는 능력
- 갑자기 H200이 나와도 인스턴스 타입만 바꾸면 되는 유연성
즉, ::: tip 온프렘이 답이 되는 조건은 명확하다. (1) 활용률이 60% 이상이고, (2) 18개월 이상 안정적으로 워크로드가 유지되고, (3) 하드웨어를 직접 만질 사람이 1명 이상 있을 때. 셋 중 하나라도 불확실하면 클라우드가 싸다. :::
언제 사고 언제 빌릴지 — 판단 기준
이처럼, 같은 결정 앞에 있는 사람이라면 아래 3가지를 먼저 계산해보면 된다.
결국, 1. 6개월간 실측 활용률을 먼저 뽑아라. RunPod이든 AWS든 일단 빌려서 6개월 굴리고, nvidia-smi --query-gpu=utilization.gpu --format=csv -l 60을 cron에 걸어서 평균을 내라. 우리는 이걸 안 하고 "당연히 100%일 거다"라고 가정했고, 그게 ROI 추정의 가장 큰 오류였다.
2. 손익분기점에 1.5배를 곱하라. 처음 엑셀로 두드린 숫자가 8개월이면 실제로는 12개월 걸린다고 생각해야 한다. 견적엔 없는 전기 공사, 부품 고장, BIOS 삽질 시간이 반드시 발생한다.
3. 워크로드가 1년 뒤에도 살아있을지 자문해라. LLM 분야는 모델이 6개월마다 바뀐다. 지금 파인튜닝 중인 모델이 1년 뒤에도 유효할 거란 보장이 없으면 자본 지출은 위험하다. 학습 워크로드는 임시성이 크고, 추론 워크로드는 지속성이 크다. 추론 중심이면 사고, 학습 중심이면 빌려라가 14개월 운영하고 내린 결론이다.
당장 할 수 있는 액션 셋:
- 지난 3개월 클라우드 GPU 청구서에서 인스턴스별 평균 활용률을 뽑아 본다(CloudWatch
GPUUtilization또는 RunPod usage export). - 회피 비용을 "온디맨드 24/7"이 아니라 "실측 활용률 × 스팟 단가"로 다시 계산해본다.
- 견적서에 **전기 공사 + IDC 임대 + 18개월치 부품 교체 예비비 10%**를 미리 더해서 의사결정한다.
참고 자료:
관련 글
- Redis 캐시 전략 비교 — LRU·LFU·allkeys로 maxmemory 다루기 – 프론트엔드에서 백엔드로 넘어온 지 2년. Redis OOM 에러를 만나고서야 maxmemory-policy를 제대로 본다. LRU와 LFU…
- AWS 다시 써보니 떠난 이유 더 명확함 — 3개월 회고 – 2년 만에 다시 만진 AWS의 3개월 기록이다. RDS Performance Insights는 빛났고 NAT Gateway 청구서는 폭탄이…
- AWS 3개월 쓰다가 다시 떠난 이유 – 결국 뭐가 문제였나 – GCP에서 AWS로 옮긴 뒤 3개월 만에 짐을 다시 쌌다. 청구서가 두 배 넘게 찍히기까지의 시간순 기록과, 떠나기 전에 했어야 할 것들을…