Energy-Efficient Software Architecture for Developers • Henrik Bærbak Christensen • GOTO 2023

GOTO Conferences·GOTO Conference 2023·2023년

AI 요약

Henrik Bærbak Christensen(GOTO 2023)의 강연으로, 지속가능성을 거창한 담론이 아니라 "같은 일을 가장 적은 에너지로 끝내는 아키텍처를 고르는 것"으로 좁혀 개발자가 키보드 앞에서 바로 쓸 수 있는 측정 가능한 전술로 풀어낸다. 실제 소형 PC에서 측정한 수치로 절약 효과를 증명한다.

핵심 포인트

에너지는 주로 CPU(+냉각)가 쓰며, 소프트웨어는 하드웨어가 빨라지는 속도보다 빨리 느려진다 — 먼저 측정하고 추세를 읽어야 한다
스케일링을 안 쓸 거면 모놀리스가 마이크로서비스보다 1.8배 효율적, 배칭은 서버 에너지 27%·풀링은 30%·MongoDB→Redis는 31% 절약
에너지 비비례성 때문에 CPU 활용률을 (큐 이론상 ~70%까지) 끌어올리는 게 핵심이며, 효율적 언어(C·Go·Java vs Python 162%)·로깅 절제·기능 절제가 큰 차이를 만든다

왜 읽나비용·탄소를 함께 줄이고 싶은 백엔드/아키텍트에게 추측이 아닌 측정 기반의 구체적 절약 전술을 제공한다.

챕터별 상세

010:00 – 11:30

에너지 효율이란 — 더 적은 일을 택하고, 물리를 이해하기

오르후스 대학의 연구자이자 교육자 Henrik Bærbak Christensen 이 소프트웨어 아키텍처 관점의 에너지 효율을 다룬다. 현장 개발자가 바로 적용할 기법에 초점을 두며, 첫 교훈으로 "낮은 충실도를 받아들이거나(accept lower fidelity) 에너지를 많이 쓰는 기능 자체를 만들지·쓰지 말라"를 든다. 강연자에게 질문하는 문제를 풀 때, 앱을 만들어 다운로드·입력·무선 전송·서버 저장·조회까지 거치는 "솔루션 A"보다 그냥 손을 들어 "헨릭, 질문 있어요"라고 말하는 "솔루션 B"가 압도적으로 에너지 효율적이라는 비유다. 에너지 효율이란 결국 "같은 일을 가장 적은 에너지로 끝내는 아키텍처를 고르는 것", 즉 1와트당 컴퓨터가 최대한 많이 일하게 하는 것이다.

원래 물리학자인 그는 줄(Joule)과 와트의 관계, 그리고 강남스타일이 첫해 17억 회 재생되며 덴마크 가정 약 7만 가구의 연간 전력을 썼다는 사례로 동기를 부여한다. 핵심 긴장은 하드웨어와 소프트웨어의 관계다. 하드웨어는 2년 반마다 같은 에너지로 두 배의 연산을 하는 "착한 쪽"인 반면, 소프트웨어는 하드웨어가 빨라지는 속도보다 더 빨리 느려지는 "나쁜 쪽"이다(부팅 1분 걸리는 새 노트북 vs 즉시 켜지는 1991년 Amiga, 6년 새 2.5배 무거워진 "경량" Ubuntu). 에너지를 가장 많이 쓰는 것은 메모리·디스크가 아니라 CPU(와 그것을 식히는 냉각)이며, 그는 11~43와트를 쓰는 2012년형 "런치박스" 소형 PC를 실험실 삼아 측정한다 — 절대값이 아니라 추세 가 클라우드로도 스케일한다는 점을 강조한다.

에너지 효율의 첫 단계는 측정과 실험 이다. 어떤 아키텍처가 더 절약하는지 비교하려면 실제로 재 봐야 하며, 측정만큼이나 "무엇이 통하고 안 통하는지에 대한 감"을 얻는 것이 중요하다고 강조한다(그 자신도 처음엔 1~5% 절약을 기대했다가 30%까지 줄이는 경험을 했다). 측정 도구로는 150크로네짜리 전력 측정 플러그, 그리고 2010년 이후 CPU 칩에 내장돼 Linux에서 `powerstat` 으로 직접 읽는 방법(팬은 못 재지만 상관관계가 높다)을 소개하며, 가상 머신이 아닌 실제 머신에서 통계적으로 오차를 통제해 재라고 권한다.

