분산 데이터베이스의 설계와 진화 — Peter Mattis

URL: https://www.youtube.com/watch?v=0GzwuYGvKA4 원문 제목: Distributed databases with Peter Mattis 날짜: 2026-10-01 채널: pragmaticengineer

---

메타데이터

• 출연 인물: Peter Mattis — Cockroach Labs 공동창업자·CTO, Google의 Gmail 저장·검색 시스템과 Colossus 분산 파일 시스템 초기 설계 참여자
• 주제: 분산 스토리지와 데이터베이스의 차이, B-tree와 캐시 지역성, CockroachDB의 자동 샤딩·강한 일관성·Raft, AI 시대의 소프트웨어 엔지니어링
• 처리 기준: 영어 자동 자막 전체 검토 후 한국어로 재구성

📌 핵심 질문 / 분산 시스템 설계를 관통하는 핵심 논점

==분산 시스템의 성능과 신뢰성은 추상적인 ‘클라우드’가 아니라 데이터 구조, 하드웨어 지연, 복제·합의 알고리즘, 애플리케이션의 사용 방식까지 끝까지 내려가서 설계할 때 얻어진다. AI는 이 깊은 전문성을 대체하기보다 증폭하므로, 엔지니어의 야망·검증 수준·학습 속도를 함께 끌어올려야 한다.==

• Gmail, Colossus, Spanner, CockroachDB는 서로 다른 문제를 풀지만 모두 저장 형식과 장애 모델을 정확히 정의하는 데서 출발했다.
• B-tree는 작은 배열의 캐시 친화성에서 출발해 데이터베이스 인덱스, 분산 키 공간, 저장 엔진에 반복해서 등장한다.
• 강한 일관성과 장애 복구는 세 개 이상의 복제본, 쿼럼, 합의 프로토콜, 지역 간 물리적 지연을 함께 고려해야 한다.
• AI 에이전트는 생산량을 폭발시키지만 테스트·성능·보안 검증을 스스로 충분히 수행하지 않으므로 강한 가드레일과 전문적인 리뷰가 필요하다.

Peter Mattis의 경력은 한 사람이 저수준 자료구조, 대규모 저장 시스템, 데이터베이스 제품, AI 보조 개발을 어떻게 연결하는지 보여준다. 1990년대 대학에서 시작한 그래픽 편집기 작업은 Google의 Gmail과 빌드 시스템으로 이어졌고, GFS의 한계를 넘기 위한 Colossus 설계 경험은 CockroachDB의 분산 데이터베이스 아키텍처로 이어졌다. 핵심은 새로운 이름의 기술을 좇는 것이 아니라, 실제 프로파일·장애·물리적 한계를 관찰하고 더 적합한 데이터 구조와 운영 모델을 적용하는 태도다.

1. 호기심과 순진함이 대규모 시스템 경력으로 이어진 과정

게임과 주변의 컴퓨터를 만지작거리던 호기심, 문제의 본질을 직접 파고드는 습관, 다른 사람이 같은 아이디어를 발표해도 구현을 멈추지 않는 태도가 이후의 시스템 작업을 가능하게 했다.

1.1. 컴퓨터를 선택하게 된 계기와 첫 제품

1. 가정용 컴퓨터와 게임에서 시작한 관심

   1. Peter의 어머니가 IBM에서 프로그래밍을 했고, 집에는 Apple II Plus와 Apple IIGS가 있었다.
   2. 서점에서 BASIC 책이나 잡지를 구해 프로그램을 직접 입력하고, 무엇을 하는지 완전히 이해하지 못해도 입력과 결과 사이의 관계를 실험하는 과정에 빠졌다.

2. 기계공학에서 컴퓨터과학으로의 전환

   1. 아버지를 따라 기계공학을 전공으로 선택했지만, 한 문제에 여섯 페이지가 필요한 기계공학 과제와 동시에 수강한 CS 과목을 비교하며 잘못된 분야에 있다는 사실을 깨달았다.
   2. 다른 학생들이 어려워하던 CS 과제가 자신에게는 훨씬 쉽게 느껴졌고, 첫 학기 뒤 전공을 바꿨다.

3. 대학에서 만든 그래픽 편집기

   1. 룸메이트와 컴파일러 관련 수업을 듣던 중 과제 대신 재미있는 프로젝트를 찾았고, 고등학교 시절 저널리즘 경험과 컴퓨터 그래픽 관심을 결합해 Adobe Photoshop 같은 프로그램을 만들기 시작했다.
   2. 그래픽 라이브러리와 렌더링·그리기·자료구조를 논문과 실험으로 직접 익혔으며, GTK는 이후 크게 발전했다.
   3. 공개 직전 Usenet 그래픽 그룹에 다른 사람이 “같은 프로그램을 이미 만들었고 모든 기능을 구현했다”고 발표했지만, 그 사람이 실제 제품을 내놓지 않자 작업을 계속해 공개했다.

1.2. 아이디어보다 실행을 우선하는 창업 감각

1. 선점 발표가 실행을 대체하지 못한다

   1. 세상에는 같은 아이디어를 가진 사람이 대개 여러 명 있고, 실제로 작업을 시작하는 사람은 그보다 적다.
   2. 경쟁자가 같은 아이디어를 발표했다는 사실보다 구현·출시·시장 대응을 계속하는 것이 중요하며, 경쟁 자체를 두려워하지 말고 즐겨야 한다.

2. 초기 오픈소스의 사용자 가치

   1. 당시 무료·오픈소스 소프트웨어가 지금만큼 일반적이지 않았지만, GIMP는 비싼 Photoshop을 살 수 없던 사람에게 기능을 제공하면서도 불법 복제를 요구하지 않았다.
   2. 훗날 일부 소프트웨어 엔지니어가 GIMP 코드를 읽으며 프로그래밍을 배웠다고 말했고, Peter는 30년 전 자신의 코드가 그들에게 학습 재료가 됐다는 사실을 뜻밖의 영향으로 받아들였다.

2. Google에서 Gmail·빌드 시스템·Colossus를 만든 방식

Google의 초기 대규모 시스템은 기존 인프라를 활용하되, 규모·검색·복구 요구가 한계에 도달할 때마다 저장 모델과 메타데이터 계층을 다시 설계하는 방식으로 성장했다.

2.1. Google 합류와 Gmail의 저장·검색 설계

1. Google에 두 번 초대된 이유

   1. 초기 Google 로고의 첫 버전이 GIMP로 만들어졌고, Google 창업자 Larry Page 또는 Sergey Brin이 Peter를 찾아 2001년 면접을 제안했다.
   2. 당시 Google이 세 살이었지만 샌프란시스코에서 Mountain View까지 통근하기 싫어 첫 제안을 거절했다. 다른 스타트업에서 1년을 보낸 뒤 다시 제안을 받아 2002년 4월 1일 입사했다.

