회사에서 매년 환경에 대해 이야기 나누는 ‘액티브그린 톡’이라는 캠페인를 진행합니다. 올해는 북클럽으로 진행되어 ‘그린 소프트웨어’라는 책을 함께 읽어보았습니다.
보통 환경 보호라고 하면 종이컵 대신 텀블러 사용하기, 사용하지 않는 전자기기 끄기같이 어렸을 때부터 들어오던 실천 방안들을 생각나는데요, 이 책은 소프트웨어 개발자의 관점에서 환경 보호를 다뤄 눈길이 갔습니다. 생각해보면 최근 들어서는 AI나 영상 스트리밍같은 디지털 측면에서의 환경 보호를 다루는 글들이 이전보다 자주 보입니다.
책 뒷표지가 말하는 이 책의 주요 내용입니다:
‘데이터 센터’, ‘클라우드’, ‘시스템’과 같은 단어들을 보면 인프라 관점에서 서술을 많이 할 것 같다는 첫인상을 받았습니다. 저는 프론트엔드 개발자라 이쪽 배경지식은 약한데 그럼에도 얻어갈게 있길 바랬습니다.
더 폭넓은(or 적은) 하드웨어로도 작업이 실행되도록 설계해야합니다. 스마트폰과 같은 전자기기는 생산 단계에서 가장 많은 탄소를 배출하기에 한 기기를 오래 사용할 수 있는 환경을 만들어야합니다. 서비스 개발자로서는 최소 지원 버전이 가장 연관있는 개념같스ㅂ니다. 네이버나 카카오톡 같은 사실상 필수 앱들이 설치 혹은 잘 동작하지 않는다는건 하드웨어를 바꿀 큰 요인일 것입니다.
모든 기계는 가능한 오랫동안, 최대 한도로 사용되어야 한다.
하드웨어가 많은 작업을 수행할수록 효율성이 높아진다는 것도 인상깊었습니다. 가능한 소수의 하드웨어를 열심히 굴리는게 낫고, 유휴상태인 하드웨어는 아얘 끄는게 낫다는 것도 자주 언급되었네요.
서버리스는 친환경 소프트웨어의 성배이며…
동일한 이유로 서버리스를 좋게 말했는데 제대로 써본 적은 없지만 뉴스레터에서 서버리스를 안좋게 말한 글들이 보인게 생각났습니다.
친환경 소프트웨어는 더 적은 전력으로도 작업이 실행되도록 설계해야합니다. 전기가 다양한 방식으로 생성되긴 하지만 사용하는 입장에서는 어떻게 만들어진 전기인지 알 방법이 없다고 생각했습니다. 플러그를 꼽으면 전기가 나올 뿐이잖아요? 하지만 몇몇 국가에서는 시스템이 마련되어있다고 합니다. 이미 아이폰에서는 Use Clean Energy Charging on your iPhone처럼 친환경 전기가 사용 가능한 시간대에 충전되도록 설정이 가능하다고 합니다. 우리나라에서도 이런 시스템이 있는지 찾아봐야겠네요.
책에서 정말 꾸준히 나오는 토픽입니다.
코드를 작성할 때는 기계 생산성과 개발자 생산성 사이의 절충이 필요하다.
친환경성의 맥락이 아니더라도 개발하다보면 자주 고민하게되는 문제입니다. 모든 것을 직접 만들면 가장 최적화된 코드를 만들 수 있지만 그만큼 시간이 오래 걸립니다(회사도 좋아하지 않을거고요). 반대로 다른 사람의 도구(라이브러리, 프레임워크)를 사용하면 시간은 절약할 수 있겠지만 성능을 희생하게될 것입니다.
기타 기억에 남는 관련 글들 인용…
API는 공짜가 아니다. 코드와 아키텍처 수준에서 라이브러리 또는 서비스 호출은 에너지 사용량, 성능, 호스팅 비용에 영향을 미친다. 잘못된 아키텍처(예: 잘못된 설계로 인해 끊임없이 서로 호출하는 마이크로서비스)나 코드 디자인(자주 사용되는 API가 한 번만 호출해도 충분한데 여러 번 호출하는 경우)은 필요 이상으로 많은 작업을 생성할 수 있다.
기술 산업에서는 무어의 법칙이 예측한 것처럼 지난 30년 동안 하드웨어의 개선이 이루어져 더 나은 API와 서비스를 통해 개발자의 삶이 편해졌다. (…) 이러한 개선은 주로 추상화 계층을 사용해 이루어졌는데, 이 추상화를 통해 서드 파티가 제공하는 기능을 가져다 편리하게 사용함으로써 코드의 복잡성은 신경쓰지 않아도 되지만 더 많은 CPU 사이클이 필요하다.
합리적인 성능 테스트와 버그 수정을 넘어서는 낮은 수준의 코드 효율성이 유용한 상황은 그다시 많지 않다.
-> low-level을 ‘낮은 수준의’라고 번역한 것 같은데요, 처음에 ‘낮은 효율성’의 의미로 이해해서 자연스러운 번역인지는 모르겠습니다.
플랫폼을 의도한 대로 사용하고 있는지 확인해야한다. (플랫폼이 의도하는 바가 친환경적인지도 확인해야한다.)
효율성은 항상 이점이 있지만, 모든 경우에 비용을 상쇄할 만큼 충분한 것은 아니다.
-> 어떤 작업이 친환경적인지 아닌지 판단하는게 쉽지 않음을 의미하지만, 동시에 이게 핑계가 되어서는 안되겠다는 생각이 들었습니다.
이 책의 4장인데요, 그린 소프트웨어뿐만 아니라 인프라 관리에 대한 인사이트를 얻을 수 있었습니다. 깃옵스, 멀티테넌시, 클러스터와 같은 인프라 용어들과 클러스터링에 어떤 정보가 필요한지를 배웠습니다. 캡슐화나 빠른 인스턴스화가 왜 필요하며 이때 도커의 역할에 대해서 배웠습니다. 친환경 운영을 배우려고 읽은 책인데 인프라 지식을 얻어 독특했네요.
저는 웹 개발을 하니 여기서 인사이트를 많이 얻어갈 수 있을 것이라 기대했는데요, 인터넷을 사용하는 입장보다 라우터등의 인터넷 요소를 관리하는 입장에서 서술되어 아쉬웠습니다.
그래도 줌과 같은 화상회의 서비스가 동물/페이스 필터라든지 배경 대체의 기능을 사용해 교묘하게 전송할 비디오 데이터의 양을 줄였다는 사실은 UX 측면에서 굉장히 흥미로웠습니다. 만약 ‘네트워크 대역폭 부족으로 화질이 일시적으로 저하됩니다’ 같은 메시지를 띄웠다면 유저 경험은 아주 달라졌을 것입니다. 공항이 수하물이 나오는데 오래 걸려 컴플레인이 걸리는 문제를 수하물 찾는 곳까지의 동선을 길게 만들어 해결했다는 일화가 생각나네요.
머신러닝 학습은 긴급한 경우가 거의 없으므로 반드시 탄소 인식 학습을 해야한다는 점이다. (…) 깨끗한 에너지를 사용할 수 있을 때까지 기다려야 한다.
제가 속한 서비스는 매일 아침 유저의 상태를 정리하는 배치 작업이 돌아가는데요, 작업 시간을 친환경 전기가 가능한 시간대로 옮기면 보다 친환경적이 되지 않을까하는 생각이 들었습니다.
그렇다면 프론트엔드 서비스에서는 친환경성을 어떻게 측정할 수 있을까요? 가장 간단하면서 직관적인건 네트워크 리소스를 얼마나 사용하는지일 것입니다. 네트워크를 덜 사용하면 그만큼 운송에 필요한 에너지를 덜 사용한 것이겠지요. 유저가 접속한 페이지에 대한 리소스만 보내는 code splitting, lazy loading같은 기법이 도움이 될 것입니다.
그렇다면 SSR과 CSR중에 어떤 방법론이 친환경적일까요? SSR은 서버에서 이미 렌더링을 했기에 브라우저의 추가 요청이 필요한 CSR보다 네트워크 요청 측면에서 더 친환경적일 것입니다. 반면 단순 파일 업로드면 충분한 CSR과는 달리 SSR은 별도의 서버가 필요하기에 서버를 운영하는데 사용되는 에너지와 잘 비교해봐야할 것입니다.
리소스 단위로 캐싱 관리를 잘하고 CDN을 활용하는 것도 친환경적인 방법이 될 수 있겠습니다.
gRPC가 언급되어 REST 대신 쓸 수 있나 찾아봤는데 인간이 읽을 수 없는 등 난관이 있어보입니다.
댓글을 남기려면 로그인이 필요합니다.