🧑🏻‍💻 구글 엔지니어는 이렇게 일한다 (1) - 소프트웨어 엔지니어링

🚀 1. 소프트웨어 엔지니어링

소프트웨어 엔지니어링은 흐르는 시간 위에서 순간순간의 프로그래밍을 모두 합산한 것이다.

-구글-

 

소프트웨어 엔지니어링에서 프로그래밍이 큰 비중을 차지하는 건 틀림없지만 프로그래밍은 결국 새로운 소프트웨어를 제작하는 수단입니다.

이 차이를 받아들인다면 자연스럽게 프로그래밍 작업(개발, development)과

소프트웨어 엔지니어링 작업(개발 / development + 수정 / modification + 유지보수 / maintenance)의 차이도 궁금할 것입니다.

 

시간이라는 요소가 더해지면서 프로그래밍에는 중요한 차원이 하나 늘어서 더 입체적으로 바뀝니다.

시간이 프로그램에 미치는 영향을 알아보려면 “이 코드의 예상 수명은?” 이라는 질문을 던져보면 좋습니다.

짧게 생을 마감하는 코드는 대체로 시간의 영향을 받지 않습니다. 하지만 수명이 길어질수록 변경이라는 요소가 점점 중요해집니다.

 

우리가 생각하는 소프트웨어 엔지니어링과 프로그래밍을 가르는 핵심은 이 사실을 인식하는 데서 시작합니다.

 

⏱️ 1-1. 시간과 변경

🔗 소프트웨어 프로젝트의 기대수명과 업그레이드의 중요도의 관계

프로젝트는 외부 환경의 변화에 대비하기 시작해야 하고 지속 가능하게 하기 위해서는 요구되는 변경들의 영향을 계획하고 관리해야 합니다.

 

🔍 단명하는 프로그램용 코드와 수명이 훨씬 긴 프로젝트가 만들어내는 코드는 구체적으로 어떻게 다를까요?

 

수명이 길어질 수록 동작한다 와 유지보수 가능하다의 차이를 더 분명히 인지해야 합니다.

이 둘을 구분하는 완전한 해법은 없습니다.

• 소프트웨어를 장기간 유지보수하는 일은 끝나지 않는 전쟁이기 때문입니다.

 

📖 1.1.1 하이럼의 법칙

엔지니어들이 프로젝트를 유지보수 하고 있다면 동작한다 와 유지보수 가능하다 를 구분 짓는 가장 중요한 요인은 하이럼의 법칙 일 것입니다.

하이럼의 법칙

• API 사용자가 충분히 많다면 API 명세에 적힌 내용은 중요하지 않습니다.
• 시스템에서 눈에 보이는 모든 행위(동작)를 누군가는 이용하게 될 것이기 때문

 

💡 시간의 흐름에 따른 변경과 유지보수를 이야기하기 위해서는 하이럼의 법칙을 알아야 합니다.

 

하이럼의 법칙은 최선의 의도, 최고의 엔지니어, 꼼꼼한 코드 리뷰가 뒷받침되더라도 공표한 계약(명세)이나 모범 사례를 완벽하게 구현해냈다고 단정할 수 없다는 현실을 표현한 말입니다.

 

API 소유자는 인터페이스를 명확하게 설명해놓으면 어느 정도의 유연성과 자유를 얻을 수 있습니다.

하지만 현실에서는 API 사용자가 (명세에는 없는) 기능을 찾아 활용하기도 하며 그 기능이 유용해 널리 쓰이면 추후 API를 변경하기 어렵게 됩니다.

• 모든 변경은 누군가의 워크플로와 충돌한다.

따라서 변경이 얼마나 유용할 지를 분석할 때는 이러한 충돌을 조사, 식별, 해결하는 데 따르는 비용도 고려해야 합니다.

 

📖 1.1.2 사례: 해시 순서

동작한다 와 옳다 의 차이를 보여주는 아주 기초적인 예시

해시 컨테이너의 반복 순서에 의존하더라도 프로그램의 수명이 짧다면 기술적 문제를 겪지 않을 것입니다.

 

반면 소프트웨어 엔지니어링 프로젝트에서 이런 의존성은 위험 요인에 해당합니다.

 

당장 돌아가야 한다 라는 생각으로 작성한 코드와 언제까지고 작동해야 한다 라는 생각으로 작성한 코드의 차이를 생각해보면 어떤 관계인지가 분명하게 그려질 것입니다.

• 이용하는 API의 명세에 명시되지 않은, 즉 언제든 변할 수 있는 기능을 사용하는 코드는 “임시방편적인” 혹은 “기발한” 코드입니다.
• 반대로 모범 사례를 따르고 미래에 대비한 코드는 “클린하고 유지보수 가능한” 코드입니다.

 

