연속성은 canonical, 표현은 제한적

"폰은 창을 보여줘. 백엔드는 방 전체를 쥐어. 창을 방으로 절대 착각하지 마."

'그 대화'라 불리는 다른 두 가지

폰에선 화면 공간이랑 메모리가 빠듯하니까, Pippa Go 는 제한된 뷰를 보여줘: 최근 질문-답 교환, 반드시 전체 역사는 아닌. 표현엔 맞는 판단이야 — 아무도 폰에서 천 개 턴을 스크롤하고 싶지 않으니까. 근데 위험한 유혹을 만들어: 폰이 보여주는 걸 대화 그 자체로 다루고, 다음 턴의 컨텍스트를 그 제한된 창에서 짓는 거. 그 유혹은 거부해야 해. 연속성 — Pippa 가 추론하는 진짜, 완전한 컨텍스트 — 은 백엔드가 소유해. 표현 — 폰이 렌더하는 것 — 은 설계상 제한적이고 손실이 있어. 둘은 같은 객체가 아니고, 작은 게 큰 걸 절대 정의하면 안 돼.

창에서 컨텍스트를 재구축하지 마라

구체적 규칙: 새 턴을 보낼 때, 그 컨텍스트는 백엔드가 canonical 로그에서 재구축해야 해 — 완전한 리플레이, 자동 압축, 전부 — 절대 폰에서 마지막 N 개 보이는 메시지로 조립하면 안 돼. 폰이 컨텍스트를 지으면, 대화가 화면 밖으로 스크롤된 모든 걸 조용히 잃고, Pippa 는 앞선 역사가 없었던 것처럼 답할 거야. 제한된 창은 뷰포트지 출처가 아냐. 덜 렌더하는 건 괜찮아; 덜 기억하는 건 버그야.

표현 (폰): 최근 턴을 보여주고, 공간 위해 옛것을 버릴 수 있어. 일부러 손실.
연속성 (백엔드): 모든 턴을 위해 전체 대화를 리플레이해. 설계상 무손실.
규칙: 다음 턴의 컨텍스트는 연속성에서 오지, 절대 표현에서 안 와.

왜 이 분리가 안전한가 (그리고 필요한가)

이 둘을 분리하면 각각 자기 일에 최적일 수 있어. 표현은 공격적으로 최소일 수 있어 — 빠르고, 가볍고, 폰 친화적 — 정확히 메모리 책임을 안 지니까. 연속성은 철저할 수 있어 — 완전한 리플레이, 압축, 전부 — 정확히 화면에 안 맞아도 되니까. 융합하면 둘 다 나빠져: 폰이 전부 쥐고 렌더해야 하거나(무겁고 느림), 대화 메모리가 뷰포트에 맞는 만큼 쪼그라들거나(고장). 분리해 두는 게, Pippa Go 가 폰에선 가볍게 느껴지면서 백엔드에선 전부 기억하게 해. 창이 작을 수 있는 건 정확히 방이 완전하기 때문이야.

Code

다음 턴의 컨텍스트는 보이는 목록이 아니라 백엔드에서 온다·typescript

// 틀림: 폰이 보여주는 걸로 컨텍스트를 지음.
async function askWrong(convId: string, q: string, visibleTurns: Turn[]) {
  const context = visibleTurns.slice(-10);   // 화면의 마지막 10개 — 손실
  return callModel({ convId, q, context });   // 스크롤된 전부를 잊음
}

// 맞음: 백엔드가 canonical 로그에서 완전한 연속성을 재구축.
async function ask(convId: string, q: string) {
  return callCanonical({ convId, q });        // 백엔드가 전체 역사 리플레이
}

// 폰은 트랜스크립트가 아니라 식별자를 넘겨. 기억은 백엔드의 일;
// 보이는 목록은 뷰포트지 절대 컨텍스트의 출처가 아냐.

Exercise

챗 클라이언트를 하나 골라 메모리가 뷰에 제한되는지 테스트해: 멀리 스크롤 올려서, 맨 위 근처에만 보이는 뭔가에 의존하는 새 턴을 시작하고, 모델이 여전히 그걸 '기억'하는지 봐. 연속성이 보이는 창에 묶여 있으면, 모델이 잊어. 그다음 어떻게 고칠지 묘사해: 보이는 트랜스크립트를 컨텍스트로 보내는 대신, 식별자를 넘기고 백엔드가 완전한 컨텍스트를 리플레이하게.

Hint

실패 서명은 화면 밖으로 스크롤된 걸 '잊는' 모델 — 컨텍스트가 표현 창에서 지어졌다는 증거야. 해법은 항상 연속성을 conversation id 로 키한 백엔드 책임으로 만들고, 폰은 트랜스크립트가 아니라 참조를 넘기는 거야.