🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Jacob Baskin의 Data Warehouse From Scratch 이야기는 데이터 웨어하우스를 “더 큰 Postgres”로 만드는 일이 아니라, 조직의 실제 사용 방식에 맞춰 무엇을 포기하고 무엇을 보장할지 선택하는 시스템 설계의 문제임을 보여준다.

📌 핵심 요점

1. Jacob Baskin의 경력은 메커니즘 디자인, 광고 거래소, 분산 시스템, 금융 데이터 인프라로 이어지며, 공통적으로 “전략적 사용자 행동”과 “대규모 계산 시스템”이 만나는 지점에 놓여 있다.
2. Google AdExchange 경험에서는 실시간 입찰, 지연 시간, 보안·프라이버시, 대형 고객 요구, 분산 인프라를 동시에 다뤄야 했고, 이론적으로 깔끔한 시장 설계보다 설명 가능성과 운영 가능성이 더 중요했다.
3. Jane Street의 데이터 문제는 여러 Postgres 데이터베이스와 자유로운 사용자 쿼리 환경에서 커졌고, 단일 머신 한계를 넘어 대규모 읽기·압축·조인·접근 로그·권한 관리를 지원하는 분석 시스템이 필요해졌다.
4. Superstore는 full SQL transactional semantics를 그대로 재현하지 않고, 단일 테이블 단위의 일관성, 컬럼형 저장, 비동기 쓰기, 시스템 경계를 통한 Parquet 직접 접근 차단 같은 타협을 선택했다.
5. 초기 설계에서 CockroachDB 기반 메타데이터 저장은 쓰기 지연 병목으로 드러났고, 이후 Arya 기반 단일 시퀀서 선택처럼 성능과 가용성 사이의 현실적 트레이드오프가 핵심 설계 이슈가 됐다.

🧩 배경과 문제 정의

• Jacob Baskin의 경력은 대규모 컴퓨팅·데이터 시스템, 알고리즘, 경제적 인센티브가 교차하는 지점에 놓여 있다.
• 메커니즘 디자인은 자원 배분 문제에서 참여자의 전략적 행동과 계산 복잡도를 함께 다루며, 실제 소프트웨어 시스템 설계에도 영향을 미친다.
• Google의 DoubleClick 인수 이후 광고 거래 시스템은 검색 광고식 경매 역량, 대형 퍼블리셔·광고주 관계, 대규모 분산 인프라를 함께 결합해야 하는 문제로 확장됐다.
• Jane Street의 데이터 웨어하우스 구축은 Postgres 중심 환경의 한계, 대규모 분석 쿼리, 내부 사용자의 자유도, 온프레미스 데이터 규모를 동시에 해결해야 하는 과제였다.
• 후반부의 핵심 문제는 Superstore 이후 Hive 같은 대규모 계산 인프라에서 스케줄링, 인센티브 설계, 데이터 접근 경계, 계산 그래프 최적화를 어떻게 다룰 것인가로 이어진다.

🕒 시간순 섹션별 상세정리

1. 컴퓨터과학 진입과 메커니즘 디자인의 출발점

• Jacob Baskin은 어린 시절 BASIC으로 코딩을 시작했고, 대학에서는 심리학을 생각했지만 코딩과 흥미로운 문제들에 끌려 컴퓨터과학으로 방향을 바꿨다 [00:24]
• Brown University 논문 주제는 메커니즘 디자인과 경제학·알고리즘의 접점이었으며, 경제적 조건이 들어오면 효율적인 절차를 찾는 일이 훨씬 어려워진다 [00:45]

2. 자원 배분 문제에서 전략과 계산 복잡도가 겹치는 구조

• 메커니즘 디자인은 경매처럼 참여자가 자원에 대해 얼마를 지불할 의사가 있는지 드러내게 하고, 전략적 왜곡 없이 사회적으로 가치가 큰 배분을 찾는 문제를 다룬다 [01:28]
• 네트워크 구축 사례에서는 참호·광섬유 배치 자체도 계산적으로 어렵고, 여기에 계약자·통신사·가격 차이가 더해지며 알고리즘 문제와 경제적 문제가 동시에 얽힌다 [02:18]

3. 광고 거래소에서 드러난 시장 설계와 양면 시장

