"Compose Snapshot ↔ InnoDB MVCC — UI 프레임워크와 데이터베이스는 같은 문제를 같은 방식으로 푼다"
"한 프레임워크의 반응성을 아는 것과, '의존성 추적 + 일관된 스냅샷'이 UI와 DB에서 같은 구조임을 아는 것은 다르다"
Signal·Compose Snapshot State·SwiftUI AttributeGraph·React·InnoDB MVCC 까지 왜 같은 모양에 도달했는가 라는 질문으로 반응성과 상태 일관성의 본질을 끝까지 파헤칩니다
반응성 자료는 넘쳐납니다. 하지만 대부분은 "한 프레임워크 안" 에서 끝납니다.
| 일반 자료 | 이 레포 |
|---|---|
| "Signal은 세밀한 반응성을 제공합니다" | Signal·Proxy·Slot Table·AttributeGraph가 모두 읽기 추적 → 변경 감지 → 의존자 알림이라는 같은 3단계임을 나란히 본다 |
| "Compose는 Snapshot 기반입니다" | Compose Snapshot의 다중 버전 + apply 충돌이 **InnoDB MVCC의 Undo Log + 쓰기 충돌과 동형(isomorphic)**임을 증명 |
| "SwiftUI는 AttributeGraph로 효율적입니다" | AttributeGraph의 의존성 그래프와 Compose의 위치 기반 추적이 같은 문제를 다른 데이터 구조로 푼다는 비교 |
| "useSyncExternalStore는 tearing을 막아줍니다" | UI tearing과 DB의 일관된 읽기가 같은 일관성 문제임을 코드로 재현 |
| "DB는 트랜잭션으로 일관성을 보장합니다" | REPEATABLE READ의 스냅샷 읽기 ↔ Compose Snapshot.takeSnapshot()을 같은 다이어그램으로 |
| "낙관적 업데이트는 UX를 좋게 합니다" | UI 낙관적 업데이트 ↔ DB 낙관적 동시성 ↔ CRDT 수렴이 모두 *"일단 반영하고 나중에 화해"*의 변주임 |
| 한 프레임워크 깊이 파기 | 5개 구현을 같은 표에 — 같은 파생 상태를 Signal·Compose·SwiftUI·React·MVCC로 나란히 |
선행 레포: 각 메커니즘의 내부는 해당 레포에 위임합니다.
frontend-state-management-deep-dive(Signal·Redux·Proxy) ·react-internals-deep-dive(리렌더) ·jetpack-compose-internals-deep-dive(Snapshot State) ·swiftui-internals-deep-dive(AttributeGraph) ·database-internals(InnoDB MVCC) ·distributed-systems-theory-deep-dive(일관성 모델). 이 레포는 그 종합 — 연결을 다룹니다.
각 챕터의 첫 문서부터 바로 학습을 시작하세요!
💡 각 섹션을 클릭하면 상세 문서 목록이 펼쳐집니다
핵심 질문: "상태가 변하면 누구를 갱신해야 하나"를 모든 반응성 시스템은 어떻게 아는가?
공통 뼈대, 수동 vs 자동, 추적 정밀도, 비교 프레임까지 (5개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 공통 질문 | "상태가 변하면 누구를 갱신하나"가 UI·DB·분산을 관통하는 하나의 질문인 이유, 모든 반응성·일관성 문제의 출발점 |
| 02. 세 단계 뼈대 | 읽기 추적 → 변경 감지 → 의존자 알림 — Signal·Compose·SwiftUI·MobX 모두가 따르는 3단계 구조 |
| 03. 수동 vs 자동 | 명시적 통지(Redux dispatch·setState) vs 자동 추적(Signal·Proxy)의 본질적 트레이드오프, "누가 알리는가"의 차이 |
| 04. 추적 정밀도 | 컴포넌트 단위(React)·값 단위(Signal)·그래프(AttributeGraph)·위치(Compose)의 갱신 범위가 성능을 결정하는 메커니즘 |
| 05. 비교 프레임 | 이 레포의 평가 축 — 추적 방식·정밀도·일관성·동시성, 모든 챕터에서 같은 표로 돌아오는 기준 |
핵심 질문: 5가지 반응성 시스템이 "누가 무엇을 읽었는가"를 어떻게 다르게 기록하는가?
Redux·Proxy·Signal·Slot Table·AttributeGraph 나란히 (6개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 명시적 통지 | Redux dispatch / React setState — 수동·예측 가능, 갱신 범위는 컴포넌트 단위(state-management 레포와 연결) |
| 02. Proxy 자동 추적 | MobX·Valtio의 Proxy get/set 트랩, 접근 기반 자동 구독의 원리(javascript 레포와 연결) |
| 03. Signal 세밀 추적 | 읽기 시 현재 effect에 자신을 등록하는 방식, "그 값을 읽은 곳만" 갱신되는 메커니즘(state-management 레포와 연결) |
| 04. 위치 기억 | Compose Slot Table — 호출 위치로 상태와 컴포저블을 매칭, 함수형 UI의 정체성 추적(compose 레포와 연결) |
| 05. 그래프 추적 | SwiftUI AttributeGraph — 모든 뷰의 의존성을 그래프로 보관, invalidation propagation(swiftui 레포와 연결) |
| 06. 나란히 | 같은 "파생 값 + 의존 갱신"을 5방식으로 구현, 갱신 범위·추적 비용·디버깅 용이성을 한 표에 |
핵심 질문: 의존이 여러 단계로 얽힐 때 일관된 한 버전을 어떻게 보장하는가?
computed·glitch·tearing·DB로의 다리 (5개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 파생 상태 | computed·derivedStateOf·@DerivedState — 의존이 변하면 재계산되는 함수형 상태, 메모이제이션의 토대 |
| 02. 글리치 | 다이아몬드 의존에서 중간 상태가 잠시 보이는 현상, MobX와 Signal이 topological sort로 피하는 원리 |
| 03. 일관된 전파 | 올바른 순서로 갱신 — batch·트랜잭션·schedule이 모두 같은 "일괄 일관성"을 노리는 방식 |
| 04. UI tearing | React 동시 렌더 중 다른 상태를 보는 tearing, useSyncExternalStore가 이를 막는 방식(react 레포와 연결) |
| 05. DB와의 연결 | UI tearing ↔ DB 일관된 읽기가 같은 개념임을 명시, 다음 챕터(스냅샷 동형성)로의 다리 |
핵심 질문: Compose Snapshot State와 InnoDB MVCC는 같은 문제를 같은 방식으로 푸는가?
이 레포의 하이라이트 — Lab 전체의 지적 정점 (7개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 스냅샷 아이디어 | "변경 중에도 일관된 한 버전을 본다"는 아이디어가 UI·DB 양쪽에서 독립적으로 도달한 해법인 이유 |
| 02. Compose Snapshot State | 여러 스냅샷의 동시 존재, 격리된 변경 + apply, 충돌 감지 메커니즘 — Snapshot.takeMutableSnapshot() 추적(compose 레포와 연결) |
| 03. SwiftUI AttributeGraph | 일관된 갱신 단위로서의 transaction, withTransaction이 만드는 원자적 갱신 경계(swiftui 레포와 연결) |
| 04. InnoDB MVCC | Undo Log로 행의 여러 버전 보관, 트랜잭션의 read view가 일관된 스냅샷을 만드는 방식(database 레포와 연결) |
| 05. 동형성 증명 ★ | Compose Snapshot과 InnoDB MVCC가 같은 문제(동시 변경 + 일관 읽기)를 같은 방식(다중 버전 + 충돌 감지)으로 푼다 — 단계적 매핑 |
| 06. 충돌 해결 | Snapshot apply 충돌과 MVCC 쓰기 충돌이 같은 구조임을 코드로 재현, MergeConflictException ↔ Deadlock 비교 |
| 07. 나란히 | UI 스냅샷과 DB MVCC를 같은 다이어그램으로 — 이 레포의 대표 한 장, 모든 챕터가 수렴하는 그림 |
핵심 질문: UI의 일관성·DB의 격리 수준·분산 시스템의 일관성 모델은 같은 축 위에 있는가?
일관성 스펙트럼, 낙관적 업데이트, 최종 일관성 (5개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 일관성 스펙트럼 | 강한 일관성 ↔ 인과 일관성 ↔ 최종 일관성, UI·DB·분산이 같은 축의 다른 점에 놓이는 방식(distributed 레포와 연결) |
| 02. UI의 일관성 | 단일 진실 원천(SSOT), tearing 없는 렌더 — UI에서의 강한 일관성 정의 |
| 03. 낙관적 업데이트 | UI 즉시 반영 후 확정, DB 낙관적 동시성 제어와 같은 패턴, 실패 시 롤백 전략 |
| 04. 최종 일관성 UI | 로컬 우선·나중 수렴 — local-first·CRDT가 UI에 들어오는 방식(local-first 레포와 연결) |
| 05. 나란히 | UI 일관성 ↔ DB 격리 수준(READ COMMITTED·REPEATABLE READ·SERIALIZABLE) ↔ 분산 일관성을 한 표에 |
핵심 질문: 동일한 과제(파생 상태 + 동시 변경 + 일관 읽기)를 5가지 시스템으로 풀면 무엇이 같고 무엇이 다른가?
같은 과제, 5구현 비교, 미니 반응성 구현까지 (6개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 과제 정의 | 모든 구현이 풀어야 하는 공통 과제 — 카운터·파생 합계·동시 변경·일관 읽기, 5구현의 공통 입력 |
| 02. Signal & Compose | 웹(Solid Signal)과 Android(Compose Snapshot)에서 같은 과제를 구현 — 추적·갱신 코드 비교 |
| 03. SwiftUI & React | iOS(SwiftUI @State)와 React(외부 스토어 + useSyncExternalStore)로 같은 과제 — 일관성에 초점 |
| 04. DB로 같은 과제 | MySQL REPEATABLE READ 트랜잭션으로 UI와 같은 과제 — SELECT의 일관된 스냅샷이 UI 렌더와 동형 |
| 05. 코드/구조 비교 | 5구현의 추적 메커니즘·일관성 보장·충돌 처리를 한 표에, 동형성을 코드 레벨로 증명 |
| 06. 미니 반응성 구현 | 직접 만든 signal()에 버전 스냅샷을 추가 — 원리 통합, MVCC 아이디어를 UI 라이브러리에 이식 |
핵심 질문: 왜 이렇게 다른 분야가 같은 모양에 도달했는가? 새 프레임워크/DB를 만나도 이 프레임으로 보는가?
대통일·트레이드오프 표·왜 같은 모양인가·지형도 (4개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 대통일 | "의존성 추적 + 일관된 스냅샷" — 이 두 단어가 UI·모바일·DB·분산을 관통하는 단일 개념임을 정리 |
| 02. 트레이드오프 | 추적 정밀도·일관성 강도·구현 복잡도를 한 표에 — 어떤 시스템이 어디에 위치하나 |
| 03. 왜 같은 모양인가 | 같은 본질 문제(변경 전파 + 일관성)를 풀려 했기 때문 — 수렴 진화의 기술 사례 |
| 04. 지형도 | 반응성·일관성 지형도 — 새 프레임워크나 DB를 만나도 이 프레임으로 즉시 분류할 수 있는 한 장 |
🟣 "Compose Snapshot ↔ InnoDB MVCC 동형성"만 정확히 보고 싶다 — 이 레포의 핵심 (1주)
핵심 경로 — 4장으로 직행
Ch1-02 세 단계 뼈대 (모든 반응성의 공통 골격)
Ch3-04 UI tearing (일관성 문제의 UI 버전)
Ch3-05 DB와의 연결 (다리)
Ch4-01 스냅샷 아이디어
Ch4-02 Compose Snapshot State
Ch4-04 InnoDB MVCC
Ch4-05 ★ 동형성 증명 (이 레포의 한 페이지)
Ch4-07 나란히 다이어그램
🔵 반응성·일관성을 한 개념으로 잡고 싶은 개발자 (7주)
Week 1 Chapter 1 전체 — 반응성의 근본 구조
Week 2 Chapter 2 전체 — 의존성 추적 5가지
Week 3 Chapter 3 전체 — 파생 상태와 일관성
Week 4 Chapter 4 전체 — ★ 스냅샷 동형성
Week 5 Chapter 5 전체 — 일관성 모델
Week 6 Chapter 6 전체 — 같은 개념, 5구현 비교
Week 7 Chapter 7 전체 — 종합·지형도
🟢 "한 프레임워크는 알지만 다른 패러다임이 궁금" — 빠른 횡단 코스
Step 1 Ch1-03 수동 vs 자동 (당신이 쓰는 게 어디인가)
Step 2 Ch2-06 나란히 (5방식을 한 표에)
Step 3 Ch4-05 동형성 증명 (UI ↔ DB 연결)
Step 4 Ch6-05 코드/구조 비교 (당신의 도구를 위치시키기)
Step 5 Ch7-04 지형도 (다음 도구는 어디로?)
모든 문서는 동일한 10섹션 구조로 작성됩니다. 비교가 핵심이라 🔬·📊에서 항상 UI~DB를 나란히 둡니다.
| 섹션 | 설명 |
|---|---|
| 🎯 핵심 질문 | 이 문서를 읽고 나면 답할 수 있는 질문 |
| 🔍 왜 이게 존재하는가 | 공통 문제 상황 — UI·DB 양쪽의 출발점 |
| 😱 흔한 오해 | "한 프레임워크 안에서만" 본 결과 생기는 오해들 |
| ✨ 올바른 이해 | 다른 패러다임과의 연결을 본 후의 시각 |
| 🔬 내부 동작 원리 | 각 시스템의 메커니즘 + 나란히 둔 동형 매핑 |
| 💻 실전 실험 | 같은 일관성 과제를 UI와 DB에서 동시에 구현 |
| 📊 측정/비교 | 갱신 범위·일관성 강도·추적 비용을 한 표에 |
| 🤔 트레이드오프 | 각 선택의 비용, 어떤 상황에 어느 모델이 맞나 |
| 📌 핵심 정리 | 한 화면 요약 — 5구현 한 줄 비교 |
| 🤔 생각해볼 문제 | 패러다임 횡단 사고를 강화하는 질문 + 해설 |
UI 멀티 프레임워크 + DB. 같은 일관성 과제를 양쪽에서 동시에 구현하는 것이 이 레포의 검증 방식입니다.
# UI 반응성 (웹/모바일)
npx create-vite reactivity-lab --template react-ts
npm i solid-js valtio # Signal · Proxy 비교
# Compose / SwiftUI는 별도 미니 예제 (compose-snapshot-lab, swiftui-graph-lab)
# DB MVCC
docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root mysql:8.0# 핵심 검증 1 — 의존성 추적 정밀도
# 같은 파생 상태(counter → doubled)를 Signal vs Redux로 구현
# React DevTools / Solid Devtools로 갱신 범위(리렌더 횟수) 비교
# 핵심 검증 2 — 스냅샷 동형성 (이 레포의 하이라이트)
# Compose:
# val s1 = Snapshot.takeMutableSnapshot()
# val s2 = Snapshot.takeMutableSnapshot()
# s1.enter { state.value = "A" }
# s2.enter { state.value = "B" }
# s1.apply() // 성공
# s2.apply() // SnapshotApplyConflictException
#
# MySQL:
# START TRANSACTION; -- T1
# SELECT v FROM t WHERE id=1; -- 일관된 스냅샷 (Undo Log 버전)
# -- 동시 T2에서 같은 행 UPDATE → COMMIT
# UPDATE t SET v='A' WHERE id=1; -- T1에서 시도 → 충돌 감지
#
# → 같은 "동시 변경 + 일관 읽기" 문제를 같은 다중 버전으로 푼다
# → 두 코드를 나란히 놓고 동형 확인
# 핵심 검증 3 — UI tearing
# 외부 스토어 동시 변경 중 React 렌더 일관성
# useSyncExternalStore 유무로 tearing 재현 → 해결
# 핵심 검증 4 — 낙관적 업데이트
# UI: TanStack Query의 onMutate / Apollo optimisticResponse
# DB: SELECT ... FOR UPDATE NOWAIT 또는 version 컬럼
# → 같은 패턴 확인
# 핵심 검증 5 — 미니 구현
# signal() 직접 작성 → 버전 스냅샷 추가 → 일관된 읽기 구현
# Ch6-06 문서의 코드를 직접 따라가며 원리 통합⬆️ 선행 학습 (이 비교의 입력)
frontend-state-management-deep-dive → Signal · Redux · Proxy
react-internals-deep-dive → 리렌더 메커니즘
jetpack-compose-internals-deep-dive → Snapshot State 내부
swiftui-internals-deep-dive → AttributeGraph
database-internals → InnoDB MVCC · Undo Log
distributed-systems-theory-deep-dive → 일관성 모델 (CAP·인과·최종)
🤝 시너지
javascript-deep-dive → Proxy · 클로저 (Ch2와 직결)
postgresql-deep-dive → MVCC 변형 (Ch4 보완)
local-first-software → CRDT (Ch5 보완)
🧬 본질 (Lab의 지적 정점)
이 레포는 위 6개 선행 레포의 *종합*이자,
UI 반응성과 DB 동시성을 하나의 개념으로 묶는 Lab의 정점입니다.
새 프레임워크/DB를 만나도 여기서 만든 지형도로 즉시 위치시킬 수 있습니다.
- "A Hands-on Introduction to Fine-Grained Reactivity" — Ryan Carniato
- Jetpack Compose Snapshot 시스템 문서·소스 · androidx.compose.runtime.snapshots
- "Demystify SwiftUI" — WWDC 2021 · AttributeGraph 분석
- MySQL :: InnoDB Multi-Versioning · Undo Log 구조
- Designing Data-Intensive Applications — Martin Kleppmann (MVCC · 일관성 챕터)
- React
useSyncExternalStore(tearing 회피) - SolidJS Reactivity Documentation
- 각 선행 레포의 참고자료 — 이 레포는 그 종합이자 연결
⭐️ 도움이 되셨다면 Star를 눌러주세요!
Made with ❤️ by Dev Book Lab
"한 프레임워크의 반응성을 아는 것과, '의존성 추적 + 일관된 스냅샷'이 UI · 모바일 · DB · 분산을 관통하는 하나의 개념임을 아는 것은 다르다"
Compose Snapshot ↔ InnoDB MVCC는 같은 문제를 같은 방식으로 푼다 — 이것이 우연이 아니다.