📖 1.1.3 ‘변하지 않기’를 목표로 하지 않는 이유

시간과 변경에 대처하는 이유에 관한 모든 논의의 밑바탕에는 변경은 피할수 없다 라는 가정이 깔려있습니다.

 

효율 개선은 상황을 더욱 복잡하게 만듭니다.

구글은 데이터센터를 비용 효율적인 장비들로 꾸리길 원합니다(특히 CPU 효율 개선에 힘씁니다).

하지만 구글에서 오래전에 만들어둔 알고리즘과 데이터 구조는 최신 장비에서 효율이 떨어지기도 합니다.

연결 리스트와 이진 검색 트리는 여전히 잘 동작하지만 CPU 클록과 메모리 지연시간의 격차가 점점 벌어지면서 “효율적인” 코드의 모습이 변하고 있습니다.

그래서 소프트웨어 설계도 제때 변경해주지 않으면 최신 하드웨어를 도입하는 효과가 퇴색됩니다.

 

↗️ 1-2. 규모 확장과 효율성

조직에서 코드를 작성하고 관리하는 데 활용하는 모든 것이 총 비용과 자원 소비 측면에서 확장 가능해야 합니다.

 

📖 1.2.2 확장 가능한 정책들

우리가 좋아하는 구글 내부 정책 중 인프라팀이 인프라 변경을 안전하게 진행하게끔 보호해주는 정책이 하나 있습니다.

바로 “인프라를 변경하여 서비스가 중단되는 등의 문제가 발생하더라도 같은 문제가 지속적 통합(Continuous Integration, CI) 시스템의 자동 테스트에서 발견되지 않는다면 인프라 팀의 책임이 아니다”라는 정책입니다.

 

이 정책의 이름은 “비욘세 규칙”이며 친군하게 표현하면 “네가 좋아했다면 CI 테스트를 준비해뒀어야지”라는 뜻입니다.

공통 CI 시스템에 추가해두지 않은 테스트는 인프라 팀이 책임지지 않는다는 뜻입니다.

 

👍 우리는 전문성과 공유 포럼이 조직 확장에 기여하는 바가 크다는 사실을 깨달았습니다.

• 엔지니어들이 포럼에 질문하고 답하는 과정에서 지식이 전파되고 새로운 전문가가 성장합니다.

 

📖 1.2.4 원점 회귀(왼쪽으로 옮기기)

개발자 워크플로를 시간순으로 생각했을 때 문제 발견 시점을 왼쪽으로 이동시킬 수록 수정 비용이 줄어듭니다.

• 왼쪽으로 옮기는 행위를 원점 회귀

코드 커밋 전에 정적 검사나 코드 리뷰로 찾아낸 버그는 프로덕션 이후에 발견한 버그보다 훨씬 싸게 고칠 수 있습니다.

그래서 개발 프로세스 초기에 품질, 안정성, 보안 문제를 찾아 알려주는 도구와 관례를 제공하는 일은 구글 인프라 팀의 주요 목표중 하나입니다.

 

🔄 1.3 트레이드오프와 비용

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

 

좋은 선택이 대체로 좋은 결과로 이어집니다.

하지만 결정에 이르는 과정은 쉽게 간과되곤 합니다.

 

💰 비용의 정확한 뜻

 

비용은 금액만을 지칭하는 것이 아닌 투입된 노력과 다음의 요소들까지 모두 포괄합니다.

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

 

소프트웨어 엔지니어링 처럼 창의적이고 수익성이 높은 분야에서는 금융 비용보다는 인적 비용이 제한 요소일 가능성이 큽니다.

엔지니어들이 행복을 느끼게 만들고 일에 집중하고 참여할 수 있게 해주면 효율이 높아집니다.

 

📖 1.3.1 사례: 화이트보드 마커

결국 엔지니어링 조직의 선택을 결정짓는 요인은 다음의 몇 가지로 압축됩니다.

• 반드시 해야 하는 일(법적 요구사항, 고객 요구사항)
• 근거에 기반하여 당시 내릴 수 있는 최선의 선택(적절한 결정권자가 확정)

💡 의사결정이 내가 시켰으니까가 되어서는 안 됩니다.

 

📖 1.3.3 사례: 분산

전혀 과학적이지 않은 트위터 여론조사에 따르면 소프트웨어가 거대해진 오늘날에도 약 60%~70%의 개발자가 빌드를 로컬에서 실행한다고 합니다.

여러분의 조직에서는 빌드가 끝나기를 기다리느라 얼마나 많은 생산적인 시간을 낭비하고 있나요?

2000년대 중반 구글은 로컬에서 컴파일 했으며 코드베이스가 커져가며 컴파일 시간도 꾸준히 늘어났습니다.

 

결국 구글은 자체 분산 빌드 시스템을 개발했습니다.