• 금융시장과 거래소 설계에서는 메커니즘 디자인, 참여자 행동, 기술 구조가 서로 영향을 주며, Jacob의 관심사는 이후 trading firm 경력과도 계속된다 [03:41]
• Google에서의 첫 업무는 외부 웹사이트에 더 나은 광고를 노출하는 광고 비즈니스였고, AdExchange는 광고 공간을 가진 쪽과 광고를 싣고 싶은 쪽을 연결하는 양면 시장이었다 [04:02]

4. DoubleClick 인수 이후 Google 광고 사업의 확장 과제

• 2008년 Google은 배너 광고와 광고 추적에 강한 DoubleClick을 인수했고, DoubleClick은 사용자가 웹사이트를 방문할 때 어떤 이미지를 로드할지 선택하고 결과를 추적하는 영역에서 강점을 갖고 있었다 [04:59]
• Google은 검색 광고 경매에는 강했지만, 대형·복잡한 외부 웹사이트 광고에서는 DoubleClick이 업계 선두였고, 인수 이후 두 역량을 결합해야 하는 과제가 생겼다 [05:29]

5. 대형 고객 이해와 Google 인프라로의 재구축

• DoubleClick의 강점은 대형 퍼블리셔와 대형 광고주 관계, 엔터프라이즈 고객 요구를 이해하는 역량이었고, 이는 당시 Google에는 부족한 DNA였다 [07:09]
• 기업 간 거래에서는 고객이 무엇을 하려는지와 왜 하려는지를 깊게 이해하는 태도, 영업·관리형 관계, 대형 고객을 섬기는 방식이 중요해진다 [07:31]

6. 실시간 입찰과 광고 노출 순간의 지연 시간 문제

• 기술적으로 어려운 작업은 수평 확장 가능한 Google 인프라와 DoubleClick의 대형 고객용 기능 요구를 결합하는 일이었고, Ad Exchange에서는 실시간 입찰이 별도의 핵심 문제가 됐다 [10:06]
• 실시간 입찰에서는 광고주가 모든 광고 재고를 미리 넘기지 않고, 광고 노출이 발생하는 매 순간 외부 광고 시스템에 질의해 즉시 입찰가를 받는다 [10:29]

7. 광고 추적 인프라의 성능·보안·프라이버시 부담

• 광고 로딩은 이미지 자체보다 추적 쿠키, 픽셀, 여러 외부 도메인, 광고 측정·모니터링 코드 때문에 훨씬 무거웠고, 페이지 부하의 병목은 광고 주변 인프라로 이동했다 [12:01]
• 추적과 쿠키 기반 구조는 보안·프라이버시 측면에서 위험했고, 플랫폼이 사용자를 인터넷 전반에서 추적하지 못하도록 식별자를 익명화하는 장치가 필요했다 [12:36]

8. 메커니즘 디자인 이론과 실제 시장 설계의 간극

• 학교에서 배운 메커니즘 디자인의 중심 메시지는 인센티브 호환성이었고, 좋은 메커니즘에서는 참여자가 진실을 말하는 편이 이익이 된다 [14:21]
• 실제 산업에서도 인센티브 호환성은 가치 있는 목표였지만, 전체 문제에서 차지하는 비중은 학교에서 생각했던 것보다 작았다 [15:04]

9. 예산 제약이 경매 이론과 단순성 원칙을 흔든다

• 광고주는 좋은 가격을 얻을 수 있어도 무한정 지출하지 않으며, 하루 예산과 리스크 한도는 실제 입찰 전략의 기본 제약으로 작동한다 [16:04]
• 예산을 빠르게 소진해 하루 끝에 소액만 남은 광고주는 입찰가를 낮추는 편이 나을 수 있고, 이는 한계가치 그대로 입찰한다는 단순한 경매 모델을 흔든다 [16:24]

10. Google식 분산 시스템 설계와 상태 관리의 축소

• Google에서의 시스템 경험은 어려운 분산 시스템 문제를 가능한 한 작은 영역에 가두고, 기존 합의 시스템이나 대규모 상태 저장소 위에 새 시스템을 얹는 사고방식으로 이어졌다 [18:22]
• Bigtable은 Chubby 같은 분산 합의 메커니즘 위에 구축됐고, 대부분의 엔지니어는 Bigtable이나 Chubby 자체보다 그 위의 애플리케이션 계층을 만들었다 [19:12]

11. 광고 서빙과 트레이딩 시스템의 지연시간·조직 구조 차이

