캡처 그다음 조립

"움직이는 동안 조각을 남겨. 멈추면 그걸 이해해. 두 일, 두 자세, 두 순간."

한 단계가 아니라 두 단계

Waystone 는 여행 로깅을 일부러 분리된 두 단계로 쪼개. 요구가 완전히 다르니까. 움직이며: 몇 초 만에 유용한 breadcrumb 남기기 — 빠르고, 싸고, 해석 없고, Pippa 조용. 호텔에서: Pippa 가 그 breadcrumb 을 일관된 event·route 변경·결정·draft 산문으로 조립하게 돕기 — 느리고, 풍부하고, 해석적이고, Pippa 두드러짐. 둘을 한 번에 하려는 게 전형적 실수야: 캡처를 현장에 너무 무겁게, 조립을 저녁에 너무 얕게 만들어. 분리해 두면 각자 자기 일을 잘할 수 있어.

조립은 제안하지, 안 덮어

저녁 단계 — 'Assemble Today' — 는 그날의 breadcrumb·itinerary·route·이전 journey context 위에 Pippa consultation 을 시작해. Pippa 가 제안해: 이 세 조각을 케이블카 event 하나로 묶어, 저걸 오전과 오후로 쪼개, 이 crumb 을 결정으로 승격해, 그날 서사를 draft 해. 근데 기억 명제 전체로 되돌아가는 규율이 여기 있어: 원래 breadcrumb 은 조립 후에도 immutable 증거로 남아. 구조화된 event 와 산문 draft 는 자기 소스 breadcrumb ID 로 링크하지; 대체하거나 편집하지 않아. 조립은 증거 위에 얹힌 해석이지, 그걸 다시 쓰는 게 절대 아냐.

왜 분리가 설계인가

이 두-단계 형태가 모바일 표면이 계획 대화가 아니라 캡처 스트림으로 열리는 이유, Pippa 가 현장에선 조용하고 호텔에선 두드러지는 이유야. 비 속을 걷는 사람의 interaction budget 과 저녁 후 차 들고 앉은 사람의 interaction budget 은 같지 않고, 같은 척하면 둘 다 못 섬기는 도구가 나와. 캡처는 속도와 생존을 최적화; 조립은 의미와 일관성을 최적화. 엔진은 이게 여행자 하루의 두 다른 순간임을 존중하고 — 각각에 다른 표면을 지어.

Code

두 단계, 두 자세·text

단계 1 -- 움직이며 (캡처)
  목표:     조각을, 몇 초 만에 담기
  Pippa:    조용; latency 가 절대 안 막음
  출력:     immutable breadcrumb (증거)

단계 2 -- 호텔에서 (조립)
  목표:     그날을 이해하기
  Pippa:    두드러짐; 클러스터·event·draft 제안
  출력:     구조화된 event + 산문, crumb id 로 LINK
            (crumb 은 아래 immutable 로 남음)

# 조립은 증거 위에 얹힌 해석이야.
# 원래 breadcrumb 을 절대 편집하거나 대체 안 해.

Exercise

지금 네가 뭔가 캡처하고 그다음 처리하는 방식을 생각해봐 — 노트를 요약으로, 사진을 앨범으로, 태스크를 계획으로. 둘을 한 번에 하려 해(그리고 둘 다 못 하게 돼), 아니면 진짜 '지금 빨리 캡처, 나중에 이해' 분리가 있어? raw 캡처가 immutable 로 남고 처리된 버전이 그냥 링크로 돌아가면 뭐가 달라질까?

Hint

뭉개진 두-단계의 징후는 순간에 과처리하거나(캡처하기엔 너무 느림) 아예 처리 안 하거나(조각이 안 읽힌 채 쌓임)야. 분리하면 — 빠른 immutable 캡처, 나중 링크된 해석 — 각 단계가 다른 걸 오염 안 하고 자기 일을 잘할 수 있어.