구글 14년이 알려준 소프트웨어 엔지니어 커리어 전략

소프트웨어 엔지니어의 성장은 "코드를 잘 짜는 것"으로만 설명되지 않습니다. 구글에서 14년간 일한 한 엔지니어의 경험담을 들여다보면, 진짜 커리어를 가르는 건 기술 그 자체보다 사람, 문제 정의, 협업, 그리고 태도에 가깝습니다.

아래 내용은 그가 14년 동안 프로젝트와 팀을 옮겨 다니며 반복해서 깨달은 패턴을 재구성한 것입니다. 특정 기술 스택 이야기는 거의 나오지 않습니다. 대신 어떤 회사, 어떤 언어, 어떤 포지션에서도 통하는 "일하는 방식"에 대한 이야기로 채워져 있습니다.

엔지니어로 오래 가고 싶다면, 그리고 단순한 '개발자'가 아니라 '문제를 해결하는 프로페셔널'이 되고 싶다면, 한 번쯤 끝까지 읽어볼 만한 내용입니다.

사용자 문제에 집착하는 엔지니어가 끝까지 살아남는다

많은 엔지니어가 새로운 기술이나 프레임워크에 먼저 마음을 빼앗깁니다. "이거 어디다 써먹을 수 있지?"를 먼저 떠올리죠.

하지만 정말 높은 임팩트를 내는 사람들은 정반대로 움직입니다. 기술이 아니라 "사용자에게 지금 가장 아픈 문제는 무엇인가?"에서 출발합니다.

이들은 실제 사용자의 목소리를 최대한 가까이에서 듣습니다. 지원 티켓을 샅샅이 읽고, 고객 인터뷰에 참여하고, 사용자가 제품에서 헤매는 모습을 지켜봅니다. 그리고 "왜?"를 계속 물어보며 문제의 뿌리까지 내려가려 합니다.

이렇게 문제를 깊이 이해하고 나면, 생각보다 단순한 해법이 보이는 경우가 많습니다. 반대로 해결책부터 들고 시작한 프로젝트는 괜히 복잡해지기 쉽습니다. 기술을 껴맞추려고 만들다 보면, 필요 이상으로 거대한 시스템이 되어버리거든요.

결국 좋은 엔지니어링은 "멋진 기술 자랑"이 아니라 "사용자의 실제 고통 감소"라는 점을 잊지 않는 사람에게서 나옵니다.

혼자 옳은 것보다, 함께 옳은 방향으로 가는 게 더 어렵다

기술 토론에서 매번 이기는 사람이 있습니다. 논리도 빼어나고, 근거도 탄탄해서, 회의만 열리면 그 사람 의견으로 결론이 나곤 합니다.

그런데 이상하게도, 그 사람이 참여한 프로젝트는 자꾸 삐걱거립니다. 겉으로는 모두 동의한 것 같은데, 실제 실행 단계에서는 "이상한 저항"이 생기기 때문입니다.

문제는 "옳은 의견"이 아니라 "함께 도달한 결론이 아니라는 것"입니다. 상대가 말할 틈을 주지 않거나, 다른 관점에 진지하게 귀 기울이지 않으면 사람들은 조용히 마음을 닫습니다. 반대 의견을 접고 포기해버리고, 그 에너지는 나중에 실행 단계의 미묘한 비협조로 돌아옵니다.

진짜 시니어는 '내가 맞는지'보다 '우리가 같은 문제를 보고 있는지'를 먼저 확인합니다. 문제 정의에 시간을 쓰고, 다른 사람이 말할 수 있는 공간을 열고, 본인의 확신조차 의심해 봅니다.

유명한 말처럼 "강한 의견을 갖되, 그것이 틀릴 수 있음을 항상 열어둔 상태"로 움직이는 태도가 중요합니다. 정답을 맞히는 사람보다, 사람을 설득하고 끌어안는 사람이 결국 더 큰 일을 맡게 됩니다.

완벽주의보다 실행: 일단 만들고, 그다음에 다듬자

많은 팀이 "완벽한 설계"를 찾아 헤매느라 몇 주씩 토론만 하곤 합니다. 아키텍처 다이어그램은 아주 아름다운데, 실제로 돌아가는 코드는 없는 상태로 말이죠.

하지만 현실에서 좋은 해법은 대개 책상이 아니라 사용자 앞에서 나옵니다. 엉성하더라도 프로토타입을 빨리 만들어 실제로 돌려보는 순간, 그동안 상상 속에서만 논의하던 문제들이 눈앞에서 드러납니다.