• Google식 구조는 상태를 가진 코어가 데이터를 효율적인 형태로 메모리에 올리고, 수많은 웹 서버가 그 코어에 질의하며 가능한 많은 작업을 바깥 계층으로 밀어내는 방식에 가깝다 [20:07]
• 트레이딩 시스템은 Google과 달리 극단적인 지연시간을 우선시하기 때문에 상태를 엣지 가까이에 두는 선택이 필요하고, 아키텍처의 중심 제약도 크게 달라진다 [20:35]

12. 도시 도로변 규칙을 데이터화하는 스타트업 문제

• Google 이후에는 도시가 도로변을 관리하도록 돕는 스타트업으로 이동했고, 도로변 관리는 표지판·도로 표시·아이콘이 차량의 주차, 정차, 하역 가능 여부를 결정하는 복잡한 규칙 체계와 연결됐다 [21:56]
• 도시의 도로변 규칙은 시간이 지나며 누적됐지만 무엇이 왜 존재하는지에 대한 좋은 기록은 거의 없었고, 물리적 제어 인프라와 규칙 분석 플랫폼을 함께 관리할 필요가 있었다 [22:27]

13. AR식 장면 매핑에서 주차 표지판 위치 데이터로 확장된다

• 포켓몬이 화면 속 장면에 고정돼 보이려면 휴대폰 안에 주변 장면의 지도가 필요하고, 같은 원리로 한 블록의 지도를 만들어 표지판 위치를 높은 정확도로 배치할 수 있다 [24:01]
• 주차 데이터 수집은 표지판 위치를 찾는 데서 끝나지 않고, 표지판 문구를 읽는 전사 문제와 그 문구가 실제로 어떤 주차 규칙을 뜻하는지 해석하는 문제로 계속된다 [24:29]

14. 주차 표지판 파서는 도시별 어휘와 공간 배치를 함께 다뤄야 한다

• 주차 표지판의 어휘는 비교적 작지만 도시마다 규칙과 표현이 달라지고, 같은 숫자와 단어도 위치 배치에 따라 의미 연결이 달라진다 [24:52]
• “2”라는 큰 숫자와 “maximum hours parking” 같은 문구가 표지판의 다른 위치에 놓이면, 사람은 공간 맥락으로 의미를 결합하지만 컴퓨터 모델은 그 결합 방식을 따로 표현해야 한다 [25:20]

15. 실패한 도시 데이터 사업 이후 뉴욕과 금융, OCaml이 Jane Street 선택으로 계속된다

• 다음 커리어를 고민할 때 Google 복귀의 매력은 낮았고, 회사가 훨씬 커진 상황과 뉴욕에 계속 살고 싶은 조건이 선택지를 좁혔다 [26:02]
• 도시 스타트업에 대한 관심과 초기 경력의 경제적 사고가 맞물리면서, 뉴욕에서 금융 관련 일을 하는 사람들과 연결되는 경로가 자연스러워졌다 [26:21]

16. 데이터베이스 인프라 팀 매칭에서 데이터웨어하우스 구상이 나온다

• 입사 전 팀 매칭 과정에서 database infrastructure 팀은 여러 Postgres 데이터베이스를 운영하고 있었고, 일부는 매우 컸으며 사람들이 임의의 데이터를 넣으면서 관리 문제가 커졌다 [27:53]
• 기존 문제를 더 잘 관리하는 대신, 여러 데이터가 단일 Postgres 머신에 묶이지 않아도 전체를 질의할 수 있는 분산 분석 데이터베이스가 필요하다는 방향이 떠올랐다 [28:24]

17. Postgres는 거래 처리와 분석 처리의 저장 요구가 충돌한다

• Postgres는 웹사이트 결제처럼 주문 기록, 재고 감소, 원자적 성공이 짧은 시간 안에 함께 보장되어야 하는 단일 행·소수 행 트랜잭션에 강하다 [29:14]
• 분석 처리는 수백만 행을 훑어 집계 질문에 답해야 하며, Postgres에서도 가능하지만 거래 처리에 맞춘 저장 방식 때문에 훨씬 느려질 수 있다 [29:47]

18. SQL의 강한 추상화는 열 지향 시스템의 장점을 쉽게 무너뜨린다

