14년간 구글에서 근무한
개발자의 조언
21 Lessons from 14 Years at Google
이 글은 14년간 구글에서 근무한 개발자 Addy Osmani가 작성한 21 Lessons from 14 Years at Google의 내용을 한국어로 정리한 내용입니다. 영어가 익숙하시다면 본문을 직접 읽어보시는 것을 추천드립니다.
이분이 Addy Osmani 라네요이 글의 핵심은 "성공하는 엔지니어는 단순히 코드를 잘 짜는 사람이 아니라, 사람, 조직의 방향성, 그리고 모호함을 잘 다루는 사람"이라는 것입니다. 그는 21개의 조언을 통해 기술적 역량뿐만 아니라 소프트 스킬과 마인드셋의 중요성을 강조합니다.
Addy Osmani는 이 글에서 호기심을 유지하고, 겸손함을 잃지 않으며, 작업의 핵심은 항상 사람이라는 점을 기억하라고 말합니다. 결국 내 주변에 있는 동료들, 그리고 내가 만드는 제품의 사용자들이 중요하다는 것을 강조합니다.
또한 엔지니어의 커리어는 실수를 충분히 저지르고도 성공할 수 있을 만큼 길다고 말합니다. 존경하는 모든 엔지니어들 또한 실패에서 배웠고, 발견한 것을 공유했으며, 꾸준히 모습을 드러낸 사람들이라고 합니다. 겉으로는 대단한 것을 이루는 사람들만 주변에 있는 것 같아 보이지만, 그 대단한 것을 이루기 위해 꾸준히 노력하고 실패한 사람들이 있다는 것을 기억해야겠습니다.
1. 최고의 엔지니어는 기술이 아닌 사용자 문제 해결에 집착한다
엔지니어는 기술적인 우아함이나 최신 트렌드(Tech Stack)에 매몰되기 쉽다. 하지만 엔지니어의 존재 이유는 코드를 짜는 것이 아니라, 사용자가 겪고 있는 고통을 덜어주는 것이다. 코드를 한 줄도 짜지 않고 문제를 해결할 수 있다면 그게 가장 훌륭한 엔지니어링이다.
"이게 기술적으로 멋진가?"가 아니라 "이게 사용자의 문제를 해결하는가?"를 항상 먼저 생각해야 한다.
2. 혼자 옳기보다 함께 정답을 찾는다
기술 논쟁에서 논리로 상대를 제압하여 '나의 정답'을 관철시키는 것은 잘못된 방법이다. 팀원들이 공감하지 못하는 정답은 실행 단계에서 실패할 확률이 높기 때문이다. 내 의견이 틀릴 수 있음을 인정하는 지적 겸손함을 갖고, 팀 전체가 합의한 '우리의 정답'을 도출하는 리더의 자질을 가져야 한다.
3. 실행이 답이다 (일단 배포하라)
완벽한 설계를 위해 몇 달을 토론만 하는 것은 시간 낭비일 때가 많다. 회의실에서 수백번 추측하면서 '분석 마비(Analysis Paralysis)'에 빠지는 것 보다, 차라리 엉성한 프로토타입이라도 빠르게 배포하여 실제 사용자 데이터와 피드백을 받는 것이 좋다.
4. 명확함이 곧 시니어의 역량이다
갓 입사한 주니어는 현란한 기법을 써서 '똑똑해 보이는 코드'를 짜려고 한다. 하지만 진정한 시니어는 누가 봐도 뻔하고 지루할 정도로 '쉬운 코드'를 짠다. 코드는 작성하는 시간보다 읽히는 시간이 훨씬 길다. 새벽 3시에 장애가 났을 때, 다른 동료가 즉시 이해하고 수정할 수 있는 코드가 최고의 코드입니다.
5. 혁신은 '대출'처럼 신중하게 하라
새롭고 실험적인 기술 스택이 항상 옳은 것이 아니다. 대부분의 기술은 지루하고 검증된(예: SQL, Java 등) 것을 사용한다. 제품의 핵심 경쟁력이 되는 딱 한두 군데에만 혁신의 에너지를 집중해야 실패 확률을 줄일 수 있다.
6. 코드는 나를 대변해주지 않는다
"묵묵히 일하면 언젠가 알아주겠지"라는 생각은 위험하다. 조직은 거대하고 바쁘기 때문이다. 내가 어떤 난제를 해결했는지, 어떤 가치를 창출했는지 '브래그 문서(Brag document)'나 주간 보고 등을 통해 적극적으로 알려야 한다. 나의 성과를 기록하고 알리는 것도 업무의 일부로 생각하자.
7. 최고의 코드는 작성하지 않은 코드다
모든 코드는 '부채'다. 코드가 늘어날수록 버그, 유지보수 비용, 인지 부하가 늘어난다. 기능을 추가해 달라는 요청을 받았을 때, 코드를 짜지 않고 해결할 방법은 없는지, 혹은 이 기능이 정말 필요한지 꼭 생각해야 한다. 작성하지 않은 코드는 디버깅하거나 유지보수하거나 설명하지 않아도 된다.
8. 하위 호환성의 중요성을 인지하자
API 사용자 수가 충분히 많아지면, 당신이 의도하지 않았던 버그나 부작용조차 누군가는 중요한 기능으로 사용할 수 있다. 따라서 규모가 큰 시스템에서는 사소한 수정도 누군가의 워크플로우를 망가뜨릴 수 있음을 인지하고, 하위 호환성을 꼭 신경써야 한다.
9. 방향이 일치하는 팀이 되어야 한다
엔지니어들이 타자를 느리게 쳐서 개발이 느린 경우는 없다. 기획팀은 A를 원하고, 개발팀은 B를 만들고, 디자인팀은 C를 생각하기 때문에, 계속 수정하느라 속도가 안 나는 것이다. 코딩 속도를 높이려 하지 말고, 전체 구성원이 같은 목표를 보고 있는지 확인하는 일에 시간을 써야 한다. 방향이 맞으면 속도는 저절로 따라온다.
10. 통제할 수 있는 것에 집중하라
대기업의 조직 개편, 프로젝트 취소, 경영진의 변경 등은 개인이 통제할 수 없는 부분이다. 이러한 통제 불가능한 변수에 스트레스를 받으면 번아웃이 온다. 대신 내가 오늘 작성할 코드의 품질, 동료에게 건네는 친절한 말 한마디, 나의 학습 등 '내가 통제 가능한 것'에만 집중하는 태도를 가져야 롱런할 수 있다.
11. 로우 레벨에 대한 학습을 게을리 하면 안된다
라이브러리나 프레임워크는 편리하지만, 그 내부 동작 원리를 모르면 문제가 터졌을 때 해결할 수 없다. 편리함을 누리되, 그 아래의 로우 레벨(OS, 네트워크, 메모리 등)이 어떻게 돌아가는지 끊임없이 호기심을 갖고 공부해야 결정적인 순간에 문제를 해결할 수 있다.
12. 글을 잘 쓰는 엔지니어가 되어야 한다
머릿속으로는 다 아는 것 같더라도, 글로 적었을때 논리의 구멍이 생길 때가 있다. 기술 문서, 설계 제안서, 블로그 글을 쓰는 행위는 남을 위한 것이기도 하지만, 사실 자신의 멘탈 모델을 디버깅하는 가장 좋은 방법이다. 설계를 잘하는 엔지니어들이 대체적으로 글을 잘 쓴다.
13. 보이지 않는 헌신에 대해서 근거를 남겨라
팀원 간의 의견 조율, 문서 정리, 온보딩 가이드 작성 등 코드 외적인 '접착제 업무(Glue Work)'는 팀의 성공에 필수적이다. 하지만 이것은 눈에 잘 띄지 않아 인사 평가에서 불이익을 받기 쉽다. 이런 일을 할 때는 반드시 티켓을 생성하거나 문서화하여, 이것이 팀에 얼마나 기여했는지 명확한 근거를 남기는 것이 중요하다.
14. 상대방을 이기기 위한 토론이 되어서는 안된다
논리적으로 상대를 완벽히 짓밟아 이기는 것은 최악의 승리다. 상대방은 납득한 게 아니라 '더 말해봤자 소용없다'고 느껴 입을 다문 것일 수 있다. 이런 패배감이 쌓이면 나중에 당신이 도움을 필요로 할 때나 프로젝트 위기 상황에서 동료들은 방관자가 된다. 관계를 잃지 않는 선에서 적극적으로 토론하는 것이 중요하다.
15. 측정 지표가 목표가 되면 더 이상 지표가 아니다
'코드 라인 수'나 '커밋 횟수'를 생산성 지표로 삼으면, 개발자들은 쓸데없이 코드를 길게 짜거나 의미 없는 커밋을 남발한다. 지표는 현재 상태를 파악하는 대시보드일 뿐, 그 자체가 목표가 되어서는 안된다. 숫자에 매몰되어 본질을 놓치는 것을 경계하자.
16. 모른다고 인정하는 것이 안전한 문화를 만든다
가장 경험 많은 시니어가 "이 부분은 저도 잘 모르겠네요, 같이 찾아볼까요?"라고 말할 때, 주니어들은 "아, 모르는 건 부끄러운 게 아니구나"라는 생각과 함께 심리적 안정을 느낀다. 모르는 것을 숨기는 문화에서는 치명적인 실수가 덮어지고 곪아 터지게 된다.
17. 네트워크는 직장보다 오래 간다
회사는 언젠가 떠나지만, 그때 맺은 동료 관계는 평생 간다. 지금 옆자리에 있는 동료가 5년 뒤 나를 더 좋은 회사로 이끌어 줄 사람일 수 있다. 코드 리뷰를 할 때나 협업할 때 적을 만들어서는 안된다. 평판은 복리로 쌓이는 자산이 된다.
18. 성능 개선은 '제거'에서 온다
코드를 0.1초 빠르게 최적화하는 것보다, 그 코드가 아예 실행될 필요가 없도록 프로세스를 바꾸는 것이 성능을 100배 향상할 수 있다. 가장 빠른 함수는 호출되지 않는 함수라는 생각을 가지고, "이 작업을 더 빠르게 하려면?"이 아닌 "이 작업을 안 해도 되게 하려면?"을 먼저 고민하는 것이 중요하다.
19. 프로세스는 불확실성을 줄이기 위해 존재한다
개발 프로세스(Jira, Agile, 회의 등)를 귀찮은 숙제라고 생각하면 안된다. 이것들은 '실수할 확률'을 줄이고 '예측 가능성'을 높이기 위한 도구다. 만약 어떤 프로세스가 리스크를 줄여주지도 않고 명확성도 주지 못한 채 시간만 뺏는다면, 그 프로세스는 잘못된 것이니 과감히 없애거나 고쳐야 한다.
20. 결국 돈보다 시간이 중요해진다
커리어 초기에는 연봉을 높이기 위해 야근과 주말 근무를 마다하지 않는다. 하지만 어느 순간 건강, 가족, 개인의 삶이 돈보다 훨씬 희소하고 가치 있다는 것을 깨닫게 된다. 번아웃이 오기 전에 일과 삶의 균형을 잡는 법을 배우고, 시간을 돈으로 사는(위임하기, 도구 사기 등) 지혜가 필요하다.
21. 지름길은 없지만 '복리'는 있다
하루아침에 구글 수석 엔지니어가 되는 비법은 없다. 하지만 매일 30분씩 읽는 기술 블로그, 매일 조금씩 개선하는 코딩 습관, 매일 쌓아가는 동료와의 신뢰는 '복리(Compound Interest)'로 불어날 수 있다. 당장은 티가 안 나도 5년, 10년 뒤에는 따라잡을 수 없는 격차를 만든다. 꾸준함이 유일한 지름길이다.