시스템을 개발할 엔지니어를 투입해야 했고, 다른 모두의 컴파일 습관과 워크플로를 바꿔 새로운 시스템에 적응시키는 데는 더 많은 엔지니어 시간이 투입됐습니다. 빌드 시스템 자체를 구동할 컴퓨팅 자원도 별도로 필요했음은 물론입니다.

그래도 전체적으로는 절약되는 비용이 훨씬 컸음이 명백했습니다. 빌드가 빨라졌고 엔지니어가 멍 때리는 시간이 줄었습니다.

 

📖 1.3.5 결정 재고하기와 잘못 인정하기

잘 드러나지는 않지만 잘못했음을 인정할 수 있게 해주는 능력 역시 데이터 중심 문화가 주는 커다란 장점입니다.

우리는 취합한 데이터에 기초하여 특정 시점에 결정을 내립니다. 제대로 된 데이터이고 가정의 수는 가능한 한 적어야 좋겠지만 결정 시점에 가용한 데이터만을 활용해야 한다는 한계가 있습니다.

그래서 새로운 데이터를 얻어 상황이 바뀌거나 가정이 무너진다면 기존 결정에 오류가 있었음이 밝혀질 수도 있습니다.

• 당시에는 옳았지만 지금은 아닐 수도 있습니다.

시간은 기술적 의존성과 소프트웨어 시스템뿐 아니라 의사결정에 활용되는 데이터도 달라지게 하기 때문이죠.

• 우리는 데이터에 기초한 의사결정을 강력히 지지합니다.
• 하지만 데이터 자체도 시간이 지나면 변하고 새로운 데이터가 나타날 수 있음을 알죠.

그러니 시스템의 생애 동안 과거에 내린 결정을 수시로 재고해봐야 합니다.

 

이때 중요한 것은 결정권자에게 잘못을 인정할 권리가 있느냐입니다. 어떤 사람의 직관에는 맞지 않을지 모르지만 잘못을 인정할 줄 아는 리더가 더 존경받습니다.

 

🆚 소프트웨어 엔지니어링 vs 프로그래밍

서로 관련은 깊지만 상이한 두 용어인 프로그래밍 과 소프트웨어 엔지니어링 을 구별해야 한다고 생각합니다.

• 그 차이 대부분은 시간 흐름에 따른 코드 관리, 시간 흐름에 따른 규모의 확장의 영향, 이런 관점에서의 의사결정 방식에 있습니다.

프로그래밍은 코드를 생산하는 즉각적인 행위입니다.

소프트웨어 엔지니어링은 활용 가치가 남아 있는 한 오랫동안 코드를 유용하게 관리하고 팀 간 협업을 가능케하는 정책, 관례, 도구 모두를 아우르는 종합적인 개념입니다.

 

🤔 1장을 읽고나서,,,

✅ 프로그래밍과 소프트웨어 엔지니어링의 본질적 차이

프로그래밍은 “작동하는 코드”를 만드는 즉각적 행위라면 소프트웨어 엔지니어링은 코드의 “장기적 생존”과 관련된 모든 것(정책, 관례, 도구, 협업 등)을 아우르는 개념이구나!

 

✅ 시간과 변경 / 유지보수의 중요성

• 시간이 흐름에 따라 “동작하는 것”과 “유지보수 가능한 것”의 차이가 점점 커진다는 점 그리고 이 차이를 극복하는 데 명확한 해법이 없다..!
• 하이럼의 법칙처럼 사용자의 의도하지 않은 동작으로 인해 코드 변경 비용으로 이어질 수 있음을 배움.

 

✅ 정책, 도구, 자동화의 필요성

• 구글의 인프라팀 정책 “비욘세 규칙”와 같은 정책과 자동화(자동 테스트, CI 등)를 통해 대규모 조직에서도 시스템을 안정적으로 운영하는 것을 배움
• 코드 품질을 보장하고 비용을 줄이기 위한 방법을 고민을 해야겠다.. (원점 회귀 전략)

 

✅ 비용과 트레이드오프를 고민하기

• 소프트웨어 개발에서 비용은 단순한 금전뿐 아니라 엔지니어의 노력, 시스템 자원, 의사 결정 비용, 기회비용 등 다양한 형태로 존재함을 배움.
• 현재의 최선의 선택이 나중에 바뀔 수 있음을 인정하고 데이터와 환경의 변화에 따라 결정을 재고하는 유연성의 중요성

 

🚀 결론

장기적이고 지속 가능한 소프트웨어를 만들려면 코딩을 넘어서 설계, 프로세스 개선, 협업, 자동화, 문화 전반에 관심을 가져야 하며 시간의 흐름에 대응하는 유연한 사고가 필요하다..!

 

📚 Ref.

https://product.kyobobook.co.kr/detail/S000061352347