• 열 지향 저장을 쓰는 SQL 데이터베이스는 많고 Jane Street도 당시 Vertica를 사용했지만, 그 위에 완전한 SQL 트랜잭션 의미론을 얹으면 시스템이 쉽게 취약해진다 [31:45]
• Postgres가 효율적으로 처리하는 SQL 기능을 열 지향 데이터 위에서 그대로 보장하려 하면, 성능 이점이 사라지고 쿼리가 극도로 느려지거나 데이터베이스를 실질적으로 쓰기 어려워질 수 있다 [32:21]

19. 데이터베이스의 가치는 조인 가능한 생태계에서 커진다

• Jane Street의 일별 전체 거래 목록은 개인 트레이딩 정보와 결합될 때 수수료, 포지션, 시장·통화·심볼 분석에 활용되며, 단일 테이블보다 연결 가능한 데이터 집합으로서 더 큰 가치를 갖는다 [36:28]
• 새 데이터가 플랫폼에 추가될수록 조인 가능한 대상이 늘어나고, SQL join은 서로 다른 데이터 원천을 묶어 실제 분석 가치를 만드는 핵심 연산이 된다 [37:01]

20. 자유로운 쿼리 환경은 통제 장치 없이는 운영 위험을 키운다

• 많은 회사는 트랜잭션 데이터베이스의 규모 문제를 피하기 위해 스키마 위원회, 코드 리뷰된 쿼리, GUI 기반 쿼리 생성 같은 제한을 두고, 그만큼 유연성과 사용성을 줄인다 [37:18]
• Jane Street에서는 트레이더를 포함한 여러 사용자가 데이터베이스에서 거의 원하는 일을 할 수 있어야 큰 가치가 생겼고, 그 자유도를 유지하기 위해 운영팀이 내부 보호 장치를 많이 떠안았다 [38:02]

21. 장기 트랜잭션은 락·복제·vacuum 비용을 누적시킨다

• Postgres는 트랜잭션이 테이블을 변경할 때 변경 전후 상태를 관리하며, copy-on-write 방식으로 실제로 건드린 조각만 분리해 커밋 시점에 병합에 가까운 처리를 한다 [38:47]
• SQL 트랜잭션은 단순한 독립 fork가 아니라 변경 중인 row에 사실상 락을 걸어 충돌을 막고, 커밋 시점의 merge hell이 생기지 않도록 제어한다 [39:44]

22. 새 시스템은 Wild West 자유도와 대규모 읽기 중심 구조가 필요하다

• 기존 환경은 여러 데이터베이스 위에서 자유로운 데이터 추가와 SQL 트랜잭션을 허용했고, 잦은 성능 문제를 사람의 운영 작업으로 버티는 Frankenstein식 구조에 가까웠다 [41:37]
• Postgres는 본질적으로 데이터를 단일 머신에 두는 구조였고, 당시 Jane Street의 가장 큰 컴퓨터급 장비가 Trino DB를 돌릴 정도로 단일 머신 한계가 요구사항을 압박했다 [42:06]

23. 완전한 트랜잭션 대신 제한된 일관성 범위를 선택한다

• Postgres에서 데드락은 많은 락을 잡는 과정에서 발생하는 심각한 성능 문제였고, 기존 운영에서는 데드락을 감지한 뒤 관련 쿼리를 종료하는 방식으로 대응했다 [43:22]
• 새 데이터 웨어하우스는 Postgres를 단순히 더 잘 만든 버전이 아니라, 트랜잭션이 만드는 문제를 피하기 위해 어떤 보장을 포기할 수 있는지부터 정해야 했다 [43:42]

24. 단일 테이블 원자성과 컬럼형 저장의 update 비용 사이에서 타협한다

• 최종 설계는 중간 지점을 택해 단일 테이블에는 일관된 쓰기를 허용하고, 거래 목록처럼 누락이나 중복이 치명적인 로그성 데이터에는 원자적 append와 order-preserving write를 보장한다 [45:36]
• 거래 데이터는 source of truth에서 다시 가져와 최신화할 수 있고 대부분의 변경이 append이기 때문에, 여러 테이블을 하나의 트랜잭션으로 묶지 않아도 실무상 필요한 일관성 대부분을 유지할 수 있다 [45:58]

25. 비동기 쓰기와 읽기 가능 시점 분리

• 모든 쓰기를 비동기로 처리하면 커밋은 즉시 승인되지만, 독자가 그 결과를 바로 볼 수는 없고 원자성·순서 보장은 별도 의미론으로 유지된다 [48:11]
• 쓰기와 읽기 사이의 지연 구간에서 데이터가 컬럼형 저장소의 적절한 위치로 들어가고, 필요하면 압축도 다시 수행되며, 읽기 대기자나 쓰기 커밋 대기자에게 비용이 직접 전가되지 않는다 [48:30]