2. 코드명 Caribou와 Gmail의 충격적인 저장 용량

   1. Google의 이메일 프로젝트는 처음에 Gmail이라는 이름이 아니라 Caribou라는 내부 코드명으로 불렸고, Peter는 백엔드의 스레딩·메시지 저장·인덱싱을 맡았다.
   2. 2004년 4월 1일 출시 당시 무료 이메일 서비스가 수 메가바이트에서 수십 메가바이트를 제공하던 상황에 1GB 안팎의 저장 공간과 즉각적인 검색을 제공해 만우절 농담처럼 보였다.
   3. Google File System(GFS)의 대규모 분산 파일 시스템과 기존 검색·검색 결과 회수 기술을 바탕으로 프로토타입을 만들고, 이후 핵심 부분을 다시 작성했다.

3. 메일 스레딩과 B-tree

   1. Gmail은 처음부터 메시지 스레딩을 채택했으며, 메시지 ID나 제목을 스레드 ID와 연결하고 스레드별 읽지 않은 메시지 수를 관리해야 했다.
   2. 이 매핑과 카운터에는 B-tree가 사용됐고, 역색인(inverted index)도 함께 작동했다. 저장 시스템은 단순히 메시지를 쌓는 것이 아니라 검색·정렬·상태 갱신을 동시에 지원해야 했다.

4. 무료 서비스의 비용과 초대제 모델

   1. 기존 광고 기능을 이메일에 붙일 수 있다는 아이디어가 나왔고, Paul Buchheit가 기존 광고 기능을 빠르게 통합하면서 거대한 사업 모델이 형성됐다.
   2. 초대제는 수요와 부하를 통제하는 동시에 “Gmail 초대장을 구할 수 있는가”라는 사회적 열기를 만들었다. 이는 인프라 용량 관리와 마케팅 효과를 한 번에 달성했다.

2.2. Google 2에서 Google 3, Blaze·Bazel·Buck으로

1. 거대한 Makefile의 한계

   1. Google 2의 빌드 시스템은 하나의 거대한 Makefile과 일부 하위 Makefile로 구성돼 의존성을 사람이 저수준으로 직접 작성해야 했다.
   2. Make는 의존성 선언 자체는 가능하지만 어셈블리 언어처럼 세밀하고 실수하기 쉬워, 누락된 의존성이 빌드 오류나 재현성 문제를 만들 수 있었다.

2. 더 높은 수준의 의존성 표현

   1. Peter는 Google 3의 기반을 만들며 간소화된 Python 형태의 build file을 도입했고, Gconfig가 사람이 쓰기 어려운 거대한 Makefile을 생성하게 했다.
   2. 시간이 지나 이 접근은 내부적으로 Blaze가 됐고, 외부에서는 Bazel로 공개됐다. Facebook으로 옮긴 사람들은 유사한 필요를 Buck으로 발전시켰다.
   3. 의존성을 더 높은 수준의 의미로 작성하면 시스템이 캐시·증분 빌드·의존성 갱신 엔진을 직접 최적화할 수 있어 대규모 저장소에서 성능과 유지보수성이 함께 좋아진다.

2.3. GFS의 다음 세대, Colossus

1. 분산 파일 시스템의 역할

   1. Colossus는 로컬 디스크가 아닌 여러 서버의 하드디스크와 SSD에 파일을 저장하고, 클라이언트가 네트워크를 통해 접근하는 Google의 2세대 분산 파일 시스템이다.
   2. S3처럼 이름 중심의 제한된 계층을 제공하며, 일반 POSIX 파일 시스템처럼 완전한 디렉터리·권한 모델을 처음부터 제공하지는 않았다.
   3. 파일을 복제해 장애에도 데이터를 유지하고, 이후에는 SSD와 확장된 권한 기능을 포함하는 여러 세대의 시스템으로 발전했다.

2. 복제에서 Reed–Solomon 삭제 부호화로

   1. GFS의 삼중 복제는 같은 데이터를 세 배 저장해야 했지만, Colossus는 Reed–Solomon 기반 삭제 부호화(Erasure Coding)를 도입해 더 적은 공간으로 더 높은 수준의 복원력을 얻었다.
   2. 직관적으로 데이터 조각과 패리티 조각을 여러 머신에 나누어 보관하고, 일부 조각이 사라져도 남은 조각으로 원본을 재구성한다.
   3. Peter가 든 예시는 9개 청크 중 임의의 5개로 데이터를 복구해 4개를 잃어도 복원이 가능한 형태다. 실제 파라미터는 시스템·시점에 따라 다르지만, 핵심은 단순 복제보다 저장 효율과 장애 허용을 함께 최적화하는 데 있다.

3. GFS의 단일 마스터 병목과 Bigtable 메타데이터

   1. GFS는 약 1,000대 규모의 클러스터에서 확장성 한계가 나타났고, Google은 10,000대까지 확장할 필요가 있었다.
   2. 파일 이름, 파일을 구성하는 청크 목록, 각 청크의 위치와 복구 상태를 관리하는 메타데이터가 단일 마스터에 집중되는 것이 병목이었다.
   3. Colossus는 Bigtable을 메타데이터 저장소로 활용해 분산 마스터를 구성했다. 파일은 약 64MB 청크로 나뉘며, 마스터는 주기적으로 전체 메타데이터를 훑어 복구 작업을 수행한다.

4. 순환 의존성을 감수한 부트스트랩

   1. Bigtable의 가장 큰 사용자가 GFS 위에서 동작하는 Bigtable인데, Colossus도 메타데이터를 Bigtable에 저장해야 하는 순환 의존성이 생겼다.
   2. 초기에는 Colossus가 사용하지 않는 기반 Bigtable을 따로 두고, Colossus가 그 위에서 메타데이터를 관리하며, 일반 Bigtable은 다시 Colossus 위에서 동작하는 구조로 출발했다.
   3. 완벽한 최종 구조를 기다리지 않고 부트스트랩용 해킹을 인정하면 핵심 시스템을 더 빨리 출범시킬 수 있고, 나중에 기반 계층을 교체할 수 있다.

2.4. 물리적 지연을 숨길 수 없는 분산 시스템

1. 처리량과 지연 시간은 같은 말이 아니다

   1. GCS와 S3 같은 대규모 객체 저장소는 높은 처리량을 제공하지만 하드디스크 기반 첫 읽기 지연은 약 20~30ms 수준일 수 있다.
   2. 하드디스크의 접근은 대략 5~10ms, NVMe SSD는 약 30~50µs 수준이며 1ms는 1,000µs이므로 하드웨어 세대만 바뀌어도 시스템 설계의 전제가 달라진다.
   3. Google·Amazon의 같은 가용 영역 내부 네트워크 왕복도 과거의 밀리초 수준에서 약 100µs 수준으로 내려왔다.

