컴퓨터공학 300 주제 시리즈의 299번째 글이다. 전체 지도는 여기.

한 줄 요약

소프트웨어의 환경 영향은 실행에 쓰는 전기(운영 배출)와 하드웨어를 만드는 데 든 배출(내재 배출)로 나뉜다. 개발자는 일을 덜 하게 만들고(효율), 놀고 있는 자원을 줄이고(활용도), 깨끗한 전기를 쓸 수 있을 때 일하게 해서(탄소 인지) 이를 줄일 수 있다.

왜 필요한가

국제에너지기구(IEA)의 「Energy and AI」 보고서는 2024년 전 세계 데이터센터 전력 소비를 약 415 TWh, 세계 전력 소비의 약 1.5% 로 추정했다. 그리고 2030년에는 약 945 TWh 로 두 배 이상이 될 것으로 전망했고, AI 를 가장 중요한 증가 요인으로 꼽았다.

이 전기는 코드가 쓴다. 비효율적인 쿼리, 아무도 보지 않는 로그, 24시간 켜져 있는 개발 환경, 필요 이상으로 큰 모델이 모두 전기 사용량이 된다. 그리고 대부분의 경우 에너지 절감은 비용 절감과 같은 방향이다. 클라우드 청구서와 탄소 배출은 함께 움직인다.

핵심 개념

배출의 두 갈래

구분 뜻 줄이는 법
운영 배출(operational) 실행 중 쓰는 전기 x 그 전기의 탄소 집약도 에너지 효율, 깨끗한 전기 시간·지역 선택
내재 배출(embodied) 서버·네트워크 장비·단말을 만들고 폐기하는 데 든 배출 장비를 오래 쓰기, 활용도 높이기, 적은 장비로 처리

탄소 집약도(carbon intensity)는 전기 1 kWh 를 만들 때 나오는 온실가스(gCO2e/kWh)다. 같은 1 kWh 라도 지역의 발전 구성과 시간대에 따라 다르다. 태양광이 많은 지역은 낮에 낮고, 화석 연료 비중이 높은 시간대에는 높다.

SCI: 소프트웨어 탄소 집약도

Green Software Foundation 의 SCI(Software Carbon Intensity) 명세는 소프트웨어의 탄소 배출을 “기능 단위당 비율”로 표현한다.

SCI = (O + M) per R,   O = E x I

  E: 소프트웨어가 쓴 에너지 (kWh)
  I: 그 지역·시간 전기의 탄소 집약도 (gCO2e/kWh)
  M: 하드웨어 내재 배출 중 이 소프트웨어에 할당된 몫
  R: 기능 단위 (요청 1건, 사용자 1명, 학습 1회 등)

총량이 아니라 비율이라는 점이 핵심이다. 사용자가 늘어 총배출이 늘어도 사용자당 배출이 줄면 개선이다. 반대로 총량을 줄이려고 서비스를 덜 쓰게 만드는 것은 목표가 아니다.

데이터센터 효율: PUE

PUE(Power Usage Effectiveness)는 The Green Grid 가 제안한 데이터센터 지표다.

PUE = 데이터센터 전체 에너지 / IT 장비 에너지        (이상값 1.0)

PUE 1.5 라면 서버가 1 kWh 를 쓸 때 냉각·전력 변환 등에 0.5 kWh 가 더 든다. PUE 는 건물의 효율이고, 소프트웨어가 일을 얼마나 효율적으로 하는지는 말해 주지 않는다. 텅 빈 서버만 가득해도 PUE 는 좋을 수 있다.

개발자가 할 수 있는 것

1. 일을 덜 한다(에너지 효율)

  • 알고리즘과 쿼리를 개선한다. O(n²) 를 O(n log n) 으로 바꾸는 것은 곧 에너지 절감이다.
  • 캐시로 같은 계산을 반복하지 않는다.
  • 응답 크기를 줄인다. 압축, 필요한 필드만 반환, 이미지 최적화.
  • 로그와 지표를 필요한 만큼만 남기고 보존 기간을 정한다.