둘째는 우선순위 다. 리팩터링에는 정신적·시간적 비용이 들므로, 초당 1,000 트랜잭션을 처리하는 코드에 집중하고 화요일 밤에만 도는 코드는 두지 말라는 것이다. 셋째는 동료와의 인식 공유 다. 40와트 전구 대신 2와트 전구를 쓰라고 가족에게 알리듯, 아키텍트·테스터·동료에게 무엇이 통하는지 알려 인식을 높이면 작은 투자로 큰 효과를 얻는다고 말한다.

본격적인 전술들은 각각 "집에서도 하는 일"과 짝지어진다. 첫째 유휴 시 종료(shut down when idle) — 화장실 불을 끄듯 안 쓰는 장비는 끈다. 둘째, 마이크로서비스의 함정 이다. 독립 스케일링이라는 약속(쇼핑몰의 판매 컴포넌트만 크리스마스에 키웠다 줄이기)은 분명 가치 있지만, 스케일링을 활용하지 않는다면 마이크로서비스는 훨씬 더 많은 에너지를 쓴다. 그의 'Pizza Land' 실험에서 모놀리스는 요청당 20.3밀리줄, 마이크로서비스는 36.6밀리줄로 약 1.8배였다 — "독립 스케일링이 꼭 필요해질 때까지 모놀리스를 유지하라"는 결론이다.

셋째, 페이로드 최소화 — 안 쓸 양말을 여행 가방에 넣지 않듯, Docker 이미지·네트워크 전송에서 안 쓸 것을 빼고 최소 베이스 이미지를 고른다. 넷째, 배칭(batch method) — 장을 한 번에 보듯 필요한 정보를 한 번에 크게 받는다. 객체지향의 잘게 쪼개진 API(`getName`·`getMana`·`getAttack`…)를 원격 호출하면 "get get get"의 수다가 되는데, 카드 속성을 한 번에 묶어 전송하고 5초간 캐시하니 서버 측 에너지 27% 절약 을 보였다. 다섯째, 캐싱 — 부엌 옆 창고처럼 데이터를 가까이 두는 것으로, CDN도 같은 원리다.

여섯째, 효율적 기술 사용 이다. 2017년 포르투갈 연구를 자신의 3-엔드포인트 REST 서비스로 재현하니 C 대비 Go는 약 3.5% 더, Scala는 27% 더, Python은 같은 일에 162% 더 많은 에너지를 썼다(다만 자바 가상머신처럼 인터프리터도 점차 튜닝될 것이라 본다). DB도 단순 키-값 용도라면 MongoDB 대신 Redis로 바꿔 31% 절약 했다. 일곱째이자 가장 중요한 것은 에너지의 비비례성 이다. 아무 일도 안 하는 컴퓨터도 상당한 전력을 쓰므로 "놀리지 말고 일하게" 해야 한다. 100% CPU에서 90와트로 2,000 TPS를 처리하던 서버를 두 대로 나누면 각 75와트, 합쳐 150와트로 같은 일을 해 오히려 손해다. 그래서 온프레미스 평균 부하 15~20%(상사에게 혼날까 봐 과프로비저닝) 를 클라우드 수준(60~70%)으로 끌어올려야 하되, 대화형 서버는 큐 이론 때문에 100%가 아닌 약 70%를 노린다. 클라우드 가상화·스레드/커넥션 풀링(naive 연결 생성·해제 대비 약 30% 절약)도 같은 맥락이다.

나머지 전술로는 낮은 충실도(이미지·영상 다운스케일), 과도한 로깅 절제(Docker 파일 로그 기준 11.6% 절약 — 다만 진단을 위해 전부 끄지는 말 것), 그리고 기능 절제(feature creep) 를 든다. 10년 된 하드웨어의 Pizza Land 코어가 시간당 5만 건을 처리하듯, 정작 필요한 핵심만 코딩하면 구형 장비로도 충분하다. "완벽은 더할 게 없을 때가 아니라 뺄 게 없을 때"라는 말과 함께, 측정으로 시작해 활용률을 높이고 효율적 언어를 배우며 기능을 덜어 내자고 마무리한다.