2. 속도의 한계는 캐시와 빛의 속도까지 내려간다

   1. 멀티스레드 시스템은 잠금과 동기화를 줄이거나 없애고, 레지스터·L1·L2·L3 캐시·메모리·디스크의 계층을 고려해 데이터 배치를 설계해야 한다.
   2. 데이터를 프로그램 전체에서 무작위로 접근하면 캐시 지역성이 무너져 하드웨어 성능을 소프트웨어가 사용하지 못한다. 고빈도 거래 시스템은 이 차이를 매일 최적화하지만 많은 애플리케이션은 점진적으로 성능을 잃는다.
   3. 가용 영역·리전 간 지연은 광섬유 속의 빛에 제한된다. 대륙 간 초저지연 통신은 대기권 밖을 통과하는 Starlink 경로가 광섬유보다 빠를 수 있고, 뉴욕–시카고처럼 거리가 충분히 길지 않은 구간은 마이크로파 링크가 유리할 수 있다.

3. 반복해서 등장하는 B-tree와 자료구조 최적화

B-tree가 강력한 이유는 트리라는 이름보다 작은 데이터를 연속 배열에 모아 캐시 친화적으로 처리하고, 그 묶음을 계층적으로 확장하기 때문이다. 이 원리는 STL map 대체, Go 해시 테이블, 데이터베이스 인덱스와 분산 샤딩에 공통으로 나타난다.

3.1. STL map을 대체한 캐시 친화적 B-tree

1. 기존 균형 이진 트리의 메모리 비용

   1. Google 내부 Gaia 시스템에서 정수 사용자 ID를 사용자 메타데이터에 매핑하는 작업에 STL map을 널리 사용했지만, 프로파일에서 큰 메모리 사용량이 드러났다.
   2. STL map은 레드-블랙 트리 같은 균형 이진 트리이며, 각 노드가 값과 두 개의 포인터를 가진다. 4바이트 정수 하나를 저장하는 데 포인터 오버헤드가 과도할 수 있다.
   3. 트리를 따라 내려갈 때마다 서로 다른 캐시 라인을 읽어야 하므로, 메모리 사용량과 캐시 미스가 모두 성능을 제한했다.

2. B-tree의 작은 배열 모델

   1. 여덟 개 정도의 항목이라면 트리 노드 여덟 개보다 정렬된 배열 하나가 더 빠르다. 선형 스캔이나 이진 검색을 사용할 수 있고, 작은 크기에서는 선형 스캔이 오히려 빠를 수 있다.
   2. 항목이 아홉 개가 되면 배열을 두 덩어리로 나누고, 두 덩어리를 가리키는 부모 노드를 만든다. 삽입 때 한 노드가 가득 차면 4개와 5개처럼 분할한 뒤 부모를 갱신한다.
   3. 많은 키를 한 노드에 넣으므로 포인터 수가 줄고 공간 지역성이 높아진다. STL map의 포인터 안정성이 필요한 경우에는 완전히 대체할 수 없지만, 그 요구가 없으면 더 작고 빠른 구조가 된다.

3.2. Go Swiss table과 외부 기여

1. 해시 테이블의 두 가지 기본 충돌 처리

   1. 키를 정수 해시로 바꿔 버킷 배열에 넣고 충돌한 항목을 연결 리스트로 묶는 chaining은 단순하지만 포인터 추적 비용이 있다.
   2. Open addressing은 별도 연결 리스트 대신 다음 슬롯을 탐색하거나 다시 해시해 배열 내부에 저장한다. 데이터가 연속적으로 배치될수록 캐시 친화성이 좋아진다.

2. Swiss table을 Go 런타임에 적용한 과정

   1. Google 스위스 오피스에서 나온 것으로 알려진 Swiss table 논문과 구현을 읽고, Go의 이미 고도로 최적화된 map 런타임을 능가할 수 있는지 살폈다.
   2. 방갈로르로 가는 장거리 비행 중 문제를 붙잡고, 회사의 실제 사용 사례에 맞는 구현을 만들어 일부 벤치마크에서 더 빠른 결과를 얻었다.
   3. Go 이슈 트래커에서 다른 사람들이 제안했던 아이디어와 런타임 팀의 도움을 합쳐 대부분의 벤치마크에서 더 빠른 구현을 만들었고, Go 팀이 런타임에 맞게 다듬어 완성했다.
   4. 외부 기여는 기존 코드를 무시하고 처음부터 다시 쓰는 일이 아니라, 프로파일에서 병목을 찾고 논문·이슈 트래커·실험 결과를 연결해 개선안을 증명하는 과정이다. CRC(순환 중복 검사) 어셈블리 구현을 Intel 자료에서 적용한 동료의 사례도 같은 흐름에 속한다.

3.3. “어디서나 B-tree 또는 해시 테이블”이라는 관점

1. 데이터베이스 인덱스

   1. 이메일 주소처럼 정렬된 순서로 범위를 훑어야 하는 인덱스는 일반적으로 B-tree를 사용한다. 해시 인덱스도 존재하지만 순서와 범위 질의에는 B-tree가 적합하다.
   2. 1980년대의 “The Ubiquitous B-tree”라는 이름 그대로 B-tree는 단일 노드 데이터베이스부터 분산 저장 시스템까지 반복해서 등장한다.

2. 분산 키 공간

   1. 분산 시스템의 전체 키를 하나의 연속된 키 공간으로 생각하고, 연속된 범위(span)를 여러 노드에 배정하면 “어느 노드에 이 범위가 있는가”를 찾는 상위 인덱스가 필요하다.
   2. 이 인덱스는 이름이 B-tree가 아닐 수 있지만, 범위를 정렬해 분할하고 상위 노드가 하위 범위를 가리킨다는 점에서 B-tree와 같은 구조적 직관을 갖는다.

4. CockroachDB: 분산 저장소에서 분산 데이터베이스로

Google의 저장 시스템 경험과 Viewfinder·Square에서 마주친 제품 요구가 CockroachDB의 설계로 이어졌다. 핵심은 애플리케이션 개발자가 수동 샤딩과 분산 트랜잭션을 직접 구현하지 않도록 데이터베이스가 복잡성을 맡는 것이다.

4.1. Colossus와 Spanner, 저장소와 데이터베이스의 차이

