선정 이유
IDC 계약 갱신 시즌이 다가오면서 IT팀은 하드웨어 도입 예산서를 재무팀에 제출해야 한다. 서버 증설 승인은 3개월째 CEO 책상 위에서 움직이지 않는다. 이때 누군가 던지는 질문이 있다. “이걸 AWS로 전환하면 진짜로 얼마나 줄일 수 있을까?” 단순한 비용 비교가 아니다. 자산과 비용의 성격이 바뀌는 재무 구조의 변화이자, 현금흐름 패턴을 재설계하는 전략적 의사결정이다.
CapEx와 OpEx의 구조적 차이점
기업 내부의 회계팀이 클라우드 전환을 반기지 않는 이유는 단순하다. 자산에서 비용으로 이동하는 금액의 성격이 달라지기 때문이다.
CapEx(자본지출)는 서버, 스토리지, 네트워크 장비를 구매하는 행위다. 한 번에 큰 돈이 나가지만, 자산으로 잡히고 감가상각을 통해 여러 해에 걸쳐 비용처리된다. 재무제표상 유형자산이 늘어나는 구조다.
반면 OpEx(운영비용)는 AWS 사용료다. 매달 나가는 돈이며, 당기 비용으로 전액 인식된다. 세금 계산 시즌에 회계팀이 선호하는 방식은 아닐 수 있다. 하지만 현금흐름 관점에서는 전혀 다른 그림이 펼쳐진다.
| 구분 | CapEx (온프레미스) | OpEx (AWS) | 재무적 영향 |
|---|---|---|---|
| 초기 투자 | 높음 (하드웨어 구매) | 낮음 (사용한 만큼) | 현금 유출 시점 차이 |
| 비용 인식 시점 | 감가상각 (3~5년) | 당기 전액 비용 | 세무 이익/손실 변동 |
| 유연성 | 낮음 (장비 처분 어려움) | 높음 (즉시 확장/축소) | 사업 변화 대응력 |
| 예측 가능성 | 높음 (일정 비용) | 변동 (사용량 기반) | 예산 편성 복잡도 |
AWS TCO 분석 방법론
TCO(Total Cost of Ownership) 계산은 단순한 숫자 놀음이 아니다. 인프라를 운영하는 조직의 숨은 비용—데이터센터 임대료, 전기요금, 심지어 정전 위험에 대비한 UPS와 비상 발전기 유지비까지—모두를 현금흐름에 할당해야 비로소 진짜 그림이 보인다.
AWS는 공식 TCO Calculator를 제공한다. 이 도구는 온프레미스 인프라의 스펙을 입력하면, 동등한 AWS 서비스로 전환 시 예상 비용을 산출한다. 하지만 이 계산기의 함정은 ‘직접 비용’만 비교하기 쉽다는 점이다.
진정한 TCO 분석에는 다음이 포함되어야 한다.
– 직접 비용: 하드웨어 구매비, 소프트웨어 라이선스, AWS 서비스 요금
– 간접 비용: 데이터센터 임대, 전기/냉방비, 네트워크 회선료
– 운영 비용: 인프라 엔지니어 인건비, 24/7 모니터링 인력, 정기 유지보수
– 기회 비용: 서버 프로비저닝 대기 시간, 유휴 자원, 장애 복구 시간
특히 주목해야 할 것은 인건비다. IDC를 운영하는 기업은 평균적으로 서버 100대당 2~3명의 인프라 엔지니어가 필요하다. AWS로 전환 시 이 인력은 애플리케이션 개발이나 아키텍처 최적화에 투입될 수 있다. 이 숫자를 뺀 계산은 의미가 없다.
전환 시나리오별 비용 모델링
Lift-and-shift(재호스팅) 방식과 Refactoring(재설계) 방식은 비용 구조가 완전히 다르다.
단순히 VMware 워크로드를 EC2로 옮기는 경우, 초기 비용은 낮지만 장기적으로는 1:1 매핑으로 인해 비용이 증가할 수 있다. 반면 컨테이너화하거나 서버리스로 전환하면 개발 비용이 들지만 운영 비용이 급감한다.
시나리오별 3년 TCO 비교 모델은 다음과 같다.
| 전환 방식 | 초기 1년 비용 | 2년차 비용 | 3년차 비용 | 핵심 변수 |
|---|---|---|---|---|
| 온프레미스 유지 | 높음 (하드웨어 교체) | 중간 | 중간 | 장비 교체 주기 |
| Lift-and-shift | 낮음 | 중간 | 높음 | EC2 사용량 증가 |
| Refactoring | 높음 (개발 비용) | 낮음 | 매우 낮음 | Lambda/S3 사용 최적화 |
결정적 변수는 ‘유휴 자원률’이다. 온프레미스 환경에서는 피크 트래픽에 대비해 평균 70~80%의 자원이 유휴 상태로 존재한다. AWS는 Auto Scaling으로 이를 10~20%까지 줄일 수 있다. 이 숫자 하나로 TCO는 역전된다.
실행 가능한 비용 절감 전략
전환 후에도 AWS 비용은 통제하지 않으면 기하급수적으로 늘어난다. FinOps 프레임워크 적용 없이는 OpEx의 유연성이 오히려 재앙이 된다.
즉시 실행 가능한 세 가지 전략이 있다.
Reserved Instances(RI)와 Savings Plans(SP)
온디맨드 요금 대비 최대 72%까지 절감 가능하다. 1년 또는 3년 약정을 통해 컴퓨팅 파워를 미리 구매하는 방식이다. RI는 인스턴스 패밀리가 고정되어야 하지만, SP는 유연하게 워크로드를 옮길 수 있다. 예측 가능한 워크로드가 70% 이상이라면 RI/SP 도입은 필수다.
Graviton2/3 마이그레이션
ARM 기반 AWS 자체 프로세서로 전환하면 동일 성능 대비 20~40% 비용이 절감된다. 대부분의 오픈소스 워크로드는 재컴파일만으로 마이그레이션이 가능하다.
스토리지 계층화
S3 Standard-IA, Glacier, Glacier Deep Archive로 데이터를 자동 이동시키는 라이프사이클 정책을 설정한다. 접근 빈도가 낮은 데이터를 Deep Archive로 옮기면 GB당 비용이 1/10 이하로 떨어진다.
자주 묻는 질문
Q. TCO 분석 시 반드시 포함해야 하는 숨은 비용은 무엇인가요?
A. 데이터센터 임대료와 전기요금 외에도, ‘인건비’와 ‘기회비용’이 핵심이다. 서버 프로비저닝에 소요되는 평균 4~6주의 대기 시간을 비용화하면, 비즈니스 기회 상실 비용이 하드웨어 가격을 초과할 수 있다. 또한 재해 복구(DR)를 위한 이중화 인프라 유지비용도 클라우드에서는 서비스 레벨에 따라 유연하게 조정 가능하다.
Q. CapEx에서 OpEx 전환 시 재무제표에 미치는 영향은?
A. 자산 대비 비용 비중이 증가하여 당기 순이익이 감소할 수 있다. EBITDA(세전영업이익)는 개선되나, 순이익 단계에서는 일시적 감소가 나타날 수 있다. 다만 현금흐름표에서는 초기 투자 부담이 사라져 영업활동 현금흐름이 개선된다. 투자 유치나 대출 시 차입금 상환능력(Coverage Ratio) 산정 방식도 변화하므로, 전환 전 재무팀과의 사전 협의가 필수다.
Q. Reserved Instance와 Savings Plans 중 어떤 것을 선택해야 하나요?
A. 워크로드의 예측 가능성과 유연성에 따라 다르다. EC2 인스턴스 패밀리와 리전을 1~3년간 변경하지 않을 확신이 있다면 RI가 더 높은 할인율을 제공한다. 반면 MSA 아키텍처로 컨테이너를 옮겨다니거나, 리전 간 워크로드 이동이 잦다면 SP가 유리하다. 대부분의 기업은 두 가지를 혼합하여 사용하며, 예측 가능한 베이스로드는 RI로, 변동성 있는 워크로드는 SP로 커버하는 전략이 일반적이다.