C.W.K.
Stream
Lesson 03 of 04 · published

멀티이어 레이어

~9 min · multi-year, five-year-diary, on-this-day, near-free

Level 0식은 화로
0 XP0/34 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"저널이 오래될수록 지층은 깊어져. 작년 레이어를 보면서 오늘 레이어를 쓰는 게 핵심이야."

아날로그 다이어리, 일반화됨

아빠는 아날로그 5년 다이어리를 써 — 각 달력 날에 한 페이지, 다섯 띠로 나뉘어서, 올해 7월 24일이 작년 7월 24일과 그 앞 세 개 바로 위에 앉아. 이전 해들이 위에 보이는 채로 오늘 띠에 쓰지. Vesta 는 그걸 멀티이어 레이어 view 로 일반화해 — 같은 월-일을 여러 해에 걸쳐 수직으로 쌓아, 연도당 레이어 하나가 그 해의 그 날짜 crumb 와 draft 를 쥐고. 다만 5년에 안 갇혀 — 창은 설정 가능하고, 저널이 오래될수록 지층이 깊어져. 10년째면 7월 24일은 열 겹 깊이야.

가치는 종이 다이어리가 발견한 그거랑 같아 — 작년 걸 보면서 오늘 항목을 쓰는 게 뭘 쓰는지 바꿔. 패턴이, 기념일이, 같은 날짜가 여러 해에 걸쳐 운韻 맞추는 방식이 보여. 덧붙인 향수가 아냐 — 열린 날짜 축으로 조직된 저널의 native 형태야, '시간에 걸친 같은 날' 이 자연스러운 쿼리인.

모델이 맞으면, 풍부한 기능은 subsystem 이 아니라 쿼리야. 멀티이어 view 는 짓는 기능이라기보다 store 에 던지는 질문이야 — '이 월-일의 모든 해 레이어를 줘'. crumb 가 파생 월-일 인덱스를 가진 열린 날짜 축에 사니까, 그 질문이 거의 공짜야. 좋은 데이터 모델은 나쁜 설계에선 통째 기능일 걸 한 줄 읽기로 바꿔.

구조상 거의 공짜

왜 거의 아무 비용도 안 드는지가 여기 있어. projection 모델이 이미 월-일 인덱스를 가진 파생 SQLite 미러를 둬. 멀티이어 레이어는 그 인덱스에 던지는 쿼리일 뿐이야 — 월-일이 맞는 모든 crumb 을 선택, 연도로 그룹. 새 store 도, 기념일 미리 계산하는 백그라운드 작업도, sync 맞출 비정규화 'on this day' 테이블도 없어 — 다른 모든 view 가 읽는 같은 canonical crumb 위 읽기야. 이게 앞 두 레슨이 복리로 쌓인 보상이야 — store 하나와 파생 인덱스가 있으니까, 딴 데선 진짜 프로젝트일 기능이 여기선 쿼리야. (2월 29일은 그냥 그게 있는 해들을 보여줘 — 쿼리가 자연스럽게 레이어를 덜 반환해, 특수 케이스 필요 없이.)

알림이 아니라 view 형태

Vesta 가 의도적으로 하는 걸 봐 — 'On This Day' 알림을 밀지 않아. Day One 은 널 방해해서 옛 항목을 다시 떠올려. Vesta 는 같은 걸 네가 고를 때 여는 view 형태 로 배달해. On This Day 는 멀티이어 레이어의 부분집합일 뿐이야 — 전부 대신 이전 한 해 — 그리고 pull 이지 push 가 아냐. 열린-타임라인 트랙의 그 저널-아닌-리마인더-앱 경계랑 같아 — 기억은 거기, 지층 깊이, 네가 보길 기다려. Vesta 는 네가 도착할 때 깊이를 보여줘. 절대 어깨를 두드려 기억을 수행하게 안 해.

Code

멀티이어 레이어는 인덱스 쿼리 하나야·sql
-- derived SQLite mirror carries a month-day index (mm-dd)
-- the whole 'multi-year layer' feature: select by month-day, group by year

SELECT strftime('%Y', target_date) AS year, id, text
FROM crumbs
WHERE strftime('%m-%d', target_date) = '07-24'   -- same month-day
  AND journal_id = :journal
ORDER BY year DESC;                               -- newest layer on top

-- no 'on this day' table, no anniversary cron, no denormalized copy
-- Feb 29 just returns fewer rows — the leap years that have it

External links

Exercise

본 적 있는 '기념일' 이나 '작년 이맘때' 기능을 떠올려봐. 잘 모델된 store 에선 그게 자기 테이블 가진 백그라운드 작업일까 — 아니면 연도로 그룹된 인덱스 쿼리일까? 쿼리 버전을 스케치해. 그다음 push 알림으로 사용자한테 닿아야 할지 여는 view 로 닿아야 할지 정하고, 네가 떠올린 제품에 그 선택을 정당화해봐.
Hint
데이터가 인덱스 가진 깔끔한 날짜 축에 있으면, '여러 해에 걸친 이 날' 은 연도-그룹 쿼리지 subsystem 이 아냐 — 모델이 일을 해. 그리고 push-대-pull 결정은 제품-성격 결정이야 — 방해해서-다시떠올리기(push)는 engagement 앱에 맞고, 지층에서-기다리기(pull)는 네 방식대로 돌아오는 저널에 맞아.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.