1. 분산 파일 시스템의 대상

   1. Colossus는 수십 MB에서 GB 규모의 큰 파일과 append-only 파일을 저장하며, 파일 전체를 제자리에서 갱신하지 않는다.
   2. 대규모 파일을 청크로 쪼개고 복제·삭제 부호화·메타데이터 복구를 수행하는 것이 주된 문제다.

2. 분산 데이터베이스의 대상

   1. 데이터베이스는 SQL이나 관계형 모델에서 수십억 개 행, 타입이 있는 열, 작은 레코드, 인덱스, 동시 트랜잭션을 처리한다.
   2. Spanner는 분산 데이터베이스이고 Colossus는 분산 저장소이며, Spanner는 Colossus 같은 저장 계층 위에 구축된다.
   3. Colossus의 불변·append-only 저장 방식은 데이터베이스가 로그 구조 병합 트리(LSM tree)를 채택하도록 이끌었다. Bigtable에서 나온 아이디어가 LevelDB, RocksDB로 널리 퍼졌고, Peter는 이를 다시 구현한 Pebble을 Cockroach Labs에서 사용한다.

4.2. Viewfinder와 Square에서 CockroachDB를 분리하다

1. Viewfinder의 실패와 학습

   1. 2012년 모바일 사진 공유 스타트업 Viewfinder를 공동창업했지만 Instagram과 경쟁할 바이럴 성장·시장 진입 전략을 확보하지 못했다.
   2. 회사는 Square에 인수됐지만 제품이나 IP보다 기술 인재를 위한 acqui-hire에 가까웠고, 투자금은 대체로 투자자에게 돌려줬다.
   3. Viewfinder 시절부터 Bigtable·Spanner처럼 강력한 내부 데이터베이스를 원했지만, 모바일 사진 공유 제품을 만드는 동안 직접 분산 데이터베이스를 만드는 것은 우선순위가 아니어서 설계를 보류했다.

2. Square에서 다시 나타난 같은 문제

   1. Peter, 대학 룸메이트 Spencer, Ben Darnell은 Square에서 데이터 저장 시스템의 한계를 다시 마주쳤고, Spencer가 경영진을 설득해 분산 데이터베이스 설계를 파트타임으로 실험했다.
   2. 외부의 관심이 커지자 세 사람은 프로젝트를 회사로 분리했고, Cockroach Labs를 시작하며 즉시 VC 투자를 받았다.
   3. Peter는 VC가 시장·채용·전략을 함께 보는 지적이고 유용한 멘토가 될 수 있다고 평가하며, Viewfinder에서 투자를 받은 방식은 결과적으로 권하지 않지만 Cockroach Labs에서는 초기 투자를 긍정적으로 활용했다고 말했다.

3. 이름과 장애 복원력

   1. Cockroach라는 이름은 바퀴벌레가 핵전쟁 뒤에도 살아남는다는 이미지처럼 데이터베이스가 노드·리전 장애에도 살아남기를 바라는 뜻에서 붙였다.
   2. 실제 CockroachDB는 노드 하나를 죽이거나 전체 리전을 중단해도 워크로드를 계속 처리하는 “performance under adversity” 실험을 수행했고, 데이터센터 화재나 지역 전원 장애 뒤에도 다른 시스템이 멈추는 동안 계속 동작한 고객 사례가 있다.

4.3. 수동 샤딩에서 자동 범위 분할로

1. 수동 샤딩의 애플리케이션 부담

   1. 단일 노드 PostgreSQL이 한 머신의 크기 한계에 도달하면 흔히 10·20·100개의 샤드로 나누지만, 개발자가 키를 어느 샤드로 보낼지와 재분배를 직접 구현해야 한다.
   2. 애플리케이션 개발자가 분산 데이터베이스 개발자로 변해 분산 트랜잭션·보조 인덱스·리밸런싱을 직접 만들게 되며, 구현 품질과 운영 부담이 떨어질 수 있다.

2. 해시 샤딩과 리샤딩

   1. 사용자 ID를 해시해 고정된 100개 샤드 중 하나에 넣는 방식은 균등 분포를 쉽게 얻지만, 샤드가 가득 차면 전체 매핑을 바꾸고 데이터를 복사해야 한다.
   2. 해시 테이블을 확장할 때 새 테이블을 만들고 모든 항목을 옮기는 것과 같은 문제이며, 운영 중 데이터 이동과 메타데이터 갱신이 부담스럽다.
   3. 일관된 해싱(consistent hashing)은 노드를 추가할 때 각 샤드에서 일부 데이터만 이동시키지만, CockroachDB는 Cassandra식 해시 링보다 Bigtable·Spanner·HBase에 가까운 연속 키 범위 분할을 사용한다.

3. 범위 기반 자동 분할

   1. 모든 키를 하나의 연속 공간으로 보고 연속 범위를 여러 노드에 배정하면, 범위가 커질 때 해당 범위를 잘라 다른 노드로 옮길 수 있다.
   2. 상위 인덱스가 범위와 노드를 매핑하고 자동으로 분할·이동하므로, 애플리케이션은 샤드 위치를 직접 추적할 필요가 없다.
   3. 범위 인덱스의 구조는 B-tree와 닮았고, 데이터 구조의 선택이 운영 기능과 직접 연결된다.

4.4. ACID와 강한 일관성

1. 트랜잭션의 네 가지 속성

   1. 원자성(Atomicity)은 여러 변경을 전부 커밋하거나 전부 롤백해 부분 실행을 없앤다.
   2. 내구성(Durability)은 기록이 완료된 뒤 장애가 나도 데이터가 사라지지 않도록 한다.
   3. 격리성(Isolation)은 여러 트랜잭션을 동시에 실행하면서도 직렬로 실행한 것처럼 보이게 한다. 직렬가능성(Serializability)과 더 강한 선형화 가능성(Linearizability)이 안전한 동시성의 기준이 된다.
   4. 일관성(Consistency)은 애플리케이션의 불변식과 데이터베이스 규칙을 지키는 의미로 사용되며, 격리성과 함께 애플리케이션이 단순한 실행 모델을 유지하게 한다.

2. 약한 일관성의 애플리케이션 비용

   1. 최종적 일관성(Eventual Consistency)에서는 쓰기가 모든 복제본에 도달하기 전에 읽기가 수행될 수 있다.
   2. 주 복제본에 쓴 뒤 보조 복제본에서 읽으면 최신 값이 보이지 않는 상황이 대표적인 예이며, 신용카드 잔액처럼 잠깐의 지연도 문제가 될 수 있다.
   3. 애플리케이션이 이런 지연과 재시도를 직접 감안해야 하므로 데이터베이스가 빠른 대신 애플리케이션의 복잡성과 결함 가능성이 커진다.