26. 내부 사용자 환경에서 가능한 쓰기 인터페이스 절충

• 상용·오픈소스 시스템은 사용자를 매번 교육해야 하기 때문에 이런 비동기 쓰기 의미론을 잘 택하지 않지만, 사내 사용자만 상대하는 환경에서는 작동 방식과 이유를 직접 공유할 수 있다 [49:23]
• SQL은 1급 읽기 인터페이스로 남아도 쓰기 인터페이스까지 SQL일 필요는 없고, Trader DB의 쓰기는 대체로 사람의 즉흥 쿼리보다 잘 정의된 소프트웨어 시스템을 통해 발생했다 [49:49]

27. Parquet 직접 접근 차단과 시스템 경계 유지

• Superstore의 기반 데이터는 Parquet 파일로 저장되지만, 사용자가 분산 파일을 직접 읽어 임의 작업을 수행하는 요청은 계속 거부된다 [51:26]
• 데이터베이스가 디스크 파일을 직접 읽는 도구가 아니라 시스템 인터페이스를 통해 접근되는 것처럼, Parquet 파일도 내부 구현 세부사항으로 남아야 한다 [51:56]

28. 사용 로그, 스키마 진화, 수평 확장의 필요성

• 직접 파일 접근을 막아야 전체 읽기·쓰기 로그를 확보할 수 있고, 이는 TraderDB 같은 기존 시스템에서 어려웠던 폐기와 스키마 진화를 가능하게 하는 기반이 된다 [53:05]
• 500명이 매일 조회하는 테이블을 삭제하려면 실제 사용자가 누구인지, 뷰와 중첩 뷰를 통해 간접 참조되는지, 어떤 데이터 범위가 필요한지까지 파악해야 한다 [53:18]

29. 데이터 폭증과 전사적 활용 확대

• 데이터 양과 사용 강도가 폭발적으로 늘고, 머신러닝 기반 접근까지 합류하면서 데이터 시스템에 걸리는 압력이 커졌다 [54:47]
• 여러 테라바이트를 효율적으로 조회할 수 있는 시스템이 생기면 트레이더와 리서처를 넘어 사이버보안의 네트워크 접근 로그, 도구·컴파일러의 코드 리뷰 이력, 빌드 기록까지 새 활용처가 생긴다 [55:09]

30. 외부 데이터 웨어하우스 대신 자체 구축을 택한 이유

• Snowflake와 Databricks 같은 클라우드 SaaS 데이터 웨어하우스는 성숙한 제품이지만, 쿼리 비용이 높아 실행할 쿼리 자체를 달러 비용 기준으로 고민하게 만든다 [56:44]
• Jane Street의 많은 데이터는 온프레미스 시스템에서 생성·관리되므로, 쿼리를 위해 대량의 데이터를 클라우드로 복사하는 방식은 적합하지 않다 [57:24]

31. 사용자 요구를 거부하지 않는 내부 플랫폼의 장점

• Superset 같은 도구 사용을 보면 더 나은 방식이 있는지 따져볼 필요는 있지만, 사용 사례 자체를 부정하면 안 되는 상황이 있었다 [1:00:01]
• 트레이더들은 자신들이 무엇을 이해하려는지 깊이 고민한 사용자들이고, 내부 플랫폼은 벤더보다 훨씬 더 많은 경우에 “가능하다”고 답할 수 있었다 [1:00:27]

32. 협업자와 사용자 신뢰가 초기 도입을 가능하게 한 구조

• 프로젝트는 한 사람의 성과가 아니라, 오래 일한 협업자들과 Sam 같은 리더가 Jane Street에서 가치 있는 소프트웨어의 조건을 전달하면서 형태를 갖췄다 [1:01:10]
• 잠재 사용자들에게 무엇을 만들고 왜 필요한지 미리 공유했고, 실제 시스템이 생겼을 때 바로 사용할 준비가 되도록 조직적 조율이 병행됐다 [1:01:38]

33. 위험을 감수하는 문화와 10페타바이트 스토리지 결정

