projection 추가하기

"새 view 는 배선할 새 기능이 아냐. model 한테 새 질문을 하는 reader 하나가 더 붙는 거야."

하나의 model 이 주는 보상

이 트랙 전부가 실용적 보상을 향해 쌓여왔어. 하나의 canonical model 이 있고 모든 표면이 그 projection 이면, 새 view 추가가 싸고 안전해. 새 projection 은 자기 저장소도, 자기 sync 로직도, 여행 사본도 필요 없어. 딱 하나 필요해: canonical state 를 읽고 렌더하는 방법. globe, place lens, planned-geometry 레이어, 피로 heatmap, '엄마가 좋아한 곳' 필터 — 각각 그냥 reader 하나 더고, 아무도 안 쓰니까 아무도 서로를 손상 못 해.

두 세계 비교

marker-DB 설계에선, 새 view 마다 작은 악몽이야: 자기 store 가 필요하고, 다른 것들과 sync 유지해야 하고, 모든 write 경로가 그걸 갱신하는 걸 기억해야 해. view 다섯 개 추가하면 조용히 안 맞아질 수 있는 게 다섯 개야. 하나-model 설계에선, 다섯 개 추가하면 같은 truth 의 reader 가 다섯 개 — drift 할 대상이 없으니 drift 못 해. 새 projection 의 비용이 '새 동기화 DB' 에서 '새 query 와 렌더' 로 붕괴해. 그건 사소한 최적화가 아냐. 지리를 고정된 화면 세트가 아니라 자라나는 계층으로 만드는 거야.

왜 미래 ring 이 싼가

이게 바로 Waystone 가 Journey Map 을 먼저 출시하고 Globe 와 Place Lens 를 아무 불안 없이 미래 ring 으로 남길 수 있는 이유야. 그 ring 들은 새 인프라에 막혀 있지 않아 — 걔들이 읽을 canonical state 가 이미 존재해. Globe 가 오면 'globe DB' 를 추가하는 게 아냐. 이미 있는 journey 와 flag 위에 globe reader 를 추가하는 거야. 앞서 지불한 하나-model 규율이 모든 미래 view 를 새 subsystem 대신 작은 추가로 만들어. 여기서 다형성은 추상적 미덕이 아냐 — 로드맵이 감당 가능한 이유야.

Code

새 view 의 비용, 두 설계·text

MARKER-DB 설계                    하나-MODEL 설계
----------------------------------------------------------
새 view 가 필요로 하는 것:         새 view 가 필요로 하는 것:
  - 자기 store                       - canonical state 위 query
  - 다른 모든 view 와 sync           - 렌더
  - 모든 write 경로에 슬롯

view 5개 = drift 하는 5개        view 5개 = reader 5개, drift 0

# add_projection(model):
#     data = model.query(...)   # 읽기만
#     render(data)              # 저장 없음, sync 없음, write 없음
# 그게 비용 전부야. Globe 와 Place Lens 가 이거야.

Exercise

네 누적 데이터 위에 원하는 새 view 하나를 상상해봐 — heatmap, timeline, 필터된 목록. 지금 도구에서 그걸 추가한다는 건 새 동기화 store 를 짓는 거야, 아니면 이미 있는 데이터 위에 새 query 를 쓰는 거야? 그 답이 네가 여러 reader 를 가진 하나의 model 을 가졌는지, 아니면 합의하는 척하는 작은 DB 여럿을 가졌는지 말해줘.

Hint

데이터를 보는 새 방식이 데이터 재입력이나 재sync 를 요구하면, 넌 하나의 model 이 아니라 사본을 가진 거야. 하나-model-여러-view 의 가치 전부가 다음 view 가 마이그레이션이 아니라 query 라는 거야.