[개발 서적] 구글 개발자는 이렇게 일한다 - 1편 소프트웨어 엔지니어링

 

본 글은 구글 엔지니어는 이렇게 일한다에서 각 파트별 요약 정리를 위한 내용을 담고 있습니다.

No	주제	책 해당 목차	주요 주제 요약
1편	소프트웨어 엔지니어링	1장	소프트웨어 엔지니어링의 정의, 지속 가능성, 하이럼의 법칙
2편	구글의 협업 문화와 팀워크	2장 ~ 4장	팀워크, 지식 공유, 공정성(다양성과 포용성)
3편	리더십과 생산성	5장 ~ 7장	기술 리더십, 성장하는 조직, 생산성 측정 철학
4편	품질을 위한 개발 프로세스	8장 ~ 11장	스타일 가이드, 코드 리뷰, 문서화, 테스트 개요
5편	테스트와 기술 부채 관리	12장 ~ 15장	테스트 심화 (단위, 통합, 대역), 기술 부채 및 폐기 전략
6편	개발 인프라와 도구: 구글의 자동화 시스템	16장 ~ 25장	빌드 시스템, CI/CD, 정적 분석, 의존성, 리뷰 도구 등 개발 인프라 전반

---

1편. 소프트웨어 엔지니어링 – 변화에 견디는 코드를 만든다는 것

‘코드를 잘 짠다’는 말에는 많은 의미가 담겨 있습니다.
동작하는 코드, 깔끔한 코드, 빠른 코드 외에도 “시간이 지나도 무너지지 않는 코드”, 즉 변화에 강한 코드입니다.

소프트웨어는 언젠가 반드시 바뀝니다.
기능이 바뀌고, 사용하는 사람이 바뀌고, 개발자가 바뀝니다.
그 변화 속에서 살아남기 위해 필요한 것이 바로 소프트웨어 엔지니어링입니다.

---

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

“프로그래밍은 문제 해결이다.
소프트웨어 엔지니어링은 그 해결책이 시간 속에서도 계속 유효하게 만드는 것이다.”

 

프로그래밍은 기능을 구현하는 기술입니다.
반면, 소프트웨어 엔지니어링은 그 기능이 수년간 유지되고, 여러 명이 함께 일할 수 있도록 만드는 구조와 문화를 포함합니다.

 

지속 가능성(Sustainability)

좋은 소프트웨어는 변화에 강해야 합니다.
이는 처음부터 유지보수와 협업을 염두에 둔 설계, 문서화, 테스트, 리뷰 문화가 포함되어야 합니다.

 

하이럼의 법칙: 의도하지 않은 동작도 누군가는 쓴다

“API를 사용하는 사람이 충분히 많다면, 명세에 없는 동작조차 누군가는 사용하고 있다.”

 

당신이 생각하지 않은 부분도 실제 서비스에서는 의존 대상이 될 수 있습니다.
이로 인해 사소한 수정도 예기치 않은 오류를 낳을 수 있기에 설계를 명확하게, 명세를 구체적으로, 변경을 신중하게 해야합니다.

 

트레이드오프의 인식: 이상보다 현실

“비용은 언제나 존재한다. 중요한 건 그 비용을 언제, 어떻게 치를지 결정하는 것이다.”

 

소프트웨어 엔지니어링은 언제나 이상과 현실 사이의 균형에서 결정됩니다.
기술 부채를 줄이기 위한 리팩토링도, 빌드 속도를 위한 시스템 개선도, 결국은 비용과 시간이 필요합니다.

 

---

요약 정리

핵심 개념설명

소프트웨어 엔지니어링	단기 구현이 아닌, 장기 유지보수와 협업을 전제로 한 구조적 접근 방식
지속 가능성	시간이 지나도 잘 작동하고, 쉽게 이해되고 수정 가능한 코드
하이럼의 법칙	의도하지 않은 동작도 사용자에게는 '기능'이 될 수 있음
트레이드오프 인식	완벽보다 실현 가능한 시스템 설계와 개선 전략이 중요함

 

마무리

좋은 소프트웨어는 혼자 만드는 것이 아니며, 변화를 견딜 수 있도록 처음부터 구조화되어야 합니다.

1편에서는 ‘지속 가능한 소프트웨어 엔지니어링’이라는 철학을 살펴봤습니다.

2편에서는 이 철학이 현실 속에서 어떻게 팀워크와 협업 문화로 연결되는지 살펴보겠습니다.