탄소 배출량을 넘어, 클라우드 인프라의 또 다른 환경 지표인 ‘물 사용량’까지 분석 가능한 시대가 열렸습니다. AWS가 7월 16일 공개한 AWS Sustainability의 워크로드별 연간 Water Withdrawals(물 취수량) 데이터 제공 기능은 “ESG 보고용 숫자”를 넘어, Software Infra 운영 자체에 환경 메트릭을 편입시키는 변화로 읽어야 합니다.
Software Infra에 새로 추가된 메트릭: 워크로드별 Water Withdrawals란?
이번 기능의 핵심은 간단합니다. 이제 AWS가 데이터센터 운영 과정에서 사용되는 물(연간 취수량)을, 워크로드 관점에서 다음 축으로 쪼개 콘솔과 API로 제공한다는 점입니다.
- Region(리전) 별
- Service(서비스) 별
- Account(계정) 별
즉, “우리 조직이 AWS에서 물을 얼마나 썼는가?”라는 질문을 막연한 추정이 아니라, 운영 데이터로 조회할 수 있게 된 것입니다. 특히 API 제공이 결정적입니다. 수동 다운로드가 아니라, 기존 리포팅/대시보드/데이터 파이프라인에 정기 수집-적재-시각화로 연결할 수 있기 때문입니다.
Software Infra 운영이 바뀌는 지점: 왜 ‘물’이 중요한가?
기존 인프라 관측(Observability)은 대체로 다음에 집중했습니다.
- 성능: CPU, 메모리, 네트워크, 지연시간
- 안정성: 오류율, 가용성
- 비용: 사용량 기반 비용, FinOps 지표
여기에 이제 환경 메트릭의 두 번째 축이 들어옵니다. 탄소(Carbon footprint)에 이어 물(Water footprint)까지 확장되는 셈이죠. 이 변화가 의미하는 바는 명확합니다.
- “잘 돌아가고, 싸게 운영된다”만으로는 최적화가 끝나지 않습니다.
- 앞으로는 “환경 영향을 얼마나 줄였는가”가 인프라 의사결정의 동등한 기준이 됩니다.
특히 물 사용량은 지역(리전) 특성과 맞물립니다. 같은 워크로드라도 리전 선택과 서비스 조합에 따라 환경 영향이 달라질 수 있고, 이는 곧 Software Infra 설계의 새로운 제약 조건이 됩니다.
Software Infra 관점의 실무 포인트: 어디에 붙여야 ‘기능’이 아니라 ‘체계’가 된다
이 기능을 제대로 쓰려면 “새 화면이 생겼다”가 아니라, 운영 루프에 어떻게 편입하느냐를 먼저 봐야 합니다.
1) 리포팅 파이프라인에 API로 편입
Sustainability API → (배치 수집) → DWH/데이터 레이크 → BI/ESG 대시보드로 이어지는 구조가 가장 자연스럽습니다. 이렇게 하면 연간 보고 시즌마다 급하게 취합하지 않고, 상시적으로 누적·비교 가능한 데이터 자산이 됩니다.
2) 계정(Account) 단위 거버넌스에 연결
멀티 계정 구조를 운영하는 조직이라면, 물 사용량 데이터는 곧바로 조직/사업부 KPI가 됩니다.
예를 들어 “사업부 A는 물 사용량이 증가 추세인데, 어떤 리전/서비스가 원인인가?” 같은 질문을 정량적으로 분해할 수 있습니다.
3) IaC(Infra as Code) 정책에 ‘환경 조건’을 추가할 여지
Terraform/CloudFormation으로 리전과 서비스를 선택할 때, 기존에는 비용/지연시간 중심이었습니다. 이제는 조직 정책으로
- 특정 리전 사용 가이드
- 특정 서비스 조합 권장/제한
같은 형태의 Sustainability-aware Architecture 규칙을 만들 수 있습니다.
Software Infra 엔지니어가 기억해야 할 한 가지: ‘실시간 메트릭’이 아니라 ‘의사결정 메트릭’이다
주의할 점도 있습니다. 공개된 형태는 연간(annual) water withdrawals 중심의 집계 데이터입니다. 즉, CPU 사용률처럼 실시간 오토스케일링 트리거로 쓰기보다는 다음에 적합합니다.
- 월/분기/연간 단위의 운영 리뷰
- 신규 아키텍처 설계 시 리전·서비스 선택 근거
- 경영/ESG 보고를 위한 감사 가능한 근거 데이터
정리하면, 이번 발표는 “환경 보고 기능 추가”가 아니라, Software Infra에 새로운 최적화 축(물 사용량)을 공식적으로 끼워 넣은 사건입니다. 이제 클라우드 운영은 비용·성능만이 아니라, 환경 지표까지 포함하는 다중 목적 최적화로 진화하고 있습니다.
Software Infra 관점에서 AWS Sustainability Water Withdrawals 기능, 기술적 의미를 파헤치다
단순한 보고 도구일까요, 아니면 인프라 관측 스택의 혁신적 진화일까요? AWS가 7월 16일 공개한 워크로드별 연간 Water Withdrawals(물 취수량) 데이터는 “환경 지표를 보여주는 화면 하나 추가” 수준이 아닙니다. 핵심은 Software Infra가 다뤄야 할 메트릭의 범위를 비용/성능에서 ‘자원 영향(물)’까지 확장했다는 데 있습니다. 즉, 운영자가 보는 대시보드의 세계관 자체가 바뀝니다.
Software Infra Observability가 바뀌는 지점: “상태”가 아니라 “영향”을 본다
기존 인프라 관측(Observability)은 대체로 다음 질문에 답하도록 설계돼 왔습니다.
- 시스템이 정상 동작하는가? (가용성, 오류율)
- 빠른가? (지연시간)
- 효율적인가? (CPU/메모리, 스토리지 I/O, 비용)
하지만 Water Withdrawals는 결이 다릅니다. 이 메트릭이 답하는 질문은 “상태(state)”가 아니라 “영향(impact)”에 가깝습니다.
- 이 워크로드를 운영하기 위해 데이터센터 레벨에서 연간 얼마나 물이 취수되었는가?
- 그 영향이 어느 리전/어느 서비스/어느 계정에서 발생하는가?
이 차이는 중요합니다. CPU 사용률은 트래픽이 줄면 내려가지만, 환경 메트릭은 아키텍처/리전/서비스 선택의 결과로 ‘누적되는’ 성격이 강합니다. 그래서 이 기능은 실시간 알람보다 정책·설계·거버넌스 의사결정에 더 직접적으로 연결됩니다.
Software Infra 설계 축의 확장: Region/Service/Account가 ‘환경 분해능’이 된다
AWS가 이 데이터를 리전(Region)·서비스(Service)·계정(Account) 단위로 제공하는 구조는 단순한 필터 옵션이 아닙니다. Software Infra에서 의미 있는 이유는 “개선 가능한 단위”로 쪼개서 보여주기 때문입니다.
- Region 축: “어디에 배치할 것인가”가 지연시간/비용뿐 아니라 물 사용 영향까지 포함한 최적화 문제가 됩니다.
- Service 축: “무엇으로 구현할 것인가”가 기능/운영 편의뿐 아니라 서비스 선택에 따른 환경 영향 비교로 확장됩니다.
- Account 축: “누가 책임지는가”가 명확해집니다. 다계정(Multi-account) 환경에서는 계정이 곧 조직/사업부의 경계이므로, 환경 KPI를 할당하고 추적할 수 있습니다.
즉, 기존에는 “리전/서비스/계정”이 비용 분석의 분류 체계에 가까웠다면, 이제는 환경 영향의 분류 체계가 됩니다. 이게 곧 거버넌스가 가능한 형태의 데이터라는 뜻입니다.
Software Infra 운영 모델의 변화: FinOps → SustainabilityOps로 이어지는 메트릭 통합
현장에서는 이미 비용(Cloud Cost)을 중심으로 한 FinOps 루프가 자리 잡았습니다.
1) 사용량 수집 → 2) 비용 분석 → 3) 태깅/쇼백 → 4) 최적화 액션
Water Withdrawals 데이터가 들어오면 이 루프는 자연스럽게 다음 형태로 확장됩니다.
- 비용 + 성능 + 환경(물)을 한 테이블에서 비교
- “가장 싼 리전”이 아니라 “비용과 환경 영향의 균형점”을 찾는 선택
- 최적화 액션이 단순 리사이징이 아니라 리전 이동, 서비스 전환, 조직 정책 변경까지 포함
결국 Software Infra 팀은 “장애를 막는 팀”을 넘어, 환경 목표 달성을 위한 운영 루프의 공동 소유자가 됩니다. 특히 API로 제공된다는 점은 결정적입니다. 콘솔에서 확인하는 데서 끝나는 것이 아니라, 사내 DWH/대시보드/정책 엔진으로 흘려보내 자동화 가능한 운영 체계를 만들 수 있기 때문입니다.
Software Infra에서 ‘SLO의 재정의’가 시작된다: 성능 SLO → 영향 SLO
SRE/플랫폼 팀이 익숙한 SLO는 보통 가용성과 성능입니다. 그런데 Water Withdrawals는 새로운 종류의 목표를 가능하게 합니다.
- “특정 워크로드는 연간 water withdrawals를 계정 단위로 관리한다”
- “신규 서비스는 특정 리전 사용을 기본 금지(또는 승인제)로 한다”
- “분기 리뷰에서 서비스별 물 사용 영향이 높은 구간을 찾아 아키텍처 개선 백로그로 만든다”
이런 목표는 단순 모니터링이 아니라 조직의 정책과 아키텍처 설계 원칙을 바꾸는 수준입니다. 그래서 이 기능은 ‘보고 도구’가 아니라, Software Infra 관점에서 관측 가능한 세계를 확장하는 새로운 메트릭 소스로 보는 게 맞습니다.
Software Infra 실제 사례로 본 환경 메트릭 활용법: ESG 보고부터 FinOps와의 시너지까지
물 사용량 데이터를 활용해 ESG 규제 대응을 자동화하고, 비용 최적화에서 환경 최적화로 확장하는 방법은 무엇일까요? 핵심은 AWS Sustainability의 워크로드별 연간 Water Withdrawals 데이터를 “보고용 자료”로만 두지 않고, Software Infra 운영 의사결정에 들어오는 1급 메트릭으로 만드는 데 있습니다. 아래는 기업들이 이 데이터를 현장에 적용할 때 가장 효과를 보는 패턴을 실제 업무 흐름 중심으로 정리한 내용입니다.
Software Infra 사례 A: ESG·규제 보고를 “자동 생성”하는 데이터 파이프라인
많은 조직이 물 사용량을 포함한 환경 지표를 연 1회 수작업으로 취합하면서, 데이터 누락·정합성 이슈·감사 대응 부담을 겪습니다. 여기서 워크로드별 Water Withdrawals 데이터는 “증빙 가능한 시스템 데이터”로서 큰 역할을 합니다.
현장에서 많이 쓰는 구현 흐름(레퍼런스 패턴)
수집(Extraction)
- 정기 배치(예: 월 1회 또는 분기 1회)로 AWS Sustainability API 호출
- 축은 보통 Account → Region → Service 순으로 내려가며, 조직의 비용/책임 단위에 맞춰 분해합니다.
표준화(Transformation)
- 계정 매핑 테이블(계정ID → 사업부/제품/서비스 오너)을 붙여 “조직 기준”으로 재분류
- 리전/서비스별 집계가 필요한 경우, 보고서 템플릿에 맞게 연간 수치를 재정렬
- ESG 문서에서 요구하는 항목(예: 사업부별 총량, 상위 리전 TOP N, 전년 대비 증감)을 자동 계산
적재(Load)
- DWH/데이터 레이크에 적재해 변경 이력(스냅샷)을 남깁니다.
- 이렇게 하면 “올해 수치”뿐 아니라 “올해 산출 시점에 우리가 어떤 원천 데이터를 봤는지”가 추적됩니다.
제출(Reporting)
- BI(Tableau/Power BI)로 대시보드화하거나, ESG 보고서 생성 파이프라인에 합류
- 감사 대응 시 “근거 데이터는 어디서 왔나?” 질문에 대해 API 기반의 재현 가능성을 제공합니다.
기술적으로 중요한 포인트
- 이 데이터는 실시간 트래픽 메트릭이 아니라 연간 집계성 환경 데이터에 가깝습니다. 따라서 Software Infra에서의 활용은 자동 스케일링 트리거가 아니라, 월/분기/연간 거버넌스 리듬에 맞춘 리포팅·정책에 최적화됩니다.
- 데이터 소비자가 인프라 팀만이 아니라 재무/ESG 조직까지 확장되므로, IAM 최소 권한과 계정 경계(멀티어카운트) 설계가 함께 정리되어야 합니다.
Software Infra 사례 B: FinOps가 SustainabilityOps로 확장되는 “이중 최적화” 의사결정
FinOps가 비용만 줄이면 끝나던 시대는 빠르게 지나가고 있습니다. 워크로드별 물 사용량 데이터가 들어오면, 비용 최적화 프레임이 비용 + 환경 영향의 다목적 최적화로 바뀝니다.
대표적인 적용 방식
리전 선택의 다중 기준화
기존: 지연시간, 비용, 가용성 중심
확장: 여기에 Water Withdrawals(연간 물 취수량)을 추가해 “어디에 배치할지”를 재평가- 예: 동일 서비스라도 리전별로 물 사용량 프로파일이 다르면, 신규 워크로드는 더 유리한 리전을 우선 검토하도록 가이드
서비스 아키텍처 선택의 근거 강화
완전관리형 서비스 vs 직접 운영(EC2 기반) 같은 선택은 비용·인력·장애 책임뿐 아니라, 결과적으로 리소스 소비 패턴이 달라져 환경 지표에도 차이가 납니다.
이때 물 사용량 데이터는 “환경 관점의 트레이드오프”를 숫자로 논의하게 만들며, 회의가 감(感)이 아니라 측정 기반으로 바뀝니다.내부 쇼백/차지백에 환경 지표를 추가
조직 내 제품팀이 클라우드 자원을 쓰면 비용이 청구되듯, 환경 영향도 같은 방식으로 투명화할 수 있습니다.- 예: 계정별(또는 제품별) 연간 물 사용량을 비용 리포트 옆에 붙여 비용이 낮아도 환경 영향이 큰 워크로드를 드러냄
