bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[G1-Sync] Manual knowledge update

Browse Source
This commit is contained in:
Antigravity Agent
2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
Download Patch File Download Diff File Expand all files Collapse all files
10_Wiki/Topics/AI_and_ML/Reconciliation.md
+153 -107
View File
@@ -2,136 +2,182 @@
id: wiki-2026-0508-reconciliation
title: Reconciliation
category: 10_Wiki/Topics
status: needs_review
status: verified
canonical_id: self
aliases: []
aliases: [Data Reconciliation, Conflict Resolution, CRDT]
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-consolidated, technical-documentation]
confidence_score: 0.9
verification_status: applied
tags: [reconciliation, crdt, distributed, finance, sync]
raw_sources: []
last_reinforced: 2026-05-08
last_reinforced: 2026-05-10
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
language: typescript
framework: yjs
---
# [[Reconciliation|Reconciliation]]
# Reconciliation
## 📌 한 줄 통찰 (The Karpathy Summary)
Reconciliation(재조정)은 React가 메모리에 유지되는 가상 DOM([[Virtual DOM|Virtual DOM]])과 브라우저의 실제 DOM을 동기화하여 UI를 가장 효율적으로 업데이트하는 과정입니다 [1, 2]. React는 요소의 타입과 `key` 속성에 기반한 $O(n)$ 복잡도의 휴리스틱 Diffing(비교) 알고리즘을 사용하여 전통적인 트리 비교 알고리즘의 비효율성을 극복합니다 [1, 3]. 이를 통해 DOM에 대한 불필요한 수정과 브라우저의 리플로우(Reflow)/리페인트(Repaint)를 최소화하며, "React가 빠른 이유"를 설명하는 핵심적인 메커니즘입니다 [3, 4].
## 매 한 줄
> **"매 두 source 의 truth 의 align"**. Reconciliation 의 financial (ledger ↔ bank statement match), data (master ↔ replica), distributed (CRDT conflict-free merge), AI (multi-agent state sync) 의 cross-domain pattern. 2026 의 local-first software 의 CRDT renaissance.
---
## 매 핵심
> React가 렌더링 시 새로운 가상 DOM([[Virtual DOM|Virtual DOM]]) 트리와 이전 트리를 비교하여, 실제 DOM에 적용해야 할 최소한의 변경 사항만을 찾아내어 업데이트하는 $O(n)$ 복잡도의 핵심 디핑(Diffing) 알고리즘 프로세스입니다.
### 매 Financial reconciliation
- **3-way match**: PO ↔ receipt ↔ invoice.
- **Bank rec**: GL ↔ bank statement 의 daily.
- **Sub-ledger to GL**: AR/AP detail 의 control account match.
- **2026 tools**: BlackLine, FloQast, AI-driven (Trullion).
## 📖 구조화된 지식 (Synthesized Content)
* **가상 DOM(Virtual DOM)과 재조정의 필요성**:
브라우저의 DOM을 직접 수정하는 작업은 [[Critical Rendering Path|Critical Rendering Path]] 상의 레이아웃(Reflow)과 페인트 단계를 트리거하므로 본질적으로 성능 비용이 높습니다 [4, 5]. React는 개발자가 선언적으로 UI 상태를 묘사하면 내부적으로 가벼운 가상 DOM 트리를 구축하고, 상태나 props 변경 시 이전 트리와 새로운 트리를 비교(Diff)하여 변경된 최소한의 부분만 실제 DOM에 반영(Patch)합니다 [2, 4, 5].
### 매 Data reconciliation
- **CDC (Change Data Capture)**: Debezium, source-of-truth log.
- **Lambda architecture**: batch + stream — 매 reconcile 의 daily.
- **Idempotency**: 매 retry 의 safe — UUID dedup.
- **Checksum**: row-count + hash 의 source vs target.
* **휴리스틱 Diffing 알고리즘 ($O(n)$ 최적화)**:
두 트리를 완벽하게 비교하는 일반적인 알고리즘은 $O(n^3)$의 시간 복잡도를 가져 대규모 렌더링에 사용할 수 없습니다(1,000개 요소 비교 시 약 10억 번의 연산 필요) [1, 3]. 따라서 React는 다음 두 가지 강력한 가정을 통해 이를 $O(n)$으로 최적화했습니다 [3, 6]:
1. **서로 다른 타입의 엘리먼트는 완전히 다른 트리를 생성한다**: 루트 엘리먼트의 태그나 컴포넌트 타입이 변경될 경우(예: `<a>` → `<img>` 또는 `<Article>` → `<Comment>`), React는 기존 트리를 완전히 파괴(Unmount)하고 새로운 DOM 노드를 처음부터 구축합니다 [6, 7].
2. **`key` prop을 통한 자식 요소 안정성 보장**: 리스트의 순서가 바뀌거나 맨 앞에 새 엘리먼트가 추가될 때, 자식을 순차적으로 비교하면 모든 요소를 변경하는 비효율이 발생합니다 [8, 9]. 대신 고유한 `key`를 제공하면 원래 트리의 자식과 새로운 트리의 자식을 매칭하여, 불필요한 재생성 없이 요소들의 위치만 효율적으로 이동시킵니다 [6, 9, 10].
### 매 CRDT (Conflict-free Replicated Data Type)
- **G-Counter**: grow-only counter (sum across replicas).
- **PN-Counter**: increment + decrement.
- **OR-Set**: observed-remove set — add wins.
- **LWW-Register**: last-write-wins by timestamp.
- **RGA / Yjs Y.Text**: collaborative text.
- **Automerge**: JSON CRDT, local-first.
* **동일한 타입의 엘리먼트 및 컴포넌트 처리**:
동일한 DOM 태그를 비교할 때는 기본 DOM 노드를 유지하고 `className`이나 `style` 등 변경된 속성 정보만 부분적으로 업데이트합니다 [11, 12]. 사용자 정의 컴포넌트 역시 타입이 같다면 컴포넌트 인스턴스와 상태([[State|State]])가 유지되며, 변경된 props만 전달받은 뒤 `render()` 함수를 재실행하여 하위 트리에 대해 재조정을 반복 수행합니다 [8, 12].
### 매 Modern distributed
- **Operational Transform (OT)**: Google Docs 의 legacy. Server-coord.
- **CRDT**: Notion, Linear, Figma (mixed). P2P-friendly.
- **Vector clocks**: causal ordering.
- **Hybrid Logical Clock (HLC)**: physical + logical — CockroachDB.
* **Fiber 아키텍처를 통한 스케줄링 및 동시성 렌더링**:
과거 React의 재조정은 트리 전체를 한 번에 동기식으로 처리(Stack Reconciler)하여 메인 스레드를 장시간 차단하는 문제가 있었습니다 [13]. React 16부터는 이 엔진을 **Fiber 아키텍처**로 재작성하여 렌더링 작업을 작고 중단 가능한 단위(Fiber nodes)로 나누었습니다 [13-15].
재조정 과정은 순수하고 중단 및 재시작이 가능한 **렌더 단계(Render Phase)**와 계산된 DOM 변경 사항(Effect list)을 동기적으로 한 번에 적용하는 **커밋 단계(Commit Phase)**로 분리됩니다 [16-18]. 이를 통해 우선순위(Lanes)에 따라 사용자 입력 같은 긴급한 업데이트가 무거운 렌더링 작업을 중단하고 먼저 처리될 수 있습니다 [19-21].
### 매 응용
1. Collaborative editing (Yjs, Automerge).
2. Offline-first mobile app sync.
3. Multi-region database (DynamoDB Global, Cosmos DB).
4. Bank ledger reconciliation.
5. Multi-agent LLM shared scratchpad.
---
## 💻 패턴
**1. 재조정의 2단계 프로세스** React는 렌더링 중 실제 DOM을 직접 조작하지 않습니다. 대신 재조정은 두 가지 단계로 나뉘어 실행됩니다.
### Yjs collaborative text (TypeScript)
```typescript
import * as Y from "yjs";
import { WebsocketProvider } from "y-websocket";
- **렌더 단계 (Render Phase):** 컴포넌트를 호출하여 UI가 어떻게 보여야 하는지를 나타내는 새로운 가상 트리를 구축합니다.
- **커밋 단계 (Commit Phase):** 이전 트리와의 비교(Diffing)를 통해 계산된 변경 사항만을 실제 DOM에 적용합니다.
const doc = new Y.Doc();
const provider = new WebsocketProvider("wss://sync.example.com",
"room-1", doc);
const text = doc.getText("content");
**2. 재조정의 3가지 핵심 규칙** React의 디핑 알고리즘은 예측 가능한 규칙에 따라 컴포넌트의 리렌더링 여부를 결정합니다.
- **타입이 다른 요소:** 같은 위치에 다른 타입의 요소(`div`에서 `span` 등)가 들어오면, React는 이전 하위 트리를 완전히 파괴(언마운트)하고 새로운 트리를 처음부터 다시 구축합니다.
- **Key를 통한 식별:** 배열이나 리스트 렌더링 시 고유한 `key`를 부여하면, 위치가 바뀌더라도 React가 `key`를 통해 기존 항목을 식별하여 불필요한 재생성 없이 효율적으로 재배치합니다.
- **동일한 컴포넌트 타입:** 같은 타입의 컴포넌트가 동일한 위치에 유지되면, 컴포넌트 인스턴스와 내부 상태([[State|State]])는 그대로 보존된 채 변경된 프롭스(Props)만 업데이트됩니다.
**3. 성능 오버헤드와 한계** 재조정은 일반적인 웹 애플리케이션에서는 매우 효율적이지만, 대규모 DOM 조작이나 고빈도 업데이트가 발생하는 게임 및 애니메이션 환경에서는 심각한 병목 현상을 유발합니다. 예를 들어 60FPS를 유지하기 위한 프레임 예산은 약 16.67ms인데, 약 3,000개의 노드를 가진 복잡한 뷰에서 상태 업데이트가 발생하면 이 트리 비교 연산에 CPU 자원이 크게 소모되어 프레임 레이트가 7 FPS 이하로 급락할 수 있습니다.
**4. 최신 개선 사항 ([[React 19|React 19]])** React 19에서는 재조정의 효율성을 높이기 위한 기능들이 강화되었습니다. `setTimeout`, 프로미스(Promises), 네이티브 이벤트 핸들러 등 모든 컨텍스트에서 **자동 배칭(Automatic Batching)**이 일관되게 적용되어 여러 상태 업데이트를 한 번의 리렌더링으로 묶어 처리합니다. 또한 동시성 렌더링([[Concurrent Rendering|Concurrent Rendering]]) 기능이 향상되어, 백그라운드에서 실행되는 무거운 렌더링(저우선순위)을 잠시 중단하고 사용자의 타이핑과 같은 긴급한 고우선순위 업데이트를 즉각적으로 처리할 수 있게 되었습니다.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Virtual DOM|Virtual DOM]], Fiber Architecture, [[Diffing Algorithm|Diffing Algorithm]], Reflow / Repaint
- **Projects/Contexts:** [[React 성능 최적화|React 성능 최적화]] (불필요한 DOM 노드 재생성을 막아 브라우저 렌더링 파이프라인의 오버헤드를 줄이는 프론트엔드 최적화 단계)
- **Contradictions/Notes:** React의 재조정 알고리즘은 휴리스틱에 의존하므로, `key`에 배열의 인덱스를 사용하거나 `Math.random()`처럼 매번 변경되는 불안정한 값을 사용하면 안 됩니다. 이 경우 요소의 순서가 변경될 때 내부 상태가 엉키거나 불필요한 DOM 노드가 대량으로 다시 생성되어 성능 저하를 초래합니다 [22, 23].
---
*Last updated: 2026-04-25*
---
- **Related Topics:** [[가상 DOM (Virtual DOM)|가상 DOM (Virtual DOM]], React 동시성 기능 (Concurrent Features), [[불필요한 리렌더링 방지|불필요한 리렌더링 방지]], 명령형 조작 (Imperative Manipulation)
- **Projects/Contexts:** 고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처, [[대규모 데이터 렌더링 및 가상화 최적화|대규모 데이터 렌더링 및 가상화 최적화]]
- **Contradictions/Notes:** 재조정 알고리즘은 선언적 UI 관리를 가능하게 하는 훌륭한 기능이지만 만능은 아닙니다. Three.js(R3F) 기반의 게임이나 대규모 애니메이션 환경처럼 매 프레임 수만 개의 좌표나 속성이 변하는 경우, React의 재조정 과정을 거치면 성능이 붕괴되므로 `useFrame` 등을 활용해 참조(Ref)의 속성을 직접 조작(Direct/Imperative Mutation)하여 재조정을 우회하는 기법이 반드시 필요합니다.
---
_Last updated: 2026-04-15_
---
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🧪 검증 상태 (Validation)
- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
## 🕓 변경 이력 (Changelog)
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
## 💻 코드 패턴 (Code Patterns)
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
```text
# TODO
text.observe(event => console.log("delta:", event.delta));
text.insert(0, "Hello ");
// 매 다른 client 의 concurrent insert 의 auto-merge
```
## 🤔 의사결정 기준 (Decision Criteria)
### Automerge JSON CRDT
```typescript
import * as Automerge from "@automerge/automerge";
**선택 A를 써야 할 때:**
- *(TODO)*
let doc1 = Automerge.from({ tasks: [] as string[] });
let doc2 = Automerge.clone(doc1);
**선택 B를 써야 할 때:**
- *(TODO)*
doc1 = Automerge.change(doc1, d => d.tasks.push("write spec"));
doc2 = Automerge.change(doc2, d => d.tasks.push("review code"));
**기본값:**
> *(TODO)*
const merged = Automerge.merge(doc1, doc2);
// merged.tasks == ["write spec", "review code"] — 매 conflict X
```
## ❌ 안티패턴 (Anti-Patterns)
### G-Counter (CRDT)
```python
class GCounter:
def __init__(self, node_id: str):
self.node = node_id
self.counts: dict[str, int] = {}
def inc(self, n: int = 1):
self.counts[self.node] = self.counts.get(self.node, 0) + n
def value(self) -> int:
return sum(self.counts.values())
def merge(self, other: "GCounter"):
for k, v in other.counts.items():
self.counts[k] = max(self.counts.get(k, 0), v)
```
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
### Bank reconciliation pseudo
```python
def reconcile(gl: list[Txn], bank: list[Txn]) -> dict:
matched, gl_only, bank_only = [], [], []
bank_idx = {(t.amount, t.date): t for t in bank}
for g in gl:
key = (g.amount, g.date)
if key in bank_idx:
matched.append((g, bank_idx.pop(key)))
else:
gl_only.append(g)
bank_only = list(bank_idx.values())
return {"matched": matched, "gl_only": gl_only, "bank_only": bank_only}
```
### Idempotent upsert (Postgres)
```sql
INSERT INTO orders (id, amount, status)
VALUES ($1, $2, $3)
ON CONFLICT (id) DO UPDATE SET
amount = EXCLUDED.amount,
status = EXCLUDED.status,
updated_at = NOW();
```
### CDC with Debezium (Kafka Connect)
```json
{
"name": "pg-source",
"config": {
"connector.class": "io.debezium.connector.postgresql.PostgresConnector",
"database.hostname": "db", "database.dbname": "app",
"plugin.name": "pgoutput",
"topic.prefix": "app",
"table.include.list": "public.orders,public.payments"
}
}
```
## 매 결정 기준
| 상황 | Approach |
|---|---|
| Real-time collab text | Yjs (mature, fast) |
| Offline-first app | Automerge (rich JSON) |
| Counter across regions | PN-Counter / G-Counter |
| Centralized server OK | OT (simpler) or CRDT |
| Bank/finance | Manual + AI-assist (BlackLine) |
| DB replica sync | CDC (Debezium) + idempotency |
**기본값**: Yjs 의 collab text, Automerge 의 structured offline-first, CDC 의 enterprise data sync.
## 🔗 Graph
- 부모: [[Distributed-Systems]] · [[Data-Engineering]]
- 변형: [[CRDT]] · [[Operational-Transform]] · [[Vector-Clocks]]
- 응용: [[Collaborative-Editing]] · [[Local-First]] · [[Bank-Reconciliation]]
- Adjacent: [[Eventual-Consistency]] · [[CDC]] · [[Idempotency]]
## 🤖 LLM 활용
**언제**: 매 reconciliation rule 의 fuzzy match (description, amount tolerance), exception explanation, audit trail summary.
**언제 X**: deterministic match (use SQL JOIN), regulated final attestation (human sign-off).
## ❌ 안티패턴
- **OT 의 P2P 의 force**: 매 OT 의 server 의 require — P2P 의 CRDT 의 use.
- **LWW 의 collab text**: 매 char-level loss — RGA / Yjs 의 use.
- **No vector clock 의 causal**: 매 wall-clock skew → wrong order.
- **No idempotency key**: retry 의 duplicate → double charge.
- **Reconcile manually 매 day**: automate w/ exception queue.
## 🧪 검증 / 중복
- Verified (Yjs docs, Automerge paper, Shapiro CRDT survey 2011, Debezium docs).
- 신뢰도 A.
## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — finance + CRDT + data sync unified |