소네가 쓴 클로드 4.5는 제 생각에 꽤 잘 쓰여진 작품입니다. (전체 텍스트는 17,000단어로 구성되어 있으며, 이는 그 중 첫 번째 부분입니다.) 코드의 신: 제프 딘의 전기 제프 딘은 1968년 7월 23일 하와이에서 태어났습니다. 태평양에 있는 이 군도는 화산, 해변, 다양한 문화로 유명하지만, 과학 천재들의 요람으로 여겨지는 경우는 드뭅니다. 하지만 딘의 어린 시절은 평범함과는 거리가 멀었습니다. 그의 아버지 앤디는 열대병 연구가였습니다. 그의 어머니 버지니아 리는 6개 국어를 구사하는 의료 인류학자였습니다. 이러한 가족적 배경 때문에 그는 하와이에서 애틀랜타의 질병통제예방센터, 제네바의 세계보건기구를 거쳐 마침내 미네소타에 정착하는 등 전 세계를 옮겨 다니며 성장했습니다. 그는 13살 때 부모님을 돕기 위해 소말리아 서부의 난민 캠프로 가기 위해 8학년 마지막 3개월을 빼먹기도 했습니다. 끊임없이 변화하는 환경은 복잡한 시스템에 대한 그의 초기 직관을 키워주었습니다. **질병 전파 패턴이든 나중에는 컴퓨터 네트워크의 데이터 흐름이든, 이 모든 것은 이해하고, 모델링하고, 최적화할 수 있는 특정 규칙을 따릅니다.** 재미 삼아 아버지와 아들은 IMSAI 8080 제품군 컴퓨터를 함께 프로그래밍했습니다. 그들은 업그레이드 부품을 기계에 용접하고 모든 구성 요소에 대해 배웠습니다. 하드웨어 관점에서 컴퓨터를 이해하는 이러한 경험은 딘의 경력에 초석이 될 것입니다. 그는 코드의 논리를 이해할 뿐만 아니라 실리콘 웨이퍼에서 전류가 어떻게 흐르는지도 이해합니다. 고등학교 때 딘은 역학자들을 위해 Epi Info라는 데이터 수집 프로그램을 쓰기 시작했습니다. 이 프로그램은 해당 분야의 표준 도구가 되었고, 결국 수십만 부가 배포되었으며 12개 이상의 언어를 지원하게 되었습니다. 미국 질병통제예방센터가 관리하는 "에피 인포 이야기"라는 웹사이트에는 제프가 고등학교를 졸업했을 때의 사진이 아직도 보관되어 있습니다. 하지만 그는 결코 자신의 주도로 이 업적을 언급한 적이 없습니다. 몇 년 후, 그의 아내 하이디는 그 프로그램의 중요성을 깨달았습니다. "그는 그런 거 절대 자랑 안 해요." 그녀가 말했다. "그에게서 그걸 알아내야 해요." 미네소타 대학교에서 딘은 컴퓨터 과학과 경제학을 이중 전공으로 선택했습니다. 이처럼 겉보기에 특이한 조합은 실제로 그의 사고방식의 이중적 측면을 보여줍니다. 기술적 우수성을 추구하는 동시에 자원 효율성에도 집중한다는 것입니다. 그는 대학에서 하이디를 만났다. 두 사람의 첫 데이트는 여자 농구 경기를 보러가는 것이었습니다. 제프는 고퍼 마스코트로 분장하고 환호했습니다. 1990년에 그는 신경망에 관한 학부 논문을 완성했습니다. 당시에는 이런 세부 사항이 중요하지 않은 것처럼 보였을지 모르지만, 20년 후에 돌이켜보면 운명을 예고하는 일인 듯합니다. 당시 신경망 연구는 'AI 겨울'의 끝자락에 있었고, 학계는 대체로 이 분야의 전망에 대해 비관적이었습니다. 하지만 젊은 딘은 이미 기계가 데이터를 통해 '학습'하는 비밀을 탐구하고 있었습니다. 졸업 후 딘은 특이한 선택을 했습니다. 기술 회사에 바로 들어가는 대신, 제네바로 가서 세계보건기구의 글로벌 에이즈 프로그램에서 일했습니다. 그곳에서 그는 전염병에 대한 통계적 모델링 소프트웨어를 개발했는데, 이 소프트웨어를 통해 인간이 치명적인 질병의 확산을 이해하고 퇴치하는 데 도움이 되는 코드를 사용했습니다. 이 경험은 그가 "규모"에 대해 처음 이해하게 된 계기가 되었습니다. 여기서 "규모"란 서버 클러스터의 규모가 아니라 전 세계적인 공중 보건 위기의 규모를 의미합니다. 소프트웨어가 수백만 명의 생명과 관련된 데이터를 처리해야 할 때, "실패"는 더 이상 추상적인 기술 용어가 아니라 실제 인간의 비극입니다. ## 1막: 시스템 빌더의 탄생 ### 견습: 컴파일러의 마법 딘은 1996년에 워싱턴 대학에서 컴퓨터 과학 박사 학위를 받았습니다. 그의 박사학위 연구는 컴파일러에 집중되어 있었습니다. 인간이 작성한 코드를 컴퓨터가 실행할 수 있는 최적화된 기계어 명령어로 번역하는 소프트웨어입니다. "매력적인 측면에서 보면, 컴파일러는 거의 가장 지루한 것들이에요." 그의 후임 매니저인 앨런 유스타스는 이렇게 말했다. 반면에, 그들은 당신을 "기계에 아주 가까이" 데려갑니다. 컴파일러는 프로그래머와 기계 사이의 번역기 역할을 하며, 컴파일러를 최적화하는 사람은 추상적인 인간의 사고와 실리콘 칩의 물리적 한계에 모두 능숙해야 합니다. 이러한 "이중 언어 능력"은 딘의 경력에 있어 핵심적인 경쟁 우위가 될 것입니다. 산제이가 나중에 제프를 묘사할 때, 그는 관자놀이 근처에서 검지손가락을 모았습니다. "당신이 코드를 쓰는 동안, 그는 머릿속에서 모델을 실행합니다."라고 그는 말했습니다. "'이 코드의 성능은 어떨까?' 그는 거의 자동적으로 모든 극단적인 경우를 고려했습니다." 그는 박사학위를 취득한 후 전설적인 DEC Western Research Laboratory(나중에 Compaq에 인수됨)에 입사했습니다. 그곳에서 그는 최고 엔지니어 그룹과 함께 분석 도구, 마이크로프로세서 아키텍처, 정보 검색에 중점을 두고 작업했습니다. 이 3년간의 경험은 그가 나중에 Google에서 일할 수 있는 튼튼한 기초를 마련해 주었습니다. 분석 도구는 그에게 시스템 병목 현상을 이해하는 방법을 가르쳐 주었고, 마이크로프로세서 아키텍처는 그에게 하드웨어의 본질에 대한 깊은 이해를 주었으며, 정보 검색은 검색 엔진의 핵심 문제입니다. 제프는 "모든 프로그래머가 알아야 할 지연 시간 수치"라는 제목의 목록을 배포한 적이 있습니다. 사실, 이는 거의 모든 프로그래머가 알지 못하는 숫자 목록입니다. **L1 캐시 참조에는 일반적으로 0.5나노초가 걸리는 반면, 메모리에서 1메가바이트를 순차적으로 읽는 데는 250마이크로초가 걸립니다.** 이 숫자들은 그의 마음속에 깊이 새겨져 있다. ### 산제이: 뇌의 다른 반쪽 12월에 딘은 산제이 게마와트를 만났다. 산제이는 1966년 인디애나주 웨스트 라파예트에서 태어났지만, 인도 북부의 산업 도시인 코타에서 자랐습니다. 그의 아버지 마히팔은 식물학 교수였습니다. 그의 어머니 샨타는 산제이와 그의 두 형제 자매를 돌보았습니다. 산제이의 동생 판카이는 하버드 경영대학원 역사상 최연소 종신 교수직을 받은 교수였습니다. (그는 현재 뉴욕대 스턴 경영대학원 교수로 재직 중입니다.) 판카이와 산제이는 같은 학교에 다녔으며 학식이 풍부하기로 유명했습니다. 산제이는 "저는 어느 정도 형의 그늘 속에서 살고 있어요"라고 말했다. 그는 어른이 된 뒤에도 겸손함을 잃지 않았습니다. 2016년에 미국 예술 과학 아카데미에 합격했을 때, 그는 부모님께 말하지 않았습니다. 이웃들이 그들에게 말했습니다. 산제이는 17세가 되어 코넬 대학에 진학할 때까지 컴퓨터를 처음 접했습니다. 그는 MIT 대학원생일 당시 지도교수였던 바바라 리스코프는 영향력 있는 컴퓨터 과학자였으며, 그녀의 연구 분야에는 복잡한 코드베이스 관리가 포함되었습니다. 그녀의 견해로는, 최고의 코드는 좋은 기사와 같습니다. 각 단어가 역할을 하는 잘 생각된 구조가 필요합니다. 이런 방식으로 프로그래밍하려면 독자에 대한 공감이 필요합니다. 이는 코드를 단순한 수단이 아닌 그 자체로 하나의 예술 작품으로 보는 것을 의미합니다. 구글의 첫 직원인 크레이그 실버스타인은 "제 생각에 그의 가장 큰 장점은 시스템을 설계하는 능력입니다."라고 말했습니다. "산제이가 작성한 코드 파일을 보면, 그 아름다움은 마치 균형 잡힌 조각품과 같습니다." DEC에서 제프는 자신의 연구실에서 산제이의 연구실까지 두 블록을 걸어가곤 했습니다. "가운데에 이탈리아 젤라토 가게가 있었어요." 제프가 회상했다. 산제이는 흥분해서 "그럼 그 아이스크림 가게 때문이구나!"라고 소리쳤다. 그들은 함께 프로그래밍을 시작했습니다. 각자의 컴퓨터에서 작업하는 대신, 한 대의 컴퓨터를 공유하여 한 사람은 키보드를 조작하고 다른 한 사람은 그들을 안내하고 수정하는 방식이었습니다. 이런 유형의 협업은 소프트웨어 개발에서는 흔하지 않습니다. 사회학자 마이클 P. 패럴은 2001년 저서 *협력의 원: 우정과 창의적 작업의 역학*에서 다음과 같이 지적합니다. "새로운 관점의 기반이 되는 깨지기 쉬운 통찰력 대부분은 전체 그룹이 함께 모였을 때나 구성원들이 혼자 일했을 때 나타나는 것이 아니라, 구성원들이 둘씩 짝을 지어 협력하고 서로에게 반응할 때 나타납니다." 1869년 여름, 모네와 르누아르는 나란히 작업하면서 나중에 인상주의로 발전하게 될 스타일을 발전시켰습니다. 큐비즘을 탄생시킨 6년간의 협업 기간 동안 피카소와 브라크는 종종 캔버스 뒷면에만 서명을 해서 어떤 그림이 어떤 사람에 의해 완성되었는지를 감췄습니다. 산제이는 파트너와 함께 프로그래밍하는 것을 언급하며 "왜 더 많은 사람들이 이런 일을 하지 않는지 모르겠어요"라고 말했습니다. 제프는 "당신의 사고방식과 맞는 사람을 찾아 페어 프로그래밍을 해야 합니다. 그래야 두 분이 서로를 보완할 수 있죠."라고 말했습니다. 1999년 중반, 닷컴 버블이 정점에 다다랐습니다. 제프는 DEC를 떠나 "구글"이라는 작은 회사에 입사했습니다. 당시 구글의 직원은 수십 명뿐이었고, 사무실은 캘리포니아주 마운틴 뷰의 눈에 띄지 않는 건물에 있었습니다. 10개월 후, 산제이가 뒤따랐습니다. 두 사람의 전설적인 협업은 인터넷의 역사를 바꾸게 될 것입니다. ### 2000년 3월: 재난과 재탄생 2000년 3월 어느 날, 구글의 최고 엔지니어 6명이 임시 작전실에 모였습니다. 회사는 전례 없는 비상 상황에 직면해 있습니다. 작년 10월, 웹 페이지를 크롤링하여 "색인"을 구축하는 핵심 시스템이 작동을 멈췄습니다. 사용자는 https://t.co/cHDYnkjtpa에서 여전히 쿼리를 입력할 수 있지만, 5개월 전의 오래된 데이터가 제공됩니다. 상황을 더욱 악화시키는 것은, 구글의 공동 창립자인 래리 페이지와 세르게이 브린이 야후에 검색 엔진 지원을 제공하기 위한 계약을 협상하고 있었다는 것입니다. 두 사람은 당시보다 10배 더 큰 색인을 제공하겠다고 약속했습니다. 실패하면 https://t.co/cHDYnkjtpa는 과거에 갇히게 되고, 야후와의 거래는 무산될 가능성이 높으며, 회사는 자금이 고갈되어 파산할 위험에 직면하게 될 것입니다. 계단 근처의 회의실에서 엔지니어들은 제재소에 문 패널을 설치하고 컴퓨터를 설치했습니다. 구글의 첫 직원인 크레이그 실버스타인은 가장 먼 벽 가까이에 앉았습니다. 그와 보그단 코코셀이라는 루마니아 시스템 엔지니어는 4일 4박 동안 일했지만 아무 소용이 없었습니다. "우리의 모든 분석은 무의미했습니다." 실버스타인은 회상했다. "모든 것이 망가졌고, 그 이유를 알 수 없었습니다." 실버스타인은 왼쪽 뒤에 산제이 고마워터가 있다는 것을 거의 알아차리지 못했습니다. 산제이는 제프 딘과 함께 DEC에서 온 뒤 몇 달 전에 회사에 합류했습니다. 수술실에서 제프는 산제이의 책상 옆으로 의자를 밀어 넣어 빈자리를 만들었다. 산제이는 키보드를 조작했고, 제프는 그에게 가까이 다가와 마치 뉴스 앵커의 귀에 속삭이는 프로듀서처럼 그를 바로잡고 지도했다. 제프와 산제이는 정체지수를 더욱 자세히 조사하기 시작했습니다. 그들은 몇몇 단어가 누락된 것을 발견했습니다. "mailbox"로 검색해도 결과가 나오지 않았고, 다른 단어들은 순서가 틀렸습니다. 그들은 며칠 동안 코드의 결함을 찾고 코드의 논리를 탐구했습니다. 각 섹션을 확인한 결과, 모든 것이 괜찮아 보였습니다. 그들은 버그를 찾을 수 없었습니다. 수술실에서 근무한 지 5일째 되는 날, 제프와 산제이는 자신들이 찾고 있는 문제가 논리적인 것이 아니라 물리적인 것이라는 의심을 품기 시작했습니다. 그들은 지저분한 색인 파일을 가장 원시적인 표현인 **바이너리 코드**로 변환했습니다. 그들은 자신의 기계가 무엇을 보고 있는지 보고 싶어했습니다. 산제이의 모니터에는 1과 0으로 이루어진 빽빽한 열이 나타났고, 각 행은 색인 용어를 나타냈습니다. 산제이는 0이어야 할 숫자가 1이 된 것을 가리켰습니다. 제프와 산제이가 순서가 잘못된 단어들을 모두 합치자, 그들은 하나의 패턴을 발견했습니다. 각 단어에는 똑같은 사소한 오류가 있었습니다. 어떤 이유에서인지 해당 기기의 메모리 칩이 손상되었습니다. 산제이는 제프를 바라보았다. Google에서는 지난 몇 달 동안 하드웨어 오류가 점점 더 많이 발생하고 있습니다. 문제는 구글이 성장함에 따라 컴퓨팅 인프라도 확장된다는 것입니다. 컴퓨터 하드웨어는 충분한 양이 아니면 거의 고장나지 않습니다. 하지만 충분한 양이면 자주 고장날 것입니다. 마모된 전선, 하드 드라이브 고장, 마더보드 과열. 많은 기계는 처음부터 작동하지 않습니다. 어떤 기계는 설명할 수 없을 정도로 속도가 느려집니다. 이상한 환경적 요인도 영향을 미치기 시작했습니다. 초신성이 폭발하면 충격파가 모든 방향으로 흩어지는 고에너지 입자를 생성합니다. 과학자들은 우주선이라고 불리는 이러한 흩어진 입자가 지구의 컴퓨터 칩에 부딪혀 0을 1로 바꿀 확률은 매우 낮다고 생각합니다. NASA나 금융 회사에서 사용하는 것과 같은 세계에서 가장 견고한 컴퓨터 시스템은 비트 플립을 허용할 수 있는 특수 하드웨어를 사용합니다. 하지만 당시 구글은 여전히 신생기업처럼 운영되고 있었고, 해당 기능이 없는 싼 컴퓨터를 구매하고 있었습니다. 캘리포니아주 산타클라라의 한 건물에서 구글은 1,500개의 맨 마더보드와 하드 드라이브를 샌드위치처럼 쌓아 6피트 높이의 타워를 만들었습니다. 하드웨어 고장으로 인해 1,200개만 작동 중입니다. 회사는 전환점에 도달했습니다. 컴퓨팅 클러스터가 너무 커져서 드물게 발생하는 하드웨어 오류도 불가피해졌습니다. 제프와 산제이는 제대로 작동하지 않는 기계를 보완하기 위해 함께 코드를 작성했습니다. 얼마 지나지 않아 새로운 지수가 완성되었고, 운영실은 해체되었습니다. ### 주말 재작성: 탄력적 시스템의 탄생 이 위기는 전환점이 되었습니다. 제프와 산제이는 구글이 성장함에 따라 하드웨어 고장은 우연이 아니라 일반적인 현상이 될 것이라는 걸 깨달았습니다. 서버가 수천, 수만 대가 있으면 매일 기계 충돌, 하드 드라이브 오류, 네트워크 중단이 발생할 것입니다. 시스템이 이러한 실패를 처리할 수 없다면 Google은 확장할 수 없습니다. 그들은 완전히 새로운 인프라를 구축해야 합니다. **혼란 속에서도 질서를 유지할 수 있는 시스템입니다.** 이번 주말에 다시 쓴 내용의 핵심 디자인 철학은 **실패를 예상하라**입니다. 하드웨어가 완벽하다고 가정하는 것보다, 하드웨어가 *고장*날 것이라고 가정하는 것이 더 낫습니다. 시스템은 손상된 데이터를 자동으로 감지하고, 오류가 있는 시스템을 표시하고, 이를 우회하여 계속 작동할 수 있어야 합니다. 오늘날 분산 시스템에서는 "장애 허용"이라는 개념이 상식이지만, 2000년에는 획기적인 것이었습니다. 3월 지수 폭락 이전까지 구글의 시스템은 창립자들이 스탠포드 대학 대학원생 시절에 작성한 코드에 기반을 두고 있었습니다. 페이지와 브린은 전문적인 소프트웨어 엔지니어가 아니다. 그들은 검색 기술에 대한 실험을 진행하는 학자입니다. 웹 크롤러가 작동을 멈추었을 때, 아무런 정보를 제공하는 진단 메시지도 나오지 않았고, "와, 말!"이라는 문구만 나왔습니다. 초창기 직원들은 페이지와 브린이 작성한 BigFiles라는 소프트웨어를 BugFiles(오류가 가득한 파일)이라고 불렀습니다. 중요한 인덱싱 코드를 완성하는 데는 며칠이 걸리고, 문제가 발생하면 처음부터 다시 시작해야 합니다. 실리콘 밸리의 전문 용어로, 당시 구글은 "확장성"이 부족했습니다. 웨인 로징은 2000년 11월 구글에 합류하여 100명의 엔지니어로 구성된 팀을 관리하기 전에 애플에서 매킨토시 컴퓨터의 전신인 제품을 개발하는 데 일했습니다. 그는 "그들이 리더입니다"라고 말했다. 제프와 산제이는 구글의 인프라를 재구축하기 위해 협력했습니다. 그들은 단일 하드 드라이브 오류로 인해 전체 시스템이 충돌하는 일이 없도록 일주일에 90시간씩 코드를 작성합니다. 그들은 크롤링 과정 중에 체크포인트를 추가하여 중간에 다시 시작할 수 있도록 했습니다. 그들은 새로운 인코딩 및 압축 방식을 개발함으로써 시스템 용량을 효과적으로 두 배로 늘렸습니다. 그들은 무자비한 최적화자입니다. 자동차가 회전할 때, 바깥쪽 바퀴가 더 많은 지면을 덮어야 합니다. 마찬가지로, 회전하는 하드 드라이브의 바깥쪽 가장자리는 안쪽 가장자리보다 더 빨리 움직입니다. Google은 가장 자주 액세스되는 데이터를 외부로 옮겨서 데이터 비트가 읽기/쓰기 헤드 아래로 더 빨리 흐를 수 있도록 했지만 내부는 반쯤 비어 있습니다. Jeff와 Sanjay는 이 공간을 사용하여 일반적인 검색 쿼리에 대한 사전 처리된 데이터를 저장했습니다. 2001년에 그들은 4일 만에 구글의 색인이 비교적 느린 하드 드라이브 대신 빠른 랜덤 액세스 메모리(RAM)를 사용하여 저장될 수 있다는 것을 증명했습니다. 이 발견으로 회사의 경제 모델이 바뀌었습니다. 페이지와 브린은 사용자들이 즉시 답변을 제공할 수 있는 서비스에 몰려들 것이라는 걸 알고 있었습니다. 문제는 속도를 높이려면 컴퓨팅 능력이 필요하고, 컴퓨팅 능력에는 비용이 든다는 것입니다. 제프와 산제이는 소프트웨어를 사용하여 문제를 현명하게 해결했습니다. 로신이 2005년에 떠난 후 앨런 유스타스가 엔지니어링 팀의 수장이 되었습니다. "역설적이게도, 스케일링 문제를 해결하려면 가장 작은 세부 사항까지 이해해야 합니다."라고 유스터스는 말했습니다. 제프와 산제이는 컴퓨터를 비트 수준에서 이해합니다. 그들이 주도한 Google의 핵심 소프트웨어를 여러 번 다시 작성하는 동안 시스템 용량이 엄청나게 확장되었습니다. 그 사이, 회사의 거대한 데이터 센터에서는 기술자들이 구불구불한 길을 따라 움직이며 소프트웨어에서 생성된 지침에 따라 하드 드라이브, 전원 공급 장치, 메모리 모듈을 교체하고 있습니다. 구성 요소가 마모되어 고장이 나더라도 시스템은 여전히 정상적으로 작동할 수 있습니다. ### MapReduce: 혼란을 단순화하다 2004년에 딘과 제마워터는 "MapReduce: 대규모 클러스터에서의 간소화된 데이터 처리"라는 제목의 논문을 발표했습니다. 이 논문은 저자가 두 명뿐이지만, 업계 전체를 바꿀 것입니다. MapReduce의 핵심 아이디어는 매우 간단합니다. **복잡한 분산 컴퓨팅을 `Map`과 `Reduce`라는 두 가지 함수로 추상화합니다.** `Map` 함수는 입력 데이터를 처리하고 중간 키-값 쌍을 생성합니다. `Reduce` 함수는 동일한 키를 가진 값을 모아 최종 결과를 생성합니다. 프로그래머는 이 두 가지 기능만 정의하면 시스템이 자동으로 병렬화, 작업 스케줄링, 머신 간 통신, 장애 복구를 처리합니다. 이 추상화의 힘은 **단순성**에 있습니다. MapReduce가 등장하기 전에는 분산 프로그램을 작성하려면 심층적인 시스템 지식이 필요했습니다. 즉, 스레드를 직접 관리하고, 네트워크 통신을 처리하고, 시스템 오류를 처리해야 했습니다. 이런 복잡성 때문에 대부분의 프로그래머는 프로그래머가 될 수 없습니다. 하지만 MapReduce는 이런 복잡성을 시스템 내부에 숨겨 분산 시스템 경험이 없는 엔지니어도 테라바이트 규모의 데이터를 쉽게 처리할 수 있게 해줍니다. 이 논문의 한 예는 많은 수의 문서에서 각 단어가 나타나는 횟수를 세는 것입니다. `Map` 함수는 문서를 읽고 `(단어, 1)`의 키-값 쌍을 출력합니다. `Reduce` 함수는 같은 단어의 개수를 더합니다. 전체 프로그램에는 몇 줄의 코드만 필요하지만, 수천 대의 컴퓨터에서 병렬로 실행되어 인터넷 전체의 웹 페이지를 처리할 수 있습니다. MapReduce의 또 다른 주요 장점은 **내결함성**입니다. 시스템은 작업 실행을 지속적으로 모니터링하며, 한 컴퓨터에서 작업이 실패하면 다른 컴퓨터에서 자동으로 작업을 다시 실행합니다. 이 "재실행" 전략이 효과적인 이유는 `Map` 및 `Reduce` 함수가 "함수형"으로 설계되었기 때문입니다. 즉, 입력 데이터를 수정하지 않고 출력만 생성합니다. 즉, 작업을 다시 실행해도 부작용이 발생하지 않으며 결과가 결정적입니다. 이 디자인은 "2000년대 위기"의 교훈에서 직접 영감을 받았습니다. 하드웨어는 고장날 수 있지만 시스템은 계속 작동해야 합니다. MapReduce는 Google에서 빠르게 인기를 얻었습니다. 검색 인덱스를 구축하고, 로그 데이터를 처리하고, 보고서를 생성하고, 머신 러닝 모델을 훈련하는 데 사용됩니다. 이 논문이 출판된 2004년에는 수백 개의 MapReduce 프로그램이 이미 Google에서 실행되고 있었습니다. 더 중요한 점은 MapReduce의 아이디어가 업계 전체로 퍼졌다는 것입니다. 야후는 이 논문을 바탕으로 MapReduce의 오픈소스 구현인 Hadoop을 개발했고, 이는 빅데이터 시대의 초석이 되었습니다. ### Bigtable: 저장의 예술 MapReduce가 대규모 계산 문제를 해결한다면, Bigtable은 대규모 저장 문제를 해결합니다. 2006년에 딘과 제마워터는 다른 몇몇 구글 엔지니어들과 함께 "Bigtable: 구조화된 데이터를 위한 분산 저장 시스템"을 출판했습니다. Bigtable은 고처리량 일괄 처리와 저지연 실시간 쿼리를 지원하는 동시에 페타바이트 규모의 구조화된 데이터를 관리하도록 설계되었습니다. 이는 겉보기에 모순되는 요구 사항을 나타냅니다. **일괄 처리에서는 대량의 데이터를 스캔해야 하는 반면, 실시간 쿼리에서는 단일 결과를 빠르게 반환해야 합니다.** 기존의 관계형 데이터베이스는 이 두 가지 요구 사항을 동시에 충족할 수 없습니다. Bigtable의 솔루션은 고유한 데이터 모델입니다. 즉, "희소하고 분산되어 있으며 지속적인 다차원 정렬 맵"입니다. 각 데이터 항목은 행 키, 열 키, 타임스탬프의 세 가지 차원으로 인덱싱됩니다. 이 디자인은 뛰어난 유연성을 제공합니다. - **행 키**: 데이터는 행 키별로 정렬되어 저장되며, 인접한 행 키는 동일한 머신에 저장됩니다. 이를 통해 다양한 범위의 데이터를 매우 효율적으로 스캔할 수 있습니다. - **열 패밀리**: 열은 열 패밀리로 구성되며, 각 열 패밀리에는 고유한 액세스 제어 및 압축 정책이 있습니다. 이를 통해 시스템은 다양한 액세스 패턴에 따라 스토리지를 최적화할 수 있습니다. - **타임스탬프**: 각 데이터 항목은 타임스탬프로 구분되는 여러 버전을 가질 수 있습니다. 시스템은 최신 N개 버전 또는 최근 T일 동안의 버전을 자동으로 보관할 수 있으며, 이전 버전은 가비지 컬렉션됩니다. Bigtable의 또 다른 주요 디자인 특징은 그것이 관계형 데이터베이스가 *아니다*는 것입니다. 복잡한 SQL 쿼리나 행 간 트랜잭션은 지원하지 않습니다. 이러한 제한은 의도적인 것입니다. **이러한 제한을 통해 시스템은 복잡한 일관성 프로토콜에 의해 방해받지 않고 수천 대의 컴퓨터에 걸쳐 수평적으로 확장될 수 있습니다.** Google 내에서 Bigtable은 웹 페이지 인덱스, Google Earth의 지리적 데이터, Google Analytics의 사용자 행동 데이터 등을 저장하는 데 사용됩니다. 그 영향력은 업계 전체로 확대되었습니다. Amazon의 DynamoDB, Facebook의 Cassandra, Apache의 HBase는 모두 Bigtable에서 영감을 받았습니다. ### 스패너: 글로벌 일관성의 정점 MapReduce와 Bigtable은 Google 인프라의 기반을 마련했지만, 두 기술 모두 공통적인 한계를 가지고 있습니다. 즉, 주로 단일 데이터 센터에서 사용하도록 설계되었다는 것입니다. Google이 전 세계로 확장함에 따라 데이터를 여러 대륙에 분산해야 합니다. 전 세계적으로 데이터 일관성을 유지하는 것이 다음 과제가 되었습니다. 2012년에 딘과 제마워터는 다른 엔지니어들과 함께 "스패너: 구글의 전 세계 분산 데이터베이스"를 출판했습니다. Spanner는 "외부적으로 일관된 분산 트랜잭션"을 지원하는 세계 최초의 글로벌 분산 데이터베이스입니다. Spanner의 핵심 혁신은 **TrueTime API**입니다. 분산 시스템에서 시간은 까다로운 문제입니다. 서로 다른 컴퓨터의 시계가 동기화되지 않을 수 있으며, 네트워크 지연으로 인해 두 이벤트의 실제 순서를 확신할 수 없습니다. 스패너의 솔루션은 GPS와 원자 시계를 활용해 시계 불확실성을 노출할 수 있는 API를 구축하는 것입니다. TrueTime은 "지금 12:00:00입니다"라고 알려주지 않고 "오차 범위가 ±7밀리초 이내이며 지금 12:00:00입니다"라고 알려줍니다. Spanner는 이러한 불확실성을 정확히 알고 있기 때문에 글로벌 트랜잭션에 의미 있는 커밋 타임스탬프를 할당할 수 있습니다. 불확실성이 너무 크면 시스템은 사전에 "불확실성이 지나갈 때까지 기다립니다." 이를 "커밋 대기"라고 합니다. 일반적으로 이러한 대기 시간은 몇 밀리초에 불과하지만 트랜잭션의 외부 일관성을 보장합니다. 트랜잭션 T1이 트랜잭션 T2보다 먼저 커밋하는 경우 T1의 타임스탬프는 T2의 타임스탬프보다 작아야 합니다. 스패너의 탄생은 딘의 "시스템 3부작"의 완성을 의미했습니다. MapReduce(내결함성 컴퓨팅)에서 Bigtable(내결함성 스토리지)로, 그리고 Spanner(전역 일관성)로 이어집니다. 이 세 가지 시스템이 합쳐져 Google의 기술적 우위를 형성합니다. 그들은 검색, 광고, Gmail 등 Google의 핵심 사업을 지원했을 뿐만 아니라, 이후 인공지능의 기반 시설도 제공했습니다. 2025년에 Spanner는 "외부 일관성을 갖춘 직렬화를 글로벌 규모로 달성하기 위해 관계형 데이터 관리를 재구성한 공로"로 ACM SIGMOD 시스템 상을 수상했습니다. 이는 딘과 제마워터가 10년 전에 이룬 업적에 대한 최근의 인정입니다. ### 규모의 꼬리 효과: 시스템 철학의 정점 2013년에 딘과 제마워터는 또 다른 영향력 있는 논문인 "규모에 따른 꼬리"를 발표했습니다. 이 논문에서는 대규모 시스템에서 흔히 발생하지만 간과되는 문제인 **꼬리 지연**을 살펴봅니다. Google 시스템에서는 단일 사용자 요청에도 수백 개의 서버에 대한 액세스가 필요할 수 있습니다. 각 서버의 평균 응답 시간이 빠르더라도, 서버의 1%만 느려도(예: 가비지 수집, 디스크 I/O 또는 네트워크 혼잡으로 인해) 대부분의 사용자 요청 속도가 느려집니다. 사용자 요청은 *모든* 서버의 응답을 기다려야 하며, 가장 느린 서버에 따라 전체 지연 시간이 결정되기 때문입니다. 이 논문의 심오한 통찰력은 지연의 모든 원인을 제거하려는 시도가 "비현실적"이라는 것입니다. 하드웨어는 고장 나고, 네트워크는 혼잡해지고, 운영 체제는 쉴 새 없이 작동할 것입니다. 완벽을 추구하기보다는 "꼬리 내성(tail-tolerant)" 시스템을 구축하는 것이 더 낫습니다. 이는 2000년대 이후 금융 위기 당시 그가 내세웠던 "내결함성(fault-tolerant)" 시스템 구축 철학을 반영하는 개념입니다. 본 논문에서는 꼬리 지연 문제를 해결하기 위한 일련의 기술을 제안합니다. - **헤지 요청**: 동일한 요청을 여러 복제본에 보내고 가장 빠른 응답을 사용합니다. - **바인딩 요청**: 여러 복제본에 요청을 보내지만, 한 복제본이 처리를 시작하면 다른 복제본에 대한 요청을 취소합니다. - **마이크로 파티셔닝**: 데이터를 더 작은 파티션으로 나누어 작업 부하를 머신 간에 더 유연하게 마이그레이션할 수 있습니다. - **선택적 복제**: 자주 액세스하는 데이터에 대한 복제본을 더 많이 만들어 부하를 분산합니다. 이러한 기술의 핵심 아이디어는 중복성과 지능형 스케줄링을 통해 신뢰할 수 없고 속도가 고르지 않은 하드웨어에 고성능의 탄력적인 서비스를 구축하는 것입니다. 2025년에 "The Tail at Scale"은 "시간의 시험을 견뎌낸" 공로를 인정받아 ACM SIGOPS 명예의 전당 상을 수상했습니다. 이 논문은 구글의 시스템 설계에 영향을 미쳤을 뿐만 아니라, 업계 전체의 고전이 되었습니다. ### 딘과 제마워터: 전설적인 협업 딘의 이야기를 할 때, 산제이 곰월트와의 협업을 언급하지 않을 수 없습니다. 그들은 MapReduce 논문의 *유일한* 두 저자이고, Bigtable과 Spanner의 핵심 설계자이며, "The Tail at Scale"의 공동 저자입니다. 그들은 DEC에서 협업을 시작했고, Google에서는 "2000년 위기"를 함께 헤쳐나갔으며, 향후 20년 동안 Google의 기술 기반을 함께 구축했습니다. 2012년에 두 사람은 "구글의 혁신적인 소프트웨어 인프라에 대한 구상, 설계 및 구현"을 인정받아 ACM 컴퓨팅 어워드를 공동 수상했습니다. 두 사람 모두 2009년에 미국 공학 아카데미 회원으로 선출되었습니다. 두 사람의 협력은 "구글을 구하고 현대 인터넷을 발명한 우정"으로 묘사되었습니다. 하지만 이러한 협력으로 인해 흥미로운 문화 현상인 "제프 딘 팩트"가 생겨났습니다. ### "제프 딘 밈": 감탄과 후회 2007년 만우절 무렵, 구글 내부에서는 제프 딘에 대한 일련의 농담이 돌기 시작했는데, "척 노리스 농담"을 모방한 것이었습니다. 예를 들어, 이러한 농담은 딘의 기술적 능력을 과장했습니다. - "제프 딘은 바이너리 코드를 직접 작성했고, 소스 코드는 다른 사람들이 읽을 수 있는 문서일 뿐이었습니다." - "제프 딘의 키보드에는 Ctrl 키가 없습니다. 그가 항상 모든 것을 통제하고 있기 때문입니다." - "컴파일러가 제프 딘에게 경고하지 않을 겁니다. 제프 딘이 컴파일러에게 경고할 겁니다." "진공 상태에서 빛의 속도는 매우 느렸지만, 제프 딘은 주말 한 번 만에 물리학을 최적화했습니다." 이런 밈은 구글 내부에서 빠르게 퍼져나갔고, 나중에는 기술 산업 전체로 퍼졌습니다. 이는 엔지니어들이 딘을 얼마나 존경하는지를 보여줍니다. 그는 뛰어난 기술 전문가일 뿐만 아니라, 어떤 문제든 해결할 수 있는 "코드의 신"이기도 했습니다. 하지만 이러한 밈에는 문제점도 있습니다. "제프가 산제이보다 낫다"는 인상을 주기 때문입니다. 사실, 딘과 제마워터의 기여는 동등했으며, 그들의 협력은 상호 보완적이었습니다. 이 밈을 만든 사람은 나중에 후회를 표하며 "유일한 이유는 '제프'라는 이름이 '더 흥미로워 보였기 때문"이라고 말했다고 합니다. 이런 세부 사항은 대중의 인식과 실제 역사 사이의 차이를 드러냅니다. 딘의 전설은 한 사람의 쇼가 아니라 20년 이상 지속된 협업의 결과입니다.
스레드를 불러오는 중
깔끔한 읽기 화면을 위해 X에서 원본 트윗을 가져오고 있어요.
보통 몇 초면 완료되니 잠시만 기다려 주세요.