[책] 구글 엔지니어는 이렇게 일한다 - 1

책을 읽고 인상 깊었던 글귀 정리

Chapter1. 소프트웨어 엔지니어링이란?

---

[1.1 시간과 변경]

엔지니어는 시간의 흐름과 언젠가 변경될 가능성에 더 신경 써야 합니다. 

십 년 이상(== 오랜 시간) 살아남는 프로그램의 경우 간접적이든 직접적이든 프로그램의 거의 모든 의존성(외부 라이브러리, 기반 프레임워크, 운영체제 등)이 처음과는 달라질 것입니다. 우리가 생각하는 소프트웨어 엔지니어링과 프로그래밍을 가르는 핵심은 이 사실을 인식하는데서 시작하며, 이 차이가 우리가 말하는 소프트웨어의 지속 가능성의 핵심입니다.

프로젝트의 기대 수명을 생각했을 때, 그 수명이 길것으로 예상된다면 프로젝트는 외부 환경의 변화에 대비하기 시작해야 합니다. 그렇지 않으면 매우 고통스러울 수 있습니다.  

대부분의 프로젝트는 세월이 충분히 흐르면 기반 환경을 모두 교체해야 할 것입니다. 하지만 아무런 외부 의존성 없이 (혹은 POSIX처럼 아주 오랜 기간 변하지 않는 대상만 이용하도록) 작성된 순수한 C 언어 프로젝트라면 리팩터링이나 난해한 업그레이드 없이 버틸 수도 있습니다. 이런 면에서 C 언어는 상당히 안정적이며, 이런 안정성이야말로 C 언어를 선택하는 주된 이유 중 하나입니다. 하지만 대부분의 프로젝트는 기반 기술의 변화를 훨씬 많이 겪습니다. 대다수의 프로그래밍 언어와 런타임은 C 언어보다 빠르게 변합니다. 여러분의 프로젝트가 의존하는 모든 기술에는 여러분이 사용하기 시작한 후에야 발견될 심각한 버그와 보안 구멍이 존재할 위험이 도사립니다. 

변경은 본질적으로 좋지 않으므로 변경을 위한 변경은 삼가야 하지만 변화에 대응할 수는 있어야 합니다.

 

[1.2 규모 확장과 효율성]

소프트웨어 조직에서 가장 중요한 자산인 코드베이스는 확장 가능해야 합니다. 코드가 많아지고 변경 이력이 쌓이는 등의 이유로 빌드 시스템이나 버전 관리 시스템이 점점 느려진다면 어느 순간 더는 정상 운영할 수 없는 시점이 옵니다. '전체 빌드에 걸리는 시간', '리포지토리에서 전체를 새로 내려받는 시간', '프로그래밍 언어 버전을 업그레이드하는 비용' 같은 지표는 적극적으로 관리하지 않으면 천천히 악화됩니다. 마치 '끓는 물속의 개구리'처럼 서서히, 위험이 현실이 되는 순간까지 단 한 번도 눈치채지 못할 수도 있습니다. 그래서 이런 문제들은 조직 차원에서 챙기며 확장 가능성에 신경 써야지만 안정되게 관리할 수 있습니다.

개발 과정에서 문제를 일찍 발견할수록 비용이 적게 든다는 사실은 널리 받아들여지는 진실입니다. 만약 개념잡기와 설계에서 시작하여 구현, 리뷰, 테스트, 커밋, 카나리를 거쳐 최종적으로 프로덕션 환경에 배포하는 과정이 있다고 했을 때, 해당 과정 타임라인에서 우측으로 갈수록 수정 비용이 더 커질 것입니다. (여기서 카나리는 소수의 사용자(주로 사내 집단)에만 배포하여 검증하는 테스트를 말함)

 

[1.3 트레이드오프와 비용]

프로그래밍하는 방법과 소프트웨어의 수명을 이해했고, 새 기능을 추가하고 관리할 엔지니어를 더 고용하면서도 제품을 온전히 유지보수하는 방법을 깨우쳤다면, 남은 것은 좋은 결정을 내리는 일뿐입니다. 결정을 내리는데 있어서 고려되는 비용은 아래와 같이 다양할 수 있습니다. 

• 금융 비용 (예: 돈)
• 리소스 비용 (예: CPU 시간)
• 인적 비용 (예: 엔지니어링 노력)
• 거래 비용 (예: 조치를 취하는 비용)
• 기회 비용 (예: 조치를 취하지 않는 비용)
• 사회적 비용 (예: 선택이 사회 전체에 미치는 영향)

비용을 평가할 때는 앞에서 열거한 모든 비용을 염두에 두어야 합니다. 소프트웨어 엔지니어링처럼 매우 창의적이고 수익성 높은 분야에서는 금융 비용보다는 인적 비용이 제한 요소일 가능성이 큽니다. 그래서 엔지니어들이 행복을 느끼게 만들고 일에 집중하고 참여할 수 있게 해 주면 효율이 높아지죠. 집중력이 생산성에 미치는 영향은 아주 커서 10%~20%의 차이는 우습게 만들어냅니다.

ex) 내가 두 주 동안 이 연결 리스트를 고성능 데이터 구조로 변환한다면 프로덕션 시스템의 메모리 5GB를 더 쓰지만 필요한 CPU 수를 2,000개 줄일 수 있어. 진행해야 할까? 이 물음에 답하려면 메모리와 CPU의 상대적 비용은 물론, 나아가 인건비(소프트웨어 엔지니어가 2주간 작업)와 기회비용 (2주 동안 엔지니어가 할 수 있는 다른 일)까지 고려해야 합니다.

전혀 과학적이지 않은 트위터 여론조사에 따르면 소프트웨어가 거대해진 오늘날에도 약 60%~70%의 개발자가 빌드를 로컬에서 실행한다고 합니다. 여러분의 조직에서는 빌드가 끝나기를 기다리느라 얼마나 많은 생산적인 시간을 낭비하고 있나요? 2000년대 중반 구글은 로컬에서 컴파일 했으며 코드베이스가 커져가며 컴파일 시간도 꾸준히 늘어났습니다. 자연스레 더 크고 강력한 로컬 머신을 구입하는데 지출이 커졌고 컴파일 시간 상승은 곧 일할 시간이 줄어든다는 뜻이라서 우회적으로 인건비를 상승시키는 효과도 있었습니다. 결국 구글은 자체 분산 빌드 시스템을 개발했습니다. 이 시스템을 개발하는데도 비용과 시간이 들어갔지만, 결과적으로 전체적으로는 절약되는 비용이 훨씬 컸음이 명백했습니다. (빌드가 빨라졌고, 엔지니어가 멍 때리는 시간이 줄어듬)

 

[1.4 소프트웨어 엔지니어링 vs 프로그래밍]

우리는 서로 관련은 깊지만 상이한 두 용어인 '프로그래밍'과 '소프트웨어 엔지니어링'을 구별해야 한다고 생각합니다. 그 차이 대부분은 시간 흐름에 따른 코드 관리, 시간 흐름에 따른 규모 확장의 영향, 이런 관점에서의 의사결정 방식에 있습니다. 프로그래밍은 코드를 생산하는 즉각적인 행위입니다. 소프트웨어 엔지니어링은 활용 가치가 남아 있는 한 오랫동안 코드를 유용하게 관리하고 팀 간 협업을 가능케 하는 정책, 관례, 도구 모두를 아우르는 종합적인 개념입니다.