2. 놀지 않게 한다(활용도)

서버는 놀고 있어도 상당한 전력을 쓴다. 그래서 적은 수의 서버를 높은 활용도로 쓰는 편이 많은 서버를 낮은 활용도로 쓰는 것보다 효율적이다. 쿠버네티스의 수평 자동 확장(HPA)과 노드 자동 확장, 적절한 리소스 요청값 설정이 여기에 해당한다. 요청값을 과하게 잡으면 노드가 실제로는 놀면서도 “가득 찼다”고 판단해 노드를 더 띄운다.

3. 깨끗할 때 일한다(탄소 인지)

미룰 수 있는 작업(배치, 학습, 백업, 리포트 생성)은 탄소 집약도가 낮은 시간이나 지역으로 옮긴다. 실시간 응답이 필요한 작업은 옮길 수 없지만, 생각보다 많은 작업이 몇 시간 늦어져도 괜찮다.

4. 하드웨어를 오래 쓴다(내재 배출)

소프트웨어가 무거워져 멀쩡한 기기를 버리게 만드는 것도 배출이다. 오래된 단말과 느린 네트워크에서도 쓸 만한 웹 페이지는 접근성과 지속 가능성을 동시에 높인다.

AI 와 에너지

대형 모델의 학습과 추론은 에너지 사용이 크다. Patterson 외(2021)는 학습의 탄소 배출이 모델 구조, 데이터센터 효율, 가속기 종류, 그리고 전력망의 탄소 집약도에 따라 크게 달라진다고 분석했다. 같은 모델이라도 어디서, 무엇으로 돌리느냐가 중요하다. 실무에서는 “더 큰 모델” 전에 “작은 모델로 충분한가”, “결과를 캐시할 수 있나”, “배치로 묶을 수 있나”를 먼저 묻는다.

직접 해 보기

SCI 식으로 서비스의 요청당 배출을 계산하고, 개선 조치의 효과와 탄소 인지 스케줄링을 비교한다. 모든 숫자는 설명을 위한 가정값이다. 실제로는 전력 측정값과 전력망의 공식 탄소 집약도 데이터를 쓴다.

# SCI = ((E * I) + M) per R
def sci(energy_kwh, intensity_g_per_kwh, embodied_g, functional_units):
    operational = energy_kwh * intensity_g_per_kwh      # O = E * I
    return (operational + embodied_g) / functional_units

E = 3 * 60 * 24 / 1000          # 서버 3대, 평균 60W, 24시간 -> kWh
I = 450                          # gCO2e/kWh (가정)
M = 3 * 1200                     # 서버 3대의 하루치 내재 배출 몫, g (가정)
R = 200_000                      # 하루 API 요청 수
print(f"에너지 {E:.2f} kWh, 요청당 SCI = {sci(E, I, M, R) * 1000:.2f} mgCO2e")

E2 = 2 * 60 * 24 / 1000          # 자동 축소로 평균 2대 분량만 가동
print(f"자동 축소 후      요청당 SCI = {sci(E2, I, M, R) * 1000:.2f} mgCO2e")
print(f"캐시 추가 후      요청당 SCI = {sci(E2 * 0.7, I, M, R) * 1000:.2f} mgCO2e")

# 탄소 인지 스케줄링: 미룰 수 있는 배치 작업(4 kWh)을 언제 돌릴까
hourly_intensity = {0: 420, 3: 380, 6: 400, 9: 300, 12: 250, 15: 280, 18: 480, 21: 460}
job_kwh = 4
best = min(hourly_intensity, key=hourly_intensity.get)
worst = max(hourly_intensity, key=hourly_intensity.get)
print(f"배치 작업: {worst}시 실행 {job_kwh * hourly_intensity[worst] / 1000:.2f} kg, "
      f"{best}시 실행 {job_kwh * hourly_intensity[best] / 1000:.2f} kg")