조금 부끄러운 MVP를 출시해 피드백을 받아보는 일, 러프한 설계 문서를 먼저 써보고 비판을 받는 일, 일단 동작하는 버전을 만들어 개선해 나가는 일. 이 모든 것이 "생각만 많이 하는 팀"과 "실제로 결과를 내는 팀"을 가르는 지점입니다.

AI 도구가 발달한 지금은 초안을 만드는 일은 훨씬 쉬워졌습니다. "처음부터 완벽하게" 만들 이유는 더더욱 줄어들었죠.

정리하면 순서는 이렇습니다. 먼저 해본다. 그다음 제대로 한다. 그리고 나중에 더 잘한다. 모멘텀은 선명함을 만들어주지만, 분석 마비 상태에서는 아무것도 얻을 수 없습니다.

시니어일수록 '영리함'보다 '명료함'을 선택한다

개발을 시작하면 누구나 한 번쯤 "내가 얼마나 똑똑한지 보여주는 코드"를 쓰고 싶어집니다. 짧고, 트릭이 있고, 한 줄에 여러 일을 해내는 마법 같은 코드 말이죠.

하지만 소프트웨어는 혼자 오늘만 보는 예술품이 아니라, 여러 사람이 몇 년 동안 만지는 생물이기도 합니다. 이 환경에서 "영리해 보이는 코드"는 곧바로 "장애의 씨앗"이 됩니다.

당신의 코드는, 언젠가 새벽 2시에 장애를 처리해야 하는 누군가에게 쓰는 메모라고 생각하는 게 좋습니다. 그 사람이 처음 보는 코드여도 5분 안에 이해할 수 있어야 진짜 배려입니다.

그래서 가장 존경받는 시니어일수록 한 가지를 반복해서 선택합니다. 보는 사람이 바로 이해하는 단순한 코드. "이걸 쓴 사람이 정말 잘하는 사람 같다"는 인상을 주기보다는, "누가 썼는지 모르겠지만 유지보수하기 편하다"는 시스템을 남기려 합니다.

명료함은 스타일이 아니라 리스크 관리입니다.

새로운 기술은 빚이다: 어디에 써야 덜 아플까

새 라이브러리, 새로운 언어, 멋진 아키텍처… 이 모든 건 처음엔 "멋진 장난감" 같지만, 시간이 지날수록 유지보수 비용이라는 이름의 청구서를 보냅니다.

새 기술을 도입할 때마다, 팀은 다음과 같은 비용을 떠안게 됩니다. 장애 패턴이 낯설어 디버깅이 어려워지고, 신규 채용이 힘들어지고, 온보딩 시간도 길어집니다. 머릿속에 떠안아야 할 개념이 늘어나니 인지적 부담도 커집니다.

그래서 좋은 팀은 마치 "혁신 토큰"을 제한된 개수만 가진 것처럼 행동합니다. 정말 필요한 곳에만, 정말 의미 있는 차별화가 가능한 곳에만 새로움을 씁니다. 나머지는 최대한 "지루하지만 검증된 선택"을 고릅니다.

혁신을 하지 말자는 이야기가 아닙니다. "우리가 돈을 벌거나 임팩트를 내는 핵심 지점에만 혁신하고, 나머지는 되도록 평이하게 가자"는 것입니다. 운영하기 힘든 동물원을 꾸미는 대신, 관리 가능한 몇 가지 도구로 오래 가는 편이 대부분의 조직에 더 이롭습니다.

코드는 당신을 대신해 말하지 않는다

초년 시절에는 이렇게 믿기 쉽습니다. "좋은 코드, 좋은 결과물만 내면 언젠가 알아봐 주겠지."

하지만 현실의 큰 조직은 그렇게 움직이지 않습니다. 승진, 기회, 중요한 프로젝트 배정은 대부분 당신이 없는 자리에서, 당신이 쓰지 않은 요약본을 통해 결정됩니다.

그때 중요한 건 저장소 속 코드가 아니라, 당신의 인풋과 임팩트를 또렷하게 설명해줄 수 있는 사람들입니다. 매니저, 동료, 협업 팀, 그리고 함께 일해본 리더들.

그래서 '셀프 PR'이라는 단어가 불편하더라도, 최소한 이런 일은 해야 합니다. 내가 어떤 문제를 풀었고, 그게 비즈니스나 사용자에 어떤 차이를 만들었는지 명확한 문장으로 남기는 것. 주변 사람들도 그 이야기를 쉽게 가져다 쓸 수 있도록 정리해 두는 것.

