현대 세계에서 소프트웨어는 우리 주머니 속의 휴대폰부터 인터넷을 구동하는 거대한 데이터 센터에 이르기까지 모든 곳에서 실행됩니다. 우리는 흔히 에너지 소비를 하드웨어의 문제, 즉 서버나 배터리가 얼마나 많은 전력을 사용하는지의 문제로 생각하지만, 소프트웨어 그 자체도 매우 중요한 역할을 합니다. 목적지까지 가는 두 가지 서로 다른 경로가 서로 다른 시간과 연료를 소모할 수 있는 것처럼, 똑같은 작업을 수행하는 두 개의 서로 다른 코드는 매우 다른 양의 전력을 끌어다 쓸 수 있습니다. 이 소프트웨어가 하루에 수백만 번 실행될 때, 이러한 작은 차이는 상당한 비용과 탄소 배출량으로 쌓이게 됩니다. 개발자들의 오랜 과제는 이 에너지 비용이 눈에 보이지 않는다는 점이었습니다. 프로그래머가 코드를 작성할 때, 코드가 제대로 작동하는지 또는 얼마나 빨리 실행되는지에 대해서는 즉각적인 피드백을 받지만, 자신의 변경 사항이 소프트웨어를 더 에너지 효율적으로 만들었는지 혹은 덜 효율적으로 만들었는지 알려주는 신호는 받지 못합니다. 이러한 격차로 인해 비효율적인 코드가 생산 단계로 넘어가 눈에 띄지 않게 에너지를 계속 낭비하게 됩니다.

핀란드 라펜란타-라피엔란타 공과대학교(Lappeenranta-Lahti University of Technology)의 연구팀은 개발자들이 매일 사용하는 도구 내에서 이 보이지 않는 에너지를 가시화하기 위해 노력했습니다. 그들은 세 가지 뚜렷한 단계, 즉 코드의 변경, 그 변경의 에너지를 자동으로 측정하는 것, 그리고 에너지 사용량의 증가를 버그를 체크하는 테스트처럼 실패로 표시하는 것을 연결하는 피드백 루프를 설계된 시스템을 테스트했습니다. 이것이 실제 세상에서 작동하는지 확인하기 위해, 그들은 이 시스템을 두 개의 오픈 소스 소프트웨어 애플리케이션과 표준 자동화 테스트 파이프라인에 적용했습니다. 그들은 단순히 새로운 아이디어를 제안하는 데 그치지 않고, 이를 직접 구축하고 실행하며 결과를 측정했습니다. 그들의 연구는 개발자가 변경 사항을 제출하는 순간 에너지 낭비를 포착하는 것이 가능하다는 것을 입증하며, 코드의 실제 문제와 공유 인프라에서 실행되는 컴퓨터에서 발생하는 일반적이고 해롭지 않은 변동을 구분해 냅니다.

연구진은 특정 코드 변경이 에너지 사용량의 차이를 보여줄 수 있는지 실제로 측정 가능한지를 테스트하는 것부터 시작했습니다. 그들은 두 개의 잘 알려진 소프트웨어 애플리케이션을 선택하고 각각에 표적화된 변경 사항을 도입했습니다. 첫 번째 애플리케이션에서는 소프트웨어가 데이터베이스에서 동일한 정보를 두 번 조회하는 중복 단계를 제거했습니다. 두 번째에서는 소프트웨어가 기사를 검색하는 방식을 재구성하여, 반복되는 단계들을 하나의 더 깔기한 프로세스로 통합했습니다. 그런 다음 공정한 비교를 보장하기 위해 전용 머신에서 각 버전의 테스트 스위트를 20번씩(원본 코드 10회, 새 코드 10회) 실행했습니다. 결과는 명확했습니다. 첫 번째 애플리케이션은 총 에너지 사용량이 약 8% 감소한 것으로 나타났고, 두 번째는 21% 이상의 감소를 보였습니다. 결정적으로, 연구진은 이러한 절감이 단일 순간에 전력을 적게 사용했기 때문이 아니라, 소프트웨어가 작업을 더 빠르게 완료했기 때문에 발생했다는 것을 발견했습니다. 이 구분은 매우 중요합니다. 코드가 단순히 일을 더 빠르게 처리함으로써 더 효율적이 되었고, 이것이 자연스럽게 총 에너지 소비를 낮춘 것입니다.

