Google에서 14년간 얻은 21가지 교훈

(addyo.substack.com)

155P by neo 2달전 | ★ favorite | 댓글 5개

뛰어난 엔지니어는 최고의 프로그래머가 아니라 코드 주변의 사람, 정치, 조율, 모호성을 탐색하는 방법을 터득한 사람들임
기술보다는 프로젝트와 팀에서 반복적으로 나타나는 패턴에 초점을 맞춘 내용으로, 사용자 문제 해결, 팀 협업, 코드 품질, 경력 관리 등을 포괄함
명확성이 선임 엔지니어의 핵심 자질이며 영리함은 오버헤드일 뿐이라는 점과, 작성하지 않은 코드가 최고의 코드라는 역설적 통찰을 보여줌
대규모 조직에서는 정렬 실패가 속도 저하의 주요 원인이며, 측정 지표가 목표가 되면 왜곡된다는 조직 운영의 함정을 드러냄
장기적 관점에서 시간이 돈보다 가치 있는 자원이 되며, 네트워크는 각 직장보다 오래 지속되므로 의도적인 경력 설계가 필요함

1. 최고의 엔지니어는 사용자 문제 해결에 집착함

기술에 먼저 빠져 적용처를 찾는 것은 유혹적이지만, 가장 큰 가치를 창출하는 엔지니어는 역으로 작업함 - 사용자 문제를 깊이 이해하고 거기서 솔루션을 도출
사용자 집착이란 지원 티켓에 시간 투자, 사용자와 대화, 사용자의 어려움 관찰, 근본에 도달할 때까지 "왜"를 질문하는 것을 의미함
문제를 진정으로 이해하는 엔지니어는 종종 우아한 솔루션이 예상보다 단순함을 발견함
솔루션부터 시작하는 엔지니어는 정당화를 찾기 위해 복잡성을 구축하는 경향이 있음

2. 옳은 것은 쉽지만, 함께 옳음에 도달하는 것이 진짜 업무

모든 기술 논쟁에서 이기고도 프로젝트를 잃을 수 있으며, 항상 방에서 가장 똑똑한 사람이 되어 조용한 반감을 축적하는 뛰어난 엔지니어들을 목격함
비용은 나중에 "불가사의한 실행 문제"와 "이상한 저항"으로 나타남
핵심 기술은 옳은 것이 아니라 문제 정렬을 위해 토론에 참여하고, 타인을 위한 공간을 창출하며, 자신의 확신에 회의적 태도를 유지하는 것
강한 의견, 약한 집착 - 확신이 부족해서가 아니라, 불확실성 하의 결정을 정체성에 결합해서는 안 되기 때문

3. 행동 편향을 가지고 출시하라. 나쁜 페이지는 편집 가능하지만 빈 페이지는 불가능

완벽 추구는 마비를 초래하며, 한 번도 만들어보지 않은 것의 이상적 아키텍처를 몇 주간 논쟁하는 엔지니어들을 목격함
완벽한 솔루션은 사고만으로 나오지 않고 현실과의 접촉에서 등장하며, AI가 여러 방식으로 도움을 줄 수 있음
먼저 하고, 제대로 하고, 더 잘하는 순서로 진행 - 못생긴 프로토타입을 사용자 앞에 두고, 지저분한 디자인 문서 초안을 작성하고, 약간 부끄러운 MVP를 출시함
한 주의 실제 피드백에서 한 달의 이론적 논쟁보다 더 많이 학습하며, 추진력이 명확성을 만들고 분석 마비는 아무것도 만들지 못함

4. 명확성이 시니어의 징표이며, 영리함은 오버헤드

영리한 코드 작성 본능은 엔지니어에게 거의 보편적이며 역량 증명처럼 느껴짐
소프트웨어 엔지니어링은 시간과 다른 프로그래머를 추가할 때 발생하며, 그 환경에서 명확성은 스타일 선호가 아닌 운영 리스크 감소를 의미함
코드는 장애 중 새벽 2시에 유지보수할 낯선 사람들을 위한 전략 메모이므로, 우아함이 아닌 그들의 이해도를 최적화해야 함
가장 존경받는 선임 엔지니어들은 영리함을 명확성과 매번 교환하는 법을 학습함