이건 단순한 자기 과시가 아니라, 조직 속에서 자신의 가치를 읽을 수 있게 만드는 작업입니다. 심지어 본인에게도 도움이 됩니다. "나는 요즘 무엇으로 가치 전달을 하고 있지?"를 객관적으로 돌아볼 수 있으니까요.

가장 좋은 코드는, 처음부터 쓰지 않아도 되는 코드다

새 기능을 설계할 때, 많은 엔지니어가 곧장 "이걸 어떻게 구현하지?"로 달려갑니다. 하지만 정말 시니어다운 질문은 조금 다릅니다.

"이걸 아예 안 만들면 어떤 일이 생기지?"

생각보다 자주, 답은 "딱히 나쁜 일은 안 생긴다"입니다. 그렇다면 그게 바로 솔루션일 수도 있습니다.

코드를 추가하는 순간, 당신은 그걸 영원히 관리할 책임을 떠안게 됩니다. 버그, 보안 업데이트, 리팩토링, 문서화, 새 사람에게 설명하는 시간까지 모두 포함해서 말이죠.

그래서 좋은 엔지니어링 문화는 삭제와 비구현도 가치 있는 선택으로 인정합니다. "이거 굳이 안 만들어도 됩니다"라는 말을 할 수 있는 팀이, 장기적으로 건강한 팀입니다.

우리는 코드 작성에 너무 능숙해진 나머지, "정말 필요한가?"라는 질문을 놓치기 쉽다는 걸 잊지 말아야 합니다.

커다란 시스템에서는 버그조차 누군가의 의존성이 된다

사용자가 많아지면 이상한 일이 벌어집니다. 명시적으로 문서화하지도 않은 동작, 심지어 버그마저도 누군가의 자동화 스크립트나 워크플로우에 녹아들어 버립니다.

이 말은 곧, "우리 원래 의도는 이런 API였어"라고 말해도 소용없는 순간이 온다는 뜻입니다. 실제 동작이 이미 '사실상의 규격'이 되어버리기 때문입니다.

그래서 규모가 있는 제품에서 호환성 유지와 폐기 계획은 그 자체로 하나의 "제품"입니다. 단순히 "예전 버전은 곧 삭제합니다" 공지 하나 띄우는 수준으로 끝날 수 없습니다.

시간을 충분히 주고, 마이그레이션 도구나 가이드를 제공하고, 실제 사용자 입장에서 불편함을 최소화하도록 설계해야 합니다.

화려한 신규 기능이 아니라 "구버전 관리"에 시간을 쓰는 일이 별로 멋져 보이지 않을 수 있습니다. 하지만 이걸 잘하는 팀이 결국 신뢰를 얻습니다. 대규모 제품일수록, 실제로 하는 일의 상당 부분은 "디자인"이 아니라 "은퇴 설계"에 가깝다는 점을 인정해야 합니다.

팀이 느린 이유는 보통 '정렬'이 안 됐기 때문이다

프로젝트가 자꾸 늘어지고, 끝이 안 보일 때 흔히 떠올리는 가설은 이렇습니다. "사람이 부족해서 그래", "실력이 부족해서 그래", "기술 스택이 구려서 그래".

물론 그럴 수도 있지만, 큰 조직에서는 다른 원인이 더 흔합니다. 바로 정렬 실패입니다.

각 팀이 서로 다른 가정을 가지고 움직이거나, 우선순위에 대한 공감대 없이 각자 중요한 일을 하고 있다고 믿는 상태가 되면, 겉으로는 다들 열심히 일하는데 결과는 잘 안 나옵니다.

큰 회사에서 진짜 병목은 "코드를 더 빨리 치는 능력"이 아니라, "어디를 향해 달려야 하는지 모두가 같은 그림을 보는 것"에 있습니다.

그래서 시니어가 될수록 직접 구현하는 시간을 줄이고, 문제 정의, 인터페이스 조율, 목표와 우선순위 명확화에 더 많은 시간을 씁니다. 이건 게으름이 아니라, 병목 지점을 알고 있는 사람의 움직임에 가깝습니다.

통제할 수 없는 것에 에너지 낭비하지 않는 연습

큰 회사일수록 내 힘으로 바꾸기 힘든 요소가 늘어납니다. 조직 개편, 경영진 결정, 시장 변화, 제품 전략 변경 같은 것들이 그렇습니다.