• 조직 문화에는 다른 팀이 합리적인 시도를 하고 있다는 신뢰와, 소프트웨어 프로젝트도 일정한 실패 가능성을 가진 베팅이라는 인식이 함께 있었다 [1:03:20]
• Superstore를 뒷받침할 스토리지 장비를 언제 사고 얼마나 크게 잡을지가 초기 의사결정의 큰 쟁점이었고, 2022년에는 코로나 이후 공급망 지연으로 리드타임도 길었다 [1:03:55]

34. 메타데이터 저장소 선택이라는 초기 설계 후회

• Superstore의 여러 설계 베팅은 전반적으로 잘 맞았지만, 가장 후회되는 결정은 메타데이터 처리 방식이었다 [1:05:23]
• 컬럼형 데이터베이스에서 메타데이터는 테이블 구조와 현재 데이터 위치를 가리키는 포인터를 담는 핵심 구성요소이고, 많은 시스템에서는 권한 정보까지 포함한다 [1:05:42]

35. 스트리밍 쓰기와 분산 합의가 만든 지연 병목

• CockroachDB는 여러 면에서 적합했지만, Superstore가 커질수록 특히 쓰기 지연에서 문제가 커졌다 [1:07:11]
• Superstore 데이터의 상당 부분은 스트리밍으로 들어오며, 이 스트림을 테이블로 물질화하는 목표 지연은 1초 미만에 가까웠다 [1:07:26]

36. CockroachDB 제거와 Arya 기반 단일 시퀀서 선택의 트레이드오프

• 분산 합의는 여러 서버가 데이터 위치에 대해 다수결로 합의하게 만들어 장애 허용성을 주지만, 네트워크 통신과 동기화가 시스템 속도를 제한한다 [1:08:54]
• 단일 CPU 자체는 많은 결정을 빠르게 처리할 수 있으므로, 병목의 핵심은 한 장소로 가는 행위가 아니라 분산 동기화 비용에 있었다 [1:09:38]

37. Superstore의 고가용성 설계가 단일 테이블 커밋 병목으로 남는다

• 대형 기술 시스템에서도 다운타임 원인은 단일 장애점보다 소프트웨어 버그인 경우가 많고, 처음 방어하려던 하드웨어·인프라 실패와 실제 장애 원인이 어긋난다 [1:12:00]
• Superstore의 핵심 메타데이터 시스템은 높은 가용성 요구를 기준으로 설계됐고, 그 선택이 전체 확장성에서 필요한 처리량을 막는 트레이드오프로 이어졌다 [1:12:17]

38. Hive는 연구·학습·시뮬레이션을 위한 대규모 계산 클러스터로 확장된다

• Hive는 Jane Street의 모든 컴퓨터가 아니라, 많은 컴퓨터가 동시에 필요한 계산을 실행하는 장소이며 신경망 학습과 여러 날의 거래 데이터 분석이 대표적인 사용처다 [1:13:06]
• 실제 거래 시스템 코드를 시뮬레이션 모드로 실행해 광범위한 과거 데이터 위에서 대규모 실험을 수행하는 작업도 Hive의 중요한 용도다 [1:13:34]

39. 신경망 학습 수요가 폭증하면서 Hive 자체가 인프라 리스크가 된다

• Hive 컴퓨트 수요 증가의 대부분은 신경망 학습과 그 학습에 투입할 피처 데이터 처리에서 발생한다 [1:14:44]
• 신경망 학습은 거의 전적으로 GPU에서 실행되지만, 학습 전후의 데이터 생산과 분석은 상당 부분 CPU에서 일어난다 [1:15:04]

40. 격리와 인터페이스 설계가 저장소 장애를 줄이는 핵심 수단이 된다

• Hive 작업은 거래 시스템과 우발적으로 상호작용하지 못하도록 격리되어야 하며, 동시에 Hive가 접근해야 하는 시스템도 과도한 요청으로 쓰러지지 않게 다뤄져야 한다 [1:16:32]
• 많은 데이터 접근은 여전히 NFS를 통해 이뤄지고, NFS는 디렉터리 나열과 파일 생성 같은 동작에서 특이한 잠금 의미론을 가진다 [1:17:04]

41. 이미 쓰이는 Hive를 개선하려면 전체 스택과 실제 사용자 흐름을 이해해야 한다