3. CockroachDB의 강한 읽기 보장

   1. CockroachDB는 쓰기 직후 어느 노드에서 읽더라도 방금 쓴 값을 관찰할 수 있는 강한 일관성을 목표로 한다.
   2. 복제본에 기록하는 비용을 시스템이 부담하므로 애플리케이션은 복제본 위치나 복제 지연을 직접 관리하지 않아도 된다.
   3. 강한 일관성은 공짜가 아니다. 여러 리전 사이의 왕복 지연과 합의 비용을 고려해야 하므로, 대화를 여러 번 왕복하는 쿼리보다 읽기를 병렬로 모으고 한 번에 쓰는 접근이 중요하다.

4.5. Raft 합의와 장애 도메인

1. 두 복제본으로는 안전한 합의가 어렵다

   1. 두 노드 중 하나가 장애 난 뒤 남은 노드는 상대 노드가 마지막 쓰기를 받았는지 알 수 없다.
   2. 쓰기를 되돌리면 데이터가 사라질 수 있고, 유지하면 아직 합의되지 않은 데이터가 확정될 수 있어 어느 쪽도 안전하지 않다.

2. 세 개 이상의 복제본과 쿼럼

   1. 합의는 최소 세 개 복제본이 필요하며, 일반적인 설정은 세 개다. 일부 시스템 테이블이나 높은 내구성을 요구하는 고객은 다섯 개·일곱 개를 선택할 수 있다.
   2. 평상시 읽기는 한 복제본에서 처리하고, 쓰기는 복제본 전체에 반영한다. 장애가 발생하면 둘 이상의 복제본을 읽어 이전 상태를 결정하는 합의 읽기를 수행한다.
   3. 복제본을 늘리면 저장 공간과 쓰기 비용이 커지고, 서로 다른 리전에 배치하면 지진·전원 장애·네트워크 단절을 견디는 대신 물리적 지연이 커진다.

3. Raft의 실용적 의미

   1. Paxos는 최초의 대표적인 합의 프로토콜이지만 구현이 어렵기로 유명하고, Raft는 이를 대체하거나 변형한 이해하기 쉬운 합의 접근으로 자리 잡았다.
   2. 합의의 본질은 “어떤 변경이 발생했는가”를 복제본들이 동일하게 결정하는 것이다. CockroachDB는 그 결과로 특정 노드·리전 장애 후에도 데이터의 확정 여부를 재구성한다.

5. 미션 크리티컬 시스템과 신뢰의 운영 경제학

데이터베이스가 미션 크리티컬하다는 말은 단순히 편리한 SaaS가 아니라, 멈추면 거래·수익·고객의 생활·기업 평판이 즉시 손상되는 Tier 0 시스템을 뜻한다.

5.1. 장애 뒤에 찾아오는 분산 데이터베이스 수요

1. 재해가 도입 결정을 만든다

   1. 많은 고객은 새로운 데이터베이스의 기능보다 심각한 장애를 경험한 뒤 CockroachDB에 연락한다.
   2. 한 대형 은행은 날씨로 한 리전 전체의 전원이 끊긴 뒤 CEO가 “다시는 이런 방식으로 운영하지 말라”는 요구를 내렸고, 이 요구가 조직 전체에 전달됐다.
   3. AWS 인스턴스 크기 한계에 도달한 초기 고객은 단일 데이터베이스를 수동 샤딩하는 대신 자동 분산으로 전환할 이유를 얻었다.

2. 미션 크리티컬의 구체적 사례

   1. 거래 시스템과 은행 시스템은 중단 자체가 기업의 존립·고객 자산·규제 책임에 영향을 준다.
   2. DoorDash의 주문·배달 시스템이나 쇼핑 카트도 사용자는 단순 기능으로 보지만, 중단되면 시간당 수십만~수백만 달러의 손실이 발생할 수 있다.
   3. Gmail과 검색도 사람들의 업무와 커뮤니케이션에 깊이 들어가 있어 사용자는 별도 통신 수단을 준비하지 않는다. 검색 장애는 광고 매출의 즉각적인 감소뿐 아니라 “이 서비스는 믿을 수 없다”는 평판 손상으로 이어진다.

5.2. 안정성은 기능이 아니라 신뢰 계약이다

1. 사용자가 걱정하지 않는 상태의 가치

   1. Gmail이 항상 작동한다고 믿으면 사용자는 이메일 외의 예비 연락 수단을 만들지 않는다.
   2. 기업이 이런 수준의 신뢰를 얻으면 사용자는 시스템의 내부 복잡성을 신경 쓰지 않고 업무에 집중할 수 있다.

2. 안정성 투자의 책임

   1. 데이터베이스는 단순히 정상 경로에서 빠른 답을 내는 것보다 장애·화재·지역 정전에서도 데이터를 지키는 능력을 우선해야 한다.
   2. “할머니가 집세를 낼 수 없게 된다”는 식의 구체적인 피해를 상상해야 신뢰와 가용성을 마케팅 문구가 아닌 책임으로 다룰 수 있다.

6. AI가 바꾼 코딩 생산성과 엔지니어링 운영

Peter의 AI 경험은 보일러플레이트 생성이 아니라, 수만 줄의 고성능 코드·설계 탐색·병렬 실험·품질 가드레일까지 포함하는 실전 개발 방식의 변화다.

6.1. 10만 줄의 수작업에서 10,000줄의 30분 생성으로

1. AI 이전의 생산량

   1. CockroachDB 초기 몇 년 동안 공동창업자들과 함께 많은 코드를 작성했고, Peter의 GitHub 최고 기록은 1년에 약 10만 줄이었다.
   2. 2019년 RocksDB의 한계 때문에 저장 엔진을 다시 쓰며 혼자 4만~5만 줄을 밀어붙였고, 그 양을 머릿속에 유지하는 것 자체가 부담이었다.
   3. 업계에서 말하는 엔지니어 생산성은 월 3,000줄, 연 36,000줄 정도만 돼도 좋은 수준인데, 10만 줄은 입력과 이해 양쪽에서 비정상적으로 높은 양이다.

2. 2022~2024년의 손떼기

   1. CTO로서 VP of Engineering과 관리자 팀을 두고, 임원이 직접 코드를 쓰기보다 조직·고객·회의·조정에 집중해야 한다는 조언을 받아들였다.
   2. 2022년부터 2024년까지 핵심 제품 코드에 대한 출력은 크게 줄었고, Swiss table 작업처럼 부수적인 기여는 있었지만 일상적인 코딩 흐름은 끊겼다.