여기에 마음을 빼앗기면 금방 번아웃으로 이어집니다. 불만과 걱정은 많은데, 정작 내가 할 수 있는 행동은 없기 때문입니다.

오랫동안 건강하게 버티는 사람들은 "영향력의 반경"을 구분하는 데 능숙합니다. 내가 관여할 수 없는 일은 정보 수준에서만 인지하고 내려놓습니다. 대신 내가 바꿀 수 있는 것들 — 내 일의 퀄리티, 협업 방식, 학습, 대응 방식 — 에 에너지를 집중합니다.

이것은 무기력이 아니라 전략입니다. 어차피 시간과 체력은 한정되어 있으니까요. 바꿀 수 없는 것에 소모되는 에너지는, 바꿀 수 있는 것을 바꾸는 데 써야 합니다.

추상화는 복잡성을 없애지 않는다, 그날을 미룰 뿐이다

새로운 추상화 계층은 편리합니다. 복잡한 디테일을 가려주고, 더 높은 수준의 개념으로 생각하게 해주니까요.

하지만 어떤 추상화도 완벽히 새지 않는 경우는 없습니다. 언젠가는 그 아래에서 무슨 일이 벌어지는지 직접 들여다봐야 할 날이 찾아옵니다. 보통 그날은 심야 장애나 생산 이슈와 함께 찾아오곤 합니다.

그래서 시니어 엔지니어들은 스택이 높아질수록 오히려 아래 층에 대한 이해를 계속 유지하려고 노력합니다. 낡은 기술에 대한 향수가 아니라, 위급할 때 무엇을 기대할 수 있고 무엇이 깨질 수 있는지 감을 잃지 않기 위해서입니다.

프레임워크와 클라우드 서비스, AI 도구는 마음껏 사용하되, "이게 실패하면 무슨 일이 벌어지는지"에 대한 간단한 모델 정도는 머릿속에 담아두는 습관이 도움이 됩니다.

글 쓰기와 설명하기는 최고의 성장 치트키다

어떤 개념을 "안다"고 느끼다가도, 막상 다른 사람에게 설명하려고 하면 말이 막힐 때가 있습니다. 이 지점이 바로 진짜 학습이 시작되는 지점입니다.

문서, 설계서, 코드 리뷰 코멘트, 팀 발표, 심지어 AI에게 설명해 보는 것까지. 이 모든 행위는 내 머릿속 생각을 외부로 꺼내 구조화하는 과정입니다. 그 과정에서 허점과 모순, 빈 구멍이 자연스럽게 드러납니다.

그래서 지식을 공유하는 행위는, 사실 꽤 이기적인 학습 방법입니다. 설명을 시도하다가 막히는 부분이 곧 내가 더 공부해야 할 부분이기 때문입니다.

"말 잘하는 사람"이 되려고 애쓰기보다, "내가 정말 이해했는지 점검하는 도구로 설명하기를 활용한다"는 관점으로 접근하면 부담도 줄어듭니다. 가르치는 척하면서, 사실은 내 사고 모델을 디버깅하고 있는 셈입니다.

보이지 않는 일은 경력에 도움이 되지만, 그대로 두면 위험하다

팀의 숨은 영웅을 떠올려보면 이런 사람이 떠오르곤 합니다. 문서 잘 쓰고, 신입 온보딩 도와주고, 회의 조율하고, 프로세스를 정리하고, 팀 사이를 중재해 주는 사람.

이런 일은 프로젝트의 성공에 매우 중요하지만, 눈에 잘 띄지 않습니다. 그리고 더 큰 문제는, 이런 일을 무의식적으로 계속 맡다 보면 본인의 기술 성장이나 커리어 방향이 희생되기 쉽다는 점입니다.

그래서 이런 종류의 일을 할 때는 전략이 필요합니다. 시간을 정해두고, 가능한 한 반복 가능한 형태(템플릿, 자동화, 가이드)로 남기고, "나의 기여"로 공식적으로 기록되게 만들어야 합니다.

"다 내가 하면 편하니까"라는 마음으로 계속 떠안다 보면, 나중에는 팀도, 조직도, 나도 모두 손해보는 방향으로 굳어질 수 있습니다. 가치 있는 일이지만, 의식적으로 경계를 정해야 하는 종류의 일입니다.

질문할 용기와 "모른다"는 말이 만드는 안전한 팀

시니어가 되면 모르는 티를 내기 싫어질 때가 많습니다. "이 정도는 알고 있어야 하는 거 아닌가?"라는 압박도 느껴지고요.