실행 결과다.

에너지 4.32 kWh, 요청당 SCI = 27.72 mgCO2e
자동 축소 후      요청당 SCI = 24.48 mgCO2e
캐시 추가 후      요청당 SCI = 22.54 mgCO2e
배치 작업: 18시 실행 1.92 kg, 12시 실행 1.00 kg

두 가지가 보인다. 첫째, 자동 축소와 캐시로 운영 배출을 줄여도 내재 배출(M)은 그대로 남는다. 이 예에서는 M 이 전체의 절반을 넘는다. 서버 대수 자체를 줄이거나 장비 수명을 늘려야 M 이 준다. 둘째, 같은 작업도 실행 시각만 바꿔 배출을 절반 가까이 줄였다. 코드 한 줄 바꾸지 않고 스케줄만 바꾼 결과다.

현업에서는

  • 비용 대시보드와 에너지·탄소 대시보드는 같은 데이터에서 나온다. 클라우드 사업자들은 계정별 탄소 배출 추정 도구를 제공한다. 비용 최적화 회의에 탄소 지표를 함께 올리면 설득이 쉽다.
  • 쿠버네티스에서는 리소스 요청값을 실제 사용량에 맞추고, 사용하지 않는 네임스페이스와 개발 환경을 업무 시간 외에 축소한다. 홈랩 k3s 처럼 작은 클러스터도 노드마다 상시 전력이 들기 때문에, 놀고 있는 노드를 줄이거나 저전력 장비로 바꾸면 전기 요금이 바로 줄어든다. 노트북을 서버로 재활용하는 것은 내재 배출 측면에서도 나쁘지 않은 선택이다.
  • CI 파이프라인도 에너지를 쓴다. 변경된 부분만 테스트하고, 캐시를 활용하고, 필요 없는 야간 전체 빌드를 줄인다.
  • 측정 없이 주장하지 않는다. “친환경 아키텍처” 같은 말보다 “요청당 에너지 X 에서 Y 로” 같은 측정값을 쓴다. 리눅스의 RAPL(powercap) 인터페이스나 전력 측정 장비로 실제 값을 잴 수 있다.

확인 문제

  1. 운영 배출과 내재 배출의 차이를 설명하고, 각각을 줄이는 방법을 하나씩 들어라.
  2. SCI 가 총량이 아니라 기능 단위당 비율인 이유는?
  3. PUE 가 1.1 로 매우 좋은 데이터센터에서도 소프트웨어 낭비가 클 수 있는 이유는?
  4. 쿠버네티스에서 리소스 요청값을 과하게 잡으면 왜 에너지 낭비가 되는가?
  5. 탄소 인지 스케줄링을 적용하기 좋은 작업과 어려운 작업을 하나씩 들어라.

풀이

  1. 운영 배출은 실행 중 쓰는 전기에서, 내재 배출은 하드웨어의 제조·폐기에서 나온다. 운영은 효율 개선이나 깨끗한 시간대 실행으로, 내재는 장비 수 감축·수명 연장으로 줄인다.
  2. 서비스가 성장하면 총량은 늘 수 있으므로, 같은 일 한 단위를 얼마나 적은 배출로 하는지가 소프트웨어 효율을 공정하게 보여 준다.
  3. PUE 는 건물 설비의 효율만 측정한다. 서버가 놀거나 비효율적 코드가 돌아도 PUE 에는 드러나지 않는다.
  4. 스케줄러가 요청값 기준으로 노드가 찼다고 판단해 실제 사용률이 낮은데도 노드를 더 띄우거나 줄이지 못한다.
  5. 좋은 예: 야간 배치, 모델 재학습, 백업. 어려운 예: 사용자 요청에 즉시 응답해야 하는 API.

더 읽을거리 (References)