3. AI와 함께 돌아온 생산성

   1. GitHub Copilot의 자동완성에서 시작해 Cursor, Claude Code 계열 도구를 사용하며 모델이 함수 전체를 맞히는 수준을 경험했다.
   2. 추수감사절부터 겨울 휴가까지 4일 동안 CockroachDB의 CPU 수·디스크 수·노드 수 조합을 모두 시험하는 벤치마크 도구를 만들었고, 오랫동안 우선순위를 받지 못하던 실험이 코드로 빠르게 구체화됐다.
   3. 최근 한 달에는 약 30분 동안 고도로 최적화된 Rust 10,000줄 규모의 또 다른 B-tree 구현을 만들었다. 사람이 직접 타이핑할 수 없는 속도지만, Peter는 결과를 데이터베이스 품질의 코드로 다듬는 검증 책임을 여전히 맡는다.

6.2. AI는 코더이면서 설계·학습의 스파링 파트너다

1. 문제 정의를 함께 탐색하기

   1. AI를 정확히 정해진 설계의 실행자만으로 쓰지 않고, “이 문제를 어떻게 풀 수 있는가”를 함께 논의하는 스파링 파트너로 사용한다.
   2. 모델은 항상 맞지 않지만 방대한 지식을 빠르게 조합해 설계 후보를 내고, 사람이 이상한 점을 지적하면 방향을 수정한다.
   3. 전통적인 러버 덕 디버깅처럼 말로 생각을 정리하는 효과에 더해, AI는 대안을 제시하고 반례를 탐색한다.

2. 관리자보다 손을 잡은 테크 리드에 가깝다

   1. Peter는 AI 에이전트 여러 개를 이끄는 일을 대규모 팀의 엔지니어 매니저에 비유했지만, 사람 사이의 갈등·성과평가·관계 관리가 없다는 지적을 받아들였다.
   2. 실제로는 30~40명이 참여하는 조직의 hands-on tech lead 또는 직접 코드를 확인하는 아키텍트에 가깝다.
   3. 일반적으로 5~10개의 세션을 동시에 관리하고, 각 세션이 여러 하위 에이전트를 띄우게 하며, 기차 안에서 세 개의 하위 에이전트로 조사하거나 필요할 때 20~100개의 에이전트를 병렬로 실행한다.

3. 모델 선택과 적대적 리뷰

   1. Claude Desktop·터미널 기반 Claude Code·Codex 데스크톱 앱을 섞어 쓰고, 모델이 설계를 만든 뒤 다른 모델에게 동료의 결과를 적대적으로 검토하게 한다.
   2. 속도가 특별히 중요하지 않으면 모델별 차이를 매번 판단하는 인지 비용을 줄이기 위해 가장 강력한 모델을 선택한다.
   3. 중요한 출시를 앞두고는 최고 성능 모델을 쓰는 비용보다 잘못된 설계와 결함을 발견하지 못하는 비용이 크다고 판단한다.

6.3. 품질·테스트·보안을 생산량과 함께 끌어올리기

1. 에이전트가 자주 생략하는 검증

   1. 코드 생성량이 늘면 결함 수가 함께 늘어날 수 있으므로, 단순한 배포 빈도 증가를 품질 향상으로 착각하면 안 된다.
   2. 에이전트는 테스트를 충분히 작성하지 않고 성능 영향도 세밀하게 살피지 않는 경향이 있어, 명시적인 검증 요구와 강한 피드백이 필요하다.
   3. 인간도 “이제 충분하다”며 테스트를 멈추기 때문에, 에이전트는 오히려 반복 검증을 자동화하기 쉽다는 장점이 있다.

2. 적용해야 할 테스트 기법

   1. 속성 기반 테스트(Property-based testing)로 입력 공간의 일반 규칙을 검증한다.
   2. 메타모픽 테스트(Metamorphic testing)로 입력 변환에 따른 출력 관계를 검증한다.
   3. 결정적 시뮬레이션 테스트(Deterministic simulation testing)로 분산 시스템의 시간·장애·재시도 순서를 재현한다.
   4. 모델에게 이런 기법들을 사용하도록 반복 지시하고, 테스트 커버리지뿐 아니라 성능·보안·운영 실패 시나리오까지 요구해야 한다.

3. 가드레일이 코드 리뷰를 대체하는 방식

   1. 모든 커밋을 보안 전문가나 여러 적대적 에이전트가 검토하도록 하면 보안 결함을 빠르게 찾을 수 있다.
   2. 성능 회귀는 “추가된 명령어가 몇 개인가”처럼 측정 가능한 제약으로 바꿀 수 있다. Peter는 테스트 시점에만 존재하고 프로덕션에서는 컴파일되어 사라지는 zero-overhead 추상화를 만들며 디컴파일 결과를 자동 확인하는 시스템을 사용한다.
   3. 모델은 가드레일 안에서 일하는 것을 잘 받아들이므로, 사람이 모든 줄을 읽는 방식보다 불변식·벤치마크·보안 정책·배포 검사를 자동화하는 편이 확장 가능하다.

4. 코드 리뷰의 미래

   1. AI 이전에는 주니어 엔지니어의 변경에 시니어 엔지니어보다 더 많은 검토를 할 정도로 코드 리뷰가 필수였다.
   2. 모델이 좋아질수록 모든 줄에 동일한 수준의 검토를 하는 대신, 테스트 누락·보안 관행 위반·성능 회귀처럼 위험한 부분에 집중하게 된다.
   3. 컴파일러가 어셈블리를 잘 생성한다고 믿고 대부분의 사람이 어셈블리를 읽지 않는 것처럼, 앞으로는 사람이 소스 코드 전체를 직접 읽기보다 AI와 자동 검증 장치가 생성 결과를 검사할 가능성이 크다.

6.4. 조직 전체와 비엔지니어의 소프트웨어 생산

1. 모든 애플리케이션이 AI로 작성되는 방향

   1. 인간이 비전과 목표를 제시하는 역할은 오래 남겠지만, 코드 자체는 AI가 작성하는 비중이 점점 커질 가능성이 높다.
   2. 손으로 작성한 어셈블리가 남아 있듯 bespoke 소프트웨어도 사라지지 않지만 전체에서 차지하는 비중은 점차 줄어든다.

2. 비엔지니어가 만드는 내부 애플리케이션

   1. Cockroach Labs는 비엔지니어가 애플리케이션을 만들 수 있는 내부 플랫폼을 출시했고, 몇 달 사이 약 500~1,000개의 애플리케이션이 만들어졌다.
   2. HR 팀은 직접 필요한 작은 도구를 만들고, CFO 조직은 예전에는 만들기 어려웠던 대시보드를 구성했다.
   3. 개인도 자신에게 맞는 소프트웨어를 직접 얻는 시대가 올 수 있다. Peter는 소프트웨어가 필요한 아내를 위해 지금까지 직접 만들어주지 못한 것을 자신의 실패로 인정하며, AI가 이 장벽을 낮출 것이라고 기대한다.