5. 새로움은 장애, 채용, 인지 오버헤드로 갚는 빚

기술 선택을 작은 "혁신 토큰" 예산을 가진 조직처럼 다루고, 실질적으로 비표준적인 것을 채택할 때마다 하나씩 소비함 - 많이 감당할 수 없음
요점은 "절대 혁신하지 말라"가 아니라 "고유하게 혁신하도록 보상받는 곳에서만 혁신" 하는 것이며, 나머지는 지루함이 기본값이어야 함
지루함은 알려진 실패 모드를 가지고 있기 때문
"작업에 최고의 도구"는 종종 "많은 작업에 걸쳐 최소-최악의 도구" 를 의미함 - 동물원 운영이 실제 세금이 되기 때문

6. 코드는 당신을 옹호하지 않으며, 사람들이 옹호함

초기 경력에서 훌륭한 업무가 스스로 말할 것이라 믿었으나 이는 오류였으며, 코드는 저장소에 조용히 앉아있을 뿐
관리자가 회의에서 당신을 언급하거나 하지 않고, 동료가 프로젝트에 당신을 추천하거나 다른 사람을 추천함
대규모 조직에서는 초대받지 않은 회의에서, 직접 작성하지 않은 요약으로, 5분과 12개 우선순위를 가진 사람들이 결정을 내림
당신이 없는 방에서 아무도 당신의 영향을 표현할 수 없다면 그 영향은 사실상 선택 사항이며, 이는 자기 홍보가 아니라 가치 사슬을 자신을 포함한 모두에게 읽기 가능하게 만드는 것

7. 최고의 코드는 작성할 필요가 없었던 코드

엔지니어링 문화에서 창조를 축하하지만, 삭제가 추가보다 시스템을 더 개선하는 경우가 많은데도 코드 삭제로 승진하는 사람은 없음
작성하지 않은 모든 코드 라인은 디버깅, 유지보수, 설명할 필요가 없는 라인
구축 전 질문을 고갈시켜야 함: "그냥... 하지 않으면 어떻게 될까?" - 때때로 답이 "나쁜 일 없음"이면 그것이 솔루션
문제는 엔지니어가 코드를 작성하지 못하거나 AI로 작성하지 못하는 것이 아니라, 너무 잘 작성해서 작성해야 하는지를 묻는 것을 잊는 것

8. 규모에서는 버그조차 사용자를 보유함

충분한 사용자가 있으면 모든 관찰 가능한 동작이 의존성이 되며, 약속과 무관함 - 누군가는 API를 스크래핑하고, 특이점을 자동화하며, 버그를 캐싱함
이는 경력 수준의 통찰을 창출함: 호환성 작업을 "유지보수"로, 새 기능을 "실제 작업"으로 취급할 수 없으며, 호환성이 곧 제품
시간, 도구, 공감으로 지원 중단을 마이그레이션으로 설계해야 함
대부분의 "API 설계"는 실제로 "API 은퇴" 를 의미함

9. 대부분의 "느린" 팀은 실제로 정렬되지 않은 팀

프로젝트가 지연될 때 본능은 실행을 비난하는 것 - 사람들이 충분히 열심히 일하지 않음, 기술이 잘못됨, 엔지니어가 충분하지 않음 - 하지만 보통 이것이 실제 문제가 아님
대기업에서 팀은 동시성의 단위이지만, 팀이 곱해질수록 조정 비용은 기하급수적으로 증가함
대부분의 느림은 실제로 정렬 실패를 의미함 - 잘못된 것을 구축하거나, 올바른 것을 호환되지 않는 방식으로 구축함
선임 엔지니어는 "코드를 더 빨리 작성"보다 방향, 인터페이스, 우선순위 명확화에 더 많은 시간을 투자함 - 실제 병목이 거기 있기 때문

10. 통제 가능한 것에 집중하고, 불가능한 것은 무시하라

