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라는 데 있어.