캡처 그다음 조립

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

한 단계가 아니라 두 단계

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 캡처, 나중 링크된 해석) 각 단계가 다른 걸 오염 안 하고 자기 일을 잘할 수 있어.