3. 디자이너의 PR과 빠른 UX 개선

   1. 디자이너가 Figma에서 목업만 넘기고 개발팀을 기다리는 방식보다 HTML·CSS·JavaScript를 직접 수정해 PR을 만드는 흐름이 가능해졌다.
   2. 이는 핵심 데이터베이스 코드가 아니라 디자이너가 책임지는 UX 영역에서 적용되며, 중간 전달 단계가 줄어들어 작은 회귀와 불편을 즉시 수정할 수 있다.

7. 생산성을 증폭시키는 사람의 역량

AI 시대에 가장 큰 격차는 도구를 켰는지 여부가 아니라, 문제를 구조화하고 결과를 검증하며 도메인 지식을 질문에 녹여낼 수 있는지에서 생긴다.

7.1. 운전·F1·페어 프로그래밍 비유

1. AI 코딩 도구는 운전해야 하는 자동차다

   1. 개발자가 걷고 있을 때 옆에 자동차가 멈춰 서서 태워주지만, 조작법을 모르면 페달을 잘못 밟아 나무에 부딪힐 수 있다.
   2. 따라서 도구를 자연스럽게 쓰게 될 것이라고 기대하지 말고, 어디서 실패하는지 익히며 운전법을 배워야 한다.

2. F1 드라이버의 격차

   1. 에이전트 사용 경험이 많은 엔지니어는 모델이 무너지는 지점을 알고, 빠른 피드백과 검증으로 훨씬 더 강한 속도를 낸다.
   2. 기존에 좋은 소프트웨어 엔지니어였던 사람의 역량 곡선이 AI로 크게 늘어나는 경향이 있지만, 모두에게 동일한 배수가 적용되는 것은 아니다.

3. 페어 프로그래밍에서 연구 보조원 군집으로

   1. 예전에는 한 키보드 앞에 두 엔지니어가 앉아 한 명이 입력하고 한 명이 방향을 제시했다.
   2. 지금은 여러 에이전트가 동시에 실험을 수행하고, 전문 엔지니어는 결과를 비교·반박·재지시하는 연구 책임자처럼 일한다.
   3. 과거 일주일 걸리던 아이디어 실험 여러 개를 동시에 시작할 수 있지만, 실패한 실험을 빠르게 버리는 심리적 여유가 필요하다.

7.2. 전문성이 AI 출력의 깊이를 결정한다

1. 도메인 전문가의 증폭

   1. 테런스 타오가 AI와 야코비안 추측을 논의한 대화는 AI가 단순한 자동완성기가 아니라 전문가의 사고를 확장하는 동료처럼 작동할 수 있음을 보여준다.
   2. 수학·분산 데이터베이스처럼 맥락이 깊은 분야에서는 질문의 순서와 용어를 아는 사람이 훨씬 더 유용한 결과를 끌어낸다.

2. 마법사와 주문의 비유

   1. 전문가는 자신이 다루는 영역의 마법사처럼 저장 계층·네트워크·자료구조·런타임·장애 모델을 올바른 순서로 요청한다.
   2. 분산 데이터베이스 전문성이 없는 사람이 “CockroachDB 같은 시스템을 만들어라”고 하면 겉모양은 나오지만 내부는 비어 있는 결과가 되기 쉽다.
   3. 반대로 전문가는 무엇을 검증해야 하는지 알고, 모델이 만든 구조에서 빠진 쿼럼·불변식·성능 경로를 짚어 짧은 시간 안에 실제 시스템에 가까운 결과를 만든다.

7.3. 중견·시니어 엔지니어를 위한 학습법

1. AI를 가장 접근성 높은 개인 튜터로 사용하기

   1. Google에서 Jeff Dean과 Sanjay Gawande의 변경 목록을 읽으며 고성능·우아한 코드를 관찰했던 학습법을 AI로 확장할 수 있다.
   2. 기존 코드의 작동 원리, 설계 이유, 대안, 다이어그램을 요청하고 “다섯 살에게 설명하듯”, “열 살에게 설명하듯”, 다른 언어로 설명해 달라고 수준을 바꿔가며 질문한다.
   3. AI는 코드를 다른 이해 수준의 언어로 번역해 주므로, 단순히 복사하는 대신 이해가 될 때까지 계속 질문해야 한다.

2. 현재 업무 밖으로 호기심 확장하기

   1. Gmail을 만들면서 Google 검색과 Bigtable 내부에 호기심을 가졌던 것처럼, 현재 담당하지 않는 시스템의 설계 이유도 질문해야 한다.
   2. 결제 회사의 엔지니어라면 결제 도메인 지식을, 분산 데이터베이스를 다루면 저장·네트워크·운영 도메인을 함께 학습할 수 있다.
   3. 충분히 이해한 뒤에는 “이 설계를 바꾸면 어떻게 되는가”를 묻고, 학습자에서 기여자로 이동한다.

3. 개인 주도 학습

   1. 새로운 모델과 도구를 설명해 줄 사람이 항상 최신 상태일 수 없으므로, 누군가의 교육을 기다리기보다 직접 사용하며 학습해야 한다.
   2. Peter는 AI와 함께 만든 지난 1년 동안 이전 5년보다 더 많이 배웠다고 느꼈다. 이는 경력이 긴 엔지니어도 도구를 통해 학습 속도를 다시 높일 수 있다는 사례다.

주요 발언 모음

“같은 아이디어를 가진 사람은 세상에 열두 명쯤 있을 것이다. 중요한 것은 그 아이디어를 실제로 작업하는가이다.”

“작은 데이터 묶음이라면 트리가 아니라 정렬된 배열이 가장 빠를 수 있다.”

“분산 데이터베이스를 만들면 애플리케이션 개발자가 데이터베이스 개발자가 되는데, 그 일을 잘하지 못한 채 떠맡게 된다.”

“모델은 테스트에 조금 게으르고 성능을 충분히 들여다보지 않는다. 하지만 강하게 지도하면 이 문제는 생각보다 쉽게 고칠 수 있다.”

“AI는 기존 전문성을 증폭한다. 올바른 질문과 검증을 아는 도메인 전문가에게서 훨씬 더 마법 같은 결과가 나온다.”

“앞으로는 우리가 하는 모든 일에 대해 더 야심 차야 한다. 더 높은 성능, 품질, 보안을 요구해야 한다.”

핵심 데이터 & 수치