대기업에서는 수많은 변수가 통제 밖에 있음 - 조직 변경, 관리 결정, 시장 변화, 제품 전환 - 이것에 몰두하면 행위성 없는 불안을 창출함
제정신을 유지하고 효과적인 엔지니어는 영향력 범위에 집중함 - 재조직 발생 여부는 통제할 수 없지만, 업무 품질, 대응 방식, 학습 내용은 통제 가능함
불확실성에 직면하면 문제를 조각으로 나누고 자신에게 가능한 구체적 행동을 식별해야 함
이는 수동적 수용이 아니라 전략적 집중이며, 바꿀 수 없는 것에 쓰는 에너지는 바꿀 수 있는 것에서 훔쳐오는 에너지

11. 추상화는 복잡성을 제거하지 않으며, 당신이 온콜일 때로 이동시킴

모든 추상화는 밑에 무엇이 있는지 이해할 필요가 없을 것이라는 내기이며, 때때로 이 내기에 이김
하지만 무언가는 항상 누출되며, 누출될 때 자신이 무엇 위에 서 있는지 알아야 함
선임 엔지니어는 스택이 높아질수록 "하위 레벨" 것들을 계속 학습함 - 향수가 아니라, 추상화가 실패하고 새벽 3시에 시스템과 홀로 있는 순간에 대한 존중 때문
스택을 사용하되, 기본 실패 모드에 대한 작동 모델을 유지해야 함

12. 글쓰기는 명확성을 강제함. 무언가를 더 잘 학습하는 가장 빠른 방법은 가르치려 시도하는 것

글쓰기는 명확성을 강제하며, 개념을 다른 사람에게 설명할 때 - 문서, 발표, 코드 리뷰 코멘트, 심지어 AI와 채팅 - 자신의 이해에서 공백을 발견함
무언가를 다른 사람에게 읽기 가능하게 만드는 행위가 자신에게 더 읽기 가능하게 만듦
이는 외과의사가 되는 법을 가르쳐서 배운다는 의미는 아니지만, 전제는 소프트웨어 엔지니어링 영역에서 대체로 참
이는 지식을 나누는 관대함만이 아니라 이기적인 학습 해크(hack) 이기도 함 - 무언가를 이해한다고 생각하면 간단히 설명을 시도하고, 막히는 곳이 이해가 얕은 곳
가르치는 것은 자신의 정신 모델을 디버깅하는 것

13. 다른 업무를 가능하게 하는 업무는 귀중하지만 보이지 않음

글루 작업 - 문서화, 온보딩, 팀 간 조정, 프로세스 개선 - 은 필수적이지만, 무의식적으로 하면 기술 궤적을 정체시키고 번아웃을 초래할 수 있음
함정은 이를 "도움됨"으로 하는 것이지, 의도적이고, 경계가 있고, 가시적인 영향으로 다루지 않는 것
시간 제한을 두고, 순환시키고, 산출물로 전환해야 함: 문서, 템플릿, 자동화 - 그리고 이를 성격 특성이 아닌 영향으로 읽기 가능하게 만들어야 함
귀중하지만 보이지 않는 것은 경력에 위험한 조합

14. 모든 논쟁에서 이기면, 아마도 조용한 저항을 축적하고 있는 것

자신의 확신을 의심하는 법을 배웠으며, 너무 쉽게 "이길" 때는 보통 무언가 잘못됨
사람들이 당신과 싸우는 것을 멈추는 이유는 당신이 설득했기 때문이 아니라 포기했기 때문이며, 회의가 아닌 실행에서 그 불일치를 표현함
진정한 정렬은 더 오래 걸림 - 다른 관점을 실제로 이해하고, 피드백을 통합하고, 때로는 공개적으로 마음을 바꿔야 함
옳다는 단기적 느낌은 기꺼이 협력하는 동료들과 함께 무언가를 구축하는 장기적 현실보다 훨씬 가치가 적음

15. 측정이 목표가 되면, 측정을 멈춤

