구글 클라우드 AI 디렉터인 애디 오스마니는 경험이 풍부한 소프트웨어 엔지니어이자 사상가로, 크롬에서 약 14년간 개발자 경험 책임자로 재직하며 DevTools, Lighthouse, Core Web Vitals 등의 프로젝트를 진행했습니다. 현재는 구글 딥마인드와 엔지니어링, 제품, 개발자 관계 팀 간의 협업을 조율하고 있습니다.
3일, 그는 자신의 개인 블로그에 구글에서의 오랜 경험과 전문적인 자질을 공유하는 심층적 인 글을 게시했습니다. 그는 의사소통, 기술 선택, 경력 계획과 관련하여 21가지 유용한 제안을 정리했는데, 아래에 그 내용을 요약했습니다.
약 14년 전 구글에 입사했을 때, 저는 완벽한 코드를 작성하는 것이 업무의 핵심이라고 생각했습니다. 하지만 제 생각은 부분적으로만 맞았습니다. 시간이 흐를수록 최고의 성과를 내는 엔지니어는 반드시 최고의 프로그래머가 아니라, 코드 외적인 모든 요소, 즉 인간관계, 사내 정치, 합의 도출, 그리고 불확실성을 헤쳐나가는 법을 배운 사람들이라는 것을 깨달았습니다.
이것들은 제가 좀 더 일찍 알았더라면 좋았을 교훈들입니다. 어떤 교훈들은 몇 달간의 좌절을 막아주었고, 어떤 교훈들은 진정으로 이해하는 데 몇 년이 걸렸습니다. 이 교훈들은 특정 기술과는 아무런 관련이 없습니다. 기술은 너무 빨리 변하기 때문에 중요하지 않습니다. 이 교훈들은 여러 프로젝트와 팀에서 반복적으로 나타나는 패턴에 관한 것입니다.
제가 이 글을 공유하는 이유는, 후배들을 기꺼이 멘토링해 주시는 엔지니어분들 덕분에 큰 도움을 받았기 때문입니다. 이는 그분들께 드리는 작은 감사의 표시입니다.
1. 최고의 엔지니어들은 사용자 문제 해결에 몰두합니다.
어떤 기술에 매료되어 그 기술의 활용법을 찾아보는 것은 매우 매력적인 일입니다. 저도 그랬고, 누구나 그럴 겁니다. 하지만 가장 큰 가치를 창출하는 엔지니어들은 "정반대"로 일합니다. 사용자 문제를 깊이 이해하는 데 몰두하고, 그 이해에서 자연스럽게 해결책이 나오도록 하는 것이죠.
사용자 중심적 사고방식이란 고객 서비스 티켓을 분석하고, 사용자와 대화하고, 그들이 겪는 운영상의 어려움을 관찰하며, 문제의 핵심에 도달할 때까지 끊임없이 "왜?"라는 질문을 던지는 것을 의미합니다. 문제를 진정으로 이해하는 엔지니어는 우아한 해결책이 예상보다 훨씬 간단하다는 것을 발견하는 경우가 많습니다. 반대로 해결책만 생각하는 엔지니어는 자신의 해결책을 합리화하기 위해 불필요한 복잡성을 추가하는 경향이 있습니다.
2. "자신이 옳다는 것을 증명하는 것"은 무의미합니다. 중요한 것은 올바른 목표를 함께 달성하는 것입니다.
기술적인 논쟁에서 모두 이길 수도 있지만, 프로젝트 전체를 망칠 수도 있습니다. 뛰어난 엔지니어들이 항상 자신이 가장 똑똑한 사람이 되려고 애쓰다 보니 마음속에 불만을 쌓아가는 모습을 많이 봤습니다. 이러한 불만은 나중에 "원인 불명의 실행 문제"나 "설명할 수 없는 저항"으로 나타납니다.
실력은 '옳다'는 데 있는 것이 아니라, 쟁점에 대한 의견을 일치시키기 위해 토론에 참여하고, 다른 사람들을 위한 공간을 마련하며, 자신의 확신에 대해 회의적인 태도를 유지하는 데 있습니다. 확고한 의견과 열린 마음 은 신념이 부족해서가 아니라, 불확실한 상황에서 내리는 결정이 자신의 자존심에 좌우되어서는 안 된다는 것을 의미합니다.
3. 행동 지향적. 바로 서비스를 시작하세요! 깨진 페이지는 고칠 수 있지만, 빈 페이지는 고칠 수 없습니다.
완벽을 추구하다 보면 오히려 아무것도 하지 못하게 될 수 있습니다. 엔지니어들이 실제로 만들어보지도 않은 것에 대한 이상적인 아키텍처를 놓고 몇 주씩 토론하는 모습을 본 적이 있습니다. 완벽한 해결책은 순수한 생각에서 나오는 경우가 드물고, 현실과의 충돌에서 비롯됩니다. 인공지능은 이러한 점에서 여러모로 도움이 될 수 있습니다.
먼저 시도하고, 제대로 하고, 마지막으로 더 잘 하세요. 사용자에게 조잡한 프로토타입을 보여주세요. 디자인 문서의 초안을 엉망으로 작성하세요. 약간 민망하더라도 MVP를 출시하세요. 한 달 동안 이론적인 논쟁을 하는 것보다 일주일 동안 실제 피드백을 받는 것이 훨씬 더 많은 것을 배울 수 있습니다. 추진력은 명확성을 가져다주지만, 분석에만 매몰되면 아무것도 얻지 못합니다.
4. 경험은 명확성과 책임감 있는 업무 처리 능력에 반영됩니다.
엔지니어들 사이에서 "똑똑한" 코드를 작성하려는 본능은 거의 보편적입니다. 그것은 자신의 능력을 증명하는 것처럼 느껴지기 때문입니다. 하지만 소프트웨어 엔지니어링은 "시간"과 "다른 프로그래머들"이 만들어내는 화학 반응과 같습니다. 이러한 환경에서 명확성은 스타일 선호도가 아니라 운영상의 리스크 줄이는 방법입니다 .
당신이 작성하는 코드는 새벽 2시에 버그를 수정해야 할지도 모르는 낯선 사람들을 위해 작성된 전략 메모와 같습니다. 코드의 우아함보다 그들이 이해하기 쉬운 코드를 우선시하세요. 제가 가장 존경하는 선임 엔지니어들은 언제나 "기발함"보다는 "명확성"을 택했습니다.
5. "새로움"은 유지 관리, 채용 및 인지 부하로부터 빌린 고금리 대출과 같습니다.
여러분의 기술 선택을 제한된 예산을 가진 "혁신 토큰" 회사라고 생각해 보세요. 진정으로 비표준적인 기술을 도입할 때마다 토큰 하나를 사용하세요. 너무 많이 사용하면 안 됩니다. 핵심은 "절대 혁신하지 말라"는 것이 아니라 " 독특한 보상을 받을 수 있는 경우에만 혁신하라 "는 것입니다.
그 외의 모든 것은 "지루하다"고 가정해야 합니다. 왜냐하면 지루함은 실패 원인이 이미 알려져 있음을 의미하기 때문입니다. "업무에 가장 적합한 도구"는 종종 "여러 업무에서 최고의 성능을 발휘하는 도구"입니다. 왜냐하면 온갖 종류의 도구를 한꺼번에 관리하는 것은 엄청난 부담이 될 것이기 때문입니다.
6. 코드가 당신을 대신해서 말해주지는 않습니다. 사람들이 대신 말해줄 것입니다.
경력 초반에는 뛰어난 업무 성과가 그 자체로 모든 것을 말해줄 거라고 생각했습니다. 하지만 착각이었죠. 코드는 저장소에 조용히 남아 있을 뿐입니다. 중요한 것은 상사가 회의에서 나를 언급하는지, 동료들이 나를 프로젝트에 추천하는지 여부입니다.
대규모 조직에서는 초대받지 않은 회의에서, 단 5분 안에 12가지 우선순위를 처리해야 하는 사람들이, 당신이 작성하지도 않은 요약 자료를 바탕으로 결정을 내립니다. 당신이 없을 때 아무도 당신의 영향력을 제대로 설명할 수 없다면, 당신의 영향력은 미미한 것입니다. 이는 단순히 자기 홍보에 관한 것이 아니라, 당신 자신을 포함한 모든 사람이 가치 사슬을 명확하게 볼 수 있도록 하는 것에 관한 것 입니다.
7. 최고의 코드는 당신이 절대 작성하지 않는 코드 한 줄입니다.
엔지니어링 문화는 창조를 중시합니다. 코드를 삭제한다고 해서 승진하는 사람은 아무도 없습니다. 삭제가 오히려 시스템 최적화에 더 효과적인 경우가 많은데도 말이죠. 작성하지 않은 코드 한 줄 한 줄은 디버깅, 유지보수, 해석할 필요가 없는 코드이기 때문입니다.
무언가를 만들기 전에, " 만약 우리가 이것을 전혀 하지 않는다면 어떻게 될까? "라는 질문을 스스로에게 철저히 던져보세요. 때로는 "아무런 문제도 없을 것이다"라는 답이 나올 수 있고, 그것이 바로 해결책이 될 수 있습니다. 문제는 엔지니어들이 코드를 작성할 줄 모르거나 AI를 활용해 코드를 작성할 줄 모르는 것이 아니라, 우리가 코드를 작성하는 데 너무 능숙해서 "과연 코드를 작성해야 할까?"라는 질문을 잊어버린다는 것입니다.
8. 규모가 충분히 커지면 버그조차도 사용자를 갖게 될 것입니다.
사용자가 충분히 많아지면, 애초에 약속했던 것과는 상관없이 관찰 가능한 모든 동작이 의존성이 됩니다(히람의 법칙). 누군가 당신의 API를 스크래핑하고, 당신의 특이한 점들을 자동화하고, 버그를 캐싱해 놓는 것입니다.
이는 전문가 수준의 통찰력으로 이어집니다. 호환성 작업을 "유지보수"로, 새로운 기능 개발을 "진정한 작업"으로 취급해서는 안 됩니다. 호환성 자체가 제품의 핵심입니다. 사용 중단 솔루션을 설계할 때는 시간, 도구, 그리고 공감을 바탕으로 마이그레이션 프로세스처럼 접근해야 합니다. 대부분의 "API 설계"는 사실상 "API 폐기"입니다.
9. 대부분의 "느린" 팀은 사실 "집중력이 부족한" 팀입니다.
프로젝트가 지연될 때, 사람들은 본능적으로 실행상의 문제, 즉 인력 부족이나 잘못된 기술 선택을 탓합니다. 하지만 대개 이러한 것들이 핵심적인 원인은 아닙니다. 대기업에서는 팀이 동시에 운영되는 단위이지만, 팀 수가 많아질수록 조정 비용도 기하급수적으로 증가합니다. 대부분의 프로젝트 지연은 실제로는 팀 간의 조율 실패 에서 비롯됩니다. 사람들이 잘못된 것을 만들거나, 올바른 것을 호환되지 않는 방식으로 만들고 있는 것입니다. 숙련된 엔지니어들은 "코드를 더 빨리 작성하는 것"보다 방향, 인터페이스, 우선순위를 명확히 하는 데 더 많은 시간을 투자합니다. 왜냐하면 실제 병목 현상은 바로 그 부분에 있기 때문입니다.
10. 자신이 통제할 수 있는 것에 집중하고, 통제할 수 없는 것은 무시하세요.
대기업에서는 조직 개편, 경영진의 결정, 시장 변화, 제품 변경 등 통제할 수 없는 변수가 무수히 많습니다. 이러한 변수들에만 매달리는 것은 불안감만 가중시키고 결국 아무런 소용이 없습니다. 합리적이고 효율적인 엔지니어는 자신이 영향력을 행사할 수 있는 영역 에 집중합니다.
구조조정 자체는 통제할 수 없지만, 업무의 질, 반응, 그리고 배우는 내용은 통제할 수 있습니다. 불확실한 상황 대면 때는 문제를 세분화하고 구체적으로 실행 가능한 조치를 파악하십시오. 이는 수동적으로 상황을 받아들이는 것이 아니라 전략적으로 집중하는 것입니다. 바꿀 수 없는 것에 에너지를 쏟는 것은 바꿀 수 있는 것에 집중해야 할 에너지를 빼앗는 것과 같습니다.
11. 추상화는 복잡성을 없애는 것이 아니라, 단지 다른 곳으로 옮길 뿐이다.
모든 추상화는 일종의 도박입니다. 근본 원리를 이해하지 않아도 된다는 도박이죠. 때로는 성공할 수도 있지만, 추상화에는 항상 허점이 있습니다. 실패했을 때는 그 밑바닥에서 무슨 일이 일어나고 있는지 알아야 합니다. 시니어 엔지니어들은 기술 스택이 점점 더 높아지더라도 "하위 레벨"에 대해 계속 학습합니다. 이는 향수 때문이 아니라 추상화가 실패하는 순간들을 존중하기 때문입니다. 사용하는 툴체인을 활용하되, 그 툴체인의 근본적인 실패 원인을 머릿속에 그려보는 능력을 키우세요.
12. 강제로 글을 쓰게 하면 명확성이 생기고, 가르치는 것이 가장 빠른 학습 방법이다.
글쓰기는 생각을 강요합니다. 문서, 연설, 코드 검토 댓글, 심지어 AI와의 대화 등 어떤 방식으로든 다른 사람에게 개념을 설명할 때면, 제 이해에 부족한 부분이 있음을 발견하곤 합니다.
다른 사람들에게 내용을 명확하게 설명하는 것은 저에게도 더 명확하게 다가옵니다. 이는 단순히 지식을 아낌없이 나누는 것만이 아니라, 자기 주도적인 학습 기법 이기도 합니다. 무언가를 이해했다고 생각되면, 그것을 간단하게 설명해 보세요. 막히는 부분은 바로 이해가 얕은 부분입니다. 가르치는 것은 자신의 사고방식을 다듬고 오류를 수정하는 과정입니다.
13. 다른 일을 가능하게 하는 일은 매우 귀중하지만, 동시에 눈에 보이지 않기도 합니다.
문서 작성, 온보딩, 팀 간 협업, 프로세스 개선과 같은 "연결 작업"은 매우 중요합니다. 하지만 이러한 작업을 무의식적으로 하다 보면 기술적 성장을 저해하고 피로감을 느끼게 될 수 있습니다. 함정은 이러한 작업을 단순히 "도움"을 주는 것으로 여기기보다는 의식적이고, 구체적이며, 가시적인 기여 로 인식해야 한다는 것입니다. 시간 제한을 두고, 돌아가면서 작업을 수행하고, 문서, 템플릿, 자동화 도구와 같은 결과물을 만들어내세요.
그것은 성격적 특성이 아니라 영향력으로 보아야 합니다.
14. 모든 논쟁에서 이긴다면, 당신은 조용한 저항을 쌓아가고 있을지도 모릅니다.
저는 제 확신에 의문을 품는 법을 배웠습니다. 너무 쉽게 "이기는" 것처럼 느껴질 때는 대개 뭔가 잘못된 것입니다. 사람들이 논쟁을 멈추는 것은 당신이 그들을 설득해서가 아니라, 더 이상 노력하는 것을 포기했기 때문입니다. 그들은 회의에서가 아니라 실행에서 이러한 반대를 표출합니다. 진정한 합의에 도달하는 데는 훨씬 더 오랜 시간이 걸립니다.
상대방의 관점 진정으로 이해하고, 피드백을 수용하며, 때로는 자신의 생각을 기꺼이 바꿀 줄 알아야 합니다. 논쟁에서 이기는 단기적인 만족감은 진정으로 설득된 파트너와 함께 일하는 장기적인 가치보다 훨씬 떨어집니다.
15. 어떤 지표가 목표가 되면, 더 이상 좋은 지표가 아닙니다.
경영진에게 제시하는 모든 지표는 결국 "조작"될 것입니다. 이는 악의적인 의도가 아니라, 인간은 자신이 측정하는 것에 최적화하려는 경향이 있기 때문입니다(굿하드의 법칙). 코드 라인 수를 추적하면 실제보다 더 많은 라인 수가 제시될 것이고, 작업 속도를 추적하면 부풀려진 추정치가 나올 것입니다.
노련한 접근 방식: 각 지표 요청에 대해 속도 지표와 품질 또는 리스크 지표, 이렇게 두 가지 지표를 함께 제공하십시오. 임계값에 집착하기보다는 추세를 파악하는 데 집중하세요. 목표는 감시가 아니라 통찰력을 얻는 것입니다.
16. "모르겠다"고 인정하는 것이 아는 척하는 것보다 더 큰 안정감을 준다.
"모르겠습니다"라고 말하는 선임 엔지니어는 약점을 보이는 것이 아니라, 오히려 "모르도록 허용하는" 분위기를 조성하는 것입니다. 리더가 불확실성을 인정할 때, 그것은 팀원 모두가 안심하고 배울 수 있는 분위기를 조성합니다. 저는 선임 구성원이 절대 혼란스러워하지 않는 팀을 많이 봤는데, 이는 엄청난 악영향을 미칩니다. 아무도 질문하지 않고, 아무도 가정에 이의를 제기하지 않으며, 주니어 엔지니어들은 자신만 이해하지 못한다고 생각하며 침묵을 지킵니다. 호기심을 보여주세요. 그러면 진정으로 배우는 팀을 만들 수 있을 것입니다.
17. 당신의 인맥은 지금까지 해왔던 어떤 직장보다도 더 오래되었습니다.
경력 초기에 저는 업무에만 집중하고 네트워킹을 소홀히 했습니다. 돌이켜보면 그것은 큰 실수였습니다. 회사 안팎에서 관계 구축에 투자한 동료들은 수십 년 동안 엄청난 혜택을 누렸습니다. 그들은 기회를 먼저 접하고, 더 빠르게 인맥을 쌓고, 취업 추천을 받고, 오랜 신뢰를 쌓은 사람들과 함께 사업을 시작하기도 했습니다. 직장은 영원하지 않지만, 인맥은 영원합니다. 관계를 맺을 때는 거래적인 관점이 아닌 호기심과 관대함을 가져야 합니다.
18. 성능 향상의 대부분은 "똑똑한 알고리즘"이 아니라 "작업 제거"에서 비롯됩니다.
시스템 속도가 느려지면 캐시 계층, 병렬 처리, 더 똑똑한 알고리즘 등을 추가하려는 본능적인 반응이 나타납니다. 때로는 이것이 맞는 방법일 수도 있지만, 저는 " 우리가 불필요하게 계산하고 있는 것은 무엇인가? "라는 질문을 통해 성능 향상을 더 자주 목격했습니다. 불필요한 작업을 제거하는 것이 필요한 작업을 더 빠르게 처리하는 것보다 거의 항상 더 효과적입니다. 가장 빠른 코드는 아예 실행되지 않는 코드입니다.
19. 프로세스는 불확실성을 줄이기 위해 존재하는 것이지, 서류 기록을 만들기 위해 존재하는 것이 아닙니다.
최적의 프로세스는 협업을 용이하게 하고 실패로 인한 비용을 줄여줍니다. 최악의 프로세스는 "관료주의적 드라마"와 같습니다. 이러한 프로세스는 도움을 주기 위한 것이 아니라 문제가 발생했을 때 책임을 회피하기 위한 수단으로 존재합니다. 프로세스가 어떻게 리스크 줄이거나 명확성을 높이는지 설명할 수 없다면, 그것은 단지 부담일 뿐입니다. 사람들이 실제 업무를 수행하는 시간보다 문서화에 더 많은 시간을 소비한다면, 심각한 문제가 있는 것입니다.
20. 결국 시간은 돈보다 더 소중할 것입니다. 그러므로 그에 맞게 행동하십시오.
경력 초반에는 시간을 돈으로 바꾸는 것이 괜찮을 수 있습니다. 하지만 어느 시점이 되면 계산이 뒤바뀝니다. 시간은 재생 불가능한 자원이라는 것을 깨닫게 되는 것이죠. 저는 경력이 많은 엔지니어들이 다음 단계로 승진하거나 연봉을 몇 퍼센트라도 더 받으려고 애쓰다가 번아웃되는 경우를 많이 봤습니다. 어떤 사람들은 그 이유를 이해하지만, 대부분은 나중에 그 대가가 과연 가치가 있었는지 의문을 품습니다. 해답은 "열심히 일하지 마라"가 아니라 " 무엇을 희생하는지 알고, 의식적으로 희생하라 "입니다.
21. 지름길은 없지만, 복리 효과는 있습니다.
전문성은 의도적인 연습, 즉 현재 기술 수준을 약간 뛰어넘는 연습, 숙고, 반복, 그리고 수년간의 지속적인 노력을 통해 얻어집니다. 단축된 방법은 없습니다. 하지만 학습을 통해 단편적인 지식이 아닌 새로운 선택지를 만들어낼 때 전문성이 누적된다는 것이 핵심입니다. (명확성을 위해) 글을 쓰고, 재사용 가능한 프로토타입을 만들고, 힘들었던 경험에서 얻은 교훈들을 모아 사용 설명서를 작성하십시오. 자신의 경력을 "복권"이 아닌 "복리 이자"처럼 생각하는 엔지니어들은 훨씬 더 큰 성공을 거두는 경향이 있습니다.
마지막으로 한 가지 더 말씀드리겠습니다.
이 21가지 항목은 많아 보일 수 있지만, 핵심 아이디어는 사실 몇 가지에 불과합니다. 호기심을 유지하고, 겸손함을 잃지 않으며, 모든 일은 결국 사람에 관한 것임을 기억하세요 . 여기에는 여러분이 제품을 만드는 사용자뿐만 아니라 함께 제품을 만드는 팀원들도 포함됩니다.
엔지니어의 경력은 충분히 길기 때문에 수많은 실수를 저지르고도 성공할 수 있습니다. 제가 가장 존경하는 엔지니어는 실수를 전혀 하지 않는 사람이 아니라, 실수로부터 배우고, 발견한 것을 공유하며, 끈기 있게 노력하는 사람들입니다.
이 여정을 이제 막 시작하셨다면, 시간이 지날수록 더 나아질 것이라는 점을 기억하세요. 이미 이 분야에서 오랫동안 일해 오셨다면, 이 글에서 언급된 내용 중 일부는 공감이 가실 겁니다.
