구글 엔지니어는 이렇게 일한다. S E a G
구글,구글러,문화,프로세스,도구
Software Engineering at Google
구글이야기 문화, 프로세스, 도구의 모든 것 책도 상당히 두껍습니다.
색인까지 맨 뒷장 704쪽
왜 다른 회사가 저렇게 일하는 것에
관심을 가져야 하는가?
불과 몇 년 안 되어 구글 OKR이 도배가 된 시기가 있었다. 무언가 성공한 사례들을 만병통치약이라도 되는 듯 도입하는 붐이 근 10년간 반복되어 욌었다.
하지만, 이제는 다 안다 그것을 자신의 조직에 맞게 상황에 맞게 재구성하지 않는다면 큰 의미가 없다는 것을 말이다. 분명 누군가 도입한 사람들의 단기 성과들로 끝나버리기에는 너무 리소스 소모가 많은 활동이기에 다들 이제는 더 믿지 않고 더 움직이기 않게 되는 것이다.
그렇다고 벤치마킹 없이는 자신의 수준을 알 수 없고 견줄 수가 없기에 발전할 수도 없다. 그래서 충분히 공감하고 좋은 것을 자신들에 맞게 차용하면 되는 것이다.
그러면 부담이 없어진다. 답을 가져가려고 문제 해결책으로만 바라보는 순간 기존 것은 나쁜 것이고 문제 있음이고, 새로운 것이 항상 정답이기 때문이다.
소프트웨어 엔지니어링이란?
프로그래밍과 소프트웨어 엔지니어링의 가장 큰 차이는 시간 time, (규모) 확장 scale, 실전에서의 트레이드오프 trade-offs at play, 이렇게 세 가지라고 생각하니다. 소프트웨어 엔지니어링 프로젝트에서 엔지니어는 시간의 흐름과 언제가 변경 change 될 가능성에 더 신경 써야 합니다. 소프트웨어 엔지니어링 조직은 만들어낼 소프트웨어 자체뿐 아니라 제작하는 조직까지 양 측면 모두에서의 확장과 효율에 더 집중해야 합니다. 마지막으로 소프트웨어 엔지니어는 대체로 수명과 성장 속도를 정밀하게 예측하기 어려운 상황에서, 결과에 더 큰 영향을 주는 보다 복잡한 결정을 내려야 합니다.
프로그래밍은 결국 새로운 소프트웨어를 제작하는 수단, 프로그래밍 작업(개발 development)과 소프트웨어 엔지니어링 작업(개발development+수정modification+유지보수maintenance)
이 코드의 예상 수명은?
단순한 구동 수명이 아니라 유지보수 수명을 말합니다. 즉, 이 코드가 언제까지 개발, 구동, 유지 보수될 것인지, 혹은 이 소프트웨어의 가치가 언제까지 유효할지를 묻는 질문
소프트웨어의 지속 가능성, susttainability의 핵심, 사업적인 이유든, 소프트웨어의 기대 생애 동안 요구되는 모든 가치 있는 변경에 대응할 수 있는다면 '그 프로젝트는 지속 가능하다'라고 말합니다. 여기서 중요한 것은 역량만을 따진다는 점, 즉, 가치가 충분치 않거나 더 중요한 일을 위해 해당 변경을 진행하지 않기로 선택할 수 도 있습니다.
기술 부채(technical debit) 해야 할 일을 아직 하지 않은 것을 말하며, 따라서 코드에 바라는 모습과 현재 모습의 차이만큼 이 기술 부채의 크기
맨먼스 머신
이 책은 수만 명의 엔지니어와 함께 전 세계애 뻗어 있는 컴퓨팅 자원 위에서 수십 년을 살아남을 소프트웨어를 개발하고 유지보수하며 깨달은 내용을 소개 (p44)
구글은 어떻게 개발하고 코드를 관리하는가
책은 4가지 챕터로 구성됩니다.
특히, 프로세스 중의 문서자료를 유심히 보게 됩니다.
가장 성공적이었던 방법은 문서자료를 코드처럼 취급하여
엔지니어링 워크플로에 통합하는 것
이 설계를 택한 이유가 뭐지?
코드를 왜 이런 식으로 구현했을까?
(예컨대 2년 후 자신의 코드를 살펴보며) '내가' 왜 이렇게 구현했지?
덜 중요하게 생각하는 이유
많은 엔지니어가 글쓰기를 프로그래밍과는 별개의 기술로 봅니다. 이 책은 이 시각이 잘되었음을 보여줄 것입니다. 설혹 다르다 해도 글쓰기는 소프트웨어 엔지니어링에 반드시 필요한 기술입니다.
글쓰기에 자신 없어하는 엔지니어도 있습니다. 하지만 영어에 꼭 유창해야만 양질의 문서자료를 작성할 수 있는 건 아닙니다. 한 걸음 뒤에서 사용자의 관점으로 바라볼 줄만 알면 됩니다.
문서자료는 도구 지원이나 개발 워크플로 통합 측면에서 아직 많이 부족하기 때문에 작성하기가 상대적으로 더 어렵습니다.
문서자료가 기존 코드를 유지 보수하기 더 쉽게 해 준다고 생각하기보다는 유지 보수할 대상이 하나 더 늘어난다고 생각합니다.
작성자에게도 다음과 같은 혜택
API를 가다듬는 데 도움을 줍니다. API 문서화는 API가 가치가 있는지를 알아내는 가장 확실한 방법 중 하나입니다. 문서화를 하다 보면 자연스럽게 자신의 설계를 되돌아보게 됩니다. API를 말끔히 설명하거나 정의할 수 없다면 설계가 미흡했을 가능성이 큽니다.
유지보수를 위한 로드맵과 과거 이력을 제공합니다. 코딩에서 꼼수는 무조건 피해야 하지만, 어쩔 수 없다면 주석이라도 잘 달아둬야 합니다. 잘만 작성해두면 2년 전 코드에서 문제점을 찾아야 하는 경우 큰 도움이 될 것입니다.
코드를 더 전문적이고 매력 있어 보이게 합니다. 개발자들은 무의식적으로 문서화가 잘되어 있는 API를 더 잘 설계된 API라고 여깁니다. 항상 그런 것은 아니지만 일반적으로 상관성이 높습니다 겉치레로 들 릴 수도 있을 텐데, 그렇지 않습니다. 문서화가 잘되어 있는 제품은 유지관리가 잘되고 잇는 제품일 확률이 높기 때문이죠.
이용자들의 질문이 줄어듭니다. 아마도 작성자에게 돌아오는 가장 크게 와닿고 시간이 갈수록 더 커지는 혜택일 것입니다. 만약 다른 이에게 두 번 이상 똑같은 설명을 하고 있는 자신을 발견한다면 그 내용을 문서화하는 게 좋습니다.
문서자료는 소스 코드와 밀접하게 연관된 경우가 많으므로 가능한 한 코드처럼 다뤄야 합니다.
꼭 따라야 하는 내부 정책과 규칙이 있어야 합니다.
버전 관리 시스템이 등록해 관리해야 합니다.
관리 책임자를 명시해야 합니다.
변경 시 (문서자료가 설명하는 코드와 함께) 리뷰를 거쳐야 합니다.
코드 상의 버그를 추적하듯 문제를 추적해야 합니다.
주기적으로 평가(혹은 테스트)를 받아야 합니다.
가능하다면 정확성이나 최신 정보 반영 여부 등을 측정해야 합니다(아쉽게도 아직은 도구들이 충분히 뒷받침해주지 못합니다).
문서자료 리뷰
'정확성' 확인용 기술 리뷰 : 주로 해당 주제 전문가가 수행하며, 팀 동료인 경우가 많습니다. 코드 리뷰 과정에서 함께 다르곤 합니다.
'명확성' 확인용 독자 리뷰 : 주로 도메인을 잘 모르는 사람이 수행합니다. 팀에 새로 합류한 동료나 해당 API의 고객일 것입니다.
'일관성' 확인용 작문 리뷰 : 주로 테크니컬 라이터나 지원자가 수행합니다.
누가, 무엇을 언제, 어디서, 왜
'누가'는 앞에서 한번 이야기했습니다. 바로 독자죠. 하지만 대상 독자가 누구인지를 문서 안에서 명화 하게 밝혀줘야 할 때도 있습니다. 예컨대 'Sectet Wizard 프로젝트에 새로 합류한 엔지니어를 위한 무서입니다'처럼 말이죠.
'무엇'은 문 성 목적을 알려줍니다. '이 문서는 Frobber 서버를 테스트 환경에서 구동하기 위해 설계된 튜튜 리얼입니다'처럼 말이죠. 때로는 '무엇'을 작성하는 것만으로 문서를 적절하게 구성하는 데 도움이 됩니다. 예를 들어 '무엇'과 연관이 없는 정보가 적혀 있다면 해당 내용을 별도 옮기라는 신호입니다.
'언제'는 문서가 생성되고, 리뷰되고, 갱신된 날짜를 말합니다. 소스 코드에 임베드된 문서자료는 날짜 정보가 묵시적으로 들어갑니다. 다른 형태의 문서자료들도 개시될 때 이 정보가 자동으로 추가되기도 합니다. 만약 자동화된 시스템이 없다면 문서 자체에 작성일(혹은 최종 갱신일)을 기입해주세요.
'어디에'는 문서가 존재해야 할 장소를 말해주며, 역시 묵시적으로 결정되는 경우가 많습니다. 보통 설정과 관련된 정보는 버전 관리 시스템으로, 이성적으로는 '문서자료가 설명하는 소스 코드와 함께' 관리합니다. 그 외 목적의 정보는 다른 포맷의 문서를 이용하죠. 예를 들어 구글에서는 특히 설계와 관련한 문제는 구글 문서를 애용합니다. 협업하기 편하기 때문입니다. 하지만 어느 시점부터 공유 문서의 주 용도는 '논의'보다는 '안정된 버전 기록' 쪽으로 치우치기 시작합니다. 그 시점이 되면 더 안정적이고, 소유권도 명확하고, 버전 관리도 잘되는 다른 시스템으로 옮기는 게 좋습니다.
'왜'는 문서의 목적을 설정합니다. 문서를 읽은 독자가 무엇을 얻어가기를 바라는지를 요약합니다. 경험상 '왜'는 문서의 소개 부분에 명시하는 게 좋습니다. 그러면 마지막에 요약을 작성할 대 '왜'를 기초로 원래 기대한 바를 달성했는지를 확인하고 달성하도록 보강할 수 있습니다.
핵심 정리
문서자료는 시간이 흐르고 조직 규모가 커질수록 더 중요해집니다.
문서자료 변경도 기존 개발자 워크플로에 통합되어야 합니다.
하나의 문서는 하나의 목적에 집중해야 합니다.
문서자료는 자신이 아니라 독자를 위해 써야 합니다.
나는 리뷰어이다.
매달 나는 리뷰어이다 활동을 하면서, IT 감을 잃지 않고 있습니다. 나름 한 손에는 트렌드와 다른 한 손에는 기술을 보듬어 가고 있습니다.