• Google 합류 시점: 2002년 4월 1일, Google이 설립된 지 약 3년 뒤
• Gmail 출시: 2004년 4월 1일, 당시 무료 이메일보다 수십 배 큰 약 1GB급 저장 공간과 빠른 검색 제공
• Colossus 확장 목표: GFS의 약 1,000대 규모 한계를 넘어 약 10,000대 규모로 확장
• 저장 청크 예시: 파일을 약 64MB 단위 청크로 분할
• 삭제 부호화 예시: 9개 청크 중 5개로 복구해 4개 손실 허용
• 하드웨어 지연: HDD 약 5~10ms, NVMe SSD 약 30~50µs, 객체 저장소 첫 읽기 약 20~30ms 수준
• CockroachDB 복제: 일반적으로 3개, 시스템 테이블·고내구성 설정은 5개·7개 가능
• Peter의 AI 이전 생산량: 최고 약 10만 줄/년, 당시 업계 기준 약 3,000줄/월
• AI 활용 사례: 약 30분 동안 약 10,000줄의 고성능 Rust B-tree 구현
• 동시 에이전트 운영: 일반적으로 5~10개 세션, 작업에 따라 하위 에이전트 20~100개
• 비엔지니어 내부 앱: 플랫폼 출시 뒤 수개월 동안 약 500~1,000개 생성

결론 및 시사점

1. 분산 시스템의 핵심은 제품 이름이나 클라우드 추상화가 아니라 데이터 구조, 복제 단위, 장애 복구, 메타데이터와 물리적 지연을 명시적으로 설계하는 데 있다.
2. B-tree처럼 오래된 자료구조도 캐시·메모리·범위 질의·샤딩 요구를 새 하드웨어에서 다시 측정하면 표준 라이브러리를 개선할 여지가 생긴다.
3. 저장소와 데이터베이스를 구분해야 한다. 큰 append-only 파일을 다루는 Colossus와 작은 행·인덱스·트랜잭션을 다루는 CockroachDB는 다른 문제를 푼다.
4. 자동 범위 분할과 강한 일관성은 애플리케이션 개발자가 수동 샤딩과 복제 지연을 떠안지 않게 하지만, 그 비용으로 네트워크 왕복·합의·쓰기 지연을 지불한다.
5. 미션 크리티컬 시스템은 장애가 없는 시스템이 아니라 장애가 일어나도 데이터와 신뢰를 유지하는 시스템이다.
6. AI 생산성은 코드 생성량만으로 평가할 수 없다. 속도만큼 테스트·성능·보안·UX 가드레일을 자동화해야 실제 품질이 올라간다.
7. 엔지니어는 에이전트를 관리하는 사람이라기보다 수많은 실험을 병렬로 지휘하는 hands-on 테크 리드에 가까워지고 있다.
8. AI가 전문성을 대체하기보다 증폭한다는 점에서, 자료구조·분산 시스템·도메인 지식을 깊게 익힌 사람의 영향력은 더 커질 수 있다.
9. 중견·시니어 엔지니어는 AI에게 코드를 대신 쓰게 하는 데서 멈추지 말고, 기존 코드의 설계 이유와 도메인 규칙을 설명하게 하며 학습 속도를 높여야 한다.
10. 높은 생산성의 다음 단계는 더 많은 코드를 내는 것이 아니라, 예전에는 시간·인력 때문에 포기했던 성능·복원력·보안·사용자 경험까지 구현하는 것이다.

핵심 요약 (20줄)

1. Peter Mattis는 GIMP, Gmail, Colossus, CockroachDB를 거치며 그래픽·저장소·데이터베이스를 연결해 온 시스템 엔지니어다.

2. 대학 시절 만든 GIMP는 다른 사람이 같은 프로그램을 만들었다는 발표에도 멈추지 않고 출시했기에 사용자와 오픈소스 학습자에게 영향을 남겼다.

3. Google의 Gmail은 GFS 위에서 대용량 저장과 빠른 검색을 제공하며 무료 이메일 서비스의 경제적 기대치를 바꿨다.

4. Gmail의 메시지 스레딩과 읽지 않은 개수 관리에는 B-tree와 역색인이 사용됐다.

5. Google 3의 빌드 파일은 거대한 Makefile의 저수준 의존성 표현을 추상화해 Blaze와 Bazel로 발전했다.

6. Colossus는 GFS의 단일 마스터와 확장성 한계를 넘기 위해 메타데이터를 Bigtable에 저장한 분산 파일 시스템이다.

7. Reed–Solomon 삭제 부호화는 삼중 복제보다 적은 공간으로 여러 청크 손실을 복구하게 한다.

8. 분산 시스템의 처리량이 높아도 HDD·SSD·네트워크·빛의 속도가 첫 읽기와 리전 간 지연의 하한을 결정한다.

9. B-tree는 작은 정렬 배열의 캐시 지역성에서 출발해 데이터베이스 인덱스와 분산 키 범위 관리에 반복해서 등장한다.

10. Google 내부 STL map의 메모리 병목은 캐시 친화적인 B-tree 구현으로 개선됐고 Go의 Swiss table 기여로도 이어졌다.

11. Colossus가 큰 append-only 파일을 저장한다면 Spanner와 CockroachDB는 작은 행·인덱스·트랜잭션을 처리하는 데이터베이스다.

12. CockroachDB는 수동 샤딩과 리샤딩의 부담을 애플리케이션에서 데이터베이스의 자동 범위 분할 계층으로 옮긴다.

13. 강한 일관성은 어느 복제본에서 읽어도 방금 쓴 값을 보장하지만 합의와 네트워크 지연이라는 비용을 가진다.

14. Raft 기반 합의는 보통 세 복제본과 쿼럼을 사용하며 지역 간 복제는 재해 복원력과 물리적 지연을 맞바꾼다.

15. 미션 크리티컬 시스템은 거래·은행·주문·쇼핑 카트처럼 중단 시 매출과 사용자 신뢰가 즉시 손상되는 서비스다.

16. Peter는 AI 이전 연간 10만 줄을 작성했지만 2022~2024년 임원 역할로 코딩을 줄였다가 AI와 함께 다시 생산 현장으로 돌아왔다.

17. AI 에이전트는 설계 탐색과 병렬 실험을 가속하며 약 30분 만에 1만 줄 규모의 고성능 Rust B-tree를 생성할 수 있다.

18. 에이전트는 테스트·성능·보안 검증을 생략하기 쉬우므로 속성 기반·메타모픽·결정적 시뮬레이션 테스트를 강제해야 한다.

19. AI는 기존 전문성을 증폭하므로 엔지니어는 코드를 맡기는 동시에 자료구조·분산 시스템·업무 도메인을 더 깊게 학습해야 한다.

20. 더 높은 AI 생산성의 목표는 더 많은 코드가 아니라 과거에 포기했던 성능·복원력·보안·UX까지 구현하는 것이다.