구글에서 14년간 일하며 깨달은, 코드 그 자체를 넘어 사람·정렬·모호함을 다루는 법까지 포함한 21가지 교훈.
홈 GitHub 보도자료 약력 LinkedIn Twitter 뉴스레터 블로그
약 14년 전 구글에 입사했을 때, 저는 이 일이 훌륭한 코드를 작성하는 것에 달려 있다고 생각했습니다. 어느 정도는 맞았습니다. 하지만 오래 있을수록, 잘해나가는 엔지니어들은 반드시 최고의 프로그래머가 아니라는 걸 더 많이 깨달았습니다. 그들은 코드 주변의 모든 것을 다루는 법을 터득한 사람들이었습니다. 사람, 정치, 정렬(alignment), 모호함(ambiguity) 말이죠.
이 교훈들은 제가 더 일찍 알았더라면 좋았을 것들입니다. 어떤 것들은 몇 달 치의 좌절을 아껴줬을 겁니다. 또 어떤 것들은 완전히 이해하는 데 몇 년이 걸렸습니다. 어떤 것도 특정 기술에 관한 이야기는 아닙니다. 기술은 너무 빨리 바뀌어 중요하지 않거든요. 대신, 프로젝트가 바뀌고 팀이 바뀌어도 계속 반복해서 등장하는 패턴들에 관한 이야기입니다.
저는 저에게도 같은 방식으로 도움을 준 엔지니어들 덕분에 엄청난 혜택을 받았습니다. 이 글은 그 빚을 다음 사람에게 돌려주려는 제 시도라고 봐주시면 좋겠습니다.
어떤 기술에 빠져든 뒤, 그것을 적용할 곳을 찾아다니는 건 유혹적입니다. 저도 그랬고, 누구나 한 번쯤은 그렇습니다. 하지만 가장 큰 가치를 만드는 엔지니어는 거꾸로 접근합니다. 사용자의 문제를 깊이 이해하는 데 집착하고, 그 이해로부터 해결책이 자연스럽게 나오도록 둡니다.
사용자 집착은 지원 티켓을 들여다보고, 사용자와 대화하고, 사용자가 고군분투하는 모습을 관찰하며, ‘왜?’를 바닥이 드러날 때까지 계속 묻는 것을 뜻합니다. 문제를 진짜로 이해한 엔지니어는, 우아한 해법이 사람들이 예상했던 것보다 훨씬 단순하다는 사실을 종종 발견합니다.
반대로 해결책부터 시작하는 엔지니어는, 정당화를 찾기 위해 복잡성을 쌓아 올리는 경향이 있습니다.
기술적 논쟁을 매번 이기면서도 프로젝트는 망칠 수 있습니다. 저는 방 안에서 가장 똑똑한 사람으로 늘 ‘이기는’ 뛰어난 엔지니어들이 조용한 반감을 쌓아가는 모습을 봐왔습니다. 그 비용은 나중에 “이상한 실행 이슈”와 “묘한 저항”으로 드러납니다.
중요한 능력은 ‘내가 옳다’가 아닙니다. 문제에 대해 정렬하기 위해 토론에 들어가고, 다른 사람들을 위한 공간을 만들며, 자신의 확신을 스스로 의심하는 것입니다.
강한 의견, 그러나 약하게 고수하기(strong opinions, weakly held). 신념이 없어서가 아니라, 불확실성 아래에서 내려진 결정은 자아/정체성과 용접하듯 붙여두면 안 되기 때문입니다.
완벽을 추구하는 건 마비를 부릅니다. 저는 한 번도 만들어보지 않은 것의 ‘이상적인 아키텍처’를 두고 몇 주씩 토론하는 엔지니어들을 봐왔습니다. 완벽한 해법은 생각만으로는 거의 나오지 않습니다. 현실과의 접촉에서 나옵니다. AI는 이 부분에서 여러 면으로 도움을 줄 수 있습니다.
먼저 만들고, 그다음 제대로 만들고, 그다음 더 잘 만들어라. 투박한 프로토타입을 사용자 앞에 먼저 내놓으세요. 지저분한 첫 디자인 문서 초안을 작성하세요. 약간은 부끄러운 MVP를 출시하세요. 이론적 논쟁 한 달보다, 실제 피드백 1주일에서 더 많이 배웁니다.
모멘텀은 명확함을 만듭니다. 분석 마비는 아무것도 만들지 못합니다.
영리한 코드를 쓰고 싶은 본능은 거의 모든 엔지니어에게 있습니다. 그게 능력의 증거처럼 느껴지니까요.
하지만 소프트웨어 엔지니어링은 시간과 다른 프로그래머들이 더해졌을 때 벌어지는 일입니다. 그런 환경에서 명확함은 스타일 취향이 아니라 운영 리스크를 줄이는 방법입니다.
당신의 코드는 장애가 난 새벽 2시에 시스템을 유지보수해야 할 낯선 사람들에게 보내는 전략 메모입니다. 우아함이 아니라 이해 가능성을 최적화하세요. 제가 가장 존경하는 시니어 엔지니어들은 매번 영리함을 명확함으로 바꾸는 법을 배운 사람들입니다.
기술 선택을 ‘혁신 토큰(innovation token)’ 예산이 아주 작은 조직처럼 다루세요. 눈에 띄게 비표준적인 무언가를 도입할 때마다 토큰 하나를 쓰는 겁니다. 많이 쓸 여유는 없습니다.
핵심은 “절대 혁신하지 말라”가 아닙니다. “당신이 고유하게 돈을 받고 혁신해야 하는 곳에서만 혁신하라”입니다. 나머지는 지루한 것(boring)을 기본값으로 두어야 합니다. 지루한 것에는 알려진 실패 모드가 있으니까요.
“일에 가장 잘 맞는 도구”는 종종 “많은 일에 걸쳐 가장 덜 나쁜 도구”입니다. 동물원을 운영하는 것이 진짜 세금이 되기 때문이죠.
커리어 초기에 저는 훌륭한 결과물은 스스로 말한다고 믿었습니다. 틀렸습니다. 코드는 저장소에 조용히 앉아 있을 뿐입니다. 매니저가 회의에서 당신을 언급하느냐, 아니냐. 동료가 당신을 프로젝트에 추천하느냐, 아니면 다른 누군가를 추천하느냐.
큰 조직에서는 당신이 초대받지 않은 회의에서, 당신이 쓰지 않은 요약을 기반으로, 5분과 열두 가지 우선순위를 가진 사람들이 결정을 내립니다. 당신이 방에 없을 때도 누군가가 당신의 임팩트를 말로 설명할 수 없다면, 당신의 임팩트는 사실상 ‘있어도 그만’이 됩니다.
이건 단순한 자기 PR만의 이야기가 아닙니다. 가치 사슬을 모두가 읽을 수 있게 만드는 일입니다. 당신 자신을 포함해서요.
엔지니어링 문화는 ‘창조’를 축하합니다. 코드를 삭제해서 승진하는 사람은 없지만, 삭제가 추가보다 시스템을 더 많이 개선하는 경우가 많습니다. 쓰지 않은 코드 한 줄은 디버깅, 유지보수, 설명을 절대 하지 않아도 되는 한 줄입니다.
무언가를 만들기 전에 이 질문을 끝까지 밀어붙이세요. “그냥… 안 하면 어떻게 되지?” 때로 답은 “아무 일도 안 나빠진다”이고, 그게 곧 해법입니다.
문제는 엔지니어가 코드를 못 쓰거나 AI를 못 쓰는 게 아닙니다. 코드를 너무 잘 쓰다 보니, 애초에 써야 하는지 묻는 걸 잊는 데 있습니다.
사용자가 충분히 많아지면, 관측 가능한 모든 동작은 ‘의존성’이 됩니다. 당신이 약속했는지 여부와 무관하게요. 누군가는 당신의 API를 스크래핑하고, 당신의 ‘특이한 동작’을 자동화하며, 당신의 버그를 캐시합니다.
여기서 커리어 수준의 인사이트가 나옵니다. 호환성 작업을 “유지보수”로, 신규 기능을 “진짜 일”로 취급할 수 없습니다. 호환성이 곧 제품입니다.
디프리케이션(deprecation)을 마이그레이션으로 설계하세요. 시간, 도구, 공감이 필요합니다. 대부분의 “API 설계”는 사실 “API 은퇴”입니다.
프로젝트가 질질 끌리면 본능적으로 실행력을 탓합니다. 사람들이 충분히 열심히 일하지 않는다, 기술이 잘못됐다, 엔지니어가 부족하다. 하지만 대개 그 어느 것도 진짜 문제가 아닙니다.
큰 회사에서 팀은 동시성(concurrency)의 단위지만, 팀 수가 늘수록 조정 비용은 기하급수적으로 증가합니다. 대부분의 느림은 정렬 실패입니다. 사람들이 잘못된 것을 만들거나, 올바른 것을 서로 호환되지 않게 만들고 있는 거죠.
시니어 엔지니어는 “코드를 더 빨리 쓰는” 것보다 방향, 인터페이스, 우선순위를 명확히 하는 데 더 많은 시간을 씁니다. 진짜 병목이 거기에 있기 때문입니다.
큰 회사에는 당신이 통제할 수 없는 변수가 무수히 많습니다. 조직 개편, 경영진 결정, 시장 변화, 제품 피벗. 여기에 집착하면 권한 없는 불안만 커집니다.
정신을 지키며 효과적으로 일하는 엔지니어들은 자신이 영향력을 행사할 수 있는 범위에 집중합니다. 리오그(reorg)가 일어날지는 통제할 수 없지만, 일의 품질, 대응 방식, 배움은 통제할 수 있습니다. 불확실성 앞에서는 문제를 조각내고, 지금 당신이 취할 수 있는 구체적 행동을 식별하세요.
이건 수동적 체념이 아니라 전략적 집중입니다. 바꿀 수 없는 것에 쓰는 에너지는, 바꿀 수 있는 것에서 훔쳐온 에너지입니다.
모든 추상화는 “아래를 이해하지 않아도 될 것”이라는 내기입니다. 때로 그 내기는 이깁니다. 하지만 무언가는 항상 새고(leak), 그때가 오면 당신은 자신이 무엇 위에 서 있는지 알아야 합니다.
시니어 엔지니어는 스택이 높아져도 “더 로우 레벨”을 계속 배웁니다. 향수가 아니라, 추상화가 실패하고 새벽 3시에 혼자 시스템과 마주하는 순간에 대한 존중에서요. 스택을 활용하세요.
하지만 그 아래의 실패 모드에 대한 작동 모델(working model)은 유지하세요.
글쓰기는 명확함을 강제합니다. 문서, 발표, 코드 리뷰 코멘트, 심지어 AI와의 대화에서 다른 사람에게 개념을 설명할 때마다, 저는 제 이해의 빈틈을 발견합니다. 다른 사람에게 읽히게 만드는 행위는 제게도 더 잘 읽히게 만듭니다.
물론 가르친다고 해서 외과의사가 되는 법을 배울 수 있다는 뜻은 아니지만, 소프트웨어 엔지니어링 영역에서는 이 전제가 대체로 잘 맞습니다.
이건 지식을 아낌없이 나누라는 이야기만이 아닙니다. 이기적인 학습 해킹입니다. 뭔가를 이해한다고 생각되면, 단순하게 설명해보세요. 막히는 지점이 바로 이해가 얕은 곳입니다.
가르침은 내 정신 모델을 디버깅하는 일입니다.
글루 작업(glue work) — 문서화, 온보딩, 팀 간 조율, 프로세스 개선 — 은 필수입니다. 하지만 무의식적으로 맡다 보면 기술적 성장 경로를 막고 번아웃을 부를 수 있습니다. 함정은 이것을 ‘친절함’으로 처리하면서, 의도적이고 경계가 있으며 눈에 보이는 임팩트로 다루지 않는 것입니다.
시간을 박아두고(timebox) 순환시키며(rotate) 산출물로 남기세요: 문서, 템플릿, 자동화. 그리고 그것이 성격이 아니라 임팩트로 읽히게 만드세요.
값지지만 보이지 않는 조합은 커리어에 위험합니다.
저는 제 확신을 의심하는 법을 배웠습니다. 제가 너무 쉽게 “이길” 때는 대개 뭔가가 잘못되어 있습니다. 사람들이 설득돼서가 아니라, 싸우는 걸 포기해서 더 이상 반대하지 않는 경우가 많습니다. 그리고 그 불일치는 회의가 아니라 실행에서 드러납니다.
진짜 정렬은 더 오래 걸립니다. 다른 관점을 실제로 이해해야 하고, 피드백을 반영해야 하며, 때로는 공개적으로 마음을 바꿔야 합니다.
단기적으로 ‘내가 옳다’는 느낌은, 기꺼운 협력자들과 함께 무언가를 만들어내는 장기적 현실에 비하면 훨씬 덜 값집니다.
관리자에게 공개한 모든 지표는 결국 게임의 대상이 됩니다. 악의가 아니라, 인간은 측정되는 것을 최적화하기 때문입니다.
코드 라인 수를 추적하면 라인이 늘고, 벨로시티를 추적하면 추정치가 부풀어 오릅니다.
시니어의 움직임: 어떤 메트릭 요청에도 ‘쌍’으로 답하세요. 하나는 속도, 다른 하나는 품질 또는 리스크. 그리고 임계값을 숭배하지 말고 추세(trend)를 해석하자고 고집하세요. 목표는 감시가 아니라 인사이트입니다.
“모르겠습니다”라고 말하는 시니어 엔지니어는 약함을 드러내는 게 아닙니다. 허용(permisson)을 만들어내는 겁니다. 리더가 불확실성을 인정하면, 다른 사람도 그렇게 해도 안전하다는 신호가 됩니다. 반대로 모두가 이해하는 척하는 문화에서는 문제들이 숨겨지다가 폭발합니다.
가장 시니어가 절대 혼란을 인정하지 않는 팀도 봤고, 그 피해도 봤습니다. 질문이 나오지 않습니다. 가정이 도전받지 않습니다. 주니어는 모두가 이해한다고 생각해서 침묵합니다.
호기심을 모델링하면, 실제로 학습하는 팀을 얻게 됩니다.
커리어 초기에 저는 일에만 집중하고 네트워킹을 소홀히 했습니다. 돌이켜보면 실수였습니다. 회사 안팎에서 관계에 투자한 동료들은 수십 년에 걸쳐 이익을 얻었습니다.
그들은 기회를 더 먼저 들었고, 더 빠르게 다리를 놓았으며, 역할 추천을 받았고, 수년간 쌓은 신뢰를 바탕으로 공동 창업까지 했습니다.
직장은 영원하지 않지만 네트워크는 남습니다. 거래적 허슬이 아니라, 호기심과 관대함으로 접근하세요.
이직할 때가 오면, 문을 여는 것은 종종 관계입니다.
시스템이 느려지면 본능적으로 무언가를 추가하려 합니다. 캐싱 레이어, 병렬 처리, 더 똑똑한 알고리즘. 때로는 그게 맞습니다. 하지만 저는 “우리가 굳이 계산할 필요 없는 걸 무엇을 계산하고 있지?”를 물어서 얻은 성능 향상을 더 많이 봤습니다.
불필요한 일을 삭제하는 것은, 필요한 일을 더 빠르게 하는 것보다 거의 항상 더 큰 임팩트가 있습니다. 가장 빠른 코드는 실행되지 않는 코드입니다.
최적화하기 전에, 그 일이 애초에 존재해야 하는지부터 의심하세요.
좋은 프로세스는 조율을 쉽게 하고 실패를 더 싸게 만듭니다. 최악의 프로세스는 관료적 연극입니다. 도움을 주기 위해서가 아니라, 일이 잘못됐을 때 비난 대상을 정하기 위해 존재합니다.
어떤 프로세스가 리스크를 어떻게 줄이거나 명확함을 어떻게 높이는지 설명할 수 없다면, 그건 아마 오버헤드일 뿐입니다.
그리고 사람들이 일을 하는 시간보다 문서화에 더 많은 시간을 쓰고 있다면, 뭔가가 심각하게 잘못된 겁니다.
커리어 초반에는 시간을 돈과 바꾸게 됩니다. 괜찮습니다. 하지만 어느 순간 계산이 뒤집힙니다. 시간이야말로 재생 불가능한 자원이라는 걸 깨닫게 되죠.
저는 시니어 엔지니어들이 다음 승진 레벨을 좇으며 번아웃되는 모습을 봤습니다. 몇 퍼센트의 보상을 더 최적화하려고 말이죠. 어떤 사람들은 얻었습니다. 하지만 대부분은 나중에, 그게 자신이 포기한 것들만큼 가치가 있었는지 궁금해했습니다.
답은 “열심히 일하지 말라”가 아닙니다. “무엇을 거래하고 있는지 알고, 그 거래를 의도적으로 하라”입니다.
전문성은 의도적인 연습(deliberate practice)에서 나옵니다. 현재 능력보다 약간 더 어려운 것을 시도하고, 되돌아보고, 반복합니다. 수년 동안. 압축판은 없습니다.
하지만 희망적인 부분이 있습니다. 배움은 단순한 잡지식이 아니라 ‘새로운 선택지’를 만들 때 복리로 불어납니다. 참여(engagement)를 위해서가 아니라 명확함을 위해 글을 쓰세요. 재사용 가능한 프리미티브를 만드세요. 상처의 흔적(scar tissue)을 플레이북으로 모으세요.
커리어를 복리 이자처럼 대하는 엔지니어는, 복권처럼 대하는 엔지니어보다 대체로 훨씬 더 멀리 갑니다.
21가지 교훈은 많아 보이지만, 결국 몇 가지 핵심으로 압축됩니다. 호기심을 잃지 말 것, 겸손할 것, 그리고 일은 언제나 ‘사람’에 관한 것임을 기억할 것 — 당신이 만드는 대상인 사용자와, 함께 만드는 동료들 말입니다.
엔지니어로서의 커리어는 실수를 잔뜩 하고도 결국 앞서나갈 만큼 충분히 깁니다. 제가 가장 존경하는 엔지니어들은 모든 걸 맞춘 사람들이 아니라, 잘못된 것에서 배웠고, 발견한 것을 공유했으며, 계속 나타나 일을 해온 사람들입니다.
여정을 막 시작했다면, 시간이 지날수록 더 풍성해진다는 걸 알아두세요. 이미 깊이 들어와 있다면, 이 중 일부가 공감되길 바랍니다.
Addy Osmani는 Google에서 Chrome과 AI를 담당하는 소프트웨어 엔지니어입니다. 트윗 공유
더 보고 싶으신가요? 무료 뉴스레터를 구독하세요:
구독