코드 변경을 측정할 수 있음을 증명한 후, 팀은 다음 과제인 이 측정을 실시간 자동화 워크플로우에 통합하는 단계로 넘어갔습니다. 그들은 개발자가 새로운 코드를 제출할 때마다 실행되는 프로세스인 지속적 통합(continuous integration) 파이프라인을 구축했습니다. 이 시스템은 두 가지 수준에서 에너지를 측정했습니다. 첫째, 전체 테스트 스위트 전체를 살펴보았습니다. 둘째, 정확히 어디에서 에너지가 사용되는지 확인하기 위해 단일 검색이나 단일 데이터 검색과 같은 개별 요청의 에너지를 측정했습니다. 그들은 이러한 테스트에 사용되는 공유 컴퓨터에서 에너지 수치가 놀라울 정도로 안정적이라는 것을 발견했습니다. 실행 간의 자연스러운 변동은 매우 작았기에, 시스템은 정상적인 노이즈와 실제 문제를 확실히 구분할 수 있었습니다. 이러한 안정성 덕분에 시스템은 모든 새로운 코드가 비교될 수 있는 기준점, 즉 정상적인 성능의 표준을 설정할 수 있었습니다.

마지막 테스트는 시스템이 실수를 잡아낼 수 있는지 확인하는 것이었습니다. 연구진은 파이프라인이 에너지 낭비 오류를 포착하는지 보기 위해 코드에 두 가지 유형의 에너지 낭비 오류를 의도적으로 주입했습니다. 한 가지 시나리오에서는 코드를 변경하여 데이터를 한꺼번에 가져오는 대신 데이터베이스에 하나씩 요청하도록 만들었는데, 이는 엄청난 비효ال성을 초래하는 흔한 오류입니다. 다른 시나리오에서는 소프트웨어의 특정 부분에 무거운 계산 작업을 추가했습니다. 시스템은 기대했던 대로 작동했습니다. 오류가 시스템 전체에 영향을 미쳤을 때는 파이프라인이 전체 빌드를 실패로 표시했습니다. 오류가 단 몇 개의 특정 기능에 국한되었을 때는 시스템이 해당 특정 기능들을 문제로 정확히 식별하면서 나머지 소프트웨어는 통과시켰습니다. 이러한 정확한 위치를 짚어내는 능력은 개발자들에게 무엇을 고쳐야 할지 알려주기 때문에 이 접근 방식을 실용적으로 만듭니다.

또한 이 연구는 이러한 시스템을 사용하는 데 따르는 실질적인 현실을 강조했습니다. 테스트를 실행하는 컴퓨터는 시간이 지남에 따라 변할 수 있는 공유 자원이기 때문에, 시스템은 기준을 조정하는 방법이 필요했습니다. 연구진은 기초가 되는 하드웨어가 변경되면 에너지 수치가 급격히 변하여 잠재적으로 잘못된 경보를 일으킬 수 있다는 것을 발견했습니다. 이를 해결하기 위해, 그들의 시스템은 코드가 성공적으로 병합될 때마다 베이스라인을 자동으로 재조정하는 메커니즘을 포함하여, 기준이 항상 현재 환경을 반영하도록 보장합니다. 이는 컴퓨터 환경이 바뀌었다는 이유만으로 좋은 코드를 차단하는 것을 방지합니다. 연구진은 시스템이 통제된 테스트에서는 잘 작동했지만, 8%나 21% 감소와 같은 구체적인 수치는 특정 애플리케이션과 수행된 코드 변경의 유형에 따라 달라진다고 언급했습니다. 그들은 모든 코드 변경이 이만큼의 에너지를 절약할 것이라고 주장한 것이 아니라, 이러한 변화를 측정하고 표시하는 방법 자체가 실행 가능하다는 것을 말하고자 했습니다.

궁극적으로, 이 연구는 에너지 효율성이 버그나 성능 속도를 체크하는 것과 마찬가지로 일상적인 품질 점검처럼 다뤄질 수 있다는 개념 증명을 제공합니다. 에너지 소비를 개발 워크플로우 내에서 가시적이고 실행 가능하게 만듦으로써, 이 시스템은 개발자가 코드를 출시하기 전에 정보에 입각한 결정을 내릴 수 있도록 돕습니다. 이 연구는 코드를 측정하고, 데이터를 파이프라인에 통합하고, 회귀를 탐지하는 세 가지 기술적 구성 요소가 하나의 루프로 함께 작동할 수 있음을 확인해 줍니다. 연구진은 개발자들이 이러한 신호에 어떻게 반응하는지에 대한 추가적인 평가가 광범위한 채택을 위해 필요하다는 점을 인정하면서도, 핵심적인 결론은 확고합니다. 즉, 실시간으로 에너지 낭비를 잡아내어 보이지 않는 문제를 관리 가능한 소프트웨어 생성 과정의 일부로 만드는 시스템을 구축하는 것은 가능하다는 것입니다.