carbon-measurement

1 개의 포스트

gitlab

그린 DevOps: 탄소 측정이 CI/CD 파이프라인에 포함되어야 하는 이유 (새 탭에서 열림)

CI/CD 파이프라인은 매일 상당한 컴퓨팅 에너지와 탄소를 소비하지만, 일반적인 파이프라인 지표에는 그 영향이 드러나지 않는다. 글은 GitLab에 Eco CI와 Carmen을 연동해 파이프라인·인프라·애플리케이션 수준의 탄소 배출량을 측정해야 한다고 주장한다. 측정만으로도 불필요한 테스트 실행, 의존성 재설치, 유휴 서비스 같은 낭비를 찾아 비용과 탄소 배출을 함께 줄일 수 있다. ## CI/CD 파이프라인에 탄소 측정이 필요한 이유 - 현대적인 개발 파이프라인은 하루에도 수백 개의 작업을 실행한다. - AI 기반 테스트, 코드 리뷰, 자동화 작업이 늘면서 과거보다 실행 작업과 에너지 소비가 증가했다. - 파이프라인 로그나 아키텍처 다이어그램에는 컴퓨팅에 따른 탄소 배출량이 표시되지 않는 경우가 많다. - 배출량을 줄이려면 먼저 파이프라인 실행별, 서비스별, 팟(pod)별 배출량을 측정해야 한다. - Green DevOps는 탄소 데이터를 엔지니어링 의사결정에 활용하는 실천 방식이다. ## 파이프라인 수준의 측정: Eco CI - Eco CI는 CI/CD 작업별 에너지 소비량과 탄소 배출량을 측정한다. - 별도 서버나 데이터베이스 없이 가벼운 Bash 스크립트로 실행할 수 있다. - 각 작업의 배출량을 확인하고, 자원 사용량이 큰 작업과 시간에 따른 추세를 파악할 수 있다. - README에 탄소 배출량을 보여주는 배지를 추가할 수도 있다. - 기존 GitLab 파이프라인에 몇 줄을 추가하는 방식이므로 도입 난도가 낮다. - 파이프라인 자체가 이미 관측 대상이므로, 초기 Green DevOps 도구로 적합하다. ## 인프라와 애플리케이션 수준의 측정: Carmen - Carmen(Carbon Measurement Engine)은 Green Software Foundation의 Impact Framework를 기반으로 한다. - Kubernetes에서 실행되는 가상 머신, 팟, 개별 애플리케이션 워크로드까지 측정한다. - 컴포넌트별 CSV 보고서를 생성하며 다음 탄소를 구분한다. - 운영 탄소: 전력 사용으로 발생하는 배출량 - 내재 탄소: 하드웨어 제조와 폐기 과정에서 발생하는 배출량 - 주요 출력 필드는 다음과 같다. - `EnergykWh`: 에너지 소비량 - `TotalCarbonGramsCO2eq`: CO₂ 환산 총 배출량 - 생성된 데이터는 Grafana, FinOps 대시보드, 사내 분석 도구에 직접 연결할 수 있다. - “어떤 서비스가 가장 많은 CO₂를 배출하는가?”, “API 게이트웨이와 데이터 처리 계층 중 어디가 더 큰가?” 같은 질문에 답할 수 있다. ## GitLab 파이프라인에 연동하는 방법 - Eco CI와 Carmen 모두 `.gitlab-ci.yml`에 직접 추가할 수 있다. - Carmen 예시는 다음 작업을 수행한다. - `python:3.12` 이미지 사용 - Node.js, npm, Git, `lsb-release` 설치 - Carmen 저장소를 Git으로 복제 - Impact Framework 관련 npm 패키지 설치 - Carmen을 Python 패키지로 설치 - `carbon-daemon` 실행 - 생성된 결과를 GitLab artifact로 보관 - 결과 artifact는 예를 들어 1주일 동안 보관한 뒤 다운로드해 첫 탄소 보고서로 활용할 수 있다. - Carmen 작업을 별도의 비차단(non-blocking) 작업으로 구성하면 기존 배포 경로를 지연시키지 않는다. ## 측정으로 발견할 수 있는 낭비 - 한 팀은 Eco CI 도입 후 통합 테스트가 전체 파이프라인 배출량에서 예상보다 큰 비중을 차지한다는 사실을 발견했다. - 원인은 테스트 코드가 아니라 매 실행마다 모든 의존성을 처음부터 다시 설치하는 설정이었다. - 의존성 캐시를 추가하면 다음 효과를 동시에 얻을 수 있다. - 테스트 실행 시간 단축 - CI 탄소 배출량 감소 - 개발자 대기 시간 감소 - CI 비용 절감 - Carmen을 스테이징 클러스터에 적용한 결과, 폐기된 기능의 데이터 처리 서비스가 유휴 상태로 계속 실행되고 있었다. - 해당 서비스를 제거함으로써 불필요한 운영 탄소와 내재 탄소 소비를 줄일 수 있었다. - 두 사례 모두 대규모 지속가능성 프로젝트가 아니라, 데이터 가시성에서 출발한 개선이었다. ## 낮은 도입 비용과 실질적인 효과 - Eco CI는 몇 줄의 설정과 Bash 스크립트만으로 추가할 수 있다. - 별도 인프라를 구축하지 않으며 파이프라인에 의미 있는 지연을 추가하지 않는다. - Carmen 역시 독립적인 작업으로 실행할 수 있어 기존 핵심 경로에 영향을 주지 않는다. - 측정 데이터는 향후 탄소 보고와 규제 대응을 위한 조직의 기준선(baseline)이 된다. - 탄소 배출이 적은 코드는 대체로 더 빠르고 저렴하다. - 의존성 캐시, 러너 규모 조정(right-sizing), 불필요한 서비스 제거는 환경 개선이면서 동시에 FinOps 최적화이기도 하다. ## 규제와 기업 요구사항 변화 - 탄소 인식형 엔지니어링은 선택적 활동에서 전문적인 개발 관행으로 자리 잡고 있다. - EU의 기업 지속가능성 보고 지침(CSRD)은 대기업에 클라우드 사용량을 포함한 가치사슬 전반의 배출량 공개를 요구한다. - 기업 고객도 공급업체 선정 과정에서 지속가능성 정책과 배출량 관리 여부를 확인하는 경우가 늘고 있다. - 법적 의무가 생긴 뒤 시작하기보다, 지금부터 작은 범위에서 측정 기준과 내부 운영 습관을 마련하는 편이 유리하다. Eco CI를 단일 GitLab 파이프라인에 먼저 적용해 작업별 탄소 배출량을 확인하고, 이후 Carmen으로 Kubernetes와 서비스 수준까지 범위를 확장하는 접근이 현실적이다. 특히 의존성 캐시, 유휴 리소스 제거, 러너 크기 조정처럼 비용과 성능도 함께 개선하는 항목부터 실행하는 것이 효과적이다.