관리에 노출하는 모든 지표는 결국 게임화되며, 악의가 아니라 인간이 측정되는 것을 최적화하기 때문
코드 라인을 추적하면 더 많은 라인을 얻고, 속도를 추적하면 부풀려진 추정치를 얻음
선임의 움직임: 모든 지표 요청에 쌍으로 응답함 - 하나는 속도용, 하나는 품질 또는 리스크용 - 그런 다음 임계값 숭배가 아닌 추세 해석을 주장함
목표는 통찰이지 감시가 아님

16. 모르는 것을 인정하는 것이 아는 척하는 것보다 더 많은 안전을 창출함

"모르겠습니다"라고 말하는 선임 엔지니어는 약함을 보이는 것이 아니라 허가를 창출함
리더가 불확실성을 인정하면 다른 사람들도 동일하게 할 수 있다는 신호이며, 대안은 모두가 이해하는 척하고 문제가 폭발할 때까지 숨겨지는 문화
가장 선임인 사람이 혼란을 인정하지 않는 팀과 그 피해를 목격함 - 질문이 나오지 않고, 가정이 도전받지 않으며, 주니어 엔지니어는 다른 모든 사람이 이해한다고 가정하기 때문에 침묵함
호기심을 모델링하면, 실제로 학습하는 팀을 얻음

17. 네트워크는 당신이 가질 모든 직장보다 오래 지속됨

초기 경력에서 업무에 집중하고 네트워킹을 소홀히 했으며, 돌이켜보면 이는 실수였음
관계에 투자한 동료들 - 회사 안팎 - 은 수십 년간 혜택을 거둠
그들은 기회를 먼저 듣고, 더 빠르게 다리를 구축할 수 있었으며, 역할에 추천받고, 수년간 신뢰를 쌓은 사람들과 벤처를 공동 창업함
직장은 영원하지 않지만, 네트워크는 각 직장보다 오래 감 - 거래적 허슬이 아닌 호기심과 관대함으로 접근해야 함
떠날 때가 오면, 종종 관계가 문을 여는 것

18. 대부분의 성능 향상은 영리함 추가가 아닌 작업 제거에서 나옴

시스템이 느려질 때 본능은 추가하는 것 - 캐싱 레이어, 병렬 처리, 더 똑똑한 알고리듬 - 때때로 이것이 맞지만, "계산하지 않아도 되는 것이 무엇인가?"를 묻는 것에서 더 많은 성능 향상을 목격함
불필요한 작업 삭제는 거의 항상 필요한 작업을 더 빠르게 하는 것보다 더 영향력이 있으며, 가장 빠른 코드는 실행되지 않는 코드
최적화 전에 작업이 존재해야 하는지 의문을 가져야 함

19. 프로세스는 불확실성을 줄이기 위해 존재하며, 서류 흔적 생성을 위해서가 아님

최고의 프로세스는 조정을 더 쉽게 하고 실패를 더 저렴하게 만들며, 최악의 프로세스는 관료적 연극 - 도움이 아니라 잘못될 때 비난을 할당하기 위해 존재함
프로세스가 어떻게 리스크를 줄이거나 명확성을 높이는지 설명할 수 없다면, 아마도 그냥 오버헤드
사람들이 업무를 하는 것보다 업무 문서화에 더 많은 시간을 쓰고 있다면, 무언가 심각하게 잘못됨

20. 결국 시간은 돈보다 가치가 있게 되며, 그에 따라 행동하라

초기 경력에서는 시간을 돈으로 교환하며, 이는 괜찮지만, 어느 시점에서 계산이 역전됨 - 시간이 재생 불가능한 자원임을 깨닫기 시작함
다음 승진 레벨을 쫓고, 보상의 몇 퍼센트 포인트를 더 최적화하며 번아웃되는 선임 엔지니어들을 목격함
일부는 얻었지만, 대부분은 나중에 포기한 것이 가치가 있었는지 의문을 가짐
답은 "열심히 일하지 말라"가 아니라 "무엇을 교환하고 있는지 알고, 의도적으로 교환하라"

21. 지름길은 없지만, 복리는 있음

