본문 바로가기
C.W.K.
Stream
Lesson 02 of 04 · published

대화가 state 를 materialize 한다

~12 min · proposal, provenance, mutation, accept

Level 0표식 없는 길
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"여기선 말이 싸지 않아. 말이 itinerary를 짓는 방식이야. 단, 네가 yes 한 다음에."

턴 하나가 mutation을 제안할 수 있어

대화가 곧 계획이면, 대화 턴은 계획을 바꿀 수 있어야 해. 아니면 그냥 잡담이지. Waystone에선 턴 하나가 여러 개의 proposed 도메인 mutation을 만들 수 있어. 날을 더하거나 빼거나 순서를 바꾸고, 후보 장소를 넣거나 planned로 승격하고, route나 호텔을 비교하고, 추천이랑 rationale를 남기고, 아빠 결정을 기록하고, travel event를 만들고, 링크된 글 문서를 열고. 대화는 폼 위에 얹은 장식이 아냐. 구조화된 state가 쓰이는 주된 통로야.

Proposal, 그다음 accept. 절대 조용히는 아냐

근데 여기 신뢰를 지키는 규율이 있어. Pippa는 중요한 변경을 보이는 proposal이나 diff로 내놓고, 아빠가 같은 대화에서 accept하거나 reject하거나 다듬을 수 있어. 말이 나온 순간 중요한 게 그냥 쓰이는 일은 없어. accept라야 proposal이 canonical Waystone state로 바뀌고. 이건 'AI가 그냥 해버렸다' 패턴, 그러니까 assistant가 네 데이터를 조용히 바꿔놓고 넌 나중에야 알게 되는 그 패턴을 일부러 거부한 거야. Waystone에선 'Pippa가 제안했다'랑 '이제 이게 사실이다' 사이 경계가 눈에 보이는 사람의 행동이야.

Accept된 state는 provenance를 달고 와

proposal이 accept되면, 결과 state는 고아로 안 와. 그걸 만든 대화랑 결정을 provenance로 달고 와. 몇 달 뒤에 추가된 날이나 승격된 장소를 보고 인지 되짚을 수 있어. 어느 턴이었고, 어떤 추론이었고, 무슨 결정이었는지. 그 provenance가 itinerary 편집 더미를 방어할 수 있는 history로 바꿔. 설명 못 하는 편집은 못 믿을 편집이고, lineage 달린 편집은 audit하고 다시 찾아보고 배울 수 있는 편집이야.

이 proposal-그다음-accept 루프의 첫 완전한 버튼 버전이 Track 6의 Carve야. 거친 계획이나 사진이 리뷰 게이트가 걸린 proposed scaffold로 에디터에 뜨고, Accept라야 그게 persist돼. 이전 버전을 먼저 스냅샷하면서. 같은 루프를, 손에 잡히게 만든 거지.

Code

proposal -> accept -> provenance 루프·text
아빠 (대화에서):  "Zurich 빼고, Grindelwald 에 이틀 추가."
        |
        v
Pippa 가 DIFF 제안:  - remove day: Zurich (D2)
                     + add day: Grindelwald (D2)
                     + add day: Grindelwald (D3)
        |
        v
아빠: accept / reject / refine  <-- 인간의 경계
        |
   (accept)
        v
canonical state 가 mutate 되고, 새 날들이 provenance 를 실어:
   from_conversation: <id>   from_decision: "날씨로 Zurich 뺌"

# 'Pippa 가 제안했다' 와 '이제 사실이다' 는 다른 이벤트야.
# 그 둘 사이의 틈에 신뢰가 살아.

External links

Exercise

네 데이터를 편집하는 AI 도구를 떠올려봐. 똑똑한 캘린더, 이메일 자동응답, 파일을 정리해주는 assistant. 움직이기 전에 proposal을 보여줘, 아니면 그냥 해놓고 네가 알아채길 바라? 이제 1년 뒤에 그 변경 중 하나가 왜 일어났는지 설명해야 한다고 그려봐. 할 수 있어? 그 변경을 audit할 수 있게 만들 최소한의 'accept' 단계를 설계해봐.
Hint
제일 싼 audit 가능성은 보이는 diff에 저장된 이유를 붙이는 거야. AI 변경이 '어떤 요청이 이걸 일으켰고 왜?'에 답 못 하면, 오늘은 편의고 내일은 미스터리야. accept 단계가 이유가 붙는 자리야.

Progress

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

댓글 0

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

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