umm v0.72.0
v0.72.0 — 내 생각을 여는 데 남의 서버를 기다리지 않습니다
"스페이스 로딩이 너무 느려. 메모가 별로 없어도 느려."
재 봤습니다.
임베딩이 사람의 경로 위에 있었습니다
공간을 연다 → 그동안 바뀐 메모를 전부 색인 → 게이트웨이 왕복 → 화면
메모를 쓴다 → 그 자리에서 벡터 생성 → 게이트웨이 왕복 → 저장 완료
ensureEmbeddings 의 호출자는 listNotes 하나뿐이었습니다. 공간을 여는 것이 색인의
계기였습니다. 그리고 UpsertEmbedding 이 메모 생성·수정에서 동기로 불렸습니다.
게이트웨이가 실패하면 더 나빴습니다 — 같은 읽기가 그 공간의 모든 메모를 로컬로 다시
썼습니다. 여전히 사람이 기다리는 채로.
메모 수와 무관합니다. 메모 세 개짜리 공간도 왕복 한 번은 그대로 냅니다.
실측
호출당 2초 걸리는 임베딩 게이트웨이, 메모 3개짜리 공간:
전 후
쓰기 3 + 읽기 1 6.39s → 0.18s
고친 것
읽기도 쓰기도 sweep에 알리고 즉시 돌아옵니다. 색인은 5초 주기 배경 작업이 하고, 공간을
열거나 메모를 쓰면 그 공간을 먼저 보라고 알립니다. 알림은 막지 않는 힌트라 버퍼가 차면
그냥 버립니다 — 다음 주기가 어차피 같은 메모를 찾기 때문입니다.
안 바뀐 것: AI 제외
제외된 생각은 별도 묶음으로 넘깁니다. 한 묶음에 섞으면 ensureEmbeddings 가 묶음
전체를 로컬로 떨어뜨려서, 제외되지 않은 남의 생각까지 설정한 모델을 못 쓰게 됩니다.
변형 시험에서 이걸 처음엔 못 잡았습니다 — 두 생각을 각각 다른 sweep에서 색인하면 섞일
일이 없어서, 어느 쪽이든 통과했습니다. 둘 다 색인되지 않은 상태에서 한 번에 돌리는
시험으로 바꾸니 잡힙니다.
임베딩 타임아웃을 채팅과 분리했습니다
둘은 기다리는 대상이 다릅니다. Dream을 쓰는 채팅 모델에는 몇 분을 줘도 되지만, 문장 하나를
임베딩하는 건 네트워크 한 홉 뒤의 1밀리초짜리 일이고, 그걸 기다리는 사람은 검색 중입니다.
하나로 묶여 있어서 채팅에 넉넉히 준 시간이 곧 검색이 기다리는 시간이었습니다.
embedding_timeout_seconds, 기본 10초. 안 정하면 채팅 값으로 떨어지지 않습니다 —
그러면 분리한 의미가 없습니다.
일하던 공간으로 돌아옵니다
같이 나온 별개 문제입니다.
내비게이션의 My Space 는 /canvas 를 가리키고, 그 주소는 공간을 지정하지 않습니다.
그래서 누를 때마다 이름 알파벳순 첫 공간이 열렸고, 주소도 /canvas 그대로라 그다음
새로 고침이 또 처음부터 판단했습니다.
ZZZ 공간에서 일하는 중
→ "My Space" 클릭
→ AAA 공간이 열림
→ 주소는 /canvas
→ 새로 고침 → 또 판단
- 주소가 공간을 가리키면 그게 이깁니다
- 아니면 마지막에 보던 공간
- 그것도 없으면 첫 공간
- 그리고 주소를 항상 고쳐 써서 다음 새로 고침이 다시 판단하지 않게 합니다
못 여는 공간이면 그렇다고 말합니다
주소가 가리키는 공간이 지워졌거나 공유가 회수됐으면, 예전에는 조용히 다른 공간을 보여
주면서 주소는 그대로 뒀습니다 — 주소와 화면이 서로 다른 것을 가리켰습니다. 이제 말합니다.
벡터가 최신이어야 하는 기능들
색인이 비동기가 되자 시험이 잡았습니다 — 방금 쓴 메모에 벡터가 없어서 연결 추천 · 아침
브리핑 · 공간 추천이 그 메모를 못 봤습니다. 조용히 빠지는 것이라 더 나쁩니다.
그 셋은 이제 스스로 sweep을 한 번 돌리고 시작합니다. 사람이 의도해서 누르는 기능이고,
정상 상태에선 아무것도 못 찾는 질의 한 번입니다.
확인한 것
✓ 느린 게이트웨이(2s)에서 읽기·쓰기 모두 1초 미만
✓ 읽기가 게이트웨이를 한 번도 부르지 않음
✓ sweep이 색인하고, 두 번째 패스는 빈손 (매번 다시 하지 않음)
✓ 고친 메모를 sweep이 다시 집음
✓ 제외된 생각은 게이트웨이에 안 가고, 로컬 벡터는 받음
✓ 제외된 생각이 옆 생각까지 로컬로 끌어내리지 않음
✓ 임베딩 타임아웃이 채팅 값을 따라가지 않고, 미설정 시 10초
✓ 브라우저: 내비 링크가 일하던 공간으로, 주소가 그 공간을 가리킴
✓ 브라우저: 두 번 새로 고쳐도 같은 공간
✓ 브라우저: 못 여는 공간이면 그렇다고 말함
| 바꾼 것 | 잡은 것 |
|---|---|
| 읽기가 다시 색인 | 읽기가 게이트웨이를 기다림 |
| 쓰기가 다시 동기 색인 | 쓰기가 게이트웨이를 기다림 |
| sweep이 오래된 것을 못 봄 | 고친 메모가 영영 안 잡힘 |
| 제외된 생각을 한 묶음에 | (처음엔 못 잡음 → 시험을 고침) |
| 임베딩 타임아웃이 채팅을 따라감 | 검색이 채팅 시간만큼 기다림 |
| 마지막 공간을 기억 안 함 | 링크가 엉뚱한 공간을 엶 |
| 주소를 안 고쳐 씀 | 새로 고침이 다시 판단 |
| 못 여는 공간을 조용히 교체 | 주소와 화면이 다른 곳을 가리킴 |
| Suspense를 앱 바깥으로 되돌림 | 화면 전체가 사라짐 |
| 목록을 다시 숫자 줄 안으로 | 읽는 순서가 엉킴 |
열 개 전부 검출(하나는 시험을 고친 뒤).
화면이 통째로 사라지지 않습니다
Suspense 가 라우트 트리 바깥에 있었습니다. 그래서 페이지 코드를 불러오는 동안
헤더와 내비게이션까지 언마운트됐습니다 — 화면 전체가 어두워지고 가운데 점이 돌다가,
다시 전부 그려졌습니다. 틀은 바뀐 게 하나도 없는데요.
앱이 재시작하는 것처럼 읽힙니다. 모든 요청이 10ms에 답하는데도 느리게 느껴진 큰
이유였습니다.
안으로 옮겼습니다. 이제 본문 영역만 기다리고, 누르는 순간 내비에서 가려는 곳이 이미
표시되므로 어디로 가는지 보입니다.
오늘의 리뷰 요약이 엉켜 있었습니다
지난밤 umm이 살펴본 것 의 숫자 블록과 그 아래 목록이 같은 Group 안의 형제였습니다.
Group 은 한 줄에 늘어놓고 감싸므로, 키 큰 목록 옆에 다음 숫자가 밀려 붙습니다.
전: 1 아직 정리하지 않은 5 답을 못 찾은 [질문 목록...] 1 기록해 둔 상충
↑ 상관없는 목록 오른쪽에 혼자
후: 1 아직 정리하지 않은 5 답을 못 찾은 1 기록해 둔 상충
질문으로 표시해 둔 것
...
글자는 어느 쪽이나 같아서, 시험은 기하로 확인합니다 — 숫자 라벨들이 같은 세로 띠에
있는지, 목록이 그 전부보다 아래에서 시작하는지.
아직 남은 것
메모가 많아지면 별도로 느려집니다. 카드의 "관련 N" 은 열 때마다 모든 쌍을 비교합니다.
| 메모 | 정상 상태 |
|---|---|
| 2,000 | 0.13s |
| 5,000 | 0.79s |
| 10,000 | 2.9s (그중 2.81s가 이 계산) |
이번 릴리스와는 다른 문제이고, 다음에 따로 갑니다. 조용히 두지 않고 적어 둡니다.
전체 검증: go test -p 1 ./internal/... ./cmd/...(통합 포함) · go vet · gofmt ·
변형 10종 전부 검출 · vitest 158개 · e2e 127개 전부(실제 바이너리·실제 번들) ·
oxlint(종료 코드) · Prettier · tsc · i18n 999키 · OpenAPI 드리프트 · PWA precache
What's Changed
Full Changelog: v0.71.7...v0.72.0