전문성은 의도적 연습에서 나옴 - 현재 기술을 약간 넘어서서 밀어붙이고, 성찰하고, 반복함 - 수년간 - 압축 버전은 없음
희망적인 부분: 학습은 새로운 선택지를 창출할 때 복리로 작용하며, 새로운 사소한 지식만이 아님
글을 쓰되 - 참여가 아니라 명확성을 위해 - 재사용 가능한 원시 요소를 구축하고, 상처 조직을 플레이북으로 수집함
경력을 복리 이자로 취급하는 엔지니어가 복권 티켓으로 취급하는 엔지니어보다 훨씬 앞서 나가는 경향

최종 생각

21가지 교훈은 많아 보이지만, 실제로는 몇 가지 핵심 아이디어로 귀결됨: 호기심을 유지하고, 겸손함을 유지하고, 업무는 항상 사람에 관한 것임 - 구축하는 사용자와 함께 구축하는 팀원
엔지니어링 경력은 많은 실수를 하고도 앞서 나갈 만큼 충분히 길며, 가장 존경하는 엔지니어들은 모든 것을 올바르게 한 사람이 아니라 잘못된 것에서 배우고, 발견한 것을 공유하고, 계속 나타난 사람들
여정 초기라면 시간이 지나면서 더 풍부해진다는 것을 알고, 깊이 있다면 이 중 일부가 공감되기를 희망함

▲

GN⁺ 19일전 [-]

Hacker News 의견들

“규모가 커지면 버그에도 사용자가 생김”이라는 말이 떠오름
첫 직장에서 로드타임을 5분에서 30초로 줄였을 때, 고객들이 불만을 터뜨렸던 일화가 있었음
예전엔 컴퓨터 켜놓고 커피 마시며 잡담하던 시간이 사라졌기 때문임
이 이야기의 교훈은 단순히 개선하지 말라는 게 아니라, 소프트웨어는 실제 사람들의 습관과 상호작용 속에 존재함을 잊지 말라는 것임
엔지니어의 일은 티켓을 처리하는 게 아니라, 진짜 사용자 문제를 해결하는 것임
- 나도 창고 자동화 프로젝트를 맡았을 때 비슷한 경험을 했음
  효율을 높일수록 직원들이 더 많은 육체노동을 해야 해서 오히려 불만이 생겼음
  결국 나는 ‘좋은 시스템을 망친 사람’으로 보였음
- 이 개념은 Hyrum’s Law에서도 잘 설명됨
  “충분히 많은 사용자가 있다면, 시스템의 모든 관찰 가능한 동작은 누군가에게 의존 대상이 됨”이라는 말이 있음
- 내 비즈니스도 한때 Microsoft와 Netscape의 공통 버그에 의존했음
  매번 “이번엔 고치겠지”라 생각했지만, 10년 동안 고쳐지지 않아 오히려 사업이 유지됐음
- Lehman은 개발자–소프트웨어–사용자 삼각 관계를 이야기했음
  세 주체는 문제를 서로 다르게 이해함
  코드의 의미는 의도나 희망으로 바뀌지 않으며, 현실 세계의 제약 속에서만 작동함
  관련 글: Laws of Software Evolution
- “티켓을 처리하는 게 아니라 문제를 해결하는 게 일”이라는 말에 공감함
  하지만 모든 회사가 그렇게 생각하지 않음
  면접 때 기대치를 명확히 파악하는 게 중요함
Addy Osmani가 쓴 글을 보고 약간의 위선을 느꼈음
예전에 내 코드를 표절했고, 나중에 사과문을 올렸지만 SNS에는 공유하지 않았음
진심 어린 사과라면 팔로워들에게도 공개해야 한다고 생각함
- 실제 사과문 자체는 잘 써졌다고 봄
- “그냥 잊자”는 반응도 있었음. “그게 그렇게 큰 일은 아니지 않냐”는 식으로 말함
처음 세 가지 교훈이 특히 와닿았음
1. 최고의 엔지니어는 사용자 문제 해결에 집착함
  교육 과정에서 언어와 프레임워크만 배우고 문제 자체를 배우지 않는 게 문제임