하지만 정말 건강한 팀을 만드는 리더들은 의외로 이런 말을 자주 합니다. "이건 잘 모르겠다", "다시 한 번만 설명해 줄 수 있니?", "이 부분은 헷갈린다".

리더가 모르는 걸 인정하는 순간, 팀 전체에 묵시적인 허가가 내려갑니다. "우리 팀에서는 모른다고 말해도 괜찮다." 이 안전감이 쌓이면, 작은 의문들이 회의실 안에서 처리되고, 큰 사고로 커지기 전에 경고 신호들이 수면 위로 올라옵니다.

반대로 누구도 모른다고 말하지 못하는 문화에서는, 문제가 있어도 모두들 "어쩌겠어"라는 분위기로 넘어가 버리고, 결국 한 번에 크게 터지는 경우가 많습니다.

모른다는 말은 약점이 아니라, 학습과 개선이 일어날 공간입니다.

네트워크는 모든 회사보다 오래간다

초기에 경력만 쌓느라 인간관계를 소홀히 하는 경우가 많습니다. "일만 잘하면 되지"라는 생각도 들고, 네트워킹이 어색하게 느껴지기도 하고요.

하지만 시간이 지나면, 사람들은 한 회사를 오래 다니기보다 여러 회사를 옮기거나, 창업을 하거나, 전혀 다른 역할로 이동하기 시작합니다. 이때 진짜 힘을 발휘하는 게 바로 "함께 일해 본 사람들과의 신뢰"입니다.

새로운 기회 소식을 가장 먼저 듣고, 서로를 추천해주고, 어려운 문제를 풀어본 동료와 다시 한 번 팀을 꾸릴 수 있는 것. 이 모든 건 그동안 쌓아둔 관계에서 나옵니다.

네트워킹을 "명함 돌리기"나 "자기 홍보" 정도로만 생각하면 피곤해지기 쉽습니다. 대신 "함께 일해본 사람들과 오래 가는 관계를 유지한다"는 관점으로 접근하는 게 훨씬 자연스럽습니다. 호기심과 진심을 바탕으로 연결을 유지한 사람들은, 시간이 지날수록 복리가 붙습니다.

성능, 효율, 결과는 '일을 더하는 것'이 아니라 '빼는 것'에서 온다

시스템이 느려지면 본능적으로 "뭔가를 더 붙이려는" 반응이 나옵니다. 캐시를 더 얹고, 더 똑똑한 알고리즘을 도입하고, 병렬화를 시도하죠.

물론 이런 접근이 필요한 경우도 있지만, 실제 현업에서 가장 큰 성능 개선은 종종 다른 질문에서 나옵니다.

"이 계산 자체가 정말 필요한가?"

돌려보면 아무 의미 없는 작업이 포함된 경우가 생각보다 많습니다. 로그를 허무하게 많이 남기거나, 사용되지 않는 데이터를 계속 가공하거나, 옛날 요구사항을 위해 도입한 흐름이 그대로 남아 있는 경우처럼요.

존재하지 않는 연산을 최적화할 필요는 없습니다. 가장 빠른 코드는 애초에 실행되지 않는 코드입니다. 시스템을 튜닝할 때, "빼는 것"부터 점검해야 하는 이유가 여기 있습니다.

프로세스는 책임 추적이 아니라 불확실성 줄이기 위해 존재한다

문서, 승인 절차, 리뷰, 체크리스트… 이 모든 프로세스는 잘 설계되면 일을 쉽게 만들지만, 잘못 설계되면 사람들의 시간을 잠식하는 서류 작업으로 변합니다.

좋은 프로세스는 다음 두 가지 중 하나를 확실히 합니다. 불확실성을 줄이거나, 실패 비용을 낮추거나.

그런 목적 없이 "혹시 문제가 생기면 책임을 묻기 위한 증거" 정도로 굴러가기 시작하면, 현장은 금방 피로해지고, 사람들은 문서를 위해 일하는 느낌을 받게 됩니다.

만약 팀에서 사용하는 프로세스에 대해 "이게 우리에게 어떤 리스크를 줄여주지?"라고 물었을 때 명확한 답이 나오지 않는다면, 그건 재검토 대상일 가능성이 큽니다.

사람들이 실제 일보다 문서 쓰는 시간에 더 많은 에너지를 쓰고 있다면, 이미 빨간불이 켜진 상태라고 봐도 무방합니다.