• Superstore는 처음부터 API와 트레이드오프를 설계할 여지가 있었지만, Hive는 이미 많은 사람이 연구 작업의 중심에서 쓰는 오래된 시스템이라 API를 자유롭게 다시 정하기 어렵다 [1:18:30]
• 기능을 만들어 배포해도 사용자가 쓰지 않는 문제가 있었고, 실제 사용자는 Hive API를 직접 호출하기보다 그 API를 감싼 다른 시스템을 통해 작업하고 있었다 [1:19:29]

42. 향후 Hive의 핵심 과제는 스케줄링 인센티브와 긴급도 모델링이다

• Hive는 한정된 컴퓨터 자원을 여러 작업에 배정해야 하며, 수요가 공급을 넘을 때 어떤 작업을 먼저 실행할지 정하는 메커니즘 설계 문제를 안고 있다 [1:21:17]
• Jane Street에서는 CPU 시간·GPU 시간당 달러 입찰과 2가격 경매를 쓰지만, 현재 구조만으로는 사용자가 작업 실행 선호를 충분히 표현하기 어렵다 [1:21:41]

43. 시간 선호까지 포함한 스케줄링 문제

• 주기적으로 도는 작업은 마지막 실행과 다음 실행 사이의 간격이 중요하며, 하루 단위 모니터링에서는 20시간·28시간 간격은 괜찮아도 4시간·44시간 간격은 품질을 크게 떨어뜨린다 [1:24:00]
• 시간에 따른 효용까지 모델링하면 스케줄링은 더 복잡해지고, 이미 GPU 작업의 gang scheduling 때문에 특정 수의 GPU를 한꺼번에 확보해야 하는 조합 문제가 존재한다 [1:24:38]

44. 즉시 입찰 모델이 사용자에게 떠넘기는 복잡성

• 기존 방식은 모든 작업이 지금 실행될 수 있는지를 놓고 입찰하고, 가장 높은 입찰이 이기는 구조라 작업의 실제 시간 선호를 충분히 반영하지 못한다 [1:26:12]
• 큰 작업을 당장 돌리려는 사용자는 과도한 비용을 낸 뒤, 밤까지 기다렸다면 더 저렴했을 것이라고 후회할 수 있다 [1:26:28]

45. 대규모 작업 시작 비용과 BitTorrent식 배포

• 또 다른 문제는 worker 단위의 실행 효율이며, 동일한 프로세스 1,000개를 데이터 shard 1,000개에 돌리려면 코드가 먼저 1,000개 코어에 배포돼야 한다 [1:27:31]
• 코드 크기가 크면 바이트를 복사하는 일 자체가 비싸지고, 한 장소에 있는 코드를 1,000대의 컴퓨터가 동시에 가져오면 원본 위치가 병목이 된다 [1:27:52]

46. 유기적으로 자란 API와 계산 그래프 최적화

• Hive의 주요 접근 방식 중 하나는 computation graph API이며, 태스크와 태스크가 만드는 데이터 의존성을 그래프로 표현하고 Hive가 이를 위상 순서대로 실행한다 [1:30:23]
• 이 그래프를 더 빠르게 실행하려는 순간 query planner와 같은 문제가 생기며, 작업 그래프 자체와 각 머신 안에서 수행되는 계산을 함께 최적화해야 한다 [1:30:50]

47. 선언적 계산 그래프와 도메인 특화 인터페이스

• Pandas는 eager mode에 가까워 요청한 연산을 즉시 실행하지만, Polars는 lazy execution으로 연산을 조각별로 쌓아 전체 쿼리를 만든 뒤 시스템이 이를 보고 최적화할 수 있다 [1:32:01]
• Spark 같은 다른 분산 시스템도 비슷하게 분산 쿼리 엔진의 성격을 가지며, Hive에도 이런 선언적이고 최적화 가능한 스타일의 인터페이스가 필요하다는 결론으로 계속된다 [1:32:40]

🧾 결론

