Skip to content

Google

Google Products의 상세 목록

구글(Google)은 웹 검색, 클라우드 컴퓨팅, 광고를 주 사업 영역으로 하는 미국의 다국적 회사로 1998년에 래리 페이지(Larry Page)와 세르게이 브린(Sergey Brin)이 ~BackRub이라는 이름으로 설립했다. 구글은 미국 전체 인터넷 검색의 2/3, 전 세계의 70%를 장악했다. 2008년에 구글은 자사 웹 페이지 인덱스 크기가 1조 개를 돌파했다고 발표했으며 다른 어떤 검색 엔진보다도 3배 이상 큰 인덱스를 관리한다. 2009년 초 구글에서 매일 수십억 개의 검색 결과 페이지가 방문되고, 수백억 개의 구글 광고가 노출되었다.

Categories

ETC

  • Genkit - Google의 오픈소스 AI 풀스택 프레임워크
  • Longfellow ZK - 구글, ‘제로-지식 증명(ZKP)’ 기술 오픈소스로 공개

사이트 단축키

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

최종 생각

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

Google에서 14년간 얻은 또다른 14가지 교훈

  1. 최고의 엔지니어들은 적절한 문제를 고른다
    • 모든 일에 최대의 에너지를 쏟을 수는 없다.
  2. 뭘 요구해야 할 지 모르겠다면, 당신은 미팅할 준비가 되지 않은 것이다
    • 허가, 선택, 막힘 해소 (unblock), 정보 공유 (inform) - 이 중 하나를 고를 수 없다면, 그 미팅은 시간낭비일 것이다.
  3. "해야죠"는 계획이 아니다. "화요일에 할게요"가 계획이다.
    • 구체적인 날짜를 지정하면 추진력이 생긴다.
  4. 느린 코드는 증상일 뿐이고, 느린 의사결정이 진짜 원인이다.
    • 무언가 결정하는데 몇 시간이 아니라 몇 주가 걸린다면 그 이유를 들여다보아야 한다.
  5. 신뢰성 (Reliability) 는 제품의 기능으로 간주하라
    • 제품를 검토하지 않고 기능을 출시하지 않듯이, 신뢰성에 대한 논의없이 시스템을 배포해선 안된다.
  6. 팀 간의 인터페이스가 나쁘다면 커뮤니케이션을 잘 할 수 없다
    • 모호한 경계와 불분명한 계약 (Contract) 들은 더 많은 회의와 슬랙 채널을 만든다. 누가 무엇을 책임지고 있고, 서로 어떻게 의존하고 있는지가 명확해야 한다.
  7. 최고의 에스컬레이션은 제안을 곁들이는 것이다.
    • 문제를 제기하는 사람과 문제를 해결하는 사람 모두 이슈를 파악해냈지만, 한 쪽만이 신뢰와 자율성을 얻는다.
  8. 영웅이 필요없는 시스템을 구축하라
    • 한 사람이 지속적으로 회사나 팀을 구해내고 있다면, 그것은 영광이 아니라 추락하고 있다는 신호다.
  9. 관측 가능성 (Observability) 를 기능의 일부로 여겨라
    • "코드가 잘 작동한다는 것을 확인했음"을 일의 종료로 간주하라.
  10. 작은 PR은 친절함이다. 특히 그게 AI가 만든 것이라면.
    • 작은 PR은 점진적으로 생각할 수 있게 만들기에, 지식을 조금씩 차곡차곡 쌓아갈 수 있다.
  11. 새 팀을 추가하면 것은 노드 (Node) 뿐 아니라 간선 (Edge) 들도 추가된다
    • 의도적으로 연결고리를 줄이지 않으면 새 팀을 추가해도 아웃풋은 동일하다.
  12. 마이그레이션은 절대 그냥 마이그레이션이 아니다
    • 실제로 완료되는 마이그레이션은 세 가지 공통점을 가진다. 지속적으로 관여하는 후원자 (Sponsor), 진정으로 마이그레이션을 주도하는 팀, 그리고 모두가 신뢰하는 명확한 종료일. 이 세 가지가 모두 충족되지 않으면 마이그레이션은 영원히 '거의 완료' 상태에 머물게 되고, 영원히 두 시스템을 책임진다.
  13. AI는 초안을 쉽게 만들고, 취향 (Taste) 은 점점 희귀해지고 있다.
    • 가장 훌륭한 것을 선별하는 엔지니어가 이 시대의 최고가 될 것이다.
  14. 신뢰는 레이턴시 최적화다
    • 약속을 지킬 때마다, 실수를 솔직히 인정할 때마다, 남들의 삶을 편하게 해줄 때마다, 당신은 예금을 하는 것이다. 나는 평범한 기술력을 가진 엔지니어들이, 모두가 그들을 신뢰했기에 엄청난 성과를 이루는 모습을 봤다.

See also

  • DuckDuckGo
  • gogcli - 터미널에서 Google Workspace를 제어하는 고속 CLI

Favorite site

Tip/Trick

  • Cutting Google out of your life - DeGoogle - 내 삶에서 구글 제거하기 - 구글 의존적인 삶에서 구글 제품들을 제거하기 위한 대체제들을 정리

Article

  • Millions of Accounts Vulnerable due to Google’s OAuth Flaw ◆ Truffle Security Co. - 구글 OAuth 결함으로 수백만 계정이 위험에 처하다
    • 구글의 '구글로 로그인' 인증 흐름에 결함이 있어 수백만 명의 개인 정보가 도용될 위험에 처해 있습니다.
    • 구글 OAuth 로그인은 실패한 스타트업의 도메인을 구매한 공격자가 이전 직원의 이메일 계정을 재생성하는 것을 막지 않습니다.
    • 이로 인해 여러 SaaS 제품에 대한 접근이 가능해지며, 민감한 데이터(소셜 보장 번호, 세금 문서 등)가 유출될 수 있습니다.
    • 현재 100,000개 이상의 실패한 스타트업의 도메인이 매매 가능하며, 이로 인한 잠재적 노출 계정 수는 1천만 개 이상에 이를 수 있습니다.
    • 구글은 이 문제를 인지하였지만 아직 해결책을 제시하지 않았습니다.