돈보다 시간이 더 중요해지는 시점이 온다

커리어 초반에는 시간과 에너지를 거의 전부 "성장"과 "연봉 상승"에 투자하게 됩니다. 이건 어느 정도 자연스러운 흐름입니다.

하지만 어느 순간부터 계산이 바뀝니다. 더 이상 돈만이 유일한 목표가 아니게 되고, 건강, 관계, 개인적인 프로젝트, 여유, 자기만의 삶의 속도 같은 것들이 점점 더 중요해집니다.

그럼에도 불구하고 많은 시니어들이 다음 레벨 승진, 몇 퍼센트의 보상 인상에 모든 시간을 갈아 넣다가 지치기도 합니다. 운 좋게 목표를 달성하더라도, "이게 정말 내가 원하던 거였나?"라는 질문이 남습니다.

이건 "열심히 일하지 마라"는 메시지가 아닙니다. 다만, 무엇을 위해 무엇을 포기하는지 의식적으로 결정하자는 이야기입니다. 시간은 돈과 달리 다시 채울 수 없는 자원이기 때문입니다.

커리어는 복리로 쌓인다, 인생 역전을 노리는 복권이 아니다

전문성이란 하루아침에 생기지 않습니다. 약간 어려운 문제에 반복해서 도전하고, 실패를 복기하고, 다음에는 조금 더 잘해보고… 이런 사이클을 몇 년이고 돌려야 비로소 "감각"이 생깁니다.

그래서 중요한 건 "얼마나 빨리 성장하느냐"보다 "얼마나 꾸준히, 의도적으로 성장하느냐"입니다.

글을 쓰는 이유도 단순히 조회수를 위해서가 아니라 생각을 정리하고, 다시 써먹을 수 있는 지식을 축적하기 위해서일 때 복리가 붙습니다. 재사용 가능한 코드와 도구를 쌓는 것도 마찬가지입니다. 실패에서 얻은 교훈을 체계적으로 기록해두면, 다음 선택의 질이 달라집니다.

커리어를 한 방에 뒤집을 "기회"를 찾기보다, 매일 조금씩 복리로 쌓이는 선택을 하는 사람들은 언젠가 남들이 보기엔 "갑자기 잘 나가는 사람"처럼 보이기도 합니다. 실제로는 그저 오래, 꾸준히, 방향을 잘 잡고 있었을 뿐인데 말이죠.

시사점: 좋은 엔지니어는 결국 '사람'과 '시간'을 의식한다

구글에서 14년 동안 얻은 21가지 교훈은 개별적으로 보면 다양한 이야기처럼 보이지만, 몇 가지 공통된 축으로 정리할 수 있습니다.

첫째, 일의 중심에는 언제나 사람이 있습니다. 사용자의 진짜 문제를 이해하는 집착, 함께 옳은 방향으로 가기 위한 정렬, 동료를 존중하는 커뮤니케이션, 심야 장애를 맞을 미래의 동료를 생각한 코드까지 모두 포함해서요.

둘째, 좋은 엔지니어는 "무엇을 하지 않을지"를 결정하는 능력이 뛰어납니다. 안 만들어도 되는 코드를 구분하고, 굳이 새 기술을 도입하지 않아도 되는 영역을 식별하며, 쓸데없는 작업을 과감히 삭제할 줄 압니다.

셋째, 커리어는 단기간의 스퍼트보다 장기적인 복리로 만들어진다는 사실입니다. 관계, 신뢰, 학습 습관, 글쓰기, 기록, 정직함 같은 것들은 당장 눈에 띄지 않지만 시간이 지날수록 엄청난 차이를 만들어 냅니다.

지금 어느 단계에 있든, 이 중에서 한두 가지라도 오늘부터 실험해 볼 수 있습니다. 조금 덜 화려하더라도 더 명료한 코드를 선택해 보는 것, "이 기능 정말 필요할까?"를 한 번 더 물어보는 것, 모르는 걸 모른다고 말해보는 것, 함께 고생했던 동료에게 오랜만에 연락을 해보는 것처럼요.

엔지니어링 커리어는 길고, 그 안에서 실수할 기회도, 다시 배울 기회도 충분합니다. 중요한 건 멈추지 않고 계속 배우고, 배운 것을 주변과 나누며, 조금씩 더 사람답게, 더 좋은 동료로 성장하려는 의지를 놓지 않는 일입니다.

출처 및 참고 : 21 Lessons from 14 Years at Google - by Addy Osmani