• 이 대화의 중심 메시지는 데이터 웨어하우스 구축이 단순한 저장소 선택이 아니라, 사용자의 자유도·운영 안정성·일관성 보장·비용 구조를 함께 조율하는 아키텍처 문제라는 점이다.
• Jane Street는 외부 SaaS 데이터 웨어하우스 대신 자체 구축을 택했는데, transcript 기준으로는 온프레미스 데이터, 금융 특화 요구, 쿼리 비용, 경쟁우위 노출 리스크가 중요한 이유로 제시된다.
• Superstore의 설계는 “모든 SQL 기능을 다 지원하는 범용 데이터베이스”보다 “내부 사용자가 실제로 많이 하는 대규모 읽기·조인·분석을 안정적으로 빠르게 처리하는 시스템”에 초점을 맞춘다.
• 메커니즘 디자인에서 출발한 관점은 Hive 스케줄링 문제에서도 이어진다. 사용자가 단일 달러 입찰로 모든 선호를 표현하기 어렵기 때문에, 시간에 따른 효용과 긴급도를 더 잘 모델링하는 문제가 남아 있다.
• transcript에서 확인되는 범위 안에서, Jacob Baskin의 핵심 관심사는 이론적으로 완벽한 시스템보다 사용자가 이해하고 신뢰하며 실제 업무에 채택할 수 있는 시스템을 만드는 데 있다.

📈 투자·시사 포인트

• 데이터 인프라 투자는 “제품을 사느냐 직접 만드느냐”의 문제가 아니라, 데이터 위치, 보안 요구, 쿼리 비용, 내부 사용 패턴, 경쟁우위 노출 가능성을 함께 따지는 전략적 선택으로 봐야 한다.
• 컬럼형 저장, 비동기 쓰기, 접근 로그, 권한 제어, 스키마 진화 같은 기능은 대규모 조직에서 데이터 활용이 늘어날수록 단순한 성능 개선이 아니라 운영 리스크 관리 수단이 된다.
• 클라우드 데이터 웨어하우스가 성숙해도, transcript에서 제시된 Jane Street 사례처럼 특수한 온프레미스·금융·고빈도 분석 요구가 강한 조직은 자체 시스템의 경제성이 커질 수 있다.
• 대규모 GPU·CPU 클러스터인 Hive 사례는 AI·신경망 학습 수요가 커질수록 컴퓨트뿐 아니라 저장소, 코드 배포, 스케줄링, 사용자 인센티브 설계가 병목이 될 수 있음을 시사한다.
• 검증 필요: Superstore, Hive, Arya의 현재 구현 세부사항이나 Jane Street 내부 운영 수치는 transcript 밖의 정보이므로, 실제 기술 평가나 벤치마크 판단에는 공개 자료와 추가 확인이 필요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• Superstore, TraderDB, Hive, Arya의 내부 구조와 현재 운영 상태는 발표자의 설명에 기반한 것이므로, Jane Street의 공식 자료나 후속 문서로 최신 상태를 확인필요가 있다.
• 10페타바이트 규모 스토리지 구매와 “여덟 자리 달러에 가까운 비용” 언급은 내부 의사결정 사례로 제시됐지만, 실제 계약 규모·최종 비용·현재 증설 규모는 외부 검증이 필요하다.
• CockroachDB가 Superstore 메타데이터 병목이 됐다는 설명은 특정 워크로드와 설계 선택에 대한 사례로 봐야 하며, CockroachDB 일반 성능 평가로 확대 해석해서는 안 된다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 노트의 핵심 태그를 데이터웨어하우스, 분산시스템, 메커니즘디자인, Jane Street, Superstore, Hive, 시스템설계 중심으로 정리한다.
• Superstore 설계 원칙을 “포기한 것과 얻은 것” 관점으로 따로 요약한다: full SQL write semantics, cross-table transaction, 직접 Parquet 접근 제한, 비동기 write, 단일 테이블 원자성.
• Hive 스케줄링 파트를 별도 아이디어 노트로 분리해 GPU gang scheduling, 시간 선호, 효용 곡선, 입찰 기반 자원 배분의 한계를 정리한다.
• CockroachDB에서 Arya 기반 시퀀서로 전환한 대목을 “분산 합의 vs 단일 시퀀서” 트레이드오프 사례로 표시하고, 장애 허용성·처리량·운영 복잡도 기준으로 비교한다.

❓ 열린 질문

• Superstore가 단일 테이블 원자성만 보장하면서도 사용자들이 데이터 일관성을 충분히 이해하고 안전하게 사용할 수 있도록 만든 구체적 UX·문서화·교육 방식은 무엇이었을까?
• Arya 기반 단일 시퀀서 구조에서 쓰기 중단이 발생했을 때, 읽기 전용 전환과 복구 절차는 실제 운영에서 어느 정도 자동화되어 있을까?
• Hive 스케줄링에서 사용자가 복잡한 효용 곡선을 직접 쓰지 않게 하면서도 시간 선호를 잘 표현하게 만드는 API는 어떤 형태가 가장 현실적일까?