TOC
참고
본 내용은 구글 엔지니어는 이렇게 일한다(링크)를 읽고 정리한 내용입니다.
책의 내용과 함께 개인적인 의견과 생각, 학습을 담아 작성하였습니다.
들어가며
- 프로그래밍 스타일 가이드의 목표는 코드의 지속 가능성을 높이도록 이끄는 것
- 언어별로 스타일 가이드를 다르게, 독립적으로 관리한다. 언어마다 장점, 특성, 우선순위, 도입 배경이 제각각이기 때문이다.
'지속 가능성'이라는 용어가 참 좋네요. 그동안 유지보수성이라는 용어를 많이 사용해왔는데 용어 사전에 하나 추가하겠습니다.
규칙이 필요한 이유
- 규칙의 목표는 '좋은' 행동을 장려하고 '나쁜' 행동을 억제하기 위함. 단, 이 기준은 조직마다 다르다. 때문에 조직이 추구하는 가치를 파악해야 한다.
- 규칙과 지침은 조직의 공통 코딩 어휘가 된다. 그러면 코드 표현 '형식'보다는 코드에 담는 '내용'에 집중할 수 있다.
규칙 만들기
규칙 모음을 정의할 때는 어떤 목표를 이루려 하는지가 중요하다. 목표에 집중하면 규칙이 따라온다.
좋은 관점이네요. 저는 무언가를 의식적으로 하는 것을 잘 못해서 훈련을 하고 있어요. 이 역시 규칙을 만들어야 하기 때문에 만드는 게 아니라 어떤 목표를 이루기 위해 규칙을 만드는지 의식하고 만든다는 개념이라 숙지하면 좋겠다고 느낍니다.
기본 원칙 안내
- 구글에서 규칙의 가치는 '규모와 시간 양쪽 측면에서 탄력적인 엔지니어링 환경이 지속되도록 하는 것'
- 구글에서 규칙의 목적은 '개발 환경의 복잡도를 관리하고 엔지니어들의 생산성을 희생하지 않는 선에서 코드베이스를 관리 가능하게끔 유지하는 것'
- 구글에서 규칙을 만들 때 염두에 두는 것
- 규칙의 양을 최소화한다.
- 코드를 읽는 사람에게 맞춘다.
- 일관되어야 한다.
- 오류가 나기 쉽거나 예상치 못한 동작을 유발하는 구조를 피한다.
- 꼭 필요하다면 실용성을 생각해 예외를 허용한다.
규칙의 양을 최소화한다
- 가이드가 많으면 익히고 적응하는 데에 비용이 든다. 또 관리도 어렵다.
- 너무 자명한 규칙은 의도적으로 배제한다.
이 부분 cursor rules를 작성할 때 참고하면 좋을 것 같아요. 일반적으로 자명한 것은 빼버려야 겠습니다.
코드를 읽는 사람에게 맞춘다
- 코드는 작성되는 횟수보다 읽히는 횟수가 더 많다.
- 읽기 난해한 것보다 타이핑이 지루한 게 낫다.
- 변수와 타입 이름은 읽기에 서술식으로 더 길게 짓는다. 그리고 귀찮아도 반복해서 타이핑한다.
- 코드에 의도한 행위를 분명하게 남겨라. 읽는 사람이 파악하게 하지 말고.
- 함수의 구현부를 보지 않더라도 호출 지점에서 무슨 일이 벌어지는지 알 수 있도록 하라.
클린코드에서도 강조하는 내용입니다. 변수명과 함수명이 길더라도 어떤 의미를 가지는지 명확하게 보여주는 것이 더 중요하다는 것에 공감합니다.
조금 별개이지만, 전에 했던 프로젝트에서 토스의 세종대왕 프로젝트처럼 한글 폴더, 컴포넌트, 변수, 함수 등을 추진했던 기억이 납니다. 모두가 영어를 사용해왔기에 처음엔 거부감이 있었던 것은 사실이지만, 지원서 특성상 영어로 매핑했을 때 소통과 학습 장벽이 더 생길 수 있었거든요. 결과는 대성공이었죠.
일관되어야 한다
- 구글은 모든 하드웨어와 기기를 어떤 구글의 공간에서도 호환되게 설정하여 공간 변화에도 업무 적응이 없도록 했다.
- 코드도 마찬가지다. 코드가 일관되면 익숙하지 않는 부분을 볼 때에도 빠르게 작업이 가능하다.
- 프로젝트마다 도구, 기법, 라이브러리는 모두 똑같다.
토스에서는 개별 조직 프로젝트에서도 자사 오픈소스 라이브러리를 많이 사용하는 것으로 알고 있습니다. 이게 사일로 방식으로 조직을 운영하면서도 문제가 커지지 않는 이유가 아닐까 싶습니다. 사용하는 라이브러리가 같기 때문에 프로젝트를 오갈 때 적응이 빠르게 될테니까요. 전사적 디자인시스템을 통일하는 것도 그런 이유 때문이지 싶고요.
일관성이 안겨주는 이점
- 때로는 일관성이 구속으로 느껴지는 것은 사실이다. 하지만 더 많은 엔지니어가 더 많은 일을 더 적은 노력으로 수행할 수 있다.
- 코드베이스의 스타일과 기준이 일관되면 '무엇을' 하느냐에 집중할 수 있다.
- 일관성은 규모를 확장하기 쉽게 돕는다. 여기에는 도구 활용이 핵심이다.
- 모든 사람이 각자의 방식으로 코드를 작성한다면 균일성에 의존하는 도구의 이점을 제대로 누릴 수 없다.
- 조직의 엔지니어를 재배치할 때에 용이하다. 엔지니어가 다른 팀에 가서 적응을 빠르게 할 수 있다.
이게 정말 트레이드오프의 영역이라고 생각합니다. 정말로 전사의 모든 프로젝트가 같은 구조의 같은 라이브러리를 사용하는 등 똑같으면 좋겠지만 그렇지는 않겠죠. 그런데 이를 어디까지 통일되게 만들 것인가는 '정도'의 영역입니다. 어떤 프로젝트는 SEO를 위해 Next.js를 사용하지만, 또다른 프로젝트는 DX를 위해 Vite+CSR을 사용한다면 이 역시 차이잖아요. 이걸 같다고 친다면 React와 Vue 등의 언어도 통일해야 할까요? 그 일관됨의 선은 어떻게 잡으면 좋을까요.
표준 정하기
- 사내의 일관성(지역적인 일관성)을 더 중요시 하라.
- 단, 외부 커뮤니티와의 일관성과 다르다면 유지하는 것과 바꾸는 것의 비용을 비교하라.
- 길게 보면 널리 쓰이는 표준을 따르는 게 유리하다.
오류를 내기 쉽거나 예상과 다르게 동작할 여지가 있는 구조는 피하기
- 구글은 코드베이스가 특정 전문가의 전유물이 아닌 모든 엔지니어의 작업 공간이 되길 원한다.
- 초보 SW 엔지니어한테도, 사이트 신뢰성 엔지니어(SRE)한테도 유리하다.
- 이해하기 쉽고, 유지보수가 쉬운 명료하고 직관적인 코드를 추구하라.
사실 어렵고 잘 짜여진 코드를 봤을 때 "와" 하는 게 있는데, 좋은 코드는 쉬운 코드라는 이야기에 공감합니다. 이것도 결과론적인 거겠죠. 잘 굴러가는 코드를 위해서는 쉽고 이해하기 좋아야 할테니까요.
실용적 측면을 인정하자
- 어리석게 일관성만 고집한다면 편협한 홉고블린과 다를 바 없다.
성능: 예를 들면 일관성과 가독성을 희생해서라도 성능을 끌어올려야 할 때상호운용성: 외부 코드와 연동되도록 설계할 때는 대상 코드와 잘 어우러져야 한다.- 일관성은 매우 중요하지만 융통성이 없어서는 안 된다.
스타일 가이드
모든 스타일 가이드는 세 범주로 나눌 수 있다.
- 위험을 피하기 위한 규칙
- 모범 사례를 적용하기 위한 규칙
- 일관성을 보장하기 위한 규칙
스타일 가이드는 보통 '일관성 보장'에 초점을 맞췄는데 의외로 가장 나중에 소개가 되는군요.
규칙 수정하기
- 세월이 흐르면 내부 사정과 기존 결정의 요인들도 바뀐다.
- 때로는 재평가가 필요할 정도로 여건이 달라진다.
- 모든 규칙을 유용하고 최신 상태로 유지하려면 업데이트가 필요한 규칙이 무엇인지를 적시에 알아채야 한다.
좋은 말입니다. 항상 이런 게 고민이 많이 되더라고요. 과연 왕도는 없는가.
- 구글에서는 각 결정마다 근거를 명시해둔다.
- 규칙을 추가할 때
- 장단점이 무엇인지
- 잠재적인 파장은 뭘지
- 결정 실행에 따른 변경량은 규모에서 문제가 없는지
도입 근거와 과정을 적으면 규칙의 정당함을 세우는 것도 맞지만, 상황이 바뀌었을 때 변경을 판단하는 기준이 된다는 사실이 좋네요. 규칙을 세울 때 이런 원칙을 참고해야 하겠습니다.
프로세스
- 변경할 게 있는지 찾고 갱신하는 데에는 프로세스가 필요하다.
- 구글은 '해법'이 중심이다. 현재 문제를 찾아내고 해법을 보여주며 제안한다.
- 엔지니어 커뮤니티가 가장 유리한 시작이다.
지침
- 구글의 엔지니어링 경험에서 선별한 지혜이자 과거로부터 배운 교훈들로부터 추린 모범 사례
- 규칙이 반드시(must) 지켜야 하는 것이라면 지침은 되도록(should) 따라야 하는 것
- 지침의 예시로 구글에서는 주요 언어들의 입문서가 있다. 범용 사용법과 구글 내 사용법이 다르기 때문에 구글에 특화된 방식을 다시 교육한다.
규칙 적용하기
- 규칙을 정해도 적용하지 않으면 의미가 없다.
- 구글은 규칙들이 요구하는 모범 사례들을 숙달하게끔 도와주는 정규 교육을 운영한다.
- 참고 문서들이 낡은 규칙을 담고 있지 않도록 업데이트하는 것에도 자원을 투자한다.
- 사람의 눈이 아닌 자동화 도구가 규칙의 준수를 감시하도록 하는 것도 좋다.
앎과 실천은 다르다는 말이 가장 먼저 와닿았습니다. 실천이 필요한데, 이를 위한 실천 방식도 잘 되어 있다고 느꼈습니다.
오류 검사기
- 언어 사용법과 관련된 규칙 상당수는 정적 분석 도구로 강제할 수 있다.
- 규칙의 위반 뿐 아니라 어떻게 변경하면 좋을지 가이드를 주면 더 좋다.
- 유연하게 적용할 수 있도록 검사에서 제외할 수 있는 옵션도 제공해야 한다.
eslint를 처음 봤을 때는 너무 빡빡하고 불편하게 느꼈지만, 이제는 제가 놓친 게 무엇인지 코드 작성 과정에서 바로 알려주는 규칙이 되었습니다. 더 올라가면 typescript도 그랬어요. 뭐가 이렇게 복잡하고 불편한지 계속 오류를 터트리고 퍼포먼스도 안 나왔죠. 그런데 이제는 없으면 큰일 날 것 같습니다.
코드 포맷터
- 코드의 형식을 일관되게 관리하기 위해 사용한다.
- 코드의 형식은 엔지니어들에게 더이상 논의거리가 아니다. 로직에 집중한다.
- 결과 역시 대부분의 경우 사람보다는 자동화 도구가 훨씬 뛰어났다.
prettier 없는 환경에서 개발하면 힘들어 죽을 겁니다. 포맷팅을 일일히 해주어야 한다니요. 너무 좋은 시대에 개발자로 일하고 있습니다.
총평
- 재미있는 인사이트를 얻을 수 있는 부분이 많았습니다. 공감이 되는 부분도 있었고요. 기억에 남는 것은 규칙 도입에 근거를 함께 적어 나중에 상황이 바뀌게 되었을 때 유지해야 할 지, 바꿔야 할 지 기준으로 삼는다는 내용이 좋았습니다.
- 원칙보다는 결과에 기반한 의사 결정들이 많아서 좋았습니다. 무조건 유지하는 것도, 무조건 바꾸는 게 아니라 객관적인 근거와 계산 하에 트레이드오프를 고려하여 결정한다는 영역도요. '실용주의 프로그래머' 책이 떠오르더라고요.
- 평소에 고민하던 선택의 영역과 혼란에 대해서도 다루었지만 엄청나게 간지러운 부분을 긁어주었다는 느낌은 들지 않습니다. 특히 구글이 생각하는 일관성의 디테일한 범위가 어디까지일까가 궁금했어요. 그리고 구글 뿐만이 아니라 다른 회사들은 어느 정도까지 프로젝트와 팀간의 일관성을 맞추는지도 궁금해졌고요.
- 전체적으로 스타일 가이드들이 궁금해서 github page도 눌러보고 다른 페이지들도 들어가 봤는데, 아쉽게도 github page는 사라졌고, 기껏 들어갔는데 C++과 파이썬만 취급하는 등 유효한 링크들이 없었습니다. 이 점이 조금 아쉽네요.
