과거를 다시 쓰지 마라

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

제일 어려운 규칙

이 트랙이 통째로 말하긴 쉽고 지키긴 어려운 규칙 하나로 모여. 회고는 그때 알던 걸 절대 다시 쓰면 안 된다. 여행을 돌아보며 정리하고 싶을 때, 장소 이름 고치고, 노트를 맞는 날로 옮기고, 날씨에 못 살아남은 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 로그는 자리에서 안 고치고, 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