과거를 다시 쓰지 마라

"앞으로 나아가며 기록을 고칠 순 있어. 그때 뭘 알았는지를 뒤로 손 뻗어 바꿀 순 절대 없어."

가장 어려운 규칙

이 트랙 전부가 말하긴 쉽고 지키긴 어려운 한 규칙으로 수렴해: 회고는 그때 알던 걸 절대 다시 쓰면 안 된다. 여행을 돌아보며 정리하고 싶을 때 — 장소 이름 고치기, 노트를 맞는 날로 옮기기, 날씨에 못 살아남은 plan 고치기 — 유혹은 깔끔하게 읽히게 history 를 편집하는 거야. Waystone 는 편집을 금지하고 다른 수를 줘: 정정을 append 하되, 원본을 절대 덮지 마. 과거는 있던 그대로 남고; 정정은 위에 얹힌 새 fact 로, 언제 만들어졌는지 stamp 돼.

Append, 덮지 마

이게 breadcrumb 을 고치는 방식에 구체적으로 드러나. breadcrumb 의 원래 캡처 기록 — 언제 어디서 제출됐는지 — 은 immutable 이야. 텍스트나 place 를 고치고 싶어? 그건 캡처-시점 기록을 그대로 두면서 live view 에 fold 되는 edit revision 이야. 틀린 날짜로 정리해서 다른 날로 옮기고 싶어? 그건 스케줄 날짜의 append-only revision 이야; 정체성·캡처 시간·미디어·위치가 전부 안 바뀌어. 그리고 tombstone 된 breadcrumb 은 존재로 다시 revise 될 수 없어 — 삭제는 정직하고 최종이야, 조용히 되돌려지는 게 아냐. 정정은 언제나 가산이지 파괴가 아냐.

왜 이게 엔진 전체를 보호하나

이유는 이 트랙이 내내 맴돈 그거야: 엔진의 가치는 그때 뭘 알았는지를 기억하는 거야, 틀린 짐작·버린 계획·틀린 날에 정리한 노트까지. 그걸 다시 써 지우는 회고는 더 단정하고 덜 진실한 기록을 남겨 — 덜 진실함이 바로 기억 엔진이 감당 못 하는 실패야. 실제로 일어난 걸 지워서 산 깔끔해 보이는 history 는 부채야. append-only 정정이 Waystone 가 정확하면서도 정직하게 남는 방식이야: 지금 정확하고, 그때에 대해 정직하고.

이건 cwkPippa 의 ground truth 와 같은 본능이야: append-only 로그는 in-place 편집 안 하고; derived view 는 거기서 재빌드돼. 여행을 고치는 것과 대화를 고치는 게 똑같은 규칙을 따라 — 과거는 증거고, 증거는 편집하지 않아.

Code

breadcrumb 고치기: append, 절대 덮지 마·text

add:    crumb#42  text="Bort 에서 점심"  date=D14  captured=D14 10:31

# 텍스트 고침  -> edit revision 이 view 에 fold:
edit:   crumb#42  text="Bort 에서 점심 (rosti 최고)"
        # 캡처 시간, id, 미디어: 안 바뀜

# 틀린 날로 정리됨 -> 스케줄-날짜 revision append:
edit:   crumb#42  local_date=D13
        # ULID, captured_local_date, 캡처 시간, 미디어: 안 바뀜

# 삭제 -> tombstone, 그리고 다시 revise 못 함:
delete: crumb#42

# 원래 add 기록은 절대 다시 안 쓰임. 정정이 쌓여.
# 기록은 지금 정확하고 그때에 대해 정직해.

Exercise

사후에 '정리' 한 기록을 찾아봐 — 편집한 일기, 다시 쓴 계획, 고친 로그. 그 정리가 원래 쓴 걸 보존했어, 아니면 덮었어? 이제 그 지저분한 원본 자체가 그때 네 생각의 단서였다고 상상해봐. 단정한 버전이 조용히 뭘 지웠어 — 그거 되찾고 싶어?

Hint

append-only 테스트: 정정 후에도 원본을 아직 볼 수 있어? 고침이 덮으면, 깔끔한 기록을 최적화하고 네 과거 state 의 증거를 버린 거야. 쌓이는 정정은 정확한 '지금' 과 정직한 '그때' 를 둘 다 지켜.

과거를 다시 쓰지 마라

가장 어려운 규칙

Append, 덮지 마

왜 이게 엔진 전체를 보호하나

Code

External links

Exercise

Progress

댓글 0