2. 옳음은 싸게 얻을 수 있지만, 함께 옳아지는 과정이 진짜 일임
  합의는 창의적 과정에서 쌓이고, 권력은 위기 때 쓰여야 함
3. 행동 편향. 일단 Ship해야 함
  실패를 두려워해 논쟁만 하다 시간 낭비하는 경우가 많음
“Boring Technology” 에세이에서 ‘혁신 토큰’ 개념을 처음 배웠음
boringtechnology.club 글인데, 여전히 내가 가장 좋아하는 아키텍처 글 중 하나임
“추상화는 복잡성을 제거하지 않고, 단지 당신이 온콜일 때로 옮긴다”는 말은 Joel Spolsky의 Law of Leaky Abstractions을 떠올리게 함
리더십 15년 동안 대형 리테일 기업에서 수십억 달러 규모의 시스템을 운영했음
하지만 결국 중요한 건 정치와 인간관계였음
더 똑똑한 사람들도 정치 못 해서 승진 못함
아이들에게 “정치와 아부를 배워라”고 가르쳐야 한다는 씁쓸한 결론임
- 어떤 이는 “차라리 그런 세상에서 벗어나 의미 있는 일을 하라”고 함
- 또 다른 이는 “정치인을 불신하고 스스로 강해져라”고 조언함
- 다른 사람은 “그건 단순히 인간관계 기술임”이라며, 영향력을 배우는 게 중요하다고 말함
- 반면 “그런 게임 자체를 거부한다”는 의견도 있었음
“Clarity is seniority”라는 말에 깊이 공감함
명확함이 유지보수성과 확장성의 핵심임
나는 이를 가르치는 책 Elements of Code를 썼음
추상화는 나쁜 게 아니라 목적의 명확성이 문제임
지형을 보지 않고 창고 안에서 다리를 짓는 토목기사와 같음
추상화 자체를 탓할 게 아니라, 무엇을 모델링하려는지 이해해야 함
- 나도 추상화의 위험성에 동의함
  잘못된 추상화는 오히려 명확성을 해치며, 불필요한 복잡성을 낳음
  차라리 부족한 추상화가 낫다고 생각함
이런 리스트의 진짜 가치는 직접 써보는 것임
읽는 것만으로는 금세 잊히고, 스스로 커리어를 돌아보며 정리해야 의미가 생김
이 글은 Google의 공식 가치가 아니라, Google에서 일하며 배운 개인적 교훈임
조직이 가르친 게 아니라, 경험 속에서 스스로 깨달은 것들임
대기업에서도 여전히 어려운 부분들이라는 점이 핵심임
“규모가 커지면 버그에도 사용자가 생긴다”는 건 ossification(경직화) 현상과 같음
네트워크 프로토콜뿐 아니라 모든 시스템에 적용됨
HTTP/3와 QUIC의 암호화 설계 이유도 중간 장치가 잘못된 가정을 하지 못하게 하기 위함임
API도 마찬가지로 내부 상태를 노출하지 말아야 함
- 이는 Hyrum’s Law와 유사한 개념임
“Bias towards action” 문장이 인상 깊었음
아무리 좋은 조언도 빈 페이지에는 도움이 안 됨
일단 뭔가 만들어야 피드백을 받을 수 있음
- 나도 그 문장을 좋아함
  첫 글자를 입력하는 순간, 예상치 못한 문제들이 드러남
  거대한 조직일수록 이런 보이지 않는 병목이 많음
- 하지만 Google은 품질과 성능에도 더 편향됐으면 좋겠음
  “Ship fast”가 “엉성하게 내보내라”는 뜻은 아님
  완성도 높은 최소 기능 제품이 오히려 낫다고 생각함
- 여러 회사에서 “행동 편향”을 내세웠지만, 실제로는 야근과 불량 릴리스로 이어졌음
  현실과 이상 사이의 간극이 크며, 글쓴이는 “Kool Aid가 맛있었다”고 풍자함
- 내 버전은 “존재 자체가 가장 중요한 기능”임
- 하지만 팀 전체가 같은 마인드여야 함
  그렇지 않으면 “날림”으로 오해받고, 문제 생기면 희생양이 됨