구글에서의 14년, 그동안 배운 21가지 교훈

• 느린 팀은 실행력이 부족한 게 아니라 '조율'이 안 된 것이다
• 팀이 정체되어 있다면 대부분은 목표 설정(Alignment)의 실패이지, 기술력 부족이 아닙니다.
• 훌륭한 엔지니어는 단순히 코드를 잘 짜는 사람이 아니라, 복잡한 세상을 단순하게 만들고 동료들과 함께 사용자의 문제를 해결하는 사람입니다.

구글 14년 재직자 Addy Osmani의 글이 올라와 제미나이의 번역으로 5가지 주제로 정리해봤습니다.

기술보다 중요한 것은 '사람'과 '문제 해결'

• 사용자 문제에 집착하라: 기술 자체에 빠지지 말고, 사용자가 겪는 진짜 문제를 해결하는 데 집중해야 합니다. 우아한 코드보다 단순한 해결책이 더 가치 있을 때가 많습니다.
• 코드는 스스로를 대변하지 않는다: 아무리 코드를 잘 짜도 사람들이 그 가치를 모르면 영향력은 제로입니다. 자신의 성과를 명확히 알리고 동료들과 신뢰를 쌓는 것이 필수적입니다.
• 옳은 것보다 함께 가는 것이 중요하다: 혼자만 정답을 맞히는 것은 저렴한 승리입니다. 동료들을 설득하고 함께 정답에 도달하는 과정이 진짜 실력입니다.

엔지니어링의 본질: 단순함과 명확성

• 명확함이 곧 시니어의 역량이다: 똑똑해 보이는 복잡한 코드(Clever code)는 나중에 유지보수 비용만 높입니다. 2년 뒤 새벽 2시에 장애를 해결할 동료를 위해 가장 이해하기 쉬운 코드를 짜야 합니다.
• 가장 좋은 코드는 애초에 작성할 필요가 없었던 코드다: 코드를 추가하기 전에 "이게 정말 필요한가?"를 먼저 물으세요. 삭제된 코드는 버그를 만들지도, 유지보수할 필요도 없습니다.
• 추상화의 함정: 추상화는 복잡성을 없애는 것이 아니라 '이동'시키는 것입니다. 기반 기술에 대한 이해 없이 추상화에만 의존하면 장애 발생 시 대처할 수 없습니다.

효율적인 실행과 협업

• 실행에 우선순위를 두라 (Bias towards action): 완벽한 설계를 위해 고민만 하기보다, 일단 작게라도 출시해서 현실의 피드백을 받는 것이 훨씬 빠릅니다.
• 글쓰기는 사고의 도구다: 글을 쓰는 과정에서 자신의 지식에 구멍이 난 부분을 발견하게 됩니다. 남을 가르치고 글을 쓰는 것이 본인의 이해도를 높이는 가장 빠른 길입니다.
• 느린 팀은 실행력이 부족한 게 아니라 '조율'이 안 된 것이다: 팀이 정체되어 있다면 대부분은 목표 설정(Alignment)의 실패이지, 기술력 부족이 아닙니다.

조직 내에서의 생존과 성장

• 지표의 함정: 측정되는 지표는 반드시 왜곡되기 마련입니다. 지표 자체를 맹신하지 말고 그 이면의 트렌드와 맥락을 읽어야 합니다.
• 모른다고 말하는 용기: 시니어일수록 모르는 것을 솔직히 인정해야 팀 전체에 질문하기 편한 심리적 안전감이 형성됩니다.
• 네트워크는 직장보다 오래간다: 현재의 직업은 영원하지 않지만, 함께 일하며 쌓은 동료들과의 관계는 평생의 자산이 됩니다.

커리어와 삶에 대한 태도

• 시간의 가치: 커리어 초기에는 시간을 돈과 바꾸지만, 결국 시간은 대체 불가능한 자원임을 깨닫게 됩니다. 무엇을 위해 자신의 시간을 쓰는지 의식적으로 선택해야 합니다.
• 지식의 복리 효과: 지름길은 없지만, 꾸준히 학습하고 기록하며 재사용 가능한 자산(코드든 문서든)을 만드는 과정은 시간이 지날수록 복리처럼 거대한 차이를 만들어냅니다.

한줄평: 개인적으로는 복잡성을 해결했다는 것이 사실은 복잡성을 이동시킨 것에 불과했다는 결론이 뼈아프네요. 실무에서 일정, 리소스의 이유로 자주 빠지는 추상화의 함정. 조심하자고요!