구글 엔지니어는 이렇게 일한다(타이터스 윈터스, 톰 맨쉬렉, 하이럼 라이트) - 02
공감되거나 인상 깊었던 문장들은 다음과 같다.
- 소프트웨어의 수명이 길어질수록 ‘동작한다’와 ‘유지보수 가능하다’의 차이를 더 분명하게 인지해야 한다. 둘을 구분하는 완벽한 해법은 없다. 소프트웨어를 장기간 유지보수하는 일은 끝나지 않는 전쟁이기 때문이다. (P.46)
- 하이럼의 법칙(Hyrum’s Law): API 사용자가 충분히 많다면 API 명세에 적힌 내용은 중요하지 않다. 시스템에서 눈에 보이는 모든 행위(동작)를 누군가는 이용하게 될 것이기 때문이다. (P.46)
- 하이럼의 법칙은 최선의 의도, 최고의 엔지니어, 꼼꼼한 코드 리뷰가 뒷받침되더라도 공표한 계약(명세)이나 모범 사례를 완벽하게 구현해냈다고 단정할 수 없다는 현실을 표현한다. API 소유자는 인터페이스를 명확하게 설명해놓으면 어느 정도 유연성과 자유를 얻을 수 있다. 하지만 현실에서는 API 사용자가 명세에 없는 기능을 찾아 활용하기도 하며, 그 기능이 유용해 널리 쓰이면 추후 API를 변경하기 어렵게 된다.
- 사용자가 늘어나면 가장 무해할 듯한 변경도 일부 사용자의 소프트웨어를 망가뜨릴 수 있다. (P.47)
- 모든 변경은 누군가의 워크플로우와 충돌한다. (P.47)
- 이용하는 API의 명세에 명시되지 않은, 즉 언제든지 변할 수 있는 기능을 사용하는 코드는 ‘임시방편적(hacky)’ 혹은 ‘기발한(clever)’ 코드다. 반대로 모범 사례를 따르고 미래에 대비한 코드는 ‘클린’하고 ‘유지보수 가능한’ 코드다. 우리는 ‘기발한’이 칭찬으로 느껴지면 프로그래밍이라 하고, 질책으로 느껴진다면 소프트웨어 엔지니어링이라 말한다. (P.49)
- 이전 시스템에 문제가 없더라도 시간이 흐르면 변경을 진행할 이유(e.g. 보안 패치, 하드웨어 변경, 효율 개선 등)가 자연스럽게 만들어지기도 한다. (P.51)
- 변경은 본질적으로 좋지 않으므로 변경을 위한 변경은 삼가야 하지만 변화에 대응할 수는 있어야 한다. (P.51)
- 코드베이스의 수명이 다할 때까지 직면하는 변화가 몰고 오는 모든 변경을 안전하게 처리할 수 있다면 그 코드베이스는 지속 가능하다. (P.51)
- 비용이 너무 많이 드는 변경은 지연되기 쉽다. 변경 비용이 시간 흐름보다 가파르게 상승하는 시스템은 분명 확장 가능(scalable)하지 않다. (P.51)
- 소프트웨어 조직에서 가장 중요한 자산인 코드베이스 자체도 확장 가능해야 한다. 코드가 많아지고 변경 이력이 쌓이는 등의 이유로 빌드 시스템이나 버전 관리 시스템이 점점 느려진다면 어느 순간 더는 정상 운영할 수 없는 시점이 온다. 관련 지표들은 적극적으로 관리하지 않으면 천천히 악화된다. ‘끓는 물 속의 개구리’처럼 위험이 현실이 되는 순간까지 눈치채지 못할 수도 있다. (P.52)
- 우리는 전문성과 공유 포럼이 조직 확장에 기여하는 바가 크다는 사실을 깨달았다. 엔지니어들이 포럼에 질문하고 답하는 과정에서 지식이 전파되고 새로운 전문가가 성장한다. 100명의 자바 엔지니어가 있는 조직에서 질문에 기꺼이 답해줄 전문가가 한 명만 있어도 곧 더 나은 자바 코드를 작성하는 100명의 엔지니어가 생겨난다. 지식은 입에서 입을 타고 퍼지며 전문가들이 그 매개체가 된다. (P.54)
프로그래밍과 소프트웨어 엔지니어링의 차이점을 API 유지보수하는 관점에서 설명한 것이 인상 깊었다. 공식 문서에 작성되어 있지 않더라도 공개된 API는 누군가 사용할 수 있다는 점을 예로 들어 공개되어 버린 코드를 고치는 일은 얼마든지 충돌이 발생할 수 있으므로 변경에 주의해야 한다는 점이 공감됐다. 소프트웨어 엔지니어는 작성하는 코드의 생명 주기가 오래 유지될 것이라는 마음가짐을 갖고, 모범 사례를 따르고 미래에 대비한 코드를 작성해야 한다. 버전 업그레이드나 아키텍처 변경처럼 큰 변화가 일어나기 전에 대비가 필요하다. 이는 소프트웨어를 빌드해 나가면서 지속적인 리팩토링과 개선, 적극적인 관심과 관리를 통해 이뤄진다.
댓글남기기